티스토리 툴바


보통 응답파일은 Unix일경우 cde환경이나 linux일경우 x-window 상태에서 db2setup을 하면
GUI환경에서 설치할때 기본으로 생성이 된다.
하지만 설치가 완료된 이후에도 툴을 이용하면 응답파일(xxxx.rsp)을 추출할 수 있다.

응답파일 생성기
<DB2설치디렉토리>/bin/db2rspgn -d <응답파일을 추출할 디렉토리> -i <인스턴스 이름>

구성 프로필 생성기
<DB2설치디렉토리>/bin/db2cfexp <추출할 디렉토리/추출할 파일명> [template | backup | maintain]

위와 같이 하면 2가지 파일이 생성된다. 응답파일은 db2 엔진을 설치하고 바로 인스턴스까지 생성이 된다.
물론 기본 시스템에서 뽑아낸 계정과 같다는 전제조건 하에서이다.
만약 틀릴시 xxx.rsp파일을 편집하여 설치하려는 시스템에 맞게 고쳐주어야 한다.

응답파일을 이용 DB2설치법
1. 일단 응답파일에 몇가지 수정을 한다.
LIC_AGREEMENT에서 DECLINE을 ACCEPT로 바꾸어 준다.
그외 필요한 수정을 한다.
그리고 실행!
db2setup -u <응답파일 경로명과 파일명>

구성 프로필을 이용한 인스턴스 구성법.
su - db2inst1 -c ". sqllib/db2profile;
       db2cfimp <인스턴스 구성파일 디렉토리/파일명>"

저작자 표시 비영리 변경 금지
Posted by RaiKan RaiKan

db2pdcfg -catch locktimeout count=1  : locktime 및 lockname을 알수 있다.

db2pd -db sample -locks :  locktime 및 lockname을 알수 있다.

db2pd -db sample -applications : app가 실행하는 동적 sql문의 결과나 진행상태를 볼수 있다.

db2pd -memblock  : 메모리 사용률을 알 수 있다.

db2pd -tcbstats : tcb table(시스템관련 테이블) 상태 확인

db2pd -db sample -tablespaces : 테이블스페이스 상태

db2pd -db sample -agent : agent상태 및 쓰기 상황 보기.

db2pd -db sample -recovery : db 복구 상태 보기.

db2pd -db sample -transactions : 트랜잭션 보기.

db2pd -db sample -logs : log 사용량 보기.

db2pd -db sample -stack all, db2pd -db sample -stack <pid> : 스택 상태 보기.

db2pd -db sample -bufferpools <bpid>: bufferpool 상태보기 <id> : id에 따른 상세보기

db2pd -db sample -apinfo <handleid> : 해당 handle번호 어플 상세보기.


examples(몇개를 조합해서 볼수도 있다. 하지만 정밀하게 보기를 원할경우 옵션은 하나만 지정한다.)

db2pd -dbpartitionnum 0,1 -db sample -locks

db2pd -dbp 0,1 -database sample -locks app=<appid>

db2pd -alldbp -alldbs

저작자 표시 비영리 변경 금지
Posted by RaiKan RaiKan

DB2 레지스트리 및 환경 변수

DB2® 데이터베이스 제품은 시작 및 실행을 위해 알아야 하는 여러 가지 레지스트리 변수 및 환경 변수를 제공합니다.

지원되는 모든 레지스트리 변수 목록을 보려면 다음 명령을 실행하십시오.

db2set -lr

db2start 명령을 실행하기 전에 갱신할 레지스트리 변수에 대한 값을 설정해야 합니다.

다음 표에는 범주별 모든 레지스트리 변수가 나열되어 있습니다.
표 1. 레지스트리 및 환경 변수 요약
변수 범주 레지스트리 또는 환경 변수 이름
일반

DB2ACCOUNT
DB2BIDI
DB2_CAPTURE_LOCKTIMEOUT
DB2CODEPAGE
DB2_COLLECT_TS_REC_INFO
DB2_CONNRETRIES_INTERVAL
DB2CONSOLECP
DB2COUNTRY
DB2DBDFT
DB2DISCOVERYTIME
DB2FFDC
DB2FODC
DB2_FORCE_APP_ON_MAX_LOG
DB2GRAPHICUNICODESERVER
DB2INCLUDE
DB2INSTDEF
DB2INSTOWNER
DB2_LIC_STAT_SIZE
DB2LOCALE
DB2_MAX_CLIENT_CONNRETRIES
DB2_OBJECT_TABLE_ENTRIES
DB2_SYSTEM_MONITOR_SETTINGS
DB2TERRITORY
DB2_VIEW_REOPT_VALUES

시스템 환경

DB2_ALTERNATE_GROUP_LOOKUP
DB2CONNECT_ENABLE_EURO_CODEPAGE
DB2CONNECT_IN_APP_PROCESS
DB2_COPY_NAME
DB2DBMSADDR
DB2_DIAGPATH
DB2DOMAINLIST
DB2ENVLIST
DB2INSTANCE
DB2INSTPROF
DB2LDAPSecurityConfig
DB2LIBPATH
DB2LOGINRESTRICTIONS
DB2NODE
DB2OPTIONS
DB2_PARALLEL_IO
DB2PATH
DB2_PMAP_COMPATIBILITY
DB2PROCESSORS
DB2RCMD_LEGACY_MODE
DB2RESILIENCE
DB2_RESTORE_GRANT_ADMIN_AUTHORITIES
DB2SYSTEM
DB2_UPDDBCFG_SINGLE_DBPARTITION
DB2_USE_PAGE_CONTAINER_TAG
DB2_WORKLOAD

