성능 관련 기능

행(hang) 상태의 시스템을 위한 "Memory-Attached” SGA Query

Oracle Enterprise Manager를 이용하여 성능 이슈를 진단하고 해결하고 있는 한 관리자가 있습니다. 어느 날, 골치 아픈 문제가 발생했습니다. 엉성하게 설계된 애플리케이션으로 인해 심각한 라이브러리-캐시 락(lock)이 발생하고 데이터베이스가 행(hang) 상태로 떨어진 것입니다. 관리자는 문제의 주범이 되는 세션을 확인하여 신속하게 제거해야 합니다.

이 문제를 해결하기 위해 Oracle Enterprise Manager를 사용할 수도 있을 것입니다. 하지만 잠깐! 데이터베이스의 동작이 거의 멈추어버린 상태인데 Oracle Enterprise Manager에서 쿼리를 해서 그 결과를 확인할 수 있을까요

Oracle Database 10g Release 2를 사용하는 환경이라면 가능합니다. 이 시리즈의 제 2 부에서 설명한 것처럼, “Memory Access Mode” 옵션을 이용하면 V$SESSION에 쿼리를 하는 대신 SGA 메모리에 직접 액세스할 수 있습니다. “Memory Access Mode”는 SQL 계층을 우회하는 방식으로 동작하며, 따라서 데이터베이스가 행 상태라 하더라도 쿼리는 실행 가능합니다.

그 방법이 다음과 같습니다: Enterprise Manager 스크린에서 performance 탭을 선택하고 “Additional Monitoring Links” 섹션이 위치한 페이지 하단으로 스크롤합니다 (아래 그림 참조)

"Hang Analysis" 링크를 클릭하면 아래와 같은 스크린이 표시됩니다.

위 그림에서 동작이 멈추어 버린 “frozen” 세션의 맵을 확인할 수 있습니다. 위 예에서는 SID 193의 루트 세션(root session)이 다른 두 개의 세션(192와 214)의 실행을 가로막고 있음을 알 수 있습니다. 각 세션의 색깔을 통해, 세션이 얼마나 오랜 시간 동안 실행 중단되었는지 알 수 있습니다. SID를 클릭하면 Session Details 스크린이 뜨고, 더 자세한 정보가 표시됩니다.

ORADEBUG 유틸리티를 기억하십니까 Oracle Enterprise Manager는 ORADEBUG 유틸리티를 이용해서 시스템 행(system hang)에 관련한 데이터를 수집합니다. SGA 영역에 직접 액세스하는 경우, 오라클은 인스턴스 별로 하나의 SQL 컬렉터(SQL collector)를 사용합니다. 이 컬렉터는 Enterprise Manager가 시작할 때 자동으로 시작되며, 다음과 같은 뷰로부터 데이터를 가져옵니다:

V$SESSION

V$SESSION_WAIT

V$SYSTEM_EVENT

V$SYSSTAT

“Memory-attached” SGA 쿼리는, 최소한 한 번쯤은 관리자의 위기를 모면할 수 있게 해 주는 매우 강력하고 유용한 기능입니다. 애플리케이션으로 인해 데이터베이스의 성능이 저하되는 현상은 비일비재하며, 사람들은 그 이유를 줄곧 묻고는 합니다. 필자는 Release 2에서 DBA에게 가장 유용한 기능으로 “Memory-attached” SGA 쿼리를 꼽겠습니다.

SQL Access Advisor의 중간 결과 확인하기

Oracle Database 10g의 SQL Access Advisor에 대해서는 모두들 잘 알고 계시리라 생각합니다. SQL Access Advisor는 인덱스와 MV(materialized view)의 분석을 통해 SQL 워크로드를 자동으로 튜닝하고 SQL 성능을 개선시켜 줍니다.

