웨어밸리 구축사례

“가벼움의 미학! 신속, 간단한 모니터링이 매력”

이민성 │현대정보기술 IDC 기술팀

세상이 빠르게 변하듯 기술 변화도 그렇다. 기업도 이러한 변화 속도에 부합하기 위해 노력하고 있으며, 이를 지원하는 기업 조직 중 IT 부서는 많은 고민과 노력을 하고 있다. 시스템의 복잡과 다양화는 시스템 관리하는데 요구되는 시간과 인력을 더 필요로 한다.

기업의 시스템 중 중요한 위치를 차지하고 있는 데이터베이스 시스템을 예를 들어보면, 요즘 웬만한 기업의 DBA들은 1인당 최소 2개 이상의 DB 인스턴스를 관리하고 있고 심지어는 10개 이상의 Production 인스턴스와 개발 장비의 인스턴스까지 관리하기도 한다. 여기에 개발 인력들의 짧은 경력 기간에 따른 비효율적인 SQL 구사력과 데이터베이스에 대한 이해력 부족으로 유발되는 문제까지 지원하게 된다면 DBA의 작업 부담은 더 늘어날 것이다.

DB 모니터링 툴이 필요한 이유

아무리 실력과 의욕을 갖춘 DBA라고 하더라도 이처럼 관리 대상이 많다면, 자연히 당면한 문제 사항에 대한 즉각적인 대응 위주로 작업을 하게 되기 때문에 시스템 및 데이터베이스의 전반적인 성능 관리 부분에 대해 거시적인 분석과 대응을 하기가 사실상 힘들다.

특히 데이터베이스가 비정상적 상황일 경우에는 Hot Spot 시점과 주원인을 찾는 것이 일차적인 목표이고 성능 변화 추이 분석까지도 가능해야 하는데, 기존에 보유하고 있는 스크립트 기반의 문제 해결 방식으로는 분명 한계를 갖고 있다.

프로젝트를 진행하는 과정에서도 성능 관리는 중요한 부분이다. 대부분 데이터베이스의 생성과 오브젝트 관리를 철저히 시행했으면 시스템을 오픈한 후에도 큰 문제가 없을 것이다. 하지만 운영 시스템은 시간이 흐를수록 새로운 기능과 요구 사항을 반영하기 위해 조금씩 변해간다. 그러므로 시스템 튜닝이 필요하며, 3개월이나 6개월을 주기로 수행하는 것이 일반적이다.

이와 함께 꾸준한 모니터링으로 문제 요소를 사전에 파악해 장애가 발생하기 전 조치를 취하는 것이 이상적인 시스템 관리 방법이다. 그러나 현실적으로 오라클 데이터베이스를 관리하는 많은 관리자들의 공통적인 문제점은 분명히 데이터베이스에 성능 문제가 있는데 무엇 때문에 느려지는지를 명확히 모른다는 것과 기존의 스크립트 기반의 방식으로는 성능 및 문제 관련 요소들의 상관관계를 파악해 문제를 탐지, 원인을 규명하는데 많은 시간이 소요된다는 것이다. 이처럼 문제 현상이 길어지거나 문제 원인 정보를 요청한 사용자에게 적시에 제공하기 어렵기 때문에 개발자뿐만 아니라 DBA까지도 가벼우면서 사용하기 쉽고 직관적인 GUI 인터페이스를 제공하는 모니터링 툴을 필요로 하는 것이다.

오렌지, 2개 이상 DB 운용하는 중소기업에 최적

그렇다고 이러한 요구사항을 충족하기 위해 억대를 호가하는 툴을 반드시 사용해야만 하는 것은 아니다. 사용 목적과 필요한 기능의 제공 여부가 툴 선정의 중요 기준이 됨과 동시에 사용 용이성, 유지 보수(교육 포함) 그리고 매력적인 가격 경쟁력까지 취할 수 있다면 더할 나위 없이 좋다고 본다.