통신

DB2CHECKCLIENTINTERVAL
DB2COMM
DB2FCMCOMM
DB2_FORCE_NLS_CACHE
DB2_PMODEL_SETTINGS
DB2RSHCMD
DB2RSHTIMEOUT
DB2SORCVBUF
DB2SOSNDBUF
DB2TCP_CLIENT_CONTIMEOUT
DB2TCP_CLIENT_KEEPALIVE_TIMEOUT
DB2TCP_CLIENT_RCVTIMEOUT
DB2TCPCONNMGRS

명령행

DB2BQTIME
DB2BQTRY
DB2_CLP_EDITOR
DB2_CLP_HISTSIZE
DB2_CLPPROMPT
DB2IQTIME
DB2RQTIME

파티션된 데이터베이스 환경

DB2CHGPWD_EEE
DB2_FCM_SETTINGS
DB2_FORCE_OFFLINE_ADD_PARTITION
DB2_NUM_FAILOVER_NODES
DB2_PARTITIONEDLOAD_DEFAULT
DB2PORTRANGE

쿼리 컴파일러

DB2_ANTIJOIN
DB2_DEFERRED_PREPARE_SEMANTICS
DB2_INLIST_TO_NLJN
DB2_LIKE_VARCHAR
DB2_MINIMIZE_LISTPREFETCH
DB2_NEW_CORR_SQ_FF
DB2_OPT_MAX_TEMP_SIZE
DB2_REDUCED_OPTIMIZATION
DB2_SELECTIVITY
DB2_SQLROUTINE_PREPOPTS

성능

DB2_ALLOCATION_SIZE
DB2_APM_PERFORMANCE
DB2ASSUMEUPDATE
DB2_ASYNC_IO_MAXFILOP
DB2_AVOID_PREFETCH
DB2BPVARS
DB2CHKPTR
DB2CHKSQLDA
DB2_EVALUNCOMMITTED
DB2_EXTENDED_IO_FEATURES
DB2_EXTENDED_OPTIMIZATION
DB2_HASH_JOIN
DB2_IO_PRIORITY_SETTING
DB2_KEEP_AS_AND_DMS_CONTAINERS_OPEN
DB2_KEEPTABLELOCK
DB2_LARGE_PAGE_MEM
DB2_LOGGER_NON_BUFFERED_IO
DB2MAXFSCRSEARCH
DB2_MAX_INACT_STMTS
DB2_MAX_NON_TABLE_LOCKS
DB2_MDC_ROLLOUT
DB2MEMDISCLAIM
DB2MEMMAXFREE
DB2_MEM_TUNING_RANGE
DB2_MMAP_READ
DB2_MMAP_WRITE
DB2_NO_FORK_CHECK
DB2NTMEMSIZE
DB2NTNOCACHE
DB2NTPRICLASS
DB2NTWORKSET
DB2_OVERRIDE_BPF
DB2_PINNED_BP
DB2PRIORITIES
DB2_RCT_FEATURES
DB2_RESOURCE_POLICY
DB2_SET_MAX_CONTAINER_SIZE
DB2_SKIPDELETED
DB2_SKIPINSERTED
DB2_SMS_TRUNC_TMPTABLE_THRESH
DB2_SORT_AFTER_TQ
DB2_SQLWORKSPACE_CACHE
DB2_SELUDI_COMM_BUFFER
DB2_TRUSTED_BINDIN
DB2_USE_ALTERNATE_PAGE_CLEANING
DB2_USE_FAST_PREALLOCATION
DB2_USE_IOCP

기타

DB2ADMINSERVER
DB2_ATS_ENABLE
DB2AUTH
DB2CLIINIPATH
DB2_COMMIT_ON_EXIT
DB2_COMPATIBILITY_VECTOR
DB2_CREATE_DB_ON_PATH
DB2_DDL_SOFT_INVAL
DB2DEFPREP
DB2_DISABLE_FLUSH_LOG
DB2_DISPATCHER_PEEKTIMEOUT
DB2_DJ_INI
DB2DMNBCKCTLR
DB2_DOCHOST
DB2_DOCPORT
DB2DSDRIVER_CFG_PATH
DB2_ENABLE_AUTOCONFIG_DEFAULT
DB2_ENABLE_LDAP
DB2_EVMON_EVENT_LIST_SIZE
DB2_EVMON_STMT_FILTER
DB2_EXTSECURITY
DB2_FALLBACK
DB2_FMP_COMM_HEAPSZ
DB2_GRP_LOOKUP
DB2_HADR_BUF_SIZE
DB2_HADR_NO_IP_CHECK
DB2_HADR_PEER_WAIT_LIMIT
DB2_HADR_ROS
DB2_HADR_SORCVBUF
DB2_HADR_SOSNDBUF
DB2LDAP_BASEDN
DB2LDAPCACHE
DB2LDAP_CLIENT_PROVIDER
DB2LDAPHOST
DB2LDAP_KEEP_CONNECTION
DB2LDAP_SEARCH_SCOPE
DB2_LOAD_COPY_NO_OVERRIDE
DB2_LIMIT_FENCED_GROUP
DB2LOADREC
DB2LOCK_TO_RB
DB2_MAP_XML_AS_CLOB_FOR_DLC
DB2_MAX_LOB_BLOCK_SIZE
DB2_MEMORY_PROTECT
DB2_MIN_IDLE_RESOURCES
DB2NOEXITLIST
DB2_NCHAR_SUPPORT
DB2_NUM_CKPW_DAEMONS
DB2_OPTSTATS_LOG
DB2REMOTEPREG
DB2_RESOLVE_CALL_CONFLICT
DB2ROUTINE_DEBUG
DB2SATELLITEID
DB2_SERVER_CONTIMEOUT
DB2_SERVER_ENCALG
DB2SORT
DB2_STANDBY_ISO
DB2STMM
DB2_TRUNCATE_REUSESTORAGE
DB2_USE_DB2JCCT2_JROUTINE
DB2_UTIL_MSGPATH
DB2_VENDOR_INI
DB2_XBSA_LIBRARY

