Пакет DBMS LOGMNR 1635

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

Пакеты LogMiner предоставляют средства для решения всех этих и многих других задач. В этом разделе я представлю краткий обзор использования пакетов LogMiner, а затем опишу ряд проблем при его использовании, о которых не сказано в руководстве Supplied PL/SQL Packages Reference, поставляемом корпорацией Oracle. Как и в случае прочих пакетов, рекомендуется прочитать разделы руководства Supplied PL/SQL Packages Reference, посвященные пакетам DBMS LOGMNR и DBMS LOGMNR D, чтобы получить общее представление о функциях и процедурах, которые они содержат, и о принципах использования этих пакетов. Далее в разделе Опции и использование представлен обзор соответствующих процедур и их входных данных.

Пакеты LogMiner лучше всего работают с архивными файлами журнала повторного выполнения, хотя их можно использовать и для анализа неактивных оперативных файлов журнала повторного выполнения. Попытка анализа активного оперативного файла журнала повторного выполнения может привести к выдаче сообщения об ошибке или дать некорректные результаты, поскольку файл журнала повторного выполнения содержит данные стар1х и новых транзакций. Интересно, что с помощью LogMiner можно анализировать файл журнала, первоначально созданный в другой базе данных. Даже версии серверов при этом могут не совпадать (архивные файлы версии 8.0 можно анализировать на сервере версии 8.1). Можно перенести архивный файл журнала повторного выполнения в другую систему и анализировать его там. Это весьма удобно в случае проверки или ретроспективного анализа тенденций использования, не влияющей на работу системы. Для этого, однако, надо использовать сервер на той же аппаратной платформе (т.е. обеспечить тот же порядок байтов, размер слова и т.п.). Желательно обеспечить такой же размер блоков базы данных, как в исходной (размер блока в базе данных, где выполняется анализ, не должен б1гь меньше, чем в базе данных, где журнал повторного выполнения сгенерирован), и совпадение кодовых страниц.

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

На втором этапе импортируются файлы журнала повторного выполнения, и запускается LogMiner. После запуска основного пакета LogMiner можно просматривать содержимое файлов журнала повторного выполнения с помощью SQL-операторов. С пакетами LogMiner связано четыре представления V$. Основное представление - V$LOGMNR CONTENTS. Именно оно будет использоваться для анализа содержимого загруженных файлов журнала повторного выполнения. Более детально это представ-

1636

Приложение А

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

V$LOGMNR DICTIONARY. Это представление содержит информацию о загруженном файле словаря. Этот словарь б1л создан на первом этапе. Чтобы разобраться в содержимом файла журнала повторного выполнения, необходим файл словаря, задающий имя объекта с данным идентификатором, имена и типы данных столбцов таблиц и т.п. Это представление содержит не больше одной строки, описывающей текущий загруженный словарь.

V$LOGMNR LOGS. Это представление содержит информацию о файлах журнала

повторного выполнения, которые пользователь загрузил в систему с помощью LogMiner. Содержимое файлов журнала повторного выполнения можно найти в представлении V$LOGMNR CONTENTS. Там же вы найдете характеристики самих файлов: имя файла журнала повторного выполнения, имя базы данных, в которой он сгенерирован, номера системных изменений (SCNs - system change numbers), содержащихся в нем, и т.д. В представлении содержится по одной строке для каждого анализируемого файла.

V$LOGMNR PARAMETERS. Это представление содержит параметры, передан-

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

Важно отметить, что, поскольку пакеты LogMiner выделяют память в области PGA, средства LogMiner нельзя использовать в среде MTS. Дело в том, что в среде MTS каждое обращение к базе данных будет обрабатываться другим разделяемым сервером (процессом или потоком). Данные, загруженные первым процессом (первым разделяемым сервером) не доступны для второго процесса (второго разделяемого сервера). Для работы пакетов LogMiner необходимо подключиться к выделенному серверу. Кроме того, результат доступен в одном сеансе и только в процессе его работы. Если необходим дальнейший анализ, надо либо загрузить информацию повторно, либо сохранить ее в постоянной таблице, например, с помощью оператора CREATE TABLE AS SELECT. При анализе больших объемов данных размещение их в обычной таблице с помощью операторов CREATE TABLE AS SELECT или INSERT INTO имеет еще больше смысла. В дальнейшем эту информацию можно проиндексировать, тогда как представление V$LOGMNR CONTENTS всегда просматривается полностью, что требует очень много ресурсов.

Обзор

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

Пакет DBMS LOGMNR 1637

Этап 1: создание словаря данных

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

Чтобы понять назначение файла словаря данных, давайте рассмотрим результата работе! LogMiner, когда словарь данн1х не загружен. Для этого загрузим архивный файл журнала повторного выполнения и запустим LogMiner. Затем выполним запрос к представлению V$LOGMNR CONTENTS, чтобы определить его содержимое:

tkyte@TKYTE816> begin

2 sys.dbms logmnr.add logfile

3 (C:\oracle\oradata\tkyte816\archive\TKYTE816T001S01263.ARC ,

4 sys.dbms logmnr.NEW);

5 end;

PL/SQL procedure successfully completed.

tkyte@TKYTE816> begin

2 sys.dbms logmnr.start logmnr;

3 end;

PL/SQL procedure successfully completed. tkyte@TKYTE816> column sql redo format a3 0

tkyte@TKYTE816> column sql undo format a30

tkyte@TKYTE816>select scn, sql redo, sql undo from v$logmnr contents

SCN SQL REDO SQL UNDO

6.4430E+12

6.4430E+12 set transaction read write;

6.4430E+12 update UNKNOWN.Objn:30551 set update UNKNOWN.Objn:30551 set Col[2] =HEXTORAW(787878) wh Col[2] =HEXTORAW(534d495448 ere ROWID = AAAHdXAAGAAAAJKAA ) where ROWID = AAAHdXAAGAAAA A ; JKAAA ;

6.4430E+12 6.4430E+12 coit;

tkyte@TKYTE816> select utl raw.cast to varchar2(hextoraw(787878)) from dual; UTL RAW.CAST TO VaRCHAR2(HEXTORAW(787878))