SQL.RU
 client/server technologies
 
 Главная | Документация | Статьи | Книги | Форум | Опросы | Рассылка | Работа | Поиск | FAQ |

Добро пожаловать в форум, Guest  >>  Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик  Ответить
 Межпроцессная коммуникация - совет нужен   [new]
ASNexus
Member

Откуда: Tula
Сообщений: 92
Прошу подсказку, в каком направлении смотреть.

Есть задача, которая выполняется периодически по мере поступления файлов - они грузятся с помощью SQL Loader'а в таблицу, на которой триггер FOR EACH ROW выполняет некоторые действия. Есть требование обеспечить контроль времени последней загрузки. Решить планирую с помощью job'а, который будет запускаться, например, 1 раз в пол часа и проверять время последней загрузки и отсылать сообщение (email), если загрузки давно не было.

Собственно суть - хочется использовать наименее ресурсоемкую возможность обозначения первым процессом времени своего запуска (т.е. при обработке каждой строки триггер выставляет где-то значение SYSDATE). Что-нибудь вроде общедоступной переменной в SGA.

Писать время в таблицу из одной строки и одного поля нет желания, также как и использовать AQ или ALERT (инсертов много, требования абсолютной гарантии получения сообщения нет), PIPE тоже (будет плохо, если умрет получатель).

В принципе, насколько я понимаю, можно прикрутить CONTEXT ACCESSED GLOBALLY, но есть свои сложности, да и не для этих целей данный механизм придуман.

Есть какие-то другие возможности одному процессу выставить значение переменной, а другому ее получить (повторюсь, гарантии получения после рестарта инстанса точно не нужно, т.к. такое явление само по себе ЧП и о нем и так заинтересованные лица будут в курсе, нужны наименьшие затраты времени первого, выставляющего переменную, процесса)?
19 фев 08, 21:50    [5312839] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5009
ASNexus

Писать время в таблицу из одной строки и одного поля нет желания,


Путь это будет таблица-журнал загрузок. Загрузка прошла - занесли в неё запись, когда и что было загружено, если не загружено, то почему. IMHO, для SQL*Loader добавить запись в таблицу сущие пустяки, тогда как реализация других методов наверняка потребует работы мозга как в плане регистрации данных так и в плане их целостного извлечения.

С другой стороны, если гарантия не нужна, так может быть и не делать ничего?
19 фев 08, 22:34    [5312929] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1348
ASNexus
Прошу подсказку, в каком направлении смотреть.

Есть задача, которая выполняется периодически по мере поступления файлов - они грузятся с помощью SQL Loader'а в таблицу, на которой триггер FOR EACH ROW выполняет некоторые действия.


Это уже не выглядит хорошо. :-) зачем там триггер для каждой строки?

ASNexus
"(т.е. при обработке каждой строки триггер выставляет где-то значение SYSDATE). Что-нибудь вроде общедоступной переменной в SGA."


Зачем это делать при обработки каждой строки... не проще это делать раз в n (5-10-30) минут и в автономной транзакции просто выполнять обновление даты процессига в какой-нибудь таблице, в которую код проверки и будет периодически смотреть. А ещё лучше это сделать тогда когда sql*loader сеанс появляется т.е. через on-logon trigger, например.

...
l_refresh_time DATE := SYSDATE;
...
...
IF (l_refresh_time < SYSDATE - 1/24/60*5)
THEN
  l_refresh_time := SYSDATE;
  -- ну там ещё чё-нибудь записать можно, если нужно
  call some updater;
END IF
19 фев 08, 22:42    [5312948] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
ASNexus
Member

Откуда: Tula
Сообщений: 92
mcureenab
ASNexus

Писать время в таблицу из одной строки и одного поля нет желания,

Путь это будет таблица-журнал загрузок. Загрузка прошла - занесли в неё запись, когда и что было загружено, если не загружено, то почему. IMHO, для SQL*Loader добавить запись в таблицу сущие пустяки, тогда как реализация других методов наверняка потребует работы мозга как в плане регистрации данных так и в плане их целостного извлечения.


