Oracle events что это

Обновлено: 06.07.2024

Высокая производительность Web-приложений зависит от эффективных баз данных, которые могут быстро обрабатывать запросы и извлекать их результаты. В статье описан анализ событий ожидания в Oracle для повышения производительности. В ней также демонстрируется использование системных утилит для эффективного сбора и анализа статистики производительности базы данных Oracle с целью определения проблем.

Мониторинг производительности базы данных и анализ событий ожидания

Чтобы повысить производительность СУБД Oracle, необходимо проанализировать события ожидания Oracle, чтобы определить узкие места и настроить параметры базы данных. Повышение эффективности обработки в базе данных Oracle повышает производительность всех систем и приложений, использующих эту базу данных. В статье демонстрируется использование системных утилит для эффективного сбора и анализа статистики производительности базы данных Oracle с целью определения проблем.

На производительность базы данных Oracle влияет множество факторов. В частности, существенное влияние на производительность оказывают факторы, перечисленные ниже.

Неэффективные SQL-операторы негативно влияют на производительность

При создании SQL-операторов имейте в виду, что они могут существенно повлиять на производительность запросов. Чем конкретнее оператор, тем быстрее будет получен результат. Предположим, нужно просмотреть информацию о конкретном сотруднике employee1 с идентификатором employee_id , равным 123 , из таблицы employee. Таблица employee содержит столбцы employee_name , employee_sal и employee_id , где employee_id является первичным ключом. Рассмотрим следующие варианты в порядке повышения эффективности:

С помощью запроса select * from employee , извлекаем все записи из таблицы. Находим в результатах конкретного работника. Если результат запроса содержит много записей, этот процесс будет медленным.
Используем запрос select * from employee where employee_name='employee1' . Этот оператор сужает поиск и ускоряет процесс.
Используем запрос select * from employee where employee_id=123 . Поскольку employee_id является первичным ключом, этот запрос будет самым быстрым

Чтобы создать наиболее эффективный SQL-оператор, используйте следующие рекомендации:

Избегайте запросов, которые не содержат условий where и первичных ключей.
Большое количество запросов delete со временем приводит к росту несвязных блоков данных. Оператор delete только удаляет данные из блока, но не освобождает блок данных для дальнейшего использования. Поскольку операторы delete не снижают верхнюю границу заполнения, общий объем данных, в которых будут выполнять поиск будущие запросы, не уменьшается. Используйте оператор truncate, где это возможно, поскольку он сбрасывает верхнюю границу заполнения.
Используйте операторы COMMIT только в случае необходимости. Избегайте их частого использования, поскольку они инициируют очистку буфера, что может привести к чрезмерному количеству операций ввода/вывода.

Неэффективная конфигурация базы данных негативно влияет на производительность

Неумелое конфигурирование негативно влияет на производительность базы данных. Конкретные параметры инициализации и конфигурации базы данных влияют не только на конфигурацию запуска, но и на обработку запросов. На производительность могут повлиять в сторону ухудшения приведенные ниже параметры (если они не настроены оптимальным образом).

Параметр PCTFREE

Параметр PCTFREE устанавливает минимальный процент резервирования свободного пространства блока для возможных обновлений строк, уже существующих в этом блоке. Слишком низкое значение PCTFREE может вызвать проблемы при обновлении. Слишком высокое значение может привести к неэкономному использованию пространства и вызвать избыточное перемещение блоков данных.

Параметр PCTUSED

Параметр PCTUSED устанавливает минимальный процент использования блока для данных в строках и накладных расходов на добавление в блок новых строк. После заполнения блока данными до предела, определенного параметром PCTFREE , Oracle считает блок недоступным для вставки новых строк, пока процент не опустится ниже значения параметра PCTUSED . До достижения этого порога Oracle использует свободное пространство блока данных только для обновления строк, уже содержащихся в блоке.

Неадекватное выделение памяти System Global Area (SGA) негативно влияет на производительность

Системная глобальная область (System Global Area - SGA) представляет собой группу общих структур памяти, содержащих данные и управляющую информацию для одного экземпляра базы данных Oracle. Пользователи, одновременно подключившиеся к одному и тому же экземпляру, совместно используют данные в SGA экземпляра. Поэтому SGA иногда называют общей глобальной областью. Для обеспечения эффективной производительности базы данных необходимо определить оптимальный размер памяти SGA и настроить ее соответствующим образом. Слишком маленькая память может существенно снизить производительность базы данных.

События ожидания негативно влияют на производительность

