Phantom Read 부정합문제 해결방안 In Oracle

이번 포스팅에서는 Repeatable Read 격리수준에서 발생하는 부정합 문제인 Phantom Read를 Oracle에선 어떤 방식으로 해결했을지에 대해서 알아보도록 하겠습니다. 

 

Oracle은 전 세계에서 가장 많이 사용하는 데이터베이스 중 하나로 오랜시간 사랑받은 데이터베이스입니다. 

 

Phantom Read 해결방안 In Oracle

데이터를 잠근다는 것은 같은 리소스에 접근하는 트랜잭션 사이에서 일어날 수 있는 해를 끼치는 상황들을 막아줍니다. 

 

이러한 모든 상황에서 오라클은 SQL문이 처리될 때 필요한 락을 자동적으로 얻을 수 있습니다. 그래서 오라클을 사용하는 유저는 세세한 것까지 걱정할 필요가 없어지죠. 

 

오라클은 자동적으로 가장 낮은 수준의 제한정도를 가장 높은 수준의 데이터 정합성으로 바꿔줍니다. 

 

공식문서인데 뭔가 광고글을 보는 것 같은 느낌이 들긴 합니다. 이런 공식문서는 또 새로운 느낌이네요. 

 

아무튼 오라클은 데이터를 잠그기위해 Exclusive Lock(이하 (x)Lock)과 Shared Lock(이하 (s)Lock)을 사용합니다. 이건 어디서 보던거죠? Mysql에서 일반적인 Lock을 구현한 것 중에 가장 기본이 되는 Lock입니다. (s)Lock은 읽기에 대한 락이고 (x)Lock은 삽입, 수정, 삭제에 대한 락이었습니다. 

 

하지만 Mysql과 다른 점이 있는데 바로 Lock Duration을 사용한다는 점입니다. 

 

Lock Duration

모든 락은 트랜잭션의 지속동안 동시성문제인 Dirty Read, Lost Update, 그리고 DDL 실행에의한 해를 끼치는 문제를 보호하는 상태를 획득합니다. 

 

따라서 트랜잭션은 오리지널 트랜잭션이 커밋이나 롤백을 완전히 수행할 때까지 계속해서 기다립니다. 

 

그러니까 트랜잭션이 전부 수행될 때까지 락을 걸어두고 접근하지 못하게 막는다는 의미인 것 같습니다. 

 

 

오라클은 Lock Escalation을 사용하지는 않습니다. Lock Escalation은 수많은 Lock들이 다양한 상황에서 획득될 때, 만약 한명의 유저가 테이블에서 많은 행들을 잠궈놓았다면 몇몇 데이터베이스는 자동적으로 그 유저의 행에 걸린 Lock들을 한단계 증가시킵니다. 

 

이렇게 증가시키게 되면 이 락들은 줄어드는게 아니라 오히려 이렇게 잠긴 락들이 증가하게 됩니다. 

 

이런 경우는 데드락을 심각하게 초래할 수 있습니다. 

 

데드락에 대해서는 아래의 포스팅에서 자세하게 설명이 되어있습니다. 

https://coding-review.tistory.com/302

Phantom Read 부정합문제 해결방안 In Mysql

 

또한 Mysql의 Record Lock과 비슷한 DML Lock이 있고, 행을 잠그거나 테이블을 잠그는 것 또한 가능합니다. 이것은 모두 트랜잭션의 연산 동안에 이루어집니다. 

 

 

여기까지 Oracle이 Phantom Read를 어떻게 해결했는지에 대해서 알아봤습니다. 

 

Oracle은 대단히 뭔가 하지는 않네요. 뭔가 특별한 기능을 사용하는 것은 Mysql이 유일하고 Oracle, PostgreSQL, SQL Server는 단순한 방법으로 구현해 놓은 것 같습니다. 

 

격리수준에서 발생하는 부정합 문제만을 놓고 봤을 때는 Mysql이 다른 RDBMS보다 더 나은 것 같습니다. 

 

이번에는 짧게 마무리짓고 넘어가도록 하겠습니다. 이번 포스팅도 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요~

 

 

출처

https://docs.oracle.com/cd/B13789_01/server.101/b10743/consist.htm

13 Data Concurrency and Consistency