reference: "데이터베이스 개론" / 김연희 / 한빛아카데미
병행 제어
=> 트랜잭션의 일관성(C), 고립성(I) 보장
DBMS는 앞선 포스팅에서 설명한 것처럼 트랜잭션의 원자성과 지속성 특성을 보장하기 위해 '회복 기능'을 제공한다. 그리고 일관성과 고립성 특성을 보장하기 위해 '병행 제어' 기능을 제공한다.
이 기능을 통해 여러 개의 트랜잭션들이 동시에 수행되는 병행 수행이 가능해지고, 이에 여러 사용자가 DB를 동시에 공유할 수 있게 된다. 병행 수행은 실제로 여러 트랜잭션들이 차례로 번갈아 수행되는 인터리빙(interleaving) 방식으로 진행된다.
만약 병행 수행되는 트랜잭션들이 서로 다른 데이터를 사용하여 연산을 실행하는 경우에는 괜찮지만 동시에 같은 데이터에 접근하여 변경 연산을 실행하려고 하면 예상치 못한 결과가 나타날 수 있다. 그러므로 병행 수행을 하더라도 각 트랜잭션이 다른 트랜잭션의 방해를 받지 않고 정확한 수행 결과를 얻을 수 있도록 제어해야 한다. 이러한 제어를 병행 제어 또는 동시성 제어라 한다.
제어가 없는 병행 수행의 문제
=> "갱신 분실", "모순성", "연쇄 복귀 실패"
문제1) 갱신 분실
갱신 분실(lost update)은 하나의 트랜잭션이 수행한 데이터 변경 연산의 결과를 다른 트랜잭션이 덮어써 변경 연산이 무효화되는 것이다.
source: https://blog.daum.net/lkno01/64
위 그림은 데이터 X에 1000을 더하는 트랜잭션 T1과 데이터 X를 절반으로 감소시키는 트랜잭션 T2가 병행 수행되면서 갱신 분실의 문제가 발생한다. T1이 자신이 실행한 변경 연산의 결과(X+=1000)을 DB에 반영하려고 write(X) 연산을 실행하고, DB에 있는 X 값이 변경된다. 그런데 바로 이어서 T2도 마찬가지로 자신이 실행한 변경 연산의 결과(X/=2)를 DB에 반영하려고 write(X) 연산을 실행하면서 DB에 있는 값이 최종적으로 1500된다. 결과적으로 T1의 변경 연산이 DB에 실제로 반영되지 않고 무효화되어 T1이 수행되지 않은 것처럼 된다. T1이 갱신 분실이 발생한 것이다.
각 트랜잭션을 순차적으로 수행하며 병행 제어를 하면 정확한 병행 수행을 할 수 있다.
source: https://blog.daum.net/lkno01/64
문제2) 모순성
모순성(inconsistency)은 하나의 트랜잭션이 여러 개의 데이터 변경 연산을 실행할 때 일관성 없는 상태의 DB에서 데이터를 가져와 연산을 실행함으로써 모순된 결과가 발생하는 것이다.
예를 들어 어떤 연산은 현재의 트랜잭션이 실행되기 전 상태의 DB에서 데이터를 가져와 실행하고, 또 다른 연산은 다른 트랜잭션이 변경한 DB에서 데이터를 가져와 실행하면 모순성 문제가 발생할 수 있다. 아래 그림이 그 예가 된다.
source: https://osskdb.wordpress.com/2016/10/10/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EB%AA%A8%EC%88%9C%EC%84%B1/
위에서 트랜잭션 T1은 데이터 X와 Y 값에 각각 1000을 더하는 트랜잭션이고, 트랜잭션 T2는 X와 Y값을 각각 50%씩 감소시키는 트랜잭션 T2가 병행 수행되면서 모순성의 문제가 발행한 예이다.
T2가 T1의 중간에 수행되면서, Y에 대한 변경 연산이 남아있는 T1는 자신이 수행하기 전 상태의 데이터 Y 값 3000이 아닌 T2가 변경한 데이터 Y 값인 1500을 가지고 연산을 수행하는 모순이 발생한다. 즉 T1이 T2로 인해 데이터 X와 데이터 Y를 서로 다른 상태의 DB에서 가져와 연산을 실행하기에 결과를 신뢰할 수 없다.
두 트랜잭션을 이와 같이 아무런 제어 없이 동시에 수행하면, 정확한 트랜잭션 수행 결과를 얻을 수 없어 DB는 모순된 상태가 되는 것이다.
문제3) 연쇄 복귀
연쇄 복귀(cascading rollback)은 트랜잭션이 완료되기 전에 장애가 발생하여 rollback 연산을 수행하면, 이 트랜잭션이 장애 발생 전에 변경한 데이터를 가져가 변경 연산을 실행한 또 다른 트랜잭션에도 rollback 연산을 연쇄적으로 실행해야 한다는 것이다. 그런데 장애가 발생한 트랜잭션이 rollback 연산을 실행하기 전에, 변경한 데이터를 가져가 사용하는 다른 트랜잭션이 수행을 완료해버리면 rollback 연산을 실행할 수 없어 문제가 발생하게 된다.
source: https://blog.daum.net/lkno01/64
데이터 X와 Y값에 각각 1000을 더하는 트랜잭션 T1과 데이터 X의 값을 절반으로 감소시키는 트랜잭션 T2가 병행 수행되면서 연쇄 복귀의 문제가 발행한 예이다.
T1의 연산이 남아있는 상태에서 T2가 T1이 변경한 데이터 X 값을 가지고 자신의 모든 연산을 실행한 후 완료되었다. 그런데 그 다음 T1이 데이터 Y를 읽어오는 연산을 실행하는 도중 장애가 발생하여 rollback 연산으로 원래의 DB 상태로 복구되어야 한다면, 잘못된 데이터 X로 연산을 실행한 T2에도 rollback 연산이 연쇄적으로 실행되어야 한다. 하지만 T2는 이미 커밋된 상태이고 rollback 연산이 실행될 수 없어 문제가 발생하게 된다.
트랜잭션 스케줄
=> "직렬 스케줄", 비직렬 스케줄", "직렬 가능 스케줄"
병행 순서에서는 트랜잭션들이 차례로 번갈아 수행되는 인터리빙 방식으로 진행된다. 트랜잭션에 있는 연산을 실행하는 순서에 따라 트랜잭션들의 수행 결과가 달라지기도 하고, 병행 수행에 따른 문제가 발생하기도 한다. 따라서 여러 트랜잭션을 병행 수행할 때는 트랜잭션들의 연산을 실행하는 순서가 중요하다.
트랜잭션 스케줄은 트랜잭션에 포함되어 있는 연산들을 수행하는 순서이다. 일반적으로 하나의 트랜잭션에는 많은 연산들이 포함되어 있어 여러 트랜잭션을 병행 수행하는 경우 트랜잭션들의 각 연산을 실행시키는 순서인 트랜잭션 스케줄도 여러 가지가 있을 수 있다.
직렬 스케줄
- 인터리빙 X, 병행 수행 X
- 어떤 직렬 스케줄을 사용하는가는 중요 X
직렬 스케줄은 인터리빙 방식을 이용하지 않고 각 트랜잭션별로 연산들을 순차적으로 실행시키는 것이다. 이를 통해 모든 트랜잭션이 완료될 때까지 다른 트랜잭션의 방해를 받지 않고 독립적으로 수행된다. 그래서 직렬 스케줄에 따라 트랜잭션이 수행되고 나면 항상 모순이 없는 정확한 결과만 얻는다.
같은 트랜잭션들을 대상으로 하더라도 트랜잭션의 수행 순서에 따라 다양한 직렬 스케줄이 만들어 질 수 있고, DB의 최종 결과가 달라질 수 있다. 하지만 결과는 모두 정확하기에 어떤 직렬 스케줄을 사용하는가는 중요하지 않다.
source: https://blog.daum.net/lkno01/64
직렬 스케줄에 따라 여러 트랜잭션들을 수행하면 항상 정확한 결과를 얻을 수 있지만, 인터리빙 방식이 아니기에 병행 수행이라 할 수 없다. 성능적으로 불리하기에 이 방식은 잘 사용하지 않는다.
비직렬 스케줄
- 인터리빙 O, 병행 수행 O
- 갱신 분실, 모순성, 연쇄 복귀 문제가 발생할 수 있음 => 최종 수행 결과의 정확서을 보장할 수 없음
- 어떤 비직렬 스케줄을 선택하느냐가 중요
비직렬 스케줄은 인터리빙 방식을 이용하여 트랜잭션을 병행해서 수행시키는 것이다. 비직렬 스케줄에 따라 여러 트랜잭션들이 병행 수행되면서 갱신 분실, 모순성, 연쇄 복귀 실패 등의 문제가 발행할 수 있어 최종 수행 결과의 정확성을 보장할 수 없다. 그러므로 어떤 비직렬 스케줄을 선택하여 트랜잭션들을 수행하느냐가 중요하다. 정확한 결과를 얻을 수 있는 비직렬 스케줄도 있을 수 있고, 정확한 결과를 얻을 수 없는 비직렬 스케줄도 있을 수 있다.
source: https://blog.daum.net/lkno01/64
직렬 가능 스케줄
- 인터리빙 O, 병행 수행 O
- 정확한 결과를 생성하는 비직렬 스케줄
- 비직렬 스케줄 중 '직렬 가능성'을 가진 스케줄이 직렬 가능 스케줄
직렬 가능 스케줄은 직렬 스케줄에 따라 수행한 것과 같이 정확한 결과를 생성하는 비직렬 스케줄이다. 모든 비직렬 스케줄이 직렬 가능한 것은 아니다.
비직렬 스케줄 중에서 수행 결과가 동일한 직렬 스케줄이 없는 것들은 결과의 정확성을 보장할 수 없으므로 직렬 가능 스케줄이 아니다.
앞서 비직렬 스케줄 설명에서의 첫 번째 그림이 직렬 가능 스케줄이고, 두 번째 그림이 직렬 가능 스케줄이 아니다.
직렬 가능 스케줄은 직렬 스케줄과 다르게 병행 수행이 가능하지만 직렬 가능 스케줄인지 여부를 판단하는 일은 쉽지 않다. 따라서 DBMS에서는 직렬 가능 스케줄인지를 검사하기보다는 직렬 가능성을 보장하는 병행 제어 기법을 사용한다.
병행 제어 기법
- 직렬 가능 스케줄 검사는 너무 많은 시간이 소모됨 => 병행 제어 기법을 통해 트랜잭션 병행 수행
병행 제어 기법은 여러 트랜잭션을 병행 수행하면서도 정확한 결과를 얻을 수 있는 직렬 가능성을 보장받기 위해 사용한다. 모든 트랜잭션이 따르는 직렬 가능성이 보장되는 나름의 규약을 정의하고, 트랜잭션들이 이 규약을 따르도록 하는 것이다. 그러므로 트랜잭션 스케줄이 직렬 가능 스케줄인지를 미리 검사할 필요가 없다. 스케줄 내의 모든 트랜잭션이 병행 제어 기법에서 정의한 규약을 따르면 해당 스케줄은 직렬 가능성을 보장할 수 있다.
로킹 기법(가장 많이 사용되는 기법) 개념
로킹(locking) 기법은 병행 수행되는 트랜잭션들이 동일한 데이터에 동시에 접근하지 못하도록 lock과 unlock이라는 두 개의 연산을 이용해 제어한다. 로킹 기법의 기본 원리는 한 트랜잭션이 먼저 접근한 데이터에 대한 연산을 모두 마칠 때까지, 해당 데이터에 다른 트랜잭션이 접근하지 못하도록 상호 배제(mutex)하여 직렬 가능성을 보장하는 것이다.
로킹 기법에서 lock 연산은 트랜잭션이 사용할 데이터에 대한 독점권을 가지기 위해 사용한다. 반대로 unlock 연산은 트랜잭션이 데이터에 대한 독점권을 반납하기 위해 사용한다. 이 두 연산을 이용하여 다른 트랜잭션의 방해를 받지 않고 데이터에 독점적으로 접근할 수 있게 된다.
기본 로킹 규약
로킹 기법을 사용해 트랜잭션이 DB에 있는 데이터에 접근하는 연산을 실행하려면 먼저 해당 데이터에 lock 연산을 실행하여 독점권을 획득해야 한다. 일반적으로는 DB에 있는 데이터에 접근이 필요한 연산은 read 또는 write 연산이다.
다른 트랜잭션이 이미 lock 연산을 실행한 데이터는 다시 lock 연산을 실행시킬 수 없다. 그러므로 트랜잭션이 lock 연산을 통해 독점권을 획득한 데이터에 대한 모든 연산의 수행이 끝나면 unlock 연산을 실행해서 독점권을 반남해야 한다. 그래야 다른 트랜잭션이 해당 데이터에 접근할 수 있다.
로킹 단위
lock 연산은 크게는 전체 DB부터 작게는 DB를 구성하는 속성에 이르기까지 다양한 크기의 데이터를 대상으로 실행할 수 있다. 릴레이션이나 튜플도 lock 연산의 대상이 될 수 있다. 만약 전체 DB에 lock 연산을 실행하면 제어가 간단하다는 장점이 있지만 DB에 하나의 트랜잭션만 수행되므로 병행 수행이라 할 수 없다. 반면, 가장 작은 단위인 속성에 lock 연산을 하면 독점하는 범위가 좁아 많은 수의 트랜잭션이 병행 수행할 수 있다는 장점이 있지만, 제어가 복잡하다는 단점이 있다.
즉, 로킹 단위가 커질수록 병행성이 낮아지지만 제어가 쉽고, 로킹 단위가 작아질수록 제어가 어렵지만 병행성은 높아진다. 그러므로 시스템에 따 적절한 로킹 단위를 선택하는 것이 중요하다.
lock 연산 종류
기본 로킹 기법을 사용하면 병행 수행을 제어하는 목표는 이룰 수 있지만 너무 엄격한 제약으로 인해 어떤 순간이든 데이터에 대한 독점권을 하나의 트랜잭션만 가지게 된다.
write 연산을 실행할 때는 다른 트랜잭션이 방해하지 못하도록 독점권을 가져야 하지만, 데이터를 단순히 읽어오기만 하는 read 연산은 다른 트랜잭션이 같은 데이터에 동시에 read 연산을 동시에 실행할 수 있도록 해서 처리 효율성을 높일 수 있다.
-
공용 lock(shared lock)
: 트랜잭션이 데이터에 대해 공용 lock 연산을 실행하면, 해당 데이터에 read 연산을 실행할 수 있지만 write 연산은 실행할 수 없다. 그리고 해당 데이터에 다른 트랜잭션도 공용 lock 연산을 동시에 실행할 수 있다.
즉, 데이터에 대한 사용권을 여러 트랜잭션이 함께 가질 수 있다. -
전용 lock(exclusive lock)
: 트랜잭션이 데이터에 전용 lock 연산을 실행하면 해당 데이터에 read 연산과 write 연산을 모두 실행할 수 있다. 그러나 해당 데이터에 다른 트랜잭션은 공용이든 전용이든 어떤 lock 연산도 실행할 수 없다.
즉, 전용 lock 연산을 실행한 트랜잭션만 해당 데이터에 대한 독점권을 가질 수 있다.
기본 로킹 규약의 결함
아래 그림은 기본 로킹 규약이 적용된 트랜잭션들의 수행이다.
source: https://blog.daum.net/lkno01/64
그림에서 확인할 수 있듯이 트랜잭션의 직렬 가능성을 보장하려면 기본 로킹 규약으로는 부족하고, lock과 unlock 연산을 실행하는 시점에 대한 새로운 규약이 추가로 필요하다. 이것이 다음 살펴볼 2단계 로킹 규약이다.
2단계 로킹 규약
기본 로킹 규약의 문제를 해결하고 트랜잭션의 직렬 가능성을 보장하기 위해 lock과 unlock 연산의 수행 시점에 대해 새로운 규약을 추가한 것이 2단계 로킹 규약(2PLP)이다. 트랜잭션 스케줄의 모든 트랜잭션이 2단계 로킹 규약을 준수하면 해당 스케줄은 직렬 가능성이 보장된다.
교착상태는 발생할 수 있다.
2단계 로킹 규약을 따르려면 모든 트랜잭션이 lock과 unlock 연산을 다음과 같이 2단계로 나누어 실행해야 한다.
- 확장 단계: 트랜잭션이 lock 연산만 실행할 수 있고, unlock 연산을 실행할 수 없는 단계
- 축소 단계: 트랜잭션이 unlock 연산만 실행할 수 있고, lock 연산은 실행할 수 없는 단계
source: https://blog.daum.net/lkno01/64
트랜잭션이 처음에 수행되면 확장 단계로 들어가 lock 연산만 실행할 수 있다. 그러다 unlock 연산을 실행하면 축소 단계로 들어가 그때부터는 unlock 연산만 실행할 수 있게 된다. (lock -> locK .. unlock -> unlock)
2단계 로킹 규약을 준수하는 트랜잭션은 첫 번째 unlock 연산을 실행하기 전에 필요한 모든 lock 연산을 실행해야 한다.
위 그림은 트랜잭션 T1과 T2 모두 2단계 로킹 규약을 준수하므로 직렬 가능성을 보장할 수 있다. 이 스케줄의 수행 결과는 트랜잭션 T1을 먼저 수행한 후에 트랜잭션 T2를 수행한 직렬 스케줄의 결과와 같다.
교착 상태
2단계 로킹 규약을 적용하면 직렬 가능성을 보장할 수 있지만, 교착 상태가 발생할 수 있다. 트랜잭션들이 상대가 독점하고 있는 데이터에 unlock 연산이 실행되기를 서로 기다리면서 트랜잭션의 수행을 중단하고 있는 상태이다. 교착 상태에 빠지면 트랜잭션들은 더이상 수행을 계속하지 못하고 상대 트랜잭션이 먼저 unlock 연산을 실행해주기를 한없이 기다리게 된다.
예들 들어 트랜잭션 T1과 T2가 모두 데이터 X와 데이터 Y에 접근하려 하는데, T1이 T2가 lock한 데이터X에 접근하려하고, T2는 T1이 lock한 데이터Y에 접근하려 하는 경우 모두 서로의 unlock 만을 기다리는 교착 상태가 된다.
교착 상태는 처음부터 발생하지 않도록 예방하거나, 발생했을 때 빨리 탐지하여 필요한 조치를 취하는 방법으로 해결한다.