Oracle Database 11g имеет более 1000 событий ожидания, которые могут привести к задержкам обработки запроса. Эти события ожидания принято делить на следующие группы:

Cluster (кластер)
Network (сеть)
Administration (администрирование)
Configuration (конфигурация)
Commit (фиксация)
Application (приложение)
Concurrency (параллелизм)
System I/O (системный ввод/вывод)
User I/O (пользовательский ввод/вывод)
CPU (процессор)

Использование Oracle Enterprise Manager для анализа событий ожидания

Для мониторинга событий ожидания при обработке данных используется Oracle Enterprise Manager (OEM). OEM графически отображает состояние базы данных во время обработки. Он также предоставляет подробный аналитический отчет, в котором можно перейти к каждому событию и найти соответствующие SQL-операторы (см. рисунок 1). В легенде справа показаны типы событий ожидания.

Рисунок 1. Пример снимка экрана Oracle Enterprise Manager

На рисунке 2 показано детальное представление ожидания типа User I/O для данных, использованных в рисунке 1. Нажмите User I/O в OEM, чтобы перейти на страницу сведений о событиях ожидания типа User I/O.

Рисунок 2. Ожидание активных сеансов

Анализ событий ожидания с помощью shell-сценария

Можно собрать статистику событий ожидания базы данных Oracle без использования инструментальных средств, воспользовавшись shell-сценарием и встроенными системными утилитами. Чтобы собрать и проанализировать статистику для выявления источника узких мест и исправления проблем при поддержке администратора базы данных, необходимо выполнить приведенные ниже шаги.

Подготовка данных

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

Шаг 1. Создание сценария

Чтобы получить подробную информацию и SQL-операторы для событий ожидания в представлениях V$ACTIVE_SESSION_HISTORY , V$EVENT_NAME и V$ SQLAREA , создайте простое соединение трех таблиц.

V$ACTIVE_SESSION_HISTORY Отображает активность сеансов в базе данных. В нем содержатся ежесекундные снимки активного сеанса базы данных.
V$EVENT_NAME Отображает информацию о событиях ожидания.
V$SQLAREA Отображает статистику для общей SQL-области, содержит одну строку для каждого SQL-выражения. Предоставляет статистику по SQL-операторам, которые находятся в памяти, проанализированы и готовы к выполнению.

Поскольку данные в этих представлениях периодически очищаются, используйте сценарий, приведенный в листинге 1, для сбора данных через одинаковые промежутки времени.

Листинг 1. Сценарий gather_event_stats.sh для периодического сбора данных

echo "SET MARKUP HTML OFF;">>sql 2>/dev/null

" в качестве разделителя столбцов
echo "SET CLOSEP '

Чтобы данные, собранные в текстовый файл, можно было представить с помощью электронных таблиц (например, Microsoft Excel) и в дальнейшем проанализировать, в качестве разделителя столбцов используется символ тильды (

). Этот сценарий создает SQL-файл через одинаковые промежутки времени, выполняет SQL-выражения для сбора данных и помещает статистику в текстовый файл

Шаг 2. Запуск сценария

Разместите сценарий на любом сервере приложений и выполните сценарий для сбора данных. В приведенном ниже коде перед вызовом сценария замените переменные ORADBNAME, ORACLEID, PASSWORD соответствующими значениями.

sqlplus ORACLEID/PASSWORD@ORADBNAME < sql >> $outfile_name 2>/dev/null

Примечание . Эти значения можно сделать параметрами и передать в сценарий во время выполнения.

Для выполнения сценария используйте следующий синтаксис:

gather_event_stats.sh <No.of.Iterations> <Time Interval in m(in)/h(ours)/d(ays)> gather_event_stats.sh 5 2h ---> would run for 10 hrs (5times*for every 2hours = 10Hrs)

Запустите сценарий до загрузки данных и не останавливайте его, пока загрузка данных не завершится. При выполнении сценария тщательно подберите значения No.Of.Iterations ($1) и Interval ($2) для выражения No.Of.Iterations x Intervals = Test Duration (Число итераций х интервалы = продолжительность теста).

Чтобы убедиться, что сценарий запущен, выполните следующую команду:

Шаг 3. Обработка данных

Введите данные и убедитесь, что приложение обрабатывает данные. Проверьте еще раз, что данные загружаются в базу данных. Подождите, пока не будут обработаны все данные. Выведите файл $outfile_name (имя файла, в который помещаются выходные данные запроса; в нашем случае - статистика событий ожидания) через одинаковые промежутки времени и убедитесь, что размер файла растет.

