BLOTER.NET

Oracle 사용자를 위한 DB2 Conversion 프로젝트|DB2 아키텍처이해

김명훈, DB2 프리랜서 DBA

현재 DB2 프리랜서로 일하고 있으며 근래 주요 DB2 프로젝트는 POSCO 열연 생산관리 시스템 구축, K-Power DSS 시스템 설계 구축, 삼성 DB2 Monitoring 컨설팅 등을 담당하였다.

DB2에서 데이터 조회/변경 시 사용되는 메커니즘과 DB2의 주요 프로세스&메모리에 대해서 알아 보도록 하겠다.

1. DB2 데이터 조회 및 변경 메커니즘

우선 데이터베이스에 접속하기 위해서는 인스턴스가 기동(db2start) 되어 있는 상태에서 db2 “connect to [DB이름] user [user명] using [password]” 명령을 해야 한다. 그 뒤 데이터베이스 설정에 따라 한 개 혹은 복수개의 에이전트가 애플리케이션에 할당되게 되고 애플리케이션의 요청은 이 에이전트(oracle의 Server process의 역할)가 모든 작업을 수행하게 된다.

1.1 데이터 조회
1. 애플리케이션이 에이전트를 통해 데이터 조회를 요청할 경우 에이전트는 필요한 데이터를 버퍼 풀 (oracle의 data buffer의 기능) 메모리에서 읽어 오게 된다.
2. 이때 필요한 데이터가 버퍼 풀에 없는 경우 이 데이터가 연속적인 데이터라면 해당 데이터는 db2pfchr(프리패처)가 big-block I/O방식으로 버퍼 풀에 에이전트가 필요로 하는 데이터를 올리게 되고 에이전트는 계속해서 버퍼 풀 메모리 접근 만으로 데이터를 읽어 오게 된다. (이때 프리패처는 에이전트가 필요로 하는 데이터뿐만 아니라 데이터가 속해 있는 extent 내에 모든 데이터를 불러 오게 되고 그에 따라 사용하지 않는 버퍼 풀 공간이 생기게 된다. 이 요소가 너무 클 경우 해당 테이블 스페이스의 extent size 크기를 적절히 고려해야 한다.)
3. 하지만 연속적인 데이터가 아니라면, db2에이전트가 직접 디스크에서 버퍼 풀로 데이터를 읽어 오게 된다.
? db2pfchr (Prefetcher) 디스크에서 버퍼 풀(=오라클의 Data buffer와 흡사)로 데이터를 적재하여 에이전트가 디스크를 거치지 않고 메모리에서 데이터를 읽을 수 있도록 하는 프로세스

1.2 데이터 변경
1. 애플리케이션이 데이터를 변경할 경우 버퍼 풀의 해당 내용이 변경/삽입 되고 해당 SQL문과 변경된 데이터의 사전 / 사후 이미지가 로그버퍼에 기록된다.
2. 이는 다시 특정 시점에 db2loggw를 통하여 로그 파일에 기록된다.

3. 이렇게 변경된 데이터(dirty buffer)는 버퍼 풀의 효율성을 위해 특정 시점에 에이전트와 비 동기로 db2pchr(페이지 크리너)를 통해 다시 디스크로 반영된다. (오라클에서의 DBWn이 데이터베이스 Buffer Cache에 있는 내용을 데이터 파일에 쓰는 것과 동일한 기능) 이때 반드시 로그 파일에 먼저 쓰여지고 디스크에 쓰여지는 write ahead logging 방식이 이용된다.

Tip> db2loggw (log write) 오라클의 LGWR과 같은 기능으로 데이터에 대한 변경 사항을 log buffer에서 log file로 쓰는 역할을 한다.
Tip> 페이지 클리너(db2pchr-page cleaner)
에이전트가 버퍼 풀 내의 공간을 필요로 하기 전에 필요 공간을 확보하기 위해 버퍼 풀에서는 변경되었으나 디스크 내에 반영되지 않은 페이지(dirty page)를 에이전트와는 비동기로 작동하여 디스크에 반영하는 프로세스로, NUM_IOCLEANERS를 통해 개수가 지정할 수 있다.

