특집 2 부 오라클데이터베이스 10g 릴리즈 2 편 김도근 롯데정보통신 IS 사업팀 DBA 로근무하고있으며올해아지아지역최초의 OTN ACE 로선정됐다. RDBMS 에있어서주된관심사는성능과튜닝, 데이터웨어하우징, 병렬처리쪽이다. 취미는오라클

Transcription

1 특집 2 부 오라클데이터베이스 10g 릴리즈 2 편 김도근 delri@ldcc.co.kr 롯데정보통신 IS 사업팀 DBA 로근무하고있으며올해아지아지역최초의 OTN ACE 로선정됐다. RDBMS 에있어서주된관심사는성능과튜닝, 데이터웨어하우징, 병렬처리쪽이다. 취미는오라클관련책수집과여행. 축구보기. 특히축구라면사족을못쓰는데요즘은프리미어리그에빠져있다고. 현재는 OCM 을준비중이다. 오라클은올 4월오라클데이터베이스 10g의 TPC-C 결과를발표하며 32개프로세스부분에서 1분에 160만트랜잭션을처리해세계신기록을기록했다고밝힌바있다. 이러한수치가우리에게의미하는바는무엇이며오라클 10g가다른 DBMS 제품과차별화되는점은무엇인지성능측면에서살펴본다. 성능항목별 DBMS 3종비교분석 database 많은 DBMS 업체들이자사제품성능의우수함을주장하기위해공신력있는기관의벤치마크결과를인용한다. 이때많이근거로제시되는것이바로가장객관적이라고알려진 TPC (Transaction Processing Performance Council) 이다. TPC는 TPC-C와 TPC-D라는기준을가지고지속적으로벤치마크결과를발표하는데, 전자는 TPC에의해기획된 OLTP(OnLine Transaction Processing, 실시간데이터처리 ) 벤치마크테스트로여기서세계신기록을수립했다는것은 32-프로세스등해당부분에서가장좋은성능을가진 DBMS임을의미한다. 마치수영이나육상등의시합에서 100m를얼마만에주파했는지시간기록이있듯이 TPC-C도처리속도에분당 (tpmc) 혹은비용 ($/tpmc) 대비 DBMS의기록인셈이다. < 표 1> 은각데이터볼륨사이즈별 TPC-H의결과치와시간당처리쿼리 (QphH) 순으로상위 3위를정리한것이다. TPC-H는의사결정벤치마크결과로, 복잡한질의를실행하고중대한비즈니스질문에대한답변을주는의사결정지원시스템을선택하는기준으로활용되곤한다. < 표 1> 에서볼수있듯이 100GB에서 QphH의수치는 MS SQL 서버 2005가가장뛰어난성능을보인다. 그러나 300GB 이상의데이터볼륨의경우오라클데이터베이스 10g의성능이가장뛰어난처리능력을보여주는것을알수있다. 즉오라클은중대형으로올라가면올라갈수록진가를발휘하는셈이다. 실제로시장에서는 MS SQL은중소형 DBMS, 오라클은대형 DBMS 라는인식이형성돼있다. 그렇다면왜오라클은중대형서버에서제성능을발휘하는것일까. 지금부터실제주요 DBMS와오라클을직접비교해보자. 기능비교는 DBMS의성능을결정하는핵심요인을중심으로이루어지며구체적으로는동시성모델과인덱싱, 파티셔닝, 병렬실행, 클러스터링등을살펴볼예정이다. 동시성모델 : 데이터베이스의 Locking 메커니즘을비교하기위한것으로, 얼마나많은사용자가동시에같은데이터읽기일관성을유지하는가가관건이다. 파티셔닝 : 대량의데이터를처리하는데있어서파티셔닝, 즉특정값을기준으로데이터를분할하는방법 병렬실행 : 멀티 CPU 환경에서 CPU 별로균등하게작업을분배해전체처리성능을높인다. 클러스터링 : 복수의노드를단일노드처럼처리하여성능과고가용성을높이는요인이된다. 오라클데이터베이스 10g vs. SQL 서버 2005 먼저오라클의가장최신버전인오라클데이터베이스 10g 릴리즈

