Skip to content

Latest commit

 

History

History
171 lines (106 loc) · 7.02 KB

회복과병행제어.md

File metadata and controls

171 lines (106 loc) · 7.02 KB

회복과 병행 제어

  • 트랜잭션 (Transaction)의 특성(ACID)를 지원하는 DBMS 기능

스크린샷 2020-11-11 오후 3 56 13


1. 회복(Recovery)

  • 장애가 발생했을 때 장애가 발생하기 전의 일관된 상태로 복구시키는 것

  • DBMS의 recovery manager 역할

  • 회복을 위한 방법

    1. 덤프(dump) or 백업(backup): 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법
    2. 로그(log) : 데이터베이스에서 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경한 이후의 값을 별도의 파일에 기록하는 방법
  • 회복 연산

    1. redo(재실행): 가장 최근에 저장한 데이터베이스 복사본을 가져온 후 로그를 이용해 복사본이 만들어진 이후에 실행된 모든 변경 연산을 재실행
    2. undo(취소): 실행된 논리적인 연산을 모두 취소

트랜잭션 처리 과정

스크린샷 2020-11-11 오후 4 00 19


로그를 통한 회복

  • 로그는 트래잭션 단위로 실행
  • 레코드 단위로 기록됨

스크린샷 2020-11-11 오후 4 03 32


트랜잭션 로그의 예

[ T1, START ]
[ T1, UPDATE, 학생(김연아), 중간성적, 88, 99 ]
[T2, START ]
[T2, UPDATE, 학생(이승엽), 기말성적, 89, 93 ]
[ CHECKPOINT ]
[ T2, UPDATE, 학생(홍길동), 기말성적, 77, 66 ]
[ T2, UPDATE, 학생(이영애), 중간성적, 91, 97 ]
[ T1, COMMIT ]
[ T2, COMMIT ]

체크 포인트(check point)

  • 검사점
  • 특정 시점까지의 데이터 버퍼 안의 모든 변경 내용을 데이터베이스 파일에 물리적으로 저장하는 시점
  • 장애 발생 시 복구 작업량을 줄이기 위해서 주기적으로 동기화를 수행
  • 체크 포인트 역시 로그에 기록
  • 체크 포인트 시점에는 버퍼 캐시 안의 데이터와 디스크 안의 저장 베이터베이스가 100% 일치하는 동기화가 수행
  • 체크 포인트가 트랜잭션 로그에 기록되는 순간 모든 데이터 버퍼 안의 데이터들이 데이터베이스 파일에 쓰여짐
  • 회복 대상을 마지막 체크 포인트 시점 이후의 로그 내용으로만 제한시킴

회복의 기본 개념

  • 장애 발생 시점에 이미 commit된 트래잭션의 변경 내용은 로그를 이용하여 반드시 데이터베이스에 반영한다.
  • 반면 commit 되지 못하고 중단된 트랜잭션의 실행 결과는 철회되어야 한다.

장애 발생 시 트랜잭션 로그를 이용한 회복 기법의 적용 과정

  • 마지막 체크포인트 이후의 commit 되지 않은 트랜잭션의 로그 내용들은 모두 롤백 (실행 순서의 역순으로 취소된다)
  • 마지막 체크포인트 이후의 commit 된 트랜잭션의 로그 내용들은 모두 로그 순서대로 재실행됨 (rollforward)

로그 기반 회복의 예

  • Commit 되기 전에는 데이터 버퍼 안의 내용이 디스크에 반영되지 않는다는 가정
[ T1, START ]
[ T1, UPDATE, 학생(김연아), 중간성적, 88, 99 ]
[T2, START ]
[T2, UPDATE, 학생(이승엽), 기말성적, 89, 93 ]
[ CHECKPOINT ]
[ T2, UPDATE, 학생(홍길동), 기말성적, 77, 66 ]
[ T2, UPDATE, 학생(이영애), 중간성적, 91, 97 ]
[ T1, COMMIT ]
[ T2, COMMIT ]
  • 어느 트랜잭션을 어디까지 undo하고 어디까지 redo를 할까?

트랜잭션 T1은 Commit 완료

  • 체크포인트 이전의 T1 UPDATE는 DB 파일에 이미 기록되어 있음
  • 체크포인트 이후의 T1 UPDATE는 DB 파일에 기록 없는데, COMMIT 완료이기 때문에 REDO

트랜잭션 T2는 Commit 완료 X

  • 체크포인트 이전의 T2 UPDATE는 DB 파일에 기록이 있기 때문에 UNDO
  • 체크포인트 이후의 T2 UPDATE는 DB 파일에 기록이 없기 때문에 처리할 내용 없음

스크린샷 2020-11-11 오후 4 19 38


병행 제어(concurrency control)

  • Lock 기법 사용

    • 동시에 수행되는 트랜잭션들이 동일한 데이터에 동시에 접근하지 못하도록 잠그는 것
    • lock/unlock 연산을 통해 제어
  • Lock 종류

    • 공유 lock(shared lock): SELECT문을 실행하기 위한 읽기 전용 lock(Read-Only, 특정 데이터에 대해 여러 트랜잭션이 사용할 수 있음)
    • 동적 lock(exclusive lock): INSERT, UPDATE, DELETE와 같이 데이터 변경을 위한 lock(특정 데이터에 대해서 하나의 트랜잭션만 사용할 수 있음)

스크린샷 2020-11-11 오후 4 23 19


  • Lock 양립성

  • 독점 lock과 공유 lock 2가지 유형의 lock 사이에 서로 추가 잠금 허용 여부를 결정하는 규칙

스크린샷 2020-11-11 오후 11 25 17


Lock 수행에서의 문제

  • X와 Y값인 3000에 각각 1000을 더하는 T1과 X와 Y 값을 각각 50%씩 감소시키는 T2를 수행해서 2000의 결과값을 얻고 싶은 상황의 문제 발생

스크린샷 2020-11-11 오후 11 40 22

위의 상황을 보면 X, Y에 각각 1000을 더하는 상황에서 X만 더하고, Y를 더하기 전에 50% 감소하는 작업이 일어나는 문제가 생겼다.


Locking 규약으로 해결

  • lock 설정과 해제를 적절한 시점에 할 필요가 있음

  • 1단계: lock 확장 단계

    • 접근하고자 하는 데이터에 대한 모든 lock을 획들할 때까지 새로운 lock을 지속적으로 요청하여 잠금을 설정
    • 보유하고 있는 lock을 해제할 수는 없고 lock을 추가로 획득할 수만 있음
  • 2단계: lock 축소 단계

    • 필요로 하는 모든 lock을 획득하는 시점인 lock 포인트가 되면 보유하고 있던 lock을 점차적으로 해제
    • 일단 하나라도 lock을 해제하기 시작하면 다시 새로운 lock을 요청할 수는 없음

스크린샷 2020-11-11 오후 11 47 33


해결 상태

스크린샷 2020-11-11 오후 11 48 50