生产案例：突然产生大量的归档日志，导致磁盘空间满了无法登陆数据库

生产案例：突然产生大量的归档日志，导致磁盘空间满了无法登陆数据库

 

早上吃完早饭打开电脑，突然告知数据库无法登陆，马上打开终端连接数据库，报如下错误

sqlplus / as sysdba
ERROR:
ORA-09817: Write to audit file failed.
SVR4 Error: 28: No space left on device
ORA-01075: you are currently logged on

很明显几个单词NO SPACE，赶忙看系统df -h 果然100%没了，第一反应，是归档日志占满了空间，数据库不会增长那么快，所以到归档日志目录里发现很多很多归档日志；

为了让业务人员能马上连上数据库使用，先手动删除了部分归档日志，腾出一点点空间，但是没多久空间又满了，然后去看归档日志目录，发现每个6秒就要生成一个归档日志文件，每一个文件大小187M，这很吓人，

分分钟就把磁盘占满。

马上查看每天的归档日志量，发现昨天到今天，每天大概有600多G，而平时差不多1g不到，马上就问业务最近在做什么操作，说他们在把其它业务迁移过来，问题大概知道了，就是因为迁移这个来出问题了。

SELECT TRUNC(FIRST_TIME) "TIME",
SUM(BLOCK_SIZE * BLOCKS) / 1024 / 1024 / 1024 "SIZE(GB)"
FROM V$ARCHIVED_LOG
GROUP BY TRUNC(FIRST_TIME);

 

查看都是最近两天的归档日志，并没有过期的。

select * from v$archived_log

问题排查一，看alert告警日志

查看alter日志后，发现并没有什么异常，只是里面归档很快，伴有日志切换等待，

所以我查看了日志组大小，发现是三个组，每个组200M，应该是够了，为了保险，我增加了两组。

select group#,sequence#,bytes/1024/1024,members,status from v$log; 
 
alter database add logfile group 4 ('/oradata/hhfz/redo04.log') size 200M;
alter database add logfile group 5 ('/oradata/hhfz/redo05.log') size 200M;

 

最后还是没有改变归档日志频率大的问题，所以应该不是这里问题，这不能无休止增加日志组。

 

问题排查二，logminer查看归档日志

到底是什么产生的呢？看看日志写的是啥，所以用oracle自带的logminer查看了一下

--创建logminer数据字典表
@?/rdbms/admin/dbmslm.sql;
@?/rdbms/admin/dbmslmd.sql;
--执行要分析的归档日志
exec sys.dbms_logmnr.add_logfile(logfilename => '/oradata/hhfz_arch/1_5056_912160774.arc',options => dbms_logmnr.new);
exec sys.dbms_logmnr.start_logmnr(options => sys.dbms_logmnr.dict_from_online_catalog);
--查询 归档日志的内容
select seg_owner,count(*) from v$logmnr_contents group by seg_owner;
select count(1),substr(sql_redo,1,60) from v$logmnr_contents group by substr(sql_redo,1,60) order by count(1) desc ;
--增加别的日志文件
exec sys.dbms_logmnr.add_logfile(logfilename=>'/oradata/hhfz_arch/1_5056_912160774.arc');
exec sys.dbms_logmnr.add_logfile(logfilename=>'/oradata/hhfz_arch/1_4986_912160774.arc');
--结束分析归档日志
exec sys.dbms_logmnr.end_logmnr;

 最后查出一些sql，但是业务觉得这些sql不算大，所以并不觉得有啥问题。我也感觉，虽然一直同一个SQL在插入，但是这点应该能承受才对。

 

问题排查三，AWR分析

等了几个小时，AWR的时间点也有了，所以抽取了一个小时的AWR查看，

load profile里的redo size很大，因为有一直在产生归档日志，肯定是日质量很大，所以这点想得到

 

TOP10 的log file sync很大，也正常，因为日志切换很频繁，所以都是同个问题引起的。

 

然后看下面的SQL语句排序，很多个指标无论执行次数与时间，一眼就看出问题来了。马上找业务查该SQL，最后果然是代码里BUG导致，每一条数据都要全表update。

 

 

修改BUG后，问题解决，一切恢复正常。