Oracle-DG备库日志应用异常问题分析

问题背景:

接用户报障，一个Oracle DG单实例备库日志应用出现异常，后台alert日志不断提示Unable to create archive log file 报错，需要进行分析排查

问题分析：

查看数据库的后台alert日志，可以看到大量的本地归档创建失败报错，备库已经很久没有出现应用日志恢复Media Recovery的操作

查看归档日志的路径/oradata2_old，空间使用率较低，只有6%没有达到上限，排查空间不足导致的归档创建失败

检查备库的standby log状态，发现全部都是active的状态，怀疑有可能是目录磁盘IO读写出现问题

检查操作系统日志/var/log/message,发现后台出现大量的IO写丢失报错lost page write due to I/O error on dm-4,报错的磁盘都指向dm-4路径，这正是归档路径/oradata2_old目录所在的磁盘

检查到这里，备库日志应用出现异常的原因已被找到，由于归档目录底层的存储磁盘出现IO写异常，导致备库的日志无法正常归档出现日志应用异常的问题

问题解决:

1 首先需要恢复备库正常的日志归档，由于出现IO写异常的目录短时间内没有办法恢复，存储层还在进行排查解决，所以我们先将归档路径临时调整到了磁盘IO正常的目录，确保备库的日志归档正常

复制代码

alter system set log_archive_dest_1='location=/arch/STBY VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=stby';

2 在备库日志归档恢复正常之后，重新启动备库的日志应用，发现部分归档日志已经被删除且没有备份，日志应用出现了gap，只能通过增量备份恢复的方式修复备库恢复数据同步

备库增量恢复步骤如下

a.获取当前备库数据文件里面最小的检查点scn，作为增量备份的起点

复制代码

SQL>  select min(fhscn) from x$kcvfh;

MIN(FHSCN)
------------------------------------------------
136060071643

b.基于a步骤获取的scn，在主库发起增量备份以及备份最新的控制文件，并将备份文件拷贝到备库服务器

复制代码

run {
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
backup incremental from scn 136060071643 database format '/backup/db_incr%U.bak' tag 'forstandby';
backup current controlfile for standby format '/backup/standby_ctl.bak' tag 'forstandby_ctl'; 
release channel c1;
release channel c2;
release channel c3;
release channel c4;
}

c.将备库启动到nomount状态，恢复最新的备份控制文件

复制代码

run{
restore controlfile from '/backup/standby_ctl.bak'
}
--如果控制文件里面的路径跟实际的数据文件路径不一致，需要重新修改为备库路径
--修改datafile路径
--将数据文件作为copy的方式注册到控制文件里面
catlog start with '数据文件所在路径'
--查看注册成功
list copy of database;
--将控制文件里面的数据文件路径切换为实际的数据文件路径
switch database to copy;

d.备库应用增量备份进行恢复

复制代码

run {
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
RECOVER DATABASE NOREDO;
release channel c1;
release channel c2;
release channel c3;
release channel c4;
}

e.备库打开mrp进程应用归档日志同步，重新恢复实时同步

复制代码

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