<오라클 성능 고도화 원리와 해법1> Ch01-02 DB 버퍼 캐시

오라클 성능 고도화 원리와 해법1 - Ch01 오라클 아키텍처 - 02 DB 버퍼 캐시

(1) 블록 단위 I/O

블록 단위로 읽는다는 의미는, 하나의 레코드에서 하나의 컬럼만을 읽고자 하더라도 레코드가 속한 블록 전체를 읽게 됨을 의미한다. 6장에서 자세히 설명하겠지만, 이는 데이터베이스 I/O 성능과 튜닝 원리를 이해하는 데 있어 아주 중요한 의미를 갖는다. SQL 성능을 좌우하는 가장 중요한 성능지표는 액세스하는 블록 개수이며, 옵티마이저의 판단에 가장 큰 영향을 미치는 것도 액세스해야 할 블록 개수다. 예를 들어, 옵티마이저가 인덱스를 이용해 테이블을 액세스할지 아니면 Full Table Scan 할지를 결정하는 데 있어 가장 중요한 판단 기준은, 읽어야 할 레코드 수가 아니라 블록 개수다.

(2) 버퍼 캐시 구조

SGA 내에는 수없이 많은 자료구조(Data Stucure)가 사용되고 있으며 그 중 가장 많이 사용되는 것이 해시 테이블(또는 해시 맵)이고, DB 버퍼 캐시도 해시 테이블 구조로 관리된다.

(3) 캐시 버퍼 체인

그림 1-9에는 표현하지 않았지만 각 해시 체인은 래치(Latch)에 의해 보호된다. DB 버퍼 캐시는 공유 메모리 영역인 SGA 내에 존재하므로 여러 프로세스에 의한 동시 액세스가 일어날 가능성이 크다. 따라서 같은 리소스에 대한 액세스를 반드시 직렬화(serialization)해야 하고, 이를 위해 구현된 일종의 Lock 메커니즘을 래치(Latch)라고 부른다.

래치를 획득한 프로세스만이 그 래치에 의해 보호되는 자료구조로의 진입이 허용된다.

하나의 cache buffers chains 래치가 여러 개 해시 체인을 동시에 관리한다는 사실도 기억할 필요가 있다.

그림1- 9에는 하나의 체인에 여러 개의 버퍼가 연결되도록 그렸지만 실제로는 하나의 체인에 하나의 버퍼만 달리는 것을 목표로 삼아야 하며, 그래야 목표한 해시 체인을 찾고서 추가적으로 스캔하는 비용을 최소화할 수 있다.

다시 얘기하지만, 래치는 데이터 자체를 보호하는 게 아니라 SGA에 공유돼 있는 자료구조를 보호하는 것이며, 그중 cache buffers chains 래치는 버퍼 캐시에 연결된 체인구조를 보호한다. 즉, 해시 체인을 스캔하거나 거기에 블록을 추가, 제거할 때 래치가 요구된다.

cache buffers chains 래치의 중요한 용도가 한 가지 더 있는데, 버퍼 헤더에 Pin을 설정할 때다. 이는 다음 절에서 자세히 다룬다.

(4) 캐시 버퍼 LRU 체인

버퍼 헤더는 해시 체인 뿐 아니라 LRU 체인에 의해서도 연결돼 있다. DB 버퍼 캐시는 한번 읽은 데이터 블록을 캐싱해 두는 메모리 공간이지만 메모리는 유한한 자원이어서 모든 데이터를 캐싱할 수는 없는 일이다. 따라서 버퍼 캐시가 사용빈도가 높은 데이터 블록들 위주로 구성될 수 있도록 LRU(least recently used) 알고리즘을 사용해 관리된다.

그림 1-10과 같은 컨베이어 벨트를 연상하면 LRU 알고리즘을 쉽게 이해할 수 있다.

[버퍼 상태]

모든 캐시 버퍼는 아래 세 가지 중 하나의 상태에 놓이게 된다.

• Free 버퍼 인스턴스 기동 후 아직 데이터가 읽히지 않아 비어 있는 상태(Clean 버퍼)이거나, 데이터가 담겼지만 데이터파일과 서로 동기화돼 있는 상태여서 언제든지 덮어 써도 무방한 버퍼 블록을 말한다. 오라클이 데이터 파일로부터 새로운 데이터 블록을 로딩하려면 먼저 Free 버퍼를 확보해야 한다. Free 상태인 버퍼에 변경이 발생하면 그 순간 Dirty 버퍼로 상태가 바뀐다.

• Dirty 버퍼: 버퍼에 캐시된 이후 변경이 발생했지만, 아직 디스크에 기록되지 않아 데이터 파일 블록과 동기화가 필요한 버퍼 블록을 말한다. 이 버퍼 블록들이 다른 데이터 블록을 위해 재사용되려면 디스크에 먼저 기록되어야 하며, 디스크에 기록되는 순간 Free 버퍼로 상태가 바뀐다.

• Pinned 버퍼 읽기 또는 쓰기 작업을 위해 현재 액세스되고 있는 버퍼 블록을 말한다.