07 트랜잭션

1. 트랜잭션

1. 트랜잭션 (Transaction)

• DBMS에서 데이터를 다루는 논리적인 작업의 단위
• 여러 개의 SQL 연산(INSERT, UPDATE, DELETE 등)을 하나의 묶음으로 처리하는 것
• 데이터의 일관성과 무결성을 보장하기 위해 하나로 묶여 수행되는 연산들의 집합

2. 트랜잭션의 특성

특성	설명
Atomicity (원자성)	트랜잭션의 모든 연산은 전부 실행되거나 전혀 실행되지 않아야 함. 실패 시 전체 취소(ROLLBACK).
Consistency (일관성)	트랜잭션 전후로 데이터베이스의 규칙(무결성 제약조건 등)이 항상 유지되어야 함.
Isolation (고립성)	동시에 여러 트랜잭션이 실행되어도 서로의 중간 결과를 볼 수 없어야 함.
Durability (지속성)	트랜잭션이 성공적으로 완료되면 그 결과는 시스템 장애가 발생해도 영구히 보존됨.

3. 트랜잭션의 상태

상태	설명
Active	트랜잭션이 실행 중인 상태
Partially Committed	모든 명령이 수행되고, 커밋 직전 단계
Committed	커밋이 완료되어 DB에 영구 반영된 상태
Failed	실행 중 오류나 시스템 문제로 실패한 상태
Aborted	실패로 인해 롤백되어 트랜잭션이 취소된 상태

4. 명령어

명령	설명
BEGIN / START TRANSACTION	트랜잭션 시작
COMMIT	트랜잭션 성공 → 변경사항 확정
ROLLBACK	트랜잭션 실패 → 변경사항 취소
SAVEPOINT	중간 지점 저장 (부분 롤백 가능)

5. 예시

  START TRANSACTION; -- 시작
  
  UPDATE account SET balance = balance - 10000 WHERE user_id = 'A'; -- A작업
  UPDATE account SET balance = balance + 10000 WHERE user_id = 'B'; -- B작업
  
  COMMIT; -- 커밋 / 종료

2. 동시성 제어

1. 동시성 제어

• 여러 트랜잭션이 동시에 실행될 때 데이터의 일관성을 깨뜨리지 않도록 관리하는 기술

2. 문제유형

문제 유형	설명	예시
갱신 손실 (Lost Update)	두 트랜잭션이 같은 데이터를 수정할 때, 나중에 커밋된 값이 먼저 커밋된 값을 덮어써서 손실 발생	A가 100 → 80으로 수정, B가 같은 데이터 100 → 90으로 수정 후 커밋 → A의 변경(80)이 사라짐
더티 리드 (Dirty Read)	다른 트랜잭션이 아직 커밋하지 않은 데이터를 읽어버림	A가 잔액 100 → 50으로 수정 중, 아직 커밋 안 했는데 B가 50을 읽음
비반복적 읽기 (Non-repeatable Read)	같은 데이터를 두 번 읽었는데 값이 달라짐	A가 한 번 읽을 때는 100, 다시 읽을 때는 B가 수정해서 80이 됨
유령 읽기 (Phantom Read)	한 번 조회한 결과 집합에 나중에 새로운 행이 추가되거나 사라져서 결과가 달라짐	A가 “잔액 100 이상 고객” 조회 → B가 새 계좌 추가 → 다시 조회하니 행 수가 늘어남

3. 트랜잭션 고립수준과 동시성 제어 문제

• 여러 트랜잭션이 동시에 수행될 때, 서로의 작업(특히 아직 커밋되지 않은 변경 내용)에 접근할 수 있는 정도를 정하는 규칙
• 트랜잭션 간에 얼마나 ‘고립되어’ 독립적으로 동작할지를 설정하는 단계

• 종류

  Level	고립 수준	설명	허용되는 문제 현상
  1	READ UNCOMMITTED (커밋되지 않은 읽기)	다른 트랜잭션이 아직 커밋하지 않은 데이터도 읽을 수 있음	Dirty Read, Non-repeatable Read, Phantom Read
  2	READ COMMITTED (커밋된 읽기)	커밋된 데이터만 읽을 수 있음	Non-repeatable Read, Phantom Read
  3	REPEATABLE READ (반복 가능 읽기)	트랜잭션 동안 읽은 행(row)은 다른 트랜잭션이 수정 불가	Phantom Read
  4	SERIALIZABLE (직렬화 가능)	트랜잭션이 완전히 순차적으로 실행된 것처럼 보장	없음

4. 문제의 해결 방법

제어 기법	개념	특징
로킹(Locking)	데이터 접근 시 잠금(lock)을 걸어 다른 트랜잭션 접근 제한	가장 일반적, 2단계 로킹 규약(2PL) 사용
타임스탬프 순서(Timestamp Ordering)	트랜잭션 시작 시간(타임스탬프) 기준으로 순서 강제	충돌 시 늦은 트랜잭션이 롤백
낙관적 검증(Optimistic Concurrency Control)	충돌이 거의 없다고 가정하고, 커밋 시점에 검증	읽기 위주 시스템에 적합
다중 버전(MVCC: Multi-Version Concurrency Control)	데이터의 여러 버전을 유지하여 읽기/쓰기 충돌 최소화	PostgreSQL, MySQL InnoDB 등에서 사용

3. 락

1. 락(Lock)

• 트랜잭션이 데이터를 읽거나 쓸 때, 다른 트랜잭션이 동시에 접근하지 못하게 잠그는 장치
• 데이터 접근 제어를 위한 기본 수단
• 동시성 제어(Concurrency Control) 를 실현하는 도구
• 락킹(Locking)은 락을 거는 행위나 메커니즘 자체

2. 락의 종류

