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(存储过程);