none
TABELA CORROMPIDA SQL SERVER 2008 RRS feed

  • Pergunta

  • ESTOU COM UMA TABELA CORROPIDA, NÃO CONSIGO ACESSAR, JÁ EXECUTEIS VÁRIOS COMANDOS, DBCC CHECKTABLE E NADA DÁ CERTO,, DÁ UM ERRO DO TIPO:

    SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x4d73f960; actual: 0x4d77f960). It occurred during a read of page (1:6352) in database ID 25 at offset 0x000000031a0000 in file 'c:\Arquivos de programas\Microsoft SQL Server\MSSQL10_50.DLINK\MSSQL\DATA\SERRA.mdf'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.


    domingo, 1 de maio de 2011 20:26

Respostas

  • Bom Dia,

    Não recomendo em hipótese nenhuma a execução desse comando como primeira alternativa. Veja que "ALLOW_DATA_LOSS" significa que você está aceitando perder dados para resolver o problema e isso nem sempre é desejável ou necessário. Há outras alternativas que podem ser usadas antes desse comando (DBCC DBRECOVER, sp_resetstatus, Tail Log, DBCC PAGE, dropar e reconstruir índices, etc)

    [ ]s,

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

    Consultas parametrizadas, ISNULL e SQL dinâmica
    http://gustavomaiaaguiar.wordpress.com/2011/05/19/consultas-parametrizadas-isnull-e-sql-dinmica/


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Richard Juhasz segunda-feira, 6 de junho de 2011 20:37
    quinta-feira, 19 de maio de 2011 10:59
  • Gefferson,

     

    Não encontrei nada sobre como solucionar este problema em questão nunca confrontei, todo caso, checksum é uma contagem que o SQL faz em relação as paginas de dados, se voce realizar um backup pelo SSMS, vera que existem opções como fazer checksum assim que terminar, entre outras.

     

    Bom, a primeira pergunta de todas, existe um backup valido? se sim, eu voltaria o mesmo o mais rapido possivel, ao menos para ja pegar as informações e manter como reserva.

    Segundo: Se sua base for recovery model full e não foi truncado o log da mesma nem realizado o backup do log, eu faria o backup de taillog e restauraria, teoricamente a perda de informação deve ser minimizada.

    Vi pessoas comentando que resolveram este problema apenas fazendo um novo Bkp/Restore, o que pode ser muito demorado.

    Bom, em relação ao comando passado pela Vanessa, como o Gustavo comentou, as chances de haver perda de dados são grandes, o que até onde imagino tem que ser evitado.

    Eu tentatia um comando pareciso, porem ao invez do Allow_Data_loss, eu faria com repair_rebuild primeiro e tentaria todas as opções descritas acima, caso nada funcionasse, allow_data_loss é uma maneira de contornar, mas com grandes impactos.


    Oracle OCA11g, MCC 2011! Dicas e novidades: www.fabrizziocaputo.wordpress.com
    • Marcado como Resposta Richard Juhasz segunda-feira, 6 de junho de 2011 20:37
    quinta-feira, 19 de maio de 2011 19:44
    Moderador

Todas as Respostas

  • Gefferson,

    Pode ser um erro de algum registro. Se vc der qq comando tipo select top1 * from tabela, dá o erro? Ja peguei varios problemas assim que eram de registros...Depois que retirei tais registros voltou a consistencia da tabela.

    Att.,


    Marco Antônio Pinheiro / MCTS - Database Developer 2008 http://marcoantoniopinheiro.blogspot.com Se o post foi útil, não esqueça de marcá-lo.
    segunda-feira, 2 de maio de 2011 00:05
  • Já executou o comando DBCC CHECKDB nessa database SERRA? Ele retorna esse erro acima?

    Ve se esse artigo te ajuda. Tem uma forma de você ler essa página que está com problemas para saber o que tem nela.

    http://fabriciolima.net/blog/2011/03/17/casos-do-dia-a-dia-erro-ao-executar-o-comando-dbcc-checkdb/

    Nos de um retorno.


    Fabrício França Lima | MCP, MCTS, MCITP | Visite meu site: http://fabriciolima.net | Dicas de artigos SQL: Siga-me no twitter @fabriciodba.
    segunda-feira, 2 de maio de 2011 03:49
  • Gefferson, eu também estava com o mesmo problema e a única coisa que me salvou foi os comandos abaixo...faça o teste e poste aqui novamente:

            DBCC CHECKDB ('nome do banco de dados') WITH ALL_ERRORMSGS
    ALTER DATABASE nome do banco de dados SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    DBCC CheckDB ('nome do banco de dados', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS
    ALTER DATABASE nome do banco de dados SET MULTI_USER

     

    quarta-feira, 18 de maio de 2011 18:29
  • Bom Dia,

    Não recomendo em hipótese nenhuma a execução desse comando como primeira alternativa. Veja que "ALLOW_DATA_LOSS" significa que você está aceitando perder dados para resolver o problema e isso nem sempre é desejável ou necessário. Há outras alternativas que podem ser usadas antes desse comando (DBCC DBRECOVER, sp_resetstatus, Tail Log, DBCC PAGE, dropar e reconstruir índices, etc)

    [ ]s,

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

    Consultas parametrizadas, ISNULL e SQL dinâmica
    http://gustavomaiaaguiar.wordpress.com/2011/05/19/consultas-parametrizadas-isnull-e-sql-dinmica/


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Richard Juhasz segunda-feira, 6 de junho de 2011 20:37
    quinta-feira, 19 de maio de 2011 10:59
  • Gustavo, quando pedi para ele realizar um teste...é claro que suponho que ele vá fazer isto em um banco de homologação e que depois verificará no próprio LOG que os comandos resultam a integridade de seus dados, antes de realizar no banco de produção.


    Mas você também deu uma super dica, esta eu dessconhecia e se eu tiver um tempo aqui farei os testes.

     

     

    quinta-feira, 19 de maio de 2011 19:31
  • Gefferson,

     

    Não encontrei nada sobre como solucionar este problema em questão nunca confrontei, todo caso, checksum é uma contagem que o SQL faz em relação as paginas de dados, se voce realizar um backup pelo SSMS, vera que existem opções como fazer checksum assim que terminar, entre outras.

     

    Bom, a primeira pergunta de todas, existe um backup valido? se sim, eu voltaria o mesmo o mais rapido possivel, ao menos para ja pegar as informações e manter como reserva.

    Segundo: Se sua base for recovery model full e não foi truncado o log da mesma nem realizado o backup do log, eu faria o backup de taillog e restauraria, teoricamente a perda de informação deve ser minimizada.

    Vi pessoas comentando que resolveram este problema apenas fazendo um novo Bkp/Restore, o que pode ser muito demorado.

    Bom, em relação ao comando passado pela Vanessa, como o Gustavo comentou, as chances de haver perda de dados são grandes, o que até onde imagino tem que ser evitado.

    Eu tentatia um comando pareciso, porem ao invez do Allow_Data_loss, eu faria com repair_rebuild primeiro e tentaria todas as opções descritas acima, caso nada funcionasse, allow_data_loss é uma maneira de contornar, mas com grandes impactos.


    Oracle OCA11g, MCC 2011! Dicas e novidades: www.fabrizziocaputo.wordpress.com
    • Marcado como Resposta Richard Juhasz segunda-feira, 6 de junho de 2011 20:37
    quinta-feira, 19 de maio de 2011 19:44
    Moderador