저작자 표시 비영리 변경 금지
Posted by RaiKan RaiKan

현재 IBM® DB2® Universal Database™ (DB2 UDB)에서는 최소 25개의 테이블/테이블 공간에 대한 상태정보를 가지고 있다. 이러한 상태정보들은 특정 상황에서, 데이터 액세스를 제어하는데 사용되거나 특정 사용자 액션을 알아내서 데이터베이스의 무결성을 보호하는데 사용된다. 이벤트에서 생긴 결과 대부분이 로드 유틸리티나 백업과 복구 유틸리티 같은 DB2 유틸리티의 작동과 관련이 있다.

이 글에서 각각의 지원 받는 테이블 또는 테이블 공간 상태(표 1참조)를 설명하겠다. 상태의 이름을 클릭하면 자세한 설명을 볼 수 있다. 또한 상태를 정확히 인터프리팅 하고 응답하는 방법을 예제를 통해 설명하겠다. 예제들은 AIX에서 실행되었던 명령어 스크립트에서 가져온 것이다. 이를 복사한 후 실행해야 한다. 유닉스 계열 외 시스템에서 DB2 UDB를 실행한다면 경로 이름이 알맞은 포맷으로 되었는지를 확인하라. 예제 대부분이 DB2 UDB에서 제공하는 SAMPLE 데이터베이스에 있는 테이블에 기반하고 있다. 몇 가지는 SAMPLE 데이터베이스의 일부가 아닌 시나리오도 필요하지만 시작점으로서 SAMPLE 데이터베이스를 사용하도록 한다.

표 2에서는 테이블 공간 상태를, 표 3에서는 현재 지원되는 테이블 상태를 설명하겠다.

표 1. DB2 UDB Version 8.1.4에서 정의된 테이블과 테이블 공간 상태

상태 범위 상태 범위
Backup Pending 테이블 공간 Quiesced Update 테이블 공간
Backup in Progress 테이블 공간 Read Access Only 테이블
Check Pending 테이블 Reorg in Progress 테이블 공간
DMS Rebalance in Progress 테이블 공간 Restore Pending 테이블 공간
Disable Pending 테이블 공간 Restore in Progress 테이블 공간
Drop Pending 테이블 공간 Roll Forward Pending 테이블 공간
Load Pending 테이블 Roll Forward in Progress 테이블 공간
Load in Progress 테이블 공간 또는 테이블 Storage May be Defined 테이블 공간
Normal 테이블 공간 또는 테이블 Storage Must be Defined 테이블 공간
Not Load Restartable 테이블 Table Space Creation in Progress 테이블 공간
Offline and Not Accessible 테이블 공간 Table Space Deletion in Progress 테이블 공간
Quiesced Exclusive 테이블 공간 Unavailable 테이블
Quiesced Share 테이블 공간

테이블 공간 상태

db2tbst 명령어는 16진수의 상태 값을 받아들여 이에 상응하는 테이블 공간 상태(그림 1)를 리턴한다. 예를 들어, db2tbst 0x0008 명령어는 State = Load Pending을 리턴한다. “LIST TABLESPACES “ 명렁어를 수행하면 16진수로 된 상태정보값을 볼 수 있다. ( 그림 2) IBM DB2 Universal Database Command Reference를 참조하면 좀 더 자세한 정보를 얻을 수 있다.


그림 1. db2tbst 명령어는 16진수의 상태 값을 받아 들여 이에 상응하는 테이블 공간 상태를 리턴한다.
Figure 1

외부에 보여지는 테이블 공간의 상태는 개별 상태 값들의 16진수 합으로 구성된다. 테이블 공간의 상태가 Backup PendingLoad in Progress이면 16진수 리턴 값은 0x20020 (0x00020 + 0x20000)이다. 이 경우 db2tbst 0x20020 명령어는 다음을 리턴한다.

State = Backup Pending
      + Load in Progress


그림 2. LIST TABLESPACES 명령어는 연결된 데이터베이스에 있는 테이블 공간의 현재 상태를 결정하는데 사용된다.
Figure 2

표 2. 테이블 공간 상태

