SQL SERVER 2005 使用订阅发布同步数据库

　　这两天有一个同事在设计项目的时候考虑到数据量查询和写入都比较大，问我数据库该怎么设计，了解了他们的业务后，我给的建议是发布一个订阅的数据库来分担压力，写下自己的操作步骤分享给大家。

　　数据库复制涉及

　　发布服务器：数据的来源服务器，维护源数据，决定哪些数据将被分发，检测哪些数据发生了修改，并将这些信息提交给分发服务器。

　　分发服务器：分发服务器负责把从发布服务器拿来的数据传送至订阅服务器。

　　订阅服务器：订阅服务器就是发布服务器数据的副本，接收维护数据。

　　订阅类型
　　推订阅：推订阅是指由发布服务器将所有发生修改过的数据复制给订阅者，这种在数据同步性价比较高的场合，推荐使用推订阅。
　　拉订阅：拉订阅是指订阅服务器在经过一段时间就会向发布服务器要求复制出版数据库发生的变化的数据。
　　发布，分发，订阅可以部署在独立的服务器上面也可以部署在一台sql server 上面，然而分开部署肯定能提高性能。

　　复制代理：

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

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

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

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

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

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

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

　　快照复制是最为简单的一种复制类型，能够在出版者和订阅者之间保证数据的一致性。快照复制通常使用在以下场合：
　　在一定时间内出现大量的更改的操作，但数据总量不大，变化周期较长。
　　（2）事务复制
　　快照复制是将整个数据集发送给订阅服务器，由于体积大而造成复制周期较长，会形成复制滞后问题。那么事务复制使用事务日志来生成将复制到订阅服务器的事务，因为它只复制事务也就是变化，所以滞后也比快照复制低得多，因为将不断地在订阅服务器处得到及时应用。
　　事务复制有三个组件：快照代理，它生成架构，数据以及跟踪复制过程所需的数据；
　　分发代理：它分发快照和随后的命令；
　　日志读取器代理：它读取发布数据的事务日志。
　　在事务复制中，当出版数据库发生变化时，这种变化就会立即传递给订阅者。并在较短时间内完成（几秒），而不是像快照复制那样要经过很长一段时间间隔。因此，事务复制是一种接近实时地从源到目标分发数据的方法。由于某种原因事务复制的频率较高。所以必须保证在订阅者与出版者之间要有可靠的网络连接。
　　（3）合并复制
　　合并复制是为移动用户设计的，可以在发布服务器或是订阅服务器处执行修改，在合并代理运行时，这些修改将同步，多用于发布服务器与订阅服务都修改数据的情况下。工作原理如下：在要复制的每个表上实现触发器，并使用包含GUID列唯一标识要复制的表中的每一行。对其中的任何一个表进行修改时，都会将更改将记录一个数据表中，在合并代理运行时，它收集数据表中的GUID，这些GUID指出了在发布服务器和订阅服务器处修改过的行。对于只在发布服务器或是订阅端修改的数据则直接进行相应操作，如INSERT，UPDATE，DELETE，如果双方都有GUID则按照用户指定的方式解决冲突，默认发布服务器伏先。
　　配置复制：
　　无论是快照复制，事务性复制还是合并复制，创建复制都要经过以下几个步骤：
　　1．创建发布服务器。选择要发布的服务器。如果有条件的，也可以分发服务器，在这里我们就将发布服务器和分发服务器设置在同一台计算机上。
　　2．不论是发布服务器还是订阅服务器必须开启代理服务。
　　3．创建一个发布。即将需要的数据库及对象发布出来。
　　4．选择一个适合自己的发布类型。
　　5．设置复制代理及安全，即指定可以运行代理的用户帐号。
　　创建可以使用此发布的订阅服务器。

　　测试服务器的版本是企业版 Enterprise Edition

　　Microsoft SQL Server 2005 - 9.00.4035.00 (X64)   Nov 24 2008 16:17:31   Copyright (c) 1988-2005 Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2)

　　查看服务器的名是否和数据库一致，不一致需要统一计算机名.

　　统计命名语句，统一完命名需要重新启动数据库。

if  serverproperty('servername')  <>  @@servername  
begin  
           declare  @server  sysname  
           set  @server  =  @@servername  
           exec  sp_dropserver  @server  =  @server  
           set  @server  =  cast(serverproperty('servername')  as  sysname)              
           exec  sp_addserver  @server  =  @server  ,  @local  =  'LOCAL'  
end