본문 바로가기
데이터베이스

[데이터베이스론] 10장. 회복과 병행제어

by CuckooBird 2024. 6. 7.

트랜잭션

  • 트랜잭션
    • 하나의 작업을 수행하는데 필요한 데이터베이스 연산들을 모아놓은 것
    • 작업 수행에 필요한 SQL 문들의 모임
    • 특히, 데이터베이스를 변경하는 INSERT, DELETE, UPDATE 문의 실행을 관리
    • 논리적인 작업의 단위
    • 장애 발생 시 복구 작업이나 병행 제어 작업을 위한 중요한 단위로 사용됨
    • 데이터베이스의 무결성과 일관성을 보장하기 위해 작업 수행에 필요한 연산들을 하나의 트랜잭션으로 제대로 정의하고 관리해야 함
  • 트랜잭션의 특성- ACID 특성
    • Atomicity(원자성): 트랜잭션의 연산들이 모두 정상적으로 실행되거나 하나도 실행되지 않아야 하는 all-or-nothing 방식을 의미 → 회복 기능 필요
    • Consistency(일관성): 트랜잭션이 성공적으로 수행된 후에도 데이터베이스가 일관된 상태를 유지해야 함을 의미 → 병행 제어 기능 필요
    • Isolation(격리성): 수행 중인 트랜잭션이 완료될 때까지 다른 트랜잭션들이 중간 연산 결과에 접근할 수 없음을 의미 → 병행 제어 기능 필요
    • Durability(지속성): 트랜잭션이 성공적으로 완료된 후 데이터베이스에 반영한 수행 결과는 영구적이어야 함을 의미 → 회복 기능 필요
  • 트랜잭션의 주요 연산
    • commit 연산: 트랜잭션이 성공적으로 수행되었음을 선언(작업 완료) → 트랜잭션의 수행 결과가 DB에 반영되고 일관된 상태를 지속적으로 유지하게 됨
    • rollback 연산: 트랜잭션을 수행하는 데 실패했음을 선언(작업 취소) → 트랜잭션이 지금까지 실행한 연산의 결과가 취소되고 DB가 트랜잭션 수행 전의 일관된 상태로 되돌아

  • 트랜잭션의 상태
    • active(활동): 트랜잭션이 수행되기 시작하여 현재 수행 중인 상태
    • partially committed(부분 완료): 트랜잭션의 마지막 연산이 실행을 끝낸 직후의 상태
    • committed(완료): 트랜잭션이 성공적으로 완료되어 commit 연산을 실행한 상태
    • failed(실패): 장애가 발생하여 트랜잭션의 수행이 중단된 상태
    • aborted(철회): 트랜잭션의 수행 실패로 rollback 연산을 실행한 상태 → aborted로 종료된 트랜잭션은 상황에 따라 다시 수행되거나 폐기됨

