Redo?

Redo 로그의 구성

1. Online Redo log(온라인 리두)

• Online Redo 로그는 Redo 로그 버퍼에 버퍼링된 로그 엔트리를 기록하는 파일이다.
• 최소 2개이상의 파일로 구성된다.
• 현재 사용중인 Redo 로그 파일이 꽉 차면 다음 Redo 로그 파일로 로그 스위칭이 발생한다.
• 모든 로그파일이 꽉차면 다시 첫번째 Redo 로그 파일부터 재사용하는 라운드로빈 방식을 사용한다.

2. Archived Redo log(아카이브(오프라인) 리두)

• Archived Redo 로그는 Online Redo 로그가 재사용되기 전에 백업해둔 파일을 말한다.

  Redo 로그의 목적

1. Database Recovery
   • Redo 로그는 물리적인 하드웨어 손상인 Media Fail 발생 시 데이터베이스를 복구하기 위해 사용된다.
   • Media Fail로 인한 데이터베이스 복구를 위해 이때는 "Archived Redo log"를 이용한다.
     (= Media Recovery)

2. Cache Recovery

   • I/O 성능 향상을 위한 휘발성의 버퍼캐시의 저장된 변경사항이 디스크 상의 데이터 블록에 아직 기록되지 않은 상태에서 정전 등이 발생해 인수턴스가 비정상적으로 종료될 때(Instance Crash), 트랜잭션 데이터의 유실에 대비하기 위해 Redo 로그를 사용한다.
   • Instance Crash 발생 후 , Online Redo log에 저장된 기록 사항들을 읽어드여 마지막 체크포인트 이후부터 사고발생 직전까지 수행되었던 트랜잭션들을 재현한다.
   • 버퍼캐시에만 수정하고, 데이터파일에 반영되지 않았던 변경사항들이 복구된다.
   • 커밋여부를 불문하고, 버퍼캐시를 시스템 셧다운 이전 상태로 되돌린다.
   • Cache Recovery 완료후, Undo Data를 이용하여, 커밋되지 않았던
     트랜잭션들을 모두 롤백한다.(=Transaction Recovery)

3. Fast Commit

   • 데이터블록에 기록하는 방식인 랜덤 엑세스는 느리고, 반면 로그는 Append 방식으로 기록하기 때문에 상대적으로 빠르다.
   • 트랜잭션 발생시 건건이 데이터 파일에 기록하기 보다, 우선 변경사항을 로그에 기록한다.
   • 기록한 로그파일을, 메모리 데이터 블록과 데이터 파일간 동기화는 적절한 수단(DBWR)을 이용해 나중에 배치 방식으로 일괄 수행한다.
   • 사용자의 갱신내용이 메모리상의 버퍼블록에만 기록된 채 , 아직 디스크에 기록되어 있지 않지만, Redo 로그를 믿고 빠르게 커밋을 완료한다는 의미이다.
   • Instance Crash 가 발생하더라고 언제든지 Recovery 가능한 상태가 되므로 오라클은 안심하고 커밋을 할 수 있다.

   Redo 로그의 기록

   • Redo 레코드를 기록할 때도 곧바로 로그 파일에 저장하는 것은 아니다.
   • Redo 로그 버퍼에 기록한다. 즉 데이터블록을 변경하기 전에 항상 Redo 로그 버퍼에 먼저 기록하고, 일정 시점마다 LGWR 프로세스에 의해 Redo 로그 버퍼에 있는 내용을 로그파일에 기록한다.

   LGWR이 Redo 로그에 기록하는 시점

   1.3초마다 DBWR 프로세스로 부터 신호를 받을때.
   2.로그 버퍼의 1/3이 차거나, 기록된 Redo 레코드양이 1mb를 넘을때.
   3.사용자가 커밋 또는 롤백 명령을 날릴때.(=fast commit 매커니즘의 핵심)
   -> 트랜잭션이 영속성을 보장받으려면 최소한 커밋 시점에는 Redo 정보가 메모리가 아닌 디스크상에 저장되어 있어야한다.(Log force at commit.)