DataGuard - 操作Cascaded Redo Log Destinations停止WAN不变性题目
发布时间：2018-08-17 12:46:46 所属栏目：电商 来源：站长网
导读：最近一向头疼于DataGuard情形中万一收集失败将导致的Primary库短时刻内无法正常事变的题目。 这个题目的征象根基上是这样： 当Primary和Standby之间的收集呈现题目，好比说在测试情形中我们拔掉Standby的网线，此时当Primary产生日记切换（Log Switch）的时
|
最近一向头疼于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事变站就可以满意要求了。至于是不是确实可以满意机能需求，我还会有后续的测试。 呵呵，敬请等候。 （编辑：河北网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
热点阅读