Administração SQL Server, Backups, Banco de Dados, DBA, Disaster e Recovery, Disponibilidade, ORACLE, PostgreSQL

(Enquete encerrada) Onde guardam seus backups?

Ola galera,
Essa enquete ficou ativa entre os dias 01/10/2016 à 04/01/2017, o objetivo era saber como as empresas estão armazenando seus dados, diante o cenário atual de segurança de dados!

Podemos observar que existe sim a preocupação no que se diz respeito a backup, apesar de vermos diversos casos no Estado do Ceará e no Brasil, de empresas que perdem todas (ou quase todas) as informações quando precisaram recuperar de um desastre, mais ai vem a questão: Será que estão sendo feitos testes nesses backups?

Pontos positivos:
62% dos participantes usam estratégias bem seguras em relação a backup (Servidor de Backup, Nuvem, Fita, Rede, Espelho ou Replicado);
– A questão de backup em Nuvem (18%), esta crescendo muito e atualmente é uma das opções mais acessíveis e rápidas de serem utilizadas;

Pontos negativos:
23% dos participantes informaram se seus backups são guardados em HD externo, não digo um ponto negativo, mas creio que devam ter uma segunda opção de backup, por ser tratar de uma mídia que pode dar problemas físicos com facilidade. Atenção galera!!!
14% informaram que fazem backup no próprio computador, isso é extremamente crítico se não feito como deve ser feito. Backup no computador é uma boa prática no que se diz respeito a volta rápida ao estado anterior, quando o problema não é na máquina ou no disco, mas essa estratégia obrigatoriamente deve ser seguida por alguma outra como por exemplo um backup em nuvem! Atenção galera!!!

Agradeço a todos pela atenção e espero ter ajudado com essa pesquisa, que no meu ponto de vista, levou a questão:

Seus backups são testados periodicamente?
Deixem seus comentários!

 

DBA, Disaster e Recovery, SQL Server - Replicação

Será que você precisa de Alta Disponibilidade nos seus ambientes?

Todos os direitos reservados a Fabio Cotrim (Especialista em Banco de Dados MS SQL Server)
Matéria original

Introdução

Nesta apresentação, pretendo levantar algumas questões para ajudar aos DBAs avaliarem as reais necessidades de implementar a alta disponibilidade nos ambientes que administram.

Como toda nova funcionalidade de uma ferramenta, vários profissionais, técnicos ou gerenciais, querem implantá-las, mais por ser moda do que por ter real necessidade, e não está sendo diferente com os recursos de alta-disponibilidade criados para os ambientes de bancos de dados, mas, nem sempre, eles serão úteis para a maioria dos ambientes, pois poderão ser complicadores para a administração e, em alguns casos, para a recuperação após um desastre.

Aconselho que analisem a situação de uma forma menos emocional, deixando um pouco de lado a vontade de ser um vanguardista.

Quando questionados, a maioria dos usuários dos ambientes, respondem que seus ambientes são totalmente indispensáveis para o funcionamento da empresa, o que, em muitos casos não é verdade.

Um exemplo simples, é desabilitar a calculadora de troco do caixa de uma padaria; o funcionário  vai afirmar que não consegue executar as suas tarefas, mesmo que ele tenha uma caneta e papel à disposição; esta ação seria um dificultador, mas não causaria um impedimento à realização das tarefas. Ok, você vai dizer que fui cruelmente exagerado neste exemplo, mas pode ficar tranquilo que não sou tão maléfico assim, foi só uma forma de exemplificar a situação.

Em um outro exemplo, este sendo de uma forma que a indisponibilidade de um recurso causaria a parada nas operações e, consequentemente, eliminaria as receitas de uma empresa, seria retirar todas as ferramentas de um mecânico; neste caso, ele não poderia realizar nenhum trabalho até que as ferramentas fossem disponibilizadas novamente.

Em TI, o que é Alta Disponibilidade?

São ambientes que têm a capacidade de tolerar falhas, de tal forma que, o processamento continue com pouca ou nenhuma interrupção, de forma transparente ao usuário, permitindo que a equipe de infraestrutura tenha tempo, e consequente serenidade, para realizar os reparos necessários.

Para quem a Alta Disponibilidade é mais útil?

