About DATABASE

시 스템 개발·운영시에 다양한 소프트웨어나 솔루션을 도입해 구축하게 된다. 이때 어떠한 솔루션을 도입하느냐에 따라 시스템의 성패가 좌우된다. 또한 다양한 툴의 구매도 그 목적에 따라 해당 업무의 효율성을 높일 수도 있고 효과를 주지 못하는 경우도 있다. 이 글에서는 데이터베이스를 이용하는 개발 프로젝트에서 필수 불가결한 툴인 데이터베이스 클라이언트 툴 가운데 웨어밸리의 Orange for Oracle(이하 오렌지) 제품의 기술적인 기능에 대해 알아보고자 한다. 오렌지 도입시 판단의 기준에 도움이 되길 바란다.

뒷방 신세로 전락되는 툴

많은 기업에서 오라클 데이터베이스 지원 툴을 구매하고도 6개월 아니 1년이 지나면 단지 구매 리스트에만 등재돼 있을 뿐 현업에서는 사용하지 않아 사장되는 경우를 종종 볼 수 있다. 이것은 툴의 기능에 대한 잘못된 판단으로 적절하게 구매하지 못한 이유도 있겠지만, 구매 후 잘 활용할 수 있도록 교육이 되지 않는 이유가 크다. 이러한 측면에서 볼 때 오렌지는 지금도 매월 1회씩의 무료 교육을 실시해 사용자들이 오렌지를 업무에 잘 활용하도록 유도한다.

필자의 경우 튜닝 작업이나 시스템 아키텍처를 수립하기 위해 고객과 함께 작업을 할 때, 오렌지의 기본 기능만을 사용하거나 아예 사용하지 않는 고객도 많이 봤다. 이러한 경우 고객에게 몇 가지 유용한 기능을 알려주면 대부분의 고객 반응은 ‘아니, 이런 기능도 있었군요’란 놀란 표현이 나온다. 결국 수 십 가지 기능 중에 사용자가 알고 사용하는 기능은 극히 일부이며, 편리하게 사용할 수 있는 기능이 있는데도 불구하고 적절하게 사용하지 못하고 있어 구매 후 교육 여부도 구매시 꼭 생각해 볼 점이다.

툴 구매시 가장 고려할 점

그럼 툴을 구매하고자 할 때 가장 고려해야 할 점은 무엇일까? 앞서 언급한 사후 교육, 사용자 요구사항 적용 등도 있겠지만 가장 먼저 생각해 볼 수 있는 것은 ‘툴의 기능성이다. 기본적으로 적용하고자 하는 업무에 툴이 갖고 있는 기능이 얼마나 적합한가에 따라 잘 활용되는 도구로써 사용될 가능성이 높아지기 때문이다.

오렌지의 4가지 버전과 특징

오렌지는 2001년 12월 12일 1.0버전 출시 이후 현재 3.1버전까지 오라클 데이터베이스 기반의 개발 및 DBA 툴로 선보이고 있다. 최초 오렌지의 개발자는 DBMS 튜닝 및 디자인을 하는 사람으로, 현업에서 작업 중에 비효율적인 매뉴얼 작업들을 자동화하기 위해 오렌지를 만들었다. 이렇게 만들어진 오렌지는 많은 튜너 및 컨설턴트의 피드백을 받아 사용자 중심의 툴로 설계된 것이 가장 큰 특징이다. 지금의 오렌지 3.1버전은 개발 지원 기능 및 튜닝 지원 툴, 모니터링 툴도 제공된다.

오렌지는 오라클 데이터베이스를 기반으로 하는 시스템을 구축할 경우, 개발자가 SQL을 작성하고 데이터를 조회, 등록, 수정 및 PL/SQL 개발 등을 하는데 많은 기능을 제공한다. 또한 DBA의 주요 작업인 데이터베이스 모니터링을 쉽게 할 수 있는 모니터링 기능도 제공한다(DBA 에디션).

오렌지는 사용 용도별로 크게 4가지로 나눠 구분할 수 있다. 스탠더드 에디션(Standard Edition), DBA 에디션, Reorg 에디션, Trusted 에디션으로 나눠지는데, 2005년 3월에 Reorg 에디션을 추가로 구성했다. 사실 Reorg 에디션이라고 해서 특별히 Table, Index, Tablespace 등의 reorg 작업을 오렌지가 직접 해주는 것이 아니라 오라클의 DBMS_REDEFINITION 패키지를 이용해 온라인 reorg 절차를 간편하게 작업할 수 있도록 지원해 주는 것이다. 또한 Trusted 에디션은 사전 등록된 내부 결제 프로세스를 거친 SQL만을 수행할 수 있도록 하는 기능을 갖춘 사전 보안 감시용이라 할 수 있다.

Trusted 에디션의 경우 고객의 업무 프로세스와 연계해 구성되어 사용하는 것이므로 제품 구입시 고려할 사항이 스탠더드 에디션, DBA 에디션과 현격하게 다르기에, 이글에서는 고객이 주로 사용하는 스탠더드 에디션, DBA 에디션만을 설명하도록 하겠다.

개발자 위한 오렌지 스탠더드 에디션

