|
Getting your Trinity Audio player ready...
|
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…
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 
. 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:
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”
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… 
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.
[youtube=http://www.youtube.com/watch?v=6D9vAItORgE]
Concordo é imperdoável não haver backup, ainda se houver qualquer forma de,redundância deve existir um backup. Abraço.
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.
É…
Acho que a partir de agora ele vai ter pelo menos uns 3 backups…
“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.