복구 시스템

장애는 필연적으로 발생하기에 복구 시스템이 갖춰져야 한다.

질의처리기 - read/write -> 트랜잭션 매니저(for 직렬성, 일관성) 

 

# 실패의 분류

- 트랜잭션 실패

  ˙ 논리적 에러 : 트랜잭션이 내부조건으로 인해 더 이상 정상적인 실행을 지속할 수 없다

  ˙ 시스템 에러 : 교착상태 같은 상태에 도달하여 더 이상 정상적인 실행이 안된다. 그러나 이후 재실행될 수 있다

 

- 시스템 손상

 ˙ 시스템을 중단시키지만 비휘발성 저장장치의 내용은 손상시키지 않는다는 가정을 실패 중지 가정

 

- 디스크 고장

 ˙ 데이터 전송 작업동안 헤드의 손상이나 고장으로 인해 내용을 손실할 수 있다. 따라서 3차 저장 매체에 백업 

 

- 복구 알고리즘 (데이터베이스의 일관성과 트랜잭션의 원자성을 보장하는 알고리즘)

  ˙  로그(journal)파일에 진행상황을 기록하는 알고리즘 (for 실패로부터 복구하는데 필요한 정보)

  ˙  데이터를 복구 한 다음 원자성, 일관성, 지속성을 책임져주는 알고리즘

 

# 저장구조, 저장 장치    p.664

- 휘발성 저장 매체

- 비휘발성 저장 매체

- 안정 저장 매체  **복구 알고리즘에서 중요**

   ˙ 동일한 내용을 여러 군데에 복사해놓는다

 

# 안전 저장 장치 여러가지 구현 방법

- 필요한 정보르 여러 비휘바렁 저장 매체(디스크같은..)에 중복 저장

- RAID는 재난에 잃을 가능성이 있다. 따라서 별도의 장소에 보관요 백업 데이터를 저장.

- 원격 사이트에 보관하고 컴퓨터 네트워크를 통해 갱신하는 방식

- 데이터 전송 실패가 발생하면 복구 프로시저 호출해 일관성 유지하도록 해야함. 각 논리적 데이터베이스 블록에 대해 두 개의 물리적 블록을 유지한다.

 

# 데이터 액세스

- 블록 : 디스크 사이의 데이터 전송 단위

- 물리적 블록 : 디스크 상의 블록

- 버퍼 블록 : 메인 메모리에 임시적으로 있는 블록

- 디스크 버퍼 (input, output) : 블록이 임시로 있게 되는 메모리 영역

 

# 메인 메모리와 디스크 사이의 블록 이동에 발생하는 연산

1. input(B) : 물리적 블록 B를 메인 메모리로 전송한다

2. output(B) : 버퍼 블록 B를 디스크로 전송하고 그곳에 적당한 물리적 블록을 대체시킨다

 

# 복구와 원자성 

Log-Based Recovery 로그기반 복구

- 로그log는 안전 저장 장치다

- 즉시 데이터베이스를 변경하는 로그 접근방식을 주로 사용한다

- log에 트랜잭션이 commit 완료됨을 알려주는 메시지를 보내면

 

# 즉시 변경 (immediate-modification)

트랜잭션이 수행되는 도중(트랜잭션 commit 전에) 데이터베이스 변경을 하는 것

블록 저장 연산, 과정

# WAL (write ahead log)   **중요***  

위 그림에서 (T1, Y, 50, 100) T1트랜잭션에서 Y버퍼를 50에서 100으로 값을 변경작업을 log에 먼저 작성 후, 진짜 DB로 가서 물리적 블록의 값을 바꿈

 

# 로그 레코드

- 로그 : 로그 레코드의 시퀀스, 데이터베이스의 모든 갱신 작업을 기록

- 갱신 로그 레코드 <트랜잭션, 피기록 데이터 항목, 이전 값, 새로운 값>

- 데이터 항목은 데이터 항목 식별자. 기록한 데이터 항목의 고유 식별자로서 일반적으로 데이터 항목의 디스크 상 위치이며, 데이터 항목이 존재하는 블록의 블록 식별자와 블록 안에서의 오프셋으로 구성

