DBMS 2
DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!
성능과 모니터될 수 있는 것을 이해하기 위해서는 DB2 아키텍처 관점에서 전반적으로 이해를 해야 한다. 이 장에서는 프로세스와 메모리 관점에서 살펴보도록 한다. DB2에서의 프로세스 모델 또는 서버 아키텍처는 n-n 프로세스 모델로 알려져 있다. 이 아키텍처의 주요 특성은 데이터베이스 무결성을 보장하는 능력이다. 주요한 데이터베이스 자원들로부터 모든 데이터베이스 응용프로그램을 독립시킨다. 이 자원들은 데이터베이스 제어 블록과 주요한 데이터베이스 파일들이다. 데이터베이스 연결 과정동안 DB2 조정 에이전트는 각 데이터베이스 응용프로그램에 할당된다. 각각의 DB2 에이전트는 데이터베이스 응용프로그램을 대신하여 작업하고 모든 SQL 요청들을 다룬다. 응용프로그램과 데이터베이스 에이전트는 IPC(Inter Process Communication) 기술(메시지 큐, 공유 메모리, 세마포아 등)을 이용하여 통신한다. DB2 조정 에이전트는 파티션내 병렬 처리가 가능하다면, DB2 서브 에이전트와 함께 작업한다. 이 아키텍처는 잘못된 응용프로그램으로부터 데이터베이스 자원들을 보호하기 위해 방화벽을 제공한다. 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)라고 한다. 데이터베이스 관리자는 데이터베??에 강제로 기록된다. 6) Fenced / Not Fenced 자원 데이터베이스 저장 프로시저는 CALL 문장을 사용하여 데이터베이스 응용프로그램에서 호출될 수 있는 동적으로 로드되는 라이브러리이다. 이 라이브러리는 DB2 데이터베이스 서버에 저장되고, Fenced 자원 또는 Not Fenced 자원으로써 실행될 수 있다. Fenced 자원은 데이터베이스 에이전트로부터 분리된 프로세스에서 실행되는 것이고, Not Fenced 자원은 데이터베이스 에이전트로써 같은 프로세스내에 실행된다. Not Fenced 자원은 내부-프로세스 통신 오버헤드가 적기 때문에 Fenced 자원보다 더 나은 성능을 가지지만, Not Fenced 자원은 만약 제대로 테스트되지 않으면 DB2 제어 블록위에 다시 쓸수 있다. 7) 쿼리 병렬 처리 병렬 처리의 활용은 DB2에 대한 쿼리 뿐만 아니라 다른 관리 작업에 대해 상당한 성능 이점을 제공한다. 쿼리 병렬 처리에는 두가지 유형이 있다. 그림 1-2에서는 병렬로 수행될 수 있는 4개의 조각으로 쪼개져 결과가 순차적인 방식으로 수행되는 것보다 더 빨리 리턴되는 쿼리를 볼수 있다. 파티션내 병렬 처리를 이용하기 위해서는 병렬로 수행하는 쿼리의 조각의 수인 병렬 처리의 정도(Degree of Parallelism)를 선택하거나 시스템이 할 수 있도록 데이터베이스를 적절하게 구성하는 것이 필요하다. 파티션간 병렬 처리는 쿼리를 단일 머신 또는 복수개의 머신에서 분할된 데이터베이스의 복수 파티션 사이로 복수개의 부분으로 쪼개는 능력을 의미한다. 쿼리는 병렬로 수행된다. 파티션간 병렬 처리는 MPP 시스템에 매우 적합하다. 그림 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-2.와 그림 2-3.은 메모리가 응용프로그램을 지원하기 위해 어떻게 사용되는지와 메모리의 크기를 조정할 수 있는 구성 매개변수들을 보여준다. 데이터베이스 관리자 공유 메모리는 데이터베이스 관리자가 수행하기 위해 필요하다. 이 메모리의 크기는 다음의 구성 매개변수에 의해 영향을 받는다. 데이터베이스 관리자는 파티션내 병렬 처리가 사용되면, DB2 에이전트들 사이에 데이터를 전달하기 위해 FCM(Fast Communication Manager) 구성요소를 사용한다. 만약 파티션내 병렬 처리를 사용하지 않는다면, FCM 버퍼, 메시지 앵커, 연결 항목, 요청 블록에 필요한 메모리 영역이 할당되지 않는다. 데이터베이스 전역 메모리 세그먼트의 최대 크기는 다음의 구성 매개변수에 의해 결정된다. 응용프로그램 전역 메모리는 다음의 구성 매개변수에 의해 결정된다. 에이전트 개인 메모리 세그먼트의 최대 수는 다음의 매개변수에 의해 결정된다. 에이전트/응용프로그램 공유 메모리는 다음의 매개변수에 의해 영향을 받는다.DB2 아키텍처 개요
DB2 아키텍처 개요
프로세스 모델
파티션간 병렬 처리(Inter-Partition Parallelism)
메모리 모델