09.26
뉴스홈 > 종합/정책
베리타스의 DB 성능관리
엔드-투-엔드 데이터베이스 성능 관리
인프라스트럭처에서 애플리케이션 영역까지 포괄적인 접근 필요

가트너그룹은 글로벌 2000대기업의 대부분이 적게는 500개에서 많게는 1,000개에 이르는 애플리케이션을 운영하고 있으며, 이러한 애플리케이션의 대부분이 커스터마이즈를 요구하는 것으로 추정하고 있다. 애플리케이션 아키텍처는 메인프레임 시스템에서 분산형 멀티-티어 클라이언트 서버 환경에 이르기까지 환경에 따라 크게 달라지지만, 데이터를 관계형 데이터베이스에 저장하는 것만큼은 모든 기업에 공통적으로 적용되는 요구사항이다.
애플리케이션 응답시간에서 가장 많은 부분을 차지하는 것이 데이터베이스의 프로세싱 타임이기 때문에, 애플리케이션 성능 문제를 진단하는 과정에서 가장 철저하게 점검되는 부분이 바로 데이터베이스(그것이 Oracle, DB2, Sybase, 또는 SQL Server 중 어떤 것이든)이다. 하지만 다양한 애플리케이션의 종류, 복잡한 아키텍처 등으로 인해 DBA가 성능 문제를 효과적으로 진단하고 해결하기가 현실적으로 매우 어려운 상황이다.
애플리케이션 성능 저하 현상에 대한 엔드 유저의 요청을 빠른 시간 안에 해결하기 위해서는, 폭넓은 범위의 모니터링 및 진단 기술이 필요한다. 분산 컴퓨팅 환경의 엔드 유저가 마우스를 클릭하거나 엔터 키를 누르는 순간, 정보는 복잡한 네트웍 경로를 따라 이동하여 다수의 서버와 스토리지 서브시스템으로 전달된다.
각각의 경로, 그리고 경로 상의 서버 및 스토리지 서브시스템은 애플리케이션 성능을 제약할 수 있는 잠재적인 문제 요소로서 작용한다.
베리타스는 분산 컴퓨팅 인프라스트럭처에 대한 포괄적이면서도 심도 있는 성능 분석 테크놀로지를 보유하고 있으며, 성능 문제를 해결하기 위한 솔루션 지향형 접근법을 제공한다는 점에서 다른 벤더와 차별화된다. 베리타스의 데이터베이스 성능 솔루션들은 데이터 베이스의 고성능 환경 실현을 위한 최상의 인프라스트럭처 기반을 구현한다. 시스템 관리자와 DBA는 이러한 툴을 이용하여 애플리케이션 성능 이슈의 근본 원인을 확인하고 문제 해결을 위한 즉각적인 조치를 실행할 수 있다.

데이터 경로의 매핑
애플리케이션 서버(데이터 요청자)와 스토리지 서브시스템(데이터 소스) 간의 데이터 교환 과정은, 분산 컴퓨팅 환경에서의 성능관리가 얼마나 복잡한 문제인지를 단적으로 보여준다.
애플리케이션의 개별적인 데이터 요청은 내용적인 면에서 매우 단순하다. 애플리케이션이 SQL 구문을 발행하는 경우, 조건을 만족하는 데이터 레코드들이 반환된다.
모든 비즈니스 애플리케이션은 데이터 액세스를 기반으로 하고 있으며, 실제로 이러한 데이터 액세스 시간은 전체 애플리케이션 응답시간의 약 80 퍼센트 가량을 차지한다. 따라서 애플리케이션 성능 문제의 이면에는 대개 데이터베이스의 문제가 숨어 있다.
애플리케이션 프로그램은 데이터베이스로부터 데이터를 가져오기 위해 SQL 구문을 발행한다. SQL은 비즈니스 애플리케이션을 위한 표준 데이터 액세스 언어로서, 관계형 데이터베이스 시스템의 기본 인터페이스의 역할을 담당한다. 애플리케이션 서버는 SQL 구문이 데이터베이스에 전달되기 전에 네트웍 전송을 위해 SQL 구문을 변형시킨다.
이러한 변형작업은 ODBC(Open Database Connectivity), JDBC (Java Database Connectivity) 등으로 불리는 DBMS 드라이버 소프트웨어에 의해 수행된다. SQL 구문은 여러 컴포넌트로 분절된 후, 라우터, 허브, 스위치 등의 네트웍 인프라스트럭처를 거쳐 최종적으로 데이터베이스 서버에 도달한다.
데이터베이스는 SQL 구문을 재조립하고 서버에 저장된 데이터 테이블에 대하여 해당 구문을 수행한다. 데이터베이스는 스토리지 서브시스템의 하나 또는 그 이상의 테이블과 인덱스에 대해 I/O 요청을 발행한다. 만일 update, insert, delete 구문이 포함된 경우라면 데이터베이스 로그 파일에 대한 접근 또한 이루어져야 한다.
데이터베이스와 스토리지 서브시스템 간의 상호작용은 데이터 액세스 과정에서 매우 큰 비중을 차지한다. 애플리케이션 응답시간의 80%는 데이터베이스 요청을 처리하는 데 소요되며, 데이터베이스 요청을 처리하는 시간의 80%는 물리적인 I/O를 수행하는 데 소요된다. 엔터프라이즈 데이터베이스의 백엔드 스토리지는 하드-엔드 스토리지 어레이로 구성되는 경우가 대부분이고, 또 많은 경우 다수의 하이-엔드 스토리지가 병렬적으로 구성되기도 한다. 오늘날 사용되는 스토리지 어레이는 대용량 저장공간을 지원하므로 고성능 SAN(Storage Area Network)을 통해 여러 서버에 의해 공유되는 것이 일반적이다. 이를 위해 많은 네트워킹 컴포넌트가 데이터 경로 상에 위치하게 되며, 경우에 따라 애플리케이션 서버 간의 자원 경합이 발생하게 될 소지가 있다.
데이터베이스 시스템이 발생시키는 I/O 요청이 물리적 디스크로 직접 전달되는 경우는 존재하지 않는다. 각각의 요청은 하부 물리 환경을 추상화하는 복잡한 논리적 계층을 통과해야만 한다. 파일 시스템, 로지컬 볼륨 매니저(logical volume manager), 스토리지 어레이, 볼륨 매니저 스트라이핑/미러링, 또 어레이의 플렉스(plex)와 서브디스크(sub-disk) 등을 모두 거친 후에야 I/O 요청이 물리적 하드 디스크에 도달하게 되는 것이다.