하지만 이런 경우가 있을 수 있습니다: 성능 문제가 있음을 발견한 관리자가 일련의 SQL 구문에 대해 SQL Access Advisor를 실행하려 합니다. 보다 정확한 분석을 위해, 관리자는 “Comprehensive mode” 옵션을 선택하고 프로그램을 실행합니다. 분석 대상이 되는 SQL 워크로드의 규모가 큰 경우 (구문의 수가 수백 개에 이르는 경우), 또는 SQL 구문이 복잡한 구조를 갖는 경우, 대기 시간은 길어질 수 밖에 없습니다. 하지만 사용자는 당장 문제를 해결해 달라고 관리자에게 재촉하고 있습니다. 어떻게 해야 할까요

Oracle Database 10g Release 2에서는 어드바이저의 실행을 중단하고, 지금까지 확인된 권고사항 및 분석내용을 조회하는 것이 가능합니다. SQL Tuning Advisor의 경우에는 이와 같은 기능이 Release 1부터 제공되고 있었습니다.

실행 방법은 다음과 같습니다. 먼저 Advisor Central 스크린에서 SQL Access Advisor 링크를 클릭합니다.

“Actions” 드롭다운 메뉴에서 “Interrupt”를 선택한 후 Go 버튼을 클릭합니다. 이렇게 하면 SQL Access Advisor의 실행을 중단하고 지금까지 분석된 권고사항을 바로 확인할 수 있습니다. 물론 그 내용은 완전하지 않겠지만, 사용자의 요구사항을 들어주기에는 충분한 수준인 경우가 대부분입니다.

Oracle Enterprise Manager 대신 SQL Access Advisor의 커맨드라인 버전을 사용하는 경우에는, 새로 추가된 V$ADVISOR_pROGRESS 뷰를 이용할 수 있습니다:

SQL> desc v$advisor_progress

 Name                                      Null    Type

 ----------------------------------------- -------- -----------

 SID                                                NUMBER

 SERIAL#                                            NUMBER

 USERNAME                                           VARCHAR2(30)

 OpNAME                                             VARCHAR2(64)

 ADVISOR_NAME                                       VARCHAR2(64)

 TASK_ID                                            NUMBER

 TARGET_DESC                                        VARCHAR2(32)

 SOFAR                                              NUMBER

 TOTALWORK                                          NUMBER

 UNITS                                              VARCHAR2(32)

 BENEFIT_SOFAR                                      NUMBER

 BENEFIT_MAX                                        NUMBER

 FINDINGS                                           NUMBER

 RECOMMENDATIONS                                    NUMBER

 TIME_REMAINING                                     NUMBER

 START_TIME                                         DATE

 LAST_UpDATE_TIME                                   DATE

 ELApSED_SECONDS                                    NUMBER

 ADVISOR_METRIC1                                    NUMBER

 METRIC1_DESC                                       VARCHAR2(64)

TOTALWORK 컬럼과 SOFAR 컬럼을 비교하면 작업이 몇 퍼센트 가량 진행되었는지 확인할 수 있습니다. (V$SESSION_LONGOpS 뷰를 통해서도 유사한 결과를 확인할 수 있습니다.)

트레이스 활성화 여부의 확인

세션이 정상적으로 실행되지 않거나 느려진 경우, 대부분의 DBA는 가장 먼저 wait 이벤트를 점검합니다. 또 프로파일을 만들기 위해서는 오랜 시간에 걸쳐 세션에 대한 트레이스(trace) 작업을 수행하고 그 결과로 얻어진 트레이스 파일을 user_dump_dest 디렉토리에 저장해야 합니다.

그렇다면 여러 세션에 대해 엔드-투-엔드 트레이스를 사용하고 있었는데, 어떤 세션에 트레이스를 적용했는지 잊어버렸다면 어떻게 해야 할까요