Quem realmente precisa de Alta Disponibilidade, são os serviços que nunca podem ficar parados, como os serviços essenciais, ou empresas que oferecem seus produtos e serviços aos clientes em período 24×7, tais como:

  • Hospitais;
  • Polícia;
  • Bombeiros;
  • Energia Elétrica;
  • Aeroportos;
  • Serviços de Água e Esgoto;
  • Companhia de Engenharia de Trânsito;
  • Instituições Financeiras;
  • Indústrias 24×7;
  • E-commerce, etc.

Continuar lendo

Base Corrompida, Consultoria em banco de dados, Disaster e Recovery, Disponibilidade

Acordo de Nível de Serviço (SLA)

Um passo importantíssimo para entregar o valor esperado pelos clientes com os serviços de TI é garantir que exista um acordo de nível de serviço, planejado por todas as áreas de TI bem como com o cliente final. Logicamente não basta existir um SLA (Service Level Agreements), ele deve ser cumprido, mas o fato de existir algum SLA já é o primeiro passo, por que significa que o mesmo foi discutido dentro da área de TI bem como com o cliente.

O SLA é útil para garantir que os serviços entregues atendem às expectativas de negócios, as metas de desempenho e os custos necessários para a entrega de um determinado serviço de TIC a um conjunto de clientes. Um SLA eficaz reflete a comunicação entre os clientes e usuários (os consumidores do serviço) e deverá traduzir-se na tabela de indicadores. Os objetivos de nível de serviço que são identificados, em seguida, serão usados para desenvolver e personalizar o scorecard de aderência para o serviço.

O SLA deve ser balanceado entre ser relevante e factível. Em geral, a disponibilidade desejada por todos é de 100%, mas isso, infelizmente, é irreal. O SLA deve conter um objetivo relevante a ponto de atingir o nível de serviço realmente necessário e exigido pelo negócio, mas também deve ser possível de ser entregue, não pode conter premissas ou promessas irreais.

Um SLA deve possuir a descrição e definição, em linguagem clara para o cliente, de todos os pontos importantes sobre o serviço de TIC. Por exemplo, descrição do serviço, seus requerimentos, necessidades de dados de entrada, saídas esperadas, horários de funcionamento do serviço, tempos de atendimento ao usuário em caso de problema, disponibilidade total esperada, tempo de retorno em caso de indisponibilidade, etc.

Cálculo de Disponibilidade

Um dos pontos mais comuns de ser descrito em um SLA é a disponibilidade esperada do serviço. Um indicador comum usado para medir a disponibilidade é o percentual de tempo que um serviço foi capaz de servir aos seus clientes e usuários.

  • Percentagem de disponibilidade = Tempo Total em Serviço / Tempo Total Esperado em Serviço

No caso de um serviço que é esperado que funcione 24 x 7, o tempo total esperado, no ano, é de 24 horas x 365 dias = 8760 horas.

Em geral, a disponibilidade desejada por todos é 100%, mas isso, infelizmente, é irreal. Num caso mais realista, a disponibilidade nos SLAs é medida em “noves”, ou seja, quantos “noves” no percentual são esperados. Um serviço que é esperado “3 noves” deve ter disponibilidade de 99,9%.

A tabela abaixo mostra os cálculos de disponibilidade em relação a um serviço 24×7, com base anual.

% Disponibilidade Horas Totais no Ano (24×7) Tempo máximo de indisponibilidade Horas Totais no Ano (8×5) Tempo máximo de indisponibilidade
90% 8760 horas 876 horas (36,5 dias) 2086 horas 208.6 horas (26 dias)
95% 8760 horas 438 horas (18,3 dias) 2086 horas 104 horas (13 dias)
99% (2 noves) 8760 horas 87 horas (3,6 dias) 2086 horas 20,86 horas (2,6 dias)
99,9% (3 noves) 8760 horas 8,76 horas 2086 horas 2 horas
99,99% (4 noves) 8760 horas 52,56 minutos 2086 horas 12,5 minutos
99,999% (5 noves) 8760 horas 5,3 minutos 2086 horas 1,25 minutos

Como pode ser reparado na tabela de tempos de indisponibilidade, o tempo máximo aceitável de indisponibilidade é alterado com a alteração do tempo total esperado de serviço (janela de funcionamento do serviço). No caso de um serviço em horário comercial (8×5), uma queda do sistema durante a madrugada, com o serviço voltando a funcionar antes ainda do horário comercial não afeta o cálculo de disponibilidade para efeitos do SLA, por que o serviço não tinha a obrigação de funcionar fora da sua janela estipulada.

