SQL Server数据库同步问题分享(二)---操作步骤[未完，待续]
合并发布(复制)通常也是从发布数据库对象和数据的报表快照开始。并用触发器跟踪在发布服务器和订阅服务器中所做的后续数据更改和架构修改。订阅服务器与发布服务器在连接到网络时进行同步，并交换自上次同步以来发布服务器和订阅服务器间发生变化的所有行。允许站点对已经复制的数据进行匿名更改，并且在晚些时候合并更改和更加需要解决冲突。(数据合并可能导致主键冲突)
适用的情况:
(1) 多个定语服务器可能会在不同的时间更新同一数据，这些更改将传播到发布服务器和其他订阅服务器。
(2) 订阅服务器需要接手数据，脱机更改数据，并且在以后与发布服务器和其他定语服务器同步更改
(3) 订阅服务器都需要不同的数据分区
(4) 可能会发生冲突，如果发生冲突，需要具备检测和解决冲突的能力
(5) 应用程序需要最终的更改结果，而不是访问中间的数据状态。
工作原理：
合并复制允许不同的站点自主工作，然后将更新合并成一个统一的结果，由于更新是在多个服务器中进行，因此统一数据可能由发布服务器和多个定语服务器进行了更新，可能会出现冲突，合并复制提供解决冲突方案。在订阅服务器中更新数据时，首先将数据传播到发布服务器，然后再传播到其他订阅服务器。如果使用立即更新，将使用两阶段提交协议立即传播更改。如果使用排队更新，更改将存储在队列中；当网络连接可用时，再在发布服务器中异步应用排队事务。由于更新异步传播至发布服务器，所以发布服务器或另一台订阅服务器有可能更新同一数据，而在应用更新时会发生冲突。将根据创建发布时设置的冲突解决策略检测和解决冲突。
两种可更新订阅:
(1) 立即更新。必须连接发布服务器和订阅服务器才能在订阅服务器中更新数据。
(2) 排队更新。不必连接发布服务器和订阅服务器即可在订阅服务器中更新数据。可以在订阅服务器或发布服务器脱机时进行更新最近做数据库同步，看似非常简单的东西，可是问题一个接一个，或许我们在本机做测试，数据量小的时候根本查不到问题所在，在正式环境中每个因素都要考虑到，这里将遇到的问题以及操作步骤与大家分享一下，希望对大家有帮助！
(一) 数据库同步的必要性
1. 数据库实时备份同步，在数据库服务器出现问题时可以有正常工作时的备份
2. 数据库实时备份同步，在数据库访问压力过大时，可以用来做负载均衡
3. 数据库实时备份，数据库服务器可以无间断的无损失迁移
4. 当数据库遭受攻击或者服务器出现问题可以启用同步机器应急
5. 可以实现数据库之间的合并
(二) 数据库同步前提条件
1. 数据库故障还原模式必须是完全还原模型
2. 所有被同步的数据库都必须有主键
数据库被同步的数据表必须有主键，因为大家都习惯使用自增列作为主键，这里不一定要指定主键为自增列。主键主要用于事务复制
3. 使用计算机名来注册服务器
发布服务器，分发服务器和订阅服务器都必须使用计算机名称来进行SQLServer服务器的注册。在企业管理器里面注册服务器，如果需要 作为发布服务器，分发服务区和订阅服务器都必须使用服务器名称进行注册，不得使用IP地址以及别人注册，也不得使用带有端口号
4. SQL Server必须启动代理服务
SQLServer必须启动代理服务，且代理服务器必须以本地机器的账号运行
(三) SQL Server数据库同步相关定义
(1). 复制简介
复制是将数据或数据库对象从一个数据库复制和分发到另外一个数据库，并进行数据同步，从而使源数据库和目标数据库保持一致。使用复制，可以在局域网和广域网、拨号连接、无线连接和 Internet 上将数据分发到不同位置以及分发给远程或移动用户。
一组SQL SERVER2005复制有发布服务器、分发服务器、订阅服服务器组成，他们之间的关系类似于书报行业的报社或出版社、邮局或书店、读者之间的关系。以报纸发行为例说明，发布服务器类似于报社，报社提供报刊的内容并印刷，是数据源；分发服务器相当于邮局，他将各报社的报刊送（分发）到订户手中;订阅服务器相当于订户，从邮局那里收到报刊。在实际的复制中，发布服务器是一种数据库实例，它通过复制向其他位置提供数据，分发服务器也是一种数据库实例，它起着存储区的作用，用于复制与一个或多个发布服务器相关联的特定数据。每个发布服务器都与分发服务器上的单个数据库（称作分发数据库）相关联。分发数据库存储复制状态数据和有关发布的元数据，并且在某些情况下为从发布服务器向订阅服务器移动的数据起着排队的作用。在很多情况下，一个数据库服务器实例充当发布服务器和分发服务器两个角色。这称为“本地分发服务器”。订阅服务器是接收复制数据的数据库实例。一个订阅服务器可以从多个发布服务器和发布接收数据。
(2). 复制类型
(3) 快照发布
快照复制就是在某一时刻对出版数据库进行一次照相，生成一个描述发布数据的瞬时状态的静态文件，然后再规定的时间复制到订阅数据库
快照发布特点：
(1) 不需要实时监控和跟踪发布数据库发生的数据库变化
(2) 复制的内容不是Insert,Update,Delete语句数据，也不是被修改的数据
(3) 对网络资源要求较高，而且要保证传输的可靠性
(4) 对订阅数据库进行一次刷新，将发布数据库完全重新复制一份到订阅数据库
适用条件:
(1) 很少有数据更改
(2) 在一段时间内允许具有相对发布服务器已过时的数据副本
(3) 复制少量数据
(4) 在短期内出现大量更改
工作机制：
(1) 发布服务器，将要发布的数据库整个做一个快照
(2) 订阅服务器的快照代理程序把发布服务器的快照读取过来，放在本地的快照文件夹内订阅服务器的发布代理程序把快照文件夹中的快照发布到订阅服务器上。历史记录和快照记录在分发服务器中
(4) 事务发布
复制的一种类型，在订阅服务器上应用数据的初始快照，然后当发布服务器上发生数据修改时，捕获个别的事务并传播到订阅服务器。
适用环境：
(1) 希望发生增量更改时将其传播到订阅服务器。
(2) 从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短
(3) 应用程序需要访问中间数据状态，而不只是响应该行最终的数据更改.
(4) 发布服务器有大量的插入、更新和删除活动发布服务器或订阅服务器不是 SQL Server 数据库
(5) 具有可更新订阅的事务发布
在订阅服务器中更新数据时，首先将数据传播到发布服务器，然后再传播到其他订阅服务器。如果使用立即更新，将使用两阶段提交协议立即传播更改。如果使用排队更新，更改将存储在队列中；当网络连接可用时，再在发布服务器中异步应用排队事务。由于更新异步传播至发布服务器，所以发布服务器或另一台订阅服务器有可能更新同一数据，而在应用更新时会发生冲突。将根据创建发布时设置的冲突解决策略检测和解决冲突。
两种可更新订阅:
(1) 立即更新。必须连接发布服务器和订阅服务器才能在订阅服务器中更新数据。
(2) 排队更新。不必连接发布服务器和订阅服务器即可在订阅服务器中更新数据。可以在订阅服务器或发布服务器脱机时进行更新
(6) 合并发布
合并发布(复制)通常也是从发布数据库对象和数据的报表快照开始。并用触发器跟踪在发布服务器和订阅服务器中所做的后续数据更改和架构修改。订阅服务器与发布服务器在连接到网络时进行同步，并交换自上次同步以来发布服务器和订阅服务器间发生变化的所有行。允许站点对已经复制的数据进行匿名更改，并且在晚些时候合并更改和更加需要解决冲突。(数据合并可能导致主键冲突)
适用的情况:
(1) 多个定语服务器可能会在不同的时间更新同一数据，这些更改将传播到发布服务器和其他订阅服务器。
(2) 订阅服务器需要接手数据，脱机更改数据，并且在以后与发布服务器和其他定语服务器同步更改
(3) 订阅服务器都需要不同的数据分区
(4) 可能会发生冲突，如果发生冲突，需要具备检测和解决冲突的能力
(5) 应用程序需要最终的更改结果，而不是访问中间的数据状态。
工作原理：
合并复制允许不同的站点自主工作，然后将更新合并成一个统一的结果，由于更新是在多个服务器中进行，因此统一数据可能由发布服务器和多个定语服务器进行了更新，可能会出现冲突，合并复制提供解决冲突方案。