구분	설명	동시 접근 가능 여부
공유 락 (Shared Lock, S-lock)	데이터를 읽을 때 사용. 여러 트랜잭션이 동시에 공유 가능	O
배타 락 (Exclusive Lock, X-lock)	데이터를 변경할 때 사용. 다른 트랜잭션 접근 불가	X
의도 락 (Intent Lock)	상위 단위(테이블 등)에 락이 걸릴 예정임을 표시	내부적으로 DB가 관리

3. 2단계 락킹(2-Phase Locking, 2PL)

• 락을 거는 단계(성장 단계) 와 락을 해제하는 단계(축소 단계) 두 단계를 명확히 구분해서 수행하는 규칙

• 구조

  단계	이름	설명
  1단계: 성장 단계 (Growing Phase)	트랜잭션이 필요한 데이터에 락을 획득할 수 있음. 하지만 해제는 불가능.
  2단계: 축소 단계 (Shrinking Phase)	더 이상 새로운 락을 획득할 수 없고, 이미 획득한 락을 해제만 할 수 있음.

• 방법 (특정 기점이후로는 해제만 가능함.)

    시간축 →
    [ Growing Phase ]  | [ Shrinking Phase ]
       락 획득 가능      |    락 해제만 가능
    -------------------↓--------------------
    | Lock A | Lock B | Unlock A | Unlock B |
  

4. 데드락(DeadLock)

• 락킹 과정에서 발생하는 문제 상황
• 락의 “방법”이 아니라 락킹이 잘못 걸려서 생긴 “현상”

• 상황

  T1: A 자원 잠금 → B 자원 필요
  T2: B 자원 잠금 → A 자원 필요
   → 둘 다 상대방이 가진 락을 기다리느라 영원히 멈춤
  

4. 회복

1. 트랜잭션 회복(Recovery)

• 트랜잭션 실패나 시스템 장애가 발생했을 때 DB를 일관된 상태로 복구하는 절차.
• 데이터베이스에서 트랜잭션 실패나 시스템 장애가 발생했을 때, DB를 일관된 상태로 복구하는 과정
• 대부분의 DBMS 회복 기법은 로그(Log) 기반으로 동작

• 장애 종류

  트랜잭션 회복처리	장애 유형	설명	원인/예시	회복 방식
  V	시스템 충돌 (System Crash)	DBMS가 실행 중인 시스템이 갑자기 멈춤	전원 차단, OS 다운, DBMS crash	체크포인트 + 로그 기반 UNDO/REDO
  V	미디어 장애 (Media Failure)	저장장치 손상으로 데이터 읽기/쓰기 불가	디스크 고장, 파일 손상, RAID 오류	백업 복원 후 로그 적용
  V	응용 소프트웨어 오류 (Application Error)	프로그램이나 SQL 오류로 데이터 불일치 발생	잘못된 SQL 문, 버그, 트랜잭션 논리 오류	UNDO, 필요시 백업 복원
  -	자연재해 (Natural Disaster)	지진, 화재, 홍수 등 외부 환경 요인으로 시스템/장치 피해	서버/디스크 물리적 손상, 데이터센터 접근 불가	미디어 장애 처리(백업 복원) 및 시스템 재구성
  -	부주의 혹은 태업 (Human Error / Sabotage)	관리자의 실수나 악의적 행위로 데이터 손상	잘못된 DELETE/DROP, 설정 오류, 내부 공격	로그 기반 복구, 백업 복원, 보안 강화

2. 로그 기반 회복

• 유형
  • UNDO : 트랜잭션 실패 시 이미 수행한 연산을 되돌리는 것
  • REDO : 트랜잭션 성공 후 커밋된 내용을 영구 저장 장치에 반영하는 것
• 회복 과정 예시
  • 장애 발생 후 로그 분석
  • 커밋되지 않은 트랜잭션 → UNDO 수행
  • 커밋된 트랜잭션 → REDO 수행

3. 체크포인트 기반 회복(Checkpoint Recovery)

• 데이터베이스의 현재 상태를 주기적으로 디스크에 저장하고,
• 장애 발생 시 체크포인트 이후 로그만 확인하여 빠르게 회복.
• 동작 원리
  • DBMS가 주기적으로 체크포인트 신호를 발생
  • 현재까지 커밋된 트랜잭션 상태와 수정된 페이지를 디스크에 기록
  • 장애 발생 시
    • 체크포인트 이후 로그만 읽어서 UNDO / REDO 수행
    • 체크포인트 이전 로그는 무시 가능 → 회복 시간 단축

4. 그림자 페이징(Shadow Paging)

• 로그방식 X
• 트랜잭션이 수정할 때 원본 페이지를 그대로 두고, 새로운 그림자 페이지를 만들어 수정
• 커밋 시 그림자 페이지를 실제 페이지로 바꾸면 성공, 실패하면 기존 원본 그대로 유지
• 동작 원리
  • 트랜잭션 시작 → 페이지 수정 요청
  • DB는 그림자 페이지(Shadow Page) 생성
  • 트랜잭션 수행 → 그림자 페이지에 변경 내용 적용
  • 커밋과 롤백
    • 커밋 시: 그림자 페이지 → 실제 페이지 교체
    • 롤백 시: 원본 페이지 그대로 유지 → UNDO 필요 없음

5. Note

1. DBMS - 기본고립수준

DBMS	기본 고립 수준	특징
Oracle	READ COMMITTED	가장 일반적, 성능 중심
MySQL (InnoDB)	REPEATABLE READ	갭 락(Gap Lock)으로 팬텀 리드 방지
PostgreSQL	READ COMMITTED	READ COMMITTED 또는 SERIALIZABLE 지원
SQL Server	READ COMMITTED	SNAPSHOT 모드 선택 가능