데이터베이스 회복과 병행 제어
트랜잭션
개념
하나의 작업을 수행하는데 필요한 데이터베이스 연산들을 모아놓은 것
작업 수행에 필요한 SQL문들의 모임(특히 DB를 변경하는 INSERT, DELETE, UPDATE문 관리)
논리적인 작업의 단위
장애 발생 시 복구 작업이나 병행 제어 작업을 위한 중요한 단위로 사용된다.
데이터베이스 무결성과 일관성을 보장하기 위해 작업 수행에 필요한 연산들을 하나의 트랜잭션으로 제대로 정의, 관리해야 한다.
특성
= ACID 특성
원자성, 일관성, 격리성, 지속성
원자성(atomicity)
트랜잭션의 연산들이 모두 정상적으로 실행되거나, 하나도 실행되지 않아야 하는 all-or-nothing 방식을 의미
트랜잭션 수행 도중 장애 발생 → 지금까지 실행한 연산 처리를 모두 취소, 데이터베이스를 트랜잭션 작업 전 상태로 되돌려야 함
→ 원자성 보장을 위해 장애 발생 시 회복 기능 필요
일관성(consistency)
트랜잭션이 성공적으로 수행된 후에도 데이터베이스가 일관된 상태를 유지해야 함을 의미
격리성(isolation)
수행 중인 트랜잭션이 완료될 때까지 다른 트랜잭션들이 중간 연산 결과에 접근할 수 없음을 의미
격리성 보장을 위해서 여러 트랜잭션이 동시에 수행되더라도 마치 순서대로 하나씩 수행되는 것처럼 정확하고 일관된 결과를 얻을 수 있도록 제어하는 기능 필요
지속성(durability)
트랜잭션이 성공적으로 완료된 후 데이터베이스에 반영한 수행 결과는 영구적이어야 함을 의미
지속성 보장을 위해 발생 시 회복 기능 필요
트랜잭션의 4가지 특성을 보장하기 위해 필요한 기능
트랜잭션의 주요 연산
commit 연산
트랜잭션이 성공적으로 수행되었음을 선언(작업 완료)
commit 연산이 실행되면 트랜잭션 수행 결과가 DB에 반영되고 일관된 상태를 지속적으로 유지하게 된다.
rollback 연산
트랜잭션을 수행하는 데 실패했음을 선언(작업 취소)
rollback 연산이 실행되면 트랜잭션이 지금까지 실행한 연산의 결과가 취소되고 DB가 트랜잭션 수행 전의 일관된 상태로 되돌아간다.
트랜잭션의 상태
활동(active) 상태
트랜잭션이 수행되기 시작하여 현재 수행 중인 상태
부분 완료(partially committed) 상태
트랜잭션의 마지막 연산이 실행을 끝낸 직후의 상태
완료(committed) 상태
트랜잭션이 성공적으로 완료되어 commit 연산을 실행한 상태. 최종 결과를 DB에 반영함
실패(failed) 상태
장애가 발생하여 트랜잭션의 수행이 중단된 상태
철회(aborted) 상태
트랜잭션 수행 실패로 rollback 연산을 실행한 상태. 철회 상태로 종료된 트랜잭션은 상황에 따라 다시 수행되거나 폐기됨
장애와 회복
장애(failure)
시스템이 제대로 동작하지 않는 상태
데이터베이스를 저장하는 저장장치의 종류
트랜잭션 수행을 위해 필요한 데이터 연산
디스크 ↔ 메인 메모리 데이터 이동 연산: input/output
일반적으로 DB는 비휘발성 저장 장치인 디스크에 상주하므로, 트랜잭션이 DB의 데이터를 처리하기 위해서는 데이터를 디스크에서 메인 메모리로 가져와 처리 후, 그 결과를 디스크로 보내는 작업이 필요하다.
블록 단위로 수행됨(디스크 블록/버퍼 블록)
메인 메모리 ↔ 프로그램 변수 데이터 이동 연산: read/write
응용 프로그램에서 트랜잭션의 수행을 지시하면 메인 메모리 버퍼 블록에 있는 데이터를 프로그램의 변수로 가져오고, 데이터 처리 결과를 저장한 변수 값을 메인 메모리 버퍼 블록으로 옮기는 작업이 필요하다.
회복(recovery)
장애가 발생했을 때 데이터베이스를 장애가 발생하기 전의 일관된 상태로 복구시키는 것
트랜잭션의 특성을 보장하고, DB를 일관된 상태로 유지하기 위해 필수적인 기능
회복 관리자가 담당하여, 장애 발생을 탐지하고, 장애가 탐지되면 DB 복구 기능을 제공한다.
회복을 위해 데이터베이스 복사본 생성
데이터베이스 회복의 핵심 원리 = 데이터 중복!
회복을 위한 기본 연산
로그 파일
데이터 변경 전 값과 변경 후 값을 기록한 파일
레코드 단위로 트랜잭션 수행과 함께 기록된다.
회복 기법
1. 로그 회복 기법 - 즉시 갱신 회복 기법
트랜잭션 수행 중에 데이터 변경 연산 결과를 데이터베이스에 즉시 반영
장애 발생에 대비하기 위해 데이터 변경에 대한 내용을 로그 파일에 기록
데이터 변경 연산이 실행되면, 로그 파일에 로그 레코드를 먼저 기록한 다음 데이터베이스에 변경 연산을 반영
장애 발생 시점에 따라 redo나 undo 연산으로 데이터베이스를 복구
- 트랜잭션 완료 전 장애 발생 시 = 로그 파일에 <Ti, start>는 존재하지만 <Ti, commit>은 존재하지 않는 상태: undo 연산
- 트랜잭션 완료 후 장애 발생 시 = 로그 파일에 <Ti, start>와 <Ti, commit> 모두 존재하는 상태: redo 연산
2. 로그 회복 기법 - 지연 갱신 회복 기법
트랜잭션 수행 중에 데이터 변경 연산의 결과를 로그에만 기록해두고, 트랜잭션이 부분 완료된 후에 로그에 기록된 내용을 이용해 데이터베이스에 한번에 반영
트랜잭션 수행 중 장애가 발생할 경우, 로그에 기록된 내용을 버리기만 하면 DB가 원래 상태를 그대로 유지하게 됨
undo 연산이 필요 없고, redo 연산만 사용
- 트랜잭션 완료 전 장애 발생 시: 로그 내용을 무시하고 버림
- 트랜잭션 완료 후 장애 발생 시: redo 연산
로그 레코드에는 변경 후 값만 기록하면 됨: <Ti, X, new_value>
3. 검사 시점 회복 방법
로그 기록을 사용하되, 일정 시간 간격으로 검사 시점(checkpoint)을 만듦
검사 시점이 되면 모든 로그 레코드를 로그 파일에 기록하고, 데이터 변경 내용을 데이터베이스에 반영한 후, 검사 시점을 표시하는 <checkpoint L> 로그 레코드를 로그 파일에 기록(L은 현재 실행 중인 트랜잭션 리스트)
장애 발생 시 가장 최근 검사 시점 이후의 트랜잭션에만 회복 작업 수행; 회복 작업은 로그 회복 기법 중 하나로 사용
→ 로그 전체를 대상으로 회복 기법을 적용할 때 발생할 수 있는 비효율성 문제 해결
검사 시점으로 작업 범위가 정해지므로 불필요한 회복 작업이 없어 시간이 단축된다.
4. 미디어 회복 기법
디스크에 발생할 수 있는 장애에 대비한 회복 기법
덤프(복사본) 이용 → 전체 데이터베이스의 내용을 일정 주기마다 다른 안전한 저장 장치에 복사
디스크 장애 발생 시: 가장 최근에 복사해둔 덤프를 이용해 장애 발생 이전의 DB 상태로 복구, 필요에 따라 redo 연산 수행
병행 제어
병행 수행(concurrency): 여러 사용자가 데이터베이스를 동시 공유할 수 있도록 여러 개의 트랜잭션을 동시에 수행하는 것
여러 트랜잭션이 차례로 번갈아 수행되는 인터리빙(interleaving) 방식으로 진행
병행 제어(concurrency control) = 동시성 제어: 병행 수행 시 같은 데이터에 접근해 연산을 수행해도 문제가 발생하지 않고, 정확한 수행 결과를 얻을 수 있도록 트랜잭션 수행을 제어하는 것
병행 수행 시 발생할 수 있는 문제점
갱신 분실(lost update)
하나의 트랜잭션이 수행한 데이터 변경 연산 결과를 다른 트랜잭션이 덮어써 변경 연산이 무효화되는 것
여러 트랜잭션이 동시에 수행되더라도 갱신 분실 문제가 발생하지 않고, 마치 트랜잭션들을 순차 수행한 것과 같은 결과 값을 얻을 수 있어야 한다.
모순성(inconsistency)
하나의 트랜잭션이 여러 개 데이터 변경 연산을 실행할 때 일관성 없는 상태의 데이터베이스에서 데이터를 가져와 연산함으로써 모순된 결과가 발생하는 것
연쇄 복귀(cascading rollback)
트랜잭션이 완료되기 전 장애가 발생하여 rollback 연산을 수행하면, 장애 발생 전에 이 트랜잭션이 변경한 데이터를 가져가, 변경 연산을 실행한 다른 트랜잭션에도 rollback 연산을 연쇄적으로 실행해야 한다는 것
트랜잭션 스케줄
트랜잭션에 포함되어 있는 연산들을 수행하는 순서
1. 직렬 스케줄(serial schedule)
인터리빙 방식을 이용하지 않고, 각 트랜잭션별로 연산들을 순차적으로 실행시키는 것
다른 트랜잭션의 방해를 받지 않고 독립적으로 수행되어 항상 모순 없는 정확한 결과를 얻게 된다.
다양한 직렬 스케줄이 만들어질 수 있고, 결과는 모두 정확하다.
But 병행 수행으로 볼 수 없음!
2. 비직렬 스케줄(nonserial schedule)
인터리빙 방식을 이용하여 트랜잭션을 병행 수행하는 것
트랜잭션이 번갈아 연산 실행 → 한 트랜잭션이 완료되기 전에 다른 트랜잭션의 연산 실행 가능
갱신 분실, 모순성, 연쇄 복귀 등의 문제가 발생할 수 있어 결과의 정확성 보장 불가
다양한 비직렬 스케줄이 만들어질 수 있고, 그중 잘못된 결과를 생성하는 것도 존재한다.
3. 직렬 가능 스케줄
직렬 스케줄에 따라 수행한 것과 같이 정확한 결과를 생성하는 비직렬 스케줄
비직렬 스케줄 중에서 수행 결과가 동일한 직렬 스케줄이 있는 것
인터리빙 방식으로 병행 수행하면서도 정확한 결과를 얻을 수 있음
직렬 가능 스케줄인지 판단하는 것의 어려움 → 직렬 가능성을 보장하는 병행 제어 기법을 사용하는 것이 일반적
병행 제어 기법
병행 수행하면서도 직렬 가능성을 보장하기 위한 기법
모든 트랜잭션이 준수하면 직렬 가능성이 보장되는 규약을 정의하고, 트랜잭션들이 이 규약을 따르도록 한다.
로킹(locking) 기법
기본 원리: 한 트랜잭션이 먼저 접근한 데이터에 대한 연산을 끝낼 때까지는 다른 트랜잭션이 그 데이터에 접근하지 못하도록 상호 배제(mutual exclusion)한다.
방법: 병행 수행되는 트랜잭션들이 같은 데이터에 동시에 접근하지 못하도록 lock과 unlock 연산을 이용해 제어
- lock: 트랜잭션이 데이터에 대한 독점권을 요청하는 연산
- unlock: 트랜잭션이 데이터에 대한 독점권을 반환하는 연산
기본 로킹 규약:
트랜잭션이 데이터에 접근하기 위해 먼저 read나 write 실행 전 lock 연산으로 독점권 획득
다른 트랜잭션에 의해 lock 연산이 실행된 데이터에는 lock 연산 실행 불가
독점권을 획득한 데이터에 대한 모든 연산 수행이 끝난 뒤 unlock 연산을 실행해 독점권을 반납
로킹 단위:
lock 연산을 실행하는 대상 데이터의 크기
전체 DB부터 릴레이션, 투플, 속성까지도 가능
로킹 단위가 커질수록 병행성은 낮아지지만 제어가 쉽고, 단위가 작아질수록 제어는 어렵지만 병행성은 높아진다.
기본 로킹 규약의 효율성을 높이기 위한 방법
트랜잭션들이 같은 데이터에 동시에 read 연산을 실행하는 것을 허용
서로 다른 트랜잭션이 같은 데이터에 공용 lock 연산만 동시에 실행 가능
전용 lock을 실행한 데이터에는 모두 실행 불가
기본 로킹 규약으로 직렬 가능성이 보장되지 않는 스케줄 예
트랜잭션 T1이 너무 빨리 unlock 연산을 실행하여 트랜잭션 T2가 일관성 없는 데이터에 접근하게 됨
T1의 데이터 Y에 대한 연산이 끝나기 전에 T2에서 Y에 대한 연산을 수행해 Y의 데이터 값이 일관성을 잃게 됨
2단계 로킹 규약(2PLP; 2 Phase Locking Protocol)
기본 로킹 규약의 문제를 해결하고 트랜잭션의 직렬 가능성을 보장하기 위해 lock과 unlock 연산의 수행 시점에 대한 새로운 규약을 추가한 것
방법:
트랜잭션이 lock과 unlock 연산을 확장 단계와 축소 단계로 나누어 실행
트랜잭션 처음 실행 시 확장 단계로 들어가 lock 연산만 실행 가능
unlock 연산을 실행하면 축소 단계로 들어가 unlock 연산만 실행 가능
트랜잭션은 첫번째 unlock 연산 실행 전에 필요한 모든 lock 연산을 실행해야 함
트랜잭션 시작 → 확장 단계 → lock 연산(1) → lock 연산(2) → unlock 연산(2) → 축소 단계 → unlock 연산(1) → 완료
즉, 한 트랙잭션 안에서 lock-unlock 과정이 교차되지 않고 중첩되어 발생하도록 제한함
교착 상태(deadlock)
트랜잭션들이 상대가 독점하고 있는 데이터에 unlock 연산이 실행되기를 서로 기다리면서 트랜잭션 수행을 중단하고 있는 상태
→ 발생하지 않도록 예방하거나, 빨리 탐지해 조치해야 함
Time 8: T1이 X를 읽고자 하지만 T2의 read_lock(X)로 읽지 못하고 중단됨
출처: 데이터베이스 개론 2판 김연희 저, MySQL로 배우는 데이터베이스 개론과 실습 박우창 외2