DataGuard ORA-10458 ORA-1196 ORA-1110

问题现象

SQL> startup
ORACLE instance started.


Total System Global Area 1.0689E+10 bytes
Fixed Size    2237776 bytes
Variable Size 6509562544 bytes
Database Buffers 4160749568 bytes
Redo Buffers   16924672 bytes
Database mounted.
ORA-10458: standby database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/oradata/orcl/orcl/system01.dbf'

问题说明

客户环境是Oracle 11.2.0.3版本的DataGuard环境，接到客户保障电话的时候说的是主库本地文件系统无可用空间了，导致数据库hang机。

简单分析后，发现是DG的日志传输服务中断了，standby数据库没有运行，因此在primary库累计了大量的归档日志，因此占用了大量的本地文件系统空间。
---客户机房环境比较有特点，会经常发生断电事故????

既然知道是standby没有运行导致primary库积累了大量归档日志的原因，因此下一步就是启动standby数据库并恢复日志同步，但sqlplus登陆到standby库后执行startup，结果就报了 问题现象 中的错误提示。

问题解决

由于当时standby库是由于服务器断电而被强迫关闭的，因此数据库的一致性肯定是无法保证的，因此还暂时不能直接open standby库。

1、启动standby库到mount阶段
SQL> startup mount
2、启动日志传输服务
SQL> alter database recover managed standby database using current logfile disconnect from session;

然后观察standby库的alert日志，几分钟后发现primary库上的archive log开始被传送到standby ，此时，如果想要将standby库置为open with read only状态，可直接关闭standby库然后重新启动，如：

SQL> shutdown immediate
SQL> startup
SQL> alter database recover managed standby database using current logfile disconnect from session;

心得

遇到问题，切勿手忙脚乱，比如在该case中，如果经验不足，可能上来就是delete archivelog，因为首先想的是恢复业务是第一的；
而我想说的是，在故障发生的紧急时刻，恢复业务肯定是首要任务，不过还是要多动动脑，不要因为一条失误的命令引发后续大量的无谓工作。
在我登陆到primary库上的时候，首先是删除了一份最早期的rman备份，从而释放出了大量的空间，然后随即启动数据库并恢复了业务。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15156791/viewspace-2122880/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15156791/viewspace-2122880/