성능 관리의 문제
DBA들은 고속 데이터 액세스를 보장하는 한편으로 쉽게 관리 가능한 데이터베이스 시스템을 구현해야 한다는, 서로 모순적인 요구사항을 놓고 고민하고 있다.
애플리케이션 데이터 액세스 과정이 복잡하면 복잡할수록, 성능 문제의 진단과 일상적인 관리 업무는 어려워질 수 밖에 없다. 데이터 경로의 모든 지점이 잠재적인 성능 병목으로 작용하므로, SQL 구문의 프로세싱 과정에서 성능 저하가 발생할 가능성은 그만큼 높아진다.
또 문제가 발생한 경우 어느 곳을 먼저 보아야 하는 지 판단하기도 어렵다. 애플리케이션의 성능 패턴은 변화무쌍하다. 사소한 변경 작업으로 인해 성능이 심각하게 저하되는 현상이 나타나기도 한다. 따라서 문제를 신속하게 확인할 수 있어야 할 뿐 아니라, 장기적으로 데이터 액세스 관련 성능을 추적할 수 있어야 한다. 점진적인 성능의 변화 양상을 지속적으로 감시함으로써, 심각한 문제로 발전되기 전에 사전 예방이 가능하다.

가시성(Visibility)
오늘날 사용되는 성능 모니터링 툴과 관리 툴은 개별적인 데이터 액세스 계층을 감시하며, 각각의 도메인에 한정된 뷰를 제공한다. 하지만, 여러 계층으로 구성된 멀티-벤더 시스템에서 SQL 구문은 복잡한 경로를 이동해야 하며, 빠르고 효과적인 문제 진단이 어렵다.
이러한 환경에서 시스템 관리자가 SQL 구문 실행의 성능 경로를 한 눈에 파악하는 것이 불가능하다. 시스템 관리자가 SQL의 실행에 관련하여 직접적인 책임을 지지 않는 상황이라면, 문제 발생 시 책임 전가가 뒤따르게 될 확률이 높다.
문제의 원인을 파악하지 못한 시스템 관리자는 문제의 책임을 다른 사람에게 돌리려 할 것이다. 한편 사용자 응답시간이 저하되었다는 사실을 통보 받은 애플리케이션 관리자는 데이터베이스를 문제의 원인으로 지적한다. DBA는 데이터베이스에서 문제를 발견하지 못하고 스토리지 서브시스템을 원인으로 진단한다. 스토리지 관리자는 문제와 관련된 I/O를 확인할 수 없으므로 다시 책임을 애플리케이션 관리자에게 떠넘긴다.
애플리케이션 서버 관리자는 서버의 성능을 진단하기 위한 툴을 사용하고 있지만, 서버 바깥쪽의 문제에 대해서는 아무런 관리 방법을 갖고 있지 못하다. 네트웍 관리자는 네트웍 인프라스트럭처의 건강 상태를 점검할 수 있지만, 개별적인 패킷과 데이터베이스 요청의 상관관계를 파악하지 못한다.
DBA가 사용하는 툴은 SQL 구문의 효율성을 확인하는 데는 효과적이지만, 상부의 애플리케이션 그리고 하부의 스토리지 환경에 관련한 성능은 모니터링할 수 없다. 애플리케이션의 데이터 접근 요청은 I/O의 형태로 변환되어 다양한 논리 계층을 거쳐 물리적 하드 디스크로 전달된다. 스토리지 관리자가 보유한 툴은 I/O 레벨의 성능 문제를 진단하는 데 유용하지만, 어떤 I/O가 어떤 비즈니스와 연관되어 있는지 확인할 방법은 없다.
IT 환경이 결코 단일 벤더 제품으로만 구성되어 있지 않다는 사실은 문제 해결을 더욱 어렵게 한다. 애플리케이션 서버, 운영 체제, SAN, 스토리지 어레이, 스토리지 관리 소프트웨어, 데이터베이스 서버, DBMS 시스템 등은 모두 서로 다른 벤더의 제품으로 구성된다. 벤더에 의해 제공되는 툴이 특정 플랫폼의 성능 문제만을 진단할 수 있다는 것은 결코 놀라운 일이 아니다. 분산 환경에서 효과적으로 성능 문제를 진단하기 위해서, DBA는 관련된 모든 툴의 사용법을 알고 있어야만 한다.

성능의 점진적인 저하
애플리케이션에 대한 테스트 준비가 아무리 완벽하다 해도, 실제 운영 환경과 똑같을 수는 없다. 운영 단계로의 진입 과정에는 언제나 예기치 않은 사고가 있게 마련이고, 이러한 사고는 대개 성능 문제로 연결된다.
개발자와 DBA들은 애플리케이션과 사용자의 상관관계를 깊이 이해하고 있다고 자신하지만, 실제 환경에서는 상황이 달라진다. 많은 성능 문제는 운영 단계로 넘어간 후에 비로소 발견된다. 또 성능은 시간의 흐름에 따라 계속적으로 변화하고, 이 때문에 성능 문제의 원인을 확인하는 것이 더욱 어려워진다.
시간의 흐름에 따라 점진적으로 나타나는 경우, 어제의 쿼리 성능과 오늘의 쿼리 성능을 비교하면 아무런 차이가 없는 것처럼 보이기도 한다. 하지만 석 달 전과 오늘의 성능을 비교하는 경우 이상 현상이 분명하게 확인될 수 있다. 이처럼 기간별 성능을 비교 분석함으로써, 발생된 문제의 원인을 좀 더 효과적으로 파악할 수 있다. 이러한 수준의 진단과 분석을 수행하기 위해서는, 먼저 애플리케이션의 성능 베이스라인을 분명하게 이해하고 있어야 한다. 정상적인 상태가 무엇인지 정의되어 있는 상황에서만 이상 현상의 정의도 가능하기 때문이다.
애플리케이션의 일반적인 행태(behavior)를 이해하려면 지속적인 모니터링이 필수적이다. 하지만 여기에도 딜레마는 있다. DBA가 사용하는 모니터링 툴들은 장기적인 관점에서의 추이 분석에 필요한 상세한 배경 정보를 제공하지만, 다른 한편으로 상당한 수준의 성능 오버헤드를 수반한다. 비즈니스 애플리케이션이 자원 부족으로 인해 문제를 겪고 있을 때 DBA는 성능 모니터링 툴을 꺼야 하는지, 아니면 성능 저하를 감수하고 모니터링을 계속해야 하는지 고민할 수밖에 없다.

