开始本文的前提是你需要有一套正常运行的Oracle Data Guard,在这里,我使用的版本是11g。

一、环境声明
首先,有几个脚本需要说明:
1. 自动根据次数去执行日志切换的脚本
这个脚本稍后会在主库端执行,用以产生大量的归档序列

2. 根据日志编号移动归档日志的脚本
该脚本稍后会在备库端执行,用以方便的移动拿到的归档日志,从而手动造成GAP的现象

在开始前,你还可以给自己的主库创建几张大表:

二、关于Data Guard的GAP自动修复

1) 开始手动制造日志序列
在主库端执行手动日志切换的脚本:
sh auto_switch_logfile.sh 320

表示自动执行日志切换【320】次。

2) 在备库端
查看日志应用情况:

可以看到,当前SEQUENCE# 【1099】的归档还没有被应用。

用移动脚本移动它:

因为是移动,所以这时候归档目录中应该就没有1099对应的数据文件了。
这时候,GAP就出现了。

这时候备库的DG会被卡住吗?

并不会,因为10g开始的DG有自动的GAP解决机制。

通过备库端的ALERT日志可以更清楚的看到这个过程:

最初的时候:

可以看到,1099的归档通过RFS拿到备库了,并且,日志应用已经到了1098。

接下来,就是1099了,但我们知道1099对应的数据文件已经不在了。
看看Oracle会怎么表现:

可以看到,Oracle发现1099对应的数据文件访问有问题,并且确定了GAP【Media Recovery Waiting for thread 1 sequence 1099】

接下来,Oracle让备库向主库请求1099的数据文件:【Attempting refetch】

可以看到,最后备库重新拿到了1099,并且也应用成功了。

而在备库中查阅这一块的记录的时候,你也会发现有两条1099有关的记录:

这是一个正常的DG在遇到GAP的时候,会发生的事情。
————————————————————————

三、还可能出现的问题

但很多时候,GAP的自动解决机制并不会正常的发生效用,原因有很多,但主要涉及两个大的方面:网络与存储。

存储方面:
1. 主库端是,否还有备库请求的归档日志
2. 备库端的归档目录,是否有足够空间存放即将传过来的归档数据

网络:
0. 主库与备库之间的网络是否连通,带宽是否稳定、顺畅
1. 备库端到主库端的TNS配置是否正确
2. 主库端监听器的SERVICE_NAME与GLOBAL_NAME是否正确
3. 主库端监听器如果不是启用默认的LISTENER与1521端口,那么实例中是否正确配置了LOCAL_LISTENER
4. 主库端实例配置的DB_UNIQUE_NAME是否正确
5. 主库端的服务器/etc/hosts中是否声明了备库端的IP与主机名;或者主库端是否可以解析到备库端的主机名
6. 主库与备库之间是否有防火墙设备,拦下了需要开放的端口?主备库所在的服务器是否也启用了防火墙类的服务拦下了需要开放的端口?

————————————————————————
如果能注意到以上这些问题,应该可以规避掉很多错误。

————————————————————————
Done。

1 thought on “Oracle DG:关于GAP Refetch与可能产生的问题”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

隐藏
变装