Oracle alert log где находится

Обновлено: 04.07.2024

Главная /
Статьи /
Oracle /
Дублирование базы данных с помощью RMAN. Часть 1.

Задания в Oracle9i

В Oracle существует возможность запланировать выполнение определенного набора действий в виде заданий. Задание может, представляет собой хранимую процедуру, анонимный блок PL /SQL, внешнюю процедуру на языке C или Java. Время выполнения может иметь значение любого времени суток и подчинятся заданному интервалу. Это хорошо подходит для переноса тяжёлых в обработке расчётов на менее загруженное ночное время. По умолчанию выполнение заданий выключено. Поэтому надо провести небольшую дополнительную настройку сервера.

Настройка сервера

Для того чтобы задания начались выполняться необходимо, установить параметр инициализации JOB_QUEUE_PROCESSES. Изначально он имеет значение 0 и задаёт максимальное количество фоновых процессов для выполнения заданий. В версии Oracle 9.2 максимальное значение этого параметра может составлять 1000. На практике же обычно можно ограничиться не более 5 процессами. В любом случае вы всегда можете изменить это значение с помощью команды ALTER SYSTEM SET без перезагрузки сервера. Итак, для начала внесем новую строчку в файл инициализации и перезагрузим сервер:

В файле alert.log мы увидим, что в момент, когда стартуют фоновые процессы, у нас появилось новая запись:

Это стартовал новый фоновый процесс CJQ0, так называемый координатор заданий. Что он делает и для чего он нужен, мы рассмотрим чуть ниже, а на этом предварительную настройку сервера можно считать законченной.

Процессы

Итак, процесс координатора заданий запущен, и как можно догадаться из его названия именно этот процесс осуществляет общее управление всеми заданиями. Для начала он выбирает таблицу SYS.JOB$, в которой хранятся параметры заданий. Если среди заданий имеются те, которые будут выполняться в ближайший интервал времени указанный в скрытом параметре _JOB_QUEUE_INTERVAL (по умолчанию его значение составляет 5 секунд), то для них порождаются фоновые процессы очереди заданий Jnnn, которые в свою очередь создают сеансы для непосредственного выполнения запланированных действий. Именно максимальное количество процессов Jnnn, которые могут быть одновременно запущены и отражает настраиваемый параметр JOB_QUEUE_PROCESSES.

После того как выбранным заданиям были выделены процессы Jnnn, координатор выжидает интервал времени, указанный в параметре _JOB_QUEUE_INTERVAL. Процессы заданий в тоже время продолжают работать. После выполнения задания процесс Jnnn считается свободным, и координатор распределяет его на выполнение другого задания. Если такого задания не находится в течение определенного времени, то процесс Jnnn уничтожается. В случае, когда процессов Jnnn не хватает, задание будет выполнено в тот момент времени, когда один из них освободится.

Выставляйте значение параметра JOB_QUEUE_PROCESSES чуть больше максимального количества одновременно запускаемых заданий. Маленькое значение может привести к сдвигу времени выполнения из-за конкуренции за процессы Jnnn. Большое значение к неоправданному запуску этих же процессов в исключительных ситуациях.

Создание заданий

Для управления заданиями в Oracle существует специальный пакет DBMS_JOB. С его помощью над ними можно осуществлять различные действия. Для начала попробуем создать новое задание. В нашем случае для этого, нужно применить следующую процедуру пакета:

Опишем параметры этой процедуры:

JOB - это идентификатор задания. Имеет уникальное значение для каждого задания, генерируемое системной последовательностью. Является выходным параметром. Его лучше запомнить, если потребуются дальнейшие действия над заданиями.

WHAT - тело задания. Представляет собой анонимный PL/SQL блок. Всё что здесь указано, будет выполнено в процессе работы задания. Если вы запускаете только одну процедуру, то можно не заключать её в блок достаточно поставить в конце названия процедуры точку с запятой. Значение WHAT в этом случае автоматически будет помещено в PL/SQL блок. Если процедура имеет строковые параметры, то они обязательно должны заключаться в две одинарные кавычки с каждой стороны. В PL/SQL блоке можно также писать DML и DDL команды, но нельзя производить создание и запуск заданий. Это только приведёт к ошибке ORA-32317. Если же используются ссылки на удалённую базу данных, то они должны явно включать имя и пароль. Анонимные ссылки здесь не поддерживаются. И, наконец, владельцу задания требуется явно предоставить привилегии, на объекты, используемые в теле задания.

