Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1365071
  • 博文数量: 416
  • 博客积分: 10495
  • 博客等级: 上将
  • 技术积分: 4258
  • 用 户 组: 普通用户
  • 注册时间: 2005-04-23 22:13
文章分类

全部博文(416)

文章存档

2015年(7)

2014年(42)

2013年(35)

2012年(14)

2011年(17)

2010年(10)

2009年(18)

2008年(127)

2007年(72)

2006年(23)

2005年(51)

分类: Oracle

2015-01-04 12:14:30

环境:
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. -- 2.使用本地的在线数据字典分析归档日志
  4. exec sys.dbms_logmnr.start_logmnr(options => sys.dbms_logmnr.dict_from_online_catalog);

  5. -- 3.查询分析出来的归档日志内容,例如统计最大修改量的Schema
  6. select seg_owner,count(*) from v$logmnr_contents group by seg_owner;

  7. -- 4.增加别的日志文件
  8. exec sys.dbms_logmnr.add_logfile(logfilename=>'/arch2/2_825_733092736.dbf');

  9. -- 5.结束分析归档日志
  10. 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. PL/SQL procedure successfully completed

  3. SQL> exec sys.dbms_logmnr.start_logmnr(options => sys.dbms_logmnr.dict_from_online_catalog);

  4. PL/SQL procedure successfully completed
  5.  
      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

阅读(1101) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

deargentle2015-01-04 12:15:08

select * from v$logmnr_contents