트레이스 파일을 일일이 조회하여 SID 컬럼과 Serial# 컬럼을 확인하고, 이 값을 V$SESSION 뷰와 비교하는 것도 한 가지 방법입니다. 말할 필요도 없는 얘기지만, 이러한 방법은 복잡하고 까다로울 뿐 아니라 실수의 가능성이 높습니다. Oracle Database 10g Release 2에서는 보다 세련되고 편리한 방법이 제공됩니다. 관리자는 V$SESSION의 내용을 확인하기만 하면 됩니다.

트레이스 상태의 확인을 위해 추가된 3개의 컬럼이 다음과 같습니다:

• sql_trace - (ENABLED/DISABLED) 해당 세션의 SQL 트레이스 활성화 여부를 표시합니다.
• sql_trace_waits - (TRUE/FALSE) 세션 트레이스가 활성화된 경우, “trace write wait” 정보를 트레이스 파일에 함께
  기록할 수 있습니다. 이 정보는 성능 진단 과정에서 매우 유용하게 활용됩니다.
• sql_trace_binds - (TRUE/FALSE) 세션이 바인드 변수(bind variable)을 사용하는 경우, 바인드 변수의 값을 트레이스
  파일에 함께 저장할 수 있습니다.

세션의 트레이스가 활성화되지 않은 상황에서 아래와 같이 쿼리를 수행한다고 가정해 봅시다:

select sid, serial#, sql_trace, sql_trace_waits, sql_trace_binds

from v$session

where username = 'HR'The output is:

       SID    SERIAL# SQL_TRAC SQL_T SQL_T

---------- ---------- -------- ----- -----

       196      60960 DISABLED FALSE FALSE

따라서 SID 196, Serial# 60960을 갖는 세션에 트레이스가 활성화되어 있지 않음을 알 수 있습니다.

이번에는 (바인드 변수의 트레이스는 활성화하지 않고) wait 이벤트의 트레이스를 활성화해 봅시다. dbms_monitor 패키지를 사용하여 트레이스를 활성화할 수 있습니다.

begin

   dbms_monitor.session_trace_enable (

      session_id   => 196,

      serial_num   => 60960,

      waits        => true,

      binds        => false

   );

end;

/

그리고 다시 세션 정보를 조회해 봅시다

select sid, serial#, sql_trace, sql_trace_waits, sql_trace_binds

from v$session

where username = 'HR'

쿼리 결과가 다음과 같습니다:

       SID    SERIAL# SQL_TRAC SQL_T SQL_T

---------- ---------- -------- ----- -----

       196      60960 ENABLED  TRUE  FALSE

dbms_monitor 패키지의 session_trace_enable 프로시저를 통해 트레이스를 활성화한 경우에만 V$SESSION 뷰에 데이터가 생성되며, “alter session set sql_trace = true” 명령 또는 10046 이벤트를 설정한 경우에는 데이터가 생성되지 않음을 참고하시기 바랍니다. 사용자는 위와 같은 쿼리를 이용하여 어떤 세션에 트레이스가 적용되었는지 확인할 수 있습니다.

dbms_monitor 패키지의 다른 프로시저(SERV_MOD_ACT_TRACE_ENABLE 또는 CliENT_ID_TRACE_ENABLE)를 이용하여 트레이스를 활성화한 경우에는, V$SESSION 뷰에서 정보를 확인할 수 없으며, 그 대신 DBA_ENABLED_TRACES 뷰를 조회해야 합니다. 세션의 트레이스 적용여부를 확인하기 위해 아래와 같이 UNION 구문을 사용할 수도 있습니다:

SELECT *

  FROM (SELECT SID, 'SESSION_TRACE' trace_type

          FROM v$session

         WHERE sql_trace = 'ENABLED')

UNION

(SELECT SID, t.trace_type

   FROM v$session s, dba_enabled_traces t

  WHERE t.trace_type = 'CliENT_ID' AND s.client_identifier = t.primary_id)

UNION

