AlwaysOn可用性组log_send_rate

在所有在虚拟机和裸机上运行Windows 2012和SQL Server 2012的AlwaysOn设置上，我发现log_send_rate sys.dm_hadr_database_replica_states始终返回错误值。

例如（对于同步模式）

sys.dm_hadr_database_replica_states.log_send_rate（ave = 36,571（kb / s在bol中列出））

Perfmon-SQLServer：可用性副本-发送到副本/秒的字节数（最大值= 486,000.000，平均= 259,000.000）

Perfmon-SQLServer：Databases-刷新的日志字节/秒（最大值= 653,044.000，平均= 341,000.000）

我还没有看到任何关于此的帖子，但它似乎无法正常工作。正确的log_send_rate值对于监视AlwaysOn很有用。

其他人有没有经历过？

是的，最近在Service Pack 2，累积更新3中对此进行了修复。这是知识库文章：http : //support.microsoft.com/kb/3012182

“ FIX：sys.dm_hadr_database_replica_states中的Log_Send_Rate列无法正确反映SQL Server 2012中的速率”

之所以将log_send_rate（和redo_rate）是有点棘手的理解和“关联”，尤其是当我们习惯了的思维时类型的不间断点的数据传输，这两个率在活动时间，不是所有的时间来计算。

换句话说，log_send_rate当有日志块正在发送时，它将进行调整，但是当它处于安静状态并且主副本正在等待日志发送时，它将不会关闭。同样，在二级上也是如此redo_rate。

我一直在查看log_send_rate值，作为对我们生产环境之一中存在的延迟问题进行故障排除的一部分。

我已经向Microsoft建议，他们对字段的定义是错误的，如此处所述（http://technet.microsoft.com/en-us/library/ff877972(v=sql.110).aspx）。“日志记录发送到辅助数据库的速率，以千字节（KB）/秒为单位。”

我认为下面的定义更好。它是...“从发送队列中清除日志记录的速率”，并且只有在所有辅助节点上都已对其进行了加固之后，才可以从该队列中清除日志记录，并且只有在已经将它们记录后才可以清除。不论这些记录到达需要多长时间，加固它们需要多长时间，以及辅助节点将确认发送回主节点所需的时间，该发送和接收的时间都是如此。

即使它们在外观上相同，这也是一个非常不同的定义。可以从内存队列中的本地（log_send_queue）删除数据，其发送速度比将数据发送到另一个区域，国家或数据中心的辅助数据库的速度要快得多。

尼科斯

@Thomas（抱歉，我仍然在这里没有意见，如果抱歉，我可以提供我的工作电子邮件，我们可以脱机讨论，并在达成共识时在此处更新吗？）

不幸的是，尽管您的观点是正确的，但并不是关键所在。是的，由于您所描述的所有原因，很难进行关联，但这并不是我要强调的问题。

关键是，DMV中的字段“ log_send_rate”实际上不是将日志记录发送到副本的速率。

更准确地说，是将日志记录从发送队列中删除之后（已将它们发送到辅助数据库，然后在辅助数据库中进行加固，然后将确认发送回主数据库）的速率。只有这样，才能从主发送队列中清除它们。

这与我在第一篇文章中包含的链接中列出的含义完全不同。当您处理跨区域（例如伦敦到纽约）的发送速率，而不是往返于本地数据中心的发送速率时，也更容易看到差异。