이러한 사용자와 DBA의 욕구를 충족시켜줄 수 있는 대표적인 것이 국산 툴인 웨어밸리의 오렌지(Orange)다. 오렌지는 여러 시스템에 복수의 데이터베이스를 운영하는 환경과 개발자, DBA 모두에게 중급 수준의 데이터베이스 운영 기능을 제공하는 툴을 필요로 하는 중·소 규모 기업 또는 대규모 기업의 부서 단위 업무용으로 적합하다. 하지만 SQL 튜닝 기능, 정보 시스템 각 구성 요소 간의 상관관계와 성능 관련 정보를 저장소에 저장해 사후 분석을 필요로 하는 애플리케이션 성능 관리 관점의 툴을 필요로 하는 기업에게는 보다 고가의, 기능이 많은 다른 툴을 권고하고 싶다.

이 글에서는 오렌지 4개 버전 중 DBA 측면의 유용한 기능이 풍부한 ‘Orange for Oracle V3.1 DBA Extended Edition’이 현장에서 어떻게 구축, 활용되고 있는지 알아보기 위해 현대백화점의 활용 사례를 소개하고자 한다. 오렌지가 개발자나 DBA에게 제공하는 기능은 풍부하나 여기에서는 특히 데이터베이스 모니터링과 운영간 발생하는 문제점을 파악, 조치하는데 필요한 오렌지의 활용법에 대해 주로 살펴본다.

현대백화점의 오렌지 도입 이유

현대정보기술 IDC(Internet Data Center)에서는 현대그룹 계열사의 주요 시스템에 대해 업무 분석, 설계, 구축, 운영, 관리 등의 업무 전체를 위탁받아 서비스를 제공하는 호스팅 서비스를 제공하고 있으며, 이중 현대백화점은 최근 주요 업무를 메인프레임에서 오픈 시스템 환경으로 다운사이징을 수행하고 있어 시스템 아키텍처, 애플리케이션 등 모든 측면에서 많은 변화가 진행되고 있다. 변화에 도전하는 것에는 항상 난관이 따르게 마련이듯 많은 애플리케이션의 개발이 동시에 진행되고, 이를 수행하는 비즈니스 파트너 회사 개발 인력의 개발 능력 차이로 인해 혼란을 겪고 있었다.

현대백화점은 개발을 진행하는 개발 인원의 데이터베이스에 대한 이해와 기술력이 제각각이고 개발 업무를 지원하는 DBA 간의 이슈 사항에 대한 의사소통 어려움, 애플리케이션 개발, 전개 그리고 운영 단계에서 발생하는 문제 해결 어려움 등을 해결하기 위해 사용이 용이하고, 서버에 부하를 주지 않으면서 가격이 저렴한 모니터링 툴 도입을 검토하게 됐다.

DB 문제 때문에 개발에 집중할 수가 없어!

오렌지는 이러한 요구 조건을 충족해 현대백화점에서 검토, 선정 그리고 구축될 수 있었으며, 현대백화점은 오렌지 구축 이후 사용자(개발자)·개발 DBA·운영 DBA 간의 업무 구분, 사용자의 긴급 조치 능력 향상, 문제 원인 탐지 시간의 감소, 문제 원인 정보 공유, 의사소통 활성화, 모니터링 표준 툴 정립 등의 도입 효과를 얻을 수 있었다.

<그림 1> 현대백화점 시스템 구성도

<그림 1>의 시스템 구성도는 오렌지가 현대백화점의 고객사랑 시스템과 RIS(Resource Information System, 영업 지원 시스템)의 데이터베이스에 설치, 구축, 운영해오던 중 신용판매(백화점과 현태카드의 연합카드), CRM, 사은품, 배송, 고객의 소리, 의류 단품, 문화센터, 법인IR 시스템의 데이터베이스에 확대 설치해 운영하게 된 것을 표현한 것이며, 오라클 8i 버전부터 오라클 10g 버전까지 다양한 오라클 데이터베이스를 운영 중이다. 특히 데이터 연관도 및 흐름 측면에서 보면 신용판매, RIS, 고객사랑, CRM, 사은품, 문화 센터 데이터베이스는 밀접한 관계가 있다. 이러한 시스템간 연관성 또한 오렌지 기반 모니터링 체계를 구축해야하는 요인이 됐다.

