SQL Server 2005 数据库复制（转载）

对于一个地域分散的大型企业组织来说，构建具有典型的分布式计算机特征的大型企业管理信息系统时，总要解决一个很重要的问题：如何在多个不同数据库服务器之间保证共享数据的一致性。之所以有这个重要的问题在于企业组织在不同地点对具有相同结构的本地数据库进行修改，但要保证修改后的数据库有相同的结果，其本质就是在对本地数据库的修改体现在其他具有相同数据的远程数据库中。那么如何解决这个问题就要用到数据库的复制技术。

　　SQL SERVER提供了内置的复制能力，复制组件并不是附加产品，而是核心引擎的一部分。在复制这个技术的支持下，用户可以跨局域网、广域网或因特网的不同数据服务器上维护数据的多个拷贝，从而保证数据的一致性。

　　
　　复制模型

　　SQL SERVER使用出版和订阅这一术语来描述其复制活动，所谓出版，就是向其他数据库服务器（订阅者）复制数据，订阅就是从另外服务器（出版者）接收复制数据。虽然出版和订阅的对象都是将数据复制，但出版和订阅却并不是不同角度的同一数据操作，而是体现出一定的层次性和顺序性（总是先进行出版，再进行订阅）。SQL SERVER的复制组件有出版物与论文。出版者、订阅者、推订阅和拉订阅。

　　（1）出版物和论文

论文是被复制的数据集合，一篇论文一般就是咱们所说的表，论文是出版物的基本组成单元。出版物是论文的集合。它可以包括一个或多个论文订阅者，订阅的是出版物而不是出版物中的论文，这样可以使订阅更为简单。

　　（2）出版者

出版者是出版出版物的服务器。出版者服务器来维护源数据库以及有关出版物的信息。使数据可用于复制。除了决定哪些数据将被复制外，出版者要检测哪些复制数据发生了变化，并将这些变化复制到分发者的分发数据库中。

　　（3）分发者

分发者是指把从出版者传递来的复制数据或事务等送至相应的订阅者的服务器，并负责维护分发数据库。

　　（4）订阅者

订阅者是指存储复制数据的副本机器。且接收并维护已出版的数据的服务器，订阅者也可以对出版数据进行修改，尽管订阅者可以对数据进行修改，但它仍是一个订阅者，当然订阅者也可以作为其他订阅者的出版者。

出版者、分发者、订阅者实际上并不一定指相互独立的服务器。它只是对SQL SERVER在复制过程中所扮演的不同角色的描述。SQL SERVER允许一台SQL SERVER服务器可以扮演不同的角色。比如一台出版者的服务器既可出版出版物，也可以作为分发者来存储和传送快照复制和事务复制。在实际应用中，用户决定是否让一台服务器扮演一个或多个角色。在很大程序是基于对复制系统性能的考虑，例如，为了提高分发者从分发数据库向订阅者的数据库复制出版物的效率，降低出版者服务器的负载，用户常不允许一台服务器既扮演出版者又扮演分发者。而是让其他的服务器专站承担分发者任务，从而提高了出版者和分发者的性能。

　　（5）订阅类型

推订阅和拉订阅

推订阅是指由出版者将所有发生在出版数据库的修改复制给订阅者，而不必向订阅者发出请求，只要出版数据库发生修改，出版者就会自动把这种修改体现在订购者那里，在对数据同步性要求比较高的场合，最好使用推订阅，拉订阅是指订阅者在经过一段时间就会向出版者要求复制出版数据库发生的变化。

　　复制代理：

　　（1）快照代理

快照代理在分发者上创建并存储快照文件，任务是：在分发数据库中准备已发布表的架构和初始数据以及其他对象、存储快照文件并记录出版数据库和订阅服务器之间的同步信息，快照代理运行在分发者服务器上，并与出版者相连接。每一个出版物都有自己的快照代理。与各种类型的复制一起使用。

　　（2）日志阅读代理

日志读取器代理与事务性复制一起使用。它将发布服务器上的事务日志中标记为复制的事务移至分发数据库中。使用事务性复制发布的每个数据库都有自己的日志读取器代理，该代理运行于分发服务器上并与发布服务器连接（分发服务器与发布服务器可以是同一台计算机）。

　　（3）分发代理

分发代理与快照复制和事务性复制一起使用。它将初始快照应用于订阅服务器，并将分发数据库中保存的事务移至订阅服务器。分发代理既可以运行于分发服务器（对于推送订阅），也可运行于订阅服务器（对于请求订阅）。

