퀘스트 Toad 구축사례

'TOAD, 아는 만큼 사용할 수 있는 툴'

전철진|TOAD 고객사 주임

DBA는 현재 운영되고 있는 시스템, 데이터베이스, 애플리케이션 등의 다양한 환경을 구성하고 설치, 보안, 운영 및 설계나 개발 단계에 직, 간접적으로 참여해 전체 구성이 원활하게 유지되도록 하는 업무를 담당한다.

이러한 업무를 수행하다 보면 원하는 서비스가 제대로 동작하지 못하고 특정 부분에 대한 장애가 발생하거나 알 수 없는 그 무엇인가에 의해 성능이 원하는 만큼 나오지 않을 경우도 있다. 특히 DBA에게 내·외적 요소에 의한 뜻하지 않는 돌발 상황으로 인해 소비되는 시간이나 노력은 가장 큰 부담이다.

이럴 경우 누군가가 현재의 시스템이나 데이터베이스의 부하 없이 효율적으로 문제점을 찾아내어 원인 파악을 해주고 문제점을 해결할 방법을 제시해주길 DBA는 원한다. DBA로서 개발 지원 및 튜닝 툴을 도입하게 된 이유와 TOAD를 사용하면서 느낀 장단점 등을 설명하고자 한다.

도입 배경 “RDBMS 관리 어려움”

7～8년 전, 메인프레임 기반의 DB 환경에서 유닉스 기반의 오라클 7.x RDBMS 환경으로 전환하면서 데이터베이스 관리 및 튜닝의 중요성은 매우 커졌다.

A기업의 전산부서는 기존의 메인프레임 DB를 오라클로 전환하는 파일럿 프로젝트를 통해 사전 실행프로세스를 수행했다. 이 작업은 메인프레임의 소스와 데이터 구조를 자바 기반의 소스와 오라클 데이터베이스로 전환하는 것이지만, 단순 쉬프트가 아닌 운영 구조의 변화와 데이터 구조의 커스터마이징도 함께 진행됐다.

이를 위해 프로세스 모델링 → 데이터베이스 모델링 → 자바(JSP, 서블렛) 소스개발 → 테스트 → 병행 운영 → 유닉스기반 JAVA/RDB 3티어 구조 전환 등의 과정을 거쳤다.

당시 BPWIN/ERWIN을 이용한 비즈니스모델링과 데이터베이스모델링 수행은 상당히 선진적인 과정이었다. 그러나 ERWIN을 이용, 역엔지니어링(Reverse-Engineering) 측면에선 유용했지만 실질적인 개발, 디버깅, 모니터링 및 관리 등은 SQLPLUS라는 전문 툴이 담당했다.

이후 1～2년이 지나면서 데이터베이스 관리자는 성능을 모니터링해서 문제발생 부분을 파악, 해결할 필요성을 절감하게 됐다. 물론 당시엔 대부분의 원인이 SQL 문장이 성능 저하에 있었고, 개발자, 설계자, 관리자도 SQL문장의 어느 부분이 문제이고 이것이 SQL의 문제인지 장비의 문제인지조차 가늠하기 힘든 RDBMS 도입기였다.

이에 A기업의 DBA는 성능관리 툴 도입을 검토하게 됐다. 가격 대비 성능이 뛰어나고, 그래픽적인 UI를 갖춰 사용이 용이하며, 관리 기능이 발달된 툴이 A기업이 바라는 요건이었다.

당시 주로 활용되는 퀘스트소프트웨어의 Spotlight, MIB의 프리사이즈, Golden 등을 검토했으나, 가격이 고가라는 점 때문에 보다 저렴한 개발 전문 툴을 찾게 됐고, 그러다 접하게 된 것이 TOAD이다.

TOAD는 개발 전용 툴이면서, 관리 기능과 비주얼이 뛰어나 사용이 편리하다는 것이 장점이었다. 또 특히 기존에 사용하던 SQLPLUS와 혼용해서 사용하기 적합한 툴이라는 점이 도입의 주요인이 됐다.

“비용 대비 효과 면에서 ROI 뛰어나다”

TOAD for Oracle의 튜닝 버전 3카피를 우선 도입한 A기업은 초기 테스트 형태로 개발자들에게만 배포, PL/SQL 디버거와 SQL문 튜닝 기능 등을 활용하도록 했다. 그러나 이미 SQLPLUS에 익숙한 개발자들은 TOAD의 기본적인 기능만을 사용했고, PL/SQL 개발과 디버거, SQL 튜닝 등 주요 업무는 여전히 SQLPLUS로 수행했다.