Загрузок много и с большим количеством записей, в триггере FOR EACH ROW писать лог смысла нет, делать еще один триггер AFTER STATEMENT большая нагрузка. Даже если его сделать, со временем может начать тормозить процедура контроля (или надо будет думать над автоматизированной очисткой устаревших записей лога). В любом случае без работы мозга не обойтись, хочется сделать оптимально (и для собственного опыта в том числе :-))

mcureenab

С другой стороны, если гарантия не нужна, так может быть и не делать ничего?

Нужно примерно с такой достоверностью - загрузка идет 1 раз в пол часа, контролер это проверяет и, если не было загрузки в течении 6 часов, отправляет сообщение - то есть контроль нужен, но не особо критичный.
19 фев 08, 22:45    [5312957] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
ASNexus
Member

Откуда: Tula
Сообщений: 92
Владимир Бегун
ASNexus
Прошу подсказку, в каком направлении смотреть.

Есть задача, которая выполняется периодически по мере поступления файлов - они грузятся с помощью SQL Loader'а в таблицу, на которой триггер FOR EACH ROW выполняет некоторые действия.


Это уже не выглядит хорошо. :-) зачем там триггер для каждой строки?


К сожалению в данном случае требования бизнес-логики - каждая строка пришедшего файла должна обработаться и, в случае ошибки (EXCEPTION'а в триггере по любой причине), соответствующая запись должна быть в log-файле loader'а.
19 фев 08, 22:53    [5312970] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 11564
ASNexus
В принципе, насколько я понимаю, можно прикрутить CONTEXT ACCESSED GLOBALLY, но есть свои сложности
А в чем сложности-то?
Тем более, что, как я понял, нисколько не критично, если несколько процессов попытаются записать дату последней загрузки одновременно, т.е. можно не заморачиваться с блокировками и т.д.
20 фев 08, 01:55    [5313218] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5009
ASNexus
Загрузок много и с большим количеством записей, в триггере FOR EACH ROW писать лог смысла нет, делать еще один триггер AFTER STATEMENT большая нагрузка. Даже если его сделать, со временем может начать тормозить процедура контроля (или надо будет думать над автоматизированной очисткой устаревших записей лога). В любом случае без работы мозга не обойтись, хочется сделать оптимально (и для собственного опыта в том числе :-))
.


А кто тебе сказал, что журнал нужно непременно через триггер заполнять? Пусть SQL*Loader запись в журнал добавляет в КОНЦЕ загрузки. Тогда никакой особой нагрузки на СУБД не будет, да и если загрузка упадёт на пол пути, то дежурный оператор системы об этом узнает.
Просто, я не знаю как у тебя загрузка запускается. Если скриптом, то можно в скрипт добавить вызов SQL*Plus с SQL скриптиком, который простым insert внесёт запись в журнал.
20 фев 08, 03:13    [5313275] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
ASNexus
Member

Откуда: Tula
Сообщений: 92
Вячеслав Любомудров
ASNexus
В принципе, насколько я понимаю, можно прикрутить CONTEXT ACCESSED GLOBALLY, но есть свои сложности
А в чем сложности-то?
Тем более, что, как я понял, нисколько не критично, если несколько процессов попытаются записать дату последней загрузки одновременно, т.е. можно не заморачиваться с блокировками и т.д.


Основной мой вопрос, который я не очень понял при чтении документации - возможно-ли сделать контекст видимым при логине другим пользователем (про установку ID понятно, но вот необходимо или нет, чтобы обе сессии, и устанавливающая контекст, и читающая его, были под одним и тем-же пользователем)?
Для моей задачи крайне желательно, чтобы пользователи были разными (загрузка запускается из скрипта, в котором явно прописан логин и пароль, поэтому у пользователя только необходимые для его работы права, и давать ему их больше не хотелось бы).

Ну и вопрос, не будет-ли это "из пушки по воробьям", может есть другие варианты?
20 фев 08, 11:15    [5314397] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
ASNexus
Member

Откуда: Tula
Сообщений: 92
mcureenab
ASNexus
Загрузок много и с большим количеством записей, в триггере FOR EACH ROW писать лог смысла нет, делать еще один триггер AFTER STATEMENT большая нагрузка. Даже если его сделать, со временем может начать тормозить процедура контроля (или надо будет думать над автоматизированной очисткой устаревших записей лога). В любом случае без работы мозга не обойтись, хочется сделать оптимально (и для собственного опыта в том числе :-))
.