O que deve ser considerado para confecção de um SLA?

A Microsoft recomenda considerar os seguintes pontos quando da criação e manutenção de SLAs e medições de disponibilidade:

  • Necessidades reais de negócio – Os custos de alcançar maior disponibilidade podem não valer a pena considerando os benefícios reais necessários. Analise a real disponibilidade de serviço de TIC que sua empresa realmente precisa antes de definir metas. Ter sempre meta de 24×7 com 99,999% de disponibilidade pode ser desejável para todos os serviços, mas obriga um enorme investimento em pessoas, processos e tecnologia a fim de atingir esse nível e poucos serviços realmente precisam disso.
  • Correta granularidade – Um sistema de TI, seja qual for, tem múltiplas medições e monitorações de disponibilidade, e não simplesmente funcionando e parado. Partes distintas podem estar funcionando enquanto outras podem ter algum problema de disponibilidade. Uma regra simples, clara e justa deve ser alcançada para que o cálculo não seja mais custoso que a informação resultante deste.
  • Responsabilidade e Cobrança – uma pessoa ou time deve ser responsável por cada medição, e deve ser garantido poder de decisão necessário para que seja feito o que é necessário para controlar o serviço e respeitar os SLAs.
  • Riscos Ordinários e Extraordinários – Falha de disco ou memória, bem como rede e falta de energia são riscos ordinários, previsíveis, que são parte do cotidiano. Você sabe que os enfrentará mais cedo ou mais tarde e deve se planejar para quando isso ocorrer. A maior probabilidade de indisponibilidade pode ser tratada analisando e previnindo riscos ordinários.
    O tipo de planejamento a ser feito para riscos extraordinários é bem diferente e deve inclusive levar em conta risco de perda de pessoal e instalações. São eventos mais raros e especiais, mas que devem ser avaliados se vale a pena prevení-los ou apenas conhecê-los e preparar reação em caso de ocorrência. Isso vai depender do custo da prevenção e também da quantidade e importância dos recursos envolvidos pelo risco.
  • Escopo e tolerâncias – métricas rígidas e absolutas podem trazer mais malefícios do que benefícios. Atritos entre áreas, avaliações e auditorias no cálculo do SLA e outros fatores podem ser resultados de intolerâncias. Em geral, recomenda-se trabalhar com médias e desvio padrão para cálculos de indicadores de SLA.
  • Mensurabilidade – cada item do SLA deve ter um indicador e meta determinada. O SLA deve ser oficializado em cima de valores trangíveis e objetivos, nunca sobre avaliações pessoais e subjetividade. Termos como “melhor”, “mais disponível”, “total”, etc. devem ser evitados, dando-se preferência para “10% de melhoria a cada ano”, ou ainda, “99% de disponibilidade claculada sobre a fórumula XXX =YYY / ZZZ”.
  • Margens de Erro – um outro aspecto da capacidade de medir algo é a margem de erro de medição. Por exemplo, a Microsoft possui dezenas de Active Directory Domain Controllers e Exchange Servers espalhados pelo mundo em diversos datacenters. Sincronização de horário entre todos os serviodres pode levar um certo tempo e ainda assim acontecer com pequenas diferenças de horário. Uma mensagem de ping pode ter o seu horário de chegada, visto por um servidor, milisegundos antes do seu horário de saída. Sabemos que isso é impossível, logo deve-se ao fato de sincronização e outros detalhes inerentes a distribuição e às margens de erro de medição. As objetivos de nível de serviço não devem ser tão pequenos e precisos que sejam da mesma ordem de grandeza que a margem de erro de medição.

Reunião de Revisão de Nível de Serviço

Conduzir uma reunião regular de Revisão de Nível de Serviço é uma forma importante de entender o estado atual do serviço. A revisão frequente dos dados atingidos mantém o foco de trabalho nos mais importantes indicadores de negócio, bem como pode alertar com boa antecedência para eventuais desvios aos objetivos dos SLAs.

Após a documentação e formalização do serviço do SAJ com mapa de serviço, SLAs, OLAs, e a tecnologia totalmente revisada e corretamente configurada, a manutenção dos níveis de serviço requerem criação de:

  • Procedimentos operacionais para todos os componentes do serviço, a fim de garantir que todas as engrenagens estão funcionando corretamente, e de suporte, a fim de garantir que o atendimento ao usuário está sendo feito conforme o acordado no SLA;
  • Disciplina e comprometimento do time a fim de colocarem em prática uma reunião de Revisão de Nível de Serviço com frequência mínima quinzenal.

