生产案例：突然产生大量的归档日志，导致磁盘空间满了无法登陆数据库
早上吃完早饭打开电脑，突然告知数据库无法登陆，马上打开终端连接数据库，报如下错误
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后，问题解决，一切恢复正常。
