Log Miner: Oracle Database Administration
Log Miner: Oracle Database Administration
Using Log Miner utility, you can query the contents of online redo log files and archived log
files. Because LogMiner provides a well-defined, easy-to-use, and comprehensive relational
interface to redo log files, it can be used as a powerful data audit tool, as well as a tool for
sophisticated data analysis.
LogMiner Configuration
There are three basic objects in a LogMiner configuration that you should be familiar with:
the source database, the LogMiner dictionary, and the redo log files containing the data of
interest:
The source database is the database that produces all the redo log files that you want
LogMiner to analyze.
The LogMiner dictionary allows LogMiner to provide table and column names,
instead of internal object IDs, when it presents the redo log data that you request.
LogMiner uses the dictionary to translate internal object identifiers and datatypes to object
names and external data formats. Without a dictionary, LogMiner returns internal object IDs
and presents data as binary data.
(HEXTORAW('45465f4748'),HEXTORAW('546563686e6963616c20577269746572'),
HEXTORAW('c229'),HEXTORAW('c3020b'));
The redo log files contain the changes made to the database or database dictionary.
LogMiner requires a dictionary to translate object IDs into object names when it returns redo
data to you. LogMiner gives you three options for supplying the dictionary:
Oracle recommends that you use this option when you will have access to the source database
from which the redo log files were created and when no changes to the column definitions in
the tables of interest are anticipated. This is the most efficient and easy-to-use option.
Oracle recommends that you use this option when you do not expect to have access to the
source database from which the redo log files were created, or if you anticipate that changes
will be made to the column definitions in the tables of interest.
This option is maintained for backward compatibility with previous releases. This option
does not guarantee transactional consistency. Oracle recommends that you use either the
online catalog or extract the dictionary from redo log files instead.
To extract a LogMiner dictionary to the redo log files, the database must be open and in
ARCHIVELOG mode and archiving must be enabled. While the dictionary is being extracted
to the redo log stream, no DDL statements can be executed. Therefore, the dictionary
extracted to the redo log files is guaranteed to be consistent (whereas the dictionary extracted
to a flat file is not).
To extract dictionary information to the redo log files, use the DBMS_LOGMNR_D.BUILD
procedure with the STORE_IN_REDO_LOGS option. Do not specify a filename or location.
When the LogMiner dictionary is in a flat file, fewer system resources are used than when it
is contained in the redo log files. Oracle recommends that you regularly back up the
dictionary extract to ensure correct analysis of older redo log files.
1. Set the initialization parameter, UTL_FILE_DIR, in the initialization parameter file. For
example, to set UTL_FILE_DIR to use /oracle/database as the directory where the
dictionary file is placed, enter the following in the initialization parameter file:
UTL_FILE_DIR = /oracle/database
SQL> startup
DBMS_LOGMNR_D.STORE_IN_FLAT_FILE);
You can direct LogMiner to automatically and dynamically create a list of redo log files to
analyze, or you can explicitly specify a list of redo log files for LogMiner to analyze, as
follows:
Automatically
If LogMiner is being used on the source database, then you can direct LogMiner to find and
create a list of redo log files for analysis automatically. Use the CONTINUOUS_MINE option
when you start LogMiner.
Manually
The easiest way to examine the modification history of a database is to mine at the source
database and use the online catalog to translate the redo log files. This example shows how to
do the simplest analysis using LogMiner.
Note that there are four transactions (two of them were committed within the redo log file
being analyzed, and two were not). The output shows the DML statements in the order in
which they were executed; thus transactions interleave among themselves.
SQL> SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS
XID,SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS WHERE username IN ('HR',
'OE');
Example of Mining Without Specifying the List of Redo Log Files Explicitly
The previous example explicitly specified the redo log file or files to be mined. However, if
you are mining in the same database that generated the redo log files, then you can mine the
appropriate list of redo log files by just specifying the time (or SCN) range of interest. To
mine a set of redo log files without explicitly specifying them, use the
DBMS_LOGMNR.CONTINUOUS_MINE option to the DBMS_LOGMNR.START_LOGMNR
procedure, and specify either a time range or an SCN range of interest.
This example assumes that you want to use the data dictionary extracted to the redo log files.
Step 1 Determine the timestamp of the redo log file that contains the start of the data
dictionary.
NAME FIRST_TIME
-------------------------------------------- --------------------
Step 2 Display all the redo log files that have been generated so far.
This step is not required, but is included to demonstrate that the CONTINUOUS_MINE option
works as expected, as will be shown in Step 4.
NAME
----------------------------------------------
/usr/oracle/data/db1arch_1_207_482701534.dbf
/usr/oracle/data/db1arch_1_208_482701534.dbf
/usr/oracle/data/db1arch_1_209_482701534.dbf
/usr/oracle/data/db1arch_1_210_482701534.dbf
DBMS_LOGMNR.COMMITTED_DATA_ONLY + -
DBMS_LOGMNR.PRINT_PRETTY_SQL + -
DBMS_LOGMNR.CONTINUOUS_MINE);
NAME
------------------------------------------------------
/usr/oracle/data/db1arch_1_207_482701534.dbf
/usr/oracle/data/db1arch_1_208_482701534.dbf
/usr/oracle/data/db1arch_1_209_482701534.dbf
/usr/oracle/data/db1arch_1_210_482701534.dbf
To reduce the number of rows returned by the query, exclude all DML statements done in the
sys or system schema. (This query specifies a timestamp to exclude transactions that were
involved in the dictionary extraction.)
Note that all reconstructed SQL statements returned by the query are correctly translated.
declare
begin
end;
set
where
values
OE 1.9.1598 update "OE"."PRODUCT_INFORMATION"
set
"LIST_PRICE" = 92
where
values