DBMS 2

DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!

DB2 아키텍처 개요

DBMS 2
DB2 가이드
DB2 성능가이드
DB2 아키텍처 개요
작성자
admin
작성일
2021-02-19 15:04
조회
1321

DB2 아키텍처 개요

성능과 모니터될 수 있는 것을 이해하기 위해서는 DB2 아키텍처 관점에서 전반적으로 이해를 해야 한다. 이 장에서는 프로세스와 메모리 관점에서 살펴보도록 한다.


프로세스 모델

DB2에서의 프로세스 모델 또는 서버 아키텍처는 n-n 프로세스 모델로 알려져 있다. 이 아키텍처의 주요 특성은 데이터베이스 무결성을 보장하는 능력이다. 주요한 데이터베이스 자원들로부터 모든 데이터베이스 응용프로그램을 독립시킨다. 이 자원들은 데이터베이스 제어 블록과 주요한 데이터베이스 파일들이다.

데이터베이스 연결 과정동안 DB2 조정 에이전트는 각 데이터베이스 응용프로그램에 할당된다. 각각의 DB2 에이전트는 데이터베이스 응용프로그램을 대신하여 작업하고 모든 SQL 요청들을 다룬다. 응용프로그램과 데이터베이스 에이전트는 IPC(Inter Process Communication) 기술(메시지 큐, 공유 메모리, 세마포아 등)을 이용하여 통신한다. DB2 조정 에이전트는 파티션내 병렬 처리가 가능하다면, DB2 서브 에이전트와 함께 작업한다. 이 아키텍처는 잘못된 응용프로그램으로부터 데이터베이스 자원들을 보호하기 위해 방화벽을 제공한다.

그림 1-1. 프로세스 모델


그림 1-1. 프로세스 모델

DB2 에이전트는 Windows와 OS/2에서는 쓰레드(Thread)이나, UNIX 운영체제에서는 Process이다.

각 클라이언트 응용프로그램은 DB2 UDB 클라이언트 라이브러리와 링크되어 있고, 공유 메모리와 세마포아 (지역 클라이언트) 또는 TCP/IP와 APPC와 같은 통신 프로토콜 (원격 클라이언트)을 사용하여 DB2 UDB 서버와 통신한다.

서버 쪽에서는 활동이 EDU(Engine Dispatchable Unit)에 의해 제어된다. EDU는 AIX를 포함한 UNIX에서는 프로세스들로 구현된다.

1) DB2 에이전트

조정 에이전트와 서브 에이전트를 포함한 DB2 에이전트는 응용프로그램을 대신하여 SQL 문장들의 처리를 수행하는 DB2 UDB 프로세스들의 가장 일반적인 유형이다. DB2 UDB는 응용프로그램을 위한 처리를 조정하는 조정 에이전트를 할당하고 에이전트와 통신한다. 만약 파티션내 병렬 처리를 사용하지 않는다면, 할당된 조정 에이전트는 응용프로그램으로부터의 모든 요청들을 실행한다. 또한 파티션내 병렬 처리를 사용한다면, 응용프로그램에 할당된 서브 에이전트들의 집합이 응용프로그램 요청들을 처리하기위해 작업한다. 만약 데이터베이스 서버 머신이 복수의 프로세스들을 가진다면, 복수의 서브 에이전트들이 함께 작업하도록 함으로써 응용프로그램에 의해 요청된 복잡한 쿼리는 이 프로세스들을 활용하여 결과를 좀 더 빠르게 얻을 수 있다. 그림 1-1은 파티션내 병렬 처리가 가능한 것을 가정한다. UNIX에서는 ps 명령어를 사용하면 조정 에이전트 프로세스(db2agent)와 서브 에이전트(db2agntp)를 관찰할 수 있다.

2) 버퍼 풀

버퍼 풀은 사용자 테이블 데이터, 색인 데이터, 카탈로그 데이터의 데이터 페이지들이 디스크 저장공간에서 임시로 이동하는 저장 메모리 영역이다. DB2 에이전트들은 버퍼 풀에서 데이터 페이지들을 읽고 수정한다. 버퍼 풀은 데이터가 디스크에서보다 메모리에서 좀 더 빠르게 액세스되기 때문에 데이터베이스 성능의 주요한 요소이다. 응용프로그램에서 필요로 하는 많은 데이터가 버퍼 풀에 있다면, 데이터를 디스크 저장영역에서 찾는 데 소요되는 시간에 비해 이 데이터를 액세스하기 위해 필요한 시간이 덜 소요된다.

