oracle 归档日志查看方法--logminer

环境： AIX6.1 Oracle 11g RAC 故障： 数据库频繁出现归档日志空间不够，导致数据库无法登陆的故障。一查发现原因是归档日志切换频繁，操作系统空间不够。 确定原因：

[aix01@oracle]/oracle>df -g
1. Filesystem GB blocks Free %Used Iused %Iused Mounted on
   
2. /dev/hd4 0.50 0.28 44% 13674 17%/
   
3. /dev/hd2 3.00 0.67 78% 49208 23%/usr
   
4. /dev/hd9var 1.00 0.37 63% 9285 10%/var
   
5. /dev/hd3 2.00 1.03 49% 2407 1%/tmp
   
6. /dev/fwdump 1.00 0.99 2% 30 1%/var/adm/ras/platform
   
7. /dev/hd1 0.25 0.18 28% 465 2%/home
   
8. /dev/hd11admin 0.25 0.25 1% 5 1%/admin
   
9. /proc - - - - - /proc
   
10. /dev/hd10opt 0.50 0.28 44% 10241 14%/opt
    
11. /dev/livedump 0.25 0.25 1% 12 1%/var/adm/ras/livedump
    
12. /dev/oraclelv 30.00 11.29 63% 161681 6%/oracle
    
13. /dev/installlv 15.00 3.38 78% 6478 1%/install
    
14. /dev/crslv 10.00 3.35 67% 7807 1%/crs
    
15. /dev/wmsapplv 30.00 17.49 42% 15537 1%/wmprod
    
16. /dev/archivelv 29.25 29.25 1% 4 1%/arch1
    
17. /dev/backuplv 400.00 107.13 74% 306 1%/sysbackup
    
18. aix02:arch2 30.25 0.64 99% 3 1%/arch2

可以看到，/arch2里文件系统空间已经达到99%，/arch2是用来存放归档日志的文件系统，进而导致数据库出错。

提出问题：
这下问题来了，/arch2的空间是30G，每天备份脚本都会自动rman备份归档日志，并自动清除归档日志文件，按照正常情况下，数据库不可能一天产生这么大的归档日志量。

如何查询归档日志都是由什么应用产生的，这就是logminer的用途。

使用方法：

1. -- 1.指定要分析的日志文件
   
2. exec sys.dbms_logmnr.add_logfile(logfilename=> '/arch2/2_825_733092736.dbf',options => dbms_logmnr.new);
   
3. 
   
4. -- 2.使用本地的在线数据字典分析归档日志
   
5. exec sys.dbms_logmnr.start_logmnr(options=> sys.dbms_logmnr.dict_from_online_catalog);
   
6. 
   
7. -- 3.查询分析出来的归档日志内容，例如统计最大修改量的Schema
   
8. select seg_owner,count(*)from v$logmnr_contents group by seg_owner;
   
9. 
   
10. -- 4.增加别的日志文件
    
11. exec sys.dbms_logmnr.add_logfile(logfilename=>'/arch2/2_825_733092736.dbf');
    
12. 
    
13. -- 5.结束分析归档日志
    
14. exec sys.dbms_logmnr.end_logmnr;

下面是具体的过程：

1. SQL> exec sys.dbms_logmnr.add_logfile(logfilename=> '/arch2/2_825_733092736.dbf',options => dbms_logmnr.new);
   
2. 
   
3. PL/SQL procedure successfully completed
   
4. 
   
5. SQL> exec sys.dbms_logmnr.start_logmnr(options=> sys.dbms_logmnr.dict_from_online_catalog);
   
6. 
   
7. PL/SQL procedure successfully completed

  SQL> select seg_owner,count(*) from v$logmnr_contents group by seg_owner;

SEG_OWNER                          COUNT(*)
-------------------------------- ----------
                                       2237
SYS                                     688
TMS                                      60
SPHSY                                    70
SINOSYNEW                                30
SINOSY                                  381
WAS                                 4551934

7 rows selected

SQL> execute dbms_logmnr.end_logmnr ;

PL/SQL procedure successfully completed

结论：

从上面查询结果可以看出操作量最大的用户是WAS用户，再具体看下v$logmnr_contents可以发现基本修改的内容是一致的。
与开发人员沟通后，最终确认是一个执行update过程存在问题，where条件未正确定位到记录，每执行一次都会导致大规模的修改数据。

延伸：
LogMiner使用示例
http://hi.baidu.com/dba_hui/blog/item/48bc365f6d7582c79d8204eb.html