5. V$SYSSTAT
2010.06.14 08:39
오라클은 성능 측정 지표로서 활용 가능한 항목들을 선정하여 SQL이 실행되는 동안 그 항목들의 누적통계치를저장한다.
- v$sysstat : 인스턴스 기동 후 현재까지 누적된 수행 통계치를 시스템 레벨로 확인.
- v$sesstat : 개별 세션별로 확인
- v$mystat : 현재 접속해 있는 본인 세션에 대헌 수행통계치를 확인.
실행시켜본 결과를 살짝 보면 다음과 같다.
단지, 결과의 숫자만으로는 의미를 알기 힘들다.
(1)시스템 수행 통계 수집 및 분석
위에서 봤듯이, v$sysstat이나 v$sesstat에 나타난 값만으로는 의미있는 결과를 알기 힘들다.
이들은 두 구간사이의 변화량을 분석하는 것으로 어떤 일들이 발생했는가를 판명하는 것이다.
다음과 같은 방법으로 정보수집 스크립트를 만들수도 있다. (해당 SID를 알아야 한다.)
수집용 테이블을 생성한다.
create table sess_stat
as
select 1 no, statistic#, value
from v$sesstat
where sid = 해당SID값;
수집하려는 배치작업이 종료된 후,. 별도 세션에서 다음의 insert문을 실행한다.
insert into sess_stat
select 2 no, statistic#, value
from v$sesstat
where sid = 해당SID값;
다음의 스크립트로 두 구간사이의 증분을 구해 상태를 알아볼수 있다.
위의 insert문을 스케줄러에 등록하여 주기적으로 실행하게 하면 시간대별의 Load Profiling이 가능해진다.
잘 이용해 보시라.
(2)Ratio 기반 성능 분석
위에서 수집된 자료를 이용하여 전반적인 DB건강상태를 체크할수 있다.
아래는 주로이용 되는 항목들이다. (공유리소스사용빈도, 경합발생비율 등)
1. Buffer NoWait %
버퍼블록을 읽으려 할 때, buffer busy waits대기 없이 곧바로 읽기에 성공한 비율을 나타냄.
2. Redo NoWait %
Redo로그를 기록할 공간을 요청하지 않고 곧바로 Redo 엔트리를 기록한 비율을 나타냄.
3. Buffer Hit %
디스크 읽기를 수반하지 않고 버퍼캐시에서 블록찾기에 성공한 비율을 나타냄.
4. Latch Hit %
래치 경합없이 첫번째 시도에서 곧바로 래치를 획득한 비율을 나타냄.
5. Library Hit %
파싱부하와 관련 있는 항목.
라이브러리 캐시에 이미 적재된 SQL커서를 생행하거나 오브젝트정보를 읽으려할 때 커서 또는 오브젝트정보가 Heap영역에서 찾아지는 비율을 나타냄.
6. Soft Parse %
파싱부하와 관련 있는 항목.
실행계획이 라이브러리 캐시에서 찾아져 하드파싱을 일으키지 않고 SQL을 수행한 비율을 나타냄.
7. Execute to Parse %
파싱부하와 관련 있는 항목.
Parse Call없이 곧바로 SQL을 수행한 비율. 즉, 커서를 애플리케이션에서 캐싱한 채 반복 수행한 비율을 나타냄.
8. Parse CPU to Parse Elapsd %
파싱부하와 관련 있는 항목.
파싱 총 소요 시간 중 CPU time이 차지한 비율. 파싱에 소요된 시간 중 실제 일을 수행한 시간비율을 나타냄.
9. % Non-Parse CPU
파싱부하와 관련 있는 항목.
SQL을 수행하면서 사용한 전체 CPU time중 파싱 이외의 작업이 차지한 비율을 나타냄.
10. In-memory Sort %
전체 소트 수행횟수에서 In-Memory방식으로 소트한 비율을 나타냄.
11. Memory Usage %
Shared Pool내에서 현재 사용중인 메모리 비중을 나타냄.
12. % SQL with executions>1
전체 SQL 개수에서 두번이상 수행된 SQL이 차지하는 비중을 나타냄.
13. % Memory for SQL w/exec>1
전체 SQL이 차지하는 메모리 중 두번이상 수행된 SQL이 차지하는 메모리 비중을 나타냄.
<03장 5절 끝>
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
67 | Front Page | 운영자 | 2010.05.17 | 154866 |
66 | 4. Prefetch | balto | 2010.07.10 | 28435 |
65 | 5. 오라클 Lock | 휘휘 | 2010.06.07 | 26368 |
64 | 2. DB 버퍼 캐시 | 휘휘 | 2010.05.24 | 21917 |
63 | 3. SQL 트레이스 | balto | 2010.06.06 | 21175 |
62 | 1. 기본 아키텍처 [1] | 휘휘 | 2010.05.23 | 19903 |
61 | 2. 트랜잭션 수준 읽기 일관성 | 휘휘 | 2010.06.07 | 19568 |
60 | 5. Undo | 토시리 | 2010.05.31 | 18653 |
59 | 11. Shared Pool | 실천하자 | 2010.05.31 | 18511 |
58 | 9. Static vs. Dynamic SQL [1] | balto | 2010.07.04 | 18345 |
57 | 4. Array Processing 활용 | 휘휘 | 2010.07.05 | 18246 |
56 | 1 장. 오라클 아키텍처 | 운영자 | 2010.05.20 | 17845 |
55 | 5. Fetch Call 최소화 | 휘휘 | 2010.07.05 | 16849 |
54 | 9. ASH(Active Session History) | 실천하자 | 2010.06.14 | 15607 |
53 | 2. SQL 처리과정 | 휘휘 | 2010.06.28 | 15343 |
52 | 3. 버퍼 Lock [1] | 휘휘 | 2010.05.24 | 15230 |
51 | 6. 바인드 변수의 부작용과 해법 | 실천하자 | 2010.06.28 | 14670 |
50 | 1. Explain Plan | 실천하자 | 2010.06.06 | 14663 |
49 | 8. PL/SQL 함수 호출 부하 해소 방안 | 토시리 | 2010.07.11 | 14027 |
48 | 7. Result 캐시 | 휘휘 | 2010.07.19 | 12969 |
좋은 자료 담아갑니다