А кто тебе сказал, что журнал нужно непременно через триггер заполнять? Пусть SQL*Loader запись в журнал добавляет в КОНЦЕ загрузки. Тогда никакой особой нагрузки на СУБД не будет, да и если загрузка упадёт на пол пути, то дежурный оператор системы об этом узнает.
Просто, я не знаю как у тебя загрузка запускается. Если скриптом, то можно в скрипт добавить вызов SQL*Plus с SQL скриптиком, который простым insert внесёт запись в журнал.


Загрузка запускается в CMD-файле Windows, и конечно можно прописать после нее вызов контрольной процедуры. Просто хотелось бы сделать средствами Oracle, для большей наглядности.
20 фев 08, 11:17    [5314417] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 11564
ASNexus
Основной мой вопрос, который я не очень понял при чтении документации - возможно-ли сделать контекст видимым при логине другим пользователем (про установку ID понятно, но вот необходимо или нет, чтобы обе сессии, и устанавливающая контекст, и читающая его, были под одним и тем-же пользователем)?
Для моей задачи крайне желательно, чтобы пользователи были разными (загрузка запускается из скрипта, в котором явно прописан логин и пароль, поэтому у пользователя только необходимые для его работы права, и давать ему их больше не хотелось бы).
Проверить -- 5 мин :)
Пользователи, естественно, могут быть разными (на то он и глобальный), но т.к. устанавливать значение придется из доверенного пакета, на него необходимо будет дать соответствующие права
20 фев 08, 11:22    [5314459] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
ASNexus
Member

Откуда: Tula
Сообщений: 92
Вячеслав Любомудров
ASNexus
Основной мой вопрос, который я не очень понял при чтении документации - возможно-ли сделать контекст видимым при логине другим пользователем (про установку ID понятно, но вот необходимо или нет, чтобы обе сессии, и устанавливающая контекст, и читающая его, были под одним и тем-же пользователем)?
Для моей задачи крайне желательно, чтобы пользователи были разными (загрузка запускается из скрипта, в котором явно прописан логин и пароль, поэтому у пользователя только необходимые для его работы права, и давать ему их больше не хотелось бы).
Проверить -- 5 мин :)
Пользователи, естественно, могут быть разными (на то он и глобальный), но т.к. устанавливать значение придется из доверенного пакета, на него необходимо будет дать соответствующие права


Большое спасибо!

Естественно буду проверять (это и подразумевалось под "своими сложностями" :-) ) Думал, вдруг еще про какую-нибудь возможность я не знаю, или от использования контекстов для этих целей категорически отговорят знающие люди. Значит буду делать так, доверенный пакет будет содержать только одну процедуру для установки значения, дать права на его исполнение не проблема конечно.
20 фев 08, 15:30    [5317006] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 11564
Я когда-то рисовал статью по этому поводу для наших программеров
Помимо обычного (приватного) контекста, начиная с версии 9.0.1 в Oracle появился глобальный контекст приложения. Он позволяет "разделять" (share) данные контекста между сессиями. Более того, значения в глобальном контексте сохраняются до перезагрузки БД или явной очистки.

Для разграничения доступа используются дополнительные атрибуты:

- USERNAME -- имя пользователя Oracle, под которым аутентифицирована сессия. Если это имя не указано (NULL) -- доступ к содержимому контекста получают все пользователи с соответствующим CL_IDENTIFIER

- CL_IDENTIFIER -- идентификатор клиента -- произвольное текстовое значение (до 64 байт), используемое для идентификации группы сессий, получающих доступ к данным контекста. Только при совпадении CL_IDENTIFIER у сессии, устанавливающей содержимое контекста и читающей это содержимое возможен доступ. При этом NULL=NULL.

Указывать значение USERNAME может только сессия, устанавлмвающая данные контекста. Для читающей сессии это значение есть значение функции USER.

Значение CL_IDENTIFIER могут устанавливать как пишущая сессия (dbms_session.set_context), указывая тем самым группу сессий, которые будут иметь доступ к этим данным, так и читающая (dbms_session.set_identifier), подключаясь к известной группе.

