아키텍처

아키텍처 개요

DB2 9.5이전 DB2프로세스 모델은 아래와 같습니다

DB2 9.5부터 다중 스레드 기반의 모델로 변경되었습니다.

단일 데이터베이스 파티션의 아키텍처

단일 데이터베이스 파티션으로 구성된 인스턴스의 아키텍처는 다음과 같습니다.

DB2 엔진은 고유한 기능을 담당하는 여러 개의 EDU(Engine Dispatchable Unit)로 구 성되어 있으며, 각 EDU는 UNIX에서는 스레드로 구현됩니다.

응용프로그램이 데이터베이스에 접속을 요청하면, 전용 Coordinator Agent 프로세스가 생성되어 응용프로그램을 대신하여 데이터베이스에게 필요한 SQL문의 실행을 요청하는 역할을 하게 됩니다. 클라이언트와 서버 사이의 통신에는 TCP/IP, APPC, Netbios 등의 프로토콜 이 지원됩니다.

에이전트 프로세스가 필요한 데이터를 가져오기 위하여 프리페치 큐를 통해 비동기 방식의 읽기 요청을 하면, 프리페처 프로세스는 big-block I/O를 통해 요청된 페이지들을 버퍼풀로 미리 가져오므로 에이전트 프로세스는 디스크 I/O 대기 시간을 줄일 수 있습니다.

페이지 클리너는 백그라운드 EDU로 특정 상황이 될 때마다 버퍼풀의 Dirty Page를 디스크로 미리 반영하여 버퍼풀의 가용 공간을 확보함으로써 버퍼풀을 사용하는 에이전트 프로세스가 대 기하는 일이 없도록 합니다.

변경된 데이터 페이지와 로그 레코드는 성능을 위해 디스크로 즉시 반영되지 않습니다. 변경된 데이터를 디스크에 반영할 때는 반드시 로그 파일에 먼저 기록됩니다. 이러한 방식을 Write Ahead Logging이라고 합니다.

다중 데이터베이스 파티션의 아키텍처

다중 데이터베이스 파티션으로 구성된 인스턴스의 아키텍처는 다음과 같습니다.

DB2 UDB의 Data Partitioning Feature는 다중 데이터베이스 파티션 기능을 이용하여 병렬 데이터베이스를 구축합니다. 다중 데이터베이스 파티션에 생성된 데이터베이스는 사용자에 게는 한 개의 논리적인 데이터베이스로 인식되지만, 각 파티션에 물리적으로 데이터베이스를 생 성합니다. 파티션별로 생성된 데이터베이스는 일반적인 단일 데이터베이스와 동일하게 독립적 인 자원을 사용할 수 있으므로 각 파티션은 버퍼풀, 잠금 관리, 디스크 등을 독립적으로 운영하게 됩니다.

데이터베이스 파티션은 동일한 머신에 생성되는 논리적 파티션과 다른 머신에 생성되는 물리적 파티션으로 구분됩니다. 동일한 머신에 존재하는 데이터베이스 파티션들은 공유 메모리를 이용 하여 통신하고, 다른 머신에 존재하는 데이터베이스 파티션끼리는 고속의 네트？을 통해서 필요 한 부분만 통신합니다.

응용프로그램이 접속을 요청하면, 접속한 데이터베이스 파티션에 Coordinator Agent 프로 세스가 생성되고, 다른 파티션에는 Subagent 프로세스들이 생성됩니다. SQL문은 Global optimizer에 의한 최적화된 후에 각 Subagent들에게 전송됩니다. Subagent가 해당 파 티션의 데이터베이스에 대해서만 SQL문의 요청을 처리하여 결과를 Coordinator Agent 프로세스에게 반환하면, Coordinator Agent는 응용프로그램에게 최종 결과를 반환합니다.

MPP 머신으로 구축한 DB2의 다중 데이터베이스 파티션 환경은 완전한 Shared Nothing Architecture를 제공하므로 확장성이 좋습니다

데이터베이스 시스템

