참고 자료
Dirty Read
처음에 x는 10 y는 20 이었다.
트랜잭션1이 트랜잭션2의 커밋되지 않은 write(y = 70)값을 읽어서 최종적으로 x = 80, y = 20 이라는 이상 현상(Anomaly)이 발생되었다.
이런 이상 현상은 격리 레벨(READ UNCOMMITTED)에서 발생할 수 있다.
Non - Repetable Read (Fuzzy Read)
x는 처음에 10 이었다.
트랜잭션1의 첫 번째 read 10 지만 중간에 트랜잭션2가 x를 50으로 바꾸고 커밋해서
트랜잭션1의 두 번째 read 50으로 트랜잭션 첫 번째 실행 결과와 다른 이상 현상 Non - Repetable Read 현상이 발생했다.
이런 이상 현상은 격리 레벨(READ COMMITTED, READ UNCOMMITED)에서 발생할 수 있다.
Phantom Read
원래 튜플2의 v = 50
처음 트랜잭션1의 v = 10인 튜플을 찾았을 때 t1만 있었지만
이후에 트랜잭션2가 t2의 v를 10으로 바꿔서 트랜잭션1이 다시 v = 10인 튜플을 찾았을 때 t1, t2 없던 데이터가 생겼다.
이런 현상을 Phantom Read 라고 한다
이런 이상 현상은 격리 레벨(READ COMMITTED, READ UNCOMMITED, REPEATABLE READ)에서 발생할 수 있다.
Isolation Level (표준 SQL 기준)
Dirty Read / Non-Repetable Read / Phantom Read
모든 이상현상을 막는것이 이상적이지만 그러면 제약사항이 많아져서 동시 처리 가능한 트랜잭션 수가 줄어들어
결국 DB의 전체 처리량이 하락하게 된다
그래서 DBMS는 일부 이상 현상은 허용하는 몇 가지 Level을 만들어서 사용자가 필요에 따라서 적절하게 선택할 수 있게 만들었다 이 Level을 Isolation Level 이라고 한다.
Isolation level | Diry Read | Non-Repetable Read | Phantom Read |
Read uncommitted | O | O | O |
Read committed | X | O | O |
Repetable read | X | X | O |
Serializable | X | X | X |
Serializable 레벨은 아예 이상 현상 자체가 발생하지 않는 level을 의미
완전한 serial schedule을 한다
애플리케이션 설계자는 isolation level을 통해서 전체 처리량과 데이터 일관성 사이에서 어느 정도 거래(trade)를 할 수 있다
이건 표준 SQL 기준이고 사실 이상 현상은 훨씬 많다
Dirty Write
x는 처음에 20 이었다.
트랜잭션1에서 x를 10으로 바꾸고 트랜잭션2에서 x를 100으로 바꾸고 commit 했는데
트랜잭션1에서 rollback 하여 최종적으로 x는 다시 10이 되었다.
이런 현상을 Dirty Write 라고 한다.
해당 이상 현상은 READ UNCOMMITTED 레벨에서 발생할 수 있다.
해당 레벨은 커밋 되지 않은 데이터에 대해서 읽거나 쓰기 모두 허용이기 때문이다.
READ COMMITTED 레벨에서는 커밋 되지 않은 데이터에 대해 읽거나 쓰기 모두 허용되지 않기 때문에
이 레벨부터 더 엄격한 레벨인 REPEATABLE READ, SERIALIZABLE 레벨에서는 Dirty Write 현상이 발생하지 않는다.
Lost Update
x는 처음에 50 이었다.
트랜잭션1에서 50을 읽고 트랜잭션2가 50을 읽어서 200으로 바꾸고 커밋하고 다시
트랜잭션1에서 50을 더하고 커밋해서 최종적으로 100이 되었다.
즉, 트랜잭션2의 실행이 증발됐다
이런 현상을 Lost Update 이상 현상이라고 한다.
해당 현상은 READ UNCOMMITTED 레벨과 READ COMMITTED 레벨에서 발생할 수 있다.
Dirty Read 확장판
처음에 x는 50 y 또한 50 이었다.
트랜잭션1에서 x를 읽고 x를 40 줄였다.
이때 트랜잭션2에서 커밋 되지 않은 x에 대한 값을 읽는다. 그리고 y 또한 읽는다
트랜잭션2에서 읽은 x,y 합은 10 + 50 = 60 이다.
트랜잭션1은 나머지 이체 작업인 y값을 읽고 y를 90으로 올린다.
최종적으로 x = 10, y = 90 이지만 트랜잭션2에서 읽은 데이터는 정합성이 깨진다. x + y = 100을 항상 유지해야 하지만
트랜잭션2에서 읽은 60은 이상한 결과다
즉, rollback 하지 않아도 Dirty Read가 발생할 수 있다.
더 많은 내용 참고
'DataBase > MySQL' 카테고리의 다른 글
[MySQL] MVCC(Multi Version Concurrency Control) (2) | 2024.11.14 |
---|---|
[MySQL] Lock을 활용한 concurrency control (2PL) (1) | 2024.11.14 |
[MySQL] concurrency control 기초2 (recoverability) (1) | 2024.11.13 |
[MySQL] concurrency control 기초1 (schedule, serializability) (1) | 2024.11.13 |
[MySQL] 트랜잭션과 ACID (0) | 2024.11.13 |