[Oracle] 오라클 아키텍처 2

오라클 데이터베이스 

 

아키텍처

리스너(Listener)에 연결요청을 하는 순간 하나의 프로세스를 뛰우고(fork) PGA 메모리를 할당한다는 사실이다. 이는 비용이 매우 큰 작업이므로 하나 또는 일련의 SQL문을 수행하기 위해 매번 연결요청을 한다면 결코 성능이 좋을 리 없다. 오라클에 접속하는 애플리케이션을 구축할 때 반드시 커넥션 풀(Connection Pool)기능이 필요한 이유가 여기에 있다.

Listener

한번 커넥션을 맺으면 작업을 완료하더라도 이를 해제하지 않고 애플리케이션 서버에 Pooling 하고 있다가 반복 재사용한다. 뒤에서 라이브러리 캐시 최적화 원리, DB 버퍼캐시 최적화 원리를 공부하면서 느끼겠지만 그 모든 것이 재사용성과 관련 있다. 소프트웨어 세계에서 가장 중요한 화두인 재사용성은 데이터베이스 성능 튜닝의 핵심 원리이기도 하다.

PGA(Private=Program Global Area) 는 서버프로세서만을 위한 독립적인 메모리 공간이다. SGA는 서버프로세스와 백그라운드가 공통으로 액세스하는 데이터와 제어구조를 담는다.

기본적인 구성으로 오라클을 설치하면 하나의 데이터베이스에 접근하는 하나의 인스턴스(메모리와 프로세스 집합)가 생성되지만 RAC(Real Application Cluster) 환경에서는 하나의 데이터베이스를 액세스하는 다중 인스턴스로 구성된다.

그뿐만 아니라 RAC 모델은 데이터파일만 공유하는 과거의 공유 디스크(Shared Disk) 방식에서 더 진일보한 공유 캐시(Shared Cache)방식을 지원한다. 글로벌 캐시(Global Cache)개념을 사용하므로 로컬 캐시(Local Cache)에 없는 데이터 블록을 이웃 노드에서 전송받아 서비스할 수 있다. 각 인스턴스를 고속의 전용 네트워크로 연결하기 때문에 가능한 일이다.

심지어 다른 인스턴스에서 갱신하고 아직 커밋하지 않은 Active 상태의 블록까지도 디스크를 경유하지 않고 Dirty 버퍼(메모리와 디스크 간에 동기화되지 않은 버퍼) 상태에서 네트워크를 통해 서로 주고받으며 갱신을 수행한다. Lock을 포함한 데이터 직렬화 매커니즘에 익숙한 분이라면 이것이 얼마나 놀라운 기술인지 이해할 것이다.

RAC 이전 OPS 환경에서는 타토드에 캐싱된 Dirty 버퍼를 읽고자 할 때 디스크로의 쓰기 작업이 선행되어야만 했고, 이처럼 디스크를 거치는 동기화 과정을 'Ping'이라고 불렀다.

 

 

※ 오라클 아키텍처에 대해 다시 Remind 하기 위해 2009년에 발간된 "오라클 성능 고도화 원리와 해법1" 을  책장에서 꺼내어 블로그로 옮겨 보았다.