이에 TOAD 활용을 확대하기 위한 퀘스트의 방문 교육 등을 진행했고 이와 맞물려 TOAD의 버전이 업그레이드되면서 개발 툴 기능 뿐 아니라 그래픽 기반의 개발, PL/SQL 개발, 디버깅, DBA 관리 기능 등이 보강됨에 따라 점차 개발자들의 TOAD 활용 폭도 넓어졌다.

도입 후 약 1년의 시간이 지난 후엔, PL/SQL 개발과 디버거 기능까지 익숙하게 활용하는 수준이 됐고 이에 전 개발자들에게 TOAD for Oracle Professional을 배포했다. DBA는 관리 기능에 중점을 두어서 사용했고 개발자들은 스키마 브라우저(schema browser)와 SQL 에디터(SQL editor) 등을 주로 사용했다.

현재도 여전히 TOAD의 메인 역할은 개발 지원이지만, 관리 기능과 성능 모니터링 기능, 튜닝 기능 등도 활발하게 활용이 되고 있고 이 기능들이 전문 툴에 비해선 부족하지만 비용 대비 효과 면에서 ROI가 뛰어나다는 것이 내부의 평가다.

<그림1> PL/SQL 에디터에서 중단점 설정해 디버거 하는 화면

<그림2> tree 구조로 펼친 스키마브라우저

도입 후 상황 및 평가

TOAD의 점차적인 확대, SQLPLUS와의 혼용 등의 과정을 거쳐 약 2년 전부터는 본격적으로 TOAD를 활용하고 있다. 모든 개발자에게 TOAD 프로페셔널이 배포되고, DBA에겐 TOAD for Oracle DBA 버전이 공급됐다. 특히 추가 확대 도입시 당시의 최신 버전으로 업그레이드해 설치함으로써 더욱 많은 기능을 활용할 수 있었다.

사실 TOAD는 사용자들이 기능이 너무 많은 게 불만이라고 말할 정도로 많은 기능을 갖고 있다. 따라서 아는 만큼 사용할 수 있는 대표적인 제품이다.

이에 지속적인 교육 차원에서 퀘스트코리아의 방문(on site) 교육을 진행했고, 이 과정을 거쳐 TOAD의 사용은 점차 안정화되어 갔다. 그러나 개발자들의 사용 폭이 넓어질수록 그에 따른 사용시 문제점도 대두가 됐다. A기업 개발자들이 제시한 문제점은 다음과 같다.

기능이 너무 많은 것이 흠

특정 버전에만 해당하기 때문에, 버전을 조정함으로써 문제점을 해결할 수 있었고, 는 TOAD의 ‘Security’ 기능을 활용해 개발자 툴 화면에서 민감하거나 주의가 되는 항목을 비활성화 시키는 방법으로 처리했다.

이는 DBA입장에서 매우 유용한 기능으로, 유저 단위로 메뉴 사용 권한을 설정하면 메뉴 사용에 제한이 된 사용자가 TOAD를 사용하려고 할 때 비활성화 된 메뉴가 나타난다. 그러나 A 기업의 DBA는 이에 그치지 않고, IP 단위로 권한 설정을 하고 비활성화 된 메뉴가 화면에 보이지 않도록 처리할 수 있는 비활성화 기법이 추가되기를 희망하고 있다.

<그림3> TOAD 시큐리티에서 특정 유저에게 메뉴 권한 부여 화면

<그림4> 제한된 메뉴사용을 부여한 유저 입장에서 본 툴 메뉴

8.5버전에서 새롭게 기능이 추가되면서 메뉴구성/처리가 MS 오피스 형태의 전통적인 방법을 선택할 수 있도록 변경됨에 따라 일정 부분 해결할 수 있었다. 그림에서처럼 TOAD 옵션 메뉴 중 Toolbar/Menus의 Visual Style에 몇 가지 선택 옵션이 나타나, 기호에 맞게 선택할 수 있다. 개인적으로는 Office 2000 스타일을 선호한다. 하지만 전체적인 툴의 글자 폰트까지도 선택할 수 있었으면 하는 아쉬움이 있다.

<그림5>TOAD 옵션에서 스타일 선택 화면

PL/SQL 에디터를 이용한 디버깅

현재 A기업은 개발자들에게 PL/SQL 개발을 PL/SQL 에디터와 디버거로 처리할 수 있도록 활성화시켜 사용하고 있다. 그런데 현재의 8.x 버전의 TOAD는 스키마 브라우저에서 PL/SQL 에디터로 바로 연결이 되지 않아, 창을 2개 띄워야 하는 번거로움이 있다. 또한 개발자들이 PL/SQL을 배치(Batch)성 프로그램으로 인식해 울트라에디트(UltraEdit)에서 타이핑하는 형태로 주로 활용한다. 최근 발표된 TOAD 8.6의 경우 스키마 에디터에서 PL/SQL 에디터로 바로 연결되도록 기능이 보강됐다고 하니, 이 부분의 개선이 기대된다.