변화가 심한 환경에서의 성능 관리
데이터베이스 성능 관리는 지속적으로 수행되어야 하는 프로세스이다. 변화가 빠르고 심한 비즈니스 환경에서, 성능 문제는 예기치 않게 발생되기 마련이고 DBA는 이에 대해 신속하고 효과적으로 대응할 수 있어야 한다.
애플리케이션 인프라스트럭처의 성능 정보에 대한 접근이 빠르면 빠를수록, DBA는 짧은 시간 안에 문제 확인 절차를 마치고 해결책을 내놓을 수 있다. 하지만 발생된 문제를 해결하기 위해 (시스템 재구성을 위해) 사용자의 애플리케이션 접근을 일정 시간 차단해야 할 수 있다.
미션 크리티컬 비즈니스 시스템의 사용자들은 일체의 다운타임을 용납하지 않는다. SLA 계약 조건에 따라서는 벌금을 물어야 할 수도 있다. 이런 상황에서는 DBA가 선택할 수 있는 해결책이 제한될 수밖에 없다.

파일 시스템과 로우 파티션
성능에 대한 요구사항은 때로 보다 거시적인 관점의 관리성에 대한 요구사항과 충돌하기도 한다. 데이터베이스 데이터의 컨테이너(또는 데이터파일)로서 파일 시스템을 사용할 것인지 아니면 로우 파티션(raw partition)을 사용할 것인지 선택하는 문제가 그 한 예이다.
데이터베이스 데이터를 보관할 컨테이너 또는 데이터파일을 선택할 때에는 로컬 파일 시스템과 로우 파티션(포맷되지 않은 채 데이터베이스 시스템에 직접 매핑 되는 데이터 블럭)의 둘 중 하나를 선택할 수 있다. 파일 시스템을 선택하는 경우, 파일의 관리 작업을 단순화할 수 있기 때문에 초기 개발에 소요되는 시간이 단축된다. 또 온라인 상태에서 파일 시스템의 크기를 다이내믹하게 확장할 수 있으며, 마찬가지로 온라인 상태에서 다른 볼륨을 추가하는 것도 가능하다.
로우 파티션(raw partition)은 용량 문제와 관련해 지속적인 모니터링과 관리를 필요로 한다. 테이블스페이스의 용량이 부족한 상황이 되더라도 다이내믹한 용량 확장은 불가능하다. DBA의 수작업으로 용량을 늘릴 수는 있지만, 그 프로세스가 복잡하고 많은 시간이 소요될 뿐 아니라 데이터베이스를 오프라인 처리하는 과정을 필요로 한다. 용량 문제로 인한 번거로운 수작업을 피하기 위해서는 초기에 로우 파티션의 용량을 정확하게 산정해 두어야 하며, 결국 필요 이상의 스토리지 공간을 점유하는 구성이 불가피하다.
로우 파티션의 관리적인 단점은 성능상의 이익에 의해 상쇄된다. 파일 시스템은 데이터 경로 상의 또 하나의 소프트웨어 추상화 계층으로 작용하며, SQL 요청의 처리 과정에서 추가적인 프로세싱을 요구하게 된다. 로우 파티션은 파일 시스템의 중복적인 I/O 처리 요소를 제거하며, 데이터베이스가 스토리지 디바이스와 보다 직접적인 형태로 커뮤니케이션할 수 있게 한다.

베리타스 데이터베이스 성능 관리 솔루션
베리타스의 솔루션은 전체 데이터 경로에 대한 가시성을 제공하는 한편 포괄적인 성능 관리, 모니터링 및 문제해결을 가능하게 한다. VERITAS Indepth는 애플리케이션 인프라스트럭처, 데이터베이스, 스토리지 환경 등 데이터 접근 경로 전반에 대한 종합적인 성능 프로파일을 제공한다.
Indepth를 이용해 문제를 확인한 후, VERITAS Storage Foundation for Database를 통해 서비스의 중단 없이 필요한 변경 작업을 수행할 수 있다. Indepth와 Storage Foundation for Database의 조합을 통해 Oracle, DB2, Sybase, SQL Server 기반 환경의 토탈 성능 관리 솔루션을 구현할 수 있다.

성능 문제의 분석
데이터베이스 쿼리가 여러 계층의 인프라스트럭처를 거쳐야만 하는 복잡한 멀티-티어 환경에서 신속하게 문제를 해결하려면 각 데이터 경로 계층에 대한 분석이 가능해야 한다. 성능 문제의 근본 원인을 정확히 파악하고, 조직 간의 책임 전가를 예방하려면, I/O 스택에 대한 드릴 다운을 통해 심도 있는 분석을 수행할 수 있어야 한다.
VERITAS Indepth는 멀티-티어로 구성된 데이터베이스 및 스토리지 시스템의 성능을 신속하게 분석하기 위한 데이터 수집 및 리포팅 툴을 제공한다.

성능 모니터링
VERITAS Indepth는 데이터베이스가 사용하는 메모리 영역에 대한 샘플링 기법을 사용하여 데이터베이스 엔진에 주는 성능 오버헤드를 최소화한다. Indepth는 수십 분의 일 초 단위로 각각의 SQL 구문이 사용하는 자원을 개별적으로 분석한다. 관리자는 데이터베이스 성능에 대한 염려 없이, Indepth를 사용하여 하루 24시간 데이터베이스를 모니터링 할 수 있다.
Indepth의 데이터 수집 에이전트가 데이터베이스를 샘플링 하는 간격은 초당 1회에서 99회 사이의 수치로 설정 가능하다. 이처럼 샘플링 주기를 조절함으로써, 복잡한 구조를 갖는 트랜잭션의 자원 사용현황을 정밀하게 분석할 수 있다.
에이전트 소프트웨어는 데이터베이스 시스템이 사용하는 18 종류의 자원(I/O, CPU 사용량, Memory 대기시간, Redo Log 액티비티, Rollback Segment 접근, 로그 스위칭, Lock 경합 등)을 추적한다. 수집된 데이터는 단기적으로 파일에, 장기적으로는 Indepth Performance Warehouse 리포지토리에 보관되며 GUI를 통해 조회할 수 있다.

