Mitos de desempenho:Truncar não pode ser revertido

Autor convidado:Derik Hammer (@SQLHammer)

As diferenças entre TRUNCATE TABLE e DELETE são muitas vezes mal compreendidas. Eu procuro refutar o mito de que TRUNCATE TABLE não pode ser revertido:
“TRUNCATE TABLE não é registrado e, portanto, não pode ser revertido. Você tem que usar DELETE, se estiver em uma transação.”

Ler o manual

O artigo do Books Online sobre TRUNCATE TABLE é bastante descritivo:
“Remove todas as linhas de uma tabela ou partições especificadas de uma tabela, sem registrar as exclusões de linhas individuais. TRUNCATE TABLE é semelhante à instrução DELETE sem cláusula WHERE; no entanto, TRUNCATE TABLE é mais rápido e usa menos recursos do sistema e do log de transações.”
O fato de que TRUNCATE TABLE usa menos recursos de log de transações implica que ele grava no log de transações até certo ponto. Vamos descobrir quanto e investigar sua capacidade de ser revertida.

Prove

Em um post anterior, Paul Randal passa por isso em detalhes meticulosos, mas achei que seria útil fornecer reproduções muito simples para refutar os dois elementos desse mito.

TRUNCATE TABLE pode ser revertido?

Provar que TRUNCATE TABLE pode ser revertido é bastante fácil. Vou simplesmente colocar TRUNCATE TABLE em uma transação e reverter.

USE demo;
BEGIN TRANSACTION;
  SELECT COUNT(*) [StartingTableRowCount] FROM [dbo].[Test];
  TRUNCATE TABLE [dbo].[Test];
  SELECT COUNT(*) [TableRowCountAfterTruncate] FROM [dbo].[Test];
ROLLBACK TRANSACTION;
SELECT COUNT(*) [TableRowCountAfterRollback] FROM [dbo].[Test];

Existem 100.000 linhas na tabela e ela retorna para 100.000 linhas após a reversão:

TRUNCATE TABLE grava no log?

Ao executar um CHECKPOINT, obtemos um ponto de partida limpo. Então podemos verificar os registros de log antes e depois do TRUNCATE TABLE.

USE demo;
CHECKPOINT;
 
  SELECT COUNT(*) [StartingLogRowCount]
  FROM sys.fn_dblog (NULL, NULL);
 
  TRUNCATE TABLE [dbo].[Test];
 
  SELECT COUNT(*) [LogRowCountAfterTruncate]
  FROM sys.fn_dblog (NULL, NULL);

Nosso comando TRUNCATE TABLE gerou 237 registros de log (pelo menos inicialmente). Isso é o que nos permite realizar uma reversão e como o SQL Server registra a alteração para começar.

E os DELETEs?

Se DELETE e TRUNCATE TABLE gravarem no log e puderem ser revertidos, o que os torna diferentes?

Conforme mencionado na referência BOL acima, TRUNCATE TABLE usa menos recursos do sistema e do log de transações. Já observamos que 237 registros de log foram escritos para o comando TRUNCATE TABLE. Agora, vamos olhar para o DELETE.

USE demo;
CHECKPOINT;
 
  SELECT COUNT(*) [StartingLogRowCount]
  FROM sys.fn_dblog (NULL, NULL);
 
  DELETE FROM [dbo].[Test];
 
  SELECT COUNT(*) [LogRowCountAfterDelete]
  FROM sys.fn_dblog (NULL, NULL);

Com mais de 440.000 registros de log escritos para DELETE, o comando TRUNCATE é claramente muito mais eficiente.

Encerramento

TRUNCATE TABLE é um comando registrado e pode ser revertido, com uma enorme vantagem de desempenho sobre um DELETE equivalente. DELETE torna-se importante quando você deseja excluir menos linhas do que as existentes na tabela (já que TRUNCATE TABLE não aceita uma cláusula WHERE). Para algumas ideias sobre como tornar DELETEs mais eficientes, veja a postagem de Aaron Bertrand, "Quebrar grandes operações de exclusão em pedaços".

Sobre o autor

Derik é um profissional de dados e MVP recém-criado da Microsoft Data Platform com foco no SQL Server. Sua paixão se concentra em alta disponibilidade, recuperação de desastres, integração contínua e manutenção automatizada. Sua experiência abrange administração de banco de dados de longo prazo, consultoria e empreendimentos empresariais trabalhando nos setores financeiro e de saúde. Ele é atualmente um Administrador Sênior de Banco de Dados responsável pela equipe de Operações de Banco de Dados na Sede Mundial da Subway Franchise. Quando não está no horário ou blogando no SQLHammer.com, Derik dedica seu tempo à #sqlfamily como líder de capítulo do grupo de usuários FairfieldPASS SQL Server em Stamford, CT.