데이터베이스 (9) 회복과 병행 제어

트랜잭션

트랜잭션의 개념

• 트랜잭션 : 하나의 작업을 수행하기 위해 필요한 데이터베이스의 연산들을 모아놓은 것
  • 데이터베이스에서 논리적인 작업의 단위
  • 장애가 발생했을 때 데이터를 복구하는 작업의 단위
  • 데이터베이스 회복과 병행 제어가 가능해 항상 정확하고 일관된 상태를 유지할 수 있게 함
  • 트랜잭션의 모든 명령문이 완벽하게 처리되거나 / 하나도 처리되지 않아야 데이터베이스가 모순이 없는 일관된 상태를 유지
  • 연산들을 하나의 트랜잭션으로 제대로 정의하고 관리

트랜잭션의 특성 (ACID)

원자성 (Atomicity)

• 트랜잭션을 구성하는 연산들이 모두 정상적으로 실행되거나 하나도 실행되지 않아야한다
• all or nothing
• 장애로 인해 작업을 완료하지 못했다면 지금까지 실행한 연산 모두 처리 취소 후 작업 전 상태로 되돌림
• 일부만 처리 X

일관성 (Consistency)

• 트랜잭션이 성공적으로 수행된 후에도 데이터베이스가 일관성 있는 상태를 유지해야 함
• 트랜잭션 수행 중 일시적으로 일관되지 않을 수도 있지만 완료 후에는 일관된 상태 유지

격리성 (Isolation)

• 트랜잭션 수행 중 완료될 때까지 트랜잭션이 생성한 중간 연산 결과에 다른 트랜잭션들이 접근할 수 없음
• 일반적으로 여러 트랜잭션 동시 수행, 각 트랜잭션은 독립 수행, 트랜잭션들의 중간 연산 결과에 서로 접근 안됨

지속성 (Durability)

• 트랜잭션이 성공적으로 완료된 후 데이터베이스에 반영한 수행 결과는 어떠한 경우에도 손실되지 않고 영구적이어야 함
• 장애가 발생하더라도 작업 결과는 데이터베이스에 그대로 남아있어야

트랜잭션의 특성을 지원하는 DBMS의 기능

• (회복기능 -> 원자성), (병행 제어 기능 -> 일관성), (병행 제어 기능 -> 격리성), (회복기능 -> 지속성)

트랜잭션의 연산

• 트랜잭션 연산
  • commit : 트랜잭션이 성공적으로 수행되었음을 선언 (작업 완료)
    • commit 실행 후 트랜잭션 수행 결과가 데이터베이스에 반영, 일관된 상태로 유지
  • rollback : 트랜잭션이 수행을 실패했음을 선언 (작업 취소)
    • 도중에 장애 발생하면 rollback 연산 실행하고 수행 전의 일관된 상태로 돌려놓는다 (스스로 됨)

트랜잭션의 상태

1. 활동 상태
   • 트랜잭션이 수행을 시작하여 현재 수행 중인 상태
2. 부분 완료 상태
   • 트랜잭션의 마지막 연산이 실행된 직후의 상태
   • 모든 연산을 처리한 상태
   • 연산은 끝나고 아직 수행한 최종 결과를 데이터베이스에 반영하지 않은 상태
3. 완료 상태
   • 트랜잭션이 성공적으로 완료되어 commit 연산을 실행한 상태
   • 완료 상태가 되면 최종 결과를 데이터베이스에 반영하고 데이터베이스가 새로운 일관된 상태가 된다
   • 그리고 트랜잭션 종료
4. 실패 상태
   • 장애가 잘생하여 트랜잭션의 수행이 중단된 상태
   • 더는 정상적으로 수행을 계속할 수 없을 때
5. 철회 상태
   • 트랜잭션 수행이 실패하여 rollback 연산을 실행한 상태
   • 지금까지 실행한 연산 모두 취소하고 트랜잭션이 수행되기 전의 데이터베이스 상태로 되돌림
   • 수행됐던 트랜잭션은 다시 수행되거나 폐기

장애와 회복

회복 : 장애가 발생했을 때 데이터베이스를 장애가 발생하기 전의 일관된 상태로 복구시키는 것

