Утилита LogMiner. Пакет DBMS_LOGMNR

Государственное учреждение образования

"Белорусский государственный технологический университет"

Факультет издательского дела и полиграфии

Кафедра информационных систем и технологий

Пояснительная записка

по курсовой работе:

"Утилита LogMiner. Пакет DBMS_LOGMNR"

Выполнила:

Ревяко В.А.

курс 3 группа 9

проверил:

доц. Смелов В.В

Минск 2011

Содержание

Введение

1.   Пакеты LogMiner

.     Предварительные установки

2.1 Параметр utl_file_dir

.2 Режим ARCHIVELOG

.3 Дополнительное журналирование базы данных

3.   Словарь данных LogMiner

.     Пример использования средств LogMiner

Заключение

Введение

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

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

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

На втором этапе импортируются файлы журнала повторного выполнения, и запускается LogMiner. После запуска основного пакета LogMiner можно просматривать содержимое файлов журнала повторного выполнения с помощью SQL-операторов. Для анализа содержимого загруженных файлов журнала используется представление V$LOGMNR_CONTENTS.

1.      Пакеты LogMiner

Функциональные возможности LogMiner реализуются двумя пакетами:

·        DBMS_LOGMNR

·        DBMS_LOGMNR_D.

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

·        DICTIONARY_FILENAME. Имя файла словаря, который необходимо создать.

·        DICTIONARY_LOCATION. Каталог, в котором этот файл будет создан.

Пакет DBMS_LOGMNR состоит из трех процедур:

·        ADD_LOGFILE. Зарегистрировать набор файлов журнала для анализа.

·        START_LOGMNR. Заполнить данными представление V$LOGMNR_CONTENTS.

·        END_LOGMNR. Освободить все ресурсы, выделенные при работе LogMiner. Эта процедура вызывается для корректного освобождения ресурсов перед завершением сеанса или при окончании работы с пакетами LogMiner.

2.      Предварительные установки

Перед началом работы с LogMiner необходимо установить некоторые параметры и изменить режим базы данных.

·        Установить параметр инициализации utl_file_dir

·        Установить режим ARCHIVELOG

·        Установить дополнительное журналирование базы данных - SUPPLEMENTAL LOG DATA

2.1 Параметр utl_file_dir

Стандартный пакет UTL_FILE позволяет читать и создавать текстовые файлы в файловой системе сервера в среде PL/SQL.

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

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

Пакет DBMS_LOGMNR_D, с помощью которого создается файл словаря данных, для выполнения ввода-вывода использует средства пакета UTL_FILE.

Рис.1 - изменение параметра utl_file_dir

2.2 Режим ARCHIVELOG

База данных Oracle может работать в двух режимах:

·        NOARCHIVELOG

·        ARCHIVELOG.

Если база данных не работает в режиме ARCHIVELOG, данные рано или поздно будут потеряны.

Чтобы сервер Oracle мог сохранять данные файла журнала повторного выполнения, перед тем как файл будет перезаписан, необходимо перевести базу данных в режим ARCHIVELOG. Тогда сервер будет архивировать журналы и никакие данные не будут утеряны.

Для перевода базы данных в режим ARCHIVELOG (рис. 2) необходимо:

·        остановить экземпляр Oracle - shutdown immediate;

·        запустить экземпляр Oracle в режиме mount;

·        перевести базу данных в режим ARCHIVELOG -

alter database archivelog

·        открыть базу данных alter database open.

Рис. 2 - перевод базы данных в режим ARCHIVELOG

2.3 Дополнительное журналирование базы данных

Supplemental logging - это процесс записи дополнительной информации в журнал во время выполнения операций изменения (например, изменения строки). Существует два уровня supplemental logging:

·        database-level supplemental logging

·        table-level supplemental logging.

Database-level supplemental logging. Существует 2 типа database-level supplemental logging:

·        minimal supplemental logging

·        identification key logging.

Первый в отличие от второго не добавляет значительную нагрузку на базу данных.Рекомендуется как минимум включать minimal supplemental logging.

Minimal supplemental logging - в этом режиме база данных журналирует дополнительный объем данных, необходимый для идентификации, группировки и соединения операций Redo, связанных с DML изменениями.

Включить: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Выключить: ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;

Database identification key logging имеет ряд режимов:

·        ALL - безусловно заставляет базу записывать в журналы изменения для всех столбцов в изменяемой строке

·        PRIMARY KEY - безусловно (даже если первичный ключ не меняется) заставляет базу записывать в журналы изменения для первичного ключа в изменяемой строке.

·        UNIQUE - при условии, что изменяется столбец, входящий в уникальный или bitmap индекс, журналирует изменения для всех столбцов, принадлежащие этому индексу

·        FOREIGN KEY - при условии, что изменяется столбец, входящий в FK, журналирует изменения для всех столбцов FK.

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

файл журналирование база данный

Рис. 3 - дополнительное журналирование базы данных

3.      Словарь данных LogMiner

Чтобы средства LogMiner могли сопоставить внутренним идентификаторам объектов и столбцов соответствующие имена, необходим словарь данных. Имеющийся в базе данных словарь при этом не используется. Словарь данных должен загружаться из внешнего файла. Это необходимо для того, чтобы журналы повторного выполнения можно было анализировать в другой базе данных. Кроме того, текущий словарь данных в базе может поддерживать уже не все объекты, находившиеся в базе данных в момент генерации файла журнала повторного выполнения, вот почему словарь данных необходимо импортировать.

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

