今天本来下班快要走了，结果开发人员说他们有个测试表的数据突然不见了，而且说应该是没有人delete，问我是不是oracle的Bug（这个
今天本来下班快要走了，结果开发人员说他们有个测试表的数据突然不见了，而且说应该是没有人delete，问我是不是Oracle的Bug（这个有点搞吧，这都想得出来，哈哈），，让我帮看一下，没法只能使用logminer来分析日志了：
1、 修改utl_file_dir参数为一个特定目录，或者修改为*（建议，这样就可以访问所有oracle用户可以访问的目录，修改这个参数需要重启生效！）
2、 执行一下脚本初始化logminer环境
4、 添加日志文件，可以使归档日志也可以使在线redo日志，由于这个数据库没有起归档，所有就使用online redo日志来分析，还好他们没有做压力，日志没被切换掉：
5、 使用第三步中生成的数据字典开始分析日志，可以使用scn参数分析从多少scn号至多少scn号之间的日志
经查看sql_redo，发现他们在2012-02-22 19:52:22时对那个表做了663个delete操作，亏他还还想得起来。呵呵。
7、 使用以后可以使用EXECUTE DBMS_LOGMNR.END_LOGMNR 清空v$logmnr_logs及v$logmnr_contents的内容
8、 附加：
当使用logminer挖掘日志时，可能出现sql_redo值为UNSUPPORTED的内容信息，这时可以打开数据库的追加日志选项：
查询数据库级别的日志追加选项是否已经开启：
这里启用minimal logging，一般做到这一步，logminer就拥有足够的信息分析所有所做过的操作。
禁用Supplemental Logging：
启用表级别的追加日志，如：
