권순용의 DB 이야기
데이터베이스의 수호자, Redo Log Buffer 2부. 0 1 4,201

by axiom Redo Log Buffer Page Fix Rule Write-Ahead Logging Change Vector Log Ahead [2013.12.19]


필자는 데이터베이스를 확실히 분석하기 위해 데이터베이스 Internal을 반드시 이해해야 한다고 지난 시간에 강조했다.

이번 강의에는 데이터베이스의 복구 및 데이터 정합성을 책임지는 Redo Log Buffer의 Page Fix Rule과 Write-Ahead Logging에 대해 확인해 보자.

데이터의 정합성을 위한 Page Fix Rule

데이터베이스를 Install하기 위해 사전 작업으로 세마포어를 설정하게 된다. 이와 같은 세마포어는 운영체제 수준의 락을 구현하게 된다.

Redo Log Buffer의 두 번째 사상은 이와 같은 세마포어를 이용한 Page Fix Rule이다.

  • [그림 1] Page Fix Rule의 이해
  • Page Fix Rule의 이해

  • - Page Fix Rule : 변경을 시도하는 블럭에 대한 모든 변경이 성공하기까지 다른 Access 방지

Page Fix Rule은 블록에 변경을 시도하는 순간에 해당 블록의 보호를 세마포어가 시작하는 과정을 의미한다.

세마포어에 의해 보호가 시작된 블록은 해당 블록에 대한 변경이 완료되고 Commit이 수행되는 시점까지 세마포어에 의해 변경을 방지하게 된다. 이와 같은 세마포어를 수행하는 단계를 확인해 보자.

  • 1. 블록에 대해 Read/Modify 전에 해당 Buffer Cache에 Lock을 수행
  • 2. 블록에 대해 Read/Modify 전에 해당 블록을 위한 Redo/Undo Change Vector를 생성
  • 3. 해당 Buffer에 대한 Undo를 이용한 Read Consistency 수행

이와 같이 Page Fix Rule은 변경되는 블록에 대한 데이터 정합성을 수행하며 이를 이용해 Redo를 생성하는 사상이다.

Redo/Undo Change Vector를 생성

두 번째 단계의 블록에 대해 Read/Modify 전에 해당 블록을위한 Redo/Undo Change Vector 생성에 대해 더 상세히 확인해 보자.

  • - Redo/Undo Change Vector : 블록 변경에 대한 가장 최소 단위의 트랜잭션

예를 들어 하나의 블록이 변경되는 경우 Undo Segment의 공간을 할당 받고 경우에 따라서는 Extent를 할당 받아 실제 작업을 수행하게 된다. 이와 같은 각각의 작업을 Change Vector라고 한다.

이와 같은 Change Vector의 모임을 Redo Record라고 부르며 Redo Record는 Change Vector보다는 큰 작은 트랜잭션을 의미한다.

  • [그림 2] 트랜잭션의 구성
  • 트랜잭션의 구성

[그림 2]와 같이 실제의 트랜잭션은 여러 개의 Redo Record로 구성되고 하나의 Redo Record는 실제 여러 개의 Change Vector로 구성된다.

완벽한 복구를 위한 Write-Ahead Logging

Redo Log Buffer의 세 번째 사상은 Write-Ahead Logging이다. 이를 Log Ahead라고도 부른다.

앞서 Redo Log Buffer의 가장 큰 목적은 복구에 있다고 언급했다. 블록이 변경된 후 Redo Log를 생성해 Redo Log Buffer에 저장한다면 어떻게 되겠는가?

블록이 변경된 후 Redo Log를 생성하지 못하고 데이터베이스가 비정상 종료를 한다면 해당 트랜잭션은 Redo Log가 존재하지 않기 때문에 복구를 수행할 수 없게 된다.

이와 같은 이유에서 오라클 데이터베이스는 블록을 변경하기 전에 반드시 Redo Log를 생성해야 하는 Write-Ahead Logging 기법을 사용하게 된다.

  • [그림 3] Write-Ahead Logging의 이해
  • Write-Ahead Logging의 이해

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

이와 같이 Write-Ahead Logging을 사용하게 되므로 완벽한 복구를 수행할 수 있게 된다. Write-Ahead Logging은 다음과 같이 두 가지 경우로 분리된다.

  • - Log Buffer Ahead
  • - Log File Ahead

Log Buffer Ahead

변경하기 위한 버퍼를 데이터베이스 버퍼 캐시에 캐싱한 후 실제 변경을 수행하기 전에 Redo를 Log Buffer에 먼저 기록하는 방식이다.

Log File Ahead

DBWR이 변경된 블록 버퍼를 데이터 파일에 기록하기 전에 LGWR이 Redo Record를 Redo Log File에 기록하는 방식이다.

LRU 알고리즘에 따라 DBWR에 의해 변경된 블록 버퍼를 데이터 파일에 기록하기 전에 해당 변경에 대한 Redo Record가 LGWR에 의해 Redo Log File에 기록되었는지를 확인한다.

확인 결과 LGWR에 의해 기록이 완료되었다면 DBWR은 해당 변경이 발생한 블록에 대해 데이터 파일에 기록할 수 있지만 LGWR에 의해 해당 Redo가 Redo Log File에 기록되지 않았다면 DBWR은 LGWR에 의해 해당 Redo가 Redo Log File에 기록될 때 까지 대기(Post/Wait)하게 된다.

이와 같은 Write-Ahead Logging에 의해 해당 데이터베이스는 완벽한 복구를 수행하게 된다.

- 강좌 URL : http://www.gurubee.net/lecture/2667

- 구루비 강좌는 개인의 학습용으로만 사용 할 수 있으며, 다른 웹 페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^

- 구루비 강좌는 서비스 제공을 위한 목적이나, 학원 홍보, 수익을 얻기 위한 용도로 사용 할 수 없습니다.

by 아발란체 [2013.12.20 13:42:45]
강좌를 통해 "Redo Log Buffer"이 어떤 사상을 가지고 있는지는 알겠는데 
이해 하려고 하면.... 머리가... 아프군요... ㅡ ㅁ ㅜ)ㆀ
아무튼 좋은 강좌 감사합니다 ~ !!!
댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입