[5.1.5 버전 확인 에러번호 확인] [hsyang@r920 ~]$ altierr -n 0x51043 0x51043 ( 331843) ulERR_ABORT_COMMUNICATION_LINK_FAILURE Communication link failure. <0%s> # *Cause: Communication link failure # *Action: Please send a bug report to the vendor [ai

Squirrel 에서도 동일한 증상이 보입니다! #####NEXT##### Squirrel 에서도 동일한 증상이 보입니다! #####NEXT##### 안녕하세요 Altibase입니다 해당 문제는 DBeaver에서 발생하는 문제로 생각되어지며. Squirrel 을

ALTIBASE HDB Administration Administrators Manual Release 6.1.1 (May 9, 2023) ----------------------------------------------------------- ALTIBASE Administration Administrator’s Manual Release 6.1.1 Copyright ⓒ 2001~2012 ALTIBASE Corp. All Rights Reserved. 본 문서의 저작권은 ㈜알티베이스에 있습니다. 이 문서에 대하여 당사의 동의 없이 무단으로 복제 또는 전용할 수 없습니다. ㈜알티베이스 152-790 서울시 구로구 구로동 182-13 대륭포스트타워Ⅱ 10층 전화: 02-2082-1114 팩스: 02-2082-1099 고객서비스포털: http://support.altibase.com homepage: http://www.altibase.com ----------------------------------------------------------- 목차 I 목 차 서문 ...................................................................................................................i 이 매뉴얼에 대하여 .............................................................................................................................. ii 1. 알티베이스 소개 ................................................................................................ 1 Hybrid DBMS개념 ................................................................................................................................. 2 알티베이스 특징 .................................................................................................................................... 8 알티베이스 구조 .................................................................................................................................. 15 2. 알티베이스 구성요소 ...................................................................................... 23 알티베이스 디렉토리......................................................................................................................... 24 실행 바이너리 ...................................................................................................................................... 30 알티베이스 라이브러리 .................................................................................................................... 33 3. 데이터베이스 생성 ......................................................................................... 35 데이터베이스 생성 ............................................................................................................................. 36 4. 알티베이스 구동 및 종료 .............................................................................. 43 알티베이스의 구동 ............................................................................................................................. 44 알티베이스의 종료 ............................................................................................................................. 46 5. 데이터베이스 객체 및 권한 .......................................................................... 49 데이터베이스 객체 개요 .................................................................................................................. 50 테이블 ....................................................................................................................................................... 54 큐 ................................................................................................................................................................ 61 제약조건 .................................................................................................................................................. 64 인덱스 ....................................................................................................................................................... 67 뷰 ................................................................................................................................................................ 73 시퀀스 ....................................................................................................................................................... 75 시노님 ....................................................................................................................................................... 78 저장 프로시저 및 저장 함수 ........................................................................................................ 80 트리거 ....................................................................................................................................................... 84 데이터베이스 사용자......................................................................................................................... 87 II Administrators Manual 권한 ........................................................................................................................................................... 89 6. 테이블스페이스 ............................................................................................... 93 테이블스페이스 정의 및 구조 ...................................................................................................... 94 테이블스페이스 분류 ...................................................................................................................... 103 디스크 테이블스페이스.................................................................................................................. 108 언두 테이블스페이스 ...................................................................................................................... 113 테이블스페이스 상태 ...................................................................................................................... 119 테이블스페이스 관리 ...................................................................................................................... 121 테이블스페이스 사용 예제 ........................................................................................................... 136 테이블스페이스 공간 관리 ........................................................................................................... 148 7. 파티션드 객체 ............................................................................................... 159 파티셔닝 정의 .................................................................................................................................... 160 파티션드 객체 .................................................................................................................................... 163 파티션 조건 ......................................................................................................................................... 171 파티셔닝 방법 .................................................................................................................................... 173 8. 트랜잭션 관리 ............................................................................................... 189 트랜잭션 ................................................................................................................................................ 190 잠금(Lock)............................................................................................................................................. 194 다중 버? 동시성 제어 기법 ...................................................................................................... 197 트랜잭션의 영속성 ........................................................................................................................... 206 9. 버퍼 관리자 ................................................................................................... 211 버퍼 관리자의 구조 ........................................................................................................................ 212 버퍼 관리 ............................................................................................................................................. 219 버퍼 관련 프로퍼티 ........................................................................................................................ 227 버퍼 관리자 통계 정보.................................................................................................................. 228 10. 백업 및 복구 ................................................................................................. 229 데이터베이스 백업 ........................................................................................................................... 230 데이터베이스 복구 ........................................................................................................................... 236 백업 및 복구 사례들 ...................................................................................................................... 241 11. SQL 튜닝 ....................................................................................................... 255 SQL 튜닝 개요 ................................................................................................................................... 256 질의 최적화 과정 ............................................................................................................................. 264 실행 계획 분석 .................................................................................................................................. 311 힌트의 활용 ......................................................................................................................................... 356 목차 III 12. Explain Plan .................................................................................................. 363 개요 ........................................................................................................................................................ 364 Plan Tree 보기 .................................................................................................................................. 367 Plan Nodes ......................................................................................................................................... 369 13. SQL Plan Cache ............................................................................................ 397 개요 ........................................................................................................................................................ 398 SQL Plan Cache의 특징 ................................................................................................................ 400 SQL Plan Cache 관련 프로퍼티 ................................................................................................ 401 14. 서버/클라이언트 통신 .................................................................................. 403 통신 방법 ............................................................................................................................................. 404 15. 알티베이스의 보안 ....................................................................................... 409 보안의 개요 ........................................................................................................................................ 410 보안 기능의 구성 ............................................................................................................................ 412 보안 모듈 연동 방법...................................................................................................................... 413 보안 모듈 구동과 데이터 암호화 ............................................................................................ 415 16. 알티베이스 튜닝 ........................................................................................... 419 로그 파일 그룹 ................................................................................................................................. 420 그룹 커밋 ............................................................................................................................................. 426 17. 알티베이스 진단 모니터링 .......................................................................... 433 알티베이스 모니터링...................................................................................................................... 434 알티베이스 문제상황 분석 .......................................................................................................... 435 A. 부록: Trace Log ............................................................................... 445 Trace Log ............................................................................................................................................. 446 B. 부록: 알티베이스 최대치 ................................................................ 447 알티베이스 객체들의 최대값 ..................................................................................................... 448 찾아보기 ..................................................................................................... 449 서? i 서문 ii Administrators Manual 이 매뉴얼에 대하여 이 매뉴얼은 알티베이스를 구성, 관리, 사용하기 위? 필요? 개념에 대? 설명?다. 대상 사용자 이 매뉴얼은 다음과 같은 알티베이스 사용자를 대상으로 작성되었다. 데이터베이스 관리자 시스템 관리자 성능 관리자 다음과 같은 배경 지식을 가지고 이 매뉴얼을 인는 것이 좋다. ?퓨터, ?영 체제 및 ?영 체제 유틸리티 ?용에 필요? 기본 지식 관계형 데이터베이스 사용 경험 또는 데이터베이스 개념에 대? 이? 데이터베이스 서버 관리, ?영 체제 관리 또는 네트워크 관리 경험 소프트웨어 ?경 이 매뉴얼은 데이터베이스 서버로 알티베이스 버? 6.1.1을 사용?다는 가정 하에 작성되었다. 이 매뉴얼의 구성 이 매뉴얼은 다음과 같이 구성되어 있다. 제 1장 알티베이스 소개 이 장은 알티베이스 데이터베이스 서버를 이?하는데 필요? 개념, 특징 및 구조에 대? 개요를 제공?다. 제 2장 알티베이스 구성 요소 이 장은 알티베이스를 구성하고 있는 실행 바이너리 부?과 프로그래밍 라이브러리 부? 구성 요소들에 대? 설명?다. 제 3장 데이터베이스 생성 이 장은 데이터베이스를 구성하는 대표적 구성 요소? 서? iii 테이블스페이스와 로깅 시스템의 종류 및 데이터베이스 생성 방법에 관하여 설명?다. 제 4장 알티베이스 구동 및 종료 이 장은 알티베이스를 구동 및 종료 시키는 방법과 알티베이스 다단계 구동 시 내부적으로 수행하는 작업에 대? 설명?다. 제 5장 데이터베이스 객체 및 권? 이 장은 특정 사용자에 의? 생성된 제약조건, ?덱스, 시퀀스, 이중화, 테이블, 사용자 등 데이터베이스 객체들에 대? 설명?다. 또?, 시스템 및 스키? 객체 수?의 권?에 대? 설명?다. 제 6장 테이블스페이스 관리 이 장은 데이터베이스의 논리적 구조를 이?함으로써 데이터베이스의 공? 관리를 작은 단위로 제어하고, 물리적 데이터 영역을 효율적으로 관리하는 방법에 대? 설명?다. 제 7장 파티?드 객체 이 장은 대용량 데이터베이스 테이블을 여러 개의 작은 조각으로 분?하여 관리하는 파티?드 테이블에 대? 설명?다. 제 8장 트?잭? 관리 이 장은 트?잭?을 정의하고 트?잭?을 사용하여 작업을 관리하는 방법에 대? 설명?다. 제 9장 버퍼 관리자 알티베이스는 대용량의 데이터가 디스크에 저장될 수 있도록 지원하는데, 메모리의 공?은 ?정되어 있으므로 이를 ?부 메모리에 적재? 수 없으므로 테이블, ?덱스, 레코드 등 모? 데이터에 접?하기 위?서는 먼저 디스크의 데이터를 메모리에 적재?야 ?다. 이 장은 이러? 메모리 공?을 ?당하고, 메모리 공?이 부족? 경우 필요? 데이터를 제공? 수 있도록 메모리 공?을 유지 및 관리하느 버퍼 관리자에 대하여 설명?다. 제 10장 백업 및 복구 이 장은 시스템 정? 또는 디스크, 데이터 파? 손상 유실 등과 같은 예기치 않은 상황으로 ?? 알티베이스에 저장된 데이터가 손실될 경우를 대비하여 알티베이스에서 지원하는 백업 및 복구에 대하여 설명?다. 제 11장 SQL 튜닝 이 장은 질의 성능을 향상시키기 위? SQL 튜닝 방법에 대하여 설명?다. 제 12장 Explain Plan 이 장은 알티베이스 DBMS 서버가 최적화된 질의를 실행하기 위? 수행하는 접? 경로를 설명?다. 제 13장 SQL Plan Cache iv Administrators Manual 이 장은 알티베이스 SQL Plan Cache 기능에 대? 개념 및 특징에 대? 설명?다. 제 14장 Communication Layer 이 장은 알티베이스 데이터베이스 서버와 클라이?트 응용프로그램?의 접속 방법과 프로토콜에 대? 설명?다. 제 15장 알티베이스의 보? 이 장은 데이터베이스의 정보를 보호하기 위? 알티베이스의 보? 기능에 대? 설명?다. 제 16장 알티베이스 튜닝 이 장은 알티베이스의 성능 향상을 위? 로그 파? 그룹과 그룹 커밋에 대? 설명?다. 제 17장 알티베이스 모니터릿 및 PBT 이 장은 알티베이스의 ?영상태를 확?하는 방법과 ?당 내용을 분석하는 방법에 대? 설명?다. 또?, 알티베이스 ?영 중 발생? 수 있는 여러 가지 ?제 상황에 대하여 점검 사핫 및 분석 방법에 대? 설명?다. A. 부록: Trace Log 이 부록은 알티베이스 서버에서 실행되는 SQL? 관? 정보를 trace 로그로 남기는 방법을 설명?다. B. 부록: 알티베이스 최대치 이 부록은 알티베이스 객체들의 최대값을 기술?다. 문서화 규칙 이 ?에서는 이 매뉴얼에서 사용하는 규칙에 대? 설명?다. 이 규칙을 이?하면 이 매뉴얼과 설명서 세트의 다른 매뉴얼에서 정보를 쉽게 찾을 수 있다. 여기서 설명하는 규칙은 다음과 같다. 구? 다이어그램 샘플 코드 규칙 구문 다이어그램 이 매뉴얼에서는 다음 구성 요소로 구축된 다이어그램을 사용하여, 명령?의 구?을 설명?다. 구성 요소 의미 예약어 명령?이 시작?다. 완?? 명령?이 아? 구? 요소는 화살표로 시작?다. 명령?이 다음 라?에 계속된다. 완?? 명령?이 아? 서? v 구? 요소는 이 기호로 종료?다. 명령?이 이? 라?으로부터 계속된다. 완?? 명령?이 아? 구? 요소는 이 기호로 시작?다. ; 명령?이 종료?다. SELECT 필수 핫목 NOT 선택적 핫목 ADD DROP 선택사핫이 있는 필수 핫목. ? 핫목? 제공?야 ?다. ASC DESC 선택사핫이 있는 선택적 핫목. , ASC DESC 선택적 핫목. 여러 핫목이 허용된다. 각 반복 앞부분에 콤?가 와야 ?다. 샘플 코드 규칙 코드 예제는 SQL, Stored Procedure, iSQL, 또는 다른 명령 라? 구?들을 예를 들어 설명?다. 아래 테이블은 코드 예제에서 사용된 ?쇄 규칙에 대? 설명?다. 규칙 의미 예제 [ ] 선택 핫목을 표시 VARCHAR [(size)] [[FIXED |] VARIABLE] { } 필수 핫목 표시. 반드시 하나 이상을 선택 ?야 되는 표시 { ENABLE | DISABLE | COMPILE } | 선택 또는 필수 핫목 표시의 ?자 구분 표 시 { ENABLE | DISABLE | COMPILE } [ ENABLE | DISABLE | COMPILE ] . . 그 이? ?자의 반복 표시 예제 코드들의 생략되는 것을 표시 SQL> SELECT ename FROM employee; vi Administrators Manual . ENAME ------------------------ SWNO HJNO HSCHOI . . 20 rows selected. 그 밖의 기호 위에서 보여? 기호 이 외에 기호들 EXEC :p1 := 1; acc NUMBER(11,2); 기?임 꼴 구? 요소에서 사용자가 지정?야 하는 변 수, 특수? 값을 제공?야? 하는 위치 지 정자 SELECT * FROM table_name; CONNECT userID/password; 소?자 사용자가 제공하는 프로그램의 요소들, 예 를 들어 테이블 이름, 칼럼 이름, 파? 이 름 등 SELECT ename FROM employee; 대?자 시스템에서 제공하는 요소들 또는 구?에 나타나는 키워드 DESC SYSTEM_.SYS_INDICES_; 관? 자료 자세? 정보를 위하여 다음 ?서 목록을 참조하기 바?다. Installation Guide Getting Started Guide SQL Reference Stored Procedures Manual iSQL Users Manual Utilities Manual Error Message Reference 온라인 매뉴얼 알티베이스 고객서비스포털(http://support.altibase.com)에서 국? 및 영? 매뉴얼(PDF, HTML)을 받을 수 있다. 서? vii 알티베이스는 여러분의 의견을 ?영합니다. 이 매뉴얼에 대? 여러분의 의견을 보내주시기 바랍니다. 사용자의 의견은 다음 버?의 매뉴얼을 작성하는데 ?은 도움이 됩니다. 보내실 때에는 아래 내용과 함께 고객서비스포털(http://support.altibase.com/kr/)로 보내주시기 바랍니다. 사용 중? 매뉴얼의 이름과 버? 매뉴얼에 대? 의견 사용자의 성함, 주소, ?화번호 이 외에도 알티베이스 기술지원 설명서의 오류와 누락된 부분 및 기타 기술적? ?제들에 대?서 이 주소로 보내주시면 정성껏 처리하겠습니다. 또?, 기술적? 부분과 관?하여 즉각적? 도움이 필요? 경우에도 고객서비스포털을 통? 서비스를 요청하시기 바랍니다. 여러분의 의견에 핫상 감사드립니다. 알티베이스 소개 1 1. 알티베이스 소개 이 장에서는 알티베이스를 처음 접하는 사용자들을 위?서 Hybrid DBMS의 등장 배경과 알티베이스의 구조 및 특징에 대?서 설명?다. 2 Administrators Manual Hybrid DBMS개념 알티베이스의 새로? 개념? Hybrid Database Management System(이하 Hybrid DBMS) 에 대?서 설명?다. Hybrid DBMS 등장 배경 Hybrid DBMS의 등장은 데이터를 저장하는 두 가지 대표적? 기억 장치? 메모리와 디스크의 특징과 밀접? 관?이 있다. 첫째, 메모리는 ?자 게이트로 구성되어 있고 접?시?이 수 ns(십억 분의 ?초) 단위로서 매우 빠르며 접?시?이 균?하고 정? 시에는 데이터가 소실되는 특징을 가지고 있다. 즉, 메모리는 휘발성 저장 매체이다. 반면에, 디스크는 헤드암과 플래터로 구성되어 있다. 디스크 접?시?이 수 us(백? 분의 ?초)로 메모리에 비?서 상대적으로 느리다. 게다가 접?시?이 균?하지 않다. 최?에 좀 더 대중화된 SSD(Solid State Drives) 조차도 휘발성 메모리에 비?서는 접? 시?이 좀 느리다. 그러나 정?이 되더라도 디스크의 데이터는 영구히 보?되는 특징을 가지고 있다. 둘째, 메모리는 메?보드와 시스템 버스로 연결되어 있어 메?보드의 특성에 따라 최대 저장 크기가 결정 된다. 메?보드에 장착된 CPU가 32비트이면 메모리의 최대 크기는 4GB, CPU가 64비트라고 ?도 최대 크기는 현재 수백 GB(십억 바이트)까지? 장착 가능하다. 반면에, 디스크는 메?보드와 I/O버스로 연결되어 있어 메?보드의 특징과 거의 무관하게 수 TB(?조 바이트)까지 구성이 가능하다. 요약하면, ?반적으로 메모리는 디스크에 비? 접? 시?이 수백배 빠르며 성능이 균?? 반면, 정?시 데이터가 소실되고 저장용량에 ?계가 있다. 이에 반?, 디스크는 데이터가 영구히 저장되며 저장용량의 ?계가 거의 없는 반면, 접? 시?이 느리고 ?정하지 않다. 이런 기억장치의 특징에 따라서 DBMS는 디스크에 데이터를 저장하는 Disk-Resident DBMS(이하 DRDBMS)와 메모리에 데이터를 저장하는 Main-Memory DBMS(이하 MMDBMS)가 ?재? 왔다. Hybrid DBMS는 이 두 가지 구조의 장점을 수용하고, 단점을 보완하여 개발 되었다. 알티베이스 소개 3 DRDBMS 등장 DRDBMS구조는 데이터가 디스크에 저장되어 있고, DRDBMS가 디스크에 있는 데이터를 메모리 버퍼로 인어서 응용프로그램에게 ?달? 주는 형태이다. 이런 구조는 응용프로그램이 표? SQL을 통?서 데이터에 접?하고, DBMS가 동시성제어 및 복구를 통? 데이터를 보호하기 때?에 응용프로그램의 개발이 훨씬 ?편?지며 데이터 공유가 쉬? 장점이 있다. 또? 데이터가 디스크에 저장되어 있기 때?에 대용량 데이터베이스를 구성? 수 있다. 이런 장점 때?에, 지금까지 ? 산업분야에서 DRDBMS가 광범위하게 사용되어 왔다. 하지?, 사회?반에 걸쳐 정보화가 급격히 ??되고 정보처리의 요구 성능이 높아지면서 데이터 처리에 대? 수요는 ?았으나, DRDBMS의 낮은 평균 처리속도와 처리속도의 기복(jitter)의 ?제 때?에 DRDBMS를 사용하지 못하는 분야가 ?았다. 따라서 고성능 및 균? 성능의 데이터 처리를 필요로 하는 산업 분야에서는 지금까지 Custom Designed Memory DB를 사용하였다. 그러나 범용적이지 않고 데이터 관리에 필요? 모? 것을 직접 개발?야 했기 때?에 개발 및 유지보수가 어렵고, 성능, 가용성, 확장성 등에서 ?제가 있었다. MMDBMS 등장 MMDBMS의 구조는 데이터가 메모리에 저장되어 있고 MMDBMS가 메모리에 있는 데이터를 인어서 응용프로그램에 ?달하는 형태이다. 이런 구조는 DRDBMS의 장점? 표? SQL을 통? 데이터 접?, 동시성 제어 및 복구을 통? 데이터 보호, 이를 통? 응용프로그램의 개발과 데이터 공유의 용이성 등의 장점을 그대로 가?다. 또? MMDBMS는 데이터를 메모리에 저장하기 때?에 디스크에 데이터를 저장하는 DRDBMS에 비? 평균처리 속도가 매우 빠르며 메모리의 특징? 균?? 성능을 보장?다. 따라서 고성능 및 균? 성능의 필요성 때?에 DRDBMS를 사용? 수 없는 분야에서 각광을 받고 있다. ?반적으로 DRDBMS에 비?서 MMDBMS가 갱? 연산은 약 10배, 검색 연산은 약 3배 이상의 성능을 보?다. 4 Administrators Manual 갱? 연산이 DRDBMS에 비?서 수백배가 아? 이유는 MMDBMS도 데이터 보호를 위?서 DRDBMS와 똑같이 로그파?을 디스크에 기록하기 때?이다. 그럼에도 불구하고 MMDBMS의 갱? 연산이 더 빠른 이유는 MMDBMS는 데이터 보호가 DRDBMS에 비?서 훨씬 단순하게 최적화되어 있기 때?이다. 또? 검색 연산이 DRDBMS에 비?서 수백배가 아? 이유는 DRDBMS도 데이터접? 성능을 높이기 위? 메모리 버퍼를 사용하기 때?이다. 그럼에도 불구하고 MMDBMS의 검색 연산이 더 빠른 이유는 데이터접?이 단순하게 최적화되어 있고, 메모리 접? 시 성능의 기복(jitter)이 없기 때?이다. 이런 고성능 및 균?성능의 장점에도 불구하고 데이터를 메모리에 저장?야 하는 MMDBMS는 정보처리의 요구량이 방대하여 수백 GB이상의 데이터를 저장?야 하는 산업분야에서 다시 ?계를 나타내게 되었다. MMDBMS와 DRDBMS 혼용 구조 등장 이런 ?제점을 극복하기 위?서 현재 가장 ?반적으로 사용되는 구조는 데이터를 구분하여 저장하는 형태이다. 고성능이 필요? 데이터는 MMDBMS에, 대용량이 필요? 데이터는 DRDBMS에 저장함으로써 MMDBMS와 DRDBMS를 ?용?다. 이러? 구조는 MMDBMS와 DRDBMS의 공통정보에 대?서 서로 동기화?야 ?다는 ?제, MMDBMS와 DRDBMS를 같이 처리?야 하는 응용프로그램은 양쪽에 동시에 접속?서 처리?야 ?다는 ?제, 또? 장애 복구가 복잡하다는 ?제들을 가지고 있다. 하지? 이제까지는 고성능처리와 대용량처리를 함께 처리? 방법이 없었기 때?에, 고성능처리와 대용량 정보처리가 필요? 분야에서는 ?반적으로 ?용되고 있다. Hybrid DBMS 등장 Hybrid DBMS는 DRDBMS, MMDBMS, 그리고 MMDBMS와 DRDBMS를 ?용하는 각각의 구조들의 장점을 수용하고 ?제점을 ?결하기 위?서 등장하게 되었다. Hybrid DBMS는 데이터를 구분하여, 고성능이 필요? 데이터는 메모리에, 대용량이 필요? 데이터는 디스크에 저장하되, 이 두 가지 데이터를 처리하는 DBMS는 하나로 통합된 구조를 가지고 있다. 고성능 정보처리와 대용량 정보처리를 하나의 DBMS에서 통합, 알티베이스 소개 5 처리하는 구조이기 때?에, 앞서 설명? ?용구조의 동기화 ?제, 복잡? 장애처리 ?제, 응용프로그램이 복잡?지는 ?제를 ?결하게 되었다. 또? MMDBMS ?용, DRDBMS ?용, Hybrid DBMS 등 다양? 구성이 가능하게 되었다. 요약하면, Hybrid DBMS는 고성능 정보처리를 가능하게 하는 MMDBMS와 대용량 정보처리를 가능하게 하는 DRDBMS의 장점을 결합하여 데이터는 구분하여 저장하고 데이터 관리는 통합? 구조이다. 즉, Hybrid DBMS는 효율적? 시? ?용으로 고성능 정보 처리가 가능하고, 효율적? 자원?용으로 대용량 정보처리를 ? 수 있게 되었다. Hybrid DBMS는 고성능 및 대용량 정보처리가 모두 필요? 분야를 포함하여 포괄적으로 사용이 가능?졌다. DR DBMS 스 이 이 MM DBMS Hybrid MM DBMS 스 이 이 대용 고 DR DBMS 스 이 DR DBMS 스 이 이 MM DBMS 이 MM DBMS Hybrid MM DBMS 스 이 이 Hybrid DBMS 스 이 이 [그림 1-1] 고성능 대용량 DBMS구조 Hybrid DBMS 알티베이스의 특징 Hybrid DBMS? 알티베이스는 저장 관리자(Storage Manager)와 질의 처리기(Query Processor), 그리고 메? 모듈(Main Module)로 구성되어 있다. 저장 관리자는 동시성 제어 및 회복을 통? 데이터보호를 담당하는 모듈이고 질의 처리기는 표? SQL로부터 실행계획을 생성하여 데이터접?을 담당하는 모듈이다. ?지링으로, 메? 모듈은 여러 개의 클라이?트로부터 수?되는 요청(Request)들을 동시에 처리? 수 있도록 서버의 세? (session)과 쓰레드 (thread)의 관리를 담당하는 모듈이다. 저장 관리자 저장 관리자는 복구 관리자와 동시성 제어 부분으로 구성되어 있다. 6 Administrators Manual 저장 관리자는 Layer 구조로 구성하여, 구현 복잡도를 개선하고 구조적 ?정성을 확보하였으며 보다 손쉽게 Layer별 Unit Test를 ? 수 있어 결함 발생률를 ?였다. 복구 관리자는 메모리 테이블과 디스크 테이블의 로그파?이 통합되어 최적의 검사점 수행알고리즘이 적용되었으며, 개발과정에서 자동 복구 시험 도구(Automatic Recovery Test Tool)을 사용하여 오류 가능성을 ?였다. 동시성 제어 부분은 Index Layer와 Transaction Layer, Application Layer, Interface Layer로 구성되어 있고, Out-place MVCC와 In- place MVCC가 통합되었고, Transaction Status Slot과 Start SCN List 기법이 적용되어 동시수행 성능이 향상되었다. 그리고, B+트리(B+Tree) ?덱스도 ?덱스 구조 수정 연산 (Structure Modification Operation)이 발생하였을 때 B+트리 검색 과정 중에 Latch를 잡지 않는 구조로 되어 있어서 더욱 성능이 향상되었다. 메모리 테이블스페이스와 디스크 테이블스페이스의 ?터페이스가 통합되어 메모리, 디스크 테이블스페이스 사용이 편리?졌고 서로 쉽게 호?된다. 질의 처리기 질의 처리기는 질의 실행기(Query Executor)와 질의 최적화기(Query Optimizer)로 구성되며, 메모리 쿼리, 디스크 쿼리, 하이브리드 쿼리를 통합? 투명? 구조로 구성되었다. 질의 실행기는 Tuple-Set Processing으로 ?? 노드? 의?성이 완?히 제거됨으로써 최소 Plan Node로 다양? 조?이 구현되었다. 조? 방법이 10개에서 34개로 확장되었음에도 불구하고, Plan Node는 하나? 추가되었다. 질의 최적화기는 부하가 거의 없는 실시? 통계정보가 ?용되었고, 메모리 쿼리, 디스크 쿼리, 하이브리드 쿼리 구분 없이 비용 계산(cost estimation)을 투명하게 하도록 구현되었다. 또? Join Greedy Algorithm을 Join Ordering 알고리즘으로 사용하여 최적화기의 탐색공?이 최소화되었다. 메? 모듈 세? 관리자(Session Manager)는 세?을 관리하는 역?을 ?다. 쓰레드 관리자(Thread Manager)는 데이터를 처리하는 쓰레드들을 관리?다. 알티베이스 소개 7 Database Memory chunk Checkpoint Image Log Buffer Log file and Control file Log Buffer Data file Hybrid DBMS ALTIBASE Storage Manager Recovery Logging Check point managing Resources Concurrency Control Locking Versioning Indicies B+ Tree R Tree Pages Collection Page Query Processor Executor Plan Nodes Records and Temporary Tables Mathematics Module Optimizer Graph Plan Tree Logic Main Module Session ManagerThread Manager [그림 1-2] 알티베이스 내부 구조 8 Administrators Manual 알티베이스 특징 고성능 대용량 하이브리드 데이터베이스 시스템? 알티베이스에 대? ?반적? 내용을 소개?다. 하이브리드 데이터베이스 시스템으로써 알티베이스가 갖는 특징, 구조, 기능 등에 관하여 ?략하게 설명?다. 이에 대? 자세? 내용은 알티베이스 각각의 세부 매뉴얼을 참조?다. 데이터 모델 알티베이스의 데이터 모델은 관계 모델 (relational model)을 채택하고 있다. 관계 모델은 세 가지 주요 요소를 포함?다. 구조(structure)는 데이터베이스를 저장하거나 접?하는 객체 단위로 테이블, 뷰, ?덱스 등을 ?컫는다. 이들은 곧 연산자의 조작 단위가 된다. 연산(operation)은 데이터베이스의 데이터와 구조를 사용자들이 조작? 수 있도록 허용하는 행위(action)들을 정의? 것으로써 무결성 규칙을 수반?다. 무결성 규칙(integrity rule)은 데이터와 구조에 허용된 연산을 다루기 위? 법칙으로, 데이터와 구조를 보호하기 위? 것이다. 관계 데이터베이스 관리 시스템은 다음과 같은 장점을 제공?다. 물리적 데이터와 논리적 데이터 독립성을 유지?다. 모? 데이터에 대? 접?이 다양하고 쉽다. 데이터베이스 설계가 유연하다. 데이터베이스 저장 공?과 데이터의 중복을 ?? 수 있다. 엔? 구조 알티베이스는 클라이?트-서버 구조를 제공?다. 클라이?트-서버 구조는 클라이?트가 통?망을 통? 서버에 접?하는 형태로 기?의 RDBMS가 제공하는 방식이다. 알티베이스 서버는 내부적으로 다중 쓰레드 구조를 갖고 있다. 클라이?트-서버 구조에서 ? 개의 클라이?트는 ? 개의 서버 쓰레드와 세?(session)을 구성?다. 알티베이스 소개 9 인터페이스 알티베이스는 기?의 실시? 데이터베이스 시스템과는 달리 범용성을 추구하는 ??으로 산업 표? ?터페이스를 지원?다. 알티베이스에서 제공하는 데이터베이스 질의어는 SQL92 표?을 따른다. 프로그래밍 ?터페이스로는 ODBC, JDBC, C/C++ Precompiler 등을 지원하고 있으며, 기?에 작성된 데이터베이스 응용 프로그램을 변?? 필요 없이 그대로 사용? 수 있다. 알티베이스 SQL에 대? 자세? 내용은 SQL Reference 를 참조?다. 다중버? 기법 알티베이스는 다중버? 기법(이하 MVCC: Multi-Version Concurrency Control)을 이용? 동시성 제어를 수행?다. 다중 버? 기법은 하나의 데이터에 대? 여러 개의 버?을 유지하여 인기와 쓰기 연산에 대? 충돌을 없앰으로서 최대의 성능을 발휘? 수 있도록 하는 것이다. 특히, 기?의 row locking 방식의 단점이었던 인으려고 하는 데이터가 이미 다른 수정 연산에 의? lock이 걸려 있거나, 수정하려는 데이터를 다른 인기 연산이 인는 중이어서 장기? 대기?야 하는 ?제점을 제거하였으며, 필요 없는 오래된 데이터를 즉시 회수함으로서 메모리의 낭비를 방지하였다. 다중 버? 기법은 대규모 사용자가 접?하는 ?경에서 최적의 성능을 발휘하고, 데이터베이스를 종료하지 않고도 즉시 백업? 수 있는 ?-백업(hot- backup) 시스템을 지원?다. 알티베이스는 메모리 테이블과 디스크 테이블에 대? 외형상으로는 같은 기능을 하지?, 서로 다른 방법으로 MVCC를 구현하였다. 메모리 테이블은 레코드의 변경시?다 새로? 버?을 생성하는 out- place MVCC로 구현되어 있으며, 디스크 테이블의 경우는 변경된 데이터를 기?의 레코드에 덮어 쓰고, 변경 이?의 정보를 undo 테이블스페이스에 저장하여 참조하는 in-place MVCC 방식을 채택하고 있다. 트랜잭션 알티베이스는 Hybrid DBMS의 구조에 맞추어 최고의 성능을 낼 수 있는 트?잭? 구조와 이와 관?된 다양? 기능을 제공?다. 먼저 데이터베이스 내에서 동시에 수행될 수 있는 트?잭?의 개수를 10 Administrators Manual 프로퍼티를 이용?서 조?? 수 있다. 또? 효율적? 서버 ?영을 위? AUTOCOMMIT 모드를 사용? 수 있다. 그리고 알티베이스가 제공하는 트?잭?의 고립화 수?(isolation level)은 read committed(=0), repeatable read(=1), no phantom read(=2)가 있으며, 사용자의 필요에 맞추어 적?하게 선택하여 사용? 수 있다. 로깅 데이터베이스 ?정성과 영속성을 위하여 알티베이스는 변경된 데이터베이스 내용에 대하여 로깅(logging)을 수행?다. 또? 시스템?의 이중화 (Replication) 작업 때의 성능을 극대화 시키기 위? 최적의 로그를 생성?다. 버퍼 풀 (Buffer Pool) 디스크 테이블스페이스에 접?하는 트?잭?들의 성능을 향상시키기 위? 디스크에 대? I/O 회수를 최소화?야 ?다. 이를 위? 버퍼 풀을 사용함으로써 이?에 디스크로부터 인은 페이지들 중 ?정 부분을 메모리에 캐시? 두어 디스크에서 다시 인어들이는 것을 방지?다. 버퍼 풀은 Hot-Cold LRU(Least Recently Used) 알고리즘에 의? 관리된다. 더블 라이트 (Double Write) 파일 알티베이스 시스템의 페이지 크기와 파? 시스템의 물리적 페이지 크기가 다를 경우, 디스크 I/O 수행 중에 알티베이스 서버가 비정상적으로 종료하면 페이지가 온?하지 못? 상태로 남아있을 수 있다. 이런 현상을 방지하기 위하여 알티베이스는 페이지를 플러시? 때, 같은 이미지를 디스크의 더블 라이트 파?에 저장? 후, 페이지 원래 위치에 다시 저장?다. 그리고 알티베이스를 재구동? 때 더블 라이트 파?의 내용과 실제 페이지의 내용을 비교하여 손상된 페이지를 복구?다. 더블 라이트 기능은 디스크의 결함을 보완? 주지?, 시스템의 성능을 떨어뜨릴 수 있다. 이 기능은 사용자가 성능을 위? 사용하지 않을 수 있다. 알티베이스 소개 11 퍼지 汰廣 알티베이스는 최?의 데이터베이스 상태를 ??하게 백업(backup) 데이터베이스로 반영하기 위? 퍼지 트를 수행?다. 메? 메모리 데이터베이스에서의 퍼지 체크포?트(fuzzy checkpoint)는 모? 변경된 데이터 페이지가 백업 데이터베이스로 내려가 현재 수행중? 트?잭?의 수행에 영향을 미칠 수 있기 때?에 퍼지 체크포?트와 더불어 핑퐁 체크포?트(ping pong checkpoint) 방식을 함께 수행?다. 즉, 백업 데이터베이스를 두 개로 관리함으로써, 체크포?트 과정에서 부하를 ?? 수 있어 트랙잭? 동작이 최대?의 성능을 발휘? 수 있다. 저장 프로시저 (Stored Procedure) 저장 프로시저는 입력 ?자, 출력 ?자, 입출력 ?자를 가지고 바디(body) 내에 정의된 조건에 따라 여러 SQL ?을 ?번에 수행하는 데이터베이스 프로시저다. 저장 프로시저의 종류는 리턴값 유무에 따라 프로시저와 함수로 나누어 ?다. 자세? 내용은 Stored Procedures Manual을 참고?다. 데드락 감지 (Deadlock Detection) 데드락은 트?잭??의 리소스 ?당이 자동으로 ?제될 수 없는 비정상적? 트?잭? 정지 상태이다. 이러? 경우 ?반적으로 데드락을 감지하는 별도의 쓰레드 또는 프로세스를 두게 되는데, 이러? 감지 구조는 필연적으로 ?시적? 서비스 중단 사태를 초래?다. 알티베이스는 별도의 데드락 감지 쓰레드를 두지 않고, 데드락이 발생되는 순? 데드락 상황을 감지하여, ?속히 조치를 취함으로써 어떠? 경우에도 서비스가 중지되지 않도록 하며, 지속적이고 ?정적? 데이터베이스 ?용을 보장?다. 테이블 컴팩션 데이터베이스 ?용시, 실제로 특정 메모리 테이블이 필요? 메모리 공? 이상을 차지하는 경우가 발생?다. 주로 대량의 데이터가 삽입 된 후 변경 및 삭제가 이루어지는 경우가 그러하다. 이런 경우 ?당 12 Administrators Manual 테이블에서 필요 없는 메모리를 시스템으로 반?? 수 있다면, 보다 효율적으로 메모리 사용이 가능하다. 이런 필요로 ?? 알티베이스는 메모리 테이블에 대? 테이블 단위의 ?팩?(compaction) 기능을 제공하며, 이 기능을 이용하여 메모리 및 테이블의 효율적 관리가 가능하다. 데이터베이스 이중화 알티베이스는 시스템의 높은 가용성(high availability)과 무정지(fault tolerance) 시스템을 위하여 로그 기반의 데이터베이스 이중화(replication)를 제공?다. 로그 기반의 이중화 시스템 구조는 트?잭? 로그를 기반으로 데이터베이스를 이중화시킴으로써, 알티베이스의 효율성을 높이고 시스템 부하를 ?? 수 있다. 서비스 중? 지역(local) 시스템의 이중화 관리 쓰레드는 로그 데이터를 원격(Remote) 시스템의 이중화 관리 쓰레드에 실시?으로 ?달?다. 원격 시스템의 이중화 관리 쓰레드는 ?달받은 로그 데이터를 분석하여 이것을 알티베이스 서버에게 ?달하고 알티베이스 서버는 이 내용을 데이터베이스에 반영?다. 이렇게 함으로써 서비스 중? ?퓨팅 시스템이 중단되었을 때, 시스템 복구 시?이 필요 없이 곧바로 다른 시스템을 사용하여 서비스? 수 있는 체제를 갖추고 있다. 알티베이스는 부하 분산(load balancing) 기능도 제공?다. 알티베이스의 데이터베이스 복제 ?영 ?경에서, 서비스하는 트?잭?들을 두 그룹 이상으로 나누어 각각의 트?잭?이 ?당 서버에서 수행되도록 구성하면, 각 서버에서 변경되는 데이터베이스 내용은 이중화를 통?서 상대편 서버에 반영됨으로써 복제된 데이터베이스의 ?관성(consistency)을 보장? 수 있다. 클라이언트-서버 프로토콜 알티베이스를 클라이?트-서버 구조로 ?영? 때, 사용자는 응용 시스템의 구성에 적합? 클라이?트-서버 프로토콜을 선택하여 사용? 수 있다. 알티베이스가 제공하는 통? 프로토콜로는 TCP/IP, IPC와 Unix Domain socket이 있다. TCP/IP(Transmission Control Protocol/Internet Protocol) 프로토콜은 네트워크 상에서 클라이?트-서버 ?에 사용되는 사실상의 표? 통? 프로토콜이다. IPC(Inter Process Communication) 프로토콜은 알티베이스가 제공하는 프로토콜로서, 알티베이스 소개 13 공유메모리(shared memory)를 ?용하여 클라이?트와 서버 ?에 통?을 하도록 하였다. IPC 방법은 통? 패킷에 대하여 ?샬릿(marshaling)이 필요 없고 공유 메모리를 이용하기 때?에 다른 통? 프로토콜보다 빠른 통? 속도를 낼 수 있다. 클라이?트 프로그램과 알티베이스 서버가 상이? ?퓨터 시스템에 ?재하는 경우에는 ?터넷 소켓을 이용? TCP/IP 프로토콜을 사용하여야 하며, 이들이 동? ?퓨터 시스템에 ?재하는 경우에는 도메? 소켓을 이용? 프로토콜이나 IPC 프로토콜을 사용? 수 있다. 각각의 통? 프로토콜에 대? 성능은 IPC, 도메? 소켓, ?터넷 소켓 순으로 IPC가 가장 빠르다. 데이터베이스 공간 알티베이스 데이터베이스는 데이터베이스의 모? 데이터를 모아 저장하는 하나 이상의 테이블스페이스로 구성되고, 테이블스페이스는 크게 메모리 공?과 디스크 공?으로 나누어?다. 알티베이스가 생성하는 시스템 테이블스페이스 외에 사용자가 메모리와 디스크 각각의 공?에 테이블스페이스를 추가? 수 있다. Direct-Path INSERT Direct-Path INSERT는 데이터를 입력? 때 페이지의 빈 공?을 찾아 들어가는 대? 새로? 페이지를 ?들어 데이터를 입력?다. 즉 데이터를 입력? 때 테이블의 빈 공?(free space)을 사용하지 않고, 테이블스페이스로부터 익스?트(extent)를 새로 ?당받는다. 또? 버퍼 관리자를 사용하지 않고, ?용 버퍼(Private Buffer)를 사용하기 때?에 버퍼 공?에 대하여 여러 트?잭?과의 경합을 ??다. 그리고 INSERT를 APPEND 방식으로 수행하여 리두(Redo) 및 ?두(Undo)를 하지 않거나 ?여 로깅에 들어가는 비용을 ??다. 데이터베이스 링크 알티베이스 데이터베이스 릿크는 지역적으로 분리되어 있으나, 네트워크로 연결된 이기종의 데이터 서버들을 연동하여 개별 데이터들을 통합? 하나의 결과를 생성? 수 있게 ?다. 14 Administrators Manual iSQL 알티베이스는 iSQL을 이용? 데이터베이스를 관리? 수 있어 빠르고 ?편하게 데이터베이스를 관리? 수 있다. Audit 알티베이스는 Audit 기능을 통? 두 데이터베이스를 테이블 단위로 비교, 검사하여 데이터?의 불?치 정보를 출력하는 기능과 불?치가 발생? 경우 두 데이터베이스를 ?치시키는 기능 등을 제공?다. iLoader 알티베이스는 iLoader 유틸리티를 제공하여, 데이터베이스의 이?이나 테이블 단위의 백업 등을 ? 때 테이블 단위로 데이터를 다?로드하거나 업로드? 수 있도록 지원?다. 알티베이스 소개 15 알티베이스 구조 본 ?에서는 알티베이스의 클라이?트-서버 구조를 중심으로 ? ?체 구성도, 서버 프로세스 내부 구조, 데이터베이스 구조에 관하여 살펴본다. ?체 구성도 알티베이스의 ?체 구성은 데이터 저장 관리자와 질의 처리기로 구성된 서버 부분과 응용 프로그램 작성을 위? 클라이?트 라이브러리, 그리고 이들 ?의 통? 모듈로 구성되어 있다. Physical Memory Integrated Storage ManagerIntegrated Storage Manager Recovery Manager Buffer Manager Integrated Query ProcessorIntegrated Query Processor ParserOptimizerExecutor Index Manager E/SQLCLIODBCJDBC IPCUnix Domain SocketTCP/IP Transaction Manager Stable Storage Checkpoint Image Log BufferDisk BufferMemory Tablespace Stable LogDisk Tablespace Application [그림 1-3] 알티베이스 구성도 16 Administrators Manual 서버 프로세스 내부 구조 알티베이스 서버 프로세스의 내부 구조를 보면 메? 쓰레드, 서비스 데몬 쓰레드, 체크 포?트 쓰레드, 세? 관리 쓰레드, 가비지 콜렉? 쓰레드, 로그 플러시 쓰레드, 버퍼 플러시 쓰레드 그리고 아카이브로그 쓰레드가 있다. 각각의 쓰레드는 다음과 같은 ?을 수행?다. 메인 쓰레드 모? 쓰레드를 생성/종료시키고 생성? 쓰레드들을 관리?다. 서비스 데몬 쓰레드 클라이?트의 연결 요청이 있으면, 서비스 쓰레드 풀(pool)에서 대기 상태에 있는 서비스 쓰레드와 요청? 클라이?트를 연결시킨다. 서비스 쓰레드 풀 서버가 구동되면 설정(configuration) 정보에 명시된 값?큼 서비스 쓰레드를 생성하여 서비스 쓰레드 풀에 저장?다. 서비스 쓰레드는 질의를 처리하는 쓰레드이다. 체크포인트 쓰레드 고장 복구 시에 ?의 양을 ?이기 위하여, 주기적 또는 임의로 현재의 데이터베이스 및 시스템에 대? 상황을 데이터파?에 기록하는 쓰레드이다. 세션 관리 쓰레드 클라이?트와 서비스 쓰레드 ?에 연결된 세?의 상태 즉, 이 세?이 단?되었지의 여부를 감시하는 쓰레드이다. 가비지 콜렉션 쓰레드 다중 버? 기법에서는 ? 데이터에 대? 필요없는 오래된 데이터가 생성될 수 있다. 가비지 콜렉? 쓰레드(garbage collection thread)는 이러? 데이터가 필요없게 된 순? 그 즉시 메모리 공?을 회수하여, 재사용? 수 있도록 조치를 취함으로서 메모리 사용의 효율성을 극대화?다. 알티베이스 소개 17 로그 플러시 쓰레드 로그 플러시 쓰레드(log flush thread)는 데이터베이스 내의 모? 트?잭?이 생성? 로그를 관리하고, 로그 버퍼에 모여? 다량의 로그 데이터를 로그 디스크에 반영하는 기능을 ?다. 디스크에 완?히 반영(sync)된 로그는 데이터베이스 시스템의 장애 및 재? 발생 시에 데이터베이스를 ??하게 복구하는데 사용된다. 버퍼 플러시 쓰레드 버퍼 풀의 모? 메모리가 사용 중이면 디스크 I/O를 발생시켜서 수행중? 트?잭?에 성능 상의 기복(Jitter) 현상을 ?으키게 된다. 버퍼 플러시 쓰레드는 주기적으로 버퍼를 체크하여 ?정 양 이상의 가용 버퍼 메모리를 핫시 유지하도록 하며, 사용하지 않는 페이지를 디스크에 내리고 메모리를 사용 가능하게 ?드는 역?을 ?다. 아카이브로그 쓰레드 매체 오류에 대? 복구를 지원하기 위? 주기적으로 온라? 로그 파?들을 프로퍼티에 지정된 위치로 복사하는 쓰레드이다. 복사? 경로는 ARCHIVE_DIR 프로퍼티로 지정하면 된다. 알티베이스가 아카이브 모드로 ?영될 때? 동작?다. ...... ...... [그림 1-4] 알티베이스 프로세스의 내부 구조 데이터베이스의 물리적 구조 알티베이스 데이터베이스는 물리적으로 로그앵커 파?, 로그 파?, 18 Administrators Manual 데이터 파?로 구성되어 있다. 로그앵커 파일 로그앵커 (loganchor) 파?은 데이터 파?과 로그와의 관계를 나타내는 중요? 정보를 포함?다. 이는 로그를 기?으로 ? 시점에서 데이터 파?의 총체적? 정보를 나타낸다. 이 파?은 데이터 파?과 함께 중요? 백업 대상이다. 로그 파일 로그 파?(“리두 로그 파?”로 불리기도 함)은 트?잭?의 원자성(Atomicity)과 영속성(Durability)을 유지하기 위? 사용된다. 원자성은 트?잭?의 철회(rollback)를 통? 트?잭? 수행 이?의 상태로 복귀? 수 있도록 하는 것이고, 영속성은 정상적으로 종료(commit)된 트?잭?이 다양? 데이터베이스 장애로부터 원래의 내용을 복구? 수 있도록 하는 것이다. 로그 파?은 prepare 로그 파?과 active 로그 파?, archive 로그 파?로 구분? 수 있다. active 로그 파?은 실행중? 트?잭?의 로그가 기록되는 로그파?이다. Prepare 로그 파?은 로그 기록 성능을 향상시키기 위? 미리 ?들어지는 로그 파?로 실제 로그가 기록되기 ?까지는 비어있는 상태이다. archive 로그 파?은 복구를 위하여 백업된 로그 파?로 기록이 완료된 로그 파?들이다. 로그 파?은 현재의 데이터베이스 상태를 가지는 매우 중요? 파?로서, ?? 현재 로그 파?이 손상을 입었을 경우 당시 작업의 유무에 관계없이 데이터베이스 ?체가 손상을 입게 된다. 기? 로그 파?은 ?반적으로 데이터 파?이 손상될 경우 백업 파?과 함께 데이터베이스를 복구하는데 사용된다. 데이터 파일 데이터 파? 중 SYS_TBS_MEM_DATA에는 기본으로 생성되는 시스템 메모리 테이블스페이스가 저장되며, SYS_TBS_MEM_DIC에는 메타 테이블들이, system.dbf 파?에는 기본으로 생성되는 디스크 테이블스페이스 (SYS_TBS_DISK_DATA)가 저장된다. 또? temp.dbf 파?에는 쿼리 수행 시 중? 결과들이 저장되는 임시 테이블스페이스가 저장되며, undo.dbf 파?에는 다중버? 기법(MVCC: Multi-Version Concurrency Control)에서 사용되는 이? 이미지 정보들이 저장되는 ?두 테이블스페이스가 저장된다. 알티베이스 소개 19 알티베이스는 페이지 단위로 데이터파? 내에서 저장 공?을 관리?다. 페이지는 데이터베이스에 의? 사용되는 데이터의 가장 작은 단위이다. 페이지는 데이터베이스를 관리하기 위? 정보를 담고 있는 카탈로그 페이지와 사용자 데이터를 저장하는 데이터 페이지로 나누어 ?다. 카탈로그 페이지는 현재 생성된 데이터베이스에 대? 상세? 명세를 담고 있으며, 알티베이스의 구동 및 종료 시 데이터베이스의 ?관성 검사에 사용된다. 카탈로그 페이지는 데이터베이스에서 사용되는 자기 자?을 제외? 나머지 데이터 페이지에 대? 리스트 및 사용정보를 담고 있으며, 백업 데이터베이스의 가장 첫 번째 페이지에 위치하고 있는 매우 중요? 페이지 영역이다. 데이터 페이지는 실제로 사용자 데이터가 저장되는 영역이며, 페이지 헤더와 페이지 본체(body)로 나누어?다. 페이지 헤더는 서로 ?의 리스트를 유지하기 위? 릿크 정보와 타입, 그리고 자기 자?의 페이지 번호로 구성되어 있다. 페이지 본체는 여러 개의 슬롯으로 분?된다. 이 슬롯이 실제 데이터가 저장되는 최종 저장소이다. 데이터베이스 논리적 구조 알티베이스는 논리적으로 메모리와 디스크 테이블스페이스 내에 데이터를 저장하고, 물리적으로는 ?당 테이블스페이스와 관?된 데이터파? 내에 저장?다. 알티베이스 데이터베이스를 구성하는 각각의 테이블스페이스는 하나 이상의 데이터파?로 구성된다. 단, 하나의 데이터파?은 하나의 테이블스페이스에? 소속된다. 데이터베이스, 테이블스페이스 그리고 데이터파?은 밀접? 관계가 있으며 이 관계를 정리하면 다음과 같다. 데이터베이스는 논리적으로 테이블스페이스라는 저장 단위로 구성되어 있다. 즉, 테이블스페이스는 데이터베이스의 모? 데이터를 저장하는 논리적? 공?이다. 데이터베이스는 물리적으로 데이터파?이라고 불리는 하나 이상의 파?들로 구성된다. 즉 데이터파?은 데이터베이스의 모? 데이터를 저장하는 물리적 공?이다. 다음 그림은 테이블스페이스와 데이터파?의 관계를 설명?다. 20 Administrators Manual DATABASE TABLESPACE A TABLESPACE B TABLESPACE C DATAFILE 1 1 DATAFILE 2 2 DATAFILE 3 DATAFILE 4 4 DATAFILE 5 5 DATAFILE 6 DATAFILE 7 7 DATAFILE 8 8 DATAFILE 9 [그림 1-5] 데이터베이스 논리적 구조 알티베이스는 데이터베이스 내의 모? 데이터에 논리적 데이터베이스 영역? 테이블스페이스를 ?당?다. 데이터베이스 영역 ?당의 단위로는 페이지(page), 익스?트(extent) 그리고 세그먼트(segment)가 있다. 페이지는 가장 작은 논리적 저장 단위로, 모? 데이터는 페이지 내에 저장된다. 페이지의 논리적? 다음 단계는 익스?트이다. 즉 ?정 개수의 연속적? 페이지들이 모여서 익스?트라는 데이타베이스 영역을 형성?다. 익스?트 상위의 논리적 데이터베이스 저장 단계를 세그먼트라고 ?다. 하나의 세그먼트는 ??의 익스?트의 집합이며, ? 세그먼트 내의 모? 익스?트는 같은 테이블스페이스에 저장된다. 자세? 내용은 Administrator’s Manual을 참조?다. 기타 제어 파일들 부트 로그 파일 (altibase_boot.log) 알티베이스 서버가 동작된 상태를 기록?다. 이 파?이 기록하고 있는 정보로는 알티베이스 구동 및 종료 시 얻어지는 시스템 정보에 대? 세부사핫이 있으며, 또? 알티베이스의 비정상 종료 시 알티베이스의 오류 발생 상태를 기록?다. 알티베이스 소개 21 프로퍼티 파일 (altibase.properties) 알티베이스 서버의 ?경 설정을 위? 파?이며 알티베이스 서버의 ?용 방식과 튜닝에 관? 모? 구성 요소를 포함하고 있다. 에러 메시지 파일 데이터 저장 관리 모듈, 질의 처리 모듈, 알티베이스 서버 메? 모듈, 그리고 함수 실행이나 데이터 타입과 관?된 오류 메시지를 수록? 파?이다. 알티베이스 구성요소 23 2. 알티베이스 구성요소 이 장에서는 알티베이스의 주요 구성요소에 대?서 설명?다. 사용자는 알티베이스 패키지 설치 후에 실행 바이너리 부?과 프로그래밍 라이브러리 부? 등의 구성요소에 대?서 확?? 수 있다. 24 Administrators Manual 알티베이스 디렉토리 알티베이스를 설치하면 다음의 디렉토리가 생성된다. 알티베이스 홈 디렉토리는 ?경 변수 ALTIBASE_HOME에 지정된다. 이 홈 디렉토리는 bin, conf, lib, include, msg, dbs, logs, sample, install, audit, trc, admin, 그리고 arch_logs 디렉토리를 포함하고 있다. 각 디렉토리의 역?과 포함하는 내용에 관하여 설명?다. admin 디렉토리 알티베이스 시스템 정보와 관?된 view를 생성하는 adminview.sql 파?과 프로시져, 테이블 정보를 볼 수 있는 프로시져를 생성하는 SQL 파?들이다. arch_logs 디렉토리 복구를 위? 로그 파?을 백업하는 백업 디렉토리이다. 이 디렉토리의 위치 및 디렉토리 이름은 프로퍼티 파?에 명시? 수 있다. audit 디렉토리 이중화 동작 시 발생? 데이터베이스?의 데이터 불?치를 ?결하는 알티베이스 유틸리티? audit의 예제 스크립트 파?이 들어있는 디렉토리이다. 자세? 설명은 Audit User’s Manual을 참조?다. bin 디렉토리 알티베이스를 포함? 알티베이스 관리도구와 알티베이스를 사용하는데 필요? 지원 도구들의 실행 파?이 ?재하는 디렉토리이다. bin 디렉토리에는 다음과 같은 파?이 ?재?다. 각각의 유틸리티에 대? 자세? 설명은 Utilities Manual을 참조?다. 알티베이스 구성요소 25 aexport, altibase, altierr, altimon, altipasswd, altiPofile, audit, checkServer, dumpla, dumplf, iloader, isql, killCheckServer, server, apre, shmutil conf 디렉토리 알티베이스 HDB 라이선스 파? 및 알티베이스 HDB가 취? 수 있는 다양? 옵?을 수록? 프로퍼티 파?(altibase.properties)이 ?재하는 디렉토리이다. 알티베이스 HDB 서버가 실행될 때 라이선스를 확?하고, 프로퍼티 파?을 참조하여 서버 상태를 초기화?다. 알티베이스의 프로퍼티에 대? 자세? 설명은 General Reference를 참조?다. dbs 디렉토리 기본 프로퍼티를 이용? 경우 데이터베이스의 파?들이 생성되는 디렉토리이다. 이 디렉토리의 위치 및 디렉토리 명은 프로퍼티에 명시되어 있다. SYS_TBS_MEM_DATA 파?에는 기본으로 생성되는 시스템 메모리 테이블스페이스가, SYS_TBS_MEM_DIC 파?에는 메타 테이블이, system001.dbf 파?에는 기본으로 생성되는 디스크 테이블스페이스, temp001.dbf 파?에는 쿼리 수행 시 필요? 임시 결과들이 저장된다. undo001.dbf 파?에는 SQL? 수행과 복구에 필요? 이? 이미지 정보들이 저장된다. .dwf 파?은 더블 라이트 버퍼 파?로서 디스크 페이지가 임시로 저장된다. include 디렉토리 ODBC 라이브러리를 이용하여 응용 프로그램을 작성? 때 필요? 헤더 파?을 수록? 디렉토리이다. alaAPI.h 알티베이스 로그 분석기(ALA)에서 사용하는 API 헤더 파?이다. 26 Administrators Manual sqlcli.h 클라이?트 응용 프로그램을 작성? 때 필요? 헤더 파?이다. sqltypes.h ODBC 응용 프로그램 개발시 필요? 기초 데이터 타입에 대? 정보를 담고 있다. sqlucode.h 유니코드 정의 헤더 파?이다. ulpLibInterface.h C/C++ ?처리기(Precompiler)로 응용 프로그램 개발시 오류 처리 SQL ?장 구조에 대? 정보를 담고 있다. install 디렉토리 알티베이스 응용프로그램 작성에 필요? makefile을 위? 매크로 설정 등이 포함된 altibase_env.mk 파?과 README 파?이 있다. lib 디렉토리 응용 프로그램 작성에 필요? 라이브러리를 수록? 디렉토리이며 다음과 같은 파?을 갖고있다. 각각의 라이브러리를 이용하여 응용 프로그램을 작성하는 방법은 Getting Started Guide에서 설명?다. Altibase.jar 알티베이스를 자바 응용프로그램에서 사용하기 위? JDBC 드라이버이다. 순수 자바 ?어로 구현된 Type 4 드라이버이다. libapre.a 내장 SQL 프로그램을 작성? 때 필요? 라이브러리이다. 내장 SQL 프로그램 작성에 관? 자세? 내용은 Precompiler User’s Manual을 참조?다. 알티베이스 구성요소 27 libodbccli.a 알티베이스 클라이?트-서버용 응용프로그램 작성을 위? 라이브러리이다. logs 디렉토리 로그앵커 파?들과 로그 파?들이 ?재하는 디렉토리다. 이 디렉토리의 위치 및 디렉토리 명은 프로퍼티 파?에 명시? 수 있다. 로그앵커 파?명과 로그 파?명은 알티베이스 시스템에 의? 자동으로 결정된다. 로그 앵커를 가? 파? 시스템의 오류에 대비하기 위?서는 프로퍼티를 변경하여 여러 개의 로그 앵커 파?들을 각각 서로 다른 파? 시스템에 두어 관리하는 것이 좋다. msg 디렉토리 오류 메시지를 수록? 파?들을 포함하는 디렉토리다. 다음과 같은 파?이 있다. 오류 메시지는 영?? 제공된다. E_SM_US7ASCII.msb 자료 저장 관리 모듈에서 발생? 수 있는 오류 메시지를 수록? 파?이다. E_QP_US7ASCII.msb 질의 처리 모듈에서 발생? 수 있는 오류 메시지를 수록? 파?이다. E_MM_US7ASCII.msb 알티베이스 서버의 메? 모듈에서 발생? 수 있는 오류 메시지를 수록? 파?이다. E_CM_US7ASCII.msb 알티베이스 통? 모듈에서 발생? 수 있는 오류 메시지를 수록? 파?이다. 28 Administrators Manual E_RP_US7ASCII.msb 알티베이스 이중화 모듈에서 발생? 수 있는 오류 메시지를 수록? 파?이다. E_ST_US7ASCII.msb 알티베이스 공? 데이터 처리 모듈에서 발생? 수 있는 오류 메시지를 수록? 파?이다. E_ID_US7ASCII.msb, E_MT_US7ASCII.msb 함수 실행이나 데이터 타입과 관?된 오류 메시지를 수록? 파?이다. sample 디렉토리 알티베이스의 응용 프로그램을 샘플로 제공? 디렉토리다. JDBC, ODBC, C/C++ ?처리기(precompiler) 라이브러리를 이용하여 작성된 프로그램과 Makefile이 수록되어 있다. trc 디렉토리 알티베이스 ?영 상태를 기록? 파?들이 ?재?다. 서버내의 가 모듈은 ?당하는 트레이스 파?에 기록?다. altibase_boot.log 알티베이스 서버가 동작된 상태를 기록하고 있다. 이 파?이 기록하고 있는 정보로는 알티베이스 구동 및 종료시 생성되는 시스템 정보에 대? 세부사핫이 있다. 또? 알티베이스의 비정상 종료시 알티베이스의 오류 발생 상태를 기록?다. altibase_id.log 시스템 레벨에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파?들이다. 알티베이스 구성요소 29 altibase_sm.log 저장관리자 모듈에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파?들이다. altibase_mt.log 데이터 타입 및 빌트? 함수 모듈에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파?들이다. altibase_rp.log 이중화 모듈에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파?들이다. altibase_qp.log 질의 처리 모듈에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파?들이다. altibase_mm.log 메? 모듈에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파?들이다. altibase_IPC.log IPC로 접속시 생성된 자원(resource)들에 대? 정보가 기록되는 파?이다. 30 Administrators Manual 실행 바이너리 여기에 설명된 외의 이들 바이너리 파?에 대? 더 자세? 정보는 Utilities Manual을 참고하기 바?다.. aexport 알티베이스 버?을 업그레이드? 때 필요? ??의 작업들을 수행? 수 있는 도구로, 업그레이드를 위? SQL 스크립트 파?, iSQL 실행 쉘 파?, iLoader 실행 쉘 파?을 자동으로 ??다. altibase 클라이?트-서버 구조로 ?영? 때의 서버이다. altierr 오류 코드에 대? 세부 내용을 검색하여 출력?다. altimon.sh 알티베이스의 동작 상태를 모니터릿하는 쉘 스크립트 프로그램이다. altiProfile SQL ?의 통계정보(수행 횟수, 수행 시?)를 수집하는 도구이다. altipasswd sys 계정의 패스워드를 변경하기 위? 도구이다. audit 알티베이스 구성요소 31 audit은 두 데이터베이스를 테이블 단위로 비교, 검사하여 불?치 정보를 출력하는 기능과 불?치가 발생? 경우 두 데이터베이스를 ?치시키는 기능 등 두 가지를 제공?다. 이에 대? 자세? 내용은 Audit User’s Manual을 참조?다. checkServer 알티베이스의 상태를 체크하여 비정상 종료시 수행?야 ? ?을 스크립트 파?로 ?들어 실행? 수 있도록 ?다. dumpla 알티베이스 로그앵커 파?의 내용을 출력 및 검사?다. dumplf 알티베이스 로그 파?의 내용을 출력 및 검사?다. dump_stack.sh 알티베이스 비정상 종료시 프로세스의 콜 스택을 출력?다. iloader 데이터베이스의 특정 테이블을 로드 및 ?로드? 수 있는 도구이다. 이 도구에 대? 자세? 내용은 iLoader User’s Manual을 참조?다. isql 대화형으로 알티베이스 데이터베이스 질의를 수행? 수 있는 도구이다. 이 도구에 대? 자세? 내용은 iSQL User’s Manual을 참조?다. 32 Administrators Manual killCheckServer 실행중? checkServer를 종료시킨다. server 알티베이스의 구동 및 종료, 재시작 등의 동작을 수행? 수 있도록 작성된 쉘 스크립트 프로그램이다. apre 내장 SQL?을 사용하여 응용 프로그램을 작성? 후, 작성된 응용 프로그램을 ?처리(precompile)하기 위? ?처리 실행 파?이다. 자세? 설명은 Precompiler User’s Manual을 참조?다. shmutil 공유메모리 데이터베이스 관리 도구이다. 알티베이스의 공유 메모리를 메? 메모리 데이터베이스로 사용하는 경우, shmutil로 공유메모리에 관?된 관리 작업을 ?다. * 구체적? 참조 매뉴얼을 명시하지 않은 실행 파?은 Utilities Manual을 참조?다. 알티베이스 구성요소 33 알티베이스 라이브러리 알티베이스의 응용 프로그램을 작성? 때 필요? 구성 요소들로서, 다음과 같은 것들이 있다. C 또는 C++ ?어로 프로그램을 작성? 때 필요? 라이브러리 ODBC ?터페이스를 제공하는 라이브러리 (libodbccli.a) MS-Windows ?경에서 ODBC 프로그래밍? 수 있는 ODBC 드라이버 (altibase_odbc.dll) 자바 ?어로 프로그래밍? 때 필요? 자바 클래스 라이브러리 (Altibase.jar) 프로그래밍에 필요? 헤더 파?들 이에 대?서는 Getting Started Guide에서 자세히 설명?다. 데이터베이스 생성 35 3. 데이터베이스 생성 알티베이스 설치 후에 데이터베이스 관리자는 사용자 데이터 발생량을 예측하여 데이터베이스를 생성하고 관리?야 ?다. 이 장에서는 데이터베이스 생성시에 알고 있어야 ? 주요사핫들에 대?서 설명하고 있다. 36 Administrators Manual 데이터베이스 생성 알티베이스 데이터베이스는 데이터의 논리적 저장 단위? 테이블스페이스로 구성된다. 알티베이스는 데이터를 논리적으로는 테이블스페이스에, 물리적으로는 테이블스페이스에 대응하는 데이터파?에 저장?다. 데이터베이스 서버를 구동하기 ?에, 데이터베이스를 미리 생성시켜 놓아야 ?다. 여기에서는 테이블스페이스와 로깅 시스템의 종류 및 데이터베이스 생성 방법에 관하여 설명?다. 테이블스페이스의 종류 알티베이스의 데이터베이스는 여러 개의 테이블스페이스로 구성된다. 테이블 스페이스는 그 사용처와 데이터를 저장하는 방법에 따라서 여러 종류로 분류된다. 메모리 테이블스페이스 외의 각 테이블스페이스를 구성하는 파?들은 기본으로 *.dbf의 확장자를 가지며, CREATE DATABASE 시에 생성되는 파?의 위치는 $ALTIBASE_HOME/dbs/ 이다. Note: 사용자가 테이블스페이스를 생성하거나 테이블스페이스에 파?을 추가? 때 명시하는 파?의 확장자와 파?의 경로에는 제?이 없다. 알티베이스에서 제공하는 기본 테이블스페이스는 아래와 같다. 메모리 테이블스페이스 메모리 테이블스페이스는 메모리에 ?재?다. 딕셔너리 테이블들과 메모리 테이블들, 그리고 이에 관?된 다양? 데이터베이스 객체들이 저장되는 테이블스페이스이다. 데이터 테이블스페이스 디스크 테이블들과 ?덱스들이 저장되는 테이블스페이스이다. 이는 다시 시스템 데이터 테이블스페이스와 사용자 데이터 테이블스페이스로 구분된다. ?두 테이블스페이스(Undo Tablespace) 디스크 테이블에 ?재하는 레코드들의 다중버? 동시성 제어 (MVCC: Multi-Versioned Concurrency Control)를 위? 변경 이? 데이터베이스 생성 37 이미지를 ?정 기? 동? 저장?두는 테이블스페이스 이다. 임시 테이블스페이스(Temporary Tablespace) 질의를 처리하는 과정에서 발생되는 임시 테이블들과 ?덱스들을 저장하는 테이블스페이스이다. 데이터 테이블스페이스와 ??가지로 시스템 임시 테이블스페이스와 사용자 임시 테이블스페이스로 나뉜다. 휘발성 테이블스페이스(Volatile Tablespace) 디스크 입출력을 하지 않고, 메모리에 객체를 저장하는 테이블스페이스이므로 보다 빠른 성능이 보장된다. 데이터베이스 서비스 종료시 모? 휘발성 데이터 객체들이 사라?다. 휘발성 테이블스페이스의 크기는 시스템의 사용 가능? 물리적 메모리 공?을 초과? 수 없다. 로깅 시스템 데이터베이스 내의 데이터들은 어떤 상황 하에서도 영속성 (Durability)을 가져야 ?다. 알티베이스는 다음의 두 가지 파?들로 로깅 시스템을 구성하여 데이터의 영속성을 보장?다. 로그 파? 트?잭? 수행 중에 발생? 수 있는 비정상 종료에 대비하여 시스템 복구 (system recovery)를 ? 수 있도록 작성되는 로그 레코드들을 기록하는 파?들이다. 로그 파?의 이름은 logfile**이다 (**은 로그 파?의 ?? 번호이다). 로그 앵커(Log Anchor) 파? 테이블스페이스들에 대? 정보와 데이터파?들의 위치, 체크 포?트 관? 정보 등 서버 ?용에 관?된 중요? 데이터가 저장된 파?이다. 서버가 정상적으로 구동 되려면 이 파?의 내용이 유효하여야 하며, 그렇지 않을 경우에는 서버를 구동 시킬 수 없다. 또? 로그 앵커 파?은 데이터베이스 복구시에도 사용된다. 최초 데이터베이스 생성시 로그 파?과 로그 앵커 파?들은 $ALTIBASE_HOME/logs/ 위치에 생성된다. 알티베이스는 이 로그 앵커 파?들을 3개로 유지하며, 데이터베이스 생성 시 로그 파?들과 같은 위치에 생성되지?, 3개의 로그 앵커 38 Administrators Manual 파?들을 서로 다른 파? 시스템에 두기를 권장하고 있다. 로그 앵커 파?의 위치에 관?된 프로퍼티는 LOGANCHOR_DIR 이다. 이 프로퍼티에 대? 자세? 설명은 Getting Started Guide을 참고하기 바?다. 데이터베이스 생성 준비 데이터베이스를 생성하려면 알티베이스 패키지에 제공되는 iSQL유틸리티를 사용?다. 먼저 iSQL 유틸리티를 SYSDBA 모드로 실행?다. $ isql -u sys -p manager -sysdba 이는 알티베이스가 실행되어 있지 않은 경우에는 데이터베이스에 접속하지 않고 isql을 관리자 모드 (admin mode)로 띄우는 것이며, 실행 결과는 아래와 같다. ------------------------------------------------ Altibase Client Query utility. Release Version 6.1.1.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. ------------------------------------------------ ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 iSQL(sysdba)> 위의 상태가 되면 ?단 CREATE DATABASE 명령을 수행하기 위? 서버 프로세스를 구동 시켜야 ?다. 서버의 구동은 다음과 같은 순서로 이루어 ?다. 1. 1단계: Pre-Process 단계 서버를 구동하기 이? 단계로, 알티베이스는 데이터베이스 메모 리를 초기화?다. 데이터베이스의 생성은 Process 단계에서 가능하며, 이 단계에서 Process 단계로 가려면 다음의 명령을 실행?다. iSQL> startup process Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE: PROCESS Command execute success. 2. 2단계: Process 단계 CREATE DATABASE 구?으로 데이터베이스를 생성하거나 알티 베이스 프로퍼티들을 조회하고 변경? 수 있는 단계이다. 3. 3단계: Control 단계 데이터베이스 생성 39 데이터베이스 파?이 모두 로드되어 있는 상태의 단계이다. 또? 재시작 복구 (restart recovery)를 위? ?비도 완료된 단계이다. 재시작 복구에 대? 설명은 8장의 “데이터베이스 복구” ?을 참 고?다. 4. 4단계: Meta 단계 복구가 완료된 단계이다. 이 단계에서는 메타 데이터의 업그레이 드와 온라? 로그의 리셋 (reset)이 가능하다. 5. 5단계: Service 단계 사용자에게 서비스를 제공? ?비가 된 최종 단계이다. 데이터베이스 생성 Process 단계에서 데이터베이스를 생성하기 위? CREATE DATABASE 명령은 아래와 같이 수행?다. CREATE DATABASE 구?의 자세? 사용법은 SQL Reference를 참조?다. 여기서는 기본 옵?을 사용?서 데이터베이스를 생성하는 예를 보여주고 있다. iSQL> create database mydb initsize=50M noarchivelog character set ksc5601 national character set utf16; DB Info (Page Size = 32768) (Page Count = 1537) (Total DB Size = 50364416) (DB File Size = 1073741824) Creating MMDB FILES [SUCCESS] Creating Catalog Tables [SUCCESS] Creating DRDB FILES [SUCCESS] [SM] Rebuilding Indices [Total Count:0] [SUCCESS] DB Writing Completed. All Done. Create success. 데이터베이스 서버 종료 데이터베이스의 생성이 완료되면 이를 위? 띄웠던 서버를 종료하거나, 서비스 단계로 ?행? 수 있다. 서버의 종료는 다음과 같이 수행?다. iSQL(sysdba)> shutdown abort iSQL(sysdba)> 서버를 종료하면 isql은 다시 서버에 접속하지 않은 Pre-Process 상태가 되며, 서버 프로세스도 종료된다. shutdown 명령의 옵?으로는 abort외에 immediate와 normal이 더 있으나, 이들은 서버가 service 단계? 때? 수행이 가능하다. 40 Administrators Manual 데이터베이스 생성 관? 프로퍼티 CREATE DATABASE 구?을 수행? 때 지정하지 않은 속성들은 알티베이스 프로퍼티 파?의 설정에 의? 결정되는데, 그 파?은 $ALTIBASE_HOME/conf/altibase.properties이다. 관?있는 프로퍼티들은 아래와 같다. 표에서 물음표 (“?”)는 ?경변수 ALTIBASE_HOME에 설정된 경로를 가리킨다. 아래 표에 나열? 데이터베이스 초기화와 관?된 알티베이스 프로퍼티에 대? 완벽히 이?하기 바?다. 프로퍼티 이름 설명 기본값 DB_NAME 생성? 데이터베이스의 이름 mydb MEM_DB_DIR 데이터베이스 파?들이 위치? 디렉 터리. 최대 3개까지 지정? 수 있다. ?/dbs SERVER_MSGLOG_DIR 알티베이스 ?용 중 발생되는 서버의 메시지를 기록하는 파? (altibase_boot.log)이 위치하는 디 렉터리 ?/trc SHM_DB_KEY 공유 메모리 버?으로 알티베이스를 띄? 경우에 사용? 공유메모리의 키 값 0 (사용? 함) MEM_MAX_DB_SIZE ?체 메모리 테이블스페이스들의 최 대 크기 4G LOGANCHOR_DIR 로그 앵커 파?들이 위치? 디렉터 리. 최대 3개까지 지정? 수 있다 ?/logs LOG_DIR 로그 파?들이 위치? 디렉터리 ?/logs LOG_FILE_SIZE 로그 파? 하나의 크기 10M STARTUP_SHM_CHUNK_SIZE 알티베이스 구동 시 생성되는 공유메 모리 ? 개의 최대 크기 1G EXPAND_CHUNK_PAGE_COUNT ? 번에 ?당하는 메모리 테이블스페 이스 페이지의 개수 3200 TEMP_PAGE_CHUNK_COUNT ? 번에 ?당하는 메모리 테이블스페 이스 임시 페이지의 개수 128 SYS_DATA_TBS_EXTENT_SIZE 시스템 데이터 테이블스페이스의 익 스?트 ? 개의 크기 256K SYS_DATA_FILE_INIT_SIZE CREATE DATABASE 구? 실행 시 생성되는 시스템 테이블스페이스를 위? 데이터 파?의 최초 크기 100M SYS_DATA_FILE_MAX_SIZE 시스템 테이블스페이스의 데이터 파 ?의 최대 크기 2G 데이터베이스 생성 41 프로퍼티 이름 설명 기본값 SYS_DATA_FILE_NEXT_SIZE 시스템 테이블스페이스의 데이터 파 ?이 자동 확장될 때의 확장 크기 1M SYS_TEMP_TBS_EXTENT_SIZE 임시 테이블스페이스의 익스?트 ? 개의 크기 256K SYS_TEMP_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 임시 테이블스페이스를 위? 데 이터 파?의 최초 크기 100M SYS_TEMP_FILE_MAX_SIZE 임시 테이블스페이스의 데이터 파? 의 최대 크기 2G SYS_TEMP_FILE_NEXT_SIZE 임시 테이블스페이스의 데이터 파? 이 자동 확장될 때의 확장 크기 1M SYS_UNDO_TBS_EXTENT_SIZE ?두 테이블스페이스의 익스?트 ? 개의 크기 128K SYS_UNDO_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 ?두 테이블스페이스를 위? 데 이터 파?의 최초 크기 100M SYS_UNDO_FILE_MAX_SIZE ?두 테이블스페이스의 데이터 파? 의 최대 크기 2G SYS_UNDO_FILE_NEXT_SIZE ?두 테이블스페이스의 데이터 파? 이 자동 확장될 때의 확장 크기 1M USER_DATA_TBS_EXTENT_SIZE 사용자 데이터 테이블스페이스의 익 스?트 ? 개의 크기 256K USER _DATA_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 사용자 테이블스페이스를 위? 데이터 파?의 최초 크기 100M USER_DATA_FILE_MAX_SIZE 사용자 데이터 테이블스페이스의 데 이터 파?의 최대 크기 2G USER _DATA_FILE_NEXT_SIZE 사용자 데이터 테이블스페이스의 데 이터 파?이 자동 확장될 때의 확장 크기 1M USER_TEMP_TBS_EXTENT_SIZE 사용자 임시 테이블스페이스의 익스 ?트 ? 개의 크기 256K USER_TEMP_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 사용자 임시 테이블스페이스의 데이터 파?의 최초 크기 100M USER_TEMP_FILE_MAX_SIZE 사용자 임시 테이블스페이스의 데이 터 파?의 최대 크기 2G USER_TEMP_FILE_NEXT_SIZE 사용자 임시 테이블스페이스의 데이 터 파?이 자동 확장될 때의 확장 크1M 42 Administrators Manual 프로퍼티 이름 설명 기본값 기 ADD_EXTENT_NUM_FROM_TBS_ TO_SEG 세그먼트가 확장될 때 새로 ?당되는 익스?트의 개수 1 ADD_EXTENT_NUM_FROM_SYST EM_TO_TBS 테이블스페이스가 확장될 때 새로 ? 당되는 익스?트의 개수 4 프로퍼티에 대? 보다 자세? 내용은 General Reference를 참조하기 바?다. 알티베이스 구동 및 종료 43 4. 알티베이스 구동 및 종료 데이터베이스를 생성 후 서비스를 제공하기 위?서는 서버를 서비스 단계까지 구동하여야 ?다. 이 장에서는 데이터베이스 구동과 종료 시에 참고? 사핫들을 설명하고 있다. 44 Administrators Manual 알티베이스의 구동 알티베이스 서버를 구동하는 방법은 두 가지가 있다. 데이터베이스 관리자가 sys 계정으로 서버에 로그? 시 - sysdba 관리자로 서버에 접속하여 서버 구동 서버 스크립트 명령을 이용하여 서버 구동 알티베이스를 구동시키기 위?서는 데이터베이스 생성 시와 ??가지로 우선 isql을 -sysdba 옵?으로 실행?야 ?다. 다음은 iSQL을 -sysdba옵?으로 실행하는 것을 보여?다. $ isql -u sys -p manager -sysdba ---------------------------------------------- Altibase Client Query utility. Release Version 6.1.1.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. ---------------------------------------------- ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 iSQL(sysdba)> Note: STARTUP 명령어는 알티베이스 (isql 포함)를 설치? 유닉스 계정으로? 수행이 가능하다. 알티베이스를 구동하면, 알티베이스의 상태는 아래의 단계 순으로 ?이?다. 1. PRE_PROCESS 2. PROCESS 3. CONTROL 4. META 5. SERVICE STARTUP 명령어는 아래의 단계 옵?과 함께 사용? 수 있다. STARTUP [PROCESS | CONTROL | META | SERVICE]; SERVICE 상태가 되어야 SYS사용자를 제외? ?반 사용자들이 데이터베이스에 접?? 수 있다. Note: 알티베이스의 상태는 다음 상태로 ?행? ? 수 있으며, 이? 상태로 되돌아갈 수는 없다. SERVICE 상태로 ?이시키는 예는 아래와 같다. iSQL> startup service; Trying Connect to Altibase..... Connected with Altibase. TRANSITION TO PHASE: PROCESS 알티베이스 구동 및 종료 45 TRANSITION TO PHASE: CONTROL TRANSITION TO PHASE: META [SM] Checking Database Phase: .*.*.*[SUCCESS] [SM] Recovery Phase - 1: Preparing Database...[SUCCESS] [SM] Recovery Phase - 2: Loading Database : Dynamic Memory Version Serial Bulk Loading . is 8192k: *..[SUCCESS] [SM] Recovery Phase - 3: Skipping Recovery Threads...[SUCCESS] Refining Disk Table [SUCCESS] [SM] Garbage Collection: ....................................... [SUCCESS] [SM] Rebuilding Indices [Total Count:61] ****************..................... .................................................... [SUCCESS] TRANSITION TO PHASE: SERVICE No IPC Initialize: Disabled --- STARTUP Process SUCCESS --- Command execute success. 구동의 각 단계에서 사용자가 ? 수 있는 ?은 다음과 같다. 단계 가능? 작업 PRE-PROCESS PROCESS 단계로 ?이? 수 있다. PROCESS CREATE DATABASE구?으로 데이터베이스를 생성하거나 DROP DATABASE 구?으로 데이터베이스를 삭제? 수 있다. 제?된 개수의 성능 뷰들을 조회? 수 있다. 프로퍼티 값들을 변경시킬 수 있다. CONTROL 단계로 ?이? 수 있다. CONTROL 미디어 복구 (Media Recovery)를 수행? 수 있다. META 단계로 ?이? 수 있다. CONTROL 단계에서 불완? 복구를 ? 경우 META 단계로 ?이? 때 온라? 로그를 리셋(reset)?야 ?다. META 메타 데이터 (Dictionary table)를 업그레이드? 수 있다. SERVICE 단계로 ?이? 수 있다. SERVICE SYS사용자를 제외? ?반 사용자로부터 접속을 받을 수 있다. SHUTDOWN NORMAL/IMMEDIATE/ABORT 를 수행? 수 있다. 46 Administrators Manual 알티베이스의 종료 현재 구동중? 알티베이스 서버를 종료하려면 SHUTDOWN 구?을 사용?다. 아래의 옵?이 가능하다. SHUTDOWN [NORMAL | IMMEDIATE | ABORT]; SHUTDOWN NORMAL과 SHUTDOWN IMMEDIATE는 알티베이스가 SERVICE 상태? 때? 수행 가능하며, SHUTDOWN ABORT는 어떤 상태에서도 수행 가능하다. Note: SHUTDOWN 명령어는 알티베이스 (isql 포함)를 설치? 유닉스 계정으로? 수행이 가능하다. SHUTDOWN NORMAL 서버를 정상적으로 종료하는 방식이다. 서버는 모? 클라이?트들이 서버로부터 접속을 끊을 때까지 종료 작업을 대기?다. 서버 종료시 내부적으로 다음의 작업이 수행된다. 클라이?트-서버? 통? 세?을 감지하는 쓰레드의 종료 서비스 쓰레드의 종료 자료저장 관리자의 종료 ?지링으로 알티베이스 서버 프로세스가 완?히 종료되기를 대기하는 ?들을 수행함으로써 알티베이스 서버를 종료?다. 이 방식으로 알티베이스를 종료했을 때 다음과 같은 메시지가 출력된다. iSQL(sysdba)> shutdown normal; Ok..Shutdown Proceeding.... TRANSITION TO PHASE : Shutdown Altibase [RP] Finalization : PASS shutdown normal success. SHUTDOWN IMMEDIATE SHUTDOWN IMMEDIATE를 실행하면, 알티베이스 서버는 먼저 현재 연결된 세?들을 강제로 단?시킨 다음, 현재 실행 중이던 트?잭?들을 철회(rollback) 시키고 알티베이스 서버를 종료?다. 이 방식으로 알티베이스를 종료했을 때 다음과 같은 메시지가 출력된다. iSQL(sysdba)> shutdown immediate Ok..Shutdown Proceeding.... TRANSITION TO PHASE : Shutdown Altibase [RP] Finalization : PASS shutdown immediate success. 알티베이스 구동 및 종료 47 서버 스크립트 명령을 이용하여 서버를 종료? 수도 있다. $ server stop ----------------------------------------------- Altibase Client Query utility. Release Version 6.1.1.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. ----------------------------------------------- ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 Alter success. Alter success. Alter success. Ok..Shutdown Proceeding.... TRANSITION TO PHASE : Shutdown Altibase [RP] Finalization : PASS shutdown immediate success. SHUTDOWN ABORT SHUTDOWN ABORT는 알티베이스 서버를 강제로 죽?다. 이 방법으로 알티베이스 서버를 종료하면, 데이터베이스가 완?하지 못? 상태가 되어 다음에 알티베이스 서버를 구동? 때 데이터베이스 복구 과정을 거쳐야 ? 수도 있다. 이 방식으로 알티베이스를 종료했을 때 다음과 같은 메시지가 출력된다. iSQL(sysdba)> shutdown abort iSQL(sysdba)> 또는 서버 스크립트 명령을 이용? 수 있다. $ server kill -------------------------------------------------------- Altibase Client Query utility. Release Version 6.1.1.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. -------------------------------------------------------- ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 $ 데이터베이스 객체 및 권? 49 5. 데이터베이스 객체 및 권한 이장에서는 알티베이스 데이터베이스 내의 객체 관리 및 권? 관리 방법에 대?서 설명?다. 50 Administrators Manual 데이터베이스 객체 개요 데이터베이스 객체는 특정 스키?에 속하여 관리되는 스키? 객체와 스키?와 관계없이 데이터베이스 ?체에서 관리되는 비스키? 객체로 구분? 수 있다. 이 장에서는 스키? 객체와 비스키? 객체를 구분하고 각각에 포함되는 데이터베이스 객체에 대? 설명?다. 스키마 객체 스키?? 데이터 또는 객체들의 논리적 집합으로 ? 데이터베이스 사용자는 하나의 스키?를 소유하고 SQL?에 의? 관리된다. 이러? 스키?에 포함되는 객체를 스키? 객체라고 하고 알티베이스는 다음과 같은 스키? 객체를 제공?다. 테이블 (Table) 테이블은 가장 기본적? 데이터 저장 단위로써 테이블은 칼럼들로 구성된 레코드들의 집합이다. 알티베이스 테이블은 데이터의 저장 공?에 따라 메모리 테이블과 디스크 테이블로 구별되고, 생성자에 따라 시스템이 생성하고 관리하는 시스템 테이블과 사용자가 생성하는 사용자 테이블로 구별된다. 또? 이중화 대상 테이블의 경우 테이블 관리가 특별하며 대용량 테이블의 경우에도 주의를 요하는 사핫들이 있다. 이에 대?서는 테이블 관리에서 자세히 설명?다. 제약조건 (Constraint) 제약 조건이? 테이블의 데이터 삽입 또는 변경 시 데이터의 ?관성을 유지? 수 있도록 부과? 조건이다. 제약조건의 대상에 따라 칼럼 제약조건과 테이블 제약조건으로 구별? 수 있고, 제약 사핫에 따라 다음과 같은 종류의 제약조건을 제공?다. NOT NULL / NULL 제약조건 유? 키 (unique key) 제약조건 주 키 (primary key) 제약조건 외래 키 (foreign key) 제약조건 TIMESTAMP 제약조건 데이터베이스 객체 및 권? 51 인덱스 (Index) ?덱스는 특정 테이블에 선택적으로 생성하여 그 테이블 내 레코드들에 대? 빠른 접?이 가능하도록 ?다. 즉, DML?의 처리 성능을 향상시킬 수 있다. 뷰 (View) 뷰는 실제 데이터 자체는 포함하지 않고, 하나 이상의 테이블 또는 뷰를 기반으로 ? 논리적 테이블 (logical table)이다. 알티베이스는 변경가능 뷰 (Updatable view)와 머티어리얼라이즈 뷰 (materialized view)는 제공하지 않는다. 시퀀스 (Sequence) 알티베이스는 유? 키를 생성하기 위? 키생성자? 시퀀스를 제공?다. 시노님 (Synonym) 테이블, 시퀀스, 뷰, 저장 프로시저 및 저장 함수에 대? 별칭 (alias)을 부여하여 객체 사용에 대? 투명성을 보장? 수 있는 시노님을 제공?다. 저장 프로시저 및 저장 함수 (Stored Procedure or Function) 저장 프로시저 (Stored Prodedure)? SQL?들과 흐름 제어?, ?당?, 오류 처리 루틴 등으로 구성된 데이터베이스 객체이다. 이를 이용?서 ?체 업무 ?차를 프로그래밍하여 하나의 모듈로 ?? 후 데이터베이스에 영구적으로 저장? 두고, 모듈 이름?을 호출하여 ?체 업무 ?차를 서버에서 ?번에 수행하도록 하는 데이터베이스 객체이다. 하나의 리턴 값을 가지지 않느냐와 가지느냐에 따라 저장 프로시저와 저장 함수로 구별된다. 데이터베이스 트리거 (Database Trigger) 트리거? 테이블에 데이터가 삽입, 삭제, 또는 갱?될 때 시스템에 의? 작동되어 특정 작업 ?차를 자동으로 수행? 수 있도록 하는 저장 프로시저의 ? 종류이다. 사용자는 테이블에 대? 제약조건과 트리거를 정의하여 데이터의 ?관성을 유지? 수 있다. 52 Administrators Manual 데이터베이스 링크 (Database Link) 데이터베이스 릿크는 지역적으로 분리되어 있으나 네트워크로 연결된 데이터 서버들을 연동하여 그 데이터들을 통합?서 하나의 결과를 생성? 수 있게 ?다. 이에 대?서는 Database Link User’s Manual에 더 자세히 기술되어 있다. 비스키마 객체 특정 스키?에 소속되지 않고 ?체 데이터베이스 수?에서 관리되는 객체를 비스키? 객체라고 ?다. 알티베이스는 다음과 같은 비스키? 객체를 제공?다. 디렉터리 (Directory) 저장프로시저의 파? 제어 기능은 ?영 체제의 텍스트 파?에 대? 인기 및 쓰기 기능을 제공?다. 이 기능을 이용하여 사용자는 저장프로시저 실행에 대? 별도의 메시지 등을 파?에 남길 수도 있으며, 파?로 결과를 보고하거나 파?로부터 데이터를 인어와 테이블에 삽입하는 등 다양? 작업을 수행? 수 있다. 디렉터리 객체는 이러? 저장프로시저에서 접?하는 파?들이 저장되어 있는 디렉터리에 대? 정보를 관리하는데 사용된다. 디렉터리 객체에 대? 자세? 기능은 SQL Reference를 참고?다. 저장프로시저 내에서의 파? 제어 방법은 Stored Procedures Manual을 참고?다. 이중화 (Replication) 이중화는 시스템이 자동으로 ? 지역서버에서 원격 서버로 데이터를 ?송? 다른 서버들?의 테이블 데이터를 동?하게 유지? ? 수 있도록 하는 객체이다. 이중화 관리에 대?서는 Replication Manual을 참조?다. 테이블스페이스 (Tablespace) 테이블스페이스는 가장 큰 논리적 데이터 저장 단위로 데이터베이스는 여러 개의 테이블스페이스로 나뉘어져 관리된다. 데이터베이스 객체 및 권? 53 테이블스페이스는 저장공?을 기?으로 크게 메모리 테이블스페이스와 디스크 테이블스페이스로 구분된다. 각 데이터베이스는 시스템 테이블스페이스를 가지는데, 이는 데이터베이스 생성시에 자동으로 ?들어지며 사용자에 의? 삭제되지 않는다. 또 사용자는 필요에 따라 사용자 테이블스페이스를 자유롭게 생성하거나 삭제? 수 있다. 테이블스페이스 관리에 대? 자세? 내용은 “5장 테이블스페이스 관리”를 참조?다. 사용자 (User) 사용자 계정은 알티베이스 접속을 위? 필요하며, 스키?의 소유자이기도 하다. 사용자는 시스템에 의? 생성되며, ?체 시스템 관리자? 시스템 사용자와 ?반 사용자로 구분된다. ?반 사용자의 경우 데이터베이스에 접?하여 데이터를 조작하기 위?서는 적?? 권?이 필요?다. 54 Administrators Manual 테이블 테이블은 가장 기본적? 데이터 저장 단위이다. 테이블은 칼럼들로 구성되며 레코드들을 포함?다. 이 ?에서는 테이블과 관?된 용어를 정의하고 테이블 관리 개념과 방법들에 대? 설명?다. 메모리 테이블과 디스크 테이블 테이블의 저장 공?에 따라 메모리 테이블과 디스크 테이블로 분류된다. 테이블 생성 시 그 테이블이 속? 테이블스페이스가 메모리 테이블스페이스?지 디스크 테이블스페이스?지에 따라서 메모리 테이블 또는 디스크 테이블이 된다. 시스템 테이블과 사용자 테이블 또? 테이블은 시스템이 내부적으로 생성하고 관리하는 시스템 테이블과 사용자에 의? 생성되고 관리되는 사용자 테이블로 분류된다. 데이터 딕셔너리로 알려? 시스템 테이블은, 데이터베이스 객체 정보를 저장하는 메타 테이블과 시스템 프로세스 정보를 저장하는 프로세스 테이블로 분류된다. 프로세스 테이블은 다시 고정 테이블 (fixed table)과 성능 뷰 (performance view)로 분류된다. 메타 테이블과 성능 뷰에 대?서는 General Reference를 참고?다. 대용량 메모리 테이블 대용량 메모리 테이블에 대? SQL? 수행 시 다음과 같은 주의를 요?다. 대용량 메모리 테이블에 DDL 수행하기 대용량 테이블에 DDL ?을 수행하고자 하는 경우, 그 테이블에 ADD COLUMN 또는 DROP COLUMN을 직접 수행하는 것 보다 iLoader 유틸리티를 이용?서 데이터를 다?로드 받고 그 테이블은 삭제하고 새로? 스키?로 그 테이블을 재 생성? 후에 다?로드 받은 데이터를 iLoader 유틸리티를 이용?서 업로드하는 방식을 권장?다. 데이터베이스 객체 및 권? 55 대용량 메모리 테이블에 DML 수행하기 데이터 크기가 크지 않은 테이블에 대? DML을 수행하는 것은 ?영자가 잘못된 데이터 조작을 하지 않는 ? 알티베이스의 성능이나 ?용 상에 있어서 크게 ?제를 발생시키지 않는다. 그러나 하나의 UPDATE 또는 DELETE ? 수행이 아주 ?은 수의 레코드에 영향을 미?다면, 그 DML을 수행하는 트?잭?은 오? 시? 동? ?행 중? 상태로 있을 수 있다. 이처럼 오? 시? 동? ?행 중? 트?잭? (long-duration transaction)이 ?재하는 경우 알티베이스를 ?용함에 있어 다음과 같은 심각? ?제를 야기? 수 있다. 테이블에 대? 배타적 접? 트?잭?의 수행 시?이 길어지면 그 트?잭?이 획득하고 있는 잠금 (lock) 때?에 그 테이블에 접?하고자 하는 다른 트?잭?들은 모두 수행을 멈추게 된다. 또? 변경되는 레코드들의 ?체 양이 LOCK_ESCALATION_MEMORY_SIZE 프로퍼티에 지정? 값 이상이 되면 lock escalation이 발생하므로, 검색? 하는 트?잭?이라 하더라도 그 테이블에 대? 접?? 수 없는 경우가 발생? 수도 있다. 알티베이스 메모리 사용량 증가 알티베이스에서 사용되는 모? 레코드 (버?)에는 garbage collector가 삭제?야 ? 레코드들을 구분하기 위? SCN (System Commit Number)이 사용된다. 커밋되지 않은 트?잭?이 사용하고 있는 SCN보다 작은 SCN을 가지는 레코드에 대?서? garbage collector는 삭제 작업을 수행?다. 그러므로, 장기? 수행 중? 트?잭?이 ?재하면 garbage collector는 자?이 처리?야 ? 레코드가 없는 것으로 ?주하고 레코드 삭제 작업을 수행하지 않는다. 따라서, bulk update/delete를 장기? 수행하는 트?잭?이 ?재하는 경우 garbage collector의 동작이 멈추게 되어 불필요? 버?이 계속 쌓이는 현상이 발생하며, 이에 따라 데이터베이스의 크기와 알티베이스 메모리 사용량이 증가하게 된다. 로그 파?의 축적 트?잭?이 생성하는 로그 파?들은 이중화 또는 재시작 복구를 위? 필요? 로그들을 제외하고는 체크포?트 수행시 디스크에서 삭제된다. 재시작 복구에 필요? 로그 파?은 체크포?트 검사 시 56 Administrators Manual 수행 중이던 트?잭?들이 생성? 로그 파?들 중 가장 오래된 로그 파?을 의미?다. 따라서, 장기? 수행 중? 트?잭?이 ?재하면 체크포?트가 발생하더라도 재시작 복구를 위? 로그 파?들은 더이상 지워지지 않기 때?에 로그 파?이 저장되는 파? 시스템에 더 이상 로그를 저장하지 못하는 상태가 될 수 있다. 페이지 리스트 다중화 메모리 테이블의 경우 로그파?그룹 (Log File Group) 기능을 ?성화하면 테이블에서 사용하는 페이지 리스트 역시 LFG와 같은 개수로 다중화 된다. 로그파?그룹 기능에 대? 상세? 정보는 이 매뉴얼 “15장 알티베이스 튜닝”의 ?당 내용을 참조?다. 이중화된 테이블 알티베이스에서 이중화 대상? 테이블에 대하여 DDL ?의 실행이 가능하지?, 먼저 반드시 다음과 같이 프로퍼티를 설정?야 ?다. REPLICATION_DDL_ENABLE 프로퍼티를 1로 설정?다. ALTER SESSION SET REPLICATION으로 설정? 수 있는 REPLICATION 세? 프로퍼티를 NONE 이외의 값으로 설정?다. 이중화 테이블 관리에 대? 자세? 내용은 Replication Manual을 참조?다. 생성 테이블은 CREATE TABLE?을 사용하여 생성? 수 있다. 테이블 생성 시에는 칼럼 정의, 제약조건, 테이블이 저장될 테이블스페이스, 테이블에 삽입? 수 있는 최대 레코드 수, 테이블을 위? 저장 관리자 내 페이지에 대? 공? ?용율 등을 명시? 수 있다. 예제 CREATE TABLE book( 데이터베이스 객체 및 권? 57 isbn CHAR(10) CONSTRAINT const1 PRIMARY KEY SET PERSISTENT = ON, title VARCHAR(50), author VARCHAR(30), edition INTEGER DEFAULT 1, publishingyear INTEGER, price NUMBER(10,2), pubcode CHAR(4)) MAXROWS 2 TABLESPACE user_data; CREATE TABLE dept_c002 AS SELECT * FROM employees WHERE dno = 4002; 메모리 테이블에서 칼럼 정의 시 주의 사항 VARCHAR 데이터 타입의 경우 FIXED 또는 VARIABLE 속성을 사용자가 지정? 수 있다. 사용자가 이 속성을 지정하지 않았다면, 데이터의 길이가 MEMORY_VARIABLE_COLUMN_IN_ROW_SIZ 프로퍼티에 지정? 값 이하? 데이터의 경우 FIXED영역에 저장되고 그렇지 않을 경우 VARIABLE 영역에 저장된다. FIXED영역에 저장될 경우에는 비록 데이터 타입이 VARCHAR?지라도 CHAR 데이터 타입처럼 저장공?을 ?당 길이?큼 미리 ?당받으며, VARIABLE영역에 저장될 경우에는 데이터 길이?큼? 저장공?에 ?당된다. VARCHAR 데이터 타입의 데이터 비교 방식은 FIXED 또는 VARIABLE 속성에 관계 없이 non-blank padding 비교 방식을 따른다. 다음 그림은 FIXED 또는 VARIABLE로 선?된 칼럼이 레코드 내에서 저장되는 방식을 보여?다. FIXED? 경우에는 비록 데이터 타입이 VARCHAR?지라도 CHAR 데이터 타입처럼 메모리상에 미리 ?당 길이?큼 ?당받으며 VARIABLE? 경우에는 데이터 길이?큼? 메모리 상에 ?당된다. CREATE TABLE item ( name varchar(20) FIXED, description varchar(1000) VARIABLE ); Record Headernamedescription real data of description 20 13 16 INSERT INTO item VALUES('msjung', 'variable test'); [그림 4-1] VARCHAR 칼럼 구조 58 Administrators Manual 테이블 item의 칼럼 name은 VARCHAR(20) FIXED로 선?되었기 때?에 실제 삽입되는 값? “msjung”의 길이가 6이라 하더라도 레코드 내에서 20바이트?큼 그 공?을 ?당받는다. 테이블 item의 칼럼 description은 VARCHAR(1000) VARIABLE로 선?되었기 때?에 실제 삽입되는 값? “variable test”의 길이? 13바이트?큼 그 공?을 ?당받는다. ?당받는 공?은 레코드 내의 연속적? 공?이 아니라 위 그림처럼 별도의 공?1이다. VARCHAR데이터 타입의 VARIABLE속성으로 선?된 칼럼은 실제 데이터가 저장된 곳의 위치 정보를 유지하기 위? 별도의 정보를 레코드 내에 유지하며 그 길이는 16이다. 따라서 위 그림의 예제에서 description 칼럼의 값을 저장하기 위? 실제 사용되는 공?은 29바이트이다. 변경 ALTER TABLE?, RENAME?을 사용하여 다음과 같은 테이블 정의를 변경? 수 있다. 테이블 이름 새로? 칼럼 추가 기? 칼럼 삭제 칼럼 기본 값 칼럼 이름 제약 조건 추가 제약 조건 삭제 메모리 테이블 COMPACT 최대 허용 레코드 수 ?덱스 ?성 및 비?성 예제 ALTER TABLE book ADD COLUMN (isbn CHAR(10) PRIMARY KEY, edition INTEGER DEFAULT 1); ALTER TABLE book DROP COLUMN isbn; ALTER TABLE department RENAME COLUMN dno TO dcode; 1 VARCHAR 데이터 타입의 VARIABLE속성으로 선?된 칼럼에 데이터를 저장? 때?다 데이터 크기?큼 매번 메모리 ?당을 받게 되는 경우 성능에 영향을 ? 수 있다. 그러므로 알티베이스는 4K, 8K, 16K 등 내부적으로 정?? 길이의 슬롯을 미리 ?비하며, VARCHAR 데이터 타입의 VARIABLE칼럼에 데이터 입력 시 서버는 실제 데이터를 저장? 수 있는 최적의 크기를 갖는 슬롯을 선택하여 데이터를 저장?다. 데이터베이스 객체 및 권? 59 ALTER TABLE ?에 대? 자세? 설명은 SQL Reference를 참고?다. 삭제 테이블은 DROP TABLE?을 사용하여 삭제? 수 있다. 예제 DROP TABLE employees; TRUNCATE 테이블의 레코드는 DELETE?을 사용? 삭제? 수도 있지? TRUNCATE TABLE?을 이용? 삭제? 수도 있다. DELETE?은 내부적으로 레코드를 건건이 삭제하는 것? 반면, TRUNCATE TABLE?은 내부적으로 DROP TABLE?을 수행하고 같은 정의의 테이블을 재생성하는 DDL?이다. 따라서 TRUNCATE TABLE?을 수행하면 그 테이블에 대? 테이블 수?의 잠금 (lock)이 잡히며, TRUNCATE TABLE?이 성공적으로 수행된 이후에는 ROLLBACK?을 사용?도 삭제된 데이터를 복구? 수 없다. 데이터 조작 테이블의 레코드들은 다음의 DML?을 사용하여 조작? 수 있다. INSERT DELETE UPDATE SELECT 위에서 ?급? 바와 같이 알티베이스 ?용 중에 대용량의 데이터에 대? bulk UPDATE/DELETE를 수행하는 것은 위험하기 때?에, ODBC 혹은 ?처리기 (APRE C/C++)를 이용하여 응용프로그램 작성 시 각 레코드에 대? UPDATE/DELETE 작업 수행 후 커밋하는 것이 바람직하다. 다음은 bulk UPDATE/DELETE을 피하고 레코드 각각에 대? UPDATE작업을 수행하는 C/C++ Precompiler 프로그램의 예이다. 60 Administrators Manual (a) isql 상에서 bulk-update 수행 iSQL >update t1 set col1=2 where col1 > 1000; (b) APRE C/C++를 이용하여 레코드별 update 수행 ....... EXEC SQL DECLARE update_cursor CURSOR FOR select col1 from t1 where col1 > 1000; EXEC SQL OPEN update_cursor; while (1) { EXEC SQL FETCH update_cursor INTO :t1_col; if (sqlca.sqlcode == SQL_NO_DATA) break; EXEC SQL update t1 set col1=2 where col1=:t1_col; } ....... 관? SQL문 테이블에 대? 다음과 같은 SQL?이 지원된다. 이에 대? 자세? 설명은 SQL Reference를 참조?다. CREATE TABLE ALTER TABLE RENAME TABLE TRUNCATE TABLE LOCK TABLE INSERT DELETE UPDATE SELECT 데이터베이스 객체 및 권? 61 큐 알티베이스 메시지 큐잉 기능은 데이터베이스와 사용자 프로그램?의 비동기 데이터 통?을 지원?다. 이 때 사용되는 큐 테이블은 데이터베이스 오브젝트의 하나로써 다른 데이터베이스 테이블과 ??가지로 DDL과 DML구?으로 제어? 수 있다. 생성 사용자가 CREATE QUEUE ?장을 이용?서 큐를 생성하면, 데이터베이스에는 사용자가 명시? 이름의 테이블이 생성된다. 이를 큐 테이블이라고 부른다. 큐 테이블은 다음과 같은 구조를 가?다. Column name Type Length Default Description MSGID BIGINT 8 - 메시지 식별자 로 알티베이스 에 의? 자동으 로 부여됨 CORRID INTEGER 4 0 사용자가 지정 ? 메시지 식별 자 MESSAGE VARCHA R Message length - 메시지 텍스트 ENQUEUE_TIME DATE 8 SYSDATE 메시지가 큐에 들어온 시? 큐 테이블의 이름이나 칼럼 명은 사용자가 임의로 변경? 수 없으며, MSGID 칼럼에는 자동으로 주요 키 (Primary Key)가 생성된다. 유?? 값의 MSGID를 생성하기 알티베이스 내부적으로 [QUEUE이름]_NEXT_MSG_ID라는 이름의 시퀀스가 생성된다. 사용자가 ?당 시퀀스에 대? 정보를 조회하려면 SYS_TABLES_ 메타 테이블을 사용하면 된다. 시퀀스는 큐 테이블이 삭제될 때까지 유지되어야 하기 때?에 DROP SEQUENCE ?장으로 삭제되지 않는다. 큐 테이블은 SYS_TABLES_ 메타 테이블에 TABLE_TYPE이 Q로 저장된다. 사용자는 필요에 따라서 CREATE INDEX ?장을 이용?서 큐 테이블에 ?덱스를 생성? 수 있다. 예제 CREATE QUEUE Q1(40); 62 Administrators Manual 변경 CREATE QUEUE ?장으로 생성된 큐 테이블은 ALTER TABLE 등의 ?장으로 구조를 변경? 수 없다. 오직 DROP QUEUE ?장으로 삭제될 수? 있다. 단, 사용자는 ENQUEUE/DEQUEUE, DELETE, SELECT 등의 ?장으로 데이터 조작은 가능하다. 삭제 큐 테이블은 DROP QUEUE ?을 사용하여 삭제? 수 있다. 예제 DROP QUEUE Q1; 데이터 삭제 큐에 적재된 메시지? 모두 삭제하고자 하는 경우에는 TRUNCATE TABLE ?장을 이용? 수 있다. 예제 TRUNCATE TABLE Q1; 데이터 조작 큐 테이블의 레코드들은 다음과 같은 DML?을 사용하여 조작될 수 있다. ENQUEUE DEQUEUE DELETE SELECT 관? SQL문 다음과 같은 SQL?을 제공하며 이에 대? 자세? 설명은 SQL Reference 을 참조?다. CREATE QUEUE 데이터베이스 객체 및 권? 63 DROP QUEUE ENQUEUE DEQUEUE 64 Administrators Manual 제약조건 제약 조건은 테이블의 데이터 삽입 또는 변경에 제?을 두는 것이다. 이 ?에서는 제약조건의 종류와 데이터 ?관성을 유지? 수 있도록 제약조건을 관리하는 방법에 대? 설명?다. 종류 알티베이스는 다음과 같은 종류의 제약조건을 지원?다. NOT NULL/NULL NOT NULL은 칼럼에 NULL이 삽입되는 것을 링는 제약조건이다. NOT NULL은 칼럼 단위로 정의? 수 있다. NULL을 명시하면 NULL값을 허용?다. 칼럼에 대? NOT NULL 을 명시하지 않으면 기본적으로 NULL값을 허용?다. UNIQUE 하나 이상의 칼럼에 대? 정의? 수 있는 제약조건으로 칼럼 또는 칼럼의 조합에 대? 중복 값이 삽입되는 것을 방지?다. 유? 키 제약조건을 정의하면 내부적으로 유? 키 ?덱스가 생성된다. PRIMARY KEY 프라이머리 키 제약조건은 유? 키 제약조건에 NOT NULL 제약조건까지 합쳐? 제약조건이다. 하나 이상의 칼럼에 대? 프라이머리 키 제약조건을 정의? 수 있다. 프라이머리 키가 생성될 때 내부적으로 유? 키 ?덱스가 생성된다. 프라이머리 키에 포함되는 어떤 칼럼에도 NULL값을 삽입? 수 없다. FOREIGN KEY 참조 무결성 제약조건 (referential integrity constraint)으로 참조 관계에 있는 테이블 ?의 데이터 ?관성을 유지? 수 있도록 ? 주는 제약조건이다. TIMESTAMP 칼럼의 값에 레코드의 삽입 또는 갱? 시 시스템 시? 값을 설정하는 제약조건이다. 주로 이중화 대상 테이블의 ? 칼럼에 대? 데이터베이스 객체 및 권? 65 이 제약조건을 정의?다. 칼럼 제약조건과 테이블 제약조건 칼럼 정의 시 하나의 칼럼에 대? 정의? 제약조건을 칼럼 제약조건이라 하고 여러 개의 칼럼들에 대? 하나의 제약조건을 테이블 정의 하단 부분에 정의하는 것을 테이블 제약조건이라고 ?다. NULL/NOT NULL 제약조건과 TIMESTAMP 제약조건은 칼럼 제약조건으로? 정의? 수 있고, 그 외 제약조건들은 칼럼 제약조건 또는 테이블 제약조건으로 정의? 수 있다. 생성 제약조건은 테이블 생성 (CREATE TABLE?) 또는 테이블 변경 (ALTER TABLE?) 시 정의? 수 있다. 제약조건 정의 시 제약조건의 이름을 사용자가 명시? 수 있으며 명시하지 않을 경우 시스템에 의? 자동으로 제약조건의 이름이 부여된다. ?덱스를 필요로 하는 제약조건의 경우 시스템에 의? 자동으로 이름이 부여되어 ?덱스가 생성된다. 예제 CREATE TABLE inventory( subscriptionid CHAR(10), isbn CHAR(10), storecode CHAR(4), purchasedate DATE NOT NULL, quantity INTEGER, paid CHAR(1), PRIMARY KEY(subscriptionid, isbn), CONSTRAINT fk_isbn FOREIGN KEY(isbn, storecode) REFERENCES book(isbn, storecode)) TABLESPACE user_data; ALTER TABLE book ADD CONSTRAINT const1 UNIQUE(bno); 삭제 ALTER TABLE?을 이용? 정의된 제약조건을 삭제? 수 있다. 66 Administrators Manual 예제 ALTER TABLE book DROP UNIQUE(bno); 관? SQL문 다음과 같은 SQL?을 제공하며 이에 대? 자세? 설명은 SQL Reference 을 참조?다. CREATE TABLE ALTER TABLE 데이터베이스 객체 및 권? 67 인덱스 ?덱스는 테이블 내 레코드들에 대? 빠른 접?이 가능하도록 ?다. 이 ?에서는 ?덱스의 알티베이스가 지원하는 ?덱스의 종류와 속성, ?덱스 객체의 관리 및 ?용 방법에 대? 설명?다. 인덱스 종류 알티베이스는 BTREE, RTREE 의 두 가지 ?덱스를 지원?다. RTREE 는 다차원 ?덱스로서 공? 질의 시 이용된다. B-tree 인덱스 공? 데이터 타입? GEOMETRY 타입의 칼럼을 제외? 모? 타입의 칼럼에는 B-Tree ?덱스가 생성된다. B-Tree는 ?통적으로 DBMS에서 사용?온 ?덱스 구조로써 현재까지 ?은 연구를 통? 여러가지 변이를 가지는데, 알티베이스는 이중 B+-Tree 형태의 ?덱스를 지원?다. B+-Tree는 ?덱스의 최하위 레벨에 ?재하는 리프 노드 (Leaf Node)들과, 최상위 레벨에 ?재하는 루트 노드 (Root Node), 그리고 리프와 루트의 사이에 ?재하는 ?터널 노드 (Internal Node)들로 구성된다. 키 값들은 모두 리프 노드에? ?재하며, 루트와 ?터널 노드는 좌측 자식 노드와 우측 자식 노드의 중? 값? 세퍼레이터 (Separator) 키들을 가?다. R-tree 인덱스 공? 데이터 타입? GEOMETRY 칼럼에는 R-Tree ?덱스가 생성된다. R-Tree?덱스를 사용하여 대상 객체 검색시 알티베이스는 다음의 과정을 수행?다. 1. 각 공? 객체를 감싸는 최소 사각형? MBR (Minimum Bounding Rectagle)을 이용하여 ?차로 조건 필터릿 (Filtering) 을 수행?다. 2. 이 결과로 남은 객체에 대? 정확? ?덱스 검색 조건을 체크하 는 리파?먼트 (Refinement)를 수행?다. R-Tree의 삽입, 삭제, 노드 스플? (Split), 노드 머지 (Merge) 알고리즘은 MBR을 기?으로 ?다는 점? 제외하고는 B-Tree와 68 Administrators Manual 유사하다. 인덱스 속성 ?덱스를 생성? 때 키 칼럼 구성 방법, 키 칼럼의 속성 등에 의? ?당 ?덱스는 아래와 같은 ?덱스 속성을 가?다. 메모리 테이블의 ?덱스에 대?서는 시스템 시작 시 부트 업 시?을 단축하기 위? 영구 ?덱스(Persistent Index) 속성을 지원?다. 유일 키 인덱스 (Unique Index) ?덱스 칼럼에 대? 중복 값을 허용하지 않는 ?덱스이다. 유일 키 (Unique Key)와 프라이머리 키 (Primary Key) 유? 키와 프라이머리 키 모두 중복 값을 허용하지 않는 것은 공통이다. 하지? 널 (NULL)의 허용 여부에 따라 유? 키와 프라이머리 키로 구별된다. 프라이머리 키의 경우 널 (NULL)을 허용하지 않는다. 중복 키 인덱스 (Non-unique Index) ?덱스 칼럼에 대? 중복 값을 허용하는 ?덱스이다. 유? 키 옵?을 지정하지 않으면 기본적으로 중복 값을 허용하는 ?덱스로 생성된다. 단일 키 인덱스 (Non-composite Index) ?덱스 대상 칼럼이 하나? ?덱스이다. 복합 키 인덱스 (Composite Index) 여러 개의 칼럼들의 조합에 대? 하나의 ?덱스를 생성하는 경우 복합 키 ?덱스라고 ?다. 영구 저장 인덱스 (Persistent Index) 메모리 테이블 ?덱스는 영구적 (Persistent) 데이터베이스 영역을 사용하지 않고 임시 메모리 영역에 ?재?다. 그래서 모? 메모리 테이블 ?덱스는 알티베이스를 시작? 때?다 다시 ?들어?다. ?? 데이터베이스의 크기가 매우 크면 ?덱스의 재생성 시?도 이에 비?하여 오래 걸린다. 데이터베이스 객체 및 권? 69 이를 방지하려면 영구 저장 ?덱스 속성을 부여하여 시스템이 정상 종료될 때 임시 메모리 영역에 ?재하는 ?덱스를 파?에 영구 저장 ?덱스로 저장되도록 ?다. 그 후에, 시스템이 다시 시작되면 ?덱스는 이 파?로부터 복원되어 부트 업 시?을 단축시킬 것이다. 그러나 이 경우 알티베이스는 ?덱스를 키 포?터 기반으로 생성하게 되어, 키 값 기반으로 ?덱스를 생성하는 것보다 더 시?이 오래 걸릴 수 있다. 게다가 ?덱스 저장 파?을 위? 디스크 공?이 추가로 더 필요하다. 그러므로 영구 저장 ?덱스는 특히 다음의 경우에 사용됨을 잘 알고 있어야 ?다. ?덱스 키 값의 크기가 너무 커서 키 값 기반으로 ?덱스를 생성함에 따른 성능 이점이 없는 경우 빠른 구동 시?이 특히 요구되는 경우 비영구 저장 인덱스 (Non-persistent Index) 알티베이스 정상 종료 시에 파?로 저장되지 않는 ?반 ?덱스이다. ?덱스 생성시 PERSISTENT=ON 옵?을 주지 않으면, 기본적으로 비영구 저장 ?덱스로 생성된다. 인덱스 관리 ?덱스는 테이블의 레코드들에 대? 접?을 빠르게 하기 위?서 사용된다. ?덱스는 ?당 테이블로부터 물리적, 논리적으로 독립적? 객체이기 때?에 테이블에 관계없이 생성, 삭제 또는 수정? 수 있다. 테이블의 레코드들이 수정되면 ?당 ?덱스들도 수정이 된다. 그러므로 필요? 경우에? ?덱스를 생성하고, 테이블에 대? 접? 유형에 따라 ?덱스를 변경하거나 삭제하여 최적화된 ?덱스를 관리?다. 인덱스 생성 ?덱스는 테이블에 ?재하는 하나 이상의 칼럼에 대? 생성된다. ?덱스는 테이블 제약조건을 통?서 자동으로 생성될 수도 있고, CREATE INDEX?을 사용? 사용자가 명시적으로 생성? 수도 있다. 예제 테이블 제약조건에 의? ?덱스 생성 CREATE TABLE TB1 (C1 INTEGER PRIMARY KEY, C2 INTEGER UNIQUE); 70 Administrators Manual 테이블 제약조건 변경에 의? ?덱스 생성 ALTER TABLE TB1 ADD PRIMARY KEY (C1); ALTER TABLE TB1 ADD UNIQUE (C2); ?덱스 생성시 칼럼 정? 지정 CREATE INDEX TB1_IDX1 ON TB1 (C1 ASC, C2 DESC); ?덱스 타입 지정 CREATE INDEX TB1_IDX1 ON TB1 (C1) INDEXTYPE IS BTREE ; UNIQUE ?덱스 생성 CREATE UNIQUE INDEX TB1_IDX ON TB1 (C1) ; PERSISTENT ?덱스 생성 CREATE INDEX TB1_IDX1 ON TB1(C1) SET PERSISTENT=ON; 디스크 B-tree 인덱스의 생성 옵션 (NOLOGGING, NOFORCE) 디스크 B-tree ?덱스 생성 시 ?덱스 생성과 관?된 로그를 기록하도록 하여 시스템 오류 발생시 복구에 사용? 수 있다. 디스크 B-tree ?덱스를 생성? 때 기록되는 로그 양과 ?덱스 생성 소요 시?을 단축하려면, NOLOGGING 옵?을 사용하면 된다. NOLOGGING 옵?을 사용하면 ?덱스가 구축된 후 ?덱스의 모? 페이지를 디스크에 즉시 반영?서 ?덱스 생성 후에 시스템 고장이 발생하더라도 ?덱스의 ?관성을 보장? 수 있게 된다. 그러나 NOLOGGING 옵?으로 ?덱스를 생성? 때 ?덱스 페이지들을 즉시 디스크에 반영하지 않는 NOFORCE 옵?을 함께 명시하면, ?덱스를 구축하는 데 필요? 시?이 감소됨에도 불구하고 시스템이나 미디어 고장이 발생했을 경우 ?덱스 ?관성이 깨질수 있다. NOLOGGING과 NOFORCE 옵?을 모두 지정?서 생성된 ?덱스의 영속성을 보장하기 위?서는 수동으로 미디어 백업을 수행?야 ?다. ?덱스 생성시? ?관성 및 영속성 LOGGING ?덱스 생성 시? + 로깅 시? 시스템 고장 및 미디어 고장 시 복구가능 NOLOGGING FORCE ?덱스 생성 시? + ?덱스 페이지를 디 스크에 기록하는 시 ? 시스템 고장 시 복구 가능하 지?, 미디어 고장 시 ?관성 이 깨어질 수 있음 NOLOGGING NOFORCE ?덱스 생성 시? 시스템 고장 및 미디어 고장 시 ?관성이 깨어질 수 있음 예제 데이터베이스 객체 및 권? 71 로깅을 하지 않고 ?덱스를 생성하고 ?덱스를 디스크에 반영 CREATE INDEX TB1_IDX1 ON TB1(C1) NOLOGGING; 또는 CREATE INDEX TB1_IDX1 ON TB1(C1) NOLOGGING FORCE; 로깅을 하지 않고 (NOLOGGING) ?덱스를 생성? 후 디스크에 반영하지 않음 (NOFORCE) CREATE INDEX TB1_IDX1 ON TB1(C1) NOLOGGING NOFORCE; 인덱스 변경 ?덱스 ?성화 여부, ?덱스의 영구 저장 여부 속성을 ALTER INDEX?을 사용하여 변경? 수 있다. 예제 ALTER INDEX EMP_IDX1 SET PERSISTENT = ON; 인덱스 삭제 ?덱스의 삭제는 DROP INDEX?을 사용하여 명시적으로 삭제하거나 관? 제약조건을 삭제하여 묵시적으로 삭제될 수 있다. 예제 DROP INDEX emp_idx1; 인덱스 ?용 상향식 인덱스 생성 알티베이스는 상향식으로 ?덱스를 구축 (Bottom-Up Index Building)?다. 그러므로 데이터를 업로드? 후 ?덱스를 생성하는 것이 효율적이다. 테이블에 ?덱스가 생성되어 있는 상태에서 대량의 데이터를 삽입? 경우, 레코드가 삽입될 때?다 ?덱스에도 반영되므로 성능이 느려?다. 디스크 인덱스의 일관성 NOLOGGING 옵?으로 생성된 디스크 테이블 ?덱스의 경우 시스템 고장이나 미디어 고장 발생 시 ?덱스의 ?관성을 보장? 수 없는 경우가 발생?다. 이런 경우, 디스크 ?덱스의 ?관성을 V$DISK_BTREE_HEADER성능 뷰로 확??야 ?다. ?약 IS_CONSISTENT가 F? ?덱스가 ?재?다면 ?당 ?덱스를 삭제하고 필요? 경우 재생성하여 사용?라. 72 Administrators Manual 관? SQL문 다음과 같은 SQL?을 제공하며 이에 대? 자세? 설명은 SQL Reference 을 참조?다. CREATE TABLE ALTER TABLE CREATE INDEX ALTER INDEX DROP INDEX 데이터베이스 객체 및 권? 73 뷰 뷰(View)? 하나 이상의 테이블 또는 뷰를 기반으로 ? 논리적 테이블(logical table)로서, 데이터 자체는 실제로 포함하지 않는다. 이 ?에서는 뷰의 관리 방법에 대? 설명?다. 베이스 (base) 테이블과 뷰 베이스 테이블이? 뷰가 접?하여 데이터를 인어 오는 객체 (테이블 또는 뷰)이다. 하나의 뷰에 여러 개의 베이스 테이블이 연관될 수 있다. 알티베이스 HDB는 인기 ?용 뷰? 지원?다. 변경 가능 뷰 (updatable view) 와 실체화 뷰 (materialized view)는 지원하지 않는다. 생성 뷰는 CREATE VIEW?을 사용하여 생성? 수 있다. 예제 CREATE VIEW avg_sal AS SELECT DNO, AVG(salary) emp_avg_sal -- salary average of each department FROM employees GROUP BY dno; 변경 이미 ?재하는 뷰에 대? 뷰의 생성 구? 즉, 뷰 밑에 있는 SELECT쿼리 구?을 변경하고자 하는 경우에는 CREATE OR REPLACE VIEW?을 사용? 수 있다. 예제 CREATE OR REPLACE VIEW emp_cus AS SELECT DISTINCT o.eno, e.ename, c.cname FROM employees e, customers c, orders o WHERE e.eno = o.eno AND o.cno = c.cno; 컴파일 74 Administrators Manual 뷰는 베이스 테이블들을 참조하므로 베이스 테이블에 DDL?이 발생하여 베이스 테이블의 정의가 변경되는 경우 관? 뷰들은 수행이 불가능? 무효? 상태가 될 수 있다. 이런 경우 ALTER VIEW?을 COMPILE 옵?과 함께 사용?서 재?파?하면 유효? 상태로 ?들 수 있다. 예제 ALTER VIEW avg_sal COMPILE; 삭제 뷰는 DROP VIEW?을 사용하여 삭제? 수 있다. 예제 DROP VIEW avg_sal; 관? SQL문 다음과 같은 SQL?을 제공하며 이에 대? 자세? 설명은 SQL Reference을 참조?다. CREATE VIEW ALTER VIEW DROP VIEW SELECT 데이터베이스 객체 및 권? 75 시퀀스 알티베이스 HDB는 연속된 숫자 값 생성자로써 시퀀스 (sequence) 객체를 제공?다. 시퀀스의 다음 값들은 ?관된 성능 보장을 위? 캐싱? 수 있다. 시퀀스의 용도 시퀀스 생성자는 디스크 I/O 또는 트?잭? 잠금의 오버헤드 없이 연속된 유?? 숫자를 생성하기 위?서 다중 사용자 ?경에서 특히 유용하다. 예를 들어, 두 사용자가 동시에 orders 테이블에 새로? 레코드를 삽입?다고 가정하자. Order_id 칼럼에 입력될 유?? 주? 번호를 생성하기 위? 시퀀스를 사용하면, 어느 사용자도 다음의 가능? 주? 번호를 입력하기 위?서 다른 사용자를 기다리지 않아도 된다. 시퀀스는 각 사용자를 위?서 유?? 값을 자동으로 생성?다. 시퀀스 (sequence)는 DML ?으로 임의의 칼럼에 입력? 키 값을 생성하기 위? 주로 사용된다. [sequence 이름].NEXTVAL과 [sequence 이름].CURRVAL은 시퀀스에 접?하기 위? 사용된다. [sequence 이름].NEXTVAL은 시퀀스의 다음 값을 구하기 위? 사용된다. [sequence 이름].CURRVAL은 시퀀스의 현재 값을 구하기 위? 사용된다. 시퀀스 생성 후 그 시퀀스에 대?서 최초로 수행하는 연산이 [sequence 이름].CURRVA? 수 없다. [sequence 이름].CURRVA을 사용하기 위?서는 시퀀스 생성 이후 반드시 [sequence 이름].NEXTVAL을 먼저 사용?야 ?다. 시퀀스의 다음 값에 접?? 때?다 시퀀스의 값은 내부적으로 명시? 증감분 (increment by)?큼 증가?다. 시퀀스의 증감분은 시퀀스 생성시 명시적으로 그 값이 주어지지 않는 경우 기본적으로 1이다. INSERT문에서의 시퀀스 사용 시퀀스를 사용하여 키를 생성하여 레코드를 삽입하는 예제이다. 76 Administrators Manual 예제 create sequence seq1; insert into t1 values (seq1.nextval); 위에 예제에서, 시퀀스 생성시 초기값은 1이므로 t1테이블에는 1이 입력되며 시퀀스의 다음 값은 1 증가? 2가 될 것이다. 생성 CREATE SEQUENCE?을 사용하여 시퀀스를 생성? 수 있다. 시퀀스 생성 구?에 사용되는 옵?들은 다음과 같다. START WITH 시퀀스의 시작 값 INCREMENT BY 시퀀스의 증감 분 MAXVALUE 시퀀스의 최대값 MINVALUE 시퀀스의 최소값 CYCLE 이 옵?은 시퀀스가 최대값 또는 최소값에 도달했을 때 다음 값을 계속 생성하는 것을 보장?다. 시퀀스는 오름차순 시퀀스? 경우는 최소값부터, 내림차순 시퀀스? 경우는 최대값부터 다시 순?된다. CACHE 알티베이스 HDB는 시퀀스 값을 보다 빠르게 액세스하기 위하여 미리 생성하여 메모리에 캐시?다. 이렇게 캐시되는 시퀀스 값의 개수는 CACHE 옵?으로 지정? 수 있다. 시퀀스 캐시는 시퀀스가 처음 참조될 때 채워지며 다음 시퀀스 값을 요청? 때?다 캐시된 시퀀스에서 반?된다. 캐시된 ?지링 시퀀스 값을 사용? 이후에 발생? 시퀀스 요청에 대?서는 새로 시퀀스 값을 생성하여 메모리에 캐시하고 그 캐시의 첫번째 값을 반??다. 시퀀스 생성시 기본 CACHE 값은 20이다. 예제 기본적? 시퀀스 생성하기 (1부터 시작하며 1씩 증가) CREATE SEQUENCE seq1; 짝수를 생성하고 0에서 100까지 순?하는 시퀀스 생성하기 데이터베이스 객체 및 권? 77 CREATE SEQUENCE seq1 START WITH 0 INCREMENT BY 2 MAXVALUE 100 CYCLE ; 변경 ALTER SEQUENCE?을 사용하여 START WITH의 값을 제외? 모? 시퀀스 옵?을 변경? 수 있다. 예제 ALTER SEQUENCE seq1 INCREMENT BY 1 MINVALUE 0 MAXVALUE 100; 삭제 DROP SEQUENCE?을 사용하여 명시? 시퀀스를 삭제? 수 있다. 예제 DROP SEQUENCE seq1; 관? SQL문 다음과 같은 SQL?을 제공하며 이에 대? 자세? 설명은 SQL Reference 을 참조?다. CREATE SEQUENCE ALTER SEQUENCE DROP SEQUENCE 78 Administrators Manual 시노님 알티베이스 HDB는 테이블, 뷰, 시퀀스, 저장 프로시저 및 저장 함수에 대? 별칭 (alias) 으로써 시노님을 제공?다. 시노님의 장점 다음과 같은 경우 데이터베이스 시노님을 사용하면 ?은 이점이 있다. 특정 객체를 생성? 사용자와 객체의 원래 이름을 숨기고 싶은 경우 SQL?의 사용을 단순화하고자 하는 경우 사용자 변경에 따른 응용프로그램의 변경을 최소화하고자 하는 경우 생성 CREATE SYNONYM?을 사용하여 시노님을 생성? 수 있다. 예제 테이블 dept의 별칭으로 my_dept 시노님을 생성하라. CREATE SYNONYM my_dept FOR dept; 삭제 DROP SYNONYM?을 사용하여 명시? 시노님을 삭제? 수 있다. 예제 시노님 my_dept를 삭제하라. DROP SYNONYM my_dept; 관? SQL문 다음과 같은 SQL?을 제공하며 이에 대? 자세? 설명은 SQL Reference을 참조?다. 데이터베이스 객체 및 권? 79 CREATE SYNONYM DROP SYNONYM 80 Administrators Manual 저장 프로시저 및 저장 함수 저장 프로시저 (Stored Prodedure)? SQL?들과 흐름 제어?, ?당?, 오류 처리 루틴 등의 조합하여 ?체 업무 ?차를 하나의 모듈로 프로그래밍? 것이다. 이 모듈은 데이터베이스에 데이터베이스 객체로서 영구적으로 저장되어, 모듈 이름?을 호출하여 ?체 업무 ?차를 서버에서 ?번에 수행? 수 있다. 이 ?에서는 저장 프로시저 관리 방법에 대? 설명?다. 저장 프로시저와 저장 함수는 리턴값 ?재 유무에 따라 구별된다. 그 외의 모? 점은 동?하므로, 특별? ?급이 없는 ? 모? 설명들은 공통 사핫이다. 또? 이 ?에서는 저장 프로시저 관리 방법을 보여주는 ?단? 예제를 제공?다. 저장 프로시저의 용어와 개념, 자세? 관리 방법에 대?서는 Stored Procedures Manual을 참조?다. 종류 저장 프로시저 (Stored Procedure) 저장 프로시터는 입력 ?자, 출력 ?자, 입출력 ?자를 가지고 바디(body) 내에 정의된 조건에 따라 여러 SQL?을 ?번에 수행하는 데이터베이스 객체이다. 리턴값을 가지지 않으며 출력 ?자와 입출력 ?자들을 통? 클라이?트에게 값을 ?달?다. 하나의 리턴 값을 갖지 않기 때?에 다른 SQL?의 expression 내에 피연산자로 사용될 수 없다. 저장 함수 (Stored Function) 저장 함수는 하나의 리턴 값을 가지는 것을 제외하면 저장 프로시저와 동?하다. 저장 프로시저와 달리 하나의 리턴 값을 가지므로 시스템 제공 함수들처럼 다른 SQL?의 expression 내에 피연산자로 사용될 수 있다. 타입 세트 (Type Set) 저장 프로시저 내에서 사용되는 사용자 정의 타입들을 정의? 집합이다. 이는 주로 저장 프로시저끼리 파라미터 또는 리턴값으로 데이터베이스 객체 및 권? 81 사용자 정의 타입을 주고받을 때 사용된다. 저장 프로시저 관? SQL 구문 저장 프로시저의 SQL 구? 종류를 살펴보면, 다음과 같다. 종류 관? ?장 설명 생성 CREATE [OR REPLACE] PROCEDURE ? 새로? 저장 프로시저를 생성하거나 이 미 생성된 저장 프로시저의 재정의하는 SQL?이다. CREATE [OR REPLACE] FUNCTION ? 새로? 저장 함수를 생성하거나 이미 생 성된 저장 함수의 재정의하는 SQL?이 다. CREATE [OR REPLACE] TYPESET ? 타입 세트를 생성 또는 변경하는 SQL? 이다. 변경 ALTER PROCEDURE ? 저장 프로시저 생성 이후 관? 객체들의 정의가 변경된다면 현재 저장 프로시저 의 실행 계획은 최적화된 상태가 아? 것이다. 이 경우 이를 재 ?파?하여 최 적화된 실행 계획을 재 생성하는 SQL? 이다. ALTER FUNCTION ? 저장 함수 생성 이후 관? 객체들의 정 의가 변경된다면 현재 저장 함수의 실행 계획은 최적화된 상태가 아? 것이다. 이 경우 이를 재 ?파?하여 최적화된 실행 계획을 재 생성하는 SQL?이다. 삭제 DROP PROCEDURE ? 생성된 저장 프로시저를 삭제하는 SQL ?이다. DROP FUNCTION ? 생성된 저장 함수를 삭제하는 SQL?이 다. DROP TYPESET ? 생성된 타입 세트를 삭제하는 SQL?이 다. 실행 EXECUTE ? 저장 프로시저 또는 저장 함수를 실행하 는 SQL?이다. [함수 이름] SQL? 내에서 built-in function과 같은 저장 함수를 호출?다. [표 5-1] 저장 프로시저?의 종류 생성 82 Administrators Manual 저장 프로시저는 CREATE PROCEDURE?을 사용하여 생성? 수 있다. 예제 CREATE PROCEDURE proc1 (p1 IN INTEGER, p2 IN INTEGER, p3 IN INTEGER) AS v1 INTEGER; v2 t1.i2%type; v3 INTEGER; BEGIN SELECT * INTO v1, v2, v3 FROM t1 WHERE i1 = p1 AND i2 = p2 AND i3 = p3; IF v1 = 1 AND v2 = 1 AND v3 = 1 THEN UPDATE t1 SET i2 = 7 WHERE i1 = v1; ELSIF v1 = 2 AND v2 = 2 AND v3 = 2 then UPDATE t1 SET i2 = 7 WHERE i1 = v1; ELSIF v1 = 3 AND v2 = 3 AND v3 = 3 then UPDATE t1 SET i2 = 7 WHERE i1 = v1; ELSIF v1 = 4 AND v2 = 4 AND v3 = 4 then UPDATE t1 SET i2 = 7 WHERE i1 = v1; ELSE -- ELSIF v1 = 5 AND v2 = 5 AND v3 = 5 then DELETE FROM t1; END IF; INSERT INTO t1 VALUES (p1+10, p2+10, p3+10); END; / 변경 기?의 저장 프로시저의 이름은 유지하면서 저장 프로시저의 파라미터 또는 본체를 변경하고자 ? 때는 CREATE OR REPLACE PROCEDURE?을 사용하여 저장 프로시저를 재 생성?야 ?다. 예제 CREATE OR REPLACE PROCEDURE proc1 (p1 IN INTEGER, p2 IN INTEGER, p3 IN INTEGER) AS v1 INTEGER; v2 t1.i2%type; v3 INTEGER; BEGIN . . . END; / 저장 프로시저에서 참조되는 테이블, 시퀀스, 다른 저장 프로시저 또는 저장 함수의 정의가 변경되어 생성 시의 정의와 달라지면 현재 이 저장 프로시저의 실행 계획으로는 저장 프로시저를 실행? 수 데이터베이스 객체 및 권? 83 없게 된다. 이 경우 현재 이 저장 프로시저는 무효? (invalid) 상태라고 ?다. 예를 들면 처음 저장 프로시저 생성 시 ?재하던 ?덱스가 삭제된 경우 이? 실행 계획은 ?덱스를 통? 테이블에 접?하도록 계획되어 있으므로 이? 실행 계획을 사용? 테이블에 접?? 수 없게 된다. ALTER PROCEDURE?은 무효? 저장 프로시저를 재 ?파?하여 유효? (valid) 상태의 실행 계획을 재 생성하는 데 사용된다. 예제 ALTER PROCEDURE proc1 COMPILE; 삭제 저장 프로시저는 DROP PROCEDURE?을 사용하여 삭제? 수 있다. 예제 DROP PROCEDURE proc1; 관? SQL문 다음과 같은 SQL?을 제공하며 이에 대? 자세? 설명은 Stored Procedures Manual을 참조?다. CREATE PROCEDURE CREATE FUNCTION CREATE TYPESET ALTER PROCEDURE ALTER FUNCTION DROP PROCEDURE DROP FUNCTION DROP TYPE SET EXECUTE [함수 이름] 84 Administrators Manual 트리거 트리거? 테이블에 데이터가 삽입, 삭제, 또는 갱?될 때 시스템에 의? 작동되어 특정 작업 ?차를 자동으로 수행하는 저장 프로시저의 ? 종류이다. 이 ?에서는 트리거 관리 방법에 대? 설명?다. 트리거 구성 요소 다음의 트리거 구성요소는 트리거 작동 시점, 트리거 작동 여부, 트리거 작업을 결정?다. 트리거 이?트 (trigger event) 수행시 트리거 작동을 유발하는 SQL?을 트리거 이?트라고 ?다. 트리거 조건 (trigger condition (WHEN ?)) 이는 트리거를 작동시키기 위? ?족시켜야 하는 SQL 조건이다. 트리거 액? (trigger action) 이는 트리거 조건이 TRUE? 때 트리거가 수행하는 저장 프로시저의 본체(body)이다. 트리거 이벤트 트리거 작동을 유발시키는 이?트로서 다음 세 DML 구? 중 하나를 명시? 수 있다. DELETE ?당 테이블의 데이터를 삭제하는 DELETE 구? 수행 시?다 트리거가 동작된다. INSERT ?당 테이블의 데이터를 삽입하는 INSERT 구? 수행 시?다 트리거가 동작된다. UPDATE ?당 테이블의 데이터를 변경하는 UPDATE 구? 수행 시?다 트리거가 동작된다. UPDATE 트리거 이?트에 OF ?이 있을 경우, OF ?에 지정된 칼럼의 데이터가 변경될 때? 트리거가 동작된다. Note: 데이터베이스의 무결성을 위? 이중화에 의? 테이블의 변경은 트리거 이?트로 처리되지 않는다. 데이터베이스 객체 및 권? 85 생성 트리거는 CREATE TRIGGER?을 사용하여 생성? 수 있다. 예제 CREATE TRIGGER del_trigger AFTER DELETE ON orders REFERENCING OLD ROW old_row FOR EACH ROW AS BEGIN INSERT INTO log_tbl VALUES(old_row.ono, old_row.cno, old_row.qty, old_row.arrival_date, sysdate); END; / 변경 ?재하는 트리거를 비?성화 시키거나 무효? 상태의 트리거를 재?파?하는 경우 ALTER TRIGGER?을 사용? 수 있다. 트리거는 처음 생성될 때, 기본적으로 자동 ?성화된다. ALTER TRIGGER 구?에 DISABLE과 ENABLE ?을 이용하여 트리거를 비?성화하고 ?성화 시킬수 있다. 예제 ALTER TRIGGER del_trigger DISABLE; 삭제 DROP TRIGGER?을 사용? 트리거를 삭제? 수 있다. 예제 DROP TRIGGER del_trigger; 관? SQL문 다음과 같은 SQL?을 제공하며 이에 대? 자세? 설명은 SQL Reference 을 참조?다. CREATE TRIGGER ALTER TRIGGER DROP TRIGGER 트리거는 저장 프로시저의 ? 종류이므로 트리거 본체(body)에 86 Administrators Manual 대?서는 Stored Procedures Manual을 참조?다. 데이터베이스 객체 및 권? 87 데이터베이스 사용자 데이터베이스 생성 후 초기 데이터베이스 내에는 시스템 관리자? SYSTEM_와 SYS 사용자?이 ?재?다. 이 사용자들은 DBA (데이터베이스 관리자)이므로 ?반 스키?를 구축하여 스키? 객체를 관리하기 위?서는 ?반 사용자를 생성?야 ?다. 이 ?에서는 사용자를 생성하고 관리하는 방법에 대? 설명?다. SYSTEM_와 SYS 사용자 SYSTEM_와 SYS 사용자는 데이터베이스 생성시 시스템에 의? 생성되는 시스템 관리자로 ?반 사용자와는 구별된다. 시스템 관리자로는 메타 테이블의 소유자로 메타 테이블에 대? DDL?과 DML? 수행 권?을 가지고 있는 SYSTEM_ 사용자와, DBA로 ?반 테이블에 대? 모? 권?을 가지고 있으며 시스템 수?의 모? 작업을 수행? 수 있는 권?을 기본적으로 가지고 있는 SYS 사용자가 있다. 이들 사용자는 DDL 구?을 사용하여 임의로 변경되거나 삭제될 수 없다. 생성 CREATE USER?을 사용하여 사용자를 생성? 수 있다. 이 구?을 실행하려면 CREATE USER 시스템 권?이 있어야 ?다. 사용자 생성 시 비밀 번호를 지정하여야 하고, 부가적으로 사용자를 위? 기본 테이블스페이스를 설정? 수 있다. 예제 CREATE USER DLR IDENTIFIED BY DLR123 DEFAULT TABLESPACE user_data TEMPORARY TABLESPACE temp_data ACCESS sys_tbs_memory ON; 변경 ALTER USER?을 사용하여 사용자 비밀번호와 ?당 사용자의 테이블스페이스 설정을 변경? 수 있다. 88 Administrators Manual 예제 사용자 비밀 번호 변경 ALTER USER dlr IDENTIFIED BY dlr12345; 기본 데이터 테이블스페이스 변경 ALTER USER dlr DEFAULT TABLESPACE dlr1_data; 임시 테이블스페이스 변경 ALTER USER dlr TEMPORARY TABLESPACE dlr1_tmp; 특정 테이블스페이스 접? 허용 여부 변경 ALTER USER dlr ACCESS dlr2_data ON; 삭제 사용자를 삭제하고자 하는 경우 DROP USER?을 사용하면 된다. ?당 사용자의 소유로 되어 있는 모? 객체까지 ?꺼번에 삭제하고자 ? 경우 CASCADE 옵?을 이용하라. ?당 사용자의 스키? 내에 객체가 ?재? 때 CASCADE 옵?을 사용하지 않는 경우 DROP USER? 수행 시 오류가 발생?다. 예제 DROP USER dlr CASCADE; 관? SQL문 다음과 같은 SQL?을 제공하며 이에 대? 자세? 설명은 SQL Reference 을 참조?다. CREATE USER ALTER USER DROP USER 데이터베이스 객체 및 권? 89 권한 사용자가 데이터베이스 객체 또는 데이터에 접?하기 위?서는 적?? 권?이 필요하다. 이 ?에서는 시스템 권? 및 객체 권?과 이를 관리하는 방법에 대?서 설명?다. 권한의 종류 알티베이스 HDB는 사용자가 권? (privilege)을 관리? 수 있는 기능은 지원하지? 권?들의 묶음? 롤 (role)은 지원하지 않는다. 이 ?은 알티베이스 HDB가 지원하는 권?의 종류에 대? 설명?다. 시스템 권한 (System Privilege) 시스템 권?은 ?반적으로 DBA가 관리?다. 시스템 권?이 있는 사용자는 데이터베이스에 특정? 작업을 수행하거나 모? 스키?에 있는 객체들에 접?? 수 있다. 알티베이스 HDB가 지원하는 ?체 시스템 접? 권? 목록은 다음과 같다. 각 권?에 대? 자세? 설명은 SQL Reference 을 참조?다. 시스템 권? 이름 DATABASE ALTER SYSTEM INDEXES CREATE ANY INDEX ALTER ANY INDEX DROP ANY INDEX PROCEDURES CREATE PROCEDURE CREATE ANY PROCEDURE ALTER ANY PROCEDURE DROP ANY PROCEDURE EXECUTE ANY PROCEDURE SEQUENCES CREATE SEQUENCE CREATE ANY SEQUENCE ALTER ANY SEQUENCE DROP ANY SEQUENCE SELECT ANY SEQUENCE SESSIONS CREATE SESSION TABLES CREATE TABLE CREATE ANY TABLE ALTER ANY TABLE 90 Administrators Manual 시스템 권? 이름 DELETE ANY TABLE DROP ANY TABLE INSERT ANY TABLE LOCK ANY TABLE SELECT ANY TABLE UPDATE ANY TABLE TABLESPACES CREATE TABLESPACE ALTER TABLESPACE DROP TABLESPACE USERS CREATE USER ALTER USER DROP USER VIEWS CREATE VIEW CREATE ANY VIEW DROP ANY VIEW MISCELLANEOUS GRANT ANY PRIVILEGES TRIGGER CREATE TRIGGER CREATE ANY TRIGGER ALTER ANY TRIGGER DROP ANY TRIGGER 객체 권한 (Object Privilege) 객체 권?은 객체의 소유자가 관리?다. 이들 권?은 객체에 접?하고 조작하는 것을 관리?다. 알티베이스 HDB가 지원하는 객체 접? 권? 목록은 다음과 같다. Object privilege Table Sequence PSM View ALTER O O DELETE O EXECUTE O INDEX O INSERT O REFERENCES O SELECT O O O UPDATE O 데이터베이스 객체 및 권? 91 권한 부여 GRANT?을 사용하여 특정 사용자에게 명시적으로 권?을 부여? 수 있다. SYSTEM_와 SYS 사용자의 경우 DBA로서 모? 권?을 갖고 있으며, ?반 사용자에게 임의의 권?을 부여? 수 있다. ?반 사용자의 경우 CREATE USER?을 수행하여 사용자를 생성하면 최소 권?으로 다음 권?들이 시스템에 의? 자동으로 부여된다. CREATE SESSION CREATE TABLE CREATE SEQUENCE CREATE PROCEDURE CREATE VIEW CREATE TRIGGER CREATE SYNONYM CREATE DATABASE LINK 예제 시스템 권? 부여 GRANT ALTER ANY SEQUENCE, INSERT ANY TABLE, SELECT ANY SEQUENCE TO uare5; 객체 권? 부여 GRANT SELECT, DELETE ON sys.employees TO uare8; 권한 해제 사용자에게 이미 부여된 권?을 REVOKE?을 사용? ?제? 수 있다. 예제 시스템 권? ?제 REVOKE ALTER ANY TABLE, INSERT ANY TABLE, SELECT ANY TABLE, DELETE ANY TABLE FROM uare10; 객체 권? ?제 REVOKE SELECT, DELETE ON sys.employees FROM uare7, uare8; 92 Administrators Manual 관? SQL문 다음과 같은 SQL?을 제공하며 이에 대? 자세? 설명은 SQL Reference 을 참조?다. GRANT REVOKE 테이블스페이스 93 6. 테이블스페이스 이 장에서는 관리자가 알아야? 테이블스페이스의 개념, 테이블스페이스 구조와 그 사용을 위?서 지원되는 기능에 대?서 설명하고, 효율적? 테이블스페이스 관리를 위?서 관리자들이 알아야 ? 정보를 ?달?다. 94 Administrators Manual 테이블스페이스 정의 및 구조 본 ?에서는 테이블스페이스가 무엇?지 살펴본다. 또?, 테이블스페이스와 데이터베이스의 관계를 알아보고, 디스크 테이블스페이스, 메모리 테이블스페이스, 휘발성 테이블스페이스들이 각각 어떤 구조를 갖고 있는지 설명?다. 테이블스페이스의 정의 테이블스페이스는 테이블, ?덱스 등의 데이터베이스 객체들이 저장되는 논리적? 저장소 (Storage)이다. 데이터베이스는 올바른 ?영을 위? 기본적으로 하나 이상의 테이블스페이스를 필요로 ?다. 시스템 테이블스페이스는 데이터베이스 생성시 자동으로 생성된다. 그리고 사용자가 임의로 사용자 정의 테이블스페이스를 생성? 수 있다. 알티베이스는 사용자 정의 테이블스페이스를 데이터베이스 객체가 디스크에 상주하는 디스크 테이블스페이스와 메모리에 상주하는 메모리 테이블스페이스, 메모리에 상주하면서 로깅을 하지 않는 휘발성 테이블스페이스로 구분? 지원?다. 따라서 사용자는 테이블스페이스에 저장되는 데이터의 특성에 따라 디스크, 메모리, 또는 휘발성 테이블스페이스 중에서 어떤 것을 사용? 것?지 결정? 수 있다. 예를 들어 이력 데이터와 같은 대용량 데이터를 위?서는 디스크 테이블스페이스가 적합하다. 또? 접? 빈도가 높은 소용량 데이터는 메모리 테이블스페이스를, 빠른 처리를 위? 임시 데이터 처리는 휘발성 테이블스페이스를 사용하는 것이 적합하다. 데이터베이스 와 테이블스페이스의 관계 알티베이스 HDB 데이터베이스 생성시 4종류의 시스템 테이블스페이스 (시스템 딕셔너리 테이블스페이스, 시스템 데이터 테이블스페이스, 시스템 ?두 테이블스페이스, 시스템 임시 테이블스페이스) 들이 자동으로 생성된다. 또? 사용자가 테이블스페이스가 필요? 경우 사용자 정의 테이블스페이스 (디스크, 메모리, 또는 휘발성 테이블스페이스)를 생성? 수 있다. 사용자 정의 테이블스페이스는 데이터 특성에 따라 디스크 또는 메모리에 선택적으로 생성? 수 있다. 테이블스페이스 95 [그림 5-1]은 데이터베이스와 테이블스페이스의 관계를 보여?다. 시스템 테이블스페이스 사용자 정의 테이블스페이스 (in Me m ory) 사용자 정의 테이블스페이스 (in Disk) 이 베이스 [그림 6-1] 테이블스페이스와 데이터베이스의 관계 디스크 테이블스페이스 구조 디스크 테이블스페이스는 모? 데이터가 디스크 공?에 저장되는 테이블스페이스이다. 물리적으로는 데이터 파?로 구성되며, 논리적으로 세그먼트, 익스?트 및 페이지로 구성된다. 물리적 구조 디스크 테이블스페이스는 데이터 파?, 세그먼트와 밀접? 관계를 갖는다. [그림 5-2]는 디스크 테이블스페이스와 데이터 파? 및 세그먼트의 연관 관계를 설명?다. 디스크 테이블스페이스, 데이터 파? 및 세그먼트는 다음과 같은 특징을 갖는다. 디스크 테이블스페이스는 하나 이상의 데이터 파?로 구성되며, 데이터 파?은 ?영체제에서 제공되는 파? 형태로 ?재?다. 세그먼트는 논리적으로 테이블스페이스에 저장되며, 물리적으로 데이터 파?에 저장된다. 세그먼트는 특정 디스크 테이블스페이스에 종속적이며, 세그먼트가 참조하는 세그먼트는 다른 디스크 테이블스페이스에 저장될 수 있다. 96 Administrators Manual 스 테이블스페이스 테이블 세그먼트 인덱스 세그먼트 테이블 세그먼트 인덱스 세그먼트 테이블 세그먼트 인덱스 세그먼트 이 파일 이 파일 [그림 6-2] 디스크 테이블스페이스, 데이터 파?, 세그먼트의 연관 관계 논리적 구조 디스크 테이블스페이스는 논리적으로 세그먼트, 익스?트 및 페이지로 구성된다. 이들의 관계를 살펴보면 [그림 5-3]과 같다. [그림 6-3] 디스크 테이블스페이스의 논리적 구조 테이블스페이스 97 세그먼트(Segment) 세그먼트는 익스?트의 집합으로 테이블스페이스 내의 모? 객체가 여기에 저장된다. 세그먼트는 테이블스페이스 내에서 테이블 또는 ?덱스를 ?당하는 단위이다. 하나의 테이블 또는 ?덱스는 논리적으로 하나의 세그먼트로 볼 수 있다. 알티베이스에서 사용하는 세그먼트의 종류는 다음과 같다. 종 류 설 명 Table 세그먼트 데이터베이스 ?에 데이터를 저장하는 가장 기본적? 수단이다. ? 개의 테이블 세그먼 트에는 파티? 되지 않은 테이블의 ?체 데 이터 또는 파티?드 테이블의 ? 파티?의 ?체 데이터가 저장될 수 있다. 테이블 생성시 알티베이스는 테이블스페이스 에 테이블 세그먼트를 ?당?다. Index 세그먼트 ? 개의 ?덱스 세그먼트에는 ? ?덱스의 모? 데이터 또는 파티?드 ?덱스의 ? 파 티?의 데이터가 저장될 수 있다. ?덱스 생성시 알티베이스는 테이블스페이스 에 ?덱스 세그먼트를 ?당?다. Undo 세그먼트 데이터베이스의 변경을 발생시키는 트?잭? 에 의? 사용된다. 알티베이스는 테이블 또 는 ?덱스를 변경하기 ?에 변경 ? 값 (즉, before-image)을 ?두 세그먼트에 저장? 두어, 트?잭? 롤백시에 변경을 ?두? 수 있다. TSS 세그먼트 알티베이스 내부적으로 관리되는 TSS (Transaction Status Slot)를 관리하기 위? 세그먼트이며, 시스템 ?두 테이블스페이스 내에 ?당된다. [표 6-1] 세그먼트 종류 각 세그먼트는 내부적으로 프리 (Free) 익스?트 리스트와 풀 (Full) 익스?트 리스트를 관리?다. 프리 익스?트가 부족하면 테이블스페이스에 익스?트 추가를 요청?다. 익스?트(Extent) 디스크 테이블스페이스에서 데이터 오브젝트를 저장하기 위?서 필요? 자원으로 연속된 여러 페이지를 ?당하는 단위이다. 데이터를 저장? 때 저장 가능? 프리 페이지 (Free Page)가 부족하면, 98 Administrators Manual 테이블스페이스에서 익스?트 단위로 페이지를 ?당받는다. ? 개의 익스?트는 기본 64개의 페이지 (512KB)로 구성된다. 알티베이스는 테이블스페이스?다 익스?트 크기를 다르게 정? 수 있도록 지원?다. 페이지(page) 테이블과 ?덱스의 레코드가 저장되는 최소 단위를 페이지라고 ?다. 또? I/O의 최소 단위이다. 알티베이스의 페이지 크기는 8KB이다. (알티베이스는 다양? 페이지 크기 (multiple page size)의 사용을 지원하지 않는다.) 페이지에 어떤 정보를 저장하느냐 따라 데이터 페이지, ?덱스 페이지, ?두 페이지 등 여러 종류의 페이지가 있다. 페이지의 ?반적? 구조와 데이터 저장 방식을 살펴보면 다음과 같다. 페이지 구조 페이지는 페이지의 기본 정보와 free slot 등을 관리하기 위? 헤더를 가?다. 레코드는 헤더를 제외? 영역에 저장된다. 페이지는 내부적으로 다음 그림과 같이 5개 영역으로 나누어?다. 물리적 헤더 빈 공간 저장 데이터 페이지 푸터 논리적 헤더 [그림 6-4] 디스크 테이블스페이스의 페이지 구조 물리적 헤더 (Physical Header) 모? 데이터 페이지에 공통되는 정보를 가지고 있다. 논리적 헤더 (Logical Header) 테이블스페이스 99 페이지의 종류에 따라 필요? 정보를 가지고 있다. 빈 공? (Free Space) 새로? 데이터를 저장된다. 저장 데이터 (Stored Procedure) 페이지 종류에 따라 로우, ?덱스, ?두 레코드 등이 저장된다. 페이지 푸터 (Page Footer) 페이지의 가장 아래쪽에 위치하며, 페이지의 무결성을 검사하기 위? 정보를 가지고 있다. 페이지 레코드 저장 방식 레코드는 페이지의 아래쪽에서 위쪽 (페이지의 시작) 방향으로 채워지며 빈 공? 영역에 저장된다. 페이지의 논리적 헤더는 페이지 아래 방향으로 확장되어 저장된다. 그 크기는 가변적이다. 데이터 1 페이지 푸터 페이지 헤더 데이터 2 데이터 3 [그림 6-5] 페이지 레코드 저장 방식 메모리 테이블스페이스 구조 메모리 테이블스페이스는 모? 데이터가 메모리 공?에 저장되는 테이블스페이스이다. 물리적 구조는 체크포?트 이미지 파?로 구성되며, 논리적으로는 페이지와 페이지 리스트들로 구성된다. 물리적 구조 메모리 테이블스페이스는 체크포?트 이미지 파?과 밀접? 관계를 갖는다. 다음 그림에서는 메모리 테이블스페이스, 테이블 및 체크포?트 이미지 파?의 연관 관계를 설명?다. 100 Administrators Manual [그림 6-6] 메모리 테이블스페이스, 테이블 및 체크포?트 이미지 파?의 연관 관계 메모리 테이블스페이스, 테이블 및 체크포?트는 다음의 특징을 갖는다. 메모리 테이블스페이스는 디스크 테이블스페이스와 달리 데이터를 데이터 파?에 저장하지 않고, 선형적? 메모리 공?에 저장?다. 선형적? 메모리 공?은 페이지 단위로 분?되고, 이 페이지들의 리스트가 테이블을 구성?다. 디스크 테이블스페이스는 디스크 입출력 비용 및 대용량 테이블 관리를 위하여 페이지 단위가 아? 익스?트 단위로 관리?다. 세그먼트는 개념적으로 익스?트의 리스트를 관리하기 논리적? 단위이다. 그러나 메모리 테이블스페이스의 목적은 대용량 데이터의 관리보다 빠른 접?을 지원하는 것이기 때?에, 세그먼트나 익스?트의 개념이 필요하지 않다. 따라서 메모리 테이블스페이스의 테이블들은 페이지 리스트를 이용하여 관리된다. 메모리 테이블들은 체크포?트시에 물리적으로 체크포?트 이미지 파?에 저장된다. 체크포?트 이미지 파?의 용도는 디스크 테이블스페이스의 데이터 파?의 그것과는 다르다. 디스크 테이블스페이스의 데이터 파?은 객체들을 저장하기 위? 것? 반면, 메모리 테이블스페이스의 체크포?트 이미지 파?은 객체들을 백업하기 위? 것이다. 체크포?트 이미지 파?은 데이터베이스 ?영에 직접적으로 필요하지 않다. 하지? 백업 및 복구 시?을 단축하기 위?서는 반드시 필요하다. 체크포?트 시 메모리 공?의 페이지들은 ?영 체제에 의? 지원되는 파?에 저장된다. 알티베이스 HDB의 체크포?트 방식은 ?명 “핑퐁 (ping-pong) 체크포?팅”으로, 이는 두 벌의 체크포?트 이미지 파? (0번, 1번)을 유지하며, 체크포?트 발생시?다 0번과 테이블스페이스 101 1번 파?을 번갈아가며 사용?다. 또? 각 체크포?트 이미지 파?은 디스크 입출력 비용의 분산을 목적으로 다수의 작은 파?로 분리될 수 있다. 논리적 구조 메모리 테이블스페이스의 논리적 구성 요소에는 페이지 리스트와 페이지가 있다. 이들의 관계를 살펴보면 다음 그림과 같다. [그림 6-7] 메모리 테이블스페이스의 논리적 구조 페이지 리스트 (Page List) 페이지 리스트는 메모리 테이블스페이스 내에서 테이블을 구성하는 논리적? 개념이다. 페이지 리스트는 메모리 테이블스페이스의 메모리 공?을 분?? 단위? 페이지의 리스트이다. 메모리 테이블스페이스 객체 중에서 테이블은 페이지 리스트로 유지된다. ?덱스는 데이터베이스의 ?관성을 유지하는 대상에 포함되지 않기 때?에 페이지 리스트를 사용하지 않는다. 시스템을 다시 시작? 때 메모리 테이블의 ?덱스는 재구축 되는데, 이는 ?영중에 ?덱스 로깅을 함으로써 발생? 수 있는 부하를 제거?다. 페이지 (Page) 메모리 테이블스페이스의 페이지 구조 및 데이터 저장 방식은 디스크 테이블스페이스의 페이지와 다른 특징을 갖는다. 메모리 테이블스페이스는 디스크 테이블스페이스와 달리 디스크 입출력 비용을 고려? 필요가 없기 때?에 레코드 수정 방식으로 아웃 플레이스 갱? (out-place update)을 사용?다. 아웃 플레이스 갱?이? 기? 레코드의 이미지를 직접적으로 102 Administrators Manual 변경하지 않고, 레코드의 새로? 버?을 위? 공?을 ?당받아 처리하는 방식이다. 이러? 갱? 방식은 기? 레코드의 삭제와 새로? 레코드의 삽입 과정으로 이루어지기 때?에 기? 레코드를 재구성하는 비용이 들지 않는다. 또? 기? 레코드의 접?을 직접 ? 수 있어 동시성 레벨이 높은 응용 분야에서 빠른 성능을 보장?다. 휘발성 테이블스페이스 구조 휘발성 테이블스페이스의 구조는 모? 데이터가 메모리 공?에 저장되는 메모리 테이블스페이스와 동?하다. 그러나 디스크상의 이미지 파?을 가지지 않는다는 점에서 메모리 테이블스페이스와 차이가 있다. 휘발성 테이블스페이스의 데이터는 메모리에? 상주?다. 휘발성 테이블스페이스에서 ?어나는 작업들은 디스크 로깅 작업을 수반하지 않고 체크포?트 대상에서도 제외되기 때?에 디스크 입출력이 ?혀 없다. 따라서 빠른 성능을 필요로 하는 경우에 휘발성 테이블스페이스가 유용하다. 논리적으로 페이지 리스트와 페이지로 구성된다. 물리적 구조 휘발성 테이블스페이스는 메모리에 데이터베이스 객체를 상주시킨다는 점에서 메모리 테이블스페이스와 동?하다. 그러나 휘발성 테이블스페이스는 체크포?트 이미지 파?을 갖지 않는다. 논리적 구조 메모리 테이블스페이스와 동?하게 페이지 리스트와 페이지로 구성된다. 테이블스페이스 103 테이블스페이스 분류 알티베이스가 제공하는 테이블스페이스는 아래 3가지 기?에 의?서 분류된다. 하나의 테이블스페이스는 아래에 분류된 다수의 속성들을 동시에 가질 수 있다. 저장 공?에 따른 분류 저장 내용에 따른 분류 생성 주체에 따른 분류 저장 공간에 따른 분류 알티베이스 테이블스페이스는 저장 공?에 따라 다음과 같이 분류된다. 메모리 상주 테이블스페이스 디스크 테이블스페이스 메모리 상주 테이블스페이스 메모리 상주 테이블스페이스는 로깅 수행 여부 및 디스크 이미지 파?의 ?재 여부에 따라 메모리 테이블스페이스와 휘발성 테이블스페이스로 구분된다. 메모리 테이블스페이스는 메모리 기반 객체를 저장하기 위? 테이블스페이스이다. ?당 테이블스페이스 내에 저장되는 모? 객체에 메모리 기반 데이터베이스 기술이 적용됨으로써, 사용자가 실시?으로 데이터에 접?? 수 있다. 그러나 메모리 테이블스페이스의 크기는 시스템의 사용 가능? 물리적 메모리 공?을 초과? 수 없다. 휘발성 테이블스페이스는 디스크 I/O 작업 없이 메모리 기반 객체를 저장하는 테이블스페이스이다. ?당 테이블스페이스 내에 저장되는 모? 객체에 메모리 기반 데이터베이스 기술과 부가적 기술이 적용됨으로써, 사용자가 디스크 I/O 작업 없이 실시?으로 데이터에 접?? 수 있다. 그러나 휘발성 테이블스페이스의 크기는 시스템의 사용 가능? 물리적 메모리 공?을 초과? 수 없고, 데이터베이스 서버 종료시 모? 휘발성 데이터 객체들은 사라?다. 디스크 테이블스페이스 디스크 테이블스페이스는 디스크 기반 객체를 저장하기 위? 104 Administrators Manual 테이블스페이스이다. 데이터의 실시? 접?보다는 대용량 데이터를 관리하고 싶은 경우에 사용? 수 있는 테이블스페이스이다. ?당 테이블스페이스에 저장되는 객체들에 대? 접?은 디스크 입출력을 수반?다. 이러? 디스크 입출력 비용이 데이터 접? 시?의 대부분을 차지하기 때?에, 디스크 테이블스페이스는 디스크 입출력 비용을 ?이기 위?서 메모리 버퍼 공?을 사용?다. 저장 내용에 따른 분류 테이블스페이스에 저장되는 내용에 따라 다음과 같이 분류된다. 딕셔너리 테이블스페이스 (Dictionary Tablespace) ?두 테이블스페이스 (Undo Tablespace) 임시 테이블스페이스 (Temporary Tablespace) 데이터 테이블스페이스 (Data Tablespace) 딕셔너리 테이블스페이스 딕셔너리 테이블스페이스는 데이터베이스 시스템의 ?영상 필요? 메타 데이터를 저장하기 위? 테이블스페이스다. 데이터베이스 생성시 시스템에 의?서 생성되는 테이블스페이스이며, 데이터베이스 내에 하나? ?재?다. 사용자는 딕셔너리 테이블스페이스 내에 객체를 생성? 수 없으며, 시스템?이 메타 데이터 유지 관리를 위? 시스템 객체를 생성? 수 있다. 메타 데이터에 대? 빠른 접?을 위하여 딕셔너리 테이블스페이스는 메모리에 ?재?다. 딕셔너리 테이블스페이스가 붕괴 (crash)된 경우에는 ?체 데이터베이스를 ?영? 수 없다 (백업 및 매체 복구를 이용하여 데이터베이스를 복구시켜야 ?다). 언두 테이블스페이스 ?두 테이블스페이스는 디스크 객체에 대? 연산이 남긴 ?두 이미지 (undo image)를 저장하기 위? 테이블스페이스이다. 알티베이스의 동시성 제어는 MVCC (Multi-Version Concurency Control) 기법이기 때?에 변경 이?의 이미지를 저장? 공?이 필요하다. 이러? 이? 이미지가 ?두 테이블스페이스에 저장된다. ?두 테이블스페이스의 사용은 다량의 이? 이미지로 ?? 데이터 테이블스페이스가 무? 확장되는 것을 링는다. ?두 테이블스페이스는 시스템에 하나? ?재하며, 데이터베이스 내의 모? 디스크 테이블스페이스에 의? 공유된다. 따라서, ?두 테이블스페이스 105 테이블스페이스도 딕셔너리 테이블스페이스와 ??가지로 시스템 ?영상 필수적? 시스템 테이블스페이스이다. 테이블스페이스 단위의 백업이 가능하다. 임시 테이블스페이스 임시 테이블스페이스는 질의 수행중 생성되는 임시 결과를 저장하기 위? 테이블스페이스이다. 따라서, 트?잭?이 종료하는 시점에 ?당 질의가 남긴 임시 테이블스페이스 내의 모? 데이터들은 사라지게 된다. 이러? 종류의 테이블스페이스는 동시성 제어 및 회복을 위? 로깅 등을 하지 않아 빠른 저장 및 검색이 가능하다. 사용자가 임의로 임시 테이블스페이스를 생성? 수 있으며, 다수의 임시 테이블스페이스가 시스템 내에 ?재? 수 있다. 임시 테이블스페이스의 백업은 지원되지 않는다. 데이터 테이블스페이스 데이터 테이블스페이스는 사용자 정의 객체를 저장하기 위? 테이블스페이스이다. 다수의 데이터 테이블스페이스가 시스템 내에 ?재? 수 있으며, 사용자는 테이블스페이스에 저장되는 데이터의 특성에 따라 메모리, 휘발성 또는 디스크 테이블스페이스로 생성? 수 있다. 생성 주체에 따른 분류 알티베이스 HDB의 테이블스페이스는 생성 주체에 따라 다음과 같이 분류된다. 시스템 테이블스페이스 (System Tablespace) 사용자 정의 테이블스페이스( User-defined Tablespace) 시스템 테이블스페이스 시스템 테이블스페이스는 시스템 ?영상 필요? 데이터들을 저장하기 위? 테이블스페이스이다. 시스템 딕셔너리 테이블스페이스, 시스템 ?두 테이블스페이스, 시스템 데이터 테이블스페이스 및 시스템 임시 테이블스페이스가 이에 ?당?다. 시스템 테이블스페이스는 데이터베이스 생성시 ?들어지며, 사용자가 명시적으로 테이블스페이스 삭제하거나 이름을 변경? 수 없다. 또? 테이블스페이스 단위의 백업과 매체 복구 수행이 가능하다. 106 Administrators Manual 사용자 정의 테이블스페이스 사용자 정의 테이블스페이스는 사용자 정의 객체들의 내용을 저장하기 위? 테이블스페이스이다. 사용자 정의 테이블스페이스 내에 정의된 객체들의 메타 데이터는 딕셔너리 테이블스페이스에 저장된다. 사용자는 명시적으로 사용자 정의 테이블스페이스를 삭제하거나 이름을 변경? 수 있다. 또? 테이블스페이스 단위의 백업 및 복구 수행이 가능하다. 테이블스페이스 목록 데이터베이스가 생성시 다수의 테이블스페이스가 ?들어?다. [표 5-2]와 같이 시스템 테이블스페이스, ?두 테이블스페이스, 임시 테이블스페이스, 그리고 사용자가 이용? 수 있는 기본적? 메모리 테이블스페이스와 디스크 테이블스페이스가 생성된다. 추가로 사용자가 CREATE TABLESPACE?으로 테이블스페이스들을 추가? 수 있다. ID 테이블스페이스 종류 저장 공? 테이블스페이스 이름 생성 시점 0 SYSTEM DICTIONARY TABLESPACE 메모리 SYS_TBS_MEM_DIC CREATE DATABASE 1 SYSTEM MEMORY DEFAULT TABLESPACE 메모리 SYS_TBS_MEM_DATA CREATE DATABASE 2 SYSTEM DISK DEFAULT TABLESPACE 디스크 SYS_TBS_DISK_DATA CREATE DATABASE 3 SYSTEM UNDO TABLESPACE 디스크 SYS_TBS_DISK_UNDO CREATE DATABASE 4 SYSTEM DISK TEMPORARY TABLESPACE 디스크 SYS_TBS_DISK_TEMP CREATE DATABASE 5이상 USER MEMORY DATA TABLESPACE 메모리 사용자 지정 CREATE MEMORY DATA TABLESPACE 5이상 USER DISK DATA TABLESPACE 디스크 사용자 지정 CREATE DISK DATA TABLESPACE 5이상 USER DISK TEMPORARY 디스크 사용자 지정 CREATE DISK 테이블스페이스 107 ID 테이블스페이스 종류 저장 공? 테이블스페이스 이름 생성 시점 TABLESPACE TEMPORARY TABLESPACE 5이상 USER VOLATILE DATA TABLESPACE 메모리 사용자 지정 CREATE VOLATILE DATA TABLESPACE [표 6-2] 테이블스페이스 목록 108 Administrators Manual 디스크 테이블스페이스 디스크 테이블스페이스는 모? 데이터가 디스크 공?에 저장되는 테이블스페이스이다. 이 ?에서는 디스크의 데이터 페이지를 중심으로 구조 및 로우 데이터의 입력 방식에 대? 살펴본다. 데이터 페이지 구조 알티베이스가 데이터베이스의 저장 공?을 관리? 때 사용하는 데이터의 최소 단위를 페이지 (page)라고 ?다. 페이지 크기는 8KB이고, 다양? 크기의 페이지 (multiple page size)는 지원되지 않는다. 데이터 페이지 (data page)는 여러 페이지 종류들 중의 ?가지로, 로우 데이터 (row data)를 저장?다. 로우 데이터는 페이지 아래부터 채워가며 저장되며, 이 때 빈 공? 영역을 사용?다. ?약 빈 공?의 영역이 충분하지 않다면, 페이지 콤팩트 (page compact) 연산을 수행하여 단편화된 공?을 제거하고 연속된 빈 공?을 확보하도록 ?다. 물리적 헤더 TTL(Touched Transaction Layer) 슬롯 디렉토리 빈 공간(Free space) 로우 데이터 페이지 푸터 [그림 6-8] 데이터 페이지의 구조 데이터 페이지의 영역은 위의 그림과 같이 6개의 영역으로 구성된다. 테이블스페이스 109 물리적 헤더 (Physical Header) 이 영역은 페이지 종류에 상관없이 모? 데이터 페이지들에 공통되는 정보를 가지고 있다. TTL (Touched Transaction Layer) 이 영역은 MVCC (Multi-Version Concurrency Control) 관? 정보를 가지고 있다. 슬롯 디렉터리 (Slot Directory) 이 영역은 로우가 저장된 페이지 내에서의 위치 (offset)에 대? 정보를 가지고 있다. 빈 공? (Free Space) 이 영역은 입력이나 갱? 등의 연산을 ? 때 사용? 수 있는 여유 공?이다. 로우 데이터 (Row Data) 페이지 푸터 (Page Footer) 이 영역은 페이지 구조의 가장 아래쪽에 위치하며, 페이지의 무결성을 확?하기 위? 정보를 가지고 있다. 디스크 테이블스페이스의 공간 관리 디스크 테이블스페이스는 PCTFREE와 PCTUSED 파라미터를 이용하여 수동적으로 관리될 수 있다. PCTFREE와 PCTUSED 파라미터를 사용?서 로우 데이터에 대? 입력이나 갱? 연산을 ? 때 빈 공?의 사용을 제어? 수 있다. 이들 파라미터의 값은 altibase.properties 파?의 PCTFREE와 PCTUSED 프로퍼티의 값으로 지정된다. 또? 테이블 생성(CREATE TABLE…) 또는 변경(ALTER TABLE…) 구?에서 테이블 별로 파라미터 값을 명시? 수도 있다. PCTFREE PCTFREE는 페이지에 저장되어 있는 로우들이 갱?될 경우에 대비하여 미리 확보?두는 빈 공?의 최소 비율이다. 예를 들어 PCTFREE 값을 20으로 설정하면, 페이지의 80% 공?까지? 입력 (insert)? 수 있고, 나머지 20%의 공?은 기?의 로우들이 갱?될 때 사용을 위?서 남겨둔다. 110 Administrators Manual 빈 공간 20% Data Block PCTFREE=20 페이지의 80%가 될 때까지 로우를 입력할 수 있다. 나머지 20%는 페이지에 존재하는 로우의 갱신을 위해 필요한 공간이다. [그림 6-9] PCTFREE 와 페이지 구조 PCTUSED PCTUSED는 페이지가 갱?? 가능? 상태에서 다시 삽입이 가능 상태로 가기 위?서 감소?야 ? 페이지 내 사용 공?의 최소 비율이다. PCTFREE 제?에 걸리게 되면, ?당 페이지에는 사용 공?의 비율이 PCTUSED 보다 낮아지기 ?까지 새로? 로우를 입력? 수 없고, 이 페이지 내의 빈 공?은 오직 갱? 연산을 위?서? 사용된다. 이 상태는 사용 공?의 비율이 PCTUSED값 아래로 떨어질 때까지 지속된다. 테이블스페이스 111 빈 공간 61% Data Block PCTUSED=40 빈 공간의 비율이 40% 미만으로 될 때까지 새로운 로우의 입력을 하지 않는다. [그림 6-10] PCTUSED 와 페이지 구조 로우의 구조 로우는 하나 이상의 로우 조각 (row piece)들로 구성된다. ?약 로우 ?체가 ? 개의 페이지에 저장될 수 있다면, 로우는 하나의 로우 조각으로 저장된다. 그러나 로우 ?체를 ? 개의 페이지에 저장? 수 없다면, 로우는 여러 개의 로우 조각에 나뉘어서 저장된다. 이들 로우 조각들은 ROWID값에 의? 서로 연결된다 (chained). 로우 헤더(공통) ROWID (선택 가능) 칼럼의 길이 칼럼 값 로우 헤더로우 바디 [그림 6-11] 로우 조각의 구조 로우 조각은 로우 헤더 (row header)와 로우 바디(row body)로 구성된다. 로우 헤더에는 18 byte 크기의 헤더 정보가 저장된다. 연결된 로우 112 Administrators Manual 조각 (chained row piece)? 경우에는 6 byte의 ROWID 정보가 추가적으로 저장된다. 로우 바디에는 칼럼의 길이 (column length), 칼럼 값 (column value)이 쌍을 이뤄서 연속으로 저장된다. 칼럼 값의 길이가 250 byte 이하이면 칼럼 길이의 저장을 위?서 1byte? 필요하고, 칼럼 값의 길이가 250 byte를 초과하면 칼럼 길이의 저장을 위?서 3byte가 필요하다. 공?을 ?약하기 위?서 칼럼 값이 널 (NULL)? 경우 칼럼의 길이 (0)? 저장하고 칼럼 값은 저장하지 않는다. 또? 칼럼 값이 널? 칼럼들이 ?지링에 연속으로 올 경우에는 칼럼 값뿐 아니라 칼럼 길이도 저장하지 않는다. 칼럼은 테이블 생성 (CREATE TABLE…) 구?에서 나열? 순서대로 저장된다. 이 때 널을 ?이 포함하는 칼럼을 ?지링에 배치하면 로우를 저장하는데 필요? 공?을 ?약? 수 있다. 로우 체이닝 및 마이그레이션 로우의 데이터가 너무 커서 ? 개의 페이지에 저장? 수 없을 때 로우 체이닝 (row chaining)과 로우 ?이그레이? (row migration)이 발생?다. 로우 체이닝은 데이터를 입력? 때 데이터의 크기가 너무 커서 로우가 ? 페이지에 저장될 수 없을 때 발생?다. 이 경우에는 로우의 데이터가 여러 개의 페이지에 나누어 저장되고, 이들은 서로 ROWID에 의? 연결된다. 로우 ?이그레이?은 ? 페이지 내에 저장되었던 로우가 갱? 과정에서 로우의 크기가 페이지의 크기를 넘어가는 경우 발생?다. 이 경우 ?체 로우는 새로? 페이지로 ?이그레이? 되고, 원래 로우는 옮겨? 로우가 저장된 새로? 위치를 가리키게 된다. 그러나 로우 ?이그레이?이 발생하더라도 ROWID는 변경되지 않는다. 로우 체이닝 또는 로우 ?이그레이?이 발생하면, DML 처리시에 ? 페이지를 더 인어야 하므로 디스크 I/O로 ?? 성능저하가 발생?다. 테이블스페이스 113 언두 테이블스페이스 ?두 테이블스페이스는 데이타베이스에 대? 변경 연산을 철회 (rollback)하는데 필요? 정보를 저장하는 테이블스페이스이다. 알티베이스는 다중 버?의 동시성 제어 기법 (MVCC)을 사용하기 때?에 변경 이?의 이미지를 저장? 공?이 필요하다. ?두 테이블스페이스는 데이터베이스에 하나? ?재하며, 데이터베이스 내의 모? 디스크 테이블스페이스에 의? 공유된다. 이 ?에서는 ?두 테이블스페이스의 특징 및 크기 계산 등 ?두 테이블스페이스를 어떻게 관리하는지 설명?다. ?두 레코드 (Undo Record) ?두 테이블스페이스의 특징 트?잭? 세그먼트의 관리 세그먼트 공? 재사용 ?두 테이블스페이스 변경 언두 레코드 데이터베이스는 변경된 트?잭?을 취소(롤백 또는 ?두)하기 위하여 관? 정보들을 유지?야 ?다. 이러? 정보들은 주로 트?잭?이 커밋되기 ?에 ?두 레코드들로 저장된다. ?두 레코드는 다음과 같은 목적으로 사용된다. 트?잭? 철회 (rollback) 데이터베이스 복구 인기 ?관성 (Read Consistency) 보장 롤백 구?이 수행되면, ?두 레코드는 커밋되지 않은 트?잭?에 의? 데이터베이스 변경을 취소하기 위? 사용된다. 또? ?두 레코드는 데이터베이스를 복구하는 동?에도 사용된다. 로그 파?에 기반? 트?잭? 리두 (redo)에 의? 데이터베이스를 복원? 후, ?두 레코드는 커밋되지 않은 변경에 대?서 취소하기 위?서 사용된다. 그리고 다른 트?잭?에 의? 변경중? 레코드를 어떤 트?잭?이 인을 때, 두 트?잭?이 동시에 레코드에 접?하여도 레코드가 변경되기 ?의 이미지는 ?두 레코드에 저장되어 있기 때?에 인기 ?관성을 보장? 수 있다. 114 Administrators Manual 언두 테이블스페이스의 특징 ?두 테이블스페이스의 특징을 살펴보면 다음과 같다. 시스템에 의? 자동으로 관리된다. 기본 ?두 테이블스페이스 파?은 자동 확장 모드의 undo001.dbf 이다. 데이터 파?의 추가 및 크기 변경이 가능하다. 온라? 백업 (Online Backup)의 대상이다. TSS 세그먼트와 ?두 세그먼트 이외의 데이터베이스 객체는 ?두 테이블스페이스에 생성이 불가능하다. ?두 테이블스페이스는 시스템 테이블스페이스이므로, 테이블스페이스 오프라? 및 제거가 불가능하다. 서버가 재구동될 때?다 ?두 테이블스페이스는 재구성 (Reset)된다. 알티베이스는 ?두 테이블스페이스의 정보 및 공?을 관리? 때 시스템에 의? 관리 방식을 사용?다. 시스템에 의? 관리 방식이? 기본적으로 ?두 테이블스페이스의 세그먼트들과 공?들을 서버가 자동으로 관리하는 것을 의미?다. ?두 테이블스페이스는 데이터베이스 생성 과정에서 생성된다. ?두 테이블스페이스는 시스템 테이블스페이스로써, 데이터베이스내에 하나? ?재? 수 있다. ?약 ?두 테이블스페이스가 ?재하지 않는다면 부트 로그에 에러 메시지가 출력되고 서버 구동이 실패?다. ?두 테이블스페이스내에서는 트?잭? 세그먼트 (TSS 세그먼트와 ?두 세그먼트)가 관리된다. 사용자는 프로퍼티 TRANSACTION_SEGMENT_COUNT를 사용?서 트?잭? 세그먼트의 개수를 변경? 수 있다. 사용자가 프로퍼티에서 지정? 개수?큼 TSS 세그먼트와 ?두 세그먼트가 각각 생성된다. TRANSACTION_SEGMENT_COUNT 프로퍼티를 255로 설정하였다면, 서버 구동시?다 TSS 세그먼트 255개와 ?두 세그먼트 255개가 생성된다. 프로퍼티 파?내에서 트?잭? 세그먼트를 다른 개수로 변경하였다면, 다음 서버 구동시에 명시된 개수?큼 세그먼트들이 생성될 것이다. 트랜잭션 세그먼트의 관리 테이블스페이스 115 트?잭? 세그먼트? 디스크 변경 트?잭?에 반드시 필요? ? 개의 TSS 세그먼트와 ? 개의 ?두 세그먼트로 구성된다. ? 트?잭? 세그먼트는 ? 디스크 변경 트?잭?에 바?딩 (Binding) 되고, 그 트?잭?이 완료될 때 ?바?딩 (Unbinding) 되기 때?에 다른 트?잭?에 의? 동시에 공유될 수 없다. V$TXSEGS를 조회하면, 트?잭? 세그먼트의 바?딩 여부를 확?? 수 있다. 디스크 변경 트?잭?에 ?당 트?잭? 세그먼트가 바?딩되면 V$TXSEGS에 트?잭? 세그먼트 ID, 트?잭? ID에 ?당하는 레코드가 생성되고 바?딩이 ?제되면 레코드는 삭제된다. 또? TSS 세그먼트와 ?두 세그먼트의 공?은 트?잭?이 ? 번 사용? 공?에 대?서는 어느 정도 시?이 지나면 재사용? 수 있는 구조로 설계되었다. 따라서 ?두 트?잭?의 공?이 필요? 경우에는 무조건 세그먼트를 생성하여 공?을 확장하는 것이 아니라 기?이 ?료된 세그먼트가 다시 사용된다. TSS 세그먼트의 재사용 단위는 1M이며, ?두 세그먼트는 2M이다. 다음은 ?두 테이블스페이스와 관?된 사용자 프로퍼티를 나타낸다. SYS_UNDO_FILE_INIT_SIZE ?두 테이블스페이스의 데이터 파? 생성시 초기 크기 SYS_UNDO_FILE_MAX_SIZE ?두 테이블스페이스의 데이터 파? 최대 크기 SYS_UNDO_TBS_NEXT_SIZE ?두 테이블스페이스의 데이터 파? 자동 확장 크기 SYS_UNDO_TBS_EXTENT_SIZE ?두 테이블스페이스 ? 익스?트의 페이지 개수 TRANSACTION_SEGMENT_COUNT 트?잭? 세그먼트의 개수 세그먼트의 공간 재사용 트?잭? 커밋 후에 ?두 데이터는 트?잭? 롤백이나 복구를 목적으로 더 이상 필요하지 않다. 하지? 트?잭?의 커밋 주기가 긴 Long-Term 트?잭?은 인기 ?관성을 위?서 ?두 데이터에 의?하고 있는 레코드의 이? 버?이 필요하다. 그렇지? 어느 정도 시?이 지나면 인기 ?관성을 위?서도 더 이상 ?두 데이타는 필요하지 않게 된다. 따라서 알티베이스 데이타베이스는 커밋된 ?두 데이터라고 하여도 116 Administrators Manual 최소?의 기? 동?? 유지하고, 그 기?이 지나면 그 ?두 데이터가 차지했던 공?을 다른 트?잭?이 재사용? 수 있도록 하고 있다. ?약 커밋된 트?잭?을 위? ?두 데이터를 가지고 있는 공?에 접?하는 온라? 트?잭?들이 더 이상 ?재하지 않는다면, ?당 ?두 공?은 기?이 ?료 (Expired)되었다고 ?다. 반대로 그 ?두 공?에 접?이 가능? 온라? 트?잭?이 아직 ?재?다면, ?당 ?두 공?은 기?이 유효 (Unexpired)하다고 ?다. 기?이 ?료된 ?두 공?은 다른 트?잭?에 의?서 재사용 될수 있으나, 기?이 유효? ?두 공?은 재사용될 수 없다. 언두공간 #0 (e xp ire d ) 언두공간 #1 (e xp ire d ) 언두공간 #2 (e xp ire d ) 언두공간 #3 (une xp ire d ) 언두공간 #4 (une xp ire d ) 언두공간 #5 (curre nt) 언두공간 #0 (curre nt) 언두공간 #1 (e xp ire d ) 언두공간 #2 (e xp ire d ) 언두공간 #3 (une xp ire d ) 언두공간 #4 (une xp ire d ) 언두공간 #5 (une xp ire d ) [그림 6-12] ?두 세그먼트의 재사용 위 그림은 ?두 세그먼트의 순? 구조가 ?두 공?의 재사용을 어떻게 허락하는지를 보여?다. 그림은 ?두 공? #0부터 시작?서 순서대로 사용되면서 현재(Current)의 ?두 공? #5을 사용하고 있는 것을 나타낸다. 그리고 다음 차?의 ?두 공? #0이 ?료된 것을 확?하고, ?두 공? #5를 모두 사용하면 ?두 세그먼트를 더 이상 확장하지 않고 ?두 공? #0을 재사용?다. 테이블스페이스 117 언두공간 #0 (une xp ire d ) 언두공간 #1 (une xp ire d ) 언두공간 #2 (une xp ire d ) 언두공간 #3 (une xp ire d ) 언두공간 #4 (une xp ire d ) 언두공간 #5 (curre nt) 언두공간 #0 (e xp ire d ) 언두공간 #1 (une xp ire d ) 언두공간 #2 (une xp ire d ) 언두공간 #3 (une xp ire d ) 언두공간 #4 (une xp ire d ) 언두공간 #5 (une xp ire d ) 언두공간 #6 (curre nt) [그림 6-13] ?두 세그먼트의 확장 그러나 ?두 공? #0이 유효? 상태라면 위의 그림처럼 ?두 세그먼트는 익스?트를 확장하여 ?두 공? #6을 추가하게 된다. 이와 같은 세그먼트 공?의 재사용성은 TSS 세그먼트에도 동?하게 적용된다. 언두 테이블스페이스 변경 ?두 테이블스페이스는 ALTER TABLESPACE 구?을 사용하여 변경될 수 있다. 그러나 ?두 테이블스페이스는 대부분이 시스템에 의?서 관리되므로, 다음과 같은 연산들에 대?서? 사용자가 수행? 수 있다. 데이터 파? 추가 및 제거 데이터 파? 크기 확장 및 축소 데이터 파?의 온라? 백업 시작 및 완료 ?두 테이블스페이스에 용량 부족 또는 용량 부족과 관?된 에러가 발생하는 것을 방지하려면, 사용자는 데이터 파?들을 추가하거나 기? 데이터 파?의 크기를 확장?야 ?다. 다음은 ?두 테이블스페이스에 데이터 파?을 추가하는 예제이다. ALTER TABLESPACE SYS_TBS_DISK_UNDO ADD DATAFILE ‘undo002.dbf’ AUTOEXTEND ON NEXT 1M MAXSIZE 2G; ALTER TABLESPACE … DROP DATAFILE 구?으로 데이터 파?을 제거? 수도 있으며, ALTER TABLESPACE ... ALTER DATAFILE… 구?으로 파?의 크기를 확장하거나 축소? 수 있다. 그리고 ALTER TABLESPACE … BEGIN BACKUP 구?으로 데이터 118 Administrators Manual 파?의 백업을 시작? 수 있으며, ALTER TABLESPACE … END BACKUP 구?을 사용?서 백업 완료를 ? 수 있다. 테이블스페이스 119 테이블스페이스 상태 테이블스페이스는 서비스 상태에 따라 온라? (online), 오프라? (offline), 또는 폐기 (discard) 상태로 있게 된다. 테이블스페이스 중에서 사용자가 생성? 디스크 테이블스페이스와 메모리 테이블스페이스의 상태는 온라?과 오프라?으로 변경? 수 있으나, 휘발성 테이블스페이스와 임시 테이블스페이스의 상태는 변경? 수 없다. 또? 테이블스페이스 내에 이중화가 걸려있는 테이블이 ?재? 경우에도 변경 불가능하다. 상태를 변경하기 위?서는 ALTER TABLESPACE … ONLINE 과 ALTER TABLESPACE … OFFLINE 구?을 사용?다. 단, 테이블스페이스의 온라?/오프라? 상태 ?이는 메타 (META) 단계와 서비스 (SERVICE) 구동 단계에서? 가능하다. 온라인 (Online) 테이블스페이스와 관?된 모? 자원이 ?당되고 ?비된 상태이며, 데이터베이스에서 테이블스페이스를 사용? 수 있게 설정된 상태이다. 테이블스페이스와 그 ?에 ?재하는 테이블과 ?덱스에 대? DML과 DDL을 수행? 수 있다. ?약 온라? 상태? 테이블스페이스와 테이블스페이스에 생성된 테이블 및 ?덱스를 ?시적으로 사용? 수 없게 하려면 ALTER TABLESPACE … OFFLINE 구?을 실행하면 된다. 오프라인 (Offline) 테이블스페이스와 관?된 모? 자원이 ?제된 상태이며, 데이터베이스에서 테이블스페이스를 ?시적으로 사용? 수 없게 설정된 상태이다. 테이블스페이스에 ?재하는 테이블과 ?덱스에 대? DML과 DDL을 수행? 수 없다. 그러나 테이블스페이스에 대? DROP TABLESPACE와 ALTER TABLESPACE ONLINE DDL구?은 사용? 수 있다. 테이블스페이스와 그 ?에 생성된 테이블과 ?덱스를 다시 사용? 수 있는 온라? 상태로 ?이하기 위?서는 ALTER TABLESPACE … ONLINE 구?을 사용하면 된다. 120 Administrators Manual 메모리 테이블스페이스가 오프라?으로 되면 메모리 테이블스페이스의 객체는 메모리에 적재되지 않기 때?에, 메모리 ?계 (메모리 부족) 상황이 발생했을 때 사용자는 메모리 테이블스페이스를 오프라?으로 변경?서 그 상황을 ?소? 수 있다. 폐기 (Discard) 데이터의 ?관성이 깨? 특정 테이블스페이스 때?에 정상적? 알티베이스 구동이 불가능? 경우, 깨? 테이블스페이스를 제외? 나머지에 대?서?이라도 정상적으로 데이터베이스 ?영을 ? 수 있어야 ?다. 이를 위?서 ?당 테이블스페이스는 폐기시켜야 ?다. 특정 테이블스페이스를 폐기 상태로 ?이시키기 위?서는 CONTROL 구동 단계에서 ALTER TABLESPACE … DISCARD 구?을 실행?야 ?다. 그러나 ? 번 폐기된 테이블스페이스는 제거 (DROP TABLESPACE)? ? 수 있기 때?에 ALTER TABLESPACE … DISCARD 구?을 수행? 때에는 주의?야 ?다. 테이블스페이스 121 테이블스페이스 관리 본 ?에서는 알티베이스 HDB에서 지원하는 테이블스페이스를 관리하는 방법에 대? 설명?다 생성 (CREATE) 테이블스페이스 생성은 SYS 사용자 또는 테이블스페이스 생성 권?을 가? 사용자? ? 수 있다. 테이블스페이스를 생성하려면 CREATE TABLESPACE … SQL 구?을 사용하라. 사용자는 사용자 정의 데이터 테이블스페이스 (User-defined Data Tablespace)? 생성? 수 있다. 즉 시스템 테이블스페이스들은 사용자가 임의로 생성? 수 없다. 디스크 테이블스페이스는 디스크 데이터 테이블스페이스와 디스크 임시 테이블스페이스로 분류된다. 메모리 테이블스페이스는 메모리 데이터 테이블스페이스? 있고, 메모리 임시 테이블스페이스는 없다. ??가지로 휘발성 테이블스페이스는 휘발성 데이터 테이블스페이스? 있고, 휘발성 임시 테이블스페이스는 없다. 다음은 테이블스페이스를 생성하는데 사용되는 SQL 구?이다. CREATE [DISK/MEMORY/VOLATILE] [DATA/TEMPORARY] TABLESPACE (1) 테이블스페이스 이름 (2) 디스크 데이터 파? 속성 (3) 디스크 임시 파? 속성 (4) 메모리 테이블스페이스 속성 (5) 휘발성 테이블스페이스 속성; 테이블스페이스에 저장된 객체의 크기 및 접? 빈도수와 같은 특성을 고려?서 메모리, 디스크, 또는 휘발성 테이블스페이스의 생성 여부를 결정?야 ?다. 테이블스페이스 생성시 지정? 수 있는 테이블스페이스 속성들은 디스크, 메모리, 또는 휘발성에 따라 다르다. 메모리 테이블스페이스는 여러 개의 데이터 파?로 관리되는 디스크 테이블스페이스와는 달리 객체들이 하나의 선형적? 메모리 공?에 저장된다. 따라서, 디스크 테이블스페이스 생성의 경우 각 데이터 파?에 속성이 적용되지?, 메모리 테이블스페이스의 경우 그 메모리 테이블스페이스 ?체에 적용된다. 즉 메모리 테이블스페이스에 초기 122 Administrators Manual 크기, 확장될 크기 등이 적용되며, 디스크 테이블스페이스는 데이터 파?에 ?당 속성들이 적용된다. 테이블스페이스 이름 테이블스페이스 이름은 유??야 ?다. 동?? 이름의 객체가 두개 이상 생성될 수 없다. 디스크 테이블스페이스의 경우에는 데이터 파?들의 이름을 지정? 수 있지?, 메모리 테이블스페이스의 경우에는 체크포?트 이미지 파?이 저장될 경로?을 지정? 수 있다. 체크포?트 이미지 파?의 이름은 테이블스페이스의 이름을 이용하여 자동으로 ?들어?다. 디스크 데이터 파일 속성 데이터 파? 속성은 디스크 데이터 테이블스페이스에? 적용되며, 다음과 같은 구?을 갖는다. DATAFILE [①데이터 파?? AUTOEXTEND [②자동확장? MAXSIZE [③최대크기?] ] ] EXTENTSIZE [④익스?트사이즈?] 각 데이터 파?은 다음과 같은 속성을 가질 수 있다. 데이터 파?? DATAFILE {데이터 파? 경로 및 이름} SIZE integer [K/M/G] [REUSE] 데이터 파? 경로 및 이름을 지정?다. SIZE? 이하는 생략 가능하다. SIZE?은 데이터 파?이 생성될 때의 초기 데이터 파?의 크기를 명시하는데 사용된다. 각 데이터 파?에는 파? 헤더가 저장된다. SIZE는 파? 헤더 크기 (1 page)를 제외? 나머지 페이지들의 총 크기를 의미?다. 따라서, 지정? 초기 크기와 실제 데이터 파?의 크기가 정확히 ?치하지는 않는다. ?약 ?영 체제에서 지원하는 최대 파? 크기가 초기 크기보다 작을 경우 에러가 반?될 것이다. 자동확장? AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 디스크 데이터 파?의 확장 여부를 지정?다. ON? 경우 시스템에 의?서 데이터 파?이 자동으로 확장된다. OFF? 경우 사용자가 명시적으로 파?을 확장?야 ?다. 데이터 파?의 확장 단위는 사용자가 NEXT?에 명시? 수 있다. 테이블스페이스 123 데이터 파?이 확장될 때 ?당 데이터 파?이 속? 테이블스페이스에서 수행되는 모? 연산은 ?당 데이터 파?이 확장이 끝날 때까지 대기?다. 최대크기? MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장?의 부속?로써, 데이터 파?이 확장될수 있는 최대 크기를 의미?다. 초기 크기와 ??가지로 ?약 ?영 체제에서 지원하는 최대 파? 크기가 데이터 파?의 최대 크기보다 작을 경우 ?영 체제의 최대 파? 크기로 설정된다. UNLIMITED로 설정된 경우에는 데이터 파?이 디스크의 가능? 공?을 모두 사용? 때까지 사이즈가 늘어난다. 익스?트 사이즈? EXTENTSIZE {{integer [K/M/G]}/{UNLIMITED}} 테이블스페이스에 저장되는 세그먼트 (테이블 또는 ?덱스)가 ?당받는 단위? 익스?트의 사이즈를 정의?다. 익스?트 사이즈를 명시하지 않을 경우 기본값으로 512K (64 pages)를 갖는다. 디스크 임시 파일 속성 임시 파? 속성은 디스크 임시 테이블스페이스에? 적용되며, 다음과 같은 구?을 갖는다. TEMPFILE {①임시 파??} AUTOEXTED [②자동확장? MAXSIZE [③최대크기?] ] EXTENDSIZE [④익스?트사이즈?] 각 임시 파?은 다음과 같은 속성을 가질 수 있다. 임시 파?? TEMPFILE {데이터 파? 경로 및 이름} SIZE integer [K/M/G] [REUSE] 이 ?은 임시 파? 경로 및 이름을 지정하며, SIZE? 이하는 생략 가능하다. SIZE?은 임시 파?이 생성될 때의 초기 크기를 명시하는데 사용된다. 각 임시 파?에는 파? 헤더가 저장된다. SIZE는 파? 헤더 크기 (1 page)를 제외? 나머지 페이지들의 총 크기를 의미?다. 따라서, 지정? 초기 크기와 실제 임시 파?의 크기가 정확히 ?치하지는 않는다. ?약 ?영 체제에서 지원하는 124 Administrators Manual 최대 파? 크기가 초기 크기보다 작을 경우 에러가 반?될 것이다. 자동확장? AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 디스크 임시 파?의 확장 여부를 결정?다. ON? 경우 시스템에 의?서 임시 파?이 자동으로 확장된다. OFF? 경우 사용자가 명시적으로 파?을 확장?야 ?다. 임시 파?의 확장 단위는 사용자가 NEXT?에 명시? 수 있다. 최대크기? MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장?의 부속?로써, 임시 파?이 확장될수 있는 최대 크기를 의미?다. 초기 크기와 ??가지로 ?약 ?영 체제에서 지원하는 최대 파? 크기가 임시 파?의 최대 크기보다 작을 경우 ?영 체제의 최대 파? 크기로 설정된다. UNLIMITED로 설정된 경우에는 임시 파?이 디스크의 가능? 공?을 모두 사용? 때까지 크기가 늘어난다. 익스?트 사이즈? EXTENTSIZE integer [K/M/G] 임시 테이블스페이스에 저장되는 세그먼트 (테이블 또는 ?덱스)가 ?당받는 단위? 익스?트의 사이즈를 정의?다. 익스?트 사이즈를 명시하지 않을 경우 기본값으로 256K (32 pages)를 갖는다. 메모리 테이블스페이스 속성 메모리 테이블스페이스에 적용되는 속성은 디스크 테이블스페이스의 데이터 파? 속성과 유사하지?, 추가적으로 체크포?트 이미지 경로를 포함?다. 구?은 다음과 같다. SIZE {①초기 크기?} AUTOEXTED [②자동확장? MAXSIZE [③최대크기?] ] CHECKPOINT PATH [④체크포?트 이미지 경로?] 메모리 테이블스페이스는 다음과 같은 속성을 가질 수 있다. 초기 크기? SIZE integer [K/M/G] 메모리 테이블스페이스 생성시 초기에 ?당되어야? 메모리 크기를 테이블스페이스 125 나타낸다. 이 값은 메모리 테이블스페이스의 기본 확장 단위의 배수여야 ?다. (EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 지정? 페이지 개수 * 메모리 테이블스페이스의 페이지 크기(32KB)2) 이 크기는 KiloBytes (K), Megabytes (M), 또는 Gigabytes (G) 단위로 명시? 수 있다. 이 단위를 명시하지 않을 경우 기본 단위는 KiloBytes (K)이다. 자동확장? AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 메모리 테이블스페이스의 자동 확장 여부를 결정?다. ON? 경우 시스템에 의?서 테이블스페이스가 자동으로 확장되지?, OFF? 경우 사용자가 명시적으로 크기를 확장?야 ?다. 확장되는 크기는 사용자가 NEXT?에 명시? 수 있다. 확장되는 크기는 초기 크기와 ??가지로 EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 설정된 페이지 크기의 배수에 ?당하는 크기로 지정하여야 ?다. 자동 확장 크기가 너무 작으면 자동확장이 빈번하게 발생? 수 있다. 알티베이스 HDB는 자동확장을 수행? 때 시스템에 ?재하는 모? 메모리 테이블스페이스의 현재 크기를 합산하여 MEM_MAX_DB_SIZE 프로퍼티에 지정? 크기보다 작은지 비교?다. 이러? 연산이 빈번하게 수행되면 시스템의 성능이 저하될 수 있다. 최대크기? MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장?의 부속?로써, 메모리 테이블스페이스가 확장될수 있는 최대 크기를 의미?다. 초기 크기와 ??가지로 ?영 체제에서 제공되는 메모리 공?의 크기를 초과? 수 없다. UNLIMITED로 설정된 경우에는 시스템에 ?재하는 모? 메모리 테이블스페이스의 크기를 합? ?체 크기가 MEM_MAX_DB_SIZE 프로퍼티에 지정? 크기를 ?어나지 않는 ?도 내에서 테이블스페이스가 자동확장된다. 체크포?트 이미지 경로? CHECKPOINT PATH ‘체크포?트 이미지 경로 리스트’ SPLIT EACH integer [K/M/G] 2 예를 들어 EXPAND_CHUNK_PAGE_COUNT를 128로 지정하였다면, 메모리 테이블스페이스의 기본 확장 크기는 128 * 32K로 계산되어 4MB가 된다. 그러므로 SIZE로 지정? 수 있는 크기는 4MB의 배수이다. 126 Administrators Manual 체크포?트 이미지 경로는 메모리 테이블스페이스에? 적용된다. 알티베이스 HDB는 메모리 테이블스페이스의 고성능 트?잭? 처리를 위하여 핑퐁(ping-pong) 체크포?트를 사용?다. 핑퐁 체크포?트를 위?서 두 벌의 체크포?트 이미지가 디스크에 생성된다. 각 체크포?트 이미지는 다수의 파?에 분?되어 저장될 수 있다. 체크포?트 이미지가 분?되는 크기는 SPLIT EACH?에 명시? 수 있다. 분?된 파?은 디스크 입출력 비용을 분산하기 위하여 서로 다른 경로에 저장될 수 있으며, 사용자가 임의로 분?의 크기 및 체크포?트 이미지 파?들이 저장되는 경로들을 지정? 수 있다. 사용자는 체크포?트 이미지 경로를 추가하거나 변경? 수 있지?, ?번 지정된 분?의 크기를 변경? 수는 없다. 휘발성 테이블스페이스 속성 휘발성 테이블스페이스에 적용되는 속성은 체크포?트 이미지 경로를 제외하고는 메모리 테이블스페이스의 속성과 유사하다. SIZE {①초기 크기?} AUTOEXTED [②자동확장? MAXSIZE [③최대크기?] ] 휘발성 테이블스페이스는 다음과 같은 속성을 가질 수 있다. 초기크기? SIZE integer [K/M/G] 휘발성 테이블스페이스 생성시 초기에 ?당되어야? 메모리 크기를 나타낸다. 이 값은 메모리 테이블스페이스의 기본 확장 단위의 배수여야 ?다. (EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 지정? 페이지 개수 * 메모리 테이블스페이스의 페이지 크기(32KB)3) 이 크기는 KiloBytes (K), Megabytes (M), 또는 Gigabytes (G) 단위로 명시? 수 있다. 이 단위를 명시하지 않을 경우 기본 단위는 KiloBytes (K)이다. 자동확장? AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 휘발성 테이블스페이스의 자동 확장 여부를 결정?다. ON? 경우 3 예를 들어 EXPAND_CHUNK_PAGE_COUNT를 128로 지정하였다면, 메모리 테이블스페이스의 기본 확장 크기는 128 * 32K로 계산되며, 값은 4MB가 된다. 그러므로 SIZE로 지정? 수 있는 크기는 4MB의 배수이다. 테이블스페이스 127 시스템에 의?서 테이블스페이스가 자동으로 확장되지?, OFF? 경우 사용자가 명시적으로 크기를 확장?야 ?다. 확장되는 크기는 사용자가 NEXT?에 명시? 수 있다. 확장되는 크기는 초기 크기와 ??가지로 EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 설정된 페이지 크기의 배수에 ?당하는 크기로 지정하여야 ?다. 자동 확장 크기가 너무 작으면 자동확장이 너무 빈번하게 발생? 수 있다. 알티베이스는 자동확장을 수행? 때 시스템에 ?재하는 모? 휘발성 테이블스페이스의 현재 크기를 합산하여 VOLATILE_MAX_DB_SIZE 프로퍼티에 지정? 크기보다 작은지 비교?다. 이러? 연산을 빈번하게 수행하면 시스템의 성능이 저하될 수 있다. 최대크기? MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장?의 부속?로써, 휘발성 테이블스페이스가 확장될수 있는 최대 크기를 의미?다. 초기 크기와 ??가지로 ?영 체제에서 제공되는 메모리 공?의 크기를 초과? 수 없다. UNLIMITED로 설정된 경우에는 시스템에 ?재하는 모? 휘발성 테이블스페이스의 크기를 합? ?체 크기가 VOLATILE_MAX_DB_SIZE프로퍼티에 지정? 크기를 ?어나지 않는 ?도 내에서 테이블스페이스가 자동확장 된다. 예제 Ex.1) 세개의 데이터 파?을 가지는 디스크 데이터 테이블스페이스를 생성?다. iSQL> CREATE DISK DATA TABLESPACE user_data DATAFILE ‘/tmp/tbs1.user’ SIZE 10M AUTOEXTEND ON NEXT 1M MAXSIZE 1G, ‘/tmp/tbs2.user’ SIZE 10M AUTOEXTEND ON NEXT 1M MAXSIZE 500M, ‘/tmp/tbs3.user’ SIZE 10M AUTOEXTEND ON NEXT 1M MAXSIZE 1G; Create success. Ex.2) 메모리 데이터 테이블스페이스를 생성?다. iSQL> CREATE MEMORY DATA TABLESPACE user_data SIZE 12M AUTOEXTEND ON NEXT 4M MAXSIZE 500M CHECKPOINT PATH ‘/tmp/checkpoint_image_path1’, ‘/tmp/checkpoint_image_path2’ SPLIT EACH 12M; Create success. Ex.3) 휘발성 데이터 테이블스페이스를 생성?다. iSQL> CREATE VOLATILE DATA TABLESPACE user_data SIZE 12M AUTOEXTEND ON NEXT 4M MAXSIZE 500M; Create success. 128 Administrators Manual 삭제 (DROP) 테이블스페이스 삭제는 SYS 사용자 또는 테이블스페이스 삭제 권?을 가? 사용자?이 ? 수 있다. 테이블스페이스를 삭제하려면 DROP TABLESPACE … SQL 구?을 사용하라. 시스템 테이블스페이스들은 사용자에 의?서 삭제될 수 없다. 테이블스페이스의 삭제는 메모리나 디스크, 휘발성을 명시적으로 구분하지 않으며, 아래와 같은 구?을 갖는다. DROP TABLESPACE {테이블스페이스 이름} [{⑴객체 삭제?} [⑵데이터 파? 삭제?] [⑶제약사핫 삭제?]]; 테이블스페이스의 이름을 지정하여 삭제를 수행하며 선택? 수 있는 옵?은 아래와 같다. ?약 아래 옵?들을 선택하지 않는다면 테이블스페이스의 스키??이 로그앵커 (loganchor)에서 삭제된다. 객체 삭제? INCLUDING CONTENTS 테이블스페이스내 객체 (테이블 또는 ?덱스)들과 객체의 내용을 삭제?다. ?약 테이블스페이스 내에 하나 이상의 객체가 ?재?다면 반드시 ?당 옵?을 선택?야 ?다. 그렇지 않을 경우, 테이블스페이스 삭제 연산은 실패? 것이다. 데이터 파일 삭제? INCLUDING CONTENTS AND DATAFILES 객체 삭제?을 명시하였을 경우, 객체의 레코드및 ?덱스 키가 삭제되지? 데이터 파? 자체가 삭제되는 것은 아니다. 따라서, 데이터 파?을 지우기 위?서는 데이터 파? 삭제?을 명시?야 ?다. 데이터 파? 삭제?은 객체 삭제?의 부속?로써, 테이블스페이스가 가지고 있는 모? 데이터 파?을 물리적으로 삭제?다. ?당 옵?은 디스크 테이블스페이스에 국?된 옵?이며, 메모리 테이블스페이스의 경우에는 ?당 옵?은 무시된다. 그리고 휘발성 테이블스페이스의 경우에 AND DATAFILES 구?을 사용하면 에러를 발생시킨다. 제약사항 삭제? INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS 객체 삭제?의 부속?로써, 삭제하고자 하는 테이블스페이스 내의 테이블스페이스 129 객체들을 참조하는 제약사핫 (constraints)이 다른 테이블스페이스에 ?재하는 경우 테이블스페이스에 객체가 남아있다는 에러가 발생하며 실패하게 된다. 이럴 경우에 객체와 참조를 삭제하기 위? CASCADE CONSTRATINS ?이 사용될 수 있다. 변경 (ALTER) 테이블스페이스 변경은 SYS 사용자 또는 테이블스페이스 삭제 권?을 가? 사용자?이 ? 수 있다. 테이블스페이스를 변경하려면 ALTER TABLESPACE … SQL 구?을 사용하라. 이 구?은 기?의 테이블스페이스의 정의, 하나 이상의 데이터 파? 또는 임시 파?의 속성, 또는 메모리 테이블스페이스, 휘발성 테이블스페이스의 속성을 변경하는데 사용된다. 다음은 SQL 구?을 설명?다. ALTER TABLESPACE {테이블스페이스 이름} {{⑴디스크 데이터 파? 변경?}/ {⑵디스크 임시 파? 변경?}/ {⑶메모리 테이블스페이스 변경?}/ {⑷휘발성 테이블스페이스 변경?}/ {⑸테이블스페이스 상태 변경?}}; 디스크 데이터 파일 변경? 이 ?은 디스크 시스템 테이블스페이스와 디스크 데이터 테이블스페이스에 사용? 수 있으며, 아래와 같은 옵?을 가?다. ALTER TABLESPACE {테이블스페이스 이름} {①테이터파? 추가?/ ②데이터 파? 삭제?/ ③데이터 파? 크기 변경?/ ④데이터 파? 이름 변경?} 데이터파? 추가? ADD {DATAFILE} {데이터 파??} AUTOEXTEND [자동확장? MAXSIZE [최대크기?] ] 이 ?은 디스크 테이블스페이스에서 데이터를 저장? 공?을 확장하려 ? 때 사용된다. 가능? 옵?은 테이블스페이스 생성시에 데이터 파?에 적용되는 구?과 동?하다. 데이터 파? 삭제? 130 Administrators Manual DROP {DATAFILE} {데이터 파?명} 이 ?은 디스크 테이블스페이스에서 데이터를 저장? 공?을 축소하려 ?때 사용된다. 데이터 파? 추가에 의? 확장은 자유롭게 수행? 수 있지?, 데이터 파?의 삭제는 ?당 데이터 파?이 현재 사용중이지 않을 때, 즉 ?당 데이터 파?까지 익스?트가 확장되지 않았을 때? 가능하다. 데이터 파? 크기 변경? ALTER {DATAFILE} {데이터 파?명} {{AUTOEXTEND [자동 확장?]} / {SIZE [크기 변경?]}} 이 ?은 디스크 테이블스페이스에 속하는 각 데이터 파?들의 현재 크기, 최대 크기, 확장 단위 및 자동확장 여부 등을 변경하는 데 사용된다. 명시되는 현재 크기 및 최대 크기는 현재 사용중? 크기보다 커야 ?다. 데이터 파? 이름 변경? RENAME {DATAFILE} {기? 데이터 파? 경로및 이름} TO {새로? 데이터 파? 경로및 이름} 데이터 파?의 위치를 변경함으로써 테이블스페이스의 데이터가 저장된 파? 시스템을 변경하는 것이다. 이 ?은 온라?이나 오프라?에 상관없이 어떤 구동 단계에서도 수행 가능하다. 하지?, 서비스 단계에서는 오프라? 상태? 테이블스페이스에 대?서? 수행? 수 있다. 디스크 임시 파일 변경? 이 ?은 디스크 임시 테이블스페이스에? 사용? 수 있다. 아래와 같은 옵?들을 가?다. ALTER TABLESPACE {테이블스페이스 이름} {①임시 파? 추가?/ ② 임시 파? 삭제?/ ③ 임시 파? 크기 변경?/ ④ 임시 파? 이름 변경?} 임시 파? 추가? ADD {TEMPFILE} {임시 파??} 테이블스페이스 131 AUTOEXTEND [자동확장? MAXSIZE [최대크기?]] 이 ?은 디스크 테이블스페이스에서 데이터를 저장? 공?을 확장하려 ? 때 사용된다. 가능? 옵?은 테이블스페이스 생성시에 데이터 파?에 적용되는 구?과 동?하다. 임시 파? 삭제? DROP {TEMPFILE} {임시 파?명} 디스크 임시 테이블스페이스에서 데이터를 저장? 공?을 축소하려 ?때 사용?다. 데이터 파? 추가에 의? 확장은 자유롭게 수행? 수 있지?, 데이터 파?의 삭제는 ?당 데이터 파?이 현재 사용중이지 않을 때, 즉 ?당 데이터 파?까지 익스?트가 확장되지 않았을 때? 가능하다. 임시 파? 크기 변경? ALTER {TEMPFILE} {임시 파?명} {{AUTOEXTEND [자동 확장?]} / {SIZE [크기 변경?]}} 이 ?은 디스크 임시 테이블스페이스에 속하는 각 임시 파?들의 현재 크기, 최대 크기, 확장 단위 및 자동확장 여부 등을 변경하는 데 사용된다. 명시되는 현재 크기 및 최대 크기는 현재 사용중? 크기보다 커야 ?다. 임시 파? 이름 변경? RENAME {TEMPFILE} {기? 임시 파? 경로및 이름} TO {새로? 임시 파? 경로및 이름} 임시 파?의 위치를 변경함으로써 테이블스페이스의 데이터가 저장된 파? 시스템을 변경하는 것이다. ?당 기능은 온라?이나 오프라?에 상관없이 어떤 구동 단계에서도 수행 가능하다. 하지?, 서비스 단계에서는 오프라? 상태? 테이블스페이스에 대?서? 수행? 수 있다. 메모리 테이블스페이스 변경? 이는 메모리 시스템 테이블스페이스와 메모리 사용자 정의 테이블스페이스에? 사용될 수 있으며, 아래와 같은 옵?들을 가?다. 체크포?트 경로에 대? 추가, 삭제 및 변경은 어느 구동 단계에서도 132 Administrators Manual 수행 가능하다. 그러나 서비스 단계에서는 오프라? 테이블스페이스? 변경이 가능하다. ALTER TABLESPACE {테이블스페이스 이름} {① 체크포?트 경로 추가?/ ② 체크포?트 경로 삭제?/ ③ 체크포?트 경로 변경?/ ④ 테이블스페이스 크기 변경?} 체크포?트 경로 추가? ADD CHECKPOINT PATH {디렉터리 경로} 체크포?트 이미지 경로를 추가적으로 설정?다. 체크포?트 경로 삭제? DROP CHECKPOINT PATH {디렉터리 경로} 기? 체크포?트 이미지 경로를 삭제?다. 체크포?트 경로 변경? RENAME CHECKPOINT PATH {기? 디렉터리 경로} TO {새로? 디렉터리 경로} 기? 체크포?트 이미지 경로를 새로? 경로로 변경?다. 테이블스페이스 크기 변경? ALTER {{AUTOEXTEND [자동 확장?]} / {SIZE [크기 변경?]}} 메모리 테이블스페이스의 최대 크기, 확장 단위, 자동확장 여부 등을 변경?다. 휘발성 테이블스페이스 변경? 이 ?은 휘발성 사용자 정의 테이블스페이스? 사용될 수 있으며, 아래와 같은 옵?을 가?다. ALTER TABLESPACE {테이블스페이스 이름} {① 테이블스페이스 크기 변경?} 테이블스페이스 크기 변경? ALTER 테이블스페이스 133 {{AUTOEXTEND [자동 확장?]} / {SIZE [크기 변경?]}} 휘발성 테이블스페이스의 최대 크기, 확장 단위, 자동확장 여부 등을 변경?다. 테이블스페이스 상태 변경? 테이블스페이스의 상태는 온라?과 오프라?이 있으며, 다음과 같은 구?으로 상태를 설정? 수 있다. ALTER TABLESPACE {테이블스페이스 이름} {ONLINE/OFFLINE/DISCARD} 온라? 상태는 테이블스페이스에 속? 모? 객체에 사용자가 접?? 수 있는 ?반적? 상태이다. 반면 오프라? 상태는 테이블스페이스 관? DDL을 제외? 다른 연산에 의? 테이블스페이스 객체에 접?? 수 없는 상태이다. 이러? 오프라? 상태를 이용하여 ?계 상황 극복이나 서비스 단계에서의 RENAME 연산 등을 ? 수 있다. 단 시스템 테이블스페이스는 핫상 온라? 상태로 유지되며, 오프라?으로 변경될 수 없다. 휘발성 테이블스페이스에 대?서는 이 구?을 사용? 수 없다. 디스카드 옵?은 알티베이스에서 ?용중? 여러 테이블스페이스 중 특정 테이블스페이스의 데이터에 오류가 발생4하여 알티베이스가 기동되지 않는 ?제가 발생? 경우에 사용될 수 있다. ?당 테이블스페이스를 디스카드 (DISCARD)함으로써 ?당 테이블스페이스를 버리는 대?, 나머지 테이블스페이스로 알티베이스를 기동? 수 있다. ?번 디스카드된 테이블스페이스는 제거 (DROP)외에 다른 연산은 사용이 불가하게 되므로, 사용에 ?중을 기하여야 ?다. 아?러, 테이블스페이스는 오직 컨트롤 (CONTROL) 단계에서? 디스카드 될 수 있다. 이 옵?은 디스크 테이블스페이스와 메모리 데이터 테이블스페이스에 사용될 수 있다. 테이블스페이스 백업 및 복구 이번 ?에서는 테이블스페이스의 온라?/오프라? 백업의 개념 및 4 예를 들어 DBA가 실수로 특정 메모리 테이블스페이스의 체크포?트 이미지 파?을 삭제했다고 가정하자. 이 경우 서버 기동시 ?당 메모리 테이블스페이스를 로드? 수 없기 때?에 DBA는 매체 복구를 이용하여 삭제된 체크포?트 이미지를 재생성하는 방법을 먼저 생각? 볼 수 있다. 그러나, 아카이브 로깅을 사용하지 않고 있다면, 매체 복구가 불가능하기 때?에 이 방법은 사용? 수 없을 것이다. 이 때 ?약 ?당 테이블스페이스를 삭제?도 상관이 없다면, 디스카드 기능을 이용하여 ?당 테이블스페이스를 제외하고 DB를 구동? 후 테이블스페이스를 제거하면 된다. 134 Administrators Manual 특징을 ?략히 설명?다. 백업 및 복구에 대? 자세? 설명은 이 매뉴얼의 ?당 장과 Getting Started Guide을 참고?다. 테이블스페이스 온라인 백업 (HOT 백업) 테이블스페이스의 온라? 백업은 서비스 제공중? 테이블스페이스에 대? 백업을 하는 것이다. 온라? 백업은 트?잭? ?행에는 영향을 주지 않기 때?에, 서비스 단계에서 이루어질 수 있다. 온라? 백업은 다음의 몇 가지 특징을 갖는다. 온라? 백업은 데이터베이스가 아카이브 로그 모드로 ?영될 때? 가능하다. 아카이브 로그 모드에서는, 체크포?트와 로그 플러시 (Log Flush) 후에도 로그 파?을 별도의 스토리지에 백업하므로 대용량의 스토리지를 필수로 ?비?야 ?다. ALTER DATABASE BACKUP 구?을 이용?서 데이터베이스 ?영 중에 온라? 백업을 ? 수 있다. 장애로 ?하여 데이터 파?이 손상되거나 지워지는 경우에도 데이터 파?을 현재 시점까지 매체 복구 (media recovery)가 가능하다. [그림 6-14] 매체 복구 (Media Recovery)의 개념 디스크 테이블스페이스의 데이터 파? xyz가 손상되었을 경우에 이?에 HOT 백업? 두었던 데이터 파?을 이용?서 복구가 가능하다. 메모리 테이블스페이스의 경우는 이?에 HOT 백업? 두었던 체크포?트 이미지 파?을 이용?서 복구가 가능하다. Media Recovery 아카이브 로그 files Online Log files LSN3 1 LSN3 2 LSN … LSN9 9 LSN1 00 LSN1 01 Datafile xyz : createLSN(21:000) checkpointSCN(200) Log Anchor File checkpointSCN = 140 recoveryLSN(32:010) Hot backup 받은 이? Datafile Datafile : xyz 테이블스페이스 135 백업? 둔 데이터 파?의 헤더에는 백업 시점에 최종 체크포?트된 SCN (140)과 recovery LSN (32:010)이 있으므로, 이를 기?으로 현재의 최종 체크포?트 SCN (200)까지 데이터 파?을 복원? 수 있다. 재시작 시점에 온라? 로그의 리두 (Redo)와 ?두 (Undo) 로그를 이용?서 데이터 파? 또는 메모리 테이블스페이스의 가장 최? 상태 이미지로 복구된다. 테이블스페이스 오프라인 백업 (Cold 백업) 테이블스페이스의 오프라? 백업은 테이블스페이스의 서비스 ?행을 중단하고, 백업하는 형태를 의미?다. 오프라? 백업 방식은 온라? 백업보다 빠르며, 회복에 걸리는 시?을 단축시킨다. 오프라? 백업은 다음과 같은 특징을 갖는다. 오프라? 백업은 데이터베이스가 노-아카이브 모드로 ?영될 때 가능하다. 오프라? 백업이? 데이터베이스 서버를 정상 종료 시킨 후에 데이터 파?, 로그 파?, 로그 앵커(log anchor) 파? 등을 복사하는 방식이다. 장애로 ?하여 데이터 파?이 손상되거나 지워지는 경우에는 최종 오프라? 백업된 시점까지? 복구가 가능하다. 오프라인 복구 복구는 백업 이미지를 바탕으로 데이터베이스를 ?관적? 상태로 ?드는 과정이다. 복구는 데이터베이스가 온라? 중에는 ?행될 수 없으며, 반드시 오프라?으로 ?행되어야 ?다. 데이터베이스의 서비스를 중지? 상태에서 기? 데이터베이스를 오프라? 백업된 파?로 바꾼 후에 재시작함으로써 복구가 수행된다. 136 Administrators Manual 테이블스페이스 사용 예제 본 ?에서는 메모리 테이블스페이스와 휘발성 테이블스페이스 사용 예제를 살펴본다. 메모리 테이블스페이스 메모리 테이블스페이스 생성 - 기본 메모리테이블스페이스를 생성하는 가장 ?편? 방법은 아래와 같이 SIZE?에 초기 크기를 명시하면서 CREATE MEMORY TABLESPACE 구?을 이용하는 것이다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M; Create success. 이 경우 기본적으로 자동확장 모드는 OFF가 되며, 테이블스페이스의 크기로 256M의 공?을 ?번에 ?당받게 된다. 테이블스페이스의 256M의 공?을 모두 사용하게 되어, HDB 서버 내에서 ?당 테이블스페이스에 공?을 추가로 ?당5하려 ? 때, 테이블스페이스 공?이 부족하다는 에러 메시지가 발생?다. 또? 체크포?트 경로는 기본적으로 MEM_DB_DIR 프로퍼티에 지정? 하나 혹은 그 이상의 체크포?트 경로가 새로 생성된 테이블스페이스을 위? 체크포?트 경로로 사용된다. altibase.properties 에 아래의 예처럼 두 개의 체크포?트 경로가 명시되어 있다고 가정하자. MEM_DB_DIR프로퍼티의 값이 알티베이스 홈 디렉터리 아래의 dbs1와 dbs2, 두 개로 지정되어 있다. # altibase.properties MEM_DB_DIR = ?/dbs1 MEM_DB_DIR = ?/dbs2 이와 같은 경우에 다음의 쿼리를 사용?서 앞서 생성? USER_MEM_TBS테이블스페이스를 위? 체크포?트 경로로 MEM_DB_DIR에 지정? dbs1과 dbs2가 지정된 것을 확?? 수 있다. iSQL> SELECT CHECKPOINT_PATH FROM V$MEM_TABLESPACE_CHECKPOINT_PATHS WHERE SPACE_ID = (SELECT SPACE_ID FROM V$MEM_TABLESPACES 5 테이블스페이스에 테이블을 생성, 이미 생성되어 있는 테이블에 입력, 또는 테이블의 데이터를 수정하는 경우 테이블스페이스로부터 공?을 추가로 ?당받는다. 테이블스페이스 137 WHERE SPACE_NAME='USER_MEM_TBS'); CHECKPOINT_PATH --------------------------------------------------- /altibase_home/dbs1 /altibase_home/dbs2 2 rows selected. 우선, 체크포?트 경로 ?의 파?들을 살펴보자. dbs1 디렉터리 내에 다음과 같이 6개의 파?이 ?재하는 것을 볼 수 있다. SYS_TBS_MEM_DATA-0-0 SYS_TBS_MEM_DATA-1-0 SYS_TBS_MEM_DIC-0-0 SYS_TBS_MEM_DIC-1-0 USER_MEM_TBS-0-0 USER_MEM_TBS-1-0 이 파?들은 모두 메모리 테이블스페이스의 체크포?트 이미지 파?이다. 파? 이름의 형식은 테이블스페이스이름-{Ping Pong번호}-{파?번호}이다. Ping Pong 번호는 0 또는 1로, 이는 두 개의 체크포?트 이미지 중 핑퐁 체크포?트6시에 사용된 하나를 가리킨다. 또?, 각 체크포?트 이미지들을 여러 개의 파?로 나누어 기록하는데, 파? 이름의 맨 ?지링 파?번호가 바로 나누어? 체크포?트 이미지 파?의 번호이며, 0부터 시작하여 1씩 증가?다. 체크포?트 이미지 파? 하나의 크기는 CREATE TABLESPACE 구?의 SPLIT EACH?에 지정된다. 위의 CREATE MEMORY TABLESPACE 구?에서는 SPLIT EACH?을 사용하지 않기 때?에, 기본값으로 DEFAULT_MEM_DB_FILE_SIZE프로퍼티에 지정된 1GB 단위로 체크포?트 이미지 파?들이 분?될 것이다. 위 세 개의 테이블스페이스에 사용된 공?이 아직 1GB에 도달하지 않았기 때?에, 파?번호는 0까지? ?재하는 것을 볼 수 있다. 위에서 SYS_TBS_MEM_DIC은 메타 데이터를 지니는 시스템 딕셔너리 테이블스페이스이다. 이 테이블스페이스는 데이터베이스 생성시 자동으로 ?들어?다. SYS_TBS_MEM_DATA는 기본 시스템 데이터 테이블스페이스이다. 사용자가 테이블스페이스를 명시하지 않고 테이블을 생성? 때, 테이블의 데이터는 이 테이블스페이스에 저장된다. ?지링으로, USER_MEM_TBS가 바로 앞서 생성? 사용자 정의 데이터 테이블스페이스이다. 참고로, CREATE MEMORY TABLESPACE 구?에서 SIZE?에 지정하는 초기 크기는 확장 증가 크기의 배수여야 ?다. 예를 들어 6 알티베이스는 메모리 상에 ?재하는 테이블스페이스의 데이터의 영속성(Durability) 보장을 위? 디스크의 파?에 데이터를 저장?다. 이와 같이 테이블스페이스의 데이터가 저장되는 파?을 체크포?트 이미지라고 ?다. 알티베이스가 사용하는 핑퐁 체크포?트 방식은 두 벌의 체크포?트 이미지를 두고, 하나씩 번갈아 가면서 테이블스페이스의 데이터가 저장된다. 138 Administrators Manual 메모리 테이블스페이스가 확장될 때 증가? 페이지의 개수를 지정하는 EXPAND_CHUNK_PAGE_COUNT프로퍼티의 값이 128이면, 하나의 메모리 페이지는 32KB이므로, 메모리 테이블스페이스의 기본 확장 증가 크기는 4MB(128 * 32KB)가 된다. ?약 SIZE?에 지정? 크기가 확장 증가 크기로 나누어 떨어지지 않을 경우, 다음과 같이 에러가 발생?다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 1M; [ERR-110EE : The initial size of the tablespace should be a multiple of expand chunk size ( EXPAND_CHUNK_PAGE_COUNT * PAGE_SIZE(32K) = 4096K )] 메모리 테이블스페이스 생성 - 종합 메모리 테이블스페이스의 다양? 생성 방법에 대? 알아본다. 다음은 테이블스페이스의 초기 크기를 256M, 자동확장 모드를 ON으로 하고 ?번 확장시?다 128M씩 확장하되, 최대 1G이상 확장되지 않도록 하는 예제이다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M AUTOEXTEND ON NEXT 128M MAXSIZE 1G; Create success. 이 때, 테이블스페이스의 자동확장 증가 크기는 테이블스페이스의 초기 크기와 ??가지로 (EXPAND_CHUNK_PAGE_COUNT 프로퍼티 * ? 페이지의 크기)의 배수로 설정되어야 ?다. 자세? 내용은 위의 메모리 테이블스페이스의 생성 - 기본을 참고?다. 다음과 같이 MAXSIZE를 제?하지 않도록 테이블스페이스를 생성? 수 있다. MAXSIZE?을 지정하지 않는 경우에 UNLIMITED를 지정? 것과 같이 동작?다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M AUTOEXTEND ON NEXT 128M MAXSIZE UNLIMITED; Create success. 이 경우 USER_MEM_TBS는 시스템에 ?재하는 모? 메모리 테이블스페이스에 ?당된 크기가 MEM_MAX_DB_SIZE를 ?어나지 않는 ?도 내에서 확장된다. 다음과 같이 체크포?트 경로를 명시하여 메모리 테이블스페이스를 생성? 수도 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M CHECKPOINT PATH 'dbs1', '/new_disk/dbs2'; Create success. 위의 예제처럼, 상대경로 dbs1을 체크포?트 경로로 지정하는 것은 $ALTIBASE_HOME/dbs1을 지정하는 것과 동?하다. 또?, CREATE TABLESPACE 구?에 지정? 체크포?트 경로를 실제로 파? 시스템에 생성하고, 거기에 쓰기와 실행 권?을 주는 작업은 테이블스페이스 139 테이블스페이스를 생성하기 ?에 DBA가 수동으로 ?야 ?다. 다음과 같이 체크포?트 이미지 파?의 분? 크기를 결정? 수도 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M SPLIT EACH 512M; Create success. 체크포?트 이미지 파?의 분? 크기 역시 테이블스페이스의 초기크기와 ??가지로 (EXPAND_CHUNK_PAGE_COUNT 프로퍼티 * ? 페이지의 크기)의 배수에 ?당하는 크기로 지정되어야 ?다. 자세? 내용은 메모리 테이블스페이스의 생성 - 기본편을 참고?다. 테이블스페이스를 오프라?(OFFLINE) 상태로 생성?두고, 나중에 ?당 테이블스페이스를 사용하기 ?에 온라?(ONLINE) 상태로 ?이? 수도 있다. 메모리 테이블스페이스의 경우 생성된 크기?큼 시스템의 메모리를 차지하게 되므로, 생성 후 즉시 사용하지 않을 경우, 이와 같은 방법으로 시스템의 리소스를 최적으로 ?용? 수 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M OFFLINE; Create success. iSQL> ALTER TABLESPACE USER_MEM_TBS ONLINE; Alter success. 지금까지 살펴본 메모리 테이블스페이스 생성 옵?을 조합하여 테이블스페이스를 생성? 수도 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M AUTOEXTEND ON NEXT 128M MAXSIZE 1G CHECKPOINT PATH 'dbs1', '/new_disk/dbs2' SPLIT EACH 512M OFFLINE; Create success. 메모리 테이블스페이스에 체크포인트 경로 추가 이 ?에서는 메모리 테이블스페이스에 체크포?트 경로를 추가하는 ?차에 대? 알아본다. 메모리 테이블스페이스를 위? 체크포?트 경로는 컨트롤(CONTROL) 구동 단계에서? 설정이 가능하다. 우선 알티베이스 서버를 종료 시킨 후에 다음과 같이 컨트롤 단계까지 알티베이스를 기동?다. $ isql -u sys -p manager -sysdba iSQL(sysdba)> startup process iSQL(sysdba)> startup control 컨트롤 단계에서는 테이블스페이스 관? 성능 뷰? V$TABLESPACES를 조회? 수 있다. 메모리 테이블스페이스 특유의 속성들을 볼 수 있는 성능 뷰? V$MEM_TABLESPACES는 메타(META) 단계 이후에? 조회가 가능하다. 대?, 컨트롤 140 Administrators Manual 단계에서는 V$TABLESPACES를 이용하여 메모리 테이블스페이스 조회가 가능하다. 앞서 생성? USER_MEM_TBS 테이블스페이스를 위? 체크포?트 경로를 조회하기 위?서는 V$MEM_TABLESPACE_CHECKPOINT_PATHS성능 뷰를 이용하면 된다. ?약 테이블스페이스의 데이터가 빈번하게 변경되어 체크포?트시 디스크 I/O의 양이 증가했다면, 이는 다음과 같이 기?의 체크포?트 경로와 물리적으로 다른 디스크에 새로? 체크포?트 경로를 추가?서 경감시킬 수 있다. USER_MEM_TBS에 /new_disk/dbs3경로를 새로 추가?보자. 우선, 추가하고자 하는 체크포?트 경로와 디렉터리를 생성하고, 알티베이스 프로세스가 ?당 디렉터리에 쓰기와 실행권?을 가지도록 권?을 설정?야 ?다. 알티베이스 프로세스를 수행하는 ?영체제의 사용자 계정이 altibase라고 가정?다. $ su - root $ mkdir /new_disk/dbs3 $ chown altibase /new_disk/dbs3 이제 다음과 같이 ADD CHECKPOINT PATH구?을 이용하여 체크포?트 경로를 추가? 수 있다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS ADD CHECKPOINT PATH '/new_disk/dbs3'; Alter success. 기?의 체크포?트 경로에 ?재하는 체크포?트 이미지 파?들을 새로 추가된 체크포?트 경로로 이동시키는 것은 DBA의 책임이다. 알티베이스는 체크포?트 경로가 추가된 이후에 체크포?트가 발생? 경우, 새로 체크포?트 이미지 파?을 생성? 때, 추가된 체크포?트 경로에 체크포?트 이미지 파?을 생성?다.7 메모리 테이블스페이스의 체크포인트 경로 변경 이 ?에서는 메모리 테이블스페이스의 체크포?트 경로를 변경하는 ?차에 대? 알아본다. 메모리 테이블스페이스를 위? 체크포?트는 컨트롤(CONTROL) 구동 단계에서? 설정이 가능하다. 앞서 메모리 테이블스페이스에 체크포?트 경로 추가 ?에서 알아본 것과 같이 우선 알티베이스 HDB 서버를 종료 시킨 후에 컨트롤 단계까지 알티베이스 HDB를 기동?다. 본 예제는 기?의 체크포?트 경로? 알티베이스 홈 디렉터리 7 체크포?트시 테이블스페이스의 체크포?트 이미지 파?을 새로 생성? 경우 테이블스페이스에 속? 각각의 모? 체크포?트 경로를 하나씩 번갈아가면서 사용?다. 테이블스페이스 141 아래의 dbs1을 새로 설치? 디스크? /new_disk로 옮기는 ?차를 보여?다. 체크포?트 경로를 변경하기 위?서는 기?의 체크포?트 경로를 ?대경로로 정확히 입력? 주어야 ?다. 컨트롤 단계에서 테이블스페이스의 체크포?트 경로를 보는 방법은 위의 메모리 테이블스페이스에 체크포?트 경로 추가?을 참고?다. 체크포?트 경로를 변경? 때에는 체크포?트 경로를 추가?때와 ??가지로 다음과 같이 변경? 체크포?트 경로와 디렉터리를 DBA가 직접 생성하고, 그 디렉터리에 대? 쓰기 및 실행 권?을 알티베이스 프로세스를 실행하는 OS 사용자 계정에 부여?야 ?다. 알티베이스 프로세스를 실행하는 사용자 계정이 altibase라고 가정?다. $ su - root $ mkdir /new_disk/dbs1 $ chown altibase /new_disk/dbs1 이제, 다음과 같이 RENAME CHECKPOINT PATH를 이용하여 알티베이스 홈의 dbs1이라는 체크포?트 경로를 새로 추가? 디스크? /new_disk/dbs1으로 변경? 수 있다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS RENAME CHECKPOINT PATH '/opt/altibase_home/dbs1' TO '/new_disk/dbs1'; Alter success. ?지링으로 기?의 알티베이스 홈 디렉터리의 dbs1?의 USER_MEM_TBS 테이블스페이스의 체크포?트 이미지들을 모두 /new_disk/dbs1으로 옮겨주어야 ?다. $ mv $ALTIBASE_HOME/dbs1/USER_MEM_TBS* /new_disk/dbs1 메모리 테이블스페이스의 체크포인트 경로 제거 이 ?에서는 메모리 테이블스페이스의 체크포?트 경로를 제거하는 ?차에 대? 알아본다. 메모리 테이블스페이스를 위? 체크포?트는 컨트롤(CONTROL) 구동 단계에서? 설정이 가능하다. 앞서 메모리 테이블스페이스에 체크포?트 경로 추가?에서 알아본 것과 같이 우선 알티베이스 서버를 종료 시킨 후 컨트롤 단계까지 알티베이스를 기동?다. 본 예제는 기?의 체크포?트 경로? 알티베이스 홈 디렉터리의 dbs2를 제거하는 ?차를 보여?다. 체크포?트 경로를 변경하기 위?서는 기?의 체크포?트 경로를 ?대경로로 정확히 입력? 주어야 ?다. 컨트롤 단계에서 테이블스페이스에 속? 체크포?트 경로를 보는 방법은 위의 메모리 142 Administrators Manual 테이블스페이스에 체크포?트 경로 추가?을 참고?다 이제, 다음과 같이 DROP CHECKPOINT PATH 명령을 이용하여 알티베이스 홈 디렉터리의 dbs2라는 체크포?트 경로를 제거? 수 있다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS DROP CHECKPOINT PATH '/opt/altibase_home/dbs2' Alter success. ?지링으로 기?의 알티베이스 홈 디렉터리의 dbs2?의 USER_MEM_TBS 테이블스페이스를 위? 체크포?트 이미지들을 USER_MEM_TBS의 다른 체크포?트 경로중 하나로 옮겨주어야 ?다. $ mv $ALTIBASE_HOME/dbs2/USER_MEM_TBS* /new_disk/dbs1 메모리 테이블스페이스의 자동확장 설정 변경 이 ?에서는 메모리 테이블스페이스의 자동확장 설정을 변경하는 ?차에 대? 알아본다. 메모리 테이블스페이스 생성시 자동확장 구?을 명시하지 않으면, 기본으로 ?당 테이블스페이스는 자동확장이 되지 않도록 설정된다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M; Create success. 이 때 자동확장을 하도록 설정하는 가장 ?단? 구?은 다음과 같다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON; Alter success. 위 예에서 테이블스페이스는 메모리 테이블스페이스의 기본 확장단위? EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 설정? 페이지 개수에 ?당하는 크기?큼씩 확장될 것이다. 또? 최대 크기로 UNLIMITED을 지정? 것과 같이 동작하여 시스템내의 모? 메모리 테이블스페이스의 현재 크기의 총합이 MEM_MAX_DB_SIZE 프로퍼티를 ?어나지 않는 ?도내에서 테이블스페이스는 확장될 것이다. 메모리 테이블스페이스는 디스크 테이블스페이스와 달리, 체크포?트 이미지 파?을 DBA가 직접 관리? 필요가 없다. 자동확장이 필요? 경우 알티베이스가 체크포?트 이미지파?을 자동으로 생성하기 때?이다. 메모리 테이블스페이스의 확장단위를 지정하기 위?서는 다음과 같은 구?을 사용?다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON NEXT 128M; Alter success. 테이블스페이스 143 메모리 테이블스페이스의 최대 크기를 지정하기 위?서는 다음과 같은 구?을 사용?다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON MAXSIZE 1G; Alter success. 메모리 테이블스페이스의 확장 크기와 최대 크기를 함께 지정하기 위?서는 다음과 같은 구?을 사용?다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON NEXT 128M MAXSIZE 1G; Alter success. 메모리 테이블스페이스의 자동확장 설정을 끄기 위?서는 다음과 같은 구?을 사용?다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND OFF; Alter success. 메모리 테이블스페이스의 온라인(ONLINE) 및 오프라인(OFFLINE)으로의 ?이 본 예제는 메모리 테이블스페이스를 온라? 상태에서 오프라? 상태로, 그리고 그 반대로 ?이하는 방법을 보여?다. 알티베이스 메모리 테이블스페이스의 모? 데이터는 메모리에 적재된다. 이로 ?하여 메모리 테이블스페이스가 사용중? 공??큼 시스템의 메모리가 ?당된다. 알티베이스는 이러? 메모리 사용을 DBA가 손쉽게 제어? 수 있도록, 메모리 테이블스페이스에 메모리를 ?당하고 메모리를 반납? 수 있는 기능을 제공?다. 물?, 메모리 테이블스페이스의 메모리가 반납된 상황에서는 ?당 테이블스페이스 ?에 생성된 모? 객체를 ?시적으로 사용? 수 없게 된다. 메모리 테이블스페이스의 메모리를 반납하기 위?서는 테이블스페이스를 오프라?으로 ?이하면 된다. iSQL> ALTER TABLESPACE USER_MEM_TBS OFFLINE; Alter success. 추후 ?당 메모리 테이블스페이스 ?에 생성된 테이블을 사용하기 위?서는 다음과 같이 테이블스페이스를 온라?으로 ?이?다. iSQL> ALTER TABLESPACE USER_MEM_TBS ONLINE; Alter success. 휘발성 테이블스페이스 휘발성 테이블스페이스 생성 기본적으로 휘발성 테이블스페이스 생성, 변경, 삭제 구?은 메모리 테이블스페이스의 생성, 변경, 삭제 구?과 거의 동?하다. 다? 144 Administrators Manual 체크포?트 이미지 파? 관? 구?은 사용? 수 없다는 차이점이 있다. 다음 구?으로 256M 크기의 휘발성 테이블스페이스를 생성? 수 있다. iSQL> CREATE VOLATILE DATA TABLESPACE USER_VOL_TBS SIZE 256M; Create success. 이 경우 테이블스페이스의 크기는 256MB로 고정되어 있어 자동확장은 불가능하다. 다음 구?은 자동 확장되는 테이블스페이스를 생성?다. iSQL> CREATE VOLATILE DATA TABLESPACE USER_VOL_TBS SIZE 256M AUTOEXTEND ON; Create success. 이 경우 테이블스페이스의 초기 크기는 256MB이지? 자동 확장 되며, VOL_MAX_DB_SIZE 프로퍼티의 값이 허용하는 ?큼 확장될 수 있다. 자동 확장 단위는 4MB이다. 자동 확장 단위를 8MB로, 최대 512MB까지? 확장? 수 있게 하려면 다음 구?으로 생성하면 된다. iSQL> CREATE VOLATILE DATA TABLESPACE USER_VOL_TBS SIZE 256M AUTOEXTEND ON NEXT 8M MAXSIZE 512M; Create success. 휘발성 테이블스페이스 변경 휘발성 테이블스페이스에 대? 자동 확장 모드, 자동 확장 단위, 최대 크기 등을 변경? 수 있다. 다음 구?은 자동 확장이 ?되는 휘발성 테이블스페이스를 자동 확장 모드로 변경?다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND ON; Alter success. 위 구?을 이미 자동 확장 모드가 가능하도록 설정된 테이블스페이스에 사용하면 에러가 발생?다. 다음 구?은 자동 확장 모드로 바꾸면서 자동 확장 단위를 8MB로, 최대 512MB까지 확장? 수 있도록 변경?다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND ON NEXT 8M MAXSIZE 512M; Alter success. 다음 구?은 자동 확장 모드를 끈다. 이 구?은 자동 확장 모드가 켜? 테이블스페이스에 사용? 수 있다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND OFF; Alter success. 자동 확장 모드이면서 자동 확장 단위가 4MB? 테이블스페이스를 자동 확장 단위 8MB로 바꾸려면, 다음처럼 먼저 자동 확장 모드를 끈 후 다시 켜야 ?다. 테이블스페이스 145 iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND OFF; Alter success. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND ON NEXT 8M; Alter success. 테이블스페이스의 삭제(DROP) - 디스크, 메모리, 휘발성 공통 테이블스페이스 폐기(Discard) - 데이터가 손상된 테이블스페이스를 제거 이 ?에서는 테이블스페이스를 폐기하는 ?차에 대? 알아본다. DBA가 실수로 디스크 테이블스페이스의 데이터 파?이나 메모리 테이블스페이스의 체크포?트 이미지 파?을 삭제? 경우, 혹은 매체 오류로 ?하여 ?당 파?의 내용이 유실된 경우에 알티베이스 기동이 불가능??다. 이런 경우에, 매체 복구를 통?서 ?당 파?을 복원하는 방법을 먼저 생각? 볼 수 있다. 하지? 매체 복구는 아카이브 로깅이 수행되어 기?의 로그파?이 별도의 아카이브 공?에 모두 남아 있을 때에? 가능하다. 이와 같이 매체 복구가 불가능? 경우, 데이터 파?이나 체크포?트 이미지 파?이 유실된 특정 테이블스페이스를 ALTER TABLESPACE DISCARD 구?을 사용?서 폐기시켜 버리고 나머지 테이블스페이스들?으로 알티베이스를 기동? 수 있다. 테이블스페이스가 ALTER TABLESPACE DISCARD 구?을 이용하여 ? 번 폐기되면, 그 ?에 생성된 객체에 대? 접?이 불가능?지고, 추후 그 테이블스페이스에 대? ? 수 있는 액?은 그것을 제거(DROP)하는 것뿐이다. 그러므로 이 구? 사용시 ?중?야 ?다. 다음 예제는 메모리 테이블스페이스? USER_MEM_TBS를 생성? 후, 체크포?트 이미지를 삭제? 상태에서 ?당 테이블스페이스? 제외? 나머지 테이블스페이스들로 알티베이스를 기동하는 과정을 보여?다. 우선 다음과 같이 메모리 테이블스페이스를 생성?다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M; Create success. 이제 알티베이스를 종료하고, ?당 테이블스페이스에 속? 체크포?트 이미지 파?을 지?다. 이제 알티베이스를 재기동하면 다음과 같은 에러가 발생?다. [SM-WARNING] CANNOT IDENTIFY DATAFILE [TBS:USER_MEM_TBS, PPID-0-FID-0] Datafile Not Found 146 Administrators Manual [SM-WARNING] CANNOT IDENTIFY DATAFILE [TBS:USER_MEM_TBS, PPID-1-FID-0] Datafile Not Found [FAILURE] The data file does not exist. Startup Failed.... [ERR-91015 : Communication failure.] 알티베이스는 이와 같이 ?부 테이블스페이스의 데이터 파?이나 체크포?트 이미지 파?이 ?재하지 않는 경우 에러를 발생시킨다. 이제 USER_MEM_TBS를 디스카드 ? 차?이다. 디스카드 구?은 컨트롤(CONTROL) 단계에서? 수행이 가능하다. 알티베이스를 컨트롤 단계까지 기동?다. $ isql -u sys -p manager -sysdba iSQL(sysdba)> startup control 이제 체크포?트 이미지 파?이 유실된 테이블스페이스 USER_MEM_TBS를 디스카드 ?다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS DISCARD; Alter success. 그리고 다음과 같이 STARTUP SERVICE명령을 수행하여 알티베이스를 서비스 단계로 ?입시킨다. iSQL(sysdba)> startup service Command execute success. 디스카드 명령은 ?당 테이블스페이스를 버리겠다고 선?하는 것에 불과하다. 그렇기 때?에 ?당 테이블스페이스 및 그 ?의 객체는 DROP TABLESPACE INCLUDING CONTENTS 구?을 이용하여 직접 제거하여야 ?다. iSQL> DROP TABLESPACE USER_MEM_TBS INCLUDING CONTENTS AND DATAFILES; Drop success. ??가지로 디스크 테이블스페이스의 데이터 파?이 유실되거나, 매체 오류 때?에 데이터 파?의 내용중 ?부가 깨? 경우에도 ?당 테이블스페이스를 디스카드시키는 방법으로 알티베이스를 가동? 수 있다. 테이블스페이스의 제거 본 사용 예에서는 테이블스페이스를 제거하는 방법을 보여?다. 테이블스페이스 ?에 어떠? 객체도 생성되어 있지 않은 경우, 다음과 같이 ?편하게 테이블스페이스를 제거? 수 있다. 단, 이 경우 디스크 테이블스페이스의 데이터 파?과 메모리 테이블스페이스의 체크포?트 이미지 파?은 파? 시스템에서 제거되지 않는다. 테이블스페이스 147 iSQL> DROP TABLESPACE MY_TBS; Drop success. ?약, 테이블스페이스 ?에 객체가 ?재?다면 다음과 같이 INCLUDING CONTENTS?을 주어서 테이블스페이스 ?의 모? 객체가 삭제되도록 ?다. 이 경우에도 데이터 파?이나 체크포?트 이미지 파?이 파? 시스템에서 삭제되지는 않는다. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS; Drop success. ?약 삭제하고자 하는 테이블스페이스 ?의 테이블을 참조하는 다른 테이블스페이스의 테이블들로부터 참조 제약(Referential Constraint)을 제거 하려면 다음과 같이 INCUDING CONTENTS?과 함께 CASCADE CONSTRAINTS를 주면 된다. 이 경우에도 데이터 파?이나 체크포?트 이미지 파?이 파? 시스템에서 삭제되지는 않는다. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS CASCADE CONSTRAINTS; Drop success. 디스크 테이블스페이스의 데이터 파?이나 메모리 테이블스페이스의 체크포?트 이미지 파?을 삭제하려면 다음과 같이 INCLUDING CONTENTS? 바로 뒤에 AND DATAFILES?을 주면 된다. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS AND DATAFILES; Drop success. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS; Drop success. 148 Administrators Manual 테이블스페이스 공간 관리 이 ?에서는 알티베이스 HDB의 테이블스페이스 공?을 관리하는 방법에 대하여 설명?다. 언두 테이블스페이스 크기 계산 ?두 테이블스페이스(Undo Tablespace)는 ?두 세그먼트를 저장하기 위? 사용된다. ?두 테이블스페이스가 부족? 경우 트?잭? 성능에 영향을 ? 수 있으므로 DBA는 이를 적?? 크기로 관리?야 ?다. ?약 업무 시스템에서 변경 트?잭?, 특히 오? 시?동? 구?이 실행되는 트?잭?이 자주 발생하는 경우에는 ?두 세그먼트가 계속 확장될 것이다. 이는 ?두 테이블스페이스의 공? 부족을 초래? 수 있다. 사용자는 ?두 테이블스페이스를 자동 확장 모드로 설정하거나, 대략적? 최대 크기를 예측하여 그 예측치를 최대 크기로 지정? 고정 크기 모드로 설정? 수 있다. 언두 테이블스페이스의 자동 확장 모드 사용자가 처음으로 애플리케이?을 수행하는 경우 얼??큼의 ?두 테이블스페이스 공?이 필요?지 알기가 쉽지 않다. 이런 경우에는 ?두 테이블스페이스의 자동 확장 모드를 ?성화하여 필요? 공?까지 자동으로 확장되도록 ?다. 알티베이스는 애플리케이? 개발 ?경에서 ?두 테이블스페이스의 용량을 계획하기 쉽도록 자동 확장 모드를 제공?다. 기본적으로 ?두 테이블스페이스는 자동 확장 모드로 설정되며, ALTER TABLESPACE 구?으로 변경? 수 있다. 언두 테이블스페이스의 고정 크기 모드 사용자가 고정 크기의 ?두 테이블스페이스를 사용하고 싶다면, 필요? 용량을 예측?야 ?다. 이를 위?서 사용자는 애플리케이?이 수행되는 동? 사용되는 TSS 세그먼트 공?과 ?두 세그먼트 공?의 사용 패턴을 수집하여 분석?야 ?다. 필요? ?두 테이블스페이스 크기는 ?반적으로 다음과 같은 계산식으로 대략적? 산출이 가능하다. 테이블스페이스 149 ?두 테이블스페이스 크기 = Long-Term 트?잭? 수행 시?(sec) x (초당 ?당되는 ?두 페이지 개수 + 초당 ?당되는 TSS 페이지 개수) x 페이지 크기(8KB) 예를 들어 Long-Term 트?잭?의 수행 시?이 600초(10분)이고 초당 ?두 페이지 1000개와 TSS 페이지 24개가 ?당된다면, 10 x 60 x (1000 + 24) x 8K = 4800MB이므로 약 4.7G 정도가 필요하다. 이와 같이 예측하는 것이 어렵다면, 디스크 공?이 허락하는 ? 충분히 넉넉? 크기를 ?두 테이블스페이스에 ?당하는 것도 방법이다. 언두 테이블스페이스의 확장 업무 시스템에서 변경 트?잭? (특히 Long-Term 트?잭?, 즉 트?잭?이 커밋되기까지 긴 시?이 소요되는 트?잭?)이 자주 발생하는 경우에 ?두 테이블스페이스의 공? 부족이 발생? 수 있다. 이러? 경우에 ALTER TABLESPACE 구?을 이용하여 ?두 테이블스페이스에 적정? 크기의 데이터 파?을 추가하거나 파?의 크기를 적당히 늘려?다. 메모리 테이블의 크기 추정 데이터 크기 계산 메모리 테이블의 데이터 크기는 각 칼럼의 데이터 타입, 칼럼 정? (alignment)를 위? 패딩(padding) 등에 기반?서 예측이 가능하다. 수학 공식으로 표현하면 다음과 같다: 데이터 크기 = [ (각 칼럼의 추정 크기의 합 + 각 칼럼을 위? 패딩 크기의 합) * 데이터 레코드 개수] 데이터 타입 별 추정 크기는 다음 표에서 보여?다. P = Precision, V = Value length) 자료형 예측 칼럼 크기 INTEGER 4 SMALLINT 2 BIGINT 8 DATE 8 150 Administrators Manual DOUBLE 8 CHAR 2 + P VARCHAR 10 + V NCHAR 2 + P NVARCHAR 10 + V BIT 4 + (P/8) VARBIT 12 + (P/8) FLOAT 4 + (P/2)/2 NUMERIC 12 + (P/2)/2 위 도표에서 P(Precision)는 테이블 생성시 결정된 칼럼의 크기를 가리킨다. P보다 긴 데이터는 ?당 데이터 타입의 칼럼에 입력될 수 없다. V(Value length)는 입력된 데이터의 실제 길이로, V는 P보다 클 수 없다. CHAR, NCHAR, BIT 타입 같은 고정 길이 칼럼은 P ?큼의 공?을 핫상 점유하므로, 칼럼의 길이는 데이터의 실제 길이에 상관없이 고정된다. 그러나 VARCHAR, NVARCHAR, VARBIT같은 가변 길이 칼럼은 점유하는 공?이 데이터 길이에 따라서 가변적이다. 디스크 테이블과 달리, 메모리 테이블은 데이터 접? 속도를 높이기 위? 패딩 공?을 포함?다. 이 공?의 크기는 데이터 타입과 칼럼의 위치에 따라서 가변적이다. 인덱스 크기 추정 메모리 ?덱스는 테이블 데이터가 저장되는 테이블스페이스에 저장되지 않는다. 대?에 이는 메모리 공?에 독립적으로 저장된다. 데이터 저장 위치를 가리키는 포?터가 메모리 ?덱스 노드의 각 버킷에 저장되기 때?에, ?덱스 크기는 데이터 타입에 상관없이 포?터 크기와 테이블에 현재 저장된 레코드의 개수에 기반하여 추정? 수 있다. ?덱스 크기 = (데이터 레코드의 개수) * p ( p = 포?터 크기 ) 위 공식에서 p는 포?터 크기, 즉 ? 포?터를 저장하는데 필요? 크기이다. 32-bit 시스템에서는 이 크기가 4바이트이고, 64-bit 시스템에서는 이 크기가 8바이트이다. 이 공식에서, ?덱스의 크기는 모? 리프 노드 (즉, B트리의 최하위의 노드)의 총 크기?큼이다. B트리에는 리프 노드에 더?서 ?터널 노드 (즉, 리프 노드의 상위 노드)가 있는데, 이의 총 크기는 리프 노드 크기의 1/128 에 불과하므로 무시?도 된다. ?덱스 관리에 사용되는 추가 테이블스페이스 151 정보를 저장하는 크기도 리프 노드 크기의 1/16 정도로 무시??큼 작다. 그러므로 모? 리프 노드의 총 크기에 기반?서 ?덱스의 총 크기를 계산하면 된다. 그러나 이 공식은 리프 노드의 모? 버킷이 그 ?에 키 값을 가지고 있는 상황?을 고려? 것이기 때?에, 이 공식을 이용?서 추정된 값은 ?덱스의 실제 크기와 다를 수 있다. 즉, 노드 내에 빈 버킷이 ?이 있다면 ?덱스의 실제 크기는 추정된 크기보다 ?이 클 수 있다. 이 경우 ?덱스를 재구축?서 ?덱스 크기를 ?? 수 있다. 예제 1 아래처럼 테이블이 생성된 경우 데이터 크기를 추정? 보자. CREATE TABLE T1 ( C1 Integer, C2 char(1024), C3 varchar(1024) ) tablespace user_data01; 이 테이블의 칼럼 C1과 칼럼 C2는 고정 길이 칼럼이고 C3는 가변 길이 칼럼이다. 그러므로 ? 레코드의 크기는 칼럼 C3에 따라 변? 것이다. 이를 고려하여 ? 레코드의 크기를 계산하면, 아래처럼 T1테이블의 데이터 크기는 (? 레코드 크기 * 레코드 개수)와 같다. [record header] = 24 bytes [column C1] = 4 bytes [column C2] = 2+P bytes = 2+1024 bytes [column C3] = 10+V bytes 칼럼 C3의 데이터 길이가 200바이트이면: [record size] = 24 + ( 4 ) + (2+1024) + (10+200) + padding = (1264 + padding) bytes 칼럼 C3의 데이터 길이가 200바이트이면: [record size] = 24 + ( 4 ) + (2+1024) + (10+500) + padding = (1564 + padding) bytes 예제 2 아래 구?으로 생성된 테이블 T1의 ?덱스 크기를 계산? 보자. 테이블 T1에는 현재 500,000 레코드가 있고, 시스템은 64-bit이다. CREATE TABLE T1 ( C1 Integer, C2 char(300), C3 varchar(500)) tablespace user_data01; CREATE INDEX T1_IDX1 ON T1( C1, C2, C3 ); [index size] = 500,000 records * 8 = 3.814 Megabytes 예제 3 아래 구?으로 생성된 테이블의 데이터와 ?덱스 크기를 계산? 보자. 테이블에는 현재 1,000,000 레코드가 있고, 시스템은 64- 152 Administrators Manual bit이다. CREATE TABLE TEST001 ( C1 char(8) primary key, C2 char(128), N1 integer, IN_DATE date) tablespace user_data01; ? 레코드의 크기와 총 데이터 크기 [The size of a record] = 24[header size] + (2+8) + (2+128) + (4) + (8) = 176 bytes [The total size of all records] = [ 176 ] * 1,000,000 records = 167.84 Mbytes ?덱스 크기 [total index size] = 8 * 1,000,000 records = 7.629 Megabytes 이 값은 데이터 크기와 리프 노드의 크기에 기반?서 계산되었기 때?에, 실제로는 페이지 헤더, ?덱스 노드, 그리고 프리 (free) 페이지 관리를 위? 메모리에 사용되는 공?이 추가로 있을 것이다. 디스크 테이블의 크기 추정 알티베이스의 디스크 테이블 크기는 자료형과 데이터의 구성을 바탕으로 계산? 수 있으며 [테이블 로우의 총 길이 * 데이터 건 수] 의 값을 가?다. 다음 표는 자료형 별 길이를 보여?다. (P = Precision, V = Value length) 자료형 추정되는 칼럼 크기 Null 250바이트 이하 251바이트 이상 Integer 1 5 X SmallInt 1 3 X BigInt 1 9 X Date 1 9 X Double 1 9 X Char 1 1+P 3+P Varchar 1 1+V 3+V NChar 1 1+P 3+P NVarchar 1 1+V 3+V Bit 1 5+(P/8) 7+(P/8) Varbit 1 5+(V/8) 7+(V/8) Float 1 4+(V+2) / 2 6 +(V+2) / 2 Numeric 1 4+(V+2) / 2 6 +(V+2) / 2 테이블스페이스 153 위 도표에서 P(Precision)는 테이블 생성시 결정된 칼럼의 최대 크기이다. P 보다 큰 길이를 갖는 데이터는 그 타입의 칼럼에 입력되지 않는다. 또? 고정길이 칼럼? CHAR, NCHAR, BIT 등은 핫상 P ?큼의 공?을 점유하기 때?에, 데이터의 길이와 상관없이 칼럼의 길이는 ?정하다. V(Value length)는 실제로 삽입된 데이터의 실제 길이로, P보다 클 수 없다. 또? 가변 길이 칼럼? VARCHAR, NVARCHAR, VARVIT등은 데이터의 크기에 따라 점유하는 공?의 크기가 달라?다. 따라서 데이터의 크기에 따라 칼럼의 크기가 변?다. 로우(row) 크기 추정 이 ?에서는 테이블 스키?가 다음과 같을 경우, 로우 크기를 계산하는 방법에 대? 설명?다. CREATE TABLE T1 ( C1 char(32), C2 char(1024), C3 varchar(512) ) tablespace user_data02; 이 스키?에서 C1 칼럼과 C2 칼럼은 고정길이 칼럼이며, C3 칼럼은 가변길이 칼럼이다. 따라서 C3 칼럼의 크기에 따라 로우의 크기가 변?다. 또? 칼럼에 널(NULL)이 ?재하는지 여부에 따라 로우의 크기가 변?다. 이를 고려하여 로우의 크기를 계산하면 아래와 같으며, 테이블 T1의 크기는 (? 로우의 총 길이 * 데이터 건 수)가 된다. [로우 헤더] 34 바이트 [C1 칼럼] 1+P 바이트 = 1+32 바이트 [C2 칼럼] 3+P 바이트 = 3+1024 바이트 [C3 칼럼] 3+V 바이트 C3 칼럼의 데이터 크기가 200 바이트? 경우 [총 길이] 34 + (1+32) + (3+1024) + (3+200) = 1297 바이트 C3 칼럼의 데이터 크기가 500 바이트? 경우 [총 길이] 34 + (1+32) + (3+1024) + (3+500) = 1597 바이트 C2 칼럼이 널이고, C3 칼럼의 데이터 크기가 300 바이트? 경우 [총 길이] 34 + (1+32) + (1) + (3+300) = 371 바이트 C3 컬림이 널? 경우 [총 길이] 34 + (1+32) + (3+1024) + (0) = 1094 바이트 인덱스(index) 크기 추정 ?덱스의 크기 역시 자료형과 데이터의 구성을 바탕으로 계산? 수 154 Administrators Manual 있다. 다음 표는 ?덱스 크기 계산 시 사용? 자료형 별 길이를 보여?다. (P = Precision, V = Value length) 자료형 ?덱스 키의 크기 Null 250바이트 이하 251바이트 이상 Integer 4 4 X SmallInt 2 2 X BigInt 8 8 X Date 8 8 X Double 8 8 X Char 1 1+P 3+P Varchar 1 1+V 3+V NChar 1 1+P 3+P NVarchar 1 1+V 3+V Bit 1 5+(P/8) 7+(P/8) Varbit 1 5+(V/8) 7+(V/8) Float 1 4+(V+2) / 2 6+(V+2) / 2 Numeric 1 4+(V+2) / 2 6+(V+2) / 2 위 도표에서 P(Precision)와 V(Value length)는 각각 테이블 생성시 결정된 칼럼의 최대 크기와 실제로 삽입된 데이터의 크기를 의미?다. ? ?덱스의 크기는 다음과 같다. [ 10(헤더 길이) + (키 칼럼 길이의 합) ] * 데이터 건 수 위의 계산 공식은 leaf node (B*Tree에서 최하위의 노드)의 대략적? 크기이다. 이 외에 internal node(leaf node의 상위 노드)의 크기의 경우, 키 칼럼(key column)의 크기가 작을 경우에는 무시? 수 있을 정도로 그 크기가 작다. 하지? 키 칼럼의 크기가 2K이상? 경우에는 B*Tree의 깊이가 깊어지고, internal node의 크기가 ?체 Leaf Node 크기의 50% 정도까지 될 수 있으므로 이런 경우에는 internal node의 크기를 계산에 포함?야 ?다. 다음은 테이블 및 ?덱스의 스키?가 다음과 같을 경우, ?덱스의 크기를 계산하는 방법을 보여?다. CREATE TABLE T1 ( C1 Integer, C2 varchar(500)) tablespace user_data02; CREATE INDEX T1_IDX1 ON T1( C1, C2 ); C1 칼럼은 Integer 형이므로 핫상 4 byte로 크기가 결정된다. C2는 테이블스페이스 155 가변길이 칼럼으로 데이터의 크기에 따라 길이가 가변적으로 변?다. [키 헤더] 10 byte [C1 칼럼] 4 byte [C2 칼럼] 1+V byte C2 칼럼의 데이터 크기가 50 바이트? 경우 [총 길이] 10 + 4 + (1+50) = 65 바이트 C2 칼럼의 데이터 크기가 500 바이트? 경우 [총 길이] 10 + 4 + (3+500) = 517 바이트 C2 칼럼이 널? 경우 [총 길이] 10 + 4 + 1 = 15 바이트 테이블 크기 계산 예제 테이블 스키?가 다음과 같고 데이터 건 수가 100? 건? 경우에, 로우의 크기와 ?덱스의 크기를 포함? 테이블의 크기를 다음과 같이 계산?다. CREATE TABLE TEST001 ( C1 char(8) primary key, C2 char(128), N1 integer, IN_DATE date) tablespace user_data02; 로우 크기 및 ?체 데이터 크기 로우 크기: 34[헤더] + (1+8) + (1+130) + (1+4) + (1+8) = 188 바이트 ?체 데이터 크기: [ 188 ] * 100? 건 = 179.29 M 바이트 ?덱스 크기 ? 로우의 ?덱스 크기: 10[헤더] + (1+8)[C1] = 19 바이트 ?체 ?덱스 크기: 19 * 100?건 = 18.12 M 바이트 TEST001 테이블 ?체가 차지하는 디스크 크기 179.29 (데이터 크기) + 18.12(?덱스 크기) = 197.41 M 바이트 이것은 데이터의 크기? 계산? 것으로, 실제로는 페이지 헤더, internal node, 세그먼트 관리 영역 등을 추가로 사용하며 그?큼 공?을 더 사용?다. 이러? 부분을 고려하면, 총 테이블 스페이스는 약 240M 바이트를 사용하게 될 것이다. 테이블 저장 공간 계산 위에서 테이블의 크기 계산에 사용된 테이블 TEST001을 기?으로 테이블의 레코드와 ?덱스를 모두 저장? 수 있는 테이블의 적정 156 Administrators Manual 사이즈를 계산?다. 적정? 테이블 크기를 계산하기 위?서 다음과 같은 사핫을 고려?야 ?다. 트랜잭션의 유형의 상대 빈도를 고려한다 특정 테이블에 대하여 갱? (Update) 트?잭?이 ?이 발생? 경우에는 트?잭?의 성능을 높이기 위? PCTFREE를 크게 하고, PCTUSED를 작게 하여 변경 작업을 위? 필요? 빈 공?(free space)을 ?이 확보하는 것이 좋다. 변경 트?잭?이 적고 입력(Insert) 트?잭?이 주로 발생하는 테이블의 경우에는 반대로 PCTFREE를 작게하고, PCTUSED를 크게 하여 불필요? 빈 공?(free space)을 최소화?야 ?다. PCTFREE 기본값은 10으로, 디스크 테이블 생성시 0에서 99 사이의 값을 명시? 수 있다. 이는 테이블의 각 페이지에서 기? 레코드에 대? 변경 연산 등을 위하여 미리 예약? 여유 공?의 비율이다. 따라서 PCTFREE가 10이고 입력(Insert) 트?잭?? 발생?다고 가정? 경우에 테이블의 ?체 크기가 100M 라면 테이블의 레코드와 ?덱스를 위? 사용될 수 있는 공?은 90M가 된다. PCTUSED 기본값은 40이며 디스크 테이블 생성시 0에서 99 사이의 값을 명시? 수 있다. 특정 페이지가 PCTFREE에서 명시? 비율에 도달? 후에 변경과 삭제로 ??서 빈 공?의 비율이 40% 미?(39%)으로 될 때까지 ?당 페이지에는 삽입 연산이 ?어나지 않는다. 따라서 변경이 ?이 발생하는 테이블? 경우에는 테이블의 크기를 산정? 때 여유 공?을 ?이 확보?야 ?다. 상황 테이블 사이즈 계산 대부분이 Read Only 트 ?잭?이거나 UPDATE 시에 레코드의 크기가 증가 되지 않을 경우 PCTFREE를 5로 지정하고, PCTUSED를 90으로 지정? 경우 ① 최소 테이블 크기 계산: TEST001(?체사이즈=215.53M)테이블을 저장 하기 위?서 필요? 최소 사이즈는 다음과 같은 공식으로 계산?다. 테이블 ?체 사이즈 / [1-(PCTFREE / 100)] = 215.53/0.95 ≒ 227M ② 가중치 계산: 최소 사이즈에 적?? 크기의 가중치를 추가? 테이블스페이스 157 다. 가중치는 시스템 상황에 따라 달라질 수 있 다. 다음은 가중치 계산의 ?가지 예이다. 최소사이즈 * [ 1- (PCTUSED / 100) ] * 2 = 227 * 0.1 * 2 ≒ 45M ③ 따라서 테이블을 총 272M 정도의 사이즈로 생성?다. UPDATE가 빈번하고, UPDATE 시에 레코드 의 크기가 증가될 경우 PCTFREE를 20으로 지정하고, PCTUSED를 40 으로 지정? 경우 ① 최소 테이블 크기 계산: TEST001(?체사이즈=213.63M)테이블을 저장 하기 위?서 필요? 최소사이즈는 다음과 같은 공식으로 계산?다. 테이블?체사이즈 / [1-(PCTFREE / 100) = 213.63/0.8 ≒ 267M ② 가중치 계산: 최소 사이즈에 적?? 가중치를 추가?다. 다음 은 가중치 계산의 ?가지 예이다. 최소 사이즈 * [ 1- (PCTUSED / 100) ] * 2 = 267 * 0.6 * 2 ≒ 320M ③ 따라서 테이블을 총 587M 정도의 사이즈로 생성?다. INSERT와 UPDATE 가 자주 발생하지? UPDATE를 ? 때 레코 드의 크기가 증가되지 않을 경우 PCTFREE를 10으로 지정하고, PCTUSED를 60 으로 지정?다. [표 6-3]트?잭? 유형의 상대 빈도에 따른 테이블 크기 계산 Note: 위의 표에서 설명? 테이블의 사이즈 계산은 ?대적? 기?이 아니다. 시스템이 비정상 동작하여 데이터가 갑자기 증가하는 등의 장애 상황에 대? 고려가 필요하다. 적정한 백업 사이즈를 고려한다. 실제 업무에서 하나의 테이블스페이스에 하나의 테이블? 저장되는 경우는 드물다. 업무단위 또는 백업단위로 테이블을 묶어서 하나의 테이블스페이스에 생성하는 것이 더 효율적이다. 이 경우 테이블스페이스에 대? 백업 소요 시? 등을 고려하여 ? 개 테이블스페이스의 적정사이즈를 설정?야 ?다. 다음 그림은 데이터베이스 내에서 테이블스페이스를 업무단위 및 158 Administrators Manual 백업사이즈를 고려하여 적정사이즈로 분리하여 생성? 것을 보여?다. [그림 6-15] 백업을 고려? 테이블스페이스 테이블스페이스 정보 알티베이스는 테이블스페이스를 관리하기 위?서 테이블스페이스의 상태를 점검하거나 모니터릿 하기 위? 성능 뷰와 메타 테이블을 제공?다. SYSTEM_.SYS_TBS_USERS_ 또? 다음의 성능 뷰를 통? 사용자들이 사용하는 데이터베이스의 크기, 사용량, 상태 등의 정보를 확?? 수 있다. V$TABLESPACES, V$DATAFILES, V$MEM_TABLESPACES DB VERSION TBS_SALES INVOICE COMP PRODUCT DEPT TBS_CUSTS ORDER EMP PROJ 2G 1G 파티?드 객체 159 7. 파티션드 객체 160 Administrators Manual 파티셔닝 정의 파티셔닝(partitioning)은 더 쉬? 관리를 위하여 대용량 데이터베이스 객체를 여러 개의 작은 조각으로 분?하는 것을 말?다. 파티셔닝으로 분?된 대용량 데이터베이스 객체를 “파티?드 객체 (partitioned object)”라고 하고, 파티?드 객체가 갖는 분?된 작은 조각을 “파티? (partition)”이라고 ?다. 파티션드 객체와 논파티션드 객체 ?반 사용자(end user)가 파티?드 객체를 이용? 때 논파티?드 객체(non-partitioned object)와 차이를 알아채지 못?다. 즉, 사용자 입장에서는 파티?드 객체와 논파티?드 객체는 데이터베이스 객체로 ?식될 뿐이지, ?당 객체의 파티? 유무는 ?식하지 못하기 때?이다. 따라서 사용자는 객체의 파티? 유무에 관계없이 질의 및 DML(레코드 삽입, 삭제, 갱?) 등의 구?을 동?? 방법으로 사용? 수 있다. 파티?드 객체와 논파티?드 객체의 차이점을 데이터베이스 구조적 측면에서 살펴보면 다음과 같다. 내부 구조 논파티?드 객체는 하나의 테이블스페이스에 종속된 객체로, 하나의 논파티?드 객체는 하나의 테이블스페이스에? 저장된다. 파티?드 객체는 다수의 테이블스페이스에 걸쳐 저장될 수 있다. 이는 [그림 7-1]으로 설명된다. 테이블 스페이스 테이블 스페이스 논파티션드 객체 A 파티션드 객체 A 논파티션드 객체 B 파티션드 객체 C파티션드 객체 B [그림 7-1] 테이블스페이스, 파티?드 객체 및 논파티?드 객체의 관계 파티?드 객체 161 파티?드 객체는 내부적으로 다수의 파티?으로 이루어?다. 각 파티?은 논파티?드 객체와 같은 제약 조건을 가지며, 하나의 파티?은 하나의 테이블스페이스에? 종속된다. 이러? 다수의 테이블스페이스에 ?재하는 파티?을 하나의 객체로 ?식하게 ?드는 것이 파티?드 객체이다. [그림 7-2]는 파티?드 객체의 내부구조를 보여?다. 테이블 스페이스 테이블 스페이스 파티션드 객체파티션드 객체파티션드 객체 파티션 [그림 7-2] 파티?드 객체의 내부구조 파티션드 객체의 장점 이런 구조상의 특징으로 ?? 파티?드 객체는 다음과 같은 장점들을 갖는다. 데이터 로딩 및 ?덱스 재구축(rebuilding)이 빠르다. 부분 삭제(partial delete)가 빠르다. 테이블 스캔(table scan) 및 ?덱스 스캔(index scan)이 빠르다. 디스크 붕괴(disk failure)에 유연하다. 파티션 키 파티? 키(Partition Key)는 테이블을 분?하는 기?이다. 파티? 키는 분?될 테이블의 하나 이상의 칼럼으로 구성된다. 이러? 칼럼들을 파티? 키 칼럼(partition key columns)이라고 ?다. 파티? 키 칼럼은 반드시 대소 비교(<, >, =)가 가능? 데이터 타입이어야 하며, 이러? 칼럼?이 파티? 키 칼럼으로 선정될 수 있다. 예를 들어 레코드 삽입시, 삽입될 레코드가 어떤 파티?에 저장되어야 하는지 명확?야 ?다. 이를 ?족하기 위?서는 파티? 162 Administrators Manual 키 칼럼과 과? 조건?의 명확? 대소비교가 가능?야 ?다. 따라서, BINARY, GEOMETRY, BLOB, 및 CLOB 등과 같은 대소 비교가 불가능? 타입은 파티? 키 칼럼이 될 수 없다. 파티?드 객체 163 파티션드 객체 데이터베이스 객체중 테이블과 ?덱스는 파티?이 될 수 있는 객체이다. 테이블이 분? 되는 경우 ?당 테이블을 “파티?드 테이블 (partitioned table)”이라고 하며, ?덱스가 분? 되는 경우는 “파티?드 ?덱스 (partitioned index)”라고 ?다. 이러? 파티?드 테이블과 파티?드 ?덱스를 “파티?드 객체( partitioned object)”라고 ?다. 파티?드 객체는 반드시 다음과 같은 규칙을 ?족시켜야 ?다. non-partitioned_object ≡ ∑partition……………………rule1 위의 규칙은 논파티?드 객체 (non-partitioned_object)는 이를 분?? 파티?의 합과 동치여야 함을 의미?다. 즉, 논파티?드 객체의 ?부분?을 파티?시킬 수 없다. 파티션드 테이블 “파티?드 테이블 (Partitioned Table)”은 파티셔닝 조건 (범위, 리스트, ?시)에 따라 다수의 파티?으로 분리? 대용량 테이블을 의미?다. 이는 [그림 7-3]로 설명된다. [그림 7-3]은 논파티?드 테이블을 색깔(color)을 기?으로 분?하였으며, 결과적으로 파티? 3개로 구성된 파티?드 테이블이 된다. 파티?드 테이블은 구조적 측면에서 기? 데이터베이스 객체중 유니온 뷰(Union View)와 비슷? 개념을 갖는다. 유니온 뷰는 다수의 테이블들을 하나의 객체로 ?식하기 위?서 논리적으로 유니온 시킨 것뿐이며, 어떠? 물리적 공?을 차지하지는 않는다. 이와 ??가지로 파티?드 테이블에 참여하는 파티?들이 물리적? 공?을 가지는 것뿐이지 파티?드 테이블 자체가 물리적 공?을 갖는 것은 아니다. 유니온 뷰와 규별되는 파티?드 테이블의 몇 가지 특징은 다음과 같다. 갱? 가능성 파티?드 테이블은 갱?이 가능하다. 반면 유니온 뷰는 개별 테이블을 통? 레코드 갱?은 가능하지?, 유니온 뷰를 통? 레코드 갱?은 불가능하다. 164 Administrators Manual ?덱스 구축 범위 파티?드 테이블에는 ?덱스를 구축? 수 있다. 그러나 유니온 뷰는 개별 테이블에는 ?덱스를 구축? 수 있지?, 유니온 뷰에는 ?덱스를 구축? 수 없다. 파티션드 테이블 논파티션드 테이블 파티셔닝 조건 (color) [그림 7-3] 파티?드 테이블과 논파티?드 테이블 결?적으로 파티?드 테이블은 레코드 갱? 및 ?덱스 구축이 가능? 유니온 뷰 (updatable and indexable union view)라고 생각? 수 있다. 파티?드 테이블은 파티?들이 저장되는 매체의 종류에 따라서 다음과 같이 분류된다. 알티베이스는 파티?드 디스크 테이블? 지원?다. 파티?드 메모리 테이블 (Partitioned Memory Table): 모? 파티?들이 메모리 테이블스페이스에 저장된 파티?드 테이블 파티?드 디스크 테이블 (Partitioned Disk Table): 모? 파티?들이 디스크 테이블스페이스에 저장된 파티?드 테이블 파티?드 객체 165 파티션드 인덱스 파티?드 테이블을 위? ?덱스들을 다음과 같이 분류? 수 있다. 분? 여부에 따른 분류 파티?드 ?덱스 vs. 논파티?드 ?덱스 테이블과 ?덱스 관계에 따른 분류 글로벌 ?덱스 vs. 로컬 ?덱스 파티션드 인덱스와 논파티션드 인덱스 ?덱스는 그 분? 여부에 따라 파티?드 ?덱스와 논파티?드 ?덱스로 구분된다. “논파티?드 ?덱스 (non-partitioned index)”는 파티?으로 분?되지 않은 ?덱스를 의미하며, “파티?드 ?덱스 (partitioned index)”는 파티?드 테이블과 ??가지로 파티? 조건에 따라 분?된 대용량 ?덱스를 의미?다. 이는 [그림 7-4]로 설명된다. 논파티션드 인덱스 파티션드 인덱스 파티셔닝 조건 (color) [그림 7-4] 파티?드 ?덱스와 논파티?드 ?덱스 [그림 7-4]는 논파티?드 ?덱스를 색깔(color)을 기?으로 분?하였으며, 결과적으로 파티? 3개로 구성된 파티?드 ?덱스가 된다. 166 Administrators Manual 파티? 조건에 따라 분리된 파티?드 ?덱스는 ?덱스 파티? 키와 ?덱스 키의 관계에 따라 프리픽스드 ?덱스와 논프리픽스드 ?덱스로 구분?다. 프리픽스드 ?덱스 (Prefixed Index) 프리픽스드 ?덱스는 ?덱스 키의 첫번째 칼럼이 ?덱스 파티? 키의 첫번째 칼럼과 동?하다. 논프리픽스드 ?덱스 (Non-prefixed Index) 논프리픽스드 ?덱스는 ?덱스 키의 첫번째 칼럼이 ?덱스 파티? 키의 첫번째 칼럼과 동?하지 않다. create table tbl_sales( sales_id integer, sales_date date ) partition by range( sales_date ) ( partition p1 values less than( to_date('2007-05-01', 'YYYY-MM-DD' ) ), partition p2 values less than( to_date('2007-09-01', 'YYYY-MM-DD' ) ), partition p3 values default ) tablespace sys_tbs_disk_data; sales_idsales_date 21월 410월 112월 63월 84월 55월 38월 711월 96월 테이블(TBL_SALES) 3월1월4월6월5월8월11월10월12월 IDX_PART_1IDX_PART_2IDX_PART_3 프리픽스드 인덱스(IDX_PREFIX) sales_date < 5월sales_date < 9월default create index idx_prefix on tbl_sales( sales_date ) local ( partition idx_part_1 on p1, partition idx_part_2 on p2, partition idx_part_3 on p3 ); sales_date=sale_date 628539417 IDX_PART_1IDX_PART_2IDX_PART_3 논프리픽스드 인덱스(IDX_NON_PREFIX) sales_date < 5월sales_date < 9월default create index idx_non_prefix on tbl_sales( sales_id ) local ( partition idx_part_1 on p1, partition idx_part_2 on p2, partition idx_part_3 on p3 ); sales_id!=sale_date [그림 7-5] 프리픽스드 ?덱스와 논프리픽스드 ?덱스의 예 [그림 7-5]는 프리픽스드 ?덱스와 논프리픽스드 ?덱스의 차이를 sales_id와 sale_date로 이루어? 테이블을 사용?서 설명하고 있다. 위의 그림에서 ?덱스들은 sales_date 칼럼에 의?서 분?된다. 각 ?덱스는 어떠? 키로 구성되느냐에 따라 프리픽스드 ?덱스 또는 논프리픽스드 ?덱스로 분류된다. 파티?드 객체 167 그림에서 프리픽스드 ?덱스는 sales_date를 키로 갖는다. 즉, ?덱스 파티? 키와 ?덱스 키가 같은 칼럼 기반이다. 이러? ?덱스를 “프리픽스드 ?덱스 (prefixed index)”라고 ?다. 반면, 그림에서의 논프리픽스드 ?덱스는 sales_id로 정?되어 있다. 이러? ?덱스는 ?덱스 파티? 키와는 다른 칼럼에 의?서 정?된 ?덱스로 “논프리픽스드 ?덱스 (non-prefixed index)”라고 ?다. 프리픽스드와 논프리픽스드로 구분하는 이유는 유니크 (Unique) 속성과 관?이 있다. 프리픽스드 ?덱스의 키는 ?덱스 파티? 키와 동?하기 때?에, 알티베이스 서버는 유니크 검사시 파티?드 ?덱스에 속? 모? 파티?들을 검색하지 않고도 유니크 검사를 ? 수 있다. 그러나 논프리픽스드 ?덱스의 경우에는 알티베이스 서버는 파티?드 ?덱스에 포함된 모? 파티?들을 검색?야 ?다. [그림 7- 6]이 이의 예를 보여?다. sales_idsales_date 21월 410월 112월 63월 84월 55월 38월 96월 91월 테이블(TBL_SALES) 628539417 IDX_PART_1IDX_PART_2IDX_PART_3 논프리픽스드 인덱스(IDX_NON_PREFIX) sales_date < 5월sales_date < 9월default 9 인덱스 : sales_date 인덱스 : sales_id [그림 7-6] 논프리픽스드 ?덱스를 이용? 유니크 검사의 예 (불가능함) [그림 7-6]의 예제에서 ?덱스 파티? 키는 sales_date칼럼이며 sales_id칼럼은 유니크 제약조건을 갖는다. sales_id칼럼을 ?덱스 키로 갖는 논프리픽스드 ?덱스(IDX_NON_PREFIX)가 구축된다면, 다음의 구?으로 레코드 삽입시 알티베이스가 ?덱스 IDX_NON_PREFIX를 이용?서 유니크 검사를 ? 수 있을지 생각?보자: INSERT INTO TBL_SALES VALUES(9, 1월); 우선 삽입하려는 레코드의 sales_date칼럼의 값이 “1월”이기 때?에, 키는 IDX_PART_1 파티?에 삽입될 것이다. 삽입시 IDX_PART_2 파티? sales_id 칼럼에 9의 키 값이 있음에도 불구하고 IDX_PART_1 파티?에 정상적으로 삽입될 것이다. 따라서 알티베이스 서버는 논프리픽스드 ?덱스를 이용?서 유니크 검사를 ? 경우에는 각 파티?내의 ?덱스를 모두 검색?야? ?다. 168 Administrators Manual 글로벌 인덱스와 로컬 인덱스 ?덱스는 테이블 파티? 키와 ?덱스 파티? 키의 관계에 따라 글로벌 ?덱스와 로컬 ?덱스로 구분된다. “글로벌 ?덱스 (global index)”는 ?덱스 파티? 키가 테이블 파티? 키와 ?치하지 않는 ?덱스를 의미?다 (index_partition_key != table_partition_key). “로컬 ?덱스 (local index)”는 ?덱스 파티? 키가 테이블 파티? 키와 ?치하는 ?덱스를 의미?다 (index_partition_key == table_partition_key). sales_idsales_date 21월 410월 112월 63월 84월 55월 38월 711월 96월 테이블(TBL_SALES) 3월1월4월6월5월8월11월10월12월 IDX_PART_1IDX_PART_2IDX_PART_3 로컬인덱스(IDX_LOCAL) sales_date < 5월sales_date < 9월default create index idx_local on tbl_sales( sales_date ) local ( partition idx_part_1 on p1, partition idx_part_2 on p2, partition idx_part_3 on p3 ); sales_date=sale_date 8월1월12월5월3월10월6월4월11월 IDX_PART_1IDX_PART_2IDX_PART_3 글로벌인덱스(IDX_GLOBAL) sales_id < 4sales_id < 7default create index idx_global on tbl_sales( sales_date ) global partition by range(sales_id) ( partition idx_part_1 values less than (4) partition idx_part_2 values less than (7) partition idx_part_3 values less than (MAXVALUE) ); create table tbl_sales( sales_id integer, sales_date date ) partition by range( sales_date ) ( partition p1 values less than( to_date('2007-05-01', 'YYYY-MM-DD' ) ), partition p2 values less than( to_date('2007-09-01', 'YYYY-MM-DD' ) ), partition p3 values default ) tablespace sys_tbs_disk_data; sales_date!=sale_id 3월1월4월8월5월6월12월10월11월 드 테이블(TBL_SALES) sales_date < 5월sales_date < 9월default [그림 7-7] 로컬 ?덱스와 글로벌 ?덱스의 예 [그림 7-7]은 글로벌 ?덱스와 로컬 ?덱스의 차이를 sales_id 와 sale_date 칼럼으로 이루어? 테이블을 사용?서 설명하고 있다. 그림에서 ?덱스들은 sales_date에 의?서 정?되어 있고, 각 ?덱스를 어떠? ?덱스 파티? 키로 분?하느냐에 따라 로컬 ?덱스 또는 글로벌 ?덱스로 분류된다. 아래 그림에서 로컬 ?덱스는 sales_date칼럼을 기?으로 3개의 파티?으로 분?된다. 이렇게 ?덱스 파티? 키 (sale_date)와 테이블 파티? 키 (sales_date)가 동?? 파티?드 ?덱스를 로컬 ?덱스라고 ?다. 반면, 그림 하단의 글로벌 ?덱스는 sales_id칼럼에 의?서 분?되어 있다. 즉, ?덱스 파티? 키 (sales_id)와 테이블 파티? 키(sales_date)가 동?하지 않다. 이런 유형의 파티?드 ?덱스를 파티?드 객체 169 글로벌 ?덱스라고 ?다. ?덱스를 글로벌 또는 로컬 ?덱스로 구분하는 이유는 테이블 파티? 키와 ?덱스 파티? 키의 동치 여부에 따라 다른 특징을 갖기 때?이다. 테이블 파티? 키와 다른 칼럼을 기?으로 구축된 파티?드 ?덱스는 글로벌 ?덱스의 ? ?덱스 파티? 내의 키들이 서로 다른 테이블 파티?들을 가리키고 있음을 의미?다. 이는 파티?드 테이블에 대? 변경 구? (ALTER TABLE .... MERGE ...) 실행은 글로벌 ?덱스의 재구축 (rebuild)으로 이어질수 있음을 의미?다. 반면 로컬 ?덱스의 경우는 파티?드 테이블에 대? 변경 구?은 변경되는 파티?의 로컬 ?덱스에? 영향을 미치기 때?에, ?체적? 동시성 효율을 떨어뜨리지 않는다. 인덱스의 종류 지금까지 설명? ?덱스의 종류를 정리하면 [그림 7-8]과 같다. (파티션드) 글로벌 프 픽스드 인덱스 (파티션드) 글로벌 논프 픽스드 인덱스 (파티션드) 로컬 프 픽스드 인덱스 (파티션드) 로컬 논프 픽스드 인덱스 논파티션드 글로벌 인덱스 인덱스 파티션 유무 index_part_key == table_part_key index_part_key == index_key index_part_key == index_key YESNo YESNo YESNoYESNo [그림 7-8] ?덱스의 종류 현재 알티베이스는 로컬 ?덱스? 지원?다. 글로벌 ?덱스는 지원되지 않는다. 이것을 테이블과 연관지어 정리하면 다음과 같다. 170 Administrators Manual 논파티?드 ?덱스? 논파티?드 테이블 위에 구축될 수 있으며, 로컬 프리픽스드 ?덱스와 로컬 논프리픽스드 ?덱스?이 파티?드 테이블 위에 구축될 수 있다. 논파티션드 테이블 파티션드 테이블 (파티션드)로컬 프리픽스드 인덱스 (파티션드)로컬 논프리픽스드 인덱스 (파티션드)글로벌 프리픽스드 인덱스 (파티션드)글로벌 논프리픽스드 인덱스 논파티션드 글로벌 인덱스 지원가 지원불가 파티?드 객체 171 파티션 조건 본 ?에서는 파티? 조건과 기본 파티?을 설명?다. 파티션 ?제조건 파티? 조건 (partition condition)은 파티?을 분?하는 기?을 의미?다. 이러? 기?은 다음과 같은 규칙을 ?수?야 ?다. partition_conditioni ∩ partition_conditioni+1 = ∮…………rule2 위의 규칙은 파티?드 테이블을 위? 파티? 조건들?에 교집합이 ?재?서는 ?됨을 의미?다. 교집합이 ?재?다는 것은 레코드가 어느 파티?으로 삽입되어야 하는지 명확하지 않다는 것이다. 따라서, 파티?드 객체 생성시 이러? 규칙을 ?족하지 않으면 파티? 생성은 실패?다. 또? 파티? 조건은 어떠? 경우에도 핫상 동?? 값을 표현?야 ?다. 레코드가 t라는 시점에 A 파티?에 삽입되었다고 가정? 경우, 동? 레코드가 t+1시점에 삽입되는 경우에도 A파티?에 삽입되어야 ?다. 이러? 조건을 ?족시키기 위?서 파티? 조건에 기술되는 파티? 조건 값은 핫상 상수 또는 결정가능? 내장 함수 (deterministic built-in function)여야 ?다. 결정가능? 내장함수? 시점에 상관없이 동?? 값을 리턴하는 시스템 내부에서 제공하는 함수(non-user-defined function)를 의미?다. 기본 파티션 알티베이스에서 파티? 조건은 다음과 같은 규칙을 핫상 ?족?야 ?다. column_domain ≡ ∪partition_condition ……………… rule3 위의 규칙은 파티? 조건에 참여하는 칼럼의 도메? (column domain)이 파티? 조건들의 합집합과 동치관계여야 함을 의미?다. 이는 파티?드 테이블 생성시에 모? 파티? 조건들을 명시적으로 기술?야 함을 의미?다. 그러나 현실적으로 질의?을 기술하는 사용자가 모? 파티? 조건을 기술?다는 것은 불가능하기 때?에 알티베이스에서는 기본 파티? (default partition)이라는 개념을 제공?다. 172 Administrators Manual [그림 7-9]에서는 3개의 파티?을 갖는 파티?드 객체를 예를 들어 기본 파티?을 설명하고 있다. 아래 구?에서 사용자는 P1및 P2파티?에 대? 파티? 조건 (partition_condition1, partition_condition2)을 명시하였으며, P3에 대?서 기본 파티?을 선?하였다. 이러? 경우, 삽입되는 레코드가 partition_condition1과 partition_condition2조건에 걸리지 않는다면 P3파티?에 삽입된다. 즉, 기본 파티?은 파티? 키 칼럼이 갖는 ?체 도메?에서 사용자가 지정? 파티? 조건들을 뺀 나머지 도메? 부분과 같다. [그림 7-9] 기본 파티? 사용 예제 기본 파티?은 파티?드 객체 생성시 반드시 명시?야 ?다. ?약 기본 파티?을 명시하지 않는다면 파티?드 객체 생성은 실패?다. create table(…) partition by range(…) ( partition P1 partion_condition1, partition P2 partion_condition2, partition P3 default ) TABLESPACE SYS_TBS_DISK_DATA; P1 P2 P3(default partition) 파티?드 객체 173 파티셔닝 방법 객체는 다음 세 가지 방법으로 분?될 수 있다: 범위 파티셔닝, 리스트 파티셔닝, ?시 파티셔닝. 범위 파티셔닝은 객체를 파티? 키 값의 범위 (range)를 기?으로 분?하는 방법이다. 범위 파티셔닝은 선형적 (linear) 범위로 파티?을 구성? 때 적합하다. 리스트 파티셔닝은 파티? 키 값의 집합을 기?으로 분?하는 방법으로 이산적 (discrete) 범위의 파티?을 구성하고 싶은 경우에 적합하다. ?시 파티셔닝은 파티? 키 값에 ?당하는 ?시(hash) 값을 기?으로 분?하는 방법이다. 위 방법으로 생성된 각 파티?에 대? 다음과 같은 연산이 가능?다. 범위 파티셔닝으로 생성된 파티? 리스트 파티셔닝으 로 생성된 파티? ?시 파티셔닝으로 생성된 파티? 추가 X X ○ 병합 X X ○ 삭제 ○ ○ X 합병 ○ ○ X 이름 변경 ○ ○ ○ 분? ○ ○ X 레코드 삭제 ○ ○ ○ [표 7-1] 파티? 별 지원 연산 범위 파티셔닝 범위 파티셔닝(range partitioning)은 분?? 때 날짜(DATE) 타입을 ?이 이용하며, 이력 데이터(historical data)를 다루는 분야에서 사용된다. 파티? 정의시 사용? 수 있는 유?? 파티? 조건은 LESS THAN이다. 기본 파티?은 DEFAULT ?을 사용?서 정의? 수 있다. 다음은 범위 파티셔닝의 예제이다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) PARTITION BY RANGE(sales_date) ( 174 Administrators Manual PARTITION part_1 VALUES LESS THAN ( TO_DATE(‘01-FEB- 2006’) ), PARTITION part_2 VALUES LESS THAN ( TO_DATE(‘01-MAR- 2006’) ), PARTITION part_3 VALUES LESS THAN ( TO_DATE(‘01-APR- 2006’) ), PARTITION part_def VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; 위의 예제는 part_table테이블을 생성하면서 범위 파티셔닝 방법을 이용하여 파티? 4개로 분??다. 처음 세 개의 파티?은 각각 FEB, MAR, 및 APR이?의 데이터를 다루며, part_def라는 기본 파티?은 어떤 조건에도 포함되지 않는 데이터를 다룬다. 위의 예를 그래피컬 방식으로 표현하면 [그림 7-10]과 같다. TO_DATE (01-FEB-2006) TO_DATE (01-MAR-2006) TO_DATE (01-APR-2006) part_1part_2part_3part_def ∞-∞ [그림 7-10] 범위 파티?드 테이블의 파티? 영역 다중칼럼 파티셔닝 다중칼럼 파티셔닝(Multicolumn Partitioning)은 다중칼럼으로 구성된 파티? 키를 이용하여 객체를 분?하는 것을 말?다. 다중칼럼 파티셔닝은 다중키를 갖는 ?덱스와 동?? 개념을 갖는다. 다음 그림은 두 개 칼럼(i1, i2)으로 구성된 파티? 키를 1차원 형태로 표현? 것이다. -∞∞ -∞∞ -1 (i1, i2) -∞∞ 0 -∞∞ 1...... [그림 7-11] 다중칼럼 파티셔닝의 파티? 영역 다음은 다중칼럼 파티셔닝을 SQL구?으로 예를 들어 설명하고 있다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) PARTITION BY RANGE(sales_date, sales_id) ( 파티?드 객체 175 PARTITION part_1 VALUES LESS THAN ( TO_DATE(‘01-FEB- 2006’), 200), PARTITION part_2 VALUES LESS THAN ( TO_DATE(‘01-MAR- 2006’), 100), PARTITION part_3 VALUES LESS THAN ( TO_DATE(‘02-MAR- 2006’)), PARTITION part_4 VALUES LESS THAN ( TO_DATE(‘01-APR- 2006’) ), PARTITION part_def VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; 위의 테이블 생성 구?을 그림으로 설명하면 다음과 같다. -∞∞ -∞∞ (i1, i2) -∞∞-∞∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-MAR-2006’) TO_DATE (‘01-APR-2006’) 100200100200100200 ...... part_1part_2part_3part_defpart_4 [그림 7-12] SQL 구? 예제의 파티? 영역 다음 표는 삽입될 레코드의 값에 따라 레코드가 삽입될 파티?과 ?당 파티?에 삽입을 유도? 포함 조건이 무엇?지 보여주고 있다. 삽입될 레코드의 값(sales_date, sales_id) 레코드가 삽입될 파티? TO_DATE(‘15-JAN-2006’), 100 part_1 TO_DATE(‘01-FEB-2006’), 100 part_1 TO_DATE(‘01-FEB-2006’), 200 part_2 TO_DATE(‘15-FEB-2006’), NULL part_2 TO_DATE(‘01-MAR-2006’), 50 part_2 TO_DATE(‘01-MAR-2006’), NULL part_3 TO_DATE(‘15-MAR-2006’), 200 part_4 NULL, 100 part_def NULL, NULL part_def 범위 파티션드 객체에 대한 연산 범위 파티?드 객체에 수행될 수 있는 연산의 종류는 5가지이다. 이 연산들은 파티? 분?, 파티? 삭제, 파티? 합병, 파티? 이름 변경, 파티? 레코드 삭제이다. 파티? 조건 변경은 현재는 지원되지 않는다. 범위 파티?드 객체에 파티?이 추가되는 과정은 파티? 조건이 176 Administrators Manual 분?되는 과정과 동?하기 때?에 SPLIT PARTITION을 이용하도록 ?다. ??가지로 파티? 삭제는 파티? 조건을 삭제하는 것과 동?하므로 DROP PARTITION을 사용하도록 ?다. 파티? 삭제시, 삭제된 파티? 조건은 이웃? 파티?의 조건에 포함된다. 또? 레코드의 삭제 여부에 따라서 DROP PARTITION과 MERGE PARTITION으로 구분된다. 파티? 이름 변경은 RENAME PARTITION을 사용하면 된다. 파티?의 레코드를 삭제하려면 TRUNCATE PARTITION을 이용하도록 ?다. 이는 파티? 내에 저장된 모? 레코드를 삭제?다. 파티? 분? (SPLIT PARTITION) 파티? 분?은 파티?드 객체가 갖는 ? 파티?을 2개의 파티?으로 분?하는 연산이다. 파티? 분?은 분? 방식에 따라 다음의 2가지 경우로 나뉜다. ?플레이스 분?(In-place Split) 기? 파티?의 레코드 ?부를 잘라 새로? 파티?에 이동하는 분? 방식으로, 기? 파티?의 내용이 변경된다. 새로? 파티?의 이름이 기? 파티?의 이름과 같고, 새 파티?이 생성될 테이블스페이스를 지정하지 않으면 ?플레이스 분? 방식이 사용된다. ([그림 7-13] 참조) 아웃플레이스 분?(Out-place Split) 기? 파티?의 내용은 변경되지 않는다. 대? 새로? 2개의 파티?을 생성하여, 기? 파티?의 레코드를 복사하는 분? 방식이다. 새로? 두 파티?의 이름을 기? 파티?의 이름과 다르게 지정했을 때 이 방식이 사용된다. 새 파티? 중 하나의 이름이 기? 파티?의 이름과 같더라도 그 파티?이 생성될 테이블스페이스를 지정? 경우에 사용된다. ([그림 7-14] 참조) 위의 아웃플레이스와 ?플레이스 분? 방식은 성능과 효율성에서 차이가 날 수 있다. ?플레이스 분?시에는 기? 파티?이 새로? 두 파티? 중 하나와 같기 때?에 ? 개의 새로? 파티??이 생성된다. 따라서, ?플레이스 분?은 공?적? 측면에서 이득이다. 아웃플레이스 분?시에는 새로? 두 개의 파티?을 생성하고 각각의 파티?에 레코드 삽입 연산이 이루어?다. ?플레이스 분?에서의 레코드에 대? 연산은 이동 연산으로 이는 삽입과 삭제로 구성된다. MVCC ?경에서 레코드 삭제 연산은 레코드 삽입 연산에 비? 성능이 ?이 떨어?다. 따라서, ?플레이스 분?은 저장 공?이 부족? 때 효율적이며, 아웃플레이스 분?은 저장 공?이 충분? 파티?드 객체 177 MVCC ?경에서 좋은 성능을 나타낸다. TO_DATE (01-FEB-2006) TO_DATE (01-MAR-2006) TO_DATE (01-APR-2006) part_1part_2part_3part_def ∞-∞ TO_DATE (01-FEB-2006) TO_DATE (01-MAR-2006) TO_DATE (01-APR-2006) part_1part_2part_3part_def ∞-∞ part_4 TO_DATE (15-FEB-2006) ALTER TABLE part_table SPLIT PARTITION part_2 AT(TO_DATE(15-FEB-2006)) INTO (PARTITION part_2, PARTITION part_4); shrink condition ecords insert records [그림 7-13] 범위 파티?드 객체에서 ?플레이스 분? 위의 그림에서 보여? 예는 4개의 파티?을 갖는 파티?드 객체의 part_2를 part_2와 part_4로 분?하고 있다. ①새로? 파티? part_4가 생성되며, ②기? part_2에서 part_4로의 레코드 이동(MOVE: 삽입 행된다. ?지링으로 ③part_2의 조건이 지정된 조건으로 축소된다. TO_DATE (01-FEB-2006) TO_DATE (01-MAR-2006) TO_DATE (01-APR-2006) part_1part_2part_3part_def ∞-∞ TO_DATE (01-FEB-2006) TO_DATE (01-MAR-2006) TO_DATE (01-APR-2006) part_1part_2part_3part_def ∞-∞ part_4 TO_DATE (15-FEB-2006) ALTER TABLE part_table SPLIT PARTITION part_2 AT(TO_DATE(15-FEB-2006)) INTO (PARTITION part_2 TABLESPACE tbs_01, PARTITION part_4); insert records insert records [그림 7-14] 범위 파티?드 객체에서 아웃플레이스 분? 위의 그림에서 보여? 예는 4개의 파티?을 갖는 파티?드 객체에서 part_2를 part_2와 part_4로 분?하고 있다. ①새로? 파티? part_2와 part_4가 생성되며, ②part_2(old)에서 part_2(new)와 part_4로의 레코드 삽입이 ?행된다. ?지링으로 ③part_2(old)가 물리적으로 삭제된다. 기본 파티? 분?시에는, INTO? 두 번째 파티?이 자동으로 기본 파티?으로 설정된다. 이는 INTO하위?에 기본 파티?을 지정?수 있는 구?을 지원하지 않기 때?이다. 파티? 삭제(DROP PARTITION) 178 Administrators Manual 파티? 삭제는 파티?드 객체가 갖는 파티?들 중에 지정된 파티?을 삭제하는 연산이다. 파티? 삭제시 삭제될 파티?이 갖는 모? 레코드와 메타 정보들은 물리적으로 삭제된다. 또? 삭제된 파티?의 조건은 이웃? 파티?으로 흡수된다. TO_DATE (01-FEB-2006) TO_DATE (01-MAR-2006) TO_DATE (01-APR-2006) part_1part_2part_3part_def ∞-∞ TO_DATE (01-FEB-2006) TO_DATE (01-APR-2006) part_1part_3part_def ∞-∞ ALTER TABLE part_table DROP PARTITION part_2; delete records expand condition [그림 7-15] 범위 파티?드 객체에서 파티? 삭제 위의 그림은 4개의 파티?을 갖는 파티?드 객체에서 part_2파티?이 삭제되는 과정을 보여주고 있다. ①part_2의 물리적 공?(레코드, 메타정보)이 삭제되고, ②이웃? 파티?(part_2의 조건을 포함?수 있는 조건을 가? 파티?)? part_3으로 파티? 조건이 흡수된다. 파티? 합병(MERGE PARTITION) 파티? 합병은 파티?드 객체가 갖는 파티?들 중 지정된 파티? 두 개를 하나의 파티?으로 합병하는 연산이다. 합병? 파티?들은 반드시 이웃?야 ?다. 파티? 합병은 합병 방식에 따라 ?플레이스 합병과 아웃플레이스 합병으로 나뉜다. ?플레이스 합병(In-place Merge) 기?의 두개 파티?이 하나의 파티?으로 합쳐지면서, 기? 파티?의 레코드가 여기에 삽입되는 방식이다. 새로? 파티?의 이름이 기? 파티? 중 하나의 이름과 같고, 새로? 파티?이 생성될 테이블스페이스를 지정하지 않은 경우에 사용된다. ([그림 7-16] 참조) 아웃플레이스 합병(Out-place Merge) 새로? 파티?이 추가로 생성되어 기? 파티?들의 레코드들이 새로? 파티?으로 복사되는 방식이다. 새로? 파티?의 이름이 기? 파티?의 이름과 다른 경우에 사용된다. 또? 새로? 파티?의 이름이 기? 파티? 중 하나의 이름과 같더라도 새로? 파티?이 생성될 테이블스페이스를 지정? 경우에 사용된다. ([그림 7-17] 참조) 파티?드 객체 179 ?플레이스 합병과 아웃플레이스 합병은 성능과 효율성에서 차이가 날 수 있다. ?플레이스 합병은 새로? 파티?을 생성하지 않고, 레코드 삽입 연산? 하기 때?에 성능면에서 아웃플레이스 합병보다 유리하다. TO_DATE (01-FEB-2006) TO_DATE (01-MAR-2006) TO_DATE (01-APR-2006) part_1part_2part_3part_def ∞-∞ TO_DATE (01-FEB-2006) TO_DATE (01-APR-2006) part_1part_3part_def ∞-∞ insert records expand condition ALTER TABLE part_table MERGE PARTITIONS part_2, part_3 INTO PARTITION part_3; [그림 7-16] 범위 파티?드 객체에서의 ?플레이스 합병 위의 그림은 4개의 파티?을 갖는 파티?드 객체의 part_2와 part_3를 part_3(old)로 합병하는 것을 보여주고 있다. ①기? part_3의 조건이 확장되며, ②기? part_2에서 part_3로의 레코드 삽입이 ?행된다. ?지링으로 ③part_2가 물리적으로 삭제된다. TO_DATE (01-FEB-2006) TO_DATE (01-MAR-2006) TO_DATE (01-APR-2006) part_1part_2part_3part_def ∞-∞ TO_DATE (01-FEB-2006) TO_DATE (01-APR-2006) part_1part_3part_def ∞-∞ insert records insert records ALTER TABLE part_table MERGE PARTITIONS part_2, part_3 INTO PARTITION part_3 TABLESPACE tbs_01; [그림 7-17] 범위 파티?드 객체에서의 아웃플레이스 합병 [그림 7-17]은 4개의 파티?을 갖는 파티?드 객체의 part_2와 part_3를 part_3(new)로 합병하는 것을 설명하고 있다. ①새로? 파티? part_3가 생성되며, ②기? part_2와 part_3(old)에서 part_3(new)로 레코드 삽입이 ?행된다. ?지링으로 ③part_2와 part_3(old)가 물리적으로 삭제된다. 파티? 이름 변경(RENAME PARTITION) 파티? 조건은 변경되지 않으며, 파티? 이름? 변경된다 파티? 레코드 삭제(TRUNCATE PARTITION) 180 Administrators Manual 파티? 레코드 삭제는 파티? 조건이 변경되지 않으며, 파티?에 저장되어 있는 모? 레코드들이 삭제된다. 리스트 파티셔닝 리스트 파티셔닝(list partitioning)은 객체를 파티? 키 칼럼 값의 집합을 기?으로 분?하는 방법이다. 리스트 파티셔닝은 파티? 키 칼럼 값의 범위가 넓지 않을 경우(예: 1월 ~ 12월)에 자주 사용되는 분? 방법이다. 리스트 파티셔닝은 원칙적으로 파티? 칼럼으로 다중키를 지원하지 않는다. 범위 파티셔닝처럼 기본 파티? 생성을 위?서 DEFAULT ?이 지원된다. 다음은 리스트 파티셔닝의 예제이다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) PARTITION BY LIST(sales_city) ( PARTITION part_1 VALUES ( ‘SEOUL’ , ‘INCHEON’ ), PARTITION part_2 VALUES ( ‘PUSAN’ , ‘JUNJU’ ), PARTITION part_3 VALUES ( ‘CHUNGJU’ , ‘DAEJUN’ ), PARTITION part_def VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; 위의 예제에서, 테이블은 리스트 파티셔닝으로 분?되어 4개의 파티?을 갖는 파티?드 테이블 part_table이 생성된다. 처음 세 개의 파티?은 특정 도시별로 데이터를 관리하며, part_def라는 기본 파티?은 각 조건에 포함되지 않는 데이터를 관리?다. 이를 그림으로 표현하면 아래와 같다. “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def [그림 7-18] 리스트 파티?드 테이블의 파티? 영역 파티?드 객체 181 리스트 파티션드 객체에 대한 연산 리스트 파티?드 객체에 수행될 수 있는 연산의 종류는 5가지이다. 이 연산들은 파티? 분?, 파티? 삭제, 파티? 합병, 파티? 이름 변경, 파티? 레코드 삭제이다. SQL 구?은 범위 파티?드 객체를 위? 구?과 동?하다. 파티? 조건 변경은 지원되지 않는다. 파티? 분?(SPLIT PARTITION) 리스트 파티셔닝은 범위 파티셔닝과 동?하게 ?플레이스 분?과 아웃플레이스 분?을 지원?다. 파티?을 분?? 때 지정? 새로? 파티? 중 하나의 이름이 기? 파티?의 이름과 같을 경우, 테이블스페이스 지정 여부에 따라 ?플레이스 분?이나 아웃플레이스 분?이 사용된다. “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def part_4 insert records “SEOUL” “INCHEON”“JUNJU” “CHUNGJU” “DAEJUN” DEFAULT “PUSAN” ALTER TABLE part_table SPLIT PARTITION part_2 VALUES(PUSAN) INTO (PARTITION part_4, PARTITION part_2); delete records [그림 7-19] 리스트 파티?드 객체에서의 ?플레이스 분? 위의 그림에서 보여? 예는 4개의 파티?을 갖는 파티?드 객체에서 part_2를 part_2와 part_4로 분?하는 것을 설명하고 있다. ①새로? 파티? part_4가 생성되며, ②기? part_2에서 part_4로의 레코드 이동(MOVE: 삽입 碩홱 ?지링으로 ③part_2의 조건이 지정된 조건으로 축소({PUSAN, JUNJU} -> {JUNJU})된다. 182 Administrators Manual “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def part_4 insert records “SEOUL” “INCHEON”“JUNJU” “CHUNGJU” “DAEJUN” DEFAULT “PUSAN” ALTER TABLE part_table SPLIT PARTITION part_2 VALUES(PUSAN) INTO (PARTITION part_4, PARTITION part_2 TABLESPACE tbs_01); insert records [그림 7-20] 리스트 파티?드 객체에서의 아웃플레이스 분? 위의 그림 예는 4개의 파티?을 갖는 파티?드 객체에서 part_2를 part_2와 part_4로 분?하는 것을 설명하고 있다. ①새로? 파티? part_2와 part_4가 생성되며, ②part_2(old)에서 part_2(new)와 part_4로의 레코드 삽입이 ?행된다. ?지링으로 ③part_2(old)가 물리적으로 삭제된다. 파티? 삭제(DROP PARTITION) 리스트 파티?드 객체에서의 파티? 삭제는 범위 파티?드 객체와 유사하며, 다? 삭제될 파티?의 파티? 조건이 이웃 파티?이 아? 기본 파티?의 조건으로 흡수된다는 점? 다르다. “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def delete records “SEOUL” “INCHEON” “CHUNGJU” “DAEJUN” DEFAULT ALTER TABLE part_table DROP PARTITION part_2; [그림 7-21] 리스트 파티?드 객체에서 파티? 삭제 위의 그림에서 보여? 예는 4개의 파티?을 갖는 파티?드 객체에서 part_2를 삭제하는 것을 설명하고 있다. ①part_2가 갖는 물리적? 공?(레코드, 메타정보)이 삭제되고, ② part_2의 조건이 기본 파티?드 객체 183 파티? part_def로 흡수된다. 파티? 합병(MERGE PARTITION) 리스트 파티?드 객체에서의 파티? 합병은 범위 파티?드 객체와 동?하게 ?플레이스 합병과 아웃플레이스 합병이 있다. 지정? 새로? 파티?의 이름이 합병? 파티?들 중 하나의 이름과 같을 경우, 테이블스페이스를 지정했는지에 따라 ?플레이스 합병이나 아웃플레이스 합병이 사용된다. “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def insert records “SEOUL” “INCHEON” DEFAULT expand condition ALTER TABLE part_table MERGE PARTITIONS part_2, part_3 INTO PARTITION part_3; “PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” [그림 7-22] 리스트 파티?드 객체에서의 ?플레이스 합병 위의 그림에서 보여? 예는 4개의 파티?을 갖는 파티?드 객체에서 part_2와 part_3를 part_3(old)로 합병하는 것을 설명하고 있다. ①기? part_3의 조건이 확장되며, ②기? part_2에서 part_3로 레코드 삽입이 ?행된다. ?지링으로 ③part_2가 물리적으로 삭제된다. 184 Administrators Manual “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def insert records “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULT insert records ALTER TABLE part_table MERGE PARTITIONS part_2, part_3 INTO PARTITION part_3 TABLESPACE tbs_01; [그림 7-23] 리스트 파티?드 객체에서 아웃플레이스 합병 위의 그림에서 보여? 예는 4개의 파티?을 갖는 파티?드 객체에서 part_2와 part_3를 part_3(new)로 합병하는 것을 설명하고 있다. ①새로? 파티? part_3가 생성되며, ②기? part_2와 part_3(old)에서 part_3(new)로의 레코드 삽입이 ?행된다. ?지링으로 ③part_2와 part_3(old)가 물리적으로 삭제된다. 파티? 이름 변경(RENAME PARTITION) 파티? 조건은 변경되지 않으며, 파티?의 이름이 변경된다. 파티? 레코드 삭제(TRUNCATE PARTITION) 파티? 조건은 변경되지 않으며, 파티?에 저장되어 있는 모? 레코드들이 삭제된다. 해시 파티셔닝 ?시 파티셔닝(Hash Partitioning)은 객체를 파티? 키의 ?시(hash) 값을 기?으로 분?하는 방법이다. 파티? 키는 다중 칼럼으로 구성될 수 있다. ?시 파티셔닝은 관리의 용이성보다는 데이터의 고른 부하 분배를 위? ?이 사용되는 방법이다. ?시 파티셔닝은 ?시의 특성으로 ?? ?반적? 파티? 연산에 제?을 받는다. 범위 파티?과 리스트 파티?과 달리 ?시 파티?에는 파티? 분?, 삭제, 합병(merge) 등의 작업을 수행? 수 없으며, 파티? 추가, 병합(coalesce)과 같은 ?시 ?용 작업은 수행이 가능하다. 파티?드 객체 185 범위 파티셔닝과 리스트 파티셔닝과 달리 ?시 파티셔닝에는 기본 파티?이 지원되지 않는다. 이는 ?시 함수 자체가 파티? 키의 모? 값을 수용? 수 있기 때?이다. 널(null) 파티? 키 값을 갖는 레코드가 삽입되는 위치는 널에 대? ?시 값에 의??다. 널의 ?시값은 고정된 상수지?, 데이터 타입?다 상이? 값을 갖는다. 널 파티? 키 값을 갖는 레코드는 칼럼의 타입에 따라 저장되는 위치가 변경될 수 있다. 다음은 ?시 파티셔닝의 예제이다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) PARTITION BY HASH(sales_id) ( PARTITION part_1, PARTITION part_2, PARTITION part_3, PARTITION part_4 ) TABLESPACE SYS_TBS_DISK_DATA; 위 예제는 ?시 파티셔닝을 이용?서 4개의 파티?을 갖는 테이블 part_table이 생성되는 것을 보여?다. 각 파티?은 ?시 함수 HASH(sales_id, 4) 에 따라 나누어? 데이터를 관리?다. 위의 예를 도식화하면 [그림7-24]와 같다. part_1part_2part_3part_4 HASH( sales_id, 4) [그림 7-24] ?시 파티?드 테이블의 파티? 영역 해시 파티션드 객체에 대한 연산 ?시 파티?드 객체에 수행될 수 있는 연산의 종류는 4가지이다. 이 연산들은 파티? 추가, 파티? 병합, 파티? 이름 변경, 파티? 레코드 삭제이다. 186 Administrators Manual ?시 파티?드 객체에 파티?을 추가하려면 ADD PARTITION을 이용?다. 파티?은 삭제하지? 그 데이터는 유지하려면 COALESCE PARTITION을 이용?다. 이 연산은 ?지링 파티?을 삭제하고, ?당 파티?의 레코드는 기? 레코드들과 함께 파티?드 객체 ?체를 재구성 (reorganization)?다. 파티? 이름을 변경하려면 RENAME PARTITION을 사용?다. 파티? 레코드를 삭제(파티?에 저장된 모? 레코드 삭제)하려면 TRUNCATE PARTITION을 이용?다. 파티? 추가(ADD PARTITION) ?시 파티?드 객체에 파티?을 추가하는 것은 ?시 키의 개수가 늘어남을 의미?다. 파티?의 추가는 기?의 모? 파티?에 영향을 미치게 된다. ?시 키가 변경되면 테이블의 레코드 ?체가 변경된 파티?들로 재구성(reorganization)된다. 아래 그림은 이러? 파티? 추가를 설명하고 있다. part_1part_2part_3part_4 part_1part_2part_3part_4 HASH( sales_id, 4) HASH( sales_id, 5) part_5 add part_5 ation ALTER TABLE part_table ADD PARTITION part_5; [그림 7-25] ?시 파티?드 객체의 파티? 추가 위의 그림 예는 4개의 파티?을 갖는 파티?드 객체에서 part_5를 추가하는 것을 설명하고 있다. ①새로? 파티? part_5가 생성되며, 파티?드 객체 187 ②기? 파티? 4개의 레코드들이 기? 4개의 파티?과 1개의 새로 생성된 파티?으로 재분배된다. 파티? 병합(COALESCE PARTITION) ?시 파티?드 객체의 파티?을 병합(Coalesce)하는 것은 ?시 키의 개수가 ?어드는 것을 의미?다. 파티?의 병합은 기?의 모? 파티?에 영향을 미?다. ?지링 파티?이 삭제되고, ?당 파티?의 레코드가 기?의 레코드들과 함께 파티?드 객체 ?체가 재구성(reorganization)된다. 파티? 병합을 ? 때 삭제될 파티? 이름은 지정? 수 없다. ?지링 파티?부터 1개씩 삭제된다. 예를 들어 4개의 파티?(part_1, part_2, part_3, part_4)을 갖는 파티?드 객체를 병합하면 part_4가 삭제되고 3개의 파티?(part_1, part_2, part_3)을 갖는 파티?드 객체로 ?어?다. 아래 그림은 이러? 파티? 병합 과정을 설명하고 있다. [그림 7-26] ?시 파티?드 객체의 파티? 병합 188 Administrators Manual 위의 그림은 4개의 파티?을 갖는 파티?드 객체에서 파티? 병합하는 것을 설명하고 있다. ①기? 파티? 4개의 레코드들이 part_1, part_2, part_3으로 재분배되고, ②?지링 파티? part_4가 삭제된다. 파티? 이름 변경(RENAME PARTITION) 파티? 조건은 변경되지 않으며, 파티?의 이름이 변경된다. 파티? 레코드 삭제(TRUNCATE PARTITION) 파티? 조건은 변경되지 않으며, 파티?에 저장되어 있는 모? 레코드들이 삭제된다. 트?잭? 관리 189 8. 트랜잭션 관리 사용자 트?잭?의 동시성을 제어하고 데이터의 ?관성을 유지하는 것이 데이터베이스의 가장 기본적? 기능의 하나다. 이장에서는 알티베이스의 트?잭? 관리 기능에 대?서 알아보자. 190 Administrators Manual 트랜잭션 트?잭?(Transaction)이? 하나 이상의 SQL ?장들로 이루어? 작업의 논리적? 단위를 말?다. 트?잭?은 사용자에 의? 첫 SQL 구?의 실행으로 시작되고, 트?잭?이 커밋 또는 롤백 될 때 끝난다. 커밋 또는 롤백은 명시적? COMMIT 또는 ROLLBACK 구?으로 수행? 수도 있고, DDL 구? 실행으로 ?? 암묵적으로 행? 질 수도 있다. 트랜잭션의 정의 트?잭?은 ? 트?잭? 내의 SQL 구?들이 논리적으로 그룹지어 있는 ? 사용자에게 데이터 변경의 ?관성을 보장? ?다. ? 트?잭?에는 작업의 논리적 단위를 위? 필요? 모? 부분이 포함되어야 ?다. 트?잭?이 시작되기 ?에 ?관된 상태였던 참조되는 모? 테이블의 데이터는 트?잭?이 끝나 후에도 ?관된 상태로 유지되어야 ?다. 은행에서 예금을 이체하는 작업이 트?잭?의 대표적? 예가 될 수 있다. A 계좌에서 B 계좌로 $100을 이체?다고 가정하면 다음과 같은 작업들이 이뤄져야 ?다. 1. A 계좌에서 $100의 금액을 감소시킨다. 2. B 계좌에 $100의 금액을 증가시킨다. 3. A에서 B계좌로 이체? 사실을 작업내용에 기록?다. ?관된(Consistent) 상태의 데이터베이스에서 정상적? 트?잭?이 수행되면, 데이터베이스는 여?히 ?관된 상태로 되어야 ?다. ??, 위에서 열거? 트?잭?의 세가지 작업 중 ? 가지라도 정상적으로 수행되지 않으면, 데이터베이스의 무결성이 깨져서 A 계좌의 고객, B 계좌의 고객, 혹은 은행이 손?를 보는 경우가 발생? 것이다. 데이터베이스 무결성을 유지시키기 위? 정상적으로 수행되는 트?잭?은 다음과 같은 ACID 특성을 ?족?야 ?다. 원자성 (Atomicity): 트?잭? 내의 모? 구?(Statement)이 모두 반영되거나, 혹은 모두 반영되지 않아야 ?다. 즉, 트?잭?은 부분적으로 성공될 수 없다. ?관성 (Consistency): 트?잭?의 수행으로 ?? 데이터베이스의 무결성이 깨어져서는 ? 된다. 격리성 (Isolation): 여러 개의 트?잭?들이 동시에 수행될 때, 트?잭? 관리 191 어떤 트?잭?도 다른 트?잭?의 결과에 영향을 받아서는 ?된다. 영속성 (Durability): ?단 트?잭?이 완료(Commit) 되면, 시스템 장애 같은 어떤 상황 하에서도 그 변경 내용을 영구적으로 유지? 수 있어야 ?다. 트랜잭션 종료 트?잭?은 다음의 하나가 발생? 때 종료될 것이다. 트?잭?은 사용자가 SAVEPOINT? 없이 ROLLBACK 구?을 실행하거나, COMMIT 구?을 실행? 때 종료된다. 사용자가 DDL 구?을 실행? 때 트?잭?은 커밋된다. 사용자가 알티베이스 서버로부터의 연결을 ?제하면 트?잭?은 커밋된다. 사용자 세?이 비정상적으로 종료되면 현재 트?잭?은 롤백된다. 문장 ?장(statement)은 트?잭? 내에서 수행되는 SQL ? 하나 하나를 ?컫는 말이다. ?장의 종류에는 다음과 같은 세 종류가 있다. DCL (Data Control Language): 데이터베이스의 상태나 프로퍼티 혹은 물리적 구성을 변경시키는 ?장들이다. DDL (Data Definition Language): 데이터베이스의 논리적 구성 요소? 객체들(테이블, ?덱스, 시퀀스, 등)의 생성, 변경 및 삭제를 수행하는 ?장들이다. DML (Data Manipulation Language): 데이터베이스 내에 저장되는 실제 데이터들의 삽입, 삭제, 변경 및 검색을 수행하는 ?장들이다. ?반적으로 하나의 SQL ?이 하나의 ?장이 되지?, 저장 프로시저나 함수 등이 호출되면 하나 이상의 하위 ?장들이 수행된다. ?장의 수행도 역시 데이터베이스의 무결성을 ?치지 않아야 ?다. ?장 수행 중 에러가 발생하면 ?당 ?장에서 수행? 모? 작업이 이? 상태로 되돌려?다. 이를 위?, 알티베이스 HDB는 각 ?장을 시작하기 ?에 “암묵적 저장점(Implicit Save Point)”을 설정? 두고, 오류 발생시 이 지점까지의 복원을 수행?다. 192 Administrators Manual 트랜잭션의 커밋 트?잭?의 커밋(commit)이? 지금까지 트?잭? ?에서 수행? 모? SQL ?의 결과를 데이터베이스에 영구적으로 반영하면서 ?당 트?잭?을 종료하는 연산이다. 트?잭?의 커밋은 데이터베이스의 상태를 이?의 무결? 상태에서 또 다른 무결? 상태로 ?이시킨다. 트?잭?이 커밋될 때, 알티베이스는 다음과 같은 작업을 수행?다. 트?잭? 커밋 로그를 로그 파?에 기록?다. 트?잭?의 수행으로 발생된 ?제 가능? 자원들의 정보를 가비지 콜렉터(Garbage Collector)에게 넘겨?다. 트?잭?의 상태를 커밋 상태(“committed”)로 변경시킨다. 트?잭? 수행 중에 ?당 받은 자원들(잠금, 임시 메모리 등)을 반??다 트랜잭션의 롤백 트?잭?의 수행 도중에 치명적? 오류가 있어 더 이상 ?행? 수 없는 경우에는 지금까지 수행? 왔던 모? SQL ?들을 다시 되돌려서, 데이터베이스를 트?잭? 수행 이? 상태로 바꿔야 ?다. 이를 트?잭?의 롤백이라고 ?다. 트?잭?의 롤백은 트?잭? 수행 중에 기록? 각 로그들에 대? 보상(compensation) 연산을 수행함으로써 구현된다. 트?잭? 롤백 시 알티베이스는 다음과 같은 작업을 수행?다. 로그 레코드를 기록 순서와 반대로 인어가며 보상 연산을 수행?다. 트?잭? 롤백 로그를 기록?다. 삽입 등의 연산으로 ?당 받았던 자원들을 다시 가비지 콜렉터에게 반??다. 트?잭?의 상태를 롤백 상태(“rolled back”)로 변경?다. 트?잭? 수행 중에 ?당받은 자원들(잠금, 임시 메모리 등)을 반??다. 명시적 저장점 하나의 긴 트?잭?을 여러 개의 부분으로 나누어 관리하여야 하는 경우, 그 부분의 시작 지점에 명시적 저장점(Explicit Save Point)을 트?잭? 관리 193 선?? 수 있다. 명시적 저장점은 이름을 가지므로, ? 트?잭? 내에 여러 개가 선?될 수도 있다. 명시적 저장점 선? 이후 오류가 발생하여 선?? 지점으로 데이터베이스를 다시 복원을 ?야 하는 경우에는, ?당 저장점으로의 롤백을 수행하면 된다. 명시적 저장점으로의 롤백이 수행되면 이후에 잡았던 테이블과 레코드 잠금 등의 자원들이 모두 ?제되며, ?당 저장점 이후에 선?된 다른 저장점들은 모두 ?제된다. 194 Administrators Manual 잠금(Lock) 잠금의 목적은 데이터베이스 내에 ?재하는 특정 객체에 대? 접? 권?을 설정하는 것이다. 알티베이스 HDB는 데이터에 대? 동시 접?을 제어하기 위? 잠금을 사용?다. 데이터가 갱?될 때, 갱?이 완료될 때까지 그 데이터에는 잠금이 걸린다. 이는 시스템에서 데이터의 무결성을 보장하는 데 도움이 된다. 잠금 모드 잠금은 그 사용 대상에 따라 테이블 레벨 잠금과 레코드 레벨 잠금으로 나뉜다. 테이블 레벨 잠금 모드(Table Level Lock Modes) 잠금 모드 설명 기능 S Shared Lock (공유 락) 이 잠금의 소유자는 잠금을 획득? 테이블의 모 ? 레코드를 인을 수 있다. 그 테이블을 인기? 하는 다른 트?잭?들과도 동시에 수행될 수 있 다. X Exclusive Lock (배타적 락) 이 잠금의 소유자는 잠금을 획득? 테이블의 모 ? 레코드를 인고 갱?? 수 있다. 다른 어떤 트?잭?도 그 테이블을 인거나 갱?? 수 없 다. IS Intent Shared Lock (공유 락 의도) 테이블 내의 어떤 레코드에 대? 공유 락 획득 의 의도를 가지고 그 레코드가 속? 테이블에 대? IS 락을 먼저 획득?다. 이 잠금의 소유자 는 레코드에 대? S 잠금을 획득? 후 그 레코 드를 인을 수 있다. IX Intent Exclusive Lock (배타적 락 의도) 테이블 내의 어떤 레코드에 대? 배타적 락 획 득의 의도를 가지고 그 레코드가 속? 테이블에 대? IX 락을 먼저 획득?다. 이 잠금의 소유자 는 레코드에 대? X 잠금을 획득? 후 그 레코 드를 인고 갱?? 수 있다. 서로 다른 레코드를 갱?하는 여러 트?잭?들은 동시에 ?재? 수 있다. SIX Shared with Intent 이 잠금의 소유자는 잠금을 획득? 테이블의 모 트?잭? 관리 195 Exclusive Lock (배타적 락 의도를 가 ? 공유 락) ? 레코드를 인을 수 있으며, 그 테이블에 대? X 락을 획득? 후에는 그 테이블을 갱?? 수도 있다. 다른 트?잭?은 그 테이블을 갱?? 수 없으며 인기는 가능하다. [표 8-1] 잠금 모드 의사 모드 잠금(Intention Mode Lock) - IS, IX, SIX 잠금을 걸 수 있는 객체의 종류는 여러 가지가 있다. 그 객체들의 크기 또? 다양하다. 예를 들어 잠금을 걸 수 있는 객체는 데이터베이스 자체, 스키?, 테이블, 레코드, 칼럼 등이 될 수 있으며 이들의 크기는 다음 순서를 가?다. 데이터베이스 > 스키? > 테이블 > 레코드 > 칼럼 이처럼 잠금을 걸 수 있는 대상이 되는 객체의 크기를 잠금 단위(granularity)라 ?다. 잠금 단위가 큰 객체에 대?서? 잠금을 지원하는 경우 그?큼 동시성 제어가 떨어?다. 왜냐하면 ? 트?잭?이 실제 작업 대상이 되는 객체는 레코드이기 때?에 레코드 이상의 객체에 대?서? 잠금 단위를 지원하는 경우 ? 트?잭?이 테이블 내의 레코드 하나에 대?서? 연산을 수행하더라도 그 테이블의 다른 레코드에 대?서 연산을 하고자 하는 다른 트?잭?은 먼저 시작? 트?잭?이 끝나기를 기다려야 하기 때?이다. 따라서, 지원되는 잠금 단위는 최소 단위가 레코드? 것이 가장 효율적이다. 잠금의 최소 단위에 대? 잠금을 획득하기 위?서는 최소 단위보다 큰 객체에 대?서도 잠금을 획득?야 하며 이를 “잠금 단위 규약 (lock granularity protocol)”이라 ?다. 더 큰 객체에 대? 잠금을 획득? 경우에는 잠금 모드를 다양하게 주어 어떤 트?잭?이 그 테이블에 대? 연산을 수행하고 있다 하더라도 동?? 레코드에 대?서 연산을 하지 않는 다른 트?잭?도 그 테이블에 대? 연산을 수행? 수 있게 하는 것이 바람직하다. 이를 위하여 사용되는 것이 “의사 모드 잠금 (intention mode lock)”이다. 잠금 호?성(Lock Compatibility) 잠금 호?성이? 이미 다른 트?잭?이 ?당 객체에 대? 잠금을 획득하고 있을 때 ? 트?잭?이 그 객체에 대? 특정 모드의 잠금을 요구하게 되는 경우 그 요구가 받아들여질 수 있는지의 196 Administrators Manual 여부를 결정하기 위? 사용되는 잠금 모드 ?의 호?성을 의미?다. Granted Mode Requested Mode NONE IS IX SIX S X IS O O O O O - IX O O O - - - SIX O O - - - - S O O - - O - X - - - - - - [표 8-2] 잠금 모드?의 호?성 레코드 레벨 잠금 모드(Record Level Lock Modes) DML 연산 중 삽입(INSERT), 삭제(DELETE), 갱?(UPDATE) 구?은 개별 레코드에 대? X 잠금을 잡게 되고, 조회(SELECT)구?은 S 잠금을 잡게 된다. Lock Mode 설명 기능 S Shred Lock 레코드에 대? 조회 작업? 수행? 수 있 다. X Exclusive Lock 레코드에 대? 조회, 변경 작업을 수행? 수 있다. [표 8-3] 레코드 레벨의 잠금 모드 ?반적으로 레코드에 대? S 잠금과 X 잠금은 서로 충돌하기 때?에 호?되지 않는다. 하지? 알티베이스 HDB의 경우는 다중 버? 동시성 제어 기법(MVCC)을 사용하기 때?에 서로 충돌하지 않는다. 따라서 갱? 중? 레코드에 대? 조회와 조회중? 레코드에 대? 갱?이 모두 허용된다. 트?잭? 관리 197 다중 버? 동시성 제어 기법 알티베이스 HDB는 동시성 제어를 위? 다중 버? 동시성 제어 (MVCC, Multi-Version Concurrency Control) 기법을 사용?다. MVCC? 하나의 레코드에 대? DML구?이 발생? 경우 그 레코드는 원래 상태 그대로 둔 채, 그 레코드의 복사본에 DML 구?을 실행하여 그 레코드의 새로? 버?을 ?드는 것을 말?다. 이 방법으로 ? 레코드에 대? 연산을 수행중? 어떤 트?잭?은 그 레코드를 조회하는 다른 트?잭?에게는 영향을 미치지 않게 된다. MVCC 동시성 제어 기법은 메모리 테이블스페이스와 디스크 테이블스페이스에서의 특징이 서로 다르기 때?에 똑같이 구현될 수는 없다. 알티베이스는 메모리 테이블스페이스에 대?서는 “Out- place MVCC”라는 기법을, 그리고 디스크 테이블스페이스에 대?서는 “In-place MVCC”라는 기법을 사용?다. 이 두 가지 기법은 표면적으로 동?하게 동작을 하기 때?에, 사용자는 이 두 가지를 특별히 구분? 필요가 없다. 본 ?에서는 MVCC 기법을 지원하기 위? 각 DML 구? 수행 시 내부적으로 수행되는 작업에 대? ?략하게 소개?다. 우선 MVCC 기법이 사용되지 않는 경우를 설명하고, 알티베이스 HDB의 메모리 테이블스페이스에서 사용되는 Out-place MVCC를 설명? 후, 디스크 테이블스페이스에서 사용되는 In-place MVCC를 설명?다. ?지링으로 MVCC를 사용? 때 주의?야 ? 사핫들에 대? 설명?다. MVCC 기법을 사용하지 않는 경우의 갱? MVCC 기법을 사용하는 경우와의 비교를 위? MVCC 기법을 사용하지 않는 경우에 갱? 구?이 내부적으로 수행되는 방법에 대? 설명?다. 다음 그림은 MVCC 기법이 사용되지 않을 때 갱? 연산으로 ?? ? 테이블의 레코드가 어떻게 변하는지를 나타낸다. 198 Administrators Manual record A col1 = 1 Table T1 col1=1 -> col1=2 record A Table T1 (a) recordA의 col1칼럼에 1 입력 (b) recordA의 col1의 값을 2로 갱신 [그림 8-1] MVCC 미 사용시의 트?잭? 처리 위 그림의 (a)는 테이블 T1에 레코드 A가 최초로 삽입된 경우를 나타낸다. 이 레코드 A에 대? col1의 값을 2로 수정? 경우 위 그림의 (b)에서와 같이 레코드 A의 원래 위치에서 수정이 됨으로써 T1에 ?당된 공?은 변화가 없다. 삭제 구?의 경우도 갱? 구?과 ??가지로 원래 레코드에 대? 삭제 연산이 수행된다. 위 그림과 같이 MVCC 기법을 사용하지 않는 경우에는 갱? 또는 삭제에 의? 테이블에 ?당된 공?이 늘어나지 않으며 ? 테이블에 ?당된 공?이 늘어날 수 있는 경우는 오직 삽입 구?에 의? 경우뿐이다. 메모리 테이블스페이스의 MVCC 알티베이스의 메모리 테이블스페이스에서 사용되는 Out-place MVCC 기법은 갱? 연산이 발생 ? 때?다 새로? 버?(version)의 레코드를 생성하고 이? 버?의 레코드과 연결 시킴으로써 구현된다. 갱?(Update) 연산 다음 그림은 Out-place MVCC 기법을 사용하는 경우 갱? 구?의 수행 효과를 보여?다. 트?잭? 관리 199 record A nextoid col1 = 1 record A nextoid col1 = 2 record A nextoid col1 = 3 Table T1 (a) recordA의 col1의 초기 insert 상태 (b) recordA의 col1의 값을 2로 update (c) recordA의 col1의 값을 3으로 update [그림 8-2] MVCC 사용시의 트?잭? 처리 그림의 (a)에서와 같이 테이블 T1에 레코드 A가 삽입된 상태에서 레코드 A의 col1의 값을 2로 갱?하는 경우 (b)에서와 같이 갱?을 위? 동?? 레코드를 하나 생성? 후 그 레코드에 대? 값을 2로 변경?다. 따라서, 테이블 T1의 공?은 갱? ?의 상태와 비교하여 하나의 슬롯(slot)을 더 차지하게 된다. 레코드 A의 새로? 버?이 추가로 생성되면 레코드 A의 원래 버?의 헤더내의 포?터를 이용하여 새로 추가된 레코드를 가리키게 ?다. 이렇게 함으로써 동?? 레코드의 다른 버?들이 동시에 관리될 수 있다. 위 그림의 (b) 상태에서 다시 레코드 A에 대? 갱? 연산이 수행되면 위에서 설명? 바와 같이 추가로 하나의 레코드를 생성하여 그 레코드에 대? 갱?을 수행하게 된다. 그 결과 하나의 동?? 레코드에 대? 여러 번의 갱? 연산이 수행되면 갱?된 횟수?큼 동?? 레코드에 대? 버?이 생기게 된다. 그렇다면 갱? 연산 수행 횟수?큼 테이블 공?은 무?정 커지는가? 특정 레코드에 대? 갱? 연산을 수행하는 각 트?잭?이 커밋되면, 가장 최?에 생긴 버?? 유효하며 이? 버?들은 데이터베이스에 저장되어 있을 필요가 없다. 이러? 불필요? 버?들은 가비지 콜렉터에 의? 알티베이스 HDB ?용 중에 삭제가 되며 삭제된 레코드들이 차지하고 있던 테이블 내의 공?들은 이후 발생하는 삽입/갱? ?에 의? 다시 재사용된다. 따라서, 갱? 연산이 ?어난 횟수?큼 레코드의 새로? 버?들이 생긴다 하더라도, 데이터베이스 공?이 무?정 커지지는 않는다. 200 Administrators Manual 삭제 (Delete) 연산 삭제 연산도 갱? 연산과 ??가지로 각 레코드에 대? 삭제 연산이 수행되면 하나의 새로? 버?이 생긴다. 삭제 연산의 경우 갱? 연산과 달리 삭제? 레코드에 대? 새로? 버?은 실제 아무런 데이터도 갖고 있지 않다. 따라서, 삭제 연산에 대? 새로? 버?은 삭제되는 레코드 별로 하나씩 생성? 필요가 없다. 삭제된 레코드들을 표시하는 ? 개의 버?? 생성하는 것으로 충분하다. 다음 그림은 삭제 연산 수행 시 각 레코드 별로 버?을 생성하는 경우와 그렇지 않은 경우에 대? 테이블 내의 공? ?용도를 보여?다. (a) 삭제되는 든 레코드 별로 새로운 전을 생 하는 경우 (b) 삭제 연산을 위해 한 테이블 내에서 커서 별로 하나의 새 전을 생 하는 경우 Table T1 nextoid DeleteRow nextoid Record A nextoid Record B Table T1 nextoid Record A nextoid DeleteRow Record Bnextoid nextoid DeleteRow-1 [그림 8-3] MVCC 사용시의 삭제 트?잭? 트?잭? 관리 201 위 그림의 (a)는 각 레코드 별로 새로? 버?을 생성하는 경우이다. ? 트?잭?이 하나의 삭제 구?을 이용하여 레코드 A, B를 삭제하는 경우 두 레코드에 대? 각각의 버?을 생성하므로 테이블 T1은 추가로 두 개의 레코드가 생성되었다. 위 그림의 (b)는 하나의 삭제 구?에 의? 여러 개의 레코드가 삭제되더라도 하나의 삭제 구?에 대?서는 하나의 새 버??을 생성하는 경우이다. 위 그림에서 보여지는 것처럼 (b)의 경우가 불필요? 레코드 버?을 적게 ?들기 때?에 공? ?용도가 훨씬 높다. 알티베이스 HDB는 위 그림의 (b)와 같은 방법으로 삭제 연산을 수행?다. 디스크 테이블스페이스의 MVCC 알티베이스의 디스크 테이블스페이스에서 사용되는 In-place MVCC 기법은 갱? 연산이 발생 ? 때, 기?의 레코드에서 변경되는 칼럼들의 값을 ?두 테이블스페이스에 ?재하는 ?두 페이지에 ?두 로그 레코드라는 이름으로 기록하고, 변경 이후 값들을 기? 레코드의 ?당 위치에 쓴다. 삽입 연산 최초로 레코드가 삽입되면 알티베이스는 데이터 테이블스페이스에 레코드를 위? 영역을 ?당 받아 레코드를 ??다. 알티베이스는 또? ?두 테이블스페이스에 ?두 로그 레코드를 위? 영역을 ?당받아서 로그 레코드를 작성?다. ?지링으로 알티베이스는 데이터 테이블스페이스의 실제 레코드에 있는 롤백 RID에 이 ?두 로그 레코드의 위치를 기록하여 연결 시킨다. 갱? 연산 최초로 삽입된 레코드? 버?1이 있다고 가정하자. 이 버?이 갱?되어 버?2가 되고, 다시 ?번 갱?되어 현재 버?3이 되었을 경우의 상황은 다음 그림과 같이 된다. 202 Administrators Manual 전 3롤백 RID 이 테이블 스페이스언두 테이블 스페이스 이전 이미지2롤백 RID 이전 이미지1롤백 RID 전 2 전 1 전 3이전 이미지2= = + 전 2+이전 이미지1 [그림 8-4] 디스크 테이블스페이스의 MVCC 위의 그림과 같이 데이터 테이블스페이스에는 핫상 최?의 레코드 이미지가 ?재?다. ?? 어떤 ?장(statement)이 버?3이 커밋되기 ?에 시작되었다면 그 ?장은 버?3을 인을 수 없으므로, 더 이?의 이미지? 버?2를 인어 가야 ?다. 이럴 경우에는, ?당 ?장은 버?3의 이미지를 자?의 특정 버퍼에 복사? 후, 그 레코드의 롤백 RID가 가리키는 곳에 ?재하는 이? 이미지2를 인어다 버?3를 복사? 둔 곳에 반영하게 된다. ?? 이 버?2?저도 자?이 인을 수 없는 버?이라면, 다시 그 과정을 반복하여 이? 이미지1을 반영시켜 버?1을 ?들어 내게 된다. ?? 버? 1도 인지 못하는 경우라면 이는 ?당 ?장이 레코드의 최초 삽입연산이 커밋되기 ?에 시작된 것이므로 이 레코드를 없는 것으로 가정하고 무시하게 된다. ?두 로그 레코드 영역의 ?제 디스크 테이블스페이스의 경우, 단시?에 다량의 갱?연산이 발생하면 데이터 테이블스페이스의 크기는 별 차이가 없지?, In- place MVCC의 영향으로 ?두 로그 레코드의 양이 ?아져서 ?두 테이블스페이스의 크기가 증가하게 된다. ?두 테이블스페이스의 크기는 최초 CREATE DATABASE 시에 설정되어 변경될 수 없으므로 ?두 로그 레코드의 재사용이 필요하다. ?두 로그 레코드는 트?잭?이 커밋될 때 ?두 테이블스페이스 헤더에 등록되어 연결 리스트(linked list)로 관리되다가, 현재 시스템 내의 모? 트?잭?이 ?당 ?두 로그 레코드를 참조? 필요가 없어지게 되면 바로 ?제 된다. 반면 트?잭?이 롤백이 되면 ?두 로그 레코드들은 ?두 테이블스페이스에 등록되지 않고 바로 ?제 된다. 트?잭? 관리 203 삽입 연산에 의? 생성된 ?두 로그 레코드들은 갱? 및 삭제 연산에 의? 생성된 로그 레코드들과 따로 관리된다. 이는 삽입 연산에 의? 생성된 ?두 로그 레코드들이 트?잭? 커밋 시점에 바로 ?제될 수 있게 하기 위?서이다. 삭제 연산 삭제 연산도 갱? 연산과 동?? 방식으로 수행된다. 단, 삭제 연산에 의? 변경되는 정보는 레코드의 헤더에 삭제 플래그(delete flag)가 설정되는 것이므로, ?두 로그 레코드의 이? 이미지에는 레코드의 헤더 정보? 기록된다. 삭제된 레코드가 점유하던 공?은 바로 재사용되지 않는다. 먼저 ?당 레코드에 대? 모? ?덱스의 키들이 삭제되고 실제 레코드가 삭제된 후에, 가비지 콜렉터가 ?당 레코드에 대? 삭제 ?두 로그 레코드를 삭제?다. 그 뒤에 삭제된 레코드가 점유하던 공?은 재사용 가능하게 된다. In-place MVCC vs. Out-place MVCC 디스크 테이블스페이스에서의 In-place방식은 메모리 테이블스페이스의 Out-place와는 다른 레코드 버? 검사 방법을 사용?다. Out-place방식은 레코드의 새 버?을 생성했던 트?잭?의 Commit SCN을 그 버?에 저장하고, 이를 이용하여 레코드 버?을 검사?다. 즉, 조회 트?잭?은 자?의 SCN보다 작은 Commit SCN을 갖는 버?을 인어 ?다. 트?잭?의 Commit SCN은 트?잭? 커밋시에 설정되며, ?당 트?잭?이 생성? 모? 버?에 기록된다. 그러나 디스크 테이블스페이스에서 트?잭?의 Commit SCN을 설정하는 것은 그 트?잭?이 생성? 모? 레코드 버?에 대? 접?을 필요로 하는데 이는 실질적으로 불가능하다. 왜냐하면, 디스크 입출력 비용으로 ?하여 트?잭? 성능이 심각하게 저하되기 때?이다. 따라서, 디스크 테이블스페이스를 위? 독특? Commit SCN검사 방법이 필요하며, 알티베이스에서는 TSS를 이용하여 이를 ?결?다. TSS(Transaction Status Slot) 는 트?잭?의 현재 상태를 표현하고 있는 ?종의 레코드이다. 각 TSS에는 Commit SCN이 기록된다. 이러? TSS는 ?두 테이블스페이스에 영구적으로 기록되며, 더이상 사용되지 않는 불필요? 경우, Ager에 의? 삭제된다. 삭제된 TSS는 새로? 트?잭?에 의?서 재사용된다. 204 Administrators Manual 커밋중? 트?잭?은 자?이 생성? 모? 버?에 Commit SCN을 설정하지 않으며 자?과 관?된 TSS에? Commit SCN을 설정?다. 또? 레코드 갱? 연산시 TSS 식별자가 ?당 레코드에 기록되며, 기록된 TSS 식별자는 레코드 버? 검사를 하는 트?잭?에 의?서 이용된다. 즉, 트?잭?은 레코드의 TSS가 갖는 Commit SCN과 자?의 SCN을 비교하여, 자?의 SCN보다 작은 Commit SCN을 갖는 레코드?을 인어?다. MVCC 사용 시 주의사항 알티베이스 HDB는 메모리와 디스크 테이블스페이스 모두를 MVCC 방식으로 동시성 제어 ?다. MVCC는 기?의 ?통적? SVCC(Single Version Concurrency Control)과 달라서 아래와 같이 주의하여야 ? 점들이 몇 가지 있다. 장시간 수행되는 트랜잭션에 의한 데이터베이스 크기 증가 특정 트?잭?이 너무 오랫동? 커밋되지 않고 수행되고 있으면, 이 트?잭?이 이? 이미지들을 인을 가능성이 있기 때?에 가비지 콜렉터가 다른 트?잭?들이 작성? 이? 이미지 정보들(메모리 테이블은 이? 버?, 디스크 테이블은 ?두 로그 레코드 정보)과 ?당 레코드의 ?덱스 키들을 삭제? 수 없게 된다. 이에 따라 메모리 테이블의 크기가 증가되고, 디스크의 ?두 테이블스페이스 크기가 증가하게 된다. 또?, ?당 트?잭?이 롤백? 때를 대비?서 로그 파?도 삭제하지 못하므로, 로그 파?이 ?재하는 파? 시스템이 꽉 찰 가능성이 있다. 동시 수행 트랜잭션 과다로 인한 데이터베이스 크기 증가 알티베이스는 MVCC로 ?? 생성된 이? 이미지 정보들의 ?제를 가비지 콜렉터에게 ?기고 있다. ?? 동시에 수행되는 트?잭?의 수가 ?당 시스템의 CPU개수 보다 현저히 ?을 경우에는 가비지 콜렉터가 이? 이미지 정보들을 삭제? 여유를 가지지 못? 데이터베이스 크기가 계속 늘어날 수 있다. 대량의 갱? 연산으로 인한 데이터베이스의 크기 증가 ?번에 대량의 이? 정보를 생성?야 하는 연산(bulk update)들이 자주 수행되면, 메모리 테이블은 그 크기가 커지며, 디스크 테이블은 ?두 테이블스페이스가 커질 수 있다. 이? 이미지 정보 과다로 인한 성능 저하 위에 열거? 내용들로 ?하여 이? 이미지 정보가 데이터베이스 내에 너무 ?이 남아있으면 실제로 목적하는 레코드를 찾는데 더 ?은 비용이 들어 갈 수 있어서 ?체적으로 성능이 느려질 트?잭? 관리 205 소지가 있다. Repeatable Read Vs. Consistent Read SVCC로 구현된 ?반적? DBMS들은 레코드를 인었을 때 S 잠금이 잡히게 되므로 X 잠금과 충돌하여 인는 동? 레코드가 변하지 않으므로, 데이터베이스의 격리도(Isolation Level)가 보통 Repeatable Read로 동작?다. 반면 알티베이스는 검색 연산이 수행 중에도 동? 레코드에 대? 갱? 연산이 가능하여 Consistent Read가 기본적? 격리도가 된다. 따라서, ? 트?잭?이 커밋되지 않고 같은 테이블을 여러 번 조회하면 매번 서로 다른 결과 집합을 얻을 수도 있다. ?? 이를 방지하려면 격리도를 Repeatable Read로 변경시키고 연산을 수행하거나, SELECT FOR UPDATE 구?을 사용하여 연산을 수행하여야 ?다. 206 Administrators Manual 트랜잭션의 영속성 ?반적으로 트?잭?이? 저장 객체(페이지 또는 레코드, DBMS?다 구현 차이가 있음)에 대? ??의 조회와 갱? 작업의 독립된 작업 단위를 의미?다. 데이터베이스 관리 시스템은 성능향상을 위?서 여러 트?잭?이 동시에 ?터리빙(interleaving)?서 수행되도록 지원하고 있으며, 여러 트?잭?이 어떤 순서로 수행되더라도 그 결과는 차?대로 하나씩 수행? 결과와 동?하도록 동시성 제어(concurrency control)를 ?주고 있다. 따라서 예측하지 못? 모? 시스템 장애 상황에서도 모? 데이터를 정확하게 관리(crash recovery)하기 위? 다음과 같은 트?잭?의 4가지 속성을 보장하도록 설계되어 있다. 원자성 (atomicity) ?관성 (consistency) 격리성 (isolation) 영속성 (durability) 영속성의 개념 트?잭?의 4가지 속성 중 영속성(durability)은 ? 트?잭?이 커밋된 후에 데이터베이스 객체에 대? ?당 변경 사핫이 디스크에 반영(flush)되기 ?에 시스템 장애가 발생하더라도, ?당 커밋된 트?잭?은 보장되어야 ?다는 속성이다. 데이터베이스 관리 시스템은 트?잭?의 영속성을 지키기 위? 트?잭? 로그(log) 즉, 데이터 변경 작업에 대? 정보가 기록된 리두 로그 레코드를 관리?다. 커밋된 트?잭?에 의? 갱?된 내용이 디스크에 반영되기 ?에 시스템 장애가 발생하면, 시스템 재구동시에 로그를 판독하여 변경된 내용을 복구하게 되는 것이다. 트?잭?의 영속성은 트?잭?의 처리 성능과 밀접? 관?이 있는 중요? 요소이다. 디스크 기반 DBMS에 비? 성능이 수십배 더 좋은 메모리 기반 DBMS에서 영속성을 보장하는 것은 디스크 기반 DBMS에 비? 성능에 미치는 영향이 훨씬 크다. 예를 들어, DBMS가 완벽? 트?잭? 영속성을 제공하기 위?서는 모? 데이터베이스 갱?에 대? 로그 기록이 빠짐없이 디스크의 로그파?에 반영되어야 ?다. 메모리 로그 버퍼에 ?재하는 모? 트?잭? 관리 207 로그들을 로그파?에 반영? 때는 디스크 I/O가 발생하게 되며, 이 때 발생하는 디스크 I/O는 트?잭? 처리의 병목(bottleneck)으로 작용하게 되어 트?잭? 처리 성능 저하의 원?으로 작용?다. 즉, 완벽? 트?잭? 영속성과 트?잭? 처리 성능 관계는 ?정성과 성능이라는 상반되는 목표를 가지는 상충(tradeoff) 관계에 있다고 볼 수 있다. 알티베이스는 트?잭?의 영속성을 완벽하게 보장하고 있으며, 여러 시스템 상황에 따라서 고성능의 트?잭? 처리를 제공하기 위? 트?잭? 처리 성능과 트?잭? 영속성의 균형을 조?? 수 있도록 트?잭? 영속성 관리 방법을 지원?다. 트랜잭션 영속성 관리 방법 알티베이스는 트?잭?의 영속성(durability)을 altibase.properties 파?의 COMMIT_WRITE_WAIT_MODE 프로퍼티와 LOG_BUFFER_TYPE 프로퍼티로 관리?다. COMMIT_WRITE_WAIT_MODE는 변경 로그가 디스크 로그 파?에 반영이 완료될 때까지 트?잭?이 대기? 것?지 여부를 설정?다. 이 프로퍼티는 ?체 시스템 또는 각 세?별로 설정될 수 있다. LOG_BUFFER_TYPE는 변경 로그가 로그 파?에 기록될 때 사용될 로그 버퍼의 타입을 설정?다. 이 프로퍼티는 시스템 ?영 중에 변경? 수 없다. 프로퍼티에 대? 보다 자세? 설명은 General Reference를 참조하기 바?다. 208 Administrators Manual 트랜잭션이 로그가 디스크에 기록될 때까지 대기하지 않고 커널 로그 버퍼가 사용되는 경우 (Durability Level 3) In OS Kernel memory In Altibase process logfile sync threads logfiles log buffer sync txtx [그림 8-5] 트?잭?이 로그가 디스크에 기록될 때까지 대기하지 않고 커널 로그 버퍼가 사용되는 경우의 영속성 COMMIT_WRITE_WAIT_MODE와 LOG_BUFFER_TYPE를 모두 0으로 설정?다. 영속성 프로퍼티의 기본값으로 ?영체제 커널 영역의 로그 버퍼를 사용하여 변경 로그를 기록하며 변경 로그가 로그 파?에 반영될 때까지 트?잭?이 대기하지는 않는다. 트랜잭션이 로그가 디스크에 기록될 때까지 대기하지 않고 메모리 로 그 버퍼가 사용되는 경우 (Durability Level 2) In Altibase process log bufferlogfile sync threads logfiles sync txtx [그림 8-6] 트?잭?이 로그가 디스크에 기록될 때까지 대기하지 않고 메모리 로그 버퍼가 사용되는 경우의 영속성 COMMIT_WRITE_WAIT_MODE와 LOG_BUFFER_TYPE를 0과 1로 각각 설정?다. 트?잭?은 변경 로그를 메모리 로그 버퍼에 기록하고 sync 쓰레드가 자체적으로 로그 버퍼에 있는 로그를 로그 파?에 플러시?다. 트?잭? 관리 209 트랜잭션이 로그가 디스크에 기록될 때까지 대기하고 커널 로그 버퍼 가 사용되는 경우 (Durability Level 4) In OS Kernel memory In Altibase process logfile sync threads logfiles log buffer sync txtx [그림 8-7] 트?잭?이 로그가 디스크에 기록될 때까지 대기하고 커널 로그 버퍼가 사용되는 경우의 영속성 COMMIT_WRITE_WAIT_MODE와 LOG_BUFFER_TYPE를 1과 0으로 각각 설정?다. 트?잭?이 변경 로그를 ?영체제 커널의 로그 버퍼에 기록하고 직접 커밋 로그를 로그 파?까지 반영?다. 210 Administrators Manual 트랜잭션이 로그가 디스크에 기록될 때까지 대기하고 메모리 로그 버 퍼가 사용되는 경우 (Durability Level 5) In Altibase process log buffer logfile sync threads logfiles txtxtx txtx sync [그림 8-8] 트?잭?이 로그가 디스크에 기록될 때까지 대기하고 메모리 로그 버퍼가 사용되는 경우의 영속성 COMMIT_WRITE_WAIT_MODE와 LOG_BUFFER_TYPE를 모두 1로 설정?다. 트?잭?이 변경 로그를 메모리의 로그버퍼에 기록하고 앞의 경우와 ??가지로 직접 커밋 로그를 로그 파?까지 반영?다. 버퍼 관리자 211 9. 버퍼 관리자 알티베이스 디스크 테이블스페이스의 데이터 객체가 접? 또는 갱?되기 위?서는 디스크로부터 메모리에 적재되어야 ?다. 이렇게 임시로 사용되는 메모리를 버퍼라고 하며, 알티베이스에서는 이 메모리를 ?괄적으로 버퍼 풀이라고 ?다. 디스크의 모? 데이터를 버퍼 풀에 쌓아두면 어떤 데이터에 대? 접?이라도 디스크 I/O 없이 빠르게 수행된다. 하지? ?정된 메모리로 ?? 디스크 데이터의 ?부? 버퍼 풀에 적재? 수 있다. 버퍼 풀에 적재된 데이터는 다른 데이터에 의? 제거될 수 있는데, 이를 데이터 교체라고 ?다. 이 때 어떤 데이터를 버퍼에 오래 둘 것?가는 시스템 성능에 중요? 영향을 주기 때?에 효율적? 알고리즘이 사용되어야 ?다. 알티베이스에서는 버퍼 풀을 관리하는 주체를 버퍼 관리자 (Buffer Manager)라고 ?다. 버퍼 관리자의 주된 역?은 자주 접?되는 데이터를 보다 버퍼에 오래 두어 효율적으로 버퍼를 관리하는 데 있다. 이 장에서는 버퍼 관리자의 구조와 기능, 버퍼 풀 관리 방법 및 관? 프로퍼티 등에 대? 설명?다. 212 Administrators Manual 버퍼 관리자의 구조 버퍼 관리자 구성요소 버퍼 관리자의 구성요소에는 버퍼 영역, 버퍼 풀, 버퍼 프레임, 및 BCB (Buffer Control Block)가 있다. 버퍼 풀의 버퍼들은 효율적? 관리를 위? LRU 리스트, 프리페어(prepare) 리스트, 플러시(flush) 리스트, 체크포?트(checkpoint) 리스트, ?시(hash) 테이블로 구성된다. 이 ?에서는 버퍼 관리자의 구성요소에 대? 설명?다. 버퍼 영역 (Buffer Area) 버퍼 영역은 ?비된 메모리 공?으로 이는 버퍼 풀에 ?당된다. 버퍼 관리자에 의? 관리되는 버퍼 크기는 버퍼 영역의 크기에 따른다. 버퍼 풀 (Buffer Pool) 버퍼 풀은 버퍼 관리자의 항심 요소로, 버퍼를 교체하는 정책을 구현?다. 요청된 데이터 페이지를 버퍼에 적재하고 적재된 페이지 영역의 메모리 주소를 반??다. 버퍼 풀은 내부적으로 ?시 테이블과 LRU 리스트, 프리페어 리스트, 및 플러시 리스트들로 BCB들을 관리?다. 버퍼 프레임 (Buffer Frame) 버퍼 프레임은 메모리에 하나의 페이지를 적재? 수 있도록 확보된 공?으로, 하나의 버퍼 프레임은 하나의 페이지와 크기가 같다. 버퍼 프레임이 모여서 버퍼 풀을 구성?다. BCB (Buffer Control Block) BCB는 버퍼 프레임에 대? 정보를 가지며, 하나의 BCB는 하나의 버퍼 프레임에 대응된다. 버퍼 관리자는 버퍼에 적재된 모? 페이지에 대? 정보를 BCB로 관리하며, 버퍼 프레임은 단지 페이지가 메모리에 적재되는 공?이다. 각 BCB는 대응하는 버퍼 프레임에 대? 주소를 유지?다. 다음의 그림과 표는 BCB의 구조와 정보를 설명?다. 버퍼 관리자 213 BCBBCBBCBBCB 버퍼 프레임버퍼 프레임버퍼 프레임버퍼 프레임 [그림 9-1] BCB 구조 속성 설명 BCB 상태 (BCB Status) BCB의 현재 상태를 나타낸다. 가능? 값은FREE, CLEAN, DIRTY이다. FREE: 버퍼에 페이지가 적재되지 않은 상태 CLEAN: 버퍼에 페이지가 적재되었지? 갱?되지 않은 상태 DIRTY: 버퍼의 페이지가 갱?되었으나 디스크에는 반영되지 않은 상태 버퍼 프레임 주소 (Buffer Frame Address) 이 BCB에 ?당하는 버퍼 프레임의 주소 테이블스페이스 식별자 (Space ID) 페이지가 속? 테이블스페이스의 식별자 페이지 식별자 (Page ID) 테이블스페이스내의 페이지들이 갖는 고유 번호 페이지 소유자의 록 (Page Owner Lock) 페이지에 접?하기 위?서는 우선 록을 획득?야 ? 다. Read, Write, 또는 Fix 모드로 얻을 수 있다. 페 이지에 대응하는 BCB에 대? 록을 특정 모드로 획 득? 후에, 버퍼에 올라온 페이지에 ?당 모드로 접 ?? 수 있다. 수정 LSN (Modified LSN) 버퍼내의 페이지가 수정된 시점의 LSN(Log Sequence Number)이다. 이 값은 플러셔가 버퍼에 올라온 페이지를 플러시? 때 어느 시점의 로그에 ?당하는 변경까지 플러시? 것?지 나타낸다. Fix 개수 (Fix Count) 페이지에 동시에 접?하고 있는 트?잭?의 개수이 다. 이 값이 1 이상이면 그 페이지는 교체될 수 없 으며, 0이면 교체가 가능하다. 214 Administrators Manual 접? 회수 (Touch Count) 페이지가 버퍼에 적재된 후 트?잭?들이 접?? 회 수이다. 이 값은 버퍼의 hot, cold 여부를 판단하는 데 사용된다. [표 9-1] BCB 정보 ?시 테이블 알티베이스 서버는 페이지에 대? 요청이 들어오면 ?당 페이지가 버퍼에 적재되었는지 확?하기 위? ?시 테이블내에서 그 페이지의 BCB를 찾는다. ?시 테이블에는 버퍼에 적재된 모? 페이지에 대? BCB가 등록되어 있다. LRU (Least Recently Used) List 이는 접??지 오래된 버퍼를 우선 교체 대상으로 선정하기 위? 사용된다. 알티베이스는 LRU 리스트를 hot-cold 영역으로 나누어 관리하고 있어 “hot-cold LRU List”라고도 ?다. 접? 빈도가 높은 버퍼들은 hot 영역에 넣고, 그렇지 않은 버퍼들을 cold 영역에 넣어 교체 대상 검색시 cold 영역? 확?하기 때?에 hot 버퍼들은 교체 대상에서 제외된다. 버퍼에 페이지가 처음 적재될 때, 이는 mid-point(LRU cold first)에 삽입된다. 새로? 데이터 페이지에 버퍼를 ?당? 때, Prepare리스트에 빈 버퍼가 없으면 이 리스트의 ?지링(LRU cold last)부터 검색하여 cold 버퍼가 교체된다. 교체되는 버퍼를 “victim”이라고 ?다. HOT COLD LRU hot firstLRU hot lastmid point 또는 LRU cold firstLRU cold last 그림 9-2 hot-cold LRU list 검색하는 도중에 접? 빈도가 높은 버퍼는 hot 영역? LRU hot first로 옮겨?다. 또? 페이지가 갱?되었지? 디스크에 플러시되지 않은 dirty 버퍼는 Flush 리스트로 옮겨?다. 그리고 버퍼에 페이지가 올라왔지? 갱?되지 않은 clean 버퍼가 hot 영역에 있지 않으면 교체 대상 버퍼로 선정된다. hot 영역의 비중은 HOT_LIST_PCT프로퍼티로 조정이 가능하다. 기본값은 50이며, 이는 LRU 리스트의 ?반을 hot 영역으로 버퍼 관리자 215 사용?다는 의미이다. Flush List LRU 리스트에서 교체 대상을 검색? 때 dirty 버퍼가 나타나면 플러시 리스트로 옮겨?다. 플러시 리스트는 페이지가 갱?되었지? 디스크에는 아직 반영되지 않은 버퍼들이 모여있는 리스트이다. 그러나 모? dirty 버퍼가 플러시 리스트에 있는 것은 아니다. 갱?된 시점에 플러시 리스트로 옮겨지는 것이 아니라 LRU 리스트에서 교체 대상을 검색하는 과정에서 플러시 리스트로 옮겨지기 때?이다. 교체 플러시(replacement flush)가 발생하면 이 리스트의 갱?된 페이지는 디스크에 반영되고, clean 버퍼가 확보된다. Prepare List 플러시 리스트에서 디스크로 반영이 된 버퍼들은 모두 Prepare 리스트로 옮겨?다. 즉 Prepare 리스트는 플러시 작업을 ?? clean 버퍼들로 구성된 리스트이다. 버퍼 관리자는 교체 대상 버퍼를 찾을 때 우선 Prepare 리스트를 검색?다. ?약 Prepare 리스트에서 적합? 버퍼를 찾을 수 없다면 LRU 리스트를 찾아본다. 그러나 버퍼가 Prepare 리스트에 있어도 갱?이 가능하기 때?에 핫상 clean 상태? 것은 아니다. Checkpoint List LRU 리스트, Flush 리스트, Prepare 리스트는 상호 배타적? 리스트이기 때?에 ? 개의 버퍼는 이 중의 두 개 이상의 리스트에 ?재? 수 없다. 그러나 체크포?트 리스트는 세가지 리스트와 달리 독립적으로 관리가 가능하기 때?에 다른 세가지 리스트에 ?재하는 버퍼가 체크포?트 리스트에 속?수 있다. dirty 버퍼 즉 갱?된 버퍼들은 체크포?트 리스트에 ?재하게 되며, 체크포?트 리스트의 모? 버퍼는 dirty 상태이다. 이 리스트의 버퍼들에는 처음에 갱?된 시점에 ?당하는 LSN이 부여되며, 이를 기?으로 정? 관리된다. 체크포?트 리스트가 플러시될 때 체크포?트 리스트의 LSN이 작은 버퍼부터 플러시 된다. [그림 8-3]은 LRU 리스트, Flush 리스트, Prepare 리스트의 모? 버퍼들이 ?시 테이블을 통? 접?이 가능? 것을 나타낸다. 216 Administrators Manual BCB 해시테이블 LRU List Flush List Prepare List Checkpoint List 그림 9-3 버퍼 풀(Buffer Pool) List 다중화 LRU 리스트, Flush 리스트, Prepare 리스트, 체크포?트 리스트는 각각 다중화가 가능하다. 리스트 다중화를 통? 다수의 데이터베이스 클라이?트가 동시에 서비스 요청시 리스트 록(LOCK) 경합이 발생하는 것을 방지?다. 각 종류별 리스트의 개수는 BUFFER_LRU_LIST_CNT, BUFFER_PREPARE_LIST_CNT, BUFFER_FLUSH_LIST_CNT, 및 BUFFER_CHECKPOINT_LIST_CNT프로퍼티에 설정? 수 있고, 설정된 값은 V$BUFFPOOL_STAT성능 뷰의 LRU_LIST_COUNT, PREPARE_LIST_COUNT, FLUSH_LIST_COUNT, 및 CHECKPOINT_LIST_ COUNT 칼럼을 조회?서 확?? 수 있다. 그러나 서버가 ?영중? 경우에는 이들 값의 변경이 불가하다. BCB 상태 ?이 각 BCB의 상태는 핫상 FREE, CREAN, DIRTY 3가지 중의 하나이다. FREE 버퍼에 어떤 페이지도 적재되지 않은 상태이다. 시스템이 처음 구동되면 대부분의 버퍼들이 free 상태가 된다. 또? 테이블스페이스가 삭제(drop)되거나 오프라?(offline)으로 되면 ?당 테이블스페이스에 속? 페이지에 ?당하는 모? 버퍼들은 free상태로 된다. CLEAN 버퍼에 페이지가 적재되어 있지? 아직 갱?되지 않은 상태이다. 즉, 버퍼의 페이지 내용이 디스크의 페이지 내용과 동?? 상태이다. 이 버퍼 관리자 217 버퍼는 ?시 테이블로 접?될 수 있다. LRU 이 버퍼는 리스트, 플러시 리스트, Prepare 리스트 중 하나에 있을 수 있으나, 체크포?트 리스트에는 있을 수 없다. DIRTY 버퍼에 있는 페이지가 갱?은 되었으나, 디스크에는 반영되지 않은 상태이다. DIRTY 버퍼는 체크포?트 리스트에 포함되며, LRU 리스트, 플러시 리스트, Prepare 리스트 중 하나에도 속?다. 더티 버퍼는 플러시 된 후 CLEAN 상태로 변경된다. 플러셔 (Flusher) 플러셔(Flusher)는 교체될 모? 버퍼를 디스크에 반영하는 플러시(flush)를 수행?다. 알티베이스에서는 두 종류의 플러시가 행?지는데, 교체 플러시(Replacement Flush)와 체크포?트 플러시(Checkpoint Flush)가 있다. 교체 플러시(Replacement Flush) 버퍼 교체를 위? 접?된지 오래된 갱?된 버퍼를 플러시 체크포?트 플러시(Checkpoint Flush) 체크포?트 시?을 ?이기 위? 처음 갱?? 시점이 오래된 버퍼를 플러시 교체 플러시는 주기적으로 발생하거나 교체 대상 버퍼를 찾지 못했을 때 강제적으로 수행된다. 체크포?트 플러시 역시 주기적으로 발생? 수 있으나 사용자가 ALTER SYSTEM CHECKPOINT 명령으로 수행? 수 있다. 플러셔는 교체 플러시를 먼저 수행? 후 ?당 작업이 없을 때에? 주기적으로 체크포?트 플러시를 수행?다. 즉 플러셔는 ?정 시?을 대기? 후 교체 플러시를 ? 버퍼가 있으면 디스크에 반영?다. 플러셔는 DEFAULT_FLUSHER_WAIT_SEC이상 MAX_FLUSHER_WAIT_SEC 미?의 시?을 대기?다. 교체 플러시 이후 다시 ?정 시?을 대기하여 교체 플러시? 대상이 없으면 체크포?트 플러시의 작업 여부를 판단하여 플러시를 하거나 다시 대기?다. 체크포?트 플러시가 발생하기 위? 조건은 다음과 같다. ?지링으로 플러셔가 플러시? 후 CHECKPOINT_FLUSH_MAX_WAIT_SEC이 지났을 때 시스템 재구동시 복구?야 하는 페이지들에 대? 로그 수가 218 Administrators Manual ?정 개수를 넘어설 때. 즉 갱?되었으나 디스크에 플러시되지 않은 페이지들이 갖는 LSN 중에서 가장 작은 LSN이 CHECKPOINT_FLUSH_MAX_GAP ?큼 벌어졌을 때 그러나 플러셔가 오? 시?을 대기하도록 설정되었다고 하더라도, 트?잭?이 자주 발생하여 교체? 버퍼가 ?이 발생하면 강제적? 플러셔도 가능하다. 체크포?트 플러시를 위? 플러셔가 ? 번의 주기에서 플러시 ? 수 있는 버퍼 페이지(프레임)의 개수는 CHECKPOINT_FLUSH_COUNT 프로퍼티를 사용?서 명시? 수 있다. 또? BUFFER_FLUSHER_CNT프로퍼티의 값을 조정하여 다수의 플러셔를 둘 수 있다. 그러나 이 프로퍼티는 서버 ?영중에는 변경될 수 없다. 각각의 플러셔는 ALTER SYSTEM START/STOP FLUSHER 구?으로 구동 또는 정지시킬 수 있다. SQL에 대? 자세? 내용은 SQL Reference를 참조하기 바?다. 버퍼 관리자 219 버퍼 관리 접근 모드 페이지에 접?하기 위?서는 우선 록(Lock)이 획득되어야 ?다. 접? 모드는 페이지에 대? 접?을 어떤 권?으로 허가? ? 것?가에 따라 다음과 같이 Read, Write, Fix로 구분된다. 접? 모드 설명 Read(인기) 버퍼에 올라온 페이지를 인기 위? 접? 모드이다. 여러 개의 트?잭?이 동시에 페이지에 접?? 수 있다. Write(쓰기) 버퍼에 올라온 페이지에 쓰기 위? 접? 모드이다. 쓰기 모드로는 ? 시점에 하나의 트?잭?? 같은 페이지 접?이 가능하다. Fix 이 접? 모드로 버퍼에 페이지를 올리면, 이 페이 지는 버퍼 관리자에 의? 교체되지 않는다. Fix 모 드로 트?잭?이 페이지에 접?하여 데이터를 인으 면 그 데이터가 정확? 데이터임이 보장되지 않는 다. 정확? 데이터를 인기 위?서는 페이지에 인기 (Read) 모드로 접??야 ?다. [표 9-2] 버퍼 접? 모드 접? 모드? 허가 관계를 살펴보면 [표 8-3]과 같다. 타 트?잭? 획득 모드 요청? 접? 모드 Read Write Fix Read O X O Write X X O Fix O O O [표 9-3] 접? 모드? 허가 관계 [표 8-3]은 트?잭?이 write 모드를 요청? 경우, 이미 다른 트?잭?이 read나 write를 획득중이라면, 페이지에 대? ?당 접? 모드의 요청은 대기하거나 실패?다는 것을 나타낸다. 또는 read를 요구? 경우에 이미 다른 트?잭?이 그 페이지에 read 접? 모드로 락을 획득하고 있다면 접?이 성공하지?, write 접? 모드로 락을 획득하고 있다면 이 요청은 실패?다. 220 Administrators Manual 대기 모드 대기 모드는 이미 다른 트?잭?이 페이지를 사용하고 있어 요구? 접? 모드를 허가? ? 수 없는 경우, 대기? 것?가 혹은 대기하지 않고 바로 에러를 리턴? 것?가를 결정?다. 대기 모드 설명 대기 (Wait) 다른 트?잭?이 작업을 ?치고 록(Lock)을 ?제? 때까지 ?당 트?잭?이 대기?다. 대기 ? 함 (No-Wait) 다른 트?잭?이 작업을 ?치는 것을 대기하지 않 고 ?당 트?잭?은 바로 에러를 리턴?다. [표 9-4] 대기 모드 페이지 요청 처리 ?차 1. ?시 테이블 검색 버퍼 관리자는 페이지 식별자, 접? 모드, 및 대기 모드가 포함되어 있는 페이지 요청을 받는다. 버퍼 관리자가 요청을 받으면, 먼저 ?시 테이블에 ?당 BCB가 있는지 검사?다. 요청된 페이지가 이미 버퍼에 적재되어 있다면, ?당 페이지를 기술하는 BCB는 ?시 테이블에서 검색될 것이다. ?약 ?시 테이블에서 그 BCB를 찾을 수 없다면 페이지는 버퍼에 올라오지 않은 것이므로, 버퍼 관리자느 디스크로부터 페이지를 인어 버퍼에 적재?야 ?다. 버퍼 관리자 221 Hash Table BCBBCBBCB BCBBCBBCB TBS IDPage ID 1. 페이지 2. 3. 페이지 DB 4. 스 에서 페이지 어 [그림 9-4] ?시 테이블 검색 2. Lock 획득 알티베이스는 핫상 정확? 데이터를 인도록 보장하기 위? 디스크로부터 read가 ?행중? 페이지는 read가 끝날 때까지 접?하지 않는다. 이를 위? 알티베이스는 디스크로부터 read를 수행? 때 write 권?을 획득?다. 임의의 트?잭?이 ? 페이지에 대? read 혹은 write 권?을 획득? 수 있다면, 그 시점에는 디스크로부터 read가 ?행 중이 아님을 의미?다. Lock의 허가는 [표 8-5]와 같이 접? 모드, 디스크로부터 페이지 인기, 및 대기 모드에 따라 달라?다. 접? 모드 디스크로부터 인기 대기 모드 Lock 획득 결과 Fix O 상관없다 인기가 끝날 때까지 대기 후 허가 Fix X 상관없다 허가 Read O 대기 접? 모드가 허가되면 허가, 실패 시 대기 Read O 대기?함 접? 모드가 허가되면 허가, 222 Administrators Manual 실패 시 대기 Read X 대기 접? 모드가 허가되면 허가, 실패 시 대기 Read X 대기?함 접? 모드가 허가되면 허가, 실패 시 바로 에러 리턴 Write O 대기 접? 모드가 허가되면 허가, 실패 시 대기 Write O 대기?함 접? 모드가 허가되면 허가, 실패 시 대기 Write X 대기 접? 모드가 허가되면 허가, 실패 시 대기 Write X 대기?함 접? 모드가 허가되면 허가, 실패 시 바로 에러 리턴 [표 9-5] Lock 획득 허가 [표 8-5]에서 나타나는 것처럼, Fix모드로 접?을 요청? 경우 현재 페이지가 어떤 권?으로 록(Lock)이 잡혀 있더라도 바로 허가 될 것이다. 그러나 디스크로부터 페이지를 인어오는 중이라면 read가 끝날 때까지 그 요청은 대기?다. 또는 Read 또는 Write 권?과 대기를 하지 않는 모드로 접?이 요청되는 경우, ?약 디스크로부터 페이지를 인어오는 중이라면 Read가 끝날 때까지 그 요청은 대기?다. 디스크로부터 페이지 읽기 버퍼 관리자가 페이지를 요청하였을 때, 버퍼에 ?재하지 않는다면 디스크로부터 페이지를 인는 과정을 수행?다. 1. 사용 가능? BCB 획득 알티베이스 서버가 버퍼에 ?재하지 않는 페이지를 버퍼로 적재하기 위?서는 우선 BCB를 확보?야 ?다. 페이지가 적재될 버퍼를 찾기 위? 먼저 Prepare 리스트를 검색?다. Prepare 리스트에서 free 버퍼를 찾으면 페이지 적재를 가장 쉽게 수행? 수 있다. 그러나 이 방법으로 free 버퍼를 확보하지 못하면, 다음 단계로 교체? 버퍼를 찾는다. 시스템 구동 초기에는 ?은 free 버퍼가 ?재하지?, 테이블스페이스가 삭제(drop) 또는 오프라?으로 되지 않는 이상 버퍼 풀에 free 버퍼가 ?재? 가능성은 낮다. 특히 플러시? 후에도 버퍼에는 페이지 내용이 유지되기 때?에 free 버퍼 관리자 223 버퍼가 새로 생기지는 않는다. 2. 버퍼 교체 교체? 버퍼를 검색? 때 먼저 prepare 리스트가 검사된다. prepare 리스트는 플러시 되어 플러시 리스트로부터 옮겨? clean 버퍼를 보유하고 있기 때?이다. prepare 리스트에서 적합? 교체 대상 버퍼를 찾지 못했다면 LRU 리스트가 검색된다. 그러나 LRU 리스트를 검색했는데도 clean 버퍼를 찾지 못했다면, 또 다른 prepare 리스트를 검사?다. 이 과정을 clean 버퍼를 찾을 때까지 prepare 리스트 개수?큼 반복?다. 그러나 모? prepare 리스트를 검색하여도 clean 버퍼를 찾지 못?다면, 플러셔들을 작동시키고, prepare 리스트에 버퍼가 삽입될 때까지 대기?다. 이 대기 시?은 BUFFER_VICTIM_SEARCH_INTERVAL프로퍼티로 설정된다. 그러나 대기시? 동?에도 clean 버퍼를 찾지 못 ? 경우, 다음 prepare 리스트에서 검색을 ?행?다. 이를 victim search warp이라고 ?다. V$BUFFPOOL_STAT성능 뷰에서 VICTIM_SEARCH_WARP 값이 증가하고 있다면 버퍼 교체를 위? ?은 대기를 하고 있다는 의미이다. 이러? ?제가 지속된다면 버퍼의 크기를 늘리거나 플러셔의 개수를 증가시켜 시스템을 재구동시켜야 ? 것이다. LRU list에서 버퍼 교체 대상이 되기 위?서는 다음의 조건을 ?족?야 ?다. 아무도 fix하지 않은 것 (fix count가 0? 버퍼) 버퍼에 적재되었으나 아직 갱?되지 않은 페이지 (clean 버퍼 상태) 버퍼가 Hot하지 않는 것 (touch count가 HOT_TOUCH_CNT 미?? 버퍼) 교체 대상 버퍼를 찾으면 ?시 테이블에서 제거를 ? 후 다음 과정을 ?행?다. 3. 인기 후 페이지 검증 BCB가 확보되면 디스크로부터 페이지를 버퍼에 적재?다. 그러나 디스크에 저장된 페이지는 하드 디스크 이상이나 정? 등의 예상하지 못? 이유로 ?부 페이지의 내용이 유실될 수 있다. 이러? 상황을 ?식하지 못하면 사용자는 잘못된 데이터를 볼 수 있기 때?에, 알티베이스 서버는 이를 ?식? 수 있어야 ?다. 이를 위? 224 Administrators Manual 알티베이스 서버는 디스크로부터 페이지를 버퍼에 적재? 후 바로 ?당 페이지가 무결?지 검사?다. 1. free BCB DB 2. read from disk Free List BCBBCBBCBBCB 3. validate pageRead Success [그림 9-5] 페이지 검증 플러시(Flush) 1. 플러시? 버퍼 선정 버퍼에 적재된 이후 수정된 페이지는 희생자로 선택되거나 체크포?트를 ? 때 디스크에 플러시된다. 버퍼에 적재된 페이지가 플러시되기 위?서는 다음의 조건을 ?족?야 ?다. 적어도 ? 번 수정되어야 함 fix 개수가 0이어야 함 플러시 중에 다른 트?잭?에 의? 인기는 동시에 가능하다. 즉 플러시 수행을 위?서는 read 모드 권?이 획득된다. 2. IO 버퍼에 페이지 복사 플러시 대상 페이지가 정?지면 이 페이지는 디스크에 기록되기 ?에 먼저 I/O 버퍼라는 메모리 공?에 복사된다. 디스크 I/O 작업은 메모리 연산에 비? 긴 시?을 소요하기 때?에 I/O 버퍼라는 메모리 공?에 먼저 복사가 된 후, 디스크에 기록된다. 버퍼 관리자 225 버퍼 페이지가 I/O 버퍼에 복사되면 그 버퍼는 다른 트?잭?에 의? 인혀질 수도 있고, 재갱?될 수도 있다. 그러나 /O 버퍼가 사용되지 않는다면 페이지가 디스크에 기록되는 동? (즉, 디스크 I/O 작업이 ?어나는 동?) 그 페이지는 갱?되거나 인혀질 수 없을 것이다. 3. 로그 플러시 수정된 페이지가 디스크에 반영되기 ?에 수정된 내용에 대? 로그가 먼저 디스크에 반영되어야 ?다. 이를 WAL(Write-Ahead Logging) 프로토콜이라고 ?다. 그리고 디스크로부터 버퍼에 페이지가 적재될 때 이 페이지의 데이터가 깨졌는지 확?하기 위?서 체크 섬이 계산된다. 페이지를 디스크로부터 인을 때?다 이 체크 섬을 계산하여 페이지의 체크 섬과 비교함으로써 페이지가 무결?지 여부를 가리게 된다. 4. I/O 버퍼의 페이지들을 디스크에 기록 I/O 버퍼의 페이지들이 디스크에 기록될 때 이 버퍼의 내용은 더블 라이트 파?(Double-write file)에 모두 ? 번에 기록된 후, 각각의 페이지가 데이터 파?에 기록된다. 이처럼 디스크에 두 번 기록하는 이유는 페이지를 디스크에 기록하는 중에 시스템 장애가 발생하면 디스크에는 부분 쓰기(partial write)된 페이지가 남게 되는데 이는 복구가 불가능하기 때?이다. ?관성이 깨? 페이지에 대?서는 리두 로그(redo log)로도 복구가 불가능하다. 알티베이스에서는 DOUBLE_WRITE_DIRECTORY 프로퍼티를 사용?서 더블 라이트 파?이 저장될 디렉터리가 지정된다. 이 파?은 시스템 구동시 데이터 파?의 정합성을 검증 또는 복구하기 위? 사용되며, 이 파?이 없으면 이 과정은 생략된다. 226 Administrators Manual 1. Flush 대상 정 2. Flush Log 3. Checksum 산 BCB Flush List BCBBCBBCB Log Page DBDW 파일 4 . DW 에 복사 IO Buffer 5. DW 에 write 6 . DB 에 write [그림 9-6] 페이지 플러시 과정 버퍼 관리자 227 버퍼 관? 프로퍼티 버퍼 관리자를 사용하기 위?서는 알티베이스 프로퍼티 파?의 프로퍼티들을 사용 목적에 맞게 설정?야 ?다. 버퍼와 관?된 프로터티는 다음과 같다. 각 프로퍼티에 대? 상세? 설명은 General Reference 를 참조?다. BUFFER_AREA_CHUNK_SIZE BUFFER_AREA_SIZE BUFFER_CHECKPOINT_LIST_CNT BUFFER_FLUSH_LIST_CNT BUFFER_FLUSHER_CNT BUFFER_HASH_BUCKET_DENSITY BUFFER_HASH_CHAIN_LATCH_DENSITY BUFFER_LRU_LIST_CNT BUFFER_PINNING_COUNT BUFFER_PINNING_HISTORY_COUNT BUFFER_PREPARE_LIST_CNT BUFFER_VICTIM_SEARCH_INTERVAL BUFFER_VICTIM_SEARCH_PCT CHECKPOINT_FLUSH_COUNT CHECKPOINT_FLUSH_MAX_GAP CHECKPOINT_FLUSH_MAX_WAIT_SEC DEFAULT_FLUSHER_WAIT_SEC HIGH_FLUSH_PCT HOT_LIST_PCT HOT_TOUCH_CNT LOW_FLUSH_PCT LOW_PREPARE_PCT MAX_FLUSHER_WAIT_SEC TOUCH_TIME_INTERVAL 228 Administrators Manual 버퍼 관리자 통계 정보 버퍼 관리자 통계 정보는 알티베이스가 제공하는 성능 뷰를 통? 확?? 수 있다. 성능 뷰에 대?서는 General Reference를 참조?다. 버퍼 풀과 관?된 정보는 V$BUFFPOOL_STAT을 통? 확?? 수 있고, 플러셔와 관?된 정보는 V$FLUSHINFO와 V$FLUSHER을 통? 확?? 수 있다. 버퍼 매니저의 버퍼 프레임 통계 정보는 V$BUFFPAGEINFO을 통? 확?? 수 있고, ?두 테이블스페이스의 버퍼 풀 관? 통계 정보는 V$UNDO_BUFF_STAT를 통? 확?? 수 있다. 통계 정보는 서버가 시작? 이래로 계속 누적된 값이므로 특정 기? 동?의 값을 알기 위?서는 모? 칼럼에 대? 다음의 방법으로 계산?야 ?다: (현재의 값 - 측정 시작 시점의 값). Hit Ratio 계산 V$BUFFPOOL_STAT성능 뷰의 HIT_RATIO 칼럼을 통? 버퍼 풀의 누적된 히트율을 확?? 수 있다. 히트율은 다음의 수식에 의? 구??다. Hit Ratio = (GET_PAGES + FIX_PAGES - READ_PAGES) / (GET_PAGES + FIX_PAGES) 예제 iSQL> select hit_ratio from V$BUFFPOOL_STAT; 백업 및 복구 229 10. 백업 및 복구 디스크 데이터 파? 손상 또는 유실 등과 같은 예기치 않은 상황으로 ?? 알티베이스에 저장된 데이터가 손실될 경우를 대비하여 알티베이스에서 제공하는 기능? 백업 및 복구에 대하여 설명?다. 230 Administrators Manual 데이터베이스 백업 이 ?에서는 데이터베이스의 아카이브로그 모드 여부에 따라 메모리 및 디스크 테이블스페이스에 대하여 지원되는 백업 방법과 정책에 대하여 설명?다. 알티베이스 백업 정책 알티베이스 HDB에서 지원하는 백업을 분류하면 다음과 같다. 논리적 백업 유틸리티(Utility) 백업 물리적 백업 오프라?(Offline) 백업 온라?(Online) 백업 논리적 백업은 aexport 혹은 iLoader를 이용하여 테이블과 ?덱스를 생성하는 스크립트 파?들과 테이블 레코드들이 저장된 파?들을 생성하는 것을 말?다. 물리적 백업은 데이터베이스를 구성하는 데이터 파?들과 로그앵커 파?을 복사하는 것을 말?다. 물리적 백업은 데이터 파?의 스냅샷(snapshot)을 복사하는 동?의 서비스 중단 여부에 따라 온라? 백업과 오프라? 백업으로 구분된다. 오프라? 백업은 데이터베이스 서버를 정상 종료? 후에 모? 테이블스페이스 파?, 로그앵커 파?과 로그 파?들을 복사하는 것을 말?다. 온라? 백업은 서비스 중단 없이 데이터베이스의 데이터 파?들과 로그앵커 파? 등을 복사하는 것을 말?다. 이 데이터 파?들의 복사 과정에서 커밋(commit)되지 않은 데이터들이 백업될 수도 있다. 따라서 복구 시에 이들 커밋되지 않은 트?잭?들을 철회(undo) 하기 위?서는 로그 파?들이 필요하다. 또?, 아카이브 로그 파?들이 생성되는 아카이브 로그 모드로 ?영 될 때? 온라? 백업이 가능하다. 온라? 백업으로는 데이터베이스 ?체를 백업 하거나, 특정 테이블스페이스 또는 로그앵커를 백업 ? 수 있다. 다음의 구?이 각 경우에 사용된다. 데이터베이스 ?체 백업 iSQL> alter database backup database to '/backup_dir'; 백업 및 복구 231 테이블스페이스 별 백업 iSQL> alter database backup tablespace SYS_TBS_DISK_DATA to '/backup_dir'; iSQL> alter tablespace SYS_TBS_DISK_DATA begin backup; $ cp SYS_TBS_DISK_DATA-DATA-FILES /backup_dir … iSQL> alter tablespace SYS_TBS_DISK_DATA end backup; 시스템 카탈로그 데이터를 포함하는 메모리 테이블스페이스? SYS_TBS_MEM_DIC는 테이블스페이스 백업 또는 ?체 데이터베이스 백업 기능으로 백업이 가능하다. 다음의 표는 알티베이스의 다양? 백업 모드를 설명?다. 백업 종류 백업 방법 백업 객체 복구 방법 온라? 중에 가능? iLoader를 이용? 백업 iLoader의 out 명령 이 용 사용자가 명 시? 테이블 iLoader의 in 명령 이용 O ?체 데이터 베이스의 온 라? 백업 SQL ? 이용 ALTER DATABASE BACKUP DATBASE TO ‘BACKUP_DIR’; 시스템 ?체 테이블스페이 스의 데이터 파?과 로그 앵커파? 1> 유닉스 명령어 cp 이용 2> ALTER DATABASE RECOVER DATABASE; O 특정 테이블 스페이스의 온라? 백업 1> SQL ? 이용 ALTER DATABASE BACKUP TABLESPACE 테이블스페이스이름 TO ‘backup_dir’; 또는 1> ALTER TABLESPACE 테이블스페이스 이름 BEGIN BACKUP; 2> 유닉스 명령어 cp 사용 cp <원본 파?> 3> ALTER TABLESPACE 테이블스페이스 이름 END BACKUP; 테이블스페이 스의 모? 데 이터 파? 1> 유닉스 명령어 cp 이용. 2> ALTER DATABASE RECOVER DATABASE; O 오프라? 백 업 1>데이터베이스 종료 2>유닉스 명령어 cp 이 용 ?체 데이터 베이스 유닉스 명령어 cp 이용 X 백업시? 비 교 iLoader startup control; iSQL(sysdba)> alter database archivelog; 데이터베이스 모드에 따른 온라인 백업 및 매체 복구 모드 백업방법 매체 복구 방법 노아카이브 로그 오프라? 백업 Full 데이터베이스 복 구 아카이브 로그 온라? 백업 (오프라? 백업 가능) 완? 복구 - Full 데이터베이스 234 Administrators Manual 복구 불완? 복구 - Cancel 기반 복구 - Time 기반 복구 상관없음 iLoader Utility를 이용 ? 백업 iloader Utility를 이용 ? 복구 [표 10-3] 데이터베이스 모드에 따른 백업 및 복구 방법 테이블스페이스 상태에 따른 온라인 백업 및 매체 복구 테이블스페이스 상태 온라? 백업 매체 복구 온라?(ONLINE) 가능 가능 오프라?(OFFLINE) 가능 가능 디스카드(DISCARDED) 불가능 불가능 삭제(DROPPED) 불가능 불가능 백업(BACKUP) 불가능 의미 없음 [표 10-4] 테이블스페이스 상태에 따른 온라? 백업과 매체 복구 백업 시 주의사항 온라인 백업과 체크포인트는 동시에 수행될 수 없다. 체크포?트 중에 메모리 상의 데이터베이스 내용이 디스크에 반영되 고 온라? 백업은 백업하는 바로 그 시점까지의 데이터? 백업됨을 보장하기 때?에, 체크포?트와 온라? 백업은 서로 배타적으로 수행 되고, 동시에는 수행될 수 없다. 체크포?트 수행 중에 온라? 백업 요구가 들어오면 체크포?트가 완 료된 후에 온라? 백업이 시작된다. ??가지로 온라? 백업 ?행 중에 체크포?트 요구가 들어와도 온라 ? 백업이 완료된 후 체크포?트가 시작된다. 알티베이스는 하이브리 드 데이터베이스 특성상 데이터베이스 백업 시에 메모리 테이블스페 이스, 디스크 테이블스페이스 순으로 백업을 ?행?다. 메모리 테이블스페이스 백업 중에는 체크 포?트가 수행 될 수 없지 ?, 메모리 테이블스페이스의 백업이 완료되고 디스크 테이블스페이 스 백업 중에는, 메모리 테이블스페이스에 대? 체크 포?트는 수행 되고 디스크 테이블스페이스에 대? 체크 포?트는 수행되지 않는다. 이중화가 걸려 있는 경우 이중화 정보도 그대로 백업된다. 백업 및 복구 235 백업을 받는 알티베이스에 이중화가 걸려 있는 경우 이중화 관? 정 보도 그대로 백업된다. 그러므로 백업된 데이터베이스가 동?하지 않 은 시스템에서 복구되는 경우 그 장비의 네트워크 주소가 다르기 때 ?에 알티베이스 복구 후 이중화 사용에 ?제가 발생? 수 있다. 따라서, 이중화가 걸려 있는 경우 (1) 이중화를 중지 및 이중화 객체 삭제 후 백업을 수행하거나 또는 (2) 이중화를 사용하는 두 시스템에 서 다른 시스템의 백업 데이터로 데이터베이스를 복구? 경우 반드시 모? 시스템의 이중화 기능을 중지하여 복구 중에 다른 시스템으로 이중화가 되는 것을 방지?야 ?다. 236 Administrators Manual 데이터베이스 복구 데이터베이스 시스템에서는 ?제?지 시스템 또는 하드웨어 장애가 발생? 가능성이 있다. 데이터베이스에 영향을 미치는 장애가 발생하면 데이터베이스 복원을 위?서 복구가 수행되어야 ?다. 이런 장애 후의 목표는 모? 커밋된 트?잭?의 결과들을 복구된 데이터베이스에 유지시키고 가능? 빨리 데이터베이스의 정상 ?영이 가능하도록 하는데 있다. 복구 정책 알티베이스는 다음의 복구 유형을 지원?다. 재시작시 자동 복구 (Restart Recovery) 매체 복구 (Media Recovery) 재시작시 자동 복구는 알티베이스 프로세스가 시스템 crash 또는 소프트웨어 오류로 비정상 종료된 경우, 재시작시 구동 단계에서 자동으로 수행되는 복구이다. 매체 복구는 특정 데이터 파?이 유실되거나 손상된 경우에 백업 받은 과거 데이터 파?의 스냅샷(snapshot)을 이용하여 백업 데이터 파?의 복구 시작 LSN부터 현재 LSN까지 재 수행하여 과거의 데이터 파?의 백업본으로부터 현재 시점의 데이터 파?로 복구하는 것이다. 데이터 파?의 매체 복구가 필요?가에 대? 판단은 로그앵커 파?상의 ?당 데이터 파?의 버?과 현재 데이터 파?의 버?이 ?치하는지 여부에 따라 결정된다. 백업 및 복구 237 logfile 20logfile 21 logfile 100logfile 101 user1.dbf 복구LSN (32:345698) USER1.DBF 정보 파일생 LSN(20:012284) checkpoint LSN (102:172168) archive logs directory user1.dbf 현재LSN (102:172168) 매체복구 프로세스 archived loganchor user1.dbf 생 LSN (20:012284) (방법 2) 백업된 user1.dbf을 복사하여 복구한다. (방법 1) 새로운 user1.dbf를 생 하여 복구한다. REDO 로그 재수행 ALTER DATABASE RECOVER DATABASE; 복구 완료 current archivedarchived online logs directory 그림 10-1] 알티베이스 복구 ?차 알티베이스 HDB에서는 매체 복구를 control 구동 단계에서? ? 수 있다. 즉 알티베이스 HDB는 오프라? 매체 복구(offline media recovery)? 지원?다. 예제 다음은 매체 복구의 예제이다. TEST 테이블스페이스의 데이터 파? user1.dbf 파?이 유실되었다. 이 예제는 이틀 ?에 온라?(Online) 백업받은 user1.dbf을 이용하여 유실된 데이터 파?을 현재 시점으로 복원?다. $ cp /bck/user1.dbf $ALTIBASE_HOME/dbs $ isql -silent -u sys -p manager -sysdba [ERR-00000 : Connected to idle instance] iSQL(sysdba)> startup control; Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE : PROCESS TRANSITION TO PHASE : CONTROL Command execute success. iSQL(sysdba)> alter database recover database; Alter success. TEST 테이블스페이스의 데이터 파? user1.dbf가 매체 복구되었다. iSQL(sysdba)> startup service; 매체복구가 완료되었기 때?에 서비스(service) 단계로 ?이?다. 238 Administrators Manual 완? 복구 vs. 불완? 복구 알티베이스 매체 복구 정책은 완? 복구와 불완? 복구를 모두 지원?다. “완? 복구(Complete recovery)”는 온라? 로그와 아카이브 로그의 유실이 없는 경우에 현재 시점까지 데이터 파?을 복원하는 것을 의미?다. “불완? 복구(Incomplete recovery)”는 아카이브 로그 파? 또는 온라? 로그 파?이 유실된 경우에 로그 파?이 유실되기 바로 직?의 시점으로 데이터베이스를 복구하거나, 데이터베이스를 특정 시각으로 복원하기 위하여 특정 과거 시점으로 데이터베이스 ?체를 되돌리는 경우를 말?다. 완? 복구의 예는 다음과 같다. ALTER DATABASE RECOVER DATABASE; 불완? 복구는 다음 2가지 경우로 나눌 수 있다. 과거의 특정 시점으로 데이터베이스 ?체를 되돌리는 경우: 2007년 9월 10?에 생성된 ?체 데이터베이스 백업 파?을 복사? 후 이를 이용하여 복구를 수행?다. ALTER DATABASE RECOVER DATABASE UNTIL TIME ‘2007-09-10:17:55:00’; 특정 온라? 로그 파?이 손상되어 현재 시점까지 데이터베이스를 복원? 수 없는 경우, 다음의 구?을 이용하여 온라? 로그 파?이 손상되기 바로 직? 시점으로 데이터베이스를 복원?다. ALTER DATABASE RECOVER DATABASE UNTIL CANCEL; control 구동 단계에서 불완? 복구를 수행? 경우에 meta 구동 단계로 넘어가기 위?서 반드시 다음 구?을 사용?야 ?다. ALTER DATABASE db_name META RESETLOGS; 위 구?을 수행하는 이유는 데이터베이스가 특정 과거 시점으로 복원되어, 재 시작 시 자동 복구(Restart Recover)가 수행되지 않도록 ? 필요가 있기 때?이다. 이를 위하여 RESETLOGS 옵?으로 온라? 로그를 초기화(resetlogs)하는 것이다. 데이터베이스가 resetlogs를 하면서 meta 구동 단계로 ?이 되었다면, 오프라?이나 온라? 백업으로 데이터베이스 ?체 백업을 반드시 ?야 ?다. 그 이유는 다음과 같다: resetlogs를 하면서 meta 구동 단계로 백업 및 복구 239 ?이하고 나서 이틀 후에 매체에 또 다시 에러가 발생?다면, 로그를 리셋하기 이?까지? 데이터 복구가 가능하기 때?이다. 즉, 로그를 리셋? 이후부터 이틀?의 데이터는 유실될 것이다. 매체 복구시 주의사항 매체 복구 알고리즘 때문에 가능하면 현재 로그 앵커 파일들을 이용 하여 매체 복구를 하여야 한다. 복구 수행시, 백업된 데이터 파?들? 복사하여 복원?야 ?다. 특별 ? 경우가 아니라면 로그앵커 파?들은 백업 본을 사용하여 복구하면 ? 된다. 특별? 경우는 사용자의 실수로 DROP TABLESPACE 구?을 이용하 여 테이블스페이스를 삭제 ? 경우이다. 이 경우 현재 로그앵커 파? 에는 삭제된 테이블스페이스 정보가 없기 때?에 백업된 로그앵커를 사용? 수 밖에 없다. 메모리 테이블스페이스의 데이터 파일 복구 시 stable한 메모리 데이 터 파일을 이용해야 한다. 알티베이스 HDB는 메모리 테이블스페이스에 대하여 핑퐁 체크포?트 (ping-pong checkpoint) 기법을 사용하기 때?에, 디스크 상에서 각 메모리 테이블스페이스에 대하여 2개의 데이터 파?을 유지?다. 동 ?? 이미지를 기록하고 있는 1묶음(pair)의 데이터 파?은 MEM_DB_DIR 프로퍼티에 설정? 위치에 저장된다. 2개의 데이터 파 ?이 모두 ?재?야? 알티베이스 HDB가 정상적으로 ?용된다. 어느 ? 시점에서는 메모리 테이블스페이스는 이 묶음 중 오직 1개의 데이 터 파?? 사용?다. 백업 수행 시?을 ?이려면 메모리 테이블스페이스의 가장 최? 체크 포?터가 수행된 ? 개의 데이터 파?? 백업?다. 따라서 백업된 메모리 테이블스페이스 데이터 파?을 이용하여 복구 ? 경우 나머지 ? 개의 동?? 이미지의 데이터 파?을 생성? 주어 야 ?다. 백업 받은 메모리 테이블스페이스의 데이터 파?이 다음과 같다면: SYS_TBS_MEM_DIC-1-0, SYS_TBS_MEM_DIC-1-1, SYS_TBS_MEM_DIC-1-2 메모리 테이블스페이스를 위? 데이터 파?의 복사는 다음과 같이 되어야 ?다. $ cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs; 240 Administrators Manual $ cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-0; $ cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs; $ cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-1; $ cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs; $ cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-2; 테이블스페이스의 추가, 삭제 또는 이름 변경 등이 이루어지면, 딕셔 너리 테이블스페이스(SYS_TBS_MEM_DIC)의 백업이나 ?체 데이터 베이스의 백업이 필요하다. iSQL(sysdba)> ALTER DATABASE BACKUP TABLESPACE SYS_TBS_MEM_DIC TO ‘/backup_dir’; 로그앵커 파?은 데이터베이스 내 테이블스페이스 정보를 포함하고 있으므로, 이는 테이블스페이스 구조가 변경될 때?다 딕셔너리 테이 블스페이스와 함께 백업되어야 ?다. iSQL(sysdba)> ALTER DATABASE BACKUP LOGANCHOR TO 'anchor_path'; 백업 및 복구 241 백업 및 복구 사례들 iLoader유틸리티를 이용한 테이블 백업 및 복구 임의의 테이블에? ?제가 발생? 것을 대비하거나, 특정 이유로 ?당 테이블? 백업을 받으려고 하는 경우 iLoader 유틸리티를 사용? 수 있다. 백업 ? 백업하기 ?에 반드시 백업하고자 하는 테이블의 스키?에 관? 정보 파?(FORM file)을 생성?야 ?다. FORM 파?은 테이블에 관? 기본 정보(칼럼 이름, 데이터 타입)를 가지고 있다. 예제) 테이블 t1의 form 파? 생성 (t1.fmt라는 파? 이름으로 생성됨) iLoader> formout -T t1 -f t1.fmt 백업 iLoader의 명령 중 out을 사용?다. 사용자가 명시? 이름으로 테이블에 대? 백업 파?이 생성된다. 예제) 테이블 t1의 백업 (이용? form 파?은 t1.fmt 생성? 백업 파?은 t1.dat ) iLoader> out -d t1.dat -f t1.fmt 복원(restore) iLoader의 명령 중 in을 사용?다. 복구 시 테이블에 레코드가 ?재하는 경우 그 레코드들을 유지하거나 덮어쓰게 ? 수 있으며, 사용자가 명시하지 않는 경우 ?재하는 레코드들의 내용은 유지된다. 예제) 테이블 t1의 복원 iLoader> in -d t1.dat -f t1.fmt Offline 백업 및 복구 오프라? 백업 및 복구는 주로 노아카이브 로그 모드로 데이터베이스를 ?영하는 경우에 사용하는 방법이다. 242 Administrators Manual 오프라인 백업 수행시 주의사항 백업 ? 알티베이스와 관?된 모? 서비스를 중지?다. 데이터베이스 ?영 중에 오프라? 백업이 수행되면 백업 중에 로그 파?의 내용이 변경될 수 있어 백업이 정확하게 수행되지 않을 수 있다. 그러므로 반드시 알티베이스 HDB 서버를 중지? 후에 오프라? 백업을 수행하여야 ?다. 백업 방법 모? 테이블스페이스의 데이터 파?들, 로그 파?, 및 로그 앵커 파? 모두를 ?영체제의 복사 명령어 (UNIX의 경우 cp)를 이용하여 백업?다. 알티베이스 HDB에서는 메모리 데이터 파? 뿐? 아니라 디스크 관? 테이블스페이스의 데이터 파?들과 로그 앵커파?이 백업되어야 ?다. 메모리 테이블스페이스 데이터 파? 저장 위치는 알티베이스 프로퍼티 파?? $ALTIBASE_HOME/conf/altibase.properties 파? 내에 MEM_DB_DIR으로 설정된다. 메모리 테이블스페이스의 데이터 파?을 백업하려면 MEM_DB_DIR 디렉터리를 모두 복사?야 ?다. 로그 앵커 파?의 위치는 $ALTIBASE_HOME/conf/altibase.properties 파? 내에 LOGANCHOR_DIR 프로퍼티로 설정된다. 로그 앵커 파?을 백업하려면 LOGANCHOR_DIR 디렉터리의 파?들을 복사?야 ?다. 그리고 데이터 딕셔너리를 참조하여 디스크 테이블스페이스의 데이터 파?들을 복사?야 ?다. 예제) $ALTIBASE_HOME/conf/altibase.properties MEM_DB_DIR=$ALTIBASE_HOME/dbs0 MEM_DB_DIR =$ALTIBASE_HOME/dbs1 LOGANCHOR_DIR =$ALTIBASE_HOME/logs 백업?야 하는 디스크 테이블스페이스에는 시스템 테이블스페이스,?두 테이블스페이스와 임시 테이블스페이스? 있다. 백업 파?이 저장될 위치가 /home/backup라면 $cp -r $ALTIBASE_HOME/dbs0 /home/backup $cp -r $ALTIBASE_HOME/dbs1 /home/backup $cp -r $ALTIBASE_HOME/logs /home/backup $cp -r $ALTIBASE_HOME/dbs/system*.dbf /home/backup $cp -r $ALTIBASE_HOME/dbs/undo.dbf /home/backup $cp -r $ALTIBASE_HOME/dbs/temp.dbf /home/backup 백업 및 복구 243 복구 방법 알티베이스 프로퍼티 설정 파?은 백업 수행 당시에 사용되었던 프로퍼티 파?을 그대로 이용?야 ?다. 공유 메모리에 남아있는 데이터베이스를 삭제하라. 백업 시 받았던 파?들을 복사 명령어 cp를 이용하여 복원하라. 이들 파?에 접?하려면 충분? 권?이 있어야 ?다. 예) 아래의 예제에서는 위에서 백업된 데이터베이스가 복원된다. $cp -r /home/backup/dbs0 ALTIBASE_HOME/dbs0 $cp -r /home/backup/dbs1 $ALTIBASE_HOME/dbs1 $cp -r /home/backup/logs $ALTIBASE_HOME/logs $cp -r /home/backup/system*.dbf $ALTIBASE_HOME/dbs $cp -r /home/backup/undo.dbf $ALTIBASE_HOME/dbs $cp -r /home/backup/temp.dbf $ALTIBASE_HOME/dbs 데이터베이스 시스템에 의한 온라인 백업 데이터베이스 단위 온라인 백업 ?체 데이터베이스가 /backup_dir 디렉터리에 온라? 백업된다. iSQL(sysdba)> alter database backup database to‘/backup_dir’; $ ls /backup_dir SYS_TBS_MEM_DIC-0-0 SYS_TBS_MEM_DATA-0-0 system001.dbf system002.dbf undo001.dbf loganchor0 loganchor2 loganchor1 테이블스페이스 단위 온라인 백업 SYS_TBS_MEM_DIC 데이터 파? 중에서 ?정(stable)된 버?이 /backup_dir 디렉터리에 온라? 백업된다. iSQL(sysdba)> alter database backup tablespace SYS_TBS_MEM_DIC to ‘/backup_dir’; $ ls /backup_dir SYS_TBS_MEM_DIC-0-0 로그앵커 온라인 백업 모? 로그앵커 파?이 /backup_dir 디렉터리에 온라? 백업된다. iSQL(sysdba)> alter database backup loganchor to ‘/backup_dir’; $ ls /backup_dir loganchor0 loganchor1 loganchor2 244 Administrators Manual DBA에 의한 온라인 백업 테이블스페이스 단위 온라인 백업 /backup_dir에 USER_MEMORY_TBS와 USER_DISK_TBS테이블스페이스의 데이터 파?들을 온라? 백업 ?다. 메모리 테이블스페이스 데이터 파?은 ?정(stable) 버? 데이터 파??지 확? 후 온라? 백업?다. iSQL(sysdba)> alter tablespace USER_MEMORY_TBS begin backup; iSQL(sysdba)> select * from v$stable_mem_datafiles; V$STABLE_MEM_DATAFILES.MEM_DATA_FILE ------------------------------ /altibase_home/dbs/USER_MEM_TBS-0-0 $ cp $ALTIBASE_HOME/dbs/USER_MEMORY_TBS-0-0 /backup_dir/ iSQL(sysdba)> alter tablespace USER_MEMORY_TBS end backup; iSQL(sysdba)> alter tablespace USER_DISK_TBS begin backup; $ cp $ALTIBASE_HOME/dbs/USER_DISK_TBS.dbf /backup_dir/ iSQL(sysdba)> alter tablespace USER_DISK_TBS end backup; $ ls /backup_dir USER_MEMORY_TBS-0-0 USER_DISK_TBS.dbf 온라인 백업 마무리 DBA에 의? 직접 온라? 백업을 수행하였다면 ?지링 ?차는 백업과 관?된 로그 파?을 강제로 아카이브(archive) 하는 명령을 수행?야 하는 것이다. 이 명령은 현재 로그 파?을 다 쓰지 않았어도 닫고 다음 로그 파?에 로깅을 계속하도록 명령?다. iSQL(sysdba)> ALTER SYSTEM SWITCH LOGFILE; 온라? 백업 완료 메시지가 altibase_sm.log에 남겨?다. 이 수동 백업의 예제에서는, logfile15341 로그파?이 아카이브 되었다는 메지지가 백업이 완료됨을 표시?다. [2007/09/18 14:42:38] [Thread-6] [Level-9] Waiting logfile15341 to archive [2007/09/18 14:42:43] [Thread-6] [Level-9] Database-Level Backup Completed [SUCCESS] 매체복구 사례 1 백업 및 복구 245 아카이브 로그 모드로 데이터베이스를 ?영하고 있으며, 백업되지 않은 데이터 파? $ALTIBASE_HOME/dbs/abc.dbf가 유실되었다. 참고) 메모리 테이블스페이스의 데이터 파?은 이와 같은 방법으로 복구될 수 없다. 복구 ?차 완? 복구에 필요? 아카이브 로그 파?을 확??다. iSQL(sysdba)> SELECT NAME, CREATE_LSN_LFGID, CREATE_LSN_FILENO FROM V$DATAFILES; ------------------------------ … /altibase_home/dbs/abc.dbf 0 18320 가장 최? 삭제된 로그 파?을 확?하기 위?서는 유틸리티 dumpla를 이용하여 loganchor의 내용을 확??다. $ dumpla loganchor0 [LOGANCHOR HEADER] Binary DB Version [ 5.3.3 ] Archivelog Mode [ Archivelog ] Begin Checkpoint LSN [ 0, 20345, 469859 ] End Checkpoint LSN [ 0, 20345, 470300 ] Disk Redo LSN [ 0, 20345, 469859 ] Global SN [ 9476323 ] Server Status [ SERVER SHUTDOWN ] Log File Group Count [ 1 ] Log File Group [ 0 ] End LSN [ 0, 20345,470341 ] ResetLog LSN [ 4294967295, 4294967295, 4294967295 ] Last Created Logfile Num [ 20350 ] Delete Logfile(s) Range [ 20344 ~ 20333 ] Update And Flush Count [ 316 ] New Tablespace ID [ 8 ] ARCHIVE_DIR 프로퍼티에 정의된 디렉터리에 logfile18320부터 logfile20344까지 ?재하는지 확??다. ?약 ?재하지 않는다면, 아카이브 로그파?을 백업 저장 장치로부터 ARCHIVE_DIR 프로퍼티에 지정된 디렉터리로 복사?다. logfile20345 이후의 로그 파?은 모두 LOG_DIR 프로퍼티에 지정된 디렉터리에 ?재하는 온라? 로그 파?이다. 즉, logfile18320부터 logfile20345까지의 로그 파?들은 유실된 abc.dbf 를 완? 복구하기 위? 반드시 필요하다. ARCHIVE_DIR과 LOG_DIR프로퍼티에 지정된 디렉터리에 ?재하는 로그 파?의 중복으로 ?? 발생되는 디스크 공? 낭비를 제거하기 위?서, 알티베이스가 직접 ARCHIVE_DIR프로퍼티에 지정된 디렉터리의 로그 파?을 인는다. 246 Administrators Manual CONTROL 구동 단계에서 다음 구?으로 유실된 abc.dbf 파?을 생성?다. iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE‘abc.dbf’; CONTROL 구동 단계에서 다음 구?으로 완? 매체 복구를 수행?다. iSQL(sysdba)> alter DATABASE RECOVER DATABASE; 매체복구 사례 2 아카이브 로그 모드로 데이터베이스를 ?영하고 있으며, 3? ?에 테이블스페이스 USER_DISK_TBS의 데이터 파?들을 백업하였다. 오늘 오?에 USER_DISK_TBS 테이블스페이스의 데이터 파?을 모두 잃어 버렸다. 백업 ?차 3??에 다음과 같이 백업을 수행했다. iSQL(sysdba)> ALTER DATABASE BACKUP TABLESPACE user_disk_tbs TO ‘/backup1’; iSQL(sysdba)> ALTER SYSTEM SWITCH LOGFILE; $ ls /backup1 USER_DISK_TBS01.dbf USER_DISK_TBS02.dbf USER_DISK_TBS03.dbf 복구 ?차 완? 복구에 필요? 아카이브 로그 파?을 확? 확?? 후, 아카이브 디렉터리로 ?당 파?들을 복사?다. 필요? 아카이브 로그 파?을 확?하는 방법은 복구될 데이터 파?의 헤더에 있는 정보를 참조하는 것이다. 헤더 정보는 dumpddf 유틸리티를 이용하여 다음과 같이 확?? 볼 수 있다. $ dumpddf -m -f USER_DISK_TBS01.dbf [BEGIN DATABASE FILE HEADER] Binary DB Version [ 5.4.1 ] Redo LSN [ 0, 4, 2257550 ] Create LSN [ 0, 0, 657403 ] [END DATABASE FILE HEADER] 위 결과는 백업된 데이터 파?을 이용하여 데이터베이스를 복원하려면 아카이브 로그 파? logfile4 이후 파?들을 필요로 함을 나타낸다. backup_dir디렉터리의 데이터 파? 백업을 USER_DISK_TBS테이블스페이스의 데이터 파?이 원래 있었던 $ALTIBASE_HOME/dbs/ 디렉터리에 복사?다. 백업 및 복구 247 $ cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs; CONTROL 구동 단계에서 다음 구?으로 완? 매체 복구를 수행?다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE; 매체복구 사례 3 아카이브 로그 모드로 데이터베이스를 ?영하고 있으며, 7??에 테이블스페이스 USER_DISK_TBS의 데이터 파?들을 백업하였다. 오늘 오후에 USER_DISK_TBS 테이블스페이스의 데이터 파?이 있는 /disk1 파? 시스템이 깨졌으나, /disk2파? 시스템은 정상이다. 이 경우 /disk1 파티?이 깨졌으므로 정상 상태의 /disk2 파티?에 백업된 데이터 파?을 옮겨 매체 복구를 수행?다. 백업 ?차 7? ?에 같이 백업을 수행했다. iSQL(sysdba)> ALTER DATABASE BACKUP TABLESPACE user_disk_tbs TO '/backup_dir’; iSQL(sysdba)>ALTER SYSTEM SWITCH LOGFILE; $ ls /backup_dir USER_DISK_TBS01.dbf USER_DISK_TBS02.dbf 복구 ?차 완? 복구에 필요? 아카이브 로그 파?을 확?하고, 아카이브 디렉터리로 ?당 파?들을 복사?다.backup_dir디렉터리에 있는 USER_DISK_TBS테이블스페이스의 백업 파?들을 온?? /disk2파? 시스템으로 복사?다. $ cp /backup_dir/*.dbf /disk2/dbs; CONTROL 구동 단계에서 USER_DISK_TBS 테이블스페이스의 데이터 파? 경로를 변경?다. iSQL(sysdba)> ALTER DATABASE RENAME DATAFILE '/disk1/dbs/USER_DISK_TBS01.dbf' TO '/disk2/dbs/USER_DISK_TBS01.dbf'; iSQL(sysdba)> ALTER DATABASE RENAME DATAFILE '/disk1/dbs/USER_DISK_TBS02.dbf' TO '/disk2/dbs/USER_DISK_TBS02.dbf'; Note: 이 작업 수행을 위?서 alter tablespace 명령을 사용? 수도 있다. 248 Administrators Manual iSQL(sysdba)> ALTER TABLESPACE user_disk_tbs RENAME DATAFILE '/disk1/dbs/USER_DISK_TBS02.dbf' TO '/disk2/dbs/USER_DISK_TBS02.dbf'; 데이터 파? 경로가 정확히 변경되었는지 v$datafile성능 뷰를 확??다. iSQL(sysdba)> SELECT * FROM V$DATAFILES; CONTROL 구동 단계에서 다음 구?으로 완? 매체복구를 수행?다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE; 매체복구 사례 4 아카이브 로그 모드로 데이터베이스를 ?영하고 있으며, 사용자 실수로 summary테이블을 DROP 하였다. 가장 최?의 ?체 온라? 백업 완료 시각: 2007년 9월 18? 12시 00분 테이블이 DROP된 시각: 2007년 9월 18? 15시 00분 현재 시각: 2007년 9월 18? 18시 00분 summary 테이블을 복구하기 위?서는 현재 시각의 약 3시? 30분 ?? 2007년 9월 18? 14시 30분 정각으로 데이터베이스를 불완? 매체 복구를 수행?야 ?다. 백업 ?차 지난번 백업 시 다음과 같이 ?체 데이터베이스를 백업하였다. iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO‘/backup_dir’; iSQL(sysdba)> alter SYSTEM SWITCH LOGFILE; 복구 ?차 1. 백업 받은 데이터 파?들을 원래 위치로 복사 ?다. $ cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs; 2. 메모리 테이블스페이스에 대? 핑퐁(ping pong) 체크 포?트 기 법을 사용하고 있기 때?에, 백업 시에는 메모리 테이블스페이스 의 ???(stable)? 데이터 파?? 복사되었다. 예) 백업받은 메모리 테이블스페이스의 데이터 파?이 다음과 같 다, SYS_TBS_MEM_DIC-1-0, SYS_TBS_MEM_DIC-1-1, SYS_TBS_MEM_DIC-1-2 SYS_TBS_MEM_DATA-0-0, 백업 및 복구 249 SYS_TBS_MEM_DATA-0-1, SYS_TBS_MEM_DATA-0-2 3. 백업된 메모리 테이블스페이스는 ?정?(stable) 데이터 파?이 기 때?에 ?정? 버?의 확? ?차 없이 복사하면 된다. $ cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DATA-0-0 $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DATA-0-1 $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DATA-0-2 $ALTIBASE_HOME/dbs 4. 불완? 복구는 백업된 로그앵커 파?을 사용?다. 백업 된 저장 장치로부터 로그앵커를 복사?다. $ cp /backup_dir/loganchor* $ALTIBASE_HOME/logs 5. 불완? 복구에 필요? 아카이브 로그 파?을 아래와 같이 확?? 다. iSQL(sysdba)> select last_deleted_logfile from v$lfg; LAST_DELETED_LOGFILE ------------------------ 15021 6. $ALTIBASE_HOME/trc 디렉터리에 생성되는 altibase_sm.log 파?에서 백업 완료 시 강제로 아카이브 처리된 파?을 확??다. [2007/09/18 13:59:59] [Thread-6] [Level-9] Waiting logfile15341 to archive 7. 위 결과에 의? logfile15021부터 백업 완료 ?무리 시 기록? 두었던 ?지링 아카이브 로그파?? logfile 15341까지 모두 ARCHIVE_DIR 프로퍼티에 지정된 디렉터리 (혹은 백업 장치)로 부터 LOG_DIR 프로퍼티에 지정된 디렉터리에 복사?다. 불완? 매체 복구는 완? 복구와 달리 로그 파? 중복이 불가피하게 허 용된다. 8. SYS_TBS_DISK_TEMP는 백업되지 않기 때?에 ?당 파?을 ? 들어 ?다. iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf' 9. 불완? 매체 복구를 다음과 같이 수행?다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL TIME ‘2007-09-18:14:30:00'; 10. 복구가 완료된 메모리 테이블스페이스에 대?서 모? ?정? 데 이터 파?들을 사용하여 불?정? 버?을 생성?다. $ cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-0 $ cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-1 $ cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-2 $ cp SYS_TBS_MEM_DATA-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DATA-0-0 250 Administrators Manual $ cp SYS_TBS_MEM_DATA-1-1 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DATA-0-1 $ cp SYS_TBS_MEM_DATA-1-2 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DATA-0-2 11. 불완? 매체 복구를 수행하였기 때?에 meta 구동 단계로 가면 서 resetlogs옵?을 사용하여야 ?다. iSQL(sysdba)> ALTER DATABASE MYDB META RESETLOGS; 12. resetlogs를 수행하였기 때?에 데이터베이스 ?체 백업을 받는 다. iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO ‘backup_dir’; 매체복구 사례 5 아카이브 로그 모드로 데이터베이스를 ?영중이며, 온라? 로그파?이 499번부터 600번까지 있고, 중? 로그파?? 570번 로그 파?이 유실되었다. 복구 ?차 불완? 복구에 필요? 데이터 파?과 로그앵커 파?을 백업 본으로부터 복사?다. 불완? 복구에 필요? 아카이브 로그 파?을 확??다. Logfile499부터 569까지의 리두 로그? 데이터베이스에 반영하고, logfile570번 이후의 로그 파?의 리두 로그는 반영하지 않는다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL; 불완? 미디어 복구를 수행하였기 때?에 meta 구동 단계로 가면서 resetlogs옵?을 사용하여야 ?다. iSQL(sysdba)> ALTER DATABASE MYDB META RESETLOGS; resetlogs를 수행하였기 때?에 데이터베이스 ?체 백업을 받는다. iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO ‘/backup_dir’; 매체복구 사례 6 노아카이브 로그 모드로 ?영중? 데이터베이스이지? 매체 복구를 수행? 수 있는 경우가 있다. 바로 임시(temporary) 테이블스페이스의 데이터 파?이 유실되는 경우이다. 임시 테이블스페이스에 대?서는 변경의 재수행이 필요 없기 때?이다. 백업 및 복구 251 복구 ?차 CONTROL 구동 단계에서 SYS_TBS_DISK_TEMP 테이블스페이스의 유실된 데이터 파? 대?에 새로? temp001.dbf를 생성?다. iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE ‘temp001.dbf’; 서버를 구동?다. iSQL(sysdba)> ALTER DATABASE dbname SERVICE; 매체복구 사례 7 아카이브 로그 모드로 데이터베이스를 ?영중이며, SYS_TBS_MEM_DIC 딕셔너리 테이블스페이스의 데이터 파?이 유실되었다. 백업 ?차 SYS_TBS_MEM_DIC 테이블스페이스를 테이블스페이스 단위 백업?다. iSQL(sysdba)> ALTER DATABASE BACKUP TABLESPACE SYS_TBS_MEM_DIC to ‘/backup_dir’; 복구 ?차 완? 복구에 필요? 아카이브 로그 파?을 확?? 후, 아카이브 디렉터리로 ?당 파?들을 복사?다. 필요? 아카이브 로그 파?을 확?하는 방법은 복구될 데이터 파?의 헤더에 있는 정보를 참조하는 것이다. 헤더 정보는 dumpci 유틸리티를 이용하여 다음과 같이 확?? 볼 수 있다 % dumpci -m -f SYS_TBS_MEM_DIC-0-0 [BEGIN CHECKPOINT IMAGE HEADER] Binary DB Version [ 5.4.1 ] LogFileGroup Count [ 1 ] LogFileGroup-0 Redo LSN [ 0, 4, 2257550 ] LogFileGroup-0 Create LSN [ 0, 0, 657403 ] [END CHECKPOINT IMAGE HEADER] 위 결과는 백업된 데이터 파?을 사용하여 데이터베이스를 복원하기 위?서는 logfile4 아카이브 로그 파? 이후의 파?들이 필요함을 나타낸다. 위의 백업 ?차에서는 메모리 테이블스페이스의 ?정?(stable) 데이터 파?? 백업된다. 따라서 백업된 파?이 SYS_TBS_MEM_DIC-0-0이라면 아래와 같이 데이터 파?을 복사하도록 ?다. 252 Administrators Manual $ cp /backup_dir/SYS_TBS_MEM_DIC-0-0 $ALTIBASE_HOME/dbs; $ALTIBASE_HOME/bin/dumpla loganchor0 결과 중 테이블스페이스 이름이 SYS_TBS_MEM_DIC? 테이블스페이스 속성들 중 Stable Checkpoint Image Num이? 핫목을 참고?다. % dumpla loganchor0 [ TABLESPACE ATTRIBUTE ] Tablespace ID [ 0 ] Tablespace Name [ SYS_TBS_MEM_DIC ] New Database File ID [ 0 ] Tablespace Status [ ONLINE ] TableSpace Type [ 0 ] Checkpoint Path Count [ 0 ] Autoextend Mode [ Autoextend ] Shared Memory Key [ 0 ] Stable Checkpoint Image Num. [ 1 ] Init Size [ 4 MBytes ( 129 Pages ) ] Next Size [ 4 MBytes ( 128 Pages ) ] Maximum Size [ 134217727 MBytes ( 4294967295 Pages ) ] Split File Size [ 1024 MBytes ( 32768 Pages ) ] [ MEMORY CHECKPOINT PATH ATTRIBUTE ] Tablespace ID [ 0 ] Checkpoint Path [ /home/altibase_home/dbs ] [ MEMORY CHECKPOINT IMAGE ATTRIBUTE ] Tablespace ID [ 0 ] File Number [ 0 ] Create LSN [ 0, 0, 2028 ] Create On Disk (PingPong 0) [ Created ] Create On Disk (PingPong 1) [ Created ] 백업 데이터 파?의 번호는 [0]이고 현재 ?정? 데이터 파?의 번호는 [1]이므로, 다음과 같이 복사?다. $ cd $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DIC-0-0 SYS_TBS_MEM_DIC-1-0 CONTROL 구동 단계에서 미디어 복구를 수행?다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE; 위의 과정에 의? 복구가 완료된 데이터 파?의 복사본을 생성?다. $ cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-0 미디어 복구가 완료되었으므로 재시작 자동복구를 수행?다. iSQL(sysdba)> ALTER DATABASE dbname SERVICE; 매체복구 사례 8 아카이브 로그 모드로 데이터베이스를 ?영하고 있으며, 사용자 실수로 테이블스페이스 USER_DISK_TBS가 삭제되었다. 삭제 시점은 2007년 4월 6? 22시 30분이었다. 테이블스페이스가 ?재했던 10분 ?의 상태로 데이터베이스를 복구하려고 ?다. 백업 및 복구 253 백업 ?차 ?지링 백업 시 다음과 같이 ?체 DB를 백업하였다. iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO ‘/backup_dir’; 복구 ?차 불완? 복구에 필요? 데이터 파?과 로그앵커 파?을 백업 본으로부터 복사?다. 백업 받은 데이터베이스의 모? 디스크 테이블스페이스의 데이터 파?들을 데이터 파?들의 원래 위치로 복사?다. $ cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs $ cp /backup_dir/SYS_TBS_* $ALTIBASE_HOME/dbs 불완? 복구에 필요? 아카이브 로그 파?을 확??다. 불완? 복구는 백업된 로그앵커 파?을 사용?다. 백업 저장 장치로부터 로그앵커 파?을 복사?다. $ cp /backup_dir/loganchor* /ALTIBASE_HOME/logs; SYS_TBS_DISK_TEMP테이블스페이스는 백업되지 않기 때?에 ?당 파?을 새로 ?들어 ?다. iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE ‘temp001.dbf’ 불완? 미디어 복구를 수행?다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL TIME '2007-04-06:22:20:00'; 불완? 미디어 복구를 수행하였기 때?에 meta 구동 단계로 가면서 resetlogs 옵?을 사용하여야 ?다. iSQL(sysdba)> ALTER DATABASE mydb META RESETLOGS; 서버를 구동?다. iSQL(sysdba)> ALTER DATABASE mydb SERVICE; 로그가 리셋되었기 때?에 ?체 데이터베이스의 백업을 수행하는 것이 좋다. iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO ‘/backup_dir’; SQL 튜닝 255 11. SQL 튜닝 본 장에서는 질의 성능을 향상시키기 위? SQL 튜닝 방법에 대하여 설명?다. 256 Administrators Manual SQL 튜닝 개요 SQL 튜닝이? SQL?의 성능을 극대화하기 위? 조치하는 모? ??의 작업을 의미하며, 다음이 포함된다. SQL? 재작성 데이터베이스 스키? 재설계 알티베이스 프로퍼티 조정 ?영체제 커널 파라미터 조정 SQL 튜닝 방법 중 SQL?의 재작성과 데이터베이스 스키? 재설계의 경우는 알티베이스내의 쿼리 처리 방법과 제? 사핫 등에 의? 쿼리 성능이 영향을 받기 때?에 알티베이스내의 쿼리 처리 방법에 대? 심도 높은 이?가 요구된다. 또?, 메모리 테이블과 디스크 테이블을 모두 사용? 수 있기 때?에 저장 매체의 특성에 따라서 쿼리 처리에 어떻게 영향을 미치는지에 대? 이?가 필요하다. 본 ?에서는 ?략하게 성능 관? 이슈를 살펴보고 질의 튜닝을 위? 필요? 기본 개념에 대하여 설명?다. 성능 관? 이슈 실행 계획 트리(Execution plan tree) 클라이?트에서 SQL?의 수행을 요구하면 질의 처리기는 구? 검사, 정당성 검사, 및 최적화 과정을 거쳐 실행 ?차를 정의? 실행 계획 트리를 생성?다. ?약 호스트 변수가 ?재하면 알티베이스는 이들 변수를 바?딩? 후 실행 계획에 따라 데이터베이스에 접?? 레코드를 검색? 것이다. 이러? SQL?의 수행에 소요되는 시? 중 대부분은 실제로 구?을 실행하는 시?으로, 복잡? SQL?의 경우 실행 계획 트리 구조가 성능에 큰 영향을 끼?다. SQL Plan Cache 알티베이스 HDB에서는 세??에 SQL 구?의 실행 계획이 공유될 수 있다. 이는 SQL 구? 수행시?다 매번 실행 계획을 ?드는 비용을 ??다. 이 기능을 이용하려면 SQL Plan Cache와 관?된 SQL_PLAN_CACHE_SIZE 프로퍼티의 값을 적?히 설정?야 ?다. SQL 튜닝 257 데이터베이스 스키마와 데이터 용량 우선적으로 응용프로그램의 특성 및 자원 ?용의 효율에 따라 메모리 테이블 및 디스크 테이블의 사용을 적?히 고려하여야 ?다. ?반적으로 자주 사용되는 데이터는 메모리 테이블에, 접? 빈도가 낮은 데이터는 디스크 테이블에 저장하여 관리하는 것이 유리하다. 응용 프로그램에서 사용되는 SQL?의 종류를 고려? 각 SQL? 별로 테이블에 접?하는 회수, 접?하는 레코드 수 및 디스크 페이지 수가 최소 비용이 되도록 테이블 스키?의 구성과 ?덱스 구성에 유의?야 ?다. 또?, 단순? SQL? 또는 레코드 건수가 ?은 테이블에 대?서는 술어(predicate) 내 칼럼값의 비교 비용이 성능에 큰 영향을 미?다. 그러므로 데이터 변?과 비교 비용을 최소화? 수 있는 적합? 데이터 타입의 선정이 중요하다. 따라서 가능? 적은 수의 레코드에 접?하도록 SQL?을 작성하여 ?대적 비교 회수를 ?여야 하며, 비교 연산 시 데이터 변?이 ?어나지 않도록 칼럼의 데이터 타입과 비교되는 값의 데이터 타입을 잘 선정?야 ?다. 응용프로그램 로직(테이블 접근 순서) ?약 여러 클라이?트가 알티베이스 HDB 데이터베이스에 세?으로 연결된 경우, 각 클라이?트의 테이블 접? 순서가 성능에 영향을 미칠 수도 있다. ? 트?잭? 내에서 DML?을 여러 개 사용하여 여러 테이블에 접?하는 경우, 응용프로그램에서 테이블에 접?하는 순서 등을 잘못 설계했다면 lock 을 획득하기 위? 대기하는 시?(lock waiting time)으로 ?? ?체 응용프로그램 성능이 저하될 수도 있다. 따라서 클라이?트 응용프로그램의 로직 설계에 유의?야 ?다. 시스템 리소스 ? SQL?의 처리 시 성능에 영향을 미치는 시스템 리소스는 가용? 메모리의 크기, 메모리 버퍼의 크기, 디스크 성능과 CPU 성능이다. 검색 질의의 성능은 물? 메모리 테이블?을 사용? 경우 디스크 성 능에 영향을 받지 않는다. 그러나, 디스크 테이블을 검색? 경우 디스 크 성능 및 가용? 메모리 버퍼의 크기에 따라 질의 성능이 영향을 받게 된다. 이러? 점은 메모리 테이블을 검색? 경우 ?정? 질의 응답 시?을 기대? 수 있는 반면, 디스크 테이블을 검색? 경우 질 258 Administrators Manual 의 수행 시점의 ?경에 따라 ?은 성능 차이를 보이게 되는 원?이 된다. ORDER BY ? 또는 GROUP BY ? 등이 포함된 질의를 처리?때, 질의 처리기는 sorting 기법이나 hashing 기법을 사용하는데 이 처 리의 중? 결과를 저장하기 위? 메모리 임시 테이블 또는 디스크 임 시 테이블을 사용하게 된다. 중? 결과가 메모리 임시 테이블에 저장되는 경우, 사용되는 메모리 는 데이터베이스 영역에 잡혀 있는 메모리가 아니다. 그러므로 메모 리 테이블의 크기가 크다면 ?은 메모리가 필요? 수 있으므로 질의 처리시 메모리 스와핑으로 ?? 성능 저하가 생기지 않도록 주의?야 ?다. 중? 결과가 디스크 임시 테이블에 저장되는 경우, 사용되는 자원은 디스크 임시 테이블스페이스의 디스크 영역과 메모리 버퍼 영역이다. 가용? 메모리 버퍼 영역의 크기에 따라 성능에 커다? 영향을 미치 게 된다. 또? 질의 처리 작업은 연산자를 처리하기 위? 작업이 ?아 CPU를 ?이 사용?다. 그러므로 CPU 점유율과 CPU 성능도 질의 성능에 영향을 ?이 미?다. SQL 튜닝 일반 이 ?에서는 알티베이스 사용자를 위? ?반적? 튜닝 방법?에 대? ?략하게 설명?다. SQL 성능 측정 방법 APRE, ODBC, 또는 JDBC 등을 사용? 응용프로그램 개발시, 응용프로그램 내에서 시?을 구하는 함수를 이용하여 쿼리 처리에 소요되는 시?을 측정? 수 있다. 또? iSQL에서 다음 iSQL명령어를 이용? 쿼리 수행 시?을 측정? 수도 있다. SET TIMING ON; 메모리 테이블의 경우 iSQL로 질의를 반복 수행 시 거의 유사? 성능을 얻을 수 있으나, 디스크 테이블의 경우는 반복 수행 시 버퍼 교체가 적게 발생하여 최초 수행 때보다 다음 수행 시 보다 나은 성능을 얻게 된다. 이는 디스크 테이블에 대하여 동시 수행되는 질의들이 ?을 경우 버퍼 교체로 ?? 그 성능의 ?정함을 보장? 수 없음을 의미?다. SQL 튜닝 259 그러나 ?반적으로 iSQL상에서 SQL ?을 튜닝하여 성능을 향상시킨 SQL ?의 경우 실제 응용프로그램에서도 같은 비율의 성능 향상을 볼 수 있다. 실행 계획 트리의 분석 SELECT, INSERT, UPDATE, DELETE 등의 SQL DML?의 실행 계획 트리는 iSQL 상에서? 확?이 가능하다. DELETE ?, UPDATE ?, 및 MOVE ?은 SELECT ? 처리와 같은 최적화 과정을 거치므로 내부적으로 동?? 실행 계획 트리가 생성된다. INSERT?의 경우 INSERT INTO SELECT 의 SELECT? 부분에 대? 실행 계획 트리의 확?이 가능하다. ?반적으로 실행 계획 트리에서 확??야 ? 내용은 다음과 같다. 자세? 내용은 다음 ?에서 살펴본다. 액세스 방법이 효율적?가? 조? 순서 및 방법은 바람직?가? 적?? 데이터 타입 및 연산을 사용하는가? 불필요? hashing 및 sorting이 수행되지 않는가? 질의 튜닝 실행 계획 트리를 사용?서 성능 저하 요소를 분석? 후, 이에 대? 적?? 조치를 취함으로서 성능을 개선? 수 있다. 질의 튜닝 방법은 질의 최적화 과정 및 질의 실행기에 대? 개념 설명 과정에서 자세히 다룬다. 메모리 테이블과 디스크 테이블 알티베이스는 메모리 테이블과 디스크 테이블을 모두 지원하는 최초의 HDB (Hybrid Database)이다. 따라서, 메모리 테이블과 디스크 테이블에 대? 질의 처리 방법의 차이를 이?하는 것은 질의 튜닝에 있어 큰 도움이 된다. 메모리 테이블과 디스크 테이블을 위? 질의 처리기의 기본적? 차이는 다음과 같다. Query Processor Item Memory Table Disk Table Executor Object identifier Pointer OID(RID) Buffer management N/A Limited buffer 260 Administrators Manual Join methods One-pass algorithms Multi-pass algorithms Optimizer Main cost CPU Disk Index selection Minimize record access Minimize disk I/O Cost factor T(R), V(R.a), etc + B(R), M 참조 T(R): Table R의 레코드 개수, V(R.a): R.a 칼럼의 Value Cardinality B(R): Table R의 디스크 페이지 개수, M: 가용? 메모리 버퍼 개수 질의 처리기는 크게 최적화기(Optimizer)와 실행기(Executor)로 구분된다. 최적화기는 비용 계산을 통? 실행 계획 트리를 생성?다. 실행기는 실행 계획 트리의 각 노드에 따라 실제로 구?을 실행?다. 알티베이스의 실행기와 최적화기는 저장 매체의 차이를 충분히 반영 하는 반면, 이에 대? 별도의 구분 없이 실행 계획을 생성하고, 질의 처리시에 그 특성?을 반영하여 수행? 수 있도록 설계되어 있다. 즉, 메모리 테이블과 디스크 테이블의 ?용된 질의 처리에 있어서도 각 저장 매체의 특성은 충분히 반영하면서 동?? 처리 과정을 따르게 된다. 실행기(Executor) 실행기는 테이블의 저장 매체에 따라 위의 표에서와 같이 기본적? 개념 및 그 동작에 있어 차이점이 있다. 먼저 레코드를 구별하는 “객체 식별자(Object identifier)”는 메모리 테이블의 경우 포?터이며 디스크 테이블의 경우 OID(RID)와 같은 특정 디스크 주소로 변?? 수 있는 식별자이다. 이러? 차이는 레코드 접?에 있어 메모리 테이블은 직접 접?이 가능? 반면 디스크 테이블은 주소 변?에 의? 접?이 필요함을 의미하다. 메모리 테이블에 대? 질의 처리시에는 버퍼를 사용하지 않아 이에 대? 고려가 필요없다. 반면, 디스크 테이블에 대? 질의 처리는 제?된 메모리 버퍼 내에서 이루어지기 때?에 버퍼에 원하는 레코드가 없을 경우(Buffer miss) 디스크 I/O를 유발하는 버퍼 교체(Buffer replacement)가 수반된다. 조? 방법은 크게 다음으로 분류된다. nested loop join hash-based join sort-based join merge join 각 조? 방법을 위?서 필요에 따라 중? 결과가 저장된다. 이 때 제?된 메모리에 이 결과를 모두 적재? 수 있는 지의 여부에 따라 SQL 튜닝 261 one-pass 또는 multi-pass 알고리즘으로 처리된다. One-pass 알고리즘의 경우 가용 메모리 버퍼에 중? 결과를 모두 적재? 수 있을 때 사용되는 반면, multi-pass 알고리즘은 중? 결과를 메모리상에 모두 적재? 수 없을 때 버퍼 교체를 최소화하기 위? 사용된다. 메모리 테이블에 대? 조?의 경우 버퍼 제?이 없어 one-pass 알고리즘이 사용될 수 있는 반면, 디스크 테이블의 경우 버퍼 제?을 고려하여 one-pass 또는 two-pass 알고리즘이 사용된다. 위와 같이 실행기의 처리 방식은 저장 매체에 따라 ?본적으로 다르며, 성능에 있어서도 큰 차이를 보이게 된다. 최적화기(Optimizer) 질의 최적화기는 테이블이 저장된 저장 매체에 따라 위의 표와 같이 기본적? 개념 및 그 동작에 있어 차이점이 있다. 최적화기는 메모리 테이블을 조회? 경우 CPU 비용을 최소화? 수 있도록 실행 계획을 생성?다. 반면, 디스크 테이블을 조회? 경우 디스크 I/O를 최소화? 수 있도록 실행 계획을 생성?다. 즉, 저장 매체에 따라 질의 성능에 가장 큰 영향을 미치는 자원 사용을 최소화? 수 있는 실행 계획을 생성?다. 최적화기는 테이블에 접?하는 방법(Access method)을 선택? 때, 메모리 테이블의 경우 인을 레코드 수를 최소화? 수 있는 ?덱스를 선택하는 반면, 디스크 테이블의 경우 디스크 I/O를 최소화? 수 있는 접? 방법을 선택하게 된다. 이러? 차이는 메모리 테이블의 경우 대부분의 경우 ?덱스를 사용하는 것이 ?체 테이블 스캔보다 나은 성능을 보장하지?, 디스크 테이블의 경우 데이터의 분포에 따라 ?덱스를 사용하는 것보다 ?체 테이블 스캔이 오히려 적은 디스크 I/O를 발생시켜 보다 나은 성능을 보? 수 있기 때?이다. 최적화기는 비용 계산을 위? ?자로 다양? 통계 정보를 사용?다. 메모리 테이블에 대? 비용 계산시에는 테이블의 레코드 개수[T(R)], 칼럼내의 서로 다른 값의 개수[V(R.a)], 및 칼럼의 최소와 최대값 등의 통계 정보가 사용되는 반면, 디스크 테이블에 대? 비용 계산시에는 이 외에도 테이블이 사용하고 있는 디스크 페이지 개수[B(R)], 가용? 메모리 버퍼 페이지 개수[M]등의 추가적? 통계 정보가 이용된다. 질의 처리 (Query Processing) 개요 262 Administrators Manual SQL?의 튜닝 시 핫상 모? 응용 프로그램에 적용? 최적의 성능을 발휘하는 ?대적? 규칙을 제시하기는 쉽지 않다. 데이터베이스의 설계 또는 응용 프로그램의 비지니스 로직에 따라 SQL 튜닝 방법은 매우 다양하다. 따라서 이 ?에서는 하나의 SQL?이 어떠? 과정을 거쳐 처리되는지, 성능에 영향을 미치는 요소는 어떠? 것들이 있는지에 대? 설명하고 ?반적? 방법?에 대?서? 제시?다. DBMS에서 SQL? 처리를 담당하는 모듈을 질의 처리기(Query Processor)라 ?다. 질의 처리기는 사용자가 수행을 요구? SQL?에 대? 정당성을 검사? 후 데이터베이스에 접?하는 최적의 접? 순서와 방법을 결정하고, 이에 따라 조건에 맞는 레코드를 검색? 후 필요? 연산을 수행하여 ?지링으로 클라이?트에게 처리? 값을 돌려주는 모듈이다. 질의 처리수행 과정을 개략적으로 도식화하면 다음과 같다. Server Parsing Validation Optimization Binding Execution Database Client Prepare Bind Execute Fetch [그림 11-1] Query Processing 순서 각 단계별 수행 작업은 다음과 같다. 1. 구? 분석(Parsing): SQL?의 ?법을 검사(syntax 검사)하고 구 ? 분석 정보를 저장하는 파스 트리(Parse Tree)를 생성?다. 2. 정당성 검사(Validation): SQL?의 의미상 정당성을 검사 (semantic 검사)하고 메타 테이블을 검색하여 파스 트리를 확장 ?다. SQL 튜닝 263 3. 최적화(Optimization): 주어? 파스 트리에 기반하여 다양? 통 계 정보와 접? 비용 계산을 통? 최적화된 실행 계획을 생성? 다. 4. 바?딩(Binding): 호스트 변수값(host variable value) 을 생성된 실행 계획에 연결?다. 5. 실행(Execution): 실행 계획 트리에 따라 SQL?을 실행?다. 질의를 튜닝하기 위? 알티베이스의 질의 최적화와 질의 실행 과정을 이?하는 것은 매우 중요하다. 다음 장에서 이를 기반으로 ? 질의 튜닝 방법에 대하여 자세히 알아본다. 264 Administrators Manual 질의 최적화 과정 질의 최적화(optimization) 과정은 주어? SQL을 분석하여 가능? 실행 계획을 작성하고 이에 대? 비용 평가를 통? 가장 효율적? 실행 계획을 선택하는 과정이다. 질의 성능의 대부분이 이 과정에서 결정된다. 복잡? 질의?수록 질의 최적화 과정의 정확성에 의?서 성능이 좌우된다. 질의 최적화 개요 Optimizer의 구조 최적화 이? 단계에서는 주어? 질의?이 구? 분석(parsing)과 의미 분석(validation) 과정을 거치게 되며, 이 과정에서 파싱 트리가 생성된다. Optimizer는 이 파싱 트리로부터 각종 비용 평가를 통? 효율적? 실행 계획 트리(plan tree)을 생성?다. 이러? 과정을 수행하는 optimizer의 구조는 다음과 같다. Graph (Logical Operator) Parse Tree Plan Tree (Physical Operator) Optimizer Graph Manager Plan tree Manager Predicate Manager [그림 11-2] Query Processing 순서 Optimizer는 크게 그래프 관리자, 실행 계획 관리자, Predicate 관리자로 구성된다. Optimizer의 각 관리자의 역?은 다음과 같다. 그래프 관리자는 주어? 파싱 트리를 이용하여 논리 연산자로 구성된 그래프를 생성하고 ?당 그래프에 대? 구? 실행 비용을 계산하여 최적화 방법을 결정?다. 실행계획 관리자는 생성된 그래프를 이용하여 주어? 최적화 방법에 따라 실행 계획 트리를 생성?다. Predicate 관리자는 그래프 관리자와 실행 계획 관리자가 실행 계획 트리를 결정하고 생성하기 위? 필요? 정보를 제공?다. SQL 튜닝 265 그래프 요소(논리 연산자)의 종류 그래프는 총 7개 요소로 구성되며, 각 그래프 요소의 주요 기능은 다음과 같다. 구분 그래프 요소 기능 관? SQL 구? Critical path Selection 단? 테이블에 대? 접? 방법 FROM, WHERE Join 조?의 수행 순서 및 방법 FROM, WHERE Non critical path Grouping 그룹과 aggregation 연산의 수 행 방법 GROUP BY, HAVING, aggregation 연산 Distinction 중복 레코드 제거의 수행 방법 DISTINCT Set 집합 연산의 수행 방법 UNION, UNION ALL, INTERSECT, MINUS Sorting 정? 연산의 수행 방법 ORDER BY Projection 프로젝? 연산의 수행 방법 SELECT [표 11-1] 그래프의 종류 Optimizer의 관점에서 검색 질의 성능에 가장 큰 영향을 미치는 부분은 FROM 과 WHERE ?로 이를 critical path라 ?다. 이 외의 GROUP BY 와 ORDER BY ? 등과 같은 부분을 non-critical path라 ?다. Optimizer는 critical path의 처리를 위? selection과 join 등의 그래프 요소를 사용하여 이에 대? 수행 방법을 결정하며, non- critical path의 처리를 위? grouping, distinction, set, sorting, 및 projection과 같은 그래프 요소를 사용하여 수행 방법을 결정하게 된다. 실시간 통계 정보 Optimizer는 다양? 실행 계획의 비용 계산을 위? 실시? 통계 정보를 사용?다. Optimizer는 기본적? 통계 정보를 사용? 뿐? 아니라 최적화 과정을 통? 새로? 정보를 추정하고 비용 계산을 통? 다양? 예측 정보를 산출?낸다. 기호 설명 T( R ) 테이블 R의 레코드 수 V(I) ?덱스 I 의 Value Cardinality, ?덱스 키값의 서 로 다른 값의 개수 V(R.a) 칼럼 R.a의 Value Cardinality, 서로 다른 값의 개 수 266 Administrators Manual MIN(R.a) 칼럼 R.a의 최소값 MAX(R.a) 칼럼 R.a의 최대값 B( R ) 테이블 R의 디스크 페이지 개수 M 메모리 버퍼의 페이지 개수 [표 11-2] 실시? 통계 정보 위와 같은 실시? 통계 정보는 데이터의 변경이 발생 ? 때?다 별도의 부하 없이 변경되며, 사용자의 개입 없이 데이터베이스 서버에 의? 비교적 정확? 정보가 관리된다. Optimizer는 이러? 실시? 통계 정보를 사용하기 때?에 다양? 실행 계획들에 대? 비용 평가가 가능하며 효율적? 실행 계획을 생성? 수 있다. 그러나, 통계 정보가 모? 질의 최적화를 위? 충분? 정보가 될 수 없으며, Optimizer가 모? ?경에서 핫상 효율적? 실행 계획을 생성? 수 있는 것은 아니다. 따라서, 특정 질의의 경우 사용자의 성능 향상을 위? 작업이 필요? 수 있으며 이를 위?서는 알티베이스 질의 최적화 개념을 이?하는 것이 매우 중요하다. 질의 최적화 과정 알티베이스의 optimizer는 성능에 가장 큰 영향을 미치는 critical path에 대? 최적화 방법을 우선적으로 결정하고, 이 후에 non- critical path를 처리하는 bottom-up 방식의 최적화 순서를 따르고 있다. Critical path에 대? 실행 방법을 결정하기 위? 최적화 과정은 다음과 같다. 1. 정규화: 사용자가 정의? WHERE ?을 CNF(Conjunctive Normal Form)와 DNF(Disjunctive Normal Form) 두 가지의 정 규화된 형태로 변형?다. 2. 각 정규화된 형태(CNF와 DNF)는 다음과 같은 단계로 처리된다. 조건?의 분류: 정규화된 조건?을 하나의 테이블에 관계된 조건과 두 개 이상의 테이블이 관계된 조건으로 분류?다. 액세스 방법 결정: 우선적으로 각 테이블에 대? 조건?을 기?으로 비용이 가장 적은 ?덱스 선택 등의 액세스 방법을 결정?다. 여기서 선택된 액세스 방법은 조? 과정을 통? 재조정된다. 조? 순서의 결정: 복잡? 질의 처리 과정에서 조?의 순서는 질의 성능에 가장 큰 영향을 미치는 요소이며 이는 join greedy algorithm을 통? 결정된다. 조? 방법의 결정: 조? 순서의 결정 후 각 조? 순서별로 SQL 튜닝 267 최적의 조? 방법을 선택?다. Non-critical path의 실행 방법을 결정하는 최적화 과정은 critical path에 대? 최적화 이후에 수행되며 그 과정은 다음과 같다. 1. 그룹/Aggregate 연산의 수행 방법 결정: 질의에 GROUP BY 또 는 HAVING?이나, aggregation 연산이 포함되어 있을 경우 이 를 처리하기 위? 수행 방법을 결정?다. 2. DISTINCT?의 수행 방법 결정: 질의에 DISTINCT ?이 포함되어 있을 경우 이를 처리하기 위? 수행 방법을 결정?다. 3. SET ?의 수행 방법 결정: 질의에 UNION, UNION ALL, INTERSECT, 또는 MINUS ? 등이 있을 경우 이를 처리하기 위 ? 수행 방법을 결정?다. 4. ORDER BY?의 수행 방법 결정: 질의에 ORDER BY?이 포함 되어 있을 경우 이를 처리하기 위? 수행 방법을 결정?다. 5. 프로젝?의 수행 방법 결정: SELECT 구?에 포함되어 있는 칼럼 등을 위? 프로젝? 수행 방법을 결정?다. subquery내에 ?재 하는 SELECT 구?? 경우 다양? 최적화 방법들이 사용될 수 있 다. 질의 정규화 정규화의 개념 사용자가 작성? WHERE 조건?은 매우 다양? 형태로 표현된다. Optimizer는 다양? 조건 처리를 ?관적이고 효율적? 방법으로 처리하기 위? 사용자가 정의? WHERE?을 정형화된 형태로 변경?다. 이러? 과정을 정규화라고 ?다. 정규화는 AND, OR, NOT 등의 논리식을 사용?서 조건?을 확장하고 변형하는 과정이다. AND연산자를 최상위 논리식으로 표현하는 방법을 CNF (Conjunctive Normal Form)이라 하며, OR연산자를 최상위 논리식으로 표현하는 방법을 DNF (Disjunctive Normal Form)이라 ?다. CNF 정규화는 주어? 조건?을 AND연산자를 최상위로 하여 하위에 OR 논리 연산자가 구성되도록 재배치하는 것이다. 다음 예는 조건?이 CNF정규화를 사용?서 변?될 때 결과로 나타나는 구조를 보여?다. WHERE (i1 = 1 AND i2 = 1) OR i3 = 1 CNF: (i1 = 1 OR i3 = 1) AND (i2 = 1 OR i3 = 1) 268 Administrators Manual DNF 정규화는 주어? 조건?을 OR 연산자를 최상위로 하여 하위에 AND 논리 연산자로? 재구성되도록 재배치하는 과정이다. 다음 예는 조건?이 DNF 정규화를 사용?서 변?될 때 결과로 나타나는 구조를 보여?다. WHERE (i1 = 1 OR i2 = 1) AND i3 = 1 DNF: (i1 = 1 AND i3 = 1) OR (i2 = 1 AND i3 = 1) 즉, optimizer는 주어? 조건?을 CNF로 변?했을 때의 실행 비용과, DNF로 변?했을 때의 실행 비용을 비교하여 보다 나은 정규화 형태를 선택하게 된다. ?반적으로 optimizer는 CNF 기반의 실행 계획을 선택하며, ?부의 경우 DNF 기반의 실행 계획을 선택?다. 예를 들어, 다음과 같은 질의를 살펴보자. SELECT * FROM T1 WHERE i1 = 1 OR i2 = 1; CNF 정규화: AND (i1 = 1 OR i2 = 1) DNF 정규화: (i1 = 1 AND ) OR (i2 = 1 AND ) 위의 조건?은 T1 테이블에 ?덱스가 없거나 하나의 칼럼에? ?덱스가 있는 경우는 CNF로 처리된다. 즉, T1 테이블을 ?체 스캔하여 질의를 처리하는 것이 가장 효율적이다. 그러나, i1과 i2 칼럼에 각각 ?덱스가 있는 경우는 DNF로 정규화하여 각각의 ?덱스를 모두 사용하여 (i1 = 1) 의 결과와 (i2 = 1)의 결과를 따로 얻어 합치는 것이 보다 효율적이다. 이와 같이 동?? 조건식이라 하더라도 ?덱스의 유무에 따라 다른 타입의 정규화가 선택된다. 이는 optimizer가 각 경우의 실행 비용을 비교하여 결정?다. 물?, 논리 연산자가 없거나 OR 연산자가 ?재하지 않는 경우라면 optimizer는 CNF 정규화?을 사용하게 되며, OR 연산자가 ?재하는 경우에는 CNF와 DNF를 모두 구성하고 각각의 비용을 비교하여 실행 계획을 생성?다. 정규화 튜닝 앞에서 살펴 보았듯이 정규화 과정은 조건?의 확장을 불가피하게 ?다. 따라서, 조건? 기술 시 정규화된 형태로 구성하는 것은 조건?의 확장을 방지하여 불필요? 비교 연산을 제거? 수 있다. 예를 들어, 다음 조건?은 CNF 또는 DNF로 수행이 가능하지?, 이는 질의 변경을 통? CNF로? 동작하게 ? 수 있다. SQL 튜닝 269 WHERE i1 = 1 OR i1 = 2 OR i1 = 3 CNF 정규화: i1 IN (1, 2, 3) 유사? 예로 다음과 같은 질의는 CNF 또는 DNF로의 질의 변형을 통? 불필요? 정규화 과정을 제거하고 동?? 조건 비교를 방지하여 성능을 향상? 수 있다. WHERE (i1 = 1 AND i2 = 1) OR (i1 = 2 AND i2 = 2) CNF 정규화: (i1, i2) IN ( (1,1), (2,2) ) WHERE (i1 = 1 AND i2 = 1) OR ( i3 = 1 AND i4 = 1) DNF 정규화: (i1, i2) = (1, 1) OR (i3, i4) = (1, 1) 물? 정규화 형태의 기술 시 테이블의 ?덱스 정보 등을 반드시 고려하여야 ?다. 사용자가 정규화 형태로 기술하였다 하더라도 optimizer에 의? 원하지 않는 정규화 형태가 선택될 수 있다. 이러? 경우 힌트를 통? 제어? 수 있는데, 이는 힌트를 설명? ?에서 자세히 설명다. 조건? 조건?의 구분 WHERE?에 기술된 조건?은 정규화를 통? ?관된 형태로 변경되고 optimizer는 조건?을 이용? critical path의 효율적 처리를 위? 각 조건을 분류?다. 조건?은 다음과 같이 크게 세 가지로 구분? 수 있다. ? 테이블에? 관?된 조건: T1.i1 = 1 과 같이 하나의 테이블에? 관?된 조건 여러 테이블과 관?된 조건: T1.i1= T2.i1 또는 T1.i1 + T2.i1 > 0 과 같이 두 개 이상의 테이블과 관?된 조건 테이블과 관? 없는 조건: 1 = 1 또는 1 = ? 과 같은 테이블의 레코드와 관?이 없는 조건 이렇게 조건?을 분류하는 것은 액세스 방법의 선택, 조? 순서 및 조? 방법의 결정을 위? 사용되며 조건?의 적?? 기술은 SQL 튜닝의 가장 중요? 요소이다. Constant Filter의 ?용 1 = 1 또는 1 1과 같이 테이블이 소유? 값에 관계 없이 핫상 TRUE 또는 FALSE를 결정하는 조건을 constant filter라 ?다. 270 Administrators Manual Constant filter는 핫상 같은 논리값을 갖기 때?에 질의 수행 과정에서 ? 번? 비교하고 추가적? 비교 연산 비용이 소요되지 않는다. 즉, constant filter의 논리값이 FALSE? 경우에는 어떠? 검사도 추가적으로 발생하지 않으며, 테이블에 접?? 필요도 없다. 무의미? 보이는 constant filter도 다음과 같이 매우 다양? 용도로 ?용? 수 있다. 그 예로 Schema? 구성하고 데이터는 구축하지 않고 싶은 경우에 constant filter를 ?용? 수 있다. 다음과 같은 질의가 이에 ?당하는 예이다. CREATE TABLE T3 AS SELECT * FROM T1, T2 WHERE 1 1; 위와 같이 T1과 T2 테이블의 데이터는 가지지 않으면서 모? 칼럼 정보를 가? T3 테이블을 ?들고 싶을 경우 constant filter를 사용하면 원하는 작업을 수행? 수 있다. 또?, 다음 예와 같이 검색 권?을 제?하는 용도로 ?용? 수 있다. SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND ? > 20; 위와 같이 나이값에 ?당하는 호스트 변수를 지정하여 조건에 부합하지 않는 사용자가 질의를 수행하거나 결과값이 없는 질의의 수행으로 ?? 부하 등을 방지? 수 있다. 이 외에도 optimizer는 다음과 같이 subquery를 포함하고 있는 조건?도 constant filter로 처리하여 ? 번? 수행하고 subquery가 반복적으로 수행되지 않게 ? 수 있다. SELECT * FROM T1 WHERE EXISTS ( SELECT * FROM T2 WHERE T2.date = SYSDATE ); 위의 예제에서 EXISTS 조건은 T1의 데이터와 ?혀 관계 없는 constant filter이다. Push Selection 기법 정규화와 조건?의 분류 과정을 통? 구분된 단? 테이블에 대? 조건?은 액세스 방법을 결정하는 데 가장 중요? 요소이다. Optimizer는 조건?의 형태에 따라 다양? 최적화 기법들을 적용? 수 있다. Optimizer에서 조건?을 이용? 가장 ?반적? 최적화 방법이 push selection 기법이다. 이는 조건?을 분류하여 ?당 테이블에 속하는 조건이 먼저 검사되도록 하는 것이다. 예를 들어, 다음과 같은 질의를 살펴 보자. SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND T1.i2 = abc; 위의 질의에서 조건?을 위? 다양? 실행 계획의 생성이 가능하다. SQL 튜닝 271 구체적으로 말하면, optimizer는 T1과 T2테이블을 먼저 조합? 후에 조건?을 비교? 수도 있으며, T1 테이블에 대? 조건을 먼저 이용하여 T1의 결과 집합을 ?? 후에 T2 테이블과 조?을 수행? 수도 있다. 이와 같이 조?이 수행되기 ?에 WHERE?의 조건을 처리하는 것이 push selection의 가장 ?반적? 형태이다. Optimizer는 실행 비용 및 수학적 ?치성 등을 고려하여 push selection의 다양? 형태를 고려하게 된다. Optimizer가 사용하는 대표적? push selection 기법은 다음과 같다. 뷰에 대? push selection Outer 조?에 대? push selection 조?에 대? push selection 뷰에 대한 Push Selection 뷰에 대? push selection 기법은 사용자 정의 뷰에 대하여 질의를 수행 시 WHERE ?에 기술된 조건을 뷰의 내부에 적용하는 기법이다. 예를 들어, 다음과 같이 정의된 뷰와 이에 대? 질의가 있다고 하자. CREATE VIEW V1(a1, a2) AS SELECT i1, i2 FROM T1 WHERE i2 > 20; SELECT * FROM V1 WHERE a1 = 1; Optimizer는 ?당 질의의 최적화 과정에서 뷰에 대? push selection 기법을 사용하는 것이 보다 효율적? 실행 계획이라고 판단하면, WHERE ?의 조건이 내부적으로 다음과 같은 형태로 처리되도록 결정?다. 이를 개념적으로 표현? 질의는 다음과 같다. SELECT * FROM ( SELECT i1, i2 FROM T1 WHERE i2 > 20 AND i1 =1 ) V1; 즉, 위와 같은 질의 변형을 통? T1.i1 칼럼의 ?덱스를 ?용? 수 있도록 ?다. 그러나, Optimizer가 핫상 이런 종류의 push selection을 사용하도록 결정하지는 않는다. 사용자가 뷰 내부의 구조를 파악하고 있다면 적?? 조건?의 사용을 통? Optimizer가 뷰에 대? push selection기법을 선택하도록 ? 수 있다. 또?, 사용자는 힌트를 사용하여 optimizer가 명시적으로 뷰에 대? push selection기법을 선택하도록 ? 수 있다. 그러나, 뷰에 대? push selection을 사용하는 것이 원래 질의와 동등하거나 더 나은 성능을 반드시 보장하지는 않는다. 뷰에 대? push selection과 상충되는 최적화 기법이 바로 view materialization 기법이다. 이는 뷰가 하나의 질의에서 반복?서 272 Administrators Manual 사용될 때 질의 처리 과정 중에 뷰의 결과를 임시로 저장하여 처리하는 기법이다. 예를 들어 다음과 같은 뷰의 정의와 관? 질의를 살펴 보자 CREATE VIEW V1(a1, a2) AS SELECT i1, SUM(i2) FROM T1 GROUP BY i1; SELECT * FROM V1 WHERE V1.a2 > (SELECT AVG(a2) FROM V1 WHERE a1 > 10 ); 위와 같은 질의에 대하여 view materialization 기법이 사용되면, V1뷰의 결과는 임시로 저장되고 최상위 질의와 subquery는 이를 사용하게 된다. 즉, V1의 결과를 얻기 위하여 뷰를 정의? 질의를 반복하여 수행하지 않아도 되는 효과를 얻게 된다. 이러? 질의에 대하여 뷰에 대? push selection 기법을 사용하도록 힌트를 주면 오히려 느린 성능을 얻을 수도 있으므로 올바른 판단이 필요하다. Outer Join에 대한 Push Selection FROM ?에 outer join이 사용된 경우 다양? 형태의 push selection 이 가능하다. 이들 기법의 공통된 점은 WHERE ?에 기술된 조건을 outer join 의 조? 처리 이?에 수행되게 ?다는 것이다. 예를 들어 다음과 같은 질의를 살펴 보자 SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 WHERE T1.i1 = 1; 위 질의에 push selection 기법이 적용될 경우 개념적으로 다음과 같은 질의 형태로 처리된다. SELECT * FROM (SELECT * FROM T1 WHERE T1.i1 = 1) T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1; 즉, left outer join에 대? 조? 조건을 처리하기 ?에 T1.i1 = 1 조건을 먼저 처리하여 T1의 결과 집합을 ??다. 이러? 기법 역시 수학적 동치 여부 및 비용 평가를 통? 적용 여부가 결정된다. 예를 들어 다음의 세 질의는 경우에 따라 서로 다른 결과를 생성하며, 동?? 질의가 아니다. SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 WHERE T2.a1 = 1; SELECT * FROM T1 LEFT OUTER JOIN (SELECT * FROM T2 WHERE T2.a1 = 1) T2 ON T1.i1 = T2.a1; SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 AND T2.a1 = 1; Optimizer는 수학적 동치? 상태에서 동?? 결과를 얻기 위?서 위의 질의를 다음과 같은 형태로 push selection을 적용?다. SELECT * FROM T1 LEFT OUTER JOIN (SELECT * FROM T2 WHERE T2.a1 = 1) T2 SQL 튜닝 273 ON T1.i1 = T2.a1 WHERE T2.a1 = 1; Left outer join의 경우 WHERE 조건을 ON ?에 옮겨 처리하고 싶다면 다음과 같이 WHERE ?에 반드시 남겨 두어야 동?? 결과를 보장받을 수 있다. SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 AND T2.a1 = 1 WHERE T2.a1 = 1; 위의 최적화 기법을 보면, optimizer가 outer join에 대하여 push selection을 적용하지 않더라도 사용자는 임의로 질의 조건의 추가를 통? 유사? 효과를 기대? 수 있다. 물?, 조건 추가를 통? 동?? 결과를 얻음과 동시에 성능을 향상시킬 수 있는지 여부를 판단하는 것이 매우 중요하다. 조인에 대한 Push Selection 조?에 대? push selection 기법은 조? 조건과 단? 테이블 조건이 ?재? 때 유사? 다른 단? 테이블 조건을 추가하여 성능을 향상시키는 기법이다. 예를 들어 다음과 같은 질의를 살펴보자 SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND T1.i1 = 1; ?당 질의를 처리하기 위? 어떠? ?덱스도 사용? 수 없을 경우 다음과 같이 유사? 단? 테이블 조건을 추가하는 것은 ?은 경우에 성능 향상에 도움이 된다. SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND T1.i1 = 1 AND T2.a1 = 1; 즉, T2 의 결과 집합의 크기를 ?임으로서 성능을 향상시킬 수 있다. 이러? 조?에 대? push selection 기법은 특히 집합 연산을 통? 생성된 뷰에 대하여 처리? 때 매우 효과적이다. 예를 들어 다음과 같은 뷰와 이를 이용? 질의를 살펴 보자. CREATE VIEW V1(a1, a2) AS ( SELECT m1, m2 FROM T2 UNION ALL SELECT x1, y1 FROM T3 ); SELECT * FROM T1, V1 WHERE T1.i1 = V1.a1 AND T1.i1 = 1; 위의 뷰 정의에서 T2.m1 과 T3.x1 칼럼에 모두 ?덱스가 있다고 ?도 ?당 질의를 수행? 때 어떤 ?덱스도 사용되지 않는다. 이 때 조?에 대? push selection 기법을 적용하여 질의를 변경? 경우 다음과 같은 효과를 얻을 수 있다. SELECT * FROM T1, V1 WHERE T1.i1 = V1.a1 AND T1.i1 = 1 AND V1.a1 = 1; 위와 같이 기술된 질의는 뷰에 대? push selection과 집합에 대? push selection 기법이 적용되어 다음과 같이 T2.m1 과 T3.x1 칼럼의 ?덱스를 모두 사용? 수 있게 된다. 274 Administrators Manual SELECT * FROM T1, ( SELECT m1, m2 FROM T2 WHERE T2.m1 = 1 UNION ALL SELECT x1, y1 FROM T3 WHERE T3.x1 = 1 ) V1 WHERE T1.i1 = V1.a1 AND T1.i1 = 1; 위와 같이 조건?의 적?? 기술은 optmizer가 보다 효율적? 실행 계획을 작성하는 데 도움을 주며, 사용자의 명시적? 조건?의 변경을 통? 성능 향상을 꾀? 수 있다. 이러? 조건?의 추가가 반드시 좋은 성능을 보장하지는 못하며, 경우에 따라 잘못된 조건?의 추가는 비교 연산 비용? 증가시킬 수 있음을 유념하여야 ?다. 액세스 방법의 결정 SQL 튜닝 시 가장 우선적으로 고려?야 하는 부분이 테이블에 대? 접? 시 ?덱스를 사용하는 지의 여부를 판단하는 것이다. 대부분의 질의 처리 성능의 ?제는 ?덱스의 사용 여부에 따라 결정되며 이에 대? 판단이 SQL 튜닝에 있어 가장 중요하다고 ? 수 있다. 조건?의 처리 유형 Optimizer 는 정규화와 조건?의 분류 과정을 통? 구분된 조건들을 기?으로 ?당 테이블의 액세스 방법 및 조건의 처리 방법을 결정하게 된다. 조건?을 처리 순서 및 처리 방법에 따라 분류하면 다음과 같다. 처리 방법 처리 순서 설명 예제 Key Range 2 ?덱스를 사용하여 범위 검색이 가능? 조건 T1.i1 > 1 Key Filter 3 범위 검색은 ?되나 ?덱스의 키 값을 비교하여 검사가 가능? 조건 T1.i2 = 1 Constant Filter 1 테이블의 데이터에 관계 없이 ? 번의 검사?으로 판단이 가능? 조건 ? = 1 Filter 4 데이터에 대? 직접적? 비교가 필요? 조건 T1.i4 = abc Subquery filter 5 Subquery를 포함하고 있는 조건 EXISTS () 예제 Index on T1(i1, i2, i3) 질의: SELECT * FROM T1 WHERE ? = 1 AND i1 > 1 AND i2 = 2 AND i4 = abc AND EXISTS ( SELECT * FROM T2 WHERE T2.a1 = T1.i3 ); [표 11-3] 조건?의 처리 SQL 튜닝 275 위의 표에서 보는 바와 같이 모? 조건들은 다섯 가지 처리 방법 중 하나에 의? 처리된다. Key range 처리 방법은 ?덱스를 이용하여 조건에 부합하는 범위내의 데이터를 검색하는 방법이다. 즉, 조건을 ?족하는 최소값의 위치와 최대값의 위치?을 결정하고 ?당 조건에 대? 별도의 비교 없이 그 범위 내의 모? 데이터를 검사하게 된다. 따라서, 이 방법은 조건 비교 시 데이터에 대? 별도의 비교 연산이 필요 없어 매우 우수? 성능을 보장?다. Key filter 처리 방법은 ?덱스를 이용하여 범위 검색은 ? 수 없으나, ?덱스에 저장되어 있는 키값을 이용하여 비교 연산을 수행하는 방법이다. 즉, 이 방법은 ?덱스를 저장하고 있는 페이지?을 접?하여 비교함으로서 데이터 페이지에 대? 접? 횟수를 ?여 성능을 향상시킬 수 있다. 이는 디스크 테이블의 ?덱스에 대?서? 사용 가능하며, 메모리 테이블의 ?덱스의 경우 별도로 키값을 저장하지 않고 있어 filter 처리 방법과 비교하여 성능 향상의 효과가 없다. Constant 처리 방법은 앞에서 살펴보았듯이 조건?을 다른 모? 조건에 우선하여 ? 번? 처리하며, 논리값이 FALSE? 경우 별도의 데이터 검색이 필요 없다. Filter 처리 방법은 ?덱스를 사용? 수 없는 ?반적? 조건에 대? 비교 방법으로 데이터를 직접 인어 비교 연산을 수행?다. 다수의 filter가 있는 경우, Optimizer는 각 filter에 대하여 예상되는 처리 비용을 비교하여 가장 비용이 적은 filter를 우선적으로 처리하여 비교 비용을 최소화? 수 있도록 filter의 처리 순서를 결정?다. subquery filter는 ?반적으로 가장 ?은 비용이 드는 비교 연산이다. 따라서 이는 모? 조건 비교가 완료된 후 ?지링으로 수행된다. Optimizer는 이러? subquery filter에 대하여 다양? 최적화 기법을 적용하여 성능 향상을 꾀?다. 이에 대?서는 이후의 subquery 처리 과정에서 자세히 다룬다. 인덱스 생성 시 고려 사항 주어? 조건?을 처리하는데 가장 효율적? key range 검색을 하기 위?서는 ?덱스가 있어야 ?다. 그러나, ?덱스를 생성하기 위?서는 다음과 같은 사핫을 반드시 고려하여야 ?다. ?덱스의 생성이 검색 연산의 성능을 향상시킬 수는 있으나, ?덱스를 관리하기 위? 저장 공?이 필요하여 시스템 자원을 추가로 소모? 수 있다. 또?, 과도? ?덱스의 생성은 삽입, 삭제, 276 Administrators Manual 또는 갱? 발생시 관? ?덱스의 정보를 유지하기 위? 비용으로 ?? 성능 저하를 유발? 수도 있다. 메모리 테이블의 경우 거의 모? 질의 처리에 있어 ?덱스를 이용? 검색 방법(index scan이라 함)이 테이블에 대? ?체 스캔(full table scan이라 함)보다 우수? 성능을 보?다. 그러나, 디스크 테이블의 경우 ?덱스 스캔(index scan)이 ?체 테이블 스캔(full table scan)보다 반드시 효과적? 것은 아니다. 이는 ?체 테이블 스캔이 데이터 페이지를 접?하는 패턴이 ?정? 반면, ?덱스 스캔은 그 패턴이 ?정하지 않아 경우에 따라 과도? Disk I/O를 유발? 수 있기 때?이다. ?반적으로 디스크 테이블의 경우 ?덱스 스캔을 이용? 검색이 테이블의 ?체 레코드 중 1/10 이하 또는 아주 작은 수의 레코드?을 선택하는 경우에 ?? ?덱스를 생성? 것을 권고하고 있다. 그러므로, ?덱스 생성 여부 결정시 질의의 수행 빈도수, ?덱스 사용으로 ?? 성능 향상 효과, ?체 시스템 자원, 및 갱? 질의 (INSERT, DELETE, UPDATE)의 성능 저하 정도를 고려하여야 ?다. Optimizer의 인덱스 선택 Optimizer는 주어? 조건과 ?당 테이블의 ?덱스를 이용하여 가장 효율적? 액세스 방법을 결정?다. 이 과정에서 Optimizer는 다양? 통계 정보를 이용하여 각 ?덱스의 사용에 따른 비용을 평가하며, 이 중 가장 효율적? 액세스 방법을 선택?다. 액세스 방법이 결정되면 Optimizer는 각 조건들에 대하여 처리 방법 (key range 처리, filter 처리 등)을 결정?다. Optimizer가 각 액세스 방법의 비용을 계산하기 위? 사용하는 개념적? 공식은 다음과 같다. Access cost + Disk I/O cost Full scan : T(R) Index Scan : log(T(R)) + T(R) * MAX(1/V(Index), selectivity) 개념적인 Access cost 산 Full scan : B(R) Index Scan : Buffer Miss : [T(R) / V(R.a)] * ( 1- M/B(R) ) No Buffer Miss : B(R) * ( 1 - (log V(R.a)/logT(R)) ) 개념적인 Disk I/O cost 산 SQL 튜닝 277 Optimizer는 접? 비용(access cost)과 디스크 I/O 비용(disk I/O cost)을 모두 통합하여 계산?다. 메모리 테이블의 경우 디스크 페이지가 ?재하지 않아 디스크 I/O 비용은 수식에 의하여 자동으로 계산되지 않는다. Optimizer는 각 ?덱스에 대? 비용 계산 시 ?덱스를 이용하여 처리? 수 있는 조건을 선택하고 이를 기반으로 비용을 계산?다. 이 때, 비용에 가장 큰 영향을 미치는 것이 ?덱스에 관?된 조건의 효율성이다. 이를 조건의 selectivity라 ?다. 조건의 selectivity는 ?체 레코드 중 조건에 의? 선택되는 레코드들의 비율을 의미?다. 즉, 조건의 selectivity가 낮을수록 결과 레코드의 수가 ?어 들어 성능을 향상시킬 수 있다. 예를 들어 다음과 같은 조건을 살펴 보자. WHERE i1 = 1 AND i2 = 1 위의 조건에서 i1과 i2 칼럼에 각각 ?덱스가 ?재?다면 어떠? ?덱스를 선택? 것?가를 결정? 때 가장 중요? 요소는 ?당 조건의 selectivity이다. 예를 들어, i1 컬럼에 서로 다른 값의 종류가 100 [V(i1) = 100] 개가 있고, i2 칼럼에는 서로 다른 값의 종류가 1000 [V(i2) = 1000] 이라면 각 조건의 selectivity는 다음과 같이 계산된다. (i1 = 1)의 selectivity = 1/V(i1) = 1/100 (i2 = 1)의 selectivity = 1/V(i2) = 1/1000 즉, ?당 질의를 처리하기 위? i2 칼럼의 ?덱스를 사용하는 것이 보다 효율적? 액세스 방법이다. 위와 같은 개념의 액세스 선택 방법이 보편적으로 올바른 실행 계획을 작성?다. 그러나 이 역시 비용 계산에 의? 선택이기 때?에 모? 상황에 있어 핫상 좋은 액세스 방법이 선택되지는 않는다. 예를 들어, 다음과 같은 질의를 살펴 보자. SELECT * FROM soldier WHERE gender = 'female' AND rank = 'lieutenant'; 위의 질의에서 gender와 rank 칼럼에 모두 ?덱스가 있다고 ? 때, optimizer는 비용 계산을 통? rank 칼럼에 대? 조건을 처리하기 위? ?덱스를 사용하는 것이 바람직하다고 판단? 것이다. 그러나, (gender = 'female') 의 조건을 ?족하는 결과 집합이 아주 작다는 것을 사용자가 알고 있다면 힌트등을 통? ?덱스 선택을 달리하는 것이 바람직하다. 278 Administrators Manual Composite 인덱스의 ?용 Optimizer는 composite ?덱스를 사용? 때 조건?을 비교하여 최대? ?은 조건을 key range 검색? 수 있도록 선택?다. 이 때 key range 검색으로 처리될 수 있는 조건이 ?을수록 보다 나은 성능을 기대? 수 있다. 정의된 ?덱스를 참조하는 조건?을 사용자가 어떻게 기술하는 가에 따라 ?덱스를 이용? 성능은 매우 차이가 나므로, composite ?덱스의 동작 원리를 이?하는 것은 SQL 튜닝에 매우 큰 도움이 된다. 예를 들어, 다음과 같은 composite ?덱스가 ?재? 때 다양? 조건들이 어떻게 처리되는 지를 살펴보자. Composite index on T1(i1, i2, i3, i4) WHERE i1 = 1 AND i2 = 1 AND i3 = 1 AND i4 = 1 위의 WHERE?에 포함되어 있는 모? 조건은 composite ?덱스를 이용하여 모두 key range 처리가 가능하다. WHERE i1 = 1 AND i2 > 0 AND i3 = 1 AND i4 = 1 Key Range : i1 = 1, i2 > 0 Filter(or Key filter) : i3 = 1, i4 = 1 위의 예에서 key range 처리로 검색? 수 있는 조건은 두 개로 결정되고 나머지는 filter 로 처리가 된다. 이는 key range 처리는 최소값과 최대값을 결정? 수 있는 영역 내에서? 가능하기 때?에 부등호 연산 이후의 조건?은 key range 처리를 ? 수 없다. WHERE i1 = 1 AND i3 = 1 AND i4 = 1 Key Range : i1 = 1 Filter : i3 = 1, i4 = 1 위의 예에서는 모두 등호 연산을 사용하고 있지?, key range 처리가 가능? 조건은 하나뿐이다. 이는 composite ?덱스를 구성하고 있는 칼럼들의 순서에 모두 부합하는 조건이 있을 경우에? key range처리가 가능하기 때?이다. 즉, i2 칼럼에 대? 조건이 없어 i3, i4 에 대? 조건은 key range처리를 ? 수 없다. 위와 같이 composite ?덱스의 경우에는 조건들이 칼럼의 누락 없이 키 칼럼의 순서에 부합? 때와 ?당 조건이 등호 연산으로 이루어져 있을 때 key range 처리를 사용하여 평가될 수 있다. 예를 들어 다음과 같은 질의가 빈번하게 사용되어 ?덱스를 추가하려고 ?다면 ?덱스를 최대? ?용? 수 있도록 생성하는 것이 바람직하다. WHERE i1 > 0 AND i2 = 1 바람직? ?덱스: Index on T1(i2, i1) SQL 튜닝 279 i2 와 i1 칼럼을 참조하는 조건들을 평가하기 위? filer 없이 key range 처리가 사용될 수 있다. 부적?? ?덱스: Index on T1(i1, i2) i1 칼럼을 참조하는 조건을 평가하는데는 key range 처리가 사용될 수 있으나, i2 칼럼을 참조하는 조건을 평가하기 위?서는 filter 처리가 사용된다. 그러므로 이 ?덱스가 더 비효율적이다. 인덱스와 비교 연산자 ?덱스가 ?재하고 ?당 칼럼에 대? 조건이 ?재?다고 ?서 반드시 ?덱스를 사용될 수 있는 것은 아니다. 즉, 조건?의 기술 형태와 비교 연산자의 종류에 따라 ?덱스의 사용 가능 여부가 결정되므로 이에 대? 주의가 필요하다. 비교 연산자의 종류와 ?덱스 사용 가능 여부는 다음과 같다. 종류 비교 연산자 ?덱스 사용 가능 여부 비고 단순 비교 = O != O O >= O 범위 비교 BETWEEN O NOT BETWEEN O 멤버 비교 IN O NOT IN O 패턴 비교 LIKE O 가능: T1.i1 LIKE abc% 불가: T1.i1 LIKE %abc NOT LIKE X NULL 비교 IS NULL O IS NOT NUL O ?재 비교 EXISTS X NOT EXISTS X UNIQUE X NOT UNIQUE X 280 Administrators Manual Quantify ANY =ANY O !=ANY O ANY O >=ANY O Quantify ALL =ALL O != ALL O ALL O >= ALL O [표 11-4] 비교 연산자에 따른 ?덱스 사용 여부 Geometry 데이터 타입 관? 비교 연산자는 다음과 같다. R-Tree ?덱스가 ?재하는 경우에? geometry 데이터 타입 칼럼에 정의된 ?덱스를 사용? 수 있다. 종류 비교 연산자 ?덱스 사용 가능 여부 비고 Geometry 비교 CONTAINS O R-Tree index only CROSSES O DISJOINT O DISTANCE O EQUALS O INTERSECTS O ISEMPTY X ISSIMPLE X NOT CONTAINS X NOT CROSSES X NOT EQUALS X NOT OVERLAPS X NOT RELATE X NOT TOUCHES X NOT WITHIN X OVERLAPS O RELATE X TOUCHES O WITHIN O [표 11-5] Geometry 비교 연산자 사용 여부 SQL 튜닝 281 위와 같이 ?덱스가 ?재하고 ?덱스를 사용? 수 있는 비교 연산자라 하더라도 핫상 ?덱스가 사용될 수 있는 것은 아니다. 즉, 조건?의 형태에 따라 ?덱스의 사용 가능 여부가 결정된다. ?덱스가 사용될 수 있는 조건?의 형태는 다음과 같다. (단, 조건?의 예제에서 ?당 칼럼이 INTEGER 타입임을 가정?다.) 조건?의 형태 가능? 예 불가능? 예 ?덱스 사용이 가능? 비교 연산자 여야 ?다. T1.i1 = 1 T1.i1 NOT LIKE a 칼럼이 있어야?다. T1.i1 = 1 1 = 3 칼럼에 대? 연산이 없어야?다. T1.i1 = 1 + 1 T1.i1 + 1 = 3 연산자의 ?쪽에? 칼럼이 있어야? 다. (T1.i1, T1.i2) = (1, 1) T1.i1 = T2.i1 (T1.i1, 1) = (1, T1.i2) T1.i1 = T1.i2 칼럼의 타입(값)이 변경되지 않아야 ?다. T1.i1 = SMALLINT'1' T1.i1 = 1.0 [표 11-6] 조건?에 따른 ?덱스 사용 여부 위와 같이 ?덱스를 사용하기 위?서는 조건?의 기술에 주의를 기?여야 ?다. 특히 칼럼의 값에 대? 연산이나 타입 변?이 발생하지 않도록 주의하여야 ?다. ?덱스 사용을 고려? 데이터 타입과 데이터 변?에 대? 설명은 다음 ?(?덱스와 데이터 타입)에서 자세히 설명?다. 인덱스와 데이터 타입 WHERE ?에서 참조하는 칼럼에 ?덱스가 생성되어 있다고 ?서 핫상 ?덱스 스캔이 가능? 것은 아니다. 데이터 타입과 데이터 변?에 따라 ?덱스 스캔이 가능? 경우도 있고 그렇지 않은 경우도 있다. SELECT * FROM T1 WHERE T1.i1 = ? 위의 질의에서 i1 칼럼이 VARCHAR 타입이고 PRIMARY KEY? 경우, iSQL로 이 쿼리의 실행 계획을 확?하면 ?덱스 스캔 가능으로 나타난다. 하지? 실제 변수를 바?딩? 때 INTEGER 등의 숫자형으로 바?딩을 하는 경우 칼럼 값을 숫자형으로 변?하여 비교?야 하므로 ?덱스 스캔이 불가능하다. 따라서, iSQL에서 ?덱스 스캔으로 수행되는 질의?지 확?하고, 실행 계획이 ?덱스 스캔이 가능? 것으로 표시되는 경우에도 실제 응용 프로그램에서 바?딩하는 값과 칼럼의 데이터 타입을 확??야 ?다. 그렇지 않으면 응용 프로그램에서는 ?체 테이블을 스캔(full table scan)하여 iSQL상에서의 실행 속도에 비? 현격? 속도 282 Administrators Manual 차이가 날 수도 있다. 데이터 타입과 ?덱스 사용 가능 여부는 다음과 같다. 검은 부분으로 표시되는 부분은 비교연산 수행시, 키 칼럼에 타입 변?이 발생하게 된다. VALUE KEY CHAR VARCHAR SMALLINT INTEGER BIGINT NUMERIC FLOAT REAL DOUBLE DATE BLOB NIBBLE BYTE GEOMETRY CHAR O O X X X X X X X X - - - - VARCHAR O O X X X X X X X X - - - - SMALLINT X X O O O O O O O - - - - - INTEGER X X O O O O O O O - - - - - BIGINT X X O O O O O O O - - - - - NUMERIC O O O O O O O O O - - - - - FLOAT O O O O O O O O O - - - - - REAL X X O O O O O O O - - - - - DOUBLE O O O O O O O O O - - - - - DATE O O - - - - - - - O - - - - BLOB - - - - - - - - - - O - - - NIBBLE - - - - - - - - - - - O - - BYTE - - - - - - - - - - - - O - GEOMETRY - - - - - - - - - - - - - O [표 11-7] 데이터 타입에 따른 ?덱스 사용 여부 데이터 타입은 다음과 같이 크게 ?자형 계열과 숫자형 계열로 구분? 수 있으며, 각 계열에 속하는 데이터 타입들?의 비교는 모두 ?덱스를 사용? 수 있다. ?자형 계열 CHAR, VARCHAR 숫자형 계열 Native 정수형 BIGINT, INTEGER, SMALLINT 실수형 DOUBLE, REAL Non-Native (지수형) 고정 소수점형 NUMERIC, DECIMAL, NUMBER(p), NUMBER(p,s) 부동 소수점형 FLOAT, NUMBER 즉, ?자형 계열에 속하는 CHAR, VARCHAR?의 비교 또는 숫자형 계열에 속하는 정수형, 실수형, 지수형?의 비교시에는 모두 ?덱스 SQL 튜닝 283 사용이 가능하다. ?자형 계열 char_column = VARCHARabc varchar_column = CHARabc 숫자형 계열 integer_column = DOUBLE1 number_column = DOUBLE1 integer_column = NUMBER1 숫자형 계열의 서로 다른 데이터 타입? 비교 연산에 대?서는 다음의 변?표를 기?으로 변?하고 비교?다. 정수형 실수형 지수형 정수형 정수형 실수형 지수형 실수형 실수형 실수형 실수형 지수형 지수형 실수형 지수형 ?덱스 칼럼에 변?이 발생하는 경우가 이에 ?당되는데, ?덱스 칼럼의 값에 변?이 발생?다 ?지라도, 이 비교 기?에 의? 내부적으로 ?덱스 칼럼의 변?된 값으로 비교연산을 수행하게 된다. 그러므로, bigint_col = NUMERIC1과 같이 칼럼에 변?이 발생하는 index scan은 bigint_col = BIGINT1과 같이 칼럼에 변?이 발생하지 않는 index scan보다 수행속도가 느리게 된다. 이 외에 ?덱스 스캔과 별도로 두 값을 비교하는 비교 연산자의 수행 성능은 비교 대상 데이터의 타입과 밀접? 관계가 있다. 같은 데이터 타입?의 비교? 경우에는 데이터 변? 비용이 없으므로 최적의 성능을 발휘하겠지? 서로 다른 데이터 타입?의 비교라면 데이터 변?이 최소화되도록 ?야 ?다. 예를 들어 숫자형 타입과 ?자형 타입을 비교? 경우 데이터 변? 비용? 고려?다면 FLOAT과 VARCHAR? 경우 가장 짧은 변? 경로를 가?다. 그러나 데이터 타입별로 데이터 저장 크기와 형식에 차이가 있으므로 이를 종합적으로 고려? 데이터 타입을 결정?야 ?다. 다음은 데이터 타입 변? 경로를 도식화? 그림이다. 284 Administrators Manual SMALLINT BIGINT INTEGER REAL DOUBLE NUMERICFLOAT INTERVAL CHARVARCHAR DATE NULLALL <0+0+0> <0+E+L> <0+E+0> <0+0+0> <0+E+0> <0+0+L> <0+E+0><0+0+L> <0+E+L> <0+E+0> <0+0+0> <0+0+0> <0+E+L> <0+0+0> <0+0+0> <0+0+0> <0+0+L> <0+0+L> ABA와 C를 비교하는 경우 항상 A가 C로 변환되거나 C가 A로 변환되는 것은 아니다. 연산자에 따라 A가 C로 변할 수도 있고, 그 반대인 경우도 있으며, A가 B로 변환되고 C가 B로 변환되어 연산을 수행하는 경우도 있다. C ABA 타입에서 B 타입으로 이 타입 변환 가 G : Group Penalty E : Error Penalty G >> E >> L L : Loss Penalty [그림 11-3] 데이터 변? 타입 경로 위와 같이 ?덱스가 사용될 수 있도록 조건?을 기술하는 것은 매우 중요하다. 조건?의 유형에 따라 성능에 영향을 미칠 수 있으므로 WHERE?의 기술 및 응용 프로그램의 작성 시 주의를 기?여야 ?다. Optimizer가 개별 테이블에 대? 액세스 방법의 결정이 완료되면, 조?에 대? 처리를 수행하게 된다. 이 때, 개별 테이블에 대하여 결정된 액세스 방법은 ?대적? 것이 아니며, 조? 처리 과정에서 재조정될 수도 있다. 조인 순서의 결정 SQL 튜닝 285 복잡? 질의의 경우 조?의 순서 및 조?의 처리 방법은 질의 성능에 가장 큰 영향을 미치게 된다. 따라서, 적?? 조? 순서와 조? 방법이 선택되었는지를 판단하고 조정하는 것은 질의 성능 향상에 큰 도움이 된다. Optimizer는 조?을 처리하기 위하여 다음과 같은 단계를 따른다. 1. 조? 조건을 이용? 조?의 그룹화 2. 각 그룹의 조? 관계 표현 3. 각 그룹의 조? 순서 결정 4. 각 조?의 조? 방법 결정 5. 그룹?의 조? 순서 및 조? 방법 결정 이와 같이 optimizer가 각 단계를 수행하는 과정을 이?하는 것은 SQL 튜닝에 도움이 된다. 이 ?에서는 optimizer가 조? 순서를 결정하는 과정에 대하여 알아본다. 조? 순서는 조? selectivity를 이용? Join greedy algorithm를 기반으로 결정된다. 조인 그룹의 분류 조? 관계가 없는 테이블들을 모두 고려하여 조? 순서를 결정하는 것은 ?반적으로 부하?을 증가시킬 뿐 올바른 조? 순서를 결정하는데 큰 도움이 되지 않는다. 즉, 조? 관계가 있는 테이블끼리 하나의 그룹으로 묶어 처리하고 이후 각 그룹에 대? 조? 순서를 결정하는 것이 효율적이다. 예를 들어, 다음과 같은 질의를 살펴보자. SELECT * FROM T1, T2, T3, T4, T5 WHERE T1.i1 = T2.a1 AND T2.a2 = T3.m1 AND T4.x1 = T5.z1; 조? 그룹의 분류: (T1, T2, T3), (T4, T5) 위의 예와 같이 두 그룹은 조? 관계가 ?혀 없는 테이블이다. 그러므로, 조? 순서를 결정하기 위하여 모? 테이블을 ?꺼번에 고려하여 처리하는 것은 비용을 증가시킬 뿐이다. ?반적? 경우 이러? 분류 방법이 효율적이나 응용 프로그램의 성격 및 데이터 구성에 따라 적합하지 않을 수 있다. 이런 경우 힌트를 통하여 조? 순서를 제어? 수 있다. 이와 같이 조? 그룹을 분류? 후 각 조? 그룹에 대하여 다음과 같은 과정을 통하여 조? 순서를 결정하게 된다. 286 Administrators Manual 조인 관계의 구성 각 조? 그룹에 대하여 조? 관계를 구성하는 것은 조? 순서 결정 시 직접적? 조? 관계가 없는 테이블?의 비교 비용을 ?여 보다 효율적? 조? 순서를 결정하기 위함이다. 예를 들어 다음과 같은 질의를 살펴 보자 SELECT * FROM T1, T2, T3, T4 WHERE T1.i1 = T2.a1 AND T2.a2 = T3.m2 AND T3.m3 = T4.x3; 위의 질의에서 조? 관계는 다음과 같이 표현될 수 있다. T1T2T3T4 조인 관 T1.i1 = T2.a1T2.a2 = T3.m2T3.m3 = T4.x3 위와 같이 조? 관계를 관리하며, 조? 순서 결정 시 조? 관계?을 고려하여 비용 평가를 함으로서 (T1, T4)와 같이 직접적? 조? 관계가 없는 테이블?의 조?이 우선적으로 결정되는 것을 방지?다. 조? 관계를 고려하는 것이 ?반적으로 효율적? 조? 순서를 결정하는 데 도움이 되나, 반드시 올바른 조? 순서를 결정하지는 않는다. 따라서, 필요? 경우 힌트를 사용하여 조? 순서를 제어? 수 있다. 조인 관계의 순서 결정 위에서 생성? 조? 관계를 이용하여 각 조? 관계들 중 가장 효율적? 조? 관계 순서를 결정하게 된다. 조? 관계의 순서를 결정하는 방법은 조? 관계들 중 조? 선택도(selectivity)가 가장 효율적? 조? 관계를 우선 선택?다. 그리고 다시 선택된 관계로부터 관?된 조? 관계들 중에 효율적? 조? 관계를 선택? 가는 방식으로 결정된다. 이 때, 조? 관계의 순서라 함은 실제 조? 순서가 아니다. 실제 조? 순서는 조? 방법의 결정을 통? 완성된다. SQL 튜닝 287 T1 JOIN T2 T3 JOIN JOIN T4 조인 관 의 순서 T1 JOIN T2 T3 JOIN JOIN T4 조인 방법 결정 후의 실제 조인 순서 [그림 11-4] 조? 관계의 순서 결정 위의 그림에서 보듯이 이 과정에서의 조? 관계의 순서는 조? 관계의 깊이?을 결정? 뿐이다. 실제 조? 순서는 조? 방법 선택에 의하여 결정된다. 조? 관계 순서의 가장 중요? 요소는 조?의 선택도 (selectivity)이며, 두 테이블의 조합을 통? 생성되는 결과 집합의 원래 테이블 크기에 대? 비율을 의미?다. 즉, 조? 관계의 순서 결정시 조?을 통? 결과 집합의 크기의 대소를 비교하기 보다 결과 집합의 크기가 원래 테이블의 레코드 개수에 비?서 얼?나 ?이 ?어드는가를 기?으로 판단하게 된다. Optimizer는 조? selecitivty 를 아래처럼 계산?다. 이 공식의 자세? 설명은 이 ?서의 범위를 ?어난다. [T(R) * T(S) / MAX[V(R.a), V(S.a)]/ [T(R) + T(S)] 개념적인 Join selectivity 산 이와 같은 join selecitivty 를 이용? 조? 관계 순서의 결정은 보다 효율적? 비율로 결과 집합을 ?? 수 있는 조? 관계를 우선적으로 선택하게 되며, 추후 조? 방법 결정에 의하여 비교적 정확? 조? 순서가 결정된다. 예를 들어, 하나의 질의에 포함된 각 테이블의 레코드 개수와 조?으로 생성되는 결과의 개수가 다음과 같을 때를 살펴보자. T(R) = 10, T(S) = 10, T(R JOIN S) = 10 T(T) = 1000, T(U) = 1000, T(T JOIN U) = 100 위의 예에서 테이블 R과 S를 조?? 결과의 개수가 T와 U를 조?? 결과의 개수보다 적지?, 오히려 결과 집합을 아주 큰 비율로 ?? 수 있는 T와 U의 관계가 더 중요? 조? 관계가 된다. 288 Administrators Manual Optimizer가 조? 관계를 이용하여 생성? 조? 순서가 모? 경우에 있어 핫상 바람직함을 보장? 수는 없다. 이를 위? 조? 순서 힌트를 사용하여 조? 순서를 제어? 수 있다. 조? 관계의 순서를 결정? 후에는 두 테이블?의 조? 방법을 결정하게 되고 최종적으로 조? 순서가 결정된다. 조인 방법의 결정 조? 관계의 순서가 결정되면, 두 테이블의 각 조? 관계에 대하여 조? 방법을 결정하게 된다. 이 때, 각 조? 방법의 비용 비교를 통? 조?의 순서, 방향, 및 조? 방법을 결정하게 된다. 알티베이스가 지원하는 조? 방법은 다음과 같이 크게 네 가지 계열에 속?다. Nested loop 조? 계열 Sort-based 조? 계열 Hash-based 조? 계열 Merge 조? 계열 각 계열 별 조? 방법 및 실행 가능 여부는 다음과 같다. 조? 계열 조? 방법 조? 방향 Left=>Right Right=>Left Nested Loop Full nested loop C, I, L C, I, R Full store nested loop C, I, L, F C, I, R, F Index nested loop I, L I, R Anti outer nested loop F F Sort-based One pass sort join I, L, F I, R, F Multi pass sort join I, L, F I, R, F Hash-based One pass hash join I, L, F I, R, F Multi pass hash join I, L, F I, R, F Merge-based Index merge join I I Sort merge join I I 사용 가능? 조?의 종류 C (Cartesian Product): 조? 관계를 갖지 않는 두 테이블의 조합 I (Inner Join): 조? 관계를 갖는 두 테이블의 ?반적? 조? L (Left outer join): Left outer 조? 관계를 갖는 두 테이블의 조? R (Right outer join): Right outer 조? 관계를 갖는 두 테이블의 조? F (Full outer join): Full outer 조? 관계를 갖는 두 테이블의 조? [표 11-8] 조?방법에 따른 실행 가능 여부 SQL 튜닝 289 Optimizer는 위와 같은 다양? 조? 방법들 중 적용 가능? 조? 방법에 대? 비용 평가를 통? 가장 효과적? 조? 방법을 선택하고 조?의 방향을 결정?다. 조? 방법이 결정되면 기? 테이블 (outer table)은 왼쪽에 위치시키고 반복 테이블 (inner table)은 오른쪽에 위치시킨다. 실행 계획 트리의 분석을 통? 어떠? 조? 방법이 선택되었는 지를 판단 가능하며, 힌트를 사용하여 제어? 수 있다. 이 ?에서는 각 조? 계열의 조? 방법에 대? 내용을 살펴 본다. Nested Loop 조인 계열 nested loop 조? 계열에는 다음과 같은 조? 방법들이 있다. Full nested loop join Full store nested loop join Index nested loop join Anti outer nested loop join Full nested loop join방법은 ? 테이블의 모? 레코드를 다른 테이블의 모? 레코드와 조?하는 방법이다. 이 방법은 ?반적으로 조? 관계가 ?재하지 않는 두 테이블?의 조?시 사용될 가능성이 높다. SELECT * FROM T1, T2; Full store nested loop join 방법은 반복 테이블(inner table)의 결과를 저장? 후 full nested loop join을 적용하는 방법이다. 이 방법은 조? 조건 이외의 조건 처리에 의하여 결과 집합이 매우 ?어드는 경우 적용될 가능성이 높으며, ?반적으로 조? 그룹?의 Cartesian product (교차 조?)에 의하여 사용될 가능성이 높다. SELECT * FROM T1, T2 WHERE T1.i1 = 1 AND T2.i1 = 1; Index nested loop join 방법은 ?덱스를 이용하여 조? 조건을 처리하는 방법이다. 기? 테이블 (outer table)의 레코드 수가 적고 반복 테이블 (inner table)에 ?덱스가 ?재하는 경우에 사용될 가능성이 높다. Index on T2(i1) SELECT * FROM T1, T2 WHERE T1.i1 = T2.i1 AND T1.i1 = 1; Anti outer nested loop join 방법은 FULL OUTER JOIN에서? 사용되며, 기? 테이블 (outer table)과 반복 테이블 (inner table) 모두 조? 조건에 ?당하는 칼럼에 대하여 ?덱스가 정의되어 있을 때 사용 가능될 수 있다. 이 경우 다른 조? 방법에 비? 이 방법이 선택될 가능성이 높다. Index on T1(i1), Index on T2(i1) SELELCT * FROM T1 FULL OUTER JOIN T2 ON T1.i1 = T2.i1; 290 Administrators Manual 각 조? 방법들의 수행 비용은 개략적으로 Access cost + Disk I/O cost로 계산된다. 조? 방법 Access Cost Disk I/O cost No Buffer Miss Buffer Miss Full nested T(L) * T(R) B(L) + B(R) B(L) + T(L) * B(R) Full store nested T(L) * T(R) + S(R) B(L) + S(R) + B(R) B(L) + S(R) + T(L) * B(R) Index nested T(L) * [log(T(R)) + s * T(R)] B(L) + B(R) * [1 + (log s/log T(R))] B(L) + T(L) * s * [1 - M/B(R)] Anti outer T(L) * [log(T(R)) + s * T(R)] B(L) + B(R) * [1 + (log s/log T(R))] B(L) + T(L) * s * [1 - M/B(R)] 참조) L: 기? 테이블, R: 반복 테이블 T(): 레코드 개수, B(): 디스크 페이지 개수, S(): 저장 비용, M: 버퍼 페이지, s: 조? 조건의 selectivity [표 11-9] nested loop 조? 계열의 비용 계산법 Sort-based 조인 계열 sort-based 조? 계열에는 다음과 같은 조? 방법들이 있다. One-pass sort-based join Multi-pass sort-based join Sort-based 조? 방법은 반복 테이블(inner table)을 정?된 순서로 저장하고 조? 조건을 이용하여 범위 검색을 하는 방법이다. ?반적으로 이 방법은 ?덱스가 없고 부등호 조? 조건을 처리? 때 선택될 가능성이 높다. SELECT * FROM T1, T2 WHERE T1.i1 > T2.i1; One-pass sort-based 조? 방법은 반복 테이블(inner table)의 데이터 양이 적어 버퍼 내에서 관리가 가능? 때 사용된다. 이 방법은 메모리 테이블이 반복 테이블(inner table)로 사용될 경우 핫상 사용된다. Multi-pass sort-based 조? 방법은 반복 테이블(inner table)의 데이터 양이 방대하여 버퍼의 범위 내에서 관리? 수 없을 때 사용된다. 이 방법은 디스크 I/O를 ?이기 위? 사용된다. 이 방법은 기? 테이블(outer table)과 반복 테이블(inner table)을 모두 정?하여 저장?다. 기? 테이블(outer table)의 데이터 정? 순서로 조? 조건을 검사하게 되어 반복 테이블(inner table)의 동?? 디스크 페이지 접? 확률을 높이게 된다. 이 때?에 디스크 SQL 튜닝 291 I/O 비용이 ?어들게 된다. 각 조? 방법들의 수행 비용은 개략적으로 Access cost + Disk I/O cost로 계산된다. 조? 방법 Access Cost Disk I/O cost No Buffer Miss Buffer Miss One-pass sort S(R) + T(L) * [log(T(R)) + s * T(R)] B(L) + S(R) + B(R) B(L) + 3S(R) + T(L) * s * B(R) Multi-pass sort S(L) + S(R) + T(L) * [log(T(R)) + s * T(R)] S(L) + S(R) + B(L) + B(R) 3S(L) + 3S(R) + B(L) + B(R) 참조) L: 기? 테이블(outer table), R: 반복 테이블(inner table) T(): 레코드 개수, B(): 디스크 페이지 개수, S(): 정? 저장 비용, M: 버퍼 페이지, s: 조? 조건의 selectivity [표 11-10] Sort-based 조? 계열의 비용 계산법 Hash-based 조인 계열 hash-based 조? 계열에는 다음과 같은 조? 방법들이 있다. One-pass hash-based join Multi-pass hash-based join Hash-based 조? 방법은 반복 테이블(inner table)을 hash 구조로 저장하고 조? 조건을 이용하여 범위 검색을 하는 방법이다. 이 방법은 등호 연산자를 사용? 조? 조건?을 처리? 수 있으며 ?덱스가 없을 때 선택될 가능성이 높다. SELECT * FROM T1, T2 WHERE T1.i1 = T2.i1; One-pass hash-based 조? 방법은 반복 테이블(inner table)의 데이터 양이 적어 버퍼 내에서 관리가 가능? 때 사용되며, 메모리 테이블이 반복 테이블(inner table)로 사용될 경우는 핫상 이 방법이 사용된다. Multi-pass hash-based 조? 방법은 반복 테이블(inner table)의 데이터 양이 방대하여 버퍼의 범위 내에서 관리? 수 없을 때 사용되며 디스크 I/O를 ?이기 위? 방법이다. 기? 테이블 (outer table)과 반복 테이블(inner table)은 모두 동?? hash 함수를 사용하여 분?되어 여러 임시 테이블에 저장된다. 그러므로, 이 방법은 각 임시 테이블끼리 조? 조건을 검사하여 반복 테이블(inner table)의 동?? 디스크 페이지 접? 확률을 높이게 된다. 각 조? 방법들의 수행 비용은 개략적으로 Access cost + Disk I/O cost로 계산된다. 292 Administrators Manual 조? 방법 Access Cost Disk I/O cost No Buffer Miss Buffer Miss One-pass hash H(R) + T(L) * s * T(R) B(L) + H(R) + B(R) B(L) + 3H(R) + T(L) * s * B(R) Multi-pass hash H(L) + H(R) + T(L) * s * T(R) H(L) + H(R) + B(L) + B(R) 3H(L) +3H(R) + B(L) + T(L) * s * B(R) 참조) L: 기? 테이블(outer table), R: 반복 테이블(inner table) T(): 레코드 개수, B(): 디스크 페이지 개수, H(): ?싱 저장 비용, M: 버퍼 페이지, s: 조? 조건의 selectivity [표 11-11] Hash-based 조? 계열의 비용 계산법 Merge 조인 계열 Merge 조? 방법은 두 테이블의 데이터가 정?될 경우 매우 효율적? 방법이다. 이 방법에는 기? 테이블과 반복 테이블의 개념이 없으며 양쪽 테이블을 순차적으로 ?행하면서 조? 조건을 검사?다. 양쪽 테이블이 모두 조? 키를 기?으로 정?되어야 ?다. 그러나 각각의 테이블이 ?덱스를 통? 정?되어 있다면 테이블을 정?? 필요가 없어?다.. Index on T1(i1), Index on T2(a1) SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1; Merge 조? 방법의 수행 비용은 개략적으로 Access cost + Disk I/O cost로 계산된다. 테이블의 유형 Access Cost Disk I/O cost No Buffer Miss Buffer Miss Indexed Table T(L) B(L) B(L) Non-index Table S(L) + T(L) S(L) + B(L) 3S(L) + B(L) 참조) Merge 조? 비용은 두 테이블의 비용을 합산함. L: 테이블 T(): 레코드 개수, B(): 디스크 페이지 개수, S(): 정? 저장 비용 [표 11-12] Merge 조? 계열의 비용 계산법 지금까지 질의 성능에 가장 큰 영향을 미치는 FROM과 WHERE ?을 의미하는 critical path의 최적화 과정에 대하여 살펴보았다. 이후의 최적화 과정은 non-critical path에 대? 최적화 과정으로 각 구?의 형태에 따라 구분하여 설명?다. SQL 튜닝 293 그룹 연산의 최적화 critical path에 대? 최적화 과정후에 Optimizer는 non-critical path, 즉 GROUP BY, HAVING, 및 aggregation 연산 등의 그룹 연산에 대? 최적화를 수행?다. 그룹 연산의 최적화시 기본적으로 hashing과 sorting에 대? 비용 계산을 통? 실행 방법이 결정된다. 아래와 같은 최적화 기법들이 적용 가능? 경우 이를 적용?다. 정? 순서를 이용? GROUP BY 최적화 정? 순서를 이용? MIN/MAX 최적화 MIN 또는 MAX 연산내의 DISTINCT 제거 정? 순서를 이용? DISTINCT aggregation 정? 순서를 이용한 GROUP BY 최적화 GROUP BY에 기술된 칼럼별로 그룹을 구분하기 위? 기본적으로 hashing 또는 sorting을 필요로 ?다. 이러? 연산은 내부적으로 ?은 저장 공?과 높은 CPU 사용을 요구?다. Optimizer는 GROUP BY를 처리하기 위? ?덱스가 ?재하거나 critical path 최적화 과정에서 ?당 칼럼의 순서가 보장될 경우 이 방법을 사용? 수 있다. Optimizer는 다음의 경우에 hashing 및 sorting을 사용하는 것을 피?다. GROUP BY ?의 칼럼에 ?덱스가 있는 경우 이? 작업에서 GROUP BY ?의 칼럼을 기?으로 데이터가 이미 정?된 경우 예제로 ? 다음 쿼리에서, Optimizer는 별도의 hashing 또는 sorting이 수행될 필요성을 제거? 실행 계획 트리를 생성?다. 않도록 실행 계획을 생성?다. 모? 질의에 핫상 이러? 최적화가 가능? 것은 아니므로, 실행 계획 분석을 통하여 적용 가능 여부를 판단? 필요가 있다. Index on T1(i1) SELECT SUM(i2) FROM T1 GROUP BY i1; SELECT SUM(i2) FROM T1 WHERE i1 > 0 GROUP BY i1; 다음 예를 통? GROUP BY ?에서 참조된 ?덱스가 있는 칼럼을 최적화에 ?용하는 방법에 대하여 알아 보자. Index IDX1 on T1(i1, i2), Index IDX2 on T1(i1, i3) SELECT * FROM T1 WHERE i1 > 0 GROUP BY i1, i3; 위의 질의를 처리하기 위? optimizer는 critical path 처리 294 Administrators Manual 과정에서 IDX1 또는 IDX2 를 사용? 수 있다. IDX1을 사용?다면 GROUP BY?을 처리하기 위? hashing 및 sorting이 필요? 반면에, IDX2를 사용? 경우 별도의 저장이 필요없다. 사용자가 실행 계획 트리를 분석하여 IDX1을 사용하고 있음을 확?했다면, 힌트를 사용?서 IDX2를 강제적으로 사용하게 ? 수 있다. 유사? 개념으로 다음 질의 수행 시 ?당 테이블에 ?덱스가 없는 경우를 고려? 보자 SELECT * FROM T1 WHERE i3 > 0 GROUP BY i1, i3; 위의 경우 T1(i3, i1) 칼럼에 Composite ?덱스를 생성하면 질의 성능을 향상시킬 수 있다. GROUP BY i1, i3 와 GROUP BY i3, i1 구?은 결과 집합의 레코드 순서? 다를 뿐 결과 집합은 동?하기 때?에 GROUP BY ?의 칼럼 순서는 중요하지 않다. 사용자가 T1(i3, i1) 칼럼에 Composite ?덱스를 생성하면, i3>0, 범위 검색은 이 predicate을 검사하기 위?서 사용될 수 없다. 정? 순서를 이용한 MIN/MAX 최적화 GROUP BY ?이 없는 MIN 또는 MAX aggregation의 경우 ?덱스를 이용하여 최소값과 최대값을 쉽게 검색? 수 있다. 이러? 기법을 정? 순서를 이용? MIN, MAX 최적화 기법이라 ?다. 즉, 다음과 같은 질의의 경우 optimizer는 ?덱스를 사용하여 MIN 또는 MAX를 처리? 수 있도록 ?다. 즉, MIN의 경우 ?덱스를 가장 작은 값으로부터 검색하고, MAX의 경우 ?덱스를 가장 큰 값으로부터 검색?다. Index on T1(i1) SELECT MIN(i1) FROM T1; SELECT MAX(i1) FROM T1 WHERE i1 < 0; 최소값 또는 최대값을 얻는 질의가 빈번하게 사용된다면 ?당 칼럼에 ?덱스를 생성하는 것이 ?체 데이터를 비교하지 않아도 되기 때?에 성능 향상에 큰 도움이 된다. 그러나, 다음과 같이 MIN과 MAX를 함께 사용하는 경우는 ?덱스를 ? 쪽 방향으로? 검색? 수 없기 때?에 별도의 최적화가 불가능하다. SELECT MIN(i1), MAX(i1) FROM T1; 그러므로 다음과 같이 질의를 작성하는 것이 성능 향상에 도움이 된다. SELECT MIN(i1) FROM T1 UNION ALL SELECT MAX(i1) FROM T1; SQL 튜닝 295 MIN 또는 MAX연산 내의 DISTINCT 제거 다음의 두 질의는 수학적으로 완? 동치이다. 즉, DISTINCT 키워드는 무의미하다. SELECT MIN(DISTINCT i2) FROM T1 GROUP BY i1; SELECT MIN(i2) FROM T1 GROUP BY i1; 물? optimzer가 MIN 또는 MAX내에 DISTINCT가 ?재? 경우 이를 제거하지?, 사용자가 의미 없는 구?을 기술하지 않는 것이 바람직하다. 정? 순서를 이용한 DISTINCT aggregation SUM(DISTINCT i1) 과 같이 DISTINCT 칼럼을 ?자로 같는 aggregation 연산은 중복 제거를 위? 별도의 저장 및 hashing 작업이 필요하다. 그러나, GROUP BY? 없이 사용된 DISTINCT aggregation의 경우, ?덱스가 사용되거나 이?의 최적화 과정에서 ?당 칼럼이 적?히 정?되었다면, 중복 제거를 위? 별도의 저장 공?을 필요로 하지 않는다. SELECT SUM(DISTINCT i1) FROM T1; SELECT COUNT(DISTINCT i1) FROM T1 WHERE i1 > 0; 위와 같은 질의가 빈번히 사용될 경우 ?당 칼럼에 ?덱스를 생성하면 중복 제거를 위? 별도의 저장 공? 및 hashing 비용이 필요 없게 되어 성능 향상을 꾀? 수 있다. DISTINCT?의 최적화 DISTINCT ?은 기본적으로 hashing 또는 sorting으로 처리가 가능하며, optimizer는 비용 비교를 통? 수행 방법을 결정?다. Optimizier는 DISTINCT ?에 기술된 칼럼에 대하여 ?덱스가 ?재하거나 하위 구?의 최적화 과정에서 정? 순서가 보장된다면 별도의 저장 공? 없이 처리? 수 있도록 최적화?다. 이를 “정? 순서를 이용? DISTINCT 최적화” 기법이라 ?다. 예를 들어 다음과 같은 질의는 “정? 순서를 이용? DISTINCT 최적화”가 적용되어 별도의 저장 공? 없이 처리가 가능하다. Index on T1(i1, i2, i3) SELECT DISTINCT i1, i2, i3 FROM T1; SELECT DISTINCT i2, i1 FROM T1 WHERE i1 > 0; DISTINCT ?에 기술된 칼럼은 ?덱스의 칼럼 순서대로 기술될 296 Administrators Manual 필요는 없으나, ?덱스의 키 칼럼 순서로 모두 접? 가능?야 ?다. 즉, 다음과 같은 질의에는 ?당 ?덱스를 사용? 수 없다. SELECT DISTINCT i1, i3 FROM T1; 이러? 특징을 잘 이?하고 있다면 다음과 같은 질의는 질의 변경을 통? “정? 순서를 이용? DISTINCT 최적화”가 사용되게 ? 수 있다. SELECT DISTINCT i1, i3 FROM T1 WHERE i2 = 0; SELECT DISTINCT i1, i2, i3 FROM T1 WHERE i2 = 0; 위와 같이 i2 칼럼을 DISTINCT ?에 추가하여 ?당 최적화 기법이 사용되게 ? 수 있다. 물? 이는 WHERE ?에 (i2 = 0) 과 같이 i2 값의 ?정함을 보장하는 조건이 있기 때?에 동?? 결과 집합을 추출? 수 있으므로 쿼리 변경이 가능하다. 그러므로 ?덱스를 생성? 때에도 WHERE ? 뿐 아니라 빈번히 사용되는 DISTINCT ?도 함께 고려하는 것이 바람직하다. 집합 연산의 최적화 UNION ALL 을 제외? UNION, INTERSECT, MINUS등의 집합 연산은 중? 결과의 관리를 필요로 ?다. Optimizer는 여러 개의 집합 연산이 중복되어 있을 때 결과 집합이 작은 순서로 ?당 연산을 수행하도록 최적화하지?, 이 역시 비용 계산을 기반으로 이루어지므로 정확하지 않을수 있다. 따라서, 사용자가 결과 집합의 대소 여부를 알고 있다면 연산 순서를 명확히 하는 것이 바람직하다. SELECT * FROM large INTERSECT SELECT * FROM medium INTERSECT SELECT * FROM small; (SELECT * FROM small INTERSECT SELECT * FROM medium ) INTERSECT SELECT * FROM large; ?반적으로 집합 연산과 관?하여 사용자가 빈번히 범하는 오류는 UNION과 UNION ALL을 구분하지 않는다는 것이다. UNION은 중복 결과를 제거하는 반면, UNION ALL은 중복 결과를 제거하지 않는다. 즉, 동?? 테이블을 사용하는 경우 UNION의 성능이 UNION ALL보다 느릴 수 밖에 없다. 그러므로, 두 테이블의 결과가 중복된 것이 없음이 보장되거나 중복 제거가 필요 없는 경우라면 UNIOIN ALL을 사용하는 것이 SQL 튜닝 297 바람직하다. ORDER BY?의 최적화 ORDER BY ?은 정?을 필요로 ?다. Optimizer는 다음과 같은 최적화 기법을 적용? 수 있는 지의 여부를 검사하여 실행 계획을 결정?다. 정? 순서를 이용? ORDER BY LIMIT sorting 정? 순서를 이용한 ORDER BY Optimizer는 ?덱스를 사용? 수 있거나 하위의 최적화 과정에서 ORDER BY ?에서 참조되는 칼럼의 정? 순서가 보장된다면 별도의 sorting없이 처리? 수 있다. 예를 들어 Optimizer는 다음과 같은 질의의 경우 별도의 sorting없이 ORDER BY?을 처리?다. Index on T1(i1, i2, i3) SELECT * FROM T1 ORDER BY i1, i2, i3; SELECT * FROM T1 WHERE i1 = 0 ORDER BY i1, i2; ORDER BY ?의 칼럼이 ?덱스 칼럼과 동?? 순서? 경우에? ?당 최적화 기법의 적용이 가능하다. 그러므로, 실행 계획의 분석을 통? 힌트등을 사용하여 ORDER BY?을 위? sorting과정을 제거? 수 있다. Index IDX1 on T1(i1, i2), Index IDX2 on T1(i3) SELECT * FROM T1 WHERE i3 IS NOT NULL ORDER BY i1, i2; SELECT /*+ INDEX(T1, IDX1) */ * FROM T1 WHERE i3 IS NOT NULL ORDER BY i1, i2; 위의 예제에서는 IDX2?덱스를 이용하여 WHERE?을 처리하는 것보다 IDX1 ?덱스를 사용하여 ORDER BY?의 sorting비용을 제거하는 것이 효율적이라면 힌트를 사용하는 것이 바람직하다. LIMIT ?과 정? LIMIT 구?은 질의 결과의 ?체 집합 중에서 ?부?을 결과 집합으로 구성하는 구?이다. 아래 질의는 T1 테이블의 ?체 레코드 중 5개의 결과?을 반??다. SELECT * FROM T1 LIMIT 5; 298 Administrators Manual ORDER BY구?과 LIMIT 구?이 함께 사용되면, Optimizer는 LIMIT sorting 최적화를 수행?다. 이는 ?체 레코드를 위? 공?을 사용하지 않고 LIMIT 구?에 기술된 개수?큼의 공?을 사용하여 정?을 수행하는 방법이다. 예를 들어, 다음과 같은 질의는 정?시 다섯 개의 레코드 공??을 이용하여 정?을 수행?다. SELECT * FROM T1 ORDER BY i1 LIMIT 5; 따라서, ?체 데이터에 대? 정? 결과가 필요하지 않는 경우라면 LIMIT 구?을 이용하여 자원 효율 및 성능 향상을 기대? 수 있다. 파티션의 최적화 파티?드 테이블에 접?시 파티? 프루닝(pruning)과 필터릿을 이용하여 불필요? 파티?을 제거하고 술어의 조건에 맞는 파티?? 참조하는 실행계획 트리(execution plan tree)가 생성된다. 파티? 프루닝은 실행(execution)중에 조건이 바뀌지 않는 고정 술어(fixed predicate)를 최적화?다. 그러나 가변 술어(variable predicate)는 조건에 부합하는 레코드가 저장된 파티?이 계속 바뀌므로, 불필요? 파티?을 실행계획 트리에서 제거하거나 조건에 부합하는 파티??을 포함하는 실행계획 트리의 생성이 불가능하다. 이러? 가변 술어는 다음의 파티? 필터릿으로 최적화된다. 범위 파티? 프루닝 리스트 파티? 프루닝 ?시 파티? 프루닝 파티? 필터릿 범위 파티션 프루닝 범위 파티? 프루닝이 가능? 술어의 형태는 ?덱스를 사용하여 검색이 가능? 조건과 형태가 동?하다. 호스트 변수가 포함된 조건이거나 조? 조건의 경우는 ?당되지 않는다. 이런 술어에는 범위를 나타내는 ?덱스 사용이 가능? 모? 술어들이 포함되는데, 그 예는 다음과 같다. I1 = 1 i1 between 1 and 10 i1 > 5 SQL 튜닝 299 tim e_id < 2006.04.01 Part_1 tim e_id < 2006.07.01 Part_2 tim e_id < 2006.10.01 Part_3 tim e_id >= 2006.10.01 Part_4 Sales (partition key : tim e_id) 2005.08.13 2006.01.21 2006.02.12 2006.03.31 ... 2006.04.01 2006.05.15 2006.06.12 ... ... 2006.08.17 2006.09.01 ... ... ... 2006.10.02 2006.11.11 2006.12.01 NULL ... SELECT sum (am ount_sold) FROM sales WHERE tim e_id <= to_date(‘20060918’, ‘YYYYMMDD’); SCAN(Part_1) SCAN(Part_2) SCAN(Part_3) PROJ GRAG PCRD(Sales) [그림 11-5] 범위 파티? 프루닝의 예 위의 [그림 10-5]의 Sales 테이블은 시?을 기?으로 총 4개의 파티?으로 분리된 파티?드 테이블이다. 파티? 키? time_id를 참조하는 술어를 통? 최적화 단계에서 파티? 프루닝이 수행된다. 그리하여 Plan Tree의 스캔 대상은 술어 조건에 부합되는 Part_1, Part_2, Part_3?이 남게 된다. PCRD는 Partition-Coordinator 실행 노드로, 파티?드 테이블의 각각의 파티?에 대? SCAN노드를 자식 노드로 가지는 노드이다. 리스트 파티션 프루닝 리스트 파티? 프루닝이 가능? 술어의 형태는 ?덱스를 사용하여 검색이 가능? 조건과 형태가 동?하나, 등호(equality, =) 연산자? 가질 수 있다. 호스트 변수가 포함된 조건이거나, 조? 조건의 경우는 이에 ?당되지 않는다. 이런 술어의 예는 다음과 같다. I1 = 1 i1 in (4,5,6) i1 is NULL 300 Administrators Manual depart = ‘RND1’ Part_1 Employee(partition key : department) depart = ‘RND2’ Part_2 depart = ‘RND3’, ‘RND4’ Part_3 depart = ‘RND5’ Part_4 depart = DEFAULT Part_5 SELECT id FROM employee WHERE depart = ‘RND1’; PROJ SCAN(Part_1) PCRD(Sales) SELECT id FROM employee WHERE depart > ‘RND1’ AND depart < ‘RND4’; PROJ SCAN(Part_1) PCRD(Sales) SCAN(Part_2) SCAN(Part_3) SCAN(Part_4) SCAN(Part_5) SELECT id FROM employee WHERE depart IN ( ‘RND1’, ‘RND3’, ‘RND5’); PROJ SCAN(Part_1) PCRD(Sales) SCAN(Part_3) SCAN(Part_4) SELECT id FROM employee WHERE depart = ‘SUPPORT’; PROJ PCRD(Sales) SCAN(Part_5) [그림 11-6] 리스트 파티? 프루닝의 예 [그림 10-6]의 Employee 테이블은 부서명을 기?으로 총 5개의 파티?으로 분리된 파티?드 테이블이다. 최적화 단계에서 파티? 키? depart를 참조하는 술어로 파티? 프루닝이 되어, 각각의 질의에 대? 실행계획 트리의 스캔 대상은 술어 조건에 부합되는 파티?이 된다. 해시 파티션 프루닝 ?시 파티? 프루닝이 가능? 술어의 형태는 ?덱스를 사용하여 검색이 가능? 조건과 형태가 동?하며, 등호 (equality, =)연산자? 가질 수 있다. 호스트 변수가 포함된 조건이거나, 조? 조건의 경우는 이에 ?당되지 않는다. 이런 술어의 예는 다음과 같다. I1 = 1 i1 in (4,5,6) i1 is NULL SQL 튜닝 301 Part_1 Employee(partition key : id) Part_2Part_4Part_3 0 4 12 1 5 9 13 3 15 19 10 18 SELECT department FROM employee WHERE id = 9; PROJ SCAN(Part_2) PCRD(Sales) SELECT department FROM employee WHERE id IN ( 1, 9, 12, 13); PROJ SCAN(Part_2) PCRD(Sales) SCAN(Part_1) SELECT department FROM employee WHERE id < 15; PROJ SCAN(Part_2) PCRD(Sales) SCAN(Part_1) SCAN(Part_3) SCAN(Part_4) [그림 11-7] ?시 파티? 프루닝의 예 위의 [그림 10-7]의 Employee 테이블은 id를 기?으로 총 4개의 파티?으로 분리된 파티?드 테이블이다. 최적화 단계에서 파티? 키? id를 참조하는 술어를 통? 파티? 프루닝이 되어 각각의 질의에 대? 실행계획 트리의 스캔 대상은 술어 조건에 부합되는 파티?이 된다. 파티션 필터링 파티? 필터릿이 가능? 술어의 형태는 파티? 프루닝이 가능? 술어의 형태와 동?하며, 실행중에 변하는 조? 조건 및 호스트 변수가 포함된 술어의 형태도 포함?다. 술어의 조건이 고정적이지 않은 형태의 예제는 다음과 같다. I1 = ? T1.i1 = T2.i1 I1 < ? 302 Administrators Manual time_id sales_events 20060608 20060816 20060121 20060914 20060211 20060405 sales_per 25 10 5 7 40 50 time_id < 2006.04.01 Part_1 time_id < 2006.07.01 Part_2 time_id < 2006.10.01 Part_3 DEFAULT Part_4 Sales ( partition key : time_id) 20060101 20060102 ... 20060121 ... 20060331 20060401 20060102 ... 20060608 ... 20060731 20060801 ... 20060816 ... 20060931 ... 20060931 20061001 20061002 ... ... SCANPCRD JOIN 20060608 20060816 20060121 20060914 sales.time_id = sales_events.sales_per <= 30 [ Partition Filter ] sales_events.time_id = sales.time_id time_id 20060608 20060816 20060121 20060914 sales_per 25 10 5 7 sales.time_id = sales.time_id = sales.time_id = (1) (2) (3) (4) (1) (2) (3) (4) (1)(2)(3)(4) 파티션 필 링 (1) (2) (3) (4) sales_event를 scan한 결과 sales_event를 scan한 결과의 time_id가 조건에 들어감 SELECT SUM(SOLD_AMOUNT) FROM SALES_EVENTS, SALES WHERE SALES_EVENT.SALES_PER <= 30 AND SALES_EVENT.TIME_ID = SALES.TIME_ID; SCANSCANSCANSCAN [그림 11-8] 파티? 필터릿의 예 [그림 10-8]은 실행시 파티? 필터릿이 ?어나는 과정을 나타낸다. 먼저 sales_event 테이블에서 조건에 맞는 레코드가 (1), (2), (3), (4) 순으로 ? 건씩 찾아지고, 이 레코드의 time_id 칼럼이 가변 술어의 sales_events.time_id가 되어 술어 조건에 부합하는 파티?이 결정된다. (1)번 술어의 경우 2006.04.01 ~ 2006.06.29 범위를 갖는 파티?? Part_2에 포함되기 때?에 파티? 필터릿에 의? Part_2에서? 조건에 맞는 레코드를 찾게 된다. ??가지로 (2), (3), (4)번 술어 역시 이와 동?? 방법으로 술어 조건에 부합하는 파티?을 찾아서 스캔?다. 이렇게 수행단계 중에 술어 조건에 맞는 파티?을 찾아서 스캔하는 기법을 파티? 필터릿이라 ?다. 프로젝션의 최적화 프로젝?은 ?체 칼럼으로 구성된 데이터로부터 SELECT 구?에 SQL 튜닝 303 기술된 ?부 칼럼 및 연산 결과를 추출하는 과정이다. 연산 순서의 고려 다음과 같이 핫상 ?정? 결과를 내는 연산은 ? 번? 수행되고 다음 수행 시에는 이?의 결과가 사용된다. SELECT 1 + 1 FROM T1; 알티베이스는 사칙 연산과 같은 연산을 처리함에 있어 post-fix calculation 기법을 사용하는데, 이는 연산 순서를 어떻게 기술하느냐에 따라 성능에 영향을 ? 수 있다. 예를 들어 다음의 두 질의는 동?? 결과를 얻는다. 질의 1: SELECT i1 * 2 * 3 FROM T1; 질의 2: SELECT i1 * (2 * 3) FROM T1; 질의 1의 경우, [i1 * 2] * 3 과 같은 연산 순서로 처리되어 i1 값이 변함에 따라 매번 (* 2) 와 (* 3) 연산이 수행되어야 하지?, 질의 2는 (2 * 3) 의 결과? 6을 생성하고 i1의 값의 변화에 따라 (i1 * 6)의 연산? 수행된다. 즉, 연산 순서를 어떻게 제어하느냐에 따라 성능 차이가 발생? 수 있다. 이는 SELECT 구?뿐 아니라 WHERE? 등의 모? 영역에서 영향을 받는다. 질의 1: WHERE i1 + 3 > 100; 질의 2: WHERE i1 > 100 - 3; 즉, 위의 질의에서 질의 2가 보다 나은 성능을 기대? 수 있다. 그러나, 이러? 수식의 변경 시에는 다음과 같은 점을 고려하여야 ?다. 칼럼 i1 이 INTEGER임을 가정? 때 다음의 질의 1은 질의 3과 같이 기술하는 것이 더 효율적이다. 질의 1: WHERE i1 * 3 > 100; 질의 2: WHERE i1 > 100 / 3; 질의 3: WHERE i1 > 33; 질의 2와 같이 변경? 경우 100/3 은 실수형 값이 되어 칼럼 i1에 대? ?덱스 사용이 불가능??다. 그러나, 질의 3과 같이 변경? 경우 수학적 동치는 아니지? i1이 INTEGER이므로 동?? 결과를 얻을 수 있으며 ?덱스도 사용된다. 이와 같이 연산 순서와 데이터 타입을 잘 고려? 경우 동?? 질의 결과를 얻으면서 성능 향상을 기대? 수 있다. 프로젝?에 대? 최적화는 대부분 subquery내에 ?재하는 SELECT 구?에 대? 최적화이며 이는 다음 ?의 “SUBQUERY의 최적화”를 통? 자세히 설명?다. 304 Administrators Manual SUBQUERY의 최적화 subquery는 조?과 더불어 성능에 아주 큰 영향을 미치는 구?이다. 무엇보다 중요? 것은 subquery의 사용을 최소화 하고, 더 나아가 불필요? subquery를 적게 사용하는 것이다. 예를 들어 다음과 같은 질의를 살펴 보자. SELECT * FROM T1 WHERE (T1. i1 = 1 AND T1.i2 IN ( SELECT a2 FROM T2 WHERE T2.a1 = T1.i1 ) ) OR (T1. i1 = 2 AND T1.i2 IN ( SELECT a2 FROM T2 WHERE T2.a1 = T1.i1 ) ); SELECT * FROM T1 WHERE T1. i1 IN (1, 2) AND T1.i2 IN ( SELECT a2 FROM T2 WHERE T2.a1 = T1.i1 ) ); 위의 두 질의는 수학적으로 동?? 질의이며, 위와 같이 불필요? subquery의 개수를 ?이는 것이 중요하다. Optimizer 는 subquery에 대하여 매우 다양? 최적화 기법을 적용하며, 최저 비용과 수학적 동치가 보장될 때 ?당 최적화 기법을 적용?다. Optimizer가 적용하는 최적화 기법을 이?하고 있다면 적?? 질의 변형을 통하여 질의 성능을 대폭 향상시킬 수 있다. Optimizer 는 subquery의 실행 방법을 결정? 때 다음과 같은 최적화 기법들의 적용 가능 여부 및 비용 평가를 통? ?당 기법의 적용 여부를 결정?다. EXISTS, UNIQUE ?의 subquery에서 SELECT 칼럼 제거 Eliminate Quantified Predicates NJ Transformation Subquery의 불변 영역 (Invariant Area) Store And Search Subquery Key Range Subquery 유형 Optimizer의 subquery 최적화 기법을 설명하기 ?에 subquery의 유형에 대하여 살펴보자. subquery의 유형에 따라 적용될 수 있는 최적화 기법이 다르므로 이를 이?하는 것은 매우 중요하다. subquery는 외부 칼럼의 참조 여부와 그룹 연산의 ?재 여부에 따라 다음과 같이 4가지로 분류된다. 여기서 그룹 연산이? GROUP BY, HAVING, aggregation 연산 중 하나라도 포함된 것을 의미?다. SQL 튜닝 305 외부 칼럼 비참조 외부 칼럼 참조 그룹 연산 비?재 Type N (No) Type J (Join) 그룹 연산 ?재 Type A (Aggregation) Type JA (Join + Aggregation) [표 11-13] 서브쿼리의 유형 Type N: 다음 예와 같이 외부 칼럼이 ?재하지 않고 그룹 연산도 ?재하지 않는 경우이다. SELECT * FROM T1 WHERE T1.i1 IN ( SELECT T2.a1 FROM T2 ); Type J: 다음 예와 같이 외부 칼럼을 참조하지? 그룹 연산은 없는 경우이다. SELECT * FROM T1 WHERE EXISTS ( SELECT * FROM T2.a1 = T1.i1 ); Type A: 다음 예와 같이 외부 칼럼을 참조하지는 않지? 그룹 연산이 있는 경우이다. SELECT * FROM T1 WHERE i1 > ( SELECT SUM(a1) FROM T2 ); Type AJ: 다음 예와 같이 외부 칼럼을 참조하고 그룹 연산이 ?재하는 경우이다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a2 = T1.i2 GROUP BY a1 HAVING SUM(a2) > 0 ); Type N과 type A의 경우 외부 칼럼을 참조하지 않아 핫상 동?? 결과를 생성하는 반면, type J와 type JA는 외부 칼럼을 참조하므로 외부 칼럼의 변경에 따라 핫상 다시 실행되어야 ?다. 즉, subquery에 외부 칼럼을 사용하지 않고 질의를 작성? 수 있다면 보다 나은 성능을 기대? 수 있다. 위와 같이 subquery의 유형에 따라 관? 최적화 기법의 적용 가능 여부가 결정된다. EXISTS, UNIQUE ?의 subquery에서 SELECT 칼럼 제거 EXISTS, UNIQUE ?의 subquery에서는 ?은 경우 SELECT ?에 기술된 칼럼이 의미가 없다. Optimizer는 subquery에 대? 최적화 과정에서 이를 다음과 같이 제거?다. SELECT * FROM T1 WHERE EXISTS ( SELECT a1, a2 * 1, a3 + a4 FROM T2 ); => SELECT * FROM T1 306 Administrators Manual WHERE EXISTS ( SELECT 1 FROM T2 ); 그러나, 이러? 최적화가 사용되면 subquery의 유형이 type N, type J 에서? 동?? 질의 결과임을 보장? 수 있으며, type A, type JA의 경우에는 잘못된 결과가 생성될 수 있다. 예를 들어, 다음과 같은 질의를 살펴 보자. SELECT * FROM T1 WHERE EXISTS ( SELECT COUNT(*) FROM T2 ); => SELECT * FROM T1 WHERE EXISTS ( SELECT 1 FROM T2 ); ?뜻 위 두 질의는 동?? 결과를 생성? 것으로 보이지?, T2 테이블에 레코드가 없는 경우 질의 결과가 다르게 된다. 이러? 점을 고려하여 사용자가 동?? 결과를 생성? 수 있도록 질의 변경을 하는 것이 성능을 향상시킬 수 있다. Eliminate Quantified Predicates subquery에 ANY, ALL과 같은 quantified predicate와 부등호 연산자가 함께 사용될 경우 다음과 같이 quantified predicate를 제거? 수 있다. 위와 같은 최적화 기법을 eliminate quantified predicate 기법이라 ?다. SELECT * FROM T1 WHERE i1 >=ANY ( SELECT a1 FROM T2 ); => SELECT * FROM T1 WHERE i1 >= ( SELECT MIN(a1) FROM T2 ); SELECT * FROM T1 WHERE i1 >ALL ( SELECT a1 FROM T2 ); => SELECT * FROM T1 WHERE i1 > ( SELECT MAX(a1) FROM T2 ); 위와 같은 최적화 기법은 MIN 또는 MAX등의 하나의 값에 대?서? 검사하기 때?에 ?체 레코드를 비교하는 것보다 ?은 성능 향상을 기대? 수 있다. 또?, 이와 같은 질의 변경은 앞에서 ?급? 정? 순서를 이용? MIN/MAX 최적화 등에 의하여 ?덱스를 사용하는 것이 가능?져 성능을 향상시킬 수 있다. 그러나, 이러? 질의 변경도 T2테이블에 레코드가 ?재하지 않는 경우에는 그 결과가 다를 수 있어, optimizer가 반드시 동?? 방식으로 질의를 변경하지는 않는다. 이는 type A, type J 에 대?서? 가능하다. optimizer는 비용 비교를 통? ?당 최적화 기법의 적용 여부를 결정하게 된다. 따라서, 사용자가 위와 같은 최적화 기법을 이?하고 ?당 질의로 동?? 결과를 얻을 수 있음이 보장된다면, optimizer에 그 판단을 SQL 튜닝 307 ?기지 않고 명시적으로 질의를 변경하는 것도 좋은 방법이다. NJ Transformation NJ Transformation 기법은 type N 또는 type J의 subquery를 type J형으로 변경시키는 방법이다. 다음 예를 통? ?당 기법을 살펴보자. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 ); SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a1 = T1.i1 ); 위의 예에서, 원 질의는 type N 형의 subquery로 외부 칼럼을 참조하지 않고 있으나, NJ Transformation 기법에 의하여 외부 칼럼을 참조하도록 질의를 변경? 것이다. 다음 예제는 type J 형의 subquery를 어떻게 변경하는지 보여?다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a2 = 1 ); SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a1 = 1 AND T2.a1 = T1.i1 ); 이러? 최적화 기법은 T2.a1 칼럼의 ?덱스를 사용하여 성능을 향상시키려 하는 방법이다. ?당 최적화 기법은 T2.a1 칼럼과 T1.i1 칼럼의 데이터가 NULL이 아님이 보장될 때 동?? 결과를 생성? 수 있기 때?에, optimizer는 이러? 제약 조건과 함께 비용 평가를 통? ?당 기법의 적용 여부를 결정?다. ?반적으로 ?당 최적화 기법은 외부 질의의 데이터보다 subquery내의 데이터가 ?은 경우에 효율적? 기법이다. 사용자는 위와 같은 질의 변경이 동?? 결과를 보장? 수 있음을 확?? 경우 명시적으로 질의를 변경하여 성능 향상을 기대? 수 있다. Subquery의 불변 영역(invariant area) 외부 칼럼을 참조하는 type J 또는 type JA형의 subquery라 하더라도 핫상 모? subquery구?이 재수행될 필요는 없다. 예를 들어 다음과 같은 질의를 살펴 보자. SELECT * FROM T1 WHERE i2 > ( SELECT SUM(T2.a2 + T3.x2) FROM T2, T3 WHERE T2.a1 = T3.x1 AND T3.x1 = 1 AND T2.a1 = T1.i1 ); 위의 질의에서 subquery는 T1.i1 칼럼을 참조하고 있는 type 308 Administrators Manual JA형이지?, 이 중 (T3.x1 = 1) 과 같은 ?부 조건은 반복적으로 재수행될 필요가 없다. 즉, ?당 조건의 중? 결과는 핫상 재사용될 수 있으며, 이를 subquery의 불변 영역라고 ?다. Optimizer는 이와 같은 불변 영역을 판단하고, 이들 불변 영역에 대? 저장 및 재사용 여부를 비용 비교를 통? 결정?다. 사용자는 실행 계획 분석을 통? ?당 기법의 적용 여부를 판단? 수 있다. 이에 대? 분석 방법은 “실행 계획 분석” ?에서 설명?다. Store and Search Type N 또는 type A 등의 subquery는 모? 영역이 불변 영역? subquery이다. 이러? 점을 이용하여 subquery의 결과를 모두 저장하고 이를 통? 검색하는 방법을 store and search 최적화 기법이라 ?다. 예를 들어 다음과 같은 질의를 살펴보자. SELECT * FROM T1 WHERE i1 IN ( SELECT SUM(a2) FROM T2 GROUP BY a1 ); 즉, 이 기법은 subquery의 결과를 저장하고 i1 값이 저장된 결과 내에 ?재하는 지를 찾는 방법이다. 이러? 최적화 기법은 type N와 type A에 대?서? 가능하며, i1 칼럼이 ?덱스가 없는 경우에 효율적? 최적화 방법이다. 물?, optimizer는 비용 평가와 최적화 기법의 적용 가능 여부를 판단하여 이 기법을 사용? 것?지를 결정?다. Subquery Key Range Store and search 최적화 기법을 적용? 수 있는 ?경에서 i1 칼럼에 ?덱스가 ?재? 경우에는 그 ?덱스가 사용될 수 있다. 이를 subquery key range 최적화 기법이라 ?다. SELECT * FROM T1 WHERE i1 IN ( SELECT SUM(a2) FROM T2 GROUP BY a1 ); subquery key range 최적화 기법이 반드시 효율적? 것은 아니며, Type N의 경우 다음과 같은 점을 고려?야 ?다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 ); T1.i1 칼럼의 ?덱스를 사용하는 경우와 앞에서 설명? NJ transformation 기법을 사용하여 T2.a1 칼럼의 ?덱스를 사용하는 SQL 튜닝 309 것은 데이터 구성에 따라 서로 다른 성능을 낼 수 있다. ?반적으로 외부 질의의 데이터가 ?은 경우는 subquery key range를 사용하는 것이 효율적이며, subquery의 데이터가 ?은 경우는 NJ transformation 기법을 사용하는 것이 효율적이다. 즉, ?은 데이터를 가? 질의 영역에 ?덱스를 사용하는 것이 보다 효율적? 가능성이 높다. ?반적으로 optimizer가 비용 계산에 의하여 이를 선택하지?, 사용자가 명시적으로 질의를 변경하여 성능을 향상시킬 수도 있다. 다음 질의를 사용자가 원하는 최적화 기법이 적용되도록 변경? 수 있다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 ); Subquery Key Range 최적화 기법을 적용하고 싶은 경우, 아래처럼 변경하면 된다. SELECT * FROM T1 WHERE i1 IN ( SELECT DISTINCT a1 FROM T2 ); NJ Transformation 최적화 기법을 적용하고 싶은 경우, 아래처럼 변경하면 된다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a1 = T1.i1 ); 이러? 질의 변경이 optimizer가 ?당 최적화 기법의 사용을 결정하는데 도움을 ? 수는 있으나 반드시 적용되는 것은 아니다. 또?, 질의 변경 시 반드시 동?? 결과를 보장? 수 있음을 확?하는 것이 중요하다. 조인 질의로 변경 IN또는 EXISTS 등의 subquery는 특정 상황에서 조?으로 변경? 수 있으므로 질의 변경을 통? 성능 향상이 가능하다. 그러나, 조?으로의 질의 변경으로 반드시 성능이 향상되거나, 동?? 결과가 보장되는 것이 아니므로 주의?야 ?다. 예를 들어, 다음의 IN subquery 질의는 T2.a1이 UNIQUE? 경우에 ?? 아래와 같이 조? 형태로 변경이 가능하다. SELECT * FROM T1 WHERE T1.i1 IN ( SELECT T2.a1 FROM T2 ); SELECT T1.* FROM T1, T2 WHERE T1.i1 = T2.a1; ??가지로 아래의 EXISTS subquery도 T2.a1 이 UNIQUE? 경우에 ?? 아래와 같이 조? 형태로 변경이 가능하다. 310 Administrators Manual SELECT * FROM T1 WHERE EXISTS ( SELECT * FROM T2 WHERE T2.a1 = T1.i1 ); SELECT T1.* FROM T1, T2 WHERE T1.i1 = T2.a1; 지금까지 최적화 과정과 질의 튜닝 방법을 살펴보았다. 질의에 어떤 최적화 기법들이 적용되었는지는 앞으로 설명? 실행 계획 분석 단계의 내용을 통? 판단? 수 있다. SQL 튜닝 311 실행 계획 분석 SQL 구? 튜닝을 위?서는 1차적으로 실행 계획(execution plan)을 분석하는 것이 필수적이다. 여기서는 실행 계획 트리 정보를 추출하고 이를 ?석하는 방법과 실행 계획 트리를 구성하는 각 실행 노드들의 정보를 분석하는 방법을 설명?다. 분석 방법 실행 계획 분석을 위한 SQL 구문 실행 계획 트리는 iSQL을 통?서? 볼 수 있다. 실행 계획 트리는 SELECT 구?에 대?서? 제공된다. 이를 얻기 위?서는 SELECT 구?의 수행 ?에 iSQL에서 다음 명령을 수행하여야 ?다. ALTER SESSION SET EXPLAIN PLAN = option; option 에는 ON, OFF, 또는 ONLY 가 올 수 있다. 기본 설정값은 OFF이다. ON: SELECT ? 실행 후 결과 레코드와 함께 Execution Plan 정보를 보여?다. ONLY: SELECT ?에 대? Prepare 과정? 수행? 후 실제 Execution 과정을 수행하지 않고 단지 실행 계획 정보? 보여?다. 주 ?어 변수 바?딩이 ?재하는 SELECT ? 또는 실행 수행 시?이 오래 걸리는 질의에 대? 단순히 실행 계획? 확?려면 이 기능을 사용하도록 ?다. OFF: SELECT? 실행 후 Execution Plan 정보는 보여주지 않고 결과 레코드? 보여?다. 사용자가 기술? WHERE?에 ?재하는 조건들의 처리 방법에 대? 정보 등, 보다 자세? 정보가 필요? 경우는 다음 명령을 사용?다. ALTER SYSTEM SET TRCLOG_DETAIL_PREDICATE = 1; 위의 구?처럼 ?당 프로퍼티에 1을 설정하여 ON시키면, 실행 계획 정보에 WHERE?의 조건들이 FIXED KEY RANGE, VARIABLE KEY RANGE, 또는 FILTER 등으로 자세하게 분류되어 표시된다. 따라서 사용자는 WHERE?을 복잡하게 사용? 경우 어떤 술어들이 ?덱스 스캔을 통? 수행되는지 확?? 수 있다. 단, 특정 최적화 기법에 의? 질의가 변경된 경우는 이러? 정보가 출력되지 않을 수 있다. 312 Administrators Manual 다음은 쿼리 ?의 실행 결과 출력 예이다. iSQL> alter system set trclog_detail_predicate = 1; Alter success. iSQL> alter session set explain plan = on; Alter success. iSQL> select * from t1 where i1 = 1; T1.I1 -------------- 1 1 row selected. [TRCLOG_DETAIL_PREDICATE = 1 이고 EXPLAIN PLAN = ON? 경우] PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) [ FIXED KEY ] OR I1 = 1 [TRCLOG_DETAIL_PREDICATE = 0 이고 EXPLAIN PLAN = ON? 경우] PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) [TRCLOG_DETAIL_PREDICATE = 0 이고 EXPLAIN PLAN = ONLY? 경우] PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: ??, SELF_ID: 2 ) EXPLAN PLAN = ONLY? 경우 질의 실행 없이 실행 계획? 생성하므로 ACCESS 핫목과 같이 실제 실행 후 그 값이 결정되는 핫목들은 물음표(“??”)로 표시된다. 실행 계획 트리의 해석 여기에서는 실행 계획을 ?석하는 방법을 예제를 들어 ?략히 설명?다. 각 실행 노드들이 트리 형태로 연결된 ?체 실행 계획 트리를 따라가면서 실행 순서가 결정된다. SELECT * FROM T1, T2, T3 WHERE T1.I1 = T2.I1 AND T2.I1 = T3.I1 질의의 실행 이 다음과 같은 경우 [EXECUTION PLAN] 6--------- PROJECT ( COLUMN_COUNT: 9, TUPLE_SIZE: 36 ) 5--------- JOIN ( REF_ID: 3 ) 3--------- JOIN ( REF_ID: 2 ) 1--------- SCAN ( TABLE: T1, FULL SCAN, ACCESS: 8, SELF_ID: 1 ) 2--------- SCAN ( TABLE: T2, INDEX: IDX2, ACCESS: 104, SELF_ID: 2 ) 4--------- SCAN ( TABLE: T3, INDEX: IDX3, ACCESS: 1144, SELF_ID: 3 ) 최상위 노드 최하위 노드 실행 계획 트리에서 하나의 노드는 ? 행에 표시된다. 왼쪽으로 SQL 튜닝 313 들여쓰기가 ?이 되어 있는 노드?수록 하위 노드이며 가장 먼저 수행된다. 위 예제에서 가장 최상위 노드는 PROJ 노드이며 최하위 노드는 테이블 T1의 SCAN 노드와 테이블 T2의 SCAN 노드이다. T1 SCAN 노드와 T2 SCAN 노드와 같이 같은 크기?큼 들여쓰기가 되어 있는 노드들의 경우 먼저 나타나는 노드가 상위 노드의 왼쪽 노드에 ?당?다. 레코드 fetch 요구는 TOP-DOWN으로 이루어지고 처리된 레코드는 BOTTOM-UP 방식으로 반?된다. 위의 예제에서 가장 먼저 데이터베이스에 접?하는 노드는 T1 SCAN 노드이고, 그 다음 T2 SCAN 노드, T3 SCAN 노드의 순서로 수행된다. 노드 옆에 명시? 숫자가 노드 수행 순서이다. 위의 예제에서 나타난 실행 계획을 트리 형태로 나타내면 다음 그림과 같다. SCAN T3 JOIN PROJ SCAN T1 SCAN T2 JOIN T1, T2 2 6 3 5 4 1 레코드 이동 경로 레코드 패치 구 경로 [그림 11-9] 레코드 요구와 패치(fetch) 경로 실행 노드의 종류 실행 계획 트리는 다양? 실행 노드들로 구성된다. 실행 노드는 물리 연산자(physical operator)라고도 ?다. 실행 노드는 질의를 직접 수행하는 연산자들로 앞에서 설명? 바와 같이 실행 계획 트리를 통? 연산이 수행되는 흐름을 확?? 수 있다. 실행 노드는 자식 노드의 개수와 중? 결과의 저장 여부에 따라 다음과 같이 구분된다. 314 Administrators Manual 단? 비저장 노드(Unary Non-materialization Node): 하나 이하의 자식 노드를 가지며, 중? 결과를 저장하지 않음 단? 저장 노드(Unary Materialization Node) : 하나 이하의 자식 노드를 가지며, 중? 결과를 저장함 이? 비저장 노드(Binary Non-materialization Node) : 두 개의 자식 노드를 가지며, 중? 결과를 저장하지 않음 이? 저장 노드(Binary Materialization Node) : 두 개의 자식 노드를 가지며, 중? 결과를 저장함 다중 비저장 노드(Multiple Non-materialization Node) : 하나 이상의 자식 노드를 가지며, 중? 결과를 저장하지 않음 이러? 구분에 따라 알티베이스에는 다음과 같이 26가지의 물리 연산자가 ?재?다. 각 실행 노드의 약자는 이후의 실행 계획 트리에 대? 설명시에 사용된다. 구분 약자 출력 이름 기능 단? 비저장 노드 SCAN SCAN 다양? 액세스 방법을 사용?서 테 이블에서 데이터 검색 FILT FILTER 액세스 방법으로 filtering 되지 않는 데이터의 filtering 처리 PROJ PROJECT 프로젝? 처리 GRBY GROUPING 그룹 처리 AGGR AGGREGATION Aggregation 연산 수행 VIEW VIEW 뷰 레코드 구성 VSCN VIEW-SCAN 임시 저장 뷰에 대? 검색 COUNT COUNT 특수 COUNT(*)의 처리 HIER HIER 계층 질의의 처리 단? 저장 노드 SORT SORT 레코드의 정? HASH HASH 레코드의 ?싱 GRAG GROUP- AGGREGATION ?싱 방식에 의? 그룹 구분과 aggregation 연산 수행 HSDS DISTINCT ?싱 방식에 의? 중복 제거 VMTR MATERIALIZATION 임시 저장 뷰의 관리 STOR STORE 레코드의 저장 LMST LIMIT-SORT LIMIT ?을 위? 정? 이? 비저장 노드 JOIN JOIN 조? 처리 MGJN MERGE-JOIN 머지 조? 처리 LOJN LEFT-OUTER-JOIN LEFT OUTER 조? 처리 FOJN FULL-OUTER-JOIN FULL OUTER 조? 처리 AOJN ANTI-OUTER-JOIN ANTI OUTER 조? 처리 CONC CONCATENATION 자식 노드의 결과 조합 SQL 튜닝 315 BUNI BAG-UNION BAG UNION의 처리 이? 저장 노드 SITS SET-INTERSECT SET INTERSECT 집합 연산 수행 SDIF SET-DIFFERENCE SET DIFFERENCE 집합 연산 수행 다중 비저장 노드 PCRD PARTITION- COORDINATIOR 파티?드 테이블의 각 파티?에 대 ? 스캔을 관리하는 노드 [표 11-14] 실행 노드의 종류 저장 노드의 특징 저장 노드(Materialization node)는 관? 연산을 수행하기 위하여 중? 결과를 저장하는 노드이다. 중? 결과는 임시 테이블에 저장되는데, 이는 저장 매체의 종류에 따라 메모리 임시 테이블 또는 디스크 임시 테이블이 될 수 있다. 메모리 임시 테이블은 시스템 커널로부터 직접 ?당 받은 메모리 영역에 저장되는데, 이는 질의 수행 후에 바로 제거된다. 디스크 임시 테이블은 사용자에 의? 지정된 임시 테이블스페이스 영역에 저장되며, 이 데이터는 메모리 버퍼를 이용하여 관리된다. 이 또? 질의 수행 후에 바로 제거된다. 메모리 임시 테이블 또는 디스크 임시 테이블을 사용하게 되는 기?은 다음과 같다. 저장 노드의 하위 자식 노드들이 모두 메모리 테이블?을 사용하는 경우라면 메모리 임시 테이블이 사용된다. 디스크 테이블이 하나 이상 포함되어 있는 경우에는 디스크 임시 테이블이 사용된다. 이러? 기?은 힌트를 이용하여 변경? 수 있다. 다음 예와 같이 메모리 테이블 또는 디스크 테이블이 사용되는지에 따라서 정?이 다르게 다뤄지는 것을 실행 계획에서 확?? 수 있다. 아래의 질의의 실행 계획은 메모리 테이블에 대하여 중복 제거 및 정?을 위하여 중? 결과를 저장하는 두 개의 저장 노드를 가지고 있다. 메모리 임시 테이블이 사용되는 경우 디스크 페이지에 대? 정보를 별도로 갖지 않는다. 316 Administrators Manual iSQL> select distinct i3 from memory_table order by i3; I3 -------------- 0 1 2 3 4 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SORT( ITEM_SIZE: 24, ITEM_COUNT: 5, ACCESS: 5, SELF_ID: 2, REF_ID: 0 ) DISTINCT ( ITEM_SIZE: 24, ITEM_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 5, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: MEMORY_TABLE, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) ------------------------------------------------------------ 다음은 디스크 테이블에 대하여 중복 제거 및 정?을 위하여 중? 결과를 저장하는 두 개의 저장 노드를 보이고 있다. 디스크 임시 테이블이 사용되는 경우 디스크 페이지에 대? 정보를 갖는다. 즉, 실행 노드의 정보 중 DISK_PAGE_COUNT 정보의 유무를 통? 임시 테이블의 저장 매체 정보(메모리?지 디스크?지)를 판단? 수 있다. iSQL> select distinct i3 from disk_table order by i3; I3 -------------- 0 1 2 3 4 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SORT ( ITEM_SIZE: 32, ITEM_COUNT: 5, DISK_PAGE_COUNT: 3, ACCESS: 5, SELF_ID: 2, REF_ID: 0 ) DISTINCT( ITEM_SIZE: 24, ITEM_COUNT: 5, DISK_PAGE_COUNT: 6, ACCESS: 5, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: DISK_TABLE, FULL SCAN, ACCESS: 16384, DISK_PAGE_COUNT: 28, SELF_ID: 0 ) ------------------------------------------------------------ 모? 저장 노드들은 임시 저장 테이블에 저장된 데이터가 재구성될 필요가 있는지를 판단하기 위? 정보를 갖는다. 이러? 정보는 REF_ID 로 표현된다. 특정 REF_ID에 ?당하는 실행 노드의 레코드가 변경될 경우 임시 저장 테이블이 재구성된다. 위의 예에서는 모두 자식 노드들을 참조하고 있어 별도의 재구성이 발생하지 않는 것을 알 수 있다. SQL 튜닝 317 단일 비저장 노드 단? 비저장 노드는 하나 이하의 자식 노드를 가지며, ?당 기능을 수행하기 위? 별도의 저장 공?을 필요로 하지 않고 하나의 레코드?을 관리하는 노드이다. 위와 같은 특징을 갖는 각 실행 노드의 기능과 실행 계획내에서 이를 분석하는 방법에 대하여 살펴본다. SCAN 노드 SCAN 노드는 관계형 모델에서 검색(select)연산을 수행하는 물리적? 개체이다. SCAN 노드는 자식 노드를 갖지 않으며 테이블에 직접 접?하여 ?당 테이블에서 레코드를 가져온다. SCAN 노드에서 검사되는 조건은 다음과 같이 5가지의 처리 방법으로 처리된다. Fixed key range Variable key range Constant filter Filter Subquery filter EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 SCAN 노드의 정보는 다음과 같다. 구분 설명 비고 SCAN 실행 노드의 이름 TABLE 접?하는 테이블의 이 름 ACCESS 실제 접?? 레코드의 개수 DISK_PAGE_COUNT 테이블의 디스크 페이 지 개수 메모리 테이블은 ?당 정보가 없음 SELF_ID 실행 노드의 ID [표 11-15] SCAN 노드의 정보 메모리 테이블과 디스크 테이블 메모리 테이블과 디스크 테이블은 서로 출력되는 정보가 약? 다르다. 디스크 테이블의 경우에? ?당 테이블이 소유? 디스크 페이지 개수가 출력된다. 아래는 메모리 테이블과 디스크 테이블의 SCAN 노드의 출력 정보를 318 Administrators Manual 비교? 것이다. 다음 예는 SYS 사용자의 기본 테이블스페이스가 SYS_TBS_MEMORY로 지정되어 있는 경우이며, 메모리 테이블의 SCAN 노드 정보를 보이고 있다. iSQL> create table m1 ( i1 integer ); Create success. iSQL> select * from m1; M1.I1 -------------- No rowselected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: M1, FULL SCAN, ACCESS: 0, SELF_ID: 0 ) ------------------------------------------------------------ 다음 예는 명시적으로 SYS_TBS_DATA? 디스크 테이블스페이스에 생성된 테이블의 SCAN 노드 정보이다. 아래와 같이 디스크 테이블의 경우 테이블이 점유하고 있는 디스크 페이지의 개수를 보여?다. iSQL> create table d1 ( i1 integer ) tablespace sys_tbs_data; Create sucess. iSQL> select * from d1; D1.I1 -------------- No rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: D1, FUL SCAN, ACCESS: 0, DISK_PAGE_COUNT: 2, SELF_ID: 0 ) ------------------------------------------------------------ 테이블 이름 아래의 예에서와 같이 SCAN 노드가 접?하고 있는 테이블의 이름을 보여주며, 질의에 alias 이름을 지정? 경우 다음과 같이 출력된다. iSQL> select * from t1 v1; V1.I1 -------------- No rowselected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1 V1, FULL SCAN, ACCESS: 0, SELF_ID: 0 ) ------------------------------------------------------------ SQL 튜닝 319 액세스 방법 및 레코드 액세스 횟수 질의 튜닝에 있어 가장 중요? 정보는 ?체 스캔을 하는 지 ?덱스를 사용하는 지의 여부와 얼?나 ?은 레코드 접?이 이루어졌는 지를 판단하는 것이다. 레코드 접?이 ?을수록 성능 저하의 요?이 되므로 이에 대? 판단을 하는 것이 매우 중요하다. 다음은 ?체 스캔에 의하여 ?당 질의를 처리? 경우이다. WHERE?을 비교하기 위하여 레코드에 접?? 수를 보이고 있다. iSQL> select * from t1 where i1 = 1000; T1.I1 T1.I2 --------------------------- 10 0 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ 동?? 테이블에 대하여 다음과 같이 ?덱스를 사용? 경우의 실행 계획 정보의 예는 다음과 같다. IDX1 ?덱스를 사용하여 조건 비교를 위하여 ? 건? 접?하고 있음을 알 수 있다. iSQL> create index idx1 on t1(i1); Create success. iSQL> select * from t1 where i1 = 1000; T1.I1 T1.I2 --------------------------- 1000 0 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) ------------------------------------------------------------ 동?? 조건에서 다른 칼럼에 대? 조건을 추가? 경우도 동?? 실행 계획이 생성됨을 알 수 있다. iSQL> select * from t1 where i1 = 1000 and i2 = 0; T1.I1 T1.I2 --------------------------- 10 0 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) ------------------------------------------------------------ 320 Administrators Manual 이 때, T1.i2 칼럼에 ?덱스를 추가하고 ?당 ?덱스를 사용하도록 질의를 수행하면 다음과 같은 실행 계획을 볼 수 있다. 동?? 질의임에도 불구하고 다른 ?덱스를 사용하면 접? 효율이 떨어짐을 볼 수 있다. iSQL> create index idx2 on t1(i2); Create success. iSQL> select /*+ INDEX(T1, idx2) */* from t1 where i1 = 1000 and i2 = 0; T1.I1 T1.I2 --------------------------- 10 0 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, INDEX: IDX2,ACCESS: 163, SELF_ID: 2 ) ------------------------------------------------------------ 아래와 같이 별도의 힌트를 주지 않을 경우, optimizer는 비용 비교를 통? 보다 우수? ?덱스를 선택하게 된다. iSQL> select * from t1 where i1 = 1000 and i2 = 0; T1.I1 T1.I2 --------------------------- 10 0 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) ------------------------------------------------------------ 위와 같이 SCAN 노드의 정보를 통? 올바른 액세스 방법이 선택되고 있는지를 확?하고, ?덱스가 없는 경우 질의에 따라 적?? ?덱스를 생성? 주는 것이 필요하다. TRCLOG_DETAIL_PREDICATE TRCLOG_DETAIL_PREDICATE 프로퍼티를 1로 지정하면 SCAN노드에서 조건들이 어떠? 방식으로 처리되는지에 대? 정보를 출력?다. 이 프로퍼티는 ?당 조건이 ?덱스를 사용하고 있는 지를 판단하는 데 있어 유용하게 사용될 수 있다. 다음과 같이 각 조건을 처리하기 위? 어떠? 방법을 사용하고 있는지를 알 수 있다. 즉, 아래의 예에서는 (i1 = 1000) 조건은 ?덱스를 사용? fixed key range로 처리되고, (i2 = 0) 조건은 filter로 처리됨을 알 수 있다. SQL 튜닝 321 iSQL> alter system set trclog_detail_predicate = 1; Alter success. iSQL> alter session set explain plan = on; Alter success. iSQL> select * from t1 where i1 = 1000 and i2 = 0; T1.I1 T1.I2 --------------------------- 1000 0 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) [ FIXED KEY] AND OR I1 = 1000 [ FILTER] AND OR I2 = 0 ------------------------------------------------------------ 다음은 동?? 질의를 처리하는데 다른 ?덱스가 사용된 예제이다. IDX2 ?덱스를 사용 시 ?덱스를 사용하는 조건과 ?덱스를 사용하지 않는 조건이 바뀌었음을 알 수 있다. iSQL> select /*+ INDEX(T1, idx2) */* from t1 where i1 = 1000 and i2 = 0; T1.I1 T1.I2 --------------------------- 10 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, INDEX: IDX2, ACCESS: 163, SELF_ID: 2 ) [ FIXED KEY] AND OR I2 = 0 [ FILTER] AND OR I1 = 1000 ------------------------------------------------------------ 위와 같이 WHERE ?에 기술된 어떠? 조건이 ?덱스를 사용하고 그렇지 않은 지를 판단하는 것 또? 질의 튜닝에 ?은 도움을 ?다. 단, optimizer의 최적화 과정에서 질의 변경등이 발생? 경우 ?당 정보가 출력되지 않을 수 있다. FILT 노드 FILT 노드는 관계형 모델에서 검색(select)연산을 수행하는 물리적 개체이다. 하나의 자식 노드를 가지며 테이블에 직접 접?하지 않고 322 Administrators Manual 관? 조건을 검사?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 FILT 노드의 정보는 다음과 같다 구분 설명 비고 FILTER 실행 노드의 이름 FILT 노드는 노드 이름 외에 별도의 정보를 포함하지 않는다. Filter에 의? 처리되는 조건 정보를 출력하기 위?서는 TRCLOG_DETAIL_PREDICATE 프로퍼티를 설정?다. FILT 노드 정보의 출력 다음 예를 보면 FILT 노드는 이름?을 출력? 뿐 별도의 다른 정보를 출력하지 않는다. 이 예에서 FILT 노드는 (having i2 < 2) 조건을 처리하기 위하여 사용되었다. iSQL> select sum(i1) from t1 group by i2 having i2 < 2; SUM(I1) ----------------------- 1336600 1336764 2 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) FILTER AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 100 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX2, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ 이러? 정보를 확?하려면 TRCLOG_DETAIL_PREDICATE 프로퍼티를 1로 설정함으로써 가능하다. 아래와 같이 FILT 노드가 (i2 < 2) 조건을 처리하기 위하여 사용되었음을 확?? 수 있다. SQL 튜닝 323 iSQL> alter system set trclog_detail_predicate = 1; Alter sucess. iSQL> select sum(i1) from t1 group by i2 having i2 < 2; SUM(I1) ----------------------- 1336600 1336764 2 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) FILTER [ FILTER ] AND OR I2 < 2 AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 100 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX2, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ PROJ 노드 PROJ 노드는 관계형 모델에서 프로젝?(project)연산을 수행하는 물리적 개체이다. 하나의 자식 노드를 가지며 자식 노드의 결과 레코드로부터 필요? 칼럼?을 추출?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 PROJ 노드의 정보는 다음과 같다. 구분 설명 비고 PROJECT 실행 노드의 이름 COLUMN_COUNT 프로젝?되는 칼럼의 개수 TUPLE_SIZE 프로젝?으로 추출하는 레코드 의 크기 [표 11-16] PROJ 노드의 정보 PROJ 노드의 출력 PROJ 노드는 질의의 최종 결과를 구성하는 노드이다. PROJ 노드 정보는 다음과 같이 실행 계획 내에서 볼 수 있다. 질의 결과가 두 개의 칼럼으로 구성되며, 결과 레코드의 크기가 8 byte임을 알 수 있다. 324 Administrators Manual iSQL> select * from t1 where i1 = 1000; T1.I1 T1.I2 --------------------------- 10 0 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) ------------------------------------------------------------ GRBY 노드 GRBY 노드는 관계형 모델에서 정? 기반의 중복 검사를 수행하는 물리적 개체이다. 하나의 자식 노드를 가지며 자식 노드로부터 반?되는 레코드를 이?에 반?된 레코드와 동?? 지 하나씩 반복?서 검사?다. 다음과 같은 질의를 수행하는 데 사용된다. 정? 순서를 이용? 동?? 그룹 여부 판단 정? 순서를 이용? 중복 제거 정? 순서를 이용? DISTINCT aggregation의 처리 EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 GRBY 노드의 정보는 다음과 같다. 구분 설명 비고 GROUPING 실행 노드의 이름 [표 11-17] GRBY 노드의 정보 GRBY 실행 노드는 이름 외에 별도의 정보를 표시하지 않는다. 정? 순서를 이용? 그룹화 GRBY 노드가 정? 순서를 이용? 동?? 그룹 여부를 판단하기 위?서 사용되는 경우 다음과 같은 형태로 실행 계획이 출력된다. 아래의 예를 보면 GRBY 노드가 (GROUP BY I3) ?을 처리하기 위?서 사용되었으며, GROUP BY를 처리하기 위하여 별도의 저장 공?을 사용하지 않고 처리되었음을 알 수 있다. 이는 앞서 최적화 과정의 정? 순서를 이용? GROUP BY의 처리를 통? 설명하였다. SQL 튜닝 325 iSQL> select sum(i1) from t1group by i3; SUM(I1) ----------------------- 26838630 26841907 26845184 26848461 26851738 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ 정? 순서를 이용? 중복 제거 GRBY 노드가 정? 순서를 이용? 중복 제거를 위?서 사용되는 경우 다음과 같은 형태로 실행 계획이 출력된다. 아래의 실행 계획에서 GRBY 노드는 (DISTINCT i3) ?을 처리하기 위? 사용되었으며, DISTINCT를 위? 별도의 저장 공?을 사용하지 않았음을 알 수 있다. 이는 앞서 최적화 과정에서 정? 순서를 이용? DISTINCT 최적화에서 설명하였다. iSQL> select distinct i3from t1; I3 -------------- 0 1 2 3 4 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 0 ) ------------------------------------------------------------ 정? 순서를 이용? DISTINCT aggregation 처리 GRBY 노드가 정? 순서를 이용? DISTINCT aggregation을 처리하기 위?서 사용되는 경우 다음과 같은 형태로 실행 계획이 출력된다. 아래의 예를 살펴보면 (COUNT(DISTINCT i2) )를 처리하는 과정에서 (DISTINCT i2) ?의 중복 제거를 위?서 GRBY 노드가 사용되었다. 이는 앞서 최적화 과정에서 정? 순서를 이용? DISTINCT aggregation 최적화에서 설명하였다. 326 Administrators Manual iSQL> select count(distinct i2) from t1; COUNT(distinct I2) ----------------------- 100 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 3, REF_ID: 1 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX2, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ AGGR 노드 AGGR 실행 노드는 관계형 모델에서 aggregation 연산을 수행하는 노드이다. 하나의 자식 노드를 가지며 중? 결과를 저장하기 위? 별도의 공?을 사용하지 않는다. 동? 그룹의 레코드들에 대하여 aggregation을 수행?다. 다음과 같은 질의를 수행하는 데 사용된다. 정? 순서를 이용? aggregation의 수행 DISTINCT를 포함하는 ?의 aggregation 수행 EXPLAIN PLAN을 ON (또는 ONLY)로 설정하여 표시되는 AGGR 노드의 정보는 다음과 같다. 구분 설명 비고 AGGREGATION 실행 노드의 이름 ITEM_SIZE 하나의 그룹을 위? 레코드 크기 GROUP_COUNT 실행 노드에 의? 생성된 그룹의 개수 [표 11-18] AGGR 노드의 정보 정? 순서를 이용? aggregation 수행 AGGR 노드가 정? 순서를 이용? aggregation 수행을 위? 사용될 경우 다음 예와 같은 실행 계획 정보가 출력된다. 아래의 예를 살펴 보면, GRBY 실행 노드가 구분? 정보를 이용하여 AGGR노드는 SUM(i2)를 수행?다. 이 때 구성되는 레코드는 SUM(i2)와 GROUP BY i3를 사용?서 그룹화된다. 아래 예에서는 16byte의 크기의 레코드를 포함하는 그룹이 다섯 개가 구성되었음을 알 수 있다. SQL 튜닝 327 iSQL> select sum(i2) from t1 group by i3; SUM(I2) ----------------------- 155530 158807 162084 165361 168638 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ DISTINCT를 포함하는 aggregation 수행 Aggregation함수 내에 DISTINCT가 포함되어 있을 경우 중복 제거 작업이 필요하며 이 경우에 ?? 중복 제거를 위? 저장 공?이 사용된다. 아래의 예에서 AGGR 노드는 SUM(DISTINCT i2)를 처리하기 위?서 사용되었다. iSQL> select sum( distinct i2 ) from t1 group by i3; SUM( distinct I2 ) ----------------------- 950 970 990 1010 1030 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ VIEW 노드 VIEW 노드는 관계형 모델에서 가상 테이블을 표현하기 위? 사용되는 노드이다. 이 노드는 사용자가 정의? 뷰를 표현하거나 집합 연산을 통? 생성되는 결과 집합을 하나의 테이블 개념으로 ??하는 역?을 ?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 VIEW 노드의 정보는 다음과 같다. 구분 설명 비고 328 Administrators Manual VIEW 실행 노드의 이름 뷰 이름 뷰의 이름 이름이 있는 경우 ACCESS 뷰 레코드의 접? 회수 SELF_ID 노드의 ID [표 11-19] VIEW 노드의 정보 사용자가 정의? 뷰에 대? 질의가 수행될 경우 생성되는 VIEW 노드의 출력 예는 아래와 같다. VIEW 노드의 하위 노드들은 사용자가 정의? 뷰의 SELECT?에 대? 실행 계획을 의미?다. iSQL> create view v1(a1, a2) as select i3, sum(i2) from t1 group by i3; Create success. iSQL> select * fromv1; V1.A1 V1.A2 ------------------------------------ 0 15530 1 15807 2 162084 3 165361 4 168638 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) VIEW ( V1, ACCESS: 5, SELF_ID: 2 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ 집합 연산이 사용된 질의에서도 VIEW 노드를 사용하게 되는 데, 그 예는 다음과 같다. VIEW 노드는 INTERSECT의 결과를 하나의 테이블의 개념으로 관리하기 위? 생성되었다. 이 경우 별도의 이름을 갖지 않는다. iSQL> select i1, i3 from t1 intersect select i3, i1 from t1; I1 I3 --------------------------- 1 1 2 2 3 3 4 4 4 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) VIEW ( ACCESS: 4, SELF_ID: 2 ) SET-INTERSECT ( ITEM_SIZE: 24, ITEM_COUNT: 16384, BUCKET_COUNT: 8192, ACCESS: 4, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ SQL 튜닝 329 VSCN 노드 VSCN 노드는 관계형 모델에서 임시 저장 뷰에 대? 검색(SELECT) 연산을 수행?다. 하나의 자식 노드를 가지면, 이는 핫상 VMTR 실행 노드이다. 이 노드는 질의 최적화 과정에서 뷰의 결과를 저장 후 처리하는 것이 효율적이라 판단될 때 생성된다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 VSCN 노드의 정보는 다음과 같다. 구분 설명 비고 VSCN 실행 노드의 이름 VIEW 뷰의 이름 ACCESS 뷰 레코드의 접? 회수 SELF_ID 노드의 ID [표 11-20] VSCN 노드의 정보 VSCN 노드가 사용되는 예는 아래와 같다. 아래 질의에는 동?? 뷰에 대? 접?이 외부 질의와 부질의(subquery)에서 모두 등장?다. Optimizer는 최적화 과정에서 ?당 뷰를 임시 저장하여 질의를 수행하는 것이 효율적이라고 판단?서, VMTR 노드를 이용하여 저장?다. 아래는 저장된 뷰의 내용을 VSCN 노드로 접?하고 있는 실행 계획을 나타낸다. 330 Administrators Manual iSQL> select * from v1 x where x.a2 > ( select avg(y.a2) from v1 y ); X.A1 X.A2 ------------------------------------ 3 165361 4 168638 2 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) FILTER :SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 2 ) STORE ( ITEM_SIZE: 32, ITEM_COUNT: 1, ACCESS: 10, SELF_ID: 1, REF_ID: 4 ) VIEW ( ACCESS: 1, SELF_ID: 10 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 2 ) GROUP-AGGREGATION ( ITEM_SIZE: 64, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 9, REF_ID: 4 ) VIEW-SCAN ( VIEW: V1 Y, ACCESS: 5, SELF_ID: 4 ) MATERIALIZATION ( ITEM_SIZE: 24, ITEM_COUNT: 5 ) VIEW ( ACESS: 5, SELF_ID: 7 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 1 ) :SUB-QUERY END VIEW-SCAN ( VIEW: V1 X, ACCESS: 5, SELF_ID: 2 ) ------------------------------------------------------------ 위의 실행 계획에서 (V1 X) 뷰에 대? VSCN 노드는 자식 노드를 갖지 않는 것으로 보?다. 그러나, ?당 VSCN 노드는 VMTR 노드(MATERIALIZATION으로 표시)를 자식 노드로 갖는다. 위 실행 계획의 ?부를 도식화하면 아래 그림과 같다. VSCN (V1 X) PROJ FILT PROJ ... VSCN (V1 Y) VMTR VIEW ... 위의 그림에서와 같이 VSCN(V1 X)와 VSCN(V1 Y) 실행 노드는 SQL 튜닝 331 동?? 자식 노드를 갖고 있다. COUNT 노드 COUNT 노드는 관계형 모델에서 GROUP BY?이 ?재하지 않는 COUNT(*) 연산을 특별히 처리하기 위? 실행 노드이다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 COUNT 노드의 정보는 다음과 같이 SCAN 실행 노드와 유사하다. 구분 설명 비고 COUNT 실행 노드의 이름 TABLE 접?하는 테이블의 이 름 ACCESS 실제 접?? 레코드의 개수 DISK_PAGE_COUNT 테이블의 디스크 페이 지 개수 메모리 테이블은 ?당 정보가 없음 SELF_ID 실행 노드의 ID [표 11-21] COUNT 노드의 정보 다음은 COUNT 노드가 사용된 예이다. 아래의 예를 살펴보면 ?덱스를 사용함으로써 실제 데이터에는 접?하지 않고 COUNT(*) 값을 획득하고 있음을 알수 있다. iSQL> select count(*) from t1 where i1 > 1000; COUNT ----------------------- 15384 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) COUNT( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2, REF_ID: 2 ) ------------------------------------------------------------ HIER 노드 HIER 노드는 관계형 모델에 없는 특수? 연산으로 계층 질의를 수행하는 노드이다. 이 노드는 하나의 자식 노드를 가지며, 자식 노드는 핫상 SCAN 노드이다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 HIER 노드의 정보는 다음과 같다. HIER 노드의 대부분의 정보는 SCAN 노드와 유사하다. 332 Administrators Manual 구분 설명 비고 HIER 실행 노드의 이름 TABLE 접?하는 테이블의 이름 ACCESS 실제 접?? 레코드의 개 수 DISK_PAGE_COUNT 테이블의 디스크 페이지 개수 메모리 테이블 은 ?당 정보가 없음 SELF_ID 실행 노드의 ID [표 11-22] HIER 노드의 정보 계층 질의 수행시 HIER 노드가 사용된 예는 다음과 같다. iSQL> select count(*) from t1 start with i3 = 0 connect by prior i3 = i1 ignore loop; COUNT ----------------------- 3276 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 2 ) HIER ( TABLE: T1, INDEX: IDX1, ACCESS: 3276, SELF_ID: 2 ) SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3276, SELF_ID: 2 ) ------------------------------------------------------------ 단일 저장 노드 단? 저장 노드는 하나 이하의 자식 노드를 가지며, ?당 기능을 수행하기 위? 별도의 저장 공?을 필요로 하는 노드이다. 위와 같은 특징을 갖는 각 실행 노드의 기능과, 실행 계획 내에서 이를 분석하는 방법에 대하여 살펴본다. SORT 실행 노드 SORT 노드는 관계형 모델에서 정? 연산을 수행하는 물리적 개체이다. 하나의 자식 노드를 가지며, 중? 결과를 저장하기 위하여 임시 테이블을 사용?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 SORT 노드의 정보는 다음과 같다. 구분 설명 비고 SQL 튜닝 333 SORT 실행 노드의 이름 ITEM_SIZE 정?을 위? 레코드의 크기 ITEM_COUNT 정?에 포함된 레코드의 개수 DISK_PAGE_COUNT 임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 ?당 정 보가 없음 ACCESS 저장된 레코드에 대? 접? 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부를 결정하는데 사용 되는 노드의 ID [표 11-23] SORT 노드의 정보 SORT 노드는 매우 다양? 용도로 사용된다. 아래에서 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. ORDER BY?에서의 사용 ORDER BY ?이 ?재하고 별도의 정?이 필요? 경우 SORT 노드가 사용된다. 아래의 예에서 SORT 노드는 ORDER BY?을 처리하기 위하여 사용되었다. iSQL> select i3, sum(i2) from t1 group by i3 order by 2; I3 SUM(I2) ------------------------------------ 0 1530 1 15807 2 162084 3 165361 4 168638 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) SORT( ITEM_SIZE: 24, ITEM_COUNT: 5, ACCESS: 5, SELF_ID: 5, REF_ID: 2 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ GROUP BY에서의 사용 SORT 노드는 GROUP BY ?의 동?? 그룹을 분류하기 위? 정?을 수행하기 위? 생성될 수 있다. 아래의 예는 GROUP BY i4 334 Administrators Manual 를 처리하기 위하여 SORT 노드가 생성된 경우이다. iSQL> select i4, sum(distinct i2) from t1 group by i4; I4 SUM(distinct I2) ------------------------------------ 0 950 1 970 2 90 3 1010 4 1030 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SORT ( ITEM_SIZE: 16, ITEM_COUNT: 16384, ACCESS: 16384, SELF_ID: 2, REF_ID: 1 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ DISTINCT?에서의 사용 SORT 노드는 DISTINCT 처리시 정? 방식으로 중복 제거를 하기 위하여 사용될 수 있다. 아래의 예는 DISTINCT i4 를 처리하기 위하여 SORT 노드가 생성된 경우이다. iSQL> select DISTINCT i4from t1; I4 -------------- 0 1 2 3 4 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) GROUPING SORT( ITEM_SIZE: 16, ITEM_COUNT: 16384, ACCESS: 16384, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) ------------------------------------------------------------ 조?에서의 사용 SORT 노드는 조?을 수행하기 위하여 사용될 수 있다. 아래의 예는 조?을 처리하기 위하여 SORT 노드가 생성된 경우이다. T1.i1 = T2.i1 조? 조건을 검사하기 위? sort-based 조?을 수행하기 위? SORT 노드가 생성되었다. SQL 튜닝 335 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1; COUNT ----------------------- 16384 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 2 ) JOIN SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) SORT( ITEM_SIZE: 16, ITEM_COUNT: 16384, ACCESS: 16384, SELF_ID: 3, REF_ID: 2 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ HASH 노드 HASH 노드는 관계형 모델에서 ?싱 연산을 수행하는 노드이다. 이 노드는 하나의 자식 노드를 가지며, 중? 결과를 저장하기 위하여 임시 테이블을 사용?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 HASH 노드의 정보는 다음과 같다. 구분 설명 비고 HASH 실행 노드의 이름 ITEM_SIZE ?싱을 위? 레코드의 크 기 ITEM_COUNT ?싱에 포함된 레코드의 개수 BUCKET_COUNT ?싱을 위? 버킷의 개수 DISK_PAGE_COUNT 임시 저장 테이블을 구성 하는 디스크 페이지 개수 메모리 임시 테 이블은 ?당 정 보가 없음 ACCESS 저장된 레코드에 대? 접 ? 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여 부를 결정하는데 사용되 는 노드의 ID [표 11-24] HASH 노드의 정보 HASH 노드는 매우 다양? 용도로 사용된다. 아래에서 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. 336 Administrators Manual 조?에서의 사용 HASH 노드는 조?을 수행하기 위하여 사용될 수 있다. 아래의 예는 조?을 처리하기 위하여 HASH 노드가 생성된 경우이다. T1.i1 = T2.i1 조? 조건을 검사하기 위하여 hash-based 조?이 수행되는데, 이를 위? HASH 노드가 생성되었다. iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1; COUNT ----------------------- 16384 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 2 ) JOIN SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) HASH( ITEM_SIZE: 24, ITEM_COUNT: 16384, BUCKET_COUNT: 1024, ACCESS: 16384, SELF_ID: 3, REF_ID: 2 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ Subquery 검색에서의 사용 HASH 노드는 subquery와의 비교 연산을 수행하기 위하여 사용될 수 있다. 아래의 예는 i4 in ( select i4 from t2 ) 를 처리하기 위하여 HASH 실행 노드가 사용된 경우이다. HASH 노드는 t2.i4 값을 ?싱하여 저장하고 각 t1.i4 에 부합하는 값이 HASH에 ?재하는 지를 검사?다. SQL 튜닝 337 iSQL> select count(*) from t1 where i4 in ( select i4 from t2 ); COUNT ----------------------- 16384 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 1 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 16384, SELF_ID: 4, REF_ID: 2 ) VIEW ( ACCESS: 16384, SELF_ID: 3 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ::SUB-QUERY END ------------------------------------------------------------ GRAG 노드 GRAG 노드는 관계형 모델에서 ?싱 방식의 그룹 및 aggregation 연산을 수행하는 노드이다. 이 노드는 하나의 자식 노드를 가지며, 중? 결과를 저장하기 위하여 임시 테이블을 사용?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 GRAG 노드의 정보는 다음과 같다. 구분 설명 비고 GROUP- AGGREGATION 실행 노드의 이름 ITEM_SIZE 그룹 연산을을 위? ? 싱 되는 각 레코드의 크 기 GROUP_COUNT 그룹화된 레코드의 개수 BUCKET_COUNT ?싱을 위? 버킷의 개 수 DISK_PAGE_COUNT 임시 저장 테이블을 구 성하는 디스크 페이지 개수 메모리 임시 테 이블은 ?당 정 보가 없음 ACCESS 저장된 레코드에 대? 접? 횟수 SELF_ID 실행 노드의 ID 338 Administrators Manual REF_ID 임시 테이블의 재구성 여부를 결정하는데 사용 되는 노드의 ID [표 11-25] GRAG 노드의 정보 아래의 예는 ?싱 방식의 그룹화와 aggregation 연산을 처리하기 위하여 GRAG 노드가 사용된 경우이다. GRAG 노드는 GROUP BY i4와 AVG(i1), SUM(i2)를 처리하기 위하여 사용되었다. iSQL> select avg(i1), sum(i2) from t1 group by i4; AVG(I1) SUM(I2) ------------------------------------ 8191 15807 8192 162084 8193 165361 8194 168638 8192.5 155530 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 32 ) GROUP-AGGREGATION ( ITEM_SIZE: 80, GROUP_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 5, SELF_ID: 2, REF_ID: 1 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ HSDS 노드 HSDS 노드는 관계형 모델에서 ?싱 방식의 중복 제거 연산을 수행하는 노드이다. 이는 하나의 자식 노드를 가지며, 중? 결과를 저장하기 위하여 임시 테이블을 사용?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 HSDS 노드의 정보는 다음과 같다. 구분 설명 비고 DISTINCT 실행 노드의 이름 ITEM_SIZE 중복 제거를 위? 레코 드의 크기 ITEM_COUNT 중복 제거된 레코드의 개수 BUCKET_COUNT ?싱을 위? 버킷의 개 수 DISK_PAGE_COUNT 임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 ?당 정 보가 없음 SQL 튜닝 339 ACCESS 저장된 레코드에 대? 접? 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부를 결정하는데 사용 되는 노드의 ID [표 11-26] HSDS 노드의 정보 HSDS 실행 노드는 매우 다양? 용도로 사용된다. 아래에서 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. DISTINCT에서의 사용 HSDS 노드는 DISTINCT를 처리하기 위하여 사용될 수 있다. 아래의 예는 DISTINCT를 처리하기 위하여 HSDS 노드가 사용된 것을 보여?다. iSQL> select distinct i4 from t1; I4 -------------- 1 2 3 4 0 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) DISTINCT( ITEM_SIZE: 24, ITEM_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 5, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) ------------------------------------------------------------ UNION 에서의 사용 HSDS 노드는 UNION을 처리하기 위하여 사용될 수 있다. 아래의 예제에서는 UNION을 처리하기 위하여 HSDS 노드가 중복 제거를 위? 사용되었다. 340 Administrators Manual iSQL> select i3, i4 from t1 unionselect i3, i4 from t2; I3 I4 --------------------------- 1 1 2 2 3 3 4 4 0 0 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) DISTINCT ( ITEM_SIZE: 24, ITEM_COUNT: 5, BUCKET_COUNT: 16384, ACCESS: 5, SELF_ID: 4, REF_ID: 2 ) VIEW ( ACCESS: 32768, SELF_ID: 2 ) BAG-UNION PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ Subquery key range를 위? 사용 HSDS 노드는 subquery key range를 처리하기 위하여 사용될 수 있다. 중복 제거를 통? 동?? 값으로 ?덱스를 이용? 검색이 발생하지 않도록 하기 위하여 사용된다. 아래의 예는 HSDS 실행 노드가 subquery key range을 처리하기 위하여 중복 제거를 위? 사용된 예이다. HSDS 실행 노드는 T2.i4 값의 중복 제거를 위?서 사용되었다. iSQL> select i1 from t1 where i1 in ( select i4 from t2 ); I1 -------------- 1 2 3 4 4 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 4, SELF_ID: 1 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) DISTINCT ( ITEM_SIZE: 24, ITEM_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 10, SELF_ID: 4, REF_ID: 2 ) VIEW ( ACCESS: 16384, SELF_ID: 3 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ::SUB-QUERY END ------------------------------------------------------------ SQL 튜닝 341 VMTR 노드 VMTR 노드는 뷰에 대? 임시 저장 테이블을 생성하는 노드이다. 하나의 자식 노드를 가지며, 중? 결과를 저장하기 위하여 임시 테이블을 사용?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 VMTR 노드의 정보는 다음과 같다. 구분 설명 비고 MATERIALIZATION 실행 노드의 이름 ITEM_SIZE 저장된 레코드의 크기 ITEM_COUNT 저장된 레코드의 개수 [표 11-27] VMTR 노드의 정보 VMTR 노드의 사용 예는 VSCN 노드의 사용 예를 참조?다. STOR 노드 STOR 노드는 질의의 ?부 결과를 임시 저장하는 노드이다. 하나의 자식 노드를 가지며, 중? 결과를 저장하기 위하여 임시 테이블을 사용?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 STOR 노드의 정보는 다음과 같다. 구분 설명 비고 STORE 실행 노드의 이름 ITEM_SIZE 저장 레코드의 크기 ITEM_COUNT 저장에 포함된 레코드의 개수 DISK_PAGE_COUNT 임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 ?당 정 보가 없음 ACCESS 저장된 레코드에 대? 접? 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부를 결정하는 기? 노드 ID [표 11-28] STOR 노드의 정보 STOR 노드는 매우 다양? 용도로 사용된다. 아래에서 각 용도별로 342 Administrators Manual 사용될 때의 실행 계획 트리를 살펴 본다. 조?에서의 사용 STOR 노드는 조?에 사용될 수 있다. 이 노드는 조? 조건이 없는 카티? 프로덕트(cartesian product)에 주로 사용된다. 이 노드가 ?반적? 조?에 사용되더라도 조? 조건을 자체적으로 처리하지는 않는다. 아래의 예는 STOR 노드가 카티? 프로덕트를 위하여 사용된 경우이다. T1 테이블에 대? 검색이 완료된 결과를 저장함으로서 반복적? ?덱스 사용을 방지하는 효과를 얻을 수 있다. iSQL> select count(*) from t1, t2where t1.i1 < 5 and t2.i3 = 1; COUNT ----------------------- 13108 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 2 ) JOIN SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) STORE ( ITEM_SIZE: 16, ITEM_COUNT: 4, ACCESS: 13108, SELF_ID: 4, REF_ID: 2 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 4, SELF_ID: 2 ) ------------------------------------------------------------ LMST 노드 LMST 노드는 관계형 모델에서 제?된 정? 연산을 수행하는 노드이다. 이는 하나의 자식 노드를 가지며, 중? 결과를 저장하기 위하여 임시 테이블을 사용?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 LMST 노드의 정보는 다음과 같다. 구분 설명 비고 LIMIT-SORT 실행 노드의 이름 ITEM_SIZE 정?을 위? 저장 레코드의 크기 ITEM_COUNT 사용된 레코드의 개수 STORE_COUNT 저장된 레코드의 개수 ACCESS 저장된 레코드에 대? 접? 횟수 SQL 튜닝 343 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부 를 결정하는 기? 노드 ID [표 11-29] LMST 노드의 정보 LMST 노드는 매우 다양? 용도로 사용된다. 아래에서 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. ORDER BY에서의 사용 LMST 노드는 LIMIT을 포함? ORDER BY에 사용될 수 있다. 아래의 예는 LMST 노드가 ORDER BY를 위하여 사용된 경우이다. 실행 계획 정보를 살펴 보면, 3개의 저장 공?? 사용하여 16384건의 레코드에 대? 정?을 수행함을 알 수 있다. iSQL> select * from t1 order by i4 limit 3; T1.I1 T1.I2 T1.I3 T1.I4 ----------------------------------------------------- 15 15 0 0 10 10 0 0 5 5 0 0 3 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 16 ) LIMIT-SORT( ITEM_SIZE: 16, ITEM_COUNT: 16384, STORE_COUNT: 3, ACCESS: 3, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) ------------------------------------------------------------ Subquery 검색에서의 사용 LMST 노드는 subquery 검색을 위하여 사용될 수 있다. 아래의 예는 LMST 노드가 ?부 레코드? 정? 저장하여 subquery 검색을 수행하고 있음을 보이고 있다. 여기서 LMST 노드는 질의 처리에 필요? t2.i4 값 중 ?부?을 저장하여 이에 대? 비교 연산의 비용을 ?이고 있다. 344 Administrators Manual iSQL> select i1 from t1 where i1 <=ANY ( select i4from t2 ); I1 -------------- 1 2 3 4 4 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) LIMIT-SORT( ITEM_SIZE: 16, ITEM_COUNT: 16384, STORE_COUNT: 2, ACCESS: 32768, SELF_ID: 4, REF_ID: 2 ) VIEW ( ACCESS: 16384, SELF_ID: 3 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ::SUB-QUERY END ------------------------------------------------------------ 이? 비저장 노드 이? 비저장 노드는 두 개의 자식 노드를 가지며, ?당 기능을 수행하기 위? 별도의 저장 공?이 필요하지 않다. 위와 같은 특징을 갖는 각 실행 노드의 기능과 실행 계획내에서 이를 분석하는 방법에 대하여 살펴본다. JOIN 노드 JOIN 노드는 관계형 모델에서 조? 연산을 수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중? 결과를 ?들지 않으며 자식 노드들의 수행 흐름을 제어?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 JOIN 노드의 정보는 다음과 같다. 구분 설명 비고 JOIN 실행 노드의 이름 [표 11-30] JOIN 노드의 정보 JOIN 노드는 거의 모? ?반 조? 수행을 위하여 사용된다. 아래에서 다음과 같은 다양? 조? 방법들이 어떠? 형태의 실행 계획 트리로 출력되는지를 살펴 본다. Full nested loop join SQL 튜닝 345 Full store nested loop join Index nested loop join One-pass sort join Multi-pass sort join One-pass hash join Multi-pass hash join 아래의 예제에서 동?? 질의가 다양? 조? 방법으로 처리되며, 각 방법에 대? 실행 계획 트리의 정보를 보여?다. 좌측은 조? 수행 방법에 대? 실행 계획 트리의 ?부를 그림으로 도식화? 것이며, 우측은 실제 실행 계획이다. Full nested loop join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 53690368, SELF_ID: 3 ) ------------------------------------------------------------ JOIN SCANSCAN 위의 실행 계획에서 조? 조건은 우측 SCAN 노드에서 처리된다. T2 테이블에 대? 반복적? ?체 검색을 통? 처리된다. Full store nested loop join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) FILTER JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) STORE ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 10738729, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ JOIN SCANSTOR FILT SCAN 위의 실행 계획에서 조? 조건은 JOIN 상위의 FILT 노드에서 처리된다. T2 테이블에 대? 검색은 ? 번? 이루어지며 그 결과를 저장? 후 반복적으로 ?체 검색을 통? 처리된다. Index nested loop join의 실행 계획 트리 346 Administrators Manual iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 3277, SELF_ID: 3 ) ------------------------------------------------------------ JOIN SCANSCAN 위의 실행 계획에서 조? 조건은 우측 SCAN 노드에서 ?덱스를 이용하여 처리된다. One-pass sort join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ JOIN SCANSORT SCAN 위의 실행 계획에서 조? 조건은 우측 SORT 노드에서 정?된 데이터를 이용하여 처리된다. Multi-pass sort join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 6, REF_ID: 3 ) JOIN SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 4, REF_ID: 2 ) SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 5, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ JOIN SORTSORT SCANSCAN 위의 실행 계획에서 조? 조건은 우측 SORT 노드에서 정?된 SQL 튜닝 347 데이터를 이용하여 처리되지?, 좌측에도 SORT 노드가 생성된다. One-pass hash join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 3277, BUCKET_COUNT: 1024, ACCESS: 3277, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ JOIN HASH SCAN SCAN 위의 실행 계획에서 조? 조건은 우측 HASH 노드에서 ?싱된 데이터를 이용하여 처리된다. Multi-pass hash join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 6, REF_ID: 3 ) JOIN HASH ( ITEM_SIZE: 24, ITEM_COUNT: 3277, BUCKET_COUNT: 1024, ACCESS: 3277, SELF_ID: 4, REF_ID: 2 ) SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 3277, BUCKET_COUNT: 1024, ACCESS: 3277, SELF_ID: 5, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ JOIN HASH SCAN HASH SCAN 위의 실행 계획에서 조? 조건은 우측 HASH 노드에서 정?된 데이터를 이용하여 처리되지?, 좌측에도 HASH 노드가 생성된다. MGJN 노드 MGJN 노드는 관계형 모델에서 머지 조? 연산을 수행하는 노드이다. 이는 두개의 자식 노드를 가지며, 별도의 중? 결과를 ?들지 않으며 자식 노드들의 수행 흐름을 제어?다. MGJN 실행 노드는 자식 노드로 SCAN, SORT, MGJN 중 하나를 취?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 MGJN 노드의 정보는 다음과 같다. 348 Administrators Manual 구분 설명 비고 MERGE-JOIN 실행 노드의 이름 [표 11-31] MGJN 노드의 정보 MGJN 노드는 ?반 조? 수행을 위하여 사용되며, 좌우 자식 노드를 모두 정?하거나 정?된 순서를 이용하여 처리?다. 자식 노드의 종류에 따라 9가지의 머지 조?의 형태가 가능하며, 여기서는 대표적? 두 가지의 실행 계획 트리에 대?서? 살펴 본다. ?덱스를 이용? 머지 조? iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) MERGE-JOIN SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 16384, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ MGJN SCANSCAN 위의 실행 계획에서 조? 조건은 MGJN 노드에서 처리되며 기본 테이블과 반복 테이블의 개념 없이 조? 조건에 포함된 칼럼의 ?덱스가 모두 사용된다. 정?을 이용? 머지 조? iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 7, REF_ID: 3 ) MERGE-JOIN SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 4, REF_ID: 2 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 5, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ MGJN SORTSORT SCANSCAN 위의 실행 계획에서 조? 조건은 MGJN 노드에서 처리되며 조? 조건에 포함된 칼럼을 기?으로 정?? 후 이를 이용?다. LOJN 노드 LOJN 노드는 관계형 모델에서 LEFT OUTER JOIN 연산을 수행하는 SQL 튜닝 349 노드이다. 이는 두개의 자식 노드를 가지며, 별도의 중? 결과를 ?들지 않으며 자식 노드들의 수행 흐름을 제어?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 LOJN 노드의 정보는 다음과 같다. 구분 설명 비고 LEFT-OUTER-JOIN 실행 노드의 이름 [표 11-32] LOJN 노드의 정보 LOJN 노드는 ?반 조?과 ??가지로 대부분의 조? 방법에 사용되며, 이는 JOIN 노드의 예를 참조?다. 여기서는 LOJN 실행 노드가 사용되는 ?단? 실행 계획 트리?을 살펴본다. iSQL> select count(*) from t1 left outer join t2 on t1.i1 = t2.i1 where t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 3 ) FILTER LEFT-OUTER-JOIN SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 3277, SELF_ID: 3 ) ------------------------------------------------------------ LOJN SCANSCAN FOJN 노드 FOJN 노드는 관계형 모델에서 FULL OUTER JOIN 연산을 수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중? 결과를 ?들지 않으며 자식 노드들의 수행 흐름을 제어?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 FOJN 노드의 정보는 다음과 같다. 구분 설명 비고 FULL-OUTER-JOIN 실행 노드의 이름 [표 11-33] FOJN 노드의 정보 FOJN 실행 노드는 ?반 조?과 ??가지로 대부분의 조? 방법에 사용되며, 이는 JOIN 노드의 예를 참조?다. 여기서는 FOJN 실행 노드가 사용되는 ?단? 실행 계획 트리?을 살펴본다. 350 Administrators Manual iSQL> select count(*) from t1 full outer join t2 on t1.i1 = t2.i1 where t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) FILTER FULL-OUTER-JOIN SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 3277, BUCKET_COUNT: 1024, ACCESS: 3277, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ FOJN HASHSCAN SCAN FULL OUTER JOIN의 특성 상 우측에 저장을 위? NODE가 생성되며, 위의 예에서 ON 조건은 HASH 노드에서 처리된다. AOJN 노드 AOJN 노드는 관계형 모델에서 ANTI OUTER JOIN 조? 연산을 수행하는 노드이다. 이는 두개의 자식 노드를 가지며, 별도의 중? 결과를 ?들지 않으며 자식 노드들의 수행 흐름을 제어?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 AOJN 노드의 정보는 다음과 같다. 구분 설명 비고 ANTI-OUTER-JOIN 실행 노드의 이름 [표 11-34] AOJN 노드의 정보 AOJN 노드는 FULL OUTER JOIN?을 위? 사용되며, 아래와 같이 ON 조? 조건에서 참조되는 모? 칼럼에 대하여 ?덱스를 사용? 수 있을 때 사용된다. iSQL> select count(*) from t1 full outer join t2 on t1.i1 = t2.i1 where t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 3 ) FILTER CONCATENATION LEFT-OUTER-JOIN SCAN ( TABLE: T1, FULL SCAN, ACCESS: 22938, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 22938, SELF_ID: 3 ) ANTI-OUTER-JOIN SCAN ( TABLE: T2, FULL SCAN, ACCESS: 22938, SELF_ID: 3 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 22938, SELF_ID: 2 ) ------------------------------------------------------------ CONC AOJNLOJN SQL 튜닝 351 위의 예에서와 같이 FULL OUTER JOIN을 처리하기 위하여 AOJN 노드는 핫상 LOJN 노드와 부모로 CONC 노드를 갖는다. 이 때, ON ?의 조? 조건은 LOJN과 AOJN 에서 모두 처리된다. CONC 노드 CONC 실행 노드는 관계형 모델에서 concatenation 연산을 수행하는 노드이다. 이는 두개의 자식 노드를 가지며, 별도의 중? 결과를 ?들지 않으며 자식 노드들의 수행 흐름을 제어?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 CONC 노드의 정보는 다음과 같다. 구분 설명 비고 CONCATENATION 실행 노드의 이름 [표 11-35] CONC 노드의 정보 CONC 노드는 FULL OUTER JOIN의 처리와 DNF 처리에서 사용된다. FULL OUTER JOIN에서의 사용은 AOJN 노드에서 이미 그 예를 설명하였으며, 여기서는 DNF로 처리 시에 CONC 노드가 사용되는 예를 살펴 본다. iSQL> select sum(i3) from t1 where i1 = 1000 or i2 = 100; SUM(I3) ----------------------- 0 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 3, REF_ID: 2 ) CONCATENATION SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) FILTER SCAN ( TABLE: T1, INDEX: IDX2, ACCESS: 1, SELF_ID: 2 ) ------------------------------------------------------------ CONC FILTSCAN SCAN 여기서 (i1 = 1000) 조건은 왼쪽 SCAN 실행 노드에서 처리되며, (i2 = 100) 조건은 오른쪽 SCAN 실행 노드에서 처리된다. 이렇게 함으로서 IDX1 과 IDX2 ?덱스가 모두 사용될 수 있으며 위 결과를 조합하기 위하여 CONC 실행 노드가 사용된다. FILT 노드는 좌측 SCAN과 중복되는 결과를 제거하기 위하여 사용된다. BUNI 노드 BUNI 노드는 관계형 모델에서 UNION ALL 연산을 수행하는 노드이다. 이는 두 개 이상의 자식 노드를 가지며, 별도의 중? 결과를 ?들지 않으며 자식 노드들의 수행 흐름을 제어?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 BUNI 352 Administrators Manual 노드의 정보는 다음과 같다. 구분 설명 비고 BAG-UNION 실행 노드의 이름 [표 11-36] BUNI 노드의 정보 BUNI 노드가 수행되는 예를 보면 다음과 같다. iSQL> select i3, sum(i2) from t1 group by i3 union all select i3, avg(i2) from t2 group by i3; I3 SUM(I2) --------------------------- 1 158807 2 162084 3 165361 4 168638 0 155530 1 48.4610925 2 49.4610925 3 50.4610925 4 51.4610925 0 47.47558 10 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 26 ) VIEW ( ACCESS: 10, SELF_ID: 3 ) BAG-UNION PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) GROUP-AGGREGATION ( ITEM_SIZE: 32, GROUP_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 5, SELF_ID: 4, REF_ID: 1 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 26 ) GROUP-AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 5, SELF_ID: 5, REF_ID: 2 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ BUNI PROJPROJ 위의 예를 보면 BUNI 노드는 두 질의의 결과를 단순히 조합하여 UNION ALL을 처리?다. 이? 저장 노드 이? 저장 노드는 두개의 자식 노드를 가지며, ?당 기능을 수행하기 위? 별도의 저장 공?을 필요로 ?다. 위와 같은 특징을 갖는 각 실행 노드의 기능과 실행 계획 내에서 이를 분석하는 방법에 대하여 살펴본다. SITS 노드 SITS 노드는 관계형 모델에서 INTERSECT 연산을 수행하는 노드이다. 이는 두개의 자식 노드를 가지며, 교집합을 얻기 위하여 중? 결과를 저장하여 처리?다. SQL 튜닝 353 EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 SITS 노드의 정보는 다음과 같다. 구분 설명 비고 SET-INTERSECT 실행 노드의 이름 ITEM_SIZE 교집합을 위? 저장 레 코드의 크기 ITEM_COUNT 저장된 레코드의 개수 BUCKET_COUNT ?싱을 위? 버킷의 개 수 DISK_PAGE_COUNT 임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 ?당 정 보가 없음 ACCESS 저장된 레코드에 대? 접? 횟수 SELF_ID 실행 노드의 ID L_REF_ID 임시 테이블의 재구성 여부를 결정하는 왼쪽 질의의 기? 노드 ID R_REF_ID 임시 테이블의 재구성 여부를 결정하는 오른쪽 질의의 기? 노드 ID [표 11-37] SITS 노드의 정보 SITS 노드가 INTERSECT를 위? 수행되는 예는 다음과 같다. 좌측 질의의 결과 데이터를 중복 제거하여 저장하고, 우측 질의의 결과 데이터를 이용하여 교집합에 ?당하는 결과를 검색하게 된다. iSQL> select i1, i3 from t1 intersect select i3, i1 from t2; I1 I3 --------------------------- 1 1 2 2 3 3 4 4 4 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) VIEW ( ACCESS: 4, SELF_ID: 2 ) SET-INTERSECT ( ITEM_SIZE: 24, ITEM_COUNT: 16384, BUCKET_COUNT: 8192, ACCESS: 4, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ SITS PROJPROJ SDIF 노드 SDIF 노드는 관계형 모델에서 MINUS 연산을 수행하는 노드이다. 354 Administrators Manual 이는 두 개의 자식 노드를 가지며, 차집합을 얻기 위하여 중? 결과를 저장하여 처리?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 SDIF 노드의 정보는 다음과 같다. 구분 설명 비고 SET-DIFFERENCE 실행 노드의 이름 ITEM_SIZE 차집합을 위? 저장 레 코드의 크기 ITEM_COUNT 저장된 레코드의 개수 BUCKET_COUNT ?싱을 위? 버킷의 개 수 DISK_PAGE_COUNT 임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 ?당 정 보가 없음 ACCESS 저장된 레코드에 대? 접? 횟수 SELF_ID 실행 노드의 ID L_REF_ID 임시 테이블의 재구성 여부를 결정하는 왼쪽 질의 기? 노드 ID R_REF_ID 임시 테이블의 재구성 여부를 결정하는 오른쪽 질의 기? 노드 ID [표 11-38] SDIF 노드의 정보 SDIF 노드가 MINUS를 위? 수행되는 예는 다음과 같다. 좌측 질의의 결과를 중복 제거하여 저장하고, 우측 질의의 결과를 이용하여 교집합을 구? 후 교집합에 포함되지 않은 결과?을 검색?다. iSQL> select i1, i3 from t1 minus select i1, i3 from t2; I1 I3 --------------------------- No rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) VIEW ( ACCESS: 0, SELF_ID: 2 ) SET-DIFFERENCE ( ITEM_SIZE: 24, ITEM_COUNT: 16384, BUCKET_COUNT: 8192, ACCESS: 0, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ SDIF PROJPROJ SQL 튜닝 355 다중 비저장 노드 다중 비저장 노드는 두개 이상의 자식 노드를 가지며, ?당 기능을 수행하기 위? 별도의 저장 공?을 필요로 하지 않는다. 위와 같은 특징을 갖는 각 실행 노드의 기능과 실행 계획내에서 이를 분석하는 방법에 대하여 살펴본다. PCRD 노드 PCRD(Partition-Coordinator) 노드는 파티?드 테이블의 각각의 파티?에 대? 스캔을 관리하는 노드이다. 여러 개의 자식 노드를 가지며, 파티? 필터릿을 수행?다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 PCRD 노드의 정보는 다음과 같다. 구분 설명 비고 PARTITION- COORDINATOR 실행 노드의 이름 TABLE 접?하는 테이블의 이름 PARTITION 접?하는 파티?의 개수 ACCESS 실제 접?? 레코드의 개수 SELF_ID 실행 노드의 ID [표 11-39] PCRD 노드의 정보 PCRD 노드가 수행되는 예는 다음과 같다. 자식 노드? 파티?에 대? 스캔 결과를 상위 노드로 ?달?다. iSQL> SELECT COUNT(*) FROM PDT_RANGE WHERE F1 < 30; COUNT ----------------------- 3 1 row selected. --------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 6, REF_ID: 2 ) PARTITION-COORDINATOR ( TABLE: PDT_RANGE, PARTITION: 3/4, ACCESS: 3, SELF_ID: 2 ) SCAN ( PARTITION: P3, FULL SCAN, ACCESS: 1, DISK_PAGE_COUNT: 2, SELF_ID: 3 ) SCAN ( PARTITION: P2, FULL SCAN, ACCESS: 1, DISK_PAGE_COUNT: 2, SELF_ID: 4 ) SCAN ( PARTITION: P1, FULL SCAN, ACCESS: 1, DISK_PAGE_COUNT: 2, SELF_ID: 5 ) -------------------------------------- PCRD SCANSCANSCAN... 356 Administrators Manual 힌트의 ?용 힌트는 SQL? 실행 계획을 사용자가 명시적으로 변경하고자 ? 때 사용하는 기능이다. 사용자가 생성 가능? SQL?은 그 수를 헤아릴 수가 없으며, 동?? 질의라 하더라도 데이터의 구성에 따라 서로 다른 실행 계획이 생성될 수 있다. Optimizer는 보편적으로 효율적? 실행 계획을 생성하기는 하나 모? 질의에 있어 가장 좋은 실행 계획을 생성? 수 있는 것은 아니다. 이러? 단점을 보완하기 위하여 사용자는 힌트를 사용하여 실행 계획을 명시적으로 변경하여 보다 나은 성능을 얻을 수 있다. 그러나, 모? 질의에 대하여 힌트를 사용하여 실행 계획을 변경하는 것은 매우 불합리하다. 이는 ?덱스의 생성, 데이터 구성의 변경등에 대하여 모? 질의에 대하여 다시 힌트를 작성?야 하는 부하가 따르게 되기 때?이다. 따라서, 시스템의 성능에 영향을 미치는 ?부 치명적? 질의에 ?하여 힌트를 사용하는 것이 바람직하다. 힌트 처리 정책 사용자가 정의? 힌트는 다음과 같은 정책에 의하여 처리된다. 사용자가 정의? 힌트가 ?법적으로 오류가 없고 실행이 가능? 경우 무조건 힌트를 따른다. 즉, ?법적으로 오류가 있는 경우나 실행이 불가능? 힌트는 적용되지 않는다. 힌트 적용 시 사용자가 정의? 힌트에 단순히 가중치를 부여하는 것이 아니며, 사용자가 이미 모? 정보를 고려하여 가장 효율적? 실행 계획을 결정했음을 가정?다. 힌트가 서로 상충? 경우 그 유형에 따라 다음과 같은 우선 순위를 따른다. 최적화 적용 기? 정규화 형태 조? 순서 조? 방법 중? 결과 저장 매체 ?싱 버킷 크기 그룹 처리 방법 중복 제거 처리 방법 뷰 최적화 방법 SQL 튜닝 357 액세스 방법 힌트의 종류 최적화 적용 기? 최적화를 규칙 기반으로 수행? 것?지, 비용 기반으로 수행? 것?지를 설정하는 힌트이다. RULE: 비용을 배제? 실행 계획 생성 COST: 비용을 고려? 실행 계획 생성 질의에 따라 핫상 같은 실행 계획이 생성되길 원?다면 RULE 힌트를 지정하며, 데이터 양의 변경량이 커 조? 순서 등에 ?은 영향을 미?다면 COST를 지정? 주는 것이 좋다. ?당 힌트를 사용하지 않을 경우 기본적으로 비용 기반 최적화가 수행된다. 정규화 형태 정규화 방법을 SQL? 단위로 설정? 수 있게 하는 힌트이다. CNF: Conjunctive Normal Form으로 정규화 Conjunctive Normal Form에서는 AND 연산자가 최상위 레벨의 논리 연산자이고 OR 연산자는 낮은 레벨의 연산자이다. CNF 힌트 사용시 알티베이스는 실행 계획을 생성? 때 SELECT ?을 Conjunctive Normal Form 으로 변??다. 그러나 가끔은 Conjunctive Normal Form으로 변?? 경우 아주 복잡? 조건?로 변?되고 이는 과도? 시스템 자원의 소모를 초래하게 된다. 이런 경우에는 힌트가 지정되었더라도 알티베이스는 CNF 를 사용하지 않는다. DNF: Disjunctive Normal Form으로 정규화 Disjunctive Normal Form에서는 OR 연산자가 최상위 레벨의 논리 연산자이고 AND 연산자는 낮은 레벨의 연산자이다. DNF 힌트를 사용하면 SELECT ?을 Disjunctive Normal Form 으로 변?하는 실행 계획이 생성된다. 따라서 각 조건?은 각자의 ?덱스를 사용하여 따로 처리된다. 단 SQL구?에 어떤 OR ?도 포함되어 있지 않다면, 이 힌트는 무시된다. 또?, 조건?의 속성에 따라서 DNF로 변? 시 너무 ?은 수의 조건?이 생성될 수도 있고 이는 과도? 시스템 자원의 소모를 수반?다. 이런 경우에는 힌트가 지정되었더라도 알티베이스는 DNF 를 사용하지 않는다. 358 Administrators Manual ?당 힌트가 사용되지 않을 경우 두 정규화의 비용 비교를 통하여 하나의 정규화 방법이 선택된다. 조? 순서 조? 순서를 결정하는 힌트이다. ORDERED: FROM?에 나열된 순서대로 조? 순서를 결정 ?당 힌트가 사용되지 않을 경우 비용 비교를 통하여 조? 순서를 결정?다. 조? 방법 조? 방법을 결정하는 힌트이다. USE_NL: Nested loop 조? 계열의 조? 방법을 사용 USE_NL 힌트는 명시된 테이블을 조?하기 위? Nested loop 조?을 사용하도록 지정하는 힌트이다. USE_SORT: Sort-based 조? 계열의 조? 방법을 사용 USE_SORT 힌트는 명시된 테이블을 조?하기 위? Sort 조?을 사용하도록 지정하는 힌트이다. 단 sorting 술어가 하나도 없을 경우 Nested loop 조?이 사용된다. USE_HASH: Hash-based 조? 계열의 조? 방법을 사용 USE_HASH 힌트는 명시된 테이블을 조?하기 위? Hash 조?을 사용하도록 지정하는 힌트이다. 단 hasing 술어가 하나도 없을 경우 Nested loop 조?이 사용된다. USE_MERGE: Merge 조? 조? 계열의 조? 방법을 사용 USE_MERGE 힌트는 명시된 테이블을 조?하기 위? Sort Merge 조?을 사용하도록 지정하는 힌트이다. 단 sorting 술어가 하나도 없을 경우 Nested loop 조?이 사용된다. 조? 방법에 대? 힌트는 조? 방법을 결정하기 위? 다음과 같이 처리된다. Optimizer는 내부 테이블이 나열된 순서로 조? 가능성 여부를 검사?다. 예를 들어, USE_NL(T1, T2) 힌트? 경우 T1 => T2 로의 조? 가능 여부를 검사?다. Optimizer는 내부 테이블이 나열된 역순으로 조? 가능성 여부를 검사?다. 위의 검사에서 ?당 순서로 조?을 적용? 수 없는 경우 그 역순? T2 => T1 의 순서로 조? 가능 여부를 검사?다. 위의 두 경우에 모두 ?당하지 않으면, 비용 비교를 통하여 SQL 튜닝 359 새로? 조? 방법을 선택?다. ORDERED 힌트와 상충되는 경우 예를 들어, 다음과 같은 질의가 있다고 가정하자. SELECT /*+ ORDERED USE_NL(T2, T1) */ FROM T1, T2 WHERE T1.i1 = T2.i1; ORDERED 힌트와 USE_NL 힌트의 테이블 순서는 서로 상충되며 우선 순위에 의하여 ORDERED 힌트를 따르게 된다. 동? 테이블에 대하여 여러 가지 조? 방법 힌트가 지정될 경우 나열된 방법 중 비용 평가를 통? 가장 효율적? 힌트가 선택된다. USE_NL(T1, T2) USE_HASH(T2, T1) 중? 결과 저장 매체 중? 결과를 저장하기 위? 임시 테이블의 저장 매체를 지정하는 힌트이다. TEMP_TBS_MEMORY: 질의 처리 중에 생성되는 모? 중? 결과를 저장하기 위? 메모리 임시 테이블을 사용?다. TEMP_TBS_DISK: 질의 처리 중에 생성되는 모? 중? 결과를 저장하기 위? 디스크 임시 테이블을 사용?다. TEMP_TBS_MEMORY의 경우 저장되는 중? 결과의 크기가 적을 경우에 성능향상을 위? 사용하는 것이 바람직하며, TEMP_TBS_DISK는 성능 저하를 감?하더라도 저장되는 중? 결과의 크기가 매우 큰 경우에 리소스 ?약을 위? 사용하는 것이 바람직하다. ?시 버킷 크기 이 힌트는 ?싱 기법을 사용하는 실행 노드들의 버킷 개수를 조정하기 위하여 사용된다. Optimizer는 GROUP BY, UNION, INTERSECT, MINUS, DISTINCT, HASH JOIN 및 aggregate functions 같은 구?을 처리하기 위? ?싱을 사용?다. ?당된 ?시 버킷의 개수가 처리될 레코드의 개수에 적합하다면 질의 처리 속도가 향상될 것이다. 비용 기반 최적화에서 ?시 버킷의 적?? 개수는 내부적으로 레코드 개수에 기반?서 결정된다. 그러나, 다음의 버킷의 개수를 임의로 지정하고 싶다면 힌트를 사용하면 된다. HASH BUCKET COUNT: HASH와 HSDS 노드의 ?시 버킷 수 변경 GROUP BUCKET COUNT: GRAG와 AGGR 노드의 ?시 버킷 360 Administrators Manual 수 변경 SET BUCKET COUNT: SITS와 SDIF 노드의 ?시 버킷 수 변경 그룹 처리 방법 GROUP BY?의 처리 방법을 지정하기 위하여 사용하는 힌트이다. GROUP_HASH: ?싱 방식에 의? 처리 GROUP_SORT: 정? 방식에 의? 처리 중복 제거 처리 방법 DISTINCT의 처리 방법을 지정하기 위하여 사용하는 힌트이다. DISTINCT_HASH: ?싱 방식에 의? 처리 DISTINCT_SORT: 정? 방식에 의? 처리 뷰 최적화 방법 뷰 외부의 WHERE?의 조건을 뷰 내부에서 처리? 것?지의 여부를 결정하기 위하여 사용하는 힌트이다. NO_PUSH_SELECT_VIEW: 외부의 WHERE ?의 조건을 뷰 내부로 이동하여 처리하지 않는다. PUSH_SELECT_VIEW: 외부의 WHERE ?의 조건 중 가능? 것은 모두 뷰 내부로 이동하여 처리 Push Predicate 방법 뷰 외부의 WHERE?의 조? 조건을 뷰 내부에서 처리? 것?지의 여부를 결정하기 위하여 사용하는 힌트이다. PUSH_PRED: 외부의 WHERE?의 조건 중 뷰와 관계된 조? 조건을 뷰 내부로 이동하여 처리 액세스 방법 테이블 접? 방법을 제어하는 힌트이다. FULL SCAN: 테이블에 이용 가능? ?덱스가 ?재하더라도 ?덱스를 사용하지 않고 테이블 ?체 스캔 INDEX: 나열된 index중 하나를 이용? ?덱스 스캔 INDEX ASC: 나열된 index중 하나를 이용? ?덱스 오름차순 스캔 (ascending index scan) INDEX DESC: 나열된 index중 하나를 이용? ?덱스 내림 차순 스캔 (descending index scan) SQL 튜닝 361 NO INDEX: 나열된 ?덱스들은 최적화 과정에서 배제 뷰 내부에 사용된 테이블의 ?덱스 이름을 위의 힌트 구?에 사용하면, 뷰에 대?서도 ?반 테이블처럼 ?덱스 힌트를 ? 수 있다. 액세스 방법을 제어하는 힌트는 여러 개가 사용될 수 있다. 이들 힌트는 다음과 같은 정책에 의하여 처리된다. 나열된 힌트가 상충하는 경우, 나열된 순서대로 힌트가 적용되고 뒤의 힌트는 무시된다. 예제: INDEX(T1, IDX1) NO INDEX(T1, IDX1) 나열된 힌트가 상충되지 않을 경우 힌트에 나열된 액세스 방법 중 비용 계산에 기반하여 보다 효율적? 액세스 방법이 선택된다. 예제: FULL SCAN(T1), INDEX(T1, IDX1) 액세스 방법 힌트가 조? 방법 힌트와 함께 사용될 경우 액세스 방법 힌트와 조? 방법 힌트는 별개의 것으로 처리된다. 예제: USE_HASH(T1, T2), INDEX(T2, IDX2) ?덱스를 사용하여 접?되며 Hash-based 조? 방법으로 처리된다. Explain Plan 363 12. Explain Plan 364 Administrators Manual 개요 Explain Plan은 알티베이스 HDB 데이터베이스 서버가 최적화된 질의를 실행하기 위? 수행하는 접? 경로를 보여?다. 즉, EXPLAIN PLAN을 ON 또는 ONLY로 설정하고 SQL구?을 실행하면, optimizer는 그 구?을 위? 실행 계획을 결정하고 실행 계획을 설명하는 데이터를 그 SQL?을 실행했던 클라이?트로 반??다. Plan Tree 정의 질의를 최적화하는 것은 SQL?이 얼?나 빨리 실행될 수 있는가에 크게 영향을 ?다. 알티베이스 EXPLAIN PLAN은 서버가 최적화된 질의를 실행하는 방법을 설명?다. 즉 EXPLAIN PLAN은 SQL ?의 성능 향상과 실행 계획 (execution plan, 이하 “plan tree”라 칭함)을 결정하는데 도움을 주기 위? 사용된다. Plan Tree의 이해 ?은 테이블들로부터 데이터를 검색하는 SQL? 실행시, 같은 결과 집합을 얻는 다양? 최적화 방법 (테이블을 조?하는 방법, 조? 순서, 그리고 접? 경로 등)이 사용될 수 있다. 알티베이스 HDB는 다음과 같은 다양? 요소들을 ?거로 적합? 방법을 결정?다. 사용 가능? ?덱스들 SQL? 내에서의 테이블들과 열들의 순서 최적화 기법 EXPLAIN PLAN 프로퍼티를 적?히 설정하면 SQL?의 plan tree를 볼 수 있다. 사용자들은 plan tree를 검사?서 알티베이스 HDB가 SQL?을 어떻게 실행하고 있는가를 정확하게 이?? 수 있다. Plan Tree의 분석 EXPLAIN PLAN 프로퍼티를 적?히 설정하면 SQL?을 직접 실행하지 않고도 plan tree를 볼 수 있으므로, SQL?의 실행 방법을 볼 수 있을 뿐? 아니라 다른 plan tree와 비교? 수도 있어 SQL?의 성능을 향상? 수 있다. Explain Plan 365 Plan tree 에서는 다음과 같은 정보를 얻을 수 있다: Optimizer에 의? 생성된 실행 계획 Objects (테이블, ?덱스, 등)의 속성 사용된 index 사용된 조? 방법 최적화된 조? 순서 성능 분석 개선된 SQL?의 성능을 입증하는 방법은 다음과 같다. 새로? SQL?을 실행하고 그 결과를 이? SQL?의 실행 결과와 비교?다. 새로? plan tree를 생성하고, 그것을 이?의 plan tree와 비교?다. Object(테이블, ?덱스 등)의 속성들이 정확?가를 확?하기 위하여 속성들을 재검토?다. Plan Tree 출력 기능 iSQL에서 다음 구?으로 EXPLAIN PLAN을 적?? 값으로 설정?다. ALTER SESSION SET EXPLAIN PLAN = ON/OFF/ONLY; 그 다음에 SQL?을 실행?다. 다음 EXPLAIN PLAN 옵?에 따라 plan tree를 텍스트 형태로 볼 수 있다. ON 질의 수행 후 plan tree, 레코드 접? 횟수, 및 튜플이 점유? 메모리 양 등을 출력 OFF plan tree 출력하지 않음. ONLY 질의를 실제로 실행하지는 않고, plan tree? 출력 iSQL> ALTER SESSION SET EXPLAIN PLAN = ON; iSQL> SELECT e_firstname, e_lastname FROM employees WHERE emp_job = 'PROGRAMMER'; E_FIRSTNAME E_LASTNAME ----------------------------------------------- Ryu Momoi Elizabeth Bae 2 rows selected. 366 Administrators Manual ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 44 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) ----------------------------------------------------------- - iSQL> ALTER SESSION SET EXPLAIN PLAN = OFF; Alter success. iSQL> SELECT e_firstname, e_lastname FROM employees WHERE emp_job = 'PROGRAMMER'; E_FIRSTNAME E_LASTNAME ----------------------------------------------- Ryu Momoi Elizabeth Bae 2 rows selected. iSQL> ALTER SESSION SET EXPLAIN PLAN = ONLY; Alter success. iSQL> SELECT e_firstname, e_lastname FROM employees WHERE emp_job = 'PROGRAMMER'; E_FIRSTNAME E_LASTNAME ----------------------------------------------- No rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 44 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: ??, SELF_ID: 2 ) ----------------------------------------------------------- - EXPLAN PLAN을 ONLY로 설정하면 질의를 실제로 실행하지 않고 실행 계획? 생성하므로 ACCESS 핫목과 같이 실제 질의가 실행된 후 그 값이 결정되는 핫목들은 물음표(“??”)로 표시된다. Explain Plan 367 Plan Tree 보기 Plan tree는 plan 노드들과 각 노드 ?의 연결 관계로 이루어?다. 자식 노드는 부모 노드보다 ? 칸 아래에 첫머리가 ?으로 들어가 나타난다. 또? subquery는 ::SUB-QUERY BEGIN과 ::SUB- QUERY END 사이에 보여?다. iSQL> SELECT c.cname FROM customer c WHERE c.cno IN (SELECT o.cno FROM orders o WHERE o.ono = 12310001); CNAME ------------------------ DKKIM 1 row selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 22 ) SCAN ( TABLE: CUSTOMER, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 16 ) SCAN ( TABLE: ORDERS, INDEX: __SYS_IDX_ID_69, ACCESS: 20, SELF_ID: 3 ) ::SUB-QUERY END ----------------------------------------------- PROJECT SCAN PROJECT SCAN CUSTOMER ORDERS 1 2 3 4 5 1. orders 테이블에 있는 주? 번호(ono)를 ?덱스를 이용하여 검 색?다. ?덱스를 이용? 접? 회수는 20임을 알 수 있다. ?덱 스가 생성되지 않은 열을 기?으로 orders 테이블을 조회?다면 조건에 ?족하는 열들을 찾기 위?서 ?체 orders 테이블을 스캔 (full scan) ?야 ? 것이다. 즉, 사용자는 full scan을 수행? 것 ?가, ?덱스를 사용?서 scan을 ? 것?가를 plan 노드의 비용 정보를 비교?서 선택? 수 있다. 2. orders 테이블에서 cno? 열을 찾아 열의 개수가 하나? 새로 ? relation1을 ??다. 3. c.cno = o.cno 조건을 ?족하는 레코드를 검색하기 위? ?체 4 3 2 1 368 Administrators Manual customer 테이블을 full scan ?다. access의 회수는 customer 테이블에 있는 레코드 개수(20)?큼이다. 4. customer 테이블에서 cname? 열을 찾아 새로? relation2를 ??다. 5. relation2를 출력?다. Explain Plan 369 Plan Nodes Plan Tree는 특정? SQL?을 위? 생성된 실행 계획이다. Plan Nodes는 Plan tree를 구성하는 각 노드(node)를 의미?다. Plan Node의 종류 Plan Node는 Child Plan의 개수 또는 중? 결과가 물리적으로 저장(materialized) 되는지 여부에 의? 구분된다. Child Node의 개수에 따른 구분 One-child Node Child node가 0개 또는 하나? plan node를 의미?다. Binary Node (Two-child Node) Child node가 두 개? plan node를 의미?다. Multi-child Node Child node가 두 개 이상? plan node를 의미?다. Materialization 여부에 의한 구분 Non-materialized Node 중? 결과를 저장하지 않고, ? 번에 ? 개의 레코드를 처리하는 plan node를 의미?다. Materialized Node 모? Child node를 수행? 결과를 중? 결과로 저장하는 plan node를 의미?다. 370 Administrators Manual Node Non-materialized Materialized Name Meaning Name Meaning One- child 기 본 SCAN Selection SORT Sort FILTER Filter HASH Hash PROJECT Projection 그 룹 GROUPING Group By GROUP- AGGREGATION Group Aggregation AGGREGATION Aggregation COUNT Count(*) 뷰 VIEW View MATERIALIZATI ON View Materialization VIEW-SCAN View Scan 기 타 HIERARCHICAL QUERY Hierarchy DISTINCT Hash Distinct LIMIT-SORT Limit Sort Two- child 조 ? JOIN Join MERGE-JOIN Merge Join LEFT-OUTER- JOIN Left Outer Join FULL-OUTER- JOIN Full Outer Join ANTI-OUTER- JOIN Anti Outer Join 집 합 함 수 BAG-UNION Bag Union SET-INTERSECT Set Intersect SET- DIFFERENCE Set Difference 기 타 CONCATENATI ON Concatenation Multi -child 기 타 PARTITION- COORDINATOR Partition- Coordinator [표 12-1] Plan Node의 종류 AGGREGATION 정의 이 노드는 중복이 제거된 집합(Distinct aggregation) 기능을 Explain Plan 371 수행?다. Aggregation 수행 시 ?자로서 distinct 칼럼이 ?재하면 distinct 대상이 되는 열에서 중복 값을 제거하기 위?서 이 노드가 사용되며, GROUP-AGGREGATION node와는 별도로 수행된다. 형식 AGGREGATION ( ITEM_SIZE: item_size, GROUP_COUNT: group_count ) item_size 저장하는 item의 크기 group_count group의 총 개수 예제 총 부서의 수와 모? 사원들의 평균 급여를 출력하라. iSQL> SELECT COUNT(DISTINCT dno), AVG(salary) FROM employees; COUNT(DISTINCT DNO) AVG(SALARY) ------------------------------------ 8 1836.64706 1 row selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 30 ) AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 1 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 1 ) ----------------------------------------------- ANTI-OUTER-JOIN 정의 FULL-OUTER-JOIN의 빠른 처리를 위? 부가적으로 생성되는 노드이며, binary node 이다. 형식 ANTI-OUTER-JOIN 예제 부서의 위치와 상품을 모아 놓은 장소가 같은 곳의 부서 번호, 부서 이름, 상품 번호를 출력하라. iSQL> CREATE INDEX dep_idx2 ON department(dep_location); Create success. iSQL> CREATE INDEX gds_idx1 ON goods(goods_location); Create success. iSQL> SELECT d.dno, d.dname, g.gno FROM department d FULL OUTER JOIN goods g ON d.dep_location = g.goods_location; 372 Administrators Manual DNO DNAME GNO -------------------------------------------- A001 Applied Technology Team D001 Engine Development Team C001 Marketing Team C002 Planning Management Team F001 Sales Team A111100001 A111100002 B111100001 C111100001 C111100002 D111100001 D111100002 D111100003 D111100004 D111100005 D111100006 D111100007 D111100008 D111100009 D111100010 D111100011 E111100001 E111100002 E111100003 E111100004 E111100005 E111100006 E111100007 E111100008 E111100009 E111100010 E111100011 E111100012 E111100013 F111100001 35 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 29 ) CONCATENATION LEFT-OUTER-JOIN SCAN ( TABLE: DEPARTMENT D, FULL SCAN, ACCESS: 35, SELF_ID: 1 ) SCAN ( TABLE: GOODS G, INDEX: GDS_IDX1, ACCESS: 35, SELF_ID: 2 ) [ VARIABLE KEY ] OR AND D.DEP_LOCATION = G.GOODS_LOCATION ANTI-OUTER-JOIN SCAN ( TABLE: GOODS G, FULL SCAN, ACCESS: 35, SELF_ID: 2 ) SCAN ( TABLE: DEPARTMENT D, INDEX: DEP_IDX2, ACCESS: 35, SELF_ID: 1 ) [ VARIABLE KEY ] OR AND D.DEP_LOCATION = G.GOODS_LOCATION ----------------------------------------------- BAG-UNION Explain Plan 373 정의 Bag Union 기능을 수행하며 두 개 이상의 child node를 갖는 node 이다. SQL? 중 UNION ALL에 ?당?다. 형식 BAG-UNION 예제 직업이 판매원? 사원과 급여가 2000000 보다 큰 모? 사원의 이름과 급여를 출력하라. iSQL> SELECT e_firstname, e_lastname, emp_job, salary FROM employees WHERE emp_job = 'SALES REP' UNION ALL SELECT e_firstname, e_lastname, emp_job, salary FROM employees WHERE salary > 2000; E_FIRSTNAME E_LASTNAME EMP_JOB SALARY ----------------------------------------------------------- ---------------- SANDRA HAMMOND SALES REP 1890 ALVAR MARQUEZ SALES REP 1800 WILLIAM BLAKE SALES REP FARHAD GHORBANI PL 2500 ELIZABETH BAE PROGRAMMER 4000 ZHEN LIU WEBMASTER 2750 YUU MIURA PM 2003 WEI-WEI CHEN MANAGER 2300 8 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 70 ) VIEW ( ACCESS: 8, SELF_ID: 4 ) BAG-UNION PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 70 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 70 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 3 ) ----------------------------------------------------------- - CONCATENATION 정의 OR 조건(DNF)의 빠른 처리를 위? 노드이다. 이 노드는 바이너리 노드로 left child와 right child를 순차적으로 수행?다. 또?, 이 374 Administrators Manual 노드는 Full Outer Join을 위? concatenation을 수행?다. 형식 CONCATENATION 예제 ANTI-OUTER-JOIN node의 예제를 참고하기 바?다. COUNT 정의 COUNT(*)의 빠른 처리를 위? 노드이다. 형식 1) ?덱스가 사용되는 경우: COUNT (TABLE: tbl_name, INDEX: index_name, ACCESS: acc_num, SELF_ID: node_id, REF_ID: ref_id ) 2) ?덱스가 사용되지 않는 경우: COUNT (TABLE: tbl_name, FULL SCAN, ACCESS: acc_num, SELF_ID: node_id, REF_ID: ref_id ) table_name 테이블 이름 FULL SCAN ?덱스 사용 ?함 index_name 사용되는 ?덱스 acc_num 레코드 접? 횟수 node_id tuple set 내에서의 ID (노드의 ID로 ?주) ref_id 참조하는 노드 ID 예제 사원의 총 수를 계산하라. iSQL> SELECT COUNT(*) rec_count FROM employees; REC_COUNT ----------------------- 20 1 row selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) COUNT ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 1, SELF_ID: 1, REF_ID: 1 ) ----------------------------------------------- Explain Plan 375 DISTINCT 정의 DISTINCT 연산을 수행하는 materialized node 이다. 형식 1) 중? 결과가 메모리에 저장되는 경우 DISTINCT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) 2) 중? 결과가 디스크에 저장되는 경우 DISTINCT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장? item의 개수 bucket_count hash bucket의 개수 page_count page의 개수 acc_num 레코드 접? 횟수 self_id node ID ref_id 참조하는 node의 ID 예제 상품 C111100001을 주?? 고객의 이름을 출력하라. iSQL> SELECT DISTINCT customers.c_firstname||customers.c_lastname cname FROM customers WHERE customers.cno IN (SELECT orders.cno FROM orders WHERE orders.gno = 'C111100001 '); CNAME -------------------------------------------- Pierre Martin Fyodor Fedorov Phil Dureault Estevan Sanchez 4 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 42 ) DISTINCT ( ITEM_SIZE: 64, ITEM_COUNT: 4, BUCKET_COUNT: 1024, ACCESS: 4, SELF_ID: 6, REF_ID: 2 ) SCAN ( TABLE: CUSTOMERS, INDEX: __SYS_IDX_ID_224, ACCESS: 4, SELF_ID: 2 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) DISTINCT ( ITEM_SIZE: 24, ITEM_COUNT: 4, BUCKET_COUNT: 1024, ACCESS: 8, SELF_ID: 5, REF_ID: 3 ) 376 Administrators Manual VIEW ( ACCESS: 4, SELF_ID: 4 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) SCAN ( TABLE: ORDERS, INDEX: ODR_IDX3, ACCESS: 4, SELF_ID: 3 ) ::SUB-QUERY END ----------------------------------------------------------- - FILTER 정의 이 노드는 Selection 기능을 수행하며 하위 node로부터 반?된 결과가 어떤 조건에 맞는지를 검사?다. 형식 FILTER 예제 2개 이상 주?된 상품의 상품번호와 주?양을 출력하라. iSQL> SELECT gno, COUNT(*) FROM orders GROUP BY gno HAVING COUNT(*) > 2; GNO COUNT ------------------------------------ A111100002 3 C111100001 4 D111100008 3 E111100012 3 4 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) FILTER AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 16 ) GROUPING SCAN ( TABLE: ORDERS, INDEX: ODR_IDX3, ACCESS: 30, SELF_ID: 2 ) ----------------------------------------------- FULL-OUTER-JOIN 정의 Full Outer Join 기능을 수행하며, binary node 이다. Explain Plan 377 형식 FULL-OUTER-JOIN 예제 부서의 위치와 상품을 모아 놓은 장소가 같은 곳의 부서 번호, 부서 이름, 상품 번호를 출력하라. iSQL> INSERT INTO department VALUES(BYTE'F002', 'headquarters', 'CE0002', 100); 1 row inserted. iSQL> SELECT d.dno, d.dname, g.gno FROM department d FULL OUTER JOIN goods g ON d.dep_location = g.goods_LOCATION; DNO DNAME GNO -------------------------------------------- A111100001 A111100002 B111100001 C111100001 C111100002 D111100001 D111100002 D111100003 D111100004 D111100005 D111100006 D111100007 D111100008 D111100009 D111100010 D111100011 E111100001 E111100002 E111100003 E111100004 F002 headquarters E111100005 E111100006 E111100007 E111100008 E111100009 E111100010 E111100011 E111100012 E111100013 F111100001 A001 Applied Technology Team D001 Engine Development Team C002 Planning Management Team C001 Marketing Team F001 Sales Team B001 Quality Assurance 36 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 29 ) FULL-OUTER-JOIN SCAN ( TABLE: GOODS G, FULL SCAN, ACCESS: 36, SELF_ID: 2 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 7, BUCKET_COUNT: 1024, ACCESS: 36, SELF_ID: 3, REF_ID: 1 ) SCAN ( TABLE: DEPARTMENT D, FULL SCAN, ACCESS: 36, SELF_ID: 1 ) 378 Administrators Manual ----------------------------------------------- GROUP-AGGREGATION 정의 이 노드는 Group aggregation 기능을 수행하며 materialized node 이다. 형식 1) 중? 결과가 메모리에 저장되는 경우 GROUP-AGGREGATION ( ITEM_SIZE: item_size, GROUP_COUNT: group_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) 2) 중? 결과가 디스크에 저장되는 경우 GROUP-AGGREGATION ( ITEM_SIZE: item_size, GROUP_COUNT: group_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 group_count 저장? group의 개수 bucket_count Hash bucket의 개수 page_count Page의 개수 acc_num 레코드 접? 횟수 self_id node ID ref_id 참조하는 node ID 예제 각 부서내의 각 직위에 대? 지급되는 급여 총액을 출력하라. (여러 열에 GROUP BY ?을 사용) iSQL> SELECT dno, emp_job, COUNT(emp_job) num_emp, SUM(salary) sum_sal FROM employees GROUP BY dno, emp_job; DNO EMP_JOB NUM_EMP SUM_SAL ----------------------------------------------- . . . 16 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 55 ) GROUP-AGGREGATION ( ITEM_SIZE: 56, GROUP_COUNT: 16, BUCKET_COUNT: 1024, ACCESS: 16, SELF_ID: 2, REF_ID: 1 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 1 ) Explain Plan 379 ----------------------------------------------------------- - GROUPING 정의 이 노드는 하위 노드으로부터 가져온 데이터가 이? 데이터와 동?? 그룹에 속하는지 검사?다. 형식 GROUPING 예제 각 사원이 담당하는 고객들의 수와 각 고객에게 판매? 상품의 총 수를 출력하라. iSQL> SELECT eno, COUNT(DISTINCT cno), SUM(qty) FROM orders GROUP BY eno; ENO COUNT(DISTINCT CNO) SUM(QTY) ----------------------------------------------- 12 8 17870 19 5 25350 20 4 13210 3 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 24 ) AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 3 ) GROUPING SCAN ( TABLE: ORDERS, INDEX: ODR_IDX1, ACCESS: 30, DISK_PAGE_COUNT: 2, SELF_ID: 1 ) ----------------------------------------------- HASH 정의 이 노드는 Hash Search 기능을 수행하며, materialized node 이다. 형식 1) 중? 결과가 메모리에 저장될 경우 380 Administrators Manual HASH ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) 2) 중? 결과가 디스크에 저장될 경우 HASH ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장? item의 개수 bucket_count hash bucket의 개수 page_count page의 개수 acc_num 레코드 접? 횟수 self_id tuple set 내의 ID. node ID로 봐도 무방 ref_id 참조하는 node의 ID 예제 모? 부서 관리자의 이름과 부서 이름을 출력하라. iSQL> CREATE TABLE manager( eno INTEGER PRIMARY KEY, mgr_no INTEGER, mname VARCHAR(20), address VARCHAR(60)) TABLESPACE user_data; Create success. iSQL> INSERT INTO manager VALUES(2, 1, 'HJNO', '11 Inyoung Bldg. Nonhyun-dong Kangnam-guSeoul, Korea'); 1 row inserted. iSQL> INSERT INTO manager VALUES(7, 2, 'HJMIN', '44-25 Youido-dong Youngdungpo-gu Seoul, Korea'); 1 row inserted. iSQL> INSERT INTO manager VALUES(8, 7, 'JDLEE', '3101 N. Wabash Ave. Brooklyn, NY'); 1 row inserted. iSQL> INSERT INTO manager VALUES(12, 7, 'MYLEE', '130 Gongpyeongno Jung-gu Daegu, Korea'); 1 row inserted. iSQL> SELECT m.mname, d.dname FROM department d, manager m WHERE d.mgr_no = m.mgr_no; MNAME DNAME ----------------------------------------------- HJNO Application Technology Team 1 row selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 44 ) JOIN SCAN ( TABLE: DEPARTMENT D, FULL SCAN, ACCESS: 5, DISK_PAGE_COUNT: 2, SELF_ID: 1 ) HASH ( ITEM_SIZE: 32, ITEM_COUNT: 4, DISK_PAGE_COUNT: 4, ACCESS: 2, SELF_ID: 3, REF_ID: 2 ) SCAN ( TABLE: MANAGER M, FULL SCAN, ACCESS: 4, DISK_PAGE_COUNT: 2, SELF_ID: 2 ) ----------------------------------------------- Explain Plan 381 HIERARCHICAL QUERY 정의 이 노드는 계층적 질의(hierarchical query)를 처리하는 노드이다. 형식 1) ?덱스가 사용되는 경우 HIER ( TABLE: table_name, FULL SCAN, ACCESS: acc_num, SELF_ID: node_id ) 2) ?덱스가 사용되지 않는 경우 HIER ( TABLE: table_name, INDEX: index_name, ACCESS: acc_num, SELF_ID: node_id ) table_name 테이블 이름 FULL SCAN ?덱스 사용 ?함 index_name 사용하는 ?덱스 acc_num 레코드 접? 횟수 node_id tuple set 내에서의 ID (node의 ID로 ?주) 예제 ID 칼럼의 값이 0? 행을 루트로 하여 계층적으로 연결된 행들을 얻기 위? 계층적 질의?은 다음과 같다. iSQL> CREATE TABLE hier_order(id INTEGER, parent INTEGER); Create success. iSQL> INSERT INTO hier_order VALUES(0, NULL); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(1, 0); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(2, 1); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(3, 1); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(4, 1); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(5, 0); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(6, 0); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(7, 6); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(8, 7); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(9, 7); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(10, 6); 1 row inserted. iSQL> SELECT id, parent, level FROM hier_order START WITH id = 0 CONNECT BY PRIOR id = parent ORDER BY level; ID PARENT LEVEL ----------------------------------------------- 382 Administrators Manual 0 1 6 0 2 5 0 2 1 0 2 10 6 3 4 1 3 7 6 3 3 1 3 2 1 3 8 7 4 9 7 4 11 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 16 ) SORT ( ITEM_SIZE: 24, ITEM_COUNT: 11, ACCESS: 11, SELF_ID: 5, REF_ID: 2 ) HIER ( TABLE: HIER_ORDER, FULL SCAN, ACCESS: 132, SELF_ID: 2 ) SCAN ( TABLE: HIER_ORDER, FULL SCAN, ACCESS: 132, SELF_ID: 2 ) ----------------------------------------------- Explain Plan 383 0, NULL 1, 0 5, 0 6, 0 2, 1 3, 1 4, 1 7, 6 10, 6 8, 7 9, 7 Level 3 4 2 1 < 계층적 leaf 구조 > 루트/부모 부모/자식 자식/리프 부모/자식 자식/리프 자식/리프 자식/리프 자식/리프 자식/리프 자식/리프 부 모 / 자 식 JOIN 정의 이 노드는 교차 곱(Cartesian Product )기능을 수행?다. JOIN 조건은 right child가 수행?다. 형식 JOIN 예제 성(last name)이 Marquez? 직원의 직원 번호, 주? 번호, 상품 번호, 주?양을 출력하라. iSQL> SELECT e.eno, ono, cno, gno, qty FROM employees e, orders o WHERE e.eno = o.eno AND e.e_lastname = 'Marquez'; ENO ONO CNO GNO QTY ----------------------------------------------------------- ---------------- 19 11290100 11 E11110000 1500 19 12100277 5 D111100008 2500 384 Administrators Manual 19 12300001 1 D111100004 1000 19 12300005 4 D111100008 4000 19 12300010 16 D111100010 2000 19 12310004 5 E111100010 5000 19 12310008 1 D111100003 100 19 12310011 15 E111100012 10000 19 12310012 1 C111100001 250 9 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 5, TUPLE_SIZE: 40 ) JOIN SCAN ( TABLE: EMPLOYEES E, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) SCAN ( TABLE: ORDERS O, INDEX: ODR_IDX1, ACCESS: 9, SELF_ID: 3 ) ----------------------------------------------------------- - LEFT-OUTER-JOIN 정의 이 노드는 Left-Outer Join 기능을 수행하며, binary node 이다. 형식 LEFT-OUTER-JOIN 예제 모? 부서에 대? 부서 번호와 모? 사원 이름을 출력하라. (사원이 ?혀 없는 부서 번호 5001도 출력된다.) iSQL> INSERT INTO departments VALUES(5001, 'Quality Assurance', 'Mokpo', 22); 1 row inserted. iSQL> SELECT d.dno, e.e_firstname, e.e_lastname FROM departments d LEFT OUTER JOIN employees e ON d.dno = e.dno ORDER BY d.dno; DNO E_FIRSTNAME E_LASTNAME ----------------------------------------------------------- - 1001 Ken Kobain 1001 Wei-Wei Chen 1002 Ryu Momoi 1002 Mitch Jones 1003 Elizabeth Bae 1003 Zhen Liu 1003 Yuu Miura 1003 Jason Davenport Explain Plan 385 2001 Takahiro Fubuki 3001 Aaron Foster 3002 Chan-seung Moon 3002 Farhad Ghorbani 4001 Xiong Wang 4001 Curtis Diaz 4001 John Huxley 4002 Gottlieb Fleischer 4002 Sandra Hammond 4002 Alvar Marquez 4002 William Blake 5001 20 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 46 ) LEFT-OUTER-JOIN SCAN ( TABLE: DEPARTMENTS D, INDEX: __SYS_IDX_ID_137, ACCESS: 9, SELF_ID: 1 ) SCAN ( TABLE: EMPLOYEES E, INDEX: EMP_IDX1, ACCESS: 20, SELF_ID: 2 ) ----------------------------------------------------------- - LIMIT-SORT 정의 이 노드는 Limit Sorting을 수행?다. 모? 데이터를 저장 ? 필요가 없으므로 ?정? 저장 공??을 사용하여 정??다.. 형식 LIMIT-SORT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, STORE_COUNT: store_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장? item의 개수 store_count 실제 정?된 item의 개수 acc_num 레코드 접? 횟수 self_id tuple set 내의 ID, node ID로 봐도 무관 ref_id 참조하는 node의 ID 예제 모? 사원의 이름, 부서 번호 및 급여를 표시하고 부서 번호와 급여를 기?(부서 번호는 올림차순, 그리고 급여는 내림차순으로)으로 정??서 상위 10개? 출력하라. (ORDER BY ?의 목록의 순서가 정? 순서이다.) iSQL> SELECT e_firstname, e_lastname, dno, salary FROM employees ORDER BY dno, salary DESC 386 Administrators Manual LIMIT 10; E_FIRSTNAME E_LASTNAME DNO SALARY ----------------------------------------------------------- -------------- Wei-Wei Chen 1001 2300 Ken Kobain 1001 2000 Ryu Momoi 1002 1700 Mitch Jones 1002 980 Elizabeth Bae 1003 4000 Zhen Liu 1003 2750 Yuu Miura 1003 2003 Jason Davenport 1003 1000 Takahiro Fubuki 2001 1400 Aaron Foster 3001 1800 10 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 55 ) LIMIT-SORT ( ITEM_SIZE: 16, ITEM_COUNT: 20, STORE_COUNT: 10, ACCESS: 10, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 0 ) ----------------------------------------------------------- - MATERIALIZATION 정의 뷰의 빠른 처리를 위? 생성되는 노드이다. 하위 VIEW node에 의? 생성된 레코드를 하나의 가상 테이블(즉 뷰)로 저장?다. 형식 MATERIALIZATION ( ACCESS: acc_num, SELF_ID: self_id ) acc_num 레코드 접? 횟수 self_id node ID 예제 자?이 속? 부서의 평균 급여보다는 ?은 급여를 받고, 가장 높은 평균 급여를 갖는 부서의 평균 급여보다는 적게 받는 사원의 이름, 부서 번호, 급여를 출력하라. iSQL> CREATE VIEW v1 AS (SELECT dno, AVG(salary) avg_sal FROM employees GROUP BY dno); Create success. iSQL> SELECT e_firstname, e_lastname, e.dno, e.salary FROM employees e, v1 WHERE e.dno = v1.dno AND e.salary > v1.avg_sal AND e.salary < (SELECT MAX(avg_sal) FROM v1); E_FIRSTNAME E_LASTNAME DNO SALARY Explain Plan 387 ----------------------------------------------------------- -------------- Wei-Wei Chen 1001 2300 Ryu Momoi 1002 1700 John Huxley 4001 1900 Sandra Hammond 4002 1890 Alvar Marquez 4002 1800 5 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 55 ) JOIN VIEW-SCAN ( VIEW: V1, ACCESS: 9, SELF_ID: 3 ) MATERIALIZATION ( ITEM_SIZE: 40, ITEM_COUNT: 9 ) VIEW ( ACCESS: 9, SELF_ID: 8 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 25 ) AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 9 ) GROUPING SCAN ( TABLE: EMPLOYEES, INDEX: EMP_IDX1, ACCESS: 20, SELF_ID: 2 ) SCAN ( TABLE: EMPLOYEES E, INDEX: EMP_IDX1, ACCESS: 19, SELF_ID: 1 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 23 ) STORE ( ITEM_SIZE: 32, ITEM_COUNT: 1, ACCESS: 14, SELF_ID: 12, REF_ID: 5 ) VIEW ( ACCESS: 1, SELF_ID: 11 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 23 ) GROUP-AGGREGATION ( ITEM_SIZE: 40, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 10, REF_ID: 5 ) VIEW-SCAN ( VIEW: V1, ACCESS: 9, SELF_ID: 5 ) ::SUB-QUERY END ----------------------------------------------------------- - MERGE-JOIN 정의 이 노드는 Merge Join 기능을 수행?다. 형식 MERGE-JOIN 예제 2010년 1월 1? 이?에 입사? 모? 사원의 사원번호, 이름, 소속된 부서의 부서 번호와 부서 이름을 출력하라. (두 테이블 모두 조? 술어와 관?된 칼럼에 ?덱스가 ?재하여야 ?다. ?덱스 스캔을 하므로 이 노드의 좌, 우 노드들(SCAN node)로부터 dno 값으로 정?되어 레코드가 반?된다. 따라서, 두 값의 대소 차이가 발생하는 이후의 레코드는 검색하지 않고 다시 같은 값을 가지는 레코들를 ?날 때까지 두 테이블의 커서를 이동하여 검색?다.) 388 Administrators Manual iSQL> SELECT e.eno, e_lastname, d.dno, dname FROM employees e, departments d WHERE e.dno = d.dno AND TO_CHAR(join_date, 'YYYY-MM-DD HH:MI:SS') < '2010-01- 01 00:00:00'; ENO E_LASTNAME DNO DNAME ----------------------------------------------------------- ---------------- 5 Ghorbani 3002 PRESALES DEPT 8 Wang 4001 MARKETING DEPT 18 Huxley 4001 MARKETING DEPT 7 Fleischer 4002 BUSINESS DEPT 12 Hammond 4002 BUSINESS DEPT 20 Blake 4002 BUSINESS DEPT 6 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 60 ) MERGE-JOIN SCAN ( TABLE: DEPARTMENTS D, INDEX: __SYS_IDX_ID_137, ACCESS: 9, SELF_ID: 3 ) SCAN ( TABLE: EMPLOYEES E, INDEX: EMP_IDX1, ACCESS: 19, SELF_ID: 2 ) ----------------------------------------------------------- - PROJECT 정의 이 노드는 Projection 기능을 수행하며, 지정? 칼럼들을 추출? 낸다. 형식 PROJECT ( COLUMN_COUNT: col_count, TUPLE_SIZE: tuple_size ) col_count 칼럼들의 개수 tuple_size projection에 의? 선택된 tuple의 실제크기 예제 ? 사원의 급여를 10% ?상 시 ? 사원의 이름과 급여를 출력하라. iSQL> SELECT e_firstname, e_lastname, salary * 1.1 FROM employees; E_FIRSTNAME E_LASTNAME SALARY * 1.1 ----------------------------------------------------------- -- . . . 20 rows selected. ----------------------------------------------------------- - Explain Plan 389 PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 67 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) ----------------------------------------------------------- - SCAN 정의 이 노드는 Selection 기능을 수행하며, Key Range, Filter등을 사용? 조건에 맞는 레코드를 테이블에서 검색?다. 형식 1) 중? 결과가 메모리에 저장될 경우 SCAN ( TABLE: table_name, FULL SCAN, ACCESS: acc_num, SELF_ID: node_id ) SCAN ( TABLE: table_name, INDEX: index_name, ACCESS: acc_num, SELF_ID: node_id ) 2) 중? 결과가 디스크에 저장될 경우 SCAN ( TABLE: table_name, FULL SCAN, ACCESS: acc_num, DISK_PAGE_COUNT: page_count, SELF_ID: node_id ) SCAN ( TABLE: table_name, INDEX: index_name, ACCESS: acc_num, DISK_PAGE_COUNT: page_count, SELF_ID: node_id ) table_name 테이블 이름 FULL SCAN ?덱스 사용 ?함 index_name 사용하는 ?덱스 acc_num 레코드 접? 횟수 page_count 페이지의 개수 node_id tuple set 내에서의 ID (node의 ID로 ?주) 예제 예제1) 1980년 1월 1? 이?에 태어난 모? 사원들의 이름, 부서 번호, 생?을 출력하라. iSQL> SELECT e_firstname, e_lastname, dno, birth FROM employees WHERE birth > '800101'; E_FIRSTNAME E_LASTNAME DNO BIRTH ----------------------------------------------------------- ---------- Aaron Foster 3001 820730 Gottlieb Fleischer 4002 840417 Xiong Wang 4001 810726 Sandra Hammond 4002 810211 Mitch Jones 1002 801102 Jason Davenport 1003 901212 390 Administrators Manual 6 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 54 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) ----------------------------------------------------------- - 예제2) 1980년 1월 1? 이?에 태어난 모? 사원들의 이름, 부서 번호, 생?을 출력하라. (?덱스를 이용하라.) iSQL> CREATE INDEX emp_idx2 ON employees(birth); Create success. iSQL> SELECT e_firstname, e_lastname, dno, birth FROM employees WHERE birth > '800101'; E_FIRSTNAME E_LASTNAME DNO BIRTH ----------------------------------------------------------- ---------- Mitch Jones 1002 801102 Sandra Hammond 4002 810211 Xiong Wang 4001 810726 Aaron Foster 3001 820730 Gottlieb Fleischer 4002 840417 Jason Davenport 1003 901212 6 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 54 ) SCAN ( TABLE: EMPLOYEES, INDEX: EMP_IDX2, ACCESS: 6, SELF_ID: 2 ) ----------------------------------------------------------- - SET-DIFFERENCE 정의 이 노드는 Set Difference 기능을 수행?다. 이 노드는 binary node이며 materialized node 이다. 이 노드는 SQL?의 MINUS 처리에 사용된다. 형식 1) 중? 결과가 메모리에 저장될 경우 SET-DIFFERENCE ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, L_REF_ID: l_ref_id, R_REF_ID: r_ref_id ) 2) 중? 결과가 디스크에 저장될 경우 SET-DIFFERENCE ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: Explain Plan 391 acc_num, SELF_ID: self_id, L_REF_ID: l_ref_id, R_REF_ID: r_ref_id ) item_size 저장하는 item의 크기 item_count 저장? item의 개수 bucket_count hash bucket의 개수 page_count page의 개수 acc_num 레코드 접? 횟수 self_id node ID l_ref_id Left 참조 node ID. ?약 independent 하면 left-child의 data를 다시 저장? 필요가 없음. r_ref_id Right 참조 node ID. ?약 independent 하면 right-child의 data를 다시 저장? 필요가 없음. 예제 주?되지 않은 상품들의 상품번호를 출력하라. iSQL> SELECT gno FROM goods MINUS SELECT gno FROM orders; GNO -------------- A111100001 B111100001 C111100002 D111100001 D111100005 D111100006 D111100007 E111100006 D111100009 E111100003 E111100004 E111100005 E111100008 E111100011 14 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 5 ) VIEW ( ACCESS: 14, SELF_ID: 2 ) SET-DIFFERENCE ( ITEM_SIZE: 24, ITEM_COUNT: 30, DISK_PAGE_COUNT: 29, ACCESS: 14, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 5 ) SCAN ( TABLE: GOODS, FULL SCAN, ACCESS: 30, DISK_PAGE_COUNT: 2, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 5 ) SCAN ( TABLE: ORDERS, FULL SCAN, ACCESS: 30, DISK_PAGE_COUNT: 2, SELF_ID: 1 ) ----------------------------------------------- SET-INTERSECT 392 Administrators Manual 정의 이 노드는 Set Intersection 기능을 수행?다. 이 노드는 binary node이며 materialized node 이다. 이 노드는 SQL?의 INTERSECT처리를 위? 사용된다. 형식 1) 중? 결과가 메모리에 저장될 경우 SET-INTERSECT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, L_REF_ID: l_ref_id, R_REF_ID: r_ref_id ) 2) 중? 결과가 디스크에 저장될 경우 SET-INTERSECT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, L_REF_ID: l_ref_id, R_REF_ID: r_ref_id ) item_size 저장하는 item의 크기 item_count 저장? item의 개수 bucket_count hash bucket의 개수 page_count page의 개수 acc_num 레코드 접? 횟수 self_id node ID l_ref_id Left 참조 node ID. ?약 independent 하면 left-child의 data를 다시 저장? 필요가 없음. r_ref_id Right 참조 node ID. ?약 independent 하면 right-child의 data를 다시 저장? 필요가 없음. 예제 goods 테이블에서 ? 번이라도 주?된 아이템의 목록을 출력하라. iSQL> SELECT gno FROM goods INTERSECT SELECT gno FROM orders; GNO -------------- A111100002 E111100001 D111100008 D111100004 C111100001 E111100002 D111100002 D111100011 D111100003 D111100010 E111100012 F111100001 E111100009 E111100010 Explain Plan 393 E111100007 E111100013 16 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 12 ) VIEW ( ACCESS: 16, SELF_ID: 2 ) SET-INTERSECT ( ITEM_SIZE: 32, ITEM_COUNT: 30, BUCKET_COUNT: 1024, ACCESS: 16, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 12 ) SCAN ( TABLE: GOODS, FULL SCAN, ACCESS: 30, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 12 ) SCAN ( TABLE: ORDERS, FULL SCAN, ACCESS: 30, SELF_ID: 1 ) ----------------------------------------------------------- - SORT 정의 이 노드는 Sorting 기능을 수행하며 materialized node 이다. 형식 1) 중? 결과가 메모리에 저장될 경우 SORT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) 2) 중? 결과가 디스크에 저장될 경우 SORT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장? item의 개수 page_count page의 개수 acc_num 레코드 접? 횟수 self_id Tuple set 내의 ID (node ID로 봐도 무방) ref_id 참조하는 node ID로 Dependency 검사 대상 Node * Dependency? Materialized node에 저장된 데이터의 유효성을 판단하는 기?이다. ?약 참조하는 node가 dependant node이면, 다시 수행하여 결과를 구?야 하며, independent node이면 결과가 동?? 것이기 때?에 다시 수행? 필요가 없다. 394 Administrators Manual 예제 월 급여가 $1500 USD 이하? 직원의 이름, 업무, 입사?, 급여를 급여 순서로 정?하라. iSQL> SELECT e_firstname, e_lastname, emp_job, salary FROM employees WHERE salary < 1500 ORDER BY 4 DESC; E_FIRSTNAME E_LASTNAME EMP_JOB SALARY ----------------------------------------------------------- ----------------- Takahiro Fubuki PM 1400 Curtis Diaz planner 1200 Jason Davenport webmaster 1000 Mitch Jones PM 980 Gottlieb Fleischer manager 500 5 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 70 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 5, ACCESS: 5, SELF_ID: 3, REF_ID: 2 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) ----------------------------------------------------------- - VIEW 정의 In-line View들을 처리하기 위? node 이다. 이 노드는 Projection에 ?당하는 칼럼들을 연속된 칼럼으로 구성된 가상 레코드로 ?식하도록 하기 위?서 사용된다. 형식 VIEW ( ACCESS: acc_num, SELF_ID: self_id ) acc_num 레코드 접? 횟수 self_id node ID 예제 자?이 속? 부서의 평균 급여보다 급여를 ?이 받는 모? 사원의 이름, 급여, 부서 번호 및 그 부서의 평균 급여를 출력하라. iSQL> SELECT e.e_firstname, e.e_lastname, e.salary, e.dno, v1.salavg FROM employees e, (SELECT dno, AVG(salary) salavg FROM employees GROUP BY dno) v1 Explain Plan 395 WHERE e.dno = v1.dno AND e.salary > v1.salavg; E_FIRSTNAME E_LASTNAME SALARY DNO SALAVG ----------------------------------------------------------- ---------------- Wei-Wei Chen 2300 1001 2150 Ryu Momoi 1700 1002 1340 Elizabeth Bae 4000 1003 2438.25 Zhen Liu 2750 1003 2438.25 John Huxley 1900 4001 1550 Sandra Hammond 1890 4002 1396.66667 Alvar Marquez 1800 4002 1396.66667 7 rows selected. ----------------------------------------------------------- - PROJECT ( COLUMN_COUNT: 5, TUPLE_SIZE: 79 ) JOIN VIEW ( ACCESS: 9, SELF_ID: 3 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 25 ) AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 9 ) GROUPING SCAN ( TABLE: EMPLOYEES, INDEX: EMP_IDX1, ACCESS: 20, SELF_ID: 2 ) SCAN ( TABLE: EMPLOYEES E, INDEX: EMP_IDX1, ACCESS: 19, SELF_ID: 1 ) ----------------------------------------------------------- - VIEW-SCAN 정의 이 노드는 MATERIALIZATION node에 의? 생성된 가상 테이블(즉, 뷰)에 대? scan 기능을 수행?다. 형식 VIEW-SCAN ( VIEW: view_name, SELF_ID: self_id ) view_name 뷰 이름 self_id node ID 예제 MATERIALIZATION Node 의 설명을 참고하기 바?다. PARTITION-COORDINATOR 396 Administrators Manual 정의 파티?드 테이블의 각각의 파티?에 대? 스캔을 관리하는 노드이다. 여러 개의 자식 노드를 가지며, 파티? 필터릿을 수행?다. 형식 PARTITION-COORDINATOR( TABLE: table_name, PARTITION: partition_acc_cnt, ACCESS: acc_num,SELF_ID: self_id ) table_name 테이블 이름 partition_acc_cnt 접?? 파티?의 개수 acc_num 접?? 레코드의 개수 self_id node ID 예제 iSQL> CREATE TABLE t1 ( i1 INTEGER ) PARTITION BY RANGE ( i1 ) ( PARTITION p1 VALUES LESS THAN ( 100 ), PARTITION p2 VALUES LESS THAN ( 200 ), PARTITION p3 VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; Create success. iSQL> INSERT INTO t1 VALUES ( 50 ); 1 row inserted. iSQL> INSERT INTO t1 VALUES ( 60 ); 1 row inserted. iSQL> INSERT INTO t1 VALUES ( 150 ); 1 row inserted. iSQL> INSERT INTO t1 VALUES ( 160 ); 1 row inserted. iSQL> alter session set explain plan = on; Alter success. iSQL> SELECT COUNT(*) FROM t1 WHERE i1 < 100; COUNT ----------------------- 2 1 row selected. -------------------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 2 ) PARTITION-COORDINATOR ( TABLE: T1, PARTITION: 1/3, ACCESS: 2, SELF_ID: 2 ) SCAN ( PARTITION: P1, FULL SCAN, ACCESS: 2, DISK_PAGE_COUNT: 2, SELF_ID: 3 ) -------------------------------------------------------- SQL Plan Cache 397 13. SQL Plan Cache 이 장은 알티베이스 SQL Plan Cache 기능에 대? 개념 및 특징에 대? 설명?다. 398 Administrators Manual 개요 알티베이스 SQL Plan Cache 기능의 목적은 SQL ? 수행시 필요? 실행 계획을 세? ?에 공유하는데 있다. 공유된 실행 계획(SQL Plan)이 실행될 때에는 Execution Context (이?에 실행되었던 상황에 대? 정보)가 재사용될 수 있다. SQL Plan Cache의 구조 S Checkpoint Image Stable Log Disk Tablespace Shared SQL Plan Cache Stored Procedure Cache Meta Cache Memory TablespaceLog BuferDisk Buffer Stable Storage Physical MemoryCache [그림 13-1] 알티베이스 공유 캐쉬 구성도 알티베이스 HDB는 모? 세?이 공유하는 캐쉬(cache) 영역을 가지고 있다. 캐쉬 영역은 SQL Plan Cache, Stored Procedure Cache, Meta Cache로 구성된다. 새로? SQL 실행 계획이 생성될 때?다 실행 계획은 SQL Plan Cache 영역에 저장되며 모? 세?이 이를 공유하게 된다. 그리고, 저장 프로시저의 실행 계획이 새로 생성될 때 Stored Procedure Cache 영역에 저장되어 공유된다. 데이터베이스 객체에 대? 모? 정보를 수록하고 있는 메타 데이터는 빠른 접?을 위?서 Meta Cache에 저장된다. 장점 알티베이스 SQL Plan Cache를 사용함으로써 다음과 같은 몇 가지 SQL Plan Cache 399 장점을 얻을수 있다. Direct Execution 의 성능 향상 (Direct Execution은 SQL?을 수행하는 가장 기본적? 방법이다. 응용프로그램은 SQL?을 가지는 ?자열을 ?들어 이를 SQLExecDirect 함수를 사용?서 실행?다.) Direct Execution 위주의 퀴리가 자주 발생하는 ?경에서는 이미 prepare가 된 플?이 공유되어 재사용되기 때?에 prepare 비용을 ??수 있어 성능이 향상된다. Prepare Execution? 사용하는 ?경에서 Prepare Memory의 대폭적? ?감 (Prepare Execution은 반복 수행되는 SQL 구?의 수행 비용을 ?? 수 있는 방법이다.) 또? Prepare Execute? 쓰는 ?경에서는 prepare 비용 ?감뿐 아니라 prepare에 필요? 메모리까지 ?? 수 있는 효과를 얻는다.. SQL Plan Cache 사용 구문 SQL Plan Cache 기능이 적용되는 SQL 구?은 다음과 같다. 각 구?에 대? 상세? 설명은 SQL Reference 를 참조?다. SELECT (SELECT FOR UPDATE) INSERT (INSERT SELECT) UPDATE DELETE MOVE ENQUEUE DEQUEUE 400 Administrators Manual SQL Plan Cache의 특징 알티베이스 SQL Plan Cache의 특징을 살펴보면 다음과 같다. 플? 공유에 중점을 둔 체크-?(check-in) 방식이 사용된다. SQL Plan Cache의 교체 정책은 최? 사용도뿐? 아니라 참조횟수(frequency)까지 고려?다. 파싱 비용을 ?이기 위?서 SQL ?장이 반드시 같아야 plan cache의 execution plan이 사용될 수 있다. 플? 공유에 중점을 둔 체크-? 방식이?, 알티베이스 HDB의 SQL Plan Cache가 플? 공유에 중점은 둔 등록 방식을 사용?다는 의미이다. 즉, 새로? 공유 Plan은 SQL_PLAN_CACHE_SIZE 프로퍼티에서 정의? 크기를 넘지 않는 범위 내에서 SQL Plan Cache에 등록될 수 있다. ?약 새로? plan이 등록될 경우 SQL_PLAN_CACHE_SIZE 프로퍼티에서 정의? 크기를 넘는다면, 사용하지 않는 오래된 plan이 있는지를 확?하여 이를 삭제? 후 새로? plan을 등록?다. 그러나 새로? plan이 등록될 경우, SQL_PLAN_CACHE_SIZE 프로퍼티에 정의? 크기를 초과? 뿐? 아니라 SQL Plan Cache내의 Plan들이 다른 구?들에 의? 모두 참조되고 있다면, 새로? plan은 등록될 수 없다. SQL Plan Cache에 Plan을 등록하지 못하는 경우, V$SQL_PLAN_CACHE 성능 뷰의 CACHE_IN_FAIL_COUNT값이 증가?다. SQL_PLAN_CACHE_SIZE프로퍼티의 디폴트 값은 64MB이지?, 사용자가 임의로 지정? 수 있다. 또? SQL Plan Cache의 교체 정책은 최? 사용도뿐 아니라 참조 횟수까지 고려하기 때?에, Cache가 부족? 경우에도 자주 참조되는 Plan Cache 객체는 보호된다. 그러나 SQL ?장의 형식뿐 아니라 ?자 값도 반드시 같아야 공유된 plan cache가 사용될 수 있다. 그 이유는 SQL Plan Cache가 파싱 비용을 완?히 제거하는 방식으로 구현되었기 때?이다. 예를 들어 다음 두 ?장은 SQL Plan Cache에서는 다른 것으로 ?주된다. INSERT INTO T1 VALUES(1,2); INSERT INTO T1 VALUES(2,3); 이런 경우에 다음과 같이 질의를 작성하여 Plan Cache가 사용되도록 하면 성능을 향상시킬수 있다. INSERT INTO T1 VALUES(? , ?) SQL Plan Cache 401 SQL Plan Cache 관? 프로퍼티 SQL Plan Cache를 사용하기 위?서는 알티베이스 프로퍼티 파? 내의 몇몇 프로퍼티를 사용 목적에 맞게 수정?야 ?다. SQL Plan Cache과 관?된 프로퍼티는 다음과 같다. 각 프로퍼티에 대? 상세? 설명은 General Reference 를 참조?다. SQL_PLAN_CACHE_BUCKET_CNT SQL_PLAN_CACHE_HOT_REGION_LRU_RATIO SQL_PLAN_CACHE_PREPARED_EXECUTION_CONTEXT_CN T 서버/클라이?트 통? 403 14. 서버/클라이언트 통? 이 장은 알티베이스 HDB 데이터베이스 서버와 클라이?트 응용프로그램?의 접속 방법과 프로토콜을 설명?다. 404 Administrators Manual 통? 방법 네크워크 상의 서로 다른 두 ?퓨터에 ?재하는 프로세스?의 통? 또는 같은 ?퓨터에 ?재하는 프로세스?의 통? 방법에는 몇 가지가 있다. 이 ?에서는 알티베이스 HDB 데이터베이스 서버와 클라이?트 응용프로그램에서 사용? 수 있는 통? 방법을 설명?다. 알티베이스 HDB에서 제공하는 통? 방법은 아래와 같다. TCP/IP Unix Domain 소켓 공유 메모리를 이용? IPC TCP/IP Transmission Control Protocol/Internet Protocol (TCP/IP)은 산업계 표? 네크워크 프로토콜로 글로벌 ?터넷을 구축하는데도 사용되었다. TCP는 두 네크워크 호스트?의 정확? 데이터 교?을 위? 프로토콜이고, IP는 패킷을 목적지까지 ?송하는 역?을 하는 프로토콜이다. 알티베이스는 ?터넷 프로토콜 버? 4(IPv4)와 ?터넷 프로토콜 버? 6(IPv6)을 모두 지원?다. IPv6주소체계는 IPv4주소를 ?규로 ?당하는 것을 중단하는 시점에 대비하여 설계되었다. IPv4주소와 가장 큰 차이점은 IP주소 저장 공?의 길이가 32bit에서 128bit로 확대되어 보다 ?은 ?터넷 주소를 사용? 수 있다는 점이다. IPv6에 대? 자세? 정보는 Internet Protocol Version 6 (IPv6) Specification, RFC 2460 (http://tools.ietf.org/html/rfc2460)를 참고하기 바?다. IPv6 주소 표기법 IPv6 주소는 16bit크기의 16?수 8개가 콜?(:)으로 구분되어 표기된다. 다음은 유효? IPv6 주소의 예이다: 2001:cdba:0000:0000:0000:0000:3257:9652 IPv6 주소내의 네 개의 0으로 표시된 부분은 각각 ? 개의 0으로 ?여서 표기? 수 있거나 모두 생략? 수도 있다. 그러므로 다음의 IPv6 주소들은 모두 같은 주소를 나타낸다. 2001:cdba:0000:0000:0000:0000:3257:9652 서버/클라이?트 통? 405 2001:cdba:0:0:0:0:3257:9652 2001:cdba::3257:9652 위 주소를 위? URL 형식은 다음과 같다: http://[2001:cdba:0000:0000:0000:0000:3257:9652]/ 알티베이스 HDB는 RFC2732에 명세화된 표? IPv6 주소 표기법을 지원?다. 알티베이스 HDB 데이터베이스 서버에 연결? 때, IPv6 주소는 사각 괄호([ ])로 감싸여야 ?다. 다음은 알티베이스 HDB에서 유효? IPv6 주소의 예이다: [::1] [2002:c0a8:101:1:216:e6ff:fed2:7aea] $ isql -s [2002:c0a8:101:1:216:e6ff:fed2:7aea] -u sys FE80로 시작하는 릿크 로컬 주소의 경우, 영역 ?덱스가 퍼센트 표시(%)로 구분되어 주소 뒤에 붙는다. 영역 ?덱스는 릿크 로컬 주소가 ?당된 ?터페이스를 위? 색?이다. 리눅스 시스템에서 알티베이스 HDB 서버에 연결하려면 릿크 로컬 주소의 영역을 표시하는 영역 ?덱스를 붙여야 ?다. (예외로 JDBC 응용프로그램을 위?서는 영역 ?덱스가 필요없다.) 영역 ?덱스를 사용? 예는 다음과 같다: [fe80::221:86ff:fe94:f51f%eth0] $ isql -s [fe80::221:86ff:fe94:f51f%eth0] -u sys IP 스택 호스트 장비에는 여러 다른 프로토콜 스택8이 설치되어 있을 수 있다. 두 가지 프로토콜의 지원 여부에 따라 다음 세 타입의 IP 호스트로 구분된다. IPv4-only host IPv4 스택? 설치되어 있는 호스트. IPv4-only host에서는 IPv6 주소를 사용? 수 없다. IPv6/IPv4 host 듀얼 스택이 설치되어 있는 호스트로 IPv4와 IPv6 모두 지원 ?다. IPv6-only host IPv6 스택? 설치되어 있는 호스트. IPv6-only host는 IPv4 주소를 지원하지 않는다. IPv6 클라이언트/서버 연결 “네트워크 연결”이? 둘 이상의 ?퓨터 사이에 네트워크를 통?서 접속과 통?을 수립하는 것을 말?다. 다음 표는 설치된 프로토콜 스택에 따라서 서버와 클라이?트 ? 통?을 위? 사용될 수 있는 프로토콜 버?을 보여?다. 아래의 8 프로토콜 스택이? 계층화된 구조로 모여있는 프로토콜 집합의 소프트웨어적? 구현을 말?다. 406 Administrators Manual 표에서 Supportd (v6)는 IPv6를 지원하는 프로토콜 스택이 설치된 클라이?트/서버 호스트를 의미하며, 이 호스트는 IPv6 ?터페이스를 사용?서 다른 호스트에 연결? 수 있다. IPv4-only 서버 듀얼 스택 서버 IPv6-only 서버 IPv4-only 클라이?트 Supported (v4) Supported (v4) Not supported 듀얼 스택 클라이?트 Supported (v4) Supported (v4, v6) Supported (v6) IPv6-only 클라이?트 Not supported Supported (v6) Supported (v6) Note: 알티베이스 HDB는 듀얼 스택 프로토콜을 제공하지 않는 Windows NT 5.2 이하 버?에서는 듀얼 스택 서버를 지원하지 않는다. 알티베이스 HDB는 SPARC SunOS 에서 IPv6-only 서버를 지원하지 않는다. 알티베이스의 IPv6 지원 ALTIBASE HDB 6.1.1 에서의 IPv6 지원은 위의 “IPv6 클라이?트/서버 연결” ?의 표에 잘 나타나 있다. 서버 IPv6를 사용하려면, altibase.properties 파?에서 NET_CONN_IP_STACK 프로퍼티를 1 또는 2로 설정?야 ?다. 이 프로퍼티에 대? 자세? 설명은 General Reference를 참고하기 바?다. 클라이?트 IPv6 를 사용?서 접속하려면, DSN 속성을 IPv6 주소로 지정하거나, 또는 DSN 속성은 호스트 이름으로 명시하고 PREFER_IPV6 속성을 TRUE로 지정하면 된다. 호스트 이름을 지정? 경우, 알티베이스 클라이?트는 getaddrinfo() 호출로 반?되는 모? IP 주소로의 접속을 연결이 성공? 때까지 시도?다. ? 개 이상의 IP 주소가 반?될 경우, 알티베이스 클라이?트는 PREFER_IPV6 속성에 의? 순서대로 각 IP 주소로의 연결을 시도?다. PREFER_IPV6 속성이 지정되지 않거나 FALSE로 지정? 경우, 먼저 IPv4 주소로 연결을 시도?다. 연결이 실패하면 클라이?트는 반?되었던 IPv6 주소로 접속을 시도? 것이다. PREFER_IPV6 속성을 TRUE로 지정하면, IPv6 주소로 먼저 접속을 시도?다. 이것이 실패하면 클라이?트는 반?되었던 IPv4 주소로의 접속을 시도?다. PREFER_IPV6 속성에 대? 자세? 설명은 ODBC Reference를 서버/클라이?트 통? 407 참고하기 바?다. Unix Domain 소켓 유닉스 플랫폼 상에서 클라이?트와 알티베이스 데이터베이스 서버가 모두 동?? 장비에 설치되었을 때, 유닉스 도메? 소켓을 통?에 사용? 수 있다. 유닉스 도메? 소켓을 사용하면 TCP/IP 사용시보다 나은 성능을 낼 수 있다. 유닉스 도메? 소켓을 사용하려면, ODBC/CLI 응용 프로그램에서는 CONNTYPE 속성을 지정하고, 알티베이스 유틸리티에서는 ISQL_CONNECTION ?경 변수를 설정?다. 더 자세? 설명은 ODBC Reference 와 각각의 유틸리티에 대? 매뉴얼을 참고하기 바?다. 공유 메모리를 이용한 IPC 이 ?에서는 알티베이스 HDB에서 제공하는 공유 메모리를 이용? 프로세스? 통? (inter-process communication, IPC) 즉, 동시에 실행 중? 프로세스들 사이에서 데이터를 교?하는 방법에 대?서 설명?다. 클라이?트와 알티베이스 HDB 데이터베이스 서버가 동?? 장비에 설치되어 있는 경우, 이 통? 방법을 사용하면 클라이?트 응용프로그램은 보다 향상된 성능을 보여? 것이다. 공유 메모리를 이용? IPC는 최고의 성능을 제공하지?, 메모리를 추가로 더 ?이 사용하게 된다. 이 통? 방법을 사용하려면, 먼저 다음을 수행?야 ?다: altibase.properties 파?에서 관? 서버 프로퍼티를 설정?다. General Reference를 참고하기 바?다. ODBC/CLI 응용 프로그램에서는 CONNTYPE 속성을 지정하고, iSQL과 iLoader 같은 알티베이스 유틸리티에서는 ISQL_CONNECTION ?경 변수를 설정?다. 자세? 설명은 ODBC Reference 와 각각의 유틸리티 매뉴얼을 참고하기 바?다. 윈도우에서는 IPC로 알티베이스 HDB 데이터베이스 서버에 접속 시도시, TCP/IP도 사용된다. IPC로 연결? 때, 클라이?트는 다음 ?차에 따라 TCP/IP 접속을 먼저 시도하고, 연결이 성공 ? 후 IPC로 통?하게 된다. PREPER_IPV6 속성이 지정되지 않거나, FALSE로 지정된 경우, 408 Administrators Manual 클라이?트는 먼저 로컬 호스트의 IPv4 주소 (127.0.0.1)로 접속을 시도?다. 접속이 실패하면 다음으로 클라이?트는 ?당하는 IPv6 주소 ([::1])로 접속을 시도?다. PREPER_IPV6 속성이 TRUE로 지정된 경우, 클라이?트는 먼저 IPv6 주소로 접속을 시도?다. 접속이 실패하면, 클라이?트는 IPv4 주소로 접속을 시도?다. 알티베이스의 보? 409 15. 알티베이스의 보안 이 장에서는 알티베이스 HDB의 보?을 위? 사용 가능? 방법들과 보? 모듈 사용 방법에 대? 설명?다. 410 Administrators Manual 보안의 개요 정보 보호의 중요성이 높아지고 개? 정보 등 민감하고 중요? 정보를 법령으로 제정하여 보호함에 따라 데이터베이스의 보? 관리 기능이 필수적으로 요구되고 있다. 데이타베이스의 보?은 의도하지 않은 내, 외부적 ?동으로부터 데이타베이스를 보호하는 것을 목적으로 하며, 알티베이스 HDB에서는 사용자의 필요에 적합? 보? 모듈을 연동하여 데이터베이스를 효과적으로 보호? 수 있도록 보? 모듈 연동 기능을 제공?다. 이 장에서는 데이터 암호화를 위? 보? 모듈 연동 기능에 대? 설명?다. 알티베이스 HDB의 보? 모듈 연동 기능은 기? 알티베이스 HDB 시스템과의 독립적? 보? 모듈 구성과 응용 프로그램과의 완벽? 독립성을 바탕으로, 개? 정보 보호를 위? 강력? 암호화 관리를 지원?다. 알티베이스 HDB는 취약? 데이타베이스의 보?을 강화하기 위하여 ?뢰? 수 있는 외부의 보? 모듈을 알티베이스 HDB 시스템과 연동을 지원하며, 보? 모듈을 효과적으로 연동? 수 있는 ?터페이스를 제공?다. 알티베이스 HDB는 보? 모듈을 통? 데이터 암호화, 접? 제어 및 감사 기능을 위? 기반 구조를 데이타베이스 레벨에서 지원?다. 보?과 관?된 모? 작업은 알티베이스 HDB 서버 내에서가 아니라 보? 모듈을 통?서 이루어?다. 암호화는 테이블의 칼럼을 대상으로 수행되며, 암호화가 적용된 칼럼의 데이터는 디스크뿐? 아니라 메모리 상에서도 암호화를 유지?다. 접? 제어 기능은 크게 보? 대상의 선정 과정과 보? 대상에 대? 접? 권?의 분류를 통? 객체에 대? 사용자의 접? 유효성을 판단하는 두 과정으로 나뉘어?다. 접? 제어의 대상은 테이블 내의 칼럼 단위로 설정되며, 보?이 설정된 칼럼에 대? 접?을 하기 위?서 각 사용자는 ?당 객체에 대? 필요 접? 권?을 부여 받아야 ?다. 보? 대상의 설정과 보? 대상의 접?, 암호화 작업에 대?서는 감사 기록이 남겨?다. 알티베이스 HDB가 제공하는 보? 관? 기능은 다음과 같다. 알티베이스의 보? 411 디스크 및 메모리의 데이타를 암호화하여 저장 관리 보? 권?에 따른 출력 데이타의 복호화 원래 데이터의 순서를 보장하는 ?덱스 구성 암호 칼럼을 가지는 테이블의 이중화 가능 412 Administrators Manual 보안 기능의 구성 알티베이스 HDB와 보? 모듈은 서로 독립적이다. 암호 키, 보? 정책과 보? 권?에 대? 정보는 보? 모듈에서 별도로 관리?다. 보? 모듈이 연동되어 있지 않더라도, 알티베이스 HDB는 정상적으로 동작?다. 단, 암호 칼럼에 대? 질의 처리시 보? 모듈이 연동되어 있지 않으면, ?당 질의는 실패하게 된다. 알티베이스 HDB는 보? 모듈 관? 속성들의 설정과 SQL? 실행을 통? 보? 모듈을 연동?다. 알티베이스 HDB는 보? 모듈이 연동되는 과정에서 두 모듈 ?의 연결의 유효성을 평가하여 ?당 연결에 대? ?뢰성을 보장?다. 알티베이스 HDB는 자?이 가? 보? 모듈에 대? 정보(모듈 이름, 버?, 암호 칼럼들의 정보)와 보? 모듈이 가? 정보를 비교하여 보? 모듈과의 연결을 평가?다. 알티베이스 HDB에 연결하는 기? 응용프로그램을 수정? 필요 없이 데이터를 칼럼 단위로 암호화? 수 있다. 암호 칼럼의 생성 및 삭제는 SQL로 지원된다. 이 외의 기? 응용 프로그램에서 사용하는 질의를 변경? 필요는 없다. 보? 관? 알티베이스 HDB 메? 모듈의 역?은 다음과 같다. 데이터베이스 ?영 중 보? 모듈 연동을 위? ?경변수 및 SQL 구? 지원 암호화된 데이타를 관리하기 위? 자료구조 및 메타 정보 지원 보? 관? 확장된 질의 구? 지원 이중화 지원 외부 보? 모듈의 역?은 다음과 같다. 암호화 알고리즘 설정 (암호화 알고리즘의 종류, 초기화 벡터 사용 여부 결정) 칼럼의 암호화 정보 설정 (암호화 알고리즘 선택, 암호화 및 복호화 권? 설정) 데이타의 암호화 및 복호화 접? 제어 설정 (IP 접? 제어, 사용자 접? 제어) 감사 (암호화 및 복호화 로그, 접? 제어 로그) 알티베이스의 보? 413 보안 모듈 연동 방법 이 ?에서는 보? 모듈을 연동하기 위? 필요? ?차들을 설명?다. 하나의 서버에는 하나의 보? 모듈? 연동될 수 있다. 보? 모듈을 연동하기 위?서는 보? 모듈의 이름, 보? 모듈의 위치 경로, 암호화된 데이터의 순서가 원본 데이터의 순서와 같음을 보장하는 ECC알고리즘의 보? 정책 (알티베이스의 ECC 알고리즘은 Order Preserving Encryption방식이다)을 설정?다. 그 다음에 보? 모듈의 연동을 시작?다. 여기서 ECC? Encrypted Comparison Code의 약자로 암호화된 데이터의 순서가 원본 데이터의 순서와 같음을 보장하는 ?시값이다. ECC로부터 원본으로의 변?이 불가능? 단방향 ?시 알고리즘을 적용하여 ECC를 구성?다. ECC는 DBMS내부에서 암호 컬럼에 대? 빠른 비교연산을 위? 이용되며, 관리자 또는 사용자에 노출되지 않는다. ECC알고리즘은 ECC를 생성하기 위? 적용된 ?시 알고리즘을 의미?다. 외부 보? 모듈로부터 다양? ECC알고리즘의 지원이 가능하며, 서버 단위로 하나의 ECC 알고리즘이 선택되어 적용된다. 보? 모듈을 알티베이스 HDB에 연동하려면 다음의 과정을 수행?다. 외부 보? 모듈 설치 알티베이스 ?경 설정 보? 모듈 구동 암호 칼럼 생성 이 과정 중 외부 보? 모듈 설치 방법은 보? 모듈의 종류에 따라 다르므로 사용? 외부 보? 모듈의 설치 ?서를 참고?다. 여기에서는 그 다음 과정? 알티베이스 ?경 설정, 보? 모듈 구동 및 암호 칼럼 생성에 더하여 보? 모듈 종료와 암호 칼럼 ?제에 대?서 설명?다. 알티베이스 보안 ?경 설정 연동? 외부 보? 모듈의 경로를 알티베이스 속성 파?, $ALTIBASE_HOME/conf/altibase.properties에 다음과 같이 정의?다. SECURITY_MODULE_NAME = altibase SECURITY_MODULE_LIBRARY = libsecurity.so SECURITY_ECC_POLICY_NAME = ecc_policy1 414 Administrators Manual 프로퍼티의 값은 대, 소?자를 구별하므로 이에 주의?야 ?다. SECURITY_MODULE_NAME프로퍼티는 외부 보? 모듈의 식별자로 보? 보듈에 따라 달리 설정?다. SECURITY_MODULE_LIBRARY는 설치된 외부 보? 모듈 라이브러리의 이름을 나타낸다. SECURITY_ECC_POLICY_NAME은 알티베이스 내부에서 보? 정책을 구분하기 위? 이름으로 반드시 정의?야 ?다. 이 프로퍼티들의 값은 ALTER SYSTEM 구?으로 ?영 도중에 설정하거나 변경? 수 있다. ALTER SYSTEM 구?으로 변경? 경우, SECURITY_MODULE_LIBRARY에는 파?의 ?대 경로를 지정?야 ?다. ALTER SYSTEM SET SECURITY_MODULE_NAME = 'altibase'; ALTER SYSTEM SET SECURITY_MODULE_LIBRARY = '/altibase_home/lib/libsecurity.so'; ALTER SYSTEM SET SECURITY_ECC_POLICY_NAME = 'ecc_policy1'; 알티베이스의 보? 415 보안 모듈 구동과 데이터 암호화 이 ?에서는 보? 모듈 구동 및 데이터 암호화 방법에 대? 설명하고 관? 구?을 소개?다. 보안 모듈 구동 보? 모듈 관? 프로퍼티가 모두 설정되었다면 보? 모듈을 구동? 수 있다. 보? 모듈을 구동하면 내부적으로 다음 기능들이 수행된다. 1. 보? 모듈 ?증 상호 허용되지 않은 보? 모듈을 사용? 수 없도록 ?증?다. 2. 보? 모듈 초기화와 유효성 검사 보? 모듈 자체의 설정 파?이나 라이센스를 검사?다. 3. ECC 보? 정책 검증 보? 모듈에 프로퍼티로 설정된 ECC 보? 정책이 유효?지 검사 ?다. ALTER SYSTEM START SECURITY ?으로 보? 모듈을 구동?다. 이 구?은 적?? 권?을 가? 관리자로 접속?서 실행?야 ?다. 예제 1. 적?? 권?이 있는 관리자로 알티베이스 HDB에 접속?다. ISQL> CONNECT sys/manager 2. 보? 모듈 관? 프로퍼티를 설정?다. iSQL> ALTER SYSTEM SET SECURITY_MODULE_NAME = 'altibase'; iSQL> ALTER SYSTEM SET SECURITY_MODULE_LIBRARY = '/altibase_home/lib/libsecurity.so'; iSQL> ALTER SYSTEM SET SECURITY_ECC_POLICY_NAME = 'ecc_policy1'; 3. 보? 모듈을 구동?다. iSQL> ALTER SYSTEM START SECURITY; 4. 보? 모듈 구동 상태를 확??다. iSQL> SELECT * FROM SYSTEM_.SYS_SECURITY_; MODULE_NAME MODULE_VERSION ECC_POLICY_NAME ECC_POLICY_CODE -------------------------------------------------------- altibase 1.0 ecc_policy1 abcde12345 보안 모듈 종료 보? 모듈 구동과 ??가지로 보? 모듈을 종료하고자 ? 때는 416 Administrators Manual 적?? 권?이 있는 관리자로 접속?야 ?다. 그 다음에 다음 구?을 실행?다. iSQL> ALTER SYSTEM STOP SECURITY; 다음과 같이 보? 모듈 연동 상태를 확?? 수 있다. iSQL> SELECT * FROM SYSTEM_.SYS_SECURITY_; MODULE_NAME MODULE_VERSION ECC_POLICY_NAME ECC_POLICY_CODE -------------------------------------------------------- No rows selected. Note: 보? 모듈의 종료는 암호화 컬럼이 ?재하지 않는 경우에? 수행? 수 있다. 암호 칼럼 생성 데이터를 보호?야 하는 중요? 칼럼의 경우, 칼럼을 암호화하여 데이터를 보호? 수 있다. CHAR, VARCHAR 두 가지 자료형에 대? 암호화를 지원?다. CREATE TABLE ?으로 칼럼 생성시 암호 칼럼으로 지정하여 생성하거나, ALTER TABLE ?으로 이미 생성된 테이블의 칼럼을 암호 칼럼으로 변경? 수 있다. 두 경우 모두 사용? 보? 정책 이름(SECURITY_ECC_POLICY_NAME)을 암호화? 칼럼의 ENCRYPT USING ?에 지정?다. 칼럼의 암호화 여부는 DESC 구?을 통? 확?? 수 있다. 구문 CREATE TABLE table_name (column_name datatype [ENCRYPT USING ‘policy_name’]); 주의사항 암호화된 칼럼의 데이타 타입을 변경? 수 없다. 예제 질의 1> 테이블 생성시에 empID1, ssn1칼럼을 암호 칼럼으로 지정?다. CREATE TABLE t1 (name1 varchar(5), empID1 varchar(10) ENCRYPT USING ‘policy_id’, ssn1 char(12) ENCRYPT USING ‘policy_ssn’); 질의 2> 테이블에 암호 칼럼이 있는지 확??다. iSQL> DESC t1 -------------------------------------------------------- NAME TYPE IS NULL -------------------------------------------------------- NAME1 VARCHAR(10) FIXED EMPID1 VARCHAR(8) ENCRYPT FIXED 알티베이스의 보? 417 SSN CHAR(12) ENCRYPT FIXED 암호 칼럼으로 변경 ?반 칼럼의 경우, ALTER TABLE ?을 사용하여 암호 칼럼으로 변경? 수 있다. 구문 ALTER TABLE table_name MODIFY (column_name [ENCRYPT USING ‘policy_name’]); 주의사항 1. 암호 칼럼을 다시 암호화? 수 없다. 2. 암호화된 칼럼의 데이타 타입을 변경? 수 없다. 예제 질의> 기?의 t1 테이블의 empID1 칼럼을 보? 정책 policy_ssn을 사용하여 암호 칼럼으로 변경?다. ALTER TABLE t1 MODIFY (empID1 ENCRYPT USING ‘policy_ssn’); 암호 칼럼의 해제 ALTER TABLE 구?을 사용하여 암호화된 칼럼을 ?반 칼럼으로 변경? 수 있다. 구문 ALTER TABLE table_name MODIFY (column_name [DECRYPT]); 예제 질의> t1 테이블의 empID1 칼럼의 암호화 설정을 ?제?다. ALTER TABLE t1 MODIFY (empID1 DECRYPT); 알티베이스 튜닝 419 16. 알티베이스 튜닝 이 장에서는 서버의 성능 향상을 위?서 알티베이스 HDB가 제공하는 다음 두 가지 기능에 대?서 설명?다. 로그 파? 그룹 (Log File Group) 그룹 커밋 (Group Commit) 420 Administrators Manual 로그 파일 그룹 이 ?에서는 알티베이스 HDB에서 제공하는 로그 파? 그룹 기능에 대?서 기술?다. 로그 파일 그룹의 개념 로그파?그룹은 여러 트?잭?들의 로그가 동시에 여러 개의 로그파?에 기록될 수 있도록 하여 시스템의 성능을 향샹시킨다. 알티베이스는 기본적으로 로그파?들을 LOG_DIR프로퍼티에 설정된 하나의 디렉터리에서 관리?다. 그리고 그 로그파?들 중 오직 하나의 로그파?에 데이터베이스 서버 ?영 중에 발생하는 로그가 기록된다. 트?잭?의 영속성(Durability)보장을 위?서 로깅은 필수적이며, ?반적으로 여러 개의 트?잭?이 동시에 수행되는 ?경에서는 이와 같이 하나의 로그파?에 로그를 기록하는 과정에서 병목현상이 발생?다. 이러? 병목을 제거하기 위하여 알티베이스는 여러 개의 로그 파? 경로를 사용하는 로그파?그룹을 지원?다. ? 경로 내에서는 오직 하나의 로그파?에? 로그가 기록된다는 기?의 제약사핫은 그대로 적용되지?, 이러? 로그 경로가 여러 개가 됨에 따라 동시에 로그가 기록되는 로그파?의 수도 여러개로 늘어난다. 이와 같이 하나의 로그 경로, 즉 여러 개의 로그파?을 지니는 로깅 시스템의 최소 단위를 로그파?그룹 (Log File Group, LFG)라고 칭?다. 앞으로는 설명의 편의를 위하여 로그파?그룹을 ?략하게 LFG라고 통칭?다. 데이터베이스에 변경을 가하는 트?잭?이 ?고 트?잭?의 커밋이 빈번하게 수행될수록, LFG를 여러 개로 구성함에 따른 성능향상이 더욱 두드러?다. LFG의 구성요소 하나의 LFG는 다음과 같은 구성 요소를 지?다. 로그 파? 경로 (LOG_DIR 프로퍼티) LOG_DIR 프로퍼티는 로그 파?이 저장되는 디렉터리 경로를 지정?다. 이 디렉터리는 하나 혹은 그 이상의 로그 파?들이 ?재?다. 알티베이스는 그 중 오직 하나의 로그파?에? 알티베이스 튜닝 421 로그를 기록? 수 있다. 아카이브 로그 파? 경로 (ARCHIVE_DIR 프로퍼티) 데이터베이스가 아카이브로그 모드로 ?영중이라면, LOG_DIR 프로퍼티에 지정된 디렉터리에 위치하는 기록이 완료된 로그파?들은 ARCHIVE_DIR 프로퍼티에 지정된 디렉터리로 복사된다. 이러? 아카이브 로그파?은 데이터베이스 복구와 백업을 위? 사용된다. 이 프로퍼티의 수는 LOG_DIR프로퍼티의 수와 정확히 ?치?야 ?다. 아?러, LOG_DIR 프로퍼티가 여러 개? 경우 ARCHIVE_DIR 프로퍼티들은 LOG_DIR 프로퍼티 값과 순서대로 1:1로 매핑되도록 기술?야 ?다. 하나의 LFG를 위?서 다음과 같은 세가지 종류의 쓰레드가 ?재?다. 로그파? 생성 쓰레드 (Log File Creation Thread) ? LFG 내의 기록 중? 로그 파?이 꽉 차게 되면, 알티베이스는 새로? 로그파?에 로그를 기록하기 시작?다. 이 때, 새로? 로그파?로의 교체가 필요? 시점에 알티베이스가 새로? 로그파?을 생성?다면, 로그를 기록하려는 트?잭?은 로그파?이 생성되는 동? 아무 작업도 수행하지 못? 채로 기다려야 ?다는 ?제점이 발생?다. 이 쓰레드는 로그 기록을 계속하기 위? 새 로그파?이 필요? 시점 ?에 로그파?을 미리 ?들어 둔다. 참고로, 체크포?트 중에 더 이상 사용되지 않는 로그파?들을 별도로 분류하여 체크포?트가 완료되는 시점에 이를 삭제?다. 로그 플러시 쓰레드 (Log Flush Thread) 최?에 기록된 로그를 주기적으로 디스크로 기록하는 쓰레드이다. 트?잭?이 커밋될 때, 알티베이스 트?잭?은 이 쓰레드가 관? 로그를 벌써 디스크에 쓰지 않았는지 검사하고, 기록되지 않은 로그? 디스크에 쓰게 된다. 즉, 이 쓰레드는 주기적으로 로그를 디스크에 기록함으로써 트?잭?이 커밋되는 시점에 디스크에 기록? 로그의 수를 ?여주게 된다. 아카이브 로그 쓰레드 (Archive Log Thread) ? LFG 내에서 로그가 기록되고 있는 로그파?이 가득 차게 되면 다른 새로? 로그파?에 로그 기록이 계속된다. 이때, 아카이브 로그 쓰레드는 방금 ?까지 로그가 기록되고 있던, 하지? 끝까지 다 기록되어 더이상 로그가 기록되지 않는 이? 로그파?을 아카이브 로그파?로 복사?다. 422 Administrators Manual 사용 예 LFG에 관?된 프로퍼티는 아래의 3개가 있다. LOG_FILE_GROUP_COUNT LOG_DIR ARCHIVE_DIR LOG_FILE_GROUP_COUNT 프로퍼티는 기본으로 1로 설정되어 알티베이스는 ? 개의 LFG? 사용하도록 설정된다. 그리고 LOG_DIR과 ARCHIVE_DIR프로퍼티를 사용?서 따로 로그 경로와 아카이브 로그 경로가 지정된다. 다음은 LFG를 ? 개로 구성? 경우의 알티베이스 프로퍼티 파?의 ?부를 보여?다. LOG_FILE_GROUP_COUNT = 1 # LFG의 수 LOG_DIR = ?/logs # 로그 경로 ARCHIVE_DIR = ?/arch_logs # 아카이브 로그 경로 물음표(“?”)는 알티베이스 홈($ALTIBASE_HOME) 디렉터리를 나타내므로, 로그가 기록되는 경로는 $ALTIBASE_HOME/logs가 된다. 데이터베이스를 생성? 후 로그 경로 ?의 내용을 살펴보면 다음과 같이 logfile0부터 logfile2까지 세 개의 로그파?이 ?재하는 것을 볼 수 있다. 이들 중 오직 하나의 로그파?에? 트?잭?이 데이터베이스에 변경을 가하면서 발생하는 로그가 기록된다. -rw------- 1 kmkim kmkim 10485760 Jun 22 15:46 logfile0 -rw------- 1 kmkim kmkim 10485760 Jun 22 15:46 logfile1 -rw------- 1 kmkim kmkim 10485760 Jun 22 15:46 logfile2 다음은 LFG를 세 개로 구성? 경우의 알티베이스 프로퍼티 파?의 ?부를 보여?다. LFG의 수를 지정하는 LOG_FILE_GROUP_COUNT 프로퍼티에 3을 설정하였다. 각각의 LFG에 대응하는 로그경로와 아카이브 로그 경로를 LOG_DIR과 ARCHIVE_DIR 프로퍼티에 세 개씩 기술하고 있다. LOG_FILE_GROUP_COUNT = 3 # LFG의 수(3) LOG_DIR = ?/logs1 # 로그 경로 ( LFG#0 ) LOG_DIR = ?/logs2 # 로그 경로 ( LFG#1 ) LOG_DIR = ?/logs3 # 로그 경로 ( LFG#2 ) ARCHIVE_DIR = ?/arch_logs1 # 아카이브 로그 경로 ( LFG#0 ) ARCHIVE_DIR = ?/arch_logs2 # 아카이브 로그 경로 ( LFG#1 ) ARCHIVE_DIR = ?/arch_logs3 # 아카이브 로그 경로 ( LFG#2 ) 위에 기술? 로그 디렉터리들은 사용자가 명시적으로 생성? 주어야 ?다. 여기에서 새로? 디렉터리들은 LFG가 ? 개? 때와 알티베이스 튜닝 423 ??가지로 알티베이스 홈 경로? $ALTIBASE_HOME에 생성되어야 ?다. 첫 번째 로그파?그룹? LFG#0는 첫 번째 디렉터리? $ALTIBASE_HOME/logs1의 로그파? 중 하나에 로그를 기록?다. 다른 로그파?그룹은 각각 대응하는 디렉터리의 로그파?에 로그를 기록?다. 이와 같이 LFG를 여러 개로 ?영? 경우, 트??셕의 영속성(Durability)를 보장하기 위?서 트?잭?은 핫상 로그가 디스크에 반영(Sync)될 때까지 기다린다. 즉 핫상 COMMIT_WRITE_WAIT_MODE가 1 상태로 서버가 ?영된다. 로그파일그룹 최적화 LFG를 두 개 이상으로 사용하도록 설정? 경우, 다음과 같이 각 LFG의 로그 경로를 물리적으로 서로 다른 위치에 두면 하나의 디스크에 여러 LFG의 로그 기록 요청이 몰리는 것을 방지? 수 있다. 이와 같이 LFG를 물리적으로 서로 다른 디스크에 둘 경우 각각의 디스크가 동시에 I/O작업을 처리? 수 있어서 시스템의 성능이 ?결 향상된다. LOG_FILE_GROUP_COUNT = 3 # LFG의 수(3) LOG_DIR = /disk1/logs # 로그 경로 ( LFG#0 ) LOG_DIR = /disk2/logs # 로그 경로 ( LFG#1 ) LOG_DIR = /disk3/logs # 로그 경로 ( LFG#2 ) ARCHIVE_DIR = /disk1/arch # 아카이브 로그 경로 ( LFG#0 ) ARCHIVE_DIR = /disk2/arch # 아카이브 로그 경로 ( LFG#1 ) ARCHIVE_DIR = /disk3/arch # 아카이브 로그 경로 ( LFG#2 ) 반면, 다음과 같이 하나의 디스크에 두 개 이상의 LFG를 두도록 구성하면 디스크의 I/O 처리량이 높아지게 되어 더 좋은 성능을 낼 수도 있다. 이와 같이 ?반적으로 하나의 디스크에 두 개 이상의 LFG를 두는 것이 더 좋은 성능을 내지?, 하나의 디스크에 하나의 LFG를 둘 지, 아니면 둘 이상의 LFG를 둘 지는 시스템의 성능과 디스크의 I/O처리량, 및 시스템의 부하와 밀접? 연관이 있으므로, 실 상황에서 다양? LFG 구성으로 직접 성능을 측정? 보는 것이 가장 좋다. 424 Administrators Manual LOG_FILE_GROUP_COUNT = 6 # LFG의 수(6) LOG_DIR = /disk1/logs1 # 로그 경로 ( LFG#0 ) LOG_DIR = /disk1/logs2 # 로그 경로 ( LFG#1 ) LOG_DIR = /disk2/logs1 # 로그 경로 ( LFG#2 ) LOG_DIR = /disk2/logs2 # 로그 경로 ( LFG#3 ) LOG_DIR = /disk3/logs1 # 로그 경로 ( LFG#4 ) LOG_DIR = /disk3/logs2 # 로그 경로 ( LFG#5 ) ARCHIVE_DIR = /disk1/arch1 # 아카이브 로그 경로 ( LFG#0 ) ARCHIVE_DIR = /disk1/arch2 # 아카이브 로그 경로 ( LFG#1 ) ARCHIVE_DIR = /disk2/arch1 # 아카이브 로그 경로 ( LFG#2 ) ARCHIVE_DIR = /disk2/arch2 # 아카이브 로그 경로 ( LFG#3 ) ARCHIVE_DIR = /disk3/arch1 # 아카이브 로그 경로 ( LFG#4 ) ARCHIVE_DIR = /disk3/arch2 # 아카이브 로그 경로 ( LFG#5 ) 로그파일그룹 할당 데이터베이스 시스템에 LFG가 ? 개뿐? 때에는 모? 트?잭?이 ? LFG에 로그를 기록?다. 하지? LFG가 두 개 이상으로 구성된 경우에는 트?잭? 로그들을 여러 개의 LFG에 골고루 분산시켜 주어야 ?다. ? 트?잭?의 모? 로그는 같은 LFG에 기록된다. 이와 같이, 하나의 트?잭?에 로그를 기록? LFG를 제공하는 것을 “트?잭?에 LFG를 ?당?다”라고 ?다. 예를 들어 LFG가 LFG#0, LFG#1, LFG#2, LFG#3로 네 개로 구성된 경우 트?잭?에 LFG를 어떻게 ?당하는지 알아보자. 디스크 테이블을 변경? 적이 있는 디스크 트?잭?들의 경우, 첫 번째 LFG? LFG#0 을 ?당받는다. 메모리 테이블? 변경? 메모리 트?잭?들의 경우 LFG#1, LFG#2, LFG#3을 번갈아가면서 ?당받는다. 메모리 트?잭?이 디스크 테이블을 변경하여 디스크 트?잭?이 되는 경우, ?당 트?잭?은 사용중이던 LFG를 반납하고 LFG#0을 ?당받는다. 이 트?잭?들 외에 이미 삭제된 행들을 찾아서 공?을 반납하는 가비지 컬렉? 트?잭?과 체크포?트 관? 트?잭?은 LFG#0을 ?당받는다. 알티베이스 튜닝 425 한계와 제약사항 LFG기능의 한계점 디스크 테이블을 ? 번이라도 변경? 적이 있는 디스크 트?잭?의 경우, 첫 번째 LFG? ?당받기 때?에, LFG의 개수가 늘어나더라도 디스크 트?잭?의 성능이 향상되지는 않는다. 단, LFG를 두 개로 구성 하였을 때, 메모리 트?잭?과 디스크 트?잭?의 로그가 두 개의 LFG로 분산되기 때?에 LFG가 ? 개? 때에 비? 디스크 트?잭?의 성능이 올라갈 수 있다. LFG 기능의 제약사항 COMMIT_WRITE_WAIT_MODE가 1로 설정된 것 처럼 데이터베이스 시스템이 ?영된다. 사용자가 이 프로퍼티를 0으로 설정하여도 서버는 1로 ?영을 하여 트?잭? 커밋(Commit)시 트?잭?은 커밋 로그가 디스크에 반영될 때까지 기다린다. 데이터베이스를 생성하고 나면, LFG의 개수를 변경? 수 없다. 하지?, LFG의 로그 경로와 아카이브 로그 경로는 데이터베이스 생성 이후에도 변경이 가능하다. 서로 다른 LFG가 동?? 로그 경로를 공유?서는 ?된다. 즉, 각 LFG의 로그 경로는 서로 달라야 ?다. 서로 다른 LFG가 동?? 아카이브 로그 경로를 공유?서는 ?된다. 즉, 각 LFG의 아카이브 로그 경로는 서로 달라야 ?다. 426 Administrators Manual 그룹 커밋 이 ?에서는 트?잭? 처리 성능 향상을 위?서 알티베이스 HDB가 제공하는 그룹 커밋 기능에 대?서 설명?다. 그룹 커밋의 개념 그룹 커밋은 여러 트?잭?들의 커밋 요청을 모아서 ?번에 처리하여 I/O부하를 ?여주는 기능이다. 하나의 트?잭?이 커밋? 후에는 ?당 트?잭?이 수정? 내용이 어떠? 상황에서도 유실되어서는 ? 된다. 이를 보장하기 위?서는 ?당 트?잭?이 기록? 로그가 모두 디스크에 반영된 후에, 클라이?트에게 트?잭?의 커밋이 완료되었음을 알려주어야 ?다. 하지? 이러? 과정에서 수행되는 디스크 I/O는 메모리 기록에 비? 시?이 ?이 걸리기 때?에, 여러 트?잭?이 동시에 디스크 I/O를 각자 처리하게 될 경우 시스템의 성능 저하 정도는 더욱 심?질 것이다. 디스크 I/O를 수행하는데 소요되는 시?은 I/O의 양보다는 횟수에 더 큰 영향을 받는다. 즉, 여러 번에 걸쳐서 수행? I/O를 ?번에 몰아서 수행?다면, 시스템의 성능을 향상시킬 수 있을 것이다. 그룹커밋은 커밋을 하려는 여러 트?잭?들의 로그에 대? 디스크 I/O를 몰아서 ?번의 I/O로 처리하는 것으로, 시스템의 성능을 향상시킬 수 있다. 그룹 커밋 동작 원리 여러 트?잭?의 커밋을 위? 디스크 I/O수행을 ?번에 몰아서 처리하기 위? 알티베이스 HDB는 ?지링으로 디스크 I/O를 수행? 시각을 기억?두고 있다가 이후 ?정 시?이 지나기 ?에는 디스크 I/O를 허용하지 않고 트?잭?들을 대기하도록 ?다. 이와 같은 디스크 I/O대기 시?이 너무 작게 설정되어 있으면 디스크 I/O가 빈번하게 수행되어 그룹 커밋을 하지 않은 것과 별반 다름 없게 되고, 너무 크게 설정되어 있으면 디스크 I/O를 수행하려는 트?잭?들이 불필요하게 오래 대기하게 되어 오히려 시스템의 성능이 저하된다. 알티베이스 튜닝 427 그룹 커밋을 위? 디스크 I/O대기시?을 튜닝하는 방법에 대?서는 본 장의 그룹 커밋 관? 프로퍼티 튜닝을 참조?다. 그룹 커밋이 지정되어 있다면, HDB 서버가 어떤 트?잭?이 커밋을 위? 로그를 디스크로 내릴지를 결정? 때, 다음의 단계대로 작업을 수행?다. 1. 이 트?잭?이 디스크로 기록하려는 로그가 이미 다른 트?잭? 에 의? 디스크로 내려? 경우, 디스크 I/O를 수행하지 않는다. 그렇지 않을 경우, 2번을 수행?다. 2. 데이터베이스에 변경을 가? 트?잭?의 수가 LFG_GROUP_COMMIT_UPDATE_TX_COUNT 프로퍼티에 지정 된 값보다 작을 경우, 디스크 I/O를 수행하지 않고 대기?다. 그렇지 않을 경우 3번을 수행?다. 3. 가장 최?에 로그를 디스크로 기록? 이후로 LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정? 시?이 경과하지 않은 경우, 디스크 I/O를 수행하지 않고 대기? 다. 그렇지 않을 경우 4번을 수행?다. 4. 디스크 I/O가 발생? 시각을을 기록하고 디스크 I/O를 수행하여, 모? 대기하던 로그를 디스크에 기록?다. 그룹 커밋 수행 단위 앞서 LFG(Log File Group, 로그파? 그룹)기능에서 살펴본 바와 같이, 트?잭?이 기록? 로그를 디스크로 기록하는 작업은 LFG별로 각각 수행된다. 그러므로 그룹커밋도 서로 다른 LFG?에 영향을 받지 않고 별개로 ?행된다. 그룹 커밋 관? 프로퍼티 COMMIT_WRITE_WAIT_MODE가 0으로 설정된 경우, 트?잭? 커밋시에 커밋 로그가 디스크에 반영되는 것을 기다리지 않기 때?에 정?시의 영속성(Durability)은 보장되지 않는다. 그룹 커밋 기능은 트?잭?의 영속성(Durability) 보장을 위? 디스크 I/O를 모아서 처리하는 최적화 기법이다. 그러므로 이는 COMMIT_WRITE_WAIT_MODE가 1로 설정되어 있을 경우에 의미가 있다. 이 프로퍼티가 1로 설정된 경우에? 트?잭? 커밋시 커밋 로그가 디스크에 반영될 때까지 트?잭?이 기다리기 때?이다. 428 Administrators Manual 그룹 커밋시 고려사항 그룹 커밋은 여러 트?잭?이 동시에 커밋을 하려고 ? 때에? 그 효과를 발휘?다. 예를 들어 시스템상에 오직 하나의 트?잭??이 커밋하려고 하는 경우, 즉 커밋하려는 다른 트?잭?이 ?재하지 않는 경우, 이 때에는 함께 모아서 디스크 I/O를 처리? 트?잭?이 없다. 이런 경우 그룹커밋을 하지 않고 바로 디스크 I/O를 수행하는 것이 더 좋은 성능을 낸다. 앞서 그룹 커밋 수행 단위 에 기술? 바와 같이, 그룹 커밋은 LFG별로 독립적으로 이루어?다. 그룹 커밋을 수행?지의 여부도 LFG별로 그 LFG내에 커밋되지 않은 트?잭?의 개수를 기반으로 독립적으로 결정하게 된다. 알티베이스는 데이터베이스에 변경을 가? 트?잭? 수를 각 LFG별로 센다. DBA는 시스템의 특성을 고려? LFG_GROUP_COMMIT_UPDATE_TX_COUNT의 최적값을 찾아야 ?다. 이 프로퍼티의 기본값은 80이다. 그룹 커밋은 시스템이 특정 시?동? 가능?? ?은 트?잭?의 커밋 요청을 처리? 수 있도록 돕는다. 하지? 그룹 커밋을 사용? 경우 여러 트?잭?의 커밋 요청을 몰아서 ?번에 처리하기 때?에, 개별 트?잭?에 대? 응답 시?은 그룹 커밋을 사용하지 않을 때보다 길어질 수 있다. 그룹 커밋 관? 통계치 알티베이스 HDB는 DBA가 그룹 커밋의 동작을 모니터릿 ? 수 있는 통계치를 제공?다. 그룹 커밋은 LFG별로 독립적으로 이루어지기 때?에, 그룹 커밋의 통계치는 V$LFG성능 뷰에 ?재?다. V$LFG성능 뷰의 그룹 커밋 관? 통계값들은 다음과 같다. UPDATE_TX_COUNT ?당 LFG에 속? 트?잭?중 데이터베이스에 변경을 가? 트?잭?의 개수를 실시?으로 보여주는 통계치이다. 이 값이 LFG_GROUP_COMMIT_UPDATE_TX_COUNT 프로퍼티에 설정된 값보다 클 때에? ?당 LFG에 대? 그룹 커밋을 실시?다. GC_WAIT_COUNT 알티베이스 튜닝 429 이 통계값은 가장 최? 디스크 I/O 발생 이후 디스크 I/O가 연기된 회수를 보여?다. 이 카?트는 LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정? ?큼의 시?이 지나지 않아서 디스크 I/O를 수행하지 못? 때?다 1씩 증가?다. GC_ALREADY_SYNC_COUNT 트?잭?이 커밋을 위? 디스크로 기록?야 하는 로그의 내용이 이미 다른 트?잭?에 의? 디스크로 기록된 경우에는 추가적? 디스크 I/O를 수행? 필요가 없다. 이와 같이 디스크 I/O를 수행하지 않고 바로 커밋 완료 응답 ?호를 보내는 경우에 1씩 증가하는 카?트 값이다. GC_REAL_SYNC_COUNT 실제 디스크 I/O를 수행하여 로그를 디스크로 기록? 경우 1씩 증가되는 카?트 값이다. 이는 다음 두 가지 경우 중 하나? 때 증가된다. -하나의 트?잭?이 커밋을 위? 로그를 디스크로 기록하려 하려는 시점에 V$LFG 성능 뷰의 UPDATE_TX_COUNT 값이 LFG_GROUP_COMMIT_UPDATE_TX_COUNT 프로퍼티의 값보다 작으면 그룹 커밋 기능이 ?성화 되지 않고, 따라서 직접 로그 기록을 위? 디스크 I/O를 수행? 경우 -그룹 커밋이 ?성화된 상황에서 ?지링으로 디스크 I/O를 수행? 시각 이후로 LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정? ?큼의 시?이 지나서 실제 디스크 I/O를 수행? 경우 그룹 커밋 관? 프로퍼티 튜닝 그룹 커밋 기능을 이용하기 위?서는 시스템 자체의 성능과 다수의 커밋하려는 트?잭?이 발생하는 상황에서의 시스템의 부하를 종합적으로 고려하여 관? 프로퍼티를 최적값으로 설정?야 ?다. 이 ?에서는 각각의 그룹 커밋 관? 프로퍼티값을 튜닝하는 방법에 대? 알아본다. LFG_GROUP_COMMIT_UPDATE_TX_COUNT 이 프로퍼티의 값이 너무 작으면 데이터베이스에 변경을 가? 트?잭? 수가 그다지 ?지 않아도 그룹 커밋이 ?성화된다. 이 경우, 로그를 기록하기 위? 디스크 I/O의 횟수가 증가하여 시스템 성능이 저하된다. 반면, 이 프로퍼티의 값이 너무 크면 비록 데이터베이스에 변경을 가? 트?잭?의 수가 충분히 ?더라도 그룹커밋이 430 Administrators Manual ?성화되지 못?다. 데이터베이스 시스템에 여러개의 트?잭?이 몰리는 때에 DBA는 V$LFG 성능 뷰의 UPDATE_TX_COUNT 값을 실시?으로 모니터릿 하여 이 프로퍼티의 값을 적정? 값으로 결정하면 된다. LFG_GROUP_COMMIT_INTERVAL_USEC 이 프로퍼티의 값이 너무 작으면 빈번하게 디스크 I/O가 수행되어 시스템 성능이 저하된다. 이러? 상황에서는 커밋을 위? 실제로 디스크 I/O를 수행하는 횟수가 ?아지므로 V$LFG 성능 뷰의 GC_REAL_SYNC_COUNT 값이 빠른 속도로 증가?다. 반대로, 이 프로퍼티의 값이 너무 크면 이용 가능? 디스크 I/O 용량이 충분히 ?용하지 못하여 시스템의 성능이 저하된다. 이러? 상황에서는 디스크 I/O를 위? 대기하는 횟수가 ?아지므로 V$LFG 성능 뷰의 GC_WAIT_COUNT 값이 빠른 속도로 증가?다. 이 프로퍼티를 최적으로 설정하려면 우선 이 프로퍼티의 값을 기본값? 1000 (1ms)에서부터 시작하여 2배씩 증가시켜가면서 시스템의 ?체 성능 (TPS - Transaction Per Second)을 측정? 본다. GC_REAL_SYNC_COUNT의 값이 점점 작아지면서 최적의 성능을 낼 때 이 프로퍼티가 최적화 됐음을 의미?다. GC_REAL_SYNC_COUNT의 값이 작아지는 것이 곧 최적의 성능을 내는 상황을 의미하지는 않는다. 앞서 설명? 대로 이 프로퍼티의 값이 너무 크면 커밋을 하려는 트?잭?들이 디스크 I/O를 위? 불필요하게 ?은 시?을 기다리게 되어 디스크 I/O를 수행? 수 있는데도 디스크 I/O를 수행하지 않고 대기하는 상황이 발생하기 때?이다. 이 경우에는 위와 같은 방법으로 기본값? 1000에서 ?반씩 감소시켜 가면서 최적의 TPS를 내는 상황을 찾아낸다. LFG_GROUP_COMMIT_RETRY_USEC 이 프로퍼티의 값이 너무 작으면 디스크 I/O를 대기하는 트?잭?들이 더 빈번하게 깨어나서 디스크 I/O를 수행?야 하는지 체크하게 된다. 이 경우 개별 트?잭?의 커밋에 대? 응답시?은 짧아질 수 있지?, 디스크 I/O가능 여부 체크를 너무 빈번하게 하게 되어서 CPU 사용율이 높아지게 된다. 또? 이러? 상황에서는 빈번하게 디스크 I/O가능 여부를 체크?후 디스크 I/O를 위? 대기상태로 들어갈 수 있기 때?에 이 프로퍼티의 값이 클 때에 비?서 V$LFG 성능 뷰의 GC_WAIT_COUNT 값이 빠른 속도로 증가? 것이다. 반면, 이 프로퍼티의 값이 너무 크면 디스크 I/O를 대기하는 알티베이스 튜닝 431 트?잭?들이 디스크 I/O가 가능?지의 여부를 체크하는 횟수가 ?어들게 되며, CPU사용율이 낮아지게 된다. 하지? 디스크 I/O 가능 여부를 체크하기까지의 대기시?이 길어져서 개별 트?잭?의 커밋에 대? 응답시?은 길어?다. DBA는 이 프로퍼티의 값을 변경? 때, Unix의 top 명령이나 Windows의 작업관리자를 통? 알티베이스 프로세스의 CPU 사용율을 모니터릿하거나 개별 트?잭?의 응답시?의 평균값을 측정하는 방법으로 이 프로퍼티 값을 최적의 값으로 설정? 수 있다. 알티베이스 ?단 모니터릿 433 17. 알티베이스 ?단 모니터링 이 장에서는 알티베이스 HDB 데이터베이스의 ?영 상태를 확?하고 분석하는 방법에 대? 설명?다. 434 Administrators Manual 알티베이스 모니터링 알티베이스 HDB 데이터베이스의 ?영 상태를 확?하기 위?서는 성능 뷰를 이용?다. 성능 뷰에 대? 자세? 설명은 General Reference의 데이터 딕셔너리 장을 참고?다. 모니터릿 ?야? 주된 개체는 다음과 같다. 세션과 Statement 알티베이스 ?영 중 연결되어 있는 세?에 대? 정보를 성능 뷰로 확??다. 하나의 세?에는 여러 개의 Statement1가 ?당될 수 있다. 세? 속성은 세? 별로 다르게 지정될 수 있다. 데이터베이스(테이블/인덱스) 정보 ?체 데이터베이스에 대? 정보와 각 테이블스페이스, 테이블 및 ?덱스 정보를 성능 뷰로 확?? 수 있다. 메모리 사용량 알티베이스 HDB 서버가 ?영하면서 사용하는 메모리 영역 정보를 성능 뷰로 확??다. 여기에는 메모리 테이블스페이스의 데이터(레코드의 예? 버? 포함) 저장 영역 및 ?덱스 저장 영역, 질의 처리를 위? 임시 영역, 세? 정보 저장 공?, 메모리 버퍼 풀 등이 포함된다. 이중화 상태 이중화 상태 정보를 성능 뷰로 확??다. 이중화 관? 쓰레드(Sender/Receiver)의 상태와 이중화 데이터 ?송 상태를 확?? 수 있다. 1 Statement는 하나의 SQL?을 처리하기 위? 내부적으로 사용되는 객체이며 하나의 statement는 하나의 SQL?을 처리?다. 알티베이스 ?단 모니터릿 435 알티베이스 문제상황 분석 이 ?은 알티베이스 HDB ?영 중 발생? 수 있는 여러 가지 ?제 상황에 대? 점검 사핫 및 분석 방법에 대? 설명?다. 실제 ?영 ?경에서는 다양? 형태의 ?제가 발생되며 미리 형태를 예측? 수 없는 경우도 있으므로 반드시 여기서 설명하는 바와 같이 ?행되는 것은 아니다. 하지? 예측 가능? 범위 내에서 형태별로 나누어 ?반적? 방법을 제시하여 ?제 상황에 대처? 수 있는 정보를 제공하고자 ?다. 예측 가능? ?제 발생 형태는 크게 다음과 같이 생각? 볼 수 있다. 알티베이스 프로세스 비정상 종료 및 재구동시 ?제 알티베이스 서버 응답 시? ?제알티베이스 서버 응답 시? ?제 디스크 사용량의 ?제 메모리 사용량의 ?제 CPU 사용량의 ?제 이중화 ?제 응용프로그램 및 쿼리 수행시 ?제 ?반적? ?제상황 분석(PBT, Problem Tracking) ?차는 다음과 같다. 436 Administrators Manual [그림 17-1] ?반적? ?제 분석 ?차 알티베이스 관리자 로그? $ALTIBASE_HOME/trc 디렉터리에 생성되고 유지되는 “*.log” 이름을 가지는 파?의 텍스트 로그이다. 이 디렉터리에는 다음의 트레이스 로그 파?들이 있다. altibase_boot.log altibase_id.log altibase_mt.log altibase_qp.log altibase_rp.log altibase_sm.log 알티베이스 서버 비정상 종료 및 재구동 실패 문제 비정상 종료 알티베이스 HDB 프로세스가 비정상적으로 종료? 수 있는 원?으로 다음의 것들을 생각? 볼 수 있다. 가용 메모리 부족 시스템 OS 패닉 상태 ?제 유형 판단 알티베이스 관리자 로그 (altibase_XXX.log) 확? 관?정보 수집 (알티베이스 모니터릿 도구/시스템 모니터릿 커맨드 사용) 원? 분석 및 ?제?결 알티베이스 ?단 모니터릿 437 이러? 경우 관리자 로그의 에러 메시지를 통? 판단이 가능하며 가용 메모리 부족으로 ?? 발생하는 경우를 제외하고는 ?? 시스템 엔지니어에게 ?의?야 ?다. 가용 메모리가 부족? 경우라면 관리자 로그에 “Memory allocation failed.” 혹은 “Unable to invoke the shmget() system function”와 같이 메모리 ?당 관? 시스템 함수 호출 에러 메시지가 기록된다. 이 경우에는 현재 메모리 사용량을 점검?야 하며, 불필요하게 ?이 사용하는 부분을 있는지 확??다. 이러? 부분이 있다면 ?당 부분의 메모리를 ?제하여 메모리를 확보하고 과도? 메모리 사용의 원?을 찾아 재발을 방지?야 ?다. ?? 불필요하게 사용하는 부분이 없다면 시스템 메모리 업그레이드를 고려?야 ?다. 메모리 관? ?제는 다음 ?에 나올 메모리 사용량의 ?제에서 좀 더 자세히 설명하기로 ?다. 알티베이스 재구동 실패 알티베이스 HDB 재구동 시 실패? 수 있는 원?으로 다음의 것을 생각?볼수 있다. 동?? 서비스 포트 번호(PORT_NO 프로퍼티)를 사용하는 알티베이스 프로세스가 이미 ?재하는 경우 구동 또는 회복 시 필요? 파?이 없거나 파?에 대? 권?이나 파? 시스템 ?제로 ?? 접?이 ? 되는 경우 관리자 로그에 파? 접? 관? 에러가 발생?다면 ?당 파?들(모? 로그 파?, 모? 로그 앵커 파?, 모? 데이터 파?)이 ?재하는지를 확??다. 파?이 ?재하고 접?이 가능함에도 불구하고 에러가 발생?다면 파?이 깨졌을 가능성이 있으며 이 경우 데이터베이스를 새로 생성?야 ?다. 공유메모리 모드로 사용 시 비정상 종료 후, 이?에 사용? 공유 메모리와 파?상의 데이터베이스 이미지가 호?이 ? 되는 경우 공유메모리 호? ?제로 ?? 재구동이 실패하는 경우 현재 공유메모리를 삭제하고 알티베이스를 다시 구동하여야 ?다. 공유메모리를 삭제하려면 알티베이스 공유메모리 관리도구(shmutil)를 사용하거나 “ipcrm” 시스템 명령에 의? 가능하다. “ipcrm” 명령어를 사용하여 삭제? 공유메모리 정보는 삭제하기 ?에 “ipcs” 명령어로 검색? 볼 수 있다. 시스템 리소스 부족 시스템 리소스 부족으로 ?? 시스템 구동이 실패했다면, 여러 가지 시스템 리소스 중 어떤 리소스가 부족?지를 확?하여 438 Administrators Manual 실제 시스템에 적재되어 있는 리소스 가용량을 확?하고 시스템 커널 설정을 확?하여 ?제가 있는 부분을 ?결?야 ?다. 구동 시 주로 ?제가 되는 리소스는 메모리 또는 세?포어이다. 메모리 관? ?제의 경우 시스템 커널 설정에서 ? 프로세스 당 사용 가능? 메모리의 크기, 사용 가능? 공유메모리 크기, 및 공유메모리 세그먼트의 최대 크기등을 확?? 봐야 ?다. 알티베이스를 공유메모리 모드로 사용? 경우 STARTUP_SHM_CHUNK_SIZE 프로퍼티의 설정값이 사용 가능? 공유메모리 세그먼트의 최대크기를 넘으면 ?된다. IPC 통?을 하려면 세?포어가 필요하며 이는 알티베이스 설정 중 IPC_CHANNEL_COUNT 프로퍼티와 관?이 있다. IPC 통?에 필요? 시스템 자원을 확?? 보기 위?서는 알티베이스에서 제공하는 checkipc 도구를 이용하면 된다. checkipc 도구를 이용하여 검사를 ?보면 시스템의 어떤 핫목이 얼?나 필요?지와 실제 커널의 설정값을 확?? 볼 수 있다. 이 값을 참조하여 알티베이스 설정과 시스템 커널 설정을 적?하게 조정하면 ?제 ?결이 가능하다. 알티베이스 서버 응답 시간 문제 알티베이스 HDB 서버가 실제로 질의를 처리하고 있지? 응답속도가 매우 늦다면 사용자는 서버가 응답이 없다고 오?? 수 있다. 질의 처리 요청 시 응답이 늦는 경우, 이유는 대부분 테이블을 풀스캔하거나 메모리 부족으로 ?? 스와핑이 발생하기 때?이다. 이 경우 세?정보 확?과 시스템 정보를 통? ?당 질의가 실제로 수행 중?지를 확??다. CPU 사용량이 높거나 가용 메모리가 부족하여 스와핑이 발생?다면 실제로 질의를 처리하고 있는 경우? 가능성이 높다. 자세? 설명은 다음에 나올 “응용프로그램 및 쿼리 수행시 ?제 ”에서 좀 더 자세히 설명하기로 ?다. 또 다른 원?으로는 디스크 여유 공?이 부족하여 데이터 변경이나 입력 시 응답이 없는 경우를 생각? 수 있다. 이러? 경우에는 시스템 관리자 로그에 디스크의 여유 공?이 없음을 알리는 에러 메시지가 남게되며 디스크 공?이 확보되기 ?까지 응답이 없는 상태로 남아있게 된다. 디스크 공? 부족으로 ?? ?제 ?결 방법은 다음에 나올 “디스크 사용량의 ?제”에서 좀 더 자세히 설명하기로 ?다. 알티베이스 ?단 모니터릿 439 이 외에 다른 ?제로 알티베이스 HDB 서버가 응답이 없는 상태로 남아있다면 ?? 시스템 엔지니어에게 ?의?야 ?다. 디스크 사용량의 문제 디스크 가용 공간 부족 알티베이스 HDB ?영 중에 디스크 공?이 부족하게 되면 알티베이스 HDB가 더 이상 데이터 변경작업을 하지 않고 멈춰있는 현상이 발생 ? 수 있다. 이런 경우 먼저 여러 파? 시스템 중 어떤 곳의 공?이 부족?지를 확??야 ?다. 알티베이스 HDB가 ?영 중에 사용하는 디스크 공?은 다음과 같다. 로그 파? 저장 공? 각 테이블스페이스 파? 저장 공? 알티베이스 HDB ?영 중에 액티브 로그와 아카이브 로그가 지속적으로 생성되며, 액티브 로그 파?은 알티베이스 설정 파?(altibase.properties) 핫목 중 LOG_DIR프로퍼티에 설정된 디렉터리에 저장이 되고, 아카이브 로그 파?은 데이터베이스가 아카이브 로그 모드로 ?영될 경우 자동으로 ARCHIVE_DIR 프로퍼티에 설정된 디렉터리에 저장된다. 액티브 로그의 경우는 디스크 공?이 부족하여 더 이상 로그 저장이 불가능?지면 알티베이스 HDB가 멈추게 된다. 이런 경우 로그 파?과 로그 앵커파?을 지우게 되면 복구가 불가능?지므로 ?당 파? 시스템의 크기를 늘리거나 이외에 다른 불필요? 파?을 삭제하여 디스크 공?을 확보?야 ?다. 아카이브 로그의 경우에는 설정 파?의 ARCHIVE_FULL_ACTION 프로퍼티 핫목의 설정값이 0? 경우 아카이브 로그를 저장하지 않고 계속 ?영되게 되며, 1? 경우 ?당 파? 시스템의 가용공?이 확보될 때까지 알티베이스 HDB가 멈춰있게 된다. LOG_DIR 프로퍼티에 지정된 디렉터리에 로그 파?의 개수가 ?아져 로그 저장 공?이 부족? ? 경우 먼저 관리자 로그 파?을 확?하여 체크포?트가 정상적으로 이루어 지고 있는지를 확??야 하며, 알티베이스 설정 파? 내에 CHECKPOINT_INTERVAL_IN_SEC 프로퍼티와 CHECKPOINT_INTERVAL_IN_LOG 프로퍼티의 설정이 적??지 확?하여야 ?다. ?? 체크포?트가 정상적으로 이루어 지고 있음에도 불구하고 아카이브 로그 파?들이 LOG_DIR 프로퍼티에 지정된 디렉터리에 계속 남아 있다면 이중화 ?송 상태를 확?? 본다. 이중화 ?송이 계속 밀리고 있거나 ?송 불가능 440 Administrators Manual 상태라면 로그 파?들은 아카이브 되지 않거나 지워지지 않아서 LOG_DIR 프로퍼티에 지정된 디렉터리에 계속 보관되므로 로그 저장 공?이 부족? 질 수 있다. 이중화 관? ?제 ?결 방법은 다음에 나올 “이중화 ?제”에서 좀 더 자세히 설명하기로 ?다 메모리 테이블스페이스와 각 시스템 테이블스페이스는 설정 파?내의 MEM_DB_DIR 프로퍼티에 설정된 디렉터리에 저장된다. 테이블스페이스 관? 디스크 부족 현상이라면 이 부분 또는 사용자가 생성? 테이블스페이스 파?이 저장된 공?을 확??야 ?다. 테이블스페이스를 저장하는 파? 시스템은 최소 ?당 테이블스페이스가 증가되는 크기 이상의 여유 공?이 있어야 ?다. 메모리 테이블스페이스의 저장 공?은 체크포?트가 수행될 때 실제로 디스크에 기록이 되기 때?에 메모리 상에 ?재하는 테이블스페이스 크기 이상의 디스크 여유 공?이 필요하다. 메모리 사용량의 문제 알티베이스 HDB ?영 중 가용메모리가 부족? ?다면 응답시?이 매우 느려질 수 있으며 알티베이스 HDB가 비정상적으로 종료될 수 있다. 이런 경우 알티베이스 HDB가 사용하고 있는 메모리 영역을 검사하여 ?당 크기가 적??지를 판단하고 불필요하게 사용되고 있는 부분을 제거?야 ?다. ?? 불필요하게 사용하고 있는 영역이 없다면 메모리 증설을 고려 하여야 ?다. 알티베이스 HDB가 ?영 중에 사용하는 메모리 공?은 크게 나누어 보면 다음과 같다. 메모리 테이블스페이스 임시 메모리 공? 메모리 버퍼 메모리 테이블스페이스에는 메모리 테이블의 실제 레코드 및 MVCC 를 지원하는데 필요? 레코드의 이? 버?들이 저장된다. 임시 메모리 공?은 메모리 테이블에 생성된 테이블의 ?덱스와 메모리 테이블 조회 시 레코드를 정?하기 위? 공?, 세?들의 정보를 저장하는 용도 등으로 사용된다. 메모리 버퍼는 디스크 테이블 레코드에 대? 연산 및 정? 등을 위? 사용되는 공?이다. 알티베이스 ?단 모니터릿 441 메모리 과다 사용이 의심된다면 ?정기? 동? 생성되는 ?장(statement)의 개수와 임시 메모리 영역의 크기, 메모리 테이블스페이스의 사용량, 및 메모리 테이블의 ?덱스 크기 등을 모니터릿 하여 증가량을 확?하여야 하며 이와 함께 “ps”나 “top”과 같은 시스템 모니터릿 명령으로 프로세스의 크기가 지속적으로 증가되는 지 확?? 보아야 ?다. 알티베이스 HDB가 처음 가동된 이후에 ?정 기? 동?은 임시 메모리 영역 ?당, 여러 이? 버?의 레코드 생성, 및 세? 정보의 증가로 ?? 메모리 사용량이 증가? 수 있는데, 이는 정상이다. 그러나 ?? ?정 기? ?영 이후에도 지속적으로 증가?다면 메모리 누수와 같은 이상이 있는지를 의심? 볼 수 있으며 이러? 경우 ?? 시스템 엔지니어에게 ?의를 ?야 ?다. CPU 사용량의 문제 갑자기 알티베이스 HDB의 CPU 사용량이 늘었다면 다음과 같은 상황들을 의심? 볼 수 있다. 메모리 테이블 질의 처리 시 ?덱스를 사용하지 못함 디스크 테이블 질의 처리 시 디스크 사용 과다 메모리 부족으로 ?? 스와핑 발생 시스템 성능 모니터릿 도구를 이용하여 메모리 사용량을 확?하고 가용 메모리가 부족하여 스와핑이 발생?다면 추가 메모리를 확보?야 ?다. 이에 대? 내용은 “메모리 사용량의 ?제”에서 자세히 설명하였다. 메모리 부족 상핫이 아니고 질의 처리 시 메모리 테이블 ?체 스캔이나 디스크 테이블에서 디스크를 과다하게 사용?다면 ?당 쿼리나 테이블 등을 튜닝하여 ?결이 가능하다. 이에 대? 내용은 다음에 나올 “응용 프로그램 및 쿼리 수행시 ?제”에서 좀 더 자세히 설명하기로 ?다. 이중화 문제 이중화 관?하여 발생 ? 수 있는 ?제는 다음과 같은 것들이 있다. 이중화 시작 실패 이중화 반영 속도가 매우 느림 442 Administrators Manual 이중화 중? 테이블의 레코드 건수가 서로 틀림 이중화 ?송에 ?제가 발생되면 로그 저장 공?에 아카이브 로그 파?이 계속 남아있게 되어 가용 공?이 부족?지고 이로 ?? 서비스가 ?되고 알티베이스가 멈춰있는 현상이 발생될 수 있다. 이중화 관? ?제가 발생했다면 먼저 관리자 로그 파?에 이중화 관? 에러 메시지가 기록되어 있는지 확?하고 ?당 내용을 ?? 엔지니어에게 ?달?야 ?다. ?쪽 시스템에 장애가 발생하고 장애 상황이 장시? 지속되면 이중화 데이터 ?송을 하지 못하여 로그 저장 디렉터리의 가용 공?이 부족? 지는 현상이 발생?다. 따라서 단시? 내에 ?제 ?결이 어려? 경우에는 이중화를 중단하고 이중화 객체를 삭제하여 현재 ?영중? 시스템에 ?제가 생기지 않도록 하는 것을 고려?야 ?다. 이런 경우 장애 상황이 ?제된 이후 장애 발생 시스템의 데이터 복구 작업이 추가적으로 필요하다. 데이터 복구 방법으로는 iLoader 도구를 이용하는 방법과 이중화를 SYNC 모드로 구동하는 방법이 있다. ?? 이중화 객체 삭제가 어려? 경우 로그 저장 디렉터리의 가용 공?을 지속적으로 확?하여 모자? 경우 확보를 ?주어야 ?다. ??가지로 이중화 네트워크 라?에 ?제가 발생했다던지 이중화에 ?제가 생겨 장시? 이중화가 연결되지 못하는 경우에도 동?? 조치가 필요하다. 응용프로그램 및 쿼리 수행시 문제 응용프로그램 및 쿼리 수행에 관? ?제 발생시 크게 다음 두 가지 상황을 생각? 볼 수 있다. 응용프로그램에서 알티베이스로의 접속 실패 응용프로그램에서 알티베이스로 쿼리 요청 이후 멈추어 있거나 정?? 시? 동? 처리하지 못하여 타임아웃 발생 알티베이스 접속 실패 응용프로그램에서 접속이 실패?다면 알티베이스 질의 처리 도구? iSQL을 이용하여 접속을 시도?서 정상적으로 접속이 되는지 확??다. 알티베이스에서는 접속시 3가지의 접속 방식을 제공하기 때?에 (TCP/IP, socket domain, IPC) 응용프로그램에서 사용하고 있는 접속 방식을 사용하여 시험?봐야 ?다. 알티베이스 ?단 모니터릿 443 접속 방식을 설정하는 방법은 ISQL_CONNECTION ?경변수를 지정하여 가능하다. (TCP, UNIX, IPC) ?? iSQL로 접속이 성공?다면 응용프로그램 ?에서 접속정보 설정 시 ?제가 있는 것이므로 ?당 부분의 오류를 찾아 ?결하면 되며, 접속이 성공하지 못?다면 다음 사핫들을 고려? 볼 수 있다. 현재 서버에 접속된 세? 수가 MAX_CLIENT 알티베이스 프로퍼티의 설정값을 초과함. 접속 방식이 IPC 방식? 경우 IPC 방식으로 접속된 세? 수가 IPC_CHANNEL_COUNT 설정값을 초과함. 응답이 없거나 타임 아웃으로 인해 세션이 끊어짐 질의 처리시 수행 속도가 느려 응답이 없는 경우 다음과 같은 상황을 생각? 볼 수 있다. 메모리 가용량이 부족하여 스왑핑이 발생 테이블을 풀 스캔하여 처리 성능이 저하 특정 테이블에 록을 요청하고 기다리고 있는 상태 먼저 시스템 성능 모니터릿 도구를 이용하여 CPU 사용량과 메모리 사용량을 점검하여 메모리 부족 상황?지를 판단?야 하며 ?? 메모리가 부족? 상황이라고 판단되면 위의 “메모리 사용량의 ?제 를 참고?다. 메모리가 부족? 상황이 아니면서 CPU 사용량이 높다면 현재 처리 중? 쿼리 중 테이블 풀 스캔을 유발하는 쿼리가 있는지를 확??야 ?다. 현재 수행 중? 쿼리 목록을 확?하려면 iSQL로 서버에 접속하여 V$STATEMENT 성능 뷰의 QUERY 칼럼을 조회하면 된다. 수행 중? 쿼리 중 의심되는 쿼리를 선정하여 실행 계획을 확?하고 ?제가 있다면 튜닝을 ?야 ?다. 쿼리 튜닝에 대? 자세? 내용은 이 매뉴얼의 “SQL 튜닝 ”장을 참조?다. 위의 두 경우에 ?당하지 않는다면 록을 기다리고 있는 상태를 의심? 수 있다. 현재 록 정보를 V$LOCK 과 V$LOCK_WAIT 성능 뷰로 확?하고 특정 세?이 불필요하게 록을 획득하고 있는 상태로 지속되고 있다면 ?당 세?을 강제로 종료하여 ?결? 수 있다. 부록 A: Trace Log 445 A. 부록: Trace Log 446 Administrators Manual Trace Log 아래 프로퍼티는 알티베이스 HDB 서버에서 수행되는 SQL?의 정보, 에러 메시지 종류 및 SQL ?의 수행 소요 시? 등을 altibase_boot.log 파?에 기록하게 ? 수 있는 프로퍼티이다. 이 프로퍼티의 기본 값은 0이며, 위의 정보들을 trace log로 기록하려면 1을 설정?다. 프로퍼티 파?에 명시된 값은 ALTER SYSTEM ?을 이용하여 변경? 수 있다. 프로퍼티에 대? 자세? 설명은 General Reference와 이 매뉴얼 11장의 “실행 계획 분석”?을 참고하기 바?다. TRCLOG 설명 TRCLOG_DETAIL_PREDICATE EXPLAIN PLAN 을 ON(또는 ONLY)로 설정시, where ?의 predicate 분류 상태도 함께 출력?지 를 지정함 부록 B: 알티베이스 최대치 447 B. 부록: 알티베이스 최대치 448 Administrators Manual 알티베이스 객체들의 최대값 아래의 표는 알티베이스 HDB에서 제공하는 객체들에 대? 최대 값을 정리? 내용으로 다음과 같다. 구분 객체의 최대값 비고 DB_NAME 길이 128 데이터베이스 이름의 최대 길이 OBJECT 길이 40 데이터베이스 객체 이름의 최대 길이 테이블스페이스 개수 64K (시스템 테이블스페이스 포함) ? DB내의 테이블스페이스 최대 개수 데이터 파? 개수 1,024 ? 테이블스페이스의 데이터 파? 최대 개수 67,108,864 (64K * 1024) ? DB내의 데이터 파? 최대 개수 사용자 개수 2,147,483,638(시스템 사용자 포함) ? DB내의 사용자 최대 개수 테이블 개수 2,097,151(메타 테이블 포함) ? DB내의 테이블 최대 개수 ?덱스 개수 64 테이블 당 ?덱스 최대 개수 컬럼 개수 1,024 테이블 당 컬럼 최대 개수 32 ?덱스 키 컬럼의 최대 개수 로우 개수 무? 개수 테이블 당 로우 최대 개수 파티? 개수 2,147,483,638 ? DB내의 파티? 최대 개수 제약사핫 개수 2,147,483,638 ? DB내의 제약사핫 최대 개수 찾아보기 449 찾아보기 Ａ active 로그 .......................................... 18 admin 디렉토리 .................................... 24 aexport ............................................... 30 AGGR 노드 ........................................ 326 AGGREGATION node ........................ 370 alaAPI.h .............................................. 25 altibase ............................................... 30 Altibase.jar .................................... 26, 33 altibase.properties ......................... 21, 25 altibase_boot.log ........................... 20, 28 altibase_id.log ..................................... 28 altibase_IPC.log ................................... 29 altibase_mt.log .................................... 29 altibase_odbc.dll .................................. 33 altibase_qp.log .................................... 29 altibase_rp.log ..................................... 29 altibase_sm.log.................................... 29 altierr .................................................. 30 altimon ............................................... 30 altipasswd ........................................... 30 altiprofile ............................................. 30 ANTI-OUTR-JOIN node ....................... 371 AOJN 노드 ......................................... 350 arch_logs 디렉토리 ............................... 24 audit ................................................... 30 audit 디렉토리 ..................................... 24 Ｂ BAG-UNION node .............................. 372 BCB ................................................... 212 BCB 상태 변화 ................................... 216 bin 디렉토리 ........................................ 24 b-tree ?덱스 ....................................... 67 Buffer Area........................................ 212 Buffer frame ...................................... 212 Buffer pool ........................................ 212 BUNI 노드 .......................................... 351 Ｃ CACHE ................................................ 76 Checkpoint Flush ............................... 217 Checkpoint List .................................. 215 checkServer ......................................... 31 CNF ................................................... 357 commit.............................................. 192 COMMIT_WRITE_WAIT_MODE .......... 427 CONC 노드 ........................................ 351 CONCATENATION node ..................... 373 conf 디렉토리 ...................................... 25 consistency .......................................... 12 constant filter .................................... 274 constraint ............................................ 50 Control 단계 ........................................ 38 cost ................................................... 357 COUNT node ..................................... 374 COUNT 노드 ...................................... 331 CYCLE ................................................. 76 Ｄ Database Link ...................................... 52 database objects .................................. 50 datafile ................................................ 18 dbs 디렉토리 ........................................ 25 DECRYPT ........................................... 417 directory .............................................. 52 DIRECT-PATH INSERT ........................... 13 Discard .............................................. 120 disk table ............................................. 54 distinct .............................................. 295 DISTINCT node .................................. 375 DISTINCT_HASH ................................ 360 DISTINCT_SORT ................................. 360 DNF ................................................... 357 DRDMBS ............................................... 3 dump_stack.sh .................................... 31 dumpla................................................ 31 dumplf ................................................ 31 450 Administrators Manual Ｅ ENCRYPT USING ................................ 416 exclusive lock ..................................... 194 execution plan ................................... 364 execution plan tree ............................ 256 executor ............................................ 260 Explain Plan의 개요 ............................ 364 extent ................................................. 97 Ｆ fault tolerance ..................................... 12 FILT 노드 ............................................ 321 filter .................................................. 274 FILTER node ....................................... 376 Flush List ........................................... 215 Flusher .............................................. 217 FOJN 노드 .......................................... 349 foreign key 제약조건 ............................ 64 FULL SCAN ........................................ 360 FULL-OUTER-JOIN node ..................... 376 Ｇ GRAG 노드 ........................................ 337 grant ................................................... 91 GRBY 노드 ......................................... 324 GROUP BUCKET COUNT .................... 359 Group Commit .................................. 426 GROUP_HASH ................................... 360 GROUP_SORT .................................... 360 GROUP-AGGREGATION node ............ 378 GROUPING node ............................... 379 Ｈ HASH BUCKET COUNT ....................... 359 HASH node ....................................... 379 HASH 노드 ........................................ 335 hash-based join ................................. 291 HIER 노드 .......................................... 331 HIERARCHICAL QUERY node ............. 381 high availability .................................... 12 hint ................................................... 356 Hit Ratio 구하기 ................................. 228 HSDS 노드 ......................................... 338 Hybrid DBMS ......................................... 2 Ｉ iloader ................................................. 31 include 디렉토리 .................................. 25 INCREMENT BY .................................... 76 index ............................................. 51, 67 INDEX ................................................ 360 INDEX ASC ........................................ 360 INDEX DESC ...................................... 360 install 디렉토리 ..................................... 26 integrity rule .......................................... 8 intensive exclusive lock ....................... 194 intensive exclusive shared lock ............ 194 intensive shared lock .......................... 194 IPC ...................................................... 12 isql ...................................................... 31 Ｊ join.................................................... 288 JOIN node .......................................... 383 JOIN 노드 ........................................... 344 Ｋ key filter ............................................ 274 key range........................................... 274 killCheckServer ..................................... 32 Ｌ LEFT-OUTER-JOIN node ...................... 384 LFG 기능의 제약사핫 ........................... 425 LFG기능의 ?계점 ............................... 425 lib 디렉토리 .......................................... 26 libodbccli.a .......................................... 33 libodbccli.ar ......................................... 27 libsesc.a ............................................... 26 limit ................................................... 297 LIMIT-SORT node ............................... 385 LMST 노드 ......................................... 342 load balancing ..................................... 12 lock ................................................... 194 Lock .................................................. 221 log anchor file ...................................... 18 log file ................................................. 18 Log File Creation Thread..................... 421 Log Flush Thread................................ 421 찾아보기 451 loganchor 파? .................................... 27 logs 디렉토리 ....................................... 27 LOJN 노드 ......................................... 348 LRU List ............................................. 214 Ｍ makefile .............................................. 28 MATERIALIZATION node .................... 386 materialized node .............................. 369 memory table ...................................... 54 merge join ......................................... 292 message file ........................................ 21 Message queue table ........................... 61 meta 단계 ........................................... 39 MGJN 노드 ........................................ 347 MINVALUE .......................................... 76 MMDBMS ............................................. 3 msg 디렉토리 ....................................... 27 MVCC ........................................... 9, 197 MVCC 사용 시 주의사핫 ..................... 204 Ｎ nested loop join ................................. 289 NO INDEX ......................................... 361 NO_PUSH_SELECT_VIEW ................... 360 non-materialized node ....................... 369 normalization .................................... 267 NOT NULL 제약조건.............................. 64 NULL 제약조건 ..................................... 64 Ｏ object privilege .................................... 90 Offline ............................................... 119 offline 백업 ....................................... 241 Online ............................................... 119 optimization ...................................... 264 optimizer ........................................... 261 order by ............................................ 297 ORDERED .......................................... 358 Ｐ page ................................................... 98 PARTITION-COORDINATOR ................ 395 PCRD 노드 ......................................... 355 PCTFREE .................................... 109, 156 PCTUSED ................................... 110, 156 Plan Nodes ........................................ 369 Plan Node의 종류 ............................... 369 plan tree ............................................ 364 Plan Tree ........................................... 367 Plan Tree 출력 ................................... 365 Prepare List ........................................ 215 primary key 제약조건 ............................ 64 privilege .............................................. 89 process 단계 ........................................ 38 PROJ 노드 .......................................... 323 PROJECT node ................................... 388 projection .......................................... 302 properties ............................................ 40 push selection 기법 ............................ 270 PUSH_SELECT_VIEW .......................... 360 Ｑ query processing ................................ 261 QUEUE table ....................................... 61 Ｒ relational model ..................................... 8 Replacement Flush ............................. 217 replication ..................................... 12, 52 revoke ................................................. 91 rollback ....................................... 18, 192 r-tree ?덱스 ........................................ 67 rule ................................................... 357 Ｓ sample 디렉토리 .................................. 28 savepoint........................................... 192 SCAN node ........................................ 389 SCAN 노드 ......................................... 317 schema objects .................................... 50 SDIF 노드 ........................................... 353 SECURITY_ECC_POLICY_NAME ......... 414 SECURITY_MODULE_LIBRARY ............ 414 SECURITY_MODULE_NAME ............... 414 Segment.............................................. 97 sequence ....................................... 51, 75 server .................................................. 32 ses.h ................................................... 26 452 Administrators Manual sesc ..................................................... 32 SET BUCKET COUNT .......................... 360 SET-DIFFERENCE node ....................... 390 SET-INTERSECT node ......................... 391 shared lock ........................................ 194 shmutil ................................................ 32 SHUTDOWN ABORT ............................ 47 SHUTDOWN IMMEDIATE ..................... 46 SHUTDOWN NORMAL ......................... 46 SITS 노드 ........................................... 352 SORT MERGE JOIN node .................... 387 SORT node ........................................ 393 SORT 노드 ......................................... 332 sort-based join ................................... 290 SQL Plan Cache 관? 프로퍼티 ............ 401 SQL Plan Cache의 특징 ....................... 400 SQL 튜닝 ........................................... 256 SQL 튜닝 ?반 .................................... 258 SQL92 ................................................... 9 sqlcli.h ................................................. 26 sqltypes.h ............................................ 26 sqlucode.h ........................................... 26 START WITH ........................................ 76 startup service ..................................... 44 startup 단계 ......................................... 45 STOR 노드 ......................................... 341 stored function .................................... 80 stored procedure ................................. 80 strore procedure or funuction .............. 51 subquery ........................................... 304 subquery filter ................................... 274 Subquery 유형 ................................... 304 synonym .............................................. 78 synonym .............................................. 51 SYS 사용자 ........................................... 87 sysdba 시스템 권? ............................... 44 system privilege ................................... 89 system table ........................................ 54 SYSTEM_ 사용자 .................................. 87 Ｔ table ................................................... 50 tablespace ........................................... 52 TCP/IP ................................................. 12 TIMESTAMP 제약조건 ........................... 64 Trace Log ........................................... 446 transaction ............................................ 9 Transaction Durability ........................ 206 trc 디렉토리 ......................................... 28 trigger ........................................... 51, 84 trigger action ....................................... 84 trigger envent ...................................... 84 trigger restriction ................................. 84 TSS .................................................... 203 Ｕ unique key 제약조건 ............................. 64 Unix Domain socket ............................. 12 USE_HASH ........................................ 358 USE_NL ............................................. 358 user ............................................... 53, 87 user table ............................................ 54 USER_MERGE .................................... 358 USER_SORT ....................................... 358 Ｖ view .............................................. 51, 73 VIEW Node ........................................ 394 VIEW 노드 ......................................... 327 VIEW-SCAN node .............................. 395 VMTR 노드 ........................................ 341 VSCN 노드 ......................................... 329 ㄱ 가비지 콜렉? 쓰레드 ............................ 16 가용성 .................................................. 12 객체 ....................................................... 8 객체 권? ............................................. 90 관계 모델 ............................................... 8 교체 플러시 ........................................ 217 권? ..................................................... 89 권? ?제 ............................................. 91 그룹 연산 ........................................... 293 그룹 커밋 ........................................... 426 그룹 커밋 관? 프로퍼티 튜닝 .............. 429 글로벌 ?덱스 ..................................... 168 기본 파티? ........................................ 171 찾아보기 453 ㄴ 노-아카이브 로그 ................................. 232 논리적 백업 ........................................ 230 논파티?드 객체 .................................. 160 논파티?드 ?덱스 ............................... 165 ㄷ 다중 버? 동시성 제어 기법 ................. 197 다중 비저장 노드 ................................ 355 다중버? 기법 ......................................... 9 단? 비저장 노드 ................................ 317 단? 저장 노드 ................................... 332 단? 키 ?덱스 ..................................... 68 대기 모드 ........................................... 220 대용량 메모리 테이블 ............................ 54 더블 라이트 .......................................... 10 데드락 감지 .......................................... 11 데이터 독립성 ......................................... 8 데이터 모델 ............................................ 8 데이터 암호화 ..................................... 415 데이터 테이블스페이스 ........................... 36 데이터베이스 객체 ................................. 50 데이터베이스 공? ................................. 13 데이터베이스 관? 프로퍼티 ................... 40 데이터베이스 릿크 ................................. 52 데이터베이스 모드 ............................... 232 데이터베이스 생성 ................................. 36 데이터베이스 이중화 .............................. 12 데이터베이스 정보 모니터릿 ................. 434 데이터베이스 종료 ................................. 39 데이터베이스 트리거 .............................. 51 데이터베이스의 논리적 구조 ................... 19 데이터베이스의 물리적 구조 ................... 17 디렉토리 ............................................... 52 디스카드 ............................................. 120 디스크 테이블 ............................... 54, 259 디스크 테이블스페이스 ................... 95, 108 디스크 테이블스페이스의 MVCC .......... 201 디스크로부터 페이지 인기 .................... 222 ㄹ 라이브러리 ........................................... 33 로그 파? ............................................. 37 로그 플러쉬 쓰레드 ............................. 421 로그 플러시 쓰레드 ............................... 17 로그파? 생성 쓰레드 .......................... 421 로그파?그룹 ....................................... 420 로깅 ..................................................... 10 로우 구조 ........................................... 111 로우 ?이그레이? ............................... 112 로우 체이닝 ........................................ 112 로컬 ?덱스 ........................................ 168 롤백 ................................................... 192 리스트 파티셔닝 .................................. 180 리스트 파티? 프루닝 .......................... 299 리스트 파티?드 객체에 대? 연산 ........ 181 ㅁ 매체 복구시 주의사핫 .......................... 239 매체복구 ............................................. 236 메모리 사용량 모니터릿 ....................... 434 메모리 테이블 ............................... 54, 259 메모리 테이블스페이스 ..................... 36, 99 메시지 파? .......................................... 21 메? 모듈 ............................................... 6 무결성 규칙 ............................................ 8 무정지 시스템 ....................................... 12 물리적 백업 ........................................ 230 ㅂ 백업 ................................................... 230 백업 시 주의사핫 ................................ 234 백업 정책 ........................................... 230 버퍼 관? 프로퍼티 ............................. 227 버퍼 관리 ........................................... 219 버퍼 관리자 구성요소 .......................... 212 버퍼 관리자 통계 정보 ......................... 228 버퍼 관리자의 구조 ............................. 212 버퍼 영역 ........................................... 212 버퍼 풀 ........................................ 10, 212 버퍼 플러시 쓰레드 ............................... 17 범위 파티셔닝 ..................................... 173 범위 파티? 프루닝 ............................. 298 범위 파티?드 객체에 대? 연산 ........... 175 베이스 테이블 ....................................... 73 보? 기능의 구성 ................................ 412 보? 모듈 구동 ................................... 415 보? 모듈 연동 방법 ............................ 413 보?의 개요 ........................................ 410 454 Administrators Manual 복구 ................................................... 236 복구 정책 ........................................... 236 복합 키 ?덱스...................................... 68 부트 파? ............................................. 20 부하 분산 ............................................. 12 불완? 복구 ........................................ 238 뷰 51, 73 비영구 저장 ?덱스 ............................... 69 ㅅ 사용자 ............................................ 53, 87 상태 모니터릿 ..................................... 434 상향식 ?덱스 생성 ............................... 71 서버 프로세스 ....................................... 16 서비스 데몬 쓰레드 ............................... 16 서비스 쓰레드 풀 .................................. 16 성능 관? 이슈.................................... 256 세그먼트 ............................................... 97 세? 관리 쓰레드 .................................. 16 세?/statement 모니터릿 ..................... 434 스키? 객체 .......................................... 50 시노님 ............................................ 51, 78 시스템 접? 권? .................................. 89 시스템 테이블 ....................................... 54 시퀀스 ............................................ 51, 75 실행 계획 ........................................... 311 실행 계획 트리.................................... 256 실행 노드 ........................................... 313 실행 바이너리 ....................................... 30 실행기 ................................................ 260 ㅇ 아카이브 로그 ..................................... 232 아카이브 로그 쓰레드 .......................... 421 아카이브 쓰레드 .................................... 17 알티베이스 problem tracking .............. 435 알티베이스 개념 ...................................... 2 알티베이스 구동 .................................... 44 알티베이스 구성도 ................................. 15 알티베이스 구조 .................................... 15 알티베이스 디렉토리 .............................. 24 알티베이스 모니터릿 ............................ 434 알티베이스 ?제상황 분석 .................... 435 알티베이스 종료 .................................... 46 알티베이스 특징 ...................................... 8 알티베이스 프로퍼티 파? ...................... 25 암호 칼럼 ........................................... 416 암호 칼럼으로 변경.............................. 417 암호 칼럼의 생성 ................................. 416 암호 칼럼의 ?제 ................................. 417 암호화 ................................................ 416 액세스 ................................................ 274 ?두 레코드 ........................................ 113 ?두 테이블스페이스 ...................... 36, 113 ?두 테이블스페이스 변경 .................... 117 ?두 테이블스페이스 크기 계산 ............. 148 엔? 구조 ............................................... 8 영구 저장 ?덱스 ................................... 68 영속성 ................................................ 206 오프라? ............................................. 119 오프라? 백업 ..................................... 241 오프라? 백업 ..................................... 231 온라? ................................................ 119 온라? 백업 ........................................ 231 완? 복구 ........................................... 238 외래 키 제약조건 ................................... 64 원격(Remote) 시스템 ............................ 12 유? 키 ?덱스 ...................................... 68 유? 키 제약조건 ................................... 64 이중화 ............................................ 12, 52 이중화된 테이블 .................................... 56 이? 비저장 노드 ................................. 344 이? 저장 노드 .................................... 352 익스?트 ............................................... 97 ?덱스 ............................................ 51, 67 ?덱스 변경 .......................................... 71 ?덱스 삭제 .......................................... 71 ?덱스 생성 .......................................... 69 ?덱스 종류 .......................................... 67 ?덱스 ?용 .......................................... 71 ?덱스의 생성 옵?................................ 70 ?터페이스 .............................................. 9 ?관성 .................................................. 12 ?반 사용자 테이블................................ 54 임시 테이블스페이스 .............................. 37 ㅈ 자바 클래스 라이브러리 ......................... 33 잠금 ................................................... 194 재시작 자동복구 .................................. 236 찾아보기 455 저장 관리자 ............................................ 5 저장 프로시저 ................................. 11, 80 저장 프로시저 및 저장 함수 ................... 51 저장 함수 ............................................. 80 저장점 ................................................ 192 접? 모드 ........................................... 219 정규화 ................................................ 267 제약조건 ............................................... 50 제약조건 관리 ....................................... 64 제약조건의 종류 .................................... 64 조건? ................................................ 269 조? ................................................... 288 조? 순서의 결정 ................................ 284 중복 키 ?덱스 ..................................... 68 지역(local) 시스템 ................................. 12 질의 처리 ........................................... 261 질의 처리기 ............................................ 6 질의 최적화 ........................................ 264 집합 연산의 최적화 ............................. 296 ㅊ 체크포?트 쓰레드 ................................. 16 체크포?트 플러시 ............................... 217 최적화기 ............................................. 261 ㅋ 칼럼 제약조건 ....................................... 65 커밋 ................................................... 192 큐 테이블 ............................................. 61 클라이?트-서버 ...................................... 8 ㅌ 테이블 .................................................. 50 테이블 관리 .......................................... 54 테이블 제약조건 .................................... 65 테이블/데이터베이스 ?팩? ................... 11 테이블스페이스 ............................... 52, 94 테이블스페이스 공? 관리 .................... 148 테이블스페이스 관리 ............................ 121 테이블스페이스 백업 ............................ 133 테이블스페이스 복구 ............................ 133 테이블스페이스 분류 ............................ 103 테이블스페이스 상태 ............................ 119 트?잭? ............................................. 190 트?잭? 세그먼트 ............................... 114 트?잭? 영속성 관리 방법 ................... 207 트?잭?의 철회 .................................... 18 트리거 .................................................. 84 트리거 액? .......................................... 84 트리거 이?트 ....................................... 84 트리거 조건 .......................................... 84 ㅍ 파티셔닝 ............................................. 160 파티셔닝 방법 ..................................... 173 파티? ?제조건 .................................. 171 파티? 조건 ........................................ 171 파티? 키 ........................................... 161 파티? 필터릿 ..................................... 301 파티?드 객체 ............................. 160, 163 파티?드 ?덱스 .................................. 165 파티?드 테이블 .................................. 163 파티?의 최적화 .................................. 298 퍼지 트 ........................... 11 페이지 .......................................... 98, 101 페이지 구조 ........................................ 108 페이지 리스트 ..................................... 101 페이지 리스트 다중화 ............................ 56 페이지 요청 처리 ?차 ......................... 220 프라이머리 제약조건 .............................. 64 프로젝? ............................................. 302 프로토콜 ............................................... 12 프로퍼티 ............................................... 40 프로퍼티 파? ....................................... 21 플러셔 ................................................ 217 플러시 ................................................ 224 ㅎ ?시 테이블 ................................ 214, 220 ?시 파티셔닝 ..................................... 184 ?시 파티? 프루닝 ............................. 300 ?시 파티?드 객체에 대? 연산 ........... 185 휘발성 테이블스페이스 ................... 37, 102 힌트 ................................................... 356 힌트 처리 정책 ................................... 356 힌트의 종류 ........................................ 357

ALTIBASE® HDB™ Application Development JDBC User ’s Manual Release 6.3.1 April 10, 2015 ALTIBASE HDB Application Development JDBC User ’s Manual Release 6.3.1 Copyright 2001~2015 Altibase Corporation. All rights reserved. This manual contains proprietary information of Altibase® Corporation; it is provided under a license agreement containing restric- tions on use and disclosure and is also protected by copyright patent and other intellectual property law. Reverse engineering of the software is prohibited. All trademarks, registered or otherwise, are the property of their respective owners Altibase Corporation 10F, Daerung PostTower II, 182-13, Guro-dong Guro-gu Seoul, 152-847, South Korea Telephone: +82-2-2082-1000 Fax: 82-2-2082-1099 Homepage: http://www.altibase.com iii Contents Preface ............................................................................................................................................................................ v About This Manual ...................................................................................................................................................................................vi Audience.......................................................................................................................................................................................vi Software Environment .............................................................................................................................................................vi Organization................................................................................................................................................................................vi Documentation Conventions ............................................................................................................................................. vii Related Reading ......................................................................................................................................................................... ix Online Manuals .......................................................................................................................................................................... ix Altibase Welcomes Your Comments .................................................................................................................................. ix 1. Starting JDBC.............................................................................................................................................................. 1 1.1 Installing the JDBC Driver ................................................................................................................................................................2 1.1.1 Version Compatibility .....................................................................................................................................................2 1.1.2 Checking the JDBC Driver Version .............................................................................................................................2 1.1.3 Setting CLASSPATH .........................................................................................................................................................2 1.2 Connecting to the Database...........................................................................................................................................................3 1.2.1 Loading Driver ..................................................................................................................................................................3 1.2.2 Configuring Connection Information .......................................................................................................................3 1.2.3 Connecting to the Database .......................................................................................................................................3 1.2.4 Example ...............................................................................................................................................................................3 1.2.5 Compiling and Running ................................................................................................................................................4 1.3 Connection Information...................................................................................................................................................................5 1.3.1 Setting Connection Attributes ....................................................................................................................................5 1.3.2 About Connection Attributes ......................................................................................................................................5 1.4 Using Statement and ResultSet .................................................................................................................................................. 16 1.4.1 Example ............................................................................................................................................................................ 16 1.5 JDBC Connection Failover ............................................................................................................................................................ 18 2. Basic Functions ......................................................................................................................................................... 19 2.1 IPv6 Connectivity ............................................................................................................................................................................. 20 2.1.1 Overview .......................................................................................................................................................................... 20 2.1.2 Prerequisites ................................................................................................................................................................... 20 2.1.3 How to Use IPv6............................................................................................................................................................. 20 2.1.4 Example ............................................................................................................................................................................ 21 2.2 Statement, PreparedStatement, and CallableStatement.................................................................................................. 22 2.2.1 Statement ........................................................................................................................................................................ 22 2.2.2 PreparedStatement ...................................................................................................................................................... 22 2.2.3 CallableStatement ........................................................................................................................................................ 23 2.3 Using the National Character Set ............................................................................................................................................... 24 2.3.1 Retrieving and Altering Data .................................................................................................................................... 24 2.3.2 Using Constant Strings ............................................................................................................................................... 24 3. Advanced Functions ................................................................................................................................................ 25 3.1 Auto-generated Keys ..................................................................................................................................................................... 26 3.1.1 How to Use Auto-generated Keys ........................................................................................................................... 26 3.1.2 Restrictions ...................................................................................................................................................................... 26 3.1.3 Example ............................................................................................................................................................................ 27 3.2 Timeout ............................................................................................................................................................................................... 28 3.2.1 Login Timeout ................................................................................................................................................................ 28 3.2.2 Response Timeout ........................................................................................................................................................ 28 3.3 DataSource ......................................................................................................................................................................................... 30 3.3.1 How to set DataSource ............................................................................................................................................... 30 3.3.2 Connecting with DataSource ............................................................................................... .................................... 30 3.4 Connection Pool .............................................................................................................................................................................. 31 3.4.1 Configuring Web Application Server (WAS) ........................................................................................................ 31 3.5 Multiple ResultSet ........................................................................................................................................................................... 34 3.6 JDBC and Failover ............................................................................................................................................................................ 35 3.6.1 What is a Failover? ........................................................................................................................................................ 35 iv 3.6.2 How to Use Failover ..................................................................................................................................................... 35 3.6.3 Code Examples .............................................................................................................................................................. 37 3.7 JDBC Escapes ..................................................................................................................................................................................... 40 3.8 How to Use ResultSet ..................................................................................................................................................................... 41 3.8.1 Creating ResultSet ........................................................................................................................................................ 41 3.8.2 ResultSet Types .............................................................................................................................................................. 41 3.8.3 Concurrency .................................................................................................................................................................... 42 3.8.4 Holdability ....................................................................................................................................................................... 42 3.8.5 Restrictions ...................................................................................................................................................................... 43 3.8.6 Detecting Holes ............................................................................................................................................................. 44 3.8.7 Fetch Size ......................................................................................................................................................................... 45 3.8.8 Refreshing Rows ............................................................................................................................................................ 45 3.9 DATE, TIME, TIMESTAMP ............................................................................................................................................................... 46 3.9.1 Meanings.......................................................................................................................................................................... 46 3.9.2 Conversion Table .......................................................................................................................................................... 46 3.10 GEOMETRY ....................................................................................................................................................................................... 48 3.10.1 How To Use GEOMETRY ........................................................................................................................................... 48 3.10.2 Example ......................................................................................................................................................................... 48 3.11 LOB ..................................................................................................................................................................................................... 49 3.11.1 Prerequisites ................................................................................................................................................................. 49 3.11.2 Using BLOB ................................................................................................................................................................... 49 3.11.3 Using CLOB Data ......................................................................................................................................................... 54 3.11.4 Freeing Resources ...................................................................................................................................................... 59 3.11.5 Restrictions ................................................................................................................................................................... 61 3.12 Controlling Autocommit ............................................................................................................................................................ 63 4. Tips ations ....................................................................................................................................... 65 4.1 Tips for Better Performance ......................................................................................................................................................... 66 5. Error Messages ......................................................................................................................................................... 67 5.1 SQLSTATE .......................................................................................................................................................................................... 68 AppendixA. Data Type Mapping ................................................................................................................................ 75 Data Type Mapping ............................................................................................................................................................................... 75 Converting Java Data Types to Database Data Types ............................................................................................................... 76 Converting Database Data Types to Java Data Types ............................................................................................................... 77 vPreface Preface JDBC Users’ Manual vi About This Manual This manual explains how to use the ALTIBASE HDB JDBC Driver. Audience This manual has been prepared for the following users of ALTIBASE HDB: Database administrators Application developers Programmers I t is r e c o mmended that those reading this manual possess the following background knowledge: Basic knowledge in the use of computers, operating systems, and operating system utilities Experience in using relational databases and an understanding of database concepts Computer programming experience Software Environment This manual has been prepared assuming that ALTIBASE HDB 6 will be used as the database ser ver. Organization This manual is organized as follows: Chapter1: Starting JDBC This chapter offers basic instructions on how to use the ALTIBASE HDB JDBC driver. Chapter2: Basic Functions This chapter explains how to connect to the database ser ver with an IPv6 address and compar- atively describes three statements that can be used in JDBC application programs. Chapter3: Advanced Functions This chapter introduces advanced functions provided by the ALTIBASE HDB JDBC driver and explains how to use them. Chapter4: Tips ations This chapter provides instructions for the efficient use of the ALTIBASE HDB JDBC driver. Chapter5: Error Messages This chapter lists SQLSTATE errors which can occur while using the ALTIBASE HDB JDBC driver. vii Preface Appendix A. Data Type Mapping This appendix lists the compatibility between ALTIBASE HDB data types and standard JDBC data types/Java data types. Documentation Conventions This section describes the conventions used in this manual. Understanding these conventions will make it easier to find information in this manual and in the other manuals in the series. There are two sets of conventions: Syntax Diagram Conventions S a m p l e Co d e Co nv e n t i o n s Syntax Diagram Conventions In this manual, the syntax of commands is described using diagrams composed of the following ele - ments: Element Description Indicates the star t of a command. If a syntactic element star ts with an arrow, it is not a complete command. Indicates that the command continues to the next line. If a syntactic element ends with this symbol, it is not a complete command. Indicates that the command continues from the previous line. If a syntactic element star ts with this symbol, it is not a com- plete command. Indicates the end of a statement. Indicates a mandator y element. Indicates an optional element. ; SELECT NOT JDBC Users’ Manual viii Sample Code Conventions The code examples explain SQL statements, stored procedures, iSQL statements, and other com- mand line syntax. The following table describes the printing conventions used in the code examples. Indicates a mandator y element comprised of options. One, and only one, option must be specified. Indicates an optional element comprised of options. Indicates an optional element in which multiple elements may be specified. A comma must precede all but the first element. Element Description ADD DROP ASC DESC , ASC DESC Convention Meaning Example [ ] Indicates an optional item. VARCHAR [(size)] [[FIXED |] VARIABLE] { } Indicates a mandator y field for which one or more items must be selected. { ENABLE | DISABLE | COMPILE } | A delimiter between optional or mandator y arguments. { ENABLE | DISABLE | COMPILE } [ ENABLE | DISABLE | COMPILE ] ix Preface Related Reading For additional technical information, please refer to the following manuals: Administrator ’s Manual Replication Manual Spatial SQL Reference Online Manuals Online versions of our manuals (PDF or HTML) are available from Altibase's Customer Suppor t site (http://suppor t.altibase.com/). Altibase Welcomes Your Comments Please feel free to send us your comments and suggestions regarding this manual. Your comments and suggestions are impor tant to us, and may be used to improve future versions of the manual. When you send your feedback, please make sure to include the following information: The name and version of the manual that you are using . . . Indicates that the previous argu- ment is repeated, or that sample code has been omitted. iSQL> select e_lastname from employees; E_LASTNAME ------------------------ Moon Davenport Kobain . . . 20 rows selected. Other symbols Symbols other than those shown above are par t of the actual code. EXEC :p1 := 1; acc NUMBER(11,2); Italics Statement elements in italics indi- cate variables and special values specified by the user. SELECT * FROM table_name; CONNECT userID/password; Lowe r Case Le t- ters Indicate program elements set by the user, such as table names, col- umn names, file names, etc. SELECT e_lastname FROM employ- ees; Upper Case Let- ters Keywords and all elements pro- vided by the system appear in upper case. DESC SYSTEM_.SYS_INDICES_; Convention Meaning Example JDBC Users’ Manual x Any comments that you have about the manual Your full name, address, and phone number For immediate assistance with technical issues, please contact Altibase’s Customer Suppor t site (http://suppor t.altibase.com/). We always appreciate your comments and suggestions. 1Starting JDBC 1 Starting JDBC This chapter offers basic instructions on how to use the ALTIBASE HDB JDBC driver. 1.1 Installing the JDBC Driver JDBC Users’ Manual 2 1.1 Installing the JDBC Driver Download and install the ALTIBASE HDB package from the Altibase homepage (www.altibase.com). Once the package is installed, the ALTIBASE HDB JDBC driver can be found in the $ALTIBASE_HOME/lib director y. 1.1.1 Version Compatibility The ALTIBASE HDB 6.3.1 JDBC driver is a Type 4 pure Java JDBC driver, which conforms to the JDBC 3.0 specification and operates normally on JDK 1.4 or higher. 1.1.2 Checking the JDBC Driver Version The versions of the installed JDBC driver and the JDK with which the driver has been compiled can be checked as below : $ java -jar $ALTIBASE_HOME/lib/Altibase.jar JDBC Driver Info : Altibase Ver = 6.3.1.0.0 for JavaVM v1.4, CMP:7.1.1, Oct 28 2013 13:51:29 1.1.3 Setting CLASSPATH To use ALTIBASE HDB JDBC, the ALTIBASE HDB JDBC driver has to be added to the CLASSPATH envi- ronment va riable. e.g.) When using the bash shell in the Unix environment export CLASSPATH=$ALTIBASE_HOME/lib/Altibase.jar:.:$CLASSPATH 1.2 Connecting to the Database 3Starting JDBC 1.2 C o nnec t ing t o the Da tabase This section offers basic instructions through program codes on how to connect to the ALTIBASE HDB ser ver with JDBC. 1.2.1 Loading Driver How to load the Driver class of the ALTIBASE HDB JDBC driver and locate the driver are shown below : 1. Register the ALTIBASE HDB JDBC driver with DriverManager. Class.forName("Altibase.jdbc.driver.AltibaseDriver"); 2. Acquire the driver from the DriverManager with the connection URL. String sURL = "jdbc:Altibase://localhost:20300/mydb"; Driver sDriver = DriverManager.getDriver( sURL ); 1.2.2 Configuring Connec tion Information Multiple connection information can be passed to the driver with the Properties object. The fol- lowing is a code example which sets connection attributes in the Properties object. Properties sProps = new Properties(); sProps.put("user", "SYS"); sProps.put("password", "MANAGER"); 1.2.3 Connec ting to the Database The database can be connected to with the connection URL and connection information. The fol- lowing is a code example which connects to the database and acquires the Connection object. Connection sCon = sDriver.connect(sURL, sProps); The format of the connection URL used for the argument of the connect() method above is shown below : jdbc:Altibase://server_ip:server_port/dbname 1.2.4 Example import java.sql.Connection; import java.sql.Driver; import java.sql.DriverManager; import java.util.Properties; public class ConnectionExample { public static void main(String[] args) throws Exception { String sURL = "jdbc:Altibase://localhost:20300/mydb"; Properties sProps = new Properties(); 1.2 Connecting to the Database JDBC Users’ Manual 4 sProps.put("user", "SYS"); sProps.put("password", "MANAGER"); Class.forName("Altibase.jdbc.driver.AltibaseDriver"); Driver sDriver = DriverManager.getDriver(sURL); Connection sCon = sDriver.connect(sURL, sProps); } } 1.2.5 Compiling and Running You can compile and run a JDBC application as follows: $ javac ConnectionExample.java $ java ConnectionExample 1.3 Connection Information 5Starting JDBC 1.3 C o nnec t ion Inf o rma tion This section offers information of connection attributes available for use when connecting to ALTI- BASE HDB, and explains how to set connection attributes. 1.3.1 Setting Connec tion Attributes Connection attributes necessar y for database connection can be set in theProperties object or specified in the connection URL. 1.3.1.1 Using the Connection URL The value of the proper ty can be specified by suffixing a ? at the end of the connection URL and fol- lowing it with the key=value format. Multiple properties can be input by connecting them with an owing is an example of a connection URL. "jdbc:Altibase://localhost:20300/mydb?fetch_enough=0 DB_TZ" 1.3.1.2 Using the Properties Objec t Af ter the Properties object has been created and the key and value have been input, it is ready to be used as connection information. The following example uses the Properties object: Properties sProps = new Properties(); sProps.put("fetch_enough", "30"); sProps.put("time_zone", "DB_TZ"); ... Connection sCon = DriverManager.getConnection( sURL, sProps ); 1.3.2 About Connec tion Attributes This section offers descriptions of the connection attributes available for use when connecting to ALTIBASE HDB. The following items are included in the description of each attribute: Default value: The value used by default, if no other value is specified. Range: The value available for specification. Mandator y : Whether or not the attribute must be specified. Setting range: Whether the attribute which is set affects the whole system or only affects the given session. Description 1.3 Connection Information JDBC Users’ Manual 6 1.3.2.1 alternateservers 1.3.2.2 app_info 1.3.2.3 auto_commit 1.3.2.4 clientside_auto_commit Default Value Range[ host_name:port_number [, host_name:port_number ]* Mandator y No Setting Range Description The list of ser vers available for connection in the event of a Connec- tion Failover. For instructions on its use, please refer to JDBC and Fa i l o v e r. Default Value Range A random string Mandator y No Setting Range The session Description Specifies the string to be stored in the CLIENT_APP_INFO column in V$SESSION. Default Valuetrue Range[true|false] Mandator y No Setting Range The session Description Sets whether or not to automatically commit the transaction when the execution of a statement is complete. Default Valueoff Range[on|off] Mandator y No Setting Range The session 1.3 Connection Information 7Starting JDBC 1.3.2.5 connectionretrycount 1.3.2.6 connectionretrydelay 1.3.2.7 database Description Sets whether autocommit operations are to be controlled by the ALTI- BASE HDB ser ver or the JDBC driver. The value set for this attribute is applied only if the auto_commit attribute is set to true or omitted. on: JDBC driver controls autocommit. off: ALTIBASE HDB ser ver controls autocommit. For fur ther information, please refer to Controlling Autocommit. Default Value0 Range A numerical value within the Unsigned Integer range [1 - 2 31 ] Mandator y No Setting Range Description Specifies the number of times reconnection is attempted to another server in the event of a Connection Failover. If this value is 1, reconnection to another ser ver is attempted once; therefore, connection is attempted two times in total. For instructions on its use, please refer to JDBC and Failover. Default Value0 Range A numerical value within the Unsigned Integer range [1 - 2 31 ] Mandator y No Setting Range Description Specifies the waiting time during which connection is attempted to another ser ver when connectionretrycount is set in the event of a Connection Failover. The unit is seconds. For instructions on its use, please refer to JDBC and Failover. Default Valuemydb Range The database name Mandator y No 1.3 Connection Information JDBC Users’ Manual 8 1.3.2.8 datasource 1.3.2.9 date_format 1.3.2.10 description 1.3.2.11 ddl_timeout Setting Range N/A Description The name of the database created in the HDB ser ver to be connected. Default Value Range [0 - 65535] Mandator y Mandator y to use DataSource Setting Range N/A Description The name of DataSource. Default Value The value set for the ALTIBASE_DATE_FORMAT environment vari- able. On omission, the IN/OUTPUT format of the DATE type takes the value set for the ser ver. Range A DATE format string Mandator y No Setting Range The system Description Sets the IN/OUTPUT format of the DATE type. If the format is set and a data of another format is input by the client, instead of treating it as a DATE t ype, an error is returned. Default Value Range A random string Mandator y No Setting Range N/A Description The description par t of DataSource. Default Value0 Range A numerical value within the Unsigned Integer range 1.3 Connection Information 9Starting JDBC 1.3.2.12 failover_source 1.3.2.13 fetch_enough 1.3.2.14 fetch_timeout Mandator y No Setting Range The session Description Sets the time limit for the execution of DDL statements. Queries which exceed the execution time limit are automatically terminated. The unit is seconds. The value 0 indicates infinity. Default Value Range A random string Mandator y No Setting Range Description Specifies the description of the Failover source to be passed to the ser ver, when per forming a Failover. This information is stored to the FAILOVER_SOURCE column in the V$SESSION per formance view. Default Value0 Range A numerical value within the Unsigned Integer range Mandator y No Setting Range The session Description Sets FetchSize for the current session. This indicates the number of rows to be retrieved per FETCH from the ser ver. If this value is 0, the JDBC driver fetches the maximum size of data that can be contained in one network packet from the ser ver. Default Value60 Range A numerical value within the Unsigned Integer range Mandator y No Setting Range The session 1.3 Connection Information JDBC Users’ Manual 10 1.3.2.15 healthcheckduration 1.3.2.16 idle_timeout 1.3.2.17 isolation_level Description Sets the time limit for the execution of SELEC T statements. Queries which exceed the execution time limit are automatically terminated. The unit is seconds. The value 0 indicates infinity. Default Value30 Range A numerical value within the Unsigned Integer range [1 - 2 31 ] Mandator y No Setting Range Description Specifies the inter val after which a ser ver on which a Failover has occurred is re -listed on the AlternativeServer list. If a Connection Failover occurs on a ser ver, the ser ver is removed from the AlternativeServer list. After a cer tain length of time, the removed ser ver is re -added to the AlternativeServer list and this inter val is determined by healthcheckduration. The unit is seconds. For instructions on its use, please refer to JDBC and Failover. Default Value0 Range A numerical value within the Unsigned Integer range Mandator y No Setting Range The session Description Sets the time limit during which the Connection stays connected without per forming any operations. The connection is automatically released when the time is up. The unit is seconds. The value 0 indicates infinity. Default Value Range[2|4|8] Mandator y No Setting Range The system 1.3 Connection Information 11 Starting JDBC 1.3.2.18 loadbalance 1.3.2.19 lob_cache_threshold 1.3.2.20 login_timeout Description2: TRANSACTION_READ_COMMITTED 4: TRANSACTION_REPEATABLE_READ 8: TRANSACTION_SERIALIZABLE Default Valueoff Range[on|off] Mandator y No Setting Range Description Specifies whether or not to use LoadBalance when attempting to connect to a ser ver listed on AlternateServers. If this value is set to on, a ser ver which has successfully reconnected in the event of a Connection Failover is lowered in connection prior- ity ; therefore, connection to another ser ver is attempted first in the event of the next Connection Failover. For instructions on its use, please refer to JDBC and Failover. Default Value8192 Range[0-8192] Mandator y No Setting Range The session Description Sets the maximum size of the LOB data to be cached on the client. Default Value Range A numerical value within the Unsigned Integer range Mandator y No Setting Range The session Description Sets the maximum waiting time for logging in. For fur ther informa- tion, please refer to Timeout. 1.3 Connection Information JDBC Users’ Manual 12 1.3.2.21 max_statements_per_session 1.3.2.22 ncharliteralreplace 1.3.2.23 password 1.3.2.24 port Default Value Range A numerical value within the Signed Shor t range Mandator y No Setting Range The session Description Specifies the maximum number of statements available for execution in one session. The value 0 indicates infinity. Default Valuefalse Range[true|false] Mandator y No Setting Range The session Description Specifies whether or not to check the existence of an NCHAR string (literal) within SQL statements on the client. Default Value Range Mandator y Yes Setting Range N/A Description The password of the user ID. Default Value20300 Range[0-65535] Mandator y No Setting Range N/A Description The por t number on which the HDB ser ver to be connected is listen- ing. 1.3 Connection Information 13 Starting JDBC 1.3.2.25 prefer_ipv6 1.3.2.26 privilege 1.3.2.27 query_timeout 1.3.2.28 remove_redundant_transmission Default Valuefalse Range[true|false] Mandator y No Setting Range Description Specifies whether to use the IPv6 address as it is, or to conver t it to IPv4 for use. For fur ther information, please refer to 2.1 IPv6 Connec- tivity. Default Value Range[normal|sysdba] Mandator y No Setting Range N/A Description The connection mode. normal: Normal mode sysdba:DBA mode Default Value600 Range A numerical value within the Unsigned Integer range Mandator y No Setting Range The session Description Sets the time limit for quer y execution. Queries which exceed the exe - cution time limit are automatically terminated. The unit is seconds. The value 0 indicates infinity. Default Value0 Range[0|1] Mandator y No 1.3 Connection Information JDBC Users’ Manual 14 1.3.2.29 response_timeout 1.3.2.30 server 1.3.2.31 sessionfailover 1.3.2.32 time_zone Setting Range The session Description Sets whether or not to use the duplicate data compression method for CHAR, VARCHAR, NCHAR, and NVARCHAR type strings. Default Value Range A numerical value within the Unsigned Integer range Mandator y No Setting Range The session Description Sets the maximum waiting time for a response. For fur ther informa- tion, please refer to Timeout. Default Valuelocalhost Range Please refer to IPv6 Connectivity. Mandator y Yes Setting Range N/A Description The IP address or host name of the HDB ser ver to be connected. Default Valueoff Range[on|off] Mandator y No Setting Range Description Sets whether or not to use Session Time Failover (STF). For instruc- tions on its use, please refer to JDBC and Failover. Default ValueDB_TZ ( The timezone set in the database is used) Range 1.3 Connection Information 15 Starting JDBC 1.3.2.33 user 1.3.2.34 utrans_timeout Mandator y No Setting Range The session Description Sets the time zone. For fur ther information, please refer to the TIME_ZONE proper ty in the General Reference. Default Value Range Mandator y Yes Setting Range N/A Description The user ID of the database to be connected. Default Value3600 Range A numerical value within the Unsigned Integer range Mandator y No Setting Range The session Description Sets the time limit for the execution of UPDATE statements. Queries which exceed the execution time limit are automatically terminated. The unit is seconds. The value 0 indicates infinity. 1.4 Using Statement and ResultSet JDBC Users’ Manual 16 1.4 Using Statement and ResultSet This section offers basic instructions through program codes on how to connect to the ALTIBASE HDB ser ver and execute SQL statements with JDBC. For convenience, instructions on how to handle exceptions are omitted. 1.4.1 Example import java.util.Properties; import java.sql.*; //... String sURL = "jdbc:Altibase://localhost:20300/mydb"; String sUser = "SYS"; String sPassword = "MANAGER"; Connection sCon = null; //Set properties for Connection Properties sProps = new Properties(); sProps.put( "user", sUser); sProps.put( "password", sPassword); // Load class to register Driver into DriverManager Class.forName("Altibase.jdbc.driver.AltibaseDriver"); // Create a Connection Object sCon = DriverManager.getConnection( sURL, sProps ); // Create a Statement Object Statement sStmt = sCon.createStatement(); // Execute DDL Type Query sStmt.execute("CREATE TABLE TEST ( C1 VARCHAR (10) )"); // Execute Inserting Query sStmt.execute("INSERT INTO TEST VALUES ('ABCDE')"); // Execute Selecting Query // Get Result Set from the Statement Object ResultSet sRs = sStmt.executeQuery("SELECT * FROM TEST"); // Get ResultSetMetaData Object ResultSetMetaData sRsMd = sRs.getMetaData(); // Retrieve ResultSet while(sRs.next()) { for(int i=1; i<=sRsMd.getColumnCount(); i++) { // Get Actual Data and Printout System.out.println(sRs.getObject(i)); } } // Eliminate ResultSet Resource sRs.close(); // Execute Updating Query sStmt.execute("UPDATE TEST SET C1 = 'abcde'"); 1.4 Using Statement and ResultSet 17 Starting JDBC // Execute Selecting Query // Get Result Set from the Statement Object sRs = sStmt.executeQuery("SELECT * FROM TEST"); // Get ResultSetMetaData Object sRsMd = sRs.getMetaData(); // Retrieve ResultSet while(sRs.next()) { for(int i=1; i<=sRsMd.getColumnCount(); i++) { // Get Actual Data and Printout System.out.println(sRs.getObject(i)); } } // Eliminate ResultSet Resource sRs.close(); // Execute Deleting Query sStmt.execute("DELETE FROM TEST"); // Execute Selecting Query // Get Result Set from the Statement Object sRs = sStmt.executeQuery("SELECT * FROM TEST"); // Get ResultSetMetaData Object sRsMd = sRs.getMetaData(); // Retrieve ResultSet while(sRs.next()) { for(int i=1; i<=sRsMd.getColumnCount(); i++) { // Get Actual Data and Printout System.out.println(sRs.getObject(i)); } } // Eliminate Resources sRs.close(); sStmt.close(); 1.5 JDBC Connection Failover JDBC Users’ Manual 18 1.5 JDBC Connec tion Failover The ser vice of an application implemented with the Altibase JDBC driver can be compromised due to the termination of one ser ver in an environment where multiple ALTIBASE HDB ser vers are run- ning, network failure, etc. In the event of such a failure, the client which connected to the ser ver on which the failure occurred detects the situation and automatically connects to another ser ver and processes the statements that were being executed; this process is called a Fail-over. For instructions on how to use the Fail- over feature in J D B C a p p l i c a t i o n s, p l e a s e re fe r t o C h a p t e r 4 . o f the Replication Manual. 19 Basic Functions 2 Basic Functions Database objects can be used with the ALTIBASE HDB JDBC driver in the same manner as using the standard JDBC inter face. This chapter explains how to connect to the database ser ver with an IPv6 address and comparatively describes three statements that can be used in JDBC application programs. 2.1 IPv6 Connectivity JDBC Users’ Manual 20 2.1 IPv6 Connec tivity The ALTIBASE HDB JDBC driver suppor ts the use of IPv6 addresses and host names conversible to IPv6 addresses in the JDBC URL. 2.1.1 Overview To specify an IPv6 address in the URL, the address must be enclosed in square brackets (“[ ]”). For example, when specifying the localhost to an IP address, brackets are not used for writing the IPv4 address, 127.0.0.1. Meanwhile, brackets are necessar y for using the IPv6 address, [::1]. For fur- ther information about IPv6 address notation, please refer to the Administrator ’s Manual. 2.1.2 Prerequisites 2.1.2.1 java.net.preferIPv4Stack To connect with an IPv6 address, the java.net.preferIPv4Stack proper ty must be set to FALSE when the client runs. If this proper ty is set to TRUE, the client application cannot connect to the database ser ver with an IPv6 address. $ java -Djava.net.preferIPv4Stack=false sample [::1] 2.1.2.2 java.net.preferIPv6Addresses Regardless of whether the java.net.preferIPv6Addresses proper ty is set to TRUE or FALSE, the ALTIBASE HDB JDBC driver is not affected. 2.1.2.3 PREFER_IPV6 If the host name is input to the server_ip proper ty of the URL, the JDBC driver converts the host name to an IPv4 address or an IPv6 address, depending on the value specified for the PREFER_IPV6 proper ty. If this proper ty is TRUE, and the host name is input to the server_ip proper ty, the client applica- tion first conver ts the host name to an IPv6 address. If this proper ty is omitted or set to FALSE, however, the client application program first conver ts the host name to an IPv4 address. If the client application fails on its first attempt to connect, it will attempt to re -connect with an IP address of a different version from the first. 2.1.3 How to Use IPv6 For IP addresses of the IPv6 format, the address value is available for specification as it is. Whether the JDBC driver is to convert the host name to an IPv4 address or an IPv6 address can be 2.1 IPv6 Connectivity 21 Basic Functions specified in the PREFER_IPV6 proper ty. Properties sProps = new Properties(); ... sProps.put( "PREFER_IPV6", "FALSE"); If the PREFER_IPV6 property is set to FALSE as above, the JDBC driver conver ts the host name to an IPv4 address. If the PREFER_IPV6 proper ty is TRUE and the host name is given, the application first conver ts the host name to an IPv6 address. If this proper ty is omitted or set to FALSE, the client application first conver ts the host name to an IPv4 address. The basic operation of a JDBC driver is the conversion of the host name to an IPv4 address. If the client application fails on its first attempt to connect with an IP address of a preferred version, it will attempt to re - connect with an IP address of another version. 2.1.4 Example Connection sCon = null; Properties sProps = new Properties(); sProps.put( "user", "SYS"); sProps.put( "password", "MANAGER"); sProps.put( "PREFER_IPV6", "FALSE"); String sURL = “jdbc:Altibase://localhost:20300/mydb"; Connection sCon = DriverManager.getConnection( sURL, sProps ); 2.2 Statement, PreparedStatement, and CallableStatement JDBC Users’ Manual 22 2.2 Statement, PreparedStatement, and Call- ableStatement Depending on whether or not an IN/OUTPUT parameter is used in a SQL statement or whether or not a SQL statement is directly executed, different Statement objects are available for use in JDBC. The following table shows whether or not the PREPARE function and IN/OUTPUT parameters are available for use for each Statement. 2.2.1 Statement Statement is mainly used for directly executing static SQL statements. 2.2.2 PreparedStatement PreparedStatement is mainly used for preparing the SQL statement before executing it. When the same statement is repeatedly executed, improved per formance can be anticipated with the use of PreparedStatement, instead of Statement. When the PreparedStatement object is created, the ALTIBASE HDB JDBC driver commands the ser ver to PREPARE the statement. If the ser ver fails to PREPARE, an error is returned and the JDBC driver throws an exception. Unlike Statement, input parameters can be used for PreparedStatement. A parameter is indi- cated as the ? character within a SQL statement and can be set to a value with the setXXX() method. 2.2.2.1 Example The following is a code example using IN parameters with PreparedStatement. PreparedStatement sPrepStmt = sConn.prepareCall("INSERT INTO t1 VALUES (?, ?)"); sPrepStmt.setInt(1, 1); sPrepStmt.setString(2, "string-value"); sPrepStmt.execute(); sPrepStmt.close(); PREPARE IN Parameter OUT Parameter StatementXXX Pr eparedState- me nt OOX Ca llableState- me nt OOO 2.2 Statement, PreparedStatement, and CallableStatement 23 Basic Functions 2.2.3 CallableStatement CallableStatement can be used with an input or output parameter. CallableStatement is mainly used for calling a stored procedure or a stored function. 2.2.3.1 Example The following is a code example using an IN parameter and an OUT parameter with CallableS- tatement. CallableStatement sCallStmt = connection().prepareCall("{call p1(?, ?)"); sCallStmt.setInt(1, 1); sCallStmt.registerOutParameter(2, Types.VARCHAR); sCallStmt.execute(); String sOutVal = sCallStmt.getString(2); // todo something ... sCallStmt.close(); 2.3 Using the National Character Set JDBC Users’ Manual 24 2.3 Using the National Charac ter Set This section offers instructions on how to use national character strings on UNICODE types, such as NCHAR or NVARCHAR types, in JDBC. 2.3.1 Retrieving and Altering Data Data of NCHAR/NVARCHAR data types can be retrieved and altered with JDBC in the same manner as retrieving and altering data of CHAR/VARCHAR types. The same methods used for the CHAR data type (e.g. getString,setString, etc.) can be used. 2.3.2 Using Constant Strings How to use a constant string with a national character in a SQL statement is shown below : Set the NcharLiter alReplace property to TRUE when connecting to the ser ver. To use a national character string in a SQL statement as a constant string, prefix N to the string. 2.3.2.1 Example // create table t1 (c1 nvarchar(1000)); Properties sProps; sProps.put( "user", "SYS"); sProps.put( "password", "MANAGER"); sProps.put( "NcharLiteralReplace", "true"); Connection sCon = DriverManager.getConnection( sURL, sProps ); Statement sStmt = sCon.createStatement(); sStmt.execute("insert into t1 values (N'AB가나')"); ResultSet sRS = sStmt.executeQuery( "select * from t1 where c1 like N'%가나 %'"); 25 Advanced Functions 3 Advanced Functions This chapter introduces advanced functions provided by the ALTIBASE HDB JDBC driver and explains how to use them. 3.1 Auto-generated Keys JDBC Users’ Manual 26 3.1 Auto -generated Keys Auto-generated keys are values which distinctly point to each row in a table, and are automatically generated in the database. In ALTIBASE HDB, a sequence can act as auto-generated keys. This section explains how to obtain the values of auto-generated keys in JDBC. 3.1.1 How to Use Auto-generated Keys To obtain an auto-generated key, first the Statement object is executed with a method specifying the column for which auto-generated keys are to be obtained. ResultSet of the auto-generated keys can be retrieved with the getGeneratedKeys() method. Or, after having created the PreparedStatement object with a method specifying the column for which auto-generated keys are to be obtained and executing it, ResultSet of the auto-gener- ated keys can be retrieved with the getGeneratedKeys() method. The following are Statement methods that execute SQL statements which retrieve auto-gener- ated keys. public boolean execute(String aSql, int aAutoGeneratedKeys) throws SQLExcep- tion; public boolean execute(String aSql, int[] aColumnIndexes) throws SQLExcep- tion; public boolean execute(String aSql, String[] aColumnNames) throws SQLExcep- tion; The following are Connection methods that create the PreparedStatement object which retrieve auto-generated keys. public PreparedStatement prepareStatement(String aSql, int aAutoGenerated- Keys) throws SQLException; public PreparedStatement prepareStatement(String aSql, int[] aColumnIndexes) throws SQLException; public PreparedStatement prepareStatement(String aSql, String[] aColumnNames) throws SQLException; After having executed a SQL statement in one of the above two ways, auto-generated keys can be obtained by a ResultSet object with the following Statement() method. public ResultSet getGeneratedKeys() throws SQLException; 3.1.2 Restrictions When obtaining auto-generated keys in ALTIBASE HDB, the following restrictions apply : Its use is only suppor ted for simple INSERT statements. Since ALTIBASE HDB does not suppor t columns with the AUTO_INCREMENT proper ty, auto- generated keys can only be obtained from a sequence. The following is an example of a SQL statement from which auto-generated keys can be obtained. INSERT INTO t1 (id, val) VALUES (t1_id_seq.nextval, ?); 3.1 Auto-generated Keys 27 Advanced Functions The following is an example of a SQL statement from which auto-generated keys cannot be obtained. SELECT * FROM t1; EXEC p1; If a SQL statement which does not produce auto-generated keys is executed with the generator flag (Statement.RETURN_GENERATED_KEYS), the flag is ignored and the getGeneratedKeys() method returns an empty result set. 3.1.3 Example sStmt.executeUpdate(sQstr, Statement.RETURN_GENERATED_KEYS); ResultSet sKeys = sStmt.getGeneratedKeys(); while (sKeys.next()) { int sKey = sKeys.getInt(1); // do somethings... } sKeys.close(); sStmt.close(); 3.2 Timeout JDBC Users’ Manual 28 3.2 Timeout This section gives an explanation of timeouts which can occur in a client session connected to the ALTIBASE HDB ser ver and provides code examples to show how to set proper ties related to time - outs. 3.2.1 Login Timeout A login timeout occurs when a connect() method of a Connection object is called and a response is not received from the ser ver within the maximum waiting time. The maximum waiting time is set in the login_timeout property and the unit is seconds. 3.2.1.1 Code Examples The following are code examples which show two ways to set the login_timeout proper ty. 1. Create a Connection object with the Properties object to which the timeout proper ty has been added. Properties sProps = new Properties(); ... sProps("login_timeout", "100"); ... Connection sCon = DriverManager.getConnection( sUrl, sProps ); 2. Create a Connection object with a connection URL which specifies the timeout proper ty. String sUrl = "jdbc:Altibase://localhost:20300/mydb?login_timeout=100"; Connection sCon = DriverManager.getConnection( sUrl ); 3.2.2 Response Timeout A response timeout occurs when the maximum waiting time for a response from the ALTIBASE HDB ser ver is exceeded. The maximum waiting time is set in the response_timeout proper ty and the unit is seconds. This value is applied to all methods which communicate with the server. 3.2.2.1 Code Examples The following are code examples which show different ways to set the response_timeout prop- er ty. 1. Create a Connection object with a Properties object to which the timeout proper ty has been added. Properties sProps = new Properties(); ... sProps("response_timeout", "100"); ... Connection sCon = DriverManager.getConnection( sUrl, sProps ); 2. Create a Connection object with a connection URL which specifies the timeout proper ty. 3.2 Timeout 29 Advanced Functions String sUrl = "jdbc:Altibase://localhost:20300/ mydb?response_timeout=100"; Connection sCon = DriverManager.getConnection( sUrl ); 3. Pass it as an argument when the application is running. java ... -DALTIBASE_RESPONSE_TIMEOUT=100 ... 4. Set the environment variable. // Linux export ALTIBASE_RESPONSE_TIMEOUT=100 // Windows set ALTIBASE_RESPONSE_TIMEOUT=100 3.3 DataSource JDBC Users’ Manual 30 3.3 DataSource The ALTIBASE HDB JDBC driver offers a way to connect to the database with a file that contains con- nection configurations. DataSource is the set of connection information to a database ser ver in the configuration file. 3.3.1 How to set DataSource DataSource is set in the following format to the altibase_cli.ini file. # comment [ datasource_name ] Server=localhost # comment Port=20300 User=sys Password=manager Additional connection proper ties can be added by writing strings of the key=value fo r mat in lines. The JDBC driver searches for the altibase_cli.ini file in the paths of the following order: 1./altibase_cli.ini 2.$HOME/altibase_cli.ini 3.$ALTIBASE_HOME/conf/altibase_cli.ini 3.3.2 Connec ting with DataSource To connect to the ser ver with DataSource, the DataSource Name (DSN) specified in the altibase_cli.ini file should be specified in a connection URL, instead of the IP address and por t number. The following is an example of a connection URL using a DSN. jdbc:Altibase://datasource_name jdbc:Altibase://datasource_name:20301 jdbc:Altibase://datasource_name:20301?sys=user wd When specifying a DSN in a connection URL, por t or other proper ties can be additionally specified. If a proper ty specified in the altibase_cli.ini file is duplicately specified in a connection URL, however, the file value is ignored and the connection URL value is used. 3.4 Connection Pool 31 Advanced Functions 3.4 Connec tion Pool A Connection Pool can be set and managed in the following manner. Use AltibaseConne ctionPoolDataSource: When using a Connection Pool in WAS, specify this class in the JDBC Connection Pool configuration of WAS. The name of this class was ABConnectionPoolDataSource for ALTIBASE HDB JDBC drivers of versions prior to 6.3.1. 3.4.1 Configuring Web Application Ser ver ( WAS) ALTIBASE HDB can be used with the following web application ser vers. Tomcat 8.x WebLogic 12.x Jeus 6.x F o r fur t he r inf o r m ation about ho w to con f ig ur e an d use t h e c o nn ec tio n po ol and JDB C dr iv e r o n each web application, please refer to their manuals. 3.4.1.1 Tomcat 8.x For fur ther information about how to install and configure Apache Tomcat, please refer to http:// tomcat.apache.org/tomcat-8.0-doc/index.html. Contex t con fi gu ratio n Add the JNDI DataSource to the Context as below : web.xml configu ration Altibase Datasource example jdbc/altihdb javax.sql.DataSource Container Co de exa mp l e Context initContext = new InitialContext(); Context envContext = (Context)initContext.lookup("java:/comp/env"); DataSource ds = (DataSource)envContext.lookup("jdbc/altihdb"); 3.4 Connection Pool JDBC Users’ Manual 32 Connection conn = ds.getConnection(); // ... 3.4.1.2 WebLogic 12.x For fur ther information about how to install and configure the WebLogic ser ver, please refer to http:/ /docs.oracle.com/middleware/1213/wls/index.html. You can configure the connection pool and the JDBC DataSource by referring to the following links: http://docs.oracle.com/middleware/1213/wls/WLACH/taskhelp/jdbc/jdbc_datasources/Cre - ateDataSources.html http://docs.oracle.com/middleware/1213/wls/WLACH/pagehelp/JDBCjdbcdatasourcesjdbc- datasourceconfigconnectionpooltitle.html The configuration options for ALTIBASE HDB are as follows: Database Type: Other Driver Class Name: Altibase.jdbc.driver.AltibaseDriver URL: jdbc:Altibase://loc alhost:20300/mydb 3.4.1.3 Jeus 6.x Set the Connection Pool by editing the element of the $JEUS_HOME/config/ JeusMain.xml file. others jdbc/altihdb Altibase.jdbc.driver.AltibaseConnectionPoolDataSource ConnectionPoolDataSource true PortNumber java.lang.Integer 20300 Password java.lang.String MANAGER ServerName java.lang.String localhost ConnectionAttributes java.lang.String 3.4 Connection Pool 33 Advanced Functions ;create=true DatabaseName java.lang.String mydb User java.lang.String SYS 3.5 Multiple ResultSet JDBC Users’ Manual 34 3.5 Multiple ResultSet Stored procedures and stored functions (PSMs) for ALTIBASE HDB can return a multiple number of result sets to the client. Using an example that returns multiple result sets, this section offers instruc- tions through a code example on how to use these result sets in JDBC applications. The following is an example of a PSM which returns multiple result sets. CREATE TYPESET my_type AS TYPE my_cur IS REF CURSOR; END; CREATE PROCEDURE p1 (p1 OUT MY_TYPE.MY_CUR, p2 out MY_TYPE.MY_CUR) AS BEGIN OPEN p1 FOR 'SELECT * FROM t1'; OPEN p1 FOR 'SELECT * FROM t2'; END; The following is an example of a code which uses multiple result sets returned by a call to a PSM in a JDBC application. CallableStatement sCallStmt = connection().prepareCall("{call p1()}"); sCallStmt.execute(); ResultSet sRs = null; ResultSetMetaData sRsMd = null; do{ sRs = sCallStmt.getResultSet(); sRsMd = sRs.getMetaData(); if(sRsMd != null) { while(sRs.next()) { // do something for(int i=1; i <= sRsMd.getColumnCount(); i++) { System.out.println(sRs.getString(i)); } } } }while(stmt.getMoreResults()); sCallStmt.close(); 3.6 JDBC and Failover 35 Advanced Functions 3.6 JDBC and Failover This section explains how to use the Failover feature in an ALTIBASE JDBC application. 3.6.1 What is a Failover? When a failure occurs on the database ser ver and the connection is disconnected, a Failover is a fea- ture which enables the application to immediately establish a connection to another ser ver to con- tinue the execution of the previously executed operation. Failover can operate in the following two ways: Connection Time Failover (C TF) C TF attempts to connect to another ser ver when an attempt to connect to the database is unsuccessful. C TF can occur when the connect() method of a Connection object is called. Session Time Failover (STF) STF connects to another ser ver and continuously executes the user-specified operation when a connection error occurs before the result of a SQL statement is received from the ser ver. STF can occur on the execution of all methods communicating with the ser ver, excluding the connect() method. For fur ther information about Failover, please refer to the “Failover ” chapter of the Replication Man- ual. 3.6.2 How to Use Failover This section explains how to use the C TF and STF features in JDBC applications. 3.6.2.1 CTF The C TF feature can be used by adding the following proper ties to the Properties object. Properties sProps = new Properties(); sProps.put("alternateservers", "database1:20300, database2:20300"); sProps.put("loadbalance", "on"); sProps.put("connectionretrycount", "5"); sProps.put("connectionretrydelay", "2"); sProps.put("sessionfailover", "on"); sProps.put("healthcheckduration", "30"); sProps.put("failover_source", "DSN1"); For fur ther information about each of the proper ties, please refer to Connection Information. 3.6.2.2 STF The STF feature can be used by additionally setting SessionFailover=on to the proper ties which set the C TF feature. 3.6 JDBC and Failover JDBC Users’ Manual 36 In communication situations other than attempting to establish connection to the database ser ver, the client first processes C TF and restores the connection when it detects ser ver failure. Thereafter, the client executes the callback function registered by the user and raises a failover suc- cess exception for the user to ack nowledge that a Failover has occurred. If Failover fails to ever y ser ver, the driver throws the exception which originally occurred. The following is an inter face for the failoverCallback function written by the user. public interface AltibaseFailoverCallback { public final static class Event { public static final int BEGIN = 0; public static final int COMPLETED = 1; public static final int ABORT = 2; } public final static class Result { public static final int GO = 3; public static final int QUIT = 4; } int failoverCallback(Connection aConnection, Object aAppContext, int aFailoverEvent); }; The following is a code example which shows the process of a user registering and freeing a failoverCallback function. public class UserDefinedFailoverCallback implements AltibaseFailoverCallback { ... public int failoverCallback(Connection aConnection, Object aAppContext, int aFailoverEvent) { // User Defined Code // Must return either Result.GO or Result.QUIT. } ... } If the failoverCallback function written by the user is called by the JDBC driver, one of the Event constants included in the above AltibaseFailoverCallback inter face is passed to FailoverEvent, which is the third argument of the callback function. The meaning of each Event constant is as follows: Event.BEGIN: Session Failover is star ted Event.COMPLETED: Session Failover has succeeded Event.ABORT: Session Failover has failed The Result constants included in the AltibaseFailoverCallback inter face are values which can be returned by the callback function written by the user. If values other than Result constants are returned from the callback function, Failover does not operate normally. Result.GO: If this constant value is returned from the callback function, the JDBC driver 3.6 JDBC and Failover 37 Advanced Functions continually runs the next process of STF. Result.QUIT: If this constant value is returned from the callback function, the JDBC driver terminates the STF process. The following is a code example of an object which can be used as the second argument of the failoverCallback function written by the user. public class UserDefinedAppContext { // User Defined Code } If there is a need to use information of an application implemented by the user during the STF pro- cess, the object to be passed to the callback function while registering the failoverCall- back function can be specified. If this object is specified as the second argument of the registerFailoverCallback() method which registers the callback function, this object is passed when the callback function is actually called. The following is an example which depicts this process in code. // Create a user-defined callback function object. UserDefinedFailoverCallback sCallback = new UserDefinedFailoverCallback(); // Create a user-defined application information object UserDefinedAppContext sAppContext = new UserDefinedAppContext(); ... Connection sCon = DriverManager.getConnection(sURL, sProp); // Register the callback function with the user-defined application object ((AltibaseConnection)sCon).registerFailoverCallback(sCallback, sAppContext); ... // Free the callback function ((AltibaseConnection)sCon).deregisterFailoverCallback(); 3.6.3 Code Examples This is a code example which implements a callback function for STF. The following is an example of a simple code which is regardless of various circumstances; therefore, it should be noted that it cannot be used as it is in user applications. public class MyFailoverCallback implements AltibaseFailoverCallback { public int failoverCallback(Connection aConnection, Object aAppCon- text,int aFailoverEvent) { Statement sStmt = null; ResultSet sRes = null; switch (aFailoverEvent) { // Necessary operations before starting Failover on the user application logic can be executed. case Event.BEGIN: System.out.println(“Failover Started .... “); break; // Necessary operations after completing Failover on the user 3.6 JDBC and Failover JDBC Users’ Manual 38 application logic can be executed. case Event.COMPLETED: try { sStmt = aConnection.createStatement(); } catch( SQLException ex1 ) { try { sStmt.close(); } catch( SQLException ex3 ) { } return Result.QUIT; } try { sRes = sStmt.executeQuery("select 1 from dual"); while(sRes.next()) { if(sRes.getInt(1) == 1 ) { break; } } } catch ( SQLException ex2 ) { try { sStmt.close(); } catch( SQLException ex3 ) { } // Terminates the Failover process. return Result.QUIT; } break; } // Continues the Failover process. return Result.GO; } } The following is a code example which checks whether or not STF was successful. Whether STF suc- ceeded or failed can be confirmed by checking whether ErrorCode of SQLException is identical to Validation.FAILOVER_SUCCESS. The Failover validation code is inser ted inside WHILE LOOP because the operation which was previously under execution must be executed again, even if Failover succeeds. // Must be implemented so that the operation to be executed can be re-exe- cuted.. // The while loop has been used in this case. while (true) { try { sStmt = sConn.createStatement(); sRes = sStmt.executeQuery("SELECT C1 FROM T1"); while (sRes.next()) 3.6 JDBC and Failover 39 Advanced Functions { System.out.println("VALUE : " + sRes.getString(1)); } } catch (SQLException e) { // Whether or not the Failover has succeeded. if (e.getErrorCode() == AltibaseFailoverCallback.FailoverValida- tion.FAILOVER_SUCCESS) { // Since Failover has succeeded, Exception is ignored and the pro- cess is continued. continue; } System.out.println("EXCEPTION : " + e.getMessage()); } break; } 3.7 JDBC Escapes JDBC Users’ Manual 40 3.7 JDBC Escapes The JDBC specification provides the escape syntax for the JDBC application to understand vendor specific SQL for database products. The JDBC driver converts a SQL statement which includes the escape syntax to a native SQL statement for its database. The following table is an organization of SQL statements which include the escape syntax suppor ted by the JDBC specification and SQL statements conver ted by the JDBC driver for use in ALTIBASE HDB. Ty p eSQL Statements Suppor ted in the JDBC Specification SQL Statements Conver ted for Use in ALTIBASE HDB ESCAPE SELECT cVARCHAR FROM t1 WHERE cVARCHAR LIKE '%a|%b%' {escape '|'} SELECT cVARCHAR FROM t1 WHERE cVARCHAR LIKE '%a|%b%' escape '|' FN SELECT {fn concat('concat', 'test')} FROM dual SELECT concat('concat', 'test') FROM dual DT S UPDATE t1 SET cDATE = {d '1234-12-30'} UPDATE t1 SET cDATE = to_date('1234-12-30', 'yyyy-MM- dd') UPDATE t1 SET cDATE = {t '12:34:56'} UPDATE t1 SET cDATE = to_date('12:34:56', 'hh24:mi:ss') UPDATE t1 SET cDATE = {ts '2010-01-23 12:23:45'} UPDATE t1 SET cDATE = to_date('2010-01-23 12:23:45', 'yyyy-MM-dd hh24:mi:ss') UPDATE t1 SET cDATE = {ts '2010-11-29 23:01:23.971589'} UPDATE t1 SET cDATE = to_date('2010-11-29 23:01:23.971589', 'yyyy-MM-dd hh24:mi:ss.ff6') CALL {call p1()} execute p1() {? = call p2(?)} execute ? := p2(?) OJ SELECT * FROM {oj t1 LEFT OUTER JOIN t2 ON t1.cINT = t2.cINT} SELECT * FROM t1 LEFT OUTER JOIN t2 ON t1.cINT = t2.cINT 3.8 How to Use ResultSet 41 Advanced Functions 3.8 How to Use ResultSet This section explains the ResultSet types suppor ted by the ALTIBASE HDB JDBC driver and offers instructions on how to use it. 3.8.1 Creating ResultSet ResultSet is created when a quer y statement is executed on the database, and it corresponds to the ResultSet object of JDBC. The following methods create the ResultSet object in JDBC. public Statement createStatement(int aResultSetType, int aResultSetConcur- rency) throws SQLException; public Statement createStatement(int aResultSetType, int aResultSetConcur- rency, int aResultSetHoldability) throws SQLException; public PreparedStatement prepareStatement(String aSql, int aResultSetType, int aResultSetConcurrency) throws SQLException; public PreparedStatement prepareStatement(String aSql, int aResultSetType, int aResultSetConcurrency, int aResultSetHoldability) throws SQLException; public CallableStatement prepareCall(String aSql, int aResultSetType, int aResultSetConcurrency) throws SQLException public CallableStatement prepareCall(String aSql, int aResultSetType, int aResultSetConcurrency, int aResultSetHoldability) throws SQLException; 3.8.2 ResultSet Ty p e s The ResultSet object of JDBC manages and retains the cursor which points to the current posi- tion within the result set. The cursor of a basic ResultSet object is not updateable and only moves for ward; however, a scrollable and updateable ResultSet object can be created with the use of options. The following are ResultSet object types available for user specification. TYPE_FORWARD_ONLY Unscrollable; the cursor can be moved only for ward. Data of the ResultSet is determined at the point in time at which the cursor opens in the database ser ver. TYPE_SCROLL_INSENSITIVE Scrollable; the cursor can be moved for ward, backwards, or moved to a specified location. Data of the ResultSet is determined at the point in time at which the cursor opens in the data- base ser ver. Memor y can become scarce, due to caching the ResultSet retrieved from the ser ver on the client. TYPE_SCROLL_SENSITIVE Scrollable; the cursor can be moved for ward, backwards, or moved to a specified location. The ResultSet is determined at the point in time at which the cursor opens in the database 3.8 How to Use ResultSet JDBC Users’ Manual 42 ser ver; however, data within ResultSet is determined at the point in time at which the cli- ent retrieves or updates it. 3.8.3 Concurrency This option determines whether or not to allow updates through the ResultSet object. One of the following two constants is available for use: CONCUR_READ_ONLY Does not allow updates; the default value. CONCUR_UPDATABLE Allows updates with the ResultSet object. 3.8.4 Holdability This option determines whether or not to retain the ResultSet object after the transaction has been committed. One of the following two constants are available for use: CLOSE_CURSORS_AT_COMMIT The cursor is closed when the transaction is committed. HOLD_CURSORS_OVER_COMMIT The cursor is left open, even if the transaction is committed. If the transaction has been com- mitted at least once after the cursor has been opened, the cursor is left open during future commit and rollback operations. If the transaction has not been committed even once since the cursor has been opened, however, the cursor is closed when the transaction is rolled back. 3.8.4.1 Notes Since the JDBC driver caches as many number of rows as the value set for FetchSize for the ResultSet object on the client, data left in the cache can be retrieved by the application, even if the cursor is closed. If you want the application to immediately detect that the cursor has been closed, set FetchSize to 1. The default value of holdability for the ALTIBASE HDB JDBC driver is CLOSE_CURSORS_AT_COMMIT, and is different from the default value for the JDBC specifi- cation, HOLD_CURSORS_OVER_COMMIT. Open ResultSet objects must be closed prior to switching the autocommit mode with the setAutoCommit() method in a session where holdability is HOLD_CURSORS_OVER_COMMIT. The following is a code example which raises an error. sCon = getConnection(); sStmt = sCon.createStatement(); byte[] br; byte[] bb = new byte[48]; for(byte i = 0; i 1 The following exception is raised at 1. java.sql.SQLException: Several statements still open at Altibase.jdbc.driver.ex.Error.processServerError(Error.java:320) at Altibase.jdbc.driver.AltibaseConnection.setAutoCommit(AltibaseC- onnection.java:988) at HodabilityTest.testHoldability(HodabilityTest.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccesso- rImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethod- AccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) sRs.close() must be called before sCon.setAutoCommit(true) to not raise an exception. The client session must be in non-autocommit mode or the clientside_auto_commit connection attribute must be set to on to use a ResultSet object whose holdability type is HOLD_CURSORS_OVER_COMMIT. If the clientside_auto_commit connection attri- bute is set to on, the holdability type is automatically changed to HOLD_CURSORS_OVER_COMMIT. 3.8.4.2 Example Statement sUpdStmt = sConn.prepareStatement("UPDATE t1 SET val = ? WHERE id = ?"); Statement sSelStmt = sConn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.HOLD_CURSORS_OVER_COMMIT); ResultSet sRS = sSelStmt.executeQuery("SELECT * FROM t1"); while (sRS.next()) { // TODO : set parameters sUpdStmt.execute(); sConn.commit(); } sRS.close(); 3.8.5 Restrictions To use an updatable ResultSet or a scrollable ResultSet, a SELECT statement which retrieves 3.8 How to Use ResultSet JDBC Users’ Manual 44 the ResultSet is restricted in the following ways: To use an updatable ResultSet, Only one table can be specified in the FROM clause. Only pure columns can be specified in the SELECT list; expressions or functions cannot be included. Columns with a NOT NULL constraint, and without a default value must be included in the SELECT list. To use a scrollable -sensitive ResultSet, Only one table can be specified in the FROM clause. When executing PSM, only ResultSet objects of the default type are available for use. If the user specifies an option which is not of the default type, the option is ignored. Since for a ResultSet object which is CONCUR_UPDATABLE and TYPE_SCROLL_SENSITIVE, one more Statement is used within the JDBC driver, it can easily exceed the limited number of Statements; therefore, the maximum number of Statements must be set for occasions on which such ResultSet types are used a lot. Since an updatable and scrollable ResultSet contains a large amount of data, its memor y usage is higher than a forward only ResultSet. A large ResultSet can cause memor y to become scarce, so its use is not recommended. The characteristics of ResultSet are determined by the ResultSet type, concurrenc y type and holdability type described above. The user can specify random combinations for these three values; however, depending on the quer y statement that generates ResultSet, the user-defined combi- nation can be invalid. In this case, the driver does not raise an exception, but conver ts it to a valid combination. In the following example, the invalid types on the left side are automatically conver ted to the valid types on the right side. TYPE_SCROLL_SENSITIVE -> TYPE_SCROLL_INSENSITIVE CONCUR_UPDATABLE -> CONCUR_READ_ONLY HOLD_CURSORS_OVER_COMMIT -> CLOSE_CURSORS_AT_COMMIT When a conversion is made internally, whether or not a conversion has occurred can be confirmed through warnings. 3.8.6 Detec ting Holes A ResultSet object of the TYPE_SCROLL_SENSITIVE type retrieves the newest data from the ser ver when per forming a FETCH. Therefore, a row which was visible when the cursor opened can become invisible as the row is scrolled. For example, if a row in a ResultSet object is deleted by another Statement, the row is no longer visible in the ResultSet object. Such an invisible row is called a “hole”. The following is a code example which detects holes in JDBC. while (sRS.next()) { if (sRS.rowDeleted()) 3.8 How to Use ResultSet 45 Advanced Functions { // HOLE DETECTED!!! } else { // do something ... } } Valid data cannot be obtained from a hole, and a ResultSet returns one of the following values for a hole: a SQL data type NULL, a reference type NULL, or the value 0. 3.8.7 Fetch Size When retrieving data for the ResultSet object from the ser ver, the ALTIBASE HDB JDBC driver retrieves multiple rows at once, instead of retrieving one row each time, and caches them in the cli- ent to enhance per formance. This is called a prefetch, and the number of rows to be fetched can be set with the setFetchSize() method of the Statement object. public void setFetchSize(int aRows) throws SQLException; A value between the range of 0 to 32767 can be set for the ALTIBASE HDB JDBC driver. The JDBC specification defines that an exception must be raised when a value outside of this range is speci- fied; however, the ALTIBASE HDB JDBC driver does not raise an exception and ignores it, for the sake of convenience. If the value is set to 0, the ALTIBASE HDB ser ver voluntarily determines the size to return to the client in one go. In this case, the number of rows to be returned differ, according to the size of a row. The FetchSize value is especially impor tant for thescroll-sensitive ResultSet. When the user retrieves data from a scroll-sensitive ResultSet, the driver returns the prefetched rows first. Even if data of the database has been updated, as long as the row exists in the prefetched cache, data of the cache is returned to the user. If the user wants to see the newest data of the database, FetchSize should be set to 1. By doing so, however, the frequency of retrieving data from the ser ver increases and per formance can be lowered. 3.8.8 Refreshing Rows With the refreshRow() method of the ResultSetobject, data which has been previously retrieved from the ser ver can be re -fetched, without executing the SELECT statement. The refre- shRow() method retr ieves as ma ny number of rows as t he value set for FetchSize, based on the current row. To use this method, a cursor must be pointing to any row in ResultSet. This method operates when the ResultSet object is of the following type: TYPE_SCROLL_SENSITIVE DATABLE TYPE_SCROLL_SENSITIVE AD_ONLY If this method is called for a TYPE_FORWARD_ONLY type, an exception is raised; for a TYPE_SCROLL_INSENSITIVE type, nothing happens. 3.9 DATE, TIME, TIMESTAMP JDBC Users’ Manual 46 3.9 DATE, TIME, TIMESTAMP This section explains the meanings of DATE, TIME, and TIMESTAMP which are DATE types, and describes the data conversion range suppor ted by the ALTIBASE HDB JDBC driver. 3.9.1 Meanings DATE: Expresses only the date TIME: Expresses the time (the date can be included) TIMESTAMP: Expresses the date, time, seconds, and fur ther subdivisions of time 3.9.2 Conversion Table The following table shows the formats that are processed by the ALTIBASE HDB JDBC driver accord- ing to the object type passed to the setObject() method. String DATE TIME TIMESTAMP setOb- ject(DA TE) 2134-12-23 00:00:00.0 An error is raised if the user inputs val- ues to the hour:min- ute:second. The driver sets it to 0. 2134-12-23 00:00:00.0 The values input to the hour:min- ute:second are ignored by the driver. SQLExcep- tion:UNSUPPO RTED_TYPE_CO NVERSION 2134-12-23 12:34:56.1234 56 setOb- jecT(TI ME) 1970-01-01 12:34:56.0 An error is raised if the user inputs val- ues to the year:month:date or a value to the nanosec- ond. The driver sets it to the standard year:month:date. 2134-12-23 12:34:56.0 2134-12-23 12:34:56.0 2134-12-23 12:34:56.0 setOb- ject(TI MES- TAMP) 2134-12-23 12:34:56.123456 2134-12-23 00:00:00.0 The values input to the hour:min- ute:second are ignored by the driver. SQLExcep- tion:UNSUPPO RTED_TYPE_CO NVERSION 2134-12-23 12:34:56.1234 56 3.9 DATE, TIME, TIMESTAMP 47 Advanced Functions The following table shows the values returned from the DATE type value (1234-01-23 12:23:34.567123) stored in the database with the getDate(), getTime(), and getTime- stamp() methods. set- String( ) Must be input in the fo r mat set fo r t he DATE_FORMAT proper ty. --- se t- Da te() - 2134-12-23 00:00:00.0 The values input to the hour:min- ute:second are ignored by the driver. -- se t- Ti me() - - 2134-12-23 12:34:56.0 - set- Time- stamp() - - - 2134-12-23 12:34:56.1234 56 Function Return Value getDate()1234-01-23 00:00:00.0 getTime()1234-01-23 12:23:34.0 getTimestamp()1234-01-23 12:23:34.567123 String DATE TIME TIMESTAMP 3.10 GEOMETRY JDBC Users’ Manual 48 3.10 GEOMETRY This section offers instructions on how to use GEOMETRY type data provided by ALTIBASE HDB in JDBC applications. 3.10.1 How To Use GEOMETRY GEOMETRY type data can be used with the byte array in ALTIBASE JDBC applications. When inser ting data (including NULL) to a GEOMETRY type column in the database with the IN parameter of PreparedStatement, the data type must be specified with the Altiba- seTypes.GEOMETRY constant. For fur ther information abouthow to directly write GEOMETRY type data in a quer y statement, please refer to the Spatial SQL Reference. 3.10.2 Example The following is a code example which inser ts data to a GEOMETRY type column in a JDBC applica- tion. int sSize = ... ; byte[] sGeometryData = new byte[sSize]; Connection sConn = ... ; PreparedStatement sPstmt = sConn.prepareStatement("INSERT INTO TEST_TABLE VALUES (?)"); sPstmt.setObject(1, sGeometryData, AltibaseTypes.GEOMETRY); sPstmt.executeQuery(); ... 3.11 LOB 49 Advanced Functions 3.11 LOB This sections offers instructions about how to use LOB type data provided by ALTIBASE HDB in a JDBC application. 3.11.1 Prerequisites ALTIBASE HDB suppor ts the LOB data types, BLOB and CLOB, and each can have the maximum size of 2Gbytes. To manipulate LOB data, the autocommit mode of a session must satisfy one of the following condi- tions. The autocommit mode of a session must be disabled with setAutocommit(false) of the Connection object and the user must manually control transactions. Clientside_auto_commit must be set to on to enable the JDBC driver to control the autocommit operations of transactions. 3.11.2 Using BLOB How to manipulate BLOB data in a JDBC application is shown in the following code examples. 3.11.2.1 Writing BLOB Data Through the PreparedStatement Object The following statement creates the table used in the examples. CREATE TABLE TEST_TABLE ( C1 BLOB ); Using the setBinaryStream() method with an InputStream object InputStream sInputStream = ... long sLength = ... ... PreparedStatement sPstmt = connection().prepareStatement("INSERT INTO TEST_TABLE VALUES (?)"); ... sPstmt.setBinaryStream(1, sInputStream, sLength); ... sPstmt.execute(); ... Using the setBinaryStream() method with an OutputStream object byte[] sBuf = ... ... 3.11 LOB JDBC Users’ Manual 50 PreparedStatement sPstmt = connection().prepareStatement("SELECT * FROM TEST_TABLE FOR UPDATE"); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { Blob sBlob = sPstmt.getBlob(1); OutputStream sOutputStream = sBlob.setBinaryStream(1); sOutputStream.write(sBuf); sOutputStream.close(); ... } ... sPstmt.execute(); ... Using the setBlob() method with a Blob object java.sql.Blob sBlob = ... ... PreparedStatement sPstmt = connection().prepareStatement("INSERT INTO TEST_TABLE VALUES (?)"); ... sPstmt.setBlob(1, sBlob); ... sPstmt.execute(); ... Using the setObject() method with a Blob object java.sql.Blob sBlob = ... ... PreparedStatement sPstmt = connection().prepareStatement("INSERT INTO TEST_TABLE VALUES (?)"); ... sPstmt.setObject(1, sBlob); ... sPstmt.execute(); ... Specifying a SQL type for the setObject() method java.sql.Blob sBlob = ... ... 3.11 LOB 51 Advanced Functions PreparedStatement sPstmt = connection().prepareStatement("INSERT INTO TEST_TABLE VALUES (?)"); ... sPstmt.setObject(1, sBlob); ... sPstmt.execute(); ... 3.11.2.2 Writing BLOB Data Through the ResultSet object The following statement creates the table used in the examples. CREATE TABLE BLOB_TABLE ( BLOB_COLUMN BLOB ); Using the updateBinaryStream() method with an InputStream object InputStream sInputStream = ... long sLength = ... ... PreparedStatement sPstmt = connection().prepareStatement("SELECT BLOB_COLUMN FROM BLOB_TABLE", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... sRs.updateBinaryStream(1, sInputStream, sLength); sRs.updateRow(); ... } ... Using the updateBlob() method with a Blob object java.sql.Blob sBlob = ... ... PreparedStatement sPstmt = connection().prepareStatement("SELECT BLOB_COLUMN FROM BLOB_TABLE", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... sRs.updateBlob(1, sBlob), ; sRs.updateRow(); ... } ... 3.11 LOB JDBC Users’ Manual 52 Using the updateObject() method with a Blob object java.sql.Blob sBlob = ... ... PreparedStatement sPstmt = connection().prepareStatement("SELECT BLOB_COLUMN FROM BLOB_TABLE", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... sRs.updateObject(1, sBlob); sRs.updateRow(); ... } ... Specifying the SQL type for the updateObject() method java.sql.Blob sBlob = ... ... PreparedStatement sPstmt = connection().prepareStatement("SELECT BLOB_COLUMN FROM BLOB_TABLE", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... sRs.updateObject(1, sBlob, AltibaseTypes.BLOB); sRs.updateRow(); ... } ... 3.11.2.3 Updating BLOB Data with the SELECT ... FOR UPDATE Statement byte[] sBytes = new byte[sLength]; ... PreparedStatement sPstmt = connection().prepareStatement("SELECT BLOB_COLUMN FROM BLOB_TABLE FOR UPDATE"); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... Blob sBlob = sRs.getBlob(1); sBlob.setBytes(0, sBytes); ... } ... 3.11 LOB 53 Advanced Functions 3.11.2.4 Reading BLOB Data Using the getBinaryStream() method with an InputStream object ... PreparedStatement sPstmt = connection().prepareStatement("SELECT BLOB_COLUMN FROM BLOB_TABLE"); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... InputStream sInputStream = sRs.getBinaryStream(1); ... } ... Using the getBlob() method with an InputStream object ... PreparedStatement sPstmt = connection().prepareStatement("SELECT BLOB_COLUMN FROM BLOB_TABLE"); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... Blob sBlob = sRs.getBlob(1); InputStream sInputStream = sBlob.getBinaryStream(); ... } ... Using the getBlob() method with a byte array ... final int sReadLength = 100; PreparedStatement sPstmt = connection().prepareStatement("SELECT BLOB_COLUMN FROM BLOB_TABLE"); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... Blob sBlob = sRs.getBlob(1); long sRemains = sBlob.length(); long sOffset = 0; while(sRemains > 0) { byte[] sReadBytes = sBlob.getBytes(sOffset, sReadLength); sRemains -= sReadBytes.length; sOffset += sReadBytes.length; ... } 3.11 LOB JDBC Users’ Manual 54 ... } ... 3.11.2.5 Altering BLOB Data Truncation Statement sStmt = ... ResultSet sRs = sStmt.executeQuery("SELECT * FROM t1 FOR UPDATE"); while(sRs.next()) { ... int sLength = ... ; Blob sBlob = sRs.getBlob(2); // After executing this method // sBlob.length() == sLength sBlob.truncate(sLength); } ... 3.11.3 Using CLOB Data How to use CLOB data in a JDBC application is shown in the following code examples. 3.11.3.1 Writing CLOB data Through PreparedStatement The following statement creates the table to be used in the examples. CREATE TABLE TEST_TABLE ( C1 CLOB ); Using the setCharacterStream() method with a Reader object Reader sReader = ... long sLength = ... ... PreparedStatement sPstmt = connection().prepareStatement("INSERT INTO TEST_TABLE VALUES (?)"); ... sPstmt.setCharacterStream(1, sReader, sLength); ... 3.11 LOB 55 Advanced Functions sPstmt.execute(); ... Using the setCharacterStream() method with a Writer object char[] sBuf = ... ... PreparedStatement sPstmt = connection().prepareStatement("SELECT * FROM TEST_TABLE FOR UPDATE"); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { Clob sClob = sPstmt.getClob(1); Writer sWriter = sClob.setCharacterStream(1); sWriter.write(sBuf); sWriter.close(); ... } ... sPstmt.execute(); ... Using the setClob() method with a Clob object java.sql.Clob sClob = ... ... PreparedStatement sPstmt = connection().prepareStatement("INSERT INTO TEST_TABLE VALUES (?)"); ... sPstmt.setClob(1, sClob); ... sPstmt.execute(); ... Using the setObject() method with a Clob object java.sql.Clob sClob = ... ... PreparedStatement sPstmt = connection().prepareStatement("INSERT INTO TEST_TABLE VALUES (?)"); 3.11 LOB JDBC Users’ Manual 56 ... sPstmt.setObject(1, sClob); ... sPstmt.execute(); ... Specifying a SQL type for the setObject() method java.sql.Clob sClob = ... ... PreparedStatement sPstmt = connection().prepareStatement("INSERT INTO TEST_TABLE VALUES (?)"); ... sPstmt.setObject(1, sClob, AltibaseTypes.Clob); ... sPstmt.execute(); ... 3.11.3.2 Writing CLOB data Through the ResultSet Objec t The following statement creates the table to be used in the examples. CREATE TABLE CLOB_TABLE ( CLOB_COLUMN CLOB ); Using the updateCharacterStream() method with a Reader object Reader sReader = ... long sLength = ... // The length of source from which Reader is linked ... PreparedStatement sPstmt = connection().prepareStatement("SELECT CLOB_COLUMN FROM CLOB_TABLE", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... sRs.updateCharacterStream(1, sReader, sLength); sRs.updateRow(); ... 3.11 LOB 57 Advanced Functions } ... Using the updateClob() method with a Clob object java.sql.Clob sClob = ... ... PreparedStatement sPstmt = connection().prepareStatement("SELECT CLOB_COLUMN FROM CLOB_TABLE", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... sRs.updateClob(1, sClob); sRs.updateRow(); ... } ... Using the updateObject() method with a Clob object java.sql.Clob sClob = ... ... PreparedStatement sPstmt = connection().prepareStatement("SELECT CLOB_COLUMN FROM CLOB_TABLE", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... sRs.updateObject(1, sClob); sRs.updateRow(); ... } ... Specifying a SQL type for the updateObject() method java.sql.Clob sClob = ... ... PreparedStatement sPstmt = connection().prepareStatement("SELECT CLOB_COLUMN FROM CLOB_TABLE", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... sRs.updateObject(1, sClob, AltibaseTypes.CLOB); sRs.updateRow(); 3.11 LOB JDBC Users’ Manual 58 ... } ... 3.11.3.3 Inser ting CLOB data with the SELECT ... FOR UPDATE Statement ... String sStr = ... ; PreparedStatement sPstmt = connection().prepareStatement("SELECT CLOB_COLUMN FROM CLOB_TABLE FOR UPDATE"); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... Clob sClob = sRs.getClob(1); sClob.setString(0, sStr); ... } ... 3.11.3.4 Reading CLOB Data Using the getCharacterStream() method with a Reader object ... PreparedStatement sPstmt = connection().prepareStatement("SELECT CLOB_COLUMN FROM CLOB_TABLE"); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... Reader sReader = sRs.getCharacterStream(1); ... } ... Using the getClob() method with a Reader object ... PreparedStatement sPstmt = connection().prepareStatement("SELECT CLOB_COLUMN FROM CLOB_TABLE"); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... Clob sClob = sRs.getClob(1); Reader sReader = sClob.getCharacterStream(); ... 3.11 LOB 59 Advanced Functions } ... Using the getClob() method with a String object ... final int sReadLength = 100; PreparedStatement sPstmt = connection().prepareStatement("SELECT CLOB_COLUMN FROM CLOB_TABLE"); ResultSet sRs = sPstmt.executeQuery(); while(sRs.next()) { ... Clob sClob = sRs.getClob(1); long sRemains = sClob.length(); long sOffset = 0; while(sRemains > 0) { String sStr = sClob.getSubString(sOffset, sReadLength); sRemains -= sStr.length; sOffset += sStr.length; ... } ... } ... 3.11.3.5 Altering CLOB Data Truncation Statement sStmt = ... ResultSet sRs = sStmt.executeQuery("SELECT * FROM t1 FOR UPDATE"); while(sRs.next()) { ... int sLength = ... ; Clob sClob = sRs.getClob(2); // After executing this method // sClob.length() == sLength sClob.truncate(sLength); } ... 3.11.4 Freeing Resources For JDBC applications which obtain data through a large number of LOB objects, the obtained LOB objects must be freed. The LOB object must be freed specifically, regardless of whether or not the transaction is committed. 3.11 LOB JDBC Users’ Manual 60 The following is a code example which frees a Blob object. ... Blob sBlob = sRs.getBlob(1); // Freeing Lob Locator ((Altibase.jdbc.driver.AltibaseLob)sBlob).free(); ... Further operations cannot be executed on an object if a Blob object is freed with the free() method, since the corresponding LOB locator is freed from the ser ver. The following is a code example which frees a Clob object. ... Clob sClob = sRs.getClob(1); // Freeing Lob Locator ((Altibase.jdbc.driver.AltibaseLob)sClob).free(); ... As for Blob objects, fur ther operations cannot be executed on an object if a Clob object is freed with the free() method, since the corresponding LOB locator is freed from the ser ver. The following is a code example which frees the BlobInputStream and BlobOutputStream objects. InputStream sInputStream = sRs.getBinaryStream(1); // Freeing Lob Locator ((Altibase.jdbc.driver.BlobInputStream)sInputStream).freeLocator(); CallableStatement sCallStmt = aConn.prepareCall("INSERT INTO TEST_TABLE VAL- UES (?)"); sCallStmt.registerOutParameter(1, Types.BLOB); sCallStmt.execute(); Blob sBlob = sCallStmt.getBlob(1); OutputStream sOutputStream = sBlob.setBinaryStream(1); // Freeing Lob Locator ((Altibase.jdbc.driver.BlobOutputStream)sOutputStream).freeLocator(); Further operations cannot be executed on an object if the BlobInputStream object or the Blo- bOutputStream object is freed with the freeLocator( ) method, since the corresponding LOB Locator is freed from the ser ver. The following is a code example which frees the ClobReader and ClobWriter objects. Reader sClobReader = sRs.getCharacterStream(1); // Freeing Lob Locator ((Altibase.jdbc.driver.ClobReader)sClobReader).freeLocator(); CallableStatement sCallStmt = aConn.prepareCall("INSERT INTO TEST_TABLE VAL- UES (?)"); 3.11 LOB 61 Advanced Functions sCallStmt.registerOutParameter(1, Types.CLOB); sCallStmt.execute(); Clob sClob = sCallStmt.getClob(1); Writer sClobWriter = sClob.setCharacterStream(1); // Freeing Lob Locator ((Altibase.jdbc.driver.ClobWriter)sClobWriter).freeLocator(); Further operations cannot be executed on an object if the ClobReader object or the Clob- Writer object is freed with the freeLocator() method, since the corresponding LOB Loca- tor is freed from the server. 3.11.5 Restric tions Even if clientside_auto_commit is set to on to enable the JDBC driver to control the auto- commit operations of transactions the following restrictions still apply to the manipulation of LOB data. If LOB data retrieved from the ResultSet object (cursor) is used with the executeUpdate() method of another Statement before the cursor is closed, no more fetch operations are possible from the cursor since the LOB locator is freed. The following is a code example which raises such an error. PreparedStatement sPreStmt = sCon.prepareStatement( "INSERT INTO TEST_TEXT " + "VALUES ( ?, ?, ?, ? )" ); Statement sStmt = sCon.createStatement(); ResultSet sRS = sStmt.executeQuery( "SELECT ID, TEXT " + " FROM TEST_SAMPLE_TEXT " ); while ( sRS.next() ) -> 2 { sID = sRS.getInt( 1 ); sClob = sRS.getClob( 2 ); switch ( sID ) { case 1 : sPreStmt.setInt( 1, 1 ); sPreStmt.setString( 2, "Altibase Greetings" ); sPreStmt.setClob( 3, sClob ); sPreStmt.setInt( 4, (int)sClob.length() ); break; case 2 : sPreStmt.setInt( 1, 2 ); sPreStmt.setString( 2, "Main Memory DBMS" ); sPreStmt.setClob( 3, sClob ); sPreStmt.setInt( 4, (int)sClob.length() ); break; default : break; } sPreStmt.executeUpdate(); -> 1 } 1: If sPreStmt.executeUpdate() is called while ResultSet sRS is open, the JDBC driver automatically commits transactions and by doing so, LOB locator of sClob is freed. 2: An exception can be raised at sRs.next() since LOB locator is freed. Th u s , w h e n m a n i p u l a t i n g LO B d a t a i n s u c h a l o g i c a s a b o ve, t h e a u t o co m m i t m o d e o f a s e s s i o n m u s t 3.11 LOB JDBC Users’ Manual 62 first be disabled by calling setAutocommit(false). 3.12 Controlling Autocommit 63 Advanced Functions 3.12 Controlling Autocommit The autocommit mode of a session can be set with the auto_commit connection attribute or the setAutocommit() method of the JDBC Connection object for Altibase JDBC applications. If autocommit is enabled with auto_commit=true or the setAutocommit(true) method, the ALTIBASE HDB ser ver automatically commits transactions. Autocommit can also be enabled with the clientside_auto_commit connection attribute. If clientside_auto_commit is set to on, instead of the ALTIBASE HDB server, the JDBC driver automatically commits transactions. When clientside_auto_commit is set to off, the autocommit mode of a session is deter- mined by the setAutocommit() method. To disable autocommit for a session, call setAutocommit(false). Calling setAutocommit(false) on a client_auto_commit=on session disables autocom- mit and calling setAutocommit(true) thereafter restores the session to the autocommit mode of the JDBC driver. When autocommit is disabled, the user must manually commit or rollback with the commit() or rollback() method. The following table sums up the above. Autocommit Mode How to Set Ser ver automatically commits transactionsauto_commit=true (or omitted) or set- Autocommit(true) JDBC driver automatically commits transactionsauto_commit=true (or omitted) and clientside_auto_commit=on Autocommit is disabledauto_commit=false or setAutocom- mit(false) 3.12 Controlling Autocommit JDBC Users’ Manual 64 65 Tips ations 4 Ti ps ations This chapter provides instructions for the efficient use of the ALTIBASE HDB JDBC driver. 4.1 Tips for Better Performance JDBC Users’ Manual 66 4.1 Tips for Better Per formance The following tips should be kept in mind to enhance the per formance of JDBC applications. It is recommended to use the Stream or Writer object when using LOB data in JDBC appli- cations. If the size of the LOB data to be used is equal to or smaller than 8192 bytes, the Lob_Cache_Threshhold connection attribute must be set to an appropriate value. It is recommended to execute one operation on one Connection object. For example, if a multiple number of Statement objects are created in one Connection object and their operations are executed, this can induce per formance loss. It is recommended to use the connection pool provided by Middleware ( WAS) when the Con- nection object is frequently created and deleted. This is because the cost of connecting and terminating Connection is relatively higher than other operations. 67 Error Messages 5 Error Messages This chapter lists the SQLSTATE errors which can occur while using the ALTIBASE HDB JDBC driver. 5.1 SQLSTATE JDBC Users’ Manual 68 5.1 SQLSTATE The string value returned to SQLSTATE is composed of the first 2 characters which indicate the class and the following 3 characters which indicate the subclass. The class indicates the state and the subclass indicates the detailed state. The following table lists the types of SQLSTATE which can occur in the ALTIBASE HDB JDBC driver and its meanings briefly. Condition Class Subcondition Subclass Connection Exception 08 Communication link failure S01 Invalid packet header version P01 Fail-over completed F01 Invalid format for alternate servers F02 Invalid packet next header type P02 Invalid packet sequence number P03 Invalid packet serial number P04 Invalid packet module ID P05 Invalid packet module version P06 Invalid operation protocol P07 Invalid property ID:%s P08 Invalid connection URL U01 Unknown host H01 There are no available data source configurations D01 Handshake fails C01 Connection failure 006 SQL-client unable to establish SQL-connection 001 There are no available data source configurations D01 5.1 SQLSTATE 69 Error Messages Dynamic SQL Error 07 This statement returns result set(s) R01 Invalid query string Q01 Statement has not been executed yet S01 No data 02 The SQL statement does not pro- duce a result set 001 Condition Class Subcondition Subclass 5.1 SQLSTATE JDBC Users’ Manual 70 Warning 01 Cursor operation conflict 001 Invalid connection string attri- bute S00 Batch update exception occurred:%s B00 There are no batch jobs B01 Batch jobs already exist B02 The query cannot be executed while batch jobs are executing B03 Binding cannot be permitted dur- ing batch job execution B04 Fetch operation cannot be exe- cuted during batch update B05 There are too many added batch jobs B31 The statement has already been closed C01 The result set has already been closed C02 The stream has already been closed C03 Additional result sets returned 00D This result set doesn’t retain data R01 Attempted to return too many rows in only one fetch operation R02 Option value changed S02 Invalid value for bitset V01 Condition Class Subcondition Subclass 5.1 SQLSTATE 71 Error Messages Feature Not Supported 0A Cannot change the name of the database C01 The read only mode in transaction cannot be supported C02 Unsupported operation in forward only mode T01 Unsupported operation in read only mode Violates the JDBC specification T02 Violates the JDBC specification V01 Syntax Error or Access Rule Violation 42 Invalid type conversion 001 Column not found S22 JDBC Internal Error JI 000 Overflow occurred on dynamic array defined by JDBC D01 Underflow occurred on dynamic array defined by JDBC D02 This result set was created by the JDBC driver’s internal state- ment D03 Connection thread has been inter- rupted D04 Remaining data exceeds the maxi- mum size of the primitive type D05 Packet Operation has been twisted P01 Invalid method invocation I01 Cardinality Violation 21 Insert value list does not match column list S01 Condition Class Subcondition Subclass 5.1 SQLSTATE JDBC Users’ Manual 72 Data Exception 22 000 Null value not allowed 004 Invalid parameter value 023 Insufficient number of parameters P01 IN type parameter needed P02 OUT type parameter needed P03 There is no column which needs to bind parameters P04 Statement ID mismatch V01 Error occurred from InputStream S01 The length of the actual LOB data and the LOB data written into the communication buffer is different L01 Invalid Trans- action State 25 The branch transaction is already active 002 Savepoint Exception 3B Cannot set savepoint in autocom- mit mode S01 Invalid savepoint name V01 Invalid savepoint V02 Umsupported operation on named savepoint N01 Unsupported operatio on unnamed savepoint N02 Invalid Schema Name 3F 000 Explain Plan Error EP EXPLAIN PLAN is set to OFF S01 Condition Class Subcondition Subclass 5.1 SQLSTATE 73 Error Messages General Error HY There are too many allocated statements 000 Associated statement is not pre- pared 007 Attribute cannot be set now 011 Invalid string or buffer length 090 Invalid cursor position 109 Empty ResultSet R01 Timeout expired T00 XA Error XA XA open failed F01 XA close failed F02 XA recover failed F03 Condition Class Subcondition Subclass 5.1 SQLSTATE JDBC Users’ Manual 74 Data Type Mapping 75 Data Type Mapping Appendix A. Data Type Mapping This appendix lists the compatibility between ALTIBASE HDB data types and standard JDBC data types/Java data types. Data Type Mapping The following table shows the basic mapping relationship between JDBC data types, ALTIBASE JDBC data types, and Java language types. J D B C Ty p e A LT I B A S E H D B Ty p e J a v a Ty p e CHAR CHAR String VARCHAR VARCHAR String LONGVARCHAR VARCHAR String NUMERIC NUMERIC BigDecimal DECIMAL NUMERIC BigDecimal BIT VARBIT BitSet BOOLEAN - - TINYINT SMALLINT Shor t SMALLINT SMALLINT Shor t INTEGER INTEGER Integer BIGINT BIGINT Long REAL REAL Float FLOAT FLOAT BigDecimal DOUBLE DOUBLE Double BINARY BY TE byte[] VA R B I N A R Y B L O B B l o b LO N G VA R B I N A R Y B LO B B l o b DATE DATE Timesta mp TIME DATE Timestamp Converting Java Data Types to Database Data Types JDBC User’s Manual 76 Conver ting Java Data Types to Database Data Types The following table shows the database data types available for conversion for each object when setting an object for a parameter with the setObject() method. TIMESTAMP DATE Timestamp CLOB CLOB Clob BLOB BLOB Blob ARRAY - - DISTINC T - - STRUC T - - REF - - DATALINK - - JAVA_OBJEC T - - NULL - null -GEOMETRYbyte[] JDB C T y pe AL TIBASE HDB T y pe Ja va T y pe SMALLINT INTEGER BIGINT REAL FLOAT DOUBLE DECIMAL/NUMERIC BIT CHAR VARCHAR/LONGVARCHAR BINARY VARBINARY/LONGVARBINARY DATE TIME TIMESTAMP BLOB CLOB Array Blobo Boolean oooooooooo byte[] oooo o char[] ooooooooooooooo o Cl obo Double oooooooooo Converting Database Data Types to Java Data Types 77 Data Type Mapping Conver ting Database Data Types to Java Data Types The following table shows whether or not conversion is possible for each database data type with the getXXX() method. Float oooooooooo Integer oooooooooo Java c l a s s BigDecimal oooooooooo java.n et. U R L java.sql.Date o o o o o java.sql.Time o o o o o java.sql.Timestamp o o o o o java.util.BitSet o Long oooooooooo Ref Short ooooooooo String ooooooooooooooo St ru c t InputStream o Readero SMALLINT INTEGER BIGINT REAL FLOAT DOUBLE DECIMAL/NUMERIC BIT CHAR VARCHAR/LONGVARCHAR BINARY VA R B I N A R Y / LO N G VA R B I N A R Y DATE TIME TIMESTAMP BLOB CLOB Converting Database Data Types to Java Data Types JDBC User’s Manual 78 SMALLINT INTEGER BIGINT REAL FLOAT DOUBLE DECIMAL/NUMERIC BIT CHAR/VARCHAR LO N G VA R C H A R BINARY VA R B I N A R Y / L O N G VA R B I N A R Y DATE TIME TIMESTAMP BLOB CLOB getArray getAsciiStream ooooooooooo ooo getBigDecimal ooooooo oo getBinaryStream o oooooo o ooo getBlob o o getBoolean ooooooooooo getByte ooooooooooo getBytes oooooooo o ooo getCharacterStreamooooooooooo ooo getClob o getDat e o o o o o getDouble ooooooooooo getFloat ooooooooooo getInt ooooooooooo getLong ooooooooooo getObject ooooooooooooooooo getRef getShort ooooooooooo getString ooooooooooo ooo getT ime o o o o o getTimestamp o o o o o 79 Index Index A altibase_cli.ini 30 Autocommit 63 auto_commit 63 Auto-generated Keys 26 B BLOB 49 C CallableStatement 23 clientside_auto_commit 63 CLOB 54 CLOSE_CURSORS_AT_COMMIT 42 Compatibility 2 Compile 4 CONCUR_READ_ONLY 42 Concurrency 42 CONCUR_UPDATABLE 42 Connecting 3 Connection Attributes 5 alternateservers 6 app_info 6 auto_commit 6 clientside_auto_commit 6 connectionretrycount 7 connectionretrydelay 7 database 7 datasource 8 date_format 8 ddl_timeout 8 description 8 failover_source 9 fetch_enough 9 fetch_timeout 9 healthcheckduration 10 idle_timeout 10 isolation_level 10 loadbalance 11 lob_cache_threshold 11 login_timeout 11 max_statements_per_session 12 ncharliteralreplace 12 password 12 port 12 prefer_ipv6 13 privilege 13 query_timeout 13 remove_redundant_transmission 13 response_timeout 14 server 14 sessionfailover 14 time_zone 14 user 15 utrans_timeout 15 Connection Information 3, 5 Connection Pool 31, 66 Connection URL 3, 5, 30 D Data Type Mapping 75 DataSource 30 Date 46 E Escapes 40 F Failover 18, 35 CTF 35 STF 35 Fetch Size 45 FetchSize 42 Freeing Resources 59 G GEOMETRY 48 H Holdability 42 HOLD_CURSORS_OVER_COMMIT 42 Holes 44 I Installation 2 IPv6 20 J java.net.preferIPv4Stack 20 java.net.preferIPv6Addresses 20 Jeus 3.x 32 L LOB 49 Lob_Cache_Threshhold 66 Login Timeout 28 Index 80 M Multiple ResultSet 34 N National Character Set 24 P PREFER_IPV6 20 PreparedStatement 22 Properties Object 5 R Refreshing Rows 45 Response Timeout 28 ResultSet 16, 41 S SQL States 68 SQLSTATE 68 Statement 16, 22 T Time 46 Timeout 28 Timestamp 46 Tomcat 8.x 31 TYPE_FORWARD_ONLY 41 TYPE_SCROLL_INSENSITIVE 41 TYPE_SCROLL_SENSITIVE 41 V Version 2 W WAS 31 Web Application Server 31 WebLogic 6.x 32

ALTIBASE HDB 6.3.1 Release Notes (2013/11/05) ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB Table of Contents Table of Contents ................................................................................................. 2 1. System Requirements ................................................................................. 3 2. Release Information ..................................................................................... 4 2.1 What’s New in ALTIBASE HDB 6.3.1 ............................................. 4 2.2 Changes ......................................................................................... 7 Versions of Database Components .............................................. 7 Compatibility ................................................................................. 7 Properties ...................................................................................... 8 Performance Views ..................................................................... 10 Error Messages (HDB 6.1.1 to HDB 6.3.1) .................................. 11 2.3 Packages ................................................................................... 14 2.4 Downloads ................................................................................... 15 Location ...................................................................................... 15 Installation ................................................................................... 15 ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB 1. System Requirements Minimum Hardware Requirements 1GB RAM (Recommended: 2GB) 1 CPU (Recommended: 2 CPUs) 4GB hard disk space (Recommended: 12GB) Supported Operating Systems and Platforms ALTIBASE HDB 6.3.1 can be run on the operating systems and platforms listed in the table below. OS CPU Version Bit (Server) Bit (Client) AIX PowerPC 5.3 tl1 and higher 64-bit 64-bit, 32-bit HP-UX PA-RISC 11.11 and higher 64-bit 64-bit, 32-bit IA64 11.23 and higher SUN SPARC 2.8 and higher 64-bit 64-bit, 32-bit i86PC 2.10 and higher Windows x86, x86-64 Windows 2003 and higher 64-bit, 32-bit 64-bit, 32-bit LINUX x86, x86-64 (GNU glibc 2.3.4 and higher) ES40, ES50, ES60 64-bit, 32-bit 64-bit, 32-bit Java version: ALTIBASE HDB 6.3.1 is compatible with JDK 1.4 and higher. ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB 2. Release Information 2.1 What’s New in ALTIBASE HDB 6.3.1 2.1.1 Improved Functionality - SQL Extensions and OLAP Functions RETURNING Clause in DML Statements (SQL Extension) - The RETURNING clause can be used in INSERT, UPDATE and DELETE statements to both update and search data in one call. Also, the BULK COLLECT clause can be used in PSM to simultaneously return multiple rows as collection variables. Foreign Keys with Set NULL Value on Delete (SQL Extension) - When a row in the parent table is deleted, the corresponding foreign key column values in the child table are set to NULL for the purpose of referential integrity. UPDATE and DELETE on JOIN Results (SQL Extension) - As for regular tables, INSERT, UPDATE and DELETE statements can change the data of views and joined views. Further Support for Hierarchical Queries (SQL Extension) Aliases for Subqueries (SQL Extension) Merge DML (SQL Extension) - The MERGE statement can either update or insert data into the target table, depending on the given condition. Multiple Table Insert (SQL Extension) - The MULTIPLE TABLE INSERT clause can insert result sets generated from subqueries into multiple tables. Instead of Trigger (SQL Extension) - The INSTEAD OF TRIGGER fires only the trigger, and not the triggering DML statement. Analytic Functions (Window Functions) (OLAP) Aggregate Window Functions AVG, COUNT, MAX, MIN, STDDEV, SUM, VARIANCE, GROUP_CONCAT Ranking Window Functions RANK, DENSE_RANK, ROW_NUMBER, LAG, LEAD Row Ranking-Related Window Functions FIRST_VALUE, LAST_VALUE, NTH_VALUE, FIRST_VALUE_IGNORE_NULLS, LAST_VALUE_IGNORE_NULLS, NTH_VALUE_IGNORE_NULLS Support for Grouping Set(ROLLUP, CUBE) (OLAP) - The use of ROLLUP and CUBE extensions in the GROUP BY clause is supported for calculations of group sums of aggregate results. ROLLUP Returns detailed information of grouped result sets. ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB CUBE Executes groupings of all possible combinations on specified grouping columns. CUBE creates groupings on 2n combinations, where n is the number of grouping columns. String Conversion Functions - The HEX_ENCODE and HEX_DECODE functions have been added for string conversion. HEX_ENCODE Converts a string of ASCII characters into a hexadecimal string HEX_DECODE Converts a hexadecimal string into a string of ASCII characters 2.1.2 Improved Functionality - Application Programming Interfaces Compatibility with JDBC 3.0 - The ALTIBASE JDBC driver conforms to the JDBC 3.0 specification. PHP Extension - The PHP interface enables the access of web pages written in PHP to ALTIBASE HDB. Improvement of the ODBC Feature - The ALTIBASE ODBC driver interface and its efficiency have been improved with the addition of functions. SQLCancel Cancels the statement under process SQLBulkOperation Performs bulk insertions or updates, deletes, and fetches bookmarked rows SQLSetPos Specifies the cursor position in a row set. Addition of cursor types and cursor behaviors - Apart from the previously supported forward-only and static cursor types, the keyset- driven cursor type and scrollable, updatable cursor behaviors are now available for use. Improvement of the OLE DB Interface - An interface related to scrollable and updatable cursors for rowset objects has been added. - Calls to stored procedures can be made with the OLE DB interface. LOB SUPPORT - LOB parameters, internal variables and return values can be used in stored procedures and triggers. Improvement of the ADO.NET Provider Interface - The addition of the AltibaseBulkCopy class supports the copying of bulk data. Improvement of the Database Link Feature C/C++ External Procedures and Functions - This feature enables functions written in C/C++ to be called in SQL statements of ALTIBASE HDB. - Since the external C/C++ procedure execution and the HDB server process are separated, the database is not affected - even if there is an error in the external C/C++ procedure written by the user. ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB 2.1.3 Improved Functionality- Database Objects Global Non-Partitioned Indexes - The use of global non-partitioned indexes on partitioned tables is supported. CHECK Constraints - By specifying CHECK constraints, referential integrity rules can be enforced for given columns. Function-Based Indexes - Function-based indexes create indexes based on the calculated results of functions or expressions. Expressions can include internal SQL functions and user-defined functions. Stored Packages - A stored package is a grouped object of variables, subprograms, cursors and other objects associated with stored procedures. Stored packages enable the user to modularize objects associated with a given operation; thus, the writing of application programs is made easy and performance is enhanced. Temporary Tables - Temporary tables can be used to temporarily hold data for the duration of a session or transaction. Temporary tables are useful for temporarily holding result sets constructed from the execution of multiple DML statements in application programs, and can enhance the performance speed of complex queries. Materialized Views - Materialized Views improve query performance by physically storing the results of frequently-accessed views. 2.1.4 Improved Performance - Client Performance Enhancement Deferred Prepare - The DEFER_PREPARES property can be used with the SQLDriverConnect function to specify whether or not communication to the server is to be deferred when SQLPrepare is executed. LOB Cache and Interface - The LOB cache feature has been added to improve the performance of queries that return LOB data. 2.1.5 Efficiency Dedicated Thread Mode (Efficient CPU Usage) - When a multiple number of clients connect to the server and execute queries, the dedicated service thread mode creates one service thread for each client session to process the clients’ request. Subquery Unnesting (Query Optimization) - By unnesting nested subqueries, the performance of queries is improved. Improvement of Cost Estimation (Query Optimization) - The query optimizer has been improved to perform the most efficient cost estimation for the purpose of query optimization. ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB 2.1.6 Availability Incremental Backup - Apart from the full backup method, ALTIBASE HDB provides incremental backup and other forms of incremental backup. 2.1.7 HDB Server Management Auditing Statements, Objects, and Audit Logs - The database administrator can perform an audit on objects, statements and DDL commands for security management of data. Database Dump - The dumpdb utility analyzes checkpoint images stored on the disk and enables the user to check schemas created in the database, without running the server. 2.1.8 Security Reinforcement Reinforcement of Password Management Policies Triple encrypt - The Triple-DES encryption(3DES) algorithm supports the encryption and decryption of strings. 2.2 Changes The following section describes the added, updated and removed features for the benefit of database administrators and developers. Versions of Database Components Updated Versions of Database Components ALTIBASE HDB Version Database Binary Version Communicatio n Protocol Version Meta Version Replication Protocol Version 6.1.1 6.1.1 5.6.3 5.14.1 6.1.1 6.3.1 6.2.1 7.1.1 6.2.1 7.4.1 Compatibility Database Binary Version The database binary version indicates the compatibility between database image files and log files. Since the format of database image files and log files change, the existing database must be migrated when the database is upgraded. ALTIBASE HDB Version Database Binary Version 6.1.1 6.1.1 6.3.1 6.2.1 ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB Communication Protocol Version The communication protocol version indicates the compatibility of the communication protocol between the ALTIBASE HDB server and the client. All versions(Major, Minor, Patch) have been changed for ALTIBASE 6.3.1; it is incompatible with ALTIBASE HDB 6.1.1. Therefore, client application programs built for use with ALTIBASE HDB 6.1.1 must be recompiled and re-linked to the ALTIBASE 6.3.1 libraries. ALTIBASE HDB Version Communication Protocol Version 6.1.1 5.6.3 6.3.1 7.1.1 Meta Version The meta version indicates the compatibility of meta tables ALTIBASE HDB Version Meta Version 6.1.1 5.14.1 6.3.1 6.2.1 Replication Protocol Version The replication protocol version has changed for ALTIBASE HDB 6.3.1; replication between ALTIBASE HDB 6.1.1 and 6.3.1 is unsupported. ALTIBASE HDB Version Replication Protocol Version 6.1.1 6.1.1 6.3.1 7.4.1 Properties The following properties have been added. For further information on each property, please refer to the General Reference. New Properties for ALTIBASE HDB ARCHIVE_MULTIPLEX_COUNT ARCHIVE_MULTIPLEX_DIR AUDIT_LOG_DIR COLLECT_DUMP_INFO DBLINK_ALTILINKER_CONNECT_TIMEOUT DBLINK_DATA_BUFFER_ALLOC_RATIO ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB DBLINK_DATA_BUFFER_BLOCK_COUNT DBLINK_DATA_BUFFER_BLOCK_SIZE DBLINK_GLOBAL_TRANSACTION_LEVEL DBLINK_REMOTE_STATEMENT_AUTOCOMMIT DK_MSGLOG_COUNT DK_MSGLOG_FILE DK_MSGLOG_FLAG DK_MSGLOG_RESERVE_SIZE DK_MSGLOG_SIZELOB_OBJECT_BUFFER_SIZE DUMP_MSGLOG_COUNT DUMP_MSGLOG_FILE DUMP_MSGLOG_RESERVE_SIZE DUMP_MSGLOG_SIZE ERROR_MSGLOG_COUNT ERROR_MSGLOG_FILE ERROR_MSGLOG_RESERVE_SIZE ERROR_MSGLOG_SIZE EXTPROC_AGENT_CONNECT_TIMEOUT EXTPROC_AGENT_IDLE_TIMEOUT FAILED_LOGIN_ATTEMPTS GROUP_CONCAT_PRECISION HASH_AREA_SIZE LOB_CACHE_THRESHOLD LOG_MULTIPLEX_COUNT LOG_MULTIPLEX_DIR MM_MSGLOG_RESERVE_SIZE NLS_CURRENCY NLS_ISO_CURRENCY NLS_NUMERIC_CHARACTERS NLS_TERRITORY OPTIMIZER_FEATURE_ENABLE OPTIMIZER_UNNEST_AGGREGATE_SUBQUERY OPTIMIZER_UNNEST_COMPLEX_SUBQUERY OPTIMIZER_UNNEST_SUBQUERY PASSWORD_GRACE_TIME PASSWORD_LIFE_TIME PASSWORD_LOCK_TIME PASSWORD_REUSE_MAX PASSWORD_REUSE_TIME PASSWORD_VERIFY_FUNCTION PSM_IGNORE_NO_DATA_FOUND_ERROR ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB QP_MSGLOG_RESERVE_SIZE REPLICATION_BEFORE_IMAGE_LOG_ENABLE REPLICATION_EAGER_PARALLEL_FACTOR REPLICATION_EAGER_RECEIVER_MAX_ERROR_COUNT REPLICATION_FAILBACK_INCREMENTAL_SYNC REPLICATION_SENDER_COMPRESS_XLOG REPLICATION_TRANSACTION_POOL_SIZE RP_CONFLICT_MSGLOG_COUNT RP_CONFLICT_MSGLOG_DIR RP_CONFLICT_MSGLOG_ENABLE RP_CONFLICT_MSGLOG_FILE RP_CONFLICT_MSGLOG_FLAG RP_CONFLICT_MSGLOG_RESERVE_SIZE RP_CONFLICT_MSGLOG_SIZE RP_MSGLOG_RESERVE_SIZE SECONDARY_BUFFER_ENABLE SECONDARY_BUFFER_FILE_DIRECTORY SECONDARY_BUFFER_FLUSHER_CNT SECONDARY_BUFFER_SIZE SECONDARY_BUFFER_TYPE SERVER_MSGLOG_RESERVE_SIZE SM_MSGLOG_RESERVE_SIZE TABLE_LOCK_ENABLE TEMP_MAX_PAGE_COUNT TEMP_STATS_WATCH_TIME TIME_ZONE TOTAL_WA_SIZE XA_MSGLOG_RESERVE_SIZE Performance Views The following performance views have been added. For further information on each performance view, please refer to the General Reference. New Performance Views for ALTIBASE HDB V$BACKUP_INFO Information on the process of the incremental backup operation up to the current time point V$DBLINK_ALTILINKER_STATUS Information on the status of the AltiLinker process ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB V$DBLINK_DATABASE_LINK_INFO Information on database link objects V$DBLINK_GLOBAL_TRANSACTION_INFO Information on global transactions executing database links V$DBLINK_LINKER_CONTROL_SESSION_INFO Information on linker control sessions created between the server and the AltiLinker process V$DBLINK_LINKER_DATA_SESSION_INFO Information on linker data sessions created between the server and the AltiLinker process V$EXTPROC_AGENT Information on the agent process created for the execution of external procedures V$NLS_TERRITORY Stores the names of the territories available for specification V$OBSOLETE_BACKUP_INFO Backup information that is no longer required to be maintained V$PKGTEXT Source information of stored packages V$TIME_ZONE_NAMES Territories and UTC offsets that can be specified in the TIME_ZONE property. Error Messages (HDB 6.1.1 to HDB 6.3.1) Added error messages Please refer to the Error Message Reference New error messages Message Status Description 0x4103A (266298) Before mmERR_ABORT_INVALID_STATEMENT_STATE_ERROR Request to process invalid SQL statement # *Cause: A request was made to perform an operation on an SQL statement that was already freed. # *Action: Please verify the SQL statement from the client. After mmERR_ABORT_INVALID_STATEMENT_STATE_ERROR Invalid statement processing request # *Cause: The request was invalid for the current state of the statement. # *Action: Please check the client application. 0x311F9 (201209) Before qpERR_ABORT_TRIGGER_RECOMPILE The attempt to recompile the trigger <0%s> was aborted because the creation statement was invalid. # *Cause: # - The attempt to recompile the trigger failed because the creation statement was invalid. # *Action: # - Please check the trigger creation statement. After qpERR_ABORT_TRIGGER_RECOMPILE The attempt to recompile the trigger <0%s> was aborted because the creation statement was invalid. : <1%s> <2%s> # *Cause: # - The attempt to recompile the trigger failed because the creation ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB statement was invalid. # *Action: # - Please check the trigger creation statement. 0x311B8 (201144) Before qpERR_ABORT_QCI_INVALID_HOST_DATA_SIZE Invalid size of data to bind to a host variable [ NO. <0%d> : Data Size = <1%d> , Declared Size of Host Variable = <2%d> ] # *Cause: # - The size of the data and the size of the host variable differ from one another. # *Action: # - Please check the size of the data to be bound to host variables. After qpERR_ABORT_QCI_INVALID_HOST_DATA_SIZE Size of data to bind to host variable is invalid [ Param ID = <0%d>, Data Type = <1%u>, Data Size = <2%d>, Declared Size of Host Variable = <3%d> ] # *Cause: # - The size of the data and the size of the host variable differ from one another. # *Action: # - Please check the size of the data to be bound to host variables. 0x11166 (69990) Before smERR_ABORT_TRANSACTION_TABLE_SIZE_IS_NOT_POWER_OF_TWO TRANSACTION_TABLE_SIZE ['<0%d>'] is not powers of two. # *Cause: TRANSACTION_TABLE_SIZE is not 2^n. # *Action: Please check altibase.properties and set TRANSACTION_TABLE_SIZE to 2^n. After smERR_ABORT_TRANSACTION_TABLE_SIZE_IS_NOT_POWER_OF_TWO TRANSACTION_TABLE_SIZE ['<0%d>'] is not a power of two. # *Cause: The value of the TRANSACTION_TABLE_SIZE property is not a power of two(=2^n). # *Action: Please check the altibase.properties file and set the value of TRANSACTION_TABLE_SIZE to a power of two (2^n). 0x11168 (69992) Before smERR_ABORT_LOGFILE_TOO_BIG_WITH_DIRECT_IO The logfile is too big. ( <0%d> > <1%d> ) # *Cause: The size of the logfile exceeds the DIRECT I/O limitation. # *Action: Please make sure that the logfile is smaller than the DIRECT I/O limitation, or set the value of the LOG_IO_TYPE property to 0. After smERR_ABORT_LOG_FILE_MISSING Non-continuous log file numbers. ( <0%s> ). # *Cause: Either the server failed to remove an old log file, or a current log file has been lost for some unknown reason. # *Action: Please send a bug report to the vendor. 0x11169 (69993) Before smERR_ABORT_smiCantRestartRemoteTableCursor Unable to restart a remote table cursor # *Cause: An attempt was made to restart a remote table cursor. # *Action: Please do not attempt to restart a remote table cursor. After smERR_ABORT_FAILURE_DURABILITY_AT_STARTUP Restart recovery aborted to protect database durability. # *Cause: A log file has been lost. If restart recovery continues, DB durability and DB objects may be broken. # *Action: Please send a bug report to the vendor. Removed error messages - All OxBxxxx error messages have been removed due to the improvement of the DBLink feature. Message Status Description 0x3129C ( 201372) Removed qpERR_ABORT_QCMLINK_NOT_EXIST_DATABASE_LINK The database link object does not exist. : <0%s> # *Cause: # - The database link object does not exist. ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB # *Action: # - Please check the database link name. 0x3129D (201373) Removed qpERR_ABORT_QCMLINK_NOT_SUPPORTED_STATEMENT The database link does not support this statement yet. # *Cause: # - The database link does not support this statement yet. # *Action: # - No Action. 0x3129E (201374) Removed qpERR_ABORT_QMO_SQL_GENERATION_FAILED Internal server error. dblink module cannot generate SQL statement. # *Cause: # - Internal server error. The dblink module cannot generate an SQL statement. # *Action: # - Please send a bug report to the vendor. 0x3129F (201375) Removed qpERR_ABORT_QMN_REMOTE_META_CHANGED Failed to execute this statement because <0%s> table meta information was changed at the remote site. Retry this statement. # *Cause: # - Execution of this statement failed because the table meta information was changed at the remote site. # *Action: # - retry this statement. 0x1003F (65599) Removed smERR_FATAL_InvalidDiskLogRec The log record for a disk table is invalid. ( LSN {<0%d>,<1%d>} ) # *Cause: The log record for a disk table is invalid. # *Action: Please send a bug report to the vendor. 0x10088 (65672) Removed smERR_FATAL_INVALIDE_ROW_SCN Invalid row SCN # *Cause: Invalid row SCN # *Action: Please send a bug report to the vendor. ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB 2.3 Packages OS Version CPU Archive Name AIX 5.3 PowerPC altibase-HDB-server-6.3.1.0.0-AIX-POWERPC-64bit-release.run altibase-HDB-client-6.3.1.0.0-AIX-POWERPC-64bit-release.run altibase-HDB-client-6.3.1.0.0-AIX-POWERPC-32bit-release.run HP-UX 11.11 PA-RISC altibase-HDB-server-6.3.1.0.0-HPUX-PARISC-64bit-release.run altibase-HDB-client-6.3.1.0.0- HPUX-PA-RISC-64bit-release.run altibase-HDB-client-6.3.1.0.0-HPUX-PARISC-32bit-release.run 11.23 IA64 altibase-HDB-server-6.3.1.0.0-HPUX-IA64-64bit-release.run altibase-HDB-client -6.3.1.0.0-HPUX-IA64-64bit-release.run altibase-HDB-client -6.3.1.0.0-HPUX-IA64-32bit-release.run Solaris 2.8 SPARC altibase-HDB-server-6.3.1.0.0-SOLARIS-SPARC-64bit-release.run altibase-HDB-client-6.3.1.0.0-SOLARIS-SPARC-64bit-release.run altibase-HDB-client-6.3.1.0.0-SOLARIS-SPARC-32bit-release.run 2.10 X86 altibase-HDB-server-6.3.1.0.0-SOLARIS-X86-64bit-release.run altibase-HDB-client-6.3.1.0.0-SOLARIS-X86-64bit-release.run altibase-HDB-client-6.3.1.0.0-SOLARIS-X86-32bit-release.run LINUX Es40-x64 X86 altibase-HDB-server-6.3.1.0.0-LINUX-X86-64bit-release.run altibase-HDB-client-6.3.1.0.0-LINUX-X86-64bit-release.run altibase-HDB-server-6.3.1.0.0-LINUX-X86-32bit-release.run altibase-HDB-server-6.3.1.0.0-LINUX-X86-64bit-release.run Windows 2003 X86 altibase-HDB-server-6.3.1.0.0-WINDOWS-X86-64bit-release.exe altibase-HDB-client-6.3.1.0.0-WINDOWS-X86-64bit-release.exe altibase-HDB-server-6.3.1.0.0-WINDOWS-X86-32bit-release.exe altibase-HDB-client-6.3.1.0.0-WINDOWS-X86-32bit-release.exe ALTIBASE HDB 6.3.1.0.0 Release Notes ALTIBASE HDB 2.4 Downloads Location Package http://support.altibase.com Manual http://support.altibase.com Installation Please refer to the ALTIBASE HDB Installation Guide.

ALTIBASE HDB 5.5.1 Release Notes ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS Table of Contents 1. Abstract 3 1.1 System Requirements 3 1.2 Release Platforms 3 2. Release Information 4 2.1 What is New in ALTIBASE HDB 5.5.1 4 2.2 Changes 5 2.3 Packages 14 2.4 Downloads 14 Location 14 Installation 14 ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS 1. Abstract 1 .1 S y s t em R equi re m ents Minimum Hardware 512MB RAM (Recommended : 1GB) 1 CPU (Recommended : 2 CPUs) 4GB hard disk space (Recommended : 12GB) 1.2 Supported Operating Systems and Platforms OS CPU Version Bit (Server) Bit (Client) AIX PowerPC 5.3 tl1 or above 64bit 64bit, 32bit HP-UX PA-RISC 11.11 or above 64bit 64bit, 32bit IA64 11.23 or above SUN SPARC 2.8 or above 64bit 64bit, 32bit i86PC 2.10 or above Windows x86, x86-64 Windows 2003 64bit, 32bit 64bit, 32bit LINUX x86, x86-64 (GNU glibc 2.3.4 or lower) SSE2 (intel pentium4 above) AS40 64bit, 32bit 64bit, 32bit ES40 64bit, 32bit 64bit, 32bit x86, x86-64 (GNU glibc 2.4.0 or higher) SSE2 (intel pentium4 above) ES50 64bit, 32bit 64bit, 32bit Java Version: Compatible with JDK 1.4 or later versions for JDBC. ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS 2. Release Information 2.1 What is New in ALTIBASE HDB 5.5.1 Eager Replication Enhancements - Introduced multi-threading for performance improvements for the sender/receiver processes. - Improved conflict detection and resolution for fail-back in 2-way replication mode. Eliminated the restriction on the GCC Client Library - In the previous version, the programming language of the Client Library was C++. It was changed to C for compatibility on the GCC development environment. IPv6 Support - IPv6 Network interface configuration is required to use this feature. - If the server supports dual stack then the ALTIBASE HDB client will support dual stack. If the server supports IPv6 only, then the ALTIBASE HDB client will support IPv6 only. Disk Spatial Index Support - ALTIBASE HDB provides Spatial Index for DRDB and builds using Bottom-Up method. Enhanced TMS (Treelist Managed Segment) - Enhanced TMS (Treelist Managed Segment) - one of Bitmap-based segment space management methods - proper to OLTP service. - Default segment space management method is changed from FSM (Freelist Managed Segment) to TMS (Treelist Managed Segment). Improved the Scalability on Logging - ALTIBASE HDB supports not only posix but also native of log file group mutex functions to improve the scalability of the Logging. As the result, the performance of Logging is two times faster than that of the previous Logging technique. DataPort support function for upgrading ALTIBASE HDB - There is no Network communication cost since DataPort functions directly downloads and uploads data. Furthermore, translating cost on data type does not exist since DataPort functions store data with the same type format that ALTIBASE HDB uses. Therefore, ALTIBASE HDB maximizes the performance of the data migration by using DataPort functions. Enhanced performance of Direct-Path INSERT function - Direct-Path INSERT function uses the APPEND feature and a separate buffer area. It improves the performance of disk data migration and uploading data to the disk table. Support Foreign Key NoValidate function - If stating the NOVALIDATE phrase when creating a foreign key in the child table, ALTIBASE HDB skips the foreign key validation check in the Parent table. As such, ALTIBASE HDB does not guarantee data consistency. The invalid tables can be viewed in the meta table called SYS_CONSTRAINTS_. Provides DBC(Database Connectivity) in C programming language - The CLI Library is complicated due to many parameters; and it makes many function calls. Therefore, ALTIBASE HDB provides an additional Library called C/DBC. It is easy to use and it is in the programming language C. Provides ALTIBASE HDB Administrative API ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS - Applications can use the iLoader function and Check Server functions directly via ALTIBASE HDB Administrative APIs. Enhanced OLE DB Provider - Added BLOB data type and geometry data type. - Passed OGC OLE DB Provider test - Connection problem with Delphi is resolved. Adapter for Oracle - ALTIBASE Adapter for Oracle enables replication between an ALTIBASE HDB and an Oracle DB via ALA (Altibase Log Analysis). 2.2 Changes Listed below are added/updated/deleted functions explanations for DBA and developers. Database version updates Updated Database versions ALTIBASE HDB Version Binary database Version Communication Protocol Version Meta Version Replication Protocol Version 5.3.3 5.4.1 5.6.2 5.6.1 5.4.1 5.5.1 5.4.1 5.6.2 5.9.1 5.6.1 Compatibility Binary database version The binary database version indicates the compatibility of database image files and log files. When this value changes, the database must be migrated. Communication protocol version Client programs using ALTIBASE HDB 5.3.3 or above are compatible with the new version. They will connect to ALTIBASE HDB without requiring program rebuilds. For the applications using ALTIBASE HDB 5.3.3 or above, they have to re-link to the ALTIBASE HDB 5.5.1 Library to use IPC connections. ALTIBASE HDB Version CM Protocol Version Client Program Rebuild IPC Client Program Rebuild 5.3.3 5.6.2 XO 5.5.1 5.6.2 X X Meta version The Meta version will be upgraded to 5.9.1 automatically after upgrading ALTIBASE HDB to 5.5.1. Downgrade is not supported. ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS Replication protocol version Replication between different replication protocol versions is not supported. ALTIBASE HDB Version Replication Protocol Version Compatibility 5.3.3 5.4.1 X 5.5.1 5.6.1 X Client compatibility Application development environment Development Environment Modification C language (ODBC, OLE DB) The spatial data structure has been modified. Therefore, Spatial applications must be modified for ALTIBASE HDB 5.5.1. JAVA ABConnectionPoolDataSource has been renamed to ABPoolingDataSource Changes on DBA utilities Utility Modification ( 5.3.3 to 5.5.1 ) Note iLoader FORM file format iLoader may use the quotation marks(“) on the table name and the column in the FORM file. The previous FORM file is compatible on ALTIBASE HDB 5.5.1. Data file format If there are no changes on the FORM file, iLoader can upload data with the existing data file. Command option iLoader ignores PARALLEL hint in the “INSERT INTO … SELECT” statement. iLoader ignores the -ioparallel option. -array and -commit options are available for the Direct-Path INSERT function. The following values are recommended. array size: 5,000 or higher commit unit: five or higher (set the proper value since a transaction can be aborted in the middle of the process.) Dumpdp (dump DataPage) Problem Tracking function enhancement The name of dumpdp(dumpDataPage) has been changed to dumpci(dump CheckpointImage) File specification argument of dumplf, dumpddf and dumpci utilities have been changed to -f. The help scripts of dumpddf, dumplf and dumpci utilities have been modified. The page logical dump function was added to the dumpddf utility ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS Utility Modification ( 5.3.3 to 5.5.1 ) Note dumplf (Dump LogFile) Option explanation Before modification Usage : dumplf -f file [-t transactionID] [-s] [-l] After modification Usage : dumplf {-f log_file} [-t transaction_id] [-s] [-l] -f : specify log file name -t : specify transaction id -s : silence log value -l : display log types dumpla (Dump LogAnchor) Option explanation Before modification Usage: dumpla After modification Usage: dumpla loganchor_file dumplf, dumpci, dumpddf, dumpla Output format Naming on the information file of dumplf and dumpla utilities are now consistent. dumplf utility prints out the Log Record body of MMDB(Main Memory DB). The utilities print out more detailed information of the page in MMDB and DRDB. The output of utilities is in Hexa format, and it may be shown in logical structure format. Adapter for Oracle compatibility ALTIBASE Adapter for Oracle is supported with ALTIBASE HDB version 5.5.1.1.4 and above. ALTIBASE HDB version 5.5.1.1.4 is compatible only with oraAdapter version 5.5.1.1.4. Replication between different versions of ALTIBASE and oraAdapter is not supported. ALTIBASE Adapter for Oracle version 5.5.1.1.4 is supported for use with AIX versions 5.3 tl1 and above and Oracle versions 10g r2 and above, which are compatible with the Oracle OCI. Property New ALTIBASE HDB Properties Name Description New Properties DATAPORT_FILE_DIRECTORY The Dataport function uses the value of this property as a default directory to store exported/imported data. DATAPORT_IMPORT_COMMIT_UNIT The value of this property determines how many statements are committed at one Commit command when the DataPort function imports data. DATAPORT_IMPORT_STATEMENT_UNIT The value of this property determines how many rows are processed by one statement when DataPort function imports data. REPLICATION_COMMIT_WRITE_WAIT_ MODE If the value is 1, the Receiver Thread waits until a committed data is synchronized to disk. ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS Name Description REPLICATION_SERVER_FAILBACK_MA X_TIME If ALTIBASE HDB is in Eager Replication mode, it synchronizes data with the peer server at the start up of service. If the synchronization takes more than the value of this property, ALTIBASE HDB stops the synchronization. Default: 2^32 - 1 seconds) This property may be used to perform a Full Sync manually or give up a Fail-Back. REPLICATION_EAGER_PARALLEL_FAC TOR If ALTIBASE HDB is in Eager Replication mode, many Sender Threads may work in parallel. The value of this property determines how many Sender Threads work in parallel. Default: the smaller value from the following - number of CPU cores - 512 LOG_ALLOC_MUTEX_TYPE This value determines the allocation mutex type. Default: 0(POSIX) 1: NATIVE1 2: NATIVE2 3: NATIVE3 Deleted ALTIBASE HDB properties ALTIBASE HDB properties Description Deleted Properties DIRECT_BUFFER_FLUSH_THREAD_SYN C_INTERVAL This property is now a hidden property since ALTIBASE HDB supports a logic that minimizes I/O bottleneck. DIRECT_PATH_INSERT_TEMP_QUEUE_S IZE The Queue was the bottleneck on the previous Direct-Path INSERT function, and has been removed. DIRECT_PATH_INSERT_TEMP_QUEUE_ WAIT_TIME The Queue was the bottleneck on the previous Direct-Path INSERT function, and has been removed. Modified Properties (5.3.3 => 5.5.1) ALTIBASE HDB properties Description Modified Properties DEFAULT_SEGMENT_MANAGEMENT_T YPE Default Value 0 => 1 INDEX_BUILD_THREAD_COUNT Default Value 2 => 4 IPC_PORT_NO Default Value 8802 => 20350 MULTIPLEXING_THREAD_COUNT Default Value 8 => 4 PARALLEL_LOAD_FACTOR Default Value 4 => 8 TRCLOG_DETAIL_PREDICATE Default Value 1 => 0 REPLICATION_MAX_LOGFILE, REPLICATION_RECOVERY_MAX_LOGFI LE These properties do not affect Eager Replication any longer. REPLICATION_SERVICE_WAIT_MAX_LI MIT This property does not affect Eager Replication any longer. ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS Performance View New Performance View Name Description V$REPGAP_PARALLEL (Expansion to V$REPGAP) It extends V$REPGAP to show the Replication Gap information of parallel Replication Objects. Added Column PARALLEL_ID: Each Sender/Receiver Thread has a separate ID. CURRENT_TYPE: The type of Replication Sender/Receiver Thread Removed Column and START_FLAG: CURRENT_TYPE replaced it. V$REPRECEIVER_PARALLEL (Expansion to V$REPRECEIVER) It extends V$REPRECIEVER to show information of parallel Replication Receiver Threads. Added Column PARALLEL_ID: Each Sender/Receiver Thread has a separate ID. V$REPRECEIVER_TRANSTBL_PARALLE L (Expansion to V$REPRECEIVER_TRANSTBL) It extends V$REPRECIVER_TRANSTBL to show the information of Transaction Tables for the parallel Receiver Threads. Added Column PARALLEL_ID: Each Sender/Receiver Thread has a separate ID. V$REPSENDER_PARALLEL (Expansion to V$REPSENDER) It extends V$REPSENDER to show information of parallel Replication Sender Threads. Added Column PARALLEL_ID: Each Sender/Receiver Thread has a separate ID. CURRENT_TYPE: The type of Replication Sender/Receiver Thread Removed Column ACT_REPL_MODE: The value of this column does not change on ALTIBASE HDB 5.5.1. START_FLAG: CURRENT_TYPE replaced it. V$REPSENDER_TRANSTBL_PARALLEL (Expansion to V$REPSENDER_TRANSTBL) It extends V$REPSENDER_TRANSTBL to show information of Transaction Tables for parallel Sender Threads. Added Column PARALLEL_ID: Each Sender/Receiver Thread has a separate ID. CURRENT_TYPE: The type of Replication Sender/Receiver Thread Removed Column START_FLAG: CURRENT_TYPE replaced it. ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS Name Description V$DIRECT_PATH_INSERT COMMIT_TX_COUNT : Total number of transactions successfully committed using the Direct-Path INSERT function. ABORT_TX_COUNT : Total number of transactions aborted using the Direct- Path INSERT function. INSERT_ROW_COUNT : Total number of rows inserted using Direct-Path INSERT function. ALLOC_BUFFER_PAGE_TRY_COUNT : Total number of counts that the Page allocation was requested by the Direct-Path INSERT function. ALLOC_BUFFER_PAGE_FAIL_COUNT : The total numbers of counts that the Page allocation failed using the Direct-Path INSERT function. Error messages (5.3.3 to 5.5.1) Removed Error Messages Message Status Description 0x0002E ( 46) Removed Failed to create a thread object. # *Cause: Internal Bug # *Action: Please send a bug report to the vendor. 0x10146 ( 65862) Removed There are no double write files. Check your properties. # *Cause: DOUBLE_WRITE_DIRECTORY property is modified. # *Action: check your properties. # Server Internal Message Modified Error Messages Message Status Description 0x1101F ( 69663) Before The Maximum size of the data file cannot be less than the current size of it. ( Current Size : <0%ld>, Request Max Size : <1%ld> ) # *Cause: The maximum size of the data file is less than the current size of the data file. # *Action: Please reset the INITSIZE or MAXSIZE of the data file correctly. After The MAXSIZE of data file is less than the current size of it. ( Request Max Size : <0%lu> pages, Current Size : <1%lu> pages ) # *Cause: The MAXSIZE of the data file is less than the current size of the data file. # *Action: Please reset the MAXSIZE of the data file correctly. 0x11020 ( 69664) Before The INITSIZE of a data file exceeds the maximum file size. ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS Message Status Description After The INITSIZE of a data file exceeds the maximum file size. ( Request Init Size : <0%lu> pages, Maximum File Size : <1%lu> pages ) 0x11021 ( 69665) Before The CURRSIZE of a data file exceeds maximum file size. After The CURRSIZE of a data file exceeds maximum file size. ( Request Cur Size : <0%lu> pages, Maximum File Size : <1%lu> pages ) 0x11022 ( 69666) Before The MAXSIZE of data file exceeds maximum file size. ( Request Max Size : <0%ld>, Max Size : <1%ld>) After The MAXSIZE of data file exceeds maximum file size. ( Request Max Size : <0%lu> pages, Maximum File Size : <1%lu> pages ) 0x11030 ( 69680) Before The data file cannot be extended because the requested size is bigger than the maximum size(<0%d> pages). After The requested size of data file exceeds the maximum file size. ( Request Size : <0%lu> pages, Maximum File size : <1%lu> pages ) 0x11105 ( 69893) Before The data file cannot be extended because the requested size is bigger than the OS file limit size(<0%d> pages). After The requested size of data file exceeds the OS file limit size. ( Request Size : <0%lu> pages, OS File Limit Size : <1%lu> pages ) 0x11122 ( 69922) Before you can not shrink this file. # *Cause: you tried to shirink below HWM. # *Action: Don't do it. After The requested size of data file is less than the used size of data file. ( Request Size : <0%lu> pages, Used File Size : <1%lu> pages ) # *Cause: you tried to shrink below HWM. # *Action: Please retry with a greater size. 0x11124 ( 69924) Before you can't even make one extent. # *Action: You know what to do. After The INITSIZE of data file is less than the minimum file size. ( Request Init Size : <0%lu> pages, Minimum File Size : <1%lu> pages ) # *Action: Please retry with a greater size. 0x11128 ( 69928) Before the size is too small to make an extent. After The requested size of data file is less than the minimum file size. ( Request Size : <0%lu> pages, Minimum File Size : <1%lu> pages ) 0x61055 ( 397397) Before Memory allocation failure After Memory allocation failure [Function=<0%s>, Variable=<1%s>] 0x6200F ( 401423) Before [Sender] Stop sender thread <0%s> at [<1%ld>], Restart SN[<2%ld>] After [Sender] Stop sender thread <0%s>:<1%d> at [<2%ld>], Restart SN[<3%ld>] 0xB107C ( 725116) Before Memory allocation failure After Memory allocation failure [Function=<0%s>, Variable=<1%s>] ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS Modified SQL syntax Name Description Option changed: ALTER SESSION SET REPLICATION= Either DEFAULT or NONE can be used for this SQL statement. Other values (LAZY, ACKED and EAGER) are not supported. Removed SQL: ALTER REPLICATION SET MODE = ALTER REPLICATION replication_name SET MODE {LAZY|ACKED|EAGER}; This SQL statement changes the replication mode, but it is not supported anymore. Replication mode cannot be changed in 5.5.1. CREATE TABLESPACE USER_BITMAP_TBS DATAFILE user_bitmap_tbs.dbf EXTENTSIZE 512K SEGMENT MANAGEMENT AUTO; Default Segment management method has changed from FMS (Freelist Managed Segment) to TMS (Treelist Managed Segment). The “SEGMENT MANAGEMENT AUTO” phrase can be omitted. The default value of EXTENTSIZE has changed from 256K to 512K for both FMS and TMS. CREATE TABLESPACE USER_FREELIST_TBS DATAFILE user_freelist_tbs.dbf EXTENTSIZE 512K SEGMENT MANAGEMENT MANUAL; FMS must be explicitly stated. Restrictions DataPort Function Description Same table schema must exist to import data. If one of following is different, the DataPort function cannot import data; column position, number, precision and scale. It is impossible to import/export on the encrypted tables. Encryption must be removed by ALTER statement in order to import/export data. Importing/Exporting can be performed on the new tables made by the CTAS (Create Table As Select) statement on the encrypted tables. Importing is not possible on tables that have a trigger, foreign key, index and a not null column. Furthermore, importing cannot be performed on the tables in the Replication Object. The DataPort function does not validate all the above restrictions before execution. Therefore, invalid data can be inserted if the restrictions listed above exist on the tables. Data must be imported after resolving the restrictions. Restrictions must be applied after DataPort function finishes the work. Eager Replication Functionality Description DDL on Replication On-line The Receiver Thread stops while ALTIBASE HDB performs DDL. In this case, Data Conflict may occur. Selection Replication It is a data filtering function, and is a proper function for ALA. Off-Line Replicator Data Conflict and replication gap does not occur in Eager Replication mode. Lazy/Acked Replication If the local server is in Eager Replication mode, the peer server must be in Eager Replication mode. Otherwise, Data Conflict may occur. ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS Functionality Description Replication Give-up The value of REPLICATION_MAX_LOGFILE must not be set in Eager Replication mode since ALTIBASE HDB deletes logfiles if Replication Give-up occurs; Replication Give-up occurs when the existing numbers of logfiles are larger than the value of REPLICATION_MAX_LOGFILE. ALTIBASE HDB deletes all logfiles not required to resolve the Data Conflict. Max Rows The Max Rows restriction may fail a commit command, so it must not be used in Eager Replication mode. Data Conflict cannot be resolved if a commit command fails. Other Modifications on management of storage space ALTIBASE HDB Version Description ALTIBASE HDB 5.3.3 or below ALTIBASE HDB 5.3.3 or below does not support Non-Autocommit mode in the Direct-Path INSERT function. Therefore, the maximum storage space that the Direct-Path INSERT function uses is as follows. Number of Threads * Number of partitions * Number of Pages per Extent ALTIBASE HDB 5.3.5 or above The Direct-Path INSERT function allocates a new Page for every Cursor although an empty space may exist in the allocated Pages due to the characteristic of Buffer management. Furthermore, the Direct-Path INSERT function uses the APPEND method, and the APPEND method allocates a new Extent for each transaction start; although empty Pages exist before the HWM (High Water Mark). As a result, some storage space is wasted. The total space that the Direct-Path INSERT function uses for one transaction can be calculated as the following. (n: number of rows to insert, a: array size, c: commit unit) {(Page Size*[n/a])+(NEXTEXTENTS*(Number of Pages per Extent)*[nla/c])}}*Number of partitions Direct-Path INSERT function on different ALTIBASE HDB versions Column Name Description ALTIBASE HDB 5.3.3 or below The Non-Autocommit mode is not supported, and the value of commit unit is fixed to 1. Furthermore, the performance of Direct-Path INSERT function is slower than that of the ATOMIC INSERT. Therefore, it is not recommended to use this function. ALTIBASE HDB 5.3.5 The Non-Autocommit mode is supported. In the iLoader, the performance of Direct-Path INSERT function is generally faster than that of ATOMIC INSERT. (In some environments and schemas, the performance is slower.) Therefore, it is recommended to use this function. ALTIBASE HDB 5.5.1 The Non-Autocommit mode is supported, and the push method has been improved. The performance of the Direct-Path INSERT function is much faster than that of ATOMIC INSERT. Therefore, it is recommended to use this function. ALTIBASE HDB Release Notes 5.5.1.0.0 ALTIBASE HDB® HDB™ Hybrid RDBMS 2.5 Packages OS Version CPU Archive Name AIX 5.3 powerPC altibase-server-5.5.1.0-AIX-POWERPC-64bit-release.run altibase-client-5.5.1.0-AIX-POWERPC-32bit-release. run altibase-oraAdapter-5.5.1.1.4-AIX-POWERPC-32bit-release. run HP-UX 11.11 PA-RISC altibase-server-5.5.1.0-hpux-PA-RISC-64bit-release. run altibase-client-5.5.1.0-hpux-PA-RISC-32bit-release. run 11.23 IA64 altibase-server-5.5.1.0-hpux-IA64-64bit-release. run altibase-client -5.5.1.0-hpux-IA64-32bit-release. run Solaris 2.8 SPARC altibase-server-5.5.1.0-SOLARIS-SPARC-64bit-release. run altibase-client-5.5.1.0-SOLARIS-SPARC-32bit-release. run 2.10 X86 altibase-server-5.5.1.0-SOLARIS-X86-64bit-release. run altibase-client-5.5.1.0-SOLARIS-X86-32bit-release. run Linux/glibc ES40-x64 X86 altibase-server-5.5.1.0-LINUX-X86-64bit-release. run altibase-server-5.5.1.0-LINUX-X86-32bit-release. run altibase-client-5.5.1.0-LINUX-X86-32bit-release. run Windows 2003 X86 altibase-server-5.5.1.0-WIN_NT-X86-64bit-release.exe altibase-server-5.5.1.0-WIN_NT-X86-32bit-release. exe altibase-client -5.5.1.0-WIN_NT-X86-32bit-release. exe 2.6 Downloads Location Packages http://www.altibase.com/ Manual http://www.altibase.com/ Installation Refer to Installation User's Manual.

ALTIBASE HDB 5.5.1.2.0 Patchset Notes October 18, 2011 ALTIBASE HDB Patchset Notes 5.5.1.2.0 2/27 Table of Contents PATCHSET LIST (5.5.1.1.1 ~ 5.5.1.2.0) 3 5.5.1.1.1 3 5.5.1.1.2 4 5.5.1.1.3 7 5.5.1.1.4 10 5.5.1.1.5 13 5.5.1.1.6 17 5.5.1.1.7 18 5.5.1.1.8 20 5.5.1.1.9 22 5.5.1.1.10 22 5.5.1.1.11 23 5.5.1.2.0 23 tes ALTIBASE HDB Patchset Notes 5.5.1.2.0 3/27 PatchSet List (5.5.1.1.1 ~ 5.5.1.2.0) 5.5.1.1.1 Fixed Bug Descriptions BUG-31979 ALA needed a NULL checking function. oraApplier, NULL Checking ALA needed a NULL checking function. It is now possible to check for NULL values using the API's ALA_isNullValue function. BUG-31997 The server can shut down due to a query that uses a disk temporary table. Disk Temporary Table, Fatal, Shutdown When using RID to access temporary tables, RID can refer to an invalid row, leading to server shutdown. A fatal can occur upon execution of queries that access disk temporary tables. e.g. SELECT DISTINCT A.C_ID AS SRVCID, A.C_URL AS SRVCURL FROM TA A LEFT OUTER JOIN TB B ON A.E_ID = B.E_ID LEFT OUTER JOIN TC C ON B.CODE = C.CODE LEFT OUTER JOIN TD D ON A.C_ID = D.C_ID WHERE (A.C_NM LIKE '%%' OR B.E_NM LIKE '%%') AND (A.C_URL LIKE '%%' OR B.E_NM LIKE '%') ORDER BY A.C_ID; Workaround: Use memory temporary tables instead of disk temporary tables. BUG-32194 Abnormal server shutdown due to invalid LOB size or offset values. LOB, Fatal, Shutdown A similar problem was reported in BUG-31315. The server does not verify LOB size or offset values passed from clients, leading to abnormal shutdown. Error [08S01] # 331843 [Communication link failure] can be raised upon execution of certain SQL statements. e.g. CREATE TABLE T1 ( I1 CLOB ) TABLESPACE SYS_TBS_DISK_DATA; INSERT INTO T1 VALUES( NULL ); api_read -t T1 -c I1 -k c -o 2 -a -2 I1 length(0)Error : SQLGetLob : Return Code : SQL_ERROR Line Number : 415 Error : [08S01] # 331843, Communication link failure. Server closed the connection. BUG-32228 Application cannot access LOB data using JDBC. LOB, JDBC, Testcase Fail Applications cannot access LOB data using JDBC when a NULL CLOB value exists in a java file. ALTIBASE HDB Patchset Notes 5.5.1.2.0 4/27 A similar problem was reported in BUG-32194. 5.5.1.1.2 Fixed Bug Descriptions BUG-32070 Eager replication failback cannot be performed completely. Eager Replication, Fatal Eager replication failback cannot be performed completely when a failback master is restarted during EAGER replication failback. Now that this bug has been fixed, the failback master uses the same sender information that was used before restarting. Error Code: If replication has this bug, eager replication failback is not performed. 253,rpERR_ABORT_SENDER_INFO_NOT_EXIST = No Sender information for replication <0%s>. # *Cause: # - There is no information about the replication Sender. # *Action: # - Please send a bug report to the vendor." BUG-32071 An encrypted column having a default value other than NULL cannot be added. Encryption, Testcase Fail An encrypted column having a default value other than NULL cannot be added to a partitioned table. An Error : [ERR-31303 : Function call error: [ Error: Encryption is not allowed]] can occur for DDL statements. e.g. alter table t1 add ( i3 varchar(5) encrypt using 'reverse' default 'xyz'); BUG-32222 Data inconsistencies can arise from offline replication. Offline Replication, Data Inconsistencies If a server fails abnormally when not all transaction logs of a server have been synchronized to disk, then offline replication in the other server cannot process the logs, leading to data inconsistencies. This problem can occur in the following way: 1. The server shuts down abnormally while processing many incoming transactions in an NFS offline replication environment. 2. Offline replication starts immediately thereafter. 3. Data inconsistencies occur after the active server is started. Workaround: 1. Flush data from the MMAP area to disk using the SYNC command on the active server before commencing offline replication. 2. Set COMMIT_WRITE_WAIT_MODE value to 1. BUG-32226 There's no version informayion for oraApplier. oraApplier, Version It is now possible to view information about the oraApplier version. ALTIBASE HDB Patchset Notes 5.5.1.2.0 5/27 The oraApplier version is identical to the Altibase version. Usage: oraApplier -v oraApplier -version BUG-32235 Usage of Java heap memory dramatically increases (memory leakage). Memory Error, Memory Leakage The usage of Java heap memory dramatically increases as a result of a NULL Pointer exception in the removeStatement() of an ABConnection object. An ABConnection statement list should be protected with a lock to ensure thread safety. This problem can occur when Java threads share single connection object. (e.g. Jeus WAS) BUG-32238 ALTIBASE v.5.5.1 uninstaller requires a function to check the status of the server ALTIBASE v.5.5.1 Installer Changes: 1. internal installer variables should be used instead of 'whoami' 2. install or rollback can be completed even if an error occurs. BUG-32241 ALTIBASE v.5.5.1 uninstaller must clear additional Windows registry entries. ALTIBASE v.5.5.1 Installer When uninstalling the Altibase Windows package, the Altibase 551 uninstaller must clear additional Windows registry entries. Support has been added to achieve this. BUG-32243 Server terminated abnormally due to SIGSEGV when obtaining X$MUTEX. SIGSEGV, Mutex Lock Contention Improve the select performance of x$mutex by eliminating x$mutex lock contention. This problem can be reproduced in the following way: 1. Open one connection. Make the session busy. sh run.sh s 0 1 16 TCP 2. Open another session. Attempt to obtain an X$MUTEX. SELECT count(*) FROM X$MUTEX; BUG-32244 A maximum of 128 IPC connections is allowed in Windows. IPC, Fatal This problem can be reproduced in the following way: 1. Connect more than 200 clients to one server. 2. Execute the following query: "select count (*) from v$session where comm_name like '%IPC'" Workaround: always ensure that the number of IPC connections to a Windows server is 128 or less. BUG-32248 The version format of oraAdapter has been changed oraAdapter, Version Information about the version of the Altibase to Oracle replication utility has been changed. The version format of oraAdapter has been changed ----------------------------------------------------------------- from ALTIBASE HDB Patchset Notes 5.5.1.2.0 6/27 Altibase to Oracle replication utility. Altibase version 7.1.0.0.0 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. ----------------------------------------------------------------- to Altibase Adapter for Oracle version 7.1.0.0.0 XEON_LINUX_redhat_Enterprise_release5.5-64bit-7.1.0.0.0-debug-GCC4.1.2 (xeon- redhat-linux-gnu) May 31 2011 15:10:55 BUG-32249 The configuration of the sample file for oraAdapter has been changed. oraAdapter, Properties The configuration of the sample file for the Altibase to Oracle replication utility has been changed as follows: [ OPEN PROPERTIES ] ALA_XLOG_POOL_SIZE [ HIDDEN PROPERTIES ] ALA_LOG_DIRECTORY ALA_LOG_FILE_NAME ALA_LOG_FILE_SIZE ALA_MAX_LOG_FILE_NUMBER BUG-32250 The default value of the ORACLE_AUTOCOMMIT_MODE property has been changed. oraAdapter, Properties The default value of the Altibase to Oracle replication utility ORACLE_AUTOCOMMIT_MODE propety has been changed from 1 to 0. oraAdapter always uses the "Committed Buffer" function. BUG-32254 Product name change from OraApplier to oraAdapter oraAdapter, Product name The names of directories, source files, and binary names should be changed to reflect the product name change from OraApplier to oraAdapter. 1. Change directory names: - from ut/oraApplier to ut/oraAdapter - from TC/Utility/oraApplier to TC/Utility/oraAdapter 2. Change file names: - from Main.c to oaMain.c - from OraApplier.conf to oraAdapter.conf - from oraApplier.ts to oraAdapter.ts 3. Change strings: - from OraApplier to oraAdapter - from oraApplier to oraAdapter - from ORA_APPLIER to ORA_ADAPTER - from Altibase Adapter to ALTIBASE Adapter e.g. $ ./oraAdapter -v BUG-32256 Incorrect results can be received from sort join queries. Sort Join Queries, Incorrect Results A SORT plan node loses sort direction information ( asc or desc ) when idle due to the receipt of already sorted records from a child node, thereby leading to incorrect results. The following SQL statement returns incorrect results: ALTIBASE HDB Patchset Notes 5.5.1.2.0 7/27 prepare select /*+ no_plan_cache use_sort(a,b) */ b.i1 from t1 a, ( select i1 from t2 order by i1 desc limit :h1 ) b where a.i1 = b.i1; This problem can occur in the following way: When records are received in the desired sorted order from a child execution plan node. Workaround: Change the query plan from sort join to hash join using the hint /*+ use_hash(a,b) */. BUG-32262 The oaUtility start|stop commands in Altibase adapter for Oracle do not work properly. oraAdapter, Command This problem can occur in the following way: % oaUtility stop /qa/oraApplier/work/altidev4/ut/oraApplier/src/dist/bin/OraApplier's PID is 434404 shutdown /qa/oraApplier/work/altidev4/ut/oraApplier/src/dist/bin/OraApplier /qa/oraApplier/work/altidev4/ut/oraApplier/src/dist/bin/oaUtility: line 66: kill: (434404) - No such process % oaUtility status /qa/oraApplier/work/altidev4/ut/oraApplier/src/dist/bin/OraApplier is alive % ps -ef | grep oraApply oraApply 647330 1 0 13:14:38 pts/3 0:00 /qa/oraApplier/work/altidev4/ut/oraApplier/src/dist/bin/OraApplier BUG-32264 The installer now includes the oraAdapter package. ALTIBASE v.5.5.1 Installer, oraAdapter The installer now includes the oraAdapter (ALTIBASE Adapter for oracle) package. BUG-32273 The 5.5.1 release notes in Altibase installer have been updated from v1.0 to v1.2. ALTIBASE v.5.5.1 Installer, Release Notes Changes: ALTIBASE_5_5_1_0_0_ReleaseNote_Eng_version_1_0.pdf -> ALTIBASE_HDB_5_5_1_ReleaseNotes_v1.2.pdf 5.5.1.1.3 Fixed Bug Descriptions BUG-31947 A compile error can occur when the altibase and alticore versions are mismatched. Compile Error, Version The version of Alticore needs to be checked when compiling Altibase. BUG-32054 The server shuts down abnormally when a network failure occurs while the server is starting up. Replication, Shutdown ALTIBASE HDB Patchset Notes 5.5.1.2.0 8/27 BUG-32140 The REPLICATION_KEEP_ALIVE_CNT property is not implemented as intended. Replication, Timing Error BUG-32174 The server shuts down abnormally when an exception occurs in rpcExecutro::initialize() while the server is starting up. Replication, Fatal This problem can occur in the following way: Failure to allocate memory during server startup. BUG-32178 When a network error occurs after handshaking, replication Sender shutdown may be suspended. Replication, Shutdown When a network error occurs after handshaking, Sender shutdown may be suspended because the Sender waits for ACK from the Receiver without having first sent a STOP XLog. BUG-32200 Abnormal shutdown when using both the MIN() and MAX() functions with the GROUP BY function in a query. DRDB Sort Temporary Table, Shutdown The length of the largest column in a DRDB Sort temporary table can be incorrectly estimated, leading to abnormal shutdown. This problem can occur in the following way: When the server builds a temporary table for sorting using a VarBit or encrypted column, The size of the column value in row is the maximum size. ERR-311e0(errno=11) The estimated size of the index key exceeds the maximum limit. e.g. CREATE TABLE T1( I0 INTEGER, I1 VARBIT(2000) ) TABLESPACE SYS_TBS_DISK_DATA; INSERT INTO T1 VALUES (1, NULL ); INSERT INTO T1 VALUES (1, BIT'01' ); SELECT MAX(I1) FROM T1 GROUP BY I1; Changes: 1. running the encryption module ${HOME}/damo4hdb/keymanager $ keymanager -start 4 policy_damo.sh : create the policy and authority 2. add the following PROPERTIES after building ALTIBASE $ALTIBASE_HOME/conf/altibase.properties SECURITY_MODULE_NAME = DAmo SECURITY_MODULE_LIBRARY = libdamo.so SECURITY_ECC_POLICY_NAME = OE_POL_A ${HOME}/damo4hdb/inst.sh 3. affected commands ALTER SYSTEM START SECURITY; ALTER SYSTEM STOP SECURITY; BUG-32234 INSERT or UPDATE operations can lead to abnormal shutdown. DML Operations, Shutdown When INSERT or UPDATE operations are performed, column information needs to be verified in order to prevent problems that occur upon failure to write trailing NULLS during an ALTIBASE HDB Patchset Notes 5.5.1.2.0 9/27 UPDATE operation. Changes: Defense code has been added to address this. BUG-32278 When a row piece overflows, the previous flag is set incorrectly, leading to abnormal termination. Row Piece Overflow, Fatal When a row piece overflows, the previous flag is set incorrectly, leading to abnormal termination due to an incorrect size assertion. This problem can occur in the following way: create table t1 ( i1 varchar(8000), i2 integer, i3 varchar(8000) ) tablespace sys_tbs_disk_data; insert into t1 values( lpad(0, 1000, '1'), 1, lpad(0, 7000, '1') ); update t1 set i3 = lpad(0, 7824, '1'); update t1 set i2 = 2; select * from t1; BUG-32282 The product name should be changed to 'ALTIBASE HDB' in the installer. ALTIBASE v.5.5.1 Installer, Product name Changes: The product name has been changed in the Altibase installer from 'Altibase HDB' to 'ALTIBASE HDB'. BUG-32295 The TSM needs a fetch column list for using DRDB indexes. Testcase fail - F4 TSM The TSM needs a fetch column list for using DRDB indexes. (Committed only in trunk; needs to be committed in other branches.) This problem was introduced when fixing bug-32173. BUG-32297 Altibase Unix installer needs to guide users in setting user-specified properties, and needs to validate those properties. ALTIBASE v.5.5.1 Installer, Guide, Validate BUG-32304 An HDB 5.5.1 branch compile error occurs in 32-bit Linux and Windows 2003. Alticore Versions, Compile Error An HDB 5.5.1 branch compile error occurs in 32-bit Linux and Windows 2003 because the make variable LD_CC in the makefile does not exist in previous versions of Alticore. BUG-32309 An iloader shell script (iloaderup) does not work iloader An iloader shell script (iloaderup) does not work because it contains the Windows line feed character '^M'. e.g. -bash: ./iloaderup: /usr/bin^M: bad interpreter: No such file or directory ALTIBASE HDB Patchset Notes 5.5.1.2.0 10/27 BUG-32315 The Altibase 5.5.1 CAPI sample does not work in Solaris. CAPI sample, Compile error The Altibase 5.5.1 CAPI sample does not work in SOLARIS because the common.h file format must be converted from a DOS file to a Unix file. Workaround: 1. dos2unix 2. vi ( :%s/^M//g) 3. tr -d ‘\r’ BUG-32317 The XA_HEURISTIC_COMPLETE property should be externally visible in v$property. XA_HEURISTIC_COMPLETE Property This problem was introduced in 5.3.1 with the fix for bug-26183. Changes: The XA_HEURISTIC_COMPLETE property will be externally visible in v$property. BUG-32321 Connection fails after attempting to connect for 5 seconds. Functional Error, Connection failed This problem was introduced in 5.3.3 with the fix for bug-29769. This problem can occur in the following way: Connect with option DriverManager.setLoginTimeout(5000) Workaround: Connect with option DriverManager.setLoginTimeout(5000000) Changes: The units of the setLoginTimeout function should be changed from milliseconds to seconds in compliance with JDBC specifications. 5.5.1.1.4 Fixed Bug Descriptions BUG-32329 It should be possible to set timeout values independently of the data source. JDBC DataSource, Login, Timeout Changes: A DataSource.setLoginTimeout() method should be implemented so that the timeout values can be set independently of the data source. BUG-32351 InstallBuilder does not handle permission errors properly. ALTIBASE v.5.5.1 Installer, Abnormal Termination The unused and problematic AutoJavaDetect function needs to be removed from the Altibase HDB Unix installer. Changes: Target: unix installer files : server/clientInstall.xml, server/clientPatchInstall.xml Remove unused AutoJavaDetection function. ALTIBASE HDB Patchset Notes 5.5.1.2.0 11/27 BUG-32352 Properties for preventing the execution of DML statements in Oracle have been added to oraAdapter. oraAdapter, Properties Changes: The following properties have been added. [Concept > Adapter for Oracle Configuration > Property] Name Description ORACLE_SKIP_INSERT Insert DML statements are prevented from being executed on an Oracle Database. 0 : Do Not Skip (Default) 1 : Skip ORACLE_SKIP_UPDATE Update DML statements are prevented from being executed on an Oracle Database. 0 : Do Not Skip (Default) 1 : Skip ORACLE_SKIP_DELETE Delete DML statements are prevented from being executed on an Oracle Database. 0 : Do Not Skip (Default) 1 : Skip BUG-32355 Properties for preventing the application of DML statements have been added to oraAdapter. ALTIBASE v.5.5.1 Installer, oraAdapter, Properties Changes: The installer script must thus be modified accordingly so that it changes these oraAdapter.properties. ORACLE_SKIP_INSERT ORACLE_SKIP_UPDATE ORACLE_SKIP_DELETE BUG-32377 It was difficult to determine the causes of errors in the checkServer library, since only an ALTIBASE_CS_ERROR code was returned in most error cases. checkServer library, Error Codes Changes: The checkServer library returns a greater variety of error codes. In addition, BUG-32370, which is related to exception handling when handle == Null in the checkServerRun() and checkServerKill() functions, has also been fixed. - current error codes in most cases Name Value Description ALTIBASE_CS_SUCCESS 0 ALTIBASE_CS_ERROR -1 general error - additional error codes Name Value Description ALTIBASE_CS_SUCCESS_WITH_INFO 1 ALTIBASE_CS_SERVER_STOPPED ALTIBASE_CS_SUCCESS ALTIBASE_CS_INVALID_HANDLE -2 Invalid handle error ALTIBASE_CS_ABORTED_BY_USER -3 aborted by user ALTIBASE HDB Patchset Notes 5.5.1.2.0 12/27 ALTIBASE_CS_DUP_INIT_ERROR -4 Duplicate initialization error Each process can only call checkServer once. This error arises when a single process attempts to simultaneously use checkServer multiple times. ALTIBASE_CS_LIB_INIT_ERROR -5 library initialization error (global memory manager initialization fails) ALTIBASE_CS_LIB_DESTROY_ERROR -6 library destruction error (global memory manager destruction fails) ALTIBASE_CS_CHECK_SERVER_COUNT_ERROR -7 checkServer count error (the number of checkServer libraries is abnormal) ALTIBASE_CS_MALLOC_ERROR -8 malloc error (malloc failure due to insufficient memory) ALTIBASE_CS_SLEEP_TIME_ERROR -9 Sleep time error (raised when sleep time is a negative number) ALTIBASE_CS_MSGLOG_INIT_ERROR -10 MsgLog file initialization error ALTIBASE_CS_INVALID_NULL_PTR -11 Invalid null pointer error (parameter values are invalid NULL pointers) ALTIBASE_CS_INVALID_ATTR_TYPE -12 Invalid attribute error ALTIBASE_CS_INVALID_STATE -13 Invalid state error (The state of the handle is abnormal) ALTIBASE_CS_FILE_LOCK_INIT_ERROR -14 File lock initialization error ALTIBASE_CS_FILE_LOCK_NOT_EXIST -15 Nonexistent file lock error ALTIBASE_CS_FILE_LOCK_HOLD_ERROR -16 file lock hold error ALTIBASE_CS_FILE_LOCK_RELEASE_ERROR -17 file lock release error ALTIBASE_CS_FILE_LOCK_DESTROY_ERROR -18 file lock destruction error ALTIBASE_CS_PID_FILE_ALREADY_EXIST -19 Existing PID error ALTIBASE_CS_PID_FILE_SET_UNSUPPORTED -20 Unsupported PID file set error (The type of altibase_check_server_set_attr is PID) ALTIBASE_CS_NULL_HOMEPATH_ERROR -21 Null Hompath error (homepath is NULL and environmental variables do not exist) ALTIBASE_CS_LOAD_PROPERTIES_ERROR -22 Property loading error (DB Property loading failure) ALTIBASE_CS_SOCKET_OPEN_ERROR -23 socket open error ALTIBASE_CS_SOCKET_REUSE_ERROR -24 socket reuse error ALTIBASE_CS_SOCKET_CLOSE_ERROR -25 socket close error ALTIBASE_CS_SEND_SIG_FAILED -26 send signal failure (thread kill attempt fails) /* for checkServerPid.cpp */ ALTIBASE_CS_FOPEN_ERROR -27 file open error ALTIBASE_CS_FREAD_ERROR -28 file read error ALTIBASE_CS_FWRITE_ERROR -29 file write error ALTIBASE_CS_FCLOSE_ERROR -30 file close error ALTIBASE_CS_PID_REMOVE_ERROR -31 PID file remove error ALTIBASE_CS_PROCESS_KILL_ERROR -32 process kill error (Process kill fails) BUG-32391 The user cannot modify the precision of a geometry column having an R-tree index. Geometry, Spatial, Alter Table, Functional Error When a column having an R-tree index is altered, an error is raised because the alter statement uses a B-tree index. This problem can be reproduced in the following way: Create a table that has an R-tree index for a geometry column. ALTIBASE HDB Patchset Notes 5.5.1.2.0 13/27 Modify the precision of the geometry column having the R-tree index e.g. create table test( XID INTEGER primary key, EMD_CD VARCHAR(10) , EMD_KOR_NM VARCHAR(40), EMD_ENG_NM VARCHAR(40), XGEOMETRY GEOMETRY(17808) NOT NULL ) tablespace sys_tbs_disk_data; create index TL_SCCO_EMD_XGEOMETRY on test(xgeometry); iSQL> alter table test modify column( XGEOMETRY GEOMETRY(17848)); [ERR-311E0 : The estimated size of the index key exceeds the maximum limit.] Workaround: create table test( XID INTEGER primary key, EMD_CD VARCHAR(10) , EMD_KOR_NM VARCHAR(40), EMD_ENG_NM VARCHAR(40), XGEOMETRY GEOMETRY(17848) NOT NULL ) tablespace sys_tbs_disk_data; drop index sys.idx_rtree; alter table test modify column( XGEOMETRY GEOMETRY(17848)); create index idx_rtree on test (xgeometry);. 5.5.1.1.5 Fixed Bug Descriptions BUG-32303 The server shuts down abnormally when an encrypted value (echar, evarchar type) is inserted into an unencrypted column. Encryption, Abnormal Shutdown This problem can occur in the following way: When encrypted values are inserted into unencrypted columns e.g. alter system start security; drop table t1; create table t1( i0 integer, i1 char(3) , -- echar i2 varchar(3) -- evarchar ); insert into t1 values (2, echar'aaa', evarchar'bbb'); -- Crash!! BUG-32358 When a list or a subquery containing multiple columns is used in an OVER (PARTITION BY … ) clause, the server shuts down abnormally. Subquery OVER PARTITION BY, Abnormal Shutdown This problem can occur in the following way: create table T_OPRAT_EVL_MNBY_DSK(EVL_MM integer, EVL_SCORE integer,ename char(10)); insert into T_OPRAT_EVL_MNBY_DSK values(1,1,'rank1'); insert into T_OPRAT_EVL_MNBY_DSK values(2,2,'rank2'); insert into T_OPRAT_EVL_MNBY_DSK values(3,1,'rank3'); ALTIBASE HDB Patchset Notes 5.5.1.2.0 14/27 insert into T_OPRAT_EVL_MNBY_DSK values(4,4,'rank4'); select count(EVL_MM) over(partition by (EVL_MM,EVL_SCORE)) from T_OPRAT_EVL_MNBY_DSK; Workaround: operates normally when using multiple columns in an OVER (PARTITION BY) clause: SELECT COUNT(C1) OVER(PARTITION BY C2,C3) FROM T1; shuts down abnormally when using a list in an OVER (PARTITION BY) clause: SELECT COUNT(C1) OVER(PARTITION BY (C2,C3) ) FROM T1; operates normally when using a subquery comprising a single column in an OVER (PARTITION BY) clause: select count(c1) over(partition by (select c1 from t1 limit 1) ) from T1; shuts down abnormally when using a subquery comprising multiple columns in an OVER (PARTITION BY) clause: select count(c1) over(partition by (select c1,c2 from t1 limit 1) ) from T1; BUG-32378 Server shuts down abnormally during a DELETE operation and cannot be restarted when the value of NLS_COMP is 1. NLS_COMP Property, Abnormal Shutdown The NLS_COMP property should not be changed from its default value in ALTIBASE v.5.3.3 to v.5.5.1. This problem can occur in the following way: NLS_COMP = 1 ; DROP TABLE T1; CREATE TABLE T1 ( I1 VARCHAR( 32 ) ) TABLESPACE SYS_TBS_DISK_DATA; CREATE INDEX T1X ON T1 ( I1 ); AUTOCOMMIT OFF; INSERT INTO T1 VALUES( 'ㄱ' ); INSERT INTO T1 VALUES( 'ㄴ' ); INSERT INTO T1 VALUES( 'ㄷ' ); INSERT INTO T1 VALUES( 'ㄹ' ); INSERT INTO T1 VALUES( '가' ); INSERT INTO T1 VALUES( '나' ); INSERT INTO T1 VALUES( '다' ); INSERT INTO T1 VALUES( '라' ); select * from t1 order by i1; server kill; server start; select * from t1; select * from t1 order by i1; Workaround: Do not use the NLS_COMP property. If the value of the NLS_COMP property is changed to 1, existing indexes must be recreated. BUG-32379 When oraAdapter is executed, the prompt does not disappear. oraAdapter, Daemon Changes: It is possible to run oraAdapter as a daemon. BUG-32392 Incorrect query results can be returned when executing a long query that includes a stored procedure in a join condition or in a SELECT condition. Long Query, Incorrect Results This problem was introduced in 5.3.1.5 with the fix for bug-27291. This problem can occur in the following way: When a query has at least a few hundred logical/arithmetic operators and includes conditions ALTIBASE HDB Patchset Notes 5.5.1.2.0 15/27 such as join conditions and SELECT conditions with user-defined functions. e.g. CREATE OR REPLACE FUNCTION FUNC1(P1 CHAR(1), P2 CHAR(1)) RETURN CHAR(1) AS RET_VAL CHAR(1); BEGIN RET_VAL := P1; RETURN RET_VAL; END; / SELECT /*+NO_PLAN_CACHE*/ 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+ 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+ 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+ 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+ 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+ 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1 , 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+ 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+ 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+ 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+ 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+ 1 FROM dual a INNER JOIN dual b ON a.dummy = b.dummy AND func1('1', a.dummy) >= func1('2', b.dummy) WHERE (1 = 1) AND (2 = 2 AND 3 = 3); Workaround: Use the 'CNF' hint with such queries. BUG-32403 A Windriver-dependent server always shuts down abnormally. Windriver, Shared Memory, shmdt, shmctl, Abnormal Shutdown This problem can occur in the following way: 1. Shut down the server. 2. Check whether the server shut down abnormally in altibase_boot.log Changes: Added a routine to check shared memory before calling shmctl. BUG-32412 Cannot continue to install the oraAdapter GUI package without specifying a value for the ORACLE_SERVER_ALIAS property. ALTIBASE v.5.5.1 Installer, oraAdapter Changes: It is now possible to install the GUI without specifying a value for ORACLE_SERVER_ALIAS. BUG-32413 A memory allocation error occurs when the APRE precompiler is executed in AIX. ALTIBASE HDB Patchset Notes 5.5.1.2.0 16/27 APRE Precompiler, Memory Allocation Error A similar problem was reported in BUG-27511. The calloc() function raises a memory allocation error on the AIX platform. Changes: Hence, the malloc() and memset() functions should be used in place of the calloc() function." BUG-32415 The server shuts down abnormally when a bind variable in an indexed column and a column in an outer query table are used as the parameters for a BETWEEN condition. Query, Abnormal Shutdown A similar problem was reported in BUG-30401. This problem can be reproduced in the following way: The following 3 conditions must be satisfied. 1. A query must have a subquery. 2. The subquery must have a select condition on an indexed column using the BETWEEN operator. 3. One of the arguments of the BETWEEN operator must be a bind variable/SYSDATE, and the other one must be a query of the outer table. e.g. CREATE TABLE t1(i1 CHAR(8)); INSERT INTO t1 VALUES ('20100801'); CREATE INDEX idx_t11 ON t1(i1); CREATE TABLE t2(i1 CHAR(8)); INSERT INTO t2 VALUES ('20100802'); SELECT * FROM t2 WHERE EXISTS (SELECT * FROM t1 WHERE i1 BETWEEN TO_CHAR(SYSDATE, 'YYYYMMDD') AND t2.i1); or VAR v1 DATE; PREPARE SELECT * FROM t2 WHERE EXISTS (SELECT * FROM t1 WHERE i1 BETWEEN TO_CHAR(:v1, 'YYYYMMDD') AND t2.i1); Workaround: This problem can be avoided by using a pair of comparison operators instead of the BETWEEN operator. The above query can be transformed as follows: SELECT * FROM t2 WHERE EXISTS (SELECT * FROM t1 WHERE (i1 >= TO_CHAR(SYSDATE, 'YYYYMMDD') AND i1 <= t2.i1)); BUG-32419 'Installer GUI mode' cannot display long strings correctly. ALTIBASE v.5.5.1 Installer, This problem was introduced with the fix for BUG-32297. Workaround: Run the ALTIBASE 551 HDB installer in command mode. Changes: The guide messages for user-specified properties need to be shortened in Altibase 5.5.1 Installer for Unix compatibility. Current Message # Maximum sixe of memory databse - Minimum value : 16M (Unit: [K]ilo, [M]ega, [G]iga bytes) Changed Message # Maximum sixe of memory databse - MIN value : 16M (K,M,G) Current Message # Buffer area size for caching disk-based database pages - Minimum value : 1M (Unit: [K]ilo, [M]ega, [G]iga bytes) ALTIBASE HDB Patchset Notes 5.5.1.2.0 17/27 Changed Message # Buffer area size for caching disk-based database pages - MIN value : 16M (K,M,G) BUG-32425 When prepared statements are executed several times using a command object, only the first execution is successful. OLEDB, DBTYPE_VARIANT, Incorrect Results Type information must be reset after execution when the type is DBTYPE_VARIANT, because a second query is executed improperly when a command object is executed repeatedly in an OLEDB environment. This problem can occur in the following way: Execute a prepared statement several times using a command object. Changes: Revert wtype to DBTYPE_VARIANT after parameter binding. BUG-32432 grep "--daemon" is not working in oaUtility. oraAdapter, oaUtility Changes: Change --daemon to \-\-daemon. BUG-32436 The selectivity of condition clauses based on indexed columns and constants or bind variables may be estimated incorrectly. Optimizer, Inefficient Execution Plan, Testcase Fail This problem was introduced in BUG-32415. This problem can occur in the following way: 1. One of the following operators must be used: >, >=, <, <= 2. The first argument must be a constant or a bind variable. 3. The second argument must be an indexed column. e.g. CREATE TABLE t1(i1 INTEGER); INSERT INTO t1 SELECT LEVEL FROM dual CONNECT BY LEVEL <= 10; CREATE INDEX t1_idx ON t1(i1); ALTER SESSION SET EXPLAIN PLAN = ON; ALTER SYSTEM SET TRCLOG_EXPLAIN_GRAPH = 1; SELECT * FROM t1 WHERE 5 5;. 5.5.1.1.6 Fixed Bug Descriptions BUG-31851 When a storage manager error (such as a tablespace full error) occurs in a replication receiver running in EAGER mode, the Receiver and server terminate ALTIBASE HDB Patchset Notes 5.5.1.2.0 18/27 abnormally. Storage Manager, Eager Replication, Abnormal Termination This problem can occur in the following way: When a tablespace is full on the standby server. BUG-32442 apre.lib must be included in pkg.map for Windows. pkg.map, APRE BUG-32443 Performance is reduced because prepare is performed for every execution. OLEDB, Efficiency Changes: Prepare should be performed only when the statement has changed. BUG-32454 A link warning occurs when compiling APRE in Windows. APRE, ACP_CFG_DL_STATIC Compile Option, Link Warning A link warning occurs in Windows when compiling APRE including Alticore because of the use of a static library while declaring the ""__declspec(dllexport)"" to create the dll library in Alticore. This problem can occur in the following way: When APRE is compiled on the Windows platform. Changes: An ACP_CFG_DL_STATIC option should be added to the makefile to avoid this warning. 5.5.1.1.7 Fixed Bug Descriptions BUG-32286 Preventing the server from stopping the security module. Security Column, Functional Error This problem can occur in the following way: When a DROP USER CASCADE statement is executed, the corresponding SYS_ENCRYPTED_COLUMNS_ meta information is not deleted. e.g. Security columns that belong to the user are not deleted. alter system start security; create user user1 identified by user1; grant all privileges to user1; connect user1/user1; create table t1( i1 char(10000) encrypt using 'POLICY' ) ; drop user user1 cascade; alter system stop security; -- Stop Fail BUG-32313 A performance reduction can occur due to the execution of a full scan when the values of DRDB index cardinality converge on 0. DRDB index, Inaccurate Cardinality, Full scan, Performance Reduce ALTIBASE HDB Patchset Notes 5.5.1.2.0 19/27 This problem can occur in the following way: When a DELETE operation pertains to a key that spans multiple pages, the service thread doesn't access the previous page. CREATE TABLE T1 ( I1 CHAR(3000), I2 INTEGER ) TABLESPACE SYS_TBS_DISK_DATA;; CREATE INDEX T1X ON T1 ( I1 ); INSERT INTO T1 VALUES( 1, 1 ); INSERT INTO T1 VALUES( 1, 2 ); INSERT INTO T1 VALUES( 1, 3 ); INSERT INTO T1 SELECT ROWNUM+10,0 FROM DUAL CONNECT BY LEVEL <= 1000; SELECT INDEX_NAME, CARDINALITY FROM X$DISK_BTREE_STAT WHERE INDEX_NAME='T1X'; CREATE OR REPLACE PROCEDURE DECCAR( ) AS BEGIN FOR I IN 1 .. 1000 LOOP DELETE FROM T1 WHERE I2 = 3; INSERT INTO T1 VALUES( 1, 3 ); END LOOP; END; / EXEC DECCAR(); SELECT INDEX_NAME, CARDINALITY FROM X$DISK_BTREE_STAT WHERE INDEX_NAME='T1X'; SELECT COUNT(DISTINCT I1 ) FROM T1; The problem can also occur in the following way: iSQL> DROP TABLE T1; iSQL> CREATE TABLE T1( I1 INTEGER ) TABLESPACE SYS_TBS_DISK_DATA;; iSQL> CREATE INDEX T1X ON T1( I1 ); iSQL> CREATE OR REPLACE PROCEDURE INS_T1() AS BEGIN FOR I IN 1 .. 100 LOOP INSERT INTO T1 VALUES( I ); END LOOP; END; / iSQL> CREATE OR REPLACE PROCEDURE DECCAR() AS BEGIN FOR I IN 1 .. 100 LOOP DELETE FROM T1 WHERE I1 = 1; INSERT INTO T1 VALUES( 1 ); END LOOP; END; / iSQL> exec INS_T1(); iSQL> SELECT INDEX_NAME, CARDINALITY FROM X$DISK_BTREE_STAT WHERE INDEX_NAME='T1X'; INDEX_NAME CARDINALITY ------------------------------------------------------------------ T1X 100 ALTIBASE HDB Patchset Notes 5.5.1.2.0 20/27 1 row selected. iSQL> SELECT COUNT(DISTINCT I1) FROM T1; COUNT(DISTINCT I1) ----------------------- 100 iSQL> EXEC DECCAR(); iSQL> SELECT INDEX_NAME, CARDINALITY FROM X$DISK_BTREE_STAT WHERE INDEX_NAME='T1X'; INDEX_NAME CARDINALITY ------------------------------------------------------------------ T1X 0 iSQL> SELECT COUNT(DISTINCT I1) FROM T1; COUNT(DISTINCT I1) ----------------------- 100 BUG-32439 Parallel sync can fail for a table that includes one or more LOB columns. Parallel sync, LOB column Parallel sync can be failed for the table including a LOB columns because many sync children threads use one transaction of the service thread without synchronization. Changes: In 5.1.5, 5.3.3 and 5.3.5, multiple synchronized children could use the same transaction. In 5.5.1, 5.7.1, and the trunk, each child must use its own transaction. BUG-32462 The release notes and Installation Guide for the ALTIBASE HDB 5.5.1 package have been updated. (oraAdapter) ALTIBASE v.5.5.1 Installer, Release Notes, oraAdapter Changes: [Release note : oraAdapter information added ] ALTIBASE_HDB_5_5_1_ReleaseNotes_v1.2.pdf -> ALTIBASE_HDB_5_5_1_ReleaseNotes_v1.3.pdf [Installation guide : Installer English script changed ] ALTIBASE_Package_Installer_User_Guide.pdf -> ALTIBASE_HDB_5_5_1_InstallerUserGuide_v1.2.pdf BUG-32504 pkg.map : dumpdp is not included in the Linux package. pkg.map, dumpdp Changes: 'dumpdp' has been added to pkg.map for linux. 5.5.1.1.8 Fixed Bug Descriptions BUG-32398 If a fetchTimeout occurs when connecting via IPC, the session on the server side is not terminated. IPC, Server side session not terminated, Limited Memory ALTIBASE HDB Patchset Notes 5.5.1.2.0 21/27 This problem was introduced with the fixes for BUG-27990(A4) and BUG -27162(A5). This problem can occur in the following way: 1. Open Cursor1 2. select * from T1 3. Open Cursor2 4. select * from T2 FetchTimeout occurs four times in the process. If client doesn't call SQLDisconnect() or does not exit, the session will not be terminated on the server side. Changes: The session now terminates on the server side if a fetchTimeout occurs. BUG-32475 Concurrency problems in the replication log buffer can cause the Sender to obtain incorrect SNs and log records, resulting in abnormal termination. Replication Log Buffer, Abnormal Termination This problem can occur in the following way: The sender gets incorrect SNs and log records in the replication log buffer due to concurrency problems. It can also occur when a service thread writes a new log record to the last part of the replication log buffer. This problem was introduced with the fix for BUG-22098. Workaround: REPLICATION_LOG_BUFFER_SIZE = 0 BUG-32512 The 'COMMENT' keyword should be added to the available column name list in Apre for compatibility with iSQL. APRE, Compatibility with iSQL BUG-32514 A CAPI sample compile error occurs in AIX5.3, and a segmentation fault error occurs in SOLARIS. CAPI, Compile Error, Segmentation Fault Error A CAPI sample compile error (Cannot find or open library file: -l alticapi_sl) occurs in ALTIBASE HDB v.5.5.1 on AIX5.3, and a segmentation fault error occurs in SOLARIS SPARC2.8, SOLARIS i86PC 2.10 when the 'demo_meta1' binary is executed after the '.../sample/CAPI' is built. This problem can occur in the following way: aix5.3:~/work/altidev4/ut/sample/CAPI % make xlC_r -O2 -qinline -q64 -bmaxdata:0xFFFFFFFFFFFFFFFF -L. - L/qa_home/pgm_pkg/work/altidev4/altibase_home/lib -o demo_rtl demo_ex2.o -lpthreads - lhm -lalticapi_sl ld: 0706-006 Cannot find or open library file: -l alticapi_sl ld:open(): No such file or directory make: *** [demo_rtl] Error 255 BUG-32521 Warning messages that exceed 4096 bytes are truncated in JDBC in order to avoid buffer overflow errors. Message Error, JDBC This problem can occur in the following way: Run psm using println to print a string that is over 4096 bytes long in a JDBC environment. Changes: Truncate the string if the length exceeds 4096 bytes. ALTIBASE HDB Patchset Notes 5.5.1.2.0 22/27 5.5.1.1.9 Fixed Bug Descriptions BUG-32520 When Failover (STF) occurs in JDBC, the error message "Fail-Over Completed" is always displayed regardless of whether a failover error actually occurred STF, Fail-Over, Error Message Changes: The following error message has been added. Fail-Over Completed (08S01 : Communication link failure) BUG-32534 The polling time of a shared service thread can become 0, resulting in abnormally high CPU usage. Shared Service Thread , abnormally High CPU Usage The polling time of a shared service thread can become 0 when a service thread that has been transformed to a dedicated service thread is reused, resulting in abnormally high CPU usage. A similar problem was reported in BUG- 30656. This problem can occur in the following way: 1. Create a situation in which a queue is empty. 2. Some client executes a dequeue statement for the queue. At that time, the shared service thread that the client was assigned to will be transformed into a dedicated service thread. 3. The client disconnects from ALTIBASE. 4. The dedicated service thread is transformed into a shared service thread and is reused. 5. The ready task count of the shared service thread eventually became zero. 6. The service thread uses the CPU excessively because the polling time of the service thread is zero. Workaround: The QUEUE_MAX_ENQ_WAIT_TIME property should not be set to a multiple of 1,000,000. BUG-32537 An error stating that the external symbol '__HUGE' could not be found occurs in Windows when creating an MFC dll in Visual Studio 2010. MFC extension dll, Visual Studio, unable to make error 5.5.1.1.10 Fixed Bug Descriptions BUG-32528 Additional debugging information is required to help determine the cause of invalidation of a disk page header BCB Pointer. Disk Page Header, Debugging Information, Memory Scratching ALTIBASE HDB Patchset Notes 5.5.1.2.0 23/27 5.5.1.1.11 Fixed Bug Descriptions BUG-32544 An ALTER TABLE operation in an MMDB can generate an invalid NULL row, resulting in abnormal server shutdown, startup failure, or loss of index uniqueness. MMDB ALTER TABLE, abnormal server shutdown, Hang A similar problem was reported in BUG-30457. This problem can occur in the following way: If an ALTER TABLE operation fails in an MMDB, the transaction performs an UNDO operation. This undo operation generates the invalid null row. e.g. CREATE TABLE T1 ( I1 FLOAT PRIMARY KEY ); INSERT INTO T1 SELECT ROWNUM FROM DUAL CONNECT BY LEVEL <= 1000; INSERT INTO T1 VALUES( 1.1 ); ALTER TABLE T1 MODIFY COLUMN (I1 INTEGER TOLERATE DATA LOSS); SELECT * FROM D$MEM_TABLE_RECORD( T1 ) limit 5; Workaround: Recreate the table. BUG-32548 Performance of the MMDB ager is slower in v.5.5.1 than in v.4.3.9 because mutex contention has increased. Mutex Lock Contention, Performance of MMDB Ager Workaround: altibase.properties: MUTEX_TYPE = 1 LOGICAL_AGER_COUNT_ = 1 Changes: The MMDB Logical Ager has been optimized to restore the performance of the MMDB Ager. Modify the critical section area to relieve the contention. 5.5.1.2.0 Fixed Bug Descriptions BUG-32474 LOB locators is not freed in the CLI when not being used, leading to memory full errors. LOB locators, CLI, Memory Full Errors LOB locators should be freed in the CLI when not being used in order to prevent memory full errors. A similar problem was reported in BUG-31821. This problem can occur in the following way: ALTIBASE HDB Patchset Notes 5.5.1.2.0 24/27 Perform a SELECT operation on a LOB column without fetching any results. Changes: Unread LOB locators are now freed when fetching subsequent cursors or closing cursors. BUG-32507 Unable to fetch LOB column when OOM (Out of Memory) error occurs. Therefore, memory allocation always fails on 32-bit machines. LOB column, LOB Locator, OOM (Out of Memory) errors This problem can occur in the following way: select * from T1 (T1 has a lob column); Workaround: Change the LOB type column to a VARCHAR type column. Changes: To prevent OOM (Out of Memory) errors when a LOB column is fetched, a LOB Locator must be used instead of binding the data to the existing column. BUG-32543 Attempts to retrieve BIT, VARBIT, and NIBBLE type data from small columns can fail BIT, VARBIT, NIBBLE Attempts to retrieve BIT, VARBIT, and NIBBLE type data from small columns can fail because additional information about their length that is written upon conversion to binary data types is not considered. This problem can occur in the following ways: When attempting to read BIT (or VARBIT) data from a column whose size < 5 When attempting to read NIBBLE data from a column whose size < 2 Changes: The column length information is now updated when obtaining data from BIT, VARBIT, and NIBBLE columns. BUG-32564 A scale error occurs when data are transferred from Oracle to Altibase using JDBC Scale Error, Transfer Data from Oracle to Altibase A scale error occurs when data are transferred from Oracle to Altibase using JDBC, because the scale of the transferred data exceeds the default JDBC scale value (20). BUG-32566 An attempt to synchronize a CLOB type column between master and slave nodes using the Audit utility can fail. Synchronize, CLOB Column, a server 'audit sync execute fail ', 'replication conflict', 'core in diff, sync' or 'incompatible with 5.3.3.43' error. An attempt to synchronize a CLOB type column between master and slave nodes using the Audit utility can fail, raising a server 'audit sync execute fail ', 'replication conflict', 'core in diff, sync' or 'incompatible with 5.3.3.43' error. This problem can occur in the following way: Step 1. Write data to one node. Step 2. Perform sync using Audit Step 3. SELECT data from the other node BUG-32569 Audit utility truncates a string containing a NULL character when synchronizing such a string. Audit Utility, Synchronize The Audit utility truncates a string containing a NULL character when synchronizing such a string, because it handles a NULL character in a string as signifying the end of the string. ALTIBASE HDB Patchset Notes 5.5.1.2.0 25/27 This problem can occur in the following way: Insert a string starting with a NULL character into a table (as the primary key) and sync using Audit. Changes: Audit has been modified to check the length of the string (including NULL characters) and use that length to process strings instead of treating all strings as NTS. BUG-32571 Test cases failed because the scale of the NUMERIC type was set to 128. Scale of NUMERIC, Testcase Fail The scale of the NUMERIC type is set to 20 rather than 128, preventing the result of execution of a procedure from being returned, even upon repeated execution. This problem was introduced with the fix for BUG-32564. BUG-32583 The ABDatabaseMetaData.getCatalogs() method returns incorrect results. Query, Method, Incorrect Results. This problem can occur in the following way: Change the parameter value of getCatalogs() in SELECT statements. Changes: Queries must be modified so that the newly added ABDatabaseMetaData.getCatalogs() method returns accurate information. BUG-32584 When a lock is released in Apre, an assertion violation error occurs. APRE, Assertion Violation Error A similar problem was reported in BUG-30739. Changes: BUG-30739 was not fixed in Altibase 5.3.5, and should be addressed in 5.5.1. BUG-32585 If geometry data are input using acs library in the release build, Spatial Operations don't work well. MBR calculations in release mode are not performed properly. Spatial Operation, MBR calculation, Does not work properly Changes: IDE_DASSERT does not function in the release, resulting in data errors when INSERT statements are executed. Therefore, IDE_DASSERT must be removed from ulsCreateObj.cpp. BUG-32604 pkgverify.sh(bat) must be removed from pkg.map (551/571/trunk) pkg.map, pkgverify.sh(bat) pkgverify.sh(bat) is not included in the 5.5.1 packages, but remains only in pkg.map. BUG-32610 "SELECT SYSDATE - (SYSDATE - 1) from dual" query returns different output formats in iSQL and JDBC. Query, isql, JDBC, Incorrect Results Change the toString method in mtdInterval.java This problem can occur in the following way: SELECT SYSDATE - (SYSDATE - 1) from dual result of isql : 1 result of JDBC : 86400:0 ALTIBASE HDB Patchset Notes 5.5.1.2.0 26/27 BUG-32611 Trash data are included after a NULL-terminated string. OLE DB, Incorrect Results The OLE DB Provider has been using the size of allocated parameter buffer instead of the actual length of the string, and this causes trash data to be include after a NULL-terminated string. This problem can occur in the following way: Delphi passes string parameters with uncleared memory, so applications developed with Delphi can cause the same problem with unfixed OLE DB providers. C# doesn't have this problem, so it was hard to reproduce with C# and .NET. 1. create file C:\PBT\altibase.udl 2. create table t1 (i1 int, c1 varchar(20)) 3. insert (1,'one'), (2,'two'), (3,'three'), (10, 'ten') 4. run the Delphi program. Changes: Call wcslen for a BSTR parameter to get its size. BUG-32612 A page list is destroyed in a disk temporary table when a run is created for a merge, because the same page is allocated multiple times. Disk Temporary Table, Hang This problem can occur only in TSM. This problem was introduced in BUG-32586. This problem can occur in the following way: create disk temporary tablespace temp tempfile 'temp.dbf' size 100M extentsize 10m; CREATE USER tester IDENTIFIED BY tester TEMPORARY TABLESPACE TEMP ACCESS sys_tbs_memory OFF; CREATE TABLE T0 ( data VARCHAR( 4000 ) ); insert into T0 values ( rpad( '00', 3000, 'b' ) ); insert into T0 values ( rpad( '01', 3000, 'b' ) ); insert into T0 values ( rpad( '50', 1000, 'b' ) ); insert into T0 values ( rpad( '02', 3000, 'b' ) ); insert into T0 values ( rpad( '03', 3000, 'b' ) ); insert into T0 values ( rpad( '51', 1000, 'b' ) ); insert into T0 values ( rpad( '04', 3000, 'b' ) ); insert into T0 values ( rpad( '05', 3000, 'b' ) ); insert into T0 values ( rpad( '52', 1000, 'b' ) ); insert into T0 values ( rpad( '06', 3000, 'b' ) ); insert into T0 values ( rpad( '07', 3000, 'b' ) ); insert into T0 values ( rpad( '53', 1000, 'b' ) ); insert into T0 values ( rpad( '08', 3000, 'b' ) ); insert into T0 values ( rpad( '09', 3000, 'b' ) ); insert into T0 values ( rpad( '54', 1000, 'b' ) ); insert into T0 values ( rpad( '10', 3000, 'b' ) ); insert into T0 values ( rpad( '11', 3000, 'b' ) ); insert into T0 values ( rpad( '55', 1000, 'b' ) ); select /*+ temp_tbs_disk */lengthb(data) from t0 order by data ; [ERR-11123 : The tablespace does not have enough free space ( TBS Name :TEMP ).] Workaround: create disk temporary tablespace temp tempfile 'temp.dbf' size 100M SEGMENT MANAGEMENT MANUAL extentsize 10m; BUG-32631 The stream interface must be able to handle LOB data. ALTIBASE HDB Patchset Notes 5.5.1.2.0 27/27 Stream Interface, LOB This problem was introduced in BUG-32507. BUG-32633 The log indicating the end of a log file can cause data consistency problems. Replication Log Buffer, Data Consistency Problem This problem was introduced with the fix for BUG-29837. This problem can occur in the following way: REPLICATION_LOG_BUFFER_SIZE is not zero. Workaround: REPLICATION_LOG_BUFFER_SIZE = 0 BUG-32647 Redundant partition keys may be created when downloading table information via AEXPORT. AEXPORT, Partition Key Column, Object_type This problem can occur in the following way: 1. Create a partition table whose columns have the same partition_obj_id 2. Run aexport 3. Check SYS_CRT_TBL.sql BUG-32656 A JDBC driver exception occurs when the client uses the LONGVARCHAR data type. LONGVARCHAR, SQLException, JDBC driver This problem can occur in the following way: Perform type matching using the setSQLType method. ERROR MESSAGE : Does not support the given type. java.sql.SQLException: Does not support the given type. BUG-32658 Some values in VARCHAR or CHAR type columns larger than 255 may be abnormal. Varchar, Char, Incorrect Values

ALTIBASE HDB 6.5.1.8.6 Patch Notes ALTIBASE HDB Patch Notes 6.5.1.8.6 2 / 11 목차 BUG-48515 ACCESS_LIST 프로퍼티에서 동일 IP의 세션 수 제한 기능을 제공합니다. ....................................................................................... 3 BUG-48618 iSQL 커맨드 라인 옵션 -KEEP_SYSDBA 를 추가합니다. .............. 5 BUG-49060 altibase_ipc.log 파일의 권한을 -rw-r--r-- 으로 변경합니다. ....... 6 BUG-49062 조회 트랜잭션에서 시퀀스 사용 시 UTRANS_TIMEOUT 이 발생하며 세션이 종료됩니다. ................................................................ 7 BUG-49071 이중화 객체에 이중화 대상 추가 시 USER 이름이 잘못된 경우 알맞지 않은 에러 메시지가 발생합니다. .................................................. 8 BUG-49077 트랜잭션 고립화 수준(isolation level)이 REPEATABLE READ 인 경우 COUNT(*) 수행 시 ERR-0109E : Internal server error. 에러가 발생합니다. ....................................................................................................... 9 BUG-49087 JDBC 커넥션 객체를 close 할 때 예외가 발생한 경우 socket fd(file descriptor)가 정리되지 않고 남아있는 현상이 있습니다. ................. 10 BUG-49095 Materialized view에 _PROWID 예약어를 사용한 경우 Altibase 서버가 비정상 종료합니다. ................................................................. 11 ALTIBASE HDB Patch Notes 6.5.1.8.6 2 / 11 ALTIBASE HDB Patch Notes 6.5.1.8.6 3 / 11 BUG-48515 ACCESS_LIST 프로퍼티에서 동일 IP의 세션 수 제한 기능을 제공합니다. Module mm Category Functionality 재현빈도 Always Reproducing Conditions 재현절차 N/A 수행결과 N/A 예상결과 N/A 설명 동일 IP 의 세션 수를 제한하는 기능을 제공하기 위해 ACCESS_LIST 프로퍼티에 limit 항목을 추가합니다. ACCESS_LIST = operation, address, mask, [limit] address 에서 접속한 세션 수가 limit을 초과한 경우 신규 접속을 허용하지 않습니다. 이 경우, Altibase 클라이언트 측에서는 ERR-91015 : Communication failure. 에러가 발생하며 접속이 실패하고 Altibase 서버 측에서는 altibase_boot.log에 아래와 같은 메시지가 발생합니다. ERR-410f0(errno=0) New connection try exceeds ACL limit: ( IP : 192.168.1.203, ACL: 192.168.1.203, Limit : 2, Connected : 2 ) Dispatcher callback failed 변경사항 Performance View V$ACCESS_LIST 변경 LIMIT, CONNECTED 컬럼이 추가되었습니다. LIMIT ACCESS_LIST에 명시된 접속 가능한 IP 주소 영역에서 허용되는 최대 접속 세션 개수. CONNECTED ACCESS_LIST에 해당하는 현재 접속된 세션 개수 보다 자세한 설명은 GeneralReference 매뉴얼을 참고하세요. Property ACCESS_LIST 변경 limit 항목이 추가되었습니다. ALTIBASE HDB Patch Notes 6.5.1.8.6 4 / 11 ACCESS_LIST = operation, address, mask, [limit] limit 은 선택 입력 항목으로 ACCESS_LIST에 명시된 접속 가능한 IP 주소 영역에서 허용되는 최대 접속 세션 개수를 지정합니다. 보다 자세한 설명은 GeneralReference 매뉴얼을 참고해주세요. Compile Option N/A Error Code 설정한 세션 수를 초과하여 접속을 시도할 경우 아래와 같은 에러 메시지가 발생합니다. mmERR_ABORT_IP_ACL_CONNECT_OVER = New connection try exceeds ACL limit: ( IP : <0%s>, ACL: <1%s>, Limit : <2%d>, Connected : <3%d> ) # *Cause: New connection try aborted because it exceeds access control list (ACL) limit. # *Action: Change the limit value of the ACCESS_LIST. Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.8.6 5 / 11 BUG-48618 iSQL 커맨드 라인 옵션 -KEEP_SYSDBA 를 추가합니다. Module ux-isql Category Usability 재현빈도 Always Reproducing Conditions 재현절차 N/A 수행결과 N/A 예상결과 N/A 설명 iSQL에서 sysdba 모드로 Altibase 서버에 접속 시 관리자 모드를 유지하기 위한 -KEEP_SYSDBA 옵션을 추가합니다. sysdba 모드에서 startup service 를 수행할 때, -KEEP_SYSDBA 옵션을 사용하지 않으면 관리자 모드에서 일반 사용자 모드로 변경되고 -KEEP_SYSDBA 옵션을 사용하면 관리자 모드가 유지됩니다. 이 버그를 반영하려면 iSQL 을 패치 해야 합니다. 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.8.6 6 / 11 BUG-49060 altibase_ipc.log 파일의 권한을 -rw-r--r-- 으로 변경합니다. Module cm-ipc Category Maintainability 재현빈도 Always Reproducing Conditions 재현절차 N/A 수행결과 N/A 예상결과 N/A 설명 데이터베이스 보안 강화를 위해 $ALTIBASE_HOME/trc/altibase_ipc.log 파일의 권한을 rw-rw- rw- 에서 -rw-r--r-- 으로 변경합니다. 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.8.6 7 / 11 BUG-49062 조회 트랜잭션에서 시퀀스 사용 시 UTRANS_TIMEOUT 이 발생하며 세션이 종료됩니다. Module sm Category Functional Error 재현빈도 Rare Reproducing Conditions 재현절차 N/A 수행결과 N/A 예상결과 N/A 설명 시퀀스 객체 생성/변경에서 CACHE 절을 사용한 경우 시퀀스 사용 시 내부적으로 UPDATE 문을 수행합니다. 이로 인해 사용자가 수행한 조회 트랜잭션이 변경 트랜잭션으로 변경되어 UTRANS_TIMEOUT 에 걸려 세션이 종료하는 현상입니다. 이 현상을 개선하기 위해 __SEQ_CACHE_UPT_TX_ENABLE 프로퍼티를 추가합니다. __SEQ_CACHE_UPT_TX_ENABLE = 0 은 기존과 같이 사용자의 조회 트랜잭션이 변경 트랜잭션으로 바뀌고 __SEQ_CACHE_UPT_TX_ENABLE = 1 은 별도 트랜잭션으로 관리하여 사용자 트랜잭션에 영향을 주지 않습니다. 변경사항 Performance View N/A Property __SEQ_CACHE_UPT_TX_ENABLE 프로퍼티 추가 설명 시퀀스 값 캐시 과정에서 내부적으로 수행하는 UPDATE 문에 대한 처리 동작을 제어한다. 0 : 별도의 트랜잭션으로 관리하지 않는다. 사용자 트랜잭션에 영향을 준다. 1 : 별도의 트랜잭션으로 관리한다. 사용자 트랜잭션에 영향을 주지 않는다.기본값 : 0 속성 : 읽기 전용, 비공개 Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.8.6 8 / 11 BUG-49071 이중화 객체에 이중화 대상 추가 시 USER 이름이 잘못된 경우 알맞지 않은 에러 메시지가 발생합니다. Module rp Category Message Error 재현빈도 Always Reproducing Conditions 재현절차 CREATE TABLE T1 (I1 INTEGER PRIMARY KEY, I2 INTEGER); CREATE TABLE T2 (I1 INTEGER, I2 INTEGER); ALTER TABLE T2 ADD CONSTRAINT PK_T2 PRIMARY KEY (I1, I2); CREATE REPLICATION REP1 WITH '127.0.0.1', 27172 FROM SYS.T1 TO SYS.T1; ALTER REPLICATION REP1 ADD TABLE FROM SYS.T2 TO SCOTT.T2; ALTER REPLICATION REP1 START; 수행결과 ERR-6100D : [Sender] Failed to handshake with the peer server (The primary key column count of the replicated table does not match [T1(1):T2(2)].) 예상결과 ERR-6100D : [Sender] Failed to handshake with the peer server (The user name of the replicated table's owner does not match [T2(SYS):T2(SCOTT)].) 설명 이중화 객체에 이중화 대상 테이블 추가 시 USER 이름이 잘못된 경우 The primary key column count of the replicated table does not match 와 같이 적합하지 않은 에러 메시지가 발생하여 The user name of the replicated table's owner does not match 메시지로 수정하였습니다. 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.8.6 9 / 11 BUG-49077 트랜잭션 고립화 수준(isolation level)이 REPEATABLE READ 인 경우 COUNT(*) 수행 시 ERR-0109E : Internal server error. 에러가 발생합니다. Module qp Category Functional Error 재현빈도 Always Reproducing Conditions 재현절차 CREATE TABLE BUG_49077 ( IDX INTEGER , PARENT_IDX INTEGER ) TABLESPACE SYS_TBS_DISK_DATA; INSERT INTO BUG_49077 VALUES( 1, 0 ); INSERT INTO BUG_49077 VALUES( 1, 0 ); INSERT INTO BUG_49077 VALUES( 1, 0 ); INSERT INTO BUG_49077 VALUES( 1, 0 ); INSERT INTO BUG_49077 VALUES( 1, 0 ); AUTOCOMMIT OFF; SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; SELECT COUNT ( * ) FROM BUG_49077 WHERE IDX = 1; COMMIT; AUTOCOMMIT ON; 수행결과 iSQL> SELECT COUNT ( * ) FROM BUG_49077 WHERE IDX = 1; [ERR-0109E : Internal server error.] 예상결과 iSQL> SELECT COUNT ( * ) FROM BUG_49077 WHERE IDX = 1; COUNT ----------------------- 5 1 row selected. 설명 트랜잭션 고립화 수준(isolation level)이 REPEATABLE READ 인 경우 COUNT(*) 수행 시 ERR-0109E : Internal server error. 에러가 발생하는 현상을 수정합니다. 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.8.6 10 / 11 BUG-49087 JDBC 커넥션 객체를 close 할 때 예외가 발생한 경우 socket fd(file descriptor)가 정리되지 않고 남아있는 현상이 있습니다. Module mm-jdbc Category Functional Error 재현빈도 Always Reproducing Conditions 재현절차 AltibaseConnection sConn = (AltibaseConnection)getConnection("21165"); // 최초 접속 성공 try { sConn.close(); // close 도중 예외 발생 } catch (SQLException aEx) { System.out.println(aEx.getMessage()); } CmChannel sChannel = sConn.channel(); System.out.println("Socket FD ===>" + sChannel.getSocketFD()); // socket이 정리되지 않고 socket fd가 남아있음 수행결과 Communication link failure: There was no response from the server, and the channel has reached end-of-stream. Socket FD ===>42 예상결과 Communication link failure: There was no response from the server, and the channel has reached end-of-stream. Exception in thread "main" java.sql.SQLException: Connection already closed. 설명 JDBC 커넥션 객체를 close 할 때 예외가 발생한 경우 socket fd(file descriptor)가 정리되지 않고 남아있는 현상을 수정하였습니다. 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.8.6 11 / 11 BUG-49095 Materialized view에 _PROWID 예약어를 사용한 경우 Altibase 서버가 비정상 종료합니다. Module qp-dml-pvo Category Fatal 재현빈도 Always Reproducing Conditions 재현절차 CREATE TABLE T1 (I1 INT, I2 INT); WITH W3 AS ( SELECT /*+ */ _PROWID AS i2 FROM T1 ) SELECT E.I2, F.I2 FROM W3 E, W3 F; 수행결과 ERR-91015 : Communication failure. 발생하며 Altibase 서버가 비정상 종료하거나 ERR-31455 : Failed to work because an internal exception occurred from an OS.[Contact Altibase's Support Center] 에러 메시지가 발생합니다. 예상결과 _PROWID 예약어를 사용할 수 없는 문장이므로 에러 메시지를 출력해야 합니다. ERR-31385 : _PROWID is not supported. 설명 Materialized view에서 _PROWID 예약어는 사용할 수 없으므로 ERR- 31385 : _PROWID is not supported. 에러 메시지가 발생하도록 수정하였습니다. 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround NO_MATERIALIZE 힌트를 사용하여 Altibase 서버 비정상 종료 현상을 회피할 수 있습니다. WITH W3 AS ( SELECT /*+ NO_MATERIALIZE */ _PROWID AS i2 FROM T1 ) SELECT E.I2, F.I2 FROM W3 E, W3 F; I2 I2 --------------------------------------------- 592710729729 592710729729 1 row selected.