在运行着的数据库驱动的应用程序中，SQL复制能解决许多问题。由于发送/订阅的模式不是十分容易理解，复杂的脚本语言和监视复制系统也是需要一定的思想在里面。希望在接下来的几个章节中能尽量将基本原理和操作阐述的详细完整些，便于大家理解。
在SQL Server中，复制就是产生或复制数据；比如你需要去创建一个你数据的副本，或者复制一个那份数据的改变，SQL复制就派上用场了。
复制的副本可以在同一个数据库中也可以在远程的分隔的服务器上。
副本与源数据保持实时同步，或者在规定时间间隔内保持同步。单步同步方式，就像双向同步一样都是可行的，复制甚至能被用来保持多个数据集之间彼此的同步。既然有这么多优点，那我们就迫不及待的开始学习复制吧，当然一开始先要描述一些基础信息，比如基本的复制组件和这些组件如何组合在一起来实现复制。Come on!
复制的组成：SQL Server 复制主要由三部分组成：出版商，经销商和订阅者，这些组件作用于发行和订阅服务器内部的文章上。
通过命名我们就能推想出来，复制很像报纸杂志的发行，可以简单理解它的一般流程：出版--》经销--》订阅。
文章（复制的对象）对于每个应该被复制的对象，一个复制文章需要被定义。每个文章对应着一个见得SQLServer对象或者一个对象的子集。这个被复制的对象通常就是表、视图、或者存储过程。当然也可以在单个文章中创建多个对象。
出版物(对象的集合)一组在逻辑上在一起的文章（复制的对象）被混合成一个出版物。这个出版物有公共的被定义的可选项，主要的选项就是复制的类型。
出版商（发布服务器）一个提供复制的出版物的SQL Server 实例被叫做出版商。出版商监视所有改变的文章，并且将这些改变通知给经销商。
经销商（分发服务器）经销商是既要追踪所有的订阅者又追踪所有的发布者的改变，同时要保证任何一个改变都会被每一个订阅者知晓。绝大多数的改变在分发服务器中被追踪到。尽管经销商能作为一个独立的数据库实例，但是通常情况下分发服务器会运行在出版商的机器上。
订阅者（订阅服务器）订阅者可以看做是能够通过订阅的方式接收发布的所有信息的数据库实例。
订阅订阅是相对于发布而言的，订阅定义了哪一个订阅服务器将要去接收来自发布服务器发布的更新。每个订阅创建了一个在发布者和订阅者之间的链接。有两种订阅方式，推送订阅（Push)和请求订阅（Pull)。
在推送订阅的情况下，分发服务器直接在订阅服务器数据库更新订阅的数据；
而在请求订阅的模式下，需要订阅服务器定期查询分发服务器是否有可用更新，如果存在任何的可用更新，那么订阅服务器自己完成更新数据。
复制的类型在SQLServer 中主要有三种可用的复制类型，它们分别是：快照复制、合并复制和事物复制。
快照复制快照复制就是每次运行都创建一个完整复制对象和对象数据的副本。它使用数据库的BCP 工具来写入每个表的内容到快照文件夹中。快照文件夹是一个共享的文件夹地址，在启动复制的时候这个地址必须被建立在分发服务器上。并且每个参与者都是有权限访问快照复制的文件夹的，需要在设置复制的时候进行设置。
这种模式缺点是：每次快照复制运行，都要所有的一切从头再来一遍，因此它会占用很高的带宽和存储。
需要了解的是，所有其他类型的复制在初始化设置的时候都要使用一个简单的复制快照来同步给所有的订阅者和经销商一个复制。
事务复制顾名思义，就是以事务为基础。对于每一次提交的事务的变更都要被扫描到复制的文章中。事务日志读取代理扫描这些被做的变更，它读取发布数据库的事务日志。假如有改变影响了发布的对象，那么这些改变将被日志记录在分发数据库，然后分发数据库再选用合适的方式发送给订阅者。
事务复制可用作接近实时的同步，同时仅仅留下一些痕迹在发布方。尽管有一些选择项可以考虑使用双向数据移动，但是事务复制一开始就被设计为单向的模式。
合并复制合并复制即允许发布服务器更新数据库，也允许订阅服务器更新数据。定期将这些更新进行合并，使得发布的数据在所有的节点上保持一致。因此，有可能发布服务器和订阅服务器更新了同样的数据，当冲突产生时，并不是完全按照发布服务器优先来处理冲突，而是根据设置进行处理，这些会在后续文章中讲到。
设置事务复制