사용 용이, 최소한의 서버 부하, 가격 저렴 OK

최종 사용자나 DBA가 해당 데이터베이스를 모니터링 하는데 별도의 중앙 콘솔이 필요 없이 기본 설정이 되어있는 윈도우 사용자가 타깃 서버에 직접 접속해 데이터베이스 정보 조회, 변경 그리고 모니터링을 할 수 있다.

타 툴은 서버별 별도의 라이선스를 구매해야 하지만, 오렌지는 클라이언트 사용자 수에 대한 라이선스만을 지불하면 몇 개의 데이터베이스를 모니터링 하는데 제한이 없다. 이는 타 툴은 하나의 라이선스를 구매 후 단 하나의 서버에만 설치, 모니터링이 가능한데 비하면 매우 차별되는 특징이라 할 수 있다.

또한 설치가 매우 쉬어 오라클 데이터베이스나 툴에 대한 경험이 적은 사용자에 의해서도 직접 설치가 가능하다. 오렌지는 개발자용과 DBA용 버전을 제공하므로 각 사용자나 사이트의 필요에 맞는 버전 적용이 가능하다.

◆ 현대백화점의 오렌지 도입 이유

• 신속·간단한 문제 원인 탐지 및 정보 파악
• 서버 부하를 주지 않고 사용자에게 용이한 조작성
• 한 눈에 DB 상태 파악 가능한 그래픽 유저 인터페이스(GUI) 기반 지속적인 모니터링 툴 필요
• 사용자 독립적인 표준 툴 필요성 증가
• 순수 국내 기술로 개발되어 제공 기능에 비해 저렴한 가격

현대백화점의 DB 문제 발생 및 해결 사례

DB 관리, 문제의 주 원인(Root Cause)를 어떻게 신속히 탐지해내는가

이제부터 본격적으로 데이터베이스 내에서 자주 문제시되고, 병목 현상이 많이 발생할 수 있는 부분의 상태를 파악하는 방법에 대해 알아보자.

현대백화점 데이터베이스 사용, 특정 세션이 Locking을 유발해 저하나 웨이트 이벤트(wait event)가 증가하는 문제가 발생해 서비스 제공에 영향을 미치게 된다. 이를 탐지, 조치하는데 오렌지의 세션 모니터, 락/래치 모니터, 인스턴스 모니터가 주로 활용된다.

먼저 Top OS 프로세스를 추적해 탑 세션을 찾는 경우에서 스크립트 기반(Command Level Interface)의 전통적인 방식을 활용하는 방법과 오렌지 툴을 활용하는 방법을 함께 제시해 두 방법 간의 오퍼레이션 신속성과 간단성 면에서 비교해보자.

Top OS 프로세스 추적하기

"미꾸라지 한 마리가 물을 흐린다"는 속담에 적합한 경우이다. 특정 탑 프로세스 하나가 시스템 전체에 영향을 미친다. 현대백화점 전국 매장은 오전 10시에 일제히 업무가 시작된다. IT실 직원들은 업무 오픈 전 짧은 시간에 많은 일을 한다. 간단한 집계 작업이나 프로그램 수정·적용 등의 업무가 그것이다.

현대백화점 트랜잭션 스타일은 주로 OLTP(Online Transaction Processing)인데, 갑자기 시스템 CPU 리소스 사용률이 100% 도달하며 큐에 대기하는 프로세스 수도 비례하여 증가한다. 이렇게 되면 사용자 애플리케이션의 속 빗발치게 되는 상황이 연출된다. 이런 상황이 발생하면, 개발자는 운영 DBA에게 전화를 걸게 마련이다. 운영 DBA는 OS상의 CPU 리소스 사용률을 파악한 후에 다음과 같은 스크립트를 실행해 문제 프로세스가 실제 무엇을 하는지에 대한 정보를 찾기 시작한다.

<리스트 1>의 SQL은 필자가 자주 이용하는 스크립트로, 문제되는 프로세스나 세션의 실마리를 알게 되면 해당 세션의 모든 정보를 확인할 수 있다. 이는 서버 프로세스의 pid나 세션의 sid, 클라이언트의 machine 이름 등을 알 경우 v$process와 v$session의 정보를 보여주는 스크립트이다.