Fonte: Ronaldo Smith Jr

Backups, Banco de Dados, Base Corrompida, Consultoria em banco de dados, Disaster e Recovery, Importantes

Perda de dados custa às empresas brasileiras US$ 26 bilhões em 12 meses

L&A Soluções – Consultoria em Banco de Dados SQL Server ( Suas informações em boas mãos! )

Companhias tiveram 17 horas de tempo de inatividade inesperado no período, o que acarretou consequências perda de receita e atrasos no desenvolvimento de produtos

A perda de dados e tempo de inatividade custou aproximadamente US$ 26 bilhões às empresas brasileiras no último ano. Mundialmente, o montante foi de US$ 1,7 trilhão. É o que apontou um estudo encomendado pela EMC, que indica que 62% dos profissionais de TI do Brasil não confiam integralmente em sua capacidade de recuperar informações após um incidente.

Além disso, 61% das organizações não têm plano de recuperação de desastres para cargas de trabalho emergentes; e apenas 4% têm planos para big data, nuvem híbrida e dispositivos móveis. De acordo com o levantamento, “nenhuma das organizações do Brasil são ‘Líderes’ em proteção de dados; 9% são ‘Adotantes’; 91% estão desatualizadas”, informa a fabricante.

Apesar de o número de incidentes estar em queda, o volume de dados perdidos por incidente cresce exponencialmente. De acordo com o estudo, 59% das empresas pesquisadas passaram por perda de dados ou tempo de inatividade nos últimos 12 meses.

Na média, as empresas tiveram 17 horas (mais de dois dias de trabalho) de tempo de inatividade inesperado no período, o que acarretou consequências perda de receita e atrasos no desenvolvimento de produtos.

Segundo a pesquisa, empresas com três ou mais fornecedores perderam quase cinco vezes mais dados em comparação com as que têm estratégia de um só fornecedor.

“As empresas com três fornecedores também tenderam a gastar, em média, US$ 15 milhões a mais na infraestrutura de proteção de dados, em comparação com as que têm apenas um”, informa o relatório.

O EMC Global Data Protection Index, realizado pela Vanson Bourne, pesquisou 3,3 mil responsáveis por decisões de TI de médias a grandes empresas em 24 países entre agosto e setembro de 2014.

Fonte: Site Computerworld

Backups, Consultoria em banco de dados, Disaster e Recovery, Restore

Lendo Informações do Backup – SQL Server

OnlyWhatMatters

Neste artigo irei mostrar alguns comandos T-SQL, que estão disponíveis do SQL Server 2005, que retornam informações úteis dos backups realizado, tais como: arquivos de data e log que estão no backup, horário de inicio e término do backup, integridade do backup realizado, etc.

Os comandos T-SQL são:

RESTORE FILELISTONLY
RESTORE LABELONLY
RESTORE HEADERONLY
RESTORE VERIFYONLY

Obs.: estes comandos apenas extraem as informações que estão no backup, isso sem a necessidade de restaura-lós.

Para saber mais detalhes de cada informação retornada nestes comandos, clique no título do comando.

RESTORE FILELISTONLY

Este comando retorna informações sobre os arquivos de dados (mdf e ndf) e log (ldf) armazenados em um dispositivo.

Por exemplo, neste comando ele retorna algumas informações importantes como:
– LogicalName: nome lógico do arquivo no SQL Server;
– PhysicalName: caminho e nome do arquivo;
– Type: o tipo do arquivo, ex: se o Type for “D”, trata-se de um…

Ver o post original 201 mais palavras

Backups, Consultoria em banco de dados, Disaster e Recovery, Restore

Recoverying Model Database

Freccia's Blog

Recentemente tive algumas discussões a respeito de como proceder em caso a base de dados Model seja corrompida. A primeira coisa que escutei foi:

Nunca tivemos a base de dados model corrompida! É tão pequena que não teriamos problema

Bom, ai é que surge o problema! Se estamos pensando em um verdadeiro cenário de Disaster Recovery, nada pode passar despercebido por nós, nem mesmo aquela pequena base chamada de model. Se você quer saber um pouco mais sobre a mesma, indico a leitura do link abaixo.

