标签：

1 LogMiner简介

   LogMiner是Oracle自带的一个工具，它通过SQL接口查询分析在线重做日志或是归档日志（包含数据库以往的操作记录），本文介绍通过命令行的形式使用LogMiner。当然，你也可以通过OEM中的LogMiner图形界面工具来使用它，详见OEM在线帮助相关文档。

   数据库所有的用户数据以及数据字典的变化都记录在Oracle的重做日志文件中，以便日后可以执行数据库恢复。Oracle推出的LogMiner提供了一个明确、简单易用且全面的关系接口来分析重做日志文件，它可以作为一个强大的数据审计工具，同时也作为一种先进的数据分析工具。

   LogMiner工具的主要用途有（来自网络）：

1．跟踪数据库的变化：可以离线的跟踪数据库的变化，而不会影响在线系统的性能；

2．回退数据库的变化：回退特定的变化数据，减少point-in-time recovery的执行；

3．优化和扩容计划：可通过分析日志文件中的数据以分析数据增长模式。

1.1 LogMiner配置

          LogMiner配置涉及到4个方面：源数据库，目标库、LogMiner数据字典和包含要分析数据的重做日志文件。

•  源数据库是指生成重做日志文件或者归档日志的数据库；

•  目标库是指运行LogMiner的数据库；

•  LogMiner数据字典用来解析表名、列名等，没有数据字典，分析结果返回的对象名以及数据显示为二进制形式；

   例1：如下图，一个简单的LogMiner配置，源数据库Boston将它的重做日志归档并传给San Francisco（目标数据库），LogMiner数据字典包含在这些重做日志文件中，目标库可以以此来分析重作日志文件。

关于源数据库，目标库、LogMiner数据字典和包含要分析数据的重做日志文件的要求，如下：

• 源数据库与目标库：必须运行在相同的硬件平台；目标库与源库可以是同一库，也可以是独立的2个库；目标库必须与源库版本相同，或者比源库版本更高；目标库与源库字符集一致，或者是源库字符集的超集。

• LogMiner数据字典：必须由产生重做日志文件的数据库生成。

• 重做日志文件：必须产生于同一数据库；必须具有相同的数据库RESETLOGS SCN；必须产生于8.0或者更新的数据库版本，但是，9.0.1版本中的一些LogMiner特性仅适用于9i或者更新版本数据库产生的重做日志文件。

  注意：在生成用于LogMiner分析的重做日志之前，务必启用补充日志，这样其他有用的信息会被记录在重做日志文件中，因此，至少应该开启最小补充日志。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

通过V$DATABASE视图查看修改是否完成，当值为“YES”或者“IMPLICIT”，表示修改成功。

SQL> SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;

1.2 LogMiner分析日志步骤

   使用PL/SQL包中的DBMS_LOGMNR和DBMS_LOGMNR_D执行LogMiner分析操作，然后通过V$LOGMNR_CONTENTS查看分析结果，具体步骤如下：

1.生成LogMiner数据字典，通过DBMS_LOGMNR_D.BUILD生成LogMiner数据字典。

2.添加重做日志文件分析列表，通过DBMS_LOGMNR.ADD_LOGFILE添加需要分析的日志文件。

3.启动LogMiner，通过DBMS_LOGMNR.START_LOGMNR开始分析日志文件。

4.查询分析结果，通过V$LOGMNR_CONTENTS查询分析结果数据（必须拥有SELECT ANY TRANSACTION权限）。

5.关闭LogMiner分析，通过DBMS_LOGMNR.END_LOGMNR停止分析。

1.3 LogMiner数据字典与重作日志文件

1.3.1 LogMiner数据字典模式

LogMiner需要数据字典来将重做日志文件中的对象ID解析成对象名称，Oracle提供了3种LogMiner数据字典模式：

   1.使用在线字典，这是Oracle推荐的方法，适用于在源数据库做LogMiner，这是最高效和易用的模式。在线字典除了可以用来分析在线联机重做日志，也可以用来分析同一系统生成的归档日志。