다음의 <표 1>과 같이 스탠더드 에디션은 오라클 데이터베이스를 기반으로 개발할 때 필요한 많은 기능들을 제공한다. 그리고 DBA 에디션은 데이터베이스 시스템의 전반적인 작업 및 모니터링 작업을 수행할 때 필요한 기능들을 갖추고 있다.

Step-In 기능으로 직관적 정보 분석이 가능

오렌지는 개발부터 가장 가볍고 빠르게 수행될 수 있어야 한다는 전제 하에 제작됐으며, 성능이 느린 화면은 개발시부터 자체 튜닝 대상이 되어 집중적으로 관리됐다. 오렌지의 개발 언어는 Visual C++를 이용했고, 오라클 OCI 인터페이스를 사용한다. 또한 디스크 공간도 매뉴얼을 포함해 약 20MB 정도만 사용할 뿐이다. 다만 오렌지의 빠른 성능을 보장하기 위해서 오렌지에서 사용하는 뷰(view)를 데이터베이스에 생성해야 하는데, 이 작업을 하는 것은 ‘Orange Configuration Admin’을 통해서 쉽게 생성할 수 있다. 하지만 이 작업은 오라클 데이터베이스의 내부 사용 User인 SYS user로 접속해서 수행해야 하기 때문에 데이터베이스 관리자의 허가 하에 작업할 수 있다. 처음 오렌지를 사용할 때는 이것이 다소 제약사항이지만, 스탠더드 에디션인 경우에는 ‘Orange Configuration Admin’을 돌리지 않아도 대부분의 기능은 사용이 가능하다.

화면 간의 작업 및 동작은 멀티 쓰레드 방식으로 구현돼 여러 개의 창에서 동시에 작업할 수 있으며, 오래 수행되는 쿼리를 기다리지 않고 다른 작업을 할 수 있다는 것이 장점이다. 또한 데이터베이스로의 접속도 여러 개의 세션을 맺을 수 있어서 많은 작업을 한 번에 할 수 있게 디자인됐다. 게다가 많은 컨설턴트들의 오랜 노하우가 담겨 있어 개발자, DBA는 작업시 편리한 작업환경에서 오렌지를 사용할 수 있다. 이러한 예는 오렌지 곳곳에서 찾아 볼 수 있다.

SQL monitor에서 특정 SQL을 찾은 후, 현재 이 SQL을 사용하는 세션을 찾는 Step-In 기능은 현업에서 시스템 분석시 많이 사용하는 방법이다. 또한 DBA 에디션의 Health Check 기능은 간단하면서도 기본적으로 점검해야 하는 부분을 많은 컨설턴트가 아이디어 및 개인의 노하우를 집약시킨 것이다. 물론 Report & Graph 기능에 이미 정의되어 있는 스크립트 구성을 보면 노하우를 쉽게 느낄 수 있을 것이다.

그리고 <표 1>에서 나열한 많은 툴 간에 Step-In 작업이 가능해 직관적인 정보 분석이 가능하다. 관심 있는 정보에서 더블 클릭이나 오른쪽 버튼을 누르면 상세 정보 창으로 전이되어 빠르게 자세한 정보를 확인할 수 있다. <화면 1>은 오렌지가 제공하는 툴 간의 Step-In을 보여주고 있다. 이러한 Step-In 기능은 실제 업무에서 작업하는 경우 참고 정보를 확인하기 위한 최적의 툴로 연동하는 기능이다.

고객 맞춤형 툴로 변신 가능한 ‘오렌지’

마지막으로 오렌지의 일반적인 측면 중 가장 돋보이는 것은 국내에서 개발한 툴이므로 사용자의 요구사항을 적극적으로 수용할 수 있다는 점이다. 여타 다른 툴들은 외산이므로 제공되는 기능만을 사용할 뿐 추가적인 요구 사항을 요청할 방법이 없다. 다만 오렌지의 경우에는 사용자가 필요한 기능을 개발자와 협의해 점차 고객에게 편리한 툴로 만들 수 있다는 것이다. 사실 오렌지를 개발한 웨어밸리 홈페이지(www.warevalley.com)에는 고객과 개발자의 통신 채널이 있으며 활발하게 Q&A를 진행하고 있다.

그 중 한 예가 ERP 모니터 기능으로 오라클 애플리케이션(ERP)을 사용하는 고객의 요청사항에 의해 만들어진 기능이다. 이는 ERP 관리 작업을 할 때 기본적으로 모니터링을 해야 하는 항목에 대한 화면을 항상 보게 되는데, 오렌지를 이용한 모니터링과 함께 하게 되므로 불편할 사항이 있었다. 이에 대해 고객이 적극적인 요청을 해서 오렌지에 상기 기본 모니터링을 할 수 있는 ERP 모니터 기능을 추가하게 된 것이다. 그러므로 고객이 꼭 필요하다고 느끼고 생각하는 기능에 대해서는 향후에도 추가적인 Add-on이 될 수 있다.

오렌지 탄생 실화