NEXT_DATE - дата следующего выполнения задания. Время непосредственно задаётся владельцем или автоматически вычисляется Oracle.

Если вы введёте дату меньше чем текущую, то выполнение задания может начаться немедленно или отложится на неопределённое время. В этом случае попробуйте принудительно запустить задание или повторно изменить этот параметр, это инициирует немедленный запуск задания.

INTERVAL - формула интервала времени. Представляет собой DATE функцию. Именно от её правильного значения будет зависеть дата следующего выполнения задания казанного в столбце NEXT_DATE. Приведём некоторые примеры формулы интервала задания:

Задание будет выполняться ровно в n часов m минут каждого дня.

Задание будет выполняться ровно в n часов m минут последнего дня каждого месяца.

Задание будет выполняться ровно в n часов m минут первого дня каждого месяца.

Учитывайте, что вычисление NEXT_DATE с помощью формулы интервала происходит после выполнения задания. Поэтому всегда учитывайте это время и старайтесь не ставить их на время близкое к окончанию суток из-за возможного неправильного расчёта следующей даты выполнения.

NO_PARSE - флаг разбора PL/SQL. Если его значение равно FALSE разбор происходит в момент установки задания. Иначе, в момент выполнения задания.

INSTANCE - какой экземпляр производит выполнение задания.

FORCE - если значение этого параметра истинно то в качестве INSTANCE может выступать любое положительное целое число. В противном случае экземпляр, указанный в INSTANCE должен быть обязательно запущен, иначе поднимается исключение.

При создании задания или изменения его параметров ORACLE записывает текущие параметры NLS владельца. Эти параметры каждый раз восстанавливаются при выполнении задания. Это может приводить к некоторым ошибкам в случае ожидания других значений. Поэтому если необходимо лучше производить установку нужных NLS значений с помощью команды ALTER SESSION в параметре WHAT задания.

В качестве примера создадим простое задание, которое при запуске будет делать паузу в 20 секунд, первый раз выполниться 1 января 2006 года в 1 час 5 минут и будет повторяться каждый день в то же самое время.

Изменение задания

И так задание создано. Теперь попробуем изменить некоторые его параметры. Для изменения доступны следующие параметры задания: WHAT, NEXT_DATE, INTERVAL и INSTANCE. Их можно менять все одновременно или по отдельности. К примеру, следующая процедура пакета меняет все три параметра, при этом следует учитывать, что если какой либо из них равен NULL, то значение параметра не изменится.

А вот уже эта процедура меняет значение только параметра WHAT:

Также с параметрами NEXT_DATE,INTERVAL,INSTANCE:

В качестве примера, увеличим паузу, которое делает задание, созданное ранее, до 30 секунд и изменим, время повторного запуска задания на 3 часа 15 минут:

Изменить параметры или совершать другие действия над заданием можно только его владельцу. В противном случае возникнет ошибка ORA-23421: job number 24 is not a job in the job queue.

Удаление задания

Если задание становиться ненужным, то его можно удалить. Сделать это можно следующей процедурой:

Выключение задания

Бывают случаи, когда задание временно не должно выполняться. Для этого совсем необязательно его удалять. Достаточно его просто выключить. Выключение (включение) задания производится установкой специального флага состояния - BROKEN. Делается это с помощью следующей процедуры:

Если флаг BROKEN имеет значение истинно, то такое задание считается разрушенным и выполняться не будет. Параметр NEXT_DATE определяет здесь дату следующего выполнения задания и действует только при его включении.

В момент выключения задания параметр NEXT_DATE устанавливается в максимальное значение даты. Если не указать параметр NEXT_DATE в момент включения, то задание начнёт выполняться немедленно.

Для примера выключим задание:

Вынужденное выполнение задания

Если необходимо запустить задание в текущий момент времени, то сделать это можно с помощью следующей процедуры пакета:

Если параметр FORCE имеет значение ложно, то задание может быть выполнено в приоритетном режиме только в указанном экземпляре, иначе .

Задание выполняется в текущем сеансе, при этом повторно инициализируются пакеты текущего сеанса, и происходит неявная фиксация транзакции.