SQL> EXECUTE DBMS_LOGMNR.START_LOGMNR(-

   OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

在线日志模式要求数据库必须是OPEN状态，另外DBMS_LOGMNR.START_LOGMNR带DDL_DICT_TRACKING选项时在线日志不可用。

   在线字典包含了数据库最新的信息，可能是启动分析的最快捷的方式。但是切记在线字典仅可以重构表最新执行SQL语句，一旦表被修改，在线字典就不能反应表先前的状态，这意味着LogMiner将不能重构表先前版本的SQL语句。也就是说，LogMiner产生的SQL（V$LOGMNR_CONTENTS视图中SQL_REDO的值，包括16进制到二进制格式的值）将不可执行，如下：

SQL> insert into HR.EMPLOYEES(col#1, col#2)values(hextoraw('4a6f686e20446f65'),hextoraw('c306'));"

   2.将字典存于重做日志中，不能再源数据的直接进行LogMiner时使用。这种模式下数据库必须是OPEN状态、必须启用归档模式和归档。当字典被提取到重作日志流中，DDL语句不可执行，以此来保证字典与重作日志 的一致性，生成方式如下：

SQL> EXECUTE DBMS_LOGMNR_D.BUILD( -OPTIONS=> DBMS_LOGMNR_D.STORE_IN_REDO_LOGS);

   将字典提取到重做日志文件的过程中，会消耗数据库资源，但如果将提取时间限制为非高峰时间，那么这就不是问题，并且比提取到一个OS文件要快得多。根据字典的大小，它可能包含在多个重做日志文件中，如果相关的重做日志文件已被归档，那么可以通过V$ARCHIVED_LOG视图找出哪些重做日志文件包含已提取的字典，如下：

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN='YES';

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_END='YES';

   查出字典相关的重做日志文件的起始和最终编号，然后找出它们中间的其他日志，通过调用ADD_LOGFILE过程来实现LogMiner分析。Oracle建议你定期备份重做日志文件以便后期可用，理想情况下，这不需要额外的工作量来完成，因为只要数据库是正确管理的，都会有备份和恢复归档的操作，而且一般都是在非高峰时间完成。

3.将字典生成OS文件，这种方式不能保证事务一致，主要用于兼容先前的数据库版本，不推荐使用。

   当字典存于OS文件中，如果它是包含在重做日志文件中将消耗更少的系统资源，Oracle建议定期备份提取的字典以保证能够正确的分析旧的重做日志文件。通过DBMS_LOGMNR_D.BUILD的STORE_IN_FLAT_FILE参数完成字典的OS文件生成，生成过程中避免DDL操作，步骤如下：

• 设置初始化参数UTL_FILE_DIR用于存放字典文件

SQL> alter system set UTL_FILE_DIR = /oracle/database scope=spfile;

注：必须重启数据库已使设置生效。

•  使用DBMS_LOGMNR_D.BUILD指定字典名称以及路径生成字典文件
  

SQL> EXECUTE DBMS_LOGMNR_D.BUILD('dictionary.ora', -

       '/oracle/database/', -

      DBMS_LOGMNR_D.STORE_IN_FLAT_FILE);

具体选择哪种模式主要取决于实际情况，如下：

1.3.2 重做日志文件选项

在做LogMiner重做日志文件分析时，可以自动或者手动的方式来添加重做日志列表，如下：

1. 自动方式

   如果在源数据库上已经使用了LogMiner，就可以通过DBMS_LOGMNR.START_LOGMNR过程的CONTINUOUS_MINE（数据库必须mounted状态并且是归档模式）参数直接指定要做分析的重做日志文件列表以及时间或SCN范围。

LogMiner可以使用数据库的控制文件来查找、添加指定时间或SCN范围的重做日志文件，例如：

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';

SQL> EXECUTE DBMS_LOGMNR.START_LOGMNR( -

       STARTTIME => '01-Jan-2003 08:30:00', -

       ENDTIME => '01-Jan-2003 08:45:00', -

       OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -

       DBMS_LOGMNR.CONTINUOUS_MINE);

2. 手动方式

   手动方式添加重做日志文件是通过DBMS_LOGMNR.ADD_LOGFILE过程来完成，注意前后添加的所有日志文件必须源于同一数据库而且具有相同的数据库RESETLOGS SCN，该方法不需要LogMiner连接到源数据库。

例如，开始指定一个新的重做日志文件列表，如下：

SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -

  LOGFILENAME => '/oracle/logs/log1.f', -

  OPTIONS => DBMS_LOGMNR.NEW);

   在这个基础上添加其他的重做日志文件：

SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -

   LOGFILENAME => '/oracle/logs/log2.f', -

   OPTIONS => DBMS_LOGMNR.ADDFILE);

注：可以查询V$LOGMNR_LOGS视图获得LogMiner当前分析的重做日志文件序号。