https://msdn.microsoft.com/en-us/library/ms186388.aspx

Ver o post original 740 mais palavras

Consultoria em banco de dados, Disaster e Recovery, Integration Services (SSIS)

Restore Database com SSIS – Parte 02

Use [SQL Server] GO!!

Oie Gente!

Dando continuação ao post anterior o próximo passo é criarmos um “Execute Process Task”.  Para alterarmos o nome do arquivo no “.txt” criado no WINSCP, utilizaremos um pouco de powershell.

A necessidade da adição desse passo é porque precisamos recuperar o nome do arquivo exato que o FTP irá copiar para o diretório S:RESTORERESTORE_DATABASE.

A primeira coisa a fazer é pegar um o “Execute Process Task” e arrastarmos para o Control Flow, conforme imagem abaixo:

1

Antes de modificarmos o “Execute Process Task”, vamos criar o script para modificarmos o arquivo de texto. A lógica é simples:

  1. Vamos abrir o diretório onde encontra-se o “.txt”;
  2. Procurar a palavra COLOCARDATAAQUI;
  3. Substituir ela por uma data (A data especificada nesse caso é a data que o backup full foi criado);
  4. Salvar o arquivo;

Abra o Windows PowerShell ISE (http://technet.microsoft.com/en-us/library/dd819514.aspx), conforme a imagem abaixo:

2

O script para modificar o arquivo de texto…

Ver o post original 106 mais palavras

Consultoria em banco de dados, Disaster e Recovery, Integration Services (SSIS)

Restore Database com SSIS – Parte 01

Use [SQL Server] GO!!

Olá Pessoal!

Demorou mas.. “I’m here..”… \o/..

O post de hoje será sobre uma das tarefas fundamentais de um administrador de banco de dados (DBA) que é garantir que os dados possam ser recuperados no caso de um desastre.  No nosso dia a dia, adquirimos várias coisas que possam nos deixar tranquilos com nossos bens como por exemplo, uma apólice de seguro para carro ou para sua casa. Apesar de caro e rezarmos para nunca usarmos é uma maneira que escolhemos para nos assegurar contra qualquer “imprevisto”.  Enfim, voltando para o nosso assunto, os backups são as apólices de seguro contra qualquer eventualidade na empresa em que trabalhamos. O backup será o responsável por recuperarmos os dados que foram perdidos e no final das contas o negócio voltar a fazer as suas operações empresariais rotineiras. Costumo dizer que ele é o responsável pelo “final feliz” de qualquer situação.. (rsrs).

Muitas…

Ver o post original 350 mais palavras

Disaster e Recovery

Como recuperar um banco de dados apagado acidentalmente sem ter o backup

SQL DBA Insights

Você acaba de apagar um banco de dados acidentalmente em uma instância do SQL Server. Para muitos DBAs o banco está perdido para sempre, a menos que você possua um backup.

Este é o conhecimento comum de muitos DBAs que trabalham com o Microsoft SQL Server, porém, não é completamente verdadeira.

No entanto este caso é como um paciente em um hospital que teve uma parada cardíaca. Quanto mais demorar pra tomar os procedimentos de recuperação dos arquivos, com mais sequelas estes podem ficar, ou até mesmo se tornar o procedimento irreversível. Em suma, não há garantias de que o procedimento funcionará e nem de que o banco será 100% recuperado, em muitos casos recuperar alguma parte do que foi perdido pode ser muito melhor do que não se recuperar nada.

Neste artigo iremos utilizar algumas ferramentas gratuitas como o FreeUndelete da OfficeRecovery.com

FreeUndelete – File Undelete Software – http://www.officerecovery.com/

Ver o post original 2.815 mais palavras

Backups, Base Corrompida, Consistência de dados, Consultoria em banco de dados, Disaster e Recovery, Restore

Banco de dados corrompido (Análise)

Esta é uma área que gosto muito, apesar que não gostaria de passar por uma situação desta em produção… hehehe

Encontrei este Post no Blog do Erickson Ricci, segue abaixo conforme o autor escreveu (todo o mérito do matérial é do autor, que esta de parabens pelo excelente material)
Neste post farei a análise de um banco de dados corrompido. O banco de dados corrompido que irei utilizar foi disponibilizado num grupo de estudos para a certificação MCM no qual estou participando. O grupo foi iniciado pelo MVP Jason Strate ( blog | @StrateSQL ) e quem quiser mais informações pode acessar este post dele: http://www.jasonstrate.com/2011/12/sql-mcm-study-group/.

Vocês poderão baixar o banco de dados corrompido aqui.

Vamos começar a análise então. Antes de mais nada, precisamos deixar nosso banco de dados disponível em nossa instância. A maneira mais simples de fazer isto é anexar (attach) a base, seja pela interface gráfica ou via comando, desta forma:

CREATE DATABASE [CorruptDB1] ON
( FILENAME = N'C:\temp\CorruptDBs\CorruptDB1\DBFiles\CorruptDB1.mdf' ),
( FILENAME = N'C:\temp\CorruptDBs\CorruptDB1\DBFiles\CorruptDB1_log.ldf' )
FOR ATTACH;
GO

Substitua o caminho “C:\temp\CorruptDBs\…” para o local onde você escolher descompactar os arquivos.

Uma vez que o banco de dados estiver anexado, vamos rodar um DBCC CHECKDB para ver qual o estado do nosso banco.

DBCC CHECKDB(CorruptDB1)
WITH ALL_ERRORMSGS, NO_INFOMSGS

Utilizei as opções ALL_ERRORMSGS e NO_INFOMSGS para exibir como resultado somente mensagens de erro e ignorar mensagens informativas. Se desejar mais informações sobre o comando DBCC CHECKDB, clique aqui. O resultado que temos é o seguinte:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data),
page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -4.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