Экспорт задания

Если требуется перенести задание в другую базу данных или пересоздать задание, то это можно легко сделать с помощью следующей процедуры пакета:

Переменная mycall будет при этом содержать текст команды, с помощью которой можно заново создать задание.

Контроль задания

Как было указано выше, координатор заданий обращается в своей работе к системной таблице SYS.JOB$, хранящей описания всех заданий. На эту таблицу существуют три представления: DBA_JOBS, ALL_JOBS и USER_JOBS. Они наиболее часто используются для контроля над заданиями. Рассмотрим их некоторые столбцы:

JOB, NEXT_DATE, INTERVAL, WHAT, INSTANCE - эти столбцы знакомы нам по процедуре SUBMIT.
LOG_USER - пользователь под которым была создано задание. Фактически это и есть владелец задания.
PRIV_USER - пользователь привилегии которого используются для выполнения задания.
SCHEMA_USER - схема по умолчанию для разбора задания.
LAST_DATE (LAST_SEC) - дата (время) последнего успешного выполнения задания.
THIS_DATE (THIS_SEC) - дата (время) начала выполнения задания.
TOTAL_TIME - общее время выполнения задания в секундах. Содержит суммарное время длительности всех выполнений задания.
BROKEN - этот столбец показывает состояние флага разрушенного задания. Если значение равно Y задание выполняться не будет.
FAILURES - количество неудачных попыток выполнить задание. Максимальное значение может достигать 16.
NLS_ENV - NLS параметры сеанса. Соответствуют параметрам сеанса, в котором задание создавалось.

Кроме вышеперечисленных представлений существует и ещё одно - DBA_JOBS_RUNNING. Оно показывает задания, которые выполняются в текущий момент времени. С его помощью можно легко определить SID сеанса выполняемого задания.

Блокировки

Если подробнее разобрать представление DBA_JOBS_RUNNING, то можно увидеть что в его основе лежит соединение таблицы SYS.JOB$ и представления V$LOCK. Кажется, какая тут есть связь? Оказывается, есть и самая прямая. Для того чтобы гарантировать, что данное задание выполняется одновременно только в одном сеансе, Oracle выставляет блокировку JQ. Это можно хорошо видеть, сделав запрос к представлению V$LOCK во время выполнения задания:

При этом столбец ID2 будет указывать на идентификатор выполняемого задания.

Ошибки

Прерывание задания

Администраторы баз данных Oracle обычно используют сценарии SQL для предупреждений о ненормальных ситуациях. В Oracle Database 11g и 12c предусмотрена встроенная система сигналов (Oracle alerts), формально именуемая генерируемыми сервером сигналами тревоги, которые автоматически предупреждают о возникновении проблемных ситуаций. База данных генерирует сигналы в ответ на возникновение специфических событий, или когда определенные метрики базы данных превышают свои пороговые значения.

В Oracle сигналы на основе пороговых значений называют сигналами с состоянием (stateful alerts), и они могут быть настроены как на предупреждающие пороговые значения, так и на критичные. Таким образом, сигналы на основе пороговых значений основаны на метриках, а не событиях. В отличие от старых систем уведомления OEM, сама база данных собирает связанные с сигналами метрики вместо OEM. Предупреждающие и критичные пороговые значения могут быть установлены администратором баз данных или же можно принять внутренние настройки порогов Oracle.

Сигналы Oracle, не связанные с порогами — это сигналы, вызванные проблемами, которые основаны на возникновении в базе данных определенных событий (обычно плохих). В Oracle это называют сигналами без состояния (stateless alerts). Ниже даны некоторые примеры.

Переполнение пространства области восстановления.
Приостановка возобновляемого сеанса.
Устаревший снимок.

Таким образом, существуют три ситуации, когда база данных может посылать сигнал.

Метрика преодолевает критичное пороговое значение.
Метрика преодолевает пороговое значение предупреждения.
Возникновение непорогового (проблемного) типа сигналов.

При использовании сигналов на основе пороговых значений Oracle делает различие между предупреждающим сигналом (уровень серьезности 5) и критичным сигналом (уровень серьезности 1). Например, по умолчанию база данных будет посылать предупреждающий сигнал, когда любое табличное пространство превысит порог в 85% занятого места. Когда использованное пространство достигнет 97%, вы получите критичный сигнал.

