h1.Introduction

h5.1.Response Time Analysis 방법론 이란?

• 대기 이벤트를 기반으로 세션 또는 시스템 전체에 발생하는 병목현상과 그원인을 찾아 문제를 해결하는 방법 및 과정 을 말한다.
• 대기 이벤트 기반 이라고도 말한다.

h5.2.Response Time의 정의

Response Time = Service Time + Wait Time  
              = CPU Time + Queue Time 

• Service Time(= CPU Time) : 프로세스가 정상적으로 동작하며 일을 수행한 시간
• Wait Time(=Queue Time) : 대기 이벤트가 발생해 수행을 잠시 멈추고 대기한 시간
  Response Time(오라클 서버의 응답 시간) 은 프로세스가 정상적으로 동작하며 일을 수행하는 시간과 수행 하는 동안에 대기 이벤트가 발생한 시간들
  의 합이라고 Response Time Analysis 방법론에서는 정의하고 있다.

h5.3.Response Time Analysis 방법론

• CPU time 과 Wait time을 각각 break down 하면서 서버의 일량과 대기 시간을 분석.
• CPU time 은 파싱 작업에 소요된 시간인지?
  쿼리 본연의 오퍼레이션 수행을 위해 소요된 시간인지? 를 분석
• Wait Time은 각각 발생한 대기 이벤트들을 분석해 가장 시간을 많이 빼앗긴 이벤트 중심으로 해결방안을 모색.
  이와 같은 일련의 분석 방법을 Response Time Analysis 방법론이라고 한다.

h5.4.OWI(Oracle Wait Interface)
Response Time Analysis 방법론이 제시되고 난후 이에 착안한 많은 새로운 분석 기반과 활용방법들이 제시 되었는데 이중 오라클에서도
이 방법론을 지원하기위해 오라클이 제공하는 기능과 인터페이스를 통칭한는 말.

h5.5.Response Time Analysis 방법론기반의 튜닝기법 (병목해소 과정)
예시)

insert into t1
select /*+ ordered use_nl(t3) */ seq.nextval t2.*, t3.*
from t2, t3
where t2.key = t3.key
and t2.col between :range1 and :range2

• 20개 프로세스가 동시에 떠서 작업을 수행
• 하루 저녁에 1억 건을 처리해야 하는 배치 프로그램 (한 세션당 500만)
• 서로 읽는 범위를 달리하여 프로그램 Parallel 방식으로 수행
  

(그림 3-4)
상황1 : db file scattered read 대기 이벤트 가 Wait time의 대부분을 차지

• 원인 : t2 테이블 기준으로 NL 조인을 수행하면서 반복 액세스가 일어나는 t3 테이블 조인 컬럼에 인덱스가 없어 매번 Full Table Scan으로 처리되고 있음
• 해결 : 인덱스를 추가해 정상적인 Index Scan으로 처리되도록 튜닝

 h3.file scattered read 대기 이벤트?
 멀티블록 I/O 요청이 완료되기를 대기하는 세션에 의해 발생

(그림 3-5)
상황2 : buffer busy waits과 latch: cache buffers chains 이벤트가 새롭게 발생

• 원인 : 문제1의 해결으로 많은 처리를 버퍼 캐시 내에서 할 수 있게 됨으로 인해 서버 프로세스의 처리 속도가 크게 향상되어 그 때문에 버퍼 블록에 대한 동시 액세스가 증가하면서 메모리 경합이 발생하기 시작한 것
• 해결 : 캐싱된 버퍼 블록에 대한 읽기 요청이 많이 생기는 문제이므로 블록 요청 횟수를 줄이기 위해 NL 조인을 해시 조인 방식으로 변경

 h3.buffer busy waits?
 - insert 및 update 시Buffer Lock을 Exclusive 모드로 획득할 것을 요구하는데 여러 프로세스가 동시에 동일 블록에 대해 Buffer Lock을
   Exclusive 모드로 획득하는 경우 Buffer Lock 경합이 발생하게 되고 이때 buffer busy Waits 이벤트가 발생하게 된다.

 h3.latch: cache buffers chains 이벤트?
 - Cache Buffer Chain(SGA에 있는 cached된 data blocks을 찾을 때 획득해야하는 latch)을 탐색하기 위해 cache buffers chains latch를 
   획득하고자 대기하는 이벤트
-  여러 세션이 동시에 동일 cache buffers chains latch를 Exclusive Mode로 요청으로 인해 일어남

(그림 3-6)
상황3 : log buffer space, enq:SQ - contention 이벤트가 새롭게 발생

• 원인 : select 경합이 해소되니 insert 처리부분에서 경합이 발생(insert에 의한 Redo 레코드 생성 속도가 증가하면서 Redo 로그 버퍼 공간이
  부족해 졌으며, Sequence 테이블에 대한 경합 발생)
• 해결 : Redo 로그 버퍼 크기를 약간 늘려주고, Sequence 캐시 사이즈 10에서 20으로 증가시킴

 h3.log buffer space대기 이벤트?
 - 새로운 redo 레코드를 로그버퍼에 기록하려고 할 때가용한 공간이 없을 경우에 발생
 - 해당 대기는 LGWR가 리두로그파일에 기록하는 것보다 빨리 애플리케이션에서 리두정보를 생성한다는 것을 의미

 h3.enq:SQ - contention 이벤트?
 - 메모리에 캐쉬되어 있는 범위안에서 시퀀스의 nextval을 호출하는 동안 SQ LOCK을 SRX모드로 획득하게 되는데 동시에 많은 세션이 
   SQ LOCK을 획득하기 위해 경쟁하는 과정에서 경합이 발생하게 되었을때 발생하는 이벤트

이와 같이 Response Time Analysis 방법론기반의 튜닝기법으로 모니터링과 튜닝을 반복하면서 병목을 해소해 나가는 방법을 OWI 방법론이라고 한다.