2 성능항목별 DBMS 3 종비교분석 2와마이크로소프트 ( 이하 MS) 의 SQL 서버최신제품인 SQL 서버 2005의기술적인차이점을성능과확장성관점에서비교해보자. (undo) 레코드에기록이되기때문에트랜잭션이커밋되기전까지언두레코드에저장된이전버전의정보를사용자에게반환하고따 라서데이터의읽기일관성을보장한다. 동시성모델동시성모델 (Concurrency Model) 은멀티 -유저환경에서특정사용자에의해수행된데이터업데이트가다른사용자에게영향을미치는지여부를알수있는매우중요한지표다. 오라클데이터베이스 10g와 SQL 서버 2005는동시성모델의구현방법에서차이를보이는데주요차이점은 < 표 2> 와같다. 오라클데이터베이스에서구현되는멀티-버전읽기일관성 (multi-version read consistency) 은예를들면, 트랜잭션에의해업데이트가발생한경우기존데이터값은데이터베이스의언두 반면 SQL 서버 2005가기본적으로제공하는격리 (isolation) 모델은읽기작업에대해공유읽기잠금 (shared read lock) 을사용한다. 즉공유잠금이적용된경우현재읽기작업이수행되고있는데이터에대한업데이트가불가능하다. 이러한모델은읽기 / 쓰기작업이동시에발생하는환경에서동시요청을처리하는데성능상불리할수밖에없다. 또한애플리케이션이점유하는잠금의수가점차증가함에따라잠금에스컬레이션 (lock escalation, 잠금의확대, 예를들어 row 레벨락에서테이블락으로확대되는현상 ) 이발생해동시성이한층더제약되고데드락 ( 두세션이각각상대방에 < 표 1> 볼륨사이즈별 TPC 상위 3위 100GB 결과 기업 시스템 vqphh 가격 /QphH System 데이터베이스 운영체제 Date 클러스터 Availability Submitted hp HP ProLiant DL585 G1 4P 12, $ 11/07/05 MS SQL 서버 2005 MS 윈도우서버 /04/05 N 엔터프라이즈 x64 에디션 엔터프라이즈 x64 에디션 IBM IBM e서버 , $ 11/08/03 IBM DB2 UDB 8.1 수세리눅스엔터프라이즈서버 8 07/29/03 Y 썬 SunFire V890 10, $ 08/15/05 썬사이베이스 IQ 12.6 싱글 썬솔라리스 GB 결과 기업 시스템 vqphh 가격 /QphH System 데이터베이스 운영체제 Date 클러스터 Availability Submitted hp HP BladeSystem ProLiant 18, $ 11/11/05 오라클 10g 엔터프라이즈 레드햇엔터프라이즈 11/11/05 Y BL25p Cluster 8P DC 에디션 R2 w/ Partitioning 리눅스 4 ES hp HP BladeSystem ProLiant 13, $ 10/31/05 오라클데이터베이스 10g 레드햇엔터프라이즈 09/16/05 Y BL25p Cluster 8P 릴리즈 2 엔터프라이즈에디션 리눅스 4 ES IBM IBM e서버 , $ 11/08/03 IBM DB2 UDB 8.1 수세리눅스 07/29/03 07/29/03 Y 엔터프라이즈서버 GB 결과 기업 시스템 vqphh 가격 /QphH System 데이터베이스 운영체제 Date 클러스터 Availability Submitted hp HP Integrity Superdome 68, $ 01/18/06 오라클데이터베이스 HP UX 11.i V2 64비트 08/08/05 N 엔터프라이즈서버 10g R2 엔터프라이즈 에디션 w/partitioning IBM IBM e서버 xseries , $ 02/14/05 IBM DB2 UDB 8.2 수세리눅스엔터프라이즈서버 9 02/14/05 Y hp HP ProLiant DL585 35, $ 10/21/04 오라클 10g RAC 레드햇엔터프라이즈 10/22/04 Y Cluster 48P with Partitioning Linux AS GB 결과 기업 시스템 vqphh 가격 /QphH System 데이터베이스 운영체제 Date 클러스터 Availability Submitted 썬 Sun Fire E25K server 108, $ 01/23/06 오라클 10g 엔터프라이즈 썬솔라리스 10 11/29/05 N 에디션 R2 w/ Partitioning IBM IBM e서버 p , $ 08/15/05 IBM DB2 UDB 8.2 IBM AIX 5L V5.3 05/20/05 Y hp HP Integrity Superdome 86, $ 04/06/05 오라클데이터베이스 10g HP UX 11.i V2 64비트 10/07/04 Y 엔터프라이즈서버 엔터프라이즈에디션 출처 TPC, 마이크로소프트웨어 155

3 특집 2 부 오라클데이터베이스 10g 릴리즈 2 편 대해서 lock을잡고있는상태 ) 으로연결될가능성도있다. 이러한문제때문에 MS SQL 서버 2005에서는이러한문제에대응하기위해구문레벨읽기일관성 (read committed with snapshots), 트랜젝션레벨읽기일관성 (snapshot isolation) 등두가지격리수준을추가했다. 이두가지격리수준은각각오라클에서예전부터지원해온 < 표 2> 오라클 10g와 MS SQL 서버 2005의동시성모델비교 오라클데이터베이스 10g SQL 서버 2005 멀티버전읽기일관성 항상가능 디폴트아님. (Multi-version read Consistency) 기능의사용을위해활성화해야함 로우레벨잠금의에스컬레이션잠금 지원 지원안됨 (Non-escalating row-level locking) (Locks escalate) < 표 3> 인덱스유형비교 인덱스유형 오라클데이터베이스 10g SQL 서버 2005 B-트리인덱스 지원 지원 B-트리클러스터인덱스 지원 지원하지않음 해시클러스터인덱스 지원 지원하지않음 리버스키인덱스 지원 지원하지않음 비트맵인덱스 지원 지원하지않음 비트맵조인인덱스 지원 지원하지않음 기능기반인덱스 지원 지원하지않음. 계산된컬럼 (computed column) 에대해서도인덱스를생성할수있지만해당컬럼이테이블내에실제로존재하고있어야함. 도메인인덱스 지원 지원하지않음 IOT 지원 지원 (clustered index) READ COMMITTED와 SERIALIZABLE 격리수준에대응된다. 이두가지격리수준에서는특정읽기작업이동일한데이터에접근하는다른읽기 / 쓰기작업을블로킹하지않으며쓰기작업역시읽기작업을블로킹하지않는것이특징이다. 먼저트랜젝션레벨읽기일관성은로우버저닝 (row versioning) 을기반으로하고있다. 이는커밋된데이터로우를포함하고있는여러버전들의링크드체인 (linked chain), 즉원래의데이터위치를추적함으로써읽기일관성을보장하는방법이다. 링크드체인은 tempdb라는임시스토어드프로시저 (temp stored procedure) 와기타임시작업을위한데이터베이스저장공간에위치한별도의버전저장소 (version store) 에저장된다. 이러한 SQL 서버 2005의트랜젝션레벨읽기일관성은혁신적인기술로보기힘들다. SQL 서버 2000에서는지원되지않았기때문에이전버전보다개선된것은사실이나오라클은이미오래전부터멀티 -버전읽기일관성을기본으로지원해왔기때문이다. 이외에도 SQL 서버 2005는동시성모델에있어서다음과같은한계들을갖는다. 관리자는데이터베이스레벨에서명시적으로설정한경우에만 read-com mitted with snapshot 또는 snaption isolation이활성화된다 ( 기본적으로는성능상의이유때문에 disable 되어있다 ). 기존에운영중이던 SQL 서버애플리케이션의경우이모드를구현하려면 SQL 서버애플리케이션을오라클환경으로이전하는것과동등한수준의수정작업이요구된다. 왜냐하면 SQL 서버 2000에서는이러한기능이지원되지않았기때문이다. 읽기잠금을이용하는애플리케이션에멀티-버전읽기일관성을적용하기위해서는일정수준의재설계와재개발작업이불가피하다. < 그림 1> 비트맵조인인덱스 sales SELECT FROM WHERE AND customers SUM(s. cost) sales s, customers c s.cust_id = c.cust_id c.region = East ; CREATE BITMAP INDEX cust_sales_bji ON sales (c.region) FROM sales s, customers c WHERE c.cust_id = s.cust_id; <East, , , > <Central, , , > <West, , , > 이쿼리를수행하는경우오직인덱스와 sales 테이블만을읽으면된다. 인덱싱인덱스가데이터에대한신속한접근을제공하기위해생성되는중요한기능중에하나라는것은데이터베이스를사용하는사람들에게는상식적인이야기다. 인덱스를이용하면디스크 I/O 작업을크게줄이고데이터인출성능을개선할수있으며성능향상을기대할수있다. 그렇다면오라클데이터베이스 10g와 MS SQL 서버 2005의인덱싱은어떠한차이가있을까. < 표 3> 은두제품이지원하는인덱싱메커니즘의차이를요약한것이다. 오라클과 SQL 서버 2005는모두고전적인 B-트리인덱스구조를지원한다. B-트리인덱스는순차적으로정렬된키값을, 실제값이저

