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?

obrigado

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.

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.

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

http://sqlmag.com/blog/worst-practice-allowing-autoclose-sql-server-databases

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).

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.

Avise-se me.

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 :) :)

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.