Вердикт наших DBA после общения с саппортом вот такой:
orphaned pipes - это именно те, которые остаются из под сессий, выполняемый код в которых не удосужился или не получил возможности сделать DBMS_ALERT.REMOVE или DBMS_ALERT.REMOVEALL после использования DBMS_ALERT. cleanup => true - костыль от неаккуратного кода.
Логику приложения cleanup => false не нарушит, сигналы по алертам-сиротам просто проигнорируются, риск только в затрате ресурсов на эти отправки сигналов, возможно несколько вырастет общее потребление CPU со стороны приложения.
Бесхозные алерты со временем удалятся фоновыми процессами СУБД, их бесконтрольное накопление можно мониторить например запросом SELECT count(SID) FROM DBMS_ALERT_INFO, для поиска именно бесхозных можно сопоставлять строки DBMS_ALERT_INFO.sid текущим SID SERIAL# из v$session.
т.е. все последствия отражены вот тут:
1.
2.
DBMS_ALERT.REMOVE
Removing alerts is important because it reduces the amount of work done by signalers of the alert.
If a session dies without removing the alert, that alert is eventually (but not immediately) cleaned up.
Соответственно можно смело применить изменение cleanup => false для проблемного DBMS_ALERT.REGISTER при условии контроля за накоплением алертов в DBMS_ALERT_INFO и связанным с ним потреблением CPU. Если что пойдет не так - вашему SR всегда будут рады :)
остались открытыми вопросы:
1. Почему в документации Oracle, вместо что бы явно написать про удаление-неудаление алертов завершенных сессий, зачем-то пространно написано про «cleanup of any extant orphaned pipes used by the DBMS_ALERT package»,
2. Зачем «проверочный» запрос на cleanup=>true помимо SELECT DISTINCT SID FROM DBMS_ALERT_INFO делает дополнительно фуллскан по всему shared pool.
так что запрос
1.
SELECT DISTINCT SUBSTR(KGLNAOBJ,11) SID FROM X$KGLOB WHERE KGLHDNSP = 7 AND KGLNAOBJ LIKE 'ORA$ALERT$%' AND BITAND(KGLHDFLG,128)!=0
тоже возможно имеет смысл в качестве мониторинга последствий cleanup => false.
У меня главной проблемой являлся запрос по X$KGLOB, критично увеличивающий время DBMS_ALERT.REGISTER, тоже потребляющий ресурсы. Этот запрос при cleanup => false ушел, проблему это решило, без последствий или особенностей. Мониторили начнут ли копиться пайпы. Этого не произошло – т.е. приложение аккуратно за собой прибирает или фоновые процессы СУБД это успевают сделать. Специальный мониторинг по порогам и с оповещениями не понадобился, в моем случае все хорошо.
