Surgutnet.ru - Средства диагностики и утилиты отладки в Oracle

Oracle > Средства диагностики и утилиты отладки в Oracle

Для правильной диагностики проблем СУРБД Oracle необходимо знать утилиты отладки, предоставляемые Oracle. Необходимо понимать такие операции, как чтение дампов управляющего файла или файлов трассировки.
Автор : Владимир Голяков / Дата : 2006-10-11 08:46
Добавить или посмотреть комментарии :

(0)
Рейтинг пользователей :

Трассировочные файлы 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 используются следующие строки:
- выгружается стек ошибок каждый раз, когда процесс встречает ошибку ORA-00604:

Код:

EVENT = "604 TRACE NAME ERRORSTACK FOREVER"

- контролируется целостность каждого блока при чтении с диска в кэш:

Код:

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>');

Код:

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');

Код:

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;
SQL> EXEC DBMS_REPAIR.CHECK_OBJECT ( ' PROD', 'DATA', NULL, 1, 'REPAIR_ADMIN' , NULL, NULL, NULL, NULL, :A);
SQL>PRINT A;
SQL>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

Код:

SQL>VARIABLE A NUMBER;
SQL>EXEC DBMS_REPAIR.FIX_CORRUPT_BLOCKS( 'PROD', 'DATA', NULL, 1, 'REPAIR_ADMIN', NULL, :A);
SQL> -- Проверим помечены ли элементы блока, как программно поврежденные:
SQL>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

Код:

SQL>EXEC DBMS_REPAIR.SKIP_CORRUPT_BLOCKS ( 'PROD', 'DATA', 1,1);

Использование процедуры DBMS_REPAIR.DUMP_ORPHAN_KEYS для просмотра висячих ключей

Код:

SQL>EXEC DBMS_REPAIR.DUMP_ORPHAN_KEYS ('PROD', 'SNO_IDX', NULL, 2, 'REPAIR_ADMIN','ORPHAN_ADMIN', NULL, :A);
SQL>SELECT SCHEMA_NAME, INDEX_NAME, INDEX_ID, TABLE_NAME, KEYROWID, KEY, DUMP_TIME FROM ORPHAN_ADMIN;
SQL>--Чтобы перестроить список свободной памяти таблицы DATA:
SQL>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

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

Владимир Голяков
Оригинал статьи

Комментарии :