oracle dataguard备库故障处理一例 -m6米乐安卓版下载

背景介绍

给某职能单位检查oracle数据库的时候，发现dataguard备库并没有启动（ps：该单位没有dba的角色，平日里并没有巡检），备库运行在超融合平台之上，使用的windows操作系统，我试着启动该备库，得到如下提示：

alter database open
*
第 1 行出现错误:
ora-10458: standby database requires recovery
ora-01196: 文件 1 由于介质恢复会话失败而不一致
ora-01110: 数据文件 1: 'd:\app\administrator\oradata\spectra\system01.dbf'

分析步骤

和用户做了一些简单的沟通，得知一个月前该备库从物理机迁移到超融合平台之后，就没再管它，于是乎我打开了备库的alert日志，提示缺少sequence#为22598的归档文件及以后。那么问题基本可以定位为：备库迁移过来之后就没打开过，有大量的归档文件没有传输过来！

处理过程

此时只能祈祷主库的自动清理归档日志脚本没有工作，登录到主库一看，还真就没删除，用户和实施人员的不专业帮了大忙！

1、从主库复制sequence#=22598及之后的归档文件到备库（漫长的等待…）

ctrl c
ctrl v

2、备库rman注册归档恢复目录

rman target /
catalog start with d：\app\log';
yes
select count(*) from v$archived_log;   #检查归档文件是否注册成功

3、备库启动到mount状态，启动恢复

startup mount
alter database recover managed standby database disconnect from session;

4、此时观察备库的alert日志(肉眼可见的速度在追进度)

tail -100f alert.log
media recovery log d:\app\interlib\log\1_234891_1023798854.dbf
media recovery log d:\app\interlib\log\1_234892_1023798854.dbf
media recovery log d:\app\interlib\log\1_234893_1023798854.dbf
media recovery log d:\app\interlib\log\1_234894_1023798854.dbf
media recovery log d:\app\interlib\log\1_234895_1023798854.dbf

5、日志出现如下提示，则代表恢复完成

media recovery waiting for thread 1 sequence 247384 (in transit)

6、取消恢复状态

alter database recover managed standby database cancel;

7、开启数据库，并启动实时应用功能

alter database open
alter database recover managed standby database using current logfile disconnect from session; 

8、测试主备库，确保数据能够实时应用（主库建表插数据，备库查看）

后话

这次多亏了实施人员没有部署主库归档日志自动清理脚本，不然可能就要重搭备库了。那么对我们dba来说，遇到dataguard的环境时，用户如果要求清理归档文件的时候，格外的需要注意，要先验证主备库是否同步正常。我的做法，是在主库建张测试表，看看备库是否能够同步创建。确定dg备库功能正常之后，再对归档文件进行删除