关于SQL Server复制的分析

60_3710_246e74a326b710b.jpg[删除]

数据库复制有4种.
分别是:


60_3710_22b7eb78074e210.jpg[删除]

每一种都有各自的优缺点. 其中本人主要使用快照发布, 和事务发布. 至于为什么不使用其他的, 是因为除这两种之外其他的都为互相同步. 可能照成自增主键冲突问题, 并且网上还有人说有可能会照成死循环. 当然我没试过.

快照发布:  
发布服务器按预定的时间间隔向订阅服务器发送已发布数据的快照。

原理: 对当前数据库进行拍照然后将所得的照片发过去恢复数据
优点: 快照发布可以有效的保证数据的完整性. 可以控制快照生成的间隔时间等.
缺点: 由于是快照原理就是对当前数据库进行拍照然后将所得的照片发过去恢复数据, 所以会存在三个问题
1. 由于是恢复的过程, 所以会对整个表先进行删除再进行恢复. 所以会存在很小的一段时间数据库找不到表的情况, 因为删了么. 这段时间由当前同步表的大小决定
2. 由于是快照是对整个数据表进行拍照, 所以在数据量大的表会存在老数据再做无效传输.
3. 由于每次同步数据比较大所以会存在不及时性.
适用: 经常改变的, 并且数据量不大的表.

事务性发布:
在订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。

原理: 记录表数据的变化, 将变化同步到订阅服务器表.
优点: 数据同步及时, 一般几秒就能同步. 不管表数据如何庞大多没事.
缺点:  
1. 订阅服务器表不能更改, 否者很有可能同步失败.
2. 只对以后有变化的数据进行同步, 所以对旧数据丢失情况没办法恢复. 缺乏完整性.
3. 由于对发布表进行更改立马就会进行同步, 所以连接订阅服务器经常频繁.
适用: 不是经常变动的数据表.

具有可更新订阅的事务性发布:
在 SQL Server 订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。来自订阅服务器的事务被应用于发布服务器。

合并发布:
在订阅服务器收到已发布数据的初始快照后，发布服务器和订阅服务器可以独立更新已发布数据。更改会定期合并。Microsoft SQL Server Mobile Edition 只能订阅合并发布。