Redo Log Buffer의 목적은 복구에 있다. 그렇기 때문에 Redo Log Buffer는 복구를 위해 모든 아키텍처가 구성되어 있다.

이번 강의에서는 이와 같은 Redo Log Buffer의 하나의 사상인 Log Force At Commit과 Logical Ordering Of Redo에 대해 설명한다.

확실한 복구를 위한 Log Force At Commit

Write Ahead-Logging의 경우에는 Redo Log Buffer의 비정상에 대비한 확실한 복구를 위한 아키텍처다. 데이터 복구의 기준은 트랜잭션의 Commit에 있다. 그렇기 때문에 Commit과 함께 해당 트랜잭션의 Redo Log를 기록하는 기법이 Log Force At Commit이다.

• - Log Force At Commit : DML 작업 시 블록의 변경보다 Redo Log를 먼저 생성해 Redo Log Buffer에 기록하는 기법

• [그림 1] Log Force At Commit
• 

[그림 1]에서 트랜잭션이 수행된 해당 트랜잭션이 Commit된다면 LGWR이 Posting되고 LGWR에 의해 해당 트랜잭션의 Redo Log가 Redo Log File에 반드시 기록되어야만 해당 트랜잭션은 Commit을 종료할 수 있게 된다.

이와 같은 Log Force At Commit을 수행하는 경우의 몇 가지 특징을 확인해 보자.

• - 더티 버퍼 기록
• - Piggyback Write/Group Commit

더티 버퍼 기록

트랜잭션이 Commit되는 동안 Log Force At Commit에 의해 해당 트랜잭션의 Redo는 반드시 Redo Log File에 기록되어야 한다. 이와 같은 상황에서 데이터베이스 버퍼 캐시에는 실제 블록이 변경되어 있을 것이다.

해당 데이터베이스 버퍼 캐시에 존재하는 변경된 블록은 DBWR에 의해 데이터 파일에 기록될 필요는 없다. 이는 Commit과는 무관하게 그 후에 발생하게 된다.

Piggyback Write/Group Commit

데이터베이스 시스템은 동시에 여러 유저에 의해 사용된다. 이와 같다면 동시에 여러 유저에 의해 DML이 발생하게 되고 또한 한번에 여러 트랜잭션이 동시에 또는 매우 근접한 시간에 Commit이 발생하게 된다.

이와 같은 경우 트랜잭션별로 한 번씩 LGWR에 의해 해당 Redo Log를 기록한다면 LGWR에 의한 디스크 I/O가 과다하게 발생한다.

이와 같은 이유에서 오라클 데이터베이스는 Piggyback Write/Group Commit을 수행하게 되고 이는 하나씩의 Redo Log를 Redo Log File에 기록하는 것이 아니라 잠시 대기해 한 번에 여러 개의 Redo Log를 Redo Log File에 기록해 디스크 I/O에 대한 부하를 감소시키고 있다.

이와 같은 Log Force At Commit은 해당 데이터베이스를 확실하게 복구할 수 있는 방법을 제공한다.

복구 순서를 정하는 Logical Ordering Of Redo

Redo Log File은 트랜잭션별로 Redo Log를 생성해 기록하는 방식이 아니다. Redo Log File은 단지 OS의 파일이기 때문에 해당 파일의 위에서부터 아래로 빈 공간에 순서대로 Write하게 된다. 따라서 해당 Redo Log File로 복구하는 부분은 매우 복잡해 질 수 있다.

트랜잭션별로 Redo Log를 기록한다면 해당 트랜잭션별로 복구를 수행하면 되므로 복구는 매우 수월해질 수 있다. 하지만 이와 같은 방식으로 Redo Log를 Redo Log File에 기록한다면 변경된 블록은 데이터베이스 버퍼 캐시에 기록하는 것과 성능적으로 그다지 차이가 없을 것이다.

이와 같은 이유에서 Redo Log File에 Redo Log를 기록하는 과정에는 Logical Ordering Of Redo의 개념을 사용하게 된다.

• - Logical Ordering Of Redo : Redo Log File에 Redo Log를 기록하 는 과정에서 트랜잭션별로 물리적인 순서를 정하는 것이 아니라 SCN 에 의해 논리적인 순서를 정해 저장하는 기법

• [그림 2] Logical Ordering Of Redo
• 

이와 같이 논리적인 순서를 정해 저장하기 때문에 Redo Log File을 이용해 쉽게 복구할 수 있게 된다. 이와 같은 Logical Ordering Of Redo를 구현하기 위해 오라클 데이터베이스는 SCN이라는 기법을 이용하게 된다.

• - SCN : System Change Number의 약자로 오라클 데이터베이스의 데이터 정합성을 좌우하는 요소

데이터베이스 정합성을 좌우하는 SCN은 다음과 같은 특징을 가진다.

• - 각 Database는 하나의 Global SCN Generator를 가짐 : SCN은 유일한 값을 할당해 주어야 하므로 하나의 Generator에 의해 생성됨.
• - Database Committed Version 관리를 위한 Internal Clock : 모든 트랜잭션에 대해 SCN이 할당되며 SCN에는 시간을 포함하고 있음.
• - SCN은 트랜잭션 Commit 또는 Redo Recode의 Header에 할당 : SCN은 모든 경우에 할당하기 때문에 해당 SCN을 통해 복구 가능함.
• - SCN은 Consistency를 위해 사용 : SCN은 유일한 값을 할당하게 되므로 해당 값으로 데이터베이스 전체의 정합성을 보장할 수 있음.
• - SCN은 Control File 또는 데이터파일 Header에도 저장 : SCN은 Control File과 데이터파일 헤더에도 저장되어 Media Recovery에서도 사용됨.
• - 반영구적인 SCN 할당 : 초당 1만6,384개의 SCN을 할당할 수 있으며 500년 간 사용이 가능함.
• - SCN의 크기 : 하나의 SCN 크기는 총 6바이트이며 Wrap 번호 2바이트와 Base 4바이트로 구성되며 Base에 시간을 포함하고 있음.

결국, 오라클 데이터베이스는 Redo Log를 생성할 때도 SCN을 이용하며 복구에도 SCN을 이용하게 된다. SCN은 데이터베이스의 정합성을 책임지고 있는 가장 중요한 요소다.