4 성능항목별 DBMS 3 종비교분석 database 장된테이블로우의저장위치와연계한형태로구성된다. B-트리인덱스는별도의인덱스영역에키값을기준으로정렬되어있고이인덱스영역은실제데이터의위치정보 (RowID) 를가지고있다. 또한두제품모두 IOT(Index-Organized Table) 을지원한다 (MS는 clustered index라는용어를사용한다 ). IOT는테이블로우를프라이머리키인덱스의리프노드에저장하고있기때문에프라이머리키를기준으로한조건및영역검색에서뛰어난성능을보여준다. IOT의대표적인성격은모든테이블의데이터를인덱스처럼저장하는것이다. 즉인덱스입력항목의두번째요소로행의 RowID를가지지않고실제데이터행이 B-트리인덱스에저장된다. 게다가오라클은스태틱비트맵인덱스 (static bitmap index) 와비트맵조인인덱스 (bitmap join index) 를추가로지원한다. 이두가지인덱스는데이터웨어하우징환경의로드 / 쿼리작업에서좋은성능효과를보여준다. 비트맵인덱스는 RowID와값에대해 BIT 값으로저장을함으로써나이, 성별, 지역처럼전체레코드건수에비해카디널리티 ( 선택도 ) 가낮은속성들과 OR, AND 연산시에효과적으로사용할수있는인덱스구조이다. 또한오라클 9i부터지원되는비트맵조인인덱스는두개이상의테이블에조인인덱스를생성함으로써질의처리를위한조인에서오는부하를피하고그만큼성능향상을가져올수있다. 비트맵인덱스는테이블로우의저장위치목록대신각키값에대한비트맵 ( 또는비트벡터 ) 을사용한다. 비트맵의각비트는테이블의로우에대응한다. 테이블의로우가키값을포함하고있는경우에해당비트가설정된다. 로우의저장위치를저장하는방식과비교했을때비트맵표현방식은매우많은비용절감효과를제공한다. B-트리인덱스는실제로조건이비교되는컬럼값에대한테이블의원시값과 Row의물리적인주소인 RowID를인덱스블럭에도저장하므로데이터의중복저장에따른공간낭비가발생한다. 반면비트맵인덱스는저장공간에인덱스컬럼값이아닌 1과 0의비트값이저장되고, 스캔에의한데이터추출이아닌비트연산에의한데이터추출을하기때문에성능을높일수있다. 특히선택도 (cardinality) 가낮은데이터가사용되는경우효과적이다. 비트맵인덱스는 AND, OR 등고속의불리언 (Boolean) 연산을통해서로다른인덱스의비트맵을조합하는형태로도활용된다. 여러개의조건에대한연산을수행하기위해각조건에대응되는인덱스들을 WHERE절내에서효과적으로조합한다. WHERE절내의모든조건을만족하지않는로우는테이블에대한액세스가수행되기전에필터링되며상황에따라극적인성능개선도기대할수있다. 오라클데이터베이스에서는 IOT에대한비트맵인덱스를생성하 고, IOT를데이터웨어하우징환경을위한팩트테이블 (fact table, 다차원모델에서중심이되는테이블 ) 로활용하는것이가능하다. 비트맵조인인덱스는두개이상의테이블을조인 (join) 하기위해사용되는비트맵인덱스이다. 이를이용하면실제테이블을조인할필요가없으며제약조건을미리실행함으로써실제로조인되는데이터의양을크게줄일수있다. 또한비트단위연산을통해 Bit map join index를이용하는쿼리의실행속도도개선할수있다. < 그림 1> 은비트맵조인인덱스의대표적인사례다. 조건절을통해 Customer 테이블과 Sales 테이블사이의조인을미리계산하는 (precomputation) 역할을하게되므로두개의테이블질의시비트맵조인인덱스를통하게되면하나의테이블에만접근하면된다. 게다가비트맵조인인덱스는다수의디멘션테이블을포함하고있으므로비트단위연산이필요치않다 ( 실제로단일테이블에비트맵인덱스의형태로스타스키마를적용한경우에는비트단위연산이반드시필요하다 ). 다양한형태의스타스키마 (Star Schema, 데이터웨어하우징에서복잡한정보를모델링하는표준형기술로, 중심이되는 Fact 테이블을중심으로디멘전 (dimension) 테이블이붙어있는형태이다 ) 에대한쿼리테스트를수행해보면비트맵조인인덱스를사용한쿼리가실제성능개선효과를제공한다는사실을확인할수있다. 파티셔닝파티셔닝 (Partitioning) 은테이블, 인덱스등대규모데이터베이스구조를더작고관리하기쉬운단위로분해하는기능이다. 주로관리성과가용성을개선하기위해활용되지만성능측면에서도몇가 < 그림 2> 스타스키마모델 Product (Dimension Table) Geography (Dimension Table) Sales (Fact Table) Customer (Dimension Table) Supplier (Dimension Table) Time (Dimension Table) 마이크로소프트웨어 157

5 특집 2 부 오라클데이터베이스 10g 릴리즈 2 편 지혜택을제공한다. 파티셔닝은애플리케이션시나리오별로다양한파티셔닝테크닉을고려할수있다. 예를들어레인지파티셔닝 (Range Partition ing) 은일정영역의컬럼값을이용해로우를파티션에맵핑한다. 이옵션은히스토리 (history) 데이터베이스즉이력데이터에특히유용하게활용되며데이터웨어하우스환경의롤링윈도우 (rolling window, 주기적으로새로운데이터가추가되면서오래된데이터는데이터웨어하우스에서삭제되는것 ) 지원을위한이상적인파티셔닝방법으로이용되기도한다. 해시파티셔닝 (Hash Partitioning) 은파티션된컬럼에해시함수를적용해서데이터를분산시키는방법으로균일하게분포된데이터에효과적이다. 즉이력데이터의범위분할적용에서나타나는단점인, 각범위 (Bound) 가포함하는데이터의양이일정하지않아분포도가일정하지않고각파티션의크기가다르게나타나는점을개선한다. 이를통해일정한분포를가진파티션으로나누고균등한데이터분포도를이용한병렬처리로성능을높인다. 리스트파티셔닝 (List Partitioning) 은로우를파티션으로맵핑하는방법을관리자가명시적으로설정할수있다. 관리자는파티셔닝컬럼을위한값의리스트를정의하는방법으로맵핑방법을설정한다. 컴포짓파티셔닝 (Composite partitioning) 은사용자가다양한파티셔닝테크닉을조합할수있도록지원한다. 첫번째방법을이용해서테이블을먼저파티셔닝한후두번째방법을통해각파티션을다시서브파티션으로분할하는것이다. 이때인덱스는크게 3가지종류로구분할수있다. 로컬인덱스 (Local Index) : 하부파티션테이블과동일한파티션방법을사용하여파티셔닝된테이블에생성된인덱스이다. 로컬인덱스의각파티션은하부테이블의특정파티션에맵핑된다. 글로벌파티션드인덱스 (Global Partitioned Index) : 테이블의서로다른파티셔닝-키를이용해파티션된테이블이나파티셔닝되지않은테이블에생성된인덱스를가리킨다. 파티셔닝되지않은테이블의인덱스와동일한형태로구성되며이때인덱스구조는파티셔닝되지않는다. < 표 4> 는오라클과 SQL 서버의파티셔닝옵션을비교한것이다. 오라클이지원하는다양한파티셔닝옵션을확인할수있으며실제기능에있어서도 < 표 5> 처럼차이가있음을알수있다. 병렬실행과클러스터링 SQL 작업은병렬실행을통해대량의데이터가수반되는작업의성능을크게개선할수있다. 특히의사결정시스템또는데이터웨어하우스등의대규모데이터베이스에서데이터집중적인작업을 수행할때응답시간개선에도움이된다. 예를들어오라클사용자가 SQL문에대한병렬처리를수행하고자한다면오라클서버는사용자의요청에따라가용가능한 CPU 개수만큼병렬처리를수행한다. 4개의 CPU를가진서버에서의병렬처리를수행한다면 3 개의 CPU에서실 SQL문에대해균등하게작업을할당하여처리하고나머지 1개의 CPU에서이를병합하는작업을수행한다. 오라클데이터베이스는파티셔닝된데이터베이스오브젝트또는파티셔닝되지않은데이터베이스오브젝트에액세스하는과정에서 INSERT, UPDATE, DELETE, MERGE 등의구문을병렬적으로실행한다. 반면 SQL 서버 2005의 INSERT, UPDATE, DELETE 구문은순차적으로실행된다. 클러스터는사설네트워크를통해연결된다수의독립적인서버또는노드들이마치하나의시스템인것처럼협력하여동작하는환경을의미한다. 단일노드시스템이갖는확장성의한계를극복하고대형서버의성능을뛰어넘는부하처리를가능케한다. 오라클 RAC(Real Application Cluster) 이바로이런역할을지원하는솔루션으로 DBMS에대한요구사항이증가함에따라단순히노드를추가함으로써확장할수있는것이특징이다. SQL 서버 2000은제품문서에명시된것처럼이러한형태의클러스터링을지원하지않는다. 이것은 SQL 서버 2005에서도마찬가지인데대신 Federated Database Server 라는새로운방식을지원한다. 두접근법은매우큰차이를갖고있어애플리케이션의성능과확장성에큰영향을미칠수있다. Federated Database Server는독립적인데이터베이스들로구성되며공통데이터딕셔너리와글로벌인덱스를지원하지않는다. 이때문에성능과확장성면에서많은제약이따른다. 또한 SQL 서버 2005의접근법은실제애플리케이션환경에서적용이매우힘들다. 실제로 SAP, 피플소프트등의비즈니스애플리케이션은일반적으로수천개의테이블로구성되는데 SQL 서버 2005의 Feder ated Database Server를구현하려면모든테이블을파티셔닝하거 < 표 4> 오라클과 SQL 서버의파티셔닝옵션비교 파티셔닝옵션 오라클데이터베이스 10g 릴리즈 2 SQL 서버 2005 Range 지원 지원 Hash 지원 지원하지않음 List 지원 지원 Composite 지원 (Range-hashRange-list) 지원하지않음 Local Index 지원 지원 Global Index 지원 지원 < 표 5> 오라클 SQL 서버의최대파티션수 오라클데이터베이스 10g 릴리즈 2 SQL 서버 2005 테이블당최대파티션수 1024K(100만개이상 )

