Grupo de disponibilidade Always On com dois nós, confirmação síncrona.
A contenção de thread de redo na réplica secundária cria regularmente uma fila de redo muito grande. Confirmei que os tipos de espera são semelhantes aos seguintes:
No meu caso, esta é uma saída de sessão de eventos estendida (capturada quando a fila de refazer era grande) agrupada e agregada como no link acima:
Minha pergunta:
Como posso descobrir a origem exata da operação DDL que está causando a espera LCK_M_SCH_M?
Como Brent Ozar mencionou na seção de comentários, esta não é uma tarefa simples para encontrar o tipo de espera (e o que está causando a espera) entre o primário e o secundário com correlação com o tempo. Estou respondendo sua pergunta sobre encontrar a fonte. Modifiquei a definição de rastreamento de evento estendido fornecida na postagem do blog que você mencionou. Removida a cláusula where para que você possa capturar todas as sessões que estão causando espera.
Adicionadas mais algumas ações para capturar mais informações. Por exemplo:
Aqui está a definição completa.