·        установлен параметр utl_file_dir (см. пункт 2.1.)

·        схема, в которой будет вызываться пакет DBMS_LOGMNR_D, должна иметь привилегию EXECUTE ON SYS.DBMS_LOGMNR_D, или ей должна быть предоставлена роль с привилегий выполнения этого пакета. По умолчанию роль EXECUTE_CATALOG_ROLE имеет привилегию для выполнения этого пакета (рис. 4).

Рис. 4 - назначение роли EXECUTE_CATALOG_ROLE

После настройки пакета UTL_FILE и получения привилегии EXECUTE ON DBMS_LOGMNR_D создаём файл словаря. Для этого нужно вызвать пакет DBMS_LOGMNR_D с процедурой BUILD (рис. 5).

рис. 5 - создание словаря данных LogMiner

Выполненная выше команда, в каталоге c:\oracle\temp (который мы указали при установке параметра utl_file_dir) создала файл dictionary_logminer. Это обычный текстовый файл, который можно просматривать в текстовом редакторе (рис. 6, рис. 7). Файл содержит SQL-подобные операторы, которые анализируются и выполняются процедурой запуска основного пакета LogMiner. Теперь, при наличии файла словаря, можно посмотреть, какая информация содержится в представлении V$LOGMNR_CONTENTS.

Рис.6 - словарь данных LogMiner

Рис. 7 - словарь данных LogMiner

4.      Пример использования средств LogMiner

Для наглядного представления работы Logminer сгенерируем некоторые транзакции, которые потом будем искать в файлах журналов. Например, пользователь VIKA, в своей схеме создаёт таблицу Test и делает в ней некоторые изменения (рис. 8).

Рис. 8 - генерация транзакций

Далее необходимо найти имеющиеся на сервере файлы журналов повторного выполнения. Для этого делаем запрос к представлению v$logfile (рис. 9). Из рисунка видно, что на сервере имеется три redo-файла.

рис. 9 - поиск redo-файлов

Теперь загружаем полученные файлы в LogMiner. Для этого используется пакет DBMS_LOGMNR с процедурой ADD_LOGFILE (рис. 10).

Процедура ADD_LOGFILE вызывается еще до запуска LogMiner. Она создает список файлов журнала, которые будут обрабатываться при выполнении процедуры START_LOGMNR для заполнения представления VSLOGMNR_CONTENTS. Процедура ADD_LOGFILE принимает следующие параметры:

·        LOGFILENAME. Полное имя файла архивного журнала повторного выполнения, который необходимо проанализировать.

·        OPTIONS. Задает, добавлять указанный файл или удалять. В качестве значения задаются следующие константы пакета DBMS_LOGMNR:

ü  DBMS_LOGMNR.NEW. Начать новый список. Если список уже существует, он очищается.

ü  DBMS_LOGMNR.ADD. Добавить файл в уже существующий или пустой список.

ü  DBMS_LOGMNR.REMOVEFILE. Удалить файл из списка.

Рис. 10 - загружаем Redo в LogMiner

Далее стартуем LogMiner, используя процедуру START_LOGMNR (рис. 11) и в качестве параметра передаём полное имя словаря созданного процедурой DBMS_LOGMNR_D.BUILD.

Рис. 11 - запуск LogMiner

Теперь можно просматривать представление V$LOGMNR_CONTENTS. Представление V$LOGMNR_CONTENTS содержит по одной строке для каждого логического изменения в базе данных, выбранного из обработанных файлов журналов. На рис. 12-13 показаны все столбцы представления:

Рис. 12 столбцы представления V$LOGMNR_CONTENTS

Рис. 13 столбцы представления V$LOGMNR_CONTENTS

Для просмотра представления используем оператор SELECT. Выбираем наиболее важные столбцы, которые помогут нам разобраться, что было изменено, когда и кем.

Рис. 14. - оператор SELECT

В результате запроса получаем следующие данные (рис. 15, 16, 17):

рис. 15 - системный номер, время, схема, в которой были изменения, кто их проделал.

Рис. 16 - sql _redo

На рисунке 16 показан столбец sql_redo, который содержат SQL-подобные операторы, представляющие логические операции повторного выполнения, построенные на основе одной или нескольких записей архивного журнала повторного выполнения. Мы видим, что в столбце полностью отображаются проделанные нами операторы.

Чтобы отменить транзакции, нужно воспользоваться данными из столбца sql_undo, который содержит обратные sql_redo операции (рис. 17).

Рис. 17 - sq_undo

Последняя процедура - DBMS_LOGMNR.END_LOGMNR (рис. 18).

Она завершает сеанс LogMiner и очищает представление V$LOGMNR_CONTENTS.

После вызова DBMS_LOGMNR.END_LOGMNR любые попытки обратиться к этому представлению приведут к ошибке.

Рис. 18 - завершение работы LogMiner

Заключение

Средства LogMiner позволяют определить, что происходило в базе данных, и с этой задачей справляются прекрасно.

Мы увидели, как пакеты LogMiner помогают при поиске "кто и когда это сделал" - именно для этого средства LogMiner и используются.

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

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