엑셈 MaxGauge 기술자료

엑셈 MaxGauge for Oracle, 기능 분석

실시간 모니터링으로 무장한 DB 성능 관리 ‘수문장’

박상철 │엑셈

요즘처럼 DBA들이 힘이 드는 때가 없다. 낮 시간에는 무수히 많은 회의를 i아 다녀야 하고, 밤 시간에는 문서작업, 시스템 점검 등을 해야 하기 때문에 정작 DBA들이 자신의 업무를 할 시간은 없다. 또한 언제 어디서 무슨 일이 생길지 모르기 때문에 DBA는 불안하다. 프로그램의 오작동이나 성능 문제가 생길 때 개발자들은 제일 먼저 오라클 데이터베이스의 문제로 돌린다. 오라클의 오작동이나 성능 문제는 항상 DBA의 몫이다. 시스템이 느려서, 개발자들이 프로그램을 잘못 작성해서, 디스크 I/O가 느린 것까지 모두 DBA의 잘못이다. 이런 무차별적인 공격 때문에 DBA는 힘이 든다.

하지만 방법이 있다. DBA 자신을 방어할 수 있도록 문제의 명확한 원인을 찾을 수 있는 힘을 갖는 것이다. 유능한 DBA라면 이런 문제에 직면했을 때 문제의 원인을 신속하게 파악하고 재발 방지대책을 세우는 것이 가능하다. 이 지점이 초보 DBA와 유능한 DBA의 분기점이라고 할 수 있다. 유능한 DBA가 되고 싶지 않은가 만약 ‘YES’라고 대답한다면 그럼 한걸음 앞으로 내딛어 보자.

오라클 성능문제나 장애가 발생하였을 경우 제일 먼저 해야 할 일은 현상을 관찰하는 것이다. 단지 SQL만 본다고 모든 문제가 해결되지는 않는다. SQL 문제만으로 해결되는 경우도 있지만 대다수 경우가 SQL 분석만으로는 한계를 느끼게 된다. 여기에서 필요한 것이 오라클 분석 방법론이다.

요즘 방법론 중에 가장 각광받고 있는 것이 OWI(Oracle Wait Interface)를 이용한 오라클 분석 방법론이다. 여기서 소개하는 MaxGauge는 OWI 방법론을 기반으로 구현된 DB 성능 모니터링 툴이다. 그럼 이제 OWI와 MaxGauge를 함께 알아보기로 하자.

   EVENT TIME_WAITED

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

   latch free 1,142,981

   db file sequential read 727,075

   enqueue 31,650

   db file scattered read 3,712

   log file switch completion 2,328

   local write wait 801

   file open 8

OWI 방법론 기반의 성능관리 ‘MaxGauge’

MaxGauge는 크게 리얼타임 모니터링(Real-Time Monitoring), 퍼포먼스 애널라이저(Performance Analyzer), 라이트플러스(LitePLus) 등 세부분으로 구성된다. 하지만 여기서는 리얼타임 모니터링, 퍼포먼스 애널라이저의 모든 기능들에 대해 장황하게 설명하기 보다는 이를 주요 기능 표로 대체하고, 사용자들이 필요로 하는 주요 기능들에 대해 중점적으로 설명하겠다. 또한 라이트플러스의 경우는 기존 SQL 에디팅(Editing) 툴인 웨어밸리의 오렌지, 퀘스트의 TOAD 등과 대부분 비슷한 기능이므로 여기서는 다루지 않겠다.

<표 1> MaxGauge의 주요 기능

MaxGauge의 SGA DIRECT ACCESS