Генерируемые сервером сигналы по умолчанию (Oracle Alerts default)

Oracle предлагает несколько генерируемых сервером сигналов по умолчанию, которые могут базироваться как пороговых значениях, так и на возникновении проблем. Ниже перечислены некоторые готовые генерируемые сервером сигналы в Oracle Database 11g.

Устаревший снимок.
Использование табличного пространства (предупреждающий сигнал при 85% занятого места и критичный — при 97%).
Приостановка возобновляемого сеанса.
Исчерпано свободное место в области восстановления.

На заметку! Oracle автоматически устанавливает пороги на всех метриках объектного типа SYSTEM.

В дополнение к сигналам по умолчанию можно выбирать и другие сигналы, а также изменять пороги сигналов по умолчанию. Эти задачи решаются с помощью OEM Database Control или поставляемых с Oracle пакетов PL/SQL. Средство Database Control можно так-же использовать для установки правил уведомления, например, указать период задержки сигналов, в течение которого никакие сигналы базой данных посылаться не будут.

Удостоверьтесь в установке параметра STATISTICS_LEVEL равным TYPICAL или ALL, чтобы использовать средство серверной генерации сигналов. В дополнение можно отображать сигналы, непосредственно подписавшись на очередь доставки сигналов.

Oracle alert log - лог сигналов тревоги

В файле alert.log хранится журнал сигналов тревоги и ошибок экземпляра. Многих системных администраторов интересует, где он располагается. Его нахождение задается настройкой background_dump_dest в файле параметров init[SID].ora. Выполните такой запрос:

Также местоположение файла alert log можно узнать из представления V$PARAMETER:

Предполагается, что вы инсталлировали базу данных, согласно документа.

Обязательные файлы:

Необязательные файлы:

(необязательные в том смысле, что база может быть настроена для работы без данных файлов) (Alertlog - если нет необходимости в изучении данных по ошибкам, можно удалить. Трассировочные файлы по умолчанию не создаются. Чтобы создавались, нужно включать трассировку и потом не забыть отключить) (По умолчанию не используются. Нужно специально создавать специальными командами.)

Файлы данных (Data Files)

Все данные в базе данных Oracle сохраняются в файлах данных. Все таблицы, индексы, триггеры, последовательности, программы на PL/SQL, представления - все это находится в файлах данных. И хотя эти и другие объекты базы данных логически содержатся в табличных пространствах, в действительности они сохраняются в файлах на жестком диске компьютера.

В каждой базе данных Oracle имеется по крайней мере один файл данных (но обычно их бывает больше). Если вы создаете в Oracle таблицу и заполняете ее строками, Oracle помещает эту таблицу и строки в файл данных. Каждый файл данных может быть связан только с одной базой данных.

У каждого файла данных имеется специальный формат, внутренний для программного обеспечения Oracle. Важно отдавать себе отчет в том, что файл данных состоит из заголовка и совокупности блоков. Заголовок файла данных Oracle содержит несколько структур, в том числе и идентификатор базы данных, номер и имя файла, тип файла, SCN создания и состояния файла.

Данные в файлы вносятся исключительно средствами Oracle.

Следующий запрос, покажет, где находятся файлы данных.

Оперативные файлы журналов повтора (Online Redo Log Files)

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

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

Каждая база данных должна иметь не менее двух оперативных файлов журналов повтора. Текущий файл постепенно заполняется, после его заполнения (или переключения некоторыми командами), база данных приступает к записи в следующий файл. Эта операция называется переключением журналов.

Поскольку файлы повтора необходимы для выполнения восстановления базы данных и являются критичными, их объединяют в группы. Запись происходит одновременно в файлы одной группы.

Управляющие файлы (Control Files)

Поскольку база данных Oracle является физическим набором связанных файлов данных, то для их синхронизации и контроля требуется особые методы. Для этих целей используются управляющие файлы.

База данных Oracle может иметь один или несколько управляющих файлов. Если имеется несколько управляющих файлов, все они должны быть абсолютно идентичными. При каждом запуске базы данных Oracle читает информацию управляющего файла, а при каждом изменении размещения или добавления новых файлов данных и журналов базы данных обновляет управляющий файл.

Файлы параметров pfile, spfie (Parameter Files)