장애의 유형

1. 트랜잭션 장애
   • 트랜잭션 수행 중 오류 발생
   • 원인 : 트랜잭션의 논리적 오류, 잘못된 데이터 입력, 시스템 자원의 과다 사용 요구, 처리 대상 데이터의 부재 등
2. 시스템 장애
   • 하드웨어 결함
   • 원인 : 하드웨어 이상으로 메인 메모리에 저장된 정보가 손실되거나 교착 상태 발생
3. 미디어 장애
   • 디스크 장치의 결함으로 디스크에 저장된 데이터베이스 손상
   • 원인 : 디스크 헤드의 손상이나 고장

데이터베이스의 저장연산

1. 휘발성 저장 장치
   • 장애 발생 시 저장된 데이터 손실
   • ex. 메인 메모리
2. 비휘발성 저장 장치
   • 장애 발생해도 저장된 데이터 손실 X. 디스크 헤더 손상 같은 저장장치 자체에 이상 발생 시 데이터 손실될 가능성 O
   • ex. 디스크, 자기테이프, CD/DVD
3. 안정 저장 장치
   • 비휘발성 저장 장치를 이용해 여러 개 데이터 복사본을 만드는 방법
   • 장애 발생해도 데이터 손실 X, 데이터 영구적으로 저장

• 데이터베이스는 저장장치에 저장된다

• 일반적으로 데이터베이스는 디스크에 상주 (그림 참조)

  • 트래잭션이 처리하려면 데이터를 디스크에서 메인 메모리로 가져와서 처리하고
  • 처리 후에는 결과를 다시 디스크로 보내야 함.

• 디스크와 메인 메모리 간의 데이터 이동

  • 블록 단위
  • 디스크 블록 : 디스크에 있는 블록
  • 버퍼 블록 : 메인 메모리에 있는 블록
  • input(X) : 디스크 블록의 데이터 X -> 버퍼 블록
  • output(X) : 버퍼 블록의 데이터 X -> 디스크 블록

• 트랜잭션 수행을 지시하면 버퍼블록의 데이터를 프로그램의 변수로 가져오고

• 데이터를 처리한 결과를 저장하고 있는 변수값을 버퍼블록으로 옮김

  • read(X) : 메인 메모리 버퍼 블록에 저장되어 있는 데이터 X를 프로그램 변수로 읽어 옴
  • write(X) : 프로그램의 변수 값을 메인 메모리 버퍼블록에 있는 데이터 X에 기록하는 연산

• input -> read -> write -> output (그림 참조)

회복 기법

• 회복 : 장애 발생 시 데이터베이스를 장애가 발생하기 전의 모순이 없고 일관된 상태로 복구시키는 것
• 회복 관리자가 담당 : 장애 발생 탐지 -> 데이터베이스 복구

회복을 위한 연산

• 데이터 중복 : 데이터를 별도의 장소에 미리 복사 -> 장애 발생 시 복사본을 이용해 원래 상태로 복원

  • 덤프 (dump) : 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법
    • 미리 정해진 주기 (하루 한번, 한달에 한번)에 따라 수행
    • 비휘발성 저장 장치 (디스크)에 저장
  • 로그 (log) : 데이터베이스에서 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경한 이후의 값을 별도의 파일에 기록

• 회복 연산

  • redo (재실행) : 가장 최근에 저장한 데이터베이스 복사본 가져옴 -> 로그를 이용해 복사본이 만들어진 이후에 실행된 모든 변경 연산 재실행 : 장애가 발생하기 직전의 데이터베이스 상태로 복구
    • 전반적으로 손상된 경우 사용
  • undo (취소) : 로그를 이용해 지금까지 실행된 모든 변경 연산을 취소하여 원래 상태로 복구
    • 변경 중이었거나 이미 변경된 내용만 신뢰성을 잃은 경우 사용

• 로그 : 데이터를 변경하기 이전의 값과 변경한 이후의 값 기록

  • 로그 파일 : 로그를 저장한 파일, 레코드 단위로 기록

