backup copy의 timestamp 조회하기

DB2 LUW 2009. 3. 17. 17:55
DB backup copy를 사용하여 restore를 수행할 경우,
해당 backup copy의 timestamp를 알아내야 한다.

db2 DB의 backup copy가 생성된 timestamp를 확인하는 command는 다음과 같다.

db2 list history backup since YYYYMMDD for ${dbname}

정상적인 경우에는 다음과 같이 timestamp를 확인할 수 있다.

$ db2 list history backup since 20090316 for sample |more
                    List History File for sample
Number of matching file entries = 12
 Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
 -- --- ------------------ ---- --- ------------ ------------ --------------
  B  D  20090316183010001   N    O  S0422805.LOG S0422879.LOG 
 ----------------------------------------------------------------------------
  Contains 276 tablespace(s):
  00001 SYSCATSPACE
  00002 USERSPACE1
              ...

그러나, 간혹 다음과 같이 조회 시 오류가 발생하는 경우가 있다.

$ db2 list history backup since YYYYMMDD for ${dbname}
                    List History File for sample
Number of matching file entries = 12
SQL2155W  Changes have been made to the recovery history file since the open
scan was issued.

이는 내부적으로 history file에 대해 open scan이 발행된 후
이를 종료하기 위한 db2HistoryCloseScan API의 호출이
비정상적이었을 경우 발생하는 오류이다.

이런 경우는
다음 SQL로 timestamp를 조회할 수도 있고,

select  timestamp(start_time) as "Start Time (min)",
          case(operationType)         when 'F'  then 'Offline Full'
                                                 when 'N' then 'Online Full'
                                                 when 'I' then 'Offline Incremental'
                                                 when 'O' then 'Online Incremental'
                                                 when 'D' then 'Offline Delta' 
                                                 when 'E' then 'Online Delta'        
          else '?'       end as Type, 
          SQLCODE
 from TABLE(ADMIN_LIST_HIST()) AS LIST_HISTORY
where  operation = 'B' ;

위의 TABLE(ADMIN_LIST_HIST()) snapshot function을 수행하는 과정에서
history file scan이 초기화 되므로
간단히 ADMIN_LIST_HIST() function을 호출한 후에
본디의 list history backup 명령을 사용해서 조회가 가능해진다.
저작자표시 비영리 변경금지
Posted by in0de
,

Tablespace FSC Option OFF로 DB2 성능 향상

DB2 LUW 2009. 2. 6. 13:46
Tablespace의 File System Caching 기능을 해제하여 DB2 응답 성능을 향상시킬 수 있다.

모든 I/O를 할 때, OS 레벨의 File system caching 기능을 사용하지 않고
DB2의 bufferpool만을 사용하는 개념인데,
모든 상황, 모든 버전에서 효과가 있는 지는 테스트를 해봐야 알 것 같다.

Filesystem caching On 상태

이 상태로 속도는 최초 수행 시 0.83초, 반복 수행 시 0.45초로 나타났다.
정확한 측정을 위해서는 db2batch command를 사용해야하나, 측정 결과는 크게 다르지 않다.

Alter tablespace문의 NO FILE SYSTEM CACHING command option으로 OS level의 cache를 사용하지 않도록 지정한다.
online으로 바로 적용 가능하며, Connection terminate 이후부터 반영된다.

FSC 컬럼을 보면 Filesystem caching이 해제된 것을 확인할 수 있다.

적용 후의 동일 쿼리 수행 결과

OS Caching을 bypass함으로써, 상당한 성능 향상을 볼 수 있다.

단, 다음 환경에서의 테스트에 따르면
OS : AIX 5.3, CPU : 2, Memory : 2GB, DB size : 8GB, Partition : Single, db2_parallelism_io = null
FSC OFF 할 경우 백업 속도가
36MB/sec에서 30MB/sec 정도로 느려질 수 있다는 결과가 있다.
저작자표시 비영리 변경금지
Posted by in0de
,

DB2 process를 OS에서 kill하는 경우의 위험성

DB2 LUW 2008. 12. 30. 18:00
db2의 application을 강제종료 시켜야 하는 경우라면
꼭 application id를 force하여 종료시켜야 하며
OS에서의 pid를 kill하면 db2 전체가 shutdown 된다.

2008-12-30-15.09.05.193737+540 E383578A507        LEVEL: Severe
PID     : 2330652              TID  : 1           PROC : db2wdog 0 0
INSTANCE: db2instance        NODE : 000
FUNCTION: DB2 UDB, oper system services, sqloWatchDogMain, probe:20
MESSAGE : ADM0503C  An unexpected internal processing error has occurred.  ALL
          DB2 PROCESSES ASSOCIATED WITH THIS INSTANCE HAVE BEEN SHUTDOWN.
          Diagnostic information has been recorded.  Contact IBM Support for
          further assistance.

kill 하면 안된다는 사실을 잘 알고 있다 하더라도, 다른 원인으로 kill이 발행될 수 있는 경우가 많다.

예를 들어, db2 v8 LUW에서는
기존에 사용한 적이 있는 DMS Tablespace를 drop한 후
tablespace를 생성했었던 lv (Logical volumn)을 삭제하려고 할 경우,
db2를 restart하기 전까지 lv를 삭제할 수 없는 경우가 있다.
이럴 때, fuser -k 커맨드를 사용하여 file을 사용하는 process를 kill한다거나

