ROLLBACK이 빠른 작업입니까?

RDBMS 시스템이 COMMIT운영에 최적화되어 있다는 것이 사실 입니까? 얼마나 느리게 / 빠르게 ROLLBACK작동합니까?

SQL Server의 경우 커밋 작업은 LOP_COMMIT_XACT를 로그 파일에 기록하고 잠금을 해제하는 것 이상일 수 있습니다. 물론 BEGIN TRAN 이후 트랜잭션이 수행 한 모든 작업의 ​​ROLLBACK보다 빠릅니다.

커밋뿐만 아니라 거래의 모든 행동을 고려하고 있다면, 나는 당신의 진술이 사실이 아니라고 주장합니다. 외부 요소를 제외하고 데이터 디스크 속도와 비교 한 로그 디스크 속도는 트랜잭션이 수행 한 작업의 롤백이 처음 작업을 수행하는 것보다 빠를 가능성이 높습니다.

롤백은 변경 사항의 순차 파일을 읽고 메모리 내 데이터 페이지에 적용합니다. 원래 "작업"은 실행 계획을 생성하고, 페이지를 획득하고, 행을 조인하는 등의 작업을 수행해야했습니다.

편집 : 그것은 비트에 따라 다릅니다 ...

@JackDouglas는 롤백이 원래 작업보다 훨씬 오래 걸릴 수있는 상황 중 하나를 설명 하는 이 기사 를 지적했습니다 . 롤백은 대부분 단일 스레드이기 때문에 롤백하는 데 48 시간 이상 걸리는 병렬 처리를 사용하는 14 시간 트랜잭션입니다. 또한 버퍼 풀을 반복적으로 이탈하는 경우가 많으므로 더 이상 메모리 내 페이지 변경 사항을 되 돌리지 않아도됩니다.

따라서 이전 답변의 수정 된 버전입니다. 롤백이 얼마나 느려 집니까? 다른 모든 고려 사항은 일반적인 OLTP 트랜잭션의 경우 그렇지 않습니다. 일반적인 범위를 벗어나면 "do"보다 "실행 취소"하는 데 시간이 더 오래 걸릴 수 있지만 (이것은 혀 트위스터일까요?) 왜 "일"이 수행되었는지에 달려 있습니다.

편집 2 : 의견에 대한 논의에 이어 수행되는 작업이 커밋 대 롤백의 상대적 비용을 작업으로 결정하는 주요 요인임을 보여주기 위해 매우 고안된 예입니다.

두 개의 테이블을 만들고 비효율적으로 묶습니다 (페이지 당 낭비되는 공간).

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

"잘못된"업데이트 쿼리를 실행하여 작업을 수행하는 데 걸리는 시간과 커밋을 실행하는 데 걸리는 시간을 측정하십시오.

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

다시 동일하게 수행하지만 롤백을 발행하고 측정하십시오.

    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

@Rows = 1이면 합리적으로 일관성이 있습니다.

• 찾기 / 업데이트를위한 5500ms
• 3ms 커밋
• 1ms 롤백

@ Rows = 100으로 :

• 8500ms 찾기 / 업데이트
• 15ms 커밋
• 15ms 롤백

@ Rows = 1000으로 :

• 15000ms 찾기 / 업데이트
• 10ms 커밋
• 500ms 롤백

원래 질문으로 돌아 가기 작업과 커밋을 수행하는 데 걸리는 시간을 측정하는 경우 롤백은 실제로 데이터를 수정하지 않고 업데이트 할 행을 찾는 데 소비되므로 롤백이 진행되고 있습니다. 커밋 작업을 단독으로 살펴보면 커밋이 "작업"을 거의 수행하지 않는 것이 분명합니다. 커밋은 "완료되었습니다".

Oracle의 경우 롤백을 변경하는 데 걸리는 시간보다 롤백에 시간이 오래 걸릴 수 있습니다. 이것은 종종 중요하지 않기 때문에

1. 트랜잭션이 롤백되는 동안 잠금이 유지되지 않습니다.
2. 낮은 우선 순위 백그라운드 프로세스로 처리됩니다.