성능 튜닝
문제 발생에 대한 경고 메시지를 접수한 DBA는, Indepth GUI를 사용하여 데이터베이스 환경에 무슨 일이 일어났는지 신속하게 확인할 수 있다. SQL 구문, 프로그램, 사용자, 데이터베이스 오브젝트 별 자원 사용량을 기준으로 한 순위 리스트가 제공되므로, 가장 많은 자원이 소모되는 곳이 어디인지 쉽게 파악할 수 있다.
문제와 관련된 SQL 구문이 확인되고 나면, GUI의 드릴다운 메뉴를 통해 현상을 심도 있게 분석할 수 있다. Indepth GUI는 구문의 explain 정보와 액세스 플랜(access plan)을 단계별로 제시하며, 문제가 있어 보이는 부분을 컬러 코드와 플래그로 구분하여 표시한다. 이러한 분석을 통해, (예를 들어) 쿼리가 인덱스를 사용하지 않고 풀 테이블 스캔을 수행하고 있다는 사실을 확인할 수 있다.
또 문제가 발생되기 이전에 액세스 플랜에 대한 사전 분석을 실행하는 것도 가능한다. 예를 들어, 쿼리가 수백만 개의 레코드를 갖는 테이블에 풀 스캔을 수행하고 있는 것을 GUI를 통해 확인한 DBA는 후속 조치로 테이블의 statistics를 업데이트하게 된다.
Indepth Performance Warehouse는 모든 SQL 구문의 explain 정보와 함께, 각 구문의 시간대별 자원사용현황을 수집하여 저장한다. 이렇게 수집된 데이터를 통해 정상적인 성능 프로파일에서 벗어나는 이상 현상을 확인할 수 있다. 예를 들어 쿼리의 응답시간 문제가 지속적으로 발생되어 온 것인지 아니면 갑작스럽게 나타난 것인지 등을 확인하는 것이 가능하다.
수집된 성능 데이터는 문제의 성격을 분석하고 해결 방안을 결정하기 위한 핵심 정보로서 활용된다. 이전까지 잘 수행되던 쿼리가 갑자기 느려졌다면, DBA는 먼저 최근 환경에 어떤 변화가 있었는지 확인해야 한다. DBA는 Performance Warehouse의 히스토리 정보를 통해 성능의 변화 추이를 파악한 후 “What-if” 형식의 영향 분석을 수행하고 가능한 해결책을 찾을 수 있다.
예를 들어 인덱스에 대한 변경 작업으로 인해 특정 구문의 실행 속도가 빨라진 반면, 다른 20개 구문의 실행 속도가 느려진 것은 아닌지 확인할 수 있다.

해결책의 제시
Indepth의 가장 강력한 기능 중 하나로, 데이터베이스 환경의 성능 개선을 위한 전문적 조언을 제공하는 것을 들 수 있다. 예를 들어 전혀 사용되지 않는 인덱스에 플래그 처리를 하는 등, DBA가 데이터베이스 환경을 최적화하는 데 필요한 중요한 변경 사항을 제안한다.
Indepth SmarTune 기능은 Performance Warehouse의 자원 사용량 정보와 SQL 구문 정보를 기반으로 분석을 수행한 뒤, 인덱스 사용과 SQL 구문에 대한 상세한 조언을 제시한다. GUI 화면에서 SmarTune을 선택하는 경우, Indepth는 SQL 코딩의 개선, 또는 인덱스의 개선을 위한 해결방안을 제공한다.

제너릭 로그온에 대한 실제 사용자의 구분
DBA에게 있어 다른 성능관리 애플리케이션들이 사용하는 제너릭 로그온(generic database signon) 기능은 심각한 골칫거리이다. 요청자가 누구인지 분명하게 확인할 수 없기 때문에 성능 문제의 진단이 어렵기 때문이다. Indepth의 Interpoint extestion은 이러한 문제 요인을 완벽하게 제거하며, SAP, Oracle E-Business Suite, Peoplesoft 등의 패키지 애플리케이션으로부터 전달되는 쿼리가 실제 사용자, 또는 프로그램 별로 추적될 수 있도록 보장한다.
DBA는 Interpoint 기능을 활용하여 패키지 애플리케이션에 대한 가시성을 확보할 수 있다. 모든 SQL 구문은 개별적인 데이터베이스 로그온을 통해 접속하는 내부 개발 애플리케이션의 경우와 동일한 형태로 상세하게 추적될 수 있다. SQL 구문을 개별 사용자, 모듈, 트랜잭션, 프로그램, 스크린, 리포트 등과 연계할 수 있으며, 더 나아가 불필요한 인덱스 등의 데이터베이스 오브젝트 분석 또한 가능하다.
패키지 애플리케이션의 설치 과정에서 전혀 불필요한 인덱스가 생성되는 경우가 많은데, 어떤 인덱스가 어떤 애플리케이션에 의해 사용되고 있는지 확인할 수 없다면, 제거 대상을 선택할 수도 없습니다. 이처럼 불필요한 인덱스를 제거하는 경우 데이터베이스의 성능이 극적으로 향상될 수 있다.