3) 프리페처

프리페처는 응용프로그램이 데이터를 필요로 하기 이전에 디스크에서 데이터를 추출하여 버퍼 풀로 이동하는 역할을 한다. 예를 들어, 데이터 프리페처가 없다면, 대량의 데이터를 스캔하는 응용프로그램이 데이터가 디스크에서 버퍼 풀로 이동되기를 기다려야 한다. 응용프로그램의 에이전트들은 비동기 미리 읽기 요청들을 공통의 프리페치 큐로 보낸다. 요청된 페이지들을 디스크에서 버퍼 풀로 가져오기 위해 프리페처는 대형 블록(Big-Block) 또는 스캐터 읽기 입력(Scatter Read Input) 운영방법을 사용함으로써 요청들을 수행한다. UNIX에서는 ps 명령어를 사용하면 프리페처 프로세스(db2pfchr)를 볼 수 있다.

4) 페이지 정리자

페이지 정리자는 프리페처가 디스크 저장 영역에서 페이지들을 읽어 버퍼 풀로 이동하기 전에 버퍼 풀에 방을 만들기 위한 역할을 한다. 예를 들어, 테이블내에 대량의 데이터를 갱신한다면, 버퍼 풀의 데이터 페이지는 변경되나 디스크 저장 영역에는 기록되지 않는다 (이러한 페이지들을 Dirty 페이지라고 함). 이 경우 프리페처는 변경이 디스크 저장 영역에 반영될 때까지 이 페이지들을 사용할 수 없다. 페이지 정리자는 응용프로그램 에이전트들과는 관계없이 버퍼 풀에 방이 있다는 것을 보장하기 위해 버퍼 풀에서 페이지들을 찾아 기록한다. UNIX에서는 ps 명령어를 사용하면 페이지 정리자 프로세스(db2pclnr)를 볼 수 있다.

서로 독립적인 프리페처와 페이지 정리자가 없어도, DB2 에이전트들은 버퍼 풀과 디스크 저장 영역 사이에 데이터를 읽고 기록하는 모든 일을 해야 한다. 버퍼 풀, 프리페처, 페이지 정리자들의 구성은 응용프로그램이 필요한 데이터의 가용성을 제어한다.

5) 로그

버퍼 풀내의 데이터 페이지에 대한 변경들이 로깅된다. 데이터베이스내에서 데이터 레코드를 변경하는 에이전트 프로세스들은 버퍼 풀내에 관련된 페이지를 변경하고, 로그 레코드를 로그 버퍼로 기록한다. 로그 버퍼에 기록된 로그 레코드들은 로거(Logger)에 의해 비동기적으로 로그 파일로 기록된다. UNIX에서는 ps 명령어를 사용하면 각 활동중인 데이터베이스에 대해서 로거 프로세스(db2loggr)를 볼 수 있다.

버퍼 풀에 갱신된 데이터 페이지나 로그 버퍼내의 로그 레코드는 성능을 최적화하기 위해 즉각적으로 디스크에 기록되지 않는다. 페이지 정> 로 거와 버퍼 풀 관리자는 관련된 로그 레코드가 로그에 기록되기 전에 변경된 데이터 페이지가 디스크 저장 영역에 기록되지 않는 것을 보장한다. 즉, 데이터베이스 관리자가 전원 중단 등으로 데이터베이스가 손상될 때 불일치 상태에 놓여 있는 데이터베이스를 보호하고 복구하기 위해 로그에서 충분한 정보를 얻을 수 있다는 것을 보장한다. 만약 데이터 페이지에 미확약된 변경이 디스크에 기록된다면, 데이터베이스 관리자는 변경을 취소하기(Undo) 위해 관련된 로그 레코드에서 Undo 정보를 사용한다. 또한 확약된 변경이 디스크에 반영되지 않았다면, 데이터베이스 관리자는 변경을 다시 하기(Redo) 위해 관련된 로그 레코드에서 Redo 정보를 사용한다. 이 매카니즘을 손상 복구(Crash Recovery)라고 한다. 데이터베이스 관리자는 데이터베??에 강제로 기록된다.


  • 일치하는 데이터 페이지가 디스크에 강제로 기록되기 전에(Write-ahead 로깅).
  • COMMIT시에. 그룹 확약 개?한 후에.
  • 로그 버퍼가 가득찰 때.