DB2 UDB 데이터베이스 시스템은 엔진, 인스턴스, 데이터베이스로 구성됩니다. 엔진, 인스턴 스, 데이터베이스, 테이블스페이스 컨테이너 등은 물리적으로 분리되어 있으므로 제품의 재설치, 인스턴스의 재생성시에도 데이터베이스와 관련된 물리적인 파일은 보존되고, 필요시에 다시 사 용할 수 있습니다

DB2 UDB 제품 모듈은 AIX 머신에서는 default 경로인 /opt/ibm/db2/V9.7 디렉토리 에 설치되고, Windows 머신에서는 원하는 디렉토리에 설치됩니다. 한 개의 서버 머신에서 서 로 다른 디렉토리에 각각의 다른 버전의 제품의 설치가 가능합니다.

한 개의 서버 머신에서 여러 개의 인스턴스를 생성할 수 있습니다. AIX 머신에서는 인스턴스마 다 사용자 계정이 필요합니다.

root 사용자가 db2icrt 명령어를 이용하여 인스턴스를 생성하면, 인스턴스 사용자 계정의 홈 디렉토리에 sqllib 라는 서브디렉토리가 생성됩니다. sqllib에 생성된 일부 디렉토리와 파일은 제품이 설치된 /opt/ibm/db2/v9.7 디렉토리의 일부 서브디렉토리와 심볼릭 링크 (symbolic link)로 연결되거나 복사됩니다.

인스턴스 사용자가 db2start 명령어를 이용하여 인스턴스를 기동시키면, sqllib에 존재하는 파일들을 이용하여 인스턴스와 관련된 여러 개의 엔진 프로세스가 생성되고, 인스턴스 전역 메모 리가 할당됩니다.

인스턴스 사용자가 create database 명령어를 이용하여 데이터베이스를 생성하면, 특정 디렉토리에 데이터베이스 구성 파일을 비롯한 물리적인 디렉토리와 파일들이 생성됩니다.

데이터베이스에 접속한 후에 create tablespace 명령어를 이용하여 테이블스페이스와 컨 테이너를 지정하면, 실제 데이터를 물리적으로 독립적인 공간에 저장할 수 있습니다

단일 데이터베이스 파티션의 프로세스 모델

단일 데이터베이스 파티션으로 구성된 인스턴스에서는 다음과 같은 프로세스가 생성됩니다.

단일 데이터베이스 파티션 환경에서 DB2 프로세스는 인스턴스 레벨 에서만 보여진다.

데이터베이스 엔진과 관련된 프로세스들은 방화벽을 통해 외부의 응용프로그램 프로세스들과 다 른 address space를 사용하도록 구성되어 있으므로, 데이터베이스 제어 블록 및 중요한 데 이터베이스 파일과 분리되도록 설계되어 있습니다.

다중 데이터베이스 파티션의 프로세스 모델

다중 데이터베이스 파티션으로 구성된 인스턴스에서는 다음과 같은 프로세스가 생성됩니다.

다중 데이터베이스 파티션 환경에서 DB2 프로세스는 인스턴스, 카탈로그 파티션, 데이터베이스 파티션, 응용프로그램의 4가지 수준으로 분리됩니다.

인스턴스 수준의 프로세스

인스턴스 수준의 프로세스에는 db2fmcd, db2wdog, db2sysc, db2ckpwd, db2acd, db2fmd 등이 있습니다. 인스턴스 사용자가 db2start를 실행한 후에 ps 명령어 를 이용하여 확인할 수 있습니다.

인스턴스가 기동될 때, 최초로 생성되는 기본 프로세스는 다음과 같습니다.

인스턴스 수준의 프로세스

지역 또는 원격에서 데이터베이스에 대한 접속을 요청하면, 클라이언트와 서버 머신 사이에 사용 되는 통신 프로토콜의 유형에 따라 다음과 같은 통신 리스너 스레드가 db2agent 라는 EDU 를 생성하여 응용프로그램과 엔진을 연결시켜 줍니다.

