IBM DB2 UDB Blog Center

유닉스의 “Cron”, 윈도우의 “예약된 작업”을 사용하여 DB2 관리 작업을 자동화 한다. 보통은 OS의 스케줄링 기능을 이용하는데, DB2 자체에서도 기능이 있는지 문의를 받는 경우가 있다.

기능은 있다. 그러나 권장하지는 않는다.(왜 권장하지 않는지는 글을 읽으면 알게 될 것이다.)

DB2 자체의 작업 스케줄링 기능을 어떻게 설정할 수 있는지 살펴 보자.

Windows에서도 DAS (DB2 Administration Server)라는 용도로 계정을 설치할 때 묻는다. Unix나 Linux 에서는 OS 계정으로 인스턴스나 DAS를 생성하기 때문에 설치 작업 하면서 DAS를 왜 만들어야 하는지 의문을 많이 가졌을 것이다.

이 DAS 가 하는 주 업무가 DB2의 작업 스케줄링을 해주는 것이라 보면 되겠다. 물론 DAS의 개념? 역할?은 이것으로 한정되지는 않는다.

1. 도구 카탈로그 설정

   인스턴스가 dbm cfg 라는 구성 변수를 가지고 있듯이 das도 자체 구성 변수를 가지고 있다. 앞으로 기술되는 명령어는 인스턴스 계정으로 실행하면 확인할 수 있다.

   아무런 설정 작업을 하지 않았다면 다음과 같이 결과가 나온다.

도구 카탈로그가 되었다면 다음처럼 몇 개의 변수에 값이 들어가 있을 것이다.

도구 카탈로그 작업을 하기 전에 다음처럼 해당 변수 값을 초기화 한다.

도구 카탈로그 작업을 한다.

- 스케줄링:ON

- 도구 카탈로그 DB명: sample

- 도구 카탈로그 인스턴스명: inst97

- 도구 카탈로그 스키마명: systools

“도구 카탈로그 작업”시 데이터베이스 선택은 원격지의 것이던, 운영되는 시스템의 것이던 상관없다. 이와 관련된 자세한 설정은 정보 센터를 참고하면 될 것 같다.

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.admin.cmd.doc/doc/r0008881.html

이 후의 작업은 GUI 도구인 “Task Center”를 이용하여 진행한다.

2. 작업 스케줄링 설정

(1) 태스크 센터에서 “새로 작성”을 선택한다.

(2) 태스크 이름, 명령어 유형 등등을 선택, 기입한다.

(3) 실행할 스크립트를 “명령 스크립트” 탭에 작성한다.

(4) 작업 스케줄링 설정

(5) 사용자 권한 설정 및 확인

(6) 생성한 task 실행 테스트

db2 백업 이미지가 생성되었다. 이제 시간 설정하여 주기적으로 실행되도록 설정만 하면 되겠다.

3. 작업 기록 확인하기

(1) 저널 실행

(2) 실행 기록 목록

(3) 실행 기록 확인

도구 카탈로그를 하는 이유는 “스케줄링 설정 정보”를 “기록”하고, 실행 이력을 관리할 저장소를 설정하는 작업이다.

가끔 GUI 기반으로 DB2 설치 작업을 하다 보면 “도구 카탈로그” 를 할 것이냐는 화면을 본 적이 있을 것이다. 만일 선택을 하게 되면 “TOOLSDB”라는 데이터베이스가 생성되고 이 데이터베이스는 이처럼 작업 스케줄링관련 정보를 저장하는 데이터베이스가 된다.

DB2를 사용하면서 TOOLSDB가 만들어진 경우를 봤을 것이다. 사용을 하던 하지 않던 설치 시 “도구 카탈로그” 선택하면서 생성이 되어진 결과이다.

운영 시스템에 “작업 스케줄링” 정보를 기록하도록 하는 경우는 없을 것 같다. 그렇다고 운영시스템에 이를 위한 별도의 TOOLSDB 데이터베이스를 생성하여 사용하지도 않을 것이다. (자원 낭비이기 때문에)

원격지에 DB2를 스케줄링 작업을 하는 용도로 사용한다고 해도, DB2 엔진이 설치되어져야 하고 데이터베이스가 있어야 한다. 스케줄링 하기 위해 작업을 많이 필요로 한다.

이런 번거로운 작업하느니 편하게  Cron이나 "예약된 작업”을 설정하여 OS상에서 실행되도록 하는 것이 번거로운 설정/구성 작업도 없고, 관리 포인트를 불 필요하게 가져가지 않는 것이 현명할 것이다. (해야 되고 관리해야 될 작업이 많은 DBA입장이라면 현실적으로 쓰지 못할 것이다.)

