SQL SERVER 2012 使用订阅发布同步数据库（一）

baiyunjn

企业做大了，就会有分支机构。分公司与总公司之间既统一又独立。这就是业务，技术服务于业务，那么摆在我们面前的问题是如何让数据既统一又独立？其实SQLServer已经为我们提供了很好的解决方案：发布、订阅。
打开SQL Server2012的对象资源管理器我们可以看到里面有一个”复制“节点。（图1）

先来简单了解下复制的概念：
　　复制是将数据或数据库对象从一个数据库复制和分发到另外一个数据库，并进行数据同步，从而使源数据库和目标数据库保持一致。使用复制，可以在局域网和广域网、拨号连接、无线连接和Internet上将数据分发到不同位置以及分发给远程或移动用户。
　　复制由发布服务器、分发服务器、订阅服服务器组成：
　　发布服务器：数据的来源服务器，维护源数据，决定哪些数据将被分发，检测哪些数据发生了修改，并将这些信息提交给分发服务器。
　　分发服务器：分发服务器负责把从发布服务器拿来的数据传送至订阅服务器。
　　订阅服务器：订阅服务器就是发布服务器数据的副本，接收维护数据。
　　点开复制节点我们看到其下面的两个自节点：“本地发布”、“本地订阅”（图2）

　　举个经典的例子解释下发布、订阅：
　　发布服务器类似于报社，报社提供报刊的内容并印刷，是数据源；分发服务器相当于邮局，他将各报社的报刊送（分发）到订户手中;订阅服务器相当于订户，从邮局那里收到报刊。
　　发布服务器通过复制向其他位置提供数据，分发服务器起着存储区的作用，用于复制与一个或多个发布服务器相关联的特定数据。每个发布服务器都与分发服务器上的单个数据库（称作分发数据库）相关联。分发数据库存储复制状态数据和有关发布的元数据，并且在某些情况下为从发布服务器向订阅服务器移动的数据起着排队的作用。在很多情况下，一个数据库服务器实例充当发布服务器和分发服务器两个角色。这称为“本地分发服务器”。订阅服务器是接收复制数据的数据库实例。一个订阅服务器可以从多个发布服务器接收数据。
　　好了先消化一下理论，下面我们创建一个发布服务器：
　　在“本地发布”节点上右击->新建发布由于我没有安装复制组件所以出了点儿意外（图3）

　　重新运行SQL Server2012安装向导，选择SQL Server复制功能（图4）

　　下一步->下一步->直到完成（图5）

　　这次再点击“新建发布”呵呵，界面不一样了（图6）

　　点击下一步（图7）

　　我们先实验一下“本地分发服务器”模式直接点击下一步，由于我之前没有启动SQL Server代理所以又出了点儿小意外（图8）

　　微软已经解释的很清楚了，直接点击下一步（图9）

　　到了这一步是不是感到有些迷惑？好了我们先消化几个概念：
　　推订阅：推订阅是指由发布服务器将所有发生修改过的数据复制给订阅者，推荐使用推订阅。
　　拉订阅：拉订阅是指订阅服务器在经过一段时间就会向发布服务器要求复制出版数据库发生的变化的数据。
　　发布，分发，订阅可以部署在独立的服务器上面也可以部署在一台sql server 上面，分开部署可以提高性能。
　　点击下一步，由于我没有建立自己的数据库所以又出了点儿小意外（图10）

　　好了会过头来吧数据库补上（图11）

　　这次界面就不一样了（图12）

　　点击下一步（图13）

　　微软的发布类型说明似乎不太好理解：
　　（1）快照发布
　　快照发布指在某一时刻给出版数据库中的出版数据照相，然后将数据复制到订阅者服务器。快照复制实现较为简单，其所复制的只是某一时刻数据库的瞬间数据，快照复制是将整个出版物传送给订阅者，就是在某一时刻将出版数据进行一次“照相”，生成一个描述出版数据库中数据的当前状态的一个文件，然后在相应的时间将其复制到订阅的数据库上，快照复制并不是不停的监视出版数据库中发生的变化情况，它是对出版数据库进行一次扫描，把所有出版数据中的数据从源数据库送至目标数据库，而不仅仅是变化的数据。如果数据量很大，那么要复制的数据就很多。因此对网络资源要求很高，不仅要有较快的传输速度，而且要保证传输的可靠性。快照复制是最为简单的一种复制类型，能够在出版者和订阅者之间保证数据的一致性。快照复制通常使用在以下场合：在一定时间内出现大量的更改的操作，但数据总量不大，变化周期较长。
　　（2）事务发布
　　快照发布是将整个数据集发送给订阅服务器，由于体积大而造成复制周期较长，会形成复制滞后问题。那么事务复制使用事务日志来生成将复制到订阅服务器的事务，因为它只复制事务也就是变化，所以滞后也比快照复制低得多。
　　（3）合并发布　　
合并发布是为移动用户设计的，可以在发布服务器或是订阅服务器处执行修改，在合并代理运行时，这些修改将同步，多用于发布服务器与订阅服务都修改数据的情况下。工作原理如下：在要复制的每个表上实现触发器，并使用包含GUID列唯一标识要复制的表中的每一行。对其中的任何一个表进行修改时，都会将更改记录到一个数据表中，在合并代理运行时，它收集数据表中的GUID，这些GUID指出了在发布服务器和订阅服务器处修改过的行。对于只在发布服务器或是订阅端修改的数据则直接进行相应操作，如INSERT，UPDATE，DELETE，如果双方都有GUID则按照用户指定的方式解决冲突，默认发布服务器优先。
　　我们先选择最简单的发布模式（快照发布），点击下一步，由于我没有在Publish数据库中建立任何数据表所以又出了点儿意外（图14）
　　

　　建立Account数据表（图15）

　　继续我们的发布之旅（图16）

　　要发布的对象已经划分的很详细了，从数据表到数据表的每一个字段，项目属性也非常详细（图17）

　　点击下一步还有更加令人惊喜的筛选器（图18）

　　微软做事总是很成熟，我们能想到的他都想到了。点击下一步（图19）

　　快照代理，它生成架构，数据以及跟踪复制过程所需的数据；
　　欣赏一下快照代理的核心界面（图20）

　　设置账户（图21）

　　为发布起个名字吧（图22）

　　总算可以点完成了，可惜又出了点儿小意外（图23）

　　
　　用以下代码搞定：
sp_configure 'show advanced options', 1;  
GO  
RECONFIGURE;  
GO  
sp_configure 'Agent XPs', 1;  
GO  
RECONFIGURE  
GO  大功告成（图24）