В этой статье рассказывается:
- как Healt Monitor автоматически наблюдает за состоянием некоторых компонент базы данных и записывает результаты в Automatic Diagnostic Repository,
- как при наличии проблемы создать пакет для отправки в Oracle Support и
- как читать новые версии alert.log, listener.log и других журналов.
Автоматический монитор состояния (Automatic Health Monitor)
Каким образом можно определить, что база данных чувствует себя хорошо? Одним из способов является проверка "всего" ("everything"), но это - трудоемкий и потенциально подверженный ошибкам процесс. Пример решения вопроса - в некоторых организациях для определения состояния работоспособности базы данных выделенные для этой задачи АБД выполняют одни и те же действия снова и снова. Однако, в большинстве случаев нанять команду на полный рабочий день не представляется возможным. Альтернативной является наличие постоянной АБД-команды для выполнения проверок состояния, однако, результат не всегда удовлетворительный. Разделение внимания одного человека на слишком большое количество деталей может вызвать упущение некоторых потенциально опасных мелочей.
В Oracle Database 11g эта задача становится несколько проще с появлением Automatic Health Monitor (Автоматический монитор состояния). Так же как появившиеся ление в Oracle Database 10g советчики (Advisers), в 11g контролеры (checkers) из Automatic Health Monitor наблюдают (автоматически после сбоя или по требованию) за множеством компонент, например, за файлами данных или словарем, на предмет их логической или физической целостности. Когда контролеры находят что-то, информация рапортуется и может быть передана множеству советчиков восстановления. Как минимум, новая функциональность Incident Packaging Service (будет рассмотрена далее) позволяет скомпоновать все текущие проблемы и необходимые файлы для простой отсылки в Oracle Support.
Как и большинство других возможностей базы данных Oracle Database 11g, этот процесс может управляться как из командной строки, так и через GUI продукта Oracle Enterprise Manager. Ниже в этой статье будет показано, как это делается.
На главной странице Database, прокрутив вниз, находится раздел Related Links:
В списке ссылок, щелкнув по Advisor Central, попадаем на страницу Advisors and Checkers. Щелкнув по закладке Checkers, появится страница, верхняя часть которой показана ниже:
Это очень важный экран, тут отображено множество доступных контролеров вместе с автоматическими контролерами, которые уже были выполнены.
Для начала сконцентрируемся на доступных контролерах.
DB Structure Integrity Check. Лучше всего описать его через следующий пример. Щелкнув по ссылке DB Structure Integrity Check, попадаем на экран, где задаем какое-либо имя (например, "DB_Struct_Int1") создаваемого запуска контролера. Второй ожидаемый ввод - лимит на время выполнения задачи, лучше не менять для большей эффективности.
После успешной отработки контролера появляется подтверждающее сообщение, как видно на верхней части экрана, показанного ниже:
Нижняя часть экрана так же показывает информацию о только что выполненном запуске. Имя - то, что было задано выше, DB_Struct_Int1. Важное отличие заключается в том, что поле Run Type для только что выполненного запуска содержит значение "Manual" вместо "Reactive", которое отображается у остальных контролеров. Чтобы выбрать этот запуск контролера, отметим радио-кнопку слева от него и щелкнем по кнопке Details. Экран, полученный в результате этого действия, будет содержать подробности запуска, какой тип повреждений обнаружен и т.д.
В рассматриваемом случае файл данных каким-то образом оказался поврежден и контролер обнаружил это. Эта информация будет отправлена компоненте Data Recovery Advisor (обсуждается в статье об усовершенствованиях RMAN) для выполнения необходимых действий. Администратор может запустить этот контролер в любой момент для проверки целостности файлов данных.
Скорее всего этот контролер и станет самым популярным. На экране со списком последних запусков выберем любой нужного типа и щелкнув по кнопке Details увидим следующий экран:
На экране все находки касательно текущей проблемы: файл данных #7 поврежден. Запустив Recovery Advisor, получим рекомендации, что лучше сделать в этой ситуации.
Data Block Integrity Checker. Этот контролер похож на DB Structure Integrity Check, с той лишь разницей, проверяет он не весь файл данных, а только выбранные блоки данных. Допустим, были заданы название запуска и прочие необходимые детали - вот что необходимо задать дополнительно:
Обращаю внимание, необходимо ввести номер файла данных и номер блока (я ввел 7 и 20 соответственно). После ввода данных нажимаем OK. Запускается процесс проверки, в нижней части экрана появляется статус работы как показано ниже:
Опять, в случае нахождения проблем с блоком данных, контролер найдет их. Через ссылку попадем на страницу с подробностями найденных проблем.
Redo Integrity Check. Эта проверка анализирует содержимое оперативных (redo log) и архивных (archive log) файлов журнала базы данных на предмет доступности и целостности.
Undo Segment Integrity Check. Эта проверка находит логические разрушения в UNDO, которые иногда обнаруживаются во время rollback-операций. После обнаружения разрушения в UNDO контролер с помощью процессов PMON и SMON пытается восстановить разрушенную транзакцию. Если восстановление не получилось, Automatic Health Monitor сохраняет информацию о сбое в представлении V$CORRUPT_XID_LIST. Большинство разрушений в UNDO могут быть решены за счет выполнения принудительной фиксации (forcing commit).
Transaction Integrity Check. Эта проверка практически идентична контролеру Undo Segment Check за тем исключением, что проверяет она только одну конкретную транзакцию, переданную в качестве входного параметра. После обнаружения разрушения в UNDO, контролер с помощью процессов PMON и SMON пытается восстановить разрушенную транзакцию. Если восстановление не получилось, Automatic Health Monitor сохраняет информацию о сбое в представлении V$CORRUPT_XID_LIST. Большинство разрушений в UNDO могут быть решены за счет выполнения принудительной фиксации (forcing commit).
Dictionary Integrity Check. Эта проверка анализирует целостность таких фундаментальных компонентов словаря базы данных, как tab$ и col$. Выполняется проверка содержимого всех объектов словаря для которых включены ограничения (constraints) на строках, а так же ограничения, обеспечивающие целостность отношений родитель-ребенок (parent-child) между объектами словаря.
Автоматические проверки состояния (Automatic Health Checks)
Помните главную страницу Контролеров? Обратите внимание на список Checker Runs (Запуски Контролеров) внизу страницы и значение поля Run Type - отображены произошедшие запуски различных контролеров. Если контролер был запущен вручную, как это было сделано в примере выше, значение Run Type будет "Manual" (Ручное). Значение "Reactive" (Реактивный) означает, контролер будет запущен автоматически в случае обнаружения ошибки где-либо. Если запуск что-то обнаружил, находки становятся ссылками и по ним можно получить дополнительную информацию. Например, щелкнув на первом запуске, HM_RUN_140013, будут показаны детали этого запуска:
Причина сбоя явно показана. Точнее, здесь два типа сбоя, по крайней мере: разрушен оперативный журнал (online log) и файл данных. Первое, что можно сделать - попросить совета, щелкнув по кнопке Launch Recovery Advisor. После прохождения через интерфейс Мастера (Wizard), попадаем на экран со списком конкретных действий, предлагаемых Советчиком:
Возможным действием будет выполнение SQL-файла reco_767216331.hm из каталога /home/oracle/diag/rdbms/odel11/ODEL11/hm. Если открыть файл, внутри будет следующая конструкция:
begin
/*Clear the Log Group*/
execute immediate 'ALTER DATABASE CLEAR LOGFILE GROUP 3';
end;
Разрушенный файл журнала принадлежит группе, которая не является активной в данный момент, поэтому является идеальным кандидатом на очистку - собственно, это и есть рекомендация от Recovery Advisor. Если вы решаете продолжить работу с Советчиком, щелкните по кнопке Continue, и восстановление продолжается. Когда оно закончится, вернувшись обратно на экран Support Workbench видно, что разрушение оперативного файла журнала позади, однако обнаружено новое разрушение - архивированный журнал (archivelog).
Как всегда, необходимо запустить Советчика для исправления этих ошибок.
Автоматический репозиторий диагностики (Automatic Diagnostic Repository)
Когда контролеры что-либо находят, им необходимо где-то записать информацию для дальнейшего анализа и обработки. Все метаданные записываются в новой структуре, называемой Automatic Diagnostic Repository (Автоматический репозиторий диагностики), куда попадают все критические события, а не только те, которые обнаруживают контролеры. Эта область - как табличное пространство SYSTEM - для всех критических событий базы данных. Посмотрим, как этим пользоваться через Enterprise Manager.
Со страницы Database интерфейса Enterprise Manager щелкаем по закладке Software and Support, затем по Support Workbench и попадаем на экран, похожий на этот:
Здесь отображена статистика работы контролеров: обнаружены ошибки ORA-603. Щелкнем на значок "+" слева от ошибки и видим детальное описание ошибки:
Под заголовком Incidents находится список ID-инцидентов, являющихся ссылками. Щелкнув по ссылке, можно посмотреть описание конкретного инцидента. Например, рассмотрим инцидент 14435. Щелкнув по ссылке, появится экран с деталями:
Верхняя часть экрана содержит детали, говорящие сами за себя. Нижняя часть экрана содержит дополнительную информацию, например, список трассовых файлов. Эти файлы отсылаются в Oracle Support для анализа (только в случае, если используется Incident Packaging Service для упаковки этих файлов и настроен Oracle Configuration Manager с правильными данными авторизации). Щелкнув по иконке "лупа" рядом с первым трассовым файлом, раскроется страница с содержимым файла:
Обратите внимание, строки файла обработаны и показаны в очень понятном виде. Enterprise Manager читает каждую строку, определяет зависимые друг от друга строки и отображает их с необходимыми отступами. Кликнув по ссылке внутри файла, отображается необработанное (raw) содержимое файла.
Инциденты можно собрать в один "конверт" и отправить в Oracle Support, для чего необходимо их запаковать. Чтобы сделать это, поставим галочку под Select и нажмем кнопку Package. Появится страница:
В нашем примере проигнорируем Custom Packaging. Щелкаем на Quick Packaging и потом на Continue. Появится следующая страница:
Заполним все поля и нажмем Next. На следующем экране будет подтверждение, что именно запаковано, "манифест" созданного пакета и т.д. Будет видно, что все необходимые трассовые файлы, связанные с ошибкой, определены и добавлены в пакет. Этот процесс защищает от потенциальных ошибок в ходе определения правильного набора трассовых файлов для конкретной ошибки. Инструмент достаточно умен, чтобы собрать трассовые файлы от похожих ошибок в один пакет. Это важно, т.к. Oracle Support необходимы все трассовые файлы от похожих ошибок для определения основной причины ошибки. Ошибка, которую вы решили упаковать, может быть лишь симптомом, но не основной причиной. В конце жмем Submit для отправки в Oracle. После нажатия экран будет выглядеть немного по-другому, как показано ниже:
Обратите внимание, появилась запись "Yes" (Да) под заголовком Packaged. Это подтверждение, что инцидент упакован. Вот еще одна важная деталь:
Здесь показано, что файл для загрузки сгенерирован вместе с соответствующими деталями, которые были в момент генерации, основная причина находится в пакете и т.д. Тем не менее, файл не отправлен в Oracle Support, потому что до сих пор не проинсталлирован или не настроен Configuration Manager. Описание этого процесса приводится ниже. А если щелкнуть на имени пакета, показаны детали:
Детали говорят сами за себя. Все инциденты снабжены ссылками, щелкнув по которым, вы попадете на ранее показанные страницы с инцидентами. Щелкнув по закладке Files, попадаем на страницу со всеми файлами, содержащимися в пакете. Маленькая иконка с лупой в дальнем правом углу говорит о том, что щелкнув по ней, можно посмотреть содержимое файлов.
Щелкнув сейчас по закладке Activity Log, можно увидеть историю пакета, когда он был создан, отослан в Oracle (если был отослан) и т.д.
Изменение Пакета (Customizing the Package)
Одна из самых удобных возможностей этого инструмента - возможность изменять содержимое пакета, отправляемого в Oracle. Для использования этой возможности необходимо кликнуть по кнопке Customize. Появится вот такая страница:
Рассмотрим панель в правой части экрана - Packaging Tasks. Здесь собраны ссылки для выполнения множества задач с пакетом. Вот несколько основных:
- Редактировать содержимое
- Добавить проблемы (Add Problems): позволяет добавить другие проблемы в пакет. Полезно, если вы считаете, что проблемы могут быть связаны.
- Исключить проблемы (Exclude Problems): позволяет исключить проблемы; полезно, если вы считаете, проблемы не связаны с другими проблемами, включенными в пакет.
- Посмотреть Манифест Пакета (View Package Manifest): манифест - это документ, описывающий содержимое пакета (о чем пакет, какие проблемы покрывает, какие трассовые файлы включены и т.д.). Это текстовый файл, щелкнув по этой ссылке, можно посмотреть содержимое файла.
- Удалить пользовательские данные
- Скачать файлы для редактирования содержимого (Copy out Files to Edit Contents): тут можно скопировать трассовые и другие файлы на локальную файловую систему и затем отредактировать их, если необходимо. Это может понадобиться, если файлы содержат важную пользовательскую информацию.
- Закачать файлы для замены содержимого (Copy in Files to Replace Contents): После того, как файлы отредактированы, можно закачать их обратно с целью заменить оригиналы.
- Дополнительная диагностическая информация
- Собрать дополнительные дампы (Gather Additional Dumps): позволяет добавить дополнительные дампы (например, трассовые файлы, полученные в результате установки параметра sql_trace = true) и примеры для репродуцирования проблемы (test cases).
- Добавить внешние файлы (Add External Files): можно добавить любые другие файлы (например, init.ora или listener.ora) по требованию Oracle Support (или по другим причинами).
- Отправить в Oracle Support
- Завершить подготовку содержимого (Finish Contents Preparation): как следует из названия, можно подтвердить, содержимое готово и может быть отправлено в Oracle Support.
- Создать файл для закачки (Generate Upload File): позволяет сгенерировать файл для закачки еще раз, с учетом всех добавлений и удалений, сделанных со списком файлов.
- Посмотреть/Отправить файлы (View/Send Upload Files): если настроен Configuration Manager, можно закачать файл в Oracle Support.
Менеджер конфигурации (Configuration Manager)
Было бы неплохо, если бы был создан пакет и отправлен в Oracle Support, создан черновик Service Request (TAR) с необходимыми деталями - вашим CSI и именем пользователя из MetaLink? Это возможно, используя инструмент Oracle Configuration Manager.
Во время инсталляции Oracle Database 11g появляется вопрос, надо ли инсталлировать и настроить этот инструмент. Если ответ был "Yes" (Да), он у вас уже установлен, если же "No" (Нет), это можно сделать сейчас.
В Oracle Home переходим в каталог ccr/bin. Для первичной настройки Configuration Manager запускаем файл setupCCR. Показывается лицензионное соглашение и предложение согласиться с ним или отказать. Далее будут заданы вопросы - ваш номер CSI, имя пользователя на MetaLink и т.д. Вот как выглядит эта сессия. Ответы пользователя выделены жирным шрифтом:
*** Do you accept this license agreement? (Y/N) [Y]: Y
Configuration requires the following piece(s) of information.
Customer Support Identifier (CSI): XXXXXXX
Oracle MetaLink User Name: arup@proligence.com
The two character country code: US
** Installing base package **
Deploying core - Version 10.2.6.0.0
** Registering installation with Oracle Configuration Manager server(s) **
Deploying engines - Version 10.2.2.0.3
Deploying metricdata - Version 10.2.4.0.2
Deploying scripts - Version 10.2.6.0.0
** Getting package updates from ContentServer **
** Starting the Oracle Configuration Manager Scheduler **
Oracle Configuration Manager - Release: 10.2.6.0.0 - Production
Copyright (c) 2005, 2007, Oracle. All rights reserved.
------------------------------------------------------------------
Starting Oracle Configuration Manager...
Waiting for status from Oracle Configuration Manager....
Start Date 16-Oct-2007 09:28:46
Last Collection Time -
Next Collection Time 17-Oct-2007 09:28:00
Collection Frequency Daily at 09:28
Collection Status scheduled collection running
Log Directory /home/oracle/app/oracle/product/11.1/db_1/ccr/log
Registered At 16-Oct-2007 09:28:17
Automatic Update On
Collector Mode Connected
Oracle Configuration Manager successfully started.
После того как Configuration Manager настроен, изменить параметры можно с помощью скрипта configCCR из того же каталога.
Домашний каталог ADR (ADR Home)
Так как все внимание базы данных сконцентрировано на возможностях диагностики, должна ли Oracle Database хранить все трассовые, журнальные и т.д. файлы в виде организованной структуры? Oracle Database 11g делает это. Файлы Automatic Diagnostic Repository (ADR) находятся под общим каталогом, указанным как Diagnostic Destination (или ADR Base). Этот каталог выставляется параметром инициализации (diagnostic_dest). По-умолчанию он равен $ORACLE_BASE, однако, вручную его можно исправить на любой другой каталог (это, кстати, не рекомендуется). Под этим каталогом находится каталог diag, в котором и находятся подкаталоги, содержащие диагностические файлы.
ADR хранит журнальные и трассовые файлы всех компонент - ASM, CRS, слушивателя (listener) и т.д. - в дополнение к тем, что генерирует сама база. Таким образом, все файлы журналов находятся в одном месте, и найти какой-то определенный не составляет труда.
Внутри ADR Base могут находиться несколько ADR Home, по одному на каждый компонент и экземпляр. Например, если на сервере работают два экземпляра Oracle, будет два ADR Home. Вот как выглядит структура каталогов в ADR Home для баз данных:
|
Имя Каталога |
Описание |
|
< Каталог, указанный в параметре DIAGNOSTIC_DEST > |
|
|
→diag |
|
|
→rdbms |
|
|
→<Имя Базы Данных> |
|
|
→<Имя Экземпляра> |
|
|
→alert |
alert log в формате XML хранится тут. |
|
→cdump |
Тут хранятся Core dumps, эквивалент параметра core_dump_dest в ранних версиях. |
|
→hm |
Health Monitor запускает проверки на многие компоненты и тут хранит некоторые файлы. |
|
→incident |
Все дампы инцидентов хранятся тут. |
|
→<все каталоги с инцидентами находятся тут> |
Каждый инцидент хранится в своем каталоге, все они находятся тут. |
|
→incpkg |
Когда происходит упаковка инцидента (описание процесса упаковки в этой статье), некоторые дополнительные файлы хранятся тут. |
|
→metadata |
Метаданные о проблемах, инцидентах, пакетах и т.д. хранятся тут. |
|
→trace |
Пользовательские, фоновых процессов трассовые файлы и текстовая версия журнала alert.log хранятся здесь. |
Например, если имя базы данных - ODEL11 и имя экземпляра так же ODEL11 (большими буквами), путь к ADR Home будет выглядеть так: /home/oracle/diag/rdbms/odel11/ODEL11. Под каталогом ADR Home находятся следующие каталоги:
$ ls
alert cdump hm incident incpkg ir lck metadata stage sweep trace
Для поддержания этой новой структуры, все *_dest параметры из предыдущих релизов (background_dump_dest и user_dump_dest) игнорируются (core_dump_dest не игнорируется; Oracle рекомендует устанавливать его, т.к. core dump может быть очень большим). Эти параметры не следует устанавливать вовсе, а если происходит миграция с 10g на 11g, их следует удалить из файла параметров во избежание конфликтов впоследствии.
Структура каталогов ADR для других компонент схожая. Например, для экземпляра ASM каталог под каталогом "diag" вместо rdbms называется asm. Остальная часть структуры каталогов та же. Имя целевого каталога в случае asm будет +asm. Для примера, вот как у меня выглядит ADR Home для ASM:
$ pwd
/home/oracle/diag/asm/+asm/+ASM
$ ls
alert cdump hm incident incpkg ir lck metadata stage sweep trace
Для прослушивателя каталог под каталогом diag называется tnslsnr, под которым находится еще один каталог с названием хоста, а под ним - каталог с названием, равным имени процесса-слушивателя. Под ним находятся все остальные каталоги.
<Каталог, указанный в параметре DIAGNOSTIC_DEST>
→ diag
→ tnslsnr
→ <hostname of the server>
→ <name of the listener>
→ alert
→ trace ...
Например, для хоста с именем oradba3 и прослушивателя "listener" (имя по-умолчанию), каталог будет иметь вид /home/oracle/diag/tnslsnr/oradba3/listener. Ниже этого каталога создаются все остальные (alert, trace, metadata и т.д.). Как и alert.log, журнал listener.log хранится в виде записей XML в каталоге alert. Стандартный текстовый журнал прослушивателя все еще создается и находится в каталоге trace.
Новое представление, V$DIAG_INFO, отображает все детали всех существующих ADR Home. В моем RDBMS Home его содержимое выглядит вот так:
SQL> select * from v$diag_info;
INST_ID NAME VALUE
-------- ------------------------------ -----------------------------------------------------------------
1 Diag Enabled TRUE
1 ADR Base /home/oracle
1 ADR Home /home/oracle/diag/rdbms/odel11/ODEL11
1 Diag Trace /home/oracle/diag/rdbms/odel11/ODEL11/trace
1 Diag Alert /home/oracle/diag/rdbms/odel11/ODEL11/alert
1 Diag Incident /home/oracle/diag/rdbms/odel11/ODEL11/incident
1 Diag Cdump /home/oracle/diag/rdbms/odel11/ODEL11/cdump
1 Health Monitor /home/oracle/diag/rdbms/odel11/ODEL11/hm
1 Default Trace File /home/oracle/diag/rdbms/odel11/ODEL11/trace/ODEL11_ora_3908.trc
1 Active Problem Count 3
1 Active Incident Count 37
11 rows selected.
Представленный вывод отображает информацию об ADR только для текущего экземпляра. Чтобы увидеть информацию для других экземпляров, необходимо установить соединение с интересующим экземпляром и запросить информацию из представления V$DIAG_INFO. Названия столбцов говорят сами за себя. Трассовый файл По-умолчанию (Default Trace File) означает трассовый файл для текущей сессии. Значения Active Problem (Активные Проблемы) и Incident counts (Количество Инцидентов) - для проблем и инцидентов, рассмотренных выше.
Получить доступ к файлам ADR и выполнить другие действия можно двумя способами. Наипростейший - использовать Enterprise Manager, как было показано выше. Второй способ - использовать утилиту командной строки adrci. Посмотрим, как пользоваться этим инструментом. Для командной строки UNIX (или Windows) набираем "adrci":
$ adrci
ADRCI: Release 11.1.0.6.0 - Beta on Sun Sep 23 23:22:24 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
ADR base = "/home/oracle"
Как было сказано выше, существует несколько ADR Home, один для каждого экземпляра Oracle. Поэтому, первой задачей будет посмотреть, сколько всего ADR Home существует. Команда звучит как "show homes":
adrci> show homes
ADR Homes:
diag/rdbms/odel11/ODEL11
diag/rdbms/dbeng1/DBENG1
diag/clients/user_unknown/host_411310321_11
diag/tnslsnr/oradba3/listener
Как видно, есть несколько ADR Home. Для работы с конкретным ADR Home, следует использовать команду "set homepath":
adrci> set homepath diag/rdbms/odel11/ODEL11
Как только ADR Home установлен, можно выполнять множество команд. Первая команда, которую следует попробовать - "help", - покажет все доступные команды. Вот неполный вывод работы команды:
adrci> help
HELP [topic]
Available Topics:
CREATE REPORT
ECHO
EXIT
HELP
HOST
IPS
...
Если требуется узнать больше о конкретной команде, следует использовать синтаксис help <command>. Например, чтобы получить помощь по использованию команды show incidents, следует выполнить:
adrci> help show incident
Usage: SHOW INCIDENT [-p <predicate_string>]
[-mode BASIC/BRIEF/DETAIL]
[-last <num> / -all]
[-orderby (field1, field2, ...) [ASC/DSC]]
Purpose: Show the incident information. By default, this command will
only show the last 50 incidents which are not flood controlled.
Options:
[-p <predicate_string>]: The predicate string must be double-quoted.
[-mode BASIC/BRIEF/DETAIL]: The different modes of showing incidents.
[... and so on ...]
Из вывода становится ясно, как пользоваться командой. Теперь, чтобы узнать, как много инцидентов было зарегистрировано, выполним:
adrci> show incident -mode basic
ADR Home = /home/oracle/diag/rdbms/odel11/ODEL11:
******************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
-------------------- ---------------------------------------------------- ----------------------------------------
14556 ORA 600 [KSSRMP1] 2007-10-17 04:01:57.725620 -04:00
14555 ORA 600 [KSSRMP1] 2007-10-16 18:45:03.970884 -04:00
14435 ORA 603 2007-10-16 06:06:46.705430 -04:00
14427 ORA 603 2007-10-16 06:06:42.007937 -04:00
14419 ORA 603 2007-10-16 06:06:30.069050 -04:00
6001 ORA 4031 2007-08-28 14:50:01.355783 -04:00
5169 ORA 4031 2007-09-04 19:09:36.310123 -04:00
5121 ORA 4031 2007-09-03 14:40:14.575457 -04:00
5017 ORA 4031 2007-09-04 19:09:30.969226 -04:00
4993 ORA 4031 2007-09-04 19:09:33.179857 -04:00
4945 ORA 4031 2007-09-04 19:09:30.955524 -04:00
4913 ORA 4031 2007-09-04 19:09:31.641990 -04:00
Этот вывод содержит информацию обо всех зарегистрированных инцидентах. Чтобы получить детальную информацию о конкретном инциденте, выполним:
adrci> show incident -mode detail -p "incident_id=14556"
ADR Home = /home/oracle/diag/rdbms/odel11/ODEL11:
*************************************************************************
**********************************************************
INCIDENT INFO RECORD 1
**********************************************************
INCIDENT_ID 14556
STATUS ready
CREATE_TIME 2007-10-17 04:01:57.725620 -04:00
.
[... and so on ...]
.
INCIDENT_FILE /home/oracle/diag/rdbms/odel11/ODEL11/trace/ODEL11_mmon_14831.trc
OWNER_ID 1
INCIDENT_FILE /home/oracle/diag/rdbms/odel11/ODEL11/incident/incdir_14556/ODEL11_mmon_14831_i14556.trc
1 rows fetched
Информация от утилиты adrci аналогична той, что доступна через Enterprise Manager. EM, однако, намного более удобен и прост в использовании. adrci очень помогает, когда по каким-то причинам нет доступа к страницам EM Support Workbench. Утилита adrci так же может быть использована для непрерывного (tail -f) просмотра alert.log, а так же поиска в журналах (listener, css, crs, alert etc.) определенных записей. Утилита adrci так же незаменима при работе с ADR программными методами.
Новый Alert Log
В Oracle Database 11g журнал событий системы (alert.log) пишется в формате XML. Ради совместимости со старыми инструментами, традиционная версия журнала - текстовая - также доступна в ADR Home, в каталоге trace. Например, в моем примере, приведенном выше, в каталоге /home/oracle/diag/rdbms/odel11/ODEL11/trace находится файл alert_ODEL11.log. Тем не менее, остальные журналы событий создаются в формате XML и находятся в подкаталоге alert под ADR Home. Вот эти файлы:
$ pwd
/home/oracle/diag/rdbms/odel11/ODEL11/alert
$ ls -ltr
total 60136
-rw-r----- 1 oracle oinstall 10485977 Sep 13 17:44 log_1.xml
-rw-r----- 1 oracle oinstall 10486008 Oct 16 06:35 log_2.xml
-rw-r----- 1 oracle oinstall 10485901 Oct 16 07:27 log_3.xml
-rw-r----- 1 oracle oinstall 10485866 Oct 16 08:12 log_4.xml
-rw-r----- 1 oracle oinstall 10486010 Oct 17 23:56 log_5.xml
-rw-r----- 1 oracle oinstall 9028631 Oct 21 20:07 log.xml
Обратите внимание, файлов несколько: log_1.xml, log_2.xml и т.д. Когда log.xml достигает определенного размера, он переименовывается в log_?.xml и создается новый файл. Это предотвращает журнал от достижения слишком больших размеров и следующих вслед за этим проблем с его управлением.
Новый alert.log доступен через adrci - утилиту командной строки для работы с ADR, описанную выше. Выполним следующую команду из интерфейса adrci:
adrci> show alert
Choose the alert log from the following homes to view:
1: diag/rdbms/odel11/ODEL11
2: diag/clients/user_oracle/host_1967384410_11
3: diag/clients/user_unknown/host_411310321_11
4: diag/tnslsnr/oradba3/listener
Q: to quit
Please select option:
Можно выбрать одну из предложенных опций меню или добавить еще один ADR Home:
adrci> set homepath diag/rdbms/odel11/ODEL11
adrci> show alert
ADR Home = /home/oracle/diag/rdbms/odel11/ODEL11:
[... тут будет целиком показан alert.log ...]
Вместо того чтобы запрашивать весь alert.log, можно указать, что требуется отобразить лишь несколько строк с конца файла - например, 10 (аналогично команде tail -10 в среде UNIX):
adrci> show alert -tail 10
2007-09-23 19:57:44.502000 -04:00
Errors in file /home/oracle/diag/rdbms/odel11/ODEL11/trace/ODEL11_arc1_20810.trc:
[... остаток 10 строк ...]
Скорее всего, наиболее частым использованием этой возможности будет постоянный вывод последних строк файла alert.log, нечто подобное команды tail -f в UNIX:
adrci> show alert -tail -f
Из интерфейса adrci можно запускать скрипты. Вот пример, как в Windows из скрипта установить ADR Home и показать последние 10 строк из alert.log:
C:\>type show_alert_10lines.cmd
set homepath diag\rdbms\lapdb11\lapdb11
show alert -tail 10
Вызвать этот скрипт можно следующим образом:
adrci script=show_alert_10lines.cmd
Похожую функциональность обеспечивает параметр exec, который позволяет выполнять команды прямо из командной строки:
adrci exec="show homes; show catalog"
Также, из командной строки adrci можно выполнять команды, используя команду "run" или символ "@":
adrci>> @show_alert_10lines.cmd
Одна из лучших возможностей, ставшая доступной из-за XML формата файла alert.log - информация хранится в структурированном виде. Прошли времена, когда alert.log был хранилищем неструктурированной информации. Формат XML позволяет просматривать alert.log в виде таблицы через adrci. Чтобы увидеть поля "таблицы", используем команду:
adrci>> describe alert_ext
Name Type NULL?
----------------------------- --------------- -----------
ORIGINATING_TIMESTAMP timestamp
NORMALIZED_TIMESTAMP timestamp
ORGANIZATION_ID text(65)
COMPONENT_ID text(65)
HOST_ID text(65)
HOST_ADDRESS text(17)
MESSAGE_TYPE number
MESSAGE_LEVEL number
MESSAGE_ID text(65)
MESSAGE_GROUP text(65)
CLIENT_ID text(65)
MODULE_ID text(65)
PROCESS_ID text(33)
THREAD_ID text(65)
USER_ID text(65)
INSTANCE_ID text(65)
DETAILED_LOCATION text(161)
UPSTREAM_COMP_ID text(101)
DOWNSTREAM_COMP_ID text(101)
EXECUTION_CONTEXT_ID text(101)
EXECUTION_CONTEXT_SEQUENCE number
ERROR_INSTANCE_ID number
ERROR_INSTANCE_SEQUENCE number
MESSAGE_TEXT text(2049)
MESSAGE_ARGUMENTS text(129)
SUPPLEMENTAL_ATTRIBUTES text(129)
SUPPLEMENTAL_DETAILS text(129)
PARTITION number
RECORD_ID number
FILENAME text(513)
PROBLEM_KEY text(65)
Теперь, когда информация структурирована, можно искать точно то, что требуется. Представим, что в alert.log требуется найти строки, содержащие определенное значение в поле. Вот пример:
adrci>> show alert -p "module_id='DBMS_SCHEDULER'"
Эта команда покажет все строки, записанные процессом, у которого module_id равен dbms_scheduler. Также можно использовать оператор неравенства (не содержит DBMS_SCHEDULER):
adrci>>show alert -p "module_id != 'DBMS_SCHEDULER'"
Подобным образом можно использовать поиск на примерное совпадение с шаблоном:
adrci>>show alert -p "module_id like '%SCHEDULER'"
Команда spool работает точно так же, как ее тезка из SQL*Plus. Вывод команды можно записать в файл:
adrci>> spool a
adrci>> show alert -tail 50
adrci>> spool off
Будет создан файл (a.ado), содержащий последние 50 строк из alert.log. Приятной особенностью данной опции является возможность получить из alert.log сообщения определенного типа. Если из alert.log требуется получить сообщения о Streams, можно использовать следующую команду:
adrci> show alert -p "message_text like '%STREAM%'"
Так же можно посмотреть все трассовые файлы, сгенерированные в каталоге ADR Base из командной строки adrci:
adrci>> show tracefile
Указанная команда выведет список всех трассовых файлов, сгенерированных в каталоге ADR. Для вывода трассовых файлов определенного типа (например, "reco") в обратном хронологическом порядке, выполним:
adrci>>show tracefile %reco% -rt
18-JUL-07 22:59:50 diag\rdbms\lapdb11\lapdb11\trace\lapdb11_reco_4604.trc
12-JUL-07 09:48:23 diag\rdbms\lapdb11\lapdb11\trace\lapdb11_reco_4236.trc
11-JUL-07 10:30:22 diag\rdbms\lapdb11\lapdb11\trace\lapdb11_reco_3256.trc
Утилита adrci предоставляет множество других опций для самого эффективного просмотра журнала alert.log и связанных с ним файлов. Полное описание утилиты adrci доступно в документации.