최근 출시되는 DB 성능 모니터링 툴들은 대부분 SGA DIRECT 방식을 채택하고 있다. DB 성능 모니터링에서 1세대가 SQL*NET 방식이었다면 SGA DIRECT 방식은 진화한 2세대라고 할 수 있다. SGA DIRECT 방식은 쉽게 설명하면 OS 레벨에서 오라클이 사용하는 메모리 주소를 참조해 오라클 성능정보를 도출하는 것이다. 이 방식의 장점은 빠른 데이터 채집과 DB 행(Hang)이 발생했을 경우에도 정상적으로 데이터를 채집할 수 있다는 것이다. SGA DIRECT 방식의 단점은 수집된 데이터가 오라클 Dictonary에서 가져온 정보가 아니기 때문에 약간의 오차가 있다는 것이다.

그러면 SGA DIRECT 방식을 사용하는 DB 성능관리 툴이라면 모두 같은 것인가

결론부터 말하면 ‘NO’이다. 제품 컨셉과 기술력이 각각 다르기 때문이다. 가장 중요한 제품 컨셉의 경우 사용자가 어떤 뷰를 보고자 하는가에 대한 근본적인 물음에 대한 답이다. 어떤 제품은 SQL을 기반으로 할 수도 있고, MaxGauge처럼 OWI를 근간으로 하는 제품도 있을 수 있기 때문이다. 이 컨셉에 따라서 장애발생시 문제원인 파악의 신속성 여부나 활용빈도, 툴의 사용 또는 사장 여부 등이 결정되기 때문이다. 또한 기술력의 차이 또한 무시하지 못한다. SGA DIRECT 방식의 경우 일반적으로 SQL만을 대상으로 정보를 추출하게 되고 나머지는 SQL 쿼리를 통해 정보를 가져오게 된다. 하지만 현실은 SQL 말고도 다양한 문제가 발생할 수 있다.

예를 들면 LOCK이 과도하게 발생해 시스템의 정체를 유발했다면, SQL 쿼리를 통해서 정보를 추출할 경우 이 DB 성능정보 툴은 무용지물이 될 것이기 때문이다. 이에 비해 MaxGauge는 대부분의 기능을 SGA DIRECT 방식을 통해서 데이터를 채집하기 때문에 상대적으로 안정적으로 작동한다.

<그림 1> MaxGauge 데이터 채집방법

OWI와 MaxGauge, 호형호제하는 사이

OWI는 다양한 다이내믹 성능 뷰(dynamic performance views)들과 확장된 SQL 트레이스(trace) 파일로 구성되어 있다. 확장된 SQL 트레이스는 사용자가 직접 트레이스를 생성해야 하므로 제외하기로 하자.

V$로 시작하는 다이내믹 성능 뷰는 오라클에서 발생했던 현재와 과거의 성능정보 내역을 가지고 있는 보물창고다. 그런데 이 보물창고로 들어가는 길은 복잡한 미로로 되어 있어서, 보통 DBA들이 이 미로를 자력으로 찾아서 들어가기에는 너무나 많은 시간과 노력이 필요하다. 수많은 시행착오를 거쳐야 비로소 이 보물창고로 들어가는 문이 열리는 것이다. 하지만 MaxGauge를 사용한다면 약간의 노력으로 이 문에 들어설 수 있다.

MaxGauge의 메인화면에서 제공하는 지표들은 다이내믹 성능 뷰에서 핵심적인 내용을 추출해서 보여주게 되며 MaxGauge의 세션 매니저(Session Manager)에서는 현재 수행 중인 세션의 STAT과 웨이트(wait) 이벤트를 보여 준다.

또한 MaxGauge의 퍼포먼스 애널라이저는 오라클 9i에서는 아직 구현하지 못한 세션들의 STAT과 웨이트 이벤트의 과거 이력데이터를 시간 순으로 보여줄 수 있다. 만약 사용자가 직접 STAT과 웨이트 이벤트를 보기 원한다면 V$SESSTAT, V$SESSION_WAIT, V$STATNAME, V$PROCESS, V$SESSION, V$LATCHNAME 등 많은 다이내믹 성능 뷰들을 직접 조회해야 한다. 또한 이 뷰들을 알고 있다고 하더라도 조인 방법이나 구체적으로 이 지표들이 의미하는 바를 알기는 쉽지 않다. 하지만 MaxGauge를 사용한다면 좀 더 직관적으로 문제의 원인과 현재 DB 시스템의 상태를 파악하고 OWI의 과거데이터를 로깅할 수 있다.

