Средства диагностики и утилиты отладки в Oracle
ОГЛАВЛЕНИЕ
Трассировочные файлы Oracle
Главным является файл журнала оповещений (alert.log), который содержит важнейшую информацию о работе БД, в ходе диагностики его следует проверять в первую очередь.
В начале работы БД в alert.log заносятся все параметры файла init.ora и сообщения о запуске фоновых процессов. Регистрируется также используемый этим экземпляром поток и последовательный номер журнала, в который производит запись процесс LGWR.
В общем случае заносится также информация о запусках и остановах БД, создании табличных пространств и сегментов отката, некоторых операциях alter, переключениях журналов и сообщениях об ошибках.
Помимо alert.log Oracle автоматически генерирует два файла трассировки. Один из них - фоновый файл трассировки, создается фоновыми процессами DBWR и LGWR. Эти файлы трассировки могут и не создаваться при запуске системы, в зависимости от наличия информации для записи.
Файл трассировки второго типа создается соединением пользователя с БД и называется пользовательским файлом трассировки.
Такой файл появляется, только если сеанс пользователя наталкивается на ошибку.
Имена файлов трассировки имеют стандартный формат и зависят от используемой ОС. В среде UNIX фоновый файл трассировки выглядит как ORA_PID_PROCESS.trc, а пользовательский файл - PROCESS_ID.trc. При этом ORA_PID представляет идентификатор процесса Oracle, а PROCESS_ID - системного процесса, создавшего файл трассировки.
Для отладки поддерживаются различные средства диагностики. Для выгрузки в файлы трассировки диагностической информации можно подключить определенные события. Для диагностики повреждений диска и памяти применяются некоторые специальные параметрыinit.ora. Эти параметры не задаются при нормальной работе БД, т.к. они снижают ее производительность.
Задание событий трассировки
Приведем способы задания событий трассировки:
-выгрузить содержание всего управляющего файла
alter session set events 'immediate trace name controlf level 10'; (rdbms/mesg/oraus.msg)
-выгрузить состояние системы для диагностики проблем, связанных с зависанием
alter session set events 'immediate trace name systemstate level 10';
-выгрузить содержание всех заголовков файлов данных
alter session set events 'immediate trace name file_hdrs level 10';
-выгрузить стек ошибки и процесса (напр., ошибка ORA-00604)
alter session set events ' 604 trace name errorstack forever' ;
При задании событий с помощью 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 -- пропустить поврежденные блоки в ходе сканирования таблицы и выгрузить их в файл трассировки
alter session set events '10231 trace name context off';
event = "10231 trace name context forever, level 10"
Первый оператор отключает проверку блоков для данного сеанса. Второй включает проверку всех блоков БД, считываемых любым процессом в область SGA.
Анализ журнала с помощью LogMiner
Архивные файлы журналов повторов очень важны, особенно для восстановления БД. Для того, чтобы прочитать внесенные в БД изменения, которые содержаться в архивном файле журнала повторов, необходимо открыть указанный файл и изучить его содержимое.
Для этого существует специальный инструмент под названием LogMiner.
Для работы с этим инструментом необходимо:
1. Установить utl_file_dir в init.ora
2. Запустить $ORACLE_HOME/rdbms/admin/dbmslogmnrd.sql
3. SQL> EXECUTE dbms_logmnr_d.build('dictionary.ora', '<utl_file_dir>');
4. SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE(LogFileName => ' /oradata/test/arc/test454.arc', Options => dbms_logmnr.NEW);
для каждого добавляемого к списку файла журнала удалить
DBMS_LOGMNR.REMOVEFILE
5. EXECUTE DBMS_LOGMNR.START_LOGMNR(DictFileName => <utl_file_dir/dictionary.ora');
6. select scn, log_id, username, sql_redo, sql_undo from v$logmnr_contents where username='SCOTT';
список всех изменений, выполненных пользователем SCOTT
7. SQL> EXEC DBMS_LOGMNR.END_LOGMNR;
Поиск и исправление поврежденных блоков данных с помощью модуля DBMS_REPAIR
Для устранения повреждений в блоках, таблицах и индексах Oracle предлагает инструмент DBMS_REPAIR.
Этот модуль позволяет:
- мягко повреждать блоки, чтобы показать, что они повреждены;
- пропускать поврежденные блоки в ходе полного сканирования таблицы или индекса;
- обслуживать ставшие ненужными строки индекса, которые указывают на поврежденные блоки данных;
- перестраивать списки свободной памяти для указанной таблицы или индекса.
Создание таблиц администрирования модуля DBMS_REPAIR
1. sqlplus " / as sysdba"
2. Создать (по желанию) табличное пространство.
3. SQL> EXEC DBMS_REPAIR.ADMIN_TABLES( ' REPAIR_ADMIN', 1, 1, 'REPAIR_TS');
SQL> EXEC DBMS_REPAIR.ADMIN_TABLES( ' ORPHAN_ADMIN' , 2, 1, 'REPAIR_TS');
Если нужно удалить таблицу:
SQL> EXEC DBMS_REPAIR.ADMIN_TABLES( ' ORPHAN_ADMIN' , 2, 3, NULL);
Чтобы очистить таблицу (удалив все ее строки ) :
SQL> EXEC DBMS_REPAIR.ADMIN_TABLES( ' ORPHAN_ADMIN' , 2, 2, NULL);
Сканирование конкретной таблицы или индекса с помощью процедуры DBMS_REPAIR.CHECK_OBJE
Проверим на повреждения таблицу data схемы prod. Допустим, что в схеме sys была создана таблица repair_admin
1. sqlplus " / as sysdba"
SQL> VARIABLE A NUMBER;
2. SQL> EXEC DBMS_REPAIR.CHECK_OBJECT ( ' PROD', 'DATA', NULL, 1,
'REPAIR_ADMIN' , NULL, NULL, NULL, NULL, :A);
3. PRINT A;
4. SELECT RELATIVE_FILE_ID FILE,
BLOCK_ID BLOCK,
OBJECT_NAME OBJECT,
CORRUPT_DESCRIPTION,
REPAIR_DESCRIPTION,
MARKED_CORRUPT MARKED FROM REPAIR_ADMIN;
Исправление поврежденных блоков с помощью процедуры DBMS_REPAIR.FIX_CORRUPT_BLOCKS
1. VARIABLE A NUMBER;
2. EXEC DBMS_REPAIR.FIX_CORRUPT_BLOCKS( 'PROD', 'DATA', NULL, 1, 'REPAIR_ADMIN', NULL, :A);
3. Проверим помечены ли элементы блока, как программно поврежденные:
SELECT RELATIVE_FILE_ID FILE,
BLOCK_ID BLOCK,
OBJECT_NAME OBJECT,
CORRUPT_DESCRIPTION,
REPAIR_DESCRIPTION,
MARKED_CORRUPT MARKED FROM REPAIR_ADMIN;
Пропуск поврежденных блоков с помощью процедуры DBMS_REPAIR.SKIP_CORRUPT_BLOCKS
EXEC DBMS_REPAIR.SKIP_CORRUPT_BLOCKS ( 'PROD', 'DATA', 1,1);
Использование процедуры DBMS_REPAIR.DUMP_ORPHAN_KEYS для просмотра висячих ключей
EXEC DBMS_REPAIR.DUMP_ORPHAN_KEYS ('PROD', 'SNO_IDX', NULL, 2, 'REPAIR_ADMIN',
'ORPHAN_ADMIN', NULL, :A);
SELECT SCHEMA_NAME, INDEX_NAME, INDEX_ID, TABLE_NAME, KEYROWID, KEY,
DUMP_TIME FROM ORPHAN_ADMIN;
Чтобы перестроить список свободной памяти таблицы DATA:
EXEC DBMS_REPAIR.REBUILD_FREELISTS( 'PROD', 'DATA', NULL, 1);
ORADEBUG
Утилита oradebug предоставляет доступ к структурам памяти процессов Oracle, стекам и т.д. С его помощью можно генерировать дамп состояния процесса, а также выгружать структуры области SGA. Кроме того, для уже работающего процесса можно активизировать какое-либо событие.
SQL> oradebug help
SQL> oradebug setospid 9431
процесс менеджера прикрепляется к процессу Oracle под Unix номером 9431.
пример выхода: Oracle pid: 12, unix process pid: 9431, image: oraclevk803
SQL> oradebug unlimit
размер файла трассировки устанавливается в unlimited
SQL> oradebug event 10046 trace name context forever, level 12
активизируется событие трассировки SQL
SQL> oradebug flush
сбрасываем трассировочную информацию на диск нельзя так делать для фоновых оракловых процессов - может произойти остановка базы