Oracle diagnostic events - это очень мощное средство, но, к сожалению, слабо документированное, поэтому я решил перечислить и свести воедино несколько неизвестных или малоизвестных способов его использования. Единственная его документация - это очень краткая встроенная документация, доступная по команде oradebug doc в SQL*Plus, и она отсутствует в официальной документации. Вы можете встретить только отрывки из нее в разных блогах, что не очень удобно, поэтому я скомпилировал ее полностью: http://orasql.org/files/events/  Современный синтаксис и несколько простых примеров приведены в oradebug doc event. Я их здесь приводить не буду и начну сразу с примеров. kg_event[errno] - это Kernel Generic event из библиотеки Generic, инструктирующее сработать на ошибку с номером errno; {occurence: start_after X, end_after Y} - это один из фильтров , инструктирующий пропустить X срабатываний данного event и выполниться Y раз; trace(format, str1, str2, ..., str15) - это функция из ACTIONS для вывода в трейс-файл своих сообщений; shortstack() - это функция из ACTIONS , возвращающая call stack в кратком виде; errorstack(level) - это функция из ACTIONS, выводящая в трейс-файл расширенную информацию (level: 0 - только errorstack, 1 - errorstack + call stack, 2 - как level=1 + processtate, 3 - как level=2 + context area). Еще более расширенную информацию можно получить с помощью PROCESSSTATE или SYSTEMSTATE. Если нужен только call stack можно воспользоваться CALLSTACK(level) - при level>1 запишет и аргументы. trace[component] - это основной диагностический event, позволяющий указать компоненты, внутри которых надо срабатывать. В данном случае, я указал срабатывать внутри всех дочерних функций в SQL_Compiler и SQL_Execution. Например, RDBMS.SQL_Compiler.SQL_Optimizer.SQL_Transform.* указало бы срабатывать только в функциях трансформации запросов. SQL[SQL: sqlid ] - это единственный SCOPE в библиотеке RDBMS, позволяющий отфильтровать все события, связанные с указанными запросами, включая события его рекурсивных запросов(например, если это sql_id PL/SQL вызова, то будут оттрассированы все запросы внутри него, или для запроса - все его внутренние запросы во время парсинга и оптимизации, внутренних запросов PL/SQL функций и тд.); {process: ...} - это фильтр, позволяющий указать процессы для которых данный event будет включен. controlc_signal - это ACTION, вызывающий ошибку "ORA-01013: user requested cancel of current operation", т.е. сессия запустившая этот запрос получит эту ошибку, как будто она сама прервала выполнение запроса. Конкретно, данным примером я воспользовался, когда в ходе нагрузочного тестирования большого веб-приложения на hibernate, были обнаружены очень плохие фактически ненужные запросы и нужно было помочь разработчикам быстро найти откуда в их коде они выполняются.  sql_trace - это старый добрый event 10046, а целиком команда предписывает при каждом событии инструментированным этим event 10046, вывести функцию, его вызвавшую(evfunc) и sqlid запроса (ACTION sqlid). Пример: Как видите, при "_rowsource_statistics_sampfreq" =1 инструментировано намного больше событий: 26 против 12! Подробнее тут. wait_event[name] - event, срабатывающий по имени событий ожидания (wait events), имена и их параметры вы можете посмотреть в v$event_name:select wait_class,name,parameter1,parameter2,parameter3 ,display_name from v$event_name {wait: ... } - фильтр позволяющий отфильтровать как по долготе ожидания(в мс), так и по параметрам P1, P2, P3. Например, для указанного  ожидания "TM-contention", P2 - это object #, и можно указать {wait: minwait=1000; p2=12345}, т.е. только ожидания табличной блокировки на таблице с object_id=12345 и длившиеся дольше 1 сек. evargX() - это функции из ACTION, возвращающие аргументы event-check события, где 1-й аргумент это elapsed time(ms), 2-4 - p1-p3, 5-й - имя ожидания. Соответствующие функции имеет и kg_event: errargX. Или еще пример, когда вам надо узнать какие сессионные переменные были изменены. Допустим, кто-то забыл указать nls-параметры в to_number, on conversion error не указан, и какие-то сессии периодически получают ORA-01722: invalid number: Хотя нет никакой вьюхи для получения параметров чужой сессии, не входящих в v$ses_optimizer_env, мы можем легко их получить с помощью  MODIFIED_PARAMETERS(): И благодаря тому, что сейчас есть удобные v$diag_alert_ext - для доступа к alert.log, v$diag_trace_file_contents - для доступа к трейс-файлам, мы можем все получить простым запросом: Update: В телеграм канале RuOUG спросили:В качестве примера, у нас используется код расширения статистики оптимизатора, периодически падающий с ошибкой ORA-06550 PL/SQL compile error, т.е. этот код вызывает сам оптимизатор Oracle. 
Возможно ли в  Oracle diagnostic events одновременно задать kg_event и sql_id, чтобы в alert.log появились  ошибки ORA-06550 и имена соответствующих trace файлов, например так: 
alter system set events 'kg_event[6550]
       {occurence: start_after 1, end_after 3}
        [sql: 7ujay4u33g337]
         errorstack(3)
      '; И я вспомнил, что хотел описать и еще один крайне полезный ACTION - incident(). Пример: kg_event[6550] - трассировать ошибки "ORA-06550: line %, column %" и incident(plserrors) - создать инцидент-файл (при необходимости его можно легко упаковать через adrci и отправить для разбора консультантам или в Oracle Support) PS. Дополнительные детали вы можете узнать в статьях Tanel Poder:1. The full power of Oracle’s diagnostic events, part 1: Syntax for KSD debug event handling2. The full power of Oracle’s diagnostic events, part 2: ORADEBUG DOC and 11g improvements3. What Caused This Wait Event: Using Oracle's wait_event[] tracing4. http://tech.e2sn.com/oracle/troubleshooting/oradebug-doc О внутренних функциях у Frits Hoogland: http://orafun.info/ Полная внутренняя документация по oradebug/diagnostic events: http://orasql.org/files/events Oracle ACE, performance tuning and troubleshooting