Grupos de disponibilidade AlwaysOn log_send_rate

Em todas as nossas configurações AlwaysOn, executando o Windows 2012 e o SQL Server 2012 em máquinas virtuais e bare-metal, acho que o log_send_rate in sys.dm_hadr_database_replica_statesestá retornando consistentemente valores incorretos.

Por exemplo (para modo síncrono)

sys.dm_hadr_database_replica_states.log_send_rate (ave = 36.571 (kb / s listados em bol))

Perfmon - SQLServer: réplica de disponibilidade - bytes enviados para réplica / s (máximo = 486.000.000, avg = 259.000.000)

Perfmon - SQLServer: Bancos de dados - Bytes de log liberados / s (máximo = 653,044.000, avg = 341.000.000)

Não vi nenhuma postagem sobre isso, mas parece não estar funcionando corretamente. Um log_send_ratevalor correto é útil para monitorar o AlwaysOn.

Alguém mais experimentou isso?

Sim, isso foi corrigido recentemente no Service Pack 2, Atualização Cumulativa 3. Aqui está o artigo da KB: http://support.microsoft.com/kb/3012182

"CORREÇÃO: A coluna Log_Send_Rate em sys.dm_hadr_database_replica_states não pode refletir a taxa com precisão no SQL Server 2012"

A razão pela qual o log_send_rate(e redo_rate) é um pouco complicado de entender e "correlacionar", especialmente quando estamos acostumados à transferência de dados em um tipo de pensamento ininterrupto no tempo, é que essas duas taxas são calculadas durante os períodos ativos, nem sempre .

Em outras palavras, ele log_send_rateserá ajustado quando houver o envio de blocos de log, mas não será desativado quando estiver silencioso e a réplica principal estiver aguardando o envio do log. Da mesma forma, o mesmo inversamente com secundários com redo_rate.

Estive analisando os valores log_send_rate como parte da solução de problemas de latência que temos em um de nossos ambientes de produção.

Propus à Microsoft que sua definição de campo esteja incorreta, conforme mencionado aqui ( http://technet.microsoft.com/en-us/library/ff877972(v=sql.110).aspx ). "Taxa na qual os registros de log estão sendo enviados para os bancos de dados secundários, em kilobytes (KB) / segundo."

Eu acho que minha definição abaixo é melhor. É ... “A taxa na qual os registros de log são limpos da fila de envio”, e os registros de log só podem ser limpos dessa fila quando eles já foram protegidos em todos os secundários, e isso só pode acontecer quando eles já foram enviados e recebidos, independentemente de quanto tempo levaram esses registros para chegar, e quanto tempo levaram para serem endurecidos, e quanto tempo levou para o secundário enviar as acusações de volta ao primário.

Essa é uma definição muito diferente, mesmo que pareçam esteticamente iguais. Os dados podem ser removidos de um local na fila de memória (log_send_queue) muito mais rapidamente do que podem ser enviados para os secundários em outra região, país ou centro de dados.

Nikos

@ Thomas (ainda sou muito noob para adicionar comentários aqui, desculpas. Se mais fácil eu puder fornecer meu email de trabalho e discutirmos offline, e atualizar aqui quando for alcançado um consenso?) Olá Thomas

Infelizmente, enquanto o seu ponto está correto, não é o ponto em jogo. Sim, é mais difícil correlacionar por todos os motivos que você descreveu, mas não é esse o problema que estou tentando destacar.

A questão é que o campo "log_send_rate" na DMV não é realmente a taxa na qual os registros de log são enviados para as réplicas.

Mais precisamente, é a taxa na qual os registros de log estão sendo removidos da fila de envio, APÓS que JÁ foram enviados para o secundário, protegidos no secundário e depois enviados de volta ao primário. Somente então eles podem ser limpos da fila de envio principal.

Esse é um significado completamente diferente do listado no link que incluí no meu primeiro post. Também é muito mais fácil ver a discrepância quando você está lidando com taxas de envio inter-regionais (como Londres para Nova York), em vez de enviar taxas de e para o datacenter local.