The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Средства диагностики и утилиты отладки в Oracle (database oracle debug log crash)


<< Предыдущая ИНДЕКС Правка src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: database, oracle, debug, log, crash,  (найти похожие документы)
From: Владимир Голяков <http://a-sys.ru>; Date: Mon, 20 Mar 2005 18:21:07 +0000 (UTC) Newsgroups: http://a-sys.ru Subject: Средства диагностики и утилиты отладки в Oracle Оригинал: http://a-sys.ru/Articles/Article.aspx?ID=49 Средства диагностики и утилиты отладки в Oracle Для правильной диагностики проблем СУРБД 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. Некоторые другие события: http://www.orafaq.com/faqdbain.htm#EVENTS Анализ журнала с помощью 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 сбрасываем трассировочную информацию на диск нельзя так делать для фоновых оракловых процессов - может произойти остановка базы Владимир Голяков. ©"АКС", 2004. При использовании материалов сайта ссылка на "a-sys.ru" обязательна

<< Предыдущая ИНДЕКС Правка src Установить закладку Перейти на закладку Следующая >>

Ваш комментарий
Имя:         
E-Mail:      
Заголовок:
Текст:





  Закладки на сайте
  Проследить за страницей
Created 1996-2017 by Maxim Chirkov  
ДобавитьРекламаВебмастеруГИД  
Hosting by Ihor