동시성 제어

직렬 스케줄(serial schedule)
여러 트랜잭션들의 집합을 한 번에 한 트랜잭션씩 차례대로 수행함

비직렬 스케줄(non-serial schedule)
여러 트랜잭션들을 동시에 수행함

직렬가능(serializable)
비직렬 스케줄의 결과가 어떤 직렬 스케줄의 수행 결과와 동등함


데이터베이스 연산
Input(X) 연산은 데이터베이스 항목 X를 포함하고 있는 블록을 주기억 장치의 버퍼로 읽어들임
Output(X) 연산은 데이터베이스 항목 X를 포함하고 있는 블록을 디스크에 기록함
read_item(X) 연산은 주기억 장치 버퍼에서 데이터베이스 항목 X의 값을 프로그램 변수 X로 복사함
write_item(X) 연산은 프로그램 변수 X의 값을 주기억 장치 내의 데이터베이스 항목 X에 기록함

동시성 제어를 하지 않고 다수의 트랜잭션을 동시에 수행할 때 생길 수 있는 문제
갱신 손실(lost update): 수행 중인 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어 씀으로써 갱신이 무효가 되는 것
오손 데이터 읽기(dirty read): 완료되지 않은 트랜잭션이 갱신한 데이터를 읽는 것
반복할 수 없는 읽기(unrepeatable read): 한 트랜잭션이 동일한 데이터를 두 번 읽을 때 서로 다른 값을 읽는 것

예: 갱신 손실
하나의 SQL문은 DBMS 내에서 여러 개의 명령들로 나뉘어 수행된다. 다수 사용자 환경에서는 여러 사용자들이 동시에 요청한 트랜잭션의 명령들이 섞여서 수행될 수 있다. 트랜잭션 T1은 X에서 Y로 100000을 이체하고, 트랜잭션 T2는 X의 값에 50000을 더하려고 한다. 두 트랜잭션이 수행되기 전의 X와 Y의 초기값이 각각 300000과 600000이라고 가정하면 T1의 수행을 먼저 완료하고 T2의 수행을 완료하던지, T2의 수행을 먼저 완료하고 T1의 수행을 완료하던지 관계 없이 X의 최종값은 250000, Y의 최종값은 700000이 되어야 한다.

예: 오손 데이터 읽기
그림 9.8에서 트랜잭션 T1이 정미림의 잔액을 100000원 감소시킨 후에 트랜잭션 T2는 모든 계좌의 잔액의 평균값을 검색하였다. 그 이후에 T1이 어떤 이유로 철회되면 T1이 갱신한 정미림 계좌의 잔액은 원래 상태로 되돌아간다. 따라서 T2는 완료되지 않은 트랜잭션이 갱신한 데이터, 즉 틀린 데이터를 읽었다.

예: 반복할 수 없는 읽기
그림 9.9에서 먼저 트랜잭션 T2는 모든 계좌의 잔액의 평균값을 검색하였다. 트랜잭션 T2가 완료되기 전에 트랜잭션 T1이 정미림의 잔액을 100000원 감소시키고 완료되었다. 트랜잭션 T2가 다시 모든 계좌의 잔액의 평균값을 검색하면 첫 번째 평균값과 다른 값을 보게 된다. 동일한 읽기 연산을 여러 번 수행할 때 매번 서로 다른 값을 보게 될 수 있다.

9.1절의 항공기 예약 트랜잭션
여러 여행사에서 동시에 고객들의 요청에 따라 동일한 날짜에 출발하는 항공기의 빈 좌석 유무를 검사할 수 있음
그림 9.10의 순서와 같이 만일 두 여행사에서 각각 트랜잭션을 수행하는 과정에 SQL문 (1)의 수행 결과로 특정 항공기에 빈 좌석이 1개 남아
있다는 사실을 확인하고 동시에 SQL문 (2)와 (3)을 수행하여 팔린
좌석수를 1만큼씩 증가시키고 자신의 고객의 정보를 항공사
데이터베이스에 입력하려 할 때 DBMS가 아무런 조치를 취하지 않으면,
1개 남은 좌석에 두 명의 고객이 배정되는 결과를 초래하게 됨

로킹(locking)
데이터 항목을 로킹하는 개념은 동시에 수행되는 트랜잭션들의 동시성을 제어하기 위해서 가장 널리 사용되는 기법
로크(lock)는 데이터베이스 내의 각 데이터 항목과 연관된 하나의 변수
각 트랜잭션이 수행을 시작하여 데이터 항목을 접근할 때마다 요청한 로크에 관한 정보는 로크 테이블(lock table) 등에 유지됨
트랜잭션에서 갱신을 목적으로 데이터 항목을 접근할 때는 독점 로크(X-lock, eXclusive lock)를 요청함
트랜잭션에서 읽을 목적으로 데이터 항목을 접근할 때는 공유 로크(S-lock, Shared lock)를 요청함
트랜잭션이 데이터 항목에 대한 접근을 끝낸 후에 로크를 해제(unlock)함

2단계 로킹 프로토콜(2-phase locking protocol)
로크를 요청하는 것과 로크를 해제하는 것이 2단계로 이루어짐
로크 확장 단계가 지난 후에 로크 수축 단계에 들어감
일단 로크를 한 개라도 해제하면 로크 수축 단계에 들어감

