Настройка табличных функций
Ivanov Sergey
Использую в запросах табличные функции, например,
select sp.ChildID from table(sp_c_AllChilds(cast(:ID as number(9)))) sp
where sp.ChildID <> :ID
and exists (select b.ID from BBBB b where b.RefTTTT = sp.ChildID and
b.IsCurrent = 1)
Данный запрос вместе с другими запросами выполняется очень часто, на
некоторых данных возвращается такой "ответ":
ORA-03113: принят сигнал конца файла по коммуникационному каналу
Что и как нужно настроить на сервере, чтобы такие запросы работали без
ошибок?
Функция sp_c_AllChilds рекурсивная - обходит дерево по таблице. Дерево
корректно (без зацикливаний). Сама по себе функция работает на том же,
проблемном, значении параметра и выдаёт сравнительно немного записей - не
более 200. И даже этот запрос работает, если его гонять через sqlplus,
указав значение параметра. Я понимаю, что для работы с деревьями в Оракле
есть, свои расширения SQL, но я использую данную функцию и вообще запрос для
совместимости с другой СУБД.
Работаю на 9i R2 под Windows, подключаюсь через ODAC (Delphi), используя
оракловского клиента (то есть без всяких Net).
Я в Oracle понимаю мало, особенно в администрировании и настройках.
В своё время на подобных запросах вываливалось много сообщений о
невозможности выделить память. Эмпирическим (алхимическим) путём удалось
заткнуть большую часть подобных ошибок, увеличением shared_pool_size. Причём
при 30 подключениях пользователей этот пул приходится устанавливать почти в
гигабайт, а large_pool_size - в нуль (хотя иногда ругань вылезала, что
невозможно выделить именно эту память).
У кого-нибудь есть опыт работы с табличными функциями? Чего им нужно?
Albert Indeev
> Использую в запросах табличные функции, например,
>
> select sp.ChildID from table(sp_c_AllChilds(cast(:ID as number(9)))) sp
> where sp.ChildID <> :ID
> and exists (select b.ID from BBBB b where b.RefTTTT = sp.ChildID and
> b.IsCurrent = 1)
>
> Данный запрос вместе с другими запросами выполняется очень часто, на
> некоторых данных возвращается такой "ответ":
>
> ORA-03113: принят сигнал конца файла по коммуникационному каналу
>
Трудно ответить (информации мало), скорее всего дело не в запросе и не в
табличной функции, а в сетевой работе или DAC. Вот что написано в Bugs
fixed in the 9.2.0.4 Patch Set по поводу одной из ORA-03113:
Instance termination during a big array fetch or prefetch
can result in an unexpected ORA-3123 being returned to the
client application even though it is not non-blocking-mode.
This can cause TAF (Transparent Application Failover) not
to failover.
Скорее всего это, попробуйте вывести базу на версию 9.2.0.4 или 9.2.0.5.
С уважением Альберт Индеев.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Ivanov Sergey
news:ccv6mu$j5q$1...@host.talk.ru...
Запатчил. Не помогло. Явно на сервере нужно что-то настраивать, а что, я не
знаю.
Alexandr V.Ivanov
IS> "Albert Indeev" <gov_...@first.sakhanet.ru> wrote
>in message
IS> news:ccv6mu$j5q$1...@host.talk.ru...
IS>> Ivanov Sergey wrote:
IS>> > Использую в запросах табличные функции, например,
IS>> >
IS>> > select sp.ChildID from table(sp_c_AllChilds(cast
> (:ID as number(9)))) sp
IS>> > where sp.ChildID <> :ID
IS>> > and exists (select b.ID from BBBB b where
> b.RefTTTT = sp.ChildID and
IS>> > b.IsCurrent = 1)
IS>> >
IS>> > Данный запрос вместе с другими запросами
> выполняется очень часто, на
IS>> > некоторых данных возвращается такой "ответ":
IS>> >
IS>> > ORA-03113: принят сигнал конца файла по
> коммуникационному каналу
Считаю, что Альберт прав, и стоит еще раз перепроверить
является ли связь с клиентом иделальной, поскольку
некоторые приложения очень чувствительны к качеству
связи.
Мне известен пример такой интеграции, когда интерфейсное
приложение производит "цикл" по данным, поручая серверу
часть вычислений. И в результате довольно высокий трафик.
Может быть попробовать заменить exists на менее
оптимальное объединение? (или b.ID на 1:) или логику )
--
Alexandr V. Ivanov
DBA, OCP 9i
Albert Indeev
>>>
>
> Запатчил. Не помогло. Явно на сервере нужно что-то настраивать, а что, я не
> знаю.
>
файлов патча?
Ivanov Sergey
> >>>ORA-03113: принят сигнал конца файла по коммуникационному каналу
> >>>
> >>Скорее всего это, попробуйте вывести базу на версию 9.2.0.4 или 9.2.0.5.
> >
> > Запатчил. Не помогло. Явно на сервере нужно что-то настраивать, а что, я
не
> > знаю.
> >
> Извините за уточнение, а Post Installation Task делали после копирования
> файлов патча?
Для третьего патча в том виде, как это написано в доке к патчу, не делал.
Я до этого думал, что патчи не кумулятивные и пытался последовательно
накатывать каждый поверх другого. В общем, мне не понравилось так долго
ждать выполнения скрипта catpatch.sql и выделять столько памяти под Яву.
Даже рекомендованная очистка статистики SYS-а не помогает. В третьем патче
(9.2.0.4) я поступил проще и быстрее: сделал экспорт своей схемы, грохнул
базу, обновил сервер, создал базу с нуля, сделал импорт в новую базу. Я так
понимаю, что это то же самое, что и выполнение catpatch.sql. Так? По крайней
мере, запрос
select comp_name || ' ' || status || ' ' || version from dba_registry;
возвращает, что почти все пакеты имеют версию 9.2.0.4 (хотя Workspace
Manager - 9.2.0.1, а XDK for Java - 9.2.0.6).
Dmitry P. Konopatsky
> > файлов патча?
>
> Для третьего патча в том виде, как это написано в доке к патчу, не делал.
> Я до этого думал, что патчи не кумулятивные и пытался последовательно
> накатывать каждый поверх другого. В общем, мне не понравилось так долго
> ждать выполнения скрипта catpatch.sql и выделять столько памяти под Яву.
> Даже рекомендованная очистка статистики SYS-а не помогает. В третьем патче
> (9.2.0.4) я поступил проще и быстрее: сделал экспорт своей схемы, грохнул
> базу, обновил сервер, создал базу с нуля, сделал импорт в новую базу. Я
так
> понимаю, что это то же самое, что и выполнение catpatch.sql. Так? По
крайней
> мере, запрос
> select comp_name || ' ' || status || ' ' || version from dba_registry;
> возвращает, что почти все пакеты имеют версию 9.2.0.4 (хотя Workspace
> Manager - 9.2.0.1, а XDK for Java - 9.2.0.6).
>
По старому опыту - нужно прогонять catpatch.sql & etc. после создания базы
для пропатченного оракла.