Sintomas
Quando você usa o espelhamento de banco de dados no Microsoft SQL Server 2012 ou no Microsoft SQL Server 2014, você pode pressionar uma condição Assert e o espelhamento do banco de dados entra no estado suspenso.
Causa
O problema ocorre porque, ao alocar uma nova página, o SQL Server Obtém um X Lock na nova página. O SQL Server colocará o hobt_id (heap ou ID B-Tree) ao qual a nova página pertence à solicitação de bloqueio. No entanto, o SQL Server não pode colocar o hobt_id no log de espelhamento e resulta em um comportamento de bloqueio diferente entre o principal e o espelho. Isso pode ser explicado em detalhes da seguinte maneira:
-
T1 mantém um bloqueio do IX na página P1.
-
T2 fazer uma divisão de página em P1, atribuir uma nova página P2, uma transmissão de transação do sistema é usada aqui, ela contém um X Lock em P2. Aqui, o SQL Server não colocou o hobt_id no log de espelhamento.
-
TX faz uma migração de bloqueio para T1 para mover o IX Lock do P1 para P2.
-
A TX confirmada, agora T2 pode usar a página P2, e T2 obter outro bloqueio do IX na página P2.
-
T1 confirmado, agora T2 é o único que mantém um travamento do IX em P2.
-
Após uma grande quantidade de inserções, ocorre um escalonamento de bloqueio, no principal, T2 libera o IX do P2, mas no espelho, durante o escalonamento do bloqueio, T2 não lança o IX Lock.
-
Após um grande volume de exclusão, a página P2 se tornou vazia e é desalocada.
-
O T3 precisa de uma nova página, e acontece para atribuir P2, isso exige um X Lock, mas no espelho, essa etapa falhou devido à etapa 6.
No espelho, a etapa 6 não libera o IX Lock porque o hobt_id no bloco de bloqueio está incorreto. Este hobt_id incorreto vem durante a etapa 2 e, por isso, o SQL Server não coloca a hobt_id no log de espelhamento. normalmente, você não vê nenhum problema porque a TX na etapa 2 é muito curta, e o bloco de bloqueio com hobt_id incorretos será liberado quando for confirmado. No entanto, devido à migração de bloqueio no Step3 e às etapas a seguir (4 e 5), esse bloco de bloqueio com hobt_id incorreto é preservado e, por fim, causa o problema. O principal não tem esse problema porque usa um hobt_id correto na etapa 2. Mas o registro de log não tem hobt_id corretos.
Resolução
O problema foi corrigido primeiro na atualização cumulativa a seguir do SQL Server.
Atualização cumulativa 1 para SQL Server 2014 /en-us/help/2931693
Atualização cumulativa 9 para SQL Server 2012 SP1 /en-us/help/2931078
Cada nova atualização cumulativa do SQL Server contém todos os hotfixes e todas as correções de segurança incluídas na atualização cumulativa anterior. Confira as atualizações cumulativas mais recentes do SQL Server:
Solução alternativa
Para contornar o problema, reinicialize o espelho para encerrar o status suspenso.
Status
A Microsoft confirmou que este é um problema nos produtos Microsoft listados na seção "Aplicável a".