Файлы параметров используются для конфигурирования действий Oracle предже всего при старте. Для того, чтобы запустить экземпляр базы данных, Oracle должен прочесть файл параметров и определить, какие параметры инициализации установлены для этого экземпляра. В файле параметров содержатся многочисленные параметры и их установленные значения. Oracle считывает файл параметров при запуске базы данных. Можно создать несколько файлов параметров, каждый будет соответствовать различным конфигурациям экземпляра.

spfile - бинарный файл, который используется сервером Oracle при старте.
pfile - текстовый файл с параметрами, будет использоваться при старте, если не будет найден spfile.

При старте, Oracle считает файл spfileora112.ora. (файл серверных параметров). Преимущество spfile заключается в том, что при работе с базой данных, любые изменения в базе касающиеся изменения параметра системы, автоматически записываются в данный файл.

Если используется pfile, для сохранения изменений, необходимо либо “руками вносить эти изменения” в текстовый файл, либо в консоли выполнять команды для создания данных файлов Ораклом.

Как я могу узнать, что моя база данных использует PFILE или SPFILE?

Выполните следующий запрос, чтобы увидеть какой файл параметров был использован:

Архивные файлы журналов повтора (Archive Log Files)

Как только оперативный файл журнала повтора (Redolog) оказывается заполнен, программное обеспечение сервера Oracle начинает запись в следующий файл. Эта операция повторяется, как следствие информация в оперативных файлах журнала (Redolog) многократно перезаписывается.

Если необходимо сохранить историю изменений, нужно, чтобы после переключения журналов сохранялась их копия. Для этого достаточно перевести работу базы данных в режим работы ARCHIVELOG.

Архивные файлы журналов повтора жизненно важны при восстановлении. Если часть базы данных потеряна или повреждена, то для устранения повреждений обычно требуется несколько архивных журналов или туева хуча этих журналов. Файлы журналов повтора должны применяться к базе данных последовательно. Если один из архивных файлов журналов повтора пропущен, то остальные архивные файлы журналов не могут использоваться. Храните все свои архивные файлы журналов повтора с момента выполнения последней резервной копии. Файлы журналов постепенно накапливаются и разрастаются. Иногда необходимо их удалять. Все операции с данными файлами по применению их к базе выполняются исключительно средствами базы данных. А копировать и переносить их при желании можно как угодно. Бездумно удалять их руками не рекомендуется.

Alert log и трассировочные файлы (trace file)

При работе базы данных события и ошибки регистрируются в текстовых файлах на сервере базы данных. Файл журнала предупреждений (alert log) нужен администратору базы данных для отслеживания важнейших действий с базой данных - наподобие открытия и закрытия базы данных, установления параметров загрузки базы данных и переключения оперативных журналов повтора. Также в эти файлы записываются многие ошибки базы данных для последующего расследования их причин. Любые структурные изменения базы данных также регистрируются в файле журнала предупреждений.

Когда возникает ошибка базы данных, может генерироваться файл трассировки (trace file). Они содержит подробную информацию о возникновении ошибки.

Файлы паролей (Password File)

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

Tags: Oracle Database, Файлы базы данных Oracle,

Oracle DBA

Лучше потратить какое-то количество времени, чтобы записать успешный опыт, чем потом повторно воспроизводить его по памяти.

Все материалы обновляются по мере нахождения лучших практик и апгрейда знаний. Если будут желающие добавлять свои знания или исправлять ошибки и неточности, пишите в телеграм чате. Если будет учавствовать больше людей, качество материалов будет улучшаться и обновляться быстрее. Ссылки на ваши профили в соц. сетях будут добавлены в статьях, в которых вы учавствуете.

Расположение журнала тревог

В ORACLE 10g параметр BACKGROUND_DUMP_DEST определяет местоположение журнала аварийных сигналов, но имя файла журнала аварийных сигналов не может быть изменено. Имя журнала аварийных сигналов - : alert_ <SID> .log, где <SID> - имя экземпляра. Параметр BACKGROUND_DUMP_DEST является динамическим.

Журнал аварийных сигналов и все файлы фоновой трассировки будут записаны в каталог, указанный параметром BACKGROUND_DUMP_DEST.

