一、故障背景
近日，我司在某银行的驻场运维团队收到客户的故障申请，称数据库业务出现异常。该数据库每天都要进行跑批操作，今天进行操作时数据库却hang住没有反应。
安图特团队在收到客户的请求后进行了详细的分析，并制定了解决方案，经客户认可后正式申请变更，得到批准后，在预定的维护时间内完成了此次故障处理，得到了客户的好评。
二、故障处理
操作系统版本：AIX 6100
数据库版本： Oracle 11g 单机 11.2.0.4
1、首先检查数据库alert日志，报错信息如下：
日志报错显示闪回区满，无法从闪回区中分配新的闪回日志。
2、检查闪回区设置：
闪回区大小为20G。
3、检查文件系统使用情况，使用情况如下：
闪回区所在的文件系统还有剩余空间。
4、关闭数据库，并重新启动数据库，并监控alert日志，报错信息如下：
日志中显示闪回区使用率为100%，查看闪回路径下面的闪回日志文件大小，发现日志文件的总大小达到闪回区设置的大小，闪回日志没有被覆盖，闪回区没有循环使用。
5、检查v$restore_point视图，信息如下：
数据库创建了GUARANTEE RESTORE POINT，时间点为2016年5月3日，是当时数据库做升级时创建的强制还原点。
当设置了GUARANTEE RESTORE POINT时，闪回日志是无法被覆盖，闪回日志一直是增长的，当闪回区使用率为100%时，数据库就会hang住，因此需要删除该还原点。
Logging for Flashback Database with Guaranteed Restore Points DefinedIf you enable Flashback Database and define one or more guaranteed restore points, then the database performs normal flashback logging. In this case, the recovery area retains the flashback logs required to flash back to any arbitrary time between the present and the earliest currently defined guaranteed restore point. Flashback logs are not deleted in response to space pressure if they are required to satisfy the guarantee.Flashback logging causes some performance overhead. Depending upon the pattern of activity on your database, it can also cause significant space pressure in the fast recovery area. Thus, you should monitor space used in the fast recovery area.If no files are eligible for deletion from the fast recovery area because of the requirements imposed by your retention policy and the guaranteed restore point, then the database performs as if it has encountered a disk full condition. In many circumstances, this causes your database to halt.
６、删除restore point，信息如下：
7、重新开启闪回，信息如下：
设置guarantee restore point后，flashback database log不会被覆盖，且一直在增加，当闪回空间满后，数据库会hang住。当guarantee restore point不再使用后，需要及时drop掉，否则容易导致空间撑满。细节决定成败，看似简单的一个疏忽就能导致致命的故障，数据库操作无小事，一些细微的问题可能存在严重的隐患，因此每个操作都要小心谨慎，每个修改都不容轻视。
如欲了解更多，请登录安图特官方网站:www.antute.com.cn
您现在的位置：首页 > 典型案例