트랜잭션 경계와 격리 수준: ACID·COMMIT·READ COMMITTED·SERIALIZABLE

핵심 요약

Transaction은 여러 SQL을 함께 성공시키거나 함께 취소해야 하는 하나의 업무 단위로 묶는 경계입니다. 계좌 이체라면 출금, 입금, 이체 이력 기록이 모두 성공해야 하나의 업무가 완성됩니다.

업무 Transaction 시작
→ 업무 SQL 실행
→ COMMIT: 전체 변경 확정
또는
→ ROLLBACK: 전체 변경 취소

Oracle의 기본 격리 수준은 READ COMMITTED입니다. 각 SQL Statement는 자신이 시작한 시점에 Commit된 데이터와 자기 Transaction의 변경을 읽습니다. 따라서 한 Query 내부는 한 시점으로 일관되지만, 같은 Transaction에서 같은 Query를 다시 실행하면 그 사이 다른 Transaction이 Commit한 결과를 볼 수 있습니다.

SERIALIZABLE과 READ ONLY는 여러 Query가 Transaction 시작 시점의 Snapshot을 공유합니다. SERIALIZABLE은 DML을 허용하지만, Transaction 시작 후 다른 Transaction이 변경·Commit한 Row를 갱신하려 하면 ORA-08177이 발생할 수 있습니다. READ ONLY는 여러 Query의 기준 시점을 고정하는 Report에 적합하며 일반 사용자의 DML을 허용하지 않습니다.

학습 목표

이 이론을 학습한 뒤에는 다음을 설명할 수 있어야 합니다.

1. Session과 Transaction의 차이를 구분한다.
2. ACID의 네 속성을 Oracle의 Undo·Redo·Lock·Constraint와 연결한다.
3. Statement 일관 읽기와 실제 Read/Write Transaction 시작을 구분한다.
4. COMMIT, 전체 ROLLBACK, ROLLBACK TO SAVEPOINT의 효과를 비교한다.
5. DDL의 실행 전·후 묵시적 Commit 규칙을 설명한다.
6. Statement 실패와 업무 Transaction 전체 실패를 구분한다.
7. Dirty·Non-Repeatable·Phantom Read를 사례로 판별한다.
8. READ COMMITTED, SERIALIZABLE, READ ONLY의 Snapshot 기준 시점을 비교한다.
9. ORA-08177의 원인과 안전한 재시도 범위를 판단한다.
10. 업무 원자성·Lock 보유시간·Undo·재시작 요구를 고려해 Transaction 경계를 설계한다.

1. Session과 Transaction의 차이

Session은 Client가 Database에 연결해 요청을 보내는 논리적 연결입니다. 하나의 Session 안에서 여러 Transaction을 차례로 실행할 수 있습니다.

Session 시작
├─ Transaction 1 → COMMIT
├─ Transaction 2 → ROLLBACK
├─ Transaction 3 → COMMIT
└─ Session 종료

Transaction은 Session 전체가 아니라 하나의 논리적 업무 변경 단위입니다.

UPDATE account
SET    balance = balance - 10000
WHERE  account_id = 1;

UPDATE account
SET    balance = balance + 10000
WHERE  account_id = 2;

INSERT INTO transfer_history(
       transfer_id, from_account, to_account, amount, created_at
)
VALUES (
       transfer_seq.NEXTVAL, 1, 2, 10000, SYSTIMESTAMP
);

COMMIT;

출금만 먼저 Commit하면 입금이나 이력 기록 실패 시 업무 불변식이 깨집니다. Commit 위치는 처리 Row 수가 아니라 함께 성공해야 하는 업무 범위를 기준으로 정합니다.

2. ACID를 Oracle 동작과 연결하기

ACID Consistency와 Read Consistency

ACID Consistency
→ 잔액 합계, PK·FK·CHECK 같은 업무·무결성 상태를 만족

Read Consistency
→ Query가 한 기준 시점의 일관된 데이터 버전을 읽음

Database는 선언된 Constraint와 Transaction 규칙을 보장하지만, “일일 이체 한도”처럼 Schema에 선언하지 않은 업무 규칙은 Application이나 Database Logic에 올바르게 구현해야 합니다.

3. Statement 일관 읽기와 Transaction 시작

Oracle은 일반 Query에 항상 Statement-Level Read Consistency를 제공합니다. 그러나 단순 SELECT를 실행했다는 사실과 변경 가능한 TX Transaction이 시작되었다는 사실을 동일하게 보지 않습니다.

현재 Transaction을 명시적으로 시작하거나 TX Lock을 얻는 대표 동작은 다음과 같습니다.

