Oracle 성능분석방법론

Oracle 성능분석방법론

 

 

글 ㈜엑셈 선임컨설턴트 김한도

 

 

성능분석방법을 언급하기 전에우선성능분석이라는 것이무엇인가에 대해생각해 볼필요가 있다. 성능문제라는 사실을 판정하는 것도쉽지가 않고더나아가 성 능문제의정의를내리는것은더욱어려운문제이다. 성능문제가어떤것이라고정의를내리는것은이미성능에영향을미치는요소, 혹은성능문제를판별할수있 는요소를이미찾아내었다는것을의미하는것이다. 원인을가려내고해결책을찾는과정이수반된다

 

 

 

Oralce 성능 분석 방법론이란 말그대로 Oracle의 성능을 총체적으로 분석하는 방법론이다. 여기에는 Oracle의 성능은 무엇을 의미하며 그 성능을 측정하기 위해서는 어떠한 요소들을 관찰해야 하는지 또한 이 관찰한 값에 어떠한 의미를 부여하여 성능을 표현할 수 있는지 그리고 성능 저하를 야기한 원인과 그에 대한 해결 방법에 대한 논리적인 프로 세스가 포함된다.

지금껏 Oracle의 성능을 분석하는 여러방법론이 있었고 각각의 방법론은 성능 문제를 인식하는 시각과 원인을 분석해가는 방법에서 차이가 나타나고 있다. 이들의 방법론은 나름대로의 장점도 있지만 또 다른 관점이 등장하고 IT 업무환경이 진화해가면서 좀더 성능을 잘표현해줄수있는 방법론의 필요성이 대두 되는것도 현실이다. 이러한 측면에서 지금껏 현장에서 다년간 여러가지 성능문제를 분석하며 여러분석 방법론을 실험하고 또한 현실에 맞는 방법론을 연구한 ㈜엑셈은 기존의 방법론과는 조금 다른 시각으로 성능을 바라보고 각각의 방법론을 개선하여 새로운 방법론을 정리하게 되었다.

본지에서는 이러한방법론이 성능을 어떻게 바라보고 있으며이를표현하기위해어떠한요소들을어떻게다루고있는지에대해서소개해보려한다.

 

 

 

 

성능을 어떻게 말할 수 있는가?

 

 

새로운 방법론에서 파악하고 있는 성능문제는 Ratio-Base Analysis 나Wait Event Analysis 등이 방법론에서 Resource 또는 대기시간을 살펴 병목을 찾음으로써 성능문제를 인식한것에서 크게 벗어나지는 않는다. 즉 새로운 방법론에서 도병목이라는 현상 혹은 상황을 주요한성능문제 라고 파악한다. 그러나 이 새로운 방법론에서는 병목 보다는 경합 이라는 의미가 더적절하다.

병목이란말그대로병의목, 즉 갑자기 좁아지는곳을 의미한다. 경합이란 경쟁을 의미한다. 무언가 틈바구니를 서로 헤집고 나간다는 상태를 표현하는 데는 서로 무리가 없지만 굳이 차이를 구별해 낸다면 병목은 장소의 의미가 강하고 경합은 행위의 의미가 강하다는것이다. 그러므로 Oracle Area 중 어딘가에서 문제가 생겼다는 것을 표현하는 데에는 병목현상 이라고 칭하는 것이 적절하고 세션들이 특정 리소스 나 오브젝트 등을 놓고 대기하는 현상을 경합 현상이라 고칭하는것이 적절 하다 할수있다.

데이터베이스라는 것은사용자의 요청에대해개개의프로세스 혹은세션이그에관계된데이터를처리해결과값으로응답하는시스템이다. 이데이터베이스를 사용하는 사용자들은 그 동안의 경험을 통해 학습된 요청의 응답시간 대한 어떤 기대 수준이 있다. 성능 관리란 이러한 기대 수준의 범위를 넘지 않도록 데이터베이스의 요청에서 응답으로의 흐름이 원활하게 지속될 수 있도록하는것이라가정한다. 경합이란 이러한 흐름이 막히거나 원활하지 못하여 전체적인 요청- 응답의 순환계에 지장을 주는 것이고 이는 데이터베이스 전반적인성능의 저하, 즉 성능문제를 야기하는것이다.

새로운방법론에서는 분석의 초점이 어디서 정체가 발생했나 보다는 응답을 기다리는 세션들이 얼마나 정체되어있고, 얼마나 오래 기다리고 있는지에 대해서, 즉 대기 행렬과 대기 시간을 놓고 성능 문제를 인식하고 있기 때문에 병목이라는 용어보다는 오히려 경합이라는 용어가 성능 문제를 표현하는데 있어 더욱 적당하다. 다시 정리하자면 새로운 방법론에서 성능 문제란 결국 데이터베이스의 흐름이 막히는 것으로 여러 세션들이 어떠한 문제로 인해 서로 경합에 빠지게 되어 점점 경합에 참가하는 세션들과 그 세션들의 대기 시간이 증가하는것을 의미한다고 할수 있겠다.

성능 분석의 흐름

 

 

이러한 성능 문제의 양상은 도로 교통의 상황과 비슷하다. 이미 건설된 도로를 전체 데이터베이스라고 하고 여기를 지나는 자동차를 개개 세션 혹은 프로 세스 라고 가정하자. 자동차들은 어떤 목적지를 향해간다. 여러분이만약도로 교통을 관리하고 모니터링 하는 사람이라면 어느 부분에 관심을 가질까? 질 문을 바꾼다면, 당신이 관심을 가져야 할 도로 교통의 문제 상황은 어떤 것일까? 아마도 어딘가에서 자동차들이 정체되기 시작하는 것을 가장 관심을 갖게 되고 또한 그것을 문제 상황이라고 판단할 것이다. 즉 교통의 흐름을 방해 하는 경합 이라는것이 바로교통의 문제인 것이다.