- 트랜잭션이 기록 연산을 수행할 때마다 db가 변경되기 전에 기록 연산을 위한 로그 레코드가 생성되고 로그에 추가되어야 한다. (생성 후 추가)

 

트랜잭션이 내용 변경
<Ti strat>
<Ti, Y, 50, 100>
.
.
트랜잭션이 commit 요청
<Ti commit>
트랜잭션에게 commit 완료 응답을 전달

 

# 데이터베이스 변경 (실패 시 복구 작업)

˙ undo 와 redo는 순서가 중요하다

- Undo : old value로 돌아간다 (Recovery)

   ˙ < Ti, X, V >   트랜잭션의 값을 old value인 V로 

   ˙ < Ti abort >  종료

   ˙ 트랜잭션이다 -> undo작업에 대해 log레코드 발생** -> redo 전용 로그 레코드

  ˙ <Ti start> 는 있는데 <Ti commit or abort> 가 없을 때

  

- Redo : new value로 갱신

   ˙ 진행만 하고 log레코드 생성 x

   ˙ <Ti start>부터 <Ti comit or abort> 가 모두 있을때, 이 작업들을 다시 redo 해달라고 요청하는 것

  ˙ 각 트랜잭션 별로 수행하지 않는다. 대신 로그를 순차적으로 스캔하며 각 로그 레코드에 대한 redo작업을 한다   

 

(a) 는 트랜잭션 start만 있으므로, failure 발생 후 B를 복구하는 undo 작업

(b) 는 T0는 커밋까지 했지만 T1은 시작만 했다. 따라서 redoT0, undoT1

(c) 체크포인트 기능을 상요하면 물리적버퍼와 버퍼블록의 내용을 강제로 일치시킨다

 

 

# 체크포인트 (검사점)   

- 로그 전체를 탐색하지 않기 위해 만들어짐

- 도입장점 ) 시간 절약, 실행된 redo는 제외함으로써 시간 절약

- 자료구조 : 리스트

- 체크포인트 기능을 사용하면 물리적버퍼와 버퍼블록의 내용을 강제로 일치시킨다

- 장애가 발생하면 checkpoint 영역까지 가서 redo 작업

- start부터 commit작업까지 완료한 트랜잭션은 undo 리스트에서 제외시킨다.

도입 전 (천숭피셜)	도입 후 변화 (천숭피셜)
- 검사점 연산이 수행되는 동안에는 모든 갱신 작업을 금지 - 검사점이 수행되면 모든 수정된 머퍼 블록들을 디스크에 기록	- 현재 메인 메모리에 존재하는 모든 로그 레코드를 안정 저장 장치로 기록 - 변경된 모든 버퍼 블록을 디스크로 기록 -로그 레코드 <checkpoint L>을 안정 저장 장치로 기록한다. 여기에서 L은 검사점 시점에 동작 중인 트랜잭션의 목록이다.

 

# 시스템 실패 후의 복구   p.677

redo	- 마지막 검사점에서부터 순방향으로 로그를 탐색하며 모든 트랜잭션의 갱신을 재실행한다.  - 미완료나 롤백되어야 하는 트랜잭션을 모두 찾는다 - 검사점 이전이나 이후일 수도 있다, - abort, commit 레코드를 갖지 않는다
undo	- 끝에서부터 역방향으로 탐색을 통해 롤백을 수행 -

 

 

# 로그 레코드 버퍼링

: 메인메모리에서 I/O 발생할때마다 로그에 기록할 순 없다. 따라서 log용 버퍼블럭을 메인메모리 안에 만든다

로그 레코드 버퍼가 가득 차면 로그에 기록된다

 

- log force-output : 트랜잭션의 commit레코드가 로그 레코드 버퍼에 들어오면 바로 로그에 기록한다. (로그 레코드 버퍼링 공간이 남았을지라도)

 

- log no-force : 트랜잭션에서 내용변경이 발생했지만 디스크에 기록하는것을 강제로 하지 않는다.

 

- log steal policy : 

 

latch - 아주 가벼운 락. latch가 걸렸을때만 작동