(SELECT SID, t.trace_type

   FROM v$session s, dba_enabled_traces t, v$instance i

  WHERE t.trace_type = 'SERVICE'

    AND s.service_name = t.primary_id

    AND (t.instance_name IS NulL OR t.instance_name = i.instance_name))

UNION

(SELECT SID, t.trace_type

   FROM v$session s, dba_enabled_traces t, v$instance i

  WHERE t.trace_type = 'SERVICE_MODulE'

    AND s.service_name = t.primary_id

    AND s.module = t.qualifier_id1

    AND (t.instance_name IS NulL OR t.instance_name = i.instance_name))

UNION

(SELECT SID, t.trace_type

   FROM v$session s, dba_enabled_traces t, v$instance i

  WHERE t.trace_type = 'SERVICE_MODulE_ACTION'

    AND s.service_name = t.primary_id

    AND s.module = t.qualifier_id1

    AND s.action = t.qualifier_id2

    AND (t.instance_name IS NulL OR t.instance_name = i.instance_name))

UNION

(SELECT SID, t.trace_type

   FROM v$session s, dba_enabled_traces t, v$instance i

  WHERE t.trace_type = 'DATABASE'

    AND (t.instance_name IS NulL OR t.instance_name = i.instance_name))

실행 결과가 아래와 같습니다:

       SID TRACE_TYpE

---------- ---------------------

       136 SERVICE_MODulE

       136 SERVICE_MODulE_ACTION

세션 136에 대해 Service Module과 Service Module Action의 트레이스가 활성화되었음을 알 수 있습니다. 단, DBA_ENABLED_TRACES 뷰에서는 바인드 변수 또는 wait 이벤트의 트레이스 여부를 확인할 수 없습니다.

Activity Session History

이미 독자 여러분도 Automatic Workload Repository (AWR)의 유용성에 대해 잘 이해하고 계시리라 믿습니다. (자세한 정보가 필요하신 경우 AWR을 주제로 한 OTN 아티클을 참고하시기 바랍니다.) AWR은 사용자 또는 시스템 레벨에서 워크로드에 관련한 성능 데이터를 캡처하고, 일정한 주기로 디멘션, 메트릭, OS 통계, ASH 데이터를 기준으로 한 성능통계정보를 제공합니다.

Activity Session History (ASH)는 최근 사용된 세션에 관련한 히스토리 정보로, 메모리 상의 순환구조 버퍼에 캡처된 후 AWR에 기록되는 방식으로 효율성을 최대화하고 오버헤드를 최소화하도록 설계되었습니다. ASH 데이터는 TOp SQL, 오브젝트 파일, 세션, 모듈, 액션 등의 디멘션 별로 롤업(roll-up)이 가능합니다.

하지만 대부분의 경우, DBA는 현재 진행중인 성능 문제에 대해 진단을 수행해야 합니다 ASH 리포트가 추가되었습니다. ASH 리포트는 전체 데이터베이스 또는 특정 세션, SQL ID, 모듈, 액션을 기준으로 한 성능 정보를 제공합니다.

ASH 리포트는 Oracle Enterprise Manager의 Database 페이지를 통해 접근할 수 있습니다. performance 탭을 클릭하면 다음과 같은 스크린이 표시됩니다:

(붉은색 원 안의) “Run ASH Report” 버튼을 클릭하면 Active Session History 리포트 메뉴가 표시됩니다:

위 스크린을 통해 리포트의 시작 일시와 종료 일시를 입력하고, 우측 상단의 “Generate Report” 버튼을 클릭합니다. (디폴트 리포트 주기는 5 분으로 설정되어 있습니다.)

버튼을 클릭하면, 해당 시간대의 ASH 리포트를 확인할 수 있습니다. 주의 깊게 살펴보면, 리포트의 내용이 STASpACK 리포트와 매우 유사하다는 것을 알 수 있을 것입니다. 하지만 ASH 리포트는 AWR 데이터를 이용하여 생성되었으므로 유용성 면에서 STASpACK 리포트에 비해 훨씬 뛰어납니다. 아래 그림은 ASH 리포트의 일부를 보여 주고 있습니다:

