5.4 End to End Tracing

• 성능문제 추적의 어려움을 해소하기 위해 오라클은 End to End Tracing이라는 개념을 소개하고 이를 지원하기 위한 PL/SQL 패키지, 다이나믹 뷰, 확장된 SQL Trace 기능을 제공.

End to End Tracing의 구조
-- 일반적인 의미 - < 사용자웹 -> 서버어플리케이션 서버 -> DB서버 > 에 이르는 일련의 흐름을 모두 추적
-- 오라클에서의 의미 - 데이터베이스 레벨에서만 추적이 가능

• End to End Tracing 용어를 사용하는 이유는 오라클 데이터 베이스는 물리적으로는 백그라운드 프로세스, 서버프로세스, 데이터베이스 등으로 이루어 져 있지만, 논리적으로는 서비스의 집합 이라고 바라보는 관점 때문

• 서비스(Service) - 오라클 10g에서 추가 된 개념, 특정 업무기능을 제공하는 논리적인 그룹을 관리하기 위해 추가, RAC시스템에서 더욱 유용
  ex)
  HR(Human Resource. 인력)을 담당하는 모듈들을 모두 묶어서 "HR"이라는 이름의 서비스를 정의
  하나의 서비스에 여러 개의 인스턴스를 할당 or 하나의 인스턴스가 여러 개의 서비스를 제공 N:M
  ex)
  10개의 인스턴스로 이루어진 RAC환경을 가정
  HR서비스에 1~5번 인스턴스를,
  Billing 서비스에 4~8번 인스턴스를,
  Payment 서비스에 7~10번 인스턴스를 할당
  만일 HR 서비스에 대한 업무량이 증가하면, 6번 인스턴스를 추가적으로 HR 서비스에 할당 함으로써 부하를 분산시킬 수 있음.

• 오라클 10g부터 서비스 -> 모듈 -> 액션 의 계층 구조를 가진다.
• 오라클 10g에서 추가된 새로운 논리적 계층은 클라이언트(Client)이다. DBMS_SESSION.SET_IDENTIFIER 프로시저를 통해서 세션에 클라이언트 ID를 부여 할 수 있으며, 클라이언트 ID를 통해 논리적인 클라이언트의 자격을 부여한다.

<<오라클 10g 에서의 End to End Tracing의 기본적인 구조>>

End to End Tracing을 이루는 요소

• Service Module Action + Client ID로 구성되는 논리적인 구조
• 새로운 PL/SQL 패키지들
  • DBMS_SERVICE 서비스(Service)를 생성, 삭제하고 제어
  • DBMS_MONITOR End to End Tracing의 핵심 컴포넌트로, 서비스/모듈/액션/클라이언트ID레벨의 통계 정보 수집과 SQL Trace를 제어

• 새로운 동적 성능 뷰들
  • V$ACTIVE_SERVICES
  • V$SERV_MOD_ACT_STATS
  • V$CLIENT_STATS

• 새로운 SQL Trace 기능
  • 서비스/모듈/액션/클라이언트ID 레벨의 SQL Trace
  • 트레이스 파일 통합을 위한 trcsess 유틸리티

• PL/SQL 패키지
  • DBMS_SERVICE 패키지
    서비스(Service)를 생성, 삭제하고 제어하는 기능을 제공하는 PL/SQL 패키지 인터페이스를 제공한다. 동일한 작업을 EM(Enterprise Manager)나 srvctl 툴을 이용해서 수행 할 수 있다.
  • DBMS_SERVICE.CREATE_SERVICE: 새로운 서비스 생성
  • DBMS_SERVICE.DELETE_SERVICE: 서비스 삭제
  • DBMS_SERVICE.START_SERVICE: 서비스 시작
  • DBMS_SERVICE.STOP_SERVICE: 서비스 정지

• DBMS_SESSION 패키지
  세션 관리를 위한 다양한 프로시저들을 제공
  그 중 End to End Tracing과 관련된 프로시저들
  DBMS_SESSION.SET_IDENTIFIER:세션의 클라이언트 ID 지정, 클라이언트 레벨에서 성능 데이터를 추적하고 분석하려면 반드시 이프로시저를 이용해 클라이 언트 ID를 지정 해 주어야 한다. 지정된 클라이언트 ID는 V$SESSION. CLIENT_IDENRIFIER 컬럼을 통해 확인 할 수 있다.

• DBMS_MONITOR 패키지
  DBMS_MONITOR 패키지는 End to End Tracing의 핵심 컴포넌트로, 서비스/모듈/액션/클라이언트ID 레벨의 통계 정보 수집과 SQL Trace를 제어하는 역할
  오라클 10g 이전 버전에서는 기본적으로 시스템 전체 레벨이나 세션 레벨의 통계정보 수집과 SQL Trace만 가능
  또한 SQL Trace를 활성화하는 방법이 통일성이 없어 여러 패키지나 명령문으로 분산되어 지원
  오라클 10g에서는 SQL Trace를 제어하는 모든 기능이 DBMS_MONITOR 패키지로 통합(이전버전사용방식도 지원)
  물리적인 세션레벨 뿐 만 아니라 논리적인 서비스/모듈/액션/클라이언트ID 레벨에서 통계 정보를 수집하고 SQL Trace를 제어

