日期：2011-05-02 15:22:00 来源：本站整理

SQL Server数据库技术（106)[MSSQL防范]

赞助商链接

分享到： QQ空间新浪微博腾讯微博人人网

　　本文“SQL Server数据库技术（106)[MSSQL防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
16.4.1 事件复制的特点
????前面我们指出复制的本质就是从源数据库向目标数据库复制数据,但对差别的复制范例而言老是有差别的.从复制的具体内容来看快照复制是真正意义上的数据复制,不管采取何种数据接纳方法（如将表删除后再重建或删除表中数据但保存表构造）,在网络中传送的是数据.而事件复制在网络中传送的是事件（由一条或多条INSERT、 DELETE、 UPDATE）;从传输的数据量来看,事件复制仅将发生的改变传送给订购者,是一种增量复制,但快照复制却将整个出版物复制给订购者.
????由于事件复制要不断地监督源数据库的数据改变,所以与快照复制相比,其服务器负载呼应要重.
????在事件复制中当出版数据库发生改变时,这种改变就会被当即传送给订购者,并在较短时间内完成（几秒或更短）,而不是像快照复制那样要经过很长一段时间隔断.因此,事件复制是一种几近及时地从源数据库向目标数据库分发数据的办法.由于事件复制的频率较高,所以必须保证在订购者与出版者之间要在坚固的网络衔接.
????事件复制只答应出版者对复制数据举行改正（若设置了当即更新订购者选项,则答应订购者改正复制数据）,而不像归并复制那样,全部的节点（出版者和订购者）都被答应改正复制数据,因此事件复制保证了事件的一致性.它所实现的事件一致性介于当即事件一致性和潜在事件一致性之间.
????由于事件复制在极小的时延内把数据分发到订购者,因此要求出版者与订购者老是保持衔接.但在快照复制中,由于相邻两次复制数据的传送隔断时间较长,则答应订购者与出版者没必要保持永久衔接.
????事件复制别的一个独有特点是支持并行的快照处理,这也是sql server 2000 事件复制的新特点.正如在快照复制一节中所论述的那样,普通而言,在成立初始快照文件的整个处理历程中,都要在出版表上安排一个同享锁来禁止对出版的更.新但事件复制所支持的并行快照处理却答应在成立快照文件的整个历程中不必将同享锁保持到快照文件成立完毕之时.其具体历程是:在复制开始时,快照代理在出版表上安排同享锁.当表示快照开始的事件被写入事件日记时,该同享锁即被释放.这样在随后的时间,即便快照文件仍处于生成历程中,仍可以对出版表举行改正.由此可见,同享锁在出版表时持续的时间很短.释放同享锁的时刻恰是快照代理开始成立快照文件的时刻.在完毕快照文件成立时.表明成立完毕的事件被记录到事件日记中.在从开始到完毕的整个快照生成历程中所发生的影响出版表的事件将被日记阅读代理发送到分发数据库.
????并行快照处理固然答应在成立快照文件的历程中对出版表举行改正,但也因此而增添了快照处理的负载,降低了复制处理的性能,所以应在系统活动较少时,举行快照初始化处理.

16.4.2 事件复制的履行步骤
事件复制的履行主要需求三个代理:快照代理、日记阅读代理、分发代理.

1 快照代理
????快照代理从出版者获得新的改变之前,必须使订购数据库的表与出版数据库表具有相同的表构造和数据.因此快照代理首先要实现同步调集的初始化.SQL Server 只有在确认订购者包含表描写与数据的快照文件后,才能举行事件复制.

2 日记阅读代理
从出版者事件日记中搜索出带有复制标志的事件,并将这些事件插入分发数据库.

3 分发代理
分发代理将日记阅读代理插入到分发数据库中的事件分发到订购者.
在事件复制中快照代理和分发代理的具体步骤与快照复制基本相同.事件复制中各代理按照以下的履行次序来调和工作完成事件复制（见图16-53）.
SQL Server数据库技术（106)

（1）当成立订购时或到了成立出版物时,所筹划的时间快照代理就会被履行,快照代理在论文上安排同享锁之后,便成立包含数据文件与描写文件的同步调集.描写文件主如果为了在订购数据库内成立与论文表相同的表构造.然后将:这两个文件存储在分发者的复制目录下,并在分发数据库中记录同步功课.

