Published on

November 28, 2011

Compreendendo o estado suspeito do banco de dados do SQL Server

Você já se perguntou o que faz um banco de dados do SQL Server entrar em estado suspeito? Muitas pessoas acreditam que arquivos ausentes podem levar a um banco de dados suspeito, mas isso não é totalmente verdade. Neste artigo, exploraremos o conceito de um banco de dados suspeito e desmistificaremos o mito em torno de arquivos ausentes.

Primeiro, vamos esclarecer o que é um banco de dados suspeito. Quando um banco de dados do SQL Server é marcado como suspeito, significa que a instância do SQL Server não pode garantir a integridade do banco de dados. Isso pode acontecer por várias razões, como corrupção nos arquivos do banco de dados ou problemas com o log de transações.

Contrariamente à crença popular, simplesmente perder um arquivo não resulta automaticamente em um banco de dados suspeito. Para provar isso, vamos realizar uma série de testes. Vamos criar um banco de dados com vários arquivos e tabelas e, em seguida, renomear intencionalmente um dos arquivos antes de reiniciar a instância do SQL Server.

Durante os testes, vamos observar o estado do banco de dados e os logs de erro para entender o que acontece quando um arquivo está ausente. Também veremos como podemos recuperar o banco de dados do estado de recuperação pendente.

Primeiro, vamos renomear um arquivo no grupo de arquivos secundário. Após reiniciar a instância do SQL Server, descobrimos que o estado do banco de dados é de recuperação pendente. Isso ocorre porque a transação não confirmada que estava em execução no momento do desligamento precisa ser recuperada. O log de erros afirma claramente que o arquivo está ausente, mas o banco de dados não é marcado como suspeito.

Em seguida, repetimos o processo com um arquivo no grupo de arquivos primário. Novamente, o estado do banco de dados é de recuperação pendente, mas não suspeito. Ao colocar o banco de dados offline, corrigir o nome do arquivo e trazê-lo de volta online, podemos recuperar completamente o banco de dados sem problemas.

Por fim, testamos o próprio arquivo primário. Como esperado, o banco de dados entra no estado de recuperação pendente, mas não suspeito. Seguindo o mesmo processo de recuperação, podemos colocar o banco de dados online novamente.

Com base nesses testes, podemos concluir que, para um banco de dados se tornar suspeito após a inicialização do SQL Server, um ou mais dos arquivos do banco de dados devem estar danificados. Apenas arquivos ausentes ou inacessíveis resultarão no banco de dados sendo marcado como recuperação pendente.

É importante observar que o estado de recuperação pendente não é fatal. Uma vez que corrigimos o problema subjacente, como renomear o arquivo de volta para o nome original, podemos reiniciar o banco de dados e colocá-lo online sem problemas.

Em conclusão, arquivos ausentes por si só não farão com que um banco de dados do SQL Server entre em estado suspeito. O estado suspeito é reservado para bancos de dados com danos reais nos arquivos. Compreender esse conceito pode ajudá-lo a solucionar problemas e recuperar bancos de dados de forma mais eficaz.

Obrigado por ler este artigo. Esperamos que ele tenha fornecido uma melhor compreensão do estado suspeito do banco de dados do SQL Server e desmistificado o mito em torno de arquivos ausentes.

Click to rate this post!
[Total: 0 Average: 0]

Let's work together

Send us a message or book free introductory meeting with us using button below.