6) Fenced / Not Fenced 자원

데이터베이스 저장 프로시저는 CALL 문장을 사용하여 데이터베이스 응용프로그램에서 호출될 수 있는 동적으로 로드되는 라이브러리이다. 이 라이브러리는 DB2 데이터베이스 서버에 저장되고, Fenced 자원 또는 Not Fenced 자원으로써 실행될 수 있다. Fenced 자원은 데이터베이스 에이전트로부터 분리된 프로세스에서 실행되는 것이고, Not Fenced 자원은 데이터베이스 에이전트로써 같은 프로세스내에 실행된다.

Not Fenced 자원은 내부-프로세스 통신 오버헤드가 적기 때문에 Fenced 자원보다 더 나은 성능을 가지지만, Not Fenced 자원은 만약 제대로 테스트되지 않으면 DB2 제어 블록위에 다시 쓸수 있다.

7) 쿼리 병렬 처리

병렬 처리의 활용은 DB2에 대한 쿼리 뿐만 아니라 다른 관리 작업에 대해 상당한 성능 이점을 제공한다. 쿼리 병렬 처리에는 두가지 유형이 있다.


  • 쿼리간 병렬 처리(Inter-Query Parallelism)는 동시에 복수개의 응용프로그램이 데이타베이스를 쿼리할 수 있는 능력을 의미한다. 각 쿼리는 다른 쿼리들과 독립적으로 수행되나, DB2는 동시에 모든 쿼리들을 수행한다. DB2는 항상 이러한 유형의 병렬 처리는 지원해 왔다.
  • 쿼리내 병렬 처리(Intra-Query Parallelism)는 파티션내 병렬 처리(Intra-Partition Parallelism) 또는 파티션간 병렬 처리(Inter-Partition Parallelism) 또는 모두를 사용하여 동시에 단일 쿼리의 부분을 처리하는 것을 의미한다. 쿼리내 병렬 처리를 가지고, 단일 복잡한 쿼리는 DB2 옵티마이저에 의해 수행될 수 있고, 병렬로 수행될 수 있도록 여러 조각으로 나누어질 수 있다.
  • 파티션내 병렬 처리(Intra-Partition Parallelism)는 한 쿼리를 복수개의 부분으로 쪼개는 능력을 의미한다. 즉 색인 생성, 데이터베이스 로드, SQL 쿼리와 같은 단일 데이터베이스 작업을 복수개의 부분으로 세분하여, 단일 데이터베이스 파티션내에서 병렬로 실행한다. 파티션내 병렬 처리는 SMP 시스템에 매우 적합하다.

그림 1-2. 파티션내 병렬 처리 (Intra-Partition Parallelism)


그림 1-2. 파티션내 병렬 처리 (Intra-Partition Parallelism)

그림 1-2에서는 병렬로 수행될 수 있는 4개의 조각으로 쪼개져 결과가 순차적인 방식으로 수행되는 것보다 더 빨리 리턴되는 쿼리를 볼수 있다. 파티션내 병렬 처리를 이용하기 위해서는 병렬로 수행하는 쿼리의 조각의 수인 병렬 처리의 정도(Degree of Parallelism)를 선택하거나 시스템이 할 수 있도록 데이터베이스를 적절하게 구성하는 것이 필요하다.


파티션간 병렬 처리(Inter-Partition Parallelism)

파티션간 병렬 처리는 쿼리를 단일 머신 또는 복수개의 머신에서 분할된 데이터베이스의 복수 파티션 사이로 복수개의 부분으로 쪼개는 능력을 의미한다. 쿼리는 병렬로 수행된다. 파티션간 병렬 처리는 MPP 시스템에 매우 적합하다.

그림 1-3. 파티션간 병렬 처리 (Inter-Partition Parallelism)


그림 1-3. 파티션간 병렬 처리 (Inter-Partition Parallelism)

그림 1-3에서는 병렬로 수행될 수 있는 4개의 조각으로 쪼개쪄 결과가 단일 파티션에서 순차적인 방식으로 수행되는 것보다 더 빨리 리턴되는 쿼리를 볼 수 있다. 병렬 처리의 정도는 생성한 파티션의 수와 노드 그룹을 정의하는 방법에 따라 대개 결정된다. 파티션간 병렬 처리 뿐만 아니라 파티션내 병렬 처리와 파티션간 병렬처리의 조합이 가능하도록 DB2 EEE (Enterprise-Extended Edition)가 설치될 필요가 있다.


