[Oracle] SGA Database Buffer Cache DBC 데이터베이스 버퍼 캐시 사용원리 :: 마이자몽

SGA Shared Pool 관련 글

[Oracle] SGA Shared Pool 공유풀 사용 원리 :: 마이자몽

 

 

Database Buffer Cache

이전 글에서 SGA 구성요소 Shared Pool에 Parse된 공유 데이터에 대해서 알아봤습니다. 이번 글에서는 Parse에 이어서 Select문 요청이 들어왔을 때 Execute 단계를 Database Buffer Cache(DBC)의 역할을 알아보겠습니다.

 

DBC는 4가지 구성요소를 갖고 있습니다.

Keep Buffer Cache : 자주 사용되는 테이블을 지정하용 사용되는 Buffer
Recycle Buffer Cache : 자주 사용되지 않는 테이블을 지정하여 사용되는 Buffer
Default Buffer Cache : 그외 일반 기본 Buffer
nK Buffer Cache : 다른 Block Size의 테이블이 있다면 사용

 

Database Buffer Cache는 검색된 Data Block의 복사본을 Buffer에 저장합니다. 공유메모리 영역에 있어 모든 유저가 동시에 사용할 수 있으며 Data Block Size와 동일한 크기의 Buffer를 갖고 있습니다.

 

 

 

Select Process

Shared Pool에서 Parse된 데이터를 올리고  SQL문을 실행할 준비를 끝냈습니다. 이제 Execute 단계에서 실행 계획에 따라 데이터를 읽어야하는데 이 과정에서 Database Buffer Cache를 어떻게 사용하는지 알아보겠습니다.

 

 

 

Execute

1. User Process Query문 실행 요청
2. Parse
3. DB File Data Block, Database Buffer Cache로 복사
4. Server Process, Database Buffer Cache 읽어 필요한 데이터 받아옴
5. Fetch

전체 흐름은 위와 같습니다. 요청이 들어오면 Server Process는 직접 DB File을 읽지 않고 먼저 Database Buffer Cache에 Data Block을 복사하고 Database Buffer Cache에 있는 Block을 읽어옵니다. 한번에 접근하지 않고 Cache를 통해서 데이터를 읽는 이유는 왜일까요? 결론적으로 속도 때문입니다. 논리적 읽기(Logical Read)와 물리적(Physical Read)에 대해서 알아보면서 속도의 차이를 알아보겠습니다.

 

 

 

논리적 읽기와 물리적 읽기

논리적 읽기(Logical Read) 
읽으려는 Data Block Address가 Database Buffer Cache에 있어 I/O 없이 데이터를 읽을 수 있는 방식입니다. Cache Hit이라고도 합니다.

물리적 읽기(Physical Read)
읽으려는 Data Block Address가 Database Buffer Cache에 없고 Datafile에 있어 I/O를 통해 데이터를 읽어야하는 방식입니다. Cache Miss라고도 합니다.

 

Data Block Address가 DB File에 존재한다면 I/O를 통해서 데이터를 Database Buffer Cache에 올려야합니다. 만약 Database Buffer Cache에 존재한다면 I/O없이 데이터를 읽을 수 있기 때문에 속도적인 측면에서 10만 ~ 20만배 정도가 차이가 난다고 합니다. 즉, Database Buffer Cache의 존재 이유는 논리적 읽기를 최대한 많이 하도록 하는 것 입니다.

 

 

 

Database Buffer Cache 메모리관리

논리적인 읽기를 최대한 많이 하도록 하는 방법은 모든 데이터가 Database Buffer Cache에 존재하는 것이겠죠? 하지만, 제한된 메모리기 때문에 관리는 필수 입니다.

 

새로운 데이터가 들어왔을 때 메모리를 할당해줘야합니다. 만약 할당 공간이 부족하면 기존 메모리에 대한 처리가 필요합니다. 메모리 관리 이전에 Database Buffer Cache의 Buffer들의 상태를 알아야합니다.

Buffer Status
Free : 사용해도 되는 Buffer
Clean : Buffer의 데이터와 DB File내의 데이터가 일치하는 상태
Pinned : 현재 사용중인 Buffer. 누군가 변경하거나 읽고 있는 상태
Dirty : Buffer의 데이터와 DB File내의 데이터가 불일치 하는 상태

 

Buffer의 상태가 Free이거나 Clean일때 메모리 할당은 문제 없습니다. 하지만, Pinned나 Dirty의 상태에서는 할당해줄 수 없습니다. Pinned의 경우 누군가 사용하고 있는 상태이기 때문에 메모리 할당이 불가능합니다. Dirty의 경우, DB File과 Buffer의 데이터가 일치하지 않아 메모리를 할당 했다가 일관되지 않는 데이터를 읽을 수 있습니다.

 

Database Buffered Cache는 기본적으로 Shared Pool과 같이 LRU(Last Recently Used) 알고리즘을 사용합니다. 그런데 만약 가장 최근에 사용하지 않은 데이터가 Dirty한 상태이면? 메모리 할당을 못해주잖아요? 그래서 Touch Count가 가미된 LRU 알고리즘을 사용한다고 하네요.

 

만약 모든 Buffer가 Free한 공간이 없다면 어떻게 될까요? 이런 문제를 방지하기 위해 Oracle의 Background Process중에 DBWR(Database Writer)가 열일 해줍니다.

 

 

 

DBWR Database Writer

DBWR는 Dirty 상태인 Buffer를 Free한 상태로 변경해주는 작업을 합니다. Dirty상태의 Buffer가 생기면 따로 Dirty List에 넣어줍니다. 이후 Dirty를 Free로 변경이 필요할때 DBW가 Dirty List에 있는 Buffer들의 변경된 내용을 DB File에 적용시켜줍니다. 아래와 같은 상황에서 DBWR 프로세스가 일을 시작합니다.

1. FREE BUFFER를 찾기 위해 LRU LIST를 임계길이(Threshold Length) 만큼 찾았을 때
메모리 관리를 위해 LRU LIST에서 FREE한 BUFFER를 찾습니다. 너무 오랜 시간 탐삭하는 것은 비효율적이기 때문에 Threshold Length로 지정된 길이까지 Free한 Block을 못 찾으면 Dirty List에 들어있는 내용을 Disk에 반영합니다.

2. Dirty List의 길이가 임계길이만큼 늘어났을 때
한번에 너무 많은 양은 반영시키는 것을 방지하기 위해 Dirty List가 임계길이만큼 늘어나도 DBWR가 일을 합니다.

3. Timeout 시간 3초 마다
지정된 Timeout 시간마다 DIsk에 반영합니다.

4. Check Point 이벤트가 발생할 때
Check Point는 메모리에 있는 내용을 디스크에 맞춰주는 것 입니다.

 

 

Redo Log Buffer Update 참조 글

[Oracle] SGA Redo Log Buffer 리두 버퍼 사용원리 :: 마이자몽