번호   제목 닉네임 조회 등록일
9 IBM informix administrator's guide for 11.70 file
조인상
2499 2014-12-25
원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 참고 : IBM informix information center http://www-01.ibm.com/support/knowledgecenter/SSGU8G_11.70.0/com.ibm.welcome.doc/welcome.htm 1. 간단 백업/복구 절차 onbar 백업 (Storage Manager 사전 구성 필요) - backup a whole system (physical) # onbar -b -w -p - restore # onbar -r -w ontape 백업 (Storage Manager 없이 백업가능) - onconfig 파일에서 관련 파라미터 수정 $informix_dir/etc/onconfig 에서 TAPEDEV 파라미터 - full backup(online or quiescent mode) # ontape -s -L0 -d (s : start, L : level, d : non-interactive) - 백업 history 조회 # onstat -pr - cold restore (offline mode) # ontape -r 2. 데이터 저장영역 조회 - check chunks and data store # onstat -d 3. 운영모드 및 변경명령어 1. offline mode : onmode -ky 2. quiescent mode : onmode -sy / onmode -uy 3. administration mode : onmode -j / 4. online mode : oninit / onmode -m
8 DB2 우수 사례 : IBM Smart Analytics System을 위한 DB2 인스턴스 복구 imagefile
조인상
5930 2010-12-30
원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어 출처1 : http://www.kdug.co.kr/?pgname=home/board&mode=VV&brcode=pds_tech&wrno=2225 출처2 : http://www.ibm.com/developerworks/data/library/techarticle/dm-1010db2instancerecovery/index.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 데이터 손실이나 손상을 복구하는 작업은 백업 데이터베이스에서 데이터를 복원하는 과정을 통해 수행됩니다. 그러나 인스턴스 구성이 손상되었거나 데이터베이스 파티셔닝을 사용하는 경우에는 어떻게 해야 할까요? 서버를 전체적으로 복원하지 않으면서도 효율적이고 효과적으로 DB2 인스턴스 환경을 복원하려면 어떻게 해야 할까요? 이 기사에서는 파티션된 데이터베이스 환경에 필요한 복구 전략과 DB2 인스턴스 백업을 구현하는 방법을 설명하는 과정을 통해 이러한 질문에 답변을 하려고 합니다. 특히, System x와 Power Systems 서버를 기반으로 구성된 IBM Smart Analytics System 환경을 집중적으로 살펴봅니다. 데이터 손실이나 손상을 복구하는 작업은 백업 데이터베이스에서 데이터를 복원하는 과정을 통해 수행됩니다. 그러나 인스턴스 구성이 손상되었거나 데이터베이스 파티셔닝을 사용하는 경우에는 어떻게 해야 할까요? 서버를 전체적으로 복원하지 않으면서도 효율적이고 효과적으로 DB2 인스턴스 환경을 복원하려면 어떻게 해야 할까요? 이 기사에서는 파티션된 데이터베이스 환경에 필요한 복구 전략과 DB2 인스턴스 백업을 구현하는 방법을 설명하는 과정을 통해 이러한 질문에 답변을 하려고 합니다. 특히, System x와 Power Systems 서버를 기반으로 구성된 IBM Smart Analytics System 환경을 집중적으로 살펴봅니다. [목차] l 인스턴스 구성 l 인스턴스 백업 전략 l 인스턴스 장애 l 인스턴스 복구 절차 l 알려진 장애의 복구 소개 이 기사에서는 DB2 인스턴스가 손상된 상황에서 인스턴스를 지원하는 모든 구성 특성을 복원하여 참조할 수 있도록 해당 파일과 환경 설정을 백업하는 방법을 설명한다. 이 기사는 우수 사례 기사 시리즈의 일부로 IBM Smart Analytics System 환경에서의 백업과 복구를 다룬다. 우수 사례 기사 시리즈에 대한 링크는 참고자료 섹션을 참조하기 바란다. 이 기사의 기초가 되는 샘플 환경은 하나의 관리 노드와 두 개의 데이터 노드가 있는 IBM Smart Analytics System 5600이다. 다운로드 섹션에는 이 기사에서 권장하는 대로 파일, 환경 및 구성 설정을 백업하는 데 필요한 명령어가 포함된 예제 스크립트에 대한 링크가 있다. 필요에 따라 예제를 편집하여 예제가 해당 환경에 호환 가능하도록 하자. 그리고 언제나 비프로덕션 환경에서 명령어를 테스트하도록 하자. 실수로 파일 사용 권한을 변경했거나 파일을 삭제한 경우 또는 파일 시스템이 사용 가능하지 않게 된 경우에는 DB2 인스턴스를 사용하지 못할 수 있다. 이러한 시나리오에 신속하고 효과적으로 대응할 준비를 하려면 적절한 인스턴스 복구 계획을 수립해야 한다. DB2 인스턴스와 관련된 파일과 환경 설정을 식별하고 발생할 가능성이 있는 모든 유형의 인스턴스 장애를 복구하는 데 필요한 파일을 제공할 백업 전략을 복구 계획을 통해 정의해야 한다. 인스턴스와 데이터베이스 간의 관계는 절대적인 것이 아니다. 손상된 인스턴스를 삭제한다고 해서 관련된 데이터베이스가 삭제되는 것은 아니다. 데이터는 손실되지 않는다. 인스턴스 구성과 환경을 올바르게 복구할 수 있기만 하면 데이터베이스와 관련된 인스턴스와 카탈로그를 삭제하고 다시 작성할 수 있다. 파티션된 데이터베이스 환경에서 DB2 인스턴스를 백업하고 복구하는 전략을 구현하여 서버를 전체적으로 복구하지 않아도 인스턴스 구성을 복구할 수 있게 하면 다운타임 가능성을 줄일 수 있다. 그림 1에는 파티션된 데이터베이스 환경의 DB2 아키텍처가 표시되어 있다. DB2 소프트웨어는 각 노드에서 실행하고 이 노드에서 데이터베이스 파티션을 지원한다. IBMTEMPGROUP으로 레이블이 지정된 파티션 그룹은 관리 노드와 두 개의 데이터 노드에 걸쳐있다. SDPG와 IBMCATGROUP 파티션 그룹은 관리 노드에 있다. PDGP 파티션 그룹의 범위는 테이블 공간이 위치한 데이터 노드까지이다. 그림 1. DB2 인스턴스 복구 아키텍처 인스턴스 구성 IBM Smart Analytics System은 데이터베이스 파티셔닝을 구현하여 대규모의 병렬 처리 및 선형 확장성을 제공한다. 이러한 환경에서는 인스턴스 대신 데이터베이스를 파티션한다. 관리 노드에서 인스턴스를 작성하면 DB2 소프트웨어를 실행 중인 관련 노드(서버)에서 db2home 디렉토리를 공유할 수 있게 된다. 파티션된 데이터베이스가 제대로 기능하도록 하려면 데이터 노드마다 동일한 방식으로 사용자, 그룹 및 운영 체제 환경을 구성해야 한다. 파티션된 데이터베이스는 데이터베이스 구조를 관리하고 이 구조에 대한 액세스 권한을 조정하는 관리 노드를 통해 관리된다. IBM Smart Analytics System에는 데이터 노드당 다수의 데이터베이스 파티션이 있다. 각 데이터베이스 파티션에는 프로세서와 메모리, I/O 자원이 할당되며 이 파티션에서 별도의 데이터베이스 컨테이너와 로그, 인덱스 및 자체 데이터베이스 구성 관리자가 유지보수된다. 쿼리는 쿼리를 만족시키는 데 필요한 데이터를 검색하는 코디네이터 함수에 제출된다. 이 기사에서 다루게 될 테스트 클러스터는 세 개의 노드로 구성되며 beluga-bvn-05는 관리 노드이고 beluga-bvn-06과 beluga-bvn-07은 데이터 노드이다. 관리 노드에는 하나의 데이터베이스 파티션이 있으며 각 데이터 노드에는 네 개의 데이터베이스 파티션이 있다. 따라서 테스트 클러스터는 총 9개의 데이터베이스 파티션으로 구성된다. 클러스터에 있는 모든 노드에서 인스턴스가 작성되면 db2nodes.cfg 파일에서 정의한 모든 데이터베이스 파티션에서 데이터베이스가 작성된다. 목록 1에는 db2home/sqllib 디렉토리에 있는 샘플 db2nodes.cfg 파일이 표시되어 있다. 이 파일에는 테스트 클러스터의 구성이 기술되어 있다. 목록 1. 샘플 0 beluga-bvn-05 0 1 beluga-bvn-06 0 2 beluga-bvn-06 1 3 beluga-bvn-06 2 4 beluga-bvn-06 3 5 beluga-bvn-07 0 6 beluga-bvn-07 1 7 beluga-bvn-07 2 8 beluga-bvn-07 3 IBM Smart Analytics System 환경에서는 DB2 인스턴스 홈 디렉토리가 관리 노드에 있는 /shared_db2home 디렉토리가 된다. 이 파일 시스템은 GPFS나 NFS를 통해 다른 노드에서 공유하게 된다. 기타 노드는 로컬 파일 시스템에 /db2home으로 마운트된다. 각 노드의 /db2home 파일 시스템은 관리 노드에 대한 마운트 지점이므로 디렉토리 백업은 관리 노드에서만 수행하면 된다. 인스턴스 백업 전략 DB2 환경을 위한 백업 전략에서는 운영 체제와 DB2 인스턴스 및 DB2 데이터베이스를 다루어야 한다. 모든 복구 시나리오는 이렇게 특정 백업을 통해 처리된다. 대상을 정하여 복구하면 다운타임이 최소화된다는 점에서 이러한 방식이 효과적이라고 할 수 있다. 인스턴스 백업 프로세스를 전체 백업 스케줄에 통합한다. 환경 구성을 변경하기 전과 후에 인스턴스 구성을 백업한다. 인스턴스를 백업하기 위해 다음과 관련된 모든 세부사항을 기록한다. l 소프트웨어 버전 l 라이센스 l 사용자 및 그룹 l 구성 설정이 포함된 파일 l 인스턴스 디렉토리 이 섹션에서 나열한 파일과 설정 및 변수를 모두 백업해야 한다. 이러한 파일은 크기가 작지만 복구 후에 모든 것이 제대로 되었는지 조정하고 유효성을 검증하기 위해 사용할 수 있는 가치 있는 정보를 포함하고 있다. 이외에도 추가로 도움이 필요한 경우에는 IBM 지원 센터를 통해 세부적인 백업 관련 정보를 요청할 수 있다. 이 섹션에 있는 네 개의 테이블은 각각 백업해야 하는 파일과 구성 설정으로 이루어진 네 개의 카테고리 중 하나를 나타낸다. 표 1과 2에는 각 노드에서 백업해야 하는 데이터가 표시되어 있다. 표 3과 4에는 관리 노드에서 백업해야 하는 데이터가 표시되어 있다. 이러한 두 가지 백업을 DB2 인스턴스 소유자로서 실행할 수 있다. 백업은 다운로드 섹션에 있는 두 개의 스크립트로 표현된다. 표 1. 운영 체제 파일 백업 DB2 소프트웨어에서 참조하는 정보가 포함된 각 노드의 운영 체제에서 이러한 파일을 백업한다. 인스턴스에 장애가 발생하는 경우, 이러한 구성 파일을 다시 적용하면 운영 체제를 복원하지 않아도 된다. 파일 이름 설명 /etc/services DB2 FCM 네트워크 설정 포함 /etc/exports 내보낸 파일 시스템과 관련된 세부사항 포함 /etc/passwd 사용자 정보 /etc/hosts 클러스터에 있는 기타 노드의 호스트 이름과 IP 주소 /etc/group 그룹 정보 /opt/tivoli/tsm/client/api/bin64/dsm.opt 백업 저장 관리자 설정(테스트에는 TSM이 사용됨) /opt/tivoli/tsm/client/api/bin64/dsm.sys TSM은 DB2 로그 아카이브와 통합되며 구성을 백업하고 복사한다. 표 2. 운영 체제 정보 캡처 이러한 명령어를 실행한 결과를 캡처하여 백업 시점에 각 노드에서 운영 체제 환경의 스냅샷을 작성한다. 환경을 복원한 후에는 이러한 정보를 사용하여 해당 환경의 유효성을 검증할 수 있다. 명령 설명 db2level > db2level.out DB2 제품 레벨 oslevel > oslevel.out 운영 체제 레벨 df > df_g.out 디스크 공간 상태 mount > mount.out 마운트 상태 ulimit -a > ulimit.out Ulimit 설정 crontab -l > crontab.out Crontab 스케줄 id $Instance > id.out 사용 중인 인스턴스 ID ~/sqllib/java/jdk64/jre/bin/java -version > jdk.out Java JDK 버전 ~/sqllib/java/jdk64/jre/bin/java com.ibm.db2.jcc.DB2Jcc -version > jcc.out JCC 버전 표 3. DB2 홈 디렉토리로 구성된 tar 파일 작성 인스턴스를 복원할 경우에는 관리 노드에서 이 디렉토리와 이 디렉토리에 포함된 파일이 필요하다. 또한, 이 디렉토리에는 해당 환경에 맞는 백업 스크립트와 기타 스크립트가 포함되어 있다. tar 명령을 사용하여 링크가 유지되고 있는지 확인할 수 있다. 명령 설명 tar -cvf 2010-07-29.beluga-bvn-05.tar $HOME/* 관리 노드에서 DB2HOME/directory로 구성된 tar 파일을 작성한다. 표 4. DB2 관리자와 관련 구성의 출력 및 저장 관리 노드에서 이러한 명령을 실행하여 인스턴스 구성 스냅샷을 작성한다. 명령 설명 db2 get admin cfg > admin.cfg db2 관리 구성 가져오기 db2set -all > db2set DB2 환경 레지스트리 변수 설정 표시 db2licm -l > db2licm.license.information DB2 라이센스 정보 가져오기 db2cfexp db2cfexp.bak backup DB2 구성 내보내기 데이터 가져오기 db2 list node directory > db2.list.node.directory 노드 디렉토리 목록 가져오기 db2 list database directory > db2.list.database.directory 데이터베이스 목록 가져오기 db2 list dcs directory > db2.list.dcs.directory DCS 디렉토리 표시 cp /sqllib/.rhosts .rhosts.bak Linux 플랫폼의 신뢰 호스트 db2 get dbm cfg > dbm.cfg 데이터베이스 관리자 구성 가져오기 $HOME/.profile 인스턴스 소유자 프로파일 복사 $HOME/sqllib/db2nodes.cfg 데이터베이스 노드와 파티션 구성 파일 복사 인스턴스 장애 시나리오 인스턴스 장애는 대부분 인간의 실수나 서비스 장애, 파일 손상 때문에 발생한다. 장애는 환경 변수의 변경으로 인한 장애에서 DB2 소프트웨어에서 참조하는 운영 체제 환경 파일의 항목이 수정되면서 생긴 장애에 이르기까지 다양하다. 문제의 원인을 아는 경우나 그렇지 않은 경우에 따라 복구 시나리오의 카테고리를 나눌 수 있다. 문제의 원인을 아는 경우에는 파일이나 구성 설정을 수정하면 문제를 해결할 수 있다. 원인을 모르는 경우에는 인스턴스를 완전히 복구해야 한다. 프로덕션 환경에서는 원인을 발견하는 속도보다 복구를 수행하는 속도가 더 중요하다. 해당 환경에서 어떤 복구 시나리오를 수행할 수 있는지 확인한 다음, 장애 시나리오와 관계없이 인스턴스를 복구하는 데 사용할 수 있는 백업 전략을 적절히 시행한다. 적절한 복구 계획을 수립해야 하는 네 가지 일반적인 장애 시나리오는 아래에서 설명한다. l 관리 노드에 있는 db2home 디렉토리가 제거되었거나 인스턴스가 갑자기 삭제되었다. 관리 노드에 있는 db2home 디렉토리는 파티션된 데이터베이스에 있는 다른 모든 노드에서 공유한다. 홈 디렉토리의 내용이 손상되거나 제거되면, 인스턴스를 사용할 수 없게 된다. l 인스턴스 구성이 손상되었다. 구성이나 DB2 바이너리 파일이 손상되거나 삭제되면 인스턴스를 사용할 수 없게 된다. 이러한 파일로는 .rhosts, db2nodes.cfg 및 글로벌 레지스트리가 있다. 또한, 환경 변수가 갑자기 수정되면 이러한 시나리오가 발생할 수 있다. l 데이터와 관련된 공유 db2home 파일 시스템, 대기, 사용자 또는 InfoSphere 웨어하우스 애플리케이션 노드가 삭제되었다. 이러한 디렉토리가 제거된 노드에서는 인스턴스를 사용할 수 없게 된다. l 인스턴스 디렉토리의 사용 권한이 갑자기 변경되었다. db2home 디렉토리에서 파일이나 디렉토리 사용 권한이 변경되면 DB2를 사용할 수 없게 된다. 인스턴스 복구 절차 이 섹션에서는 운영 체제의 구성을 확인하는 절차와 인스턴스를 삭제하고 다시 작성하는 절차를 살펴본다. 참조한 백업 파일은 다운로드 섹션에 있는 샘플 백업 스크립트를 사용하여 작성한 것이다. 설정을 확인할 때는 장애 노드에 설정된 값과 이 노드에서 백업한 파일을 비교한다. 운영 체제 파일과 설정을 편집하려면 root 계정으로 액세스해야 한다. 1. DB2와 관련된 모든 태스크에서 DB2 인스턴스 소유자를 사용한다: a. 다음과 같이 영향을 받은 노드에서 운영 체제의 구성을 확인한다. 인스턴스 사용자와 분리 사용자가 /etc/passwd에 존재하는지 확인한다. b. 관련된 DB2 그룹 계정이 /etc/group에 존재하는지 확인한다. c. 각 백업 사본에서 /etc/services와 /etc/hosts를 비교하여 필요에 따라 수정하거나 복원한다. d. 해당 시스템과 관련된 소프트웨어 패키지를 열거하여 백업 파일에 표시된 것과 비교한다. 모든 변경 원인을 분리하고 판별한다. e. 사용자 한계(ulimit), 마운트 지점(/etc/fstab), 운영 체제 레벨(oslevel) 및 crontab 항목을 비교하고 확인한다. 모든 변경 원인을 판별한다. 2. 다음과 같이 영향을 받은 노드에서 손상된 인스턴스를 삭제한다: a. db2ilist 명령을 사용하여 해당 인스턴스가 여전히 인스턴스 목록에 존재하는지 판별한다. 해당 인스턴스가 손상되지 않은 경우에는 마운트와 네트워크 문제를 확인한다. db2iupdt 명령을 사용하여 사용 권한 문제를 수정한다. b. db2idrop <instance> 명령을 사용하여 부분적으로 손상된 인스턴스를 삭제한다. c. db2iset 명령을 사용하여 관련된 프로파일 정보와 구성 매개변수를 제거한다. (예: db2iset -d bcuinst2) 3. 다음과 같이 영향을 받은 노드에서 인스턴스를 작성하고 구성한다. a. db2icrt 명령을 사용하여 root 사용자로 관리 노드에서 인스턴스를 작성한다. DB2 소프트웨어를 설치한 제품 디렉토리에서 이 명령을 실행한다. 이 기사의 테스트 클러스터에서는 제품 디렉토리가 /opt/IBM/dwe/db2/V9.7/instance이다. 다음과 같이 명령을 실행한다. db2icrt -u bcufenc2 bcuinst2 여기서 bcufenc2와 bcuinst2는 인스턴스 소유자의 사용자 ID이다. b. 데이터베이스 관리자 구성 매개변수를 dbm.cfg.out 백업 파일에 있는 매개변수와 비교하고 필요하면 복원한다. c. $DB2HOME/sqllib/db2nodes.cfg 파일을 백업 버전과 비교하고 필요하면 바꾼다. d. 레지스트리 변수를 db2set.out 백업 파일에 있는 변수와 비교하고 필요하면 다시 적용한다. 예를 들면, 다음과 같이 DB2COMM 변수를 tcpip로 설정해야 할 수도 있다. db2set DB2COMM=tcpip e. $DB2HOME/sqllib/userprofile 파일을 백업된 파일과 비교하고 필요하면 바꾼다. 4. 다음과 같이 라이센스 파일을 추가하고, 영향을 받은 노드에 있는 데이터베이스의 목록을 작성하고 DB2를 시작한다. a. 백업 파일 세트에서 db2ese.lic 파일을 복원하고 다음 명령을 실행한다. db2licm -a db2ese.lic 라이센스 파일을 찾을 수 없으면 db2start 명령은 SQL8000N 오류를 리턴한다. b. 백업 세트의 db2.list.database.directory 및 db2.list.node.directory 파일에 표시된 것에 따라 노드와 디렉토리 목록을 작성한다. 예를 들어, 테스트 클러스터에서 이러한 작업을 수행하려면 다음과 같은 명령을 실행한다. catalog tcpip node beluga-bvn-05 remote beluga-bvn-05 server 50000 catalog database BCUDB as BCUDB at node beluga-bvn-05 c. DB2를 시작한다. DB2 HA(High Availability) 기능을 사용할 경우에는 해당 환경에 적합한 시스템 종료 및 시작 절차를 참조한다. 알려진 장애의 복구 이 섹션에서 기술한 바와 같이 인스턴스 장애의 원인을 아는 경우에는 완전한 복구 작업을 수행할 필요가 없다. 특정 복구 단계에서 사용 권한 문제뿐만 아니라 네트워크와 마운트 문제를 수정할 수 있다. n 비관리 노드에 있는 인스턴스 소유자 홈 디렉토리가 제거되었다. 관리 노드가 아닌 노드에 있는 인스턴스 홈 디렉토리는 마운트된 파일 시스템이다. 다음 단계를 수행하여 이러한 장애를 복구한다. 1. 다음과 같이 마운트 명령을 사용하여 영향을 받은 노드에 있는 파일 시스템을 마운트한다. mount /db2home 2. 인스턴스 소유자로서 데이터베이스 관리자를 시작한다. (예:db2start) 참고: 고가용성 환경에서는 다른 명령을 사용해야 할 수도 있다. 이런 경우에는 해당 사용자 안내서를 참조한다. n 인스턴스 디렉토리에 대한 사용 권한이 갑자기 변경되었다. db2home 디렉토리 특히, sqllib 디렉토리에서 chmod나 cp 명령을 실행하면 DB2 소프트웨어가 파일을 읽거나 쓰거나 실행할 때 장애가 일어날 수 있기 때문에 인스턴스가 사용 불가능하게 될 수 있다. 예를 들면, 이 기사의 테스트 클러스터에서는 관리 노드에서 chmod 명령을 실행했다. 이렇게 하면 파일 사용 권한 오류로 인해 db2start 명령이 실패하게 된다. 목록 2에는 장애가 발생하는 상황이 표시되어 있다. 목록 2. 사용 권한을 변경한 데 따른 장애 cd">bcuinst2@beluga-bvn-05:~>cd ~/sqllib chmod">bcuinst2@beluga-bvn-05:~>chmod -R 444 * bcuinst2@beluga-bvn-05:~> db2start -bash: /db2home/bcuinst2/sqllib/adm/db2start: Permission denied SQL6031N Error in the db2nodes.cfg file at line number "<line>". Reason code "<reason-code>". Explanation: The statement cannot be processed because of a problem with the db2nodes.cfg file, as indicated by the following reason codes: 1 Cannot access the sqllib directory of the instance. 이러한 시나리오에서는 다음과 같은 단계를 수행하여 소유권과 사용 권한 값을 다시 적용한다. 1. ~/sqllib에 있는 각 파일은 인스턴스 사용자 ID와 db2 인스턴스 그룹이 소유해야 한다. 이렇게 하려면 관리 노드에서 다음과 같은 명령을 실행한다. chown db2inst2:db2igrp /db2home/bcuinst2/sqllib/* 여기에서 bcuinst2와 db2igrp은 각각 인스턴스와 그룹 계정이다. 2. db2iupt 명령을 실행하여 db2home 디렉토리를 업데이트하고 설치된 DB2 소프트웨어에 기반을 둔 공통 파일을 바꾼다. db2iupdt 명령을 사용하여 인스턴스를 업데이트하려면 먼저, 인스턴스를 처리하기 위해 실행 중인 모든 프로세스를 중지해야 한다. db2iupt 명령을 실행하면 ~/sqllib 디렉토리 아래에 있는 파일이 변경된다. 목록 3에는 테스트 클러스터에서 이러한 단계를 수행하는 방법이 표시되어 있다. 목록 3. 설치된 DB2 소프트웨어를 기반으로 하는 인스턴스를 db2iupdt 명령을 사용하여 업데이트하기 beluga-bvn-05:/opt/IBM/dwe/db2/V9.7/instance # ./db2iupdt bcuinst2 DBI1070I Program db2iupdt completed successfully. bcuinst2@beluga-bvn-05:~> db2start 08/10/2010 15:09:16 1 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 5 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 2 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 3 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 7 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:17 6 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:18 4 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:18 8 0 SQL1063N DB2START processing was successful. 08/10/2010 15:09:30 0 0 SQL1063N DB2START processing was successful. SQL1063N DB2START processing was successful. 결론 인스턴스가 손상되어 결국에는 사용할 수 없게 되는 상황을 신속하고 효과적으로 복구할 수 있도록 DB2 인스턴스 백업 전략과 복구 전략을 구현해야 한다. 인스턴스 백업 전략과 복구 전략을 함께 사용하면 인스턴스가 손상되는 상황에 직면했을 때 운영 체제를 완전히 복원해야 하는 상황을 피할 수 있다. 이렇게 하면 그러한 상황에서 경험하게 되는 다운타임을 대폭 줄일 수 있다. 참고자료 l developerWorks에 있는 다른 DB2 우수 사례 기사를 읽어보자. l DB2 Database for Linux, UNIX, and Windows Information Center에는 관련된 IBM InfoSphere Information Server 제품 및 기능뿐만 아니라 DB2 제품군과 기능을 사용하는 방법이 기술된 정보가 있다. l developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다. l 무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다. l Twitter의 developerWorks 페이지를 살펴보자. l developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다. 다운로드 DB2 Instance Backup Script db2_instance_backup.zip 10KB HTTP DB2 Instance Backup OS Script db2_instance_backup_os.zip 10KB HTTP
7 IBM DB2 User's Guide file
조인상
25244 2010-12-22
원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어 출처 : KDUG - http://www.kdug.co.kr +++++++++++++++++++++++++++++++++++++++++++++++++++++++ IBM DB2 User's Guide - Korea DB2 User Group(KDUG) 공개자료실에서 다운로드
6 IBM DB2 제품군
조인상
5770 2010-12-14
원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ IBM의 DB2 제품군 1. DB2 UDB (transaction 처리) 2. Business Intelligence 3. Contents Manager 1. DB2 UDB (transaction 처리) 제품군 1. DB2 UDB Personal Edition : 개인 사용자를 위한 DB엔진. 서버기능은 없음 2. DB2 UDB Workgroup Edition : 서버 역할 가능. 3. DB2 UDB Enterprise Edition(EE) : 여기서 부터 기업형. DB2 connect 포함. 64비트 OS지원 4. DB2 UDB Enterprise-Extended Edition(EEE) : 병렬처리기능 포함. 최대 999노드로 확장가능. * DB2 엔진에 포함된 제품 - DB2 connect : 각 플랫폼별 DB2 끼리 연동시키는 제품 - DB2 Everyplace : PDA용 DB - DB2 SyncServer : DB2 Everyplace와 DB2 서버를 동기화 시키는 제품 - DB2 Relation connect : 이기종 DB와 DB2의 연동을 시켜주는 제품 - DB2 Data Propagater Relational : DB2를 다른 DB서버로 복제해 주는 제품. - Net.data : 웹으로의 연동을 쉽게하기 위한 매크로 스크립트 2. Business Intelligence 제품군 : DW/OLAP제품군. 1. DB2 Warehouse Manager : DB2 엔진의 데이터를 분석하기 위해 추출,이동,변환,검색해주는 제품 2. DB2 Warehouse Manager Connectors : DB외 다른 저장소의 데이터를 분석하기 위해 추출,이동,변환,검색해주는 제품 3. Db2 Query Patroller : DW, DataMart 등에서 사용하는 조회를 관리,분석하는 제품 4. DB2 OLAP Server : 의사결정을 위해 데이터를 분석하기 위한 제품 5. DB2 Intelligent Miner : 보다 심화된 데이터 분석,예측을 위한 제품 3. Contents Manager : DB에 저장될수 있는 정형데이터가 아닌 데이터의 관리를 위한 제품 1. Content Manager : image, audio, video를 관리하고 workflow를 관리해주는 제품 2. Content Manager OnDemand : 기업체에서 사용하는 종이문서를 전자문서화하여 관리하는 제품 3. Content Manager CommonStore : SAP R/3, Domino Notes, MS Exchange 등에서 발생하는 대량의 데이터를 복제/관리하는 제품 4. Content Manager VideoCharger : 화상교육, 화상관리를 위한 제품 5. Enterprise Information Portal : 기업전체의 데이터를 하나의 포탈로 구축 관리하게 해주는 제품 ** 위 까지는 (구)DB2 UDB 제품군 ** DB2 9.7 의 제품군 1. DB2 Express-C 2. DB2 Express (EXP) 3. DB2 Workgroup Server Edition (WSE) 4. DB2 Enterprise Server Edition (ESE) * 각 제품군은 엔진은 모두 동일하지만, 하위 제품군의 경우 일부 옵션이 불가능하거나 추가 구매로써 구현할 수 있게 되어있다. 1. DB2 Express-C - 지원 운영체제 : Linux, Windows - 메모리 제한 : 4GB - CPU 제한 : 2 CPU - 무료로 다운로드 가능. 추가옵션 구매 불가. 오라클 PL/SQL 호환 불가. 2. DB2 Express (EXP) - 지원 운영체제 : Linux, Windows - 메모리 제한 : 4GB - CPU 제한 : 2 CPU 3. DB2 Workgroup Server Edition (WSE) - 지원 운영체제 : Linux, Windows, AIX, HP-UX, Solaris - 메모리 제한 : 16GB - CPU 제한 : 4 CPU 4. DB2 Enterprise Server Edition (ESE) - 지원 운영체제 : Linux, Windows, AIX, HP-UX, Solaris - 메모리 제한 : 무제한 - CPU 제한 : 무제한
5 DB2 Monitoring imagefile
조인상
6829 2010-12-13
원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어 출처 : IBM Software Group - IBM DB2 Technical Evangelist - 왕천재님 자료에서 발췌 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1. Thread 모니터링 1. DB2 9.5 이전 < ps 시스템 명령 > 또는 db2_local_ps 명령을 사용하여 전체 활성 DB2 EDU를 나열 2. DB2 9.7 에서는 db2pd -edu 명령어로 확인 2. 메모리 사용량 확인 방법 1. db2pd -dbptnmem - db2pd 는 공유 메모리 계층을 정확하게 표시한다. - db2pd는 여전히 Private Memory 할당을 표시하지 못한다. 2. db2 get snapshot for applications on sample 3. select * from table(admin_get_dbp_mem_usage()) 4. db2mtrk -a - db2mtrk 는 Private Memory 할당은 표시하지만 다른 영역 표시에는 약하다. - Private Memory 사용은 이제 관심대상이 아니다. - db2pd -dbpntmem 의 고수준 보고 기능으로 충분할 수 있다. 3. 인스턴스 공유 메모리 확인 - 할당된 인스턴스 공유 메모리의 양은 db2mtrk -i -v 명령어로 확인할 수 있다. - Database Managed Memory 양은 db2 get snapshot for dbm 으로 확인한다. 4. 데이터베이스 공유 메모리 확인 방법 5. 응용프로그램 Private 메모리 확인 - 특정한 에이전트 개별 메모리의 양을 확인하려면 db2 list applications 명령어로 에이전트에 대응되는 핸들번호를 확인한다. - db2 get snapshot for application 명령어에서 agentid 옵션으로 특정한 에이전트 개별 메모리의 양을 확인한다. 6. db2top 유틸리티 이용 - 인스턴스 사용자로 db2top 명령어를 실행한다.
4 IBM DB2 아키텍쳐 및 프로세스 모델 - 3. DB2 Memory Model imagefile
조인상
8475 2010-12-13
원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어 출처 : IBM Software Group - IBM DB2 Technical Evangelist - 왕천재님 자료에서 발췌 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ IBM DB2 아키텍쳐 및 프로세스 모델 1. DB2 Architecture & Engine Components 2. DB2 Process Model 3. DB2 Memory Model 3. DB2 Memory Model [ DB2 메모리모델의 구조 ] - DB2 V8~V9.1 까지의 메모리 모델 구성도 - DB2 V9.5 에서 변경된 메모리모델. - V9.1 까지의 모델과 차이점을 살펴보면 = Instance Global Control Block 에 포함되어있었던 Sort Heap Threshold 항목이 Database Global Memory 쪽으로 변경 = Application 그룹에 할당되던 메모리를 빼고, Database 에 할당하여 Global 메모리를 공유메모리화 = 클라리언트에 할당되는 db2agent 에도 공유메모리 할당 - 위의 그림과 같이 메모리 구조가 할당된다. - Instance shared memory - Database Shared Memory - Application Group shared Memory - Agent Private Memory 1. Instance shared memory : 인스턴스 공유 메모리 영역은 전체적인 DB2 세션들이 공유해서 사용할 수 있는 메모리 영역이다. - 인스턴스를 기동할때 할당되고, 인스턴스를 중지할때 해제된다. - Monitor heap, FCM, Audit buffer등이 포함. - Monitor Heap : 스냅샷모니터, 이벤트 모니터등을 이용하여 모니터링 정보를 수집할때 사용되는 메모리 영역 MON_HEAP_SZ 인스턴스 구성 변수를 이용하여 조절 - FCM : 다중 데이터베이스 파티션 환경에서 파티션간의 통신에 사용되는 메모리 영역. FCM_NUM_BUFFEERS 인스턴스 구성 변수를 이용하여 조절 - Audit Buffer : db2audit 유틸리티가 수집한 데이터를 저장하는 audit용 버퍼영역 db2chkau 프로세스는 audit용 버퍼에 저장된 데이터를 db2audit.log파일에 비동기식으로 기록. AUDIT_BUF_SZ 인스턴스 구성변수를 이용하여 조절 2. Database Shared Memory : 데이터베이스 공유 메모리 공간은 실제 agent 들의 요청을 받아서 요청을 처리하는 메모리 공간이다. - 데이터베이스가 활성화 될때 할당되고, 비활성화되면 해제. - Buffer pool, Database Heap, Catalog Cache, Log buffer, Lock List, Package Cache, Shared Sort heap, Utility Heap 등이 포함. - Buffer Pool : 버퍼풀은 테이블 및 인덱스 데이터 페이지를 디스크에서 읽거나 수정할때 캐시하기 위해 사용되는 메모리이다. 버퍼풀은 디스크 대신 메모리에서 데이터를 Access 할 수 있도록 허용함으로써 성능을 향상시킨다. - Database Heap : 테이블, 인덱스, 테이블스페이스, 버퍼풀 등의 데이터베이스 오브젝트에 대한 Control Block 정보를 저장하고, Log Buffer와 Catalog Cache를 포함하는 영역으로 데이터베이스 구성변수인 DBHEAP 을 이용하여 동적으로 조절할 수 있음 - Catalog Cache : SQL문을 컴파일 하는 동안 SYSIBM.SYSTABLES, SYSIBM.SYSDBAUTH, SYSIBM.SYSROUTINES 등의 시스템카탈로그의 정보를 저장하는 메모리영역으로 Database Heap 에서 할당되며, CATALOGCACHE_SZ 변수로 동적으로 조절 - Log Buffer : 로그 레코드를 디스크의 로그파일에 기록하기전에 버퍼링하는 메모리 영역으로 Database Heap에서 할당되며 데이터베이스 구성변수인 LOGBUFSZ를 이용하여 동적으로 조절 - Lock List : 데이터베이스에 접속된 모든 어플리케이션이 보유하고 있는 테이블과 행잠금 정보를 저장하는 메모리영역. LOCKLIST변수로 조절 - Package Cache : Static 및 dynamic SQL문을 젖아하는 캐시영역으로 Static SQL문이 포함된 패키지를 reload하거나 Dynamic SQL문을 재컴파일 하는 내부적인 오버헤드를 줄여준다. PCKCACHESZ 변수로 조절한다. - Shared Sort Heap : Shared Sort Memory는 SubAgent 들이 정렬작업을 병렬로 처리하고, 그 결과를 공유하기 위해 사용하는 메모리영역. SHEAPTHRES_SHR 변수로 조절한다. - Utility Heap : Load, Backup, Restore, Runstats 등의 유틸리티가 실행될때 사용하는 메모리 영역으로 동적으로 조절가능. 유틸리티가 수행도리때 할당되고, 유틸리티가 종료되면 반환된다. UTIL_HEAP_SZ 변수로 조절한다. 3. Application Group shared Memory : 해당 응용프로그램에 연관된 모든 에이전트 프로세스 사이의 정보를 교환을 위해 사용되는 영역. - 병렬처리가 가능한 환경에서 응용프로그램의 첫번째 에이전트 프로세스가 데이터베이스에 연결을 요청하는 경우에 할당. - 해당 응용프로그램과 연관된 모든 EDU들이 Access 할 수 있다. - 특정 응용프로그램의 요청을 처리하는 SubAgent 와 Coordinator Agent 간의 정보 교환. - Application Control Heap - Application Control Heap : 해당 응용프로그램과 연관된 모든 에이전트 프로세스 사이의 정보를 교환하기 위해 사용되는 영역. 이 영역은 선언된 임시테이블에 대한 Descriptor 정보를 저장하는데도 사용. 명시적으로 삭제되지 않은 선언된 모든 임시테이블에 대한 Descriptor 정보가 보존되므로 선언된 임시테이블이 삭제될때까지 메모리를 반환할 수 없다. 파티션마다 각 연결에 한개씩 할당되며, APP_CTL_HEAP_SZ 변수로 조절한다. 4. Agent Private Memory : 각 DB2 에이전트 프로세스는 작업을 수행할 메모리를 획득해야 한다. 어플리케이션을 대신하여 Access 게획을 최적화, 구현, 실행하고, Sort를 수행하고, 위치와 상태같은 Cursor 정보를 기록하고, 통계를 모을 메모리를 사용하게 된다. - 지역 또는 원격 응용프로그램이 데이터베이스에 접속을 요청하는 경우에 할당되고, 접속을 종료하면 해제. - Sort Heap, Satement Heap, Application Heap, Statistics Heap, Query Heap 등 - Sort Heap : 정렬작업 또는 Hash Join 이 필요할때 할당되고, 작업이 종료되면 메모리 반환, SORTHEAP 변수로 조절. - Statement Heap : SQL 컴파일러의 작업영역으로 사용되는 메모리. 프리컴파일 또는 바인드 작업시에 각 SQL문에 대해 할당되고, 작업이 종료되면 반환. STMTHEAP 변수로 조절. - Application Heap : db2agent 프로세스의 개별 작업 영역으로 서브에이전트 프로세스가 SQL문에 대한 패키지 중에서 실행가능한 섹션을 복사하여 저장하는데 사용. SQL문에 대한 실행섹션은 요청된 SQL문을 수행하기 위해 필요한 정보를 제공하며, 이 메모리 영역에 캐시된 섹션은 재사용되어 오버헤드를 줄일수 있음. APPLHEAPSZ 변수로 조절. - Statics Heap : 명령어가 실행될때만 Utility Heap으로부터 할당받는 메모리 영역. Runstats 실행시 메모리를 사용 STAT_HEAP_SZ 변수로 조절. - Query Heap : db2agent 프로세스가 쿼리문, SQLCA, SQLDA, 패키지 등의 이름과 생성자, 섹션번호, 일관성 토큰등을 저장하는데 사용. QUERY_HEAP_SZ 변수로 조절. [ DB2 메모리모델 - DB2 9 새로운 메모리 기능 ] 1. 단순화된 다중 스레드 아키텍쳐 - DB2 9.5는 모든 플랫폼에 다중 스레드 아키텍쳐가 있다. 9.5 이전 버전에서 유닉스, 리눅스 기반 Db2는 각 에이전트가 각각 고유 프로세스를 실행하는 프로세스 기반 모델을 사용했다. 다중 스레드 아키텍쳐는 Db2의 메모리 Footprint를 줄인다. 2. 모든 플랫폼에서 사용가능한 STMM. - DB2 9.1에서는 AIX 및 Windows 에서만 전체 데이터베이스 메모리에 대해 database_memory 매개변수를 자동으로 설정하여 STMM을 사용할 수 있었다. 그러나 DB2 9.5에서는 모든 플랫폼에서 사용이 가능하다. 3. 보다 많은 구성 매개변수를 자동으로 설정하여 동적으로 구성할 수 있다. - 이러한 매개변수에는 applheapsz, database_memory, dbheap, instance_memory, mon_heap_sz, stat_heap_sz, stmtheap 등이 있다. 4. NO_FILE_SYSTEM_CACHING 이 기본이다. - Db2 9.5에서 테이블스페이스 컨테이너를 만들면 기본적으로 데이터베이스 매니저가 가능한 경우마다 동시 I/O (CIO : Cuncurrent I/O) 를 사용하려고 시도한다. CIO가 지원되지 않는 시스셈구성의 경우 직접I/O (DIO) 또는 버퍼링된 I/O (Buffered I/O) 가 대신 사용된다. CIO나 DIO를 설정하면 데이터베이스 매니저가 파일시스템 레벨에서 캐싱을 사용하지 않기 때문에 메모리 성능이 향상된다. 각 메모리세트는 다양한 메모리 풀을 구성하고 있다. 위 그림에서는 메모리풀의 이름이 나열되어 있다. 예를들어 LockList는 데이터베이스 공유메모리 세트에 속한 메모리 풀이다. Private Sort Heap 은 에이전트 개인 메모리 세트에 속한 메모리 풀이다. 5. 64비트 AIX에서의 대형 페이지(16MB) 지원. - 대형 페이지 사용은 집중적으로 메모리 접근을 필요로 하며 다량의 가상메모리를 사용하는 고성능 어플리케이션에 성능향상을 위해서 제공된다. 6. database_memory 구성 매개 변수의 새로운 값. - DB2 9 에서 database_memory 구성 매개변수의 COMPUTED 설정은 DB2 8버전에서의 AUTOMATIC 설정과 같다. DB2 9에서 database_memory 매개변수를 AUTOMATIC(AIX 및 Windows의 경우)으로 설정하면 데이터베이스 메모리 사용을 자동으로 튜닝하는 새로운 자가튜닝메모리관리 기능을 이용할 수 있다. 7. 새 구성 매개 변수 db_mem_thresh - database_memory 매개변수에서 사용되지 않은 부분이 물리적 메모리량을 제어하도록 새로운 데이터베이스 구성매개변수인 db_mem_thresh을 추가해 왔다. 8. Sheapthres_shr 매개변수 변경 - Sheapthres_shr 매개변수는 어떤 한 시점에서Sort 메모리 소비가 총 데이터베이스 공유메모리의 양을 제한하는 것을 의미한다. Db2 8버전에서는 이것이 하드제한(Hard limit) 이었다. 만약 정렬 메모리가 한계에 가까워지면 경고가 발생된다. DB2 9의 Sheapthres_shr 매개변수는 소프트제한(soft limit)이다. 정렬 메모리 힙이 필요한 경우 추가적으로 제한없이 데이터베이스 공유 메모리를 사용할 수 있다. 9. AWE 지원이 사용되지 않음(Windows) - 64비트 운영체제 이전, DB2 초기버전에서는 가상주소공간을 초과하여 추가적인 물리적 메모리를 사용하기 위해서 32비트 Db2 서버를 사용할 수 있는 AWE기능을 지원했다. 그러나 64비트 플랫폼 도입으로 AWE 기능 사용의 요구가 줄어들게 되었다. 따라서 DB2 9에서는 DB2_AWE 레지스트리 변수와 함께 AWE기능에 대한 지원을 하지 않는다.
3 IBM DB2 아키텍쳐 및 프로세스 모델 - 2. DB2 Process Model imagefile
조인상
9622 2010-12-07
원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어 출처 : IBM Software Group - IBM DB2 Technical Evangelist - 왕천재님 자료에서 발췌 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ IBM DB2 아키텍쳐 및 프로세스 모델 1. DB2 Architecture & Engine Components 2. DB2 Process Model 3. DB2 Memory Model 2. DB2 Process Model [ DB2 프로세스 모델 구조 ] 1. DB2 Processing Model 지난 시간에 살펴본 프로세스기반 \모델의 구성도에서 좀더 자세히 살펴보면 다음과 같이 설명된다. 비교해보자. 큰 차이는 없지만 EDU가 하는 역할이 좀더 명확히 명시되어 있다. Coordinator Agent가 바로 db2agent. 2. Main DB2 EDU 의 구조 EDU : 데이터베이스 애플리케이션의 요청 처리, 데이터베이스 로그 파일 읽기, 로그 버퍼의 로그 레코드를 디스크의 로그 파일로 플러시하는 것과 같은 여러 작업 수행을 담당한다. 위 그림에서는 각 Instance / Application / Database / Request 레벨에서 하는 역할이 표시되고 있다. DB2 9.5 버전에서의 차이점. 프로세스 기반에서 스레드 기반으로 변경되면서 Instance 레벨에서 많이 간소화되었다. db2wdog, db2gds,db2fcmdm,db2srvlst 등이 삭제되고 db2aiothr 로 통합되었다. 3. 단일 DB 파티션 상에서의 DB2 프로세스 모델 - 데이터베이스 엔진과 관련된 프로세스들은 방화벽을 통해 외부의 응용프로그램 프로세스들과 다른 adress space를 사용하도록 구성되어있으므로, 데이터베이스 제어블록 및 중요한 데이터베이스 파일과 분리되도록 설계되어 있다. 3-1. 인스턴스 : 인스턴스 레벨의 프로세스는 db2start 명령을 실행하여 인스턴스를 기동할때 생성되며 db2fmcd, db2wdog, db2sysc, db2ckpwd, db2acd, db2fmd 가 있다. 그리고 동시에 db2sysc, db2tcpcm, db2pfchr, db2pclnr 등의 EDUs가 실행된다. 3-2. 데이터베이스 : 데이터베이스 레벨에서는 EDUs로 보여지며 activate db 명령어에 의해 데이터베이스가 활성화될때 생성되고, deactivate db 명령어에 의해 데이터베이스가 비활성화되면 제거된다. db2evmgi, db2fw0, db2wlmd, db2pfchr, db2pclnr, db2dlock, db2lfr, db2loggw, db2taskd, db2stmm등의 EDUs가 있다. 3-3. 응용프로그램 : 응용프로그램 레벨에서도 EDUs로 보여지며 지역 또는 원격 응용프로그램이 데이터베이스에 접속을 요청하는 경우에 생성된다. db2agent, db2agntp 등의 EDUs가 있다. 4. 다중 DB 파티션 상에서의 DB2 프로세스 모델 - 파티션 PROD(좌), 파티션 TEST(우) 다중 데이터베이스 파티션 환경에서의 EDU 역할 4-1. 인스턴스 : 단일 데이터베이스 파티션 환경과 동일한 시점에 생성되고 제거된다. db2pdbc, db2fcmd 등의 EDUs가 추가된다. 4-2. 카달로그 파티션 : 단일 데이터베이스 파티션 환경과 동일한 시점에 생성되고 제거된다. db2glock EDUs가 추가된다. 4-3. 데이터베이스 파티션 : 단일 데이터베이스 파티션 환경과 동일한 시점에 생성되고 제거된다. 4-4. 응용프로그램 : 단일 데이터베이스 파티션 환경과 동일한 시점에 생성되고 제거된다. * db2pdbc, db2panic, db2glock 등은 다중파티션 환경에서만 존재하는 프로세스 [ 인스턴스 수준의 프로세스 ] 1. 인스턴스 레벨의 프로세스 - 최초기동시 생성되는 프로세스들 1-1. db2sysc : DB2 9.5 이상의 시스템에서 db2start 명령과 동시에 발생되는 프로세스이다. 이 한개의 프로세스로 모든 파티션의 쓰레드를 처리하도록 멀티-쓰레드로 되어있으며, 여기에는 모든 EDU가 쓰레드로 구성되어있다. 따라서 이 프로세스 없이는 데이터베이스가 실행될 수 없다. UNIX환경에서는 db2sysc, Windows 환경에서는 db2syscs 로 명명한다. 1-2. db2gds : 9.1버전 DB2 Global Daemon Spawner 로 모든 EDU를 생성한다. UNIX플랫폼의 DB2 9.5 에서는 존재하지 않는다. 1-3. db2wdog : 9.1버전에서는 DB2의 PPID를 tracking. 새로운 프로세스가 시작될때마다 db2gds가 db2 watchdog에 알려주며 db2의 어느 프로세스라도 다른 비정상적인 signal을 받으면 그 프로세스는 watchdog에 signal을 보낸다. watchdog는 그 signal을 인스턴스내의 다른 프로세스에게 전달한다. 9.5버전 부터는 쓰레드기반으로 바뀌면서 db2gds가 없어졌으므로 db2wdog는 db2sysc를 감시하는 역할로 바뀌었다. db2sysc 프로세스의 비정상 종료시 IPC 자원을 정리하고, db2fmp 및 Health monitor 프로세스를 생성,정리,재시작시키며, Agent 의 스케줄링 우선순위(priority)를 조정한다. (단, DB2를 root로 설치하지 않았을때는 지원되지 않는 기능) 1-4. db2vend : Fenced Vendor Process. EDUs 에서 처리할 수 없는 모든 Vendor code 실행은 엔진외부에서 이 프로세스로 수행 예) userexit 1-5. db2fmp : stored procedures 또는 user defined functions(UDF) 와 같이 DB2 의 외부에서 실행되는 코드를 처리한다. db2fmp 프로세스는 항상 별도의 프로세스이지만 실행하는 루틴의 유형에 따라 멀티쓰레드일수 있다. DB2 8.7 이하에서의 db2udf 와 db2dari 프로세스가 db2fmp 프로세스로 대체되었다. 1-6. db2aiothr : 비동기식 I/O collector threads 1-7. db2licc : License controller. 1-8. db2acd : Health Monitor, 자동 유지보수 유틸리티 및 관리태스크 스케줄을 관장하는 Automatic Computing Daemon이다. db2hmon에서 db2acd로 바뀌었다. 2. 인스턴스 레벨의 프로세스 - Connect 시에 생성되는 리스너 2-1. db2ipccm : DB2 IPC Communication Manager. 데이터베이스에서 로컬로 접속을 요청하는 응용프로그램을 지원하는 통신 리스너 EDU. 한개의 로컬 응용프로그램으로 데이터베이스의 접속을 요청받으면, db2agent EDU를 생성하여 해당 응용프로그램 프로세스와 생성한 db2agent EDU를 연결한다. 연결이 완료되면, db2agent EDU가 로컬 응용프로그램 프로세스와 엔진을 연결하는 역할을 하게되고, db2ipccm은 새로운 접속 요청을 대기하게 된다. 2-2. db2tcpcm :DB2 TCP Communication Manager. TCP/IP 프로토콜을 이용하여 접속을 요청하는 원격 응용프로그램을 지원하는 통신 리스너 EDU. db2ipccm과 동일한 방법으로 작동한다. 2-3. db2snacm : DB2 SNA/APPC Communication Manager. SNA/APPC 프로토콜을 이용하여 접속을 요청하는 원격 응용프로그램을 지원하는 통신 리스너 EDU. db2ipccm과 동일한 방법으로 작동한다. 2-4. db2tcpdm : DB2 TCP Dicovery Manager. 클라이언트 머신에서 TCP/IP 프로토콜을 이용하여 원격 데이터베이스 서버의 인스턴스를 자동으로 발견해내는 기능인 DISCOVERY 요청을 처리하는 통신 리스너이다. 3. 인스턴스레벨의 프로세스 - 아카이브 로깅시 3-1. db2cart : 아카이브로깅에서 UserExit 가 설정되어있는 경우에 사용된다. 로그파일을 아카이브해야 하는 시점을 결정하고, Disk 또는 Tape 등의 저장매체로 로그파일의 아카이브를 실제로 수행하는 user exit 프로그램을 호출한다. UserExit 프로그램을 이용한 아카이브 로깅을 사용하려면 데이터베이스별로 설정해야 한다. 데이터베이스 구성변수인 LOGRETAIN=ON으로 설정하고 USEREXIT=ON으로 설정한다. 3-2. db2fmtlg : DB2 Format Log. UserExit 프로그램을 사용하지 않지만, 로그파일을 현재의 로그 디렉토리에 아카이브하는 경우에 로그파일을 미리 포맷하여 할당한다. DB2 엔진프로세스는 특정한 로그파일에 대한 기록을 완료하고, 다른 로그파일로 연속적으로 기록하는 경우에 새로운 로그파일이 생성될때까지 기다리지 않고 처리를 계속할 수 있도록 한다. UserExit 프로그램을 이용하지 않고 현재의 로그디렉토리에 아카이브만 하게 하려면 데이터베이스 구성변수인 LOGRETAIN=ON, USEREXIT=OFF로 설정한다. 4. 인스턴스 수준의 프로세스 - 특정명령어 유틸리티 4-1. db2chkau : DB2 Check Audit. db2audit 시작시에 생성된다. db2audit 유틸리티가 DB2 audit 로그파일의 각 항목을 audit 버퍼에서 $instance_home/sqllib/security/db2audit.log 파일로 로깅할때 사용된다. 4-2. db2govd : DB2 Governor Daemon. db2gov 시작시에 생성된다. db2gov 유틸리티가 governor configuration 으로 지정한 규칙에 따라 데이터베이스에서 수행되는 응용프로그램을 모니터링하고, 지정한 임계값을 초과한 응용프로그램에 대한 조치를 취하기 위해 사용된다. db2gov 유틸리티는 데이터베이스에 대한 응용프로그램이 아니므로, 데이터베이스에 접속하는것이 아니라, 인스턴스에 접속한다. 4-3. db2rebal : DB2 Rebalancer. 테이블스페이스에 Container 추가시 호출되어, 기존 데이터를 추가된 컨테이너로 균등하게 분산시키는 작업을 수행한다. 단, 컨테이너를 추가할 경우이며, 기존 컨테이너의 크기만 늘리는 경우에는 db2rebal 프로세스가 호출되지 않는다. 5. 인스턴스 수준의 프로세스 - 파티션 환경 - 한개의 SQL문을 두개의 파티션에서 병렬로 실행시키고자 할 경우 두개의 트랜잭션이 서로 Lcok wait이 결려 Dead Lock 이 발생하게 된다. - 이때 db2glock 프로세스가 점검하여 한쪽의 응용프로그램을 강제종료시켜 DeadLock 상태를 풀어준다. 5-1. db2fcmd : DB2 Fast Communication Manager Deamon. 파티션간의 통신에 사용된다. 5-2. db2fcms : Fast Communications Manager Sender. 5-3. db2glock : DB2 Global Deadlock Detector. 개별 파티션에 있는 db2dlock 프로세스로부터 수집된 정보를 모아서 데이터베이스 파티션간의 데드락 상태가 발생했는지를 점검한다. 카달로그 파티션에 존재한다. 5-4. db2panic : DB2 Panic. 특정한 데이터베이스 파티션에서 Agent 의 한계(PANIC)에 도달하게 되면 긴급 요청을 처리한다. 5-5. db2pdbc : DB2 Parallel Database Controller. 원격 데이터베이스 파티션간의 병렬요청을 처리한다. 개별 데이터베이스 파티션마다 한개씩 존재한다. 6. 인스턴스 수준의 프로세스 - Fault Monitor - db2fmcd 와 db2fmd 프로세스는 UNIX 플랫폼에서만 존재한다. - db2fmcd프로세스는 기본적으로 시스템 부팅시에 시작되도록 /etc/inittab 파일에 등록되어있다. ==> respawn:/opt/ibm/db2/V9.7/bin/db2fmcd 6-1. db2fmcd : DB2 Fault Monitor Coordinator Daemon. 시스템 부팅시에 생성된다.(/etc/inittab) 각 데이터베이스 서버머신에 한개씩 존재하며, db2fmd 프로세스에 이상이 없는지를 모니터링한다. 사용자가 kill 로 강제로 db2fmd 프로세스를 제거하더라도 db2fmcd 프로세스가 다시 생성시킨다. 6-2. db2fmd : DB2 Fault Monitor Daemon. db2start시에 생성된다. DB2 인스턴스를 모니터링 하는 데몬으로 DB2 인스턴스가 db2stop 명령어에 의하여 정상적으로 중지되는 것을 제외한 경우에 다시 엔진을 기동시키는 역할을 한다. HA 환경을 구성하는 경우에는 db2fmcd와 db2fmd 프로세스가 자동적으로 시작되지 않도록 해야 한다. 7. 인스턴스 수준의 프로세스 - OS 관련작업 7-1. db2ckpw : DB2 Check Password. DB2 UDB는 OS의 인증시스템을 이용하여 사용자에 대한 인증을 실행한다. 원격 클라이언트 응용프로그램에서 제공된 사용자명과 암호가 OS에 등록된 사용자 정보와 일치하는지를 점검하여 접속의 허용여부를 결정한다. AIX에서 사용자인증을 위해 /etc/security/passwd 파일을 사용한다. 7-2. db2resyn : DB2 Resynchronization. 2-phase commit 방식을 사용하는 응용프로그램에 대한 동기화를 담당한다. 단일 또는 다중 파티션 환경에서 모두 사용된다. 7-3. db2srvlst : DB2 Server List. OS/390과 같은 시스템에 대한 address list를 관리하는데 사용된다. parallel Sysplex와 함께 사용된다. 7-4. db2syslog : DB2 System Logger. OS의 시스템 오류 로그파일에 오류를 기록한다. 7-5. db2disp : DB2 Dispatcher. Connection Concentration 기능을 사용하는 경우에 생성된다. 응용프로그램에 할당되어 있는 Logical Coordinating Agent 와 사용가능한 Coordinate Agent 를 연결시키는 역할을 한다. [ 데이터베이스 수준의 프로세스 ] 1. 데이터베이스 수준의 프로세스 - Buffer Pool과 Tablespace I/O - 데이터베이스가 활성화될때 생성 (activate db 명령, connect 명령) 1-1. db2pfchr : DB2 Bufferpool Prefetcher. PreFetcher는 테이블과 인덱스의 데이터를 테이블스페이스 컨테이너인 디스크로부터 버퍼풀로 비동기식으로 미리 읽어들이는 역할을 한다. 각 응용프로그램을 대신하는 db2agent 프로세스가 db2pfchr 프로세스에게 PreFetch 요청을 보내면, db2pfchr는 Big-Block I/O방식으로 데이터를 효율적으로 읽어들인다. 데이터베이스 구성변수인 NUM_IOSERVER 를 이용하여 데이터베이스별로 활동할 PreFetcher의 개수를 지정한다.(자동) 1-2. db2pclnr : DB2 Bufferpool Page Cleaner. 버퍼풀에 가용공간을 확보하기 위해 버퍼풀로부터 비동기식으로 테이블스페이스 컨테이너에 변경된 데이터를 기록한다. 특정한 페이지클리너가 작업을 시작하면, 다른 페이지클리너들도 동시에 작업을 수행한다. 작업이 완료되면, 페이지 클리너 프로세스들은 sleep 상태로 대기하게 된다. 데이터베이스 구성변수인 NUM_IOCLEANERS를 이용하여 데이터베이스별로 활동할 페이지 클리너의 개수를 지정한다.(자동) 1-3. 변수, 구성요소들 - NUM_IOSERVER : 데이터베이스 별 프리페쳐 (db2pfchr) 개수를 지정하는 구성변수(자동) - NUMIOCLEANERS : 데이터베이스 별 페이지클리너 (db2pclnr) 개수를 지정하는 구성변수(자동) - good victim page : 프로세스가 버퍼풀의 페이지를 요구하는 시점 직전에 디스크로 변경사항이 기록된 페이지. Agent가 버퍼풀 전체를 검색할 필요 없음. 기준값이하로 떨어지면 페이지 클리너 호출 - Dirty Page : 버퍼풀에서 그 값이 변경되었으나, 테이블스페이스의 컨테이너에 아직 반영되지 않은 값이 포함된 페이지. - CHNGPGS_THRESH : 변경된 페이지 임계값 구성 매개변수. 기본값은 60%. 갱신작업이 많다면 기준값 이하로 설정하여 버퍼풀에 가용페이지를 충분히 확보하는것이 유리함. - Dirty Page Threshold : 버퍼풀의 Dirty Page의 비율이 구성값을 초과할때 db2agent가 페이지 클리너 프로세스를 호출 - LSN : Log Sequence Number. 엔진이 트랜잭션을 식별하고 추적할수 있게 번호를 매김. - MINBUFFLSN : Commit 되었지만, 테이블스페이스 컨테이너로 반영되지 않은 가장 오래된 LSN을 표시함. 버퍼풀에서 가장 오래된 Dirty Page의 LSN을 의미함. - SOFTMAX : 기본값은 100%. 복구범위 및 소프트 체크포인트 간격 구성 매개변수. 로그파일 한개 크기만큼. - LSN Gap Threshold : MINBUFFLSN과 현재 LSN의 차이가 SOFTMAX의 값을 초과할때 Log Writer 프로세스가 페이지클리너를 호출 2. 데이터베이스 수준의 프로세스 - 로그파일 I/O 2-1. db2loggr : DB2 Database Log Reader. 트랜잭션 롤백, 응급복구, 아카이브로그 적용시에 로그파일로부터 데이터베이스 로그 레코드를 읽어들이는 역할 2-2. db2loggw : DB2 Log Writer. - 로그버퍼에 공간이 없는 경우에도 로그버퍼에 저장된 로그레코드를 로그파일로 기록하는 역할 - 버퍼풀의 Dirty Page가 디스크로 반영되거나 commit 이 요청되는 경우에도 작동 2-3. WAL : Write Ahead Logging. 버퍼풀 또는 로그버퍼에 있는 데이터가 테이블스페이스의 컨테이너에 기록될때에는 반드시 로그파일에 먼저 기록이 되어야 함. 2-4. db2logts : DB2 log Tablespace. - 테이블스페이스가 변경될 당시에 어떤 로그가 활성화 상태였는지에 대한 history 정보를 수집하는데 사용 - 수집된 정보는 DB2TSCHG.HIS 파일에 저장되며, 테이블스페이스에 대한 롤포워드 복구시에 해당 테이블스페이스의 복구작업에 불필요한 로그파일은 적용하지 않으므로 복구의 성능을 향상시키는데 사용 2-5. DB2_COLLECT_TS_REC_INFO : 테이블스페이스를 롤포워드 할때 테이블스페이스에 영향을 미치는 로그레코드가 로그파일에 포함되어있는지 여부와 관계없이 DB2가 모든 로그파일을 처리하는지 여부를 지정한다. - 테이블스페이스에 영향을 미치는 로그레코드를 포함하지 않는 것으로 알려진 로그파일을 건너뛰려면 이변수를 ON으로 설정해야 한다. - 로그파일을 건너뛰는데 필요한 정보를 수집하기 위해 로그파일을 작성하고 사용하기전에 DB@_COLLECT_TS_REC_INFO를 설정해야한다. 3. 데이터베이스 수준의 프로세스 - 아카이브로그 3-1. 아카이브로그파일의 USEREXIT와 연관된 프로세스 - db2logmgr : LOGARCHMETH1 변수에 로그 디렉토리명이 지정된 경우에 사용. 사용자가 정의한 user exit program을 사용하지 않고, 엔진이 직접 로그파일을 아카이브 한다. - db2dlock : DB2 Local Deadlock Detector. 파티션마다 존재하며, LOCKLIST를 스캔하여 교착상태를 검출하는 역할 교착상태에 있는 응용프로그램중에서 희생자(victim)로 선택된 응용프로그램은 롤백. 희생자를 결정하는 우선순위는 내부적인 기준에 의해 결정. db2dlock은 Z잠금을 보유한 응용프로그램 또는 load, redistribute, online reorg등을 실행하는 세션은 희생자프로세스가 되지 않도록 고려 3-2. 데이터베이스 수준의 프로세스 - 기타 - db2estor : DB2 Extended Storage Manager. 데이터베이스 버퍼풀과 확장스토리지 사이에서 데이터 페이지를 복사할때 사용 NUM_ESTORE 변수가 설정된 경우에만 사용. 64비스테서는 필요없음 - db2even : DB2 Event Monitor 활성화된 이벤트 모니터에 대해 각각 한개씩 할당되어 이벤트모니터 정보를 수집. - db2taskd : 백그라운드 데이터베이스 태스크 분산용. 이러한 태스크는 db2taskp라는 스레드가 실행 - db2hadrp : HADR 기본 서버 스레드 - db2hadrs : HADR 대기 서버 스레드 - db2lfr : 개별 로그파일을 처리하는 로그파일 판독기용 - db2redom : Redo Master. 복구 중 redo 로그 레코드를 처리하고 redo 작업자에게 처리할 로그레코드를 지정한다. - db2wlmd : WorkLoad Manager. 워크로드 관리 통계의 자동수집용. - db2redow : Redo Worker. 복구중 redo 마스터의 요청에 따라 redo 로그 레코드를 처리함 - db2shre : 로그페이지의 개별로그 레코드 처리용 - db2thcln : EDU가 종료되면 자원을 재활용 (UNIX 전용) - db2alarm : 요청한 타이머가 만기된 경우 EDU에 통지(UNIX전용) - db2aiothr : 데이터베이스 파티션의 비동기 입출력 요청을 관리 (UNIX 전용) - db2pdbc : 리모트 데이터베이스 파티션의 병렬요청을 처리하는 병렬시스템 제어기(파티션 DB) [ 응용프로그램 수준의 프로세스] 1. 응용프로그램 수준의 프로세스 - 리스너 프로세스 - 지역 또는 원격 응용프로그램이 데이터베이스에 접속을 요청할 때 생성 1-1. db2agent : DB2 Coordinator Agent - 접속을 요청한 응용프로그램을 대신하여 엔진에게 응용프로그램의 요청을 전달하고, 엔진이 반환한 결과를 응용프로그램에 전달 - 응용프로그램별로 한개의 db2agent 프로세스로 관리 - Coordinator Agent 또는 간단하게 Agent 프로세스라고 함. 1-2. db2agntp : DB2 Sub-Agent - 병렬처리가 가능한 환경인 경우에 Agent는 응용프로그램으로부터 전달받은 요청들을 SubAgent에게 분해하여, 엔진에게 요청을 전달하도록 SubAgent들이 엔진으로부터 받은 결과를 다시 Agent에게 반환하면, Agent가 종합하여 응용프로그램에게 최종적인 결과를 반환함 - db2agentg : DB2 Gateway Agent DB2 Connect 제품을 이용하여 호스트 DB에 접속하거나, 다른 인스턴스를 경유하여 DB에 접속을 요청하는 경우에는 db2agent 대신에 db2agentg프로세스가 생성됨 1-3. 관련변수 - MAXAGENTS : 에이전트 프로세스의 총개수 - MAX_COORDAGENTS : 인스턴스에서 생성될수 있는 Coordinator Agent 프로세스의 최대개수 - MAXAPPLS : 데이터베이스에 접속할 수 있는 응용프로그램의 최대개수 2. 응용프로그램 수준의 프로세스 - Agent Pooling - SubAgent로 생성되어 사용이 완료된 프로세스는 성능을 위해 즉시 제거하지 않고 Agent Pool에 저장하였다가 재사용할 수 있다. - Agent Pooling을 사용시 응용프로그램이 접속을 요청시 에이전트를 생성하는 오버헤드를 줄임. - NUM_POOLAGENTS 와 NUM_INITAGENTS 조절. - db2agnta : 특정 응용프로그램에 대한 작업종료시 Agent Pool에서 응용프로그램에게 할당되기를 기다리는 Agent를 Idle Agent라고 하고, 다른 Coordinator Agent 에 의해 요청되어 다시 SubAgent로 사용됨 - Agent 프로세스 할당 우선순위 결정방법 (Assigning SubAgents) = 요청한 응용프로그램과 연관이 있으면서 Idle 상태에 있는 SubAgent를 할당 = 다른 응용프로그램과 연관이 있으면서 Idle 상태에 있는 SubAgent를 할당 = MAXAGENTS 구성변수의 값에 도달하지 않았다면 새로운 SubAgent를 생성 = 다른 응용프로그램과 연관이 있으면서 Idle한 SubAgent를 가로채기 함. 3. 응용프로그램 수준의 프로세스 - 병렬복구처리 - Coordinator Agent는 읽어온 로그레코드를 병렬프리페쳐를 이용하여 버퍼풀로 저장. - Parallel Recovery Agent 들은 버퍼풀의 데이터를 이용하여 병렬로 복구작업을 진행. - db2agnsc : DB2 Parallel Recovery Agent = 로그파일에서 읽어온 로그레코드의 내용에 따라 rollforward restart db, rollforward 명령을 병렬로 처리하여 복구유틸리티의 성능을 높이기 위해 사용 = 병렬처리에 사용되는 Agent 프로세스의 개수는 SMP머신의 CPU개수를 고려하여 엔진이 결정.
2 IBM DB2 아키텍쳐 및 프로세스 모델 - 1. DB2 Architecture & Engine Components imagefile
조인상
9599 2010-12-06
원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어 출처 : IBM Software Group - IBM DB2 Technical Evangelist - 왕천재님 자료에서 발췌 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ IBM DB2 아키텍쳐 및 프로세스 모델 1. DB2 Architecture & Engine Components 2. DB2 Process Model 3. DB2 Memory Model 1. DB2 Architecture & Engine Components 1. DB2 버전별 차이점 < DB2 9.1 - 프로세스 기반 모델 > - 각 원들은 OS의 프로세스들이다. < DB2 9.5 이후 - 다중 스레드 기반 프로세스 모델 > - 빨간색 네모상자는 인스턴스를 제공하는 단일 OS 프로세스(db2sync)를 의미한다. 그 안의 원들은 OS 스레드이다. - 9.5 이후부터는 스레드 기반으로 바뀐걸 표시하고 있다. 2. DB2 아키텍쳐 설명 1. 새 멀티스레드 기반 메모리모델의 장점 - 더 단순하고 쉽게 구성된다. @ 구성 메모리와 메모리 heap @ 간단해진 메모리 구성 2. 새 모델은 리소스를 저장한다. - OS file descriptor 사용이 현저하게 줄어들었다. Process 와 Thread 의 가장 분명한 차이는 Process 안의 모든 Threads 가 동일한 메모리 공간과 시스템 정의기능(system-defined facility)을 공유한다는 것이다. 이 기능에는 Open File Handle(File descriptor), Shared Memory, 프로세스 동기화 원본(Primitive), 현재 디렉토리가 포함된다. Process내 모든 Thread는 같은 File descriptor를 공유할 수 있다. 각 에이전트가 자신의 File descriptor table을 가질 필요가 없다. 3. 성능이 향상되었다. - 일반적으로 OS는 다른 프로세스 간에서보다 같은 프로세스내 Thread 간에 더 빨리 Context Switch (문맥교환)할 수 있다. Memory Address 공간을 전환할 필요가 없다. Global Memory 가 공유되고 새 메모리를 할당할 필요가 없으므로 Thread를 만드는 것이 Process를 만드는 것보다 더 간단하고 빠르다. 프로세스 생성은 Processor Cycle과 Memory 사용량 측면에서 비용이 많이든다. 4. 자동화되고 동적인 파라미터가 많기 때문에 DBA가 수행해야할 작업이 줄어들었다. 5. 프로세스 모델이 이제 Linux,Unix,Windows 각각 플랫폼에서 모두 똑같다. 3. 단일 데이터베이스 파티션의 아키텍쳐 1. DB2 엔진은 고유한 기능을 담당하는 여러개의 EDU(Engine Dispatchable Unit)로 구성되어 있으며, 각 EDU는 UNIX에서 Thread로 구현된다. 2. 어플리케이션이 DB에 접속을 요청하면 전용 CoornidatorAgent 프로세스가 생성되어 어플리케이션을 대신하여 DB에게 필요한 SQL문의 실행을 요청하는 역할을 하게 된다. 클라이언트와 서버사이의 통신에는 TCP/IP, APPC, Netbios 등의 프로토콜이 지원된다. 3. 에이전트 프로세스가 필요한 데이터를 가져오기 위하여 Prefetch Queue를 통해 비동기방식의 읽기요청을 하면 Prepatcher 프로세스는 big-block I/O를 통해 요청된 페이지들을 버퍼풀로 미리 가져오므로 에이전트 프로세스는 디스크 I/O 대기시간을 줄일수 있다. 4. 페이지 클리너는 백그라운드 EDU로 특정상황이 될때마다 버퍼풀의 DirtyPage를 디스크로 미리 반영하여 버퍼풀의 가용공간을 확보함으로써 버퍼풀을 사용하는 에이전트프로세스가 대기하는 일이 없도록 한다. 5. 변경된 데이터 페이지와 로그레코드는 성능을 위해 디스크로 즉시 반영되지 않는다. 변경된 데이터를 디스크에 반영할때는 반드시 로그파일에 먼저 기록된다. 이러한 방식을 Write Ahead Logging 이라고 한다. - SMP 머신에서 파티션내 병렬 기능을 이용하면, 여러개의 SubAgent를 이용하여 쿼리를 병렬로 처리할 수 있다. - 에이전트프로세스의 생성과 제거로 인한 오버헤드를 줄이기 위해 에이전트프로세스를 위한 POOL을 운영할 수 있다. - 데이터가 여러 디스크에 걸쳐 스트라이핑 되어있다면, 여러개의 Prefetcher 를 지정하여 여러디스크를 동시에 Access 할 수 있도록 한다. 4. 다중 데이터베이스 파티션의 아키텍쳐 - 다중데이터베이스 파티션 환경에서 클라이언트에게는 단일 데이터베이스 관점으로 보인다. - 다중 파티션에서 환경변수, 전역 수준 프로파일 레지스트리, DB 환경 및 디렉토리등을 공유하는것을 알 수 있다. 1. DB2 UDB(버전 8.x)의 Data Partitioning Feature는 다중 데이터베이스 파티션 기능을 이용하여 병렬데이터베이스를 구축한다. 다중 데이터베이스 파티션에 생성된 데이터베이스는 사용자에게는 한개의 논리적인 데이터베이스로 인식되지만, 각 파티션에 물리적으로 데이터베이스를 생성한다. 파티션별로 생성된 데이터베이스는 일반적인 단일 데이터베이스와 동일하게 독립적인 자원을 사용할 수 있으므로 각 파티션은 버퍼풀, 잠금관리, 디스크등을 독립적으로 운영하게 된다. 2. 데이터베이스 파티션은 동일한 머신에 생성되는 논리적 파티션과 다른 머신에 생성되는 물리적 파티션으로 구분된다. 동일한 머신에 존재하는 데이터베이스 파티션들은 공유 메모리를 이용하여 통신하고, 다른 머신에 존재하는 데이터베이스 파티션끼리는 고속의 네트워크을 통해서 필요한 부분만 통신한다. 3. 응용 프로그램이 접속을 요청하면, 접속한 데이터베이스 파티션에 Coordinator Agent 프로세스가 생성되고, 다른 파티션에는 Subagent 프로세스들이 생성된다. SQL문은 Global optimizer에 의한 최적화된 후에 각 Subagent들에게 전송된다. Subagent가 해당 파티션의 데이터베이스에 대해서만 SQL문의 요청을 처리하여 결과를 Coordinator Agent 프로세스에게 반환하면, Coordinator Agent는 응용 프로그램에게 최종결과를 반환한다. § 4. MPP 머신으로 구축한 DB2의 다중 데이터베이스 파티션 환경은 완전한 Shared Nothing Architecture를 제공하므로 확장성이 좋다. – - 다중 데이터베이스 파티션 환경에서는 파티션간 병렬처리가 자동적으로 적용되며, 파티션 내 병렬 처리기능과 함께 사용 할수도 있다. – - 한 개의 서버에 기본적으로 4개의 논리적 파티션이 생성 될 수 있으며, 필요 시 4개 이상도 생성 할 수 있다. – - SQL문을 처리하는 각 Subagent 들의 실행은 모든 파티션을 통하여 병렬로 처리된다. DB2가 제공하는 여러가지 유틸리티들도 모두 병렬로 처리된다. 5. DB2 Database System §1. DB2 UDB 데이터베이스시스템 ( 엔진, 인스턴스, 데이터베이스로 구성) – - 엔진 : 서버 머신에 설치된 실제적인 제품 모듈 – - 인스턴스 : DB 엔진을 사용하기 위한 논리적인 환경 – - 데이터베이스: 실질적인 데이터 파일 § 2. 엔진, 인스턴스, 데이터베이스, 테이블스페이스 컨테이너 등 은 물리적으로 분리 되어 있으므로 제품의 재설치, 인스턴스의 재생성시에도 데이터베이스와 관련된 물리적인 파일은 보존되고, 필요시에 다시 사용할 수 있습니다. 6. DB2 Architecture 1. DB2 Engine Components - OSS : Operating System Services : Sqlo~ "모든operating system call을 만들고 모든memory 관리와 file I/O를 조정하며 Process를 생성한다. " Memory management File input and output (disk access) Process and thread creation and management Semaphore processing Authentication with the operating system" - EDU : Engine Dispatch able Unit : "데이터베이스 애플리케이션의 요청 처리, 데이터베이스 로그 파일 읽기, 로그 버퍼의 로그 레코드를 디스크의 로그 파일로 플러시하는 것과 같은 여러 작업 수행을 담당한다." - BSU : Base Service Utilities : Sqle~ "db2 instance의main 엔진으로db2start시EDU( engine dispatchable Units)라고 불리는다른 components의 process를 invoke 하고memory를 할당 하는 등의 일을 한다. " - SQMO : Memory Optimizer : " Memory balancing 서비스를 하며 동적memory 할당 관리를 지원한다 " - RDS : Relational Data Services : Sqlr~ "Common Client (CCI) 의function pointer로부터invoke되며statement를 최적화 하여plan을 만들고 data 추출을 위해 이 plan을DMS에 보내는 일을한다. DMS로 부터 받은result set은CCI를 통해application으로 넘겨준다. " - DMS : Data Management Services : Sqld~ "RDS로부터access plan을 받아 그 plan대로 data를 추출한다. Data 추출을 위해 index manager, sort list services, file manager등을call한다. Result set을RDS로 반환한다." - SLS : Sort List Services : Sqls~ "DMS에 의해 호출되며 Index build 나 order by, group by 등에 의한 정렬을 수행한다." - IXM : Index Manager : Sqli~ "DB2에 있는 모든 index 관리를 하며 Multi Multi-dimensional clustered indexes와 Online Index reorganization 및rebuild를 포함한다." - DPS : Data Protection Services : Sqlp~ "logging, locking과 같이data 정합성을 보장하는 기능을 제공한다. " - BPS : Buffer Pool Services : Sqlb~ "모든 data, index, temp overflow page는 buffer pool에서 가공되며, file storage나 raw storage manager를 사용하여OSS를 통해 page를 읽어온다." - CCI : Common Client : Sqlc~, sqlkf~ "모든client/server communication을 조정한다." 2. DB2 Architecture dpswls Components - Function Names 7. db2dialog.log 파일의 예시 - 로그파일안에서 동작하는 프로세스명, 컴퍼넌트 및 함수명에 주목. 1. DB2 엔진기동 - 호출 function : BSU : sqle 2. TCP Listener 기동 - 호출 function : CCI : Common Client : sqlc 3. 첫번째 Connection 연결 - 호출 function : DPS : Data Protection Services : sqlp~ BPS : Buffer Pool Services : sqlb~ 4. SQL 실행 - 호출 function : RDS : Relational Data Services : sqlr~ DPS : Data Protection Services : sqlp~ 5. DB2 유틸리티 수행 (Load) - 호출 fuction : Database Utilities : sqlu~ Index manager : sqli~ 6. TableSpace 생성시 Storage 부족 - 호출 fuction : Data Management Services : sqld~ 7. DB2 Configuration 변경 - 호출 fuction : Configuration Services : sqlf~
1 IBM DB2 Overview file
조인상
5655 2010-11-26
원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ IBM DB2 Overview ------------- 1. 관리비용 절감 - 자가 최적화 ( Self-Optimizint) - 자가 치유 (Self-Healing) - 자가 구성(Self-Configuring) - 워크로드 관리 - 확장된 자동화 기능 2. 스토리지 비용 절감 - Deep Compression 기술 : 최대 83%에 달하는 데이터 압축률 - 디스크 I/O 최소화 -> 효율적인 메모리 사용으로 성능 향상 - 데이터 압축으로 인한 스토리지 관련 에너지 비용 절감 -> 환경오염 물질의 배출 감소 ( Index 압축, Large Object 압축을 포함한 스토리지의 최적화 강화) 3. 서버 비용 절감 - 오라클에 비해 1/2개의 프로세서를 가지고도 성능이 49% 더 우수함 - 더 낮은 서버비용 -> 더 낮은 SW라이센스 비용 -> 더 낮은 SW관리 비용 - 개발비용 절감 : PL/SQL 컴파일러 내장을 통한 오라클 어플리케이션 호환성 확보 4. DB2에 대한 진실 - DB2 HADR : 업계에서 가장 빠른 고가용성 솔루션 : RAC는 디스크 장애에 대처할수 없음. 이를 위해서 오라클 DataGuard 또는 스토리지 복제 솔루션을 구매해야 함. : DB2의 장점은 추가 비용없이 HADR로 구성가능. : RAC처럼 Active-Active를 지원하지는 않지만 한대의 서버로 두대의 오라클 RAC트랜젹선을 소화가능할 만큼 고성능 : 실시간 복제를 통한 TakeOver 시간이 빠름. - InfoSphere Warehouse : DB2 기반의 실시간 DW구현 솔루션 - DB2 pureXML : XML 데이터 처리 5. DB2 경험 혜택 프로그램 - DB2 Early Access Program - Power of DB2 Program