오렌지 개발의 핵심 목표는 가볍고, 빠르고, 쉽게 사용할 수 있는 툴을 만든다는 목표 아래 만들어 졌다. 상상을 해보라. 오렌지의 instance monitor(9개의 그래프)는 단 하나의 SQL로 구현됐다.
오렌지의 탄생은 처음 툴을 만들려고 만들어진 것은 아니다. 데이터베이스 컨설팅을 하던 초기 개발자가 자신이 작업하는 것을 자동화하기 위해 2000년부터 2001년 사이 약 1년간 ‘오렌지’라는 이름으로 만들어 졌다. 그 이후 2001년 12월 정식 ‘오렌지’라는 제품으로 탄생했다. 오렌지라는 이름은 그가 오렌지를 그냥 좋아했기 때문이란다.
그 후 웨어밸리의 한 개발자가 오라클 연동한 클라이언트 툴을 혼자 만들어 보기 위해 ‘토마토’라는 것을 만들었다. 결국 토마토는 오렌지의 기능을 강화하기 위해 오렌지에 흡수됐고, 그 이름을 Report & Graph 툴이라고 했다. 가볍고, 빠르고, 쉽게 사용할 수 있는 툴로 개발될 수밖에 없는 이유는 국내 개발 환경을 잘 아는 개발자의 땀이 묻어 있기 때문이다.

개발자 측면의 유용한 기능들

이제까지는 오렌지의 일반적인 구조에 대해 알아봤다. 그럼 개발자 측면에서의 오렌지 기능들에 대해 살펴보자. 개발자가 주로 하는 작업은 SQL의 작성, 데이터 로딩, 데이터 확인, 데이터 수정, PL/SQL 프로그램 작성 등으로, 오렌지는 이러한 작업 활동을 수행할 수 있는 기능들을 제공한다.

SQL 툴에서 지원되는 기능으로 SQL의 조회 결과를 엑셀로 저장하는 기능은 기본적으로 지원되며 그리드 출력, 텍스트 출력을 지원한다. 그리고 멀티 탭을 지원해 여러 SQL 작업을 동시에 할 수 있다. 이 SQL 툴에서는 필자가 자주 사용하는 기능으로는 SQL 툴의 Action 메뉴에 Recall Named Script 기능인데, 자주 사용되는 SQL 스크립트를 선택해서 수행할 수 있다. 핫 키로 Ctrl+R을 누르면 쉽게 저장된 SQL을 수행할 수 있다(필자의 경우에는 Named Script를 종류별로 잘 정리해 약 200여개의 스크립트를 업무에 필요시 바로바로 사용한다). 이 SQL 툴에서 특별히 지원되는 기능으로 SQL 포맷 기능이 있는데, 이는 정돈되지 않는 SQL을 가지런하게 정돈해주는 기능이다. 특히 이 기능은 튜닝 작업을 할 때 SQL Area에서부터 악성 SQL을 추출해 작업하는 경우에 더욱 편리하다. SQL Area에서 추출한 SQL들은 주로 작성된 SQL의 형태가 아닌 무작위로 보여주는데, 이 SQL 포맷 기능은 버튼 한 번의 클릭으로 보기 어렵게 되어 있는 SQL을 잘 정돈해준다. SQL*Navigator에도 이러한 기능이 있는데 비교해 본다면 오렌지가 그다지 훌륭하게 포맷되지는 않지만 무료로 제공된다는 데에서 매력이 있다.

SQL 툴에서 SQL을 작성하다 보면 여러 번의 수정 및 테스트를 하게 된다. 이때 여러 번 수정된 것을 취소하고 싶을 때는 Undo 기능을 이용해 변경 전의 값으로 돌리는데, 오렌지의 경우는 무한 undo가 지원된다. 이는 SQL을 처음 작성한 시점까지 undo할 수 있다는 것으로. undo가 제한적으로 지원되는 경우(예, MS-Word)에는 undo를 하다가 더 이상 안 될 때 난처할 경우가 발생하는 단점을 없애준다.

개발자들이 많이 사용하는 또 다른 기능 중에 하나는 로더(Loader)이다. 프로젝트의 개발 단계에서 레거시 데이터를 오라클 데이터베이스로 로딩할 때 사용하게 된다. 또한 현재 오라클 데이터베이스에서 데이터를 Un-loading하는 기능도 지원된다. 로더를 이용해 데이터를 로딩할 수 있는 포맷으로는 .csv, .xls, .txt file 등을 지원하므로, 다양한 소스의 데이터 로딩이 가능하다. 반대의 경우인 Unload 역시 상기 지원되는 포맷으로 Un-loading이 가능하다.

개발자들이 SQL을 작성하거나 PL/SQL을 작성할 때 모든 구문을 알고 작업하는 것이 아니므로, 자주 오라클 매뉴얼을 참조해봐야 하는데, 이러한 불편을 없애기 위해 오렌지에서는 DML, DDL, PL/SQL, PL/SQL Control structure, Pseudo column, SQL Function 등의 템플릿을 지원해 매뉴얼 참조 없이 손쉽게 SQL이나 PL/SQL의 작성을 도와준다.

PL/SQL 툴의 독특한 기능 ‘Source Control’

개발자 관련 오렌지 툴 중의 PL/SQL 툴은 독특한 기능이 있다. 이는 오라클 내의 PL/SQL을 작성할 때 편리하게 작업할 수 있는 환경을 지원한다. 이 PL/SQL 툴의 독특한 기능으로 Source Control이 있는데, 기존의 PL/SQL을 수정할 때 다른 개발자와의 동시 수정을 예방하고 어떤 사용자가 현재 어떤 PL/SQL을 수정하고 있는지 알 수 있는 checkout list를 지원한다. Checkout list는 다른 개발자가 동일 PL/SQL을 Check-In한 정보를 보여 준다.

