전문가칼럼

DBMS, DB 구축 절차, 빅데이터 기술 칼럼, 사례연구 및 세미나 자료를 소개합니다.

[DB이야기][Internal Is Internal 데이터베이스의 수호자, Redo Log Buffer (2)

전문가칼럼
DBMS별 분류
DB일반
작성자
dataonair
작성일
2011-07-12 00:00
조회
22339




◎ 연재기사 ◎


[DB 이야기] Internal Is Internal 데이터베이스의 수호자, Redo Log Buffer (1)


[DB이야기][Internal Is Internal 데이터베이스의 수호자, Redo Log Buffer (2)


[DB이야기]Internal Is Internal 데이터베이스의 수호자, Redo Log Buffer (3)


Internal Is Internal 데이터베이스의 수호자, Redo Log Buffer (4)


Internal Is Internal 데이터베이스의 수호자, Redo Log Buffer (5)


Internal Is Internal 데이터베이스의 수호자, Redo Log Buffer (6)


Internal Is Internal Redo Log Buffer의 Latch



권순용의 DB 이야기

Internal Is Internal 데이터베이스의 수호자, Redo Log Buffer (2)

필자는 데이터베이스를 확실히 분석하기 위해 데이터베이스 Internal을 반드시 이해해야 한다고 지난 시간에 강조했다. 이번 시간에는 데이터베이스의 복구 및 데이터 정합성을 책임지는 Redo Log Buffer의 Page Fix Rule과 Write-Ahead Logging에 대해 확인해 보자.

데이터의 정합성을 위한 Page Fix Rule
데이터베이스를 Install하기 위해 사전 작업으로 세마포어를 설정하게 된다. 이와 같은 세마포어는 운영체제 수준의 락을 구현하게 된다. Redo Log Buffer의 두 번째 사상은 이와 같은 세마포어를 이용한 Page Fix Rule이다. - Page Fix Rule : 변경을 시도하는 블럭에 대한 모든 변경이 성공하기까지 다른 Access 방지

110712_img01.jpg

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보다는 큰 작은 트랜잭션을 의미한다.

110712_img02.jpg
<그림 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 기법을 사용하게 된다.

110712_img02.jpg

- 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에 의해 해당 데이터베이스는 완벽한 복구를 수행하게 된다.

필자소개

권순용 kwontra@hanmail.net|Data Consulting 업무를 수행하는 엑시엄의 대표이사이며 DBA로 시작해 SQL 튜닝, 데이터베이스 아키텍처 및 모델링 업무를 주로 수행했다. 데이터베이스 교육에도 많은 관심을 가지고 있으며 저서로는 『Perfect! 오라클 실전 튜닝』, 『초보자를 위한 오라클 10g』 및 『INSIDE SQL』이 있다. 또한, 데이터 액세스 최적화에 대한 특허를 출원했다.