일반적인 리두 로그의 용도

  1. 시스템 장애 후, 인스턴스 리커버리 진행시 이용됨
  2. 백업본으로 복원(restore)한 이후, 그 시점 이후의 변경 내용을 복구(recover)해야 할 때에 이용됨
  3. 데이터 가드, 오라클 스트림, 로그 마이너 등에서 사용됨

DB상에 변경을 가하는 대부분의 작업은 리두를 발생시킨다. 이러한 정보가 담겨 있기에, 이를 통해 DB 복구시 이용 한다거나, 가드, 스트림과 같은 특수 용도에 사용한는 것이다. 

온라인 리두 로그

온라인 리두 로그에는 그룹과 멤버라는 것이 있으며, 최소 2개 이상의 리두 로그 그룹과, 그룹당 1개 이상의 리두 로그 멤버로 구성되게 된다.
리두는 그룹 단위로 사용이 되게 되며, 동일 그룹내에 2개 이상의 멤버가 있다면 이들은 미러링 개념으로 사용되게 되는것이다.
하나의 그룹을 처음부터 끝까지 다 쓰게되면 그 다음 그룹을 사용하게 된다. 이렇게 다음 리두 로그 그룹으로 넘어가는 것을 로그 스위치라고 한다.
(2개의 그룹이 사용되고 있다는 가정하에) 두번째 그룹도 다 사용하였다면, 다시 첫번째 그룹을 사용하게된다. 리두 로그 파일은 재사용 가능하다는 것이다.
단, 이렇게 재사용을 하겠다는 이야기는 과거의 내용은 지워버리겠다는 의미가 되므로, 정말 필요없는 내용만 들어있는지 확실시 되어야 리두 로그가 재사용되기 시작한다.
따라서 리두 로그가 스위치 될 때에는 체크포인트라는 작업이 발생하게 된다. (체크 포인트는 다음 장에서 다시 설명될 예정)

좀더 상세한 리두 로그의 동작 과정은 다음과 같다.
DB블록에 변경을 수행할 경우, 오라클에서는 디스크 I/O 발생 횟수를 줄이기 위해, 디스크로부터 DB블록 이미지를 읽어들여 1차적으로 DB 버퍼 캐쉬라는 영역에 저장해 놓고, 해당 메모리 영역 안에서 블록 이미지를 변경하게 된다.
향후 동일한 블록에 대한 액세스가 발생하게 된다면 그때는 디스크로부터 I/O가 발생하는 것이 아니라, 메모리 영역에서 작업이 발생하게 되는 것인다. 
사용자 입장에서는 COMMIT을 수행하였다면 이제 자기가 변경한 내용이 모두 안전하게 디스크에 저장되었을 것이라 생각할 수 있을 것이다.
하지만 실제 오라클은, 이렇게 DB 버퍼 캐쉬 영역으로 불러 들여진 DB 블록에 변경이 가해졌을 때에, 매번 변경된 블록 이미지가 디스크에 저장되는 것이 아니다.
매번 실제 메모리상의 변경 내역을 디스크로 내려 쓰는 것이 아니라, 디스크 I/O를 최소화 하기 위해 일정 기준만큼 모아서 한번에 내려쓰게 되는 것이다.
만약 시스템에 장애가 발생하고 DB를 재기동하게 되었다면, 아직 디스크에 저장되지 못한 DB 블록들이 있으므로, DB가 가장 마지막 변경사항까지 반영하지 못한 상태가 될 것이다. 하지만 사용자가 입력한 모든 변경 사항들은 로그 형태로 리두 로그 파일에 모두 기록이 되게 된다.
장애를 겪은 뒤에 DB가 재기동 된다면, DB를 재기동하는 시점에, 리두 로그에는 남아 있으나 DB 블록에는 반영되지 못한 내용들을 찾아내어, 마치 사용자가 쿼리를 수행했던 때 처럼 다시 한번 그 쿼리들을 수행해주게 된다. 이러한 과정을 인스턴스 리커버리라고 부르며, 이러한 과정이 리두 로그가 사용되는 가장 핵심이 되는 부분이 된다.
당장 겉으로 보기에는 인스턴스 리커버리라는 복구 기능을 수행하기 위해 리두 로그가 필요한 것으로 보이지만, 디스크 I/O 부하를 획기적으로 줄여주면서, 장애시에도 완료된 트랜잭션에 손실을 입지 않을 수 있는 것은, 리두 로그가 DB의 안전을 보장해 주고 있기 때문인 것이다.