1.4 补充日志

          重做日志文件通常用于实例恢复和介质恢复，然而，基于重做日志的应用可能需要被记录在重做日志文件中的附加列值，这些附加列值的信息被称为补充日志。默认情况下，Oracle数据库是不提供任何补充日志的，所以，在LogMiner之前至少要开启最小补充日志：

补充日志分为：数据库级补充日志和表级补充日志。

1.4.1 数据库级补充日志

        数据库级补充日志有2种：最小补充日志和标识键补充日志，最小补充日志对数据库生成重做日志文件的开销没有显著影响。然而，启用数据库的标识键补充日志会增加数据库生成日志文件的开销，Oracle建议至少使LogMiner最小补充日志。

1. 最小补充日志

   最小补充日志记录了LogMiner用来解析重做日志中的DML操作的最少的数据信息，它使得LogMiner（以及其他基于LogMiner技术的产品）有足够的信息来支持行链接和各种存储方式，如簇表和索引组织表。

启用最小补充日志如下（Oracle 9.0.1默认启用最小补充日志，之后的版本则需要自行开启）

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

2. 标识键补充日志

   当重做日志文件不允许在源数据库进行分析时，比如要在逻辑备库进行数据分析，则标识键补充日志就派上了用场。另外，可以通过指定一个或者多个ALTER DATABASE ADD SUPPLEMENTAL LOG中如下的参数来记录所有update操作的数据库广度的前像。

•  ALL

这个参数表明只要一行数据被修改，该行其他列值（除了LOBS.LONGS,ADPS类型）都将被记录在重做日志文件中。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

•  PRIMARY KEY

   当包含主键的行数据被修改，指定该参数会使该行其他列的值被记录到重做日志文件中，即便主键值没有被修改。当表中没有主键，但是有一个或者多个非空唯一约束或者索引键，那么其中一个唯一索引列会被选中作为执行update的唯一标识键。如果表既没主键也没有非空唯一索引键，除了LONG和LOB列都将记录为补充日志，相当于指定ALL参数的效果。因此，Oracle建议使用数据库级的主键补充日志，所有或者多数表必须拥有主键或者唯一索引键。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

•  UNIQUE

   指定该参数，数据库将发生更改操作的行数据的所有列值以复合唯一键或者位图索引的方式记录在重做日志文件中，唯一键可以是唯一约束或唯一索引。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY) COLUMNS;

• FOREIGN KEY

如果包含外键的列值发生修改操作，指定该参数，数据库将该行所有的列值记录到重做日志文件中。

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY) COLUMNS;

  注意：不管是否启用了标识键补充日志，LogMiner返回的SQL中都有ROWID列，如果不想要，可以通过DBMS_LOGMNR.START_LOGMNR指定NO_ROWID_IN_STMT过滤掉。

在数据库open状态下开启标识键补充日志，会使游标缓存中的DML游标失效，直到游标缓存重新生成才生效。

   开启标识键补充日志也会默认启用最小补充日志，另外，标识键补充日志是可以累加的，比如，可以同时开启主键和唯一键的补充日志。

3. 关闭数据库级补充日志

使用ALTER DATABASE DROP语句来关闭数据库级补充日志：

SQL> ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

SQL> ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;

注意：关闭最小补充日志之前，必须关闭所有标识键补充日志，否则返回ORA-32589。

1.4.2 表级补充日志

   表级补充日志指定在表中哪些列将被记录到补充日志中，可以使用标识键补充日志或者用户定义的有条件和无条件的补充日志组来记录补充日志信息。

1. 标识键补充日志

   与数据库级标识键补充日志一样，表级标识键补充日志也有all，primary key，foreign key，and unique key关键字选项，但是，这些关键字选项用在表级时只对指定的表有影响，如下对employees表用表级ALL标识键补充日志，那么只有该表某列值改变时它所在的行数据（除了LOB，LONGs，和ADTs类型数据）都将被记录在重做日志文件中。

SQL> ALTER TABLE HR.EMPLOYEES ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

   注意：表级标识键补充日志一旦被应用到某个表，那么游标缓冲池这个表所有的DML游标都将失效直到游标缓冲池被重建，另外不同类型的表级标识键补充日志也是可以累加的。

2. 表级自定义补充日志组

   除了表级标识键日志，Oracle还支持自定义补充日志组，用户可以通过它指定哪些列使用补充日志，可以指定有条件或者无条件日志组。

• 自定义无条件日志组

   创建一个hr.employees表上employee_id、last_name和department_id组和列的，名为emp_parttime的日志组，只要该表执行update，不管update跟这3列有无关系，这3列都会被记录到日志组中。

