O ROLLBACK é uma operação rápida?

Para o SQL Server, você poderia argumentar que uma operação de commit nada mais é do que escrever LOP_COMMIT_XACT no arquivo de log e liberar bloqueios, o que obviamente será mais rápido do que o ROLLBACK de todas as ações executadas por sua transação desde BEGIN TRAN.

Se você está considerando cada ação de uma transação, não apenas o commit, eu ainda diria que sua afirmação não é verdadeira. Excluindo fatores externos, velocidade do disco de log em comparação com a velocidade do disco de dados, por exemplo, é provável que a reversão de qualquer trabalho feito por uma transação seja mais rápida do que fazer o trabalho em primeiro lugar.

Uma reversão está lendo um arquivo sequencial de alterações e aplicando-as às páginas de dados na memória. O "trabalho" original tinha que gerar um plano de execução, adquirir páginas, juntar linhas etc.

Edit: Depende um pouco...

@JackDouglas apontou para este artigo que descreve uma das situações em que a reversão pode demorar significativamente mais do que a operação original. O exemplo é uma transação de 14 horas, inevitavelmente usando paralelismo, que leva mais de 48 horas para reverter porque a reversão é principalmente de thread único. Você provavelmente também estaria agitando o pool de buffer repetidamente, portanto, não está mais revertendo as alterações nas páginas na memória.

Portanto, uma versão revisada da minha resposta anterior. Quão mais lento é o rollback? Todas as outras coisas consideradas, para uma transação OLTP típica, não é. Fora dos limites do típico, pode demorar mais para "desfazer" do que para "fazer", mas (isso é um trava-língua em potencial?) O motivo dependerá de como o "fazer" foi feito.

Edit2: Na sequência da discussão nos comentários, aqui está um exemplo muito artificial para demonstrar que o trabalho que está sendo feito é o principal fator na determinação da despesa relativa de confirmação versus reversão como operações.

Crie duas tabelas e empacote-as de forma ineficiente (espaço desperdiçado por página):

SET STATISTICS IO OFF;
SET STATISTICS TIME OFF;
SET NOCOUNT ON;
GO

CREATE TABLE dbo.Foo
(
    col1 INT IDENTITY(1,1) PRIMARY KEY CLUSTERED
    , col2 CHAR(4000) NOT NULL DEFAULT REPLICATE('A', 4000)
)

CREATE TABLE dbo.Bar
(
    col1 INT IDENTITY(1,1) PRIMARY KEY CLUSTERED
    , col2 CHAR(4000) NOT NULL DEFAULT REPLICATE('A', 4000)
)
GO

INSERT dbo.Foo DEFAULT VALUES
GO 100000

INSERT dbo.Bar DEFAULT VALUES
GO 100000

Execute uma consulta de atualização "ruim", medindo o tempo necessário para fazer o trabalho e o tempo necessário para emitir o commit.

DECLARE 
    @StartTime DATETIME2
    , @Rows INT

SET @Rows = 1

CHECKPOINT
DBCC DROPCLEANBUFFERS

BEGIN TRANSACTION

SET @StartTime = SYSDATETIME()

UPDATE
    dbo.bar
SET
    col2 = REPLICATE('B', 4000)
FROM
    dbo.bar b
INNER JOIN
    (
    SELECT TOP(@Rows)
        col1
    FROM
        dbo.foo
    ORDER BY
        NEWID()
    ) f
ON  f.col1 = b.col1
OPTION (MAXDOP 1)

SELECT 'Find and update row', DATEDIFF(ms, @StartTime, SYSDATETIME())

SET @StartTime = SYSDATETIME()

COMMIT TRANSACTION

SELECT 'Commit', DATEDIFF(ms, @StartTime, SYSDATETIME())
GO

Faça o mesmo novamente, mas emita e meça a reversão.

    DECLARE 
    @StartTime DATETIME2
    , @Rows INT

SET @Rows = 1
    
CHECKPOINT
DBCC DROPCLEANBUFFERS

BEGIN TRANSACTION

SET @StartTime = SYSDATETIME()

UPDATE
    dbo.bar
SET
    col2 = REPLICATE('B', 4000)
FROM
    dbo.bar b
INNER JOIN
    (
    SELECT TOP(@Rows)
        col1
    FROM
        dbo.foo
    ORDER BY
        NEWID()
    ) f
ON  f.col1 = b.col1
OPTION (MAXDOP 1)

SELECT 'Find and update row', DATEDIFF(ms, @StartTime, SYSDATETIME())

SET @StartTime = SYSDATETIME()

ROLLBACK TRANSACTION

SELECT 'Rollback', DATEDIFF(ms, @StartTime, SYSDATETIME())
GO

