Lost Update Lost Update 는 여러 트랜잭션이 같은 행을 동시에 읽어 수정할 때 한쪽 갱신이 나중 갱신에 의해 덮여 사라지는 현상이다. MVCC(스냅샷) 는 일부 읽기 문제를 막지만, 클라이언트 측에서 Read–Modify–Write 패턴을 쓰면 여전히 발생할 수 있다. 실무 대응은 가능한 경우 UPDATE … SET v = v + 1 처럼 원자적 SQL 사용 충돌이 잦지 않으면 낙관적 잠금(버전/타임스탬프 비교) 으로 충돌 감지 후 재시도 핫스팟엔 비관적 잠금(SELECT … FOR UPDATE) 사용 강제 일관성이 필요하면 DBMS 의 Serializable/SSI 선택이다 운영에서는 충돌률·재시도율·락 대기 시간을 관측하고 재시도·백오프 정책을 설계해야 한다. ...
Phantom Read Phantom Read 는 한 트랜잭션이 같은 조건으로 반복 조회할 때, 다른 트랜잭션의 삽입·삭제로 인해 결과 행 집합이 달라지는 현상이다. 예컨대 " 잔여 재고가 0 이면 주문 허용 " 을 검사할 때 다른 트랜잭션이 새 주문을 추가하면 최초 조건이 깨질 수 있다. 전통적 2PL 은 키 - 범위 잠금으로 갭을 막아 phantom 을 예방하고, MVCC 기반 DB 는 **스냅샷 + 직렬화 (Serializable/SSI)**로 충돌을 감지해 해결한다. 하지만 강한 격리는 동시성·지연·교착 비용을 키우므로, 실무에서는 위험 쿼리를 먼저 식별하고 (업무 불변식), 범위 인덱스·명시적 락·트랜잭션 경계 재설계 또는 애플리케이션 레벨 보완을 조합해 적용하는 것이 현실적이다. ...
Write Skew Write Skew 는 두 트랜잭션이 같은 **판단 (읽기)**을 하고 각자 다른 레코드를 갱신해서 결과적으로 비즈니스 규칙이 깨지는 현상이다. 예: 두 의사가 동시에 당직 해제 판단 → 최종적으로 아무도 남지 않는 상황. Snapshot Isolation 은 읽기는 스냅샷에서 빠르게 처리하고 쓰기 충돌 (같은 행을 동시에 쓰는 경우) 만 검사하기 때문에 이런 상황을 허용할 수 있다. 예방은 DB 수준 (Serializable/SSI, predicate/next-key locks) 이나 애플리케이션 수준 (guard row, 명시적 락, 집계 테이블) 으로 수행하며, 운영적으로는 직렬화 오류율을 모니터링하고 재시도 정책을 설계해야 한다. ...
Dirty Read Dirty Read 는 한 트랜잭션이 커밋하지 않은 변경을 다른 트랜잭션이 읽는 현상으로, 잘못된 집계·오판·롤백 후 부정합을 초래한다. 대부분의 실무에서는 정확성 우선 업무에는 금지하고, 로그·집계처럼 정확성 요구가 낮은 영역에만 제한적으로 허용한다. 완화책으로는 MVCC 기반 스냅샷 격리 (RCSI/SI), 읽기 전용 리플리카 (CQRS), 쿼리 힌트·화이트리스트 적용, 모니터링 및 재현 테스트가 있다. DB 엔진별 동작이 다르니 적용 전 반드시 벤더별 테스트와 정책 문서화를 수행하라. Dirty Read 개념·관계·실무 적용 Dirty Read 는 아직 확정되지 않은 (커밋되지 않은) 변경을 읽는 상황 을 말한다. 이로 인해 나중에 원 트랜잭션이 취소되면 읽은 값이 허위가 되어 잘못된 계산·보고가 발생할 수 있다. 따라서 대부분 운영 시스템은 기본적으로 Dirty Read 를 차단하는 READ COMMITTED 이상을 사용하고, 로그·모니터링 등 정확성에 덜 민감한 경로만 별도 복제본이나 스냅샷을 통해 읽도록 분리한다. ...
Serializable Serializable 은 트랜잭션 동시성에서 가장 강한 격리 수준으로, 실행 결과가 어떤 순차적 실행과 같도록 보장해 Dirty Read·Non-Repeatable Read·Phantom 등 모든 이상현상을 차단한다. 구현 방식은 잠금 (Strict 2PL), MVCC 기반의 직렬성 검증 (SSI), 또는 낙관적 검증 (OCC) 등이며, 분산 환경에서는 2PC·분산 합의·외부 시계 같은 추가 메커니즘이 필요하다. 실무에서는 데이터 무결성이 절대적일 때 우선 적용하되 성능 저하·교착·재시도 비용을 인덱스 튜닝, 트랜잭션 단축, 백오프/재시도 설계, 부분적 격리 상향 (핵심 경로만) 으로 완화하는 것이 핵심 전략이다. ...
Read Committed Read Committed(읽기 커밋) 는 실무에서 널리 쓰이는 기본 격리 수준으로, 항상 커밋된 데이터만 읽게 해 Dirty Read 를 차단한다. 다만 트랜잭션 내 여러 문장은 서로 다른 시점의 커밋 상태를 볼 수 있어 Non-repeatable Read 와 Phantom이 발생할 수 있다. 내부 구현은 DB 마다 달라 (PostgreSQL/Oracle 은 MVCC 스냅샷 기반, SQL Server 는 기본 락 기반에 RCSI 옵션 존재) 동일 명칭이라도 동작이 다르므로 DB 별로 테스트·검증해야 한다. 일반 웹·OLTP 는 Read Committed 가 성능·정합성의 균형이지만, 회계·결제 등 강한 일관성이 필요한 도메인에서는 Repeatable Read 나 Serializable 을 사용하는 것이 추천된다. 운영 시 장기 트랜잭션 회피, 락 대기·데드락 모니터링, 읽기 풀 설계로 위험을 완화하는 것이 추천된다. ...
Read Uncommitted Read Uncommitted(읽기 미확정) 는 트랜잭션 격리에서 가장 낮은 수준으로, 다른 트랜잭션의 커밋되지 않은 변경 (Dirty Read) 을 허용해 읽기 처리량을 최대화하려는 목적이다. SQL 표준상 정의되지만, 많은 상용 DB 는 이를 진짜로 지원하지 않거나 내부적으로 Read Committed 로 승격하기 때문에 기대 동작을 DB 별로 확인해야 한다. 실무에서는 로그 집계·대략적 통계·탐색 쿼리처럼 정확성보다 속도가 우선인 경우에만 제한적으로 사용하며, 읽기 전용 커넥션 분리·금지 쿼리 목록·롤백 탐지·재검증 같은 가드레일을 반드시 둬야 안전하다. 읽기 성능이 필요하면 레플리카 기반 읽기, MVCC 스냅샷 격리 또는 샘플링을 우선 고려하는 편이 바람직하다. ...
Repeatable Read Repeatable Read(반복 읽기) 는 트랜잭션 내에서 같은 조회가 항상 동일한 결과를 반환하도록 보장해 재현성을 확보한다. 구현은 MVCC(스냅샷 기반) 또는 잠금 (범위·next-key) 방식으로 나뉘며, 두 방식은 가시성·충돌 처리·성능 특성이 다르다. RR 은 Dirty Read 와 Non-repeatable Read 를 방지하지만 Phantom(범위 삽입/삭제) 은 엔진별로 다르게 처리된다. 따라서 금융·결산 같은 재현성이 중요한 워크로드에 유리하되, 실제 적용 전 DB 별 동작 확인, 재현 테스트, 성능·교착 검증, 필요 시 부분적 상향 (Serializable) 또는 리포트 분리가 필요하다. ...