• INSERT, UPDATE, DELETE, MERGE 같은 DML
• SELECT ... FOR UPDATE
• SET TRANSACTION
• DBMS_TRANSACTION을 통한 명시적 시작

COMMIT;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- SET TRANSACTION은 현재 Transaction의 첫 문장이어야 한다.

일반 SELECT는 Query가 열린 시점의 Snapshot을 읽지만, READ COMMITTED에서 다음 Query가 반드시 같은 Snapshot을 사용하는 것은 아닙니다.

4. Transaction의 종료

Application은 Tool의 종료 동작이나 Connection Pool 구현에 의존하지 않고, 정상·오류 경로에서 COMMIT 또는 ROLLBACK을 명시해야 합니다.

5. COMMIT의 내구성 의미

COMMIT은 현재 Transaction의 변경을 확정하고, 이후 시작되는 다른 Session의 Statement에서 변경을 볼 수 있게 합니다.

COMMIT 요청
→ Commit SCN 확정
→ Commit Record를 포함한 Redo를 LGWR가 Online Redo Log에 기록
→ Transaction 확정
→ Savepoint 제거
→ Transaction Lock 해제

Commit 성공은 모든 Dirty Data Block이 Datafile에 기록됐다는 뜻이 아닙니다. DBWn은 변경 Block을 이후 적절한 시점에 기록할 수 있습니다.

Commit 완료
≠ 모든 Dirty Block의 Datafile Write 완료

Commit 완료
= 장애 후 변경을 재현할 Redo의 내구성 확보

기본적인 동기 Commit은 Client가 Redo 기록 완료를 기다립니다. COMMIT WRITE NOWAIT 또는 비동기 설정은 응답 지연을 줄일 수 있지만, Redo가 안정 저장되기 전에 Instance가 실패하면 Application이 성공으로 인식한 최근 Commit이 손실될 위험을 허용합니다. 금전·재고·주문처럼 손실을 허용할 수 없는 업무에는 신중해야 합니다.

6. ROLLBACK과 SAVEPOINT

전체 ROLLBACK

ROLLBACK;

현재 Transaction의 모든 미완료 변경을 Undo를 이용해 취소하고 Transaction을 끝냅니다.

부분 ROLLBACK

UPDATE orders
SET    status = 'PROCESSING'
WHERE  order_id = 1001;

SAVEPOINT before_payment;

INSERT INTO payment_history(payment_id, order_id, amount)
VALUES (5001, 1001, 70000);

ROLLBACK TO before_payment;

ROLLBACK TO before_payment는 Savepoint 이후의 변경을 취소하지만 Transaction을 끝내지 않습니다. Savepoint 이전의 UPDATE는 계속 미완료 상태로 남습니다.

SAVEPOINT A
→ 작업 1
→ SAVEPOINT B
→ 작업 2
→ ROLLBACK TO A

결과
→ A 이후의 작업 1·작업 2 취소
→ A 이후에 만든 B 제거
→ A는 유지
→ Transaction은 계속 진행

같은 Savepoint 이름을 다시 사용하면 그 이름은 최신 위치를 가리킵니다. COMMIT이나 전체 ROLLBACK은 모든 Savepoint를 제거합니다.

ROLLBACK TO SAVEPOINT는 Savepoint 이후 획득한 일부 Row·Table Lock을 해제할 수 있지만, 이미 해당 Row를 기다리던 Transaction의 대기 상태 등 세부 동작은 단순히 “모든 대기가 즉시 해소된다”로 일반화하지 않습니다.

7. Statement 실패와 Transaction 전체 실패

Oracle은 실행되는 SQL Statement 앞에 내부 Savepoint를 사용합니다. 실행 중 한 Statement가 실패하면 일반적으로 그 Statement의 변경만 취소되고, 이전에 성공한 Statement는 같은 Transaction에 미완료 상태로 남습니다.

INSERT INTO orders(order_id, customer_id)
VALUES (1001, 10);
-- 성공

INSERT INTO orders(order_id, customer_id)
VALUES (1001, 20);
-- PK 중복 오류: 두 번째 Statement만 Rollback

SQL Statement 실행 오류
→ 해당 Statement의 변경 Rollback
→ 이전 성공 Statement는 미완료 상태로 남을 수 있음
→ Application이 업무 전체 COMMIT·ROLLBACK을 결정

Trigger가 Statement의 일부로 실행되다가 오류를 발생시키면 해당 DML과 일반 Trigger 변경도 함께 Statement 수준으로 취소됩니다. 다만 Autonomous Transaction은 별도 Transaction이므로 별도로 Commit된 내용은 Parent Statement Rollback으로 취소되지 않습니다.

