RabbitMQ

Transaction log corruption and DBCC CHECKDB

Como a corrupção do log de transações pode levar a falhas de backup de log de transações, e como recuperar.
Qualquer operação que tenta usar um registro de log corruptos vão encontrar o fracasso, e DBCC CHECKDB é uma destas operações.
Por padrão, DBCC CHECKDB irá criar um snapshot do banco escondidos debaixo dos panos para fornecer uma visão transacional consistente do banco de dados no qual executar as verificações de consistência. O processo para criar um  snapshot do banco de dados é o ponto de verificação no banco de dados real, e depois executar essencialmente de recuperação de queda na base de dados real, mas no contexto do  snapshot do banco - que não afetam o banco de dados real. Esta recuperação pseudo-crash reverte o efeito de quaisquer transações não confirmadas que estão ocorrendo no banco de dados real, tornando o  snapshot do banco de dados consistente.
Se este processo encontra um registro de log de transações danificado, então a criação do  snapshot do banco de dados irá falhar - levando à CHECKDB DBCC não demasiado, um monte de erros serão gerados, incluindo uma que identifica o registro de log de transações danificado, como abaixo:
DBCC encontrou uma página com um LSN maior do que o fim atual de log LSN (141131:0:4) para o seu banco de dados interno instantâneo. Não foi possível ler página (9647: -33648758), 'PaulsDB' database (banco de dados ID 26), LSN = (-1302554001:2131886119:4432), type = 255, isInSparseFile = 1. Por favor, volte a executar este comando DBCC.
ID da página e seus LSN são, obviamente, ambos encontram-se completamente errados.
Nem tudo está perdido, no entanto, como existem duas maneiras de contornar este problema.
1º, você pode empregar a técnica para alternar para o modelo Simple Recovery Model, ponto de verificação para truncar o log, e voltar para o modelo  Full Recovery Model , mas você tem que ter certeza que não existe nenhuma transação não confirmada caso contrário, o log de transação não pode truncar passado.
2º, você pode usar a opção WITH TABLOCK para DBCC CHECKDB. 
Isto irá ignorar a criação de um snapshot do banco e em vez disso criará um bloqueio de banco de dados de curto prazo, enquanto exclusivo verificações de consistência de alocação estão concluídas, e, em seguida, bloqueios de compartilhamento tabela como cada tabela é a consistência verificada. 
Esta é a versão offline do DBCC CHECKDB, mas não vai colidir com a corrupção log de transações.
Independentemente do método que você usa, não se esqueça de realizar análise para determinar o que causou a corrupção do log de transações.

Comments