MSSQL网页编程之DataGuard - 使用Cascaded Redo Log De...
用一个库#bak_database存放这些历史数据。成绩比来一向头疼于DataGuard情况中万一收集失利将招致的Primary库短工夫内没法一般事情的成绩。这个成绩的征象基础上是如许:
当Primary和Standby之间的收集呈现成绩,好比说在测试情况中我们拔失落Standby的网线,此时当Primary产生日记切换(LogSwitch)的时分,Primary将试图关照Standby一样作回档,可是因为收集欠亨,就会默许有30秒的TimeOut,而在这30秒的工夫内,Primary上的任何DML操纵都将被悬停。
至今为止我还没有找到很好的举措能够无效地延长这个TimeOut工夫,固然依照文档上说应当能够延长到最小15秒。即便是15秒,也是没法忍耐的,出格是假如DataGuard情况搭建在WAN上,好比说经由过程2M的DDN专线,那末呈现收集妨碍的概率是对照高的。
假如说将有大概因为DataGuard的收集缘故原由而招致主营业库的操纵悬停,不管关于客户仍是关于我团体而言都是不太简单承受的。
WAN上的收集妨碍概率较年夜,那末假如我们换到LAN上,就能够下降这类妨碍的产生率。由此想到能够使用DataGuard中的CascadedRedoLogDestinations功效。明天作了此项测试,效果仍是很幻想的。
所谓CascadedRedoLogDestinations功效,是指A呆板(Primary)将redo数据传送给B呆板(Standby),然后B呆板再将吸收到的redo传送给C呆板(Standby),这类直达体例在PhysicalStandby和LogicalStandby中都能够完成。假如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.JUMPERLGWRASYNC=20480NET_TIMEOUT=15MAX_FAILURE=2REOPEN=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中一些对照风趣的中央:
ThuJan1312:05:272005
RFS:Successfullyopenedstandbylogfile4:/oradata/ctsdb/redo04.log
ThuJan1312:05:332005
RFS:Successfullyopenedstandbylogfile5:/oradata/ctsdb/redo05.log
ThuJan1312:05:382005
RFS:Successfullyopenedstandbylogfile6:/oradata/ctsdb/redo06.log
RFS:Successfullyopenedstandbylogfile7:/oradata/ctsdb/redo07.log
RFS:Nostandbyredologfilesofsize6144blocksavailable
之前的测试和Freelists中的一些邮件列表的会商都标明在DataGuard情况中我们最多只能利用到2组StandbyRedolog(一样平常情形我们只会只用到1组),这是由于Oracle关于SRL的启用机制就是从首个SRL入手下手找第一个可使用的,一般情形下只要在承受下一次redo信息时,redo04.log还没有被回档乐成,这时候候才会利用redo05.log,而redo05被写满今后,redo04还没有被回档停止的情形我们几近不成能碰着,以是下一次的redo信息又被写到redo04中。
而此次测试,因为B和C之间的收集中止,招致redo04-redo07这四组SRL都被启用了,而且再接下往RFS报了Nostandbyredologfiles的毛病,这个一样很分明地暗示了假如收集中止,在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:Evaluatingarchivelog6thread1sequence600
ARC1:Beginningtoarchivelog6thread1sequence600
CreatingarchivedestinationLOG_ARCHIVE_DEST_2:CTSDB.STANDBY
CreatingarchivedestinationLOG_ARCHIVE_DEST_1:/oradata/ctsdb/archive/1_600.dbf
ARC1:Completedarchivinglog6thread1sequence600
从以上的测试中我们得出一个结论,只需是Primary能够跟Standby的RFS历程一般通讯,那末就不会发生操纵被悬停的成绩,不论Standby究竟是利用了SRL仍是利用了Archivelog。
最初,因为如许的情况增加了分外的呆板(呆板B),而因为DataGuard情况必需请求同构,以是假如全部情况是UNIX的,那末大概人人要问,如许岂不是必要再购置一台小型机,这在budget方面是否是就有些成绩了。
的确,必要分外的投进,可是因为B呆板只是作直达redo的感化,以是我们乃至能够不将B置于managedrecover形式下,也就是B只卖力承受A的redo,再把redo传送到C,如许关于B呆板的功能请求就能够下落良多,大概一台一般的SunRay事情站就能够满意请求了。至因而不是的确能够满意功能需求,我还会有后续的测试。
呵呵,敬请等候。先说DDL的分类。有一类DDL,是不需要重建表的,比如加非聚簇索引。这类操作其实不会丢数据,也是在原表上直接操作,对于我们“以恢复数据为目的”的闪回,是可以先忽略的。另外一类,则是会影响到表数据的操作。 代替了原来VB式的错误判断。比Oracle高级不少。 Mirror可以算是SQLServer的Dataguard了。但是能不能被大伙用起来就不知道了。 你可以简单地认为适合的就是好,不适合就是不好。 having子句的作用是筛选满足条件的组,即在分组之后过滤数据,条件中经常包含聚组函数,使用having条件显示特定的组,也可以使用多个分组标准进行分组。 多加的系统视图和实时系统信息这些东西对DBA挑优非常有帮助,但是感觉粒度还是不太细。 如果处理少量数据,比如几百条记录的数据,我不知道这两种情况哪个效率更高,如果处理大量数据呢?比如有表中有20万条记录. 我们学到了什么?思考问题的时候从表的角度来思考问 另一个是把SQL语句写到服务器端,就是所谓的SP(存储过程);
页:
[1]