• Redo 로그

• 데이터 파일과 컨트롤 파일에 가해지는 모든 변경사항을 하나의 Redo로그 엔트리로 저장하는 것
• Online Redo
  
•  Redo 로그 버퍼에 버퍼링된 로그 엔트리를 기록하는 파일 최소 두개이상
•  라운드로빈 방식 (마지막 사용후 첫번째 사용)
• Archived(Offline) Redo : Online Redo 로그가 재사용되기 전에 백업해둔 파일

• Redo 로그의 목적

• 1. Database Recovery

• Media Recovery, 물리적 디스크 복구 Archive Redo 로그 이용

• 2. Cache Recovery (Instance Recovery 시 roll forward 단계)

• - Instance Recovery , 버퍼 캐시의 휘발성을 대비하기위해 트랜잭션 데이터의 유실에 대비하기 위해 Redo 로그를 사용
• Instance Carash 발생후 재기동하면 마지막 checkpoint 이후부터 발생직전까지의 트랜잭선을 재현하여 버퍼캐시를 시스템 셧다운 이전 상태로 복구 하고 이후 Undo 데이터를 이용해 커밋되지 않은 데이터를 롤백 (Transaction Recovery) 진행-> Roll forward 와 rollback 단계를 모두 완료하면 동기화(다운전상태로) 완료

• 3. Fast Commit

• - 변경된 메모리 블록을 디스크상에 기록할대는 random access가 발생하여 느리지만 Append 방식인 로그에 우선 기록하면 빠르게 저장가능 이후 DBWR,CHECKPINT를 이용해 나중에 BATCH 방식으로 일괄 수행
• 오라클 뿐아니라 다른 DBMS 공통적인 사항이지만 오라클은 Delayed 블록 클린아웃을 사용
• Delayed 블록 클린아웃 - Undo 세그먼트 헤더의 트랜잭션 테이블에만 커밋 정보록 기록하고 블록 클린 아웃은 이후 수행 -> 8절

• Redo 기록

• 데이터 블륵 버퍼를 변경하기 전에 Redo 로그 버퍼에 먼저 기록
• LGWR 프로세스에 의해 Redo 로그 버퍼에 있는 내용을 Redo 로그 파일에 기록
• 1. 3초마다 DBWR 프로세스로 신호를 받을때 
  
• DIRY 버퍼를 기록하기전에 LGWR에게 신호를보내 Redo 엔트리를 Redo 로그에 기록
  
• Write Ahead Logging
• 2. 로그 버퍼의 1/3이 차거나 기록된  Redo 레코드량이 1MB를 넘을때
• 3. 사용자가 커밋 또는 롤백 명령을 보낼때

• Fast Commit 메커니즘

• 사용자가 커밋 또는 롤백할 때마다 log file sync라는 대기 이벤트가 발생
•  LGWR 프로세스가 로그 버퍼 내용을 Redo 로그 파일에 기록할때 까지 프로세스가 대기하는 현상때문에 발생

• 오라클 고도화 원리와 해법 1 (bysql.net 2012년 1차 스터디)
• 작성자: 남송휘 (tofriend)
  
• 최초작성일: 2012년 3월 11일
• 본문서는 bysql.net 스터디 결과입니다 .본 문서를 인용하실때는 출처를 밝혀주세요. http://www.bysql.net
• 문서의 잘못된 점이나 질문사항은 본 문서에 댓글로 남겨주세요. ^^