Например, можно передавать данные отчетам через глобальный контекст, установив нужный CL_IDENTIFIER в отчете, который передается как параметр отчета при запуске (USERNAME у них будет одинаковый).

В отношения чтения/записи все сессии равноправные -- если сессия имеет доступ к данным определенного глобального контекста (USERNAME, CL_IDENTIFIER), то она так же может менять/удалять/добавлять данные.


Возможные грабли

Данные в глобальном контексте не удаляются сами по себе и остаются болтаться до перезагрузки экземпляра или явной очистки. При этом все содержимое располагается в Shared pool в SGA - глобальной памяти для экземпляра БД. Размер ее, естественно, ограничен, поэтому при распухании места под глобальный контекст остальные структуры в Shared pool (кешированные SQL операторы, пакеты и другие PL/SQL блоки, а также записи и определения словаря данных) могут быть вытеснены из памяти, что приведет к резкому ухудшению производительности и в конце концов исчерпанию памяти. Поэтому основное правило при работе с глобальными контекстами: "ПОЕЛ - УБЕРИ ЗА СОБОЙ" (добавлял данные в глобальный контекст - очисти их с помощью операции clear).

Так же не забываем, что в глобальном контексте могут находиться одинаковые "переменные" (атрибуты) с разными значениями для разных CL_IDENTIFIER (даже для одинаковых USERNAME), что может внести некоторую путаницу. И что CL_IDENTIFIER равный NULL представляет собой обычное значение, как и любое другое, например 'PUPKIN'. Что тоже ясности не добавляет.

Ну и проблемы с секурностью - любой, кто видит данные контекста - может их изменить. Более того, изменение данных пользователем с определенным CL_IDENTIFIER (возможно NULL) для определенного атрибута удалит значение этого атрибута для ВСЕХ USERNAME для соответствующего CL_IDENTIFIER

И опять секурность - при очистке контекста (операция clear), для соответствующего CL_IDENTIFIER очищаются данные для ВСЕХ USERNAME

Небольшой примерчик:
tst> connect u1/u1@tst
Connected.
tst> create context gctx using gctx_set accessed globally;

Context created.

tst> create procedure gctx_set(field in varchar2, value in varchar2, cl_ident varchar2, usr varchar2 default user) as
  2  begin dbms_session.set_context('GCTX', field, value, usr, cl_ident);
  3  end;
  4  /

Procedure created.

tst> exec u1.gctx_set('V1', 'User + Identifier', 'Id1', user)

PL/SQL procedure successfully completed.

tst> exec u1.gctx_set('V2', 'User with NULL Id', null, user)

PL/SQL procedure successfully completed.

tst> exec u1.gctx_set('V3', 'Any User + ID', 'Id2', null)

PL/SQL procedure successfully completed.

tst> exec u1.gctx_set('V4', 'Any User with NULL Id', null, null);

PL/SQL procedure successfully completed.

tst> select 'V1', substr(sys_context('GCTX', 'V1'), 1, 20) from dual union all
  2  select 'V2', substr(sys_context('GCTX', 'V2'), 1, 20) from dual union all
  3  select 'V3', substr(sys_context('GCTX', 'V3'), 1, 20) from dual union all
  4  select 'V4', substr(sys_context('GCTX', 'V4'), 1, 20) from dual;

'V SUBSTR(SYS_CONTEXT('
-- --------------------
V1  /* не видим, т.к. текущий CL_IDENTIFIER не установлен (NULL) */
V2 User with NULL Id
V3  /* аналогично */
V4 Any User with NULL I

tst> exec dbms_session.set_identifier('Id1');

PL/SQL procedure successfully completed.

tst> select 'V1', substr(sys_context('GCTX', 'V1'), 1, 20) from dual union all
  2  select 'V2', substr(sys_context('GCTX', 'V2'), 1, 20) from dual union all
  3  select 'V3', substr(sys_context('GCTX', 'V3'), 1, 20) from dual union all
  4  select 'V4', substr(sys_context('GCTX', 'V4'), 1, 20) from dual;

