태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

[티팩] Session Snapshot Report - Part 2

오라클 2010.08.04 14:13
얼마전 오라클에서 가장 가벼운 작업은?이라는 퀴즈를 낸 적이 있었습니다. 그 때 답변으로 제시된 것은 이것입니다.
begin 
   null;
end;
/
의문을 가질 수 있습니다? 정말 제일 가벼운가? 얼마나 가벼운가? 특히 { select 1 from dual (fast dual일 경우) }와 비교하면 어떠한가?

이런 의문에 답을 할 수 있는 제일 좋은 도구가 티팩이 제공하는 Session Snapshot Report입니다. Session Snapshot Report는 V$SES[SYS]STAT, V$LATCH, V$SES[SYS]_TIME_MODEL, V$SESSION[SYSTEM]_EVENT 등 성능 분석에 필요한 핵심적인 뷰들에 대한 비교를 가능하게 해주기 때문입니다.

Session Snapshot Report를 이용해서 { select 1 from dual }{ begin null; end; }의 성능이 어떤 차이를 보이는지 분석해보겠습니다.

1. 두 경우를 루프를 돌면서 각각 100,000번 수행하고 그 차이를 Session Snapshot Report를 통해 분석해보겠습니다.

TPACK@ukja1021> exec tpack.begin_session_snapshot;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.09
TPACK@ukja1021> 
TPACK@ukja1021> declare
  2  	     v1      number;
  3  begin
  4  	     for idx in 1 .. 100000 loop
  5  		     select 1 into v1 from dual;
  6  	     end loop;
  7  end;
  8  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:02.70
TPACK@ukja1021> 
TPACK@ukja1021> exec tpack.add_session_snapshot;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.09
TPACK@ukja1021> 
TPACK@ukja1021> declare
  2  	     v1      number;
  3  begin
  4  	     for idx in 1 .. 100000 loop
  5  		     begin null; end;
  6  	     end loop;
  7  end;
  8  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
TPACK@ukja1021> 
TPACK@ukja1021> exec tpack.add_session_snapshot;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.10
TPACK@ukja1021> 
TPACK@ukja1021> col type format a10
TPACK@ukja1021> col item format a40
TPACK@ukja1021> col deltas format a20
TPACK@ukja1021> select type, item, deltas from table(tpack.session_snapshot_report);
Report는 아래와 같습니다(큰 차이를 보이는 부분만 편집). Call수, Execute Count, Time, Library Cache 래치와 Library Cache Pin의 획득 개수에서 { select 1 from dual }이 압도적으로 불리한 것을 알 수 있습니다. { begin null; end; }가 가장 가벼운 작업이라는 것이 증명된 것일까요?
TYPE       ITEM                                     DELTAS
---------- ---------------------------------------- --------------------
STAT       recursive calls                          100038->36
STAT       calls to get snapshot scn: kcmgss        100024->23
STAT       execute count                            100014->14

TIME       DB time                                  2792453->97955
TIME       sql execute elapsed time                 2791349->96441
TIME       DB CPU                                   2792453->92407

LATCH      library cache                            200066->56
LATCH      library cache pin                        200046->40
사실 위의 테스트는 함정을 가지고 있습니다. PL/SQL 블록내에서 수행되기 때문에 일반적인 쿼리의 수행 패턴이 아니라는 함정입니다. 일반적인 쿼리는 클라이언트에서 SQL*Net을 통해 쿼리를 수행 요청하고, 서버는 그 결과 중 일부를 클라이언트에게 보내주고, 클라이언트는 다시 다음 번 결과를 요청(페치)하는 일련의 과정을 거칩니다.

2. 이 함정을 피하기 위해 다음과 같이 개별 쿼리를 각각 10,000번씩 수행하도록 스크립트를 생성합니다.

spool select_dual.sql
select 
	'select 1 from dual; '
from dual 
connect by level <= 10000;
spool off


spool null.sql
select 
	'begin null; end; ' || chr(10) || '/'