장애와 회복

  • failure (장애): 시스템이 제대로 동작하지 않는 상태
  • failure의 유형
    • 트랜잭션 장애: 트랜잭션 수행 중 오류가 발생하여 정상적으로 수행을 계속할 수 없는 상태
      → 원인: 트랜잭션의 논리적 오류, 잘못된 데이터 입력, 시스템 자원의 과다 사용 요구, 처리 대상 데이터의 부재 등
    • 시스템 장애: 하드웨어의 결함으로 정상적으로 수행을 계속할 수 없는 상태
      → 원인: 하드웨어 이상으로 메인 메모리에 저장된 정보가 손실되거나 교착 상태가 발생한 경우 등
    • 미디어 장애: 디스크 장치의 결함으로 디스크에 저장된 데이터베이스의 일부 혹은 전체가 손상된 상태
      → 원인: 디스크 헤드의 손상이나 고장 등
  • 저장 장치의 종류
    • 휘발성(voatile) 저장 장치: 장애가 발생하면 저장된 데이터가 손실됨 (ex. 메인메모리 등)
    • 비휘발성(nonvolatile) 저장 장치: 장애가 발생해도 저장된 데이터가 손실되지 않음. 단, 디스크 헤더 손상 같은 저장 장치 자체에 이상이 발생하면 데이터가 손실될 수 있음. (ex. 디스크, 자기 테이프, CD/DVD)
    • 안정(stable) 저장 장치: 비휘발성 저장 장치를 이용해 데이터 복사본 여러 개를 만드는 방법으로, 어떤 장애가 발생해도 데이터가 손실되지 않고 데이터를 영구적으로 저장 할 수 있음
  • 디스크와 메인메모리 간 데이터 이동 연산
    • 트랜잭션이 DB의 데이터를 처리하기 위해서는 데이터를 디스크에서 메인 메모리로 가져와 처리한 다음 그 결과를 디스크로 보내는 작업이 필요함
    • 블록(block) 단위로 실행 : 디스크 블록 - 디스크의 블록  / 버퍼 블록 - 메인 메모리의 블록
    • input 연산 / output 연산
      • input(X) : 디스크 블록 → 버퍼 블록
      • output(X) : 버퍼 블록 →  디스크 블록 
  • 메인 메모리와 변수 간의 데이터 이동 연산
    • 응용 프로그램에서 트랜잭션의 수행을 지시하면 메인메모리 버퍼 블록에 있는 데이터를 프로그램의 변수로 가져오고, 데이터 처리 결과를 저장한 변수 값을 메인 메모리 버퍼 블록으로 옮기는 작업이 필요
    • read 연산 / write 연산
      • read(X) : 버퍼 블록 → 프로그램의 변수
      • write(X) : 프로그램의 변수 → 버퍼 블록

  • recovery (회복)
    • failure가 발생했을 때 DB를 failure가 발생하기 전의 일관된 상태로 복구시키는 것
    • recovery manager(회복 담당자)가 담당 → failure 탐지 및 recovery 기능 제공
  • 회복을 위해 데이터베이스 복사본을 만드는 방법 - DB recovery 핵심 원리: 데이터 중복
    • dump: 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법
    • log: 데이터베이스에서 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경한 이후의 값을 별도의 파일에 기록하는 방법
  • recovery를 위한 기본 연산
    • redo(재실행): 가장 최근에 저장한 DB 복사본을 가져온 후 log를 통해 복사본이 만들어진 이후에 실행된 모든 변경 연산을 재실행하여 장애가 발생하기 직전의 DB 상태로 복구
    • undo(취소): log를 이용해 지금까지 실행된 모든 변경 연산을 취소하여 DB를 원래의 상태로 복구
  • 로그 파일
    • 데이터를 변경하기 이전의 값과 변경한 이후의 값을 기록한 파일
    • 레코드 단위로 트랜잭션의 수행과 함께 기록됨
  • 회복 기법
    • 로그 회복 기법 - 즉시 갱신(immediate update) 회복 기법
      • 트랜잭션 수행 중에 데이터 변경 연산의 결과를 DB에 즉시 반영
      • 장애 발생에 대비하기 위해 데이터 변경에 대한 내용을 로그 파일에 기록
        → 데이터 변견 연산이 실행되면, 로그 파일에 로그 레코드를 먼저 기록한 다음 DB에 변경 연산을 반영
      • 장애 발생 시점에 따라 redo나 undo 연산을 실행해 DB를 복구
        • 트랜잭션이 완료되기 전 장애가 발생한 경우: undo 연산
        • 트랜잭션이 완료된 후 장애가 발생한 경우: redo 연산
    • 로그 회복 기법 - 지연 갱신(deferred update) 회복 기법
      • 트랜잭션 수행 중에 데이터 변경 연산의 결과를 log에만 기록해두고, 트랜잭션이 부분 완료된 후에 log에 기록된 내용을 이용해 DB에 한번에 반영
      • 트랜잭션 수행 중에 장애가 발생할 경우 log에 기록된 내용을 버리기만 하면 DB가 원래 상태를 그대로 유지하게 됨
      • undo 연산은 필요 없고 redo 연산만 사용
      • log 레코드에는 변경 이후의 값만 기록하면 됨
        • 트랜잭션이 완료되기 전에 장애가 발생한 경우: 로그 내용을 무시하고 버림
        • 트랜잭션이 완료된 후에 장애가 발생한 경우: redo 연산 실행
    • 검사 시점 회복 기법
      • log 기록을 이용하되, 일정 시간 간격으로 검사 시점(check point)을 만듦
        → 검사 시점이 되면 모든 로그 레코드를 로그 파일에 기록하고, 데이터 변경 내용을 DB에 반영한 후 검사 시점을 표시하는 <checkpoint L> 로그 레코드를 로그 파일에 기록함
        (<checkpoint L>에서 L은 현재 실행되고 있는 트랜잭션의 리스트)
      • 장애 발생 시 가장 최근 검사 시점 이후의 트랜잭션에만 회복 작업 수행
        → 가장 최근의 <checkpoint L>로그 레코드 이후 기록에 대해서만 회복 작업 수행
        (회복 작업은 즉시 갱신 회복 기법 / 지연 갱신 회복 기법을 통해 수행)
      • 로그 전체를 대상으로 회복 기법을 적용할 때 발생할 수 있는 비효율성의 문제를 해결 → 시간 단축
    • 미디어 회복 기법
      • 디스크에 발생할 수 있는 장애에 대비한 회복 기법 → dump 이용: 전체 DB의 내용을 일정 주기로 다른 안전한 저장 장치에 복사
      • 디스크 장애 발생 시: 가장 최근에 복사해둔 dump를 이용해 장애 발생 이전의 DB 상태로 복구하고 필요에 따라 redo 연산