Шаг 4. Анализа данных и настройка базы данных

После завершения обработки данных и выполнения сценария gather_event_stats.sh загрузите выходной файл $outfile_name из машины Unix в машину Windows.
Откройте файл в текстовом редакторе. Если в этом файле есть символы табуляции или дополнительные пробелы, замените их одним пробелом, прежде чем загрузить файл в электронную таблицу Excel. На рисунке 3 показано, как выглядят загруженные данные в редакторе Notepad.

Рисунок 3. Снимок экрана с исходными данными в текстовом файле

Импортируйте данные в электронную таблицу Excel, выбрав Data > Convert Text to Columns . Укажите символ тильды (

Рисунок 4. Снимок экрана с данными событий ожидания после разделения в Excel с помощью разделителя

Проанализируйте событие ожидания с помощью администратора базы данных Oracle, чтобы понять причину этого события. В нашем примере событием с наибольшим временем ожидания является TX - index contention . Это говорит о наличии проблемы индексирования при обработке транзакций.
Получите SQLID для операторов wait с наибольшим временем ожидания и проверьте соответствующие SQL-операторы. В поле C.SQL_TEXT указывается SQL-оператор для каждого SQLID . Обратитесь к разработчикам и администратору базы данных, чтобы определить возможность настройки SQL-операторов для сокращения времени ожидания.
Повторите пункт 6 для каждого из 10 событий с наибольшим временем ожидания.
Реализуйте решения, предложенные разработчиками и администратором базы данных, для устранения этих событий ожидания.
Снова выполните этот тест с той же нагрузкой и с той же продолжительностью, чтобы убедиться в уменьшении времени ожидания или полном устранении события ожидания.

Заключение

В этой статье описывается один из способов сбора статистики о событиях ожидания для базы данных Oracle. Процесс очень прост и не требует никаких специальных инструментов. Этот метод применим для анализа и решения проблем производительности базы данных для продуктов IBM, интегрированных с серверными базами данных Oracle.

Oracle diagnostic events - это очень мощное средство, но, к сожалению, слабо документированное, поэтому я решил перечислить и свести воедино несколько неизвестных или малоизвестных способов его использования.

Современный синтаксис и несколько простых примеров приведены в oradebug doc event. Я их здесь приводить не буду и начну сразу с примеров.

kg_event[errno] - это Kernel Generic event из библиотеки Generic, инструктирующее сработать на ошибку с номером errno;

- это один из фильтров , инструктирующий пропустить X срабатываний данного event и выполниться Y раз;

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 функций и тд.);

- это фильтр, позволяющий указать процессы для которых данный event будет включен.

controlc_signal - это ACTION, вызывающий ошибку "ORA-01013: user requested cancel of current operation", т.е. сессия запустившая этот запрос получит эту ошибку, как будто она сама прервала выполнение запроса.

Конкретно, данным примером я воспользовался, когда в ходе нагрузочного тестирования большого веб-приложения на hibernate, были обнаружены очень плохие фактически ненужные запросы и нужно было помочь разработчикам быстро найти откуда в их коде они выполняются.

sql_trace - это старый добрый event 10046, а целиком команда предписывает при каждом событии инструментированным этим event 10046, вывести функцию, его вызвавшую(evfunc) и sqlid запроса (ACTION sqlid).

включаем event сначала выполняем запрос с настройками по умолчанию, а затем с _rowsource_statistics_sampfreq=1 Разница в трейсе заметна

Как видите, при "_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

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] [sql: 7ujay4u33g337] errorstack(3) ';

И я вспомнил, что хотел описать и еще один крайне полезный ACTION - incident(). Пример:

сгенерируем ошибку включим трейс и увидим, что инцидент-файл сформировался

По Вашему запросу ничего не найдено.

Рекомендуем сделать следующее:

Проверьте правильность написания ключевых слов.
Используйте синонимы введенных Вами ключевых слов, например “приложение” вместо “программное обеспечение”.
Попробуйте воспользоваться одним из популярных поисковых запросов ниже.
Начните новый поиск.

Сервис Oracle Events Service стал общедоступным

Отслеживайте изменения в своих облачных ресурсах и реагируйте на них, используя сервисы Functions, Notifications и Streaming.

Полное управление

Oracle Events Service упрощает задачу отслеживания изменений по всем облачным ресурсам и позволяет реагировать на них практически в реальном времени, используя сервисы функций, уведомлений и потоковой передачи.

Полная интеграция

