DBCC Writepage – Considerado o comando mais perigoso existente no Microsoft SQL Server.

Bom tarde, Comunidade e Amantes do Microsoft SQL Server.

Tudo bem? Espero que todos possam ter passado e aproveitado as festas de final de ano, pois realmente 2014 foi um ano passou de forma avassaladora, com tantos acontecimentos esportivos e políticos.

Mas agora é hora de voltar a luta, começar 2015 com muito trabalho e logicamente pensando sempre como podemos conhecer e aprender cada vez mais com o Microsoft SQL Server, através de seus segredos, mas principalmente com alguns dos principais nomes dentre eles: Paul Randal e Bob Ward, peço licença por citá-lo, pois sou um simples mortal e mero DBA perto destes “monstros”.

Seguindo nesta linha de raciocínio, onde me refiro a aprender, tenho a certeza que a cada dia todos nós temos a capacidade e o dever em buscar novos ensinamentos e desafios, procurando compartilhar as lições, aprendizados e até mesmo os riscos que muitas vezes encontramos. É com base nesses riscos e desafios que eu gostaria de destacar o objetivo deste artigo, apresentar para aqueles que ainda não conhecem o tão temido comando DBCC WritePage. Sendo este destacado por Paul Randal em sua frase: “DBCC WRITEPAGE – the most dangerous command you can use in SQL Server.” extraída de um dos seus diversos artigos e posts.

 

Introdução

Conhecido por ser um dos comandos DBCC não-documentados pela Microsoft o DBCC Writepage é considerado por muitos, dentre eles Paul Randal, um dos principais segredos existente no SQL Server.

Mas qual seria o motivo de tanto segredo? Ou até mesmo preocupação?

Na verdade o DBCC Writepage esta presente no Microsoft SQL Server desde a versão 2000, mas efetivamente mantido em segredo ou até mesmo escondido de muitos da comunidade.

No entendo, o mesmo passou a ser mais procurado e conhecido a partir do momento em que a Microsoft introduziu na versão 2005 a Trace Flag 2588 que apresenta em conjunto com a relação tradicional de comandos DBCCs, aqueles possivelmente considerados não-documentados ou até mesmo não suportados. Por padrão até a versão 2005 era utilizada da Trace Flag 2520 que omitia justamente os comandos não documentados.

Como destacou Paul Randal, durante muitos anos ele procurou evitar escrever e até mesmo falar sobre este comando, inclusive em conversas com Bob Ward um dos Engenheiros do Time do SQL Server ele dizia: “I discussed this issue with the SQL product team and CSS last week, and they agree with me doing this. You won’t see a Microsoft post about this, but my great friend Bob Ward from CSS wanted me to quote him saying “Microsoft does not support the usage of DBCC WRITEPAGE and its use would invalidate the support for a customer database on which it is used.”

Outro fator importante que podemos analisar é a crescente necessidades dos Administradores de Bancos de Dados, Desenvolvedores e Profissionais de Tecnologia possuem em tentar de alguma forma simular situações, cenários de risco e aprender com este tipo de ambiente, algo que fez a curiosidade pelo DBCC Writepage aumentar.

Eu mesmo durante algum tempo venho brincando com os meus alunos em exercícios e trabalhos quando estou me referindo a Cenários de Desastre e Recuperação de Dados no SQL Server.

Mas afinal o que este comando faz?

A resposta para esta pergunta é bem simples:

O DBCC Writepage permite a alteração de qualquer byte, em qualquer página de dados, que em qualquer bando de dados, desde que o usuário possua privilégios sysadmin. Além disso, permite contornar completamente o pool de buffer, em outras palavras, você pode forçar falhas na estrutura de verificação de página conhecido tecnicamente como CheckSum. Levando-se em consideração esta capacidade podemos dizer que o DBCC Writepage pode ser analisado e entendido como um comando extremamente perigoso quando estamos se referindo a um banco de dados.

Comportamento

Por padrão o comando DBCC Writepage possibilidade ao usuário com poderes administrativos alterar todo conjunto de bytes que estão vinculados ou melhor dizendo compondo uma determinada página de dados. Comportamento que possibilidade atribuir a este comando a capacidade de edição em tempo real da estrutura física e lógica de armazenamento de um banco de dados.

 

Considerações e Preocupações