메모리 모델

데이터베이스 활동은 디스크 액세스(I/O)와 메모리 액세스(CPU)를 포함한다. 각각의DB2 구성 매개변수들은 메모리 또는 디스크 자원중에 영향을 미친다. 디스크 액세스는 메모리 액세스보다 훨씬 느리기 때문에 주요 데이터베이스 성능 조정의 목적 I/O wait 시간을 제거할 수 있다면, 데이터베이스 요청들은 CPU bound이고 성능을 증가하는 것은 좀 더 빠른 CPU 또는 복수개의 CPU들을 필요로 할 것이다.

DB2 UDB에 이용되는 구성 매개변수들중 시스템에서의 메모리 사용에 영향을 미치는 것이 많다. DB2 UDB가 사용하는 메모리 유형들은 그림 2-1과 같다. 이 그림에서는 파티션내 병렬 처리가 가능한 것을 가정한다.

그림 2-1. DB2 UDB가 사용하는 메모리 세크먼트


그림 2-1. DB2 UDB가 사용하는 메모리 세크먼트

  • 데이터베이스 관리자 공유 메모리(Database Manager Shared Memory)는 데이터베이스 관리자가 db2start 명령어를 사용하여 시작할 때 할당되고 db2stop 을 사용하여 데이터베이스 관리자가 중지될 때까지 할당된 채로 남아 있다. 이 메모리는 모든 데이터베이스 연결들 사이에 활동을 관리하기 위해 사용된다. 데이터베이스 관리자 공유 메모리에서 모든 다른 메모리가 부착되어 할당된다.
  • 데이터베Memory)는 데이터베이스가 ACTIVATE DATABASE 명령어를 사용하여 활성화될 때 또는 첫번째 응?터베이스에 할당된다. 데이터베이스 전역 메모리는 데이터베이스가 DEACTIVATE DATABASE 명령어를 사용하여 비활성화하거비활성화하거나 마지막 응용프로그램이 데이터베이스에 연결을 끊을 때까지 할당된 채로 남아 있다. 데이터베이스 전역 메모리는 버퍼 풀, 잠금 목록, 데이터베이스 힙, 유틸리티 힙과 같은 메모리 영역을 포함한다. 데이터베이스 관리자 구성 매개변수 NUMDB는 동시에 활동중인 데이터베이스의 최대 수를 정의한다. 만약 이 매개변수의 값이 증가한다면, 데이터베이스 전역 메모리 세그먼트의 수는 활동중인 데이터베이스의 수에 따라 증가한다.
  • 응용프로그램 전역 메모리(Application Global Memory)는 연결이 데이터베이스에 설정될 때 각 연결마다 할당되고 연결이 종료될때까지 할당된 채로 남아 있다. 이 메모리는 응용프로그램을 대신하여 작업하는 조정 에이전트와 서브 에이전트를 포함한 DB2 에이전트가 데이터를 공유하고 에이전트들 사이에 활동들을 조정하기 위해 사용된다. 파티션내 병렬 처리가 가능하거나 데이터베이스 관리?할된 데이터베이스 환경에 있다면, 응용프로그램 전역 메모리가 할당된다.
  • 에이전트 개인 메모리(Agent Private Memory)는 DB2 에이전트가 응용프로그램에 대해 작업하기 위해 할당될 때 DB2 에이전트마다 할당된다. 에이전트 개인 메모리는 특정 에이전트에 의해서만 사용되는 정렬 힙과 응용프로그램 힙과 같은 메모리 영역을 포함한다. DB2 에이전트는 현재의 요청에 대한 실행이 완료되어 에이전트 풀에 리턴할 때 할당된 정렬 힙을 포함한 에이전트 개인 메모리를 해제하지 않는다. 이것은 빠른 재사용을 위해 메모리를 유지함으로써 좋은 성능의 결과를 위함이다. 하지만 에이전트 풀의 크기를 증가하고자 한다면, 많은 유휴 에이전트가 대량의 메모리를 유지할 수도 있으므로 페이징 공간의 과도한 활동을 야기시킬 수 있다. 따라서 이러한 것을 피하기 위해 DB2 레지스트리 변수 DB2MEMDISCLAIM을 YES로 설정하면, DB2 UDB는 각 DB2 에이전트가 유지할 수 있는 메모리의 양을 정의한 DB2 레지스트리 변수 DB2MEMMAXFREE의 값에 따라, 에이전트 풀에 리턴할 에이전트와 연관된 메모리 일부 또는 전부를 포기(해제)한다.
  • 데이터베이스 구성 매개변수 MAXAPPLS는 데이터베이스에 동시에 연결할 수 있는 최대 수를 정의한다. 데이터베이스 관리자 구성 매개변수 MAXAGENTS는 인스턴스내에 조정 에이전트와 서브 에이전트를 포함한 DB2 에이전트의 최대 수를 정의한다. 만약 이 매개변수의 값이 증가하면, 응용프로그램 전역 메모리 세그먼트와 에이전트 개인 메모리 세크먼트의 수도 응용프로그램과 DB2 에이전트에 연결된 수에 따라서 증가한다.

