一, 数据库复制

SQL Server 2008数据库复制是通过发布/订阅的机制进行多台服务器之间的数据同步，我们把它用于数据库的同步备份。这里的同步备份指的是备份服务器与主服务器进行 实时数据同步，正常情况下只使用主数据库服务器，备份服务器只在主服务器出现故障时投入使用。它是一种优于文件备份的数据库备份解决方案。

SQL Server的复制分为种：

1. 快照发布:

发布服务器按预定的时间间隔向订阅服务器发送已发布数据的快照。每隔一段时间将订阅数据库中的相应表中的数据全部删除，然后将自己相应表中的全部插到订阅数据库中

使用快照复制本身是最合适的：

1）很少更改数据。
           2）在一段时间内允许具有相对发布服务器已过时的数据副本。
           3）复制少量数据。
          4）在短期内出现大量更改。

在数据更改量很大，但很少发生更改时，快照复制是最合适的。 例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。 对于给定的某些类型的数据，更频繁的快照可能也比较适合。 例如，如果一天中在发布服务器上更新相对小的表，但可以接受一定的滞后时间，则可以在夜间以快照形式传递更改。

发布服务器上快照复制的连续开销低于事务复制的开销，因为不用跟踪增量更改。 但是，如果要复制的数据集非常大，那么若要生成和应用快照，将需要使用大量资源。 评估是否使用快照复制时，需要考虑整个数据集的大小以及数据的更改频率。

2. 事务发布:

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

事务复制通常从发布数据库对象和数据的快照开始。 创建了初始快照后，接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。 数据更改将按照其在发布服务器上发生的顺序和事务边界应用于订阅服务器，因此，在发布内部可以保证事务的一致性。

以下各种情况下适合采用事务复制：

1). 希望发生增量更改时将其传播到订阅服务器。
         2). 从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。
         3). 应用程序需要访问中间数据状态。 例如，如果某一行更改了五次，事务复制将允许应用程序响应每次更改（例如，激发触发器），而不只是响应该行最终的数据更改。
          4).发布服务器有大量的插入、更新和删除活动。
          5).发布服务器或订阅服务器不是 SQL Server 数据库（例如，Oracle）。

默认情况下，事务发布的订阅服务器应视为只读，因为更改将不会传播回发布服务器。 但是，事务复制确实提供了允许在订阅服务器上进行更新的选项

3.  具有可更新订阅的事务发布:

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

4.  合并发布:

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

与事务复制相同，合并复制通常也是从发布数据库对象和数据的快照开始， 并且用触发器跟踪在发布服务器和订阅服务器上所做的后续数据更改和架构修改。 订阅服务器在连接到网络时将与发布服务器进行同步，并交换自上次同步以来发布服务器和订阅服务器之间发生更改的所有行。

合并复制通常用于服务器到客户端的环境中。 合并复制适用于下列各种情况：

1).  多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器。
            2). 订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
            3). 每个订阅服务器都需要不同的数据分区。
            4). 可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。
            5). 应用程序需要最终的数据更改结果，而不是访问中间数据状态。 例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。

合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。 由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。 因此，在合并更新时可能会产生冲突，合并复制提供了多种处理冲突的方法

 复制的缺点： 表有主键，而且表结构日后不能更改，如果架构稳定也是不错的，如果有很多张表那就比较麻烦了

复制方法及过程：

http://www.cnblogs.com/dudu/archive/2010/08/26/1808540.html

http://www.cnblogs.com/killkill/archive/2009/07/17/1525733.html

http://dufei.blog.51cto.com/382644/84645

http://www.cnblogs.com/wangdong/archive/2008/10/24/1318740.html

 二，数据库镜像：

        数据库镜像：

优点是系统能自动发现主服务器故障，并且自动切换至镜像服务器。

缺点是配置复杂，镜像数据库中的数据不可见（在SQL Server Management Studio中，只能看到镜像数据库处于镜像状态，无法进行任何数据库操作，最简单的查询也不行。想眼见为实，看看镜像数据库中的数据是否正确都不行。只 有将镜像数据库切换主数据库才可见）

相对于日志传送，数据库镜像显然更高一级。在最简单的形式下，它其实与日志传送的工作原理相似，但是生产服务器发送事务到镜像服务器的频率要高得多，这意味着更新速度也要快很多。

　　对于数据库镜像来说，故障转移功能也是需要手动完成。但是你可以添加第三个SQL Server，称为witness。Witness可以作为一个普通的SQL Server，但是一直留意着其它两个镜像服务器。当主镜像发生故障，witness可以让第二个镜像接管操作，类似一种自动的故障转移。

　　在故障转移时，任何进行中的客户端事务都将重新启动，而由于在这一过程中仍然存在着延迟，镜像服务器也不能保证百分之百不丢失数据。

三，数据库日志传输：

作为高可用性的最低级形式，日志传送(log shipping)本质上是SQL Server复制功能的一种延伸

允许解决方案提供商创建多个数据库副本。日志传输能够将次数据库日志副本同步发送到SQL Server实例上。然后这些日志会在次服务器上重放，从而保持数据库副本是最新的。

　　有一些解决方案提供商使用日志传输作为克服数据库镜像缺点的方法。数据库镜像是很好的技术，但是它只允许我们实现一个数据库副本。镜像可以接近实时的方式进行，所以数据库修改可以快速地写到次数据库上。如果客户数据库损坏或数据库记录意外删除，那么这可能会造成问题。

　　日志传输有两个主要的优点。首先，解决方案提供商能够实现一种延迟，这样日志就不会即时重放。这是很重要的，因为如果主(或镜像)数据库出现问题，日志可以在重放之前拦截，因此可以防止问题扩散。

　　日志传输第二个主要的优点是它支持实现多个数据库副本。有一些单位使用日志传输作为在备份数据中心维护数据库副本的方法，这能够防止主数据中心出现问题时发生数据丢失。

　　 虽然日志传输通过是作为数据库镜像的补充措施，但是它是一种独立的技术，它可以不依赖于镜像技术而独立使用。

http://www.searchdatabase.com.cn/showcontent_11708.htm

四，故障转移集群

集群技术是微软可用性的*形式，它需要你设置一个Windows集群。

　　在集群中并不会涉及传输以及镜像，取而代之，两台或更多的电脑将会彼此连接在一个共享的外部存储器中，通常是存储区域网络(SAN)。数据库文件就存放在这个共享存储器上，同样设置的SQL Server实例都运行在集群节点上。

　　集群中的所有节点中，实际上只有一个节点是一直处在活动状态的，如果这个节点发生故障，其它的节点将启动相应的SQL Server实例，并连接共享存储器的数据文件。而整个故障转移过程往往只有几秒钟时间，对于任何给定的SQL Server实例，Windows集群技术都可以确保客户端始终注视活动的节点。

　　集群技术非常复杂，但它是实现高可用的最高效技术。与前面介绍的两个功能相比，集群依赖于一个单一的数据库文件集。如果这些文件损坏了，故障转移也不能起作用了，因为故障转移的实例同损坏的文件是一样的。而使用镜像与日志传送，你可以对文件进行实时拷贝，因此不必担心文件损坏的问题。SQL Server中，文件遭到损坏的情况很少发生，因此我认为集群应该还是一个不错的选择。

缺点的。其中一个重要的问题是故障恢复的实现是非常昂贵的。Microsoft只在那些通过Windows Server认证的硬件上才支持故障恢复。  另一个问题是它要求使用共享存储