교통이 정체되었다는 사실을 인지하면 가장 먼저하는일은 언제부터 발생 했고 어디에서 발생했는지를 파악하는 것이다. 그 이후 이 정체의 근본 원인 이사고인지, 아니면도로에 방해물이 떨어졌는지 아니면 단순히 차량이 갑자기 몰려서 그러한 일이 발생했는지를 분석하고 이에 따라 교통상황을 개선하기 위한 조치에 들어가게된다.

이러한 과정은 성능 분석에서도 그대로 맞아 떨어지게 된다. 일단 성능 문제를 병목 또는 경합 이라고 했을때는 이러한 성능 문제를 판별하기 위한 방법 적인 절차가 필요하게 된다.

즉 병목, 경합은 어떤 상황이냐에 대한 답이 필요한 것이다. 성능 분석에서도 교통과 마찬가지로 행렬과 속도로 판별할 수 있다. 즉 병목 또는 경합이 발생 하는 것은 위에서 가정했듯 개개 세션의 수행 속도가 느려지게 되고 세션의 수가 급격하게 늘어나는 현상을일컫는다. 개개세션의 수행 속도는 바로 대기에 소비하는 시간에반비례하고 세션들은 Active 상태에서 대기에 빠지게 된다. 결국 전체적인 대기 행렬과 대기 시간으로 성능 문제를 인지 할 수있게된다.

그 이후의 상황도 교통 상황과 비슷하게 진행된다. 이 성능 문제가 언제부터 발생했고 또한 이 문제가 데이터베이스의 어느 영역에서 발생했는지를 파악하는것이다. 이성능문제의원인은Oracle 에서제공하는Wait Event 를 이용하여 파악 할 수 있다. 이후에 이러한 원인 분석을 기반으로 하여 해결책을 모색할 수 있는 것이다. 다시 말해 성능문제가 인지되면 성능 문제의 정도를 판단하고 이 성능 문제가 어느 시점에 발생하고 있는지를 먼저 파악한 후 이에대한분석이수행되어야한다는것이다.

그런데 여기서 한가지 생각해 보아야 할것이있다. 성능문제가심각한경우 과연 성능 분석을 빨리 수행하여 해결책을 제시할 수 있을지에 대한 것이다. 사실 성능 문제가 발생하면 그 원인을 분석하는 것보다 빨리 이 문제를 해결하여 정상화 시키는 것이 당면 과제가 된다. 하지만 성능 문제가 인지된 이 상성능문제의 재발방지를 위해서도 성능분석은 불가피하다.

 

 

성능 측정을 위한 요소들

 

 

이러한 이유에서 성능분석을 위한 성능데이터의 이력은 반드시 필요하다 할 수 있다. 성능 데이터의 이력이란 말 그대로 과거의 성능 데이터를 모아 놓은 것을 말하는데 성능 데이터의 이력이 없는 경우 우리가 볼 수 있는 정보는 세션들의 현 상태와 활동 상태, 그리고 매우 요약된 수준의 통계들을 보여주는 몇 몇 뷰들로 제한되며, 이 정보들만으로는 성능 문제의 발생 여부를 알 수 있을지는 몰라도 문제의 원인을 밝힐 수 없는 경우가 많다. 대부분의 경우 성능 문제 증상들을 재현하여 원인을 밝혀내기 위해 작업들을 재실행 하는 경우에는, 그 증상들이 재현 가능하고, 문제의 증상이 발생하는 시점을 안다는 전제가 있어야 한다. 성능 문제의 원인 파악이 없이 조치를 취하는 것은 밤중에 사격을하는것과같고, 상황을악화시킬수도있다. [OWI ] 그러나 성능 데이터의 이력을 교통상황 과 비교해본다면 CCT V를 녹화해 둔 것이라 말 할 수있다. 즉 재현이없이도그당시의상황을그대로관찰해볼 수 있다는 것이다. 일단 성능 문제가 발생했고 이것이 지금은 해결이 됐다고 생각은 하지만 성능 분석이 불가능하기 때문에 정확한 원인을 파악하지 못한 이상 조치를 취하기는 어렵고 이러한 문제가 앞으로 발생하지 않을 것이라는 보장도 없다. 그러나 성능 데이터의 이력이 있다면 그 당시의 상황에서 성능 분석이 가능하다. 성능 문제가 있는 당시보다는 조금 더 여유 있는 상태에서 성능문제의 원인을 분석해 볼수 있는 것이다.

성능 데이터의 이력을 생성하는 방법은 여러가지가 있다. 그러나 그 중에서 가장 시스템에 부하를 주지 않으면서도 충분히 많은 데이터를 수집할 수 있는샘플링방법이가장유용하다할수있다. 그러나 이것은 Oracle 에서 제공하는 유틸리티를 사용하는 것이 아니고 별도의 개발이 필요하다. 이는 상세한 성능 데이터를 수집할 수 있고 부하를 최소화 할 수 있으며 원하는 형태로 저장이 가능해야 한다는 필요에 의한 것이다. 샘플링 방법은 일정 주기로 데이터베이스에 접속된 모든 세션 및 시스템 레벨의 성능 통계자료와 SQL 및 대기 이벤트의 정보를 샘플링하여 저장한다. 이를 통해 데이터베이스 전반에 대한 성능데이터를 수집할 수 있는 것이다. [OWI ]

