KB2938828 - FIX: Os sucessos de espelhamento da base de dados afirmam e a sessão de espelhamento mostra estado suspenso no SQL Server 2012 ou SQL Server 2014

Sintomas

Quando utilizar o espelhamento da base de dados no Microsoft SQL Server 2012 ou no Microsoft SQL Server 2014, poderá atingir uma condição de afirmação e o espelhamento da base de dados entra em estado suspenso.

Causa

O problema ocorre porque, ao alocar uma nova página, o SQL Server obtém um bloqueio X na nova página. O SQL Server colocará o hobt_id (Heap ou B-Tree ID) ao qual a nova página pertence ao pedido de bloqueio. No entanto, o SQL Server não pode colocar a hobt_id no Registo de Espelhos e resulta num comportamento de bloqueio diferente entre o primário e o espelho. Isto pode ser explicado em detalhe da seguinte forma:

  1. T1 mantenha um bloqueio IX na página P1.

  2. T2 fazer uma divisão de página em P1, alocar uma nova página P2, uma transação de sistema TX é usada aqui, ele segura um bloqueio X em P2. Aqui o SQL Server não colocou a hobt_id no Registo de Espelhos.

  3. TX faz uma migração de bloqueio para T1 para mover o bloqueio IX de P1 para P2.

  4. TX comprometido, agora T2 pode usar a página P2, e T2 obter outro bloqueio IX na página P2.

  5. T1 comprometido, agora T2 é o único que segura um bloqueio IX no P2.

  6. Após muita inserção, ocorre uma escalada de bloqueio, na primária, T2 liberta o IX em P2, mas no espelho, durante a escalada de bloqueio, T2 não desbloqueou o bloqueio IX.

  7. Depois de muitas eliminações, a página P2 ficou vazia e é negociada.

  8. O T3 precisa de uma nova página, e acontece de alocar P2, isto requer uma fechadura X, mas no espelho, este passo falhou por causa do passo 6.

No espelho, o passo 6 não desbloqueia a fechadura IX porque o hobt_id no bloco de bloqueio está incorreto. Esta hobt_id incorreta vem durante o passo 2 e por causa do SQL Server não coloca a hobt_id no Registo de Espelhos.Normalmente não vê qualquer problema porque o TX no passo 2 é muito curto, e o bloco de bloqueio com hobt_id incorreto será libertado quando se compromete. No entanto, devido à migração de bloqueio no passo 3 e aos passos seguintes (4 e 5), este bloqueio com hobt_id incorretos é preservado e finalmente causa o problema. O primário não tem esta questão porque usa uma hobt_id correta no passo 2. Mas o registo de registos não tem hobt_id corretos.

Cada nova atualização cumulativa do SQL Server contém todos os hotfixes e todas as correções de segurança que foram incluídas com a atualização cumulativa anterior. Confira as últimas atualizações cumulativas do SQL Server:

Solução

Para contornar a questão, reinicie o espelho para acabar com o estatuto suspenso.

Estado

A Microsoft confirmou que este problema ocorre nos produtos da Microsoft listados na secção "Aplica-se a".

Precisa de mais ajuda?

Aumente os seus conhecimentos
Explore as formações
Seja o primeiro a obter novas funcionalidades
Aderir ao Microsoft insiders

As informações foram úteis?

Obrigado pelos seus comentários!

Obrigado pelo seu feedback! Parece que poderá ser benéfico reencaminhá-lo para um dos nossos agentes de suporte do Office.

×