Com @Rows=1, obtenho uma consistência razoável:

• 5500ms para localizar/atualizar
• Compromisso de 3ms
• reversão de 1 ms

Com @Linhas=100:

• 8500ms encontrar/atualizar
• 15ms de confirmação
• reversão de 15ms

Com @Linhas=1000:

• 15000ms encontrar/atualizar
• 10ms de confirmação
• reversão de 500ms

De volta à pergunta original. Se você está medindo o tempo gasto para fazer o trabalho mais a confirmação, a reversão está ganhando, porque a maior parte desse trabalho é gasta para encontrar a linha a ser atualizada, não modificando os dados. Se você está olhando para a operação de commit isoladamente, deve ficar claro que o commit faz muito pouco "trabalho" como tal. Commit é "terminei".

Para Oracle, a reversão pode levar muito mais tempo do que o tempo necessário para fazer as alterações que estão sendo revertidas. Muitas vezes isso não importa porque

1. Nenhum bloqueio é mantido enquanto a transação está sendo revertida
2. É tratado por um processo em segundo plano de baixa prioridade

Para o SQL Server, não tenho certeza se a situação é a mesma, mas alguém dirá se não for ...

Quanto ao "porquê", eu diria que rollbackdeve ser raro , geralmente apenas se algo der errado e, commité claro, provavelmente será muito mais comum - portanto, faz sentido otimizar paracommit

A reversão não é apenas "oh, não importa" - em muitos casos, ela realmente precisa desfazer o que já havia feito. Não há regra de que a operação de reversão será sempre mais lenta ou sempre mais rápida que a operação original, embora, mesmo que a transação original seja executada em paralelo, a reversão seja de thread único. Se você está esperando, sugiro que seja mais seguro continuar esperando.

Tudo isso muda com o SQL Server 2019, é claro, e o Accelerated Database Recovery (que, com uma penalidade também variável, permite a reversão instantânea, independentemente do tamanho dos dados).

Nem todas as transações terão sua atividade de confirmação executada muito melhor do que sua reversão. Um desses casos é a operação de exclusão no SQL. Quando uma transação exclui linhas, essas linhas são marcadas como registros fantasmas. Depois que um commit é emitido e uma tarefa de limpeza de registro fantasma é iniciada, somente esses registros são 'excluídos'.

Se, em vez disso, foi emitida uma reversão, ela apenas remove as marcações fantasmas desses registros, e não as instruções de inserção intensivas.

Nem todos são. O PostgreSQL não leva mais tempo para reverter do que para confirmar, pois as duas operações são efetivamente idênticas em termos de E/S de disco. Na verdade, não acho que seja uma questão de ser otimizado para confirmação, mas sim para quais outras consultas alguém está otimizando.

A questão básica é como você aborda o layout em disco e como isso afeta o commit versus o rollback. Os principais bancos de dados que revertem mais lentamente do que o commit tendem a mover os dados, principalmente de tabelas agrupadas, para fora das estruturas de dados principais e colocá-los em um segmento de reversão ao atualizar os dados. Isso significa que, para confirmar, basta descartar o segmento de reversão, mas para reverter, você deve copiar todos os dados de volta.

Para o PostgreSQL, todas as tabelas são heap e os índices são separados. Isso significa que, ao reverter ou confirmar, nenhum dado precisa ser reorganizado. Isso torna a confirmação e a reversão rápidas.

No entanto, torna algumas outras coisas um pouco mais lentas. Uma pesquisa de chave primária, por exemplo, precisa percorrer um arquivo de índice e, em seguida, atingir a tabela de heap (supondo que não haja índices de cobertura aplicáveis). Isso não é grande coisa, mas adiciona uma pesquisa de página extra ou talvez até algumas pesquisas de página aleatórias (se muitas atualizações ocorreram nessa linha) para verificar outras informações e visibilidade.

A velocidade aqui, no entanto, não é uma questão de otimização no PostgreSQL para operações de gravação versus operações de leitura. É uma falta de vontade de privilegiar algumas operações de leitura em detrimento de outras. Conseqüentemente, o PostgreSQL executa, em média, tão bem quanto os outros bancos de dados. São apenas algumas operações que podem ser mais rápidas ou mais lentas.

Portanto, acho que a resposta real é que os bancos de dados são otimizados para determinadas cargas de trabalho no lado da leitura e isso leva a desafios no lado da gravação. Normalmente, quando há uma dúvida, os commits geralmente, embora nem sempre, serão favorecidos em relação aos rollbacks. No entanto, isso depende das implicações de fazer qualquer um deles (atualizações são diferentes de exclusões).