问题现象
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 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,结果就报了 问题现象 中的错误提示。
简单分析后,发现是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;
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备份,从而释放出了大量的空间,然后随即启动数据库并恢复了业务。
而我想说的是,在故障发生的紧急时刻,恢复业务肯定是首要任务,不过还是要多动动脑,不要因为一条失误的命令引发后续大量的无谓工作。
在我登陆到primary库上的时候,首先是删除了一份最早期的rman备份,从而释放出了大量的空间,然后随即启动数据库并恢复了业务。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15156791/viewspace-2122880/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/15156791/viewspace-2122880/