'V SUBSTR(SYS_CONTEXT('
-- --------------------
V1 User + Identifier
V2  /* остальное не видим, т.к. больше с таким CL_IDENTIFIER ничего нет) */
V3
V4

tst> connect system/manager@tst
Connected.
tst> select 'V1', substr(sys_context('GCTX', 'V1'), 1, 20) from dual union all
  2  select 'V2', substr(sys_context('GCTX', 'V2'), 1, 20) from dual union all
  3  select 'V3', substr(sys_context('GCTX', 'V3'), 1, 20) from dual union all
  4  select 'V4', substr(sys_context('GCTX', 'V4'), 1, 20) from dual;

'V SUBSTR(SYS_CONTEXT('
-- --------------------
V1  /* USER не совпадает */
V2  /* ничего не совпадает */
V3  /* USER по барабану, но CL_IDENTIFIER не совпадает */
V4 Any User with NULL I

tst> exec dbms_session.set_identifier('Id1');

PL/SQL procedure successfully completed.

tst> select 'V1', substr(sys_context('GCTX', 'V1'), 1, 20) from dual union all
  2  select 'V2', substr(sys_context('GCTX', 'V2'), 1, 20) from dual union all
  3  select 'V3', substr(sys_context('GCTX', 'V3'), 1, 20) from dual union all
  4  select 'V4', substr(sys_context('GCTX', 'V4'), 1, 20) from dual;

'V SUBSTR(SYS_CONTEXT('
-- --------------------
V1
V2  /* CL_IDENTIFIER совпадает, но USER нет */
V3
V4

tst> exec dbms_session.set_identifier('Id2');

PL/SQL procedure successfully completed.

tst> select 'V1', substr(sys_context('GCTX', 'V1'), 1, 20) from dual union all
  2  select 'V2', substr(sys_context('GCTX', 'V2'), 1, 20) from dual union all
  3  select 'V3', substr(sys_context('GCTX', 'V3'), 1, 20) from dual union all
  4  select 'V4', substr(sys_context('GCTX', 'V4'), 1, 20) from dual;

'V SUBSTR(SYS_CONTEXT('
-- --------------------
V1
V2
V3 Any User + ID
V4

tst> exec u1.gctx_set('V1', 'Updated', 'Id1', user) 
/* для другого USER (SYSTEM) завели с тем же CL_IDENTIFIER одинаковый с U1 аттрибут */

PL/SQL procedure successfully completed.

tst> exec u1.gctx_set('V3', 'Updated', 'Id2', null) 
/* изменили аттрибут для всех USER с тем же CL_IDENTIFIER */

PL/SQL procedure successfully completed.

tst> exec dbms_session.set_identifier('Id1');

PL/SQL procedure successfully completed.

tst> select 'V1', substr(sys_context('GCTX', 'V1'), 1, 20) from dual union all
  2  select 'V2', substr(sys_context('GCTX', 'V2'), 1, 20) from dual union all
  3  select 'V3', substr(sys_context('GCTX', 'V3'), 1, 20) from dual union all
  4  select 'V4', substr(sys_context('GCTX', 'V4'), 1, 20) from dual;

'V SUBSTR(SYS_CONTEXT('
-- --------------------
V1 Updated  /* свое видим */
V2
V3
V4

tst> exec dbms_session.set_identifier('Id2');

PL/SQL procedure successfully completed.

tst> select 'V1', substr(sys_context('GCTX', 'V1'), 1, 20) from dual union all
  2  select 'V2', substr(sys_context('GCTX', 'V2'), 1, 20) from dual union all
  3  select 'V3', substr(sys_context('GCTX', 'V3'), 1, 20) from dual union all
  4  select 'V4', substr(sys_context('GCTX', 'V4'), 1, 20) from dual;

'V SUBSTR(SYS_CONTEXT('
-- --------------------
V1
V2
V3 Updated
V4

tst> connect u1/u1@tst
Connected.
tst> select 'V1', substr(sys_context('GCTX', 'V1'), 1, 20) from dual union all
  2  select 'V2', substr(sys_context('GCTX', 'V2'), 1, 20) from dual union all
  3  select 'V3', substr(sys_context('GCTX', 'V3'), 1, 20) from dual union all
  4  select 'V4', substr(sys_context('GCTX', 'V4'), 1, 20) from dual;

