本文紧跟上一章：SQL Server镜像简介
本文出处：http://blog.csdn.net/dba_huangzj/article/details/27203053俗话说：工欲善其事必先利其器。计划好如何部署和使用镜像，可以减少很多不必要的风险。本文将按照三步骤的形式展示，但是要注意这不是唯一的标准，具体情况具体分析。
第一步：了解环境
在搭建SQL Server镜像时，必须先了解你所要部署的环境，才能决定镜像的配置项。这不仅是镜像配置的前提，也是部署SQL Server甚至搭建数据平台和其他高可用都应该做的事情。下面是一些常见的需要了解的问题：
- 服务器是否已经准备好
- 数据库是否已经准备好
- 是否知道所需的服务帐号
- 是否了解数据库的大小
- 镜像服务器和主体服务器的性能情况
- 是否需要和其他技术组合
下面详细介绍一下这6点：
服务器是否已经准备好：
根据镜像的要求，必须使用SQL Server 2005 SP1以上的版本，SP1是第一个完全支持镜像功能的版本。理想情况下，主体服务器和镜像服务器所使用的操作系统和sqlserver的版本尽量完全一致。对于SQL Server版本，必须是企业版或者标准版。除此之外，数据库的数据文件和日志文件所在的盘符和目录名必须一致，如果不一致，当主体库把事务发送到镜像库时会因为无法识别从而引起报错。
如果引入了见证服务器，可以运行在工作组或者express版本上。
数据库是否已经准备好：
首先需要确保没有文件组使用filestream选项，因为filestream是通过T-SQL操作本地文件，镜像无法在镜像服务器中读取主体服务器上的文件。
其次，镜像环境要求完整恢复模式。
是否知道所需的服务账号：
在部署过程中，最简单的就是使用域账号。如果使用相同的服务帐号，就不需要在端点中授权。如果使用本地系统帐号运行镜像，必须使用证书授权来替代Windows授权。当使用证书时，需要注意证书的过期时间。和其他最佳实践一样，如果不能使用域账号，建议使用专用的账号操作
是否了解数据库的大小：
如果需要做镜像的库很大，在初始化的过程中就要考虑到可能的风险。因为一般步骤是先做完整备份，然后传输备份到镜像服务器然后再还原，然后再在主体数据库上做日志备份再还原到镜像中，这个步骤可能需要好几个小时。如果此时业务本身就比较繁忙，加上镜像库需要追上主体库的进度，会导致严重的性能问题，最起码网络传输压力会很大。
针对这种情况，可以使用log shipping功能进行传输，注意使用NORECOVERY选项而不要用STANDBY选项。在搭建镜像一文中会提到，镜像库需要使用NORECOVERY状态。
镜像服务器和主体服务器的性能情况：
理想情况下，镜像服务器的性能应该接近主体服务器，因为在Failover的时候可能会短期接管主体服务器的所有请求，如果镜像服务器性能太低，会导致用户响应速度变慢。极端情况下，镜像服务器可能会在短期内承受不了原主体服务器带来的压力直接崩溃，也就是说镜像服务器可能也会停止响应，这会导致搭建镜像的初衷荡然无存。毕竟搭建镜像主要就是针对这种情况。
是否需要和其他技术组合:
在企业级应用中，很少只使用单纯的一种高可用技术，可能会使用镜像搭配复制、日志传输甚至集群。当混合使用的时候，需要更严谨的测试，后续将会提到。
第二步：了解应用程序：
除了了解镜像环境的硬件部分，也要了解软件部分，也就是运行在这个环境下的应用程序，这些应用中，有些是“黑盒”，特别是第三方软件。对于这方面的内容，需要考虑的有：
- 应用程序是如何连到服务器的
- 是否有不支持自动Failover的组件
- 应用程序是否依赖其他库
- 应用程序是否依赖外部资源
应用程序是如何连到服务器的：
如果需要支持镜像，应用程序需要使用SQL Native Client、ADO.NET 2.0 Data Provider或者JDBC 1.1 Driver for SQL Server。并且连接字符串需要使用Failover partner属性。如果搭建了镜像，而不添加Failover Partner属性，那么就要每次在Failover时手动修改应用程序的连接字符串，这会影响程序的业务持续性。
是否有不支持自动Failover的组件：
如果如DTS包、SSIS包或者外部应用使用了不支持镜像的连接协议，需要评估在进行Failover的时候的影响还要制定应对策略。常见的处理手段是把这些组件复制到镜像服务器并配置连接到镜像库中。
应用程序是否依赖其他库：
镜像是库级的高可用方案，如果应用程序需要使用多个数据库协同运行时，仅对一个库做镜像是不可行的。针对这种情况，可以把所依赖的所有库都做镜像，并且使用触发器检测镜像状态，只要有一个库的状态满足Failover，就强制把所有库都进行Failover。这需要额外的编程。
应用程序是否依赖外部资源：
如果应用程序依赖本机服务器的资源，Failover会导致应用程序出现意外，针对这种情况，可以考虑把外部资源放到共享文件夹上，并用UNC地址访问。
第三步：检验计划：
- 在主体服务器和镜像服务器上建立所需的帐号，建议使用专用的域账号，并做好归档处理，避免其他维护人员或者时间过久之后连自己都不记得账号密码。
- 镜像库不建议使用sa作为owner。
- 如果CLR依赖TRUSTWORTHY配置，需要在初始化Failover之后配置。可以通过使用相同的数据库owner来解决。即镜像库和主体库在搭建过程中就要尽可能保持完全一致，包括数据库的owner。
- 在镜像配置过程中确保所有数据库备份的作业都禁用，完整备份和日志备份都将影响镜像服务器恢复失败。
- 确保完整模式下配置镜像。
- 确保镜像服务器和主体服务器上相关数据库的数据文件及日志文件名字、路径都完全一样。顺带说一句，系统库不可做镜像。
实践建议：
- 使用与主体服务器性能尽可能接近的镜像服务器。
- 使用专用网络用于镜像环境的数据传输，网络和磁盘I/O往往是镜像和其他高可用技术的常见瓶颈。特别是在大事务量传输时。
- 在高性能模式下不要使用见证服务器，否则有引起服务丢失的风险，当见证不能连接主体或镜像时，另外一个伙伴会因为丢失仲裁而offline。
- 使用相同的盘符和文件路径。
- 在测试环境中进行压力测试。确保镜像环境不是一个幌子，而是真正能协助业务连续性的功能。
- 在生产环境中，先使用异步方式运行，如果性能满足，切换到同步模式，如果同步模式也满足，再添加见证服务器。
- SQL Server最好使用2005 的SP2（带有CU6），或者2008，推荐使用2008R2。
- 确保镜像和主体服务器是相同的SP和SQL Server版本。
- 使用相同的排序规则。
- 维护计划不支持镜像功能，需要额外编程，针对sys.databases中的state字段做处理。在《SQL Server镜像日常维护》一文中介绍。
- 保存镜像的配置脚本及文件。以便快速重建及版本管控。
- 不要把伙伴的timeout时间设为小于10秒。过小的timeout会影响镜像的正常运行，但是从实践来说，并不是越长越好，一般上限是30~50秒。
- 初始化镜像时可以临时使用logshipping同步。Logshipping也可以作为高性能模式下的辅助功能。
- 监控msdb中suspect_pages系统表，用于修复torn pages。
- 避免使用相同的交换机或者路由器用于连接主体和镜像。主要原因是避免因为交换机、路由器同时出现故障而影响整个网络环境。
- 确保镜像所需的端口没有被占用，搭建一文会延时。镜像需要某些端口，虽然不强制，但是要指定，所以网络不仅要连通，还要端口可Telnet，防火墙的配置也要考虑。