Parse 단계에서 발견된 오류는 변경 작업이 시작되지 않았으므로 실행 중 Statement Rollback과 구분합니다.

8. DDL의 묵시적 COMMIT

Oracle은 문법적으로 유효한 DDL을 실행하기 전에 현재 Transaction을 Commit합니다. DDL이 성공하면 실행 후에도 Commit합니다.

기존 DML
→ DDL 실행 전 묵시적 COMMIT
→ DDL 실행
→ 성공 시 DDL 실행 후 묵시적 COMMIT

INSERT INTO audit_test(id, message)
VALUES (1, 'before ddl');

CREATE TABLE existing_table(id NUMBER);
-- 이미 존재하여 실행 오류가 발생한다고 가정

ROLLBACK;

DDL이 문법적으로 유효했다면 실행 전 Commit 때문에 앞선 INSERT는 이미 확정될 수 있습니다. DDL 실패 후 ROLLBACK으로 앞선 INSERT를 되돌릴 수 없습니다.

배포 Script에 DML과 DDL을 섞으면 Rollback 가능 범위가 예상과 달라질 수 있으므로 단계별 복구 계획이 필요합니다.

9. 읽기 이상 현상

Dirty Read

다른 Transaction의 미Commit 값을 읽는 현상입니다. Oracle의 지원 격리 수준에서는 다른 Transaction의 Dirty Data를 읽지 않습니다.

Non-Repeatable Read

같은 Row를 같은 조건으로 다시 읽었는데 다른 Transaction의 Commit 때문에 값이 달라지는 현상입니다.

첫 조회: 잔액 100
다른 Transaction: 잔액 200으로 변경 후 Commit
두 번째 조회: 잔액 200

Phantom Read

같은 검색 조건을 다시 실행했을 때 조건을 만족하는 Row 집합이 달라지는 현상입니다.

첫 조회: status='READY' 10행
다른 Transaction: READY Row 1행 Insert 후 Commit
두 번째 조회: 11행

Oracle은 READ UNCOMMITTED라는 격리 수준을 제공하지 않으며, 별도의 REPEATABLE READ 이름 대신 SERIALIZABLE이 Transaction-Level Read Consistency를 제공합니다.

10. READ COMMITTED: Statement Snapshot

READ COMMITTED는 Oracle의 기본 격리 수준입니다. 각 Query는 Query가 열린 시점에 Commit된 데이터와 자신의 Transaction 변경을 봅니다.

Transaction 또는 Session 작업 흐름
├─ SELECT 1 시작 → Snapshot A
├─ 다른 Session COMMIT
└─ SELECT 2 시작 → Snapshot B

따라서 같은 Transaction 안에서도 두 SELECT의 결과가 달라질 수 있습니다. 그러나 한 SELECT가 대량 데이터를 읽는 동안 다른 Session이 Commit하더라도 해당 SELECT는 시작 Snapshot을 유지하므로 결과의 앞부분과 뒷부분이 서로 다른 시점으로 섞이지 않습니다.

READ COMMITTED는 읽은 Row를 Transaction 끝까지 잠그지 않습니다. “조회한 값이 이후에도 바뀌지 않는다”는 업무 요구가 있다면 SELECT FOR UPDATE, 조건부 UPDATE, Version Column, Unique Constraint 같은 별도 동시성 제어가 필요합니다.

11. SERIALIZABLE: Transaction Snapshot과 ORA-08177

COMMIT;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SERIALIZABLE Transaction의 Query는 Transaction 시작 시점의 Snapshot과 자신의 변경을 봅니다.

Transaction 시작 Snapshot S
├─ SELECT 1 → S 기준
├─ 다른 Session COMMIT
├─ SELECT 2 → 여전히 S 기준
└─ 자신의 UPDATE 결과는 확인 가능

SERIALIZABLE은 읽은 모든 Row에 Read Lock을 거는 방식이 아닙니다. 다른 Transaction은 계속 데이터를 변경할 수 있지만, 현재 SERIALIZABLE Transaction에서는 그 변경이 보이지 않습니다.

현재 Transaction이 시작된 뒤 다른 Transaction이 특정 Row를 변경·Commit했고, 현재 Transaction이 그 Row를 UPDATE 또는 DELETE하려 하면 ORA-08177이 발생할 수 있습니다.

ORA-08177
→ Transaction 시작 후 다른 Transaction이 변경·Commit한 데이터를 만남
→ 현재 Snapshot 기준으로 안전한 직렬화가 불가능

공식 오류 조치는 의도한 Operation 또는 Transaction을 재시도하는 것입니다. 실제 업무에서는 앞선 조회 결과로 계산·검증한 조건도 오래된 Snapshot에 기반할 수 있으므로, 일반적으로 전체 업무 Transaction을 Rollback하고 최신 데이터로 다시 판단하는 방식이 안전합니다.