from dual 
connect by level <= 10000;
spool off
3. 위에서 생성한 스크립트를 이용해 동일한 성능 비교를 수행합니다.
TPACK@ukja1021> exec tpack.begin_session_snapshot;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.10
TPACK@ukja1021> 
TPACK@ukja1021> @select_dual
...

TPACK@ukja1021> exec tpack.add_session_snapshot;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.09
TPACK@ukja1021> 
TPACK@ukja1021> @null
...

TPACK@ukja1021> exec tpack.add_session_snapshot;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.09
TPACK@ukja1021> 
TPACK@ukja1021> col type format a10
TPACK@ukja1021> col item format a40
TPACK@ukja1021> col deltas format a20
TPACK@ukja1021> select type, item, deltas from table(tpack.session_snapshot_report);
Report는 아래와 같습니다(큰 차이를 보이는 부분만 편집). 전혀 다른 모습을 보입니다.
  • User Calls 수에서는 { select 1 from dual }이 더 많습니다.
  • Network을 통한 데이터 전송도 { select 1 from dual }이 더 많습니다. 한건이라고는 사지만 페치가 이루어지기 때문입니다.
  • Execute Count는 동일합니다. 앞서의 비교에서는 { select 1 from dual }의 Execute Count가 훨씬 많았던 것과는 차이가 있습니다.
  • 수행 시간(DB time)의 차이도 크게 줄었습니다. 시간면에서의 차이는 거의 없다고 보입니다.
  • 재미있는 것은 { begin null; end; }가 Library Cache 래치를 두 배 정도 더 획득한다는 것입니다.
TYPE       ITEM                                     DELTAS
---------- ---------------------------------------- --------------------
STAT       bytes sent via SQL*Net to client         4040131->1310178
STAT       user calls                               30002->20002
STAT       SQL*Net roundtrips to/from client        20001->10001
STAT       execute count                            10013->10012
STAT       parse count (total)                      10001->10002
STAT       opened cursors cumulative                10001->10001
STAT       session cursor cache hits                10001->10000

TIME       DB time                                  1236939->1005865
TIME       DB CPU                                   1236939->1000893
TIME       sql execute elapsed time                 515669->437225

LATCH      session idle bit                         60023->40016
LATCH      library cache                            20309->40089
LATCH      library cache pin                        20168->40062
테스트 방식에 따라 전혀 의외의 결과가 나온다는 것을 알 수 있습니다. 실제로 쿼리가 수행되는 방식으로 시뮬레이션해보면 두 경우의 성능 차이가 생각보다 그렇게 크지 않다고 할 수 있습니다. 그 이유는 서버에서의 작업보다는 클라이언트와의 통신에서 발생하는 부하가 더 비중이 높기 때문이라고 볼 수 있습니다.

여기서 한가지 의문을 가질 수 있습니다.

{ begin null; end; } 가 오라클에서 가장 가벼운 작업이라는 것은 올바른 답인가? 여러분들의 판단은 어떤 것인가요?

PS) 이 포스트의 목적은 티팩의 Session Snapshot Report의 효용성을 설명하기 위한 것입니다. 무엇이 가장 가벼운 작업인가는 사실 중요한 것이 아니죠. 그것이 가장 가벼운 작업인지를 어떻게 증명하느냐가 핵심입니다.

이전 글 보기

  1. [티팩] 성능 문제를 트러블슈팅하는 두가지 틀(Frame)
  2. [티팩] oradebug
  3. [티팩] [티팩] 지능적 대기 이벤트 분석 - Part 1
  4. [티팩] [티팩] 지능적 대기 이벤트 분석 - Part 2 (핫 블록?)
  5. [티팩] 지능적인 대기 이벤트 분석 - Part3. (대기이벤트 프로파일링)
  6. [티팩] Session Snapshot Report - Part 1
저작자 표시
신고
tags :
Trackback 0 : Comment 0

Write a comment

티스토리 툴바