<리스트 1> sess.sql 스크립트

clear columns

col “Session Info”form a80

accept sid prompt ‘Please enter the value for Sid if known : ‘

accept terminal prompt ‘Please enter the value for terminal if known : ‘

accept machine prompt ‘Please enter the machine name if known : ‘

accept process prompt ‘Please enter the value for Client Process if known : ‘

accept spid prompt ‘Please enter the value for Server Process if known : ‘

accept osuser prompt ‘Please enter the value for OS User if known : ‘

accept machine prompt ‘Please enter the value for machine if known : ‘

select

‘ Sid,Serial#,Aud sid,Oracle pid : ‘||s.sid||’, ‘||s.serial#||’, ‘||s.audsid

||’, ‘||p.pid||’(‘|| s.status || ‘)’|| chr(10)||

‘ ClientMachine , ClientTerminal : ‘||s.machine||’, ‘|| s.terminal||chr(10)||

‘ ClientProgramName : ‘||s.program ||chr(10)||

‘ ClientModule : ‘||s.module||chr(10)||

‘ DBuser , OSuser : ‘||s.username||’, ‘||s.osuser|| chr(10)||

‘ OS Process Ids : ‘||s.process||’(Client) ‘||p.spid||’(Server)’|| chr(10)||

‘ Waiting for : ‘||w.event ||’(‘||w.seconds_in_wait||’secs)’|| chr(10) ||

‘ Command : ‘||

substr(decode(s.command, 1, ‘Create Table’, 2, ‘Insert’, 3, ‘Select’,

4, ‘Create Cluster’, 5, ‘Alter Cluster’, 6, ‘Update’,

7, ‘Delete’, 8, ‘Drop’, 9, ‘Create Index’,

10, ‘Drop Index’, 11, ‘Alter Index’, 12, ‘Drop Table’,

15, ‘Alter Table’, 17, ‘Grant’, 18, ‘Revoke’,

19, ‘Create Synonym’,20, ‘Drop Synonym’, 21, ‘Create View’,

22, ‘Drop View’, 26, ‘Lock Table’, 30, ‘Audit’,

31, ‘No Audit’, 44, ‘Commit’, 45, ‘Rollback’,

46, ‘Savepoint’, ‘Other: ‘ || to_char(s.command)),1, 20) “Session Info”

from v$session s,

v$process p,

v$session_wait w

where s.paddr = p.addr

and s.sid = w.sid(+)

and s.sid = nvl(‘&SID’,s.sid)

and nvl(s.process,’‘) = nvl(‘&Process’,nvl(s.process,’‘))

and p.spid = nvl(‘&spid’,p.spid)

and nvl(s.osuser,’‘) = nvl(‘&OSUser’,nvl(s.osuser,’‘))

and nvl(s.machine,’‘) = nvl(‘&machine’,nvl(s.machine,’‘))

and ‘&SID’||’&TERMINAL’||’&PROCESS’||’&SPID’||’&OSUSER’||’&machine’is not null;

<리스트 2> 29755 프로세스

$top

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND

29755 oracle8i 20 0 55632 54M 41988 R 22.4 21.8 0:29 oracle

29751 oracle8i 17 0 56880 55M 43228 R 21.8 22.3 0:31 oracle

29753 oracle8i 18 0 55796 54M 42148 R 20.8 21.8 0:30 oracle

$ ps -ef | grep 29755

oracle8i 29754 28265 11 21:17 pts/6 00:00:49 exp file=c full=y