DB를 어떠한 용도로 사용하고 있는지, 사용자는 얼마나 되는지에 따라 발생되는 리두 로그의 사이즈가 달라지게 될 것이다.
시스템의 사양이나 어떻게 설정이 되어있는지에 따라 해당 시스템이 소화할 수 있는 리두 로그의 사이즈도 달라지게 될 것이다.
만약 시스템이 소화해낼 수 없을 정도의 리두 로그가 발생하게 된다면, 불필요한 대기 이벤트가 발생하게 될 수 있다.
예를 들면, 앞서 언급했던 것 처럼 리두 로그가 재사용되기 전에, 해당 리두 로그가 가진 내용이 더이상 필요없는 내용이라는 것을 확실시 하기 위해 체크포인트가 발생된다.
해당 로그 파일이 안전을 보장하고 있기에 아직 디스크로 내려써지지 않았던 모든 DB블록이 이 시점에서 디스크에 내려쓰여지게 되며, DBWn 프로세스는 이 작업이 완료되기 전까지 해당 작업에만 전념하게되어 일시적으로 작업이 중단되게 된다. 따라서 충분한 사이즈의 리두 로그 파일과 충분한 개수의 리두 로그 그룹이 필요하게 된다.
이에 대한 가이드는 어떠한 시스템인지에 따라 달라지게 되지만, 일반적으로 아래와 같은 내용들을 계산해보면 정답에 가까운 값이 나올 것이다.

 

아카이브 리두 로그

아카이브 리두 로그는, 온라인 리두 로그에 대한 복사본이다.
오라클 데이터베이스는 아카이브 리두 로그를 생성하도록 설정(아카이브로그 모드)할 수도 있으며, 생성하지 않도록 설정(노아카이브로그 모드)할 수도 있다.
만약 아카이브로그 모드로 설정이 되어있다면, 리두 로그 스위치가 발생할 때 직전에 사용되었던 온라인 리두 로그에 대한 아카이빙 작업이 시작된다.
이렇게 리두 로그에 대한 사본을 만들어주어 리두 로그 정보를 잃지않고 모두 보관할 수 있게 된다.

이러한 아카이브 로그를 사용할 경우 몇가지 이득이 있다.
마지막 백업 수행 시점부터 현재 시점까지의 리두 로그 정보가 모두 보관되고 있으므로, 이를 통해 가장 최신 시점까지의 완전 복구를 수행할 수 있게 된다.
또한 Point-in-Time 복구 방식을 사용할 수 있게 되어, 가장 최신 시점 뿐 아니라 그 사이의 시간대에서 원하는 시점 언제로든지 복구를 수행할 수 있게된다.
노아카이브로그 모드에서는 재사용되는 리두 로그 정보들은 잃게 되므로, 복구상에 문제가 생길 가능성이 높다. 
이러한 복구 시점에서의 이슈 뿐 아니라, 백업 시점에서도 아카이브로그 모드를 사용하고 있다면 핫 백업을 사용할 수 있게 된다는 장점이 있다. 
아무리 스토리지단에서 RAID 구성을 잘 해놓았다 한들, 사용자 실수로 날려버린 테이블에 대해서까지 안전을 보장해 줄 수 있는 것은 아니다. 따라서 안전한 데이터베이스의 구축을 위해서는 아카이브로그 모드의 사용은 필수라고 할 수 있다. 


아카이브로그 모드를 사용하게 된다면, 아직 사본 생성이 완료되지 않은 온라인 리두 로그는 재사용이 되지 않는다.
따라서 충분한 크기의 리두 로그 사이즈와 그룹 개수가 확보되어 있지 않다면, 일시적인 DB 행 현상이 발생하게 될 수 있다. 또한 리두 로그 아카이빙 작업으로 인한 부차적인 디스크 I/O 발생이라는 문제도 생기게 되므로, 엄청난 수의 트랜잭션이 발생되는 시스템에서라면 디스크 I/O 속도 또한 뒷받침 되어야 할 것이다.