logminer和配置安装logminer为logminer创建单独的表空间跟踪ddl语句设置数据字典将数据字典提取为Flat File将数据字典提取为Redo Log使用联机日志作为数据源(推荐）
分析在线日志挖掘归档日志批量增加分析文件结束分析
以sqlplus / as sysdba登录系统数据库系统，ORACLE默认安装logminer，如果没有安装，执行SQL脚本安装
普通用户执行logminer需要进行赋权
默认情况下logminer生成的表和数据都是在system表空间下，很容易就把system撑爆从而引发问题。
因此需要创建单独的表空间，并制定logminer使用该表空间：
使用logminer需要指定数据字典，在没有数据字典的情况下表，表名和字段名都会显示为Object#1111和col#1,col#2，阅读起来非常的不方便。可以提取数据字典文件，或者使用当前数据库的联机目录作为字典源，目的都是能让logminer“知道”表名和表的字段名
以sqlplus / as sysdba登录，修改数据库spfile参数，并重启数据库（生产环境慎用！）
要特别注意一个问题，我在测试环境上执行这条命令以后，ORACLE大概卡顿了20分钟，最后返回一个提示信息：总线错误（吐核）……还吐核。。你咋不再来二两花生米呢
其实那个错误，从日志里看应该是core dumped，内核已转储，也就是确实遇到了系统问题。此时服务器能正常使用，但是所有跟oracle用户的功能都废了，自然也包括数据库服务器。执行reboot重启也是长时间无反应，接了个显示器一看，服务器已经在那里装死了。16核64G服务器配置应该也不算低。我现在还不确定这个问题是服务器本身就有错误，还是那条命令导致的，反正我是强烈建议在生产环境上慎用。如果真要执行的话，最好先跟信息中心那边协商好，万一真出问题了能直接到机房去按电源重启。
反正我是最后按电源重启解决
这种方式用的比较广泛，大多是异地挖掘，比如数据是在生产环境数据库上，把归档日志拷贝到本地数据库服务器上，只要本地数据库开启了归档并且处于OPEN状态就可以进行分析。但是要注意必须有对应的数据字典。
网络上很多说法都是用DBMS_LOGMNR_D.BUILD把数据字典提取到挖掘数据库的在线日志中，但是我自己试了不行，我觉得原因就是拷贝的归档日志文件中并不包含对应的数据字段，最后解析出来的SQL都是unknown,col#,object#。另外一种可能，就是归档期间内有数据库的重启、重建表空间等操作，导致归档的数据字典和当前的不一致了。因此以后还是做好数据字典的备份
使用联机日志作为数据源，是最快的方式，但是局限是如果表上发生过ddl语句，那么就无法分析ddl之前的SQL。因为联机日志在ddl之后就失效了。
至此logminer的安装完成
依次添加所有的日志文件：
使用联机日志开始执行分析
将日志内容写入物理表
然后就可以查询usr_logmnr.logmnr201912212053中的内容了。
当联机日志达到指定大小后就会转为归档日志，
首先通过rman查看要进行挖掘的归档日志
登录rman拷贝要进行挖掘的归档日志
也可以在sqlplus中通过SQL执行查询归档日志：
然后开始分析拷贝的归档日志，或者也可以直接增加归档日志
然后可以查看归档日志的内容：
当要分析的日志文件比较多时，可以批量增加文件
logmnr分析的结果，在另一个会话中是查询不到的，当分析结束后，建议关闭当前分析过程。释放PGA内存区域