PL/SQL 에디터는 비주얼베이식을 사용해 본 사람이라면 쉽게 사용, 디버깅할 수 있는 기능을 제공해준다. 이로 인해 많은 시간과 공임을 절약할 수 있다.

DBA 입장에서의 TOAD 활용

DBA입장에서도 TOAD는 많은 유용성을 제공한다. 앞있는 기능과 DBA 메뉴의 DB 진단/오프라인 리오그(Offline reorg), 세션 관리 기능 등이 자주 사용하는 기능들이다.

특히 오프라인 리오그 기능은 라이브 리오그(live reorg)에 비하면 기능이 떨어진다고 평가할 수도 있지만, 투자 비용 대비 효용성에 있어서는 매우 뛰어나다. 또 세션 관리의 경우 매일 사용하는 기능은 아니지만, 필요시 즉시 각 세션의 자세한 정보(메모리, LOCK)를 볼 수 있어서 DBA에겐 필수적인 기능이다.

<그림6> 세션 브라우저 화면

SQL 에디터에서 튜닝 랩으로 건너가면 각 단계별로 튜닝을 할 수 있게 해준다. 오리지널 SQL과 수정된 SQL과의 비교를 통해서 DBA가 수정 여부를 확인, 검증할 수 있다. 또 퀘스트에서 제공하는 어드바이스를 보여주고 이를 적용할지 여부를 묻기 때문에, 실행시 적용 여부를 사용자가 선택할 수 있다. 초/중급 엔지니어에겐 유용자에게는 예전의 튜닝 모듈이 보다 자유롭게 튜닝을 할 수 있다는 점에서 더 좋다고 판단할 수도 있을 것 같다.

<그림7> 튜닝랩의 단계별 진행 과정을 보여주는 화면

전문 툴에 뒤지지 않는 튜닝, 모니터링 기능

TOAD는 데이터베이스 모니터링 기능도 제공한다. 특정 DB의 몇 가지 지표를 보여주는 것으로 전문 모니터링 툴에 비하면 기능이 많지 않지만 기본 모니터링에 있어서는 UI가 편리해 유용하다. 또한 데이터베이스 프로브(Probe) 기능이 있어서 보다 자세한 모니터링을 할 수도 있다.

<그림8> 데이터베이스 프로브 화면

여러 개의 데이터베이스를 관리하는 관리자에게 필수적인 인스턴스 매니저(Instance Manager) 기능은 일일이 각각의 서버에 접속해 상태를 파악하지 않아도 여러 개의 인스턴스 상태를 한 눈에 알아볼 수 있게 보여준다. 각 인스턴스 별로 노드, 리스너, 데이터베이스 등을 확인할 수 있다.

<그림9> 인스턴스 모니터 화면

PL/SQL에 대한 날리지 엑스퍼트(Knowledge Expert)도 유용하다. 퀘스트 기술진에 의해 업데이트된 SQL 문법이나 예문 등 실용적인 가이드를 제공해 줘 상황별로 활용 가능한 SQL 문을 찾아 활용하기에 적합하다.

<그림10> PL/SQL에 대한 Knowledge Expert 화면

또 한 가지 TOAD의 눈에 띄는 기능이 팀 코딩(Team coding)이다. 협업 환경에서 코딩을 할 수 있는 기능으로, 이제 적용 단계에 있어 자세한 특장점을 얘기하기는 힘들지만, 개발 작업이 많은 기업에선 사용하기를 권장할만한 기능이다.

<그림11> TOAD의 팀 코딩 화면

TOAD ‘탐구 가능성 큰 툴’

약 7년 동안 TOAD를 사용하면서 느낀 점들을 정리했다. TOAD는 단순 개발 지원 툴이라고 평가하기엔 기능이 대단히 풍부하다. 그런 점에서 매우 보편적으로 사용하는 대중화 된 툴이지만, 어떤 툴보다 교육이 필수적인 툴이다.

사용하면서 가장 아쉬웠던 부분이 한 화면에서 여러 개의 DB를 관리할 수 있는 기능과 메뉴 실행의 스케줄링이었는데, 최근 발표된 TOAD 8.6 버전에서 이를 비롯한 몇 가지 기다리던 기능이 지원된다고 하니 기대가 크다.

생각건대, 현재 사용하는 기능들이 TOAD에 주어진 기능의 50%에도 못 미친다고 본다. 버전업되는 새로운 기능의 습득과 함께 기존 기능에 대한 끊임없는 배움이 필요하다는 점에서 탐구 가능성이 큰 툴이라고 생각한다.