DB2MON 소개
© 2018 IBM Corporation
db2mon 개요
▪ db2mon은 Db2 메모리 메트릭스 모니터링 인터페이스를 사용하여 특정 기간 동안
모니터링 데이터를 수집하는 Db2 명령 행 처리기 (CLP) 스크립트 세트입니다.
- db2mon.sh 쉘 스크립트는 데이터 콜렉션 및 분석 샘플을 제공합니다. 또한 스크립트는
db2mon의 전제 조건이 충족되는지 점검합니다.
- 메모리 메트릭스 모니터링 인터페이스는 ＂MON_GET_DATABASE＂와 같이
＂MON_GET＂으로 시작하는 내장 루틴을 참조합니다.
- MON_GET 함수는 데이터베이스가 활성화 된 시점부터 증가하는 데이터를 반환합니다.
데이터베이스 활동은 별도의 시간에 측정 값을 수집 한 다음 차이를 계산하여 결정됩니다.
db2mon 스크립트는 stored procedure를 사용하여 정보를 수집하고 계산을 자동으로
처리합니다.
2
© 2018 IBM Corporation
db2mon fileset (Db2 v11.1.3.3)
▪ 다음 파일은 db2mon의 일부로 제공되며 인스턴스 디렉토리의 ~ / sqllib / samples / perf
아래에 있습니다.
db2mon.sh
db2mon.sql (db2monBefore.sql, db2monInterval.sql 및 db2monAfter.sql의 연결된
양식)
db2mon_import.sql
db2mon_export.sql
db2mon_report.sql
db2mon은 사용자 임시 테이블 스페이스와 MON_ACT_METRICS 및 MON_REQ_METRICS에
대한 최소 필수 값을 점검합니다. 이 검사의 결과는 보고서의 전제 조건 섹션에보고됩니다.
3
© 2018 IBM Corporation
db2mon.pl (Db2 v11.1.3.3 이전)
▪ db2mon.pl의 perl 코드는 mon_get 함수를 활용하여 특정 기간 동안의 활동을 자동으로
수집하는 SQL 을 생성합니다.
▪ 일반적인 생성 명령은 다음과 같습니다.
perl db2mon.pl <DB2 버전> [수집 지연]
▪ collection delay optional 인수의 기본값은 30 초 입니다.
db2mon.pl을 실행하면 다음 파일이 생성됩니다.
4
© 2018 IBM Corporation
사전 작업
▪ db2mon CLP 스크립트는 데이터베이스에 연결이 필요하며, 또한 db2mon.sql은
데이터베이스에 사용자 임시 테이블 스페이스가 생성되어 있어야 합니다.
▪ 데이터베이스에 사용자 임시 테이블 스페이스가없는 경우, CREATE TABLESPACE 문을
사용하여 작성할 수 있습니다.
DB2 CREATE USER TEMPORARY TABLESPACE myTempTbsp
db2mon.sql 및 db2mon_export.sql이 모니터링 데이터를 올바르게 수집하려면 다음
데이터베이스 구성 매개 변수를 사용하여 데이터베이스 레벨에서 모니터링을 사용
가능하게 해야합니다.
MON_ACT_METRICS, MON_REQ_METRICS 는 최소한 BASE로 설정되어야 합니다.
디폴드 값은 BASE 입니다.
MON_OBJ_METRICS 의 디폴트 값은 EXTENDED이며, 이는 테이블 및 인덱스에 대한
전체 모니터 정보를 제공합니다.
db2mon을 오프라인 모드에서 실행중인 경우, 테이블 및 인덱스를 생성할 수있는 권한이
있어야합니다.
5
© 2018 IBM Corporation
실행 모드
▪ 온라인
db2mon 의 가장 일반적으로 실행하는 모드이며, 완료 될 때까지 모니터링되고있는
시스템에서 표준 출력에 대한 보고서를 작성합니다. 보고서에는 메트릭에서 델타 값을
찾고 출력을 나열하는 데 사용되는 모든 SQL이 포함됩니다. db2mon.sh는 자동으로
데이터베이스에 연결하고, 사용자 임시 테이블 스페이스 및 작은 개인용 버퍼 풀 (시스템에
대한 영향을 최소화하기 위해)을 작성하고 db2mon.sql을 실행 한 다음 연결을 끊습니다.
 db2mon.sh 사용
db2mon.sh mydb > db2mon.out
 기존 연결 사용
