none
BANCO DE DADOS SQL SERVER 2008 EM SUSPECT RRS feed

  • Pergunta

  • Bom dia Pessoal...

    Bom dia pessoal,

    Hoje me deparei com um banco de dados em suspect do SQL SERVER 2008 e não estou conseguindo recuperar este banco.
    Este é o processo que sempre segui e deu certo para o SQL SERVER 2000, isso pra quando seria o LDF que está corrompido.


    -----------------------------------------------------------------------

    1. NÃO EXCLUIR O BANCO EM SUSPECT
    2. PARAR O SERVIÇO DO SQL
    3. FAZER A CÓPIA DA PASTA ONDE SE LOCALIZA O MDF E LDF
    4. EXCLUIR SOMENTE O ARQUIVO LDF DA PASTA ORIGINAL
    5. INICIAR O SERVIÇO DO SQL

    -----------------------------------------------------------------------

    sp_configure 'allow updates', 1

    reconfigure with override

    -----------------------------------------------------------------------

    update sysdatabases set status = 32768 where name = 'BANCO'

    -----------------------------------------------------------------------

    dbcc rebuild_log ('BANCO', 'D:\DATABASES\BANCO_1.ldf')

    -----------------------------------------------------------------------

    exec master.dbo.sp_dboption 'BANCO','dbo use only',false

    exec master.dbo.sp_dboption 'BANCO','single user',true

    dbcc checkdb (BANCO , repair_allow_data_loss ) WITH ALL_ERRORMSGS

    ----------------------------------------------------------------------

    6. APÓS FINALIZAR O DBCC CHECKDB, RETIRAR O BANCO DO MODO SINGLE,USER

    exec master.dbo.sp_dboption 'BANCO','single user',false

    -----------------------------------------------------------------------

    Tentei fazer o mesmo processo para o SQL SERVER 2008, porém ao tentar executar a linha:

    update sysdatabases set status = 32768 where name = 'BANCO'

    Ele me retorna o seguinte erro:

    Ad hoc updates to system catalogs are not allowed.

     

    Será que o arquivo que foi corrompido foi o mdf?
    Caso sim, existe alguma outra forma de tentar recuperar este mdf?


    Valeu

    • Movido Gustavo Maia Aguiar terça-feira, 4 de janeiro de 2011 13:22 (De:SQL Server - Desenvolvimento Geral)
    terça-feira, 4 de janeiro de 2011 13:11

Respostas

  • AQUI ESTÁ MEU PASSO-A-PASSO DE COMO CONSEGUI RECUPERAR O BANCO DE DADOS.

    NO MEU CASO....

    ----------------------------------


    1.  PARAR O SERVIÇO DO SQL

    2.  FAZER UMA CÓPIA DA PASTA ONDE ESTÁ ARMAZENADO OS ARQUIVOS MDF E LDF

    3.  EXCLUIR OS ARQUIVOS MDF E LDF DESTA PASTA

    4.  INICIAR O SERVIÇO DO SQL

    5.  EXCLUIR O BANCO DE DADOS

        OBS: TENTEI EXCLUIR DIRETAMENTE O BANCO QUE ESTAVA EM SUPECT MAS NÃO EXCLUÍA, ENTÃO POR ISSO ELIMINEI O MDF E LDF PRIMEIRO E DEPOIS O BANCO.

    6.  RESTAURAR UM BACKUP DO BANCO ANTIGO COM O MESMO NOME QUE ESTAVA ANTERIORMENTE E NO MESMO CAMINHO PARA OS ARQUIVOS MDF E LDF

    7. PARAR O SERVIÇO DO SQL NOVAMENTE

    8.  EXCLUIR OS ARQUIVOS MDF E LDF DESTA PASTA E SUBSTITUÍ-LOS PELOS 2 ARQUIVOS MAIS RECENTES (OS QUE ESTAVAM EM SUSPECT)

    9.  INICIAR O SERVIÇO DO SQL

            ----EXECUTAR OS SCRIPTS ABAIXO---- 

    10.  ALTER DATABASE BANCO SET EMERGENCY

    11.  ALTER DATABASE BANCO SET SINGLE_USER

    12.  DBCC CHECKDB (BANCO, repair_allow_data_loss ) WITH ALL_ERRORMSGS

    13. ALTER DATABASE BANCO SET read_write

    14. ALTER DATABASE BANCO SET multi_user

     

    MUITO OBRIGADA PELA AJUDA DE TODOS, TOMEI CONHECIMENTOS DE COISAS QUE NÃO SABIA.

    ABRAÇOS

     

    terça-feira, 4 de janeiro de 2011 19:38

