IBM DB2 UDB Blog Center

DB2의 데이터 관리는 page 단위로 이뤄진다. 그리고 지원하는 page 크기는 4K, 8K, 16K, 32K 가 존재한다.

이번 달에 출시된 V10.5 에서는 페이지 크기를 넘는 row를 기존 페이지에 관리할 수 있는 기능이 지원되었지만, 이런 page 단위의 데이터 관리는 IO 성능 관리에서 중요한 부분을 차지한다.

DB2에서는 여러 page에 데이터가 분리되어 들어가는 것을 허용하지 않기 때문에 데이터 단편화(?) 가 발생하지 않는다.

반면, 테이블을 생성 전 어떤 페이지 크기로 사용할 것인지 고민이 필요하다.

이런 데이터 단편화에 대한 의미는 2가지로 구분을 할 수 있는데, 일반적으로는 “row chain”으로 인식이 되는 것 같다.

그래서 경쟁사에 비해 DB2는 데이터 단편화가 발생하지 않는다는 말을 과거에 많이 들었고 경쟁사 대비 장점이였다.

그러나 DB2도 단편화는 발생한다. 이것을 DB2에서는 overflow라고 표현을 하는데  기존 record가 수정되면서 공간 부족으로 현재의 page에 저장이 되지 못하는 경우, 여유있는 페이지에 record를 저장하고 record가 저장된 위치만 현 page에 저장이 되는 현상을 말한다.

이것을 row migration 이라고 표현을 한다.

나름 엄격한 데이터 관리 방식으로 데이터 단편화를 현상을 원천 봉쇄를 하지만, 수정된 데이터에 대해서는 row migration은 발생할 수 있고

syscat.tables 뷰의 overflow 컬럼을 통하여 migration된 페이지를 확인할 수 있다.

이 수치가 커지는 경우 table reorg 및 index reorg 작업이 수행될 필요가 있다.

DB2 V9.5 (Viper II) 부터 root 이외 계정으로 설치가 가능해졌다.

특정 고객사 설치 작업 시, root가 필요한 사유를 작성해야 되는 경우가 있었으니, non root 설치 방식 지원은 업무 진행에 도움이 될 것이다.

비루트 설치의 제약사항은 DB2 설치 시 인스턴스 구성이 된다는 점이다. (1 엔진에 1 인스턴스 구성만 가능)

어떤 의미에서는 엔진과 인스턴스가 붙어있다고 말할 수 있을 것 같다.

설치 후를 비교하면 다음과 같은 차이가 있다.

1. root로 수행되는 프로세스의 소유자

2. fence (루틴 소유자)

   인스턴스 계정과 fence 계정을 동일하게 하는 것은 개발환경에서만 권장하고, 운영시스템에서는 권장하지 않는 것으로 알고 있다.

   non-root 설치의 경우는 fence 계정과 인스턴스 계정이 동일해지는 점을 유의하고, 비루트 설치 시의 차이점을 고객에게 인지시켜야겠다.

3. fixpack 적용 시의 downtime

  비루트 방식의 설치는 엔진과 인스턴스가 동시에 진행되기 때문에 root 설치 방식의 fixpack 작업과는 조금 달라질 수 있다.

  개인적으로 fixpack을 적용하는 경우 사용 중인 엔진과 별도의 경로에 설치 후, 인스턴스를 update 해야 할 때만 운영중인 인스턴스를 중단한다.

  그러나 이런 방식의 fixpack은 비루트 방식에서는 불가능하다. (db2stop 후 fixpack 설치 작업 진행 함)

4. 기타

    root 설치의 경우 사용자 자원 제약(ulimit) 값을 설정하지 않는다, 그러나 비루트 설치의 경우 ulimit 값을 설정해야 한다.

     이외 OS기반 DB2 사용자 인증처리를 하도록 root 권한으로 설정작업이 필요하다.

테스트해 본 바, SVCENAME, SVCEPORT 설정은 되지 않았다.

응답파일을 통한 비루트 설치 시, 인스턴스 DBM CFG의 SVCENAME 값은 포트번호로 설정이 되었다.

테이블 구조가 변경되거나, 정규화가 되어 RI가 존재하는 테이블을 사용하고 주기적으로 LOAD 작업이 발생한다면 SQL0668N 에러 메시지를 받게 될 것이다.

이런 경우는 테이블 상태 체크를 신속히 파악해야 되는데, 관리 뷰(AdminTabInfo)를 통해서 작업이 가능하다.

데이터 컬럼 속성이 변경되거나, 컬럼이 삭제되는 경우 SQL0668N Reason Code 7 에러가 반환된다.

이런 경우 sysibmadm.admintabinfo 뷰를 조회하여 “재구성 보류”(reorg pending) 상태인지 확인이 가능하다.

만일 load 작업이 빈번하게 일어난다면, load 작업이 완료 후 load 대상 테이블들이 “로드 보류” 상태에 놓였는지 확인해 보도록 절차를 만들 필요가 있다.

SQL0668N Reason Code3 은 블로그에 전에 언급을 했지만, 여러 이유 (Dead Lock, Load Temp 공간 부족, 작업 강제 취소 등등) 로 Load 작업이 완료되지 못해서 발생한 것이다.

Load Pending 상태는 Load Query 구문을 통해서도 확인 가능하지만, View를 통해서 테이블 일괄 검사하는 것이 편한 방법일 것이다.

(최근 이 문제로 AdminTabInfo 뷰를 찾으려 했는데 기억나지 않아서 load query 방식으로 고객에게 안내해 준 기억이 난다..)

이외에도 RI(부모-자식 테이블 관계)가 존재하거나 Check 제약조건이 있는 테이블들도 Load 작업 이후 “데이터 무결성” 확인을 하는 것이 좋다. (Integrity Pending에 놓인 테이블의 경우 SELECT 는 가능해서 쉽게 찾아내기 어려울 수 있다.)

(참고로 inoperative 상태는 어떤 경우에 놓이는지 재현해서 확인해 보지 못했다.)