{"id":1497,"date":"2020-05-21T23:57:54","date_gmt":"2020-05-22T02:57:54","guid":{"rendered":"https:\/\/thesqltimes.com\/blog\/?p=1497"},"modified":"2020-05-21T23:57:54","modified_gmt":"2020-05-22T02:57:54","slug":"copia-recuperando-dados-deletados-do-sql-server-sem-backup-full-parte-4","status":"publish","type":"post","link":"https:\/\/thesqltimes.com\/blog\/2020\/05\/21\/copia-recuperando-dados-deletados-do-sql-server-sem-backup-full-parte-4\/","title":{"rendered":"Recuperando dados deletados do SQL Server sem Backup Full – Parte 4"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>
Post 4\/6. Este post \u00e9 parte da s\u00e9rie: Recuperando dados deletados sem Backup Full<\/a>\r\n<\/div>\r\nTempo de Leitura:<\/span> 4<\/span> minutos<\/span><\/span>

Ol\u00e1! Finalmente, chegamos a quarta parte da nossa s\u00e9rie sobre como recuperar registros deletados sem um Backup FULL. O resumo \u00e9 o seguinte: Por alguma raz\u00e3o, voc\u00ea deletou alguns registros de sua tabela e a \u00fanica coisa que tem \u00e9 o backup de log do hor\u00e1rio em que foi deletado (por exemplo, voc\u00ea perdeu o backup full pela mesma magia negra que fez voc\u00ea deletar registros incorretamente). Ent\u00e3o, at\u00e9 o post anterior, eu mostrei como \u00e9 poss\u00edvel recuperar seus dados somente com este backup de log e um pouco de conhecimento de como o SQL Server armazena os dados. Hoje, eu vou explicar melhor trechos do script que apresentei no post anterior.<\/p>\n

\u00c9 claro que tudo que eu mostrei at\u00e9 aqui n\u00e3o \u00e9 algo que voc\u00ea deve incluir em seu planejamento. Sua preocupa\u00e7\u00e3o sempre deve ser o backup (e ter o backup). O que voc\u00ea viu at\u00e9 agora \u00e9 apenas uma carta na manga e nem sempre vai dar certo por uma s\u00e9rie de raz\u00f5es como, por exemplo, se h\u00e1 compress\u00e3o ou n\u00e3o, se voc\u00ea sabe ou n\u00e3o a estrutura, tipos de dados, desempenho, etc… Ent\u00e3o, sabendo disso, continuemos a brincadeira…<\/p>\n

O script que apresentei no post anterior<\/a> usa a nossa tabela LogDeletes<\/strong>. Cada linha tem uma coluna chamada Registro<\/strong> que \u00e9 a nossa [RowLog Contents 0]<\/strong>. Ela \u00e9 exatamente o registro bin\u00e1rio, e por isso come\u00e7a com 0x, uma vez que a fn_dump_dblog<\/strong> me retorna como um varbinary<\/em>. Quando estes registros estavam nas p\u00e1gina de dados, esses bin\u00e1rios estavam um seguido do outro. (Isso mesmo: \u00e9 aquilo que voc\u00ea v\u00ea quando usa um DBCC PAGE<\/a>). Aqui est\u00e3o as primeiras linhas para refrescar sua mem\u00f3ria:<\/p>\n

\"\"<\/a><\/p>\n

Se voc\u00ea fez o dever de casa e estudou sobre a anatomia do registro, ent\u00e3o descobriu que os primeiros 4 bytes do registro bin\u00e1rio s\u00e3o reservados para o header dele. Cada registro tem o seu e ele define algumas informa\u00e7\u00f5es que n\u00e3o s\u00e3o relevantes para este post. Isto \u00e9, no quinto byte come\u00e7a a primeira coluna de tipo fixo! No nosso caso, como descobrimos no post anterior, as colunas de tipo fixo, e o seus tamanhos s\u00e3o:<\/p>\n