Happy Virus(^-^)

드라마 프레지던트 명대사

RaiKan RaiKan — Mon, 02 Apr 2012 10:37:18 +0900

대통령은 투표하는 국민들이 만드는겁니다.

정치인들은 표를 먹고 삽니다.
세상에 어느 정치인이 표도 주지 않는 사람을 위해 발로 뜁니까

다들 말은 번지르르하게 해 댑니다.
여러분들도 귀가 닳도록 들었죠
청년실업해소, 청년 일자리 몇십만개 창출
그러나 실제로는 어떻습니까??
왜그럴까요??

여러분들이 정치를 혐오하기 때문입니다
투표안하는 것을 부끄러워하지 않기 때문입니다!!

못배우고 나이든 어르신들이 지팡이 집고,
버스타고 읍내에 나와 소중한 한표를 행사할 때에,
지성인을 자처하는 여러분들은 애인 팔장끼고,
산으로 강으로 놀러가지 않았습니까!!

영어사전은 종이채 찢어 먹으면서,
기껏해야 8쪽도 안되는않는 손바닥만한 선거공보에는
눈길조차 주지 않았습니다
제말 틀렸습니까?

권리 위에 잠자는 사람은 보호받지 못합니다.
투표를 하지 않는 계층은결코 보호받지 못합니다.

투표합시다!

난 개날당 싫다. 좃나게 싫다. 그렇다고 민주당이나 야당통합 좋아하는건 아니다.

답답해서 니들도 못보겠다.

하지만 최악을 피하고자 차악을 선택하겠다. 잘좀해봐.

잘좀해봐!!! x발!

[DB2] 응답파일 및 구성프로필 생성기를 이용한 DB2 설치

RaiKan RaiKan — Wed, 16 Nov 2011 14:06:28 +0900

보통 응답파일은 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 <인스턴스 구성파일 디렉토리/파일명>"

[TIP] IT 각종 로고

RaiKan RaiKan — Tue, 15 Nov 2011 17:39:10 +0900

무료로 된것들만 모아놓은 사이트
http://www.allfreelogo.com/

[DB2] DB2PD를 이용한 모니터링

RaiKan RaiKan — Mon, 14 Nov 2011 11:19:17 +0900

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

[DB2] 레지스트리 및 환경 변수

RaiKan RaiKan — Tue, 08 Nov 2011 11:05:41 +0900

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

[DB2] Tablespace와 그 상태 분석하기

RaiKan RaiKan — Fri, 04 Nov 2011 14:41:28 +0900

현재 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진수의 상태 값을 받아 들여 이에 상응하는 테이블 공간 상태를 리턴한다.

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

State = Backup Pending
      + Load in Progress

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

표 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 Defined와 Restore 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 명령어는 특정 테이블의 상태를 결정하는데 사용된다.

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

기사의 원문보기

DB2 Basics: Demystifying table and table space states

참고자료

[DB2] Table Size 알아내기

RaiKan RaiKan — Wed, 12 Oct 2011 17:00:55 +0900

- 첫번째방법.
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 항목을 참조.
이 또한 페이지 사이즈 임.
유의할 점은 인덱스의 경우 개별 인덱스의 크기가 아닌 해당 테이블 인덱스의 전체 크기임.

[DB2] Recursive SQL(With문을 이용한)

RaiKan RaiKan — Thu, 06 Oct 2011 15:37:36 +0900

Recursive SQL(With문을 이용한)
보통 계층적인 구조를 만들때 사용한다.

Oracle의 Connect by절은 DB2에서는 없다.
그래서 With절을 이용해서 만들어야 한다.
다음 사이트를 참고한다.

http://www.ibm.com/developerworks/data/library/techarticle/dm-0510rielau/
DB2 9.5 SQL CookBook에도 나와있다.(18page 맨아래 예제, 307page)

예제 1. (LEVEL 숫자 포함)
Oracle
SELECT LEVEL, name
FROM emp
START WITH name = 'Goyal'
CONNECT BY PRIOR empid = mgrid

DB2
WITH n(level, empid, name) AS
          (SELECT 1, empid, name
             FROM emp
             WHERE name = 'Goyal'
           UNION ALL
           SELECT n.level + 1, nplus1.empid, nplus1.name
             FROM emp as nplus1, n
             WHERE n.empid = nplus1.mgrid)
SELECT level, name FROM n;

LEVEL      NAME
----------- ----------
          1 Goyal
          2 Zander
          2 Henry
          2 Scott
          3 McKeough
          3 Barnes
          3 O'Neil
          3 Smith
          3 Shoeman

9 record(s) selected

예제 2.
Oracle
SELECT
    TO_CHAR(TO_DATE('201106','YYYYMM') + LEVEL-1, 'YYYYMMDD') AS DT,
    TO_CHAR(TO_DATE('201106','YYYYMM') + LEVEL-1, 'DAY') AS WEEK
FROM DUAL
CONNECT BY LEVEL <= TRUNC(TO_DATE('201106','YYYYMM')+32,'MM') - to_date('201106','YYYYMM')

DB2
WITH DateRange(dt) AS
(
SELECT date('2011-06-01') AS dt FROM dual
UNION ALL
SELECT (date(dt) + 1 day) AS dt FROM DateRange WHERE dt < (date('2011-07-01') - 1 day)
)
SELECT to_char(A.dt,'YYYYMMDD') as dt FROM DateRange A

예제 3.
Oracle
SELECT   LEVEL, TO_CHAR(TO_NUMBER('20111006') - 3 + LEVEL) Y_CD
FROM   DUAL
CONNECT BY LEVEL <= 3

DB2
WITH TEMPDATE(Y_CD, LVL) AS
(
SELECT CHAR(INTEGER('20111006')-2) AS Y_CD, 1 FROM SYSIBM.SYSDUMMY1
UNION ALL
SELECT CHAR(INTEGER(Y_CD) + 1), LVL+1 FROM TEMPDATE WHERE LVL <= 3
)
SELECT * FROM TEMPDATE