로크 확장 단계(1단계)
로크 확장 단계에서는 트랜잭션이 데이터 항목에 대하여 새로운 로크를 요청할 수 있지만 보유하고 있던 로크를 하나라도 해제할 수 없음
로크 수축 단계(2단계)
로크 수축 단계에서는 보유하고 있던 로크를 해제할 수 있지만 새로운 로크를 요청할 수 없음
로크 수축 단계에서는 로크를 조금씩 해제할 수도 있고(그림 9.12), 트랜잭션이 완료 시점에 이르렀을 때 한꺼번에 모든 로크를 해제할 수도 있음(그림 9.13)
일반적으로 한꺼번에 해제하는 방식이 사용됨
로크 포인트(lock point)는 한 트랜잭션에서 필요로 하는 모든 로크를 걸어놓은 시점

데드록(deadlock)
2단계 로킹 프로토콜에서는 데드록이 발생할 수 있음
데드록은 두 개 이상의 트랜잭션들이 서로 상대방이 보유하고 있는 로크를 요청하면서 기다리고 있는 상태를 말함
데드록을 해결하기 위해서는 데드록을 방지하는 기법이나, 데드록을 탐지하고 희생자를 선정하여 데드록을 푸는 기법 등을 사용함

① T1이 X에 대해 독점 로크를 요청하여 허가받음
② T2이 Y에 대해 독점 로크를 요청하여 허가받음
③ T1이 Y에 대해 공유 로크나 독점 로크를 요청하면 로크가 해제될 때까지 기다리게 됨
④ T2가 X에 대해 공유 로크나 독점 로크를 요청하면 로크가 해제될 때까지 기다리게 됨

다중 로크 단위(multiple granularity)
대부분의 트랜잭션들이 소수의 투플들을 접근하는 데이터베이스 응용에서는 투플 단위로 로크를 해도 로크 테이블을 다루는 시간이 오래 걸리지 않음
트랜잭션들이 많은 투플을 접근하는 데이터베이스 응용에서 투플 단위로만 로크를 한다면 로크 테이블에서 로크 충돌을 검사하고, 로크 정보를 기록하는 시간이 오래 걸림
트랜잭션이 접근하는 투플의 수에 따라 로크를 하는 데이터 항목의 단위를 구분하는 것이 필요함
한 트랜잭션에서 로크할 수 있는 데이터 항목이 두 가지 이상 있으면 다중 로크 단위라고 말함
데이터베이스에서 로크할 수 있는 단위로는 데이터베이스, 릴레이션, 디스크 블록, 투플 등

일반적으로 DBMS는 각 트랜잭션에서 접근하는 투플 수에 따라 자동적으로 로크 단위를 조정함
로크 단위가 작을수록 로킹에 따른 오버헤드가 증가함
로크 단위가 작을수록 동시성의 정도는 증가함

예: 다중 단위 로크
EMPLOYEE 릴레이션에 속하는 디스크 블록 b1에 다섯 개의 투플 t1, t2, t3, t4, t5가 있다고 가정하자. 또한 트랜잭션 T1은 이 중에서 투플 t1과 t4를 갱신하고, 트랜잭션 T2는 투플 t2를 검색한다고 가정하자. 만일 로크 단위가 투플이라면 두 트랜잭션이 접근하는 투플들이 서로 상이하므로 해당 투플에 로크를 걸고 두 트랜잭션이 동시에 수행될 수 있다.

예: 다중 단위 로크
트랜잭션 T1은 블록 단위, T2는 투플 단위로 로크를 하는 경우에, 먼저 T1이 블록 b1에 대해 독점 로크를 요청하여 허가를 받으면 이 블록에 들어 있는 투플 다섯 개에도 모두 독점 로크가 걸린다. 그 다음에 트랜잭션 T2가 투플 t2에 대해 공유 로크를 요청하면 트랜잭션 T1이 로크를 풀 때까지 기다려야 한다.

팬텀 문제(phantom problem)
두 개의 트랜잭션 T1과 T2가 그림 4.8의 EMPLOYEE 릴레이션에 대해서 아래와 같은 순서대로 수행된다고 가정
그림 9.16에서 트랜잭션 T1은 EMPLOYEE 릴레이션에서 1번 부서에 근무하는 사원들의 이름을 검색하는 동일한 SELECT문을 두 개 포함하고, 트랜잭션 T2는 1번 부서에 근무하는 사원 투플을 한 개 삽입하는 INSERT문을 포함

시간 1에 트랜잭션 T1의 SELECT문이 수행되면 1번 부서에 근무하는 사원들의 이름인 박영권, 김상원이 검색됨
시간 2에 트랜잭션 T2의 INSERT문이 수행되면 EMPLOYEE 릴레이션에 1번 부서에 근무하는 정희연 투플이 삽입됨
시간 3에 트랜잭션 T1의 두 번째 SELECT문이 수행되면 박영권, 김상원, 정희연이 검색됨
즉 한 트랜잭션 T1에 속한 첫 번째 SELECT문과 두 번째 SELECT문의 수행 결과가 다르게 나타남 → 이런 현상을 팬텀 문제라고 부름