• 로그 레코드의 종류

  1. <Ti, start> : 트랜잭션 Ti가 수행을 시작했음을 기록
     • ex. <T1, start>
  2. <Ti, X, old_value, new_value> : 트랜잭션 Ti가 데이터 X를 이전의 값에서 새로운 값으로 변경하는 연산을 실행했음을 기록 (old_value -> new_value)
     • ex. <T1, X, 10000, 5000>
  3. <Ti, commit> : 트랜잭션 Ti가 성공적으로 완료되었음을 기록
     • <T1, commit>
  4. <Ti, abort> : 트랜잭션 Ti가 철회되었음을 기록
     • <T1, abort>

로그 회복 기법

1. 즉시 갱신 회복 기법
   즉시 갱신 회복 기법 : 트랜잭션 수행 중 데이터를 변경한 연산의 결과를 데이터베이스에 즉시 반영

• 장애 발생에 대비하기 위해 데이터 변경에 대한 내용을 로그 파일에도 기록
• 변경 연산 시 로그파일에 로그 레코드 먼저 기록 후 데이터베이스에 변경 연산 반영
• 즉시 갱신 회복 기법의 데이터베이스 회복 전략
  • 트랜잭션이 완료되기 전에 장애가 발생한 경우 (로그 파일에 <Ti, start> 존재 O, <T1, commit> 존재 X)
    • undo
  • 트랜잭션이 완료된 후에 장애가 발생한 경우 (로그 파일에 <Ti, start> 존재 O, <T1, commit> 존재 O)
    • redo

2. 지연 갱신 회복 기법
   지연 갱신 회복 기법 : 트랜잭션이 수행되는 도중 데이터 변경 연산의 결과를 로그 파일에만 기록해두었다가 부분 완료된 후 로그에 기록된 내용을 이용해 데이터베이스에 한번에 반영

• undo 필요 없고 redo만 필요
• 지연 갱신 회복 기법의 데이터베이스 회복 전략
  • 트랜잭션이 완료되기 전에 장애가 발생한 경우 (로그 파일에 <Ti, start> 존재 O, <T1, commit> 존재 X)
    • 로그 내용 무시하고 버림
  • 트랜잭션이 완료된 후에 장애가 발생한 경우 (로그 파일에 <Ti, start> 존재 O, <T1, commit> 존재 O)
    • redo

검사 시점 회복 기법

검사 시점 회복 기법 : 로그 회복 기법과 같은 방법으로 로그 기록을 이용하되 일정 간격으로 검사 시점을 만들어 둠

• 로그 전체를 분석하는 / 필요 없는 트랜잭션도 redo 하는 비효율성 해결
• 장애 발생 시 가장 최근 검사 시점 이전의 트랜잭션에는 회복 작업 X
• 이후 트랜잭션에만 회복 작업
• 회복 시간 단축
• 일정 간격으로 검사 시점 기록해서 범위 정함

미디어 회복 기법

미디어 회복 기법 : 전체 데이터베이스의 내용을 일정 주기마다 다른 안전한 저장 장치에 복사해두는 덤프 이용

• 디스크에 발생할 수 있는 장애에 대비한 회복 기법
• 장애 발생 시 덤프를 이용해 장애 발생 이전의 일관된 데이터베이스 상태로 복구
• 그 다음에 로그 내용대로 redo 연산
• CPU 낭비되는 단점

병행 제어

병행 수행과 병행 제어

• 병행 수행 : 여러 사용자가 데이터베이스를 동시에 공유할 수 있도록 여러 개의 트랜잭션이 동시에 수행되는 것
  • 인터리빙 : 여러 트랜잭션들이 차례로 번갈아 수행
  • 동시에 같은 데이터 접근하면 문제 생김 -> 제어 필요함
• 병행 제어 (동시성 제어) : 여러 개의 트랜잭션이 병행 수행되면서 같은 데이터에 접근하여 연산을 실행하더라도 정확한 수행 결과를 얻을 수 있도록 트랜잭션의 수행을 제어하는 것

병행 수행의 문제

병행 수행을 특별한 제어 없이 진행할 때 생기는 문제들 (그림과 예시 참조)