IBM에서 InfoSphere 라는 용어가 나오기 전에는 WebSphere Federation Server (WFS) 라고 불리었다. (DB 관련 제품인데 WAS쪽으로 편입된 것이 일하면서 이상하게 느껴지긴 했었다.)

Federation (국내에서 “연합” 이라고 번역되는 것 같다) 구성에는 크게 2가지로 분류가 된다.

Homogeneous Federation과 Heterogeneous Federation.

Homogeneous Federation은 같은 DBMS의 DB federation을 의미한다. (그러나 사실은 한 벤더의 DBMS를 의미한다고 봐야 될 듯 하다. Informix federation 도 제공한다.) 이 기능은 DB2 for LUW 제품을 쓰면 기본으로 사용 가능하다.

그러나 Hetrogeneous Federation 은 Oracle 이나 MS-SQL 등의 타 제조사의 DBMS의 DB를 federation을 의미한다. 이 경우는 DB2 설치 버전 이외 별도의 InfoSphere Federation Server를 설치해 주어야 한다.

Heterogeneous Federation 은 지면이 길어지는 관계로 다음 기회로 미루고, DB2내의 Federation을 살펴 본다.

1. DBM 구성변수 값 변경

    FEDERATED라는 변수는 기본으로 NO로 되어 있다. 이 값은 YES으로 설정한 후 인스턴스를 재시작한다.

2. Federation 구성 환경 (예)

3. 카탈로그 설정 작업

    inst2에서 inst1의 db1에 대한 연결 정보를 가지고 있어야 한다.

4. Wrapper 생성

5. Federation Server 생성

6. 사용자 매핑

7. 원본 테이블/뷰에 대한 nickname 생성

여기까지의 작업으로 IFS 설정은 완료 되었다.

IFS설정 부분에 대해서는 다음과 같은 형식으로 작성해서 일괄 실행할 수도 있을 것이다.

참고로 “create server” 를 실행할 때, shell의 특수문자 인식 방식으로 db2 clp에서는 사용자 계정과 비밀번호에 Escape 문자인 \ (역 슬래시) 을 넣어 주었다. 넣어 주지 않으면 계속 syntax 오류가 발생한다.

현업 업무 중 DB2의 메모리인 버퍼풀을 조정하기 위해 보통 Alter 명령을 사용한다.
예를 들면 아래와 같다.

db2 "alter bufferpool BP_8K size 2000"
db2 "select * from syscat.bufferpools"(버퍼풀의 조회)

근데 간혹 버퍼풀의 size를 조정할 때 위의 사이즈를 페이지단위가 아닌 바이트 단위로
착각하여 엄청난 크기의 버퍼풀을 생성하는 오류를 범할 수 있다.
(실제 현업에서 담당자가 위의 실수를 하여 운영 업무에 영향을 준적이 있다.)

문제는 DB2의 데이터베이스 Activate 시 실제 물리적메모리의 양을 초과하여 Paging을
유발 함으로써 DB접속이 상당히 오래 걸리거나 아예 안되는 상황이 발생할 수 있게 된다.
(실제 DB2 Activate 시 할당된 Bufferpool로 Shared Memory를 생성한다.)

이런 만약의 사태를 대비하여 DB2는 Resgistry 변수에 특별한 옵션이 존재 하며 이를 활용
하여 위의 사태를 해결할 수 있다.

DB2_OVERRIDE_BPF Registry 변수의 사용이다.

DB2SET DB2_OVERRIDE_BPF=1000(Page 단위)의 옵션을 사용하여 DB상의 설정된 버퍼풀로
Active 하는게 아니라 위의 옵션으로 Override하는 것이다.

다음은 위의 명령을 실행하는 절차이다.
====================================================================================
1. db2stop
2. db2set DB2_OVERRIDE_BPF=1000
3. db2stop
4. db2start
5. db2 activate db CNIDB
6. db2 "alter bufferpool BUFF size 1000"(기존에 하고자 했던 사이지로 재조정)
7. db2set DB2_OVERRIDE_BPF=
8. db2stop
9. db2start
10. db2 activate db CNIDB

관리하는 시스템이 많아지고, 체계적으로 시스템이 관리되지 않다 보면 서버에 누가! 무엇을! 설치해 놓았는지 알 수 없게 된다.

컴플라이언스 문제로 서버에 DB2가 설치되었는지 여부를 확인할 필요성이 생길 것이다.