스토리지 성능과 데이터베이스 성능의 상호연계
EMC, IBM, HP, Hitachi Data Systems 스토리지 어레이 등에 대해 제공되는 Indepth Storage Extension 플러그인을 사용하는 경우, DBA는 스토리지 서브시스템 계층의 자원 사용현황에 대한 가시성을 확보할 수 있다.
Storage Extension을 활용함으로써 데이터베이스 레벨에서 수집한 성능 지표들을 더욱 정밀하게 분석할 수 있다. DBA는 이 정보를 활용하여 문제가 되는 쿼리에 대한 물리적 디스크 레벨의 드릴다운을 수행하게 된다. Indepth GUI에서 데이터베이스 서버에서 물리적 디스크에 이르는 각 논리적 계층을 분석할 수 있다. 여기에서 분석의 대상이 되는 논리 계층에는 데이터베이스 서버에서 정의한 논리적 볼륨과, 스토리지 어레이에서 정의한 논리적 볼륨, 하이퍼볼륨(hypervolume) 등이 포함된다.
스토리지 관리자는 Indepth와 Storage Extension에서 생성된 성능 데이터를 활용하여 스토리지 환경에 발생한 문제의 원인을 분석할 수 있다. 예를 들어 특정 디스크가 평균 이상의 I/O 부하 수준을 보이는 경우, 스토리지 관리자는 Indepth GUI를 사용하여 어떤 데이터베이스 오브젝트가 문제의 원인이 되는지, 어떤 쿼리가 I/O와 관련이 있는지, 그리고 어떤 사용자가 해당 쿼리를 실행하고 있는지 확인할 수 있다.
만일 그 쿼리가 자주 사용되지 않는 것이라면, DBA는 별도의 조치가 불필요하다고 판단할 것이다. 반면 보다 체계적인 조치가 필요한 경우라면, DBA는 데이터베이스 오브젝트를 별도의 디스크로 옮기는 것이 좋을지, 아니면 데이터베이스 오브젝트에 대한 튜닝을 수행하는 것이 좋은지 검토하게 된다.
대규모 스토리지 어레이에 다양한 애플리케이션, 데이터베이스, 웹 서버를 연결하여 사용하는 환경이라면, 둘 혹은 그 이상의 서버의 경합으로 인해 발생하는 I/O 자원 문제는 확인하기가 무척 어렵습니다. Indepth Storage Extension은 이러한 종류의 문제를 해결하기 위해 필요한 정보를 제공한다. 특정 서버에 한정되지 않고 전체 스토리지 어레이에 걸쳐 데이터를 수집함으로써, 문제를 해결하기 위한 전체 맥락을 파악하고 성능병목의 원인을 분명하게 확인할 수 있게 한다.

변경 사항에 대한 영향 분석
Indepth Performance Warehouse는 데이터베이스에서 실행되는 모든 SQL 구문에 대한 정보를 보관한다. 이렇게 수집된 데이터가 데이터베이스 오브젝트와 연계되고, 자원 사용에 관련한 히스토리가 Performance Warehouse에 의해 추적될 수 있다면, DBA는 문제가 발생하기 전에 환경 변화의 영향을 점검할 수 있는 시야를 확보하게 된다.
데이터베이스에 변경을 적용하기 전에 영향 분석(impact analysis)를 수행할 수 있는 환경을 구현함으로써 문제의 가능성을 최소화할 수 있다. 예를 들어 새로 작성한 쿼리가 풀 테이블 스캔을 사용하는 것으로 분석된다면, DBA는 기존의 인덱스를 버리고 데이터베이스의 query optimizer가 선택할 가능성이 높은 새로운 인덱스를 생성하게 된다. 이때 기존의 인덱스를 버리기 전에 Indepth GUI에서 영향 분석을 수행하여 인덱스를 이용하던 다른 쿼리에 성능적인 영향이 없는지 점검할 수 있다.
분석 결과 다른 두 개의 쿼리가 인덱스를 사용하고 있는 것으로 확인되었지만 두 쿼리 모두 자원 사용에 관련한 통계를 Per- formance Warehouse에 전혀 남기지 않았다면, 두 개의 쿼리가 지금까지 한 번도 실행되지 않았다고 판단할 수 있다. DBA는 이러한 정보에 기반하여 인덱스를 안전하게 제거하고 애플리케이션에 성능적인 영향이 없음을 확인할 수 있다.

트렌드 분석 및 용량 계획
Indepth Performance Warehouse에 저장된 자원 사용 히스토리 정보는 트렌드 분석 및 용량 계획에 매우 유용하게 활용된다. Indepth 에이전트 소프트웨어에 의해 시간대별로 수집된 정보를 기반으로 한 성능 통계 리포팅을 통해 장기적인 관점의 변화를 파악할 수 있다.
이러한 형태의 분석을 이용하면 매우 오랜 기간에 걸쳐 점진적으로 일어나는 변화를 확인할 수 있고, 따라서 미래에 발생할 수 있는 문제를 사전에 예방하는 데 도움이 된다.
Performance Warehouse에 저장된 히스토리 정보는 하드웨어 구매 계획을 세우는 과정에서 활용될 수도 있다. 일정 기간 동안의 데이터베이스 운영 상황을 추적함으로써, 하드웨어 자원 사용의 추이를 정확하게 분석할 수 있다. 인프라스트럭처의 컴포넌트 별로 하드웨어 업그레이드가 필요한 시기를 예측할 수 있으므로, 벤더와의 협상 시 유연한 대처가 가능하다.

성능 문제의 해결
데이터베이스 시스템이 충분한 메모리와 프로세싱 자원을 보유하고 있는 경우라면, 문제의 원인은 비효율적인 SQL 구문, 데이터베이스 오브젝트의 설계 문제, 또는 스토리지 환경의 문제 중 하나일 가능성이 높다.
SQL 또는 데이터베이스 오브젝트에 문제가 있다면, 서버 또는 데이터베이스 서버에 대한 변경작업으로 문제를 해결할 수 있다. VERITAS Storage Foundation for Databases는 스토리지 환경의 성능 문제를 해결하고 생산성을 향상시키기 위해 필요한 툴을 DBA에게 제공한다.

유연한 스토리지 인프라스트럭처
VERITAS Storage Foundation for Databases 내에 포함된 VERITAS Volume Manager와 VERITAS File System은 데이터베이스의 성능과 안정성을 확보하기 위한 기반 환경을 제공한다.
Storage Foundation for Databases는 스토리지 인프라스트럭처의 다이내믹한 변경을 지원하므로, DBA는 서비스의 중단 없이 신속하게 성능 문제를 해결할 수 있다.
Quick I/O 및 Cached Quick I/O 기능은 데이터베이스 파일을 파일 시스템에 보관함으로써 관리성을 향상시키는 한편 로우 파티션(raw partition)에 준하는(또는 그 이상의) 성능 조건을 제공한다. Storage Foundation은 I/O 관련 데이터베이스 성능 문제의 신속한 해결, 유연한 스토리지 인프라스트럭처 관리, 그리고 자동화된 스토리지 관리 환경을 제공한다.
Storage Foundation의 자동화된 스토리지 성능 관리 기능은 에이전트 소프트웨어를 통해 구현된다. 에이전트는 파일 시스템을 지속적으로 모니터링하면서 스토리지 사용률에 관련된 성능지표를 추적하고, 데이터베이스 오브젝트의 성능지표가 DBA에 의해 미리 정의된 임계치를 넘어서는 경우 자동적으로 조치를 취한다.

