- Recuperando dados deletados do SQL Server sem Backup Full – Parte 1
- Recuperando dados deletados do SQL Server sem Backup Full – Parte 2
- Recuperando dados deletados do SQL Server sem Backup Full – Parte 3
- Recuperando dados deletados do SQL Server sem Backup Full – Parte 4
- Recuperando dados deletados do SQL Server sem Backup Full – Parte 5
- Recuperando dados deletados do SQL Server sem Backup Full – Parte 6
Nos últimos dois posts desta série eu mostrei uma situação onde você deletou “sem querer” 10 mil registros de uma tabela e não tinha backup FULL para recuperar. Então, eu te mostrei uma arma secreta chamada fn_dump_dblog e aparentemente, conseguimos recuperar essas linhas do BACKUP do log de transação! Neste post, vou mostrar como extrair os dados a partir do que pegamos do backup de log. Aqui começa a escovação de bit!
A coluna [RowLog Contents 0] (a qual eu inseri na tabela LogDelete com o nome Registro), no caso das operações de DELETE, contém o registro que estava na página quando ele foi deletado, porém em formato binário. De novo, se você aprendeu direitinho a anatomia de um registro, vai conseguir decodificar tranquilamente.
Já que vamos decodificar um registro, a informação crucial que precisamos aqui é da estrutura da tabela, especialmente os tipos de dados de cada coluna, pois é baseado nisso que as colunas são dispostas neste binário todo! Você pode consultar a estrutura direto no seu banco de produção e caso não tenha disponível (o que eu acho difícil, pois estamos falando de um DELETE FROM), pode tentar um backup FULL mais antigo ou uma cópia da tabela que você saiba que exista. O desafio é achar qual era a bendita estrutura da tabela no momento do DELETE.
Um jeito rápido é utilizar sp_help:
As informações principais que preciso são estas dentro do quadro vermelho!
- O nome;
- Tipo de dados (e a quantidade de bytes usados);
- Se aceita nulo, ou não;
- O collation é importante também, mas para este exemplo, vou omitir o uso dele, para deixarm mais simples;
É muito importante que consiga todas essas informações, exatamente como eram no momento no DELETE, pois sem isso, seu trabalho vai ganhar um grau de dificuldade altíssimo e suas chances vão cair bastante.
Pronto! Agora temos tudo que precisamos para começar a remontar nossas colunas. No post anterior, mostrei um script que gera uma tabela chamada LogDeletes. Ela tem uma coluna chamada “Registro” que é a nossa [RowLog Contents 0]. Cada uma dessas linhas equivalem às linhas que foram deletadas, por isso o total é exatamente dez mil.
Esta coluna é o nosso registro e você está olhando para os valores das colunas de algumas das linhas que foram deletadas, porém na representação binária. A fn_dump_dblog me retorna na coluna [RowLog Contents 0] (coluna Registro na tabela LogDeletes) um tipo varbinary . Por isso começa com 0x. Se tudo isso estivesse numa página de dados, esses binários estariam um seguido do outro.
Você consegue escrever uma query que faça as extrações utilizando algumas funções que trabalhem com dados binários, como SUBSTRING, REVERSE e algumas conversões que são necessárias, usando a função CONVERT. O script abaixo está no git.
E aí estão as minhas 10 mil linhas de volta!
No próximo post eu vou explicar cada um desses trechos. Então, se ainda não leu sobre anatomia do registro, ainda dá tempo!
Até lá!
DBA Team Leader na Power Tuning
Posts Relacionados:
Entendendo o que é um banco de dados e o que faz um Administrador de Banco de dados (DBA)
Recuperando dados deletados do SQL Server sem Backup Full – Parte 4
Recuperando dados deletados do SQL Server sem Backup Full – Parte 2
Recuperando dados deletados do SQL Server sem Backup Full – Parte 5
Recuperando dados deletados do SQL Server sem Backup Full – Parte 6