<그림 2> MaxGauge 실시간 모니터링

액티브 세션이 왜 중요한가

액티브 세션(Active Session)은 시스템의 안정도를 나타내는 가장 중요한 척도이다. 시스템에서 액티브 세션을 찾는 방법은 V$SESSION의 상태가 ‘active’인 것을 찾는 것이다. 액티브 세션의 의미는 현재 오라클 시스템에서 실행되고 있는 세션을 총칭하는 것이다.

Active Session = background process + wait process + 현재 active한 user process

간혹 인액티브(Inactive) 세션이 lock holder로 문제를 일으키는 경우도 있지만 대부분의 문제는 액티브 세션에서 발생된다. 일반적으로 안정적인 시스템이라면 액티브 세션의 개수는 어느 한계 내에서 움직이게 되며 백그라운드 프로세스(background process)의 개수에 유저 프로세스(user process)가 실행시킨 몇 개 혹은 몇 수십 개의 프로세스의 개수가 더해져 현재 액티브 세션의 개수를 나타내게 된다. 따라서 액티브 세션의 개수가 일정한 한계치를 벗어나서 갑작스럽게 증가한다면 시스템에 문제가 생겼다는 것을 알 수 있다. 왜냐하면 작업들이 계속 작업 큐에 쌓여서 빠지지 않고 뒤에 들어오는 작업들도 작업 큐에 쌓이기 때문에 액티브 세션이 증가할 수밖에 없다. 즉 액티브 세션은 시스템에 문제가 발생하고 그 문제로 인해서 발생하는 후행적인 작업인 것이다. 여기서 액티브 세션이 증가한 문제의 원인을 찾기 위해서는 각각의 액티브 세션들이 어떤 웨이트 이벤트를 겪고 있는지, 어떤 STAT 지표가 증가하는지를 파악하는 것이 중요하다.

만약 많은 수의 세션들이 latch free에 대기 이벤트를 기다리고 있다면 latch의 종류를 파악하고 그에 따른 적절한 대처를 취해야 액티브 세션이 지속적으로 증가하는 것을 막을 수 있다. 이와 같이 문제가 발생하고 이를 해결하는 과정에서 MaxGauge는 많은 도움을 줄 수 있다. 왜냐하면 MaxGauge는 액티브 세션의 STAT과 웨이트 이벤트를 모니터링하고 서로 연계된 정보들을 한 화면에서 표현해 줄 수 있어 문제의 원인에 보다 쉽게 접근할 수 있는 것이다. 그리고 액티브 세션 내역을 그대로 로깅하기 때문에 문제가 발생한 후에도 발생한 문제를 심도 있게 분석할 수 있다.

실시간 모니터링의 유용성

현재 시스템이 어떤 상태인지, 어떤 프로그램이 어떤 SQL을 수행하는지, 어떤 STAT과 웨이트 이벤트를 발생시키는지, OS의 상황은 어떻게 되는지 등을 모른다면 사용자는 너무 답답한 상태가 될 것이다. 그리고 실시간으로 보여주기는 하는데 이게 도대체 무슨 의미가 있는지를 파악하려고 애쓰는 것은 시간 낭비적인 일이다. 직관적으로 사용자가 보고자 하는 많은 정보들을 한 화면에서 제공해 모니터링의 효율성을 높이는 것이 실시간 모니터링의 핵심이라고 할 수 있다.

MaxGauge 리얼타임 클라이언트(Real-Time Client)의 초기 화면에서는 개별 DB의 성능 및 대기지표와 OS 성능지표의 초당 변화치 및 그 변화 추이, 대기지표에 대한 집중 감시, 현 시점 SGA 사용량과 RAC의 모니터링, 오라클 Alert 로그의 변화 등을 동시에 하나의 화면에서 통합 모니터링한다. 따라서 실시간 감시 및 진단 업무를 신속하고 효율적으로 수행할 수 있고 또한 여러 개의 DB 인스턴스들에 대해서도 Top-Down 방식으로 보다 깊고 세밀한 정보들을 추적할 수 있다.

