镜像数据库 (mirror database)在采用异步时，如何获取备库到主库的延迟时间类似于mysql里面的salve_lag，mysqlsalve_lag

镜像数据库 (mirror database)在采用异步时，如何获取备库到主库的延迟时间类似于mysql里面的salve_lag，mysqlsalve_lag

镜像数据库 (mirror database)在采用异步时，如何获取备库到主库的延迟时间？想监控下主备时间库的延迟时间，怎么监控？谢谢

LZ下面是SQLSERVER数据库镜像的一些维护技巧

如果发生故障，errorlog中会记录镜像数据库的状态变化，以及连接问题的错误代码。

这些错误代码对我们分析和定位连接会非常有用。

这里举一些例子

（1）镜像服务器的errorlog

the mirrored database "xxx"is changing roles from "mirror" to "principal"

due to auto failover

主体服务器的errorlog

the mirrored database "xxx" is changing  roles from "principal"  to "mirror" 

due to role  synchronization

（2）伙伴服务器之间发生网络连接错误

错误 :1474，级别16，状态:1

database mirroring connection error 4'an error occurred while receiving data:'

10054(an existing connection was forcibly closed by the remote host) for 'tcp://test.testdomain.com:5022'

错误 :1474，级别16，状态:1

database mirroring connection error 4'an error occurred while receiving data:'

64(the specified network name is no longer available) for 'tcp://test.testdomain.com:5022'

（3）伙伴服务器不响应连接请求，可能是出现了严重的性能问题

错误 :1479，级别16，状态:2

the mirroring connection to 'tcp://test.testdomain.com:5022'has timed out for database "xxx"

after 30 seconds without a response.check the service and network connections

除此之外，errorlog中当然还记录了各种SQLSERVER遇到的异常，这些异常可能是非常重要的参考信息，

可以用来推断数据库镜像发生故障转移或者无法正常工作的原因

2、操作系统自带的perfmon monitor

数据库镜像在性能监视器中有一个专门的对象SQLSERVER：DATABASE MIRRORING

这个对象下的计数器对于了解数据库镜像运行状态，有非常重要的作用

在主体数据库上，你可以检查Transaction Delay计数器以确定数据库镜像是否影响主体服务器的性能

检查Log Send Queue KB计数器，以确定发送队列的大小。如果send queue很长，有可能是镜像数据库

处理日志慢导致的，也可能是由于网络传输慢导致的。主体服务器的Log Bytes Sent/Sec  计数器显示了

每秒发送的日志量。可以计算（Log Send Queue）/（Log Bytes Received/Sec）来估算镜像数据库

需要多长时间才能追赶上主体数据库

在镜像数据库上，Log Bytes Received/Sec计数器显示了每秒接收到的日志量。你可以检查Redo Queue KB

计数器来确定重做队列的大小，就知道有多少日志没有被重做。如果Redo Queue很大，这往往意味着

镜像数据库存在I/O瓶颈。镜像数据库上的Redo Bytes/Sec 计数器显示了执行重做操作的速率。前面

已经提到过，发生故障转移的时候，原始的镜像数据库需要把重做队列里的日志都重做完才能真正上线运行。

我们可以通过计算（Redo Queue）/（Redo Bytes/Sec ）来估算一旦发生故障转移，需要多长时间才能完成

全部重做操作

这些计数器，配合一些系统自带的计数器（例如：物理磁盘，网络等对象下的计数器），可以很直观地

定位到数据库镜像的性能瓶颈。

3、数据库镜像监视器

数据库镜像监视器是一个图形用户界面的工具，你可以用他来监视镜像伙伴或镜像会话的状态，

利用这些信息你可以评估在当前状况下完成故障转移所需的时间，和潜在的数据丢失量。你也可以

为一些你认为更重要的指标（如send queue，redo queue）配置警告阀值，一旦超过你设置的阀值

就触发警告来通知DBA

4、系统存储过程和系统表

可以通过运行

USE [msdb] GO EXEC sys.[sp_dbmmonitorresults] @database_name = DLGPOS, -- sysname     @mode = 0, -- int     @update_table = 0 -- int

系统存储过程来查看当前数据库镜像的状态。你可能会感兴趣数据库镜像监视器或者sp_dbmmonitorresults

是从哪里获取信息的。其实，这两者都是来自于一个MSDB数据库中的系统表dbm_monitor_data。

而这个系统表的更新由以下两者完成。

（1）当使用SSMS启动镜像会话时，会自动创建一个”数据库镜像监视器作业“。

这个作业每分钟更新一次dbm_monitor_data系统表。如果你是用ALTER DATABASE [DLGPOS] SET PARTNER

命令来创建镜像会话，这个作业就不存在了。但是你可以执行EXEC sys.[sp_dbmmonitorresults] 存储过程来

手动创建这个作业

（2）数据库镜像监视器每30秒更新一次dbm_monitor_data系统表。

事实上这两个方法背后都是调用了[sp_dbmmonitorresults] 存储过程来更新信息。你可以手动

运行这个存储过程来更新dbm_monitor_data系统表。无论你使用什么方法，SQLSERVER会保证

每两个更新的间隔不小于15秒

[sp_dbmmonitorresults] 是一个非常重要的存储过程。如果你有兴趣，可以去查看他的定义，你会发现

这个存储过程是通过查询sys.[dm_os_performance_counters]视图来获得性能相关的数据，并且

EXEC sys.[sp_dbmmonitorupdate] @database_name = NULL -- sysname

通过将用户设置的阀值与sys.[dm_os_performance_counters]视图进行比较来确定是否触发警告。

而sys.[dm_os_performance_counters]视图中的数据和性能监视器中的SQLSERVER:Database Mirroring

下的计数器是一一对应的。

以上就是诊断数据库镜像问题时通常要收集的信息。数据库镜像问题主要有两类：

1、诊断发生故障转移的原因（对于非高可用模式的镜像，就是诊断镜像停止工作的原因）

对于这类问题，你需要收集主体服务器，镜像服务器和见证服务器（如果有）上的errorlog

如上面所讲，errorlog里会记录什么时候镜像发生了问题，发生了什么问题，以及最终的结果如何。

最重要的是，你不能孤立地去分析各个errorlog，而是应该将他们彼此作为参考，互相印证。

举例来说，如果你在主体服务器的errorlog里发现了主体服务器失去了镜像服务器的连接，

你就应当去查看镜像服务器和见证服务器errorlog中相应时间点的日志，去了解当时镜像服务器和

见证服务器是否能连接到主体服务器。只有了解了所有服务器彼此之间的连通状况，才能正确

判断出当时那台服务器的网络端出现了什么问题

2、性能问题

由于主体服务器才能响应应用端的请求，性能问题都会体现在主体服务器端。例如主体服务器上

事务提交有严重的延迟，或者是发送队列很长等。但是这类问题的最终症结往往却不在主体服务器

上，而在镜像服务器上或者网络上。要诊断这类问题，需要在主体服务器和镜像服务器上打开

性能监视器来记录各项镜像相关数据，以及磁盘，网络，内存，CPU相关的数据。此外数据库镜像

监视器也能帮助你了解主体服务器/镜像服务器的运行状态。通过这些数据，你可以了解镜像

服务器的处理事务的效率，网络传送事务的速度，以及镜像端的磁盘负载和磁盘性能（往往是最大瓶颈）

等。掌握这些信息，你可以判断出问题源头：是否主体服务器的负载已经超出了镜像数据库的容纳范围，

是否网络性能低于设计容量等。