Java application source code sample

DB2 LUW 2008. 4. 14. 07:43
Infocenter에서
"Licensed Materials import java" 로 검색

마찬가지로 C source code sample은
"Licensed Materials include CLI" 로 검색
Posted by in0de
,

TIMESTAMP 출력

DB2 LUW 2008. 4. 13. 11:10
1900-01-01-00.00.00.000000 와 같은 TIMESTAMP 형식의 컬럼을
흔히 사용하는 1900-01-01 00:00:00으로 출력하려면

substr(char(${colname}),1,10) || ' ' ||substr(translate(char(${colname}),':','.'),12
,8)

이렇게 쓰는 것보다는

varchar_format (${colname}, 'YYYY-MM-DD HH24:MI:SS')

이 간단하다.
딱 이 출력포맷으로만 찍을 수 있고, 포맷 스트링의 변형이 허용되지 않는다.
만들려면 좀 쓸모있게 만들어놓지...

export 시에 날짜 출력 포맷을 위와 같이 변경하려면

EXPORT TO ${filepath} OF DEL MODIFIED BY COLDEL;
TIMESTAMPFORMAT=\"dd.mm.yyyy hh:mm\"
select * from foo
TIMESTAMPFORMAT modifier option 참조

오라클보다 시간, 날짜 관련 타입을 세분화해놨지만
어쨌거나 불편하고, 날짜 계산도 엉망이다.
Posted by in0de
,

Application heap size 조정

DB2 LUW 2008. 3. 10. 23:58
증상
Application에서 application heap size error 및 오류 코드 리턴

원인
db2의 application 실행 중 application heap size를 초과하는 경우에는
db2diag.log에도 log가 남지 않으며 application 쪽에서만 error code가 발생함.

해결
instance cfg인 APPLHEAPSZ를 확장하여 해결

db cfg 설정
db2 update db cfg for ${instance} using APPLHEAPSZ ${new_value}

HA Freeze (HADR 환경일 경우)
hagrp -freeze ${SVC_GRP}

모든 application 종료
db2 force application all

인스턴스 중지
db2stop

인스턴스 재기동
db2start

HA unfreeze (HADR 환경일 경우)
hagrp -unfreeze ${SVC_GRP}
Posted by in0de
,

vxresize로 Tablespace size보다 작게 LV 를 resize한 경우

DB2 LUW 2008. 2. 15. 20:39
증상
   
LV를 resize한 후 특정 테이블에 access하면 dump를 발생하며 db가 restart되고
crash recovery를 반복적으로 수행함
"db2start admin mode"에서도 해결할 방도가 없음
해당 table 및 table이 포함된 tablespace를 alter, drop할 수 없음

db2diag.log에 발생하는 로그
2008-02-15-14.51.54.366915+540 E17958A453         LEVEL: Error (OS)
PID     : 6643876              TID  : 1           PROC : db2agent (DBTA) 0
INSTANCE: dbtainst             NODE : 000         DB   : DBTA
APPHDL  : 0-2634               APPID: GAFF6E24.FE3E.0402F4213409
FUNCTION: DB2 UDB, oper system services, sqloReadBlocks, probe:60
CALLED  : OS, -, unspecified_system_function
OSERR   : ENXIO (6) "존재하지 않는 장치나 주소에 대한 요청이 있습니다."
2008-02-15-14.51.54.377898+540 I18412A810         LEVEL: Error
PID     : 6643876              TID  : 1           PROC : db2agent (DBTA) 0
INSTANCE: dbtainst             NODE : 000         DB   : DBTA
APPHDL  : 0-2634               APPID: GAFF6E24.FE3E.0402F4213409
FUNCTION: DB2 UDB, oper system services, sqloReadBlocks, probe:200
MESSAGE : ZRC=0x860F0004=-2045837308=SQLO_DGFL "general failure (DD)"
          DIA8402C A disk error has occurred.
DATA #1 : File handle, PD_TYPE_SQO_FILE_HDL, 8 bytes
0x0FFFFFFFFFFED5C0 : 0000 0031 0000 0000                        ...1....
DATA #2 : unsigned integer, 4 bytes
891841
DATA #3 : unsigned integer, 8 bytes
1
DATA #4 : unsigned integer, 4 bytes
13
DATA #5 : File Offset, 8 bytes
8192
DATA #6 : File Offset, 8 bytes
7305961472
DATA #7 : unsigned integer, 8 bytes
0
2008-02-15-14.51.54.406948+540 I19223A458         LEVEL: Error
PID     : 6643876              TID  : 1           PROC : db2agent (DBTA) 0
INSTANCE: dbtainst             NODE : 000         DB   : DBTA
APPHDL  : 0-2634               APPID: GAFF6E24.FE3E.0402F4213409
FUNCTION: DB2 UDB, buffer pool services, sqlbReadPageFromContainer, probe:20
RETCODE : ZRC=0x860F0004=-2045837308=SQLO_DGFL "general failure (DD)"
          DIA8402C A disk error has occurred.