В ORACLE 11g и ORACLE 12c местоположение файла журнала аварийных сигналов было изменено. В основном из-за введения ADR (репозиторий автоматической диагностики : каталог для хранения журналов диагностики базы данных и файлов отслеживания), расположение каталога, соответствующее ADR, можно просмотреть в системном представлении v $ diag_info. Как показано ниже, (ORACLE 12c)

Как показано выше, каталог, соответствующий Diag Trace, - это каталог, в котором находится файл журнала предупреждений в текстовом формате, а каталог, соответствующий Diag Alert, - это журнал предупреждений в формате XML (соответствующий log_x.xml).

Содержание журнала аварийных сигналов:

Тогда журнал аварийных сигналов очень важен и важен, так какую же информацию содержит журнал аварийных сигналов? Журнал тревог содержит следующую информацию. Как и некоторые ошибки ORA, это чрезвычайно важно для мониторинга базы данных.

1: Вся информация о внутренней ошибке (ORA-600), информация об ошибке повреждения блока (ORA-1578), информация об ошибке тупика (ORA-60) и т. Д.

2: Операции управления, такие как операторы CREATE, ALTER, DROP и т. Д., А также некоторая информация о запуске, завершении работы базы данных и архивировании журналов.

2.1 Все операции, связанные с физической структурой: такие как команда ALTER DATABASE для создания, удаления и переименования файлов данных и файлов журнала повторного выполнения. Кроме того, это также включает перераспределение размера файлов данных и операции с файлами данных онлайн и офлайн.

2.2 Операции с табличными пространствами, такие как команды DROP и CREATE, в дополнение к операциям по размещению и удалению табличных пространств в режиме горячего резервного копирования для резервного копирования, управляемого пользователем

4: Произошла ошибка во время автоматического обновления материализованного представления.

5: Информация о модификации динамических параметров.

Мониторинг журнала тревог:

Поскольку журнал аварийных сигналов очень важен, и мы не можем просмотреть файл журнала аварийных сигналов вручную в любое время, мы должны отслеживать журнал аварийных сигналов. Итак, каковы же решения для мониторинга журнала аварийных сигналов? Резюмируйте ниже

Решение 1. Решение, данное Мастером Томом (применимо только к ORACLE 10g), считывает информацию из файла журнала сигналов тревоги в глобальную временную таблицу, а затем мы можем настроить некоторые операторы SQL для запроса информации журнала сигналов тревоги.

Решение 2. Просмотрите содержимое файла журнала аварийных сигналов во внешней таблице. Довольно удобно. Затем также используйте пользовательские операторы SQL для запроса информации об ошибках.

Вариант 3. Мой предыдущий блогАрхив аварийных сигналов базы данных ORACLEВ нем описывается, как архивировать и контролировать журналы тревог. Эти скрипты действительно очень эффективны для меня, чтобы контролировать работу базы данных.

Архив журнала тревог

Если журнал аварийных сигналов не архивируется вовремя, файл журнала аварийных сигналов надолго станет очень большим, а просмотр и чтение журнала аварийных сигналов приведет к дополнительным накладным расходам ввода-вывода. Поэтому файлы журнала тревог обычно следует архивировать каждый день, хранить в течение определенного периода времени (например, 90 дней) и удалять по истечении указанного времени.

Можно ли удалить журнал тревог? Коллега сказал, что файлы трассировки в каталоге background_dump_dest можно удалить, кроме журнала аварийных сигналов. Если вы удалите файл журнала аварийных сигналов, могут возникнуть непредвиденные ошибки. I Сомнительно, удалите журнал аварийных сигналов на тестовом сервере. После проверки система заново создаст файл журнала аварийных сигналов (файл журнала аварийных сигналов будет создан не сразу, но когда процесс будет записывать журнал аварийных сигналов При записи будет создан новый файл журнала тревог).

рис. Старый "дедовский" debug кода

Добрый день! Работая разработчиком Oracle PL/SQL, часто ли вам приходилось видеть в коде dbms_output.put_line в качестве средства debug-а? Стоит признать, что к сожалению, большинство (по моему личному мнению и опыту) разработчиков Oracle PL/SQL не уделяет должного внимания логированию как к «спасательному кругу» в случае возникновения ошибок. Более того, большая часть разработчиков не совсем понимает зачем нужно логировать информацию об ошибках и самое главное, не совсем понимают что делать и как использовать эту информацию в будущем.

