Seria possível reverter uma transação usando um único thread?
Tentei encontrar uma resposta para esta pergunta, mas não consegui encontrar uma que fornecesse referências. Eu li sobre mecanismos de reversão. Veja abaixo:
Qual é o mecanismo de reversão de transações no SQL-Server?
Se você reverter a transação, o mecanismo começará a varrer o log para trás procurando registros do trabalho realizado por sua transação e desfará o trabalho: quando encontrar o registro de atualização de A para B, alterará o valor de volta para A. insert será desfeito excluindo a linha inserida. Uma exclusão será desfeita inserindo de volta a linha. Isso é descrito em Arquitetura Lógica do Log de Transação e Log de Transação Write-Ahead.
Esta é a explicação de alto nível, os detalhes internos exatos de como isso acontece não são documentados para leigos e não estão sujeitos à sua inspeção nem alterações.
Reverter uma transação leva mais tempo do que executá-la. Há várias razões para isso.
Agora, a questão é: como posso testar em vários cenários quantos recursos (single/multithreaded) são consumidos por essas operações?
Pelo que ouvi, um único segmento é reivindicado. No entanto, não consigo encontrar nenhuma evidência para apoiar essa afirmação.
Se uma operação de thread único for executada, o comportamento pode ser alterado para multi thread? Que tal o contrário?
A reversão é principalmente de encadeamento único (é por isso que a reversão pode demorar mais do que a transação que você está revertendo). https://www.brentozar.com/archive/2014/03/happens-issue-kill/
Você não pode "controlar" como o SQL fará a reversão.
Para citar Brent Ozar: "O que é que você está tentando consertar".
O SQL Server 2019 introduziu a recuperação acelerada de banco de dados (ADR).
https://learn.microsoft.com/en-us/sql/relational-databases/accelerated-database-recovery-concepts?view=sql-server-ver16
Se você tiver o ADR habilitado, a reversão da transação durante a recuperação do banco de dados é instantânea, independentemente do tempo em que a transação esteve ativa ou do número de atualizações realizadas.
Então, algumas vezes, em caso de emergências, é melhor reiniciar o servidor do que esperar o rollback.
Além disso, se bem me lembro, antes da reversão do ADR durante a fase de recuperação do banco de dados era multithread.
No Sql server não há conceitos de multi thread como gerenciamento de thread por outra linguagem de alto nível (como c#), e os mecanismos de rollback estão fora de seu controle e são implementados e gerenciados pelo mecanismo sql interno.