本文接着前面的章节：SQL Server镜像简单介绍　　

本文出处：http://blog.csdn.net/dba_huangzj/article/details/27203053

俗话说：工欲善其事必先利其器。计划好怎样部署和使用镜像，能够降低非常多不必要的风险。

本文将依照三步骤的形式展示。可是要注意这不是唯一的标准，详细情况详细分析。

第一步：了解环境

　　在搭建SQL Server镜像时，必须先了解你所要部署的环境。才干决定镜像的配置项。

这不仅是镜像配置的前提，也是部署SQL Server甚至搭建数据平台和其它高可用都应该做的事情。以下是一些常见的须要了解的问题：

1. server是否已经准备好
2. 数据库是否已经准备好
3. 是否知道所需的服务帐号
4. 是否了解数据库的大小
5. 镜像server和主体server的性能情况
6. 是否须要和其它技术组合

　　以下详细介绍一下这6点：

server是否已经准备好：

　　依据镜像的要求，必须使用SQL Server 2005 SP1以上的版本号，SP1是第一个全然支持镜像功能的版本号。理想情况下。主体server和镜像server所使用的操作系统和sqlserver的版本号尽量全然一致。对于SQL Server版本号，必须是企业版或者标准版。除此之外，数据库的数据文件和日志文件所在的盘符和文件夹名必须一致，假设不一致，当主体库把事务发送到镜像库时会由于无法识别从而引起报错。

　　假设引入了见证server，能够执行在工作组或者express版本号上。

数据库是否已经准备好：

　　首先须要确保没有文件组使用filestream选项。由于filestream是通过T-SQL操作本地文件，镜像无法在镜像server中读取主体server上的文件。

　　其次，镜像环境要求完整恢复模式。

是否知道所需的服务账号：

　　在部署过程中，最简单的就是使用域账号。

假设使用同样的服务帐号。就不须要在端点中授权。

假设使用本地系统帐号执行镜像，必须使用证书授权来替代Windows授权。当使用证书时。须要注意证书的过期时间。和其它最佳实践一样，假设不能使用域账号，建议使用专用的账号操作

是否了解数据库的大小：

　　假设须要做镜像的库非常大，在初始化的过程中就要考虑到可能的风险。由于一般步骤是先做完整备份，然后传输备份到镜像server然后再还原。然后再在主体数据库上做日志备份再还原到镜像中，这个步骤可能须要好几个小时。

假设此时业务本身就比較繁忙。加上镜像库须要追上主体库的进度，会导致严重的性能问题，最起码网络传输压力会非常大。

　　针对这样的情况，能够使用log shipping功能进行传输。注意使用NORECOVERY选项而不要用STANDBY选项。在搭建镜像一文中会提到，镜像库须要使用NORECOVERY状态。

 

镜像server和主体server的性能情况：

　　理想情况下。镜像server的性能应该接近主体server。由于在Failover的时候可能会短期接管主体server的全部请求，假设镜像server性能太低，会导致用户响应速度变慢。极端情况下，镜像server可能会在短期内承受不了原主体server带来的压力直接崩溃。也就是说镜像server可能也会停止响应。这会导致搭建镜像的初衷荡然无存。毕竟搭建镜像主要就是针对这样的情况。

 

是否须要和其它技术组合:

　　在企业级应用中。非常少仅仅使用单纯的一种高可用技术，可能会使用镜像搭配复制、日志传输甚至集群。

当混合使用的时候，须要更严谨的測试。兴许将会提到。

 

第二步：了解应用程序：

　　除了了解镜像环境的硬件部分，也要了解软件部分，也就是执行在这个环境下的应用程序。这些应用中，有些是“黑盒”，特别是第三方软件。对于这方面的内容，须要考虑的有：

1. 应用程序是怎样连到server的
2. 是否有不支持自己主动Failover的组件
3. 应用程序是否依赖其它库
4. 应用程序是否依赖外部资源

应用程序是怎样连到server的：

　　假设须要支持镜像。应用程序须要使用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的时候的影响还要制定应对策略。常见的处理手段是把这些组件拷贝到镜像server并配置连接到镜像库中。

应用程序是否依赖其它库：

　　镜像是库级的高可用方案，假设应用程序须要使用多个数据库协同执行时。仅对一个库做镜像是不可行的。针对这样的情况。能够把所依赖的全部库都做镜像，而且使用触发器检測镜像状态。仅仅要有一个库的状态满足Failover。就强制把全部库都进行Failover。这须要额外的编程。

应用程序是否依赖外部资源：

　　假设应用程序依赖本机server的资源，Failover会导致应用程序出现意外，针对这样的情况。能够考虑把外部资源放到共享文件夹上，并用UNC地址訪问。

 

第三步：检验计划：

1. 在主体server和镜像server上建立所需的帐号，建议使用专用的域账号，并做好归档处理，避免其它维护人员或者时间过久之后连自己都不记得账号password。

2. 镜像库不建议使用sa作为owner。

3. 假设CLR依赖TRUSTWORTHY配置，须要在初始化Failover之后配置。能够通过使用同样的数据库owner来解决。即镜像库和主体库在搭建过程中就要尽可能保持全然一致，包含数据库的owner。

4. 在镜像配置过程中确保全部数据库备份的作业都禁用，完整备份和日志备份都将影响镜像server恢复失败。
5. 确保完整模式下配置镜像。
6. 确保镜像server和主体server上相关数据库的数据文件及日志文件名称字、路径都全然一样。顺带说一句，系统库不可做镜像。

 

实践建议：

1. 使用与主体server性能尽可能接近的镜像server。

2. 使用专用网络用于镜像环境的传输数据。网络和磁盘I/O往往是镜像和其它高可用技术的常见瓶颈。特别是在大事务量传输时。
3. 在高性能模式下不要使用见证server。否则有引起服务丢失的风险，当见证不能连接主体或镜像时，另外一个伙伴会由于丢失仲裁而offline。

4. 使用同样的盘符和文件路径。
5. 在測试环境中进行压力測试。确保镜像环境不是一个幌子，而是真正能协助业务连续性的功能。
6. 在生产环境中。先使用异步方式执行，假设性能满足。切换到同步模式，假设同步模式也满足，再加入见证server。
7. SQL Server最好使用2005 的SP2（带有CU6）。或者2008。推荐使用2008R2。
8. 确保镜像和主体server是同样的SP和SQL Server版本号。
9. 使用同样的排序规则。

10. 维护计划不支持镜像功能，须要额外编程，针对sys.databases中的state字段做处理。在《SQL Server镜像日常维护》一文中介绍。
11. 保存镜像的配置脚本及文件。以便高速重建及版本号管控。
12. 不要把伙伴的timeout时间设为小于10秒。过小的timeout会影响镜像的正常执行，可是从实践来说。并非越长越好。一般上限是30~50秒。
13. 初始化镜像时能够暂时使用logshipping同步。Logshipping也能够作为高性能模式下的辅助功能。

14. 监控msdb中suspect_pages系统表，用于修复torn pages。
15. 避免使用同样的交换机或者路由器用于连接主体和镜像。主要原因是避免由于交换机、路由器同一时候出现问题而影响整个网络环境。
16. 确保镜像所需的port没有被占用，搭建一文会延时。镜像须要某些port，尽管不强制。可是要指定，所以网络不仅要连通，还要port可Telnet，防火墙的配置也要考虑。