oracle8i 29755 29754 20 21:17  00:01:32 oracleORA816 (DESCRIPTION=(LOCAL

이 세션에 대한 좀 더 자세한 정보를 얻기 위해서는 다음과 같이 sess.sql을 수행시킨다.

<리스트 3>의 결과로 알신이 AIX5L이므로 AIX5L 서버에서 수행된 클라이언트 프로그램임을 알 수 있고, 프로그램 이름이 exp@AIX5L이므로 export를 수행하는 것을 알 수 있다. 또한 데이터베이cle9i이다.

마지막으로 현재 수행되는스나 데이터베이스 세션을 찾았을 때 마지막으로 어떤 프로그램인지, 누가 수행한 것인지를 확인할 수 있고, 문제 상황을 종료하기 위해서 프로세스를 중단하려면, 데이터베이스의 sid, serial# 값을 알아내 별도의 SQL 문장을 수행해야 정리가 가능하다.

<리스트 3> sess.sql를 이용한 데이터베이스 세션 정보 보기

SQL> @sess

Please enter the value for Sid if known :

Please enter the value for terminal if known :

Please enter the machine name if known :

Please enter the value for Client Process if known :

Please enter the value for Server Process if known : 29755

← 입력값(OS의 프로세스 번호)

Please enter the value for OS User if known :

Please enter the value for machine if known :

Session Info

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

Sid,Serial#,Aud sid,Oracle pid : 12 , 7092 , 20058 , 14 (INACTIVE)

ClientMachine , ClientTerminal : AIX5L , pts/6

ClientProgramName : exp@AIX5L (TNS V1-V3)

ClientModule :

DBuser , OSuser : SYSTEM , oracle9i

OS Process Ids : 29754 (Client) 29755 (Server)

Waiting for : SQL*Net message from client (0 secs)

Command : Select

톱 세션 찾기

톱 세션(Top Session)이란 현재 접속해 있는 세션 중에 임의의 자원을 가장 많이 사용하는 세션을 말하는 것으로, 이는 시스템 이벤트의 통계 뷰에서 참조할 수 있다. 세션 통계 뷰는 v$sesstat에 있으며, 이를 이용해 200여 개의 통계정보 중에 관심 있는 자원을 많이 사용하는 세션을 찾아낸다.

<리스트 4> 관심 있는 통계치의 톱 세션 찾기(예: session logical reads를 찾아보기)

SQL>select *

from (

select /*+ ordered */ SID, NAME, valuef

from v$statname n, v$sesstat s

where s.statistic# = n.statistic#

and n.name = ‘session logical reads’

order by value desc

)

where rownum < 11;

SID NAME VALUE

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

7 session logical reads 2809185

9 session logical reads 2279330

5 session logical reads 1180682

19 session logical reads 835337

15 session logical reads 203717

24 session logical reads 159137

28 session logical reads 56738

26 session logical reads 15047

11 session logical reads 14777

20 session logical reads 11512

SQL> @sess

Please enter the value for Sid if known : 7

Session Info

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

Sid,Serial#,Aud sid,Oracle pid : 7 , 3577 , 20874 , 11 (INACTIVE)

ClientMachine , ClientTerminal : HIT-IDC, MSLEE

ClientProgramName : Orange.exe

ClientModule : Orange for ORACLE

DBuser , OSuser : SYS , mslee

OS Process Ids : 980:1128 (Client) 6686 (Server)

Waiting for : SQL*Net message from client (2 secs)

Command : Other: 0

<리스트 4>의 결과로는 7번 세션이 현재 접속한 세션 중에 ‘session logical reads’를 가장 많이 사용하는 세션으로, sess.sql을 이용해 7번 세션이 mslee client에서 Orange.exe를 사용하는 것을 알 수 있다. 즉 개발자가 임의의 작업을 하기 위해 오렌지 툴을 사용하며 현재 많은 SQL을 수행해서 가장 logical read가 많은 것을 알 수 있다.

지금 사용한 예로는 ‘seesion logical reads’를 이용한 것인데, 데이터베이스 내에는 약 219개의(8i v$statname에서 확인 가능) 통계 값이 있으므로 원하는 값들의 톱 세션을 찾아 문제 해결을 해야 할 것이다.

오렌지의 세션 모니터링 기능 활용

그런데 10분간 10초 간격으로 정보를 얻고자 한다면, 툴이 없는 기업은 사용자가 수작업으로 10초 간격으로 10분간 스크립트를 실행시키거나 프로시저를 작성해 스케줄러를 사용하는 방법을 고려해야 한다. 그러나 아쉬운 것은 이러한 스크립트를 사용자 모두가 보유하고 있는 것은 아니며, 사용하기 불편한 CLI(Command Level Interface)라서 여러 번의 오퍼레이션과 많은 시간이 소요돼 비효율적이라는 것이다.

문제 상황 발생, 인지 즉시 신속하게 문제 원인을 파악, 조치하지 못한다면, 현대백화점 내 사용자들은 업무 처리가 지연되어 당황할 것임에 틀림없다. 물론 고객들의 불편과 불만도 높아질 것이다.

그러나 오렌지 툴을 활용하면 수작업으로 조회하는 것보다 단 정보를 신속·간단하게 정보의 추하게 문제 조치 후 파악한 문제 정보를 현대백화점 개발자에게 피드백 해 줘서니터에서 옵션 중 필터 탭에서 모듈과 프로그램에 대해 exclude만 가능하고 include는 없는 것이 아쉽다.

<그림 3> 오렌지 세션 모니터를 활용해 탑 세션 찾기와 세부 정보 보기

Lock Holder 찾기

데이터베이스 웨이팅 중에서 Lock에 대한 웨이팅은 불필요한 대기 현상이다. 많은 사용자들이 이러한 구조적인 문제가 있는 애플리케이션을 갖고 있다. 애플리케이션에서 트랜잭션이 발생한 후에 빠른 시간에 작업을 마치고 commit이나 롤백을 하지 않을 때, 동일한 애플리케이션이나 다른 애플리케이션에 의해 동일한 데이터에 대한 DML 작업이 발생할 경우에는 lock에 대한 웨이팅이 불가피하다.

현대백화점에서도 종종 이런 문제를 겪는데, 업무 오픈 전 시간을 이용 집계 프로그램을 실행시킨 후 동일 리소스에 대한 경합 문제로 다른 트랜잭션 처리에 지장을 주는 문제가 되는 상황이 발생한다. 이런 문제도 신속하게 조치하지 않으면, 애플리케이션의 속도 저하는 물론이고 시스템 전체의 행(Hang) 상태까지 초래할 수 있다. 이럴 경우 Locking Holder를 파악해 해당 세션을 강제 종료함으로써 다른 트랜잭션이 정상 처리되도록 막힌 길을 뚫어 준다.

Lock에 의한 웨이팅 증가로 시스템 부하가 급격히 증가해 애플리케이션 반응 시간이 길어지는 상황이 발생됐을 때, 이러한 locking을 유발한 프로세스, 프로그램, 세션 정보, SQL Text에 대한 정보를 캡쳐해 놓은 상태(사후 분석 용도)에서 비상조치로 문제의 해당 프로세스를 중단하는 처리를 어떻게 할 수 있을까 물론 스크립트 기반의 방식도 있다.

<리스트 5> Lock Holder와 Waiter 찾기

select lpad(‘‘,decode(a.request,0,0,3))||a.sid sid,

a.id1,a.lmode,a.request,c.name ObjName,

s.program Program,

s.process Client,

p.spid Server

from sys.obj$ c,v$lock b,v$lock a,v$session s, v$process p

where a.id1 in ( select id1 from v$lock where lmode = 0 )

and a.sid = b.sid

and c.obj# = b.id1

and b.type = ‘TM’

and a.sid=s.sid

and s.paddr = p.addr

order by a.id1,a.request,b.sid,c.name

/

SID ID1 LMODE REQUEST OBJNAME PROGRAM CLIENT SERVER

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

16 131103 6 0 DEPT sqlplus@AIX5L (TNS V1-V3) 30447 30448

22 131103 0 6 DEPT sqlplus@AIX5L (TNS V1-V3) 30501 30502

13 196637 6 0 EMP sqlplus@AIX5L (TNS V1-V3) 7402 7403

8 196637 0 6 EMP sqlplus@AIX5L (TNS V1-V3) 7404 7405

주기적으로 lock holder와 waiter가 있는지 확인해 lock holder 프로그램의 구조적인 문제를 파악해서 Lock을 오랜 시간 잡 Lock/Latch 모니의 방식은 문제 순간에 활용하기에는 용이하지만, 주 하는 상황에서는 부적합할 수밖에 없다. 꼼짝하지 않고 사다. 오렌지 Lock/Latch 모니터에서 Lock Holder에 시간 임계치를 설정, Lock Holder가 해당 임계치를 초과할 경우 경고 팝업 윈도우를 띄워 통지해 주는 기능이 부가되었으면 하는 아쉬움이 있다.

<그림 4> 오렌지 Lock/Latch 모니터를 활용 Lock holder 찾기와 Holder 세션 강제 종료

데이터베이스에서 웨이트 이벤트 확인하기

모니터링 할 때 가장 기본적으로 확인해야 하는 것은 어떤 세션들이 작업 중에 ‘웨이팅이 있는가’로, 어떤 종류의 자원을 얻기 위해 웨이팅을 하고 있는지를 파악하는 것이다.

웨이팅이란 임의의 작업을 수행하는 과정에 사용하고자 하는 특정 자원을 요청했으나 다른 사용자가 이미 이 자원을 사용하고 있기 때문에 대기 현상이 발생하는 것이다. 튜닝의 목적은 이러한 웨이팅이 없이 모든 작업을 원활히 진행할 수 있도록 구성해 주는 것이다. 웨이팅 종류도 상당히 많으며 오라클 8i의 경우에는 약 210개 정도의 웨이트(wait) 종류가 있다.

현대백화점 경우 데이터베이스 시스템이 정상이었는데, 사용자들이 성능에 대한 불만을 토로할 때 “평소에는 3초 정도면 결과가 나오는데 지금은 20초 이상을 기다려도 끝나지 않는다”라고 말하곤 한다. 스크립트를 사용한다면, 현재의 성능 지표 값만 알 수 있으므로 문제 발생 시점의 과거와 현재를 비교할 기준이 없다는 것이다.

어떻게 조치할 것인가 문제 세션을 찾아 종료해주는 방법이 최고이다. 그러나 문제는 이것이 사후 조치에 불과하다는 것이다.

오렌지의 인스턴스 모니터링 기능 활용

현대백화점에는 데이터베이스에 문제가 있다. 예를 들어 갑자기 데이터베이스 버퍼 캐시 히트율이 저하되고, 웨이트 이벤트의 Full Scan 이벤트가 상승하는 경우가 발생했다. 이되면 세션 모니터에서 탑 세션 중 Full Scan을 유발하는 세션을 찾아 해당 정보를 개발자에게 제공해 애플리케이션 수정이나 인덱스를 추가해 문제를 해결할 수 있다. 문제가 지속되어 표면화되기 이전에 문제 징후를 포착, 처리하는 것이 사전 조치이며 이런 조치를 현대백화점은 원하고 있다.

오렌지는 인스턴스 모니터에서 웨이트 이벤트에 대한 추이를 보여주지만 설정된 주요 이벤트 이외의 이벤트는 ‘Other Events’로 표시되어 문제 웨이트 이벤트가 Other Events 범주에 포함되는 것이면 주요 이벤트처럼 이벤트 이름을 바로 알 수 없다는 단점이 있다.

그러므로 데이터베이스 내에 어떤 웨이트 이벤트가 발생하는지를 확인해 해소시켜줘야 한다. 웨이트 이벤트를 확인하는 방법은 두 가지가 있다. 첫 번째는 시스템 전체의 누적 웨이트 이벤트를 확인하는 방법과, 현재 데이터베이스의 세션 중에 웨이팅을 하고 있는 세션을 확인하는 방법이 있다.

첫 번째로 시스템 전체의 누적 웨이트 이벤트를 확인하는 방법으로는 오라클 뷰 중에 v$system_event를 참조하면 된다. 여기에는 웨이트 이벤트 별 웨이트 횟수, 시간, timeout 등의 정보가 나오므로 데이터베이스의 주요 웨이트 이벤트를 확인할 수 있다. 주의할 사항은 데이터베이스가 운영된 후부터의 총 누적 값이라는 것이다. 오라클 데이터베이스 내부에는기록되므로 필요시에는 연관된 정보를 조회해 문제를 파악하고 해결할 수 있을 것이다. 누적 값이 가장 큰 것부터 원인을 해소해 시스템의 전체적인 성능을 높일 수 있다. 상위 2～3개의 웨이트 이벤트만 제거해도 많은 성능의 향상을 가져올 수 있다.

두 번째는 현재의 사용 중인 세션 중에 웨이트 이벤트에 걸려있는 세션을 확인하는 것이다. 이것은 지금 현재의 상황을 파악할 수 있는 것으로 데이터베이스가 예외적으로 성능이 느릴 경우에 자주 사용한다. 이 정보는 v$sesion_wait의 뷰 컬럼 중에 wait_time=0인 것이 현재 대기 중인 세션을 의미한다.

데이터베이스 성능 추이를 한 눈에

기업 정보 시스템에서 중요한 위치를 차지하고 있는 데이터베이스 시스템은 한 눈을 팔수가 없는 밀착 모니터링이 필요하다. 많은 사용자와 DBA는 주요 성능 측정 지표들에 대해서 변화 추이를 보기를 요구하고 있다.

현대백화점에는 주요 데이터베이스에 대해서 오렌지의 인스턴스 모니터를 통해 실시간으로 성능 지표 변화 상태를 관찰하고 가능하도록 운영하고 있다. 여러 데이터베이스에 대한 인스턴스의 주요 성능 지표의 변화 추이를 볼 수 있어야, 해당 데이터베이스에 대한 작은 변화도 탐지할 수 있는 중요한 자료가 된다. 여기서 GUI 기반의 차트 형식으로 추이를 보여줄 수 있는 기능이 필요한 것이다.

다른 툴과 같이 인스턴스 모니터 한 개의 윈도우에 여러 인스턴스를 보여줄 수 있었으면 관리 측면에서 가시성이 더욱 향상될 것이다.

<그림 5> 오렌지 인스턴스 모니터를 활용한 웨이트 이벤트 및 성능 추이 모니터링

싼 게 비지떡 No! 목적에 맞는 툴 도입

최근 모니터링 툴도 여러 방면으로 진화를 하다.

그러나 가격이 비싸다고 해않을 것이다. 제공되는 모든 기능을 모두 필요로 하의 목적과 이를 충족해 줄 수 있는 기능이 무엇인지 정의하고 도입 대상 툴에 대해서 검토를 하면 구매시 적합한 툴을 선정하는데 도움이 될 것이다.

요약하 현대백화점은 데이터베 제공할 수 있는 모니터링 도구 등 관리적인 측면의 초점과 개발자도 쉽게 사용 가능하고 가벼우면서도 가격도 적절한 툴을 검토했고 이 요건을 충족한 오렌지가 선정될 수 있었던 것이다. 또한 기술 인력의 이탈에도 영향을 받지 않고 일정한 수준의 기술력을 유지하는 것도 가능해졌다. 도입 초기에는 순수 국내 솔루션이라는 점 때문에 IT 부서 일부에선 신뢰를 하지 않았지만, 테스트, 구축 그리고 운영을 통해 그것은 기우에 불과함을 느낄 수 있었다.

오렌지에 보완됐으면 하는 점

다만 오렌지의 다음과 같은 기능이 보강된다면 한층 더 사용자층을 두텁게 가져갈 수 있으리라 본다.

SQL 튜닝 기능을 갖춘 툴을 원하는 IT 부서는 타 툴 도입을 검토하길 권하고, 오렌지는 개발자와 DBA 모두에게 중급 수준의 데이터베이스에 대한 운영을 제공하는 툴을 필요로 하는 중소 업무 또는 대규모 업무 일부에 적용이 가능하다.

시스템에 문제가 있다는 것은 열이면 아홉은 성능의 문제이다. 그렇지만 이러한 성능의 문제가 단지 DBA나 시스템 관리자만의 몫은 아니다. 아무런 도구 없이 문제를 해결하던 시대는 지났으며, 개발자나 DBA에게 생산성을 높일 수 있는 도구 하나는 필요한 시대가 도래했다. 이를 활용, 사용자와 개발자가 책임을 나누어 가질 때 비로소 데이터베이스의 원활한 운영이 가능할 것이다.