'backup'에 해당되는 글 3건

  1. 2009.06.06 Backup image size 구하기
  2. 2009.03.17 backup copy의 timestamp 조회하기
  3. 2008.04.17 UTIL_IMPACT_PRIORITY

Backup image size 구하기

DB2 LUW 2009. 6. 6. 13:57
여러 가지 방법이 존재하겠지만,
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
,

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
,

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
,

티스토리툴바