병행 수행
여러 사용자가 데이터베이스를 동시에 공유할 수 있도록 여러 개의 트랜잭션을 동시에 수행하는 것을 의미한다.
여러 트랜잭션이 차례로 번갈아 수행되는 인터리빙 방식으로 수행됨
병행 제어
병행 수행 시 같은 데이터에 접근하여 연산을 실행해도 문제가 발생하지 않고 정확한 수행 결과를 얻을 수 있도록 트랜잭션의 수행을 제어하는 것을 의미한다.
병행 수행 시 발생할 수 있는 문제점
● 갱신 분실
하나의 트랜잭션이 수행한 데이터 변경 연산의 결과를 다른 트랜잭션이 덮어써 변경 연산이 무효화되는 것
여러 트랜잭션이 동시에 수행되더라도 갱신 분실 문제가 발생하지 않고 마치 트랜잭션들을 순차적으로 수행하는 것과 같은 결과 값을 얻을 수 있어야 한다.
● 모순성
하나의 트랜잭션이 여러 개 데이터 변경 연산을 실행할 때 일관성 없는 상태의 데이터베이스에서 데이터를 가져와 연산함으로써 모순된 결과가 발생하는 것
● 연쇄 복귀(cascading rollback)
트랜잭션이 완료되기 전 장애가 발생하여 rollback 연산을 수행하면, 장애 발생 전에 이 트랜잭션이 변경한 데이터를 가져가서 변경 연산을 실행한 다른 트랜잭셔에도 rollback 연산을 연쇄적으로 실행해야 한다는 것
트랜잭션 스케줄
트랜잭션에 포함되어 있는 연산들을 수행하는 순서
● 직렬 스케줄
인터리빙 방식을 사용하지 않고 각 트랜잭션별로 연산들은 순차적으로 실행시키는 것
- 다양한 직렬 스케줄이 만들어질 수 있고, 직렬 스케줄마다 데이터베이스에 반영되는 최종결과가 다를 수는 잇지만 직렬 스케줄의 결과는 모두 정확하다.
- 각 트랜잭션을 독립적으로수행하기 때문에 병행 수행으로 볼 수 없다.
● 비직렬 스케줄
인터리빙 방식을 이용하여 트래잭션들을 병행하여 수행시키는 것
- 트랜잭션을 번갈아 연산을 실행하기 때문에 하나의 트랜잭션이 완료되기 전에 다른 트랜잭션의 연산이 실행될 수 있다.
- 비직렬 스케줄에 따라 병행 수행하면 갱신 분실, 모순성, 연쇄 복귀 등의 문제가 발생할 수 있어 결과의 정확성을 보장할 수 없음
- 다양한 비직렬 스케줄이 만들어질 수 있고 그 중에는 잘못된 결과를 생성하는 것도 있다.
● 직렬 가능 스케줄
직렬 스케줄과 같이 정확한 결과를 생성하는 비직렬 스케줄. 비직렬 스케줄 중에서 수행 결과가 동일한 직렬 스케줄이 있는 것
- 인터리빙 방식으로 병행 수행하면서도 정확한 결과를 얻을 수 있음
- 직렬 가능 스케줄인지 판단하는 것은 간단한 작업이 아니므로 직렬 가능성을 보장하는 병행 제어 기법을 사용하는 것이 일반적이다.
병행 제어 기법
병행 수행하면서도 직렬 가능성을 보장하기 위한 기법
모든 트랜잭션이 준수하면 직렬 가능성이 보장되는 규약을 정의하고, 트랜잭션들이 이 규약을 따르도록 함
병행 제어 기법은 다음과 같다.
● 로킹(locking) 기법
한 트랜잭션이 먼저 접근한 데이터에 대한 연산을 끝낼 때까지는 다른 트랜잭션이 그 데이터에 접근하지 못하도록
상호배제(mutual exclution)함
병행 수행되는 트랜잭션들이 같은 데이터에 동시에 접근하지 못하도록 lock과 unlock 연산을 제어
> lock: 트랜잭션이 데이터에 대한 독점권을 요청하는 연산
> unlock: 트랜잭션이 데이터에 대한 독점권을 반환하는 연산
기본 로킹 규약
- 트랜잭션은 데이터에 접근하기 위해 먼저 lock 연산을 실행해 독점권을 획득한다.
> read 또는 write 연산을 실행하기 전 lock 연산을 실행한다.
- 다른 트랜잭션에 의해 이미 lock 연산이 실행된 데이터에는 다시 lock 연산을 실행할 수 없다.
- 독점권을 획득한 데이터에 대한 모든 연산의 수행이 끝나면 트랜잭션은 unlock 연산을 실행해서 독점권을 반납해야 한다.
로킹 단위
- lock 연산을 실행하는 대상 데이터의 크기
- 전체 데이터베이스부터 릴레이션, 투플, 속성까지도 가능함
- 로킹 단위가 커질수록 병행성은 낮아지지만 제어가 쉽다.
- 로킹 단위가 작아질수록 제어가 어렵지만 병행성은 높아진다.
기본 로킹 규약의 효율성을 높이기 위한 방법
트랜잭션들이 같은 데이터에 동시에 read 연산을 실행하는 것을 허용한다.
lock 연산을 두 가지 종류로 구분하여 사용한다.
> 공용 lock: 트랜잭션이 데이터에 대해 공용 lock 연산을 실행하면, 해당 데이터에 대해 read 연산을 실행할 수 있지만 write 연산을 실행할 수 없다. 그리고 해당 데이터에 다른 트랜잭션도 공용 lock 연산을 동시에 실행할 수 있다.
(데이터에 대한 사용권을 여러 트랜잭션이 함께 가질 수 있음)
> 전용 lock: 트랜잭션이 데이터에 전용 lock 연산을 실행하면 해당 데이터에 read 연산과 write 연산을 모두 실행할 수 없다. 그러나 해당 데이터에 다른 트랜잭션은 공용이든 전용이든 어떤 lock 연산도 실행할 수 없다.
(전용 lock 연산을 실행한 트랜잭션만 해당 데이터에 대한 독점권을 가질 수 있다. )
공유락과 배타락을 사용하는 규칙
공유락(LS, shared lock): 트랜잭션이 읽기를 할 때 사용하는 락
배타락(LX, exclusive lock): 읽고 쓰기를 할 때 사용하는 락
- 데이터에 락이 걸려있지 않으면 트랜잭션은 데이터에 락을 걸 수 있다.
- 트랜잭션이 데이터 X를 읽기만 할 경우 LS(X)를 요청하고, 읽거나 쓰기를 할 경우 LX(X)를 요청한다.
- 트랜잭션이 락을 허용받지 못하면 대기 상태가 된다.
<lock 연산의 양립성>
공용 lock(LS 상태) | 전용 lock(LX 상태) | |
공용 lock(LS 상태) | 가능 | 불가능 |
전용 lock(LX 상태) | 불가능 | 불가능 |
- 서로 다른 트랜잭션이 같은 데이터에 공용 LOCK 연산을 동시에 실행할 수 있다.
- 다른 트랜잭션이 전용 LOCK 연산을 실행한 데이터에는 공용 lock, 전용 lock을 모두 실행 불가하다.
2단계 로킹 규약(2PLP: 2 Phase Locking Protocol)
기본 로킹 규약의 문제를 해결하고 트랜잭션의 직렬 가능성을 보장하기 위해
lock과 unlock 연산의 수행시점에 대한 새로운 규약을 추가한 것
트랜잭션이 lock과 unlock연산을 확장 단계와 축소 단계로 나누어 실행
> 트랜잭션이 처음 수행되면 확장 단계로 들어가 lock 연산만 실행 가능
> unlock 연산을 실행하면 축소 단계로 들어가 unlock 연산만 실행 가능
> 트랜잭션은 첫 번째 unlock 연산 실행 전에 필요한 모든 lock 연산을 실행해야 한다.
확장 단계: 트랜잭션이 lock 연산만 실행할 수 있고, unlock 연산은 실행할 수 없는 단계
축소 단계: 트랜잭션이 unlock연산만 실행할 수 있고, lock 연산은 실행할 수 없는 단계
교착 상태(deadlock)
트랜잭션들이 상대로 독점하고 있는 데이터에 unlock 연산이 실행되기를 서로 기다리면서 트랜잭션의 수행을 중단하고 있는 상태
교착 상태가 발생하지 않도록 예방하거나, 발생 시 빨리 탐지하여 필요한 조치를 취해야 한다.
트랜잭션 고립 수준
<트랜잭션 읽기 쓰기 시나리오>
구분 | 트랜잭션1 | 트랜잭션2 | 발생문제 | 동시접근 |
[상황 1] | 읽기 | 읽기 | 읽음(읽기만 하면 아무 문제가 없음) | 허용 |
[상황 2] | 읽기 | 쓰기 | 오손 읽기, 반복불가능 읽기, 유령 데이터 읽기 | 허용 혹은 불가 선택 |
[상황 3] | 쓰기 | 쓰기 | 갱신손실(절대 허용하면 안됨) | 허용불가(LOCK을 이용) |
● 오손 읽기
읽기 작업을 하는 트랜잭션1이 쓰기 작업을 하는 트랜잭션 2가 작업한 중간 데이터를 읽기 때문에 생기는 문제
작업 중인 트랜잭션 2가 어떤 이유에서 작업을 철회(ROLLBACK)할 경우 트랜잭션 1은 무효가 된 데이터를 읽게 되고 잘못된 결과를 도출하는 현상
● 반복불가능 읽기
트랜잭션 1이 데이터를 읽고 트랜잭션 2가 데이터를 쓰고(갱신, UPDATE) 트랜잭션 1이 다시 한 번 데이터를 읽을 때 생기는 문제
트랜잭션 1이 읽기 작업을 다시 한 번 반복할 경우 이전의 결과와 다른 결과가 나오는 현상
T1이 데이터를 일고 작업하던 중 T2가 데이터를 변경하면 T1은 변경한 데이터를 보고 다시 한 번 작업을 한다.
오손 읽기와 달리 이번에는 T2가 COMMIT을 했기 때문에 틀린 데이터는 아니다. 하지만 T1 입장에서는 같은 SQL문이 다른 결과를 도출한다.
● 유령 데이터 읽기
트랜잭션이 1이 데이터를 일고 트랜잭션 2가 데이터를 쓰고(삽입) 트랜잭션 1이 다시 한 번 데이터를 읽을 때 생기는 문제. 트랜잭션 1이 읽기 작업을 다시 한 번 반복할 경우 이전에 없던 데이터(유령 데이터)가 나타는 현상
트랜잭션 고립 수준 명령어(transaction isolation level instruction)
DBMS는 트랜잭션을 동시에 실행시키면서 락보다 더 완화된 방법으로 문제를 해결하기 위해 제공하는 명령어
오손읽기 | 반복 불가능 읽기 | 유령데이터 읽기 | |
READ UNCOMMITTED | 가능 | 가능 | 가능 |
READ COMMITTED | 불가능 | 가능 | 가능 |
REPEATABLE READ | 불가능 | 불가능 | 가능 |
SERIALIZABLE | 불가능 | 불가능 | 불가능 |
● READ UNCOMMITTED(Level = 0)
고립 수준이 가장 낮은 명령어로, 자신의 데이터에 아무런 공유락을 걸지 않는다.
(배타락은 갱신 손실 문제때문에 걸어야 한다). 또한 다른 트랜잭션에 공유락과 배타락이 걸린 데이터를 대기하지 않고 읽는다. 심지어 다른 트랜잭션이 COMMIT하지 않은 데이터도 읽을 수 있다. 그 때문에 오손(dirty) 페이지의 데이터를 일게 된다. 이 명령어는 SELECT 질의의 대상이 되는 테이블에 댇해서 락을 설정하지 않는 것(NOLOCK)과 같다.
● READ COMMITED(Level = 1)
오손(dirty)페이지의 참조를 피하기 위해 자신의 데이터를 읽는 동안 공유락을 걸지만 트랜잭션이 끝나기 전이라도 해지가능
다른 트랜잭션 데이터는 락 호환성 규칙에 따라 진행한다. 이 옵션은 오라클의 기본 설정으로 아무런 설정을 하지 않으면 READ COMMITTED 방식으로 수행된다.
● REPEATABLE READ(Level = 2)
자신의 데이터에 설정된 공유락과 배타락을 트랜잭션이 종료할 때까지 유지하여 다른 트랜잭션이 자신의 데이터를 갱신할 수 없도록 한다.
다른 트랜잭션 데이터는 락 호환성 규칙에 따라 진행한다. 다른 고립화 수준에 비해 데이터의 동시성이 낮아 특별하지 않은 상황이라면 사용하지 않는 것이 좋다.
● SERIALIZABLE(Level = 3)
고립 수준이 가장 높은 명령어로, 실행 중인 트랜잭션은 다른 트랜잭션으로부터 완벽하게 분리된다.
데이터 집합에 범위를 지어 잠금을 설정할 수 있기 때문에 다른 사용자가 데이터를 변경할려고 할 때 트랜잭션을 완벽하게 분리할 수 있다. 이 명령어는 네가지 고립화수준 중 제한이 가장 심하고 데이터의 동시성도 낮다. 이 명령어는 SELECT 질의의 대상이 되는 테이블에 미리 배타락을 설정한 것과 같은 효과를 낸다.
'데이터베이스' 카테고리의 다른 글
데이터베이스(회복과 병행 제어) (0) | 2021.05.29 |
---|---|
데이터베이스 정규화 총정리 (0) | 2021.05.21 |
데이터베이스 언어 SQL-2 (0) | 2021.04.19 |
데이터베이스 언어 SQL (0) | 2021.04.19 |
관계 데이터 연산 (0) | 2021.04.19 |