2. DB2 Memory & Process Architecture
DB2에서는 Oracle과 달리 하나의 인스턴스에 여러 개의 데이터베이스가 존재하여 오라클과 흡사한 쉐어드 메모리(shared memory) 구조를 가지고 있으나 인스턴스 레벨의 메모리와 데이터베이스 레벨의 메모리가 따로 존재하며 각각 고유한 설정 값(dbm cfg, db cfg)을 가지고 있다. 프로세스 또한 인스턴스 레벨의 프로세스와 데이터베이스 레벨의 프로세스가 분리되어 있다.

2.1 DB2 Memory 구조

Shared / Private memory 구조

2.1.1 인스턴스 레벨
데이터베이스 manager(=instance) shared memory는 데이터베이스 관리자 공유 메모리로 불리며 db2start 명령을 통해 시스템에 할당된다. db2stop 명령을 통해 해제되기 전까지 시스템 상에 할당되게 된다. db2stop 명령은 인스턴스를 멈추는 명령어로 데이터베이스가 활동 상태일 경우 중지할 수 없다.
- Monitor heap / Audit Buffer: Audit가 사용 될 때만
- FCM(Fast Communications manager : 파틴션 된 데이터베이스 환경에서만

2.1.2 데이터베이스 레벨
데이터베이스 쉐어드 메모리는 데이터베이스 공유 메모리로, db2 active db 명령 혹은 db2 connect to db 명령을 통해 시스템에 할당된다. active db 명령으로 시작된 DB인 경우 db2 deactive db 명령을 통해 해제되며, connect 명령을 통해 활성화 된 db인 경우 마지막 connection이 끊기는 경우 해제되게 된다.
데이터베이스 공유 메모리 영역은 Heap 영역과 Cache 영역들로 구성되어 있으며 운영 중 데이터베이스 공유 메모리 총 영역(heap+cache)의 크기는 변하지 않지만, 데이터베이스 공유 메모리 영역을 구성하는 각 메모리들은 동적으로 조정될 수 있다.
- 데이터베이스 Heap
: Log buffer ? 디스크에 로그 레코드를 기록하기 전에 이들 레코드에 대한 버퍼로 사용되는 영역으로 동적 변경 가능한 메모리 영역이다.
: 카탈로그 캐시(catalogcache_sz, Oracle의 Data Dictionary Cache) ? 시스템 정보를 보유하는 메모리 영역으로 동적 변경 가능한 메모리 영역이다.
- 잠금 목록용 최대 스토리지(locklist): 잠금 정보를 저장하는 메모리 영역으로 이 메모리 영역은 동적으로 늘릴 수만 있고 줄일 수는 없다.
- 유틸리티 힙 크기(util_heap_sz, Oracle의 large pool): DB2의 유틸리티(load, backup, runstats…)가 실행될 때 사용되는 메모리 영역으로 동적 변경이 가능하며, 유틸리티가 종료되면 반환되는 메모리 영역이다.
- 공유 정렬 힙(sheapthres_shr) ? Intra parallel 환경 혹은 연결 집중기(connection concerntrator)인 경우 SQL에 대한 병렬 처리가 가능하게 된다. 이때 병렬로 이루어진 정렬작업에 대한 정보를 공유하기 위해 사용되는 메모리 영역이다.
- 패키지 캐시 크기(pckcachesz, Oracle의 Libarary Cache) ? 동적/정적 SQL문을 저장하여 동일한 문장을 다시 수행할 경우 드는 비용을 감소시킨다. 동적 변경이 가능한 메모리 영역이다.

2.1.3 애플리케이션 레벨
애플리케이션 레벨의 메모리는 애플리케이션 global / private memory로 구성되어 있으며, 애플리케이션 global memory의 경우 데이터베이스 환경이 병렬(intra/inter parallel) 환경 혹은 연결 집중기(connection concerntrator)인 경우만 활성화 되며 에이전트간의 데이터를 공유하고 이들 사이의 활동을 조정하기 위해서 쓰이는 메모리 영역이다.
애플리케이션 private memory는 db2 에이전트마다 할당되는 개인 메모리 영역이다. 기본적으로 에이전트에 할당되어 있는 메모리는 에이전트의 종료와 함께 해지되지만 에이전트 풀이 구성되어 있는 경우 에이전트 사용이 종료 되어도 풀의 범위 안의 에이전트 개수만큼의 메모리를 해지하지 않고 다음 할당에 따른 부하를 줄이기 위해 다른 에이전트에게 할당할 수 있도록 보유한다.
- 응용 프로그램 그룹 메모리 크기 판별 요소
: appgroup_mem_sz / groupheap_ratio / app_ctl_heap_sz
- 응용프로그램 개인 메모리
: 애플리케이션 / Query / java / Statement / Statistics heap
: Sort Heap(sortheap) - sortheap은 정렬, 해쉬 조인 등이 필요한 경우 할당되고 작업 종료 시 해제 되는 메모리 영역

2.2 DB2 Process 구조
DB2 메모리 구조와 마찬가지로 다중 파티션 환경과 단일 파티션 환경에 따라 3/4가지 수준의 프로세스로 분류된다.

2.2.1 인스턴스 레벨의 프로세스
인스턴스 레벨의 메모리와 마찬가지로 db2start / db2stop으로 할당 해제된다.
- Listener (프로토콜 유형에 따라 db2tcpcm / db2ipccm / db2snacm / db2tcpdm)
- db2sysc ? DB2 시스템 컨트롤러(엔진)로 가장 핵심이 되는 프로세스
- db2gds(global deamon spawner) / db2wdog(watch dog)
: db2gds 유닉스 환경에서 모든 프로세스를 실행시키고 db2wdog에게 프로세스 정보 전달, db2wdog은 해당 프로세스가 정지되는 경우 인스턴스 안의 다른 모든 프로세스에게 정보 전달
: 유닉스에만 존재하는 프로세스로 윈도우 기반 DB2는 하나의 프로세스(db2sysc)에 스래드 기반이기 때문에 위의 프로세스 들이 필요치 않다.
- db2fmtlg (Format Log) / db2cart
: Oracle의 ARCn(Archiver log process)의 기능을 하는 프로세스
: db2fmtlg는 DB2에서의 USER EXIT 프로그램을 이용하여 로그 파일을 별도의 장치에 저장하지 않고 현재 로그 디렉토리에 아카이브 하도록 한다.
: db2cart는 아카이브 방식 중 USER EXIT가 ON인 설정인 경우 사용되며 user exit 프로그램을 호출한다.

2.2.2 데이터베이스 레벨의 프로세스
- db2loggr (DB2 log reader) : 트랜잭션 롤백이나 리커버리, 롤포워드 동작시에 로그파일을 읽는 프로세스로 Oracle의 PMON과 같은 기능
- db2logw (DB2 log writer): 로그 버퍼에 있는 내용을 로그파일로 옮겨는 역할, Oracle의 LGWR과 같은 기능
- db2pclnr (DB2 page cleaner): 프리패처가 버퍼풀에 데이터를 올리기 전에 공간을 확보하는 프로세스로 에이전트와는 별도로 움직인다. Oracle의 DBWn과 같은 기능
- db2pfchr (DB2 prefecher): 애플리케이션이 데이터가 필요할 때 디스크로부터 버퍼풀에 데이터를 올리는 프로세스로 Oracle에 동일한 기능의 프로세스가 존재하지 않는다.
- db2dlock (DB2 deadlock detector): deadlock을 감지하는 프로세스로 LOCKLIST를 검색하고 deadlock 접속 상태를 점검한다.

2.2.3 애플리케이션 레벨의 프로세스
- db2에이전트 (DB2 coordinating 에이전트): 애플리케이션을 대신하여 데이터베이스 작업을 수행하는 프로세스. Connection concentrator/ intra- parallelism / inter-parallelism가 동작하지 않을 경우 애플리케이션 당 하나의 에이전트가 생성된다. 만약 위의 기능이 활성화 되어 있을 경우 db2에이전트는 sub에이전트(db2agntp)를 호출하게 된다. Oracle의 server process와 흡사한 기능
- db2agnta(DB2 sub에이전트): 유휴 상태의 sub에이전트로 에이전트 pool에서 에이전트의 할당이 해지되어 있는 상태로 새로운 에이전트 할당 시 db2agntp의 상태로 전환된다.

프로세스에 대한 좀더 자세한 내용은 IBM developerWroks(http://www.ibm.com/developerworks/db2/library/techarticle/0304chong/0304chong.html#table1)에서 확인할 수 있다.