altibase administrator's manualsupport.altibase.com/kr/download?attachpath=/altra/... · z 제...

ALTIBASE Administration

Administrators Manual

Release 4.3.9.0

1-2 Administrator’s Manual

------------------------------------------------ ALTIBASE Administration Administrators Manual

Release 4.3.9.0

Copyright ⓒ 2001 ALTIBASE Corporation.

10F DaerungPostTowerⅡ 182-13

Guro-dong, Guro-gu, Seoul,152-847 Korea

Tel: +82-2-2082-1114 Fax: +82-2-2082-1099

All Rights Reserved.

본 문서의 저작권은 ㈜알티베이스에 있습니다. 당사의 동의 없이 무단으로 복제

또는 전용할 수 없습니다.

㈜알티베이스

152-847

서울시 구로구 구로동 182-13 대륭포스트타워Ⅱ 10 층

전화: 02-2082-1114 팩스: 02-2082-1099

e-mail: [email protected]

homepage: http://www.altibase.com

mailto:[email protected]

http://www.altibase.com/

목차 i

목 차

서문............................................................................................................... i 이 매뉴얼에 대하여....................................................................................................... ii

Part I .................................................................................................. 1

1. 데이터베이스 생성.................................................................................. 3

데이터베이스 생성..........................................................................................................4

2. 알티베이스 구동 및 종료...................................................................... 11

알티베이스의 구동........................................................................................................12

알티베이스의 종료........................................................................................................14

3. 데이터 딕셔너리 ................................................................................... 15

메타 테이블....................................................................................................................16 SYS_COLUMNS_...........................................................................................................18 SYS_CONSTRAINTS_...................................................................................................21 SYS_CONSTRAINT_COLUMNS_................................................................................23 SYS_DATABASE_ .........................................................................................................25 SYS_DIRECTORIES_ ....................................................................................................26 SYS_GRANT_OBJECT_ ................................................................................................27 SYS_GRANT_SYSTEM_...............................................................................................29 SYS_INDEX_COLUMNS_ ............................................................................................30 SYS_INDICES_...............................................................................................................32 SYS_PRIVILEGES_........................................................................................................34 SYS_PROCEDURES_ ....................................................................................................35 SYS_PROC_PARAS_ .....................................................................................................38 SYS_PROC_PARSE_......................................................................................................40 SYS_PROC_RELATED_................................................................................................41 SYS_REPLICATIONS_ ..................................................................................................43 SYS_REPL_HOSTS_......................................................................................................45 SYS_REPL_ITEMS_.......................................................................................................46 SYS_SYNONYMS_........................................................................................................48 SYS_TABLES_ ...............................................................................................................49 SYS_TBS_USERS_.........................................................................................................51 SYS_TRIGGERS_...........................................................................................................52 SYS_TRIGGER_DML_TABLES_ .................................................................................54 SYS_TRIGGER_STRINGS_...........................................................................................55 SYS_TRIGGER_UPDATE_COLUMNS_......................................................................56 SYS_USERS_..................................................................................................................57 SYS_VIEWS_..................................................................................................................58 SYS_VIEW_PARSE_......................................................................................................59 SYS_VIEW_RELATED_................................................................................................60 성능 뷰............................................................................................................................61

성능 뷰의 종류..............................................................................................................63

ii Administrator’s Manual

V$ALLCOLUMN ...........................................................................................................65 V$ARCHIVE...................................................................................................................66 V$BUFFPAGEINFO.......................................................................................................67 V$BUFFPOOL_STAT ....................................................................................................70 V$DATABASE ...............................................................................................................72 V$DATAFILES...............................................................................................................75 V$DISKGC .....................................................................................................................79 V$DISKTBL_INFO ........................................................................................................80 V$MEMTBL_INFO ........................................................................................................94 V$FLUSHINFO ..............................................................................................................81 V$INDEX........................................................................................................................82 V$INSTANCE.................................................................................................................83 V$LATCH .......................................................................................................................84 V$LFG.............................................................................................................................85 V$LOCK .........................................................................................................................88 V$LOCK_WAIT .............................................................................................................89 V$LOG ............................................................................................................................90 V$LOCK_STATEMENT................................................................................................92 V$MEMGC .....................................................................................................................93 V$MEMSTAT.................................................................................................................95 V$MUTEX ......................................................................................................................96 V$PLANTEXT................................................................................................................97 V$PROCTEXT................................................................................................................98 V$PROPERTY................................................................................................................99 V$REPEXEC................................................................................................................. 100 V$REPGAP ...................................................................................................................101 V$REPSYNC ................................................................................................................102 V$REPRECEIVER........................................................................................................103 V$REPRECEIVER_TRANSTBL .................................................................................105 V$REPSYNC ................................................................................................................106 V$REPSENDER_TRANSTBL ..................................................................................... 107 V$SEGMENT................................................................................................................108 V$REPSENDER............................................................................................................109 V$SEQ...........................................................................................................................111 V$SERVICE_THREAD................................................................................................ 112 V$SESSION .................................................................................................................. 113 V$SESSIONMGR ......................................................................................................... 118 V$STATEMENT...........................................................................................................119 V$SQLTEXT.................................................................................................................121 V$TABLE .....................................................................................................................122 V$TABLESPACES.......................................................................................................123 V$TRACELOG .............................................................................................................125 V$TRANSACTION ......................................................................................................127 V$TRANSACTION_MGR ........................................................................................... 130 V$UNDO_BUFF_STAT............................................................................................... 131 V$VERSION ................................................................................................................. 132

4. 데이터베이스 객체 및 권한 관리.........................................................133

데이터베이스 객체 개요 ...........................................................................................134

테이블 관리 .................................................................................................................138

큐 테이블 관리 ...........................................................................................................146

제약조건 관리 .............................................................................................................148

인덱스 관리 .................................................................................................................151

목차 iii

뷰 관리..........................................................................................................................155

시퀀스 관리..................................................................................................................157

시노님 관리..................................................................................................................160

저장 프로시저 및 저장 함수 관리 ..........................................................................162

트리거 관리..................................................................................................................166

사용자 관리..................................................................................................................168

권한 관리......................................................................................................................170

Part II............................................................................................. 173

5. 테이블스페이스 관리........................................................................... 175

테이블스페이스 개요..................................................................................................176

테이블스페이스 생성..................................................................................................186

테이블스페이스 변경..................................................................................................196

테이블스페이스 삭제..................................................................................................203

테이블스페이스 정보..................................................................................................204

6. 트랜잭션 관리..................................................................................... 207

트랜잭션........................................................................................................................208

잠금(Lock)의 개요 .......................................................................................................211

다중 버전 동시성 제어 기법 ....................................................................................214

트랜잭션 지속성(Transaction Durability) 개념 .........................................................222

트랜잭션 지속성 관리 정책(Transaction Durability Policy) ....................................224

7. 버퍼 관리자........................................................................................ 227

버퍼 관리자 구조........................................................................................................228

버퍼 관리......................................................................................................................232

관련 프로퍼티..............................................................................................................240

통계 정보......................................................................................................................241

8. 백업 및 복구 ...................................................................................... 243

알티베이스 백업..........................................................................................................244

알티베이스 복구..........................................................................................................247

백업 및 복구 사례들..................................................................................................253

9. SQL 튜닝 ........................................................................................... 265

SQL 튜닝 소개 ............................................................................................................266

질의 최적화 과정........................................................................................................273

실행 계획 분석............................................................................................................314

힌트의 활용..................................................................................................................354

10. Explain Plan....................................................................................... 359

개요................................................................................................................................360

Plan Tree 보기 ..............................................................................................................363 Plan Nodes .....................................................................................................................365

Part III ........................................................................................... 395

11. 알티베이스 튜닝 ................................................................................. 397

그룹 커밋(Group Commit)...........................................................................................398

로그파일그룹(Log File Group) ....................................................................................404

iv Administrator’s Manual

12. 알티베이스 모니터링 및 PBT .............................................................412

알티베이스 모니터링 .................................................................................................413

알티베이스 PBT ..........................................................................................................414

A. 부록: Trace Log .................................................................................423

서문 i

서문

ii Administrator’s Manual

이 매뉴얼에 대하여 이 매뉴얼은 알티베이스를 구성, 관리, 사용하기 위해 필요한 개

념에 대해 설명한다.

대상 사용자 이 매뉴얼은 다음과 같은 알티베이스 사용자를 대상으로 작성되

었다.

데이터베이스 관리자

시스템 관리자

성능 관리자

다음과 같은 배경 지식을 가지고 이 매뉴얼을 읽는 것이 좋다.

컴퓨터, 운영 체제 및 운영 체제 유틸리티 운용에 필요한 기

본 지식

관계형 데이터베이스 사용 경험 또는 데이터베이스 개념에

대한 이해

데이터베이스 서버 관리, 운영 체제 관리 또는 네트워크 관

리 경험

소프트웨어 환경 이 매뉴얼은 데이터베이스 서버로 알티베이스 버전 4.3.9.0을 사

용한다는 가정 하에 작성되었다.

이 매뉴얼의 구성 이 매뉴얼은 다음과 같이 구성되어 있다.

제 1장 데이터베이스 생성

이 장은 데이터베이스를 구성하는 대표적 구성 요소인 테이

블스페이스와 로깅 시스템의 종류 및 데이터베이스 생성 방

법에 관하여 설명한다.

제 2장 알티베이스 구동 및 종료

이 장은 알티베이스를 구동 및 종료 시키는 방법과 알티베이

스 다단계 구동 시 내부적으로 수행하는 작업에 대해 설명한

다.

서문 iii

제 3장 데이터 딕셔너리

이 장은 알티베이스 시스템 정보를 제공하는 데이터 딕셔너

리에 대해 설명한다.

제 4장 데이터베이스 객체 및 권한 관리

이 장은 특정 사용자에 의해 생성된 제약조건, 인덱스, 시퀀

스, 이중화, 테이블, 사용자 등 데이터베이스 객체들에 대해

설명한다. 또한, 시스템과 스키마 객체 레벨 권한에 대해 설

명한다.

제 5장 테이블스페이스 관리

이 장은 데이터베이스의 논리적 구조를 이해함으로써 데이터

베이스의 공간 관리를 작은 단위로 제어하고, 물리적 데이터

영역을 효율적으로 관리하는 방법에 대해 설명한다.

제 6장 트랜잭션 관리

이 장은 트랜잭션을 정의하고 트랜잭션을 사용하여 작업을

관리하는 방법에 대해 설명한다.

제 7장 버퍼 관리

알티베이스는 대용량의 데이터가 디스크에 저장될 수 있도록

지원하는데, 메모리의 공간은 한정되어 있으므로 이를 전부

메모리에 적재할 수 없으므로 테이블, 인덱스, 레코드 등 모

든 데이터에 접근하기 위해서는 먼저 디스크의 데이터를 메

모리에 적재해야 한다. 이 장은 이러한 메모리 공간을 할당하

고, 메모리 공간이 부족한 경우 필요한 데이터를 제공할 수

있도록 메모리 공간을 유지 및 관리하느 버퍼 관리자에 대하

여 설명한다.

제 8장 백업 및 복구

이 장은 시스템 정전 또는 디스크 ,데이터 파일 손상 유실 등

과 같은 예기치 않은 상황으로 인해 알티베이스에 저장된 데

이터가 손실될 경우를 대비하여 알티베이스에서 지원하는 백

업 및 복구에 대하여 설명한다.

제 9장 SQL 튜닝

이 장은 질의 성능을 향상시키기 위한 SQL 튜닝 방법에 대

하여 설명한다.

제 10장 Explain Plan

이 장은 알티베이스 DBMS 서버가 최적화된 질의를 실행하

기 위해 수행하는 접근 경로를 설명한다.

제 11장 알티베이스 모니터링과 PBT

이 장은 알티베이스의 운영상태를 확인하는 방법과 해당 내

용을 분석하는 방법에 대해 설명한다. 또한, 알티베이스 운

iv Administrator’s Manual

영 중 발생할 수 있는 여러 가지 문제 상황에 대하여 점검

사항 및 분석 방법에 대해 설명한다.

부록 B: Trace Log

문서화 규칙 이 절에서는 이 매뉴얼에서 사용하는 규칙에 대해 설명한다. 이

규칙을 이해하면 이 매뉴얼과 설명서 세트의 다른 매뉴얼에서 정

보를 쉽게 찾을 수 있다.

여기서 설명하는 규칙은 다음과 같다.

구문 다이어그램

샘플 코드 규칙

구문 다이어그램

이 매뉴얼에서는 다음 구성 요소로 구축된 다이어그램을 사용하

여, 명령문의 구문을 설명한다.

구성 요소 의미

예약어

명령문이 시작한다. 완전한 명령문이 아닌 구문 요소는 화살표로 시작한다.

명령문이 다음 라인에 계속된다. 완전한 명령문이 아닌 구문 요소는 이 기호로 종료한다.

명령문이 이전 라인으로부터 계속된다. 완전한 명령

문이 아닌 구문 요소는 이 기호로 시작한다. ;

명령문이 종료한다.

SELECT

필수 항목

NOT

선택적 항목

ADD

DROP

선택사항이 있는 필수 항목. 한 항목만 제공해야 한다.

ASC

DESC

선택사항이 있는 선택적 항목.

서문 v

,

ASC

DESC

선택적 항목. 여러 항목이 허용된다. 각 반복 앞부

분에 콤마가 와야 한다.

샘플 코드 규칙

코드 예제는 SQL, Stored Procedure, iSQL, 또는 다른 명령 라인

구문들을 예를 들어 설명한다.

아래 테이블은 코드 예제에서 사용된 인쇄 규칙에 대해 설명한다.

규칙 의미 예제 [ ] 선택 항목을 표시 VARCHAR [(size)]

[[FIXED |] VARIABLE] { } 필수 항목 표시. 반드시 하나 이상을 선

택해야 되는 표시 { ENABLE | DISABLE | COMPILE }

| 선택 또는 필수 항목 표시의 인자 구분 표시

{ ENABLE | DISABLE | COMPILE } [ ENABLE | DISABLE | COMPILE ]

.

.

.

그 이전 인자의 반복 표시 예제 코드들의 생략되는 것을 표시

SQL> SELECT ename FROM employee; 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_;

vi Administrator’s Manual

관련 자료 자세한 정보를 위하여 다음 문서 목록을 참조하기 바란다.

ALTIBASE Administration Installation Users Manual

ALTIBASE Administration Starting Users Manual

ALTIBASE Application Development SQL Users Manual

ALTIBASE Application Development Stored Procedure

Users Manual

ALTIBASE Tools iSQL Users Manual

ALTIBASE Tools Utilities Users Manual

ALTIBASE Message Error Message Reference

온라인 매뉴얼 알티베이스 온라인 문서사이트 http://www.altibase.com/ 다운로

드 센터에서 한글 및 영어 온라인 매뉴얼(PDF, HTML)을 얻을

수 있다.

알티베이스는 여러분의 의견을 환영합니다. 이 매뉴얼에 대한 여러분의 의견을 보내주십시오. 사용자의 의견

은 다음 버전의 매뉴얼을 작성하는 데 많은 도움이 됩니다. 다음

내용을 함께 적어 보내주십시오.

사용 중인 매뉴얼의 이름과 버전

매뉴얼에 대한 의견

사용자의 성함, 주소, 전화번호

다음 주소로 전자 우편을 보내주십시오.

[email protected]

이 주소는 설명서의 오류와 누락된 부분을 보고할 수 있도록 만

들어진 주소입니다. 기술적인 문제와 관련하여 즉각적인 도움이

필요한 경우에는 Altibase Customer Support로 연락하시기 바랍

니다.

여러분의 의견에 항상 감사드리고 있습니다.

PartⅠ 1

Part I

데이터베이스 생성 3

1. 데이터베이스 생성

알티베이스 설치 후에 데이터베이스 관리자는 사용자 데이터 발

생량을 예측하여 데이터베이스를 생성하고 관리해야 한다. 이장에

서는 데이터베이스 생성시에 알고 있어야 되는 주요사항들에 대

해서 설명하고 있다.

4 Administrator’s Manual

데이터베이스 생성 알티베이스를 사용하기 위해서는 반드시 데이터베이스를 생성 시

켜 놓아야 한다. 그렇지 않으면 알티베이스가 실행되지 않는다.

여기에서는 데이터베이스를 구성하는 대표적 구성 요소인 테이블

스페이스와 로깅 시스템의 종류 및 생성 방법에 관하여 설명한

다.

테이블스페이스의 종류 알티베이스의 데이터베이스는 여러 개의 테이블스페이스로 구성

된다. 알티베이스에서 제공하는 기본 테이블스페이스는 아래와 같

다.

메모리 테이블스페이스 딕셔너리 테이블들과 메모리 테이블들, 그리고 이에 관련된 다양

한 데이터베이스 객체들이 저장되는 테이블스페이스이다.

데이터 테이블스페이스 디스크 테이블들과 인덱스들이 저장되는 테이블스페이스이다. 이

는 다시 시스템 데이터 테이블스페이스와 사용자 데이터 테이블

스페이스로 구분된다.

언두 테이블스페이스(Undo Tablespace) 디스크 테이블에 존재하는 Record들에 대한 다중버전 동시성 제

어( MVCC: Multi-Versioned Concurrency Control)를 제공하기

위해 변경 이전 이미지를 일정 기간 동안 저장해두는 테이블스페

이스 이다.

임시 테이블스페이스(Temporary Tablespace) 질의를 처리하는 과정에서 발생되는 임시 테이블들과 인덱스들을

저장하는 테이블스페이스 이다. 데이터 테이블스페이스와 마찬가

지로 시스템 임시 테이블스페이스와 사용자 임시 테이블스페이스

로 나뉜다.

각 테이블스페이스를 구성하는 파일들은 기본적으로 .dbf의 확장

자를 가지며, CREATE DATABASE 시에 생성되는 위치는

$ALTIBASE_HOME/dbs/ 이다.

*참고: 알티베이스 운용 중 사용자의 요구에 의해 새로 추가되는

파일의 확장자의 형식이나 디렉터리 위치는 제한은 없다.

로깅 시스템


데이터베이스 내의 데이터들은 어떤 상황 하에서도 영속성을 가

져야 한다. 알티베이스는 다음의 두 가지 파일들로 로깅 시스템을

구성하여 데이터베이스의 영속성을 제공한다.

로그 파일 트랜잭션 수행 중에 abnormal shutdown에 대비하여 system

recovery를 위해 작성되는 로그 레코드들을 기록하는 파일들이

다. 로그 파일의 이름은 logfile**이다(**은 로그 파일의 시퀀스

번호이다.).

로그 앵커(Log Anchor) 파일 테이블스페이스들에 대한 정보와 파일들의 위치, 체크 포인트 관

련 정보 등 서버 운용에 관련된 중요한 데이터가 저장된 파일이

다. 서버가 정상적으로 구동 되려면 이 파일의 내용이 유효하여야

하며, 그렇지 않을 경우에는 서버를 구동 시킬 수 없다.

최초 데이터베이스 생성시 로그 파일과 로그 앵커 파일들은

$ALTIBASE_HOME/logs/ 위치에 생성된다.

알티베이스는 이 로그 앵커 파일들을 3벌로 유지하며, 데이터베

이스 생성 시에는 로그 파일들과 같은 위치에 존재하지만, 3개의

로그 앵커 파일들을 서로 다른 파일 시스템에 두기를 권장하고

있다. 로그 앵커 파일의 위치에 관련된 프로퍼티

LOGANCHOR_DIR 이다.

데이터베이스 생성 준비 알티베이스의 데이터베이스를 생성하려면 패키지에 제공되는 사

용자 유틸리티인 isql을 다음과 같이 수행한다.

shell> isql –s 127.0.0.1 –u sys –p manager –sysdba

이는 데이터베이스에 접속하지 않고 isql을 관리자 모드(admin

mode)로 띄우는 것이며, 다음과 같은 명령도 동일한 기능을 수행

한다.

shell > is –sysdba

결과는 아래와 같다.

------------------------------------------------ Altibase Client Query utility. Release Version 4.1.1.5 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. ------------------------------------------------ ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20000 [ERR-00000: Connected to idle instance]


위의 상태가 되면 일단 CREATE DATABASE 명령을 수행하기

위한 서버 프로세스를 구동 시켜야 한다. 서버의 구동은 다음과

같은 순서로 이루어 진다.

1. Pre-Process 단계

서버를 구동하기 이전 단계이다.

2. Process 단계

create database 및 property들을 조회하고 변경할 수 있는 단

계이다.

3. Control 단계

database 파일 로드, recovery 준비 단계이다.

4. Meta 단계

recovery 완료, meta data upgrade 가능, 온라인로그 reset할

수 있는 단계이다.

5. Service 단계

사용자에게 서비스 가능한 최종 단계이다.

데이터베이스의 생성은 Process 단계에서 이루어 질 수 있다. 현

재 단계는 Pre-Process 단계이므로, 다음과 같은 명령을 수행하

여 Process 단계로 진행한다.

iSQL> startup process

Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE: PROCESS Command execute success.

Process 단계로 진행되었으면 이제 CREATE DATABASE 명령

으로 데이터베이스를 생성할 수 있다.

데이터베이스 생성 Process 단계에서 데이터베이스를 생성하기 위한 CREATE

DATABASE 명령은 아래와 같이 수행한다. CREATE

DATABASE 구문의 자세한 사용법은SQL Users Manual을 참조

한다. 여기서는 기본 옵션으로 데이터베이스를 생성하는 예를 보

여주고 있다.

iSQL> create database mydb initsize=50M noarchivelog;

DB Info (Page Size = 32768)

(Page Count = 1600)

(File Size = 52428800)


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> shutdown abort;

altibase process killed.. [ERR-00000: Connected to idle instance]

서버를 종료하면 isql은 다시 서버에 접속하지 않은 Pre-Process

상태가 되며, 서버 프로세스도 종료된다.

shutdown 명령의 유형으로는 abort외에 immediate와 normal이

더 있으나, 이들은 서버가 service 단계일 때만 수행이 가능하다.

데이터베이스 생성 관련 프로퍼티 CREATE DATABASE 구문을 수행할 때 지정하지 않은 속성들은

알티베이스 프로퍼티 파일에 의해 결정되며, 영향을 미치는 프로

퍼티들은 아래와 같다. 표에서 ?는 환경변수 ALTIBASE_HOME

의 경로를 의미한다..

프로퍼티 이름 설명 기본 값 DB_NAME 생성할 데이터베이스의 이름 mydb LOG_DIR 로그 파일들이 위치할 디렉터리 ?/logs

MEM_DB_DIR 데이터베이스 파일들이 위치할 디렉터리(3번 정의됨) ?/dbs

LOGANCHOR_DIR 로그 앵커 파일들이 위치할 디렉터

리(3번 정의됨) ?/logs

TRC_DIR 알티베이스 운용 중 발생되는 서버

의 메시지를 기록하는 파일들이 위치하는 디렉터리

?/trc

SHM_DB_KEY 공유 메모리 버전으로 알티베이스 0


를 띄울 경우에 사용할 공유메모리 키값

(사용안함)

MEM_MAX_DB_SIZE 메모리 테이블스페이스의 최대 크기 4G

MEM_DB_FILE_SIZE 메모리 테이블스페이스를 구성하는 파일들 하나의 최대 크기 1G

LOG_FILE_SIZE 로그 파일 하나의 크기 10M

STARTUP_SHM_CHUNK_SIZE 알티베이스 구동 시 생성되는 공유

메모리 한 개의 최대 크기 1G

PERS_PAGE_CHUNK_COUNT 메모리 테이블스페이스 페이지를 한 번에 할당하는 페이지 개수 3200

TEMP_PAGE_CHUNK_COUNT 메모리 테이블스페이스의 임시 페이지를 한 번에 할당하는 페이지 개수

128

SYS_DATA_TBS_EXTENT_SIZE 시스템 데이터 테이블스페이스의 익스텐트 한 개의 크기 256K

SYS_DATA_TBS_INIT_SIZE CREATE DATABASE 실행 시 생성되는 시스템 테이블스페이스의 최초 크기

100M

SYS_DATA_TBS_MAX_SIZE 시스템 테이블스페이스의 최대 크기 2G

SYS_DATA_TBS_NEXT_SIZE 시스템 테이블스페이스 파일이 자동 확장될 때 의 확장 크기 1M

SYS_TEMP_TBS_EXTENT_SIZE 임시 테이블스페이스의 익스텐트 한 개의 크기 256K

SYS_TEMP_TBS_INIT_SIZE CREATE DATABASE 실행 시 생성되는 임시 테이블스페이스의 최초 크기

100M

SYS_TEMP_TBS_MAX_SIZE 임시 테이블스페이스의 최대 크기 2G

SYS_TEMP_TBS_NEXT_SIZE 임시 테이블스페이스 파일이 자동 확장될 때 의 확장 크기 1M

SYS_UNDO_TBS_EXTENT_SIZE 언두 테이블스페이스의 익스텐트 한 개의 크기 128K

SYS_UNDO_TBS_INIT_SIZE CREATE DATABASE 실행 시 생성되는 언두 테이블스페이스의 최초 크기

100M

SYS_UNDO_TBS_MAX_SIZE 언두 테이블스페이스의 최대 크기 2G

SYS_UNDO_TBS_NEXT_SIZE 언두 테이블스페이스 파일이 자동 확장될 때 의 확장 크기 1M

USER_DATA_TBS_EXTENT_SIZE 사용자 데이터 테이블스페이스의 익스텐트 한 개의 크기 256K

USER _DATA_TBS_INIT_SIZE CREATE DATABASE 실행 시 생성되는 사용자 테이블스페이스의 최초 크기

100M

USER _DATA_TBS_MAX_SIZE 사용자 테이블스페이스의 최대 크기 2G


USER _DATA_TBS_NEXT_SIZE 사용자 테이블스페이스 파일이 자동 확장될 때 의 확장 크기 1M

USER _TEMP_TBS_EXTENT_SIZE 사용자 임시 테이블스페이스의 익스텐트 한 개의 크기 256K

USER _TEMP_TBS_INIT_SIZE CREATE DATABASE 실행 시 생성되는 사용자 임시 테이블스페이

스의 최초 크기 100M

USER _TEMP_TBS_MAX_SIZE 사용자 임시 테이블스페이스의 최대 크기 2G

USER _TEMP_TBS_NEXT_SIZE 사용자 임시 테이블스페이스 파일

이 자동 확장될 때 의 확장 크기 1M

ADD_EXTENT_NUM_FROM_TBS_TO_SEG

세그먼트가 확장될 때 증가하는 익스텐트의 개수 1

ADD_EXTENT_NUM_FROM_SYSTEM_TO_TBS

테이블스페이스가 확장할 때 새로

운 익스텐트를 할당하는 개수 4

CHECKSUM_METHOD 페이지의 상태가 올바른지 체크하

는 방법의 종류 1

* 프로퍼티에 대한 보다 자세한 내용은 Starting Users Manual를

참조하기 바란다.

알티베이스 구동 및 종료 11

2. 알티베이스 구동 및

종료

데이터베이스를 생성한 다음 서비스 수행을 위해서는 데이터베이

스를 다시 구동하여야 한다. 이 장에서는 데이터베이스 구동과 종

료 시에 참고할 사항들을 설명하고 있다.


알티베이스의 구동 알티베이스 서버를 실행하는 방법은 sys 계정의 관리자가 서버에

로그인 시 -sysdba 관리자 모드를 통하여 서버에 접속한 후 부

여된 관리자 권한을 이용하거나 서버 스크립트 명령을 이용하여

실행할 수 있다.

알티베이스를 실행시키기 위해서는 데이터베이스 생성 시와 마찬

가지로 우선 isql을 –sysdba 옵션으로 실행해야 한다.

알티베이스의 startup 명령어는 알티베이스(isql 포함)를 설치한

유닉스 계정으로만 수행이 가능하다.

shell> isql –s 127.0.0.1 –u sys –p manager –sysdba

----------------------------------------------

Altibase Client Query utility.

Release Version 4.1.1.5

Copyright 2000, ALTIBASE Corporation or its

subsidiaries.

All Rights Reserved.

----------------------------------------------

ISQL_CONNECTION = TCP, SERVER = 127.0.0.1,

PORT_NO = 20000

[ERR-00000: Connected to idle instance]

알티베이스가 구동할 때 상태는 PRE_PROCESS, PROCESS,

CONTROL, META, SERVICE 의 순으로 전이하며, SERVICE 상

태가 되어야 일반 사용자들의 연결을 받을 수 있다. SERVICE 상

태로 진행하기 위해서는 아래의 STARTUP 구문을 사용한다.

STARTUP [PROCESS | CONTROL | META | SERVICE];

*참고: 알티베이스의 상태는 다음 상태로 진행만 되며, 이전 상태

로의 복귀는 지원하지 않는다.

SERVICE 상태로 전이시키는 예는 아래와 같다.

iSQL> startup service;

Trying Connect to Altibase..... Connected with Altibase. TRANSITION TO PHASE: PROCESS 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

알티베이스 구동 및 종료 13

Serial Bulk Loading . is 8192k: *..[SUCCESS] [SM] Recovery Phase - 3: Skipping Recovery & Starting 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.

Startup의 각 단계에서 할 수 있는 일은 다음과 같다.

단계 가능한 작업 PRE-PROCESS PROCESS 단계로 전이할 수 있다.

PROCESS

Create Database를 수행할 수 있다. 제한된 개수의 Performance View들을 검색할 수 있다. 프로퍼티 값들을 변경시킬 수 있다. CONTROL 단계로 전이할 수 있다.

CONTROL Media Recovery를 수행할 수 있다. META 단계로 전이할 수 있다.

META

Meta(Dictionary table)를 upgrade 할 수 있다. CONTROL 단계에서 불완전 복구를 한 경우 meta 구동 단계로 가는 과정에 온라인로그를 reset 하는데 사용할 수 있다. SERVICE 단계로 전이할 수 있다.

SERVICE 일반 사용자로부터 접속을 받을 수 있다. SHUTDOWN NORMAL/IMMEDIATE/ABORT 를 수행할 수 있다.


알티베이스의 종료 현재 구동중인 알티베이스 서버를 종료하려면 SHUTDOWN 구문

을 사용한다.

SHUTDOWN [NORMAL | IMMEDIATE | ABORT];

shutdown normal과 shutdown immediate는 알티베이스가

SERVICE 상태일 때만 수행 가능하며, shutdown abort는 어떤

상태에서도 수행 가능하다. 알티베이스의 shutdown 명령어는 알

티베이스(isql 포함)를 설치한 유닉스 계정으로만 수행이 가능하

다.

normal 서버를 정상적으로 종료하는 방식으로서, 클라이언트들이 모두 종

료될 때까지 서버의 종료 작업을 대기하는 방법이다. 서버가 종료

하면서 수행하는 일들은 클라이언트-서버간 통신 세션을 감지하

는 쓰레드의 종료, 서비스 쓰레드의 종료, 자료저장 관리자의 종

료, 그리고 알티베이스 서버 프로세스가 완전히 종료되기를 대기

하는 일들을 수행함으로써 알티베이스 서버를 종료한다.

immediate 서버를 종료할 때 현재 연결된 세션들을 강제로 단절시킨 다음,

알티베이스 서버가 현재 실행 중인 트랜잭션들을 철회(rollback)

시키고 알티베이스 서버를 종료하는 방법이다.

abort 알티베이스 서버를 kill -9 시스템 명령을 사용하여 강제로 죽이

는 방법이다. 이 방법으로 알티베이스 서버를 종료하면, 데이터베

이스가 완전하지 못하여 다음에 알티베이스 서버를 실행할 때 데

이터베이스 복구 과정을 거쳐야 한다.

알티베이스 서버를 정상적인 방법(normal/immediate)으로 종료시

키면 아래와 같은 메시지가 화면에 출력된다.

iSQL> shutdown normal;

Ok..Shutdown Proceeding.... TRANSITION TO PHASE: Shutdown Altibase . Writing Persistent Indices[Total Count:61] shutdown normal success. [ERR-00000: Connected to idle instance]

알티베이스 서버를 강제종료 시키면 다음과 같은 메시지가 화면

에 출력된다.

iSQL> shutdown abort;

altibase process killed.. [ERR-00000: Connected to idle instance]

데이터 딕셔너리 15

3. 데이터 딕셔너리

알티베이스의 데이터 딕셔너리는 데이터베이스 객체 정보를 저장

하는 메타 테이블과 시스템 프로세스 정보를 저장하는 프로세스

테이블로 나뉘어지며, 프로세스 정보는 다시 고정 테이블과 성능

뷰로 나뉘어진다.

본 장은 데이터베이스 객체 및 알티베이스 시스템 정보를 제공하

는 데이터 딕셔너리에 대해 설명한다.


메타 테이블 메타 테이블이란 데이터베이스 객체에 관한 모든 정보를 수록하

기 위한 시스템 정의 테이블이다. 여기에서는 메타 테이블의 종류

및 구조, 그리고 메타 테이블의 조회 및 변경에 관하여 설명한다.

구조 및 기능 메타 테이블은 시스템이 데이터베이스 객체를 관리하기위해 생성

하는 시스템 정의 테이블로 사용자가 생성하는 일반 테이블과 동

일한 구조를 가진다. 따라서 메타 테이블이 사용하는 데이터 타입

및 레코드 저장 형태는 일반 테이블과 동일하다.

알티베이스는 구동 시 데이터베이스 객체 정보를 로딩하고, DDL

문 수행 시 데이터베이스 객체 정보를 조회, 저장 및 변경하기 위

해 메타 테이블을 사용한다.

메타 테이블의 소유자는 시스템 사용자(SYSTEM_ )로 일반 사용

자는 메타 테이블의 접근이 제한적이다.

메타 테이블 조회 DDL문을 통해 데이터베이스 객체를 생성, 삭제 및 변경 시 메타

테이블의 레코드가 시스템에 의해 생성, 삭제 또는 변경된다.

DDL문 수행 후 반영된 데이터베이스 객체 정보는 메타 테이블을

통해 확인할 수 있는데, 메타 테이블의 레코드는 일반 테이블과

같이 SELECT문을 통하면 조회할 수 있다.

메타 테이블 데이터 변경 메타 테이블 데이터에 대한 사용자의 명시적인 변경은 메타 테이

블에 대한 DML문을 통하여 수행할 수 있다. 다만 시스템에서 정

의된 시스템 사용자(SYSTEM_ )만이 메타 테이블을 명시적으로

변경할 수 있다. 그러나 메타 테이블 정보가 변경되면 시스템 구

동이 실패하거나, 데이터베이스 객체 정보를 상실하여 시스템에

치명적인 손상이 발생할 수 있다. 따라서 가급적 메타 테이블 데

이터에 대한 사용자의 명시적인 변경은 피해야 하고, 불가피한 사

정으로 메타 테이블 데이터 변경 시에는 변경 전에 반드시 데이

터베이스 백업을 해야 하며, 사용자의 명시적인 메타 테이블 데이

터 변경으로 인해 발생하는 데이터베이스의 손상은 전적으로 사

용자 책임이다.


메타 테이블 스키마 변경 새로운 DDL문의 제공 또는 DDL문 기능 변경 시 메타 테이블 스

키마가 변경될 수 있다. 이 때 메타 테이블 스키마 변경 특성에

따라 데이터베이스 마이그레이션이 필요한 경우와 알티베이스 구

동 시 자동으로 메타 테이블 스키마를 변경하는 두 가지 경우로

구분할 수 있다. 알티베이스 하위 버전에서 상위 버전으로 업그레

이드 시 이를 고려해야 한다.

메타 테이블 종류 메타 테이블의 이름은 SYS_로 시작하며 종류는 다음과 같다.

Meta Table Name Description

SYS_COLUMNS_ 칼럼 메타 테이블 SYS_CONSTRAINTS_ 제약 조건 메타 테이블 SYS_CONSTRAINT_COLUMNS_ 제약 조건 관련 칼럼 메타 테이블 SYS_DATABASE_ 데이터베이스 메타 테이블 SYS_GRANT_OBJECT_ 객체 권한 메타 테이블 SYS_GRANT_SYSTEM_ 시스템 권한 메타 테이블 SYS_INDEX_COLUMNS_ 인덱스 키 칼럼 메타 테이블 SYS_INDICES_ 인덱스 메타 테이블 SYS_PRIVILEGES_ 권한 메타 테이블 SYS_PROCEDURES_ 저장 프로시저 및 함수 메타 테이블

SYS_PROC_PARAS_ 저장 프로시저 및 함수의 파라미터 메타 테이블

SYS_PROC_PARSE_ 저장 프로시저 및 함수 구문 메타 테이블

SYS_PROC_RELATED_ 저장 프로시저 및 함수 접근 테이블 메타 테이블

SYS_REPLICATIONS_ 이중화 메타 테이블 SYS_REPL_HOSTS_ 이중화 호스트 메타 테이블 SYS_REPL_ITEMS_ 이중화 테이블 메타 테이블 SYS_TABLES_ 테이블 메타 테이블 SYS_TBS_USERS_ 테이블스페이스 사용자 메타 테이블 SYS_TRIGGERS_ 트리거 메타 테이블 SYS_TRIGGER_DML_TABLES_ 트리거 접근 테이블 메타 테이블 SYS_TRIGGER_STRINGS_ 트리거 구문 메타 테이블 SYS_TRIGGER_UPDATE_COLUMNS_ 트리거 변경 칼럼 메타 테이블 SYS_USERS_ 사용자 메타 테이블 SYS_VIEWS_ 뷰 메타 테이블 SYS_VIEW_PARSE_ 뷰 구문 메타 테이블 SYS_VIEW_RELATED_ 뷰 접근 테이블 메타 테이블

이들 메타 테이블 각각의 스키마와 저장 정보에 대한 상세 설명

은 다음과 같다.


SYS_COLUMNS_ 모든 테이블에 정의된 칼럼들의 정보, 뷰의 가상 칼럼 정보, 그리

고 시퀀스의 가상 칼럼 정보를 저장하는 메타 테이블이다.

Column name Type Description COLUMN_ID INTEGER 칼럼 식별자 DATA_TYPE INTEGER 데이터 타입 LANG_ID INTEGER 언어 식별자 OFFSET INTEGER 레코드 내 칼럼의 오프셋 SIZE INTEGER 레코드 내 칼럼의 물리적 길이 USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 PRECISION INTEGER 지정한 프리시즌(precision) SCALE INTEGER 지정한 스케일(scale) COLUMN_ORDER INTEGER 칼럼 생성순서 COLUMN_NAME VARCHAR(40) 칼럼 이름

IS_NULLABLE CHAR(1) 널(NULL) 허용 여부 T: NULL 허용 F: NULL 불허

DEFAULT_VAL VARCHAR(4000) 기본 값

IS_VARING CHAR(1) 칼럼의 VARIABLE 옵션 여부 T: variable column F: fixed column

IN_ROW_SIZE INTEGER 메모리 테이블의 VARCHAR 칼럼의 데이

터를 저장할 때 fixed 영역에 저장할 데이

터 길이를 지정한다.

칼럼 정보 COLUMN_ID

칼럼 식별자로 시스템 시퀀스에 의해 자동으로 부여되는 식별자

이다.

DATA_TYPE

데이터타입의 식별자로 데이터타입 별 식별자 값은 다음과 같다.

Data Type Name Number CHAR 1 NUMERIC 2 DECIMAL 2 INTEGER 4 SMALLINT 5 FLOAT 6 NUMBER 6


REAL 7 DOUBLE 8 DATE 9 VARCHAR 12 BLOB 30 BIGINT -5 BYTE 20001 NIBBLE 20002

데이터 타입에 대한 자세한 내용은 SQL Users Manual을 참조한

다.

LANG_ID

문자형 타입(CHAR, VARCHAR)의 언어 속성 정보를 나타내는 칼

럼이다.

OFFSET

레코드 내 칼럼의 물리적 저장 시작 위치이다. 레코드의 물리적

저장 크기를 계산할 때 칼럼의 오프셋과 사이즈 값을 이용해 계

산한다.

SIZE

레코드 내 칼럼의 사이즈로 칼럼의 타입 및 사용자가 지정하는

프리시즌 등에 따라 시스템이 계산하여 정해진 물리적 저장 사이

즈이다.

USER_ID

칼럼이 속한 테이블 소유자의 사용자 식별자로 SYS_USERS_ 메

타 테이블의 USER_ID 값과 동일하다.

TABLE_ID

칼럼이 속한 테이블 식별자로 SYS_TABLES_ 메타 테이블의

TABLE_ID 값과 동일하다.

PRECISION

사용자가 지정하거나 또는 시스템이 기본 값으로 부여한 데이터

타입의 프리시즌이다. 문자형 타입의 경우 사용자가 정의한 문자

형 타입의 길이이다.

SCALE


타입의 스켈이다. 타입에 따라 이 값은 사용하지 않을 수 있다.

COLUMN_ORDER

한 테이블 내에서 해당 칼럼의 생성 순서이다.

CREATE TABLE문의 칼럼 명시 순서가 칼럼의 생성 순서이며,

ALTER TABLE문으로 칼럼을 추가한 경우 이 칼럼은 해당 테이

블의 마지막 칼럼으로 생성된다.


COLUMN_NAME

사용자가 테이블 생성 시 명시한 칼럼의 이름이다.

IS_NULLABLE

칼럼의 NULL 허용 여부를 나타낸다.

칼럼 생성 시 사용자가 명시적으로 칼럼의 NULL 허용 여부를 명

시할 수 있으며 명시하지 않을 경우 기본 값은 NULL을 허용한

다.

DEFAULT_VAL

레코드 삽입 시 칼럼의 값을 명시하지 않을 경우 기본 칼럼 값을

나타낸다. 기본 값은 칼럼 생성 시 사용자가 명시해야 그 값이 설

정되고 사용자가 기본 값을 명시하지 않을 경우 NULL이 삽입된

다.

IS_VARING

칼럼을 물리적으로 저장할 때 레코드 내에 기록할 수도 있고, 레

코드 내에는 칼럼의 저장 위치 정보만을 가지고 실제 칼럼 값은

다른 페이지에 기록할 수도 있다.

한 칼럼의 물리적 저장 크기가 크거나 레코드별 칼럼의 저장 크

기 변동이 잦은 칼럼의 경우 칼럼 정의 시 VARIABLE 옵션을 사

용하면 레코드와 물리적으로 다른 페이지에 해당 칼럼을 저장하

도록 지정할 수 있다. 일반적으로 VARCHAR 타입의 경우 문자

열 길이가 긴 칼럼의 경우 이 옵션을 사용한다.

이 칼럼은 이러한 VARIABLE 옵션 지정 여부를 나타낸다.

IN_ROW_SIZE

메모리 테이블에 사용된 VARCHAR 타입 데이터의 기본 in row

size를 나타낸다. in row size는 VARCHAR 데이터 타입의 칼럼

에 데이터가 들어갈 때 데이터 길이가 이 값보다 작거나 같으

면 fixed 영역에 저장하고, 이 보다 긴 경우에는 variable 영역에

들어가도록 지정하는 속성이다. in row size나 VARCHAR 타입

에 대한 자세한 사항은 SQL User’s Manual의 데이터 타입 부분

을 참조한다. 디스크 테이블의 경우 이 값은 0이다 .

참조 테이블 SYS_USERS_

SYS_TABLES_


SYS_CONSTRAINTS_ 테이블의 제약 조건에 관한 정보를 포함하는 메타 테이블이다.

Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 CONSTRAINT_ID INTEGER 제약조건 식별자 CONSTRAINT_NAME VARCHAR(40) 제약조건 이름 CONSTRINT_TYPE INTEGER 제약조건 타입 INDEX_ID INTEGER 제약조건의 인덱스 식별자 COLUMN_CNT INTEGER 제약조건의 칼럼 개수 REFERENCED_TABLE_ID INTEGER parent table의 식별자 REFERENCED_INDEX_ID INTEGER 관련된 제약 조건 식별자

칼럼 정보 USER_ID

사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동

일하다.

TABLE_ID

제약 조건을 정의한 테이블 식별자로 SYS_TABLES_ 메타 테이

블의 TABLE_ID 값과 동일하다.

CONSTRAINT_ID

제약 조건 식별자로 시스템 시퀀스에 의해 자동으로 부여되는 식

별자이다.

CONSTRAINT_NAME

제약 조건의 이름이다.

CONSTRAINT_TYPE

제약조건의 타입을 나타내는 값으로 종류는 다음과 같다.

0: FOREIGN KEY

1: NOT NULL

2: UNIQUE

3: PRIMARY KEY

4: NULL

5: TIMESTAMP

각 제약 조건의 기능에 대한 설명은 SQL Users Manual을 참조

한다.


INDEX_ID

UNIQUE 또는 PRIMARY KEY 제약 조건과 같이 제약조건의 정

의가 인덱스 생성을 필요로 할 때 시스템 내부적으로 인덱스를

생성하게 되고 이때 생성한 인덱스의 식별자로 SYS_INDICES_

메타 테이블의 INDEX_ID 값과 동일하다.

COLUMN_CNT

제약 조건과 관련된 칼럼들의 개수를 나타낸다. 예를 들어

UNIQUE (i1,i2,i3) 과 같은 제약 조건을 생성하였다면 이 값은 3

이된다.

REFERENCED_TABLE_ID

참조 제약조건(Foreign key)의 경우 제약 조건을 정의하는 테이

블 외에 다른 테이블을 참조하므로 이 때 참조하는 테이블의 식

별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하

다.

REFERENCED_INDEX_ID

참조 제약조건의 경우 참조하는 테이블에 UNIQUE 또는

PRIMARY KEY 제약조건이 존재해야 하는데, 이 제약조건의 식

별자 값으로 SYS_CONSTRAINTS_ 메타 테이블의

CONSTRAINT_ID 값과 동일하다.


SYS_TABLES_

SYS_INDICES_


SYS_CONSTRAINT_COLUMNS_ 사용자 테이블에 정의된 모든 제한조건에 걸려있는 칼럼의 정보

를 기록하고 있는 메타 테이블이다.

Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 CONSTRAINT_ID INTEGER 제약조건 식별자 CONSTRAINT_COL_ORDER INTEGER 제약 조건 칼럼 순서 COLUMN_ID INTEGER 칼럼 식별자



일하다.

TABLE_ID

제약조건을 정의한 테이블의 식별자로 SYS_TABLES_ 메타 테이


CONSTRAINT_ID

칼럼의 해당 제약조건의 식별자로 SYS_CONSTRAINTS_ 메타

테이블의 CONSTRAINT_ID 값과 동일하다.

CONSTRAINT_COL_ORDER

제약조건 내 칼럼의 정의 순서이다. 예를 들어 UNIQUE (i1, i2,

i3)과 같은 제약조건을 생성할 경우

SYS_CONSTRAINT_COLUMNS_ 메타 테이블에는 3개의 레코드

가 삽입된다. 이 때 i1에 대해서는 1, i2에 대해서는 2, i3에 대해

서는 3이 각각 기록된다.

COLUMN_ID

제약조건에 정의된 칼럼의 식별자로 SYS_COLUMNS_ 메타 테이

블의 COLUMN_ID 값과 동일하다.


SYS_TABLES_

SYS_CONSTRAINTS_


SYS_COLUMNS_


SYS_DATABASE_ 데이터베이스 이름과 메타 버전 정보를 기록하는 테이블이다.

Column name Type Description DB_NAME VARCHAR(40) 데이터베이스 이름 META_MAJOR_VER INTEGER 데이터베이스 메타 테이블 버전 (주) META_MINOR_VER INTEGER 데이터베이스 메타 테이블 버전 (부) META_PATCH_VER INTEGER 데이터베이스 메타 테이블 버전 (패치)

칼럼 정보 DB_NAME

현재 알티베이스가 단일 데이터베이스 만을 지원하기 때문에 데

이터베이스 이름은 저장되지 않는다.

META_MAJOR_VER

메타 테이블의 베이스가 변경될 경우 증가하는 값으로, 데이터베

이스의 이 버전과 알티베이스 바이너리의 해당 버전이 일치하지

않은 경우 데이터베이스 마이그레이션 작업을 요한다.

META_MINOR_VER

메타 테이블의 일부 스키마 또는 레코드 값이 변경될 경우 증가

하는 값으로 데이터베이스의 이 버전과 알티베이스의 해당 버전

이 다른 경우 내부적으로 값을 비교해 상위 버전으로 메타 테이

블에 대해 자동 업그레이드를 수행한다.

META_PATCH_VER

메타 테이블 패치 버전으로 현재 이 값은 사용하지 않는다.


SYS_DIRECTORIES_ 저장프로시저 내의 파일 제어를 위한 디렉토리 정보를 기록하는

테이블이다.

Column name Type Description DIRECTORY_ID BIGINT 디렉토리 식별자 USER_ID INTEGER 사용자 식별자 DIRECTORY_NAME VARCHAR(40) 디렉토리 이름 DIRECTORY_PATH VARCHAR(4000) 시스템 내 디렉토리의 절대 경로

칼럼 정보 DIRECTORY_ID

디렉토리 식별자로 시스템 내 유일값을 가진다.

USER_ID

디렉토리 소유자의 사용자 식별자를 나타낸다.

DIRECTORY_NAME

디렉토리 이름으로 시스템 내 유일값을 가진다.

DIRECTORY_PATH

디렉토리가 저장된 시스템 내 절대 경로로 CREATE

DIRECTORY문 수행 시 사용자가 명시적으로 지정한다.


SYS_GRANT_OBJECT_ 사용자에게 부여된 객체 권한 정보를 포함한다

Column name Type Description GRANTOR_ID INTEGER 권한 부여자의 식별자 GRANTEE_ID INTEGER 권한 피수여자의 식별자 PRIV_ID INTEGER Privilege 식별자 USER_ID INTEGER 객체 소유자의 식별자 OBJ_ID INTEGER 객체 식별자 OBJ_TYPE CHAR(1) 객체 타입

WITH_GRANT_OPTION INTEGER

객체 접근 권한 부여시 WITH GRANT OPTION의 사용 유무 0: 사용 안 함 1: 사용

칼럼 정보 GRANTOR_ID

권한을 부여한 사용자의 사용자 식별자로 SYS_USERS_ 메타 테

이블의 USER_ID 값과 동일하다.

GRANTEE_ID

권한을 부여받은 사용자의 사용자 식별자로 SYS_USERS_ 메타

테이블의 USER_ID 값과 동일하다.

PRIV_ID

권한 식별자로 SYS_PRIVILEGES_ 메타 테이블의 PRIV_ID 값과

동일하다.

USER_ID

해당 권한과 관련된 객체 소유자의 사용자 식별자로

SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다.

OBJ_ID

해당 권한과 관련된 객체의 식별자이다.

OBJ_TYPE

해당 권한과 관련된 객체의 종류를 나타내는 값이다.

T: 테이블

S: 시퀀스

P: 저장 프로시저 또는 저장 함수

V: 뷰


WITH_GRANT_OPTION

권한 피수여자가 다른 사용자에게 해당 권한을 부여할 수 있는

권한이 있는지 여부를 나타낸다.


SYS_PRIVILEGES_

SYS_TABLES_

SYS_PROCEDURES_


SYS_GRANT_SYSTEM_ 사용자에게 부여된 시스템 권한 정보를 포함한다.

Column name Type Description GRANTOR_ID INTEGER 권한 부여자의 식별자 GRANTEE_ID INTEGER 권한 피수여자의 식별자 PRIV_ID INTEGER 권한 식별자

칼럼 정보 GRANTOR_ID

권한을 부여한 사용자의 사용자 식별자로 SYS_USERS_ 메타 테


GRANTEE_ID

권한을 부여받은 사용자의 사용자 식별자로 SYS_USERS_ 메타

테이블의 USER_ID 값과 동일하다.

PRIV_ID

권한 식별자로 SYS_PRIVILEGES_ 메타 테이블의 PRIV_ID 값과

동일하다.


SYS_PRIVILEGES_


SYS_INDEX_COLUMNS_ 사용자 테이블에 정의된 모든 인덱스에 걸려있는 칼럼의 정보를

기록하고 있는 메타 테이블이다.

Column name Type Description USER_ID INTEGER 사용자 식별자 INDEX_ID INTEGER 인덱스 번호 COLUMN_ID INTEGER 칼럼의 식별자 INDEX_COL_ORDER INTEGER 인덱스 칼럼 순서 SORT_ORDER CHAR(1) 인덱싱 순서 TABLE_ID INTEGER 테이블 식별자


인덱스 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의

USER_ID 값과 동일하다.

INDEX_ID

인덱스 식별자로 SYS_INDICES_ 메타 테이블의 INDEX_ID 값과

동일하다.

COLUMN_ID

인덱스를 생성한 칼럼의 식별자로 SYS_COLUMNS_ 메타 테이블

의 COLUMN_ID 값과 동일하다.

INDEX_COL_ORDER

복합 인덱스(composite index)의 경우 여러 개의 칼럼에 한 인덱

스를 생성하므로 이 때 해당 칼럼이 인덱스의 몇 번째 칼럼인지

를 나타내는 값이다.

SORT_ORDER

인덱싱 순서로 오름차순 또는 내림차순을 나타낸다.

A: 오름차순

D: 내림차순

TABLE_ID

인덱스를 생성한 테이블의 식별자로 SYS_TABLES_ 메타 테이블

의 TABLE_ID 값과 동일하다.

참조 테이블


SYS_USERS_

SYS_TABLES_

SYS_COLUMNS_

SYS_INDICES_


SYS_INDICES_ 사용자 테이블에 정의된 모든 인덱스 정보를 기록하고 있는 메타

테이블이다.

Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 INDEX_ID INTEGER 인덱스 번호 INDEX_NAME VARCHAR(40) 인덱스 이름 INDEX_TYPE INTEGER 인덱스 타입 IS_UNIQUE CHAR(1) 중복 키 값 허용 여부 COLUMN_CNT INTEGER 인덱스 칼럼 개수 IS_RANGE CHAR(1) 범위 검색 가능 여부 IS_PERS CHAR(1) 인덱스 영구 저장 여부 TBS_ID INTEGER 테이블스페이스 식별자


인덱스 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의


TABLE_ID

인덱스를 생성한 테이블의 테이블 식별자로 SYS_TABLES_ 메타

테이블의 TABLE_ID 값과 동일하다.

INDEX_ID

인덱스 식별자로 시스템 시퀀스에 의해 자동으로 부여되는 식별

자이다.

INDEX_NAME

인덱스의 이름이다.

INDEX_TYPE

인덱스 타입으로 1이면 B-TREE 인덱스 타입이고 2이면 R-

TREE 인덱스 타입이다.

IS_UNIQUE

중복 키 값 허용여부를 나타낸다.

T: 중복 키 값을 허용하지 않는다.

F: 중복 키 값을 허용한다.

COLUMN_CNT


인덱스 키 칼럼의 개수를 나타낸다.

IS_RANGE

범위 검색 가능 여부를 나타낸다.

T: 범위 검색 가능

F: 범위 검색 불가능

IS_PERS

서버 구동 시 테이블로부터 데이터를 읽어 모든 인덱스를 구축하

는데, 서버 종료 시 인덱스를 디스크에 저장하고 서버 재 구동 시 디스크에 저장된 인덱스 파일로부터 인덱싱 정보를 바로 읽어 서버 구동 시 인덱스 구축 비용을 절약할 수 있다. 디스크에 인덱스 파일을 저장하는 인덱스를 영구 인덱스라고 하고 인덱스 생성 시 사용자가 이를 명시할 수 있다.

T: 영구 인덱스

F: 비영구 인덱스

TBS_ID

인덱스가 저장되는 테이블스페이스의 식별자


SYS_TABLES_


SYS_PRIVILEGES_ 알티베이스가 지원하는 권한의 종류 정보를 기록하는 메타 테이

블로 권한에 대한 자세한 설명은 데이터베이스 권한 관리 또는

SQL Users Manual의 GRANT문 설명을 참조한다.

Column name Type Description PRIV_ID INTEGER 권한 식별자 PRIV_TYPE INTEGER 권한 타입 PRIV_NAME VARCHAR(40) 권한 이름

칼럼 정보 PRIV_ID

권한 식별자로 시스템이 내부적으로 정의한 값이다.

PRIV_TYPE

권한의 타입을 나타내는 값으로 1인 경우 객체 권한을 나타내고

2인 경우 시스템 권한을 나타낸다.

PRIV_NAME

권한의 이름이다.


SYS_PROCEDURES_ 사용자가 정의한 저장 프로시저와 저장 함수들에 대한 정보로 저

장 프로시저 이름, 리턴 타입, 파라미터 개수, 실행 가능 여부 등

을 기록하는 테이블이다.

Column name Type Description USER_ID INTEGER 저장 프로시저 소유자 식별자 PROC_OID BIGINT 저장 프로시저 식별자 PROC_NAME VARCHAR(40) 저장 프로시저 이름

OBJECT_TYPE INTEGER 저장 프로시저, 저장 함수, 타입세트인지를 구별

STATUS INTEGER 0: VALID 1: INVALID

PARA_NUM INTEGER 저장 프로시저 파라미터 개수 RETURN_DATA_TYPE INTEGER 저장 함수의 리턴 데이터 타입 RETURN_LANG_ID INTEGER 리턴 타입 언어 식별자 RETURN_SIZE INTEGER 저장 함수의 리턴 데이터 타입 크기

RETURN_PRECISION INTEGER 저장 함수의 리턴 데이터 타입 precision

RETURN_SCALE INTEGER 저장 함수의 리턴 데이터 타입 scale

PARSE_NO INTEGER SYS_PROC_PARSE_에 저장된 구문 정

보 레코드 수

PARSE_LEN INTEGER SYS_PROC_PARSE_에 저장된 구문 전

체 길이 CREATED DATE 저장 프로시저를 생성한 날짜

LAST_COMPILED DATE 저장 프로시저를 마지막으로 컴파일 한 날짜


저장 프로시저 또는 저장 함수 소유자의 사용자 식별자로


PROC_OID

저장 프로시저 또는 저장 함수의 식별자로 시스템에 의해 자동으

로 부여되는 식별자이다.

PROC_NAME

저장 프로시저 또는 저장 함수의 이름이다.

OBJECT_TYPE

저장 프로시저와 저장 함수를 구별하는 값으로 저장 함수는 저장

프로시저와 달리 하나의 리턴 값을 가진다.


0:저장 프로시저

1:저장 함수

3: 타입 세트

STATUS

저장프로시저 또는 함수의 실행 가능 여부를 나타내는 값으로 이

값이 0(VALID)이어야 실행가능하다.

저장 프로시저 또는 저장 함수가 접근하는 객체에 대한 DDL문을

수행하면 관련 저장 프로시저 또는 저장 함수는 무효한 상태가

된다. 예를 들어 저장 프로시저가 접근하는 테이블에 새로운 칼럼

이 추가되면 관련 저장 프로시저는 재 컴파일 후 VALID 상태가

되면 실행할 수 있다.

0:VALID

1:INVALID

PARA_NUM

저장 프로시저 또는 저장 함수의 정의된 파라미터 개수를 나타낸

다.

RETURN_DATA_TYPE

저장 함수의 리턴값에 대한 데이터 타입의 식별자로 데이터타입

별 식별자 값은 SYS_COLUMNS_ 메타 테이블의 DATA_TYPE

칼럼 설명을 참조한다.


다.

RETURN_LANG_ID


럼이다.

RETURN_SIZE

데이터 타입의 물리적 크기이다.

RETURN_PRECISION




RETURN_SCALE


타입의 스켈이다. 타입에 따라 이 값은 사용하지 않을 수 있으며

데이터 타입의 프리시즌과 스케일에 대한 상세한 내용은 SQL Users Manual을 참조한다.

PARSE_NO


저장 프로시저 또는 저장 함수 구문은 SYS_PROC_PARSE_ 메타

테이블에 나눠져 여러 레코드로 저장되는데 저장하는 레코드의

수를 나타내는 값이다.

PARSE_LEN

저장 프로시저 또는 저장 함수 구문은 SYS_PROC_PARSE_ 메타

테이블에 나눠져 여러 레코드로 저장되는데 저장하는 전체 구문

의 문자열 길이이다.



SYS_PROC_PARAS_ 사용자가 정의한 저장 프로시저와 저장 함수들의 인자

(parameter)들에 대한 정보를 기록하는 테이블이다.

Column name Type Description USER_ID INTEGER 저장 프로시저 소유자 식별자 PROC_OID BIGINT 저장 프로시저 식별자 PARA_NAME VARCHAR(40) 파라미터 이름

PARA_ORDER INTEGER 파라미터의 순서로 첫번째 파라미터의

경우 1을 가짐 INOUT_TYPE INTEGER 파라미터의 입력, 출력, 입출력 여부 DATA_TYPE INTEGER 파라미터의 데이터 타입 LANG_ID INTEGER 파라미터 타입 언어 식별자 SIZE INTEGER 파라미터 타입 size PRECISION INTEGER 파라미터 타입 precision SCALE INTEGER 파라미터 타입 scale DEFAULT_VAL VARCHAR(4000) 파라미터의 기본 값




PROC_OID

저장 프로시저 또는 저장 함수의 식별자로 SYS_PROCEDURES_

메타 테이블의 PROC_OID 값과 동일하다.

PARA_NAME

파라미터의 이름이다.

PARA_ORDER

여러 파라미터들 중 해당 파라미터가 몇번째 정의된 파라미터인

지를 나타내는 값이다.

INOUT_TYPE

저장 프로시저 또는 저장 함수의 파라미터는 입력인자, 출력인자,

입출력인자로 정의할 수 있는데 이를 나타내는 값이다.

0: IN

1: OUT

2: IN OUT

DATA_TYPE


파라미터 데이터 타입의 식별자로 데이터타입 별 식별자 값은

SYS_COLUMNS_ 메타 테이블의 DATA_TYPE 칼럼 설명을 참조

한다.


다.

LANG_ID


럼이다.

SIZE

데이터 타입의 물리적 크기이다.

PRECISION




SCALE


타입의 스케일이다. 타입에 따라 이 값은 사용하지 않을 수 있으

며 데이터 타입의 프리시즌과 스케일에 대한 상세한 내용은 SQL Users Manual을 참조한다.

DEFAULT_VAL

파라미터 정의 시 사용자가 지정하는 파라미터 기본 값이다.


SYS_PROCEDURES_


SYS_PROC_PARSE_ 사용자가 정의한 저장 프로시저와 저장 함수들의 파싱할 텍스트

정보를 기록하는 테이블이다.

Column name Type Description USER_ID INTEGER 저장 프로시저 또는 저장 함수의 소유자 식별자 PROC_OID BIGINT 저장 프로시저 객체 식별자 SEQ_NO INTEGER 나뉘어 저장된 구문 레코드의 순서 PARSE VARCHAR(100) 저장 프로시저 또는 저장 함수의 구문


저장 프로시저 소유자의 사용자 식별자로 SYS_USERS_ 메타 테


PROC_OID



SEQ_NO

한 저장 프로시저의 구문 정보를 SYS_PROC_PARSE_에 여러 개

의 레코드로 저장할 때 이들 레코드의 순서이다.

PARSE

저장 프로시저 또는 저장 함수 구문의 문자열이다. 한

PROC_OID 값으로 레코드들을 검색하여 SEQ_NO 순서대로

PARSE 값을 합치면 저장 프로시저 전체 구문을 생성할 수 있다.


SYS_PROCEDURES_


SYS_PROC_RELATED_ 사용자가 정의한 저장 프로시저와 저장 함수들이 접근하는 테이

블, 시퀀스, 저장 프로시저, 저장 함수, 또는 뷰들에 대한 정보를

기록하는 테이블이다.

Column name Type Description USER_ID INTEGER 저장 프로시저 소유자 식별자 PROC_OID BIGINT 저장 프로시저 내 객체 식별자

RELATED_USER_ID INTEGER 저장 프로시저 내 객체 사용자 식별자

RELATED_OBJECT_NAME VARCHAR(40) 저장 프로시저 내 객체 이름

RELATED_OBJECT_TYPE INTEGER 저장 프로시저가 접근하는 객체의 타입

저장프로시저 PROC1이 테이블 t1에 INSERT 작업을 수행하는

저장프로시저일 경우 PROC1의 소유자 식별자와 저장프로시저

식별자가 각각 USER_ID와 PROC_OID에 저장되고, 테이블 t1의

소유자 ID와 테이블 이름은 각각 RELATED_USER_ID,

RELATED_OBJECT_NAME에 저장되며,

RELATED_OBJECT_TYPE에는 TABLE임을 명시하게 된다.




PROC_OID



RELATED_USER_ID

저장프로시저가 접근하는 객체 소유자의 사용자 식별자로


RELATED_OBJECT_NAME

저장프로시저가 접근하는 객체

RELATED_OBJECT_TYPE

저장프로시저가 접근하는 객체의 타입이다.

저장프로시저가 접근하는 객체의 종류로는 테이블,시퀀스,뷰 또는

다른 저장 프로시저와 저장 함수가 가능하다.

0: 저장 프로시저 또는 저장 함수


2: 테이블, 시퀀스, 뷰


SYS_PROCEDURES_

SYS_TABLES_


SYS_REPLICATIONS_ 이중화 관련 정보를 기록하고 있는 메타 테이블이다.

Column name Type Description REPLICATION_NAME VARCHAR(40) 이중화 이름 LAST_USED_HOST_NO INTEGER 가장 최근에 사용한 원격 서버 HOST_COUNT INTEGER 원격 서버 개수 IS_STARTED INTEGER 이중화 시작 여부

XLSN_FILE_NO INTEGER 원격 서버에 마지막으로 전송한 로그 파일번호

XLSN INTEGER 송신자의 전송시작 SN ITEM_COUNT INTEGER 이중화 대상 테이블 개수 CONFLICT_RESOLUTION INTEGER 이중화 Conflict Resolution 방법

칼럼 정보 REPLICATION_NAME

사용자가 이중화 생성 시 명시한 이중화 이름이다.

LAST_USED_HOST_NO

가장 최근에 사용한 원격 서버의 번호로 SYS_REPL_HOSTS_ 메

타 테이블의 HOST_NO 값과 동일하다.

HOST_COUNT

이중화를 실행하는 원격 서버의 개수로 SYS_REPL_HOSTS_ 에

있는 IP의 개수와 동일하다.

IS_STARTED

이중화 시작 여부를 나타낸다.

0: 중지

1: 이중화 수행 중

XLSN_FILE_NO

원격 서버에 마지막으로 전송한 로그의 파일 번호를 기록한다.

XLSN

리플리케이션이 시작되었을 때, Sender Threadp서 전송 시작해

야 할 로그의 일련번호를 나타낸다.

ITEM_COUNT

이중화 대상 테이블의 개수로 이 수만큼 해당 이중화에 대해

SYS_REPL_ITEMS_ 메타 테이블의 레코드들이 존재한다.


CONFLICT_RESOLUTION

이중화 Conflict Resolution 방법을 기록한다.

0: 기본 값

1: Master Server로 동작

2: Slave Server로 동작

이중화 Conflict Resolution 방법의 종류에 각 방법별 자세한 기

능은 Replication Users Manual을 참조한다.


SYS_REPL_HOSTS_ 원격 서버에 관련된 정보를 가진 메타 테이블이다.

Column name Type Description HOST_NO INTEGER 일련 번호 REPLICATION_NAME VARCHAR(40) 이중화 이름 HOST_IP VARCHAR(40) 원격 서버 IP 주소 PORT_NO INTEGER 원격 서버 이중화 포트 번호

칼럼 정보 HOST_NO

원격 서버의 일련 번호로 시스템 시퀀스에 의해 자동으로 부여된

다.

REPLICATION_NAME

사용자가 명시한 이중화 이름으로 SYS_REPLICATIONS_ 메타

테이블의 REPLICATION_NAME 값과 동일하다.

HOST_IP

원격 서버의 IP 주소를 기록한다.

PORT_NO

원격 서버의 이중화 포트 번호를 기록한다.

참조 테이블 SYS_REPLICATIONS_


SYS_REPL_ITEMS_ 이중화 대상 테이블에 관련된 정보를 가진 메타 테이블이다.

Column name Type Description REPLICATION_NAME VARCHAR(40) 이중화 이름 TABLE_OID BIGINT 테이블 객체 식별자 LOCAL_USER_NAME VARCHAR(40) 지역 서버 사용자 이름 LOCAL_TABLE_NAME VARCHAR(40) 지역 서버 테이블 이름 REMOTE_USER_NAME VARCHAR(40) 원격 서버 사용자 이름 REMOTE_TABLE_NAME VARCHAR(40) 원격 서버 테이블 이름

한 이중화는 여러 개의 테이블들에 대해 이중화가 가능하다. 따라

서 한 이중화가 10개의 테이블에 대한 이중화를 수행한다면 이

메타 테이블에 이 이중화에 대해 총 10개의 레코드가 존재한다.

칼럼 정보 REPLICATION_NAME

사용자가 명시한 이중화 이름으로 SYS_REPLICATIONS_ 메타

테이블의 REPLICATION_NAME 값과 동일하다.

TABLE_OID

이중화 대상 테이블의 식별자로 SYS_TABLES_ 메타 테이블의

TABLE_OID 값과 동일하다.

LOCAL_USER_NAME

지역 서버의 이중화 대상 테이블 소유자의 사용자 이름으로

SYS_USERS_ 메타 테이블의 USER_NAME 값과 동일하다.

LOCAL_TABLE_NAME

지역 서버의 이중화 대상 테이블의 이름으로 SYS_TABLES_ 메

타 테이블의 TABLE_NAME 값과 동일하다.

REMOTE_USER_NAME

원격 서버의 이중화 대상 테이블 소유자의 사용자 이름으로 원격

서버의 SYS_USERS_ 메타 테이블의 USER_NAME 값과 동일하

다.

REMOTE_TABLE_NAME

원격 서버의 이중화 대상 테이블의 이름으로 원격 서버의

SYS_TABLES_ 메타 테이블의 TABLE_NAME 값과 동일하다.

참조 테이블


SYS_REPLICATIONS_

SYS_USERS_

SYS_TABLES_


SYS_SYNONYMS_ 데이터베이스 객체에 대한 별칭 기능을 하는 시노님에 대한 정보

를 기록하는 테이블이다.

Column name Type Description USER_ID INTEGER 사용자 식별자 SYNONYM_NAME VARCHAR(40) 시노님 이름 SCHEMA_NAME VARCHAR(40) 객체 소유자 이름 SYNONYM_OBJECT_NAME VARCHAR(40) 시노님 대상 객체 이름


시노님 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의


SYNONYM_NAME

사용자가 명시한 시노님 이름이다.

SCHEMA_NAME

사용자가 명시한 시노님 대상 객체가 소속된 스키마 소유자의 이

름이다.

SYNONYM_OBJECT_NAME

사용자가 명시한 시노님 대상 객체의 이름이다.



SYS_TABLES_ 메타 테이블들과 사용자가 정의한 테이블, 시퀀스 그리고 뷰에 대

한 정보를 기록하는 테이블이다.

Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 TABLE_OID BIGINT 테이블 객체 식별자 COLUMN_COUNT INTEGER 테이블 칼럼의 개수 TABLE_NAME VARCHAR(40) 테이블 이름 TABLE_TYPE CHAR(1) 객체 타입 REPLICATION_COUNT INTEGER 테이블과 관련된 replication 개수

MAXROW BIGINT 입력할 수 있는 최대 레코드 개수, 0: 제한 없음

TBS_ID INTEGER 테이블스페이스 식별자

INSERT_HIGH_LIMIT INTEGER 페이지에서 사용될 수 있는 최대한

의 공간 (백분율)

INSERT_LOW_LIMIT INTEGER 페이지에서 사용될 수 있는 최소한

의 공간 (백분율)


테이블 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의


TABLE_ID

테이블 식별자로 시스템 시퀀스에 의해 자동으로 부여되는 식별

자이다.

TABLE_OID

테이블 식별자로 시스템 내부에서 자동으로 부여되는 식별자로

사용자가 메타 테이블 조회 시 사용하는 TABLE_ID와는 달리 시

스템 내부 동작 시에만 사용하는 식별자이다.

COLUMN_COUNT

테이블에 정의된 칼럼의 개수이다.

TABLE_NAME

사용자가 명시한 테이블 이름이다.

TABLE_TYPE

SYS_TABLES_ 메타 테이블에는 테이블 외에 시퀀스, 뷰 정보도

함께 저장된다. 따라서 이들 객체를 구별하기 위한 타입이다.


T: 테이블

S: 시퀀스

V: 뷰

REPLICATION_COUNT

해당 테이블과 관련된 이중화의 개수이다.

MAXROW

테이블에 삽입가능한 최대 레코드 수이다.

TBS_ID

테이블이 저장되는 테이블스페이스의 식별자이다.

INSERT_HIGH_LIMIT

1에서 100사이의 값으로 CREATE TABLE문 정의 시 사용자가

명시하는 INSERT HIGH LIMIT 값을 저장한다.

INSERT_LOW_LIMIT

1에서 100사이의 값으로 CREATE TABLE문 정의 시 사용자가

명시하는 INSERT LOW LIMIT 값을 저장한다.

INSERT HIGH LIMIT과 INSERT LOW LIMIT에 대한 자세한 설

명은 SQL Users Manual의 CREATE TABLE문 설명을 참조한다.



SYS_TBS_USERS_ 사용자가 정의한 사용자의 테이블스페이스에 관한 정보를 기록하

는 테이블이다.

Column name Type Description TBS_ID INTEGER 테이블스페이스 식별자 USER_ID INTEGER 사용자 식별자 IS_ACCESS INTEGER 테이블스페이스 접근 허용 여부

칼럼 정보 TBS_ID

테이블스페이스 식별자이다.

USER_ID


일하다.

IS_ACCESS

사용자가 해당 테이블스페이스에 접근 가능한지를 나타낸다.

0: 접근불가

1: 접근가능



SYS_TRIGGERS_ 트리거의 기본 정보를 저장하는 메타 테이블이다.

Column name Type Description USER_ID INTEGER 사용자 식별자 USER_NAME VARCHAR(40) 사용자 이름 TRIGGER_OID BIGINT 트리거 식별자 TRIGGER_NAME VARCHAR(40) 트리거 이름 TABLE_ID INTEGER 테이블 식별자 IS_ENABLE INTEGER 트리거 수행 여부 EVENT_TIME INTEGER 이벤트 구분 EVENT_TYPE INTEGER 트리거 이벤트 타입 UPDATE_COLUMN_CNT INTEGER UPDATE 이벤트의 칼럼 개수 GRANULARITY INTEGER 트리거 수행 단위 구분 REF_ROW_CNT INTEGER REFERENCING 구문의 ALIAS 개수 SUBSTRING_CNT INTEGER 트리거 구문 저장 레코드 수 STRING_LENGTH INTEGER 트리거 구문 전체 문자열 길이



일하다.

USER_NAME

사용자 이름으로 SYS_USERS_ 메타 테이블의 USER_NAME 값

과 동일하다.

TRIGGER_OID

트리거 식별자로 시스템에 의해 자동으로 부여되는 값이다.

TRIGGER_NAME

사용자가 명시한 트리거 이름이다.

TABLE_ID

트리거가 참조하는 테이블의 식별자로 SYS_TABLES_ 메타 테이


IS_ENABLE

트리거 수행 여부를 나타내는 값으로 ALTER TRIGGER문에 의

해 변경된다.

0:미수행

1:수행


EVENT_TIME

BEFORE 또는 AFTER 이벤트를 구분하는 값이다.

1:BEFORE

2:AFTER

EVENT_TYPE

트리거 이벤트의 타입을 나타낸다.

1:INSERT

2:DELETE

3:UPDATE

UPDATE_COLUMN_CNT

UPDATE 이벤트의 칼럼 수로

SYS_TRIGGER_UPDATE_COLUMNS_ 메타 테이블의 해당 트리

거를 위한 레코드 수와 동일하다.

GRANULARITY

FOR EACH ROW 또는 FOR EACH STATEMENT를 구분한다.

1: FOR EACH ROW

2: FOR EACH STATEMENT

REF_ROW_CNT

REFERENCING 구문에 정의된 ALIAS의 개수이다.

SUBSTRING_CNT

한 트리거 구문은 SYS_TRIGGER_STRINGS_ 메타 테이블에 나

눠져 여러 레코드로 저장되는데 저장하는 레코드의 수를 나타내

는 값이다.

STRING_LENGTH

트리거 구문의 전체 문자열 길이이다.


SYS_TABLES_


SYS_TRIGGER_DML_TABLES_ 트리거가 참조하고 접근하는 테이블의 정보를 저장하는 메타 테

이블이다.

Column name Type Description TABLE_ID INTEGER 테이블 식별자 TRIGGER_OID BIGINT 트리거 식별자 DML_TABLE_ID INTEGER 테이블 식별자 STMT_TYPE INTEGER 실행 구문 종류

칼럼 정보 TABLE_ID

트리거가 참조하는 테이블의 식별자로 SYS_TABLES_ 메타 테이


TRIGGER_OID

트리거 식별자로 SYS_TRIGGERS_ 메타 테이블의

TRIGGER_OID 값과 동일하다.

DML_TABLE_ID

트리거 바디(body)내에서 DML문으로 접근하는 테이블의 식별자

로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다.

STMT_TYPE

테이블에 수행하는 구문의 종류를 나타낸다.

8 : DELETE

17: INSERT

29: UPDATE

참조 테이블 SYS_TABLES_

SYS_TRIGGERS_


SYS_TRIGGER_STRINGS_ 트리거 구문을 저장하는 메타 테이블이다.

Column name Type Description TABLE_ID INTEGER 테이블 식별자 TRIGGER_OID BIGINT 트리거 식별자 SEQNO INTEGER 나뉘어 저장된 구문 레코드의 순서 SUBSTRING VARCHAR(100) 트리거 구문


테이블 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과

동일하다.

TRIGGER_OID



SEQNO

한 트리거의 구문 정보를 SYS_TRIGGER_STRINGS_에 여러 개

의 레코드로 저장할 때 이들 레코드의 순서이다.

SUBSTRING

트리거 구문의 문자열이다. 한 TRIGGER_OID 값으로 레코드들을

검색하여 SEQNO 순서대로 SUBSTRING 값을 합치면 트리거 전

체 구문을 생성할 수 있다.


SYS_TRIGGERS_


SYS_TRIGGER_UPDATE_COLUMNS_ 트리거의 UPDATE 이벤트문의 칼럼 정보를 저장하는 메타 테이

블이다.

Column name Type Description TABLE_ID INTEGER 테이블 식별자 TRIGGER_OID BIGINT 트리거 식별자 COLUMN_ID INTEGER 칼럼 식별자


테이블 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과

동일하다.

TRIGGER_OID



COLUMN_ID

칼럼 식별자로 SYS_COLUMNS_ 메타 테이블의 COLUMN_ID 값

과 동일하다.


SYS_TRIGGERS_


SYS_USERS_ 데이터베이스 사용자에 대한 정보를 기록하는 테이블이다. 여러

사용자에 대한 정보를 포함할 수 있다.

Column name Type Description USER_ID INTEGER 사용자 식별자 USER_NAME VARCHAR(40) 사용자 이름 PASSWORD VARCHAR(40) 사용자 패스워드 DEFAULT_TBS_ID INTEGER 디폴트 테이블스페이스 식별자 TEMP_TBS_ID INTEGER 임시 테이블스페이스 식별자


사용자 식별자로 시스템의 시퀀스에 의해 자동으로 부여되는 값

이다.

USER_NAME

사용자가 명시한 이름이다.

PASSWORD

사용자의 패스워드로 DES with MDS로 암호화 되어 있다.

DEFAULT_TBS_ID

사용자가 겍체 생성 시 테이블스페이스를 명시적으로 기술하지

않을 경우 사용하는 기본 테이블스페이스의 식별자이다.

TEMP_TBS_ID

사용자의 임시 테이블스페이스 식별자이다.


SYS_VIEWS_ 뷰에 대한 기본 정보는 SYS_TABLES_ 메타 테이블에 기록되고

그 외에 뷰의 부가 정보를 기록하는 메타 테이블이다.

Column name Type Description USER_ID INTEGER 뷰의 소유자 식별자 VIEW_ID INTEGER 뷰 식별자 STATUS INTEGER 뷰 상태


뷰 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의


VIEW_ID

뷰 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동

일하다.

STATUS

뷰 상태를 나타내는 값이다.

0:VALID

1:INVALID


SYS_TABLES_


SYS_VIEW_PARSE_ 사용자가 정의한 뷰의 구문 정보를 기록하는 테이블이다.

Column name Type Description USER_ID INTEGER 뷰의 소유자 식별자 VIEW_ID INTEGER 뷰 식별자

SEQ_NO INTEGER 파싱한 뷰 생성문 텍스트를 정보를

SYS_VIEW_PARSE_에 여러 개의 레코드로

저장할 때 이들 레코드의 순서 PARSE VARCHAR(100) 뷰 생성문 텍스트

칼럼 정보

USER_ID



VIEW_ID


일하다.

SEQ_NO

한 뷰의 구문 정보를 SYS_VIEW_PARSE_에 여러 개의 레코드로

저장할 때 이들 레코드의 순서이다.

PARSE

뷰 구문의 문자열이다. 한 VIEW_ID 값으로 레코드들을 검색하여

SEQ_NO 순서대로 PARSE 값을 합치면 뷰 전체 구문을 생성할

수 있다.


SYS_TABLES_


SYS_VIEW_RELATED_ 사용자가 정의한 뷰들이 접근하는 관련 객체에 대한 정보를 기록

하는 테이블이다.

Column name Type Description USER_ID INTEGER 뷰의 소유자 식별자 VIEW_ID INTEGER 뷰 식별자 RELATED_USER_ID INTEGER 뷰가 접근하는 객체의 소유자 식별자 RELATED_OBJECT_NAME VARCHAR(40) 뷰가 접근하는 객체의 이름 RELATED_OBJECT_TYPE INTEGER 뷰가 접근하는 객체의 타입




VIEW_ID


일하다.

RELATED_USER_ID

뷰가 접근하는 객체 소유자의 사용자 식별자로 SYS_USERS_ 메

타 테이블의 USER_ID 값과 동일하다.

RELATED_OBJECT_NAME

뷰가 접근하는 객체의 이름이다.

RELATED_OBJECT_TYPE

뷰가 접근하는 객체의 타입이다.

뷰가 접근하는 객체의 종류로는 테이블,시퀀스,뷰 또는 저장 프로

시저와 저장 함수가 가능하다.

0: 저장 프로시저 또는 저장 함수

2: 테이블, 시퀀스, 뷰


SYS_TABLES_

SYS_PROCEDURES_


성능 뷰 성능 뷰(performance view)란 알티베이스 시스템 내부의 정보,

즉 시스템 메모리, 프로세스 상태, 세션, 버퍼 등의 메모리 구조

를 일반 테이블 형태로 나타내어 사용자가 모니터링이 가능하도

록 해 주는 구조를 말한다.

성능 뷰는 알티베이스를 사용하는 사용자가 테이블에 저장된 데

이터를 검색하기 위하여 SQL을 사용하는 것처럼, 알티베이스 운

용 시 사용되는 메모리 객체(예, 세션 정보, 로그 정보)에 관한

정보를 SQL을 이용하여 검색함으로써 알티베이스를 운용하는데

있어 편의성을 제공한다.

이 절에서는 알티베이스가 지원하는 성능 뷰의 구조 및 기능, 조

회 방법, 종류, 그리고 각 뷰에서 나타나는 정보에 대해 설명한

다.

구조 및 기능 알티베이스 내부에는 사용자가 생성한 일반 데이타베이스 관련

테이블 뿐만 아니라 DBMS 운용에 필요한 프로세스 자체의 정보

를 다수 보유하고 있다.

특히, Altibase4의 경우 메모리 공간 외에도 디스크 공간에 대한

테이블 생성 및 조회가 가능한 하이브리드 형태이기 때문에 알티

베이스 자체에 대한 모니터링 기능이 필수적이라고 할 수 있다.

성능 뷰는 알티베이스 운용과정에서 사용되는 대부분의 내부 메

모리 구조체를 뷰 형태로 제공하며, 해당 테이블에 대한 조회를

하는 순간에 그 데이타가 실시간으로 생성되기 때문에 언제나 프

로세스 내부의 최신 정보를 얻을 수 있다.

또한, 성능 뷰는 언제나 읽기 전용 속성을 가진다. 만일 이 테이

블에 대한 변경 연산을 시도한다면, 알티베이스는 에러를 내고,

해당 트랜잭션에 대한 부분철회를 수행할 것이다.

조회 방법 성능 뷰의 전체 목록은 iSQL에서 SELECT * FROM V$TAB 명령

어를 이용해 다음과 같이 조회한다.

iSQL> SELECT * FROM V$TAB; TABLE NAME TYPE --------------------------------------------- V$ALLCOLUMN PERFORMANCE VIEW V$ARCHIVE PERFORMANCE VIEW V$BUFFPOOL_STAT PERFORMANCE VIEW V$DATABASE PERFORMANCE VIEW


V$DATAFILES PERFORMANCE VIEW V$DB_FREEPAGELISTS PERFORMANCE VIEW V$DISKGC PERFORMANCE VIEW V$DISKTBL_INFO PERFORMANCE VIEW V$FLUSHINFO PERFORMANCE VIEW V$INSTANCE PERFORMANCE VIEW V$LATCH PERFORMANCE VIEW V$LFG PERFORMANCE VIEW V$LOCK PERFORMANCE VIEW V$LOCK_STATEMENT PERFORMANCE VIEW V$LOCK_WAIT PERFORMANCE VIEW V$LOG PERFORMANCE VIEW V$MEMGC PERFORMANCE VIEW V$MEMSTAT PERFORMANCE VIEW V$MEMTBL_INFO PERFORMANCE VIEW V$MUTEX PERFORMANCE VIEW V$PROPERTY PERFORMANCE VIEW V$REPEXEC PERFORMANCE VIEW V$REPGAP PERFORMANCE VIEW V$REPRECEIVER PERFORMANCE VIEW V$REPSENDER PERFORMANCE VIEW V$SEQ PERFORMANCE VIEW V$SERVICE_THREAD PERFORMANCE VIEW V$SESSION PERFORMANCE VIEW V$SESSIONMGR PERFORMANCE VIEW V$STATEMENT PERFORMANCE VIEW V$TABLE PERFORMANCE VIEW V$TABLESPACES PERFORMANCE VIEW V$TRANSACTION PERFORMANCE VIEW V$TRANSACTION_MGR PERFORMANCE VIEW V$UNDO_BUFF_STAT PERFORMANCE VIEW V$VERSION PERFORMANCE VIEW 33 rows selected.

성능 뷰의 스키마는 일반 테이블과 같이 iSQL문에서 DESC 명령

어를 통해 확인할 수 있고, 데이터 조회는 일반 테이블과 동일하

게 SELECT문을 이용하여 검색할 수 있다.


성능 뷰의 종류 성능 뷰의 이름은 V$로 시작하며 종류는 다음과 같다.

Fixed Table Name Description V$ALLCOLUMN 성능 뷰를 구성하는 칼럼 정보 V$ARCHIVE 아카이브 관련 정보와 백업 정보 V$BUFFPAGEINFO 버퍼 메니저의 버퍼 프레임 통계 정보 V$BUFFPOOL_STAT 버퍼 풀 hit ratio를 비롯, 버퍼 풀 관련 통계 정보 V$DATABASE 메모리 데이터베이스 공간의 내부 정보 V$DATAFILES 테이블스페이스에서 사용하는 데이터 파일의 정보 V$DISKGC 디스크 공간 회수 (disk garbage collection) 정보 V$DISKTBL_INFO 디스크 테이블 정보 V$FLUSHINFO 버퍼 플러쉬 정보 V$INDEX 테이블의 인덱스 정보 V$INSTANCE 현재 알티베이스의 다단계 startup 정보

V$LATCH 버퍼 풀의 버퍼 제어 블록(BCB) latch 정보와 read or write가 try된 페이지에 대하여 read/ write latch에 대한 통계 정보

V$LFG 그룹커밋 관련 통계값

V$LOCK 현재 시점에서 데이터베이스의 모든 테이블 lock 노드 정보

V$LOCK_WAIT 트랜잭션의 락 대기 상태 정보 V$LOG 로그 앵커 정보 V$LOCK_STATEMENT Lock과 statement정보 V$MEMGC 메모리 공간 회수 (memory garbage collect) 정보 V$MEMTBL_INFO 메모리 테이블 정보

V$MEMSTAT 알티베이스 프로세스가 사용하는 메모리 통계 정보

V$MUTEX 알티베이스 프로세스에서 사용되고 있는 동시성 제어 관련 mutex 통계 정보

V$PLANTEXT SQL의 실행 계획 텍스트 정보 V$PROCTEXT 저장 프로시저의 텍스트 정보를 나타낸다 V$PROPERTY 알티베이스 내부에 설정된 프로퍼티 정보 V$REPEXEC 리플리케이션 관리자 정보

V$REPGAP 리플리케이션 송신자의 작업 로그 파일이 현재 생성된 최근 로그 파일간의 차이 정보

V$REPRECEIVER 리플리케이션 수신자 정보 V$REPRECEIVER_TRANSTBL 리플리케이션 송신자의 트랜잭션 테이블 정보 V$REPSYNC SYNC 중인 테이블의 정보 V$REPSENDER 리플리케이션 송신자 정보 V$REPSENDER_TRANSTBL 리플리케이션 수신자의 트랜잭션 테이블 정보 V$SEQ 시퀀스 관련 정보 V$SERVICE_THREAD Multiplexing 관련 서비스 쓰레드 정보 V$SESSION 알티베이스 내부에 생성된 클라이언트에 대한 세


션 정보 V$SESSIONMGR 알티베이스의 세션 통계 정보 V$STATEMENT 현재 알티베이스에 생성된 모든 세션의 구문 정보 V$SQLTEXT 시스템에서 수행되는 SQL의 텍스트 정보 V$TABLE 모든 성능 뷰의 레코드 및 칼럼 정보 V$TABLESPACES 테이블스페이스 정보 V$TRACELOG 트레이스 로깅 정보 V$TRANSACTION 트랜잭션 객체 정보 V$TRANSACTION_MGR 알티베이스 트랜잭션 관리자 정보 V$UNDO_BUFF_STAT Undo table space의 버퍼 풀 관련 통계 정보 V$VERSION 데이터베이스 버전 관련 정보


V$ALLCOLUMN 성능 뷰에 속한 칼럼의 정보를 나타낸다.

Column name Type Description TABLENAME VARCHAR(39) 성능 뷰 테이블의 이름 COLNAME VARCHAR(39) 성능 뷰 칼럼의 이름

칼럼 정보 TABLENAME

해당 성능 뷰 칼럼이 속한 테이블의 이름을 나타낸다.

COLNAME

현재 뷰 칼럼의 이름을 나타낸다.


V$ARCHIVE 아카이브 관련 정보와 백업 정보를 보여준다.

Column name Type Description ARCHIVE_MODE BIGINT 아카이브 로그 모드 ARCHIVE_THR_RUNNING BIGINT 아카이브 쓰레드 수행 여부

ARCHIVE_DEST VARCHAR(1024) 로그를 아카이브 하여 저장하는 디렉터리

NEXTLOGFILE_TO_ARCH INTEGER 다음 번에 아카이브 할 로그 번호

OLDEST_ACTIVE_LOGFILE INTEGER 온라인로그 중 가장 오래된 로그 파일 번호

CURRENT_LOGFILE INTEGER 현재 온라인로그 파일 번호

칼럼 정보 ARCHIVE_MODE

데이터베이스의 아카이브 로그 모드를 나타낸다.

0: 노(No) 아카이브 로그 모드

1: 아카이브 로그 모드


V$BUFFPAGEINFO 버퍼 관리자에서 관리되는 버퍼 프레임의 페이지 타입별 주요 연

산들에 대한 통계치를 보여준다.

Column name Type Description PAGE_TYPE INTEGER 페이지 타입 READ_PAGE_COUNT BIGINT DISK I/O (READ)를 유발한 횟수 WRITE_PAGE_COUNT BIGINT DISK I/O (WRITE)를 유발한 횟수 GET_PAGE_COUNT BIGINT 버퍼 프레임을 요구한 횟수 CREATE_PAGE_COUNT BIGINT 새로운 버퍼 프레임을 요구한 횟수

칼럼 정보 PAGE_TYPE

페이지 타입을 나타내며, 다음과 같은 페이지 타입을 갖는다.

0: 인덱스(INDEX) 페이지

1: 테이블(TABLE) 페이지

2: 이중 쓰기(DOUBLE_WRITE) 페이지

3: 외부(EXTERNAL) 페이지

4: 다중(MULTIPLE) 페이지

5: 임시(TEMP) 페이지

6: 세그먼트 디렉토리(SEGMENT_DIR) 페이지

7: 익스텐트 디렉토리(EXTENT_DIR) 페이지

8: 트랜잭션 상태 슬롯(TRANSACTION_STATUS_SLOT) 페이지

9: 언두(UNDO) 페이지

10: 메타 헤더(META_HEADER) 페이지

초기 버퍼 프레임은 어떠한 페이지 타입에도 속하지 않을 수 있

기 때문에, 이러한 버퍼 프레임의 페이지 타입은 0xFFFFFFFF

(-1)를 갖는다.

READ_PAGE_COUNT

서버 구동 이후부터 현재까지 PAGE_TYPE에 해당하는 버퍼 프

레임들에 DISK I/O (READ)를 유발시킨 총 횟수를 나타낸다.

0 이상의 값을 갖는다.


WRITE_PAGE_COUNT

서버 구동 이후부터 현재까지 PAGE_TYPE에 해당하는 버퍼 프

레임들에 DISK I/O (WRITE)를 유발시킨 총 횟수를 나타낸다.


GET_PAGE_COUNT

서버 구동 이후부터 현재까지 버퍼 관리자에게 데이터 쓰기나 읽

기 목적으로 PAGE_TYPE에 해당하는 버퍼 프레임들을 요구한

총 횟수를 나타낸다.


CREATE_PAGE_COUNT

서버 구동 이후부터 현재까지 버퍼 관리자에게 PAGE_TYPE에

해당하는 새로운 버퍼 프레임들을 요구한 총 횟수를 나타낸다.


예제)

서버 구동 이후 버퍼에서 관리해 온 페이지 타입별 주요 연산들

의 누적치를 확인한다.

iSQL> select * from v$buffpageinfo;

PAGE_TYPE READ_PAGE_COUNT WRITE_PAGE_COUNT GET_PAGE_COUNT -------------------------------------------------- ------------------------------ CREATE_PAGE_COUNT ----------------------- 0 279343 289787 6945332 0 1 3150167 131377 22953297 0 2 0 0 0 0 3 0 0 0 0 4 0 0 0 0 5 0 0 0 0 6 6 17 4240 1 7 273 331 53174


1 8 2 16 355591 0 9 1521 1737 426443 0 10 63 82 493305

1

11 rows selected.


V$BUFFPOOL_STAT 버퍼 풀 hit ratio를 포함하여, 버퍼 풀 관련 통계 정보를 보여준

다. (정확한 hit ratio를 구하기 위하여, undo table space관련 정

보는 제외함.)

Column name Type Description MAX_SIZE INTEGER 버퍼 풀 최대 크기 CURR_SIZE INTEGER 버퍼 풀 현재 크기 FREE_LIST_COUNT INTEGER Free list BCB 개수 LRU_LIST_COUNT INTEGER Used list BCB 개수 FLUSH_LIST_COUNT INTEGER Flush list BCB 개수 READY_COUNT INTEGER Ready 상태의 BCB 개수

READ_PAGE_COUNT BIGINT 디스크에서 버퍼로 read한 페이지

의 개수

WRITE_PAGE_COUNT BIGINT 버퍼에서 디스크로 write한 페이지

의 개수

GET_PAGE_COUNT BIGINT 서버가 버퍼 관리자에게 페이지를 요청한 횟수

CREATE_PAGE_COUNT BIGINT 서버가 버퍼 관리자에게 페이지 생성을 요청한 횟수

칼럼 정보 MAX_SIZE

버퍼 풀의 최대 크기를 나타낸다. 이 크기 이상 버퍼 풀을 늘릴

수 없다.

CURR_SIZE

현재 버퍼 풀의 크기를 나타낸다. 이 크기 이상 데이터를 버퍼에

올릴 수 없다. 더 큰 데이터를 버퍼에 올리고자 할 때 내부적으로

공간 확보를 위해 일부 페이지를 디스크에 내린다.

FREE_LIST_COUNT

현재 버퍼 풀에서 사용 가능한 버퍼 제어 블록(BCB)의 개수를

나타낸다. 즉, 버퍼 풀에 올릴 수 있는 페이지의 개수를 의미한

다. 이 값 * 페이지 크기가 버퍼 풀의 빈 공간의 크기이다.

LRU_LIST_COUNT

현재 버퍼 풀에서 사용 중인 BCB의 개수를 나타낸다. 즉, 버퍼에

올라와 있는 페이지의 개수를 의미한다. 이 값 * 페이지 크기가

버퍼 풀의 현재 사용중인 크기이다.

FLUSH_LIST_COUNT


현재 버퍼 풀에서 사용 중인 BCB 중 디스크에 플러쉬 해야 하는

BCB의 개수를 나타낸다. 즉, 버퍼에 올라와 있는 페이지 중 수정

되어 디스크에 반영해야 할 페이지의 개수를 의미한다. 이 값 *

페이지 크기가 현재 버퍼 풀에 올라온 페이지 중 디스크에 반영

할 필요가 있는 페이지이다. 이 페이지들은 체크포인트 시에 일부

디스크에 반영되며, 버퍼 replacement 시 일부 반영된다.

READY_COUNT

현재 버퍼 풀에서 사용 중 -> 사용 중이 아님 혹은 사용 중이 아

님 -> 사용 중인 상태로 진행중인 중간 단계의 BCB의 개수를

나타낸다.

READ_PAGE_COUNT

버퍼 초기화 이후 페이지를 디스크로부터 읽은 총 회수를 나타낸

다.

WRITE_PAGE_COUNT

버퍼 초기화 이후 페이지를 디스크에 플러쉬 한 총 회수를 나타

낸다.

GET_PAGE_COUNT

버퍼 초기화 이후 버퍼 매니저에 페이지를 요청한 총 회수를 나

타낸다. 이 요청에 대해 버퍼 매니저는 만약 페이지가 버퍼에 있

다면 버퍼의 페이지를 리턴하고, 그렇지 않으면 디스크로부터 페

이지를 버퍼에 읽어온 후 리턴한다.

CREATE_PAGE_COUNT

버퍼 초기화 이후 트랜잭션이 버퍼 매니저에 페이지 생성을 요청

한 총 회수를 나타낸다. 이 요청에 대해 버퍼 매니저는 버퍼에서

빈 BCB를 확보한 후 페이지를 초기화 하여 리턴한다. 디스크 IO

는 이 연산에서 수행되지 않는다.


V$DATABASE 메모리 데이터베이스 공간의 내부 정보를 보여준다.

Column name Type Description DB_NAME VARCHAR(128) 메모리 데이터베이스 명 PRODUCT_SIGNATURE VARCHAR(256) 제품 고유 스트링

DB_SIGNATURE VARCHAR(256) 데이터베이스 파일 고유 스트

링 VERSION_ID INTEGER 데이터베이스 고유 버전 COMPILE_BIT INTEGER 컴파일 비트(32/64) ENDIAN BIGINT 엔디안 정보 LOGFILE_SIZE BIGINT 로그화일 크기 TX_TBL_SIZE INTEGER 트랜잭션 테이블 크기 LAST_SYSTEM_SCN BIGINT 내부 용도 INIT_SYSTEM_SCN BIGINT 내부 용도 DURABLE_SYSTEM_SCN BIGINT 저장된 시스템 SCN 값 MEM_DBFILE_SIZE BIGINT 메모리 데이터 파일 크기

MEM_MAX_DB_SIZE VARCHAR(256) 메모리 데이터베이스의 최대 크기 .

MEM_DBFILE_COUNT_0 INTEGER 0번 데이터베이스 파일 그룹

의 개수

MEM_DBFILE_COUNT_1 INTEGER 1번 데이터베이스 파일 그룹

의 개수 MEM_TIMESTAMP VARCHAR(64) 고유 생성 시간 스트링 MEM_ALLOC_PAGE_COUNT BIGINT 할당된 페이지 총 개수 MEM_FREE_PAGE_COUNT BIGINT 사용 가능한 페이지 총 개수

MEM_RESTORE_TYPE BIGINT 메모리 데이터 베이스 로딩 타입

MEM_CURRENT_DB INTEGER 로딩할 메모리 데이터 베이스 그룹 번호

MEM_HIGH_LIMIT_PAGE BIGINT 현재 메모리 데이터베이스에

서 부여할 수 있는 최대 페이

지 번호

MEM_PAGE_COUNT_PER_FILE BIGINT 각 메모리 데이터 파일에서 페이지 개수

MEM_PAGE_COUNT_IN_DISK INTEGER

현재 디스크 에 있는 페이지 개수. 대략 메모리 데이터 파일 * 각 메모리 데이터 파일에서 페이지 개수.

칼럼 정보


DB_NAME

메모리 데이터베이스의 이름을 나타낸다.

PRODUCT_SIGNATURE

알티베이스 제품이 가지는 고유한 제품 정보를 나타낸다.

DB_SIGNATURE

알티베이스 메모리 데이터베이스 공간의 유일하게 결정하는 임의

의 스트링이다.

VERSION_ID

알티베이스 저장관리자가 유지하는 고유 버전번호를 나타낸다.

COMPILE_BIT

현재 생성된 데이터베이스가 32비트인지 혹은 64비트인지 표현

한다.

ENDIAN

현재 생성된 데이터베이스의 엔디안을 나타낸다. 0은 little

endian, 1은 big endian을 표현한다.

LOGFILE_SIZE

현재 생성된 데이터베이스에서 사용하는 로그 파일의 크기를 나

타낸다.

DBFILE_SIZE

현재 생성된 메모리 데이터베이스 공간을 유지하는 데이터 파일

의 크기를 나타낸다.

TX_TBL_SIZE

현재 할당된 트랜잭션 테이블의 크기를 나타낸다.

DBFILE_COUNT_0

0번 데이터베이스 그룹에 생성된 총 데이터 파일의 개수를 나타

낸다.

DBFILE_COUNT_1

1번 데이터베이스 그룹에 생성된 총 데이터 파일의 개수를 나타

낸다.

MEM_MAX_DB_SIZE

메모리 데이터베이스의 최대 크기를 나타낸다.

TIMESTAMP

내부 데이터베이스 정보의 변경시간을 나타낸다.

ALLOC_PAGE_COUNT


현재 메모리 데이터베이스 공간의 할당된 총 페이지 개수를 나타

낸다.

FREE_PAGE_COUNT

할당된 총 페이지 중 사용가능한 페이지 개수를 나타낸다.

FIRST_FREE_PAGE

첫번째 사용 가능한 페이지 아이디를 표현한다.

DURABLE_SYSTEM_SCN

데이터베이스 공간에 저장된 시스템 SCN의 값을 나타낸다.


V$DATAFILES 테이블스페이스에서 사용하는 데이터 파일의 정보를 보여준다.

Column name Type Description ID INTEGER 아이디 NAME VARCHAR(256) 이름 SPACEID INTEGER 테이블스페이스 아이디 OLDEST_LSN_FILENO INTEGER 아래 참조 OLDEST_LSN_OFFSET INTEGER 아래 참조 CREATE_LSN_FILENO INTEGER 아래 참조 CREATE_LSN_OFFSET INTEGER 아래 참조 SM_VERSION INTEGER 버전 정보 NEXTSIZE BIGINT 증가 시 크기 MAXSIZE BIGINT 최대 크기 INITSIZE BIGINT 초기 크기 CURRSIZE BIGINT 현재 크기 AUTOEXTEND INTEGER 자동 확장 플래그 IOCOUNT INTEGER I/O 횟수 OPENED INTEGER 사용 중 여부 MODIFIED INTEGER 변경 여부 STATE INTEGER 상태

칼럼 정보 ID

데이터 파일의 아이디를 나타낸다. 아이디는 생성된 순서대로 순

차적으로 부여되며 같은 아이디가 중복되는 일은 없다.

NAME

데이터 파일의 물리적 경로, 파일의 이름을 나타낸다.

SPACEID

데이터 파일이 속한 테이블스페이스의 아이디를 나타낸다.

OLDEST_LSN_FILENO

데이터 파일에 페이지를 플러쉬한 마지막 체크포인트 시점의 버

퍼에 올라와 수정되었던 페이지 중 가장 오래된 페이지의 LSN의

값 중 파일 번호를 나타낸다.

OLDEST_LSN_OFFSET


데이터 파일에 페이지를 플러쉬한 마지막 체크포인트 시점의 버

퍼에 올라와 수정되었던 페이지 중 가장 오래된 페이지의 LSN의

값 중 offset을 나타낸다.

CREATE_LSN_FILENO

데이터 파일이 생성된 시점의 LSN의 값 중 파일 번호를 나타낸

다.

CREATE_LSN_OFFSET

데이터 파일이 생성된 시점의 LSN의 값 중 offset을 나타낸다.

SM_VERSION

데이터 파일을 생성한 바이너리의 버전을 나타낸다. 모든 데이터

파일은 호환 가능한 바이너리의 버전을 가지게 된다.

NEXTSIZE

데이터 파일의 autoextend 속성이 on인 경우, 공간 부족 시 데이

터 파일이 확장될 크기를 나타낸다.

MAXSIZE

데이터 파일의 autoextend 속성이 on인 경우, 공간 부족 시 데이

터 파일이 확장될 수 있는 최대 크기를 나타낸다.

INITSIZE

데이터 파일이 최초에 생성된 크기를 나타낸다.

CURRSIZE

데이터 파일의 현재 크기를 나타낸다.

AUTOEXTEND

데이터 파일의 공간이 부족할 때 자동 확장될 지 여부를 나타낸

다.

0: 자동 확장 안함.

1: 자동 확장

IOCOUNT

데이터 파일에 현재 진행 중인 IO의 개수를 나타낸다. 데이터 파

일이 IO가 진행 중이 아니라면, 다음 데이터 파일의 오픈을 위해

양보해 줄 수 있다.

OPENED

데이터 파일이 현재 오픈되었는 지 나타낸다.

0: 닫혀 있음

1: 열려 있음

MODIFIED


데이터 파일이 수정되었는지 나타낸다. 데이터 파일에 페이지가

플러쉬 한 적이 있으면 이 값이 1이 된다. 데이터 파일에 싱크를

수행하면 이 값이 0이된다.

STATE

데이터 파일의 상태를 나타낸다.

1: online

2: backup 시작

3: backup 끝


V$DB_FREEPAGELISTS 데이타베이스의 사용가능한 페이지 리스트들의 정보를 보여준다.

Column name Type Description

RESOURCE_GROUP_ID INTEGER 리스트의 자원 그룹 아이디

FIRST_FREE_PAGE_ID BIGINT 리스트의 첫번째 사용가능한 페이지 아이디

FREE_PAGE_COUNT BIGINT 리스트의 사용가능한 페이지 개수

칼럼 정보 RESOURCE_GROUP_ID

다중화된 리스트들을 식별하기 위한 고유 번호를 나타낸다.

FIRST_FREE_PAGE_ID

해당 리스트의 맨 앞에 위치한 사용가능한 페이지 아이디를 표현

한다.

FREE_PAGE_COUNT

해당 리스트에 속한 사용가능한 페이지 개수를 나타낸다.


V$DISKGC 디스크 공간 회수 (disk garbage collection) 상태를 보여준다.


GC_NAME VARCHAR(128)

DISK_GC: 구버젼 인덱스 키 슬롯 해제 쓰레드 . DISK_DELTHR: delete된 레코드해

제와 drop table등 pending연산을 하는 쓰레드.

CURR_SYSTEMVIEWSCN BIGINT 현재 system view SCN

MINDISKSCN_INTXS BIGINT 디스크 관련 트랜잭션의 viewSCN중 제일 작은 SCN

SCNOFTAIL BIGINT Disk GC, DISK DELTHR의 Tail의 disk view SCN

ADD_TSS_CNT BIGINT Garbage Collection 처리를 위하여 추가된 TSS 개수

GC_TSS_CNT BIGINT Garbage Collecting한 TSS 개수


V$DISKTBL_INFO 디스크 테이블의 정보를 보여준다.

Column name Type Description TABLESPACE_ID INTEGER 테이블스페이스 아이디. TABLE_OID BIGINT 테이블 헤더의 OID DISK_PAGE_CNT BIGINT 테이블에서 할당한 페이지 개수 INSERT_HIGH_LIMIT SMALLINT 아래 참조 INSERT_LOW_LIMIT SMALLINT 아래 참조

테이블 이름을 포함하여 보려면 다음과 같이 메타 테이블과 조인

하여 질의를 하여야 한다.

SELECT A.TABLE_NAME, B.DISK_PAGE_CNT, B.INSERT_HIGH_LIMIT, B.INSERT_LOW_LIMIT FROM SYSTEM_.SYS_TABLES_ A, V$DISKTBL_INFO B WHERE A.TABLE_OID = B.TABLE_OID;

칼럼 정보 INSERT_HIGH_LIMIT

한 페이지가 insert 가능한 상태를 유지하는 상한 비율을 의미한

다.

예를 들면, 이 값이 80으로 설정되면, 80% 까지 만 insert 가능

한 페이지가 되며, 나머지 20%는 update 연산을 위하여 남겨둔

다.

INSERT_LOW_LIMIT

한 페이지가 update만 가능한 상태에서 다시 insert 가능 상태로

가기 위한 최소 페이지 가용 공간 비율을 의미한다.


V$FLUSHINFO 버퍼 플러쉬 정보를 보여준다.


FLUSH_TYPE VARCHAR(24)

버퍼 플러쉬 종류 LRU 플러쉬: 트랜잭션에 의하여 행해지

는 플러쉬 FLUSH 플러쉬: 플러쉬 쓰레드에 의하

여 행해지는 플러쉬 IS_FLUSH BIGINT 플러쉬 여부

FLUSH_WAIT_COUNT INTEGER DW 버퍼에서 복사되어 flush 대기 중인 페이지 개수


V$INDEX 현재 데이터베이스에 존재하는 인덱스 정보를 보여준다..

Column name Type Description TABLE_OID BIGINT 테이블 헤더의 OID

INDEX_SEG_DESC BIGINT DISK 인덱스의 경우 Index segment의 OID

INDEX_ID INTEGER 인덱스 ID

INDEX_TYPE VARCHAR(7) 해당 인덱스가 Primary Key로 사용

되는지 일반 인덱스인지 식별하기 위한 구분자


V$INSTANCE 현재 알티베이스의 구동 단계, 구동된 시간, 구동 후 경과된 시간

에 관한 정보를 보여준다.

Column name Type Description STARTUP_PHASE VARCHAR(13) 다단계 startup phase STARTUP_TIME_SEC BIGINT Startup 시간 WORKING_TIME_SEC BIGINT Startup 하여 지금까지 일한 시간


V$LATCH 버퍼 풀의 BCB latch 정보이며, read or write가 try된 페이지에

대하여 latch 시도 횟수, 바로 latch를 잡는 경우, miss한 경우 등

을 각각 read/ write latch에 대하여 통계 정보를 보여준다.

Column name Type Description SPACE_ID BIGINT 테이블스페이스 아이디 PAGE_ID INTEGER 페이지 아이디 TRY_READ_LATCH BIGINT 읽기 latch 시도 횟수 READ_SUCCESS_IMME BIGINT 읽기 latch를 바로 성공한 횟수 READ_MISS BIGINT 읽기 latch를 바로 못 잡은 개수 TRY_WRITE_LATCH BIGINT 쓰기 latch 시도 횟수 WRITE_SUCCESS_IMME BIGINT 쓰기 latch를 바로 성공한 횟수 WRITE_MISS BIGINT 쓰기 latch를 바로 못 잡은 개수 SLEEPS_CNT BIGINT Latch를 잡기 위하여 sleep한 횟수


V$LFG 알티베이스는 DBA가 그룹 커밋의 동작을 모니터링 할 수 있는

통계치를 제공한다. 각 칼럼에 대한 보다 상세한 정보는 이 매뉴

얼의 그룹커밋 장을 참조한다.


LFG_ID INTEGER 로그파일그룹 ID CUR_WRITE_LF_NO INTEGER 기록 로그 파일 번호 LF_OPEN_COUNT INTEGER 열린 로그파일의 수 LF_PREPARE_COUNT INTEGER 미리 생성한 로그파일의 수 LF_PREPARE_WAIT_COUNT INTEGER 로그 스위치 발생시 대기 횟수

LST_PREPARE_LF_NO INTEGER 마지막으로 미리 생성한 로그파일

의 수

END_LSN_LFGID INTEGER Restart REDO가 시작될 LSN(Log Sequence Number) 중 LFG ID

END_LSN_FILE_NO INTEGER Restart REDO가 시작될 LSN 중 파일 번호

END_LSN_OFFSET INTEGER Restart REDO가 시작될 LSN 중 파일 내의 오프셋

FIRST_DELETED_LOGFILE INTEGER 지워진 로그파일(포함) LAST_DELETED_LOGFILE INTEGER 지워진 로그파일(비포함)

RESET_LSN_LFGID INTEGER 특정 시각까지 복구 후 새 로그가 기록될LSN(Log Sequence Number)중 LFG ID

RESET_LSN_FILE_NO INTEGER 특정 시각까지 복구 후 새 로그가 기록될LSN 중 파일번호

RESET_LSN_OFFSET INTEGER 특정 시각까지 복구 후 새 로그가 기록될LSN 중 파일 내의 오프셋

UPDATE_TX_COUNT INTEGER [그룹커밋] DB에 변경을 가하는

트랜잭션

GC_WAIT_COUNT INTEGER [그룹커밋] 디스크 I/O를 기다린 횟수

GC_ALREADY_SYNC_COUNT INTEGER [그룹커밋] 이미 디스크 I/O가

수행된 횟수

GC_REAL_SYNC_COUNT INTEGER [그룹커밋] 그룹커밋도중 실제 디스크 I/O


칼럼 정보

LFG_ID

0부터 시작하여 1씩 증가하는 로그파일 그룹 고유번호

예를들어, 시스템에 네 개의 로그파일 그룹이 존재한다면,

LFG_ID를 조회했을 때 0,1,2,3 네 개의 행을 볼 수 있다.

CUR_WRITE_LF_NO

현재 로그를 기록하기 위해 사용하고 있는 로그 파일의 번호

LF_OPEN_COUNT

디스크상에 존재하는 로그파일중 알티베이스가 사용하기 위해 오

픈(Open)한 로그파일의 갯수

LF_PREPARE_COUNT

로그파일 생성 쓰레드가 지금까지 미리 생성한 로그파일의 갯수

LF_PREPARE_WAIT_COUNT

기록중이던 로그파일을 다 사용하여 새로운 로그파일로 스위칭했

을 때, 사용할 로그파일을 미리 만들지 못해서 기다린 횟수

이 값이 크다면 PREPARE_LOG_FILE_COUNT프로퍼티의 값을

더 큰값으로 재설정하여 충분한 갯수의 로그파일을 미리 만들어

두도록 한다.

LST_PREPARE_LF_NO

로그파일 생성 쓰레드가 마지막으로 미리 생성한 로그파일의 번

호

END_LSN_LFGID

Restart 시 REDO를 시작할 LSN(Log Sequence Number)중

LFG 고유번호

LFG별로 Restart시 REDO를 정확하게 이 부분에서 시작하지는

않는다. 하지만 최소한 이 LSN이후의 로그는 반드시 REDO된다

는 것을 보장할 수 있다.

LFG_ID 칼럼과 같은 값을 지닌다.

END_LSN_FILE_NO

Restart 시 REDO를 시작할 LSN(Log Sequence Number)중 로

그파일의 번호

END_LSN_OFFSET

Restart 시 REDO를 시작할 LSN(Log Sequence Number)중 로

그파일안의 오프셋

FIRST_DELETED_LOGFILE


체크포인트중 불필요한 로그파일로 분류되어 삭제된 로그파일중

첫번째 로그파일의 번호

이 칼럼의 값은 체크포인트중에 해당 로그파일 번호의 로그파일

까지 포함하여 삭제된 상태임을 의미한다.

LAST_DELETED_LOGFILE

체크포인트중 불필요한 로그파일로 분류되어 삭제된 로그파일중

마지막 로그파일의 번호에 1을 더한 값

이 칼럼의 값은 체크포인트중에 해당 로그파일 번호의 로그파일

바로 앞 로그파일까지 삭제된 상태임을 의미한다.

RESET_LSN_LFGID

RESET_LSN은 시스템 장애나 다른 이유로 인해 특정 시각까지

만 데이터베이스를 복구한 이후에 발생되는 새로운 작업들에 대

한 로그를 기록할 LSN이다.

이 칼럼은 RESET_LSN중 LFG고유번호를 지닌다. LFG_ID칼럼과

같은 값이다.

RESET_LSN_FILE_NO

RESET_LSN중 로그파일번호

RESET_LSN_OFFSET

RESET_LSN중 로그파일안의 오프셋

UPDATE_TX_COUNT

현재 DB에 변경을 가하는 트랜잭션중 이 LFG에 속한 트랜잭션

수를 실시간으로 반환

본 칼럼은 그룹커밋 관련 칼럼으로

TRANSACTION_DURABILITY_LEVEL프로퍼티가 5로 설정된

경우에만 유효한 값을 반환한다.

GC_WAIT_COUNT

그룹커밋을 위해 이 LFG에 속한 트랜잭션들이 디스크 I/O를 기

다린 횟수.

GC_ALREADY_SYNC_COUNT

그룹커밋도중 이 LFG에 속한 트랜잭션들이 필요로 하는 만큼의

디스크 I/O가 이미 수행되어 별도의 디스크 I/O를 수행하지 않은

횟수.

GC_REAL_SYNC_COUNT

그룹커밋도중 이 LFG에 속한 트랜잭션들이 실제로 디스크 I/O를

수행한 횟수.


V$LOCK 현재 시점에서 데이터베이스의 모든 테이블 lock 노드 정보를 보

여준다.


TABLE_OID BIGINT 테이블 OID TRANS_ID INTEGER 트랜잭션 아이디 LOCK_DESC VARCHAR(32) Lock mode에 대한 문자열

Ex) IX, IS, X LOCK_CNT INTEGER 해당 locknode의 lock 개수 IS_GRANT

BIGINT 해당 테이블에 대하여 Lock을 쥐고 있는지 , 대기하고 있는지 여부를 나타내

는 플래그.


V$LOCK_WAIT 시스템에서 수행되는 트랜잭션 간의 대기 정보를 나타낸다.

Column name Type Description TRANS_ID BIGINT 대기 트랜잭션 아이디 WAIT_FOR_TRANS_ID BIGINT 대기 대상 트랜잭션 아이디

칼럼 정보 TRANS_ID

현재 대기하고 있는 트랜잭션의 아이디를 나타낸다.

WAIT_FOR_TRANS_ID

대기하고 있는 TRANS_ID의 트랜잭션이 어떠한 트랜잭션에 대해

대기하고 있는지를 나타낸다.

SQL> select * from v$lock_wait;

V$LOCK_WAIT.TRANS_ID V$LOCK_WAIT.WAIT_FOR_TRANS_ID

---------------------------------------------

1216 2208

5344 2208

2 rows selected.

트랜잭션 2208에 대해서 트랜잭션 1216과 트랜잭션 5344가 현

재 대기하고 있다.


V$LOG 로그 앵커 정보를 보여준다.


BEGIN_CHKPT_FILE_NO INTEGER 가장 최근 수행된 검사점의 검사적 시작 로그의 로그 파일 번호

BEGIN_CHKPT_FILE_OFFSET INTEGER 가장 최근 수행된 검사점의 검사적 시작 로그의 로그 오프셋

END_CHKPT_FILE_NO INTEGER 가장 최근 수행된 검사점의 검사적 종료 로그의 로그 파일 번호

END_CHKPT_FILE_OFFSET INTEGER 가장 최근 수행된 검사점의 검사적 종료 로그의 로그 오프셋

END_LSN_FILE INTEGER 가장 최근 검사점 수행 시 또는 서버 정상 종료 시 마지막 로그의 로그 파일 번호

END_LSN_OFFSET INTEGER 가장 최근 검사점 수행 시 또는 서버 정상 종료시 마지막 로그의 로그 오프셋

STABLE_DB_NO INTEGER 가장 최근 검사점 수행 시 사용되

던 데이터베이스 번호

LST_CREATED_LOGFILE INTEGER 가장 최근 검사점 수행 시 마지막

으로 생성된 로그의 로그 파일 번호

SERVER_STATUS INTEGER 서버의 상태를 나타내며 1인 경우 서버가 수행 중임을 나타낸다.

FIRST_DB_FILECNT INTEGER 첫 번째 데이터베이스에 생성된 데이터베이스 파일의 개수

SECOND_DB_FILECNT INTEGER 두 번째 데이터베이스에 생성된 데이터베이스 파일의 개수

FIRST_DELETED_LOGFILE INTEGER 가장 최근 검사점 수행 시 최초로 삭제된 로그 파일의 번호

LST_DELETED_LOGFILE INTEGER 가장 최근 검사점 수행 시 마지막

으로 삭제된 로그 파일의 번호 LOGGING_LEVEL INTEGER 현재 설정된 로깅 레벨 ARCHIVELOG_MODE VARCHAR(12) 데이터베이스 모드 TABLESPACE_CNT INTEGER 테이블스페이스 개수

OLDEST_LOGFILE INTEGER Restart recovery 시에 disk 관련 redo가 시작되는 log 파일 번호

OLDEST_LOGFILE_OFFSET INTEGER Restart recovery 시에 disk 관련 redo가 시작되는 log 파일에서 offset


RESET_LOGFILE INTEGER 불완전 복구를 한 후 resetlog를 수행 할 시작 로그 파일 번호

RESET_LOGFILE_OFFSET INTEGER 불완전 복구를 한 후 resetlog를 수행 할 시작 로그 파일 번호에서 offset


V$LOCK_STATEMENT LOCK과 STATEMENT 정보를 같이 보여준다.

Column name Type Description SESSION_ID BIGINT 세션 ID ID BIGINT Statement ID TX_ID BIGINT 트랜잭션 ID QUERY VARCHAR(1024) Query 문장 STATE BIGINT Statement 상태 BEGIN_FLAG BIGINT Statement 시작 플래그 TABLE_OID BIGINT 테이블 OID

LOCK_DESC VARCHAR(32) Lock mode에 대한 문자열 Ex) IX, IS, X

LOCK_CNT INTEGER 해당 lock node의 lock 개수

IS_GRANT BIGINT 해당 테이블에 대하여 lock을 쥐고 있는지, 대기하고 있는지 여부를 나타내는 플래그


V$MEMGC 메모리 공간 회수 수행 (memory garbage collect) 정보를 보여준

다.


GC_NAME VARCHAR(128)

MEM_LOGICAL_AGER: 구버젼 인덱스 키 슬롯 해제 쓰레드 MEM_DELTHR: delete된 레코드 해제와 drop table등 pending연산을 하는 쓰레드

CURRSYSTEMVIEWSCN BIGINT 현재 system view SCN

MINMEMSCNINTXS BIGINT 디스크 관련 트랜잭션의 viewSCN중 제일 작은 SCN

SCNOFTAIL BIGINT Disk GC, DISK DELTHR의 Tail의 disk view SCN

IS_EMPTY_OIDLIST BIGINT OID 리스트가 비어 있는지 여부 0: 비어 있음 1: 비어 있지 않음

ADD_OID_CNT BIGINT Garbage Collection 처리를 위하여 추가된 OID 개수

GC_OID_CNT BIGINT Garbage Collecting한 OID 개수


V$MEMTBL_INFO 메모리 테이블의 상태를 보여준다.

Column name Type Description TABLESPACE_ID INTEGER 테이블스페이스 아이디. TABLE_OID BIGINT 테이블 헤더의 OID MEM_PAGE_CNT BIGINT 테이블에서 사용하는 fixed page개수 MEM_VAR_PAGE_CNT BIGINT 테이블에서 사용하는 var page 개수

MEM_SLOT_PERPAGE INTEGER 하나의 fixed page에 들어갈수 있는 슬롯 개수

MEM_SLOT_SIZE BIGINT 테이블의 레코드의 fixed영역의 크기. FIXED_ALLOC_MEM BIGINT 테이블에서 할당한 fixed 영역 메모리.

FIXED_USED_MEM BIGINT 테이블에서 실제 사용하고 있는 fixed 영역 메모리

VAR_ALLOC_MEM BIGINT 테이블에서 할당한 vaiable 영역 메모리

VAR_USED_MEM BIGINT 테이블에서 실제 사용하고 있는 variable 영역 메모리

MEM_FIRST_PAGEID BIGINT 테이블의 fixed 페이지중 제일 앞에 있는 페이지 번호

테이블 이름을 포함하여 보려면 다음과 같이 메타 테이블과 조인

하여 질의를 하여야 한다.

SELECT A.TABLE_NAME, B.MEM_PAGE_CNT, B.MEM_SLOT_SIZE, B.MEM_FIRST_PAGEID FROM SYSTEM_.SYS_TABLES_ A, V$MEMTBL_INFO B WHERE A.TABLE_OID = B.TABLE_OID;


V$MEMSTAT 알티베이스 프로세스가 사용하는 메모리의 통계정보를 보여준다.

Column name Type Description NAME VARCHAR(40) 메모리 모듈 이름 ALLOCSIZE BIGINT 해당 모듈의 메모리 사용량

ALLOC_COUNT BIGINT 해당 모듈에서 ALLOC_SIZE를 구성하는 단위 메모리의 개수

MAX_TOTAL_SIZE BIGINT 해당 모듈이 보유했던 최대 메모

리 양

칼럼 정보 NAME

알티베이스가 사용하는 44개의 모듈 이름을 나타낸다.

ALLOCSIZE

해당 모듈에서 사용하고 있는 메모리 사용량을 나타낸다.

ALLOC_COUNT

해당 모듈에서 ALLOC_SIZE를 구성하는 단위 메모리의 개수를

나타낸다.

MAX_TOTAL_SIZE

해당 모듈이 보유했던 최대 메모리 양을 나타낸다.


V$MUTEX 알티베이스 프로세스에서 사용되고 있는 동시성 제어와 관련

mutex 통계 정보를 보여준다.

Column name Type Description NAME VARCHAR(64) Mutex 이름 TRY_COUNT INTEGER Lock 시도 횟수 LOCK_COUNT INTEGER Lock 성공 횟수 MISS_COUNT INTEGER Lock을 잡지 못하여 대기 횟수 SPIN_VALUE INTEGER 현재 사용하고 있지 않는 필드 YIELD_VALUE INTEGER 현재 사용하고 있지 않는 필드


V$PLANTEXT 시스템에서 수행되는 SQL의 실행 계획 텍스트 정보를 나타낸다.

Column name Type Description SID INTEGER 세션 일련 번호 STMT_ID INTEGER 스테이트먼트 일련 번호 PIECE INTEGER PLAN TEXT 조각 일련 번호 TEXT VARCHAR(64) PLAN TEXT 문자열

칼럼 정보 SID

PLAN TEXT가 속한 세션의 고유 번호를 나타낸다.

STMT_ID

PLAN TEXT가 속한 세션의 스테이트먼트 일련 번호를 나타낸다.

PIECE

FULL PLAN TEXT를 구성하는 64바이트 TEXT 조각을 나타내

며 0부터 번호가 시작되는 일련 번호이다.

TEXT

실제 PLAN TEXT를 표현하는 64바이트 텍스트 조각을 나타낸

다.


V$PROCTEXT 시스템에서 수행되는 PSM의 텍스트 정보를 나타낸다.

Column name Type Description PROC_OID BIGINT PSM 오브젝트 아이디 PIECE INTEGER TEXT 조각 일련 번호 TEXT VARCHAR(64) SQL TEXT 문자열

칼럼 정보 PROC_OID

PSM 프로시져를 유일하게 가리키는 오브젝트 아이디를 나타낸

다.

PIECE

FULL PROC TEXT를 구성하는 64바이트 TEXT 조각을 나타내

며 0부터 번호가 시작되는 일련 번호이다.

TEXT

실제 PROC TEXT를 표현하는 64바이트 텍스트 조각을 나타낸

다.


V$PROPERTY 알티베이스 내부에 설정된 프로퍼티의 정보를 보여준다.

Column name Type Description NAME VARCHAR(256) 프로퍼티의 이름 STOREDCOUNT INTEGER 저장된 프로퍼티 개수 ATTR BIGINT 프로퍼티 속성 MIN VARCHAR(256) 최소값 MAX VARCHAR(256) 최대값 VALUE1 VARCHAR(256) 저장된 첫 번째 값 VALUE2 VARCHAR(256) 저장된 두 번째 값 VALUE3 VARCHAR(256) 저장된 세 번째 값 VALUE4 VARCHAR(256) 저장된 네 번째 값 VALUE5 VARCHAR(256) 저장된 다섯 번째 값 VALUE6 VARCHAR(256) 저장된 여섯 번째 값 VALUE7 VARCHAR(256) 저장된 일곱 번째 값 VALUE8 VARCHAR(256) 저장된 여덟 번째 값

칼럼 정보 NAME

해당 프로퍼티의 이름을 나타낸다.

STOREDCOUNT

해당 프로퍼티가 몇 개의 값을 가지고 있는지 나타낸다. 8개가지

중복된 값을 가질 수 있다.

ATTR

해당 프로퍼티의 속성을 나타낸다.

MIN

해당 프로퍼티의 최소값을 나타낸다.

MAX

해당 프로퍼티의 최대 값을 나타낸다.

VALUE1 ~ 8 실제 저장된 프로퍼티의 값을 나타낸다.


V$REPEXEC 리플리케이션 관리자 정보를 보여준다.

Column name Type Description PORT INTEGER 사용중인 포트 번호 MAX_SENDER_COUNT INTEGER 최대 송신자 개수 MAX_RECEIVER_COUNT INTEGER 최대 수신자 개수

칼럼 정보 PORT

지역서버의 이중화 관리자가 원격 서버의 이중화 요청을 받아들

이는 포트번호 이다.

MAX_SENDER_COUNT

지역서버에서 생성 가능한 이중화 송신 쓰레드의 최대 개수이다.

MAX_RECEIVER_COUNT

지역서버에서 생성 가능한 이중화 수신 쓰레드의 최대 개수이다.


V$REPGAP 리플리케이션 송신자의 작업 로그 파일이 현재 생성된 최근 로그

파일간의 차이를 보여준다.

Column name Type Description REP_NAME VARCHAR(40) 이름 REP_LAST_SN BIGINT 마지막 로그 일련번호 REP_SN BIGINT 전송 로그의 일련번호 REP_GAP BIGINT 간격

칼럼 정보 REP_NAME

지역서버에 생성된 이중화 객체의 이름이다.

REP_LAST_SN

지역서버의 트랜잭션에 의해 가장 최근에 로깅된 로그레코드의 S

N이다.

REP_SN

지역서버의 이중화 송신 쓰레드가 송신한 로그레코드의 SN이다.

REP_GAP

지역서버 트랜잭션에 의해 가장 최근 로깅된 로그레코드와 이중

화 송신 쓰레드가 송신한 로그레코드의 오프셋의 간격을 나타낸

다.


V$REPSYNC SYNC 중인 테이블의 정보를 보여준다.


REP_NAME HAR(40) 이름 SYNC_TABLE VARCHAR(40) SYNC 대상 테이블명 SYNC_RECORD_COUNT INTEGER 현재 사용하지 않음 SYNC_SN BIGINT 현재 사용하지 않음



SYNC_TABLE

SYNC 대상 테이블의 이름이다.


V$REPRECEIVER 리플리케이션 수신자의 정보를 보여준다.

Column name Type Description REP_NAME VARCHAR(42) 이름 MY_IP VARCHAR(50) IP 주소 MY_PORT INTEGER 포트 번호 PEER_IP VARCHAR(50) 원격 IP 주소 PEER_PORT INTEGER 원격 포트 번호 APPLY_XSN BIGINT 처리중인 XSN INSERT_SUCCESS_COUNT BIGINT 성공한 INSERT 수

INSERT_FAILURE_COUNT BIGINT 실패한 INSERT 수

UPDATE _SUCCESS_COUNT BIGINT 성공한 UPDATE 수

UPDATE_FAILURE_COUNT BIGINT 실패한 UPDATE 수

DELETE_SUCCESS_COUNT BIGINT 성공한 DELETE 수

DELETE_FAILURE_COUNT BIGINT 성공한 DELETE 수



MY_IP

지역서버의 IP 주소값이다.

MY_PORT

지역서버의 수신 쓰레드가 사용하는 포트번호이다.

PEER_IP

원격서버의 IP 주소값이다.

PEER_PORT

원격서버의 송신 쓰레드가 사용하는 포트번호이다.

APPLY_XSN

원격서버에서 송신 쓰레드가 전송하여 지역서버에서 수신 쓰레드

가 적용 중인 로그레코드의 SN을 나타낸다.


INSERT_SUCCESS_COUNT

지역서버에서 수신 쓰레드가 적용에 성공한 INSERT 로그레코드

의 수를 나타낸다.

INSERT_FAILURE_COUNT

지역서버에서 수신 쓰레드가 적용에 실패한 INSERT 로그레코드

의 수를 나타낸다. (Conflict를 포함)

UPDATE_SUCCESS_COUNT

지역서버에서 수신 쓰레드가 적용에 성공한 UPDATE 로그레코드


UPDATE_FAILURE_COUNT

지역서버에서 수신 쓰레드가 적용에 실패한 UPDATE 로그레코드


DELETE_SUCCESS_COUNT

지역서버에서 수신 쓰레드가 적용에 성공한 DELETE 로그레코드


DELETE_FAILURE_COUNT

지역서버에서 수신 쓰레드가 적용에 실패한 DELETE 로그레코드



V$REPRECEIVER_TRANSTBL 리플리케이션 수신자의 트랜잭션 테이블의 정보를 보여준다.


REP_NAME VARCHAR(40) 이름 LOCAL_TID INTEGER 지역 트랜잭션 ID REMOTE_TID INTEGER 원격 트랜잭션 ID BEGIN_FLAG INTEGER 현재 사용하지 않음 BEGIN_SN BIGINT 트랜잭션의 최초 로그 SN



LOCAL_TID

지역서버에서 실행되는 트랜잭션의 ID이다.

REMOTE_TID

원격서버에서 실행되는 트랜잭션의 ID이다.


V$REPSYNC SYNC 중인 테이블의 정보를 보여준다.


REP_NAME VARCHAR(40) 이름 SYNC_TABLE VARCHAR(40) SYNC 대상 테이블명 SYNC_RECORD_COUNT INTEGER 현재 사용하지 않음 SYNC_SN BIGINT 현재 사용하지 않음



SYNC_TABLE

SYNC 대상 테이블 이름이다.


V$REPSENDER_TRANSTBL 리플리케이션 송신자의 트랜잭션 테이블의 정보를 보여준다.


REP_NAME VARCHAR(40) 이름 LOCAL_TID INTEGER 지역 트랜잭션 ID REMOTE_TID INTEGER 현재 사용하지 않음 BEGIN_FLAG INTEGER 트랜잭션의 BEGIN 전송 여부 BEGIN_SN BIGINT 트랜잭션의 최초 로그 SN



LOCAL_TID

지역서버에서 실행되는 트랜잭션의 ID이다.

REMOTE_TID

원격서버에서 실행되는 트랜잭션의 ID이다


V$SEGMENT 디스크 테이블과 디스크 인덱스를 구성하는 세그먼트의 상태, 종

류, 할당된 익스텐트의 개수를 보여준다.


TABLESPACE_ID INTEGER 테이블스페이스 아이디 TABLE_OID BIGINT 테이블 헤더의 OID SEGMENT_DESC BIGINT 세그먼트 기술자의 RID SEGMENT_TYPE VARCHAR(7) 세그먼트의 종류 SEGMENT_STATE VARCHAR(7) 세그먼트의 상태 EXTENT_TOTAL_COUNT BIGINT 세그먼트에 할당된 extent 총 개수

EXTENT_FULL_COUNT BIGINT 더 이상 데이터를 추가할 수 없는 익스텐트의 개수

EXTENT_NOT_FULL_COUNT BIGINT 총 익스텐트 개수에서 full 익스텐

트 개수를 제외한 익스텐트 개수

칼럼 정보 SEGMENT_TYPE

INDEX - 해당 세그먼트가 인덱스 세그먼트인 경우

TABLE - 해당 세그먼트가 테이블 세그먼트인 경우

SEGMENT_STATE

USED – 해당 세그먼트가 사용 중인 경우

FREE – 해당 세그먼트가 FREE인 경우

SEGMENT_TOTAL_COUNT

세그먼트에 할당된 총 익스텐트 개수

SEGMENT_FULL_COUNT

테이블 - 더 이상 데이터를 insert할 수 없는 page만을 포함한

익스텐트의 개수

인덱스 세그먼트 - free page를 포함하지 않는 익스텐트의 개수

SEGMENT_NOT_FULL_COUNT

테이블 세그먼트 - 총 익스텐트 개수에서 full 익스텐트 수를 제

외한 익스텐트의 개수

인덱스 세그먼트 - free page를 포함하고 있는 익스텐트의 개수


V$REPSENDER 리플리케이션 송신자의 정보를 보여준다.

Column name Type Description REP_NAME VARCHAR(42) 이름 START_FLAG BIGINT 시작 플래그 NET_ERROR_FLAG BIGINT 에러 상태 플래그 BUFFER_SIZE INTEGER 송신자 버퍼 크기

BUFFER_OFFSET INTEGER 송신자 버퍼에서 현재 사용하고 있는 크기.

STATUS BIGINT 현재 상태 SENDER_IP VARCHAR(50) 송신자 IP PEER_IP VARCHAR(50) 원격 IP SENDER_PORT INTEGER 송신 포트 PEER_PORT INTEGER 원격 포트 XSN BIGINT 전송 Log의 SN COMMIT_XSN BIGINT Commit Log의 SN READ_LOG_COUNT BIGINT 읽은 Log의 수 SEND_LOG_COUNT BIGINT 읽은 Replication Log의 수



START_FLAG

지역서버의 이중화 구동시에 명시한 구동옵션이며, NORMAL,

QUICK, SYNC, SYNC ONLY 등의 옵션을 나타낸다.

NORMAL: 0

QUICK: 1

SYNC: 2

SYNC_ONLY: 3

NET_ERROR_FLAG

이중화 연결여부를 나타낸다. 0이면 연결되어 있는 상태이고, 1이

면 연결이 끊어진 상태이다.

XLSN_FINENO

지역서버의 이중화 송신 쓰레드가 송신한 로그레코드의 로그 파

일번호를 나타낸다.

STATUS


지역서버의 이중화 송신 쓰레드의 현재 상태(STOP(0), RUN(1),

RETRY(2))를 나타낸다.

SENDER_IP

지역서버의 IP 주소값이다.

PEER_IP

원격서버의 IP 주소값이다.

SENDER_PORT

지역서버의 이중화 송신 쓰레드가 사용하는 포트번호이다.

PEER_PORT

원격서버의 이중화 수신 쓰레드가 사용하는 포트번호이다.

XSN

지역서버의 이중화 송신 쓰레드가 송신한 로그레코드의 SN을 나타낸다.

COMMIT_XSN

지역서버에서 가장 최근에 COMMIT한 트랜잭션이 로깅한 COMMIT 로그

레코드의 SN을 나타낸다.

READ_LOG_COUNT

지역서버에서 송신 쓰레드가 읽은 로그레코드의 수를 나타낸다.

SEND_LOG_COUNT

지역서버에서 송신 쓰레드가 읽은 전송 대상 로그레코드의 수를 나타낸다.


V$SEQ 시퀀스 관련 정보를 보여준다.

Column name Type Description SEQ_OID BIGINT 시퀀스 객체 ID CURRENT_SEQ BIGINT 현재 시퀀스 값 START_SEQ BIGINT 시퀀스 시작 값 INCREMENT_SEQ BIGINT 시퀀스 증가 값 SYNC_INTERVAL BIGINT 캐쉬 값 CACHE_SIZE BIGINT 캐쉬 크기 MAX_SEQ BIGINT 시퀀스 최대값 MIN_SEQ BIGINT 시퀀스 최소값 IS_CYCLE VARCHAR(7) 시퀀스 싸이클 여부


V$SERVICE_THREAD 멀티플렉싱(Multiplexing)과 관련하여 서비스 쓰레드 정보를 보여

준다.

서버에서 클라이언트의 요청을 받아 질의를 수행하는 쓰레드를

서비스 쓰레드라 한다. 서버에 수 많은 클라이언트가 접속하여 질

의를 수행하는 경우 각 클라이언트 세션마다 하나의 서비스 쓰레

드를 생성하여 질의를 수행하게 되면 성능이 저하될 수 있다.

따라서 서버에 최적화된 개수만큼의 서비스 쓰레드만 생성하여

클라이언트 세션들의 질의를 수행하는 것을 서비스 쓰레드 멀티

플렉싱이라 한다.

MULTIPLEXING_THREAD_COUNT 프로퍼티 값만큼의 서비스

쓰레드가 생성되어 여러 클라이언트 세션들을 담당하는데 이 쓰

레드를 SHARED 서비스 쓰레드라 하고, 서비스 쓰레드가 부족하

다고 서버가 판단하는 경우 임시로 하나의 세션을 담당한 뒤 세

션이 종료하면 삭제되는 쓰레드를 DEDICATED 서비스 쓰레드라

한다. 이들 서비스 쓰레드를 관리하는 서비스 쓰레드 관리자가 서

버 내에 존재한다.

Column name Type Description ID INTEGER 서비스 쓰레드 ID

TYPE VARCHAR(9)

SHARED / DEDICATED: DEDICATED는 하나의 세션을 전담하는 서비스 쓰레드로 IPC_MULTIPLEXING=0 일 경우 모든 IPC 세션은 DEDICATED 서비스 쓰레드

에 의해 서비스된다. 또한 서비스 쓰레드

들의 처리 시간이 증가되어 응답이 느려질 때 DEDICATED 서비스 쓰레드가 추가될 수 있다.

STATE VARCHAR(7) POLL: 요청을 기다리는 상태 EXECUTE: 요청을 처리중인 상태

TASK_COUNT INTEGER 서비스 쓰레드가 담당하고 있는 세션 수

READY_TASK_COUNT INTEGER 요청이 들어와서 EXECUTE를 대기 중인 세션 수

TASK_IN_COUNT INTEGER 다른 서비스 쓰레드에서 옮겨 온 세션 수 TASK_OUT_COUNT INTEGER 다른 서비스 쓰레드로 옮겨 간 세션 수

ELAPSE_TIME INTEGER

서비스 쓰레드가 EXECUTE를 시작한 지

연시간으로 서비스 쓰레드 관리자가 일정 주기로 이 값을 증가시킨다. 그러므로 시간 단위와 일치하지 않을 수 있다. 이 값과 관련된 프로퍼티는 다음과 같다. MULTIPLEXING_MANAGER_INTERVAL, MULTIPLEXING_MAX_ELAPSE_TIME


V$SESSION 알티베이스 내부에 생성된 클라이언트에 대한 세션 정보를 보여준다.

Column name Type Description ID INTEGER 세션 아이디 STATUS BIGINT 내부 용도 EVENTFLAG INTEGER 세션 이벤트 플래그 DETECTOR_FLAG BIGINT 내부 용도 PROTOCOL_INTERNAL INTEGER 내부 용도 CLIENT_ID BIGINT 클라이언트 아이디 COMM_NAME VARCHAR(128) 접속 정보 COMM_MARSHAL_TYPE BIGINT 마샬링 여부 플래그 COMM_FEATURE_FLAG BIGINT 통신 속성 XA_SESSION_FLAG BIGINT XA 세션 플래그 XA_ASSOCIATE_FLAG BIGINT XA associate 플래그 QUERY_TIME_LIMIT INTEGER 아래 참조 FETCH_TIME_LIMIT INTEGER 아래 참조 UTRANS_TIME_LIMIT INTEGER 아래 참조 IDLE_TIME_LIMIT INTEGER 아래 참조 IDLE_START_TIME INTEGER 아래 참조 ACTIVE_FLAG BIGINT 트랜잭션 활성 플래그 OPENED_STMT_COUNT INTEGER 사용 중인 구문 개수 CLIENT_VERSION BIGINT 클라이언트 버전 CLIENT_CONSTR VARCHAR(256) 클라이언트 연결 스트링 CLIENT_IDN VARCHAR(256) 클라이언트 Language 타입 DB_USERNAME VARCHAR(256) 데이터베이스 유저 명 DB_USERID INTEGER 데이터베이스 유저 아이디 CLIENT_PID BIGINT 클라이언트 프로세스 아이디

DEFAULT_TBSID BIGINT 사용자

의 default tablespace 아이디

DEFAULT_TEMP_TBSID BIGINT 사용자

의 default temp tablespace 아이디

SYSDBA_FLAG BIGINT Sysdba 접속 여부 AUTOCOMMIT_FLAG BIGINT Autocommit 플래그 SESSION_STATE BIGINT 세션의 상태 PROTOCOL_SESSION INTEGER 프로토콜 상태 ISOLATION_LEVEL INTEGER 고립도 OPTIMIZER_MODE INTEGER 최적화 모드 HEADER_DISPLAY_MODE INTEGER 0: display table name CURRENT_STMT_ID BIGINT 사용 중인 구문 아이디 STACK_SIZE INTEGER 스택 크기 CONTINUOUS_FAILURE_COUNT BIGINT 내부 용도 DEFAULT_DATE_FORMAT VARCHAR(64) 디폴트 날짜 format


Ex)DD-MON-RRRR

칼럼 정보 ID

현재 연결된 세션의 고유 아이디를 나타낸다. 이 값은 서버가 재

구동하지 않는 한 세션이 접속할 때 마다 계속 증가한다.

EVENTFLAG

세션에 발생한 특정 이벤트 값을 나타낸다.

세션이 끊어졌을 때: 0x00010000 플래그가 설정된다.

세션에 Timeout이 발생했을 때 0x0000FFFF 로 마스킹

한 값이 0이 아니다.

세션에 대한 이벤트를 금지시켰을 때: 0x00100000 플래

그가 설정된다.

CLIENT_ID

클라이언트가 부여한 고유 아이디를 나타낸다. 클라이언트에 따라

설정될 수도, 안될 수도 있다.

COMM_NAME

클라이언트의 접속 정보를 나타낸다. 연결할 때 쓰이는 내부 고유

스트링과 소켓의 경우 Remote IP Address를 출력한다.

COMM_MARSHAL_TYPE

통신과정에서 데이터에 대한 마샬링이 필요한지 여부를 나타낸다.

0일 경우 아무런 마샬링을 하지 않고, 1일 경우 마샬링을 수행한

다.

COMM_FEATURE_FLAG

통신 객체의 속성을 나타낸다.

0x01: 해당 통신 객체는 연속적인 버퍼에 대한 Fetch가

허용된다.

0x02: 해당 통신 객체는 sysdba의 접속을 허용한다.

XA_SESSION_FLAG

현재의 세션이 XA 세션인지 나타낸다.

0: NON-XA

XA_ASSOCIATE_FLAG

XA 세션의 Assiciate 플래그를 나타낸다.


QUERY_TIME_LIMIT

현재 세션의 Query TimeOut 값을 나타낸다.

FETCH_TIME_LIMIT

현재 세션의 Fetch TimeOut 값을 나타낸다.

UTRANS_TIME_LIMIT

현재 세션의 Update Transaction Timeout 값을 나타낸다.

IDLE_TIME_LIMIT

현재 세션의 Idle Timeout 값을 나타낸다.

IDLE_START_TIME

Idle 이 시작된 시간을 표시한다.

ACTIVE_FLAG

세션이 어떤 구문을 수행했을 경우 1로 설정되고, 단지 연결만

되어 있거나, commit, rollback 이후의 상태라면 0으로 표시된다.

OPENED_STMT_COUNT

해당 세션이 현재 수행중인 구문의 개수를 나타낸다.

CLIENT_VERSION

접속된 클라이언트의 버전 정보를 나타낸다.

CLIENT_CONSTR

접속된 클라이언트의 접속 스트링을 나타낸다.

CLIENT_IDN

접속된 클라이언트의 언어 종류를 나타낸다.

DB_USERNAME

접속된 클라이언트가 사용하는 유저명을 나타낸다.

DB_USERID

알티베이스가 구별하는 유저명에 대한 숫자로 표현되는 아이티를

나타낸다.

CLIENT_PID

접속된 클라이언트의 프로세스 아이디를 나타낸다.

DEFAULT_TBSID

사용자의 default tablespace의 아이디를 나타낸다.

DEFAULT_TEMP_TBSID

사용자의 default temp tablespace의 아이디를 나타낸다.

SYSDBA_FLAG


접속된 세션이 sysdba 인지 아닌지 나타낸다.

1: sysdba

AUTOCOMMIT_FLAG

접속된 세션이 autocommit 인지 나타낸다. 0일 경우 non-

autocommit 이고, 1일 경우 autocommit 이다.

SESSION_STATE

0: 세션 초기화 상태

1: 세션 접속 초기 상태

2: 세션 접속 후 인증 초기 상태

3: 세션 접속 후 인증 진행 상태

4: 인증 성공 후 서비스 초기화 상태

5: 인증 성공 후 서비스 처리 상태

6: Disconnect 프로토콜에 의한 정상 종료 상태

7: 비정상 상태(Network 에러 등)에 의한 세션

Rollback 및 종료 상태

PROTOCOL_SESSION

아래의 값은 해당 프로토콜을 나타낸다.

0x53455256 Handshake for sysdba dispatch

0x41444D4E Handshake for users dispatch

0x434F4E4E Connect

0x4449434E Disconnect

0x494E564C Invalid

0x4C524745 Large

0x544D4F54 Timeout

0x45524F52 Error

0x50524550 Prepare

0x45584543 Execute

0x45444952 ExecDirect

0x46544348 Fetch

0x46524545 Free

0x494F4552 I/O Error

0x4541474E EAGIN Error

0x5841434D XA Commands


0x41434E4E Acknowledge

0x47455454 Get

ISOLATION_LEVEL

해당 세션에 설정된 고립도를 나타낸다.

OPTIMIZER_MODE

해당 세션에 설정된 최적화 모드를 나타낸다.

1이면 rule based, 0이면 cost based로 동작한다.

CURRENT_STMT_ID

현재 수행중인 구문의 아이디를 나타낸다.

STACK_SIZE

해당 세션에 설정된 Query Processor를 위한 스택 크기를 나타

낸다.


V$SESSIONMGR 알티베이스의 세션 통계 정보를 보여준다.

Column name Type Description TASK_COUNT INTEGER 연결된 세션 개수 BASE_TIME INTEGER 현재 시간 QUERY_TIMEOUT_COUNT INTEGER 아래 참조 IDLE_TIMEOUT_COUNT INTEGER 아래 참조 FETCH_TIMEOUT_COUNT INTEGER 아래 참조 UTRANS_TIMEOUT_COUNT INTEGER 아래 참조 SESSION_TERMINATE_COUNT INTEGER 아래 참조

칼럼 정보 TASK_COUNT

현재 접속된 세션의 총 개수를 나타낸다.

BASE_TIME

현재 알티베이스가 유지하고 있는 시간을 숫자로 나타낸다.

QUERY_TIMEOUT_COUNT

알티베이스가 구동된 이후에 발생된 Query Timeout의 횟수를 나

타낸다.

IDLE_TIMEOUT_COUNT

알티베이스가 구동된 이후에 발생된 Idle Timeout의 횟수를 나타

낸다.

FETCH_TIMEOUT_COUNT

알티베이스가 구동된 이후에 발생된 FetchTimeout의 횟수를 나

타낸다.

UTRANS_TIMEOUT_COUNT

알티베이스가 구동된 이후에 발생된 Update Transaction

Timeout의 횟수를 나타낸다.

SESSION_TERMINATE_COUNT

알티베이스가 구동된 이후에 sysdba에 의해 강제로 연결이 끊긴

세션의 개수를 나타낸다.


V$STATEMENT 현재 알티베이스에 생성된 모든 세션의 구문 리스트를 보여준다.

Column name Type Description ID BIGINT 해당 구문 아이디 CURSOR_TYPE INTEGER 구문의 커서 타입 SESSION_ID BIGINT 해당 구문이 속한 세션 아이디 TX_ID BIGINT 트랜잭션 아이디 QUERY VARCHAR(1024) 수행되는 Query 스트링 QUERY_START_TIME INTEGER Query의 시작 타임 FETCH_START_TIME INTEGER Fetch 시작 타임 STATE BIGINT 상태 BEGIN_FLAG BIGINT 시작 플래그 INIT_TIME BIGINT 초기화 시간 LAST_QUERY_START_TIME BIGINT 최근 쿼리 시작 시간 TOTAL_TIME BIGINT 지원되지 않음 PARSE_TIME BIGINT 지원되지 않음 VALIDATE_TIME BIGINT 지원되지 않음 OPTIMIZE_TIME BIGINT 지원되지 않음 EXECUTE_TIME BIGINT 지원되지 않음 FETCH_TIME BIGINT 지원되지 않음 WAIT_TIME BIGINT 지원되지 않음 TIME_CHECK_FLAG BIGINT 지원되지 않음

칼럼 정보 ID

해당 구문이 가지고 있는 세션내부에서 구별되는 유일한 아이디

이다. 0에서 1023까지 가질 수 있다.

CURSOR_TYPE

0x02비트가 셋팅될 경우 메모리 커서이고, 0x04 비트가 셋팅될

경우 디스크 커서이다.

SESSION_ID

해당 구문이 속한 세션의 아이디이다.

TX_ID

현재 수행중인 트랜잭션의 아이디를 나타낸다.

QUERY

현재 구문이 수행하고 있거나, 수행했던 Query의 String을 나타

낸다.


QUERY_START_TIME

현재 구문이 수행하는 Query의 시작 시간을 나타낸다.

FETCH_START_TIME

현재 구문이 select일 경우 Fetch가 시작된 시간을 나타낸다.

STATE

0: 해당 구문이 할당된 초기화 상태

1: 해당 구문이 prepare 된 상태

2: 해당 구문이 Fetch를 위해 준비하고 있는 상태

3: 해당 구문이 Fetch 과정중에 있는 상태

LAST_QUERY_START_TIME

해당 쿼리의 가장 최근 실행 시작 시간을 나타낸다.


V$SQLTEXT 시스템에서 수행되는 SQL의 텍스트 정보를 나타낸다.

Column name Type Description SID INTEGER 세션 일련 번호 STMT_ID INTEGER 스테이트먼트 일련 번호 PIECE INTEGER TEXT 조각 일련 번호 TEXT VARCHAR(64) SQL TEXT 문자열

칼럼 정보 SID

SQL TEXT가 속한 세션의 고유 번호를 나타낸다.

STMT_ID

SQL TEXT가 속한 세션의 스테이트먼트 일련 번호를 나타낸다.

PIECE

FULL SQL TEXT를 구성하는 64바이트 TEXT 조각을 나타내며

0부터 번호가 시작되는 일련 번호이다.

TEXT

실제 SQL TEXT를 표현하는 64바이트 텍스트 조각을 나타낸다.


V$TABLE 성능 뷰 리스트를 보여준다.

Column name Type Description NAME VARCHAR(39) 테이블 명 SLOTSIZE SMALLINT 레코드의크기 COLUMNCOUNT SMALLINT 칼럼의 개수

칼럼 정보 NAME

성능 뷰의 이름을 나타낸다.

SLOTSIZE

해당 성능 뷰가 가진 레코드의 크기를 나타낸다.

COLUMNCOUNT

해당 성능 뷰가 가진 칼럼의 크기를 나타낸다.


V$TABLESPACES 테이블스페이스의 정보를 보여준다.

Column name Type Description ID INTEGER 아이디 NAME VARCHAR(40) 이름 NEXT_FILE_ID INTEGER 다음 데이터 파일 아이디 TYPE INTEGER 타입 STATE INTEGER 상태 DATAFILE_COUNT INTEGER 파일 개수 TOTAL_PAGE_COUNT BIGINT 총 페이지 개수

A_EXTENT_PAGE_CNT INTEGER 해당 테이블스페이스의 extent 크기(페이지 개수)

USED_PAGE_CNT BIGINT 해당 테이블스페이스에서 초기화된 페이지 개수

칼럼 정보 ID

테이블스페이스의 아이디를 나타낸다. 유저 테이블스페이스는 4

부터 부여되며, 항상 증가하는 값으로 부여된다.

NAME

CREATE TABLESPACE 구문에 정의된 테이블스페이스의 이름

을 나타낸다.

NEXT_FILE_ID

테이블스페이스에 데이터 파일이 추가될 경우 데이터 파일에 부

여할 아이디이다. 하나의 데이터 파일이 추가될 경우 이 값은 1

증가한다.

TYPE

테이블스페이스의 타입을 나타낸다.

0: 메모리 테이블스페이스

1: 디스크 시스템 데이터 테이블스페이스

2: 디스크 사용자 데이터 테이블스페이스

3: 디스크 시스템 temp 테이블스페이스

4: 디스크 사용자 temp 테이블스페이스

5: 디스크 시스템 undo 테이블스페이스


STATE

테이블스페이스의 상태를 나타낸다.

1: online

2: 테이블스페이스 백업 중

3: 테이블스페이스 백업 종료.

DATAFILE_COUNT

테이블스페이스에 속한 데이터 파일의 개수를 나타낸다.

TOTAL_PAGE_COUNT

테이블스페이스의 크기를 페이지 개수로 나타낸다. 실제 테이블스

페이스의 공간은 이 값 * 페이지 크기로 계산할 수 있다.


V$TRACELOG 데이터베이스 내부 모듈들이 수행하는 트레이스 로깅 작업정보를 보여준다.

Column name Type Description MODULE_NAME VARCHAR(8) 모듈명 TRCLEVEL INTEGER 로깅 레벨 (1~32) FLAG VARCHAR(8) 현재의 로깅 유무 플래그 POWLEVEL BIGINT 레벨 2의 승수 DESCRIPTION VARCHAR(8) 설명

칼럼 정보

MODULE_NAME

알티베이스에서 유지하고 있는 모듈의 이름을 나타낸다.

현재 알티베이스는 SERVER, QP, RP, SM의 모듈을 유지하고 있

다.

TRCLEVEL

내력 레벨을 나타낸다. 1에서 32의 값을 가진다.

FLAG

현재의 레벨의 내력 메시지가 출력되고 있는지의 상태를 나타낸

다. X의 경우는 출력되지 않는 상태이고, O는 출력중인 상태이다.

POWLEVEL

현재 레벨의 2의 승수를 나타낸다. 이 값은 함께 배포되는 tracel

og.sql에 의해 생성된 PSM인 addTrcLevel(), delTrcLevel() 을

손쉽게 사용할 수 있도록 미리 계산된 값을 유지한다.

DESCRIPTION

현재의 레벨이 나타내는 내력 메시지에 대한 설명을 나타낸다.

예제)

레벨 1, 2, 3이 active된, SERVER의 내력 메시지 상태를 확인한

다.

iSQL> select module_name, trclevel, flag, powlevel from

v$tracelog where module_name like '%SER%';

MODULE_NAME TRCLEVEL FLAG POWLEVEL

------------------------------------------------

-------------

SERVER 1 O 1


SERVER 2 O 2

SERVER 3 O 4

SERVER 4 X 8

SERVER 5 X 16

SERVER 6 X 32

SERVER 7 X 64

SERVER 8 X 128

SERVER 9 X 256

SERVER 10 X 512

SERVER 11 X 1024

SERVER 12 X 2048


V$TRANSACTION 트랜잭션 객체의 정보를 보여준다.

Column name Type Description ID BIGINT 트랜잭션 아이디 MEMORY_VIEW_SCN BIGINT 아래 참조 DISK_VIEW_SCN BIGINT 아래 참조 COMMIT_SCN BIGINT 아래 참조 SAVED_OLDEST_SCN BIGINT 아래 참조 STATUS BIGINT 아래 참조 UPDATE_STATUS BIGINT 아래 참조 LOG_TYPE INTEGER 아래 참조 XA_COMMIT_STATUS BIGINT 아래 참조 XA_PREPARED_TIME VARCHAR(64) 아래 참조 CURR_UNDO_NEXT_LSN_FILENO INTEGER 내부 용도 CURR_UNDO_NEXT_LSN_OFFSET INTEGER 내부 용도 FIRST_UNDO_NEXT_LSN_FILENO INTEGER 아래 참조 FIRST_UNDO_NEXT_LSN_OFFSET INTEGER 아래 참조 LAST_UNDO_NEXT_LSN_FILENO INTEGER 아래 참조 LAST_UNDO_NEXT_LSN_OFFSET INTEGER 아래 참조 SLOT_NO INTEGER 아래 참조 LOCK_ROW_OID BIGINT 내부 용도 REMOVE_OID BIGINT 내부 용도 UPDATE_SIZE INTEGER 아래 참조 ENABLE_ROLLBACK BIGINT 내부 용도 FIRST_UPDATE_TIME INTEGER 아래 참조 SESSION_FLAG INTEGER 내부 용도 LOG_BUF_SIZE INTEGER 내부 용도 LOG_OFFSET INTEGER 내부 용도 SKIP_CHECK_FLAG BIGINT 내부 용도 SKIP_CHECK_SCN_FLAG BIGINT 내부 용도 DDL_FLAG BIGINT 아래 참조 TSS_RID BIGINT 아래 참조 UNDO_NO INTEGER 아래 참조

칼럼 정보 ID

해당 트랜잭션을 구분할 수 있는 번호이다. ID의 값은 0 부터

2^32 – 1 까지 사용되며, 이 값들은 다시 재사용 될 수 있다.

MEMORY_VIEW_SCN


알티베이스는 MVCC를 사용하기 때문에 테이블에 대해 열리는

각 커서들에 대해 열린 시점을 나타내는 SCN을 가지게 되어 있

다. 이 항목은 현재 해당 트랜잭션에서 메모리 테이블에 대해 열

려있는 커서의 View SCN 중 가장 작은 값은 나타낸다. 이 값이

2^63을 가지면 어떤 커서도 열려 있지 않다는 것을 나타낸다.

DISK_VIEW_SCN

현재 해당 트랜잭션에서 디스크 테이블에 대해 열려있는 커서의

View SCN 중 가장 작은 값은 나타낸다. 값의 범위는

MEMORY_VIEW_SCN과 동일하다.

COMMIT_SCN

트랜잭션이 커밋한 시점의 시스템 SCN을 나타낸다. 아직 커밋하

지 않았다면 2^63을 가진다.

SAVED_OLDEST_SCN

트랜잭션이 시작된 후 최초로 연 디스크 커서의 VIEW SCN값을

나타낸다. 이 값이 트랜잭션 매니져에서 관리하는 SSL(Start SCN

List)에 달리게 된다.

STATUS

현재 트랜잭션의 상태를 나타낸다. (0: BEGIN, 1: PRECOMMIT,

2: COMMIT_IN_MEMORY, 3: COMMIT, 4: ABORT, 5:

BLOCKED, 6: END)

UPDATE_STATUS

해당 트랜잭션이 현재까지 갱신연산을 수행한 트랜잭션인지

read-only 트랜잭션인지를 나타낸다.( 0: read-only, 1:

updating )

LOG_TYPE

해당 트랜잭션이 리플리케이션에 관련된 테이블을 갱신한 적이

있는지를 나타낸다.(0: 일반, 1: 리플리케이션 관련)

XA_COMMIT_STATUS

글로벌 트랜잭션에 의한 로컬 트랜잭션의 현재 상태를 표시한

다.(0: BEGIN, 1: PREPARED, 2: COMPLETE)

XA_PREPARED_TIME

글로벌 트랜잭션에 의한 로컬 트랜잭션이 PREPARE 명령을 코디

네이터(글로벌 트랜잭션 관리자)로부터 받은 시점을 나타낸다.

FIRST_UNDO_NEXT_LSN_FILENO

트랜잭션이 처음 기록한 로그의 위치를 나타내는 LSN 중 파일

번호를 나타낸다.

FIRST_UNDO_NEXT_LSN_OFFSET


트랜잭션이 처음 기록한 로그의 위치를 나타내는 LSN 중 파일

내에서의 위치(오프셋)를 나타낸다.

LAST_UNDO_NEXT_LSN_FILENO

트랜잭션이 마지막 기록한 로그의 위치를 나타내는 LSN 중 파일

번호를 나타낸다.

LAST_UNDO_NEXT_LSN_OFFSET

트랜잭션이 마지막 기록한 로그의 위치를 나타내는 LSN 중 파일

내에서의 위치(오프셋)를 나타낸다.

SLOT_NO

프로퍼티에 저장된 트랜잭션 풀 중 해당 트랜잭션 객체의 순번을

나타낸다.

UPDATE_SIZE

트랜잭션이 수행한 갱신(Update) 연산에 의해 작성된 로그의 크

기를 나타낸다. 이 값은 프로퍼티 중

LOCK_ESCALATION_MEMORY_SIZE 값과 비교되어, 이 값보다

더 커지면 이후로는 테이블에 X 록을 잡고 in-place update 방식

으로 갱신을 수행하게 된다.

FIRST_UPDATE_TIME

최초로 데이터베이스에 대한 변경이 일어난 시각이 기록된다.

DDL_FLAG

DDL을 수행 중인 트랜잭션인지 나타낸다. (0: non-DDL, 1: DDL)

TSS_RID

디스크 테이블에 대한 갱신 연산 수행을 위해 얻은

TSS(Transaction Status Slot)의 물리적 위치를 나타낸다. 0 값이

아닐 경우에는 해당 트랜잭션은 디스크 테이블에 대해 갱신연산

을 한번이라도 수행 했음은 나타낸다.

UNDO_NO

디스크 테이블에 대한 MVCC를 위해 레코드 변경 시 언두 로그

레코드를 작성하는데, 각 언두 로그 레코드는 1씩 증가하는 언두

로그 번호를 가진다. 이 항목은 트랜잭션이 다음에 할당받을 언두

로그 번호를 나타낸다.


V$TRANSACTION_MGR 알티베이스 트랜잭션 관리자의 정보를 보여준다.

Column name Type Description TOTAL_COUNT INTEGER 트랜잭션 총 개수 FREE_LIST_COUNT INTEGER 리스트 개수 BEGIN_ENABLE BIGINT 사용가능 플래그 ACTIVE_COUNT INTEGER 할당된 개수

칼럼 정보 TOTAL_COUNT

알티베이스는 시스템 시작시에 프로퍼티에 지정된 개수의 트랜잭

션 객체들을 미리 생성해 두고, 이것을 트랜잭션 풀로 사용한다.

이 항목은 현재 알티베이스에서 생성한 트랜잭션의 총 개수를 나

타낸다.

FREE_LIST_COUNT

트랜잭션 풀을 분할 관리하는 리스트의 개수를 나타낸다.

BEGIN_ENABLE

새로운 트랜잭션을 begin 할 수 있는지를 나타낸다.

0: disabled

1: enabled

ACTIVE_COUNT

현재 할당되어 작업을 수행중인 트랜잭션 객체의 개수를 나타낸

다.


V$UNDO_BUFF_STAT Undo table space의 버퍼 풀 관련 통계 정보를 보여준다.

Column name Type Description READ_PAGE_COUNT BIGINT 아래 참조 WRITE_PAGE_COUNT BIGINT 아래 참조 GET_PAGE_COUNT BIGINT 참조 횟수 CREATE_PAGE_COUNT BIGINT 아래 참조

칼럼 정보 READ_PAGE_COUNT

버퍼 초기화 이후 페이지를 디스크로부터 읽은 총 회수를 나타낸

다.

WRITE_PAGE_COUNT

버퍼 초기화 이후 페이지를 디스크에 플러쉬 한 총 회수를 나타

낸다.

GET_PAGE_COUNT

버퍼 초기화 이후 버퍼 매니저에 페이지를 요청한 총 회수를 나

타낸다. 이 요청에 대해 버퍼 매니저는 만약 페이지가 버퍼에 있

다면 버퍼의 페이지를 리턴하고, 그렇지 않으면 디스크로부터 페

이지를 버퍼에 읽어온 후 리턴한다.

CREATE_PAGE_COUNT

버퍼 초기화 이후 트랜잭션이 버퍼 매니저에 페이지 생성을 요청

한 총 회수를 나타낸다. 이 요청에 대해 버퍼 매니저는 버퍼에서

빈 BCB를 확보한 후 페이지를 초기화 하여 리턴한다. 디스크 IO

는 이 연산에서 수행되지 않는다.


V$VERSION 데이터베이스 버전 관련 정보를 보여준다.


PRODUCT_VERSION VARCHAR(128) 제품 버전 Ex) 4.3.9.0

PKG_BUILD_PLATFORM_INFO VARCHAR(128) 패키지 가 빌드된 플랫폼 PRODUCT_TIME VARCHAR(128) 패키지가 빌드된 시간 SM_VERSION VARCHAR(128) SM 버전 META_VERSION VARCHAR(128) 메타 버전 PROTOCOL_VERSION VARCHAR(128) 프로토콜 버전 REPL_PROTOCOL_VERSION VARCHAR(128) 리플리케이션 프로토콜 버전

데이터베이스 객체 및 권한 관리 133

4. 데이터베이스 객체 및

권한 관리

이장에서는 알티베이스 데이터베이스 내의 객체의 생성, 운영방법

및 사용자와 객체 권한 관리 체계에 대해서 설명한다.


데이터베이스 객체 개요 데이터베이스 객체는 특정 스키마에 속하여 관리되는 스키마 객

체와 스키마와 관계없이 데이터베이스 전체에서 관리되는 비스키

마 객체로 구분할 수 있다. 이 장에서는 스키마 객체와 비스키마

객체를 구분하고 각각에 포함되는 데이터베이스 객체에 대해 설

명한다.

스키마 객체 스키마란 데이터 또는 객체들의 논리적 집합으로 한 사용자는 하

나의 스키마를 소유하고 SQL문에 의해 관리한다. 이러한 스키마

에 포함되는 객체를 스키마 객체라고 하고 알티베이스는 다음과

같은 스키마 객체를 제공한다.

테이블(Table) 테이블은 가장 기본적인 데이터 저장 단위로 칼럼들로 구성된 레

코드들의 집합이다.

알티베이스 테이블은 데이터의 저장 공간에 따라 메모리 테이블

과 디스크 테이블로 구별되고, 생성자에 따라 시스템이 생성하고

관리하는 시스템 테이블과 사용자가 생성하는 일반 테이블로 구

별될 수도 있다.

또한 이중화 대상 테이블의 경우 테이블 관리가 특별하며 대용량

테이블의 경우에도 주의를 요하는 사항들이 있다.

이에 대해서는 테이블 관리에서 자세히 설명한다.

제약조건(Constraint) 제약 조건이란 테이블의 데이터 삽입 또는 변경 시 제약 사항을

설정하여 데이터의 일관성을 유지할 수 있도록 하는 조건을 의미

한다.

제약조건의 대상에 따라 칼럼 제약조건과 테이블 제약조건으로

구별할 수 있고, 제약 사항에 따라 다음과 같은 종류의 제약조건

을 제공한다.

- NOT NULL / NULL 제약조건

- 유일 키(unique key) 제약조건

- 프라이머리 키(primary key) 제약조건

- 외래 키(foreign key) 제약조건

- TIMESTAMP 제약조건


이에 대해서는 제약조건 관리에서 자세히 설명한다.

인덱스(Index) 인덱스는 테이블 내 레코드들의 빠른 접근이 가능하도록 하는 구

조체로 테이블에 인덱스를 생성하여 DML문의 처리 성능을 향상

시킬 수 있다. 이에 대해서는 인덱스 관리에서 자세히 설명한다.

뷰(View) 뷰(View)란 실제 데이터 자체는 포함하지 않고, 하나 이상의 테

이블 또는 뷰를 기반으로 한 논리적 테이블(logical table)을 의미

한다. (알티베이스는 변경가능 뷰(Updatable view)와 머티어리얼

라이즈 뷰(materialized view)는 제공하지 않는다.)

이에 대해서는 뷰 관리에서 자세히 설명한다.

시퀀스(Sequence) 알티베이스는 유일 키를 생성하기 위해 키생성자로 시퀀스를 제

공한다.

이에 대해서는 시퀀스 관리에서 자세히 설명한다.

시노님(Synonym) 테이블, 시퀀스, 뷰, 저장 프로시저 및 저장 함수에 대한 별칭

(alias)을 부여하여 객체 사용에 대한 투명성을 부여할 수 있는

시노님을 제공한다.

이에 대해서는 시노님 관리에서 자세히 설명한다.

저장 프로시저 및 저장 함수(Stored Procedure or Function) 저장 프로시저(Stored Prodedure)란 SQL문들과 흐름 제어문, 할

당문, 오류 처리 루틴 등을 이용해 전체 업무 절차를 프로그래밍

하여 하나의 모듈로 만든 후 데이터베이스에 영구적으로 저장해

두고, 모듈 이름만을 호출하여 전체 업무 절차를 서버에서 한번에

수행하는 데이터베이스 객체이다.

하나의 리턴 값을 가지지 않느냐와 가지느냐에 따라 저장 프로시

저와 저장 함수로 구별된다.

이에 대해서는 저장 프로시저 및 저장 함수 관리에서 자세히 설

명한다.

데이터베이스 트리거(Database Trigger)


트리거란 테이블에 데이터가 삽입, 삭제, 또는 갱신될 때 시스템

에 의해 묵시적으로 작동되어 특정 작업 절차를 자동으로 수행할

수 있도록 하는 저장 프로시저다. 사용자는 테이블에 대해 제약조

건과 트리거를 정의하여 데이터의 일관성을 유지할 수 있다.

이에 대해서는 트리거 관리에서 자세히 설명한다.

비스키마 객체 특정 스키마에 소속되지 않고 전체 데이터베이스 수준에서 관리

되는 객체를 비스키마 객체라고 하고 알티베이스는 다음과 같은

비스키마 객체를 제공한다.

디렉토리(Directory) 저장프로시저의 파일 제어 기능은 운영 체제의 텍스트 파일에 대

한 읽기 및 쓰기 기능을 제공한다. 이 기능을 이용하여 사용자는

저장프로시저 실행에 대한 별도의 메시지 등을 파일에 남길 수도

있으며, 파일로 결과를 리포팅 하거나 파일로부터 데이터를 읽어

와 테이블에 삽입하는 등 다양한 작업을 수행할 수 있다. 이러한

저장프로시저 파일 제어 기능에서 사용하는 파일들을 저장하는

디렉토리 객체이다.

디렉토리에 대한 자세한 기능과 디렉토리 관리에 대해서는 SQL Users Manual을 참조한다.

저장프로시저의 파일 제어 기능에 대해서는 Stored Procedure Users Manual을 참조한다.

이중화(Replication) 이중화는 시스템이 자동으로 한 지역서버에서 원격 서버로 데이

터를 전송해 다른 서버들간의 테이블 데이터를 동일하게 유지해

줄 수 있도록 하는 객체이다.

이중화에 대한 자세한 기능과 이중화 관리에 대해서는

Replication Users Manual을 참조한다.

테이블스페이스(Tablespace) 테이블스페이스는 가장 큰 논리적 데이터 저장 단위로 데이터베

이스는 여러 개의 테이블스페이스 단위로 나뉘어져 관리된다.

테이블스페이스는 크게 저장공간을 기준으로 메모리 테이블스페

이스(SYS_TBS_MEMORY)와 이를 제외한 디스크 테이블스페이스

로 구분되며 최초 데이터베이스 생성시에 만들어지며 삭제될 수

없는 SYSTM 테이블스페이스와 필요에 따라 생성과 삭제가 자유


롭고 테이블과 인덱스만을 저장할 수 있는 사용자(USER) 테이블

스페이스로 종류를 구별한다.

테이블스페이스 관리에 대한 자세한 내용은 제6장. 테이블스페이

스 관리를 참조한다.

사용자(User) 스키마의 소유자로 알티베이스 접속을 위해서는 사용자 계정이

필요하다. 사용자는 시스템에 의해 생성되어 전체 시스템 관리자

인 시스템 사용자와 일반 사용자로 구별된다.

일반 사용자의 경우 데이터베이스에 접근하여 데이터를 조작하기

위해서는 적절한 권한 관리를 요한다.

이에 대해서는 사용자 관리와 권한 관리에서 자세히 설명한다.


테이블 관리 테이블은 가장 기본적인 데이터 저장 단위로 칼럼들로 구성된 레

코드들의 집합으로 이 절에서는 테이블과 관련된 용어 설명, 테이

블 관리 개념과 방법들에 대해 설명한다.

메모리 테이블과 디스크 테이블 테이블의 저장 공간에 따라 메모리 테이블과 디스크 테이블로 구

별된다. 테이블 생성 시 테이블이 속한 테이블스페이스가 메모리

테이블스페이스인지 디스크 테이블스페이스인지에 따라 메모리

테이블과 디스크 테이블로 생성된다.

시스템 테이블과 일반 사용자 테이블 시스템이 내부적으로 생성하고 관리하는 시스템 테이블과 일반

사용자에 의해 생성되고 관리되는 일반 사용자 테이블로 테이블

의 종류를 분류할 수 있다.

시스템 테이블은 데이터 딕셔너리로, 데이터베이스 객체 정보를

저장하는 메타 테이블과 시스템 프로세스 정보를 저장하는 프로

세스 테이블로 나뉘어지며, 프로세스 정보는 다시 고정 테이블과

성능 뷰로 나뉘어진다. 이에 대해서는 데이터 딕셔너리 장에서 자

세히 설명한다.

대용량 메모리 테이블 대용량 메모리 테이블의 경우 SQL문 수행 시 다음과 같은 주의

를 요한다.

대용량 메모리 테이블에 DDL 수행하기 대용량 테이블에 DDL 문을 수행하고자 하는 경우 ADD

COLUMN이나 DROP COLUMN을 직접 수행하는 것 보다

iLoader 유틸리티를 이용해서 데이터를 다운로드 받고, 해당 테

이블을 새로운 스키마로 재 생성한 후에 다운로드 받은 데이터를

iLoader 유틸리티를 이용해서 업로드하는 방식을 권장한다.

대용량 메모리 테이블에 DML 수행하기 데이터 크기가 크지 않은 테이블에 대해 DML을 수행하는 것은

운영자가 잘못된 데이터 조작을 하지 않는 한 알티베이스의 성능

이나 운용 상에 있어서 크게 문제를 발생시키지 않는다. 그러나

레코드 개수가 많은 대용량의 테이블에 대해 하나의

update/delete 문을 이용하여 DML을 수행하는 것은 그 DML을


수행하는 트랜잭션이 오랜 시간 동안 진행 중인 상태로 있게 할

수 있다. 이처럼 오랜 시간 동안 진행 중인 트랜잭션(long-

duration transaction)이 존재하는 경우 알티베이스를 운용함에

있어 다음과 같은 심각한 문제를 야기할 수 있다.

테이블에 대한 배타적 접근 트랜잭션의 수행 시간이 길어지면 그 트랜잭션이 내부적으로 획

득하고 있는 록(lock) 때문에 그 테이블에 접근하고자 하는 다른

트랜잭션들은 모두 수행을 중지하게 된다. 또한 변경되는 레코드

의 크기가 일정 크기 이상이 되면 lock escalation이 발생하므로

검색만 하는 트랜잭션이라 하더라도 그 테이블에 대해 접근할 수

없는 경우가 발생될 수도 있다.

알티베이스 메모리 사용량 증가 알티베이스에서 사용되는 모든 레코드(버전)에는 garbage

collector가 삭제해야 할 레코드들을 구분하기 위해 SCN(Serial

Commit Number)이 사용된다. 커밋하지 않은 트랜잭션이 사용하

고 있는 SCN보다 작은 SCN을 가지는 레코드에 대해서만

garbage collector는 삭제 작업을 수행한다. 그러므로, 장기간 수

행 중인 트랜잭션이 존재하면 garbage collector는 자신이 처리

해야 할 레코드가 없는 것으로 간주하고 레코드 삭제 작업을 수

행하지 않는다.

따라서, bulk update/delete를 장기간 수행하는 트랜잭션이 존재

하는 경우 garbage collector의 동작이 멈추게 되어 불필요한 버

전이 계속 쌓이는 현상이 발생하며 이에 따라 데이터베이스의 크

기가 증가하게 되며 알티베이스 메모리 사용량이 증가하게 된다.

로그 파일이 저장되는 파일 시스템 full 가능성 트랜잭션이 생성하는 로그 파일들은 이중화 또는 재시작 회복을

위해 필요한 로그들을 제외하고는 체크포인트 수행시 디스크에서

삭제된다. 재시작 회복에 필요한 로그 파일은 체크포인트 검사 시

수행 중이던 트랜잭션들이 생성한 로그 파일 중 최소 로그 파일

을 의미한다.

따라서, 장기간 수행 중인 트랜잭션이 존재하면 체크포인트가 발

생하더라도 로그 파일들은 재시작 회복을 위해 계속 지울 수 없

는 상태로 남아있기 때문에 로그 파일이 저장되는 파일 시스템에

더 이상 로그를 저장하지 못하는 상태가 될 수 있다.

페이지 리스트 다중화 메모리 테이블의 경우 로그파일그룹(Log File Group)에 따라 사

용하는 자원 또한 병렬화되어야 한다. 따라서 LFG의 개수에 따라

테이블에서 사용하는 페이지 리스트 역시 같은 개수로 다중화되

게 된다. 로그파일그룹 기능에 대한 상세한 정보는 이 매뉴얼 ‘알

티베이스 튜닝’ 장의 해당 내용을 참조한다.


이중화된 테이블 주의 사항

이중화 객체에 포함된 테이블에 대해서는 DDL이 수행될 수 없

다. DDL문을 수행하기 위해서는 반드시 두 서버에서 이중화를 중

지하고 해당 테이블을 이중화에서 삭제한 후 각각의 서버에서

DDL을 수행해야 한다. DDL이 성공적으로 수행된 후 이중화에

해당 테이블을 다시 등록한 후 이중화를 시작하여야 한다.

1. 서비스 중지

alter replication rep1 stop;

alter replication rep1 drop table from sys.t1 to sys.t1;

check replication_gap;

4. DML 대상 테이블을 이중화에서 제거

3. 이중화 중지

2. 이중화 완료 여부 검사

4. DML 대상 테이블을 이중화에서 제거

3. 이중화 중지

2. 이중화 완료 여부 검사

alter replication rep1 start;

alter replication rep1 add tablefrom sys.t1 to sys.t1;

7. 이중화 시작

6. DML 대상 테이블을 이중화에 추가

8. 서비스 개시

7. 이중화 시작

6. DML 대상 테이블을 이중화에 추가

create index idx1 on t1(col1);5. 인덱스 생성 5. 인덱스 생성

A, B 두 서버에서작업 완료 여부 확인

A, B 두 서버에서작업 완료 여부 확인

Server A Server B

<

그림 4-１> 이중화 구조에서 인덱스 추가하기

생성 테이블은 CREATE TABLE문을 사용하여 생성할 수 있다.


테이블 생성 시에는 칼럼 정의, 제약조건, 테이블이 저장될 테이

블스페이스, 테이블에 삽입할 수 있는 최대 레코드 수, 테이블을

위한 저장 관리자 내 페이지에 대한 공간 활용율 등을 명시할 수

있다.

예제 CREATE TABLE book( 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 employee WHERE dno = HSS_BYTESC002;

칼럼 정의 시 주의 사항 VARCHAR 타입의 FIXED/VARIABLE 속성

VARCHAR 데이터 타입의 경우 FIXED/VARIABLE 속성을 사용자

가 지정할 수 있다.사용자가 이 속성을 지정하지 않은 경우에 데이

터베이스는 내부적으로 특정 길이(메모리 테이블: 126, 디스크 테

이블:14) 이하일 경우 VARCHAR 타입이더라도 FIXED로 취급한

다. FIXED일 경우에는 비록 데이타 타입이 VARCHAR일지라도

CHAR 데이터 타입처럼 저장공간을 해당 길이만큼 미리 할당받으

며 VARIABLE일 경우에는 데이터 길이 만큼만 저장공간에 할당된

다. VARCHAR 데이타 타입의 데이터 비교 방식은

FIXED/VARIABLE 형식에 관계없이 NON-BLANK PADDING 비

교 방식을 따른다.

다음 그림은 FIXED/VARIABLE로 선언된 칼럼이 레코드 내에서

저장되는 방식을 나타낸다.. FIXED일 경우에는 비록 데이타 타입

이 VARCHAR일지라도 CHAR 데이터 타입처럼 메모리상에 미리

해당 길이만큼 할당받으며 VARIABLE일 경우에는 데이터 길이 만

큼만 메모리 상에 할당된다. VARCHAR 데이타 타입의 데이터 비

교 방식은 FIXED/VARIABLE 형식에 관계없이 non-blank

padding 비교 방식을 따른다.

다음 그림은 FIXED/VARIABLE로 선언된 칼럼이 레코드 내에서

저장되는 방식을 나타낸다.


CREATE TABLE item ( name varchar(20) FIXED, description varchar(1000) VARIABLE);

Record Header name description

real data of description

20

13

16

INSERT INTO item VALUES('msjung', 'variable test');

<그림 4-２> VARCHAR 칼럼 구조

테이블 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문을 사용하여 다음

과 같은 테이블 정의를 변경할 수 있다.

테이블 이름

새로운 칼럼 추가

기존 칼럼 삭제

칼럼 기본 값

칼럼 이름

1 Varchar variable 로 선언된 칼럼의 실제 데이터를 저장하기 위해 데이터 크기만큼 매번 메모리

할당을 받게 되는 경우 성능에 영향을 줄 수 있으므로 알티베이스는 4K, 8K, 16K 등 내부적으로

정해진 길이의 슬롯을 미리 준비하며, 데이터 입력 시 실제 데이터를 저장할 수 있는 최적의 크기를

갖는 슬롯을 선택하여 varchar variable 로 선언된 칼럼의 실제 데이터를 저장한다.


제약 조건 추가

제약 조건 삭제

메모리 테이블 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;

삭제 테이블은 DROP TABLE문을 사용하여 삭제할 수 있다.

예제 DROP TABLE employee;

전체 레코드 삭제 테이블의 레코드는 DELETE문을 사용해 삭제할 수도 있지만

TRUNCATE TABLE문을 이용해 삭제할 수도 있다. DELETE문

은 내부적으로 레코드를 건건이 삭제하는 것이고 TRUNCATE

TABLE문은 DDL문으로 내부적으로 DROP TABLE문을 수행하고

같은 정의의 테이블을 재생성한다. 따라서 TRUNCATE TABLE

문을 수행하면 테이블 수준의 록(lock)이 잡히며 TRUNCATE

TABLE문이 성공적으로 수행된 이후에는 ROLLBACK문을 사용

해 삭제된 데이터를 복구할 수 없다.

테이블 레코드 조작 테이블의 레코드들은 DML문을 사용하여 조작할 수 있다.

INSERT

DELETE


UPDATE

SELECT

위에서 언급한 바와 같이 알티베이스 운용 중에 대용량의 데이터

에 대해 bulk update/delete를 수행하는 것은 위험 요소를 갖고

있으므로 ODBC 혹은 전처리기 프로그램을 이용하여 응용프로그

램 작성 시 레코드 별로 update/delete 후 커밋하도록 하는 것이

바람직하다.

다음은 bulk update/delete를 피하고 레코드별로 update를 수행

하는 C/C++ Precompiler 프로그램 작성 예이다.

isql>update t1 set col1=2 where col1 > 1000;

(a) isql 상에서 bulk-update 수행 (b) ses를 이용하여 레코드별 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;} .......

위 그림의 (b)처럼 전처리기 프로그램을 작성하는 경우 반드시

auto commit 모드여야 하며 non-autocommit 모드로 설정한 후

update가 끝난 시점에 명시적으로 commit을 호출하는 형식의 프

로그램을 작성하는 것은 바람직하지 않다.

관련 SQL 문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL Users Manual을 참조한다.

CREATE TABLE

ALTER TABLE

RENAME TABLE

TRUNCATE TABLE

LOCK TABLE

INSERT

DELETE


UPDATE

SELECT


큐 테이블 관리 알티베이스는 메시지 큐잉 기능을 이용하여 데이터베이스와 사

용자 프로그램간의 비동기 데이터 통신을 지원한다. 이때 사용되

는 큐 테이블은 데이터베이스 오브젝트의 하나로써 다른 데이터

베이스 테이블과 마찬가기로 DDL과 DML로 제어할 수 있다.

생성 사용자는 CREATE QUEUE 문장을 이용해서 큐를 생성할 수 있

으며 이때 데이터베이스는 큐의 이름에 해당하는 테이블을 생성

하고 이를 큐 테이블이라고 부른다. 큐 테이블은 다음과 같은 구

조를 가진다.

Column name Type Length Default Description MSGID BIGINT 8 - 메시지 식별자

CORRID INTEGER 4 0 사용자가 지정한 메시

지 식별자 MESSAGE VARCHAR Message length - 메시지

큐 테이블의 칼럼 명이나 테이블 명은 사용자가 임의로 변경할

수 없으며, MSGID 칼럼에는 자동으로 Primary Key가 생성된다.

MSGID을 관리하기 위해서 데이터베이스는 내부적으로 QUEUE

이름_NEXT_MSG_ID라는 이름의 SEQUENCE를 생성하여

MSGID를 UNIQUE하게 관리하며, 사용자는

SYSTEM_SYS_TABLES_ 메타테이블에서 테이블 타입 W인 것들

을 조회하면 이 SEQUENCE에 대한 정보를 조회할 수 있다.

이 SEQUENCE는 큐 테이블이 삭제 될 때 까지 유지 되어야 하

기 때문에 DROP SEQUENCE문장으로 임의로 삭제 할 수 없다.

큐 테이블은 SYSTEM.SYS_TABLES에서 테이블 type Q로 저장

된다.

사용자는 필요에 따라서 CREATE INDEX 문장을 이용해서 큐 테

이블에 인덱스를 생성할 수 있다.

예제 CREATE QUEUE Q1;

변경


CREATE QUEUE문장으로 생성된 큐 테이블은 DROP QUEUE문

장으로 삭제 될 때까지 ALTER TABLE등의 문장을 이용해서 구조

를 변경할 수 없다. 단, 사용자는 ENQUEUE/DEQUEUE,

DELETE, SELECT등의 문장을 이용해서 데이터 조작만 할 있다.

삭제 테이블은 DROP QUEUE문을 사용하여 삭제할 수 있다.

예제1 DROP QUEUE Q1;

예제2

큐에 적재된 메시지만 삭제하고자 하는 경우에는 TRUNCATE

QUEUE 문장을 이용할 수 있다.

TRUNCATE QUEUE Q1;

테이블 데이터 조작 큐 테이블의 레코드들은 다음과 같은 DML문을 사용하여 조작할

수 있다.

ENQUEUE

DEQUEUE

DELETE

SELECT


CREATE QUEUE

DROP QUEUE

ENQUEUE

DEQUEUE


제약조건 관리 제약 조건이란 테이블의 데이터 삽입 또는 변경 시 제약 사항을

설정하여 데이터의 일관성을 유지할 수 있도록 하는 조건으로 이

절에서는 제약조건의 종류와 관리 방법에 대해 설명한다.

종류 NOT NULL / NULL 제약조건 칼럼에 NULL을 삽입할 수 없는 제약조건으로 칼럼 단위로 정의

할 수 있다. NULL 제약조건은 NULL도 허용하는 것으로 칼럼에

대해 NOT NULL 제약조건을 명시하지 않으면 기본적으로 NULL

을 허용한다.

유일 키(unique key) 제약조건 하나 이상의 칼럼에 대해 정의할 수 있는 제약조건으로 칼럼 또

는 칼럼의 조합에 대해 중복 값을 삽입할 수 없는 제약조건이다.

유일 키 제약조건을 정의하면 내부적으로 유일 키 인덱스가 생성

된다.

프라이머리 키(primary key) 제약조건 프라이머리 키 제약조건은 유일 키 제약조건에 NOT NULL 제약

조건까지 존재하는 제약조건이다. 하나 이상의 칼럼에 대해 프라

이머리 키 제약조건을 정의할 수 있고 내부적으로 유일 키 인덱

스가 생성되며 프라이머리 키에 포함되는 모든 칼럼은 NULL을

삽입할 수 없다.

외래 키(foreign key) 제약조건 참조 무결성 제약조건(referential integrity constraint)으로 참조

관계에 있는 테이블 간의 데이터 일관성을 유지할 수 있도록 해

주는 제약조건이다.

TIMESTAMP 제약조건 칼럼의 값으로 레코드의 삽입 또는 갱신 시 시스템 시간 값을 설

정하는 제약조건이다. 주로 이중화 대상 테이블의 하나의 칼럼에

대해 정의해 사용한다.

칼럼 제약조건과 테이블 제약조건


칼럼 정의 시 하나의 칼럼에 대해 정의한 제약조건을 칼럼 제약

조건이라 하고 여러 개의 칼럼들에 대해 하나의 제약조건을 테이

블 정의 하단 부분에 정의하는 것을 테이블 제약조건이라고 한다.

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문을 이용해 정의된 제약조건을 삭제할 수 있다.

예제 ALTER TABLE book DROP UNIQUE(bno);

관련 SQL 문


다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL Users Manual을 참조한다.

CREATE TABLE

ALTER TABLE


인덱스 관리 인덱스는 테이블 내 레코드들의 빠른 접근이 가능하도록 하는 구

조체로 이 절에서는 인덱스의 종류와 관리 및 활용 방법에 대해

설명한다.

인덱스 타입 알티베이스는 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는 각 공간 객체를 감싸는 최소 사각형인 MBR(Minimum

Bounding Rectagle)을 이용하여 일차로 조건 필터링(Filtering)을

수행한 후, 이 결과로 남은 객체에 대해 정확한 인덱스 검색 조건

을 체크하는 리파인먼트(Refinement)를 수행하는 방식으로 대상

객체를 찾아낸다. R-Tree의 삽입, 삭제, 노드 스플릿(Split), 노드

머지(Merge) 알고리즘은 MBR을 기준으로 한다는 점만 제외하고

는 B-Tree와 유사하다.

유일 키 인덱스 (Unique)

유일 키 인덱스(Unique Index) 인덱스 칼럼에 대해 중복 값을 허용하지 않는 인덱스이다.


중복 키 인덱스(Non-unique Index) 인덱스 칼럼에 대해 중복 값을 허용하는 인덱스이다. 유일 키 옵

션을 지정하지 않으면 기본적으로 중복 값을 허용하는 인덱스로

생성된다.

유일 키(Unique Key)와 프라이머리 키(Primary Key)의 차이 유일 키와 프라이머리 키 모두 중복 값을 허용하지 않는 것은 공

통이나 NULL의 허용 여부에 따라 유일 키와 프라이머리 키로 구

별된다. 프라이머리 키의 경우 NULL을 허용하지 않는다.

복합 키 인덱스 (Composite Index)

단일 키 인덱스(Non-composite Index) 인덱스 대상 칼럼이 하나인 인덱스이다.

복합 키 인덱스(Composite Index) 여러 개의 칼럼들의 조합에 대해 하나의 인덱스를 생성하는 경우

복합 키 인덱스라고 한다.

인덱스 저장

영구 저장 인덱스(Persistent Index) 알티베이스의 메모리 테이블에 걸린 인덱스는 영구적(Persistent)

데이터베이스 영역을 사용하지 않고 임시 메모리 영역에 생성된

다. 따라서, 알티베이스는 시스템을 시작할 때마다 메모리 테이블

에 걸린 모든 인덱스를 다시 만들어낸다. 만일 데이터베이스의 크

기가 매우 크면 인덱스의 재생성 시간도 비례하여 오래 걸리게

된다.

영구 저장 인덱스는 이런 현상을 방지하기 위해, 시스템이 정상

셧 다운 되는 경우에 임시 메모리 영역에 구현된 인덱스를 파일

로 만들어 저장하였다가, 다시 시스템이 시작되면 이 파일로부터

인덱스를 생성해 내어, 부트 업 시간을 단축 시킬 수 있다.

비영구 저장 인덱스(Non-persistent Index)


알티베이스의 정상 셧 다운 시에 파일로 저장되지 않는 일반 인

덱스로써, 인덱스 생성시 PERSISTENT=ON 옵션을 주지 않으면

기본적으로 비영구 저장 인덱스로 생성된다.

인덱스 생성 인덱스는 테이블 제약조건을 통해서 내부적으로 생성될 수도 있

고, CREATE INDEX문을 사용해 사용자가 명시적으로 생성할 수

도 있다.

예제

칼럼별 ordering을 지정

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;

인덱스 변경 인덱스 활성 및 비활성 여부, 인덱스의 영구 저장 여부를 ALTER

INDEX문을 사용하여 변경할 수 있다.

예제 ALTER INDEX EMP_IDX1 SET PERSISTENT = ON;

인덱스 삭제 인덱스의 삭제는 DROP INDEX문을 사용하여 명시적으로 삭제하

거나 관련 제약조건을 삭제하여 묵시적으로 삭제될 수 있다.

예제 DROP INDEX emp_idx1;



CREATE TABLE

ALTER TABLE

CREATE INDEX

ALTER INDEX

DROP INDEX


뷰 관리 뷰(View)란 실제 데이터 자체는 포함하지 않고, 하나 이상의 테

이블 또는 뷰를 기반으로 한 논리적 테이블(logical table)로 이

절에서는 뷰의 관리 방법에 대해 설명한다.

베이스 테이블(base table)과 뷰 베이스 테이블이란 뷰가 접근하여 데이터를 읽어 오는 테이블로

하나의 뷰에는 여러 개의 베이스 테이블이 존재할 수 있다.

알티베이스가 지원하는 뷰는 읽기 전용 뷰로, 변경 가능 뷰

(updatable view) 또는 실체화 뷰(materialized view)는 지원하지

않는다.

생성 뷰는 CREATE VIEW문을 사용하여 생성할 수 있다.

예제 CREATE VIEW avg_sal AS SELECT DNO, AVG(salary) emp_avg_sal -- salary average of each department FROM employee GROUP BY dno;

변경 이미 존재하는 뷰에 대해 뷰의 내용(SELECT문)만 변경하고자 하

는 경우에는 CREATE OR REPLACE VIEW문을 사용한다.

예제 CREATE OR REPLACE VIEW emp_cus AS SELECT DISTINCT o.eno, e.ename, c.cname FROM employee e, customer c, orders o WHERE e.eno = o.eno AND o.cno = c.cno;

뷰의 경우 베이스 테이블들을 참조하므로 베이스 테이블에 DDL

문이 발생하여 베이스 테이블의 정의가 변경되는 경우 관련 뷰들

은 수행 불가능한 무효한 상태가 될 수 있다. 이런 경우 ALTER

VIEW문을 사용해 뷰의 수행 가능 여부를 검증할 수 있다.

예제 ALTER VIEW avg_sal COMPILE;


이 외에 기존에 존재하는 뷰의 이름만 다른 이름으로 변경하고자

할 경우 RENAME문을 사용하여 변경할 수 있다.

삭제 뷰는 DROP VIEW문을 사용하여 삭제할 수 있다.

예제 DROP VIEW avg_sal;


CREATE VIEW

ALTER VIEW

RENAME VIEW

DROP VIEW

SELECT


시퀀스 관리 알티베이스에서는 키 생성자(Key Generator)로서 시퀀스

(sequence)가 제공되며 캐싱해서 사용하기 때문에 속도 저하가

없다.

시퀀스의 용도 키 생성자로 사용되는 시퀀스(sequence)는 DML 문에서 임의의

칼럼에 값을 설정하기 위해 주로 사용된다. 시퀀스를 사용하는 구

문은 sequence 이름.nextval, sequence 이름.currval이 있다.

Sequence 이름.nextval은 시퀀스의 다음 값을 사용하고,

sequence 이름.currval은 시퀀스의 현재 값을 사용한다.

시퀀스 생성 후 최초로 수행하는 연산이 시퀀스의 sequence 이

름.currval을 이용하는 연산일 수 없다. sequence 이름.currval을

사용하기 위해서는 시퀀스 생성 이후 반드시 sequence 이

름.nextval을 먼저 사용한 후이어야 한다.

시퀀스의 nextval을 사용할 때마다 시퀀스의 값은 시퀀스 내부적

으로 시퀀스의 증감분(increment by)만큼 증가한다. 시퀀스의 증

감분은 시퀀스 생성시 명시적으로 그 값이 주어지지 않는 경우

기본적으로 1이다.

INSERT 문에서의 시퀀스 사용 시퀀스를 사용하여 키를 생성하여 레코드를 삽입하는 예제이다.

예제 create sequence seq1; insert into t1 values (seq.nextval); *.sequence를 이용한 입력, sequence 생성시 초기값

은 1이므로 t1에는 1이 입력되며 sequence의 nextval은 1 증가한 2가 된 상태이다.


생성 CREATE SEQUENCE문을 사용하여 시퀀스를 생성하며 시퀀스

생성 구문에 사용되는 옵션들은 다음과 같다.

START WITH: 시퀀스의 시작 값

INCREMENT BY: 시퀀스의 증감 분

MAXVALUE: 시퀀스의 최대값

MINVALUE: 시퀀스의 최소값

CYCLE

시퀀스가 최대값 또는 최소값 한계에 도달하면 해당 시퀀스의 다

음 값을 할당하기 위하여 오름차순 시퀀스인 경우는 최소값을, 내

림차순 시퀀스인 경우는 최대값부터 시퀀스의 값이 다시 순환한

다.

CACHE 해당 시퀀스 값을 보다 빠르게 액세스하기 위하여 CACHE에 명

시된 값만큼 시퀀스 값들을 미리 생성하여 메모리에 캐시한다. 시

퀀스 캐시는 시퀀스를 처음 참조할 때 채워지며 다음에 시퀀스

값을 요청할 때마다 캐시된 시퀀스에서 검색된다. 마지막 캐시된

시퀀스 값을 사용한 이후에 발생한 시퀀스 요청에 대해서는 새로

시퀀스 값을 생성하여 메모리에 캐시하고 그 캐시에서 검색하여

결과값을 반환한다. 시퀀스 생성시 기본 값은 20이다.

예제

기본적인 시퀀스 생성하기 (1부터 시작하며 1씩 증가)

CREATE SEQUENCE seq1 ;

짝수를 생성해 내고 순환하게 하기 (0 – 100) 생성

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;


CREATE SEQUENCE

ALTER SEQUENCE

DROP SEQUENCE


시노님 관리 알티베이스는 테이블, 시퀀스, 뷰, 저장 프로시저 및 저장 함수에

대한 별칭(alias)을 부여할 수 있는 시노님을 제공한다.

시노님 이용 시 장점 다음과 같은 경우 데이터베이스 시노님을 사용하면 많은 이점이

있다.

특정 객체를 생성한 사용자와 객체의 원래 이름을 숨기고 싶

은 경우

SQL문 사용의 단순화하고자 하는 경우

사용자 변경에 따른 응용프로그램의 변경 최소화하고자 하는

경우

생성 CREATE SYNONYM문을 사용하여 생성한다.

예제

CREATE SYNONYM my_dept FOR dept;

테이블 dept의 별칭으로 my_dept 시노님을 생성하는 예제이다.

삭제 DROP SYNONYM문을 사용하여 명시한 시노님을 삭제한다.

예제 DROP SYNONYM my_dept;


CREATE SYNONYM


DROP SYNONYM


저장 프로시저 및 저장 함수 관리 저장 프로시저(Stored Prodedure)란 SQL문들과 흐름 제어문, 할

당문, 오류 처리 루틴 등을 이용해 전체 업무 절차를 프로그래밍

하여 하나의 모듈로 만든 후 데이터베이스에 영구적으로 저장해

두고, 모듈 이름만을 호출하여 전체 업무 절차를 서버에서 한번에

수행하는 데이터베이스 객체로 이 절에서는 저장 프로시저 관리

방법에 대해 설명한다.

저장 프로시저와 저장 함수의 구별은 하나의 리턴값의 존재 유무

에 따라 구별되는데 특별한 언급이 없는 한 모든 설명들은 공통

사항이다.

이 절에서는 저장 프로시저 관리에 대한 간단한 예제에 대해서만

설명하고 저장 프로시저에서 사용하는 용어와 개념, 자세한 관리

방법에 대해서는 Stored Procedure Users Manual을 참조한다.

종류 저장 프로시저(Stored Procedure)

입력 인자, 출력 인자, 입출력 인자를 가지고 바디(body) 내에 정

의된 조건에 따라 여러 SQL문을 한번에 수행하는 데이터베이스

프로시저이다. 리턴값을 가지지 않으며 출력 인자와 입출력 인자

들을 통해 클라이언트에게 값을 전달한다. 하나의 리턴 값을 갖지

않기 때문에 다른 SQL문의 expression 내에 피연산자로 사용될

수 없다.

저장 함수(Stored Function)

저장 프로시저와 동일하나 하나의 리턴 값을 가지는 함수를 의미

한다. 저장 프로시저와 달리 하나의 리턴 값을 가지므로 다른

SQL문의 expression 내에 시스템 제공 함수들과 같이 피연산자

로 사용할 수 있다.

타입 세트(Type Set)

저장 프로시저의 사용자 정의 타입들을 정의한 집합이다. 주로 저

장 프로시저끼리 파라미터 또는 리턴값으로 사용자 정의 타입을

주고받을 때 사용한다.

저장 프로시저관련 문장

종류 관련 문장 설명


CREATE [OR REPLACE] PROCEDURE 문

새로운 저장 프로시저를 생성

하거나 이미 생성된 저장 프로시저의 정의를 변경하는 SQL문이다.

CREATE [OR REPLACE] FUNCTION 문

새로운 저장 함수를 생성하거

나 이미 생성된 저장 함수의 정의를 변경하는 SQL문이다.

생성

CREATE [OR REPLACE] TYPESET 문

타입 세트를 생성 또는 변경하는 문장이다.

ALTER PROCEDURE 문

저장 프로시저 생성 이후 관련 객체들의 정의가 변경되어 현재 저장 프로시저의 실행계

획 트리가 최적화된 상태가 아닐 경우 이를 재 컴파일하

여 최적화된 실행 계획 트리

를 재 생성하는 SQL문이다. 변경

ALTER FUNCTION 문

저장 함수 생성 이후 관련 객체들의 정의가 변경되어 현재 저장 함수의 실행계획 트리가 최적화된 상태가 아닐 경우 이를 재 컴파일하여 최적화된 실행 계획 트리를 재 생성하

는 SQL문이다.

DROP PROCEDURE 문 생성된 저장 프로시저를 삭제

하는 SQL문이다.

DROP FUNCTION 문 생성된 저장 함수를 삭제하는 SQL문이다.

삭제

DROP TYPESET 문 생성된 타입 세트를 삭제 하는 문장이다.

EXECUTE 문 저장 프로시저 또는 저장 함수를 실행하는 SQL문이다.

실행 FUNCTION

SQL문 내에서 built-in function과 같은 형태로 사용

할 수 있다.

생성 저장 프로시저는 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; /

저장 프로시저와 관련된 테이블, 시퀀스, 이 저장 프로시저가 호

출하는 다른 저장 프로시저 또는 저장 함수가 생성 시 정의된 상

태와 달라 현재 이 저장 프로시저의 실행 계획 트리로 실행할 수


없을 경우 현재 이 저장 프로시저는 무효한(invalid) 상태라고 한

다.

예를 들면 처음 저장 프로시저 생성 시 존재하던 인덱스가 삭제

된 경우 이전 실행 계획 트리는 인덱스를 통해 테이블에 접근하

도록 계획되어 있으므로 이전 실행 계획을 사용해 테이블에 접근

할 수 없게 된다.

ALTER PROCEDURE문은 무효한 저장 프로시저를 재 컴파일하

여 유효한(valid) 상태의 실행 계획을 재 생성하는 기능을 수행한

다.

예제 ALTER PROCEDURE proc1 COMPILE;

삭제 저장 프로시저는 DROP PROCEDURE문을 사용하여 삭제할 수

있다.

예제 DROP PROCEDURE proc1;

관련 SQL 문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 Stored Procedure Users Manual을 참조한다.

CREATE PROCEDURE

CREATE FUNCTION

CREATE TYPESET

ALTER PROCEDURE

ALTER FUNCTION

DROP PROCEDURE

DROP FUNCTION

DROP TYPE SET

EXECUTE


트리거 관리 트리거란 테이블에 데이터가 삽입, 삭제, 또는 갱신될 때 시스템

에 의해 묵시적으로 작동되어 특정 작업 절차를 자동으로 수행할

수 있도록 하는 저장 프로시저로 이 절에서는 트리거 관리 방법

에 대해 설명한다.

트리거 구성 요소

트리거 이벤트(trigger event or statement)

트리거 수행을 발생시키는 SQL문을 트리거 이벤트라고 한다.

트리거 조건(trigger restriction)

트리거 이벤트가 발생하고 트리거를 수행시킬 조건으로 논리

연산자를 포함하는 식이다.

트리거 액션(trigger action)

트리거 조건이 TRUE일 때 트리거가 수행하는 저장 프로시

저 본체(body)이다.

트리거 이벤트 DELETE

해당 테이블의 데이터를 삭제하는 DELETE 구문을 수행 시

트리거를 동작시킨다.

INSERT

해당 테이블의 데이터를 삽입하는 INSERT 구문을 수행 시


UPDATE

해당 테이블의 데이터를 변경하는 UPDATE 구문을 수행 시

트리거를 동작시킨다. UPDATE 트리거 이벤트에 OF 구문

을 사용할 경우 OF 구문에 명시된 칼럼이 변경될 경우에만


단, 데이터베이스의 무결성을 위해 리플리케이션에 의해 적용되는

테이블의 변경은 트리거 이벤트로 처리되지 않는다.

생성


트리거는 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 del_trigger DISABLE;

삭제 DROP TRIGGER문을 사용해 트리거를 삭제할 수 있다.

예제 DROP TRIGGER del_trigger;


CREATE TRIGGER

ALTER TRIGGER

DROP TRIGGER

또한, 트리거는 저장 프로시저이므로 트리거 본체(body)에 대해

서는 Stored Procedure Users Manual을 참조한다.


사용자 관리 데이터베이스 생성 후 초기 데이터베이스 내에는 시스템 관리자

인 SYSTEM_와 SYS 사용자만이 존재한다. 이 사용자들은 DBA

이므로 일반 스키마를 구축하기 위해서는 일반 사용자를 생성하

여 스키마 객체를 관리해야 한다. 이 절에서는 권한을 제외한 사

용자 관리에 대해 설명한다.

SYSTEM_와 SYS 사용자 데이터베이스를 생성하면 시스템에 의해 생성되는 시스템 관리자

로 일반 사용자와 구별된다.

SYSTEM_ 사용자는 메타 테이블의 소유자로 메타 테이블에 대한

DDL문과 DML문 수행 권한을 가지고 있다.

SYS 사용자는 DBA로 일반 테이블에 대해 모든 권한을 가지고

있으며 시스템 수준의 모든 작업을 수행할 수 있는 권한을 기본

적으로 가지고 있다.

또한 이들 사용자는 임의로 변경되거나 삭제될 수 없다.

생성 CREATE USER문을 사용하여 사용자를 생성한다. 사용자 생성

시 비밀 번호를 지정하여야 하고, 부가적으로 테이블스페이스를

설정할 수 있다.

예제 CREATE USER DLR IDENTIFIED BY DLR123

DEFAULT TABLESPACE user_data TEMPORARY TABLESPACE temp_data ACCESS sys_tbs_memory ON;

변경 ALTER USER문을 사용하여 사용자 비밀번호와 해당 사용자와

관련된 테이블스페이스 설정을 변경할 수 있다.

예제

사용자 비밀 번호 변경

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;


CREATE USER

ALTER USER

DROP USER


권한 관리 사용자가 데이터베이스 객체 또는 데이터에 접근하기 위해서는

적절한 권한을 필요로 한다. 이 절에서는 사용자와 권한 및 객체

와 권한에 대해 이를 관리하는 방법에 대해 설명한다.

종류 알티베이스는 사용자가 권한(privilege)을 관리할 수 있는 기능은

지원하지만 권한들의 묶음인 롤(role)은 지원하지 않으며, 여기서

는 알티베이스가 지원하는 권한의 종류에 대해 설명한다.

시스템 접근 권한 (System Privilege) 시스템 접근 권한은 일반적으로 DBA가 관리를 하며, 데이터베이

스에 특정한 작업을 수행하거나 모든 스키마에 있는 객체들을 관

리할 수 있는 권한이다.

알티베이스가 지원하는 전체 시스템 접근 권한 목록은 다음과 같

다. 이와 관련된 자세한 설명은 SQL Users Manual을 참조한다.

System privilege Name 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 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) 객체 접근 권한은 객체의 소유자가 관리를 하며, 객체에 접근하고

조작할 수 있는 권한이다.

알티베이스가 지원하는 객체 접근 권한 목록은 다음과 같다.

Object privilege Table Sequence PSM View ALTER X X DELETE X EXECUTE X INDEX X INSERT X REFERENCES X SELECT X X X UPDATE X

권한 부여 GRANT문을 사용하여 특정 사용자에게 명시적으로 권한을 부여

할 수 있다.

SYSTEM_와 SYS 사용자의 경우 DBA로서 모든 권한을 갖고 있

으며 일반 사용자에게 임의의 권한을 부여할 수 있다.

일반 사용자의 경우 CREATE USER문을 수행하여 사용자를 생성

하면 최소 권한으로 다음 권한들은 시스템에 의해 자동 부여된다.

- CREATE SESSION

- CREATE TABLE

- CREATE SEQUENCE

- CREATE PROCEDURE


- CREATE VIEW

예제

시스템 접근 권한 부여

GRANT ALTER ANY SEQUENCE, INSERT ANY TABLE, SELECT ANY SEQUENCE TO uare5;

객체 접근 권한 부여

GRANT SELECT, DELETE ON sys.employee TO uare8;

권한 해제 사용자에게 기 부여된 권한은 REVOKE문을 사용해 해제할 수 있

다.

예제

시스템 접근 권한 해제

REVOKE ALTER ANY TABLE, INSERT ANY TABLE, SELECT ANY TABLE, DELETE ANY TABLE FROM uare10;

객체 접근 권한 해제

REVOKE SELECT, DELETE ON sys.employee FROM uare7, uare8;


GRANT

REVOKE

PartⅡ 173

Part II

테이블스페이스 관리 175

5. 테이블스페이스 관리

알티베이스는 사용자 데이터와 시스템 데이터를 테이블 오브젝트

에 저장하고, 테이블 오브젝트는 테이블스페이스라는 논리적인 구

조체위에 만들어진다. 이장에서는 테이블스페이스의 종류와 관리

방안에 대해서 설명한다.


테이블스페이스 개요 데이터베이스 구조는 데이터베이스를 구성하는 논리적, 물리적 구

조를 포함한다.

물리적 구조는 콘트롤(Control) 파일, 리두(Redo) 로그 파일, 그

리고 데이터 파일로 구성된다.

논리적 데이터베이스 구조는 테이블스페이스, 세그먼트, 익스텐

트, 그리고 페이지로 이루어진다.

테이블스페이스는 논리적 구조의 가장 큰 단위로서 데이터베이스

는 하나 이상의 테이블스페이스로 구성된다.

데이터베이스의 논리적 구조를 이해함으로써 데이터베이스의 공

간 관리를 작은 단위로 제어하고, 물리적 데이터 영역을 효율적으

로 관리할 수 있다.

데이터베이스의 구성 알티베이스 데이터베이스는 데이터베이스의 모든 데이터를 모아

저장하는 하나 이상의 테이블스페이스로 구성되고, 각 테이블스페

이스는 하나 이상의 데이터 파일로 구성된다. 단 하나의 데이터

파일은 하나의 테이블스페이스에만 소속한다.

다음 그림은 데이터베이스와 테이블스페이스 그리고 테이블스페

이스를 구성하는 데이터 파일의 관계를 설명한다.

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

<그림 5-１> 테이블스페이스 구조

테이블스페이스는 크게 저장공간을 기준으로 메모리 테이블스페

이스(SYS_TBS_MEMORY)와 이를 제외한 나머지 디스크 테이블

스페이스로 구분되며 최초 데이터베이스 생성시에 만들어지며 삭

제될 수 없는 SYSTM 테이블스페이스와 필요에 따라 생성과 삭


제가 자유롭고 테이블과 인덱스만을 저장할 수 있는 USER 테이

블스페이스로 종류를 구별한다.

알티베이스에서 제공하는 TABLESPACE의 종류는 다음과 같다.


<표 5-1> 테이블스페이스의 종류

ID TABLESPACE 종류

저장 공간

TABLESPACE 이름 생성 시점 설명

0 MEMORY TABLESPACE

메모

리 SYS_TBS_MEMORY

CREATE DATABASE

ALTIBASE3에서 지원하던 테이

블과 동일한 메모리 기반 객체 저장을 위한 TABLESPACE이다. 데이터베이스 내에 오직 하나

만 존재한다. 모든 데이터베이스 객체(테이

블, 인덱스, 뷰, 시퀀스, 저장프

로시저 등)를 저장할 수 있다. 메타 테이블과 인덱스를 저장

하는 TABLESPACE이다.

1

SYSTEM DATA TABLESPACE

디스

크 SYS_TBS_DATA

CREATE DATABASE

데이터베이스 생성 시 기본적

으로 생성되는 TABLESPACE이다. 데이터베이스 객체 중 테이블

과 인덱스만 저장할 수 있다.

2

SYSTEM UNDO TABLESPACE

디스

크 SYS_TBS_UNDO

CREATE DATABASE


으로 생성되며 undo 정보를 저장하기 위해 유일하게 사용되

는 특수한 TABLESPACE이다. 사용자는 undo 테이블스페이스 내에 테이블이나 인덱스 등을 생성할 수 없다. 데이터베이스 내에 오직 하나만 존재 하며, 사용자가 생성하거나 삭제할 수 없다.

3

SYSTEM TEMPORARY TABLESPACE

디스

크 SYS_TBS_TEMP

CREATE DATABASE


으로 생성되며, 데이터베이스 각종 연산의 임시 저장소로 사용되는 TABLESPACE이다. 모든 사용자의 DISK 객체를 위한 DEFAULT TEMP TABLESPACE로 지정된다. 데이터베이스 객체 중 테이블


4 이

상

USER DATA TABLESPACE

디스

크 사용자 지정 CREATE TABLESPACE

사용자의 객체를 저장하기 위

한 TABLESPACE이다. 데이터베이스 객체 중 테이블


4 이

상

USER TEMPORARY TABLESPACE

디스

크 사용자 지정

CREATE TEMPORARY TABLESPACE

사용자의 임시 TABLESPACE이며, 각 사용자 별로 한 개만 지정 가능하다. 즉, 사용자 질의

처리 과정 중에 생기는 중간

결과를 처리할 때 지정된

temporary tablespace가 사용

된다. 임시 테이블과 인덱스만 저장

할 수 있다.


System 테이블스페이스의 특성 Sytem 테이블스페이스는 Memory 테이블스페이스와 System

Data 테이블스페이스, System Undo 테이블스페이스, System

Temporary 테이블스페이스 등 4개의 테이블스페이스이다.

데이터베이스 생성 시에 만들어 진다. Sytem 테이블스페이스는 create database 구문에 의하여 데이터

베이스를 생성할 때 만들어지며 System 테이블스페이스는 모든

데이터베이스에 반드시 존재해야 한다.

메모리 테이블스페이스는 메타 정보를 가진다. 메모리 테이블스페이스(SYS_TBS_MEMORY)는 모든 메모리 기반

의 객체들이 저장되며 디스크 기반의 테이블스페이스를 포함하여

모든 데이터베이스 객체들(테이블, 인덱스, 뷰, 시퀀스, 저장프로

시저, 리플리케이션 등)의 Meta정보가 저장되는 테이블스페이스

로 사용된다.

자동확장 속성을 가진 데이터파일을 포함한다. 메모리 테이블스페이스를 제외한 System 테이블스페이스는 최초

생성시에 자동확장(Autoextend) 속성을 가진 데이터파일 1개가

포함되며 DBA에 의하여 데이터파일이 추가될 수 있다.

User 테이블스페이스의 특성 User 테이블스페이스는 User Data 테이블스페이스와 User

Temporary 테이블스페이스 2가지이다.

디스크에 저장된다. 모든 User 테이블스페이스는 디스크에 저장되며 시스템의 필요에

따라 추가, 확장 및 변경이 가능하므로 데이터베이스 관리를 유연

하게 해 준다.

데이터의 특성에 따라 저장공간을 분리 할 수 있다. 테이블과 인덱스를 각각 다른 테이블스페이스에 저장할 수 있고,

동적 또는 정적 데이터를 서로 다른 테이블스페이스에 분리하여

저장할 수 있으며 백업정책에 따라 데이터를 각각 다른 테이블스

페이스에 분리하여 저장할 수 있다.


사용자 객체의 공간할당을 제어할 수 있다. 데이터영역의 할당정책을 객체의 특성 및 필요에 따라 제어할 수

있다. 다음에 설명하는 테이블스페이스 하위의 논리적 구조를 통

해 구체적인 내용을 파악할 수 있다.

테이블스페이스의 논리적 구조 테이블스페이스는 논리적 데이터베이스 구조에서 가장 큰 상위의

단위이며 다음과 같은 하위구조를 포함한다.

테이블스페이스를 구성하는 최소의 논리적 단위이며 레코드가 저

장되는 최소의 영역은 페이지(여기서 페이지는 OS가 관리하는 페

이지 블록과는 다른 개념이며 물리적으로 32KB의 사이즈를 가

짐.)이며 알티베이스는 이러한 Page들을 효율적으로 할당하기 위

해 익스텐트(Extent)라는 단위를 사용하며 테이블스페이스 내에

서 테이블, 인덱스 등의 데이터베이스 저장 오브젝트들을 할당하

는 단위로써 세그먼트(Segment)라는 개념을 사용한다.

<그림 5-２> 테이블스페이스 구조

세그먼트(Segment) 테이블스페이스 내에서 데이터베이스 오브젝트 즉, 테이블 또는

인덱스를 할당하는 단위이며 하나의 테이블 또는 인덱스는 논리

적으로 하나의 세그먼트로 볼 수 있다.

알티베이스에서 사용하는 세그먼트의 종류는 다음과 같다.

Tablespace

Table Index

Extent

Used Page

Free Page

Segment


<표 5-2 > 테이블스페이스의 종류

종 류 설 명

Table 세그먼트 데이터베이스 안에 데이터를 저장하는 가장 기본

적인 수단이며 테이블의 모든 데이터는 한 개의 테이블스페이스에 속한다.

Index 세그먼트 한 개의 특정한 인덱스의 레코드는 한 개의 세그

먼트 안에 저장되며, 인덱스의 목적은 특정키를 기준으로 테이블의 데이터를 찾는 것이다.

Undo 세그먼트

데이터베이스의 변경을 발생시키는 트랜잭션에 의해 사용되며, 테이블 혹은 인덱스를 변경하기 전에, 변경 전 값을 Undo세그먼트에 저장하여 변경

을 취소할 수 있도록 한다.

TSS 세그먼트 알티베이스 내부적으로 관리되는 TSS(Tansaction Status Slot)를 관리하기 위한 세그먼트이며, System Undo Tablespace내에 할당된다.

익스텐트(Extent) 데이터 오브젝트를 저장하기 위해서 필요한 자원 즉, 페이지를 할

당하는 단위이며, 데이터 저장 시에 저장이 가능한 Free Page가

부족할 경우에 테이블스페이스로부터 익스텐트 단위로 페이지를

할당 받는다.

세그먼트는 내부적으로 Free Extent 리스트와 Full Extent 리스

트를 관리하며 Free Extent가 부족할 경우에 테이블스페이스에

익스텐트 추가를 요청하게 된다.

한 개의 익스텐트는 디폴트로 8개의 페이지(256KB)로 구성된다.

페이지(page) 테이블과 인덱스의 레코드가 저장되는 최소단위이며 I/O의 최소

단위이다.

페이지의 구조와 데이터 저장방식은 다음과 같다.

페이지 구조


<그림 5-３> 테이블스페이스 구조

페이지는 페이지의 기본정보와 free slot정보 등을 관리하기 위한

헤더를 가지며 헤더를 제외한 나머지의 데이터 영역에 레코드가

저장된다.

페이지 레코드 저장 방식 페이지 내에서의 레코드 저장은 레코드타입 및 트랜잭션 종류에

따라 각각 다음과 같은 방식으로 수행한다.

1. 입력(Insert): 하나의 레코드가 1 개의 페이지 내에 입력될 수

있는 경우에는 고정길이(Fixed) 칼럼과 가변길이(Variable) 칼럼

을 포함한 모든 레코드가 한 페이지에 저장된다.

<그림 5-４> 페이지 레코드 저장방식-입력1

2. 입력(Insert): 하나의 레코드 길이가 페이지 한 개의 사이즈를

넘는 경우에는 한 개의 레코드가 2개 이상의 페이지(Multi Page)

에 저장된다.

header

F F V

data

Physical header

(type, extent RID, page ID, free size, free offset)

Logical header(free slot list)

record record


<그림 5-５> 페이지 레코드 저장방식 – 입력2

3. 입력(Insert): 하나의 레코드에서 칼럼 1개의 길이가 페이지 1

개 사이즈의 반(1/2)을 넘는 경우에는 해당되는 칼럼을 한 개의

페이지(Single Page)에 저장한다.

<그림 5-６> 페이지 레코드 저장방식 - 입력3

4. 수정(Update): 하나의 페이지 내에서 레코드에 대한 Update

를 수행할 수 있는 공간이 충분한 경우에는 다음과 같이

Variable 칼럼의 경우에는 New Data를 새로운 영역에 저장한 후

에 Old Data영역은 Free Slot으로 전환되고, Fixed 칼럼의 경우

에는 Old Data영역의 값을 새로운 값으로 변경하는 방식(In-

Place Update)으로 처리된다.

header header

data

data

data F F V V V

header

F

header

data

V data F V V

data


<그림 5-７> 페이지 레코드 저장방식 – 입력4

5. 수정(Update): 하나의 페이지 내에서 레코드에 대한 Update

를 수행할 공간이 부족한 경우에는 Old Data를 해당 페이지에서

삭제한 후에 새로운 Page에 New Data를 Insert하는 방식으로

Update가 처리된다.

결론적으로 알티베이스는 디스크 기반의 테이블에 대하여 위에서

설명된 Insert방식(3번)과 Update방식(5번)을 통해 입력/수정의

속도 보다는 조회의 속도를 높이기 위한 방식으로 레코드 저장이

수행된다는 것을 알 수 있다.

Expand Chunk 데이타베이스가 생성, 확장될 때 메모리 테이블스페이스에서는 페

이지들의 묶음인 Expand Chunk 단위로 공간이 생성된다.

이때, Expand Chunk의 첫 몇개의 페이지에는 Expand Chunk내

의 모든 페이지들의 사용가능 정보가 기록되고, 데이타베이스에서

는 이 메타 페이지를 통해 페이지 관리를 하고 있다. 따라서 데이

타베이스에서 사용하고 있지 않은 빈 페이지들은 실제 OS에서

메모리를 할당받지 않기 때문에 예를 들어, 2GB 데이타베이스를

생성하더라도 OS에서 실제 2GB 메모리를 사용하지 않는다.

데이타베이스에서는 항상 각 Expand Chunk 내의 앞쪽에 있는

메타 페이지를 참조해야 하기 때문에, 이 메타페이지의 위치가 항

상 동일해야하므로 Expand Chunk의 크기 역시 항상 동일해야

한다. 따라서 데이타베이스가 한번 생성되면 Expand Chunk 크기

를 변경할 수 없다. Expand Chunk 관련해서는 Starting User’s

Manual의 EXPAND_CHUNK_PAGE_COUNT,

MIN_PAGES_ON_DB_FREE_LIST 프로퍼티를 참조한다.

header

F V

Old data

V

New data


테이블스페이스 생성 테이블스페이스의 생성 및 공간관리 방법에 대하여 설명한다.

테이블스페이스 생성 구문

① 테이블스페이스명 테이블스페이스명을 지정한다.

② 데이터 파일절

데이터 파일명은 절대경로를 지정해야 한다. 위의 구문에서 SIZE

절 이하의 구문은 생략이 가능하다. 생략할 경우 알티베이스 프로

퍼티에 정의된 Default 값으로 데이터 파일이 생성된다.

[REUSE] 가 정의되었을 경우에는 기존에 존재하는 데이터 파일

을 사용하며 데이터 파일명의 지정된 경로에 파일이 존재해야 한

다.

③ 자동확장절

AUTOEXTEND ON 일 경우 데이터 파일은 구문을 통해서 지정되거나 디폴트 크기의 NEXT 만큼 자동 확장되며 [최대크기절] 을 통해 지정된 크기까지 확장

된다.

AUTOEXTEND OFF 일 경우

CREATE TABLESPACE [①테이블스페이스명]

DATAFILE [②데이터 파일절

AUTOEXTEND [③자동확장절

MAXSIZE [④최대크기절] ] ]

EXTENTSIZE [익스텐트사이즈절]

[⑤ONLINE|OFFLINE]

DATAFILE 데이터 파일명 SIZE integer [K|M|G] [REUSE]

[자동확장절]

AUTOEXTEND [ON NEXT integer [K|M|G] [최대크기절]

|OFF]


데이터 파일은 최초 생성된 사이즈에서 확장되지 않으며 저장영

역이 부족할 경우 다음 데이터 파일로 전환되거나 사용 가능한

데이터 파일이 없는 경우에는 트랜잭션이 취소 된다.

④ 최대 크기절: 자동확장절의 부속절

자동확장 속성이 지정된 테이터파일이 확장될 수 있는 최대크기

를 지정한다. UNLIMITED 로 지정된 경우에는 스토리지 device

가 full될 때 까지 사이즈가 늘어나게 된다.

⑤ 익스텐트 사이즈절

테이블스페이스에 저장되는 세그먼트(테이블 또는 인덱스)가 할당

받는 페이지의 단위인 익스텐트의 사이즈를 정의한다.

익스텐트 사이즈를 지정하지 않을 경우 디폴트 값은

256K(8pages)이 된다.

⑥ ONLINE/OFFLINE 절 ONLINE으로 지정할 경우에 테이블스페이스는 사용가능하며,

OFFLINE일 경우에는 ALTER TABLESPACE 를 통해 ONLINE

으로 변경한 후에 사용할 수 있다.

테이블스페이스 생성 예제 이 절에서는 알티베이스에서 테이블스페이스를 생성하는 경우의

다양한 예를 설명한다.

디폴트 속성을 가진 데이터 파일 한개를 가진 테이블스페이스 생성

user_data01 테이블스페이스는 10M의 /data01/dbs/user01.dbf

데이터 파일 한 개를 가지며 데이터 파일은 자동 확장되지 않는

다.

MAXSIZE {integer [K|M|G] | UNLIMITED }

EXTENTSIZE integer [K|M|G]

iSQL> CREATE TABLESPACE user_data01

DATAFILE /user1/dbs/user01.dbf SIZE 10M;

Create success.


자동확장 속성을 가진 데이터 파일을 가지며 익스텐트 사이즈가 재 정의된 테이블스페이스 생성

user_data02 테이블스페이스는 2개의 데이터 파일을 가지며,

/user1/dbs/user02.dbf 파일의 경우에는 자동확장속성을 가지며

확장시에 1M byte 단위로 늘어나고 최대 1G byte까지 확장된다.

따라서 user_data02 테이블스페이스는 두 개의 데이터 파일을 포

함하여 전체 1.1G까지 데이터를 저장할 수 있게 된다.

또한 EXTENT의 사이즈는 512K로 정의되어 세그먼트에 Page가

할당될 때 512K(16Pages)씩 할당된다.

테이블스페이스 공간 관리 이 절에서는 알티베이스 테이블스페이스의 공간관리 방법에 대하

여 설명한다.

디스크 테이블의 사이즈 계산 알티베이스 디스크 테이블의 사이즈는 다음과 같은 방법으로 계

산할 수 있다.

record의 경우 [ 32(header) + (column의 길이의 합) ] * record count 칼럼길이가 고정(Fixed)인 경우의 크기이며 가변(Variable)칼럼에

대하여는 가변칼럼의 헤더와 실제데이터의 크기를 계산해야 하므

로 약간의 증감이 발생할 수 있다.

index의 경우 [ 16(header) + (key column 길이의 합) ] * record count 위의 계산 공식은 leaf node (B*Tree에서 최하위의 노드)의 대략

적인 크기이고, 이 외에 internal node (leaf node를 제외한 상위

노드)의 사이즈는 key칼럼의 사이즈가 작을 경우에는 무시할 정

도로 사이즈가 작지만 key칼럼 사이즈가 10K이상으로 클 경우에

iSQL> CREATE TABLESPACE user_data02

DATAFILE /user1/dbs/user01.dbf SIZE 100M,

/user1/dbs/user02.dbf SIZE 100M

AUTOEXTEND ON NEXT 1M MAXSIZE 1G

EXTENTSIZE 512K;

Create success.


는 B*Tree의 Depth가 깊어지면서 전체 leaf Node 사이즈의

50%정도가 될 수도 있으므로 해당되는 경우에는 사이즈 계산에

포함해야 함.

테이블 사이즈 계산 예 테이블 스키마가 다음과 같고 레코드의 개수가 100만 건일 경우

에 레코드의 크기와 인덱스의 크기를 포함한 테이블의 사이즈는

다음과 같이 계산된다.

CREATE TABLE TEST001 (

C1 char(8) primary key,

N1 double unique,

C2 char(128),

N2 integer,

IN_DATE date) tablespace user_data02;

1. 레코드사이즈

10(C1:헤더2byte포함)+ 130(C2:헤더2byte포함) + 8(N1) +

4(N2) + 8(IN_DATE) = 160 Bytes

[ 32(헤더) + 160(칼럼길이의 합) ] * 100만건 = 183.11M

2. 인덱스사이즈

[ 16(헤더) + 18(key칼럼길이의 합) ] * 100만건 = 32.42M

3. TEST001 테이블 전체 사이즈

183.11(레코드사이즈) + 30.52(인덱스사이즈) = 215.53M

자료형 별 사이즈계산은 SQL매뉴얼의 2장. 자료형을 참조하면

된다.

테이블스페이스 적정 크기 계산

위에서 테이블의 크기 계산에 사용된 테이블(TEST001)을 기준

으로 테이블의 레코드와 인덱스를 모두 저장할 수 있는 테이블스

페이스의 적정 사이즈를 계산한다.

적정한 테이블스페이스 크기를 계산하기 위해서 고려해야 할 사

항은 다음과 같다.

트랜잭션의 구성 비율을 고려한다.


특정 테이블에 대하여 『변경(Update) 트랜잭션이 많이 발생할

경우에는 트랜잭션의 성능을 높이기 위해 Insert High Limit을 줄

이고, Insert Low Limit을 작게하여 Update를 위해 필요한 free

space를 많이 확보』해야 하며 변경 트랜잭션이 적고 『입력

(Insert) 트랜잭션이 주로 발생하는 테이블의 경우에는 반대로

Insert High Limit을 늘리고, Insert Low Limit을 높임으로써 불필

요한 free space를 최소화』 해야 한다.

Insert High Limit

디폴트 값은 90이며 테이블생성시 지정 가능함.

Insert High Limit

테이블정보를 저장할 때 테이블스페이스의 각 페이지에서 기존

레코드에 대한 변경 연산 등을 위하여 사용될 free space를 제외

하고 사용될 수 있는 최대공간의 백분율이다.

따라서 Insert High Limit이 90 이고 입력(Insert) 트랜잭션만 발

생한다고 가정할 경우에 테이블스페이스의 전체 크기가 100M 라

면 테이블의 레코드와 인덱스를 위해 사용될 수 있는 공간은

90M가 된다.

Insert Low Limit

디폴트 값은 40이며 테이블생성시 지정 가능함.

특정 페이지가 Insert High Limit에 도달한 후에 변경과 삭제로

인해서 free space가 늘어나는 경우에 free space의 비율이 40%

미만(39%)이 될 때 까지 해당 Page에는 Insert가 되지 않는다.

따라서 『변경이 많이 발생하는 테이블일 경우에는 테이블스페이

스 크기 산정 시에 추가 스페이스를 많이 확보』해야 한다.


<표 5-3 > 트랜잭션 구성비율에 따른 테이블스페이스 크기 계산

케이스 테이블스페이스 사이즈 계산

변경 대부분이 Read

Only 트랜잭션이거나

UPDATE 시에 Record

의 크기가 증가 되지 않

을 경우

① Insert High Limit 95 으로 지정하고

② Insert Low Limit 90 으로 지정한 경우

③ 최소 테이블스페이스 크기 계산: TEST001(전체

사이즈=215.53M)테이블을 저장하기 위해서 필요한

최소사이즈는 다음과 같은 공식으로 계산한다.

테이블전체사이즈 / (Insert High Limit / 100)

= 215.53/0.95 ≒ 227M 가 된다.

④ 가중치 계산: 최소사이즈에 적절한 크기의 가중치

를 추가한다. 가중치는 시스템상황에 따라 달라질 수

있으며 다음은 가중치 계산의 한가지 예이다.

최소사이즈 * [ 1- (Insert Low Limit / 100) ] * 2

= 227 * 0.1 * 2 ≒ 45M

따라서 테이블스페이스를 총 272M 정도의 사이즈로

생성한다.

UPDATE가 빈번하고,

UPDATE 시에 Record

의 크기가 증가 될 때

① Insert High Limit 80 으로 지정하고,

② Insert Low Limit 40 으로 지정한 경우

③ 최소 테이블스페이스 크기 계산: TEST001(전체

사이즈=213.63M)테이블을 저장하기 위해서 필요한

최소사이즈는 다음과 같은 공식으로 계산한다.

테이블전체사이즈 / (Insert High Limit / 100)

= 213.63/0.8 ≒ 267M 가 된다.

④ 가중치 계산: 최소사이즈에 적절한 가중치를 추

가한다. 다음은 가중치 계산의 한가지 예이다.

최소사이즈 * [ 1- (Insert Low Limit / 100) ] * 2

= 267 * 0.6 * 2 ≒ 320M

따라서 테이블스페이스를 총 5878M 정도의 사이즈

로 생성한다.

INSERT, UPDATE 가

자주 발생하지만

UPDATE 시 ROWS 크

기가 증가 되지 않을 때

① Insert High Limit 90 으로 지정하고,

② Insert Low Limit 60 으로 지정한다.

* 위의 표에서 설명한 테이블스페이스 사이즈의 계산은 절대적인

기준이 아니며 시스템이 비정상 동작하여 데이터가 갑자기 증가

하는 등의 장애상황에 대한 추가적인 고려가 필요하다.


적정한 백업 사이즈를 고려한다. 실제 업무에서 하나의 테이블스페이스에 하나의 테이블만 저장되

는 경우는 드물며 업무단위 또는 백업단위로 테이블을 묶어서 하

나의 테이블스페이스에 생성하는 것이 효율적이다.

이때 테이블스페이스에 대한 백업 소요 시간 등을 고려하여 한

개 테이블스페이스의 적정사이즈를 설정해야 한다.

다음 그림은 데이터베이스 내에서 테이블스페이스를 업무단위 및

백업사이즈를 고려하여 적정사이즈로 분리하여 생성한 예이다.

<그림 5-８> 백업을 고려한 테이블스페이스

임시(Temporary) 테이블스페이스 임시 테이블스페이스는 질의 처리 과정 중에 각종 연산을 통해

발생하는 중간 결과를 저장하기 위한 테이블스페이스이며 데이터

베이스 생성 시에 만들어지고 1개만 존재하는 SYSTEM

TEMPORARY TABLESPACE(SYS_TBS_TEMP) 와 사용자별로

1개씩 할당 받을 수 있는 USER TEMPORARY TABLESPACE 2

가지가 있으며 이 절에서는 User Temporary 테이블스페이스에

대하여 설명한다.

임시 테이블스페이스 생성 구문

임시 테이블스페이스는 백업이나 복구의 대상이 아니다. 따라서 ONLINE/OFFLINE 구문이 없으며 굵은 글자체로 표시된

부분을 제외하고는 User Data 테이블스페이스 생성 구문과 동일

하다.

DB

VERSION

TBS_SALES

INVOICE

COMP PRODUCT

DEPT

TBS_CUSTS

ORDER EMP

PROJ

2G 1G


① 테이블스페이스명

테이블스페이스명을 지정한다.

② 데이터 파일절

③ 자동확장절: 테이터파일절의 부속절

④ 익스텐트사이즈절: 익스텐트 할당 단위를 정의

임시 테이블스페이스 생성 예

임시 테이블스페이스 관리

임시 테이블스페이스가 부족할 경우에 Query 속도가 느려질 수

있으므로 임시 테이블스페이스의 사용량 등을 확인하여 부족할

경우에 사이즈를 늘려 주어야 한다.

임시 테이블스페이스의 확장은 ALTER TABLESPACE ADD

TEMPFILE 또는 ALTER TABLESPACE ALTER TEMPFILE ~

SIZE 구문으로 수행할 수 있다.

CREATE TEMPORARY TABLESPACE [①테이블스페이스명]

TEMPFILE [②데이터 파일절

AUTOEXTEND [③자동확장절

MAXSIZE [④최대크기절] ] ]

EXTENTSIZE [익스텐트사이즈절]

DATAFILE 데이터 파일명 SIZE integer [K|M|G] [REUSE]

[자동확장절]

AUTOEXTEND

[ON NEXT integer [K|M|G] MAXSIZE [최대크기절]

|OFF ]

EXTENTSIZE integer [K|M|G]

iSQL> CREATE TEMPORARY TABLESPACE user_temp01

TEMPFILE /user1/dbs/usrtmp01.dbf SIZE 10M;

Create success.


언두(Undo) 테이블스페이스 언두 테이블스페이스는 데이터베이스 생성 시에 만들어지는

SYSTEM UNDO TABLESPACE(SYS_TBS_UNDO) 1개만 존재하며 사용자가

추가로 생성하거나 삭제할 수 없다.

언두 테이블스페이스 관리

언두 테이블스페이스는 언두 세그먼트를 저장하기 위해 사용 되

며 언두 테이블스페이스가 부족할 경우에 트랜잭션의 성능에 영

향을 줄 수 있으므로 적절한 사이즈로 관리되어야 한다. 언두 테

이블스페이스의 공간관리는 다음과 같은 방법으로 수행될 수 있

다.

언두 테이블스페이스의 확장 업무 시스템에서 변경 트랜잭션(특히, Long-Term 트랜잭션: 트

랜잭션의 Commit 주기가 긴 경우)이 많이 발생하는 경우에 언두

테이블스페이스의 부족이 발생할 수 있으며 이러한 경우에 언두

테이블스페이스의 ALTER TABLESPACE 구문을 이용하여 적정

한 사이즈로 데이터 파일을 추가하거나 파일사이즈를 늘려주면

된다.

디스크 GC(Garbage Collector) 쓰레드 관련 프로퍼티 변경 Commit이 완료된 언두 공간을 free space로 전환하는 작업을

Garbage Collecting이라고 한다.

트랜잭션이 단시간에 많이 발생할 경우에 디스크 GC 쓰레드에

의한 테이블스페이스의 free space 확보가 늦어짐으로 인해서

테이블스페이스 부족현상이 발생할 수 있으며 이러한 경우에 알

티베이스 디스크GC 쓰레드의 실행주기와 실행 시에 처리하는

페이지의 개수 등에 관한 프로퍼티를 수정함으로써 디스크 GC

의 성능을 높일 수 있다.

다음 그림은 디스크 GC 쓰레드의 처리 흐름도이다.


<그림 5-９> 디스크 GC 처리 흐름

① 디스크 GC 쓰레드는 프로퍼티에 정의된 실행주기에 따라

Data(Table/Index포함) Segment 에서 Commit이 완료된 Record

를 데이터 저장이 가능한 free slot으로 전환한다.

② Data Record에 대한 Garbage Collecting이 완료된

RID(Record ID)에 해당하는 Undo Record들을 포함한 Undo 페

이지를 free한다.

Disk GC

Thread

Header Header

Table Segment Page

(on Data Tablespace)

Undo Segment Page

(on Undo Tablespace)

Undo Records

Deleted Record

Updated Record

Undo Record


테이블스페이스 변경 이번 장에서는 테이블스페이스의 크기 및 속성 변경 그리고 백업

에 대하여 설명한다.

테이블스페이스의 크기 변경 테이블스페이스의 크기를 변경하는 방법에는 다음의 4가지가 있

다.

1. ALTER TABLESPACE ADD [ DATAFILE|TEMPFILE ] 구문

으로 데이터파일을 추가한다.

구문 설명

테이블스페이스의 ON/OFFLINE에 관계없이 가능하다.

예제

user_data02 테이블스페이스에 초기사이즈 100M 이면서 500M

까지 확장될 수 있는 데이터파일을 추가한다.

2. ALTER TABLESPACE DROP [ DATAFILE|TEMPFILE ] 구

문으로 특정 데이터파일을 제거한다.

구문 설명

테이블스페이스의 ON/OFFLINE에 관계없이 가능하지만 현재 사

용중인(초기화되어 할당되어진) 데이터파일 이후의 사용 중이 아

닌 데이터파일에 대해서만 가능하다.

ALTER TABLESPACE [테이블스페이스명]

ADD DATAFILE|TEMPFILE [데이터 파일절

AUTOEXTEND [자동확장절

MAXSIZE [최대크기절] ] ]

iSQL> ALTER TABLESPACE user_data02

ADD DATAFILE /user1/dbs/user03.dbf SIZE 100M

AUTOEXTEND ON NEXT 1M MAXSIZE 500M;

Alter success.


DROP DATAFILE|TEMPFILE 데이터 파일명


예제

user_data02 테이블스페이스에서 /user1/dbs/user03.dbf 데이터파

일을 삭제한다.

3. ALTER TABLESPACE ALTER [ DATAFILE|TEMPFILE ]

AUTOEXTEND 구문으로 데이터파일의 자동확장모드를 ON/OFF

할 수 있다.

구문 설명

테이블스페이스의 ON/OFFLINE에 관계없이 가능하다.

예제 1


일의 자동확장 모드를 ON시키고 최대 1GB까지 확장 되도록 한

다.

예제 2


일의 자동확장 모드를 OFF시킨다.


DROP DATAFILE /user1/dbs/user03.dbf;

Alter success.


ALTER DATAFILE|TEMPFILE 데이터 파일명

AUTOEXTEND [ON [자동확장절] | OFF]


ALTER DATAFILE /user1/dbs/user01.dbf

AUTOEXTEND ON MAXSIZE 1G;

Alter success.



AUTOEXTEND OFF;

Alter success.


4. ALTER TABLESPACE ALTER [ DATAFILE|TEMPFILE ]

SIZE 구문으로 데이터파일의 사이즈를 조정할 수 있다.

구문 설명

테이블스페이스의 ON/OFFLINE에 관계없이 가능하지만 현재 사

용중인 데이터파일 또는 이후 데이터파일에 대해서만 가능하며,

사이즈를 늘리거나 줄일 수 있다.

예제


일의 사이즈를 200MB 로 늘린다.


ALTER DATAFILE|TEMPFILE 데이터 파일명

SIZE integer [K|M|G]



SIZE 200M;

Alter success.


테이블스페이스의 속성 변경 이번 절에서는 테이블스페이스의 속성 변경에 대하여 설명한다.

테이블스페이스와 데이터파일의 ONLINE/OFFLINE

테이블스페이스의 이름을 변경하거나 테이블스페이스의 오프라인

백업/복구에는 테이블스페이스를 OFFLINE 시켜야 한다.

구문 설명

테이블스페이스와 데이터파일의 OFFLINE은 다단계 Startup의

CONTROL 단계에서 가능하다.

예제

다음과 같은 순서로 테이블스페이스를 OFFLINE 시킨다.

1. 알티베이스를 Shutdown 시킨다.

2. sysdba 모드로 isql에 접속한다.

3. startup process 로 PROCESS 단계로 전환한다.

4. alter database [db_name] control 구문으로 CONTROL 단계

로 전환한다.

5. ALTER TABLESPACE ~ OFFLINE 구문으로 테이블스페이스

또는 데이터파일을 OFFLINE 시킨다.

-- 테이블스페이스 ONLINE/OFFLINE

ALTER TABLESPACE [테이블스페이스명] [ OFFLINE | OFFLINE ]

-- 데이터 파일 ONLINE/OFFLINE


ALTER DATAFILE 데이터 파일명 [ OFFLINE | OFFLINE ]

$ is -sysdba


...

Command execute success.

iSQL> alter database mydb control;

...



ALTER DATAFILE /user1/dbs/user02.dbf OFFLINE;

Alter success.

iSQL> ALTER TABLESPACE user_data02 OFFLINE;

Alter success.


DATAFILE의 위치 이동(이름변경)

테이블스페이스의 스토리지를 변경하거나 특정 데이터파일의 위

치를 다른 디렉터리로 변경하고자 할 때는 데이터파일의 이름을

변경해야 한다.

구문 설명

데이터파일의 이름 변경은 테이블스페이스 OFFLINE 상태에서

가능하다.

예제

다음과 같은 순서로 데이터파일을 이동 시킨다.

1. Startup Control 단계에서 ALTER TABLESPACE …

OFFLINE 구문으로 테이블스페이스를 OFFLINE 시킨다.

2. ALTER TABLESPACE … RENAME DATAFILE 구문으로 테

이블스페이스를 ONLINE 시킨다.


RENAME [ DATAFILE | TEMPFILE ]

기존데이터 파일명 TO 변경데이터 파일명

$ is -sysdba


...


iSQL> alter database mydb control;

...


iSQL> ALTER TABLESPACE user_data02 OFFLINE;

Alter success.


RENAME DATAFILE /user1/dbs/user02.dbf

TO /data01/dbs/user02.dbf;

Alter success.

iSQL> ALTER TABLESPACE user_data02 ONLINE;

Alter success.


테이블스페이스 백업 및 복구 이번 절에서는 테이블스페이스의 온라인/오프라인 백업의 개념

및 특징을 간단하게 설명한다. 자세한 백업구문과 방법은

Administrator’s 매뉴얼과 Starting매뉴얼에 정리되어 있는 것을

참고하면 된다.

테이블스페이스 온라인 백업(HOT 백업) 온라인 백업의 특징 1. 데이터베이스가 아카이브로그 모드로 운영될 때만 가능하다.

2. 아카이브 로그 모드로 운영되면 체크포인트와 Log Flush 후

에도 로그 파일을 별도의 스토리지에 백업하므로 대용량의

스토리지를 필수로 준비해야 한다.

3. Alter database backup 구문을 통해 데이터베이스 운영 중

에 백업할 수 있다.

4. 장애로 인하여 데이터파일이 손상되거나 지워지는 경우에

도 데이터파일의 현재 시점까지 복구(media recovery)가

가능하다.

<그림 5-１０> 온라인 복구(Media Recovery)의 개념

5. Datafile xyz 가 손상되었을 경우에 이전에 Hot 백업해 두

었던 데이터파일을 이용해서 복구가 가능하다.

Media

Recovery

아카이브 로그 files Online Log files

LSN

31

LSN

32

LSN

…

LSN

99

LSN

100

LSN

101

Datafile xyz : createLSN(21:000)

checkpointSCN(200)

Log Anchor File checkpointSCN = 140

recoveryLSN(32:010)

Hot backup받은

이전 Datafile

Datafile : xyz


6. 백업해 둔 데이터파일의 헤더에 백업 시점에 최종 체크포인

트된 SCN(140)과 recovery LSN(32:010)이 있으므로 이를

기준으로 현재의 최종 체크포인트 SCN(200) 까지 데이터파

일을 복원할 수 있다.

7. Startup 시점에 온라인로그의 Redo/Undo를 통해 데이터파

일이 최종 상태의 이미지로 복구된다.

테이블스페이스 오프라인 백업: Cold 백업

오프라인 백업의 특징 1. 데이터베이스가 노 아카이브 모드로 운영될 때 가능하다.

2. 오프라인 백업이란 데이터베이스 서버를 정상 shutdown 시

키고 나서 데이터파일, 로그 파일, log anchor 파일 등을

copy 해 놓는 방식이다.

3. 장애로 인하여 데이터파일이 손상되거나 지워지는 경우에

최종 오프라인 백업된 시점까지만 복구가 가능하다.

오프라인 복구 데이터베이스를 shutdown 시킨 후에 기존 데이터베이스를 오프

라인 백업된 파일로 바꾼후에 startup 함으로써 복구가 수행된

다.


테이블스페이스 삭제 이번 장에서는 테이블스페이스의 삭제 방법을 설명한다.

테이블스페이스 삭제: 3 가지 경우 1. 테이블스페이스의 오브젝트만을 데이터베이스 메타정보에서

삭제

2. 삭제할 테이블스페이스에 테이블 또는 인덱스가 존재하거나

해당 오브젝트를 참조하는 constraints가 존재할 경우

“The tablespace has objects” 에러가 발생하며 실패하게 된다.

이럴 경우에 모든 오브젝트와 참조를 먼저 삭제하거나 다음과 같

은 방법으로 테이블스페이스를 삭제한다.

3. 테이블스페이스에 포함된 데이터파일들과 모든 constraints들

을 함께 지울 경우

iSQL> DROP TABLESPACE user_data02;

Drop success.

iSQL> DROP TABLESPACE user_data02

INCLUDING CONTENTS CASCADE CONSTRAINTS;

Drop success.

iSQL> DROP TABLESPACE user_data02

INCLUDING CONTENTS AND DATAFILES CASCADE

CONSTRAINTS;

Drop success.


테이블스페이스 정보 알티베이스는 테이블스페이스를 관리하기 위해서 테이블스페이스

의 상태를 점검하거나 모니터링 하기 위한 성능 뷰를 제공한다.

DBA는 성능 뷰에 대한 조회를 통해 테이블스페이스의 크기, 사

용량, 상태 등을 점검할 수 있다.

테이블스페이스 사용내역 정보 보기

iSQL> select b.name, b.datafile_count,

a.maxsize || K tbs_max_size,

a.currsize || K tbs_curr_size,

a.usedsize || K tbs_used_size

from (

select df.spaceid spaceid, maxsize, currsize, nvl(usedsize,n/a) usedsize

from (select sum(maxsize) * 32 * 1024 maxsize ,

sum(currsize) * 32 * 1024 currsize ,

spaceid

from v$datafiles

where state=1

group by spaceid) df left outer join

(select tablespace_id spaceid,

to_char(sum(disk_page_cnt) * 32 * 1024) usedsize

from v$disktbl_info

where disk_page_cnt > 0

group by tablespace_id) uf on df.spaceid = uf.spaceid

union all

select 0 spaceid, max_db_size maxsize,

mem_alloc_page_count * 32 * 1024 currsize,

to_char((mem_alloc_page_count - mem_free_page_count)

* 32 * 1024) usedsize

from (select mem_alloc_page_count, mem_free_page_count

from v$database),

(select value1 max_db_size from v$property

where name = MEM_MAX_DB_SIZE)

) a,

v$tablespaces b

where a.spaceid = b.id and b.name = USER_DATA02

group by b.name, b.datafile_count, a.maxsize, a.currsize, a.usedsize;

NAME FILE_COUNT TBS_MAX_SIZE TBS_CURRSIZE TBS_USEDSIZE

-------------------------------------------------------------------

USER_DATA02 2 1178566656K 209715200K 20971520K

1 row selected.


SYSTEM_.SYS_TBS_USERS_ - 각 테이블스페이스를 사용하는 데이터베이스 계정정보

iSQL> select b.user_name, a.user_id, c.name

from system_.sys_tbs_users_ a, system_.sys_users_ b,

v$tablespaces c

where a.tbs_id = c. id and a.user_id = b.user_id;

USER_NAME USER_ID TBS_NAME

---------------------------------------

USER01 22 USER_DATA02

1 rows selected.

트랜잭션 관리 207

6. 트랜잭션 관리

사용자 트랜잭션의 동시성을 제어하고 데이터의 일관성을 유지하

는 것이 데이터베이스의 가장 기본적인 기능의 하나다. 이장에서

는 알티베이스의 트랜잭션 관리 기능에 대해서 알아보자.


트랜잭션

트랜잭션의 정의 트랜잭션(Transaction)이란 하나 이상의 SQL 문장들로 이루어진

논리적인 작업 단위를 말한다. 은행에서 예금을 이체하는 작업이

트랜잭션의 대표적인 예가 될 수 있다. A 계좌에서 B 계좌로

100 만큼을 이체한다고 가정한다면 다음과 같은 작업들이 이루어

져야 한다.

1. A 계좌에서 100의 금액을 감소시킨다.

2. B 계좌에 100의 금액을 증가시킨다.

3. A에서 B계좌로 이체한 사실을 작업내용에 기록한다.

일관된(Consistent) 데이터베이스에서 정상적인 트랜잭션이 수행

되면 다시 일관된 상태로 되어야 한다. 만일, 위의 트랜잭션이 열

거한 세가지 작업 중 한 가지라도 정상적으로 수행되지 않으면,

데이터베이스의 무결성이 깨져서 A 계좌의 고객, B 계좌의 고객,

혹은 은행이 손해를 보는 경우가 발생한다.

정상적인 트랜잭션은 수행 후의 데이터베이스 무결성을 유지시키

기 위해 다음과 같은 ACID 특성을 만족시켜야 한다.

Atomicity: 트랜잭션 내의 모든 문장이 모두(all) 반영되거나,

혹은 모두 반영되지 않아야(nothing) 한다.

Consistency: 트랜잭션의 수행으로 데이터베이스의 무결성이

깨어져서는 안 된다.

Isolation: 여러 개의 트랜잭션들이 동시에 수행될 때, 한 개

의 트랜잭션이 다른 트랜잭션의 영향을 받지 않아야 한다.

Durability: 일단 수행이 완료된(Committed) 트랜잭션은 어

떤 상황 하에서도 그 내용을 영구적으로 유지할 수 있어야

한다.

스테이트먼트 스테이트먼트(statement)는 트랜잭션 내에서 수행되는 SQL문장

하나 하나를 일컫는 말이다. 스테이트먼트의 종류에는 다음과 같

은 세 종류가 있다.

DCL (Data Control Language): 데이터베이스의 상태나 프로

퍼티 혹은 물리적 구성을 변경시키는 문장들이다.


DDL (Data Definition Language): 데이터베이스의 논리적 구

성 요소인 객체들(테이블, 인덱스, 시퀀스, …)의 생성, 변경

및 삭제를 수행하는 문장들이다.

DML (Data Manipulation Language): 데이터베이스 내에 저

장되는 실제 데이터들의 삽입, 삭제, 변경 및 검색을 수행하

는 문장들이다.

일반적으로 하나의 SQL문장이 하나의 스테이트먼트로 되지만, 저

장 프로시저나 함수 등이 호출되면 하나 이상의 하위 스테이트먼

트들이 생성되어 수행된다.

스테이트먼트의 수행도 역시 데이터베이스의 무결성을 해치지 않

아야 한다. 스테이트먼트 수행 중 에러가 발생하면 해당 스테이

트먼트에서 수행한 모든 작업이 이전 상태로 되돌려 진다. 이를

위해, 각 스테이트먼트는 시작하기 전에 암묵적 저장점(Implicit

Save Point)을 설정해 두고, 에러 발생시 이 지점까지의 복원을

수행한다.

트랜잭션의 커밋 트랜잭션의 커밋(commit)이란 지금까지 트랜잭션 안에서 수행한

모든 SQL 문장들의 결과를 데이터베이스에 영구적으로 반영하면

서 해당 트랜잭션을 종료하는 연산이다.

트랜잭션의 커밋은 데이터베이스의 상태를 이전의 무결한 상태에

서 또 다른 무결한 상태로 전이 시킨다.

알티베이스에서 트랜잭션의 커밋으로 다음과 같은 작업을 수행한

다.

로그 파일에 커밋 로그를 기록한다.

트랜잭션의 수행으로 발생된 해제 가능한 자원들의 정보를

가비지 콜렉터(Garbage Collector)에게 넘겨준다.

트랜잭션의 상태를 커밋 상태로 변경시킨다.

트랜잭션 수행 중에 할당 받은 자원들을 반환한다. (잠금, 임

시 메모리 등)

트랜잭션의 롤백 트랜잭션의 수행 도중에 치명적인 오류가 있어 더 이상 진행할

수 없는 경우에는 지금까지 수행해 왔던 모든 SQL 문장들을 다

시 되돌려서, 데이터베이스를 트랜잭션 수행 이전상태로 변경시켜

야 한다. 이를 트랜잭션의 롤백이라고 한다.


트랜잭션의 롤백은 트랜잭션 수행 중에 기록한 각 로그들에 대한

보상(compensation) 연산을 수행함으로써 구현된다.

알티베이스에서 트랜잭션 롤백 시 수행하는 일들은 다음과 같다.

로그 레코드를 기록 순서와 반대로 읽어가며 보상 연산을 수

행한다.

트랜잭션의 롤백 로그를 기록한다.

삽입 등의 연산으로 할당 받았던 자원들을 다시 가비지 콜렉

터에게 반환한다.

트랜잭션의 상태를 롤백 상태로 변경한다.

트랜잭션 수행 중에 할당 받은 자원들을 반환한다. (잠금, 임

시 메모리 등)

명시적 저장점 하나의 긴 트랜잭션을 여러 개의 부분으로 나누어 관리하여야 하

는 경우, 그 부분의 시작 지점에 명시적 저장점(Explicit Save

Point)를 선언하여 사용할 수 있다. 명시적 저장점은 이름을 가

지므로, 한 트랜잭션 내에 여러 개를 선언할 수도 있다. 명시적

저장점 선언 이후 오류가 발생하여 선언한 지점으로 데이터베이

스를 다시 복원을 해야 하는 경우에는, 해당 저장점으로의 롤백을

수행하면 된다.

명시적 저장점으로의 롤백이 수행되면 이후에 잡았던 잠금(테이

블, 레코드)등의 자원들이 모두 해제되며, 해당 저장점 이후에 선

언된 다른 저장점들은 모두 해제된다.


잠금(Lock)의 개요

잠금 모드 잠금이란 데이터베이스 내에 존재하는 특정 객체에 대한 접근 권

한을 설정한 것을 의미한다. 잠금에는 그 사용 대상에 따라 테이

블 레벨 잠금과 레코드 레벨 잠금으로 나뉜다.

테이블 레벨 잠금 모드(Table Level Lock Modes) <표 6-1> 테이블스페이스의 종류

의사 모드 잠금(Intention Mode Lock) - IS, IX, SIX 잠금을 걸 수 있는 객체는 여러 가지 일 수 있으며 그 객체들은

데이터베이스 내에서 사용되는 크기가 다양할 수 있다. 예를 들어

잠금을 걸 수 있는 객체는 데이터베이스 자체, 스키마, 테이블,

레코드, 칼럼 등이 될 수 있으며 이들은 각각 크기가 데이터베이

스>스키마>테이블>레코드>칼럼 순이다. 이처럼 잠금을 걸 수 있

는 대상이 되는 객체의 크기를 잠금 단위(granularity)라 한다.

잠금 단위가 큰 객체에 대해서만 잠금을 지원하는 경우 그만큼

동시성 제어가 떨어진다. 왜냐하면 한 트랜잭션이 실제 작업 대상

잠금 모드 설명 기능

S Shared Lock

레코드 잠금의 획득 없이 테이블의 모든 레코드를 검색할 수 있으며 레코드 검색 만을 수행하는 다른 트랜잭션들과도 동시에 수행될 수 있다.

X Exclusive Lock

레코드 잠금의 획득 없이 테이블의 모든 레코드를 검색 및 변경할 수 있으며 그 테이블에 대해 오직 한 트랜잭션만이 검색 및 수정 연산을 수행할 수 있다.

IS Intensive Shared Lock 레코드 잠금을 획득한 후 레코드에 대한 검색을 할 수 있다는 점을 제외하고는 S 모드와 동일하다.

IX Intensive Exclusive Lock

레코드 잠금을 획득한 후 레코드에 대한 검색 및 수정을 할 수 있다. 서로 다른 레코드를 수정하는 트랜잭션들은 동시에 여러 개 존재할 수 있다.

SIX Intensive Exclusive Shared Lock

레코드 잠금을 획득한 후 레코드에 대한 검색 및 수정을 할 수 있다. 레코드에 대한 수정 연산은 오직 한 트랜잭션만이 수행할 수 있다.


이 되는 객체는 레코드이기 때문에 레코드 이상의 객체에 대해서

만 잠금 단위를 지원하는 경우 한 트랜잭션이 테이블 내의 레코

드 하나에 대해서만 연산을 수행하더라도 그 테이블의 다른 레코

드에 대해서 연산을 하고자 하는 다른 트랜잭션은 먼저 시작한

트랜잭션이 끝나기를 기다려야 하는 경우가 발생하기 때문이다.

따라서, 지원되는 잠금 단위는 최소 단위가 레코드인 것이 가장

효율적이다. 잠금 단위의 최소 단위에 대해 잠금을 획득하기 위해

서는 최소 단위보다 상위 단위인 객체에 대해서도 잠금을 획득해

야 하며 이를 잠금 단위 규약(granularity protocol)이라 한다.

상위 단위의 객체에 대해 잠금을 획득할 경우에는 잠금 모드를

다양하게 주어 어떤 트랜잭션이 그 테이블에 대해 연산을 수행하

고 있다 하더라도 동일한 레코드에 대해서 연산을 하지 않는 다

른 트랜잭션도 그 테이블에 대해 연산을 수행할 수 있게 하는 것

이 바람직하다. 이를 위하여 사용되는 것이 의사 모드 잠금이다.

알티베이스에서 지원되는 잠금 단위는 테이블과 레코드이다.

잠금 호환성(Lock Compatibility) 잠금 호환성이란 이미 다른 트랜잭션이 해당 객체에 대해 잠금을

획득하고 있을 때 한 트랜잭션이 그 객체에 대해 특정 모드의 잠

금을 요구하게 되는 경우 그 요구가 받아들여질 수 있는지의 여

부를 결정하기 위해 사용되는 잠금 모드 간의 호환성을 의미한다.

다음은 잠금 호환성을 나타내는 표이다.

레코드 레벨 잠금 모드(Record Level Lock Modes)

D

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 - - - - - -

Lock

Mode 설명 기능

S Shred Lock 레코드에 대해 검색만을 수행할 수 있다.

X Exclusive Lock 레코드에 대해 수정을 할 수 있다.


ML 연산 중 삽입, 삭제, 갱신 구문은 레코드에 대한 X 잠금을 잡

게 되고, 검색 연산은 S 잠금을 잡게 된다.

일반적으로 레코드에 대한 S 잠금과 X 잠금은 서로 충돌하여 호

환되지 않지만, 알티베이스의 경우는 다중 버전 동시성 제어 기법

을 사용하기 때문에 서로 충돌하지 않는다. 따라서 갱신 중인 레

코드에 대한 검색과 검색중인 레코드에 대한 갱신이 모두 허용된

다.


다중 버전 동시성 제어 기법 알티베이스는 동시성 제어를 위해 다중 버전 동시성 제어

(MVCC, Multi-Version Concurrency Control) 기법을 사용한다.

MVCC란 하나의 레코드에 대해 DML이 발생할 경우 그 레코드의

원래 버전은 그대로 유지한 채로 새로운 버전을 만들어 그 새로

운 버전에 대해 DML을 수행함으로써 비록 한 트랜잭션이 동일

레코드에 대해 연산을 수행하고 있더라도 그 레코드를 검색하는

다른 트랜잭션에게는 영향을 미치지 않도록 하는 동시성 제어 기

법이다.

동시성 제어 기법으로 MVCC 를 사용하더라고 메모리 테이블스

페이스와 디스크 테이블스페이스에서의 특징이 서로 다르기 때문

에 똑같이 구현될 수는 없다. 알티베이스는 메모리 테이블스페이

스에 대해서는 Out-place MVCC라는 기법을, 그리고 디스크 테

이블스페이스에 대해서는 In-place MVCC라는 기법을 사용한다.

이 두 가지 기법은 표면적으로 동일하게 동작을 하기 때문에, 사

용자는 이 두 가지를 특별히 구분하여 사용할 필요가 없다.

본 절에서는 MVCC 기법을 지원하기 위해 각 DML 수행 시 내부

적으로 수행되는 작업에 대해 간략하게 소개한다. 우선 MVCC

기법을 사용하지 않는 경우를 설명하고, 알티베이스의 메모리 테

이블스페이스에서 사용되는 Out-place MVCC를 설명한 후, 디스

크 테이블스페이스에서 사용되는 In-place MVCC를 설명하고,

MVCC를 사용할 때 주의해야 할 사항들에 대해 설명한다.

MVCC 기법을 사용하지 않는 경우의 갱신 연산 MVCC 기법을 사용하는 경우와의 비교를 위해 MVCC 기법을 사

용하지 않는 경우에 갱신 구문이 내부적으로 수행되는 방법에 대

해 설명한다.

다음 그림은 MVCC 기법을 사용하지 않는 경우, 즉 갱신 연산이

발생하는 경우에 한 테이블의 레코드가 어떻게 변하는지를 나타

낸다.


record A

col1 = 1

Table T1

col1=1 -> col1=2

record A

Table T1

(a) recordA의 col1의 초기 insert 상태

(b) recordA의 col1의 값을 2로 update

<그림 6-１> MVCC 미 사용시의 트랜잭션 처리

위 그림의 (a)는 테이블 T1에 레코드 A가 최초로 삽입된 경우를

나타낸다. 이 레코드 A에 대해 col1의 값을 2로 수정한 경우 위

그림의 (b)에서와 같이 레코드 A의 원래 위치에 대해 수정이 됨

으로써 T1에 할당된 공간에 대해서는 변화가 없다. 삭제 구문의

경우도 갱신 구문과 마찬가지로 원래 레코드에 대해 삭제 연산이

수행된다.

위 그림과 같이 MVCC 기법을 사용하지 않는 경우에는 갱신/삭

제에 의해 테이블에 할당된 공간이 늘어나지 않으며 한 테이블에

할당된 공간이 늘어날 수 있는 경우는 오직 삽입 구문에 의한 경

우 뿐이다.

메모리 테이블스페이스에서의 MVCC 알티베이스의 메모리 테이블스페이스에서 사용되는 Out-place

MVCC 는 갱신 연산이 발생 할 때마다 새로운 버전(version)을

생성하고 이전 버전과 연결 시킴으로써 구현된다.

갱신(Update) 연산 다음 그림은 Out-place MVCC 기법을 사용하는 경우 갱신 구문

의 수행 효과를 나타낸다.


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

<그림 6-２> MVCC 사용시의 트랜잭션 처리

위 그림의 (a)에서와 같이 테이블 T1에 레코드 A가 삽입된 상태

에서 레코드 A의 col1의 값을 2로 갱신하는 경우 (b)에서와 같이

갱신을 위해 동일한 레코드를 하나 생성한 후 그 레코드에 대해

값을 2로 변경한다. 따라서, 테이블 T1의 공간은 갱신 전의 상태

와 비교하여 하나의 슬롯(slot)을 더 차지하게 된다.

레코드 A에 대해 하나의 버전이 추가로 생성되면 원래의 레코드

A는 추가된 레코드가 무엇인지를 나타내기 위해 레코드 헤더에

하나의 포인터를 이용하여 새로 추가된 레코드를 가리키게 된다.

이렇게 함으로써 동일한 레코드에 대한 버전들을 관리할 수 있다.

위 그림의 (b) 상태에서 다시 레코드 A에 대한 갱신 연산이 수행

되면 위에서 설명한 바와 같이 추가로 하나의 레코드를 생성하여

그 레코드에 대해 갱신을 수행하게 된다. 그 결과 하나의 동일한

레코드에 대해 여러 번의 갱신 연산이 수행되면 갱신된 횟수만큼

동일한 레코드에 버전이 생기게 된다.

갱신 연산 수행 횟수만큼 테이블 공간은 무한정 커지는가? 동일한 레코드에 대하여 생긴 여러 개의 버전들은 갱신 연산을

수행한 각 트랜잭션이 커밋하게 되면 최근에 생긴 버전만 유효하

며 이전 버전들은 데이터베이스에 저장되어 있을 필요가 없다. 이

러한 불필요한 버전들은 가비지 콜렉터에 의해 알티베이스 운용

중에 삭제가 되며 삭제된 레코드들이 차지하고 있던 테이블 내의

공간들은 이후 발생하는 삽입/갱신 문에 의해 다시 재사용된다.

따라서, 갱신 연산이 일어난 횟수만큼 새로운 버전들이 생긴다 하

더라도 데이터베이스 공간이 무한정 커지지는 않는다.


삭제 (Delete) 연산 삭제 연산도 갱신 연산과 마찬가지로 각 레코드에 대해 삭제 연

산이 수행되면 하나의 새로운 버전이 생긴다. 삭제 연산의 경우

갱신 연산과 달리 삭제할 레코드에 대한 새로운 버전은 실제 아

무런 데이터도 갖고 있지 않다. 따라서, 삭제 연산에 대한 버전은

각 레코드 별로 하나씩 생성할 수도 있고, 그렇게 하지 않는다 하

더라도 데이터베이스 내의 데이터에는 아무런 영향을 미치지 않

는다.

다음 그림은 삭제 연산 수행 시 각 레코드 별로 버전을 생성하는

경우와 그렇지 않은 경우에 대해 테이블 내의 공간 활용도를 보

여준다.

(a) 각 record 별로 delete에 대한 version record를 생성하는 경우

(b) 한 테이블 내에서 커서 별로 delete에 대한 하나의 version record를 생성하는 경우

Table T1

nextoid DeleteRow

nextoid Record A

nextoid Record B

Table T1

nextoid Record A

nextoid DeleteRow

Record Bnextoid

nextoid DeleteRow-1

<그림 6-３> MVCC 사용시의 삭제 트랜잭션


위 그림의 (a)는 각 레코드 별로 하나의 버전을 생성하는 경우이

다. 한 트랜잭션이 하나의 삭제 구문을 이용하여 레코드 A, B를

삭제하는 경우 두 레코드에 대해 각각의 버전을 생성하므로 테이

블 T1은 추가로 두 개의 레코드가 생성되었다.

위 그림의 (b)는 하나의 삭제 구문에 의해 여러 개의 레코드가

삭제되더라도 하나의 삭제 구문에 대해서는 하나의 버전만을 생

성하는 경우이다.

위 그림에서 보여지는 것처럼 (b)의 경우가 불필요한 레코드 버

전을 적게 만들기 때문에 공간 활용도가 훨씬 높다. 알티베이스는

위 그림의 (b)와 같은 방법대로 메모리 테이블스페이스에 대해

삭제 연산을 수행한다.

디스크 테이블스페이스에서의 MVCC 알티베이스의 디스크 테이블스페이스에서 사용되는 In-place

MVCC 는 갱신 연산이 발생 할 때, 기존의 레코드에서 변경되는

칼럼들을 언두 테이블스페이스에 존재하는 언두 페이지에 언두

로그 레코드라는 이름으로 기록하고, 변경 이후 값들을 기존 레코

드의 해당 위치에 복사한다.

삽입 연산 최초로 레코드가 삽입되면 데이터 테이블스페이스에 레코드를 위

한 영역을 할당 받아 레코드를 만들고, 다시 언두 테이블스페이스

에서 삽입에 대한 언두 로그 레코드를 위한 영역을 할당 받아서

로그 레코드를 작성한 후, 데이터 테이블스페이스의 실제 레코드

에 있는 롤백 RID에 이 언두 로그 레코드의 위치를 기록하여 연

결을 시킨다.

갱신 연산 최초로 삽입된 레코드인 버전1이 있다고 가정하자. 이 버전이 갱

신되어 버전2가 되고, 다시 한번 갱신되어 현재 버전3이 되었을

경우의 상황은 다음 그림과 같이 된다.


버전 3 롤백 RID

데이터 테이블 스페이스언두 테이블 스페이스

이전 이미지2 롤백 RID

이전 이미지1 롤백 RID

버전 2

버전 1

버전 3 이전 이미지2=

=

+버전 2 + 이전 이미지1

<그림 6-４> 디스크 테이블스페이스의 MVCC

위의 그림과 같이 데이터 테이블스페이스에는 항상 최신의 레코

드 이미지가 존재한다. 만일 어떤 스테이트먼트가 버전3이 커밋

되기 전에 시작되었다면 버전3을 읽을 수 없으므로, 더 이전의

이미지인 버전2를 읽어 가야 한다. 이럴 경우에는, 해당 스테이트

먼트는 버전3의 이미지를 자신의 특정 버퍼에 복사한 후, 그 레

코드의 롤백 RID가 가리키는 곳에 존재하는 이전 이미지2를 읽어

다 버전3를 복사해 둔 곳에 반영하게 된다. 만일 이 버전2마저도

자신이 읽을 수 없는 버전이라면, 다시 같은 작업으로 이전 이미

지1을 반영시켜 버전1을 만들어 내게 된다.

만일 버전 1도 읽지 못한다면 이는 해당 스테이트먼트가 레코드

의 최초 삽입연산이 커밋되기 전에 시작된 것이므로 이 레코드를

없는 것으로 가정하고 무시하게 된다.

언두 로그 레코드 영역의 해제 디스크 테이블스페이스의 경우, 단시간에 다량의 갱신연산이 발생

하면 데이터 테이블스페이스의 크기는 별 차이가 없지만, In-

place MVCC의 영향으로 언두 로그 레코드의 양이 많아져서 언

두 테이블스페이스의 크기가 증가하게 된다. 언두 테이블스페이스

의 크기는 최초 CREATE DATABASE 시에 프로퍼티로 정의되어

변경되지 않으므로 언두 로그 레코드는 재사용이 가능하여야 한

다. 언두 로그 레코드는 트랜잭션이 커밋될 당시에 언두 테이블스

페이스 헤더에 등록되어 연결 리스트(linked list)로 관리되어 있

다가, 현재 시스템 내의 모든 트랜잭션이 해당 언두 로그 레코드

를 참조할 필요가 없어지게 되면 바로 해제가 된다. 반면 트랜잭

션이 롤백이 되면 언두 로그 레코드들은 언두 테이블스페이스에

등록되지 않고 바로 해제가 된다.

언두 로그 레코드들 중 삽입 연산에 의한 언두 로그 레코드들은

갱신 및 삭제 로그 레코드들과 따로 관리 되는데, 이유는 삽입 연


산에 의한 언두 로그 레코드들을 트랜잭션 커밋 시점에 바로 해

제할 수 있게 하기 위해서 이다.

삭제 연산 삭제 연산도 갱신 연산과 동일한 방식으로 수행된다. 단, 삭제 연

산에 의해 변경되는 정보는 레코드의 헤더에 삭제 플래그(delete

flag)가 설정되는 것이므로, 언두 로그 레코드의 이전 이미지에는

레코드의 헤더 정보만 기록된다.

삭제된 레코드는 바로 재사용되지 않고, 가비지 콜렉터가 해당 레

코드에 대한 삭제 언두 로그 레코드를 삭제하기 전에, 해당 레코

드에 대한 모든 인덱스의 키들을 삭제하고 실제 레코드를 삭제함

으로써 다시 재사용이 가능하게 된다.

MVCC 사용 시 주의사항 알티베이스는 메모리와 디스크 테이블스페이스 모두를 MVCC 방

식으로 동시성 제어 한다. MVCC 는 기존의 전통적인

SVCC(Single Version Concurrency Control)과 달라서, 아래와

같이 주의하여야 할 점들이 몇 가지 있다.

장시간 수행되는 트랜잭션에 의한 데이터베이스 크기 증가 특정 트랜잭션이 너무 오랫동안 커밋하지 않고 수행되고 있으면,

이 트랜잭션이 이전 이미지들을 읽을 가능성이 있기 때문에 가비

지 콜렉터가 다른 트랜잭션들이 작성한 이전 이미지 정보들(메모

리 테이블은 이전 버전, 디스크 테이블은 언두 로그 레코드 정보)

과 해당 레코드의 인덱스 키들을 삭제할 수 없게 된다. 이에 따라

메모리 테이블의 크기가 증가되고, 디스크의 언두 테이블스페이스

크기가 증가하게 된다. 또한, 해당 트랜잭션이 롤백할 때를 대비

해서 로그 파일도 삭제하지 못하므로, 로그 파일이 존재하는 파일

시스템이 꽉 찰 가능성이 있다.

동시 수행 트랜잭션 과다로 인한 데이터베이스 크기 증가 알티베이스는 MVCC로 인해 생성된 이전 이미지 정보들의 해제

를 가비지 콜렉터에게 맡기고 있다. 만일 동시에 수행되는 트랜잭

션의 수가 해당 시스템의 CPU개수 보다 현저히 많을 경우에는

가비지 콜렉터가 이전 이미지 정보들을 삭제할 여유를 가지지 못

해 데이터베이스 크기가 계속 늘어날 수 있다.

대량의 갱신 연산으로 인한 데이터베이스의 크기 증가


한번에 대량의 이전 정보를 생성해야 하는 연산(bulk update)들이

자주 사용되면, 메모리 테이블은 그 크기가 커지며, 디스크 테이

블은 언두 테이블스페이스가 커질 수 있다.

이전 이미지 정보 과다로 인한 성능 저하 위에 열거한 내용들로 인하여 이전 이미지 정보가 데이터베이스

내에 너무 많이 남아있으면 실제로 목적하는 레코드를 찾는데 더

많은 비용이 들어 갈 수 있어서 전체적으로 성능이 느려질 소지

가 있다.

Repeatable Read Vs. Consistent Read 일반적인 SVCC DBMS들은 레코드를 읽었을 때 S 잠금이 잡히게

되므로 X 잠금과 충돌하여 읽는 동안 레코드가 변하지 않으므로,

데이터베이스의 격리도(Isolation Level)이 보통 Repeatable Read

로 동작한다. 반면 알티베이스는 검색 연산이 수행 중에도 동일

레코드에 대해 갱신 연산이 가능하여 Consistent Read가 기본적

인 격리도 이다. 따라서, 한 트랜잭션이 커밋하지 않고 같은 테이

블을 여러 번 검색하면 서로 다른 결과 집합을 보여 줄 수도 있

다. 만일 이를 방지하려 한다면 격리도를 Repeatable Read로 변

경시키고 연산을 수행하거나, SELECT FOR UPDATE 구문을 사

용하여 수행하여야 한다.


트랜잭션 지속성(Transaction Durability) 개념 일반적으로, 트랜잭션이란 저장 객체(페이지 또는 레코드, DBMS

마다 구현이 차이가 있음)에 대한 일련의 판독과 갱신 작업의 독

립된 작업 단위를 의미한다.

데이터베이스 관리 시스템은 성능향상을 위해서 여러 트랜잭션이

동시에 인터리빙(interleaving)해서 수행되도록 지원하고 있으며,

여러 트랜잭션이 어떤 순서로 수행되던지 간에 그 결과는 차례대

로 하나씩 수행한 결과와 동등하도록 동시성 제어(concurrency

control)를 해주고, 예측하지 못한 모든 시스템 장애 상황에서도

모든 데이터를 정확하게 관리(crash recovery)하기 위해 다음과

같은 트랜잭션의 4가지 속성을 보장하도록 설계되어 있다.

1. 원자성 (atomic)

2. 일관성 (consistency)

3. 격리성 (isolation)

4. 지속성 (durability)

이 중 트랜잭션의 지속성 즉, durability는 DBMS가 사용자에게

트랜잭션 커밋(commit) 응답을 했을 경우, 설사 데이터베이스 객

체에 대한 해당 변경 사항이 디스크에 반영(flush) 되기 전에 시

스템 장애가 발생하였더라도 해당 트랜잭션의 커밋은 보장 되어

야 한다는 속성이다.

데이터베이스 관리 시스템은 트랜잭션의 durability를 제공하기

위해 로그(log)라고 하는, 즉, 데이터베이스객체의 갱신 작업에 대

한 기록을 관리한다. 커밋된 트랜잭션에 의해 갱신된 내용이 디스

크에 미처 반영되기 전에 시스템 장애가 발생하면, 시스템 재 구

동 시에 로그를 판독하여 변경된 내용을 복구하게 되는 것이다.

트랜잭션의 durability는 트랜잭션의 처리 성능과 밀접한 관련이

있는 중요한 요소 중에 하나라고 해도 과언이 아니다. 디스크기반

DBMS에서 비해 성능이 수십배 더 좋은 메모리기반 DBMS에서

성능에 미치는 영향력이 더 두드러진다고 볼 수 있다.

예를 들어, DBMS가 완벽한 트랜잭션 durability를 위해서는 모든

데이터베이스 갱신에 대한 로그기록을 빠짐없이 디스크의 로그파

일에 반영해야 한다. 메모리 로그버퍼에 존재하는 모든 로그들을

로그파일에 반영할 때는 디스크 I/O가 발생하게 되며, 이 때 발생

하는 디스크 I/O는 트랜잭션 처리의 병목(bottleneck)으로 작용하

게 되어 트랜잭션 처리 성능 저하의 원인으로 작용한다. 즉, 완벽

한 트랜잭션 durability과 트랜잭션 처리 성능 관계는 안정성과

성능이라는 각기 다른 목표를 가지는 상충(tradeoff) 관계에 있다

고 볼수 있다.

알티베이스는 위에서 설명한 트랜잭션의 durability를 완벽하게

보장하는 것은 물론이고, 여러 시스템 상황에 따라서 고성능의 트


랜잭션 처리를 제공하기 위해 트랜잭션 처리 성능과 트랜잭션

durability의 균형을 조절할 수 있도록 특별한 트랜잭션

durability 정책을 가지고 있다.


트랜잭션 지속성 관리 정책(Transaction Durability Policy) 본 절에서는 알티베이스의 트랜잭션 durability 레벨 대하여 설명

한다.

Durability Level 범위 알티베이스의 트랜잭션 durability 레벨은 0~5 레벨로 구분하고

있으며, 알티베이스 4에서는 0과 1레벨을 제외한 2에서 5레벨까

지만 지원하고 있다.

Durability Level 설정방법 altibase.properties 파일의 [TRANSACTION_DURABILITY_

LEVEL] 프로퍼티를 설정하면, 서버 구동 시 해당 프로퍼티에 설

정된 레벨로 알티베이스 서버가 구동이 된다. 단, 서버 운영 중에

실시간으로 레벨을 변경할 수 없다.

Durability Level 설명 Durability Level 2

<그림 6-５> 알티베이스 Durability Level 2

영역의 memory 로그버퍼에 기록하고 sync thread가 로그버퍼에

있는 로그를 로그파일에 직접 flush하는 방식이다.

이 방식은 정전으로 인한 시스템 crash 상황과 알티베이스 서버

프로세스의 비정상 종료가 발생할 경우에는 트랜잭션이 커밋한

갱신 내용에 대하여 트랜잭션 durability를 보장하지 못할 수 있


다. 왜냐하면, 트랜잭션의 커밋로그가 디스크에 반영하는 것을 보

장하지 않고 단지, 프로세스 영역의 memory 로그버퍼에만 로그

를 기록하기 때문이다.

Durability Level 3 ( 알티베이스 기본 durability level )

<그림 6-６> 알티베이스 Durability Level 3

durability level 2와는 달리 OS Kernel 영역의 로그버퍼를 사용

하기 때문에 알티베이스 프로세스가 비정상 종료를 하더라도 트

랜잭션이 커밋한 로그는 운영체제의 의해 로그파일에 반영되는

방식이다.

이 방식은 정전으로 인한 시스템 crash 상황이 아닌 경우에는 트

랜잭션 durability를 완벽하게 지원한다.

durability level 2 보다 안전하지만, 운영체제를 한번 더 걸쳐야

하는 상황이므로 level 2보다는 트랜잭션 처리 성능이 떨어질 수

있다.

Durability Level 4

In OS Kernel memory

In Altibase process

logfilesync

threads

logfiles

log buffer

log buffer

sync

txtx

<그림 6-７> 알티베이스 Durability Level 4


로그를 프로세스 영역의 memory 로그버퍼에 기록하고 sync

thread가 로그버퍼에 있는 로그를 OS Kernel에 있는 로그버퍼에

직접 반영한다. 트랜잭션이 커밋을 수행하여도 durability를 보장

하지 않는다. 왜냐하면 트랜잭션은 커밋시 커밋된 로그가 로그파

일까지 반영됨을 보장하지 않는다.

이 방식은 durability level 2와 3의 중간정도의 안정성을 지원하

면서 durability level 2의 성능을 낼 수 있다.

Durability Level 5

<그림 6-８> 알티베이스 Durability Level 5

로그를 프로세스 영역의 로그버퍼에 기록하고 sync thread가 로

그버퍼에 있는 로그를 로그파일에 직접 내려주거나 각 트랜잭션

이 직접 커밋 로그를 로그파일까지 반영하는 방식이다.

이 방식은 트랜잭션이 commit 수행 시 커밋 로그를 포함한 모든

로그가 로그파일에 반영됨을 보장하기 때문에 어떠한 시스템 장

애 상황에서도 완벽하게 트랜잭션 durability를 보장한다. 하지만,

모든 커밋된 로그가 바로 로그파일에 반영되기까지 기다려야 하

기 때문에, 트랜잭션 처리 성능은 durability level 2,3,4와 비교할

때 가장 좋지 않다.

버퍼 관리자 227

7. 버퍼 관리자

알티베이스는 대용량의 데이터가 디스크에 저장될 수 있도록 지

원하는데, 메모리의 공간은 한정되어 있으므로 이를 전부 메모리

에 적재할 수 없으므로 테이블, 인덱스, 레코드 등 모든 데이터에

접근하기 위해서는 먼저 디스크의 데이터를 메모리에 적재해야

한다. 따라서 필요한 데이터 중 주어진 메모리 공간에 적재 가능

한 양만큼 적재하고 그 외 필요한 양의 데이터에 대해서는 기존

의 메모리 공간의 데이터 중 일부를 디스크에 내려 메모리 공간

을 확보한 후, 확보된 공간에 데이터를 적재해야 한다.

버퍼 관리자는 이러한 메모리 공간을 할당하고, 메모리 공간이 부

족한 경우 필요한 데이터를 제공할 수 있도록 메모리 공간을 유

지 및 관리한다.

이 장에서는 버퍼 관리자의 구조와 기능에 대해 설명한다.


버퍼 관리자 구조

구성요소 버퍼 관리자의 구성 요소로는 버퍼 풀, 버퍼 프레임, BCB(Buffer

Control Block) , 해쉬 테이블, Free list, Used list, Flush list가

있다.이 절에서는 이들 구성요소에 대해 설명한다.

버퍼 풀(Buffer Pool) 알티베이스 서버에서 확보해 놓은 전체 메모리 공간으로 버퍼 풀

은 버퍼 프레임으로 구성된다. 일반적으로 알티베이스 서버가 할

당한 전체 버퍼를 버퍼 풀이라 지칭한다.

버퍼 프레임(Buffer Frame) 메모리에 하나의 페이지를 적재할 수 있도록 확보해 놓은 공간을

말한다. 하나의 버퍼 프레임은 하나의 페이지 크기와 같다. 버퍼

프레임이 모여서 버퍼 풀을 구성한다.

BCB(Buffer Control Block) 하나의 버퍼 프레임에 대한 정보를 기술한다. 즉, 버퍼에 올라온

페이지에 대한 정보를 가진다. 하나의 BCB는 하나의 버퍼 프레

임에 대응된다. 버퍼 관리자에서 모든 버퍼에 적재된 페이지는

BCB를 통해 관리되며, 버퍼 프레임은 단지 페이지를 메모리에

적재할 수 있는 공간이다. BCB는 대응하는 버퍼 프레임에 대한

주소를 유지한다.

<그림 7-１> BCB 구조


BCB는 다음과 같은 정보를 유지한다.

<표 7-1> 테이블스페이스의 종류

속성 설명

상태 BCB의 현재 상태. FREE, READY, USE 상태

가 있다.

버퍼 프레임의 주소 하나의 BCB에 해당하는 버퍼 프레임의 주소

스페이스 식별자 페이지가 속한 스페이스의 식별자

페이지 식별자

페이지 식별자는 (스페이스 식별자, 페이지

식별자) 쌍으로 이루어진다. 알티베이스 서버

의 모든 페이지는 페이지 식별자로 구분되며,

따라서 모든 레코드도 (스페이스 식별자, 페

이지 식별자, 페이지 내에서 저장 오프셋) 쌍

으로 구분될 수 있다.

페이지를 소유하는 자

의 록(Lock)

페이지에 접근하기 위해서는 우선 록을 획득

해야 한다. Read, Write, Fix 모드로 얻을 수

있다. BCB의 록을 특정 모드로 획득한 다는

의미는 해당 모드로 버퍼에 올라온 페이지에

접근할 수 있음을 의미한다.

수정 LSN

버퍼에서 수정된 시점의 LSN(Log Sequence

Number)으로 이 값은 버퍼에 올라온 페이지

가 플러시될 때 어느 시점의 로그까지를 플

러시해야 하는지 나타낸다.

Fix 개수

페이지를 동시에 공유하고 있는 트랜잭션 개

수이다. Write 모드로 사용 중이면 이 개수는

항상 1이 된다. Read, Fix모드는 여러 개의

트랜잭션에 의해 페이지를 공유할 수 있으므

로 1이상의 값을 가질 수 있다.

IO 상태 Read 혹은 Write 중인지 나타낸다.

해쉬 테이블 페이지에 대한 요청이 들어오면 알티베이스 서버는 해당 페이지

가 버퍼에 적재되어 있는지 검색하는데, 이때 해쉬 테이블을 사용

한다. 해쉬 테이블에는 버퍼에 적재된 각 페이지에 대한 BCB가

등록된다.


Free List 버퍼 관리자는 버퍼에 없는 페이지에 대한 접근 요청이 있을 때

비어있는 버퍼 프레임을 확보하여야 한다. 이를 위해 현재 free인

BCB 리스트를 유지하는데, 이 리스트가 Free List이다.

Used List 현재 사용중인 BCB의 리스트이다. 버퍼 풀을 전부 사용중이라면

Used List의 개수는 전체 BCB의 개수와 같게 된다. 이런 경우

새로운 페이지에 대한 요청이 있다면 리스트 중 기존에 가장 요

청이 없었던 BCB를 희생자(victim)으로 선정하고, 이를 새로운

페이지로 교체한다. 이때 교체 방식은 LRU 알고리즘을 사용한다.

Flush List 페이지가 메모리 상에서 변경된 경우, 변경된 페이지에 대한

BCB의 리스트이다. Flush List에 달린 페이지는 체크포인트 혹은

버퍼 교체에 의해 디스크에 반영된다.

<그림 7-２> BCB 관리

BCB 의 상태 변화 BCB는 어느 순간 FREE, READY, USE의 3가지 상태 중 하나의

상태로 존재한다.


FREE 아직 사용되지 않은 상태이다. free list에 존재한다.

READY BCB를 사용하기 위한 중간 단계이다. 이 상태의 BCB는 free

list, used list, flush list 해쉬 테이블에 존재하지 않는다.

USE 사용중인 상태이다. 즉, BCB가 가르키는 버퍼 프레임에 디스크의

페이지가 적재된 상태이다. used list, 해쉬 테이블에 존재한다.

플러시 쓰레드(Flush Thread) 알티베이스 서버는 다음과 같은 2가지 경우에 flush를 수행한다.

- 버퍼 풀이 전부 사용중일 때 free인 공간을 확보하기 위하여

일반 트랜잭션에 의해 수행된다.

- 서버가 여유가 있는 시점에 백 그라운드로 플러시 쓰레드에 의

해 수행된다.

플러시 쓰레드는 BUFFER_FLUSH_INTERVAL_IN_SEC에 정한

시간 만큼 깨어 주기적으로 플러시를 수행한다. 이때 전체 버퍼

풀의 10%정도의 페이지를 플러시한다. 만약 플러시 대상이 전체

버퍼 풀의 10% 이하라면 플러시 쓰레드는 어떤 작업도 수행하지

않는다.

만약 트랜잭션이 너무 많은데 비하여 버퍼 풀의 크기가 작아 빈

번한 플러시가 발생하게 되면, 알티베이스는 플러시 쓰레드가 깨

어나는 주기를 좀 더 빠른 시간으로 자동 조절한다. 트랜잭션이

별로 없어 여유가 있을 때는 주기를 다시 느린 시간으로 조절한

다.


버퍼 관리

접근 모드(Lock 모드) 페이지에 대해 접근하기 위해서는 우선 Lock을 획득해야 한다.

접근 모드는 페이지에 대한 접근 즉, Lock의 획득을 어떤 권한으

로 허가해 줄 것인가를 구분한다.

접근 모드는 다음과 같이 read, write, fix로 구분된다.

접근 모드 설명

Read(읽기) 버퍼에 올라온 페이지를 단지 읽기 위해 접근

한다.

여러 개의 트랜잭션이 동시에 접근할 수 있다.

Write(쓰기) 버퍼에 올라온 페이지를 쓰기 위해 접근한다.

한 시점에 하나의 트랜잭션만이 쓰기 모드로

페이지를 접근할 수 있다.

Fix 단지 페이지를 버퍼에 올린 후, 버퍼 관리자에

의해 교체되지 않게 한다.

fix 모드로 트랜잭션이 페이지를 접근하여 데

이터를 읽게 되면 그 데이터는 정확한 데이터

임을 보장할 수 없다.

정확한 데이터를 읽기 위해서는 읽기 모드로

획득해야 한다.

접근 모드간 허가 관계는 다음과 같다

Read Write Fix

Read O X O

Write X X O

Fix O O O

이 표에서 표 왼쪽의 모드는 하나의 트랜잭션이 요구한 접근 모

드이고, 표 상단의 모드는 다른 트랜잭션이 이미 획득한 접근 모

드이다. O은 허가 가능한 것이고, X는 허가가 불가능한 것이다.


예를 들어 write를 요구했는데 이미 read나 write가 획득되어 있

다면 페이지에 대한 해당 접근 모드의 요청은 대기하거나 실패할

것이다. read를 요구한 경우라면 접근 모드가 read로 획득되어

있는 경우 성공할 것이나, write로 획득되어 있는 경우 실패할 것

이다.

대기 모드 대기 모드는 이미 다른 트랜잭션이 페이지를 사용하고 있을 때

대기할 것인가 혹은 대기하지 않고 바로 리턴할 것인가를 결정한

다.

접근 모드 설명

대기(Wait) 다른 트랜잭션이 이미 Lock을 획득한 상

태이고 요구한 접근 모드를 허가해 줄 수

없는 경우, 다른 트랜잭션이 작업을 마치

고 Lock을 해제할 때까지 대기한다.

대기 안 함(No-

Wait)

다른 트랜잭션이 이미 Lock을 획득한 상

태이고 요구한 접근 모드를 허가해 줄 수

없는 경우, 대기 없이 리턴한다.

페이지 요청 처리 절차 1. 해쉬 테이블 검색

페이지에 대해 접근하기 위해서는 BCB의 Lock을 먼저 얻어야

한다. 일단 BCB의 Lock을 획득하게 되면 해제하기 전까지 요구

한 접근 모드로 페이지에 접근할 수 있다.

버퍼 관리자는 페이지 식별자, 접근 모드, 대기 모드로 페이지 요

청을 받는다. 요청을 받으면 가장 먼저 해쉬 테이블에 해당 BCB

가 있는지 검사한다. 페이지가 이미 버퍼에 있다면 해당 페이지를

기술하는 BCB는 해쉬 테이블에서 검색할 수 있다. 만약 해쉬

테이블에서 찾을 수 없다면, 페이지는 버퍼에 올라오지 않은 것이

므로 디스크로부터 페이지를 읽어 버퍼에 적재(Read Page 과정)

해야 한다.


<그림 7-３> 해쉬 테이블 검색

2. Lock의 획득 알티베이스에서는 항상 정확한 데이터만 읽을 수 있음을 보장하

기 위해 디스크로부터 read가 진행중인 페이지는 read가 끝날 때

까지 접근하지 않는다.

이를 위해 디스크로부터 read를 수행하기 위해서는 write 권한을

획득한다. 따라서 임의의 트랜잭션이 한 페이지에 대해 read 혹

은 write 권한을 획득할 수 있는 시점에는 디스크로부터 write가

진행 중이 아님을 알 수 있다.

Lock의 허가는 다음과 같이 접근 모드, 대기 모드, 읽기 수행 여

부에 따라 달라진다.

<표 7-2> Lock 모드

접근 모드 읽기 수

행 여부

대기 모드 Lock 획득 결과

Fix O 상관없다. 읽기가 끝날 때까지 대기 후 허가

Fix X 상관없다. 허가

Read O 대기 접근 모드가 허가되면 허가, 실패


시 대기

Read O 대기 안 함 접근 모드가 허가되면 허가, 실패

시 대기

Read X 대기 접근 모드가 허가되면 허가, 실패

시 대기

Read X 대기 안 함 접근 모드로 허가 실패 시 바로 리

턴

Write O 대기 접근 모드가 허가되면 허가, 실패

시 대기

Write O 대기 안 함 접근 모드가 허가되면 허가, 실패

시 대기

Write X 대기 접근 모드가 허가되면 허가, 실패

시 대기

Write X 대기 안 함 접근 모드로 허가 실패 시 바로 리

턴

위의 표에서 fix를 요청한 경우에는 현재 페이지가 어떤 권한으로

Lock이 잡혀 있더라도 바로 허가해 줄 수 있으나 디스크로부터

read를 수행중인 경우라면 read가 끝날 때까지 대기하여야 한다.

read 혹은 write 권한과 대기를 하지 않는 경우로 요청되는 경

우, 만약 디스크로부터 read가 진행 중이라면 read가 끝날 때까

지 대기하여야 한다.

디스크로부터 페이지 읽기 페이지가 버퍼 관리자에 요청되었을 때, 버퍼에 존재하지 않는다

면 디스크로부터 페이지를 읽는 과정을 다음과 같이 수행하게 된

다.

1. 사용 가능한 BCB 획득 알티베이스 서버가 버퍼에 존재하지 않는 페이지를 버퍼로 적재

하기 위해서는 우선 BCB를 확보하여야 한다. 사용 가능한 BCB

는 free list로부터 얻을 수 있다.

사용 가능한 BCB가 있다면 이 BCB를 free list에서 떼어내고

BCB의 상태는 READY인 상태가 된다. 이 상태는 BCB가 사용을

위해 이동중임을 나타낸다.


디스크 row에서 버퍼로 페이지를 적재하는 도중에 페이지를 다

른 트랜잭션이 읽어서는 안 된다. 왜냐하면 적재 도중이기 때문

에, 페이지의 일부는 예전의 데이터, 일부는 새롭게 읽은 데이터

가 될 수 있다. 이 때문에 디스크로부터 read를 위해서 write

lock 을 획득하여 다른 누구도 read가 끝날 때까지 접근할 수 없

도록 한다.

알티베이스 서버는 사용 가능 BCB를 바로 얻을 수 있도록 하기

위해 전체 버퍼 풀의 크기에 대한 free list의 개수를 약 10% 비

율로 유지한다. free list의 개수가 10%이하로 떨어진다면 버퍼

교체를 통하여 사용 가능한 BCB를 확보하려는 시도를 하게 된

다. 이 값만큼 사용 가능 BCB를 유지할 수 없어도 에러가 발생

하는 것은 아니다.

2. 버퍼 교체 만약 free list에 사용 가능한 BCB가 없다면, 이는 버퍼 풀이 전

부 사용중인 상태임을 의미한다. 이런 상황에서는 일부 페이지(희

생자)를 버퍼에서 디스크로 내리고 버퍼 풀의 공간을 우선 확보

해야 한다.

희생자는 버퍼에 올라온 페이지 중 가장 오랫동안 사용된 적이

없는 것이 선택된다.

다음과 같은 조건을 만족해야 희생자로 선정될 수 있다.

- 아무도 fix하지 않은 것

- 디스크로부터 read 혹은 write가 진행 중이 아닌 것

- 버퍼에 적재된 이후 수정되지 않은 것

만약 선택할 수 있는 희생자가 없는 상황이라면 알티베이스 서

버는 일정시간 대기 하면서 희생자가 생길 때까지 대기한다. 이때

trc/altibase_sm.log에는 "버퍼 풀 부족하다"는 메시지가 로깅된

다. 이러한 상황이라면 관리자는 버퍼 풀의 크기가 수용해야 하는

데이터의 양보다 작음을 인식하고 버퍼 풀을 증가시켜 주어야 한

다.

지정된 시간까지 희생자가 생기지 않으면 알티베이스 서버는 버

퍼 풀이 부족하다는 에러를 내고 트랜잭션을 종료시킨다.

3. 읽기 후 페이지 검증 BCB가 확보되면 디스크로부터 페이지를 버퍼에 적재한다. 그런

데 디스크에 저장된 페이지는 하드 디스크 이상이나 정전 등의

예측하지 못한 이유로 인해 일부 페이지의 내용이 깨진 상태일

수 있다. 이러한 상황의 발생을 인식하지 못하면 사용자는 잘못된

데이터를 보게 되므로 알티베이스 서버는 이를 인식해야 한다. 이

를 위해 알티베이스 서버는 디스크로부터 페이지를 버퍼에 적재

한 직후 바로 해당 페이지가 무결한 지 검사한다.


1. free BCB 획득

DB

2. rea

d from

disk

Free List

BCB BCB BCB BCB

3. validate pageRead

Success

<그림 7-４> 해쉬 테이블 검색

Flush 1. flush 대상 선정

버퍼에 적재된 이후 수정된 페이지는 희생자로 선택된 경우나 체

크포인트 시에 디스크에 flush된다. 버퍼에 적재된 페이지가

flush 되기 위해서는 다음의 조건을 만족 시켜야 한다.

- 현재 IO 수행 중이 아님

- 한번 이상 수정되어야 함

- fix 개수가 0이어야 함

flush 중에 다른 트랜잭션에 의한 읽기는 아무런 문제 없이 동시

에 가능하다. 따라서 read 모드로 권한을 획득하게 된다.

2. 로그 flush 수정된 페이지를 디스크에 반영하기 전에는 항상 수정된 내용에

대한 로그를 먼저 디스크에 반영해야 한다(WAL). 그리고 디스크

로부터 버퍼에 페이지를 적재할 때 이 페이지가 깨졌는지 확인할

수 있도록 체크 섬을 계산한다. 페이지를 디스크로부터 읽을 때

이 체크 섬을 다시 한번 계산하여 페이지의 체크 섬과 비교함으

로써 페이지가 무결한지 여부를 가리게 된다.

3. Double Write(DW) 버퍼에 페이지 flush 알티베이스는 하드 디스크의 물리적 손상으로부터 데이터를 보호

하기 위하여 DW 버퍼를 사용한다. 하드 디스크의 물리적인 손상


으로 페이지 write 도중 실패하면 이 페이지의 데이터를 다시 복

구할 방법이 없다. 이에 대비하여 시스템 시작 시에 DW 영역이

라는 디스크 영역을 일부 확보하고, DW 버퍼라는 메모리 영역을

일부 확보한다. DW 버퍼의 내용은 DW영역에 그대로 write하며,

디스크의 DW 영역의 크기와 메모리의 DW 버퍼의 크기는 정확

하게 일치한다. 이 영역은 보통 익스텐트 크기의 2배 크기이다.

다수 개의 페이지 flush시에, 각 페이지는 먼저 DW 버퍼에 복사

된다. 모든 페이지가 다 복사되면 DW 버퍼의 내용을 먼저 DW

영역에 write 한 후, 페이지를 디스크에 write한다. 즉 하나의 페

이지는 DW 영역에 한번 더 write된다. 이때 페이지가 write 도

중 손상되어도 DW 영역에 있는 또 하나의 복사본을 이용하여 복

구할 수 있다. 알티베이스는 시스템 시작 시에 만약 페이지가 손

상되었다면 DW 영역의 페이지를 이용하여 자동으로 복구를 수행

한다.

Temp 테이블스페이스의 페이지에 대해서는 DW 버퍼를 사용하

지 않고 바로 디스크에 write한다.

<그림 7-５> Double Write Page Flush


관련 프로퍼티

이름 내용

BUFFER_POOL_SIZE 버퍼 풀의 크기. 운영 중에는 크기 변

경을 할 수 없다. 서버 정상 종료 후

altibase.properties에서 설정 변경 후

서버 시작하면 적용된다.

BUFFER_POOL_MAX_SIZE 버퍼 풀의 최대 크기.

BUFFER_POOL_SIZE보다 크게 설정

해야 된다.

BUFFER_FLUSH_INTERVAL_IN_SEC flush thread의 flush 주기. 초단위로

이 시간마다 flush thread가 깨어나

주기적으로 flush를 수행한다. 만약

알티베이스 서버가 처리해야 할 트랜

잭션이 많다면 이 주기는 짧은 시간

으로 자동 조절된다. 처리해야 할 트

랜잭션이 줄어 알티베이스 서버에 빈

시간이 많다면 큰 값으로 조절되어

flush thread의 주기를 늦춘다.


통계 정보 버퍼 관리자 통계 정보는 알티베이스가 제공하는 성능 뷰를 통해

확인 할 수 있다. 성능 뷰에 대해서는 제3장 데이터 딕셔너리를

참조한다.

버퍼 관리자와 관련된 정보는 V$BUFFERPOOL_STAT을 통해

볼 수 있다. 자세한 칼럼의 의미는 제3장 데이터 딕셔너리를 참

조한다.

통계 정보는 서버가 시작한 이래로 계속 누적된 값이므로 특정

기간 동안의 값을 알기 위해서는 (현재의 값 - 측정 시작 시점의

값)을 모든 칼럼 값에 대해 계산해야 한다.

miss rate 구하기 miss rate은 다음과 같은 식으로 구할 수 있다.

버퍼 miss rate = 디스크로부터 읽은 페이지/전체 요청된 페이지

예제)

iSQL> select (read_page_count + create_page_count)/(get_page_count + create_page_count) buffer_miss_rate from v$buffpool_stat;

버퍼 관리자가 busy 한 상황인지 확인하기 운영중 알티베이스 서버의 성능이 저하된다면 다음과 같은 것을

확인해 볼 수 있다.

- free list count 대 전체 풀 크기가 10%를 넘지 못하면서 free

list count가 급격히 떨어지는가?

- altibase_sm.log에 "Buffer pool reaches the maximum” 과 같

은 메시지가 찍히는가?

서버가 busy한 상황에서 free list count가 10%이내로 떨어지면

버퍼 교체가 발생한다. 이런 상황은 정상적으로 일어날 수 있는

상황이지만, 아주 급격히 떨어지면서 시스템의 I/O 수행이 매우

높으면, 트랜잭션의 개수에 비해 버퍼 크기가 작지 않은가 의심해

볼 수 있다.


또한 altibase_sm.log에 버퍼 풀이 최대치에 이르렀다는 메시지가

자주 발견된다면 이는 트랜잭션에 비해 버퍼의 크기가 작은 것으

로 버퍼의 크기(BUFFER_POOL_SIZE)를 좀 더 키워줄 필요가

있다.

예제)

- free list의 비율 확인

iSQL> select free_list_count/curr_size free_rate from v$buffpool_stat;

백업 및 복구 243

8. 백업 및 복구

본 장은 시스템 정전 또는 디스크 ,데이터파일 손상 유실 등과 같

은 예기치 않은 상황으로 인해 알티베이스에 저장된 데이터가 손

실될 경우를 대비하여 알티베이스에서 지원하는 백업 및 복구에

대하여 설명한다.


알티베이스 백업 알티베이스에서 제공하는 백업 유형과 정책에 대하여 기술한다.

알티베이스 백업 정책 알티베이스에서 제공하는 백업을 분류하면 다음과 같다.

논리적 백업

물리적 백업

논리적 백업은 export 혹은 iLoader를 이용하여 테이블 생성, 인

덱스 생성 스크립터와 테이블의 레코드들을 내려 받은 파일들을

생성한다.

물리적 백업은 데이터베이스를 구성하는 데이터파일들과 로그앵

커파일의 복사를 수행한다.

물리적 백업은 데이터파일의 snapshot을 복사할 때 서비스 중지

여부에 따라 온라인 백업과 오프라인 백업으로 나눌 수 있다.

온라인 백업은 서비스 중지 없이 데이터베이스 데이터파일을 복

사하는 것을 의미하며 이 데이터파일 복사과정에서 commit 되지

않은 데이터들도 백업될 수 있다. 따라서 복구 시에 트랜잭션 철

회(undo)를 수행하기 위하여 온라인백업은 데이터베이스를 아카

이브 로그 모드로 운영하는 경우에만 가능하다.

오프라인 백업은 데이터베이스 서버를 정상 shutdown한 후에

모든 데이터베이스 파일, 로그앵커파일과 로그파일들을 복사하는

것을 말한다.

온라인 백업은 데이터베이스 전체를 백업 받을 수 있거나, 특정

테이블스페이스 또는 로그앵커를 백업 받을 수 있다.

각 구문은 다음과 같다.

alter database backup database to /backup;

alter database backup tablespace SYS_TBS_DATA to /backup;

시스템 카탈로그 정보를 포함하는 메모리 테이블스페이스

인 SYS_TBS_MEMORY는 테이블스페이스 백업이 아니라 전체

데이타베이스 백업 시에만 백업이 이루어진다.

이를 표로 정리하면 다음과 같다.


백업 종류 백업 방법 백업 대상 객체 Restore 방

법

서비스 가능 여부

iLoader 이용 iLoader의 out 옵션 이용

사용자가 명시한 테이블

iLoader의 in 옵션 이

용 O

온라인 백업(DB전체)

SQL 문 이용 alter database backup datbase to backup_dir;

시스템 전체 테이블

스페이스의 데이터

파일,로그 앵커파

일

1> 유닉스 명령어 cp 이용. 2> alter database recover database;

O

온라인 백업 (특정 테이블스

페이스)

SQL 문 이용 alter database backup tablespace 테이

블스페이스이름 to backup_dir;

테이블스페이스의 모든 데이터파일

1> 유닉스 명령어 cp 이용. 2> alter database recover database;

O

오프라인 백업

1>데이터베이스 shutdown 2>유닉스 명령어 cp 이용

데이터베이스 전체

의 데이터파일, 그앵커파일, 로그파

일

유닉스 명령

어 cp 이용 x

백업시간비교 iLoader < online backup < offline backup

데이터베이스 모드 데이터베이스 운영 시 데이터파일에 반영한 온라인 로그 파일들

을 관리하는 방법에 따라 데이터베이스 모드는 아카이브 로그

(archivelog)모드와 노아카이브 로그(noarchivelog) 모드로 나눌

수 있다.

아카이브 로그 모드에서는 데이터파일에 반영하고 난 로그 파일

들을 아카이브로그 디렉토리로 복사를 한다.

아카이브 로그 디렉토리는 ARCHIVE_DIR 프러퍼티로 지정된다.

노아카이브 로그 모드에서는 위의 로그 파일들을 지운다.

데이터베이스 모드에 따른 장단점을 비교하면 다음과 같다.

데이터베이스 모드 장 점 단 점

아카이브 로그 (archivelog)

매체복구(media recovery)가 가능하다. 즉 데이터파일의 유실이나 깨짐이 발생하여도 현재

아카이브 로그 파일을 담기위한 디스크 공간이 필요하다. DBA의 역할이 커진다. 아


시점까지 복구 가능하다. 카이브 로그를 다른 저장

장치로 받아 낸다든지, 파일 정리 등의 역할이 커진다. 아카이브 로그 디스크 공간이 부족하면 장애가 발생한다.

노아카이브 로그 (noarchivelog)

아카이브 로그 파일 관리

가 필요없기 때문에 DBA 부담이 적다.

데이타 파일의 손상이 발생한다 해도, DBA는 오프

라인 백업을 이용한 복구 밖에는 하지 못한다. 즉 복구가 오프라인 백업

을 받은 시점까지 가능하

며, 백업 받은 시점과 데이터파일의 손상이 발생한 시점 사이에 데이터는 잃어버린다.

데이터베이스 모드 결정은 create database 구문에서 결정되며,

control startup 단계에서 변경될 수 있다.

다음 예는 아카이브 로그 모드로 데이터베이스를 생성하는 예이

다.

create database mydb INITSIZE=100M archivelog;

다음 예는 control startup 단계에서 데이터베이스 모드를 아카이

브 로그 모드로 변경하는 예이다.

shell> isql -silent -s 127.0.0.1 -u sys -p manager -sysdba [ERR-00000: Connected to idle instance] iSQL> startup control; Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE: PROCESS TRANSITION TO PHASE: CONTROL Command execute success. iSQL> alter database archivelog;


알티베이스 복구

복구 개념 알티베이스는 다음 두 종류의 복구를 제공한다.

재시작시 자동복구 (Restart Recovery)

매체복구 (Media Recovery)

재 시작 시 자동복구는 알티베이스 프로세스가 시스템이 crash

되거나 소프트웨어 오류로 비정상 종료된 경우, startup 단계에서

자동으로 수행되는 복구이다.

매체복구는 특정 데이터파일이 유실되거나 깨진 경우에 백업 받

은 과거 데이터파일의 snapshot을 이용하여 백업 데이터파일의

복구 시작 LSN부터 현재 LSN까지 재 수행하여 과거의 데이터파

일의 snapshot으로부터 현재 시점의 데이터파일의 snapshot까지

복구를 말한다.

데이터파일의 매체복구가 필요한가에 대한 판단은 로그앵커 파일

상의 해당 데이터파일의 버전과 데이터파일의 버전과 일치 여부

에 따라 결정된다.

그림으로 나타내면 아래와 같다.

<그림 8-１> 알티베이스 복구절차


알티베이스에서는 매체복구를 control startup 단계에서만 할수

있다. 즉 오프라인 매체복구(offline media recovery)만 지원한다.

다음은 (방법 2) 매체복구의 예이다.

TEST 테이블스페이스의 데이터파일 user1.dbf파일이 유실되었

다.

이틀 전에 online 백업 받은 user1.dbf파일을 이용하여 현재 시

점의 데이터파일로 복구하는 예는 다음과 같다.

shell> cp /bck/user1.dbf $ALTIBASE_HOME/dbs shell> isql -silent -s 127.0.0.1 -u sys -p manager -sysdba [Connected to idle instance] iSQL> startup control Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE: PROCESS TRANSITION TO PHASE: CONTROL Command execute success. iSQL> alter database recover database; [RECMGR] Starting media recovery database.. Total 1 file(s) Suggestion Logfile: <32,345698>-<102,172168> Applying suggested logfile: logfile0...* Log Applied Writing to ..[USER1.DBF<ID:0>] [RECMGR] Media recovery database completed Alter success.

TEST 테이블스페이스의 user1.dbf 데이터파일이 복구 완료되었

음.

iSQL> startup service;

매체복구가 완료되었기 때문에 service 단계로 전이한다.

완전 복구와 불완전 복구


알티베이스 매체복구 정책은 완전 복구와 불완전 복구를 모두

지원한다.

완전 복구라 하면 온라인로그와 아카이브 로그의 유실 없이 현재

시점까지 데이터파일 복원을 의미한다.

불완전 복구는 아카이브 로그 또는 온라인로그 유실이 있거나, 특

정 시각으로 복원하는 것을 의미하며 백업된 loganchor와 백업된

전체 데이터베이스를 사용하여 특정 과거 시점으로 데이터베이스

전체가 돌아가는 경우이다.

완전복구의 예는 다음과 같다.

alter database recover database;

불완전 복구는 다음 3가지 경우로 나눌 수 있다.

과거의 특정 시점으로 데이터베이스 전체를 되돌리는 경우.

2005년 3월 29일에 받은 전체 데이터베이스 백업 파일을 cp

를 이용하여 복구한다.

alter database recover database until time 2005-04-

04:17:55:00;

2005년 4월4일 버전으로 데이터베이스 전체가 되돌려 진다.

특정 온라인로그 파일이 손상되어 현재 시점까지 redo를 할

수 없는 경우

alter database recover database until cancel;

손상된 온라인로그 파일 바로 전까지 redo를 진행한다.

백업된 데이터베이스와 아카이브 로그파일과 온라인 로그파

일이 모두 존재하여 현재시점까지 복구하는 가능한 경우

alter database recover database until cancel;

마지막 온라인로그 파일까지 redo를 진행한다.

특별히 이 경우는 미디어 복구 절차를 없이 정상 서버 startup으

로 복구가 가능하다.

control startup 단계에서 불완전 복구를 한 경우에 meta startup

단계으로 넘어갈 때 반드시 다음 구문을 사용해야 한다.

alter database db-name meta resetlogs;

데이터베이스가 특정 과거 시점으로 복원되었기 때문에, 재시작

시 자동복구(Restart Recover)를 수행하지 않기 위하여 온라인로

그를 초기화(resetlogs)한다.


meta startup 단계로 resetlogs를 하면서 startup 단계로 전이 하

였다면, 오프라인이나 온라인 백업으로 데이터베이스 전체 백업을

반드시 받아야 한다.

예를 들면, resetlogs를 하고 meta startup 단계로 전이하고 나서

2일 이후에 매체에 또다시 에러가 발생한 경우에, resetlogs 이전

까지만 복구가 가능하기 때문이다.

즉, resetlogs 이후부터 2일간의 데이터는 유실하게 된다.

매체복구 시 주의사항 완전 복구시에는 현재 로그앵커 파일들을 이용하여 매체복구를 하여야 하고, 불완전복구의 경우에는 백업된 로그앵커 파일을 이용하여야 한다. 데이터베이스 관리자가 실수로 drop tablespace , alter

tablespace등의 명령어로 테이블스페이스나 데이터파일을 삭제한

경우, 현재 로그앵커 파일에 테이블스페이스 정보가 남아 있지 않

기 때문에 백업된 로그앵커 파일을 써야 한다.

메모리 테이블스페이스 데이터파일에 대해서는 복구 시 stable한 메모리 데이터파일을 이용하여 unstable 한 메모리 데이터파일을 만들어 주어야 한다 알티베이스는 메모리 테이블스페이스에 대하여 핑퐁 체크포인트

(ping-pong checkpoint) 기법을 사용하기 때문에 디스크 상에서

메모리 테이블스페이스에 대하여 데이터파일을 2개로 유지한다.

동일한 이미지를 기록하고 있는 1묶음(pair)의 데이터파일은

MEM_DB_DIR 프로퍼티에 설정된 위치에 저장된다. 2 개의 데이

터파일이 모두 존재해야만 알티베이스를 정상적으로 운용할 수

있다. 어느 한 시점에서는 메모리 테이블스페이스는 오직 한 벌의

데이터파일만 사용된다.

백업 시 백업 시간을 줄이기 위하여 메모리 테이블스페이스의 가

장 최근 체크 포인터가 수행된 한 벌의 데이터파일만 백업한다.

따라서 백업된 메모리 테이블스페이스 데이터파일을 이용하여 복

구할 경우 나머지 한 벌의 데이터파일을 동일한 이미지로 생성하

여야 한다.

e.g.) 백업 받은 메모리 테이블스페이스의 데이터파일이 다음과

같다:

mydb-1-0, mydb-1-1, mydb-1-2

그러면 메모리 테이블스페이스의 데이터파일의 복사는 다음과 같

이 되어야 한다.

shell>cp mydb-1-0 $ALTIBASE_HOME/dbs; shell>cp mydb-1-0 $ALTIBASE_HOME/dbs/mydb-0-0;


shell>cp mydb-1-1 $ALTIBASE_HOME/dbs; shell>cp mydb-1-1 $ALTIBASE_HOME/dbs/mydb-0-1; shell>cp mydb-1-2 $ALTIBASE_HOME/dbs; shell>cp mydb-1-2 $ALTIBASE_HOME/dbs/mydb-0-2;

백업 시 주의사항 온라인 백업과 체크포인트는 동시에 수행될 수 없다. 체크포인트 시 메모리 상의 데이터베이스 내용이 디스크에 반영

되고 온라인 백업은 백업할 바로 그 시점까지의 데이터만 백업됨

을 보장하기 때문에 체크포인트와 온라인 백업은 서로 배타적으

로 수행된다.

체크포인트 수행 시 온라인 백업 요구가 들어오면 체크포인트가

완료된 후에 온라인 백업이 시작된다.

온라인 백업 진행 중 체크포인트 요구가 들어오면 체크포인트는

온라인 백업이 완료된 후 수행된다.

알티베이스는 하이브리드 데이터베이스 특성상 데이터베이스 백

업 시에 메모리 테이블스페이스, 디스크 테이블스페이스 순으로

백업을 진행한다.

메모리 테이블스페이스가 백업 중에는 체크 포인트가 수행 될 수

없지만, 메모리 테이블스페이스의 백업이 완료되고 디스크 테이블

스페이스 백업 중에는, 메모리 테이블스페이스에 대한 체크 포인

트는 수행하고 디스크 테이블스페이스에 대한 체크 포인트는 수

행하지 않는다.

이중화가 걸려 있는 경우 이중화 정보도 그대로 백업된다. 백업을 받는 알티베이스에 이중화가 걸려 있는 경우 이중화 관련

정보도 그대로 백업되기 때문에 백업된 데이터베이스를 동일하지

않은 시스템에 복구하는 경우 그 머신의 network ip가 달라지므

로 알티베이스 복구 후 이중화 사용에 문제가 발생할 수 있다.

따라서, 이중화가 걸려 있는 경우 (1) 이중화를 중지 및 삭제한

후 백업을 수행하거나 또는 (2) 이중화를 사용할 두 시스템에서

데이터베이스를 복구할 경우 반드시 한 쪽 시스템의 알티베이스

를 내린 상태에서 다른 시스템의 알티베이스를 복구한 후 이중화

를 삭제하여 다른 시스템으로 이중화가 되는 것을 방지해야 한다.

데이터파일이 추가, 삭제, 이름 변경과 같은 테이블스페이스에 대한 변경을 수행하게 되면, 메모리 테이블스페이스 백업이나 전체 데이터베이스가 백업되어야 한다. 로그앵커 파일은 데이터베이스의 테이블스페이스 정보를 포함하

고 있으므로, 테이블스페이스 구조가 변경될 때마다 메모리 테이

블스페이스와 함께 백업되어야 한다.


백업 및 복구 사례들

iLoader 를 이용한 테이블 백업 및 복구 임의의 테이블에만 문제가 발생할 것을 대비하거나, 어떠한 이유

로 인하여 해당 테이블만 백업을 받고자 하는 경우 사용한다.

백업 전 주의 사항 백업하기 전에 반드시 백업하고자 하는 테이블의 스키마에 관한

파일(FORM file)을 생성해야 한다. FORM 파일이란 테이블에 관

한 기본 정보(칼럼 이름, 데이터 타입)를 가지고 있는 파일을 말

한다.

FORM 파일 생성 예제

백업 방법 iLoader의 옵션 중 out 옵션을 사용한다.

백업의 결과

사용자가 명시한 이름으로 테이블에 대한 백업 파일이 생성된다.

예제

복구(restore) 방법 iLoader의 옵션 중 in 옵션 사용

복구시 테이블에 레코드가 존재하는 경우 그 레코드들을 유지하

게 하거나 덮어쓰게 할 수 있으며 사용자가 명시하지 않는 경우

존재하는 레코드들의 내용은 유지된다.

예제

ex) 테이블 t1의 백업

(이용할 form 파일은 t1.fmt

생성할 백업 파일은 t1.dat )

ex) 테이블 t1의 form file 생성

(t1.fmt라는 파일 이름으로 생성됨)

iloader formout –T t1 –f t1.fmt

ex) 테이블 t1의 복구

iloader in –T t1 –d t1.dat –f t1.fmt


Offline 백업 및 복구 오프라인 백업 및 복구는 주로 노아카이브 로그 모드일 경우에

주로 사용하는 방법이다.

백업 전 주의 사항 백업 전 알티베이스와 관련된 모든 서비스를 중지한다.

서비스 진행 중에 오프라인 백업을 수행하면 로그 파일에 내용이

변경됨과 동시에 백업이 진행될 수 있어서 백업이 정확하게 수행

되지 않을 수 있다. 그러므로 반드시 알티베이스를 중지하고서 수

행하여야 한다.

백업 방법 테이블스페이스의 데이터파일들, 로그 파일, 로그 앵커 파일을 유

닉스 명령어 cp를 이용하여 백업한다.

주의 사항 알티베이스는 메모리 데이터파일 뿐만 아니라 디스크 관련

테이블스페이스의 데이터파일들을 백업해야 한다.

메모리 테이블스페이스 데이터파일 저장 위치는 알티베이스

프로퍼티 파일인

$ALTIBASE_HOME/conf/altibase.properties 파일 내에

MEM_DB_DIR으로 설정되어 있다.

메모리 테이블스페이스의 데이터파일을 백업 받기 위해서는

MEM_DB_DIR 디렉토리를 모두 복사해야 한다.

로그 앵커 파일의 위치는 LOGANCHOR_DIR 프로퍼티로

altibase.property 파일 내에 설정되어 있다.

로그 앵커 파일을 백업 받기 위해서는 LOGANCHOR_DIR

디렉토리의 파일들을 복사해야 한다. 그리고 나서 디스크의

테이블스페이스의 데이터파일들을 복사하면 된다.


예제

복구 방법 알티베이스 설정 파일은 백업될 당시의 설정 파일을 그대로 이용

한다.

공유 메모리에 남아있는 데이터베이스를 삭제한다.

백업 시 받았던 파일들을 cp를 이용하여 복구한다.

파일을 사용하도록 하여야 한다.

매체복구 사례 1

ex) 프로퍼티 파일의 MEM_DB_DIR=$ALTIBASE_HOME/dbs0

MEM_DB_DIR =$ALTIBASE_HOME/dbs1

LOGANCHOR_DIR =$ALTIBASE_HOME/logs

디스크 테이블스페이스는 system tablespace,undo tablespace,

temp tablespace만 있다.

백업 파일이 저장될 위치 : /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

ex) 위에서 백업된 데이터베이스를 이용하여 복구

$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


아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 백업받지

않은 데이터파일 /home1/dbs/abc.dbf가 유실되었다.

복구 방법 1. control startup 단계로 가서 빈 데이터파일 abc.dbf을 생성

한다.

shell> isql -silent -s 127.0.0.1 -u sys -p manager -sysdba [ERR-00000: Connected to idle instance] iSQL> startup control; Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE: PROCESS TRANSITION TO PHASE: CONTROL Command execute success. iSQL> alter database create datafile /home1/dbs/abc.dbf;

2. 매체복구를 수행한다.

iSQL> alter database recover database;

매체복구 사례 2 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 3일전

에 테이블스페이스 users의 데이터파일들을 백업 받았다.

오늘 오전에 users 테이블스페이스의 데이터파일을 모두 잃어 버

렸다.

백업 방법 3일전에 수행했던 백업은 다음과 같다.

iSQL>alter database backup tablespace users to /backup1; shell> ls /backup1 user001.dbf user002.dbf user003.dbf

복구 방법

1. 백업 디렉토리에 받아놓은 백업 데이터파일을 users 테이블

스페이스의 파일이 있었던 $ALTIBASE_HOME/dbs/에 cp

를 한다.

shell> cp /backup1/*.dbf $ALTIBASE_HOME/dbs;

2. 다음과 같이 매체복구를 수행한다.


shell> isql -silent -s 127.0.0.1 -u sys -p manager -sysdba [ERR-00000: Connected to idle instance] iSQL> startup control; Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE: PROCESS TRANSITION TO PHASE: CONTROL Command execute success.



매체복구 사례 3 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 7일전에

테이블스페이스 task의 데이터파일들을 백업 받았다.

오늘 오후에 task 테이블스페이스의 데이터파일이 있는 /disk1

파일 시스템이 깨졌으며, /disk2는 파일 시스템은 온전하였다.

백업 방법 일주일 전에 수행했던 백업은 다음과 같다.

iSQL>alter database backup tablespace task to /backup1; shell> ls /backup1 task001.dbf task002.dbf

복구 방법 1. 백업 디렉토리에 받아놓은 백업 데이터파일을 task 테이블

스페이스의 파일들을 온전한 /disk2파일 시스템으로 복사

(cp)를 한다.

shell> cp /backup1/*.dbf /disk2/dbs;

2. 다음과 같이 매체복구를 수행한다.


3. task 테이블스페이스 데이터파일 위치를 변경한다.


iSQL> alter database rename datafile/disk1/dbs/task001.dbf to /disk2/dbs/task001.dbf; iSQL> alter database rename datafile/disk1/dbs/task002.dbf to /disk2/dbs/task002.dbf;



매체복구 사례 4 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, DBA 실

수로 테이블 summary를 drop하였다. Drop된 시간이 2005년 4

월 6일 22시 30분이였다. 바로 10분 전으로 데이터베이스를 되

돌리길 원한다.

백업 방법 불완전 매체복구를 하기 위해서는 전체 데이터베이스 백업이 필

요하다.

iSQL>alter database backup database to /backup1;

복구 방법 1. 백업 받은 데이터파일들을 원래 위치로 복사를 한다.


2. 백업 받은 logachor파일 복사본을 copy한다.

shell> cp /backup1/loganchor* $ALTIBASE_HOME/logs

3. 메모리 테이블스페이스는 ping-pong 체크 포인트 기법을

사용하고 있으며, 메모리 테이블 백업 시 stable한 데이터베

이스 파일 만 복사되었다. 백업 받은 stable한 버전의 데이

터파일을 이용하여 unstable한 버전을 만들어 복사한다.


같다:


복사는 다음과 같이 수행되어야 한다.

shell>cp mydb-1-0 $ALTIBASE_HOME/dbs; shell>cp mydb-1-0 $ALTIBASE_HOME/dbs/mydb-0-0; shell>cp mydb-1-1 $ALTIBASE_HOME/dbs; shell>cp mydb-1-1 $ALTIBASE_HOME/dbs/mydb-0-1; shell>cp mydb-1-2 $ALTIBASE_HOME/dbs; shell>cp mydb-1-2 $ALTIBASE_HOME/dbs/mydb-0-2;


4. control startup 단계에서 미디어복구에 필요한 아카이브 로

그파일을 검색한다. 아래에서 검색된 번호의 로그파일부터

는 online log 디렉토리에 존재해야 한다.

iSQL> SELECT last_deleted_logfile FROM v$log; LAST_DELETED_LOGFILE ----------------------- 32

5. 적절한 아카이브된 로그파일32번부터 online log 디렉토리

에

빠짐없이 존재하도록 복사한다.

6. 볼완전 매체복구를 다음과 같이 수행한다.

shell> isql -silent -s 127.0.0.1 -u sys -p manager -sysdba [ERR-00000: Connected to idle instance] iSQL> startup control; Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE: PROCESS TRANSITION TO PHASE: CONTROL Command execute success. iSQL> alter database recover database until time 2005-04-06:22:20:00;

7. 불완전 미디어 복구를 수행하였기 때문에 meta startup단계

로 가기전에 resetlogs를 하여야 한다.

iSQL> alter database db_name meta resetlogs;

8. resetlogs를 수행하였기 때문에 데이터베이스 전체 백업을

받는다.

iSQL> alter database backup database to /backup1;

매체복구 사례 5 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 온라인로

그 파일이 log499~ 520이 있으며, 중간 log인 510번 로그 파일

이 손상을 입었다. log 509번까지 데이터베이스 상태를 보전하고

싶다.

백업 방법 1. 백업 받은 데이터파일들을 원래 위치로 복사를 한다.

shell> cp /backup1/*.dbf $ALTIBASE_HOME /dbs;


2. 백업 받은 logachor파일 복사본을 copy한다. shell> cp /backup1/loganchor* $ALTIBASE_HOME/logs



이스 파일 만 복사되었다. 백업 받은 stable한 버전의 데이

터파일을 이용하여 unstable한 버전을 만들어 복사한다.


같다:









에 빠짐없이 존재하도록 복사한다.

6. 다음과 같이 볼완전 매체복구를 다음과 같이 수행한다.


7. Log499~509까지만 redo를 수행하고, 510번 이후의 log에

대해서는 redo를 수행하지 않는다.

iSQL> alter database recover database until cancel;

8. 불완전 미디어 복구를 수행 하였기 때문에 meta startup 단

계로 가기 전에 resetlogs를 하여야 한다.



9. reset log를 수행하였기 때문에 데이터베이스 전체 백업을

받는다.


매체복구 사례 6 노아카이브 로그 모드이지만 매체복구를 할수 있는 경우가 있다.

바로 임시(temporary) 테이블스페이스의 데이터파일이 유실되는

경우이다. 임시 테이블스페이스에 대해서는 재수행이 필요 없기

때문이다.

백업 방법 1. control startup 단계로 가서 임시 테이블스페이스의 빈 데

이터파일 temp001.dbf를 생성한다.


2. 임시 테이블스페이스의 데이터파일을 생성만 하면된다.

iSQL> alter database create datafile /home1/dbs/temp.dbf; iSQL> alter database dbname service;

매체복구 사례 7 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 메모리

테이블스페이스의 데이터파일이 손상을 입었다.

메모리 테이블스페이스는 시스템 카탈로그 등 중요 시스템 데이

터가 저장되어 있는 공간이기 때문에, 이전에 받은 전체 데이터베

이스 백업을 이용하여 복구를 하여야 한다.

백업 방법 메모리 테이블스페이스의 데이터파일이 손상을 복구하기 위해서

는 전체 데이터베이스 백업이 필요하다.

iSQL>alter database backup database to /backup1;

복구 방법


1. 백업 받은 데이터파일들을 원래 위치로 복사를 한다.


2. 백업된 logachor파일 복사본을 copy한다.

Shell> cp /backup1/loganchor* $ALTIBASE_HOME/logs

3. 메모리 테이블스페이스는 ping pong 체크 포인트 기법을 사

용하고 있으며, 메모리 테이블 백업시 stable한 데이터베이

스 파일 만 복사되었다. 백업 받은 stable한 버전의 데이터

파일을 이용하여 un stable한 버전을 만들어 복사한다.


같다:









에 빠짐없이 존재하도록 복사한다.

6. 매체복구를 다음과 같이 수행한다.

shell> isql -silent -s 127.0.0.1 -u sys -p manager -sysdba [ERR-00000: Connected to idle instance] iSQL> startup control; Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE: PROCESS TRANSITION TO PHASE: CONTROL Command execute success. iSQL> alter database recover database;

매체복구 사례 8


아카이브 로그 모드로 데이터베이스를 운영하고 있으며, DBA 실

수로 테이블스페이스 task를 drop 하였다. 시간은 2005년 4월 6

일 22시 30분이였고, 바로 10분 전으로 데이터베이스를 되돌리

길 원한다.

백업 방법

불완전 매체복구를 하기 위해서는 전체 데이터베이스 백업이 필

요하다.

iSQL>Alter database backup database to /backup1;

복구 방법 1. 백업 받은 데이터베이스 데이터파일들을 원래 위치로 복사

를 한다.

shell> cp /backup1/*.dbf /disk1/dbs;



이스 파일만 복사되었다. 백업 받은 stable한 버전의 데이터

파일을 이용하여 unstable한 버전을 만들어 복사한다.


같다:




3. 백업 로그 앵커 파일들도 복사한다.(현재 로그 앵커에는

drop 된 테이블스페이스 정보가 없기 때문이다.)

shell> cp /backup1/loganchor? $ALTIBASE_HOME/logs;





적절한 아카이브된 로그파일489번부터 online log 디렉토리에 빠짐없이 존재하도록 복사한다.


5. 불완전 매체복구를 다음과 같이 수행한다.

shell> isql -silent -s 127.0.0.1 -u sys -p manager -sysdba [ERR-00000: Connected to idle instance] iSQL> startup control; Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE: PROCESS TRANSITION TO PHASE: CONTROL Command execute success. iSQL> alter database recover database until time 2005-04-06:22:20:00 using backup loganchor;

6. 불완전 미디어 복구를 수행하였기 때문에 meta startup 단

계로 가기전에 resetlogs를 하여야 한다.


7. resetlogs를 수행하였기 때문에 데이터베이스 전체 백업을

받는다.


SQL 튜닝 265

9. SQL 튜닝

본 장에서는 질의 성능을 향상시키기 위한 SQL 튜닝 방법에 대

하여 설명한다.



266

SQL 튜닝 소개 SQL 튜닝이란 SQL문의 성능을 극대화하기 위해 조치하는 모든

일련의 작업을 의미한다. 따라서 SQL 튜닝 방법에는 SQL문의 변

경, 데이터베이스 스키마 변경, 알티베이스 프로퍼티 조정, 운영

체제 커널 파라미터 조정 등의 작업들이 포함된다.

SQL 튜닝 방법 중 SQL문의 변경과 데이터베이스 스키마 변경의

경우는 알티베이스의 SQL문 처리 방법과 제한 사항 등에 의해

영향을 받기 때문에 알티베이스의 SQL문 처리에 대한 심도 높은

이해가 요구된다. 또한, 메모리 테이블과 디스크 테이블을 모두

사용할 수 있어 저장 매체의 특성에 따른 SQL 처리에 대한 이해

가 필요하다.

본 절에서는 간략하게 성능 관련 이슈를 살펴보고 질의 튜닝을

위해 필요한 기본 개념에 대하여 설명한다.

성능 관련 이슈

실행 계획 트리(Execution plan tree) 클라이언트에서 SQL문의 수행을 요구하면 질의 처리기는 구문

검사, 정당성 검사, 최적화 과정을 거쳐 실행 절차를 정의한 실행

계획 트리를 생성하고, 만약 주언어 변수가 존재하면 바인딩한 후

실행 계획에 따라 데이터베이스에 접근해 레코드를 검색하게 된

다. 이러한 SQL문의 수행 시간 중 대부분은 실행 과정의 시간으

로, 복잡한 SQL문의 경우 실행 계획 트리 구조가 성능의 큰 영향

을 끼친다.

데이터베이스 스키마와 크기 우선적으로 응용프로그램의 특성 및 자원 활용의 효율에 따라 메

모리 테이블 및 디스크 테이블의 사용을 적절히 고려하여야 하며,

일반적으로 자주 사용되는 데이터는 메모리 테이블로 접근 빈도

가 낮은 데이터는 디스크 테이블로 관리하는 것이 유리하다.

응용프로그램에서 사용할 SQL문의 종류를 고려해 각 SQL문 별

로 테이블에 접근하는 회수, 접근하는 레코드 수 및 디스크 페이

지 수가 최소 비용이 되도록 테이블 스키마의 구성과 인덱스 구

성에 유의해야 한다.

또한, 단순한 SQL문 또는 레코드 건수가 많은 테이블에 대해서는

술어(predicate) 내 칼럼값의 비교 비용이 성능에 큰 영향을 미치

므로 데이터 변환 비용을 최소화하고 비교 비용이 적은 적합한

데이터 타입의 선정이 중요하다.

따라서 가능한 적은 수의 레코드에 접근하도록 SQL문을 작성하

여 절대적 비교 회수를 줄여야 하며, 비교 연산 시 데이터 변환이

SQL 튜닝 267

일어나지 않도록 칼럼의 데이터 타입과 비교값의 데이터 타입을

잘 선정해야 한다.

응용프로그램 로직(테이블 접근 순서) 만약 여러 클라이언트가 여러 연결을 맺어 많은 세션이 존재할

경우 각 클라이언트의 테이블 접근 순서가 성능에 영향을 미칠

수도 있다. 한 트랜잭션 내에서 DML문을 여러 개 사용하고 여러

테이블에 접근하는 경우 응용프로그램에서 테이블에 접근하는 순

서 등을 잘못 설계할 경우 lock 대기 시간(lock waiting time)으

로 인해 전체 응용프로그램 성능이 저하될 수도 있으므로 유의해

야 한다.

시스템 리소스 한 SQL문의 질의 처리 시 성능에 영향을 미치는 시스템 리소스

는 가용한 메모리의 크기, 메모리 버퍼의 크기, 디스크 성능과

CPU 성능이다.

메모리 테이블만을 사용할 경우 검색 질의의 성능이 디스크의 성

능에 영향을 받지 않으나, 디스크 테이블의 경우 디스크 성능 및

가용한 메모리 버퍼의 크기에 따라 질의 성능이 영향을 받게 된

다. 이러한 점은 메모리 테이블을 사용할 경우 일정한 질의 응답

시간을 기대할 수 있는 반면, 디스크 테이블을 사용할 경우 질의

수행 시점의 환경에 따라 많은 성능 차이를 보이게 되는 원인이

된다.

ORDER BY, GROUP BY 등과 같이 질의 처리기 내에서 질의 처

리를 위해 sorting 기법이나 hashing 기법을 사용하는데 중간 결

과를 저장하기 위해 메모리 임시 테이블 또는 디스크 임시 테이

블을 사용하게 된다.

중간 결과를 메모리 임시 테이블에 저장하는 경우, 사용하는 메모

리는 데이터베이스 영역에 잡혀 있는 메모리가 아니기 때문에 이

경우 테이블의 크기가 크다면 많은 메모리가 필요할 수 있으므로

질의 처리 시 메모리 스와핑으로 인한 성능 저하가 일어나지 않

도록 해야 한다.

중간 결과를 디스크 임시 테이블에 저장하는 경우, 사용하는 자원

은 디스크 임시 테이블스페이스의 디스크 영역과 메모리 버퍼 영

역을 사용하게 되며 가용한 메모리 버퍼 영역의 크기에 따라 성

능에 커다란 영향을 미치게 된다.

또한 질의 처리 작업은 연산자를 처리하기 위한 작업이 많아

CPU를 많이 사용하게 되므로 CPU 점유율과 성능도 질의 성능에

영향을 많이 미친다.

SQL 튜닝 일반



268

이 절에서는 알티베이스에서 SQL 튜닝을 하고자 할 경우의 일반

적인 튜닝 방법론에 대해 간략하게 설명한다.

SQL 성능 측정 방법 SQL 성능 측정은 SES, ODBC, JDBC 등 실제 응용프로그램 환경

에서 정확하게 시간을 구하는 함수를 이용하여 측정하는 방법 이

외에 iSQL에서 다음 명령어를 이용해 SQL 수행 시간을 측정할

수도 있다.

SET TIMING ON;

iSQL에서 SQL 문을 수행할 경우 Prepare-Execute가 아닌

Direct-Execute 방법이므로 이 때 측정된 성능은 실제 응용프로

그램에서 Prepare-Execute 방법으로 측정하는 속도와는 차이가

있을 수 있다.

또한 iSQL의 경우 주 언어 변수 바인딩 과정이 없으므로 실제 응

용프로그램에서 주 언어 변수 바인딩을 하는 경우 성능 차이가

날 수 있는데 이에 대해서는 아래의 데이터 타입 확인 항목에서

자세히 설명한다.

메모리 테이블의 경우 iSQL로 질의를 반복 수행 시 거의 유사한

성능을 얻을 수 있으나, 디스크 테이블의 경우는 반복 수행 시 버

퍼 교체가 적게 발생하여 최초 수행 때보다 다음 수행 시 보다

나은 성능을 얻게 된다. 이는 디스크 테이블에 대하여 수행되는

질의는 동시 수행되는 질의들이 많을 경우 버퍼 교체에 의해 그

성능의 일정함을 보장할 수 없음을 의미한다.

그러나 일반적으로 iSQL상에서 SQL 튜닝을 하여 성능을 튜닝한

SQL 문의 경우 실제 응용프로그램에서도 같은 비율의 성능 향상

을 볼 수 있다.

실행 계획 트리의 분석 SQL 문의 실행 계획 트리는 SELECT 문에 대해서 iSQL 상에서

만 확인 가능하다.

DELETE 문이나 UPDATE 문의 경우에는 DELETE/UPDATE 문

에서의 FROM절과 WHERE절을 가지는 SELECT 문을 생성하여

실행 계획을 확인한다. DELETE 문과 UPDATE 문의 경우

SELECT 문 처리에서와 같이 최적화 과정을 거치므로 실제 내부

적으로 같은 실행 계획 트리가 생성된다. DELETE 문과

UPDATE 문의 경우에는 한 테이블에 대한 SCAN 노드만 생성되

므로 SCAN 노드의 정보를 이용하여 인덱스 검색 여부와 레코드

접근 회수를 유념해 검사하면 된다.

일반적으로 실행 계획 트리에서 확인해야 할 일반적인 내용은 다

음과 같으며, 자세한 내용은 다음 절에서 자세히 살펴본다.

효율적인 액세스 방법을 사용하는가?

조인 순서 및 방법은 바람직한가?

SQL 튜닝 269

적절한 데이터 타입 및 연산을 사용하는가?

불필요한 hashing 및 sorting을 수행하는가?

질의 튜닝 실행 계획 트리를 통해 성능 저하 요소를 분석한 후 이에 대한

적절한 조치를 취함으로서 성능을 개선할 수 있다. 자세한 질의

튜닝 방법은 질의 최적화 과정 및 질의 실행기에 대한 개념 설명

과정에서 자세히 다룬다.

메모리 테이블과 디스크 테이블 알티베이스는 메모리 테이블과 디스크 테이블을 모두 지원하는

최초의 Hybrid MM DBMS 이다. 따라서, 메모리 테이블과 디스

크 테이블에 대한 질의 처리에 대한 기본적인 차이를 이해하는

것은 질의 튜닝에 있어 큰 도움이 된다.

메모리 테이블과 디스크 테이블을 처리하기 위한 질의 처리기의

기본적인 차이는 다음과 같다.

Query Processor Item Memory Table Disk Table

Object identifier Pointer OID(RID) Buffer management N/A Limited buffer Executor

Join methods One-pass algorithms Multi-pass algorithms Main cost CPU Disk

Index selection Minimize record access Minimize disk I/O Optimizer 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)와

같은 특정 디스크 주소로 변환할 수 있는 식별자를 사용하게 된

다. 이러한 차이는 레코드 접근에 있어 메모리 테이블은 직접 접

근이 가능한 반면 디스크 테이블은 주소 변환에 의한 접근이 필

요하다.



270

메모리 테이블에 대한 질의 처리는 버퍼를 사용하지 않아 이에

대한 고려가 필요 없는 반면, 디스크 테이블에 대한 질의 처리는

제한된 메모리 버퍼 내에서 이루어지기 때문에 버퍼에 원하는 레

코드가 없을 경우(Buffer miss) 디스크 I/O를 유발하는 버퍼 교체

(Buffer replacement)가 수반하게 된다.

조인 방법은 크게 nested loop join, hash-based join, sort-

search join, merge join 계열로 분류할 수 있다. 각 계열의 조인

방법은 필요에 따라 중간 결과를 저장하게 되며 이 때 제한된 메

모리에 모두 적재할 수 있는 지의 여부에 따라 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]

등의 추가적인 통계 정보를 이용하여 비용 계산을 하게 된다.

SQL 튜닝 271

알티베이스의 실행기와 최적화기는 저장 매체의 차이를 충분히

반영하는 반면, 이에 대한 별도의 구분 없이 실행 계획을 생성하

고, 질의 처리시에 그 특성만을 반영하여 수행할 수 있도록 설계

되어 있다. 즉, 메모리 테이블과 디스크 테이블의 혼용된 질의

처리에 있어서도 저장 매체의 특성은 충분히 반영하면서 동일한

처리 과정을 따르게 된다.

질의 처리 (Query Processing) 개요 SQL문의 튜닝 시 항상 모든 응용프로그램에 적용해 최적의 성능

을 발휘하는 절대적인 규칙을 제시하기는 쉽지 않다. 데이터베이

스의 설계 또는 응용프로그램의 비지니스 로직에 따라 각 경우에

적용하는 방법은 매우 다양하다. 따라서 하나의 SQL문이 어떠한

과정을 거쳐 처리되는지, 성능에 영향을 미치는 요소는 어떠한 것

들이 있는지에 대해 설명하고 일반적인 방법론에 대해서만 제시

한다.

DBMS에서 SQL문 처리를 담당하는 모듈을 질의 처리기(Query

Processor)라 한다. 질의 처리기는 사용자가 수행을 요구한 SQL

문에 대해 정당성을 검사한 후 데이터베이스에 접근하는 최적의

접근 순서와 방법을 결정하고, 이에 따라 조건에 맞는 레코드를

검색한 후 필요한 연산을 수행하여 클라이언트에게 처리한 값을

돌려주는 모듈이다.

질의 처리수행 과정을 개략적으로 도식화하면 다음과 같다.

Server

Parsing

Validation

Optimization

Binding

Execution

Database

Client

Prepare

Bind

Execute

Fetch

<그림 9-１> Query Processing 순서



272

각 단계별 처리 내용은 다음과 같다.

1. 구문 파싱 (Parsing): SQL문 텍스트 문법 검사(syntax 검

사)하고 파싱 정보를 저장하는 파스 트리(Parse Tree) 생성

한다.

2. 정당성 검사(Validation): SQL문 의미상 정당성 검사

(semantic 검사)하고 메타 테이블 검색하여 파스 트리 확장

한다.

3. 최적화 (Optimization): 주어진 파스 트리를 다양한 통계 정

보와 접근 비용 계산을 통해 최적화된 실행 계획을 생성한

다.

4. 바인딩 (Binding): 주언어 변수값(host variable value) 을

생성된 실행 계획에 연결한다.

5. 실행 (Execution): 실행 계획 트리에 따라 SQL문 실행한다.

질의 튜닝을 위해 알티베이스의 질의 최적화와 질의 실행 과정을

이해하는 것은 매우 중요하며 다음 장에서 이를 중심으로 질의

튜닝 방법에 대하여 자세히 알아본다.

SQL 튜닝 273

질의 최적화 과정 질의 최적화(optimization) 과정은 주어진 SQL을 분석하여 가능

한 실행 계획을 작성하고 이에 대한 비용 평가를 통해 가장 효율

적인 실행 계획을 선택하는 과정이다. 질의 성능의 대부분이 이

과정에서 결정되며, 복잡한 질의일수록 질의 최적화 과정의 정확

성에 의해서 성능이 좌우된다.

질의 최적화 개요

Optimizer의 구조

Optimizer는 주어진 질의문을 구문 분석(parsing), 의미 분석

(validation) 과정을 거쳐 생성된 파싱 트리를 각종 비용 평가를

통해 효율적인 실행 계획 트리(plan tree)을 생성한다.

이러한 과정을 수행하는 optimizer의 구조는 다음과 같다.

Graph(Logical Operator)

Parse Tree

Plan Tree(Physical Operator)

Optimizer

Graph Manager

Plan treeManager

Predicate Manager

<그림 9-２> Query Processing 순서

Optimizer는 크게 그래프 관리자, 실행 계획 관리자, Predicate

관리자로 구성된다. Optimizer의 각 관리자가 하는 역할은 다음

과 같다.

그래프 관리자는 주어진 파싱 트리를 이용하여 논리 연산자인 그

래프를 생성하고 해당 그래프에 대한 비용을 계산하여 최적화 방

법을 결정한다.

실행계획 관리자는 생성된 그래프를 이용하여 주어진 최적화 방

법에 따라 실행 계획 트리를 생성한다.

Predicate 관리자는 그래프 관리자와 실행 계획 관리자가 실행

계획 트리를 결정하고 생성하기 위해 필요한 정보를 제공한다.

그래프(논리 연산자)의 종류



274

그래프 관리자는 효율적으로 파싱 트리를 분석하고 실행 계획 트

리를 생성하기 위해 중간 단계인 그래프를 생성하여 처리한다.

그래프는 총 12개로 구성되어 있으며 주요 그래프와 그 역할은

다음과 같다.

구분 그래프 기능 관련 SQL 구문 Selection 단일 테이블에 대한 접근 방법 FROM, WHERE Critical

path Join 조인의 수행 순서 및 방법 FROM, WHERE

Grouping 그룹 연산의 수행 방법 GROUP BY, HAVING, aggregation 연산

Distinction 중복 제거의 수행 방법 DISTINCT

Set 집합 연산의 수행 방법 UNION,

UNION ALL, INTERSECT, MINUS

Sorting 정렬 연산의 수행 방법 ORDER BY

Non critical path

Projection 프로젝션 연산의 수행 방법 SELECT

최적화기의 관점에서 검색 질의 성능에 가장 큰 영향을 미치는

부분은 FROM 과 WHERE 절로 이를 critical path라 한다. 이

외의 GROUP BY, ORDER BY 등과 같은 부분을 non-critical

path라 한다.

최적화기는 critical path의 처리를 위해 selection, join 등의 그

래프를 사용하여 이에 대한 수행 방법을 결정하며, non-critical

path의 처리를 위해 grouping, distinction, set, sorting,

projection과 같은 그래프를 사용하여 수행 방법을 결정하게 된

다.

실시간 통계 정보 Optimizer는 다양한 실행 계획의 비용 계산을 위해 실시간 통계

정보를 사용하게 된다. Optimizer는 기본적인 통계 정보 뿐 아

니라 최적화 과정을 통해 새로운 정보를 추정하고 비용 계산을

통해 다양한 예측 정보를 산출해 낸다.

알티베이스의 Optimizer가 사용하는 기본적인 실시간 통계 정보

는 다음과 같다.

기호 설명 T( R ) 테이블 R의 레코드 수 V(I) 인덱스 I 의 Value Cardinality, 인덱스 키값의 서로 다른 값의 개수

V(R.a) 칼럼 R.a의 Value Cardinality, 서로 다른 값의 개수 MIN(R.a) 칼럼 R.a의 최소값 MAX(R.a) 칼럼 R.a의 최대값

B( R ) 테이블 R의 디스크 페이지 개수 M 메모리 버퍼의 페이지 개수

SQL 튜닝 275

위와 같은 실시간 통계 정보는 데이터의 변경이 발생 할 때마다

별도의 부하 없이 변경되며, 사용자의 개입 없이 비교적 정확한

정보를 관리한다.

Optimizer는 이러한 실시간 통계 정보를 사용하기 때문에 다양한

실행 계획들에 대한 비용 평가가 가능하며 효율적인 실행 계획을

생성할 수 있다.

그러나, 통계 정보가 모든 질의를 위한 충분한 정보가 될 수 없으

며, Optimizer가 모든 환경에서 항상 효율적인 실행 계획을 생성

할 수 있는 것은 아니다. 따라서, 특정 질의의 경우 사용자가 성

능 향상을 위한 작업이 필요할 수 있으며 이를 위해서는 알티베

이스 질의 최적화 개념을 이해하는 것이 매우 중요하다.

질의 최적화 과정 알티베이스의 optimizer는 성능에 가장 큰 영향을 미치는 critical

path에 대한 최적화 방법을 우선적으로 결정하고, 이 후에 non-

critical path를 처리하는 bottom-up 방식의 최적화 순서를 따르

고 있다.

Critical path에 대한 실행 방법을 결정하기 위한 최적화 과정은

다음과 같다.

정규화: 사용자가 정의한 WHERE 절을 CNF와 DNF로 두

가지의 정규화된 형태로 변형한다.

각 정규화된 형태의 조건절을 이용하여 critical path에 대한

비용을 결정하고 이를 비교하여 critical path의 실행 계획을

결정한다. CNF와 DNF에 대한 처리는 동일한 과정을 거치며

다음과 같은 단계로 처리된다.

조건절의 분류: 정규화된 조건절을 하나의 테이블에 관계된

조건과 두 개 이상의 테이블이 관계된 조건으로 분류한다.

액세스 방법 결정: 우선적으로 각 테이블에 대한 조건절을

기준으로 비용이 가장 적은 인덱스 선택 등의 액세스 방법을

결정한다. 여기서 선택된 액세스 방법은 조인 과정을 통해

재조정된다.

조인 순서의 결정: 복잡한 질의 처리 과정에서 조인의 순서

는 질의 성능에 가장 큰 영향을 미치는 요소이며 이는 join

greedy algorithm을 통해 결정된다.

조인 방법의 결정: 조인 순서의 결정 후 각 조인 순서별로

최적의 조인 방법을 선택한다.

Non-critical path의 실행 방법을 결정하는 최적화 과정은

critical path에 대한 최적화 이후에 수행되며 그 과정은 다음과

같다.



276

그룹 연산의 수행 방법 결정: 질의에 GROUP BY, HAVING,

aggregation 연산이 포함되어 있을 경우 이를 처리하기 위한

수행 방법을 결정한다.

DISTINCT의 수행 방법 결정: 질의에 DISTINCT 가 포함되

어 있을 경우 이를 처리하기 위한 수행 방법을 결정한다.

SET의 수행 방법 결정: 질의에 UNION, UNION ALL,

INTERSECT, MINUS 등이 있을 경우 이를 처리하기 위한

수행 방법을 결정한다.

ORDER BY의 수행 방법 결정: 질의에 ORDER BY가 포함되

어 있을 경우 이를 처리하기 위한 수행 방법을 결정한다.

프로젝션의 수행 방법 결정: SELECT 구문에 포함되어 있는

칼럼 등을 프로젝션하기 위한 수행 방법을 결정한다.

Subquery내에 존재하는 SELECT 구문인 경우 다양한 최적

화 방법들이 사용될 수 있다.

위의 질의 최적화 과정의 순서 대로 각 과정을 보다 상세히 살펴

보고 이를 통해 SQL 튜닝을 위한 방법을 설명한다.

정규화

정규화의 개념 사용자가 작성한 WHERE의 조건절은 매우 다양한 형태로 표현된

다. Optimizer는 다양한 조건 처리를 일관적이고 효율적인 방법

으로 처리하기 위해 사용자가 정의한 WHERE절을 정형화된 형태

로 변경하며 이러한 과정을 정규화라 한다.

정규화는 AND, OR, NOT 등의 논리식을 기준으로 조건절을 확장

하고 변형하는 과정이며, AND를 최상위 논리식으로 표현하는 방

법을 CNF(Conjunctive Normal Form)이라 하며, OR를 최상위 논

리식으로 표현하는 방법을 DNF(Disjunctivie 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)

DNF 정규화는 주어진 조건절을 OR를 최상위로 하여 하위에

AND 논리 연산자로만 재구성되도록 재배치하는 과정이다. 예를

들어, 다음과 같은 조건절은 DNF로 정규화 시 다음과 같은 구조

로 변경된다.

SQL 튜닝 277

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 )

해당 조건절의 경우 인덱스가 없거나 하나의 칼럼에만 인덱스가

있는 경우는 CNF로 처리된다. 즉, T1 테이블을 전체 스캔하여

질의를 처리하는 것이 가장 효율적이다.

그러나, i1과 i2 칼럼에 각각 인덱스가 있는 경우는 DNF로 정규

화하여 각각의 인덱스를 모두 사용하여 (i1 = 1) 의 결과와 (i2 =

1)의 결과를 따로 얻어 합치는 것이 보다 효율적이다.

이와 같이 동일한 조건식이라 하더라도 인덱스의 유무에 따라 다

른 정규화가 선택되며 이는 optimizer의 비용 비교에 의해 결정

된다.

물론, 논리 연산자가 없거나 AND 연산자만 존재하는 경우라면

optimizer는 CNF 정규화만을 사용하게 되며, OR 연산자가 존재

하는 경우에는 CNF와 DNF를 모두 구성하여 비용 비교를 통해

실행 계획을 생성하게 된다.

정규화 튜닝 앞에서 살펴 보았듯이 정규화 과정은 조건절의 확장을 불가피하

게 한다. 따라서, 조건절 기술 시 정규화된 형태로 구성하는 것

은 조건절의 확장을 방지하여 불필요한 비교 연산을 제거할 수

있다.

예를 들어, 다음과 같은 조건절은 CNF 또는 DNF로 수행이 가능

하며, 이는 질의 변경을 통해 CNF로만 동작하게 할 수 있다.

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)



278

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라 한다.

Constant filter는 항상 같은 논리값을 갖기 때문에 질의 수행 과

정에서 한 번만 비교하고 추가적인 비교 연산 비용이 소요되지

않는다. 즉, constant filter의 논리값이 FALSE인 경우에는 어떠

한 검사도 추가적으로 발생하지 않으며, 테이블에 접근할 필요도

없다.

무의미해 보이는 constant filter도 다음과 같이 매우 다양한 용도

로 활용할 수 있다.

그 예로 Schema만 구성하고 데이터는 구축하지 않고 싶은 경우

에 constant filter를 활용할 수 있다. 예를 들어 다음과 같은 질

의가 이에 해당하는 예이다.

SQL 튜닝 279

CREATE TABLE T3 AS

SELECT * FROM T1, T2 WHERE 1 <> 1;

위와 같이 T1과 T2 테이블의 모든 칼럼 정보를 가진 T3 테이블

을 만들고 싶을 경우 constant filter를 사용하면 T1, T2의 데이

터양에 관계 없이 원하는 작업을 수행할 수 있다.

또한, 다음 예와 같이 검색 권한을 제한하는 용도로 활용할 수 있

다.

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 기법이며, 이는 해당 조건을 되도록 먼저 처리되

도록 하여 다른 연산을 수행하기 전에 미리 결과 집합을 줄이는

방법이다.

Push selection의 가장 일반적인 형태는 위에서 기술한 바와 같

이 조건절을 분류하여 해당 테이블에 속하는 조건을 먼저 검사하

도록 하는 것이 대표적인 형태이다.



WHERE T1.i1 = T2.a1 AND T1.i2 = abc;

위의 질의에서 해당 조건절은 다양한 실행 계획의 생성이 가능하

다. 즉, T1, T2를 모두 조합한 후에 조건절을 비교할 수도 있으

며, T1 테이블에 대한 조건을 이용하여 T1의 결과 집합을 줄인

후에 조인을 수행하여 처리할 수 있다. 이와 같이 WHERE절의



280

조건을 가능한 조인이 수행되기 전에 처리하도록 하는 것이 push

selection의 가장 일반적인 형태이다.

Optimizer는 비용 비교 및 수학적 일치성 등을 고려하여 push

selection의 다양한 형태를 고려하게 된다. Optimizer에서 사용

하는 대표적인 push selection은 다음과 같은 기법들이 있다.

뷰에 대한 push selection

Outer 조인에 대한 push selection

조인에 대한 push selection

위 기법들의 개념과 이를 활용한 SQL 튜닝 방법에 대하여 알아

보자.

뷰에 대한 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 칼럼의 인덱스를 최대한

활용할 수 있도록 한다. 그러나, 이러한 push selection이 반드

시 적용되는 것은 아니며 이에 대한 판단은 optimizer에 의해서

결정된다.

사용자가 이러한 조건절의 변경을 통해 적용할 수는 없으나 뷰

내부의 구조를 파악하고 있다면 적절한 조건절의 사용을 통해 뷰

에 대한 push selection기법이 적용되도록 할 수 있다. 또한, 힌

트를 사용하여 optimizer가 명시적으로 해당 기법이 적용되도록

할 수 있다. 이는 힌트에 대한 설명에서 자세히 다룬다.

그러나, 뷰에 대한 push selection이 반드시 원래 질의보다 동등

하거나 나은 성능을 보장하지는 않는다.

뷰에 대한 push selection과 상충되는 최적화 기법이 바로 view

materialization 기법이다. 이는 뷰가 하나의 질의에서 반복해서

SQL 튜닝 281

사용될 때 뷰의 결과를 질의 처리 과정 중에 임시로 저장하여 처

리하는 기법이다.

예를 들어 다음과 같은 뷰의 정의와 관련 질의 예를 살펴 보자


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 T1 LEFT OUTER JOIN T2

ON T1.i1 = T2.a1 AND T1.i1 = 1;

즉, left outer join에 대한 조인 조건을 처리하기 전에 T1.i1 = 1

조건을 미리 처리하여 T1의 결과 집합을 줄이는 방법이다.

이러한 기법 역시 수학적 동치 여부 및 비용 평가를 통해 적용

여부가 결정된다. 예를 들어 다음과 같은 두 질의는 경우에 따라

서로 다른 결과를 생성하며, 동일한 질의가 아니다.

SELECT *

FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1

WHERE T2.a1 = 1;

SELECT *


ON T1.i1 = T2.a1 AND T2.a1 = 1;



282

Optimizer는 수학적 동치인 상태에서 동일한 결과를 얻기 위해서

위의 질의를 다음과 같은 형태로 push selection을 적용한다.

SELECT *


ON T1.i1 = T2.a1 AND T2.a1 = 1

WHERE T2.a1 = 1;

참고로, Left outer join의 경우 WHERE 조건 중 왼쪽 테이블에

대한 조건은 ON 절에 옮겨도 동일한 결과를 보장하는 반면, 오른

쪽 테이블에 대한 조건은 ON절에 기술하더라도 WHERE 절에 반

드시 남겨 두어야 동일한 결과를 보장받을 수 있다.

위의 최적화 기법을 보면, 사용자는 optimizer가 outer join에 대

하여 push selection을 적용하지 않더라도 임의로 질의 조건의

추가를 통해 유사한 효과를 기대할 수 있다. 물론, 조건 추가를

통해 동일한 결과를 얻음과 동시에 성능을 향상시킬 수 있음을

판단하는 것이 매우 중요하다.

조인에 대한 push selection 조인에 대한 push selection 기법은 조인 조건과 단일 테이블 조

건이 존재할 때 유사한 단일 테이블 조건을 추가하여 성능을 향

상시키는 기법이다.



WHERE T1.i1 = T2.a1 AND T1.i1 = 1;

해당 질의를 처리하기 위해 어떠한 인덱스도 사용할 수 없을 경

우 다음과 같이 유사한 단일 테이블 조건을 추가하는 것은 많은

경우에 성능 향상에 도움이 된다.


WHERE T1.i1 = T2.a1 AND T1.i1 = 1 AND T2.a1 = 1;

즉, T2 의 결과 집합의 개수를 줄임으로서 성능을 향상시킬 수

있다. 이러한 조인에 대한 push selection 기법은 특히 집합 연

산을 통해 생성된 뷰에 대하여 처리할 때 매우 효과적이다.

에를 들어 다음과 같은 뷰와 이를 이용한 질의를 살펴 보자.


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 칼럼에 모두 인덱스가 있다

하더라도 해당 질의를 수행하는 데 있어 인덱스가 사용될 수 없

SQL 튜닝 283

다. 이 때 조인에 대한 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 칼럼의 인덱스를 모두 사용할 수 있게 된다.

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



284

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 );

위의 표에서 보는 바와 같이 모든 조건들은 다섯 가지 형태의 처

리 방법에 의해 처리되게 된다.

Key range 처리 방법은 해당 조건을 인덱스를 이용하여 조건에

부합하는 범위 검색에 의해 데이터를 검색하는 방법이다. 즉, 조

건을 만족하는 최소값의 위치와 최대값의 위치만을 결정하고 해

당 조건에 대한 별도의 비교 없이 해당 범위 내의 모든 데이터를

검사하게 된다. 따라서, 조건 비교 시 데이터에 대한 별도의 비

교 연산이 필요 없어 매우 우수한 성능을 보장할 수 있다.

Key filter 처리 방법은 인덱스를 이용하여 범위 검색은 할 수 없

으나, 인덱스에 저장되어 있는 키값을 이용하여 비교 연산을 수행

하는 방법이다. 즉, 인덱스를 저장하고 있는 페이지만을 접근하

여 비교함으로서 데이터 페이지에 대한 접근 횟수를 줄여 성능을

향상시킬 수 있다. 이는 디스크 테이블의 인덱스에 대해서만 유

효하며, 메모리 테이블의 인덱스의 경우 별도로 키값을 저장하지

않고 있어 filter 처리 방법과 비교하여 성능 향상 효과가 없다.

Constant 처리 방법은 앞에서 살펴보았듯이 모든 조건에 우선하

여 한 번만 처리하며, 논리값이 FALSE인 경우 별도의 데이터 검

색이 필요 없다.

Filter 처리 방법은 인덱스를 사용할 수 없는 일반적인 조건에 대

한 비교 방법으로 데이터를 직접 읽어 비교 연산을 수행한다.

Optimizer는 여러 filter에 대하여 처리 예상 비용을 비교하여 가

장 비용이 적은 filter를 우선적으로 처리하여 비교 비용을 최소화

할 수 있도록 filter의 처리 순서를 결정한다.

Subquery filter는 일반적으로 가장 많은 비용이 드는 비교 연산

이며 모든 조건 비교가 완료된 후 마지막에 수행된다.

Optimizer는 이러한 Subquery filter에 대하여 다양한 최적화 기

법을 적용하여 성능 향상을 꾀하며, 이에 대해서는 이후의

Subquery 처리 과정에서 자세히 다룬다.

인덱스 생성 시 고려 사항 주어진 조건절을 처리하기 위한 가장 효율적인 key range 검색을

하기 위해서는 인덱스가 있어야 한다. 그러나, 인덱스를 생성하

기 위해서는 다음과 같은 사항을 반드시 고려하여야 한다.

인덱스의 생성이 검색 연산의 성능을 향상시킬 수는 있으나, 인덱

스를 관리하기 위한 저장 공간이 필요하여 시스템 자원을 소모한

다. 또한, 과도한 인덱스의 생성은 삽입, 삭제, 갱신의 발생시 관

련 인덱스의 정보를 유지하기 위한 비용으로 성능 저하를 유발할

수도 있다.

SQL 튜닝 285

메모리 테이블의 경우 거의 모든 질의 처리에 있어 인덱스를 이

용한 검색 방법이 테이블에 대한 전체 스캔보다 우수한 성능을

보인다. 그러나, 디스크 테이블의 경우 인덱스 스캔이 전체 스캔

보다 반드시 효과적인 것은 아니다. 이는 전체 스캔이 데이터 페

이지를 접근하는 패턴이 일정한 반면, 인덱스 스캔은 그 패턴이

일정하지 않아 경우에 따라 과도한 Disk I/O를 유발할 수 있기

때문이다. 일반적으로 디스크 테이블의 경우 인덱스 스캔을 이용

한 검색이 테이블의 전체 레코드 중 1/10 이하이거나 아주 적은

레코드만을 선택하는 경우에 한해 인덱스를 생성할 것을 권고하

고 있다.

즉, 인덱스를 생성할 경우에는 질의의 사용 빈도, 인덱스 사용으

로 인한 성능 향상 효과, 전체 시스템 자원, 갱신 질의의 성능 저

하 정도를 고려하여야 한다.

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 계산의 개념

즉, access cost와 disk I/O cost를 모두 통합하여 계산하며, 메모

리 테이블의 경우 디스크 페이지가 존재하지 않아 disk I/O cost

는 수식에 의하여 자동적으로 계산되지 않는다.

수식에 대한 자세한 설명은 이 문서의 범위를 벗어나는 내용으로

자세히 기술하지 않으며, 대략적인 개념에 대해서만 설명한다.

Optimizer는 각 인덱스에 대한 비용 계산 시 인덱스를 이용하여

처리할 수 있는 조건을 선택하고 이를 기반으로 비용을 계산한다.

이 때, 비용 계산에 가장 큰 영향을 미치는 것이 인덱스에 관련된

조건의 효율성이다. 이를 조건의 selectivity라 한다.



286

조건의 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 sex = woman AND rank = lieutenant;

위의 질의에서 sex와 rank 칼럼에 모두 인덱스가 있다고 할 때,

optimizer는 비용 계산을 통해 rank 칼럼에 대한 조건을 처리하

기 위한 인덱스를 사용하는 것이 바람직하다고 판단한다.

그러나, (sex = woman) 의 조건을 만족하는 결과 집합이 아주 작

다는 것을 사용자가 알고 있다면 힌트등을 통해 인덱스 선택을

달리하는 것이 바람직하다.

Composite 인덱스의 활용 Optimizer는 composite 인덱스를 사용할 때 조건절을 비교하여

최대한 많은 조건을 key range 검색을 할 수 있도록 선택한다.

이 때 key range 검색을 할 수 있는 조건이 많을수록 보다 나은

성능을 기대할 수 있다.

사용자가 정의된 인덱스에 대하여 조건절을 어떻게 기술하는 가

에 따라 인덱스를 이용한 성능은 매우 차이가 나므로 composite

인덱스의 동작 원리를 이해하는 것은 SQL 튜닝에 매우 큰 도움

이 된다.

예를 들어, 다음과 같은 composite 인덱스가 존재할 때 다양한

조건들이 어떻게 처리되는 지를 살펴보자.

Composite index on T1(i1, i2, i3, i4)

SQL 튜닝 287

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)

부적절한 인덱스: Index on T1(i1, i2)

인덱스와 비교 연산자 인덱스가 존재하고 해당 칼럼에 대한 조건이 존재한다고 해서 반

드시 인덱스를 사용할 수 있는 것은 아니다.

즉, 조건절의 기술 형태와 비교 연산자의 종류에 따라 인덱스의

사용 가능 여부가 결정되므로 이에 대한 주의가 필요하다.



288

비교 연산자의 종류와 인덱스 사용 가능 여부는 다음과 같다.

분류 비교 연산자 가능여부 비고 = O != O < 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 IS NULL O NULL

비교 IS NOT NUL O EXISTS X NOT EXISTS X UNIQUE X

존재 비

교 NOT UNIQUE X =ANY O !=ANY O <ANY O <=ANY O >ANY O

Quantify ANY

>=ANY O =ALL O != ALL O < ALL O <= ALL O > ALL O

Quantify ALL

>= ALL O

SQL 튜닝 289

Geometry 관련 비교 연산자는 다음과 같으며, R-Tree 인덱스가

존재하는 경우에만 인덱스를 사용할 수 있다.

분류 비교 연산자 가능여부 비고 CONTAINS O 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

Geometry 비교

WITHIN O

R-Tree index only

위와 같이 인덱스가 존재하고 인덱스를 사용할 수 있는 비교 연

산자라 하더라도 항상 인덱스를 사용할 수 있는 것은 아니다.

즉, 조건절의 형태에 따라 인덱스의 사용 가능 여부가 결정되며,

인덱스를 사용할 수 있는 조건절의 형태는 다음과 같다. (참조, 조

건절의 예제는 해당 칼럼이 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 = SMALLINT1 T1.i1 = 1.0

위와 같이 인덱스를 사용하기 위해서는 조건절의 기술에 주의를

기울여야 하며, 특히 칼럼의 값이 연산이 필요하거나 변경이 발생

하지 않도록 주의하여야 한다.

인덱스 사용을 고려한 데이터 타입과 데이터 변환에 대한 설명은

다음에서 자세히 설명한다.



290

인덱스와 데이터 타입 WHERE 절의 칼럼에 인덱스가 생성되어 있다고 해서 항상 인덱

스 스캔이 가능한 것은 아니다. 데이터 타입과 데이터 변환에 따

라 인덱스 스캔이 가능한 경우도 있고 그렇지 못한 경우도 있다.

SELECT * FROM T1 WHERE T1.i1 = ?

이 질의에서 i1 칼럼이 VARCHAR 타입이고 PRIMARY KEY인

경우 iSQL로 실행 계획을 확인하면 인덱스 스캔 가능으로 나타나

지만 실제 변수 바인딩 시 INTEGER 등의 숫자형으로 바인딩을

하는 경우 칼럼의 값을 숫자형으로 변환하여 비교해야 하므로 인

덱스 스캔이 불가능해진다.

따라서, iSQL에서 인덱스 스캔으로 수행되는 질의인지 확인하고,

실행 계획이 인덱스 스캔 가능한 것으로 표시되는 경우에도 실제

응용프로그램에서 바인딩하는 값과 칼럼의 데이터 타입을 확인해

야 한다. 그렇지 않으면 응용프로그램에서는 전체 테이블을 스캔

(full scan)하여 iSQL상에서의 실행 속도에 비해 현격한 속도 차

이가 날 수도 있으므로 주의해야 한다.

데이터 타입과 인덱스 사용 가능 여부는 다음과 같으며, 검은 부

분으로 표시되는 부분은 비교연산 수행시, 키 칼럼에 변환이 발생

하게 된다.

VALUE KEY

CH

AR

VA

RCH

AR

SMA

LLIN

T

INTE

GER

BIG

INT

NU

MER

IC

FLO

AT

REA

L

DO

UBL

E

DA

TE

BLO

B

NIB

BLE

BYTE

GEO

MET

RY

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

SQL 튜닝 291

데이터 타입은 다음과 같이 크게 문자형 계열과 숫자형 계열로

구분할 수 있으며, 각 계열에 속하는 데이터 타입들간의 비교는

모두 인덱스를 사용할 수 있다.

문자형 계열

CHAR, VARCHAR

정수형 BIGINT, INTEGER, SMALLINT

Native

실수형 DOUBLE, REAL 고정 소수

점형 NUMERIC, DECIMAL, NUMBER(p), NUMBER(p,s)

숫자형 계열

Non-Native (지수형)

부동 소수

점형 FLOAT, NUMBER

즉, 문자형 계열에 속하는 CHAR, VARCHAR간의 비교,

숫자형 계열에 속하는 정수형, 실수형, 지수형간의 비교시에는 모

두 인덱스 사용가능하다.

예1) 문자형 계열

char_column = VARCHARabc

varchar_column = CHARabc

예2) 숫자형 계열

integer_column = DOUBLE1

number_column = DOUBLE1

integer_column = NUMBER1

숫자형 계열의 서로 다른 데이터 타입간 비교 연산에 대해서는

conversion matrix에 의하여 다음과 같은 기준으로 비교하게 된

다.

정수형 실수형 지수형 정수형 정수형 실수형 지수형 실수형 실수형 실수형 실수형 지수형 지수형 실수형 지수형

인덱스 칼럼에 변환이 존재하는 경우가 이에 해당되며, 인덱스에

변환이 발생하는 경우라 하더라도, 이 비교기준에 의해 내부적으

로 인덱스 칼럼의 변환된 값으로 비교연산을 수행하게 된다.

그러므로, bigint_col = NUMERIC1과 같이 칼럼에 변환이 발생

하는 index scan은 bigint_col = BIGINT1과 같이 칼럼에 변환이

발생하지 않는 index scan보다 수행속도가 느리게 된다.



292

이 외에 인덱스 스캔과 별도로 두 값을 비교하는 비교 연산자의

수행 성능은 비교 대상 데이터 타입의 종류와 밀접한 관계가 있

다. 같은 데이터 타입간의 비교일 경우에는 데이터 변환 비용이

없으므로 최적의 성능을 발휘하겠지만 서로 다른 데이터 타입간

의 비교라면 데이터 변환을 최소화하도록 해야 한다.

예를 들어 숫자형 타입과 문자형 타입을 비교할 경우

데이터 변환 비용만 고려한다면 FLOAT과 VARCHAR인 경우 가

장 짧은 변환 패스를 가진다. 그러나 데이터 타입별로 데이터 저

장 크기와 형식에 차이가 있으므로 이를 종합적으로 고려해 데이

터 타입을 결정해야 한다.

다음은 데이터 타입 변환 패스를 도식화한 그림이다.

SMALLINT

BIGINT

INTEGER

REAL

DOUBLE

NUMERIC FLOAT

INTERVAL

CHAR VARCHAR

DATE

NULL ALL

<G+E+L>

<0+0+0><0+E+L>

<0+E+0><0+0+0>

<0+E+0>

<0+0+L>

<G+0+0>

<0+E+0><0+0+L>

<G+E+0><0+E+L>

<0+E+0>

<0+0+0>

<0+0+0>

<0+E+L>

<G+0+0>

<0+0+0>

<0+0+0>

<0+0+0>

<0+0+L>

<G+0+0><G+0+0>

<G+0+0>

<0+0+L>

<G+0+0>

<G+0+0>

A B A와 C를 비교하는 경우 항상 A가 C로 변환되거나 C가 A로 변환되는 것은 아니다. 연산자에 따라 A가 C로 변할 수도 있고, 그 반대인 경우도 있으며, A가 B로 변환되고 C가 B로 변환되어 연산을 수행하는 경우도 있다.

C

A B A 타입에서 B 타입으로 데이터 타입 변환 가능

G : Group PenaltyE : Error Penalty G >> E >> LL : Loss Penalty

<그림 9-３> 데이터변환 타입 패스

SQL 튜닝 293

위와 같이 인덱스를 사용할 수 있도록 조건절을 기술하는 것은

매우 중요하며, 조건절의 유형에 따라 성능에 영향을 미칠 수 있

으므로 WHERE절의 기술 및 응용 프로그램의 작성 시 주의를 기

울여야 한다.

Optimizer가 개별 테이블에 대한 액세스 방법의 결정이 완료되

면, 조인에 대한 처리를 수행하게 된다. 이 때, 개별 테이블에 대

하여 결정된 액세스 방법은 절대적인 것이 아니며, 조인 처리 과

정에서 재조정하게 된다.

조인 순서의 결정 복잡한 질의의 경우 조인의 순서 및 조인의 처리 방법은 질의 성

능에 가장 큰 영향을 미치게 된다. 따라서, 적절한 조인 순서와

조인 방법이 선택되었는지를 판단하고 조정하는 것은 질의 성능

향상에 도움이 된다.

Optimizer는 조인을 처리하기 위하여 다음과 같은 단계를 따른

다.

조인 조건을 이용한 조인의 그룹화

각 그룹의 조인 관계 표현

각 그룹의 조인 순서 결정

각 조인의 조인 방법 결정

그룹간의 조인 순서 및 조인 방법 결정

이와 같이 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)



294

위의 예에서와 같이 두 그룹은 조인 관계가 전혀 설정되어 있지

않은 테이블이며, 조인 순서를 결정하기 위하여 모든 테이블을 한

꺼번에 고려하여 처리하는 것은 비용만을 증가시킬 수 있다.

일반적인 경우 이러한 분류가 효율적이나 응용 프로그램의 성격

및 데이터 구성에 따라 적합하지 않을 수 있으므로, 이런 경우 조

인 순서 힌트를 통하여 이를 제어할 수 있다.

이와 같이 조인 그룹을 분류한 후 각 조인 그룹에 대하여 다음과

같은 과정을 통하여 조인 순서를 결정하게 된다.

조인 관계의 구성 각 조인 그룹에 대하여 조인 관계를 구성하는 것은 조인 순서 결

정 시 직접적인 조인 관계가 없는 테이블간의 비교 비용을 줄여

보다 효율적인 조인 순서를 결정하기 위함이다.


SELECT * FROM T1, T2, T3, T4

WHERE T1.i1 = T2.a1 AND T2.a2 = T3.m2

AND T3.m3 = T4.x3;

위의 질의에서 조인 관계는 다음과 같이 표현될 수 있다.

T1 T2 T3 T4

죠인 관계

T1.i1 = T2.a1 T2.a2 = T3.m2 T3.m3 = T4.x3

위와 같이 조인 관계를 관리하고 조인 순서의 결정 시 조인 관계

만을 고려하여 비용 평가를 함으로서 (T1, T4)와 같이 직접적인

조인 관계가 없는 테이블간의 조인이 우선적으로 결정되는 것을

방지한다.

조인 관계의 사용이 일반적으로 효율적인 조인 순서를 결정하는

데 도움이 되나, 반드시 올바른 조인 순서를 결정하지는 않는다.

따라서, 필요한 경우 조인 순서 힌트를 사용하여 제어할 수 있다.

죠인 관계의 순서 결정 위에서 생성한 죠인 관계를 이용하여 각 죠인 관계들 중 가장 효

율적인 죠인 관계의 순서를 결정하게 된다.

죠인 관계의 순서를 결정하는 방법은 죠인 관계들 중 죠인

selectivity가 가장 효율적인 죠인 관계를 우선적으로 선택하고,

다시 선택된 관계로부터 관련된 죠인 관계들 중에 효율적인 죠인

관계를 선택해가는 방식으로 결정된다. 이 때, 죠인 관계의 순서

라 함은 실제 죠인 순서가 아니면, 실제 죠인 순서는 죠인 방법의

결정을 통해 완성된다.

SQL 튜닝 295

T1

JOIN

T2

T3

JOIN

JOIN

T4

죠인 관계의 순서

T1

JOIN

T2

T3

JOIN

JOIN

T4

죠인 방법 결정 후의 실제 죠인 순서

<그림 9-４> 죠인 관계의 순서 결정

위의 그림에서 보듯이 이 과정에서의 죠인 관계의 순서는 죠인

관계의 깊이만을 결정할 뿐 실제 죠인 순서는 죠인 방법 선택에

의하여 결정된다.

죠인 관계 순서의 가장 중요한 요소는 죠인 selectivity이며, 두

테이블의 조합을 통해 생성되는 결과 집합의 비율을 의미한다.

즉, 죠인 관계의 순서 결정 시 죠인을 통한 결과 집합의 크기의

대소를 비교하기 보다는 얼마나 많이 줄어드는 가를 기준으로 판

단하게 된다.

Optimizer가 죠인 selecitivty 계산을 위한 개략적인 개념은 다음

과 같다. 아래 수식에 대한 설명은 이 문서의 범위를 벗어나므로

자세히 기술하지 않는다.

[T(R) * T(S) / MAX[V(R.a), V(S.a)]/ [T(R) + T(S)]

Join selectivity 계산의 개념

이와 같은 죠인 selectivity를 이용한 죠인 관계 순서의 결정은

보다 효율적인 비율로 결과 집합을 줄일 수 있는 죠인 관계를 우

선적으로 선택하게 되며 추후 죠인 방법 결정에 의하여 비교적

정확한 죠인 순서를 결정할 수 있다.

예를 들어, 하나의 질의에 포함된 각 테이블의 레코드 개수와 죠

인으로 생성되는 결과의 개수가 다음과 같을 때를 살펴 보자.

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의 관계가 더 중요한 죠인 관계가 된

다.



296

Optimizer가 죠인 관계를 이용하여 생성한 죠인 순서가 모든 경

우에 있어 항상 바람직함을 보장할 수는 없으며, 이를 위해 죠인

순서 힌트를 사용하여 죠인 순서를 제어할 수 있다.

죠인 관계의 순서를 결정한 후에는 두 테이블간의 죠인 방법을

결정하게 되고 최종적으로 죠인 순서가 결정된다.

죠인 방법의 결정 죠인 관계의 순서가 결정되면, 두 테이블의 각 죠인 관계에 대하

여 죠인 방법을 결정하게 된다. 이 때, 다양한 죠인 방법의 비용

비교를 통해 죠인의 순서 및 방향, 죠인 방법을 결정하게 된다.

알티베이스의 죠인 방법은 다음과 같이 크게 네 가지의 계열로

분류할 수 있다.

Nested loop 죠인 계열

Sort 죠인 계열

Hash 죠인 계열

Merge 죠인 계열

각 죠인 방법 및 실행 가능 여부는 다음과 같다.

죠인 방향 죠인 계열 죠인 방법

Left=>Right Right=>Left 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 Nested Loop

Anti outer nested loop F F One pass sort join I, L, F I, R, F Sort-based Multi pass sort join I, L, F I, R, F One pass hash join I, L, F I, R, F Hash-based Multi pass hash join I, L, F I, R, F Index merge join I I Merge-based 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 죠인 관계를 갖는 두 테이블의 죠인

Optimizer는 위와 같은 다양한 죠인 방법들 중 적용 가능한 죠인

방법에 대하여 비용 평가를 통해 가장 효과적인 죠인 방법을 선

택하고 죠인의 방향을 결정하게 된다. 죠인 방법이 결정되면 기

준 테이블은 왼쪽에 위치하고 반복 테이블은 오른쪽에 위치하게

된다.

SQL 튜닝 297

실행 계획 트리의 분석을 통해 어떠한 죠인 방법이 선택되었는

지를 판단이 가능하며, 힌트를 사용하여 제어할 수 있다. 이에

대한 내용은 실행 계획 분석과 힌트에 대한 설명에서 자세히 다

루며 여기서는 각 죠인 계열의 죠인 방법에 대한 내용을 살펴 본

다.

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은 반복 테이블에 대하여 죠인 조건을 별도

로 처리하지 않고 모든 조합에 대하여 구성하면서 죠인 조건을

비교하는 방법이다. 모든 죠인 유형에 대하여 처리가 가능하며,

일반적으로 죠인 관계가 존재하지 않는 cartecian product에 의

하여 사용될 가능성이 높다.

SELECT * FROM T1, T2;

Full store nested loop join은 반복 테이블의 결과를 저장한 후

full nested loop join을 적용하는 방법이다. 죠인 조건 이외의 조

건 처리에 의하여 결과 집합이 매우 줄어드는 경우 적용될 가능

성이 높으며, 일반적으로 죠인 그룹간의 Cartesian product에 의

하여 사용될 가능성이 높다.


WHERE T1.i1 = 1 AND T2.i1 = 1;

Index nested loop join은 인덱스를 이용하여 죠인 조건을 처리하

는 방법이다. 기준 테이블의 레코드 수가 적고 반복 테이블에 인

덱스가 존재하는 경우에 사용될 가능성이 높다.

Index on T2(i1)


WHERE T1.i1 = T2.i1 AND T1.i1 = 1;

Anti outer nested loop join 은 FULL OUTER JOIN에서만 사용

되며, 죠인 조건에 해당하는 칼럼에 대하여 기준 테이블과 반복

테이블이 모두 인덱스를 사용할 수 있을 때 사용 가능하며 이 경

우 다른 죠인 방법에 비해 선택될 가능성이 높다.

Index on T1(i1), Index on T2(i1)

SELELCT * FROM

T1 FULL OUTER JOIN T2 ON T1.i1 = T2.i1;



298

각 죠인 방법들의 비용 계산 방법의 개략적인 개념은 다음과 같

다.


Disk I/O cost 죠인 방법 Access 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

Sort-based 죠인 계열 죠인 방법 중 sort-based 죠인 계열에는 다음과 같은 것들이 있

다.

One-pass sort-based join

Multi-pass sort-based join

Sort-based 죠인 방법은 반복 테이블을 정렬된 순서로 저장하고

죠인 조건을 이용하여 범위 검색을 하는 방법이다. 일반적으로

인덱스가 없고 부등호 죠인 조건을 처리할 때 선택될 가능성이

높다.

SELECT * FROM T1, T2 WHERE T1.i1 > T2.i1;

One-pass sort-based 죠인은 반복 테이블의 데이터 양이 적어

버퍼 내에서 관리가 가능할 때 사용되며, 메모리 테이블이 반복

테이블로 사용될 경우는 모두 one-pass 죠인을 사용하게 된다.

Multi-pass sort-based 죠인은 반복 테이블의 데이터 양이 방대

하여 버퍼의 범위 내에서 관리할 수 없을 때 사용하며 Disk I/O

를 줄이기 위한 방법이다. 기준 테이블과 반복 테이블을 모두 정

렬하여 저장하며, 기준 테이블의 데이터 정렬 순서로 죠인 조건을

검사하게 되어 반복 테이블의 동일한 디스크 페이지 접근 확률을

높이게 된다.


다.


Disk I/O cost 죠인 방법 Access Cost No Buffer Miss Buffer Miss

SQL 튜닝 299

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: 기준 테이블, R: 반복 테이블 T(): 레코드 개수, B(): 디스크 페이지 개수, S(): 정렬 저장 비용, M: 버퍼 페이지, s: 죠인 조건의 selectivity

Hash-based 죠인 계열 죠인 방법 중 hash-based 죠인 계열에는 다음과 같은 것들이 있

다.

One-pass hash-based join

Multi-pass hash-based join

Hash-based 죠인 방법은 반복 테이블을 hashing 구조로 저장하

고 죠인 조건을 이용하여 범위 검색을 하는 방법이다. 등호 죠인

조건만을 처리할 수 있으며 인덱스가 없을 때 선택될 가능성이

높다.

SELECT * FROM T1, T2 WHERE T1.i1 = T2.i1;

One-pass hash-based 죠인은 반복 테이블의 데이터 양이 적어

버퍼 내에서 관리가 가능할 때 사용되며, 메모리 테이블이 반복

테이블로 사용될 경우는 모두 one-pass 죠인을 사용하게 된다.

Multi-pass hash-based 죠인은 반복 테이블의 데이터 양이 방대

하여 버퍼의 범위 내에서 관리할 수 없을 때 사용하며 Disk I/O

를 줄이기 위한 방법이다. 기준 테이블과 반복 테이블을 모두 동

일 hash 함수로 분할하여 여러 임시 테이블에 저장하며, 하나의

임시 테이블끼리 죠인 조건을 검사하게 되어 반복 테이블의 동일

한 디스크 페이지 접근 확률을 높이게 된다.


다.


Disk I/O cost 죠인 방법 Access 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: 기준 테이블, R: 반복 테이블 T(): 레코드 개수, B(): 디스크 페이지 개수, H(): 해싱 저장 비용, M: 버퍼 페이지, s: 죠인 조건의 selectivity



300

Merge 죠인 계열 Merge 죠인은 두 테이블의 데이터가 정렬되어 있을 경우 매우

효율적인 죠인 방법이다. 기준 테이블과 반복 테이블의 개념이

없으며 양쪽 테이블을 순차적으로 진행해 가면서 죠인 조건을 검

사하는 죠인 방법이다.

양쪽 테이블이 모두 정렬되어 있어야 하며, 정렬 여부에 따라 다

음과 같이 구분할 수 있다.

Index merge join

Sort merge join

즉, 각각의 테이블이 인덱스를 통해 정렬되어 있다면 인덱스를 사

용하고 인덱스가 없다면 죠인 조건에 부합하는 정렬을 수행한 후

정렬 순서대로 죠인 조건을 비교하며, 데이터의 대소 비교에 따라

검색할 다음 레코드를 결정한다. Merge 죠인은 양쪽 모두 인덱

스를 사용할 수 있고 단일 테이블의 결과 집합을 줄일 수 없을

때 사용될 가능성이 높다.

Index on T1(i1), Index on T2(a1)

SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1;

Merge 죠인의 비용 계산 방법의 개략적인 개념은 다음과 같다.


Disk I/O cost 테이블의 유형

Access 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(): 정렬 저장 비용

지금까지 질의 성능에 가장 큰 영향을 미치는 FROM과 WHERE

절을 의미하는 critical path의 최적화 과정에 대하여 살펴보았다.

이후의 최적화 과정은 non-critical path에 대한 최적화 과정으로

각 구문의 형태에 따라 구분하여 설명한다.

그룹 연산의 최적화 Optimzers는 critical path에 대한 최적화 과정후에는 non-

critical path에 대한 최적화 과정이 이루어지고, GROUP BY,

HAVING, aggregation 연산 등의 그룹 연산에 대한 최적화를 수

행한다.

SQL 튜닝 301

그룹 연산의 최적화는 기본적으로 hashing 방식과 sorting 방식

에 대한 비용 계산을 통해 실행 방법을 결정하며, 아래와 같은 최

적화 기법들이 적용 가능한 경우 이를 적용한다.

정렬 순서를 이용한 GROUP BY

정렬 순서를 이용한 MIN, MAX

MIN, MAX내의 DISTINCT 제거

정렬 순서를 이용한 DISTINCT aggregation

정렬 순서를 이용한 GROUP BY GROUP BY 에 기술된 칼럼별로 그룹을 구분하기 위해서는 기본

적으로 hashing 또는 sorting을 필요로 한다. 이러한 연산은 내

부적으로 많은 저장 공간과 높은 CPU 사용을 필요로 한다.

Optimizer는 GROUP BY를 처리하기 위한 인덱스가 존재하거나

critical path 최적화 과정에서 해당 칼럼의 순서가 보장될 경우

이를 사용할 수 있으며, 이를 정렬 순서를 이용한 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;

다음과 같은 예를 통해 indexable 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 처리 과정

에서 IDX1 또는 IDX2 를 사용할 수 있다. IDX1 을 사용한다면

GROUP BY를 처리하기 위해 hashing 및 sorting이 필요한 반면,

IDX2를 사용할 경우 별도의 저장 없이 처리할 수 있다.

사용자가 실행 계획 트리를 분석하여 IDX1을 사용하고 있음을

확인했다면, 힌트를 통해 IDX2를 강제적으로 사용하게 할 수 있

다.



302

유사한 개념으로 다음 질의 수행 시 해당 테이블에 인덱스가 없

는 경우를 고려해 보자

SELECT * FROM T1 WHERE i3 > 0

GROUP BY i1, i3;

위의 경우 WHERE절과 GROUP BY절을 모두 고려해서 T1(i3,i1)

칼럼에 Composite 인덱스를 생성할 경우 질의 성능 향상을 할

수 있다. GROUP BY의 경우 칼럼의 순서가 중요하지 않기 때문

에 WHERE 절을 잘 고려하여 인덱스를 생성하는 것이 중요하다.

즉, GROUP BY i1, i3 와 GROUP BY i3, i1 구문은 결과 집합의

레코드 순서만 다를 뿐 결과 집합은 동일하기 때문이다.

정렬 순서를 이용한 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;

정렬 순서를 이용한 MIN, MAX 최적화의 특성을 잘 알고 있다면,

별도의 질의로 분리하여 처리하거나 다음과 같이 질의를 처리하

는 것도 성능 향상의 방법이 될 수 있다.

SELECT MIN(i1) FROM T1

UNION ALL

SELECT MAX(i1) FROM T1;

MIN, MAX내의 DISTINCT 제거 다음과 같은 질의는 DISTINCT를 사용하지 않는 질의와 수학적

으로 완전 동치이다.

SELECT MIN(DISTINCT i2) FROM T1 GROUP BY i1;

SELECT MIN(i2) FROM T1 GROUP BY i1;

SQL 튜닝 303

물론 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 에 기술된 칼럼은 인덱스의 칼럼 순서대로 기술될 필

요는 없으나, 인덱스의 키 칼럼 순서로 모두 접근 가능해야 한다.

즉, 다음과 같은 질의는 해당 인덱스를 사용할 수 없다.

SELECT DISTINCT i1, i3 FROM T1;

이러한 특징을 잘 이해하고 있다면 다음과 같은 질의는 질의 변

경을 통해 정렬 순서를 이용한 DISTINCT 최적화를 사용할 수

있다.



304

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을 사용하는 것이 바람직하다.

ORDER BY 의 최적화

SQL 튜닝 305

ORDER BY 구문은 sorting을 필요로 하는 구문이다.

Optimizer는 다음과 같은 최적화 기법을 적용할 수 있는 지의 여

부를 검사하여 실행 계획을 결정한다.

정렬 순서를 이용한 ORDER BY

LIMIT sorting

정렬 순서를 이용한 ORDER BY Optimizer는 인덱스를 사용할 수 있거나 하위의 최적화 과정에서

ORDER BY 칼럼의 정렬 순서가 보장된다면 별도의 sorting없이

처리할 수 있다.

예를 들어 다음과 같은 질의는 별도의 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;

GROUP BY나 DISTINCT와 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 sorting LIMIT 구문은 질의 결과의 전체 집합 중에서 일부만을 결과 집

합으로 구성하는 구문이다. 아래 질의는 T1 테이블의 전체 레코

드 중 5개의 결과만을 생성한다.

SELECT * FROM T1 LIMIT 5;

Optimizer는 ORDER BY구문과 LIMIT 구문이 함께 사용되면,

LIMIT sorting 최적화를 수행한다. 이는 sorting을 위해 전체 데



306

이터를 위한 공간을 사용하지 않고 LIMIT 구문에 기술된 공간만

큼을 사용하여 정렬을 수행하는 방법이다.

예를 들어, 다음과 같은 질의는 정렬시 다섯 개의 레코드 공간만

을 이용하여 정렬을 수행한다.

SELECT * FROM T1 ORDER BY i1 LIMIT 5;

따라서, 전체 데이터에 대한 정렬 결과가 필요하지 않는 경우라면

LIMIT 구문을 이용하여 자원 효율 및 성능 향상을 기대할 수 있

다.

프로젝션의 최적화 프로젝션은 전체 칼럼 정보로부터 SELECT 구문에 기술된 일부

칼럼 및 연산 결과를 추출하는 과정이다.

연산 순서의 고려 다음과 같이 항상 일정한 결과를 내는 연산은 한 번만 수행하고

다음 수행 시에는 이전의 결과를 사용한다.

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;

SQL 튜닝 307

질의 2: WHERE i1 > 100 / 3;

질의 3: WHERE i1 > 33;

질의 2와 같이 변경할 경우 100/3 은 실수형 값이 되어 칼럼 i1

에 대하여 인덱스를 사용할 수 없다. 그러나, 질의 3과 같이 변

경할 경우 수학적 동치는 아니지만 i1이 INTEGER이므로 동일한

결과를 얻을 수 있으며 인덱스도 사용할 수 있다.

이와 같이 연산 순서와 데이터 타입을 잘 고려할 경우 동일한 질

의 결과를 얻으면서 성능 향상을 기대할 수 있다.

프로젝션에 대한 최적화는 대부분 Subquery내에 존재하는

SELECT 구문에 대한 최적화이며 이는 다음 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 등의 SELECT 칼럼 제거



308

Eliminate Quantify Rule

Transform NJ

Invariant Area

Store And Search

Subquery Key Range

Subquery의 유형 Optimizer의 subquery 최적화 기법을 설명하기 전에 subquery

의 유형에 대하여 살펴 보자. Subquery의 유형에 따라 적용할

수 있는 최적화 기법이 다르므로 이를 이해하는 것은 매우 중요

하다.

Subquery는 외부 칼럼의 참조 여부, 그룹 연산의 존재 여부에 따

라 다음과 같이 4 가지로 분류한다. 여기서 그룹 연산의 존재는

GROUP BY, HAVING, aggregation 연산 중 하나라도 존재하는

경우를 의미한다.

외부 칼럼 비참조 외부 칼럼 참조 그룹 비존재 Type N Type J 그룹 존재 Type A Type JA

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는 외부 칼럼을 참조

하므로 외부 칼럼의 변경에 따라 항상 새로 실행하여야 한다.

SQL 튜닝 309

즉, subquery에 외부 칼럼을 사용하지 않고 질의를 작성할 수 있

다면 보다 나은 성능을 기대할 수 있다.

위와 같은 subquery의 유형에 따라 관련 최적화 기법을 적용할

수 있는 지의 여부가 결정된다.

EXISTS, UNIQUE의 SELECT 칼럼 제거 EXISTS, UNIQUE등의 subquery는 많은 경우에 있어 SELECT

절에 기술된 칼럼이 의미가 없다.

Optimizer는 subquery에 대한 최적화 과정에서 이를 다음과 같

은 의미로 제거한다.

SELECT * FROM T1

WHERE EXISTS ( SELECT a1, a2 * 1, a3 + a4

FROM T2 );

SELECT * FROM T1

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 Quantify Rule Subquery에 ANY, ALL과 같은 quantify와 부등호 연산자가 사용

될 경우 다음과 같이 quantify를 제거할 수 있다. 위와 같은 최

적화 기법을 eliminate quantify rule이라 한다.

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 );



310

위와 같은 최적화 기법은 MIN, MAX등의 하나의 값에 대해서만

검사하기 때문에 전체 레코드를 비교하는 것보다 많은 성능 향상

을 기대할 수 있다. 또한, 이와 같은 질의 변경은 앞에서 언급한

정렬 순서를 이용한 MIN, MAX 최적화 등에 의하여 인덱스를 사

용하여 성능을 향상시킬 수 있다.

그러나, 이러한 질의 변경도 T2의 레코드가 존재하지 않는 경우

다른 결과를 생성하는 경우가 존재할 수 있어, optimizer가 반드

시 동일한 방식으로 질의를 변경하지는 않는다. 이는 type A,

type J 에 대해서만 가능하며, optimizer는 비용 비교를 통해 해

당 최적화 기법의 적용 여부를 결정하게 된다.

따라서, 사용자가 위와 같은 최적화 기법을 이해하고 해당 질의가

동일한 결과를 얻을 수 있음이 보장된다면, optimizer에 그 판단

을 맡기지 않고 명시적으로 질의를 변경하는 것도 좋은 방법이다.

Transform NJ Transform NJ 기법은 type N 또는 type J의 subquery를 type J

형으로 변경시키는 방법이다.

다음 예를 통해 해당 기법을 살펴보자.

SELECT * FROM T1

WHERE i1 IN ( SELECT a1 FROM T2 );

SELECT * FROM T1


WHERE T2.a1 = T1.i1 );

위의 예에서, 원 질의는 type N 형의 subquery로 외부 칼럼을

참조하지 않고 있으나, transform NJ 기법에 의하여 외부 칼럼을

참조하도록 질의를 변경하는 것이다.

마찬가지로, type J 형의 subquery를 type J형의 질의로 변경하는

예는 다음과 같다.

SELECT * FROM T1


WHERE T2.a2 = 1 );

SELECT * FROM T1


WHERE T2.a1 = 1

AND T2.a1 = T1.i1 );

이러한 최적화 기법은 T2.a1 칼럼의 인덱스를 사용하여 성능을

향상시키려 하는 방법이다. 해당 최적화 기법은 T2.a1 칼럼과

T1.i1 칼럼이 NULL이 아님이 보장될 때 동일한 결과를 생성할

수 있으며, optimizer는 이러한 제약 조건들과 함께 비용 평가를

통해 해당 기법의 적용 여부를 결정한다.

일반적으로 해당 최적화 기법은 외부 질의의 데이터보다

subquery내의 데이터가 많은 경우에 효율적인 기법이며, 사용자

SQL 튜닝 311

는 위와 같은 질의 변경이 동일한 결과를 보장할 수 있음을 확신

할 경우 명시적으로 질의를 변경하여 성능 향상을 기대할 수 있

다.

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 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 Keyrange



312

Store and search 와 동일한 최적화 기법을 적용할 수 있는 환경

에서 i1 칼럼에 인덱스가 존재할 경우에는 저장된 결과를 이용하

여 인덱스를 사용할 수 있다. 이를 subquery keyrange 최적화

기법이라 한다.

SELECT * FROM T1

WHERE i1 IN ( SELECT SUM(a2)

FROM T2

GROUP BY a1 );

Subquery keyrange 최적화 기법이 반드시 효율적인 것은 아니

며, Type N의 경우 다음과 같은 점을 고려할 수 있다.

SELECT * FROM T1


T1.i1 칼럼을 인덱스를 사용하는 경우와 앞에서 설명한

transform NJ 기법을 사용하여 T2.a1 칼럼의 인덱스를 사용하는

것은 데이터 구성에 따라 서로 다른 성능을 낼 수 있다.

일반적으로 외부 질의의 데이터가 많은 경우는 subquery

keyrange를 사용하는 것이 효율적이며, subquery의 데이터가 많

은 경우는 transform NJ 기법을 사용하는 것이 효율적이다.

즉, 많은 데이터를 가진 질의 영역에서 인덱스를 사용하는 것이

보다 효율적일 가능성이 높다. 일반적으로 optimizer가 비용 계

산에 의하여 이를 처리하지만, 사용자가 명시적으로 질의를 변경

하여 성능을 향상시킬 수도 있다.

즉, 다음 질의를 사용자가 원하는 최적화 기법을 적용할 수 있도

록 변경할 수 있다.

SELECT * FROM T1


Subquery keyrange 최적화 기법을 적용하고 싶은 경우

SELECT * FROM T1

WHERE i1 IN ( SELECT DISTINCT a1 FROM T2 );

Transform NJ 최적화 기법을 적용하고 싶은 경우

SELECT * FROM T1



이러한 질의 변경이 optimizer가 해당 최적화 기법을 사용하는

데 도움을 줄 수는 있으나 반드시 적용되는 것은 아니며, 질의

변경 시 반드시 동일한 결과를 보장할 수 있음을 확신하는 것이

중요하다.

죠인 질의로 변경 IN또는 EXISTS 등의 subquery는 특정 상황에 있어 죠인으로 변

경할 수 있으므로 질의 변경을 통한 성능 향상이 가능하다. 그러

SQL 튜닝 313

나, 죠인으로의 질의 변경으로 반드시 성능 향상이 되거나, 항상

동일한 결과를 보장하는 것이 아니므로 주의하여야 한다.

예를 들어, 다음과 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 질의도 T2.a1 이 UNIQUE한 경우에

한해 아래와 같이 죠인 형태로 변경이 가능하다.

SELECT * FROM T1

WHERE EXISTS ( SELECT * FROM T2


SELECT T1.* FROM T1, T2

WHERE T1.i1 = T2.a1;

지금까지 최적화 과정에 대한 설명과 최적화를 위한 질의 튜닝

방법등에 살펴보았다. 해당 질의가 적용된 최적화 기법들은 앞으

로 설명할 실행 계획 분석 단계의 내용을 통해 판단할 수 있다.



314

실행 계획 분석 SQL 튜닝을 위해서는 1차적으로 실행 계획(plan tree)을 분석하

는 것이 필수적이다. 여기서는 실행 계획 트리 정보를 추출하고

이를 해석하는 방법과 실행 계획 트리를 구성하는 각 실행 노드

들의 정보를 분석하는 방법을 설명한다.

실행 계획 분석 방법

실행 계획 분석을 위한 SQL 구문 실행 계획 트리는 iSQL을 통해 분석이 가능하다. 실행 계획 트

리는 SELECT 구문에 대해서만 검색이 가능하며, 이를 위해서는

SELECT 구문의 수행 전에 다음 명령을 수행하여야 한다.

ALTER SESSION SET EXPLAIN PLAN = option;

여기서 option은 ON, OFF, ONLY의 세 가지 설정이 있으며, 기

본 설정값은 OFF이다.

ON: SELECT 문 실행 후 결과 레코드와 함께 Execution

Plan 정보를 보여준다.

ONLY: SELECT 문에 대해 Prepare 과정만 수행한 후

Execution 과정을 수행하지 않고 단지 실행 계획 정보만 보

여준다. 주 언어 변수 바인딩이 존재하는 SELECT 문 또는

실행 수행 시간이 오래 걸리는 질의에 대해 단순히 실행 계

획만 확인할 경우 이 기능을 사용한다.

OFF: SELECT문 실행 후 결과 레코드만 보여준다.

사용자가 기술한 WHERE절에 존재하는 조건들의 처리 방법에 대

한 정보 등의 보다 자세한 정보가 필요한 경우는 다음 명령을 사

용한다.

ALTER SYSTEM SET

TRCLOG_DETAIL_PREDICATE = 1;

위의 구문처럼 해당 프로퍼티를 1을 설정하여 ON시키면 실행 계

획 정보에 WHERE절의 조건들이 FIXED KEY RANGE,

VARIABLE KEY RANGE, FILTER 등으로 자세하게 분류되어 표

시된다. 따라서 WHERE절을 복잡하게 사용한 경우 어떤 술어들

이 인덱스 스캔을 통해 수행되는지 확인할 수 있다. 단, 특정 최

적화 기법에 의해 질의가 변경된 경우는 이러한 정보가 출력되지

않을 수 있다.

다음은 해당 SQL문을 사용한 출력 예이다.

iSQL> alter system set trclog_detail_predicate = 1;

Alter success.

SQL 튜닝 315

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을 설정하고 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을 설정하지 않고 EXPLAIN PLAN =

ON으로 한 경우]


SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 )

[TRCLOG_DETAIL_PREDICATE을 설정하지 않고 EXPLAIN PLAN =

ONLY로 한 경우]


SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: ??, SELF_ID: 2 )

EXPLAN PLAN = ONLY인 경우 질의 실행 없이 실행 계획만 생성하므

로 ACCESS 항목과 같이 실제 실행 후 그 값이 결정되는 항목들은 ??로

표시된다.

실행 계획 트리의 해석 각 실행 노드들이 트리 형태로 연결된 전체 실행 계획 트리에 따

라 어떤 순서로 실행되는지에 대해 예제를 들어 실행 계획을 해

석하는 방법을 간략히 설명한다.

예제

SELECT * FROM T1, T2, T3WHERE 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 )

최상위 노드

최하위 노드

실행 계획 트리에서 하나의 노드는 한 행에 표시되고 왼쪽으로

들여쓰기가 많이 되어 있는 노드일수록 하위 노드에 해당하며 가

장 먼저 수행된다.



316

위 예제에서 가장 최상위 노드는 PROJ 노드이며 최하위 노드는

T1 SCAN 노드와 T2 SCAN 노드이다.

T1 SCAN 노드와 T2 SCAN 노드와 같이 같은 크기만큼 들여쓰

기가 되어 있는 노드들은 먼저 나타나는 노드가 상위 노드의 왼

쪽 노드에 해당한다.

질의 처리기에서 최상위 노드에 질의의 수행을 요구하면 해당 노

드는 자신의 하위 노드에게 조건에 맞는 레코드를 요구하고 하위

노드는 조건에 맞는 레코드를 찾아 자신이 수행해야 할 작업을

수행한 후 상위 노드에게 레코드를 패치해 준다. 그러면 상위 노

드는 그 레코드를 받아 하위 노드가 했던 방법과 같은 방법을 반

복한다.

즉, 레코드 패치 요구는 TOP-DOWN으로 이루어지고 처리한 레

코드의 이동은 BOTTOM-UP 방식으로 이루어진다.

위의 예제에서 가장 먼저 데이터베이스에 접근하는 노드는 T1

SCAN 노드이고, 그 다음 T2 SCAN 노드, T3 SCAN 노드의 순서

로 수행되며, 노드 옆에 명시한 숫자가 노드 수행 순서이다.

위의 예제에서 나타난 실행 계획을 트리 형태로 나타내면 다음과

같다.

SCANT3

JOIN

PROJ

SCANT1

SCANT2

JOINT1, T2

2

6

3

5

4

1

레코드 이동 경로

레코드 패치요구 경로

<그림 9-５> 레코드 패치 경로

SQL 튜닝 317

실행 노드의 종류 실행 계획 트리는 다양한 실행 노드들로 구성된다. 실행 노드는

물리 연산자(physical operator)라고도 한다. 실행 노드는 질의

를 직접 수행하는 연산자들로 앞에서 설명한 바와 같이 실행 계

획 트리를 통해 연산이 수행되는 흐름을 판단할 수 있다.

실행 노드는 자식 노드의 개수와 중간 결과의 저장 여부에 따라

다음과 같이 구분한다.

단일 비저장 노드(Unary Non-materialization Node): 하나

이하의 자식 노드를 가지며, 중간 결과를 저장하지 않음

단일 저장 노드(Unary Materialization Node) :

하나 이하의 자식 노드를 가지며, 중간 결과를 저장함.

이진 비저장 노드(Binary Non-materialization Node) :

두 개의 자식 노드를 가지며, 중간 결과를 저장하지 않음.

이진 저장 노드(Binary Materialization Node) :

두 개의 자식 노드를 가지며, 중간 결과를 저장함.

알티베이스의 실행 노드는 이러한 구분에 따라 다음과 같은 25가

지의 물리 연산자가 존재한다.

구분 약자 출력 이름 기능 SCAN SCAN 테이블에 대한 조건 검색 FILT FILTER 테이블 이외의 조건 검색 PROJ PROJECT 결과에 대한 프로젝션 GRBY GROUPING 그룹 구분 AGGR AGGREGATION Aggregation 연산 수행 VIEW VIEW 뷰 레코드 구성 VSCN VIEW-SCAN 임시 저장 뷰에 대한 검색 CUNT COUNT 특수 COUNT(*)의 처리

단일 비저장 노드

HIER HIER 계층 질의의 처리 SORT SORT 레코드의 정렬 HASH HASH 레코드의 해싱

GRAG GROUP-AGGREGATION

해싱 방식에 의한 그룹 구분과 aggregation 연산 수행

HSDS DISTINCT 해싱 방식에 의한 중복 제거 VMTR MATERIALIZATION 임시 저장 뷰의 관리 STOR STORE 레코드의 저장

단일 저장 노드

LMST LIMIT-SORT 제한된 공간에서의 레코드 정렬 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 자식 노드의 결과 조합



318

BUNI BAG-UNION BAG UNION의 흐름 관리 SITS SET-INTERSECT SET INTERSECT 집합 연산 이진

저장 노드 SDIF SET-DIFFERENCE SET DIFFERENCE 집합 연산

각 실행 노드의 약자는 이후의 설명 과정에서 실행 계획 트리의

흐름도를 표현하는 데 사용하며, 각 실행 노드에 대한 기능과 자

세한 설명은 이후에 자세히 기술한다.

저장 노드의 특징 저장 노드들은 관련 연산을 수행하기 위하여 중간 결과를 저장하

는 노드이다. 중간 결과를 저장하기 위하여 임시 테이블을 사용

하며, 저장 매체의 종류에 따라 메모리 임시 테이블 또는 디스크

임시 테이블을 사용한다.

메모리 임시 테이블은 시스템 커널로부터 직접 할당 받은 메모리

영역을 저장 공간으로 사용하며, 질의 수행 후에 바로 제거된다.

디스크 임시 테이블은 사용자에게 지정된 임시 테이블스페이스

영역을 저장 공간으로 사용하며, 메모리 버퍼를 이용하여 데이터

에 대한 관리가 이루어진다. 이 또한 질의 수행 후에 바로 제거

된다.

메모리 임시 테이블 또는 디스크 임시 테이블을 사용하게 되는

기준은 다음과 같다. 저장 노드의 하위 자식 노드들이 메모리 테

이블만을 사용하는 경우라면 메모리 임시 테이블을 사용하게 되

며, 디스크 테이블이 하나 이상 포함되어 있는 경우에는 디스크

임시 테이블을 사용한다. 이러한 기준은 힌트를 이용하여 조정할

수 있다.

다음 예와 같이 메모리 테이블이 사용된 경우의 정렬과 디스크

테이블의 정렬을 위한 실행 계획을 살펴 보면 그 차이를 확인할

수 있다.

아래의 질의는 메모리 테이블에 대하여 중복 제거 및 정렬을 위

하여 중간 결과를 저장하는 두 개의 저장 노드를 가지고 있다.

메모리 임시 테이블을 사용하는 경우 디스크 페이지에 대한 정보

를 별도로 갖지 않는다.

SQL 튜닝 319

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에 해당하는 실행 노드의 레코드

가 변경될 경우 저장 노드는 임시 저장 테이블을 재구성하게 된

다. 위의 예에서는 모두 자식 노드들을 참조하고 있어 별도의 재

구성이 발생하지 않는 것을 알 수 있다.



320

단일 비저장 노드 단일 비저장 노드는 하나 이하의 자식 노드를 가지며, 해당 기능

을 수행하기 위해 별도의 저장 공간을 필요로 하지 않고 하나의

레코드만을 관리하는 노드이다.

위와 같은 특징을 갖는 각 실행 노드의 기능과, 실행 계획 에서의

분석 방법에 대하여 살펴본다.

SCAN 실행 노드 SCAN 실행 노드는 관계형 모델에서 검색(selection)연산을 수행

하는 물리 연산자이다. 자식 노드를 갖지 않으며 테이블에 직접

접근하여 해당 테이블에 관련된 조건을 검사한다.

SCAN 노드에서 검사되는 조건은 다음과 같이 5가지의 처리 방

법으로 처리된다.

Fixed key range

Variable key range

Constant filter

Filter

Subquery filter

EXPLAIN PLAN으로 표시되는 SCAN 노드의 정보는 다음과 같

다.

구분 설명 비고

SCAN 실행 노드의 이름 TABLE 접근하는 테이블의 이름

ACCESS 실제 접근한 레코드의 개수

DISK_PAGE_COUNT 테이블의 디스크 페이지 개수 메모리 테이블은 해당 정보가 없음

SELF_ID 실행 노드의 ID

메모리 테이블과 디스크 테이블 메모리 테이블과 디스크 테이블은 서로 표현하는 정보가 약간 다

르며, 디스크 테이블의 경우에만 해당 테이블이 소유한 디스크 페

이지 개수의 정보를 출력한다.

다음은 메모리 테이블과 디스크 테이블의 SCAN 노드의 출력 정

보를 비교한 것이다.

다음 예는 SYS 사용자의 기본 테이블스페이스가

SYS_TBS_MEMORY로 지정되어 있는 경우이며, 메모리 테이블

의 SCAN 노드 정보를 보이고 있다.

SQL 튜닝 321

iSQL> create table m1 ( i1 integer );Create success.iSQL> select * from m1;M1.I1 --------------No rows selected.------------------------------------------------------------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 success.iSQL> select * from d1;D1.I1 --------------No rows selected.------------------------------------------------------------PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: D1, FULL SCAN, ACCESS: 0, DISK_PAGE_COUNT: 2, SELF_ID: 0 )------------------------------------------------------------

테이블 이름 아래의 예에서와 같이 SCAN 노드가 접근하고 있는 테이블의 이

름을 보여주며, 질의에 alias 이름을 지정할 경우 다음과 같이 출

력된다.

iSQL> select * from t1 v1;V1.I1 --------------No rows selected.------------------------------------------------------------PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1 V1, FULL SCAN, ACCESS: 0, SELF_ID: 0 )------------------------------------------------------------

액세스 방법 및 액세스 회수 질의 튜닝에 있어 가장 중요한 정보는 전체 스캔을 하는 지 인덱

스를 사용하는 지의 여부와 얼마나 많은 레코드 접근이 이루어졌

는 지를 판단하는 것이다. 레코드 접근이 많을수록 성능 저하의

요인이 되므로 이에 대한 판단을 하는 것이 매우 중요하다.

다음은 전체 스캔에 의하여 해당 질의를 처리한 경우이다.

WHERE절을 비교하기 위하여 접근한 레코드 수를 보이고 있다.



322

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, 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 ---------------------------1000 0 1 row selected.------------------------------------------------------------PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 )------------------------------------------------------------

이 때, T1.i2 칼럼에 인덱스를 추가하고 해당 인덱스를 사용하도

록 질의를 수행하면 다음과 같은 실행 계획을 볼 수 있다. 아래

에서 보듯이 동일한 질의임에도 불구하고 다른 인덱스를 사용하

면 접근 효율이 떨어짐을 볼 수 있다.

SQL 튜닝 323

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 ---------------------------1000 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 ---------------------------1000 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 프로퍼티는 SCAN노드에

서 처리되는 조건들이 어떠한 방식으로 처리되는 지를 표현하는

정보이다. 해당 조건이 인덱스를 사용하고 있는 지를 판단하는

데 있어 유용하게 사용될 수 있다.

다음과 같이 해당 조건을 처리하기 위해 어떠한 방법을 사용하고

있는 지를 알 수 있다. 즉, 아래의 예에서는 (i1 = 1000) 을 인

덱스를 사용한 fixed key range로 (i2 = 0)은 filter로 사용함을

알 수 있다.



324

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 ---------------------------1000 0 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 실행 노드는 관계형 모델에서 검색(selection)연산을 수행

하는 물리 연산자이다. 하나의 자식 노드를 가지며 테이블에 직

접 접근하지 않고 관련 조건을 검사한다.

EXPLAIN PLAN으로 표시되는 FILT 노드의 정보는 다음과 같다.

SQL 튜닝 325


FILTER 실행 노드의 이름

FILT 노드는 별도의 정보를 포함하지 않으며 조건 정보를 출력

하기 위해서는 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

프로퍼티를 설정함으로서 가능하다. 아래와 같이 FILT 실행 노

드가 (i2 < 2)를 처리하기 위하여 생성되었음을 판단할 수 있다.

iSQL> alter system set trclog_detail_predicate = 1;Alter success.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 실행 노드



326

PROJ 실행 노드는 관계형 모델에서 프로젝션(project)연산을 수

행하는 물리 연산자이다. 하나의 자식 노드를 가지며 자식 노드

의 결과 레코드로부터 필요한 칼럼만을 추출한다.

EXPLAIN PLAN으로 표시되는 PROJ 노드의 정보는 다음과 같

다.


PROJECT 실행 노드의 이름 COLUMN_COUNT 프로젝션하는 칼럼의 개수

TUPLE_SIZE 프로젝션으로 추출하는 레코드의 크기

PROJ 노드의 출력 PROJ 노드는 질의의 최종 결과를 구성하는 노드로 다음과 같이

실행 계획 정보를 볼 수 있다. 즉, 질의 결과가 두 개의 칼럼으

로 구성되며, 결과 레코드의 크기가 8 byte임을 알 수 있다.

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 )------------------------------------------------------------

GRBY 실행 노드 GRBY 실행 노드는 관계형 모델에서 정렬 기반의 중복 검사를 수

행하는 물리 연산자이다. 하나의 자식 노드를 가지며 자식 노드

의 결과 레코드로부터 이전 레코드와 현재 레코드가 동일한 지를

판단한다.

다음과 같은 질의를 수행하는 데 사용된다.

정렬 순서를 이용한 동일한 그룹 여부 판단

정렬 순서를 이용한 중복 제거

정렬 순서를 이용한 DISTINCT aggregation의 처리

EXPLAIN PLAN으로 표시되는 GRBY 노드의 정보는 다음과 같

다.


GROUPING 실행 노드의 이름

GRBY 실행 노드는 이름 외에 별도의 정보를 표시하지 않는다.

정렬 순서를 이용한 동일한 그룹 여부 판단

SQL 튜닝 327

GRBY 노드가 정렬 순서를 이용한 동일한 그룹 여부를 판단하기

위해서 사용되는 경우 다음과 같은 형태로 실행 계획이 출력된다.

아래의 예를 보면 GRBY 노드가 (GROUP BY I3)를 처리하기 위

해서 사용되었으며, GROUP BY를 처리하기 위하여 별도의 저장

공간을 사용하지 않고 처리되었음을 알 수 있다. 이는 최적화 과

정의 정렬 순서를 이용한 GROUP BY의 처리를 통해 설명하였다.

iSQL> select sum(i1) from t1 group 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 i3 from 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



328

노드가 사용되었다. 이는 최적화 과정에서 정렬 순서를 이용한

DISTINCT aggregation 최적화에서 설명하였다.

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으로 표시되는 AGGR 노드의 정보는 다음과 같

다.


AGGREGATION 실행 노드의 이름 ITEM_SIZE 하나의 그룹을 위한 레코드 크기

GROUP_COUNT 실행 노드가 생성한 그룹의 개수

정렬 순서를 이용한 aggregation 수행 AGGR 노드가 정렬 순서를 이용한 aggregation 수행에서 사용될

경우 다음 예와 같은 실행 계획 정보가 출력된다. 아래의 예를

살펴 보면, GRBY 실행 노드가 구분한 정보를 이용하여 AGGR노

드는 SUM(i2)를 수행한다. 이 때 구성되는 레코드는 그룹을 위

한 레코드로 SUM(i2)와 GROUP BY i3의 값으로 구성된다. 예에

서는 16byte의 레코드 크기의 그룹이 다섯 개가 구성되었음을 알

수 있다.

SQL 튜닝 329

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으로 표시되는 VIEW 노드의 정보는 다음과 같

다.


VIEW 실행 노드의 이름 뷰 이름 뷰의 이름 이름이 있는 경우 ACCESS 뷰 레코드의 접근 회수 SELF_ID 노드의 ID



330

사용자가 정의한 뷰에 대한 질의가 수행될 경우 생성되는 VIEW

노드의 출력 예는 아래와 같다. VIEW 실행 노드 하위의 노드들

은 사용자가 정의한 뷰의 SELECT문에 대한 실행 계획을 의미한

다.

iSQL> create view v1(a1, a2) as select i3, sum(i2) from t1 group by i3;Create success.iSQL> select * from v1;V1.A1 V1.A2 ------------------------------------0 155530 1 158807 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 )------------------------------------------------------------

VSCN 실행 노드 VSCN 실행 노드는 관계형 모델에서 임시 저장 뷰에 대한 검색

연산을 수행한다. 하나의 자식 노드를 가지면, 이는 항상 VMTR

실행 노드이다.

SQL 튜닝 331

질의 최적화 과정에서 뷰의 결과를 저장 후 처리하는 것이 효율

적이라 판단될 때 생성된다.

EXPLAIN PLAN으로 표시되는 VSCN 노드의 정보는 다음과 같

다.


VSCN 실행 노드의 이름 VIEW 뷰의 이름

ACCESS 뷰 레코드의 접근 회수 SELF_ID 노드의 ID

VSCN 노드가 사용되는 예는 아래와 같다. 아래 질의는 동일한

뷰에 대한 접근이 외부 질의와 부질의에서 모두 등장한다. 최적

화 과정에서 해당 뷰를 임시 저장하여 질의를 수행하는 것이 효

율적으로 판단되어 VMTR 노드를 이용하여 저장하고 이를

VSCN 노드로 접근하고 있는 실행 계획을 나타낸다.

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: 22 ) STORE ( ITEM_SIZE: 32, ITEM_COUNT: 1, ACCESS: 10, SELF_ID: 11, REF_ID: 4 ) VIEW ( ACCESS: 1, SELF_ID: 10 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 22 ) 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 ( ACCESS: 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 으로 표시 ) 노드를 자식 노드로

갖는다. 위 실행 계획의 일부를 도식화하면 아래 그림과 같다.



332

VSCN(V1 X)

PROJ

FILT

PROJ

...

VSCN(V1 Y)

VMTR

VIEW

...

위의 그림에서와 같이 VSCN(V1 X)와 VSCN(V1 Y) 실행 노드는

동일한 자식 노드를 갖고 있다.

CUNT 실행 노드

CUNT 실행 노드는 관계형 모델에서 GROUP BY가 존재하지 않

는 COUNT(*)에 대한 특수 처리를 위한 실행 노드이다.

EXPLAIN PLAN으로 표시되는 CUNT 노드의 정보는 다음과 같

으며, SCAN 실행 노드와 유사한 정보로 구성된다.


COUNT 실행 노드의 이름 TABLE 접근하는 테이블의 이름




다음은 CUNT 실행 노드가 사용된 예이다. 아래의 예를 살펴보

면 인덱스를 사용함으로서 실제 데이터에는 접근하지 않고

COUNT(*) 값을 획득하고 있음을 보여준다.

SQL 튜닝 333

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으로 표시되는 HIER 노드의 정보는 다음과 같

다. HIER 실행 노드의 대부분의 정보는 SCAN 실행 노드와 유

사하다.


HIER 실행 노드의 이름 TABLE 접근하는 테이블의 이름




계층 질의에 대한 실행 계획의 예는 다음과 같다.

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 )------------------------------------------------------------

단일 저장 노드 단일 저장 노드는 하나 이하의 자식 노드를 가지며, 해당 기능을

수행하기 위해 별도의 저장 공간을 필요로하는 노드이다.



334



SORT 실행 노드 SORT 실행 노드는 관계형 모델에서 정렬 연산을 수행하는 노드

이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여


EXPLAIN PLAN으로 표시되는 SORT 노드의 정보는 다음과 같

다.


SORT 실행 노드의 이름 ITEM_SIZE 정렬을 위한 레코드의 크기

ITEM_COUNT 정렬에 포함된 레코드의 개수

DISK_PAGE_COUNT 임시 저장 테이블의 디스크 페이지 개수

메모리 임시 테이블은 해당 정보가 없음

ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID

REF_ID 임시 테이블의 재구성 여부의 기준 노드 ID

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 155530 1 158807 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에서의 사용

SQL 튜닝 335

SORT 실행 노드는 GROUP BY의 동일한 그룹을 분류하기 위한

정렬을 수행하기 위하여 생성될 수 있다. 아래의 예는 GROUP

BY i4 를 처리하기 위하여 SORT 실행 노드가 생성된 경우이다.

iSQL> select i4, sum(distinct i2) from t1 group by i4;I4 SUM(distinct I2) ------------------------------------0 950 1 970 2 990 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 i4 from 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 실행 노드가 생성되

었다.



336

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으로 표시되는 HASH 노드의 정보는 다음과 같

다.


HASH 실행 노드의 이름 ITEM_SIZE 해싱을 위한 레코드의 크기

ITEM_COUNT 해싱에 포함된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개수





HASH 실행 노드는 매우 다양한 용도로 사용되며, 각 용도별로


죠인에서의 사용 HASH 실행 노드는 죠인을 수행하기 위하여 사용될 수 있다.

아래의 예는 죠인을 처리하기 위하여 HASH 실행 노드가 생성된

경우이다. T1.i1 = T2.i1 죠인 조건을 검사하기 위하여 hash-

based 죠인이 수행되었고, 이를 위해 HASH 실행 노드가 생성되

었다.

SQL 튜닝 337

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 … ) 를 처리하기 위하여 HASH 실

행 노드가 사용된 경우이다. HASH 실행 노드는 t2.i4 값을 해싱

하여 저장하고 t1.i4 에 변화에 따라 이에 부합하는 값이 존재하

는 지를 검사하게 된다.

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으로 표시되는 GRAG 노드의 정보는 다음과 같

다.



338


GROUP-AGGREGATION 실행 노드의 이름

ITEM_SIZE 그룹을 위한 레코드의 크기 GROUP_COUNT 그룹화된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개수





아래의 예는 해싱 방식의 그룹 구분과 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 158807 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으로 표시되는 HSDS 노드의 정보는 다음과 같

다.


DISTINCT 실행 노드의 이름 ITEM_SIZE 중복 제거를 위한 레코드의 크기

ITEM_COUNT 중복 제거된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개수



SQL 튜닝 339



HSDS 실행 노드는 매우 다양한 용도로 사용되며, 각 용도별로


DISTINCT에서의 사용 HSDS 실행 노드는 DISTINCT를 처리하기 위하여 사용될 수 있

다.

아래의 예는 HSDS 실행 노드가 DISTINCT를 처리하기 위하여

사용된 예이다.

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을 처리하기 위하여 사용될 수 있다.

아래의 예는 HSDS 실행 노드가 UNION을 처리하기 위하여 중복

제거를 위해 사용된 예이다.



340

iSQL> select i3, i4 from t1 union select 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------------------------------------------------------------

VMTR 실행 노드

SQL 튜닝 341

VMTR 실행 노드는 뷰에 대한 임시 저장 테이블을 생성하는 노

드이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하

여 임시 테이블을 사용한다.

EXPLAIN PLAN으로 표시되는 VMTR 노드의 정보는 다음과 같

다.


MATERIALIZATOIN 실행 노드의 이름 ITEM_SIZE 저장된 레코드의 크기

ITEM_COUNT 저장된 레코드의 개수

VMTR 실행 노드의 사용 예는 VSCN 실행 노드의 사용 예를 참

조한다.

STOR 실행 노드 STOR 실행 노드는 질의의 일부 결과를 임시 저장하는 노드이다.

하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시

테이블을 사용한다.

EXPLAIN PLAN으로 표시되는 STOR 노드의 정보는 다음과 같

다.


STORE 실행 노드의 이름 ITEM_SIZE 저장 레코드의 크기

ITEM_COUNT 저장에 포함된 레코드의 개수





STOR 실행 노드는 매우 다양한 용도로 사용되며, 각 용도별로


죠인에서의 사용 STOR 실행 노드는 죠인에 사용될 수 있다.

일반적으로 죠인 조건이 없는 카티션 프로덕트(cartesian

product)에 주로 사용되며, 일반적인 죠인에 사용되더라도 죠인

조건을 자체적으로 처리하지는 않는다.

아래의 예는 STOR 실행 노드가 카티션 프로덕트를 위하여 사용

된 경우이다. T1 테이블에 대한 검색을 완료한 결과를 저장함으

로서 반복적인 인덱스 사용을 방지하는 효과를 얻을 수 있다.



342

iSQL> select count(*) from t1, t2 where 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으로 표시되는 LMST 노드의 정보는 다음과 같

다.


LIMIT-SORT 실행 노드의 이름 ITEM_SIZE 정렬을 위한 저장 레코드의 크기

ITEM_COUNT 사용된 레코드의 개수 STORE_COUNT 저장된 레코드의 개수



LMST 실행 노드는 매우 다양한 용도로 사용되며 각 용도별로


ORDER BY에서의 사용 LMST 실행 노드는 LIMIT을 포함한 ORDER BY에 사용될 수 있

다.

아래의 예는 LMST 실행 노드가 ORDER BY를 위하여 사용된 경

우이다. 실행 계획 정보를 살펴 보면, 저장 공간은 3개만 사용하

여 16384건의 레코드에 대한 정렬을 수행함을 알 수 있다.

SQL 튜닝 343

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 값 중 일부만을 저장하여 이에

대한 비교 연산의 비용을 줄일 수 있도록 한다.

iSQL> select i1 from t1 where i1 <=ANY ( select i4 from 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------------------------------------------------------------

이진 비저장 노드 이진 비저장 노드는 두개의 자식 노드를 가지며, 해당 기능을 수

행하기 위해 별도의 저장 공간이 필요하지 않은 노드이다.





344

JOIN 실행 노드 JOIN 실행 노드는 관계형 모델에서 죠인 연산을 수행하는 노드이

다. 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않

으며 자식 노드들의 수행 흐름을 제어한다.

EXPLAIN PLAN으로 표시되는 JOIN 노드의 정보는 다음과 같다.


JOIN 실행 노드의 이름

JOIN 실행 노드는 거의 모든 일반 죠인 수행을 위하여 사용된다.

다음과 같은 다양한 죠인 방법들이 어떠한 형태로 실행 계획 트

리가 출력되는 지를 살펴 본다.

Full nested loop join

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

SCAN SCAN

위의 실행 계획에서 죠인 조건은 우측 SCAN 노드에서 처리되며,

T2 테이블에 대한 반복적인 전체 검색을 통해 처리된다.

Full store nested loop join의 실행 계획 트리

SQL 튜닝 345

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

SCAN STOR

FILT

SCAN

위의 실행 계획에서 죠인 조건은 JOIN 상위의 FILT 노드에서 처

리된다. T2 테이블에 대한 검색은 한 번만 이루어지며 그 결과

를 저장한 후 반복적으로 전체 검색을 통해 처리된다.

Index 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, INDEX: IDX11, ACCESS: 3277, SELF_ID: 3 )------------------------------------------------------------

JOIN

SCAN SCAN

위의 실행 계획에서 죠인 조건은 우측 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

SCAN SORT

SCAN



346

위의 실행 계획에서 죠인 조건은 우측 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

SORT SORT

SCANSCAN

위의 실행 계획에서 죠인 조건은 우측 SORT 노드에서 정렬된 데

이터를 이용하여 처리되지만, 좌측에서 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의 실행 계획 트리

SQL 튜닝 347

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으로 표시되는 MGJN 노드의 정보는 다음과 같

다.


MERGE-JOIN 실행 노드의 이름

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



348

위의 실행 계획에서 죠인 조건은 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

SCAN SCAN

위의 실행 계획에서 죠인 조건은 MGJN 노드에서 처리되며 죠인

조건에 포함된 칼럼을 기준으로 정렬한 후 이를 이용한다.

LOJN 실행 노드 LOJN 실행 노드는 관계형 모델에서 LEFT OUTER JOIN 연산을

수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중간 결

과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다.

EXPLAIN PLAN으로 표시되는 LOJN 노드의 정보는 다음과 같

다.


LEFT-OUTER-JOIN 실행 노드의 이름

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

SQL 튜닝 349

FOJN 실행 노드 FOJN 실행 노드는 관계형 모델에서 FULL OUTER JOIN 연산을

수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중간 결

과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다.

EXPLAIN PLAN으로 표시되는 FOJN 노드의 정보는 다음과 같

다.


FULL-OUTER-JOIN 실행 노드의 이름

FOJN 실행 노드는 일반 죠인과 마찬가지로 대부분의 죠인 방법

이 사용되며, 이는 JOIN 노드의 예를 참조한다. 여기서는 FOJN

실행 노드가 사용되는 간단한 실행 계획 트리만을 살펴본다.

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으로 표시되는 AOJN 노드의 정보는 다음과 같

다.


ANTI-OUTER-JOIN 실행 노드의 이름

AOJN 실행 노드는 FULL OUTER JOIN만을 위해 사용되며, 아래

와 같이 ON 죠인 조건에 대하여 모든 칼럼에 대하여 인덱스를

사용할 수 있을 때 사용된다.



350

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

위의 예에서와 같이 FULL OUTER JOIN을 처리하기 위하여

AOJN 실행 노드는 항상 LOJN 실행 노드와 부모로 CONC 실행

노드를 갖는다. 이 때, ON 절의 죠인 조건은 LOJN과 AOJN 에

서 모두 처리된다.

CONC 실행 노드 CONC 실행 노드는 관계형 모델에서 concatenation 연산을 수행

하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중간 결과를

만들지 않으며 자식 노드들의 수행 흐름을 제어한다.

EXPLAIN PLAN으로 표시되는 CONC 노드의 정보는 다음과 같

다.


CONCATENATION 실행 노드의 이름

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

여기서 DNF로 WHERE 절을 처리할 때 (i1 = 1000) 조건은 왼쪽

SCAN 실행 노드에서 처리되며, (i2 = 100) 조건은 오른쪽

SCAN 실행 노드에서 처리된다. 이렇게 함으로서 IDX1 과 IDX2

인덱스를 모두 사용할 수 있으며 위 결과를 조합하기 위하여

SQL 튜닝 351

CONC 실행 노드를 사용한다. FILT 실행 노드는 좌측 SCAN과

중복되는 결과를 제거하기 위하여 사용된다.

BUNI 실행 노드 BUNI 실행 노드는 관계형 모델에서 UNION ALL 연산을 수행하

는 노드이다. 두개 이상의 자식 노드를 가지며, 별도의 중간 결과

를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다.

EXPLAIN PLAN으로 표시되는 BUNI 노드의 정보는 다음과 같

다.


BAG-UNION 실행 노드의 이름

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을 처리한다.

이진 저장 노드 이진 저장 노드는 두개의 자식 노드를 가지며, 해당 기능을 수행

하기 위해 별도의 저장 공간을 필요로하는 노드이다.





352

SITS 실행 노드

SITS 실행 노드는 관계형 모델에서 INTERSECT 연산을 수행하

는 노드이다. 두개의 자식 노드를 가지며, 교집합을 얻기 위하여

중간 결과를 저장하여 처리한다.

EXPLAIN PLAN으로 표시되는 SITS 노드의 정보는 다음과 같다.


SET-INTERSECT 실행 노드의 이름

ITEM_SIZE 교집합을 위한 저장 레코드의 크기

ITEM_COUNT 저장된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개수




L_REF_ID 임시 테이블의 재구성 여부의 왼쪽 질의 기준 노드 ID

R_REF_ID 임시 테이블의 재구성 여부의 오른쪽 질의 기준 노드 ID

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 연산을 수행하는 노

드이다. 두 개의 자식 노드를 가지며, 차집합을 얻기 위하여 중

간 결과를 저장하여 처리한다.

EXPLAIN PLAN으로 표시되는 SDIF 노드의 정보는 다음과 같다.

SQL 튜닝 353


SET-DIFFERENCE 실행 노드의 이름

ITEM_SIZE 차집합을 위한 저장 레코드의 크기

ITEM_COUNT 저장된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개수




L_REF_ID 임시 테이블의 재구성 여부의 왼쪽 질의 기준 노드 ID

R_REF_ID 임시 테이블의 재구성 여부의 오른쪽 질의 기준 노드 ID

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



354

힌트의 활용 힌트는 SQL문 실행 계획을 사용자가 명시적으로 변경하고자 할

때 사용하는 기능이다.

사용자가 생성 가능한 SQL문의 종류는 그 수를 헤아릴 수가 없

으며, 동일한 질의라 하더라도 데이터의 구성에 따라 서로 다른

실행 계획이 생성될 수 있다. 최적화 과정이 보편적으로 효율적

인 실행 계획을 생성하기는 하나 모든 질의에 있어 가장 좋은 실

행 계획을 생성할 수 있는 것은 아니다.

이러한 단점을 보완하기 위하여 사용자는 힌트를 사용하여 실행

계획을 명시적으로 변경하여 보다 나은 성능을 얻을 수 있다. 그

러나, 모든 질의에 대하여 힌트를 사용하여 실행 계획을 변경하는

것은 매우 불합리하다. 이는 인덱스의 생성, 데이터 구성의 변경

등에 대하여 모든 질의에 대하여 다시 힌트를 작성해야 하는 부

하가 따르게 된다. 따라서, 시스템의 성능에 영향을 미치는 일부

치명적인 질의에 한하여 힌트를 사용하는 것이 바람직하다.

힌트의 처리 정책 사용자가 정의한 힌트는 다음과 같은 정책에 의하여 처리된다.

사용자가 정의한 힌트가 문법적으로 오류가 없고 실행이 가능한

경우 무조건 힌트를 따른다. 즉, 문법적으로 오류가 있는 경우나

실행이 불가능한 힌트는 적용하지 않는다. 힌트 적용 시 사용자

가 정의한 힌트에 단순히 가중치를 부여하는 것이 아니며, 사용자

가 모든 정보를 고려하여 가장 효율적인 실행 계획을 이미 알고

있음을 가정한다.

힌트가 서로 상충할 경우 그 유형에 따라 다음과 같은 우선 순위

를 따른다.

최적화 적용 기준

정규화 형태

죠인 순서

죠인 방법

중간 결과 저장 매체

해싱 버켓 크기

그룹 처리 방법

중복 제거 처리 방법

뷰 최적화 방법

액세스 방법

SQL 튜닝 355

힌트의 종류 최적화 적용 기준 최적화를 규칙 기반으로 수행할 것인지, 비용 기반으로 수행할 것

인지를 설정하는 힌트이다.

RULE: 비용을 배제한 실행 계획 생성

COST: 비용을 고려한 실행 계획 생성

질의에 따라 항상 같은 실행 계획이 생성되길 원한다면 RULE 힌

트를 지정하며, 데이터 양의 변경량이 커 죠인 순서등에 많은 영

향을 미친다면 COST를 지정해 주는 것이 좋다. 해당 힌트를 사

용하지 않을 경우 기본적으로 비용 기반 최적화를 수행한다.

정규화 형태 정규화 방법을 SQL문 단위로 설정할 수 있게 하는 힌트이다.

CNF: Conjunctive Normal Form으로 정규화

DNF: Disjunctive Normal Form으로 정규화

해당 힌트가 사용되지 않을 경우 두 정규화의 비용 비교를 통하

여 하나의 정규화 방법을 선택한다.

죠인 순서 죠인 순서를 결정하는 힌트이다.

ORDERED: FROM절에 나열된 순서대로 죠인 순서를 결정

해당 힌트가 사용되지 않을 경우 비용 비교를 통하여 죠인 순서

를 결정한다.

죠인 방법 죠인 방법을 결정하는 힌트이다.

USE_NL: Nested loop 계열의 죠인 방법을 사용

USE_SORT: Sort-based 계열의 죠인 방법을 사용

USE_HASH: Hash-based 계열의 죠인 방법을 사용

USE_MERGE: Merge 죠인 계열의 죠인 방법을 사용

죠인 방법에 대한 힌트는 다음과 같은 처리 방법에 의하여 죠인

방법을 결정한다.

내부 테이블 순서로 죠인 가능성 검사

예를 들어, USE_NL(T1, T2) 힌트인 경우 T1 => T2 로의 죠

인 가능 여부를 검사한다.

내부 테이블 역순으로 죠인 가능성 검사

위의 검사에서 해당 순서로 죠인을 적용할 수 없는 경우 그

역순의 T2 => T1 의 순서로 죠인 가능 여부를 검사한다.



356

두 순서를 모두 적용할 수 없는 죠인 방법인 경우 비용 비교

를 통하여 새로운 죠인 방법을 선택한다.

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는 성능 저하를 감안하더라도 리소스 절약을

위해 저장되는 중간 결과의 크기가 매우 큰 경우에 사용하는 것

이 바람직하다.

해싱 버켓 크기 해싱 기법을 사용하는 실행 노드들의 버켓 개수를 조정하기 위하

여 사용한다.

HASH BUCKET COUNT: HASH, HSDS 노드의 해시 버켓

수 변경

GROUP BUCKET COUNT: GRAG, AGGR 노드의 해시 버켓

수 변경

SET BUCKET COUNT: SITS, SDIF 노드의 해시 버켓 수

변경

그룹 처리 방법 GROUP BY등의 처리 방법을 결정하기 위하여 사용한다.

GROUP_HASH: 해싱 방식에 의한 처리

GROUP_SORT: 정렬 방식에 의한 처리

SQL 튜닝 357

중복 제거 처리 방법 DISTINCT의 처리 방법을 결정하기 위하여 사용한다.

DISTINCT_HASH: 해싱 방식에 의한 처리

DISTINCT_SORT: 정렬 방식에 의한 처리

뷰 최적화 방법 뷰 외부의 WHERE절의 조건을 뷰 내부에서 처리할 것인지의 여

부를 결정하기 위하여 사용한다.

NO_PUSH_SELECT_VIEW: 외부의 WHERE 절의 조건을 뷰

내부로 이동하여 처리하지 않는다.

PUSH_SELECT_VIEW: 외부의 WHERE 절의 조건 중 가능

한 것은 모두 뷰 내부로 이동하여 처리

PUSH_PRED: 외부의 WHERE절의 조건 중 뷰와 관계된 죠

인조건을 뷰 내부로 이동하여 처리

액세스 방법 테이블 접근 방법을 제어하는 힌트이다.

FULL SCAN: 테이블에 이용 가능한 인덱스가 존재하더라도

인덱스를 사용하지 않고 테이블 전체 스캔

INDEX: 나열된 index중 하나를 이용해 인덱스 스캔

INDEX ASC: 나열된 index중 하나를 이용해 인덱스 오름차

순 스캔 (ascending index scan)

INDEX DESC: 나열된 index중 하나를 이용해 인덱스 내림

차순 스캔 (descending index scan)

NO INDEX: 나열된 인덱스들은 최적화 과정에서 배제

위의 힌트들은 뷰 내부에 사용된 테이블의 인덱스 이름을 힌트

구문에 사용하면, 뷰에 대해서도 일반 테이블처럼 인덱스 힌트를

줄 수 있다.

액세스 방법을 제어하는 힌트는 여러 개가 사용될 수 있으며 다

음과 같은 정책에 의하여 처리된다.

나열된 힌트가 상충하는 경우, 나열된 순서대로 힌트를 적용

한다. 뒤의 힌트는 무시한다.

예제: INDEX(T1, IDX1) NO INDEX(T1, IDX1)

상충되지 않을 경우 힌트에 나열된 액세스 방법 중 비용 계

산에 의하여 보다 효율적인 액세스 방법을 선택한다.

예제: FULL SCAN(T1), INDEX(T1, IDX1)



358

죠인 방법 힌트와 함께 사용될 경우 액세스 힌트와 죠인 방법 힌

트는 별개의 것으로 처리된다.

예제: USE_HASH(T1, T2), INDEX(T2, IDX2)

인덱스를 사용하나 Hash-based 죠인 방법으로 처리한다. 즉,

Index nested loop 죠인 방법을 사용하지 않는다.

Explain Plan 359

10. Explain Plan



360

개요

정의 질의를 최적화 하는 것은 SQL문이 얼마나 빨리 실행될 수 있는

가에 있어서 크게 영향을 준다.

Explain plan은 알티베이스 DBMS 서버가 최적화된 질의를 실행

하기 위해 수행하는 접근 경로를 설명한다. 즉, SQL문의 성능을

향상시키고 execution plan (이하 plan tree)을 결정하기 위하여

explain plan 명령을 사용한다.

Plan Tree 의 이해 많은 테이블들로부터 데이터를 검색하는 SQL문은 같은 결과 집

합을 얻기 위하여 다양한 방법 (테이블을 죠인하는 방법, 죠인 순

서, 그리고 접근 경로 등)을 사용할 수 있다. 알티베이스는 다음

과 같은 다양한 요소들을 근거로 한 기능들에 대한 적합한 경로

를 분석한다.

사용 가능한 인덱스들

SQL문 내에서의 테이블들과 열들의 순서

최적화 기법

SQL문의 plan tree는 explain plan 명령을 통해 보여진다. 사용자

들은 plan tree를 검사함으로써 알티베이스가 SQL문을 어떻게 실

행하고 있는가를 정확하게 볼 수 있다.

Plan Tree 의 분석 Explain plan 명령은 SQL문을 직접 실행하지 않고도 plan tree를

생성함으로써 SQL문의 실행 방법 뿐만 아니라 다른 plan tree와

비교하여 SQL문의 성능을 향상할 수 있다.

Plan tree 에서는 다음과 같은 정보를 얻을 수 있다:

SQL문 최적화에 따른 실행 경로

Objects (테이블, 인덱스, 등)의 속성

사용된 index

사용된 죠인 방법

Optimization에 따른 죠인 순서

Explain Plan 361

성능 분석 개선된 SQL문의 성능을 입증하는 방법

새로운 SQL문을 실행하고 그 결과를 비교한다.

새로운 plan tree를 생성하고, 그것을 이전의 plan tree와 비

교한다.

Object(테이블, 인덱스 등)의 속성들이 정확한가를 확인하기

위하여 속성들을 재검토한다.

Plan Tree Display 기능 iSQL에서 EXPLAIN PLAN을 설정(ALTER SESSION SET

EXPLAIN PLAN = ON/OFF/ONLY;)한 후 selection 기능을 수행

하는 SQL문을 실행하면 다음 option에 따라 plan tree를 텍스트

형태로 볼 수 있다.

ON 질의 수행 후 출력하며, plan tree와

access 횟수, memory size 등을 출력

OFF plan tree 출력하지 않음.

ONLY 질의 수행하지 않고, plan tree만 출력

iSQL> ALTER SESSION SET EXPLAIN PLAN = ON; Alter success iSQL> SELECT ename FROM employee WHERE emp_job = PROGRAMMER; ENAME ------------------------ HYCHOI YHBAE 2 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 22 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20,

SELF_ID: 2 ) ----------------------------------------------- iSQL> ALTER SESSION SET EXPLAIN PLAN = OFF; Alter success iSQL> SELECT ename FROM employee WHERE emp_job = PROGRAMMER; ENAME



362

------------------------ HYCHOI YHBAE 2 rows selected. iSQL> ALTER SESSION SET EXPLAIN PLAN = ONLY; Alter success iSQL> SELECT ename FROM employee WHERE emp_job = PROGRAMMER; ENAME ------------------------ No rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 22 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: ??,

SELF_ID: 2 ) -----------------------------------------------

* EXPLAN PLAN = ONLY인 경우 질의 실행 없이 실행 계획만

생성하므로 ACCESS 항목과 같이 실제 실행 후 그 값이 결정되

는 항목들은 ??로 표시된다.

Explain Plan 363

Plan Tree 보기 Plan tree는 plan node들과 각 node 간의 연결 관계로 이루어진

다. child의 표현은 parent node 보다 한 칸 아래 언급되며 첫머

리가 안으로 들어가 나타난다. 또한 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 = NIBBLE0012310001); 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 -----------------------------------------------

1 => orders 테이블에 있는 주문 번호(ono)를 index를 이용하여

검색한다. index를 이용한 access 회수는 20임을 알 수 있다.

(index가 생성되지 않은 열을 이용하여 검색을 한다면 조건에 만

족하는 열들을 찾기 위해서 orders 테이블을 full scan 해야 한

다. 즉, 각각의 plan에 대한 비용을 측정하고, 그 비용을 비교해

서 가장 비용이 적게 드는 plan을 선택하기 위하여 full scan을

PROJECT

SCAN

PROJECT

SCAN

CUSTOMER

ORDERS

4

3

2

1

5

4

3

2

1



364

이용할 것인가, index를 생성해서 scan을 할 것인가를 plan

nodes를 통해서 비교해 선택할 수 있다.)

2 => orders 테이블에서 cno인 열을 찾아 열의 개수가 하나인

새로운 relation1을 만든다.

3 => c.cno = o.cno를 검색하기 위해 full scan을 한다. access의

회수는 customer 테이블에 있는 레코드 개수(20) 만큼이다.

4 => customer 테이블에서 cname인 열을 찾아 새로운 relation2

를 만든다.

5 => relation2를 출력한다.

Explain Plan 365

Plan Nodes Plan tree는 특정한 SQL문을 위해 생성된 실행계획을 의미하며,

plan nodes는 plan tree를 구성하는 각 node를 의미한다.

Plan node는 execution algebra 또는 relational algebra 라고도

한다.

Plan Node 의 종류 Child Plan의 개수 또는 materialization 여부에 의해 나눌 수 있

다.

Child Plan의 개수에 따른 구분 One-child Node

Child node가 0개 또는 하나인 plan node를 의미한다.

Binary Node (Two-child Node)

Child node가 두 개인 plan node를 의미한다.

Materialization 여부에 의한 구분 Non-materialized Node

중간 결과를 저장하지 않고, 한 번에 한 개의 record를 처리하는

plan node를 의미한다.

Materialized Node

Child에 해당하는 node를 모두 수행하여 그 중간 결과를 저장하

는 plan node를 의미한다.



366

Non-materialized Materialized Node Name Meaning Name Meaning

SCAN Selection SORT Sort FILTER Filter HASH Hash

기본

PROJECT Projection GROUPING Group By GROUP-

AGGREGATION Group Aggregation

AGGREGATION Aggregation

그룹

COUNT Count(*) VIEW View MATERIALIZATION View

Materialization 뷰

VIEW-SCAN View Scan HIERARCHICAL QUERY

Hierarchy DISTINCT Hash Distinct

One-child

기타

LIMIT-SORT Limit Sort 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

Two-child

기타 CONCATENATION Concatenation

AGGREGATION 정의

Distinct aggregation 기능을 수행한다. Aggregation 수행 시 인

자로서 distinct column이 존재하면 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 employee;

Explain Plan 367

COUNT(DISTINCT DNO) AVG(SALARY) ------------------------------------ 5 1836647.06 1 row selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 30 ) AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 1 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, SELF_ID: 1 ) -----------------------------------------------

ANTI-OUTER-JOIN 정의

FULL-OUTER-JOIN의 빠른 처리를 위해 부가적으로 생성되는

node 이며, 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; DNO DNAME GNO -------------------------------------------- A001 응용기술팀 D001 엔진개발팀 C001 마케팅팀 C002 기획관리팀 F001 영업팀 A111100001 A111100002 B111100001 C111100001 C111100002 D111100001 D111100002 D111100003



368

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 -----------------------------------------------

Explain Plan 369

BAG-UNION 정의

Bag Union 기능을 수행하며 두 개 이상의 child node를 갖는

node 이다. SQL문의 UNION ALL에 해당한다.

형식

BAG-UNION

예제

이름이 KMLEE와 급여가 2000000 보다 큰 사원의 이름과 급여

를 출력하라.

iSQL> SELECT ename, salary FROM employee WHERE ename = KMLEE UNION ALL SELECT ename, salary FROM employee WHERE salary > 2000000; ENAME SALARY ------------------------------------- KMLEE 1200000 SJKIM 2500000 YHBAE 4000000 MSKIM 2750000 KCJUNG 2003000 JHCHOI 2300000 6 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 29 ) VIEW ( ACCESS: 6, SELF_ID: 4 ) BAG-UNION PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 29 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, DISK_PAGE_COUNT: 2, SELF_ID: 2 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 29 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, DISK_PAGE_COUNT: 2, SELF_ID: 3 ) -----------------------------------------------

CONCATENATION 정의

OR 조건(DNF)의 빠른 처리를 위한 node 이고 left child와 right

child를 순차적으로 수행하며 binary node 이다. 또한, Full Outer

Join을 위한 concatenation을 수행한다.



370

형식

CONCATENATION

예제

ANTI-OUTER-JOIN node 예제 참고

COUNT 정의

COUNT(*)의 빠른 처리를 위한 node 이다.

형식

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 table 이름

FULL SCAN index 사용 안함

index_name 사용하는 index

acc_num record 접근 횟수

node_id tuple set 내에서의 ID (node의 ID로 간주)

ref_id 참조하는 node ID

예제

사원의 총 수를 계산하라.

iSQL> SELECT COUNT(*) rec_count FROM employee; REC_COUNT ----------------------- 20 1 row selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) COUNT ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 1, SELF_ID: 1, REF_ID: 1 ) -----------------------------------------------

Explain Plan 371

DISTINCT 정의

Distinction 기능을 수행하며 materialized node 이다.

형식

1) 메모리에 materialization이 될 경우

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) 디스크에 materialization이 될 경우

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_count 저장한 item의 개수

bucket_count hash bucket의 개수

page_count, page의 개수

acc_num 접근 횟수

self_id node ID

ref_id 참조하는 node의 ID

예제

상품 C111100001을 주문한 고객이름을 출력하라.

iSQL> SELECT DISTINCT customer.cname FROM customer WHERE customer.cno IN (SELECT orders.cno FROM orders WHERE orders.gno = BYTEC111100001); CNAME ------------------------ YSKIM DKKIM IJLEE CHLEE 4 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 22 ) DISTINCT ( ITEM_SIZE: 24, ITEM_COUNT: 4, BUCKET_COUNT: 1024, ACCESS: 4, SELF_



372

ID: 6, REF_ID: 2 ) SCAN ( TABLE: CUSTOMER, INDEX: __SYS_IDX_ID_311, ACCESS: 4, SELF_ID: 2 ) [ VARIABLE KEY ] OR AND ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 16 ) DISTINCT ( ITEM_SIZE: 32, ITEM_COUNT: 4, BUCKET_COUNT: 1024, ACCESS: 8, SE LF_ID: 5, REF_ID: 3 ) VIEW ( ACCESS: 4, SELF_ID: 4 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 16 ) SCAN ( TABLE: ORDERS, INDEX: ODR_IDX3, ACCESS: 4, SELF_ID: 3 ) [ FIXED KEY ] AND OR ORDERS.GNO = BYTEC111100001 ::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 )

Explain Plan 373

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 이다.

형식

FULL-OUTER-JOIN

예제

부서의 위치와 상품을 모아 놓은 장소가 같은 곳의 부서 번호, 부

서 이름, 상품 번호를 출력하라.

iSQL> INSERT INTO department VALUES(BYTEF002, 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



374

E111100006 E111100007 E111100008 E111100009 E111100010 E111100011 E111100012 E111100013 F111100001 A001 응용기술팀 D001 엔진개발팀 C002 기획관리팀 C001 마케팅팀 F001 영업팀 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 ) -----------------------------------------------

GROUP-AGGREGATION 정의

Group aggregation 기능을 수행하며 materialized node 이다.

형식


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 )


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 )


Explain Plan 375

group_count 저장한 group의 개수

bucket_count Hash bucket의 개수

page_count Page의 개수


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 employee GROUP BY dno, emp_job; DNO EMP_JOB NUM_EMP SUM_SAL ----------------------------------------------- CEO 1 C002 DESIGNER 2 3800000 D001 ENGINEER 3 6300000 A001 PROGRAMMER 2 5700000 A001 MANAGER 1 500000 D001 MANAGER 1 C002 PLANER 2 3100000 C001 WEBMASTER 2 3750000 F001 SALESMAN 3 3690000 C001 CEO 1 980000 D001 CEO 1 2003000 C002 CEO 1 1400000 12 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 54 ) GROUP-AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 12, DISK_PAGE_COUNT: 14, ACCESS: 12, SELF_ID: 2, REF_ID: 1 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, DISK_PAGE_COUNT: 2, SELF_ID: 1 ) -----------------------------------------------

GROUPING 정의

하위 그룹으로부터 얻은 데이터가 동일한 group인지 판단한다.

형식

GROUPING



376

예제

각 사원이 담당한 고객들의 수와 각 고객에게 판매한 상품의 총

수를 출력하라.

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 이다.

형식


HASH ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID:

self_id, REF_ID: ref_id )


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 )




page_count page의 개수


self_id tuple set 내의 ID, node ID로 봐도 무관

Explain Plan 377


예제

임의의 부서를 가지고 있는 관리자의 이름과 부서 이름을 출력하

라.

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-gu Seoul, 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 응용기술팀 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 ) -----------------------------------------------

HIERARCHICAL QUERY 정의

Hierarchical query를 처리하는 노드이다.



378

형식

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 )





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.

Explain Plan 379

iSQL> SELECT id, parent, level FROM hier_order START WITH id = 0 CONNECT BY PRIOR id = parent ORDER BY level; ID PARENT LEVEL ----------------------------------------------- 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 ) -----------------------------------------------

0, NULL

Level

1 루트/부모



380

JOIN 정의

Cartesian Product 기능을 수행하며 JOIN 조건은 right child가

수행한다.

형식

JOIN

예제

입사일이 2000년 1월 1일 이전인 모든 사원의 번호, 이름, 부서

번호, 부서 이름을 출력하라.

iSQL> SELECT e.eno, ename, d.dno, dname FROM employee e, department d WHERE e.dno = d.dno AND TO_CHAR(join_date, YYYY-MM-DD HH:MI:SS) < 2000-01-01 00:00:00; ENO ENAME DNO DNAME ----------------------------------------------- 2 HJNO C002 기획관리팀 5 SJKIM D001 엔진개발팀 8 JDLEE D001 엔진개발팀 12 MYLEE F001 영업팀 4 rows selected.

Explain Plan 381

----------------------------------------------- PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 52 ) JOIN SCAN ( TABLE: EMPLOYEE E, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) [ FILTER ] AND OR TO_CHAR(JOIN_DATE, YYYY-MM-DD HH:MI:SS) < 2000-01-01 00:00:00 SCAN ( TABLE: DEPARTMENT D, INDEX: __SYS_IDX_ID_309, ACCESS: 4, SELF_ID: 3 ) [ VARIABLE KEY ] OR AND E.DNO = D.DNO -----------------------------------------------

LEFT-OUTER-JOIN 정의

Left-Outer Join 기능을 수행하며, binary node 이다.

형식

LEFT-OUTER-JOIN

예제

모든 부서에 대한 부서 번호와 사원 이름을 출력하라. (사원이 전

혀 없는 부서 번호 B001도 출력된다.)

iSQL> INSERT INTO department VALUES(BYTEB001, Quality Assurance, Jonglo, 22); 1 row inserted. iSQL> SELECT d.dno, e.ename FROM department d LEFT OUTER JOIN employee e ON d.dno = e.dno ORDER BY d.dno; DNO ENAME ------------------------------- A001 HYCHOI A001 HJMIN A001 YHBAE B001 C001 MSKIM C001 KWKIM C001 JHSEOUNG C002 HJNO C002 KMLEE C002 JHCHOI C002 DIKIM



382

C002 CHLEE D001 HSCHOI D001 KSKIM D001 SJKIM D001 JDLEE D001 KCJUNG F001 MYLEE F001 KMKIM F001 DIKIM F002 21 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 24 ) LEFT-OUTER-JOIN SCAN ( TABLE: DEPARTMENT D, INDEX: __SYS_IDX_ID_62, ACCESS: 7, SELF_ID: 1 ) SCAN ( TABLE: EMPLOYEE E, INDEX: EMP_IDX1, ACCESS: 21, SELF_ID: 2 ) -----------------------------------------------

LIMIT-SORT 정의

Limit Sorting을 수행한다. 모든 데이터를 저장 할 필요없이 일정

한 저장 공간만을 사용하여 sorting을 적용한다.

형식

LIMIT-SORT ( ITEM_SIZE: item_size, ITEM_COUNT:

item_count, STORE_COUNT: store_count, ACCESS: acc_num,



item_count 저장할 item의 개수

store_count 실제 정렬된 item의 개수


self_id tuple set 내의 ID, node ID로 봐도 무관


예제

모든 사원의 이름, 부서 번호 및 급여를 표시하고 부서 번호를 기

준으로 정렬한 후 급여를 기준으로 해서 내림차순으로 상위 10개

만 출력하라. (ORDER BY 목록의 순서가 정렬 순서임.)

iSQL> SELECT ename, dno, salary FROM employee

Explain Plan 383

ORDER BY dno, salary DESC LIMIT 10; ENAME DNO SALARY -------------------------------------------- YHBAE A001 4000000 HYCHOI A001 1700000 HJMIN A001 500000 MSKIM C001 2750000 JHSEOUNG C001 1000000 KWKIM C001 980000 JHCHOI C002 2300000 CHLEE C002 1900000 HJNO C002 1500000 DIKIM C002 1400000 10 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 33 ) LIMIT-SORT ( ITEM_SIZE: 16, ITEM_COUNT: 20, STORE_COUNT: 10, ACCESS: 10, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, SELF_ID: 0 ) -----------------------------------------------

MATERIALIZATION 정의

View의 빠른 처리를 위해 생성되는 node 이다. 하위 VIEW

node에 의해 생성된 record를 하나의 가상 table (view)로 저장

한다.

형식

MATERIALIZATION ( ACCESS: acc_num, SELF_ID: self_id )


self_id node ID

예제

해당 부서의 평균 급여보다는 급여를 많이 받고, 가장 높은 평균

급여보다는 적게 받는 사원의 이름, 부서 번호, 급여를 출력하라.

iSQL> CREATE VIEW v1 AS (SELECT dno, AVG(salary) avg_sal

FROM employee GROUP BY dno); Create success. iSQL> SELECT ename, e.dno, e.salary FROM employee e, v1 WHERE e.dno = v1.dno



384

AND e.salary > v1.avg_sal AND e.salary < (SELECT MAX(avg_sal)

FROM v1); ENAME DNO SALARY -------------------------------------------- CHLEE C002 1900000 MYLEE F001 1890000 2 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 33 ) JOIN VIEW-SCAN ( VIEW: V1, ACCESS: 6, SELF_ID: 3 ) MATERIALIZATION ( ITEM_SIZE: 32, ITEM_COUNT: 6 ) VIEW ( ACCESS: 6, SELF_ID: 8 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 24 ) AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 6 ) GROUPING SCAN ( TABLE: EMPLOYEE, INDEX: EMP_IDX1, ACCESS: 20, SELF_ID: 2 ) SCAN ( TABLE: EMPLOYEE E, INDEX: EMP_IDX1, ACCESS: 19, SELF_ID: 1 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 21 ) STORE ( ITEM_SIZE: 32, ITEM_COUNT: 1, ACCESS: 12, SELF_ID: 12, REF_ID: 5 ) VIEW ( ACCESS: 1, SELF_ID: 11 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 21 ) GROUP-AGGREGATION ( ITEM_SIZE: 40, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 10, REF_ID: 5 ) VIEW-SCAN ( VIEW: V1, ACCESS: 6, SELF_ID: 5 ) ::SUB-QUERY END -----------------------------------------------

MERGE-JOIN 정의

Merge Join 기능을 수행한다.

형식

MERGE-JOIN

예제

직원 이름이 KMKIM의 직원 번호, 주문 번호, 상품 번호, 주문양

을 출력하라. (두 테이블 모두 죠인 술어와 관련해 인덱스(eno)가

Explain Plan 385

존재하여야 한다. 인덱스 스캔을 하므로 SMJN의 좌, 우 노드들

(SCAN node)로부터 레코드의 eno 값이 sorting 되어 검색된다.

따라서, 두 값의 대소 차이가 발생하는 이후의 레코드는 검색하지

않고 다시 같은 값을 가지는 레코들를 만날 때까지 두 테이블의

커서를 이동하여 검색한다.)

iSQL> SELECT e.eno, ono, cno, gno, qty FROM employee e, orders o WHERE e.eno = o.eno AND e.ename = KMKIM; ENO ONO CNO GNO QTY ----------------------------------------------- 19 0012300001 730828-1201145 D111100004 1000 19 0011290100 700101-1001001 E111100001 500 19 0012310011 750625-1122143 E111100012 10000 19 0012100277 761012-1220475 D111100008 2500 19 0012300010 781225-1333044 D111100010 2000 19 0012310008 730828-1201145 D111100003 100 19 0012300005 720305-2101114 D111100008 4000 19 0012310004 761012-1220475 E111100010 5000 19 0012310012 730828-1201145 C111100001 250 9 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 5, TUPLE_SIZE: 40 ) MERGE-JOIN SCAN ( TABLE: EMPLOYEE E, INDEX: __SYS_IDX_ID_63, ACCESS: 20, SELF_ID: 2 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 30, ACCESS: 19, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: ORDERS O, FULL SCAN, ACCESS: 30, SELF_ID: 3 ) -----------------------------------------------

PROJECT 정의

Projection 기능을 수행하며, 지정한 column들을 추출해 낸다.

형식



386

PROJECT ( COLUMN_COUNT: col_count, TUPLE_SIZE:

tuple_size )

col_count column들의 개수

tuple_size projection에 의해 선택된 tuple의 실제

크기

예제

전 사원의 급여를 10% 인상 시 전 사원의 이름과 급여를 출력하

라.

iSQL> SELECT ename, salary * 1.1 FROM employee; ENAME SALARY * 1.1 -------------------------------------- SWNO HJNO 1650000 HSCHOI 2200000 … KMKIM 1980000 DIKIM 20 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 44 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, DISK_PAGE_COUNT: 2, SELF_ID: 2 ) -----------------------------------------------

SCAN 정의

Selection 기능을 수행하며, 특정 테이블을 Key Range, Filter등

을 사용해 조건에 맞는 레코드를 검색한다.

형식


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 )


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 )

Explain Plan 387






node_id tuple set 내에서의 ID (node의 ID로 간

주)

예제

예제1) 생일이 상반기(6월 30일) 이전인 사원들의 이름, 부서 번

호, 생일을 출력하라

iSQL> SELECT ename, dno, birth FROM employee WHERE birth < BYTE0630; ENAME DNO BIRTH --------------------------------------- HSCHOI D001 0226 HJMIN A001 0417 KMLEE C002 0102 YHBAE A001 0213 MYLEE F001 0211 JHSEOUNG C001 0514 JHCHOI C002 0509 7 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 30 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, DISK_PAGE_COUNT: 2, SELF_ID: 2 ) -----------------------------------------------

예제2) 다음은 employee 테이블에서 생일이 하반기인 직원을 검

색한다. (index 이용)

iSQL> CREATE INDEX emp_idx2 ON employee(birth); Create success. iSQL> SELECT ename, dno, birth FROM employee WHERE birth < BYTE0630; ENAME DNO BIRTH --------------------------------------- KMLEE C002 0102 MYLEE F001 0211 YHBAE A001 0213 HSCHOI D001 0226 HJMIN A001 0417



388

JHCHOI C002 0509 JHSEOUNG C001 0514 7 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 30 ) SCAN ( TABLE: EMPLOYEE, INDEX: EMP_IDX2, ACCESS: 7, DISK_PAGE_COUNT: 2, SELF_ID: 2 ) -----------------------------------------------

SET-DIFFERENCE 정의

Set Difference 기능을 수행하며, binary node, materialized node

이다. SQL문의 MINUS에 해당한다.

형식


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 )


SET-DIFFERENCE ( ITEM_SIZE: item_size, ITEM_COUNT:

item_count, DISK_PAGE_COUNT: page_count, ACCESS:


r_ref_id )






self_id node ID

l_ref_id Left 참조 node ID. 만약 independent 하

면 left-child의 data를 다시 저장할 필요

가 없음.

r_ref_id Right 참조 node ID. 만약 independent,

하면 right-child의 data를 다시 저장할 필

요가 없음.

예제

Explain Plan 389

주문된 상품들을 제외한 상품 번호를 출력하라.

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 정의

Set Intersection 기능을 수행하며, binary node, materialized

node 이다. SQL문의 INTERSECT에 해당한다.

형식




390

SET-INTERSECT ( ITEM_SIZE: item_size, ITEM_COUNT:

item_count, BUCKET_COUNT: bucket_count, ACCESS:


r_ref_id )


SET-INTERSECT ( ITEM_SIZE: item_size, ITEM_COUNT:

item_count, DISK_PAGE_COUNT: page_count, ACCESS:


r_ref_id )






self_id node ID

l_ref_id Left 참조 node ID. 만약 independent 하

면 left-child의 data를 다시 저장할 필요

가 없음.

r_ref_id Right 참조 node ID. 만약 independent

하면 right-child의 data를 다시 저장할 필

요가 없음.

예제

사원과 고객의 생일이 상반기(6월 30일 이전)인 사람들중 같은

이름을 가진 사람의 이름을 출력하라.

iSQL> SELECT ename FROM employee WHERE birth < BYTE0630 INTERSECT SELECT cname FROM customer WHERE birth < BYTE0630; ENAME ------------------------ MYLEE 1 row selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 22 ) VIEW ( ACCESS: 1, SELF_ID: 4 ) SET-INTERSECT ( ITEM_SIZE: 40, ITEM_COUNT: 7, DISK_PAGE_COUNT: 8, ACCESS: 1, SELF_ID: 5, L_REF_ID: 2, R_REF_ID: 3 )

Explain Plan 391

PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 22 ) SCAN ( TABLE: EMPLOYEE, INDEX: EMP_IDX2, ACCESS: 7, DISK_PAGE_COUNT: 2, SELF_ID: 2 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 22 ) SCAN ( TABLE: CUSTOMER, FULL SCAN, ACCESS: 20, DISK_PAGE_COUNT: 2, SELF_ID: 3 ) -----------------------------------------------

SORT 정의

Sorting 기능을 수행하며 materialized node 이다.

형식


SORT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id )


SORT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num,






self_id Tuple set 내의 ID, node ID로 봐도 무

관

ref_id 참조하는 node ID, Dependency 검사

대상 Node

* Dependency: Materialized node가 저장한 데이터의 유효성을

판단하는 기준이다. 만약 참조하는 node가 dependant 하면, 결과

를 다시 수행해야 하며, independent 하면 동일한 결과를 다시

수행할 필요가 없다.

예제

급여가 100만원 이하인 직원의 이름, 업무, 입사일, 급여를 급여

순서로 정렬하라.

iSQL> SELECT ename, emp_job, join_date, salary FROM employee WHERE salary < 1000000 ORDER BY 4 DESC;



392

ENAME EMP_JOB JOIN_DATE SALARY ----------------------------------------------- KWKIM CEO 980000 HJMIN MANAGER 2000/01/24 00:00:00 500000 2 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 59 ) SORT ( ITEM_SIZE: 32, ITEM_COUNT: 2, DISK_PAGE_COUNT: 3, ACCESS: 2, SELF_ID: 3, REF_ID: 2 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, DISK_PAGE_COUNT: 2, SELF_ID: 2 ) -----------------------------------------------

VIEW 정의

In-line View들을 처리하기 위한 node 이다. Projection에 해당하

는 column들을 하나의 연속된 가상의 레코드로 인식하도록 한다.

형식

VIEW ( ACCESS: acc_num, SELF_ID: self_id )


self_id node ID

예제

해당 부서의 평균 급여보다 급여를 많이 받는 모든 사원의 이름,

급여, 부서 번호 및 그 부서의 평균 급여를 출력하라.

iSQL> SELECT e.ename, e.salary, e.dno, v1.salavg FROM employee e,

(SELECT dno, AVG(salary) salavg FROM employee GROUP BY dno) v1 WHERE e.dno = v1.dno AND e.salary > v1.salavg; ENAME SALARY DNO SALAVG ----------------------------------------------- YHBAE 4000000 A001 2066666.67 MSKIM 2750000 C001 1576666.67 JHCHOI 2300000 C002 1660000 CHLEE 1900000 C002 1660000 SJKIM 2500000 D001 2075750 MYLEE 1890000 F001 1845000

Explain Plan 393

6 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 56 ) JOIN VIEW ( ACCESS: 6, SELF_ID: 3 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 24 ) AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 6 ) GROUPING SCAN ( TABLE: EMPLOYEE, INDEX: EMP_IDX1, ACCESS: 20, SELF_ID: 2 ) SCAN ( TABLE: EMPLOYEE E, INDEX: EMP_IDX1, ACCESS: 19, SELF_ID: 1 ) [ VARIABLE KEY ] OR AND E.DNO = V1.DNO [ FILTER ] AND OR E.SALARY > V1.SALAVG -----------------------------------------------

VIEW-SCAN 정의

MATERIALIZATION node에 의해 생성된 가상 table (view)에

대한 scan 기능을 수행한다.

형식

VIEW-SCAN ( VIEW: view_name, SELF_ID: self_id )

view_name view 이름

self_id node ID

예제

MATERIALIZATION Node 참고


PartⅢ 395

395

Part III

알티베이스 튜닝 397

11. 알티베이스 튜닝

이장에서는 서버의 성능 향상을 위해서 알티베이스가 제공하는

다음 두가지 기능에 대해서 설명한다.

그룹 커밋(Group Commit)

로그 파일 그룹(Log File Group)


그룹 커밋(Group Commit) 이 장에서는 트랜잭션 처리 성능 향상을 위해서 알티베이스가 제

공하는 그룹 커밋 기능에 대해서 설명한다.

그룹 커밋의 개념 그룹 커밋은 트랜잭션의 커밋 요청을 모아서 한번에 처리하여 다

수의 트랜잭션이 커밋을 하려는 환경에서 I/O부하를 줄여주는 기

능이다.

하나의 트랜잭션이 커밋한 후에는 해당 트랜잭션이 수정한 내용

이 어떠한 상황에서도 유실되어서는 안된다. 이를 보장하기 위해

서는 해당 트랜잭션이 기록한 로그가 모두 디스크에 기록되었음

을 확인한 다음, 클라이언트에게 트랜잭션의 커밋이 완료되었음을

알려주어야 한다.

하지만 이러한 과정에서 수행되는 디스크 I/O는 메모리 기록에

비해 시간이 많이 걸리는 작업으로, 여러 트랜잭션이 동시에 이와

같은 디스크 I/O요청을 각자 처리하게 될 경우 시스템의 성능 저

하 정도는 더욱 심해질 것이다.

디스크 I/O를 하는데 소요되는 시간은 I/O의 양보다는 횟수에 의

해 더 큰 영향을 받는다. 즉, 여러번에 걸쳐서 수행할 I/O를 한번

에 몰아서 수행할 수 있다면, 시스템의 성능을 향상 시킬 수 있

을 것이다.

그룹커밋은 커밋을 하려는 여러 트랜잭션들의 로그에 대한 디스

크 I/O를 몰아서 한번의 I/O로 처리하여 시스템의 성능을 향상시

킨다.

그룹 커밋의 동작 여러 트랜잭션의 커밋을 위한 디스크 I/O수행을 한번에 몰아서

처리하기 위해 알티베이스는 마지막으로 디스크 I/O를 수행한 시

각을 기억해두고 있다가 이후 일정 시간이 지나기 전에는 디스크

I/O를 허용하지 않고 트랜잭션들을 대기하도록 한다.

이와 같은 디스크 I/O대기 시간이 적당한 값이 너무 작으면 디스

크 I/O가 너무 빈번하게 수행되어 그룹 커밋을 하지 않은것과 별

반 다름이 없게 되고, 너무 크면 디스크 I/O를 수행하려는 트랜잭

션들이 불필요하게 오래 대기하게 되어 시스템의 성능이 저하된

다.

그룹 커밋을 위한 디스크 I/O대기시간을 튜닝하는 방법에 대해서

는 본 장의 “그룹 커밋 프로퍼티 튜닝” 을 참고한다.


하나의 트랜잭션이 커밋을 위해 로그를 기록하기 위한 디스크

I/O를 수행할 때는 다음과 같은 체크를 수행한다.

1. 디스크로 기록하려고 하는 로그가 이미 다른 트랜잭션에 의해

디스크로 내려간 경우

1.1 이미 디스크로 기록된 로그를 재차 기록할 필요가 없기

때문에 트랜잭션은 디스크 I/O를 수행하지 않는다.

2. 마지막으로 I/O를 수행한 시각이후로 사용자가

LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정한

시간만큼이 지나지 않은 경우

2.1 디스크 I/O를 실시하지 않고 대기한다.

2.2 LFG_GROUP_COMMIT_RETRY_USEC 프로퍼티에 지

정한 시간마다 한번씩 1,2,3을 다시 한번 체크한다.

3. 마지막으로 I/O를 수행한 시각이후로 사용자가

LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정한

시간이상 경과한 경우

3.1 디스크 I/O를 수행한 시각을 기록한다.

3.2 디스크 I/O를 위해 충분한 시간을 기다렸으므로, 로그

의 맨 끝단까지 기록된 모든 로그를 디스크로 내리는 디스

크 I/O를 수행한다.

그룹 커밋의 수행 단위 앞서 LFG(Log File Group,로그파일 그룹)기능에서 살펴본 바와

같이, 트랜잭션이 기록한 로그를 디스크로 기록하는 작업은 LFG

별로 각각 수행된다. 그러므로 그룹커밋도 서로 다른 LFG간에 영

향을 받지 않고 별개로 진행된다.

TRANSACTION_DURABILITY_LEVEL 프로퍼티와의 관계 TRANSACTION_DURABILITY_LEVEL 프로퍼티가 3으로 설정

된 경우에는 정전시의 영속성(Durability)을 보장하지 않기 때문

에, 트랜잭션의 커밋시에 로그를 디스크로 내리는 I/O를 수반하지

않는다.

그룹 커밋기능은 트랜잭션의 영속성(Durability)보장을 위한 디스

크 I/O를 몰아서 처리하는 최적화 기법이다. 그러므로

TRANASCTION_DURABILITY_LEVEL 프로퍼티가 5로 설정되

어서 트랜잭션의 커밋시마다 해당 트랜잭션이 기록한 로그를 모

두 디스크에 기록하여 트랜잭션의 영속성(Durability)을 보장하도

록 설정한 경우에만 그룹 커밋 기능이 활성화된다.


그룹 커밋의 수행 여부 결정 그룹 커밋은 여러 트랜잭션이 동시에 커밋을 하려고 할 때에만

그 효과를 발휘한다. 예를 들어 시스템상에 오직 하나의 트랜잭션

만이 커밋하려고 하는 경우에는 커밋 하려는 다른 트랜잭션이 존

재하지 않는 상황이 되며, 이 때에는 함께 몰아서 처리할 추가적

인 디스크 I/O가 없는 상황이므로 그룹커밋을 하지 않고 바로 디

스크 I/O를 수행하는 것이 더 좋은 성능을 낸다.

이와 같이 시스템상에 커밋을 하려는 트랜잭션의 수가 적은 경우

에는 로그를 디스크로 내리기 위해 그룹커밋을 하지 않고 바로

디스크 I/O를 수행하는것이 효과적이다.

앞서 “그룹커밋의 수행단위”에 기술한 바와 같이, 그룹 커밋은

LFG별로 독립적으로 이루어진다. 그룹 커밋을 수행할지의 여부도

LFG별로 독립적으로 결정하게 되며, 이는 각각의 LFG별로 현재

커밋하지 않은 , 하지만 앞으로 커밋을 할 트랜잭션들의 갯수를

통해 판별한다.

알티베이스는 DB에 변경을 가한 트랜잭션들의 수를 각각의 LFG

별로 센다. 그리고 하나의 트랜잭션이 커밋을 위해 로그를 디스크

로 내리려는 시점에서 해당 LFG의 DB에 변경을 가한 트랜잭션

의 수가 LFG_GROUP_COMMIT_UPDATE_TX_COUNT 프로퍼

티보다 크거나 같을 때에만 위의 “그룹 커밋의 동작”에서 기술한

대로 그룹커밋을 실시하고, 그 외의 경우에는 그룹커밋을 하지 않

고 바로 디스크 I/O를 수행한다.

DBA는 시스템의 상황을 고려하여

LFG_GROUP_COMMIT_UPDATE_TX_COUNT 의 최적값을 찾

아내야 한다. 이 프로퍼티의 기본값은 80으로 되어 있다.

그룹 커밋관련 통계치 알티베이스는 DBA가 그룹 커밋의 동작을 모니터링 할 수 있는

통계치를 제공한다. 그룹 커밋은 LFG별로 독립적으로 이루어지기

때문에, 그룹 커밋의 통계치는 V$LFG에 존재한다.

V$LFG의 그룹 커밋 관련 통계값들은 다음과 같다.

UPDATE_TX_COUNT

해당 LFG에 속한 트랜잭션중 DB에 변경을 가한 트랜잭션

의 갯수를 실시간으로 보여주는 통계치이다. 이 값이 LFG

_GROUP_COMMIT_UPDATE_TX_COUNT프로퍼티보다

클 때에만 해당 LFG에 대해 그룹 커밋을 실시한다.

－ GC_WAIT_COUNT


마지막으로 디스크 I/O를 수행한 시각 이후로 LFG_GROU

P_COMMIT_INTERVAL_USEC 프로퍼티에 지정한 만큼의

시간이 지나지 않아서 커밋을 위한 디스크 I/O를 수행하

지 못하고 기다릴 때마다 1씩 증가하는 카운트 값이다.

－ GC_ALREADY_SYNC_COUNT

트랜잭션이 커밋을 위해 디스크로 기록해야 하는 로그의

내용이 이미 다른 트랜잭션에 의해 디스크로 기록된 경우

에는 추가적인 디스크 I/O를 수행할 필요가 없다. 이와 같

이 디스크 I/O를 수행하지 않고 바로 커밋 완료 응답 신호

를 보내는 경우에 1씩 증가하는 카운트 값이다.

GC_REAL_SYNC_COUNT

실제 디스크 I/O를 수행하여 로그를 디스크로 기록한 경우

1씩 증가되는 카운트 값이다. 이는 두 가지 경우 중 하나

이다.

1. 하나의 트랜잭션이 커밋을 위해 로그를 디스크로 기

록하려 하려는 시점에서 V$LFG의 UPDATE_TX_COU

NT가 LFG_GROUP_COMMIT_UPDATE_TX_COUNT

프로퍼티보다 작아서 그룹 커밋 기능이 활성화 되지 않

아서 직접 로그 기록을 위한 디스크 I/O를 수행한 경우

2. 그룹 커밋이 활성화된 상황에서 마지막으로 디스크 I

/O를 수행한 시각 이후로 LFG_GROUP_COMMIT_INT

ERVAL_USEC 프로퍼티에 지정한 만큼의 시간이 지나

서 실제 디스크 I/O를 수행한 경우

그룹 커밋의 프로퍼티 튜닝 그룹 커밋 기능을 이용하기 위해서는 시스템 자체의 성능과

다수의 커밋하려는 트랜잭션이 발생하는 상황에서의 시스템의

부하를 종합적으로 고려하여 관련 프로퍼티를 최적값으로 설정해

주어야 한다.

이제부터 각각의 프로퍼티값을 튜닝하는 방법에 대해 알아본다.

LFG_GROUP_COMMIT_UPDATE_TX_COUNT

이 프로퍼티의 값이 너무 작으면 DB에 변경을 가한 트랜

잭션 수가 그다지 많지 않아도 그룹 커밋이 활성화된다.

이 경우, 로그를 기록하기 위한 디스크 I/O의 횟수가 증가

하여 시스템 성능이 저하된다.

이 프로퍼티의 값이 너무 크면 DB에 변경을 가한 트랜잭

션의 수가 충분히 많음에도 불구하고 그룹커밋이 활성화

되지 못한다.


DBA는 시스템에 여러개의 트랜잭션이 몰리는 때에 V$LF

G의 UPDATE_TX_COUNT를 실시간으로 모니터링 하여

이 프로퍼티의 값을 적정한 값으로 결정할 수 있다.

LFG_GROUP_COMMIT_INTERVAL_USEC

이 프로퍼티의 값이 너무 작으면 빈번하게 I/O가 수행되어

시스템의 성능이 저하된다. 이러한 상황에서는 커밋을 위

해 실제로 I/O를 수행하는 횟수가 많아지므로 V$LFG의 G

C_REAL_SYNC_COUNT가 빠른 속도로 증가한다.

이 프로퍼티의 값이 너무 크면 디스크 I/O를 수행할 수 있

는 I/O 처리량(bandwidth)을 충분히 활용하지 못하여 시

스템의 성능이 저하된다. 이러한 상황에서는 I/O를 위해 대

기하는 횟수가 많아지므로 V$LFG의 GC_WAIT_COUNT가

빠른 속도로 증가한다.

이 프로퍼티를 최적으로 설정하기 위해서는 우선 이 프로

퍼티의 값을 기본값인 1000 (1ms)에서부터 시작하여 2배

씩 증가시켜가면서 시스템의 전체 TPS(Transaction Per

Second)를 측정한다.

GC_REAL_SYNC_COUNT 의 값이 점점 작아지면서 최

적의 TPS를 내는 상황이 이 프로퍼티가 최적의 값으로 설

정된 것이다.

GC_REAL_SYNC_COUNT의 값이 작아지는 것이 곧 최적

의 TPS를 내는 상황을 의미하지는 않는다. 앞서 설명한 대

로 이 프로퍼티의 값이 너무 크면 커밋을 하려는 트랜잭션

들이 디스크 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_WA

IT_COUNT가 이 프로퍼티의 값이 클 때보다 빠른 속도로

증가한다.

이 프로퍼티의 값이 너무 크면 디스크 I/O를 대기하는 트

랜잭션들의 디스크 I/O가 가능한지의 여부를 체크하는 횟

수가 줄어들게 되며, CPU사용율이 낮아지게 된다. 하지만


I/O 가능 여부를 체크하기까지의 대기시간이 길어져서 개

별 트랜잭션의 커밋후 응답시간은 길어진다.

DBA는 이 프로퍼티의 값을 변경하면서 Unix의 top명령이

나 Windows의 작업관리자를 통해 알티베이스 프로세스의

CPU사용율을 모니터링하거나 개별 트랜잭션의 응답시간

의 평균값을 측정하는 방식으로 이 프로퍼티 값을 최적의

값으로 설정할 수 있다.

그룹 커밋의 단점 그룹 커밋은 시스템이 특정 시간동안 가능한한 많은 트랜잭션의

커밋 요청을 처리할 수 있도록 돕는다. 하지만 그룹 커밋을 사용

할 경우 여러 트랜잭션의 커밋 요청을 몰아서 한번에 처리하기

때문에, 개별 트랜잭션의 커밋 요청후 커밋 완료 응답을 받기 까

지의 시간은 그룹 커밋을 사용하기 이전보다 더욱 늘어나게 된다

는 단점을 지닌다.


로그파일그룹(Log File Group) 알티베이스에서 제공하는 로그파일그룹 기능에 대해서 기술한다.

개념 로그파일그룹은 여러 트랜잭션들의 로그가 여러개의 로그파일에

동시에 기록될 수 있도록 하여 시스템의 성능을 최적의 상태로

만들어준다.

알티베이스는 기본적으로 로그파일들을 LOG_DIR프로퍼티에 설

정된 하나의 디렉토리에 관리한다. 그리고 그 속의 로그파일들중

오직 하나의 로그파일에 시스템 운영중에 발생하는 로그를 기록

한다. 트랜잭션의 영속성(Durability)보장을 위해서 로깅은 필수적

이며, 일반적으로 여러 개의 트랜잭션이 동시에 수행되는 환경에

서는 이와 같이 시스템 상에 하나 뿐인 로그파일에 로그를 기록

하는 과정에서 병목현상이 발생한다.

이러한 병목 현상을 해결하기 위하여 알티베이스는 로그 파일이

기록되는 경로를 여러 개 지정할 수 있도록 로그파일그룹을 제공

한다. 하나의 로그 경로 안에서 오직 하나의 로그파일에만 로그가

기록된다는 기존의 제약사항은 그대로 적용되지만, 이러한 로그

경로가 여러 개가 됨에 따라 동시에 로그를 기록할 수 있는 로그

파일의 수도 여러개로 늘어난다.

이와 같이 하나의 로그 경로, 즉 여러 개의 로그파일을 지니는 로

깅 시스템의 최소 단위를 로그파일그룹(Log File Group, LFG)라

고 칭한다. 앞으로는 설명의 편의를 위하여 로그파일그룹을 간

략하게 LFG라고 통칭한다.

시스템상에 DB에 변경을 가하는 트랜잭션이 많을수록, 커밋이 빈

번하게 수행될 수록 LFG를 여러개로 구성함에 따른 성능향상

이 더욱 두드러진다.

구성요소 하나의 LFG는 다음과 같은 물리적 구성 요소를 지닌다.

로그 경로 ( LOG_DIR 프로퍼티 )

하나의 로그 경로에는 하나 혹은 그 이상의 로그 파일들이 존재하며, 그 중 오직 하나의 로그파일에만 로그를 기록할 수 있다.

아카이브 로그 경로 ( ARCHIVE_DIR 프로퍼티 )

아카이브로깅을 할 경우, 로그 경로안의 기록이 완료된 로그파일들을 아카이브 로그 경로로 복사하게 된다. 이러한 아카이브 로그파일은 데이터베이스 복구와 백업을 위해 사용된다.


이 프로퍼티의 수는 LOG_DIR프로퍼티의 수와 정확히 일치해야 한다. 아울러, LOG_DIR 프로퍼티가 여러 개인 경우 ARCHIVE_DIR프로퍼티들은 LOG_DIR 프로퍼티 값과 순서대로 1:1 로 매핑될 수 있도록 기술한다.

하나의 LFG에는 다음과 같은 세가지 종류의 쓰레드가 존재한다.

로그파일 생성 쓰레드 ( Log File Creation Thread )

알티베이스는 하나의 LFG에서 로그가 기록되는 로그파일을 끝까지 사용하였을 때, 새로운 로그파일에 로기를 기록하기 시작한다. 이 때, 새로운 로그파일이 필요한 시점에서 로그파일을 생성한다면, 로그를 기록하려는 트랜잭션들이 로그파일이 생성되는 동안 아무 작업도 수행하지 못한 채로 기다려야 한다는 문제점이 발생한다.

이 쓰레드는 로그 기록을 위한 새 로그파일이 필요하기 전에 미리 로그파일을 만들어 둔다.

참고로, 로그파일이 삭제되는 시점은 체크포인트가 끝난 후이며, 체크포인트 중에는 더 이상 사용되지 않는 로그파일들을 별도로 분류하여 삭제한다.

로그 플러쉬 쓰레드 ( Log Flush Thread )

해당 LFG에 기록된 로그를 주기적으로 디스크로 기록하는 쓰레드이다. 이 쓰레드가 로그를 미리 디스크에 기록해 두기 때문에, 커밋하려는 트랜잭션은 이 쓰레드가 이미 디스크에 기록한 로그를 다시 기록할 필요가 없으며, 디스크에 기록되지 않은 로그만 별도로 디스크에 기록하게 된다.

즉, 주기적으로 로그를 디스크로 기록하여 커밋하려는 트랜잭션이 디스크로 기록해야 할 로그의 양을 줄여주는 쓰레드이다.

아카이브 로그 쓰레드 ( Archive Log Thread )

해당 LFG에서 로그가 기록되고 있는 로그파일을 끝까지 사용하면 다른 새로운 로그파일에 로그를 기록하기 시작한다. 이때, 아카이브 쓰레드는 방금 전까지 로그가 기록되고 있던, 하지만 끝까지 다 기록되어 더이상 로그가 기록되지 않는 로그파일을 아카이브 로그파일로 복사한다.

사용 예 알티베이스는 같이 기본적으로 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/logs가 된다.

데이터베이스를 생성한 후 로그 경로 안의 내용을 살펴보면 다음

과 같이 logfile0부터 logfile2까지 세개의 로그파일이 존재하는

것을 관찰할 수 있다. 이러한 세 개의 로그파일중 오직 하나의 로

그파일에만 트랜잭션이 데이터베이스에 변경을 가하면서 발생하

는 로그가 기록된다.

-rw------- 1 kmkim kmkim 10485760 Jun 22 15:46

logfile0


logfile1


logfile2

다음은 LFG를 세개로 구성한 경우의 알티베이스 프로퍼티 파일

의 일부이다. LFG의 수를 LOG_FILE_GROUP_COUNT 프로퍼티

에 3으로 기술하였으며, LOG_DIR과 ARCHIVE_DIR을 각각 세

개씩 기술하여 세 개의 LFG에 해당하는 로그경로와 아카이브 로

그 경로를 기술하고 있다.


LOG_FILE_GROUP_COUNT = 3 # LFG의 수(3)

LOG_DIR = ?/logs1 # 로그 경로

( LFG#0 )


( LFG#1 )


( LFG#2 )

ARCHIVE_DIR = ?/arch_logs1 # 아카이브 로그 경로

( LFG#0 )


( LFG#1 )


( LFG#2 )

TRANSACTION_DURABILITY_LEVEL=5

위에 기술한 로그 디렉토리들은 LFG가 한 개일 때와 마찬가지로

알티베이스 홈 경로인 $ALTIBASE_HOME에 logs1,logs2,logs3

를 사용자가 명시적으로 생성해 주어야 한다.

LFG#0는 $ALTIBASE_HOME/logs1 에 로그파일을 기록하며, 이

안의 로그파일중 오직 하나에만 로그를 기록할 수 있다.

마찬가지 규칙이 LFG#1, LFG#2에도 적용된다.

이와 같이 LFG를 세 개로 구축한 경우, 정전시에도 트랜잭션의

영속성(Durability)를 보장하는

TRANSACTION_DURABILITY_LEVEL프로퍼티를 5로 사용해야

한다.

고려사항 LOG_FILE_GROUP_COUNT를 1보다 큰 값으로 2개 이상의

LFG를 쓰기 위해서는 TRANSACTION_DURABILITY_LEVEL

프로퍼티를 5로 설정하여 정전시에도 완벽한 지속성(Durability)

를 보장하여야 한다. LOG_FILE_GROUP_COUNT 프로퍼티는

데이터베이스 생성이후 변경이 불가능하기 때문에,

LOG_FILE_GROUP_COUNT 프로퍼티를 2 이상의 값으로 설정한

경우에는 데이터베이스를 다시 생성하기 전까지는

TRANSACTION_DURABILITY_LEVEL 프로퍼티를 5이외의 값

으로 사용할 수 없다는 점에 유의해야 한다.


로그파일그룹 최적화 LFG를 두 개 이상으로 사용하도록 설정한 경우, 다음과 같이 각

LFG의 로그 경로를 물리적으로 서로 다른 위치에 두면 하나의

디스크에 여러 LFG의 로그 기록 요청이 몰리는 것을 방지할 수

있다.

이와 같이 LFG를 물리적으로 서로 다른 디스크에 둘 경우 각각

의 디스크가 동시에 I/O작업을 처리할 수 있어서 시스템의 성능

이 한결 향상된다.


LOG_DIR = /disk1/logs # 로그 경로

( LFG#0 )


( LFG#1 )


( LFG#2 )

ARCHIVE_DIR = /disk1/arch # 아카이브 로그 경로

( LFG#0 )


( LFG#1 )


( LFG#2 )


그리고 다음과 같이 하나의 디스크에 두 개 이상의 LFG를 두도

록 구성하면 디스크의 I/O 처리량(bandwidth)을 더 폭넓게 사용

하게 되어 더 좋은 성능을 낼 수도 있다.

이와같이 일반적으로 하나의 디스크에 두 개 이상의 LFG를 두는

것이 더 좋은 성능을 내지만, 하나의 디스크에 하나의 LFG를 둘

지, 아니면 둘 이상의 LFG를 둘 지는 시스템의 성능과 디스크의

I/O처리량, 시스템의 부하와 밀접한 연관이 있으므로, 실 상황에

서 다양한 LFG 구성으로 직접 성능을 측정해 보는 것이 가장 좋

다.



LOG_DIR = /disk1/logs1 # 로그 경로

( LFG#0 )


( LFG#1 )


( LFG#2 )


( LFG#3 )


( LFG#4 )


( LFG#5 )

ARCHIVE_DIR = /disk1/arch1 # 아카이브 로그 경로

( LFG#0 )


( LFG#1 )


( LFG#2 )


( LFG#3 )


( LFG#4 )


( LFG#5 )


로그파일그룹 할당 시스템에 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 을 사용한다.

한계와 제약사항 LFG기능은 다음과 같은 한계점를 지닌다.

디스크 테이블을 한 번이라도 변경한 적이 있는 디스크 트랜잭션의 경우, 첫 번째 LFG에만 할당되기 때문에, LFG의 갯수와 디스크 트랜잭션의 성능과는 아무런 상관이 없다. 단, LFG를 두 개로 구성 하였을 때, 메모리 트랜잭션과 디스크 트랜잭션의 로그가 두 개의 LFG로 분산되어 LFG가 한 개일때에 비해 디스크 트랜잭션의 성능이 올라갈 수 있다.

LFG기능은 다음과 같은 제약사항을 지닌다.

LFG기능 사용을 위해서는 정전시에도 트랜잭션의 영속성(Durability)를 보장할 수 있도록 TRANSACTION_DURABILITY_LEVEL 프로퍼티를 5 로 설정하여야 한다.

－ LFG갯수를 정하여 데이터베이스를 생성하고 나면, LFG의 갯수를 변경할 수 없다. 하지만, LFG의 로그 경로와 아카이브 경로는 데이터베이스 생성 이후에도 변경이 가능하다.

－ 서로 다른 LFG가 동일한 로그 경로를 공유해서는 안된다. 즉, 모든 LFG의 로그 경로는 서로 달라야 한다.

－ 서로 다른 LFG가 동일한 아카이브 로그 경로를 공유해서는 안된다. 즉, 모든 LFG의 아카이브 로그 경로는 서로 달라야 한다.

주의사항 LFG를 두 개 이상으로 구성하기 위해서는

TRANSACTION_DURABILITY_LEVEL 프로퍼티를 5로 설정하

여 정전시에도 트랜잭션의 영속성(Durability)을 보장해 주어야

한다. 이 경우 LFG를 한 개만 사용하도록 구성하여 데이터베이

스를 재 생성하고 마이그레이션을 하기 전 까지는

TRANSACTION_DURABILITY_LEVEL을 3으로 설정할 수 없다.

이는 다음과 같은 두 가지 제약조건 때문이다.

두 개 이상의 LFG사용을 위해서는


TRANSACTION_DURABILITY_LEVEL을 5 로 설정해야 한다.

－ 데이터베이스 생성 이후에는 LFG수를 변경할 수 없다.

TRANSACTION_DURABILITY_LEVEL 프로퍼티는 시스템의 성

능에 큰 영향을 미치는 프로퍼티이므로 LFG기능 사용에 앞서 이

러한 주의 사항을 고려해야 한다.


12. 알티베이스

모니터링 및 PBT

알티베이스 모니터링 및 PBT 413

알티베이스 모니터링 이 장에서는 알티베이스의 운영상태를 확인하는 방법과 해당 내

용을 분석하는 방법에 대해 설명한다. 알티베이스의 운영상태를

확인하기 위해서는 Performance View를 이용하며 Performance

View에 대한 자세한 설명은 3장 데이터 딕셔너리를 참조하기 바

란다.

세션/Statement 모니터링 알티베이스 운영 중 연결되어 있는 세션에 대한 정보를 확인한다.

하나의 세션은 여러 개의 Statement1를 할당 받아 사용할 수 있

으며 세션 별로 세션 속성이 다르게 지정될 수 있다.

데이터베이스(테이블/인덱스) 정보 모니터링 생성된 테이블에 대한 정보를 확인한다. 전체 데이터베이스에 대

한 정보와 테이블스페이스 각 테이블 및 인덱스 정보를 확인할

수 있다.

메모리 사용량 모니터링 알티베이스 서버가 운영하면서 사용하는 메모리 영역 정보를 확

인한다. 메모리 테이블스페이스의 데이터(버전) 저장 영역 및 인

덱스 저장 영역, 질의 처리를 위한 임시 영역, 세션 정보 저장 공

간, 메모리 버퍼 풀 등의 메모리 사용량 정보를 확인할 수 있다.

상태 모니터링 이중화 상태 정보를 확인한다. 이중화 관련 쓰레드

(Sender/Receiver) 상태와 이중화 데이터 전송 상태를 확인할 수

있다.

1 Statement 는 하나의 SQL 문을 처리하기 위해 내부적으로 사용되는 객체이며 하나의 statement 는

하나의 SQL 문을 처리한다.


알티베이스 PBT 여기에서는 알티베이스 운영 중 발생할 수 있는 여러 가지 문제

상황에 대하여 점검 사항 및 분석 방법에 대해 설명한다. 실제 운

영 환경에서는 다양한 형태의 문제가 발생되며 미리 형태를 예측

할 수 없는 경우도 있으므로 반드시 여기서 설명하는 바와 같이

진행되는 것은 아니나 예측 가능한 범위 내에서 형태별로 나누어

일반적인 방법을 제시하여 문제상황에 대처할 수 있는 정보를 제

공하고자 한다.

예측 가능한 문제 발생 형태는 크게 다음과 같이 생각해 볼 수

있다.

알티베이스 프로세스 비정상 종료 및 재 구동 관련.

알티베이스 서버 응답 상태 관련.

디스크 사용량 관련.

메모리 사용량 관련.

CPU 사용량 관련.

이중화 관련.

응용프로그램 및 쿼리 수행 관련.

일반적인 PBT(Problem Tracking) 절차는 다음과 같다.

문제 유형 판단

알티베이스 관리자 로그

(altibase_XXX.log) 확인

관련정보 수집

(알티베이스 모니터링 도구/시스템 모니터링 커맨드 사용)

원인 분석 및 문제해결


알티베이스 관리자 로그란 “$ALTIBASE_HOME/trc” 디렉터리에

생성되어 있는 텍스트 로그이며 altibase_boot.log,

altibase_id.log, altibase_mt.log, altibase_qp.log, altibase_rp.log,

altibase_sm.log 파일이 있다.

알티베이스 프로세스 비정상 종료 및 재 구동 관련

프로세스 비정상 종료 알티베이스 프로세스가 비정상적으로 종료할 수 있는 원인은 다

음과 같이 생각할 수 있다.

가용 메모리가 부족한 상황

시스템 OS 패닉 상태

이러한 경우 관리자 로그의 에러 메시지를 통해 판단이 가능하며

가용 메모리 부족으로 인해 발생하는 경우를 제외하고는 전문 엔

지니어에게 문의해야 한다.

가용 메모리가 부족한 경우라면 관리자 로그에 “Memory

allocation failed.” 혹은 “Unable to invoke a system function,

shmget().”와 같이 메모리 할당 관련 시스템 콜 에러 메시지가

기록된다. 이런 경우에는 메모리 사용량을 점검해야 하며 불필요

하게 많이 사용하는 부분을 확인하고 이러한 부분이 있다면 해당

부분의 메모리를 해제하여 메모리를 확보하고 원인을 찾아 재발

을 방지하여야 한다. 만일 불필요하게 사용하는 부분이 없다면 시

스템 메모리 업그레이드를 고려해야 한다.

메모리 관련 부분은 다음에 나올 “메모리 사용량 관련” 부분에서

좀 더 자세히 설명하기로 한다.

알티베이스 재 구동 실패 알티베이스 재 구동 시 실패할 수 있는 원인은 다음과 같은 것을

생각해볼수 있다.

동일한 서비스 포트(PORT_NO 프러퍼티)를 사용하는 알티베

이스 프로세스가 이미 존재하는 경우

구동 또는 회복 시 필요한 파일이 없거나 파일에 대한 권한

이나 파일시스템 문제로 인해 접근이 안 되는 경우

관리자 로그에 파일 접근 관련 에러가 발생한다면 해당 파일들

(모든 로그 파일, 모든 로그 컨트롤 파일, 모든 데이터파일)이 존

재하는지를 확인해야 한다. 파일이 존재하고 접근이 가능함에도

불구하고 에러가 발생한다면 파일이 깨졌을 가능성이 있으며 이

런 경우 데이터베이스를 새로 생성하여야 한다.

공유메모리 모드로 사용 시 이전에 사용한 공유 메모리와 파

일상의 데이터베이스 이미지가 호환이 안 되는 경우


공유메모리 호환 문제로 인해 구동이 실패하는 경우 현재 공유메

모리를 삭제하고 다시 구동하여야 한다.

공유메모리를 삭제하는 방법은 알티베이스 공유메모리 관리도구

(shmutil)를 사용하거나 시스템 명령인 “ipcrm” 명령에 의해 가

능하다. “ipcrm” 명령어를 사용하여 삭제할 공유메모리는 “ipcs”

명령어로 검색하면 된다.

시스템 리소스 부족

시스템 리소스 부족으로 인한 구동 실패는 여러 가지 시스템 리

소스 중 어떤 리소스가 부족한지를 확인하여 실제 시스템에 적재

되어 있는 리소스 가용량을 확인하고 시스템 커널 설정을 확인하

여 문제가 있는 부분을 해결해야 한다.

구동 시 주로 문제가 되는 리소스는 메모리, 세마포어이다.

메모리의 경우 시스템 커널 설정에서 한 프로세스 당 사용 가능

한 메모리의 크기, 사용 가능한 공유메모리 크기, 공유메모리 세

그먼트의 최대 크기등을 확인해 봐야 한다.

알티베이스 설정에서 공유메모리 모드로 사용할 경우

“STARTUP_SHM_CHUNK_SIZE”의 설정값이 사용 가능한 공유

메모리 세그먼트의 최대크기를 넘으면 안된다.

세마포어의 경우 IPC 통신을 위해 필요하며 알티베이스 설정 중

“IPC_CHANNEL_COUNT”와 관련이 있다. IPC 통신에 필요한 시

스템 자원을 확인해 보기 위해서는 알티베이스에서 제공하는

“checkipc” 도구를 이용하면 된다.

“checkipc” 도구를 이용하여 검사를 해보면 시스템의 어떤 항목

이 얼마나 필요한지와 실제 커널의 설정값을 확인해 볼 수 있으

며 알티베이스 설정과 시스템 커널 설정을 적절하게 조정하여 해

결이 가능하다.

알티베이스 서버 응답상태 관련 알티베이스 서버가 실제로 질의를 처리하고 있지만 응답속도가

매우 늦다면 서버가 응답이 없는 상태로 오해할 수 있다.

질의 처리 요청 시 응답이 늦는 경우, 이유는 대부분 테이블을 풀

스캔하는 경우와 메모리 부족으로 인해 스와핑이 발생하는 경우

가 있을 수 있으며 세션정보 확인과 시스템 정보를 통해 해당 질

의가 수행 중인지를 확인이 필요하다.

CPU 사용량이 높거나 가용 메모리가 부족하여 스와핑이 발생한

다면 실제로 질의를 처리하고 있는 경우일 가능성이 높다.

자세한 사항은 다음에 나올 “응용프로그램 및 쿼리 수행 관련” 부분에서 좀 더 자세히 설명하기로 한다.


또 다른 원인으로는 디스크 여유 공간이 부족하여 데이터 변경이

나 입력 시 응답이 없는 경우를 생각할 수 있다. 이러한 경우에는

시스템 관리자 로그에 디스크의 여유 공간이 없음을 알리는 에러

메시지가 남게되며 디스크 공간이 확보되기 전까지 응답이 없는

상태로 남아있게 된다. 디스크 공간 부족으로 인한 문제 해결 방

법은 다음에 나올 “디스크 사용량 관련” 부분에서 좀 더 자세히

설명하기로 한다.

이 외에 다른 문제로 알티베이스 서버가 응답이 없는 상태로 남

아있다면 전문 엔지니어에게 문의해야 한다.

CPU 사용량 관련 알티베이스가 갑자기 CPU 사용량이 늘었다면 다음과 같은 상황

들을 의심해 볼 수 있다.

메모리 테이블 질의 처리 시 인덱스를 사용하지 못함

디스크 테이블 질의 처리 시 디스크 사용 과다

메모리 부족으로 인한 스왑핑 발생

시스템 성능 모니터링 도구를 이용하여 메모리 사용량을 확인하

고 가용 메모리가 부족하여 스와핑이 발생한다면 가용 메모리를

확보해야 한다. 이에 대한 내용은 “메모리 사용량 관련” 부분에

서 좀 더 자세히 설명하기로 한다.

메모리 부족 사항이 아니고 질의 처리 시 메모리 테이블 풀 스캔

이나 디스크 테이블에서 디스크를 과다하게 사용한다면 해당 쿼

리나 테이블 등을 튜닝하여 해결이 가능하다.

이에 대한 내용은 다음에 나올 “응용프로그램 및 쿼리 수행 관련” 부분에서 좀 더 자세히 설명하기로 한다.

디스크 사용량 관련

디스크 가용 공간 부족

알티베이스가 운영 중에 디스크 공간이 부족하게 되면 더 이상

데이터 변경작업이 이루어 지지 않고 멈춰있는 현상이 발생 할

수 있다. 이런 경우 먼저 여러 파일 시스템 중 어떤 곳의 공간이

부족한지를 확인해야 한다.

알티베이스가 운영 중에 사용하는 디스크 공간은 다음과 같다.

로그 파일 저장 공간

각 테이블스페이스 파일 저장 공간


알티베이스는 운영 중에 액티브 로그와 아카이브 로그가 지속적

으로 생성되며 액티브 로그 파일은 알티베이스 설정 파일

(altibase.properties) 항목 중 “LOG_DIR”에 설정된 디렉터리에

저장이 되고 아카이브 로그 파일은 데이터베이스 모드가

ARCHIVE LOG모드로 운영될 경우 자동으로 “ARCHIVE_DIR”

에 설정된 디렉터리에 저장된다. 액티브 로그의 경우는 디스크 공

간이 부족하여 더 이상 저장이 불가능 하면 알티베이스가 멈추게

되며 이런 경우 로그 파일과 로그컨트롤파일을 지우게 되면 더

이상 복구가 불가능해지므로 해당 파일시스템의 크기를 늘이거나

이외에 다른 불필요한 파일이 있다면 삭제하여 디스크 공간을 확

보해야 한다. 아카이브 로그의 경우에는 설정 파일의

“ARCHIVE_FULL_ACTION” 항목의 설정값이 0인 경우 아카이

브 로그를 저장하지 않고 계속 운영되게 되며, 1인 경우 해당 파

일시스템의 가용공간이 확보될 때 까지 멈춰있게 된다.

“LOG_DIR” 디렉터리에 로그 파일의 개수가 많아져 로그 저장

공간이 부족해 진 경우 먼저 관리자 로그 파일을 확인하여 체크

포인트가 정상적으로 이루어 지고 있는지를 확인해야 하며 알티

베이스 설정 파일 내에 “CHECK_POINT_INTERVAL_IN_SEC”

항목과 “CHECK_POINT_INTERVAL_IN_LOG” 항목의 설정이

적절한지 확인하여야 한다. 만일 체크포인트가 정상적으로 이루어

지고 있음에도 불구하고 아카이브 로그 파일들이 “LOG_DIR” 디

렉터리에 계속 남아 있다면 이중화 전송 상태를 확인해야 한다.

이중화 전송이 계속 밀리고 있거나 전송 불가능 상태라면 아카이

브 로그를 처리하지 못하고 “LOG_DIR”에 계속 보관해야 하므로

로그 저장 공간이 부족해 질 수 있다.

이중화 관련 문제 해결 방법은 다음에 나올 “이중화 관련” 부분

에서 좀 더 자세히 설명하기로 한다

메모리 테이블스페이스와 각 시스템 테이블스페이스는 설정 파일

중 “MEM_DB_DIR” 항목에 설정된 디렉터리에 저장되게 된다.

테이블스페이스 관련 디스크 부족 현상이라면 이 부분 또는 사용

자가 생성한 테이블스페이스 파일이 저장된 공간을 확인해야 한

다. 테이블스페이스 저장하는 파일 시스템은 최소 해당 테이블스

페이스의 NEXT SIZE 크기 이상 여유 공간이 있어야 한다.

메모리 테이블스페이스의 저장 공간은 체크포인트가 수행될 때

실제로 기록이 되기 때문에 메모리 상에 존재하는 테이블스페이

스 크기 이상 여유 공간이 필요하다.

메모리 사용량 관련 알티베이스 운영 중 가용메모리가 부족해 진다면 응답시간이 매

우 느려질 수 있으며 알티베이스가 비정상적으로 종료될 수 있다.

이런 경우가 발생된다면 알티베이스가 사용하고 있는 메모리 영

역을 검사하여 해당 크기가 적절한지를 판단하고 불필요하게 사


용되고 있는 부분을 제거해야 한다. 만일 불필요하게 사용하고 있

는 영역이 없다면 메모리 증설을 고려 하여야 한다.

알티베이스가 운영 중에 사용하는 메모리 공간은 크게 나누어 보

면 다음과 같다.

메모리 테이블스페이스

임시 메모리 공간

메모리 버퍼

메모리 테이블스페이스에는 메모리 테이블의 실제 레코드 및

MVCC로 인한 이전 레코드 버전이 저장된다.

임시 메모리 공간은 메모리 테이블에 생성된 테이블의 인덱스와

메모리 테이블 조회 시 정렬공간, 세션들의 정보를 저장하는 용도

등으로 사용된다.

메모리 버퍼는 디스크 테이블에 대한 연산 및 정렬을 위해 사용

되는 공간이다.

메모리 과다 사용이 의심된다면 일정기간 동안 생성되는 스테이

트먼트의 개수와 임시 메모리 영역의 크기, 메모리 테이블스페이

스의 사용량, 메모리 테이블의 인덱스 크기 등을 모니터링 하여

증가량을 확인하여야 하며 이와 함께 “ps”나 “top”과 같은 시스

템 모니터링 명령으로 프로세스의 크기가 지속적으로 증가되는

지 확인해 보아야 한다.

알티베이스가 처음 가동된 이후에 일정 기간 동안은 임시 메모리

영역과 여러 버전의 레코드 생성, 세션 정보의 증가로 인해 메모

리 사용량이 증가할 수 있으며 이는 정상적인 경우이다.

만일 일정 기간 운영 이후에도 지속적으로 증가한다면 메모리 누

수와 같은 이상이 있는지를 의심해 볼 수 있으며 이러한 경우 전

문 엔지니어에게 문의를 해야 한다.

이중화 관련 이중화 관련하여 발생 할 수 있는 문제는 다음과 같은 형태가 있

다.

이중화 시작 실패

이중화 반영 속도가 매우 느림

이중화 중인 테이블의 건수가 서로 틀림

이중화 전송에 문제가 발생되면 로그 저장 공간에 아카이브 로그

파일이 계속 남아있게 되어 가용 공간이 부족해지고 이로 인해

서비스가 안되고 멈춰있는 현상이 발생될 수 있다.


이중화 관련 문제가 발생됐다면 먼저 관리자 로그 파일에 이중화

관련 에러 메시지가 기록되어 있는지 확인하고 해당 내용을 전문

엔지니어에게 전달해야 한다.

한쪽 시스템에 장애가 발생하고 장애 상황이 장시간 지속되면 이

중화 데이터 전송을 하지 못하여 로그 저장 디렉터리의 가용 공

간이 부족해 지는 현상이 발생한다. 따라서 장시간 문제 해결이

어려운 경우에는 이중화를 중단하고 이중화 객체를 삭제하여 현

재 운영중인 시스템에 문제가 생기지 않도록 하는 것을 고려해야

하며 이런 경우 장애 상황이 해제된 이후 장애 발생 시스템의 데

이터 복구 작업이 추가적으로 필요하다. 데이터 복구 방법으로는

iLoader 도구를 이용하는 방법과 이중화의 시작 모드 중 SYNC

모드를 이용하는 방법이 있다.

만일 이중화 객체 삭제가 어려운 경우 로그 저장 디렉터리의 가

용 공간을 지속적으로 확인하여 모자란 경우 확보를 해주어야 한

다.

마찬가지로 이중화 네트워크 라인의 문제가 발생했다던지 이중화

에 문제가 생겨 장시간 이중화가 연결되지 못하는 경우에도 동일

한 조치가 필요하다.

응용프로그램 및 쿼리 수행 관련 응용프로그램 및 쿼리 수행에 관해 생각해 볼 수 있는 문제 상황

은 다음과 같다.

응용프로그램에서 알티베이스로의 접속 실패

응용프로그램에서 알티베이스로 쿼리 요청 이후 멈추어 있거

나 정해진 시간 동안 처리하지 못하여 타임아웃 발생

알티베이스 접속 실패

응용프로그램에서 접속이 실패한다면 알티베이스 질의 처리 도구

인 isql을 이용하여 접속을 시도해봤을 때 정상적으로 접속이 되

는지 확인한다. 알티베이스에서는 접속 시 3가지의 접속 방식을

제공하기 때문에 (TCP/IP 방식, socket domain 방식, IPC 방식)

응용프로그램에서 사용하고 있는 접속 방식을 사용하여 시험해봐

야 한다.

접속 방식을 설정하는 방법은 ISQL_CONNECTION 환경변수를

지정하여 가능하다. (TCP,UNIX,IPC)

만일 접속이 성공된다면 응용프로그램 안에서 접속정보 설정 시

문제가 있는 것이므로 해당 부분의 오류를 찾아 해결하면 되며,

접속이 성공하지 못한다면 다음 사항들을 고려해 볼 수 있다.

접속된 세션 수가 알티베이스 설정 항목 중 MAX_CLIENT

설정값을 초과함.


접속 방식이 IPC 방식인 경우 IPC 방식으로 접속된 세션 수

가 IPC_CHANNEL_COUNT 설정값을 초과함.

응답이 없거나 타임 아웃으로 인해 세션이 끊어짐

질의 처리 시 수행 속도가 느려 응답이 없는 경우 다음과 같은

상황을 생각해 볼 수 있다.

메모리 가용량이 부족하여 스왑핑이 발생

테이블을 풀 스캔하여 처리 성능이 저하

특정 테이블에 록을 요청하고 기다리고 있는 상태

시스템 성능 모니터링 도구를 이용하여 CPU 사용량과 메모리 사

용량을 점검하여 메모리 부족 상황인지를 먼저 판단해야 하며 만

일 메모리가 부족한 상황이라고 판단되면 “메모리 사용량 관련”

부분을 참고하여 문제를 해결하여야 한다.

메모리가 부족한 상황이 아니면서 CPU 사용량이 높다면 현재 처

리 중인 쿼리 중 테이블 풀 스캔을 유발하는 쿼리가 있는지를 확

인하여야 한다.

현재 수행 중인 쿼리 목록을 확인하려면 isql을 접속하여

V$STATEMENT 테이블의 QUERY 칼럼을 조회하면 된다.

수행 중인 쿼리 중 의심되는 쿼리를 선정하여 실행 계획을 확인

하고 문제가 있다면 튜닝을 해야 한다.

쿼리 튜닝에 대한 자세한 내용은 이 매뉴얼의 “8장. SQL 튜닝”

부분을 참조하기 바란다.

위의 두 경우에 해당 하지 않는다면 록을 기다리고 있는 상태를

의심할 수 있으며 현재 록 정보를 확인하고 특정 세션이 불필요

하게 록을 획득하고 있는 상태로 지속되고 있다면 해당 세션을

강제로 종료하여 문제 해결이 가능하다.

A. 부록: Trace Log 423

A. 부록: Trace Log


Trace Log

알티베이스 서버에서 수행되는 SQL문의 정보, 에러 메시지 종류 또는 SQL 문의

수행 시간 등을 altibase_boot.log 파일에 기록하게 할 수 있는 프로퍼티로서

다음과 같은 내용을 altibase_boot.log 파일에 기록할 수 있다. 기본 값은 0이며,

임의의 trace log를 사용하기 위해 1을 설정한다.

프로퍼티 파일에 명시된 값은 ALTER SYSTEM 문을 이용하여 변경할 수 있다.

TRCLOG 설 명 TRCLOG_SET_CONFLICT_LOG altibase_rp.log에 receiver 측에 발생한

conflict message 기록 TRCLOG_SET_INSERT_SM_LOG altibase_rp.log에 receiver 측에서

insertXLog 시 SM에서 발생하는 error message 기록

TRCLOG_DML_SENTENCE altibase_boot.log에 수행한 DML과 where 절의 predicate 분류 상태 기록

TRCLOG_DETAIL_PREDICATE explain plan 기능 사용 시 where 절의 predicate 분류 상태도 함께 display

TRCLOG_SEQ_ITERATOR sequential fetch 시 sequential iterator의 trace 정보 기록

TRCLOG_SET_LOCK_TIME lock 설정 시간 기록 TRCLOG_SET_HBT_LOG 현재 HeartBeat Thread의 동작 유무 (데이

터 통신 장애 감지)를 판단할 수 있다. 또한, HeartBeat Thread에 등록된 모든 호스

트에 대한 리스트를 주기적으로 altibase_rp.log에 남긴다.

TRCLOG_PSM_ERROR_LINE PSM 관련 SQL문(create, procedure, execute procedure 등) 수행 시 오류 메시

지를 altibase_boot.log에 남긴다.

찾아보기 425

찾아보기

ㄱ

객체 접근 권한........................... 167, 168 권한 ...................................................... 166 권한 해제............................................. 168 그룹 연산............................................. 296 그룹 커밋............................................. 394

ㄴ

노아카이브로그................................... 241 논리적 백업................................. 240, 405

ㄷ

다중 버전 동시성 제어 기법........... 210 단일 비저장 노드............................... 316 단일 저장 노드................................... 329 대용량 메모리 테이블....................... 134 데이터 딕셔너리................................... 15 데이터 테이블스페이스......................... 4 데이터베이스 객체............................. 130 데이터베이스 관련 프로퍼티............... 7 데이터베이스 생성................................. 4 데이터베이스 정보 모니터링........... 408 데이터베이스 종료................................. 7 데이터베이스 트리거......................... 131 디렉토리 .............................................. 132 디스크 테이블..................................... 134

ㄹ

로그 파일................................................. 5 로그 플러쉬 쓰레드........................... 401 로그파일 생성 쓰레드....................... 401 로그파일그룹....................................... 400 롤백 ...................................................... 205

ㅁ

매체복구 .............................................. 243 메모리 사용량 모니터링................... 408

메모리 테이블 .....................................134 메모리 테이블 스페이스 ........................4 메타 테이블 ...........................................16 물리적 백업 .........................................240

ㅂ

베이스 테이블 .....................................151 복합키 인덱스 .....................................148 불완전 복구 .........................................244 뷰 ...................................................131, 151

ㅅ

사용자 ...........................................133, 164 상태 모니터링 .....................................408 성능 뷰 ...................................................61 세그먼트 ...............................................177 세션/statement 모니터링 .....................408 스키마 객체 .........................................130 시노님 ...........................................131, 156 시스템 접근 권한 .......................166, 168 시스템 테이블 .....................................134 시퀀스 ...........................................131, 153 실행 계획 .............................................310 실행 계획 트리 ...................................262 실행 노드 .............................................313 실행기 ...................................................265

ㅇ

아카이브 로그 쓰레드........................401 아카이브로그 모드 .............................241 알티베이스 구동 ...................................12 알티베이스 모니터링 .........................408 알티베이스 종료 ...................................14 알티베이스 problem tracking ..............409 언두 테이블스페이스 .....................4, 191 영구 저장 인덱스 ...............................148 오프라인 백업 .....................................250 오프라인 백업 .....................................241 온라인 백업 .........................................241 완전 복구 .............................................244


외래 키 제약조건 ...............................144 유일 키 인덱스 ...................................147 유일 키 제약조건 ...............................144 이중화 ...................................................132 이중화된 테이블 .................................135 이진 비저장 노드 ...............................339 이진 저장 노드 join ...........................347 익스텐트 ...............................................178 인덱스 ...........................................131, 147 일반 사용자 테이블 ...........................134 임시 테이블스페이스 .....................4, 189

ㅈ

자동복구 ...............................................243 잠금 .......................................................207 저장 프로시저 .....................................158 저장 프로시저 및 저장 함수 ...........131 저장 함수 .............................................158 저장점 ...................................................206 정규화 ...................................................272 제약조건 ...............................................130 조건절 ...................................................274 죠인 .......................................................292 질의 처리 .............................................267 질의 최적화 .........................................269 집합 연산 .............................................300

ㅊ

최적화기 ...............................................266

ㅋ

칼럼 제약조건 .....................................144 커밋 .......................................................205 큐 테이블 .............................................142

ㅌ

테이블 ...................................................130 테이블 제약조건 .................................144 테이블스페이스 ...........................132, 172 테이블스페이스 백업 .........................198 테이블스페이스 복구 .........................198 트랜잭션 ...............................................204

트리거 ...................................................162 트리거 액션 .........................................162 트리거 이벤트 .....................................162 트리거 조건 .........................................162

ㅍ

페이지 ...................................................178 프라이머리 제약조건 .........................144 프로젝션 ...............................................302 프로퍼티 ...................................................7

ㅎ

힌트 .......................................................350

Ａ

AGGR 실행 노드................................324 AGGREGATION node .........................362 ALTER TABLESPACE 문 ..................193 ANTI-OUTR-JOIN node.......................363 AOJN 실행 노드 .................................345

Ｂ

BAG-UNION node................................365 BCB.......................................................224 b-tree 인덱스........................................147 Buffer Control Block.............................224 Buffer frame ..........................................224 Buffer pool ............................................224 BUNI 실행 노드 .................................347

Ｃ

CACHE .................................................154 CNF .......................................................351 commit...................................................205 composite index.....................................148 CONC 실행 노드 ................................346 CONCATENATION node ....................365 constant filter .........................................279 constraint ...............................................130 cost ........................................................351 COUNT node ........................................366 CREATE TABLESPACE 문 ...............182

찾아보기 427

CREATE TEMPORARY TABLESPACE 문 ...................................................... 189

CUNT 실행 노드................................ 328 CYCLE ................................................. 154

Ｄ

data.......................................................... 15 database objects .................................... 130 directory ................................................ 132 disk table ............................................... 134 distinct................................................... 299 DISTINCT node.................................... 367 DISTINCT_HASH................................ 353 DISTINCT_SORT ................................ 353 DNF ...................................................... 351 DROP TABLESPACE 문.................... 200 durability level ...................................... 220

Ｅ

exclusive lock........................................ 207 execution plan ....................................... 356 execution plan tree ................................ 262 executor................................................. 265 extent..................................................... 178

Ｆ

FILT 실행 노드 .................................. 320 filter....................................................... 279 FILTER node ........................................ 368 FIXED................................................... 137 Flush List .............................................. 226 Flush Thread ......................................... 227 FOJN 실행 노드 ................................. 345 foreign key 제약조건 .......................... 144 Free List ................................................ 226 FULL SCAN......................................... 353 FULL-OUTER-JOIN node ................... 369

Ｇ

garbage collector ................................... 191 GRAG 실행 노드 ............................... 333 grant ...................................................... 167 GRBY 실행 노드................................ 322 GROUP BUCKET COUNT ................. 352 Group Commit ...................................... 394 GROUP_HASH .................................... 352

GROUP_SORT......................................352 GROUP-AGGREGATION node...........370 GROUPING node ..................................371

Ｈ

HASH 실행 노드.................................332 HASH BUCKET COUNT.....................352 HASH node............................................372 hash-based join ......................................295 HIER 실행 노드 ..................................329 HIERARCHICAL QUERY node ..........373 hint .........................................................350 HSDS 실행 노드 .................................334

Ｉ

INCREMENT BY..................................154 index ..............................................131, 147 INDEX...................................................353 INDEX ASC ..........................................353 INDEX DESC........................................353 intensive exclusive lock .........................207 intensive exclusive shared lock..............207 intensive shared lock..............................207

Ｊ

join .........................................................292 JOIN 실행 노드...................................340 JOIN node..............................................376

Ｋ

key filter.................................................279 key range................................................279

Ｌ

LEFT-OUTER-JOIN node.....................377 limit........................................................301 LIMIT-SORT node ................................378 LMST 실행 노드.................................338 lock ........................................................207 Log File Creation Thread.......................401 Log Flush Thread...................................401 LOJN 실행 노드..................................344


Ｍ

MATERIALIZATION node..................379 materialized node...................................361 memory table .........................................134 merge join ..............................................296 Message queue table ..............................142 meta 단계 .................................................6 MGJN 실행 노드 ................................343 MINVALUE..........................................154 Multiplexing ..........................................108 MVCC ...................................................210

Ｎ

nested loop join......................................293 NO INDEX............................................353 NO_PUSH_SELECT_VIEW ................353 non-materialized node ...........................361 normalization .........................................272 NOT NULL 제약조건 .........................144 NULL 제약조건...................................144

Ｏ

object privilege ......................................167 offline 백업...........................................250 optimization ...........................................269 optimizer................................................266 order by..................................................300 ORDERED ............................................351

Ｐ

page........................................................178 persistent index ......................................148 plan tree .................................................356 primary key 제약조건 ..........................144 privilege.................................................166 process 단계 .............................................6 PROJ 실행 노드 ..................................321 PROJECT node......................................381 projection...............................................302 properties ...................................................7 push selection 기법 ..............................275 PUSH_SELECT_VIEW........................353

Ｑ

query processing....................................267 QUEUE table.........................................142

Ｒ

replication..............................................132 revoke ....................................................168 rollback..................................................205 r-tree 인덱스 ........................................147 rule.........................................................351

Ｓ

savepoint................................................206 SCAN 실행 노드 ................................316 SCAN node............................................382 schema objects.......................................130 SDIF 실행 노드 ..................................348 segment..................................................177 sequence ........................................ 131, 153 SET BUCKET COUNT ........................352 SET-DIFFERENCE node......................384 SET-INTERSECT node ........................385 shared lock.............................................207 shutdown abort ....................................14 shutdown immediate ...........................14 shutdown normal..................................14 SITS 실행 노드 ...................................348 SORT 실행 노드 .................................330 SORT MERGE JOIN node....................380 SORT node............................................387 sort-based join .......................................294 SQL 튜닝 .............................................262 START WITH.......................................154 startup 단계 ............................................13 startup process ...........................................6 startup service..........................................12 STOR 실행 노드 .................................337 stored function.......................................158 stored procedure ....................................158 strore procedure or funuction ................131 subquery ................................................303 subquery filter........................................280 synonym ................................................131 synonym ................................................156 SYS 사용자..........................................164 SYS_COLUMNS_ ..................................18 SYS_CONSTRAINT_COLUMNS_ .......23

찾아보기 429

SYS_CONSTRAINTS_.......................... 21 SYS_DATABASE_................................ 25 SYS_DIRECTORIES_ ........................... 26 SYS_GRANT_OBJECT_....................... 27 SYS_GRANT_SYSTEM_...................... 29 SYS_INDEX_COLUMNS_ ................... 30 SYS_INDICES_ ..................................... 32 SYS_PRIVILEGES_ .............................. 34 SYS_PROC_PARAS_............................ 38 SYS_PROC_PARSE_ ............................ 40 SYS_PROC_RELATED_....................... 41 SYS_PROCEDURES_ ........................... 35 SYS_REPL_HOSTS............................... 45 SYS_REPL_ITEMS................................ 46 SYS_REPLICATIONS_......................... 43 SYS_SYNONYMS_............................... 48 SYS_TABLES_ ...................................... 49 SYS_TBS_USERS_................................ 51 SYS_TRIGGER_DML_TABLES_ ........ 54 SYS_TRIGGER_STRINGS_ ................. 55 SYS_TRIGGER_UPDATE_COLUMNS_

............................................................ 56 SYS_USERS_................................... 52, 57 SYS_VIEW_PARSE_ ............................ 59 SYS_VIEW_RELATED_....................... 60 SYS_VIEWS_......................................... 58 -sysdba ...................................................... 5 sysdba 시스템 권한.............................. 12 system 테이블스페이스.................... 176 system privilege ............................ 166, 168 system table........................................... 134 system tablespace............................ 176 SYSTEM_ 사용자 ............................... 164

Ｔ

table....................................................... 130 tablespace...................................... 132, 172 temporary tablespace............................. 189 TIMESTAMP 제약조건...................... 144 trace log................................................. 418 Transaction Durability .......................... 218 trigger............................................ 131, 162 trigger action ......................................... 162 trigger envent ........................................ 162 trigger restriction................................... 162

Ｕ

undo tablespace..................................... 191 unique index.......................................... 147

unique key 제약조건............................144 USE_HASH...........................................351 USE_NL ................................................351 Used List................................................226 user.................................................133, 164 user 테이블스페이스..........................176 user table................................................134 user tablespace..................................176 USER_MERGE .....................................351 USER_SORT.........................................351

Ｖ

V$ PROCTEXT.......................................98 V$ALLCOLUMN ...................................66 V$ARCHIVE...........................................67 V$BUFFPAGEINFO...............................68 V$BUFFPOOL_STAT ............................71 V$DATABASE .......................................73 V$DATAFILES.......................................76 V$DISKGC..............................................79 V$DISKTBL_INFO ................................80 V$FLUSHINFO.......................................82 V$INDEX................................................83 V$INSTANCE.........................................84 V$LATCH ...............................................85 V$LFG.....................................................86 V$LOCK..................................................89 V$LOCK_STATEMENT........................93 V$LOCK_WAIT .....................................90 V$LOG ....................................................91 V$MEMGC .............................................94 V$MEMSTAT.........................................95 V$MEMTBL_INFO ................................81 V$MUTEX ..............................................96 V$PALNTEXT........................................97 V$PROPERTY ........................................99 V$REPEXEC.........................................100 V$REPGAP ...........................................101 V$REPRECEIVER................................103 V$REPSENDER....................................105 V$SEGMENT........................................104 V$SEQ...................................................107 V$SERVICE_THREAD........................108 V$SESSIONMGR .................................114 V$SQLTEXT.........................................117 V$SSESSION ........................................109 V$STATEMENT...................................115 V$TAB ....................................................61 V$TABLE..............................................118 V$TABLESPACES...............................119 V$TRANSACTION ..............................123


V$TRANSACTION_MGR ...................126 V$UNDO_BUFF_STAT.......................127 V$VERSION.........................................128 VARCHAR 데이터 타입....................137 VARCHAR datatype .............................137 VARIABLE...........................................137 view ...............................................131, 151

VIEW 실행 노드.................................325 VIEW Node...........................................388 VIEW-SCAN node................................389 VMTR 실행 노드................................336 VSCN 실행 노드 ................................326

altibase administrator's manualsupport.altibase.com/kr/download?attachpath=/altra/... · z 제...

Documents