그림 2-2.와 그림 2-3.은 메모리가 응용프로그램을 지원하기 위해 어떻게 사용되는지와 메모리의 크기를 조정할 수 있는 구성 매개변수들을 보여준다.

그림 2-2. 데이터베이스 관리자 공유 메모리(Database Manager Shared Memory) 개요


그림 2-2. 데이터베이스 관리자 공유 메모리(Database Manager Shared Memory) 개요

데이터베이스 관리자 공유 메모리는 데이터베이스 관리자가 수행하기 위해 필요하다. 이 메모리의 크기는 다음의 구성 매개변수에 의해 영향을 받는다.


  • 데이터베이스 시스템 모니터 힙 크기 (MON_HEAP_SZ)
  • 감사 버퍼 크기 (AUDIT_BUF_SZ)
  • FCM 버퍼 수 (FCM_NUM_BUFFERS)
  • FCM 메시지 앵커 수 (FCM_NUM_ANCHORS)
  • FCM 연결 항목 수 (FCM_NUM_CONNECT)
  • FCM 요청 블록 수 (FCM_NUM_RQB)

데이터베이스 관리자는 파티션내 병렬 처리가 사용되면, DB2 에이전트들 사이에 데이터를 전달하기 위해 FCM(Fast Communication Manager) 구성요소를 사용한다. 만약 파티션내 병렬 처리를 사용하지 않는다면, FCM 버퍼, 메시지 앵커, 연결 항목, 요청 블록에 필요한 메모리 영역이 할당되지 않는다.

데이터베이스 전역 메모리 세그먼트의 최대 크기는 다음의 구성 매개변수에 의해 결정된다.


  • 버퍼 풀 크기 (BUFFPAGE 구성 매개변수는 -1이 지정된 경우 사용됨)
  • 잠금 목록을 위한 최대 저장영역 (LOCKLIST)
  • 데이터베이스 힙 (DBHEAP)
  • 유틸리티 힙 크기 (UTIL_HEAP_SZ)
  • 확장 저장영역 메모리 세그먼트 크기 (ESTORE_SEG_SZ)
  • 확장 저장영역 메모리 세그먼트 수 (NUM_ESTORE_SEGS)
  • 패키지 캐쉬 크기 (PCKCACHESZ)

응용프로그램 전역 메모리는 다음의 구성 매개변수에 의해 결정된다.


  • 응용프로그램 제어 힙 크기 (APP_CTL_HEAP_SZ)

그림 2-3. 데이터베이스 에이전트/응용프로그램 개인/공유 메모리 개요


그림 2-3. 데이터베이스 에이전트/응용프로그램 개인/공유 메모리 개요

에이전트 개인 메모리 세그먼트의 최대 수는 다음의 매개변수에 의해 결정된다.


  • 응용프로그램 힙 크기 (APPLHEAPSZ)
  • 정렬 힙 크기 (SORTHEAP)
  • 문장 힙 크기 (STMTHEAP)
  • 통계 힙 크기 (STMT_HEAP_SZ)
  • 쿼리 힙 크기 (QUERY_HEAP_SZ)
  • UDF 공유 메모리 집합 크기 (UDF_MEM_SZ)
  • 에이전트 스택 크기 (AGENT_STACK_SZ)
  • 클라이언트 I/O 블록 크기 (RQRIOBLK) - 원격 클라이언트용

에이전트/응용프로그램 공유 메모리는 다음의 매개변수에 의해 영향을 받는다.


  • 응용프로그램 지원 계층 힙 크기 (ASLHEAPSZ)
  • 클라이언트 I/O 블록 크기 (RQRIOBLK) - 지역 클라이언트용