실제적으로 어느 정도 DB에 대한 지식이 있다면 처음 방문하는 사이트에서도 MaxGauge 리얼타임 클라이언트를 이용해, 단 몇 분간 실시간 모니터링을 해보면 그 시스템의 문제점이 hard parse가 많이 발생한 때문인지, latch free 이벤트의 과다 때문인지 등을 파악할 수 있을 것이다.

<그림 3-1> Top Down 접근방법

<그림 3-2> 다양한 정보에 대한 통합 모니터링

리모트 세션을 찾아라

대량의 데이터를 여러 서버에 분산해서 관리하는 경우 서울에서 관리하는 서버를 부산에서 접속, 정보를 조회할 수 있다. 이런 경우 관리 포인트가 여러 곳에 분산되어 있기 때문에 DB 성능 모니터링의 책임 소재가 불분명해져서 서울의 DBA는 항상 불안하게 된다. 언제 어떤 프로그램이 DB 링크로 접속해서 시스템에 얼마나 부하를 유발할지 아무도 장담할 수 없기 때문이다. 분산 트랜잭션의 분석이 어려운 경우가 여기에 있다. 도대체 어디서 어떤 경로로 어떤 작업이 수행되는지를 파악할 수 없기 때문이다.

MaxGauge는 리모트 세션(Remote Session)을 통해 특정 데이터베이스에 대해서 수행되는 분산 트랜잭션을 지역/원격 세션의 연관 관계에 따른 계층화된 구조로 표현함으로써 사용자들이 신속하고, 손쉽게 추적할 수 있게 해준다. 하지만 해당 리모트 데이터베이스가 MaxGauge에 접속되어 있지 않으면 로컬 세션만 나타난다는 것이 아쉬운 점이다.

<그림 4> 리모트 세션 모니터링

퍼포먼스 애널라이저의 다양한 분석

MaxGauge의 그래프는 모든 지표를 24시간 추이 그래프로 표시한다. 이 방식의 장점은 로그 데이터를 하루 단위로 분류함으로써 로그를 찾고 저장하고 피크 시점을 분석하는 작업을 용이하게 한다는 것이다. 또한 한 개의 STAT과 웨이트 이벤트만을 보는 것이 아니라 동시에 여러 개의 중요 OWI 지표들을 분석하기 때문에 정보의 연관관계를 빠르게 파악할 수 있다. 분석한 STAT과 웨이트 이벤트 지표에 따른 액티브 세션 분석 또한 연계되어서 분석해야할 대상이다.

MaxGauge의 그래프는 모든 지표를 24시간 추이 그래프로 표시한다. 이 방식의 장점은 로그 데이터를 하루 단위로 분류함으로써 로그를 찾고 저장하고 피크 시점을 분석하는 작업을 용이하게 한다는 것이다. 또한 한 개의 STAT과 웨이트 이벤트만을 보는 것이 아니라 동시에 여러 개의 중요 OWI 지표들을 분석하기 때문에 정보의 연관관계를 빠르게 파악할 수 있다. 분석한 STAT과 웨이트 이벤트 지표에 따른 액티브 세션 분석 또한 연계되어서 분석해야할 대상이다.

<그림 5> 퍼포먼스 애널라이저의 24시간 추이 그래프

퍼포먼스 애널라이저와 STATSPACK

