4._Redo

조회 수 4836 추천 수 0 2012.03.11 22:22:44
남송휘 *.168.192.1

  • 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 메커니즘

sD8A_mAx95KnCNp-ZZRXhFw.png



1) 사용자 Commit
2) LGWR은 커밋 레코드를 Redo 로그 버퍼에 기록
3) 트랜잭션 로그 엔트리와 함께 redo 로그파일에 저장
4) 커밋 수행한 트랜잭션에 ‘success code’를 리턴



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


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