SQL> ALTER TABLE HR.EMPLOYEES

     ADD SUPPLEMENTAL LOG GROUP emp_parttime (EMPLOYEE_ID, LAST_NAME,

     DEPARTMENT_ID) ALWAYS;

•  自定义有条件补充日志组

   创建一个hr.employees表的名为emp_fulltime的日志组，同样是针对employee_id、last_name和department_id组和列，但是因为没有ALWAYS子句，所以这些列值的前像只有当3列中至少其中一列的值发生update才会被记录到日志组中。

SQL> ALTER TABLE HR.EMPLOYEES

     ADD SUPPLEMENTAL LOG GROUP emp_fulltime (EMPLOYEE_ID, LAST_NAME,

     DEPARTMENT_ID);

   不管是有条件还是无条件自定义补充日志组，都可以通过NO LOG参数来显示指定某列不要记录到补充日志中，但是使用NO LOG参数的前提是必须是指定至少一列是没有使用NO LOG参数的。

SQL> ALTER TABLE HR.EMPLOYEES

     ADD SUPPLEMENTAL LOG GROUP emp_parttime(

     DEPARTMENT_ID NO LOG, EMPLOYEE_ID);

  注意，表中的列可以同属多个补充日志组，但是，列值的前像只被记录一次，如果某列同时被指定为有条件和无条件，那么只会被记录在无条件日志组中。

1.5 LogMiner字典DDL语句追踪

           LogMiner自动建立自身的内部字典，这个字典提供数据库对象及其定义的快照。如果LogMiner字典是在线模式或者OS文件，可以使用DBMS_LOGMNR.START_LOGMNR的DDL_DICT_TRACKING参数来跟踪DDL语句。

SQL> EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => - DBMS_LOGMNR.DDL_DICT_TRACKING +   DBMS_LOGMNR.DICT_FROM_REDO_LOGS);

  注意，启用补充日志和DDL跟踪，LogMiner返回的结果就不会是二进制数据。有DICT_FROM_ONLINE_CATALOG情况下DDL_DICT_TRACKING参数无效，DDL_DICT_TRACKING参数使用时数据库必须是OPEN状态的，而且必须启用补充日志或是目标表的日志组已经创建。

   DDL_DICT_TRACKING启用后，在LogMiner字典创建后执行的DML都可以正确显示。例如，employees表连续执行了增加列gender和删除commission_pct列的操作，LogMiner会记录表变化前后的信息，但是引起变化的SQL_REDO和SQL_UNDO信息则没有。因为LogMiner会自动匹配数据库元数据版本，并及时发现并通知用户重作日志文件中的字典信息与它自身的内部字典信息不一致，然后生成如V$LOGMNR_CONTENTS视图中SQL_REDO列的二进制数据，INFO列显示“Dictionary Version Mismatch”，STATUS列值为2.

注意：LogMiner内部字典会自行更新，但以任何形式存在的LogMiner字典则不会。

1.5.1 DDL_DICT_TRACKING与补充日志设置

           如果启用了DDL_DICT_TRACKING而未启用补充日志，那么当重做日志文件中包含了DDL事务，V$LOGMNR_CONTENTS视图的查询将返回ORA-01347错误；而当重做日志文件包含了DML事务，那么LogMiner不能确定字典中表的当前版本是否正确，V$LOGMNR_CONTENTS视图的SQL_REDO显示为二进制数据，TATUS列值为2，INFO列显示“Dictionary Mismatch”。

   如果DDL_DICT_TRACKING和补充日志都未启用，而DML相关列值与LogMiner字典一致，那么LogMiner会认定其字典中的最新版本是正确的，V$LOGMNR_CONTENTS中的SQL_REDO和SQL_UNDO会由LogMiner根据字典中该对象的定义来生成，INFO列显示“no supplemental log data found”，STATUS列值为3（表明SQL可能有误）.

   如果DDL_DICT_TRACKING和补充日志都未启用，而且重做日志文件中的表发生修改的数据超过LogMiner字典中该表的定义，那么SQL_REDO和SQL_UNDO值为“Dictionary Version Mismatch”，STATUS列值为2（表明SQL无效），INFO列显示“Dictionary Mismatch”.

本文参阅Oracle官方文档翻译，不足之处欢迎批评指正！

LogMiner简介

标签：

原文地址：http://blog.csdn.net/u010257584/article/details/51328624