Предисловие

Данным постом хотел бы начать цикл статей посвященных «Логированию ошибок» в Oracle PL/SQL. В первую очередь донести мысль до многих разработчиков, о том как можно построить функционал фиксации, хранения логов в БД. На своем опыте продемонстрировать поэтапный процесс создания полноценного логирования в БД. Рассказать как нам удалось создать логирование ошибок, разработать единую нумерацию событий для их дальнейшей идентификации, как поверх логирования «натянуть» мониторинг событий, создать функционал позволяющий увидеть все текущие ошибки в БД в виде таблиц (с указанием частоты возникновения ошибок и кол-ва и т.д.), графиков (отразить динамику роста кол-ва ошибок) и правильно распределить ресурсы для устранения тех или иных ошибок.

Оговорюсь сразу, что на рынке возможно уже есть успешные существующие коммерческие продукты осуществляющие логирование гораздо лучше и качественнее хотя бы, потому что у них есть многолетний опыт внедрения и сопровождения своего продукта в различных компаниях. Я же хочу показать один из множества примеров реализации функционала логирования, которые вполне можно осуществить силами своих разработчиков.

Введение

Модель логирования позволяет реализовать:

Единый подход в обработке и хранении событий

Собственную нумерацию и идентификацию событий происходящих в БД (статья)

Единый мониторинг событий (статья в разработке)

Анализ событий происходящих в БД (статья в разработке)

Описанные выше характеристики указаны в порядке нумерации и каждый следующий пункт (шаг) есть улучшение и усложнение существующей модели. Описание этой модели будет сложно выполнить в рамках одной статьи, поэтому опишем их последовательно. Начнём с первого пункта.

Единый подход в обработке и хранении событий

Основной идеей "Единого подхода в обработке и хранении событий" заключается в создании одного одновременно простого и в тоже время очень сложного правила: "Все объекты базы данных (функции, процедуры) в обязательном порядке должны завершаться блоком обработки исключений с последующим логированием события". Простота заключается в том, что легко, в команде разработчиков, на словах договориться об исполнении данного правила. Сложность же заключается в том, что данное правило должно быть установлено на ранних этапах создания вашей БД и выполняться обязательно на протяжении всего жизненного цикла. Внедрить функционал логирования в уже существующие и действующие БД очень сложно (практически не возможно).

Все объекты базы данных (функции, процедуры) в обязательном порядке должны завершаться блоком обработки исключений с последующим логированием события. Для этого можно использовать шаблон процедуры (функции) описанный во второй статье.

Наверное сейчас кто-то из читателей может возразить: "Зачем в обязательном порядке?". А всё очень просто, если вы разработчик PL/SQL и вы не согласны с этим правилом, то вот вам пример. Посмотрите на свой текущий проект более внимательно. Скорее всего вы найдете какое-нибудь логирование событий реализованное кем-то, когда-то. Вспомните сколько раз вы обращались к этому логированию при решении багов. Именно в таких ситуациях, когда есть срочность по времени в исправлении бага, вы или ваши коллеги начинают использовать dbms_output.put_line в качестве экспресс-дебага (быстрый способ получения значений переменных используемых в коде). Согласитесь, что для исправления бага мало знать в какой процедуре, в каком запросе и на какой строке возникла ошибка, необходимо знать параметры запроса на которых возникает ошибка. И вот тут нам на помощь приходит "Логирование событий", потому что помимо места возникновения ошибки мы узнаем параметры вызова процедуры, в которой возникает ошибка и это очень упрощает исправление бага.

Первая статья посвящена базовому функционалу «Логирования событий». В простейшей реализации это одна общая таблица и пакет процедур для работы с ней. Для создания и демонстрации логирования, нам необходимо реализовать следующие объекты БД (весь список объектов с их исходными кодами представлен в Git):

Таблица messagelog - единая таблица логов. Именно в данной таблице будет храниться информация о дате и времени события, об объекте где происходит событие, типе события с указанием кода, текста и параметров. В нашем примере, столбец backtrace вынесен в отдельную таблицу messagelog_backtrace для удобства.

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

Также, учитывайте пожалуйста, что создание партиции требует как минимум Oracle EE. Создание партиции вне указанной версии Oracle приведет к нарушению лицензионного соглашения.

Читайте также: