Corrompendo seu banco de dados no SQL Server

Luciano Caixeta Moreira — Fri, 20 Feb 2009 05:23:00 GMT

Hoje de manhã eu recebi uma pergunta de um amigo que queria saber como corromper um banco de dados, para fazer alguns testes. O mecanismo que ele estava utilizando não era efetivo, então eu mencionei que ele poderia usar um editor hexadecimal para fazer o trabalho, mas como não temos muitas referências em português, resolvi gastar alguns minutinhos para machucar um banco de dados. Vamos?

Criando o banco de dados

Execute o script abaixo para criarmos um coitado que será corrompido…

USE master
go

-- drop database BDProblema

CREATE DATABASE BDProblema
go

USE BDProblema
go

ALTER DATABASE BDProblema
SET PAGE_VERIFY NONE
go

CREATE TABLE Dados (
IdDado INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
Nome VARCHAR(200) NOT NULL)
go

INSERT INTO Dados VALUES ('Luciano Caixeta Moreira')
go

Note que eu configurei o banco de dados para não trabalhar com nenhum modelo de verificação de página, pois quero mostrar para vocês uma edição do arquivo sem recebermos nenhuma mensagem de erro.

Analisando a tabela criada com DBCC PAGE

Agora vamos dar uma olhada na estrutura da página. Primeiro descobrimos onde ela está e depois usando o DBCC PAGE para vermos sua estrutura.

SELECT *
FROM sys.sysindexes as s
where s.id = OBJECT_ID('Dados')
/*
    First: 0x900000000100
    Arquivo = 1
    Página = 144 (0x90)
*/

DBCC TRACEON(3604)
DBCC PAGE (BDProblema, 1, 144, 2)

/*
Vamos guardar o início da página, pois é o que importa!

Memory Dump @0x5C19C000

5C19C000:   01010400 00c00001 00000000 00000800 †.....À..........
5C19C010:   00000000 00000100 1b000000 781f8600 †............x..
5C19C020:   90000000 01000000 14000000 40000000 †............@...
5C19C030:   13000000 00000000 00000000 00000000 †................
5C19C040:   01000000 00000000 00000000 00000000 †................
5C19C050:   00000000 00000000 00000000 00000000 †................
5C19C060:   30000800 01000000 02000001 0026004c †0............&.L
5C19C070:   75636961 6e6f2043 61697865 7461204d †uciano Caixeta M
5C19C080:   6f726569 72610000 21212121 21212121 †oreira..!!!!!!!!

Agora vamos executar uma pequena alteração para identificarmos se o 0x4c em negrito é realmente o “L” do meu nome.

UPDATE Dados
SET Nome = 'Muciano Caixeta Moreira'

DBCC TRACEON(3604)
DBCC PAGE (BDProblema, 1, 144, 2)

5C19C000:   01010400 00c00001 00000000 00000800 †.....À..........
5C19C010:   00000000 00000100 1b000000 781f8600 †............x..
5C19C020:   90000000 01000000 14000000 5b000000 †............[...
5C19C030:   02000000 00000000 00000000 00000000 †................
5C19C040:   01000000 00000000 00000000 00000000 †................
5C19C050:   00000000 00000000 00000000 00000000 †................
5C19C060:   30000800 01000000 02000001 0026004d †0............&.M
5C19C070:   75636961 6e6f2043 61697865 7461204d †uciano Caixeta M
5C19C080:   6f726569 72610000 21212121 21212121 †oreira..!!!!!!!!

Aqui vemos que o caractere na posição 0x5C19C06F alterou de 0x4c (L) para 0x4d (M).
Como estamos na página 144, sabemos que o offset dessa página no arquivo em bytes é: 144 * 8192 = 1179648 (em hexadecimal –> 0x120000). Vamos para o editor hexadecimal?

Editando o arquivo BDProblema.mdf

Pare a instância do SQL Server em questão e utilizando o editor hexadecimal de sua preferência (baixei o Free Hex Editor Neo da HDD Software) abra o arquivo BDProblema.mdf.

Navegue até o offset 120000 e a partir daí vá até a posição 6F e encontre o caractere 4d, alterando-o para 4c.

(Antes)

(Depois)

Agora salve o arquivo, feche o editor, reinicie a instância do SQL Server e execute um SELECT na tabela Dados. Qual será o resultado??? O “Muciano” voltou a ser “Luciano”. Até aqui não vemos nenhum erro, pois o SQL Server não estava com nenhuma verificação específica para o banco de dados, o que está para mudar…

Habilitando o page checksum e corrompendo o banco

Primeiramente, execute o script abaixo:

ALTER DATABASE BDProblema
SET PAGE_VERIFY CHECKSUM
go

UPDATE Dados
SET Nome = 'Muciano Caixeta Moreira'
go

DBCC CHECKDB()
GO

DBCC results for 'Dados'.
There are 1 rows in 1 pages for object "Dados".
CHECKDB found 0 allocation errors and 0 consistency errors in database 'BDProblema'.

Como resultado, teremos um banco de dados com CHECKSUM habilitado e a página com seu checksum calculado, pois foi executado um update na tabela. O CHECKDB vai executar com sucesso e nenhum erro será reportado.

Repita do procedimento listado no tópico “Editando o arquivo BDProblema.mdf”, onde você vai alterar o nome “Muciano” para “Luciano” através do editor hexadecimal. Reinicie o serviço do SQL Server e tente executar a consulta abaixo:

SELECT *
FROM Dados
/*
IdDado Nome
----------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xd73d977b; actual: 0xd73d97fb). It occurred during a read of page (1:144) in database ID 7 at offset 0x00000000120000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\BDProblema.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.
*/

Se tentar executar um CHECKDB, vai ver algo parecido com:

DBCC results for 'Dados'.
Msg 8928, Level 16, State 1, Line 1
Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039697408 (type In-row data): Page (1:144) could not be processed. See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039697408 (type In-row data), page (1:144). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -4.
There are 0 rows in 0 pages for object "Dados".
CHECKDB found 0 allocation errors and 2 consistency errors in table 'Dados' (object ID 2105058535).
CHECKDB found 0 allocation errors and 2 consistency errors in database 'BDProblema'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (BDProblema).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Pronto! Você está com o seu banco de dados corrompido.
Como é um problema na página de dados, não podemos fazer um rebuild de um índice (método utilizado quando um índice não-cluster está corrompido) e temos que partir para outros métodos de disaster recovery, como recuperar um backup.

Espero que você tenha gostado e te ajudado a entender como pode simular falhas no seu banco de dados, para testar seu planejamento de disaster recovery, antes que seu ambiente de produção não esteja ok e você não sabia o que fazer. Além disso, claro, veja como é importante manter o checksum habilitado!

Até a próxima!

[]s
Luciano Caixeta Moreira
luciano.moreira@microsoft.com
===============================================
This post is provided "AS IS" and confers no right
===============================================

SQL Server Screencast #1 – DBCC PAGE

Luciano Caixeta Moreira — Wed, 21 Jan 2009 21:05:15 GMT

Oi pessoal.

Eu estou sempre procurando novas maneiras de estar em contato com vocês, para tentar mostrar um conteúdo interessante e de maneira eficiente. Com esse intuito, hoje gravei um screencast sobre como utilizar o comando DBCC PAGE. Nesse primeiro episódio eu usei um tema simples para testar as ferramentas de gravação, produção e distribuição do vídeo.

Para dizer a verdade, sou um zero a esquerda quando o assunto é edição de vídeos, então acredito que ainda vai levar um tempinho para descobrir a melhor relação custo/benefício entre tamanho e qualidade do que foi gravado, mas com o tempo eu chego lá.

Se você quiser fazer o download do vídeo, pode baixar o arquivo do meu skydrive:

http://cid-e145f7753042d628.skydrive.live.com/self.aspx/Public/Screencast/SQLSC%7C_001%20-%20DBCC%20PAGE.zip

Se você quiser assistir o vídeo online através do soapbox do MSN, aqui está o bendito:

(http://video.msn.com/video.aspx?vid=9432b1b7-b39e-489c-94cc-bea1e7e43ee4")

Ainda estou vendo outros modelos de distribuição, como youTube e MSDN Media Center, além de fazer encoding para o Silverlight e tentar colocá-lo em um host de streaming.

Para os curiosos, gravei o vídeo utilizado o Camtasia, durante a apresentação estou usando o ZoomIt para conseguir aqueles efeitos grandiosos (!) e agora estou usando o Expression Encoder 2 para gerar o conteúdo otimizado para Silverlight. Chique no último!

Nesse post, mas do que nunca, seu feedback seria MUITO importante.

1) A qualidade (vídeo e áudio) está boa?
2) O tamanho do arquivo ficou bom?
3) O vídeo no soapbox, rodou legal?
4) Gostaram do modelo de screencast?
5) Está afim de falar outra coisa qualquer?

LUTI @ Microsoft : DBCC

Corrompendo seu banco de dados no SQL Server

SQL Server Screencast #1 – DBCC PAGE