상태 16진수 상태 값 설명 예제
Backup Pending 0x20 테 이블 공간은 지정시점(point-in-time) 테이블 공간 롤포워드(rollforward) 연산 후 또는 COPY NO 옵션이 지정된 (복구 가능한 데이터베이스에 대한) 로드 연산 후에 이 상태가 된다. 이 상태가 되면 테이블 공간 (또는 전체 데이터베이스)는 사용되기 전에 백업되어야 한다. 테이블 공간이 백업되지 않으면 그 테이블 공간 안에 있는 테이블들은 쿼리 될 수는 있지만 업데이트는 되지 않는다. 주: 데이터베이스의 복구 모드를 롤포워드로 변경하게 되면 변경한 즉시 백업해야 한다. logretain 데이터베이스 설정 매개변수가 RECOVERY로 설정되거나 userexit 데이터베이스 설정 매개변수가 YES로 설정되면 데이터베이스는 복구 가능하다. 데이터베이스가 백업되기 전까지는 데이터베이스를 활성화 하거나 데이터베이스로 연결할 수 없다. 백업이 완료되면 backup_pending 정보형 데이터베이스 설정 매개변수가 NO로 설정된다. 1. 로드를위한 데이터 파일 staff_data.del 과 내용 11, "Melnyk",20,"Sales",10,70000,15000:
update db cfg for sample using logretain recovery;
backup db sample;
connect to sample;
load from staff_data.del of del messages load.msg insert into staff copy no;
update staff set salary = 69000 where id = 11;
2. update db cfg for sample using logretain recovery;
connect to sample;
Backup in Progress 0x800 이것은 백업 연산 동안에만 유효한 일시적인 상태이다. 온라인 BACKUP DATABASE 명령어를 실행한다.:
backup db sample online;
백업 연산이 실행될 때 또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
1. list tablespaces show detail; or
2. get snapshot for tablespaces on sample;
connect reset;
USERSPACE1에서 리턴된 정보를 통해 이 테이블 공간이 Backup in Progress 상태에 있다는 것을 알 수 있다.
DMS Rebalance in Progress 0x10000000 데 이터 리밸런싱(rebalancing) 연산 동안에만 유효한 일시적 상태이다. 새로운 컨테이너들이 데이터베이스 관리형 공간(DMS)로 정의된 테이블 공간에 추가되거나 기존 컨테이너들이 확장될 때 테이블 공간 데이터의 리밸런싱이 발생한다. 리밸런싱은 데이터가 게속 스트라이핑 되도록 테이블 공간의 Extent 들을 또 다른 위치로 옮기는 작업이다. Extent 는 컨테이너 공간( 페이지로 측정됨 ) 의 단위이고 스트라이프는 테이블 공간 컨테이너 집합의 Extent Layer 이다. 2만개 이상의 레코드를 가진 데이터 파일 sfaffdata.del :
connect to sample;
create tablespace ts1 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/ts1c1' 1024);
create table newstaff like staff in ts1;
load from staffdata.del of del insert into newstaff nonrecoverable;
alter tablespace ts1 add (file '/home/melnyk/melnyk/NODE0000/SQL00001/ts1c2' 1024);
list tablespaces;
connect reset;
TS1에서 리턴된 정보를 통해 이 테이블 공간이 DMS Rebalance in Progress 상태에 있음을 알 수 있다.
Disable Pending 0x200 이 상태는 데이터베이스 롤포워드 연산중에 발생될 수 있으며 롤포워드 연산이 완료될 때는 이 상태에서 벗어난다. 이 상태는 테이블 공간이 오프라인이 되고 Transaction을 위한 로그가 아직 쓰여지지 않은 상황에서 발생될 수 있다. 이 상태는 일시적으로 생겼다가 사라질 수 있으므로 사용자에게는 보여지지 않을 수도 있다. 예제 없음.
Drop Pending 0x8000 데 이터베이스를 재시작할 때 한 개이상의 컨테이너에 문제가 있을 경우 테이블 공간은 이 상태가 된다. ( 이전 세션에서 전원 오류등 비정상적으로 데이터베이스가 종료되었다면 데이터베이스는 재시작 되어야 한다. ) 테이블 공간이 Drop Pending 상태에 있다면 사용은 불가능 하고 삭제만 가능하다. 예제 없음.
Load in Progress 0x20000 COPY NO 옵션을 지정한 (복구 가능한 데이터베이스에 대한) 로드 연산 중에만 유효한 일시적인 상태이다. Load in Progress 테이블 상태를 참조한다. 로드 인풋 파일 staffdata.del과 상당량의 데이터 (약 20000 개 이상의 레코드):
update db cfg for sample using logretain recovery;
backup db sample;
connect to sample;
create table newstaff like staff;
load from staffdata.del of del insert into newstaff copy no;
connect reset;
로드 연산이 실행될 때 또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
list tablespaces;
connect reset;
USERSPACE1에서 리턴된 정보는 이 테이블 공간이 Load in Progress (그리고 Backup Pending) 상태에 있음을 나타내고 있다.
Normal 0x0 테이블 공간은 문제가 없다면 Normal 상태에 놓여진다. Normal 상태는 테이블 공간이 생성된 후의 초기 상태이다. connect to sample;
create tablespace ts1 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/tsc1' 1024);
list tablespaces show detail;
Offline and Not Accessible 0x4000 한 개 이상의 컨테이너에 문제가 있다면 테이블 공간은 이 상태에 머무르게 된다. 컨테이너는 부주의하게 재명명, 이동, 또는 손상을 입었을 것이다. 문제가 해결되면 이 테이블 공간에 속하는 컨테이너에 다시 액세스 할 수 있고, 데이터베이스에 연결된 모든 애플리케이션의 접속을 끊었다 다시 연결하면 이 비정상적인 상태에서 벗어날 수 있다. 또는 SWITCH ONLINE 구문이 지정된 ALTER TABLESPACE 문을 실행하면 Offline and Not Accessible 상태에서 벗어날 수 있다. connect to sample;
create tablespace ts1 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/tsc1' 1024);
alter tablespace ts1 add (file '/home/melnyk/melnyk/NODE0000/SQL00001/tsc2' 1024);
export to st_data.del of del select * from staff;
create table stafftemp like staff in ts1;
import from st_data.del of del insert into stafftemp;
connect reset;
테이블 공간 컨테이너를 tsc1 에서 tsc3 으로 바꾸고 STAFFTEMP 테이블을 쿼리한다.:
connect to sample;
select * from stafftemp;
이 쿼리는 SQL0290N (테이블 공간 액세스는 허용되지 않음)을 리턴하고 LIST TABLESPACES 명령어는 TS1에 대해 상태 값 0x4000 (Offline and Not Accessible)을 리턴한다. 다시 테이블 공간 컨테이너 이름을 tsc3에서 tsc1로 바꾼다. 이번에는 쿼리가 성공적이다.
Quiesced Exclusive 0x4 애 플리케이션이 테이블 공간에 대해 Quiesce 함수를 호출하여 그 테이블 공간에 배타적( 읽기 또는 쓰기) 권한을 가질 때 이 상태가 된다. QUIESCE TABLESPACES FOR TABLE 명령어를 실행하여, 테이블 공간을 Quiesced Exclusive 상태에 둘 수 있다. Quiesced Exclusive로 설정하기 전에 테이블 공간 상태가 Normal로 되어 있는지 확인한다.
connect to sample;
quiesce tablespaces for table staff reset;
quiesce tablespaces for table staff exclusive;
connect reset;
또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
select * from staff where id=60;
update staff set salary=50000 where id=60;
list tablespaces;
connect reset;
USERSPACE1에서 리턴된 정보는 이 테이블 공간이 Quiesced Exclusive 상태에 있다는 것을 말해주고 있다.
Quiesced Share 0x1 Quiesce 함수를 호출하는 애플리케이션과 동시에 접속한 애플리케이션이 읽기 ( 쓰기는 아님) 액세르를 할 때 이 상태가 된다. QUIESCE TABLESPACES FOR TABLE 명령어를 실행하여 Quiesced Share 상태에 테이블 공간을 둘 수 있다. Quiesced Share로 설정하기 전에 테이블 공간 상태가 Normal로 되어 있는지 확인한다.
connect to sample;
quiesce tablespaces for table staff reset;
quiesce tablespaces for table staff share;
connect reset;
또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
select * from staff where id=40;
update staff set salary=50000 where id=40;
list tablespaces;
connect reset;
USERSPACE1에 리턴된 정보는 이 테이블 공간이 Quiesced Share 상태에 있다는 것을 나타내고 있다.
Quiesced Update 0x2 Quiesce 함수를 호출하는 애플리케이션이 테이블 공간에 대해 배타적인 쓰기 액세스를 할 때 이 상태가 된다. QUIESCE TABLESPACES FOR TABLE 명령어를 실행하여 Quiesced Update 상태가 되게 할 수 있다. Quiesced Update로 설정하기 전에 테이블 공간 상태가 Normal로 되어 있는지 확인한다.
connect to sample;
quiesce tablespaces for table staff reset;
quiesce tablespaces for table staff intent to update;
connect reset;
또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
select * from staff where id=50;
update staff set salary=50000 where id=50;
list tablespaces;
connect reset;
USERSPACE1에 리턴된 정보는 이 테이블 상태가 Quiesced Update 상태에 있다는 것을 알려주고 있다.
Reorg in Progress 0x400 reorg 연산 중에만 일어 나는 일시적인 상태이다. REORG TABLE 명령어를 실행한다:
connect to sample;
. reorg table staff;
connect reset;
reorg 연산이 실행될 때, 또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
1. list tablespaces show detail; or
2. get snapshot for tablespaces on sample;
connect reset;
USERSPACE1에 리턴된 정보를 통해 이 테이블 공간이 Reorg in Progress 상태에 있다는 것을 알 수 있다. 주: 테이블 재구성 연산은 매우 짧은 시간 동안 수행된다. 따라서 이 방식을 사용하면 Reorg in Progress 상태를 관찰하기 힘들다.
Restore Pending 0x100 리 다이렉션 된 복구 연산의 첫 번째 부분이 수행된 후에 (SET TABLESPACE CONTAINERS 명령어가 실행되기 전에) 데이터베이스의 테이블 공간은 이 상태가 된다. 테이블 공간(또는 전체 데이터베이스)은 테이블 공간이 사용되기 전에 복구되어야 한다. 복구 연산이 성공적으로 완료될 때까지 데이터베이스에 연결할 수 없다. 복구연산이 성공적으로 완료되면 rollfwd_pending 정보형 데이터베이스 연산 매개변수의 값이 NO 로 설정된다. Storage May be Defined에서 리다이렉션된 복구 연산의 첫 번째 부분이 완료되면 모든 테이블 공간은 Restore Pending 상태가 된다.
Restore in Progress 0x2000 복구 연산 중에만 일어 나는 일시적인 상태이다. update db cfg for sample using logretain recovery;
backup db sample;
backup db sample tablespace (userspace1);
백업 이미지용 타임스탬프: 20040611174124
restore db sample tablespace (userspace1) online taken at 20040611174124;
복구 연산이 실행될 때, 또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
1. list tablespaces show detail; or
2. get snapshot for tablespaces on sample;
connect reset;
USERSPACE1에 리턴된 정보는 이 테이블 공간이 Restore in Progress 상태에 있다는 것을 알려주고 있다.
Roll Forward Pending 0x80 복구 가능한 데이터베이스에 대해 복구 연산이 수행된 후에 테이블 공간은 이 상태에 놓이게 된다. 테이블 공간(또는 전체 데이터베이스)는 테이블 공간이 사용되기 전에 롤포워드 되어야 한다. logretain 데이터베이스 설정 매개변수가 RECOVERY로 설정되거나 userexit 데이터베이스 설정 매개변수가 YES로 설정되면 데이터베이스는 복구 가능하다. 롤포워드 연산이 성공적으로 완료될 때까지는 데이터베이스를 활성화 하거나 데이터베이스에 연결할 수 없다. 롤포워드 연산이 완료되면 rollfwd_pending 정보형 데이터베이스 연산 매개변수의 값이 NO로 설정된다. Restore in Progress에 있는 온라인 테이블 공간 복구 연산이 완료되면 테이블 공간 USERSPACE1은 Roll Forward Pending 상태가 된다.
Roll Forward in Progress 0x40 롤포워드 연산 중에만 일어 나는 일시적인 상태이다. 로드 인풋 파일 staffdata.del과 상당량의 데이터 (for example, 20000 or more records):
update db cfg for sample using logretain recovery;
backup db sample;
connect to sample;
create tablespace ts1 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/ts1c1' 1024);
create table newstaff like staff in ts1;
connect reset;
backup db sample tablespace (ts1) online;
백업 이미지용 타임스탬프: 20040630000715
connect to sample;
load from staffdata.del of del insert into newstaff copy yes to /home/melnyk/backups;
connect reset;
restore db sample tablespace (ts1) online taken at 20040630000715;
rollforward db sample to end of logs and stop tablespace (ts1) online;
롤포워드 연산이 실행될 때, 또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
1. list tablespaces show detail; or
2. get snapshot for tablespaces on sample;
connect reset;
TS1에 리턴된 정보는 이 테이블 공간이 Roll Forward in Progress 상태에 있다는 것을 알려준다.
Storage May be Defined 0x2000000 리다이렉션된 복구 연산의 첫 번째 부분이 수행된 후에(SET TABLESPACE CONTAINERS 명령어가 실행되기 전에) 데이터베이스의 테이블 공간은 이 상태에 놓이게 된다. 원한다면 컨테이너를 재정의 할 수 있다. (Cloning DB2 Databases Using Redirected Restore참조) backup db sample;
백업 이미지용 타임스탬프 20040613204955:
restore db sample taken at 20040613204955 redirect;
list tablespaces;
LIST TABLESPACES 명령어에 의해 리턴된 정보는 모든 테이블 공간이 Storage May be Defined 와 Restore Pending 상태에 있다는 것을 말해주고 있다.
Storage Must be Defined 0x1000 테 이블 공간 컨테이너 설정 단계가 생략되거나, 테이블 공간 컨테이너 설정 단계 동안 지정된 컨테이너를 얻을 수 없다면, 새로운 데이터베이스에 대한 리다이렉션된 복구 연산 동안 테이블 공간은 이 상태에 있다. 후자의 경우 무효 경로 이름이 지정정되었거나 디스크 공간이 부족할 때 발생할 수 있다. backup db sample;
백업 이미지용 타임스탬프 20040613204955:
restore db sample taken at 20040613204955 into mydb redirect;
set tablespace containers for 2 using (path 'ts2c1');
list tablespaces;
LIST TABLESPACES 명령어에 의해 리턴된 정보는 테이블 공간 SYSCATSPACE와 테이블 공간 TEMPSPACE1이 Storage May be DefinedRestore Pending상태에 있다는 것을 말해주고 있다. Storage Must be Defined 상태는 Storage May be Defined 상태 보다 앞선다.
Table Space Creation in Progress 0x40000000 테이블 공간 생성 연산 중에만 일어 나는 일시적인 상태이다. connect to sample;
create tablespace ts1 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/tsc1' 1024);
create tablespace ts2 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/tsc2' 1024);
create tablespace ts3 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/tsc3' 1024);
테이블 공간 생성 연산이 실행될 때, 또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
1. list tablespaces show detail; or
2. get snapshot for tablespaces on sample;
connect reset;
TS1, TS2, TS3에 리턴된 정보는 이 테이블 공간이 Table Space Creation in Progress 상태에 있다는 것을 알려준다.
Table Space Deletion in Progress 0x20000000 테이블 공간 삭제 연산 중에만 일어 나는 일시적인 상태이다. connect to sample;
create tablespace ts1 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/tsc1' 1024);
create tablespace ts2 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/tsc2' 1024);
create tablespace ts3 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/tsc3' 1024);
drop tablespace ts1;
drop tablespace ts2;
drop tablespace ts3;
테이블 공간 삭제 연산이 실행될 때, 또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
1. list tablespaces show detail; or
2. get snapshot for tablespaces on sample;
connect reset;
TS1, TS2, TS3에 리턴된 정보는 이 테이블 공간이 Table Space Deletion in Progress 상태에 있다는 것을 알려준다.

