Atraso entre DB Primário e Secundário

Não tenho experiência com as ferramentas de monitoramento do RedGate, mas o SSMS tem um Painel de Grupo de Disponibilidade pronto para uso que sempre achei particularmente útil com métricas básicas como essa. Especificamente, a métrica no painel que seria útil para você é chamada de Tempo de recuperação estimado (segundos) :

Indica o tempo em segundos que leva para refazer o tempo de recuperação. O tempo de recuperação é o tempo que levará para a réplica secundária alcançar a réplica primária. Esse valor está oculto por padrão.

Eu também encontrei o Redo Queue Size (KB) :

Indica o número de registros de log nos arquivos de log da réplica secundária que ainda não foram refeitos. Esse valor está oculto por padrão.

E a Redo Rate (KB/s) particularmente útil para monitorar a integridade das minhas réplicas secundárias:

Indica a taxa em KB por segundo na qual os registros de log estão sendo refeitos. Esse valor está oculto por padrão.

Se você quiser acessar essas informações de forma mais nativa para coletar as métricas ao longo do tempo, o Painel do Grupo de Disponibilidade acima apenas aproveita os seguintes DMVs :

1. sys.dm_hadr_database_replica_states
2. sys.availability_databases_cluster
3. sys.availability_groups
4. sys.availability_replicas

Você pode encontrar mais informações sobre como consultar as DMVs para obter essas informações em Sincronização de réplicas do grupo de disponibilidade de monitoramento do SQLPerformance . Esta é a consulta do artigo (com uma coluna calculada adicional para obter o Tempo de recuperação estimado ):

SELECT 
    ar.replica_server_name, 
    adc.database_name, 
    ag.name AS ag_name, 
    drs.is_local, 
    drs.is_primary_replica, 
    drs.synchronization_state_desc, 
    drs.is_commit_participant, 
    drs.synchronization_health_desc, 
    drs.recovery_lsn, 
    drs.truncation_lsn, 
    drs.last_sent_lsn, 
    drs.last_sent_time, 
    drs.last_received_lsn, 
    drs.last_received_time, 
    drs.last_hardened_lsn, 
    drs.last_hardened_time, 
    drs.last_redone_lsn, 
    drs.last_redone_time, 
    drs.log_send_queue_size, 
    drs.log_send_rate, 
    drs.redo_queue_size, 
    drs.redo_rate, 
    drs.redo_queue_size / see.redo_rate AS EstimatedRecoveryTime -- Additional helpful calculated column
    drs.filestream_send_rate, 
    drs.end_of_log_lsn, 
    drs.last_commit_lsn, 
    drs.last_commit_time
FROM sys.dm_hadr_database_replica_states AS drs
INNER JOIN sys.availability_databases_cluster AS adc 
    ON drs.group_id = adc.group_id AND 
    drs.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
    ON ag.group_id = drs.group_id
INNER JOIN sys.availability_replicas AS ar 
    ON drs.group_id = ar.group_id AND 
    drs.replica_id = ar.replica_id
ORDER BY 
    ag.name, 
    ar.replica_server_name, 
    adc.database_name;

Você pode criar um trabalho SQL para registrar rotineiramente essas informações em uma tabela para que você tenha uma comparação histórica para atingir seus objetivos. (Isso é essencialmente o que o Monitor de Desempenho da RedGate provavelmente está fazendo sob o capô.)

O artigo acima também menciona brevemente uma terceira maneira de monitorar essas métricas por meio de Perfmon Counters .

E, finalmente, uma terceira e igualmente eficaz maneira de registrar as métricas de integridade dos Grupos de Disponibilidade é por meio dos Eventos Estendidos integrados .