Por se tratar de um dos comandos não – documentados pela Microsoft, o mesmo não deverá ser utilizado em ambientes de produção, os possíveis riscos e perdas de dados que o Writepage pode proporcionar vão muito além da falha no acesso a uma porção de dados, mas sim, a possibilidade de perda por completa de toda estrutura de um banco de dados.

 

O comando DBCC Writepage foi desenvolvido com objetivo de ajudar as equipes de engenheiros a entender e analisar formas de demonstração e testes de corrupção da estrutura de um banco de dados. Possibilitando uma checagem de forma automatizada do comando DBCC CheckDB na validação e reparação de um banco de dados.

 

Desta forma, vale ressaltar que qualquer teste ou simulação deverá ser aplicada em cenários ou ambientes que não representem riscos, como também, após a execução e validação de um procedimento de backup.

 

Portanto não utilize este comando em ambientes de produção!!!

Onde utilizar

Pesquisando mais informações sobre o DBCC Writepage, encontrei vários posts que destacam qualidades e possíveis situações para uso, dizer que existem somente coisas ruins na utilização deste comando, é errado, existem sim possibilidades relacionadas a: Estudos da estrutura de um Banco de Dados, Backups, Recuperação de dados, técnicas que podemos muitas vezes ilustrar e apresentar em palestras, eventos ou grupos de estudos.

 

Sintaxe

Posso dizer que sua sintaxe pode ser totalmente comparável com seu risco, ou seja, o DBCC Writepage apresenta uma sintaxe composta por um conjunto de parâmetros configuráveis que requer a definição para que o mesmo possa ser executado, conforme apresento abaixo:

Dbcc WRITEPAGE ({‘dbname’ | dbid}, fileid, pageid, offset, length, data [, directORbufferpool])

Parâmetros:

1. ‘dbname’ | DBID: Nome do Banco de Dados ou Database ID;
2. FileID: ID que representa o identificador do arquivo que terá sua página alterada;
3. PageId: Número de página;
4. offset: Deslocamento em bytes com base no início da página de dados;
5. length: Número de bytes a serem alterados, entre os valores 1 a 8;
6. data: Os novos dados para inserir (em hex, sob a forma de ‘0xABABCC’); e
7. directORbufferpool: Se o buffer pool deve ser ignorado ou não, de acordo com o valor informando (0/1).

Uma consideração muito importante se relaciona com o parâmetro directORbufferpool, caso o valor informado seja 1, o Microsoft SQL Server mudará completamente o controle e forma de uso do Buffer Pool, realizando:

• Executa pontos de verificação do banco de dados fora das páginas em buffer pool;
• Quebra o vínculo do FCB (File Control Block) existente no arquivo de dados que forma e compõe o banco de dados;
• Cria um novo FCB para o arquivo, totalmente independente do FCB já existente;
• Realiza o direcionamento a leitura de páginas que estão em memória utilizadas naquele momento pelo comando DBCC;
• Modificação direta de páginas;
• Gravação direta de páginas de dados em disco, descartando qualquer proteção da página e CheckSum;
• Ao final realiza novamente a correção dos File Control Block criados durante a execução do Writepage.

Onde o Buffer Pool não consegui identificar o que esta acontecendo, imaginando que possa estar ocorrendo uma possível falha de escrita ou leitura de dados, ou até mesmo a estrutura física tenha sido corrompida.

 

Utilizando o DBCC Writepage

Muito bem, chegamos até aqui e ainda estamos vivos, vamos então brincar um pouco com este recurso fantástico, super perigoso e desafiador!!!

Como de costume nosso cenário será o mais simples possível, para simularmos como o DBCC Writepage pode ser utilizado e principalmente o que ele pode fazer, vou criar um Banco de Dados chamado DatabaseCrazy e executar os demais passos apresentados.

Mãos na massa:

— Passo 1 – Criando o Banco de Dados DatabaseCrazy e a Tabela TB_Crazy –

Create Database DatabaseCrazy

Go

Use DatabaseCrazy

Go

 

Create Table TB_Crazy

(Id Int Identity(1,1) Primary Key,

Title NCHAR (4000) DEFAULT ‘Use the command DBCC Writepage can be crazy’)

Go

 

Insert into TB_Crazy Default Values

Go 10

 

Observe que criamos o nosso banco de dados, em seguida a tabela e inserimos 10 linhas de registro em sua estrutura, consequentemente nossas páginas de dados foram criadas e populadas. Nosso próximo passo será listar toda estrutura de páginas de dados que formam nossa tabela TB_Crazy, para isso, existem diversas possibilidades, mas como estamos falando de comandos não – documentados vamos então utilizar mais um conhecido como DBCC IND, caso queira saber mais sobre este comando acesse: DBCC IND

