DB2 기초: DB2 UDB 모니터링의 이유 및 방법 (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 샘플 코드  제안 및 의견 피드백

난이도 : 초급

Martin Hubel, Editor, IDUG Solutions Journal

2007 년 4 월 03 일

여러분 조직의 애플리케이션을 구현 및 관리하는 데에는 측정(Measurement)이 필요합니다. Linux™, UNIX™, Windows®용 IBM®DB2® Universal Database™(UDB)에는 문제 결정, 성능 관리, 경향 분석을 위한 기능이 포함되어 있습니다. 이 글에서, Martin Hubel은 이벤트와 스냅샷 모니터를 검사하고, 스냅샷 테이블을 만들고, 스크립트를 통해 스냅샷 테이블을 설치하고, 데이터에서 리포트를 개발하고, 스냅샷에서 나온 결과를 해석하는 방법을 설명하여 조직의 워크로드를 더욱 잘 이해할 수 있도록 합니다.

애플리케이션을 구현 또는 관리할 때, 중요한 것은 좋은 성능을 내는 것이다. 사실, 사용자들은 굳이 요구 사항에 포함되어 있지 않더라도 어느 정도의 성능을 기대하기 마련이다.

다른 것도 아닌 성능을 관리하기 위해서는, 성능 측정이 필요하다. Linux, UNIX, Windows용 DB2 UDB에는 성능 평가 및 시스템 액티비티를 추적하는 많은 장치들이 포함되어 있다. 이러한 장치들은 데이터베이스 관리자(DBA), 애플리케이션 개발자, 시스템 관리자들이 요구하는 각 레벨에 따라 액티비티를 평가하는데 적용된다.

모니터링의 목적

모니터링의 주요한 세 가지 목적은 문제 결정(problem determination), 성능 관리(performance management), 경향 분석(trend analysis)이다. 문제 결정의 의미는 명확하다. 여러분 또는 누군가가 문제를 탐지했고, 여러분은 그 문제를 풀어야 한다. 문제 결정에는 지금 어떤 일이 발생하고 있는지에 대한 인지가 필요하고, 무엇이 원인이고, 최근에 그 문제를 일으켰던 것이 무엇인지를 볼 수 있어야 한다. 성능 관리와 경향 분석(trending)으로도 대부분의 문제들을 피할 수 있다.

성능 관리를 통해 시스템 리소스들을 최적으로 사용할 수 있고, 일부 문제들을 확실히 피할 수 있다. 성능 관리 정보와 기술을 사용하여 문제 결정에 드는 시간을 줄일 수 있고 전체적인 사용자 만족도를 높일 수 있다.

경향 분석은 성능 관리를 또 다른 레벨로 가져간다. 여기에서 그간의 데이터들이 저장되고 사용량 증가와 사용경향을 결정하는데 사용된다. 경향 분석을 통해 전체적인 시스템 액티비티에서 변경 사항들을 규명하는데 도움이 되고 필요할 경우 하드웨어 업그레이드 플래닝에도 도움이 된다. 또한, (경향에서 나타났던 것과는 다른) 예상치 못한 일이 발생한다면, 무엇이 변경되었는지에 대해서도 물을 수 있다.

DB2 사용 경향은 비즈니스 액티비티와 연관되어 있지만 늘 그런 것은 아니다. 비즈니스 단위는 바쁜 주기(busy period)를 알고 있지만, 이것이 시스템 리소스에 미치는 영향에 대해서는 잘 모르고 있다. 시스템 부하 문제의 경우, 시스템 액티비티를 이전날 또는 지난주, 지난달, 지난해의 같은 시기와 비교하여 그 사이의 변화를 알 수 있다. 튜닝 결정, 특히 데이터베이스 매니저와 데이터베이스 설정 매개변수와 관련해서는 사용 경향을 이해하면 큰 도움을 받을 수 있다.

위로

모니터 유형

DB2는 모니터링 목적을 위해, 두 가지 유형의 모니터를 제공하며, 이것은 스냅샷과 이벤트 모니터이다. 스냅샷 모니터들은 정해진 시간 동안의 액티비티를 보여준다. 이것을 시스템 액티비티의 그림이라고 생각할 수도 있다. 어떤 애플리케이션들이 데이터베이스에 연결되었는지를 보여주고, 잠금 문제를 진단하는데 도움이 되며, 버퍼 풀, 테이블 공간, 테이블 사용, 실행중인 statement들을 볼 수 있다. 스냅샷 모니터는 수행된 과정을 기록하고 시간대 별 스냅샷을 비교할 때 훨씬 더 유용하다.

스냅샷과는 달리, 이벤트 모니터는 특정 시간 동안 특정 영역에서 발생하는 모든 상황을 포착한다. 단순한 스냅샷 보다는, 이벤트 모니터는 시간이 흐르면서 발생한 것을 포착한 영화로 생각하면 된다. DB2는 많은 이벤트들의 시작과 끝 시점에서 이벤트 레코드를 만들어 낸다. 스냅샷은 문제가 발생했을 경우 가장 유용하고, 이벤트는 시스템 Chargeback, 리소스 플래닝, 경향 분석과 같은 사용내역과 관련해서 더 정확하다.

DB2 Version 8에서, 히스토리 저장은 이벤트 모니터를 직접 DB2 테이블에 작성하는 새로운 기능과, 스냅샷을 DB2 테이블에 저장하기 위해 스냅샷 테이블 함수들을 사용하는 기능으로 더욱 쉬워졌다.

위로

스냅샷 모니터

스냅샷 모니터를 사용하려면, 먼저 모니터 스위치를 켜고 다음 명령어를 사용한다.

위 명령어를 사용하여 시작해야 하므로 테이블 모니터 스위치와 관련한 예외가 있기는 하지만, 데이터베이스 매니저 설정에서 모니터 스위치를 컨트롤 하는 것도 가능하다.

모니터 스위치의 상태를 체크하려면, Get Monitor Switches 명령어를 사용한다.

다음 차트는 스냅샷 모니터를 켜는 명령어와 수집된 주 정보 유형들이다.

주: 일반적으로, 대부분의 데이터는 DB2에서 이미 내부적으로 사용되기 때문에 스냅샷 스위치를 켜는 것과 관련한 매우 작은 오버헤드가 있다. 이러한 오버헤드 때문에 필요할 때에만 statement 스위치 및 잠금 스위치를 켜두어야 한다. 워크로드에 따라, 모든 스위치를 켜두는 것은 2%에서 5%까지 추가 오버헤드를 불러 일으킬 수 있다.

일단 스위치를 켰다면, 사용 가능한 데이터를 볼 수 있다. 스냅샷을 보려면, GET SNAPSHOT 명령을 사용한다. 그림 3은 DB2 내부 상태를 보여주는 명령어들이다.

명령행에서, 약간의 아웃풋이 생겼다. 이것은 DB2 테이블로 작성할 때의 좋은 점이다. 모니터를 구현하고 데이터를 모은 후에, 몇몇 계산을 통해 유용한 정보를 선별할 수 있다.

위로

고유의 스냅샷 모니터 작성하기

스냅샷을 얻는 것이 비교적 쉽지만, DB2 Version 8의 새로운 table 함수들을 사용해 이를 얻는 방법을 살펴보자. 이 기능은 문제를 파악하는 것뿐만 아니라 성능관리 및 경향 분석도 가능하게 한다.

테이블 함수는 성능 데이터가 select 문을 통해 디스플레이 될 수 있도록 한다. Insert 문이 subselcet와 함께 사용된다면 리턴된 데이터는 DB2 테이블에 저장된다.

다음은 스냅샷 모니터를 작성하는 세 단계이다.

• 스냅샷 테이블을 만든다.
• 스크립트로 스냅샷 테이블을 채운다.
• 데이터에서 리포트를 만든다.

모두 20개의 스냅샷 기능들이 있지만, 네 개의 가장 중요한 것은 데이터베이스, 버퍼 풀, 테이블 공간, 테이블이다. 아래 예제는 버퍼 풀을 사용한다.

스냅샷 테이블 설정하기

스냅샷 테이블을 생성하기 위해, SYSCAT에서 칼럼 정의를 얻을 수 있다. FUNCPARMS 시스템 테이블이 있는데, 이 테이블은 insert 문에서 데이터를 받는다.

-- UPQ020 Create a table to store buffer pool snapshots
-- The snapshot is stored into this table using UPS021 
-- 
-- UPQ022 and following will contain SQL to report from 
-- these tables.
--
CREATE TABLE BP_SNAP (
SNAPSHOT_TIMESTAMP      TIMESTAMP,
POOL_DATA_L_READS        BIGINT,
POOL_DATA_P_READS        BIGINT,
POOL_DATA_WRITES         BIGINT,
POOL_INDEX_L_READS       BIGINT,
POOL_INDEX_P_READS       BIGINT,
POOL_INDEX_WRITES        BIGINT,
POOL_READ_TIME           BIGINT,
POOL_WRITE_TIME          BIGINT,
POOL_ASYNC_DATA_RD       BIGINT,
POOL_ASYNC_DT_WRT        BIGINT,
POOL_ASYNC_IX_WRT        BIGINT,
POOL_ASYNC_READ_TM       BIGINT,
POOL_ASYNC_WR_TIME       BIGINT,
POOL_ASYNC_DT_RDRQ       BIGINT,
DIRECT_READS             BIGINT,
DIRECT_WRITES            BIGINT,
DIRECT_READ_REQS         BIGINT,
DIRECT_WRITE_REQS        BIGINT,
DIRECT_READ_TIME         BIGINT,
DIRECT_WRITE_TIME        BIGINT,
POOL_ASYNC_IX_RDS        BIGINT,
POOL_DATA_TESTORE        BIGINT,
POOL_INDEX_TESTORE       BIGINT,
POOL_INDEX_FESTORE       BIGINT,
POOL_DATA_FESTORE        BIGINT,
UNREAD_PREF_PGS          BIGINT,
FILES_CLOSED             BIGINT,
BP_NAME                  CHAR(18),
DB_NAME                  CHAR(8),
DB_PATH                  VARCHAR(255),
INPUT_DB_ALIAS           CHAR(8) )
In userspace1;

이 DDL은 www.db-hq.net에 공개된 것을 사용할 수 있다. 다음 URL은 네 가지 테이블을 정의하고 있다.

http://www.db-hq.net/Articles/db2luw/perfluw/LUWv8SNP/UPS025.sql

해당 문자열을 복사하여 텍스트 파일에 붙여 넣고 컴퓨터에 저장하며, 다음 명령어를 사용하여 테이블을 생성한다.

db2 -tvf UPS025.sql

스냅샷 테이블 생성하기

하나의 스냅샷을 BP_SNAP 테이블에 저장하려면 다음 SQL을 사용한다.

-- UPQ021 Store a snapshot into a table.
-- The table is created using UPQ020
-- In the near future, this query will be incorporated into a shell script. 
-- 
-- UPQ022 and following will contain SQL to report from 
-- these tables.
--
INSERT INTO BP_SNAP
SELECT 
	SNAPSHOT_TIMESTAMP,
	POOL_DATA_L_READS,
	POOL_DATA_P_READS,
	POOL_DATA_WRITES,
	POOL_INDEX_L_READS,
	POOL_INDEX_P_READS,
	POOL_INDEX_WRITES,
	POOL_READ_TIME,
	POOL_WRITE_TIME,
	POOL_ASYNC_DATA_READS,
	POOL_ASYNC_DATA_WRITES,
	POOL_ASYNC_INDEX_WRITES,
	POOL_ASYNC_READ_TIME,
	POOL_ASYNC_WRITE_TIME,
	POOL_ASYNC_DATA_READ_REQS,
	DIRECT_READS,
	DIRECT_WRITES,
	DIRECT_READ_REQS,
	DIRECT_WRITE_REQS,
	DIRECT_READ_TIME,
	DIRECT_WRITE_TIME,
	POOL_ASYNC_INDEX_READS,
	POOL_DATA_TO_ESTORE,
	POOL_INDEX_TO_ESTORE,
	POOL_INDEX_FROM_ESTORE,
	POOL_DATA_FROM_ESTORE,
	UNREAD_PREFETCH_PAGES,
	FILES_CLOSED,
	BP_NAME,
	DB_NAME,
	DB_PATH,
	INPUT_DB_ALIAS
FROM TABLE( SNAPSHOT_BP( 'perfdb', -1 )) as SNAPSHOT_BP;

지금 단 한 행의 데이터가 존재한다. 보다 유용하게 하려면, 다음 쉘 스크립트를 다운로드 하여, 네 개의 스냅샷 테이블을 만드는데 사용할 수 있다.

http://www.db-hq.net/Articles/db2luw/perfluw/LUWv8SNP/UPS024.sql

스냅샷 아웃풋(output) 해석하기

스냅샷의 여러 측면들이 설명이 필요 없지만, 다른 것들은 약간의 계산이 필요하다.

스냅샷 데이터를 얻는 가장 단순한 쿼리는 다음과 같다.

-- UPQ022 Our first sample query for snapshot data.
--
-- The table is created using UPQ020, and populated using UPQ021
-- In the near future, UPQ021 will be incorporated into a shell script. 
--
SELECT SNAPSHOT_TIMESTAMP AS TSTAMP, POOL_DATA_L_READS AS DATA_LREADS, 
  POOL_DATA_P_READS AS DATA_PREADS, POOL_DATA_WRITES AS DATA_WRITES, 
  POOL_INDEX_L_READS AS IX_LREADS, BP_SNAP.POOL_INDEX_P_READS AS IX_PREADS   
FROM BP_SNAP;

주: 버퍼 풀 튜닝은 DB2 성능을 높일 수 있는 최상의 기회들 중 하나이다. 버퍼 풀 튜닝에 대한 논의는 이 글에서는 하지 않겠지만, 중요한 부분이므로 시간을 들여 공부해 보기 바란다. 아래 Microsoft Excel 워크북 링크는 좋은 자료가 될 것이다. 이 주제에 대한 다른 기술자료들도 검색해 보기 바란다. 다음은 "IBM developerWorks"에 있는 자료들이다.
DB2 기초: 테이블 공간과 버퍼 풀 (한글)
DB2 UDB Version 8.1과 데이터베이스 튜닝의 베스트 프랙티스

명령행에서 가독성 있는 결과를 만들어 내기 위해 모든 칼럼들이 선택되지 않았다. 물론, 예외를 보고하기 위해 SELECT 문의 WHERE 구절에 조건을 넣는 것은 가능하다.

같은 많은 조건들이 버퍼 풀과 테이블 공간에 적용되며, 버퍼 풀은 메모리에 있는 영역이며, 버퍼 풀 측정은 전체적인 성능을 보여준다. 테이블 공간은 파일들이고, 이들에 대한 측정 형태는 개별 성능을 보여준다.

버퍼 풀 계산

DB2 System Monitor Guide and Reference에는 버퍼 풀 효율성을 결정하는데 사용할 수 있는 식들이 포함되어 있다. 나는 이들을 자동화 했고 Excel workbook에 놓았다.

Excel Workbook에는 세 개의 스프레드시트가 포함되어 있다. 첫 번째는 버퍼 풀 성능 비율의 계산이다. 두 번째는 Open Database Connectivity (ODBC)를 통해 Excel로 DB2 데이터를 가져오는 것이다. 세 번째는 그래프 예제로서 엑셀 차팅 장치를 사용한다. 다음은 워크북으로의 링크이다.

http://db-hq.net/downloads/BP%20Analysis.xls

위로

이벤트 모니터

이벤트 모니터를 사용하여 전체적인 액티비티 그림을 얻을 수 있다. 시작부터 끝까지 액티비티를 보여주며, 시작 및 종료 이벤트 레코드로 구성된다. 이벤트 모니터에 대한 가장 일반적인 사용법은 커넥션, 잠금, 문(statement)과 관련된 것이다.

이벤트 모니터 아웃풋(output)은 파일, 네임드 파이프, 그리고 DB2 Version 8 부터 테이블에 작성될 수 있으며, 해당 아웃풋은 blocked 또는 non-blocked가 될 수 있다. 아웃풋이 blocked상태이면, 어떤 데이터 손실도 없지만, 많은 양의 레코드를 만들어 내는 분주한 시스템에는 큰 문제를 일으킬 수 있다. blocked 상태의 아웃풋은 일반적으로 기피되며, 특히 statement 이벤트 모니터의 경우 그렇다. 인스턴스가 충돌될 수 있기 때문이다. 이벤트 모니터를 단일 사용자나 어플리케이션으로 세분화하여 제한 할 수 있다.

네임드 파이프는 여러분이 고유의 프로그램을 작성하여 모니터 데이터를 가져올 경우에 유용하다. unblocked 상태에서 사용하면 바쁜 상태일 경우 DB2에 미치는 영향을 피할 수 있다.

커넥션 이벤트는 사용자 또는 애플리케이션 기반으로 시스템 사용을 트래킹 하는데 유용하다. 이 데이터를 사용하여 좋지 않은 성능을 보이는 프로그램들, 큰 부하를 주는 사용자들, 사용 경향들을 규명할 수 있다. 데이터를 매일 검토하면 사용자들과 함께 액티비티를 논할 수 있고 SQL 교육도 제공하고 물리적인 디자인을 조절하여 그들이 DB2를 사용하는데 더 나은 지원을 할 수 있다.

여러 이벤트 모니터들은 동시에 정의 및 활성화 될 수 있다. 커넥션 이벤트는 문제까지는 일으키지 않는 충분히 적은 양이다. 다음 SQL 문은 모든 연결에 대한 이벤트 모니터를 정의한다.

CREATE EVENT MONITOR dlmon FOR CONNECTIONS WRITE TO TABLE;

일단 이벤트 모니터가 설정되면 다음 명령을 통해 이벤트 모니터를 켜야 한다.

SET EVENT MONITOR dlmon STATE=1; 

이벤트 모니터를 설정하여 데이터베이스가 시작할 때 자동으로 시작하도록 할 수도 있다. 위 문을 실행하면 네 개의 테이블이 생성된다.

• connheader_dlmon
• conn_dlmon
• connmemuse_dlmon
• control_dlmon

주: 버퍼 풀 튜닝은 DB2 성능을 높일 수 있는 최상의 기회들 중 하나이다. 버퍼 풀 튜닝에 대한 논의는 이 글에서는 하지 않겠지만, 중요한 부분이므로 시간을 들여 공부해 보기 바란다. 아래 Microsoft Excel 워크북 링크는 좋은 자료가 될 것이며, 이 주제에 대한 다른 기술자료들도 검색해 보기 바란다. 다음은 IBM developerWorks에 있는 자료들이다.
"DB2 기초: 테이블 공간과 버퍼 풀 (한글)"
"DB2 UDB Version 8.1과 데이터베이스 튜닝의 베스트 프랙티스".

위로

요약

소셜 북마크 mar.gar.in Digg del.icio.us Slashdot

측정은 조직이 DB2를 사용하는 방식을 이해하는데 있어서 핵심이 된다. 정기적으로 성능 데이터를 검토함으로써 조직에서 워크로드를 더욱 잘 이해할 수 있고, 문제가 발생하기 전에 정확한 액션을 취할 수 있다.

기사의 원문보기

• DB2 Basics: The whys and how-tos of DB2 UDB monitoring

위로

다운로드 하십시오

이름	크기	다운로드 방식
bpanalysis.zip	37 KB	FTP|HTTP

	다운로드 방식에 대한 정보

참고자료

DB2 UDB System Monitor Guide and Reference

필자소개

		Martin Hubel 은 독립 컨설턴트로서 DB2 성능, 디자인, 복구 문제 전문가이다. 1994년부터 IBM Gold Consultants 프로그램의 회원으로 있다. IDUG Solutions Journal의 편집자이다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

위로