테이블 상태

DB2 UDB Version 8 로드 유틸리티는 테이블 상태(그리고 잠금)를 사용하여 테이블에 액세스 하고 로드 연산 동안 데이터베이스 일관성을 보존한다. 로드 연산이 중지되더라도 테이블 상태는 유지된다. LOAD QUERY 명령어(그림 3)을 사용하여 특정 테이블의 상태를 알아 볼 수 있다. LOAD QUERY 명령어는 로드 연산이 실행중인 동안 로드 연산의 상태를 검사하고 테이블 상태를 리턴한다. 로드 연산이 완료(또는 중지)되면 이 명령어는 오직 테이블 상태만 리턴한다. IBM DB2 Universal Database Command Reference를 참조하면 더 자세한 정보를 얻을 수 있다.


그림 3. LOAD QUERY 명령어는 특정 테이블의 상태를 결정하는데 사용된다.
Figure 3

로드작업 수행전에 종속 테이블 공간이 quiesce 상태가 아닐지라도 테이블 공간 상태가 “Load in Progress” 일 경우 로드 작업중에는 종속 테이블 공간에 대한 백업을 수행할 수 없다. 테이블 공간 상태가 “Load in Progress” 인것과 테이블 상태가 “Load in Progress” 는 다른 상태이다. 로드 작업을 수행할 때 테이블 상태는 “Load in Progress” 가 된다. 하지만 COPY NO 옵션이 지정된 로드 작업은 테이블 공간 상태를 “Load in Progress”로 놓는다.