DB2에 대한 어떠한 정보도 모르는 상태에서 DB2가 설치되었는지 확인해 보고, 설치된 경우 인스턴스를 확인해서 DB가 존재하는지 등을 살펴 봐야 할 것이다.

1. DB2가 설치되어 있나?

    DB2 제품을 설치하게 되면 (리눅스, 유닉스 기준) OS가 사용하는 파일 시스템인 /var 하위에 db2 라는 디렉토리가 생긴다. 그 안에는 global.reg 라는 파일이 만들어 지는데 install한 경우는 설치한 정보가 기록되고, 인스턴스를 생성하면 인스턴스 정보들 까지 기록이 된다.

    위 파일을 vi 로 열어 보면 binary code가 들어가 있어 보기가 불편하다. 그래서 /var/db2 라는 디렉토리가 존재하면 db2가 설치가 되었던 시스템이라 판단하면 되겠다.

     좀 더 편히 보기 위해서는 /usr/local/bin 하위에 있는 db2ls 라는 쉘을 실행시켜 시스템 내에 설치된 DB2 버전과 설치 위치, 설치 날짜를 확인할 수 있다.

2. DB2 계정은 어떻게 되지?

엔진 설치 경로를 들어가서 instance라는 디렉토리 하위의 db2ilist, daslist 를 실행하면 생성된 인스턴스 이름을 확인할 수 있다.

3. 사용 중인 DB2는 서버 용인가? 클라이언트 용인가?

한 개의 인스턴스가 존재함을 확인하였다. 해당 인스턴스 계정으로 변경한 후, db2 get dbm cfg 명령어 수행한 결과를 통하여 생성된 인스턴스가 ESE, WSE인지 혹은 클라이언트 용인지 확인할 수 있다.

ESE나 WSE 등의 서버 제품이면 db2_ps 명령어로 서버 프로세스가 실행 중인지 확인하고, db2 list db directory 결과를 통해 로컬 DB가 있는지 확인한다.

위 예제는 pureScale 환경으로 2개의 인스턴스가 실행 중이고, 1개의 DB가 존재한다.

업무 환경, 요건에 따라서 DB 목록들을 파악하여 업무용으로 쓰는 것인지? 사용하지 않는 것인지 ? 등등 확인해서 불필요한 DB나 인스턴스는 제거하여 관리를 해야 될 것이다.

기술지원 하다 보면, 고객사 compliance 문제로 지원 요청을 하는 경우가 발생한다. 우리가 쓰는 DB2가 구입한 라이센스에 적합하게 사용하는지를 알고 싶어서다. 경우에 따라서는 시스템에 DB2 서버가 설치되어 있는지 확인하는 방법에 대한 문의 요청도 들어 온다.

DB2가 설치되어 있는지 확인하는 방법은 다음에 쓰기로 하고, 라이센스 확인 및 위배 여부를 확인하는 방법을 알아 보도록 한다.

1. 우리가 쓰는 DB2 머신의 자원과 운영 체제 버전은 무엇인가?

    DB2에서는 OS의 정보와 자원 정보를 db2pd나 sysibmadm 스키마의 어드민 뷰를 통해 확인할 수 있다.

    다음은 sysibmadm.env_sys_info 뷰를 조회하여 확인한 os 정보 결과다.

    (db2pd는 db2pd –osinfo를 통해서 확인할 수 있다.)

2. DB2 라이센스 상태는 어떻게 확인하지?

  db2licm 명령어나 sysibmadm.env_prod_info 관리 뷰를 통해 확인이 가능하다.

(db2licm 명령어는 db2licm –l 을 실행하여 확인한다.)

3. 라이센스에 위배되어 사용 중인 기능(feature)가 있을까?

    db2licm –g 나 sysibmadm.env_feature_info 관리 뷰를 통해 확인할 수 있다.

     => Storage Optimization 기능이 라이센스 위배되었음을 확인할 수 있다.

         (테이블에 compress 옵션을 주었을 가능성이 높다.)

4. 참고

  위 기능에 대해 정보센터 내용을 간략하게 정리해 보면

  (1) Advanced Access Control 기능 : LBAC

  (2) HA 기능 : HADR

  (3) Performance Optimization : MQT, MDC, Query Parallelism (interquery parallelism)

  (4) Storage Optimization : Compression

보다 자세한 정보는 정보 센터를 참고 한다.

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.admin.trb.doc/doc/t0053718.html

데이터 적재 작업을 하던가 DB 운영 작업을 하면 테이블만 남기고 데이터를 삭제해야 되는 경우가 발생한다.