（2）日记阅读代理可以持续不断地运行或在出版物成立时筹划的时刻运行来监督数据改变.日记阅读代理履行时,它首先阅读出版物的事件日记,搜索出带有复制标志的INSERT、 UPDATE、 DELETE 语句和别的改正事件.接着,日记阅读代理将这些带有复制标志的事件批拷贝至分发者的分发数据库中.日记阅读代理利用系统历程sp_replcmds 从日记中来获得下一批带有复制标志的号令.只有那些被提交的事件才送至分发数据库.

????在分发数据库中的复制事件和出版者事件日记中有复制标志的事件是一一相对的.在 Msrepl_transactions 表中存储的一个事件可由多个号令构成,每一条号令存储在Msrepl_ commands 表中.在整个批事件成功写入分发数据库后,每一号令将被提交代着阅读代理调用sp_repldone 系统历程来标明复制事件终究在那边完成.最后代理标明在事件日记中的哪一行将被截掉.那些仍旧等候复制的行不会被截掉.从出版者删除事件日记并不影响复制,因为只有那未标有复制的事件才会被排除.
（3）事件号令一向存储在分发数据库中,除非分发代理从分发者将其推至订购者数据库或从订购者将其拉到订购者数据库.

注意:分发代理第一次履行时的主要任务是订购初始化,行将初始快照文件分发到订购者.
??????分发代理仅用于复制而不包含任何用户表,同时也不答应在分发数据库中成立任何别的数据库对象.
??????在出版者接待的将被复制的操作将按次序在订购者上被履行、确保数据的终究一致性.
??????假如订购事件出版物但却没有对订购举行初始化,那么在出版者上自动定制的存储历程都不能在订购者上利用.相反必须在订购者手工成立存储历程.

16.4.3 存储历程的复制
????SQL Server 中除了可以复制表以外还可以复制存储历程.在快照复制中,假如论文中包含存储历程,则在复制历程中整个存储历程将从出版者传送到订购者.在事件复制中,假如论文中包含存储历程,则在复制历程中传送给订购者仅是一条存储历程的履行语句,而不是由存储历程的履行而惹起改变了的数据.
????假如某一存储历程在履行后产生的后果集很大,我们会发现仅复制存储历程的履行语句而不是大量的SQL 语句将带来极大好处.没必要再耽忧大量的复制语句会占满分发数据库而惹起事件丧失,也不再会因复制大量的SQL 语句而惹起网络传输性能的下降而感到懊丧.
????下面的例子大概会帮忙用户更为深化地理解复制存储历程的长处.
????假定数据库的利用者打算改正出版物中某一表的10000 条记录的某一列.假如不利用存储历程复制,它的处理历程应是这样的:当这些改正在出版者完成时,日记阅读代理便会从事件日记中读出这些带有复制标志的上10000 条DELETE 语句以及相同数目的UPDATE 语句,并将它们送到分发数据库,分发数据库有限的空间立即显得有些局促起来假如您很不走运的话,分发数据库会被添满而招致复制中止）,然后分发代理再把这20000 条语句分发到订购者,在分发时20000 语句抢先恐后地挤满了网络线路,我想您会领会到那种等候的滋味.
????但是,假如操纵存储历程来实现这一改正,并在您的事件复制论文中添上该存储历程,那么在网上传奉上仅是一条EXEC 语句.
????将一存储历程定义成出版内容并非一件艰难事,只要在图16-31 Specify Articles 对话框中选中Include Store 复选框便可
　　以上是“SQL Server数据库技术（106)[MSSQL防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：

Windows 搭配 IIS7 PHP MySQL 环境

sqlserver索引的原理及索引成立的注意事项小结

SQL Join的一些总结(实例)

SQL的Join利用图解教程

SQL中JOIN和UNION辨别、用法及示例介绍

关于SQL中CTE（公用表表达式）（Common Table Expression）的总结

mysql Out of memory (Needed 16777224 bytes)的错误办理

mysql提醒[Warning] Invalid (old?) table or database name问题的办理办法

mysql启用skip-name-resolve情势时呈现Warning的处理办法

MySQL Order By语法介绍

<b>MySQL ORDER BY 的实现解析</b>

本文地址：