Oracle Events Service интегрируется со всеми сервисами Oracle Cloud Infrastructure, и Вы можете отслеживать события из всех своих облачных ресурсов.

Открытие

Oracle Events Service соответствует спецификации CloudEvents организации Cloud Native Computing Foundation (CNCF) для полной совместимости с облачной экосистемой.

Механизм доставки Oracle Events

Возможности продукта

Интеллектуальная доставка в требуемом масштабе

Встроенные средства безопасности

Интеграция с Oracle Identity and Access Management (IAM) позволяет детально определять права пользователей для создания правил и управления ими.

Бесплатно

Плата за использование Oracle Events Service не взимается; Вы платите только за используемые Вами сервисы, которые публикуют события в Events Service или получают события из Events Service.

Oracle Data Integration, Cloud, Spatial and Analytics (GoldenGate, ODI, Cloud, Spatial, Exadata)

Простое событие (simple event) определяется как информация о состоянии, сопровождаемое временем и местоположением наблюдения этого состояния. Среди тысяч поступающих событий, система мониторинга может наблюдать, например, следующие:

Марш Мендельсона
Появление мужчины в смокинге вместе с женщиной в белом платье
Рис, бросаемый в воздух

Получив все эти события одновременно, система мониторинга может сделать вывод о возникновении сложного события Cвадьба.

CEP основывает на целом ряде технологий, включая:

обнаружение закономерностей в событиях (event-pattern detection)
абстрагирование событий (event abstraction)
моделирование иерархий событий (modeling event hierarchies)
обнаружение взаимосвязей (причинность, время возникновения) между событиями (detecting relationships between events)
абстрагирование процессов, управляемых событиями (abstracting event-driven processes)

Смежные области.

Исторически сложилось, что CEP часто используется в Business Process Management (BPM) и связанных областях.

В искусственном интеллекте выведенная информация обычно выводится системами построения выводов (например, основанных на правилах). Однако, новая информация обычно также не формируется в виде сложных событий.

История Oracle Complex Event Processing (CEP)

1992: Database Triggers in Oracle7

2002: Streams Introduce Information Management in Oracle9i

В Oracle9i Database Release 2 появилась технология Oracle Streams, которая позволила переносить данные, транзакции и события в специальных потоках из одной базы данных в другую. Oracle Streams обеспечили набор компонент, позволяющих пользователю управлять тем, какие данные попадают в поток, как этот поток перетекает и маршрутизируется от одного узла к другому, что происходит с события, когда поток приносит их в узел и где этот поток прерывается.

Oracle EDA Suite совместил в одном решении:

2007: Enabling Event Processing Applications with the Oracle Complex Event Processor

К таким возможностям можно отнести:

Высокая пропускная способность
Корреляция (Event Correlation) и обнаружение событий
Выявление закономерностей.

Список событий, установленных для текущей сессии:

Трейс выполнения запроса / SQL trace/ 10046 event

Включить/выключить стандартные трейс в текущей сессии

или с указанием уровня трейса

Включить/выключить трейс в любой сессии, используя пакет DBMS_SUPPORT:

То же с использованием утилиты ORADEBUG:

или по ospid

включить / проверить состояние / выключить трейс:

Включить/выключить трейс на уровне системы:

или с использованием параметра системы:

Выключить все события для всех инстансов бд:

с Oracle 10.2 можно определить наличие и уровень SQL_TRACE для сессии по значениям SQL_TRACE, SQL_TRACE_WAITS, SQL_TRACE_BINDS в V$SESSION

с Oracle 10g можно включить SQL трейс на уровне SERVICE [ MODULE [ ACTION ] ], устанавливаемых пакетом DBMS_APPLICATION_INFO, с помощью DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE или по CLIENT_ID с помощью DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE:

Интерпретация результатов трейса 10046:

На примере трассировке с уровнем 12 (LEVEL 12 = binds + waits) операции вставки массива строк (array insert, реализуемый с использованием FORALL кляузы в PL/SQL или host arrays) Oracle сразу после записи о разборе (PARSING IN CURSOR) запишет в файл только первый набор значений связанных переменных (первый элемент вставляемого массива строк):

и, собственно, выполнение курсора:

trcsess

штатная утилита консолидации нескольких трейс-файлов, например, при параллельном выполнении, на основе:

В консолидированном файле записи сгруппированы по курсорам, но могут нарушать хронологический порядок

tkprof

32951.1 Tkprof Interpretation: стандартно поставляемая с Oracle утилита tkprof для обработки и анализа содержимого трейс файлов

