oracle 归档日志查看方法--logminer
2016-09-24 23:05
447 查看
环境:
AIX6.1
Oracle 11g RAC
故障:
数据库频繁出现归档日志空间不够,导致数据库无法登陆的故障。一查发现原因是归档日志切换频繁,操作系统空间不够。
确定原因:
[aix01@oracle]/oracle>df -g
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/hd4 0.50 0.28 44% 13674 17%
/
/dev/hd2 3.00 0.67 78% 49208 23%
/usr
/dev/hd9var 1.00 0.37 63% 9285 10%
/var
/dev/hd3 2.00 1.03 49% 2407 1%
/tmp
/dev/fwdump 1.00 0.99 2% 30 1%
/var/adm/ras/platform
/dev/hd1 0.25 0.18 28% 465 2%
/home
/dev/hd11admin 0.25 0.25 1% 5 1%
/admin
/proc -
- - -
- /proc
/dev/hd10opt 0.50 0.28 44% 10241 14%
/opt
/dev/livedump 0.25 0.25 1% 12 1%
/var/adm/ras/livedump
/dev/oraclelv 30.00 11.29 63% 161681 6%
/oracle
/dev/installlv 15.00 3.38 78% 6478 1%
/install
/dev/crslv 10.00 3.35 67% 7807 1%
/crs
/dev/wmsapplv 30.00 17.49 42% 15537 1%
/wmprod
/dev/archivelv 29.25 29.25 1% 4 1%
/arch1
/dev/backuplv 400.00 107.13 74% 306 1%
/sysbackup
aix02:arch2 30.25 0.64 99% 3 1%
/arch2
可以看到,/arch2里文件系统空间已经达到99%,/arch2是用来存放归档日志的文件系统,进而导致数据库出错。
提出问题:
这下问题来了,/arch2的空间是30G,每天备份脚本都会自动rman备份归档日志,并自动清除归档日志文件,按照正常情况下,数据库不可能一天产生这么大的归档日志量。
如何查询归档日志都是由什么应用产生的,这就是logminer的用途。
使用方法:
-- 1.指定要分析的日志文件
exec sys.dbms_logmnr.add_logfile(logfilename
=>
'/arch2/2_825_733092736.dbf',options
=> dbms_logmnr.new);
-- 2.使用本地的在线数据字典分析归档日志
exec sys.dbms_logmnr.start_logmnr(options
=> sys.dbms_logmnr.dict_from_online_catalog);
-- 3.查询分析出来的归档日志内容,例如统计最大修改量的Schema
select seg_owner,count(*)
from v$logmnr_contents
group by seg_owner;
-- 4.增加别的日志文件
exec sys.dbms_logmnr.add_logfile(logfilename=>'/arch2/2_825_733092736.dbf');
-- 5.结束分析归档日志
exec sys.dbms_logmnr.end_logmnr;
下面是具体的过程:
SQL>
exec sys.dbms_logmnr.add_logfile(logfilename
=>
'/arch2/2_825_733092736.dbf',options
=> dbms_logmnr.new);
PL/SQL procedure successfully completed
SQL> exec sys.dbms_logmnr.start_logmnr(options
=> sys.dbms_logmnr.dict_from_online_catalog);
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
AIX6.1
Oracle 11g RAC
故障:
数据库频繁出现归档日志空间不够,导致数据库无法登陆的故障。一查发现原因是归档日志切换频繁,操作系统空间不够。
确定原因:
[aix01@oracle]/oracle>df -g
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/hd4 0.50 0.28 44% 13674 17%
/
/dev/hd2 3.00 0.67 78% 49208 23%
/usr
/dev/hd9var 1.00 0.37 63% 9285 10%
/var
/dev/hd3 2.00 1.03 49% 2407 1%
/tmp
/dev/fwdump 1.00 0.99 2% 30 1%
/var/adm/ras/platform
/dev/hd1 0.25 0.18 28% 465 2%
/home
/dev/hd11admin 0.25 0.25 1% 5 1%
/admin
/proc -
- - -
- /proc
/dev/hd10opt 0.50 0.28 44% 10241 14%
/opt
/dev/livedump 0.25 0.25 1% 12 1%
/var/adm/ras/livedump
/dev/oraclelv 30.00 11.29 63% 161681 6%
/oracle
/dev/installlv 15.00 3.38 78% 6478 1%
/install
/dev/crslv 10.00 3.35 67% 7807 1%
/crs
/dev/wmsapplv 30.00 17.49 42% 15537 1%
/wmprod
/dev/archivelv 29.25 29.25 1% 4 1%
/arch1
/dev/backuplv 400.00 107.13 74% 306 1%
/sysbackup
aix02:arch2 30.25 0.64 99% 3 1%
/arch2
可以看到,/arch2里文件系统空间已经达到99%,/arch2是用来存放归档日志的文件系统,进而导致数据库出错。
提出问题:
这下问题来了,/arch2的空间是30G,每天备份脚本都会自动rman备份归档日志,并自动清除归档日志文件,按照正常情况下,数据库不可能一天产生这么大的归档日志量。
如何查询归档日志都是由什么应用产生的,这就是logminer的用途。
使用方法:
-- 1.指定要分析的日志文件
exec sys.dbms_logmnr.add_logfile(logfilename
=>
'/arch2/2_825_733092736.dbf',options
=> dbms_logmnr.new);
-- 2.使用本地的在线数据字典分析归档日志
exec sys.dbms_logmnr.start_logmnr(options
=> sys.dbms_logmnr.dict_from_online_catalog);
-- 3.查询分析出来的归档日志内容,例如统计最大修改量的Schema
select seg_owner,count(*)
from v$logmnr_contents
group by seg_owner;
-- 4.增加别的日志文件
exec sys.dbms_logmnr.add_logfile(logfilename=>'/arch2/2_825_733092736.dbf');
-- 5.结束分析归档日志
exec sys.dbms_logmnr.end_logmnr;
下面是具体的过程:
SQL>
exec sys.dbms_logmnr.add_logfile(logfilename
=>
'/arch2/2_825_733092736.dbf',options
=> dbms_logmnr.new);
PL/SQL procedure successfully completed
SQL> exec sys.dbms_logmnr.start_logmnr(options
=> sys.dbms_logmnr.dict_from_online_catalog);
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
相关文章推荐
- oracle 归档日志查看方法--logminer
- oracle 00257归档日志错误后续及查看alert.log的方法
- 查看oracle每天产生归档日志的数据量
- 00027.Oracle查看alter日志的位置方法二
- ORACLE 归档日志打开关闭方法
- ORACLE 归档日志打开关闭方法
- oracle归档日志满了的处理方法 (ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 87.41% use)
- ORACLE 归档日志打开关闭方法
- ORACLE正确删除归档日志的方法
- ORACLE 归档日志打开关闭方法
- Oracle 归档日志查看和配置
- 修改Oracle归档日志方法
- 输出设备已满或不可用, 归档程序无法归档重做日志[oracle解决方法]
- Oracle LogMiner工具/数据库日志查看
- ORACLE 归档日志打开关闭方法
- oracle 日志切换归档模式查看归档文件的产生
- 用Oracle归档日志进行恢复方法
- Oracle在Rman备份模式下误删归档日志文件解决方法
- oracle归档日志满的处理方法!
- ORACLE 归档日志打开关闭方法