테이블은 동시에 여러 상태가 될 수 있다. 예를 들어, 데이터가 테이블 체크 제약조건이 정의된 테이블로 로딩되고 ALLOW READ ACCESS 옵션이 지정되면, 테이블은 로드 연산 중에 Check Pending, Load in Progress, Read Access Only 상태에 있게 된다.

표 3. 테이블 상태

상태 설명 예제
Check Pending 테 이블 체크 제약조건이 정의되었지만, 새롭게 정의된 제약조건과 새로운 데이터의 순응성이 아직 입증되지 않았을 경우 테이블은 이 상태가 된다. 예를 들어, DB2 로드 유틸리티가 테이블 체크 제약조건이 정의된 테이블에 대해 로드 연산을 시작할 때 Check Pending 상태를 설정한다. 테이블을 Normal 상태로 리턴하려면 SET INTEGRITY 문을 실행한다. 자세한 내용은 Constraints를 참조하라. 로드 인풋 파일 staff_data.del과 콘텐트: 11,"Melnyk",20,"Sales",10,70000,15000:
connect to sample;
alter table staff add constraint max_salary check (100000 - salary > 0);
load from staff_data.del of del insert into staff;
load query table staff;
LOAD QUERY 명령어에 의해 리턴된 정보는 STAFF 테이블이 Check Pending 상태에 있다는 것을 말해주고 있다.
Load Pending 테이블에 대해 활성화 된 로드 연산이 데이터가 커밋되기 전에 중단되었을 경우 테이블은 이 상태가 된다. 테이블을 Normal 상태로 돌리려면 load terminate, load restart, load replace 연산을 호출한다. 로드 인풋 파일 staffdata.del과 상당량의 데이터 (약 20000 개 이상의 레코드), 로드 연산의 목표 테이블과 NEWSTAFF 라고 하는 새로운 테이블을 포함하고 있는 작은 테이블을 만든다.:
connect to sample;
create tablespace ts1 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/ts1c1' 256);
create table newstaff like staff in ts1;
load from staffdata.del of del insert into newstaff;
load query table newstaff;
load from staffdata.del of del terminate into newstaff;
load query table newstaff;
connect reset;
LOAD QUERY 명령어에 의해 리턴된 정보는 NEWSTAFF 테이블이 Load Pending 상태에 있다는 것을 알려주고 있다. 로드 종료 연산 후에 테이블은 Normal 상태가 된다.
Load in Progress 로드 연산 중에만 유효한 일시적인 상태이다. 로드 연산이 잘못되었거나 인터럽트 될 경우 Load in Progress 상태에서 벗어나는 방법은 IBM DB2 Universal Database Data Movement Utilities Guide and ReferenceLoad in Progress table space state를 참조하라. 로드 인풋 파일 staffdata.del과 상당량의 데이터 (약 20000 개 이상의 레코드):
connect to sample;
create table newstaff like staff;
load from staffdata.del of del insert into newstaff;
로드 연산이 실행될 때, 또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
load query table newstaff;
connect reset;
LOAD QUERY 명령어로 리턴된 정보는 NEWSTAFF 테이블이 Load in Progress 상태에 있다는 것을 나타내고 있다.
Normal 테이블에 어떤 문제도 없다면 Normal 상태가 된다. Normal 상태는 테이블이 생성된 후 첫 상태이다. connect to sample;
create table newstaff like staff;
load query table newstaff;
LOAD QUERY 명령어로 리턴된 정보는 NEWSTAFF 테이블이 Normal 상태에 있다는 것을 나타내고 있다.
Not Load Restartable 롤포워드 작업이 실패한 로드 작업( 로드작업을 성공적으로 재시작하거나 종료하지 않았을 때 )후에 수행되었다면 테이블은 이 상태에 놓여지게 된다. 테이블은 또한 “Load Pending” 상태에도 걸리게 된다. . 테이블을 Normal 상태로 되돌리려면 LOAD TERMINATE 명령어를 실행한다. 로드 인풋 파일 staffdata.del과 상당량의 데이터 (약 20000 개 이상의 레코드):
update db cfg for sample using logretain recovery;
backup db sample;
connect to sample;
create tablespace ts1 managed by database using (file '/home/melnyk/melnyk/NODE0000/SQL00001/ts1c1' 256);
create table newstaff like staff in ts1;
connect reset;
backup db sample;
백업 이미지용 타임스탬프 : 20040629205935
connect to sample;
load from staffdata.del of del insert into newstaff copy yes to /home/melnyk/backups;
connect reset;
restore db sample taken at 20040629205935;
rollforward db sample to end of logs and stop;
connect to sample;
load query table newstaff;
connect reset;
LOAD QUERY 명령어로 리턴된 정보는 NEWSTAFF 테이블이 Not Load Restartable과 Load Pending 상태에 있다는 것을 나타내고 있다.
connect to sample;
load from staffdata.del of del terminate into newstaff copy yes to /home/melnyk/backups;
load query table newstaff;
connect reset;
LOAD QUERY 명령어로 리턴된 정보는 NEWSTAFF 테이블이 이제는 Normal 상태에 있다는 것을 나타내고 있다.
Read Access Only ALLOW READ ACCESS 옵션이 지정되었다면 로드 연산 중에 이 상태가 된다. Read Access Only는 일시적인 상태로서, 다른 애플리케이션과 유틸리티는 로드 연산 전에 존재하는 데이터로 읽기 액세스를 할 수 있다. 로드 인풋 파일 staffdata.del과 상당량의 데이터 (약 20000 개 이상의 레코드):
connect to sample;
export to st_data.del of del select * from staff;
create table newstaff like staff;
import from st_data.del of del insert into newstaff;
load from staffdata.del of del insert into newstaff allow read access;
로드 연산이 실행될 때, 또 다른 세션에서 다음 스크립트를 실행한다.:
connect to sample;
load query table newstaff;
select * from newstaff;
connect reset;
LOAD QUERY 명령어로 리턴된 정보는 NEWSTAFF 테이블이 Read Access Only와 Load in Progress 상태에 있다는 것을 나타내고 있다. 이 쿼리는 STAFF 테이블의 반출된 콘텐트만 리턴한다. 이것은 로드 연산 전에 NEWSTAFF 테이블에 존재했던 데이터이다.
Unavailable 복구 불가능한 로드 연산이 롤포워드 되면 이 상태가 된다. 이와 같은 테이블은 삭제되거나 백업 이미지에서 복구될 수 있다. 로드 인풋 파일 staff_data.del with content: 11,"Melnyk",20,"Sales",10,70000,15000:
update db cfg for sample using logretain recovery;
backup db sample;
백업 이미지용 타임스탬프 : 20040629182012
connect to sample;
load from staff_data.del of del insert into staff nonrecoverable;
connect reset;
restore db sample taken at 20040629182012;
rollforward db sample to end of logs and stop;
connect to sample;
load query table staff;
connect reset;
LOAD QUERY 명령어로 리턴된 정보는 STAFF 테이블이 Unavailable 상태에 있다는 것을 나타내고 있다.

