<오라클 성능 고도화 원리와 해법1> Ch01-01 기본 아키텍처

오라클 성능 고도화 원리와 해법1 - Ch01 오라클 아키텍처 - 01 기본 아키텍처

같은 원리로 오라클은 데이터베이스(데이터를저장하는파일집)와 이를 액세스하는 프로세스 사이에 SGA라고 하는 메모리캐시 영역을 두고 있다(그림 1-3).

워드 프로세서와의 가장 큰 차이점은, 많은 프로세스가 동시에 데이터를 액세스한다는 사실이다. 이 때문에 사용자 데이터를 보호하는 Lock은 물론 공유 메모리 영역인 SGA(System Global Area 또는 Shared Global Area)상에 위치한 데이터 구조에 대한 액세스를 직렬화하기 위한 LOCK 메커니즘(=래치, Latch)도 필요해진다.

오라클도 백그라운드에서 DBWR와 CKPT 프로세스가 캐시와 데이터파일 간 동기화를 수행해준다.

DBMS마다 데이터베이스에 대한 정의가 조금씩 다른데, 오라클에서는 디스크에 저장된 데이터 집합(Datafile, Redo Log File, Control File 등) 을 데이터베이스(Database)라고 부른다.그리고 SGA 공유 메모리 영역과 이를 액세스하는 프로세스 집합을 합쳐서 인스턴스(Instance)라고 부른다(그림1- 3참조).

그림 1-4는 오라클 인스턴스를 표현한 것인데, 그림에서 보듯 프로세스 집합을 다시 서버 프로세스와 백그라운드 프로세스 집합으로 나눌 수 있다. 서버 프로세스는 전면에서 사용자가 던지는 명령을 처리하고, 백그라운드 프로세스는 보이지 않지만 뒤에서 묵묵히 주어진 역할을 수행한다.

오라클에 접속하면 각 클라이언트를 위한 전용 서버 프로세스가 떠서(Shared Server로 구성하지 않는다면) 사용자에게 필요한 서비스를 제공한다. SQL을 파싱하고 필요하면 최적화를 수행하며, 커서를 열어 SQL을 실행하면서 블록을 읽고, 읽은 데이터를 정렬해서 클라이언트가 요청한 결과집합을 만들어 네트워크를 통해 전송하는 일련의 작업들을 모두 서버 프로세스가 처리해준다. 일하는 도중에 스스로 처리하지 못하는 일들(데이터파일로부터 DB버퍼 캐시로 블록을 적재하거나 Dirty 블록을 캐시에서 밀어냄으로써 Free 블록을 확보하는 일, 그리고 Redo 로그 버퍼를 비우는 일 등등)을 만나면 OS , I/O 서브시스템, 백그라운드 프로세스 등에 신호를 보내 대신 일을 처리하도록 요청한다.

그림 1-5는 오라클에 접속할 때 내부적으로 어떤 과정을 거쳐 세션이 수립되는지를 잘 보여준다.

주목할 점은, 리스너(Listener)에 연결요청을 하는 순간 하나의 프로세스를 띄우고(fork) PGA 메모리를 할당한다는 사실이다. 이는 비용이 매우 큰 작업이므로 하나 또는 일련의 SQL문을 수행하기 위해 매번 연결요청을 한다면 결코 성능이 좋을 리 없다. 오라클에 접속하는 애플리케이션을 구축할 때 반드시 커넥션 풀(Connection Pool) 기능이 필요한 이유가 여기에 있다(그림 1-6). 한번 커넥션을 맺으면 작업을 완료하더라도 이를 해제하지 않고 애플리케이션 서버에 Pooling 하고 있다가 반복 재사용한다. 뒤에서 라이브러리 캐시 최적화 원리, DB 버퍼 캐시 최적화 원리를 공부하면서 느끼겠지만 그 모든 것이 재사용성과 관련 있다. 소프트웨어 세계에서 가장 중요한 화두인 재사용성은 데이터베이스 성능 튜닝의 핵심 원리이기도 하다. Process(=Program=Private) Global Area의 약어로서, 서버 프로세스만을 위한 독립적인 메모리 공간이다. SGA(System Global Area)는 서버 프로세스와 백그라운드 프로세스가 공통으로 액세스하는 데이터와 제어 구조를 담는다.

기본적인 구성으로 오라클을 설치하면 하나의 데이터베이스에 접근하는 하나의 인스턴스(메모리와 프로세스 집합)가 생성되지만 RAC(Real Aplication Cluster) 환경에서는 하나의 데이터베이스를 액세스하는 다중 인스턴스로 구성된다(그림 1-7). 그뿐만 아니라 RAC 모델은 데이터파일만 공유하는 과거의 공유디스크(Shared Disk) 방식에서 한층 더 진일보한 공유 캐시(Shared Cache) 방식을 지원한다. 글로벌 캐시(Global Cache) 개념을 사용하므로 로컬 캐시(Local Cache)에 없는 데이터 블록을 이웃 노드에서 전송 받아 서비스할 수 있다. 각 인스턴스를 고속의 전용 네트워크로 연결하기 때문에 가능한 일이다.

여기서 RAC에 대한 내용을 깊이 있게 다루려는 것은 아니며 데이터베이스와 인스턴스에 대한 개념을 설명하기 위해 잠시 살펴보았다. (RAC에서 인스턴스 간에 블록을 전송하는 메커니즘에 대해서는 6장에서 자세히 설명한다.)

지금까지 오라클의 가장 기초적인 아키텍처를 살펴보았고, 이제 좀 더 깊이 있는 아키텍처의 세계로 들어가려고 한다.

• 6절과 7절에서는 Consistent 모드 읽기를 집중적으로 해부하고, Current 모드 읽기와의 차이점을 명확히 밝힌다.

하지만 앞에서도 언급했듯이 6절과 7절이 본 장에서 설명하려는 핵심 주제고, 이를 통해 오라클만의 독특한 읽기 일관성(Read Consistency) 모델을 이해하게 된다면 그것으로 성공이다. 나머지 내용은 대충 의미만 파악하더라도 다른 장을 이해하는 데 별 지장이 없으므로 가볍게 읽어나가기 바란다.