- VERITAS Enterprise Administrator
VERITAS Enterprise Administrator(VEA) GUI는 관리자가 직관적인 인터페이스를 통해 Storage Foundation의 핵심 기능을 활용하고 중앙집중적으로 다수 서버를 관리할 수 있는 환경을 제공한다. GUI의 드래그-앤-드롭 기능을 이용하여 네트웍 어디에서든 시스템 관리 및 구성 작업을 수행할 수 있다.
예를 들어, 용량이 부족한 디스크로부터 여유공간이 충분한 디스크로 볼륨을 (온라인 상태에서) 이동시킬 수 있다. 그 밖에 VEA GUI가 지원하는 기능으로 다이내믹 RAID 재구성 기능을 들 수 있다.

- Discovered Direct I/O
VERITAS Storage Foundation for Databases의 Discover Direct I/O는 스토리지 인프라스트럭처의 I/O 패턴을 지속적으로 모니터링하면서 성능 향상이 가능한 부분을 찾아낸다.
대량의 데이터 전송을 수반하는 I/O는 자동으로 캐시 프로세싱을 우회하도록 설정되므로, 스토리지 볼륨에 대한 쓰기 작업의 성능을 향상시킬 수 있다.

- Dynamic Multipathing
Storage Foundation Volume Manager가 지원하는 DMP(Dynamic Multipathing)는, 스토리지 인프라스트럭처로 연결된 여러 개의 경로를 지능적으로 활용하기 위한 I/O 경로 최적화 기능이다. DMP 기능을 active/active 구성으로 활용하는 경우, I/O는 여러 경로에 걸쳐 분산된다.
정책 알고리즘을 통해 스토리지 디바이스로 연결되는 경로의 홉(hop)수를 파악하고 실시간으로 가장 최적화된 경로로 변경할 수 있다.
데이터베이스 가속기
Storage Foundation의 Quick I/O와 Cached Quick I/O를 이용하여 로우 파티션(raw partition)과 파일 시스템의 성능 격차를 무효화할 수 있다. 이 두 기능은 파일 시스템 환경의 관리성과 로우 디바이스 수준의 성능을 제공한다.
Quick I/O는 페이지 캐시(page cache)와 유사한 형태로 동작하는 외부 캐싱 메커니즘이다. 서버에서 현재 사용 가능한 가상 메모리는 Cached Quick I/O에 의해 점유되어 데이터베이스에 제공된다. 이렇게 확보된 메모리 자원은 운영체제의 메모리 할당 메커니즘을 우회하여 데이터 액세스 성능을 향상시키기 위한 버퍼 공간으로 활용된다. Cached Quick I/O는 일반적인 로우 파티션의 수준을 넘어서는 성능 효과를 제공한다.

데이터베이스 파일 마이그레이션
Storage Foundation for Databases는 데이터베이스의 마이그레이션 프로세스를 혁신적으로 단순화시킵니다. 같은 데이터베이스 인스턴스 내에 있는 데이터는 같은 스토리지 어레이에 있을 수도, 또는 다른 어레이에 위치할 수도 있다.
VERITAS File System의 멀티-볼륨 기능을 이용하면 현재 로우 파티션 상에 위치한 파일을 간단하게 마이그레이션하고 성능과 관리성을 동시에 향상시킬 수 있다.
예를 들어 500개의 로우 디바이스 파티션에 구성된 데이터베이스를 하나 또는 그 이상의 디스크 그룹에 통합하고 VERITAS File System으로 마이그레이션 할 수 있다. 과거에 이러한 구성을 변환하기 위해서는 500개의 파일 시스템이 필요하다. VERITAS는 이러한 기능을 지원하는 업계 유일의 벤더이다.

- Portable Data Containers
Portable Data Container(PDC)는 Storage Foundation for Databases에 새로 추가된 기능으로, 이기종 서버 아키텍처 상에서의 데이터 마이그레이션에 소요되는 시간을 혁신적으로 단축시켜 준다. PDC는 서로 다른 플랫폼 간의 데이터베이스 파일 마이그레이션을 지원하며, 이 경우 서비스 중단 시간은 최소화된다.
데이터베이스 데이터를 네트웍을 통해 이동(대용량 데이터베이스의 경우 엄청난 시간이 소요된다)하는 대신, PDC 기반으로 포맷된 디스크를 소스 시스템에서 언마운트 하고 다시 타겟 서버에 마운트 하는 작업 만으로 마이그레이션을 완료한다.
데이터 이동 작업은 전혀 필요치 않다. DBA는 PDC를 활용하여 이기종 플랫폼 간의 데이터베이스 마이그레이션 작업을 (그 크기에 관계없이) 최단 시간 안에 완료할 수 있다.

