복구 단위별 데이타베이스 복구 방법 ( RECOVERY ) 소개
====================================================

Purpose
---------
데이터베이스 복구의 복구 단계별 개념과 방법을 소개 한다.


Explanation
-----------

1. 블록 단위의 리커버리

우리가 데이터를 입력, 삭제, 수정하는 경우 오라클 내부에서는 리두
레코드를 생성한다. 이의 설명은 자칫 어려워질 수 있으므로 간단히
설명하도록 한다.
리두 레코드란 테이블의 데이터 값이 수정되면 해당 데이터가 위치한
블록의 변경에 대한 정보, 이 데이터에 연결된 인덱스 정보, 이 수정에
따른 Rollback 블록에 관한 변경 정보의 총칭이라 이해하면 가능하다.
또 이들 각각을 Change Vector 라 칭하므로 리두 레코드란 Change Vector
의 모음이라고 생각할 수 있다.

오라클에서는 값이 변경되기 전에 항상 내부적으로 리두 레코드(Redo
Record)를 생성하고, 이 리두 레코드는 로그 버퍼에 변경되어지며, 이 로그
버퍼가 변경( Swich ) 되거나, 시스템의 특정 값에 에 도달하는 경우
Checkpoint가 발생하는데 이 Checkpoint 발생시 해당 변경 정보들이 실제
Physical block 인 디스크 블록에 변경이 되어지는 것이다.

그런데 이 과정중에 변경된 데이터가 리도 로그 버퍼에만 반영되고 블록
버퍼에 반영되지 못하고 작업 수행 중이던 프로세스가 실패하는 경우 블록
단위의 리커버리가 필요하다

이 블록 단위의 리커버리는 시스템이 현재 사용중인 리두로그 파일을 이용
해 자동으로 수행한다. 단 로그 파일의 사이즈에 비해 변경 작업이 빠르게
많이 실행되는 경우 checkpoint not completed' 상태에서 로그 파일이
switch된 경우는 checkpoint이후 시점의 모든 리두 로그 파일이 사용된다.

2. 트랜젝션 리커버리

특정 세션에서 Commit 을 만나기 전까지의 SQL문들을 1 트랜잭션이라
규정하며, 이 트랜잭션 리커버리는 그 일관성을 위해 필요하다.
예를 들어 Insert 나, Update 가 수행도중 시스템이 중단되는 경우가
발생했을 때 리두 로그의 정보를 이용해 Roll forward를 실시하고, Rollback
segment를 이용해 Roll backward 를 실시하는 과정을 의미한다.

즉 각 블록이 수정되기 전에 리두 레코드가 만들어 지는데 이 안에는
Rollback의 변경도 모두 만들어진다고 앞에서 언급하였다. 그러므로
이 리두 레코드 정보를 이용해 Rollforward 를 하고, 각 데이터 헤더
블록에 들어있는 롤백 정보를 이용해 Roll backward 한다 .

참고로 데이터 블록 헤더에는 그 블록을 수정한 트랜젝션 정보와 사용한
롤백 세그먼트 정보가 들어 있으므로 이를 이용해 트랜젝션 리커버리가 가능
하며 이 리커버리 자체 작업도 리두 레코드를 발생시킨다


즉 롤백 세그먼트의 정보는 UNDO$를 확인하여 구할 수 있으며 UNDO$내의
각 롤백 세그먼트에 포함된 Active transaction들(아직 처리가 완료되지 않
은 트랜젝션) 의 정보를 이용해 Rollback 시킨다.


3. Crash 리커버리

이는 모든 인스턴스가 실패하는 경우로 데이터베이스가 시작될 때 자동으로
수행되며, Online redo logs, Current online datafiles, Current control
files을 이용하여 복구되는 방안으로 각 인스턴스에서 변경한 내용이 캐쉬에
는 있으나, 아직 디스크 블록에 적지 않은 내용을 반영하는 과정이다.

현재의 데이터 파일에 반영하지 않은 블록 버퍼의 내용을 이미 생성한
리두 레코드 정보를 이용하여 반영하는 것이다.
이때의 리커버리는 온라인 리두 로그 화일의 리두 레코드를 반영하는 과정이며
단 커밋(commit)되지 않은 트랜젝션을 롤백하는 것은 포함하지 않는다.


4. 인스턴스 리커버리

여러 개의 인스턴스를 갖는 (Oracle Parallel Server) 시스템에서 한 개
이상의 인스턴스가 실패 되었으나, 전체 인스턴스 모두가 실패하지 않은
경우이다.

실패한 인스턴스 블록을 DLM 이 access 하고자 하거나, 실패한 인스턴스가
변경한 블록을 다른 인스턴스가 읽고자 하여 그 이전 Lock 을 정리를
요청하는 과정에서 이 인스턴스의 실패를 알게 되어 다른 인스턴스나 DLM이
이 실패를 자신의 SMON에게 알려 thread open lock 을 획득한 후
instance recovery 를 하게 된다,

5. 미디어 리커버리

미디어 리커버리는 다른 것과는 달리 자동으로 수행되지 않으며, Recover
명령문에 의해서만 수행된다. 백업 파일을 Restore 한 경우나, 특정 파일이
Checkpoint 없이 Offline 된 경우, Control file 을 다시 만드는 등의 과정
으로 Using Backup controlfile 을 사용한 경우이다.
이 경우는 특정 데이터 파일 헤더와, 컨트롤 파일 헤더의 Checkpoint값이
달라 미디어 리커버리를 필요로 하게 된다.
또한 미디어 리커버리는 해당 파일 헤더에 기록된 가장 작은 SCN 부터
복구를 시작한다.