이 샘플링 방법은 초기에 SQL*NET 을 통해 원하는 데이터를 얻기 위해 SQL 을 수행하여 데이터를 가져 오는 방식으로 개발이 되었다. 그러나 이것은 샘플링의 주기가 너무 짧으면 데이터베이스에 부하를 가져오게 되고 또한 성 능 문제가 심각한 경우 성능 데이터를 수집할 수 없다는 문제에 봉착하게 되었다. 그래서SGA 직접접근방식을 통해 최대초당100 회에 이르기까지 성능 데이터를 수집할 수도 있게 되어 보다 자세한 성능 분석이 가능하게 되었다. [OWI ]

성능 데이터의 이력을 가지고 성능 분석을 하게 되면 고려해야 할 사항이 한가지더 생기게 된다. 성능문제가 발생한 시점이 바로 그것이다. 물론성능 분석방법에 따라 성능 데이터의 이력도 다르게 되겠지만 성능문제의 인식과 더불어 성능 분석 시점을 찾는 것은 효율적이고 정확한 성능분석을 위해서는 중요한 과정이라 생각된다. 새로운 방법론에서도 성능 데이터의 이력을 굉장히 중요하게 여기고 있을뿐만 아니라 시간이라는 개념 자체를 필수적인 요소로 생각하고있다.

이러한 샘플링 방법에 의해 가져오는 데이터는 크게 Sy stem L evel 과 Session Level 로 나뉠수있다. System Level 은 주로 데이터베이스전반 의 성능을 파악할 수 있는 자료들을 포함하는데 여기에는 데이터베이스의 일량을 가늠할 수 있는 통계정보(Statistic) 와 대기 이벤트 정보(Wait Event) 와Oracle 에서 적절히 제공하지는 않지만 분석의 요소로 사용하기위해 별도의 방식으로 수집하는 Active Sessions Count등의 정보들이 있다.

Session Level 은 현재작업을 수행하고 있는 Session 들의 일반정보 및 통계정보, 대기이벤트정보, SQL 정보등이 포함된다.

 

 

 

성능의 평가 요소-경합지수와 그 요소

 

 

앞서 새로운 방법론에서 성능문제란 결국 경합이 발생하는 상태 또는 현상 이라고 정의하였다. 이러한 차원에서 새로운 방법론에서는 성능 문제를 가늠하는척도로경합지수(CQ : Contention Quotient) 라는것을사용한다. 성능문제라는것이데이터베이스의 속도저하로인한경합으로대기행렬과대기시 간이 증가하는 현상을 의미하기 때문에 경합지수도 대기 행렬을 반영하는 Active Sessions 와 대기 시간, 더 정확히 말하자면 대기 시간의 비율인 Wait Time Ratio 를 사용하여 구하게 된다. 그러므로 경합 지수란 Active Sessions 와Wait Time Ratio 를 통해 성능문제를 반영 하는 것이라 할 수 있다.

Active Sessions 란 Oracle에서 세션의 상태가Activ e인세션의수를의 미하며이는 Oracle에서 요청을 받고 이에 대한 응답을 하고 있는 세션의 수와 같다. Active Sessions 는실제로작업을 수행하거나 작업을수행하면서대기 에 빠져 있는 Session 이다. 이 Active Sessions 라는 것은 V$SYS - STAT 과같이Oracle 에서 제공하는 성능지표는 아니다. 이값을 가져오기 위해서는V$SESSION 에서Status 가Active 인것을 헤아려와야한다.

Active Session 의 증가 정도 즉 얼마나 많은 세션이 경합에 참가하였고 또 얼마나 이러한 상황이 지속되는지에 대한 것은 경합 자체의 성격을 규명하는 아주 중요한 요소이기 때문에 성능 문제를 인식하는데 있어 상당히 중요한의 미를 지닌다. 다시말해Active Sessions 는 경합이 심화되면 상한이 없이 무 한정 늘어날 수 있고 또한 경합이 진행될수록 큰 값이 나타나는 빈도도 상당히 잦아 진다. 이는 결국 세션들의 속도저하를 반영 하는것으로 볼수있다. 이는세션들의속도저하가세션들의대기행렬의길이와정비례관계에있기때문에이를 뒤집어 생각해 보면 Active Sessions 가 상당히 큰값으로 나타나고 큰값이 자주나타나 Active Sessions 의 값의 범위가 커지면 커질수록 속도가 그 만큼 저하되어 경합이그만큼 심하다는 상황을 여과없이 반영하고 있다고 할수있다. 즉 Active Session의 값의 범위가 커지면 수행시간은 많이 걸렸다고 간주 할 수 있게되는 것이다.

그러나 이Active Sessions 를 가지고 성능문제를 파악하기 위해 사용할 때 심각한 문제가 하나있다. 이Active Sessions 는 시스템의 하드웨어 적성능이나 업무에 따라 그 많고 적음이 차이가 있다는 것이 바로 그것이다. 성능문제를 판별하기 위한 요소로서의 Active Sessions 가 사실 굉장히 가변적인 수치이기 때문에 이것을 비교 가능한 수치로 만들기 위해서는 적당한 가공이 필요하게된다. 즉 절대적인 수치를 상대적인 수치로 변경하는 작업이 수반되어야 한다는 것이다.

이 Active Sessions 를 상대적인 수치로 변경하기 위해서는 기준값이 필요하다. 이를위해먼저Active Session 의분포를보도록할것이다. 분포란 Active Sessions 값이 얼마나 퍼져 있는지를 나타내는것으로 성능문제가 없었던 그래프는 분포 자체도 적을뿐더러 최대값에 가까운 수치를 나타내는 빈도도 상당히 적다. 그 이유는 성능 문제가 발생하여 경합이 심해지면 Active Sessions 의 값이 커지게 될 것이기 때문이다. 그러므로 Active Sessions 의 분포는 성능 문제가 심각했다는 것을 한눈에 판별할 수 있게 해 준다. 다음의 그림은 성능 문제가 발생했던 데이터베이스와 성능 문제가 거의 없는 데이터 베이스의 Active Sessions 의 분포를 나타낸 그래프이다.

위의 그림에서 또 한가지 눈에 띄는 것은 점과 화살표이다. 이것은 각 Active Session 그래프에서기준점과각점간의거리를나타낸다. 위의그래 프는 크기를 맞추느라 X축의 스케일을 왜곡한 결과 화살표의 길이가 같지만 분포를 가지고 화살표의 길이 비율을 따지면 같은 길이라 하더라도 성능문제가 있는 왼편의 화살표는10 배이상의 비율을 가진다.

벌써분포만을가지고도서로를비교할수있는무언가가나온것같다. 일단 기준점을 알게 되면 각 분포에서 그 거리를 가지고 어떤 수치를 나타낼 수 있게 되는 것이다. 그러나 이 기준점도 또한 쉽지는 않다. 이 기준점을 특정한 수치 즉 절대값으로 표현 할 수 있으면 좋겠지만 이렇게 설정할 경우 결과로 나오는 수치도 가변적일 것이 틀림없다. 그 이유는 기준값을 고정하게 되면 상한이없는Active Session 의성질에 따라 이 값도 상한이 없어질 것이기 때문이다. 그렇기 때문에 기준점도 또한 상대적으로 파악해야한다.

이를위해Active Session 으로 대변되는 성능문제 라는것에 대해서 하나의 가정이 필요하다. Active Session이 평소와 달리 큰수치를 기록하는것은 특정 시구간, 특히 하루의 경우 일상적이 아닌 특수한 상황이라는 가정이다.

이 가정으로 인한 오류는 나중에 바로 잡도록 하고 일단 이 가정이 옳다고 생각하자. 이러한 가정에 입각하면 성능문제가 발생하여 Active Session 이급 격하게 증가하는 상황은 매우 특수한 상황으로 기준점을 가장빈도가 높은지 점(α) 과 최소값과 최대값의 거리비율(β) 을 따져 보아 기준점(γ)을 놓게 된다면 이 이상한 현상의 수치에 대한 Ratio 를구 할수 있게 되는 것이다.

이렇게구한기준점을하루의데이터를기준으로하여각각의분포를구하게되면Active Session Ratio 가나타나게된다. 이공식은아래와같다.

Active Sessions Ratio = DIST( Active Sessions / Day ) 이제Active Session 이라는성능문제의한가지요소에대한계량화가이 루어졌다. 그러나 이 공식은 배경에 깔려 있는 가정에 약점이 있다. 만약 성능 문제가 하루 중 특이한 상황이 아니라면 어떻게 할 것인가? 즉 성능문제가 일시적 이어서 눈에 띄게 큰수치를 나타낸다면 Active Session Ratio 는 이를 잘 표현하겠지만 하루종일 경합에 시달리는 경우는 그반대의 상황과 비슷한 수치로 표현되기 때문에 오류가 발생하게 된다. 이를 해결할 수 있는 것이 바로 Wait Time Rati o이다.

Wait Time Ratio 는한마디로말해Elapse Time 대비Wait Time 의비 율이다. Elapse Time 은Service Time 과Wait Time 으로구성되어있다 이것은Session Level 이아니라System Level 의Wait Time Ratio 이다.

또한이Wait Time Ratio는 각 시점 시점 마다의 Elapse Time 에서 Wait Tim e 의 비율을구한다.

Wait Time Rati o를 구하기 위해서는 시점마다의 Elapse Time 과Wait Time 을 구하는 작업이 선행 되어야한다. 우선Elapse Time 을 구해야한다.

세션 차원에서 Elapse Time 을 구하는 것은 쉽다. V$SESSION 의 last_call_et 라는 컬럼이 나타나기 때문이다. 또한 시점과 시점마다의 Elapse Time 은 역시 시점간의 델타(Δ )로 구성하면된다. 즉 주기를1초로 한다면1초 동안 세션이 유지되기만 하면 시점사이의 Elapse Time 은 1초가 되는것이다. 그렇다면 이를 확장해서 생각해보자. 현재1초 동안30 개의 세션이 유지가 되었다면 전체Elapse Time 은 당연히 30초가 된다. 즉 각 주기 마다 Session 의 개수만 안다면 전체 Elapse Time 을 알수가 있게된다.

그러나 여기서 고려해야 할 두가지 사항이 있다. 첫째는이Elapse Time 을 계산할 때 Active Session 이 아니면 의미가 없다는 것이다. 그 이유는 Elapse Time 은요청에서응답까지의시간을의미하기때문이다. 그렇기 때문에 전체 Elapse Time 을 산정하는 대상은 A ctive Sessions 로 한정해야 한다.

두 번째 고려해야 할 사항은 Active Session 의 채집 주기이다. Active Sessions 는 Oracle이 주는 통계정보가 아니라 Current 하게 세션의 개수를 헤아려 오는 것이다.( Oracle의 통계정보 및 대기 이벤트의 통계정보는그값을 누적하여 가지고있다. 누적데이터는 어느 시 구간사이 에서도 전체 데이터 이기 때문에 채집 주기에 그 정확성에 영향을 받지 않는다.) 그렇기 때문에 A ctive Session 의 채집주기는 짧을수록 좋으며 계산상의 이점까지 고려한다면1초 정도가 적당하다. 만약이 수치를 넘게되면Active Session 의 채집된 데이터에 수집 주기를 초 단위로 곱하여 추정해야 하는데 이 주기가 길어지면 길어질수록 오차범위가 커지게 된다는 문제점이있다.

