一、概述
以前面试的时候总有人问我，印象最深的故障是什么，怎么解决的。我总是找不出一个很好地答案来回答，今天终于有了。2014年7月16日凌晨2点数据库宕机。
二、 故障原因：
闪回恢复区被归档日志沾满，所以导致数据库宕机。
具体根本原因如下：
首先是，NBU服务器内存报警，然后硬件维护—拔掉光纤卡，开机箱检查内存----重启服务器（没插光纤线）----系统找不到磁带驱动器----（Windows系统不稳定）驱动程序没有正确加载，驱动程序掉了----服务器连接不上磁带库-----备份失败----Rman备份失败----没有删除归档日志----归档日志沾满闪回恢复区-----数据库宕机。
还有一个原因：
NBU备份服务器CPU严重过载，超过90%，导致服务器重启，然后驱动程序掉了，连接不上磁带库。。。。。。。。。
二、故障描述：
2014年7月16日凌晨2点，被电话叫醒，值班人说是CBA数据库不能登录了，那是我们的生产数据库，整个生产过程都将停止。我到了现场先查看故障现象，发现CBA应用不能登陆。然后查看系统有没有分区沾满和日志分析，最后查看数据库ALERT日志，找到报警信息，说是闪回恢复区被占满，数据库宕机。
四、故障处理：
扩大闪回恢复区的空间，扩大至20G，原先是6G。
五、重点：
故障解决了，可以使用了，和用户解释一下。关键是这次故障的原因是什么，这个花了我一周的时间，最后终于将其解决。
数据库的RMAN备份是通过NBU执行的，由于NBU服务器维护操作，导致连接不上磁带库，造成NBU的RMAN备份失败，进而RMAN脚本为陈工执行就没有删除归档日志，归档日志所在分区是flash_recovery_db分区，这个分区的大小受数据库控制文件的管理，最大值设置为6GB，日常巡检没有这一项，所以没有检查出来。
期间找过LogMiner日志，AWR报表，分析最占内存的查询语句。还有所有应用对数据库的操作，都不得其解。
六、 总结：
花了一周的时间终于找到原因，是NBU备份出错导致的。找原因的过程是印象最深的。终于可以和领导解释一下。领导的反应这里不提了。
七、 编后语：
以上就是我两年DBA生涯遇到的印象最深的故障。幸好没有造成影响，故障排除及时。但是故障原因的排查给我留下了深刻的印象。更换一个内存就能导致这么大的问题。看来服务器独立性很重要啊。至少自己出问题了不会影响其他机器。