6 성능항목별 DBMS 3 종비교분석 database 나각노드로복제해야한다. 이처럼거대한애플리케이션을포팅하는것은복잡할뿐만아니라많은비용을필요로한다. 반면오라클 RAC는상대적으로포괄적인애플리케이션호환성을제공한다. 대표적인기업용애플리케이션들을효과적으로확장할수있으며클러스터링환경을위한커스터마이즈작업도필요치않다. 즉데이터액세스패턴이데이터블럭핑을감소또는어렵게하더라도애플리케이션을분할할필요가없다. 단일노드의오라클서버에서확장성있는애플리케이션은멀티노드의 RAC 상에서도확장성이있다. 이때문에기존애플리케이션을재설계하거나코드를수정할필요가없으며애플리케이션을명시적으로분할하거나데이터를파티셔닝할필요도없다. 또한 SQL 서버는파티션을실제로소유한노드만이해당파티션에대한읽기작업을수행할수있다. 프로세싱파워는테이블이포함된노드의프로세싱파워로한정된다. 그러나오라클데이터베이스에서는이러한제약이존재하지않으며심지어전체시스템의프로세싱파워, 다시말해모든병렬실행서버의리소스를이용해하나의파티션에대한처리작업을수행하는것도가능하다. 오라클데이터베이스 10g vs. IBM DB2 UDB 지금까지최근에새로운버전을발표한 MS SQL 서버 2005와오라클데이터베이스 10g에대해서비교해보았다. 이번엔오라클과 IBM의 DB2를역시성능관점에서비교해보자. 두제품을본격적으로비교하기에앞서여기서사용되는 DB2, DB2 UDB 등의용어는모두 DB2 UDB ESE( 엔터프라이즈서버에디션 ) Version 8.2를가리킨다. 또한오라클, 오라클데이터베이스, 오라클데이터베이스 10g는모두오라클데이터베이스의최신버전인오라클데이터베이스 10g 엔터프라이즈에디션릴리즈 2를의미한다. 동시성모델비교항목은역시앞서진행했던것과동일하다. 먼저동시성모델을보면오라클데이터베이스와 IBM DB2는동시성컨트롤의구현방식에서 < 표 6> 과같은차이를보인다. 오라클의경우쿼리와업데이트가동시에발생하는혼합형워크로드환경을지원하며쓰기작업이읽기작업을차단하거나읽기작업이쓰기작업을차단하는상황이발생하지않는다. 반면 DB2는사용자가정확성 (accu racy) 과동시성 (concurrency) 의두가지중하나를양자택일할수밖에없다. 즉읽기일관성을보장하기위해쓰기작업을블로킹하거나쓰기작업을차단하지않는대신더티리드 (dirty read) 로인한부정확한결과를감수해야한다. 여기서더티리더란언커밋리더라고도한다. 사용자가변경시키고있는 commit되지않은데이터를다른사용자가읽는현상을말한다. 예를들어서 A라는사용 자가공유되어있는문서파일을저장하지않고작성중에 B 사용자가이를열어서보는현상을들수있다. 오라클의기본적인아키텍처는대용량트랜잭션을고려해설계돼있다. 이는오라클이특허를보유한논-에스컬레이팅로우-레벨락킹 (non-escalating row-level locking) 기능 (row에대한잠금을가지는 lock이이잠금의개수를줄이기위해서상위테이블 lock 등으로확대시키지않는현상 ) 지원이있기에가능한것인데, 애플리케이션에연결되는사용자의수가늘어나고처리해야하는트랜잭션의양이증가해도오라클데이터베이스가일관된성능을유지할수있는것도이때문이다. Winter Corporation의조사결과전세계적으로가장규모가큰상위 10개유닉스데이터베이스가모두오라클기반으로운영되고있는것역시효율적인동시성모델에기인한바가크다. DB2의경우락정보의추적을위해사용되는메모리구조의용량이제한되어있기때문에트랜잭션규모가증가할경우리소스사용량을줄이기위한방편으로로우락 (row lock) 을테이블락 (table lock) 으로에스컬레이션한다. 따라서불필요한경합이발생하고처리성능의저하가일어날수있다. 오라클과 DB2 데이터베이스의구현방식은멀티유저환경에서일반적으로발생하는다음과같은문제들을방지하는메커니즘에서도큰차이를보인다. 참고로여기서 non-repeatable read는해당트랜잭션중바로전에읽은데이터가다시읽고난후변경된상태로, 첫읽기후해당데이터가다른트랜잭션에의해커밋된상태를의미한다. 또한 Phantom Read는해당트랜잭션중조건을만족하는튜플들을리턴하는쿼리를재실행한후변경된튜플들이리턴될때를가리킨다. 트랜잭션이커밋되지않은변경사항을읽는시점에더티리드 (dirty read) 또는언커밋트리드 (uncommited read) 가발생한다. 트랜잭션이방금전에읽어들인데이터를다시읽는과정에서해당데이터 < 표 6> 오라클과 DB2의동시성모델기능차이 오라클데이터베이스 10g DB2 UDB 멀티-버전읽기일관성 지원되지않음 (multi-version read consistency) 리드락이사용되지않음 더티리드를방지하려면리드락이필요 더티리드를사용하지않음 리드락을사용하지않는경우더티리드 발생 로우-레벨락 (low-level locking) 이 락의에스컬레이션발생 에스컬레이션되지않음 읽기작업은쓰기작업을블로킹하지않음 읽기작업이쓰기작업을블로킹 쓰기작업은읽기작업을블로킹하지않음 쓰기작업이읽기작업을블로킹 높은부하에서데드락이전혀발생하지않음 높은부하에서데드락으로인한심각한 문제가발생할수있음 마이크로소프트웨어 159

