Как читать трейс файл oracle
Обновлено: 27.06.2024
Где расположен нужный файл трассировки и как его найти?
SQL-Plus: Release 8.1.5.0.0 - Production on Fri 10 21:19:41 2000 (c) Copyright 1999 Oracle Corporation. All rights reserved. Connected to:
0racle8i Enterprise Edition Release 8.1.5.0.0 - Production With the Partitioning and Java options PL/SQL Release 8.1.5.0.0 - Production SQL> select Value
where Name = ' user_dump_desf /* Determine the destination of USER_DUMP_DEST */;
/* Determine the processes within your current shell. This is to determine the process ID of your SQL*Plus session */
1327 pts/2 0:00 ksh $ps -ef | grep 1279 /* Now scan all processes on the system and filter out the ones with your SQL*Plus's process ID. This is to determine the process ID of the server process that this SOL*Plus session is attached to */
oracle 1280 1279 0 21:41:00 ? 0:12 oracleprod815 (DESCRIPTION=aOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
$cd /u01/app/oracle/admin/prod815/udump /* Change directory to the USER_DUMP_DESTdirectory*/
-rw-ree 1 oracle dba 408548 Nov 10 21:04 prod815_ora_1280.trc
tkprof,
tkprof,
[print= ] [insert= ] [sys= ] [sort= ] table=schema.tablename Use 'schema.tablename' with 'explain^ option.
explain=user/password Connect to ORACLE and issue EXPLAIN PLAN.
print=integer List only the first 'integer' SQL statements. aggregate=yes|no
List SQL statements and data inside INSERT statements.
record=filename Record non-recursive statements found in the trace file,
sort=option Set of zero or more of the following sort options: prscnt number of times parse was called prscpu cpu time parsing
prsqry number of buffers for consistent read during parse
prscu number of buffers for current read during parse prsmis number of misses in library cache during parse execnt number of execute was called
execpu cpu time spent executing exeela elapsed time executing exedsk number of disk reads during execute
execu number of buffers for current read during execute exerow number of rows processed during execute exemis number of library cache misses during execute fchcnt number of times fetch was called fchcpu cpu time spent fetching fchela elapsed time fetching fchdsk number of disk reads during fetch fchqry number of buffers for consistent read during fetch fchcu number of buffers for current read during fetch fchrow number of rows fetched userid userid of user that parsed the cursor
fchela-
tkprof,
Что такое трассировка (tracing), профилирование (profiling) и чем они отличаются друг от друга?
Трассировка - это прогон программы c регистрацией того, какие строки (команды) каких модулей (подпрограмм) в какой последовательности были выполнены.
Профилирование - это прогон программы с регистрацией времени выполнения отдельных модулей (подпрограмм) и, возможно, внешних вызовов, выполняемых программой.
Трассировка и профилирование выполняются с целью собрать информацию о работе программы для дальнейшего ее анализа разработчиком. Трассировка позволяет, в частности, узнать, выполнялись ли некоторые, интересующие разработчика, строки программы. Профилирование позволяет увидеть, какие модули выполняются дольше всего и сосредоточиться на их оптимизации.
Я рассмотрю средства трассировки и профилирования, которые Oracle 11g предоставляет разработчику PL/SQL. И начну с трассировки.
Пакет SYS.DBMS_TRACE (имеется публичный синоним) позволяет включать и отключать режим трассировки в рамках текущего сеанса. Если при включенном режиме трассировки выполнить PL/SQL код, то данные о его выполнении будут записаны в трассировочные таблицы.
Если в БД трассировка ни разу не выполнялась, то трассировочные таблицы нужно вначале создать. Для этого нужно выполнить скрипт $ORACLE_HOME/rdbms/admin/tracetab.sql как пользователь SYS . Скрипт создает две таблицы и сиквенс для генерирования уникальных номеров трассировок:
Предоставлю доступ к трассировочным таблицам всем пользователям БД:
Пользователю AY , под которым буду выполнять трассировку, предоставлю право удалять трассировочные данные:
Трассировка включается процедурой DBMS_TRACE.SET_PLSQL_TRACE и отключается процедурой DBMS_TRACE.CLEAR_PLSQL_TRACE .
Процедура DBMS_TRACE.SET_PLSQL_TRACE принимает в качестве параметра уровень трассировки, задаваемый с помощью констант пакета DBMS_TRACE :
| TRACE_ALL_CALLS | Трассировать все вызовы. |
| TRACE_ALL_EXCEPTIONS | Трассировать все исключения. |
| TRACE_ALL_SQL | Трассировать все команды SQL. |
| TRACE_ALL_LINES | Трассировать все строки. |
| TRACE_ENABLED_CALLS | Трассировать активированные вызовы. |
| TRACE_ENABLED_EXCEPTIONS | Трассировать активированные исключения. |
| TRACE_ENABLED_SQL | Трассировать активированные команды SQL. |
| TRACE_ENABLED_LINES | Трассировать активированные строки. |
| NO_TRACE_ADMINISTRATIVE | Не трассировать события виртуальной машины PL/SQL. |
| NO_TRACE_HANDLED_EXCEPTIONS | Не трассировать обрабатываемые исключения. |
Под активированными (enabled) событиями понимаются события, связанные с выполнением кода только тех процедур, функций и пакетов, которые были скомпилированы для отладки. Так, уровень TRACE_ALL_CALLS включает трассировку всех вызовов в любом выполняемом коде PL/SQL, а уровень TRACE_ENABLED_CALLS - трассировку только вызовов в коде модулей, скомпилированных для отладки:
Другой способ откомпилировать PL/SQL модуль для отладки - использовать параметр PLSQL_DEBUG на уровне системы ( alter system set plsql_debug=true ), сеанса ( alter session set plsql_debug=true ) или непосредственно при компиляции:
Однако, параметр PLSQL_DEBUG в версии Oracle 11g объявлен устаревшим, поэтому первый способ предпочтительнее (к тому же, компиляция с PLSQL_DEBUG=TRUE в версии 11g генерирует предупреждения о понижении уровня оптимизации компилируемого кода.)
Посмотрим, как изменяются свойства модуля PL/SQL, доступные через вью USER_PLSQL_SETTINGS , при компиляции с опцией DEBUG и без нее. Создам процедуру HELLO , содержащую команду SQL, вызов другой процедуры, и возбуждающую исключение во время выполнения - это понадобится для экспериментов с трассировкой специфических событий:
Разобравшись с тем, как активировать код PL/SQL для целей трассировки, вернемся собственно к трассировке.
В качестве параметра для DBMS_TRACE.SET_PLSQL_TRACE можно использовать как отдельную константу пакета DBMS_TRACE , так и сумму нескольких констант. В последнем случае включается трассировка всех событий, соответствующих просуммированным константам. Например, DBMS_TRACE.TRACE_ALL_CALLS + DBMS_TRACE.TRACE_ENABLED_SQL включит трассировку всех вызовов и только активированных команд SQL.
Перехожу к экспериментам. Для начала, оттрассирую все выполняемые строки процедуры HELLO и изучу результат:
- с выполнением кода пакета DBMS_TRACE , с помощью которого я включал и отключал трассировку,
- c запуском и остановкой виртуальной машины PL/SQL,
- с управлением транзакциями при помощи пакета DBMS_TRANSACTION .
Хочется сосредоточиться на работе HELLO и исключить сбор данных, не связанных с выполнением этой процедуры. Воспользуюсь константой DBMS_TRACE.NO_TRACE_ADMINISTRATIVE , чтобы отключить регистрацию лишних событий:
Исчезли запуски и остановы виртуальной машины PL/SQL, но все еще много лишних событий, не относящихся к выполнению кода процедуры HELLO . Попробую трассировать только активированные события, для чего откомпилирую процедуру HELLO с опцией DEBUG :
Достаточно наглядно. Только строка 2 процедуры HELLO не была выполнена - в этой строке объявление переменной a pls_integer; . Можно сделать вывод, что данное объявление переменной не является исполняемой командой, а память под переменную выделяется в ходе загрузки программы в виртуальную машину PL/SQL.
Приведенный запрос, в случае трассировки одной и той же программы, запускаемой с разными параметрами, позволяет увидеть и сравнить последовательности выполнения строк программы в зависимости от параметров.
Проделаю еще один эксперимент с трассировкой. На этот раз я хочу видеть только активированные вызовы и выполнения команд SQL.
А теперь - с исходным кодом строк процедуры HELLO :
Что ж, получен ожидаемый результат.
Помимо уже упомянутых констант, в пакете DBMS_TRACE имеются и другие, предназначенные для настройки уровня трассировки. Кроме того, имеются "управляющие" константы, которые также могут передаваться при вызове DBMS_TRACE.SET_PLSQL_TRACE в качестве параметра:
| Константа | Описание | Альтернатива использованию константы |
|---|---|---|
| TRACE_PAUSE | Приостановить трассировку, не меняя уровень трассировки. | DBMS_TRACE.PAUSE_PLSQL_TRACE |
| TRACE_RESUME | Возобновить приостановленную трассировку. | DBMS_TRACE.RESUME_PLSQL_TRACE |
| TRACE_STOP | Остановить трассировку, очистив уровень трассировки. | DBMS_TRACE.CLEAR_PLSQL_TRACE |
| TRACE_LIMIT | Ограничить количество событий, хранимых в трассировочных таблицах, 8192 последними событиями. | DBMS_TRACE.LIMIT_PLSQL_TRACE |
Константы TRACE_PAUSE , TRACE_RESUME , TRACE_STOP нельзя комбинировать с другими константами при вызове DBMS_TRACE.SET_PLSQL_TRACE .
Как видно из таблицы, использованию "управляющих" констант с DBMS_TRACE.SET_PLSQL_TRACE имеется альтернатива - вызов соответствующей процедуры пакета DBMS_TRACE , приводящий к такому же результату: приостановка, возобновление и остановка трассировки.
Чтобы узнать больше о возможностях трассировки, рекомендую просмотреть спецификацию пакета DBMS_TRACE - в ней больше функций и констант, чем описано в официальном справочнике Database PL/SQL Packages and Types Reference для Oracle 11gR2.
В заключение, очищу трассировочные таблицы и удалю процедуру HELLO :
Во второй части статьи будет продемонстрирована работа с иерархическим профайлером - главным средством профлилирования программ PL/SQL в СУБД Oracle 11g.
Список событий, установленных для текущей сессии:
Трейс выполнения запроса / 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?
Для собственной сессии:
Главным является файл журнала оповещений (alert.log), который содержит важнейшую информацию о работе БД, в ходе диагностики его следует проверять в первую очередь.
Помимо alert.log Oracle автоматически генерирует два файла трассировки. Один из них - фоновый файл трассировки, создается фоновыми процессами DBWR и LGWR. Эти файлы трассировки могут и не создаваться при запуске системы, в зависимости от наличия информации для записи.
Файл трассировки второго типа создается соединением пользователя с БД и называется пользовательским файлом трассировки.
Такой файл появляется, только если сеанс пользователя наталкивается на ошибку.
Имена файлов трассировки имеют стандартный формат и зависят от используемой ОС. В среде UNIX фоновый файл трассировки выглядит как ORA_PID_PROCESS.trc, а пользовательский файл - PROCESS_ID.trc. При этом ORA_PID представляет идентификатор процесса Oracle, а PROCESS_ID - системного процесса, создавшего файл трассировки.
Для отладки поддерживаются различные средства диагностики. Для выгрузки в файлы трассировки диагностической информации можно подключить определенные события. Для диагностики повреждений диска и памяти применяются некоторые специальные параметрыinit.ora. Эти параметры не задаются при нормальной работе БД, т.к. они снижают ее производительность.
Задание событий трассировки
Приведем способы задания событий трассировки:
-выгрузить содержание всего управляющего файла
-выгрузить состояние системы для диагностики проблем, связанных с зависанием
-выгрузить содержание всех заголовков файлов данных
-выгрузить стек ошибки и процесса (напр., ошибка ORA-00604)
При задании событий с помощью init.ora используются следующие строки:
EVENT = "604 TRACE NAME ERRORSTACK FOREVER" - выгружается стек ошибок каждый раз, когда процесс встречает ошибку ORA-00604;
EVENT = "10210 TRACE NAME CONTEXT FOREVER, LEVEL 10" - контролируется целостность каждого блока при чтении с диска в кэш.
Наиболее распространенные коды событий:
10013 и 10015 -- применяются при диагностике проблем, связанных с повреждением сегментов отката.
event = "10015 trace name context forever"
10029 и 10030 -- информация о началах и остановках сеансов.
10210 и 10211 -- проверяются блоки данных, считываемые в область SGA
event = "10210 trace name context forever, level 10"
10231 и 10232 -- пропустить поврежденные блоки в ходе сканирования таблицы и выгрузить их в файл трассировки
event = "10231 trace name context forever, level 10"
Первый оператор отключает проверку блоков для данного сеанса. Второй включает проверку всех блоков БД, считываемых любым процессом в область SGA.
Анализ журнала с помощью LogMiner
Архивные файлы журналов повторов очень важны, особенно для восстановления БД. Для того, чтобы прочитать внесенные в БД изменения, которые содержаться в архивном файле журнала повторов, необходимо открыть указанный файл и изучить его содержимое.
Для этого существует специальный инструмент под названием LogMiner.
Для работы с этим инструментом необходимо:
1. Установить utl_file_dir в init.ora
2. Запустить $ORACLE_HOME/rdbms/admin/dbmslogmnrd.sql
для каждого добавляемого к списку файла журнала удалить
список всех изменений, выполненных пользователем SCOTT
7. SQL> EXEC DBMS_LOGMNR.END_LOGMNR;
Поиск и исправление поврежденных блоков данных с помощью модуля DBMS_REPAIR
Для устранения повреждений в блоках, таблицах и индексах Oracle предлагает инструмент DBMS_REPAIR.
Этот модуль позволяет:
- мягко повреждать блоки, чтобы показать, что они повреждены;
- пропускать поврежденные блоки в ходе полного сканирования таблицы или индекса;
- обслуживать ставшие ненужными строки индекса, которые указывают на поврежденные блоки данных;
- перестраивать списки свободной памяти для указанной таблицы или индекса.
Создание таблиц администрирования модуля DBMS_REPAIR
1. sqlplus " / as sysdba"
2. Создать (по желанию) табличное пространство.
Если нужно удалить таблицу:
Чтобы очистить таблицу (удалив все ее строки ) :
Проверим на повреждения таблицу data схемы prod. Допустим, что в схеме sys была создана таблица repair_admin
1. sqlplus " / as sysdba"
SQL> VARIABLE A NUMBER;
4. SELECT RELATIVE_FILE_ID FILE,
MARKED_CORRUPT MARKED FROM REPAIR_ADMIN;
Исправление поврежденных блоков с помощью процедуры DBMS_REPAIR.FIX_CORRUPT_BLOCKS
1. VARIABLE A NUMBER;
3. Проверим помечены ли элементы блока, как программно поврежденные:
SELECT RELATIVE_FILE_ID FILE,
MARKED_CORRUPT MARKED FROM REPAIR_ADMIN;
Пропуск поврежденных блоков с помощью процедуры DBMS_REPAIR.SKIP_CORRUPT_BLOCKS
Использование процедуры DBMS_REPAIR.DUMP_ORPHAN_KEYS для просмотра висячих ключей
SELECT SCHEMA_NAME, INDEX_NAME, INDEX_ID, TABLE_NAME, KEYROWID, KEY,
DUMP_TIME FROM ORPHAN_ADMIN;
Чтобы перестроить список свободной памяти таблицы DATA:
ORADEBUG
Утилита oradebug предоставляет доступ к структурам памяти процессов Oracle, стекам и т.д. С его помощью можно генерировать дамп состояния процесса, а также выгружать структуры области SGA. Кроме того, для уже работающего процесса можно активизировать какое-либо событие.
процесс менеджера прикрепляется к процессу Oracle под Unix номером 9431.
пример выхода: Oracle pid: 12, unix process pid: 9431, image: oraclevk803
размер файла трассировки устанавливается в unlimited
активизируется событие трассировки SQL
сбрасываем трассировочную информацию на диск нельзя так делать для фоновых оракловых процессов - может произойти остановка базы
При копировании материалов наличие активной индексируемой ссылки на сайт обязательно.
Читайте также: