DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳
2024-07-21 02:05:59
供稿：网友
最近一直头疼于dataguard环境中万一网络失败将导致的primary库短时间内无法正常工作的问题。
这个问题的现象基本上是这样：
当primary和standby之间的网络出现问题，比如说在测试环境中我们拔掉standby的网线，此时当primary发生日志切换（log switch）的时候，primary将试图通知standby同样作归档，但是由于网络不通，就会默认有30秒的timeout，而在这30秒的时间内，primary上的任何dml操作都将被悬停。
至今为止我还没有找到很好的办法可以有效地缩短这个timeout时间，虽然按照文档上说应该可以缩短到最小15秒。即使是15秒，也是无法忍受的，特别是如果dataguard环境搭建在wan上，比如说通过2m的ddn专线，那么出现网络故障的几率是比较高的。
如果说将有可能由于dataguard的网络原因而导致主业务库的操作悬停，无论对于客户还是对于我个人而言都是不太容易接受的。
wan上的网络故障几率较大，那么如果我们换到lan上，就可以降低这种故障的发生率。由此想到可以利用dataguard中的cascaded redo log destinations功能。今天作了此项测试，效果还是很理想的。
所谓cascaded redo log destinations功能，是指a机器（primary）将redo数据传递给b机器（standby），然后b机器再将接收到的redo传递给c机器（standby），这种中转方式在physical standby和logical standby中都可以实现。如果a，b处于同一个lan中，而b，c则通过wan通信，那么即使wan出现网络问题，也不会影响a将redo传递到b，也就不会影响a的业务进行。
大概配置如下：
1。a (primary)的init参数：
*.log_archive_dest_1='location=/oradata/ctsdb/archive'
*.log_archive_dest_2='service=ctsdb.jumper lgwr async=20480 net_timeout=15 max_failure=2 reopen=10'
2。b (standby1)的init参数：
*.log_archive_dest_1='location=/oradata/ctsdb/archive'
*.log_archive_dest_2='service=ctsdb.standby'
*.standby_archive_dest='/oradata/ctsdb/archive'
3。c (standby2)的init参数：
*.log_archive_dest_1='location=/oradata/ctsdb/archive'
*.standby_archive_dest='/oradata/ctsdb/archive'
*.fal_client='ctsdb.standby'
*.fal_server='ctsdb.jumper'
其它的配置文件，比如listener.ora和tnsnames.ora，不再赘述。
在b机器上的alertlog中一些比较有趣的地方：
thu jan 13 12:05:27 2005
rfs: successfully opened standby logfile 4: '/oradata/ctsdb/redo04.log'
thu jan 13 12:05:33 2005
rfs: successfully opened standby logfile 5: '/oradata/ctsdb/redo05.log'
thu jan 13 12:05:38 2005
rfs: successfully opened standby logfile 6: '/oradata/ctsdb/redo06.log'
rfs: successfully opened standby logfile 7: '/oradata/ctsdb/redo07.log'
rfs: no standby redo logfiles of size 6144 blocks available
以前的测试和freelists中的一些邮件列表的讨论都表明在dataguard环境中我们最多只能使用到2组standby redolog（一般情况我们只会只用到1组），这是因为oracle对于srl的启用机制就是从首个srl开始找第一个可以使用的，正常情况下只有在接受下一次redo信息时，redo04.log还没有被归档成功，这时候才会使用redo05.log，而redo05被写满以后，redo04还没有被归档结束的情况我们几乎不可能碰到，所以下一次的redo信息又被写到redo04中。
而这次测试，由于b和c之间的网络中断，导致redo04－redo07这四组srl都被启用了，并且再接下去rfs报了no standby redo logfiles的错误，这个同样很明显地表示了如果网络中断，在timeout时间内，redo是无法被正常归档的。
那么大家可能要问，如果b的4组srl都无法使用了，a继续传过来的redo数据是不是也会被阻塞，从而也间接导致了a同样无法正常继续业务？
在测试之前，我也同样担心这个问题，但是测试表明这种情况没有出现。原因在于dataguard的机制是，即使a指定了使用lgwr传递redo（如本例所示），如果出现b上的srl无法使用的情况，b的rfs进程将把接受到的redo直接写入本机的archivelog中，当a开始归档的时候，b同时归档刚才写入了数据的archivelog（此归档的sequence比a上归档的sequence大1）。从下面的alertlog中可以确认这点：
arc1: evaluating archive log 6 thread 1 sequence 600
arc1: beginning to archive log 6 thread 1 sequence 600
creating archive destination log_archive_dest_2: 'ctsdb.standby'
creating archive destination log_archive_dest_1: '/oradata/ctsdb/archive/1_600.dbf'
arc1: completed archiving log 6 thread 1 sequence 600
从以上的测试中我们得出一个结论，只要是primary可以跟standby的rfs进程正常通信，那么就不会产生操作被悬停的问题，不管standby到底是使用了srl还是使用了archivelog。
最后，由于这样的环境添加了额外的机器（机器b），而由于dataguard环境必须要求同构，所以如果整个环境是unix的，那么也许大家要问，这样岂不是需要再购买一台小型机，这在budget方面是不是就有些问题了。
确实，需要额外的投入，但是由于b机器只是作中转redo的作用，所以我们甚至可以不将b置于managed recover模式下，也就是b只负责接受a的redo，再把redo传送到c，这样对于b机器的性能要求就可以下降很多，也许一台普通的sunray工作站就可以满足要求了。至于是不是确实可以满足性能需求，我还会有后续的测试。
呵呵，敬请期待。本文来源于网页设计爱好者web开发社区http://www.html.org.cn收集整理，欢迎访问。
