Diagnosticando o erro 9001 do Microsoft SQL Server: O log do banco de dados não está disponível
No final de semana, um site que eu corro parou de funcionar, registrando o seguinte erro no Visualizador de Eventos sempre que uma solicitação é feita ao site:
ID do Evento: 9001
O log do banco de dados ' database name ' não está disponível. Verifique o log de eventos para obter mensagens de erro relacionadas. Resolva os erros e reinicie o banco de dados.
O site está hospedado em um servidor dedicado, então eu posso fazer RDP no servidor e bisbilhotar. O LDFarquivo para o banco de dados existe na C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATApasta, mas a tentativa de executar qualquer trabalho com o banco de dados no Management Studio resulta em uma caixa de diálogo com o mesmo erro - 9001: O log do banco de dados não está disponível ...
É a primeira vez que recebo esse erro e hospedo este site (e outros) neste servidor da web dedicado há mais de dois anos.
Entendo que esse erro indica um arquivo de log corrompido. Consegui colocar o site online novamente, desanexando o banco de dados e restaurando um backup de alguns dias atrás, mas minha preocupação é que esse erro seja indicativo de um problema mais sinistro, ou seja, uma falha no disco rígido.
Enviei um email para o suporte da empresa de hospedagem na web e esta foi a resposta deles:
Parece não haver outras indicações da causa no log de eventos, portanto, é possível que o log esteja corrompido. Atualmente, os recursos da memória estão em 87%, o que também pode ter um impacto, mas é improvável.
O registro pode apenas "ficar corrompido?"
Minha pergunta: quais são as próximas etapas que devo seguir para diagnosticar esse problema? Como posso determinar se esse é realmente um problema de hardware? E, se houver, existem outras opções além da substituição do disco?
Bem, mais de 99% dos problemas de corrupção de banco de dados são executados no sistema de armazenamento. Metade dos problemas restantes ocorre devido à memória insuficiente, com a outra metade sendo erros no SQL Server.
As probabilidades são de que é um problema de armazenamento.
Se isso acontecer novamente, execute o DBCC CHECKDB no banco de dados e isso fornecerá mais informações sobre a corrupção e se o problema pode ser corrigido sem a restauração. Você provavelmente precisará colocar o banco de dados online no modo de emergência para executar o checkdb no banco de dados.
O uso de memória em 87% não tem nada a ver com o problema. O SQL Server executará a memória até 100% (ou próximo a ela) por design.
Obrigado pelas sugestões. Na verdade, tentei fazer o DBCC CHECKDB, mas obtive muitos erros, incluindo um erro dizendo que não foi possível encontrar o arquivo de log. Mas não tentei colocar o banco de dados on-line no modo de emergência.
Normalmente, se o log de transações estiver corrompido, é uma coisa muito ruim. O CHECKDB pode consertá-lo ou não, dependendo da gravidade da corrupção. Se você tiver backups de log de transações (seu provedor pode não permitir isso), poderá ter perdido quase nenhum dado. No final da saída do checkdb, estará o nível de reparo necessário para corrigir os problemas com os arquivos do banco de dados.
Corrigir. O uso da memória não terá nada a ver com isso - a menos que a memória esteja corrompida e apenas transferida para o disco. De qualquer forma, você deve ver algumas outras indicações de problemas de E / S nos logs de eventos. Algum lugar.
— Michael K Campbell
Você pode tentar executar um disco de verificação (chkdsk) no disco para verificar se o Windows tem algum problema com o disco. As probabilidades são de que você precisará substituir o disco. No entanto, poderia ter sido apenas um bug no código do controlador de disco ou no código do BIOS do disco. Em ambos os casos, eu procuraria substituir os discos e / ou o controlador.
Consegui resolver isso colocando o banco de dados offline no Management Studio e colocando-o novamente on-line imediatamente. dbcc checkdbgerou erros que foram resolvidos depois de fazer isso. Eu não posso dizer por que isso funcionou apenas que fez o trabalho.
Também tive esse problema recentemente e, após várias pesquisas, parece comum quando um banco de dados é definido como FECHAMENTO AUTOMÁTICO. Defino todos os bancos de dados para FECHAR AUTOMATICAMENTE = FALSO. Isso começou com um banco de dados, passou para dois e o próximo foi para todos eles. Simplesmente reiniciei o Serviço de Instância do SQL Server em vez de restaurar os bancos de dados. Outra maneira de corrigir o sintoma é colocar o banco de dados problemático offline e colocá-lo novamente online.
— Clarice Bouwer
O MS SQL colocará offline os logs de um banco de dados afetado para evitar danos ao banco de dados. É por isso que você recebe o erro 9001.
Quando você coloca o banco de dados afetado offline / online, o MS SQL habilita os logs do banco de dados afetados até que o erro ocorra novamente.
Outra maneira de resolver isso é alterar a opção Auto_Close para OFF
— Saul A. Greco V.
Eu vou adivinhar / espero que você tenha um ataque direcionado ao disco para o seu servidor sql. Se você suspeitar de problemas de hardware, a primeira coisa que eu faria é executar as ferramentas de diagnóstico / manutenção de ataques.
a segunda coisa (provavelmente simultaneamente, se você puder) é executar o dbcc checkdb no banco de dados (talvez os bancos de dados do sistema também).
— Thirster42
Ok, primeiro passo, faça um backup do seu log e dos arquivos mdf para uma unidade completamente diferente. RAPIDAMENTE! (cópia de arquivo)
Além disso, tente executar um backup completo do banco de dados.
Em seguida, tente o seguinte. Usando seu banco de dados atual, desanexe-o, se puder, e exclua o arquivo de log ou mova-o para um local completamente diferente no disco. Em seguida, reconecte o banco de dados e ele será exibido na GUI com um arquivo de log, clique em remover (ou excluir) do arquivo de log para que ele não apareça e, em seguida, clique em ok. Basicamente, anexá-lo sem um log, forçará a criação de um arquivo de log para o banco de dados no local padrão.
Sim, eu também tive esse mesmo problema, foi sobre o erro tempDb 9001, ou seja, o log não está disponível. Reiniciámos os serviços e estava tudo bem.
O problema por trás disso era SAN ou problema de armazenamento, enquanto a operação de gravação de E / S não conseguiu gravar por mais de 15 segundos.
Ontem, recebi o mesmo erro "o log do banco de dados '%' não está disponível. Erro fatal 9001, mensagem 21. Entre em contato com o administrador" -
Solução alternativa - verifiquei o 'TempDB', mas não estava acessível da mesma forma no restante dos bancos de dados do sistema. Antes de optar pela opção de reparo, simplesmente reiniciei os serviços SQL dessa instância e o problema foi resolvido :) :)
— Poonam Choudhary
Vi isso acontecer quando não há espaço em disco disponível para expansão de log; você pode verificar se havia um amplo espaço no C: \ e se seus logs estão sendo gerenciados, ou seja, sendo copiados se você estiver no modo de recuperação total.
Gostaria de mover o seu ldf (e mdf) do volume de inicialização, se você tiver a opção.
A falta de espaço no disco rígido NUNCA causará corrupção no banco de dados, a menos que você esteja usando armazenamento thin provisionado e o armazenamento base fique sem espaço. Mas isso é um pesadelo totalmente diferente.
Vou reformular ... talvez não seja a corrupção do banco de dados, mas certamente uma causa para os arquivos de log estarem indisponíveis como o op declarou.
Há mais de 25 GB de espaço livre na unidade e o banco de dados em questão tem menos de 25 MB.
O único erro que você verá ao ficar sem espaço é um erro de arquivo completo ao tentar modificar linhas no banco de dados, pois a transação não pode ser gravada no log (não o que o OP afirmou). A falta de espaço não tornaria o banco de dados indisponível (o que o OP declarava).
Discordo. O disco ficou sem espaço na unidade em que estava o arquivo de log e comecei a ver exatamente o mesmo problema em questão.