위의그림에서보면좌측에는초당1회씩Active Sessions 를10초 동안 채집하여전제Elapse Time 을157 초라고산출한반면우측의그림은10 초 당1회Active Session 을채집하여처음의값인15 를가지고이것이10 회 지속되었다는가정으로150 초로산출(15 * 10) 하였다.

이두가지사항을고려하여Active Sessions 로Elapse Time 을구할수 있다. 이제Wait Time 을구할차례다. Wait Time 은비교적구해내기가수 월하다. V$SYSTEM_EVENT 라는뷰에서time_waited 라는컬럼의델타 를 구해 모두 합하면 된다. Oracle 은 이 데이터도 모두 누적값으로 관리하기 때문에 채집 주기를 1초로 하든 10초로 하든 큰 문제는 없다. 나중에 Wait Time Ratio 를계산할때만그주기를맞추어주기만하면된다. 그러나이대로 이 Total Wait Time 을 사용할 수는 없다. 그 이유는 Oracle 의 Wait Time 은Active Session 만증가시키는것이아니라Inactive 도또한증가 시키기때문이다. Inactive 상태에서증가하는Wait Event 는SQL*Net message from client 와같은것이있는데이러한것을통칭하여Idle Event 라고 한다. 보다정확한계산을위해이러한Event 를제외시켜야한다. (Oracle 10g부터는각Wait Event 에Class를부여하였다. Idle Event 를알기위해서는 Class 가Idle 인것을참조하면될것이다.)이렇게구한아래의공식처럼Wait Time 에Elapse Time 을각각단위를 통일하여나누게되면Wait Time Ratio 를구할수있다. 이때주의할것은앞서 언급한 것처럼 주기를 통일시키는 것이다.

 

즉 1 분 단위 주기로 이 Wai t Time Ratio를 구하기로 했다면 각 초마다 채집한Active Session 의 값을 1분단위로 합한값을 1분의 Elapse Time 으로 사용하고 Wait Time도 1분 사이의 Delta를 가지고 사용하여 구해야 한다는 것이다. 이렇게 구한것은 분당 Wait Time Ratio 라고할수있다. 이Wait Time Ratio는 앞에서 언급한 것처럼 System Level 에 해당하는 값이다. 그러나 Elapse Time을 Active Sessions로 구해왔기 때문에 이것은 결국 세션당Wait Time 의 비율이기도 하다는 사실을 염두에 두기 바란다.

 

Wait Time Ratio = AVG(Non-Idle Wait Time / ∑ Active Sessions)

 

 

 

성능 문제의 인지 - 경합지수의 산출

 

 

이제 성능 문제인 경합을 인지하기 위하여 수량화 한 두 가지 요소를 통하여 실제로 경합지수를 구하는 작업을 수행해야 한다. 이를 위해 앞서 언급한 경합지수의 정의부분으로 잠시 돌아가 보도록 하겠다. 우리는 경합지수를 Active Sessions 와Wait Time Ratio 를통해성능문제를반영하는것이라 하였다. 그렇다면경합지수는Active Sessions Wait Time Ratio의어떠한 상황을반영하고있는것일까?

경합의상황에서는실제로Active Sessions 가급격하게증가하고이경합에참가하는세션들의대기시간도아울러증가한다. 그렇기때문에경합지수는이두가지요소에비례하는관계가있다. 이수량화한두개의Ratio를2차원 그래프로 그려보면 다음의 그림과 같다. 이 그래프의 X축은 Active Session Ratio 이고오른쪽으로갈수록증가한다. 또한Y축은Wait Time Ratio 이다. 이수치는위로갈수록증가하게된다.

이 그래프의 오른쪽 상단으로 가면 갈수록 Active Session Ratio 도커지고 Wait Time Ratio도 증가한다. 결국 이 방향은 성능문제의 심각성 즉 경합 현상이 심해지는구간이라고할수있겠다. 그렇다면이는원점에서멀어지면 멀어질수록 경합 현상이 심해지는 것을 의미하게 된다. 이를 통해 우리는 점 의 거리를 구함으로써 경합 지수를 구할 수 있게 된다. 이를 다음과 같이 정의 할수있다.

RAW-CQ = f( Active Sessions Ratio , Wait Time Ratio )

그런데 이 공식에는 문제가 있다. 만약 점의 좌표가 α나 β의 위치, 즉 축에 가까이 붙는 경우는 이경합지수가 왜곡될수있다. 다시말해 Wait Time 의 비율은 높으나 Active Session이 많지 않은 경우 또는 Active Session은 비교적많으나 Wait Time의 비율이 그리 높지 않은 경우이다. 전자의경우는적 은수의 세션중에서 Enqueue 등의 Event 를대기한경우로 이는 경합의 상황 임에는 틀림이 없으나 시스템 전체에 미치는 영향을 그렇게 크지 않다고 보고 있다. 이 경합 지수는 데이터베이스의 흐름이 막혀 대기에 참가하는 세션과 대기시간이 증가 하는 현상을 성능 문제로 보고 이를 반영하기 위한 개념이기 때문에 이러한 상황은 우선순위를 두지 않고 있다. 후자의 경우는 세션은 많 으나 대기가 없는 경우이기 때문에 흐름에는 지장이 없는 것으로 간주한다.

이러한경우도우선순위를두지않고있다.

그렇다면 결국에는 축에 치우치지 않고 멀어지는것에 가중치를 부여해 경합지수를 다시 가공해야 한다. 위의 그림에서 왼편에 있는 그래프가 이전의 산출된경합지수에해당하는데노란선상에있는모든점은같은경합지수를 나타낸다. 이는 단순히 거리에 따라 같은 값을 가지는 것을 표현한다. 그러나 앞에서 지적한 부분에 대해 가중치를 부여하여 이미 구해진 경합지수를 가공 하면 오른편의 그래프와 같아지게 된다. 이는 대각선 방향의 점과 축에 가까 운 점과의 거리가 같지 않아도 같은 경합지수로 나타나게 된다. 즉 Active Session 이 증가하면서 Wait Time 이같이 증가하는것을 우선순위가 높은 성능 문제로 생각하고 있으며 경합 지수는 이를 반영하도록 한 것이다. 이 경합지수는 다음과 같이 표현할수있다.

