${instance home}/sqllib/tmp는 다음의 유틸리티/어플리케이션/툴 들에 의해 I/O가 발생한다.
DB2 Engine
db2 Utilities(Backup, load, import 등)
DB2 Governor
DB2 Snapshot functions
DB2 GUI tools / DB2 Wizards
(ie. Server profile generated from the Control Center, Redistribution Data wizard)
DB2 Extenders (ie. Text Information Extender)
any application (ie. WebSphere)
Linux의 경우, sqllib/tmp 에 named pipe를 생성하여
frontend(db2), backend(db2bp) 프로세스 간의 통신을 하기도 한다.
db2 Utilities(Backup, load, import 등)
DB2 Governor
DB2 Snapshot functions
DB2 GUI tools / DB2 Wizards
(ie. Server profile generated from the Control Center, Redistribution Data wizard)
DB2 Extenders (ie. Text Information Extender)
any application (ie. WebSphere)
Linux의 경우, sqllib/tmp 에 named pipe를 생성하여
frontend(db2), backend(db2bp) 프로세스 간의 통신을 하기도 한다.
DB2 Engine에서의 temporary processing의 세부내용은 알 수 없겠지만
대부분의 경우는 index key sorting 이라던가
여러 utility나 application들에 의해 I/O가 발생된다고 보면 되겠다.
엔터프라이즈 시스템에서의 sqllib/tmp의 위치는 신경써서 정해야할 듯 한데
실제로 이 디렉토리를 모니터링해보면 상당히 자주, 많이 access하고있고
파일시스템에 문제가 있거나
(ie. 시만텍의 매우 오래된 VxFS 4.0.3.2 (4.0 MP3RP2)의
비효율적인 dirty page scan 알고리즘으로 인해 disk I/O의 30%를 일으켰던 경우)
좋지 못한 성능의 Internal disk에 instance home을 둔다거나 한다면
전체적으로 DB의 성능을 떨어뜨릴 수 있기 때문이다.
instance home 디렉토리는 디스크 장애에 의해서 inaccessible할 경우
DB에 대해서 어떠한 제어도 할 수 없게 되므로, 안정적인 디스크에 두어야 하며
안정적인 디스크에 instance home을 두었으나 속도가 좋지 못해,
sqllib/tmp로 인한 성능 저하가 우려되는 경우
DB 자체적으로 sqllib/tmp의 위치를 hidden parameter등으로 변경할 방법은 존재하지 않으며
다음과 같은 방법으로 성능 좋은 디스크 쪽의 디렉토리를 링크하여
안정성과 성능을 둘 다 만족시킬 수 있다.
mkdir ${better perf disk path}/newTmpPath
rm -rf ${instance home}/sqllib/tmp
ln -s ${better perf disk path}/newTmpPath ${instance home}/sqllib/tmp
rm -rf ${instance home}/sqllib/tmp
ln -s ${better perf disk path}/newTmpPath ${instance home}/sqllib/tmp