<화면 2>는 checkout list 버튼을 눌렀을 때, 현재 PL/SQL을 수정하고 있는 사용자의 IP-address와 컴퓨터 이름이 나타난다. 만약 자신이 수정하고자 하는 PL/SQL이 이미 다른 개발자로부터 checkout이 됐다면, PL/SQL 툴에서는 이 PL/SQL을 수정할 수 없다. 만약 일반적인 툴이라면 이러한 제약사항 없이 사용하게 되어 두 명의 개발자가 동시에 소스를 수정해 혼란이 발생하게 될 것이다. 만약 다른 개발자가 동시에 작업하고 있다면 IP-address 및 컴퓨터 이름을 통해 어떤 개발자인지 알 수 있고, 전화 등의 통신 채널을 통해 작업 정지나 잔업 협의를 통해 계속 진행할 수 있을 것이다.

PL/SQL 툴의 다른 큰 특징으로는 디버거(Debugger) 기능이다. 일반적인 컴파일러와 유사한 형태로 PL/SQL(procedure, function) 등을 수행 스텝 별로 디버깅할 수 있다. 이 디버거 기능도 다른 외산 제품들은 고가로 팔고 있으나 오렌지는 기본으로 제공하고 있으니 이 또한 큰 장점이라 할 수 있다. 물론 이 PL/SQL 디버거 기능이 C++ 등의 디버거처럼 화려한 기능을 제공하지는 않지만, 기본적은 기능(변수 참조, Step into, Step over, Breakpoirt 등)은 지원한다. PL/SQL 툴에서 procedure, function을 컴파일할 때 컴파일 에러가 발생하게 되면 status 창에 오라클 에러 번호와 에러 메시지를 보여주는데, 이 에러 번호를 더블 클릭하면 그 에러가 발생한 PL/SQL의 부분으로 커서(cursor)를 이동시킨다. 이 기능은 개발자가 빠르게 에러의 위치를 파악하고 수정할 수 있도록 한다.

개발자의 데이터베이스 관련 툴을 사용하는 목적 중의 하나는 데이터베이스 내의 오브젝트를 참조하는 경우이다. 어떤 테이블이 있는지 해당 테이블에 어떤 컬럼이 있는지, 또한 제약사항, 인덱스 등을 확인하는 경우가 있다. 이렇듯 개발자가 SQL 작성시 참조하는 DB 오브젝트의 정보를 손쉽게 확인할 수 있는 스키마 브라우저 기능은 약 16개의 오브젝트를 윈도우의 탐색기와 같이 참조할 수 있도록 지원해 동시에 창을 열고 쉽게 다른 오브젝트를 참고할 수 있다. 물론 스키마 브라우저에서 16개 오브젝트를 검색하며 오른쪽 버튼을 누르면 그 오브젝트에 대한 작업을 할 수 있는 메뉴가 나타난다. 만약 constraint tab에서 오른쪽 버튼을 누르게 되면 ‘Describe, Add constraint, Enable Constraint, Disable Constraint, Drop object’ 등의 연관된 메뉴를 보여준다. 이는 각각의 오브젝트 타입에 따라 필요한 작업을 바로 할 수 있게 하는 기능이다.

DBA 측면의 유용한 기능들

DBA를 위한 기능은 스탠더드 에디션보다 DBA 에디션에 많다. DBA 에디션은 <표 1>과 같이 스탠더드 에디션의 모든 기능에 Space Manager, Security Manager, Instance Monitor, Graph & Report, Health Check, Analyze Manager, Log Miner가 있다.

스탠더드 에디션과 DBA 에디션의 차이는 DBA 기능은 주로 데이터베이스 전체 범위의 모니터링이나 점검, 전체 레벨의 작업을 지원하는 툴들이 대부분이라는 것이다. 가장 대표적인 DBA 지원 툴은 ‘Instance Monitor’이다. 이 툴은 데이터베이스 전반적인 상태를 표시해 주는데, 크게 9가지 부분으로 나눠져 있다. Buffer Cache Hit Ratio, Library/Dictionary Cache Hit Ratio, Connection 수, Active Transactions, Shared Pool Size usage, I/O block per Second, Redo size, Parse/Execution, Wait event 등을 한 눈에 볼 수 있게 주기적으로 그래프를 그려준다. 이 9가지 그래프들은 서로 시간적으로 연결돼 있어 한 그래프의 위치를 선택하면 나머지 8개의 그래프에 시간을 함께 보여줌으로 같은 시간의 정보를 비교해 점검해 볼 수 있다. 이전의 오렌지 2.0 버전에서는 로깅 기능이 없어서 현재 상태의 정보만을 볼 수 있었고 오렌지를 정지했다가 다시 사용할 때는 이전에 모니터링 결과는 무시되고 새로이 모니터링을 해야 했는데, 3.0 버전부터는 로깅 기능도 생겨서 정상적일 때와 부하가 있을 때의 상태를 비교해 볼 수 있다.

이 인스턴스 모니터는 데이터베이스의 전체적인 뷰를 확인하고자 할 때 사용한다. 특별히 이 인스턴스 모니터로부터 다른 Action은 취할 수 없고 현상만 보게 되지만 간단히 시스템의 상태를 보기에는 무리가 없다. 특히 wait event는 옵션 쪽에서 사용자가 특별히 관심 있는 오라클 wait event를 지정할 수 있어 사용자의 편의성을 갖추고 있다.