"Save to File” 버튼을 클릭하면 리포트를 파일에 저장하고 나중에 다시 참고할 수 있습니다.

"ASH Report" 섹션의 링크들을 주목하시기 바랍니다. 여기에서는 다양한 유형의 성능관련 통계정보를 한눈에 조회할 수 있습니다. 예를 들어 “Top Events” 링크를 클릭하면 해당 기간의 주요 이벤트를 확인할 수 있습니다. 해당 기간에 성능 문제가 발생했다면, 이 정보가 큰 도움이 될 수 있을 것입니다. ASH 리포트의 각 디멘션 별로 표시되는 그래프의 급격한 변화 양상을 기준으로 성능병목의 발생시점을 판단할 수 있습니다.

이 리포트는 상황에 따라 AWR로부터 데이터를 가져올 수도 있고, 인메모리 버퍼(in-memory buffer)로부터 데이터를 가져올 수도 있다는 사실을 기억하시기 바랍니다. 따라서 과거에 발생한 성능 문제를 확인하고자 하는 경우에도 해당 기간에 대한 ASH 리포트를 활용할 수 있습니다.

ASH 리포트는 커맨드라인을 통해 실행할 수도 있습니다. 스크립트의 위치는 다음과 같습니다:
$OH/rdbms/admin/ashrpt.sql

옵티마이저 통계정보 관리

Oracle Database 10g는 옵티마이저 통계정보의 관리에 관련한 다양한 기능을 제공합니다. 통계정보의 덮어쓰기를 방지하기 위한 락다운 기능이 그 한 예입니다. 이러한 기능들을 이용하여 옵티마이저 통계 정보를 수집하고 관리하는 작업을 한층 용이하게 할 수 있습니다. Oracle Database 10g Release 2에서는 이 기능을 Oracle Enterprise Manager에서도 사용할 수 있습니다.

먼저 Database 홈 페이지에서 Administration 탭을 클릭합니다. “Statistics Management” 섹션에서 "Manage Optimizer Statistics” 링크를 확인하실 수 있을 것입니다.

이 링크를 클릭하면 "Manage Optimizer Statistics” 페이지가 표시됩니다.

스크린의 오른쪽 링크들을 이용하여 통계정보와 관련한 여러 가지 작업을 수행할 수 있습니다. 예를 들어, Configure 버튼을 클릭하면 작업이 실행되는 시간을 설정하거나 변경할 수 있습니다.

“Related Links” 섹션의 Statistics Options 링크는 특히 눈 여겨 볼 필요가 있습니다. 이 링크를 클릭하면 아래와 같은 스크린이 표시됩니다:

이 화면에서 "parallelism”, “estimating percentage” 등의 디폴트 값을 변경할 수 있습니다

AWR 데이터의 전송

데이터베이스의 성능 문제를 분석하는 상황에서 AWR 데이터가 매우 요긴하게 활용된다는 사실은 앞에서도 언급한 바 있습니다. 하지만 운영 중인 데이터베이스에서 AWR 데이터를 분석하는 것은 대도 있습니다. 그보다는, 데이터를 별도의 중앙 저장소에 로드하고 비교 분석을 위해 활용하는 편이 좋습니다.

Oracle Database 10g Release 2에 새로 추가된 DBMS_SWRF_INTERNAL 패키지가 바로 이러한 기능을 제공합니다. AWR_EXTRACT 프로시저를 이용하면 AWR 데이터를 Data pump 덤프파일에 다운로드할 수 있습니다:

 1  begin

  2     DBMS_SWRF_INTERNAL.AWR_EXTRACT (

  3        dmpfile   => 'awr_data.dmp',

  4        dmpdir    => 'TMp_DIR',

  5        bid       => 302,

  6        eid       => 305

  7     );

  8* end;

