none
Erro em Base de Dados RRS feed

  • Pergunta

  • Srs,Boa tarde!

    Tenho uma base de dados com 56gb e o servidor que ela estava deu um erro e não estou conseguindo abrir a base de dados, gostaria da ajuda de vocês para tentar recuperar o  máximo de informações possiveis, o backup que tinhamos que voltou é de um pouco antigo.

    quanto tendo dar um select em uma tabela

    select * from tabela

    apresenta o erro:

    server: msg 8623, level 16, state 1, line 1

    Internal query processor erro: the query processor could not procedure a query plan .

    queria saber o que fazer li que passar o dbcc checkdb poderia resolver o problema, mas para não ficar dando tiro no escuro queria a opinião de vocês.


    Fabio Ramos Antonio

    quinta-feira, 12 de dezembro de 2013 17:13

Respostas

  • Fabio,

        Acho que o DBCC CHECKDB é uma opção... Na sua base, vai demorar algum tempo considerável, então... prepare-se...

        Depois que o dbcc terminar, poste aqui o resultado.. ele indicará quandos erros nas últimsa linhas, cole aqui para darmos uma olhada.


    Roberto Fonseca MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008 MCITP - Business Intelligence 2008

    quinta-feira, 12 de dezembro de 2013 20:58
    Moderador
  • Fabio,

    Realmente você tem problemas nas áreas de alocação desta table, uma possibilida inicial seria excluir os índices desta table e recriar novamente.

    Aparentemente a estrutura do banco também esta comprometida, neste caso, vamos novamente utilizar o comando DBCC CHECKDB com a opção REPAIR_ALLOW_DATA_LOSS para realizar a reparação dos dados.

    Vale ressaltar que você terá que alterar a forma de conexão do banco de dados de Multi_User para Single_User, para garantir que nenhum outro usuário ou sessão venha a atrapalhar, tudo correndo normalmente o banco de dados estará integro e você vai poder voltar a utilizar com a opção Multi_User.

    Mas tente excluir os índices desta table e recriar novamente!!!!


    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]

    sexta-feira, 13 de dezembro de 2013 14:23
    Moderador
  • Boa noite,

    Comandos DBCC sempre deve pensar e saber o que cada comando faz antes de executar em produção.

    Primieira coisa, sempre: Faça backup full da base, backup de log, backup de tail log. Pare a instancia do SQL Server, copie os arquivos MDF, NDF (Caso tiver) e LDF da base. Restaura essa base em outro servidor, ou na sua maquina, para garantir que o restore está funcionando.

    **Faça backup sempre antes de uma operação DBCC de reparação. Backup é uma coisa que você não precisa ter dó em fazer (rsrs).

    Se você executar o comando DBCC CHECKDB com a opção REPAIR_ALLOW_DATA_LOSS. Você está assumindo a culpa, como o próprio comando diz: repare o banco de dados, pois eu permito a perda de dados.

    Depois de fazer o backup, ache o problema, como aparentemente são muitos erros, faça uma consulta do tipo select * from em todas tabelas do seu banco de dados. Gere um script para isso.

    Se todos comandos de consulta executar, então você teoricamente não tem problema de corrupção de páginas do tipo data page. Gere os scripts de drop e create index. E recrie todos. Verifique se ainda há problema com o comando DBCC CHECKDB('sua base').

    Se ainda tiver problemas, responda aqui, que vamos tentar te ajudar.


    Jefferson Santos [MCTS SQL Server]

    terça-feira, 17 de dezembro de 2013 00:54