두 번째로 소개할 DBA의 툴 중에 Space Manager가 있다. 이것은 데이터베이스의 테이블 스페이스, 데이터 파일들의 사용량, redo log의 현황, 롤백 세그먼트의 현황을 확인하는 기능을 제공한다. <화면 4>는 각각의 오브젝트가 물리적으로 데이터 파일의 어떤 위치에 몇 개의 extent로 구성되어 있는지 맵 형식으로 한 눈에 보여준다. 이 화면을 통해서 데이터 파일(테이블 스페이스)이 얼마나 조각화가 됐는지 손쉽게 파악할 수 있으며 오브젝트의 실제 저장 위치를 확인 할 수 있다. 다만 블럭의 맵을 그릴 때 약간의 시간이 걸린다는 아쉬움이 남는다(여러 번 튜닝을 했다고는 하는데, 작업량 자체가 많은 관계로 쉽게 빨라지지 않는 것 같다).

상세한 정보를 제공하는 세그먼트 인포 탭

DBA 에디션에서 빈번히 사용되는 기능 중 하나로 Health Check 기능을 꼽을 수 있는데, 이는 데이터베이스의 전반적인 점검 부분들을 한 번에 점검해 HTML 형식의 리포트를 생성해 준다. 크게 General, SGA, Wait Event, I/O, Space, Access Type, MTS, OPS(RAC)의 8가지로 나뉘며, 각각의 부문별로 점검해야 하는 통계량 및 데이터베이스 운영 내역을 검토해 점검 리포트를 생성한다. 리포트에는 각각의 점검 내역에 대한 자세한 가이드도 제공되어, 문제점이 발견됐을 경우 어떠한 조치를 취해야 하는지 DBA가 쉽게 알 수 있다. 이 Health Check 기능에서 점검하는 점검 리스트들은 데이터베이스 튜닝 및 컨설팅 경험이 있는 여러 명의 노하우가 집약되어 만든 것이다.

그러므로 Instance Monitor와 Health Check 기능을 통해서 데이터베이스 관리자는 관리하고 있는 데이터베이스 상태와 일일 점검 작업을 손쉽게 수행할 수 있다. 다만 오렌지에서 제공되는 기능은 고객의 환경 및 상황에 만족되지 않을 수 있다. 즉, 오렌지에서 이미 정의된 내용이 아닌 고객의 환경에 관련한 점검이 필요한 경우에는 Instance Monitor와 Health Check 기능으로도 점검이 되지 않는다. 이러한 고객의 특화된 부분을 위해 Graph & Report 툴을 제공한다. 이 Graph & Report는 개발 초기에 ‘토마토’라고 불리었고, 오렌지와는 별도로 개발되다가 오렌지의 한 개 툴로서 통합됐다.

Graph & Report에서는 Health Check에서 수행되지 않는 다양한 점검 스크립트가 미리 정의돼 있으며, 사용자가 직접 새로운 스크립트를 정의할 수 있는 User Define Group을 통해 원하는 스크립트를 생성해 모니터링하고 이를 차트로 표현될 수 있도록 제공한다.

DBA 에디션에서 제공되는 Log miner 툴은 오라클의 log miner 기능을 이용해 이미 수행된 작업들에 대한 상세 내역을 편리하게 확인할 수 있다. 이 log miner 사용자에게 오라클 log miner package의 사용법을 숙지하지 않더라도 손쉽게 데이터베이스 작업 이력을 확인해 볼 수 있다.

튜너 측면의 유용한 기능들

SQL 튜닝에 강력한 기능을 갖고 있는 '오렌지'

오라클 데이터베이스 관련 튜닝이라고 하면 크게 두 가지로 나눌 수 있는데, 하나는 데이터베이스 튜닝이고 나머지는 SQL 튜닝이라 할 수 있다. 오렌지는 후자의 SQL 튜닝에 강력한 기능들을 많이 갖고 있으며, 전자인 데이터베이스 튜닝 기능도 보유하고 있다. 앞서 설명한 개발자 기능, DBA 기능에도 데이터베이스 튜닝을 위한 점검 기능이 포함되어 있으며, 특히 SQL Monitor, Instance Monitor, Session Monitor, Transaction Monitor, Lock Monitor는 데이터베이스 튜닝시에 자주 사용되는 기능이다.

SQL Monitor에서는 데이터베이스에 다양한 옵션을 이용해 부하를 많이 주는 SQL을 찾을 수 있으며, Instance Monitor에서는 주된 병목 현상이 어떤 부분에서 발생하는지 쉽게 확인할 수 있다. Session Monitor에서는 데이터베이스에 접속한 세션들의 작업 내역을 데이터베이스 통계치 기준으로 자원을 많이 사용하는 세션들을 편리하게 점검할 수 있다. 여기에서는 SQL을 튜닝하는 것을 중점적으로 설명하겠다.

대표적 튜닝 지원 기능 ‘Plan 툴’

