Потеря сообщений была не критична и была такая система:
1. прикладное ПО вызывало PLOG, который писал в buffered AQ (PLOG был допилен для этого)
2. было несколько процессов, читающих AQ, и вызывающих rsyslog через UTL_TCP (кол-во процессов регулировалось настройкой в прикладной таблице)
3. дальше был logstash, ElasticSearch, Kibana (ELK), куда шли логи и с серверов приложений, что в одном месте можно было видеть клиентские запросы end-to-end. Java-программисты были обучены использовать Execution Context ID (ECID), который присутствовал во всех логах, а также v$session.ecid, v$active_session_history.ecid, что на любой вопрос, почему такая-то операция работала дольше обычного, поддержка могла по логам определять проблемное место (DB/AppServer). А дальше уже команда, отвечающая за конкретный компонент по ECID могла смотреть детально, в чем причина медленной работы.
4. вызов PLOG также добавлял в сообщение мета-атрибуты (некоторые из sys_context('USERENV') и ECID))

Не успел реализовать:
1. покрытие клиентского уровня (JavaScript) и генерации ECID на клиенте с последующей отправкой данных в микро-сервис логирования и пробросом ECID по всем остальным уровням стэка.
2. поддержка ECID в фоновых заданиях DBMS_SCHEDULER через соответствующий context:


3. Автоматическое сохранение данных ASH по ECID, работавших более определенного времени, определенного владельцем сервиса, в отдельную БД (Performance Data Warehouse, которая являлась и AWR Warehouse ).
4. Автоматическая классификация сохраненных "долгих" ECID и известных проблем (ASH имеет SQL_ID. Все запросы по оптимизации в Jira тоже имели SQL_ID => Можно автоматически привязывать ECID/Jira Issue, чтобы оставлять для ручного разбора только новые проблемы)

Были какие-то костыли на случай на случай того, что AQ не будет успевать разбираться в виде либо отключения логирования автоматически, либо переключения на non-buffered запись.
В непромышленных средах разработчик мог указать параметром в прикладной таблице, чтобы использовалась запись логов в таблицу PLOG для удобства отладки.

buffered AQ использовались по двум причинам:
1. производительность
2. минимизация нагрузки на БД, создаваемой подсистемой логирования