병행 제어

  • 병행 수행(concurrency)
    • 여러 사용자가 DB를 동시 공유할 수 있도록 여러 개의 트랜잭션을 동시에 수행하는 것을 의미
    • 여러 트랜잭션이 차례로 번갈아 수행되는 interleaving 방식으로 진행됨
  • 병행 제어(concurrency control) 또는 동시성 제어
    • concurrency 수행 시 같은 데이터에 접근하여 연산을 실행해도 문제가 발생하지 않고 정확한 수행 결과를 얻을 수 있도록 트랜잭션의 수행을 제어하는 것을 의미
  • 병행 수행 시 발생할 수 있는 문제점: loss update(갱신 분실), inconsistency(모순성), cascading rollback(연쇄 복귀)
    • loss update (갱신 분실)
      • 하나의 트랜잭션이 수행한 데이터 변경 연산의 결과를 다른 트랜잭션이 덮어써 변경 연산이 무효화되는 것
    • inconsistency (모순성)
      • 하나의 트랜잭션이 여러 개 데이터 변경 연산을 실행할 때 일관성 없는 상태의 DB에서 데이터를 가져와 연산함으로써 모순된 결과가 발생하는 것
    • cascading rollback (연쇄 복귀)
      • 트랜잭션이 완료되기 전 장애가 발생하여 rollback 연산을 수행하면, 장애 발생 전에 이 트랜잭션이 변경한 데이터를 가져가서 변경 연산을 실행한 다른 트랜잭션에도 rollback 연산을 연쇄적으로 실행해야 한다는 것
      • 장애가 발생한 트랜잭션이 rollback 연산을 실행하기 전에, 변경한 데이터를 가져가 사용한 다른 트랜잭션이 수행을 완료해버리면 rollback 연산을 실행 할 수 없어 문제가 발생함
  • 트랜잭션 스케줄: 트랜잭션에 포함되어 있는 연산들을 수행하는 순서
    • 직렬 스케줄(serial schedule): interleaving 방식을 이용하지 않고 각 트랜잭션별로 연산들을 sequential하게 실행시키는 것
      → 정확한 결과를 보임. but, concurrency라고 볼 수 없음
    • 비직렬 스케줄(nonserial schedule): interleaving 방식을 이용하여 트랜잭션들을 병행해서 수행시키는 것
      → loss update, inconsistency, cascading rollback 등의 문제 발생 가능성 있음. 정확성을 보장할 수 없음
    • 직렬 가능 스케줄(serializable schedule): 직렬 스케줄과 같이 정확한 결과를 생성하는 비직렬 스케줄
      → interleaving 방식으로 병행 수행하면서도 정확한 결과를 얻을 수 있음. but, 간단한 작업이 아님.
  • 병행 제어(concurrency control) 기법
    • 의미: 병행 수행하면서도 직렬 가능성을 보장하기 위한 기법
    • 모든 트랜잭션이 준수하면 직렬 가능성이 보장되는 규약을 정의하고, 트랜잭션들이 이 규약을 따르도록 함
    • 대표적인 병행 제어 기법: locking(로킹) 기법
  • locking (로킹) 기법
    • 기본 원리: 한 트랜잭션이 먼저 접근한 데이터에 대한 연산을 끝낼 때까지는 다른 트랜잭션이 그 데이터에 접근하지 못하도록 상호 배제(mutual exclusion)함
    • 방법
      • 병행 수행되는 트랜잭션들이 같은 데이터에 동시에 접근하지 못하도록 lock과 unlock 연산을 이용해 제어
      • lock: 트랜잭션이 데이터에 대한 독점권을 요청하는 연산
      • unlock: 트랜잭션이 데이터에 대한 독점권을 반환하는 연산
    • 로킹 단위
      • lock 연산을 실행하는 대상 데이터의 크기
      • 로킹 단위가 커질수록 병행성은 낮아지지만 제어가 쉬움
      • 로킹 단위가 작아질수록 제어가 어렵지만 병행성은 높아짐
    • 기본 로킹 규약의 효육성을 높이기 위한 방법
      • 트랜잭션들이 같은 데이터에 동시에 read 연산을 실행하는 것을 허용 → lock 연산을 두 가지 종류로 구분하여 사용
        • shared(공용) lock: 트랜잭션이 데이터에 대해 공용 lock 연산을 실행하면, 해당 데이터에 read 연산을 실행할 수 있지만 write 연산은 실행할 수 없다. 그리고 해당 데이터에 다른 트랜잭션도 공용 lock 연산을 동시에 실행할 수 있다. (데이터에 대한 사용권을 여러 트랜잭션이 함께 가질 수 있음)
        • exclusive(전용) lock: 트랜잭션이 데이터에 전용 lock 연산을 실행하면 해당 데이터에 read 연산과 write 연산을 모두 실행할 수 있다. 그러나 해당 데이터에 다른 트랜잭션은 공용이든 전용이든 어떤 lock 연산도 실행할 수 없다. (전용 lock연산을 실행한 해당 데이터에 대한 독점권을 가질 수 있음)
    • 2단계 로킹 규약(2PLP; 2 Phase Locking Protocol)
      • 기본 로킹 규약의 문제를 해결하고 트랜잭션의 직렬 가능성을 보장하기 위해 lock과 unlock 연산의 수행 시점에 대한 새로운 규약을 추가한 것
      • 방법
        • 트랜잭션이 lock과 unlock 연산을 확장 단계과 축소 단계로 나누어 실행
          • 확장 단계: 트랜잭션이 lock 연산만 실행할 수 있고, unlock 연산은 실행할 수 없는 단계
          • 축소 단계: 트랜잭션이 unlock 연산만 실행할 수 있고, lock 연산은 실행할 수 없는 단계
            틀릴 수도 있습니다. 정확히 아시는 분들은 댓글 남겨주시면 감사하겠습니다.
  • 교착 상태(deadlock)
    • 트랜잭션들이 상대가 독점하고 있는 데이터에 unlock 연산이 실행되기를 서로 기다리면서 트랜잭션의 수행을 중단하고 있는 상태
    • 교착 상태가 발생하지 않도록 예방하거나, 발생 시 빨리 탐지하여 필요한 조치를 취해야 함