CQ = cq( RAW-CQ )

 

이 경합 지수는 30 분 정도의 주기를 가지고 각각 구해 낼 수 있다. 하루를 기준으로 48 개의 경합 지수 중 대표되는 경합지수는 최대값이다. 최대값을 구하는 이유는 경합지수는 성능 문제의 심각성을 반영하기 때문에 가장 위급 한 시점의 것을 취해 와야 하기 때문이다. 이렇게 가장 위급한 것을 전면에 부각하여 성능문제를 진단하고 해결한 이후에는 그다음의 최대값을 대표값으로 하기 때문에 데이터베이스의 성능 문제의 정도는 약간 떨어지게 된다. 이러한 방식을 흔히 Divide & Conquer 라고 칭하는데 문제가 있는것들을 나누어 하나씩 차근차근 해결하는 것을 의미한다. 이러한 방식을 원용한 것이라 생각하면 될 것이다.

그렇다면 이 경합지수의 가이드라인은 어디일까? 이 가이드 라인은 경험 적으로 판단할 수 밖에는 없다. 이를 알아내기 위해 지금까지 여러 성능 분석 의 결과를 토대로 경합지수를 나타내어 보기로 하겠다. 이 그래프는 Active Session Ratio 와Wait Time Ratio 를양축으로하여경합지수를점으로표 시한 것이다. 이중 ⓐ 영역은 경합지수의 분포를 나타내고 있으며 ⓑ 는 성능 문제라고판단되는영역을나타낸것이다.

우선 경합지수의 분포는 우측 상단을 향하는 럭비공 모양을 나타내고 있다. 이그림을 통해 알수있는 것은Active Session Ratio 와Wait Time Ratio 가 양의 상관관계 즉 비례관계에 있다는 것이다. 다시 말해 Wait 이 증가할수록 Active Session 에 영향을 미쳐시너지효과를 보게 된다고 할 수있다.

그런데 여기서 한가지의 문이 생길 수 있다. Active Session Ratio 와Wait Time Ratio 가 어차피 속성이 비슷하다면 굳이 두가지 요소로 복잡한 연산을 할 필요가 있을까 하는 부분이다. 그러나 이 의문의 답이 바로 성능 문제의 영역이다. 성능문제가발생한부분은주로Active Session Ratio 와Wait Time Ratio 도높은구간이다. 그러나이것도일부일뿐전체는아니다. 나머지 부분은 Active Session Ratio가 다소높거나 낮고Wait Time Ratio 도 다소 낮거나 높아 서로 비례관계가 성립 되지 않는 경우이다.

앞서 우리는 경합지수를 30분 간격으로 구한다고 하였다. 이 30분의 추이를 살펴보면 성능문제가 발생하기 시작하는 단계에서는 Wait Time Ratio 와 Active Session Ratio 가 모두 높지는 않다. 초기에는 둘중 한가지만 높은비율을 나타내다가 이것이 심화되면 동반하여 두지표가 모두 높아지게 되어 결국에는 우측 상단으로 수렴되는 형태를 관찰 할 수 있었다. 그런데 중요한 것은 성능 문제 자체이기 때문에 이미 수렴되어 Active Session Ratio 와 Wait Time Ratio 가 모두 높아지는 상태뿐만이 아니라 둘의 관계가 이미 임계 상황을 넘기 시작하면 이를 주시 해야한다. 그렇기 때문에 비례관계가 성립되지 않다 하더라도 다른 사분면에 걸쳐 있는 부분들을 찾아내야 한다. 이를 위해 두가지 요소로 쉽지않은 연산을 할수밖에 없는것이다. 그럼 다시 가이드라인이 어디인가 하는 질문으로 돌아가보자. 경합지수는 성능문제를 대변하는 수치이기 때문에 성능문제의 영역을 구분짓는 값이 결국 가이드 라인이 된다. 그러므로 가이드 라인의 값은 결국 ⓑ 의 그래프의 값이 되고 이는 경험적으로 50을 분기점으로 정하고 있다. 50 이하인 경우는 성능 문제가 없다고 가정해도 무방하고 50 이 넘어 수치가 커지면 커질수록 성능 문제가 심각하다는 것을 의미한다.

 

 

 

성능 문제 시점의 파악 - Hot Spot의 검출

 

 

Hot Spot은 사전적으로는 보통위험한지역 이나 분쟁지역을 의미한다. 그러나 여기서의 Hot Spot은 경합이 많이 발생하여 문제가 있는 구간이기도 하지만 집중적인 대처를 통해 성능상의 이득을 가장 많이 볼 수 있는 구간을 의미 하기도한다.

경합지수를 산출하여 50 이 넘지 않는 경우는 성능 문제가 심각하지 않기 때문에 굳이 성능 분석에 들어가 볼 필요는 없다. 굳이 무언가 작업을 원한다면 Elapse Time 과Wait Time Ratio 등을 기준으로Top SQL 을 찾아 튜닝 정도만 해준다면 예방차원에서도 큰 문제는 없을것이다.