대표적인 튜닝 지원 기능으로는 ‘Plan 툴’이라고 할 수 있다. Plan 툴은 개별 SQL의 수행 계획(Execution Plan)을 보여주며, 수행 계획의 각 단계별로 위치하는 오브젝트의 정보를 손쉽게 확인해 볼 수 있다. 단지 더블 클릭만으로 테이블의 컬럼 정보, 인덱스 정보, 그리고 테이블의 통계치 등을 확인해 볼 수 있다. 또한 하나의 SQL에 포함되어 있는 모든 테이블과 인덱스 정보를 수집할 수 있다. 물론 이러한 static 정보만을 갖고 정확한 튜닝 결과를 도출 할 수 없다. 이에 Plan 툴에서는 실시간 SQL Trace 기능을 지원한다. 오라클에서 SQL trace를 생성해 이 trace file을 실시간으로 읽기 편한 포맷으로 분석해 사용자에게 제공한다. 10046 이벤트를 이용한 여러 레벨의 trace를 지원하며, SQL 내부에 있는 bind 변수 값, wait event 및 실제 수행되는 시간을 정확하게 분석할 수 있다.

오라클의 tkprof 없이 자체 엔진으로 trace file을 분석한다?

오렌지를 사용하지 않는 경우에는 SQL의 trace를 걸어서 trace file을 확인하고, 오라클에서 제공하는 tkprof를 이용해 포맷팅을 해서 trace 결과를 확인하는 5∼6단계의 작업이 필요하나, plan 툴의 실시간 trace 기능을 사용하면 버튼 하나로 모든 작업이 완료돼 빠르게 튜닝 작업을 할 수 있다. 여기서 오렌지의 특이한 점은 trace file을 분석하기 위해서 오라클의 tkprof를 사용하지 않고 자체적으로 엔진을 만들어 trace file을 분석하는 것이다. 이렇게 자체적으로 엔진을 만들어서 사용하는 까닭은 오라클 서버의 tkprof를 이용해 분석하는 경우, 서버에 tkprof를 수행할 수 있도록 셸 프로그램 등을 구성해야 하는 구조적인 문제(오렌지는 서버에 에이전트가 없는 가벼운 구조이다)와 클라이언트 반응 시간, Wait Event 정보와 같은 더 많은 분석 정보를 주기 위해서다.

SQL 튜닝을 하는 과정에 하나의 SQL을 여러 방법으로 수정해 보고 작업하게 되는데, Plan 툴에서는 멀티 탭 기능을 이용해 여러 개의 SQL 버전을 만들어서 튜닝 작업을 할 수 있다. 물론 이런 변형된 SQL들을 각각 trace를 할 수 있으며, 이러한 모든 결과는 Workspace 개념으로 저장 및 로드할 수 있다(PTD 파일로 저장이 된다). 이 Workspace 개념은 개발자와 튜너와의 통신 수단으로 사용되곤 한다. 개발자가 개발한 SQL의 성능이 나오지 않을 경우에는 1차적인 Trace 및 통계정보를 workspace로 저장해 튜너에게 튜닝 요청을 하게 되면, 튜너는 이 workspace를 로드해 바로 튜닝 작업을 진행할 수 있으며 튜닝이 완료되면 수정된 SQL과 이에 따른 trace 정보를 다시 개발자에게 workspace로 저장해 전달할 수 있다.

이 Plan 툴에서는 Run time execution plan을 보여준다는 것도 특징이다. SQL이 수행되는 과정은 크게 『파싱 | 바인딩 |수행』으로 나뉘는데, 지금까지는 실행 계획을 파싱 단계에서 수립해 수행했다. 그런데 오라클 데이터베이스 9i 버전부터는 bind peeking이라는 기능이 있어서 바인딩 단계에서 변수 값을 이용해 새로이 실행 계획을 생성하는 것이다.

그러므로 수행 계획만을 체크했을 때와는 달리 실제 수행 계획이 달라지는 경우가 종종 있다.

이러한 차이점은 개발자나 튜너를 황당하게 만드는데, 이렇게 차이가 나는 실행 계획은 확인시켜 줄 수 있다. Plan 툴의 내부 기능인 Trace를 독립적인 Trace 툴로 제공하고 있는데, 이는 Trace를 오라클 전체적인 방법으로 수행하거나, 이미 trace가 생성되어 있는 경우 이 파일을 분석하는 형태로 사용하기 때문에 추가된 것이다. 또한 포맷팅된 결과로 볼 수도 있지만 종종 로우 파일(Raw file) 형태의 참조가 필요한 경우를 대비해 로우 파일의 참조도 지원한다.

미래의 오렌지에 대한 기대

지금까지 오렌지가 개발자, DBA, 튜너에게 어떠한 기능을 제공하는지에 대해 알아봤다. 이 글에서 언급한 내용이 오렌지의 모든 기능은 아니지만, 자칫 매뉴얼처럼 될 것을 우려해 오렌지가 갖고 있는 기능 중에 사용자들이 가장 많이 사용하고 많은 도움을 주는 기능 위주로 설명해 오렌지를 선택하고자 하는 고객에게 객관적인 정보가 됐으면 하는 바람이다.