Serializable Snapshot이 같더라도 “읽은 Row가 다른 Transaction에 의해 물리적으로 바뀌지 않는다”는 뜻은 아닙니다. Application 수준의 존재 여부 검사나 불변식은 Constraint 또는 명시적 Lock 없이 Snapshot만으로 완전하게 보호되지 않을 수 있습니다.

12. READ ONLY: 동일 시점 Report

COMMIT;
SET TRANSACTION READ ONLY;

SELECT COUNT(*) FROM orders;
SELECT SUM(amount) FROM orders;

COMMIT;

READ ONLY Transaction은 Transaction 시작 시점의 Snapshot을 여러 Query가 공유합니다. 첫 Query와 두 번째 Query 사이에 다른 Session이 주문을 추가해도 두 결과는 같은 기준 시점을 사용합니다.

대표 활용은 다음과 같습니다.

• 건수·합계·상세가 동일 시점을 기준으로 해야 하는 Report
• 여러 Table을 순서대로 읽는 정합성 분석
• DML 없이 긴 분석 Query 묶음을 수행하는 업무

일반 사용자의 READ ONLY Transaction에서는 DML과 SELECT FOR UPDATE를 수행할 수 없습니다. Transaction을 설정한 뒤 COMMIT 또는 ROLLBACK으로 종료합니다. 긴 Snapshot은 과거 버전을 만들기 위한 Undo가 충분히 유지되어야 하므로 실행시간과 Undo 보존 상태를 함께 관리합니다.

13. SET TRANSACTION과 ALTER SESSION

SET TRANSACTION은 현재 Transaction의 첫 문장이어야 합니다. 이미 DML이나 SELECT FOR UPDATE로 Transaction이 시작된 뒤 격리 수준을 바꿀 수 없습니다.

14. 격리 수준 선택 기준

격리 수준을 높이는 것만으로 중복 요청, 재고 음수, Lost Update 같은 모든 업무 경쟁이 해결되지는 않습니다. Constraint, Lock, Version Column, Idempotency Key를 함께 설계합니다.

15. 좋은 Transaction 경계

권장 원칙

1. 하나의 업무 불변식을 유지하는 SQL을 같은 Transaction에 둡니다.
2. 사용자 입력과 외부 API 호출은 가능한 한 Transaction 시작 전에 완료합니다.
3. Transaction 안에서는 필요한 Database 작업만 빠르게 수행합니다.
4. 모든 정상·오류 경로에서 COMMIT 또는 ROLLBACK을 명시합니다.
5. Connection Pool 반환 전에 미완료 Transaction을 정리합니다.
6. Auto-Commit 설정을 업무 요구와 일치시킵니다.
7. Batch Size와 Commit Unit을 별도로 결정합니다.
8. 재시도 가능한 업무는 중복 실행에도 안전하도록 Idempotency를 설계합니다.

피해야 할 예

Transaction 시작
→ Row 변경
→ 사용자 승인 5분 대기
→ 외부 API 호출
→ 추가 Row 변경
→ COMMIT

이 구조는 Lock·Undo·Connection을 오래 보유하고, 실패 시 Rollback 범위를 키웁니다.

사용자 입력·외부 검증 완료
→ 짧은 Database Transaction 시작
→ 업무 SQL 실행
→ COMMIT 또는 ROLLBACK

Transaction은 무조건 짧게 자르는 것이 아니라, 업무 원자성을 깨지 않는 범위에서 짧게 설계합니다.

혼동하기 쉬운 판단과 정확한 기준

적용 판단 순서

1. 한 Transaction이 보장해야 할 업무 불변식을 한 문장으로 정의합니다.
2. Application의 시작·Commit·Rollback 지점을 확인합니다.
3. Auto-Commit과 Connection Pool 반환 정책을 확인합니다.
4. DDL과 DML이 같은 처리 흐름에 섞여 있는지 확인합니다.
5. Statement 오류와 업무 Transaction 전체 오류의 Rollback 범위를 구분합니다.
6. 여러 Query가 동일 Snapshot을 요구하는지 판단합니다.
7. READ COMMITTED, READ ONLY, SERIALIZABLE 중 요구에 맞는 수준을 선택합니다.
8. SERIALIZABLE에서는 ORA-08177 재시도 정책과 Idempotency를 설계합니다.
9. 긴 Transaction의 Lock·Undo·Rollback·Connection 비용을 측정합니다.
10. 결과 정확성, 처리량, 대기시간, 재시도 횟수를 변경 전후 비교합니다.