SQL Server数据库技术（109)

核心提示：16.4.1 事务复制的特点前面我们指出复制的本质就是从源数据库向目标数据库复制数据，但对不同的复制类型而言总是有差别的，SQL Server数据库技术（109)，从复制的具体内容来看快照复制是真正意义上的数据复制，不管采用何种数据接收方式（如将表删除后再重建或删除表中数据但保留表结构），那么在网上传递上仅是一条EXE

16.4.1 事务复制的特点
　　前面我们指出复制的本质就是从源数据库向目标数据库复制数据，但对不同的复制类型而言总是有差别的。从复制的具体内容来看快照复制是真正意义上的数据复制，不管采用何种数据接收方式（如将表删除后再重建或删除表中数据但保留表结构），在网络中传送的是数据。而事务复制在网络中传送的是事务（由一条或多条INSERT、 DELETE、 UPDATE）；从传输的数据量来看，事务复制仅将发生的变化传送给订购者，是一种增量复制，但快照复制却将整个出版物复制给订购者。
　　由于事务复制要不断地监视源数据库的数据变化，所以与快照复制相比，其服务器负载相应要重。
　　在事务复制中当出版数据库发生变化时，这种变化就会被立即传递给订购者，并在较短时间内完成（几秒或更短），而不是像快照复制那样要经过很长一段时间间隔。因此，事务复制是一种几近实时地从源数据库向目标数据库分发数据的方法。由于事务复制的频率较高，所以必须保证在订购者与出版者之间要在可靠的网络连接。
　　事务复制只允许出版者对复制数据进行修改（若设置了立即更新订购者选项，则允许订购者修改复制数据），而不像合并复制那样，所有的节点（出版者和订购者）都被允许修改复制数据，因此事务复制保证了事务的一致性。它所实现的事务一致性介于立即事务一致性和潜在事务一致性之间。
　　由于事务复制在极小的时延内把数据分发到订购者，因此要求出版者与订购者总是保持连接。但在快照复制中，由于相邻两次复制数据的传递间隔时间较长，则允许订购者与出版者不必保持永久连接。
　　事务复制另外一个独有特点是支持并行的快照处理，这也是sql server(WINDOWS平台上强大的数据库平台) 2000 事务复制的新特征。正如在快照复制一节中所叙述的那样，通常而言，在创建初始快照文件的整个处理过程中，都要在出版表上放置一个共享锁来阻止对出版的更。新但事务复制所支持的并行快照处理却允许在创建快照文件的整个过程中不必将共享锁保持到快照文件创建结束之时。其具体过程是：在复制开始时，快照代理在出版表上放置共享锁。当表示快照开始的事件被写入事务日志时，该共享锁即被释放。这样在随后的时间，即使快照文件仍处于生成过程中，仍可以对出版表进行修改。由此可见，共享锁在出版表时持续的时间很短。释放共享锁的时刻正是快照代理开始创建快照文件的时刻。在结束快照文件创建时。表明创建结束的事件被记录到事务日志中。在从开始到结束的整个快照生成过程中所发生的影响出版表的事务将被日志阅读代理发送到分发数据库。
　　并行快照处理虽然允许在创建快照文件的过程中对出版表进行修改，但也因此而增加了快照处理的负载，降低了复制处理的性能，所以应在系统活动较少时，进行快照初始化处理。

16.4.2 事务复制的执行步骤
事务复制的执行主要需要三个代理：快照代理、日志阅读代理、分发代理。

1 快照代理
　　快照代理从出版者获取新的变化之前，必须使订购数据库的表与出版数据库表具有相同的表结构和数据。因此快照代理首先要实现同步集合的初始化。sql server(WINDOWS平台上强大的数据库平台) 只有在确认订购者包含表描述与数据的快照文件后，才能进行事务复制。

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

3 分发代理
分发代理将日志阅读代理插入到分发数据库中的事务分发到订购者。
在事务复制中快照代理和分发代理的具体步骤与快照复制基本相同。事务复制中各代理按照以下的执行顺序来协调工作完成事务复制（见图16-53）。
(WINDOWS平台上强大的数据库平台)数据库技术（109)（图一）" />
（1） 当创建订购时或到了创建出版物时，所规划的时间快照代理就会被执行，快照代理在论文上放置共享锁之后，便创建包含数据文件与描述文件的同步集合。描述文件主要是为了在订购数据库内创建与论文表相同的表结构。然后将：这两个文件存储在分发者的复制目录下，并在分发数据库中记录同步作业。

（2） 日志阅读代理可以连续不断地运行或在出版物创建时规划的时刻运行来监视数据变化。日志阅读代理执行时，它首先阅读出版物的事务日志，搜索出带有复制标志的INSERT、 UPDATE、 DELETE 语句和其它修改事务。接着，日志阅读代理将这些带有复制标志的事务批拷贝至分发者的分发数据库中。日志阅读代理使用系统过程sp_replcmds 从日志中来获取下一批带有复制标志的命令。只有那些被提交的事务才送至分发数据库。

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

注意：分发代理第一次执行时的主要任务是订购初始化，即将初始快照文件分发到订购者。
　　　分发代理仅用于复制而不包含任何用户表，同时也不允许在分发数据库中创建任何其它数据库对象。
　　　在出版者招待的将被复制的操作将按顺序在订购者上被执行、确保数据的最终一致性。
　　　如果订购事务出版物但却没有对订购进行初始化，那么在出版者上自动定制的存储过程都不能在订购者上使用。相反必须在订购者手工创建存储过程。

16.4.3 存储过程的复制
　　sql server(WINDOWS平台上强大的数据库平台) 中除了可以复制表以外还可以复制存储过程。在快照复制中，如果论文中包含存储过程，则在复制过程中整个存储过程将从出版者传递到订购者。在事务复制中，如果论文中包含存储过程，则在复制过程中传递给订购者仅是一条存储过程的执行语句，而不是由存储过程的执行而引起变化了的数据。
　　如果某一存储过程在执行后产生的结果集很大，我们会发现仅复制存储过程的执行语句而不是大量的SQL 语句将带来极大好处。不必再担心大量的复制语句会占满分发数据库而引起事务丢失，也不再会因复制大量的SQL 语句而引起网络传输性能的下降而感到沮丧。
　　下面的例子也许会帮助用户更为深刻地理解复制存储过程的优点。
　　假如数据库的使用者打算修改出版物中某一表的10000 条记录的某一列。如果不使用存储过程复制，它的处理过程应是这样的：当这些修改在出版者完成时，日志阅读代理便会从事务日志中读出这些带有复制标志的上10000 条DELETE 语句以及相同数目的UPDATE 语句，并将它们送到分发数据库，分发数据库有限的空间立刻显得有些局促起来如果您很不走运的话，分发数据库会被添满而导致复制中断），然后分发代理再把这20000 条语句分发到订购者，在分发时20000 语句争先恐后地挤满了网络线路，我想您会体会到那种等待的滋味。
　　但是，如果利用存储过程来实现这一修改，并在您的事务复制论文中添上该存储过程，那么在网上传递上仅是一条EXEC 语句。
　　将一存储过程定义成出版内容并不是一件困难事，只要在图16-31 Specify Articles 对话框中选中Include Store 复选框即可。