오라클은 오라클 8.1.6 버전부터 성능 데이터의 수집과 저장을 위한 유틸리티인 STATspack을 제공해오고 있다. STATspack은 OWI를 이용해 TOP 웨이트 이벤트 등의 유용한 정보를 제공한다. 하지만 STATspack의 가장 큰 단점은 인스턴스 레벨의 진단 데이터를 제공하기 때문에 근본 원인 분석에는 취약하다는 것이다. STATspack은 해당 세션 레벨의 스냅샷을 제공할 수는 있지만, 그 기능은 데이터베이스에 접속된 모든 세션들을 추적하기 위해 설계된 것은 아니다. 따라서 STATspack이 모든 성능 데이터 수집기로는 적합하지 않다고 본다. STATspack에서 만약 모든 세션에 대한 스냅샵을 만들려고 한다면 분명 시스템에 많은 부하를 유발할 가능성이 있기 때문이다.

MaxGauge의 퍼포먼스 애널라이저는 STATspack의 단점을 해소하면서 기존에 STATspack에서 제공하는 정보보다 더 많은 정보를 제공하고 시스템의 부하는 극적으로 감소시켰다. 퍼포먼스 애널라이저의 기본 데이터는 1초 마다 로깅된 액티브 세션과 V$SYSSTAT, V$SESSTAT에 들어있는 전체 인스턴스 정보, OS 프로세스 정보, 최대 1초에 99번의 SQL 채집 등 거의 실시간과 마찬가지로 시스템을 분석할 수 있다.

<그림 6> MaxGauge을 통한 과거 로그 분석

RAC를 정복하라

최근 몇 년 동안 오라클은 고가용성(High Availability), 장애예방(Fault Tolerance) 및 하드웨어 투자에 대한 높은 투자대비 효과를 위해 RAC(Real Application Clusters)의 사용을 권장하고 있다. 최근 구축되는 대형 프로젝트에서 RAC를 이용한 구축사례를 많이 찾아볼 수 있는데 이는 시스템의 안정성을 최우선으로 하는 환경에서는 당연한 결과라고 본다.

하지만 RAC의 대기 이벤트는 다소 특별하다. RAC 환경에서는 싱글 인스턴스 환경과는 다른 방식으로 동작하게 된다. 여러 개의 인스턴스는 하나의 데이터베이스를 공유하게 되며 이러한 인스턴스들은 일반적으로 각각 다른 서버 또는 노드들에서 수행된다. 이런 이유로 RAC만의 특화된 모니터링이 DB 성능 모니터링에서 필수적으로 요구되고 있다.

MaxGauge에서는 RAC 환경에 대해 특별한 모니터링 화면을 제공하고 있다. RAC 백그라운드 프로세스만을 집중적으로 모니터링 하고, RAC 환경에서 가장 중요한 다른 노드들 간의 블럭(Block) 교환 현황, 클러스터 환경으로 인해 발생되는 클로벌 캐시(global cache) 대기들에 대해서도 특화된 화면으로 제공하고 있다.

<그림 7> 특화된 RAC 모니터링

Alerting의 한계는

DB 성능관리 툴에서 Alerting 기능이야 말로 DBA에게 진정으로 필요한 기능이라고 할 수 있다. 만약 특정 테이블 스페이스(Table Space)가 한계치에 도달하는 상황이 발생해서 현업에서 다급한 전화가 오고 그때서야 조치를 한다면 이미 늦었다고 할 수 있기 때문이다. DBA가 상당히 부지런하고 데이터의 증가 형태가 일정하다면 어느 정도 조치가 가능하겠지만 현실에서는 누구도 장담할 수 없는 상황에 종종 부딪치게 된다. 그리고 LOCK이 발생했다는 경고는 어느 툴에서나 가능하지만 순간적으로 LOCK이 발생하고 해소가 된다면 쓸데없는 경고음만 사무실에 가득하게 된다. 이와 같이 Alerting이 발생할 수 있는 여러 가지 상황을 고려해 가장 필요한, 최소한의 Alerting으로 DBA에게 문제 상황을 인지시켜줄 수 있다면 가장 훌륭한 Alerting이라고 할 수 있다.

