: 동일한 트랜잭션 시나리오 (입력, 작업)에도 고립 수준에 따라 결과가 달라질 수 있음
→ ANSI/SQL 표준에서 트랜잭션 고립 수준을 4가지로 정의, 각 고립 수준에서 허용할 현상을 정함
3가지 현상
Dirty Read(Uncommitted Dependency)
: commit되지 않은 데이터를 읽는 것
→ 데이터 무결성이 깨지고, 외래 키 제약조건이 무시되는 등 문제 발생
Non-Repeatable Read(Inconsistent Analysis)
: 기존에 읽은 row를 다시 읽을 때, 해당 row 가 없거나 변경된 경우
→ 한 트랜잭션에서 같은 row를 두 번 읽었는데 결과가 다른 경우
→ 반대 : Repeatable Read 정합성 - 트랜잭션 내에서 같은 row는 항상 같은 결과
Phantom Read
: 트랜잭션 내부에서 같은 쿼리를 두 번 실행할 때, 첫 실행 시 없던(phantom) 레코드가 조회
→ 다른 트랜잭션의 INSERT에 의해 발생, write lock설정을 통해 방지 가능
→ 같은 쿼리에 대하여 만족하는 데이터가 더 많아지기 때문에 Non-repeatable read와는 차이
고립 수준에 따른 허용
Read Uncommitted (0)
- commit 하지 않은 내용도 다른 트랜잭션에서 확인 가능
- dirty read
- non-repeatable read
- phantom read
→ 데이터 정합성에 문제가 발생할 수 있어서 RDBMS에서 표준 격리 수준으로 인정 X
Oracle
- dirty read허용 X → non-blocking read 허용 → commit 되지 않은 row를 읽을 수는 있음 → 사용자가 locked row에 접근하면 우회하여 언두 세그먼트(commit 되기 전 데이터)를 읽음 → commit 되기 전에 SELECT 가능
Dirty Read 허용 DB
- commit 되지 않은 업데이트 된 값 읽음 → 최초에 SELECT 할 때와 값이 달라지고 이 값으로 여러 작업을 하면 의도가 달라짐
Read Committed (1)
- commit 된 내용만 다른 트랜잭션에서 확인 가능
- 오라클 RDBMS 기본 설정, 온라인 서비스에서 보편적으로 선택되는 레벨
- non-repeatable read, phantom read Oracle
-
non-blocking read를 제공하기 때문에 commit까지 기다릴 필요 없음
비Oracle
-
공유 lock을 레코드 별로 걸었다 해제했다 반복
-
commit 될 때까지 기다려야 함
→ 사용자가 해당 row 사용 중이라면 commit 할 때까지 기다리는 비효율
→ Update 와 Read가 충돌한 상황
-
Repeatable Read (2)
- 트랜잭션 내에서 같은 row에 대해 항상 같은 값만 조회 = 트랜잭션 시작 전에 Commit 된 내용들만 조회 가능
- MySQL RDBMS 기본 설정 Oracle
-
멀티 버저닝을 통해 쿼리가 실행되기 시작한 시점을 기준으로 일관성 있는 결과를 보여주고, 읽는 자와 쓰는 자가 서로 Blocking하지 않도록 함
- 멀티 버저닝
- 접근한 시점에 데이터베이스의 Snapshot을 읽음
- snapshot 변경이 commit 될 때까지 다른 사용자 접근 불가
- 사용자가 업데이트하면 기존 데이터에 덮어 씌우는 것이 아닌 새로운 버전의 데이터를 UNDO영역에 생성→ UNDO영역에 백업 데이터가 많아지면 성능 저하 - 이전 버전 데이터와 비교하면서 변경 내용 기록 - 사용자는 마지막 버전의 데이터를 읽게 됨비Oacle
-
공유 읽기 Lock을 채택함으로써 구현 ⇒ 트랜잭션 단위로 lock 걸었다 해제
→ 데이터를 읽는 자가 쓰는 자 Block
-
트랜잭션이 해당 row를 읽기만 해도 lock
→ 동시성을 저하하고, 교착상태에 빠질 수 있음
-
Serializable (3)
- 가장 단순하고 엄격한 수준
- 모든 동작이 직렬화하게 동작
- 작업 중인 레코드에 대해 다른 트랜잭션에서 SELECT 불가
- 동시 처리 능력 저하 (성능 저하)
