对一个地域分散的大型企业组织来说，构建具有典型的分布式计 算特征的大型企业管理信息系统时总要解决一个很棘手的问题；如何 在多个不同数据库服务器之间保证共享数据的完整性、安全性和可用 性。之所以引发这样的问题在于企业组织存在这样的数据处理和要求： 在不同的地点对具有相同结构的本地数据库进行修改；但要保证修改 后的数据库有相同的结果。其实质就是将对本地数据库的修改体现在 其它具有相同结构的远程数据库中。
那么我们如何实现这种数据的一致性呢？答案可能有很多种，但 是包括SQL Server 在内的大多数数据库产品都采用一种复制技术来解 决这一问题。本章的主旨就是介绍SQL Server 的复制技术。下面让我 们从复制的概述开始。
SQL Server 提供了内置的复制能力，复制组件并不是附加产品而是核心引擎的一部 分。在复制这一支持分布式数据处理能力的重要技术帮助下，我们可以在跨局域网、广域 网或因特网的不同数据库服务器上维护数据的多个拷贝，从而自动地以同步或异步的方式 保证数据多个拷贝之间的数据的一致性。从本质上讲，复制就是从一个源数据库向多处目 标数据库复制数据。
16.1.1 SQL Server 的复制模型
SQL Server 使用“出版和订购”这一术语来描述其复制活动。所谓出版就是向其它数 据库服务器（订购者）复制数据。订购就是从另外服务器（出版者）接收复制数据。虽然 出版和订购的对象都是将复制数据，但出版和订购却并不是不同角度（出版者和订购）的 同一数据操作（复制数据），而是体现出一定的层次性和顺序性（总是先进行出版，然后 再进行订购）。SQL Server 的复制组件有出版者、订购者、分发者、出版物与论文、推订 购和拉订购。
（1） 出版物和论文
论文（article） 是被复制的数据集合，一篇论文可以是整个表、某些列（垂直划分的 表）或某些行（水平划分的表）甚至是一些存储过程。论文是出版物的基本组成单元。 出版物是论文和集合，它可以包括一个或多个论文。订购者订购的是出版物而不是出版物 中的论文，这样可使订购更为简单。
（2） 出版者
出版者是指出版出版物的服务器。出版者服务器来维护源数据库（包含出版物）以及 有关出版物的信息，使数据可用于复制。除了决定哪些数据将被复制，外出版者要检测哪 些复制数据发生变化，并将这些变化复制到分发者的分发数据库中。
（3） 分发者
分发者是指把从出版者传递来的复制数据或事务或存储过程送至相应的订购者的服务 器，并负责维护分发数据库。
（4） 合并代理
合并代理（Merge Agent） 被用来移动、合并在快照代理创建初始快照之后所发生的 递增修改，每一个合并出版物都有自己的合并代理。当使用推订购合并出版物时，合并代 理运行在出版者上；当使用拉订购合并出版物时，合并代理运行在订购者上。快照出版物 和事务出版物没有合并代理。
（5） 队列阅读代理
在快照复制或事务复制时如果选择了queued updating 选项或immediate updating with queued updating as a failover 选项，则需要使用队列阅读代理。
队列阅读代理是运行在分发者上的多线程代理，它主要负责从分发者消息队列中读到 消息并将包含在消息中的事务应用到出版者。
16.1.3 SQL Server 的复制类型
SQL Server 提供了三种复制类型：快照复制（Snapshot Replication）、事务复制 （Transactional Replication）、合并复制（Merge Replication）。 可以在实际应用中使用一 种或多种复制类型。每一种复制类型都在不同程度上实现数据的一致性和节点的自主性， 因此对复制类型的选择主要依赖于应用系统对数据一致性、节点自主性的要求以及现有的 网络资源情况（如网宽和网络传输速度）。在分别介绍事务复制、快照复制和合并复制的 三节中我们将讨论如何选择合适的复制类型。下面扼要介绍一下这三种复制类型。
（1） 快照复制
如其名字所言，快照复制意指在某一时刻给出版数据库中的出版数据照相，然后将数 据复制到订购者服务器。快照复制实现较为简单，其所复制的只是某一时刻数据库的瞬时 数据，复制的成功与否并不影响本地数据库（出版数据库或订购数据库）的一致性。在数 据变化较少的应用环境中常使用快照复制，如复制不经常被修改的静态表。
（2） 事务复制
与快照复制不同事务日志复制的内容不是数据而是多条DELETE UPDATE INSERT 语句或存储过程。在使用事务复制时，修改总是发生在出版者上（设置了立即更新订购者 选项的事务复制可在订购者处修改复制数据），订购者只以读取数据的方式将修改反映到 订购数据库，所以能够避免复制冲突。如果数据更新频率较大且希望修改尽快复制到订购 者常使用事务复制。
（3） 合并复制
合并复制允许订购者对出版物进行修改，并将修改合并到目标数据库（可以是出版数 据库也可以是订购数据库）。各个节点可独立工作而不必相互连接，可对出版物进行任何 操作而不必考虑事务的一致性。如果在合并修改时发生冲突，则复制按照一定的规则或自定义的冲突解决策略来对冲突进行分析并接受冲突一方的修改。
16.1.4 复制数据的一致性
在分布式应用环境中事务处理除了满足事务的ACID 要求外，还必须满足数据的一致 性要求。在复制环境下的复制数据的一致性主要有两种类型：
事务的一致性（Transactional consistency）
数据的集中性（Data convergence）
（1） 事务的一致性（Transactional consistency）
在复制环境下，事务的一致性主要是指所有参与复制的节点在复制结束后都必须具有 相同的数据结果集，有如发生在所有节点上的所有的事务在每个节点都被逐一地执行了一 次在SQL Server 中对于复制数据而言有两种级别事务一致性：立即事务一致性（Immediate transactional consistency）、 潜在事务一致性（Latent transactional consistency）
立即事务一致性
立即事务一致性保证所有参于复制事务的节点在任一时刻都有完全相同的数据。在 SQL Server 中通过在所有参与事务处理的节点间使用两阶段提交协议，从而能够在分布 式应用环境下实现事务的一致性。所有节点必须同时提交事务或都不提交事务，事务在任 何一节点提交失败都会导致整个事务在所有节点上都要回滚。很明显这种较为“苛刻”的 事务一致性并不适合有大量节点参与的事务处理，因为网络传输并不可靠而且性能也不稳 定。所以在复制时保证事务的立即一致性就是要求出版数据库和订购数据库必须保持数据 的瞬时同步。
潜在事务一致性
潜在的事务一致性允许数据在出版数据库和订购数据库之间保持异步的一致，即在出 版物发生变化后，经过一定的延时后才将出版物的变化反映到订购者那里。事务在订购者 上提交成功与否并不影响出版者的事务处理。如果出版数据库不再发生新的数据变化，那 么在经过一定的时间间隔后，所有节点都将具有相同的数据结果集。另外，潜在的事务一 致性要求最终的同步数据包含某个站点所做的全部修改，即它要么是节点A 执行完一个 或多个事务后的数据状态，要么是节点B 执行完事务后的数据状态。
立即事务一致性和潜在事务一致性的差别在于：立即事务一致性要求数据立即同步， 而不允许在出版者（源服务器）所发生的数据变化在复制到订购者（目的服务器）之前有 一段等待时间。在SQL Server 中，无论是事务复制，还是快照复制都不要求保证复制立 即事务一致性。事务复制与快照复制相比只是缩短了数据分发出去的等待时间，本质上属 于潜在的事务一致性。
（2） 数据的集中性（Data convergence）
在复制环境下，数据的集中性是指所有节点最终具有相同的数据结果。但与事务一致 性不同，这里的数据结果可能并不包含某个节点所有事务都被执行后的结果。
合并复制强调的就是数据的集中和节点的自主性而不是事务的一致性。在合并复制 中，所有节点通常并不一定要互连，更多地是以离线的方式对数据自由处理，只是在合并 后才最终保证数据的同步。但有时即使在合并后，某一节点所进行的事务处理结果也并不 全都反映到其它节点，因为在合并时仍可能存在一些节点处于离线工作状态。
16.1.5 同步模式
所谓同步就是指使出版者出版物内的数据和描述文件与订购者的复制保持一致。
（1） 手工同步
当创建订购时，您可以在订购者手动装入初始快照文件而不是通过网络，这被称为“手 工同步”。如果出版物较大，那么从磁带或其它存储介质来装入快照文件进行手工同步将 大大提高效率。例如数据库有几十个GB， 那么将数据库下载到磁带，再重新装入订购者 数据库，这样将比通过传输速度较慢且不十分可靠的网络既快速又简单。使用手工方法进 行同步处理，不必再运行快照代理进行初始同步，SQL Server 也不会将目标表与出版论 文进行初始化同步，它将假设已经同步了订购者和出版者，并立即将复制文件分发给订购 者。
在进行手工同步时，由用户来负责确保出版论文与目标表的表结构与数据是相同的。 这种方法的优点是复制数据所产生的变化可以立即被分发到订购者，从而避免执行快照代 理来进行初始同步而引起的系统超载。
注意：在这里提及的“不必运行快照代理”是指不必运行快照代理来进行出版者与订购者之间的快照初始化，但在以后复制过程中快照代理仍要运行。
（2） 自动同步
自动同步是指订购者与出版者之间的出版表与目标表的初始同步由SQL Server 自动 来完成。在默认情况下，SQL Server 会在规划时间自动启动同步处理程序，首先由快照 代理在分发者内创建同步集合（*.sch 的描述文件和*.bcp 的数据文件），并在分发者上建 立一个同步作业，分发代理然后将同步集合传递到订购者首先利用描述文件生成表结构， 然后使用BCP 将数据复制到订购者数据库。
（3） 无同步
无同步就是不需要订购数据库与出版数据库同步，SQL Server 会假定出版数据库与订 购数据库已经同步，也不会对是否同步进行验证，这些工作要由用户自己来完成。
16.1.6 复制的拓扑结构
sSQL Server 仅支持星形拓扑结构，在该结构中，复制数据从中心出版者/分发者流向 多个订购者，订购者之间并不进行复制数据的传递。所以如果某一订购者不能正常工作， 并不影响其它订购者从分发者接收复制数据。
使用星形拓扑结构的最大优点在于其减少了订购过程中数据的等待时间，因为在复制 订购中，复制数据至多经过三步便在所有订购者中实现了同步。所以在数据同步中如果流 动的数据不多则使用星形拓扑结构是快速高效。的另外该结构允许将出版物进行分割从而 减少存储在每一个订购者上的数据量。但是，星形拓扑结构也有自身的缺陷，主要表现在：
数据的同步处理过分依赖于中心分发者/出版者。当订购者修改复制时，数据的 同步要求中心分发者/出版者参与其中，在该同步中使用了二阶段提交协议。当 其它订购者进行订购时，出版者又要参与其中并把复制数据反映到其它订购者。 从而导致中心分发者/出版者仅能支持有限个订购者。此时我们只能通过增加另 外的中心分发者/出版者从而支持更多订购者；
如果中心分发者/出版者失效，则整个复制体系将瘫痪，数据的订购和分发将停止。
在SQL Server 中有以上几种形式的星形结构：
中心出版者（Central Publisher）
带有远程分发者的中心出版者（Central publisher with remote Distributor）
出版订购者 （Publishing Subscriber）
中心订购者 （Central Subscriber）
（1） 中心出版者（Central Publisher）
中心出版者是最为简单的一种星形的拓扑结构，在这种配置下，一台服务器既扮演出 版者角色又扮演分发者角色，同时允许一个或多个独立的服务器扮演订购者角色。该配置 适合于从数据中心（如公司总部）向数据使用者（如分公司）复制数据，并且这些数据不 允许被数据使用者修改（如公司财务报表等）。该结构如图所示16-1 所示。
（2）） 带有远程分发者的中心出版者（Central publisher with remote Distributor）
由于在中心出版者配置下，所有的复制代理、出版和订购活动以及信息的存储和维护 等许多工作都由一台服务器来完成，因此，如果复制的事务或数据较大或有太多的订购者， 会对复制的效率产生极大的负面影响，网络资源的有限性使这一问题更为突出。基于此，我们常将分发者与出版者分离开，分别让独立的服务器来扮演分发者和出版者的角色，从 而使出版者服务器从分发任务中解放出来。应该强调的是分发者与出版者之间必须有可 靠、高速的通信连接。该结构如图16-2 所示。
（3） 出版订购者（Publishing Subscriber）
在该配置下，有两个出版者原始出版者：和出版订购者出版订购者。是原始出版者的 订购者，同时也扮演出版者角色向其它订购者出版数据。二者具有相同的出版数据。当出 版者与订购者之间的网络传输速度较慢或通信费用较高时常使用该配置方案。出版订购者 起到中转作用，它首先从原始出版者订购数据，然后将数据再出版给它的订购者。原始订 购者与出版订购者都可以是出版者与分发者的双重角色。该结构如图16-3 所示。
在跨洲或跨国的情况下的复制处理中常使用出版订购者方案。另外的应满足的需求是 出版订购者与订购者之间要比原始出版者与订购者之间有着更短的网络距离、更可靠的传 输性能。可以允许原始出版者与出版订购者之间有较慢的传输速度，但必须有可靠的传输 性能。
（4） 中心订购者（Central Subscriber）
中心订购者是指有许多出版者向一个订购者复制出版事务和数据。目标表被水平分 割每个分割块都含有一个标识本地数据的主键值。每个出版者只出版其中的一个分割块。 对于那些具有上滚数据业务的应用环境来说，该配置方案很有价值。如在一个大型分销系 统中，对销售表进行水平分割。每一具销售分部都是出版者，将只属于它自己的销售数据 出版到销售总部。该结构如图16-4 所示。