Há algo errado com nosso banco de dados. E agora, que ação devemos tomar?

O comando CHECKDB possui duas opções chamadas REPAIR_ALLOW_DATA_LOSS e REPAIR_REBUILD. A primeira impressão é “…ótimo, o DBCC CHECKDB vai resolver meu problema de corrupção!”.

A primeira opção “tenta” reparar o problema de corrupção e pode ocasionar perda de dados. Já a segunda opção “tenta” executar reparos que não possibilitem perda de dados. Como não queremos perder nenhum dado da base, vamos executar a segunda opção primeiro. Vou alterar o acesso do banco de dados para SINGLE_USER e vou executar estas opções.

ALTER DATABASE CorruptDB1 SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

DBCC CHECKDB(CorruptDB1, REPAIR_REBUILD)
WITH ALL_ERRORMSGS, NO_INFOMSGS

E temos o seguinte resultado:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
The repair level on the DBCC statement caused this repair to be bypassed.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

Hummm… Nada resolvido. Ainda tivemos o erro 8939. Vamos forçar a barra e tentar o reparo com possível perda de dados.

DBCC CHECKDB(CorruptDB1, REPAIR_ALLOW_DATA_LOSS)
WITH ALL_ERRORMSGS, NO_INFOMSGS

E o resultado:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
The repair level on the DBCC statement caused this repair to be bypassed.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

Novamente, nada feito. Pelo nível de corrupção do banco de dados, o comando DBCC CHECKDB não consegue reparar este problema. Vamos ter que fazer uma análise um pouco mais profunda e por a mão na massa para resolver o problema.

Nós vamos encontrar a explicação deste erro aqui. Em linhas gerais, ele nos informa que foi realizada uma validação numa determinada página, e esta validação falhou por uma corrupção no cabeçalho (Header) da página. Interessante não?!

Analisando a mensagem completa de erro que nos foi dada, podemos observar que ela nos informa qual é a página que está com problema: “…page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. …”. Fica a dica: LEIA TODA A MENSAGEM DE ERRO!!! Achei que isto deveria ficar em destaque pois é muito comum ver as pessoas sem saber o que fazer e a mensagem de erro te dá dicas valiosas sobre o que aconteceu. Nem sempre é assim, mas na maioria das vezes é válido. Vamos dar uma olhada nesta página:

DBCC TRACEON(3604)
GO
DBCC PAGE('CorruptDB1', 1, 7, 3)