각각의 라인을 좀 더 자세하게 살펴보기로 합시다.

라인 설명

3 타겟 파일(Data Pump export 파일)의 이름이 정의됩니다. 파일명이 명시되지 않는 경우, 디폴트 값인 “awrdat.dmp”이
사용됩니다.

4 덤프파일이 기록되는 디렉토리 오브젝트를 정의합니다. 위 예제에서는 TMP_DIR 디렉토리를 /tmp로 정의하였습니다.

5 해당 기간의 첫 번째 스냅샷의 스냅샷 ID를 정의합니다.

6 마지막 스냅샷 ID를 정의합니다. 위 예제에서는 스냅샷 ID 302~305를 갖는 스냅샷을 export하고 있습니다.

이제 awr_data.dmp 덤프파일을 새로운 위치로 이동하고, DBMS_SWRF_INTERNAL 패키지의 AWR_LOAD 프로시저를 이용하여 로드합니다:

1  begin

  2     DBMS_SWRF_INTERNAL.MOVE_TO_AWR (

  3        SCHNAME => 'ARUp'

  4     );

  5* end;

이와 같은 방법으로 ARUp 스키마에서 SYS 스키마로 AWR 데이터를 이동하였습니다.

AWR을 다른 데이터베이스로 이동하는 것은 여러 가지 면에서 장점을 갖습니다. 운영 데이터베이스에 영향을 주지 않고 다른 데이터베이스에서 분석 작업을 수행할 수 있다는 것이 그 하나입니다. 또 여러 데이터베이스로부터 수집된 AWR 데이터를 중앙집중적으로 관리할 수 있다는 혜택이 있습니다.

$ORACLE_HOME/rdbms/bin 디렉토리에 위치한 awrload.sql 스크립트는 AWR 데이터의 로드 작업에 수반되는 모든 단계별 작업을 구현하고 있습니다. 또 awrextr.sql 스크립트는 데이터 추출 작업을 위한 용도로 활용됩니다.

운영 데이터베이스의 AWR 데이터를 외부로 이동하는 메커니즘은, 원래 오라클이 고객 기술 지원용으로 개발한 것입니다. 오라클 고객은 AWR 덤프파일을 오라클 기술지원 조직에 전달하고, 오라클에서는 이 덤프파일을 스키마에 임포트하여 문제를 진단할 수 있습니다.

리포트의 기간별 비교

다음과 같은 상황을 가정해 봅시다. 비즈니스 팀과 애플리케이션 팀이 함께 참여하는 비상 회의에 DBA가 호출되었습니다. 그 이유는 물어보나 마나 입니다. 데이터베이스가 느려진 것입니다. 개발팀 리더의 말로는, 어제 밤 새벽 1시에서 3시 사이에 수행된 배치 프로그램의 실행에 매우 오랜 시간이 걸렸다고 합니다. 보통은 30 분 밖에 걸리지 않던 것이, 어제 밤에는 2 시간이나 걸린 것입니다. 비즈니스 팀의 리더는 이로 인해 “매출 손실이 우려된다”고 말합니다.

“최근에 변경 작업이 있었습니까” DBA가 묻습니다. “아뇨. 없었습니다만.” 개발 팀 리더는 당연하다는 듯한 투로 답변합니다. (“그래, 그렇겠지.” DBA는 혼자 이렇게 생각합니다.)

어디서 많이 들어본 이야기 같지 않습니까 필자 경력의 십 분의 일만큼이라도 DBA 업무를 경험해 본 사람이라면 지금쯤 고개를 끄덕이고 있을 것입니다. 그럼 이제 어떻게 해야 할까요

