最常用的还是在源库加载归档日志进行挖掘。
二.操作案例
2.1 程序异常造成误删除记录
某系统应用程序BUG，造成数据库丢失了几千条数据，但程序上没有找到对应的删除SQL，需通过日志挖掘定位数据删除的具体操作、时间点等信息。
打开补充日志：
图片
2.2 确认出现问题的时间点
根据业务排查，第一次出现问题的时间点应该在6月5日上午08:30分左右，最后问题时间在6月5日下午17:00左右。
2.3 从数据库视图中查看问题时间段归档的序号
图片
2.4 恢复已删除的归档
当前系统备份由NBU接管，归档备份存储在NBU的存储上，没有在数据库本地，所以恢复时分配通道时要指定NBU相关的环境变量并创建一个本地目录用于存放恢复的归档。
图片
2.5 加载归档文件
第一个加载的归档文件需要使用DBMS_LOGMNR.NEW，后面的不需要。
图片
2.6 执行分析
exec DBMS_LOGMNR.START_LOGMNR(OPTIONS=>DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);2.7 保存分析的数据
由于涉及了多张表的操作，并且数据较多，在存储空间允许的情况下，最好是创建一张临时表存放挖掘出的数据，由于数据量较大，可以对表名和操作类型创建联合索引，避免查询太慢。
图片
2.8 结束挖掘
execute dbms_logmnr.end_logmnr;2.9 按表名和类型检查操作
图片
可以看到，从6月5日8:29开始，总共被删除了4000多条记录。
username，machine等字段为UNKONWN，是由于问题时间段没有开启补充日志，如果启用了还是显示UNKNOWN，那么可能是缺少登录信息，即在挖掘的时间段之前会话已登录了。
注意，这里查询出的SQL并不是和实际执行的SQL完全一致的，是经过数据库转换过的SQL。