[Linux] Tip - grep, egrep, fgrep

RaiKan RaiKan — Tue, 20 Sep 2011 15:44:30 +0900

◇ grep 명령어

grep명령어는 정규식으로 표현한 특정 패턴을 찾아 검색 후 출력해주는 명령어이다.

여기서 정규식이란 어떤 특정한 규칙을 가진 문자열의 집합을 표현하는데 사용하는 언어이다.

주로 문자열을 검색할 때 사용된다.

이처럼 grep명령어는 정규식을 사용하여 특정 패턴(문자열)을 찾는 명령어이다.

정규식으로 표현한 기호에는 다음과 같은 것들이 있다.

기호	의미
.	종류에 상관없는 한 글자
*	길이에 상관없는 문자열
^	라인의 첫 시작 예)^d d로 시작하는 라인
$	라인의 마지막 위치 예)c$ c로 끝나는 라인
[]	한 문자 길이의 패턴들 예)[ab] a,b중 한글자라도 반드시 있는 단어
[^ ]	입력된 문자들의 여집합 예)[^ab] a,b중 한글자라도 없는 단어
\	정규식에 사용되는 문자를 그대로 이용
\<	단어의 시작 위치 예) \<love love로 시작하는 단어를 포함하는 행과 대응
\>	단어의 마지막 위치 예) \>love love로 끝나는 단어를 포함하는 행과 대응

먼저 grep 명령어에 어떠한 옵션 명령어가 있는지 알아보자.

-v : 지정한 패턴(문자열)과 일치하지 않는 것들을 보여준다.

-n : 패턴을 포함하는 줄을 출력할 때 줄번호와 함께 출력한다.

-i : 대 소문자의 구별을 하지 않는다.

-c : 패턴과 일치하는 라인의 수를 출력해준다.

-C [num] : 지정한 num 라인만큼 일치하는 라인의 위와 아래의 내용을 보여준다.

-A [num] : 지정한 num 라인만큼 일치하는 라인의 뒤의 내용까지 보여준다.

-v : 지정한 패턴(문자열)을 일치하지 않는 것들을 보여준다.

지정한 문자열과 일치하지 않는 것들을 보여준다.

-v 옵션을 명령어를 사용할 경우 root라는 문자열이 들어있지 않는 행 만을 출력하여 보여주는 것이다.

-n: 패턴을 포함하는 줄을 출력할 때 줄번호와 함께 출력한다.

지정한 문자열과 일치하는 라인(줄)을 보여주고, 그 파일에서의 결과 라인이 몇 번째 행인지 같이 출력된다.

한번 실습을 통해 자세히 알아보자.

아래 그림을 보면 etc라는 문자열이 들어있는 라인의 결과와 그 결과 라인이 10번째 줄, 31번째 줄, 34번째 줄에 속해 있는 것을

알 수 있다.

-i : 대 소문자의 구별을 하지 않는다.

찾은 문자열에 대해서 대ㆍ소문자를 구별하지 않고 보여주게 하는 옵션 명령어이다.

grep 명령어는 기본적으로 대ㆍ소문자를 구별하여 내용을 출력하게 된다.

하지만 이 옵션을 사용하게 되면 대ㆍ소문자를 구별없이 찾아주게 되는 것이다.

다음은 i 옵션을 사용하지 않은 예이다.

file1에 들어있는 내용 중에 jo라는 문자열이 들어간 행을 찾은 결과, 한개의 행만 출력되었다.

이번에는 i옵션을 같이 사용하여 출력한 예이다.

i옵션을 사용한 결과 대ㆍ소문자가 섞인 행이 2개 더 있다는 것을 보여준다.

-c : 패턴과 일치하는 라인의 수를 출력해준다.

찾으려는 문자열이 있는 행이 몇개 인지 라인의 수를 보여주는 옵션 명령어이다.

아래 그림에서 /etc/passwd 파일 내용 중에 etc라는 문자열이 들어가 있는 라인을 찾는데, -c 옵션을 사용하여

출력한 결과를 보여주고 있다.

찾은 결과 3개의 행에 etc라는 문자열이 포함되어있다고 출력된다.

-C [num] : 지정한 num 라인만큼 일치하는 라인의 위와 아래의 내용을 보여준다.

찾으려는 문자열이 들어간 라인의 위 아래의 내용을 지정한 숫자만큼 보여주는 명령어이다.

이때 숫자를 지정해주지 않으면 에러메시지가 출력되니, 반드시 숫자를 지정해주자.

아래 그림을 보면 root라는 문자열이 들어간 행이 2개가 출력되었는데 그 위 아래로 3행씩 더 보여주는 것을 알 수 있다.

-A [num] : 지정한 num 라인만큼 일치하는 라인의 뒤의 내용까지 보여준다.

이 옵션은 찾으려는 문자열과 일치하는 라인의 뒤에 내용을 지정한 숫자만큼 보여주는 옵션 명령어이다.

위의 -C 옵션이 위 아래로 내용을 보여주는 명령이였다면, -A 옵션은 뒤에 내용 즉, 아래의 내용을 보여준다.

아래 그림을 보면 root라는 문자열이 들어간 라인 행에서 아래의 2개 라인의 내용을 더 보여주는 것을 확인할 수 있다.

정규표현식을 사용하는 grep의 예제

grep 명령어와 정규식을 같이 사용하는 경우에는 파일에서 특정 문자열을 찾는데 사용하기보다는

여러 가지 명령어를 파이프라인을 통해 연결하여 많이 사용한다.

# ls -l /var/log | grep "^d"

(/var/log 디렉토리의 파일 리스트 중에 파일을 제외한 디렉토리만을 출력한다.)

# grep -n 'e$' /etc/inittab

(/etc/inittab에 내용 중 문자 e로 끝나는 라인의결과와 행번호를 함께 출력한다.)

# grep '^[xe]' /etc/inittab

(/etc/inittab 내용 중 문자 x나 e로 시작하는 모든 행을 출력한다.)