db2 –tvf db2mon.sql > db2mon.out
▪ 오프라인
모니터되는 시스템이 성능에 민감한 경우, 내보내기 스크립트를 사용하여 성능
데이터를 수집하고 가져 오기 및보고를 위해 다른 시스템으로 전송할 수 있습니다.
내보내기, 가져 오기 및 보고서 생성을 위해 별도의 SQL 파일이 제공됩니다.
오프라인 모드에서 생성 된 보고서 (db2mon_report.sql 실행)는 온라인 모드에서 생성 된
보고서 (db2mon.sql 실행)보다 짧습니다. 오프라인 모드 보고서는 임시 테이블 (DGTT)
선언 및 델타 계산을 선언하지 않았으므로 더 짧습니다.
6
© 2018 IBM Corporation
온라인 모드 수행
▪ db2mon.sh를 사용 :
- db2mon.sh MyDatabaseName> db2mon.out
MyDatabaseName은 모니터링중인 데이터베이스의 이름입니다. 기본적으로 db2mon.sql은
30 초 동안 MON_GET 데이터를 수집합니다. db2mon.sh는 초 단위로 지정된 다른 기간에
걸쳐 데이터를 수집하기 위해 두 번째 옵션 인수값을 사용합니다.
- db2mon.sh MyDatabaseName 120> db2mon-120s.out
기존 데이터베이스 연결을 사용 :
- db2 -tvf db2mon.sql> db2mon.out
중요 현재 연결에서 db2mon을 실행하고 실행 중 Ctrl-C를 누르는 것과 같이
db2mon.sql을 인터럽트하는 경우, CURRENT SCHEMA 특수 레지스터는 여전히
SESSION_USER로 설정 될 수 있습니다. 결과적으로 인터럽트 이후에 실행되는 모든 SQL
문이 영향을 받을 수 있습니다. 연결이 인터럽트되면 CURRENT SCHEMA를 수동으로 원래
값으로 변경해야합니다. db2mon은 CURRENT SCHEMA를 사용하여 db2mon.sql의 온라인
콜렉션 중에 사용 된 DGTT에 대한 테이블 참조를 분석합니다.
db2mon.sh를 사용하면 CURRENT SCHEMA의 모든 문제점을 피할 수 있습니다.
7
참고 : 보고서 섹션은 "STARTS"텍스트 다음에 시작됩니다.
© 2018 IBM Corporation
오프라인 모드 수행
▪ STEP1 : 모니터링 데이터 export
db2mon_export.sql은 db2mon이 사용하는 모든 MON_GET 함수의 내용을 현재 작업
디렉토리에 작성된 IXF 파일로 반출합니다. 스크립트가 시작될 때와 끝날때 콘텐츠가 두 번
내보내집니다.
- db2 -tvf db2mon_export.sql> db2mon_export.out
▪ STEP2 : 모니터링 데이터 import
IXF 파일을 다른 시스템으로 전송한 후 다른 Db2 데이터베이스에 import 하여 보고서를
작성할 수 있습니다. 보고서는 모든 운영 체제 또는 Db2 버전에서 만들 수 있습니다.
버전 11.1.3.3 이전의 Db2 버전의 경우, db2mon SQL 스크립트도 복사해야합니다.
- db2 -tvf db2mon_import.sql> db2mon_import.out
Db2 IMPORT 유틸리티를 사용하여 분석을 위해 mon_get 데이터를 다시 DB2 테이블로 재구성합니다.
Import 유틸리티에서 테이블이 자동 생성됩니다. (예를 들어, 소스 시스템의 mon_get_workload 버전과
일치하도록 CREATE TABLE을 재 작성할 필요가 없음). import 후 온라인 모니터링과 마찬가지로 델타 값을
계산합니다.
이 테이블은 DGTT가 아닌 영구 테이블입니다. 현재 기본 스키마, 테이블 공간 등에서 생성됩니다. 분석을
위해 다른 시스템으로 이동 한 경우 영구 테이블, 색인 등을 만들 수있는 충분한 권한이 있어야 합니다.
8
© 2018 IBM Corporation
CURRENT SCHEMA를이 모니터링 데이터 세트를 나타내는 값으로 설정하여 여러 데이터 세트를
가질 수
오프라인 모드 수행
▪ STEP3 : report 생성
- db2 -tvf db2mon_report.sql> db2mon_report.out
db2mon_report.sql에 의해 생성 된 보고서는 모든 DGTT 선언 및 델타 계산을 가지고 있지
않기 때문에 db2mon.sql의 출력보다 짧습니다.
참고 : 오프라인 분석을 위해 내보낼 때 db2mon.pl에서 쿼리하기 위해 나열한 테이블뿐만
아니라 거의 모든 테이블에 모든 열을 내 보냅니다. 이는 분석 중에 XYZ 메트릭이 필요하다는
것을 알면 매우 유용합니다.
명령 행에서 추가적 정보 조회를 실행하거나 db2mon_report.sql을 수정하여 오프라인에서
사용할 때 다른 메트릭을 활용하여 보고서 조회를 향상시킬 수 있습니다.
9
© 2018 IBM Corporation
보고서 결과
▪ interval의 시작과 끝에 수집되는 특정 시점 데이터 (현재 실행중인 SQL, 유틸리티 및 잠금
대기와 같은).
▪ 전체 기간에 걸쳐 측정 된 누적 데이터 : 다양한 계층 레벨 (예 : 데이터베이스 레벨, 테이블
스페이스 레벨, 버퍼 풀 레벨, 테이블 레벨, 쿼리 레벨 및 연결 레벨)에서 수집되는 데이터.
▪ 다른 배포 유형 (예 : 표준 Db2 ESE, Db2 pureScale 및 BLU가있는 Db2)에 대해 수집되는
데이터입니다.
▪ 환경 정보 (데이터베이스 및 인스턴스 구성, 레지스트리 변수, CPU 수 및 사용량, 메모리
사용량 등).
10
© 2018 IBM Corporation
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
11
▪
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
REPORT STARTS HERE;
################################################################################################################### ;
Point-in-time data: Current executing SQL, lock waits and utilities at start of capture ;
################################################################################################################### ;
================================================================================= ;
START#EXSQL: Currently executing SQL at start of capture (non-zero metrics only ;
================================================================================= ;
===================================================== ;
START#LOCKW: Current lock waits at start of capture ;
===================================================== ;
================================================================ ;
START#EXUTL: Currently executing utilities at start of capture ;
================================================================ ;
################################################################################################################### ;
Data collected from start to end of monitor interval;
################################################################################################################### ;
================================================ ;
DB#THRUP: Throughput metrics at database level ;
================================================ ;
======================================================================= ;
DB#CLACT: Client activity (active connections have at least 1 stmt/s) ;
======================================================================= ;
================================================================ ;
DB#TIMEB: Time breakdown at database level (wait + processing) ;
================================================================ ;
======================================== ;
DB#WAITT: Wait times at database level ;
======================================== ;
============================================== ;
DB#PROCT: Processing times at database level ;
============================================== ;
========================================= ;
DB#SORT: Sort metrics at database level ;
========================================= ;
==================================================== ;
SQL#TOPEXECT: Top SQL statements by execution time ;
==================================================== ;
========================================================================== ;
SQL#TOPEXECP: Top SQL statements by execution time, aggregated by PLANID ;
========================================================================== ;
============================================ ;
© 2018 IBM Corporation
PKG#EXECT: Time spent executing by package ;
Throughput metrics at database level
▪ 실제로 시스템이 적당한 처리량을 보이고 있는지?
▪ 4 개의 member에서 약 초당 2400 회의 트랜잭션 (CMT_PER_S) 또는 초당 25,000 개의
SQL 문 (ACT_PER_S)을 완료하고 표에 표시된 추가 메트릭을 보여줍니다. 이러한
트랜잭션과 명령문은 35 초 (TS_DELTA)에 걸쳐 측정됩니다.
▪ ACT_PER_S: Activities per second
▪
CMT_PER_S: Commits per second
▪ 12 RB_PER_S: Rollbacks per second
© 2018 IBM Corporation
Time breakdown at database level
▪ 데이터베이스 내 가장 높은 처리 시간을 확인, Compling SQL? Executing SQL?
Committing or rolling back transactions?
▪ PCT_SECTION은 SQL 문의 처리 및 대기 시간을 포함합니다.
이 예에서 대부분의 시간은 섹션 처리 (PCT_SECTION)에 사용되며 다음으로 커밋 처리에
소비 된 시간 (PCT_COMMIT)이 가장 깁니다. 이 패턴은 정상적인 것으로 간주됩니다.
트랜잭션 시스템에서 0.15 (또는 15 %)를 초과하는 컴파일 시간 (PCT_COMPILE)은
parameter marker 대신 literal을 사용하는 응용 프로그램일 수 있습니다.
13
© 2018 IBM Corporation
Wait times at database level
▪ 어디에서 가장 많은 wait time 이 발생하는가?
▪ 여기에서는 로그 쓰기 (PCT_LG_DST) 비트와 Locking 비트에 대해 총 70 %의 대기 시간
(PCT_RQST_WAIT)을 보여 주지만 가장 큰 대기 시간은 CF 통신 (PCT_CF)에서 발생합니다.
14
© 2018 IBM Corporation
Top SQL statements by execution time
▪ 패키지 캐시의 명령문 데이터를 표시합니다. 물론 모니터링 간격 동안 실행 및 실행이 완료된
명령문 실행을 의미합니다. (실행중인 명령문은 보고서 시작 부분의 point-in-time 섹션에
표시)
▪ 전체 활동 시간별 상위 100 개 문이 나열되고 기본 메트릭, 대기 시간, 정렬 및 I / O와
같은보기에 초점을 맞추어 여러 테이블에서 여러 가지 뷰로 표시됩니다.
15
© 2018 IBM Corporation
Wait time breakdown
▪ "Wait time breakdown"섹션에서는 디스크, 래치 및 잠금과 같은 리소스를 기다리고 있기
때문에 실행되지 않는 명령문을 보여줍니다.
▪ Statement and Plan Identifiers
▪ 상위 100 개 문 각각에 대한 EXECUTABLE_ID를 보여줍니다. MON_GET_PKG_CACHE_STMT
함수와 함께 EXECUTABLE_ID를 사용하여 이 명령문에 대한 액세스 플랜을 확보 할 수
있습니다. 다음 명령을 사용하여 EXECUTABLE_ID를 사용하여 Explain 플랜을 결정할 수도
있습니다.
db2 "call explain_from_section (x ＇<executable id>', 'M', NULL, 0, ‘<current
user>',?,?,?,?,?)"
16
© 2018 IBM Corporation
IO statistics per statement
▪ Top100 SQL 의 bufferpool activity
▪ I / O 정보는 명령문이 색인을 사용하는지 여부를 나타낼 수 있습니다. AVG_I_LRD는 실행
당 평균 색인 논리 읽기를 나타냅니다. AVG_D_LRD는 평균 데이터 논리적 읽기를
나타냅니다. 위 예제에서 처음 네 개의 항목은 높은 AVG_I_LRD 값과 AVG_D_LRD 값이
0입니다. 이 값의 조합은 인덱스 기반 계획을 나타냅니다. 명령문에 높은 데이터 논리 읽기
및 낮은 색인 논리 읽기가있는 경우, 색인을 변경하면 성능이 향상 될 수 있습니다.
17
© 2018 IBM Corporation
Database log write time
▪ 예제에서 I / O 당 로그 쓰기 시간 (LOG_WRITE_TIME_PER_IO_MS)은 약 0.4 밀리 초이며
최적입니다. 값은 시스템마다 다르지만 4.0 밀리 초를 초과하는 로그 쓰기 백분율은 저장소
구성 변경이 필요할 수 있음을 나타냅니다. 재구성에는 캐시, RAID 및 파일 시스템 당 LUN
수에 대한 변경 사항이 포함됩니다.
18
© 2018 IBM Corporation
Bufferpool read statistics
▪ 높은 풀 읽기 시간은 "Wait time breakdown for top SQL statements by execution time"섹션의
PCT_POOL_RD 열에 보고됩니다. 이 문제는 시스템이 디스크의 여러 페이지를 버퍼 풀로 읽는
경우에 특히 일반적입니다. 이러한 유형은 일반적으로 데이터베이스 활성화 직후 나 새로운 응용
프로그램이 연결을 시작하는 경우에 발생합니다. 평균 풀 읽기 시간 (AVG_READ_TIME)은 버퍼 풀
레벨과 테이블 스페이스 레벨에서보고됩니다. 마찬가지로 높은 direct I / O 시간 비율은
AVG_DRCT_READ_TIME 및 AVG_DRCT_WRITE_TIME에서 추적 할 수 있습니다.
▪ ㅇ
19
© 2018 IBM Corporation
Latch wait metrics
▪ 래치 대기 시간 백분율은 "Wait times at database level" 및 "Wait time breakdown"의 PCT_LTCH에
보고됩니다. 15 % ~ 20 %보다 높은 래치 대기 시간 비율 (PCT_LTCH)은 높다고 간주됩니다. 예제에서는
유형별 래치 대기 시간에 대한 세부 정보를 보여줍니다.
▪ TIME_PER_LATCH_WAIT_MS에 대한 대부분의 값은 시스템에서 수행중인 모든 에이전트에서 30 초 동안
측정 된 값을 나타내며, 예제 상에는 몇 밀리초 미만으로 래칭 문제가 없음을 확인합니다.
▪ 높은 래치 대기 시간 비율은 다양한 원인에서 발생할 수 있습니다. 래치 대기가 더 중요한 시나리오를
처리하려면 다음 기술을 사용하십시오.
 Db2 pureScale 에서 page reclama wait time
 SQLO_LT_SQLB_HASH_BUCKET_GROUP_HEADER__groupLatch
 SQLB_BPD__bpdLatch
20
© 2018 IBM Corporation
21
© 2018 IBM Corporation