— Passo 2 – Consultando a estrutura e relação de Páginas de Dados da tabela TB_Crazy —

DBCC IND (N’DatabaseCrazy’, N’TB_Crazy’, -1);

Go

 

Após executarmos o comando DBCC Ind, o SQL Server nos apresentou a relação de páginas de dados que sustentam nossos dados na tabela TB_Crazy, podemos observar a presença de 12 páginas de dados, conforme apresenta a Figura 1, abaixo:

Figura 1 – Relação de páginas de dados tabela TB_Crazy.

 

Loucura, loucura, loucura, como diria aquele apresentador, estamos quase lá, agora é a hora da verdade e ver o que o DBCC Writepage faz, vamos então de mãos dadas, executar o próximo passo que consiste na quebra da estrutura física e lógica da nossa tabela TB_Crazy e na sequência tentarmos fazer acesso a mesma.

— Passo 3 – Executando a quebra na página de dados relacionada com a tabela TB_Crazy —

Para que seja possível fazer uso do DBCC Writepage, temos que alterar a forma de acesso do nosso banco de dados para Single_User, para posteriormente fazer a quebra da página de dados.

Alter Database DatabaseCrazy

Set Single_User

Go

 

DBCC WRITEPAGE (N’DatabaseCrazy’, 1, 299, 1250, 1, 0xAA, 1);

Go

 

Ufa, fizemos a alteração em nosso banco de dados, e executamos o DBCC WritePage, configurando o mesmo para:

• Alterar apágina de dados de número 299;
• No deslocamento de bytes 1250;
• Realizando a mudança de 1 byte;
• Com o valor hexadecimal 0xAA; e mudando o controle do Buffer Pool ao especificar o valor 1 para o parâmetro directOrbufferpool.

Para finalizar vamos consultar nossa tabela TB_Crazy e ver se conseguimos ter acesso aos nossos dados, executando o Select baixo:

Select * from TB_Crazy

Go

 

Meu Deus, este SQL Server é fora do comum, é fantástico, ao executarmos o simples Select, foi possível verificar que conseguimos acessar os registros que não estão vinculados a página de dados 299, conforme apresenta a Figura 2 a seguir:

Figura 2 – Linhas de registros existentes na tabela TB_Crazy que não estão vinculados com a página de dados 299.

 

Em contra partida, o SQL Server nos retorna na guia Messages, uma mensagem de erro, conforme similar a esta:

Msg 824, Level 24, State 2, Line 25

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x015f2e60; actual: 0x415f2e71). It occurred during a read of page (1:299) in database ID 6 at offset 0x00000000256000 in file ‘C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\DatabaseCrazy.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail.

This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB).

This error can be caused by many factors; for more information, see SQL Server Books Online.

 

Palmas para o SQL Server, esse cara é demais!!!

 

Conclusão

Falar sobre um recurso existente no Microsoft SQL Server não é fácil, falar então sobre um recurso não-documentado e tratado como um grande segredo, posso dizer que foi um grande desafio, ainda mais sobre um recurso que Paul Randal, tratou durante anos como seu próprio filho.

Mas como eu destaquei no começo, os desafios estão presentes em nossas vidas a todos os momentos, temos que procurar vencê-los ou em último caso conviver com eles por algum tempo.

Desta forma, procurei apresentar o comando DBCC Writepage, destacando sua história, sua finalidade e objetivos, como podemos e devemos tratar esta funcionalidade que possui um grande poder e muitas vezes de destruição de todo um ambiente. Mesmo sabendo disso, conseguimos fazer uso, simular a quebra da estrutura física e lógica de uma página de dados, conhecer também de forma breve outro comando não – documentado que é o DBCC IND e principalmente ver que mesmo que nossa tabela possua sua estrutura danificada o SQL Server com todo seu poder e Inteligência conseguiu retornar uma parte destes dados.

Afirmar que o DBCC Writepage é perigoso fica fácil, o desafio é tentar encontrar uma forma de uso sem correr riscos.

——————————————————————————————————————————-

Mais uma vez agradeço a sua visita, espero que você tenha gostado e que este conteúdo possa te ajudar.

Um grande abraço.

Nos encontramos em breve.

Até mais.