那些关于SQL Server镜像数据库的事

　　数据库镜像是将数据库事务处理从一个SQLServer数据库移动到不同SQLServer环境中的另一个SQLServer数据库中。镜像不能直接访问;它只用在错误恢复的情况下才可以被访问。

　　要进行数据库镜像所需的最小需求包括了两个不同的SQLServer运行环境。主服务器被称为“主机”，第二个服务器被称作“备机”。主机数据库就是你实际用着的数据库，镜像数据库就是你的数据库的备用拷贝。当事务写入你的基本服务器的时候，他们也同样被传送到并写入你的镜像数据库中。

　　除了基本和镜像之外，你还可以引入另一个可选的组件，名为“见证”。见证服务器是第三个SQLServer2005运行实例，它是在判断什么时候进行错误恢复的时候，用于基本和镜像之间内部交流。只有当你想实现自动错误恢复的时候用到这个选项。它实现了2比1投票的能力，当我的一个组件不可达，并因此需要进行错误恢复的时候。见证服务器只有在你想实现自动错误恢复的时候才需要用到。

　　那么SQLServer数据库镜像有什么优缺点呢？

　　优点

　　下表是SQLServer可用性官方解决方案的一个对照表，现时我中心使用的恢复模式是“冷备份”中的“备份/恢复”，通常来说“热备份”比“冷备份”的可用性更高，恢复更快，更适合我中心现时的实际情况。如果不从成本考虑的话，“热备份”中的“故障转移群集”的可用性是最高的，但是故障转移群集需要借助磁盘阵列而且建设本身复杂性较高。数据库镜像的建立并没有太多的硬件要求，最起码没有像“故障转移群集”需要共享存储这么高的要求。

　　缺点

　　（1）由于SQLServer是一个实例多个数据库的产品，数据库镜像技术是基于数据库级别的，因此每次主数据库新增数据库都必须为备机增加数据库并且为新增的数据库建立镜像关系。

　　（2）数据库的登录名和用户是存储在master数据库，master数据库是不能做镜像的，所以每次操作数据库的登录名和用户也是需要多维护一份，

　　（3）数据库作业不能得到相应的维护。

　　（4）微软号称镜像可以让客户端对故障透明，但是实际测试中发现只有满足特定的条件才能实现透明化，而且透明化得客户端支持才可行（.netFramework2.0以上，MicrosoftJDBC驱动1.1以上）。

　　（5）跨数据库事务和分布式事务均不支持数据库镜像。

　　纵观其他几种方式，仅有“热备份”的“故障转移群集”没有这些问题。

　　但是，SQLServer数据库镜像是对于数据库可用性的软件解决方案。镜像在每个数据库级别被部署，并只能在完整恢复模式下工作。由于磁盘空间的问题，需要移动镜像数据库到一个不同的位置。我们想不停机、不破坏镜像来完成这个任务。需要在不同的环境做测试。

　　对于启用了数据库镜像的数据库的文件移动，我们只有有限的选择。常规方法如下：

　　破坏数据库镜像会话，通过使用Alterdatabase或AttachDetach移动在线数据库文件到一个新的位置。

　　备份数据库，并在镜像服务器上恢复备份，然后重建镜像。

　　技术上来讲，这是可行的，但是它需要停机时间，并且尤其对于大数据库，移动和恢复需要大量额外时间。

　　给定的停机时间是客户端总是会考虑的，我们得找到一个不停机的方案。以下步骤说明了如何不停机移动数据库文件而不用打扰同步数据库镜像。

　　对于镜像实例：

　　在主服务器上暂停镜像(可选)。

　　在镜像服务器上使用Alterdatabase语句来指向一个新位置。

　　停止镜像SQLServer服务。

　　移动镜像数据库文件到一个新位置，并确保文件上的权限也还在。

　　启动镜像SQLServer服务。

　　在主服务器数据库上恢复镜像，并验证镜像成功恢复。

　　对于主实例：

　　故障转移数据库到镜像服务器，以至于镜像服务器现在作为主服务器。

　　在新的主服务器上暂停镜像(可选)。

　　在新的镜像服务器上使用Alterdatabase语句来指向一个新位置。

　　停止新镜像的SQLServer服务。

　　移动新的镜像数据库文件到一个新位置，并确保文件上的权限也还在。

　　启动新镜像的SQLServer服务。

　　在主服务器数据库上恢复镜像，并验证镜像成功恢复。

　　如果详细查看以上计划，可以看到应用程序会话在镜像数据库故障转移期间会重连。当应用程序负载在主服务器上运行时，停止镜像SQLServer服务，物理移动数据库文件，然后启动镜像SQLServer服务。所以无需停机时间。

　　然而，你要确保在主服务器上有足够的日志空间，因为镜像状态将会被断开(不只是一个库，而是实例上所有镜像的数据库)。当镜像状态断开时，日志记录不会从主服务器发送到镜像服务器，将会累积在主服务器。一旦镜像实例启动，镜像状态变为同步中，主服务器将会开始发送日志记录到镜像服务器。

      我们可以通过以下T-SQL来检查所有镜像数据库的文件位置，来验证是否修改成功：

　　总的来讲，当移动数据库时可以保持数据库镜像不用停机。对于见证服务器无需任何操作，在活动期间一直保持在线状态。首先这个方案应该在测试环境验证后，再在生产环境实施。非常重要的是，我们注意到在异步镜像模式，也可以参照这种做法，只是需要在应用停机的情况下来实施。

      小编结语：

     数据库是一个庞大的系统，学好它将会得到很好的使用。本章介绍数据库一些操作内容，如有讲的不好，希望大家谅解。