– DBMS_MONITOR.CLIENT_ID_STAT_ENABLE: 클라이언트 ID 레벨에서 통계정보 수집을 활성화한다. V$CLIENT_STATS뷰에서 확인
– DBMS_MONITOR.CLIENT_ID_STAT_DISABLE: 클라이언트 ID 레벨에서 통계정보 수집을비활성화
– DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE: 클라이언트 ID 레벨에서 SQL Trace를 활성화. Trcess 유틸리티를 이용해서 병합
– DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE: 클라이언트 ID 레벨에서 SQL Trace를 비활성화
– DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE: 서비스/모듈/액션 레벨에서 통계정보수집을 활성화. V$SERV_MOD_ACT_STATS뷰에서 확인
– DBMS_MONITOR.SERV_MOD_ACT_STAT_DISABLE: 서비스/모듈/액션 레벨에서 통계정보수집을 비활성화
– DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE: 서비스/모듈/액션 레벨에서 SQL Trace를 활성화. trcess유틸리티를 이용해 병합
– DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE: 서비스/모듈/액션 레벨에서 SQL Trace를 비 활성화
– DBMS_MONITOR.SESSION_TRACE_ENABLE: 세션레벨에서 SQL Trace를 활성화 한다.
– DBMS_MONITOR.SESSION_TRACE_DISABLE: 세션 레벨에서 SQL Trace를 비활성화 한다.

동적 성능 뷰(Dynamic Performance View)

• V$ACTIVE_SERVICES 뷰
  현재 인스턴스에 할당 된 서비스의 목록에 대한 정보를 제공
  DBMS_SERVICE 패키지를 이용해서 동적으로 서비스를 제어할 수 있으며, TNSNAME 설정에서 특정 서비스를 이용하도록 지정할 수 있다.

• V$SERV_MOD_ACT_STATS 뷰
  End to End Tracing에서 가장 중요한 뷰 중 하나로, 서비스/모듈/액션 레벨에서의 수집된 통계 정보를 제공한다.

• V$CLIENT_STATS뷰
  클라이언트 ID 레벨에서 수집 된 통계정보를 제공한다.

• DBA_ENABLED_AGGREGATIONS뷰
  DBMS_MONITOR 패키지를 통해 활성화된 수집 작업의 종류를 알려준다.

• DBA_ENABLED_TRACES 뷰
  DBMS_MONITOR 패키지를 통해 활성화된 트레이스 작업의 종류를 알려준다.

• TRCSESS 유틸리티
  분산된 여러 개의 트레이스 파일을 하나의 트레이스 파일을 병합하는 역할을 하는 유틸리티이다. Trcsess 유틸리티를 사용하면 특정 서비스 별, 모듈 별, 액션 별, 클라이언트 ID별, 세션 별로 트레이스 파일을 병합할 수 있다.
  ex)모든 트레이스 파일에서 SQL*Plus를 통해 수행된 내용만 병합
  Trcsess output=trace.out module=SQL*Plus *.trc

• 성능 문제
  End to End Tracing 방법론이 비록 오라클의 성능 데이터를 추적하고 수집하는 방식의 패러다임을 바꿀정도의 위력이 있지만 약간의 트레이드-오프(Trace OFF)가 있다는 사실을 이해해야 한다.
  • 네트워크 부하
    End to End Tracing]을 활성화시키려면 DBMS_APPLICATION_INFO.SET_MODULE프로시저나 SET_ACTION 프로시저, DBMS_SESSION.SET_INDENTIFIER 프로시저를 세션 레벨에서 호출해야 한다. 어플리케이션 구현 시 DBMS에 대한 모든 요청을 SQL 문 직접 호출하는 방식으로 구현했다면 SQL 문을 수행하기 직전에 이들 프로시저를 호출해야 하므로 네트워크 부하가 크게 증가할 수 있다. 최악의 경우 SQL 문 호출 회수가 2배로 증가하기 때문에 성능에 상당한 악영향을 미칠 수 있다. DBMS에 대한 요청을 패키지나 프로시저를 호출하는 방식으로 구현 - 패키지나 프로시저 내에서 이들 프로시저를 호출하기 때문 네트워크 부하는 없어짐 DBMS에 요청을 보내 때의 오라클의 권고안은 가급적 패키지나 프로시저를 이용 End to End Tracing도 이러한 방식을 사용할 때 훨씬 효율적으로 작동하도록 구현
  • 성능데이터 수집 자체의 부하
    필요한 특정 서비스/모듈/액션/클라이언트 ID 등에 대해 선택적으로 성능 데이터를 수집하는 방식을 사용할 필요가 있다.

문서에 대하여

• 최초작성자 : 이정헌
• 최초작성일 : 2011년 04월 30일
• 이 문서는 오라클클럽 코어 오라클 데이터베이스 스터디 모임에서 작성하였습니다.
• {*}이 문서의 내용은 (주)엑셈에서 출간한 'RAC Advanced OWI, Internals and Performance in Oracle 10g'를 참고하였습니다.*