1. 갱신 분실 : 하나의 트랜잭션이 수행한 데이터 변경 연산의 결과를 다른 트랜잭션이 덮어서 변경 연산이 무효화되는 것
2. 모순성 : 하나의 트랜잭션이 여러 개의 데이터 변경 연산을 실행할 때 일관성 없는 상태의 데이터베이스에서 데이터를 가져와 연산을 실행함으로써 모순된 결과가 발생하는 것
   • 어떤 연산은 현재 트랜잭션 실행되기 전 데이터를,
     어떤 연산은 다른 트랜잭션이 변경한 데이터를 가져와 연산하면 모순성이 생김
3. 연쇄 복귀 : 트랜잭션이 완료되기 전에 장애가 발생하여 rollback 연산을 수행하면
   이 트랜잭션 장애 발생 전 데이터를 가져가 변경 연산한 다른 트랜잭션에도 rollback 연쇄적으로 해줘야함
   근데 rollback 연산 전 다른 트랜잭션에서 연산 완료하면 문제 생김

트랜잭션 스케줄

1. 직렬 스케줄 : 인터리빙 사용하지 않고 각 트랜잭션 별로 연산들을 순차적으로 실행
   • 독립적 수행
   • 항상 모순이 없는 정확한 결과
   • 직렬 스케줄 종류 (트랜잭션 순서)에 따라 결과 달라짐
   • 병행 수행 아니므로 잘 사용하지 않음
2. 비직렬 스케줄 : 인터리빙 방식 사용, 여러 트랜잭션이 연산 실행
   • 정확성 보장이 안됨
3. 직렬 가능 스케줄 : 직렬 스케줄에 따라 수행한 것과 같이 정확한 결과를 생성하는 비직렬 스케줄
   • 정확한 결과
   • 직렬 가능성을 보장하는 병행 제어 기법을 사용

병행 제어 기법

병행 제어 : 병행 수행 + 정확한 결과 -> 직렬 가능성 보장

로킹 기법의 개념

• 로킹 기법 : 병행 수행되는 트랜잭션들이 동일한 데이터에 동시에 접근하지 못하도록 lock과 unlock이라는 두 개의 연산을 사용하여 제어하는 것

  • 상호 배제 : 먼저 접근한 트랜잭션이 연산을 마칠 때까지 다른 트랜잭션 접근 못하도록 함
  • lock : 데이터에 대한 독점권 가지기 위해
  • unlock : 독점권 반납하기 위해

• 로킹 단위 : lock 연산은 다양한 크기를 대상으로 (전체 데이터베이스 ~ 데베의 속성)

  • 로킹 단위가 커질수록 병행성은 낮아지고 제어가 쉬워짐

• write 할 때는 독점권을 가져야하지만 단순 read만 해올 때는 여러 트랜잭션이 동시에 해도 됨

  • lock 연산을 두가지로 나눔
  1. 공용 lock : read O, write X / 다른 트랜잭션도 같은 데이터에 대해서 공용 lock을 동시에 할 수 있다 (여러 트랜잭션이 사용권을 함께 가짐)
  2. 전용 lock : read O, write O / 해당 데이터에 대해 다른 트랜잭션이 공용이든 전용이든 lock 못함 (전용 lock한 트랜잭션만 독점권 가짐)

• 이 기본 규약을 지켜도 모순이 발생하는 경우가 있어서 2단계 로킹 규약이 등장함 (너무 빨리 unlock해서 일관성 없는 데이터에 접근 / 그림 참조)

2단계 로킹 규약

• unlock 과 lock 연산의 수행 시점에 대한 새로운 규약

1. 확장 단계 : 트랜잭션이 lock 연산만 실행할 수 있고 unlock 연산은 실행할 수 없는 단계
2. 축소 단계 : 트랜잭션이 unlock 연산만 실행할 수 있고 lock 연산은 실행할 수 없는 단계

• 트랜잭션 처음 수행시 확장단계 -> 그러다 unlock하면 축소단계
• 직렬 가능성을 보장하지만 교착상태 (트랜잭션들이 독점된 데이터의 unlock만 기다리면서 트랜잭션 수행을 중단하는 것)에 빠질 수 있음