# ls -l /root | grep .txt*

(/root 디렉토리의 파일 리스트 중 .txt로 끝나는 확장자를 가진 모든파일들을 검색하여 출력한다.)

# grep NW d*

(d로 시작하는 모든 파일에서 NW를 포함하는 모든 행을 찾는다.

# grep '^[we]' datafile

(w나 e로 시작하는 모든 행을 출력한다.)

# grep 'TB Savage' datafile

(TB Savage를 포함하는 모든 행을 출력한다.)

# grep '[A-Z][A-Z] [A-Z]' datafile

(대문자 2개와 공백 1개, 그리고 대문자 하나가 연이어 나오는 문자열이 포함된 행을 출력한다.)
# grep "^c.*3$" test.txt

(시작문자가 "c", 마지막 문자가 "3"으로 끝나는 문자열을 포함하고 있는 문장을 검색하여 출력한다.)

# grep ".*1" test.txt

(grep 명령어를 사용하여 test.txt 파일 내용 중 "1"을 포함하고 있는 모든 문장을 검색하여 출력한다.)

◇ egrep 명령어

egrep명령어는 grep명령어와 다르게 패턴이 정규식이 아닌 확장 정규식을 사용하여

더 많은 다양한 패턴을을 찾아 검색할 수 있는 명령어이다.

사용 방법

# egrep [Option] 패턴 file_name

다음 그림을 보자.

/etc/passwd 파일의 내용 중 sshd와 root라는 특정 패턴을 찾기 위해 따로 검색하여 출력하였다.

이러한 경우 egrep명령어를 사용하여 한꺼번에 처리할 수 있다.

즉 egrep명령어는 찾고자 하는 여러개의 문자열을 |을 통해 연결하여 한꺼번에 처리할 수 있다.

◇ fgrep 명령어

fgrep명령어는 fast grep의 약어로 고속 검색 프로그램으로 개발되었다.

즉, grep이나 egrep와 다르게 정규식을 전혀 사용하지 않고 입력한 패턴을 그대로

인식한다.

따라서 고정 문자열을 검색할 때 grep보다 처리 속도가 훨씬 빠르다.

사용 방법

#fgrep [option] 패턴 file_name

Ex> 다음은 fgrep명령어의 실행 예이다.

다음 그림처럼 fgrep명령어는 '>&'기호를 그대로 인식하여 출력하기 때문에 처리속도가 빠르다.

출처 : http://cafe.naver.com/linuxs.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=12&(네이버 리눅스 스터디)

[DB2] Tablespace와 Bufferpool간의 성능 고려사항

RaiKan RaiKan — Thu, 15 Sep 2011 15:23:35 +0900

머리말

DB2의 세계로 막 진입한 DBA나 앞으로 DBA가 될 사람들에게는 새로운 데이터베이스를 위한 디자인과 퍼포먼스를 선택하기란 매우 어렵다. 이 글에서, DBA에게 있어 중요한 두 가지 영역에 대해 살펴보기로 한다. 바로 테이블 공간과 버퍼 풀이다. 테이블 공간과 버퍼 풀을 어떻게 디자인 하는냐, 또 어떻게 튜닝하느냐에 따라 DB2 Server의 성능에 큰 영향을 줄 수 있기 때문에 테이블 공간과 버퍼 풀의 디자인과 튜닝에 초점을 맞추어 설명하도록 한다.

예제는 DB2 version 8.1, Enterprise Server Edition을 기준으로 한다. 예제 대부분은 이전 버전에도 적용된다. version 8.1에만 적용될 경우 별도로 알려주겠다.

Section 1에서는 DB2가 테이블 공간 Type을 어떻게 정의하고 데이터를 어떻게 저장하는지에 대해 설명할 예정이다. 그리고 구성 옵션 및 테이블 공간의 생성 및 관리방법에 대해 다룰 것이다. 또한, 버퍼 풀이 무엇이며 버퍼 풀의 생성 및 사용방법에 대해서도 중점적으로 다룰 예정이다. Section 2에서는 성능을 높이기 위해 앞에서 다룬 테이블 공간 및 버퍼풀이 어떻게 구성되어야 하는지를 알아보도록 한다.

위로

Section 1: 정의

테이블 공간

데이터베이스안에 존재하는 모든 데이터들은 수 많은 테이블 공간에 저장된다. 테이블 공간을 자식으로 , 데이터베이스를 부모로 생각해 보면 테이블 공간(자식)은 한 개 이상의 데이터베이스(부모)를 가질 수 없다. 테이블 공간마다 사용 용도가 다르기 때문에 사용용도 및 관리 방식에 따라 테이블 공간은 다음과 같이 다섯가지로 분류된다.

카탈로그 테이블 공간: 데이터베이스 당 단 한 개의 카탈로그 테이블 공간이 있고 CREATE DATABASE 명령어가 실행될 때 만들어 진다. DB2에 의해 SYSCATSPACE로 이름이 붙여진 카탈로그 테이블 공간에는 시스템 카탈로그 테이블이 있다. 이 테이블 공간은 데이터베이스가 만들어질 때 항상 생성되어진다.
Regular 테이블 공간: regular 테이블 공간에는 테이블 데이터와 인덱스가 포함된다. 만약 Large Objects ( LOBs ) 같은 Long 데이터가 Long 테이블 공간에 명시적으로 저장되지 않았다면 이와 같은 Long 데이터도 Regular 테이블 공간에 저장될 수 있다. 테이블과 인덱스는 개별적인 Regular 테이블 공간으로 분리될 수 있다. 테이블 공간이 데이터베이스 관리 공간(DMS)일 경우가 그렇다. DMS와 시스템 관리 공간(SMS)의 차이는 나중에 설명하도록 하겠다. 적어도 한 개의 Regular 테이블 공간은 각 데이터베이스에 존재해야 한다. 데이터베이스가 만들어질 때 디폴트로 USERSPACE1이라는 이름이 붙여진다.
Long 테이블 공간: Long 테이블 공간은 길거나 LOB 테이블 칼럼을 저장하는데 사용되고 DMS 테이블 공간에 있어야 한다. 또한 구조화된 유형 칼럼이나 인덱스 데이터도 저장할 수 있다. Long 테이블 공간이 정의되지 않으면 LOB는 Regular 테이블 공간에 저장된다. Long 테이블 공간은 옵션이며 기본적으로 생기는 것이 아니다.
시스템 임시 테이블 공간: 시스템 임시 테이블 공간은 소팅, 테이블 재구성, 인덱스 생성, 테이블 결합 같은 SQL 연산 동안 필요한 내부의 임시 데이터를 저장하는데 사용된다. 데이터베이스에 최소 한 개는 있어야 한다. 데이터베이스와 함께 생성되며 디폴트 이름은 TEMPSPACE1이다.
사용자 임시 테이블 공간: 사용자 임시 테이블 공간에는 Declared Global Temporary Table이 저장된다. 데이터베이스가 만들어질 때에는 사용자 임시 테이블 공간은 존재하지 않으나 만약 Declared Global Temporary Table을 정의할 경우에는 적어도 한 개의 사용자 임시 테이블 공간이 존재해야만 한다. 사용자 임시 테이블 공간은 선택사항이며 디폴트로는 생성이 되지 않는다.

테이블 공간 관리

테이블 공간은 두 가지 방식으로 관리될 수 있다.

시스템 관리 공간(SMS): SMS 테이블 공간은 OS가 관리한다. 컨테이너들은 일반 OS 파일로서 정의되고 OS 호출을 통해 액세스 된다. 즉 이는 모든 일반 OS 함수들이 다음과 같은 것을 다룰 수 있다는 것을 의미한다. : I/O는 OS에 의해 버퍼링 되고 공간은 OS 규약에 따라 할당되고 테이블 공간은 필요할 경우 자동으로 확장된다. 하지만 SMS 테이블 공간에서 컨테이너들을 제거하는 것은 불가능하고 새로운 컨테이너들을 SMS 테이블 공간에 추가하는 것은 파티션 데이터베이스에서만 가능하다. 이전 섹션에서 설명한 이 세가지 기본 테이블 공간이 SMS이다.
데이터베이스 관리 공간(DMS): DMS 테이블 공간은 DB2가 관리한다. 컨테이너는 파일(테이블 공간이 만들어 질 때 주어진 크기로 할당될 것이다.) 또는 디바이스로 정의된다. DB2는 할당 메소드 만큼 많은 I/O를 관리할 것이고 OS가 이를 수락할 것이다. 컨테이너 확장은 ALTER TABLESPACE 명령어를 통해 가능하며 사용되지 않는 DMS 컨테이너 부분 역시 릴리스 될 수 있다. ( Version 8 부터 )

다음은 컨테이너 크기를 늘리는 방법이다. (version 7과 version 8 모두 지원됨)

ALTER TABLESPACE TS1 RESIZE (FILE '/conts/cont0' 2000, DEVICE '/dev/rcont1' 2000, FILE 'cont2' 2000)

원래 컨테이너의 크기를 더 작은 크기로 조정하는 것은 Version 8에서만 지원된다.

테이블 공간을 생성하고 보는 방법

데이터베이스를 만들 때 세 개의 테이블 공간이 만들어진다. (SYSCATSPACE, TEMPSPACE1, USERSPACE1). DB2 명령어 윈도우나 유닉스 명령행을 사용하여 testdb라는 데이터베이스를 만들어서 여기에 연결하고 테이블 공간들을 나열한다.

CREATE DATABASE testdb CONNECT TO testdb LIST TABLESPACES

아래 Listing 1은 LIST TABLESPACES 명령어의 결과이다.

Listing 1. LIST TABLESPACES 명령어의 결과

				Tablespaces for Current Database

				Tablespace ID = 0 Name = SYSCATSPACE Type = System
				managed space Contents = Any data State = 0x0000
				Detailed explanation: Normal

				Tablespace ID = 1 Name = TEMPSPACE1 Type = System
				managed space Contents = System Temporary data State =
				0x0000 Detailed explanation: Normal

				Tablespace ID = 2 Name = USERSPACE1 Type = System
				managed space Contents = Any data State = 0x0000
				Detailed explanation: Normal

위에 보이는 세 개의 테이블 공간은 CREATE DATABASE 명령어에 의해 자동으로 생성된다. 사용자는 CREATE DATABASE 명령어 수행시 테이블 공간에 대한 정의를 지정함으로써 테이블 공간을 디폴트 값으로 생성하지 않아도 된다. 하지만 카탈로그 테이블 공간과 최소 한 개의 일반 테이블 공간과 한 개의 시스템 임시 테이블 공간은 데이터베이스 생성시 만들어져야 한다. (카탈로그 테이블 공간을 제외한) 모든 유형의 테이블 공간들이 CREATE DATABASE 명령어나 CREATE TABLESPACE 명령어를 사용하여 생성될 수 있다.

컨테이너

모든 테이블 공간에는 한 개 이상의 컨테이너가 있다. 이 컨테이너를 자식으로, 테이블 공간을 부모로 생각할 수 있다. 각 컨테이너는 한 개의 테이블 공간에만 속하지만 테이블 공간은 많은 컨테이너를 가질 수 있다. 컨테이너는 DMS 테이블 공간에 추가되거나 그 공간에서 제거될 수 있고 크기도 수정될 수 있다. 컨테이너는 파티션으로 나뉜 데이터베이스 상의 SMS 테이블 공간에만 추가될 수 있다. 이 파티션에는 테이블 공간에 할당된 컨테이너가 아직 없다. 새로운 컨테이너가 추가되면 자동 밸런싱이 시작되어 전체 컨테이너에 걸쳐 데이터를 분산시킨다. 재 밸런싱은 데이터베이스로의 동시 액세스를 방해하지는 않는다.

테이블 공간 설정

테이블 공간에는 많은 것이 설정될 수 있다. 테이블 공간이 생성될 때나 나중에 ALTER TABLESPACE문을 사용하여 설정할 수 있다.

페이지 크기 ( Page Size ): 테이블 공간에 사용되는 페이지 크기를 정의한다. 지원되는 크기는 4K, 8K, 16K, 32K이다. 페이지 크기에 따라 테이블 공간에 저장되는 테이블의 한 행의 최대 길이와 컬럼 개수가 아래 표와 같이 제한된다.

표 1. 페이지 크기

페이지 크기	열 크기 한계	칼럼 카운트 한계	최대 용량
4 KB	4 005	500	64 GB
8 KB	8 101	1 012	128 GB
16 KB	16 293	1 012	256 GB
32 KB	32 677	1 012	512 GB

테이블 공간은 16384 페이지로 제한되기 때문에 이보다 더 큰 페이지를 선택하면 테이블 공간의 용량도 늘어난다.

확장 크기 ( Extent Size ): 다음 컨테이너로 넘어가기 전에 컨테이너에 작성될 페이지의 수를 지정한다.데이터베이스 매니저는 컨테이너들을 반복적으로 순환하면서 데이터들을 저장한다. 이 매개 변수는 테이블 공간을 구성하는 컨테이너가 여러 개일 경우에만 유효하다.
프리패치 크기 ( Prefetch Size ): 데이터 프리패치(미리 가져오기)가 수행될 때 테이블 공간에서 읽혀질 페이지의 수를 지정한다. 프리패치는 쿼리에 의해 참조되기 전에 쿼리에 필요한 데이터를 읽어서 쿼리가 I/O가 수행되는 것을 기다리지 않도록 한다. 프리패치는 순차적 I/O가 적절하고 프리패치가 퍼포먼스를 향상시킬 수 있다고 판단될 때 데이터베이스 매니저가 선택하는 것이다.
오버헤드와 전송 비율 ( Overhead and Transfer Rate ): 이 값은 쿼리 최적화 동안 I/O의 비용을 결정하는데 사용된다. 두 값 모두 밀리초로 측정되고 모든 컨테이너의 평균치어야 한다. 오버헤드는 I/O 컨트롤러 액티비티, 디스크 탐색 시간, 회전 지연시간과 관련된 시간이다. 전송 비율은 한 페이지를 메모리로 읽어 들이는데 필요한 시간이다. 디폴트 값은 각각 24.1과 0.9이다. 이 값들은 하드웨어 스팩에 기반하여 계산될 수 있다.

CREATE TABLESPACE문의 예제

아래 예제는 Regular 테이블 공간을 생성하는 명령문을 보여준다. 위에서 거론되었던 매개변수 값들이 설정되어 있다.

CREATE TABLESPACE USERSPACE3 
PAGESIZE 8K 
MANAGED BY SYSTEM 
USING ('d:\usp3_cont1', 'e:\usp3_cont2', 'f:\usp3_cont3') 
EXTENTSIZE 64 
PREFETCHSIZE 32 
BUFFERPOOL BP3 
OVERHEAD 24.1 
TRANSFERRATE 0.9

테이블 공간 애트리뷰트와 컨테이너를 보는 방법

LIST TABLESPACES 명령어의 SHOW DETAIL 옵션을 지정하면 추가 정보를 볼 수 있다.

LIST TABLESPACES SHOW DETAIL

Listing 2는 USERSPACE1 테이블 공간에 대한 정보를 보여준다. 디폴트로 데이터베이스 생성시 생성된 세 개의 테이블 공간들이 나열된다.

Listing 2. LlST TABLESPACES SHOW DETAIL 명령어의 결과값

Tablespaces for Current Database

Tablespace ID = 2 Name = USERSPACE1 Type = System
managed space Contents = Any data State = 0x0000
Detailed explanation: Normal Total pages = 336 Useable
pages = 336 Used pages = 336 Free pages = Not
applicable High water mark (pages) = Not applicable
Page size (bytes) = 4096 Extent size (pages) = 32
Prefetch size (pages) = 16 Number of containers = 1

필요한 컨테이너 정보를 보려면 위의 결과값에서 Tablespace ID를 사용하여 아래 명령어를 수행한다.

LIST TABLESPACE CONTAINERS FOR 2

Listing 3. LIST TABLESPACE CONTAINERS 명령어의 결과값

Tablespace Containers for Tablespace 2

Container ID = 0 Name =
C:\DB2\NODE0000\SQL00004\SQLT0002.0 Type = Path

이 명령어를 사용하면 지정된 테이블 공간에 대한 모든 컨테이너들이 나타난다. 위에 나타난 경로는 컨테이너가 물리적으로 위치한 곳을 가리킨다.

버퍼 풀

버퍼 풀은 하나의 데이터베이스와 제휴 되어 있고 한 개 이상의 테이블 공간에 의해 사용될 수 있다. 한 개 이상의 테이블 공간을 위한 버퍼 풀을 고려할 때 버퍼 풀 페이지 크기는 반드시 그 버퍼 풀을 사용하는 모든 테이블 공간의 페이지 크기와 동일해야 한다. 테이블 공간은 한 개의 버퍼 풀만을 사용한다.

데이터베이스가 만들어지면 IBMDEFAULTBP 라는 기본 버퍼 풀이 만들어지고 이는 모든 테이블 공간들이 공유한다. 더 많은 버퍼 풀들은 CREATE BUFFERPOOL 문을 사용하여 추가될 수 있다. 버퍼 풀 크기는 BUFFPAGE 데이터베이스 설정 매개변수로 지정된 크기가 기본이지만 CREATE BUFFERPOOL 명령어에서 SIZE 키워드를 지정해도 된다. 디스크 I/O를 줄이기 때문에 버퍼 풀 크기를 적절히 하는 것은 데이터베이스 성능에 중요하다. 또한 더 많은 작업들이 메모리에서 수행될 수 있으므로 버퍼 풀을 크게 하는 것은 쿼리 최적화에 영향을 준다.

블록 기반 버퍼 풀: Version 8에서는 블록 기반 프리패치를 위해 버퍼 풀(최대 98%) 부분을 남겨둘 수 있다. 블록 기반 I/O는 인접한 메모리 영역으로 블록을 읽어들임으로서 프리패치의 효율성을 높인다. 블록의 크기는 모든 버퍼 풀에 동일해야 하고 BLOCKSIZE 매개변수가 제어한다. 이 값은 페이지 단위의 블록 크기(2에서 256)이고 디폴트는 32이다.
확장된 스토리지: DB2는 버퍼의 확장된 스토리지를 사용하지 않는다. 하지만 확장된 스토리지는 메모리 페이지를 캐싱하는데 사용될 수 있다. 따라서 메모리에서 페이지를 더욱 빨리 이동할 수 있다.

CREATE BUFFERPOOL문 예제

다음은 CREATE BUFFERPOOL문 예제이다.

CREATE BUFFERPOOL BP3 SIZE 2000 PAGESIZE 8K

이 버퍼풀은 위 CREATE TABLESPACE 예제의 USERSPACE3에 지정된 것이고 테이블 공간이 생성되기 전에 만들어져야 된다. 이 버퍼 풀과 테이블 공간의 페이지 크기는 8K로 동일하다. 만약 버퍼 풀을 생성한 후에 테이블 공간을 생성하고 CREATE TABLESPACE 구문에서 BUFFER POOL BP3를 빼놓았다면 ALTER TABLESPACE 구문을 이용하여 기존 테이블 공간에 버퍼 풀을 추가할 수 있다.

ALTER TABLESPACE USERSPACE3 BUFFERPOOL BP3

버퍼 풀 애트리뷰트를 보는 방법

SYSCAT.BUFFERPOOLS 시스템 뷰를 쿼리하여 버퍼 풀 정보를 볼 수 있다.

SELECT * FROM SYSCAT.BUFFERPOOLS


BPNAME BUFFERPOOLID NGNAME NPAGES PAGESIZE ES
------------------ ------------ ------------------
----------- ----------- -- IBMDEFAULTBP 1 - 250 4096 N

1 record(s) selected.

어떤 버퍼 풀이 테이블 공간에 할당되었는지를 보려면 다음 쿼리를 실행한다.

SELECT TBSPACE, BUFFERPOOLID FROM
SYSCAT.TABLESPACES

TBSPACE BUFFERPOOLID ------------------ ------------
SYSCATSPACE 1 TEMPSPACE1 1 USERSPACE1 1

3 record(s) selected.

위의 Query 결과값에서 BUFFERPOOLID 를 사용하면 어떤 버퍼 풀이 어떤 테이블 공간과 연결되어 있는지 알 수 있다.

데이터베이스가 테이블 공간을 확보하는 방법

지금까지 테이블 공간과 버퍼풀이 무엇인지, 그리고 이들을 생성하는 방법을 설명했다. 이제는 이들이 데이터베이스 내에서 어떻게 구성되는지를 알아보자.

그림 1. 테이블 공간과 버퍼 풀

XML error: The image is not displayed because the width is greater than the maximum of 580 pixels. Please decrease the image width.

이 데이터베이스는 다섯 개의 테이블 공간을 갖고 있다. 카탈로그 테이블 공간, 두 개의 Regular 테이블 공간, Long 테이블 공간, 시스템 임시 테이블 공간. 그러나 사용자 임시 테이블 공간은 생성되지 않았다. 다섯 개의 테이블 공간에 속하는 여덟 개의 컨테이너가 있다.

이 시나리오에서 버퍼 풀들은 다음과 같이 할당된다.
BP1 (4K) – SYSCATSPACE와 USERSPACE2
BP2 (8K)- USERSPACE1
BP3 (32K)- LARGESPACE와 SYSTEMP1

위로

Section 2: 성능

일반적으로 물리적 장치에 테이블 공간과 컨테이너 배치를 설계할 때 I/O 병렬성과 버퍼 활용의 최대화에 초점을 맞추게 된다. 이 목표를 이루기 위해 데이터베이스 디자인과 애플리케이션에 대해 완벽히 이해해야 한다. 그런 다음에야 두 개의 테이블을 별도의 디바이스로 분리하는 것이 병렬 I/O를 일으킬 것인지의 여부, 또는 테이블을 별도의 테이블 공간에 생성하여 완전히 버퍼링 될 수 있는지 같은 문제를 결정할 수 있다.

새로운 데이터에 대한 물리적 레이아웃 설계는 테이블 공간을 구성하는 것으로 시작한다.

첫 번째 단계는 테이블 디자인의 제약조건을 결정하는 단계이다. 이것은 한 개이상의 Regular 테이블 공간을 사용해야 할지도 모른다.
두 번째 단계에서는 다른 설정값을 가진 테이블 공간에 테이블을 생성하는 것이 성능을 향상시키는 것인지 고려해야 한다.
임시적인 테이블 공간 디자인이 완성되면 버퍼 풀 활용에 대해 생각해야 한다. 이전 테이블 공간 디자인을 수정할 수도 있다.
마지막으로, 테이블 공간에 컨테이너를 할당한다.

이 프로세스는 반복적이고 스트레스 테스트와 벤치마킹을 통해 디자인을 검증 받아야 한다. 최적의 디자인은 강도 높은 노력을 통해 탄생하고 데이터베이스 퍼포먼스도 최상이어야 한다.

단순한 디자인에서 출발한다.
테스팅에 기반하여 충분한 이유가 있을 때만 복잡성을 추가하도록 한다.

가끔은 성능이 약간 저하된다 하더라도 데이터베이스에 대한 관리의 복잡성을 줄이고 데이터베이스 디자인을 단순화하는 것이 더 낫다. DB2는 매우 정교한 리소스 관리 로직을 가지고 있으므로 정교한 디자인 없이도 좋은 성능을 낸다.

테이블 공간 구성

카탈로그 테이블 공간과 시스템 임시 테이블 공간은 SMS로서 할당된다. 같은 페이지 크기를 가진 임시 테이블 공간을 한 개 이상 가질 필요가 없다. 최대 페이지 크기를 가진 한 개로 충분하다.

사용자 데이터를 다중 테이블 공간으로 나누어야 할 지의 여부가 의문스럽다. 고려해 볼 수 있는 것은 페이지의 활용이다. 한 행(row)은 페이지들간 나누어질 수 없기 때문에 긴 행을 가진 테이블은 적절한 페이지 크기가 필요하다. 하지만 한 페이지당 255 행 이상이 될 수 없기 때문에 짧은 행을 가진 테이블은 전체 페이지를 활용하지 않는다. 페이지 크기가 32K인 테이블 공간에 있는 행 길이 12 바이트의 테이블은 각 페이지의 10% 정도만 활용한다. (((255 행 * 12 바이트) + 91 바이트 오버헤드) / 32k 페이지 크기 = ~10%)

이는 테이블이 길 때 고려해야 할 것이다. 따라서 낭비되는 공간은 상당하다. 또한 I/O와 버퍼링의 효율성도 떨어진다. 각 페이지의 실제로 유용한 컨텐트는 작기 때문이다. 테이블이 작은 페이지 크기의 테이블 공간에 배치되고 큰 페이지를 활용한다면 가장 흔한 액세스 방식이 어떤 것이 더 나은지를 결정하게 된다. 많은 행들이 순차적으로 액세스 된다면(아마 테이블이 클러스터링 되어 있을 것이다.) 큰 페이지가 보다 효율적이다. 행이 랜덤으로 액세스 된다면 작은 페이지 크기가 버퍼를 더욱 잘 활용할 것이다.

테이블들이 페이지 크기로 그룹핑 되면 액세스 빈도와 유형으로 데이터를 개별 테이블 공간으로 그룹핑 할 것인지의 여부를 결정하게 된다. 각 테이블은 가장 빈번하게 액세스 되는 방식에 따라 가장 효율적인 테이블 공간 설정을 갖게 된다. PAGESIZE, EXTENTSIZE, PREFETCHSIZE, EXTENTSIZE는 데이터가 다음 컨테이너에 저장되기 전에 한 컨테이너에 저장될 데이터 페이지의 수이다. (한 테이블 공간에 여러 개의 컨테이너가 존재할 경우)

PREFETCHSIZE는 데이터 프리패치가 수행될 때 테이블 공간에서 읽어 들일 페이지의 수를 지정한다. 데이터베이스 매니저가 순차적 I/O가 적절하고 프리패치가 성능 향상에 도움이 된다고 결정하면 프리패치가 사용된다. PREFETCHSIZE 값은 테이블 공간의 EXTENTSIZE 값과 그 테이블 공간에 속하는 컨테이너 수의 곱의 배수로 설정하는 것이 좋다. EXTENTSIZE가 32이고 네 개의 컨테이너가 있다면 PREFETCHSIZE는 128, 256 등이 된다. 만약 자주 사용되는 테이블이 같은 테이블 공간에 존재하는 나머지 테이블과는 다른 성능 매개변수 값들을 요구한다면 이러한 테이블을 별도의 테이블 공간에 두는 것이 전체적인 성능을 향상시킬 것이다.

프리패치가 테이블 공간에 중요한 요소라면 블록 기반의 I/O에 대한 버퍼 부분을 남겨두는 것도 생각해 보라. 블록 크기는 PREFETCHSIZE와 같아야 한다.

버퍼 풀 활용

한 개 이상의 사용자 테이블 공간을 사용하는 가장 중요한 이유는 버퍼 활용을 관리하기 위해서 이다. 하나의 테이블 공간은 하나의 버퍼 풀만 사용할 수 있고 한 개의 버퍼 풀은 한 개 이상의 테이블 공간에 사용될 수 있다.

버퍼 풀을 튜닝하는 이유는 DB2가 버퍼에 사용할 수 있는 메모리를 최대한 활용할 수 있도록 하기 위해서 이다. 전체 버퍼 크기는 DB2 퍼포먼스에 중요한 영향을 미친다. 페이지가 많으면 많을수록 시간 소비가 가장 큰 I/O 작업이 현저히 줄어들기 때문이다. 하지만 총 버퍼 크기가 너무 크고 할당할 충분한 스토리지가 없다면 각 페이지 크기 별로 최소한의 버퍼 풀이 할당되고 성능은 저하될 것이다. 최대 버퍼 크기를 계산하려면 DB2 뿐만 아니라 OS와 다른 애플리케이션에서의 스토리지 활용도 고려해야 한다. 총 가용 크기가 결정되면 활용도를 높이기 위해 다른 버퍼풀로 나뉘어 질수도 있다. 다른 페이지 크기의 테이블 공간이 있다면 페이지 크기 당 최소한 한 개의 버퍼 풀이 있어야 한다.

한 개 이상의 버퍼 풀이 있다면 그 버퍼에 데이터를 보존할 수 있다. 예를 들어, 데이터베이스가 매우 빈번하게 사용되는 작은 테이블들을 갖고 있고 이들 전체 데이터가 버퍼에 있다면 매우 빠르게 액세스 될 것이다. 그러나 만약 매우 큰 테이블에 대해 실행되는 쿼리가 있고, 같은 버퍼 풀을 사용하고 총 버퍼 크기 보다 많은 페이지들을 읽는다고 가정해 보자. 쿼리가 실행되면 작고, 매우 빈번하게 사용되는 테이블에서 온 페이지들은 소실될 것이다. 이들이 다시 필요하게 될 때 다시 읽어 들여야 한다.

만약 작은 테이블들이 자신의 버퍼 풀이 있고 이로 인해 자기 소유의 테이블 공간도 가져야 한다면 메모리에 존재하는 이들 페이지는 큰 쿼리에 의해 더 이상 소실되지 않아도 된다. 비록 큰 쿼리에는 어느정도 부정적인 영향을 미치지만 이것은 전반적인 시스템 향상을 가져올 것이다. 매우 빈번한 튜닝은 전체 퍼포먼스 관점에서 볼 때 상쇄적인 측면이다. 시스템의 성능을 튜닝할 때 기능들에 대해 우선순위를 정하고 전체 throughput과 사용에 대해 항상 명심해야 한다.

데이터베이스를 중지하지 않고도 버퍼 풀 크기를 변경할 수 있는 기능이 V8에 새로 도입되었다. ALTER BUFFERPOOL 문에 IMMIDIATE 옵션을 사용하면 바로 적용된다. 그러나 데이터베이스 공유 메모리에 할당할 수 있는 충분한 보유공간이 없다면 바로 적용되지 못한다. 이 기능은 주기적인 변경에 따라 데이터베이스 퍼포먼스를 튜닝 할 때 사용된다.

물리적 스토리지 구성

테이블들이 테이블 공간으로 분산되면 물리적 스토리지를 결정해야 한다. 테이블 공간은 여러 컨테이너들에 저장될 수 있고 SMS나 DMS가 될 수 있다. SMS는 관리하기가 더 쉽고 작고 다양한 테이블들을 많이 포함하고 있는 테이블 공간(카탈로그 테이블 공간)에 알맞다. 이 테이블에 LOB가 포함되어 있다면 더욱 좋다. SMS 컨테이너를 한 번에 한 페이지씩 확장하는 오버헤드를 줄이려면 db2empfa 명령어를 실행한다. 이것은 데이터베이스 설정 매개변수인 MULTIPAGE_ALLOC의 값을 YES로 설정한다.

DMS는 일반적으로 더 나은 성능을 보이고 인덱스와 LOB 데이터를 분리해서 저장할 수 있는 유연성도 제공한다. 하나의 테이블 공간을 구성하는 여러 컨테이너들은 각각 다른 물리적 불륨에 놓여질 경우 I/O 병렬성을 향상시킬 수 있으므로 가능한한 분리해서 놓는 것이 좋다. 여러 사용자 테이블 공간과 여러 장치들이 있다면 애플리케이션 로직을 고려하여 워크로드가 장치들에 고르게 분배될 수 있도록 한다.

RAID 디바이스는 주의해야할 고려 사항들이 있다. EXTENTSIZE는 RAID 스트라이프 크기와 같거나 배수여야 한다. PREFETCHSIZE는 RAID 병렬 디바이스의 수 ( 또는 배수 ) 와 RAID 스트라이프 크기의 곱이여야 한다. DB2에는 레지스트리 변수들이 있는데 이것은 특정 환경을 향상시킨다. 다음 명령어를 실행하면 I/O 병렬성이 단일 컨테이너 내에서도 가능해 진다.

db2set DB2_PARALLEL_IO=*

또 다른 레지스트리 변수인 DB2_STRIPED_CONTAINERS=ON 은 컨테이너 태그 크기를 한페이지에서 전체 EXTENT 로 변경하여 RAID 스트라이프로 테이블 공간 EXTENT 를 구성할 수 있다.

다른 성능 평가와 마찬가지로 변경이 효과적인 결과를 가져올 것인지 알수 있는 확실한 방법은 벤치마크를 수행하는 것이다. 물리적 구성 변경의 경우 다소 복잡하다. 테이블 공간을 변경하는데 노력이 많이 든다. 가장 실질적인 방법은 디자인 단계에서 케이스의 수를 줄여서 나중에 벤치마크에도 적은 케이스만 쓰이도록 하는 것이다. 퍼포먼스가 중요할 경우에는 시간과 노력을 많이 들여도 좋다. 디자인 마다 퍼포먼스 차이가 상당하다. 버퍼 풀에 중요성을 두어야 하며, 이들은 가상 메모리에 할당되어서는 안되며 가장 효율적인 방식으로 사용되어야 한다.

데이터베이스 옮기기

다른 시스템으로 옮기기 전에, 시스템이 같은 종류의 플랫폼일지라도 데이터베이스의 매개변수와 물리적 구성은 언제나 평가되어야 한다. 실제 상황에서 DBA는 1 GB 스토리지를 가지고 있는 Window 서버에서 잘 Tuning된 데이터베이스를 256 MB 스토리지를 가지고 있는 랩탑으로 옮긴후에 서버에서는 연결 하는데에 몇초 걸리지 않았던 것이 옮긴후에 45분이나 걸렸다. 이 문제는 버퍼 풀 크기와 다른 메모리 매개변수들을 줄여서 해결되었다.

플랫폼이 다르다면 문제도 달라진다. 유닉스와 Windows간 이동일 경우, 한 시스템에서 최적 조건이 다른 시스템에서는 그렇지 않을 수도 있다. 데이터베이스를 복사한다면 반복적으로 튜닝을 해야 한다. 데이터베이스를 zSeries ^TM으로 옮겨야 한다면 해당 매뉴얼과 레드북을 참고해야 한다. iSeries 시스템에서 물리적 설정과 튜닝은 데이터베이스 환경 밖에서 함께 수행되고 iSeries ^TM 시스템 관리 매뉴얼을 참조해야 한다.

위로

결론

이 글에서는 데이터베이스 디자인과 퍼포먼스에 대한 극히 일부분만을 설명했다. 쿼리 최적화와 애플리케이션 고려사항까지 들어가지 않고 데이터베이스 디자인 문제들을 집중적으로 설명했다. 데이터베이스 설계는 가장 우선적인 일이다. 따라서 초기 플래닝은 포괄적이어야 한다. 여러분에게 도움이 되도록 온라인 지침서도 마련해 두었다.

기사의 원문보기

DB2 Basics: Table Spaces and Buffer Pools

http://www.ibm.com/developerworks/kr/library/0212wieser/0212wieser.html