Утилита LogMiner. Пакет DBMS_LOGMNR
Курсовой проект - Компьютеры, программирование
Другие курсовые по предмету Компьютеры, программирование
роки). Существует два уровня 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-Level Identification Key Logging. Используя этот режим, можно включить журналирование изменений для всех таблиц в базе данных.
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. Выбираем наиболее важ