SQL Server의 경우 상황이 같은지 확실하지 않지만 다른 사람은 그렇지 않다고 말할 것입니다 ...

에 관해서는 "왜"나는 말하고 싶지만 rollback해야 드문 일이 사라 잘못이 있고, 물론 보통 경우 commit는 최적화에 의미가 있습니다 - 그래서 훨씬 더 일반적인 될 가능성이 높습니다commit

롤백은 단지 "아, 신경 쓰지 마라"는 것이 아닙니다. 많은 경우에 이미 수행 한 작업을 취소해야합니다. 롤백 조작이 원래 조작보다 항상 느리거나 항상 빠는 규칙은 없습니다. 원래 트랜잭션이 병렬로 실행 되더라도 롤백은 단일 스레드입니다. 기다리고 있다면 계속 기다리는 것이 가장 안전합니다.

이 모든 것은 물론 SQL Server 2019 및 Accelerated Database Recovery (가변적 인 데이터 크기에 관계없이 즉각적인 롤백을 허용하는 데이터베이스 복구 )로 변경됩니다.

모든 트랜잭션이 커밋 활동이 롤백보다 훨씬 나은 것은 아닙니다. 이러한 경우 중 하나는 SQL의 삭제 작업입니다. 트랜잭션이 행을 삭제하면이 행은 고스트 레코드로 표시됩니다. 커밋이 발행되고 고스트 레코드 정리 작업이 시작되면 이러한 레코드 만 '삭제'됩니다.

롤백이 대신 발행 된 경우 집중적 인 insert 문이 아니라 이러한 레코드에서 고스트 표시를 제거합니다.

모두가 아닙니다. 디스크 I / O 측면에서 두 작업이 사실상 동일하므로 PostgreSQL은 커밋보다 롤백하는 데 시간이 더 걸리지 않습니다. 실제로 이것이 다른 쿼리에 대해 최적화하는 것에 대한 질문 인 것처럼 커밋에 최적화 된 문제라고 생각하지 않습니다.

기본적인 질문은 디스크 레이아웃을 어떻게 해결하고 이것이 커밋과 롤백에 어떤 영향을 미치는지입니다. 커밋보다 느리게 롤백하는 주요 DB는 데이터를 업데이트 할 때 특히 클러스터 된 테이블에서 메인 데이터 구조 밖으로 데이터를 이동하고 롤백 세그먼트에 넣는 경향이 있습니다. 즉, 롤백 세그먼트를 삭제하지만 롤백하려면 모든 데이터를 다시 복사해야합니다.

PostgreSQL의 경우 모든 테이블은 힙 테이블이며 인덱스는 분리되어 있습니다. 이는 롤백 또는 커밋시 데이터를 다시 정렬 할 필요가 없음을 의미합니다. 커밋과 롤백이 모두 빠릅니다.

그러나 다른 것들을 조금 느리게 만듭니다. 예를 들어 기본 키 조회는 색인 파일을 통과 한 다음 힙 테이블에 도달해야합니다 (적용 가능한 색인이 없다고 가정). 이것은 큰 문제는 아니지만 다른 정보와 가시성을 확인하기 위해 여분의 페이지 조회 또는 심지어 임의의 페이지 조회 (해당 행에서 많은 업데이트가 발생한 경우)를 추가합니다.

그러나 여기서 속도는 쓰기 작업과 읽기 작업에 대한 PostgreSQL의 최적화 문제가 아닙니다. 일부 읽기 작업을 다른 작업보다 우선적으로 수행하는 것은 바람직하지 않습니다. 결과적으로 PostgreSQL은 다른 DB뿐만 아니라 평균적으로 수행합니다. 더 빠르거나 느린 특정 작업입니다.

따라서 실제 답변은 db가 읽기 측의 특정 워크로드에 최적화되어 있으며 이는 쓰기 측에 문제를 초래한다는 것입니다. 일반적으로 질문이있는 경우, 커밋은 항상 그렇지는 않지만 롤백보다 선호됩니다. 그러나 이것은 업데이트 중 하나가 수행하는 의미에 따라 다릅니다 (업데이트는 삭제와 다릅니다).