从摆脱Data Guard手工搭建及维护的烦恼说起(2)

实际上这种方案还是可行的,但是建议是可以作为PLAN B来用,当然希望最好不要有这种情况发生.

有一套一主两备的10gR2环境,一个异机备库一直在READ ONLY状态,也就意味着数据库在打开之后一直没有应用归档,然后在某一天发现时,已经延迟了好几个月.无论怎样,还得庆幸发现了这个问题.

目前来看一种行之有效的方法就是重搭备库,但是这种修复方式需要大量的磁盘空间,而且需要恢复的时间较长,怎么改进呢,可以考虑通过基于SCN的增量备份来跳归档恢复.目前的环境是一主两备,再怎么改进呢,我们可以基于备库1来完成基于SCN的增量备份,在备库2完成恢复,对于主库几乎是完全透明,无影响的.

整个示意图如下,通过在Standby1上面基于SCN导出增量备份,拷贝到备库2上去恢复,最后再和主库汇合即可.

里面的核心用法就是增量备份恢复,说白了好像就那么回事,不过对于工作有帮助就行.

四、与时俱进：Oracle 12c Data Guard改进

Oracle的Data Guard技术在11g中有了Active Data Guard,就产生了很多的技术解决方案,比如读写分离,多活的技术支撑等,客户对于这个特性的喜爱程度很大程度上驱动了数据库的升级.

个人的体验,12c里面的改进有两个亮点,一个就是Far Sync,另外一个就是validate.

先说说Far Sync.以下是来自官方博客提供的一张图,看起来很威武霸气.

这个Far Sync到底是个什么东东,主要就是为了解决远距离的数据传输延迟,而在中间节点创建的一个虚实例,这个实例很特别,只有参数文件,密码文件和控制文件,而且需要特别强调的是没有数据文件.

当然这个特性是一个补充,你如果使用原本的Active Data Guard也全然没有问题.而这个特性可以通过中间节点来过渡,达到了官方所宣称的0数据丢失.

这个特性是不是非常牛叉呢,其实如果大家了解Data Guard的一些知识,本身备库的RFS可以在不存在数据文件的情况下,在mount状态下依然接受归档.

另外我们说说Cascade standby,在一主多备的环境中,当standby与primary的距离较远需要通过WAN来传输Redo时,为减少传输过程中对primary的压力及网络带宽的占用,仅让其中的一个standby从primary直接接收redo.

两者的结合和改进,就是Far Sync了,所以我没有说是一个技术上很大的一个创新,但是却能够给实际工作带来了不少的实惠.

如果已经有了Active Data Guard的环境,启用Far Sync那就很简单了.

下面是一个典型的DG配置情况,使用了DG Broker来统一配置管理.主库是testdb,备库是testdb2.

需要特别强调的是,Far Sync的添加一个关键就是控制文件,这个和备库控制文件有所区别.

我刚开始玩的时候大意了,结果因为这个问题给折腾了不少时间.需引以为戒.

正确的姿势是在主库生成Far Sync的控制文件：

很重要的一个检查项就是检查v$database,输出全然不同.

再次添加Far Sync节点：

当然Far Sync实例本身的资源消耗很小,不需要再给它很高的配置,作为中继节点,保证网络的畅通更加重要.

然后说说validate,这个改进比较贴心,如果需要switchover,是否可行,可以用validate来做一个检查.我对比了12c和11g中的DG Broker命令,唯一较大的差别就是validate,这个预检查还是一个很实用的改进.

五、诊断案例：备库批量查询失败的案例分析

然后给大家分享一个备库批量查询失败的案例,希望对大家分析问题有帮助.

数据库环境是10gR2,一主两备.其中一个备库上每天凌晨会开放一个窗口运行一些批量的查询,会通过crontab来调用DGBroker来在READ-ONLY和ONLINE之间切换.

但是有一天开发的同学突然找到我说,最近几天开始批量查询会频频报错,希望我帮忙查看一下.

错误日志如下,可以看到是一条查询语句.

[2016.03.0604:10:02.352]org.springframework.jdbc.UncategorizedSQLException:PreparedStatementCallback;uncategorizedSQLExceptionforSQL[selectbind_flagfromtest_billingwherecn_master=?];SQLstate[60000];errorcode[604];ORA-00604:erroroccurredatrecursiveSQLlevel1

[2016.03.0604:10:02.352]ORA-16000:databaSEOpenforread-onlyaccess

[2016.03.0604:10:02.352];nestedexceptionisjava.sql.SQLException:ORA-00604:erroroccurredatrecursiveSQLlevel1

[2016.03.0604:10:02.352]ORA-16000:databaSEOpenforread-onlyaccess

[2016.03.0604:10:02.352]

而从数据库层面没有任何的日志报错.

在备库想看看这个问题是否发生.于是根据日志中的语句使用DBA用户(属主是用户acc)查询了一下,发现没有任何问题.

selectbind_flagfromacc.test_billingwherecn_master=?语句可以顺利输出结果.

自己也尝试了dml的情况,错误信息也会有所不同.

SQL>updateacc.test_billingsetbind_flag=0wherecn_master=’660078174′;

updatetest_billingsetbind_flag=0wherecn_master=’660078174′

*

ERRORatline1:

ORA-01552:cannotusesystemrollbacksegmentfornon-systemtablespace’ACC_DATA’

开始理一理思路,之前从来没有反馈过这个问题,而问题是在最近发生的.那么应用端是否在最近有什么变化呢,得到的反馈是在1月中下旬有一次变更,但是这都过去好久了,不足以佐证现在的问题.

而从数据库层面,如果存在问题,那看似只有bug的可能性了,但是查了MOS一圈,发现了几种可能的场景,但是都和目前的情况不符合,目前查到有两种场景,一种是略微复杂的查询,一种是带有dblink的查询.参考链接如下：

DblinkonPhysicalstandby-ORA-16000(DocID1296288.1)

ORA-16000WithASemanticQueryOnARead-onlyDatabase(DocID1928638.1)

目前的情况是这个语句非常简单,实在找不出来可能的原因了.

开发的同事也催的比较紧,但是感觉从数据库层面得到的信息着实有限.无奈之下,开启了手工debug方式.就从alert日志中的那个关于temp的报错开始分析.(在11g会有备库采样数据,这个问题解决就会容易很多了)

（编辑：ASP站长网）