2008-02-15-14.51.54.420293+540 I19682A476         LEVEL: Error
PID     : 6643876              TID  : 1           PROC : db2agent (DBTA) 0
INSTANCE: dbtainst             NODE : 000         DB   : DBTA
APPHDL  : 0-2634               APPID: GAFF6E24.FE3E.0402F4213409
FUNCTION: DB2 UDB, buffer pool services, sqlbReadPageFromContainer, probe:20
MESSAGE :  Obj={pool:95;obj:108;type:1} State=x27 Parent={19;108}, EM=2389984,
          PP0=2390000 Cont=0 Offset=891841 BlkSize=13
2008-02-15-14.51.54.420993+540 I21321A496         LEVEL: Error
PID     : 6643876              TID  : 1           PROC : db2agent (DBTA) 0
INSTANCE: dbtainst             NODE : 000         DB   : DBTA
APPHDL  : 0-2634               APPID: GAFF6E24.FE3E.0402F4213409
FUNCTION: DB2 UDB, buffer pool services, sqlbrdpg, probe:1110
DATA #1 : String, 140 bytes
 Obj={pool:95;obj:108;type:1} State=x27 Parent={19;108}, EM=2389984, PP0=2390000 Page=2675473 Cont=0 Offset=891841 BlkSize=13
Unexpected EOF
2008-02-15-14.51.54.586485+540 I22536A411         LEVEL: Severe
PID     : 6643876              TID  : 1           PROC : db2agent (DBTA) 0
INSTANCE: dbtainst             NODE : 000         DB   : DBTA
APPHDL  : 0-2634               APPID: GAFF6E24.FE3E.0402F4213409
FUNCTION: DB2 UDB, Query Gateway, sqlqg_signal_handler, probe:10
MESSAGE : DIA0505I Execution of a component signal handling function has begun.
2008-02-15-14.51.54.604024+540 I22948A144         LEVEL: Severe
PID:6643876 TID:1 NODE:000 Title: QG SQLCA
Dump File:/dbta/db2dump/66438761.000

2008-02-15-14.51.54.606961+540 I23093A145         LEVEL: Severe
PID:6643876 TID:1 NODE:000 Title: QG DJDBCB
Dump File:/dbta/db2dump/66438761.000

2008-02-15-14.51.54.607172+540 I23239A144         LEVEL: Severe
PID:6643876 TID:1 NODE:000 Title: QG DJACB
Dump File:/dbta/db2dump/66438761.000

2008-02-15-14.51.54.607373+540 I23384A146         LEVEL: Severe
PID:6643876 TID:1 NODE:000 Title: QG APPDJCB
Dump File:/dbta/db2dump/66438761.000

2008-02-15-14.51.54.607571+540 I23531A147         LEVEL: Severe
PID:6643876 TID:1 NODE:000 Title: QG TRANDJCB
Dump File:/dbta/db2dump/66438761.000
2008-02-15-14.51.54.857356+540 I38845A432         LEVEL: Severe
PID     : 6643876              TID  : 1           PROC : db2agent (DBTA) 0
INSTANCE: dbtainst             NODE : 000         DB   : DBTA
APPHDL  : 0-2634               APPID: GAFF6E24.FE3E.0402F4213409
FUNCTION: DB2 UDB, DRDA Application Server, sqljsSignalHandler, probe:20
MESSAGE : DIA0506I Execution of a component signal handling function is complete.
2008-02-15-14.51.54.866330+540 I41128A460         LEVEL: Event (OS)
PID     : 6643876              TID  : 1           PROC : db2agent (DBTA) 0
INSTANCE: dbtainst             NODE : 000         DB   : DBTA
APPHDL  : 0-2634               APPID: GAFF6E24.FE3E.0402F4213409
FUNCTION: DB2 UDB, trace services, pdInvokeCalloutScript, probe:10
OSERR   : EACCES (13) "파일 액세스 권한이 지정된 조치를 허용하지 않습니다."
MESSAGE : Error invoking pdInvokeCalloutScript

원인

Tablespace보다 작게 LV를 resize했을 경우
마치 quiesce가 걸린 것처럼 데이터는 유실되지 않은 상태로
해당 Tablespace에 접근하려는 시도는 모두 실패하면서
Dump를 생성하고, db가 재기동 되며 crash recovery를 수행함
    