7 특집 2 부 오라클데이터베이스 10g 릴리즈 2 편 가다른커밋된트랜잭션에의해수정되거나삭제됐음을확인했을때 nonrepeatable read가발생한다. 트랜잭션이검색조건을만족하는일련의로우를반환하는쿼리를 2차례반복실행하고다른애플리케이션에의한 INSERT 작업으로인해두번째쿼리에서 ( 첫번째쿼리에서는반환되지않은 ) 추가적인로우가반환되었을때 phantom read가발생한다. 오라클은트랜잭션에업데이트가발생할경우기존데이터는데이터베이스의언두레코드에저장된다. 데이터베이스가읽기작업을수행하는동안데이터변경을방지하기위해또는쿼리가커밋되지않은변경데이터를읽는것을방지하기위해오라클은락을사용하는대신언두레코드에저장된기존정보를이용하여테이블데이터에대한읽기일관성을확보한다. 반면 DB2는멀티 -버전읽기일관성을제공하지않는다. 대신다양한레벨의격리모델을통해읽기잠금 (read lock) 을사용하거나더티리드를허용하는방법을사용한다. 읽기잠금은동시수행중인트랜잭션에의해변경중인데이터를읽을수없도록차단하기때문에다수의읽기 / 쓰기작업이동시에발생하는환경에서서비스동시요청을처리하는능력이제한될수밖에없다. 오라클이지원하는로우-레벨락은정교한수준의락관리방식으로높은데이터동시성을제공한다. 로우-레벨락은테이블의특정로우에대한업데이트과정에서해당로우만을잠금처리하며다른모든로우는동시작업이가능하다. 오라클은디폴트동시성모델로로우-레벨락을사용하며락정보를실제로우내부에저장하고이를통해데이터베이스의로우또는인덱스엔트리숫자만큼로우-레벨락을관리할수있게해데이터동시성을높였다. DB2 역시로우-레벨락을디폴트동시성모델로지원한다. 그러나 DB2의이전버전에서는로우-레벨락이기본잠금모드가아니었고후에로우-레벨락을추가적으로지원하는과정에서 락리스트 (lock list) 라는별도의메모리구조가필요하게됐다. 이메모리는제한된용량을가지고있으며이때문에데이터베이스에서지원할수있는최대락의숫자또한제약된다. 이때문에애플리케이션과트랜잭션볼륨에접근하는사용자의수가증가하면 DB2는메모리절약을위해로우-레벨락을테이블락 (table lock) 으로에스컬 < 표 7> 오라클과 DB2의인덱싱기능비교기능오라클 DB2 Stored Compressed Bitmap Indexes 지원 - 비트맵조인인덱스지원 - 다이나믹비트맵인덱스지원지원 IOT 지원 - 리버스키인덱스지원 - 기능기반인덱스지원부분적으로지원 레이션한다. 이는결국데이터에동시접근할수있는사용자의수가줄어들게됨을의미하는데그만큼대기시간이길어질가능성이있다. 실제로 DB2 매거진의한기사 ( archives/1999/q2/99sp_yevich.shtml) 는 락에스컬레이션은 ERP 환경에서가장심각한성능저하요인의하나로꼽힌다 고지적하고락에스컬레이션을비활성화할것을권고한바있다 ( 그러나이러한작업은 OS/390 플랫폼의 DB2에서만가능하며유닉스와윈도우기반 DB2에서는비활성화가불가능하다 ). 인덱싱오라클과 DB2는모두고전적인 B-트리인덱싱메커니즘을지원한다. 이미살펴본것처럼오라클은이밖에도스태틱비트맵인덱스와비트맵조인인덱스를지원할뿐만아니라여러개의파티션에대한글로벌인덱스를지원해 OLTP 환경의파티셔닝된테이블에서유용하다. 반면 DB2는 B- 트리인덱스와다이내믹비트맵인덱스만을지원한다. 두제품의인덱싱기능차이는 < 표 7> 과같다. 오라클의경우인덱스는대상테이블의하나또는그이상의컬럼에대한함수로생성될수있다. 함수기반인덱스 (functionbased index) 는함수또는표현식의결과를미리계산해인덱스에저장하며 B-트리인덱스또는비트맵인덱스로생성할수있다. DB2의 generated column 기능의경우표현식을기반으로생성된컬럼의값을유도한결과가인덱스에저장된다. 그러나유도된값을테이블형태로저장한다는점에서오라클의함수기반인덱스만큼효율적이지못하다. IOT는테이블로우를프라이머리키인덱스에저장하며프라이머리키에대한조건과영역검색을수반하는쿼리에서높은성능을나타낸다. IOT를이용하는경우중요컬럼이테이블과프라이머리키인덱스에이중으로저장되지않으므로공간을절약할수있고일반적인테이블에서로우의주소를저장하고인덱스값과로우데이터에대한링크를제공하는용도로사용되는 RowID를위해추가적인공간을할당할필요도없다. IOT는기본키인덱스구조로모든데이터를저장하므로기본키인덱스스캔만으로모든작업을종료할수있다. 일반테이블은기본키를사용하여인덱스스캔하여해당테이블로랜덤액세스를수행하므로 IOT보다성능저하가발생할수있다. 따라서빠른조회를요구하는 OLTP 업무에서 IOT는클러스터테이블과더불어그성능을발휘한다. IOT는 RowID pseudo-column, LOB, 2차인덱스, range/hash 파티셔닝, 오브젝트지원, 병렬쿼리등일반적인테이블에서지원되는모든기능을지원한다. IOT에비트맵인덱스를생성하고데이터웨어하우징환경의팩트테이블로활용하는것도가능한데이러