그러나 문제는경합지수가50 이넘는경우, 즉성능문제가발생하고있다고 판단되는 경우일 것이다. 앞서 경합지수는 보통 하루 단위로 30 분마다 산출하여 그 최대값으로 대표한다고 하였다. 그렇다면 이 30분 마다의 경합지 수가 의미하는 것은 당연히 30 분의 성능 문제를 알려주는 척도라고 할 수 있다. 이를통해우리는Hot Spot 을찾아낼수있다. 성능문제가발생했을때제일먼저찾을수있는Hot Spot 은경합지수의 대표값을가지고있는구간이다. 이구간부터Hot Spot으로지정해서진단에 들어가면된다. 아래의그림은하루를기준으로하여Hot Spot이3개로나타난것이다. 이Hot Spot 을구하는방법에는두가지조건이있다.

첫번째조건은당연히성능문제를알려주는 기준점인 50 을넘어야한다는것이다. 두번째조건은48개의경합지수중에서의이상치(異常置, outlier) 에 속해야 한다는 것이다. 이것은 성능 문제가 일상적이지 않다는 가정에 기반을두고있다. 48 개의수치중에서말그대로정상적이지않은그수치는당연히일상적으로발생하는수치가아니라는의미로받아들일수있다. 이 두 가지 조건 중에서 두 번째 조건이 첫 번째 조건의 부분 집합이 된다. 그러므로 경합지수 50 이 넘는 것 중에서 이상치에 속하는 것들을 우리는 Hot Spot으로간주한다. 30 분간격의경합지수에서인접한시구간이연속적 으로Hot Spot인경우는이를하나로본다. 그렇기때문에Hot Spot의시구 간은일정하지않게된다.

 

 

 

성능 문제의 원인과 해결

 

 

Hot Spot 을찾아내었다는것은가장성능문제가심각한시구간을검출했음을의미한다. 그러므로Hot Spot을찾아낸이후에는이시구간을집중적으로 분석하여그원인을밝혀내는것이중요하다.

이새로운방법론도역시Wait Event 를가지고성능문제의원인을찾는다. 그러나앞서Wait Event Analysi s에서지적한대로Top Wait은 오류의 가능성을내재하고있다는사실을이미지적한바있다.

이Hot Spot은Wait Event Analysis 에서지적한대로T op Wait 의진 단의오류가능성을상쇄하는역할을한다. Hot Spot이라는것은각시구간을 나누어본것에불과할것이라생각할수있지만사실이개념안에는Wait 과 Active Sessions의추이를본다는전제가숨어있다. Top Wait 는추이가아 니라 합산한 결과를 가지고 순위를 매기게 되지만 이 Hot Spot 은 각 시구간 별로추이가나타나게된다. 가령7시간동안큰수조에한컵의물만큼계속 부어넣고다른경우는컵하나씩분리되어증가한다고가정하자. 그중4시간 이 되는 어느때 양쪽에 한방울의 잉크를 떨어트린 경우 후자의 경우가 더 명 확하게나타나게될것이다. 이러한원리로Hot Spot을구분하게되면성능문 제가발생한시구간과문제상황도한눈에드러나게될것이다.

그러므로Hot Spot을알아낸이상Top Wai t의 문제는간단히해결된다.
왜냐하면긴시구간이아니라성능문제가일어난시구간내에서Top Wait 를 뽑아내면당연히그시구간동안에가장오래대기를했던Wait Event 가나올 것이고이것이바로성능문제의원인일가능성이크기때문이다.
그런데Top Wait이 확실한원인이아니라아주큰가능성이라고표현하였 다. 그 이유는 이것이 원인이기 위해서 증명해야 할 무언가가 또 한가지 있기 때문이다. 이것은Active Session 과의관계이다. 즉성능문제에서Active Session 의증가하는것과Wait Time 의증가라는두가지요소에주안점을 두고있기때문에Wait Time 이증가한정황만가지고서는경합지수와 그원인과의 논리적 연계성이 약하다는 생각이다. 그렇기 때문에 Active Session 과의 관계 라는것을 증명 하기 까지는 이 Wait Event 가Hot Spot내 성능 문제의 원인이라고 꼬집어 말하는것을 유보하고 있는것이다.

이Active Session 과Top Wait Event 와의 관계를 나타내는것을 패턴 지수(Pattern Index) 라고하자. 이패턴지수는 다음과 같은 개념을 지니고있 다. 아래의 그림은 특정Hot Spot에서 Top Wait Event 가 Latch Free 일 경우를 나타낸것이다. 두그래프중상단의것은Active Session 의추이이다.

아래의그래프는Top Wait Event 인Latch Free 의그래프이다. 이두그래 프의X축은시간이며Y축은각지표값이다. 여기서우리가관심을가지고보 아야 할 것은 바로 이 그래프가 나타내는 값이 아니라 바로 그래프의 모양이 다. 보통Active Session 은개수가단위이고Wait Event 는시간이단위이 기 때문에 동등 비교는 불가능하다. 그러므로 이들의 비교는 그래프의 모양 즉추이의비교여야한다.

두 그래프를 살펴보면 Latch Free 와Active Session의 그래프는 상당한 유사성을지니고있는것을확인해볼수있다. 즉Latch Free 가발생하면서A ctive Session 이증가하고Latch Free 가사라지면서A ctive Session도 성능 문제가 발생하기 이전의 수준으로 떨어짐을 알 수 있다. 이러한 추이는 아래와 같은 식으로 구현해 볼 수 있다. 패턴 지수의 값의 범위는 0에서 100 으로Ratio 로간주할수있다.

PI = PTN( Active Sessions, Top Wait Event )

패턴지수를알아냈고Top Wait Event 도알아내었다. 그렇다면이둘을 조합해서원인이되는Wait Event 를판별하는하나의지수를만들어낼수도 있을것이다. 이미패턴지수는값의범위가0에서100 이고Wait Event 도Hot Spot내의Total Wait Time 에서해당Wait Time 의비율을구하게되면이 도 또한 0 에서 100 사이를 나타낼 수 있다. 이 값들을 아래와 같이 연산하여 연관성지수(Relation Index)를 산출할수있다. Hot Spot내에서이연관성 지수가가장높은Wait Event 가바로해당시구간을Hot Spot으로만든원인이되는것이다.

