复制是将一组数据从一个数据源拷贝到多个数据源的技术，是将一份数据发布到多个存储站点上的有效方式。使用复制技术，我们可以将一份数据发布到多台服务器上，从而使不同的服务器用户都可以在权限许可的范围内共享这份数据。
SQL Server复制技术可以确保分布在不同地点的数据自动同步更新，从而保证数据的一致性，为实现数据库读写分离，高可用等都提供了不错的解决方案。SQL Server 主要采用出版物、订阅的方式来处理复制。源数据所在的服务器是出版服务器，负责发表数据。出版服务器把要发表的数据的所有改变情况的拷贝复制到分发服务器，分发服务器包含有一个分发数据库，可接收数据的所有改变，并保存这些改变，再把这些改变分发给订阅服务器。
SQL Server允许在不同的数据库如 Oracle或Access之间进行数据复制。
SQL Server复制操作的前提条件是SQL Server代理服务必须已经启动。
一个分发服务器支持多个发布服务器，就像一个报刊亭可以同时出售多个出版社发行的杂志一样。同理，分发服务器也可以和发布服务器是同一个实例，这就像直销一样。
配置复制就没有数据库镜像和Always On的要求那么高，只需要两台服务器能通过TCP进行通讯即可，两台服务器的操作系统和SQL Server版本都可以不完全一致，而且两台服务器也不需要加入域。但是复制订阅主要是针对数据表而不能像镜像和Always On那样配置整个数据库。
事务复制
在第一次设置好事务复制后，发布的表、存储过程等将会被镜像，之后每次对于发布服务器所做的改动都会以日志的方式传送到订阅服务器，使得发布服务器和订阅服务器几乎可以保持同步。因此，可以看出事务复制的特点是:
1.发布服务器和订阅服务器内容基本可以同步
2.订阅服务器也支持请求订阅,可以不用一直和分发服务器保持连接，定期查看其是否有可用更新即可。
3.适用于要求实时性的环境。
特点
相比较其它高可用性技术而言，复制有如下好处：
复制是对象级别
复制可以工作在简单恢复模式下
可以拥有无限多个订阅，并考虑请求订阅，将Distribution Agent的负载Offload到订阅服务器
复制允许在订阅端进行更新，没有其它高可用性技术可以做到这一点
在故障转移的时候，不需要Redo或Rollback日志，只需要将应用重定向到订阅节点
但同样，复制也有其自身局限性，比如：
复制建立、调错都相对比较复杂
复制是对象级别（没错，基于不同的场景）
分发库上不能建立镜像，因此分发库有可能成为Single-Point-Of-Failure
复制很容易影响发布服务器的性能
不能进行热备，这意味着就不能进行故障检测和故障排除
对于复制来说，故障转移容易，想转移回来就比较麻烦，因此这种情况下可以考虑P2P复制
但不得不说，复制的确是非常的强大，“想复制什么复制什么，想复制多远复制多远，想怎么复制就怎么复制，想复制的多复杂就多复杂”。
