2018년 11월 26일

팬텀 충돌 (Phantom Conflict)

I. 가상 튜플 충돌 현상, 팬텀 충돌의 개요

서로 충돌하지 않는 두 개 이상의 트랜잭션이 삽입되려고 하는 가상의 튜플에 의해 충돌이 발생되는 현상
트랜잭션의 일관성이 보장되지 않는 현상

읽기 수행 시	– 다른 트랜잭션의 삽입으로 처음 읽을 때 없던 튜플이 다음에 읽을 때 나타남
쓰기 수행 시	– 다른 트랜잭션의 삭제 동작으로 처음 쓰기 때 있던 튜플이 재 수행 시 사라짐

트랜잭션	내용
T1	SELECT SUM(sal) FROM emp WHERE dept=’Comp ENG’;
T2	INSERT INTO emp(eno, ename, dept, sal) VALUES(‘e123’, ‘LEE’, ‘Comp ENG’, 500);
T1 → T2	T1 수행 결과: T2 결과 튜플 포함되지 않고 계산
T2 → T1	T1 수행 결과: T2 결과 튜플 포함되어 계산

– 서로 충돌이 없는 T1, T2 트랜잭션의 실행 결과가 실행 순서에 따라 상이하여 논리적 일관성 깨어짐
– 실제 데이터베이스의 튜플이 아니라 향후 저장될 가상 튜플에 의해 트랜잭션 충돌

방안	설명	특징
Locking 단위 확대	– Locking 단위를 튜플이 아닌 릴레이션 범위로 확대	– Locking 단위 확대에 따라 병행성 감소
Index Locking	– Locking 규약을 인덱스에 적용	– 릴레이션 Index가 만들어져 있어야 함

– 일반적인 DBMS에서는 트랜잭션 격리수준 (Isolation level)을 통해 팬텀 충돌 방지 방법 제공

구분	Dirty Read	Non-repeatable Read	Phantom Conflict
Read Uncommitted	O	O	O
Read Committed	X	O	O
Repeatable Read	X	X	O
Serializable	X	X	X

– 팬텀 충돌 방지를 위해 Isolation level은 Serializable 단계 이상으로 설정 필요

3 Comments

도리
팬텀 충돌의 정의 이해를 위해서는 본문 내용 중 II-가 내용을 사례로 이해하시면 될 것 같습니다.

II-가에서 서로 충돌하지 않는 두 개 이상의 트랜잭션(T1, T2), 삽입되려고 하는 가상의 튜플(T2 수행 결과에 따라 생성되려는 튜플)로 볼 때, T1과 T2는 상대편 트랜잭션이 종료되었을 때는 수행 시 영향을 주지 않지만, 상대편 트랜잭션이 종료되지 않았을 때 수행된다면 동일 트랜잭션 내 먼저 수행한 T1과 나중에 수행한 T1의 결과가 다르기 때문에 데이터베이스 일관성이 깨지는 현상을 팬텀 충돌이라고 합니다. 조금 더 설명드리면, T1은 emp 테이블을 단순 읽기만 수행하는 트랜잭션이므로 T1 트랜잭션 내에서 항상 같은 튜플만 보여야 합니다. 하지만 T1이 종료되지 않은 상태에서 T2 수행이 된다면, T2로 인해 emp 테이블에 생성되는 튜플로 인해 T1은 항상 같은 튜플을 볼 수 없기 때문에 데이터베이스 일관성이 보장되지 않습니다.
2019년 8월 28일 응답