Veritas VCS 솔루션에서 filesystem을 unmount하는 경우
강제로 unmount되면서 db2 process가 kill될 수 있다.

db2의 crash recovery로 거의 항상 정상적으로 복구되기는 하지만
production server에서는 매우 유의할 필요가 있다.
저작자표시 비영리 변경금지
Posted by in0de
,

DB2 Production Server에서의 CPU 증설 시 참고

DB2 LUW 2008. 12. 24. 10:07
topas
runqueue가 CPU core당 4 thread가 이상적임(기준치 이상, 이하도 문제없음)
waitqueue가 발생하면 CPU를 증설해야 함




vmstat 1
wait IO가 0인 경우가 이상적임
높은 경우는
disk IO가 많은 경우
full table scan이 발생하는 경우
저작자표시 비영리 변경금지
Posted by in0de
,

SQL이 길어서 수행되지 않는 경우

DB2 LUW 2008. 10. 17. 16:45
SQL0101N The statement is too long or too complex.

복잡한 쿼리가 수행되는 경우이거나,
32bit 환경에서 잘 수행되던 쿼리가 64bit 환경으로 바뀌면서 발생하거나
클라이언트의 버전에 따라서 Statement heap이 모자라다는 오류가 발생할 수 있다.

Statement heap은
동적 SQL의 경우 Precompile시,
정적 Package의 경우 bind시 사용하는 공간인데
32bit 의 경우 2048, 64bit의 경우 4096이 default이며
필요 시 다음과 같이 확장할 수 있다.

db2 update db cfg for ${db} using STMTHEAP NNNN
Posted by in0de
,

db2 instance bit 변경

DB2 LUW 2008. 10. 15. 03:38
처음 db2를 배우면 db2icrt, db2idrop과 함께 기본적으로 나오는 명령어이기는 하지만,
대체 언제 이것을 써먹을 수 있을까 대충 지나쳤던 부분인데, 실제로 적용할 일이 발생했다.

32bit WAS와 bit를 맞춰야 하는데 db2를 64bit로 설치했던 것.
그래서 -w 32 옵션으로 db2iupdt로 해결 가능했다.

db2iupdt -w 32 ${instanceName}
Posted by in0de
,

숫자값을 CHAR() cast하여 substr()했는데 m.nn 형식으로 나올 때

DB2 LUW 2008. 4. 18. 13:32
참 단순한데 가끔 이런 것으로도 곤란한 경우가 있다.

원인은 double 값이 scientific notation으로 출력되는 점이다.

예를 들어
0.0001 = 1.0E-4
314.15 = 3.14E+2

이를 substr(char(${column}),1,3) 한 경우
1.0
3.1
처럼 정수 한 자리의 값들로 나오게 된다.
이런 경우 원하는 결과를 얻으려면 decimal()로 캐스팅해주어야 한다.
Posted by in0de
,

UTIL_IMPACT_PRIORITY

DB2 LUW 2008. 4. 17. 11:20
UTIL_IMPACT_PRIORITY는 DB2의 Utility의 실행 우선 순위를 지정하는 옵션이다.
그러나 DB2 UDB v8.2 현재 Runstats와 Backup에만 적용할 수 있다.

Throttle mode를 사용하려면
DBM CFG의 UTIL_IMPACT_LIM 변수를 100이 아닌 숫자값으로 설정해주어야 한다.
이 환경 변수의 권장치는 10 이하이며, 아마 default로 10이 설정되어 있을 것이다.

UTIL_IMPACT_PRIORITY를 달리 지정하지 않을 경우는 throttle을 조절하지 않고 수행된다.
사실 보통은 이 옵션을 지정하지 않기 때문에, 최대한 빨리 실행중이었다고 보면 되는데,
Online peak time이나, scheduled batch time에 runstats를 실행할 경우에 유용할 수 있다.
또한, HADR 구성에 따라 Online Reorg를 수행하지 못하는 경우에 적용할 수 있을 듯 하다.
$ db2 get dbm cfg | grep UTIL_IMPACT
   Workload impact by throttled utilities(UTIL_IMPACT_LIM) = 10
UTIL_IMPACT_PRIORITY 옵션은 숫자값 1~100을 step 1 단위로 지정해줄 수 있으며
숫자를 쓰지 않고 UTIL_IMPACT_PRIORITY 만 써준 경우는 기본적으로 50 으로 실행된다.
db2 backup db ${dbname} online UTIL_IMPACT_PRIORITY include logs
db2 runstats on table ${schema}.${table} and indexes all UTIL_IMPACT_PRIORITY 20
이미 실행중인 utility의 UTIL_IMPACT_PRIORITY를 변경하기 위해서는
db2 set UTIL_IMPACT_PRIORITY for ${utility_id} TO ${priority}

로 변경할 수 있다.
Posted by in0de
,

문자열 길이 구하기

DB2 LUW 2008. 4. 14. 08:15
db2에서 문자열의 길이를 구하려면 다음과 같이 한다.
VALUES(LENGTH(CHAR(${colname})))
위와 같이 길이를 구하면, 한글 1글자를 2byte로 count하기 때문에
유니코드 string 1글자를 1로 count하기 위해서는 다음과 같이 구한다.
VALUES(LENGTH(VARGRAPHIC(${colname})))
Posted by in0de
,

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
,

티스토리툴바