Você pode utilizar este script para criar uma estrutura de teste, inserir 10 mil linhas em uma tabela de testes com diversos dados aleatórios, “perder” o backup full e fazer um backup de log (que também não é necessário).
Foi exatamente o que ocorreu! A diferença foi que até que essa situação chegasse até mim, já tinha se passado horas. Então, já haviam muitos outros backups. Após descobrir o horário em que foi feito eu determinei o backup correto e copiei ele para outro local para que eu pudesse iniciar as tentativas. No nosso cenário de exemplo, vou utilizar o próprio arquivo T:\Backup16h30.trn
E por que este backup de log? Ora, como o banco está em Recovery FULL, O SQL Server sempre loga cada linha deletada no log de transações, gerando “Log Records” que contém os dados dessa linha. E ainda, ainda devido ao recovery model, ele só vai liberar ou reusar este espaço, quando um backup de log destes registros forem feitos. Ou seja, no próximo backup de log!
OK, você tem o arquivo! E agora!? O backup de log é um arquivo binário, se abrir, mesmo num editor hexadecimal, as coisas não fazem muito sentido:
E aí é que entra a nossa primeira arma secreta: fn_dump_dblog. E advinha onde eu aprendi há muito tempo sobre ela? Isso mesmo, neste post do Paul Randal!
Basicamente, esta função me permite especificar um arquivo de backup de log, e então ela monta em um resultset com toda a estrutura do log de transação. Uma linha para cada “Log Record”. Tem uma função que faz a mesma coisa, a fn_dblog, só que ao invés de pegar do backup, ela pega do log atual do banco em que você está conectado.