아무 옵션 없이 data를 export 받으면 기본값으로 ","(comma) 문자가 사용된다.

db2 "export to data.del of del select * from table"
1,"foo","100"
2,"bar","90"
3,"baz","95"


column delimiter를 comma가 아닌 tab으로 export하려면
다음과 같이 수행하면 된다.

db2 "expor to data.del of del modified by coldel0X09 select * from table"
1        "foo"       "100"
2        "bar"       "90"
3        "baz"      "95"


Posted by in0de
,
Archive log가 얼마나 발생하는 지에 따라서 archiving 정책을 정하는 것은
안정적인 운영을 위해 당연한 것이다.

다음의 스크립트를 사용하여
  • 일별 Archive log의 발생량, 또는
  • 일 평균 Archive log 발생량, 일 최대 Archive log 발생량
을 확인할 수 있다.

#// 변수 초기화
export db=${DBNAME}
diagPath=$(db2 get dbm cfg|grep DIAGPATH)
export diagPath=${diagPath#*=}
logfileSZ=$(db2 get db cfg for $db |grep LOGFILSIZ)
export logfileSZ=${logfileSZ#*=}

#// 아카이브 로그 발생량 측정
find $diagPath -name "db2diag.log*" -type f | xargs egrep -p 'Completed archive|Successfully archived' | grep 'LEVEL: Warning' | cut -c 1-10 |
nawk '{occur[$1]++} END {for (dateItem in occur) print dateItem, occur[dateItem] * 4 * '"$logfileSZ"' / 1024}' | sort -n |
nawk '{sum=sum+$2;if ($2>max){max=$2}} END {print "SUM="sum/1024" GB\n""AVG="sum/NR" MB\n""MAX="max" MB"}'

측정하고자 하는 DB의 alias를 ${DBNAME} 부분에 써넣어 환경 설정을 한 후
파란 부분까지 수행하면 일별 Archive log 발생량을,
보라색 부분까지 수행하면 일 평균, 일 최대 Archive log 발생량을 알 수 있다.

dbm cfg에 명시된 DIAGPATH에 존재하는
모든 db2diag.log에 대해서 찾는 스크립트 이므로 (db2diag -A 로 분할된 파일도 모두 포함)
db2diag.log를 삭제한 적이 있거나 다른 곳으로 옮겨두었다면
데이터가 정확하지 않을 수 있다.

ksh88, DB2 v8.2 ~ DB2 v9.5에서 테스트 되었고,
Solaris ksh는 ksh88과 호환되지 않으므로 실행되지 않는다.
또한 DB2 v.8.x의 경우 Circular mode에서 Archived 메시지를 남기지 않으므로
이런 경우에는 집계가 불가능하다.

참고로, DB2 v8.2에서는 Archive 시 "Successfully archived log file" 이 발생하고
DB2 v9.5에서는 Archive시 "Completed archive for log file" 이 발생한다.
Posted by in0de
,
임시 서버에 DB2를 설치하여 개발, 테스트를 진행하다가
운영 서버로 migrate하는 것이 아니라,
곧바로 임시 서버의 hostname을 변경하여 운영하게 되는 경우가 있다.

이런 경우 DB2 DBA 관점에서 변경해줄 내용은
db2nodes.cfg의 hostname만 변경해주면 되는데

IBM 레퍼런스에 따르면
다음과 같은 절차로 진행하면 된다고 한다.
3번 절차는 수행할 필요가 있는지는 의문이다.

  1. db2stop
  2. hostname 변경
  3. db2set -g DB2SYSTEM=<new hostname>
  4. ${DB2HOME}/sqllib/db2nodes.cfg의 <hostname>을 <new hostname>로 변경
  5. db2start

DB2에 GUI client로 붙어서 사용할 수 있는 DAS server를 띄워놓은 경우라면
추가적으로 다음을 수행할 필요도 있을 수 있겠으나,
DAS를 사용하지 않는 것이 일반적인 환경이니, 참고만 하면 되겠다.
  1. db2 admin stop
  2. db2 uncatalog node <old_hostname>
  3. db2 catalog admin tcpip node <new hostname> remote <new hostname> system <new hostname>
  4. db2 update admin cfg using DB2SYSTEM <new hostname>
  5. db2 update admin cfg using SMTP_SERVER <new hostname>
  6. db2admin start
  7. Remove the entry from Control Center for the server with old hostname and then execute a server's discover with the new hostname

Posted by in0de
,
다음과 같은 오류가 발생하는 경우가 과연 있을 지 모르겠지만
CLP에서 아래 오류 메시지가 발생하고,
DB21015E  The Command Line Processor backend process request queue or input
queue was not created within the timeout period.

db2diag.log에 다음과 같은 패턴이 보인다면
2009-06-02-11.08.57.099023+540 I521662072A395     LEVEL: Error
PID     : 5398782              TID  : 1           PROC : db2
INSTANCE: sample                             NODE : 000
EDUID   : 1
FUNCTION: DB2 UDB, command line process, clp_start_bp, probe:3
MESSAGE : CLP frontend unable to get REQUEST queue handle
DATA #1 : Hexdump, 4 bytes
0x0FFFFFFFFFFFD448 : 870F 0042                                  ...B

살펴볼 여러 상황 중 하나로, /dev/null 파일의 권한을 체크해볼 수 있다.

원래, /dev/null의 권한은 다음과 같은데
crw-rw-rw-   1 root     system        2,  2  1월  1일 00:00 /dev/null
원인을 알 수 없는 경우에 의하여 write 권한이 제거된 경우,
위와 같은 오류가 발생할 수 있다.
Posted by in0de
,
// 설치 전 필요사항 체크 루틴
INODE:/sw/db2/FixPak # ./db2prereqcheck

// FixPak 4 를 tar 해제한 후 db2_install 실행
INODE:/sw/db2/FixPak # ./db2_install
 
Default directory for installation of products - /opt/IBM/db2/V9.5
***********************************************************
Do you want to choose a different directory to install [yes/no] ?
yes
Enter full path name for the install directory -
------------------------------------------------
/sw/db2/V9.5.0.4
 
 
Specify one of the following keywords to install DB2 products.
  ESE
  CONSV
  WSE
  CLIENT
  RTCL
 
Enter "help" to redisplay product names.
Enter "quit" to exit.
***********************************************************
ESE
DB2 installation is being initialized.

 Total number of tasks to be performed: 44
Total estimated time for all tasks to be performed: 2092

Task #1 start
Description: Enabling Asynchronous I/O
Estimated time 2 second(s)
Task #1 end

Task #2 start
Description: Checking license agreement acceptance
Estimated time 1 second(s)
Task #2 end

...중간생략...

Task #43 start
Description: Initializing instance list
Estimated time 5 second(s)
Task #43 end

Task #44 start
Description: Updating global profile registry
Estimated time 3 second(s)
Task #44 end

A minor error occurred while installing "DB2 Enterprise Server Edition " on
this computer. Some features may not function correctly.

For more information see the DB2 installation log at
"/tmp/db2_install.log.835722".

// minor error의 내용은 다음과 같음
// SA MP는 현 시스템에서는 사용하지 않는 모듈로, 무시해도 됨
Space required:                            1271 MB
Install SA MP Base Component:              No


DBI1130E  The SA MP Base Component could not be installed or updated
      because system prerequisites were not met. See the log file
      /tmp/prereqSAM.log.876590 for details.

Explanation:

There are system prerequisites for installing or updating the IBM Tivoli
System Automation for Multiplatforms Base Component (SA MP Base
Component). These prerequisites have not been met.

The mentioned log file has the details for the unsatisfied
prerequisites.

To find out more about the system prerequisites for the SA MP Base
Component, see the Installation and Configuration Guide at
http://publib.boulder.ibm.com/tividd/td/IBMTivoliSystemAutomationforMultiplatforms2.2.html.

The SA MP Base Component cannot be installed or updated.

User response:

Modify your system to meet the prerequisites; and use the installSAM
utility to manually install the SA MP Base Component.





INODE:/sw/db2/V9.5.0.4/instance # ./db2iupdt -u testfenc testinst
DBI1070I  Program db2iupdt completed successfully.

// 여기까지는 root 유저로 진행,
// 여기서부터는 instance 유저로 진행
INODE:/sw/db2/V9.5.0.4/instance # su - testinst



// FixPak 설치 후 라이선스가 초기화 되기 때문에 다시 업데이트 해주어야 함
INODE:/sw/db2/license $ db2licm -l
Product name:                     "DB2 Enterprise Server Edition"
License type:                     "Trial"
Expiry date:                      "09/06/2009"
Product identifier:               "db2ese"
Version information:              "9.5"

Product name:                     "DB2 Connect Server"
License type:                     "Trial"
Expiry date:                      "09/06/2009"
Product identifier:               "db2consv"
Version information:              "9.5"



INODE:/sw/db2/license $ db2licm -a db2ese_c.lic

LIC1402I  License added successfully.
LIC1426I  This product is now licensed for use as outlined in your License Agreement.  USE OF THE PRODUCT CONSTITUTES ACCEPTANCE OF THE TERMS OF THE IBM LICENSE AGREEMENT, LOCATED IN THE FOLLOWING DIRECTORY: "/sw/db2/V9.5.0.4/license/ko_KR.eucKR"

INODE:/sw/db2/license $ db2licm -a db2so.lic

LIC1402I  License added successfully.
LIC1426I  This product is now licensed for use as outlined in your License Agreement.  USE OF THE PRODUCT CONSTITUTES ACCEPTANCE OF THE TERMS OF THE IBM LICENSE AGREEMENT, LOCATED IN THE FOLLOWING DIRECTORY: "/sw/db2/V9.5.0.4/license/ko_KR.eucKR"


// 라이선스 업데이트 완료
INODE:/sw/db2/license $ db2licm -l
Product name:                     "DB2 Enterprise Server Edition"
License type:                     "CPU Option"
Expiry date:                      "Permanent"
Product identifier:               "db2ese"
Version information:              "9.5"
Enforcement policy:               "Soft Stop"
Features:
DB2 Database Partitioning:        "Not licensed"
DB2 Performance Optimization ESE: "Not licensed"
DB2 Storage Optimization:         "Licensed"
DB2 Advanced Access Control:      "Not licensed"
DB2 Geodetic Data Management:     "Not licensed"
IBM Homogeneous Replication ESE:  "Not licensed"

Product name:                     "DB2 Connect Server"
License type:                     "Trial"
Expiry date:                      "09/06/2009"
Product identifier:               "db2consv"
Version information:              "9.5"




// CLI, 원격 DB 유틸리티, 시스템 스키마에 대해서 다시 바인드 수행
INODE:/db2/testinst # db2 "bind ./sqllib/bnd/@db2cli.lst blocking all grant public sql error continue"
INODE:/db2/testinst # db2 "bind ./sqllib/bnd/@db2ubind.lst blocking all grant public sql error continue"
INODE:/db2/testinst # db2 "bind ./sqllib/bnd/db2schema.bnd blocking all grant public sql error continue"

// DB를 재기동하면 FixPak 적용이 완료됨
INODE:/db2/testinst # db2stop force
INODE:/db2/testinst # db2start

INODE:/db2/testinst # db2level
DB21085I  Instance "testinst" uses "64" bits and DB2 code release "SQL09054"
with level identifier "06050107".
Informational tokens are "DB2 v9.5.0.4", "s090429", "U825478", and Fix Pack "4".
Product is installed at "/sw/db2/V9.5.0.4".


Posted by in0de
,
여러 가지 방법이 존재하겠지만,
db2diag.log에서 Backup Complete 메시지와 함께 정확한 사이즈가 찍혀있다.

2009-05-15-22.46.53.108696+540 I790856A473        LEVEL: Warning
PID     : 1991526              TID  : 1           PROC : db2agent (SAMPLE) 0
INSTANCE: instance             NODE : 000         DB   : SAMPLE
APPHDL  : 0-1823               APPID: *LOCAL.dbpainst.090515090122
FUNCTION: DB2 UDB, database utilities, sqlubcka, probe:128
MESSAGE : Estimated size of backup in bytes:
DATA #1 : Hexdump, 8 bytes
0x0FFFFFFFFFFEDB78 : 0000 09DD 446C 9000                        ....Dl..

2009-05-15-22.46.53.110938+540 I791330A470        LEVEL: Warning
PID     : 1991526              TID  : 1           PROC : db2agent (SAMPLE) 0
INSTANCE: instance             NODE : 000         DB   : SAMPLE
APPHDL  : 0-1823               APPID: *LOCAL.dbpainst.090515090122
FUNCTION: DB2 UDB, database utilities, sqlubcka, probe:128
MESSAGE : Actual size of backup in bytes:
DATA #1 : Hexdump, 8 bytes
0x0FFFFFFFFFFEDB80 : 0000 09DD D4D4 7000                        ......p.

2009-05-15-22.46.53.111391+540 I791801A355        LEVEL: Warning
PID     : 1991526              TID  : 1           PROC : db2agent (SAMPLE) 0
INSTANCE: instance             NODE : 000         DB   : SAMPLE
APPHDL  : 0-1823               APPID: *LOCAL.dbpainst.090515090122
FUNCTION: DB2 UDB, database utilities, sqlubcka, probe:130
MESSAGE : Backup Complete.

위의 예시에서 16진수 0000 09DD D4D4 7000 를 10진수로 변환하면
Backup image의 byte는 10,848,363,114,496 임을 알 수 있다.
Posted by in0de
,

sqllib/tmp

DB2 LUW 2009. 4. 16. 16:38

${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 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
Posted by in0de
,

db2diag.log 분할하기

DB2 LUW 2009. 4. 16. 14:50
db2diag.log는 db에 문제가 생겼을 때 참조할 수 있는
가장 확실하고 가장 먼저 살펴볼 제 1의 레퍼런스이다.

db2diag.log는
active log, archive log, loadcopy, dump, tablespaces 와 함께
용량관리를 해주어야 하는 대상이 되는데

db2diag 커맨드는 db2diag.log를 분석하는 포매팅 툴로서,
제공하는 기능들 중에서 -A 옵션으로, db2diag.log를 분할하여 archive 할 수 있다.

in root's crontab
59 23 * * * su - ${instance user} -c "db2diag -A ${diagpath}/db2diag.log" > /dev/null 2>&1

매일 오후 23시 59분에 db2diag.log를 db2diag.log_YYYY-MM-DD-HH.MM.SS 형태로
하루에 하나씩 db2diag.log를 새로 생성하도록 해두면
로그를 검색하기도 쉽고 오래된 로그를 백업해두거나 삭제하는 정책을 만들기도 좋다.
Posted by in0de
,
DB2 v9.x 에서는 column을 drop할 수 있는 등의
DB2 v8.x보다 더 유연한 기능을 제공하기 시작했는데

다음과 같은 명령들을 수행하면 해당 Table은 Reorg Pending 상태가 되며
이렇게 Reorg Pending state에 빠지게 만드는 명령을 REORG-recommended operations 라고 한다.

ALTER TABLE foo DROP COLUMN C1
ALTER TABLE bar ALTER COLUMN C1 SET DATA TYPE BIGINT

하지만 테이블의 스키마를 변경하는 경우라고 하더라도
다음의 경우에는 수행 후에도 Reorg Pending에 빠지지 않는다.

ALTER TABLE bar ALTER COLUMN C1 SET NOT NULL
ADD COLUMN
ALTER COLUMN DEFAULT VALUE
RENAME TABLE
ALTER COLUMN SET DATA TYPE VARCHAR/VARGRAPHIC/CLOB/BLOB/DBCLOB


Reorg Pending이 걸리면, 다음 command만을 수행할 수 있는 상태가 되는데

REORG TABLE
DROP TABLE
ALTER TABLE
RENAME TABLE
TRUNCATE TABLE

이렇게 Reorg Pending이 걸린 상태를 확인하려면,
DB2 v9 부터 제공하기 시작한 Snapshot function 또는 Admin view를 조회하면 된다.

db2 "select TABSCHEMA, TABNAME from SYSIBMADM.ADMINTABINFO where REORG_PENDING = 'Y'"


이렇게 Reorg Pending 상태의 테이블에
INPLACE START 를 명시하여 온라인 리오그를 수행하려 하면
SQL0668N + reason code 7 이 발생하게 되고
7        The table is in the reorg pending state. This can occur after
         an ALTER TABLE statement containing a REORG-recommended
         operation.

         Reorganize the table using the REORG TABLE command (note that
         INPLACE REORG TABLE is not allowed for a table that is in the
         reorg pending state).

이런 경우에는
반드시 Offline Reorg(a.k.a Classic Reorg)를 수행해서 해결해야 한다.
Posted by in0de
,

LOB data size 구하기

DB2 LUW 2009. 3. 31. 17:53
CLOB이나 BLOB등의 binary data가 DB를 얼마나 사용하고 있는 지 확인하려면
EXPORT LOBS IN ... LOBFILE ... MODIFIED BY LOBSINFILE 명령으로 export하여
받은 파일의 크기로 확인하는 방법도 있겠지만

가장 좋은 방법으로는
다음의 snapshot function을 통해
테이블 lob field의 페이지 개수를 알아낼 수 있다.

db2 "select tabname, lob_object_pages from table (snap_get_tab('SAMPLE',-1)) as tab"

단, function 실행 시 예기치 못한 DB shutdown이 발생하는 경우가 아주 드물게 있었으므로
운영 환경에서는 실행 시 유의할 필요가 있다.
Posted by in0de
,