인스턴스 수준의 프로세스

아카이브 로깅만 사용되거나, UserExit 프로그램을 이용하여 아카이브 로깅을 하는 경우에는 다 음과 같은 프로세스가 관련됩니다

인스턴스 수준의 프로세스

특정한 DB2 명령어 또는 유틸리티를 실행할 때 생성되는 프로세스는 다음과 같습니다

인스턴스 수준의 프로세스

DPF를 사용하여 다중 데이터베이스 파티션 환경을 구성한 경우에만 생성되는 프로세스들은 다 음과 같습니다.

global deadlock 의 작동 원리를 이해하기 위하여 다음과 같은 상황을 가정하도록 합니다. 두 개의 트랜잭션 Trans1과 Trans2가 있습니다. 두 트랜잭션은 각각 한 개의 SQL문에 대한 subsection1과 subsection2 를 두 개의 파티션에서 병렬로 실행시키려고 합니다. trans1은 파티션2에서 subsection2의 작업을 먼저 끝내고, 파티션1에서 subsection1 이 작업 결과 또는 메시지를 반환하기를 대기하고 있지만, subsection1은 파티션1에서 trans2의 subsection2가 lock을 걸고 있기 때문에 잠금 대기 상태에 있습니다. trans2는 파티션1에서 subsection2의 작업을 먼저 끝내고, 파티션2에서 subsection1 이 작업 결과 또는 메시지를 반환하기를 대기하고 있지만, subsection1은 파티션2에서 trans1의 subsection2가 lock을 걸고 있기 때문에 잠금 대기 상태에 있습니다. 다중 파티션 환경에서 서로 잠금을 대기하는 교착 상황이 발생하게 되면, db2glock 프로세스 가 점검하여 한 쪽의 응용프로그램을 강제로 종료시킵니다.

인스턴스 수준의 프로세스

Fault Monitor 와 연관된 프로세스입니다

db2fmcd 프로세스는 기본적으로 시스템 부팅시에 자동적으로 시작되도록 /etc/inittab 파일에 등록되어 있습니다. 자동적으로 시작되는 것을 원하지 않는다면, 해당 명령행을 주석으 로 처리하도록 합니다.

인스턴스 수준의 프로세스

OS와 관련된 작업을 수행하는 프로세스는 다음과 같습니다.

데이터베이스 수준의 프로세스

db2pfchr 와 db2pclnr 프로세스는 버퍼풀과 테이블스페이스 컨테이너 사이의 비동기적인 I/O를 담당합니다.

db2pclnr 프로세스는 다음과 같은 경우에 활동하게 됩니다.

데이터베이스 수준의 프로세스

데이터베이스 로그 파일의 I/O 와 연관된 프로세스입니다.

테이블스페이스의 복구와 연관된 프로세스입니다.

데이터베이스 수준의 프로세스

아카이브 로그 파일의 USEREXIT 과 연관된 프로세스입니다.

데이터베이스 수준의 프로세스에는 다음과 같은 프로세스들도 있습니다.

응용프로그램 수준의 프로세스

통신 리스너 프로세스는 지역 또는 원격 응용프로그램이 데이터베이스에 대한 접속을 요청하면 다음과 같은 에이전트 프로세스를 생성합니다.

단일 데이터베이스 파티션에서 INTRA_PARALLEL 인스턴스 구성 변수를 이용하여 파티션내 (Intra-Partition) 병렬 처리를 지정한 경우에 db2agent와 db2agntp 프로세스의 관계 는 다음과 같습니다

응용프로그램 수준의 프로세스

Subagent로 생성되어 사용이 완료된 프로세스는 성능을 위해 즉시 제거하지 않고 Agent Pool 에 저장하였다가 재사용할 수 있습니다

응용프로그램이 접속을 요청했을 때, Agent 프로세스를 할당하는 우선 순위는 다음과 같은 방 법으로 결정됩니다.

응용프로그램 수준의 프로세스

병렬 복구 처리를 위한 프로세스입니다

