💡 회복
트랜잭션을 수행하는 도중 장애 발생으로 DB 손상 사, 손상되기 이전의 정상 상태로 복구하는 작업
(1) 연기 갱신 방법
- 트랜잭션이 성공적으로 완료될 때까지 DB에 대한 실질적인 갱신을 연기
- 트랜잭션이 수행되는 동안 갱신된 내용은 Log에 보관
- 트랜잭션의 부분 완료 시점에 Log에 보관한 갱신 내용을 실제 DB에 기록
- Redo (재시도) 작업만 가능
(2) 즉각 갱신 기법
- 트랜잭션이 데이터 갱신 시, 트랜잭션이 부분 완료되기 전이라도 즉시 실제 DB에 반영
- 장애 발생하여 회복 작업할 경우를 대비하여, 갱신된 내용은 Log에 보관
- Redo (재시도) & Undo (취소) 모두 사용 가능
(3) 그림자 페이지 대체 기법
- 갱신 이전 DB를 일정 크기의 페이지 단위로 구성하여
각 페이지마다 복사본(그림자 페이지)을 별도 보관해놓고 실제 페이지를 대상으로 갱신 작업을 수행하다가,
장애 발생 시 Rollback 시킬 땐, 갱신 이후의 실제 페이지를 그림자 페이지로 대체하여 회복
(4) 검사점 기법
- 트랜잭션 실행 중 특정 단계에서 재실행할 수 있도록
갱신 내용 및 시스템 상황 관련 정보 & 검사점(Check point)을 Log에 보관해두고,
장애 발생 시 트랜잭션 전체 철회가 아닌 검사점부터 회복 작업 수행하여 회복시간 절약
💡 병행 제어
다중 프로그램의 이점 활용하여 동시에 여러 개의 트랜잭션 병행 수행 시,
동시에 실행되는 트랜잭션들이 DB의 일관성을 파괴하지 않도록 트랜잭션 간 상호 작용 제어
- 병행제어 없이 트랜잭션이 DB에 동시 접근하도록 허용할 경우,
갱신 분실 / 비완료 의존성 / 모순성 / 연쇄 복귀 등 문제 발생
(1) 로킹
- 트랜잭션이 어떤 로킹 단위를 액세스하기 전, Lock 요청해서 허락되어야만 액세스 가능
- 주요 데이터의 액세스를 상호 배타적으로 함
로킹 단위 (한꺼번에 로킹할 수 있는 객체의 크기)
- DB, 파일, 레코드, 필드 등 가능
- 로킹 단위 크면, 로크 수 작아 관리 쉬움 & 병행성 수준 낮아짐
- 로킹 단위 작으면, 로크 수 많아 관리 복잡 (오버헤드 증가) & 병행성 수준 높아짐
(2) 타임 스탬프 순서
- 트랜잭션과 읽거나 갱신한 데이터에 대해 트랜잭션 실행 전, 타임 스탬프 부여하여 부여된 시간에 따라 수행
- 직렬성 순서 결정 위해 트랜잭션 간 처리 순서를 미리 선택하는 기법 중 가장 보편적
(3) 최적 병행수행 (검증, 확인, 낙관적 기법)
- 병행하고자 하는 대부분의 트랜잭션이 Read Only일 경우,
트랜잭션 간 충돌이 낮아 병행제어를 사용하지 않고 실행되어도
이 중 많은 트랜잭션은 시스템의 상태를 일관성 있게 유지한다는 점을 이용
(4) 다중 버전 기법
- 타임 스탬프 개념 이용 / 다중 버전 타임 스탬프 기법
- 타임 스탬프 : 트랜잭션 및 데이터들이 이용될 때의 시간을 타임스탬프로 관리
- But 갱신될 때마다의 버전을 부여하여 관리
( 발을 힘차게 뻗으며 😎 )