Todas as Respostas

  • Fabio,

        Acho que o DBCC CHECKDB é uma opção... Na sua base, vai demorar algum tempo considerável, então... prepare-se...

        Depois que o dbcc terminar, poste aqui o resultado.. ele indicará quandos erros nas últimsa linhas, cole aqui para darmos uma olhada.


    Roberto Fonseca MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008 MCITP - Business Intelligence 2008

    quinta-feira, 12 de dezembro de 2013 20:58
    Moderador
  • Roberto,Bom dia!

    O final da mensagem que retornou foi :

    CHECKDB found 22191 allocation errors and 116023 consistency errors in database

    O Texto é bem grande com várias tabelas, vou postar alguns exemplos a seguir, somente uma ideia.

    Server: Msg 8904, Level 16, State 1, Line 1
    Extent (1:6934464) in database ID 7 is allocated by more than one allocation object.

    Server: Msg 8978, Level 16, State 1, Line 1

    Server: Msg 8913, Level 16, State 1, Line 1
    Extent (1:6979888) is allocated to 'GAM' and at least one other object.

    Server: Msg 8909, Level 16, State 1, Line 1
    Table error: Object ID 0, index ID 0, page ID (1:7012575). The PageId in the page header = (0:0).

    Server: Msg 8978, Level 16, State 1, Line 1
    Table error: Object ID 1118431554, index ID 1. Page (1:6594431) is missing a reference from previous page (1:7090822). Possible chain linkage problem.

    Server: Msg 8977, Level 16, State 1, Line 1
    Table error: Object ID 1118431554, index ID 1. Parent node for page (1:6589564) was not encountered.

    Table error: Object ID 2105109519, index ID 37. Page (1:1417656) is missing a reference from previous page (1:7062051). Possible chain linkage problem.
    Server: Msg 8976, Level 16, State 1, Line 1
    Table error: Object ID 2105109519, index ID 37. Page (1:7013624) was not seen in the scan although its parent (1:680012) and previous (1:6667513) refer to it. Check any previous errors.
    Server: Msg 8928, Level 16, State 1, Line 1
    Object ID 2105109519, index ID 37: Page (1:7013625) could not be processed. See other errors for details.


    Fabio Ramos Antonio

    sexta-feira, 13 de dezembro de 2013 10:41
  • Fabio,

    Realmente você tem problemas nas áreas de alocação desta table, uma possibilida inicial seria excluir os índices desta table e recriar novamente.

    Aparentemente a estrutura do banco também esta comprometida, neste caso, vamos novamente utilizar o comando DBCC CHECKDB com a opção REPAIR_ALLOW_DATA_LOSS para realizar a reparação dos dados.

    Vale ressaltar que você terá que alterar a forma de conexão do banco de dados de Multi_User para Single_User, para garantir que nenhum outro usuário ou sessão venha a atrapalhar, tudo correndo normalmente o banco de dados estará integro e você vai poder voltar a utilizar com a opção Multi_User.

    Mas tente excluir os índices desta table e recriar novamente!!!!


    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]

    sexta-feira, 13 de dezembro de 2013 14:23
    Moderador
  • Boa noite,

    Comandos DBCC sempre deve pensar e saber o que cada comando faz antes de executar em produção.

    Primieira coisa, sempre: Faça backup full da base, backup de log, backup de tail log. Pare a instancia do SQL Server, copie os arquivos MDF, NDF (Caso tiver) e LDF da base. Restaura essa base em outro servidor, ou na sua maquina, para garantir que o restore está funcionando.

    **Faça backup sempre antes de uma operação DBCC de reparação. Backup é uma coisa que você não precisa ter dó em fazer (rsrs).

    Se você executar o comando DBCC CHECKDB com a opção REPAIR_ALLOW_DATA_LOSS. Você está assumindo a culpa, como o próprio comando diz: repare o banco de dados, pois eu permito a perda de dados.

    Depois de fazer o backup, ache o problema, como aparentemente são muitos erros, faça uma consulta do tipo select * from em todas tabelas do seu banco de dados. Gere um script para isso.

    Se todos comandos de consulta executar, então você teoricamente não tem problema de corrupção de páginas do tipo data page. Gere os scripts de drop e create index. E recrie todos. Verifique se ainda há problema com o comando DBCC CHECKDB('sua base').

    Se ainda tiver problemas, responda aqui, que vamos tentar te ajudar.


    Jefferson Santos [MCTS SQL Server]

    terça-feira, 17 de dezembro de 2013 00:54
  • Olá,

        Também acho que o REPAIR_ALLOW_DATA_LOSS é demais para ser utilizado como primeira opção.... Eu tentaria, o REPAIR_FAST, depois o REPAIR_REBUILD, se necessário, além das dicas citadas pelo Jefferson.


    Roberto Fonseca MCT / MCITP - Database Administrator 2008 MCITP - Database Developer 2008 MCITP - Business Intelligence 2008


    terça-feira, 17 de dezembro de 2013 14:11
    Moderador
  • Srs,Boa tarde!

    Retomando o caso do problema na base, fiz os seguintes comandos:

    alter database CM5 set single_user with rollback immediate;
    begin transaction;
    dbcc checkdb ('cm5',repair_fast);
    alter database cm5 set multi_user;

    e no final ele não colocou a base em multi_user e apareceram os seguntes erro:

    DBCC results for 'cm5'.
    DBCC results for 'sysobjects'.
    There are 9798 rows in 193 pages for object 'sysobjects'.
    DBCC results for 'sysindexes'.
    There are 7353 rows in 438 pages for object 'sysindexes'.
    DBCC results for 'syscolumns'.
    There are 46688 rows in 1389 pages for object 'syscolumns'.
    DBCC results for 'systypes'.
    There are 26 rows in 1 pages for object 'systypes'.
    DBCC results for 'syscomments'.

    entre vários outros, só tenho o backup full do dia anterior ao ocorrido e um backup que fiz no dia não tem backup de log, alguém pode tentar me ajudar?

    Agradeço antecipadamente.

    Em uma outra base com o backup do dia do ocorrido eu usei um software chamado recovery toolbox, mas o que ele me retornou foram poucas tabelas e com vários pulos de dados.


    Fabio Ramos Antonio

    quinta-feira, 16 de janeiro de 2014 19:39
  • Srs.Boa tarde

    Complementando

    Resultado do comando

    Select * from Clientes

    Attempt to fetch logical page (1:7053159) in database 'cm5' belongs to object 'Logs', not to object 'Clientes'.

    pelo pouco que conheço deve ser erro de pagina

    Fabio Ramos


    Fabio Ramos Antonio

    sexta-feira, 17 de janeiro de 2014 19:48
  • Jefferson e Roberto,

    Realmente com esta opção Repair_Allow_Data_Loss estamos assumindo que podemos ser o culpado ou causador da falha, mas isso é um ponto que neste momento não vale a pena tentar saber, o importante é recuperar.

    Reconheço que as opções Repair_Fast ou Repair_ReBuild podem prover solução, mas isso vai depender em muito de como a estrutura de alocação esta afetada.

    Vale a pena fazer uma verificação tentando inicialmente utilizar o Repair_Fast e aguardar o retorno do próprio SQL Server.

    Valeu pela observação.


    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 fevereiro de 2014 12:37
    Moderador