아래 그림에서 Coordinator Agent는 읽어온 로그 레코드를 병렬 프리페처를 이용하여 버 퍼풀로 저장합니다. Parallel Recovery Agent 들은 버퍼풀의 데이터를 이용하여 병렬로 복구 작업을 진행합니다.

메모리 모델

DB2 메모리는 다음과 같이 4가지로 구성됩니다.

각 메모리별 특성은 다음과 같습니다.

인스턴스 공유 메모리

인스턴스 공유 메모리는 db2start 명령어로 엔진 기동시에 할당되며, 인스턴스에 존재하는 모 든 EDU들은 이 영역을 액세스할 수 있습니다

할당된 인스턴스 공유 메모리의 양은 db2mtrk 명령어로 확인할 수 있습니다.

인스턴스 공유 메모리는 다음과 같은 메모리 영역으로 구성됩니다.

데이터베이스 공유 메모리

데이터베이스 공유 메모리는 activate db 명령어로 데이터베이스 활성화시에 할당되며, 해 당 데이터베이스에 연관된 모든 EDU들은 이 영역을 액세스할 수 있습니다.

할당된 데이터베이스 공유 메모리의 양은 db2mtrk 명령어로 확인할 수 있습니다.

데이터베이스 공유 메모리의 양은 get snapshot for db 명령어로 확인할 수 있습니다

데이터베이스 공유 메모리

데이터베이스 공유 메모리는 다음과 같은 메모리 영역으로 구성됩니다.

응용프로그램 공유 메모리

응용프로그램 공유 메모리는 응용프로그램의 첫 번째 에이전트 프로세스가 데이터베이스에 연결 을 요청하는 경우에 할당되며, 응용프로그램이 완료되면, 반환됩니다. 해당 응용프로그램과 연관 된 모든 EDU들이 액세스할 수 있습니다.

응용프로그램 공유 메모리는 응용프로그램의 첫 번째 에이전트 프로세스가 데이터베이스에 연결 을 요청하는 경우에 할당되며, 응용프로그램이 완료되면, 반환됩니다. 해당 응용프로그램과 연관 된 모든 EDU들이 액세스할 수 있습니다.

SQL문의 파티션 내 병렬 처리 수준은 CURRENT DEGREE 특수 레지스터 또는 DEGREE 바인드 옵션을 사용하여 명령문 컴파일시 지정됩니다. 기본값은 DFT_DEGREE 데이터베이스 구성 변수에 지정된 값입니다. 실행 중인 응용프로그램의 파티션 내 병렬 처리의 최대 런타임 수 준은 SET RUNTIME DEGREE 명령을 사용하여 지정됩니다.

에이전트 공유 메모리는 다음과 같은 메모리 영역으로 구성됩니다.

응용프로그램 개별 메모리

에이전트 개별 메모리는 connect 명령어로 데이터베이스에 접속할 때 생성되는 에이전트 프 로세스에게 개별적으로 할당되는 메모리 영역입니다.

할당된 데이터베이스 공유 메모리의 양은 db2mtrk 명령어로 확인할 수 있습니다

특정한 에이전트 개별 메모리의 양은 확인하려면, list applications 명령어로 에이전트에 대 응되는 핸들 번호를 확인합니다.

get snapshot for application 명령어에서 agentid 옵션으로 특정한 에이전트 개별 메모리의 양을 확인합니다.

응용프로그램 개별 메모리

에이전트 개별 메모리는 다음과 같은 메모리 영역으로 구성됩니다.

Thread 모니터링

아키텍처가 변경됨에 따라 DBA도 관리방법이 변경됩니다

db2sysc가 1921135 입니다. AIX에서 모든 Thread를 확인하려면 아래와 같이 입력합니 다.

Memory 사용량 모니터링

4가지 방법이 제공됩니다.

db2pd 사용

db2 get snapshot 사용

Memory 사용량 모니터링

SQL 사용

db2mtrk 사용 (db2mtrk ？a 또는 db2mtrk ？p)