[인터널] Redo 아키텍처

리두 아키텍처는 크게 5가지 특징으로 볼 수 있다.

  ◆ Physiological Logging
  ◆ Page Fix Rule
  ◆ Write-Ahead Logging
  ◆ Log Force At Commit
  ◆ Logical Ordering of Redo

---

로그를 남김에 있어 2가지 방식이 있다.
첫번째는 Logical Logging이고 두번째는 Physical Logging이다.

◇ Logical Logging
  - 장부 기록의 개념. 요약식 기록임.
  - 변경 내용만 기록하므로 비교적 적은 Space 사용함.
  - 단, 복구시에는 변경 내용 기록만 있으므로 복구수행시간이 비교적 오래 걸림.

◇ Physical Logging
  - 변경이 발생한 모든 블록에 대해 Before image와 After image로 저장. 블록의 부분 변경이어도 해당 블록 전체를 Copy함.
  - 변경이 가해진 해당 블록 전체를 리두버퍼로 Copy하므로 많은 Space를 사용함.
  - 단, 복구시에는 Before image 를 다시 가져오면 되므로 쉽다.

이에 오라클은 Logical Logging과 Physical Logging의 장점을 통합하여 Physiological Logging 방식을 사용함.
◇ Physiological Logging
  - Operation과 블록 안에서 변경된 데이터만 Image copy함. (블록 중에서도 변경된 레코드만)
  - Physical Logging보다는 적은 공간을 사용하며 Logical Logging보다는 복구가 편하다. 변경된 블록의 부분만 Copy하므로 복구시 쉽다.
  - Redo와 Undo를 저장함.

오라클은 Physiological Logging 방식을 사용한다고 하였는데, 어느 시점에서는 Physical Logging 방식으로 변할 수 있다.
그 시점은 핫백업이나 Direct Loading을 할 때이다.

● Direct Loading
대용량 데이터베이스 환경에서 insert나 update, delete 를 수행할 때 시간이 너무 오래 걸려 서비스 타임이 지연될 수 있다.
이는 DML이 일어날 때마다 변경내역을 리두로그에 먼저 기록하는 Conventional Loading방식이어서 수많은 데이터를 가지고 DML 수행 시 너무 많은 시간을 빼앗기기 때문이다.
그래서 오라클은 대량의 DML수행 시 디스크의 내용을 DB캐시로 끌어올려 수정한 후 다시 디스크로 내려쓰고 변경 내용을 리두로그에 기록하는 방식이 아닌, 바로바로 디스크에서 작업하고 디스크에서 저장을 하는 Direct Loading 방식을 사용할 수 있게끔 하였다.

SQL> insert /*+ parallel(A 4) */ into
   select ~~~~

SQL> insert /*+ append */ into
   select ~~~~

---

◇ Page Fix Rule
오라클 서버프로세스가 디스크에서 데이터를 끌어올려 DB캐시에 놓으면 해당 블록은 읽혀지거나 변경되기 전에 Lock을 걸어놓아 다른 서버프로세스가 건드리지 못하도록 하는데 이 Lock을 세마포어(Semaphore)라고 한다.

해당 블록이 변경되면 변경된 것들을 체인지 벡터로 생성하고 여러 개의 체인지 벡터가 모여 리두 레코드를 생성한다.
일반적으로 하나의 트랜잭션은 여러 개의 리두 레코드로 이루어져 있고, 각각의 리두 레코드마다 여러 개의 체인지 벡터로 이루어져 있다.

이렇게 위에서 생성된 리두 레코드들을 순차적으로 리두로그파일에 기록한다.

위와 같은 과정을 Page Fix Rule이라 한다.

---

◇ Log Buffer Ahead
DML이 일어나면 먼저 디스크에서 해당 데이터를 DB캐시로 끌어올리고 바로 변경을 하는 것이 아니라 그 변경내용을 리두로그버퍼에 먼저 기록함.

◇ Log File Ahead
블록 변경 후 DBWR이 블록버퍼를 디스크로 내려쓰기 전에 LGWR이 해당 내역 리두 레코드를 리두로그파일에 먼저 기록함.
LRU 알고리즘에 의해 Dirty Buffer를 DBWR프로세스에 의해 디스크의 데이터파일에 저장할 경우 관련된 리두 레코드(리두 레코드의 체인지 벡터들)는 반드시 LGWR프로세스에 의해 리두로그파일에 저장되어야 하며, LGWR 프로세스가 관련 리두 레코드를 모두 저장할 때까지 DBWR프로세스는 Post / Wait 이 필요함.

---

◇ Log Force At Commit
커밋된 트랜잭션의 해당 리두 레코드를 반드시 리두로그파일로 내려 써야 함.
만약 내려쓰지 않는다면 어떻게 될까? Log File Sync 대기이벤트가 발생한다.

---

◇ Logical Ordering of Redo
리두로그의 기록 순서는 Write되는 순서가 아니며, SCN에 의해 Ordering됨.
각 데이터베이스는 하나의 유니크한 SCN을 갖는다. SCN은 일관성을 위해 사용되는 고유한 주민번호 같은 것인데, 이 SCN은 컨트롤파일과 데이터파일 헤더에도 저장되어 있다. 이를 이용해서 복구시 데이터베이스의 시점 및 장애유무를 확인한다.