04 REDO

REDO Log
-- Online redo log --
-- Archive redo log --

REDO 로그 목적

1. Database Recovery
2. Cache Recovery
3. Fast Commit

Database Recovery



- 물리적으로 Database 가 손상되었을 경우 복구하게 되며,
  이 부분은 백업부분을 restore 한 뒤에 장애가 나기전 시점, 혹은 원하는 시점까지
  recovery 하는 부분. Media recovery 라고 하며 이 경우 주로 Archive log 를 이용한다.

Cache Recovery



- Instance 가 비정상 적으로 종료되고 재기동 하면 Online Redo 로그에 저장된 기록을
  읽어들어 마지막 체크포인트이후 부터 사고 직전까지 수행되었던 트랜잭션을 재현한다.
  Roll forward 단계라고 치며, 버퍼캐시에만 수정하고 데이터파일에는 반영되지 않았던
  변경사항들이 복구된다, 여기서는 트랜잭션 Commit 여부를 확인하지 않는다.
  
  이후 Transaction Recovery 가 시작되며, 여기서 UNDO 데이터를 이용한 Commit 여부를 체크한다.
  시스템이 비정상 종료 되는 시점에 Commit되지 않았던 트랜잭션을 모두 Rollback 진행하여
  데이터파일에는 커밋에 성공한 데이터만 남게 되며, 데이터베이스는 완전히 동기화 됩니다.

Fast Commit


 - 사용자의 갱신사항을 메모리의 버퍼블록에만 기록한 채 아직 디스크에 기록되지 않았지만
   Redo 로그를 믿고 빠르게 커밋한다고 의미에서 Fast Commit 이라고 부른다.

h5.Delayed 블록 클린아웃 (Clean out)
오라클 경우 별도의 Lock 메이저 없이 레코드 속성으로 Lock을 구현하였기 때문에 Lock을
해재할라면 블록을 일일이 찾아다녀야 됨으로 커밋 시점에는 Undo 세그먼트 헤더의
트랜잭션 테이블에만 커밋 정보를 기록하고, 블록 클린아웃은 나중에 수행하도록 한다.

h5.LGWR이 REDO 로그버퍼를 Redo에 기록하는 시점

3초마다 DBWR 프로세스로부터 신호를 받을 때
로그 버퍼의 1/3 이 차거나 기록된 REDO 레코드량이 1MB 가 넘을 때
사용자가 커밋 또는 롤백명령을 날릴 때

h5.Write Ahead Logging
Buffer Cache 에 있는 블록버퍼를 갱신하기전에 먼저 Redo buffer 에 기록.
(LGWR) Redo log buffer 기록되어 있는 해당 redo 엔트리를 모두 redo log file 에 기록 후에
(DBWR) Buffer Cache 에 있는 Dirty 블록들을 디스크에 갱신할 수 있다.

h5.LogFileSync 대기 이벤트
LGWR 프로세스가 Redo 로그 버퍼의 Redo 엔트리를 Redo 로그에 기록 완료 할 때까지 발생 하는 대기 이벤트

Redo 관련된 Parameter 및 옵션

nologging : 최소한의 로그는 생성 됨

(Data Dictionary 변경 내역, 새로 할당된 Extent 상태 변경(Invalid) 내역)

기본적으로 Nologging 으로 진행되는 부분.

direct load (SQL*Loader)
direct-load INSERT
CREATE TABLE ... AS SELECT
CREATE INDEX
ALTER TABLE ... MOVE PARTITION
ALTER TABLE ... SPLIT PARTITION
ALTER INDEX ... SPLIT PARTITION
ALTER INDEX ... REBUILD
ALTER INDEX ... REBUILD PARTITION
INSERT, UPDATE, and DELETE on LOBs
in NOCACHE NOLOGGING mode stored out of line

Redo (by nakamori) [2012.03.02]

04 REDO

Redo 관련된 Parameter 및 옵션