{"id":1522,"date":"2020-05-25T10:32:03","date_gmt":"2020-05-25T13:32:03","guid":{"rendered":"https:\/\/thesqltimes.com\/blog\/?p=1522"},"modified":"2020-05-25T10:32:03","modified_gmt":"2020-05-25T13:32:03","slug":"recuperando-dados-deletados-do-sql-server-sem-backup-full-parte-5","status":"publish","type":"post","link":"https:\/\/thesqltimes.com\/blog\/2020\/05\/25\/recuperando-dados-deletados-do-sql-server-sem-backup-full-parte-5\/","title":{"rendered":"Recuperando dados deletados do SQL Server sem Backup Full – Parte 5"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>
Post 5\/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! Hoje, dando continuidade a nossa s\u00e9rie, vou responder a pergunta do \u00faltimo post: E se nos dados que estou recuperando tinham valores NULL?<\/p>\n

E a resposta \u00e9 muito simples: Isso est\u00e1 junto no meio desse bin\u00e1rio todo! Como voc\u00ea estudou sobre a anatomia de um registro , com os v\u00e1rios links que eu coloquei nos posts anteriores (n\u00e9?), ent\u00e3o aprendeu que existe um neg\u00f3cio chamado NULL bitmap.\u00a0<\/strong>Basicamente \u00e9 uma sequencia de bytes que indicam quais colunas tem o valor nulo ou n\u00e3o. Recorra aos links que coloquei anteriormente para entender com mais detalhes sobre ele.<\/p>\n

Sabendo isso, tudo que precisamos \u00e9 identificar o NULL bitmap no meio desse bin\u00e1rio todo, de cada registro, e checar se a coluna est\u00e1 nula ou n\u00e3o. Identificar o NULL bitmap envolve, al\u00e9m de conhecer a anatomia do registro, um pouco de m\u00e1gica matem\u00e1tica:<\/p>\n

\"\"<\/p>\n

Este trecho envolve basicamente achar alguns metadados que existem no registro (Veja o Post do Paul Randal<\/a>) para encontrar o resto das informa\u00e7\u00f5es. Primeiro, eu preciso encontrar os bytes que indicam a quantidade de colunas, por dois motivos:<\/p>\n

    \n
  1. Achando a posi\u00e7\u00e3o deles eu sei onde come\u00e7a o NULL bitmap<\/li>\n
  2. O tamanho do NULL bitmap, isto \u00e9, quantidade de bytes que formam ele, depende da quantidade de colunas
    \nA cada 8 colunas, ele precisa de um byte adicional. Por exemplo, uma tabela com 8 colunas, precisa de um NULL bitmap com 1 byte (8 bits, 1 pra cada coluna). J\u00e1 com 10 colunas, ele vai gastar 2 bytes (16 bits, sendo apenas 10 usados). Com 16 colunas, continuamos com os 2 bytes (agora usando todos os 16 bits) e por a\u00ed vai…<\/li>\n<\/ol>\n[stextbox id=’info’ caption=’Mas pera a\u00ed Rodrigo \u270b’]Se toda linha sempre tem a mesma quantidade de colunas, porque o SQL Server armazena esse dado para cada linha?<\/p>\n

    Pois \u00e9… corre el\u00e1 nas fontes sobre a anatomia do registro e voc\u00ea entender os porqu\u00eas disso…[\/stextbox]\n

    Por essas raz\u00f5es, eu precisei gerar a coluna chamada ColCount,\u00a0<\/em>que me indica a quantidade de colunas. Ela come\u00e7a no byte 27 porque a \u00faltima coluna de tipo fixo \u00e9 a DataCadastro, que come\u00e7a no byte 19 e usa 8 bytes… Os bytes dela s\u00e3o do 19 ao 26… A quantidade de colunas sempre gasta 2 bytes (Neste caso, bytes 27 e 28).<\/p>\n

    Na subquery acima, a coluna NullBmp cont\u00e9m todo o NULL bitmap! Novamente, estou usando a fun\u00e7\u00e3o SUBSTRING com a coluna Registro<\/em> ([RowLog Contents 0] de fn_dump_dblog<\/strong>) para extrair os bytes que comp\u00f5e o NULL bitmap. Neste caso, o NULL bitmap come\u00e7a no byte 29. E Pronto (como tenho 7 colunas, preciso de apenas 1 byte)! Agora que tenho o NULL bitmap completo, \u00e9 so checar cada bit dele para saber se a respectiva coluna \u00e9 nulo ou n\u00e3o:<\/p>\n