　　（4）合并代理：

合并代理与合并复制一起使用。它将初始快照应用于订阅服务器，并移动和协调所发生的增量数据更改。每个合并订阅都有自己的合并代理，该代理同时连接到发布服务器和订阅服务器并对它们进行更新。合并代理既可以运行于分发服务器（对于推送订阅），也可以运行于订阅服务器（对于请求订阅）。默认情况下，合并代理将订阅服务器上的更改上载到发布服务器，然后将发布服务器上的更改下载到订阅服务器。

　　（5）队列阅读代理

队列读取器代理与包含排队更新选项的事务性复制一起使用。该代理运行于分发服务器，并将订阅服务器上所做更改移回至发布服务器。与分发代理和合并代理不同，只有一个队列读取器代理的实例为给定分发数据库的所有发布服务器和发布提供服务。

　　复制类型：

　　SQL SEVER提供了三大类复制类型：快照复制、事务复制、合并复制。可以在实际应用中使用相应的复制类型，每一种复制类型都在不同程序上实现数据的一致性。
　　（1）快照复制

如其名字所言，快照复制指在某一时刻给出版数据库中的出版数据照相，然后将数据复制到订阅者服务器。快照复制实现较为简单，其所复制的只是某一时刻数据库的瞬间数据，

快照复制是将整个出版物传送给订阅者，就是在某一时刻将出版数据进行一次“照相”，生成一个描述出版数据库中数据的当前状态的一个文件，然后在相应的时间将其复制到订阅都的数据库上，快照复制并不是不停的监视出版数据库中发生的变化情况，它是对出版数据库进行一次扫描，把所有出版数据中的数据从源数据库送至目标数据库，而不仅仅是变化的数据。如果数据量很大，那么要复制的数据就很多。因此对网络资源要求很高，不仅要有较快的传输速度，而且要保证传输的可靠性。

快照复制是最为简单的一种复制类型，能够在出版者和订阅者之间保证数据的一致性。快照复制通常使用在以下场合：

　　在一定时间内出现大量的更改的操作，但数据总量不大，变化周期较长。

　　（2）事务复制

快照复制是将整个数据集发送给订阅服务器，由于体积大而造成复制周期较长，会形成复制滞后问题。那么事务复制使用事务日志来生成将复制到订阅服务器的事务，因为它只复制事务也就是变化，所以滞后也比快照复制低得多。

事务复制有三个组件：

快照代理，它生成架构，数据以及跟踪复制过程所需的数据；

分发代理：它分发快照和随后的命令；

日志读取器代理：它读取发布数据的事务日志。

在事务复制中，当出版数据库发生变化时，这种变化就会立即传递给订阅者。并在较短时间内完成（几秒），而不是像快照复制那样要经过很长一段时间间隔。因此，事务复制是一种接近实时地从源到目标分发数据的方法。由于某种原因事务复制的频率较高。所以必须保证在订阅者与出版者之间要有可靠的网络连接。

　　（3）合并复制

合并复制是为移动用户设计的，可以在发布服务器或是订阅服务器处执行修改，在合并代理运行时，这些修改将同步，多用于发布服务器与订阅服务都修改数据的情况下。工作原理如下：在要复制的每个表上实现触发器，并使用包含GUID列唯一标识要复制的表中的每一行。对其中的任何一个表进行修改时，都会将更改将记录一个数据表中，在合并代理运行时，它收集数据表中的GUID，这些GUID指出了在发布服务器和订阅服务器处修改过的行。对于只在发布服务器或是订阅端修改的数据则直接进行相应操作，如INSERT，UPDATE，DELETE，如果双方都有GUID则按照用户指定的方式解决冲突，默认发布服务器伏先。

　　配置复制：

　　无论是快照复制，事务性复制还是合并复制，创建复制都要经过以下几个步骤：

　　1．创建发布服务器。选择要发布的服务器。如果有条件的，也可以分发服务器，在这里我们就将发布服务器和分发服务器设置在同一台计算机上。

　　2．不论是发布服务器还是订阅服务器必须开启代理服务。

　　3．创建一个发布。即将需要的数据库及对象发布出来。

　　4．选择一个适合自己的发布类型。

　　5．设置复制代理及安全，即指定可以运行代理的用户帐号。

　　创建可以使用此发布的订阅服务器。

　　现在我们的实验基于下图：