Quer saber mais sobre o Trace Flag 3604 e sobre o comando DBCC PAGE, acesse aqui e aqui.
O resultado completo que temos é o seguinte:

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.PAGE: (1:7)BUFFER:BUF @0x000000008EFA8F40bpage = 0x000000008E17E000           bhash = 0×0000000000000000           bpageno = (1:7)
bdbid = 17                           breferences = 0                      bcputicks = 0
bsampleCount = 0                     bUse1 = 50557                        bstat = 0xc00809
blog = 0×21212159                    bnext = 0×0000000000000000PAGE HEADER:Page @0x000000008E17E000m_pageId = (1:7)                     m_headerVersion = 0                  m_type = 0
m_typeFlagBits = 0×0                 m_level = 0                          m_flagBits = 0×200
m_objId (AllocUnitId.idObj) = 99     m_indexId (AllocUnitId.idInd) = 0    Metadata: AllocUnitId = 6488064
Metadata: PartitionId = 0            Metadata: IndexId = 0                Metadata: ObjectId = 99
m_prevPage = (0:0)                   m_nextPage = (0:0)                   pminlen = 90
m_slotCnt = 2                        m_freeCnt = 6                        m_freeData = 8182
m_reservedCnt = 0                    m_lsn = (0:0:1)                      m_xactReserved = 0
m_xdesId = (0:0)                     m_ghostRecCnt = 0                    m_tornBits = 105713478Allocation StatusGAM (1:2) = ALLOCATED                SGAM (1:3) = NOT ALLOCATED           PFS (1:1) = 0×44 ALLOCATED 100_PCT_FULL
DIFF (1:6) = CHANGED                 ML (1:7) = NOT MIN_LOGGED
Msg 2514, Level 16, State 5, Line 1
A DBCC PAGE error has occurred: Invalid page type – dump style 3 not possible.

Obviamente houve erros no resultado. Mas o que chama a atenção são os pontos que destaquei em negrito. Se dermos uma olhada no Internals (um modo “carinhoso” de chamar o livro Microsoft SQL Server 2008 Internals), veremos no capítulo 3, página 147, parágrafo 2 ( :-O Não, eu não decorei isto, fui ver no livro… ^.^ ) as explicações sobre as páginas de alocação de dados, em resumo, assim:

  • Page 0 – File Header
  • Page 1 – PFS Page Free Space
  • Page 2 – GAM Global Allocation Map
  • Page 3 – SGAM Shared Global Allocation Map
  • Page 4 e Page 5 – não são utilizadas
  • Page 6 – DCM Differential Changed Map
  • Page 7 – BCM Bulk Changed Map

Isto nos leva à conclusão de que a página que temos corrompida neste banco de dados é a página BCM, Bulk Changed Map. Não vou entrar neste momento no detalhe das páginas de controle, ficando apenas por dizer que é uma das páginas de controle de alocação de dados do SQL Server.

Ótimo! Agora sabemos o que fazer. Podemos então fazer o restore desta página e tudo resolvido. Será?!
Vamos tentar.

USE MASTER;
GO

RESTORE DATABASE CorruptDB1
   PAGE = '1:7'
FROM DISK = 'C:\temp\CorruptDBs\CorruptDB1\Bak\CorruptDB1.bak'
WITH RECOVERY

Vamos utilizar o comando RESTORE para restaurar somente a nossa página corompida. O resultado que temos é:

Msg 3111, Level 16, State 1, Line 2
Page (1:7) is a control page which cannot be restored in isolation. To repair this page, the entire file must be restored.
Msg 3013, Level 16, State 1, Line 2
RESTORE DATABASE is terminating abnormally.

Ops! O SQL Server não nos permite restaurar isoladamente páginas de controle… E nos informa que para resolução do problema temos de restaurar o arquivo completo.

Solução para o problema e evitar perda de dados. Faça um backup de log (Tail Log Backups) e aplica um restore do banco de dados e depois aplique os logs na sequência, se houver, e por último aplique o último backup de log gerado (tail log). Depois de seguir estes passos, execute novamente o comando DBCC CHECKDB para ter certeza de que seu problema foi resolvido.

Esta foi a solução que encontrei para este problema de corrupção.


Veja também:

Integridade do Banco de Dados

Possible Index Corruption. Diagnosticando o problema

Corruption demo databases and scripts

Corrigindo Erro de Suspect Database (novo)

Corrompendo um Banco SQL (novo)

Corrupção de Dados direto das trincheiras (novo)

Ver páginas corrompidas (SQL Server)

Verificação de Página e Restore de Bases no SQL Server

Recriando as databases de sistema

Automatizando a verificação de integridade de seus bancos de dados

Como Restaurar o Master, Model e MSDB

Entendendo e Melhorando seus backups (SQL Server)

Restaurando um Database Suspect – SQL Server

Databases em modo Suspect e Pendente Recovery

Creating, detaching, re-attaching, and fixing a SUSPECT database