MaxGauge의 실시간 Alerting 기능은 다양한 형태로 활용 가능하다. 테이블 스페이스 부족뿐 아니라 로(Raw) 디바이스의 용량 부족, STAT, 웨이트 이벤트, OS 성능 정보, 그리고 특정 웨이트 이벤트의 지속 시간에 의한 경고 등 DB 성능 모니터링에서 필요한 모든 것들에 대해 Alerting이 구현돼 있다. 그리고 Alerting 정보는 일회용이 아니라 기타 성능 정보처럼 로깅이 되어 향후 Alerting 현황을 리포트하고 분석할 수 있게 화면을 제공한다.

<그림 8> MaxGauge가 제공하는 다양한 Alerting

웨이트 이벤트를 통한 SQL 추출

OWI를 이용한 웨이트 이벤트에 익숙해졌을 때 이제 모든 것을 웨이트 이벤트를 중심으로 분석하는 습관을 들이게 된다. 웨이트 이벤트에서 제공하는 정보는 아주 다양하다. 예를 들면 DB file scattered read는 대부분의 경우 Table Full Scan을 의미하며 DB file sequencial read는 Index Range Scan을 의미한다. 이런 아이디어를 가지고 MaxGauge는 기존 툴과는 다르게 SQL 플랜 없이 테이블을 full scan하는 SQL들과, 과도한 index range scan을 하는 SQL들을 웨이트 이벤트에서 추출할 수 있게 됐다. 또한 시스템 분석에서 반드시 필요한 TOP 웨이트 이벤트, TOP STAT 리스트도 함께 제공된다.

<그림 9-1> STAT과 웨이트 이벤트 조회

<그림 9-2> FULL TABLE SCAN SQL 추출

MaxGauge의 진화 방향

성능 관리 툴은 진화하고 있다. 예를 들면 최근 신규 구축하는 사이트는 대부분 RAC로 구축하고 있다. 하지만 지금까지 어떤 모니터링 툴도 RAC에 대한 적절한 뷰를 제공하지 않았다. 또한 각 DBA마다 자기의 시스템에서 발생하는 다양한 문제점들에 따라 그에 맞는 특화된 뷰를 요구하고 있다. 이는 당연한 요구이며 이를 수용, 시기적절하게 대응할 수 있다는 것이 국산 솔루션의 장점 중 하나라고 볼 수 있다.

이런 일환으로 MaxGauge의 2005년 6월 릴리즈에는 RAC 만을 특화시켜서 모니터링하고 로깅하는 기능이 구현 됐다. 또한 Alerting 기능은 기존에 오라클 관련 STAT과 웨이트 이벤트, 그리고 시스템의 CPU, 메모리 뿐 아니라 RAC 웨이트 이벤트, 테이블 스페이스 용량, 로 디바이스의 잔여량 등을 확인할 수 있도록 Alerting 대상이 계속 추가되고 있다.

하지만 MaxGauge는 적은 수의 DBA로 많은 DB를 관리하는 데 필요한 기능들이 아직 부족하다. 몇 십대의 DB를 동시에 모니터링 할 수 있는 압축된 화면, 보다 편리한 사용자 인터페이스, 그리고 자동화된 분석 기능 등은 MaxGauge에 보강되어야 할 부분이다.

이와 함께 다음 버전에서는 대부분 툴에 구현이 되어 있지만, 유명무실한 인덱스 시뮬레이션 기능을 지원, 보강하고 기존 툴의 불확실한 SQL 튜닝 가이드를 대신해 DB 컨설턴트들이 작성한 리포트 수준의 완성도 높은 자가 진단 기능 리포트를 추가하는 것 등이 보완됐으면 한다.

마지막으로 1200년 전에 이미 변화와 혁신의 시대정신으로 살았던, 유목민 톤유쿠크 장군의 비문을 소개하고자 한다. “그 자리에 성을 쌓고 머무는 자 망할 것이요, 끊임없이 이동하는 자 영원히 살 것이다.”

기획ㆍ진행 | 기묘 컨텐츠 제작팀(heyjude@gimyo.com)