我们有两个运行SQL Server 2005 SP4且具有累积更新3的生产SQL Server。这两个服务器都在相同的物理计算机上运行。DELL PowerEdge R815具有4个12核心CPU和512GB（yes GB）的ram，以及用于所有SQL数据库和日志的10GB iSCSI SAN连接的驱动器。操作系统是带有所有SP和Windows更新的Microsoft Windows Server 2008 R2企业版。操作系统驱动器是3个72GB 2.5英寸15k SAS驱动器的RAID 5阵列。SAN是具有48个10k SAS 3.5英寸驱动器的Dell EqualLogic 6510，在RAID 50中进行配置，分割为两个SQL Server的多个LUN，并且也共享一台Exchange机器和几台VMWare服务器。
我们有20多个数据库，其中有11个使用见证服务器以高可用性进行了镜像。见证服务器是运行SQL Server实例的低功耗计算机，该实例仅用于提供见证服务。最大的镜像数据库为450GB，可生成约100-300 iops。数据库镜像监视器报告当前的发送速率约为100kb至10mb /秒，并且镜像提交开销（通常为0毫秒）。镜像服务器与主体保持一致没有问题。
我们一直在经历镜像故障转移。有时，单个数据库将进行故障转移，而有时几乎所有数据库将同时进行故障转移。例如，昨晚，我们进行了11个数据库故障转移中的10个，其余的数据库保持可访问性，直到我手动对其进行故障转移。
我已经经历了一些故障排除步骤来尝试确定问题，但是到目前为止，仍无法解决问题：
1）该机器随附Broadcom BCM5709C NetXtreme II 4端口千兆网络适配器，我们最初将其用作主要网络连接。此后，我们在两台计算机上都安装了Intel PRO / 1000 PT双端口服务器适配器，以消除NIC的问题。
2）所有数据库每晚都有一个自动完整备份，以及有关镜像数据库的日志备份。日志文件的使用情况受到监控，很少使用超过15％。主数据库的日志文件为125GB，由159个虚拟日志文件组成，大小从511MB到1GB不等。TempDB位于其自己的LUN上，由24 x 2GB文件组成。
3）在见证服务器上的SQL Server登录没有显示以下任何错误：与数据库“ Data”的镜像连接“ TCP：//SQL02.DOMAIN.INET：5022”的超时在30秒后没有响应。检查服务和网络连接。
主服务器和辅助服务器上的SQL Server登录显示与镜像有关的消息：
30秒钟后，到“ TCP：//SQL01.DOMAIN.INET：5022”的镜像连接超时，数据库“ Data”无响应。检查服务和网络连接。
由于角色同步，镜像数据库“数据”正在将角色从“ PRINCIPAL”更改为“ MIRROR”。 （此处故意故意拼写错误，因为这正是实际消息的显示方式。）
由于故障转移，镜像数据库“数据”正在将角色从“主要”更改为“镜像”。
由于来自合作伙伴的故障转移，镜像数据库“数据”正在将角色从“镜像”更改为“主要”。
SQL Server服务继续运行，并且网络连接似乎保持正常。我们始终将500至2500个会话连接到每个服务器（主要是连接到单个数据库上的服务代理队列的机械手应用程序）。
4）使用NET SH语法禁用TCP烟囱和RSS等。
5）我已经在两台计算机上都运行了SQL Server 2005最佳实践分析器，除了偶尔出现的应用程序事件日志错误833，没有发现其他故障，而这与故障转移事件都不是同时发生的：
SQL Server在数据库[Data]（9）中的文件[F：\ Data.MDF]上遇到了1次以上的I / O请求，花费了超过15秒的时间才能完成。操作系统文件句柄为0x00000000000010A0。最新长I / O的偏移量是：0x000007d4b10000）。
6）有时，我们看到“客户端无法重用已重置连接池的SPID XXX的会话。此错误可能是由较早的操作失败引起的。请在此错误消息之前检查错误日志以了解失败的操作。” 由两个服务器生成。似乎没有“早期”消息指示任何问题。
7）有时数据库邮件将错误写入应用程序事件日志：
异常类型：Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException消息：连接出错。原因：超时已过期。连接完成之前，操作完成或服务器未响应之前已超时。连接参数：服务器名称：MGSQL02，数据库名称：msdb数据：System.Collections.ListDictionaryInternal TargetSite：无效的OpenConnection（Microsoft.SqlServer.Management.Common。 SqlConnectionInfo）HelpLink：NULL来源：DatabaseMailEngine
Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.OpenConnection中的StackTrace信息（Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection（SqlConnectionInfo ci） ）在Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems（String dbName，String dbServerName，Int32 lifetimeMinimumSec，LogLevel loggingLevel）
我相信超时会导致故障转移；是什么导致这些超时？显然，如果存在实际的网络问题，例如电缆不良或交换机不良，可能会导致数据包丢失并因此导致超时，但是还有哪些其他原因会导致超时呢？堵吗 如果MSDB或某些其他系统数据库有I / O超时，是否可能导致镜像故障转移？
感谢您的任何建议！
镜像超时机制
由于服务器实例无法直接检测到软错误，因此，软错误可能会导致服务器实例无限期地等待。为避免这种情况，数据库镜像基于镜像会话中的每个服务器实例以固定间隔在每个打开的连接上发送ping信息，从而实现其自身的超时机制。
要保持连接打开，服务器实例必须在定义的超时时间内，再加上发送更多ping所需的时间，对该连接执行ping操作。在超时期间收到ping指示该连接仍处于打开状态，并且服务器实例正在通过该连接进行通信。收到ping命令后，服务器实例将在该连接上重置其超时计数器。
如果在超时期间未在连接上收到任何ping命令，则服务器实例将认为连接已超时。服务器实例关闭超时连接，并根据会话的状态和操作模式处理超时事件。
netsh interface tcp show global 显示：
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disablednetsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510SELECT name, value_in_use FROM sys.configurations
临时分布式查询0
关联I / O掩码0
亲和力掩码0
finity64 I / O掩码0
finity64掩码0
代理XPs 1
允许更新0
敬畏0
进程限制阈值5
c2审核模式0
已启用clr 1
启用通用标准0
并行性的成本阈值4
跨数据库所有权链接0
光标阈值-1
数据库邮件XP 1
默认的全文语言1033
默认语言0
默认跟踪已启用1
禁止触发结果0
填充系数（％）0
英尺抓取带宽（最大）100
英尺爬网带宽（最小值）0
ft通知带宽（最大）100
ft通知带宽（分钟）0
索引创建内存（KB）0
不确定xact分辨率0
轻量级池0
锁0
最大并行度6
最大全文检索范围4
服务器最大内存（MB）393216
最大文本替换大小（B）65536
最大工作线程数0
媒体保留0
每个查询的最小内存（KB）2048
最小服务器内存（MB）52427
嵌套触发器1
网络数据包大小（B）1400
OLE自动化程序1
打开对象0
PH超时（秒）60
预计算等级0
优先级提升0
查询调控器成本限制0
查询等待-1
恢复间隔（分钟）0
远程访问1
远程管理员连接0
远程登录超时（秒）20
远程proc转换0
远程查询超时600
复制XPs 0
扫描启动过程0
服务器触发递归1
设定工作台尺寸0
显示高级选项1
SMO和DMO XP 1
SQL Mail XPs 0
转换杂音词0
两位数年份截止2049
用户连接0
用户选项4216
Web Assistant程序0
xp_cmdshell 1
前一阵子，我手动将mirroring_connection_timeout所有镜像数据库的值修改为30秒，以尝试修复该问题。这仅增加了故障转移事件之间的时间量。随着mirroring_connection_timeout设定集在10秒的默认，我们看到了很多更多的故障切换。
有一条评论要求我确保禁用IPSec，因此我要发布几个netsh显示操作系统的IPSec配置的命令的内容：
C：\> netsh ipsec动态显示所有 当前没有分配的政策 主模式策略不可用。 快速模式政策不可用。 通用主模式过滤器不可用。 特定的主模式过滤器不可用。 通用快速模式过滤器不可用。 特定的快速模式过滤器不可用。 IPsec MainMode安全关联不可用。 IPsec QuickMode安全关联不可用。 IPsec配置参数 ------------------------------ StrongCRLCheck：1 IPsec豁免：3 IPsec统计 ---------------- 活动联盟：0 卸载SA：0 等待键：0 关键添加：0 密钥删除：0 密钥：0 活动隧道：0 不良SPI Pkts：0 未解密的Pkt：0 未验证的Pkt：0 带有重放检测的Pkts：0 发送的机密字节数：0 收到的机密字节：0 发送的已验证字节数：0 收到的已验证字节数：0 发送的传输字节：0 接收的传输字节：0 在隧道中发送的字节数：0 在隧道中接收的字节数：0 发送的已卸载字节：0 接收的已卸载字节：0 C：\> netsh ipsec static全部显示 ERR IPsec [05072]：策略存储中没有策略
更新时间：2012-12-20
现在，我们已将生产系统移至SQL Server2012。自12月17日上午以来，我们一直在运行此程序-到目前为止，尚未进行故障转移。但是，几天之内就可以与基于2005年的系统相媲美。
为了记录新系统的性能，我一直在sys.dm_os_wait_stats仔细研究。并且注意到了DBMIRROR_DBM_EVENT，这是一个未记录的等待类型。Microsoft的Graham Kent有一篇有趣的文章，涉及对意外故障转移和这种等待类型进行故障排除。我将在这里回顾他的发现：
该客户正在体验一个基于大容量OLTP数据库的巨大阻塞链，其中所有头阻止程序都在等待DBMIRROR_DBM_EVENT。这是我经历的事件顺序：
回顾阻塞链本身-在这里可以找到我们的帮助，因为我们只能看到DBMIRROR_DBM_EVENT
查看未记录等待类型的来源。显然，您不能在MS之外执行此操作，但是我可以说，在编写此等待类型时，它表示主体在等待镜像硬化LSN时使用的等待，这意味着它所属的事务无法提交。这立即非常明确地指出了主体在镜像服务器上等待时无法提交事务的问题。现在，我们需要调查为什么镜像不提交事务或为什么委托人不知道是否提交事务。
查看msdb系统表
（a）查看[backupset]表以查看出现问题时生成的日志大小是否明显大于正常值。如果它们特别大，则可能是镜像中充满了事务，根本无法跟上交易量。这就是为什么在线书籍有时会告诉您如果需要执行非常大的日志记录操作（例如索引重建）时禁用镜像的原因。（有关为什么这样做的参考，请访问http://technet.microsoft.com/zh-cn/library/cc917681.aspx）。在这里我用下面的TSQL
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'（b）其次，我查看了表[dbm_monitor_data]中的数据。此处的关键是找到出现问题的时间范围，然后查看我们是否在以下任何方面经历了重大变化：
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rate这些都是与（a）部分类似的指标，因为它们可能表示没有响应的组件或体系结构。例如，如果send_queue突然开始增长，但re_do队列却没有增长，则意味着委托人无法将日志记录发送到镜像，因此您可能想查看连接性，或者服务代理队列处理实际的传输。
在这种特殊情况下，我们注意到所有计数器的值似乎都是奇怪的，因为日志备份的大小是正常的，但是状态没有变化，发送队列为0，重做队列为0，发送速率固定，发送速率固定重做率。这很奇怪，因为它暗示在问题期间DBM监视器无法从任何地方记录任何值。
查看SQL Server错误日志。在这种情况下，没有任何错误或信息消息，但是在诸如此类的其他情况下，报告1400范围内的错误是很常见的，您可以在我的其他镜像博客的其他地方找到示例，例如此错误1413示例
查看默认跟踪文件–在这种情况下，没有为我提供默认跟踪，但是它们是DBM问题信息的绝佳来源，因为它们记录了所有合作伙伴上的状态更改事件。
这通常可以使您对各种情况有一个清晰的了解，例如某个或所有合作伙伴之间的网络连接失败时，以及随后合作伙伴的状态如何。
结论：
在这种特定情况下，我目前缺少2个关键数据点，但除此之外，我仍然可以对上述信息做出合理的假设。我们可以肯定地说，阻塞是由于启用了DBM导致的，因为阻塞者都在等待DBMIRROR_DBM_EVENT等待类型。因为我们知道我们没有使用大型日志操作来充斥镜像，并且该部署通常在此模式下可以愉快地运行，所以我们可以排除异常的大型操作。这意味着我们现阶段有2个潜在候选人：
一些或所有合作伙伴之间的连接上的硬件问题。
镜像服务器上的CPU耗尽-根本无法跟上重做-CPU耗尽本身可能来自SQL Server外部或此镜像伙伴关系之外的进程。
镜像代码本身存在问题（尽管我们确实需要一些内存转储以确认这一点）。
根据经验，我会怀疑是1或2，但我也总是对3持开放态度，我们现在尝试收集更多数据以更详细地研究此问题。