1. 장애와 회복
-
장애 : 명세대로 작동하지 않는 상태
원인 : HW 결함, SW 오류, 인적 실수 등 -
장애의 유형
i. 트랜잭션 장애 : 논리적 오류, 입력 데이터 불량
ii. 시스템 장애 : 하드웨어 오동작
iii. 미디어 장애 : 디스크 고장 -
회복 : 데이터베이스를 장애 발생 이전의 일관된 상태로 복원
-
일관된 상태: DB에 오류가 없고 내용에 모순이 없는 상태
2. 회복의 원리
-
회복의 기본 원리 : 중복
덤프 : 물리적으로 다른 저장장치에 복제
로그 : 데이터의 옛 값과 새 값을 별도 파일에 기록
>> 로그로 회복 불가 시 덤프 이용 -
회복을 위한 조치
REDO : 최근 일관된 상태 + 로그
UNDO : 로그 + 모든 변경 취소
2-1. 회복 관리자
DBMS의 서브시스템으로 전체 코드 10% 차지. 장애 탐지와 복원 기능 수행
- 회복 작업
i. 손상된 부분만 포함하는 최소 범위
ii. 트랜젝션 기반 회복
iii. 회복자료의 보장
iv. 시스템 레벨 자동 조치
2-2. DB 저장장치 구조
- 소멸 저장장치 : 메인메모리
- 비소멸 저장장치 : 디스크
- 안전 저장장치 : 백업
3. DB 저장연산
DB와 프로그램 사이 데이터 이동
-
Read() : 버퍼에서 데이터를 읽고, 버퍼에 없다면 Input() 실행
-
Write() : 버퍼에 데이터를 쓰고, 버퍼에 없다면 Input() 실행
--> Output()전 시스템 붕괴시 값 손실
디스크와 메인 메모리 사이 블록 이동
-
Input() : 디스크 블록을 메인 메모리로 이동
-
Output() : 버퍼 블록을 디스크로 이동
4. 트랜잭션
연산자의 시퀀스
4-1. 트랜잭션의 특성
ACID
A : 원자성 = 전부 실행하거나 전혀 실행하지 말아야함
C : 일관성 = 트랜잭션 실행 후에도 일관성 유지
I : 격리성 = 연산 중간 결과에 다른 트랜잭션이 접근할 수 없음
D : 영속성 = 트랜잭션이 성공적으로 실행되면 결과는 영속적
4-2. 트랜잭션의 원자성 보장
-
트랜잭션 회복 : 트랜잭션은 회복의 논리적 단위
-
트랜잭션의 원자성을 위한 연산 : Commit과 Rollback
4-3. 트랜잭션 상태
-
프로그램 : 하나 이상의 트랜잭션을 포함. 모든 트랜잭션 성공 시 완료
-
실패 상태의 트랜잭션 : Rollback하여 트랜잭션 DB를 실행 전 상태로 환원
이후 장애 원인이 HW/SW 오류일 시 재시작, 트랜잭션 내부 오류일 시 폐기
5. DB 로그
5-1. 로그 레코드
- 로그 레코드
<Ti, Start> : 트랜잭션 Ti 시작
<Ti, Xj, V1, V2> : Xj 값을 V1에서 V2로 변경
<Ti, commit> or <Ti, rollback>
- 온라인 DB와 로그는 모든 실행을 기록하기 때문에 Redo와 Undo가 가능
- 보존 DB와 로그는 일관성 보장된 데이터만 기록하기 때문에 Redo가 가능하고 Undo는 불필요
5-2. 로그 압축
저장장치의 효율적 사용과 신속한 회복을 위해 로그를 압축한다
-
실패한 트랜잭션 로그는 불필요 : 일관된 이전 상태가 있고 이미 rollback되어 불필요
-
성공한 트랜잭션 갱신 전 데이터 불필요 : REDO를 위해 새로운 값만 필요
-
하나의 데이터가 여러번 갱신되었다면 마지막 데이터 값만 필요
6. 지연갱신
부분 완료될 때까지 모든 Output 연산을 지연하고 변경은 로그에 기록한다
- <Ti, Commit>을 포함하는 로그 레코드를 기록한 후에 DB를 갱신한다
- 일관되지 않은 상태는 디스크에 저장되지 않기 때문에 UNDO 연산이 불필요하다
- 로그 레코드 <Tid, Xj, V> : UNDO가 필요 없어 옛 값도 불필요하다
예)
- 트랜잭션
- 로그
- 데이터베이스
6-1. 지연갱신의 REDO
-
로그를 이용해서 REDO하여 장애 처리
-
Redo 연산은 idempotent(멱등) 성질을 가지고 있어야함
Redo(Redo(Redo...(x))) = Redo(x)
6-2. REDO 대상
- <Ti, Start>와 <Ti, Commit> 로그 레코드가 모두 있는 트랜잭션에 대해서만 해야한다
7. 즉시 갱신
데이터의 변경 결과를 데이터베이스에 그대로 반영한다
-
지연 갱신시 버퍼 용량 부족으로 문제가 발생할 수 있어 실제 DB는 즉시 갱신을 한다
-
UNDO와 REDO 연산 모두 사용하고 둘다 멱등 성질을 지녀야한다
- commit 전 변경이 가능한 것이지 변경 때마다 갱신하는 것은 아니다
- 버퍼에서 비울 때 Output()한다
7-1. 즉시 갱신의 회복
<Ti, Start>만 있고 <Ti, Commit>이 없음 = UNDO(Ti)
<Ti, Start>, <Ti, Commit> 둘다 있음 = REDO(Ti)
- REDO는 시간 순서대로, UNDO는 시간 역순으로 실행한다. UNDO를 우선 실행한다
7-2. 검사시점 회복
전체 로그 이용 회복 시 비용이 크기 때문에 검사시점을 설정하여 사용
-
검사시점 설정 방법
i. 로그 버퍼(메인 메모리)의 모든 레코드를 안정 저장소로 출력
ii. 변경된 데이터 버퍼 블록(dirty page) 전부 디스크로 출력
iii. 검사시점 <Checkpoint L>로그 레코드를 안정 저장소에 출력 (L = 실행 중인 트랜잭션 리스트) -
트랙잭션 목록 결정 방법
i. 빈 Undo-list와 Redo-list 생성
ii. 검사시점 당시 실행 중 트랜잭션은 Undo-list에 삽입
iii. 로그를 차례로 읽으며 <Ti, Start> 레코드 만날 시 Ti를 Undo-list에 삽입
iv. 로그를 차례로 읽으며 <Ti, Commit> 레코드 만날 시 Ti를 Redo-list로 옮김 -
회복
i. 후진 회복 : Undo 연산 수행
ii. 전진 회복 : Redo 연산 수행
8. 그림자 페이징 기법
로그 없이 데이터베이스 운용. 간단한 데이터베이스에 적합하다
-
페이지 테이블 : 현 페이지 테이블, 그림자 페이지 테이블
-
트랜잭션 실행 중에는 현 페이지 테이블만 사용한다
- 트랜잭션 과정
i. 버퍼를 디스크에 Out-of-place 출력한다
ii. 현 페이지 테이블을 디스크에 출력한다
iii. 현 페이지 테이블을 그림자 페이지 테이블에 복사하고 현/그림자 페이지 테이블을 바꾼다
8-1. 그림자 페이징의 회복
-
그림자 페이지 = 이전의 일관된 DB 상태
-
Out-of-place 갱신을 하기 때문에 원래 데이터도 유지된다
-
장애 발생 시 현 페이지 테이블을 버리고 그림자 페이지로 변경한다
8-2. 그림자 페이징 장단점
-
장점
i. 로그 출력 오버헤드가 없다
ii. Undo가 간단하고 Redo가 필요 없어 회복이 빠르다 -
단점
i. 커밋 오버헤드 : commit 시 모든 dirty page 기록
ii. 데이터 단편
iii. 쓰레기 수집
iv. 병행 트랜잭션 거의 불가
9. 미디어 회복
- 디스크 붕괴를 대비해 주기적으로 덤프한다
- 회복 : 가장 최근 덤프를 이용해서 회복. 로그를 이용해 덤프 이후 완료 트랜잭션 REDO
9-1. 로그 우선 기록 규약
-
로그 레코드 버퍼링 : 로그 오버헤드 때문에 사용
-
로그 우선 기록 규약 : 로그 버퍼를 사용해 발생 할 수 있는 문제를 방지하기 위한 규약
i. 트랙잭션은 Commit 로그 레코드를 안정 저장장치에 출력시켜야만 완료
--> commit 보장
ii. commit 로그 레코드를 출력하기 위해 먼저 트랜잭션 관련 모든 로그를 안정 저장장치에 출력
--> redo 보장
iii. DB 버퍼 블록 출력 전 버퍼 블록 데이터와 관련된 모든 로그 레코드가 안정 저장장치에 출력
--> undo 보장
