利用达梦DBMS_LOGMNR包挖掘归档日志

 

　　使用场景：工作中如果误删除了一张表，又没有对这张表做备份（即使做了备份也只能恢复到备份时的状态），只要开了归档，做了备份，就可以通过时间或者LSN来做还原，把数据库状态还原到某个时间点或某个LSN，是的，只能做全库还原，不支持单独还原某个表。如果不清楚具体时间点或者LSN的值，可以通过DBMS_LOGMNR来定位。
　　DBMS_LOGMNR包对归档日志进行挖掘，重构出 DDL 和 DML 等操作，并通过获取的信息进行更深入的分析。找到你删除表的语句，定位到自己到底是什么时候删除的那张表，就可以操作还原了。
　　DBMS_LOGMNR包使用方式参考《DM8系统包使用手册.pdf》，分析结果在动态视图 V$LOGMNR_CONTENTS中，该动态视图字段说明等可以参考《DM8系统管理员手册.pdf》。

一、查看当前数据库是否开启归档

　　select arch_mode from v$database;

　　

 　　我当前数据库开启了归档。如果没有开启归档，有许多方式可以开启，一般是用disql开启，如下：

　　　　1)修改数据库为 MOUNT 状态。
　　　　　　ALTER DATABASE MOUNT;
　　　　2)配置本地归档。
　　　　　　ALTER DATABASE ADD ARCHIVELOG 'DEST = E:\dmdbms\data\DAMENG\arch, TYPE = local,FILE_SIZE = 1024, SPACE_LIMIT = 2048';
　　　　3)开启归档模式。
　　　　　　ALTER DATABASE ARCHIVELOG;
　　　　4)修改数据库为 OPEN 状态。
　　　　　　ALTER DATABASE OPEN;

　　　　注意：arch文件夹需要提前创建好。

二、查询有哪些归档日志

　　SELECT NAME , FIRST_TIME , NEXT_TIME , FIRST_CHANGE# , NEXT_CHANGE# FROM V$ARCHIVED_LOG;　

　　

 三、查看RLOG_APPEND_LOGIC参数值

　　目前 DBMS_LOGMNR 只支持对归档日志进行分析，配置归档后，还需要将 dm.ini 中的RLOG_APPEND_LOGIC 选项置为 1 或 2。

　　select * from v$dm_ini where para_name ='RLOG_APPEND_LOGIC';

　　

 　　我当前参数值是0，所以需要修改一下。

四、修改RLOG_APPEND_LOGIC参数为1　　

　　alter system set 'RLOG_APPEND_LOGIC'=1 both;
　　select * from v$dm_ini where para_name ='RLOG_APPEND_LOGIC';

　　

 五、重启数据库服务

　　　

 六、再次查看归档日志

　　SELECT NAME , FIRST_TIME , NEXT_TIME , FIRST_CHANGE# , NEXT_CHANGE# FROM V$ARCHIVED_LOG;

　　

　　重启后会创建一个新的归档日志，用新的归档日志去分析才有效。RLOG_APPEND_LOGIC参数默认值是0，这就意味着，想利用DBMS_LOGMNR包分析归档日志去定位误删除的表，前提是已经提前设置RLOG_APPEND_LOGIC=1。

　　这个时候如果再设置RLOG_APPEND_LOGIC=0，重启数据库服务，发现也会再重新创建一个归档日志。现在先不做这个测试。

 七、添加测试数据　

　　drop table test;
　　create table test(id int,name varchar);
　　insert into test values(1,'test1');
　　insert into test values(2,'test2');
　　commit;
　　select * from test;

八、分析归档日志　

　　1) 查询有哪些归档日志
　　　　SELECT NAME , FIRST_TIME , NEXT_TIME , FIRST_CHANGE# , NEXT_CHANGE# FROM V$ARCHIVED_LOG;
　　2) 添加一个或多个需要分析的归档日志文件
　　　　DBMS_LOGMNR.ADD_LOGFILE('E:\dmdbms\data\DAMENG3\arch\ARCHIVE_LOCAL1_0x606C7ADA[0]_2021-07-20_18-18-14.log')
　　　　如要 看通过ADD_LOGFILE添加的归档日志文件，可以通过动态视图V$LOGMNR_LOGS 进行查询，如下：
　　　　SELECT LOW_SCN, NEXT_SCN, LOW_TIME, HIGH_TIME, LOG_ID, FILENAME FROM V$LOGMNR_LOGS;
　　3）启动归档日志文件分析
　　　　DBMS_LOGMNR.START_LOGMNR(OPTIONS=>2128 , STARTTIME=>TO_DATE('2021-03-04 17:36:00','YYYY-MM-DD HH24:MI:SS') , 　　　　ENDTIME=>TO_DATE('2021-07-21 17:36:02','YYYY-MM-DD HH24:MI:SS'));
　　　　如要查看归档日志文件的分析结果，可以通过动态视图 V$LOGMNR_CONTENTS 进行查询，如下：
　　　　SELECT OPERATION_CODE , SCN, SQL_REDO , TIMESTAMP ,SEG_OWNER, TABLE_NAME FROM V$LOGMNR_CONTENTS ;
　　4）终止归档日志文件分析
　　　　DBMS_LOGMNR.END_LOGMNR();

　　

 九、附加测试

　　1)再次重启数据库服务，发现没有新建归档日志。

　　2）终止归档日志文件分析，执行第八步，重新执行归档日志分析，发现有时候会再创建了一条归档日志。这种时候需要改为分析最新的归档日志文件。也又时候不会创建新的归档日志文件，没找到具体规律。

 　　3）如果RLOG_APPEND_LOGIC=0的话，无论启动多少次归档日志文件分析，都不会创建新的归档日志。

十、总结

　　　　1）只有当RLOG_APPEND_LOGIC=1时，生成的归档日志文件才能用来分析。

　　　　2）状态值为1，执行归档日志文件分析，只能分析执行归档日志这个操作时间点之前的归档日志，如果有新的增删改查操作，需要把新的归档日志文件加入再重新执行才能分析到最新的操作。

　　　　3）我本地数据库版本教老，试了下最新版的达梦数据库，发现多次“终止归档日志文件分析”再“启动归档日志文件分析”不会再创建多个归档日志文件了。

　　　　比如我先开启归档，这个时候会创建一个归档日志文件，这时RLOG_APPEND_LOGIC=0。接着我把RLOG_APPEND_LOGIC设置为1，然后重启数据库服务，这个时候又创建了一个归档日志文件，也就是当前有两个归档日志文件。如果我再把RLOG_APPEND_LOGIC设为0，然后重启数据库服务，这时也创建了一个归档日志文件，也就是当前有三个归档日志文件。我再次把RLOG_APPEND_LOGIC设置为1，然后重启数据库服务，这个时候又创建了一个归档日志文件，也就是最后实际上有四个归档日志文件。我随便测试下增删改查操作，然后执行第八步，启动归档日志文件分析，这个时候可以查出我刚刚的增删改查操作。接着我又执行新的增删改查操作，这时查不到，只能“终止归档日志文件分析”后再“启动归档日志文件分析”，这样就可以查到我最新的增删改查操作了。这个过程中，始终只有四个归档日志文件，也就是最终最近的操作都存储在第四个归档日志文件中。

　　

　　尴尬，在写完这篇博客后，我又发现了一个更简单的处理误操作的方式。如下，查询系统执行的 SQL 历史信息：

　　SELECT SESS_ID,TOP_SQL_TEXT,TIME_USED FROM V$SQL_HISTORY;

 

 

 

更多资讯请上达梦技术社区了解： https://eco.dameng.com