- Quality of Storage Service
동일 데이터베이스 내에서 파일 마이그레이션을 수행함으로써 I/O 경로를 최적화하고 성능을 향상시킬 수 있다. 예를 들어 인덱스 파일과 데이터 파일을 같은 스토리지 볼륨에 위치시키는 경우, I/O 경합으로 인해 SQL 쿼리 프로세싱 성능이 저하될 수 있다.
인덱스를 다른 볼륨으로 옮기면 데이터 액세스 성능은 향상된다. VERITAS Storage Foundation for Database의 Quality of Storage Service(QoSS) 기능은 스토리지 디바이스 내의 데이터베이스 파일을(서비스의 중단 없이) 온라인 상태에서 마이그레이션 하기 위한 툴이다.
자주 사용되지 않는 데이터를 테이프로 마이그레이션 하는 HSM(Hierarchical Storage Management) 솔루션과 달리, QoSS는 데이터의 하부구조를 전혀 변화시키지 않으므로, 데이터 이동 작업 역시 신속하고 효율적으로 진행된다.
QoSS는 스토리지 자원을 티어(tier) 단위로 구분하여 관리하는 것을 가능하게 한다. 예를 들어 EMC Symmetrix/DMX 어레이는 하이-엔드 스토리지 디바이스로, EMC CLARiiON 디바이스는 미드-티어 스토리지로, JBOD는 로우-엔드 스토리지로 구분할 수 있다. Storage Foundation의 멀티-볼륨 파일 시스템 기능을 이용하여 하나의 VERITAS File System을 여러 계층의 다수 스토리지에 걸쳐 구성하는 것이 가능하다.
만일 우선순위가 낮은 데이터가 하이-엔드 스토리지 어레이에 저장되어 있다면, 해당 파일은 자동적으로 낮은 순위의 스토리지 디바이스로 이동하며, 이 과정에서 온라인 데이터 액세스는 전혀 영향을 받지 않는다. QoSS는 스토리지 계층 간의 자동적인 파일 마이그레이션을 위한 정책 구현을 가능하게 한다.
QoSS를 이용하면 성능 향상을 도모할 수 있을 뿐 아니라, 자원 사용률을 대폭적으로 향상시킬 수 있다는 점에서 매우 유용하다. 하나의 파일 시스템 안에 다수의 스토리지 클래스를 구현하고 파일 마이그레이션 작업을 자동화함으로써, 높은 가치를 갖는 자원이 높은 우선순위를 갖는 데이터에 할당되도록 보장할 수 있다.

- 온라인 스토리지 마이그레이션
Storage Foundation for Databases는 단일 스토리지 내부의, 또는 하나의 스토리지에서 다른 스토리지로의 온라인 스토리지 마이그레이션을 지원한다.
서로 다른 벤더의 스토리지 간 마이그레이션 역시 가능하며, 관리자는 서로 다른 어레이를 연결하는 미러를 구성하고, 온라인 상태에서 미러를 분리하여 복제 데이터를 얻을 수 있다.

익스텐트 기반 파일 할당
VERITAS File System은 최상의 성능과 신속한 복구를 위한 익스텐트 기반의 인텐트-로깅(intent-logging) 파일 시스템이다. 디스크 공간은 연속적인 익스텐트(extent)의 단위로 파일에 할당된다. 이 구성은 블록 단위의 무작위적 할당을 사용하는 일반 운영체제 파일과 차이를 갖는다.
단일 파일 시스템 익스텐트에 데이터베이스 데이터를 위치시키는 경우, “sequential pre-fetch” 프로세싱이 발생할 가능성이 극대화된다. 데이터베이스는 애플리케이션이 요청한 데이터에 대해 sequential read가 발생하는 것을 감지하면, read ahead 알고리즘을 작동시키고 데이터를 캐시에 미리 읽어 둔다. 이때 데이터가 익스텐트가 아닌 블록 단위로 할당되어 있다면 pre-fetch 프로세스는 끊임없이 차단되어 성능 효과가 상쇄되어 버린다.

오프-호스트 프로세싱 (Off-Host Processing)
데이터베이스 성능 문제는 서버에서 실행 중인 작업이 자원을 두고 경합을 벌이는 상황에서 자주 발생한다. 예를 들어, 사용자가 접근 중인 OLTP 시스템에서 백업 프로세스를 실행하는 경우, 두 종류의 애플리케이션을 동시에 최적화하는 것이 불가능에 가깝기 때문에 응답시간이 느려질 수 밖에 없다. 결국 트랜잭션과 백업 프로그램은 하나의 자원을 두고 경합하게 되고, 백업 프로세스와 OLTP 애플리케이션의 응답시간이 함께 저하된다.
VERITAS Storage Foundation for Databases는 데이터베이스 백업, 리포팅과 같은 부하의 처리를 호스트에서 분리하여 수행하기 위한 FlashSnap 기능을 제공한다. FlashSnap은 포인트-인-타임 스냅샷 테크놀로지를 사용하여, 운영 중인 볼륨의 미러 복제본을 생성하고 필요한 경우 분리하는 원리로 동작한다.
스냅샷은 오프-호스트 프로세싱을 위해 백업 서버에 마운트 되고, 작업은 원본 볼륨과 독립적으로 수행된다. 오프-호스트 볼륨과 원본 데이터베이스 볼륨의 재동기화 시에는 스냅샷 분리 이후 변경된 데이터만이 복제되므로 매우 빠른 시간 안에 재동기화가 완료된다.
데이터베이스 스냅샷은 원본 데이터베이스 서버 성능의 일관성을 보장한다는 점에서 매우 효과적이다.
DBA는 VEA GUI에서 몇 번의 마우스 클릭만으로 FlashSnap 스냅샷을 생성하고 메인 데이터베이스 서버의 부하를 최소화하는 형태로 작업을 수행할 수 있다.

스토리지 매핑 (Storage Mapping)
Indepth Storage Extension의 매핑 기능과 별도로, VEA GUI는 데이터베이스의 스토리지 토폴로지에 대한 상세한 계층적 뷰를 제공한다. DBA에게 있어 고성능 데이터베이스를 설계하기 위해서는 물리적 스토리지 환경에 대한 지식이 필수적이다.
또 I/O 관련 성능 문제를 디버그 하거나 데이터베이스 문제로 스토리지 관리자와 커뮤니케이션 해야 하는 경우에도, 스토리지 인프라스트럭처, 그리고 스토리지와 데이터베이스의 관계에 대한 기본적인 이해가 필요하다.
VERITAS Storage Foundation for Database의 파일 매핑 기능을 통해, DBA는 복잡한 I/O 스택에 대한 가시성을 확보할 수 있다. 디스크 레벨의 I/O 통계를 이용하여 성능 병목 지점을 정확히 짚어 내고, 이를 다시 데이터베이스의 특정 오브젝트와 연계할 수 있다. 문제가 되는 컴포넌트를 확인한 뒤, I/O 경합이 발생하는 볼륨으로부터 인덱스 데이터를 이동하는 등의 조치를 취함으로써 문제가 해결된다.

