문제가 발생했을때 자동으로 인지하고 필요한 dump를 수행하도록 해주는 LTOM 입니다.
처음 설정후 사용자는 ltom 기동만 해주면 되니 잘만 쓰면 편리한 툴이죠..
다음의 내용은 OTN에 있는 내용입니다.
제품 : Database
작성날짜 : 2007-12-21
PURPOSE
실시간 성능 자료 취합과 진단하는 LTOM 툴의 사용 방법을 소개한다.
CONTENTS
1. Automatci Hang Detection
2. System Profiler
3. Automatic Session Tracing
4. LTOM 설치하기
5. LTOM 수행하기
6. 부록 - 디렉토리구조
EXPLANATIONS
LiTe Onboard Monitor (LTOM) 은 자바로 개발된 실시간 성능진단툴로 DB 자료뿐만 아니라 UNIX OS 성능자료까지 취합하고, 미리 지정한 룰에따라 Hang 과 Slow Performance 시점을 인지하여 덤프와 트레이스파일 자동 생성해주므로 성능이슈 해결에 소요되는 시간과 리소스를 절감할 수 있다.
DB 또는 OS 성능이슈 진단시 가장 어려운 점은 "문제 발생 시점에" 필요한 "정확한 데이터"를
취합하는 것 자체가 힘들다는 것이다. 특히 언제 발생할지도 모르고, 몇초 단위의 짧은 시간동안만
지속되는 성능이슈라면 재현되기를 기다려서 분석자료를 얻는데만도 많은 리소스와 시간이
소진될뿐더라 거의 불가능한 경우가 많아 여러번의 시행착오를 겪어야한다.
LTOM 은 이런 유형의 성능이슈 해결을 위해 주요 3가지 기능을 제공한다.
. Automatic Hang Detection
. System Profiler
. Automatic Sesssion Tracing
1. Automatci Hang Detection
- 주의! 이 기능은 Oracle Support 나 경험 많은 DBA 의 안내에따라 사용해야한다.
덤프 설정 레벨별로 생성되는 트레이스 양을 인지하고, 시스템에 부하를 테스트 후 적용해야한다.
(1) 용도
v$session 또는 v$session_wait 의 wait event 를 기준으로 hang detect rule 을 설정한다.
예를들어, 새벽 2시 아무도 없을때 갑자기 'latch free' wait event 가 누적되면서 몇초간
DB hang 이 발생하는 경우에는 hang detect rule 을 'latch free' 가 15초 이상 지속되면
systemstate 덤프나 hanganalyze 덤프들을 자동 생성하도록 설정할 수 있다.
(2) 장점
. systemstate 덤프와 hanganalyze 덤프를 문제발생 시점에 사용자 개입없이 자동생성한다
. hang 덤프를 24*7 동안 취합가능하다.
. Automatic Hang Detection 이 발생하면 email notification 을 보낸다.
($TOM_HOME/src/ltommail.sh 에 email 설정)
. 과도한 트레이스 방지위해 동일 hang 이 반복적으로 발생해도 Automatic Hang Detect 설정
후 처음 hang 인지시점에만 덤프를 수행한다.
(3) 설정파일 : $TOM_HOME/init/hangDetect.properties
. 모니터링할 wait event, hang detect time 기준, 생성할 덤프들을 지정한다.
. HangDetect.properties 의 기본적인 덤프생성은 아래 순서이나, 사용자가 순서 및 레벨을
변경할 수 있다.
HangAnalyze Level 3
Systemstate Level 266
Wait 60 seconds
HangAnalyze Level 3
Systemstate Level 266
자세한 설정방법과 설정단위는 LTOM 에 포함된 hangDetect.properties 파일참고.
(4) 결과물
. $TOM_HOME/hanglog/hang*.log : systemstate 덤프 와 hanganalyze 덤프 내용 정리결과
. $TOM_HOME/hanglog/hang*.report : hang detect 히스토리와 생성된 덤프 리스트
. 실제 systemstate 덤프와 hanganalyze 덤프들은 udump 에 생성된다.
(6) 사용예제
TM enqueue wait 이 발생한 경우 Automatic Hang Detect 로 진단하는 절차이다.
. $TOM_HOME/init/hangDetect.properties 파일에 rule 지정 방법
a. 문제가 되는 wait event 와 waiting time 임계치 지정
EVENT= enq: TM - contention,VALUE=15
event name 은 v$event_name 의 event name 과 정확히 일치해야한다.
VALUE=15 는 초단위로 해당 wait event 가 15초이상 지속되면 지정한 덤프를 수행한다.
b. ACTION PLAN 추가
SYSTEMSTATE=266
DELAY=30
HANGANALYZE=4
BLOCKERS=Y
SYSTEMSTATE level 266 => 30초 기다린 후 => HANGANALYZE level 4 => Blocker 덤프
. $./startltom.sh 수행
===> Enter 1 to Start Auto Hang Detection
===> polling 간격 5초 지정
. TM enqueue wait 시나리오 만들기
세션1 연결
$ sqlplus scott/tiger
SQL> lock table junk in exclusive mode;
세션2 연결
$ sqlplus scott/tiger
SQL> lock table junk in exclusive mode;
. 몇분 기다리면 LTOM 화면에도 hang detect 되는 시점에 메시지가 나오고,
$TOM_HOME/hanglog/hang*.report 에도 hang detect 정보가 있다.
. $TOM_HOME/hanglog/hang*.log 에서 systemstate 덤프 정리내용과 hanganalyze 내용을 확인한다.
2. System Profiler
(1) 용도
AWR 과 Statspack 의 단점은 DB 성능이슈 진단시 non-Oracle 프로세스정보와 OS 리소스
(MEMORY, CPU, IO) 에대한 자료가 포함되지 않아 "전체적인 관점(a holistic point of view)"으로
성능이슈를 접근하기 힘들다는 것이다. 더구나 snapshot 들이 "분" 단위이기 때문에, "초" 단위의
일시적인 성능이슈에는 해당시점의 정보만 분리해서 분석할 수 없어서 정확한 원인규명을위해
추가자료를 취합해야한다.
(2) 장점
. DB 성능정보 뿐만아니라 OS 성능정보와 non-Oracle 프로세스 정보까지 포함한다.
. 초단위로 성능정보가 자동 취합된다.
. 결과를 OS 텍스트 파일로 저장하므로 정보취합시 DB 부하 없다
. LTOMg 라는 그래픽 툴로 결과를 확인하고 html 결과 리포트도 생성할 수 있다.
(3) 결과물
. $TOM_HOME/recordings/profile/proXXXXX.log (주기적으로 파일크기 정리 필요)
OS 취합정보 - top, vmstat, iostat
DB 취합정보 - v$session, v$process, v$sesson_wait, v$system_event, v$system_statistics
(4) 사용예제
. System Profiler 시작
$ ./startltom.sh
===> Enter 3 to Start System Profiling
===> Polling frequency = 5
===> Profile Which Oracle Sessions =A
===> Profile Unix Top Processes = Y
===> Profile Unix Vmstat Info = Y
===> Profile Unix Iostat Info = Y
===> Profile CPU Statistics = Y
===> Profile Current SQL Executing = R
===> Profile Which Level = 2
. 10분 후에 System Profiler 종료
===> Enter 4 to Stop System Profiling
. 결과확인
a. $TOM_HOME/recordings/profile 에서 텍스트파일을 직접 열어서 볼수 있다.
b. LTOMg 로 진단 결과를 그래픽하게 확인할 수 있다.
$ cd $TOM_HOME/ltomg
$ java -jar ltomg.jar -i $TOM_HOME/recordings/profile/pro*.log (최종 profile 로그명)
개별그래프를 온라인으로 확인할 수도 있고, "P" 옵션을 선택하면 그래프 및 설명 포함한
HTML 형태 리포트파일이 생성된다. HTML 파일은 $TOM_HOME/ltomg/profile 의 서브디렉토리로
생성되므로 해당 디렉토리에서 HTML 을 열어보거나, 서브디렉토리를 압축해서 다른 시스템으로
이동하여 웹브라우저로 확인하다.
3. Automatic Session Tracing
- 주의! 이 기능은 Oracle Support 나 경험 많은 DBA 의 안내에따라 사용되야 한다.
덤프 설정 레벨별로 생성되는 트레이스 양을 인지하고, 시스템에 부하를 테스트 후 적용해야한다.
(1) 용도
SQL trace 는 DB 성능이슈 진단시 가장 중요한 정보 중 하나이나, 언제 이슈가 발생할지
모르고 발생 전까지는 트레이싱할 세션들을 결정할 수 없을때 기존에는 전체 DB 에
트레이스를 설정하는 위험을 감수했다. Automatic Session Tracing 은 Wait Event ,
CPU 사용량, DB User 기준으로 룰을 미리 설정하여 문제시점을 자동으로 인지하여
해당되는 세션들만 event 10046 level 12 트레이스를 자동 생성한다.
(2) 장점
. 성능이슈 발생 시점에만 10046 트레이싱 한다.
. 특정 Oracle wait event 나 CPU 사용량에따라 트레이스 결정한다.
. 룰에 해당하는 세션중 트레이싱할 세션수를 제한할 수도 있다.
. 성능이슈 원인이 되는 SQL 과 USER 를 쉽게 찾아낼 수 있다.
. 메모리 버퍼 트레이싱하므로 대량 트레이스 파일 생성을 피할 수 있고 문제시점 전후
내용만 트레이스 파일로 생성하므로 디스크 부하가 적다.
. 메모리 버퍼 크기를 지정할 수 있고, 수동으로 메모리 버퍼를 파일로 내릴 수도 있다.
. Automatic Session Tracing exit 할때 트레이싱 중이던 세션들이 자동 tracing off 되나
임의로 세션 트레이스 종료하려면 $TOM_HOME/recordings/session/stopsessions.sql 을
수행하면 된다.
(3) 설정파일 : $TOM_HOME/init/sessionRecorder.properties
sessionRecorder.properties 파일내에 설정방법 & 예제가 포함되어있다.
EVENT=A,VALUE=B,C ====> EVENT 로 룰 설정시
where A = wait event you want to trigger on. The event must match exactly
the event name from v$event_name.
where B = the average wait time to turn on session tracing in microseconds
where C = the average wait time to dump memory tracing to a file in
microseconds. This value only necessary if using in memory
tracing. This value is ignored if you will be tracing to a file.
CPU=,VALUE=B,C ====> CPU 점유로 룰 설정시
where B = the average cpu time to turn on session tracing in 10s of
milliseconds
where C = the average cpu time to dump memory tracing to a file in 10's
of milliseconds. This value only necessary if using in memory
tracing. This value is ignored if you will be tracing to a file.
USER=A ====> DB USER 설정시
where A = db user you want to turn trace on. T
(4) 결과물
. $TOM_HOME/recordings/session - 트레이싱 히스토리
. 실제 트레이스 파일들은 udump, bdump 에 생성된다
(5) 사용예제
<문제상황>
고객사 업무기준에 모든 트랜잭션은 1초안에 끝나야하나 종종 1초이상 지속되는 트랜잭션이 있다.
LTOM 의 System Profile 으로 초단위 모니터링 결과 'global cache cr request' wait event 가
문제시점에 체크되었다. 하지만 1000 여개의 세션 중 어떤 SQL이 문제인지 알기위해 모든 세션에
10046 trace 를 설정하게되면 트레이싱 부하로 정상적인 트랜잭션까지 1초이상 걸리게된다.
<분석방법>
Automatic Session Recorder 가 'global cache cr request' wait event 가 1초이상 지속되는 시점에 해당 세션들을 트레이싱하게 설정한다. 이 방법은 전체 세션에 계속 10046 트레이스를 설정하는 것에 비하면 부하가 현저히 줄어든다.
<설정절차>
. 룰 지정
a. $TOM_HOME/init/sessionRecorder.properties 에 추가
EVENT=global cache cr request, VALUE=100000,1000000
event name 은 v$event_name 에있는 event name 과 space 까지 정확히 일치해야함.
VALUE 단위는 microsecond(1/1000000초)이고 100000(0.1초)는 메모리 트레이싱 시작 기준,
1000000(1초)은 메모리를 파일로 내리는 기준이다.
b. $ ./startltom.sh 수행
===> Enter 7 to Start Session Tracing
===> Enter a polling frequency in seconds : default 5초
===> Trace sessions to memory or file : default M to memory
===> Enter amount of memory for each trace buffer in bytes :
세션당 사용할 트레이싱 버퍼 지정 default 50000 bytes
===> Enter max processes to trace : 5-10 세션정도로 지정
c. 트레이싱 세션정보 LTOM 화면에서 모니터링
Enter 71 to Display Sessions Traced
Enter 72 to Dump All Trace Buffers
Enter 73 to Dump Specific Trace Buffer
Select option 74 to stop a specific session from being traced
d. 트레이싱 종료
===> Enter 8 to Stop Session Tracing
e. 각 10046 트레이스는 bdump, udump 에서 확인
4. LTOM 설치하기
(1) Supported Platforms: Solaris, Linux, HP-UX, AIX, Tru64
(2) 다운로드 : Metalink 에서 Note 352363.1 에 링크있음.
(3) 압축풀기
uncompress ltom.tar.Z
tar xvfp ltom.tar
(4) 초기화 : ~/ltom/tom_base/install/autoinstall.sh 수행
5. LTOM 수행하기
$ cd ~/tom_base/tom ($TOM_HOME)
$ ./startltom.sh
menu example
Enter 1 to Start Auto Hang Detection
Enter 2 to Stop Auto Hang Detection
Enter 3 to Start System Profiling
Enter 4 to Stop System Profiling
Enter 7 to Start Session Tracing
Enter 71 to Display Sessions Traced
Enter 72 to Dump All Trace Buffers
Enter 73 to Dump Specific Trace Buffer
Enter 8 to Stop Session Tracing
Enter S to Update status
Enter Q to End Program
CURRENT STATUS: HangDetection=OFF ManRec=OFF SessionRec=OFF
Please Select an Option:
6. 부록 - 디렉토리구조
tom_base /install - 설치관련 파일들
/tom /ltomg /gif - ltomg 결과 gif 파일들
/src - ltomg source 파일들
/profile - html 결과 파일들
/init - 환경설정 파일들
/hanglog - Automatic Hang Detection 시 생성 로그
/recordings /event - 사용안함
/profile - System Profiler 결과
/smart - 사용안함
/session - Automatic Session Tracing 로그
/src - ltom 용 SQL과 shell scripts
/tmp - ltom 용 임시파일
References
Note 352363.1 : LTOM - The On-Board Monitor User Guide
Note.461052.1 : LTOM System Profiler - Sample Output
Note 461050.1 : The LTOM Graph (LTOMg) User Guide
Note.461228.1 : The LTOM Graph FAQ
'Oracle Database' 카테고리의 다른 글
Rolling Cursor Invalidations with DBMS_STATS in Oracle10g (0) | 2009.02.01 |
---|---|
DICTIONARY MANAGED TABLESPACE를 사용 대비, LOCALLY MANAGED TABLESPACE를 사용하는 것의 장점 (0) | 2009.01.31 |
job이 자동으로 수행이 안될때 checklist (0) | 2009.01.23 |
Linux, iSCSI 환경에서 Oracle RAC 10g Release 2 클러스터 설치하기 [펌] (0) | 2009.01.20 |
지금 수행 중인 smon recovery를 더 빠르게 할 수는 없을까? (0) | 2009.01.19 |