다행히도 DBA에게는 Oracle Database 10g Release 2가 있습니다. DBA는 Oracle Enterprise Manager의 “Time periods Comparison” 기능을 활용해 보기로 합니다. 이 기능을 이용하면 서로 다른 시간대의 성능지표 변경 내역을 비교하는 것이 가능합니다. 따라서 DBA는 어젯밤 새벽 1시~3시의 스냅샷과 전날 같은 시간대의 스냅샷을 비교해 볼 수 있을 것입니다. 전날의 배치 프로세스가 정상적으로 수행되었다면, 두 시간대를 비교함으로써 중요한 단서를 얻어낼 가능성이 높습니다.

그 방법이 다음과 같습니다: 먼저 Oracle Enterprise Manager의 performance 탭을 클릭합니다. 페이지 하단에 "Additional Monitoring Links” 섹션에서 “Snapshots” 링크를 클릭하면 아래와 같은 스크린이 표시됩니다.

붉은 원으로 표시된 드롭다운 메뉴에서 “Compare periods”를 선택하고 “Go” 버튼을 클릭합니다.
그럼 첫 번째 스냅샷의 종료 시점을 선택하는 화면이 표시됩니다:

위의 붉은 원 안에 표시된 것처럼, 분석하고자 하는 시간과 날짜를 선택합니다. 지금은 새벽 1시~3시의 시간을 확인해야 하므로 “3 a.m”을 선택합니다. Next 버튼을 클릭하면 아래와 같은 스크린이 표시됩니다.

붉은 원 안에 표시된 것처럼 Select Beginning Snapshot 옵션을 선택하면 현재 사용 가능한 스냅샷의 목록이 표시됩니다. "Go to Time” 드롭다운 메뉴에서 “1:00 AM”을 선택한 다음, 새벽 1시에 해당되는 라디오 버튼(예제의 경우 248번)을 선택하고 “Next”를 클릭합니다.

같은 작업을 반복하여 두 번째 시간대(4월 22일 1-3 a.m.)를 선택하고, 마지막으로 “Finish” 버튼을 클릭합니다. 캡처/계산된 성능지표를 나란히 비교한 결과가 표시됩니다. 아래 그림은 분석 화면의 상단 부분을 보여주고 있습니다:

각 시간대의 시작시간과 종료시간이 표시되고, 두 시간대의 성능지표를 비교한 결과가 그 아래에 표시됩니다. 이 결과를 통해, 성능 면에서 두 시간대에 어떤 차이가 있는지 분석할 수 있습니다.

Second period Rate per Second 컬럼을 클릭하면, 숫자의 크기에 따라 정렬된 결과를 볼 수 있어 편리합니다. 예를 들어, 두 번째 시간대의 "physical read” 수치가 훨씬 높은 것으로 결과가 나타났다면, 배치 수행시간이 오래 걸린 원인이 바로 여기에 있다고 판단할 수 있을 것입니다. 또 "physical read” 수치가 높은 이유를 확인하기 위해 두 시간대를 비교한 리포트를 생성한 결과가 아래와 같습니다:

하단의 SQL Statistics 섹션으로 스크롤하면 아래와 같은 메뉴를 확인하실 수 있을 것입니다:

여기서 “physical reads” 수치가 상승한 원인이 된 SQL 구문을 확인할 수 있습니다. "Top 10 SQL Comparison by physical Reads" 링크를 클릭하면 가장 많은 physical read를 발생시킨 구문의 SQL ID와 해당 physical reads 수치가 표시됩니다. 또 SQL ID를 클릭하면 더 자세한 정보를 확인할 수 있습니다.

물 론 이것은 한 가지 예에 불과합니다. 성능 문제가 어떤 종류의 것이든, 서로 다른 시간대의 비교분석을 통해 문제의 정확한 원인을 밝혀낼 수 있습니다. 또 두 시간대의 데이터베이스 설정값을 비교하는 목록 또한 함께 제공됩니다. 모든 성능지표와 통계는 정규화 과정을 거치기 때문에, 비교 대상이 되는 시간대가 동일한 시각이 아니어도 무방합니다.