728x90
반응형
앞의 포스팅에서는 snapshot을 이용한 시스템 모니터링 방법을 확인해 보았다.
이번에는 스냅샷과 더불어서 가장 많이 사용되고 있는 db2pd를 이용하여 시스템 모니터링 하는 방법에 대해서 알아 보도록 하자.
IBM에서 말하기를 스냅샷은 내부적으로 정보를 가져오기 위해서 Latch를 획득해야 하지만 db2pd는 Direct Memory 엑세스 방식이라 데이터 베이스의 문제 시점에도 무난하게 시스템 정보를 가져 올 수 있다고 한다.
하지만 , 실제로 확인은 해 보지 못했다. 정말 데이터 베이스가 hang 상태일때 db2pd 명령어가 수행이 되며, 그 시점의 데이터 베이스 상태를 남겨 놓을 수 있는지에 대해서는 ...
db2pd 명령어는 DB2 정보 센터에서는 V9.1 Fixpack 5 이전 버젼에서는 SYSADM 권한이 있으면 사용이 가능하고, V9.1 Fixpack 6 이후 에서는 SYSADM , SYSCTRL , SYSMAINT , SYSMON 의 권한 중 하나라도 가지고 있으면 사용이 가능하다고 한다.
하지만... 실제 SYSADM 그룹에 속해 있도록 O/S 유저를 생성한 후 db2pd 명령어를 수행해 보면 수행이 되질 않는다.
db2pd 명령어는 db2 owner만이 수행이 가능하다.
~sqllib/adm 디렉토리 밑의 db2pd 파일의 권한을 체크해 보면 다음과 같다.
sqllib/adm]ls -al db2pd
-r-sr-s--x 1 root db2iadm1 4021464 Aug 5 13:23 db2pd*
부득이 하게 db2 owner가 아닌 SYSADM 그룹의 다른 유저가 db2pd 명령어를 수행 할 수 있도록 하려면 ,
root 유저로 로그인을 한 후에 db2pd 명령어를 하나 카피해서 db2pd2라는 명령어를 만든 후 , db2pd2 명령어의 권한을 풀어 주는 방법을 이용하면 된다.
그럼 본격적으로 db2pd 명령어를 이용한 시스템 모니터링을 해 보도록 하자.
우선 사용할 수 있는 명령어를 알기 위해서는 다음 명령을 수행해 보면 된다.
sqllib/adm]db2pd -h
Usage:
-h | -help [file=<filename>]
Help
-v | -version [file=<filename>]
Version
-osinfo [disk] [file=<filename>]
Operating System Information
-dbpartitionnum <num>[,<num>]
Database Partition Number(s)
-alldbpartitionnums
All partition numbers
-database | -db <database>[,<database>]
Database(s)
-alldatabases | -alldbs
All Active Databases
-inst
Instance scope output
-file <filename>
All Output to Filename
-command <filename>
Read in predefined options
-interactive
Interactive
-full
Expand output to full length
-repeat [num sec] [count]
Repeat every num seconds (default 5) count times
-everything
All options on all database partitions
Instance scope options:
-agents [db=<database>] [[<AgentId> | [app=<AppHandl>]] [file=<filename>]
Agents
-fcm [hwm] [<numApps>] [file=<filename>]
FCM Information
-memsets [file=<filename>]
Memory Sets
-mempools [file=<filename>]
Memory Pools
-memblocks [[dbms, fcm, fmp, appctl <id>] | [all]] [scrape] [top] [blocks] [sort] [PoolID] [pid=<pid>]
Memory Blocks
-dbmcfg [file=<filename>]
DBM Config
-sysplex [db=<database>] [file=<filename>]
Sysplex List
-utilities [file=<filename>]
Utilities
-fmp
FMP Table
-latches [group] [file=<filename>]
Latches
-stack [all|<pid>]
Produce stack trace for all PIDs or chosen PID.
-dump [all|<pid>]
Produce dump file and stack trace for all PIDs or chosen PID.
Database scope options:
-applications [[<AppHandl> | [agent=<AgentId>]] [file=<filename>]
Applications
-transactions [<TranHdl> | [app=<AppHandl>]] [file=<filename>]
Transactions
-bufferpools [<bpID>] [file=<filename>]
Buffer Pools
-pages [<bpID>] [summary] [file=<filename>]
Bufferpool Pages
-logs [file=<filename>]
Transaction Logs
-locks [<TranHdl>] [file=<filename>] [showlocks] [wait]
Locks
-tablespaces [<Tablespace ID>] [group] [file=<filename>]
Tablespaces/Containers
-dynamic [file=<filename>]
Dynamic Cache
-static [file=<filename>]
Static Cache
-memsets [file=<filename>]
Memory Sets
-mempools [file=<filename>]
Memory Pools
-memblocks [[dbms, fcm, fmp, appctl <id>] | [all]] [scrape] [top] [blocks] [sort] [PoolID] [pid=<pid>]
Memory Blocks
-dbcfg [file=<filename>]
Database Config
-catalogcache [file=<filename>]
Catalog Cache
-tcbstats [all|index] [<TbspaceID> [<TableID>]] [file=<filename>]
Table Control Block Stats
-reorgs [file=<filename>]
Table Reorg Stats
-recovery [file=<filename>]
Recovery Status
-reopt [file=<filename>]
Reoptimized SQL Statements
-storagepaths
Storage Paths
-hadr [file=<filename>]
High Availability Disaster Recovery
-activestatements [file=<filename>]
Active Statement List
-apinfo [all|<AppHandl>] [all|<MaxStmt>] [file=<filename>]
List detailed information about the application(s)
-wlocks [file=<filename>]
Locks being waited on
Examples:
db2pd -dbpartitionnum 0,1 -db sample -locks
db2pd -dbp 0,1 -database sample -locks app=<appid>
db2pd -alldbp -alldbs
위와 같이 여러가지 옵션들이 존재를 한다. 필요에 의해서 각각의 옵션을 수행 할 수있으나, 일반적인 상태 모니터링은 다음 옵션으로 충분하다고 생각이 된다.
개인적으로 가장 많이 사용하고 있는 명령이다.
db2pd -db DB이름 -active -agent -appl -transaction -lock -dynamic >> db2pd.out
위의 옵션만을 사용해도 현재 수행중인 Application 및 SQL을 추출 가능하며, Lock으로 인한 문제 발생 시 Lock을 잡고 있는 Application 및 SQL 까지 확인이 가능하다.
간단하게 옵션을 설명하면 Active는 현재 일을 하고 있는 Application 정보를 확인하기 위하여 주는 옵션이며, Agent와 Appl은
O/S 프로세스와 Application을 연관지어 확인하기위해 주는 옵션이다.
트랜잭션 옵션은 DML이 발생하고 있다면, 로그를 가장 많이 사용하고 있는 Application을 확인하기 위해 주는 옵션이며,
lock은 Lock 획득 경합이 발생 할 경우 Holder를 찾기 위함 , dynamic은 수행 SQL을 찾기 위함이다.
그럼 위의 옵션을 이용하여 덤프 파일을 생성 한 후에 해당 파일을 가지고 하나하나 설명을 해 보도록 하자
인위적으로 Lock Waiting을 발생 시킨 후에 db2pd 명령어를 수행 하였다. Lock 경합 발생 시 Holder 찾는 방법 도 같이 나열해야 해서 ^^
테스트로 수행한 db2pd 데이터는 첨부 파일로 첨부 해 놓으니 필요 하신 분은 다운 받아서 옆에 띄워 놓고 같이 체크해 보시길..
첨부 파일은 요기 -->
20091218_1706.out
그럼 현재 수행중인 Application 및 수행 SQL에 대해서 확인 해 보도록 하자.
사용하는 옵션 부분은 Active , Agent , Application , Dynamic SQL 이다.
>> Sample 데이터
atabase Partition 0 -- Database DSSABA -- Active -- Up 24 days 19:39:21
Active Statement List:
Address AppHandl [nod-index] UOW-ID StmtID AnchID StmtUID EffISO EffLockTOut EffDegree StartTime LastRefTime
0xC0000000987F2D20 597 [000-00597] 7459 1 51 3658 2 -2 0 Fri Dec 18 17:06:51 Fri Dec 18 17:06:51
0xC00000009B1FD300 245 [000-00245] 11241905 347 57 6069 1 -2 0 Fri Dec 18 17:06:51 Fri Dec 18 17:06:51
Database Partition 0 -- Active -- Up 24 days 19:39:22
Agents:
Current agents: 239
Idle agents: 0
Active coord agents: 238
Active agents total: 238
Pooled coord agents: 1
Pooled agents total: 1
Address AppHandl [nod-index] AgentPid Priority Type State ClientPid Userid ClientNm Rowsread Rowswrtn LkTmOt DBName
중략...
0xC000000013C464A0 597 [000-00597] 22378 0 Coord Inst-Active 5776 IFRS MaxGauge 309671 1787 NotSet DSSABA
중략..
0xC000000013FE23A0 245 [000-00245] 504 0 Coord Inst-Active 0 db2jcc_a 5875 132651905 NotSet DSSABA
생략..
Applications:
Address AppHandl [nod-index] NumAgents CoorPid Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid
중략..
0xC000000013F4B280 597 [000-00597] 1 22378 UOW-Executing 51 3658 129 46175 172.26.67.139.29456.09121806484
중략..
0xC000000013FCEBA0 245 [000-00245] 1 504 UOW-Executing 57 6069 57 6069 172.17.36.103.49494.09112312312
생략..
Dynamic Cache:
Current Memory Used 8364254
Total Heap Size 8454799
Cache Overflow Flag 0
Number of References 414875062
Number of Statement Inserts 4064416
Number of Statement Deletes 4064260
Number of Variation Inserts 3972846
Number of Statements 156
Dynamic SQL Statements:
Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text
중략...
0xC00000009859E860 57 6069 1 1 24855 8652841 INSERT INTO
XM_SESSION_STAT_DATA (SEQ,DELTATIME,STATID,SIGMA,DELTA) VALUES (?,?,?,?,?)
중략..
0xC000000099D7D900 51 3658 1 1 315975 315975 select max(a.snaptime) as
snaptime from ( select max(snaptime) as snaptime from xm_alertlog where connname = 'DSEEFAS' and snaptime is not null ) a for
read only with ur
생략..
>> Sample 데이터 끝
>> Active Application 정보 확인
그럼 현재 수행중인 Application 정보를 확인해 보자. 현재 수행중인 Application의 AppHandle 값을 가지고 Agent / Application 부분과 조인을 해서 보면 수행중인 Application 정보를 확인 할 수 있다.
제일 위의 Active 부분에서 현재 수행되고 있는 Application이 두개 임을 확인 할 수 있으며 , ApplHandle값이 각각 597 , 245 임을 확인 할 수 있다.
Application Handle이 597인 Application은 Maxgauge 라는 프로그램이라는 것을 알 수 있으며, Application Handle이 245인 Application은 자바 프로세스(db2jcc_a) 임을 확인 할 수 있다.
>> Active SQL 정보 확인
Application을 확인 했으면 , 해당 Application에서 수행 중인 SQL 까지 확인을 할 수 있다.
Application에서 수행중인 SQL을 확인 하기 위해서는 Active 부분의 AnchID StmtUID 값을 이용하거나 , Application 부분의 C-AnchID C-StmtUID 값을 이용하면 된다.
Application 부분에는 현재의 SQL (C-AnchID C-StmtUID ) 과 바로 전에 수행했던 SQL(L-AnchID L-StmtUID )을 찾을 수 있도록 두개의 정보를 제공해 준다.
Application Handle이 597인 Application의 AnchID StmtUID 값을 확인해 보면 51 3658 임을 확인 할 수 있다.
이 값을 가지고 Dynamic 부분에서 조회를 해보면 Maxgauge 라는 프로그램에서 수행중인 SQL은 select max(a.snaptime) as
snaptime from ( select max(snaptime) as snaptime from xm_alertlog where connname = 'DSEEFAS' and snaptime is not null ) a for read only with ur 임을 확인 할 수 있다.
>> Lock 모니터링
위에 Sample 부분에는 꺼내 놓지 않았으나, 첨부 파일을 확인해 보면 Application 부분의 Status가 Lock-Waiting 으로 되어 있는 Application들을 확인 할 수 있을 것이다.
이는 현재 해당 Application들이 Lock을 획득하기 위하여 대기를 하고 있다는 뜻이다. DB 파라메터의 LOCKTIMEOUT 값에 정해진 시간(초) 까지 Lock을 획득하기 위하여 대기를 하며, 그 시간동안 Lock을 획득하지 못하면 자동으로 해당 SQL은 처리 되지 않는다.
그럼 간단히 Application 부분의 제일 위에서 Lock-Waiting을 하고 있는 Application(ApplHandle 714)이 Lock을 대기 하게끔 유발 시킨 Lock Holder를 찾아 보자.
찾는 순서는 Lock 정보 -> Transaction 정보 -> Application 정보 순으로 찾으면 된다.
Lock 정보에서 Sts값이 W 인 것이 Waiting을 하고 있는 정보 들이다. Status가 W인 것의 LockName값을 가지고 동일 LockName의면서 Status값이 G인 Application이 Lock Holder가 된다.
> Sample 데이터
Database Partition 0 -- Database DSSABA -- Active -- Up 24 days 19:39:21
Locks:
Address TranHdl Lockname Type Mode Sts Owner Dur HoldCount Att ReleaseFlg
중략
0xC00000001E91A840 90 0000005F000000000002006E52 Row ..X G 90 1 0 0x08 0x40000000
0xC00000001E75E3C0 388 0000005F000000000002006E52 Row ..U W 0 1 0 0x00 0x40000000
중략
0xC00000001E91B240 90 FFFA8001FFFF00000000000054 Table ..Z G 90 2 0 0x00 0x40000000
0xC00000001E9BCC40 497 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001E9B60C0 623 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001EA03780 669 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001E917080 576 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001E8762C0 132 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001E7EEE80 578 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001E95E900 300 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001E865D40 224 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001E95F780 228 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001E7FAE00 462 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001E7FA100 632 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
0xC00000001E772900 356 FFFA8001FFFF00000000000054 Table .IS W 0 1 0 0x00 0x40000000
중략..
Status가 W인 Lock은 두개임을 확인 할 수 있다. ( 0000005F000000000002006E52 , FFFA8001FFFF00000000000054)
두개의 Lock waiting을 유발 시키는 Transaction handle은 모두 90 임을 확인 할 수 있다.
Database Partition 0 -- Database DSSABA -- Active -- Up 24 days 19:39:21
Transactions:
Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2 Firstlsn Lastlsn LogSpace SpaceReserved TID AxRegCnt GXID
0xC00000001E5FEC80 278 [000-00278] 90 496 COMMIT 0x00000000 0x00000000 0x0AB6B2B70CE5 0x0AB6B2FFC19F 115200 260428 0x00010923434B 1 0
0xC00000009B563880 78 [000-00078] 388 3 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0 0 0x000109234361 1 0
0xC00000009B5C2E80 1107 [000-01107] 497 4 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0 0 0x0001092349A3 1 0
0xC00000009B6C1280 1096 [000-01096] 623 4 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0 0 0x0001092349A9 1 0
0xC00000009B799680 702 [000-00702] 669 4 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0 0 0x0001092349AE 1 0
0xC00000009B698080 714 [000-00714] 576 4 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0 0 0x0001092349AF 1 0
0xC00000009B3A3880 1136 [000-01136] 132 4 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0 0 0x0001092349ED 1 0
0xC00000009B699C80 1098 [000-01098] 578 4 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0 0 0x0001092349E9 1 0
0xC00000009B456880 760 [000-00760] 300 4 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0 0 0x0001092349EE 1 0
0xC00000009B3F4080 1127 [000-01127] 224 4 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0 0 0x0001092349F1 1 0
생략... 많아서 ..
위의 Lock 정보와 Transaction 정보를 이용하면 Lock Waiting을 유발 시키는 Application의 Transaction handle은 90 이며,
Transaction Handle 90인 Application의 Handle은 278 임을 확인 할 수 있다.
Application Handle 714 의 Transaction Handle은 576 이므로 Application 278에 의해서 Lock을 Waiting 하고 있음을 확인 할 수 있다.
Lock 모니터링 뿐만 아니라 Transaction 부분을 모니터링 하게 되면 Log를 가장 많이 사용하고 있는 Application에 대해서도 쉽게 파악을 할 수 있다.
반응형