오렌지 역시 버전이 업그레이드되며 사용자 중심의 기능들이 많이 추가됐다. 하지만 앞으로 좀 더 해야 할 일이 많은 것 역시 현재의 숙제이다. 오라클 9i, 오라클 10g, 그리고 2005년 8월 말에 출시될 오라클 10g R2의 새로운 기능들을 사용자들이 손쉽게 접근하고 활용할 수 있는 그러한 오렌지로 변신해야 할 것이다. 아직까지는 오라클 8, 오라클 8i, 그리고 오라클 9i를 지원하는데 머물러 있기 때문에, 향후 1∼2년 이내에 오라클 10g의 장점을 표현해 주지 못한다면 시장에서의 입지는 좁아질 것이다.

오라클 10g에서 제공되는 기본 기능에는 AWR(Automatic Workload Repository), ADDM(Automatic Database Diagnostic Manager) 등이 있다. 이 기능들은 데이터베이스의 운영 상태, 문제점, 병목 현상의 원인 등을 모니터링 툴이 없어도 될 정도의 데이터를 제공한다. 이렇게 풍부한 데이터를 어떻게 효율적으로 사용자에게 제공하느냐가 다음 버전 오렌지의 발전에 계기가 될 것이다.

• CPU : Pentium 133 이상
• 메모리: 64 MB 이상
• Software Platform: Windows 9x/NT/Me/2000/xp
• SQL*Net 최소 : 8.0.5, 권장 : 8.1.7 이상 (http://otn.oracle.co.kr/software/)
• Oracle RDBMS: Oracle 7.3 이상
• Disk Space : 10MB

• 현업 개발자들이 요구하는 핵심기능에 충실
• 뛰어난 인터페이스
• 오라클 경력이 많은 컨설턴트들의 실전을 통해 검증된 방법 및 interface 제공
• 모든 기능이 통합형으로 제공
• 순수 국내기술
  • 사용자들의 추가 요구사항에 신속한 대응
  • 한글 매뉴얼 및 HELP 제공
  • 기술축적에 따라 저렴한 가격으로 다양한 DB TOOL software 제공

• Standard Edition
  • Schema Browser
  • Query Builder
  • SQL Tool
  • PL/SQL Tool
  • Description Tool
  • Table Editor
  • Plan Tool
  • Trace Tool
  • Database Information
  • Network Configuration Tool
  • Expert Tool
  • Import Tool
  • File Editor
  • Loader
  • Latch Monitor
  • Transaction Monitor
  • ERP Monitor
  • SQL Monitor
  • Session Monitor
  • Lock Monitor
  • Data Dictionary Tool
    
• DBA Edition
• Space Manager
• Security Manager
• Instance Monitor
• Graph & Report
• Health Check
• Analyze Manager
• Log Miner
  
• Reorg Edition
• Reorg Manager
  dbms_redefinition 패키지를 사용하여 테이블 온라인 REORG 및 REORG 대상 추출
  
• Trusted Edition
  DB 사용자가 의도적으로 외부유출을 목적으로 데이터를 액세스하거나 또는 비의도적인 실수에 의하여 문제가 발생하는 것을 사전에 차단하기 위하여 DB 액세스 시 사전 등록된 내부결재 프로세스를 거친 SQL만 실행하도록 하는 기능을 갖춘 사전 보안감시용 툴

REDO log buffer는 SGA내에 존재하며 데이타베이스에 대한 변경에 관한 정보를 보관 유지하는 버퍼입니다. 이 정보는 REDO 엔트리에 격납됩니다. REDO 엔트리는 데이타베이스에 대해서 행해진 변경을 재실행하기 위해서 필요한 정보를 포함하고 있습니다. 필요에 따라서 개개의 REDO 엔트리는 데이타베이스의 복구에 사용됩니다.

REDO엔트리는 Oracle 서버 프로세스에 의해 유저의 메모리 영역으로부터 SGA에 있어서의 REDO log buffer에 카피됩니다. 이 때 REDO 로그 엔트리는 버퍼내의 영역에 차례로 써집니다. 백그라운드 프로세스의 LGWR는, REDO log buffer의 내용을 디스크상의 액티브한 온라인 REDO 로그 파일 (온라인 REDO 로그 파일 그룹)에 씁니다.

초기화 파라미터 LOG_BUFFER는 REDO log buffer의 사이즈를 바이트 단위로 지정한 것입니다. 1개의 트랜잭션(transaction), 혹은 다중의 트랜잭션(transaction)에서 대량의 REDO log buffer에의 기입이 발생하는 환경에서는 일반적으로는 이 값을 크게 해 로그 파일에 대한 I/O수를 줄일 수가 있습니다. LOG_BUFFER 사이즈의 설정에 관해서는 KROWN#18227을 확인해 주세요.

데이터 블록에 대한 변경이 필요할 때 이하의 순서에 의해 REDO log buffer내에 REDO 레코드가 작성됩니다.

다른 프로세스가 해당 프로세스보다 높은 COMMIT SCN(System Change Number)를 생성하고 있지 않는 것을 확인한다.

■ REDO를 쓸 수 있는 스페이스가 있는지를 확인한다. 충분한 스페이스가 없는 경우는 LGWR가

   REDO log buffer의 내용을 디스크상의 REDO 로그 파일에 쓰거나 로그 스윗치를 실시한다.
■ REDO log buffer내에 필요한 스페이스를 할당한다.
■ REDO log buffer에 REDO 레코드를 카피하고, 리커버리 시에 사용 가능하도록 관련성 실시

데이타베이스에는 이 처리를 실행하기 위해 3개의 REDO Latch가 있습니다.

・redo copy latch

redo copy latch는 상기 순서를 실행하는 동안 보관 유지되고 있습니다. 빈 공간을작성하기 위해서 로그 스윗치가 실행되었을 때에 해방되어 로그 스윗치가 종료하면 다시 취득합니다.

・redo allocation latch

SGA내의 REDO log buffer에 대한 REDO 엔트리의 기입을 직렬화하기 위해서 사용됩니다. 트랜잭션(transaction)량이 적은 혹은 1 CPU의 서버인 경우에는 redo allocation latch는 redo copy latch를 획득하지 않고  REDO를 REDO log buffer에 씁니다.빈 스페이스를 획득하기 위해서 로그 스윗치가 필요하게 되는 경우는 이 Latch는 redo copy latch와 함께 해방됩니다. 이 Latch는 데이타베이스에 1개 밖에 없습니다.

・redo writing latch

LGWR 프로세스에 대해서 동시에 복수 프로세스에 의한 로그 스윗치의 요구가 발생하는 일을 막습니다.

빈 공간이 필요한 프로세스는 LGWR에 REDO 로그 버퍼로부터 REDO 로그 파일에의 쓰거나  혹은 로그 스윗치의 실행을 요구 하거나 단지 대기할까를 판단하기 이전에 이 latch을 취득해야 합니다. 　

REDO log buffer에 있어서의 Latch 할당의 동작에 관련하는 2개의 파라미터가 있습니다.

・LOG_SIMULTANEOUS_COPIES

  시스템이 복수CPU를 가질 때 redo copy latch의 수를 제어

・LOG_SMALL_ENTRY_MAX_SIZE

  REDO log buffer에 REDO를 쓸 때 redo allocation latch를 취득할지 아닐지를 결정하는 기준

REDO log buffer에 있어서의 경합은 모든 DML 및 DDL문은 실행전에 REDO 엔트리를 작성 할 필요가 있기 때문에 퍼포먼스상 중요합니다. 경합은 Latch 경합 혹은 REDO 로그 버퍼에 대한 빈 공간의 과도의 요구가 있는 것으로 확인할 수 있습니다. 이하에 열거한 2 종류의 경합이 발생하고 있는 일을 검출하는 것이 가능합니다.

・Latch 경합

    SELECT  substr(ln.name, 1, 20) "latch type",
                  100*(misses + immediate_misses)/(gets +
                  immediate_gets + immediate_misses) "latch utilization(%)"
       FROM v$latch l, v$latchname ln
     WHERE  ln.name in ('redo allocation', 'redo copy')
   　　 and ln.latch# = l.latch#;

이 결과 latch utilization가 1%를 넘는 경우 Latch 경합이 발생하고 있다란것을 의미합니다. redo copy latch의 전에 redo allocation latch의 튜닝을 실시하는 일을 추천합니다.redo allocation latch는 인스턴스에 1개 밖에 없기 때문에 redo allocation latch의 경합은 퍼포먼스상 영향도가 높기 때문입니다.

Oracle7,8i에서는 redo alocation latch의 경합이 발생하는 경우 LOG_SMALL_ENTRY_MAX_SIZE의 값을 낮추고 redo copy latch가 획득되기 쉽게 조정하는 것이 좋다. 추천치는 평균의 REDO 사이즈이며 이하의 SQL의 결과의 'redo size'를 'redo entries'의 값으로 나눈 값이 됩니다.

    SELECT value
       FROM v$sysstat
    WHERE name in ('redo size','redo entries');

다만 이 SQL를 실행할 때는 실전 환경과 같은 조건이 아니면 적절한 결과를 얻을수 없습니다. redo copy latch 경합이 발생하고 있는 경우는 LOG_SIMULTANEOUS_COPIES 파라미터를 증가시키는 것으로 새로운 redo copy latch를 추가시킬 수가 있습니다.이 파라미터의 추천치는 CPU수*2 가 됩니다.

Oracle8i에서는 redo allocation latch 경합이 발생하고 있는 경우, 특정의 처리에 대해서는  NOLOGGING 옵션을 사용하면 생성되는 REDO를 감소시킬수  있습니다

혹은 LOG_BUFFER 파라미터를 증가시키는 것으로 latch의 부하를 낮추는 것이 가능합니다. LOG_BUFFER 파라미터의 튜닝에 관해서는 KROWN#18227 로 소개있습니다.redo copy latch 경합이 발생하고 있는 경우 Oracle8 이전과 같이 LOG_SIMULTANEOUS_COPIES를 증가 시킨다.

・영역 할당의 리퀘스트의 경합

REDO log buffer의 영역 할당을 대기한 회수는 "redo buffer allocation retries"라는 통계로 카운트 됩니다. 다음의 SQL를 사용하고, 어플리케이션이 동작중의 통계치를 감시해야 합니다. 

    SELECT name,valus
　    FROM v$sysstat
　　WHERE name = 'redo buffer allocation retries';

"redo buffer allocation retries"의 값은 0인 것이 이상적입니다.
이 값이 증가 경향에 있는 경우에는 LOG_BUFFER 파라미터의 값이 너무 작을 가능성이 있습니다.
LOG_BUFFER의 튜닝 방법에 대해서는 Krown:18227을 참조하십시오.