오라클 캐시 메모리

캐시가 필요한 이유

디스크는 액추에이터(암)를 움직여서 데이터를 읽고 씁니다. 오라클은 디스크에 읽고 쓰는 것을 요청합니다. 오라클은 여러 개의 프로세스로 구성되어 있고 동시에 SQL 문을 처리할 수 있습니다. 또한， 프로세스는 역할 분담이 되어 있으며， SQL 문의 처리를 빠르게 하는 서버 프로세스와 그것을 보조하는 백그라운드 프로세스가 존재합니다. 이 내용을 정리한 것이 아래 그림입니다.
디스크가 동작하는 것은 매우 느리고 I/O 1회에 10~20밀리초 정도 걸립니다. 그래서 가능한 한 디스크에서 처리하지 않게 하려고 ‘캐시’라고 불리는 기술을 사용하고 있습니다.

캐시는 가장 간단한 튜닝 항목이기도 하며 잘 알려진 기능 중 하나이지만, 아 키 텍 처를 제대로 이해하고 있지 않으면 생각지도 못한 부분에서 ‘가져오고 싶었던 데이터 가 캐시에 존재하지 않아 성능이 좋지 않다’와 같은 결과를 초래합니다. 동작을 잘 이해하고 데이터베이스의 성능을 올려야 합니다.

 

캐시란?

일반적으로 캐시를 ‘작업장’이나 ‘작업대’에 비교하는 경우가 많습니다. 일할 때 빈번하게 사용하는 도구나 책을 필요할 때마다 서랍이나 책장에서 꺼내어 사용하고, 끝나면 바로 다시 서랍이나 책장에 집어넣는 식으로 사용하는 빈번하게 사용한다면 책상 위나 손이 잘 닿는 곳에 놔둘 것입니다. 캐시의 목적도 이것과 같습니다. 빈번하게 사용하는 데이터를 매번 디스크에서 꺼내 오지 않고 캐시라고 불리는 메모리에 둠으로써 빠르게 사용할 수 있도록 하는 것입니다. 

버퍼 캐시에 데이터가 적재되어 있지 않을 때는 속도가 느린 디스크에서 데이터를 꺼내올 수밖에 없으므로 그만큼 SQL의 처리가 늦어집니다.

 

데이터 관리 단위

오라클은 ‘블록’이라고 하는 단위로 데이터를 관리합니다. I /o의 단위도 블록을 기반으로 하고 있으며， 버퍼 캐시도 블록 단위로 관리하고 있습니다. 블록은 ‘정리용 상자’라고 생각해 주시면 됩니다. 크기가 작고 양이 많은 것을 정리할 때 상자를 몇 개 준비하고 그 안에 보관하는 경우가 있습니다. 오라클의 데이터는 수 바이트에서 수천 바이트 이상의 다수의 ‘행’으로 존재하므로 오라클도 블록이라고 하는 상자를 준비해서 보관하는 것입니다.

그림으로 공부하는 오라클 구조

그림처럼 한 개의 블록에는 여러 건의 데이터가 보관돼 있으므로 한 건만을 디스크에서 읽어 오려고 해도 필요한 데이터를 포함한 블록 자체가 캐시에 보관됩니다. 또한， 블록 크기는 2KB， 4KB, 8KB, 16KB, 32KB 중에서 고를 수 있습니다. 데이터와 캐시의 크기가 커짐에 따라 최근 시스템에서는 8KB를 채용하는 일이 많아졌습니다. 단， 크기가 큰 테이블을 시퀀셜 액세스로 읽어 오지 않으면 안 되는 DW(Data Warehouse, 데이터 웨어하우스) 등에는 16KB나 32KB 같은 크기를 선택할 때도 있습니다.

 

프로세스와 캐시

캐시를 프로세스마다 갖게 하면 낭비가 많으며, 다른 프로세스가 변경한 데이터를 볼 수 없는 등 여러 문제가 발생합니다. 그래서 캐시로 어떠한 오라클 프로세스라도 볼 수 있는 메모리를 활용합니다. 기본적으로 다른 프로세스의 메모리를 보는 것은 불가능합니다. 이유는 데이터에 손상을 입히지 않도록 OS가 보호하고 있기 때문입니다. DBMS 입장에서는 불편하기에 OS의 기능 중 특수한 메모리 기능이 제공되고 있는데， 이것이 ‘공유 메모리’입니다. 공유 메모리를 사용하면 자신의 메모리 영역에 기록했던 데이터를 다른 프로세스에서도 즉시 볼 수 있습니다 ‘실제 메모리는 한 개다’라는 개념이 공유 메모리를 이해하기 위한 중요한 포인트입니다. 각 프로세스에는 자신의 메모리인 것처럼 보이지만, 실제로는 모든 프로세스가 같은 메모리 영역에 접근하고 있는 것입니다. 또한, 오라클에서는 이런 공유 메모리를 ‘SGA(System Global Area)’, 공유하지 않는 메모리 일부를 ‘PGA(Program Global Area)’라고 부릅니다.

DBMS에서 공유 메모리는 매우 편리한 도구이기도 하지만, DBMS가 프로세스들로 구성되어 있기에 없어서는 안 될 필수 기능이기도 합니다. 하지만 누구든지 접근할 수 있으므로 락을 걸어서 배타 제어(exclusive control)를 하지 않으면 데이터에 손상을 입힐 수도 있습니다. 실제로는 내부적으로 락을 통해 데이터를 보호하고 있습니다. 하지만 이 말은 곧 DBMS의 내부에 많은 락이 존재하며, 내부에서 사용하는 락으로 인해 성능 문제가 발생하기 쉽다는 것을 의미하기도 합니다.

 

인덱스와 캐시

테이블뿐만이 아니라 인덱스도 블록으로 구성되어 있습니다. 인덱스를 한 블록에 보관할 수 없을 때는 여러 개의 블록으로 구성합니다. 인덱스의 크기가 매우 작지 않은 한 그림과 같이 단계를 가진 구조가 됩니다.

인덱스를 3단으로 만든 후에 테이블에서 인덱스를 사용해 데이터를 한 건만 꺼내 오는 SQL 문에 걸리는 시간을 예측해 보겠습니다. 테이블의 한 블록을 포함해 총 네 블록을 처리하지 않으면 안 되므로 I/O 한 번당 10밀리초라고 가정하면， 캐시에 적재되어 있지 않을 때는 I/O만 40밀리초가 걸리게 됩니다.
그것에 비해 이런 간단한 SQL을 처리하는 데 소요되는 CPU 시간은 1〜 2밀리초 정도입니다. 합계를 보면 캐시에 데이터가 없을 때 걸리는 처리 시간이 41~42밀리초이고. 캐시에 데이터가 있을 때 걸리는 처리 시간은 1〜 2밀리초입니다.

그림으로 공부하는 오라클 구조