DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳定性问题
来源:互联网 发布:胜达网络钳子 编辑:程序博客网 时间:2024/05/21 10:45
最近一直头疼于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工作站就可以满足要求了。至于是不是确实可以满足性能需求,我还会有后续的测试。
呵呵,敬请期待。
这个问题的现象基本上是这样:
当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工作站就可以满足要求了。至于是不是确实可以满足性能需求,我还会有后续的测试。
呵呵,敬请期待。
- DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳定性问题
- DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳定性问题
- DataGuard-利用CascadedRedoLogDestinations避免WAN稳定性问题
- Cascaded Destinations/Cascaded Standby Databases
- DataGuard standby redo log 管理
- dataguard 修改redo log 和standby redo log
- 关于Dataguard Online redo log 和 Standby redo log
- 如何修改DATAGUARD的online redo log
- dataguard 下主备 online redo 与 standby redo log resize 重建
- 调整Dataguard环境的Online和Standby Redo Log
- Oracle Dataguard Standby Redo Log的两个实验 --博主
- redo log
- Redo log
- Redo Log
- redo log
- redo log
- rman恢复的方式搭建dataguard后redo log 的处理
- DATAGUARD之Redo传输服务
- 2004.1.13
- 原来叔叔是硬件以及电子方面的专家:)
- 关于Java和C++哪个更快的问题
- 历史回顾——中国各省省名之由来
- DataList控件也玩分页(vb)
- DataGuard - 利用Cascaded Redo Log Destinations避免WAN稳定性问题
- 什么时候需要虚析构函数
- 2005.1.13
- C++中基础类互相引用带来的问题
- 站长必读:防御DDOS攻击终极指南
- 很好的保存网页的工具!
- 使用HttpContext的User属性来实现用户验证
- J2ME学习笔记(七)
- 关于Java编程的一些小知识