点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
日志挖掘可以在源库进行，也可以在其他目标库进行，但需要注意必须是同构操作系统、数据库版本要大于等于源库，字符集也需相同。最常用的还是在源库加载归档日志进行挖掘。
某系统应用程序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。