현재 V9.7 코브라에서는 truncate 명령문을 지원하지만 그 하위 버전에서는 사용할 수 없었다. (V9.5에서는 Registry 변수 DB2_COMPATIBILITY_VECTOR  값을 설정함으로써 제한적으로 사용 가능했던 것으로 기억이 난다. 현재 9.5 정보센터를 찾아보니 검색되지 않는다.-_-;)

9.7 코브라가 나오기 전에 이런 작업을 어떻게 했는지 기록을 남겨 본다.

(1) db2 load/import 를 사용하는 방법

    (유닉스, 리눅스) db2 “load from /dev/null of del replace into 스키마명.테이블명”

    (윈도우)            db2 “load from 빈파일명 of del replace into 스키마명.테이블명”

          * 빈 파일명: notepad를 실행하여 만든 내용없는 텍스트 파일(txt) 을 의미한다.

(2) Alter Table 명령문의 사용하는 방법

    (유닉스,리눅스,윈도우) db2 “alter table 테이블명 activate not logged initially with emtpy table”

    * 참고: ‘not logged initially’ 키워드는 테이블 단위 로깅 옵션이다. transaction log 파일에

              로깅하지 못하게 하는 옵션이며 추가적으로 with empty table 구문을 주어 로깅없이 테

              이블의 데이터를 삭제한다.

DB2 적인 truncate 표현법은 alter table을 이용한 명령문이라 할 수 있겠다.

추가로, not logged initially 옵션은 Insert ~ Select 방식의 대용량의 데이터를 작업 상황에서 트랜잭션 로그 full 상황을 피하고자 할 때 사용할 수 있다.

이 경우 한 트랜잭션(작업 단위, UOW) 안에서 처리를 해야 되기에 db2 CLP 옵션을 주어야 한다.

db2 +p +c –tv <<EOF

alter table 테이블명 activate not logged initially ;

insert into 테이블명 select * from 테이블1 ;

EOF

혹은 위 SQL을 파일로 만든 후 “db2 +c –tvf 파일명” 으로 실행을 할 수도 있다.

이런 식으로 하면 대용량 데이터를 추가/변경/삭제 작업 시, transaction log full이 발생하는 것을 피할 수 있다.

단, 해당 SQL이 실행 중에 오류가 발생하거나 작업이 정상적으로 실행되지 못해 rollback되는 경우 table을 재생성 해야되므로 주의해서 사용해야 된다.

참고: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.sql.ref.doc/doc/r0000888.html

DB2 기술지원을 하다, 혹은 DB2 사용하다 문제가 생겨 DB2 진단로그(db2diag.log)를 열어 보다 보면 너무나 많은 메시지들과, 한 메시지가 여러 줄에 걸쳐져서 보기 힘들었을 것이다.

db2diag 명령어를 통하여 주요 메시지만 걸러서 볼 수는 있었지만, 시간단위 한 줄로 편히 보기에는 불편했다.

DB2 V9.7에서 db2diag 명령어의 -fmt 옵션이 추가되었는 줄 알았는데, V9.5에서도 -fmt 옵션이 지원이 되어 "사용자가 원하는 방식으로" 메시지를 정돈해서 볼 수 있게 되었다.

그래서 "특정 DB"의 메시지 레벨이 "Warning, Severe, Error"인 메시지의 PID, TID, PROC, APP핸들과 메시지를 정돈해서 볼 수 있다.

다음 명령어는 "timestamp 를 줄 단위"로 메시지를 정돈해서 볼 수 있다.

db2diag -time YYYY-MM-DD -gi db=디비명 -level Warning,Severe,Error -fmt "%{ts} [%{level}] PID:%{pid} TID:%{tid} PROC:%{proc} DB:@{database} APPHDL:@{apphdl} @{message}" >> db2diag_output.log

위 명령어 결과를 통해 "문제 시 되는 에러 메시지"를 확인하여, 해당 메시지의 "시간 대" 및 "PID" 등의 값을 통해 해당 메시지를 제대로 볼 수 도 있을 것이다.

참고로 V9.7 부터는 dbm(인스턴스) 구성 변수 중 diagsize 값(단위 MB) 설정을 통하여 진단로그 및 통지로그(nfy)가 크기가 무한정 늘어나는 것을 방지할 수 있다.

CentOS 5.6 인 경우,

1. /etc/redhat-release 파일의 내용을 다음과 같이 교체함!

2. compat-libstdc++-33 rpm 패키지를 설치함!