locked
Dbcc Check falha na gam, sgam e PFS RRS feed

  • Discussão Geral

  • Bom dia povo tudo blz?
    Pessoal já estou a alguns dias brigando com essa base.
    E um daqueles problemas que já fala para o cliente que se ele não tiver bkp pode esquecer .
    Mais sou teimoso e estou tentando chegar no minimo de perda possível.
    No entanto problemas na gam, sgam e ou PFS então acho difícil não haver pouca perda de dados.
    Msg 8998, Level 16, State 2, Line 2
    Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 6 pages from (3:3777096) to (3:3785183). See other errors for cause.
    Alguém pode me dar uma luz.
    sexta-feira, 10 de julho de 2015 14:07

Todas as Respostas

  • Andre bom dia,

    Você não pode fazer um restore somente da pagina 3?


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    sexta-feira, 10 de julho de 2015 14:11
  • Pois e Thiago o problema tem sido encontrar essa pagina a qual acredito que o cliente não tenha pois

    o bkp mais antigo e integro e de 2008 e em modo simples. 

     
    sexta-feira, 10 de julho de 2015 14:16
  • E carai agora ferro sem o cara não tem bkp... 

    Acho que você tem um grande desafio, resolver o problema sem ter perda de dados acho quase impossível.


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    sexta-feira, 10 de julho de 2015 14:57
  • Andre,

    Vou tentar contribuir:

    1. Qual é o tamanho deste banco de dados?
    2. Você já tentou fazer algum processo de import/export dos dados?
    3. Por acaso já tentou fazer o Rebuild deste banco?

    Há algum tempo tive uma necessidade similar e como o banco de dados não era muito grande, algo em torno de 50Gbs, tomei a decisão de fazer toda exportação da estrutura do banco para outro da seguinte forma.

    1. Crie um novo banco de dados, com a mesma estrutura de arquivos e filegroups;
    2. Configure o Recovery Model e Isolation Level iguais ao atual banco de dados; e
    3. Através da ferramenta Import/Export Data você pode fazer todo processo de ETL do seu dados e tabelas.

    Acredito que esta é uma possiblidade que vai com certeza resolver o seu problema em relação a esta falha na estrutura física e lógica do seu banco de dados.


    Pedro Antonio Galvao Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    sexta-feira, 10 de julho de 2015 16:37
    Moderador
  • Blz valeu Thiago.

    Vamos lá 

    1. Qual é o tamanho deste banco de dados?R: Ele tem 220 gb sendo que 200 gb esta em uma so tabela aonde esta o problema.
    2. Você já tentou fazer algum processo de import/export dos dados?R.: Sim como eu não atualizai as estatísticas o sql apresenta 120.777.304 de linhas e quando faço o export a quantidade de dado cai para 5.418.715 e extremamente grande a perda de dados.
    3. Por acaso já tentou fazer o Rebuild deste banco? R.: Pois e não tinha pensado nisso ainda pois como os problemas estão em páginas de alocação talvez de certo. Vou tentar.

    Vou tentar também os passos abaixo também assim que terminar eu te falo muito obrigado.

    1. Crie um novo banco de dados, com a mesma estrutura de arquivos e filegroups;
    2. Configure o Recovery Model e Isolation Level iguais ao atual banco de dados; e
    3. Através da ferramenta Import/Export Data você pode fazer todo processo de ETL do seu dados e tabelas.

    sexta-feira, 10 de julho de 2015 18:05
  • André por se tratar da pagina 3, se eu fosse você faria o restore da base de 2008, um backup da base atual, faria uma conferencia com dos dados e depois executaria o checkdb com o repair_allow_data_loss para tentar perder o minimo de dados possível. 


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    sexta-feira, 10 de julho de 2015 18:27
  • Parece ser corrupção na página PFS que rastreia o intervalo de páginas 3777096 e 3785183.

    Dá uma olhada neste link:

    http://blog.nhaslam.com/2011/08/03/page-corruption-in-a-sql-server-database/

    Você precisa conhecer bem a estrutura das páginas para saber o que está corrompido(ID de cadeia de páginas, checksum, array de index(não utilizada pela PFS),  etc).

    No entanto, o conselho de exportar dados para outro banco é mais prudente, pois as páginas marcadas como dirty na tabela suspect_pages do msdb provocam demasiada gravação de log e alterar páginas com o DBCC WRITEPAGE em um banco de dados pode ser uma estrada escorregadia caso existir várias páginas corrompidas.

    :-(

    terça-feira, 14 de julho de 2015 20:03
  • Blz valeu Thiago.

    Vamos lá 

    1. Qual é o tamanho deste banco de dados?R: Ele tem 220 gb sendo que 200 gb esta em uma so tabela aonde esta o problema.
    2. Você já tentou fazer algum processo de import/export dos dados?R.: Sim como eu não atualizai as estatísticas o sql apresenta 120.777.304 de linhas e quando faço o export a quantidade de dado cai para 5.418.715 e extremamente grande a perda de dados.
    3. Por acaso já tentou fazer o Rebuild deste banco? R.: Pois e não tinha pensado nisso ainda pois como os problemas estão em páginas de alocação talvez de certo. Vou tentar.

    Vou tentar também os passos abaixo também assim que terminar eu te falo muito obrigado.

    1. Crie um novo banco de dados, com a mesma estrutura de arquivos e filegroups;
    2. Configure o Recovery Model e Isolation Level iguais ao atual banco de dados; e
    3. Através da ferramenta Import/Export Data você pode fazer todo processo de ETL do seu dados e tabelas.

    André,

    Acho que você se confundiu, este procedimento foi eu quem indicou e não Thiago, sem crise, vamos em frente.


    Pedro Antonio Galvao Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    quarta-feira, 15 de julho de 2015 18:12
    Moderador