Lv를 줄이는 방법 두 가지
    • vxassist -g $(DGname) [shrinkto|shrinkby] -f $(LVname) $(size)
    • vxresize -g $(DGname) $(LVname) $(size)


처리

문제가 발생한 Tablespace는 db2diag.log에서
Parent 정보를 통해 문제가 발생한 Tablespace와 Table을 알 수 있음
Ex)  Obj={pool:95;obj:108;type:1} State=x27 Parent={19;108}
    Tablespaceid = 19
    Tableid = 108

다시 LV를 원래 사이즈로 복원하면, 놀랍게도 resize 직전의 상태로 원상 복구됨
Posted by in0de
,

RESTART - Load command mode

DB2 LUW 2008. 1. 20. 03:54
Load시 load할 data size를 측정하기는 쉬워도,
index size까지 미리 예측하고 load하기에는 꼼꼼함이 따라주지 않는다.

이런 부주의로 load 하다가 tablespace full 된 경우에는
RESTART INTO option을 사용해
중단된 Load를 다시 시작할 수 있다.

RESTART는 INSERT, REPLACE, TERMINATE와 함께
Load command의 모드 중 하나인데,
바로 이전의 load 에서 중지되었던 consistency point부터 Load를 계속해 나간다.

그런데, index build phase부터 restart하더라도
거의 load phase에서 걸렸던만큼의 시간이 지난 후에 index build를 한다.

in load.sql
LOAD FROM "./data.asc" OF ASC
MODIFIED BY STRIPTBLANKS CODEPAGE=970 RECLEN=71
METHOD L (1 4,5 8) NULL INDICATORS (0,0)
RESTART INTO ${schema}.${table}(col1, col2);
db2 -tvf load.sql

Posted by in0de
,

Compression in DB2 vs. Oracle 11g

DB2 LUW 2007. 12. 27. 10:35
Oracle 10g의 압축방식은 block level에서 이뤄지는데다,
direct path insert같은 load를 할 때만 효력이 있었던 듯 하고...

Oracle에서 block level compress를 하는 과정은
load 시 중복 값을 block에서 발견하면 이를 block header에 기록한 후
실제 데이터는 block header를 pointer로 가리켜놓는 식인데
한 block에 동일한 데이터가 많이 들어갈 수록 압축 효율이 높아지게 된다.

Oracle의 block level compress로 인한 태생적 한계는
  • Table, Range partition에서의 중복값을 compress하지 못함
  • 여러 block에서 반복되는 값이라 하더라도, 각 block header에 dictionary를 만들어야 함
  • column value 단위로 찾으므로, 문자열 일부분을 압축할 수 없음
  • load시에만 작동하고, insert/update시에는 작동하지 않음
11g 들어오면서 돈 내는 옵션으로 insert/update 시에도 압축을 할 수 있는 것 같은데
특정한 값이 block에 반복하여 insert/update 하는 경우에 압축을 하는 것 같다.

DB2에서는 table 또는 partiion based로 dictionary를 만들기 때문에
block level보다 합리적으로 동작하고 압축률이 높아지는데
스토리지를 절약하는 것 이외에도 여러가지 장점
- 버퍼풀에서도 압축된 상태이므로 메모리를 아낀다던가,
 백업 시간이 단축된다던가 하는(TB급 DB를 관리할 때는 이 점이 제일 좋다) - 을 가진다.
Posted by in0de
,

쿼리 문으로 HADR Status

DB2 LUW 2007. 9. 9. 13:50
DB2 v9에서 새로 생긴 SYSIBMADM.SNAPHADR 뷰를 이용해
Primary 와 Standby 설정정보나 hostname, port 번호,
현재 HADR에서의 Primary/Standby 역할, sync 모드, log gap 등을 조회할 수 있다.

HADR Status에 대한 관리 목적의 Catalog Table을 만들어두면 더 좋을 듯.
INSERT INTO DBA.HADR
SELECT
	D.SNAPSHOT_TIMESTAMP, HADR_STATE, HADR_CONNECT_STATUS,
	HADR_PRIMARY_LOG_PAGE, HADR_PRIMARY_LOG_LSN,
	HADR_STANDBY_LOG_PAGE, HADR_STANDBY_LOG_LSN,
	HADR_LOG_GAP,
	APPLS_CUR_CONS
FROM
	SYSIBMADM.SNAPDB D, SYSIBMADM.SNAPHADR H
Posted by in0de
,

티스토리툴바