Утилита 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 для отмены и повторного выполнения.
Процедуры пакета не попадут в список наиболее часто используемых, но
иногда без них не обойтись.