실제 성능 문제 사례와 해결책
VERITAS Indepth와 VERITAS Storage Foundation for Database의 강력한 기능을 적용한 실제 사례이다. 시스템 환경은 아래와 같다:
- EMC Symmetrix 8730 어레이
- 284 x 83 GB 하드 디스크
- 24 GB 캐시
- RAID 1
- SAN
- HP-UX 11i (4 CPU, 8GB 메모리)
- Oracle DBMS
- Symmetrix 어레이에 9 GB LUN 구성

애플리케이션 프로그래머로부터 OLTP 트랜잭션의 응답시간이 저하되고 있음을 통보 받은 DBA는 Indepth GUI를 통해 문제에 대한 경고를 접수하고, 문제가 되는 트랜잭션과 SQL 구문을 즉시 확인한다.

Indepth data에 대한 드릴다운을 통해, DBA는 해당 SQL 구문이 스토리지 서브시스템에 요청한 I/O의 응답을 대기하는 데 대부분의 시간을 사용함을 확인한다.

문제가 I/O와 관련되어 있음을 확인한 DBA는 Indepth 데이터에 대한 분석을 통해 문제의 원인에 접근한다. 데이터베이스 인스턴스 레벨의 분석 과정에서, 인스턴스 전체가 I/O에 지나치게 많은 시간을 소모하고 있음을 확인한다.

인스턴스에 대한 데이터베이스 I/O 데이터의 드릴다운 과정에서 가장 많은 I/O 자원을 사용하는 상위 10개 파일이 표시된다. DBA는 10개의 파일 모두가 Symmetrix 어레이의 18개 LUN에 함께 위치하고 있음을 확인한다.
문제가 되는 파일에 대한 분석 과정에서, DBA는 해당 파일이 VERITAS Volume Manager에 의해 스트라이핑(striping) 형태로 구성되어 있음을 확인한다.

Volume Manager에 의해 구성된 6-way 스트라이프는, Symmetrix 어레이에 의해 다시 한 번 스트라이핑 처리된다. Symmetrix 어레이 내부의 모든 73GB 하드 디스크는 8개의 9GB 단위 논리적 볼륨으로 분할된다.
Symmetrix의 논리적 볼륨은 다시 3개의 논리적 볼륨으로 구성되는 메타 볼륨으로 합쳐지고 하나의 LUN으로서 호스트 서버(이 사례의 경우 VERITAS Volume Manager)에 제공된다. 결국 데이터베이스 시스템이 접근하는 파일은 6개의 Volume Manager LUN에 분산되고, 또 각각의 Volume Manager LUN은 3개의 Symmetrix 메타 볼륨에 분산되어 구성된다. 결국 파일은 18개의 LUN에 분산되어 위치한다.
LUN의 구성과, LUN이 포함된 메타 볼륨의 구성을 확인한 DBA는 해당 LUN 중 동일한 디스크에 포함된 것들이 있는지 알아본다. Indepth 데이터를 검토한 결과, DBA는 18개 LUN 중 상당수가 같은 물리적 디스크 상에 위치하고 있음을 확인했다.
파일은 18개 디스크가 아닌 9개 디스크를 사용하고 있었을 뿐만 아니라, Indepth를 이용한 추가 검토 과정에서 다른 서버에 설치된 두 번째 오라클 인스턴스가 사용하는 두 개의 논리적 볼륨이 동일한 물리적 디스크에 높은 수준의 I/O를 발생시키고 있었다. 결국 두 서버가 같은 디스크를 점유하여 I/O 경합을 발생시키는 것이 성능 저하의 원인이라는 결론이 내려졌다.
SQL 요청에서 디스크 오브젝트의 디스크 위치에 이르는 전체적인 상황을 제대로 파악한 DBA는 VERITAS Volume Manager와 VEA GUI를 이용하여 성능 최적화 작업을 시도한다. DBA는 VERITAS File System이 제공하는 QoSS(Quality of Storage Service) 기능을 이용하여, 온라인 상태에서 데이터베이스 오브젝트를 멀티-볼륨 파일 시스템 내의 다른 볼륨으로 이동한다.
이처럼 Indepth와 VEA GUI를 통해 제공되는 VERITAS Volume Manager 및 VERITAS File System의 기능을 이용하여, DBA는 성능 문제의 근본 원인을 신속하게 파악하고 해결할 수 있었다.

DBA 생산성 향상 및 비용절감
외부 애널리스트 기관의 조사 결과에 의하면, VERITAS 데이터베이스와 스토리지 성능관리 및 모니터링 솔루션은 DBA의 생산성을 극적으로 향상시키고, 비즈니스 트랜잭션의 비용을 절감하며, 응답시간을 최대 25% 수준으로 향상시킬 뿐 아니라, 하드웨어 업그레이드에 수반되는 비용을 상당 수준 절감시키는 것으로 분석되었다. (VERITAS Indepth for Oracle: Quantifying the ROI_ - Hurwitz Group) 또 같은 자료에서는 VERITA Indepth의 평균 투자회수 기간을 3개월로, 연간 ROI를 350%로 산정하고 있다.
VERITAS Indepth와 VERITAS Storage Foundation for Databases는 함께 조합되는 경우 완벽한 성능 모니터링 및 관리 솔루션으로서 구현된다. 데이터베이스 성능에 대한 수십 분의 일 초 단위의 샘플링, 전체 데이터 경로에 대한 정보 수집 기능을 통해, 관리자는 데이터를 요청하는 애플리케이션의 현황에 대한 엔드-투-엔드 가시성을 확보할 수 있다.
또 VERITAS Storage Foundation for Databases가 제공하는 고성능 인프라스트럭처를 활용하여 애플리케이션과 엔드 유저에 대한 영향을 최소화한 환경에서 문제를 해결할 수 있다.
성능 모니터링 및 관리를 위한 VERITAS의 솔루션 지향적 접근 방식은 데이터베이스, 애플리케이션, 네트웍, 스토리지 관리자가 효과적으로 협력하여 성능 관련 문제를 신속하게 확인하고 해결할 수 있는 환경을 제공한다.
인기기사 순위
(우)08503 서울특별시 금천구 가산디지털1로 181 (가산 W CENTER) 1713~1715호
TEL : 02-2039-6160  FAX : 02-2039-6163  사업자등록번호:106-86-40304
개인정보/청소년보호책임자:김선오  등록번호:서울 아 00418  등록일자:2007.08  발행인:김용석  편집인:김선오