요약

DB2 UDB에서 사용되는 테이블과 테이블 공간 상태는 데이터로의 액세스를 제어하거나 특정 상황 속에서 데이터베이스의 무결성을 보호하는데 사용된다. 이 글에서는 예제를 통해서, 특정 상태를 야기시키는 공통적인 조건들, 어떤 상태가 문제인지를 규명할 때 사용할 수 있는 명령어들, 대응 방법 등을 설명했다. 위에 제시한 예제들을 직접 사용해 보는 것도 좋다. 여러 가지 상태에 대한 자신만의 해결책을 찾아낼 수 있고 데이터베이스 작동에 대한 이해도 높아질 것이다.

기사의 원문보기


참고자료

저작자 표시 비영리 변경 금지
Posted by RaiKan RaiKan
- 첫번째방법.
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.sql.rtn.doc/doc/r0052897.html
SELECT TABSCHEMA, TABNAME, SUM(DATA_OBJECT_P_SIZE),
SUM(INDEX_OBJECT_P_SIZE), SUM(LONG_OBJECT_P_SIZE),
SUM(LOB_OBJECT_P_SIZE), SUM(XML_OBJECT_P_SIZE)
FROM SYSIBMADM.ADMINTABINFO GROUP BY TABSCHEMA, TABNAME
단점이 하나 있는데....
WHERE 조건에 필터링을 사용하더라도 내부적으로는 전체 CATALOG를 뒤져서 결과를 가져온 후
필터링 조건을 적용하여 해당 결과만 표시하는 듯함.
따라서 오브젝트가 많을 경우 시간도 오래걸리고
또한 수행 도중 오브젝트에 LOCK 이 걸려 있으면 LOCKTIMEOUT이 발생하게 되서 튕겨져 나오기도 함.

- 2번째방법
통계정보가 주기적으로 수행이 된다면
SYSCAT.TABLES의 FPAGES 와 SYSCAT.INDEXES 의 NLEAFS 에다
해당 테이블스페이스의 페이지 사이즈를 곱하면 대략적인 크기를 알 수 있음.
(이건 통계정보가 최신일수록 정확함)

- 3번째방법
db2pd -d <database_alias> - tcbstats
이건 통계정보와는 상관없이 해당 테이블이 액세스 되었다면
메모리에 해당 테이블에 대한 정보가 올라오게 됨.
(액세스 되지 않았다면 메모리에 올라오지 않아 보이지 않기 때문에
간단히 몇건만 SELECT 하셔도 메모리에 올라옴.)
여기에는 액세스 내역과 크기 정보가 있다.
데이터는 DataSize 항목을 인덱스의 경우는 IndexObjSize 항목을 참조.
이 또한 페이지 사이즈 임.
유의할 점은 인덱스의 경우 개별 인덱스의 크기가 아닌 해당 테이블 인덱스의 전체 크기임.
저작자 표시 비영리 변경 금지
Posted by RaiKan RaiKan