8 성능항목별 DBMS 3 종비교분석 database 한기능은오라클데이터베이스 10g 에서만제공되는기능이다. works/db2/library/techarticle/dm-0405wilkins/ index.html). 파티셔닝이미살펴본것처럼파티셔닝은대규모데이터베이스를관리하기쉬운단위로분할하기위해사용되며파티션프루닝 (partition pruning) 이라불리는테크닉을활용하는경우성능의개선을기대할수있다. 파티션프루닝은필요한데이터가존재하는파티션에대해서만작업이실행되도록제한하는기능을말한다. 작업과정에서필요한데이터를포함하지않은파티션들은검색과정에서제외된다. 이를통해디스크로부터인출되는데이터의양과프로세싱시간을크게줄이고쿼리성능과리소스사용률을개선할수있다. 파티셔닝환경에서 partition-wise join 테크닉을사용해멀티-테이블조인작업의성능을개선할수도있다. 이것은두개의테이블이함께조인되고조인키 (join key) 를기준으로두테이블이파티셔닝된경우에적용되는데대규모조인작업을각파티션별로작은크기의조인작업으로분할하고전체조인작업에소요되는시간을단축하는효과가나타난다. 따라서순차 / 병렬작업환경에서성능개선효과를기대할수있다. 마지막으로파티셔닝환경에서 DML 작업의병렬실행기능을활성화함으로써데이터집중적인작업이수반되는대규모의사결정시스템이나데이터웨어하우스환경의응답시간을단축할수있다. 이미오라클에서제공하는파티셔닝은살펴보았으므로여기서는 DB2 UDB의파티셔닝을중점적으로살펴보자. < 표 8> 은두제품의파티셔닝옵션을비교한것이다. DB2는해시파티셔닝만을지원 (ftp.software.ibm.com/ps/products/db2/info/vr8/pdf/letter/ db2s2e80.pdf) 하기때문에오라클과차이가있음을알수있다. 레인지파티셔닝또는리스트파티셔닝과달리해시파티셔닝은일부쿼리에대해파티션프루닝을지원하지않는다. 따라서데이터웨어하우스를최신상태로유지하려면새로운데이터를로드하고오래된데이터를삭제하는작업을지속적으로반복해야하는번거로움이있다. 해시파티셔닝이적용된 DB2 환경에서는전체파티션에대한재분배작업이불가피하며결과적으로새로운데이터를로드하는데더많은시간이소요되고데이터재분배과정의테이블잠금으로인해가용성이저하될가능성이있다. 또한 DB2는테이블과인덱스간의 equi-partitioning ( 인덱스가같은칼럼에대해같은값으로파티션되어있는것 ) 을요구하며따라서글로벌인덱스의생성이불가능하다. 이러한제약은개별레코드에대한효율적인액세스를위해글로벌인덱스를빈번하게활용해야하는 OLTP 환경에서심각한문제를야기할가능성이있다. 이처럼 DB2 기반의애플리케이션설계과정에서는파티셔닝환경의유연한인덱스구성이어렵다 (www-128.ibm.com/ developer 클러스터 RAC은오라클데이터베이스 10g에포함된하드웨어클러스터지원옵션이다. 이는공유디스크 (shared disk) 방식을채택하고있는데공유디스크아키텍처에서데이터베이스파일은다수의노드에의해논리적으로공유되며각시스템의인스턴스는모든데이터에대한접근이허용된다. RAC 역시오라클이특허를보유한캐시퓨전 (Cache Fusion) 아키텍처를기반으로하고있다. 캐시퓨전은상호연결된캐시를이용해 OLTP, DSS, 패키지애플리케이션등다양한애플리케이션에대한데이터베이스클러스터기능을지원한다. 사용자의쿼리는로컬캐시또는다른노드의원격캐시를통해서도처리할수있으며업데이트작업과정에서로컬노드는다른클러스터노드의데이터베이스캐시로부터필요한블럭을직접가져오므로동기화를위한별도의읽기 / 쓰기작업을수행할필요가없는점도특징이다. 반면 DB2는 Shared-Nothing 접근방식을사용한다. 이아키텍처에서는데이터베이스파일이파티셔닝을통해클러스터를구성하는각노드의인스턴스에분산된형태로존재한다. 각인스턴스또는노드는일정범위의데이터만을보유하며해당데이터를배타적으로점유하고있다. 즉 Shared-Nothing 시스템은파티셔닝을통해워크로드를다수의노드에분산하는효과를제공하며이것은노드의데이터소유권이자주변경되지않는경우에효과적이다 ( 단데이터베이스재편성, 노드장애시데이터소유권이변경될수있다 ). 표면적으로는 Shared-Nothing 시스템이분산형데이터베이스와유사하게보인다. 그러나 Shared-Nothing 데이터베이스는하나의데이터딕셔너리를가진하나의물리적데이터베이스라는점에서분산형데이터베이스와는근본적인차이가있다. 이미살펴본것처럼오라클데이터베이스 10g RAC은패키지애플리케이션을별도의수정과정없이단일시스템에서클러스터구성으로마이그레이션할수있다. 반면 DB2 데이터베이스를 DB2 UDB EEE로마이그레이션하려면데이터파티셔닝작업과추가적인개발작업이불가피하다. < 표 9> 는두제품의아키텍처가갖는 < 표 8> 파티셔닝옵션비교기능오라클 DB2 레인지파티셔닝지원 - 리스트파티셔닝지원 - 해시파티셔닝지원지원컴포짓파티셔닝지원 - 로컬인덱스지원지원글로벌파티션드인덱스지원 - 그로벌넌파티션드인덱스지원 - 마이크로소프트웨어 161

9 특집 2 부 오라클데이터베이스 10g 릴리즈 2 편 [ 오라클데이터베이스 10g 최신성능관리팁 ] 성능향상의열쇠는테이블스캔방법 10g Segment Shrink 기능을이용한 HWM 낮추기오라클데이터베이스에서모든세그먼트는세그먼트내에데이터를포함하거나데이터를쓴적이있는상위경계선인 HWM(High Water Mark) 을가진다. HWM은일반적으로 Full Table Scan( 전체테이블검색 ) 시에 HWM까지읽음으로써빈번한삭제가일어나서실데이터에대한영역이소수존재하는테이블에대한테이블스캔시필요이상의블럭을스캔하게된다. 기존버전에서는이 HWM을낮추기위해 TRUNCATE나 DROP 후 CREATE와같은테이블을재구성해야했지만 10g 버전부터 SEGMENT SHRINK 기능을이용해테이블을재구성하지않고운영중에동적으로 HWM을낮추는것이가능해졌다. 적용되는 Object는 Normal Table, Index, lob, IOT, Mview 등이다. 먼저다음과같이테이블을생성해보자. 해당테이블이생성되는테이블스페이스는 AUTO Segment Space Managed 테이블스페이스여야한다. CREATE TABLE SHRINK_TEST AS SELECT * FROM ALL_OBJECTS; 이제 Analyzing 후에해당블럭의상태를확인한다. ANALYZE TABLE SHRINK_TEST COMPUTE STATISTICS; SELECT blocks, empty_blocks, num_rows FROM user_tables WHERE table_name = SHRINK_TEST ; BLOCKS과 EMPTY_BLOCKS의수치가그대로인것을확인할수있다. DELETE를함으로써 HWM의위치를낮추지는않는다. 그러므로 HWM 이후에존재하는 EMPTY_BLOCKS의개수또한변함이없다. 여기에 Segment Shrink 기능을적용해보자. 먼저다음과같이테이블의 row movement 기능을활성화시킨다. SQL>ALTER TABLE SHRINK_TEST ENABLE ROW MOVEMENT; 이제테이블과 HWM을 shrink시킨다. SQL> ALTER TABLE SHRINK_TEST SHRINK SPACE; 이처럼 SQL>ALTER TABLE 테이블명 SHRINK SPACE <[OPTION], <COMPACT, CASCADE>; 형태를띠는데여기서각옵션은다음과같다. COMPACT : 테이블을 SHRINK시키고 HWM는그대로둔다 CASCADE : 테이블및관련된인덱스를모두 shrink시킨다. MView 형태의테이블을 shrink시키려면 SQL> ALTER TABLE <table name> SHRINK SPACE; 와같이사용하고인덱스만 shrink시킬때는 SQL> ALTER INDEX <index name> SHRINK SPACE; 처럼사용한다. 이제 SHRINK SPACE 명령으로해당테이블을재구성한뒤 Analyzing 후결과를확인해보자. BLOCKS EMPTY_BLOCKS NUM_ROWS 여기서블럭의개수는세그먼트에의해사용된적이있는블럭의수, 즉 HWM의수치를나타낸다. 또한 EMPTY_BLOCKS 수는 HWM 위의블럭을의미한다. Delete시킨다음 Analyzing 후다음과같이해당자료사전을조회해보자. ANALYZE TABLE SHRINK_TEST COMPUTE STATISTICS; SELECT blocks, empty_blocks, num_rows FROM user_tables WHERE table_name = SHRINK_TEST ; BLOCKS EMPTY_BLOCKS NUM_ROWS DELETE FROM SHRINK_TEST WHERE ROWNUM < 30000; COMMIT; ANALYZE TABLE SHRINK_TEST COMPUTE STATISTICS; SELECT blocks, empty_blocks, num_rows FROM user_tables WHERE table_name = SHRINK_TEST ; BLOCKS EMPTY_BLOCKS NUM_ROWS 이제해당블럭의수가 112로줄어든것을확인할수있다. 10g의 BFT의생성과관리 10g에서는새로운테이블스페이스타입인 BFT(Big File Tablespace, 대용량파일테이블스페이스 ) 를새롭게선보였다. BFT의크기는블럭크기에따라 8TB 부터 128TB까지지원한다. BFT와구별하기위해 10g 이전버전에서존재했던테이블스페이스를 스몰테이블스페이스 (Small Tablespace) 라고부른다. 이 BFT는반드시 Locally-Managed Tablespace만지원하고오직하나의테이터파일로만구성이된다. 따라서 BFT는테이블스페이스와테이터파일이 1:1로대

10 성능항목별 DBMS 3 종비교분석 database 응됨으로써파일관리가용이해졌고기존의저장공간을극대화할수있는장점이있다. BFT를생성하려면다음과같이 BIGFILE 키워드를이용하면된다. SQL> CREATE BIGFILE TABLESPACE BIG_TABLESPACE DATAFILE C:\oracle\product\ \oradata\orcl\bin.dbf SIZE 10M; 일반테이블스페이스와테이블스페이스와마찬가지로 BTF 파일의변경은 ALTER 명령어로써 RESIZING할수있다 (ALTER TABLESPACE BIG_TABLESPACE RESIZE 100M;). 또한 BFT 관련된정보로는 DATABASE_PROPERTIES, V$TABLESPACE, DBA_TABLES PACES에 BIGFILE에대한정보가추가됐다. SQL>SELECT TABLESPACE_NAME,BIGFILE FROM DBA_TABLESPACE; TABLESPACE_NAME BIGFILE SYSTEM NO UNDOTBS1 NO SYSAUX NO TEMP NO BIG_TABLESPACE YES 또한 BFT는기존의 RowID 체계와달리상대파일번호 (Realtive File Number) 를제외하고이자리에 BLOCK NUMBER를기록하는자리로사용하고있다. BFT에서는상대파일번호가항상 1024로고정되어있기때문에이에대한정보가필요치않다. 따라서기존의 RowID 정보를이용한애플리케이션이나 PL/SQL에서 BFT을사용하려면이에대한영향을미리검토해야한다. RowID 체계 - Smallfile Tablespace FFF BBBBBB RRR - Bigfile Tablespace LLL LLLLLL RRR : data object number FFF : relative file number( 상대파일번호 ) BBBBBB : data block number RRR : row number LLL LLLLLL : encoded block number (BFT에서의 BLOCK NUMBER를처리하기위한자리 ) 성능과확장성면에서의차이를비교한것이다. 오라클데이터베이스 10g RAC은트랜잭션을실행중인노드에로그를기록하는작업이완료되는즉시커밋을수행할수있다. 트랜잭션이클러스터의다른노드에의해수정된데이터를접근해야하는경우에도추가적인디스크 I/O를수반하지않고고속연결을통해블럭을전송한다. 로그의쓰기작업이완료되지않은상태에서도블럭을전송할수있어 SAP SD 벤치마크처럼집중적인 INSERT 작업이수반되는벤치마크환경에서도로그쓰기작업으로인해전송이지연되는경우가 5% 이하인것으로나타났다. 반면 DB2 시스템은하나의트랜잭션을통해두개이상의파티션의데이터가변경된경우트랜잭션의정합성을보장하기위해 two-phase 커밋프로토콜 ( 커밋시점의두단계커밋의첫번째시점에준비레코드를기록해야하며, 첫번째단계를완료해야두번째단계를진행하는것 ) 이반드시수행돼야한다. DB2 트랜잭션은커밋시점에쓰기작업을수행할레코드를미리준비한후 two-phase commit의첫번째단계를완료한이후에두번째단계를수행하며이는 OLTP 애플리케이션의응답시간을저하시키는결과를초래할수있다. RAC은 GCS(global cache service, 데이터가필요하고캐시에여유공간이있는 RAC이수정된데이터를독립적으로캐시할수있게해주는서비스. 이데이터에대한추가액세스는메인메모리속도로수행할수있다 ) 를사용해캐시일관성을보장한다. GCS는 RAC가간헐적으로변경되는데이터를여러노드의캐시에동시에저장하고캐시를위한공간을확보하기때문에이후데이터에대한접근이발생하는경우메인메모리의전송속도에준하는응답시간을나타낸다. 반면 DB2는마지막액세스가발생한이후데이터가변경되지않은경우에도노드간의통신을통해다른파티션의데이터에대한접근을처리한다. DB2는인덱스와테이블을동일하게파티셔닝하기때문에쿼리를수행하는과정에서다수의파티션에대한검색작업이불가피하다. 예를들어직원테이블이직원번호를기준으로파티셔닝돼있고직원이름을기준으로한인덱스가생성되어있다면직원이름을조회하는쿼리를수행하려면모든파티션을동시에검색해야한다. 직원의이름을기준으로한조회작업은파티션의수가많으면많을수록높은부하를수반하게된다. 또한 DB2 시스템은특정노드에대한부하집중의위험도가높아데이터가전체파티션에균등하게분산되어있지않을수있다. 예를들어금융계의최근거래내역의빈번한조회라든지특정데이터영역대의과도한조회업무에따라특정파티션의데이터가집중적으로조회될가능성이있다. 반면 RAC 환경에서는개별노드가데이터를점유하지않으며 마이크로소프트웨어 163

11 특집 2 부 오라클데이터베이스 10g 릴리즈 2 편 모든노드가동일한데이터에접근하므로부하분산의불균형이발생하지않는다. 트랜잭션을클러스터의특정노드군으로라우팅함으로써 RAC의성능을더높일수있으며이를통해데이터친화도 (data affinity, 다량의서로다른데이터에서서로의유사한패턴 ) 를높이고노드간의통신을줄일수있다. 라우팅은오라클넷의서비스네임을통해간단하게설정할수있다. 반면 DB2의경우트랜잭션에의해접근되는데이터의위치정보가별도로필요하므로트랜잭션의라우팅이훨씬까다롭다. 또데이터의재분배작업을수행하지않은상태에서다수의논리적노드에트랜잭션을수행해야하므로성능저하현상이발생할수있고부하의변화에유연하게대처하지못할가능성이높다. RAC은애플리케이션의바인드값 (bind value) 를기반으로미들웨어가요청을라우팅하도록구성되기도한다. 예를들어사용자의 < 화면 1> ADDM 을통한자가튜닝보고서 < 화면 2> 튜닝어드바이스 < 표 9> 성능과확장성측면에서오라클과 DB2 비교 오라클데이터베이스 10g RAC DB2 EEE two-phase 커밋불필요 two-phase 커밋필요 데이터는다수노드의캐시에저장됨 다른파티션에접근하려는경우 IPC 필요 데이터를단한차례만조회 다수의파티션에대해데이터조회 균등한부하분배 부하가특정노드에집중될가능성높음 < 표 10> 성능관리관련기능비교 오라클데이터베이스 10g DB2 성능관련 - Automatic Workload Repository 유사한기능이 관리기능 - Automatic Database Diagnostic Monitor 존재하지 - Automatic SQL Tuning 않음 로그인정보를기반으로메일서버가이메일연결을라우팅하도록설정하는식이다. 최적의성능을위해서는레인지나리스트파티셔닝을이용해바인드값을기준으로한파티셔닝을수행하는것이다. 반면 DB2는데이터의위치를사용자가직접결정할수없으므로이와같은방식을구현하기힘들다. 셀프튜닝과성능관련기능마지막으로오라클과 DB2는진단및셀프-튜닝기능측면에서도차이가있다. 오라클데이터베이스 10g는성능모니터링작업을단순화하고성능문제의진단과해결을자동화하기위한다양한툴을기본으로지원해이를통해시스템리소스의사용상황에따라데이터매개변수를자동으로조정한다. 관리자가만일어떠한원인으로일어날수있는지에대한시나리오를시뮬레이션할수있는인텔리전트어드바이스기능도제공하는데 index advisory, summary advisory, memory advisory, MTTR advisory, table/index usage advisory 등이대표적이다. DB2 역시일부셀프-튜닝기능과어드바이스기능을제공하고있지만여전히관리자에게상당한수준의데이터베이스지식을요구한다. 예를들어 DB2의 Control Center는실시간모니터링에필요한다양한성능지표를제공하지만시스템의전반적인상태를확인하기위해어떤성능지표를참고해야하는지에대한정보는알려주지않는다. 알수없는이유로시스템의성능이저하된경우 DB2 관리자는전적으로자신의개인적인지식에의존해서문제해결작업을수행해야하는것이다. 반면오라클은어드바이스기능을이용하여관리자에대한가이드를제공하고, 도움말과드릴다운을통해문제의근본원인을분석할수있도록지원한다. < 표 10> 은오라클이데이터베이스튜닝관련정보를제공하고튜닝프로세스자동화를위해제공하는기능을요약한것이다. AWR (Automatic Workload Repository) 은데이터베이스작업에관련한성능데이터와통계를저장하기위해활용되는공간이다. 오라클데이터베이스는중요한통계정보와워크로드정보의스냅샷을일정주기로생성하고이를 AWR에저장한다. 수집 / 처리된통계정보는오라클데이터베이스 10g에의해사전예방적 / 사후대응적모니터링을위한진단데이터로활용된다. 그러나 DB2는이와유사한기능을제공하지않는다. ADDM(Automatic Database Diagnostic Monitor) 은시스템상태를확인하기위해 AWR에캡처된데이터를분석하는데이터베이스자가진단엔진이다. ADDM은시스템의어느부분이가장많은 DB time 을사용하는지분석하고해결방안을제안하거나 SQL Access Advisor와같은다른솔루션을제안함으로써 DB time을최소화하는것을기본목적으로하고있다. ADDM은표면

12 성능항목별 DBMS 3 종비교분석 database 적인현상에초점을맞추는대신드릴다운을통해문제의근본원인을확인하고문제로인한시스템의전반적인영향에대해리포트를제공한다. 또한제시된해결방안이제공하는기대효과를정량화하고성능에문제가없는또는튜닝이불필요한시스템영역에대한보고서를 < 화면 1> 처럼제공한다. 오라클데이터베이스 10g는 SQL 구문의튜닝과정을상당부분자동화했다. Automatic SQL Tuning은 Automatic Tuning Optimizer를기반으로구현된기능으로, Oracle Query Optimizer 는자동튜닝모드에서튜닝프로세스에필요한조사와검증작업에더많은시간을할애한다. 이와같은추가적인시간을통해다이내믹샘플링, 부분실행 (partial execution) 등일반운영모드에서는시간적인제약으로인해적용될수없었던테크닉이사용되며비용, 선택성 (selectivity) 과확률에대한검증작업을수행하는것이가능하다. Automatic Tuning Optimizer에의해얻어진결론은 SQL Tuning Advisor를통해튜닝어드바이스의형태로사용자에게전달된다. 어드바이스는하나또는그이상의권고사항으로구성되며각권고사항별로근거와예상효과가명시된다. 어드바이스에는새로운인덱스의추가, SQL 구문의재작성, 또는 SQL 프로파일의구현과같은내용이포함될수있으며사용자는어드바이스의이행여부를단순히선택해 SQL 구문의튜닝과정을완료할수있다. 반면 DB2는 SQL 관련문제를진단하기위한쉽고편리한방법을제공하지않으며 ( 오직트레이스기능만제공 ) SQL 구문의재작성을통해튜닝을수행하는툴또한제공하지않는다. 오라클은어렵다? 오라클데이터베이스는다양한업계표준 /ISV 벤치마크를통해그성능을인정받고있으며이것은가장최근에출시된오라클데이터베이스 10g 역시예외는아니다. 필자역시기존버전제품에서의변화보다더많은변화를몸소느끼고있다. 이번글에서는다른 DBMS와차이점을중심으로살펴보았지만오라클역시타 DBMS에서좋은점들을벤치마킹하기위해노력하고있고실례로기존버전에서쉽게손댈수없는 SQL 튜닝, 메모리튜닝등자동화된관리기능은초보자들도쉽게다룰수있도록배려한것으로볼수있다. 즉 오라클은어렵다 는등식도점점깨져가고있는것이다. 현재국내에서가장널리사용되고있는 RDBMS인오라클의진화를필자는흥미진진한마음으로지켜보고있다. m a s o 1 년후에도내용이살아있는잡지 정리 박상훈 nanugi@imaso.co.kr 마이크로소프트웨어 165