Warning: Undefined array key "HTTP_REFERER" in /www/wwwroot/prod/www.enjoyasp.net/wp-content/plugins/google-highlight/google-hilite.php on line 58

参考：Stairways to sql server replication

一，复制分发介绍。
1，文章：可订阅项，如表，存储过程，视图，函数
2，复制类型：
（1）快照复制Snapshot Replication：一般用于对于数据库的一次性的完全复制,比如备份。
每次复制工作时，就将快照文件夹的内容copy到订阅服务器上，所以要求快照文件夹需要共享，以便复制完成，
其他类型复制，如事务型，合并型，快照文件夹主要用于首次初始化订阅库使用，以便将发布数据库copy到订阅服务器上，至于是否
要设置成共享，要看订阅是推模式还是拉模式，或是推模式，即发布更新每个订阅，那么快照文件夹只需本地发布使用，故不
需要设置成共享，而在拉模式，即每个订阅去检索发布服务器，那么就要求快照文件夹为共享。注意，一般为了便于集中管理订阅，一般设置为
推模式，由发布服务器集中处理。快照生成由快照代理完成。
（2）Transactional Replication：用于主数据库向从数据库的单向复制。日志代理扫描数据库的变化，若变化的项目中有发布，那么日志代理将就将
这种变化记载到分发服务器上，然后更新到订阅。
（3）具有可更新订阅的事务性发布: 发布服务器与订阅服务器可以独立修改，会定时合并
（4）Merge Replication：可以把多个数据库中的数据进行合并后，复制到目标数据库。
注：1)重新生成快照原因：快照存储的是当时发布数据库的数据，用于建立订阅数据库并传输数据，重新生成快照的原因其中之一是为了将新的数据存储起来，以便建立新订阅时节省时间。

二，发布扮演的角色。
1，当发布建立时，会在系统库上建立一发布数据库，记录所有发布项及复制过程，另外，对于
事务型复制分发，它还会包含待同步的命令。如MSmerge_history表，存储合并历史，MSmerge_articlehistory每个订阅项的更新信息。
注：多个复制可用一个发布库
2，复制分发由代理完成，这些代理由job来体现，在推模式中，这些job都在分发服务器上，在拉模式中，订阅服务器上也有。

三，使用。
1，利用 MSmerge_history系统数据库上查看合并历史。分发订阅MSmerge_contents 插入更新记录，MSmerge_tombstone删除记录
2，数据合并过程：执行：job名称：发布-订阅，打开此job,步骤有三个，
1）合并代理启动消息：执行实际的数据同步操作，分析
sp_MSadd_merge_history @perfmon_increment = 0, @agent_id = 1, @runstatus = 1, @comments = ‘启动代理。’
执行过程是：
1，因合并复制都是在一个会话中进行，故先从MSmerge_sessions取出当前的sessionID,若无，则insert