'V SUBSTR(SYS_CONTEXT('
-- --------------------
V1  /* не назначен CL_IDENTIFIER */
V2 User with NULL Id  /* старое все осталось */
V3
V4 Any User with NULL I

tst> exec dbms_session.set_identifier('Id1');

PL/SQL procedure successfully completed.

tst> select 'V1', substr(sys_context('GCTX', 'V1'), 1, 20) from dual union all
  2  select 'V2', substr(sys_context('GCTX', 'V2'), 1, 20) from dual union all
  3  select 'V3', substr(sys_context('GCTX', 'V3'), 1, 20) from dual union all
  4  select 'V4', substr(sys_context('GCTX', 'V4'), 1, 20) from dual;

'V SUBSTR(SYS_CONTEXT('
-- --------------------
V1  /* !!! назначив такой же аттрибут другому USER с одинаковым CL_IDENTIFIER, мы затерли значения у всех остальных этой группы !!! */
V2
V3
V4

tst> exec dbms_session.set_identifier('Id2');

PL/SQL procedure successfully completed.

tst> select 'V1', substr(sys_context('GCTX', 'V1'), 1, 20) from dual union all
  2  select 'V2', substr(sys_context('GCTX', 'V2'), 1, 20) from dual union all
  3  select 'V3', substr(sys_context('GCTX', 'V3'), 1, 20) from dual union all
  4  select 'V4', substr(sys_context('GCTX', 'V4'), 1, 20) from dual;

'V SUBSTR(SYS_CONTEXT('
-- --------------------
V1
V2
V3 Updated
V4
21 фев 08, 05:29    [5319553] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
ASNexus
Member

Откуда: Tula
Сообщений: 92
Вячеслав Любомудров
Я когда-то рисовал статью по этому поводу для наших программеров


Еще раз огромное спасибо! За статью, да еще на русском языке, содержащую ответы на все мои вопросы и, к тому-же, с подробными примерами использования и возможных граблей - просто нет слов для выражения благодарности!!!

P.S. Удивил такой момент - в документации (Oracle 9.2) CREATE OR REPLACE CONTEXT namespace USING schema.package ... и далее все упоминания только о пакете, но нигде не сказано, что это может быть процедура (хотя, попробовал примеры на 9.2.0.8 - действительно с процедурой все работает)...
21 фев 08, 17:30    [5324472] Ответить | Цитировать    Сообщить модератору

 Re: Межпроцессная коммуникация - совет нужен   [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 11564
ASNexus
Еще раз огромное спасибо! За статью, да еще на русском языке, содержащую ответы на все мои вопросы и, к тому-же, с подробными примерами использования и возможных граблей - просто нет слов для выражения благодарности!!!
По большому счету, незачто
Она была выложена на внутриконторский форум более 3-х лет назад, и, когда я ее вчера перечитал, мне показалось, что там гон сплошной (не прижилась у нас эта тема, поэтому и забылось все). Захотелось перепроверить, заодно и освежить в памяти
ASNexus
P.S. Удивил такой момент - в документации (Oracle 9.2) CREATE OR REPLACE CONTEXT namespace USING schema.package ... и далее все упоминания только о пакете, но нигде не сказано, что это может быть процедура (хотя, попробовал примеры на 9.2.0.8 - действительно с процедурой все работает)...
Скорее всего, это связано с тем, что на момент создания контекста доверенного пакета может не существовать, поэтому здесь ошибку не выдашь. А когда ее выдавать? На момент создания процедуры с таким именем? В момент выполнения?
И еще, по большому счету, одной процедуры мало -- необходимо еще как минимум вызывать dbms_session.clear_context, которая тоже вызывается из доверенного пакета
И, в конце концов, доверенный пакет/процедура сделаны именно для того, чтоб рулить доступом на изменение значений контекста. Что пакет, что процедура этому удовлетворяют
22 фев 08, 02:56    [5325964] Ответить | Цитировать    Сообщить модератору

Все форумы / Oracle Ответить
Generated time: 140ms.
Rambler's Top100 Powered by ActualForum 1.5.3 [s1] Copyright (c) Alex Sibilev 2000-2010