В тему глюков CQN, т.к. инфы по этой теме маловато.


На development server-е развалил давно отлаженный и работающий захват уведомлений CQN.

Предполагаемые причины :
* проверял на примере dbms_photoshop-а 18413360 как DBMS_PARALLEL_EXECUTE реагирует на многократные ошибки при формировании заданий, например, если их вносить в l_chunk_sql и/или в l_sql . DBMS_PARALLEL_EXECUTE, с внесенными ошибками, запускался DBMS_SCHEDULER Job-ом.
* нагрузочный тест с DBMS_PARALLEL_EXECUTE без лимита ресурсов. EM зафиксировал ORA 700 [kskvmstatact: excessive swapping observed] и ORA-00700

Последствия были примерно следующие :
1. странное поведение копируемых и вновь создаваемых Job-ов -- они создавались, запускались и прекращали работу ничего не делая. Через несколько часов вылечилось само. А может и не вылечилось....
2. PL\SQL CQN handler перестал получать уведомления об изменении данных. Совсем. Подписки создаются, запросы регистрируются, данные меняются, handler ничего не получает. Само не вылечилось...

Лечение (пока не вылечили)
Доступа в MOS уже 2 года нет, соответственно, лечим, как (не)понимаем. Это не рекомендации!
1. рестарт инстанса -- не помогло
2. лечение "регистраций - неубиваемых призраков". Взято когда-то из Metalink-а:
The notifications can only be removed automatically by the database software itself once the notifications timeout. There is no way to remove notifications directly. They cannot be removed by another application or another session of the same application; lifting this restriction has been considered, but this would mean one application could delete another application's active notifications, which is not desirable.

If the notifications are building up due to repeated application crashes then they can be removed indirectly by revoking the change notification privilege from the user (database schema) to which the notifications belong, or by dropping the user from the database. Either of these operations will remove any change notifications owned by that user.

...Удаление регистраций возможно только после включения дебага:

event "10865 trace name context forever, level 1".

Выполнили от system:


Потом DROP и CREATE cqn_handler.

Результат : движок CQN ожил, handler стал получать уведомления...НО с кривыми REGISTRATION_ID!
При регистрации запросов (как в примере) DBMS_CQ_NOTIFICATION.new_reg_start(reginfo) возвращает очередной REGISTRATION_ID, он запоминается в таблице приложения.

Инфа в dba_cq_notification_queries соответствует регистрации



А вот cqn_handler получает:
** в ntfnds.registration_id числа с отставанием от зарегистрированных на первом шаге
** в ntfnds.query_desc_array(i).queryid данные корректные, соответствуют регистрации

Если у кого-то был такой "перекос", подскажите, как его ликвидировать

Vladimir Filin... соответственно, лечим, как (не)понимаем.

После рестарта инстанса проблема пять вернулась в исходное состояние: handler не вызывается.



показывают, что подписки есть, запросы зарегистрированы, всё выглядит замечательно!....но, не работает.