Для правильной диагностики проблем СУБД Oracle необходимо знать утилиты отладки, предоставляемые 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
сбрасываем трассировочную информацию на диск
нельзя так делать для фоновых оракловых процессов - может произойти остановка базы