FGID propery is incorrect


A algumas semanas o pessoal me ligou com um problema em uma base de um cliente.

A base possuia 180GB, divididos em 6 arquivos todos no FG Primary,,, Dois destes arquivos estavam em unidades que apresentaram problemas e o pessoal conseguiu recuperar utilizando aqueles programas de recuperação RAW.

Quando acessei o ambiente a base estava em modo Emergencial e não aceitava nenhuma interação, o errorlog mostrava que quando ele tentava ler a base apresentava erro 5172 que o cabeçalho do “arquivo X” não era um cabeçalho válido para um arquivo de banco de dados e que a propriedade de FGID era incorreta…

FGID

hhhhmmmm… isso não estava cheirando muito bem…

O melhor dos mundos seria recuperar a base utilizando um backup mais recente, movendo os arquivos para unidades de disco que estivessem integras, aplicar alguns LOG´s, todos felizes Smiley de boca aberta . boa noite e bons sonhos…

Mas não… ai não tem graça…

Backup? nada… nunca foi feito porque a base era grande e “deixava tudo lento”

HA? Cluster ou Mirror até mesmo log Shipping ??? um sonoro não…

OK… basicamente é um caso perdido… mas vamos ver o que da pra tentar fazer…

Usando um editor Hexadecimal abri o arquivos 03 e fui tentar entender o que ele estava reclamando com o header do arquivo… aí me deparo com isso:

03ndf_hex_erro

Uma beleza… basicamente o arquivo todo esta com problema… mas se eu conseguisse colocar a base pelo menos online talvez o CHECKDB conseguiria excluir a massa de dados com problema e partiriamos dali…

Abri o outro arquivo que o SQL havia conseguido carregar para comprar o conteúdo e era totalmente diferente… Feitas algumas modificações… consegui fazer o SQL mostrar outra mensagem de erro… “The PageAudit property is incorrect”

03ndf_hex_ok

Ta bom… relendo o arquivo o valor para 0x00 – Header Version – deve ser 0x01, o valor para 0x01 – m_type – deve ser entre 0x01 e 0x66, o valor de 0x04 – m_flagbits – não pode ser 0x02, o valor de 0x18 – m_objid – deve ser 0x63 ou superior e assim vai por uma parte…

Mas mesmo com as modificações, não consegui trazer a base online… Smiley triste

Em uma situação onde não existe nenhum backup, nenhum tipo de plano de contingência, não existe outra opção que traga a base de volta, o que sobra é: deixe o cracha na mesa, atualize seu curriculo (exclua esta empresa do CV) e perca a CTPS, dependendo do caso mude de cidade…

Hoje, não se justifica este tipo de descaso, o negócio depende de informação, de continuidade. Unidades de backup não são mais tão caras, podemos montar um ambiente razoavelmente barato com mirror, por exemplo, a baixo custo, existem opções. As pessoas só percebem o quanto a informação é imporante depois que perde.

Anúncios

4 pensamentos sobre “FGID propery is incorrect

  1. Complicado isso viu ! Se a base é muito grande, porque ao menos não divide-a em online e history. Compressao na history e poucos dados na online. Se faz uma politica assim pelo menos o mínimo de dados seria salvo e não só o banco em sua totalidade.

    Lamentável.

  2. “Backup? nada… nunca foi feito porque a base era grande e ‘deixava tudo lento’ hã? Cluster ou Mirror até mesmo log Shipping ??? um sonoro não…”
    Eu quase, quase, quaaase usei esse mesmo discurso com um grande cliente meu outro dia: “deixe o cracha na mesa, atualize seu curriculo (exclua esta empresa do CV) e perca a CTPS” porque eu tava realmente pasmo com o descaso. Eu nem digo de deixar a base chegar até aquele ponto (pode-se não perceber, sei lá, sendo otimista), mas não criar um plano de ação? Deixar o cenário de exceção tornar-se regra? Revoltante.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s