TIL/TIL

[DB] 트랜잭션 격리 수준 & 부정합 이슈

JoJobum 2022. 10. 6.

부정합 이슈

Dirty Read: 다른 트랜잭션에서 처리한 작업이 완료되지 않았음에도 불구하고 다른 트랜잭션에서 볼 수 있는 현상

Non-Repeatable Read: 하나의 트랜잭션내에서 동일한 SELECT 쿼리 실행시 항상 같은 결과를 보장해야하는 Reapeatable Read 정합성에 어긋난 것

Phantom Read: 읽을 때 쓰기 잠금을 거는 경우 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안보였다가 하는 현상

트랜잭션 격리 수준

Read Uncommitted

읽기 트랜잭션이 시작했을 때 다른 트랜잭션이 Update 가능

읽기 트랜잭션이 Update 중(un-commit)인 데이터를 조회할 수 있음

⇒ 다른 트랜잭션이 중간에 롤백을 해도 읽기 트랜잭션은 롤백 전 데이터를 조회할 수 있음

⇒ 다른 트랜잭션의 Update(커밋)과 무관하게 일관된 데이터를 얻을 수 없는 확률 높음 == Dirty Read

 

Read Committed

읽기 트랜잭션이 시작했을 때 다른 트랜잭션이 Update 가능

읽기 트랜잭션은 다른 트랜잭션에서 Update 완료(commit)된 데이터만 조회할 수 있음

⇒ Dirty Read 발생할 수 없음,

⇒ ex) 읽기 트랜잭션을 열어두고 조회한 후, 그 사이에 다른 트랜잭션이 Update 트랜잭션을 수행하고 commit 하면, 다시 읽기 트랜잭션이 조회하면 처음 조회한 것과 결과가 달라질 수 있음 (Repeatable Read 어김)

일반적인 웹 어플리케이션에선 크게 문제 안될수도?, But 은행같이 금전적인 처리와 연결되면 문제될 수 있음.

 

Repeatable Read

읽기 트랜잭션이 시작했을 때 다른 트랜잭션 Update 가능

읽기 트랜잭션은 자기자신이 시작한 순간 이전의 데이터 상태만 조회할 수 있음

⇒ Non-Repeatable Read 발생할 수 없음

⇒ 다른 트랜잭션의 Update와 상관없이 일관된 데이터 얻을 수 있음

But, Insert, Delete에 따라 결과 달라질 수 있음

Phantom Read 이슈 발생할 수 있음

발생하는 이유는 undo 레코드에 잠금을 걸 수 없기에

undo 영역의 변경 전 데이터를 가져오는 거싱 아니라

현재 레코드의 값을 가져오게 됨

Serializable

읽기 작업도 공유 잠금을 획득해야하고, 동시에 다른 트랜잭션은 변경 불가, 즉 한 트랙잭션에서 읽고 쓰는 레코드는 다른 트랜잭션에서 절대 접근 불가

⇒ 동시 처리 성능 매우 떨어짐, 모든 부정합 문제 발생X

 

반응형

댓글