[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 가 떨어짐
팬텀현상 해결 방법
- insert, delete 가 없으면 됨 (일부러 없앨수는 없지만 없는 경우는 이 현상에 대해서 생각하지 않아도 됨)
- 테이블 락 방식을 사용
- 인덱스 락 방식을 사용 (인덱스에 락을 거는 방법)
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 이 필요함
- 데드락 발생 가능