RI = RLT( PI, Wait Ratio )

이렇게 찾아낸 Wait Event 는경합을유발하는원인으로생각할수있다. Wait Event 를 가지고 그야말로 궁극적인 원인을 알아내기 위해서는 해당 Wait Event 에대한지식을필요로한다. 그러나이부분에대한내용은이미 여러서적이나문서, Metalink 등을통해공개되어있다. 이글의참고자료중 하나인 ㈜엑셈에서 번역 출간한“ OWI 를 활용한 오라클 진단&튜닝”이라는 서적에도Wait Event 에대한설명이자세히나와있기때문에이들의자료를 참고하는것이좋을것이다.

 

 

기존 성능 방법론과의 비교

 

 

지금까지 우리는 새로운 방법론이 어떠한 상황을 성능 문제로 가정하고 이를 해결하기 위해 어떻게 성능 문제를 인식, 진단, 해결 할 수 있는지를 살펴보았 다. 요약하자면 새로운 방법론에서는 데이터베이스를 하나의 흐름으로 보고 이 흐름이 막히는 상황을 성능 문제라고 정의하고 있다. 이러한 성능 문제를 인식하기 위해 Active Session Ratio 와Wait Time Ratio 를 각각 산출하여 경합지수(CQ)를 추출하여 이 수치를 통해 문제의 유무 및 정도를 파악하였다. 경험적으로 경합지수가 50 이 넘는 경우를 성능 문제가 있다고 간주하여 성능 문제를 진단하기 시작하게 된다.

성능데이터의 이력을 바탕으로 성능문제의 진단을 하기때문에 우선적으로 시도하는 것은 바로 성능 문제가 발생한 시점을 찾는 것이다. 이것은 이미경합지수를 찾으면서 생성된 데이터를 이용하여 위험 구간이며 해결 시 가장 큰효과를 볼수있는 Hot Spot을 선정할수있다. 그리고 이 Hot Spot 구간에서 성능문제를 일으킨 Wait Event 를 Wait Ratio 와Pattern Index 를통해 산출된연관성지수(RI)로 판별해내었다.

이제 성능문제의 진단과정에서 나타난Wait Event 를 통해 성능문제를 해결할 실마리를 잡게되었다. 검출된 Wait Event 는 그자체로 문제의 원인과해결책을내포하고있다. 그러나이것도 Wait Event 에 대한 지식 체계가 갖추어 지지 않는다면 의미 없는 암호에 지나지 않게 된다. 그렇기 때문에 적절한 해결책을 제시 하기 위해서는 각 Wait Event에 대한 지식이 뒷받침 되어 있어야 한다.

이 새로운 방법론은 기존의 방법론을 보완, 발전시킨 방법론이다. 새로운 방법론은 기존의 방법론의 강점을 수용, 변화 발전하고 약점을 보완하였는데 이는 이미 언급한 현자의 어깨 위에서 더 멀리 내다 본다는 말로 가장 잘 표현 된다.

성능 문제의 인식을 위해 사용된 경합지수(CQ) 는 우선 Oracle Response Time Analysi s의 강점인 하나의 수치로전체적인데이터베이스 의 성능을 대변할 수 있다는 강점을 그대로 살리고 있다. 또한 경합지수 그 자체를 하나의 지수로 만들어 Ratio-Base Analysis 의 강점이 절대량을 상대량으로 변경하여 비교가 가능하도록 규격화하고 있다는 강점도 아울러 살리고 있다. 그리고 새로운 방법론에 와서 전체 흐름에 성능 분석에 초점을 두고 있다는것은Session Level Profiling Analysis 의 약점인 전체의흐름을 볼 수없다는단점을보완 하고있다.

또한 Hot Spot이라는 개념을 통해 Wait Event Analysis 의 병목을 판단 하기 좋다는 강점을Wait 과더불어성능문제를입체적으로판단하는장치를 마련하여 더욱 발전 시키고 있다. 그리고Top Wait 이라는것이 문제의 원인을 찾는과정 에서 오류가 발생 할 수 있다는 약점은 Hot Spot으로보완할수있기 때문에Wait Event Analysis 및Oracle Response Time Analysis 의약점을보완하고있다. 성능 문제 해결에서 사용하고 있는 Wait Event 는 Ratio-Base Analysis 에서 Wait를 배제하고 있어 정확한 원인파악이 어렵다는 약점을극복 하고있으며 Wait Event Analysis 의 장점을 그대로 수용하고 있다는 것을 알수있다.

그리고 또한 방법론 전반에 사용되고 있는 System L eve l에서Session Level 로의T op Down 의 흐름은 다양한 경로로 튜닝의대상을찾을수있기 때문에Session Level Profiling nalysis 의강점을발전시켰다고할수있다. 앞의 표는 기존의 방법론의 강점 및 약점이 새로운 방법론에서 어떻게 변화되고 수용 되는지를 간략하게 나타내고 있다.
여기까지가 새로운방법론의개략적인설명이다. 앞에서도 언급 되었지만 이 방법론은 다년간의 경험의 산물이기 때문에 현재의 이방법론은 글을 작성하는 지금까지의 경험이 녹아 있는 것이다. 바꿔 말해 앞으로 더 나은 경험과 연구, 시도가 있으면 이방법론도 그에 맞게 개선 및 보강이 될 것이다.

 

 

제공 : DB포탈사이트 DBguide.net

출처명: ㈜ 엑셈