Todas as Respostas

  • Caso seu arquivo MDF não esteja corrompido, procure por procedimentos de reconstrução de logs (rebuild), isto vai lhe ser útil.

    Torça para que tenha corrompido apenas o arquivo de log LDF , pois isto te dará menos trabalho, porque para recuperar o MDF creio que seja mais complexo.

    terça-feira, 4 de janeiro de 2011 13:14
  • Bom Dia,

    Quando um banco de dados entra em SUSPECT normalmente temos o hábito de agir diretamente para resolver o problema o mais rápido possível (principalmente se o banco for importante). Normalmente, esse impulso acaba por nos fazer rodar qualquer comando que devolva a base tornando-a acessível e muitas vezes evitamos o "pensar". A maioria dos comandos executados até seriam úteis, mas na ordem em que foram executados, não haverá mais o que fazer. Receio que caso você não tenha conseguido, em virtude da ordem não haverá mais o que fazer. O correto seria:

    - Executar a sp_resetstatus
    - Rodar o comando DBCC DBRECOVER
    - Verificar a possibilidade de restauração com uma estratégia baseada em Tail Log
    - Colocar o banco em modo de emergência para exportar os dados

    Até esse ponto, as alternativas acima não impõe nenhum risco ao SGBD. Se elas forem utilizadas nessa ordem e o banco puder se restaurados, não pioramos nada em relação ao cenário da base em SUSPECT.

    Alternativas como excluir LDFs, copiar MDFs por cima, rodar o DBCC com ALLOW_DATA_LOSS já são alternativas muito mais arriscadas, pois, além de incorrer em perda potencial de dados, uma vez executadas anulam outras alternativas que poderiam resolver o problema sem incorrer em perda de dados.

    Se as quatro primeiras alternativas falharem, então sim devemos partir para as alternativas arriscadas, mas não devemos começar pelas arriscadas primeiro, pois, qualquer uma delas invalidas as primeiras (que são bem mais seguras).

    exec sp_configure 'allow updates', 1
    reconfigure with override
    update sysdatabases set status = 32768 where name = 'BANCO'
    

    No SQL Server 2008 não temos essa possibilidade, esse conjunto foi substituído por ALTER DATABASE Banco SET EMERGENCY.

    Na atual situação, acho que no máximo um ATTACH do MDF. Caso não funcione, tente o CREATE DATABASE com o parâmetro FOR ATTACH e o REBUILD_LOG

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com/

    Simulado para o Exame 70-433 – MCTS: Microsoft SQL Server 2008 – Database Development – Parte 07
    http://gustavomaiaaguiar.wordpress.com/2010/12/31/simulado-para-o-exame-70-433-mcts-microsoft-sql-server-2008-database-development-%e2%80%93-parte-07/


    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 4 de janeiro de 2011 13:37
  • Realmente Carlos, estou achando que o que foi corrompido foi o mdf :(
    terça-feira, 4 de janeiro de 2011 14:50
  • Certo Gustavo...

    É bem isso mesmo que acontece, na hora do problema queremos solucionar o mais rápido possível.

    Você comentou dos processos que poderiam ter sidos executados sobre piorar a situação, mas eu fiz uma cópia dos arquivos mdf e ldf antes de fazer qualquer alteração.

    Estou esperando o servidor chegar aqui para tentar fazer o processo que me passou do attach. Só que não entendi o seguinte, se o banco tá em suspect, eu vou dar um dettach e depois em seguinda attach novamente? isso mudaria alguma coisa? pra mim acho q continuaria em suspect, a não ser q entendi errada sua colocação.

    E eu não conheço essas estratégias baseada em Tail Log, se puder me passar alguns exemplo para depois eu poder dar uma pesquisada.

    Daqui um pouco posto aqui o que tentei.

    Obrigada por enquanto....

     

    terça-feira, 4 de janeiro de 2011 15:00
  • Oi Sheetara,

    Como o log original foi excluído, isso já eliminou todas as outras estratégias. Só temos duas cartas na manga agora:

    - Você pode colocar o banco em modo de emergência e exportar todos os dados para um novo banco
    - Você pode tentar atachar a cópia do MDF e do LDF que foram copiados como um banco novo e torcer para dar certo. Se o MDF estiver corrompido não teremos mais o que fazer. Você ficará na última posição de seus backups (se houver).

    A estratégia de Tail Log pressupõe que a corrupção ocorreu somente no MDF (e não no LDF). Então você consegue tirar um backup de Log (mesmo com o banco em SUSPECT) através do BACKUP LOG com a opção NO_TRUNCATE. Posteriormente você restaura um backup full, o último diferencial, os logs necessários e o último log tirado (TAIL LOG). Assim você consegue voltar no banco no momento do desastre. Há detalhes sobre ela em um Webcast que apresentei. Consulte os links abaixo:

    SQL Server Day
    http://gustavomaiaaguiar.wordpress.com/2009/11/01/sql-server-day/

    SQL Server Day – Depois do Evento
    http://gustavomaiaaguiar.wordpress.com/2009/11/09/sql-server-day-%e2%80%93-depois-do-evento/

    SQLServerDF Encontro V – PASS Summit e Disaster Recovery
    http://gustavomaiaaguiar.wordpress.com/2009/11/28/sqlserverdf-encontro-v-pass-summit-e-disaster-recovery/

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com/

    Simulado para o Exame 70-433 – MCTS: Microsoft SQL Server 2008 – Database Development – Parte 07
    http://gustavomaiaaguiar.wordpress.com/2010/12/31/simulado-para-o-exame-70-433-mcts-microsoft-sql-server-2008-database-development-%e2%80%93-parte-07/


    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 4 de janeiro de 2011 15:33
  •  

    Não sei se já é muito tarde, mas ve se esse artigo te ajuda em algo:

     

    http://fabriciolima.net/blog/2010/10/08/casos-do-dia-a-dia-database-em-modo-suspect/

     

     


    Fabrício França Lima | MCP, MCTS, MCITP | Visite meu site: http://fabriciodba.wordpress.com/ | Dicas de artigos SQL: Siga-me no twitter @fabriciodba.
    terça-feira, 4 de janeiro de 2011 15:39
  • Gustavo...

    Isto foi o que rodei e o retorno:

    Eu tentei criar o banco com ele recriando novo ldf e não deu certo :(


    CREATE DATABASE BANCO ON
    (NAME = BANCO, FILENAME = 'd:\BASE\BANCO.mdf')
    FOR ATTACH_REBUILD_LOG

     

    File activation failure. The physical file name "D:\BASE\BANCO_1.ldf" may be incorrect.
    The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.
    Msg 1813, Level 16, State 2, Line 1
    Could not open new database 'BANCO'. CREATE DATABASE is aborted.

     

    terça-feira, 4 de janeiro de 2011 17:39
  • Aqui eu tentei restaurar um backup antigo..

    Depois substitui somente pelo mdf atual e tentei entrar em single user:

    Msg 5173, Level 16, State 1, Line 1
    One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files.  If this is an existing database, the file may be corrupted and should be restored from a backup.
    Log file 'd:\BASE\BANCO_1.ldf' does not match the primary file.  It may be from a different database or the log may have been rebuilt previously.
    Msg 945, Level 14, State 2, Line 1
    Database 'BANCO' cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.
    Msg 5069, Level 16, State 1, Line 1
    ALTER DATABASE statement failed.
    sp_dboption command failed.

     

    • Editado S h e e t a r a terça-feira, 4 de janeiro de 2011 17:53 CORREÇÃO
    terça-feira, 4 de janeiro de 2011 17:53
  • Aqui eu tentei restaurar um backup antigo..

    Depois substitui pelo mdf e pelo ldf atuais, daí o banco agora mudou o status para (In Recovery) e tornou ficar em suspect

    :|

    terça-feira, 4 de janeiro de 2011 17:59
  • Já parti para estes scripts:

    ALTER DATABASE banco SET EMERGENCY


    ALTER DATABASE banco SET SINGLE_USER


    DBCC CHECKDB (banco , REPAIR_ALLOW_DATA_LOSS)
    WITH NO_INFOMSGS, ALL_ERRORMSGS

    Por enquanto ele está em execução...vamos ver se vai resolver algo.

     

    terça-feira, 4 de janeiro de 2011 18:06
  • Não sei se vc já tentou reconstruir o log com este comando:

    DBCC rebuild_log('BASE','C:\BASE.LDF')
    

    terça-feira, 4 de janeiro de 2011 18:42
  • opaaaaaa..... deu certo !!!!

     

    Depois de rodar o DBCC CHECKDB 2 X, ele retornou 0 erros e FINALMENTE consegui recuperar o banco de dados!

    Logo mais escreve certinho os passos que fiz.

     

    Obrigada a todos ;)

     

    terça-feira, 4 de janeiro de 2011 18:42
  • Carlos,

    Desta forma não consegui reconstruir o log no sql server 2008, mas eu tinha tentando recriar desta forma recriando o banco novamente:

    CREATE DATABASE BANCO ON
    (NAME = BANCO, FILENAME = 'd:\BASE\BANCO.mdf')
    FOR ATTACH_REBUILD_LOG

     

    terça-feira, 4 de janeiro de 2011 18:45
  • AQUI ESTÁ MEU PASSO-A-PASSO DE COMO CONSEGUI RECUPERAR O BANCO DE DADOS.

    NO MEU CASO....

    ----------------------------------


    1.  PARAR O SERVIÇO DO SQL

    2.  FAZER UMA CÓPIA DA PASTA ONDE ESTÁ ARMAZENADO OS ARQUIVOS MDF E LDF

    3.  EXCLUIR OS ARQUIVOS MDF E LDF DESTA PASTA

    4.  INICIAR O SERVIÇO DO SQL

    5.  EXCLUIR O BANCO DE DADOS

        OBS: TENTEI EXCLUIR DIRETAMENTE O BANCO QUE ESTAVA EM SUPECT MAS NÃO EXCLUÍA, ENTÃO POR ISSO ELIMINEI O MDF E LDF PRIMEIRO E DEPOIS O BANCO.

    6.  RESTAURAR UM BACKUP DO BANCO ANTIGO COM O MESMO NOME QUE ESTAVA ANTERIORMENTE E NO MESMO CAMINHO PARA OS ARQUIVOS MDF E LDF

    7. PARAR O SERVIÇO DO SQL NOVAMENTE

    8.  EXCLUIR OS ARQUIVOS MDF E LDF DESTA PASTA E SUBSTITUÍ-LOS PELOS 2 ARQUIVOS MAIS RECENTES (OS QUE ESTAVAM EM SUSPECT)

    9.  INICIAR O SERVIÇO DO SQL

            ----EXECUTAR OS SCRIPTS ABAIXO---- 

    10.  ALTER DATABASE BANCO SET EMERGENCY

    11.  ALTER DATABASE BANCO SET SINGLE_USER

    12.  DBCC CHECKDB (BANCO, repair_allow_data_loss ) WITH ALL_ERRORMSGS

    13. ALTER DATABASE BANCO SET read_write

    14. ALTER DATABASE BANCO SET multi_user

     

    MUITO OBRIGADA PELA AJUDA DE TODOS, TOMEI CONHECIMENTOS DE COISAS QUE NÃO SABIA.

    ABRAÇOS

     

    terça-feira, 4 de janeiro de 2011 19:38
  • Sheetara,

    Se interessar a alguém no meu blog tem algumas informações sobre como recuperar banco de dados em estado suspect.

    Acessem: pedrogalvaojunior.wordpress.com


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    quarta-feira, 5 de janeiro de 2011 00:36
    Moderador
  • Muito Bom, segui esses passos e consegui recuperar com facilidade um banco corrompido.

    Vlw!

    quarta-feira, 2 de janeiro de 2013 14:24
  • segui esta dica e também consegui recuperar um banco em suspect. Valeu mesmo!

    Obrigado a você e a todos que compartilham conhecimento.

    domingo, 9 de março de 2014 21:47
  • Eu consegui resolver somente executando os Scripts.

     ----EXECUTAR OS SCRIPTS ABAIXO---- 

    10.  ALTER DATABASE BANCO SET EMERGENCY

    11.  ALTER DATABASE BANCO SET SINGLE_USER

    12.  DBCC CHECKDB (BANCO, repair_allow_data_loss ) WITH ALL_ERRORMSGS

    13. ALTER DATABASE BANCO SET read_write

    14. ALTER DATABASE BANCO SET multi_user

    quarta-feira, 27 de agosto de 2014 22:04