Из обработанного tkprof трейса:

Обработанный трейс Array insert из предыдущего примера выглядит так:

По крайней мере, начиная с версии 11g, tkprof пишет статистику плана выполнения (row source statistics):

TRCANLZR

Использование DBMS_SQLTUNE.SELECT_SQL_TRACE

events sql_trace

например для конкретного SQL_ID на уровне системы:

Трейс вызовов Oracle kernel functions на уровне ОС/Linux

10053 event / 10132 event

Timing is only written out to trace if CPU or Elapsed time exceed a threshold based on the value of the fix control.
This threshold is 10^N microseconds where N is the value of the fix control and can be between 0 and 7 with default 6.
Value 0 means disabled. The min (1) is 10 microseconds, the default (6) is 1 sec and the max (7) is 10 sec.

Optimizer Trace

, формат версии 12c:

Начиная с Oracle 11.2 можно получить трейс оптимизатора для запроса, находящегося в shared pool (v$sql), без повторного выполнения запроса:

При выполнениии процедуры dbms_sqldiag.dump_trace для формирования трейса будет выполнен повторный разбор запроса, в текст которого добавляется соответствующий комментарий:

та же проблема в 11.2.0.*

SQL Plan Directive (SPD) trace

, или на уровне системы, например, для конкретного SQL_ID:

SQL PLAN MANAGEMENT trace

или на уровне сессии:

cursortrace event

drop_segments event

10949 event

trace name treedump

Выводит внутреннюю структуру индекса по id объекта

10231 event

event 43905

heapdump / memory heaps dump

Level	Description
1	PGA summary
2	SGA summary
4	UGA summary
8	Callheap (Current)
16	Callheap (User)
32	Large pool
64	Streams pool
128	Java pool
1025	PGA with contents
2050	SGA with contents
4100	UGA with contents
8200	Callheap with contents (Current)
16400	Callheap with contents (User)
32800	Large pool with contents
65600	Streams pool with contents
131200	Java pool with contents

heapdump_addr

library_cache_object

library_cache dump

_px_trace

Трейс паралельного выполнения, как запускать и что и как нужно читать описано в Tracing Parallel Execution with _px_trace. Part I [ID 444164.1]:

high
medium
low

events 10384

dbms_space_admin.segment_dump(&tablespace_name, &relative_fno, &header_block)

дамп блоков заголовка сегмента и bitmap-карты в USER_DUMP_DEST

dump of datafile block[s]

по номерам файлов бд, и по диапазонам блоков:

dump of datafile headers

dump of logfile

header или содержимое redo log

dump of controlfile

events 1652

может быть полезно для трассировки условий возникновения ORA-1652: unable to extend temp segment by 16 in tablespace TEMP

events 10704

events 10104

детали выполнения операций HASH JOIN

уровни 1-10, к более подробному

events 10730

трассировка предикатов, добавляемых политиками VPD | RLS | FGAC, в Tracing VPD Predicates описан для диагностики ошибок типа ORA-28113: policy predicate has error

10513 event

обязательное последующее включение:

ORADEBUG утилита

_swrf_test_action

трассировка процессов MMON:

и snapshot flush trace (M00x процессов):

ashdump

запись данных Active Session History системы (v$active_session_history) в файл

10 => кол-во минут истории для дампа

event 16000
event 604

Для поиска причин ORA-16000 ORA-604 на Read Only Standby / Active Data Guard db:

event 10442

CURSORTRACE event
CURSORDUMP event

Трассировка информации о причинах повторного неиспользования курсоров

10237 event

Тестовое событие, позволяет прервать выполнение запроса в другой сессии

10157 event

событие, позволяющее блокировать использование операции INLIST ITERATOR с индексным доступом; в документах MOS рекомендуется устанавливать на уровне системы, ввиду нестабильности, см., например, Конкатенация против INLIST ITERATOR

10119 event

событие отключения NOSORT опции для операции SORT GROUP BY:

пример использования на стандартной схеме SCOTT:

Alexander Anokhin. Dynamic tracing of Oracle logical I/O

10128 event

Трассировка Partition Pruning, впрочем, достаточно бесполезная

10507 event

10505 event

10979 event

Трассировка PL/SQL

28131 event

trace[nsmtio]

кроме того, полезная диагностика причин неприменения direct path read для NON-EXADATA систем:
Frits Hoogland. The full table scan direct path read decision for version 12.2

modified_parameters

Как найти название трейс файла процесса Oracle?

Для собственной сессии:

Читайте также: