В базе данных Oracle Database 11g и 12c используется встроенная инфраструктура диагностики сбоев, которая помогает обнаруживать, диагностировать ошибки и разрешать проблемы в базе данных. Эта инфраструктура сосредоточена на перехвате и разрешении критичных ошибок, таких как повреждение данных и ошибки в коде базы данных. Целью является проактивное (упреждающее) обнаружение проблем и ограничение повреждений баз данных при сокращении времени диагностики и разрешения проблем. Средство диагностики сбоев также содержит элементы, которые облегчают взаимодействие со службой поддержки Oracle. Ниже перечислены ключевые компоненты новой инфраструктуры диагностики сбоев.
- Automatic Diagnostic Repository. Этот основанный на файлах репозиторий предназначен для хранения данных диагностики базы данных. Обращаться к ADR можно из командной строки или диспетчера Enterprise Manager. Помимо многих прочих вещей он включает файлы трассировки, журналы сигналов тревоги и отчеты монитора работоспособности. Каждый экземпляр базы данных имеет свой собственный домашний каталог ADR, но структура каталогов унифицирована между экземплярами и продуктами, что позволяет службе поддержки Oracle сравнивать и анализировать диагностические данные множества продуктов и экземпляров. Немедленно после возникновения проблемы в базе данных диагностическая информация захватывается и сохраняется внутри ADR. Данные диагностики используются для отправки в службу поддержки Oracle того, что называется пакетами инцидентов (incident packages).
- ADR Command Interpreter (ADRCI). Инструмент командной строки для управления диагностической информацией, создания и управления отчетами об инцидентах.
- Health Monitor. Этот инструмент запускает автоматическую диагностику после ошибок базы данных. Запускать проверку работоспособности базы данных можно также вручную.
- Support Workbench. Это мастер Enterprise Manager, который помогает диагностировать критические ошибки, обрабатывает и пакетирует диагностические данные для отправки в службу поддержки Oracle и заполнения запросов на техническое обслуживание.
- Incident packaging service. Это новый инструмент, позволяющий легко создавать, редактировать и модифицировать информацию об инцидентах в физические пакеты для отправки в службу поддержки Oracle для диагностики.
- Data Recovery Advisor. Этот инструмент автоматически диагностирует сбои данных, такие как потеря или повреждение файлов данных, и подсказывает соответствующие опции восстановления.
- SQL Repair Advisor. Это новый инструмент, генерирующий сбойный оператор SQL вместе с рекомендациями по его исправлению.
- SQL Test Case Builder. Этот инструмент помогает службе поддержки Oracle воспроизвести сбой.
Automatic Diagnostic Repository
Экземпляры базы данных, подобно другим продуктам и компонентам Oracle, хранят различные типы диагностических данных в ADR. К ADR можно обратиться всегда, даже при остановленном экземпляре, что позволяет некоторым сравнивать ADR с черным ящиком самолета, который позволяет диагностировать причины авиакатастрофы.
Настройка каталога Automatic Diagnostic Repository
Местоположение ADR настраивается с помощью параметра инициализации DIAGNOSTIC_DEST. Установка этого параметра означает, что вам не придется устанавливать такие традиционные параметры инициализации, как CORE_DUMP_DEST.
Если опустить параметры DIAGNOSTIC_DEST, то база данных назначит местоположение базового репозитория ADR так, как описано ниже.
- Если установлена переменная
ORACLE_BASE, то базой ADR станет каталог, который был назначен дляORACLE_BASE. - Если переменная
ORACLE_BASEне установлена, то значением параметраDIAGNOSTIC_DESTпо умолчанию станет$ORACLE_HOME/log.
Параметр DIAGNOSTIC_DEST устанавливает местоположение базы ADR на сервере. Домашний каталог ADR настраивается для каждого индивидуального экземпляра базы данных. База ADR может состоять из множества домашних каталогов ADR, по одному для каждого экземпляра продукта Oracle.
Домашний каталог ADR связан с базой ADR. Вот как выглядит общая структура домашнего каталога ADR, начиная с базы ADR:
diag/product_type/product_id/instance_id
Итак, если ваша база данных имеет имя и SID-идентификатор orcl1, а базой ADR является /u01/app/oracle, то домашний каталог ADR для базы orcl1 будет выглядеть так:
/u01/app/oracle/diag/rdbms/orcl1/orcl1
Структура ADR
Различные подкаталоги домашнего каталога ADR содержат различные типы диагностических данных, вроде журналов сигналов тревоги, отчетов Health Monitor, отчетов об инцидентах и файлов трассировки ошибок. Обратите внимание, что в Oracle Database 11g есть два типа журналов сигналов тревоги: нормальный текстовый файл и журнал в формате XML. Для просмотра различных подкаталогов ADR экземпляра можно опросить представление V$DIAG_INFO:
SQL> select * from v$diag_info;
INST_ID NAME VALUE
------- -------------- ----------------------------------------------
1 Diag Enabled TRUE
1 ADR Base /u01/app/oracle
1 Diag Trace /u01/app/oracle/diag/rdbms/orcl2/orcl2/trace
1 Diag Alert /u01/app/oracle/diag/rdbms/orcl2/orcl2/alert
1 Diag Incident /u01/app/oracle/diag/rdbms/orcl2/orcl2/incident
1 Diag Cdump /u01/app/oracle/diag/rdbms/orcl2/orcl2/cdump
1 Health Monitor /u01/app/oracle/diag/rdbms/orcl2/orcl2/hm1
1 Def Trace File /u01/app/oracle/diag/rdbms/orcl2/orcl2/trace
/orcl2_ora_4813.trc
1 Active Problem Count 2
1 Active Incident Count 4
11 rows selected.
SQL>
Следующие каталоги требуют пояснений:
ADR Base— базовый каталог ADR;ADR Home— домашний каталог ADR для экземпляра;Diag Trace— содержит текстовый журнал сигналов тревоги;Diag Alert— содержит журнал сигналов тревоги в формате XML;Diag Incident— каталог, содержащий созданные вами пакеты инцидентов.
ADRCI
ADRCI — это новая утилита командной строки, помогающая взаимодействовать с ADR. Утилиту ADRCI можно использовать для просмотра диагностических данных, создания пакетов инцидентов и просмотра отчетов Health Monitor.
ADRCI вызывается вводом adrci в командной строке:
$ adrci ADRCI: Release 11.1.0.6.0 - Beta on Thu Sep 27 16:59:27 2007 Copyright (c) 1982, 2007, Oracle. All rights reserved. ADR base = "/u01/app/oracle" adrci>
Наберите команду help, чтобы увидеть команды, которые можно использовать в приглашении ADRCI. Для выхода из утилиты ADRCI введите exit или quit.
Утилиту ADRCI можно также применять в пакетном режиме, который позволяет использовать команды ADRCI внутри сценариев оболочки и командных файлов. При запуске ADRCI в пакетном режиме должны применяться параметры командной строки exec и script:
adrci exec 'команда [; команда]. . . ' adrci script=имя_файла
Домашний путь ADR
При наличии нескольких экземпляров Oracle, все они будут текущими, когда вы входите в ADRCI. Есть некоторые команды ADRCI, которые работают, когда есть несколько домашних каталогов ADRCI, но другие требуют, чтобы текущим был только один экземпляр. По умолчанию после запуска ADRCI домашний путь ADRCI получает значение null. Когда домашний путь ADRCI равен null, все домашние каталоги ADR являются текущими. Вот пример:
adrci> show homes adrci> ADR Homes: diag/rdbms/orcl/orcl diag/rdbms/orcl2/orcl2 diag/rdbms/eleven/eleven diag/rdbms/nina/nina adrci>
Все домашние каталоги ADR всегда показаны относительно базы ADR. Таким образом, если базой ADR является /u01/app/oracle, а именем и SID базы — orcl1, то полный путь к домашнему каталогу ADR должен выглядеть так:
/u01/app/oracle/diag/rdbms/orcl1/orcl1
В приведенном примере домашний путь ADR указывает на то, что несколько домашних каталогов ADR являются текущими. С помощью команды SET HOMEPATH путь ADR можно установить так, чтобы он указывал на единственный экземпляр.
Совет. После входа в ADRCI всегда первым делом устанавливайте домашний путь:
adrci> set homepath diag/rdbms/orcl1/orcl1 adrci> show homes ADR Homes: diag/rdbms/orcl1/orcl1 adrci>
Теперь, если ввести команду adrci, база данных извлечет диагностические данные только из экземпляра orcl1.
Просмотр журнала сигналов тревоги
Журнал сигналов тревоги просматривается следующим образом:
adrci> show alert –tail 2008-10-17 16:49:50.579000 - Starting background process FBDA Starting background process SMCO . . . Completed: ALTER DATABASE OPEN adrci>
Перед запуском этой команды удостоверьтесь в корректной настройке домашнего пути. Вернуться в приглашение ADRCI можно, нажав <Ctrl+C>.
Помимо ADRCI, есть и другие возможности для просмотра содержимого журнала сигналов тревоги. Просмотреть традиционный текстовый журнал можно, зайдя в каталог, указанный в поле Diag Trace представления V$DIAG_INFO. Естественно, просматривать содержимое журнала сигналов можно и через домашнюю страницу диспетчера Enterprise Manager. Для этого просто щелкните на ссылке Alert Log Contents (Содержимое журнала сигналов тревоги) в группе Related Links (Связанные ссылки).
Служба пакетирования инцидентов
Диагностическая инфраструктура Oracle основана на двух ключевых концепциях: проблемах и инцидентах. Проблема — это критичная ошибка, например, сопровождаемая сообщением ORA-4031, которая возникает при нехватке разделяемой памяти. Инцидент — отдельное проявление проблемы; таким образом, если проблема проявляется многократно, каждое такое событие помечается отдельным инцидентом со своим уникальным идентификатором инцидента. Когда инцидент случается в базе данных, база собирает диагностические данные о нем, прикрепляет идентификатор инцидента к событию и сохраняет его в подкаталоге ADR. Инцидент связывается с проблемой посредством ключа проблемы. База данных автоматически создает инцидент при возникновении проблемы, но можно также создавать свои собственные инциденты, когда необходимо сообщить об ошибках, которые не возникают, и послать критичный сигнал тревоги службе поддержки Oracle.
ADR использует контролируемую по объему систему инцидентов, которая допускает ограниченное количество инцидентов для каждой данной проблемы. Это делается, чтобы избежать затопления ADR большим количеством информации об идентичных инцидентах. База данных позволяет каждой проблеме регистрировать в журналах диагностические данные только для определенного числа инцидентов в ADR. Например, после появления 25 инцидентов по причине одной и той же проблемы в течение дня ADR не станет фиксировать новые инциденты с тем же ключом проблемы. ADR использует два типа политики сохранения: один управляет хранением метаданных инцидента, а другой — хранением инцидента и файлов дампа. По умолчанию ADR сохраняет метаданные инцидента в течение месяца, а инцидент и файлы дампа — в течение одного года.
Просмотр инцидентов
Проверить текущее состояние инцидента можно с помощью команды SHOW INCIDENT, как показано ниже:
adrci> show incident ADR Home = /u01/app/oracle/diag/rdbms/orcl1/orcl1: **************************************************************** INCIDENT_ID PROBLEM_KEY CREATE_TIME ------------ ----------------- ----------------------------------- 17060 ORA 1578 2007-09-25 17:00:18.019731 -04:00 14657 ORA 600 2007-09-09 07:01:21.395179 -04:00 2 rows fetched adrci>
Детальную информацию об инциденте можно просмотреть, выполнив команду SHOW INCIDENT...MODE DETAIL, показанную ниже:
adrci> show incident -mode DETAIL -p "incident_id=1234"
Приведенная команда показывает детальную информацию об инциденте с идентификатором 1234.
Пакет инцидента содержит диагностические данные, касающиеся одного или более инцидентов (охватывающих одну или более проблем). Пакет инцидентов позволяет легко передавать диагностическую информацию службе поддержки Oracle. Пакеты инцидентов создаются либо в Support Workbench, либо из командной строки с использованием инструмента ADRCI. Пакет инцидентов отправляется в службу поддержки Oracle, когда требуется помощь Oracle в разрешении проблем и инцидентов. После создания пакета инцидентов можно отредактировать пакет, добавляя к нему и удаляя из него диагностические файлы.
Создание пакета инцидентов
Служба пакетирования инцидентов ( incident packaging service — IPS) позволяет создать пакет инцидентов. С помощью IPS осуществляется сбор диагностических данных об ошибке, таких как файлы трассировки, файлы дампов, отчеты о состоянии работоспособности системы, тестовые сценарии SQL и прочая информация, и пакетирование этих данных в zip-файл для отправки в службу поддержки Oracle. IPS отслеживает и собирает диагностическую информацию об инцидентах, используя номера инцидентов. Перед передачей zip-файла в службу поддержки Oracle можно добавлять, удалять или прочищать диагностические файлы. Ниже перечислены ключевые моменты, которые следует знать относительно пакетов инцидентов.
- Пакет инцидентов — логическая сущность, содержащая только метаданные проблемы. По умолчанию база данных включает в zip-пакет первые и последние три
инцидента для проблемы. - Zip-файл, который вы в действительности отправляете Oracle, конечно, является физическим пакетом и содержит диагностические файлы, специфицированные метаданными в логическом пакете инцидентов.
- В службу поддержки Oracle можно отправлять инкрементные или полные zip-файлы.
Рассмотрим шаги, которые потребуется выполнить для создания службы пакетирования инцидентов, используя команды IPS в ADRCI.
1. Создайте логический пакет, который будет использован для хранения метаданных инцидента. Создать можно пустой или непустой логический пакет. Непустой пакет требует указания номера инцидента, номера или ключа проблемы, и автоматически включает диагностическую информацию об указанном инциденте или проблеме. В следующем примере создается пустой пакет с помощью команды IPS CREATE PACKAGE:
adrci> ips create package Created package 4 without any contents, correlation level typical adrci>
Чтобы создать непустой пакет, укажите номер инцидента:
adrci> ips create package incident 17060 Created package 5 based on incident id 17060, correlation level typical adrci>
Можно также создать пакет, охватывающий интервал времени:
adrci> ips create package time '2007-09-20 00:00:00 -12:00' to '2007-09-30 00:00:00 -12:00'
2. Если на первом шаге был создан пустой логический пакет, в него необходимо добавить диагностические данные:
adrci> ips add incident 17060 package 4 Added incident 17060 to package 4 adrci>
Добавление диагностических файлов к пакету производится следующим образом:
adrci> ips add file package
3. Сгенерируйте физический пакет, который будет передан в службу поддержки Oracle:
adrci> ips generate package 4 in /u01/app/oracle/support Generated package 4 in file /u01/app/oracle/diag/IPSPKG_20070929163401_COM_1.zip, mode complete adrci>
COM_1 в имени файла говорит о том, что это полный файл, а не инкрементный. Для создания инкрементного физического пакет инцидентов служит следующая команда:
adrci> ips generate package 4 in /u01/app/oracle/diag incremental Generated package 4 in file /u01/app/oracle/diag/IPSPKG_20070929163401_INC_2.zip, mode incremental adrci>
4. Прежде чем отправлять пакет инцидентов в службу поддержки Oracle для диагностики и получения помощи, нужно формально финализировать пакет инцидентов, как показано ниже:
adrci> ips finalize package 4 Finalized package 4 adrci>
После этого финализированный zip-файл можно пересылать в службу поддержки Oracle, загрузив его вручную. В следующем разделе данной статьи ниже, где пойдет речь о Support Workbench, будет показано, как автоматизировать передачу пакетов инцидентов в службу поддержки Oracle.
Support Workbench
Автоматизированное рабочее место поддержки (Support Workbench), к которому можно обратиться из Enterprise Manager, позволяет автоматизировать управление инцидентами, включая заполнение запросов на обслуживание в Oracle Support и отслеживание хода выполнения таких запросов. Помимо просмотра проблем и инцидентов, можно также генерировать диагностические данные о проблеме и запускать советники для решения проблемы. С помощью Support Workbench легко создавать пакеты инцидентов и отправлять их в службу поддержки Oracle.
Чтобы включить Support Workbench для загрузки файлов IPS в службу поддержки Oracle, понадобится инсталлировать и сконфигурировать Oracle Configuration Manager (Диспетчер конфигурации Oracle). Этот диспетчер можно установить во время инсталляции программного обеспечения Oracle, как показано на рисунке 1 ниже:
Установить и сконфигурировать Oracle Configuration Manager можно и после инсталляции сервера, вызывая для этого Oracle Universal Installer.
В следующих разделах статьи будут подведены итоги по применению Support Workbench для решения проблем.
Совет. Хотя база данных автоматически отслеживает все критичные ошибки, сохраняя данные в ADR, через Support Workbench можно также произвести созданную пользователем проблему для ошибок, которые не трактуются базой данных как критичные. Для этого нужно щелкнуть на ссылке Create User-Reported Problems (Создать проблемы, сообщаемые пользователем) в группе Related Links (Связанные ссылки).
Просмотр сигналов об ошибках
На домашней странице Support Workbench можно просматривать информацию о нерешенных проблемах. Критичные сигналы проверяются на странице Database Home (Домашняя страница базы данных) в разделе Diagnostic Summary (Диагностическая сводка), щелкая на ссылке Active Incidents (Активные инциденты), либо перейдя в раздел Critical Alerts (Критичные сигналы) внутри раздела Alerts (Сигналы). Чтобы получить доступ к Support Workbench, щелкните на ссылке Software and Support (Программное обеспечение и поддержка), а затем — на ссылке Support Workbench (Автоматизированное рабочее место поддержки) внутри раздела Support (Поддержка). На рисунке 2 ниже показана страница Support Workbench.
На домашней странице Support Workbench в списке View (Показать) выберите вариант All (Все) для просмотра всех проблем.
Просмотр подробностей о проблемах
Чтобы просмотреть детальную информацию по любой проблеме, щелкните на кнопке View Incident Details (Просмотреть детальную информацию об инциденте) на странице Incidents (Инциденты).
Сбор дополнительных данных
Помимо автоматического сбора диагностических данных после возникновения в базе данных критичной ошибки, Support Workbench также используется для выполнения проверки работоспособности и сбора диагностических данных. Чуть позже, в разделе “Запуск проверки работоспособности”, будут даны дополнительные пояснения на эту тему.
Создание запросов службы
Через интерфейс Support Workbench можно создавать запросы службы в формате MetaLink. Для дальнейших ссылок имеет смысл записать номер запроса службы.
Создание пакетов инцидентов
Для создания и отправки пакетов инцидентов используется либо метод Quick Packaging (Быстрое пакетирование), либо Custom Packaging (Настраиваемое пакетирование). Метод Quick Packaging проще, но не позволяет редактировать или подстраивать диагностические данные, которые отправляются в службу поддержки Oracle. Метод Custom Packaging более сложен, однако обеспечивает возможность тонкой настройки пакета инцидента.
Ниже перечислены шаги, которые необходимо предпринять для создания пакета инцидента и отправки его в службу поддержки Oracle посредством метода Custom Packaging.
- На странице Incident Details (Детальная информация об инциденте) щелкните на ссылке Package (Пакетировать).
- На странице Select Packaging Mode (Выберите режим пакетирования) выберите вариант Custom Packaging (Настраиваемое пакетирование) и щелкните на кнопке OK.
- На странице Select Package (Выберите пакет) выберите опцию Create New Package (Создать новый пакет). Введите имя пакета и щелкните на кнопке OK.
- Support Workbench отобразит страницу Customize Package (Настройка пакета), подтверждая создание пакета. Страница Customize Package показана на рисунке 3 ниже:
- Завершив задачи вроде редактирования содержимого пакета или добавления диагностических данных, финализируйте пакет щелчком на ссылке Finish Contents Preparation (Завершить подготовку содержимого) в подразделе Send to Oracle Support (Отправить в службу поддержки Oracle) раздела Packaging Tasks (Задачи пакетирования) на странице Customize Package.
- Сгенерируйте файл для загрузки, щелкнув на ссылке Generate Upload File (Сгенерировать файл для загрузки). Щелкните на опции Immediately (Немедленно) или Later (Позже), а затем на кнопке Submit (Отправить) для планирования отправки пакета об инциденте в службу поддержки Oracle.
- После отправки пакета в службу поддержки Oracle служба IPS обрабатывает zip-файл и подтверждает его, прежде чем вернуть на страницу Customize Package. Щелкните на кнопке Send to Oracle (Отправить в Oracle) для отправки подтвержденного zip-файла Oracle. Затем потребуется заполнить мандат MetaLink и указать, нужно ли создать новый запрос обслуживания. Щелкните на кнопке Submit для отправки файла в службу поддержки Oracle.
Отслеживание запросов на обслуживание
После отправки пакета инцидента в службу поддержки Oracle можно добавлять к нему новые инциденты. Кроме того, можно также позволить другим администратором баз данных в организации получать детали пакета инцидента, добавив комментарии в журнал активности проблемы.
Реализация восстановлений и закрытие инцидентов
Если рекомендации по восстановлению включают использование советника Oracle, такое восстановление можно выполнить непосредственно из Support Workbench, например, запустить Data Recovery Advisor и SQL Repair Advisor.
Разрешенный инцидент можно закрыть или позволить Oracle очистить его; по умолчанию Oracle очищает все инциденты по истечении 30 дней.
Health Monitor
Монитор работоспособности Health Monitor представляет собой диагностический каркас базы данных Oracle, который автоматически запускает диагностические проверки в том случае, если база данных сталкивается с серьезными ошибками. В дополнение к реактивным проверкам при желании можно запускать ручные проверки. Для запуска ручных проверок работоспособности базы данных применяется либо Enterprise Manager, либо пакет DBMS_HM. В ответ на реактивные или ручные проверки база данных проверяет такие компоненты, как память и транзакционная целостность, и предоставляет отчеты о результатах.
Следующий запрос к представлению V$HM_CHECK показывает различные типы проверок работоспособности, которые могут быть выполнены:
SQL> SELECT name, description FROM v$hm_check;
NAME DESCRIPTION
ИМЯ ОПИСАНИЕ
--------------------- ---------------------------
HM Test Check Check for HM Functionality
Проверка HM Проверка функциональности HM
DB Structure Integrity Check Checks integrity of all Database files
Целостность структуры БД Проверка целостности всех файлов базы данных
Data Block Integrity Check Checks integrity of a datafile block
Целостность блоков данных Проверка целостности блоков файлов данных
Redo Integrity Check Checks integrity of redo log content
Целостность данных повторного Проверка целостности содержимого журналов
выполнения повторного выполнения
Logical Block Check Checks logical content of a block
Логические блоки Проверка логического содержимого блока
Transaction Integrity Check Checks a transaction for corruptions
Целостность транзакций Проверка транзакции на предмет разрушения
Undo Segment Integrity Check Checks integrity of an undo segment
Целостность сегмента отмены Проверка целостности сегмента отмены
All Control Files Check Checks all control files in the database
Все управляющие файлы Проверка всех управляющих файлов в базе данных
CF Member Check Checks a multiplexed copy of the control file
Члены управляющих файлов Проверка мультиплексированной копии
управляющего файла
All Datafiles Check Checks for all datafiles in the database
Все файлы данных Проверка всех файлов данных в базе данных
Single Datafile Check Checks a datafile
Одиночный файл данных Проверка отдельного файла данных
Log Group Check Checks all members of a log group
Группа журналов Проверка всех членов группы журналов
Log Group Member Check Checks a particular member of a log group
Член группы журналов Проверка отдельного члена группы журналов
Archived Log Check Checks an archived log
Архивный журнал Проверка архивного журнала
Redo Revalidation Check Checks redo log content
Повторная проверка достоверности Проверка содержимого журнала
данных повторного выполнения повторного выполнения
IO Revalidation Check Checks file accessibility
Повторная проверка достоверности Проверка доступности файлов
ввода-вывода
Block IO Revalidation Check Checks file accessibility
Повторная проверка достоверности Проверка доступности файлов
блочного ввода-вывода
Txn Revalidation Check Revalidate corrupted txn
Повторная проверка Повторная проверка разрушенного txn
достоверности txn
Failure Simulation Check Creates dummy failures
Эмуляция сбоев Создание фиктивных сбоев
Dictionary Integrity Check Checks dictionary integrity
Целостность словаря Проверка целостности словаря
21 rows selected.
SQL>
Все проверки, кроме проверки целостности данных повторного выполнения и перекрестной проверки данных, можно запускать, когда база данных открыта или находится в смонтированном режиме.
Запуск проверки работоспособности Health Monitor
Запуск проверки работоспособности базы данных осуществляется из интерфейса Health Monitor в консоли Enterprise Manager, к которому можно добраться, щелкнув на вкладке Checkers (Средства проверки) на странице Advisor Central (Центр советников). Запустить проверку работоспособности можно также с использованием пакета DBMS_HM. Следующий пример демонстрирует запуск проверки работоспособности с помощью процедуры RUN_CHECK:
BEGIN dbms_hm run_check ( check_name => 'Transaction Integrity Check', run_name => 'testrun1', input_params => 'TXN_ID=9.44.1'); END; / PL/SQL procedure successfully completed. SQL>
В приведенном выше примере для указанной транзакции запускается проверка транзакционной целостности.
Просмотр результатов проверки работоспособности Health Monitor
Health Monitor хранит все результаты запусков в ADR. Для просмотра рекомендаций и обнаружений проверки работоспособности можно опросить представления V$HM_RECOMMENDATION, V$HM_FINDING и V$HM_RUN. Однако более простой способ просмотра результатов проверки работоспособности состоит в вызове функции GET_RUN_REPORT, как показано в следующем примере:
SQl> SET LONG 100000
SQL> SELECT dbms_hm.get_run_report('TestCheck1') FROM DUAL;
DBMS_HM.GET_RUN_REPORT('TESTCHECK1')
------------------------------------------------------------
Basic Run Information
Run Name : TestCheck1
Run Id : 42721
Check Name : Dictionary Integrity Check
Mode : MANUAL
Status : COMPLETED
Start Time : 2008-10-03 16:40:47.464989 -04:00
End Time : 2008-10-03 16:41:23.068746 -04:00
Error Encountered : 0
Source Incident Id : 0
Number of Incidents Created : 0
Input Paramters for the Run
TABLE_NAME=ALL_CORE_TABLES
CHECK_MASK=ALL
Run Findings And Recommendations
Finding
Finding Name : Dictionary Inconsistency
Finding ID : 42722
Type : FAILURE
Status : OPEN
Priority : CRITICAL
Message : SQL dictionary health check:
dependency$.dobj# fk 126 on object DEPENDENCY$ failed
Message : Damaged rowid is AAAABnAABAAAOiHABI –
description: No further damage description available
SQL>
Для просмотра результатов проверки Health Monitor можно также воспользоваться ADRCI. Для начала выполните команду SHOW HM_RUN, чтобы увидеть результаты проверки работоспособности:
adrci> SHOW hm_run **************************************************************** HM RUN RECORD 2131 **************************************************************** RUN_ID 42721 RUN_NAME TestCheck1 CHECK_NAME Dictionary Integrity Check NAME_ID 24 MODE 0 START_TIME 2008-10-03 16:40:47.4649 -04:00 RESUME_TIME END_TIME 2008-10-03 16:41:23.0687 -04:00 MODIFIED_TIME 2008-10-03 16:41:59.7867 -04:00 TIMEOUT 0 FLAGS 0 STATUS 5 SRC_INCIDENT_ID 0 NUM_INCIDENTS 0 ERR_NUMBER 0 REPORT_FILE /u01/app/oracle/diag/rdbms/orcl2/orcl2/hm/HMREPORT_TestCheck1 2131 rows fetched adrci>
В этом примере команда SHOW HM_RUN показывает имя файла отчета в столбце REPORT_FILE. Увидев имя файла, можете просмотреть сам отчет, выполнив команду SHOW REPORT HM_RUN, как показано ниже:
adrci> SHOW REPORT hm_run TestCheck1
Если столбец REPORT_FILE показывает значение NULL, сначала потребуется сгенерировать файл отчета:
adrci> CREATE REPORT hm_run TestCheck1
Сгенерировав отчет, как показано выше, с помощью команды SHOW REPORT HM_RUN можно просмотреть его содержимое.
Восстановление операторов SQL с помощью SQL Repair Advisor
SQL Repair Advisor (Советник по исправлению SQL) — это новый инструмент, который помогает исследовать ситуации, когда оператор SQL завершается критической ошибкой. Например, если имеется известная ошибка в коде, которая служит причиной критической ошибки при его выполнении, можно применить SQL Repair Advisor. В противоречии с его названием, SQL Repair Advisor на самом деле не переписывает и не восстанавливает сбойный оператор SQL, а рекомендует исправление, которое поможет этому оператору обойти ошибку. Другими словами, советник предлагает обходной путь для выполнения проблемного оператора SQL. Обратите внимание, что исправление SQL в этом случае очень похоже на профиль SQL, и его применение изменяет план выполнения запроса. Вызывать SQL Repair Advisor можно из Support Workbench или же с помощью пакета DBMS_SQLDIAG. Оба метода рассматриваются в последующих разделах этой статьи.
Вызов SQL Repair Advisor из Support Workbench
Для вызова SQL Repair Advisor из Support Workbench выполните следующие шаги.
- На домашней странице Support Workbench щелкните на идентификаторе проблемы, которую вы пытаетесь решить.
- На странице Problem Details (Детальная информация о проблеме) щелкните на сообщении о проблеме от сбойного оператора SQL.
- В разделе Investigate and Resolve (Исследование и разрешение) на вкладке Self Service (Самообслуживание) щелкните на SQL Repair Advisor (Советник по исправлению SQL).
- Выберите расписание для запуска советника и щелкните на кнопке Submit (Отправить). Щелкните на View (Просмотреть) на странице результатов SQL Repair Advisor для просмотра страницы Report Recommendations (Отчет о рекомендациях).
- Щелкните на ссылке Implement (Реализовать), если хотите, чтобы советник реализовал выданные рекомендации. После реализации рекомендаций советник SQL Repair Advisor отобразит страницу подтверждения.
При переходе на новый выпуск базы данных можно легко сбросить исправления, примененные через SQL Repair Advisor.
Вызов SQL Repair Advisor через пакет DBMS_SQLDIAG
В следующем примере демонстрируется создание задачи SQL Repair Advisor и применение исправления SQL, рекомендованной советником для исправления дефектного оператора SQL.
Несколько слов о следующем примере
Следующий пример был позаимствован из материалов курса Oracle University. Если вы попытаетесь выполнить пример как он есть, то не увидите никаких ошибок. В курсе Oracle ошибка вызывается использованием механизма управления исправлений, который позволяет отключать исправления ошибок, связанных с оптимизатором. Управление этим механизмом осуществляется установкой недокументированного параметра инициализации _FIX_CONTROL.
Для нахождения ошибок, исправления которых можно отключить, можно запросить представление V$SESSION_FIX_CONTROL. Для этого понадобится выполнить запрос SELECT DISTINCT BUGNO FROM V$SESSION_FIX_CONTROL. Когда вы решите, исправления каких ошибок нужно отключить в целях тестирования, можете выдать запрос ALTER SESSION SET "_FIX_CONTROL"= '4728348:OFF';, чтобы временно отключить исправление ошибки на время тестирования кода этого примера.
По завершении тестирования не забудьте выполнить оператор ALTER SESSION SET "_FIX_CONTROL"='4728348:ON';, чтобы вновь включить исправление ошибки. Как видите, это довольно запутанная процедура, помимо того, что она требует использования недокументированного параметра на свой страх и риск, без помощи службы поддержки Oracle. Несмотря на упоминание стратегии для тестирования следующего кода, возможно, разумней не использовать никаких недокументированных параметров инициализации, поскольку это может принести потенциальный ущерб базе данных.
Предположим, что приведенный ниже оператор SQL идентифицирован как причина возникновения критичной ошибки в базе данных:
SQL> DELETE FROM t t1 WHERE t1.a = 'a' AND rowid <> (select max(rowid) FROM t t2 WHERE t1.a= t2.a AND t1.b = t2.b AND t1.d=t2.d);
Для устранения проблемы можно воспользоваться SQL Repair Advisor, выполнив следующие шаги.
1. Запустите процедуру CREATE_DIAGNOSTIC_TASK из пакета DBMS_SQLDIAG, чтобы создать задачу SQL Repair Advisor:
SQL> declare 2 report_out clob; 3 task_id varchar2(50); 4 begin 5 task_id := dbms_sqldiag.create_diagnosis_task( 6 sql_text=>' delete from t t1 where t1.a = ''a'' and rowid <> (select max(rowid) from t t2 where t1.a= t2.a and t1.b = t2.b and t1.d=t2.d)',
7 task_name =>'test_task1', 8 problem_type=>dbms_sqldiag.problem_type_compilation_error); 9* end; SQL> / PL/SQL procedure successfully completed. SQL>
Здесь в качестве значения параметра PROBLEM_TYPE в процедуре CREATE_DIAGNOSTIC_TASK было выбрано PROBLEM_TYPE_COMPILATION. Этот параметр можно также установить в PROBLEM_TYPE_EXECUTION.
2. Запустите процедуру SET_TUNING_PARAMETERS для применения параметров для новой задачи, созданной на предыдущем шаге:
SQL> exec dbms_sqltune.set_tuning_task_parameter('task_id,
'-SQLDIAG_FINDING_MODE', dbms_sqldiag.SQLDIAG_FINDING_FILTER_PLANS);
3. Выполните следующую задачу после указания имени задачи в параметре процедуры EXECUTE_DIAGNOSTIC_TASK:
SQL> exec dbms_sqlldiag.execute_diagnosis_task('test_task1');
PL/SQL procedure successfully completed.
SQL>
Обратите внимание, что для выполнения процедуры EXECUTE_DIAGNOSTIC_TASK потребуется только параметр TASK_NAME.
4. Отчет о диагностической задаче можно получить с помощью функции REPORT_DIAGNOSTIC_TASK:
SQL> declare rep_out clob;
2 begin
3 rep_out := dbms_sqldiag.report_diagnosis_task
4 ('test_task1',dbms_sqldiag.type_text);
5 dbms_output.put_line ('Report : ' || rep_out);
6* end;
SQL> /
Report : GENERAL INFORMATION
SECTION
-------------------------------------------------
Tuning Task Name : test_task1
Tuning Task Owner : SYS
Tuning Task ID : 3219
Workload Type : Single SQL Statement
Execution Count : 1
Current Execution : EXEC_3219
Execution Type : SQL DIAGNOSIS
Scope : COMPREHENSIVE
Time Limit(seconds) : 1800
Completion Status : COMPLETED
Started at : 10/20/2007 06:33:42
Completed at : 10/20/2007 06:36:45
Schema Name : SYS
SQL ID : 44wx3x03jx01v
SQL Text : delete from t t1 where t1.a = 'a'
and rowid <> (select max(rowid)
from t t2 where t1.a= t2.a
and t1.b = t2.b and t1.d=t2.d)
. . .
PL/SQL procedure successfully completed.
SQL>
5. Исправление, рекомендованное SQL Repair Advisor, принимается с использованием процедуры ACCEPT_SQL_PATCH:
SQL> exec dbms_sqldiag.accept_sql_patch ( task_name => 'test_task1', task_owner => 'SYS')
При выполнении этого оператора SQL после применения предложенного исправления вы увидите другой план выполнения оператора. Используйте представление DBA_SQL_PATCHES для нахождения имен всех рекомендуемых SQL Repair Advisor исправлений. Удаляется исправление с помощью процедуры DROP_SQL_PATCH. Исправление SQL можно также экспортировать в другую базу данных, используя промежуточную таблицу.
SQL Test Case Builder
Быстро создать тестовый сценарий для отправки в службу поддержки Oracle можно в новом построителе сценариев тестирования SQL (SQL Test Case Builder). Этот инструмент предоставляет информацию о запросе SQL, определениях объектов, процедур, функций и пакетов, статистике оптимизатора и настройках параметров инициализации. SQL Test Case Builder создает сценарий SQL, который может выполняться в другой системе для воссоздания объектов базы, имеющихся в исходной базе. Вызывается SQL Test Case Builder с помощью функции DBMS_SQLDIAG.EXPORT_SQL_TESTCASE_DIR_BY_INC. Эта функция сгенерирует тестовый сценарий SQL, соответствующий идентификатору инцидента, переданного функции. Вместо этого можно воспользоваться функцией DBMS_SQLDIAG.EXPORT_SQL_TESTCASE_DIR_BY_TEXT и сгенерировать тестовый сценарий SQL, который соответствует тексту SQL, переданному в качестве аргумента. Однако обычно намного проще обратиться к SQL Test Case Builder со страницы Support Workbench в Enterprise Manager, выполнив для этого следующие шаги.
- Зайдите на страницу Problem Details (Детальная информация о проблеме), щелкнув на идентификаторе соответствующей проблемы.
- Щелкните на Oracle Support (Служба поддержки Oracle).
- Щелкните на Generate Additional Dumps and Test Cases (Сгенерировать дополнительные дампы и сценарии тестирования).
- Щелкните на пиктограмме в столбце Go to Task (Перейти к заданию) на странице Additional Dumps and Test Cases (Дополнительные дампы и сценарии тестирования). В результате будет запущен анализ SQL Test Case Builder для соответствующего оператора SQL.
