Eu tenho um problema em que a reconstrução do índice está causando uma grande fila de refazer no nó secundário do AG síncrono.
Este problema ocorre apenas em 1 db, e a única diferença entre este db e todos os outros dbs é que este db tem durabilidade atrasada forçada. Em média, todos os dbs variam de 300 a 600 GB de tamanho de arquivo de dados.
Com base na documentação, entendo que, para este banco de dados, a durabilidade da transação não é garantida (por exemplo, após a reinicialização ou falha) e o cliente recebe confirmação antes do registro de log gravado no disco no nó AG primário/secundário.
Minha pergunta é: quando o log é finalmente liberado para o disco no nó primário (seja por meio de uma transação durável ou comando de descarga forçada), o log também é enviado para o nó secundário neste ponto? Então, efetivamente, este é um grande pedaço de registros e provavelmente a razão pela qual a fila de refazer se torna grande?
Atualização: o acúmulo da fila de refazer durante a reconstrução do índice dura apenas cerca de 20 segundos (quando a durabilidade atrasada é forçada). Se eu desativar a durabilidade atrasada, não haverá acúmulo de fila de refazer durante a reconstrução do índice. Estou me perguntando se os grandes pedaços de descarga (devido à durabilidade atrasada) estão causando o acúmulo momentâneo da fila de refazer.
Sim, isso vai acontecer.
Sim.
Se uma fila de refazer aumentar, pode ser devido a vários motivos. Nesta causa, o motivo não é a durabilidade atrasada, mas sim o fato de que está ocorrendo uma grande reconstrução de índice, que está gerando mais log que pode ser enviado do que refazer pode passar na mesma quantidade de tempo. Enviar e Refazer são dois itens separados, pois não estão acoplados. Você pode examinar o(s) encadeamento(s) de redo para ver se há algo que possa ajustar, no entanto, com reconstruções de índice, isso é normal, portanto, provavelmente seria uma perda de tempo.