[DB] 팬텀현상

데이터의 입력과 삭제

insert, delete 모두 X-lock 을 얻어야 가능

Phantom phenomenon(팬텀 현상) : two-phase lock 을 써도 이상한 경우

팬텀 현상의 가장 큰 문제는 서로 다른 item 에 대한 연산에서 충돌이 발생한다는 것임

 

예

T1 : Account 테이블에서 부산의 모든 balance 의 합과 Assets의 부산의 값이 같은지 비교

T2 : Account 테이블에 <400, Busan, 700> tuple 을 추가하고, Assets 테이블 또한 수정

 

2PL 에서의 흐름

T1 : Read(Account[100], Account[200, Account[300]) // returns 1500

T2: insert(Account[400, Busan, 700])

T2 : read(Assets[Busan]) // returns 1500

T2 : write(Assets[Busan]) // writes 2200

T1 : read(Assets[Busan]) // returns 2200

 

여기서 T1 은 1500과 2200을 비교하여 둘이 다르다고 결과를 내놓음

위 결과는 <T1, T2> 혹은 <T2, T1> 그 어떤 것과도 결과가 다르므로 serializable 하지 않음

 

table locking 을 사용하게 된다면 팬텀현상은 발생하지 않지만 concurrency 가 떨어짐

팬텀현상 해결 방법

1. insert, delete 가 없으면 됨 (일부러 없앨수는 없지만 없는 경우는 이 현상에 대해서 생각하지 않아도 됨)
2. 테이블 락 방식을 사용
3. 인덱스 락 방식을 사용 (인덱스에 락을 거는 방법)

2PL을 인덱스에 거는 법

인덱스는 B+ 트리로 이루어지며 락을 걸 때 부모/조상 노드(인덱스)에도 걸어버림 : S-lock, X-lock 적절히

Two-phase locking protocol 도 적용 가능

하지만 인덱스에 2-phase locking 을 걸면 동시성이 떨어짐 -> Crabbing 기법 사용

인덱스 구조에 Crabbing 기법 사용하기

• 루트 노드에 S-lock
• 필요한 모든 자식 노드들에게 S-lock 을 걸고, 자신의 lock 은 품
• leaf 노드에 다다르면 X-lock 으로 업그레이드
• B+ 트리 특성인 Splitting(분할), Coalescing(병합)이 일어난다면 이 때는 부모 노드에 대해서도 X-lock 이 필요함
• 데드락 발생 가능