안녕하세요. 알티베이스입니다. 문의주신 사항에 대해 답변드립니다. 3.5.9 버젼은 dbadmin으로 접속하여 status 명령을 사용하여 모니터링이 가능합니다. 1. dbadmin 접속 [hsyang@r920 conf]$ dbadmin dbadmin Utilit

모니터링 쿼리는 다음과 같습니다. > status가 abort인 상황이 rollback 상황 > query 를 통해 해당 쿼리 확인 가능 > 해당 쿼리가 들어오는 세션의 정보 등 set linesize 900; set colsize 50; set vertical on; SELECT tx.id t

고속 트랜잭션 처리를 위한 효율만점 DB, 메인 메모리 데이터베이스 구축 (2) 메메인인메메모모리리 데데이이터터베베이이스스 설설치치와와 응응용용 프프로로그그램램 작작성성 이번 호에서는 메인메모리 데이터베이스 시스템의 설치 방법과 각 플랫폼에 최적화된 성 능 튜닝을 위한 운영체제 환경 설정을 알아본다. 또한, 적용 업무에 따른 데이터베이스 시 스템을 최적화하기 위해 데이터베이스 관련 프로퍼티를 설정하는 방법과 데이터베이스 관리 툴을 사용한 모니터링을 통해 운영 환경을 최적화하는 방법을 살펴 본다. 마지막으로 메인 메모리 데이터베이스 특성을 활용한 응용 시스템 구축을 위하여, 다양한 프로그래밍 인터페 이스를 이용한 기본적인 프로그램 개발 방법을 알아본다. 연재순서 2002/02 메인메모리 데이터베이스 이해 2002/03 메인메모리 데이터베이스 설치와 응용 프로그램 작성 2002/04 실시간 이중화를 활용한 응용 구축 2002/05 기존 데이터베이스와 연동 응용 구축 현재까지 메인메모리 데이터베이스 시스템은 대형 서버부터 내장형 리눅스 시스템까지 다 양한 플랫폼에 이식되어 있으며, 동일한 프로그램 인터페이스를 통한 응용 프로그램 작성 방법을 사용자에게 제공한다. 그러나, 플랫폼에 따른 운영체제의 특수성이 존재하므로, 최적 의 성능을 위해서는, 설치시 각 운영체제에 종속적인 환경 설정이 필요하다. 이러한 최적화 과정은 메인메모리 데이터베이스 시스템 메이커마다 다르므로, 편의상 알티베이스를 예로 들어 설명한다. 설설치치하하기기 설치는 세 단계로 구성되는데, 먼저 패키지에 포함된 인스톨 프로그램을 실행시켜 필요 한 실행 파일과 라이브러리를 설치하는 단계, 플랫폼에 따른 운영체제별 환경 설정 단계, 데이터베이스 운영 환경 설정 단계로 나뉘어 진다. (1) 프로그램 설치 패키지에는 알티베이스 서버, 각종 유틸리티 프로그램, 프로그램 작성을 위한 라이브러 리, 예제 스키마 및 프로그램, 전자 매뉴얼이 포함되어 있다. 먼저, 데이터베이스 관리용 사 용자를 생성하고, 인스톨 프로그램(install.sh)을 실행시키면, [그림 1] 과 같은 디렉토리 구 조의 홈 디렉토리가 생성된다. $ALTIBASE_HOME bin conf lib includemsg dbs logssample trc audit [그림 1] 홈 디렉토리 구조 주요 디렉토리를 살펴 보면, bin 은 서버를 포함한 실행파일을, conf는 운영환경 설정 프로퍼티 파일을, include와 lib은 응용 프로그램용 헤더파일과 라이브러리를, dbs 는 데이터 베이스 파일을, logs는 로그 파일을, trc는 서버운영 로그를 저장한다. 관리용 사용자와 일반 사용자의 시작 쉘 파일에 서버운영에 필요한 환경변수를 선언한 다. bash쉘을 사용했을 경우, .bashrc 파일에 [그림 2]와 같이 선언한다. $ALTIBASE_HOME 은 알티베이스가 설치된 디렉토리를 지정하는 것으로, 서버를 관리하거나 응용 프로그램을 작성하고 운영할 때, 참조되는 환경변수이다. ALTIBASE_HOME = /home/altiadmin/altibase_home PATH=$PATH:$ALTIBASE_HOME/bin CLASS_PATH=.:$ALTIBASE_HOME/lib/Altibase.jar:$CLASS_PATH LD_LIBRARY_PATH=$ALTIBASE_HOME/lib: $LD_LIBRARY_PAH [그림 2] 환경변수 선언 공유 라이브러리를 사용하는 경우는, LD_LIBRARY_PATH를 지정해야 하며, 자바를 이용 하는 경우는 CLASS_PATH를 통해 JDBC드라이버의 경로를 지정해야 한다. (2) 운영체제 종속 환경 설정 플랫폼에 따라 운영체제의 세부 특성이 달라지므로, 최적화된 성능을 위해서는, 각 운 영체제 특성에 맞도록 운영체제 파라미터를 변경할 필요가 있다. 이러한 파라미터에는 프로 세스당 메모리 한계, 쓰레드 한계, 파일 디스크립터 한계, 공유 메모리 및 세마포어 한계 등 이 있다. 구체적인 설정 방법은 운영체제별로 다르므로, 자세한 내용은 매뉴얼을 참조하길 바란다. (3) 프로퍼티 파일 설정 데이터베이스 관리자는 데이터베이스 시스템의 운영환경을 최적화 필요가 있는데, 이러 한 데이터베이스 성능과 운영에 관한 일반적인 설정은 conf 디렉토리의 altibase.properties 파일에 정의되어 있다. 이 파일에 정의된 각 프로퍼티는 데이터베이스 구성, 세션 연결, 트 랜잭션, 로그, 이중화에 관한 특성을 관리자가 세밀하게 제어할 수 있도록 허용한다. 특히, 관리자는 이 프로퍼티의 설정을 통해 데이터베이스 성능을 최적화 할 수 있다. 몇 가지 주요 프로퍼티를 살펴보면, [그림 3]에서 DB0_DIR, DB1_DIR과 LOG_DIR은 데 이터베이스 파일과 로그 파일을 저장하는 디렉토리를 각각 지정하는 것으로 ? 는 $ALTIBASE_HOME의 dbs와 logs 디렉토리를 지정하는 기본값이다. 필요한 경우, 이들 디 렉토리를 별도의 물리적 디스크로 지정함으로써, 대량의 트랜잭션 처리시 I/O WAIT율을 적 정 수준으로 유지할 수 있다. DB0_DIR=? DB1_DIR=? LOG_DIR=? PORT_NO=20521 MAX_THREAD=1024 MAX_DB_SIZE=4G CHECKPOINT_INTERVAL_IN_SEC=600 REPLICATION_PORT_NO=21521 [그림 3] 프로퍼티 설정 PORT_NO는 클라이언트와의 통신을 위한 포트 번호를 정의하며, REPLICATION_PORT_NO는 이중화 기능을 설정하는 것으로 상대 서버와 이중화 데이터를 송수신 하기위한 전용 포트 번호를 정의한다. MAX_THREAD는 데이터베이스 서비스를 위한 서버측의 서비스 풀을 구성하는 쓰레드 개수를 지정한다. 플랫폼 및 운영환경을 고려하여, 최적의 쓰레드 개수를 지정하는 것이 성 능상 중요하다. 필요한 데이터의 양에 따라 서버는 데이터베이스의 크기를 동적으로 늘리는 데, 관리자는 운영환경에 따라 너무 많은 시스템 자원을 소모하는 것을 막기 위해 MAX_DB_SIZE로 데이터베이스의 최대 한계를 지정할 수 있다. CHECK_POINT_INTERVAL_IN_SEC은 메인메모리 데이터베이스와 디스크 데이터베이스 파일간의 검사점 간격을 지정하는 것으로 I/O 처리율이 낮은 시스템의 경우 이 값을 크게 함으로써, I/O 처리에 따른 시스템 성능 저하를 피할 수 있다. 이외에도 데이터베이스의 성능을 최적화하기 위한 다양한 프로퍼티가 존재하므로, 관리 자는 매뉴얼을 참조하여 시스템에 가장 알맞게 프로퍼티를 설정할 수 있다. 데데이이터터베베이이스스 생생성성과과 삭삭제제하하기기 메인메모리 데이터베이스는 주 데이터베이스가 메인메모리에 위치하며, 1차 백업으로 디스크에 데이터베이스 파일을 유지한다. 따라서, 데이터베이스 생성은 먼저 1차 백업인 데 이터베이스 파일을 생성하는 것으로 시작한다. createdb 유틸리티를 이용해서 생성할 데이터베이스의 크기를 Mbyte 단위로 지정하거 나 페이지 개수로 지정하면, 백업 데이터베이스 파일과 로그앵커 및 초기 로그파일이 생성 된다. 이때, 데이터베이스의 메타 정보를 관리하는 시스템 정의 테이블이 생성된다. [리스트 1]은 100 Mbyte의 데이터베이스를 생성하는 결과이다. shell> createdb -M 100 CreateDB: Release 2.0.0 - Production on Nov 26 2001 10:47:20 (c) Copyright 2001 ALTIBase Corporation. All rights reserved. DB Info (Page Size = 32768) (Page Count = 3200) (File Size = 104857600) Ready for Creating Database [mydb] (y/N) ?y BEGIN: Database Creation .... SUCCESS: Database Creation Completed.. BEGIN: QP Meta Information Creation .... SUCCESS: QP Meta Information Creation Completed. BEGIN: DB Writing (Page Count = 3200) SUCCESS: DB Writing Completed. All Done. shell> [리스트 1] 데이터베이스 생성 메타 테이블은 테이블, 컬럼, 인덱스, 제약조건, 저장 프로시져 등의 정보를 관리하는 테이블로 구성된다. [표 1]은 몇가지 주요 메타 테이블에 대해 설명한다. 메타 테이블 명 설명 qpm_databases_ 데이터베이스 이름 등 데이터베이스 정보를 관리 qpm_users_ 사용자 id, password등 사용자 정보를 관리 qpm_tables_ 테이블명, 사용자 id 등 테이블 정보를 관리 qpm_fields_ 테이블 id, 컬럼명 등 컬럼 정보를 관리 qpm_constraints_ 컬럼 id, 제약조건 타입 등 제약조건을 관리 qpm_indices_ 인덱스 명, 컬럼 id 등 인덱스 정보를 관리 qpm_procedures_ 파라미터 이름, 타입 등 저장 프로시져 정보를 관리 qpm_replications_ 이중화명, 테이블 id 등 이중화 정보를 관리 [표 1] 메타 테이블 데이터베이스를 삭제하는 경우는, destroydb 유틸리티를 사용한다. 이 유틸리티를 실행 하면, 데이터베이스 파일과 관련 로그 파일들을 전부 삭제하게 된다. 서서버버 시시작작과과 종종료료 dbadmin 툴은 서버의 시작(startup)과 종료(shutdown), 모니터링(status) 기능을 수행 하는 유틸리티이다. Startup 명령을 수행했을 때, 서버가 내부적으로 하는 일을 살펴보자. [그림 4]와 같이 서버는 기동을 할 때, ○ 1 altibase.properties 파일에 정의된 데이터베이스 운영환경을 설정하고, ○ 2 데이터베이스 일관성 검사를 통해 서버의 비정상 종료 등으로 인 한 데이터베이스의 손상을 복구하는 회복과정을 수행한다. ○ 3 회복과정에서 서버는 데이터 베이스 파일의 데이터를 바탕으로 로그 파일의 로그를 해석하여 재수행(redo)과 취소(undo) 연산을 수행한다. 데이터베이스의 일관성이 확보되면, ○ 4 디스크에 있는 데이터베이스 파일 을 메모리로 로딩한다. 마지막으로 ○ 5 서비스 쓰레드와 서버 커넥션풀을 초기화하여 서비스 를 수행할 준비를 한다. 알티베이스 서버 ○ 5 ○ 3 ○ 2 ○ 4○ 1 서비스 쓰레드 서버 커넥션풀 데이터베이스 로그 파일 데이터베이스 파일 프로퍼티 파일 [그림 4] 서버 시작 절차 이러한 각 단계별 진행 상황은 커맨드 라인에 상태정보로 출력되며, 관리자는 상태정보 를 분석함으로써, 서버의 문제점을 파악할 수 있다. 예를 들어, 서버가 트랜잭션을 처리하는 중에 비정상적으로 종료한 경우에 서버를 재시작하면, 회복 단계에서 현재 회복중임을 알려 주는 메시지를 볼 수 있다. 또한, 데이터베이스 파일의 물리적인 손상이나, 로그 파일의 손 상등으로 인한 재시작 실패의 원인을 파악할 수 있는 에러 메시지를 볼 수 있다. 운영로그 파일(altibase.log)은 서버 운영중에 발생하는 문제점과 더불어 서버 시작과 종료시의 문제 점을 내부적인 추적 정보를 포함하여 기록해 둔다. 따라서, 관리자는 시작 및 종료 메시지 와 운영로그 파일을 참조하여 서버의 문제에 적절히 대처할 수 있다. Shutdown 명령은 세가지 모드(normal, immediate, abort)를 가지며, 각 모드에 따라 서 버는 종료시 현재 연결중인 클라이언트가 있는지 검사하고, 트랜잭션 테이블을 검사하여 진 행중인 트랜잭션을 철회(rollback)하거나 종료할 때까지 대기한다. 진행중인 트랜잭션이 없 으면, 정상적인 종료 과정을 수행한다. 먼저, 검사점(checkpoint)을 발생시켜, 메모리 데이 터베이스의 변경 내용을 데이터베이스 파일에 반영한 후, 로그와 가비지 관리 쓰레드를 종 료하고, 서비스 쓰레드와 커넥션풀을 해제한다. 서서버버 상상태태 확확인인 관리자는 dbadmin 툴을 이용하여 현재 운영중인 서버의 상태를 확인할 수 있다. 이러 한 상태 정보에는 프로퍼티 정보, 세션 정보, 이중화 정보, 데이터베이스 정보, 메모리 사용 정보 등이 있다. 세션 정보는 현재 연결된 클라이언트의 연결 방법, IP주소 등 연결 정보와 실행중인 statement의 개수를 보여준다. 이중화 정보는 이중화 송신 관리자와 수신 관리자에 대한 연 결 정보 및 이중화 상대 서버의 연결 정보를 포함한다. 데이터베이스 정보는 데이터베이스의 내부적인 정보를 보여주는 것으로, 데이터베이스 버전 번호, 타입, 크기 등의 정보와 데이터베이스에 할당된 메모리 크기와 사용 메모리 크 기가 포함된다. 또한 각 테이블별로 할당된 메모리 크기, 사용 메모리 크기, 메모리 사용률 을 보여준다. 관리자는 메모리 사용률을 분석하여 전체적인 데이터베이스 메모리 사용을 최적화할 수 있다. 할당된 메모리 크기는 크지만, 메모리 사용률이 낮은 경우는 해당 테이블의 메모리 공간을 최적화(compaction)할 필요가 있다. 이것은 테이블에서 레코드가 삭제된 경우 테이 블에 할당된 메모리는 테이블 레벨에서 재사용되기 때문인데, ALTER TABLE table_name COMPACT; 를 수행하면, 테이블의 미사용 공간을 반납하고, 레코드를 재조직한다. [그림 5]를 보면, 데이터의 삭제후 메모리 사용률이 떨어짐을 알 수 있다. 최적화를 수행하면, 테 이블에 할당된 메모리가 데이터베이스로 반납되므로, 데이터베이스 레벨에서 메모리 사용 효율성을 가져올 수 있다. AE ○ 3 65,536 레코드를 삭제한 후 메모리 사용률 Table : T1 Alloc Mem = 3.219M Alloc Page = 103 Alloc Slot = 70246 Used Slot = 4098 Memory Efficiency = 5.83% AE ○ 4 compaction후 메모리 사용률 Table : T1 Alloc Mem = 0.219M Alloc Page = 7 Alloc Slot = 4774 Used Slot = 4097 Memory Efficiency = 85.82% AE ○ 1 최초 T1 테이블의 메모리 사용률 Table : T1 Alloc Mem = 0.031M Alloc Page = 1 Alloc Slot = 682 Used Slot = 1 Memory Efficiency = 0.15% AE ○ 2 69,633 레코드를 삽입한 후 메모리 사용률 Table : T1 Alloc Mem = 3.219M Alloc Page = 103 Alloc Slot = 70246 Used Slot = 69633 Memory Efficiency = 99.13% [그림 5] compaction 사용예 SSQQLL 문문 실실행행하하기기 자 이제부터 SQL문을 이용해 테이블을 생성하고 데이터를 삽입, 삭제, 변경, 조회하는 예를 살펴보자. 먼저, 주지할 점은 SQL92 표준을 지원하고 있기 때문에, 기존의 데이터베 이스 시스템과 거의 같은 수준의 표현력을 가지고 있다는 점이다. 따라서, 사용자는 SQL문 을 충분히 활용하여 데이터를 조작할 수 있다. ISQL은 대화식으로 SQL문을 실행할 수 있는 유틸리티로, 실행의 편의를 위해 히스토리, 스풀 등 부가기능을 제공한다. ISQL을 실행하기 위해서는 서버 IP 주소와 포트번호를 지정 해야 한다. 다음의 명령은 192.168.1.11에서 실행중인 데이터베이스 서버에 포트번호 20521로 연결하는 예이다. isql -S 192.168.1.11 -P 20521 먼저 테이블을 생성해보자. 패키지에서 제공되는 schema.sql과 sample.sql을 실행하면, 샘플로 제공되는 스키마와 SQL문 사용예제를 볼 수 있다. 그 중 EMPLOYEE 테이블을 생 성하는 DDL문을 ISQL에서 실행한 결과는 [리스트 2]와 같다. iSQL> CREATE TABLE EMPLOYEE( ENO integer primary key, ENAME varchar(10) not null, EMP_JOB varchar(15), EMP_TEL nibble(15), DNO bytes(2), SALARY number(10,2) default 0, SEX char(1) default 'M' not null, BIRTH bytes(2), JOIN_DATE date, STATUS CHAR(1) default 'H'); Create Success [리스트 2] DDL문 사용예제 예제의 DDL문을 살펴보면, integer나 varchar와 같이 일반적인 데이터타입 뿐만 아니라 nibble 타입이 있다. nibble 타입은 전화번호와 같이 표현하는 캐릭터의 범위가 제한적일 때 1 바이트에 두 글자씩, 즉 4bit에 데이터를 표현할 수 있으므로, 저장공간을 절약할 수 있는 데이터 타입이다. iSQL> INSERT INTO EMPLOYEE VALUES (5, '홍길동', '개발자', '01145582310', 'D001', 2500000, 'M', '', '20-DEC-99','H'); 1 row inserted. iSQL> SELECT ENO, ENAME FROM EMPLOYEE WHERE EMP_JOB = ‘개발자’; ENO ENAME ----------------------------- 5 홍길동 selected row count [1] [리스트 3] DML문 사용예제 DML문은 데이터를 조작하는 작업을 수행하는데, JOIN 과 SUB-SELECTION 등 다양한 조건에 의한 데이터 수집이 가능하다. [리스트 3]의 예제는 삽입과 검색 연산의 예를 보여 주는 것으로, 컬럼값 뿐만 아니라 테이블명, 컬럼명 등에서도 한글을 사용할 수 있다. 텍텍스스트트 파파일일 업업로로딩딩과과 다다운운로로딩딩하하기기 데이터가 텍스트파일에 일정한 포맷으로 저장되어 있다면, ILOADER 유틸리티를 활용하 여 데이터베이스에 로딩할 수 있고, 테이블에 저장된 레코드를 텍스트 파일로 다운로딩할 수 있다. 이것은 특히 기존의 데이터베이스에서 이식(migration)하는 경우 유용한 기능이다. ILOADER는 대화형 모드 및 명령형 모드로 사용가능하며, 데이터 파일의 포맷을 정의 하는 폼 파일과 데이터 파일, 그리고 테이블 명을 지정하여 로딩한다. 특히, 현재 정의된 테 이블에서 폼 파일을 생성하는 기능을 이용하면, 폼 파일을 수작업으로 정의하는 수고를 덜 수 있다. [리스트 4]는 EMPLOYEE 테이블의 폼파일 생성과 업로딩, 다운로딩을 하는 예제 이다. iLOADER> formout ­T EMPLOYEE ­f emp.fmt /* 폼파일 생성 */ iLOADER> in ­f emp.fmt ­d emp.dat /* 데이터 업로딩 */ iLOADER> out ­f emp.fmt ­d emp.dat /* 데이터 다운로딩 */ [리스트 4] 텍스트 파일 업다운 로딩 응응용용 프프로로그그램램 작작성성 응용 프로그램은 SQLCLI, ODBC, SES C/C ++ 그리고 JDBC 인터페이스를 사용하여 클라 이언트 프로그램을 작성할 수 있으며, 이들은 일반적인 범용 데이터베이스 운영 환경에서의 프로그램 작성법이라 할 수 있다. 각각의 인터페이스를 활용한 응용 프로그램 작성법에 관 하여 살펴 보자. (1) SQLCLI 를 활용한 프로그램 SQLCLI는 응용 프로그램이 데이터베이스 서버와 연결하여 SQL 작업을 처리할 수 있도 록 하는 호출 수준의 인터페이스로, X/OPEN CLI 표준 스펙을 준수한다. CLI API는 응용 작 성에 필요한 환경 정의, 연결 관리, SQL문 처리, 트랜잭션 처리 등에 관련된 기능을 제공하 는 함수들로 구성된다. 먼저, 응용 프로그램을 작성하기 위해서는 include 디렉토리의 헤더 파일(sqlcli.h)을 포함하고 lib 디렉토리의 라이브러리(libodbccli.a )를 링크해야한다. 프로그램은 초기설정, 트랜잭션 처리, 종료, 진단메시시 처리로 구성되며, 각 단계에서 는 다음과 같은 일을 수행한다. [그림 6]은 각 단계별로 적용되는 API를 도표로 보여준다. 초기설정 : 환경 및 연결핸들을 할당하고 초기화 한다. 각 단계에서 다음 단계로의 전환은 적절한 핸들을 전달함으써 이전 단계의 실행 결과에 관한 정보를 전달 하 는 것으로 이루어 진다. 트랜잭션 처리 : 응용 프로그램의 데이터 조작 로직을 구현한다. 종료 : 할당된 핸들을 단절하고 할당되었던 메모리를 회수한다. 진단 메시지 처리 : 진단이란 어플리케이션 내에서 생성된 경고나 오류상태를 처 리하는 것으로, 결과값이 에러일 경우에 진단 메시지를 확인해 볼 수 있다. 특히, 트랜잭션 처리는 SQL문을 직접처리(Direct Execution)하거나, 간접처리(Indirect Execution)하는 방식으로 코딩할 수 있다. 간접처리는 동일한 SQL문 구조에서 실제 바인딩 하는 값만 다른 경우로, 미리 SQL문을 준비(Prepare)하고, 반복적으로 값을 변경하면서 바 Statement Type? DISCONNECT SQLFreeHandle() SQLDisconnect() SQLFreeConnect() SQLFreeEnv() TRANSACT SQLEndTran FETCH ROW COUNT SQLRowCount() FETCH RESULTS SQLNumResultCols() SQLDescribeCol() SQLBindCol() SQLFetch() SQLGetData() EXECUTE Catalog function SQLBindParameter SQLExecDirect INITIALIZE SQLAllocStmt() SQLSetStmtAttr() CONNECT SQLAllocHandle() SQLSetEnvAttr() SQLAllocHandle() SQLConnect() SQLSetConnectAttr() [그림 6] SQLCLI 프로그래밍 단계 인딩하여 실행하는 방식이다. 두 방식간의 차이점은 직접처리는 SQL문을 실행할 때 마다, 서버측에서 파싱(parsing) ­ 검사(validation) ­ 최적화(optimization) 과정을 수행하는 반면, 간접 처리는 이러한 과정을 준비 시점에 한번만 수행한다. 실행 성능만으로 고려하면 간접 처리 방식이 뛰어나므로, 개발자는 업무 특성에 따라 SQL문의 작성과 실행방식을 결정할 필요가 있다. [리스트 5]는 TEST001 이라는 테이블을 생성한 후, 레코드를 insert 하고 select 하는 프로그램으로 주석부분을 잘 살펴보면 각 단계별로 처리하는 방법을 알 수 있다. #include /* SQLCLI 프로그램시 필요한 헤더 파일 */ #include #include #define SQL_LEN 1000 #define MSG_LEN 1024 SQLHENV env; /* Environment를 할당 받을 handle. */ SQLHDBC con; /* Connection을 할당 받을 handle. */ SQLHSTMT st1; /* Statement를 할당 받을 handle. */ SQLHSTMT st2; /* Statement를 할당 받을 handle. */ SQLHSTMT st3; /* Statement를 할당 받을 handle. */ SQLHSTMT st4; /* Statement를 할당 받을 handle. */ void execute_err(SQLHSTMT stat, char* q) { SQLINTEGER errNo; SQLSMALLINT msgLength; SQLCHAR errMsg[MSG_LEN]; printf("Error : %s\n",q); if (SQL_SUCCESS == SQLError ( env, con, stat, NULL, rMsg, MSG_LEN, )) { printf(" Error : # %ld, %s\n", errNo, errMsg); /* 진단 메시지 처리 부분, SQL 수행 후 반환값이 SQL_ERROR 일 경우 SQLError API 를 사용해서 진단을 할 수 있다. */ } SQLFreeStmt(st1, SQL_DROP); SQLFreeStmt(st2, SQL_DROP); SQLFreeStmt(st3, SQL_DROP); SQLFreeStmt(st4, SQL_DROP); if (SQL_ERROR == SQLDisconnect(con)) { printf("disconnect error\n"); } SQLFreeConnect(con); SQLFreeEnv(env); exit (1); } int main(int argc,char **argv) { char query[SQL_LEN]; int PORT_NO, age; char *USERNAME, *PASSWD, *NLS, connStr[1024], name[22]; SQLINTEGER len, name_ind, age_ind; if ( argc < 2 ) { printf("Usage : %s port_no \n",argv[0]); exit(1); } PORT_NO = atoi(argv[1]); /* 서버의 접속 Port 번호. */ USERNAME = "SYS"; /* 사용자명. */ PASSWD = "MANAGER"; /* 사용자 암호. */ NLS = "US7ASCII"; /* 사용언어 ( KO16KSC5601, US7ASCII ) */ /* Altibase Server에 접속 */ /* Environment 을 위한 메모리를 할당 */ if (SQL_ERROR == SQLAllocEnv( printf("SQLAllocEnv error!!\n"); exit(1); } /* Connection 을 위한 메모리를 할당 */ if (SQL_ERROR == SQLAllocConnect(env, printf("SQLAllocConnect error!!\n"); SQLFreeEnv(env); exit(1); } /* Altibase DBMS 로 연결하는 데 필요한 값을 설정한다 */ sprintf(connStr, "DSN=127.0.0.1;UID=%s;PWD=%s;CONNTYPE=%d;NLS_USE=%s;PORT_NO=%d", USERNAME, PASSWD, 1, NLS, PORT_NO); /* Connection을 형성, 실제로 DBMS 로 연결을 하는 부분이다. */ if (SQL_ERROR == SQLDriverConnect( con, NULL, connStr, SQL_NTS, NULL, 0, NULL, SQL_DRIVER_NOPROMPT )) { printf("connection error\n"); SQLFreeEnv(env); exit(1); } /* Statement을 위한 메모리를 할당, Statement 는 SQL 문 수행을 담당하는 핸들이다. */ if (SQL_ERROR == SQLAllocStmt(con, printf("SQLAllocEnv error!!\n"); SQLFreeEnv(env); exit(1); } /* Statement을 위한 메모리를 할당 */ if (SQL_ERROR == SQLAllocStmt(con, printf("SQLAllocEnv error!!\n"); SQLFreeEnv(env); exit(1); } /* Statement을 위한 메모리를 할당 */ if (SQL_ERROR == SQLAllocStmt(con, printf("SQLAllocEnv error!!\n"); SQLFreeEnv(env); exit(1); } /* Statement을 위한 메모리를 할당 */ if (SQL_ERROR == SQLAllocStmt(con, printf("SQLAllocEnv error!!\n"); SQLFreeEnv(env); exit(1); } /* 쿼리 직접수행 */ /* SQLExecDirect 는 서버로 직접 SQL문을 전송하고 바로 결과를 받아 온다. */ sprintf(query,"DROP TABLE TEST001"); SQLExecDirect(st1,query, SQL_NTS); sprintf(query,"CREATE TABLE TEST001 ( name varchar(20), age integer )"); if (SQL_ERROR == SQLExecDirect(st2,query, SQL_NTS)) { execute_err(st2, query); } /* Statement를 준비하고 변수를 바인드한다. */ /* SQLPrepare 는 서버로 SQL 문을 전송하면 서버에서 쿼리 파싱,최적화 과정을 거쳐 준비를 해 두고, SQLExecute 을 통해서 호스트 변수 값만 변경하면서 수행을 할 수 있다. 이는 동일한 쿼리의 반복 수 행시 빠른 결과를 보장할 수 있다. */ sprintf(query,"INSERT INTO TEST001 VALUES( ?, ? )"); if (SQL_ERROR == SQLPrepare(st3, query, SQL_NTS)) { execute_err(st3, query); } SQLBindParameter(st3, 1, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_CHAR, sizeof(name), 0, name, 0, SQLBindParameter(st3, 2, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, en); /* DB로 입력할 값들의 버퍼를 바인딩 하는 부분 */ /* 준비된 Statement를 수행 */ len = SQL_NTS; sprintf(name, "홍길동"); age = 25; if (SQL_ERROR == SQLExecute(st3)) { execute_err(st3, query); } sprintf(name, "차돌이"); age = 34; if (SQL_ERROR == SQLExecute(st3)) { execute_err(st3, query); } sprintf(query,"SELECT * FROM TEST001"); if (SQL_ERROR == SQLExecDirect(st4,query, SQL_NTS)) { execute_err(st4, query); } /* Select의 결과값을 저장할 변수를 설정한다. */ SQLBindCol(st4, 1, SQL_C_CHAR, name, sizeof(name), SQLBindCol(st4, 2, SQL_C_SLONG, ge_ind); while (SQLFetch(st4) == SQL_SUCCESS) /* 결과값이 있는 동안 결과값을 받아 화면에 출력 */ { printf("Name : %5s, Age : %5ld\n",name,age); } /* 모든 handle을 해제하고 접속을 종료 */ SQLFreeStmt(st1, SQL_DROP); SQLFreeStmt(st2, SQL_DROP); SQLFreeStmt(st3, SQL_DROP); SQLFreeStmt(st4, SQL_DROP); /* DBMS 로부터의 연결을 해제한다. */ if (SQL_ERROR == SQLDisconnect(con)) { printf("disconnect error\n"); } SQLFreeConnect(con); SQLFreeEnv(env); } [리스트 5] SQLCLI 예제 프로그램 (2) ODBC를 활용한 프로그램 Microsoft 의 Open Database Connectivity (ODBC) 인터페이스는 산업 표준으로 SQLCLI 의 확장된 스펙이라고 할 수 있다. ODBC 인터페이스는 응용 프로그램을 동일한 인터페이스로 다양한 DBMS로 접근하는 것을 가능하게 한다. 응용 프로그램 사용자는 프로 그램과 특정 DBMS 간의 인터페이스인 소프트웨어 콤포넌트(ODBC드라이버)를 설치해야 한 다. ODBC를 이용하기 위해서는 먼저 패키지에서 제공하는 설치 프로그램(setup.exe)으로 ODBC 드라이버를 설치한다. 다음 제어판에서 ODBC 관리도구를 통하여 DSN 을 추가한다. [그림 7]과 같이 제어판 -> 관리 도구 -> ODBC 데이터 원본 관리자에서 추가를 선택한 후 1에서 설치된 Altibase 드라이버를 선택한다. 연결 환경 설정 창에서 호스트 IP, 포트 번 호 등을 입력한 후 DSN 을 등록한다 [그림 8]. [그림 7] ODBC 드라이버 설정 [그림 8] DSN 등록 과정 이제 등록된 ODBC드라이버를 통해 서버에 연결하여 데이터를 가지고 오는 테스트를 해보자. [그림 9]는 Visual Basic의 비주얼 데이터 관리자를 실행시켜 샘플 스키마에 정의된 orders 테이블을 검색한 결과이다. [그림 9] 비주얼 데이터 관리자를 통해서 알티베이스에 연결하기 ODBC드라이버 테스트가 끝났으면, 이제 비주얼 베이직에서 ADO Data Contol 과 Data Grid Contol 을 사용해서 테이블을 조회하는 프로그램을 작성해 보자. [그림 10]은 ADO오 브젝트를 활용하여 데이터베이스 커넥션을 정의하고, ORDERS 테이블을 지정하여 레코드를 가져오는 간단한 예제 프로그램이다. 먼저 ADO Data Contol을 생성하여 알티베이스 ODBC 드라이버를 선택하고, 연결 문자열 설정과 검색할 테이블을 지정하고 이름을 Adoc1으로 지 정한다 [그림 10]. DataGrid 오브젝트를 생성하여 DataSource를 Adoc1으로 지정하고 폼에 위치를 정한다 [그림 11]. 프로그램을 실행하면 [그림 12]와 같이 서버에 연결하여 ORDERS 테이블에서 레코드를 가지고 온다. [그림 10] ADO 오브젝트 속성 지정 [그림 11] DataGrid 오브젝트 속성 지정 [그림 12] Visual Basic으로 작성한 간단한 예제 (3) SES C/C++를 활용한 프로그램 SES C/C++는 소스 프로그램(확장명 sc) 을 입력으로 받아, 소스 프로그램 내에 있는 SQL 문장(내장 SQL 문장)들을 라이브러리 호출 형태의 코드로 변환된 파일을 생성하여, C/C++ 컴파일러로 컴파일될 수 있도록 변환하는 전처리기(precompiler)이다. 이는 개발자 로 하여금 간단한 내장 SQL 문을 사용하여 응용 프로그램을 작성할 수 있도록 하여, 개발 비용을 절감하는 효과를 기대할 수 있다. 알티베이스의 SES C/C++ 은 Oracle 의 Pro*C/C++ 과 유사하여 기존의 개발자들에게는 친숙할 것이다. 먼저, 응용 프로그램을 작 성하기 위해서는 lib 디렉토리의 libsesc.a와 libodbccli.a를 링크해야한다. 전처리기는 다음과 같이, 소스 파일을 지정하여 실행한다. 이때, 소스 코드에 따라 C와 C++을 지정할 수 있으며, 개발자가 정의한 위치의 헤더파일을 포함하도록 지정할 수 있다. sesc [-h] [-t ] [-include pathname] source_file SQLCLI 설명에서 작성했던 예제를 내장 SQL 소스로 변경하여 비교해 보도록 하자 [리 스트 6]. 먼저, 눈에 뛰는 것은 SQLCLI와 달리 복잡한 환경 설정과 메모리 할당 등의 번거 로운 작업이 없다는 점이다. 이것은 전처리기 자동적으로 코드를 생성해주기 때문이다. 또 한, 개발자는 내장 SQL문 처리를 통해 업무 로직에만 집중할 수 있다는 점도 장점이다. 전 처리기는 개발자의 소스코드를 분석하여 최적화 과정을 통해 SQLCLI로 직접 작성한 경우와 거의 대등한 성능을 보이는 코드로 변환한다. /* 호스트 변수 선언 */ EXEC SQL BEGIN DECLARE SECTION; char USERNAME[50]; char PASSWD[50]; char connStr[1024]; char name[22]; int age; int name_ind; int age_ind; EXEC SQL END DECLARE SECTION; void execute_err(char* q) { printf("Error : %s\n",q); printf(" Error : # %ld, %s\n", SQLCODE, sqlca.sqlerrm.sqlerrmc); /* 진단 메시지 처리 부분, SQL 수행 후 반환값이 SQL_ERROR 일 경우 SQLError API 를 사용해서 진단 을 할 수 있다. */ EXEC SQL DISCONNECT; exit (1); } int main(int argc,char **argv) { int PORT_NO; char NLS[50]; if ( argc < 2 ) { printf("Usage : %s port_no \n",argv[0]); exit(1); } PORT_NO = atoi(argv[1]); /* 서버의 접속 Port 번호. */ strcpy(USERNAME, "SYS"); /* 사용자명. */ strcpy(PASSWD, "MANAGER"); /* 사용자 암호. */ strcpy(NLS, "US7ASCII"); /* 사용언어 ( KO16KSC5601, US7ASCII ) */ /* Altibase Server에 접속 */ /* Altibase DBMS 로 연결하는 데 필요한 값을 설정한다 */ sprintf(connStr, "DSN=127.0.0.1;CONNTYPE=%d;NLS_USE=%s;PORT_NO=%d", 1, NLS, PORT_NO); /* Connection을 형성, 실제로 DBMS 로 연결을 하는 부분이다. */ EXEC SQL CONNECT :USERNAME IDENTIFIED BY :PASSWD USING :connStr; if (sqlca.sqlcode == SQL_ERROR) { printf("connection error\n"); exit(1); } /* SQL문 수행 */ EXEC SQL DROP TABLE TEST001; EXEC SQL CREATE TABLE TEST001 ( name varchar(20), age integer); if (sqlca.sqlcode == SQL_ERROR) { execute_err(“create table…”); } sprintf(name, "홍길동"); age = 25; /* SQLCLI 에서 SQLBindParameter 과정을 통해서 변수를 바인딩했던 과정을 호스트 변수를 써서 간단하 게 작성할 수 있다. */ EXEC SQL INSERT INTO TEST001 VALUES( :name, :age); if (sqlca.sqlcode == SQL_ERROR) { execute_err(“insert into table…”); } sprintf(name, "아무개"); age = 34; EXEC SQL INSERT INTO TEST001 VALUES( :name, :age); if (sqlca.sqlcode == SQL_ERROR) { execute_err(“insert into table…”); } EXEC SQL DECLARE test_cursor CURSOR FOR SELECT * FROM TEST001; if (sqlca.sqlcode == SQL_ERROR) { execute_err(“declare cursor…”); } EXEC SQL OPEN test_cursor; if (sqlca.sqlcode == SQL_ERROR) { execute_err(“open cursor…”); } while (1) /* 결과값이 있는 동안 결과값을 받아 화면에 출력 */ { EXEC SQL FETCH FROM test_cursor INTO :name indicator :name_ind, :age indicator :age_ind; /* SQLCLI에서 SQLBindCol을 통하여 바인딩하는 것을 호스트 변수와 indicator로 작성할 수 있다. */ if (sqlca.sqlcode == SQL_NO_DATA) break; printf("Name : %5s, Age : %5ld\n",name,age); } EXEC SQL DISCONNECT; /* DBMS 로부터의 연결을 해제한다. */ } [리스트 6] SES C/C++로 작성한 예제 프로그램 (4) JDBC 를 활용한 프로그램 JDBC API는 SQL문들을 JDBC 인터페이스들에 있는 메쏘드의 인수로서 사용할 수 있 게 해 주는 SQL레벨의 API이다. JDBC API는 개발자들이 데이터베이스 문제에 전혀 신경 쓸 필요가 없이 업무 로직만 구현할 수 있도록 해 준다. 알티베이스 JDBC 드라이버는 자바 소프트에서 분류한 드라이버 유형 중 4번째 타입을 지원한다. 타입 4는 네트워크 프로토콜 을 통하여 데이터베이스 서버와 직접 통신하는 방식으로 100 % 순수 자바로 제작되었다. JDBC 드라이버는 lib 디렉토리에 Altibase.jar라는 이름으로 설치된다. 따라서, 개발자 는 환경변수 CLASS_PATH에 JDBC 드라이버 경로를 지정해야 한다. 응용 프로그램에서 드 라이버를 로드하는 방법은 [리스트 7-1]과 같다. 드라이버를 등록한 후, 데이터베이스 URL, 사용자 이름, 패스워드를 지정하여 DriverManger로부터 Connection 객체를 획득한다 [리스 트 7-2]. URL 지정 방식은 jdbc:Altibase://host명:port_no/dbname와 같이 한다. [1] Class.forName(“Altibase.jdbc.driver.AltibaseDriver”); [2] Connection con = DriverManager.getConnection(“jdbc:Altibase://localhost:20222/dbname”,“SYS”, “MANAGER”); [리스트 7] JDBC 드라이버 등록과 객체 획득 이제 자바 개발툴인 Jbuilder에서 알티베이스 JDBC 드라이버를 등록하고 사용하는 방 법을 알아보자. Tools -> Configure Libraries 메뉴에서 New를 선택하여 Class탭에 Altibase JDBC Driver를 추가하고, Required Libraries 탭을 선택하여 같은 방식으로 추가한다 [그림 13]. [그림 13] JBuilder에서 JDBC 드라이버 등록 Tools -> Enterprise Setup 메뉴를 선택하고 Database Drivers 탭에서 위에 등록한 라 이브러리를 추가한다 [그림 14]. [그림 14] JBuilder의 Enterprise Setup에서 JDBC 드라이버 등록 이제 JDBC 드라이버가 제대로 등록되었는지 Database Pilot을 실행시켜 테스트하자. 먼저 Options -> Drivers에서 Altibase JDBC Driver를 추가하고 URL을 지정하고 [그림 15], File -> New 를 통해서 새로운 DB 연결을 생성하고 서버로 연결을 시도한 후에, Enter SQL 탭에서 ODBC 드라이버 테스트와 같은 방식으로 SQL문을 테스트한다. [그림 15] JBuilder의 Database Pilot에서 JDBC 드라이버 등록 SQLCLI 설명에서 작성했던 예제를 JDBC를 이용한 자바 프로그램으로 변경하여 비교 해 보도록 하자 [리스트 8]. 소스 코드를 살펴보면, 기존의 데이터베이스 응용 프로그램과 동일함을 알 수 있다. 즉, JDBC 드라이버를 정확히 등록하면 이후의 과정은 기존의 방식과 크게 다른점이 없다. import java.sql.*; class JdbcTest { public static void main(String args[]) { Connection con = null; Statement stmt = null; PreparedStatement pstmt = null; ResultSet res; if ( args.length == 0 ) { System.err.println("Usage : java JdbcTest port_no \n"); System.exit(1); } String port = args[0]; String url = "jdbc:Altibase://192.168.1.11:" + port + "/mydb"; String user = "SYS"; String passwd = "MANAGER"; /* 알티베이스 JDBC 드라이버 등록 */ try { Class.forName("Altibase.jdbc.driver.AltibaseDriver"); } catch ( Exception e ) { System.err.println("Can't register Altibase Driver"); return; } /* 접속하고 Statment를 할당. */ try { con = DriverManager.getConnection(url, user, passwd); stmt = con.createStatement(); } catch ( Exception e ) { e.printStackTrace(); } /* SQL문 수행 */ try { stmt.execute("DROP TABLE TEST001"); } catch ( SQLException se ) { } try { stmt.execute("CREATE TABLE TEST001 ( name varchar(20), age number(3) )"); pstmt = con.prepareStatement("INSERT INTO TEST001 VALUES(?,?)"); pstmt.setString(1,"홍길동"); pstmt.setInt(2,25); pstmt.execute(); pstmt.setString(1,"아무개"); pstmt.setInt(2,34); pstmt.execute(); res = stmt.executeQuery("SELECT * FROM TEST001"); /* 결과를 받아 화면에 출력 */ while(res.next()) { System.out.println(" Name : "+res.getString(1)+", Age : "+res.getInt(2)); } /* 연결 해제 */ stmt.close(); pstmt.close(); con.close(); } catch ( Exception e ) { e.printStackTrace(); } } } [리스트 8] JDBC를 이용한 예제 프로그램 이번 호에서는 알티베이스를 설치하는 방법과 플랫폼 및 운영환경에 최적화된 성능을 얻기 위해 환경 설정 방법을 설명하였다. 또한, 각종 유틸리티를 사용하여 관리자가 데이터 베이스를 생성하고 삭제하는 방법과 서버를 시작하고 종료하는 방법을 알아보았다. 마지막 으로 동일한 내용의 프로그램을 다양한 프로그래밍 인터페이스를 이용해 예제 프로그램을 개발하는 연습을 해보았다. 다음 호에서는 주식 시세 구축사례를 통해 이중화 기능의 원리 와 이중화를 활용하여 전체적인 생산성과 가용성을 확대할 수 있는 응용의 구조와 개발 방 법을 살펴볼 예정이다. 본 연재에 대한 질문은 ㈜알티베이스의 홈페이지나 전자메일을 통해 하기 바란다.

ALTIBASE Administration Administrator’s Manual Release 5.3.3 -------------------------------------------- ALTIBASE Administration Administrator’s Manual Release 5.3.3 Copyright ⓒ 201~209 ALTIBASE Corp. All Rights Reserved. 본 문서의 저작권은 ㈜알티베이스에 있습니다. 이 문서에 대하여 당사의 동의 없이 무단으로 복제 또는 전용할 수 없습니다. ㈜알티베이스 152-790 서울시 구로구 구로동 182-13 대륭포스트타워Ⅱ 10 층 전화: 02-2082-1114 팩스: 02-2082-1099 e-mail: support@altibase.com homepage: http://ww.altibase.com -------------------------------------------- 목차 I 목 차 서문 ..................................................................................................... i 이 매뉴얼에 대하여 ............................................................................................ ii Part I .................................................................................................. 1 1. 데이터베이스 생성 .................................................................................. 3 데이터베이스 생성 .............................................................................................. 4 2. 알티베이스 구동 및 종료 ...................................................................... 11 알티베이스의 구동 ........................................................................................... 12 알티베이스의 종료 ........................................................................................... 14 3. 데이터 딕셔너리 ................................................................................... 17 메타 테이블 ..................................................................................................... 18 SYS_COLUMNS_ ............................................................................................ 22 SYS_COMMENTS_ ......................................................................................... 26 SYS_CONSTRAINTS_ .................................................................................... 27 SYS_CONSTRAINT_COLUMNS_ ................................................................... 29 SYS_DATABASE_ .......................................................................................... 31 SYS_DATABASE_LINKS_ .............................................................................. 32 SYS_DIRECTORIES_ ...................................................................................... 34 SYS_ENCRYPTED_COLUMNS_ ..................................................................... 35 SYS_SECURITY_ ............................................................................................ 36 SYS_GRANT_OBJECT_ .................................................................................. 37 SYS_GRANT_SYSTEM_ ................................................................................. 39 SYS_INDEX_COLUMNS_ ................................................................................ 40 SYS_INDEX_PARTITIONS_ ........................................................................... 42 SYS_INDICES_ ............................................................................................... 44 SYS_LOBS_ .................................................................................................... 46 SYS_PART_INDICES_ .................................................................................... 47 SYS_PART_KEY_COLUMNS_ ........................................................................ 49 SYS_PART_LOBS_ ......................................................................................... 50 SYS_PART_TABLES_ .................................................................................... 51 SYS_PRIVILEGES_ ......................................................................................... 53 SYS_PROCEDURES_ ...................................................................................... 54 II ALTIBASE5 Administrator’s Manual SYS_PROC_PARAS_ ........................................................................................ 57 SYS_PROC_PARSE_ ........................................................................................ 59 SYS_PROC_RELATED_ ................................................................................... 60 SYS_REPLICATIONS_ ..................................................................................... 62 SYS_REPL_HOSTS_ ........................................................................................ 65 SYS_REPL_ITEMS_ ......................................................................................... 66 SYS_REPL_OFFLINE_DIR__ ........................................................................... 68 SYS_REPL_OLD_COLUMNS_ ......................................................................... 69 SYS_REPL_OLD_INDEX_COLUMNS_ ............................................................. 71 SYS_REPL_OLD_INDICES_ ............................................................................. 73 SYS_REPL_OLD_ITEMS_ ................................................................................ 75 SYS_REPL_RECOVERY_INFOS_ ..................................................................... 77 SYS_SYNONYMS_ ........................................................................................... 78 SYS_TABLES_ ................................................................................................ 79 SYS_TABLE_PARTITIONS_ ........................................................................... 83 SYS_TBS_USERS_ .......................................................................................... 85 SYS_TRIGGERS_ ............................................................................................. 86 SYS_TRIGGER_DML_TABLES_ ...................................................................... 89 SYS_TRIGGER_STRINGS_ .............................................................................. 90 SYS_TRIGGER_UPDATE_COLUMNS_ ................................... ........................ 91 SYS_USERS_ ................................................................................................... 92 SYS_VIEWS_ ................................................................................................... 93 SYS_VIEW_PARSE_ ........................................................................................ 94 SYS_VIEW_RELATED_ ................................................................................... 95 SYS_XA_HEURISTIC_TRANS_ ....................................................................... 97 성능 뷰 ............................................................................................................. 98 V$ALLCOLUMN ............................................................................................ 103 V$ARCHIVE .................................................................................................. 104 V$BUFFPAGEINFO ....................................................................................... 105 V$BUFFPOOL_STAT .................................................................................... 109 V$CATALOG ................................................................................................. 115 V$DATABASE ............................................................................................... 116 V$DATAFILES .............................................................................................. 118 V$DATATYPE ............................................................................................... 121 V$DBA_2PC_PENDING ................................................................................. 125 V$DBLINK_REMOTE_STATEMENT_INFO .................................................. 126 V$DBLINK_REMOTE_TRANSACTION_INFO .............................................. 127 V$DBLINK_TRANSACTION_INFO ............................................................... 128 V$DB_FREEPAGELISTS ............................................................................... 129 V$DB_PROTOCOL ........................................................................................ 130 V$DISKTBL_INFO ................................................ ........................................ 131 목차 III V$DISK_BTREE_HEADER ........................................................................... 133 V$EVENT_NAME ......................................................................................... 136 V$FILESTAT ................................................................................................ 139 V$FLUSHINFO ............................................................................................. 141 V$INDEX ...................................................................................................... 142 V$INSTANCE ............................................................................................... 143 V$LATCH ..................................................................................................... 144 V$LFG .......................................................................................................... 145 V$LINKER_STATUS .................................................................................... 148 V$LOCK ........................................................................................................ 149 V$LOCK_STATEMENT ............................................................................... 150 V$LOG .......................................................................................................... 151 V$LOCK_WAIT ............................................................................................ 152 V$MEMGC .................................................................................................... 153 V$MEMSTAT ............................................................................................... 155 V$MEMTBL_INFO ........................................................................................ 156 V$MEM_BTREE_HEADER ........................................................................... 158 V$MEM_BTREE_NODEPOOL ...................................................................... 160 V$MEM_RTREE_HEADER ........................................................................... 162 V$MEM_RTREE_NODEPOOL ...................................................................... 164 V$MEM_TABLESPACES.............................................................................. 166 V$MEM_TABLESPACE_CHECKPOINT_PATHS ......................................... 169 V$MEM_TABLESPACE_STATUS_DESC .................................................... 170 V$MUTEX .................................................................................................... 171 V$NLS_PARAMETERS ................................................................................ 172 V$PLANTEXT .............................................................................................. 174 V$PROCTEXT .............................................................................................. 175 V$PROPERTY .............................................................................................. 176 V$REPEXEC ................................................................................................. 177 V$REPGAP ................................................................................................... 178 V$REPLOGBUFFER ..................................................................................... 180 V$REPOFFLINE_STATUS ........................................................................... 181 V$REPRECEIVER ......................................................................................... 182 V$REPRECEIVER_COLUMN ........................................................................ 184 V$REPRECEIVER_TRANSTBL .................................................................... 185 V$REPRECOVERY ....................................................................................... 186 V$REPSENDER ............................................................................................ 188 V$REPSENDER_TRANSTBL ....................................................................... 191 V$REPSYNC ................................................................................................. 192 V$SEGMENT ................................................................................................ 193 V$SEQ .......................................................................................................... 194 IV ALTIBASE5 Administrator’s Manual V$SERVICE_THREAD ................................................................................... 196 V$SESSION ................................................................................................... 199 V$SESSIONMGR ........................................................................................... 205 V$SESSION_EVENT ..................................................................................... 206 V$SESSION_WAIT ........................................................................................ 208 V$SESSTAT .................................................................................................. 210 V$SQLTEXT ................................................................................................. 211 V$SQL_PLAN_CACHE .................................................................................. 212 V$SQL_PLAN_CACHE_PCO ......................................................................... 214 V$SQL_PLAN_CACHE_SQLTEXT ................................................................ 216 V$STABLE_MEM_DATAFILES .................................................................... 217 V$STATEMENT ........................................................................................... 218 V$STATNAME .............................................................................................. 224 V$SYSSTAT .................................................................................................. 227 V$SYSTEM_CONFLICT_PAGE ..................................................................... 228 V$SYSTEM_EVENT ...................................................................................... 229 V$SYSTEM_WAIT_CLASS ........................................................................... 231 V$TABLE ...................................................................................................... 233 V$TABLESPACES ........................................................................................ 234 V$TRACELOG ............................................................................................... 237 V$TRANSACTION ........................................................................................ 240 V$TRANSACTION_MGR ............................................................................... 245 V$TSSEGS .................................................................................................... 246 V$TXSEGS .................................................................................................... 248 V$UDSEGS .................................................................................................... 250 V$UNDO_BUFF_STAT ................................................................................. 252 V$VERSION................................................................................................... 253 V$WAIT_CLASS_NAME ............................................................................... 254 V$XID ............................................................................................................ 256 4. 데이터베이스 객체 및 권한 ................................................................. 259 데이터베이스 객체 개요 ................................................................................. 260 테이블 관리 .................................................................................................... 264 큐 테이블 관리 ............................................................................................... 271 제약조건 관리 ................................................................................................ 273 인덱스 관리 .................................................................................................... 275 뷰 관리 ........................................................................................................... 280 시퀀스 관리 .................................................................................................... 282 시노님 관리 .................................................................................................... 285 저장 프로시저 및 저장 함수 관리 .................................................................. 286 트리거 관리 .................................................................................................... 290 목차 V 사용자 관리 ................................................................................................... 292 권한 관리 ...................................................................................................... 294 Part II ............................................................................................. 297 5. 테이블스페이스 ................................................................................... 299 테이블스페이스 정의 및 구조 ........................................................................ 300 테이블스페이스 분류 ..................................................................................... 309 디스크 테이블스페이스 .................................................................................. 313 언두 테이블스페이스 ..................................................................................... 318 테이블스페이스 상태 ..................................................................................... 323 테이블스페이스 관리 ..................................................................................... 325 테이블스페이스 사용 예제 ............................................................................. 339 테이블스페이스 공간 관리 ............................................................................. 351 6. 파티션드 테이블 ................................................................................. 359 파티셔닝 정의 및 구조 .................................................................................. 360 파티션드 객체................................................................................................ 362 파티션 조건 ................................................................................................... 369 파티션 방법 ................................................................................................... 371 7. 트랜잭션 관리 ..................................................................................... 387 트랜잭션 ........................................................................................................ 388 잠금(Lock)의 개요 ........................................................................................ 391 다중 버전 동시성 제어 기법 ......................................................................... 394 트랜잭션의 영속성 ......................................................................................... 402 8. 버퍼 관리자 ........................................................................................ 407 버퍼 관리자의 구조 ....................................................................................... 408 버퍼 관리 ...................................................................................................... 414 버퍼 관련 프로퍼티 ....................................................................................... 421 버퍼 관리자 통계 정보 .................................................................................. 422 9. 백업 및 복구 ...................................................................................... 423 알티베이스 백업 ............................................................................................ 424 알티베이스 복구 ............................................................................................ 429 백업 및 복구 사례들 ..................................................................................... 433 10. SQL 튜닝 ........................................................................................... 47 SQL 튜닝 개요 .............................................................................................. 448 질의 최적화 과정 .......................................................................................... 455 실행 계획 분석 .............................................................................................. 500 힌트의 활용 ................................................................................................... 543 VI ALTIBASE5 Administrator’s Manual 11. Explain Plan ....................................................................................... 549 Explain Plan의 정의 ...................................................................................... 550 Plan Tree 보기 .............................................................................................. 553 Plan Nodes .................................................................................................... 555 12. SQL Plan Cache ................................................................................. 583 SQL Plan Cache 개요 .................................................................................... 584 SQL Plan Cache의 특징 ................................................................................ 586 SQL Plan Cache 관련 프로퍼티 ..................................................................... 587 Part III ........................................................................................... 589 13. 알티베이스의 보안............................................................................... 591 보안의 개요 .................................................................................................... 592 보안 기능의 구성 ........................................................................................... 593 보안 모듈 연동 방법 ...................................................................................... 594 보안 모듈 연동 구문 ...................................................................................... 596 14. 알티베이스 튜닝 .................................................................................. 601 로그 파일 그룹 ............................................................................................... 602 그룹 커밋 ....................................................................................................... 608 15. 알티베이스 모니터링 및 PBT ............................................................. 615 알티베이스 모니터링 ...................................................................................... 616 알티베이스 문제상황 분석 .............................................................................. 617 A. 부록: Trace Log ..................................................................... 625 Trace Log...................................................................................................... 626 찾아보기 ......................................................................................... 627 서문 i 서문 ii ALTIBASE5 Administrator’s Manual 이 매뉴얼에 대하여 이 매뉴얼은 알티베이스를 구성, 관리, 사용하기 위해 필요한 개념에 대해 설명한다. 대상 사용자 이 매뉴얼은 다음과 같은 알티베이스 사용자를 대상으로 작성되었다. y 데이터베이스 관리자 y 시스템 관리자 y 성능 관리자 다음과 같은 배경 지식을 가지고 이 매뉴얼을 읽는 것이 좋다. y 컴퓨터, 운영 체제 및 운영 체제 유틸리티 운용에 필요한 기본 지식 y 관계형 데이터베이스 사용 경험 또는 데이터베이스 개념에 대한 이해 y 데이터베이스 서버 관리, 운영 체제 관리 또는 네트워크 관리 경험 소프트웨어 환경 이 매뉴얼은 데이터베이스 서버로 알티베이스 버전 5.3.3 을 사용한다는 가정 하에 작성되었다. 이 매뉴얼의 구성 이 매뉴얼은 다음과 같이 구성되어 있다. y 제 1장 데이터베이스 생성 이 장은 데이터베이스를 구성하는 대표적 구성 요소인 테이블스페이스와 로깅 시스템의 종류 및 데이터베이스 생성 방법에 관하여 설명한다. y 제 2장 알티베이스 구동 및 종료 이 장은 알티베이스를 구동 및 종료 시키는 방법과 알티베이스 다단계 구동 시 내부적으로 수행하는 작업에 대해 설명한다. y 제 3장 데이터 딕셔너리 이 장은 알티베이스 시스템 정보를 제공하는 데이터 딕셔너리에 대해 설명한다. y 제 4장 데이터베이스 객체 및 권한 서문 iii 이 장은 특정 사용자에 의해 생성된 제약조건, 인덱스, 시퀀스, 이중화, 테이블, 사용자 등 데이터베이스 객체들에 대해 설명한다. 또한, 시스템 및 스키마 객체 수준의 권한에 대해 설명한다. y 제 5장 테이블스페이스 이 장은 데이터베이스의 논리적 구조를 이해함으로써 데이터베이스의 공간 관리를 작은 단위로 제어하고, 물리적 데이터 영역을 효율적으로 관리하는 방법에 대해 설명한다. y 제 6장 파티션드 테이블 이 장은 대용량 데이터베이스 테이블을 여러 개의 작은 조각으로 분할하여 관리하는 파티션드 테이블에 대해 설명한다. y 제 7장 트랜잭션 관리 이 장은 트랜잭션을 정의하고 트랜잭션을 사용하여 작업을 관리하는 방법에 대해 설명한다. y 제 8장 버퍼 관리자 알티베이스는 대용량의 데이터가 디스크에 저장될 수 있도록 지원하는데, 메모리의 공간은 한정되어 있으므로 이를 전부 메모리에 적재할 수 없으므로 테이블, 인덱스, 레코드 등 모든 데이터에 접근하기 위해서는 먼저 디스크의 데이터를 메모리에 적재해야 한다. 이 장은 이러한 메모리 공간을 할당하고, 메모리 공간이 부족한 경우 필요한 데이터를 제공할 수 있도록 메모리 공간을 유지 및 관리하느 버퍼 관리자에 대하여 설명한다. y 제 9장 백업 및 복구 이 장은 시스템 정전 또는 디스크, 데이터 파일 손상 유실 등과 같은 예기치 않은 상황으로 인해 알티베이스에 저장된 데이터가 손실될 경우를 대비하여 알티베이스에서 지원하는 백업 및 복구에 대하여 설명한다. y 제 10장 SQL 튜닝 이 장은 질의 성능을 향상시키기 위한 SQL 튜닝 방법에 대하여 설명한다. y 제 11장 Explain Plan 이 장은 알티베이스 DBMS 서버가 최적화된 질의를 실행하기 위해 수행하는 접근 경로를 설명한다. y 제 12장 SQL Plan Cache 이 장은 알티베이스 SQL Plan Cache 기능에 대한 개념 및 특징에 대해 설명한다. y 제 13장 알티베이스의 보안 이 장은 데이터베이스의 정보를 보호하기 위한 알티베이스의 보안 기능에 대해 설명한다. y 제 14장 알티베이스 튜닝 이 장은 알티베이스의 성능 향상을 위한 로그 파일 그룹과 그룹 커밋에 대해 설명한다. iv ALTIBASE5 Administrator’s Manual y 제 15장 알티베이스 모니터링 및 PBT 이 장은 알티베이스의 운영상태를 확인하는 방법과 해당 내용을 분석하는 방법에 대해 설명한다. 또한, 알티베이스 운영 중 발생할 수 있는 여러 가지 문제 상황에 대하여 점검 사항 및 분석 방법에 대해 설명한다. y A. 부록: Trace Log 문서화 규칙 이 절에서는 이 매뉴얼에서 사용하는 규칙에 대해 설명한다. 이 규칙을 이해하면 이 매뉴얼과 설명서 세트의 다른 매뉴얼에서 정보를 쉽게 찾을 수 있다. 여기서 설명하는 규칙은 다음과 같다. y 구문 다이어그램 y 샘플 코드 규칙 구문 다이어그램 이 매뉴얼에서는 다음 구성 요소로 구축된 다이어그램을 사용하여, 명령문의 구문을 설명한다. 구성 요소 의미 예약어 명령문이 시작한다. 완전한 명령문이 아닌 구문 요소는 화살표로 시작한다. 명령문이 다음 라인에 계속된다. 완전한 명령문이 아닌 구문 요소는 이 기호로 종료한다. 명령문이 이전 라인으로부터 계속된다. 완전한 명령문이 아닌 구문 요소는 이 기호로 시작한다. ; 명령문이 종료한다. 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 ALTIBASE5 Administrator’s Manual 자세한 정보를 위하여 다음 문서 목록을 참조하기 바란다. y ALTIBASE Administration Installation Users Manual y ALTIBASE Administration Starting Users Manual y ALTIBASE Application Development SQL Users Manual y ALTIBASE Application Development Stored Procedure Users Manual y ALTIBASE Tools iSQL Users Manual y ALTIBASE Tools Utilities Users Manual y ALTIBASE Message Error Message Reference 온라인 매뉴얼 알티베이스 테크니컬 센터(http://atc.altibase.com/)에서 국문 및 영문 매뉴얼(PDF, HTML)을 받을 수 있다. 알티베이스는 여러분의 의견을 환영합니다. 이 매뉴얼에 대한 여러분의 의견을 보내주시기 바랍니다. 사용자의 의견은 다음 버전의 매뉴얼을 작성하는데 많은 도움이 됩니다. 보내실 때에는 아래 내용과 함께 기술지원센터(support@altibase.com)로 보내주시기 바랍니다. y 사용 중인 매뉴얼의 이름과 버전 y 매뉴얼에 대한 의견 y 사용자의 성함, 주소, 전화번호 이 외에도 알티베이스 기술지원 설명서의 오류와 누락된 부분 및 기타 기술적인 문제들에 대해서 이 주소로 보내주시면 정성껏 처리하겠습니다. 기술적인 부분과 관련하여 즉각적인 도움이 필요한 경우에는 기술지원센터로 연락하시기 바랍니다. 여러분의 의견에 항상 감사드립니다. Part I 1 Part I 데이터베이스 생성 3 1. 데이터베이스 생성 알티베이스 설치 후에 데이터베이스 관리자는 사용자 데이터 발생량을 예측하여 데이터베이스를 생성하고 관리해야 한다. 이장에서는 데이터베이스 생성시에 알고 있어야 하는 주요사항들에 대해서 설명하고 있다. 4 ALTIBASE5 Administrator’s Manual 데이터베이스 생성 알티베이스를 사용하기 위해서는 데이터베이스를 미리 생성시켜 놓아야 한다. 그렇지 않으면 알티베이스가 실행되지 않는다. 여기에서는 데이터베이스를 구성하는 대표적 구성 요소인 테이블스페이스와 로깅 시스템의 종류 및 생성 방법에 관하여 설명한다. 테이블스페이스의 종류 알티베이스의 데이터베이스는 여러 개의 테이블스페이스로 구성된다. 알티베이스에서 제공하는 기본 테이블스페이스는 아래와 같다. 메모리 테이블스페이스 딕셔너리 테이블들과 메모리 테이블들, 그리고 이에 관련된 다양한 데이터베이스 객체들이 저장되는 테이블스페이스이다. 데이터 테이블스페이스 디스크 테이블들과 인덱스들이 저장되는 테이블스페이스이다. 이는 다시 시스템 데이터 테이블스페이스와 사용자 데이터 테이블스페이스로 구분된다. 언두 테이블스페이스(Undo Tablespace) 디스크 테이블에 존재하는 레코드들에 대한 다중버전 동시성 제어( MVCC: Multi-Versioned Concurrency Control)를 제공하기 위해 변경 이전 이미지를 일정 기간 동안 저장해두는 테이블스페이스 이다. 임시 테이블스페이스(Temporary Tablespace) 질의를 처리하는 과정에서 발생되는 임시 테이블들과 인덱스들을 저장하는 테이블스페이스이다. 데이터 테이블스페이스와 마찬가지로 시스템 임시 테이블스페이스와 사용자 임시 테이블스페이스로 나뉜다. 각 테이블스페이스를 구성하는 파일들은 기본적으로 .dbf 의 확장자를 갖으며, CREATE DATABASE 시에 생성되는 위치는 $ALTIBASE_HOME/dbs/ 이다. *참고: 알티베이스 운용 중 사용자의 요구에 의해 새로 추가되는 파일의 확장자의 형식이나 디렉터리 위치는 제한은 없다. 데이터베이스 생성 5 휘발성 테이블스페이스(Volatile Tablespace) 디스크 입출력을 하지 않고, 메모리 기반 객체를 저장하기 위한 테이블스페이스이다. 데이터베이스 서비스 종료시 모든 휘발성 데이터 객체들이 사라지기 때문에 빠른 성능을 필요로 하는 경우에 휘발성 테이블스페이스가 유용하게 쓰인다. 그러나 휘발성 테이블스페이스의 크기는 시스템의 사용 가능한 물리적 메모리 공간을 초과할 수 없다. 로깅 시스템 데이터베이스 내의 데이터들은 어떤 상황 하에서도 영속성(Durability)을 가져야 한다. 알티베이스는 다음의 두 가지 파일들로 로깅 시스템을 구성하여 데이터베이스의 영속성을 제공한다. 로그 파일 트랜잭션 수행 중에 abnormal shutdown 에 대비하여 system recovery 를 위해 작성되는 로그 레코드들을 기록하는 파일들이다. 로그 파일의 이름은 logfile**이다(**은 로그 파일의 시퀀스 번호이다.). 로그 앵커(Log Anchor) 파일 테이블스페이스들에 대한 정보와 파일들의 위치, 체크 포인트 관련 정보 등 서버 운용에 관련된 중요한 데이터가 저장된 파일이다. 서버가 정상적으로 구동 되려면 이 파일의 내용이 유효하여야 하며, 그렇지 않을 경우에는 서버를 구동 시킬 수 없다. 최초 데이터베이스 생성시 로그 파일과 로그 앵커 파일들은 $ALTIBASE_HOME/logs/ 위치에 생성된다. 알티베이스는 이 로그 앵커 파일들을 3 벌로 유지하며, 데이터베이스 생성 시에는 로그 파일들과 같은 위치에 존재하지만, 3 개의 로그 앵커 파일들을 서로 다른 파일 시스템에 두기를 권장하고 있다. 로그 앵커 파일의 위치에 관련된 프로퍼티 LOGANCHOR_DIR 이다. 데이터베이스 생성 준비 알티베이스의 데이터베이스를 생성하려면 패키지에 제공되는 사용자 유틸리티인 isql 을 다음과 같이 수행한다. shell> isql -u sys -p manager -sysdba 6 ALTIBASE5 Administrator’s Manual 이는 데이터베이스에 접속하지 않고 isql 을 관리자 모드(admin mode)로 띄우는 것이며, 결과는 아래와 같다. ------------------------------------ Altibase Client Query utility. Release Version 5.3.3.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. Al Rights Reserved. ------------------------------------ ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 iSQL(sysdba)> 위의 상태가 되면 일단 CREATE DATABASE 명령을 수행하기 위한 서버 프로세스를 구동 시켜야 한다. 서버의 구동은 다음과 같은 순서로 이루어 진다. 1. Pre-Process 단계 서버를 구동하기 이전 단계이다. 2. Process 단계 create database 및 프로퍼티들을 조회하고 변경할 수 있는 단 계이다. 3. Control 단계 database 파일 로드, 복구(recovery) 준비 단계이다. 4. Meta 단계 복구 완료, 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을 참조한다. 여기서는 기본 옵션으로 데이터베이스를 생성하는 예를 보여주고 있다. 데이터베이스 생성 7 iSQL> create database mydb initsize=50M noarchivelog character set ksc5601 national character set utf16; DB Info (Page Size = 32768) (Page Count = 1537) (Total DB Size = 50364416) (DB File Size = 1073741824) Creating MDB FILES [SUCES] Creating Catalog Tables [SUCES] Creating DRDB FILES [SUCES] [SM] Rebuilding Indices [Total Count:0] [SUCCESS] DB Writing Completed. All Done. Create success. 데이터베이스 서버 종료 데이터베이스의 생성이 완료되면 이를 위해 임시로 띄웠던 서버를 종료하여야 한다. 서버의 종료는 다음과 같이 수행한다. iSQL(sysdba)> shutdown abort iSQL(sysdba)> 서버를 종료하면 isql 은 다시 서버에 접속하지 않은 Pre-Process 상태가 되며, 서버 프로세스도 종료된다. shutdown 명령의 유형으로는 abort 외에 immediate 와 normal 이 더 있으나, 이들은 서버가 service 단계일 때만 수행이 가능하다. 데이터베이스 생성 관련 프로퍼티 CREATE DATABASE 구문을 수행할 때 지정하지 않은 속성들은 알티베이스 프로퍼티 파일에 의해 결정되며, 영향을 미치는 프로퍼티들은 아래와 같다. 표에서 ?는 환경변수 ALTIBASE_HOME 의 경로를 의미한다.. 프로퍼티 이름 설명 기본값 DB_NAME 생성할 데이터베이스의 이름 mydb MEM_DB_DIR 데이터베이스 파일들이 위치할 디렉 터리(3번 정의됨) ?/dbs SERVER_MSGLOG_DIR 알티베이스 운용 중 발생되는 서버의 메시지를 기록하는 파일 (altibased_boot.log)이 위치하는 디 렉터리 ?/trc SHM_DB_KEY 공유 메모리 버전으로 알티베이스를 띄울 경우에 사용할 공유메모리 키값 0 (사용안함)MEM_MAX_DB_SIZE 메모리 테이블스페이스의 최대 크기 4G LOGANCHOR_DIR 로그 앵커 파일들이 위치할 디렉터리 (3번 정의됨) ?/logs 8 ALTIBASE5 Administrator’s Manual 프로퍼티 이름 설명 기본값 LOG_DIR 로그 파일들이 위치할 디렉터리 ?/logs LOG_FILE_SIZE 로그 파일 하나의 크기 10M STARTUP_SHM_CHUNK_SIZE 알티베이스 구동 시 생성되는 공유메 모리 한 개의 최대 크기 1G EXPAND_CHUNK_PAGE_COUNT메모리 테이블스페이스 페이지를 한 번에 할당하는 페이지 개수 3200 TEMP_PAGE_CHUNK_COUNT 메모리 테이블스페이스의 임시 페이 지를 한 번에 할당하는 페이지 개수 128 SYS_DATA_TBS_EXTENT_SIZE 시스템 데이터 테이블스페이스의 익 스텐트 한 개의 크기 256K SYS_DATA_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 시스템 데이터 파일의 최초 크 기 100M SYS_DATA_FILE_MAX_SIZE 시스템 데이터 파일의 최대 크기 2G SYS_DATA_FILE_NEXT_SIZE 시스템 데이터 파일이 자동 확장될 때의 확장 크기 1M SYS_TEMP_TBS_EXTENT_SIZE 임시 테이블스페이스의 익스텐트 한 개의 크기 256K SYS_TEMP_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 임시 데이터 파일의 최초 크기 100M SYS_TEMP_FILE_MAX_SIZE 임시 데이터 파일의 최대 크기 2G SYS_TEMP_FILE_NEXT_SIZE 임시 데이터 파일이 자동 확장될 때 의 확장 크기 1M SYS_UNDO_TBS_EXTENT_SIZE 언두 테이블스페이스의 익스텐트 한 개의 크기 128K SYS_UNDO_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 언두 데이터 파일의 최초 크기 100M SYS_UNDO_FILE_MAX_SIZE 언두 데이터 파일의 최대 크기 2G SYS_UNDO_FILE_NEXT_SIZE 언두 데이터 파일이 자동 확장될 때 의 확장 크기 1M USER_DATA_TBS_EXTENT_SIZE사용자 데이터 테이블스페이스의 익 스텐트 한 개의 크기 256K USER _DATA_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 사용자 데이터 파일의 최초 크 기 100M USER_DATA_FILE_MAX_SIZE 사용자 데이터 파일의 최대 크기 2G USER _DATA_FILE_NEXT_SIZE 사용자 데이터 파일이 자동 확장될 때의 확장 크기 1M USER_TEMP_TBS_EXTENT_SIZE사용자 임시 테이블스페이스의 익스 텐트 한 개의 크기 256K USER_TEMP_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 100M 데이터베이스 생성 9 프로퍼티 이름 설명 기본값 되는 사용자 임시 데이터 파일의 최 초 크기 USER_TEMP_FILE_MAX_SIZE 사용자 임시 데이터 파일의 최대 크 기 2G USER_TEMP_FILE_NEXT_SIZE 사용자 임시 데이터 파일이 자동 확 장될 때 의 확장 크기 1M ADD_EXTENT_NUM_FROM_TBS _TO_SEG 세그먼트가 확장될 때 증가하는 익스 텐트의 개수 1 ADD_EXTENT_NUM_FROM_SYS TEM_TO_TBS 테이블스페이스가 확장할 때 새로운 익스텐트를 할당하는 개수 4 CHECKSUM_METHOD 페이지의 상태가 올바른지 체크하는 방법의 종류 1 * 프로퍼티에 대한 보다 자세한 내용은 Starting Users Manual를 참조하기 바란다. 알티베이스 구동 및 종료 11 2. 알티베이스 구동 및 종료 데이터베이스를 생성한 다음 서비스 수행을 위해서는 데이터베이스를 다시 구동하여야 한다. 이 장에서는 데이터베이스 구동과 종료 시에 참고할 사항들을 설명하고 있다. 12 ALTIBASE5 Administrator’s Manual 알티베이스의 구동 알티베이스 서버를 실행하는 방법은 sys 계정의 관리자가 서버에 로그인 시 -sysdba 관리자 모드를 통하여 서버에 접속한 후 부여된 관리자 권한을 이용하거나 서버 스크립트 명령을 이용하여 실행할 수 있다. 알티베이스를 실행시키기 위해서는 데이터베이스 생성 시와 마찬가지로 우선 isql 을 -sysdba 옵션으로 실행해야 한다. 알티베이스의 startup 명령어는 알티베이스(isql 포함)를 설치한 유닉스 계정으로만 수행이 가능하다. shell> isql -u sys -p manager -sysdba ---------------------------------- Altibase Client Query utility. Release Version 5.3.3.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. ---------------------------------- ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 iSQL(sysdba)> 알티베이스가 구동할 때 상태는 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 Serial Bulk Loading . is 8192k: *.[SUCES] [SM] Recovery Phase - 3: Skipping Recovery Threads...[SUCESS] Refining Disk Table [SUCES] [SM] Garbage Collection: ....................................... [SUCCES] [SM] Rebuilding Indices [Total Count:61] **********..................... .................................................... [SUCCESS] TRANSITION TO PHASE: SERVICE No IPC Initialize: Disabled --- STARTUP Process SUCCESS -- 알티베이스 구동 및 종료 13 Command execute success. Startup 의 각 단계에서 할 수 있는 일은 다음과 같다. 단계 가능한 작업 PRE-PROCESS PROCESS 단계로 전이할 수 있다. PROCESS Create Database를 수행할 수 있다. 제한된 개수의 Performance View들을 검색할 수 있다. 프로퍼티 값들을 변경시킬 수 있다. CONTROL 단계로 전이할 수 있다. CONTROL Media Recovery를 수행할 수 있다. META 단계로 전이할 수 있다. META Meta 데이터(Dictionary table)를 업그레이드할 수 있다. CONTROL 단계에서 불완전 복구를 한 경우 meta 구동 단계로 가는 과정에 온라인로그를 리셋(reset)하는데 사용할 수 있다. SERVICE 단계로 전이할 수 있다. SERVICE 일반 사용자로부터 접속을 받을 수 있다. SHUTDOWN NORMAL/IMMEDIATE/ABORT 를 수행할 수 있다. 14 ALTIBASE5 Administrator’s Manual 알티베이스의 종료 현재 구동중인 알티베이스 서버를 종료하려면 SHUTDOWN 구문을 사용한다. SHUTDOWN [NORMAL | IMMEDIATE | ABORT]; shutdown normal 과 shutdown immediate 는 알티베이스가 SERVICE 상태일 때만 수행 가능하며, shutdown abort 는 어떤 상태에서도 수행 가능하다. 알티베이스의 shutdown 명령어는 알티베이스(isql 포함)를 설치한 유닉스 계정으로만 수행이 가능하다. normal 서버를 정상적으로 종료하는 방식으로서, 클라이언트들이 모두 종료될 때까지 서버의 종료 작업을 대기하는 방법이다. 서버가 종료하면서 수행하는 일들은 클라이언트-서버간 통신 세션을 감지하는 쓰레드의 종료, 서비스 쓰레드의 종료, 자료저장 관리자의 종료, 그리고 알티베이스 서버 프로세스가 완전히 종료되기를 대기하는 일들을 수행함으로써 알티베이스 서버를 종료한다. 알티베이스 이 방식으로 종료했을 때 다음과 같은 메시지가 출력된다. iSQL(sysdba)> shutdown normal; Ok..Shutdown Proceeding.... TRANSITION TO PHASE : Shutdown Altibase [RP] Finalization : PASS shutdown normal success. immediate 서버를 종료할 때 현재 연결된 세션들을 강제로 단절시킨 다음, 알티베이스 서버가 현재 실행 중인 트랜잭션들을 철회(rollback) 시키고 알티베이스 서버를 종료하는 방법이다. iSQL(sysdba)> shutdown imediate Ok..Shutdown Proceeding.... TRANSITION TO PHASE : Shutdown Altibase [RP] Finalization : PASS shutdown immediate success. 서버 스크립트 명령을 이용하여 서버를 종료할 수 있다. $ server stop ----------------------------------- Altibase Client Query utility. Release Version 5.3.3.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. Al Rights Reserved. ----------------------------------- ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 알티베이스 구동 및 종료 15 Alter success. Alter success. Alter success. Ok..Shutdown Proceeding.... TRANSITION TO PHASE : Shutdown Altibase [RP] Finalization : PASS shutdown immediate success. abort 알티베이스 서버를 kill -9 시스템 명령을 사용하여 강제로 죽이는 방법이다. 이 방법으로 알티베이스 서버를 종료하면, 데이터베이스가 완전하지 못하여 다음에 알티베이스 서버를 실행할 때 데이터베이스 복구 과정을 거쳐야 한다. 또는 서버 스크립트 명령을 이용할 수 있다. iSQL(sysdba)> shutdown abort iSQL(sysdba)> 또는 서버 스크립트 명령을 이용할 수 있다. $ server kill -------------------------------------------- Altibase Client Query utility. Release Version 5.3.3.1 Copyright 20, ALTIBASE Corporation or its subsidiaries. Al Rights Reserved. -------------------------------------------- ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 $ 데이터 딕셔너리 17 3. 데이터 딕셔너리 알티베이스의 데이터 딕셔너리는 데이터베이스 객체 정보를 저장하는 메타 테이블과 시스템 프로세스 정보를 저장하는 프로세스 테이블로 나뉘어지며, 프로세스 정보는 다시 고정 테이블과 성능 뷰로 나뉘어진다. 본 장은 데이터베이스 객체 및 알티베이스 시스템 정보를 제공하는 데이터 딕셔너리에 대해 설명한다. 18 ALTIBASE5 Administrator’s Manual 메타 테이블 메타 테이블이란 데이터베이스 객체에 관한 모든 정보를 수록하기 위한 시스템 정의 테이블이다. 이 절에서는 메타 테이블의 종류 및 구조, 그리고 메타 테이블의 조회 및 변경에 대하여 설명한다. 구조 및 기능 메타 테이블은 시스템이 데이터베이스 객체를 관리하기 위해 생성하는 시스템 정의 테이블이다. 메타 테이블의 데이터 타입 및 레코드 저장 형태는 사용자가 생성하는 일반 테이블과 동일한 구조를 가지고 있다. 알티베이스는 구동시 데이터베이스 객체 정보를 로딩하고, DDL 문을 수행할 때 데이터베이스 객체 정보를 조회, 저장 및 변경하기 위해 메타 테이블을 사용한다. 메타 테이블의 소유자는 시스템 사용자(SYSTEM_)로 일반 사용자는 메타 테이블의 접근이 제한적이다. 메타 테이블 조회 DDL 문으로 데이터베이스 객체를 생성, 삭제 및 변경 시 메타 테이블의 레코드가 시스템에 의해 생성, 삭제 또는 변경된다. DDL 문 수행 후 반영된 데이터베이스 객체 정보는 메타 테이블을 통해 확인할 수 있다. 메타 테이블의 레코드는 일반 테이블과 같이 SELECT 문으로 조회가 가능하다. 메타 테이블 데이터 변경 메타 테이블 데이터에 대한 사용자의 명시적인 변경은 메타 테이블에 대한 DML 문을 통하여 수행할 수 있다. 다만 시스템에서 정의된 시스템 사용자(SYSTEM_ )만이 메타 테이블을 명시적으로 변경할 수 있다. 그러나 메타 테이블 정보가 변경되면 시스템 구동이 실패하거나, 데이터베이스 객체 정보를 상실하여 시스템에 치명적인 손상이 발생할 수 있다. 따라서 가급적 메타 테이블 데이터에 대한 사용자의 명시적인 변경은 피해야 하고, 불가피한 사정으로 메타 테이블 데이터 변경 시에는 변경 전에 반드시 데이터베이스 백업을 해야 하며, 사용자의 명시적인 메타 테이블 데이터 변경으로 인해 데이터 딕셔너리 19 발생하는 데이터베이스의 손상은 전적으로 사용자 책임이다. 메타 테이블 스키마 변경 새로운 DDL 문의 제공 또는 기능 변경 시 메타 테이블 스키마가 변경될 수 있다. 메타 테이블 스키마의 변경 특성에 따라 데이터베이스 마이그레이션이 필요한 경우와 알티베이스 구동 시 자동으로 메타 테이블 스키마를 변경하는 두 가지 경우로 구분된다. 알티베이스 하위 버전에서 상위 버전으로 업그레이드 시 이를 고려해야 한다. 메타 테이블 종류 메타 테이블의 이름은 SYS_로 시작하며 종류는 다음과 같다. 메타 테이블 이름 설명 SYS_COLUMNS_ 칼럼 메타 테이블 SYS_COMMENTS_ 설명을 달기 위한 주석 메타 테이블 SYS_CONSTRAINTS_ 제약 조건 메타 테이블 SYS_CONSTRAINT_COLUMNS_ 제약 조건 관련 칼럼 메타 테이블 SYS_DATABASE_ 데이터베이스 메타 테이블 SYS_DATABASE_LINKS_ 데이터베이스 링크 메타 테이블 SYS_DIRECTORIES_ 저장프로시저 내 파일 제어용 디렉토리 메타 테이블 SYS_DN_USERS_ 향후 확장 예정 SYS_DUMMY_ 내부 용도 SYS_GRANT_OBJECT_ 객체 권한 메타 테이블 SYS_GRANT_SYSTEM_ 시스템 권한 메타 테이블 SYS_INDEX_COLUMNS_ 인덱스 키 칼럼 메타 테이블 SYS_INDEX_PARTITIONS_ 인덱스 파티션 메타 테이블 SYS_INDICES_ 인덱스 메타 테이블 SYS_LOBS_ LOB 칼럼의 메타 테이블 SYS_PART_INDICES_ 파티션드 인덱스 메타 테이블 SYS_PART_KEY_COLUMNS_ 파티셔닝 키 메타 테이블 SYS_PART_LOBS_ 파티션별 LOB 칼럼 메타 테이블 SYS_PART_TABLES_ 파티션드 테이블 메타 테이블 SYS_PRIVILEGES_ 권한 메타 테이블 20 ALTIBASE5 Administrator’s Manual 메타 테이블 이름 설명 SYS_PROCEDURES_ 저장 프로시저 및 함수 메타 테이블 SYS_PROC_PARAS_ 저장 프로시저 및 함수의 파라미터 메타 테 이블 SYS_PROC_PARSE_ 저장 프로시저 및 함수 구문 메타 테이블 SYS_PROC_RELATED_ 저장 프로시저 및 함수 접근 테이블 메타 테 이블 SYS_REPLICATIONS_ 이중화 메타 테이블 SYS_REPL_HOSTS_ 이중화 호스트 메타 테이블 SYS_REPL_ITEMS_ 이중화 테이블 메타 테이블 SYS_REPL_OFFLINE_DIR_ 이중화 오프라인 옵션 관련 로그 디렉토리 메타 테이블 SYS_REPL_OLD_COLUMNS_ 이중화 송신 쓰레드의 이중화 칼럼 메타 테 이블 SYS_REPL_OLD_INDEX_COLUMNS_이중화 송신 쓰레드의 이중화 인덱스 칼럼 메타 테이블 SYS_REPL_OLD_INDICES_ 이중화 송신 쓰레드의 이중화 인덱스 메타 테이블 SYS_REPL_OLD_ITEMS_ 이중화 송신 쓰레드의 이중화 테이블 메타 테이블 SYS_REPL_RECOVERY_INFOS_ 복구를 위한 로그 정보 메타 테이블 SYS_SYNONYMS_ 시노님 메타 테이블 SYS_TABLES_ 테이블의 메타 테이블 SYS_TABLE_PARTITIONS_ 테이블의 파티션 메타 테이블 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_XA_HEURISTIC_TRANS_ 전역(global) 트랜잭션 메타 테이블 사용하지 않는 메타 테이블 알티베이스는 GIS 와 관련한 메타 테이블을 다음과 같이 제공한다. 이들 테이블은 STO_로 시작하며, 현재 사용하지 않는다. 데이터 딕셔너리 21 STO_COLUMNS_ STO_DATUMS_ STO_ELLIPSOIDS_ STO_GEOCCS_ STO_GEOGCS_ STO_PRIMEMS_ STO_PROJCS_ STO_PROJECTIONS_ STO_SRS_ STO_USER_COLUMNS_ 22 ALTIBASE5 Administrator’s Manual 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) 기본 값 STORE_TYPE CHAR(1) 칼럼의 저장 타입 V: 가변(Variable) 방식 F: 고정(Fixed) 방식 L : LOB 칼럼 IN_ROW_SIZE INTEGER 메모리 테이블의 VARCHAR 칼럼의 데 이터를 저장할 때 고정 영역에 저장할 데이터 길이를 지정한다. REPL_CONDITION INTEGER 칼럼이 가진 이중화 조건 수 칼럼 정보 COLUMN_ID 칼럼 식별자로 시스템 시퀀스에 의해 자동으로 부여되는 식별자이다. DATA_TYPE 데이터 타입의 식별자이다. 각 데이터 타입별 식별자 값은 다음과 같다. Data Type 값 CHAR 1 VARCHAR 12 데이터 딕셔너리 23 NCHAR -8 NVARCHAR -9 NUMERIC 2 DECIMAL 2 FLOAT 6 NUMBER 6 DOUBLE 8 REAL 7 BIGINT -5 INTEGER 4 SMALLINT 5 DATE 9 BLOB 30 CLOB 40 BYTE 20001 NIBBLE 20002 BIT -7 VARBIT -100 GEOMETRY 10003 데이터 타입에 대한 자세한 내용은 SQL Users Manual을 참조한다. LANG_ID 문자형 타입(CHAR, VARCHAR)의 언어 속성 정보를 나타내는 칼럼이다. OFFSET 레코드 내 칼럼의 물리적 저장 시작 위치이다. 레코드의 물리적 저장 크기를 계산할 때 칼럼의 오프셋과 사이즈 값을 이용해 계산한다. SIZE 레코드 내 칼럼의 사이즈로 칼럼의 타입 및 사용자가 지정하는 프리시즌 등에 따라 시스템이 계산하여 정해진 물리적 저장 사이즈이다. USER_ID 칼럼이 속한 테이블 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. TABLE_ID 칼럼이 속한 테이블 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. PRECISION 24 ALTIBASE5 Administrator’s Manual 사용자가 지정하거나 또는 시스템이 기본값으로 부여한 데이터 타입의 프리시즌이다. 문자형 타입의 경우 사용자가 정의한 문자형 타입의 길이이다. SCALE 사용자가 지정하거나 또는 시스템이 기본값으로 부여한 데이터 타입의 스케일이다. 타입에 따라 이 값은 사용하지 않을 수 있다. COLUMN_ORDER 한 테이블 내에서 해당 칼럼의 생성 순서이다. CREATE TABLE 문에서 칼럼을 명시한 순서대로 칼럼이 생성된다. ALTER TABLE 문으로 칼럼을 추가한 경우 이 칼럼은 해당 테이블의 마지막 칼럼으로 생성된다. COLUMN_NAME 사용자가 테이블 생성 시 명시한 칼럼의 이름이다. IS_NULLABLE 칼럼의 NULL 허용 여부를 나타낸다. 칼럼 생성 시 사용자가 명시적으로 칼럼의 NULL 허용 여부를 명시할 수 있으며 명시하지 않을 경우 NULL 을 허용한다. DEFAULT_VAL 레코드 삽입 시 칼럼의 값을 명시하지 않을 경우 기본 칼럼 값을 나타낸다. 기본값은 칼럼 생성 시 사용자가 명시해야 그 값이 설정되고 사용자가 기본값을 명시하지 않을 경우 NULL 이 삽입된다. STORE_TYPE 칼럼을 물리적으로 저장할 때 레코드 내에 기록할 수도 있고, 레코드 내에는 칼럼의 저장 위치 정보만을 가지고 실제 칼럼 값은 다른 페이지에 기록할 수도 있다. 한 칼럼의 물리적 저장 크기가 크거나 레코드별 칼럼의 저장 크기 변동이 잦은 칼럼의 경우 칼럼 정의 시 VARIABLE 옵션을 사용하면 레코드와 물리적으로 다른 페이지에 해당 칼럼을 저장하도록 지정할 수 있다. 일반적으로 VARCHAR 타입의 경우 문자열 길이가 긴 칼럼의 경우 이 옵션을 사용한다. 이 칼럼은 이러한 VARIABLE 옵션 지정 여부를 나타낸다. IN_ROW_SIZE 메모리 테이블에 사용된 VARCHAR 타입 데이터의 기본 in row size 를 나타낸다. in row size 는 VARCHAR 데이터 타입의 칼럼에 데이터가 들어갈 때 데이터 길이가 이 값보다 작거나 같으면 데이터 딕셔너리 25 고정(fixed) 영역에 저장하고, 이 보다 긴 경우에는 가변(variable) 영역에 들어가도록 지정하는 속성이다. 디스크 테이블의 경우 이 값은 0 이다. in row size 나 VARCHAR 타입에 대한 자세한 사항은 SQL User’s Manual 의 데이터 타입 부분을 참조한다. REPL_CONDITION 이중화에서 조건절을 사용할 때 칼럼이 몇 개의 이중화 조건을 갖고 있는지를 나타낸다. 참조 테이블 SYS_USERS_ SYS_TABLES_ STO_USER_COLUMNS_ 26 ALTIBASE5 Administrator’s Manual SYS_COMMENTS_ 사용자가 정의한 테이블, 뷰 및 그에 소속된 칼럼에 대한 설명, 즉 주석을 기록하는 메타 테이블이다. Column name Type Description USER_NAME VARCHAR(40) 사용자 이름 TABLE_NAME VARCHAR(40) 테이블 이름 COLUMN_NAME VARCHAR(40) 칼럼 이름 COMMENTS VARCHAR(4000) 주석 내용 칼럼 정보 USER_NAME 테이블 소유자 이름으로 SYS_USERS_ 메타 테이블의 USER_NAME 값과 동일하다. TABLE_NAME 테이블(뷰)의 이름으로 SYS_TABLES_ 메타 테이블의 TABLE_NAME 값과 동일하다. COLUMN_NAME 테이블(뷰)에 속한 칼럼의 이름으로 SYS_COLUMNS_ 메타 테이블의 COLUMN_NAME 값과 동일하다. 단, 주석이 테이블(뷰)에 대한 설명일 경우에는 COLUMN_NAME 은 NULL 값을 가진다. COMMENTS 사용자가 기록한 주석 내용이다. 참조 테이블 SYS_USERS_ SYS_TABLES_ SYS_COLUMNS_ 데이터 딕셔너리 27 SYS_CONSTRAINTS_ 테이블의 제약 조건에 관한 정보를 포함하는 메타 테이블이다. Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 CONSTRAINT_ID INTEGER 제약조건 식별자 CONSTRAINT_NAME VARCHAR(40) 제약조건 이름 CONSTRAINT_TYPE INTEGER 제약조건 타입 INDEX_ID INTEGER 제약조건의 인덱스 식별자 COLUMN_CNT INTEGER 제약조건의 칼럼 개수 REFERENCED_TABLE_ID INTEGER parent table의 식별자 REFERENCED_INDEX_ID INTEGER 관련된 제약 조건 식별자 DELETE_RULE INTEGER Delete CASCADE 동작 여부 0 : No action 1 : Delete CASCADE 칼럼 정보 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 28 ALTIBASE5 Administrator’s Manual 3: PRIMARY KEY 4: NULL 5: TIMESTAMP 6: LOCAL UNIQUE 각 제약 조건의 기능에 대한 설명은 SQL User’s Manual 의 CREATE TABLE 문에 있는 column constraint 설명을 참조한다. INDEX_ID UNIQUE 또는 PRIMARY KEY 제약 조건과 같이 제약조건의 정의가 인덱스 생성을 필요로 할 때 시스템 내부적으로 인덱스를 생성하게 되고 이때 생성한 인덱스의 식별자로 SYS_INDICES_ 메타 테이블의 INDEX_ID 값과 동일하다. COLUMN_CNT 제약 조건과 관련된 칼럼들의 개수를 나타낸다. 예를 들어 UNIQUE (i1,i2,i3) 과 같은 제약 조건을 생성하였다면 이 값은 3 이된다. REFERENCED_TABLE_ID 참조 제약조건(Foreign key constraint)의 경우 제약 조건을 정의하는 테이블 외에 다른 테이블을 참조하므로 이 때 참조하는 테이블의 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. REFERENCED_INDEX_ID 참조 제약조건의 경우 참조하는 테이블에 UNIQUE 또는 PRIMARY KEY 제약조건이 존재해야 하는데, 이 제약조건의 식별자 값으로 SYS_CONSTRAINTS_ 메타 테이블의 CONSTRAINT_ID 값과 동일하다. 참조 테이블 SYS_USERS_ SYS_TABLES_ SYS_INDICES_ 데이터 딕셔너리 29 SYS_CONSTRAINT_COLUMNS_ 사용자 테이블에 정의된 모든 제한조건에 걸려있는 칼럼의 정보를 기록하고 있는 메타 테이블이다. Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 CONSTRAINT_ID INTEGER 제약조건 식별자 CONSTRAINT_COL_ORDER INTEGER 제약 조건 칼럼 순서 COLUMN_ID INTEGER 칼럼 식별자 칼럼 정보 USER_ID 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. TABLE_ID 제약조건을 정의한 테이블의 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. 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_USERS_ 30 ALTIBASE5 Administrator’s Manual SYS_TABLES_ SYS_CONSTRAINTS_ SYS_COLUMNS_ 데이터 딕셔너리 31 SYS_DATABASE_ 데이터베이스 이름과 메타 버전 정보를 기록하는 테이블이다. Column name Type Description DB_NAME VARCHAR(40) 데이터베이스 이름 OWNER_DN VARCHAR(2048) 향후 확장 예정 META_MAJOR_VER INTEGER 데이터베이스 메타 테이블 버전(주 버전) META_MINOR_VER INTEGER 데이터베이스 메타 테이블 버전(부 버전) META_PATCH_VER INTEGER 데이터베이스 메타 테이블 버전(패치 버전) 칼럼 정보 DB_NAME 현재 알티베이스가 단일 데이터베이스 만을 지원하기 때문에 데이터베이스 이름은 저장되지 않는다. META_MAJOR_VER 메타 테이블의 베이스가 변경될 경우 증가하는 값으로, 데이터베이스의 이 버전과 알티베이스 바이너리의 해당 버전이 일치하지 않은 경우 데이터베이스 마이그레이션 작업을 요한다. META_MINOR_VER 메타 테이블의 일부 스키마 또는 레코드 값이 변경될 경우 증가하는 값으로 데이터베이스의 이 버전과 알티베이스의 해당 버전이 다른 경우 내부적으로 값을 비교해 상위 버전으로 메타 테이블에 대해 자동 업그레이드를 수행한다. META_PATCH_VER 메타 테이블 패치 버전으로 현재 이 값은 사용하지 않는다. 32 ALTIBASE5 Administrator’s Manual SYS_DATABASE_LINKS_ 데이터베이스 링크 정보를 기록하는 메타 테이블이다 Column name Type Description USER_ID INTEGER 사용자 식별자 LINK_ID INTEGER 데이터베이스 링크 식별자 LINK_OID BIGINT 데이터베이스 링크 객체 식별자 LINK_NAME VARCHAR(40) 데이터베이스 링크 이름 USER_MODE INTEGER 원격 서버로의 접근방법 REMOTE_USER_ID VARCHAR(40) 원격 데이타베이스 사용자 계정 REMOTE_USER_PWD BYTE(40) 원격 데이타베이스 사용자 비밀번호 LINK_METHOD INTEGER 연결 방법 LINK_INFO VARCHAR(400) 연결 정보 칼럼 정보 USER_ID 데이터베이스 링크를 생성한 사용자의 식별자이다. LINK_ID 데이터베이스 링크 식별자이다. LINK_OID 데이터베이스 링크의 객체 식별자이다. LINK_NAME 사용자가 데이터베이스 링크 생성 시에 명시한 데이터베이스 링크 이름을 나타낸다. USER_MODE 원격 서버로의 접근 방법을 나타낸다. 0 : DEDICATE USER MODE 1 : CURRENT USER MODE(향후 지원 예정) REMOTE_USER_ID 원격 데이터베이스 서버에 접근할 때 사용하는 원격 서버 사용자 계정을 나타낸다. REMOTE_USER_PWD 원격 데이터베이스 서버에 접근할 때 사용하는 원격 서버 사용자 데이터 딕셔너리 33 비밀번호를 나타낸다. 비밀번호는 복호화가 가능한 암호화 알고리즘으로 암호화하여 저장한다. LINK_METHOD 원격 서버와 연결하는 방법을 나타낸다. 0 : ODBC 1 : (향후 지원 예정) LINK_INFO 원격 서버와의 연결시에 필요한 정보를 나타낸다. 34 ALTIBASE5 Administrator’s Manual SYS_DIRECTORIES_ 저장프로시저 내의 파일 제어를 위한 디렉토리 정보를 기록하는 테이블이다. Column name Type Description DIRECTORY_ID BIGINT 디렉토리 식별자 USER_ID INTEGER 사용자 식별자 DIRECTORY_NAME VARCHAR(40) 디렉토리 이름 DIRECTORY_PATH VARCHAR(4000) 시스템 내 디렉토리의 절대 경로 CREATED DATE 디렉토리가 생성된 시간 LAST_DDL_TIME DATE 디렉토리에 대해 DDL 변경작업이 마지막 으로 일어난 시간 칼럼 정보 DIRECTORY_ID 디렉토리 식별자로 시스템 내 유일값을 가진다. USER_ID 디렉토리 소유자의 사용자 식별자를 나타낸다. DIRECTORY_NAME 디렉토리 이름으로 시스템 내 유일값을 가진다. DIRECTORY_PATH 디렉토리가 저장된 시스템 내 절대 경로로 CREATE DIRECTORY 문 수행 시 사용자가 명시적으로 지정한다. LAST_DDL_TIME 디렉토리에서 DDL 변경 작업이 마지막으로 일어난 시간을 나타낸다. 데이터 딕셔너리 35 SYS_ENCRYPTED_COLUMNS_ 보안 칼럼 설정에 따라 추가되는 보안 정보들을 보안 칼럼 단위로 관리한다. Column name Type Description USER_ID INTEGER 보안 대상 칼럼의 소유자 TABLE_ID INTEGER 보안 칼럼이 속한 테이블의 식별자 COLUMN_ID INTEGER 보안 대상 칼럼의 식별자 ENCRYPT_PRECISION INTEGER 보안 칼럼의 precision POLICY_NAME VARCHAR(16) 보안 정책의 이름 POLICY_CODE VARCHAR(128) 보안 정책에 대한 검증 코드 36 ALTIBASE5 Administrator’s Manual SYS_SECURITY_ 보안 모듈의 상태 정보를 관리한다. Column name Type Description MODULE_NAME VARCHAR(24) 보안 모듈의 이름 MODULE_VERSION VARCHAR(40) 보안 모듈의 버전 ECC_POLICY_NAME VARCHAR(16) ECC 정책의 이름 ECC_POLICY_CODE VARCHAR(64) ECC 정책에 대한 검증 코드 SYS_SECURITY_ 메타 테이블의 데이터 유무를 통해 보안 모듈의 연동 여부를 확인할 수 있다. 보안 모듈이 정상적으로 연동되어 있는 경우 SYS_SECURITY_ 메타 테이블에 보안 모듈 프로퍼티들에 대한 정보가 나타나며, 보안 모듈이 연동되어 있지 않은 경우에는 SYS_SECURITY_ 메타 테이블에 레코드가 존재하지 않는다. 데이터 딕셔너리 37 SYS_GRANT_OBJECT_ 사용자에게 부여된 객체 권한 정보를 포함한다 Column name Type Description GRANTOR_ID INTEGER 권한 부여자의 식별자 GRANTEE_ID INTEGER 권한 피수여자의 식별자 PRIV_ID INTEGER 권한 식별자 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 해당 권한과 관련된 객체의 식별자로, 메타 테이블에 저장된 대상 객체의 식별자와 1:1 관계이다. 대상 객체가 테이블, 뷰 또는 시퀀스인 경우에는 SYS_TABLES_의 TABLE_ID 와 매핑되고, 저장 프로시저이거나 저장 함수일 경우에는 SYS_PROCEDURES_의 PROC_OID 와 매핑된다. 38 ALTIBASE5 Administrator’s Manual OBJ_TYPE 해당 권한과 관련된 객체의 종류를 나타내는 값이다. T: 테이블 S: 시퀀스 P: 저장 프로시저 또는 저장 함수 V: 뷰 WITH_GRANT_OPTION 권한 피수여자가 다른 사용자에게 해당 권한을 부여할 수 있는 권한이 있는지 여부를 나타낸다. 참조 테이블 SYS_USERS_ SYS_PRIVILEGES_ SYS_TABLES_ SYS_PROCEDURES_ 데이터 딕셔너리 39 SYS_GRANT_SYSTEM_ 사용자에게 부여된 시스템 권한 정보를 포함한다. Column name Type Description GRANTOR_ID INTEGER 권한 부여자의 식별자 GRANTEE_ID INTEGER 권한 피수여자의 식별자 PRIV_ID INTEGER 권한 식별자 칼럼 정보 GRANTOR_ID 권한을 부여한 사용자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. GRANTEE_ID 권한을 부여받은 사용자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. PRIV_ID 권한 식별자로 SYS_PRIVILEGES_ 메타 테이블의 PRIV_ID 값과 동일하다. 참조 테이블 SYS_USERS_ SYS_PRIVILEGES_ 40 ALTIBASE5 Administrator’s Manual 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 테이블 식별자 칼럼 정보 USER_ID 인덱스 소유자의 사용자 식별자로 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 값과 동일하다. 데이터 딕셔너리 41 참조 테이블 SYS_USERS_ SYS_TABLES_ SYS_COLUMNS_ SYS_INDICES_ 42 ALTIBASE5 Administrator’s Manual SYS_INDEX_PARTITIONS_ 인덱스 파티션을 관리하는 메타 테이블이다. Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 INDEX_ID INTEGER 인덱스 번호 TABLE_PARTITION_ID INTEGER 테이블 파티션 식별자 INDEX_PARTITION_ID INTEGER 인덱스 파티션 식별자 INDEX_PARTITION_NAME VARCHAR(40) 인덱스 파티션 이름 PARTITION_MIN_VALUE VARCHAR(4000)파티션 최소 기준값 문자열 (지역 인덱스인 경우 NULL) PARTITION_MAX_VALUE VARCHAR(4000)파티션 최대 기준값 문자열 (지역 인덱스인 경우 NULL) TBS_ID INTEGER 테이블스페이스 식별자 칼럼 정보 USER_ID 인덱스 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. TABLE_ID 인덱스를 생성한 테이블의 테이블 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. INDEX_ID 인덱스 식별자로 SYS_INDICES_ 메타 테이블의 INDEX_ID 값과 동일하다. TABLE_PARTITION_ID 테이블 파티션의 식별자이다. INDEX_PARTITION_ID 인덱스 파티션의 식별자이다. INDEX_PARTITION_NAME 사용자가 명시한 인덱스 파티션의 이름이다. PARTITION_MIN_VALUE 파티션의 최소 기준값이 되는 문자열로, 지역(LOCAL) 인덱스인 데이터 딕셔너리 43 경우에는널(NULL)이다. PARTITION_MAX_VALUE 파티션의 최대 기준값이 되는 문자열로, 지역(LOCAL) 인덱스인 경우에는널(NULL)이다. TBS_ID 인덱스가 저장되는 테이블스페이스의 식별자이다. 참조 테이블 SYS_USERS_ SYS_TABLES_ SYS_INDICES_ SYS_TABLE_PARTITIONS_ 44 ALTIBASE5 Administrator’s Manual 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 테이블스페이스 식별자 IS_PARTITIONED CHAR(1) 파티셔닝 여부 CREATED DATE 인덱스가 생성된 시간 LAST_DDL_TIME DATE 인덱스에 대해 마지막으로 DDL 변경 작 업이 일어난 시간 칼럼 정보 USER_ID 인덱스 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. TABLE_ID 인덱스를 생성한 테이블의 테이블 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. INDEX_ID 인덱스 식별자로 시스템 시퀀스에 의해 자동으로 부여되는 식별자이다. INDEX_NAME 인덱스의 이름이다. INDEX_TYPE 인덱스 타입으로 1 이면 B-TREE 인덱스 타입이고 2 이면 R-TREE 인덱스 타입이다. 데이터 딕셔너리 45 IS_UNIQUE 중복 키 값 허용여부를 나타낸다. T: 중복 키 값을 허용하지 않는다. F: 중복 키 값을 허용한다. COLUMN_CNT 인덱스 키 칼럼의 개수를 나타낸다. IS_RANGE 범위 검색 가능 여부를 나타낸다. T: 범위 검색 가능 F: 범위 검색 불가능 IS_PERS 서버 구동 시 테이블로부터 데이터를 읽어 모든 인덱스를 구축하는데, 서버 종료 시 인덱스를 디스크에 저장하고 서버 재 구동 시 디스크에 저장된 인덱스 파일로부터 인덱싱 정보를 바로 읽어 서버 구동 시 인덱스 구축 비용을 절약할 수 있다. 디스크에 인덱스 파일을 저장하는 인덱스를 영구 인덱스라고 하고 인덱스 생성 시 사용자가 이를 명시할 수 있다. T: 영구 인덱스 F: 비영구 인덱스 TBS_ID 인덱스가 저장되는 테이블스페이스의 식별자이다. IS_PARTITIONED 테이블의 파티셔닝 여부를 나타내는 식별자이다. ‘Y’는 파티셔닝이 된 것이고, ‘N’은 파티셔닝이 되어있지 않은 것이다. 참조 테이블 SYS_USERS_ SYS_TABLES_ 46 ALTIBASE5 Administrator’s Manual SYS_LOBS_ 테이블에 정의된 LOB 칼럼의 정보를 기록하는 메타 테이블이다. Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 COLUMN_ID INTEGER 칼럼 식별자 TBS_ID INTEGER 테이블스페이스 시별자 LOGGING CHAR(1) 향후 확장 예정 BUFFER CHAR(1) 향후 확장 예정 IS_DEFAULT_TBS CHAR(1) LOB 칼럼 저장용 테이블스페이스 지정 여부 칼럼 정보 USER_ID LOB 칼럼 소유자의 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. TABLE_ID LOB 칼럼이 속한 테이블의 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. COLUMN_ID LOB 칼럼의 식별자이다. TBS_ID LOB 칼럼이 속한 테이블스페이스의 식별자이다. IS_DEFAULT_TBS LOB 칼럼 생성 시, 사용자가 LOB 칼럼이 저장될 테이블스페이스를 지정했는지를 나타낸다. 참조 테이블 SYS_USERS_ SYS_TABLES_ SYS_COLUMNS_ 데이터 딕셔너리 47 SYS_PART_INDICES_ 파티션드 인덱스를 관리하는 메타 테이블이다. SYS_INDICES_의 IS_PARTITIONED 가 ‘Y’로 되어 있는 파티션드 인덱스에 대한 정보이다. Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 INDEX_ID INTEGER 인덱스 식별자 PARTITION_TYPE INTEGER 파티션 타입 IS_LOCAL_UNIQUE CHAR(1) 로컬 유니크 여부 칼럼 정보 USER_ID 인덱스 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. TABLE_ID 인덱스를 생성한 테이블의 테이블 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. INDEX_ID 인덱스 식별자로 SYS_INDICES_ 메타 테이블의 INDEX_ID 값과 동일하다. PARTITION_TYPE 파티션 타입을 지역(LOCAL)과 글로벌(GLOBAL), 두 가지로 나타낸다. 그러나 현재 파티션 타입이 글로벌을 지원하지 않으므로 항상 0 이다. 0 : LOCAL 1 : GLOBAL IS_LOCAL_UNIQUE 로컬 유니크 여부를 묻는 것으로, ‘Y’ 또는 ‘N’으로 저장한다. Y : 로컬 유니크 인덱스이다. N : 로컬 유니크 인덱스가 아니다. 48 ALTIBASE5 Administrator’s Manual 참조 테이블 SYS_USERS_ SYS_TABLES_ SYS_INDICES_ 데이터 딕셔너리 49 SYS_PART_KEY_COLUMNS_ 파티셔닝 키를 관리하는 메타 테이블이다. Column name Type Description USER_ID INTEGER 사용자 식별자 PARTITION_OBJ_ID INTEGER 파티션 객체 식별자 COLUMN_ID INTEGER 칼럼 식별자 OBJECT_TYPE INTEGER 객체 타입 PART_COL_ORDER INTEGER 파티션 키 순서 칼럼 정보 USER_ID 인덱스 소유자의 사용자 식별자로 SYS_PART_INDICES_ 메타 테이블의 USER_ID 값과 동일하다. PARTITION_OBJ_ID 파티션 객체 식별자로 SYS_TABLES_의 TABLE_ID 값과 동일하다. COLUMN_ID 인덱스를 생성한 테이블의 테이블 식별자로 SYS_COLUMNS_ 메타 테이블의 COLUMN_ID 값과 동일하다. OBJECT_TYPE 객체 타입을 나타내는 식별자이다. 0 : 테이블(TABLE) 1 : 인덱스(INDEX) 참조 테이블 SYS_PART_INDICES_ SYS_TABLE_PARTITIONS_ SYS_COLUMNS_ 50 ALTIBASE5 Administrator’s Manual SYS_PART_LOBS_ 파티션별 LOB 칼럼을 관리하는 메타 테이블이다. Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 PARTITION_ID INTEGER 파티션 번호 COLUMN_ID INTEGER 칼럼 식별자 TBS_ID INTEGER 테이블스페이스 식별자 LOGGING CHAR(1) 향후 확장 예정 BUFFER CHAR(1) 향후 확장 예정 칼럼 정보 USER_ID LOB 칼럼 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. TABLE_ID LOB 칼럼이 속한 테이블의 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. PARTITION_ID LOB 칼럼이 속한 파티션의 식별자이다. COLUMN_ID LOB 칼럼의 식별자이다. TBS_ID LOB 칼럼이 테이블스페이스의 식별자이다. 참조 테이블 SYS_USERS_ SYS_TABLES_ SYS_PART_TABLES_ SYS_COLUMNS_ 데이터 딕셔너리 51 SYS_PART_TABLES_ 파티션드 테이블을 관리하는 메타 테이블이다. SYS_PART_TABLE_에 들어가는 테이블 정보는 SYS_TABLES_에서 IS_PARTITIONED 가 ‘Y’로 되어 있는 파티션드 테이블에 대한 정보이다. Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 PARTITION_METHOD INTEGER 파티션 메소드 PARTITION_KEY_COUNT INTEGER 파티션 키 개수 ROW_MOVEMENT CHAR(1) 갱신된 레코드에 대한 파티션 이동 허용 여 부 칼럼 정보 USER_ID 인덱스 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. TABLE_ID 인덱스를 생성한 테이블의 테이블 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. PARTITION_METHOD 파티션 메소드를 나타낸다. 0 : 범위(RANGE) 1 : 해시(HASH) 2 : 리스트(LIST) ROW_MOVEMENT 파티션 키가 갱신(UPDATE)될 때, 갱신된 레코드의 파티션이 이동될 수 있는지에 대한 허가 여부를 결정하는 것이다. T : 이동 허가 F : 이동 불허가 참조 테이블 52 ALTIBASE5 Administrator’s Manual SYS_USERS_ SYS_TABLES_ 데이터 딕셔너리 53 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 권한의 이름이다. 54 ALTIBASE5 Administrator’s Manual 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_TYP E 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_DDL_TIME DATE 저장 프로시저에 DDL 변경 작업이 마지 막으로 일어난 시간 칼럼 정보 USER_ID 저장 프로시저 또는 저장 함수 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. PROC_OID 저장 프로시저 또는 저장 함수의 식별자로 시스템에 의해 자동으로 부여되는 식별자이다. PROC_NAME 저장 프로시저 또는 저장 함수의 이름이다. 데이터 딕셔너리 55 OBJECT_TYPE 저장 프로시저와 저장 함수를 구별하는 값으로 저장 함수는 저장 프로시저와 달리 하나의 리턴 값을 가진다. 0: 저장 프로시저 1: 저장 함수 3: 타입 세트 STATUS 저장프로시저 또는 함수의 실행 가능 여부를 나타내는 값으로 이 값이 0(VALID)이어야 실행가능하다. 저장 프로시저 또는 저장 함수가 접근하는 객체에 대한 DDL 문을 수행하면 관련 저장 프로시저 또는 저장 함수는 무효한 상태가 된다. 예를 들어 저장 프로시저가 접근하는 테이블에 새로운 칼럼이 추가되면 관련 저장 프로시저는 재 컴파일 후 VALID 상태가 되면 실행할 수 있다. 0: VALID 1: INVALID PARA_NUM 저장 프로시저 또는 저장 함수의 정의된 파라미터 개수를 나타낸다. RETURN_DATA_TYPE 저장 함수의 리턴값에 대한 데이터 타입의 식별자로 데이터타입 별 식별자 값은 SYS_COLUMNS_ 메타 테이블의 DATA_TYPE 칼럼 설명을 참조한다. 데이터 타입에 대한 자세한 내용은 SQL Users Manual 을 참조한다. RETURN_LANG_ID 문자형 타입(CHAR, VARCHAR)의 언어 속성 정보를 나타내는 칼럼이다. RETURN_SIZE 데이터 타입의 물리적 크기이다. RETURN_PRECISION 사용자가 지정하거나 또는 시스템이 기본 값으로 부여한 데이터 타입의 프리시즌이다. 문자형 타입의 경우 사용자가 정의한 문자형 타입의 길이이다. RETURN_SCALE 56 ALTIBASE5 Administrator’s Manual 사용자가 지정하거나 또는 시스템이 기본 값으로 부여한 데이터 타입의 스켈이다. 타입에 따라 이 값은 사용하지 않을 수 있으며 데이터 타입의 프리시즌과 스케일에 대한 상세한 내용은 SQL Users Manual 을 참조한다. PARSE_NO 저장 프로시저 또는 저장 함수 구문은 SYS_PROC_PARSE_ 메타 테이블에 나눠져 여러 레코드로 저장되는데 저장하는 레코드의 수를 나타내는 값이다. PARSE_LEN 저장 프로시저 또는 저장 함수 구문은 SYS_PROC_PARSE_ 메타 테이블에 나눠져 여러 레코드로 저장되는데 저장하는 전체 구문의 문자열 길이이다. LAST_DDL_TIME 저장 프로시저에 DDL 변경 작업이 마지막으로 일어난 시간을 나타낸다. 참조 테이블 SYS_USERS_ 데이터 딕셔너리 57 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) 파라미터의 기본 값 칼럼 정보 USER_ID 저장 프로시저 또는 저장 함수 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. PROC_OID 저장 프로시저 또는 저장 함수의 식별자로 SYS_PROCEDURES_ 메타 테이블의 PROC_OID 값과 동일하다. PARA_NAME 파라미터의 이름이다. PARA_ORDER 여러 파라미터들 중 해당 파라미터가 몇번째 정의된 파라미터인지를 나타내는 값이다. INOUT_TYPE 저장 프로시저 또는 저장 함수의 파라미터는 입력인자, 출력인자, 입출력인자로 정의할 수 있는데 이를 나타내는 값이다. 0: IN 58 ALTIBASE5 Administrator’s Manual 1: OUT 2: IN OUT DATA_TYPE 파라미터 데이터 타입의 식별자로 데이터타입 별 식별자 값은 SYS_COLUMNS_ 메타 테이블의 DATA_TYPE 칼럼 설명을 참조한다. 데이터 타입에 대한 자세한 내용은 SQL Users Manual을 참조한다. LANG_ID 문자형 타입(CHAR, VARCHAR)의 언어 속성 정보를 나타내는 칼럼이다. SIZE 데이터 타입의 물리적 크기이다. PRECISION 사용자가 지정하거나 또는 시스템이 기본 값으로 부여한 데이터 타입의 프리시즌이다. 문자형 타입의 경우 사용자가 정의한 문자형 타입의 길이이다. SCALE 사용자가 지정하거나 또는 시스템이 기본 값으로 부여한 데이터 타입의 스케일이다. 타입에 따라 이 값은 사용하지 않을 수 있으며 데이터 타입의 프리시즌과 스케일에 대한 상세한 내용은 SQL Users Manual 을 참조한다. DEFAULT_VAL 파라미터 정의 시 사용자가 지정하는 파라미터 기본 값이다. 참조 테이블 SYS_USERS_ SYS_PROCEDURES_ 데이터 딕셔너리 59 SYS_PROC_PARSE_ 사용자가 정의한 저장 프로시저와 저장 함수들의 파싱할 텍스트 정보를 기록하는 테이블이다. Column name Type Description USER_ID INTEGER 저장 프로시저 또는 저장 함수의 소유 자 식별자 PROC_OID BIGINT 저장 프로시저 객체 식별자 SEQ_NO INTEGER 나뉘어 저장된 구문 레코드의 순서 PARSE VARCHAR(100) 저장 프로시저 또는 저장 함수의 구문 칼럼 정보 USER_ID 저장 프로시저 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. PROC_OID 저장 프로시저 또는 저장 함수의 식별자로 SYS_PROCEDURES_ 메타 테이블의 PROC_OID 값과 동일하다. SEQ_NO 한 저장 프로시저의 구문 정보를 SYS_PROC_PARSE_에 여러 개의 레코드로 저장할 때 이들 레코드의 순서이다. PARSE 저장 프로시저 또는 저장 함수 구문의 문자열이다. 한 PROC_OID 값으로 레코드들을 검색하여 SEQ_NO 순서대로 PARSE 값을 합치면 저장 프로시저 전체 구문을 생성할 수 있다. 참조 테이블 SYS_USERS_ SYS_PROCEDURES_ 60 ALTIBASE5 Administrator’s Manual 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 임을 명시하게 된다. 칼럼 정보 USER_ID 저장 프로시저 또는 저장 함수 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. PROC_OID 저장 프로시저 또는 저장 함수의 식별자로 SYS_PROCEDURES_ 메타 테이블의 PROC_OID 값과 동일하다. RELATED_USER_ID 저장 프로시저가 접근하는 객체 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. RELATED_OBJECT_NAME 저장 프로시저가 접근하는 객체 RELATED_OBJECT_TYPE 저장 프로시저가 접근하는 객체의 타입을 나타낸다. 저장 프로시저가 접근하는 객체의 종류는 다음과 같다. 데이터 딕셔너리 61 0 : 저장 프로시져 1 : 저장 함수 2 : 테이블, 시퀀스, 뷰 3 : 타입세트 4 : 데이터베이스 링크 참조 테이블 SYS_USERS_ SYS_PROCEDURES_ SYS_TABLES_ 62 ALTIBASE5 Administrator’s Manual SYS_REPLICATIONS_ 이중화 관련 정보를 기록하고 있는 메타 테이블이다. Column name Type Description REPLICATION_NAME VARCHAR(40) 이중화 이름 LAST_USED_HOST_NO INTEGER 가장 최근에 사용한 원격 서버 HOST_COUNT INTEGER 원격 서버 개수 IS_STARTED INTEGER 이중화 시작 여부 XSN BIGINT 송신자의 전송시작 SN ITEM_COUNT INTEGER 이중화 대상 테이블 개수 CONFLICT_RESOLUTION INTEGER 이중화 Conflict Resolution 방법 REPL_MODE INTEGER 이중화 기본 모드 ROLE INTEGER 송신 쓰레드의 역할 OPTIONS INTEGER 이중화 부가 기능을 위한 플래그 INVALID_RECOVERY INTEGER 이중화 복구 가능 여부 칼럼 정보 REPLICATION_NAME 사용자가 이중화 생성 시 명시한 이중화 이름이다. LAST_USED_HOST_NO 가장 최근에 사용한 원격 서버의 번호로 SYS_REPL_HOSTS_ 메타 테이블의 HOST_NO 값과 동일하다. HOST_COUNT 이중화를 실행하는 원격 서버의 개수로 SYS_REPL_HOSTS_ 에 있는 IP 의 개수와 동일하다. IS_STARTED 이중화 시작 여부를 나타낸다. 0: 중지 1: 이중화 수행 중 XSN 리플리케이션이 시작되었을 때, 송신 쓰레드에서 로그 전송을 시작해야 할 SN 을 나타낸다. ITEM_COUNT 이중화 대상 테이블의 개수로 이 수만큼 해당 이중화에 대해 데이터 딕셔너리 63 SYS_REPL_ITEMS_ 메타 테이블의 레코드들이 존재한다. CONFLICT_RESOLUTION 이중화 Conflict Resolution 방법을 기록한다. 0: 기본 값 1: Master Server 로 동작 2: Slave Server 로 동작 이중화 Conflict Resolution 방법에 대한 자세한 기능은 Replication Users Manual을 참조한다. REPL_MODE 이중화 생성시에 지정한 이중화 기본 모드이다. ALTER REPLICATION … SET MODE 문으로 변경할 수 있다. 0: LAZY MODE (기본 값) 1: ACKED MODE 2: EAGER MODE 이중화 기본 모드는 ALTER SESSION SET REPLICATION 구문으로 세션의 이중화 모드를 설정하지 않았을 때 사용된다. 이중화 기본 모드에 관한 자세한 내용은 Replication Users Manual 을 참조하며, ALTER SESSION SET REPLICATION 구문에 관한 내용은 SQL User’s Manual을 참조한다. ROLE 송신 쓰레드의 역할을 나타낸다 0 : 이중화 1 : Log Analyzer. 자세한 내용은 Log Analyzer User's Manual 을 참고한다. OPTIONS 이중화 부가 기능으로 복구 및 오프라인 옵션에 대한 사용 여부를 기록하는 플래그이다. 0: 복구 및 오프라인 옵션 사용하지 않음 1: 복구 옵션 사용함 INVALID_RECOVERY 이중화를 이용하여 복구가 가능한지 여부를 나타낸다. 64 ALTIBASE5 Administrator’s Manual 0: 복구 가능 상태 1: 복구 불가능 상태 데이터 딕셔너리 65 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_ 66 ALTIBASE5 Administrator’s Manual SYS_REPL_ITEMS_ 이중화 대상 테이블에 관련된 정보를 가진 메타 테이블이다. Column name Type Description REPLICATION_NAME VARCHAR(40) 이중화 이름 TABLE_OID BIGINT 테이블 객체 식별자 LOCAL_USER_NAME VARCHAR(40) 지역 서버 사용자 이름 LOCAL_TABLE_NAME VARCHAR(40) 지역 서버 테이블 이름 LOCAL_PARTITION_NAME VARCHAR(40) 지역 서버 파티션 이름 REMOTE_USER_NAME VARCHAR(40) 원격 서버 사용자 이름 REMOTE_TABLE_NAME VARCHAR(40) 원격 서버 테이블 이름 REMOTE_PARTITION_NAME VARCHAR(40) 원격 서버 파티션 이름 IS_PARTITION CHAR(1) 파티션 여부 INVALID_MAX_SN BIGINT 건너 뛸 로그의 최대 SN CONDITION VARCHAR(1000) 이중화 조건절 하나의 이중화는 여러 개의 테이블들에 대해 이중화가 가능하며, 이중화된 테이블 각각에 대해 SYS_REPL_ITEMS_에 레코드가 존재한다. 예를 들어 한 이중화가 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 값과 동일하다. LOCAL_PARTITION_NAME 데이터 딕셔너리 67 지역 서버의 이중화 대상 파티션의 이름이다. REMOTE_USER_NAME 원격 서버의 이중화 대상 테이블 소유자의 사용자 이름으로 원격 서버의 SYS_USERS_ 메타 테이블의 USER_NAME 값과 동일하다. REMOTE_TABLE_NAME 원격 서버의 이중화 대상 테이블의 이름으로 원격 서버의 SYS_TABLES_ 메타 테이블의 TABLE_NAME 값과 동일하다. REMOTE_PARTITION_NAME 원격 서버의 이중화 대상 파티션의 이름이다. IS_PARTITIONED 테이블의 파티셔닝 여부를 나타내는 식별자이다. ‘Y’는 파티셔닝이 된 것이고, ‘N’은 파티셔닝이 되어있지 않은 것이다. INVALID_MAX_SN 이중화에 테이블이 추가되는 시점에서 가장 최근에 기록된 SN 이 저장된다. 해당 SN 까지의 테이블 로그를 이중화에서 건너뛰기 위한 용도로 사용된다. CONDITION 이중화 사용시 사용자가 입력한 조건절이다. 참조 테이블 SYS_REPLICATIONS_ SYS_USERS_ SYS_TABLES_ 68 ALTIBASE5 Administrator’s Manual SYS_REPL_OFFLINE_DIR__ 이중화 오프라인 옵션과 관련된 로그 디렉토리 정보를 가지는 메타 테이블이다. Column name Type Description REPLICATION_NAME VARCHAR(40) 이중화 이름 LFG_ID INTEGER 로그 파일 그룹의 식별자 PATH VARCHAR(512) 오프라인 로그 경로 칼럼 정보 REPLICATION_NAME 사용자가 명시한 이중화 이름이다. SYS_REPLICATIONS_ 메타 테이블의 REPLICATION_NAME 값과 동일하다. LFG_ID 로그 파일 그룹(LFG, Log File Group)당 하나의 아카이브 디렉토리가 존재하며 해당하는 LFG 의 식별자를 가리킨다. PATH 로그 파일이 저장되는 시스템 내의 절대 경로를 나타낸다. 데이터 딕셔너리 69 SYS_REPL_OLD_COLUMNS_ 이중화 송신 쓰레드가 현재 사용중인 이중화 대상 칼럼의 정보를 가진 메타 테이블이다. Column name Type Description REPLICATION_NAME VARCHAR(40) 이중화 이름 TABLE_OID BIGINT 테이블 객체 식별자 COLUMN_NAME VARCHAR(40) 칼럼 이름 MT_DATATYPE_ID INTEGER 데이터 타입 식별자 MT_LANGUAGE_ID INTEGER 언어 식별자 MT_FLAG INTEGER 내부 플래그 MT_PRECISION INTEGER 정밀도 MT_SCALE INTEGER 소수 자릿수 MT_ENCRYPT_PRECISION INTEGER 보안 칼럼 정밀도 MT_POLICY_NAME VARCHAR(16) 보안 칼럼 정책 SM_ID INTEGER 칼럼 식별자 SM_FLAG INTEGER 내부 플래그 SM_OFFSET INTEGER 내부 오프셋 SM_SIZE INTEGER 내부 크기 칼럼 정보 REPLICATION_NAME 사용자가 명시한 이중화 이름이다. SYS_REPLICATIONS_ 메타 테이블의 REPLICATION_NAME 값과 동일하다. TABLE_OID 이중화 송신 쓰레드가 현재 사용중인 이중화 대상 테이블의 식별자이다. SYS_TABLES_ 메타 테이블의 TABLE_OID 값과 다를 수 있다. COLUMN_NAME 이중화 송신 쓰레드가 현재 사용중인 이중화 대상 칼럼의 이름이다. MT_DATATYPE_ID 데이터 타입 식별자로 내부 값이다. MT_LANGUAGE_ID 언어 식별자로 내부 값이다. MT_FLAG 70 ALTIBASE5 Administrator’s Manual Altibase 의 내부 플래그이다. MT_PRECISION 정밀도를 나타낸다. MT_SCALE 소수 자릿수를 나타낸다. MT_ENCRYPT_PRECISION 보안 칼럼의 정밀도를 나타낸다. MT_POLICY_NAME 보안 칼럼에 적용된 정책 이름을 나타낸다. SM_ID 칼럼 식별자로 0 부터 시작한다. SM_FLAG Altibase 의 내부 플래그이다. SM_OFFSET Altibase 의 내부 오프셋이다. SM_SIZE Altibase 의 내부 크기이다. 참조 테이블 SYS_REPL_OLD_ITEMS_ SYS_REPL_OLD_INDICES_ SYS_REPL_OLD_INDEX_COLUMNS_ 데이터 딕셔너리 71 SYS_REPL_OLD_INDEX_COLUMNS_ 이중화 송신 쓰레드가 현재 사용 중인 이중화 대상 인덱스 칼럼의 정보를 가진 메타 테이블이다. Column name Type Description REPLICATION_NAME VARCHAR(40) 이중화 이름 TABLE_OID BIGINT 테이블 객체 식별자 INDEX_ID INTEGER 인덱스 식별자 KEY_COLUMN_ID INTEGER 칼럼 식별자 KEY_COLUMN_FLAG INTEGER 내부 플래그 COMPOSITE_ORDER INTEGER 인덱스 구성 칼럼 순서 칼럼 정보 REPLICATION_NAME 사용자가 명시한 이중화 이름으로 SYS_REPLICATIONS_ 메타 테이블의 REPLICATION_NAME 값과 동일하다. TABLE_OID 이중화 송신 쓰레드가 현재 사용 중인 이중화 대상 테이블의 식별자이다. SYS_TABLES_ 메타 테이블의 TABLE_OID 값과 다를 수 있다. INDEX_ID 이중화 송신 쓰레드가 현재 사용 중인 이중화 대상 인덱스의 식별자이다. KEY_COLUMN_ID 인덱스를 구성하는 칼럼의 식별자이다. KEY_COLUMN_FLAG 인덱스를 구성하는 칼럼의 내부 플래그이다. COMPOSITE_ORDER 인덱스를 구성하는 칼럼의 순서이다. 참조 테이블 SYS_REPL_OLD_ITEMS_ 72 ALTIBASE5 Administrator’s Manual SYS_REPL_OLD_COLUMNS_ SYS_REPL_OLD_INDICES_ 데이터 딕셔너리 73 SYS_REPL_OLD_INDICES_ 이중화 송신 쓰레드가 현재 사용 중인 이중화 대상 인덱스의 정보를 가진 메타 테이블이다. Column name Type Description REPLICATION_NAME VARCHAR(40) 이중화 이름 TABLE_OID BIGINT 테이블 객체 식별자 INDEX_ID INTEGER 인덱스 식별자 INDEX_NAME VARCHAR(40) 인덱스 이름 TYPE_ID INTEGER 인덱스 타입 식별자 IS_UNIQUE CHAR(1) 글로벌 유니크 여부 IS_LOCAL_UNIQUE CHAR(1) 로컬 유니크 여부 IS_RANGE CHAR(1) 범위 매칭 여부 칼럼 정보 REPLICATION_NAME 사용자가 명시한 이중화 이름이다. SYS_REPLICATIONS_ 메타 테이블의 REPLICATION_NAME 과 동일하다. TABLE_OID 이중화 송신 쓰레드가 현재 사용중인 이중화 대상 테이블의 식별자이다. SYS_TABLES_ 메타 테이블의 TABLE_OID 값과 다를 수 있다. INDEX_ID 이중화 송신 쓰레드가 현재 사용중인 이중화 대상 인덱스의 식별자이다. INDEX_NAME 이중화 송신 쓰레드가 현재 사용 중인 이중화 대상 인덱스의 이름이다. TYPE_ID 인덱스 형태의 식별자로 내부 값이다. IS_UNIQUE 글로벌 유니크의 여부를 나타낸다. 'Y'는 글로벌 유니크를 나타내고, 'N'은 글로벌 유니크가 아님을 나타낸다. IS_LOCAL_UNIQUE 74 ALTIBASE5 Administrator’s Manual 로컬 유니크 여부를 나타낸다. 'Y'는 로컬 유니크를 나타내고, 'N'은 로컬 유니크가 아님을 나타낸다. IS_RANGE 범위 매칭 여부를 나타낸다. 'Y'는 Range 를 나타내고, 'N'은 Exact Match 를 나타낸다. 참조 테이블 SYS_REPL_OLD_ITEMS_ SYS_REPL_OLD_COLUMNS_ SYS_REPL_OLD_INDEX_COLUMNS_ 데이터 딕셔너리 75 SYS_REPL_OLD_ITEMS_ 이중화 송신 쓰레드가 현재 사용중인 이중화 대상 테이블의 정보를 가진 메타 테이블이다. Column name Type Description REPLICATION_NAME VARCHAR(40) 이중화 이름 TABLE_OID BIGINT 테이블 객체 식별자 USER_NAME VARCHAR(40) 사용자 이름 TABLE_NAME VARCHAR(40) 테이블 이름 PARTITION_NAME VARCHAR(40) 파티션 이름 PRIMARY_KEY_INDEX_ID INTEGER 프라이머리 키의 인덱스 식별자 칼럼 정보 REPLICATION_NAME 사용자가 명시한 이중화 이름으로 SYS_REPLICATIONS_ 메타 테이블의 REPLICATION_NAME 값과 동일하다. TABLE_OID 이중화 송신 쓰레드가 현재 사용중인 이중화 대상 테이블의 식별자이다. SYS_TABLES_ 메타 테이블의 TABLE_OID 값과 다를 수 있다. USER_NAME 지역 서버의 이중화 대상 테이블인 소유자의 이름이다. SYS_USERS_ 메타 테이블의 USER_NAME 값과 동일하다. TABLE_NAME 지역 서버의 이중화 대상 테이블의 이름이다. SYS_TABLES_ 메타 테이블의 TABLE_NAME 값과 동일하다. PARTITION_NAME 지역 서버의 이중화 대상 파티션 이름이다. PRIMARY_KEY_INDEX_ID 프라이머리 키(Primary Key)의 인덱스 식별자이다. 참조 테이블 SYS_REPL_OLD_COLUMNS_ 76 ALTIBASE5 Administrator’s Manual SYS_REPL_OLD_INDICES_ SYS_REPL_OLD_INDEX_COLUMNS_ 데이터 딕셔너리 77 SYS_REPL_RECOVERY_INFOS_ 원격 서버를 복구하기 위해 로그 정보를 기록하는 메타 테이블이다. Column name Type Description REPLICATION_NAME VARCHAR(40) 이중화 이름 MASTER_BEGIN_SN BIGINT 주 트랜잭션의 시작 로그 번호 MASTER_COMMIT_SN BIGINT 주 트랜잭션의 완료 로그 번호 REPLICATED_BEGIN_SN BIGINT 이중화된 트랜잭션의 시작 로그 번호 REPLICATED_COMMIT_SN BIGINT 이중화된 트랜잭션의 완료 로그 번호 칼럼 정보 REPLICATION_NAME 사용자가 명시한 이중화 이름으로 SYS_REPLICATIONS_ 메타 테이블의 REPLICATION_NAME 값과 동일하다. MASTER_BEGIN_SN 원격 서버에서 발생한 주 트랜잭션의 시작 로그 번호이다. MASTER_COMMIT_SN 원격 서버에서 발생한 주 트랜잭션의 완료 로그 번호이다. REPLICATED_BEGIN_SN 지역 서버에서 발생한 이중화된 트랜잭션의 시작 로그 번호이다. REPLICATED_COMMIT_SN 지역 서버에서 발생한 이중화된 트랜잭션의 완료 로그 번호이다. 참조 테이블 SYS_REPLICATIONS_ 78 ALTIBASE5 Administrator’s Manual SYS_SYNONYMS_ 데이터베이스 객체에 대한 별칭 기능을 하는 시노님에 대한 정보를 기록하는 테이블이다. Column name Type Description SYNONYM_OWNER_ID INTEGER 사용자 식별자 SYNONYM_NAME VARCHAR(40) 시노님 이름 OBJECT_OWNER_NAME VARCHAR(40) 객체 소유자 이름 OBJECT_NAME VARCHAR(40) 시노님 대상 객체 이름 CREATED DATE 시노님이 생성된 시간 LAST_DDL_TIME DATE 시노님에 대해 마지막으로 DDL 변경 작업이 일어난 시간 칼럼 정보 SYNONYM_OWNER_ID 시노님 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. SYNONYM_NAME 사용자가 명시한 시노님 이름이다. OBJECT_OWNER_NAME 사용자가 명시한 시노님 대상 객체가 소속된 스키마 소유자의 이름이다. OBJECT_NAME 사용자가 명시한 시노님 대상 객체의 이름이다. CREATED 시노님이 생성된 시간을 나타낸다. LAST_DDL_TIME 시노님에 대해 DDL 변경 작업이 마지막으로 일어난 시간을 나타낸다. 참조 테이블 SYS_USERS_ 데이터 딕셔너리 79 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_RECOVERY _COUNT INTEGER 테이블과 관련된 복구 옵션을 사용하 는 이중화 개수 MAXROW BIGINT 입력할 수 있는 최대 레코드 개수(0: 제한 없음) TBS_ID INTEGER 테이블스페이스 식별자 PCTFREE INTEGER 페이지에서 삽입 가능한 상태 유지하 는 여유 공간의 비율 PCTUSED INTEGER 페이지에서 사용하는 공간의 비율 INITRANS INTEGER 페이지에서 동시에 갱신 가능한 트랜 잭션의 초기 개수 MAXTRANS INTEGER 페이지에서 동시에 갱신 가능한 트랜 잭션의 최대 개수 INITEXTENTS BIGINT 테이블 생성시 초기 익스텐트 개수 NEXTEXTENTS BIGINT 테이블 확장시 확장할 익스텐트 개수 MINEXTENTS BIGINT 테이블의 최소 익스텐트 개수 MAXEXTENTS BIGINT 테이블의 최대 익스텐트 개수 IS_PARTITIONED CHAR(1) 파티셔닝 여부 CREATED DATE 테이블이 생성된 시간 LAST_DDL_TIME DATE 테이블에 대해 마지막으로 DDL 변경 작업이 일어난 시간 칼럼 정보 USER_ID 테이블 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. TABLE_ID 80 ALTIBASE5 Administrator’s Manual 테이블 식별자로 시스템 시퀀스에 의해 자동으로 부여되는 식별자이다. TABLE_OID 시스템 내부에서 자동으로 부여되는 테이블 식별자이다. 사용자가 메타 테이블 조회 시 사용하는 TABLE_ID 와는 달리 시스템 내부 동작 시에만 사용된다. COLUMN_COUNT 테이블에 정의된 칼럼의 개수이다. TABLE_NAME 사용자가 명시한 테이블 이름이다. TABLE_TYPE SYS_TABLES_ 메타 테이블에는 테이블 외에 시퀀스, 뷰 정보 등도 함께 저장된다. 다음은 이들 객체를 구별하기 위한 타입이다. T: 테이블 S: 시퀀스 V: 뷰 W: 큐(Queue) 전용 시퀀스 Q: 큐의 시퀀스 테이블 REPLICATION_COUNT 해당 테이블과 관련된 이중화의 개수이다. REPLICATION_RECOVERY_COUNT 해당 테이블에 대해 복구 옵션을 사용하는 이중화 개수이다. MAXROW 테이블에 삽입가능한 최대 레코드 수이다. TBS_ID 테이블이 저장되는 테이블스페이스의 식별자이다. PCTFREE 한 페이지가 삽입 연산이 가능한 상태를 유지하는 여유 공간의 최소 비율을 의미한다. 기존에 페이지에 저장된 행들을 갱신하기 위해 PCTFREE 에서 명시한 비율만큼의 여유 공간을 페이지에 할당한다. 예를 들어 이 값을 20 으로 명시한 경우, 20%의 공간은 갱신 연산을 위해 공간을 남겨두고, 80%의 공간에 대해서만 삽입 연산이 데이터 딕셔너리 81 가능하다. 0 에서 99 사이의 값으로 CREATE TABLE 문 정의시 사용자가 명시할 수 있다. PCTUSED 페이지가 갱신만 가능한 상태에서 다시 삽입이 가능한 상태로 가기 위한 페이지 사용 공간의 최소 비율을 의미한다. 페이지의 여유 공간이 PCTFREE 에 명시한 비율에 도달하면 더 이상 삽입 연산은 안되며, 갱신만 가능해진다. 이후 갱신과 삭제 등으로 페이지 사용 공간의 비율이 PCTUSED 에서 정한 값보다 낮아지면 새로운 행을 삽입할 수 있다. 0 에서 99 사이의 값으로 CREATE TABLE 문 정의시 사용자가 명시할 수 있다. * PCTFREE 와 PCTUSED 에 대한 자세한 설명은 SQL Users Manual 의 CREATE TABLE 문 설명을 참조한다. INITRANS 페이지를 생성할 때 동시에 갱신 연산을 수행할 수 있는 트랜잭션의 개수이다. 이 개수는 페이지 내의 가용 공간이 허용하는 한 MAXTRANS 까지 확장이 가능하다. MAXTRANS 페이지에서 동시에 갱신 연산을 수행할 수 있는 트랜잭션의 최대 트랜잭션 개수이다. INITEXTENTS 테이블을 생성할 때 할당하는 가용 익스텐트 개수를 나타낸다. NEXTEXTENTS 테이블의 공간을 확장할 때 할당할 수 있는 가용 익스텐트 개수를 나타낸다. MINEXTENTS 테이블의 최소 가용 익스텐트 개수를 나타낸다. MAXEXTENTS 테이블의 최대 가용 익스텐트 개수를 나타낸다. IS_PARTITIONED 테이블의 파티셔닝 여부를 나타내는 식별자이다. ‘Y’는 파티셔닝이 된 것이고, ‘N’은 파티셔닝이 되어있지 않은 것이다. 82 ALTIBASE5 Administrator’s Manual 참조 테이블 SYS_USERS_ SYS_TABLES_ 데이터 딕셔너리 83 SYS_TABLE_PARTITIONS_ 테이블의 파티션을 관리하는 메타 테이블이다. Column name Type Description USER_ID INTEGER 사용자 식별자 TABLE_ID INTEGER 테이블 식별자 PARTITION_OID BIGINT 파티션 객체 식별자 PARTITION_ID INTEGER 파티션 식별자 PARTITION_NAME VARCHAR(40) 파티션 이름 PARTITION_MIN_VALUE VARCHAR(4000)파티션 최소 기준값 문자열 (해시인 경우 NULL) PARTITION_MAX_VALUE VARCHAR(4000)파티션 최대 기준값 문자열 (해시인 경우 NULL) PARTITION_ORDER INTEGER 파티션 순서(hash인 경우 필요) TBS_ID INTEGER 테이블스페이스 식별자 칼럼 정보 USER_ID 테이블 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. TABLE_ID 테이블 식별자로 시스템 시퀀스에 의해 자동으로 부여되는 식별자이다. PARTITION_OID 시스템 내부에서 자동으로 부여되는 파티션 식별자이다. 메타 테이블 조회 시 사용하는 PARTITION_ID 와 달리 시스템 내부 동작 시에만 사용한다. PARTITION_ID 파티션 식별자이다. PARTITION_NAME 사용자가 명시한 파티션 이름이다. PARTITION_MIN_VALUE 파티션의 최소 기준값이 되는 문자열로, 해시(HASH)인 경우에는 널(NULL)이다. 84 ALTIBASE5 Administrator’s Manual PARTITION_MAX_VALUE 파티션의 최대 기준값이 되는 문자열로, 해시(HASH)인 경우에는 널(NULL)이다. PARTITION_ORDER 파티션의 순서를 나타낸 것으로, 파티션이 해시(HASH)인 경우에 필요하다. TBS_ID 테이블이 저장되는 테이블스페이스의 식별자이다. 참조 테이블 SYS_USERS_ SYS_TABLES_ SYS_PART_TABLES_ 데이터 딕셔너리 85 SYS_TBS_USERS_ 사용자가 정의한 사용자의 테이블스페이스에 관한 정보를 기록하는 테이블이다. Column name Type Description TBS_ID INTEGER 테이블스페이스 식별자 USER_ID INTEGER 사용자 식별자 IS_ACCESS INTEGER 테이블스페이스 접근 허용 여부 칼럼 정보 TBS_ID 테이블스페이스 식별자이다. USER_ID 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. IS_ACCESS 사용자가 해당 테이블스페이스에 접근 가능한지를 나타낸다. 0: 접근불가 1: 접근가능 참조 테이블 SYS_USERS_ 86 ALTIBASE5 Administrator’s Manual 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 트리거 구문 전체 문자열 길이 CREATED DATE 트리거가 생성된 시간 LAST_DDL_TIME DATE 트리거에 대해 마지막으로 DDL 변경 작업이 일어난 시간 칼럼 정보 USER_ID 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. USER_NAME 사용자 이름으로 SYS_USERS_ 메타 테이블의 USER_NAME 값과 동일하다. TRIGGER_OID 트리거 식별자로 시스템에 의해 자동으로 부여되는 값이다. TRIGGER_NAME 사용자가 명시한 트리거 이름이다. TABLE_ID 트리거가 참조하는 테이블의 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. 데이터 딕셔너리 87 IS_ENABLE 트리거 수행 여부를 나타내는 값으로 ALTER TRIGGER 문에 의해 변경된다. 0: 미수행 1: 수행 EVENT_TIME BEFORE 또는 AFTER 이벤트를 구분하는 값이다. 1: BEFORE 2: AFTER EVENT_TYPE 트리거 이벤트의 타입을 나타낸다. 1: INSERT 2: DELETE 4: 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 트리거 구문의 전체 문자열 길이이다. 88 ALTIBASE5 Administrator’s Manual 참조 테이블 SYS_USERS_ SYS_TABLES_ 데이터 딕셔너리 89 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_ 메타 테이블의 TABLE_ID 값과 동일하다. TRIGGER_OID 트리거 식별자로 SYS_TRIGGERS_ 메타 테이블의 TRIGGER_OID 값과 동일하다. DML_TABLE_ID 트리거 바디(body)내에서 DML 문으로 접근하는 테이블의 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. STMT_TYPE 테이블에 수행하는 구문의 종류를 나타낸다. 8: DELETE 19: INSERT 33: UPDATE 참조 테이블 SYS_TABLES_ SYS_TRIGGERS_ 90 ALTIBASE5 Administrator’s Manual SYS_TRIGGER_STRINGS_ 트리거 구문을 저장하는 메타 테이블이다. Column name Type Description TABLE_ID INTEGER 테이블 식별자 TRIGGER_OID BIGINT 트리거 식별자 SEQNO INTEGER 나뉘어 저장된 구문 레코드의 순서 SUBSTRING VARCHAR(100) 트리거 구문 칼럼 정보 TABLE_ID 테이블 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. TRIGGER_OID 트리거 식별자로 SYS_TRIGGERS_ 메타 테이블의 TRIGGER_OID 값과 동일하다. SEQNO 한 트리거의 구문 정보를 SYS_TRIGGER_STRINGS_에 여러 개의 레코드로 저장할 때 이들 레코드의 순서이다. SUBSTRING 트리거 구문의 문자열이다. 한 TRIGGER_OID 값으로 레코드들을 검색하여 SEQNO 순서대로 SUBSTRING 값을 합치면 트리거 전체 구문을 생성할 수 있다. 참조 테이블 SYS_TABLES_ SYS_TRIGGERS_ 데이터 딕셔너리 91 SYS_TRIGGER_UPDATE_COLUMNS_ 트리거의 UPDATE 이벤트문의 칼럼 정보를 저장하는 메타 테이블이다. Column name Type Description TABLE_ID INTEGER 테이블 식별자 TRIGGER_OID BIGINT 트리거 식별자 COLUMN_ID INTEGER 칼럼 식별자 칼럼 정보 TABLE_ID 테이블 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. TRIGGER_OID 트리거 식별자로 SYS_TRIGGERS_ 메타 테이블의 TRIGGER_OID 값과 동일하다. COLUMN_ID 칼럼 식별자로 SYS_COLUMNS_ 메타 테이블의 COLUMN_ID 값과 동일하다. 참조 테이블 SYS_TABLES_ SYS_TRIGGERS_ 92 ALTIBASE5 Administrator’s Manual SYS_USERS_ 데이터베이스 사용자에 대한 정보를 기록하는 테이블이다. 여러 사용자에 대한 정보를 포함할 수 있다. Column name Type Description USER_ID INTEGER 사용자 식별자 USER_NAME VARCHAR(40) 사용자 이름 PASSWORD VARCHAR(40) 사용자 패스워드 DEFAULT_TBS_ID INTEGER 디폴트 테이블스페이스 식별자 TEMP_TBS_ID INTEGER 임시 테이블스페이스 식별자 CREATED DATE 데이터베이스 사용자가 생성된 시간 LAST_DDL_TIME DATE 사용자에 대해 마지막으로 DDL 변경 작업이 일어난 시간 칼럼 정보 USER_ID 사용자 식별자로 시스템의 시퀀스에 의해 자동으로 부여되는 값이다. USER_NAME 사용자가 명시한 이름이다. PASSWORD 사용자의 패스워드로 DES with MDS 로 암호화 되어 있다. DEFAULT_TBS_ID 사용자가 ?체 생성 시 테이블스페이스를 명시적으로 기술하지 않을 경우 사용하는 기본 테이블스페이스의 식별자이다. TEMP_TBS_ID 사용자의 임시 테이블스페이스 식별자이다. 데이터 딕셔너리 93 SYS_VIEWS_ 뷰에 대한 기본 정보는 SYS_TABLES_ 메타 테이블에 기록되고 그 외에 뷰의 부가 정보를 기록하는 메타 테이블이다. Column name Type Description USER_ID INTEGER 뷰의 소유자 식별자 VIEW_ID INTEGER 뷰 식별자 STATUS INTEGER 뷰 상태 칼럼 정보 USER_ID 뷰 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. VIEW_ID 뷰 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. STATUS 뷰 상태를 나타내는 값이다. 0: VALID 1: INVALID 참조 테이블 SYS_USERS_ SYS_TABLES_ 94 ALTIBASE5 Administrator’s Manual SYS_VIEW_PARSE_ 사용자가 정의한 뷰의 구문 정보를 기록하는 테이블이다. Column name Type Description USER_ID INTEGER 뷰의 소유자 식별자 VIEW_ID INTEGER 뷰 식별자 SEQ_NO INTEGER 파싱한 뷰 생성문 텍스트를 정보를 SYS_VIEW_PARSE_에 여러 개의 레 코드로 저장할 때 이들 레코드의 순서 PARSE VARCHAR(100) 뷰 생성문 텍스트 칼럼 정보 USER_ID 뷰 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. VIEW_ID 뷰 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. SEQ_NO 한 뷰의 구문 정보를 SYS_VIEW_PARSE_에 여러 개의 레코드로 저장할 때 이들 레코드의 순서이다. PARSE 뷰 구문의 문자열이다. 한 VIEW_ID 값으로 레코드들을 검색하여 SEQ_NO 순서대로 PARSE 값을 합치면 뷰 전체 구문을 생성할 수 있다. 참조 테이블 SYS_USERS_ SYS_TABLES_ 데이터 딕셔너리 95 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 뷰가 접근하는 객체의 타입 칼럼 정보 USER_ID 뷰 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. VIEW_ID 뷰 식별자로 SYS_TABLES_ 메타 테이블의 TABLE_ID 값과 동일하다. RELATED_USER_ID 뷰가 접근하는 객체 소유자의 사용자 식별자로 SYS_USERS_ 메타 테이블의 USER_ID 값과 동일하다. RELATED_OBJECT_NAME 뷰가 접근하는 객체의 이름이다. RELATED_OBJECT_TYPE 뷰가 접근하는 객체의 타입이다. 뷰가 접근하는 객체의 종류는 저장 함수, 테이블, 시퀀스, 뷰 또는 데이터베이스 링크가 가능하다. 1: 저장 함수 2: 테이블, 시퀀스, 뷰 4: 데이터베이스 링크 5: 시노님 참조 테이블 96 ALTIBASE5 Administrator’s Manual SYS_USERS_ SYS_TABLES_ SYS_PROCEDURES_ 데이터 딕셔너리 97 SYS_XA_HEURISTIC_TRANS_ 데이터베이스가 가지고 있는 글로벌(Global) 트랜잭션 식별자들과 그 상태를 가지고 있는 메타 테이블이다. Column name Type Description FORMAT_ID BIGINT 전역(Global) 트랜잭션의 형식(Format) 식별자 GLOBAL_TX_ID VARCHAR(128) 전역 트랜잭션 식별자 BRANCH_QUALIFIER VARCHAR(128) 전역 트랜잭션의 branch qualifier STATUS INTEGER 해당 식별자의 전역 트랜잭션 상태 칼럼 정보 FORMAT_ID 글로벌 트랜잭션의 형식(Format) 식별자 GLOBAL_TX_ID 글로벌 트랜잭션 식별자 BRANCH_QUALIFIER 글로벌 트랜잭션의 브랜치(Branch) qualifier STATUS 해당 식별자의 글로벌 트랜잭션 상태 98 ALTIBASE5 Administrator’s Manual 성능 뷰 성능 뷰(performance view)란 알티베이스 시스템 내부의 정보, 즉 시스템 메모리, 프로세스 상태, 세션, 버퍼 등의 메모리 구조를 일반 테이블 형태로 나타내어 사용자가 모니터링이 가능하도록 해 주는 구조를 말한다. 성능 뷰는 알티베이스를 사용하는 사용자가 테이블에 저장된 데이터를 검색하기 위하여 SQL 을 사용하는 것처럼, 알티베이스 운용 시 사용되는 메모리 객체(예, 세션 정보, 로그 정보)에 관한 정보를 SQL 을 이용하여 검색함으로써 알티베이스를 운용하는데 있어 편의성을 제공한다. 이 절에서는 알티베이스가 지원하는 성능 뷰의 구조 및 기능, 조회 방법, 종류, 그리고 각 뷰에서 나타나는 정보에 대해 설명한다. 구조 및 기능 알티베이스 내부에는 사용자가 생성한 일반 데이터베이스 관련 테이블뿐 아니라 DBMS 운용에 필요한 프로세스 자체의 정보를 다수 보유하고 있다. 특히 알티베이스의 경우 메모리 공간 외에도 디스크 공간에 대한 테이블 생성 및 조회가 가능한 하이브리드 형태이기 때문에 알티베이스 자체에 대한 모니터링 기능이 필수적이라고 할 수 있다. 성능 뷰는 알티베이스 운용과정에서 사용되는 대부분의 내부 메모리 구조체를 뷰 형태로 제공하며, 해당 테이블에 대한 조회를 하는 순간에 그 데이터가 실시간으로 생성되기 때문에 언제나 프로세스 내부의 최신 정보를 얻을 수 있다. 또한, 성능 뷰는 언제나 읽기 전용 속성을 가진다. 만일 이 테이블에 대한 변경 연산을 시도한다면, 알티베이스는 에러를 내고, 해당 트랜잭션에 대한 부분 철회를 수행할 것이다. 성능 뷰의 조회 방법 성능 뷰의 전체 목록은 iSQL 에서 SELECT * FROM V$TAB 명령어를 이용해 다음과 같이 조회한다. iSQL> SELECT * FROM V$TAB; 성능 뷰의 스키마는 일반 테이블과 마찬가지로 Isql 환경에서 DESC 명령어를 통해 확인할 수 있고, 데이터 조회는 일반 테이블과 데이터 딕셔너리 99 동일하게 SELECT 문을 이용하여 검색할 수 있다. 성능 뷰의 종류 성능 뷰의 이름은 V$로 시작하며 종류는 다음과 같다. Fixed Table Name Description V$ALLCOLUMN 성능 뷰를 구성하는 칼럼 정보 V$ARCHIVE 아카이브 관련 정보와 백업 정보 V$BUFFPAGEINFO 버퍼 메니저의 버퍼 프레임 통계 정보 V$BUFFPOOL_STAT 버퍼 풀 hit ratio를 비롯, 버퍼 풀 관련 통계 정보 V$CATALOG 테이블의 구조 정보 V$DATABASE 메모리 데이터베이스 공간의 내부 정보 V$DATAFILES 테이블스페이스에서 사용하는 데이터 파일의 정보 V$DATATYPE 알티베이스에서 지원되는 데이터 타입의 정보 V$DBA_2PC_PENDING 분산 트랜잭션에서 in-doubt 상태의 트랜잭션 브랜치 목록 V$DBLINK_REMOTE_STATEMENT _INFO 데이터베이스 링크 사용시 원격 서버에서 발생 한 문장(Statement) 정보 V$DBLINK_REMOTE_TRANSACTI ON_INFO 데이터베이스 링크 사용시 원격 서버에서 발생 한 트랜잭션 정보 V$DBLINK_TRANSACTION_INFO 데이터베이스 링크를 사용하는 트랜잭션 정보 V$DB_FREEPAGELISTS 사용가능한 페이지 리스트 정보 V$DB_PROTOCOL 서버로 유입되는 데이터베이스 프로토콜의 정 보 V$DISKTBL_INFO 디스크 테이블 정보 V$DISK_BTREE_HEADER 디스크 BTREE 인덱스들의 헤더 정보 V$EVENT_NAME 알티베이스 서버의 대기 이벤트 정보 V$FILESTAT 디스크의 데이터 파일별 I/O 통계 정보 V$FLUSHINFO 버퍼 플러쉬 정보 V$INDEX 테이블의 인덱스 정보 V$INSTANCE 현재 알티베이스의 다단계 startup 정보 V$LATCH 버퍼 풀의 버퍼 제어 블록(BCB) latch 정보와 read or write가 try된 페이지에 대하여 read/ write latch에 대한 통계 정보 V$LFG 그룹커밋 관련 통계값 V$LINKER_STATUS 데이타베이스 링크를 위한 AltiLinker의 상태 정보 V$LOCK 현재 시점에서 데이터베이스의 모든 테이블 100 ALTIBASE5 Administrator’s Manual Fixed Table Name Description lock 노드 정보 V$LOCK_STATEMENT Lock과 statement정보 V$LOCK_WAIT 트랜잭션의 락 대기 상태 정보 V$LOG 로그 앵커 정보 V$MEMGC 메모리 공간 회수 (memory garbage collect) 정보 V$MEMSTAT 알티베이스 프로세스가 사용하는 메모리 통계 정보 V$MEMTBL_INFO 메모리 테이블 정보 V$MEM_BTREE_HEADER 메모리 BTREE 인덱스의 헤더 정보 V$MEM_BTREE_NODEPOOL 메모리 BTREE 인덱스를 위한 노드풀 정보 V$MEM_RTREE_HEADER 메모리 RTREE 인덱스의 헤더 정보 V$MEM_RTREE_NODEPOOL 메모리 RTREE 인덱스를 위한 노드풀 정보 V$MEM_TABLESPACES 메모리에 생성된 테이블스페이스 정보 V$MEM_TABLESPACE_CHECKPOI NT_PATHS 체크포인트 발생시 반영되는 DB 파일 위치 정 보 V$MEM_TABLESPACE_STATUS_D ESC 메모리 테이블스페이스의 상태 값 내용 정보 V$MUTEX 알티베이스 프로세스에서 사용되고 있는 동시 성 제어 관련 뮤텍스(mutex) 통계 정보 V$NLS_PARAMETERS NLS 관련 파라미터 정보 V$PLANTEXT SQL의 실행 계획 텍스트 정보 V$PROCTEXT 저장 프로시저의 텍스트 정보 V$PROPERTY 알티베이스 내부에 설정된 프로퍼티 정보 V$REPEXEC 리플리케이션 관리자 정보 V$REPGAP 리플리케이션 송신자의 작업 로그 파일이 현재 생성된 최근 로그 파일간의 차이 정보 V$REPLOGBUFFER 리플리케이션 전용 로그 버퍼의 정보 V$REPOFFLINE_STATUS 오프라인 이중화의 수행 상태 정보 V$REPRECEIVER 리플리케이션 수신자 정보 V$REPRECEIVER_COLUMN 리플리케이션 수신자의 리플리케이션 대상 칼 럼 정보 V$REPRECEIVER_TRANSTBL 리플리케이션 송신자의 트랜잭션 테이블 정보 V$REPRECOVERY 리플리케이션 이용한 복구 정보 V$REPSENDER 리플리케이션 송신자 정보 V$REPSENDER_TRANSTBL 리플리케이션 수신자의 트랜잭션 테이블 정보 V$REPSYNC SYNC 중인 테이블의 정보 V$SEGMENT 테이블과 색인을 구성하는 세그먼트 정보 V$SEQ 시퀀스 관련 정보 V$SERVICE_THREAD Multiplexing 관련 서비스 쓰레드 정보 데이터 딕셔너리 101 Fixed Table Name Description V$SESSION 알티베이스 내부에 생성된 클라이언트에 대한 세션 정보 V$SESSIONMGR 알티베이스의 세션 통계 정보 V$SESSION_EVENT 구동 후부터 현재까지 접속한 세션별 모든 대 기 이벤트의 통계 정보 V$SESSION_WAIT 현재 접속한 상태에 있는 모든 세션의 대기 이 벤트 정보 V$SESSTAT 현재 접속된 세션의 상태 정보 V$SQLTEXT 시스템에서 수행되는 SQL의 텍스트 정보 V$SQL_PLAN_CACHE SQL Plan Cache의 현재 상태 및 통계 정보 V$SQL_PLAN_CACHE_PCO SQL Plan Cache에 등록된 Plan Cache 객체 에 대한 정보 V$SQL_PLAN_CACHE_SQLTEXT SQL Plan Cache에 등록된 SQL 문장 정보 V$STABLE_MEM_DATAFILES 데이터 파일의 전체 경로 정보 V$STATEMENT 현재 알티베이스에 생성된 모든 세션의 구문 정보 V$STATNAME 시스템 및 세션 상태와 이름 정보 V$ST_ANGULAR_UNIT 향후 확장 예정 V$ST_AREA_UNIT 향후 확장 예정 V$ST_LINEAR_UNIT 향후 확장 예정 V$SYSSTAT 시스템 상태 정보 V$SYSTEM_CONFLICT_PAGE 페이지 타입 별 래치 경합 정보 V$SYSTEM_EVENT 구동부터 현재까지의 대기 이벤트별 대기 통계 정보 V$SYSTEM_WAIT_CLASS 구동부터 현재까지의 대기 클래스별 대기 통계 정보 V$TABLE 모든 성능 뷰의 레코드 및 칼럼 정보 V$TABLESPACES 테이블스페이스 정보 V$TRACELOG 트레이스 로깅 정보 V$TRANSACTION 트랜잭션 객체 정보 V$TRANSACTION_MGR 알티베이스 트랜잭션 관리자 정보 V$TSSEGS 모든 TSS 세그먼트들의 정보 V$TXSEGS 바인딩된 트랜잭션 세그먼트들의 정보 V$UDSEGS 모든 언두 세그먼트들의 정보 V$UNDO_BUFF_STAT Undo 테이블스페이스의 버퍼 풀 관련 통계 정 보 V$VERSION 알티베이스 버전 정보 V$WAIT_CLASS_NAME 알티베이스 서버상의 대기 이벤트들을 그룹화 하기 위한 정보 V$XID DBMS에 현재 존재하는 분산 트랜잭션 브랜치 102 ALTIBASE5 Administrator’s Manual Fixed Table Name Description 인 XID의 목록 데이터 딕셔너리 103 V$ALLCOLUMN 성능 뷰에 속한 칼럼의 정보를 나타낸다. Column name Type Description TABLENAME VARCHAR(39) 성능 뷰 테이블의 이름 COLNAME VARCHAR(39) 성능 뷰 칼럼의 이름 칼럼 정보 TABLENAME 해당 성능 뷰 칼럼이 속한 테이블의 이름을 나타낸다. COLNAME 현재 뷰 칼럼의 이름을 나타낸다. 104 ALTIBASE5 Administrator’s Manual V$ARCHIVE 아카이브 관련 정보와 백업 정보를 보여준다. Column name Type Description LFG_ID INTEGER 로그 파일의 그룹 식별자 ARCHIVE_MODE BIGINT 아카이브 로그 모드 ARCHIVE_THR_RUNNING BIGINT 아카이브 쓰레드 수행 여부 ARCHIVE_DEST VARCHAR(1024)로그를 아카이브 하여 저장하는 디 렉토리 NEXTLOGFILE_TO_ARCH INTEGER 다음 번에 아카이브 할 로그 번호 OLDEST_ACTIVE_LOGFILE INTEGER 온라인로그 중 가장 오래된 로그 파일 번호 CURRENT_LOGFILE INTEGER 현재 온라인로그 파일 번호 칼럼 정보 LFG_ID 로그 파일 그룹(LFG, Log File Group)당 하나의 아카이브 디렉토리가 존재하며 해당 LFG 의 식별자를 가리킨다. ARCHIVE_MODE 데이터베이스의 아카이브 로그 모드를 나타낸다. 0: 노(No) 아카이브 로그 모드 1: 아카이브 로그 모드 데이터 딕셔너리 105 V$BUFFPAGEINFO 버퍼 관리자에서 관리되는 버퍼 프레임의 페이지 타입별 주요 연산들에 대한 통계치를 보여준다. Column name Type Description PAGE_TYPE VARCHAR(20) 페이지 타입 READ_PAGE_COUNT BIGINT DISK I/O (READ)를 유발한 횟수 GET_PAGE_COUNT BIGINT 버퍼 프레임을 요구한 횟수 FIX_PAGE_COUNT BIGINT 버퍼 프레임에 고정(fix)한 횟수 CREATE_PAGE_COUNT BIGINT 새로운 버퍼 프레임을 요구한 횟수 HIT_RATIO DOUBLE 버퍼 프레임 히트(hit)율 칼럼 정보 PAGE_TYPE 페이지 타입을 나타내며, 다음과 같은 페이지 타입을 갖는다. PAGE UNFORMAT PAGE FORMAT PAGE INDEX META PAGE INDEX PAGE TABLE PAGE TEMP TABLE META PAGE TEMP TABLE DATA PAGE TSS PAGE UNDO PAGE LOB DATA PAGE LOB INODE PAGE FMS SEGHDR PAGE FMS EXTDIR PAGE TMS SEGHDR PAGE TMS LFBMP PAGE TMS ITBMP 106 ALTIBASE5 Administrator’s Manual PAGE TMS RTBMP PAGE TMS EXTDIR PAGE CMS SEGHDR PAGE CMS EXTDIR PAGE FEBT FSB PAGE FEBT EGH PAGE LOB META PAGE HV TEMP NODE PAGE HV TEMP DATA READ_PAGE_COUNT 서버 구동 이후부터 현재까지 PAGE_TYPE 에 해당하는 버퍼 프레임들에 DISK I/O (READ)를 유발시킨 총 횟수를 나타낸다. 0 이상의 값을 갖는다. GET_PAGE_COUNT 서버 구동 이후부터 현재까지 버퍼 관리자에게 데이터 쓰기나 읽기 목적으로 PAGE_TYPE 에 해당하는 버퍼 프레임들을 요구한 총 횟수를 나타낸다. 0 이상의 값을 갖는다. FIX_PAGE_COUNT 서버 구동 이후부터 현재까지 버퍼 관리자에게 데이터 쓰기나 읽기를 목적으로 PAGE_TYPE 에 해당하는 버퍼 프레임들을 고정(Fix)한 총 횟수를 나타낸다. 0 이상의 값을 갖는다. CREATE_PAGE_COUNT 서버 구동 이후부터 현재까지 버퍼 관리자에게 PAGE_TYPE 에 해당하는 새로운 버퍼 프레임들을 요구한 총 횟수를 나타낸다. 0 이상의 값을 갖는다. HIT_RATIO 서버 구동 이후부터 현재까지 이 버퍼에 대한 히트(hit)율을 나타낸다. 이 값은 (GET_PAGE_COUNT + FIX_PAGE_COUNT - READ_PAGE_COUNT) / (GET_PAGE_COUNT + FIX_PAGE_COUNT)로 구해진다. 예제 데이터 딕셔너리 107 서버 구동 이후 버퍼에서 관리해 온 페이지 타입별 주요 연산들의 누적치를 확인한다. iSQL> select * from v$buffpageinfo; PAGE_TYPE READ_PAGE_COUNT GET_PAGE_COUNT ------------------------------------------- FIX_PAGE_COUNT CREATE_PAGE_COUNT HIT_RATIO ---- --- -- ---- --- -- ---- --- -- ---- --- -- ---- --- PAGE UNFORMAT 0 0 0 0 0 PAGE FORMAT 0 0 0 0 0 PAGE INDEX META 0 0 0 0 0 PAGE INDEX 0 0 0 0 0 PAGE TABLE 0 0 0 0 0 PAGE TEMP TABLE META 0 0 0 0 0 P A G E T E M P T A B L E D A T A 0 0 0 0 0 P A G E T S 0 0 0 0 0 PAGE UNDO 0 0 0 0 0 PAGE LOB DATA 0 0 0 0 0 PAGE LOB INODE 0 0 0 0 0 PAGE FMS SEGHDR 0 0 0 0 0 PAGE FMS EXTDIR 0 0 0 0 0 PAGE TMS SEGHDR 0 0 0 0 0 PAGE TMS LFBMP 0 0 0 0 0 PAGE TMS ITBMP 0 0 0 0 0 PAGE TMS RTBMP 0 0 0 0 0 PAGE TMS EXTDIR 0 0 0 0 0 PAGE CMS SEGHDR 0 1536 0 512 14.2857142857143 PAGE CMS EXTDIR 0 0 0 0 0 PAGE FEBT FSB 2 1024 515 2 14.2671493548687 PAGE FEBT EGH 0 512 0 4 14.2857142857143 108 ALTIBASE5 Administrator’s Manual PAGE LOB META 0 0 0 0 0 PAGE HV TEMP NODE 0 0 0 0 0 24 rows selected. 데이터 딕셔너리 109 V$BUFFPOOL_STAT 버퍼 풀 hit ratio 를 포함하여, 버퍼 풀 관련 통계 정보를 보여준다. Column name Type Description ID INTEGER 버퍼 풀 아이디 POOL_SIZE INTEGER 현재 버퍼 풀의 크기 PAGE_SIZE INTEGER 버퍼 풀에서 사용하는 페이지 크기 HASH_BUCKET_COUNT INTEGER 해시 테이블의 버킷 개수 HASH_CHAIN_LATCH_COU NT INTEGER 해시 테이블에 사용되는 체인 래치 개 수 LRU_LIST_COUNT INTEGER LRU 리스트 개수 PREPARE_LIST_COUNT INTEGER 버퍼 풀의 Prepare 리스트 개수 FLUSH_LIST_COUNT INTEGER 버퍼 풀의 플러시 리스트 개수 CHECKPOINT_LIST_COUNT INTEGER 버퍼 풀의 체크포인트 리스트 개수 VICTIM_SEARCH_COUNT INTEGER LRU 리스트에서 victim 검색 개수 HASH_PAGES INTEGER 현재 해시 테이블에 삽입된 페이지 개 수 HOT_LIST_PAGES INTEGER 현재 LRU hot 리스트에 있는 페이지 개수 COLD_LIST_PAGES INTEGER 현재 LRU cold 리스트에 있는 페이지 개수 PREPARE_LIST_PAGES INTEGER 현재 Prepare 리스트에 있는 페이지 개수 FLUSH_LIST_PAGES INTEGER 현재 플러시 리스트에 있는 페이지 개 수 CHECKPOINT_LIST_PAGES INTEGER 현재 체크포인트 리스트에 있는 페이 지 개수 FIX_PAGES BIGINT 래치 없이 페이지를 요청하는 누적 횟 수 GET_PAGES BIGINT 래치를 획득하면서 페이지를 요청하는 누적 횟수 READ_PAGES BIGINT 페이지 요청시 디스크에서 페이지를 읽는 누적 횟수 CREATE_PAGES BIGINT 새로운 페이지를 생성하는 누적 횟수 HIT_RATIO DOUBLE 버퍼 풀에서 시스템 구동 후부터 누적 hit율 HOT_HITS BIGINT LRU hot 리스트에서 접근된 누적 횟 수 COLD_HITS BIGINT LRU cold 리스트에서 접근된 누적 횟 수 PREPARE_HITS BIGINT Prepare 리스트에서 접근된 누적 횟 110 ALTIBASE5 Administrator’s Manual Column name Type Description 수 FLUSH_HITS BIGINT 플러시 리스트에서 접근된 누적 횟수 OTHER_HITS BIGINT 어떤 리스트에도 속하지 않은 버퍼에 접근된 누적 횟수 PREPARE_VICTIMS BIGINT Prepare 리스트에서 교체 대상을 찾 는 누적 횟수 LRU_VICTIMS BIGINT LRU 리스트에서 교체 대상을 찾는 누 적 횟수 VICTIM_FAILS BIGINT 교체 대상 검색에 실패한 횟수 PREPARE_AGAIN_VICTIMS BIGINT LRU 리스트에서 교체 대상 찾기를 실 패한 후, 다시 prepare 리스트에서 교 체 대상 버퍼를 찾는 누적 횟수 VICTIM_SEARCH_WARP BIGINT Prepare 리스트, LRU 리스트에서 교 체 대상 찾기를 실패한 후 다음 Prepare 리스트로 검색 대상을 옮긴 횟수 LRU_SEARCHS BIGINT LRU 리스트에서 검색한 버퍼 누적 횟 수 LRU_SEARCHS_AVG INTEGER 교체 대상을 검색한 평균 버퍼 수 LRU_TO_HOTS BIGINT LRU 리스트에서 hot 영역으로 옮긴 누적 횟수 LRU_TO_COLDS BIGINT LRU 리스트에서 cold 영역으로 옮긴 누적 횟수 LRU_TO_FLUSHS BIGINT LRU 리스트에서 flush 리스트로 옮긴 누적 횟수 HOT_INSERTIONS BIGINT LRU hot 리스트에 삽입된 누적 횟수 COLD_INSERTIONS BIGINT LRU cold 리스트에 삽입된 누적 횟수 칼럼 정보 ID 버퍼 풀 고유 번호를 나타낸다. 현재 다중 버퍼 풀을 지원하지 않기때문에 0 이다. POOL_SIZE 현재 버퍼 풀의 크기를 나타내며, 단위는 바이트이다. 이 값은 프로퍼티 BUFFER_AREA_SIZE 에 명시된 값보다 이하일 수 있다. PAGE_SIZE 현재 버퍼 풀에서 사용되는 페이지의 크기를 나타낸다. 현재는 다중 데이터 딕셔너리 111 버퍼 풀을 지원하지 않기 때문에 고정 값 8192 만 가능하다. HASH_BUCKET_COUNT 해시 테이블의 버킷 개수를 나타낸다. 프로퍼티 BUFFER_HASH_BUCKET_DENSITY 에 의해 결정된다. 서버 구동 중에는 변경되지 않으며, 이 값이 클수록 해시 버킷 리스트의 탐색 비용이 감소된다. HASH_CHAIN_LATCH_COUNT 해시 테이블에 사용되는 체인 래치의 개수를 나타낸다. 이 값이 클수록 해시 탐색시 발생할 수 있는 래치 경합이 줄어든다. LRU_LIST_COUNT 버퍼 풀의 LRU 리스트 개수를 나타낸다. PREPARE_LIST_COUNT 버퍼 풀의 prepare 리스트 개수를 나타낸다. FLUSH_LIST_COUNT 버퍼에 올라와 있는 페이지 중 수정되어 디스크에 반영해야 할 페이지의 개수를 나타낸다. CHECKPOINT_LIST_COUNT 버퍼 풀의 체크포인트 리스트 개수를 나타낸다. VICTIM_SEARCH_COUNT LRU 리스트에서 교체 대상을 검색할 때 몇 개까지 검색할지를 나타낸다. 명시된 값만큼 검색해도 교체 대상을 찾지 못하면 플러셔가 prepare 리스트에 clean 버퍼가 삽입될 때까지 대기한다. HASH_PAGES 해시 테이블에 삽입된 버퍼 수를 나타낸다. 이 값은 사용중인 버퍼의 수를 의미한다. HOT_LIST_PAGES LRU hot 리스트에 존재하는 버퍼 수를 나타낸다. COLD_LIST_PAGES LRU cold 리스트에 존재하는 버퍼 수를 나타낸다. PREPARE_LIST_PAGES prepare 리스트에 존재하는 버퍼 수를 나타낸다. 이 값이 0 이면 교체 대상을 얻기 위해 LRU 리스트를 조회한다. 112 ALTIBASE5 Administrator’s Manual FLUSH_LIST_PAGES 플러시 리스트에 존재하는 버퍼 수를 나타낸다. 값이 크면 플러시할 버퍼가 많다는 의미이다. CHECKPOINT_LIST_PAGES 체크포인트 리스트에 존재하는 버퍼 수를 나타낸다. 이 값은 갱신된 페이지의 수를 의미한다. FIX_PAGES 래치 획득없이 페이지를 요청하는 횟수이다. 시스템 구동 후부터 누적된 fix page 횟수를 나타낸다. GET_PAGES 페이지 래치 획득과 함께 요청된 횟수를 나타낸다. READ_PAGES 페이지 요청 시 디스크에서 페이지를 읽은 누적 횟수이다. 버퍼 miss 횟수와 동일한 의미이다. CREATE_PAGES 빈 페이지에 데이터를 삽입하기 위해 페이지 할당 작업을 하는 누적 횟수를 나타낸다. create page 시에는 물리적으로 read 작업을 수반하지 않는다. HIT_RATIO 버퍼 풀의 누적 hit 율을 나타낸다. (GET_PAGES + FIX_PAGES - READ_PAGES)/(GET_PAGES + FIX_PAGES) 값이다. 이 값이 작으면 물리적으로 읽기(read page) 횟수가 많다는 것이다. 읽기 횟수가 많으면, 시스템이 빠른 질의 처리를 못한다. HOT_HITS LRU hot 리스트에서 hit 가 발생한 누적 횟수를 나타낸다. hit 는 페이지 요청시 해당 페이지가 이미 버퍼에 있어 read page 를 유발시키지 않는다. COLD_HITS LRU cold 리스트에서 hit 가 발생한 누적 횟수를 나타낸다. PREPARE_HITS prepare 리스트에서 hit 가 발생한 누적 횟수를 나타낸다. FLUSH_HITS 플러시 리스트에서 hit 가 발생한 누적 횟수를 나타낸다. 데이터 딕셔너리 113 OTHER_HITS 버퍼가 순간적으로 어떤 리스트에도 속하지 않은 경우의 hit 발생한 횟수를 나타낸다. hit 가 발생한 버퍼는 항상 어떤 리스트에 존재해야 하는 것은 아니다. PREPARE_VICTIMS prepare 리스트에서 교체 대상 버퍼를 찾은 누적 횟수를 나타낸다. LRU_VICTIMS LRU 리스트에서 교체 대상 버퍼를 찾은 누적 횟수를 나타낸다. VICTIM_FAILS 교체 대상 버퍼 찾기에 실패한 누적 횟수를 나타낸다. 이 값은 PREPARE_AGAIN_VICTIMS + VICTIM_SEARCH_WARP 와 같다. PREPARE_VICTIMS + LRU_VICTIMS + VICTIM_FAILS 는 버퍼 풀에서 발생한 총 교체 횟수이다. PREPARE_AGAIN_VICTIMS 교체 대상 버퍼 찾기에 실패한 후 prepare 리스트에 버퍼가 삽입되기를 대기한다. 이 때 대기 중에 clean 버퍼를 받아 교체 대상으로 선정하게 된 횟수를 나타낸다. VICTIM_SEARCH_WARP prepare 리스트에 일정 시간 대기한 후에도 교체 대상 버퍼를 선정하지 못한 경우 다음 prepare 리스트로 넘어가 교체 대상 버퍼를 찾는 누적 횟수를 나타낸다. LRU_SEARCHS LRU 리스트에서 교체 대상 버퍼를 검색한 누적 버퍼 개수를 나타낸다. LRU_SEARCHS_AVG 교체 대상 검색시 탐색 버퍼의 평균 개수를 나타낸다. LRU_TO_HOTS LRU 리스트에서 hot 으로 옮겨진 버퍼의 누적 개수를 나타낸다. LRU_TO_COLDS LRU 리스트에서 cold 로 옮겨진 버퍼의 누적 개수를 나타낸다. LRU_TO_FLUSHS LRU 리스트에서 flush 리스트로 옮겨진 버퍼의 누적 개수를 나타낸다. 114 ALTIBASE5 Administrator’s Manual HOT_INSERTIONS LRU hot 리스트에 삽입된 누적 버퍼 개수를 나타낸다. COLD_INSERTIONS LRU cold 리스트에 삽입된 누적 버퍼 개수를 나타낸다. 데이터 딕셔너리 115 V$CATALOG 데이타베이스에 존재하는 테이블의 구조 정보를 보여준다. Column name Type Description TABLE_OID BIGINT 테이블의 OID(Object ID) COLUMN_CNT INTEGER 테이블의 칼럼 개수 COLUMN_VAR_SLOT_CNT INTEGER 칼럼 정보를 저장하기 위해 사 용된 Variable Slot의 개수 INDEX_CNT INTEGER 테이블의 인덱스 개수 INDEX_VAR_SLOT_CNT INTEGER 인덱스 정보를 저장하기 위해 사용된 Variable Slot의 개수 칼럼 정보 TABLE_OID 테이블의 정보를 가지는 헤더(Header)의 물리적인 위치를 나타낸다. 116 ALTIBASE5 Administrator’s Manual V$DATABASE 메모리 데이터베이스 공간의 내부 정보를 보여준다. Column name Type Description DB_NAME VARCHAR(128) 메모리 데이터베이스 명 PRODUCT_SIGNATURE VARCHAR(512) 제품 고유 스트링 DB_SIGNATURE VARCHAR(512) 데이터베이스 파일 고유 스트링 VERSION_ID INTEGER 데이터베이스 고유 버전 COMPILE_BIT INTEGER 컴파일 비트(32/64) ENDIAN BIGINT 엔디안 정보 LOGFILE_SIZE BIGINT 로그화일 크기 TX_TBL_SIZE INTEGER 트랜잭션 테이블 크기 LAST_SYSTEM_SCN VARCHAR(29) 내부 용도 INIT_SYSTEM_SCN VARCHAR(29) 내부 용도 DURABLE_SYSTEM_SCN VARCHAR(29) 저장된 시스템 SCN 값 MEM_MAX_DB_SIZE VARCHAR(256)메모리 데이터베이스의 최대 크 기 . MEM_ALLOC_PAGE_COUNT BIGINT 할당된 페이지 총 개수 MEM_FREE_PAGE_COUNT BIGINT 사용 가능한 페이지 총 개수 MAX_ACCESS_FILE_SIZ VARCHAR(12) 데이터베이스에 생성가능한 최대 파일 크기 칼럼 정보 DB_NAME 메모리 데이터베이스의 이름을 나타낸다. PRODUCT_SIGNATURE 알티베이스 제품이 가지는 고유한 제품 정보를 나타낸다. DB_SIGNATURE 알티베이스 메모리 데이터베이스 공간의 유일하게 결정하는 임의의 스트링이다. VERSION_ID 알티베이스 저장관리자가 유지하는 고유 버전번호를 나타낸다. COMPILE_BIT 현재 생성된 데이터베이스가 32 비트인지 혹은 64 비트인지 표현한다. ENDIAN 데이터 딕셔너리 117 현재 생성된 데이터베이스의 엔디안을 나타낸다. 0 은 little endian, 1 은 big endian 을 표현한다. LOGFILE_SIZE 현재 생성된 데이터베이스에서 사용하는 로그 파일의 크기를 나타낸다. TX_TBL_SIZE 현재 할당된 트랜잭션 테이블의 크기를 나타낸다. MEM_MAX_DB_SIZE 메모리 데이터베이스 공간의 확장가능한 최대 크기를 나타낸다. MEM_ALLOC_PAGE_COUNT 현재 메모리 데이터베이스 공간의 할당된 총 페이지 개수를 나타낸다. 이는 확장가능한 최대 크기까지 고려하지 않으며, 현재 메모리 데이타베이스 공간 크기에 대해서만 고려한다. 그러므로, 현재 메모리 데이타베이스 공간의 크기는 MEM_ALLOC_PAGE_COUNT 와 MEM_FREE_PAGE_COUNT 의 합에 페이지 크기(32KB)를 곱하여 표현할 수 있다. MEM_FREE_PAGE_COUNT 현재 메모리 데이타베이스 공간에서 할당된 총 페이지 개수를 뺀 할당가능한 페이지 개수를 나타낸다. 이는 확장가능한 최대 크기까지 고려하지 않으며, 현재 메모리 데이타베이스 공간 크기에 대해서만 고려한다. 그러므로, 현재 메모리 데이타베이스 공간의 크기는 MEM_ALLOC_PAGE_COUNT 와 MEM_FREE_PAGE_COUNT 의 합에 페이지 크기(32KB)를 곱하여 표현할 수 있다. DURABLE_SYSTEM_SCN 데이터베이스 공간에 저장된 시스템 SCN 의 값을 나타낸다. 118 ALTIBASE5 Administrator’s Manual V$DATAFILES 테이블스페이스에서 사용하는 데이터 파일의 정보를 보여준다. Column name Type Description ID INTEGER 아이디 NAME VARCHAR(256) 이름 SPACEID INTEGER 테이블스페이스 아이디 OLDEST_LSN_LFGID INTEGER 아래 참조 OLDEST_LSN_FILENO INTEGER 아래 참조 OLDEST_LSN_OFFSET INTEGER 아래 참조 CREATE_LSN_LFGID 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 상태 MAX_OPEN_FD_COUNT INTEGER 열 수 있는 최대 FD 개수 CUR_OPEN_FD_COUNT INTEGER 열린 FD 개수 칼럼 정보 ID 데이터 파일의 아이디를 나타낸다. 아이디는 생성된 순서대로 순차적으로 부여되며 같은 아이디가 중복되는 일은 없다. NAME 데이터 파일의 물리적 경로, 파일의 이름을 나타낸다. SPACEID 데이터 파일이 속한 테이블스페이스의 아이디를 나타낸다. OLDEST_LSN_LFGID 데이터 파일에 페이지를 플러시한 마지막 체크포인트 시점의 버퍼에 데이터 딕셔너리 119 올라와 수정되었던 페이지 중 가장 오래된 페이지 LSN 의 로그 파일 그룹(LFG) 식별자를 나타낸다. OLDEST_LSN_FILENO 데이터 파일에 페이지를 플러시한 마지막 체크포인트 시점의 버퍼에 올라와 수정되었던 페이지 중 가장 오래된 페이지의 LSN 의 값 중 파일 번호를 나타낸다. OLDEST_LSN_OFFSET 데이터 파일에 페이지를 플러시한 마지막 체크포인트 시점의 버퍼에 올라와 수정되었던 페이지 중 가장 오래된 페이지의 LSN 의 값 중 offset 을 나타낸다. CREATE_LSN_LFGID 데이터 파일이 생성된 시점에 해당하는 LSN 의 로그 파일 그룹(LFG) 식별자를 나타낸다. CREATE_LSN_FILENO 데이터 파일이 생성된 시점의 LSN 값 중 파일 번호를 나타낸다. CREATE_LSN_OFFSET 데이터 파일이 생성된 시점의 LSN 값 중 offset 을 나타낸다. SM_VERSION 데이터 파일을 생성한 바이너리의 버전을 나타낸다. 모든 데이터 파일은 호환 가능한 바이너리의 버전을 가지게 된다. NEXTSIZE 데이터 파일의 autoextend 속성이 on 인 경우, 공간 부족 시 데이터 파일이 확장될 크기를 나타낸다. MAXSIZE 데이터 파일의 autoextend 속성이 on 인 경우, 공간 부족 시 데이터 파일이 확장될 수 있는 최대 크기를 나타낸다. INITSIZE 데이터 파일이 최초에 생성된 크기를 나타낸다. CURRSIZE 데이터 파일의 현재 크기를 나타낸다. AUTOEXTEND 데이터 파일의 공간이 부족할 때 자동 확장될 지 여부를 나타낸다. 120 ALTIBASE5 Administrator’s Manual 0: 자동 확장 안함. 1: 자동 확장 IOCOUNT 데이터 파일에 현재 진행 중인 IO 의 개수를 나타낸다. 데이터 파일이 IO 가 진행 중이 아니라면, 다음 데이터 파일의 오픈을 위해 양보해 줄 수 있다. OPENED 데이터 파일이 현재 오픈되었는지 나타낸다. 0: 닫혀 있음 1: 열려 있음 MODIFIED 데이터 파일이 수정되었는지 나타낸다. 데이터 파일에 페이지가 플러시한 적이 있으면 이 값이 1 이 된다. 데이터 파일에 싱크를 수행하면 이 값이 0 이된다. STATE 데이터 파일의 상태를 나타낸다. 1: 오프라인(offline) 2: 온라인(online) 4: 백업 시작 8: 백업 끝 128: 삭제(dropped) MAX_OPEN_FD_COUNT 현재 디스크 데이터 파일에서 I/O 가 발생할 때 열 수 있는 최대 FD(File Descriptor) 개수 CUR_OPEN_FD_COUNT 현재 디스크 데이터 파일에서 열린 FD(File Descriptor) 개수 데이터 딕셔너리 121 V$DATATYPE 알티베이스에서 지원하는 데이터 타입의 정보를 보여준다. 1 Column name Type Description TYPE_NAME VARCHAR(40) DBMS에서 지원하는 데이터 타입 이름 DATA_TYPE SMALLINT DBMS에서 지원하는 데이터 타입의 내 부 정의 값 ODBC_DATA_TYPE SMALLINT 데이터 타입에 대응하는 ODBC SQL 데 이타 타입 식별자 COLUMN_SIZE INTEGER 해당 타입에 대한 최대 칼럼 크기. LITERAL_PREFIX VARCHAR(4) 해당 데이터 타입의 리터럴에 대한 접두 부로 인식하는 문자 LITERAL_SUFFIX VARCHAR(4) 해당 데이터 타입의 리터럴에 대한 접미 부로 인식하는 문자. CREATE_PARAM VARCHAR(20)SQL에서 데이터 타입 정의시 괄호로 표 현되는 매개변수 키워드 목록 NULLABLE SMALLINT 데이터 타입의 NULL 값 허용 여부 CASE_SENSITIVE SMALLINT 대/소문자 구분 여부 SEARCHABLE SMALLINT WHERE절에서 데이터 타입 사용 방법 UNSIGNED_ATTRIBUTE SMALLINT 데이터 타입의 부호 여부. FIXED_PREC_SCALE SMALLINT 데이터 타입이 고정형인지 나타낸다. AUTO_UNIQUE_VALUE SMALLINT 향후 확장 예정 LOCAL_TYPE_NAME VARCHAR(40)데이터 타입에 대한 로컬화된(자국어) 이 름 MINIMUM_SCALE SMALLINT 데이터 타입 정의시 허용가능한 최소 소 수 자릿수 MAXIMUM_SCALE SMALLINT 데이터 타입 정의시 허용가능한 최대 소 수 자릿수 SQL_DATA_TYPE SMALLINT SQL_DESC_TYPE에서 지원하는 SQL 데이터 타입 정의 값. SQL_DATETIME_SUB SMALLINT datetime 또는 interval 타입의 하위 코 드. NUM_PREC_RADIX INTEGER 열이 보유할수 있는 최대 수를 계산하기 위해 필요한 비트수 INTERVAL_PRECISION SMALLINT DATA_TYPE이 interval인 경우에 해당 데이터 타입에 표현할 수 있는 전체 자 릿수를 포함하는 간격의 값. 1 ODBC SQLGettypeInfo() 함수에서 조회하는 값이다. 자세한 내용은 ODBC User’s Manual을 참고한다. 122 ALTIBASE5 Administrator’s Manual 칼럼 정보 ODBC_DATA_TYPE 해당하는 데이터 타입에 대응하는 ODBC SQL 데이타 타입 식별자이다. 이에 대한 자세한 내용은 ODBC User’s Manual의 부록 데이터 형을 참고한다. COLUMN_SIZE 해당 타입에 대한 최대 칼럼 크기이다. 숫자형 타입의 경우, 타입 정의시에 주어진 Precision 값이 되고, 문자형 타입의 경우에는 타입 정의시에 주어진 길이 값이 할당된다. 날짜형 타입의 경우 문자로 변경될 때 값을 표시하기 위해 필요한 총 문자 수가 할당된다. LITERAL_PREFIX 해당 데이터 타입의 리터럴에 대한 접두부로 인식하는 문자로 리터럴 접두부를 적용할 수 없는 데이터 타입인 경우 NULL 이다 LITERAL_SUFFIX 해당 데이터 타입의 리터럴에 대한 접미부로 인식하는 문자로 리터럴 접두부를 적용할 수 없는 데이터 타입인 경우 NULL 이다. CREATE_PARAM SQL 에서 데이터 타입 정의시 괄호로 표현되는 매개변수 키워드목록으로 쉼표로 구분된다. NUMBER(precision,scale) 표현되는 NUMBER 를 예로 들면, 괄호 안의 ‘precision,scale’이 해당된다. 목록의 키워드는 precision, scale 중 하나일 수 있으며 매개변수 없이 정의되는 데이터 타입 경우, NULL 로 설정된다. NULLABLE 데이터 타입에서 NULL 값을 허용하는지 나타낸다. 1 : NULL 값을 허용한다. 0 : NULL 값을 허용하지 않는다. CASE_SENSITIVE 데이터 타입을 정렬할 때 대/소문자를 구분하는지 나타낸다. 1 : 대/소문자를 구분한다. 0 : 대/소문자를 구분하지 않는다. SEARCHABLE WHERE 절에서 데이터 타입을 사용하는 방법을 나타낸다. 데이터 딕셔너리 123 0 : WHERE 절에서 사용될 수 없다(SQL_PRED_NONE) 1 : WHERE 절에서 사용될 수 있으나, LIKE 와 함께 사용되어야 한다(SQL_PRED_CHAR) 2 : WHERE 절에서 LIKE 를 제외한 모든 비교 연산자들과 사용될 수 있다(SQL_PRED_BASIC) 3 : WHERE 절에서 모든 비교 연산자들과 사용될 수 있다(SQL_SEARCHABLE) UNSIGNED_ATTRIBUTE 데이터 타입의 부호 여부를 나타한다. 1 : 해당 타입이 부호없는(unsigned) 데이타 타입이다. 0 : 해당 타입이 부호를 가지는(signed) 데이타 타입이다. NULL : 해당 타입이 숫자형이 아니거나. 적용되지 않는다. FIXED_PREC_SCALE 데이터 타입이 고정형인지 나타낸다. 해당 데이터 타입이 고정형 숫자 타입이고 항상 같은 정밀도 (precision)와 소수 자릿수(scale)를 가지면 1(SQL_TRUE), 그렇지 않은 경우 0(SQL_FALSE)이다. LOCAL_TYPE_NAME 데이터 타입에 대한 로컬화된(자국어) 이름을 나타낸다. 로컬화된 이름이 없는 경우 NULL 이다. MINIMUM_SCALE 데이터 타입 정의시 허용가능한 최소 소수 자릿수이다. 고정 scale 타입일 경우 이 값이 설정되며 scale 이 적용되지 않는 타입에 대해서는 NULL 로 나타난다. MAXIMUM_SCALE 데이터 타입 정의시 허용가능한 최대 소수 자릿수이다. scale 이 적용되지 않는 타입의 경우, NULL 로 설정된다. SQL_DATA_TYPE SQL_DESC_TYPE 에서 지원하는 SQL 데이터 타입이다. interval, datetime 데이터 타입을 제외한 다른 타입의 경우, ODBC_DATA_TYPE 값과 같다. SQL_DATETIME_SUB SQL_DATA_TYPE 값이 SQL_DATETIME 또는 124 ALTIBASE5 Administrator’s Manual SQL_INTERVAL 인 경우 datetime 또는 interval 의 하위 코드이다. 데이터 타입이 datetime 또는 interval 이 아닌 경우는 NULL 이다. NUM_PREC_RADIX 열이 보유할 수 있는 최대 수를 계산하는데 필요한 비트수 또는 자릿수입니다. INTERVAL_PRECISION DATA_TYPE 이 interval 인 경우에 해당 데이터 타입에 표현할 수 있는 전체 자릿수이다. 데이터 딕셔너리 125 V$DBA_2PC_PENDING DBMS 에 존재하는 분산 트랜잭션 중에서 현재 in-doubt 상태인 XID 의 목록을 보여준다. 분산 트랜잭션에서 in-doubt 상태란 커밋할 준비가 된 상태에서 커밋 또는 롤백 명령을 받기 전까지의 트랜잭션 브랜치를 의미한다. Column name Type Description LOCAL_TRAN_ID BIGINT 글로벌 트랜잭션 아이디와 연계되는 ALTIBASE 내부의 트랜잭션 아이 디 GLOBAL_TX_ID VARCHAR(256) 글로벌 트랜잭션 아이디 칼럼 정보 LOCAL_TRAN_ID ALTIBASE 내부의 트랜잭션 아이디로써 글로벌 트랜잭션 아이디와 연계된다. GLOBAL_TX_ID 글로벌 트랜잭션 아이디를 나타낸다. 글로벌 트랜잭션 아이디는 XID 의 포맷(format) 아이디, 글로벌 트랜잭션(global transaction) 아이디, 브랜치 수식자(branch qualifier)를 문자열로 나타낸다. 126 ALTIBASE5 Administrator’s Manual V$DBLINK_REMOTE_STATEMENT_INFO 데이터베이스 링크를 사용했을 때, 원격 서버에 파생되어 발생한 질의문 정보를 보여준다 Column name Type Description TRANSACTION_ID INTEGER 데이터베이스 링크를 사용한 트 랜잭션 식별자 REMOTE_TRANSACTION_ID INTEGER 원격 서버에 발생한 트랜잭션 식 별자 STATEMENT_ID INTEGER 원격 서버에 발생한 문장 (Statement) 식별자 QUERY VARCHAR(1024) 문장에서 실행한 질의 내용 칼럼 정보 REMOTE_TRANSACTION_ID 원격 서버에 발생한 트랜잭션 식별자이다. 이 식별자는 실제 원격 서버에서 생성된 트랜잭션 식별자가 아니라, 원격 서버에 트랜잭션을 생성할 때 AltiLinker 가 자체적으로 부여한 식별자이다. 이 식별자는 관리 목적으로 생성된 것이므로, 그 값 자체에 의미를 둘 필요는 없다. STATEMENT_ID 원격 서버에 발생한 문장(Statement) 식별자이다. 이 식별자는 실제 원격 서버에서 생성된 문장 식별자가 아니라, 원격 서버에 문장을 생성할 때 AltiLinker 가 자체적으로 부여한 식별자이다. 이 식별자는 관리 목적으로 생성된 것이므로, 그 값 자체에 의미를 둘 필요가 없다. 데이터 딕셔너리 127 V$DBLINK_REMOTE_TRANSACTION_INFO 데이터베이스 링크를 사용했을 때, 원격 서버에 파생되어 발생한 트랜잭션의 정보를 보여준다. Column name Type Description TRANSACTION_ID INTEGER 데이터베이스 링크를 사용한 트랜 잭션 식별자 REMOTE_TRANSACTION_ID INTEGER 원격 서버에 발생한 트랜잭션 식 별자 CONNECTION_METHOD INTEGER 0: ODBC 1: Native(향후 확장 예정) CONNECTION_STRING VARCHAR(41) Connection String ACTIVE_STATEMENT_COUNT INTEGER 실행중인 질의문의 개수 칼럼 정보 REMOTE_TRANSACTION_ID 원격 서버에 발생한 트랜잭션 식별자이다. 이 식별자는 실제 원격 서버에서 생성된 트랜잭션 식별자가 아니라, 원격 서버에 트랜잭션을 생성할 때 AltiLinker 가 자체적으로 부여한 식별자이다. 이 식별자는 관리 목적으로 생성된 것이므로, 그 값 자체에 의미를 둘 필요가 없다. 128 ALTIBASE5 Administrator’s Manual V$DBLINK_TRANSACTION_INFO 현재 데이터베이스 링크를 사용하는 트랜잭션에 대한 정보를 나타낸다. Column name Type Description TRANSACTION_ID INTEGER 현재 데이터베이스 링크를 사용하는 트 랜잭션의 식별자 STATUS INTEGER 향후 확장 예정 CONSISTENCY INTEGER 향후 확장 예정 데이터 딕셔너리 129 V$DB_FREEPAGELISTS 데이터베이스의 사용가능한 페이지 리스트들의 정보를 보여준다. Column name Type Description SPACE_ID INTEGER 사용가능한 페이지들이 속한 테이블스 페이스 식별자 RESOURCE_GROUP_ID INTEGER 리스트의 자원 그룹 식별자 FIRST_FREE_PAGE_ID INTEGER 리스트의 첫번째 사용가능한 페이지 아 이디 FREE_PAGE_COUNT BIGINT 리스트의 사용가능한 페이지 개수 칼럼 정보 RESOURCE_GROUP_ID 다중화된 리스트들을 식별하기 위한 고유 번호를 나타낸다. FIRST_FREE_PAGE_ID 해당 리스트의 맨 앞에 위치한 사용가능한 페이지 아이디를 표현한다. FREE_PAGE_COUNT 해당 리스트에 속한 사용가능한 페이지 개수를 나타낸다. 130 ALTIBASE5 Administrator’s Manual V$DB_PROTOCOL 서버로 유입되는 모든 데이터베이스 프로토콜들의 정보를 보여준다. Column name Type Description QP_NAME VARCHAR(50) 프로토콜 이름 QP_ID INTEGER 프로토콜의 고유 아이디 COUNT BIGINT 유입된 프로토콜 개수의 누적치 데이터 딕셔너리 131 V$DISKTBL_INFO 디스크 테이블의 정보를 보여준다. Column name Type Description TABLESPACE_ID SMALLINT 테이블스페이스 아이디. TABLE_OID BIGINT 테이블 헤더의 OID DISK_TOTAL_PAGE_CN T BIGINT 테이블이 가지고 있는 전체 페이지 개수 DISK_PAGE_CNT BIGINT 테이블에서 데이터를 갖고 있는 페이지 개 수 SEG_PID INTEGER 테이블의 세그먼트의 페이지 ID META_PAGE INTEGER 세그먼트의 메타 정보 저장 FST_EXTRID BIGINT 테이블의 첫번째 익스텐트의 RID LST_EXTRID BIGINT 테이블의 마지막 익스텐트의 RID PCTFREE SMALLINT 페이지 내 여유 공간의 비율 PCTUSED SMALLINT 페이지 내 사용 공간의 비율 INITRANS SMALLINT페이지 내 동시 처리 가능한 초기 트랜잭션 개수 MAXTRANS SMALLINT페이지 내 동시 처리 가능한 최대 트랜잭션 개수 INITEXTENTS INTEGER 테이블 생성시 초기 익스텐트 개수 NEXTEXTENTS INTEGER 테이블 확장시 할당할 익스텐트 개수 MINEXTENTS INTEGER 테이블의 최소 익스텐트 개수 MAXEXTENTS INTEGER 테이블의 최대 익스텐트 개수 COMPRESSED_LOGGING INTEGER 테이블의 로그 압축 여부 테이블 이름을 포함하여 보려면 다음과 같이 메타 테이블과 조인하여 질의를 하여야 한다. SELECT A.TABLE_NAME, B.DISK_PAGE_CNT, B .PC T FREE , B.PCTUSED FROM SYSTEM_.SYS_TABLES_ A, V$DISKTBL_INFO B WHERE A.TABLE_OID = B.TABLE_OID; 칼럼 정보 PCTFREE 한 페이지가 삽입 연산이 가능한 상태를 유지하는 여유 공간의 최소 132 ALTIBASE5 Administrator’s Manual 비율을 의미한다. 기존에 페이지에 저장된 행들을 갱신하기 위해 PCTFREE 에서 명시한 비율만큼의 여유 공간을 페이지에 할당한다. 예를 들어 이 값을 20 으로 명시한 경우, 20%의 공간은 갱신 연산을 위해 공간을 남겨두고, 80%의 공간에 대해서만 삽입 연산이 가능하다. 0 에서 99 사이의 값으로 CREATE TABLE 문 정의시 사용자가 명시할 수 있다. PCTUSED 페이지가 갱신만 가능한 상태에서 다시 삽입이 가능한 상태로 가기 위한 페이지 사용 공간의 최소 비율을 의미한다. 페이지의 여유 공간이 PCTFREE 에 명시한 비율에 도달하면 더 이상 삽입 연산은 안되며, 갱신만 가능해진다. 이후 갱신과 삭제 등으로 페이지 사용 공간의 비율이 PCTUSED 에서 정한 값보다 낮아지면 새로운 행을 삽입할 수 있다. 0 에서 99 사이의 값으로 CREATE TABLE 문 정의시 사용자가 명시할 수 있다. * PCTFREE 와 PCTUSED 에 대한 자세한 설명은 SQL Users Manual 의 CREATE TABLE 문 설명을 참조한다. INITRANS 하나의 테이블 페이지 내에서 동시에 처리할 수 있는 트랜잭션의 초기 개수를 나타낸다. MAXTRANS 하나의 테이블 페이지 내에서 동시에 처리할 수 있는 트랜잭션의 최대 개수를 나타낸다. INITEXTENTS 테이블 세그먼트 생성시 초기 익스텐트 개수를 나타낸다. NEXTEXTENTS 테이블 세그먼트 확장시 할당할 익스텐트 개수를 나타낸다. MINEXTENTS 테이블 세그먼트의 최소 익스텐트 개수를 나타낸다. MAXEXTENTS 테이블 세그먼트의 최대 익스텐트 개수를 나타낸다. 데이터 딕셔너리 133 V$DISK_BTREE_HEADER 디스크 BTREE 인덱스의 헤더 정보를 보여준다. Column name Type Description INDEX_NAME CHAR(40) 인덱스 이름 INDEX_ID INTEGER 인덱스 아이디 INDEX_TBS_ID INTEGER 인덱스가 저장되어 있는 테이블스페이 스 TABLE_TBS_ID INTEGER 테이블이 저장되어 있는 테이블스페이 스 IS_UNIQUE CHAR(1) 유일 키의 인덱스 여부 IS_CONSISTENT CHAR(1) 인덱스의 일관성 여부 IS_CREATED_WITH_LOGGI NG CHAR(1) 인덱스 생성시 로깅 여부 IS_CREATED_WITH_FORCE CHAR(1) 인덱스 생성시 강제적 디스크 저장 여 부 COMPLETION_LSN_LFG_ID INTEGER 인덱스 생성 시점 (로그 그룹 아이디) COMPLETION_LSN_FILE_N O INTEGER 인덱스 생성 시점 (로그 파일 번호) COMPLETION_LSN_FILE_O FFSET INTEGER 인덱스 생성 시점 (로그 파일 옵셋) INIT_TRANS SMALLINT하나의 인덱스 노드에서 동시 처리 가능한 초기 트랜잭션 개수 MAX_TRANS SMALLINT하나의 인덱스 노드에서 동시 처리 가능한 최대 트랜잭션 개수 FREE_NODE_HEAD INTEGER 프리 노드의 첫번째 페이지 FREE_NODE_CNT BIGINT 프리 노드의 페이지 개수 INITEXTENTS INTEGER 테이블 생성시 초기 익스텐트 개수 NEXTEXTENTS INTEGER 테이블 확장시 할당할 익스텐트 개수 MINEXTENTS INTEGER 테이블의 최소 익스텐트 개수 MAXEXTENTS INTEGER 테이블의 최대 익스텐트 개수 칼럼 정보 INDEX_NAME 인덱스의 이름을 나타낸다. 134 ALTIBASE5 Administrator’s Manual INDEX_ID 해당 인덱스가 갖는 시스템 내에서 고유한 아이디를 나타낸다. INDEX_TBS_ID 인덱스가 저장되어 있는 테이블스페이스 아이디를 나타낸다. TABLE_TBS_ID 해당 인덱스와 연결되어 있는 테이블의 테이블스페이스 아이디를 나타낸다. IS_UNIQUE 유일키 인덱스 여부를 나타낸다. 유일키 인덱스는 ‘T’를, 중복키 인덱스의 경우는 ‘F’를 갖는다. IS_CONSISTENT 인덱스의 일관성 여부를 나타낸다. 일반적인 경우에는 ‘T’를 가지며, 인덱스가 비정상적으로 구성되어 있는 경우는 ‘F’를 갖는다. NOLOGGING 이나 NOFORCE 를 이용하여 인덱스를 생성한 경우에는 ‘F’를 가질수 있다. IS_CREATED_WITH_LOGGING 인덱스 생성 당시 부여되었던 로깅 여부를 나타낸다. IS_CREATED_WITH_FORCE 인덱스 생성 당시 부여되었던 강제적 디스크 저장 여부를 나타낸다. COMPLETION_LSN_LFG_ID 인덱스가 생성된 시점에서의 로그 그룹 아이디를 나타낸다. 해당 칼럼 하나로는 의미가 없으며, COMPLETION_LSN_FILE_NO 와 COMPLETION_LSN_FILE_OFFSET 이 합쳐 LSN 을 구성한다. 해당 LSN 은 인덱스의 생성이 완료된 시점을 나타낸다. COMPLETION_LSN_FILE_NO 인덱스가 생성된 시점에서의 로그 파일 번호를 나타낸다. COMPLETION_LSN_FILE_OFFSET 인덱스가 생성된 시점에서의 로그 파일 오프셋(Offset)을 나타낸다. INIT_TRANS 하나의 인덱스 노드에서 동시에 처리할 수 있는 트랜잭션의 초기 개수를 나타낸다. MAX_TRANS 데이터 딕셔너리 135 하나의 인덱스 노드에서 동시에 처리할 수 있는 트랜잭션의 최대 개수를 나타낸다. FREE_NODE_HEAD FREE NODE 는 노드 내의 모든 키에 삭제 마크가 설정되어 있는 상태의 노드를 나타내는 것으로, FREE_NODE_HEAD 는 인덱스 내에 FREE NODE 들의 첫번째 페이지를 나타낸다. FREE_NODE_CNT 인덱스 내에 FREE NODE 의 전체 개수를 나타낸다. INITEXTENTS 인덱스 세그먼트 생성시 초기 익스텐트 개수를 나타낸다. NEXTEXTENTS 인덱스 세그먼트 확장시 할당할 익스텐트 개수를 나타낸다. MINEXTENTS 인덱스 세그먼트의 최소 익스텐트 개수를 나타낸다. MAXEXTENTS 인덱스 세그먼트의 최대 익스텐트 개수를 나타낸다. 136 ALTIBASE5 Administrator’s Manual V$EVENT_NAME 알티베이스 서버에서 대기하고 있는 다양한 대기 이벤트들의 정보를 보여준다. Column name Type Description EVENT_ID INTEGER 대기 이벤트의 ID NAME VARCHAR( 128) 대기 이벤트의 이름 WAIT_CLASS_ID INTEGER 대기 클래스의 ID WAIT_CLASS VARCHAR( 128) 대기 클래스 이름 칼럼 정보 EVENT_ID 대기하고 있는 이벤트의 ID를 나타낸다. NAME 대기하고 있는 이벤트의 이름을 나타낸다. EVENT_ ID NAME Description 0 latch: buffer busy waits 다른 세션이 변경하고 있는 블록에 접근할 때 대기 1 latch: drdb B- tree index SMO B-tree 인덱스의 SMO를 수행하는 세션에 의해 발생 2 latch: drdb B- tree index SMO by other session 다른 세션에 의해 수행되는 B-tree 인덱스의 SMO 연산 완료될 때까지 대기 3 db file multi page read 다중 PAGE READ I/O 요청이 완료 되기를 대기하는 세션에 의해 발생 4 db file single page read 단일 PAGE READ I/O 요청이 완료 되기를 대기하는 세션에 의해 발생 5 db file single page write lru flush를 수행하기 전에 free bcb 가 확보될 때까지 대기 6 enq: TX - row lock contention, data row 갱신을 위해 로우(row)에 잠금을 한 대기 7 enq: TX - allocate data 테이블 페이지에서 TTS를 할당하기 위한 대기 데이터 딕셔너리 137 EVENT_ ID NAME Description TTS 8 enq: TX - allocate TXSEG entry 트랜잭션 세그먼트 엔트리를 할당하 기 위한 대기 9 latch free: drdb file i/o 디스크 파일에 READ/WRITE IO를 수행하기 위해서 파일 래치에 대해 대기 10 latch free: drdb tbs list 다른 쓰레드에 의해 사용되고 있는 테이블스페이스의 해시 래치를 얻기 위해 대기 11 latch free: drdb tbs creation 테이블스페이스 생성시 파일을 생성 하려는 세션에 의해 발생하는 대기 12 latch free: disk page list entry 다른 쓰레드에 의해 사용되고 있는 디스크 페이지 리스트 엔트리의 래치 를 획득하기를 대기 13 latch free: drdb transaction segment freelist 트랜잭션 세그먼트 프리 리스트에 대 한 대기 14 latch free: drdb LRU list 버퍼 풀의 lru list들에 대한 대기 15 latch free: drdb prepare list 버퍼 풀의 prepare list들에 대한 대 기 16 latch free: drdb prepare list wait 버퍼 풀의 prepare list에 bcb가 추 가될 때까지 대기 17 latch free: drdb flush list 버퍼 풀의 flush list들에 대한 대기 18 latch free: drdb checkpoint list 버퍼 풀의 checkpoint list들에 대한 대기 19 latch free: drdb buffer flusher min recovery LSN 버퍼 풀의 flusher의 Recovery LSN 동시성 제어를 위한 래치에 대 기 20 latch free: drdb buffer flush manager req job 버퍼 풀의 flush job의 동시성 제어 를 위한 래치에 대기 21 latch free: drdb buffer bcb mutex 버퍼 풀의 BCB 동시성 제어에 대한 래치 대기 22 latch free: drdb buffer bcb read io mutex 버퍼 풀의 BCB로 페이지 적재에 대 한 래치 대기 138 ALTIBASE5 Administrator’s Manual EVENT_ ID NAME Description 23 latch free: drdb buffer buffer manager expand mutex 버퍼 풀의 확장에 대한 대기 24 latch free: drdb buffer hash mutex 버퍼 풀의 해시에 대한 대기 25 latch free: others 다른 쓰레드에 의해 사용되고 있는 위에 언급되지 않은 모든 래치에 대 해서 획득하기를 대기 26 no wait event대기 이벤트가 존재하지 않음 WAIT_CLASS_ID 대기하고 있는 이벤트의 클래스 ID를 나타낸다. 이벤트 클래스 ID에 대한 자세한 정보는 V$WAIT_CLASS_NAME를 참조하기 바란다. WAIT_CLASS 대기하고 있는 이벤트를 그룹화하기 위한 상위 개념의 클래스를 나타낸다. 클래스에 대한 자세한 정보는 V$WAIT_CLASS_NAME 를 참조하기 바란다. 데이터 딕셔너리 139 V$FILESTAT 각각의 디스크에 있는 데이터 파일별 I/O 통계 정보를 보여준다. 통 계 정보를 통해 핫스팟(hotspot) 데이터 파일을 알 수 있다. Column name Type Description SPACEID INTEGER 테이블스페이스의 ID FILEID INTEGER 데이터 파일의 ID PHYRDS BIGINT 물리적 Read I/O 발생 회수 PHYWRTS BIGINT 물리적 Write I/O 발생 회수 PHYBLKRD BIGINT 물리적인 Read로 판독한 페이지 개수 PHYBLKWRT BIGINT 물리적인 Write로 기록한 페이지 개수 SINGLEBLKRDS BIGINT 단일 페이지에 대한 Read 개수 READTIM DOUBLE Read I/O 시간 (밀리초) WRITETIM DOUBLE Write I/O 시간 (밀리초) SINGLEBLKRDTIM DOUBLE 단일 페이지에 대한 Read 시간 (밀리초) AVGIOTIM DOUBLE 평균 I/O 시간 (밀리초) LSTIOTIM DOUBLE 마지막 I/O 시간 (밀리초) MINIOTIM DOUBLE 최소 I/O 시간 (밀리초) MAXIORTM DOUBLE 최대 Read I/O 시간 (밀리초) MAXIOWTM DOUBLE 최대 Write I/O 시간 (밀리초) 칼럼 정보 SPACEID 테이블스페이스의 ID 를 나타낸다. FILEID 데이터 파일의 ID 를 나타낸다. PHYRDS 물리적 Read I/O 가 발생한 회수를 나타낸다. PHYWRTS 물리적 Write I/O 가 발생한 회수를 나타낸다. PHYBLKRD 물리적인 Read 로 판독한 페이지 개수를 나타낸다. 140 ALTIBASE5 Administrator’s Manual PHYBLKWRT 물리적인 Write 로 기록한 페이지 개수를 나타낸다. SINGLEBLKRDS 단일 페이지에 대한 Read 개수를 나타낸다. READTIM Read I/O 시간을 나타낸다. (단위: 밀리초) WRITETIM Write I/O 시간을 나타낸다. (단위: 밀리초) SINGLEBLKRDTIM 단일 페이지에 대하여 Read 시간을 나타낸다. (단위: 밀리초) AVGIOTIM 평균 I/O 시간을 나타낸다. (단위: 밀리초) LSTIOTIM 마지막 I/O 시간을 나타낸다. (단위: 밀리초) MINIOTIM 최소 I/O 시간을 나타낸다. (단위: 밀리초) MAXIORTM 최대 Read I/O 시간을 나타낸다. (단위: 밀리초) MAXIOWTM 최대 Write I/O 시간을 나타낸다. (단위: 밀리초) 데이터 딕셔너리 141 V$FLUSHINFO 버퍼 플러시 정보를 보여준다. Column name Type Description LOW_FLUSH_LENGTH INTEGER 교체 플러시(replacement flush)를 유발 시킬 수 있는 최소한의 플러시 리스트 길이 HIGH_FLUSH_LENGTH INTEGER 플러셔가 REPLACE_FLUSH_COUNT 값을 무시하고 플러시 리스트의 모든 버 퍼를 플러시하는 플러시 리스트 길이 LOW_PREPARE_LENGTH INTEGER 교체 플러시를 유발시킬 수 있는 최소한 의 prepare 리스트 길이. 이 길이 이하 가 되면 교체 플러시가 발생한다. CHECKPOINT_FLUSH_CO UNT BIGINT 체크포인트 플러시 수행시 플러시 할 버 퍼의 개수 REQ_JOB_COUNT INTEGER 현재 플러시 관리자에 등록된 작업의 개 수 142 ALTIBASE5 Administrator’s Manual V$INDEX 현재 데이터베이스에 존재하는 인덱스 정보를 보여준다. Column name Type Description TABLE_OID BIGINT 테이블 헤더의 OID INDEX_SEG_PID INTEGER 디스크 인덱스의 경우 인덱스 세그먼트 헤더(header)의 페이지 ID INDEX_ID INTEGER 인덱스 ID INDEXTYPE VARCHAR(7) 해당 인덱스가 주 키(primary key)로 사용되는지 일반 인덱스인지 식별하기 위한 구분자 데이터 딕셔너리 143 V$INSTANCE 현재 알티베이스의 구동 단계, 구동된 시간, 구동 후 경과된 시간에 관한 정보를 보여준다. Column name Type Description STARTUP_PHASE VARCHAR(13) 다단계 재구동 단계 중 현재 단계 STARTUP_TIME_SEC BIGINT 재구동 시간 WORKING_TIME_SEC BIGINT 재구동하여 지금까지 동작한 시간 144 ALTIBASE5 Administrator’s Manual V$LATCH 버퍼 풀의 BCB latch 정보이며, 읽기 혹은 쓰기가 시도된 페이지에 대하여 latch 시도 횟수와 바로 latch 를 잡는 횟수, 잡지 못한 횟수 등을 각각 읽기/쓰기 latch 에 대하여 통계 정보를 보여준다. Column name Type Description SPACE_ID INTEGER 테이블스페이스 아이디 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한 횟수 데이터 딕셔너리 145 V$LFG 알티베이스는 데이터베이스 관리자가 그룹 커밋의 동작을 모니터링 할 수 있는 통계 정보를 제공한다. 각 칼럼에 대한 보다 상세한 정보는 이 매뉴얼의 그룹 커밋 부분을 참조한다. Column name Type Description LFG_ID INTEGER 로그파일그룹 ID CUR_WRITE_LF_NO INTEGER 기록 로그 파일 번호 CUR_WRITE_LF_OFFSET 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 칼럼 정보 146 ALTIBASE5 Administrator’s Manual LFG_ID 0 부터 시작하여 1 씩 증가하는 로그파일 그룹 고유번호이다. 예를들어, 시스템에 네 개의 로그파일 그룹이 존재한다면, LFG_ID 를 조회했을 때 0,1,2,3 네 개의 행을 볼 수 있다. CUR_WRITE_LF_NO 현재 로그를 기록하기 위해 사용하고 있는 로그 파일의 번호이다. CUR_WRITE_LF_OFFSET 현재 로그를 기록하기 위해 사용하고 있는 로그 파일의 옵셋이다. 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_ID 칼럼과 같은 값을 지닌다. LFG 별로 재구동 시 REDO 를 정확하게 이 부분에서 시작하지는 않는다. 하지만 최소한 이 LSN 이후의 로그는 반드시 REDO 된다는 것을 보장할 수 있다. END_LSN_FILE_NO Restart 시 REDO 를 시작할 LSN(Log Sequence Number)중 로그파일의 번호를 나타낸다. END_LSN_OFFSET Restart 시 REDO 를 시작할 LSN(Log Sequence Number)중 데이터 딕셔너리 147 로그파일 안의 오프셋을 나타낸다. 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 에 속한 트랜잭션 수를 실시간으로 반환한다. GC_WAIT_COUNT 그룹커밋을 위해 이 LFG 에 속한 트랜잭션들이 디스크 I/O 를 기다린 횟수를 보여준다. GC_ALREADY_SYNC_COUNT 그룹커밋 도중 이 LFG 에 속한 트랜잭션들이 필요로 하는 만큼의 디스크 I/O 가 이미 수행되어 별도의 디스크 I/O 를 수행하지 않은 횟수를 보여준다. GC_REAL_SYNC_COUNT 그룹커밋 도중 LFG 에 속한 트랜잭션들이 실제로 디스크 I/O 를 수행한 횟수를 나타낸다. 148 ALTIBASE5 Administrator’s Manual V$LINKER_STATUS 데이타베이스 링크를 위한 AltiLinker 의 상태 정보를 나타낸다. Column name Type Description LINKER_STATUS INTEGER Linker의 상태를 나타낸다. 1 : Linker가 정상적인 상태 0 : Linker가 비정상적인 상태이거나 Linker가 떠 있지 않은 상태 SESSION_COUNT INTEGER 알티베이스와 Linker 사이의 데이타베 이스 링크 세션의 개수를 나타낸다. 칼럼 정보 LINKER_STATUS Linker 의 상태를 나타낸다. 값이 1 이면 Linker 가 정상적인 상태이다. 그러나 0 이면 Linker 가 비정상적인 상태이거나 Linker 가 떠 있지 않은 상태이다. 데이터 딕셔너리 149 V$LOCK 현재 시점에서 데이터베이스의 모든 테이블 잠금(lock) 노드 정보를 보여준다. Column name Type Description LOCK_ITEM_TYPE VARCHAR(7) 잠금 대상 객체의 종류(Type) TBS_ID INTEGER 테이블스페이스 식별자 TABLE_OID BIGINT 테이블 OID DBF_ID BIGINT 데이터베이스 파일 식별자 TRANS_ID BIGINT 트랜잭션 아이디 LOCK_DESC VARCHAR(32) 잠금 모드에 대한 문자열 Ex) IX, IS, X LOCK_CNT INTEGER 해당 잠금 노드의 잠금 개수 IS_GRANT BIGINT 해당 테이블에 대하여 잠금을 잡고 있 는지, 대기하고 있는지를 나타낸다. 칼럼 정보 LOCK_ITEM_TYPE 잠금(Lock) 대상 객체 유형을 나타내며 다음의 값을 가진다. Value Description NONE 이 값을 가질 수 없음. TBS 테이블스페이스 TBL 테이블 DBF 데이터베이스 파일 UNKNOWN 객체 유형을 알 수 없음 150 ALTIBASE5 Administrator’s Manual V$LOCK_STATEMENT 잠금(lock)과 문장(statement) 정보를 같이 보여준다. Column name Type Description SESSION_ID BIGINT 세션 식별자 ID BIGINT SQL 문장 식별자 TX_ID BIGINT 트랜잭션 식별자 QUERY VARCHAR(1024) 질의문 STATE BIGINT 문장 상태 BEGIN_FLAG BIGINT 문장 시작 플래그 LOCK_ITEM_TYPE VARCHAR(7) 잠금 대상 객체의 종류(Type) TBS_ID INTEGER 테이블스페이스 식별자 TABLE_OID BIGINT 테이블 OID DBF_ID BIGINT 데이터베이스 파일 식별자 LOCK_DESC VARCHAR(32) 잠금 모드에 대한 문자열 예) IX, IS, X LOCK_CNT INTEGER 해당 잠금 노드의 잠금 개수 IS_GRANT BIGINT 해당 테이블에 대하여 잠금을 잡고 있 는지, 대기하고 있는지를 나타낸다. 데이터 딕셔너리 151 V$LOG 로그 앵커 정보를 보여준다. Column name Type Description BEGIN_CHKPT_LFGID INTEGER 가장 최근 수행된 검사점의 검사점시작 로그의 LFGID BEGIN_CHKPT_FILE_NO INTEGER 가장 최근 수행된 검사점의 검사점 시작 로그의 로그 파일 번호 BEGIN_CHKPT_FILE_OFF SET INTEGER 가장 최근 수행된 검사점의 검사점 시작 로그의 로그 오프셋 END_CHKPT_LFGID INTEGER 가장 최근 수행된 검사점의 검사점종료 로그의 LFGID END_CHKPT_FILE_NO INTEGER 가장 최근 수행된 검사점의 검사점 종료 로그의 로그 파일 번호 END_CHKPT_FILE_OFFSE T INTEGER 가장 최근 수행된 검사점의 검사점 종료 로그의 로그 오프셋 SERVER_STATUS VARCHAR(1 5) 서버의 상태를 나타내며 1인 경우 서버 가 수행 중임을 나타낸다. ARCHIVELOG_MODE VARCHAR(1 2) 데이터베이스의 아카이브 모드 상태 TRANSACTION_SEGMENT _COUNT INTEGER 언두 테이블스페이스에 생성할 트랜잭션 세그먼트의 개수 OLDEST_LFGID INTEGER 재구동 복구(Restart recovery) 시에 디 스크 관련 redo가 시작되는 LSN의 LFGID OLDEST_LOGFILE INTEGER 재구동 복구 시에 디스크 관련 redo가 시작되는 로그 파일 번호 OLDEST_LOGFILE_OFFSE T INTEGER 재구동 복구 시에 디스크 관련 redo가 시작되는 로그 파일 오프셋(offset) 152 ALTIBASE5 Administrator’s Manual 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 208 534 208 2 rows selected. 트랜잭션 2208 에 대해서 트랜잭션 1216 과 트랜잭션 5344 가 현재 대기하고 있다. 데이터 딕셔너리 153 V$MEMGC 메모리 공간 회수 즉, 가비지 콜렉션(memory garbage collect) 정보를 보여준다. Column name Type Description GC_NAME VARCHAR(1 28) MEM_LOGICAL_AGER: 구버전 인덱 스 키 슬롯 해제 쓰레드 MEM_DELTHR: 삭제된 레코드를 해제 하고 DROP TABLE 등 지연된 (pending) 연산을 하는 쓰레드 CURRSYSTEMVIEWSCN VARCHAR(2 9) 현재 system view SCN MINMEMSCNINTXS VARCHAR(2 9) 메모리 관련 트랜잭션의 view SCN 중 가장 작은 SCN OLDESTTX INTEGER 가장 오랜된 트랜잭션 식별자 (MINMEMSCNINTXS를 소유한 트랜잭 션 식별자) SCNOFTAIL VARCHAR(2 9) 공간 회수 OID 리스트의 Tail의 Commit SCN IS_EMPTY_OIDLIST BIGINT 공간 회수 OID 리스트가 비어 있는지 여부 0: 비어 있음 1: 비어 있지 않음 ADD_OID_CNT BIGINT 공간 회수 처리를 위하여 추가된 OID 개수 GC_OID_CNT BIGINT 공간 회수한 OID 개수 AGING_REQUEST_OID_C NT BIGINT 공간 회수 처리 요청 개수(OID 단위의 개수) AGING_PROCESSED_OID _CNT BIGINT 공간 회수 처리 개수(OID 단위의 개수) THREAD_COUNT INTEGER 공간 회수 쓰레드 갯수 칼럼 정보 알티베이스는 MVCC를 지원하므로 하나의 레코드에 대해 여러 버전 이 생길 수 있다. 즉 하나의 레코드는 1개의 최신버전과 다수의 구버 전으로 구성된다. MVCC에 대한 자세한 내용은 Starting User’s Manual의 다중버전 기법 부분과 본 매뉴얼의 다중 버전 동시성 제어 기법 부분을 참조한다. 154 ALTIBASE5 Administrator’s Manual AGING_REQUEST_OID_CNT 한 트랜잭션이 레코드 10 건을 지우고 커밋할 경우, 10 건의 구버전 레코드가 생기기 때문에 10 건의 공간 회수 대상이 생긴다. 하지만 기존 ADD_OID_CNT 는 트랜잭션 단위로 계산하기 때문에 1 증가한다. 이해 반해 AGING_REQUEST_OID_CNT 는 OID 단위로 계산하기 때문에 10 만큼 증가한다. AGING_PROCESSED_OID_CNT 가비지 콜렉터(garbage collector 혹은 ager)가 하나의 가비지 콜렉션(garbage collection 혹은 aging) OID 리스트에 존재하는 구버전 레코드 10 건을 지울 경우, GC_OID_CNT 는 리스트 단위로 계산하기 때문에 1 증가한다. 이해 반해 AGING_PROCESSED_OID_CNT 는 OID 단위로 계산하기 때문에 10 증가한다. THREAD_COUNT 공간 회수(garbage collection, aging) 쓰레드 개수를 나타낸다. 데이터 딕셔너리 155 V$MEMSTAT 알티베이스 프로세스가 사용하는 메모리의 통계 정보를 보여준다. Column name Type Description NAME VARCHAR(40) 메모리 모듈 이름 ALLOC_SIZE BIGINT 해당 모듈의 메모리 사용량 ALLOC_COUNT BIGINT 해당 모듈에서 ALLOC_SIZE를 구성 하는 단위 메모리의 개수 MAX_TOTAL_SIZE BIGINT 해당 모듈이 보유했던 최대 메모리 크 기 칼럼 정보 NAME 알티베이스가 사용하는 모듈 이름을 나타낸다. ALLOC_SIZE 해당 모듈에서 사용하고 있는 메모리 사용량을 나타낸다. ALLOC_COUNT 해당 모듈에서 ALLOC_SIZE 를 구성하는 단위 메모리의 개수를 나타낸다. MAX_TOTAL_SIZE 해당 모듈이 보유했던 최대 메모리 크기를 나타낸다. 156 ALTIBASE5 Administrator’s Manual V$MEMTBL_INFO 메모리 테이블의 상태를 보여준다. Column name Type Description TABLESPACE_ID SMALLINT 테이블스페이스 아이디 TABLE_OID BIGINT 테이블 헤더의 OID MEM_PAGE_CNT BIGINT 테이블에서 사용하는 고정(fixed) 페이 지 개수 MEM_VAR_PAGE_CNT BIGINT 테이블에서 사용하는 가변(variable) 페이지 개수 MEM_SLOT_PERPAGE INTEGER 하나의 고정 페이지에 들어갈수 있는 슬롯(slot) 개수 MEM_SLOT_SIZE BIGINT 테이블의 레코드의 고정 영역의 크기. FIXED_ALLOC_MEM DOUBLE 테이블에서 할당한 고정 영역 메모리 크기(단위: 바이트). FIXED_USED_MEM BIGINT 테이블에서 실제 사용하고 있는 고정 영역 메모리 크기(단위: 바이트) VAR_ALLOC_MEM DOUBLE 테이블에서 할당한 가변 영역 메모리 크기(단위: 바이트) VAR_USED_MEM BIGINT 테이블에서 실제 사용하고 있는 가변 영역 메모리 크기(단위: 바이트) MEM_FIRST_PAGEID BIGINT 테이블의 고정 페이지 중 제일 앞에 있 는 페이지 번호 STATEMENT_REBUILD_C OUNT BIGINT 문장(statement)를 재구성(rebuild)한 횟수 UNIQUE_VIOLATION_CO UNT BIGINT 유일 키 제약조건이 위반된 횟수 UPDATE_RETRY_COUNT BIGINT 갱신 시 재시도 횟수 DELETE_RETRY_COUNT BIGINT 삭제 시 재시도 횟수 테이블 이름을 포함하여 보려면 다음과 같이 메타 테이블과 조인하여 질의를 하여야 한다. SELECT A.TABLE_NAME, B.MEM_PAGE_CNT, B.MEM_SLOT_SIZE, B .MEM_ F IRST_ P AG EID FROM SYSTEM_.SYS_TABLES_ A, V$MEMTBL_INFO B WHERE A.TABLE_OID = B.TABLE_OID; 칼럼 정보 STATEMENT_REBUILD_COUNT 데이터 딕셔너리 157 Prepare-Execute 할 때 한번 Prepare 된 문장은 구문분석(Parsing), 유효성 검사(Validation), 최적화(Optimizing)이 생략되고 수행된다. 그런데 실행 시 질의 대상 객체(테이블스페이스, 테이블, 색인 등)에 대해 DDL 이 수행될 경우 문장이 재구성(rebuild)되며, 그 때마다 이 값은 증가된다. UNIQUE_VIOLATION_COUNT 유일 키 제약조건이 위반될 때, 이 값이 증가된다. UPDATE_RETRY_COUNT 갱신이 재시도될 때 이 값이 증가된다. DELETE_RETRY_COUNT 삭제가 재시도될 때 이 값이 증가된다 158 ALTIBASE5 Administrator’s Manual V$MEM_BTREE_HEADER 메모리 BTREE 의 헤더 정보를 보여준다. Column name Type Description INDEX_NAME CHAR(40) 인덱스 이름 INDEX_ID INTEGER 인덱스 아이디 INDEX_TBS_ID INTEGER 인덱스가 저장되어 있는 테이블스페이스 TABLE_TBS_ID INTEGER 테이블이 저장되어 있는 테이블스페이스 IS_UNIQUE CHAR(1) 유일 키 인덱스 여부 IS_NOT_NULL CHAR(1) 널(NULL) 포함 여부 USED_NODE_COUNT INTEGER 인덱스가 사용중인 노드의 개수 PREPARE_NODE_COUNT INTEGER 노드 요구를 대비하여 미리 할당된 노드 개수 BUILT_TYPE CHAR(1) 인덱스 생성시 사용된 키 타입 칼럼 정보 INDEX_NAME 인덱스의 이름을 나타낸다. INDEX_ID 해당 인덱스가 갖는 시스템 내에서 고유한 아이디를 나타낸다. INDEX_TBS_ID 인덱스가 저장되어 있는 테이블스페이스 아이디를 나타낸다. TABLE_TBS_ID 해당 인덱스와 연결되어 있는 테이블의 테이블스페이스 아이디를 나타낸다. IS_UNIQUE 유일 키 인덱스 여부를 나타낸다. 유일 키 인덱스는 ‘T’를 갖고, 중복키 인덱스의 경우는 ‘F’를 갖는다. IS_NOT_NULL 널(NULL)의 포함 여부를 나타낸다. 주 키(primary key) 인덱스의 경우는 ‘F’를 갖고, 나머지 인덱스는 ‘T’를 갖는다. USED_NODE_COUNT 현재 인덱스에 달려있는 노드의 총 개수를 의미한다. 해당 개수는 노드 분할시에 증가되고, 노드 삭제시에 감소된다. 데이터 딕셔너리 159 PREPARE_NODE_COUNT 노드 할당에 따른 시스템 부하를 고려하여 미리 할당받은 노드의 개수를 의미한다. BUILT_TYPE 인덱스 생성 시 키 값과 레코드의 포인터를 사용했는지 나타낸다. 키 값으로 생성되었을 경우 ‘V’를 갖고, 레코드 포인터로 생성되었을 경우 ‘P’를 갖는다. 160 ALTIBASE5 Administrator’s Manual V$MEM_BTREE_NODEPOOL 메모리 BTREE 인덱스를 위한 노드 풀 정보를 보여준다. 해당 노드 풀은 모든 메모리 BTREE 인덱스의 노드 할당과 반환을 관리한다. Column name Type Description TOTAL_PAGE_COUNT INTEGER 노드 풀의 전체 페이지 수 TOTAL_NODE_COUNT INTEGER 노드 풀의 전체 노드 수 FREE_NODE_COUNT INTEGER 할당되지 않은 노드 풀의 노드 수 USED_NODE_COUNT INTEGER 인덱스로 할당된 노드 수 NODE_SIZE INTEGER 노드의 크기 (바이트) TOTAL_ALLOC_REQ BIGINT 노드 풀에 요청된 노드 할당 횟수(누적 값) TOTAL_FREE_REQ BIGINT 노드 풀에 요청된 노드 삭제 횟수(누적 값) FREE_REQ_COUNT INTEGER 노드 풀에서 삭제 대기중인 노드 수 칼럼 정보 TOTAL_PAGE_COUNT 인덱스의 노드 풀에 할당된 페이지의 수를 나타낸다. TOTAL_NODE_COUNT 인덱스의 노드 풀에 할당된 노드의 수를 나타낸다. TOTAL_PAGE_COUNT 와 NODE_SIZE 에 의해 결정된다. FREE_NODE_COUNT 인덱스에 할당되지 않고 노드 풀에 남아 있는 노드 수를 나타낸다. USED_NODE_COUNT 현재 각 인덱스에 할당된 노드의 총 수를 나타낸다. NODE_SIZE 하나의 인덱스 노드 크기를 나타낸다. TOTAL_ALLOC_REQ 노드 풀에 요청된 노드 할당 횟수를 나타낸다. 시스템이 시작된 후부터 누적된 값을 유지한다. TOTAL_FREE_REQ 인덱스에서 사용되었던 노드가 삭제되어 노드 풀에 반환 요청된 횟수를 나타낸다. 시스템이 시작된 후부터 누적된 값을 유지한다. 데이터 딕셔너리 161 FREE_REQ_COUNT 인덱스에서 사용되었던 노드가 삭제 대기중인 노드 수를 나타낸다. 162 ALTIBASE5 Administrator’s Manual V$MEM_RTREE_HEADER 메모리 RTREE 인덱스의 헤더 정보를 보여준다. Column name Type Description INDEX_NAME CHAR(40) 인덱스 이름 INDEX_ID INTEGER 인덱스 아이디 TABLE_TBS_ID INTEGER 테이블이 저장되어 있는 테이블스페이스 TREE_MBR_MIN_X DOUBLE RTREE 인덱스의 최소 X 값 TREE_MBR_MIN_Y DOUBLE RTREE 인덱스의 최소 Y 값 TREE_MBR_MAX_X DOUBLE RTREE 인덱스의 최대 X 값 TREE_MBR_MAX_Y DOUBLE RTREE 인덱스의 최대 Y 값 USED_NODE_COUNT INTEGER 인덱스가 사용 중인 노드의 개수 PREPARE_NODE_COUNT INTEGER 노드 요구를 대비하여 미리 할당된 노드 개수 칼럼 정보 INDEX_NAME 인덱스의 이름을 나타낸다. INDEX_ID 해당 인덱스가 갖는 시스템 내에서 고유한 아이디를 나타낸다. TABLE_TBS_ID 해당 인덱스와 연결되어 있는 테이블의 테이블스페이스 아이디를 나타낸다. TREE_MBR_MIN_X 해당 RTREE 인덱스의 최소 경계 사각형들 중 최소 X 값을 나타낸다. TREE_MBR_MIN_Y 해당 RTREE 인덱스의 최소 경계 사각형들 중 최소 Y 값을 나타낸다. TREE_MBR_MAX_X 해당 RTREE 인덱스의 최소 경계 사각형들 중 최대 X 값을 나타낸다. TREE_MBR_MAX_Y 해당 RTREE 인덱스의 최소 경계 사각형들 중 최대 Y 값을 데이터 딕셔너리 163 나타낸다. USED_NODE_COUNT 현재 인덱스에 달려있는 노드의 총 개수를 의미한다. 해당 개수는 노드 분할시에 증가되고, 노드 삭제 시에 감소된다. PREPARE_NODE_COUNT 노드 할당에 따른 시스템 부하를 고려하여 미리 할당받은 노드의 개수를 의미한다. 164 ALTIBASE5 Administrator’s Manual V$MEM_RTREE_NODEPOOL 메모리 RTREE 인덱스를 위한 노드 풀 정보를 보여준다. 해당 노드 풀은 모든 메모리 RTREE 인덱스의 노드 할당과 반환을 관리한다. Column name Type Description TOTAL_PAGE_COUNT INTEGER 노드 풀의 전체 페이지 수 TOTAL_NODE_COUNT INTEGER 노드 풀의 전체 노드 수 FREE_NODE_COUNT INTEGER 할당되지 않은 노드 풀의 노드 수 USED_NODE_COUNT INTEGER 인덱스로 할당된 노드 수 NODE_SIZE INTEGER 노드의 크기 (바이트) TOTAL_ALLOC_REQ BIGINT 노드 풀에 요청된 노드 할당 횟수(누 적값) TOTAL_FREE_REQ BIGINT 노드 풀에 요청된 노드 삭제 횟수(누 적값) FREE_REQ_COUNT INTEGER 노드 풀에서 삭제 대기중인 노드 수 칼럼 정보 TOTAL_PAGE_COUNT 인덱스의 노드 풀에 할당된 페이지의 수를 나타낸다. TOTAL_NODE_COUNT 인덱스의 노드 풀에 할당된 노드의 수를 나타낸다. TOTAL_PAGE_COUNT 와 NODE_SIZE 에 의해 결정된다. FREE_NODE_COUNT 인덱스에 할당되지 않고 노드 풀에 남아 있는 노드 수를 나타낸다. USED_NODE_COUNT 현재 각 인덱스에 할당된 노드의 총 수를 나타낸다. NODE_SIZE 하나의 인덱스 노드 크기를 나타낸다. TOTAL_ALLOC_REQ 노드 풀에 요청된 노드 할당 횟수를 나타낸다. 시스템이 시작된 후부터 누적된 값을 유지한다. TOTAL_FREE_REQ 인덱스에서 사용되었던 노드가 삭제되어 노드 풀에 반환 요청된 횟수를 나타낸다. 시스템이 시작된 후부터 누적된 값을 유지한다. 데이터 딕셔너리 165 FREE_REQ_COUNT 인덱스에서 사용되었던 노드가 삭제 대기중인 노드 수를 나타낸다. 166 ALTIBASE5 Administrator’s Manual V$MEM_TABLESPACES 메모리에 생성된 테이블스페이스 정보를 보여준다. Column name Type Description SPACE_ID INTEGER 테이블스페이스 식별자 SPACE_NAME VARCHAR(51 2) 테이블스페이스 이름 SPACE_STATUS INTEGER 테이블스페이스 상태 SPACE_SHM_KEY INTEGER 테이블스페이스의 공유 메모리 키 AUTOEXTEND_MODE INTEGER 테이블스페이스의 자동 확장 모드 AUTOEXTEND_NEXT_SIZ E BIGINT 자동 확장시 확장되는 크기(Byte) MAXSIZE BIGINT 테이블스페이스의 최대 크기(Byte) CURRENT_SIZE BIGINT 테이블스페이스의 현재 크기(Byte) DBFILE_SIZE DOUBLE 데이터베이스 이미지 파일의 크기(Byt e) DBFILE_COUNT_0 INTEGER 데이터베이스 이미지 파일의 개수 DBFILE_COUNT_1 INTEGER 데이터베이스 이미지 파일의 개수 TIMESTAMP VARCHAR(6 4) 테이블스페이스 생성 시각 ALLOC_PAGE_COUNT BIGINT 테이블스페이스의 전체 페이지 개수 FREE_PAGE_COUNT BIGINT 테이블스페이스의 프리(Free) 페이지 개수 RESTORE_TYPE BIGINT 메모리에 테이블스페이스를 올리는 방 법 CURRENT_DB INTEGER 핑퐁 체크포인트 대상 파일 집합. HIGH_LIMIT_PAGE BIGINT 테이블스페이스가 가질 수 있는 최대 페이지 개수 PAGE_COUNT_PER_FILE BIGINT 데이터베이스 이미지 파일당 페이지 개 수 PAGE_COUNT_IN_DIS K INTEGER 디스크에 존재하는 페이지의 개수 칼럼 정보 SPACE_STATUS 테이블스페이스 상태 값으로, 자세한 내용은 V$MEM_TABLESPACE_STATUS_DESC 를 참고한다. SPACE_SHM_KEY 데이터 딕셔너리 167 테이블스페이스가 공유 메모리에 적재되었을 때 사용되는 공유 메모리 키를 나타낸다. AUTOEXTEND_MODE 자동확장(Autoextend) 모드를 나타낸다. 1 이면 자동확장으로 설정된 상태이며 1 이 아니면 설정되지 않은 상태이다. AUTOEXTEND_NEXTSIZE 자동 확장시 확장되는 크기(Byte)이다. MAXSIZE 테이블스페이스의 최대 크기이다. CURRENT_SIZE 현재 테이블스페이스 크기를 나타낸다. DBFILE_SIZE 테이블스페이스의 데이터베이스 이미지 파일의 크기를 나타낸다. DBFILE_COUNT_0 알티베이스는 핑퐁 체크포인트 방식이기 때문에 두 벌의 데이터베이스 이미지 파일(database Image file)을 유지하는데, 이 중, 0 번 파일 그룹의 파일 개수이다. DBFILE_COUNT_1 1 번 파일 그룹의 파일 개수를 나타낸다. TIMESTAMP 테이블스페이스 생성 시점의 타임스탬프 값을 가진다. ALLOC_PAGE_COUNT 테이블스페이스가 가지고 있는 페이지의 개수를 나타낸다. FREE_PAGE_COUNT 테이블스페이스의 빈(free) 페이지 개수를 나타낸다. RESTORE_TYPE 테이블스페이스를 메모리에 올리는 방법으로 다음 값을 갖는다. 적재 방법 값설명 RESTORE_TYPE_DYNAMIC 0 동적 메모리에 올린다. RESTORE_TYPE_SHM_CREATE 1 공유 메모리를 생성해서 테이블스페이스를 공유 메모리에 올린다. 168 ALTIBASE5 Administrator’s Manual RESTORE_TYPE_SHM_ATTACH 2 테이블스페이스를 공유 메모리에 Attach하는 방 식. 이미 데이타베이스가 공유 메모리에 올라와 있 는 상태에서 공유 메모리 를 프로세스에 Attach한 다. CURRENT_DB 체크포인트 시 변경된 페이지(Dirty-Page)가 내려가는 데이터베이스 이미지 파일 그룹으로 0 혹은 1 값을 가진다. HIGH_LIMIT_PAGE 테이블스페이스가 가질 수 있는 최대 페이지 개수를 나타낸다. PAGE_COUNT_PER_FILE 데이터베이스 이미지 파일 당 페이지의 개수를 나타낸다. PAGE_COUNT_IN_DISK 디스크에 존재하는 데이터베이스 이미지 파일의 전체 페이지의 개수. 알티베이스는 데이터베이스 확장 시 디스크에서 파일이 바로 확장되는 것이 아니라 체크포인트 시에 확장되기 때문에 메모리에 존재하는 데이터베이스 페이지 개수와 디스크에 존재하는 페이지 개수가 다르다. 데이터 딕셔너리 169 V$MEM_TABLESPACE_CHECKPOINT_PATHS 특정 테이블스페이스에 대해서 체크포인트 발생 시 변경된 페이지(Dirty Page)가 반영되는 데이터베이스 이미지 파일의 위치 즉 디렉토리 경로를 보여준다. Column name Type Description SPACE_ID INTEGER 테이블스페이스 식별자 CHECKPOINT_PATH VARCHAR(512)데이터베이스 이미지 파일들이 위치 한 디렉토리 경로 170 ALTIBASE5 Administrator’s Manual V$MEM_TABLESPACE_STATUS_DESC 메모리 테이블스페이스의 상태를 나타낼 수 있는 상태 값의 내용을 보여준다. 이 값은 V$MEM_TABLESPACES 에서 SPACE_STATUS 가 가질 수 있는 값이다. Column name Type Description STATUS INTEGER 메모리 테이블스페이스의 상태 값 STATUS_DESC VARCHAR(64) 상태 값에 대한 설명 칼럼 정보 STATUS 메모리 테이블스페이스의 상태 값을 나타낸다. STATUS_DESC 메모리 테이블스페이스의 상태 값에 대한 설명을 나타낸다. 메모리 테이블스페이스의 상태 값과 설명은 다음과 같다. STATUS_DESC Description OFFLINE 테이블스페이스가 오프라인 상태이다. ONLINE 테이블스페이스가 온라인 상태이다. DISCARDED 테이블스페이스가 폐기(DISCARD)되었다. DROPPED 테이블스페이스가 삭제되었다. BACKUP 테이블스페이스가 백업 중이다. CREATING 테이블스페이스가 생성 중이다. DROPPING 테이블스페이스가 삭제 중이다. DROP_PENDING 테이블스페이스에 대해서 지연된 삭제(Dro p Pending) 연산을 수행 중이다. SWITCHING_TO_O FFLINE 테이블스페이스가 오프라인 상태로 바뀌고 있다. SWITCHING_TO_O NLINE 테이블스페이스가 온라인 상태로 바뀌고 있다. BLOCK_BACKUP 테이블스페이스에 대해서 백업할 수 없다. 현재 다른 연산을 수행하는 중이므로 백업 은 이 연산이 완료될 때까지 대기해야 한 다. 데이터 딕셔너리 171 V$MUTEX 알티베이스 프로세스에서 사용되고 있는 동시성 제어와 관련 뮤텍스 통계 정보를 보여준다. Column name Type Description NAME VARCHAR(64) 뮤텍스 이름 TRY_COUNT INTEGER 잠금(Lock) 시도 횟수 LOCK_COUNT INTEGER 잠금 성공 횟수 MISS_COUNT INTEGER 잠금을 잡지 못하여 대기한 횟수 SPIN_VALUE INTEGER 향후 확장 예정 TOTAL_LOCK_TIME_US BIGINT 잠금을 잡은 시간의 총합(us) MAX_LOCK_TIME_US BIGINT 잠금을 잡은 시간 중 최대 시간(us) 172 ALTIBASE5 Administrator’s Manual V$NLS_PARAMETERS 서버 및 클라이언트의 NLS(National Language Support) 관련 정보 를 세션 단위로 보여준다. Column name Type Description SESSION_ID INTEGER 세션 식별자 NLS_USE VARCHAR(40) 클라이언트의 문자 집합 NLS_CHARACTERSET VARCHAR(40) 데이터베이스 문자 집합 NLS_NCHAR_CHARACTERSET VARCHAR(40) 국가 문자 집합 NLS_COMP VARCHAR(7) 문자 비교 방법 NLS_NCHAR_CONV_EXCP VARCHAR(7) 문자 집합 변환시 에러 처리 NLS_NCHAR_LITERAL_REPLACE VARCHAR(7) 국가 문자 집합 검사 여부 칼럼 정보 SESSION_ID 실행 계획이 속한 세션의 고유 번호를 나타낸다. NLS_USE 클라이언트의 문자 집합(Character set)을 나타낸다. 클라이언트에서 문자 데이터를 처리할 때 기본 문자 집합을 지정한다. 현재 알티베이스에서 지원하는 문자 집합과 그에 해당하는 NLS_USE 설정은 아래와 같다. 언어 문자 집합 NLS_USE 영어 (기본값) US7ASCII US7ASCII, ASCII, ENGLISH 한글 KSC-5601 완성형 KSC5601, KO16KSC5601, KO R E A N MS 확장 완성형 MS949, CP949, WINDOWS949 일어 EUC-JP(UNIX) EUC-JP Shift-JIS(Windows) SHIFTJIS 중국어 중국 GB231280, ZHS16CGB231280, CHINESE 대만 BIG5, ZHT16BIG5, TAIWAN 공통 유니코드(UTF-8) UTF8, UNICODE 데이터 딕셔너리 173 데이터베이스 생성시에 지정된 데이터베이스 문자 집합과 다른 문자 집합으로 지정된 데이터를 저장할 경우, 문자 집합 간의 변환 및 호환성을 고려해야 한다. 다국어 지원에 대한 보다 자세한 내용은 Starting User’s Manual을 참조한다. NLS_CHARACTERSET 서버의 데이터베이스 문자 집합(database character set)을 나타낸다. NLS_NCHAR_CHARACTERSET 국가 문자 집합(national character set)을 나타낸다. NLS_COMP 데이터베이스 생성시 지정한 문자 집합을 해당 언어의 사전 순서대로 비교하는 것을 나타낸다. 현재는 한글(KSC-5601 완성형 또는 MS 확장 완성형)로 설정된 경우에만 지원한다. NLS_NCHAR_CONV_EXCP 문자 집합 변환시 오류 처리를 보여준다. NLS_NCHAR_LITERAL_REPLACE 국가 문자 집합에 대한 검사 여부를 나타낸다. TURE 일 경우에는 국가 문자 집합을 사용하는지를 매번 검사하고, FALSE 일 경우에는 검사하지 않는다. 174 ALTIBASE5 Administrator’s Manual V$PLANTEXT 시스템에서 수행되는 SQL 의 실행계획(plan) 정보를 나타낸다. Column name Type Description SID INTEGER 세션 식별자 STMT_ID INTEGER 문장(statement) 식별자 PIECE INTEGER 실행계획 문자열 조각(plan text piece) 의 일련 번호 TEXT VARCHAR(64) 실행계획 문자열 칼럼 정보 SID 실행계획이 속한 세션의 고유 번호를 나타낸다. STMT_ID 실행계획이 속한 문장의 문장 식별자를 나타낸다. PIECE 한 문장에 대한 전체 실행계획을 64 바이트 문자열로 나누어 저장한다. PIECE 는 나뉘어진 64 바이트 문자열의 일련 번호로 0 부터 시작된다. TEXT 64 바이트 문자열에 저장되는 실행계획 구문을 나타낸다. 데이터 딕셔너리 175 V$PROCTEXT 시스템에서 수행되는 저장 프로시저(PSM)의 문자열 정보를 나타낸다. Column name Type Description PROC_OID BIGINT 저장 프로시저의 OID PIECE INTEGER 문자열 조각의 일련 번호 TEXT VARCHAR(64) SQL 구문의 문자열 칼럼 정보 PROC_OID PSM 프로시져를 유일하게 가리키는 객체 식별자 즉 OID 이다. PIECE 저장 프로시저의 전체 구문을 64 바이트 문자열로 나누어 저장한다. PIECE 는 나뉘어진 64 바이트 문자열의 일련 번호로 0 부터 시작된다. TEXT 실제 저장 프로시저를 표현하는 SQL 구문의 64 바이트 문자열을 나타낸다. 176 ALTIBASE5 Administrator’s Manual 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 실제 저장된 프로퍼티의 값을 나타낸다. 데이터 딕셔너리 177 V$REPEXEC 이중화 관리자 정보를 보여준다. Column name Type Description PORT INTEGER 사용중인 포트 번호 MAX_SENDER_COUNT INTEGER 최대 송신자 개수 MAX_RECEIVER_COUNT INTEGER 최대 수신자 개수 칼럼 정보 PORT 지역서버의 이중화 관리자가 원격 서버의 이중화 요청을 받아들이는 포트번호 이다. MAX_SENDER_COUNT 지역서버에서 생성 가능한 이중화 송신 쓰레드의 최대 개수이다. MAX_RECEIVER_COUNT 지역서버에서 생성 가능한 이중화 수신 쓰레드의 최대 개수이다. 178 ALTIBASE5 Administrator’s Manual V$REPGAP 이중화 송신자의 작업 로그 파일이 현재 생성된 최근 로그 파일간의 차이를 보여준다. 단, 이중화 송신 쓰레드가 동작 중일때만 정보를 보여준다. Column name Type Description REP_NAME VARCHAR(40) 이중화 객체의 이름 START_FLAG BIGINT 시작 플래그 REP_LAST_SN BIGINT 마지막 로그 일련번호 REP_SN BIGINT 전송 로그의 일련번호 REP_GAP BIGINT REP_LAST_SN과 REP_SN의 간격 READ_LFG_ID INTEGER 현재 읽고 있는 로그 파일 그룹 READ_FILE_NO INTEGER 현재 읽고 있는 로그 파일 번호 READ_OFFSET INTEGER 현재 읽고 있는 위치 칼럼 정보 REP_NAME 지역서버에 생성된 이중화 객체의 이름이다. START_FLAG 지역서버의 이중화 구동시에 명시한 구동 옵션으로, NORMAL, QUICK, SYNC, SYNC ONLY 등의 옵션을 나타낸다. NORMAL: 0 QUICK: 1 SYNC: 2 SYNC_ONLY: 3 SYNC RUN : 4 SYNC END : 5 RECOVERY from Replication : 6 OFFLINE : 7 REP_LAST_SN 지역서버의 트랜잭션에 의해 가장 최근에 로깅된 로그 레코드의 일련 번호(sequence number, SN)이다. REP_SN 데이터 딕셔너리 179 지역서버의 이중화 송신 쓰레드가 송신한 로그 레코드의 일련 번호이다. REP_GAP REP_LAST_SN 과 REP_SN 간의 로그 일련번호의 간격을 나타낸다. 즉 지역서버 트랜잭션에 의해 가장 최근에 로깅된 로그 레코드와 이중화 송신 쓰레드가 송신한 로그 레코드의 간격이다. READ_LFG_ID 송신하기 위해 현재 읽고 있는 로그 파일 그룹을 나타낸다. READ_FILE_NO 현재 읽고 있는 로그 파일 번호이다. READ_OFFSET 로그 파일 내에서 현재 읽고 있는 위치를 나타낸다. 180 ALTIBASE5 Administrator’s Manual V$REPLOGBUFFER 이중화 송신 쓰레드가 동작 중일 때 이중화 송신자 전용 로그 버퍼의 상태 정보를 보여준다. Column name Type Description REP_NAME VARCHAR(40) 이중화 객체의 이름 BUFFER_MIN_SN BIGINT 전용 로그 버퍼의 최소 로그 일련 번호 READ_SN BIGINT 이중화 송신 쓰레드가 읽어야 할 로그 SN BUFFER_MAX_SN BIGINT 전용 로그 버퍼의 최대 로그 일련 번호 칼럼 정보 REP_NAME 지역서버에 생성된 이중화 객체의 이름이다. BUFFER_MIN_SN 이중화 전용 로그 버퍼의 저장된 로그 레코드의 일련번호(sequence number, SN)중 최소값이다. READ_SN 이중화 전용 로그 버퍼 내에 현재 이중화 송신 쓰레드가 읽어야 할 로그 레코드의 일련번호(sequence number, SN)이다. BUFFRT_MAX_SN 이중화 전용 로그 버퍼의 저장된 로그 레코드의 일련번호(sequence number, SN)중 최대값이다. 데이터 딕셔너리 181 V$REPOFFLINE_STATUS 오프라인 이중화의 수행 상태를 표시한다. Column name Type Description REP_NAME VARCHAR(40) 이중화 객체의 이름 STATUS BIGINT 오프라인 이중화의 수행 상태 SUCCESS_TIME INTEGER 오프라인 이중화가 성공적으로 수행된 시점의 시간 칼럼 정보 REP_NAME 지역 서버에 생성된 이중화 객체의 이름이다. STATUS 오프라인 이중화의 수행 상태 0 시작되지 않았음 1 시작됨 2 종료 3 실패 SUCCESS_TIME 오프라인 이중화가 성공적으로 수행된 시점의 시간을 표시하는 것으로, 이중화가 성공적으로 시작되어 종료되었을 경우 종료된 시간이 설정되고 그 외는 0 으로 설정된다. 182 ALTIBASE5 Administrator’s Manual V$REPRECEIVER 리플리케이션 수신자의 정보를 보여준다. Column name Type Description REP_NAME VARCHAR(40) 이중화 객체의 이름 MY_IP VARCHAR(64) 지역서버의 IP 주소 MY_PORT INTEGER 지역서버의 포트 번호 PEER_IP VARCHAR(64) 원격 IP 주소 PEER_PORT INTEGER 원격 포트 번호 APPLY_XSN BIGINT 처리중인 XSN INSERT_SUCCESS_COUN T BIGINT 지역 서버에서 수신 쓰레드가 적용에 성공한 INSERT 로그레코드의 수 INSERT_FAILURE_COUN T BIGINT 지역 서버에서 수신 쓰레드가 적용에 실패한 INSERT 로그레코드의 수 UPDATE _SUCCESS_COU NT BIGINT 지역 서버에서 수신 쓰레드가 적용에 성공한 UPDATE 로그레코드의 수 UPDATE_FAILURE_COU NT BIGINT 지역 서버에서 수신 쓰레드가 적용에 실패한 UPDATE 로그레코드의 수 DELETE_SUCCESS_COU NT BIGINT 지역 서버에서 수신 쓰레드가 적용에 성공한 DELETE 로그레코드의 수 DELETE_FAILURE_COUN T BIGINT 지역 서버에서 수신 쓰레드가 적용에 실패한 DELETE 로그레코드의 수 칼럼 정보 REP_NAME 지역서버에 생성된 이중화 객체의 이름이다. MY_IP 지역서버의 IP 주소값이다. MY_PORT 지역서버의 수신 쓰레드가 사용하는 포트번호이다. PEER_IP 원격서버의 IP 주소값이다. PEER_PORT 원격서버의 송신 쓰레드가 사용하는 포트번호이다. APPLY_XSN 데이터 딕셔너리 183 원격서버에서 송신 쓰레드가 전송하여 지역서버에서 수신 쓰레드가 적용 중인 로그레코드의 SN 을 나타낸다. INSERT_SUCCESS_COUNT 지역서버에서 수신 쓰레드가 적용에 성공한 INSERT 로그레코드의 수를 나타낸다. COMMIT/ROLLBACK 과 무관하게 계산된다. 즉 ROLLBACK 을 수행해도 COUNT 가 줄어들지 않는다. INSERT_FAILURE_COUNT 지역서버에서 수신 쓰레드가 적용에 실패한 INSERT 로그레코드의 수를 나타낸다. (Conflict 를 포함) COMMIT/ROLLBACK 과 무관하게 계산된다. 즉 ROLLBACK 을 수행해도 COUNT 가 줄어들지 않는다. UPDATE_SUCCESS_COUNT 지역서버에서 수신 쓰레드가 적용에 성공한 UPDATE 로그레코드의 수를 나타낸다. COMMIT/ROLLBACK 과 무관하게 계산된다. 즉 ROLLBACK 을 수행해도 COUNT 가 줄어들지 않는다. UPDATE_FAILURE_COUNT 지역서버에서 수신 쓰레드가 적용에 실패한 UPDATE 로그레코드의 수를 나타낸다. (Conflict 를 포함) COMMIT/ROLLBACK 과 무관하게 계산된다. 즉 ROLLBACK 을 수행해도 COUNT 가 줄어들지 않는다. DELETE_SUCCESS_COUNT 지역서버에서 수신 쓰레드가 적용에 성공한 DELETE 로그레코드의 수를 나타낸다. COMMIT/ROLLBACK 과 무관하게 계산된다. 즉 ROLLBACK 을 수행해도 COUNT 가 줄어들지 않는다. DELETE_FAILURE_COUNT 지역서버에서 수신 쓰레드가 적용에 실패한 DELETE 로그레코드의 수를 나타낸다. (Conflict 를 포함) COMMIT/ROLLBACK 과 무관하게 계산된다. 즉 ROLLBACK 을 수행해도 COUNT 가 줄어들지 않는다. 184 ALTIBASE5 Administrator’s Manual V$REPRECEIVER_COLUMN 리플리케이션 수신자의 리플리케이션 대상 칼럼 정보를 보여준다. Column name Type Description REP_NAME VARCHAR(40) 이중화 이름 USER_NAME VARCHAR(40) 사용자 이름 TABLE_NAME VARCHAR(40) 테이블 이름 PARTITION_NAME VARCHAR(40) 파티션 이름 COLUMN_NAME VARCHAR(40) 칼럼 이름 칼럼 정보 REP_NAME 지역 서버에 생성된 이중화 객체의 이름이다. USER_NAME 지역 서버의 이중화 대상인 테이블 소유자의 사용자 이름이다. SYS_USERS_ 메타 테이블의 USER_NAME 값과 동일하다. TABLE_NAME 지역 서버의 이중화 대상 테이블의 이름으로 SYS_TABLES_ 메타 테이블의 TABLE_NAME 값과 동일하다. PARTITION_NAME 지역 서버의 이중화 대상 파티션 이름이다. COLUMN_NAME 지역 서버의 이중화 대상 칼럼 이름이다. 데이터 딕셔너리 185 V$REPRECEIVER_TRANSTBL 리플리케이션 수신자의 트랜잭션 테이블의 정보를 보여준다. Column name Type Description REP_NAME VARCHAR(40) 이름 LOCAL_TID INTEGER 지역 트랜잭션 ID REMOTE_TID INTEGER 원격 트랜잭션 ID BEGIN_FLAG INTEGER 현재 사용하지 않음 BEGIN_SN BIGINT 트랜잭션의 최초 로그 SN 칼럼 정보 REP_NAME 지역서버에 생성된 이중화 객체의 이름이다. LOCAL_TID 지역서버에서 실행되는 트랜잭션의 ID 이다. REMOTE_TID 원격서버에서 실행되는 트랜잭션의 ID 이다. 186 ALTIBASE5 Administrator’s Manual V$REPRECOVERY 리플리케이션을 이용한 복구 정보를 보여준다. Column name Type Description REP_NAME VARCHAR(40) 이중화 객체 이름 STATUS INTEGER 복구에 대한 현재 상태 1: 복구 정보 생성 중 2: 복구 요청 대기 중 3: 복구 진행 중 START_XSN BIGINT 복구를 위한 전송시작 SN XSN BIGINT 복구를 위해 현재 전송중인 로그 SN END_XSN BIGINT 복구를 위한 마지막 전송 SN RECOVERY_SENDER_IP VARCHAR(64) 지역 서버의 복구를 위한 송신자 IP PEER_IP VARCHAR(64) 원격 서버의 복구를 위한 수신자 IP RECOVERY_SENDER_PO RT INTEGER 지역서버의 복구를 위한 송신자 포트 번호 PEER_PORT INTEGER 원격서버의 복구를 위한 수신자 포트 번호 칼럼 정보 REP_NAME 지역 서버에 생성된 이중화 객체의 이름이다. STATUS 지역서버의 이중화 송신 쓰레드의 현재 상태를 나타낸다. 1: 복구 정보 생성 중 2: 복구 요청 대기 중 3: 복구 진행 중 START_XSN 지역 서버의 복구를 위한 송신 쓰레드가 로그 레코드를 전송하는 시작 SN 을 나타낸다. XSN 지역서버의 복구를 위한 이중화 송신 쓰레드가 송신한 로그 레코드의 SN 을 나타낸다. END_XSN 데이터 딕셔너리 187 지역 서버의 복구를 위한 송신 쓰레드가 로그 레코드를 전송하는 마지막 SN 을 나타낸다. RECOVERY_SENDER_IP 지역 서버의 복구를 위한 송신자 IP 주소이다. PEER_IP 원격 서버의 복구를 위한 IP 주소이다. RECOVERY_SENDER_PORT 지역 서버의 복구를 위한 송신 쓰레드가 사용하는 포트번호이다. PEER_PORT 원격 서버의 복구를 위한 수신 쓰레드가 사용하는 포트번호이다. 188 ALTIBASE5 Administrator’s Manual V$REPSENDER 리플리케이션 송신자의 정보를 보여준다. Column name Type Description REP_NAME VARCHAR(40) 이름 START_FLAG BIGINT 시작 플래그 NET_ERROR_FLAG BIGINT 에러 상태 플래그 XSN BIGINT 전송 Log의 SN COMMIT_XSN BIGINT Commit Log의 SN STATUS BIGINT 현재 상태 SENDER_IP VARCHAR(64) 송신자 IP PEER_IP VARCHAR(64) 원격 IP SENDER_PORT INTEGER 송신 포트 PEER_PORT INTEGER 원격 포트 READ_LOG_COUNT BIGINT 읽은 Log의 수 SEND_LOG_COUNT BIGINT 읽은 Replication Log의 수 REPL_MODE VARCHAR(7) 현재 이중화 모드 ACT_REPL_MODE VARCHAR(7) 이중화 진행이 해당 프로퍼티 수준을 초과하면 LAZY 모드로 동작 칼럼 정보 REP_NAME 지역서버에 생성된 이중화 객체의 이름이다. START_FLAG 지역서버의 이중화 구동시에 명시한 구동 옵션으로, NORMAL, QUICK, SYNC, SYNC ONLY 등의 옵션을 나타낸다. NORMAL: 0 QUICK: 1 SYNC: 2 SYNC_ONLY: 3 SYNC RUN : 4 SYNC END : 5 RECOVERY from Replication : 6 NET_ERROR_FLAG 데이터 딕셔너리 189 네트워크 오류 여부를 나타낸다. 디폴트는 0 이며 1 은 오류가 발생했음을 나타낸다. XSN 지역서버의 이중화 송신 쓰레드가 송신한 로그 레코드의 SN 을 나타낸다. COMMIT_XSN 지역서버에서 가장 최근에 COMMIT 한 트랜잭션이 로깅한 COMMIT 로그 레코드의 SN 을 나타낸다. STATUS 지역서버의 이중화 송신 쓰레드의 현재 상태(STOP(0), RUN(1), RETRY(2))를 나타낸다. SENDER_IP 지역서버의 IP 주소값이다. PEER_IP 원격서버의 IP 주소값이다. SENDER_PORT 지역서버의 이중화 송신 쓰레드가 사용하는 포트번호이다. PEER_PORT 원격서버의 이중화 수신 쓰레드가 사용하는 포트번호이다. READ_LOG_COUNT 지역서버에서 송신 쓰레드가 읽은 로그레코드의 수를 나타낸다. SEND_LOG_COUNT 지역서버에서 송신 쓰레드가 읽은 전송 대상 로그레코드의 수를 나타낸다. REPL_MODE 이중화가 설정된 모드를 나타낸다. 이중화 모드의 종류는 LAZY, ACKED, EAGER 이다. 이중화 모드에 대한 자세한 설명은 Replication User’s Manual 을 참조하기 바란다. ACT_REPL_MODE 이중화 모드가 EAGER 또는 ACKED 모드로 동작할 때, 이중화의 진행 수준이 장애 등으로 인하여 프로퍼티 REPLICATION_SERVICE_WAIT_MAX_LIMIT 의 값을 초과하면, 트랜잭션은 LAZY 모드로 동작한다. 190 ALTIBASE5 Administrator’s Manual 이 외의 경우에는 REPL_MODE 의 값과 동일하다. REPLICATION_SERVICE_WAIT_MAX_LIMIT 에 대한 자세한 설명은 Starting User’s Manual 을 참조하기 바란다. 데이터 딕셔너리 191 V$REPSENDER_TRANSTBL 리플리케이션 송신자의 트랜잭션 테이블의 정보를 보여준다. Column name Type Description REP_NAME VARCHAR(40) 이중화 이름 LOCAL_TID INTEGER 지역 트랜잭션 식별자 REMOTE_TID INTEGER 현재 사용하지 않음 BEGIN_FLAG INTEGER 트랜잭션의 BEGIN 전송 여부 BEGIN_SN BIGINT 트랜잭션의 최초 로그 SN 칼럼 정보 REP_NAME 지역서버에 생성된 이중화 객체의 이름이다. LOCAL_TID 지역서버에서 실행되는 트랜잭션의 식별자이다. REMOTE_TID 원격서버에서 실행되는 트랜잭션의 식별자이다. 192 ALTIBASE5 Administrator’s Manual V$REPSYNC SYNC 중인 테이블의 정보를 보여준다. Column name Type Description REP_NAME VARCHAR(40) 이름 SYNC_TABLE VARCHAR(40) SYNC 대상 테이블 이름 SYNC_PARTITION VARCHAR(40) SYNC 대상 파티션 이름 SYNC_RECORD_COUNT BIGINT 원격 서버에 SYNC된 레코드 수 SYNC_SN BIGINT 현재 사용하지 않음 칼럼 정보 REP_NAME 지역서버에 생성된 이중화 객체의 이름이다. SYNC_TABLE SYNC 대상 테이블 이름이다. SYNC_PARTITION SYNC 대상 파티션 이름이다. SYNC_RECORD_COUNT 지역 서버에서 원격 서버로 이중화 테이블들의 데이터를 SYNC 할 때, REPLICATION_SYNC_TUPLE_COUNT 에서 지정한 레코드 단위로 해당 칼럼에서 검색된다. 0 : SYNC 진행 중 -1 : SYNC 종료 시 데이터 딕셔너리 193 V$SEGMENT 디스크 테이블과 디스크 인덱스를 구성하는 세그먼트의 상태, 종류, 할당된 익스텐트의 개수를 보여준다. Column name Type Description SPACE_ID INTEGER 테이블스페이스 식별자 TABLE_OID BIGINT 테이블 헤더의 OID SEGMENT_PID INTEGER 세그먼트 페이지의 ID SEGMENT_TYPE VARCHAR(7) 세그먼트의 종류 SEGMENT_STATE VARCHAR(7) 세그먼트의 상태 EXTENT_TOTAL_COUNT BIGINT 세그먼트에 할당된 익스텐트의 총 개 수 칼럼 정보 SEGMENT_TYPE INDEX : 해당 세그먼트가 인덱스 세그먼트임을 나타낸다. TABLE : 해당 세그먼트가 테이블 세그먼트임을 나타낸다. TSSEG : 해당 세그먼트가 TSS 세그먼트임을 나타낸다. UDSEG : 해당 세그먼트가 언두 세그먼트임을 나타낸다. SEGMENT_STATE USED : 해당 세그먼트가 사용 중임을 나타낸다. FREE : 해당 세그먼트가 비어 있음을 나타낸다. EXTENT_TOTAL_COUNT 세그먼트에 할당된 총 익스텐트 개수 194 ALTIBASE5 Administrator’s Manual V$SEQ 시퀀스 관련 정보를 보여준다. Column name Type Description SEQ_OID BIGINT 시퀀스 객체 ID CURRENT_SEQ BIGINT 현재 시퀀스 값 START_SEQ BIGINT 시퀀스의 시작 값 INCREMENT_SEQ BIGINT 시퀀스의 증가 값 CACHE_SIZE BIGINT 캐쉬 크기 MAX_SEQ BIGINT 시퀀스 최대값 MIN_SEQ BIGINT 시퀀스 최소값 IS_CYCLE VARCHAR(7) 시퀀스 사이클 여부 칼럼 정보 SEQ_OID 생성하고자 하는 시퀀스 식별자를 나타낸다. SYS_TABLES_ 메타 테이블의 TABLE_OID 칼럼 값이 시퀀스를 나타내는 ‘S’인 경우 동일한 값을 갖는다. CURRENT_SEQ 현재 시퀀스의 값을 나타낸다. START_SEQ 시퀀스를 생성할 때 처음으로 부여되는 시퀀스의 값을 나타낸다. INCREMENT_SEQ 시퀀스 번호가 증가되는 값을 나타낸다. MAX_SEQ 생성이 가능한 시퀀스의 최대값을 나타낸다. MIN_SEQ 생성이 가능한 시퀀스의 최소값을 나타낸다. IS_CYCLE 해당 시퀀스가 최대값에 도달한 경우 다시 최소값으로 시퀀스를 생성할 것인지 사이클의 여부를 나타낸다. YES : 사이클은 한다. 데이터 딕셔너리 195 NO : 사이클을 하지 않는다. 만약 시퀀스가 최대값인 경우 새로운 시퀀스를 생성하면, 에러가 발생한다. 196 ALTIBASE5 Administrator’s Manual V$SERVICE_THREAD 멀티플렉싱(Multiplexing)과 관련하여 서비스 쓰레드 정보를 보여준다. Column name Type Description ID INTEGER 서비스 쓰레드 ID TYPE VARCHAR(7) 서비스 쓰레드 접속 방법 STATE VARCHAR(10) 서비스 쓰레드의 현재 상태 RUN_MODE VARCHAR(9) 서비스 쓰레드 운영 모드 SESSION_ID INTEGER 서비스 쓰레드가 수행중인 세션의 ID STATEMENT_ID INTEGER 서비스 쓰레드가 수행중인 Statement 의 ID START_TIME INTEGER 서비스 쓰레드가 생성된 시각 EXECUTE_TIME BIGINT 서비스 쓰레드가 현재 query 를 수 행하고 있는 시간 TASK_COUNT INTEGER 서비스 쓰레드에 할당된 세션의 개수 READY_TASK_COUNT INTEGER 서비스 쓰레드가 요청을 처리해 주기 를 대기하고 있는 세션의 개수 서버에서 클라이언트의 요청을 받아 질의를 수행하는 쓰레드를 서비스 쓰레드라 한다. 서버에 다수의 클라이언트가 접속하여 질의를 수행하는 경우 각 클라이언트 세션마다 하나의 서비스 쓰레드를 생성하여 질의를 수행하게 되면 성능이 저하될 수 있다. 따라서 서버에 최적화된 개수의 서비스 쓰레드만 생성하여 클라이언트 세션들의 질의를 수행하도록 해야 하는데, 이것을 서비스 쓰레드 멀티플렉싱이라고 부르기로 한다. 알티베이스는 필요에 따라 동적으로 서비스 쓰레드를 추가하거나 삭제하여 항상 최적화된 개수의 서비스 쓰레드를 유지하도록 설계되어 있다. 단, 최소 MULTIPLEXING_THREAD_COUNT 프로퍼티에서 지정한 개수만큼의 서비스 쓰레드는 유지한다. 칼럼 정보 ID 서비스 쓰레드의 식별자를 나타낸다. System thread ID (Light Weight Process ID 등과 같은)가 아니라 알티베이스 내부에서 유지하는 ID 이다. TYPE 데이터 딕셔너리 197 서비스 쓰레드 접속 방법으로 다음과 같은 값을 가진다. SOCKET : TCP, Unix Domain 방식 IPC : IPC 방식 STATE 서비스 쓰레드의 현재 상태. 다음과 같은 값을 가진다. NONE : 서비스 쓰레드가 초기화된 상태 POLL : 서비스 쓰레드가 이벤트를 기다리고 있는 상태 QUEUE-WAIT : 서비스 쓰레드가 Queue 를 대기하는 상태 EXECUTE : 서비스 쓰레드가 Statement 를 수행중인 상태 UNKNOWN : 서비스 쓰레드의 상태를 알 수 없음 RUN_MODE 서비스 쓰레드의 운영 모드를 나타내는 것으로 SHARED, DEDICATED 두 가지 모드가 있다. SHARED : 하나의 서비스 쓰레드에 다수의 데이터베이스 작업(Connection)이 할당되어 해당 서비스 쓰레드가 다수개의 데이터베이스 작업을 멀티플렉싱으로 처리한다. DEDICATED : 하나의 서비스 쓰레드에 하나의 데이터베이스 작업(Connection)이 할당되어 해당 서비스 쓰레드를 독점하여 사용한다. 현재 서비스 쓰레드의 운영 모드 전화은 큐(QUEUE) 관련 작업에만 적용되고 있으며, SHARED 모드에서 DEDICATED 모드로만 전환할 수 있다. STATEMENT_ID 서비스 쓰레드가 수행중인 SQL 의 문장의 식별자 START_TIME 서비스 쓰레드가 생성된 시각으로써, 시스템 시간이다.(단위 : 초) EXECUTE_TIME 서비스 쓰레드가 현재 수행하고 있는 질의(query)를 수행하는 시간을 나타낸다. (단위 : 마이크로초) TASK_COUNT 서비스 쓰레드에 할당된 전체 세션의 개수를 나타낸다. READY_TASK_COUNT 198 ALTIBASE5 Administrator’s Manual 서비스 쓰레드가 자신의 요청을 처리해 주기를 대기하고 있는 세션의 개수를 나타낸다. 데이터 딕셔너리 199 V$SESSION 알티베이스 내부에 생성된 클라이언트에 대한 세션 정보를 보여준다. Column name Type Description ID INTEGER 세션 아이디 TRANS_ID BIGINT 세션에서 현재 사용하는 트랜잭 션 아이디 TASK_STATE VARCHAR(11) 태스크 상태 COMM_NAME VARCHAR(40) 접속 정보 XA_SESSION_FLAG INTEGER XA 세션 플래그 XA_ASSOCIATE_FLAG INTEGER XA associate 플래그 QUERY_TIME_LIMIT INTEGER 아래 참조 FETCH_TIME_LIMIT INTEGER 아래 참조 UTRANS_TIME_LIMIT INTEGER 아래 참조 IDLE_TIME_LIMIT INTEGER 아래 참조 IDLE_START_TIME INTEGER 아래 참조 ACTIVE_FLAG INTEGER 트랜잭션 활성 플래그 OPENED_STMT_COUNT INTEGER 사용 중인 구문 개수 CLIENT_PACKAGE_VERSION VARCHAR(40) 클라이언트 패키지 버젼 CLIENT_PROTOCOL_VERSIO N VARCHAR(40) 클라이언트 프로토콜 버젼 CLIENT_PID BIGINT 클라이언트 프로세스 아이디 CLIENT_TYPE VARCHAR(40) 접속한 클라이언트의 타입 CLIENT_APP_INFO VARCHAR(128) 접속한 애플리케이션의 타입 CLIENT_NLS VARCHAR(40) 클라이언트 언어 타입 DB_USERNAME VARCHAR(40) 데이터베이스 사용자 이름 DB_USERID INTEGER 데이터베이스 사용자 식별자 DEFAULT_TBSID BIGINT 사용자의 디폴트 테이블스페이 스 식별자 DEFAULT_TEMP_TBSID BIGINT 사용자의 디폴트 임시(temp) 테 이블스페이스 식별자 SYSDBA_FLAG INTEGER Sysdba 접속 여부 AUTOCOMMIT_FLAG INTEGER Autocommit 플래그 SESSION_STATE VARCHAR(13) 세션의 상태 ISOLATION_LEVEL INTEGER 고립도 REPLICATION_MODE INTEGER 이중화 모드 TRANSACTION_MODE INTEGER 트랜잭션 모드 COMMIT_WRITE_WAIT_MOD E INTEGER 아래 참조 OPTIMIZER_MODE INTEGER 최적화 모드 HEADER_DISPLAY_MODE INTEGER 0: display table name 200 ALTIBASE5 Administrator’s Manual Column name Type Description CURRENT_STMT_ID INTEGER 사용 중인 구문 아이디 STACK_SIZE INTEGER 스택 크기 DEFAULT_DATE_FORMAT VARCHAR(64) 디폴트 날짜 형식 TRX_UPDATE_MAX_LOGSIZE BIGINT DML 로그 최대 크기 PARALLEL_DML_MODE INTEGER Paralle DML 수행 여부 LOGIN_TIME INTEGER 클라이언트 접속 시간 칼럼 정보 ID 현재 연결된 세션의 고유 아이디를 나타낸다. TRANS_ID 세션에서 현재 사용하고 있는 트랜잭션 아이디를 나타낸다. 트랜잭션을 사용하지 않으면 -1 을 나타낸다. TASK_STATE 현재 태크스의 상태를 아래와 같이 나타낸다. STATE Description WAITING 클라이언트로 부터 요청이 들어오기를 기다리 고 있는 상태 READY 클라이언트로부터 수신된 요청을 처리하기 위 한 쓰레드를 할당받기 위해 대기하는 상태 EXECUTING 쓰레드를 할당받은 후 작업을 수행중인 상태 QUEUE WAIT Dequeue를 위해 QUEUE가 입력되기를 기다 리는 상태 QUEUE READY QUEUE가 입력되고, Dequeue를 위해 쓰레 드 할당을 기다리는 상태 UNKNOWN 알 수 없는 상태 COMM_NAME 클라이언트의 접속 정보를 나타낸다. 연결할 때 쓰이는 내부 고유 스트링과 소켓의 경우 Remote IP Address 를 출력한다. XA_SESSION_FLAG 현재의 세션이 XA 세션인지 나타낸다. 0: NON-XA XA_ASSOCIATE_FLAG 데이터 딕셔너리 201 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_PACKAGE_VERSION 접속된 클라이언트의 패키지 버전이다. CLIENT_PROTOCOL _VERSION 접속된 클라이언트가 사용하는 프로토콜의 버전이다. CLIENT_PID 접속된 클라이언트의 프로세스 아이디를 나타낸다. CLIENT_TYPE 접속된 클라이언트의 타입을 표시하는 스트링이다. CLIENT_TYPE ::= app-type hypen word-size endian app-type ::= CLI | WIN_ODBC | UNIX_ODBC hypen ::= - word-size ::= 32 | 64 endian ::= BE | LE BE : Big Endian, LE : Little Endian 예) CLI-32LE UNIX_ODBC-32BE 202 ALTIBASE5 Administrator’s Manual CLIENT_APP_INFO 접속된 클라이언트의 애플리케이션 정보이다. 클라이언트 응용프로그램이 세팅하는 값이다. CLIENT_NLS 접속된 클라이언트의 언어 종류를 나타낸다. DB_USERNAME 접속된 클라이언트가 사용하는 사용자 이름을 나타낸다. DB_USERID 알티베이스가 구별하는 유저명에 대하여 숫자로 표현되는 아이디를 나타낸다. DEFAULT_TBSID 사용자의 디폴트 테이블스페이스 식별자를 나타낸다. DEFAULT_TEMP_TBSID 사용자의 디폴트 임시 테이블스페이스 식별자를 나타낸다. SYSDBA_FLAG 접속된 세션이 sysdba 모드인지 아닌지를 나타낸다. 1: sysdba AUTOCOMMIT_FLAG 접속된 세션이 autocommit 모드인지를 나타낸다. 0 : non-autocommit 1 : autocommit SESSION_STATE STATE Description INIT 클라이언트로부터 요청이 들어오기를 기다리 고 있는 상태 AUTH 사용자 인증을 마친 상태 SERVICE READY 서비스 준비상태 (트랜잭션을 만들 수 없음: XA의 경우에만 이 상태로 올 수 있다.) SERVICE 서비스 상태 END 정상 종료(트랜잭션이 있을 경우 커밋) 하고 있는 상태 ROLLBACK 비정상 종료(트랜잭션이 있을 경우 ROLLBACK)하고 있는 상태. 클라이언트가 데이터 딕셔너리 203 끊기거나 서버에서 세션을 강제로 끊을 때 발생한다. UNKNOWN 알 수 없는 상태 ISOLATION_LEVEL 해당 세션에 설정된 고립도(isolation level)를 나타낸다. REPLICATION_MODE 이중화 모드를 나타낸다. 0 : DEFAULT 16 : EAGER 32 : ACKED 48 : LAZY 64 : NONE TRANSACTION_MODE 트랜잭션 모드를 나타낸다. 0 : READ WRITE 4 : READ ONLY COMMIT_WRITE_WAIT_MODE 0 : commit 시, 로그를 디스크에 기록할 때까지 기다리지 않는다. 1 : commit 시, 로그를 디스크에 기록할 때까지 기다린다. OPTIMIZER_MODE 해당 세션에 설정된 최적화 모드를 나타낸다. 1 : 규칙 기반(rule based) 0 : 비용 기반(cost based) CURRENT_STMT_ID 현재 수행중인 문장의 식별자를 나타낸다. STACK_SIZE 해당 세션에 설정된 질의 처리기를 위한 스택 크기를 나타낸다. DEFAULT_DATE_FORMAT 해당 세션에 설정된 기본 날짜 형식을 나타낸다. SQL User’s 204 ALTIBASE5 Administrator’s Manual Manual의 날짜형 데이터 타입을 참조한다. 예) DD-MON-RRRR TRX_UPDATE_MAX_LOGSIZE 하나의 DML 에 의해 생성할 수 있는 로그의 최대 크기를 나타낸다. PARALLEL_DML_MODE DIRECT-PATH INSERT 작업시 Paralle DML 을 수행하고 있는지 여부를 나타낸다. 0 : Parallel DML 수행 안함 1 : Parallel DML 수행 가능 LOGIN_TIME 클라이언트가 접속한 시간을 나타낸다. 데이터 딕셔너리 205 V$SESSIONMGR 알티베이스의 세션 통계 정보를 보여준다. Column name Type Description TASK_COUNT INTEGER 연결된 세션 개수 BASE_TIME INTEGER 현재 시간 IDLE_TIMEOUT_COUNT INTEGER 아래 참조 QUERY_TIMEOUT_COUNT INTEGER 아래 참조 FETCH_TIMEOUT_COUNT INTEGER 아래 참조 UTRANS_TIMEOUT_COUNT INTEGER 아래 참조 SESSION_TERMINATE_COU NT INTEGER 아래 참조 칼럼 정보 TASK_COUNT 현재 접속된 세션의 총 개수를 나타낸다. BASE_TIME 현재 알티베이스가 유지하고 있는 시간을 숫자로 나타낸다. IDLE_TIMEOUT_COUNT 알티베이스가 구동된 이후에 발생된 Idle Timeout 의 횟수를 나타낸다. QUERY_TIMEOUT_COUNT 알티베이스가 구동된 이후에 발생된 Query Timeout 의 횟수를 나타낸다. FETCH_TIMEOUT_COUNT 알티베이스가 구동된 이후에 발생된 Fetch Timeout 의 횟수를 나타낸다. UTRANS_TIMEOUT_COUNT 알티베이스가 구동된 이후에 발생된 Update Transaction Timeout 의 횟수를 나타낸다. SESSION_TERMINATE_COUNT 알티베이스가 구동된 이후에 sysdba 에 의해 강제로 연결이 끊긴 세션의 개수를 나타낸다. 206 ALTIBASE5 Administrator’s Manual V$SESSION_EVENT 알티베이스 구동 후부터 현재까지 접속한 세션별로 모든 대기 이벤트 들의 대기 통계 정보(누적치)를 보여준다. Column name Type Description SID INTEGER 세션의 ID EVENT VARCHAR( 128) 대기 이벤트 명 TOTAL_WAITS BIGINT 대기 이벤트에 대한 총 대기 회수 TOTAL_TIMEOUTS BIGINT 지정된 시간 이후에도 요청한 리소스를 획득하는데 실패한 회수 TIME_WAITED BIGINT 대기 이벤트에 대한 대기시간 (밀리초) AVERAGE_WAIT BIGINT 대기 이벤트에 대한 평균 대기시간 (밀리초) MAX_WAIT BIGINT 대기 이벤트에 대한 최대 대기시간 (밀리초) TIME_WAITED_MICRO BIGINT 대기 이벤트에 대한 대기 시간 (마이크로초) EVENT_ID INTEGER 대기 이벤트의 ID WAIT_CLASS_ID INTEGER 대기 클래스의 ID WAIT_CLASS VARCHAR( 128) 대기 클래스 명 칼럼 정보 SID 대기하고 있는 세션의 ID 를 나타낸다. EVENT 대기 이벤트의 이름을 나타낸다. TOTAL_WAITS 대기 이벤트가 대기하고 있는 총 대기 회수를 나타낸다. TOTAL_TIMEOUTS 대기 이벤트가 지정된 시간 이후에도 요청한 리소스를 획득하는데 실패한 회수를 나타낸다. TIME_WAITED 데이터 딕셔너리 207 대기 이벤트에 대한 대기 시간을 나타낸다. (단위: 밀리초) AVERAGE_WAIT 대기 이벤트에 대한 평균 대기 시간을 나타낸다. (단위: 밀리초) MAX_WAIT 대기 이벤트에 대한 최대 대기 시간을 나타낸다. (단위: 밀리초) TIME_WAITED_MICRO 대기 이벤트에 대한 대기 시간을 나타낸다. (단위: 마이크로초) EVENT 세션에 대기하고 있는 이벤트의 이름을 나타낸다. WAIT_CLASS_ID 세션에 대기하고 있는 이벤트의 클래스 ID를 나타낸다. WAIT_CLASS 세션에 대기하고 있는 이벤트를 그룹화하기 위한 상위 개념의 클래스 이름을 나타낸다. 208 ALTIBASE5 Administrator’s Manual V$SESSION_WAIT 현재 접속한 상태에 있는 모든 세션의 대기 이벤트 정보를 보여준다. 그러나 이전에 접속했던 대기 이벤트들의 정보는 제공하지 않는다. Column name Type Description SID INTEGER 세션의 ID SEQNUM VARCHAR( 128) 대기 이벤트의 ID EVENT BIGINT 대기 이벤트의 이름 P1 BIGINT 대기 이벤트의 파라미터 1 P2 BIGINT 대기 이벤트의 파라미터 2 P3 BIGINT 대기 이벤트의 파라미터 3 WAIT_CLASS_ID INTEGER 대기 클래스의 ID WAIT_CLASS VARCHAR( 128) 대기 클래스의 이름 WAIT_TIME BIGINT 대기시간 (밀리초) SECOND_IN_WAIT BIGINT 대기시간 (초) STATE INTEGER 지원하지 않음 칼럼 정보 SID 현재 접속한 상태에 있는 세션의 ID 를 나타낸다. SEQNUM 세션에 대기하고 있는 이벤트의 ID 를 나타낸다. EVENT 세션에 대기하고 있는 이벤트의 이름을 나타낸다. WAIT_CLASS_ID 대기하고 있는 이벤트의 클래스 ID를 나타낸다. WAIT_CLASS 대기하고 있는 이벤트를 그룹화하기 위한 상위 개념의 클래스 이름을 나타낸다. WAIT_TIME 해당 이벤트가 대기하고 있는 시간을 나타낸다. (단위:밀리초) 데이터 딕셔너리 209 SECOND_IN_WAIT 해당 이벤트가 대기하고 있는 시간을 나타낸다. (단위:초) 210 ALTIBASE5 Administrator’s Manual V$SESSTAT 시스템에 존재하는 세션의 상태를 나타낸다. 이 값을 검색하면 검색한 시점의 세션의 값을 보여준다. Column name Type Description SID INTEGER 세션 일련 번호 SEQNUM INTEGER 상태 일련 번호 NAME VARCHAR(128) 상태 이름 VALUE BIGINT 상태 값 칼럼 정보 SID 세션의 고유 아이디를 나타낸다. SEQNUM 시스템의 상태를 나타내는 일련 번호를 나타낸다. NAME 상태 일련 번호에 해당하는 이름을 나타낸다. VALUE 상태 일련 번호에 해당하는 현재 시스템의 값을 64 비트 정수로 나타낸다. 데이터 딕셔너리 211 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 실행되는 전체 SQL 문을 64 바이트 단위의 문자열로 나누어 저장한다. PIECE 는 64 바이트 문자열의 일련 번호로 0 부터 시작된다. TEXT 실제 SQL 문을 표현하는 64 바이트 문자열을 나타낸다. 212 ALTIBASE5 Administrator’s Manual V$SQL_PLAN_CACHE SQL Plan Cache 의 현재 상태 및 통계 정보를 나타낸다. Column name Type Description MAX_CACHE_SIZE BIGINT SQL Plan Cache의 최대 크기 (byte) CURRENT_HOT_LRU_SIZE BIGINT 현재 HOT 영역 LRU의 크기 CURRENT_COLD_LRU_SIZ E BIGINT 현재 COLD 영역 LRU의 크기 CURRENT_CACHE_SIZE BIGINT 현재 SQL Plan Cache의 크기 CURRENT_CACHE_OBJ_C OUNT INTEGER 현재 SQL Plan Cache에 등록된 PLAN 객체수 CACHE_HIT_COUNT BIGINT SQL Plan Cache에 등록된 PLAN의 활용수 CACHE_MISS_COUNT BIGINT SQL Plan Cache에서 PLAN 검색과정 에서 PLAN을 못찾은 횟수 CACHE_IN_FAIL_COUNT BIGINT SQL Plan Cache에 새로운 plan객체 삽입시 cache 최대 크기 제약으로 실 패한 횟수 CACHE_OUT_COUNT BIGINT SQL Plan Cache에서 제거된 PLAN의 개수 CACHE_INSERTED_COUN T BIGINT SQL Plan Cache에 추가된 PLAN의 개수 NONE_CACHE_SQL_TRY_ COUNT BIGINT DDL, DCL 등의 Cache 비대상 구문의 시도 횟수 칼럼 정보 MAX_CACHE_SIZE SQL Plan Cache 의 최대 크기를 나타낸다. SQL Plan Cache 의 최대 크기를 줄이거나, 늘리기 위해서는 ‘alter system set SQL_PLAN_CACHE_SIZE = ’ 구문을 실행한다. CURRENT_HOT_LRU_SIZE SQL Plan Cache 의 LRU 리스트 중에서 빈번하게 참조되는 Plan Cache 객체를 나타낸다. HOT LRU 에서 관리되며, 크기(byte)를 나타낸다. CURRENT_COLD_LRU_SIZE SQL Plan Cache 의 LRU 리스트 중 자주 참조되지 않은 Plan Cache 객체를 나타낸다. COLD LRU 에서 관리되며, 크기(byte)를 데이터 딕셔너리 213 나타낸다. CURRENT_CACHE_SIZE SQL Plan Cache 에 현재 삽입된 Plan Cache 객체들의 전체 크기를 나타낸다. CURRENT_CACHE_OBJ_COUNT SQL Plan Cache 에 삽입된 Plan Cache 객체들의 수를 나타낸다. CACHE_HIT_COUNT SQL Plan Cache 에 삽입된 Plan Cache 객체들을 사용한 전체 횟수를 나타낸다. CACHE_MISS_COUNT SQL Plan Cache 에 없는 PLAN 객체 참조 시도 횟수를 나타낸다. CACHE_IN_FAIL_COUNT SQL Plan Cache 에 새로운 PLAN 객체를 삽입할 경우 Cache 의 최대 메모리 크기 제약으로 SQL Plan Cache 에서 현재 참조하지 않는 PLAN 객체들을 찾아 cache 에서 삭제 및 해제 시도를 수행하였지만, Cache 에 삽입을 못하는 횟수이다. CACHE_OUT_COUNT SQL Plan Cache 에 추가되었다가 삭제된 PLAN 객체의 개수를 의미한다. CACHE_INSERTED_COUNT SQL Plan Cache 에 추가된 PLAN 객체의 개수를 의미한다. NONE_CACHE_SQL_TRY_COUNT SQL Plan Cache 의 cache 비대상 구문이 발생한 횟수를 나타내며, DDL 과 DCL 이 비대상 구문이다. 214 ALTIBASE5 Administrator’s Manual V$SQL_PLAN_CACHE_PCO SQL Plan Cache 에 등록된 Plan Cache 객체에 대한 정보를 나타낸다. Column name Type Description SQL_TEXT_ID VARCHAR(64) Plan Cache 객체가 속한 SQL Text 객체 ID PCO_ID INTEGER SQL Text 객체 내에서 Plan cache 객체 번호 CREATE_REASON VARCHAR(28) Plan cache 객체를 생성한 이유 HIT_COUNT INTEGER Plan cache 객체 참조 횟수 REBUILD_COUNT INTEGER Plan cache 객체가 rebuild된 횟수 PLAN_STATE VARCHAR(17) Plan cache 객체의 plan 상태 칼럼 정보 SQL_TEXT_ID Plan Cache 객체가 속해 있는 SQL Text 객체의 ID PCO_ID SQL Text 객체 내에서 Plan cache 객체의 번호를 나타낸다. CREATE_REASON plan cache 객체를 생성한 이유를 나타내며 다음과 같은 값이 올 수 있다. y CREATE_BY_CACHE_MISS SQL Plan cache에서 plan cache 객체가 없어서 생성한 경우 y CREATE_BY_PLAN_INVALIATION prepare 과정중에 SQL Plan Cache에서 plan cache 객체를 찾았지만. Plan에서 참조한 DB 객체가 유효 상태가 아니어서 새로 생성한 경우 y CREATE_BY_PLAN_TOO_OLD execute 과정중에 Plan에서 참조한 객체의 통계 정보의 변경폭이 한계치를 넘었거나, DDL이 발생하여 새로 plan cache 객체를 생성한 경우 HIT_COUNT Plan cache 객체의 참조 횟수를 나타낸다. REBUILD_COUNT 데이터 딕셔너리 215 Plan cache 객체의 plan 이 다시 컴파일된 횟수를 나타낸다. PLAN_STATE Plan cache 객체 plan 의 상태를 나타니며, 다음과 같은 값을 가질수 있다. y NOT_READY plan cache 객체에 아직 plan 및 환경이 할당되어 있지 않는 상태 y READY plan cache 객체에 plan 및 환경이 모두 할당되어 있는 상태 y HARD-PREPARE-NEED Plan Cache 비대상 구문이거나 Plan Cache 영역 부족으로 인해 Hard Prepare가 필요한 상태 y OLD_PLAN plan rebuild에 의하여 앞으로 사용되지 않는 plan 상태 216 ALTIBASE5 Administrator’s Manual V$SQL_PLAN_CACHE_SQLTEXT SQL Plan Cache 에 등록된 Plan Cache 객체에 대한 정보를 나타낸다. Column name Type Description SQL_TEXT_ID VARCHAR(64) SQL 문장의 SQL Plan Cache에서 ID SQL_TEXT VARCHAR(16 384) SQL 문장 CHILD_PCO_COUNT INTEGER Child Plan Cache 객체의 수 CHILD_PCO_CREATE_CO UNT INTEGER Child Plan Cache 객체의 생성 갯수 칼럼 정보 SQL_TEXT_ID SQL 문장의 SQL Plan Cache 에서 ID 를 나타낸다. 앞의 4 자리 숫자는 SQL Plan Cache 내의 bucket 번호를 나타내며, 나머지 숫자는 해당 bucket 내의 일련번호를 나타낸다. SQL_TEXT SQL 문장을 나타낸다. CHILD_PCO_COUNT SQL Text plan 객체가 현재 가지고 있는 Child Plan Cache 객체의 수이다. CHILD_PCO_CREATE_COUNT SQL Text Plan 객체에서 지금까지 생성한 Child Plan Cache 의 갯수를 나타낸다. SQL Text Plan 객체에서 Child Plan Cache 객체를 생성하는 경우는 다음의 2 가지이다. y SQL문장은 같지만 Plan을 생성한 환경이 맞지 않아 Child Plan Cache 객체를 생성한다. y PLAN의 참조하는 객체의 변경 또는 객체의 통계 정보의 변경 폭이 한계치를 넘는 경우 새로운 Plan Cache 객체를 생성한다. 데이터 딕셔너리 217 V$STABLE_MEM_DATAFILES 데이터베이스에 존재하는 데이터 파일의 전체 경로를 보여준다. Column name Type Description MEM_DATA_FILE VARCHAR(256) 데이터 파일의 전체 경로 칼럼 정보 MEM_DATA_FILE 데이터베이스에 존재하는 데이터 파일의 전체 경로를 나타낸다. 218 ALTIBASE5 Administrator’s Manual V$STATEMENT 현재 알티베이스에 생성된 모든 세션의 구문 리스트를 보여준다. Column name Type Description ID INTEGER 해당 구문 아이디 PARENT_ID INTEGER 부모 구문 아이디 CURSOR_TYPE INTEGER 커서의 종류 SESSION_ID INTEGER 해당 구문이 속한 세션 아이디 TX_ID BIGINT 트랜잭션 아이디 QUERY VARCHAR( 16384) 수행되는 SQL 스트링 LAST_QUERY_START_TIME INTEGER 최종 쿼리 시작 시간 QUERY_START_TIME INTEGER 현재 쿼리 시작 시간 FETCH_START_TIME INTEGER 현재 Fetch 시작 시간 STATE VARCHAR( 13) 현재 Statement의 상태 ARRAY_FLAG INTEGER Array 수행 플래그 ROW_NUMBER INTEGER Array의 Row Number EXECUTE_FLAG INTEGER 수행 여부 플래그 BEGIN_FLAG INTEGER 내부 용도로 사용 TOTAL_TIME BIGINT 총 경과 시간 PARSE_TIME BIGINT 파싱 경과 시간 VALIDATE_TIME BIGINT 정당성 검사 경과 시간 OPTIMIZE_TIME BIGINT 최적화 경과 시간 EXECUTE_TIME BIGINT 실행 경과 시간 FETCH_TIME BIGINT Fetch 경과 시간 SOFT_PREPARE_TIME BIGINT Prepare 과정중 SQL Plan Cache에서 plan 탐색 시간 SQL_CACHE_TEXT_ID VARCHAR( 64) SQL plan cache 객체의 SQL Text ID SQL_CACHE_PCO_ID INTEGER plan cache 객체의 ID OPTIMIZER BIGINT 최적화 모드 COST BIGINT 최적화 비용 USED_MEMORY BIGINT 향후 확장 예정 READ_PAGE BIGINT 읽은 디스크 페이지 WRITE_PAGE BIGINT 기록한 디스크 페이지 GET_PAGE BIGINT 접근 디스크 페이지 데이터 딕셔너리 219 Column name Type Description CREATE_PAGE BIGINT 생성된 디스크 페이지 UNDO_READ_PAGE BIGINT 읽은 UNDO 디스크 페이지 UNDO_WRITE_PAGE BIGINT 기록한 UNDO 디스크 페이지 UNDO_GET_PAGE BIGINT 접근한 UNDO 디스크 페이지 UNDO_CREATE_PAGE BIGINT 생성한 UNDO 디스크 페이지 MEM_CURSOR_FULL_SCAN BIGINT 인덱스 없는 메모리 커서 MEM_CURSOR_INDEX_SCA N BIGINT 인덱스 사용 메모리 커서 DISK_CURSOR_FULL_SCAN BIGINT 인덱스 없는 디스크 커서 DISK_CURSOR_INDEX_SCA N BIGINT 인덱스 사용 디스크 커서 EXECUTE_SUCCESS BIGINT 실행 성공 횟수 EXECUTE_FAILURE BIGINT 실행 실패 횟수 PROCESS_ROW BIGINT 처리된 레코드 개수 MEMORY_TABLE_ACCESS_ COUNT BIGINT 검색 대상 메모리 테이블에 대해 해당 문장이 검색하는 레코드의 총수 SEQNUM INTEGER 대기 이벤트 ID EVENT VARCHAR( 128) 대기 이벤트 명 P1 BIGINT 대기 이벤트 파라미터 1 P2 BIGINT 대기 이벤트 파라미터 2 P3 BIGINT 대기 이벤트 파라미터 3 WAIT_TIME BIGINT 대기 시간 (밀리초 단위) SECOND_IN_TIME BIGINT 대기 시간 (초 단위) 칼럼 정보 ID 해당 구문이 가지고 있는 세션 내부에서 구별되는 유일한 아이디이다. PARENT_ID 해당 구문이 가지고 있는 부모 구문의 아이디이다. CURSOR_TYPE 0x02 비트가 셋팅될 경우 메모리 커서이고, 0x04 비트가 셋팅될 경우 디스크 커서이다. 220 ALTIBASE5 Administrator’s Manual SESSION_ID 해당 구문이 속한 세션의 아이디이다. TX_ID 현재 수행중인 트랜잭션의 아이디를 나타낸다. QUERY 현재 구문이 수행하고 있거나 수행했던 쿼리의 String 을 나타낸다. LAST_QUERY_START_TIME 마지막으로 수행된 쿼리의 시작 시간을 초로 나타낸다. QUERY_START_TIME 현재 구문이 수행하는 쿼리의 시작 시간을 초로 나타낸다. FETCH_START_TIME 현재 구문이 SELECT 일 경우 fetch 가 시작된 시간을 초로 나타낸다. STATE 현재 statement 의 상태를 나타내며, 다음과 같은 값을 갖는다. ALLOC : 해당 구문이 할당된 초기화 상태 PREPARED : 해당 구문이 prepare 된 상태 FETCH READY : 해당 구문이 Fetch 를 위해 준비하고 있는 상태 FETCH PROCEED : 해당 구문이 Fetch 과정중에 있는 상태 ARRAY_FLAG 현재 statement 가 array 또는 batch 모드로 수행중인지 여부를 나타내며, 다음과 같은 값을 갖는다. 0 : Array 나 batch 모드가 아님 1 : Array 나 batch 모드로 수행중임 ROW_NUMBER Array 또는 batch 모드로 수행시 현재 처리중인 row 의 번호로 1 번부터 시작한다. EXECUTE_FLAG 현재 statement 가 수행중인지 여부를 나타내며 다음과 같은 값을 갖는다. 0 : 현재 수행중이 아님 데이터 딕셔너리 221 1 : 현재 수행중임 BEGIN_FLAG 0 : 현재 구문이 시작되지 않았거나, 종료되었음. 1 : 현재 구문이 열려있음. TOTAL_TIME 현재 구문의 총 수행시간을 나타내며 단위는 micro second 이다. 해당 구문의 종류에 따라 EXECUTE_TIME 에서 PVO 의 시간이 추가되거나, Fetch 의 시간이 추가될 수 있다. PARSE_TIME 쿼리의 구문 검사 시간을 micro-second 단위로 나타낸다. VALIDATE_TIME 쿼리의 의미 검사 시간을 micro-second 단위로 나타낸다. OPTIMIZE_TIME 쿼리의 최적화 수행 시간을 micro-second 단위로 나타낸다. EXECUTE_TIME 쿼리의 순수 실행 시간을 micro-second 단위로 나타낸다. Select 의 경우에는 첫번째 Fetch 가 일어나기 전까지의 수행시간을 나타낸다. FETCH_TIME SELECT 쿼리의 경우 fetch 경과 시간을 micro-second 단위로 나타낸다. SOFT_PREPARE_TIME Prepare 과정에서 SQL 문장과 plan 생성시 필요한 각종 변수들을 이용하여 SQL Plan Cache 에서 이에 부합하는 plan 객체를 찾는 시간을 나타낸다. (단위: micro second) SQL_CACHE_TEXT_ID SQL Plan Cache 에서 plan 객체를 찾은 경우, SQL Cache Text 객체의 ID 를 나타낸다. SQL_CACHE_PCO_ID SQL Cache Text 객체에서 공유 plan cache 객체의 ID 를 나타낸다. OPTIMIZER 최적화 모드를 나타내며 다음과 같은 값을 갖는다. 222 ALTIBASE5 Administrator’s Manual 0 : 비용(COST) 기반 최적화 1 : 규칙(RULE) 기반 최적화 COST 질의 최적화로 계산된 질의 비용값을 나타낸다. USED_MEMORY 향후 확장 예정. READ_PAGE 질의 수행시 물리적으로 읽은 디스크 데이터 페이지의 개수를 나타낸다. WRITE_PAGE 질의 수행시 물리적으로 기록한 디스크 데이터 페이지의 개수를 나타낸다. GET_PAGE 질의 수행시 접근한 디스크 데이터 페이지의 개수를 나타낸다. CREATE_PAGE 질의 수행시 생성한 디스크 데이터 페이지의 개수를 나타낸다. UNDO_READ_PAGE 질의 수행시 물리적으로 읽은 디스크 UNDO 페이지의 개수를 나타낸다. UNDO_WRITE_PAGE 질의 수행시 물리적으로 기록한 디스크 UNDO 페이지의 개수를 나타낸다. UNDO_CREATE_PAGE 질의 수행시 생성한 디스크 UNDO 페이지의 개수를 나타낸다. MEM_CURSOR_FULL_SCAN 질의 수행시 메모리 테이블에 대한 검색 중 인덱스 없는 검색 방법의 사용 횟수를 나타낸다. MEM_CURSOR_INDEX_SCAN 질의 수행시 메모리 테이블에 대한 검색 중 인덱스를 이용한 검색 방법의 사용 횟수를 나타낸다. DISK_CURSOR_FULL_SCAN 질의 수행시 디스크 테이블에 대한 검색 중 인덱스 없는 검색 데이터 딕셔너리 223 방법의 사용 횟수를 나타낸다. DISK_CURSOR_INDEX_SCAN 질의 수행시 디스크 테이블에 대한 검색 중 인덱스를 이용한 검색 방법의 사용 횟수를 나타낸다. EXECUTE_SUCCESS 질의 수행의 성공 횟수를 나타낸다. EXECUTE_FAILURE 질의 수행의 실패 횟수를 나타낸다. PROCESS_ROW 질의 수행시 처리한 레코드의 개수를 나타낸다. MEMORY_TABLE_ACCESS_COUNT 문장 실행 시에 검색 대상이 되는 메모리 테이블에 대해, 각각에서 검색되는 레코드 수의 총합으로 문장의 실행 계획에 나타나는 ACCESS 수의 총합과 같다. 224 ALTIBASE5 Administrator’s Manual V$STATNAME 이 테이블은 시스템 전체의 상태를 보여주는 V$SYSSTAT 와 세션의 상태를 보여주는 V$SESSTAT 에서 사용되는 데이타의 일련번호와 이름을 나타낸다. 이 테이블은 자체로는 의미가 없으며, 위의 두 가지 성능뷰와 연결될 때 의미가 있다. Column name Type Description SEQNUM INTEGER 상태 일련 번호 NAME VARCHAR(128) 상태 이름 칼럼 정보 SEQNUM 해당 성능 뷰가 표현할 상태의 일련 번호를 나타낸다. NAME 성능 뷰에서 표현되는 상태의 이름을 나타낸다. 각 상태의 일련 번호와 설명은 아래와 같으며, 64 비트 정수로 표현된다. SEQ NAME Description 0 logon current 현재 접속된 사용자 수 1 logon cumulative 접속 사용자의 누적합 2 data page read 시스템/세션의 페이지 읽은 횟수 3 data page write 시스템/세션의 페이지 쓴 횟수 4 data page gets 시스템/세션의 페이지 접근 횟수 5 data page create 시스템/세션의 페이지 생성 횟수 6 undo page read 시스템/세션의 UNDO 페이지 읽은 횟수 7 undo page write 시스템/세션의 UNDO 페이지 쓴 횟 수 8 undo page gets 시스템/세션의 UNDO 페이지 접근 횟수 9 undo page create시스템/세션의 UNDO 페이지 생성 횟수 10 base time in second 시스템이 유지하는 내부 시간(초) 11 query timeout 시스템/세션에서 발생한 Query Timeout 횟수 12 idle timeout 시스템/세션에서 발생한 Idle Timeout 횟수 데이터 딕셔너리 225 SEQ NAME Description 13 fetch timeout 시스템/세션에서 발생한 Fetch Timeout 횟수 14 utrans timeout 시스템/세션에서 발생한 utrans Timeout 횟수 15 session terminated 시스템/세션에서 발생한 세션 강제 종료 횟수 16 session commit 시스템/세션에서 발생한 commit 횟 수 17 session rollback 시스템/세션에서 발생한 rollback 횟 수 18 execute success count 시스템/세션에서 쿼리가 성공적으로 수행된 횟수 19 execute failure count 시스템/세션에서 Query의 수행이 실 패한 횟수 20 prepare success count 시스템/세션에서 Prepare가 성공한 횟수 21 prepare failure count 시스템/세션에서 Prepare가 실패한 횟수 22 write redo log count 시스템/세션에서 기록한 로그의 횟수 23 write redo log bytes 시스템/세션에서 기록한 로그의 총 바이트 24 byte received via inet 시스템/세션 INET 소켓을 통해 읽 은 데이터 (단위:바이트) 25 byte sent via inet 시스템/세션 INET 소켓을 통해 쓴 데이터(단위:바이트) 26 byte received via unix domain 시스템/세션 Unix Domain으로 읽 은 데이터(단위:바이트) 27 byte sent via unix domain 시스템/세션 Unix Domain으로 쓴 데이터(단위:바이트) 28 semop count for receiving via ipc 시스템/세션 IPC 통신 읽기 과정에 서 수행한 세마퍼 연산 횟수 29 semop count for sending via ipc 시스템/세션 IPC 통신 쓰기 과정에 서 수행한 세마퍼 연산 횟수 30 memory table cursor full scan count 시스템/세션에서 수행한 메모리 테이 블에 대한 순차적 커서 열기 횟수 31 memory table cursor index scan count 시스템/세션에서 수행한 메모리 테이 블에 대한 인덱스 커서 열기 횟수 226 ALTIBASE5 Administrator’s Manual SEQ NAME Description 32 disk table cursor full scan count 시스템/세션에서 수행한 디스크 테이 블에 대한 순차적 커서 열기 횟수 33 disk table cursor index scan count 시스템/세션에서 수행한 디스크 테이 블에 대한 인덱스 커서 열기 횟수 34 lock acquired 시스템/세션에서 수행한 테이블에 대 한 로크의 얻기 횟수 (주의: 내부적인 이유로, V$SYSSTAT의 이 값은 아래 lock release 값과 같지 않을 수 있다. 그 러나 V$SESSTAT의 경우에는 완전 히 동일해야 한다.) 35 lock released 시스템/세션에서 수행한 테이블에 대 한 로크의 해제 횟수 데이터 딕셔너리 227 V$SYSSTAT 시스템 상태를 보여준다. 그러나 상태값이 모든 세션의 정보로부터 3 초마다 갱신되기 때문에 검색 시 보이는 값보다 이전 상태의 값일 수 있다. Column name Type Description SEQNUM INTEGER 상태 일련 번호 NAME VARCHAR(128) 상태 이름 VALUE BIGINT 상태 값 칼럼 정보 SEQNUM 시스템의 상태를 나타내는 일련 번호를 나타낸다. NAME 상태 일련 번호에 해당하는 이름을 나타낸다. VALUE 상태 일련 번호에 해당하는 현재 시스템의 값을 64 비트 정수로 표현한다. 228 ALTIBASE5 Administrator’s Manual V$SYSTEM_CONFLICT_PAGE 디스크 버퍼 공간 상에서 페이지간 래치(Latch) 경합에 의한 병목 구간을 분석할 수 있도록 페이지 타입별로 경합 정보를 보여준다. TIMED_STATISTICS 프로퍼티가 1 로 설정된 경우에만 정보를 수집한다. Column name Type Description PAGE_TYPE VARCHAR(20) 페이지 타입 LATCH_MISS_CNT BIGINT 래치 획득 실패 횟수 LATCH_MISS_TIME BIGINT 대기 시간 칼럼 정보 PAGE_TYPE 페이지 타입을 나타낸다. LATCH_MISS_CNT 버퍼 페이지의 래치 획득 실패 횟수를 나타낸다. LATCH_MISS_TIME(단위: 마이크로 초) 버퍼 페이지의 래치 획득 실패로 인한 대기 시간을 나타낸다. 데이터 딕셔너리 229 V$SYSTEM_EVENT 알티베이스 구동 후부터 현재까지 대기 이벤트별로 대기 통계 정보(누적치)를 보여준다. Column name Type Description EVENT VARCHAR(128) 대기 이벤트 명 TOTAL_WAITS BIGINT 대기 이벤트에 대한 총 대기 회수 TOTAL_TIMEOUTS BIGINT 지정된 시간 이후에도 요청한 리소스를 획득하는데 실패한 회수 TIME_WAITED BIGINT 대기 이벤트에 대한 대기시간 (밀리초) AVERAGE_WAIT BIGINT 대기 이벤트에 대한 평균 대기시간 (밀리초) TIME_WAITED_MICRO BIGINT 대기 이벤트에 대한 대기 시간(마이크로초) EVENT_ID INTEGER 대기 이벤트의 ID WAIT_CLASS_ID INTEGER 대기 클래스의 ID WAIT_CLASS VARCHAR(128) 대기 클래스 명 칼럼 정보 EVENT 대기하는 이벤트의 이름을 나타낸다. TOTAL_WAITS 대기하는 이벤트가 전체 대기한 회수를 나타낸다. TOTAL_TIMEOUTS 대기 이벤트가 지정된 시간 이후에도 요청한 리소스를 획득하는데 실패한 회수를 나타낸다. TIME_WAITED 대기 이벤트에 대한 대기 시간을 나타낸다. (단위: 밀리초) AVERAGE_WAIT 대기 이벤트에 대한 평균 대기 시간을 나타낸다. (단위: 밀리초) TIME_WAITED_MICRO 대기 이벤트에 대한 대기 시간을 나타낸다. (단위: 마이크로초) 230 ALTIBASE5 Administrator’s Manual EVENT_ID 대기 이벤트의 ID 를 나타낸다. WAIT_CLASS_ID 세션에 대기하고 있는 이벤트의 클래스 ID 를 나타낸다. WAIT_CLASS 세션에 대기하고 있는 이벤트를 그룹화하기 위한 상위 개념의 클래스 이름을 나타낸다. 데이터 딕셔너리 231 V$SYSTEM_WAIT_CLASS 알티베이스 구동 후부터 현재까지의 대기 클래스별로 대기한 통계 정보(누적치)를 보여준다. Column name Type Description WAIT_CLASS_ID INTEGER 대기 이벤트의 ID WAIT_CLASS VHARCHAR(128) 대기 클래스 명 TOTAL_WAITS BIGINT 대기 클래스에 대한 총 대기 회수 TIME_WAITED VACHAR(128) 대기 클래스에 대한 총 대기 시간(밀리초) 칼럼 정보 WAIT_CLASS_ID 세션에 대기하고 있는 이벤트의 클래스 ID 를 나타낸다. WAIT_CLASS 세션에 대기하고 있는 이벤트를 그룹화하기 위한 상위 개념의 클래스 이름을 나타낸다. TOTAL_WAITS 대기 클래스가 대기하고 있는 총 회수를 나타낸다. TIME_WAITED 대기 클래스가 대기하고 있는 총 시간을 나타낸다. (단위: 밀리초) 예제 <예 1> 현재 발생하는 대기 이벤트에 대한 대기 클래스별 대기 횟수와 대기 시간을 보여준다. iSQL> select * from v$system_wait_class order by total_waits desc; <예 1> 가장 오래 대기한 대기 클래스부터 대기 클래스 별로 전체 대비 대기 횟수 비율과 대기 시간 비율을 내림차순으로 출력한다. iSQL> select WAIT_CLAS, TOTAL_WAITS, round(10 * (TOTAL_WAITS / SUM_WAITS),2) PCT_WAITS, TIME_WAITED, round(10 * (TIME_WAITED / SUM_TIME),2) PCT_TIME from 232 ALTIBASE5 Administrator’s Manual (select WAIT_CLASS, TOTAL_WAITS, TIME_WAITED from V$SYSTEM_WAIT_CLAS where WAIT_CLAS != 'Idle'), (select sum(TOTAL_WAITS) SUM_WAITS, sum(TIME_WAITED) SUM_TIME from V$SYSTEM_WAIT_CLAS where WAIT_CLAS != 'Idle') order by 5 desc; 데이터 딕셔너리 233 V$TABLE 성능 뷰 리스트를 보여준다. Column name Type Description NAME VARCHAR(39) 테이블 명 SLOTSIZE SMALLINT 레코드의크기 COLUMNCOUNT SMALLINT 칼럼의 개수 칼럼 정보 NAME 성능 뷰의 이름을 나타낸다. SLOTSIZE 해당 성능 뷰가 가진 레코드의 크기를 나타낸다. COLUMNCOUNT 해당 성능 뷰가 가진 칼럼의 크기를 나타낸다. 234 ALTIBASE5 Administrator’s Manual V$TABLESPACES 테이블스페이스의 정보를 보여준다. Column name Type Description ID INTEGER 테이블스페이스 식별자 NAME VARCHAR(40) 테이블스페이스 이름 NEXT_FILE_ID INTEGER 다음 생성될 데이터 파일 식별자 TYPE INTEGER 테이블스페이스 타입 STATE INTEGER 테이블스페이스의 상태 EXTENT_MANAGEMENT VARCHAR(20) 사용자가 디스크 테이블스페이스를 생성할 때 정한 EXTENT를 관리하 는 방식 SEGMENT_MANAGEMENT VARCHAR(20) 테이블스페이스의 세그먼트 타입 DATAFILE_COUNT INTEGER 테이블스페이스 파일 개수 TOTAL_PAGE_COUNT BIGINT 총 페이지 개수 EXTENT_PAGE_COUNT INTEGER 해당 테이블스페이스의 익스텐트 크 기(페이지 개수) ALLOCATED_PAGE_COUNT BIGINT 해당 테이블스페이스에서 초기화된 페이지 개수 PAGE_SIZE INTEGER 테이블스페이스의 페이지 크기 ATTR_LOG_COMPRESS INTEGER 테이블스페이스에 속하는 테이블에 DML 수행시 LOG COMPRESS 여 부 칼럼 정보 ID 테이블스페이스의 식별자를 나타낸다. 사용자 테이블스페이스는 식별자 값으로 4 부터 부여되며, 항상 증가하는 값이다. NAME CREATE TABLESPACE 구문에 정의된 테이블스페이스의 이름을 나타낸다. NEXT_FILE_ID 테이블스페이스에 데이터 파일이 추가될 경우 데이터 파일에 부여할 식별자이다. 하나의 데이터 파일이 추가될 경우 이 값은 1 증가한다. TYPE 테이블스페이스의 타입을 나타낸다. 데이터 딕셔너리 235 0 : 메모리 시스템 딕셔너리(MEMORY_SYSTEM_DICTIONARY) 1 : 메모리 시스템 데이터(MEMORY_SYSTEM_DATA) 2 : 메모리 사용자 데이터(MEMORY_USER_DATA) 3 : 디스크 시스템 데이터(DISK_SYSTEM_DATA) 4 : 디스크 사용자 데이터(DISK_USER_DATA) 5 : 디스크 시스템 템프(DISK_SYSTEM_TEMP) 6 : 디스크 사용자 템프(DISK_USER_TEMP) 7 : 디스크 시스템 언두(DISK_SYSTEM_UNDO) 8 : 휘발성 사용자 데이터(VOLATILE_USER_DATA) STATE 테이블스페이스의 상태를 나타낸다. 1: 오프라인(OFFLINE) 2: 온라인(ONLINE) 5: 백업중인 오프라인 테이블스페이스(Backup) 6: 백업중인 온라인 테이블스페이스(Backup) 128: 삭제된 테이블스페이스(Dropped) 1024: 폐기된 테이블스페이스(Discarded) 1028: 백업중인 폐긴된 테이블스페이스(Backup) EXTENT_MANAGEMENT 사용자가 디스크 테이블스페이스를 생성할 때 결정한 EXTENT 를 관리하는 방식을 나타낸다. 현재는 비트맵(BITMAP) 방식을 제공한다. BITMAP : 테이블스페이스의 모든 익스텐트의 할당 여부를 관리 SEGMENT_MANAGEMENT 테이블스페이스에서 세그먼트를 생성할 때 어떤 타입으로 생성된 것인지를 나타낸다. MANUAL : 프리(Free) 페이지 관리를 프리 리스트로 하는 세그먼트 생성 AUTO : 프리 페이지 관리를 비트맵(bitmap) 인덱스 기반으로 하는 세그먼트 생성 DATAFILE_COUNT 236 ALTIBASE5 Administrator’s Manual 테이블스페이스에 포함된 데이터 파일의 개수를 나타낸다. TOTAL_PAGE_COUNT 테이블스페이스의 크기를 페이지 개수로 나타낸다. 실제 테이블스페이스의 공간은 이 값과 페이지 크기의 곱(TOTAL_PAGE_COUNT * PAGE_SIZE)으로 계산할 수 있다. 파일마다 파일 헤더 1 페이지씩을 제외하고 실제 사용할 수 있는 페이지이다. EXTENT_PAGE_COUNT 해당 테이블스페이스의 익스텐트 크기(단위: 페이지 개수)를 나타낸다. 하나의 익스텐트가 가지는 페이지 개수를 의미하며, 최소 3 개 이상의 페이지를 갖는다. ALLOCATED_PAGE_COUNT 해당 테이블스페이스에서 초기화된 페이지 개수를 나타낸다. PAGE_SIZE 테이블스페이스의 페이지 크기를 나타낸다. (디스크 테이블스페이스 8KB, 메모리 테이블스페이스 32KB) ATTR_LOG_COMPRESS 테이블스페이스에 속하는 테이블에 DML 을 수행할 때, LOG COMPRESS 의 수행 여부를 나타낸다. 0 : LOG COMPRESS 수행 안한다. 1 : LOG COMPRESS 수행한다. 데이터 딕셔너리 237 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 : 출력중인 상태 SUM : 출력중인 모든 상태의 총합. 각 모듈에 설정된 메시지 로깅 플래그 값이다. 출력 설정에 대한 자세한 내용은 하단의 사용방법을 참고한다. POWLEVEL 현재 레벨의 2 의 승수를 나타낸다. 이 값은 저장 프로시저 addTrcLevel(), delTrcLevel()을 쉽게 사용할 수 있도록 미리 계산되어 있다. 해당 저장 프로시저는 패키지와 함께 배포되는 tracelog.sql 를 실행하여 생성할 수 있다. DESCRIPTION 현재의 레벨이 나타내는 내력 메시지에 대한 설명을 나타낸다. 238 ALTIBASE5 Administrator’s Manual 예제 현재 서버 모듈에 대해 설정된 트레이스로깅 레벨을 확인한다. iSQL> select module_name, trclevel, flag, powlevel, description from v$tracelog where module_name like '%SER%'; MODULE_NAME TRCLEVEL FLAG POWLEVEL DESCRIPTION ------------------------------------------- SERVER 1 O 1 [DEFAULT] TimeOut(Query,Fetch,Idle,UTrans) Trace Log SERVER 2 O 2 [DEFAULT] Network Operation Fail Trace Log SERVER 3 O 4 [DEFAULT] Memory Operation Warning Trace Log 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 1 X 1024 - SERVER 12 X 2048 - SERVER 13 X 4096 - SERVER 14 X 8192 - SERVER 15 X 16384 - SERVER 16 X 32768 - SERVER 17 X 6536 - SERVER 18 X 131072 - SERVER 19 X 26214 - SERVER 20 X 52428 - SERVER 21 X 1048576 - SERVER 2 X 2097152 - SERVER 23 X 4194304 - SERVER 24 X 838608 - SERVER 25 X 167216 - SERVER 26 X 35432 - SERVER 27 X 6710864 - SERVER 28 X 13421728 - SERVER 29 X 268435456 - SERVER 30 X 536870912 - SERVER 31 X 1073741824 - SERVER 32 X 2147483648 - SERVER 9 SUM 7 Total Sum of Trace Log Values 33 rows selected. 사용 방법 알티베이스는 SERVER, SM, QP, RP 4 개의 모듈에 대하여 메시지 로깅 프로퍼티가 존재한다. 데이터 딕셔너리 239 SERVER_MSGLOG_FLAG : 통신 및 서버 메시지 SM _MSGLOG_FLAG : 저장관리자 관련 메시지 QP_MSGLOG_FLAG : 질의처리기 관련 메시지 RP_MSGLOG_FLAG : 이중화 관련 메시지 각각의 프로퍼티는 32 개의 비트가 존재하고, 각 비트에 대한 메시지 종류 및 설명은 V$TRACELOG 를 참조한다. 메시지 로깅 내역 변경 방법은 다음과 같다. y 서버의 로깅 메시지가 모두 출력되지 않도록 할 때. alter system set server_msglog_flag=0 y 서버의 로깅 메시지 중 첫번째, 두번째, 다섯번째 비트에 해당하는 메시지를 출력하도록 할 때(1+2+5). alter system set server_msglog_lfag=8 y 이중화 로깅 메시지 중 충돌 관련 메시지만 출력하고자 할 때. alter system set rp_msglog_flag=2 y 질의처리기에서 저장 프로시저의 오류 라인(첫번째 비트)과 DDL의 수행 내역(두번째 비트)을 로깅하고자 할 경우(1+2) alter system set qp_msglog_flag=3 240 ALTIBASE5 Administrator’s Manual V$TRANSACTION 트랜잭션 객체의 정보를 보여준다. Column name Type Description ID BIGINT 트랜잭션 아이디 SESSION_ID INTEGER 현재 트랜잭션에서 사용하고 있는 세 션 아이디 MEMORY_VIEW_SCN VARCHAR(29) 아래 참조 MIN_MEMORY_LOB_VIEW _SCN VARCHAR(29) 아래 참조 DISK_VIEW_SCN VARCHAR(29) 아래 참조 MIN_DISK_LOB_VIEW_SC N VARCHAR(29) 아래 참조 COMMIT_SCN VARCHAR(29) 아래 참조 STATUS BIGINT 아래 참조 UPDATE_STATUS BIGINT 아래 참조 LOG_TYPE INTEGER 아래 참조 XA_COMMIT_STATUS BIGINT 아래 참조 XA_PREPARED_TIME VARCHAR(64) 아래 참조 FIRST_UNDO_NEXT_LSN_ LFGID INTEGER 아래 참조 FIRST_UNDO_NEXT_LSN_ FILENO INTEGER 아래 참조 FIRST_UNDO_NEXT_LSN_ OFFSET INTEGER 아래 참조 CURRENT_UNDO_NEXT_S N BIGINT 내부 용도 CURRENT_UNDO_NEXT_L SN_LFGID INTEGER 내부 용도 CURRENT_UNDO_NEXT_L SN_FILENO INTEGER 내부 용도 CURRENT_UNDO_NEXT_L SN_OFFSET INTEGER 내부 용도 LAST_UNDO_NEXT_LSN_L FGID INTEGER 아래 참조 LAST_UNDO_NEXT_LSN_F ILENO INTEGER 아래 참조 LAST_UNDO_NEXT_LSN_ OFFSET INTEGER 아래 참조 LAST_UNDO_NEXT_SN BIGINT 아래 참조 데이터 딕셔너리 241 Column name Type Description SLOT_NO INTEGER 아래 참조 UPDATE_SIZE BIGINT 아래 참조 ENABLE_ROLLBACK BIGINT 내부 용도 FIRST_UPDATE_TIME INTEGER 아래 참조 LOG_BUF_SIZE INTEGER 내부 용도 LOG_OFFSET INTEGER 내부 용도 SKIP_CHECK_FLAG BIGINT 내부 용도 SKIP_CHECK_SCN_FLAG BIGINT 내부 용도 DDL_FLAG BIGINT 아래 참조 TSS_RID BIGINT 아래 참조 RESOURCE_GROUP_ID INTEGER 사용하는 로그 파일 그룹(LFG)의 식별자 칼럼 정보 ID 해당 트랜잭션을 구분할 수 있는 번호이다. ID 의 값은 0 부터 2 32 - 1 까지 사용되며, 이 값들은 다시 재사용될 수 있다. SESSION_ID 트랜잭션에서 현재 사용하고 있는 세션 아이디를 나타낸다. 세션을 사용하고 있지 않는 경우에는 -1 을 보여준다. -1 이 나타나는 경우는 XA 환경에서 트랜잭션 브랜치가 prepare 된 상태이다. MEMORY_VIEW_SCN 알티베이스는 MVCC 를 사용하기 때문에 테이블에 대해 열리는 각 커서들에 대해 열린 시점을 나타내는 SCN 을 가지게 되어 있다. 이 항목은 현재 해당 트랜잭션에서 메모리 테이블에 대해 열려있는 커서의 View SCN 중 가장 작은 값은 나타낸다. 이 값이 2 63 을 가지면 어떤 커서도 열려 있지 않다는 것을 나타낸다. MIN_MEMORY_LOB_VIEW_SCN 현재 해당 트랜잭션에서 열린 메모리 Lob 커서 중 가장 오래된 커서의 SCN 을 나타낸다. 이 값이 263 을 가지면 어떤 커서도 열려있지 않다는 것을 의미한다. DISK_VIEW_SCN 현재 해당 트랜잭션에서 디스크 테이블에 대해 열려있는 커서의 View SCN 중 가장 작은 값은 나타낸다. 값의 범위는 242 ALTIBASE5 Administrator’s Manual MEMORY_VIEW_SCN 과 동일하다. MIN_DISK_LOB_VIEW_SCN 현재 해당 트랜잭션에서 열린 디스크 Lob 커서중 가장 오래된 커서의 SCN 을 나타낸다. 이 값이 263 을 가지면 어떤 커서도 열려있지 않다는 것을 의미한다. COMMIT_SCN 트랜잭션이 커밋한 시점의 시스템 SCN 을 나타낸다. 아직 커밋하지 않았다면 2^63 을 가진다. 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 데이터 딕셔너리 243 2: COMPLETE XA_PREPARED_TIME 글로벌 트랜잭션에 의한 로컬 트랜잭션이 PREPARE 명령을 글로벌 트랜잭션 관리자로부터 받은 시점을 나타낸다. FIRST_UNDO_NEXT_LSN_LFGID Undo Next LSN 의 로그 파일 그룹 식별자이다. FIRST_UNDO_NEXT_LSN_FILENO 트랜잭션이 처음 기록한 로그의 위치를 나타내는 LSN 중 파일 번호를 나타낸다. FIRST_UNDO_NEXT_LSN_OFFSET 트랜잭션이 처음 기록한 로그의 위치를 나타내는 LSN 중 파일 내에서의 위치(오프셋)를 나타낸다. LAST_UNDO_NEXT_LSN_LFGID 마지막 Undo Next LSN 의 로그 파일 그룹 식별자 LAST_UNDO_NEXT_LSN_FILENO 트랜잭션이 마지막 기록한 로그의 위치를 나타내는 LSN 중 파일 번호를 나타낸다. LAST_UNDO_NEXT_LSN_OFFSET 트랜잭션이 마지막 기록한 로그의 위치를 나타내는 LSN 중 파일 내에서의 위치(오프셋)를 나타낸다. LAST_UNDO_NEXT_SN 마지막 Undo Next LSN 이 가리키는 로그의 SN SLOT_NO 프로퍼티에 저장된 트랜잭션 풀 중 해당 트랜잭션 객체의 순번을 나타낸다. UPDATE_SIZE 트랜잭션이 수행한 갱신(Update) 연산에 의해 작성된 로그의 크기를 나타낸다. 이 값은 프로퍼티 중 LOCK_ESCALATION_MEMORY_SIZE 값과 비교되어, 이 값보다 더 커지면 이후로는 테이블에 X 록을 잡고 in-place update 방식으로 갱신을 수행하게 된다. FIRST_UPDATE_TIME 최초로 데이터베이스에 대한 변경이 일어난 시각이 기록된다. 244 ALTIBASE5 Administrator’s Manual DDL_FLAG DDL 을 수행 중인 트랜잭션인지 나타낸다. 0: non-DDL 1: DDL TSS_RID 디스크 테이블에 대한 갱신 연산 수행을 위해 얻은 TSS(Transaction Status Slot)의 물리적 위치를 나타낸다. 0 값이 아닐 경우에는 해당 트랜잭션은 디스크 테이블에 대해 갱신연산을 한번이라도 수행했음은 나타낸다. 데이터 딕셔너리 245 V$TRANSACTION_MGR 알티베이스 트랜잭션 관리자의 정보를 보여준다. Column name Type Description TOTAL_COUNT INTEGER 트랜잭션 총 개수 FREE_LIST_COUNT INTEGER 리스트 개수 BEGIN_ENABLE BIGINT 사용가능 플래그 ACTIVE_COUNT INTEGER 할당된 개수 SYS_MIN_DISK_VIEWSCN VARCHAR(29)트랜잭션 중의 가장 작은 디스크 뷰 SCN 칼럼 정보 TOTAL_COUNT 알티베이스는 시스템 시작시에 프로퍼티에 지정된 개수의 트랜잭션 객체들을 미리 생성해 두고, 이것을 트랜잭션 풀로 사용한다. 이 항목은 현재 알티베이스에서 생성한 트랜잭션의 총 개수를 나타낸다. FREE_LIST_COUNT 트랜잭션 풀을 분할 관리하는 리스트의 개수를 나타낸다. BEGIN_ENABLE 새로운 트랜잭션을 begin 할 수 있는지를 나타낸다. 0: disabled 1: enabled ACTIVE_COUNT 현재 할당되어 작업을 수행중인 트랜잭션 객체의 개수를 나타낸다. SYS_MIN_DISK_VIEWSCN 트랜잭션 중에서 가장 작은 디스크 뷰 SCN 을 나타낸다. 246 ALTIBASE5 Administrator’s Manual V$TSSEGS 언두 테이블스페이스에 존재하는 모든 TSS 세그먼트의 목록을 출력 한다. Column name Type Description SPACE_ID INTEGER 언두 테이블스페이스 ID SEG_PID INTEGER TSS 세그먼트 페이지 ID TXSEG_ENTRY_ID INTEGER 트랜잭션 세그먼트 ID CUR_ALLOC_EXTENT_RID BIGINT TSS 세그먼트에서 현재 사용중인 익스텐트 RID CUR_ALLOC_PAGE_ID INTEGER TSS 세그먼트에서 현재 사용중인 페이지 ID TOTAL_EXTENT_COUNT BIGINT TSS 세그먼트의 총 익스텐트 개수 TOTAL_EXTDIR_COUNT BIGINT TSS 세그먼트의 총 익스텐트 디렉토리 개수 PAGE_COUNT_IN_EXTENT INTEGER 하나의 익스텐트의 총 페이지 개수 칼럼 정보 SPACE_ID 언두 테이블스페이스 ID 를 나타낸다. SEG_PID TSS 세그먼트 페이지 ID 를 나타낸다. TXSEG_ENTRY_ID 트랜잭션 세그먼트 ID 를 나타낸다. CUR_ALLOC_EXTENT_RID TSS 세그먼트에서 현재 사용중인 익스텐트 RID 를 나타낸다. CUR_ALLOC_PAGE_ID TSS 세그먼트에서 현재 사용중인 페이지 ID 를 나타낸다. TOTAL_EXTENT_COUNT TSS 세그먼트의 총 익스텐트 개수를 나타낸다. TOTAL_EXTDIR_COUNT TSS 세그먼트의 총 익스텐트 디렉토리 개수를 나타낸다. 데이터 딕셔너리 247 PAGE_COUNT_IN_EXTENT 하나의 익스텐트의 총 페이지 개수를 나타낸다. 248 ALTIBASE5 Administrator’s Manual V$TXSEGS 트랜잭션에 바인딩되어 온라인 상태로 있는 해당 트랜잭션의 세그먼트 목록을 출력한다. Column name Type Description ID INTEGER 트랜잭션 세그먼트의 ID TRANS_ID INTEGER 세그먼트를 바인딩한 트랜잭션의 ID MIN_DISK_VIEW_SCN VARCHAR(29) 해당 트랜잭션의 최소 디스크 뷰 SCN COMMIT_SCN VARCHAR(29) 해당 트랜잭션의 커밋 SCN FIRST_DISK_VIEW_SCN VARCHAR(29) 해당 트랜잭션의 첫번째 디스크 뷰 SCN TSS_RID BIGINT 트랜잭션 TSS RID TSSEG_EXTENT_RID BIGINT TSS를 할당한 TSS 세그먼트의 익스텐트 RID FST_UDSEG_EXTENT_RID BIGINT 트랜잭션이 사용한 언두 세그먼트의 첫번째 익스텐트 RID LST_UDSEG_EXTENT_RID BIGINT 트랜잭션이 사용한 언두 세그먼트의 마지막 익스텐트 RID FST_UNDO_PAGEID INTEGER 트랜잭션이 기록한 첫번째 언두 레코드의 페이지 ID FST_UNDO_SLOTNUM SMALLINT 트랜잭션이 기록한 첫번째 언두 레코드의 슬롯 번호 LST_UNDO_PAGEID INTEGER 트랜잭션이 기록한 마지막 언두 레코드의 페이지 ID LST_UNDO_SLOTNUM SMALLINT 트랜잭션이 기록한 마지막 언두 레코드의 슬롯 번호 칼럼 정보 ID 트랜잭션 세그먼트의 ID 를 나타낸다. TRANS_ID 세그먼트를 바인딩한 트랜잭션의 ID 를 나타낸다. MIN_DISK_VIEW_SCN 트랜잭션의 최소 디스크 뷰 SCN 을 나타낸다. 데이터 딕셔너리 249 COMMIT_SCN 해당 트랜잭션의 커밋 SCN 을 나타낸다. FIRST_DISK_VIEW_SCN 해당 트랜잭션의 첫번재 디스크 뷰 SCN 을 나타낸다. TSS_RID 해당 트랜잭션이 할당받은 TSS(Transaction Status Slot)의 RID 를 나타낸다. TSSEG_EXTENT_RID TSS 를 할당한 TSS 세그먼트의 익스텐트 RID 룰 나타낸다. FST_UDSEG_EXTENT_RID 트랜잭션이 사용한 언두 세그먼트의 첫번째 익스텐트 RID 룰 나타낸다. LST_UDSEG_EXTENT_RID 트랜잭션이 사용한 언두 세그먼트의 마지막 익스텐트 RID 룰 나타낸다. FST_UNDO_PAGEID 해당 트랜잭션이 갱신때 기록했던 첫번째 언두 레코드의 페이지 ID 를 나타낸다. FST_UNDO_SLOTNUM 해당 트랜잭션이 갱신때 기록했던 첫번째 언두 레코드의 페이지 내에서의 슬롯 번호를 나타낸다. LST_UNDO_PAGEID 해당 트랜잭션이 갱신때 기록했던 마지막 언두 레코드의 페이지 ID 를 나타낸다. LST_UNDO_SLOTNUM 해당 트랜잭션이 갱신때 기록했던 마지막 언두 레코드의 페이지 내에서의 슬롯 번호를 나타낸다. 250 ALTIBASE5 Administrator’s Manual V$UDSEGS 언두 테이블스페이스에 존재하는 모든 언두(UNDO) 세그먼트의 목록 을 출력한다. Column name Type Description SPACE_ID INTEGER 언두 테이블스페이스 ID SEG_PID INTEGER 언두 세그먼트 페이지 ID TXSEG_ENTRY_ID INTEGER 트랜잭션 세그먼트 ID CUR_ALLOC_EXTENT_RID BIGINT 언두 세그먼트에서 현재 사용중인 익스텐트 RID CUR_ALLOC_PAGE_ID INTEGER 언두 세그먼트에서 현재 사용중인 페이지 ID TOTAL_EXTENT_COUNT BIGINT 언두 세그먼트의 총 익스텐트 개수 TOTAL_EXTDIR_COUNT BIGINT 언두 세그먼트의 총 익스텐트 디렉토리 개수 PAGE_COUNT_IN_EXTENT INTEGER 하나의 익스텐트의 총 페이지 개수 칼럼 정보 SPACE_ID 언두 테이블스페이스 ID 를 나타낸다. SEG_PID 언두 세그먼트 페이지 ID 를 나타낸다. TXSEG_ENTRY_ID 트랜잭션 세그먼트 ID 를 나타낸다. CUR_ALLOC_EXTENT_RID 언두 세그먼트에서 현재 사용중인 익스텐트 RID 를 나타낸다. CUR_ALLOC_PAGE_ID 언두 세그먼트에서 현재 사용중인 페이지 ID 를 나타낸다. TOTAL_EXTENT_COUNT 언두 세그먼트의 총 익스텐트 개수를 나타낸다. TOTAL_EXTDIR_COUNT 언두 세그먼트의 총 익스텐트 디렉토리 개수를 나타낸다. 데이터 딕셔너리 251 PAGE_COUNT_IN_EXTENT 하나의 익스텐트의 총 페이지 개수를 나타낸다. 252 ALTIBASE5 Administrator’s Manual V$UNDO_BUFF_STAT Undo table space 의 버퍼 풀 관련 통계 정보를 보여준다. Column name Type Description READ_PAGE_COUNT BIGINT 아래 참조 GET_PAGE_COUNT BIGINT 참조 횟수 FIX_PAGE_COUNT BIGINT fix page 횟수 CREATE_PAGE_COUNT BIGINT 아래 참조 HIT_RATIO DOUBLE 버퍼 프레임의 히트율 칼럼 정보 READ_PAGE_COUNT 버퍼 초기화 이후 페이지를 디스크로부터 읽은 총 회수를 나타낸다. GET_PAGE_COUNT 버퍼 초기화 이후 버퍼 매니저에 페이지를 요청한 총 회수를 나타 F 낸다. 버퍼 매니저는 만약 페이지가 버퍼에 있다면 이 요청에 대해 버퍼의 페이지를 리턴하고, 그렇지 않으면 디스크로부터 페이지를 버퍼에 읽어온 후 리턴한다. FIX_PAGE_COUNT 버퍼 초기화 이후 버퍼 매니저에 언두 페이지를 래치 없이 요청한 총 회수를 나타낸다. CREATE_PAGE_COUNT 버퍼 초기화 이후 트랜잭션이 버퍼 매니저에 페이지 생성을 요청한 총 회수를 나타낸다. 이 요청에 대해 버퍼 매니저는 버퍼에서 빈 BCB 를 확보한 후 페이지를 초기화 하여 리턴한다. 디스크 IO 는 이 연산에서 발생하지 않는다. 데이터 딕셔너리 253 V$VERSION 데이터베이스 버전 관련 정보를 보여준다. Column name Type Description PRODUCT_VERSION VARCHAR(128) 제품 버전 Ex) 5.3.3.1 PKG_BUILD_PLATFORM_I NFO VARCHAR(128) 패키지가 빌드된 플랫폼 PRODUCT_TIME VARCHAR(128) 패키지가 빌드된 시간 SM_VERSION VARCHAR(128) 저장 관리자(SM) 버전 META_VERSION VARCHAR(128) 메타 테이블 버전 PROTOCOL_VERSION VARCHAR(128) 프로토콜 버전 REPL_PROTOCOL_VERSIO N VARCHAR(128) 리플리케이션 프로토콜 버전 칼럼 정보 PRODUCT_VERSION 알티베이스 제품의 버전 정보를 나타낸다. PKG_BUILD_PLATFORM_INFO 패키지가 현재 설치된 플랫폼 정보를 나타낸다. PRODUCT_TIME 패키지가 현재 플랫폼에 설치된 날짜와 시간을 나타낸다. SM_VERSION 저장 관리자의 버전을 나타낸다. 저장 구조가 변경될 때마다 버전이 변경된다. META_VERSION 데이터베이스 정보를 관리하는 메타 테이블에 대한 버전을 나타낸다. PROTOCOL_VERSION 데이터베이스의 통신을 위한 프로토콜 버전을 나타낸다. REPL_PROTOCOL_VERSION 이중화를 위한 프로토콜 버전을 나타낸다. 254 ALTIBASE5 Administrator’s Manual V$WAIT_CLASS_NAME 알티베이스 서버상의 대기 이벤트들을 그룹화 하기 위한 정보를 보여 준다. 다양한 대기 이벤트들을 분류하기 위해 상위 개념인 대기 클래 스를 사용하며 이 성능뷰를 통하여 대기 클래스들을 확인할 수 있다. Column name Type Description WAIT_CLASS_ID INTEGER 대기 클래스의 ID WAIT_CLASS VARCHAR(128) 대기 클래스 이름 칼럼 정보 WAIT_CLASS_ID 대기하고 있는 이벤트의 클래스 ID를 나타낸다. WAIT_CLASS 대기 이벤트 그룹화를 위한 상위 개념인, 대기 클래스를 나타낸다. 알티베이스는 대기하는 이벤트를 아래와 같이 8개의 대기 클래스로 대기 이벤트들을 분류한다. WAIT_CL ASS_ID WAIT_CLASS Description 0 Other 기타의 대기 클래스들을 포함한 다. 1 Administrative SYSDBA 명령으로 사용자가 대 기하게 되는 대기 이벤트를 포함 한다. 2 Configuration 데이타베이스 자원에 대한 부적절 한 설정으로 인해 대기하는 대기 이벤트를 포함한다. 3 Concurrency 데이타베이스 내부 자원에서 대기 하는 대기 이벤트를 포함한다. 4 Commit REDO 로그가 로그 파일에 Sync 되기를 대기하는 대기 이벤트를 포함한다. 5 Idle 세션의 작업이 요청되기를 기다리 며 대기하는 대기 이벤트를 포함 한다. 6 User I/O 사용자 I/O를 대기하는 대기이벤 트를 포함한다. 7 System I/O시스템 I/O를 대기하는 대기 이 데이터 딕셔너리 255 WAIT_CL ASS_ID WAIT_CLASS Description 벤트를 포함한다. 256 ALTIBASE5 Administrator’s Manual V$XID DBMS 에 현존하는 분산 트랜잭션의 ID 인 XID 의 목록을 보여준다. 분산 트랜잭션 ID 란 XA 에서 분산 트랜잭션이 시작되었을 때 TM(Transaction Manager) 내부에서 트랜잭션 ID 를 생성하는 것으로, DB 노드들인 RM(Resource Manager)에게 전달한다. Column name Type Description XID_VALUE VARCHAR(256) XID 값을 문자열로 반환 ASSOC_SESSION_ID INTEGER XID 객체와 연계된 세션 번호 TRANS_ID INTEGER XID 객체 안에 있는 분산 트랜잭션 ID STATE VARCHAR(24) XID 객체의 상태 STATE_START_TIME INTEGER XID 객체의 상태가 설정된 시간 STATE_DURATION BIGINT XID 객체의 상태가 설정된 이후의 경과된 시간 TX_BEGIN_FLAG VARCHAR(9) XID 안에 있는 트랜잭션 ID의 시작 여부 REF_COUNT INTEGER XID 객체를 현재 참조하고 있는 횟 수 칼럼 정보 XID_VALUE XID 값을 문자열로 변환한 값을 나타낸다. ASSOC_SESSION_ID XID 객체와 연계된 세션 번호로써, 해당 XID 를 XA_START 시킨 세션이다. TRANS_ID XID 객체 안에 있는 분산 트랜잭션의 아이디를 나타낸다. STATE XID 객체의 수행된 상태를 나타낸다. 상태에 대한 값은 다음과 같다. y IDLE : 해당 XID에 대하여 연계된 세션이 없는 상태 y ACTIVE : 해당 XID에 대하여 연계된 세션이 있는 상태. 즉 XA_START된 경우 y PREPARED : 2PC(Phase Commit) 과정에서 prepare 명령을 수신한 상태 y HEURISTICALLY_COMMITED : DBMS가 XID의 트랜잭션 데이터 딕셔너리 257 브랜치를 강제로 커밋한 상태 y HEURISTICALLY_ROLLBACKED : DBMS가 XID의 트랜잭션 브랜치를 강제로 롤백한 상태 y NO_TX : XID가 초기화된 상태이거나 XID의 트랜잭션 브랜치를 커밋 또는 롤백한 상태 STATE_START_TIME XID 객체의 수행 상태가 설정된 시간을 나타낸다. STATE_DURATION XID 객체의 상태가 설정된 이후의 경과 시간을 나타낸다. TX_BEGIN_FLAG XID 객체 안에 있는 트랜잭션 ID 가 RM 에서 트랜잭션 브랜치가 시작된 여부를 나타낸다. y BEGIN : 시작된 상태 y NOT BEGIN : 시작되지 않은 상태 REF_COUNT 해당 XID 객체를 현재 참조하고 있는 횟수를 나타낸다. 데이터베이스 객체 및 권한 259 4. 데이터베이스 객체 및 권한 이장에서는 알티베이스 데이터베이스 내의 객체의 생성, 운영방법 및 사용자와 객체 권한 관리 체계에 대해서 설명한다. 260 ALTIBASE5 Administrator’s Manual 데이터베이스 객체 개요 데이터베이스 객체는 특정 스키마에 속하여 관리되는 스키마 객체와 스키마와 관계없이 데이터베이스 전체에서 관리되는 비스키마 객체로 구분할 수 있다. 이 장에서는 스키마 객체와 비스키마 객체를 구분하고 각각에 포함되는 데이터베이스 객체에 대해 설명한다. 스키마 객체 스키마란 데이터 또는 객체들의 논리적 집합으로 한 사용자는 하나의 스키마를 소유하고 SQL 문에 의해 관리한다. 이러한 스키마에 포함되는 객체를 스키마 객체라고 하고 알티베이스는 다음과 같은 스키마 객체를 제공한다. 테이블(Table) 테이블은 가장 기본적인 데이터 저장 단위로 칼럼들로 구성된 레코드들의 집합이다. 알티베이스 테이블은 데이터의 저장 공간에 따라 메모리 테이블과 디스크 테이블로 구별되고, 생성자에 따라 시스템이 생성하고 관리하는 시스템 테이블과 사용자가 생성하는 일반 테이블로 구별될 수도 있다. 또한 이중화 대상 테이블의 경우 테이블 관리가 특별하며 대용량 테이블의 경우에도 주의를 요하는 사항들이 있다. 이에 대해서는 테이블 관리에서 자세히 설명한다. 제약조건(Constraint) 제약 조건이란 테이블의 데이터 삽입 또는 변경 시 제약 사항을 설정하여 데이터의 일관성을 유지할 수 있도록 하는 조건을 의미한다. 제약조건의 대상에 따라 칼럼 제약조건과 테이블 제약조건으로 구별할 수 있고, 제약 사항에 따라 다음과 같은 종류의 제약조건을 제공한다. y NOT NULL / NULL 제약조건 y 유일 키(unique key) 제약조건 y 주 키(primary key) 제약조건 y 외래 키(foreign key) 제약조건 y TIMESTAMP 제약조건 이에 대해서는 제약조건 관리에서 자세히 설명한다. 인덱스(Index) 인덱스는 테이블 내 레코드들의 빠른 접근이 가능하도록 하는 데이터베이스 객체 및 권한 261 구조체로 테이블에 인덱스를 생성하여 DML 문의 처리 성능을 향상시킬 수 있다. 이에 대해서는 인덱스 관리에서 자세히 설명한다. 뷰(View) 뷰(View)란 실제 데이터 자체는 포함하지 않고, 하나 이상의 테이블 또는 뷰를 기반으로 한 논리적 테이블(logical table)을 의미한다. (알티베이스는 변경가능 뷰(Updatable view)와 머티어리얼라이즈 뷰(materialized view)는 제공하지 않는다.) 이에 대해서는 뷰 관리에서 자세히 설명한다. 시퀀스(Sequence) 알티베이스는 유일 키를 생성하기 위해 키생성자로 시퀀스를 제공한다. 이에 대해서는 시퀀스 관리에서 자세히 설명한다. 시노님(Synonym) 테이블, 시퀀스, 뷰, 저장 프로시저 및 저장 함수에 대한 별칭(alias)을 부여하여 객체 사용에 대한 투명성을 부여할 수 있는 시노님을 제공한다. 이에 대해서는 시노님 관리에서 자세히 설명한다. 저장 프로시저 및 저장 함수(Stored Procedure or Function) 저장 프로시저(Stored Prodedure)란 SQL 문들과 흐름 제어문, 할당문, 오류 처리 루틴 등을 이용해 전체 업무 절차를 프로그래밍하여 하나의 모듈로 만든 후 데이터베이스에 영구적으로 저장해 두고, 모듈 이름만을 호출하여 전체 업무 절차를 서버에서 한번에 수행하는 데이터베이스 객체이다. 하나의 리턴 값을 가지지 않느냐와 가지느냐에 따라 저장 프로시저와 저장 함수로 구별된다. 이에 대해서는 저장 프로시저 및 저장 함수 관리에서 자세히 설명한다. 데이터베이스 트리거(Database Triger) 트리거란 테이블에 데이터가 삽입, 삭제, 또는 갱신될 때 시스템에 의해 묵시적으로 작동되어 특정 작업 절차를 자동으로 수행할 수 있도록 하는 저장 프로시저다. 사용자는 테이블에 대해 제약조건과 트리거를 정의하여 데이터의 일관성을 유지할 수 있다. 이에 대해서는 트리거 관리에서 자세히 설명한다. 데이터베이스 링크(Database Link) 데이터베이스 링크는 지역적으로 분리되어 있으나 네트워크로 262 ALTIBASE5 Administrator’s Manual 연결된 데이터 서버들을 연동하여 개별 데이터들을 통합, 하나의 결과를 생성할 수 있게 한다. 이에 대해서는 데이터베이스 링크 관리에 대해서 자세히 설명한다. 비스키마 객체 특정 스키마에 소속되지 않고 전체 데이터베이스 수준에서 관리되는 객체를 비스키마 객체라고 하고 알티베이스는 다음과 같은 비스키마 객체를 제공한다. 디렉토리(Directory) 저장프로시저의 파일 제어 기능은 운영 체제의 텍스트 파일에 대한 읽기 및 쓰기 기능을 제공한다. 이 기능을 이용하여 사용자는 저장프로시저 실행에 대한 별도의 메시지 등을 파일에 남길 수도 있으며, 파일로 결과를 보고하거나 파일로부터 데이터를 읽어와 테이블에 삽입하는 등 다양한 작업을 수행할 수 있다. 이러한 저장프로시저 파일 제어 기능에서 사용하는 파일들을 저장하는 디렉토리 객체이다. 디렉토리에 대한 자세한 기능과 디렉토리 관리에 대해서는 SQL Users Manual 을 참조한다. 저장프로시저의 파일 제어 기능에 대해서는 Stored Procedure Users Manual 을 참조한다. 이중화(Replication) 이중화는 시스템이 자동으로 한 지역서버에서 원격 서버로 데이터를 전송해 다른 서버들간의 테이블 데이터를 동일하게 유지해 줄 수 있도록 하는 객체이다. 이중화에 대한 자세한 기능과 이중화 관리에 대해서는 Replication Users Manual 을 참조한다. 테이블스페이스(Tablespace) 테이블스페이스는 가장 큰 논리적 데이터 저장 단위로 데이터베이스는 여러 개의 테이블스페이스 단위로 나뉘어져 관리된다. 테이블스페이스는 크게 저장공간을 기준으로 메모리 테이블스페이스(SYS_TBS_MEMORY)와 이를 제외한 디스크 테이블스페이스로 구분되며 최초 데이터베이스 생성시에 만들어지며 삭제될 수 없는 SYSTM 테이블스페이스와 필요에 따라 생성과 삭제가 자유롭고 테이블과 인덱스만을 저장할 수 있는 사용자(USER) 테이블스페이스로 종류를 구별한다. 데이터베이스 객체 및 권한 263 테이블스페이스 관리에 대한 자세한 내용은 테이블스페이스 부분을 참조한다. 사용자(User) 스키마의 소유자로 알티베이스 접속을 위해서는 사용자 계정이 필요하다. 사용자는 시스템에 의해 생성되어 전체 시스템 관리자인 시스템 사용자와 일반 사용자로 구별된다. 일반 사용자의 경우 데이터베이스에 접근하여 데이터를 조작하기 위해서는 적절한 권한 관리를 요한다. 이에 대해서는 사용자 관리와 권한 관리에서 자세히 설명한다. 264 ALTIBASE5 Administrator’s Manual 테이블 관리 테이블은 가장 기본적인 데이터 저장 단위로써 칼럼들로 구성된 레코드들의 집합이다. 이 절에서는 테이블과 관련된 용어 설명, 테이블 관리 개념과 방법들에 대해 설명한다. 메모리 테이블과 디스크 테이블 테이블의 저장 공간에 따라 메모리 테이블과 디스크 테이블로 구별된다. 테이블 생성 시 테이블이 속한 테이블스페이스가 메모리 테이블스페이스인지 디스크 테이블스페이스인지에 따라 메모리 테이블과 디스크 테이블로 생성된다. 시스템 테이블과 일반 사용자 테이블 시스템이 내부적으로 생성하고 관리하는 시스템 테이블과 일반 사용자에 의해 생성되고 관리되는 일반 사용자 테이블로 테이블의 종류를 분류할 수 있다. 시스템 테이블은 데이터 딕셔너리로, 데이터베이스 객체 정보를 저장하는 메타 테이블과 시스템 프로세스 정보를 저장하는 프로세스 테이블로 나뉘어진다. 프로세스 테이블은 다시 고정 테이블과 성능 뷰로 나뉘어진다. 이에 대해서는 데이터 딕셔너리 장에서 자세히 설명한다. 대용량 메모리 테이블 대용량 메모리 테이블의 경우 SQL 문 수행 시 다음과 같은 주의를 요한다. 대용량 메모리 테이블에 DDL 수행하기 대용량 테이블에 DDL 문을 수행하고자 하는 경우 ADD COLUMN 이나 DROP COLUMN 을 직접 수행하는 것 보다 iLoader 유틸리티를 이용해서 데이터를 다운로드 받고, 해당 테이블을 새로운 스키마로 재 생성한 후에 다운로드 받은 데이터를 iLoader 유틸리티를 이용해서 업로드하는 방식을 권장한다. 대용량 메모리 테이블에 DML 수행하기 데이터 크기가 크지 않은 테이블에 대해 DML 을 수행하는 것은 데이터베이스 객체 및 권한 265 운영자가 잘못된 데이터 조작을 하지 않는 한 알티베이스의 성능이나 운용 상에 있어서 크게 문제를 발생시키지 않는다. 그러나 레코드 개수가 많은 대용량의 테이블에 대해 하나의 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 가능성 트랜잭션이 생성하는 로그 파일들은 이중화 또는 재시작 회복을 위해 필요한 로그들을 제외하고는 체크포인트 수행시 디스크에서 삭제된다. 재시작 회복에 필요한 로그 파일은 체크포인트 검사 시 수행 중이던 트랜잭션들이 생성한 로그 파일 중 최소 로그 파일을 의미한다. 따라서, 장기간 수행 중인 트랜잭션이 존재하면 체크포인트가 발생하더라도 로그 파일들은 재시작 회복을 위해 계속 지울 수 없는 상태로 남아있기 때문에 로그 파일이 저장되는 파일 시스템에 더 이상 로그를 저장하지 못하는 상태가 될 수 있다. 266 ALTIBASE5 Administrator’s Manual 페이지 리스트 다중화 메모리 테이블의 경우 로그파일그룹(Log File Group)에 따라 사용하는 자원 또한 병렬화되어야 한다. 따라서 LFG 의 개수에 따라 테이블에서 사용하는 페이지 리스트 역시 같은 개수로 다중화되게 된다. 로그파일그룹 기능에 대한 상세한 정보는 이 매뉴얼 ‘알티베이스 튜닝’ 장의 해당 내용을 참조한다. 이중화된 테이블 알티베이스는 이중화 대상인 테이블에 대하여 DDL 문의 실행이 가능하다. 그러나 DDL 구문을 실행하기 위해서는 반드시 다음과 같이 프로퍼티를 설정해야 한다. y REPLICATION_DDL_ENABLE 프로퍼티를 1로 설정한다. y ALTER SESSION SET REPLICATION으로 설정할 수 있는 REPLICATION 세션 프로퍼티를 NONE 이외의 값으로 설정한다. 이중화 테이블에 대한 자세한 내용은 Replication User’s Manual 을 참조한다. 생성 테이블은 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; 메모리 테이블에서 칼럼 정의 시 주의 사항 데이터베이스 객체 및 권한 267 VARCHAR 데이터 타입의 경우 FIXED/VARIABLE 속성을 사용자가 지정할 수 있다. 사용자가 이 속성을 지정하지 않은 경우에 데이터베이스는 내부적으로 특정 길이(126 byte) 이하일 경우 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(10) VARIABLE ); Record Headernamedescription real data of description 20 13 16 INSERT INTO item VALUES('msjung', 'variable test'); [그림 4-1] VARCHAR 칼럼 구조 테이블 item 의 칼럼 name 은 varchar(20) FIXED 로 선언되었기 때문에 실제 삽입되는 값인 msjung 의 길이가 6 이라 하더라도 레코드 내에서 20 바이트만큼 그 공간을 할당받는다. 테이블 item 의 칼럼 description 은 varchar(1000) VARIABLE 로 선언되었기 때문에 실제 삽입되는 값인 variable test 의 길이인 13 바이트만큼 그 공간을 할당받으며 그 공간은 레코드 내의 268 ALTIBASE5 Administrator’s Manual 연속적인 공간이 아니라 위 그림처럼 별도의 공간 2 을 할당받는다. Varchar VARIABLE 로 선언된 칼럼은 실제 데이터가 저장된 곳의 위치 정보를 유지하기 위해 별도의 정보를 레코드 내에 유지하며 그 길이는 16 이다. 따라서 위 그림의 예제에서 description 칼럼의 값을 저장하기 위해 실제 사용되는 공간은 29 바이트이다. 변경 테이블 정의는 ALTER TABLE 문, RENAME 문을 사용하여 다음과 같은 테이블 정의를 변경할 수 있다. y 테이블 이름 y 새로운 칼럼 추가 y 기존 칼럼 삭제 y 칼럼 기본 값 y 칼럼 이름 y 제약 조건 추가 y 제약 조건 삭제 y 메모리 테이블 COMPACT y 최대 허용 레코드 수 y 인덱스 활성 및 비활성 예제 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; 2 Varchar variable 로 선언된 칼럼의 실제 데이터를 저장하기 위해 데이터 크기만큼 매번 메모리 할당을 받게 되는 경우 성능에 영향을 줄 수 있으므로 알티베이스는 4K, 8K, 16K 등 내부적으로 정해진 길이의 슬롯을 미리 준비하며, 데이터 입력 시 실제 데이터를 저장할 수 있는 최적의 크기를 갖는 슬롯을 선택하여 varchar variable 로 선언된 칼럼의 실제 데이터를 저장한다. 데이터베이스 객체 및 권한 269 전체 레코드 삭제 테이블의 레코드는 DELETE 문을 사용해 삭제할 수도 있지만 TRUNCATE TABLE 문을 이용해 삭제할 수도 있다. DELETE 문은 내부적으로 레코드를 건건이 삭제하는 것이고, TRUNCATE TABLE 문은 DDL 문으로 내부적으로 DROP TABLE 문을 수행하고 같은 정의의 테이블을 재생성한다. 따라서 TRUNCATE TABLE 문을 수행하면 테이블 수준의 록(lock)이 잡히며 TRUNCATE TABLE 문이 성공적으로 수행된 이후에는 ROLLBACK 문을 사용해 삭제된 데이터를 복구할 수 없다. 테이블 레코드 조작 테이블의 레코드들은 DML 문을 사용하여 조작할 수 있다. y INSERT y DELETE y UPDATE y SELECT 위에서 언급한 바와 같이 알티베이스 운용 중에 대용량의 데이터에 대해 bulk update/delete 를 수행하는 것은 위험 요소를 갖고 있으므로 ODBC 혹은 전처리기 프로그램을 이용하여 응용프로그램 작성 시 레코드 별로 update/delete 후 커밋하도록 하는 것이 바람직하다. 다음은 bulk update/delete 를 피하고 레코드별로 update 를 수행하는 C/C++ Precompiler 프로그램 작성 예이다. 270 ALTIBASE5 Administrator’s Manual (a) isql 상에서 bulk-update 수행 isql>update t1 set col1=2 where col1 > 1000; (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 을 참조한다. y CREATE TABLE y ALTER TABLE y RENAME TABLE y TRUNCATE TABLE y LOCK TABLE y INSERT y DELETE y UPDATE y SELECT 데이터베이스 객체 및 권한 271 큐 테이블 관리 알티베이스는 메시지 큐잉 기능을 이용하여 데이터베이스와 사용자 프로그램간의 비동기 데이터 통신을 지원한다. 이 때 사용되는 큐 테이블은 데이터베이스 오브젝트의 하나로써 다른 데이터베이스 테이블과 마찬가지로 DDL 과 DML 로 제어할 수 있다. 생성 사용자는 CREATE QUEUE 문장을 이용해서 큐를 생성할 수 있다. 데이터베이스는 큐의 이름에 해당하는 테이블을 생성하고 이를 큐 테이블이라고 부른다. 큐 테이블은 다음과 같은 구조를 가진다. Column name Type LengthDefault Description MSGID BIGINT 8 - 메시지 식별자 CORRID INTEGE R 4 0 사용자가 지정 한 메시지 식별 자 MESSAGE VARCHA R Message length - 메시지 ENQUEUE_TIME DATE 8 SYSDAT E 메시지 enqueue 시간 큐 테이블의 칼럼 명이나 테이블 명은 사용자가 임의로 변경할 수 없으며, MSGID 칼럼에는 자동으로 주요 키(Primary Key)가 생성된다. MSGID 를 관리하기 위해서 데이터베이스는 내부적으로 QUEUE 이름_NEXT_MSG_ID 라는 이름의 시퀀스를 생성해 MSGID 를 유일하게 관리한다. 사용자는 SYSTEM_SYS_TABLES_ 메타 테이블에서 테이블 타입인 것들을 조회하면 해당 시퀀스에 대한 정보를 조회할 수 있다. 시퀀스는 큐 테이블이 삭제될 때까지 유지되어야 하기 때문에 DROP SEQUENCE 문장으로 임의 삭제할 수 없다. 큐 테이블은 SYSTEM.SYS_TABLES 에서 테이블 type Q 로 저장된다. 사용자는 필요에 따라서 CREATE INDEX 문장을 이용해서 큐 테이블에 인덱스를 생성할 수 있다. 예제 CREATE QUEUE Q1(40); 변경 272 ALTIBASE5 Administrator’s Manual CREATE QUEUE 문장으로 생성된 큐 테이블은 ALTER TABLE 등의 문장으로 구조를 변경할 수 없다. 오직 DROP QUEUE 문장으로 삭제될 수 있다. 단, 사용자는 ENQUEUE/DEQUEUE, DELETE, SELECT 등의 문장으로 데이터 조작은 가능하다. 삭제 큐 테이블은 DROP QUEUE 문을 사용하여 삭제할 수 있다. 예제 DROP QUE Q1; 데이터 삭제 큐에 적재된 메시지만 모두 삭제하고자 하는 경우에는 TRUNCATE TABLE 문장을 이용할 수 있다. 예제 TRUNCATE TABLE Q1; 테이블 데이터 조작 큐 테이블의 레코드들은 다음과 같은 DML 문을 사용하여 조작할 수 있다. y ENQUEUE y DEQUEUE y DELETE y SELECT 관련 SQL 문 다음과 같은 SQL 문을 제공하며 이에 대한 자세한 설명은 SQL Users Manual 을 참조한다. y CREATE QUEUE y DROP QUEUE y ENQUEUE y DEQUEUE 데이터베이스 객체 및 권한 273 제약조건 관리 제약 조건이란 테이블의 데이터 삽입 또는 변경 시 제약 사항을 설정하여 데이터의 일관성을 유지할 수 있도록 하는 조건으로 이 절에서는 제약조건의 종류와 관리 방법에 대해 설명한다. 제약조건의 종류 NOT NULL / NULL 제약조건 칼럼에 NULL 을 삽입할 수 없는 제약조건으로 칼럼 단위로 정의할 수 있다. NULL 제약조건은 NULL 도 허용하는 것으로 칼럼에 대해 NOT NULL 제약조건을 명시하지 않으면 기본적으로 NULL 을 허용한다. 유일 키(unique key) 제약조건 하나 이상의 칼럼에 대해 정의할 수 있는 제약조건으로 칼럼 또는 칼럼의 조합에 대해 중복 값을 삽입할 수 없는 제약조건이다. 유일 키 제약조건을 정의하면 내부적으로 유일 키 인덱스가 생성된다. 프라이머리 키(primary key) 제약조건 프라이머리 키 제약조건은 유일 키 제약조건에 NOT NULL 제약조건까지 존재하는 제약조건이다. 하나 이상의 칼럼에 대해 프라이머리 키 제약조건을 정의할 수 있고 내부적으로 유일 키 인덱스가 생성되며 프라이머리 키에 포함되는 모든 칼럼은 NULL 을 삽입할 수 없다. 외래 키(foreign key) 제약조건 참조 무결성 제약조건(referential integrity constraint)으로 참조 관계에 있는 테이블 간의 데이터 일관성을 유지할 수 있도록 해 주는 제약조건이다. TIMESTAMP 제약조건 칼럼의 값으로 레코드의 삽입 또는 갱신 시 시스템 시간 값을 설정하는 제약조건이다. 주로 이중화 대상 테이블의 하나의 칼럼에 대해 정의해 사용한다. 칼럼 제약조건과 테이블 제약조건 칼럼 정의 시 하나의 칼럼에 대해 정의한 제약조건을 칼럼 제약조건이라 하고 여러 개의 칼럼들에 대해 하나의 제약조건을 테이블 정의 하단 부분에 정의하는 것을 테이블 제약조건이라고 274 ALTIBASE5 Administrator’s Manual 한다. 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 을 참조한다. y CREATE TABLE y ALTER TABLE 데이터베이스 객체 및 권한 275 인덱스 관리 인덱스는 테이블 내 레코드들의 빠른 접근이 가능하도록 하는 구조체이다. 이 절에서는 인덱스의 종류와 속성, 관리 및 활용 방법에 대해 설명한다. 인덱스 종류 알티베이스는 BTREE, RTREE, TD RTREE 의 타입의 인덱스를 제공한다. RTREE 와 TD RTREE 는 다차원 인덱스로서 공간 질의 시 이용된다. B-tre 인덱스 타입 공간 데이터 타입인 GEOMETRY 의 칼럼을 제외한 모든 타입은 B- Tree 의 인덱스가 생성된다. B-Tree 는 전통적으로 DBMS 에서 사용해온 인덱스 구조로써 현재까지 많은 연구를 통해 여러가지 변이를 가지는데, 알티베이스는 이중 B + -Tree 형태의 인덱스를 지원한다. B + -Tree 는 인덱스의 최하위 레벨에 존재하는 리프 노드(Leaf Node)들과, 최상위 레벨에 존재하는 루트 노드(Root Node), 그리고 리프와 루트의 사이에 존재하는 인터널 노드(Internal Node)들로 구성된다. 키 값들은 모두 리프 노드에만 존재하며, 루트와 인터널 노드에는 좌측 자식 노드와 우측 자식 노드의 중간 값인 세퍼레이터(Separator) 키들을 가진다. R-tre 인덱스 타입 공간 데이터 타입인 GEOMETRY 칼럼에는 R-Tree 가 생성된다. R-Tree 는 각 공간 객체를 감싸는 최소 사각형인 MBR(Minimum Bounding Rectagle)을 이용하여 일차로 조건 필터링(Filtering)을 수행한 후, 이 결과로 남은 객체에 대해 정확한 인덱스 검색 조건을 체크하는 리파인먼트(Refinement)를 수행하는 방식으로 대상 객체를 찾아낸다. R-Tree 의 삽입, 삭제, 노드 스플릿(Split), 노드 머지(Merge) 알고리즘은 MBR 을 기준으로 한다는 점만 제외하고는 B-Tree 와 유사하다. TD R-tree 인덱스 타입 TD R-Tree(Three Dimensional R-Tree)는 2 차원 공간 객체에 시간축을 추가한 3 차원 최소 경계 박스(MBB: Minimum Bounding Box)로 필터링을 수행한다. TD R-Tree 인덱스 관리를 위한 알고리즘은 R-Tree 와 동일하다. B-tree R-tree TD R-tree 276 ALTIBASE5 Administrator’s Manual MEMORY 제공 제공 제공 DISK 제공 제공하지 않음 제공하지 않음 인덱스 속성 인덱스를 생성할 때 키 칼럼 구성 방법, 키 칼럼의 속성 등에 의해 해당 인덱스는 아래와 같은 인덱스 속성을 가진다. 메모리 테이블의 인덱스는 시스템 시작 시 부트 업 시간을 단축하기 위해 영구 인덱스(Persistent Index) 속성을 지원한다. 유일 키 인덱스(Unique Index) 인덱스 칼럼에 대해 중복 값을 허용하지 않는 인덱스이다. 유일 키(Unique Key)와 프라이머리 키(Primary Key) 유일 키와 프라이머리 키 모두 중복 값을 허용하지 않는 것은 공통이다. 하지만 널(NULL)의 허용 여부에 따라 유일 키와 프라이머리 키로 구별된다. 프라이머리 키의 경우 널(NULL)을 허용하지 않는다. 중복 키 인덱스(Non-unique Index) 인덱스 칼럼에 대해 중복 값을 허용하는 인덱스이다. 유일 키 옵션을 지정하지 않으면 기본적으로 중복 값을 허용하는 인덱스로 생성된다. 단일 키 인덱스(Non-composite Index) 인덱스 대상 칼럼이 하나인 인덱스이다. 복합 키 인덱스(Composite Index) 여러 개의 칼럼들의 조합에 대해 하나의 인덱스를 생성하는 경우 복합 키 인덱스라고 한다. 영구 저장 인덱스(Persistent Index) 메모리 테이블의 인덱스는 영구적(Persistent) 데이터베이스 영역을 사용하지 않고 임시 메모리 영역에 생성된다. 그래서 메모리 테이블에 해당하는 모든 인덱스는 시스템을 시작할 때마다 다시 만들어진다. 만일 데이터베이스의 크기가 매우 크면 인덱스의 재생성 시간도 비례하여 오래 걸린다. 영구 저장 인덱스는 이러한 현상을 방지하기 위해 일단 시스템이 정상 셧 다운되는 경우 임시 메모리 영역에 구현된 인덱스를 파일로 만들어 저장한다. 그리고 시스템이 다시 시작되면 이 파일로부터 인덱스를 생성해 부트 업 시간을 단축시킨다. 비영구 저장 인덱스(Non-persistent Index) 정상 셧 다운 시에 파일로 저장되지 않는 일반 인덱스이다. 인덱스 데이터베이스 객체 및 권한 277 생성시 PERSISTENT=ON 옵션을 주지 않으면, 기본적으로 비영구 저장 인덱스로 생성된다. 인덱스 관리 인덱스는 테이블의 레코드들에 대한 접근을 빠르게 하도록 사용된다. 인덱스는 해당 테이블에 대해 물리적, 논리적으로 독립적인 객체이기 때문에 테이블에 관계없이 생성, 삭제, 수정할 수 있다. 테이블의 레코드들이 수정되면 해당 인덱스들도 수정이 되기 때문에 필요한 경우에 대해서만 인덱스를 생성하고, 테이블에 대한 접근 유형에 따라 인덱스를 변경하거나 삭제하여 최적화된 인덱스를 관리한다. 인덱스 생성(Creating Index) 인덱스는 테이블에 존재하는 하나 이상의 칼럼에 대해 생성된다. 인덱스는 테이블 제약조건을 통해서 내부적으로 생성될 수도 있고, CREATE INDEX 문을 사용해 사용자가 명시적으로 생성할 수도 있다. 예제 테이블 제약조건에 의한 인덱스 생성 CREATE TABLE TB1 (C1 INTEGER PRIMARY KEY, C2 INTEGER UNIQUE); 테이블 제약조건 변경에 의한 인덱스 생성 ALTER TABLE TB1 ADD PRIMARY KEY (C1); ALTER TABLE TB1 ADD UNIQUE (C2); 칼럼별 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; 디스크 B-tree 인덱스의 생성 옵션(NOLOGGING, NOFORCE) 디스크 B-tree 인덱스 생성 시 로그를 기록하여 고장이 나면 로그를 이용하여 인덱스를 복구한다. 디스크 B-tree 인덱스를 생성할 때 기록되는 로그 양과 인덱스 생성 시간을 단축할 수 있는 노로깅(NOLOGGING)에 관련된 옵션을 제공한다. 278 ALTIBASE5 Administrator’s Manual 노로깅(NOLOGGING) 옵션은 인덱스 생성 시 생성된 인덱스의 모든 페이지를 디스크에 즉시 반영해 인덱스 생성 후 시스템 고장이 발생하더라도 인덱스의 일관성을 보장할 수 있다. 그러나 노로깅 옵션으로 생성하더라도, 인덱스 페이지들을 즉시 디스크에 반영하지 않는 노포스(NOFORCE) 옵션을 사용하면 인덱스 생성시간을 단축하는 반면, 시스템 고장이나 미디어 고장이 발생했을 경우 일관성이 깨어질 수 있다. 노로깅으로 생성된 인덱스에 대한 영속성을 보장하기 위해 미디어 백업을 수행한다. 인덱스 생성시간 일관성 및 영속성 로깅 (LOGGING) 인덱스 생성+로깅 시스템 고장 및 미디어 고장 시 복구가능 노로깅 포스 (NOLOGGING FORCE) 인덱스 생성+인덱스 페이지 FORCE 시스템 고장 시 복구 가능, 미디어 고장 시 일관성이 깨 어질 수 있음 노로깅 노포스 (NOLOGGING NOFORCE) 인덱스 생성시간 시스템 고장 및 미디어 고장 시 일관성이 깨어질 수 있음 예제 로깅을 하지 않고 인덱스를 생성(FORCE) CREATE INDEX TB1_IDX1 ON TB1(C1) NOLOGGING; CREATE INDEX TB1_IDX1 ON TB1(C1) NOLOGING FORCE; 로깅을 하지 않고 인덱스를 생성한 후 디스크에 반영하지 않음(NOFORCE) CREATE INDEX TB1_IDX1 ON TB1(C1) NOLOGGING NOFORCE; 인덱스 변경 인덱스 활성 및 비활성 여부, 인덱스의 영구 저장 여부를 ALTER INDEX 문을 사용하여 변경할 수 있다. 예제 ALTER INDEX EMP_IDX1 SET PERSISTENT = ON; 인덱스 삭제 인덱스의 삭제는 DROP INDEX 문을 사용하여 명시적으로 삭제하거나 관련 제약조건을 삭제하여 묵시적으로 삭제될 수 있다. 예제 DROP INDEX emp_idx1; 인덱스 활용 상향식 인덱스 생성 데이터베이스 객체 및 권한 279 알티베이스는 상향식으로 인덱스를 생성(Bottom-Up Index Building)한다. 그러므로 데이터를 업로드한 후 인덱스를 생성하는 것이 효율적이다. 테이블에 인덱스가 생성되어 있는 상태에서 대량의 데이터를 삽입할 경우, 레코드가 삽입될 때마다 인덱스에 반영되므로 성능이 느려진다. 디스크 인덱스의 일관성 노로깅(NOLOGGING)으로 생성된 디스크 테이블의 인덱스의 경우 시스템 고장이나 미디어 고장 발생 시 인덱스의 일관성을 보장할 수 없는 경우가 발생한다. 이런 경우, 디스크 인덱스의 일관성을 V$DISK_BTREE_HEADER 로 확인해야 한다. 만약 IS_CONSISTENT 가 ‘F’인 인덱스가 존재한다면 해당 인덱스를 삭제하고 필요할 경우 재생성하여 사용할 수 있다. 관련 SQL 문 다음과 같은 SQL 문을 제공하며 이에 대한 자세한 설명은 SQL Users Manual 을 참조한다. y CREATE TABLE y ALTER TABLE y CREATE INDEX y ALTER INDEX y DROP INDEX 280 ALTIBASE5 Administrator’s Manual 뷰 관리 뷰(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; 이 외에 기존에 존재하는 뷰의 이름만 다른 이름으로 변경하고자 할 데이터베이스 객체 및 권한 281 경우 RENAME 문을 사용하여 변경할 수 있다. 삭제 뷰는 DROP VIEW 문을 사용하여 삭제할 수 있다. 예제 DROP VIEW avg_sal; 관련 SQL 문 다음과 같은 SQL 문을 제공하며 이에 대한 자세한 설명은 SQL Users Manual 을 참조한다. y CREATE VIEW y ALTER VIEW y DROP VIEW y SELECT 282 ALTIBASE5 Administrator’s Manual 시퀀스 관리 알티베이스에서는 키 생성자(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문을 사용하여 시퀀스를 생성하며 시퀀스 생성 구문에 사용되는 옵션들은 다음과 같다. y START WITH: 시퀀스의 시작 값 y INCREMENT BY: 시퀀스의 증감 분 데이터베이스 객체 및 권한 283 y MAXVALUE: 시퀀스의 최대값 y MINVALUE: 시퀀스의 최소값 y 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; 284 ALTIBASE5 Administrator’s Manual 관련 SQL 문 다음과 같은 SQL 문을 제공하며 이에 대한 자세한 설명은 SQL Users Manual 을 참조한다. y CREATE SEQUENCE y ALTER SEQUENCE y DROP SEQUENCE 데이터베이스 객체 및 권한 285 시노님 관리 알티베이스는 테이블, 시퀀스, 뷰, 저장 프로시저 및 저장 함수에 대한 별칭(alias)을 부여할 수 있는 시노님을 제공한다. 시노님의 장점 다음과 같은 경우 데이터베이스 시노님을 사용하면 많은 이점이 있다. y 특정 객체를 생성한 사용자와 객체의 원래 이름을 숨기고 싶은 경우 y SQL문 사용의 단순화하고자 하는 경우 y 사용자 변경에 따른 응용프로그램의 변경 최소화하고자 하는 경우 생성 CREATE SYNONYM 문을 사용하여 생성한다. 예제 테이블 dept 의 별칭으로 my_dept 시노님을 생성한다. CREATE SYNONYM my_dept FOR dept; 삭제 DROP SYNONYM 문을 사용하여 명시한 시노님을 삭제한다. 예제 시노님, my_dept 를 삭제한다. DROP SYNONYM my_dept; 관련 SQL 문 다음과 같은 SQL 문을 제공하며 이에 대한 자세한 설명은 SQL Users Manual 을 참조한다. y CREATE SYNONYM y DROP SYNONYM 286 ALTIBASE5 Administrator’s Manual 저장 프로시저 및 저장 함수 관리 저장 프로시저(Stored Prodedure)란 SQL 문들과 흐름 제어문, 할당문, 오류 처리 루틴 등을 이용해 전체 업무 절차를 프로그래밍하여 하나의 모듈로 만든 후 데이터베이스에 영구적으로 저장해 두고, 모듈 이름만을 호출하여 전체 업무 절차를 서버에서 한번에 수행하는 데이터베이스 객체로 이 절에서는 저장 프로시저 관리 방법에 대해 설명한다. 저장 프로시저와 저장 함수의 구별은 하나의 리턴값의 존재 유무에 따라 구별되는데 특별한 언급이 없는 한 모든 설명들은 공통 사항이다. 이 절에서는 저장 프로시저 관리에 대한 간단한 예제에 대해서만 설명하고 저장 프로시저에서 사용하는 용어와 개념, 자세한 관리 방법에 대해서는 Stored Procedure Users Manual을 참조한다. 종류 저장 프로시저(Stored Procedure) 입력 인자, 출력 인자, 입출력 인자를 가지고 바디(body) 내에 정의된 조건에 따라 여러 SQL 문을 한번에 수행하는 데이터베이스 프로시저이다. 리턴값을 가지지 않으며 출력 인자와 입출력 인자들을 통해 클라이언트에게 값을 전달한다. 하나의 리턴 값을 갖지 않기 때문에 다른 SQL 문의 expression 내에 피연산자로 사용될 수 없다. 저장 함수(Stored Function) 저장 프로시저와 동일하나 하나의 리턴 값을 가지는 함수를 의미한다. 저장 프로시저와 달리 하나의 리턴 값을 가지므로 다른 SQL 문의 expression 내에 시스템 제공 함수들과 같이 피연산자로 사용할 수 있다. 타입 세트(Type Set) 저장 프로시저의 사용자 정의 타입들을 정의한 집합이다. 주로 저장 프로시저끼리 파라미터 또는 리턴값으로 사용자 정의 타입을 주고받을 때 사용한다. 저장 프로시저 관련 문장 저장 프로시저의 문장 종류를 살펴보면, 다음과 같다. 데이터베이스 객체 및 권한 287 종류 관련 문장 설명 생성 CREATE [OR REPLACE] PROCEDURE 문 새로운 저장 프로시저를 생성하거나 이 미 생성된 저장 프로시저의 정의를 변경 하는 SQL문이다. CREATE [OR REPLACE] FUNCTION 문 새로운 저장 함수를 생성하거나 이미 생 성된 저장 함수의 정의를 변경하는 SQL문이다. CREATE [OR REPLACE] TYPESET 문 타입 세트를 생성 또는 변경하는 SQL 문이다. 변경 ALTER PROCEDURE 문 저장 프로시저 생성 이후 관련 객체들의 정의가 변경되어 현재 저장 프로시저의 실행계획 트리가 최적화된 상태가 아닐 경우 이를 재 컴파일하여 최적화된 실행 계획 트리를 재 생성하는 SQL문이다. ALTER FUNCTION 문 저장 함수 생성 이후 관련 객체들의 정 의가 변경되어 현재 저장 함수의 실행계 획 트리가 최적화된 상태가 아닐 경우 이를 재 컴파일하여 최적화된 실행 계획 트리를 재 생성하는 SQL문이다. 삭제 DROP PROCEDURE 문 생성된 저장 프로시저를 삭제하는 SQL 문이다. DROP FUNCTION 문 생성된 저장 함수를 삭제하는 SQL문이 다. DROP TYPESET 문 생성된 타입 세트를 삭제하는 SQL문이 다. 실행 EXECUTE 문 저장 프로시저 또는 저장 함수를 실행하 는 SQL문이다. FUNCTION SQL문 내에서 built-in function과 같 은 형태로 사용할 수 있다. [표 4-1] 저장 프로시저문의 종류 생성 저장 프로시저는 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 288 ALTIBASE5 Administrator’s Manual 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) 상태의 실행 계획을 재 생성하는 기능을 수행한다. 예제 데이터베이스 객체 및 권한 289 ALTER PROCEDURE proc1 COMPILE; 삭제 저장 프로시저는 DROP PROCEDURE 문을 사용하여 삭제할 수 있다. 예제 DROP PROCEDURE proc1; 관련 SQL 문 다음과 같은 SQL 문을 제공하며 이에 대한 자세한 설명은 Stored Procedure Users Manual 을 참조한다. y CREATE PROCEDURE y CREATE FUNCTION y CREATE TYPESET y ALTER PROCEDURE y ALTER FUNCTION y DROP PROCEDURE y DROP FUNCTION y DROP TYPE SET y EXECUTE 290 ALTIBASE5 Administrator’s Manual 트리거 관리 트리거란 테이블에 데이터가 삽입, 삭제, 또는 갱신될 때 시스템에 의해 묵시적으로 작동되어 특정 작업 절차를 자동으로 수행할 수 있도록 하는 저장 프로시저로 이 절에서는 트리거 관리 방법에 대해 설명한다. 트리거 구성 요소 y 트리거 이벤트(trigger event or statement) 트리거 수행을 발생시키는 SQL문을 트리거 이벤트라고 한다. y 트리거 조건(trigger restriction) 트리거 이벤트가 발생하고 트리거를 수행시킬 조건으로 논리 연산자를 포함하는 식이다. y 트리거 액션(trigger action) 트리거 조건이 TRUE일 때 트리거가 수행하는 저장 프로시저 본체(body)이다. 트리거 이벤트 y DELETE 해당 테이블의 데이터를 삭제하는 DELETE 구문을 수행 시 트리거를 동작시킨다. y INSERT 해당 테이블의 데이터를 삽입하는 INSERT 구문을 수행 시 트리거를 동작시킨다. y UPDATE 해당 테이블의 데이터를 변경하는 UPDATE 구문을 수행 시 트리거를 동작시킨다. UPDATE 트리거 이벤트에 OF 구문을 사용할 경우 OF 구문에 명시된 칼럼이 변경될 경우에만 트리거를 동작시킨다. 단, 데이터베이스의 무결성을 위해 리플리케이션에 의해 적용되는 테이블의 변경은 트리거 이벤트로 처리되지 않는다. 생성 트리거는 CREATE TRIGGER 문을 사용하여 생성할 수 있다. 예제 CREATE TRIGGER del_trigger 데이터베이스 객체 및 권한 291 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; 관련 SQL 문 다음과 같은 SQL 문을 제공하며 이에 대한 자세한 설명은 SQL Users Manual 을 참조한다. y CREATE TRIGGER y ALTER TRIGGER y DROP TRIGGER 또한, 트리거는 저장 프로시저이므로 트리거 본체(body)에 대해서는 Stored Procedure Users Manual 을 참조한다. 292 ALTIBASE5 Administrator’s 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; 기본 데이터 테이블스페이스 변경 데이터베이스 객체 및 권한 293 ALTER USER DLR DEFAULT TABLESPACE dlr1_data; 임시 테이블스페이스 변경 ALTER USER DLR TEMPORARY TABLESPACE dlr1_tmp; 특정 테이블스페이스 접근 허용 여부 변경 ALTER USER DLR ACES dlr2_data ON; 삭제 사용자를 삭제하고자 하는 경우 DROP USER 문을 사용하며, 해당 사용자의 소유로 되어 있는 모든 객체까지 한꺼번에 소멸시키고자 할 경우 cascade 옵션을 이용한다. Cascade 옵션을 사용하지 않는 경우 해당 사용자의 스키마 내에 객체가 존재하면 DROP USER 문 수행 시 오류가 발생한다. 예제 DROP USER DLR CASCADE; 관련 SQL 문 다음과 같은 SQL 문을 제공하며 이에 대한 자세한 설명은 SQL Users Manual 을 참조한다. y CREATE USER y ALTER USER y DROP USER 294 ALTIBASE5 Administrator’s Manual 권한 관리 사용자가 데이터베이스 객체 또는 데이터에 접근하기 위해서는 적절한 권한이 필요하다. 이 절에서는 사용자와 권한 및 객체와 권한에 대해 이를 관리하는 방법에 대해 설명한다. 종류 알티베이스는 사용자가 권한(privilege)을 관리할 수 있는 기능은 지원하지만 권한들의 묶음인 롤(role)은 지원하지 않는다. 알티베이스가 지원하는 권한의 종류에 대해 설명한다. 시스템 접근 권한 (System Privilege) 시스템 접근 권한은 일반적으로 DBA 가 관리를 하며, 데이터베이스에 특정한 작업을 수행하거나 모든 스키마에 있는 객체들을 관리할 수 있는 권한이다. 알티베이스가 지원하는 전체 시스템 접근 권한 목록은 다음과 같다. 이와 관련된 자세한 설명은 SQL Users Manual을 참조한다. 시스템 권한 이름 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 데이터베이스 객체 및 권한 295 시스템 권한 이름 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 privilegeTable SequencePSM View ALTER O O DELETE O EXECUTE O INDEX O INSERT O REFERENCES O SELECT O O O UPDATE O 권한 부여 GRANT 문을 사용하여 특정 사용자에게 명시적으로 권한을 부여할 수 있다. SYSTEM_와 SYS 사용자의 경우 DBA 로서 모든 권한을 갖고 296 ALTIBASE5 Administrator’s Manual 있으며 일반 사용자에게 임의의 권한을 부여할 수 있다. 일반 사용자의 경우 CREATE USER 문을 수행하여 사용자를 생성하면 최소 권한으로 다음 권한들은 시스템에 의해 자동 부여된다. y CREATE SESSION y CREATE TABLE y CREATE SEQUENCE y CREATE PROCEDURE y 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; 관련 SQL 문 다음과 같은 SQL 문을 제공하며 이에 대한 자세한 설명은 SQL Users Manual 을 참조한다. y GRANT y REVOKE Part II 297 Part II 테이블스페이스 299 5. 테이블스페이스 이 장에서는 관리자가 알아야할 테이블스페이스의 개념 및 구조와 지원되는 기능, 효율적인 테이블스페이스 관리 방안에 대해서 설명한다. 300 ALTIBASE5 Administrator’s Manual 테이블스페이스 정의 및 구조 본 절에서는 테이블스페이스가 무엇인지 살펴본다. 테이블스페이스와 데이터베이스의 관계를 알아보고, 디스크 테이블스페이스, 메모리 테이블스페이스, 휘발성 테이블스페이스들이 각각 어떤 구조를 갖고있는지 설명한다. 테이블스페이스의 정의 테이블스페이스는 테이블, 인덱스 등의 데이터베이스 객체들이 저장되는 논리적인 저장소(Storage)이다. 테이블스페이스는 데이터베이스의 운영을 위해 기본적으로 하나 이상의 테이블스페이스를 필요로 한다. 데이터베이스가 생성되면 시스템 테이블스페이스가 자동으로 생성되며, 사용자 임의로 사용자 정의 테이블스페이스를 생성하기도 한다. 알티베이스는 사용자 정의 테이블스페이스를 데이터베이스 객체가 디스크에 상주하는 디스크 테이블스페이스와 메모리에 상주하는 메모리 테이블스페이스, 메모리에 상주하면서 로깅을 하지않는 휘발성 테이블스페이스로 구분해 지원한다. 따라서 사용자는 테이블스페이스에 저장되는 데이터의 특성에 따라 디스크, 메모리, 또는 휘발성 테이블스페이스 중에서 어떤 것을 사용할 것인지 결정할 수 있다. 예를 들어 이력 데이터와 같은 대용량 데이터를 위해서는 디스크 테이블스페이스가 적합하다. 또한 접근 빈도가 높은 소용량 데이터는 메모리 테이블스페이스를, 빠른 처리를 위한 임시 데이터 처리는 휘발성 테이블스페이스를 사용한다. 테이블스페이스와 데이터베이스의 관계 데이터베이스를 생성하면 4 종류의 시스템 테이블스페이스(시스템 딕셔너리 테이블스페이스, 시스템 데이터 테이블스페이스, 시스템 언두 테이블스페이스, 시스템 임시 테이블스페이스) 들이 자동으로 생성된다. 또한 사용자가 테이블스페이스가 필요할 경우 사용자 정의 테이블스페이스(디스크, 메모리, 휘발성 테이블스페이스)를 생성할 수 있다. 사용자 정의 테이블스페이스는 데이터 특성에 따라 디스크 또는 메모리에 선택적으로 생성한다. 테이블스페이스는 사용자의 필요에 의해 추가적으로 생성되며, 동일한 인터페이스(interface)를 테이블스페이스 301 제공한다. [그림 5-1]은 위에서 설명한 데이터베이스와 테이블스페이스의 관계를 설명한다. 시스템 테이블스페이스 사용자 정의 테이 블스페이스 (in Me m o ry) 사용자 정의 테이블스 페이스 (in Dis k) 데이터베이스 [그림 5-1] 테이블스페이스와 데이터베이스의 관계 디스크 테이블스페이스 구조 디스크 테이블스페이스는 모든 데이터가 디스크 공간에 저장되는 테이블스페이스를 의미한다. 논리적으로 데이터 파일과 세그먼트로, 물리적으로는 세그먼트, 익스텐트 및 페이지로 구성된다. 논리적 구조 디스크 테이블스페이스는 데이터 파일, 세그먼트와 밀접한 관계를 갖는다. [그림 5-2]는 디스크 테이블스페이스와 데이터 파일 및 세그먼트의 연관 관계를 설명한다. 디스크 테이블스페이스, 데이터 파일 및 세그먼트는 다음과 같은 특징을 갖는다. 디스크 테이블스페이스는 하나 이상의 데이터 파일로 구성되며, 데이터 파일은 운영체제에서 제공되는 파일 형태로 존재한다. 세그먼트는 논리적으로 테이블스페이스에 저장되며, 물리적으로 데이터 파일에 저장된다. 세그먼트는 특정 디스크 테이블스페이스에 종속적이며, 세그먼트가 참조하는 세그먼트는 다른 디스크 테이블스페이스에 저장될 수 있다. 302 ALTIBASE5 Administrator’s Manual 디스크 테이블스페이스 테이 블 세 그먼 트 인 덱 스 세그먼 트 테이블 세그 먼트 인덱 스 세 그먼 트 테이 블 세 그먼트 인덱스 세그 먼트 데이터파일 데이터파일 [그림 5-2] 디스크 테이블스페이스, 데이터 파일, 세그먼트의 연관 관계 물리적 구조 디스크 테이블스페이스를 이루는 물리적 구조는 세그먼트, 익스텐트 및 페이지로 구성된다. 이들의 관계를 살펴보면 [그림 5-3]과 같다. [그림 5-3] 디스크 테이블스페이스의 물리적 구조 테이블스페이스 303 세그먼트(Segment) 테이블스페이스 내에서 테이블 또는 인덱스를 할당하는 단위이다. 하나의 테이블 또는 인덱스는 논리적으로 하나의 세그먼트로 볼 수 있다. 알티베이스에서 사용하는 세그먼트의 종류는 다음과 같다. 종 류 설 명 Table 세그먼트 데이터베이스 안에 데이터를 저장하는 가장 기본적인 수단이며 테이블의 모든 데이터는 한 개의 테이블스페이스에 속한다. Index 세그먼트 한 개의 특정 인덱스의 레코드는 한 개의 세 그먼트 안에 저장되며, 인덱스의 목적은 특 정 키를 기준으로 테이블의 데이터를 찾는 것이다. Undo 세그먼트 데이터베이스의 변경을 발생시키는 트랜잭션 에 의해 사용되며, 테이블 또는 인덱스를 변 경하기 전에 변경 전 값을 Undo 세그먼트에 저장하여 변경을 취소할 수 있도록 한다. TSS 세그먼트 알티베이스 내부적으로 관리되는 TSS(Tansaction Status Slot)를 관리하기 위한 세그먼트이며, 시스템 언두 테이블스페 이스 내에 할당된다. [표 5-1] 세그먼트 종류 세그먼트는 내부적으로 프리(Free) 익스텐트 리스트와 풀(Full) 익스텐트 리스트를 관리한다. 프리 익스텐트가 부족하면 테이블스페이스에 익스텐트 추가를 요청한다. 익스텐트(Extent) 디스크 테이블스페이스에서 데이터 오브젝트를 저장하기 위해서 필요한 자원으로 페이지를 할당하는 단위이다. 데이터를 저장할 때 저장이 가능한 프리 페이지(Free Page)가 부족하면, 테이블스페이스에서 익스텐트 단위로 페이지를 할당받는다. 한 개의 익스텐트는 기본 32 개의 페이지(256KB)로 구성되며, 알티베이스는 테이블스페이스마다 익스텐트 크기를 정할 수 있다. 페이지(page) 테이블과 인덱스의 레코드가 저장되는 최소 단위를 페이지라고 한다. 또한 I/O 의 최소 단위이다. 알티베이스의 페이지 크기는 8KB 이며, 다양한 크기의 페이지 (multiple page size)를 지원하지 않는다. 페이지는 어떤 정보를 저장하느냐 따라 데이터 페이지, 인덱스 페이지, 언두 페이지 등 304 ALTIBASE5 Administrator’s Manual 여러 종류가 있다. 페이지의 일반적인 구조와 데이터 저장 방식을 살펴보면 다음과 같다. 페이지 구조 페이지는 페이지의 기본 정보와 free slot 등을 관리하기 위한 헤더를 가지며 헤더를 제외한 영역에 레코드가 저장된다. 페이지는 내부적으로 다음 그림과 같이 5 개 영역으로 나누어진다. [그림 5-4] 디스크 테이블스페이스의 페이지 구조 y 물리적 헤더(Physical Header) 데이터 페이지의 공통 정보를 가지고 있다. y 논리적 헤더(Logical Header) 페이지의 종류에 따라 필요한 정보를 저장한다. y 빈 공간(Free Space) 새로운 데이터를 저장하기 위해 사용할 수 있는 여유 공간을 나타낸다. y 저장 데이터(Stored Procedure) 페이지 종류에 따라 로우, 인덱스, 언두 레코드 등을 저장한다. y 페이지 푸터(Page Footer) 페이지 구조의 가장 아래쪽에 위치하며, 페이지의 무결성을 확인하기 위한 정보를 가지고 있다. 페이지 레코드 저장 방식 페이지의 레코드 저장은 데이터가 페이지 아래부터 채워가며 저장되며, 이 때 빈 공간 영역을 사용한다. 테이블스페이스 305 그리고 페이지의 논리적 헤더는 페이지 아래 방향으로 확장되며 저장되며, 크기가 가변적으로 변한다. [그림 5-5] 페이지 레코드 저장 방식 메모리 테이블스페이스 구조 메모리 테이블스페이스는 모든 데이터가 메모리 공간에 저장되는 테이블스페이스를 의미한다. 논리적 구조는 테이블과 체크포인트 이미지 파일로 구성되며, 물리적으로는 페이지 리스트와 페이지들로 구성된다. 논리적 구조 메모리 테이블스페이스는 테이블 및 체크포인트 이미지 파일과 밀접한 관계를 갖는다. 다음 그림에서는 메모리 테이블스페이스, 테이블 및 체크포인트 이미지 파일의 연관 관계를 설명한다. [그림 5-6] 메모리 테이블스페이스, 테이블 및 체크포인트 이미지 파일의 연관 관계 306 ALTIBASE5 Administrator’s Manual 메모리 테이블스페이스, 테이블 및 체크포인트는 다음의 특징을 갖는다. 메모리 테이블스페이스는 디스크 테이블스페이스처럼 데이터를 데이터 파일에 저장하지 않고, 선형적인 메모리 공간에 데이터를 저장한다. 선형적인 메모리 공간은 페이지 단위로 분할하였을 때, 테이블은 페이지들의 리스트를 의미한다. 디스크 테이블스페이스는 디스크 입출력 비용 및 대용량 테이블 관리를 위하여 페이지 단위가 아닌 익스텐트 단위로 관리하며, 익스텐트의 리스트를 관리하기 위한 개념이 세그먼트이다. 그러나 메모리 테이블스페이스는 대용량 데이터의 관리보다 빠른 접근을 지원하는 것이 목적이기 때문에 세그먼트나 익스텐트의 개념이 필요하지 않다. 따라서 메모리 테이블스페이스의 테이블들은 페이지 리스트를 이용하여 관리된다. 이러한 테이블들은 체크포인트시에 물리적으로 체크포인트 이미지 파일에 저장된다. 체크포인트 이미지 파일의 용도는 디스크 테이블스페이스의 데이터 파일과 다르다. 디스크 테이블스페이스의 데이터 파일은 객체들이 저장되기 위한 디스크 테이블스페이스 전용 파일이며, 메모리 테이블스페이스의 체크포인트 이미지 파일은 객체들을 백업하기 위한 메모리 테이블스페이스 전용 파일이다. 체크포인트 이미지 파일은 데이터베이스 운영에 직접적으로 필요하지 않다. 하지만 백업 및 복구 시간을 단축하기 위해 반드시 필요하다. 체크포인트시 메모리 공간의 페이지들은 운영 체제의 파일을 이용하여 저장된다. 알티베이스는 체크포인트 방식으로 핑퐁(ping- pong) 체크포인트를 이용하기 때문에 두 벌의 체크포인트 이미지 파일(0 번, 1 번)을 유지하며, 각각의 체크포인트마다 0 번과 1 번 파일을 번갈아가며 사용한다. 또한 각각의 체크포인트 이미지는 디스크 입출력 비용의 분산을 목적으로 하기 때문에 다수의 작은 파일로 분리될 수 있다. 물리적 구조 메모리 테이블스페이스의 물리적 구성 요소에는 페이지 리스트와 페이지가 있다. 이들의 관계를 살펴보면 다음 그림과 같이 설명할 수 있다. 테이블스페이스 307 [그림 5-7] 메모리 테이블스페이스의 물리적 구조 페이지 리스트(Page List) 페이지 리스트는 메모리 테이블스페이스 내에서 테이블이 구성되는 물리적인 개념이다. 페이지 리스트는 메모리 테이블스페이스의 메모리 공간을 페이지 단위로 분할하였을 때, 여러 페이지들의 리스트를 의미한다. 메모리 테이블스페이스 객체 중에서 테이블은 페이지 리스트를 사용하지만, 인덱스는 데이터베이스의 일관성을 유지하는 대상에 포함되지 않기 때문에 페이지 리스트를 사용하지 않는다. 메모리 테이블의 인덱스는 시스템을 다시 시작할 때 인덱스를 재구축함으로써 운영중에 발생하는 인덱스 로깅의 부하를 제거한다. 페이지(Page) 메모리 테이블스페이스의 페이지 구조 및 데이터 저장 방식은 디스크 테이블스페이스의 페이지와 다른 특징을 갖는다. 메모리 테이블스페이스는 디스크 테이블스페이스와 달리 디스크 입출력 비용을 고려할 필요가 없어 레코드 수정 방식으로 아웃 플레이스 갱신(out-place update)을 사용한다. 아웃 플레이스 갱신이란 기존 레코드의 이미지를 직접적으로 변경하지 않고, 새로운 버전을 위한 레코드 공간을 할당받아 처리하는 방식이다. 이러한 레코드의 갱신 방식은 기존 레코드의 삭제와 새로운 레코드의 삽입 과정으로 이루어지기 때문에 디스크에서 기존 레코드를 재구성하는 비용이 들지 않는다. 또한 기존 레코드의 접근을 직접 할 수 있어 동시성 레벨이 높은 응용 분야에서 빠른 성능을 보장한다. 308 ALTIBASE5 Administrator’s Manual 휘발성 테이블스페이스 구조 휘발성 테이블스페이스의 구조는 모든 데이터가 메모리 공간에 저장되는 메모리 테이블스페이스와 동일하다. 그러나 디스크의 이미지 파일을 가지지 않고 메모리에만 상주한다는 점에서 메모리 테이블스페이스와 차이가 있다. 휘발성 테이블스페이스에서 일어나는 작업들은 디스크 로깅 작업을 수반하지 않고 체크포인트 대상에서도 제외되기 때문에 디스크 입출력이 전혀 없다. 따라서 빠른 성능을 필요로 하는 경우에 휘발성 테이블스페이스가 유용하다. 논리적으로는 테이블로 구성되며, 물리적으로는 페이지 리스트와 페이지로 구성된다. 논리적 구조 휘발성 테이블스페이스는 메모리에 데이터베이스 객체를 상주시킨다는 점에서 메모리 테이블스페이스와 동일하다. 그러나 휘발성 테이블스페이스는 체크포인트 이미지 파일은 갖지 않는다. 물리적 구조 메모리 테이블스페이스와 동일하게 페이지 리스트와 페이지로 구성된다. 테이블스페이스 309 테이블스페이스 분류 알티베이스가 제공하는 테이블스페이스는 아래 3 가지 기준에 의해서 분류된다. 하나의 테이블스페이스는 아래에 분류된 다수의 속성들을 동시에 가질수 있다. y 저장 공간에 따른 분류 y 저장 내용에 따른 분류 y 생성 주체에 따른 분류 저장 공간에 따른 분류 알티베이스 테이블스페이스는 저장 공간에 따라 다음과 같이 분류된다. y 메모리 상주 테이블스페이스 y 디스크 테이블스페이스 메모리 상주 테이블스페이스 메모리 상주 테이블스페이스는 로깅 및 디스크 이미지 파일의 존재 여부에 따라 메모리 테이블스페이스와 휘발성 테이블스페이스로 구분된다. 메모리 테이블스페이스는 메모리 기반 객체를 저장하기 위한 테이블스페이스이다. 해당 테이블스페이스 내에 저장되는 모든 객체에 메모리 기반 데이터베이스 기술이 적용됨으로써, 사용자가 실시간으로 데이터에 접근할 수 있다. 그러나 메모리 테이블스페이스의 크기는 시스템의 사용 가능한 물리적 메모리 공간을 초과할 수 없다. 휘발성 테이블스페이스는 디스크 I/O 작업 없이 메모리 기반 객체를 저장하기 위한 테이블스페이스이다. 해당 테이블스페이스 내에 저장되는 모든 객체에 메모리 기반 데이터베이스 기술과 부가적 기술이 적용됨으로써, 사용자가 디스크 I/O 작업 없이 실시간으로 데이터에 접근할 수 있다. 그러나 휘발성 테이블스페이스의 크기는 시스템의 사용 가능한 물리적 메모리 공간을 초과할 수 없고, 데이터베이스 서비스 종료시 모든 휘발성 데이터 객체들은 사라진다. 디스크 테이블스페이스 디스크 테이블스페이스는 디스크 기반 객체를 저장하기 위한 테이블스페이스이다. 데이터의 실시간 접근보다는 대용량 데이터를 관리하고 싶은 경우에 사용할 수 있는 테이블스페이스이다. 해당 테이블스페이스에 저장되는 객체들에 대한 접근은 디스크 입출력을 수반한다. 이러한 디스크 입출력 비용이 데이터의 접근의 대부분의 310 ALTIBASE5 Administrator’s Manual 시간을 차지하기 때문에, 디스크 테이블스페이스는 메모리 버퍼 공간을 사용하여 디스크 입출력 비용을 줄인다. 저장 내용에 따른 분류 테이블스페이스에 저장되는 내용에 따라 다음과 같이 분류된다. y 딕셔너리 테이블스페이스(Dictionary Tablespace) y 언두 테이블스페이스(Undo Tablespace) y 임시 테이블스페이스(Temporary Tablespace) y 데이터 테이블스페이스(Data Tablespace) 딕셔너리 테이블스페이스 딕셔너리 테이블스페이스는 시스템의 운영상 필요한 메타 데이터를 저장하기 위한 테이블스페이스다. 데이터베이스 생성시 시스템에 의해서 생성되는 테이블스페이스이며, 시스템 내에 하나만 존재할수 있다. 딕셔너리 테이블스페이스에는 사용자가 객체를 생성할 수 없으며, 시스템만이 메타 데이터 유지 관리를 위한 시스템 객체를 생성할 수 있다. 딕셔너리 테이블스페이스는 메타 데이터의 빠른 접근을 위하여 메모리 형태의 테이블스페이스를 사용한다. 딕셔너리 테이블스페이스가 붕괴(crash)된 경우에는 전체 데이터베이스를 운영할 수 없다(백업 및 매체 복구를 이용하여 데이터베이스를 회복시켜야 한다). 언두 테이블스페이스 언두 테이블스페이스는 디스크 객체에 대한 연산이 남긴 언두 이미지(undo image)를 저장하기 위한 테이블스페이스이다. 알티베이스의 동시성 제어는 MVCC(Multi-Version Concurency Control) 기법을 사용하기 때문에 변경 이전의 이미지를 저장할 공간이 필요하다. 이러한 이전 이미지가 언두 테이블스페이스에 저장되며, 다량의 이전 이미지로 인하여 데이터 테이블스페이스가 무한 확장되는 것을 막는다. 언두 테이블스페이스는 시스템에 하나만 존재하며, 데이터베이스 내의 모든 디스크 테이블스페이스에서 언두 테이블스페이스를 공유한다. 따라서, 언두 테이블스페이스도 딕셔너리 테이블스페이스와 마찬가지로 시스템 운영상 필수적인 시스템 테이블스페이스이며, 테이블스페이스 단위의 백업이 가능하다. 임시 테이블스페이스 임시 테이블스페이스는 질의 수행중 생성되는 임시 결과를 저장하기 위한 테이블스페이스이다. 따라서, 트랜잭션이 종료하는 시점에 해당 질의가 남긴 임시 테이블스페이스 내의 모든 데이터들은 사라지게 된다. 테이블스페이스 311 이러한 종류의 테이블스페이스는 동시성 제어 및 회복을 위한 로깅 등을 하지 않아 빠른 저장 및 검색을 지원한다. 사용자가 임의적으로 임시 테이블스페이스를 생성할 수 있으며, 다수의 임시 테이블스페이스가 시스템 내에 존재할 수 있다. 또한 이러한 임시 테이블스페이스는 백업을 지원하지 않는다. 데이터 테이블스페이스 데이터 테이블스페이스는 사용자 정의 객체를 저장하기 위한 테이블스페이스이다. 다수의 데이터 테이블스페이스가 시스템 내에 존재할 수 있으며, 테이블스페이스에 저장되는 데이터의 특성에 따라 메모리, 휘발성 또는 디스크 테이블스페이스로 생성할 수 있다. 생성 주체에 따른 분류 알티베이스 테이블스페이스는 생성 주체에 따라 다음과 같이 분류된다. y 시스템 테이블스페이스(System Tablespace) y 사용자 정의 테이블스페이스(User Tablespace) 시스템 테이블스페이스 시스템 테이블스페이스는 시스템 운영상 필요한 데이터들을 저장하기 위한 테이블스페이스이다. 시스템 딕셔너리 테이블스페이스, 시스템 언두 테이블스페이스, 시스템 데이터 테이블스페이스 및 시스템 임시 테이블스페이스가 이에 해당한다. 시스템 테이블스페이스는 데이터베이스 생성시 만들어지며, 사용자가 명시적으로 테이블스페이스 삭제 및 이름 변경을 할 수 없다. 또한 테이블스페이스 레벨의 백업과 매체 복구가 가능하다. 사용자 정의 테이블스페이스 사용자 정의 테이블스페이스는 사용자 정의 객체들의 내용을 저장하기 위한 테이블스페이스이다. 사용자 정의 테이블스페이스 내에 정의된 객체들의 메타데이터는 딕셔너리 테이블스페이스에 저장된다. 사용자 정의 테이블스페이스는 사용자가 명시적으로 테이블스페이스를 삭제 및 이름 변경을 할 수 있으며, 테이블스페이스 단위의 백업 및 복구가 가능하다. 테이블스페이스 목록 데이터베이스가 생성시 다수의 테이블스페이스가 만들어진다. [표 5-2]와 같이 시스템 테이블스페이스, 언두 테이블스페이스, 312 ALTIBASE5 Administrator’s Manual 임시 테이블스페이스, 그리고 사용자가 이용할 수 있는 기본적인 메모리 테이블스페이스와 디스크 테이블스페이스가 생성된다. 이외에 사용자가 ‘CREATE TABLESPACE’문으로 테이블스페이스들을 추가할 수 있다. ID 테이블스페이스 종류 저장 공간테이블스페이스 이름 생성 시점 0 SYSTEM DICTIONARY TABLESPACE 메모리 SYS_TBS_MEM_DIC CREATE DATABASE 1 SYSTEM MEMORY DEFAULT TABLESPACE 메모리 SYS_TBS_MEM_DATACREATE DATABASE 2 SYSTEM DISK DEFAULT TABLESPACE 디스크 SYS_TBS_DISK_DATACREATE DATABASE 3 SYSTEM UNDO TABLESPACE 디스크 SYS_TBS_DISK_UNDOCREATE DATABASE 4 SYSTEM DISK TEMPORARY TABLESPACE 디스크 SYS_TBS_DISK_TEMPCREATE DATABASE 5이상 USER MEMORY DATA TABLESPACE 메모리 사용자 지정 CREATE MEMORY DATA TABLESPACE 5이상 USER DISK DATA TABLESPACE 디스크 사용자 지정 CREATE DISK DATA TABLESPACE 5이상 USER DISK TEMPORARY TABLESPACE 디스크 사용자 지정 CREATE DISK TEMPORARY TABLESPACE 5이상 USER VOLATILE DATA TABLESPACE 메모리 사용자 지정 CREATE VOLATILE DATA TABLESPACE [표 5-2] 테이블스페이스 종류 테이블스페이스 313 디스크 테이블스페이스 디스크 테이블스페이스는 모든 데이터가 디스크 공간에 저장되는 테이블스페이스를 의미한다. 이 절에서는 디스크의 데이터 페이지를 중심으로 구조 및 로우 데이터의 입력 방식 등이 어떻게 되는지를 살펴본다. 데이터 페이지 구조 알티베이스가 데이터베이스의 저장 공간을 관리할 때 사용하는 데이터의 최소 단위를 페이지(page)라고 한다. 알티베이스의 페이지 크기는 8KB 이고, 다양한 크기의 페이지 (multiple page size)를 지원하지 않는다. 페이지의 종류는 여러가지가 있는데, 그 중에서 로우 데이터(row data)를 저장하는 페이지를 데이터 페이지(data page)라고 한다. 로우 데이터는 페이지 아래부터 채워가며 저장하며, 이 때 빈 공간 영역을 사용한다. 만약 빈 공간의 영역이 충분하지 않다면, 페이지 콤팩트(page compact) 연산을 수행하여 단편화된 공간을 제거하고 연속된 빈 공간을 확보한다. [그림 5-8] 데이터 페이지의 구조 314 ALTIBASE5 Administrator’s Manual 데이터 페이지의 영역은 그림과 같이 6 개의 영역으로 구성된다. y 물리적 헤더(Physical Header) 데이터 페이지의 공통 정보를 가지고 있다. y TTL(Touched Transaction Layer) MVCC 관련 정보를 가지고 있다. y 슬롯 디렉토리(Slot Directory) 로우가 저장된 위치(offset)에 대한 정보를 가지고 있다. y 빈 공간(Free Space) 입력이나 갱신 등의 연산을 할 때 사용할 수 있는 여유 공간을 나타낸다. y 로우 데이터(Row Data) y 페이지 푸터(Page Footer) 페이지 구조의 가장 아래쪽에 위치하며, 페이지의 무결성을 확인하기 위한 정보를 가지고 있다. 디스크 테이블스페이스의 공간 관리 디스크 테이블스페이스는 PCTFREE, PCTUSED 파라미터를 이용하 여 수동적으로 공간을 관리할 수 있다. PCTFREE, PCTUSED 파라미터로 로우 데이터에 대한 입력이나 갱 신 연산을 할 때 빈 공간의 사용을 제어할 수 있도록 한다. 이들 파 라미터의 값은 altibase.properties 파일의 PCTFREE, PCTUSED 프로퍼티의 값으로 지정되어 있으며, 테이블 생성(CREATE TABLE…) 또는 변경(ALTER TABLE…)하는 구문에서도 파라미터 값을 명시할 수 있다. PCTFREE PCTFREE 는 페이지에 저장되어 있는 로우들이 갱신될 경우에 대비하여 빈 공간을 미리 확보해두는 최소 비율을 의미한다. 예를 들어 이 값을 20 으로 설정하면, 페이지의 80% 공간까지만 입력(insert)할 수 있고, 나머지 20%의 공간은 기존의 로우들이 갱신될 때를 대비하여 남겨둔다. 테이블스페이스 315 [그림 5-9] PCTFREE 사용시 페이지 구조 PCTUSED PCTUSED 는 페이지가 갱신만 가능한 상태에서 다시 삽입이 가능 상태로 가기 위한 페이지 사용 공간의 최소 비율을 의미한다. PCTFREE 제한에 걸리게 되면, 해당 페이지는 사용 공간의 비율이 PCTUSED 보다 낮아지기 전까지 새로운 로우를 입력할 수 없다. 이 때 페이지 내의 빈 공간은 오직 갱신 연산을 위해서만 사용하며, 다시 사용 공간의 비율이 PCTUSED 보다 낮아지게 되면, 페이지에 새로운 로우를 입력할 수 있게 된다. 316 ALTIBASE5 Administrator’s Manual 61% Data Block PCTUSED=40 빈 공간의 비율이 40% 미만으로 될 때까지 새로운 로우의 입력을 하지 않는다. [그림 5-10] PCTUSED 사용시 페이지 구조 로우의 구조 로우는 하나 이상의 로우 조각(row piece)들로 구성된다. 만약 로우 전체가 한 개의 페이지에 저장될 수 있으면, 로우는 하나의 로우 조각에 저장된다. 그러나 한 개의 페이지에 저장할 수 없다면, 로우는 여러 개의 로우 조각에 나뉘어서 저장된다. 이 때 로우 조각들은 ROWID 로 서로 연결된다. [그림 5-11] 로우 조각의 구조 로우 조각은 로우 헤더(row header)와 로우 바디(row body)로 구성된다. 테이블스페이스 317 로우 헤더에는 18 byte 크기의 공통 헤더 정보가 먼저 저장되고, 연결된 로우 조각(chained row piece)일 경우에는 6 byte 의 ROWID 정보가 추가적으로 저장된다. 로우 바디에는 칼럼의 길이(column length), 칼럼 값(column value)이 쌍을 이뤄서 연속으로 저장된다. 칼럼 길이의 경우 칼럼 값 의 크기가 250 byte 이하이면 1byte 만 필요하고, 칼럼 값의 크기가 250 byte 를 초과하면 3byte 가 필요하다. 공간을 절약하기 위해서 칼럼 값이 널(null)인 경우 칼럼의 길이(0)만 저장하고 칼럼 값은 저장하지 않는다. 또한 칼럼 값이 널인 칼럼들이 마지막에 연속으로 올 경우에는 칼럼 값 뿐 아니라 칼럼 길이도 저장하지 않는다. 칼럼은 테이블 생성(CREATE TABLE…) 시에 나열한 순서대로 저장된다. 이 때 널을 많이 포함하는 칼럼을 마지막에 배치하면 로우를 저장하는데 필요한 공간을 절약할 수 있다. 로우 체이닝 및 마이그레이션 로우의 데이터가 너무 커서 한 개의 페이지에 저장할 수 없을 때 로우 체이닝(row chaining)과 로우 마이그레이션(row migration)이 발생한다. 로우 체이닝은 데이터를 입력할 때 데이터의 크기가 너무 커서 로우가 한 페이지에 저장될 수 없을 때 발생한다. 이 경우에는 로우의 데이터가 여러 개의 페이지에 나누어 저장되고, 이들은 서로 ROWID 에 의해 연결된다. 로우 마이그레이션은 한 페이지 내에 저장되었던 로우였더라도, 갱신 과정에서 로우의 크기가 페이지의 크기를 넘어가는 경우 발생한다. 이 경우 전체 로우는 새로운 페이지로 마이그레이션 되고, 기존의 로우는 로우가 옮겨져서 저장된 위치를 가리키게 된다. 그러나 로우 마이그레이션이 발생하더라도 ROWID 는 변경되지 않는다. 로우 체이닝 또는 로우 마이그레이션이 발생하면, DML 처리시에 한 페이지를 더 읽어야 하므로 디스크 I/O 로 인한 성능저하가 발생한다. 318 ALTIBASE5 Administrator’s Manual 언두 테이블스페이스 언두 테이블스페이스는 데이타베이스에 대한 변경 연산을 취소하기 위한 정보를 저장하는 테이블스페이스이다. 알티베이스는 다중 버전의 동시성 제어 기법을 사용하기 때문에 변경 이전의 이미지를 저장할 공간이 필요하다. 언두 테이블스페이스는 시스템에 하나만 존재하며, 데이터베이스 내의 모든 디스크 테이블스페이스에서 공유한다. 이 절에서는 언두 테이블스페이스의 특징 및 크기 계산 등 언두 테이블스페이스를 어떻게 관리하는지 설명한다. y 언두 레코드(Undo Record) y 언두 테이블스페이스 특징 y 트랜잭션 세그먼트의 관리 y 세그먼트 공간 재사용성 y 언두 테이블스페이스 변경 언두 레코드 데이터베이스는 변경된 트랜잭션을 취소(롤백 또는 언두)하기 위하여 해당 정보들을 유지해야 한다. 이러한 정보들은 주로 트랜잭션이 커 밋되기 전에 트랜잭션의 연산들을 언두 레코드들로 저장한다. 언두 레코드는 다음과 같은 목적으로 사용된다. y 롤백(rollback) 구문에 의한 트랜잭션 철회 y 데이터베이스 복구 y 읽기 일관성(Read Consistency) 보장 언두 레코드는 롤백 구문이 수행되면, 커밋되지 않은 트랜잭션에 대 한 데이터베이스 변경을 취소할 때 사용된다. 또한 데이터베이스를 복구하는 동안에도 로그 파일로부터 데이터베이 스를 리두(Redo)한 후 커밋되지 않은 변경에 대해서 언두를 할 때에 도 사용된다. 그리고 트랜잭션에 의해 변경중인 레코드를 다른 트랜잭션이 읽기 위 하여 동시에 레코드에 접근하여도 레코드가 변경되기 전의 이미지를 언두 레코드에 저장하고 있기 때문에 읽기 일관성을 보장할 수 있다. 언두 테이블스페이스의 특징 언두 테이블스페이스의 특징을 살펴보면 다음과 같다. 테이블스페이스 319 y 시스템에 의한 자동 관리 y 기본적으로 자동 확장 모드의 undo001.dbf로 구성되며, 데이터 파일의 추가 및 크기 변경이 가능 y 온라인 백업(Online Backup)의 대상 y 언두 테이블스페이스는 TSS 세그먼트와 언두 세그먼트 이외의 데이터베이스 오브젝트 생성 불가능 y 시스템 테이블스페이스로서 테이블스페이스 오프라인 및 제거가 불가능 y 서버가 재구동될 때마다 언두 테이블스페이스 재구성(Reset) 알티베이스는 언두 테이블스페이스의 정보 및 공간을 관리할 때 시스 템에 의한 관리 방식을 사용한다. 시스템에 의한 관리 방식이란 기본 적으로 언두 테이블스페이스의 세그먼트들과 공간들을 서버가 자동으 로 관리하는 것을 의미한다. 언두 테이블스페이스는 데이터베이스 생성 과정에서 생성된다. 시스템 테이블스페이스로써, 하나만 존재할 수 있다. 만약 언두 테이블스페이스가 존재하지 않는다면 부트 로그에 에러 메시지가 출력되고 서버 구동이 실패한다. 언두 테이블스페이스는 트랜잭션 세그먼트(TSS 세그먼트와 언두 세그먼트)를 관리하며, 사용자는 프로퍼티 TRANSACTION_SEGMENT_COUNT 를 통해 트랜잭션 세그먼트를 변경할 수 있다. 사용자가 프로퍼티에서 지정한 개수만큼 TSS 세그먼트와 언두 세그먼트를 각각 생성한다. 트랜잭션 세그먼트를 TRANSACTION_SEGMENT_COUNT=255 로 설정하였다면, 서버 구동시마다 TSS 세그먼트 255 개와 언두 세그먼트 255 개가 생성된다. 이처럼 프로퍼티를 통해 트랜잭션 세그먼트를 다른 개수로 변경하였다면, 다음 서버 구동시에 명시된 개수만큼 세그먼트들이 재구성된다. 트랜잭션 세그먼트의 관리 트랜잭션 세그먼트란 디스크 변경 트랜잭션에 반드시 필요한 1 개의 TSS 세그먼트와 1 개의 언두 세그먼트를 의미한다. 디스크 변경 트랜잭션마다 하나의 트랜잭션 세그먼트가 바인딩(Binding) 되고, 트랜잭션이 완료될 때 언바인딩(Unbinding) 되기 때문에 다른 트랜잭션과 동시에 공유할 수는 없다. V$TXSEGS 를 조회하면, 트랜잭션 세그먼트의 바인딩 여부를 확인할 수 있다. 디스크 변경 트랜잭션에 해당 트랜잭션 세그먼트가 바인딩되면 V$TXSEGS 에 트랜잭션 세그먼트 ID, 트랜잭션 ID 에 320 ALTIBASE5 Administrator’s Manual 해당하는 레코드가 생성되고 바인딩이 해제되면 레코드는 삭제된다. 또한 TSS 세그먼트와 언두 세그먼트의 공간은 트랜잭션이 한 번 사용한 공간에 대해서는 어느 정도 시간이 지나면 재사용할 수 있는 구조로 설계되었다. 따라서 언두 트랜잭션의 공간이 필요한 경우에는 무조건 세그먼트를 생성하여 공간을 확장하는 것이 아니라 기간이 만료된 세그먼트를 다시 사용할 수 있다. TSS 세그먼트를 재사용할 수 있는 단위는 1M 이며, 언두 세그먼트는 2M 로 결정된다. 다음은 언두 테이블스페이스와 관련된 사용자 프로퍼티를 나타낸다. y SYS_UNDO_FILE_INIT_SIZE 언두 테이블스페이스의 데이터 파일 생성 크기 y SYS_UNDO_FILE_MAX_SIZE 언두 테이블스페이스의 데이터 파일 최대 크기 y SYS_UNDO_TBS_NEXT_SIZE 언두 테이블스페이스의 데이터 파일 자동 확장 크기 y SYS_UNDO_TBS_EXTENT_SIZE 언두 테이블스페이스의 익스텐트 페이지 개수 y TRANSACTION_SEGMENT_COUNT 트랜잭션 세그먼트의 개수 세그먼트의 공간 재사용성 언두 데이터는 트랜잭션을 커밋한 후에는 트랜잭션 롤백이나 복구를 목적으로 더 이상 필요하지 않다. 하지만 트랜잭션의 커밋 주기가 긴 Long-Term 트랜잭션은 언두 데이타를 이용한 이전 레코드의 읽기 일관성을 위해서 필요하다. 그렇지만 어느 정도 시간이 지나면 읽기 일관성을 위해서도 더 이상 언두 데이타는 필요하지 않게 된다. 따라서 알티베이스 데이타베이스는 커밋된 언두 데이터라고 하여도 최소한의 기간 동안만 유지하고, 그 기간이 지나면 언두 공간을 다른 트랜잭션에 의해서 재사용할 수 있도록 하고 있다. 만약 커밋된 언두 공간을 더 이상 판독할 온라인 트랜잭션들이 존재 하지 않는다면 해당 언두 공간은 기간이 만료(Expired)되었다고 한 다. 반대로 판독이 가능한 온라인 트랜잭션이 아직 존재한다면 해당 언두 공간은 기간이 유효(Unexpired)하다고 한다. 이 때 기간이 만료된 언두 공간은 다른 트랜잭션에 의해서 재사용할수 있다는 것을 의미하며, 기간이 유효한 언두 공간은 재사용할 수 없다는 것을 의미한다. 테이블스페이스 321 언두공간#0 (exp ired ) 언두공간#1 (exp ired ) 언두공간#2 (exp ired ) 언두공간#3 (unexp ired ) 언두공간#4 (unexp ired ) 언두공간#5 ( c urre nt) 언두공간#0 (c urre nt) 언두공간#1 (exp ired ) 언두공간#2 (exp ired ) 언두공간#3 (unexp ired ) 언두공간#4 (unexp ired ) 언두공간#5 (unexp ired ) [그림 5-12] 언두 세그먼트의 재사용 위의 그림 언두 세그먼트의 순환 구조는 언두 공간이 어떻게 재사용 되는지를 보여준다. 언두 공간 #0부터 순서대로 사용되면서 현재(Current)의 언두 공간 #5을 사용하고 있는 것을 나타낸다. 그리고 다음 차례의 언두 공간 #0이 만료된 것을 확인하고, 언두 공간 #5를 모두 사용하면 언두 세 그먼트를 더 이상 확장하지 않고 언두 공간 #0을 재사용하는 것을 알 수 있다. 언두공간#0 (une xp ire d ) 언두공간#1 (une xp ire d ) 언두공간#2 (une xp ire d ) 언두공간#3 (une xp ire d ) 언두공간#4 (une xp ire d ) 언두공간#5 ( c urre nt) 언두공간#0 (exp ired ) 언두공간#1 (une xp ire d ) 언두공간#2 (une xp ire d ) 언두공간#3 (une xp ire d ) 언두공간#4 (une xp ire d ) 언두공간#5 (une xp ire d ) 언두공간#6 ( c urre nt) [그림 5-13] 언두 세그먼트의 확장 그러나 언두 공간 #0이 유효한 상태라면 위의 그림처럼 언두 세그먼 트는 익스텐트를 확장하여 언두 공간 #6을 추가하게 된다. 이와 같은 세그먼트 공간의 재사용성은 TSS 세그먼트에도 동일하게 적용된다. 322 ALTIBASE5 Administrator’s Manual 언두 테이블스페이스 변경 언두 테이블스페이스는 ALTER TABLESPACE 구문을 사용하여 변경한다. 그러나 언두 테이블스페이스는 대부분이 시스템에 의해서 관리되므로, 다음과 같은 연산들에 대해서만 사용자가 제어할 수 있다. y 데이터 파일 추가 및 제거 y 데이터 파일 확장 및 축소 y 데이터 파일 온라인 백업 시작 및 완료 언두 테이블스페이스에 용량 부족이 발생하거나 용량 부족과 관련된 에러가 발생하는 것을 방지하려면, 사용자는 데이터 파일들을 추가하거나 기존 데이터 파일의 크기를 확장해야 한다. 다음은 언두 테이블스페이스에 데이터 파일을 추가하는 예제이다. ALTER TABLESPACE SYS_TBS_DISK_UNDO ADD DATAFILE ‘undo002.dbf’ AUTOEXTEND ON NEXT 1M MAXSIZE 2G; 또한 ALTER TABLESPACE … DROP DATAFILE 구문으로 데이터 파일을 제거할 수도 있으며, ALTER TABLESPACE ... ALTER DATAFILE… 구문으로 파일의 크기를 확장하거나 축소시킬 수 있다. 그리고 데이터 파일의 백업을 시작하기 위해서는 ALTER TABLESPACE … BEGIN BACKUP 구문으로 할 수 있으며, 백업 완료는 ALTER TABLESPACE … END BACKUP 구문으로 가능하다. 테이블스페이스 323 테이블스페이스 상태 테이블스페이스는 서비스 상태에 따라 온라인(online)과 오프라인(offline), 디스카드(discard)로 구분된다. 테이블스페이스중에서 사용자가 생성한 디스크 테이블스페이스와 메모리 테이블스페이스는 온라인과 오프라인으로 사용할 수 있으나, 휘발성 테이블스페이스와 임시 테이블스페이스에서는 사용할 수 없다. 또한 테이블스페이스 내에 이중화가 걸려있는 테이블이 존재할 경우에도 불가능하다. 상태를 변경하기 위해서는 Alter Tablespace Online/Offline 구문을 사용한다. 단, 테이블스페이스의 온라인/오프라인의 상태 전이는 메타(Meta) 단계와 서비스(Service) 단계에서만 가능하다. 온라인(Online) 테이블스페이스와 관련된 모든 자원이 할당되고 준비된 상태이며, 데이터베이스에서 테이블스페이스를 사용할 수 있게 설정한 상태이다. 테이블스페이스와 그 안에 존재하는 테이블과 인덱스에 대해 DML 과 DDL 을 수행할 수 있다. 만약 온라인 상태인 테이블스페이스와 테이블스페이스에 생성된 테이블 및 인덱스를 일시적으로 사용할 수 없게 하려면 Alter Tablespace Offline 구문을 실행하면 된다. 오프라인(Ofline) 테이블스페이스와 관련된 모든 자원이 해제된 상태이며, 데이터베이스에서 테이블스페이스를 일시적으로 사용할 수 없게 설정된 상태이다. 테이블스페이스에 존재하는 테이블과 인덱스에 대한 DML 과 DDL 을 수행할 수 없다. 그러나 테이블스페이스에 대한 DDL 은 Drop Tablespace 와 Alter Tablespace Online 구문만 사용할 수 있다. 테이블스페이스와 그 안에 생성된 테이블과 인덱스를 다시 사용할 수 있는 온라인 상태로 전이하기 위해서는 Alter Tablespace Online 구문을 사용한다. 오프라인으로 설정된 경우 메모리 테이블스페이스의 객체는 324 ALTIBASE5 Administrator’s Manual 메모리에 적재되지 않기 때문에, 메모리 한계(메모리 부족) 상황에서 사용자가 직접 테이블스페이스를 오프라인으로 변경하여 사용할 수 있다. 디스카드(Discard) 데이터의 일관성이 깨진 특정 테이블스페이스 때문에 정상적인 알티베이스 구동이 불가능한 경우, 깨진 테이블스페이스를 제외한 나머지에 대해서만 정상적으로 운영할 수 있어야 한다. 이 때 해당 테이블스페이스를 디스카드 시켜서 알티베이스를 정상 구동시킨다. 특정 테이블스페이스를 디스카드 상태로 전이시키기 위해서는 컨트롤 단계에서만 Alter Tablespace Discard 구문으로 가능하다. 그러나 한 번 디스카드된 테이블스페이스는 제거(Drop Tablespace)만 가능하기 때문에 Alter Tablespace Discard 구문을 수행할 때에는 주의해야 한다. 테이블스페이스 325 테이블스페이스 관리 본 절에서는 알티베이스에서 지원하는 테이블스페이스를 관리하는 방법에 대해 설명한다 생성(CREATE) 테이블스페이스 생성은 SYS 사용자 이거나 테이블스페이스 생성 권한을 가진 사용자여야 한다. 테이블스페이스 생성시 ‘CREATE TABLESPACE … SQL’ 구문을 사용하며, 사용자 정의 데이터 테이블스페이스(User Data Tablespace)만 생성이 가능하다. 즉 시스템 테이블스페이스들은 사용자가 임의적으로 생성할수 없다. 디스크 테이블스페이스는 디스크 데이터 테이블스페이스와 디스크 임시 테이블스페이스를 지원한다. 메모리 테이블스페이스는 메모리 데이터 테이블스페이스만을 지원하고, 메모리 임시 테이블스페이스는 지원하지 않는다. 또한 휘발성 테이블스페이스는 휘발성 데이터 테이블스페이스만을 지원하고, 휘발성 임시 테이블스페이스는 지원하지 않는다. 다음은 테이블스페이스를 생성하기 위한 SQL 구문을 설명한다. CREATE [DISK/MEMORY/VOLATILE] [DATA/TEMPORARY] TABLESPACE (1) 테이블스페이스 이름 (2) 디스크 데이터 파일 속성 (3) 디스크 임시 파일 속성 (4) 메모리 테이블스페이스 속성 (5) 휘발성 테이블스페이스 속성 ; 테이블스페이스 생성시 객체의 크기및 접근 빈도수와 같은 특성을 고려해서 메모리와 디스크, 휘발성의 사용여부를 결정해야 한다. 테이블스페이스 생성시 지정할 수 있는 테이블스페이스 속성들은 디스크와 메모리, 휘발성으로 나누어 다르게 적용된다. 메모리 테이블스페이스는 여러개의 데이터 파일로 관리되는 디스크 테이블스페이스와는 달리 객체들이 하나의 선형적인 메모리 공간에 저장된다. 따라서, 디스크 테이블스페이스 생성의 경우 지정된 속성은 각각의 데이터 파일에 적용되며, 메모리 테이블스페이스는 테이블스페이스 전체에 적용된다. 즉 메모리 테이블스페이스에 초기 크기, 확장될 크기 등이 적용되며, 디스크 테이블스페이스는 데이터 파일에 해당 속성들이 적용된다. 테이블스페이스 이름 테이블스페이스는 동일한 이름의 객체가 두개 이상 생성될 수 326 ALTIBASE5 Administrator’s Manual 없으므로 유일한 것이어야 한다. 디스크 테이블스페이스는 데이터 파일들의 이름을 지정할 수 있지만, 메모리 테이블스페이스는 체크포인트 이미지가 저장될 경로만을 지정할 수 있다. 체크포인트 이미지 이름은 테이블스페이스의 이름을 이용하여 자동으로 만들어진다. 디스크 데이터 파일 속성 데이터 파일 속성은 디스크 데이터 테이블스페이스에만 적용되며, 다음과 같은 구문을 갖는다. DATAFILE [①데이터 파일절 AUTOEXTEND [②자동확장절 MAXSIZE [③최대크기절] ] ] EXTENTSIZE [④익스텐트사이즈절] 각 데이터 파일은 다음과 같은 속성을 가질 수 있다. 데이터 파일절 DATAFILE {데이터 파일 경로 및 이름} SIZE integer [K/M/G] [REUSE] 데이터 파일 경로 및 이름을 지정한다. SIZE 절 이하는 생략이 가능하다. SIZE 절은 데이터 파일이 생성될때의 초기 데이터 파일의 크기를 명시하기 위한 구문이다. 각 데이터 파일에는 파일 헤더가 저장되며, 파일 헤더 크기(1 page)를 제외한 나머지 페이지들의 총 크기를 의미한다. 따라서, 초기 크기와 데이터 파일의 크기가 정확히 일치하지는 않는다. 만약 운영 체제에서 지원하는 최대 파일 크기가 초기 크기보다 작을 경우 운영 체제의 최대 파일 크기로 설정된다. 자동확장절 AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 디스크 데이터 파일의 확장 여부를 결정한다. ON 일 경우 시스템에 의해서 데이터 파일이 자동으로 확장되며, OFF 일 경우 사용자가 명시적으로 파일을 확장해야 한다. 확장의 단위를 사용자가 명시할 수 있으며, NEXT 절 이하는 확장의 크기를 나타낸다. 데이터 파일이 확장될 때 해당 데이터 파일이 속한 테이블스페이스에서 수행되는 모든 연산은 해당 데이터 파일이 확장될때까지 대기한다. 최대크기절 MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장절의 부속절로써, 데이터 파일이 확장될수 있는 최대 크기를 의미한다. 초기 크기와 마찬가지로 만약 운영 체제에서 지원하는 최대 파일 크기가 데이터 파일의 최대 크기보다 작을 경우 운영 테이블스페이스 327 체제의 최대 파일 크기로 설정된다. UNLIMITED 로 설정된 경우에는 디스크가 공간을 모두 사용할 때까지 사이즈가 늘어난다. 익스텐트 사이즈절 MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 테이블스페이스에 저장되는 세그먼트(테이블 또는 인덱스)가 할당받는 페이지의 단위인 익스텐트의 사이즈를 정의한다. 익스텐트 사이즈를 명시하지 않을 경우 기본값으로 256K(32 pages)를 갖는다. 디스크 임시 파일 속성 임시 파일 속성은 디스크 임시 테이블스페이스에만 적용되며, 다음과 같은 구문을 갖는다. TEMPFILE {①임시 파일절} AUTOEXTED [②자동확장절 MAXSIZE [③최대크기절] ] EXTENDSIZE [④익스텐트사이즈절] 각 임시 파일은 다음과 같은 속성을 가질 수 있다. 임시 파일절 TEMPFILE {데이터 파일 경로 및 이름} SIZE integer [K/M/G] [REUSE] 임시 파일 경로 및 이름을 지정해야 하며, SIZE 절 이하는 생략 가능하다. SIZE 절은 임시 파일이 생성될 때의 초기 임시 파일의 크기를 명시하기 위한 구문이다. 각 임시 파일에는 파일 헤더가 저장되며, 파일 헤더 크기(1 page)를 제외한 나머지 페이지들의 총 크기를 의미한다. 따라서, 초기 크기와 임시 파일의 크기가 동일하지 않다. 만약 운영 체제에서 지원하는 최대 파일 크기가 초기 크기보다 작을 경우 운영 체제의 최대 파일 크기로 설정된다. 자동확장절 AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 디스크 임시 테이블스페이스의 확장 여부를 결정한다. ON 일 경우 시스템에 의해서 테이블스페이스가 자동으로 확장되며, OFF 일 경우 사용자가 명시적으로 파일을 확장해야 한다. 확장의 단위를 사용자가 명시할수 있으며, NEXT 절 이하는 확장의 크기를 나타낸다. 최대크기절 MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장절의 부속절로써, 임시 파일이 확장될 수 있는 최대 크기를 의미한다. 초기 크기와 마찬가지로 만약 운영 체제에서 지원하는 최대 파일 크기가 임시 파일의 최대 크기보다 작을 경우 운영 328 ALTIBASE5 Administrator’s Manual 체제의 최대 파일 크기로 설정된다. UNLIMITED 로 설정된 경우에는 디스크가 공간이 풀(full)될때까지 사이즈가 늘어난다. 익스텐트 사이즈절 EXTENTSIZE integer [K/M/G] 임시 테이블스페이스에 저장되는 세그먼트(테이블 또는 인덱스)가 할당 받는 페이지의 단위인 익스텐트의 사이즈를 정의한다. 익스텐트 사이즈를 명시하지 않을 경우 기본값으로 256K(32 pages)를 갖는다. 메모리 테이블스페이스 속성 메모리 테이블스페이스에 적용되는 속성은 디스크 테이블스페이스의 데이터 파일 속성과 유사하지만, 추가적으로 체크포인트 이미지 경로를 지원한다. 구문은 다음과 같다. SIZE {①초기 크기절} AUTOEXTED [②자동확장절 MAXSIZE [③최대크기절] ] CHECKPOINT PATH [④체크포인트 이미지 경로절] 각 데이터 파일은 다음과 같은 속성을 가질 수 있다. 초기 크기절 SIZE integer [K/M/G] 메모리 테이블스페이스 생성시 초기에 할당되어야할 메모리 크기를 나타낸다. 이 값은 메모리 테이블스페이스의 기본 확장 단위의 배수여야 한다. (EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 지정한 페이지 개수 * 메모리 테이블스페이스의 페이지 크기(32KB) 3 ) KiloBytes (K), Megabytes (M), 또는 Gigabytes (G) 단위로 크기를 명시할 수 있으며 이 단위를 명시하지 않을 경우 기본 단위는 K 이다. 자동확장절 AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 메모리 테이블스페이스의 확장 여부를 결정한다. ON 일 경우 시스템에 의해서 테이블스페이스가 자동으로 확장되며, OFF 일 경우 사용자가 명시적으로 파일을 확장해야 한다. 확장의 단위를 사용자가 명시할수 있으며, NEXT 절 이하는 확장의 크기를 나타낸다. 확장되는 크기는 초기 크기와 마찬가지로 3 예를들어 EXPAND_CHUNK_PAGE_COUNT 를 128 로 지정하였다면, 메모리 테이블스페이스의 기본 확장 크기는 128 * 32K 로 계산되며, 값은 4MB 가 된다. 그러므로 SIZE 로 지정할 수 있는 크기는 4MB 의 배수여야 한다. 테이블스페이스 329 EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 설정된 페이지의 배수에 해당하는 크기로 지정하여야 한다. 자동 확장 크기가 너무 작으면 자동확장이 너무 빈번하게 발생할 수 있다. 알티베이스는 자동확장을 수행할 때 시스템에 존재하는 모든 메모리 테이블스페이스의 현재 크기를 합산하여 MEM_MAX_DB_SIZE 프로퍼티에 지정한 크기보다 작은지 비교하게 되는데, 이러한 연산을 빈번하게 수행하여 시스템의 성능이 저하될 여지가 있다. 최대크기절 MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장절의 부속절로써, 메모리 테이블스페이스가 확장될수 있는 최대 크기를 의미한다. 초기 크기와 마찬가지로 운영 체제에서 제공되는 메모리 공간의 크기를 초과할 수 없다. UNLIMITED 로 설정된 경우에는 시스템에 존재하는 모든 메모리 테이블스페이스의 크기를 합친 전체 크기가 MEM_MAX_DB_SIZE 프로퍼티에 지정한 크기를 벗어나지 않는 한도 내에서 테이블스페이스가 자동확장된다. 체크포인트 이미지 경로절 CHECKPOINT PATH ‘체크포인트 이미지 경로 리스트’ SPLIT EACH integer [K/M/G] 체크포인트 이미지 경로는 메모리 테이블스페이스에만 해당한다. 알티베이스 메모리 테이블스페이스은 고성능 트랜잭션 처리를 위하여 핑퐁(ping-pong) 체크포인트를 사용한다. 핑퐁 체크포인트시 최소한 2 벌의 체크포인트 이미지를 디스크에 생성하며, 각각 체크포인트 이미지는 다수의 파일에 분할되어 저장될 수 있다. 분할 크기는 SPLIT EACH 절에 의해서 명시될수 있다. 분할된 파일은 디스크 입출력 비용을 분산하기 위하여 다수의 경로에 저장될 수 있으며, 사용자가 임의로 분할의 크기 및 체크포인트 이미지들이 저장되는 경로들을 지정할 수 있다. 체크포인트 이미지 경로는 사용자가 경로를 추가하거나 변경 가능하지만, 한번 지정된 분할의 크기는 변경될 수 없다. 휘발성 테이블스페이스 속성 휘발성 테이블스페이스에 적용되는 속성은 메모리 테이블스페이스의 속성과 유사하지만, 체크포인트 이미지 경로를 지원하지 않는다. SIZE {①초기 크기절} AUTOEXTED [②자동확장절 MAXSIZE [③최대크기절] ] 각 데이터 파일은 다음과 같은 속성을 가질 수 있다. 330 ALTIBASE5 Administrator’s Manual 초기크기절 SIZE integer [K/M/G] 휘발성 테이블스페이스 생성시 초기에 할당되어야 할 메모리 크기를 나타낸다. 이 값은 메모리 테이블스페이스의 기본 확장 단위의 배수여야 한다. (EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 지정한 페이지 개수 * 메모리 테이블스페이스의 페이지 크기 (32KB)) 크기 단위로는 KiloBytes (K), MegaBytes (M), 또는 GigaBytes (G)를 명시할 수 있으며 이 단위를 명시하지 않을 경우 기본 단위는 K 가 된다. 자동확장절 AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 휘발성 테이블스페이스의 확장 여부를 결정한다. ON 일 경우 시스템에 의해서 테이블스페이스가 자동으로 확장되며, OFF 일 경우 사용자가 명시적으로 테이블스페이스를 확장해야 한다. 확장의 단위를 사용자가 명시할수 있으며, NEXT 절 이하는 확장의 크기를 나타낸다. 확장되는 크기는 초기 크기와 마찬가지로 EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 설정된 페이지의 배수에 해당하는 크기로 지정하여야 한다. 자동 확장 크기가 너무 작으면 자동확장이 너무 빈번하게 발생할 수 있다. 알티베이스는 자동확장을 수행할 때 시스템에 존재하는 모든 휘발성 테이블스페이스의 현재 크기를 합산하여, VOL_MAX_DB_SIZE 프로퍼티에 지정한 크기보다 작은지 비교하게 되는데, 이러한 연산을 빈번하게 수행하여 시스템의 성능이 저하될 여지가 있다. 최대크기절 MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장절의 부속절로써, 휘발성 테이블스페이스가 확장될수 있는 최대 크기를 의미한다. 초기 크기와 마찬가지로 운영 체제에서 제공되는 메모리 공간의 크기를 초과할 수 없다. UNLIMITED 로 설정된 경우에는 시스템에 존재하는 모든 휘발성 테이블스페이스의 크기를 합친 전체 크기가 VOLATILE_MAX_DB_SIZE 프로퍼티에 지정한 크기를 벗어나지 않는 한도 내에서 테이블스페이스가 자동확장된다. 예제 테이블스페이스 331 세개의 데이터 파일을 가지는 디스크 데이터 테이블스페이스를 생성한다. iSQL> CREATE DISK DATA TABLESPACE user_data DATAFILE ‘/tmp/tbs1.user’ SIZE 10M AUTOEXTEND ON NEXT 1M MAXSIZE 1G, ‘/tmp/tbs2.user’ SIZE 10M AUTOEXTEND ON NEXT 1M MAXSIZE 500M, ‘/tmp/tbs3.user’ SIZE 10M AUTOEXTEND ON NEXT 1M MAXSIZE 1G; Create success. 메모리 데이터 테이블스페이스를 생성한다. iSQL> CREATE MEMORY DATA TABLESPACE user_data SIZE 12M AUTOEXTEND ON NEXT 4M MAXSIZE 500M CHECKPOINT PATH ‘/tmp/checkpoint_image_path1’, ‘/tmp/checkpoint_image_path2’ SPLIT EACH 12M; Create success. 휘발성 데이터 테이블스페이스를 생성한다. iSQL> CREATE VOLATILE DATA TABLESPACE user_data SIZE 12M AUTOEXTEND ON NEXT 4M MAXSIZE 500M; Create success. 삭제(DROP) 테이블스페이스 삭제는 SYS 사용자 이거나 테이블스페이스 삭제 권한을 가진 사용자여야 한다. 테이블스페이스 삭제시 DROP TABLESPACE … SQL 구문을 사용하며, 시스템 테이블스페이스들은 사용자에 의해서 삭제될 수 없다. 테이블스페이스의 삭제는 메모리나 디스크, 휘발성을 명시적으로 구분하지 않으며, 아래와 같은 구문을 갖는다. DROP TABLESPACE {테이블스페이스 이름} [{⑴객체 삭제절} [⑵데이터 파일 삭제절] [⑶제약사항 삭제절]]; 테이블스페이스의 이름을 이용하여 삭제를 수행하며 선택할 수 있는 옵션은 아래와 같다. 만약 아래 옵션들을 선택하지 않는다면 테이블스페이스의 스키마만이 로그앵커(loganchor)에서 삭제된다. 객체 삭제절 INCLUDING CONTENTS 테이블스페이스내 객체(테이블 또는 인덱스)들의 내용을 삭제한다. 만약 테이블스페이스내에 하나 이상의 객체가 존재한다면 반드시 해당 옵션을 선택해야 한다. 그렇지 않을 경우, 테이블스페이스 삭제 연산은 실패한다. 데이터 파일 삭제절 INCLUDING CONTENTS AND DATAFILES 객체 삭제절을 명시하였을 경우, 객체의 레코드및 키가 삭제되지만 332 ALTIBASE5 Administrator’s Manual 데이터 파일 자체가 삭제되는 것은 아니다. 따라서, 데이터 파일을 지우기 위해서는 데이터 파일 삭제절을 명시해야 한다. 데이터 파일 삭제절은 객체 삭제절의 부속절로써, 테이블스페이스가 가지고 있는 모든 데이터 파일을 물리적으로 삭제한다. 해당 옵션은 디스크 테이블스페이스에 국한된 옵션이며, 메모리 테이블스페이스의 경우에는 해당 옵션은 무시된다. 그리고 휘발성 테이블스페이스의 경우에 AND DATAFILES 구문을 사용하면 에러를 발생시킨다. 제약사항 삭제절 INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS 객체 삭제절의 부속절로써, 테이블스페이스내 객체들을 참조하는 제약사항(constraints)가 존재하는 경우 “The tablespace has objects” 에러가 발생하며 실패하게 된다. 이럴 경우에 객체와 참조를 삭제하기 위해 해당 구문이 사용될수 있다. 변경(ALTER) 테이블스페이스 변경은 SYS 사용자이거나 테이블스페이스 변경 권한을 가진 사용자여야 한다. 테이블스페이스 변경시 ALTER TABLESPACE ... SQL 구문을 사용하며, 기존의 테이블스페이스의 정의를 변경하거나 하나 이상의 데이터 파일 또는 임시 파일의 속성, 메모리 테이블스페이스, 휘발성 테이블스페이스의 속성을 변경한다. 다음은 SQL 구문을 설명한다. ALTER TABLESPACE {테이블스페이스 이름} {{⑴디스크 데이터 파일 변경절}/ {⑵디스크 임시 파일 변경절}/ {⑶메모리 테이블스페이스 변경절}/ {⑷휘발성 테이블스페이스 변경절}/ {⑸테이블스페이스 상태 변경절}}; 디스크 데이터 파일 변경절 디스크 시스템 테이블스페이스와 디스크 데이터 테이블스페이스에 해당 되며, 아래와 같은 사항들이 변경될 수 있다. ALTER TABLESPACE {테이블스페이스 이름} {①테이터파일 추가절/ ②데이터 파일 삭제절/ ③데이터 파일 크기 변경절/ ④데이터 파일 이름 변경절} 테이터파일 추가절 ADD {DATAFILE} {데이터 파일절} AUTOEXTEND [자동확장절 MAXSIZE [최대크기절] ] 테이블스페이스 333 디스크 테이블스페이스에서 데이터를 저장할 공간을 확장하려 할때 사용한다. 해당 옵션은 테이블스페이스 생성시에 데이터 파일에 적용되는 구문과 동일하다. 데이터 파일 삭제절 DROP {DATAFILE} {데이터 파일명} 디스크 테이블스페이스에서 데이터를 저장할 공간을 축소하려 할때 사용한다.데이터 파일 추가에 의한 확장은 자유롭게 수행할 수 있지만, 데이터 파일의 삭제는 해당 데이터 파일이 현재 사용중이지 않을때(해당 데이터 파일까지 익스텐트가 확장되지 않았을때)만 가능하다. 데이터 파일 크기 변경절 ALTER {DATAFILE} {데이터 파일명} {{AUTOEXTEND [자동 확장절]} / {SIZE [크기 변경절]}} 테이블스페이스에 속하는 각 데이터 파일들의 현재 크기, 최대 크기, 확장 단위및 자동확장 유무등을 변경한다. 현재 크기및 최대 크기 변경시 현재 테이블스페이스의 페이지 사용이 변경하고자 하는 현재 크기및 최대 크기를 초과하지 않는 경우에만 가능하다. 데이터 파일 이름 변경절 RENAME {DATAFILE} {기존 데이터 파일 경로및 이름} TO {새로운 데이터 파일 경로및 이름} 데이터 파일의 위치를 변경함으로써 테이블스페이스의 데이터가 저장된 파일 시스템을 변경하는 것이다. 본 기능은 어떤 단계에서도 수행 가능하며 온라인이나 오프라인에 상관없이 할 수 있지만, 서비스 단계에서는 오프라인 상태인 테이블스페이스에 대해서만 수행할 수 있다. 디스크 임시 파일 변경절 디스크 임시 테이블스페이스에만 해당 되며, 아래와 같은 사항들이 변경될 수 있다. ALTER TABLESPACE {테이블스페이스 이름} {①임시 파일 추가절/ ② 임시 파일 삭제절/ ③ 임시 파일 크기 변경절/ ④ 임시 파일 이름 변경절} 임시 파일 추가절 334 ALTIBASE5 Administrator’s Manual ADD {TEMPFILE} {임시 파일절} AUTOEXTEND [자동확장절 MAXSIZE [최대크기절]] 디스크 테이블스페이스에서 데이터를 저장할 공간을 확장하려 할때 사용한다. 해당 옵션은 디스크 임시 테이블스페이스 생성시에 임시 파일에 적용되는 구문과 동일하다. 임시 파일 삭제절 DROP {TEMPFILE} {임시 파일명} 디스크 임시 테이블스페이스에서 데이터를 저장할 공간을 축소하려 할때 사용한다. 데이터 파일 추가에 의한 확장은 자유롭게 수행할 수 있지만, 데이터 파일의 삭제는 해당 데이터 파일이 현재 사용중이지 않을때(해당 데이터 파일까지 익스텐트가 확장되지 않았을때)만 가능하다. 임시 파일 크기 변경절 ALTER {TEMPFILE} {임시 파일명} {{AUTOEXTEND [자동 확장절]} / {SIZE [크기 변경절]}} 테이블스페이스에 속하는 각 임시 파일들의 현재 크기, 최대 크기, 확장 단위및 자동확장 유무등을 변경한다. 현재 크기및 최대 크기 변경시 현재 테이블스페이스의 페이지 사용이 변경하고자 하는 현재 크기및 최대 크기를 초과하지 않는 경우에만 가능하다. 임시 파일 이름 변경절 RENAME {TEMPFILE} {기존 임시 파일 경로및 이름} TO {새로운 임시 파일 경로및 이름} 임시 파일의 위치를 변경함으로써 테이블스페이스의 데이터가 저장된 파일 시스템을 변경하는 것이다. 해당 기능은 어떤 단계에서도 수행 가능하며 온라인이나 오프라인에 상관없이 할 수 있다. 하지만, 서비스 단계에서는 오프라인 상태인 테이블스페이스에 대해서만 수행할 수 있다. 메모리 테이블스페이스 변경절 메모리 시스템 테이블스페이스와 메모리 사용자 정의 테이블스페이스에 해당되며, 아래와 같은 사항들이 변경될 수 있다. 체크포인트 경로에 대한 추가, 삭제 및 변경은 다단계 구동중 어느 단계에서도 수행 가능하다. 그러나 서비스 단계에서는 오프라인 테이블스페이스만 변경이 가능하다. ALTER TABLESPACE {테이블스페이스 이름} {① 체크포인트 경로 추가절/ ② 체크포인트 경로 삭제절/ ③ 체크포인트 경로 변경절/ 테이블스페이스 335 ④ 테이블스페이스 크기 변경절} 체크포인트 경로 추가절 ADD CHECKPOINT PATH {디렉토리 경로} 체크포인트 이미지 경로를 추가적으로 설정한다. 체크포인트 경로 삭제절 DROP CHECKPOINT PATH {디렉토리 경로} 기존 체크포인트 이미지 경로를 삭제한다. 체크포인트 경로 변경절 RENAME CHECKPOINT PATH {기존 디렉토리 경로} TO {새로운 디렉토리 경로} 기존 체크포인트 이미지 경로를 새로운 경로로 변경한다. 테이블스페이스 크기 변경절 ALTER {AUTOEXTEND [자동 확장절]} / {SIZE [크기 변경절]} 메모리 테이블스페이스의 최대 크기, 확장 단위, 자동확장 유무등을 변경한다. 휘발성 테이블스페이스 변경절 휘발성 사용자 정의 테이블스페이스에 해당되며, 아래와 같은 사항들이 변경될 수 있다. ALTER TABLESPACE {테이블스페이스 이름} {① 테이블스페이스 크기 변경절} 테이블스페이스 크기 변경절 ALTER {AUTOEXTEND [자동 확장절]} / {SIZE [크기 변경절]} 메모리 테이블스페이스의 최대 크기, 확장 단위, 자동확장 유무 등을 변경한다. 테이블스페이스 상태 변경절 테이블스페이스의 속성은 온라인과 오프라인이 있으며 다음과 같은 구문을 갖는다. ALTER TABLESPACE {테이블스페이스 이름} {ONLINE/OFLINE/DISCARD} 336 ALTIBASE5 Administrator’s Manual 온라인 상태는 테이블스페이스에 속한 모든 객체에 사용자가 접근할 수 있는 일반적인 상태이다. 반면 오프라인 상태는 테이블스페이스 관련 DDL 을 제외한 다른 연산에 의해 테이블스페이스 객체에 접근할수 없는 상태이다. 이러한 오프라인 상태를 이용하여 한계 상황 극복이나 서비스 단계에서의 RENAME 연산 등을 할 수 있다. 단 시스템 테이블스페이스는 오프라인으로 변경될수 없으며, 항상 온라인 상태로 유지된다. 휘발성 테이블스페이스에 대해서는 이 구문을 사용할 수 없다. 디스카드 기능은 알티베이스에서 운용중인 여러 테이블스페이스 중 특정 테이블스페이스의 데이터에 오류가 발생 4 하여 알티베이스가 기동되지 않는 문제가 발생할 경우에 사용된다. 해당 테이블스페이스를 디스카드(DISCARD)함으로써 해당 테이블스페이스를 버리는 대신, 나머지 테이블스페이스로 알티베이스를 기동할 수 있다. 한번 디스카드된 테이블스페이스는 제거(DROP)외에 다른 연산은 사용이 불가하게 되므로, 사용에 신중을 기하여야 한다. 아울러, 테이블스페이스 디스카드는 오직 컨트롤(CONTROL)단계에서만 수행이 가능하다. 테이블스페이스 디스크, 메모리 데이터 테이블스페이스에 사용할 수 있다. 테이블스페이스 백업 및 복구 이번 절에서는 테이블스페이스의 온라인/오프라인 백업의 개념 및 특징을 간단하게 설명한다. 자세한 백업구문과 방법은 Administrator’s 매뉴얼과 Starting 매뉴얼을 참고한다. 테이블스페이스 온라인 백업(HOT 백업) 테이블스페이스의 온라인 백업은 테이블스페이스의 서비스를 진행하면서 백업을 하는 것이다. 따라서, 온라인 백업 방식은 트랜잭션 진행에는 영향을 주지 않기 때문에 서비스 단계에서 이루어질 수 있으며 다음의 몇 가지 특징을 갖는다. 온라인 백업의 특징 y 데이터베이스가 아카이브 로그 모드로 운영될 때만 가능하다. y 아카이브 로그 모드로 운영되면 체크포인트와 로그 플러시(Log Flush) 후에도 로그 파일을 별도의 스토리지에 백업하므로 대용량의 스토리지를 필수로 준비해야 한다. 4 예) DBA 가 실수로 특정 메모리 테이블스페이스의 체크포인트 이미지 파일을 삭제했다고 가정한다. 이 경우에 서버 기동시 해당 메모리 테이블스페이스를 로드할 수 없기 때문에 매체 복구를 이용하여 삭제된 체크포인트 이미지를 재생성하는 방법을 먼저 생각해볼 수 있다. 그러나, 아카이브 로깅을 사용하지 않고 있다면, 매체 복구가 불가능하기 때문에 이와 같인 방법은 사용할 수가 없다. 이 때 만약 해당 테이블스페이스를 삭제해도 상관이 없다면, 디스카드 기능을 이용하여 해당 테이블스페이스를 제외하고 DB 를 구동한 후 테이블스페이스를 제거하면 된다. 테이블스페이스 337 y Alter database backup 구문을 이용해서 데이터베이스 운영 중에 백업할 수 있다. y 장애로 인하여 데이터 파일이 손상되거나 지워지는 경우에도 데이터 파일의 현재 시점까지 매체 복구(media recovery)가 가능하다. [ 그림 5-14] 매체 복구(Media Recovery)의 개념 y 디스크 테이블스페이스의 데이터 파일 xyz가 손상되었을 경우에 이전에 HOT 백업해 두었던 데이터 파일을 이용해서 복구가 가능하다. 메모리 테이블스페이스의 경우는 이전에 HOT 백업해 두었던 체크포인트 이미지 파일을 이용해서 복구가 가능하다. y 백업해 둔 데이터 파일의 헤더에 백업 시점에 최종 체크포인트된 SCN(140)과 recovery LSN(32:010)이 있으므로 이를 기준으로 현재의 최종 체크포인트 SCN(200)까지 데이터 파일을 복원할 수 있다. y 재시작 시점에 온라인로그의 리두/언두(Redo/Undo)를 통해 데이터 파일 또는 메모리 테이블스페이스가 최종 상태의 이미지로 복구된다. 테이블스페이스 오프라인 백업(Cold 백업) 테이블스페이스의 오프라인 백업은 테이블스페이스의 서비스 진행을 중단하고, 백업하는 형태를 의미한다. 오프라인 백업 방식은 온라인 백업보다 빠른 시간 내에 백업을 완료하고, 회복에 걸리는 시간을 단축시킨다. 오프라인 백업은 다음과 같은 특징을 갖는다. 오프라인 백업의 특징 y 데이터베이스가 노 아카이브 모드로 운영될 때 가능하다. 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 338 ALTIBASE5 Administrator’s Manual y 오프라인 백업이란 데이터베이스 서버를 정상 셧다운(shutdown)시키고 나서 데이터 파일, 로그 파일, 로그 앵커(log anchor) 파일 등을 복사해 놓는 방식이다. y 장애로 인하여 데이터 파일이 손상되거나 지워지는 경우에 최종 오프라인 백업된 시점까지만 복구가 가능하다. 오프라인 복구 복구는 백업 이미지를 바탕으로 데이터베이스를 일관적인 상태로 만드는 과정을 의미한다. 복구는 온라인에서 진행될 수 없으며, 반드시 오프라인에서 진행되어야 한다. 데이터베이스의 서비스를 중지한 상태에서 기존 데이터베이스를 오프라인 백업된 파일로 바꾼 후에 재시작함으로써 복구가 수행된다. 테이블스페이스 339 테이블스페이스 사용 예제 본 절에서는 메모리 테이블스페이스와 휘발성 테이블스페이스 사용 예제를 살펴본다. 테이블스페이스의 사용예를 다룬다. 메모리 테이블스페이스 메모리 테이블스페이스 생성 기본 메모리테이블스페이스를 생성하는 가장 간편한 방법은 CREATE MEMORY TABLESPACE 구문을 이용하여 SIZE 절에 초기 크기를 지정하는 방법이다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M; Create success. 이 경우 기본적으로 자동확장 모드는 OFF 가 되며, 테이블스페이스의 크기인 256M 의 공간을 전부 사용하게 된다. 해당 테이블스페이스에 공간을 추가로 할당할 때 5 테이블스페이스 공간이 부족하다는 에러 메시지가 발생한다. 또한 체크포인트 경로는 기본적으로 MEM_DB_DIR 프로퍼티에 지정한 하나 혹은 그 이상의 체크포인트 경로를 새로 생성된 테이블스페이스의 체크포인트 경로로 사용하게 된다. 다음은 알티베이스 프로퍼티 파일의 일부이다. MEM_DB_DIR 을 두 개 지정하고 있으며, 알티베이스 홈 디렉토리에 dbs1 와 dbs2 로 명시하고 있다. # altibase.properties MEM_DB_DIR = ?/dbs1 MEM_DB_DIR = ?/dbs2 이와 같은 경우에 앞서 생성한 USER_MEM_TBS 에는 다음과 같이 MEM_DB_DIR 에 지정한 dbs1 과 dbs2 가 체크포인트 경로로 지정된 것을 확인할 수 있다. iSQL> SELECT CHECKPOINT_PATH FROM V$MEM_TABLESPACE_CHECKPOINT_PATHS WHERE SPACE_ID = (SELECT SPACE_ID FROM V$MEM_TABLESPACES WHERE SPACE_NAME='USER_MEM_TBS'); CHECKPOINT_PATH --------------------------------------- /altibase_home/dbs1 5 테이블스페이스에 테이블을 생성, 혹은 이미 생성되어 있는 테이블을 입력하거나 수정하는 경우 테이블스페이스로부터 공간을 추가로 할당하게 할당받는다. 340 ALTIBASE5 Administrator’s Manual /altibase_home/dbs2 2 rows selected. 우선, 체크포인트 경로 안의 파일들을 살펴보자. 우선 dbs1 디렉토리 안의 파일을 살펴보면, 다음과 같이 6 개의 파일이 존재하는 것을 볼 수 있다. SYS_TBS_MEM_DATA-0-0 SYS_TBS_MEM_DATA-1-0 SYS_TBS_MEM_DIC-0-0 SYS_TBS_MEM_DIC-1-0 USER_MEM_TBS-0-0 USER_MEM_TBS-1-0 이 파일들은 모두 메모리 테이블스페이스의 체크포인트 이미지 파일이다. 형식은 ‘테이블스페이스이름-{Ping Pong 번호}- {파일번호}’이다. ‘Ping Pong 번호’는 핑퐁 체크포인트 6 시에 두 개의 체크포인트 이미지를 사용하는데, 이를 각각 0 번과 1 번으로 번호를 매긴 것이다. 또한, 이러한 두 벌의 핑퐁 체크포인트 이미지를 여러 개의 파일로 나누어 기록하는데, 맨 마지막의 ‘파일번호’가 바로 나누어진 체크포인트 이미지 파일의 번호이며, 0 부터 시작하여 1 씩 증가한다. CREATE TABLESPACE 구문에서 SPLIT EACH 절에 지정하는 크기가 바로 체크포인트 이미지 파일 하나의 크기가 된다. 위의 CREATE MEMORY TABLESPACE 구문에서는 SPLIT EACH 절을 사용하지 않기 때문에, 기본값으로 DEFAULT_MEM_DB_FILE_SIZE 프로퍼티에 지정된 1GB 단위로 체크포인트 이미지 파일들을 분할하게 된다. 위 세 개의 테이블스페이스 사용된 공간이 아직 1GB 에 도달하지 않았기 때문에, 파일번호는 0 까지만 존재하는 것을 확인할 수 있다. 위에서 SYS_TBS_MEM_DIC 은 시스템 딕셔너리 테이블스페이스로, 메타 데이터를 지니는 테이블스페이스이다. 이 테이블스페이스는 데이터베이스 생성시 자동적으로 만들어진다. SYS_TBS_MEM_DATA 는 기본 시스템 데이터 테이블스페이스로, 사용자가 테이블을 생성할 때 테이블스페이스를 명시하지 않을 경우에 테이블의 데이터가 이 테이블스페이스에 저장된다. 마지막으로, USER_MEM_TBS 가 바로 앞서 생성한 사용자 데이터 테이블스페이스이다. 참고로, CREATE MEMORY TABLESPACE 구문에서 SIZE 절에 초기크기로 지정한 256MB 는 EXPAND_CHUNK_PAGE_COUNT 로 지정한 Page 개수의 배수여야 한다. 즉, 메모리 테이블스페이스 확장의 단위가 되는 6 메모리 상에 존재하는 테이블스페이스의 데이터의 영속성(Durability) 보장을 위해 디스크의 파일에 데이터를 저장한다. 이와같이 테이블스페이스의 데이터를 저장하는 파일을 체크포인트 이미지라고 한다. 알티베이스가 사용하는 핑퐁 체크포인트 방식은 두 벌의 체크포인트 이미지를 두고, 하나씩 번갈아 가면서 테이블스페이스의 데이터를 저장한다. 테이블스페이스 341 페이지수인 EXPAND_CHUNK_PAGE_COUNT 프로퍼티가 128 로 되어 있다면, 하나의 메모리 페이지는 32KB 이므로, 메모리 테이블스페이스 확장의 기본단위는 4MB 가 된다. 만약 SIZE 절의 크기가 EXPAND_CHUNK_PAGE_COUNT 만큼의 페이지 수로 나누어 떨어지지 않을 경우, 다음과 같이 에러가 발생한다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 1M; [ER-10E : The initial size of the tablespace should be multiple of expand chunk size ( EXPAND_CHUNK_PAGE_COUNT * PAGE_SIZE(32K) = 4096K )] 메모리 테이블스페이스 생성 종합 메모리 테이블스페이스의 다양한 생성 방법에 대해 알아본다. 다음은 테이블스페이스의 초기 크기를 256M, 자동확장 모드를 ON 으로 하고 한번 확장시마다 128M 씩 확장하되, 최대 1G 이상 확장되지 않도록 하는 예제이다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M AUTOEXTEND ON NEXT 128M MAXSIZE 1G; Create success. 이 때, 테이블스페이스의 자동확장 단위는 테이블스페이스의 초기 크기와 마찬가지로 테이블스페이스 확장의 기본 단위가 되는 EXPAND_CHUNK_PAGE_COUNT 프로퍼티의 배수로 설정되어야 한다. 자세한 내용은 ‘메모리 테이블스페이스의 생성 기본’을 참고한다. 다음과 같이 MAXSIZE 를 제한하지 않도록 테이블스페이스를 생성할 수 있다. MAXSIZE 절을 지정하지 않는 경우에도 기본적으로 UNLIMITED 를 지정한 것과 같이 동작한다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M AUTOEXTEND ON NEXT 128M MAXSIZE UNLIMITED; Create success. 이 경우 USER_MEM_TBS 는 시스템에 존재하는 모든 메모리 테이블스페이스에 할당된 크기가 MEM_MAX_DB_SIZE 를 벗어나지 않는 한도 내에서 확장된다. 다음과 같이 체크포인트 경로를 명시하여 메모리 테이블스페이스를 생성할 수도 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M CHECKPOINT PATH 'dbs1', '/new_disk/dbs2'; Create success. 위의 dbs1 과 같이 체크포인트 경로로 상대경로를 지정한 경우, $ALTIBASE_HOME 의 dbs1 을 지정한 것과 같다. 또한, CREATE 342 ALTIBASE5 Administrator’s Manual TABLESPACE 구문에 지정한 체크포인트 경로를 실제로 파일 시스템에 생성하고, 쓰기, 실행 권한을 주는 작업은 TABLESPACE 를 생성하기 전에 DBA 가 직접 수행하여야 한다. 다음과 같이 체크포인트 이미지 파일의 분할 크기를 결정할 수도 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M SPLIT EACH 512M; Create success. 체크포인트 이미지 파일의 분할크기 역시 테이블스페이스의 초기크기와 마찬가지로 EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 지정한 페이지 개수의 배수에 해당하는 크기로 지정되어야 한다. 자세한 내용은 ‘메모리 테이블스페이스의 생성(기본)’편을 참고한다. 테이블스페이스를 오프라인(OFFLINE) 상태로 생성해두고, 나중에 해당 테이블스페이스를 사용하기 전에 온라인(ONLINE) 상태로 전이할 수 있다. 메모리 테이블스페이스의 경우 생성된 크기만큼 시스템의 메모리를 차지하게 되므로, 생성후 즉시 사용하지 않을 경우, 이와 같은 방법으로 시스템의 리소스를 최적으로 활용할 수 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M OFFLINE; Create success. iSQL> ALTER TABLESPACE USER_MEM_TBS ONLINE; Alter success. 지금까지 살펴본 메모리 테이블스페이스 구문을 조합하여 여러가지 옵션을 동시에 주어 테이블스페이스를 생성할 수도 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M AUTOEXTEND ON NEXT 128M MAXSIZE 1G CHECKPOINT PATH 'dbs1', '/new_disk/dbs2' SPLIT EACH 512M OFFLINE; Create success. 메모리 테이블스페이스에 체크포인트 경로 추가 메모리 테이블스페이스에 체크포인트 경로를 추가하는 절차에 대해 알아본다. 메모리 테이블스페이스의 체크포인트 경로의 설정은 컨트롤(CONTROL)단계에서만 수행이 가능하다. 우선 알티베이스 서버를 셧다운 시킨 상태에서 다음과 같이 컨트롤 단계까지 알티베이스를 기동한다. $ isql -u sys -p manager -sysdba iSQL(sysdba)> startup process iSQL(sysdba)> startup control 컨트롤 단계에서는 테이블스페이스의 관련 퍼포먼스 뷰인 테이블스페이스 343 V$TABLESPACES 를 조회할 수 있다. 메모리 테이블스페이스 특유의 속성들을 볼 수 있는 퍼포먼스 뷰인 V$MEM_TABLESPACES 는 메타(META)단계 이후에만 조회가 가능하다. 대신, 컨트롤단계에서는 V$TABLESPACES 를 이용하여 테이블스페이스의 조회가 가능하다. 앞서 생성한 USER_MEM_TBS 에 속한 체크포인트 경로를 조회하기 위해서는 V$MEM_TABLESPACE_CHECKPOINT_PATHS 를 이용하면 된다. 만약 테이블스페이스의 데이터가 빈번하게 변경되어 체크포인트시 Disk I/O 의 양이 증가했다면, 다음과 같이 기존의 체크포인트 경로와 물리적으로 다른 디스크에 새로운 체크포인트 경로를 추가하면 된다. USER_MEM_TBS 에 /new_disk/dbs3 경로를 새로 추가해보자. 우선, 추가하고자 하는 체크포인트 경로를 생성하고, 알티베이스 프로세스가 해당 경로에 쓰기와 실행권한을 가지고 있어야 한다. 알티베이스 프로세스를 수행하는 유저명이 altibase 라고 가정한다. $ su - root $ mkdir /new_disk/dbs3 $ chown altibase /new_disk/dbs3 이제 다음과 같이 ADD CHECKPOINT PATH 구문을 이용하여 체크포인트 경로를 추가할 수 있다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS AD CHECKPOINT PATH '/new_disk/dbs3'; Alter success. 기존의 체크포인트 경로에 존재하는 체크포인트 이미지 파일들을 새로 추가된 체크포인트 경로로 이동해 주는 것은 DBA 의 책임이다. 알티베이스는 체크포인트 경로가 추가된 이후에 체크포인트가 발생할 경우, 새로 체크포인트 이미지 파일을 생성할 때, 추가된 체크포인트 경로에 체크포인트 이미지 파일을 생성한다. 7 메모리 테이블스페이스에 체크포인트 경로 변경 메모리 테이블스페이스에 체크포인트 경로를 변경하는 절차에 대해 알아본다. 메모리 테이블스페이스의 체크포인트 경로의 설정은 컨트롤(CONTROL)단계에서만 수행이 가능하다. 앞서 ‘메모리 테이블스페이스에 체크포인트 경로 추가’ 절에서 알아본 것과 같이 우선 알티베이스 서버를 셧다운 시킨 상태에서 컨트롤 단계까지 알티베이스를 기동한다. 본 예제에서는 기존의 체크포인트 경로인 알티베이스 홈의 dbs1 을 7 체크포인트시 테이블스페이스의 체크포인트 이미지 파일을 새로 생성할 경우 테이블스페이스에 속한 각각의 모든 체크포인트 경로를 하나씩 번갈아가면서 사용한다. 344 ALTIBASE5 Administrator’s Manual 새로 설치한 디스크인 /new_disk 로 옮기는 절차에 대해 기술한다. 체크포인트 경로를 변경하기 위해서는 기존의 체크포인트 경로를 절대경로로 정확히 입력해 주어야 한다. 컨트롤 단계에서 테이블스페이스에 속한 체크포인트 경로를 보는 방법은 ‘메모리 테이블스페이스에 체크포인트 경로 추가’를 참고한다. 체크포인트 경로를 변경할 때에는 체크포인트 경로를 추가할때와 마찬가지로 다음과 같이 변경후의 체크포인트 경로를 DBA 가 직접 생성하고 쓰기및 실행 권한을 주어야 한다. 알티베이스 프로세스를 수행하는 유저명이 altibase 라고 가정한다. $ su - root $ mkdir /new_disk/dbs1 $ chown altibase /new_disk/dbs1 이제, 다음과 같이 RENAME CHECKPOINT PATH 를 이용하여 알티베이스 홈의 dbs1 이라는 체크포인트 경로를 새로 추가한 디스크인 /new_disk/dbs1 으로 변경할 수 있다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS RENAME CHECKPOINT PATH '/opt/altibase_home/dbs1' TO '/new_disk/dbs1'; Alter success. 마지막으로 기존의 알티베이스 홈의 dbs1 안의 USER_MEM_TBS 의 체크포인트 이미지들을 모두 /new_disk/dbs1 으로 옮겨주어야 한다. $ mv $ALTIBASE_HOME/dbs1/USER_MEM_TBS* /new_disk/dbs1 메모리 테이블스페이스에 체크포인트 경로 제거 메모리 테이블스페이스에 체크포인트 경로를 제거하는 절차에 대해 알아본다. 메모리 테이블스페이스의 체크포인트 경로의 설정은 컨트롤(CONTROL)단계에서만 수행이 가능하다. 앞서 ‘메모리 테이블스페이스에 체크포인트 경로 추가’절에서 알아본 것과 같이 우선 알티베이스 서버를 셧다운 시킨 상태에서 컨트롤 단계까지 알티베이스를 기동한다. 본 예제에서는 기존의 체크포인트 경로인 알티베이스 홈의 dbs2 를 제거하는 절차에 대해 기술한다. 체크포인트 경로를 변경하기 위해서는 기존의 체크포인트 경로를 절대경로로 정확히 입력해 주어야 한다. 컨트롤 단계에서 테이블스페이스에 속한 체크포인트 경로를 보는 방법은 ‘메모리 테이블스페이스에 체크포인트 경로 추가’를 참고한다 이제, 다음과 같이 DROP CHECKPOINT PATH 명령을 이용하여 알티베이스 홈의 dbs2 라는 체크포인트 경로를 제거할 수 있다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS DROP CHECKPOINT PATH '/opt/altibase_home/dbs2' Alter success. 테이블스페이스 345 마지막으로 기존의 알티베이스 홈의 dbs2 안의 USER_MEM_TBS 의 체크포인트 이미지들을 USER_MEM_TBS 의 체크포인트 경로중 하나로 옮겨주어야 한다. $ mv $ALTIBASE_HOME/dbs2/USER_MEM_TBS* /new_disk/dbs1 메모리 테이블스페이스의 자동확장 설정 변경 메모리 테이블스페이스의 자동확장 설정을 변경하는 절차에 대해 알아본다. 메모리 테이블스페이스 생성시 자동확장 구문을 제공하지 않으면, 기본적으로 해당 테이블스페이스는 자동확장이 되지 않도록 설정된다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M; Create success. 이 때 자동확장을 하도록 설정하는 가장 간단한 구문은 다음과 같다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON; Alter success. 이 때 확장단위는 메모리 테이블스페이스의 기본 확장단위인 EXPAND_CHUNK_PAGE_COUNT 에 설정한 페이지 개수에 해당하는 크기만큼 확장이 된다. 또한 최대 크기는 UNLIMITED 로 준 것과 같이 동작하여 시스템내의 모든 메모리 테이블스페이스의 현재크기의 총합이 MEM_MAX_DB_SIZE 프로퍼티를 벗어나지 않는 한도내에서 테이블스페이스의 확장이 수행된다. 메모리 테이블스페이스는 디스크 테이블스페이스와 달리, 체크포인트 이미지 파일을 DBA 가 직접 관리하지 않는다. 알티베이스가 자동확장이 필요한 경우 체크포인트 이미지파일을 자동으로 생성하기 때문이다. 메모리 테이블스페이스의 확장단위를 지정하기 위해서는 다음과 같은 구문을 사용한다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON NEXT 128M; Alter success. 메모리 테이블스페이스의 최대 크기를 지정하기 위해서는 다음과 같은 구문을 사용한다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON MAXSIZE 1G; Alter success. 메모리 테이블스페이스의 확장 크기와 최대 크기를 함께 지정하기 위해서는 다음과 같은 구문을 사용한다. 346 ALTIBASE5 Administrator’s Manual iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON NEXT 128M MAXSIZE 1G; Alter success. 메모리 테이블스페이스의 자동확장 설정을 끄기 위해서는 다음과 같은 구문을 사용한다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND OFF; Alter success. 메모리 테이블스페이스의 온라인(ONLINE) 및 오프라인(OFLINE)의 전이 본 사용예에서는 메모리 테이블스페이스의 온라인, 오프라인 간의 상태전에 절차와 사용예에 대해 알아본다. 알티베이스의 메모리 테이블스페이스는 모든 데이터를 메모리에 적재한다. 이로 인하여 메모리 테이블스페이스가 사용중인 공간만큼 시스템의 메모리가 할당된다. 알티베이스는 이러한 메모리 사용을 DBA 가 손쉽게 제어할 수 있도록, 메모리 테이블스페이스의 메모리를 할당, 반납할 수 있는 기능을 제공한다. 물론, 메모리 테이블스페이스의 메모리가 반납된 상황에서는 해당 테이블스페이스 안에 생성된 모든 객체를 일시적으로 사용할 수 없게 된다. 메모리 테이블스페이스의 메모리를 반납하기 위해서는 테이블스페이스를 오프라인으로 전이하면 된다. iSQL> ALTER TABLESPACE USER_MEM_TBS OFFLINE; Alter success. 추후 해당 메모리 테이블스페이스 안에 생성된 테이블을 사용하기 위해서는 다음과 같이 테이블스페이스를 온라인으로 전이한다. iSQL> ALTER TABLESPACE USER_MEM_TBS ONLINE; Alter success. 휘발성 테이블스페이스 휘발성 테이블스페이스 생성 기본적으로 휘발성 테이블스페이스 생성, 변경, 삭제 구문은 메모리 테이블스페이스의 생성, 변경, 삭제 구문과 거의 동일하다. 다만 체크포인트 이미지 파일 관련 구문은 사용할 수 없다는 차이점이 있다. 다음 구문으로 256M 크기의 휘발성 테이블스페이스를 생성할 수 있다. iSQL> CREATE VOLATILE DATA TABLESPACE USER_VOL_TBS SIZE 256M; Create success. 테이블스페이스 347 이 경우 테이블스페이스의 크기는 256MB 로 고정되어 있어 자동확장은 불가능하다. 다음 구문은 자동 확장할 수 있는 테이블스페이스를 생성한다. iSQL> CREATE VOLATILE DATA TABLESPACE USER_VOL_TBS SIZE 256M AUTOEXTEND ON; Create success. 이 경우 테이블스페이스의 초기 크기는 256MB 이지만 자동 확장 되며, VOL_MAX_DB_SIZE가 허용하는 만큼 확장될 수 있다. 자동 확장 단위는 4MB 이다. 여기서 자동 확장 단위를 8MB 로, 최대 512MB 까지만 확장할 수 있게 하려면 다음 구문으로 생성하면 된다. iSQL> CREATE VOLATILE DATA TABLESPACE USER_VOL_TBS SIZE 256M AUTOEXTEND ON NEXT 8M MAXSIZE 512M; Create success. 휘발성 테이블스페이스 변경 휘발성 테이블스페이스에 대해 자동 확장 모드, 자동 확장 단위, 최대 크기 등을 변경할 수 있다. 다음 구문은 자동 확장이 안되는 휘발성 테이블스페이스를 자동 확장 모드로 변경한다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND ON; Alter success. 위 구문을 이미 자동 확장 모드인 테이블스페이스에 사용하면 에러가 발생한다. 다음 구문은 자동 확장 모드로 바꾸면서 자동 확장 단위를 8MB 로, 최대 512MB 까지 확장할 수 있도록 변경한다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND ON NEXT 8M MAXSIZE 512M; Alter success. 다음 구문은 자동 확장 모드를 끈다. 이 구문을 사용하기 위해서는 자동 확장 모드가 ON 이어야 한다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND OFF; Alter success. 자동 확장 모드이면서 자동 확장 단위가 4MB 인 테이블스페이스를 자동 확장 단위 8MB 로 바꾸려면 다음처럼 해야 한다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND OFF; Alter success. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND ON NEXT 8M; Alter success. 테이블스페이스의 삭제(DROP) - 디스크, 메모리, 휘발성 공통 348 ALTIBASE5 Administrator’s Manual 테이블스페이스 디스카드(Discard) - 데이터가 깨진 테이블스페이스를 제거 테이블스페이스를 디스카드하는 절차에 대해 알아본다. DBA 가 실수로 디스크 테이블스페이스의 데이터 파일이나 메모리 테이블스페이스의 체크포인트 이미지 파일을 삭제한경우, 혹은 매체 오류로 인하여 해당 파일의 내용이 유실된 경우에 알티베이스 기동이 불가능해진다. 우선, 매체 복구를 이용한 해당 파일을 복구하는 방법을 생각해 볼 수 있다. 하지만 매체 복구는 아카이브 로깅을 수행하여 기존의 로그파일이 별도의 아카이브 공간에 모두 남아 있을 때에 수행이 가능하다. 이와 같이 매체 복구가 불가능한 경우, 데이터 파일이나 체크포인트 이미지 파일이 유실된 특정 테이블스페이스를 버리고 나머지 테이블스페이스들만으로 알티베이스를 기동하기 위해 사용하는 구문이 ALTER TABLESPACE DISCARD 구문이다. ALTER TABLESPACE DISCARD 구문을 이용하여 디스카드한 테이블스페이스는 그 안에 생성된 객체 또한 접근이 불가능해지고, 추후 제거(DROP)만 가능하기 때문에 사용시 신중해야 한다. 본 사용 예에서는 메모리 테이블스페이스인 USER_MEM_TBS 를 생성한 후, 체크포인트 이미지를 삭제한 상태에서 해당 테이블스페이스만 제외한 나머지 테이블스페이스들로 알티베이스를 기동하는 과정을 기술한다. 우선 다음과 같이 메모리 테이블스페이스를 생성한다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M; Create success. 이제 알티베이스 프로세스를 종료하고, 해당 테이블스페이스에 속한 파일을 지운 후, 알티베이스를 재기동하면 다음과 같은 에러가 발생한다. [SM-WARNING] CANNOT IDENTIFY DATAFILE [TBS:USER_MEM_TBS, PID-0-FID-0] Datafile Not Found [SM-WARNING] CANNOT IDENTIFY DATAFILE [TBS:USER_MEM_TBS, PID-1-FID-0] Datafile Not Found [FAILURE] The data file does not exist. Startup Failed.... [ERR-91015 : Comunication failure.] 알티베이스는 이와 같이 일부 테이블스페이스의 데이터 파일이나 체크포인트 이미지 파일이 존재하지 않는 경우 에러가 발생한다. 이제 USER_MEM_TBS 를 디스카드 할 차례이다. 디스카드 구문은 컨트롤(CONTROL)단계에서만 수행이 가능하다. 테이블스페이스 349 알티베이스를 컨트롤 단계까지 기동한다. $ isql -u sys -p manager -sysdba iSQL(sysdba)> startup control 이제 체크포인트가 유실된 테이블스페이스은 USER_MEM_TBS 를 디스카드 한다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS DISCARD; Alter success. 그리고 다음과 같이 startup service 명령을 수행하여 알티베이스를 서비스단계로 진입시킨다. iSQL(sysdba)> startup service Command execute success. 디스카드 명령은 해당 테이블스페이스를 버리겠다고 선언하는 것에 불과하다. 그렇기 때문에 해당 테이블스페이스 및 그 안의 객체는 DROP TABLESPACE INCLUDING CONTENTS 구문을 이용하여 직접 제거하여야 한다. iSQL> DROP TABLESPACE USER_MEM_TBS INCLUDING CONTENTS AND DATAFILES; Drop success. 마찬가지로 디스크 테이블스페이스의 데이터 파일이 유실되거나, 매체 오류 때문에 데이터 파일의 내용중 일부가 깨진 경우에도 해당 테이블스페이스를 디스카드시키는 방법으로 알티베이스를 가동할 수 있다. 테이블스페이스의 제거 본 사용예에서는 테이블스페이스를 제거하는 방법에 대해 알아본다. 먼저, 테이블스페이스 안에 어떠한 객체도 생성되지 않은 경우, 다음과 같이 간편하게 테이블스페이스를 제거할 수 있다. 단, 이 경우 디스크 테이블스페이스의 데이터 파일과 메모리 테이블스페이스의 체크포인트 이미지는 파일 시스템에서 제거되지 않는다. iSQL> DROP TABLESPACE MY_TBS; Drop success. 만약, 테이블스페이스안에 생성된 객체가 존재한다면 다음과 같이 INCLUDING CONTENTS 절을 주어서 테이블스페이스 안의 모든 객체를 DROP 하도록 할 수 있다. 이 경우에도 데이터 파일이나 체크포인트 이미지를 파일 시스템에서 삭제하지는 않는다. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS; Drop success. 350 ALTIBASE5 Administrator’s Manual 만약 테이블스페이스안의 테이블을 참조하는 다른 테이블스페이스의 테이블들로부터 참조 제약(Referential Constraint)를 제거 하려면 다음과 같이 INCUDING CONTENTS 절과 함께 CASCADE CONSTRAINTS 를 함께 주면 된다. 이 경우에도 데이터 파일이나 체크포인트 이미지를 파일 시스템에서 삭제하지는 않는다. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS CASCADE CONSTRAINTS; Drop success. 만약 디스크 테이블스페이스의 데이터 파일이나 메모리 테이블스페이스의 체크포인트 이미지 파일을 삭제하기 위해 다음과 같이 INCLUDING CONTENTS 절 바로 뒤에 AND DATAFILES 절을 주면 된다. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS AND DATAFILES; Drop success. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS; Drop success. 테이블스페이스 351 테이블스페이스 공간 관리 이 절에서는 알티베이스의 테이블스페이스 공간을 관리하는 방법에 대하여 설명한다. 언두 테이블스페이스 크기 계산 언두 테이블스페이스(Undo Tablespace)는 언두 세그먼트를 저장하기 위해 사용된다. 언두 테이블스페이스가 부족할 경우 트랜잭션 성능에 영향을 줄 수 있으므로 적절한 크기로 관리해야 한다. 만약, 업무 시스템에서 변경 트랜잭션(특히 오랜 시간동안 구문이 실행되는 트랜잭션이 많은 경우)이 많이 발생하는 경우에는 언두 세그먼트가 계속 확장되기 때문에 언두 테이블스페이스의 공간이 부족해질 수 있다. 사용자는 언두 테이블스페이스의 크기를 자동 확장 모드로 지정하거나 대략적인 최대 크기를 예측하여 고정 크기 모드로 지정하여 공간을 관리할 수 있다. 언두 테이블스페이스의 자동 확장 모드 사용자가 처음으로 언두 테이블스페이스에서 애플리케이션을 수행하는 경우 언두 테이블스페이스가 어느 정도가 필요한지 알기 쉽지 않다. 이런 경우에는 자동 확장 모드를 활성화하여 언두 테이블스페이스를 자동 확장이 가능하도록 설정하여 필요한 공간까지 자동으로 확장되도록 한다. 알티베이스는 애플리케이션 개발 환경에서 언두 테이블스페이스의 용량을 계획하기 쉽도록 자동 확장 모드를 제공한다. 기본적으로 언두 테이블스페이스는 자동 확장 모드로 동작하며, ALTER TABLESPACE 구문으로 변경할 수 있다. 언두 테이블스페이스의 고정 크기 모드 사용자가 고정 크기의 언두 테이블스페이스를 사용하고 싶다면, 필요한 용량을 예측해야 한다. 이를 위해서 사용자는 애플리케이션을 수행하였을 때 사용되는 TSS 세그먼트 공간과 언두 세그먼트 공간의 사용 패턴을 수집하여 분석해야 한다. 일반적으로 다음과 같은 계산식으로 대략적인 산출이 가능하다. y 언두 테이블스페이스 크기 = Long-Term 트랜잭션 시간(sec) x (초당 할당되는 언두 페이지 개수 + 초당 할당되는 TSS 페이지 개수) x 페이지 크기(8KB) 352 ALTIBASE5 Administrator’s Manual 예를 들어 Long-Term 트랜잭션이 600 초(10 분)이고, 초당 언두 페이지가 1000 개를 사용한다. 이 때 TSS 페이지는 24 개를 사용한다면, 10 x 60 x ( 1000 + 24 ) x 8K = 4800MB 이므로 약 4.7G 정도가 필요하다. 이와 같이 예측하는 것이 쉽지 않다면, 디스크 공간이 충분한 경우에는 충분히 넉넉한 크기를 할당하여 사용하는 것도 방법이다. 언두 테이블스페이스의 확장 업무 시스템에서 변경 트랜잭션(특히 Long-Term 트랜잭션: 트랜잭션의 Commit 주기가 긴 경우)이 많이 발생하는 경우에 언두 테이블스페이스의 부족이 발생할 수 있다. 이러한 경우에 언두 테이블스페이스에 ALTER TABLESPACE 구문을 이용하여 적정한 크기로 데이터 파일을 추가하거나 파일의 크기를 늘려준다. 디스크 테이블의 크기 계산 알티베이스의 디스크 테이블 크기는 자료형과 데이터의 구성을 바탕으로 계산할 수 있으며 [테이블 로우의 총 길이 * 데이터 건 수] 의 값을 가진다. 다음 표는 자료형 별로 고려해야 할 길이를 나타낸 것이다. (P = Precision, V = Value length) 자료형 테이블 로(Row)의 크기 Null250바이트 이하 251바이트 이상 Integer 1 5 X SmallInt 1 3 X BigInt 1 9 X Date 1 9 X Double 1 9 X Char 1 1+P 3+P Varchar 1 1+V 3+V NChar 1 1+P 3+P NVarchar 1 1+V 3+V Bit 1 5+(P/8) 7+(P/8) Varbit 1 5+(V/8) 7+(V/8) Float 1 4+(V+2) / 2 6 +(V+2) / 2 Numeric 1 4+(V+2) / 2 6 +(V+2) / 2 위 도표에서 P(Precision)는 테이블 생성시 결정된 칼럼의 최대 크기이다. 각 로우(Row)의 데이터는 P 이상의 길이를 갖는 값을 테이블스페이스 353 삽입할 수 없다. 또한 고정길이 칼럼인 Char, NChar, Bit 등은 항상 P 만큼의 공간을 점유하기 때문에, 데이터의 크기와 상관없이 로우의 크기는 일정하다. V(Value length)는 실제로 삽입된 데이터의 크기이다. V 는 테이블 생성시 결정된 칼럼의 최대 크기인 P 보다 클 수 없다. 또한 가변 길이 칼럼인 Varchar, NVarchar, VarVit 등은 데이터의 크기에 따라 점유하는 공간의 크기가 달라진다. 따라서 데이터의 크기에 따라 로우의 크기가 변화한다. 로우(row) 테이블 스키마가 다음과 같을 경우, 로우 크기를 계산하는 방법에 대해 설명한다. CREATE TABLE T1 ( C1 char(32), C2 char(1024), C3 varchar(512) ) tablespace user_data02; 이 스키마에서 C1 칼럼과 C2 칼럼은 고정길이 칼럼이며, C3 칼럼이 가변길이 칼럼이다. 따라서 C3 칼럼의 크기에 따라 로우의 크기가 변 한다. 또한 칼럼에 널(NULL)이 존재하는지 여부에 따라 로우의 크기 가 변한다. 이를 고려하여 로우의 크기를 계산하면 아래와 같으며, 테이블 T1의 크기는 (로우의 총 길이 * 데이터 건 수)가 된다. [로우 헤더] 34 바이트 [C1 칼럼] 1+P 바이트 = 1+32 바이트 [C2 칼럼] 3+P 바이트 = 3+1024 바이트 [C3 칼럼] 3+V 바이트 y C3 칼럼의 크기가 200 바이트인 경우 [총 길이] 34 + (1+32) + (3+1024) + (3+200) = 1297 바이트 y C3 칼럼의 크기가 500 바이트인 경우 [총 길이] 34 + (1+32) + (3+1024) + (3+500) = 1597 바이트 y C2 칼럼이 널이고, C3 칼럼의 크기가 300 바이트인 경우 [총 길이] 34 + (1+32) + (1) + (3+300) = 371 바이트 y C3 컬림이 널인 경우 [총 길이] 34 + (1+32) + (3+1024) + (0) = 1094 바이트 마지막에 널 칼럼이 존재할 경우, 해당 널 칼럼은 생략된다. 인덱스(index) 크기 계산 인덱스의 크기 역시 자료형과 데이터의 구성을 바탕으로 계산할 수 있다. 다음 표는 인덱스 크기 계산 시, 자료형 별로 고려해야 할 길이를 나타낸 것이다. 354 ALTIBASE5 Administrator’s Manual (P = Precision, V = Value length) 자료형 인덱스 키의 크기 Null250바이트 이하 251바이트 이상 Integer 4 4 X SmallInt 2 2 X BigInt 8 8 X Date 8 8 X Double 8 8 X Char 1 1+P 3+P Varchar 1 1+V 3+V NChar 1 1+P 3+P NVarchar 1 1+V 3+V Bit 1 5+(P/8) 7+(P/8) Varbit 1 5+(V/8) 7+(V/8) Float 1 4+(V+2) / 2 6+(V+2) / 2 Numeric 1 4+(V+2) / 2 6+(V+2) / 2 위 도표에서 P(Precision)와 V(Value length)는 테이블 크기 도표와 마찬가지로 각각, 테이블 생성시 결정된 칼럼의 최대 크기와 실제로 삽입된 데이터의 크기를 의미한다. 한 인덱스의 크기는 다음과 같다. [ 10(헤더) + (키 칼럼 길이의 합) ] * 데이터 건 수 위의 계산 공식은 leaf node (B*Tree 에서 최하위의 노드)의 대략적인 크기이다. 이 외에 internal node(leaf node 를 제외한 상위 노드)의 크기의 경우, 키 칼럼(key column)의 크기가 작을 경우에는 무시할 수 있을 정도로 그 크기가 작다. 하지만 키 칼럼의 크기가 2K 이상일 경우에는 B*Tree 의 깊이가 깊어지고, 전체 Leaf Node 크기의 50% 정도까지 될 수 있으므로 이런 경우에는 internal node 를 계산에 포함해야 한다. 테이블 및 인덱스의 스키마가 다음과 같을 경우, 인덱스의 크기를 계산하는 방법에 대해 설명한다. CREATE TABLE T1 ( C1 Integer, C2 varchar(50) tablespace user_data02; CREATE INDEX T1_IDX1 ON T1( C1, C2 ); C1 칼럼은 Integer 형이므로 항상 4 byte 로 크기가 결정된다. C2 는 가변길이 칼럼으로 데이터의 크기에 따라 길이가 가변적으로 변한다. [키 헤더] 10 byte [C1 칼럼] 4 byte [C2 칼럼] 1+V byte 테이블스페이스 355 y C2 칼럼의 크기가 50 바이트인 경우 [총 길이] 10 + 4 + (1+50) = 65 바이트 y C2 칼럼의 크기가 500 바이트인 경우 [총 길이] 10 + 4 + (3+500) = 517 바이트 y C2 칼럼이 널인 경우 [총 길이] 10 + 4 + 1 = 15 바이트 예제 테이블 스키마가 다음과 같고 데이터 건 수가 100 만 건일 경우에 로우의 크기와 인덱스의 크기를 포함한 테이블의 크기를 다음과 같이 계산한다. CREATE TABLE TEST01 (C1 char(8) primary key, C2 char(128), N1 integer, IN_DATE date) tablespace user_data02; y 로우 크기 및 전체 데이터 크기 로우 크기: 34[헤더] + (1+8) + (1+130) + (1+4) + (1+8) = 188 바이트 전체 데이터 크기: [ 188 ] * 10만 건 = 179.29 M 바이트 y 인덱스 크기 한 로우의 인덱스 크기: 10[헤더] + (1+8)[C1] = 19 바이트 전체 인덱스 크기: 19 * 100만건 = 18.12 M 바이트 y TEST001 테이블 전체가 차지하는 디스크 크기 179.29 (데이터 크기) + 18.12(인덱스 크기) = 197.41 M 바이트 이것은 데이터의 크기만 계산한 것으로, 실제로는 페이지 헤더, internal node, 세그먼트 관리 영역 등을 추가로 사용하며 그만큼 공 간을 더 사용한다. 이러한 부분을 고려하면, 총 테이블 스페이스는 약 240M 바이트를 사용하게 된다. 테이블의 적정 크기 계산 테이블의 크기 계산에 사용된 테이블(TEST001)을 기준으로 테이블의 레코드와 인덱스를 모두 저장할 수 있는 테이블의 적정 사이즈를 계산한다. 적정한 테이블 크기를 계산하기 위해서 다음과 같은 사항을 고려해야 한다. 트랜잭션의 구성 비율을 고려한다. 특정 테이블에 대하여 변경(Update) 트랜잭션이 많이 발생할 경우에는 트랜잭션의 성능을 높이기 위해 PCTFREE 를 크게하고, PCTUSED 를 작게하여 변경 작업을 위해 필요한 빈 공간(free 356 ALTIBASE5 Administrator’s Manual space)을 많이 확보해야 한다. 변경 트랜잭션이 적고 입력(Insert) 트랜잭션이 주로 발생하는 테이블의 경우에는 반대로 PCTFREE 를 작게하고, PCTUSED 를 크게하여 불필요한 빈 공간(free space)을 최소화해야 한다. y PCTFREE 기본값은 10이며, 디스크 테이블 생성시 0에서 99 사이의 값을 명시할 수 있다. 테이블 정보를 저장할 때 테이블의 각 페이지에서 기존 레코드에 대한 변경 연산 등을 위하여 사용될 여유 공간을 미리 예약한 공간의 비율이다. 따라서 PCTFREE가 10이고 입력(Insert) 트랜잭션만 발생한다고 가정할 경우에 테이블의 전체 크기가 100M 라면 테이블의 레코드와 인덱스를 위해 사용될 수 있는 공간은 90M가 된다. y PCTUSED 기본값은 40이며 디스크 테이블 생성시 0에서 99 사이의 값을 명시할 수 있다. 특정 페이지가 PCTFREE에서 명시한 비율에 도달한 후에 변경과 삭제로 인해서 빈 공간의 비율이 40% 미만(39%)으로 될 때까지 해당 페이지에는 삽입 연산이 일어나지 않는다. 따라서 변경이 많이 발생하는 테이블일 경우에는 테이블의 크기를 산정할 때 여유 공간을 많이 확보해야 한다. 케이스 테이블 사이즈 계산 변경 대부분이 Read Only 트랜 잭션이거나 UPDATE 시에 Record의 크기 가 증가 되지 않 을 경우 PCTFREE를 5로 지정하고, PCTUSED를 90으 로 지정한 경우 ① 최소 테이블 크기 계산: TEST001(전체사이즈=215.53M)테이블을 저장 하기 위해서 필요한 최소 사이즈는 다음과 같은 공식으로 계산한다. 테이블 전체 사이즈 / [1-(PCTFREE / 100)] = 215.53/0.95 ≒ 227M가 된다. ② 가중치 계산: 최소 사이즈에 적절한 크기의 가중치를 추가한 다. 가중치는 시스템 상황에 따라 달라질 수 있 다. 다음은 가중치 계산의 한가지 예이다. 최소사이즈 * [ 1- (PCTUSED / 100) ] * 2 = 227 * 0.1 * 2 ≒ 45M ③ 따라서 테이블을 총 272M 정도의 사이즈로 생성한다. UPDATE가 빈 번하고, UPDATE 시에 Record의 크기 PCTFREE를 20으로 지정하고, PCTUSED를 40으로 지정한 경우 ① 최소 테이블 크기 계산: TEST001(전체사이즈=213.63M)테이블을 저장 테이블스페이스 357 가 증가될 경우 하기 위해서 필요한 최소사이즈는 다음과 같은 공식으로 계산한다. 테이블전체사이즈 / [1-(PCTFREE / 100) = 213.63/0.8 ≒ 267M가 된다. ② 가중치 계산: 최소 사이즈에 적절한 가중치를 추가한다. 다음 은 가중치 계산의 한가지 예이다. 최소 사이즈 * [ 1- (PCTUSED / 100) ] * 2 = 267 * 0.6 * 2 ≒ 320M ③ 따라서 테이블을 총 587M 정도의 사이즈로 생성한다. INSERT, UPDATE 가 자 주 발생하지만 UPDATE를 할 때 로우의 크기 가 증가되지 않 을 경우 PCTFREE를 10으로 지정하고, PCTUSED를 60으로 지정한다. [표 5-3]트랜잭션 구성 비율에 따른 테이블 크기 계산 * 위의 표에서 설명한 테이블의 사이즈 계산은 절대적인 기준이 아니며, 시스템이 비정상 동작하여 데이터가 갑자기 증가하는 등의 장애 상황에 대한 추가적인 고려가 필요하다. 적정한 백업 사이즈를 고려한다. 실제 업무에서 하나의 테이블스페이스에 하나의 테이블만 저장되는 경우는 드물며 업무단위 또는 백업단위로 테이블을 묶어서 하나의 테이블스페이스에 생성하는 것이 효율적이다. [그림 5-15] 백업을 고려한 테이블스페이스 이때 테이블스페이스에 대한 백업 소요 시간 등을 고려하여 한 개 DB VERSION TBS_SALES INVOICE COMP PRODUCT DEPT TBS_CUSTS ORDER EMP PROJ 2G 1G 358 ALTIBASE5 Administrator’s Manual 테이블스페이스의 적정사이즈를 설정해야 한다. 다음 그림은 데이터베이스 내에서 테이블스페이스를 업무단위 및 백업사이즈를 고려하여 적정사이즈로 분리하여 생성한 예이다. 테이블스페이스 정보 알티베이스는 테이블스페이스를 관리하기 위해서 테이블스페이스의 상태를 점검하거나 모니터링 하기 위한 성능 뷰와 메타 테이블을 제공한다. SYSTEM_.SYS_TBS_USERS_ 또한 다음의 성능 뷰를 통해 사용자들이 사용하는 데이터베이스의 크기, 사용량, 상태 등의 정보를 확인할 수 있다. V$TABLESPACES, V$DATAFILES, V$MEM_TABLESPACES 파티션드 테이블 359 6. 파티션드 테이블 360 ALTIBASE5 Administrator’s Manual 파티셔닝 정의 및 구조 파티셔닝(partitioning)은 대용량 데이터베이스 객체를 여러 개의 작은 조각으로 분할하여 관리하는 방법을 의미한다. 대용량 데이터베이스 객체를 파티셔닝으로 분할한 경우 파티션드 객체(partitioned object), 파티션드 객체가 갖는 분할된 작은 조각을 파티션(partition)이라고 한다. 파티션드 객체와 논파티션드 객체 일반 사용자(end user)가 파티션드 객체를 이용할 때 논파티션드 객체(non-partitioned object)와 차이를 알지 못한다. 즉, 사용자 입장에서 파티션드 객체와 논파티션드 객체는 데이터베이스 객체로 인식될 뿐이지, 해당 객체의 파티션 유무를 인식하지 못하기 때문이다. 따라서 사용자는 파티션 유무에 관계없이 질의 및 DML(레코드 삽입, 삭제, 갱신) 등의 구문을 동일하게 사용할 수 있다. 파티션드 객체와 논파티션드 객체의 차이점을 데이터베이스 구조적 측면에서 살펴보면 다음과 같다. 물리적 구조 논파티션드 객체는 하나의 테이블스페이스에 종속된 객체로, 하나의 논파티션드 객체는 하나의 테이블스페이스에만 저장된다. 파티션드 객체는 다수의 테이블스페이스에 걸쳐 저장될 수 있다. 이를 그림으로 설명하면 [그림 6-1]과 같이 설명된다. 테이블 스 페이스 테이블 스페이스 논파 티션드 객체A 파티션 드 객 체A 논파티션드 객체B 파티션 드 객 체C 파티션드 객체B [그림 6-1] 테이블스페이스와 파티션드 객체 및 논파티션드 객체의 관계 파티션드 객체는 내부적으로 다수의 파티션으로 이루어진다. 각 파티션은 논파티션드 객체와 같은 제약 조건을 가지며, 하나의 파티션은 하나의 테이블스페이스에만 종속된다. 파티션드 테이블 361 이러한 다수의 테이블스페이스에 존재하는 파티션을 하나의 객체로 인식하게 만드는 것이 파티션드 객체이다. [그림 6-2]는 파티션드 객체의 내부구조를 설명한다. 테이블 스페이스 테이블 스 페이스 파티션드 객체 파티션드 객체 파티션드 객체 파티션 [그림 6-2] 파티션드 객체의 내부구조 파티션드 객체의 장점 파티션드 객체는 물리적 구조의 특징으로 다음과 같은 장점들을 갖는다. y 데이터 로딩 및 인덱스 재구축(rebuilding)이 빠르다. y 부분 삭제(partial delete)가 빠르다. y 테이블 스캔(table scan) 및 인덱스 스캔(index scan)이 빠르다. y 디스크 붕괴(disk failure)에 유연하다. 파티션 키 파티션 키(Partition Key)는 테이블을 분할하는 기준이다. 파티션 키는 분할될 테이블을 구성하는 하나 이상의 칼럼(column)으로 구성되며, 이러한 칼럼들을 파티션 칼럼(partition column)이라고 한다. 파티션 칼럼은 반드시 대소 비교(<, >, =)가 가능해야 하며, 이러한 칼럼만이 파티션 칼럼으로 선정될 수 있다. 예를 들어 레코드 삽입시, 삽입될 레코드가 어떤 파티션에 저장되어야 하는지 명확해야 한다. 이러한 기준이 되기 위해서는 파티션 칼럼과 조건간에 명확한 대소비교가 가능해야 한다. 따라서, BINARY, GEOMETRY, BLOB, CLOB 등과 같은 대소 비교가 불가능한 타입은 파티션 칼럼이 될 수 없다. 362 ALTIBASE5 Administrator’s Manual 파티션드 객체 데이터베이스 객체중 테이블과 인덱스는 파티션이 될 수 있는 객체이다. 테이블이 파티션 되는 경우 해당 테이블을 파티션드 테이블(partitioned table)이라고 하며, 인덱스가 파티션 되는 경우는 파티션드 인덱스(partitioned index)라고 한다. 이러한 파티션드 테이블과 파티션드 인덱스를 파티션드 객체(partitioned object)라고 한다. 파티션드 객체는 반드시 다음과 같은 규칙을 만족시켜야 한다. non-partitioned_object ≡ ∑partition……………………rule1 위의 규칙을 설명하면 논파티션드 객체(non-partitioned_object)는 이를 분할한 파티션의 합과 동치여야 한다. 즉, 파티션을 분할할 경우 논파티션드 객체의 일부분만을 파티션시킬 수 없다. 파티션드 테이블 파티션드 테이블(Partitioned Table)은 파티셔닝 조건(범위, 리스트, 해시)에 따라 대용량 테이블을 다수의 파티션으로 분리한 테이블을 의미한다. 이를 그림으로 살펴보면 [그림 6-3]과 같다. [그림 6-3]은 논파티션드 테이블을 색깔(color)을 기준으로 파티셔닝하였으며, 파티션 3 개로 구성된 파티션드 테이블을 구성한다. 파티션드 테이블은 구조적 측면에서 기존 데이터베이스 객체중 유니온 뷰(Union View)와 비슷한 개념을 갖는다. 유니온 뷰는 다수의 테이블들을 하나의 객체로 인식하기 위해서 논리적으로 유니온 시킨 것뿐이며, 어떠한 물리적 공간을 차지하지는 않는다. 이와 마찬가지로 파티션드 테이블은 파티션드 테이블에 참여하는 파티션들이 물리적인 공간을 가지는 것뿐이지 파티션드 테이블 자체가 물리적 공간을 갖는 것은 아니다. 파티션드 테이블과 유니온 뷰를 비교하면 다음의 몇 가지 특징이 있다. y 갱신 가능성 파티션드 테이블은 갱신이 가능하다. 반면 유니온 뷰는 개별 테이블을 통한 레코드 갱신은 가능하지만, 유니온 뷰를 통한 레코드 갱신은 불가능하다. y 인덱스 구축 범위 파티션드 테이블에는 인덱스를 구축할 수 있다. 그러나 유니온 뷰는 개별 테이블에는 인덱스를 구축할 수 있지만, 유니온 파티션드 테이블 363 뷰에는 인덱스를 구축할 수 없다. 파티션드 테이블 논파티션드 테이블 파티셔닝 조건 (color) [그림 6-3] 파티션드 테이블과 논파티션드 테이블 결론적으로 파티션드 테이블은 레코드 갱신 및 인덱스 구축이 가능한 유니온 뷰(updatable and indexable union view)와 동치이다. 이러한 파티션드 테이블은 파티션들이 저장되는 매체의 종류에 따라서 다음과 같이 분류된다. 알티베이스는 파티션드 디스크 테이블만 지원한다. y 파티션드 메모리 테이블(Partitioned Memory Table) : 모든 파티션들이 메모리 테이블스페이스에 저장된 파티션드 테이블 y 파티션드 디스크 테이블(Partitioned Disk Table) : 모든 파티션들이 디스크 테이블스페이스에 저장된 파티션드 테이블 파티션드 인덱스 파티션드 테이블과 관련 있는 인덱스들을 다음과 같이 분류할 수 있다. y 파티션 유무에 따른 분류 364 ALTIBASE5 Administrator’s Manual y 파티션드 인덱스, 논파티션드 인덱스 y 테이블과 인덱스 관계에 따른 분류 y 글로벌 인덱스, 로컬 인덱스 파티션드 인덱스와 논파티션드 인덱스 인덱스는 파티션 유무에 따라 파티션드 인덱스와 논파티션드 인덱스로 구분된다. 논파티션드 인덱스는 파티션으로 분할되지 않은 인덱스를 의미하며, 파티션드 인덱스는 파티션드 테이블과 마찬가지로 대용량 인덱스를 파티션 조건에 따라 분리한 인덱스를 의미한다. 이를 그림으로 살펴보면 [그림 6-4]와 같다. 논파티 션드 인 덱 스 파티 션드 인 덱 스 파티셔닝 조건 (color) [그림 6-4] 파티션드 인덱스와 논파티션드 인덱스 [그림 6-4]는 논파티션드 인덱스를 색깔(color)을 기준으로 파티셔닝하였으며, 파티션 3 개로 구성된 파티션드 인덱스를 구성한 모습을 설명한다. 파티션 조건에 따라 분리된 파티션드 인덱스는 인덱스 파티션 키와 인덱스 키의 관계에 따라 다음과 같이 프리픽스드 인덱스와 논프리픽스드 인덱스로 구분한다. y 프리픽스드 인덱스(Prefixed Index) 인덱스 키의 첫번째 칼럼이 인덱스 파티션 키의 첫번째 칼럼과 파티션드 테이블 365 동일한 경우를 의미한다. y 논프리픽스드 인덱스(Non-prefixed Index) 인덱스 키의 첫번째 칼럼이 인덱스 파티션 키의 첫번째 칼럼과 동일하지 않은 경우를 의미한다. create table tbl_sales( sales_id integer, sales_date date ) partition by range( sales_date ) ( partition p1 values less than( to_date('2007-05-01', 'YYYY-MM-DD' ) ), partition p2 values less than( to_date('2007-09-01', 'YYYY-MM-DD' ) ), partition p3 values default ) tablespace sys_tbs_disk_data; sales_id sales_date 21월 4 10월 1 12월 63월 84월 55월 38월 7 11월 96월 테이 블(TBL_SALES) 3월1월4월6월5월8월11월10월12월 IDX_PART_1 IDX_PART_2 IDX_PART_3 create index idx_prefix on tbl_sales( sales_date ) local ( partition idx_part_1 on p1, partition idx_part_2 on p2, partition idx_part_3 on p3 ); sales_date=sale_date 628539417 IDX_PART_1 IDX_PART_2 IDX_PART_3 create index idx_non_prefix on tbl_sales( sales_id ) local ( partition idx_part_1 on p1, partition idx_part_2 on p2, partition idx_part_3 on p3 ); sales_id=sale_date [그림 6-5] 프리픽스드 인덱스와 논프리픽스드 인덱스의 예 [그림 6-5]는 프리픽스드 인덱스와 논프리픽스드 인덱스의 차이를 sales_id 와 sale_date 로 이루어진 테이블을 예를 들어 설명하고 있다. 그림에서 인덱스들은 sales_date 에 의해서 파티션된 파티션드 인덱스이다. 각 인덱스는 어떠한 키로 구성되느냐에 따라 프리픽스드와 논프리픽스드로 분류된다. 그림에서 프리픽스드 인덱스는 sales_date 를 키로 갖는다. 이는 인덱스 파티션 키와 인덱스 키와 동일한 기준을 가지고 있다. 이러한 인덱스를 프리픽스드 인덱스라고 한다. 반면, 그림에서의 논프리픽스드 인덱스는 sales_id 로 정렬되어 있다. 이러한 인덱스는 인덱스 파티션키와는 다른 키에 의해서 정렬된 인덱스로 366 ALTIBASE5 Administrator’s Manual 논프리픽스드 인덱스라고 한다. 이러한 프리픽스드와 논프리픽스드로 구분하는 이유는 유니크(Unique) 속성과 관련이 있다. 프리픽스드 인덱스는 인덱스 파티션 키와 동일한 인덱스 키를 갖기 때문에 유니크 검사시 파티션드 인덱스에 속한 모든 파티션들을 검색하지 않고도 유니크 검사를 할 수 있다. 그러나 논프리픽스드 인덱스는 파티션드 인덱스에 포함된 모든 파티션들을 검색한다. 예를 들어 설명하면 [그림 6-6]과 같다. sales_id sales_date 21월 41 0 월 11 2 월 63월 84월 55월 38월 96월 91월 [ 그림 6-6] 논프리픽스드 인덱스를 이용한 유니크 검사의 예(불가능함) [그림 6-6]의 예제에서 sales_id 가 유니크 속성을 갖으며, 해당 테이블에 sales_date 를 인덱스 파티션 키로 갖는다. sales_id 를 인덱스 키로 갖는 논프리픽스드 인덱스(IDX_NON_PREFIX)가 구축된다고 가정하자. 이 때 레코드 삽입시(INSERT INTO TBL_SALES VALUES(9, 1 월); ) IDX_NON_PREFIX 이용해서 유니크 검사를 할 수 있는지 생각해본다. 우선 삽입하려는 레코드의 sales_date 가 1 월이기 때문에 IDX_PART_1 을 이용하여 키를 삽입할 것이다. 삽입시 IDX_PART_2 에 sales_id 가 9 를 갖는 키가 있음에도 불구하고 IDX_PART_1 에 정상적으로 삽입된다. 따라서 논프리픽스드 인덱스를 이용해서 유니크 검사를 할 경우에는 모든 인덱스를 검색해야만 한다. 글로벌 인덱스와 로컬 인덱스 테이블 파티션 키와 인덱스 파티션 키의 관계에 따라 글로벌 인덱스와 로컬 인덱스로 구분한다. 글로벌 인덱스는 인덱스 파티션 키가 테이블 파티션 키와 일치하지 않는 인덱스를 의미한다. (index_partition_key != table_partition_key) 로컬 인덱스는 인덱스 파티션 키가 테이블 파티션 키와 일치하는 인덱스를 의미한다. (index_partition_key == table_partition_key) 파티션드 테이블 367 [그림 6-7]은 글로벌 인덱스와 로컬 인덱스의 차이를 sales_id 와 sale_date 로 이루어진 테이블을 예를 들어 설명하고 있다. 그림에서의 인덱스들은 sales_date 에 의해서 정렬되어 있는 인덱스이고, 각 인덱스를 어떠한 인덱스 파티션키로 파티셔닝 하느냐에 따라 로컬 인덱스와 글로벌 인덱스로 분류한다. 아래 그림에서 로컬 인덱스는 sales_date 를 기준으로 3 개의 파티션으로 분리되어 있다. 이렇게 인덱스 파티션 키(sale_date)와 테이블 파티션 키(sales_date)가 동일한 기준으로 파티션되어 있는 인덱스를 로컬 인덱스라고 한다. 반면, 그림 하단의 글로벌 인덱스는 sales_id 에 의해서 파티션되어 있다. 즉, 인덱스 파티션키(sales_id)와 테이블 파티션 키(sales_date)가 동일하지 않는 경우이다. 이렇게 파티션된 인덱스를 글로벌 인덱스라고 한다. sales_id sales_date 21월 41 0 월 11 2 월 63월 84월 55월 38월 71 1 월 96월 [ 그림 6-7] 로컬 인덱스와 글로벌 인덱스의 예 인덱스의 종류를 글로벌과 로컬로 구분하는 이유는 테이블 파티션 키와 인덱스 파티션 키의 동치 여부에 따라 다른 특징을 갖기 때문이다. 파티션 기준과 별도로 인덱스를 만든다는 것은 글로벌 인덱스내의 키들이 서로 다른 다수의 파티션 테이블을 가리키고 있음을 내포하고 있으며, 이는 파티션드 테이블의 변경 구문(ALTER TABLE .... MERGE ...)이 글로벌 인덱스의 재구축(rebuild)으로 이어질수 있음을 의미한다. 반면 로컬 인덱스는 파티션드 테이블의 변경 구문은 변경이 행해지는 파티션의 로컬 인덱스에만 영향을 미치기 때문에 전체적인 368 ALTIBASE5 Administrator’s Manual 동시성 효율을 떨어뜨리지 않는다. 인덱스의 종류 지금까지 설명한 인덱스의 종류를 정리하면 [그림 6-8]과 같다. (파티션드) 글로벌 프리픽스드 인덱스 (파티션드) 글로벌 논프리픽스드 인덱스 (파티션드) 로컬 프리픽스드 인덱스 (파티션드) 로컬 논프리픽스드 인덱스 논파티션드 글로벌 인덱스 인덱스 파티션 유무 i n d ex _p ar t _k ey = = t ab l e_p ar t _k ey i n d ex _p ar t _k ey = = i n dex_key i n d ex _p ar t _k ey = = i n dex_key YES N o YES N o YES N oYES No [그림 6-8] 인덱스의 종류 현재 알티베이스가 지원 가능한 인덱스는 로컬 인덱스로 제한되며, 글로벌 인덱스는 제공하지 않는다. 이것을 테이블과 연관지어 정리하면 다음과 같다. 논파티션드 테이블 위에 논파티션드 인덱스만 구축할수 있으며, 파티션드 테이블 위에 로컬 프리픽스드 인덱스와 로컬 논프리픽스드 인덱스만을 구축할 수 있다. 논파티션드 테이블 파티션드 테이블 (파티션드)로컬 프리픽스드 인덱스 (파티션드)로컬 논프리픽스드 인덱스 (파티션드)글로벌 프리픽스드 인덱스 (파티션드)글로벌 논프리픽스드 인덱스 논파티션드 글로벌 인덱스 지원가능 지원불가능 파티션드 테이블 369 파티션 조건 본 절에서는 파티션을 하기 위한 파티션 조건과 기본 파티션을 알아본다. 파티션 전제조건 파티션 조건(partition condition)은 파티션을 분할하는 기준을 의미한다. 이러한 기준은 다음과 같은 규칙을 준수해야 한다. partition_condition i ∩ partition_condition i+1 = ∮…………rule2 위의 규칙은 파티션드 테이블에 참여하는 파티션 조건들이 서로간에 교집합이 존재해서는 안됨을 의미한다. 교집합이 존재한다는 것은 레코드가 어느 파티션으로 삽입되어야 하는지 명확하지 않다는 것이다. 따라서, 파티션드 객체 생성시 이러한 조건을 만족하지 않으면 파티션 생성은 실패한다. 파티션 조건은 어떠한 경우에도 항상 동일한 값을 표현해야 한다. 레코드가 t 라는 시점에 A 파티션에 삽입되었다고 가정할 경우, 동일 레코드가 t+1 시점에 삽입되는 경우에도 A 파티션에 삽입되어야 한다. 이러한 조건을 만족시키기 위해서 파티션 조건에 기술되는 파티션 조건 값은 항상 상수 또는 결정가능한 내장 함수(deterministic built-in function)여야 한다. 결정가능한 내장함수는 시점에 상관없이 동일한 값을 리턴하고, 시스템 내부에서 제공하는 함수(non-user-defined function)를 의미한다. 기본 파티션 알티베이스에서 파티션 조건은 다음과 같은 규칙을 항상 만족해야 한다. column_domain ≡ ∪partition_condition ……………… rule3 위의 규칙은 파티션 조건에 참여하는 칼럼의 도메인(column_domain)이 파티션 조건들의 합집합과 동치관계여야 한다. 이는 파티션드 테이블 생성시에 모든 파티션 조건들을 명시적으로 기술해야 함을 의미한다. 그러나 현실적으로 질의문을 기술하는 사용자가 모든 파티션 조건을 기술한다는 것은 불가능하기 때문에 알티베이스에서는 기본 파티션(default partition)이라는 개념을 제공한다. [그림 6-9]에서는 3 개의 파티션을 갖는 파티션드 객체를 예를 들어 370 ALTIBASE5 Administrator’s Manual 기본 파티션을 설명하고 있다. 아래 사용자가 명시적으로 P1 및 P2 에 대한 파티션 조건(partition_condition1, partition_condition2)을 명시하였으며, P3 에 대해서 기본 파티션을 선언하였다. 이러한 경우, 삽입되는 레코드가 partition_condition1 과 partition_condition2 에 걸리지 않는다면 해당 레코드는 P3 에 삽입된다. 즉, 기본 파티션은 파티션 칼럼이 갖는 전체 도메인에서 사용자가 지정한 파티션 조건들을 뺀 나머지 도메인과 같다. [그림 6-9] 기본 파티션 사용 예제 이러한 기본 파티션은 파티션드 객체의 생성시 반드시 기술해야한다. 만약 기술하지 않는다면 파티션드 객체 생성에 실패한다. 이는 파티션 이름에 대한 규칙을 명시적으로 하기 위함이다. create table(…) partition by range(…) ( partition P1 partion_condition1, partition P2 partion_condition2, partition P3 default ) TABLESPACE SYS_TBS_DISK_DATA; P1 P2 P3(default partition) 파티션드 테이블 371 파티션 방법 파티션을 나누는 방법으로 범위 파티션, 리스트 파티션, 해시 파티션을 사용할 수 있다. 범위 파티션은 파티션 키 값의 범위(range)를 기준으로 파티션하는 방법으로, 선형적(linear) 범위의 파티션을 구성할 때 사용된다. 리스트 파티션은 파티션 키 값의 집합을 기준으로 파티션을 하는 방법으로 이산적(discrete) 범위의 파티션을 구성하고 싶은 경우에 사용된다. 해시 파티션은 파티션 키 값의 해시(hash) 값을 기준으로 파티션하는 방법이다. 이들 파티션들은 방법에 따라 다음과 같이 연산을 지원한다. 범위 파티션 리스트 파티션해시 파티션 추가 X X ○ 병합 X X ○ 삭제 ○ ○ X 합병 ○ ○ X 이름 변경 ○ ○ ○ 분할 ○ ○ X 레코드 삭제 ○ ○ ○ [표 6-1] 파티션 방법에 따른 연산 범위 파티션 범위 파티션(range partition)은 파티션을 할 때 날짜(DATE) 타입을 많이 이용하며, 이력 데이터(historical data)를 다루는 분야에서 사용된다. 기본 파티션을 지원하기 위해서 ‘DEFAULT’라는 구문을 지원하며, 파티션 조건은 ‘LESS THAN’으로 제한한다. 다음은 범위 파티션을 이용한 예제이다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) PARTITION BY RANGE(sales_date) ( PARTITION part_1 VALUES LESS THAN ( TO_DATE(‘01-FEB- 2006’) ), PARTITION part_2 VALUES LESS THAN ( TO_DATE(‘01- MAR-2006’) ), 372 ALTIBASE5 Administrator’s Manual PARTITION part_3 VALUES LES THAN ( TO_DATE(‘01-APR- 2006’) ), PARTITION part_def VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; 위의 예는 파티션 4 개를 범위 파티션 방법을 이용하여 part_table 을 생성하는 예제이다. 처음 3 개의 파티션은 각각 FEB 와 MAR, APR 이전의 데이터를 관리하며, 각 조건에 포함되지 않는 데이터를 관리하기 위해서 part_def 라는 기본 파티션을 생성한다. 위의 예를 그래피컬 방식으로 표현하면 [그림 6-10]과 같다. TO_DATE ( ‘01- FEB- 2006’) TO_DATE ( ‘01- M AR- 2006’) TO_DATE (‘01-APR-2006’) p a r t _1 p a r t _2 p a r t _3 p a r t _d ef ∞ -∞ [그림 6-10] 범위 파티션드 테이블의 파티션 영역 다중칼럼 파티셔닝(Multicolumn Partitioning) 다중칼럼 파티셔닝은 다중칼럼으로 구성된 파티션 키를 이용하여 파티션 객체를 파티셔닝하는 것을 의미한다. 다중칼럼 파티셔닝은 다중키를 갖는 인덱스와 동일한 개념을 갖는다. 다음 그림은 파티션 키가 2 개 칼럼(i1, i2)으로 구성되었을 때, 이를 1 차원 형태로 표현한 것이다. -∞ ∞ -∞∞ -1 (i 1 , i 2 ) -∞∞ 0 -∞∞ 1...... [그림 6-11] 다중칼럼 파티셔닝의 파티션 영역 다음은 다중칼럼을 갖는 파티션닝에 대해서 SQL 을 예로 들어 설명하고 있다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) PARTITION BY RANGE(sales_date, sales_id) ( PARTITION part_1 VALUES LES THAN ( TO_DATE(‘01-FEB- 2006’), 20), PARTITION part_2 VALUES LES THAN ( TO_DATE(‘01- MAR-2006’), 100), 파티션드 테이블 373 PARTITION part_3 VALUES LESS THAN ( TO_DATE(‘02- MAR-2006’)), PARTITION part_4 VALUES LESS THAN ( TO_DATE(‘01-APR- 2006’) ), PARTITION part_def VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; 위의 테이블 생성 구문을 그림으로 설명하면 다음과 같다. [그림 6-12] SQL 예제의 파티션 영역 다음 표는 삽입될 레코드가 갖는 값이 다음과 같을때 레코드가 삽입될 파티션과 해당 파티션에 삽입을 유도한 포함 조건이 무엇인지 설명하고 있다. 삽입될 레코드가 갖는 값 (sales_date, sales_id) 삽입될 파티션 TO_DATE(‘15-JAN-2006’), 100 part_1 TO_DATE(‘01-FEB-2006’), 100 part_1 TO_DATE(‘01-FEB-2006’), 200 part_2 TO_DATE(‘15-FEB-2006’), NULL part_2 TO_DATE(‘01-MAR-2006’), 50 part_2 TO_DATE(‘01-MAR-2006’), NULL part_3 TO_DATE(‘15-MAR-2006’), 200 part_4 NULL, 100 part_def NULL, NULL part_def 범위 파티션의 연산 범위 파티션드 객체에서 수행될 수 있는 연산의 종류는 5 가지이다. 범위 파티션드 객체에서 제공하는 연산들은 파티션 분할, 파티션 삭제, 파티션 합병, 파티션 이름 변경, 파티션 레코드 삭제이다. 파티션 조건 변경은 현재는 지원하지 않는다. 374 ALTIBASE5 Administrator’s Manual 범위 파티션에서 파티션 추가는 파티션 조건이 분할되는 과정과 동일하기 때문에 ‘Split Partition’을 이용한다. 파티션 삭제는 파티션 조건을 삭제하는 것과 동일하며 ‘Drop Partition’을 사용한다. 파티션 삭제시, 삭제된 파티션 조건은 이웃한 파티션의 조건에 포함된다. 또한 레코드의 삭제 여부를 가지고 ‘Drop Partition’과 ‘Merge Partition’으로 구분한다. 파티션 이름 변경은 ‘Rename Partition’으로 처리한다. 파티션 레코드 삭제는 ‘Truncate Partition’을 이용하여, 파티션 내에 저장된 모든 레코드를 삭제한다. 파티션 분할 파티션 분할(Partition Split)은 파티션드 객체가 갖는 파티션을 2 개의 파티션으로 분할하는 연산이다. 파티션 분할은 분할 방식에 따라 다음의 2 가지 경우로 나뉜다. y 인플레이스 분할(In-place Split) 기존 파티션의 레코드 일부를 잘라 새로운 파티션에 이동하는 분할 방식으로, 기존 파티션의 내용이 변경된다. 새로운 파티션의 이름이 기존 파티션의 이름이 같고, 새 파티션이 생성될 테이블스페이스를 지정하지 않으면 인플레이스 분할 방식이 사용된다. ([그림 6-13] 참조) y 아웃플레이스 분할(Out-place Split) 기존 파티션의 내용은 변경되지 않는다. 대신 새로운 2개의 파티션을 생성하여, 기존 파티션의 레코드를 복사하는 분할 방식이다. 새로운 파티션의 이름을 기존 파티션의 이름과 다르게 정한경우이거나, 분할된 새 파티션이 기존 파티션의 이름과 같더라도 새 파티션이 생성될 테이블스페이스를 지정한 경우에 사용된다. ([그림 6-14] 참조) 위의 아웃플레이스와 인플레이스 분할 방식은 성능과 효율성에서 차이가 날 수 있다. 인플레이스 분할은 기존의 기존 파티션과 새로운 파티션이 같기 때문에 1 개의 새로운 파티션만을 생성한다. 따라서, 공간적인 측면에서 이득이 될수 있다. 아웃플레이스 분할은 새로운 2 개의 파티션을 생성하고 각각의 파티션에 레코드 삽입 연산이 이루어진다. 인플레이스 분할에서의 레코드 연산은 레코드 이동(MOVE: 삽입 처리되며, MVCC 환경에서 레코드 삭제 연산은 레코드 삽입 연산에 비해 성능이 많이 떨어진다. 따라서, 인플레이스 분할은 저장 공간이 부족할 때 효율적이며, 아웃플레이스 분할은 저장 공간이 충분한 MVCC 환경에서 좋은 성능을 나타낸다. 파티션드 테이블 375 TO_DATE ( ‘01- FEB- 2006’ ) TO_DATE (‘01-M AR-2006’) TO_DATE (‘01-APR-2006’) par t _1 par t _2par t _3 par t _def ∞-∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-M AR-2006’) TO_DATE (‘01-APR-2006’) par t _1par t _2par t _3par t _def ∞-∞ par t _4 TO_DATE (‘15-FEB-2006’) ALTER TABLE par t _tabl e SPLI T PARTI TI ON par t_2 AT (TO_DATE( ‘ 15- FEB- 2006’)) I NTO (PARTI TI ON part_2, PART I T I ON part_4); sh r i n k condition r ecor ds insert records [그림 6-13] 범위 파티션드 객체에서 인플레이스 분할 위의 그림에서 보여준 예는 4 개의 파티션을 갖는 파티션드 객체에서 part_2 를 part_2 와 part_4 로 분할하는 것을 설명하고 있다. ①새로운 파티션 part_4 가 생성되며, ②기존 part_2 에서 part_4 로의 레코드 이동(MOVE: 삽입 幣碩홱 마지막으로 ③part_2 의 조건이 지정된 조건으로 축소된다. TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-M AR-2006’) TO_DATE (‘01-APR-2006’) par t _1 par t _2par t _3 par t _def ∞-∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-M AR-2006’) TO_DATE (‘01-APR-2006’) par t _1par t _2par t _3par t _def ∞-∞ par t _4 TO_DATE ( ‘ 15-FEB-2006’ ) ALTER TABLE par t _t able SPLI T PARTI TI ON part _2 AT (TO_DATE(‘ 15- FEB- 2006’)) I NTO (PARTI TI ON par t _2 TABLESPACE t bs_01, P AR T I T I O N par t_4); insert r ecor ds insert r ecor ds [그림 6-14] 범위 파티션드 객체에서 아웃플레이스 분할 위의 그림에서 보여준 예는 4 개의 파티션을 갖는 파티션드 객체에서 part_2 를 part_2 와 part_4 로 분할하는 것을 설명하고 있다. ①새로운 파티션 part_2 와 part_4 가 생성되며, ②part_2(old)에서 part_2(new)와 part_4 로의 레코드 삽입이 진행된다. 마지막으로 ③part_2(old)가 물리적으로 삭제된다. 기본 파티션 분할시, INTO 절 두 번째 파티션이 자동으로 기본 파티션으로 설정된다. 이는 INTO 하위절에 기본 파티션을 지정할수 있는 구문을 지원하지 않기 때문이다. 파티션 삭제 파티션 삭제(Partition Drop)는 파티션드 객체가 갖는 파티션들 376 ALTIBASE5 Administrator’s Manual 중에 지정된 파티션을 삭제하는 연산이다. 파티션 삭제시 삭제될 파티션이 갖는 모든 레코드와 메타 정보들은 물리적으로 삭제된다. 또한 삭제될 파티션의 조건은 이웃한 파티션으로 흡수된다. TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-M AR-2006’) TO_DATE (‘01-APR-2006’) par t _1 par t _2par t _3 par t _def ∞-∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-APR-2006’) par t _1 par t _3par t _def ∞-∞ ALT ER T ABLE p ar t _t a bl e DROP PARTI TI ON par t_2; del et e records exp an d condition [그림 6-15] 범위 파티션드 객체에서 part_2를 삭제하는 예제 위의 그림에서 보여준 예는 4 개의 파티션을 갖는 파티션드 객체에서 part_2 의 삭제 과정을 설명하고 있다. ①part_2 의 물리적 공간(레코드, 메타정보)이 삭제되고, ②이웃한 파티션(part_2 의 조건을 포함할수 있는 조건을 가진 파티션)인 part_3 으로 파티션 조건이 흡수된다. 파티션 합병 파티션 합병(Partition Merge)은 파티션드 객체가 갖는 파티션들중에 지정된 파티션 2 개를 하나의 파티션으로 합병하는 연산이다. 지정된 파티션은 반드시 이웃하는 파티션이어야 한다. 파티션 합병은 합병 방식에 따라 인플레이스 합병과 아웃플레이스 합병으로 나뉜다. y 인플레이스 합병(In-place Merge) 기존의 두개 파티션에서 하나의 파티션으로 합쳐지면서, 다른 파티션의 레코드가 삽입되는 방식이다. 새로운 파티션과 기존 파티션의 이름이 같고, 새로운 파티션이 생성될 테이블스페이스를 지정하지 않은 경우에 사용된다.([그림 6- 16] 참조) y 아웃플레이스 합병(Out-place Merge) 새로운 파티션이 추가로 생성되어 기존 파티션들의 레코드들이 새로운 파티션으로 복사되는 방식이다. 새로운 파티션과 기존 파티션의 이름이 다른 경우이거나, 새로운 파티션(분할된 파티션)과 기존 파티션의 이름이 같더라도 새로운 파티션이 생성될 테이블스페이스를 지정한 경우에 사용된다. ([그림 6- 17] 참조) 인플레이스 합병과 아웃플레이스 합병은 성능과 효율성에서 차이가 파티션드 테이블 377 날 수 있다. 인플레이스 합병은 새로운 파티션을 생성하지 않고, 레코드 삽입 연산만 하기 때문에 성능면에서 아웃플레이스 합병보다 유리하다. TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-M AR-2006’) TO_DATE (‘01-APR-2006’) par t _1 par t _2par t _3 par t _def ∞-∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-APR-2006’) par t _1 par t _3par t _def ∞-∞ insert records expand condition ALT ER T ABLE p ar t _t a bl e M ERGE PART I T I ON S part_2, part_3 INTO PARTITION part_3; [그림 6-16] 범위 파티션드 객체에서의 인플레이스 합병 위의 그림에서 보여준 예는 4 개의 파티션을 갖는 파티션드 객체에서 part_2 와 part_3 를 part_3(old)로 합병하는 것을 설명하고 있다. ①기존 part_3 의 조건이 확장되며, ②기존 part_2 에서 part_3 로의 레코드 삽입이 진행된다. 마지막으로 ③part_2 가 물리적으로 삭제된다. TO_DATE ( ‘01-FEB- 2006’) TO_DATE ( ‘01- M AR- 2006’) TO_DATE (‘01- APR- 2006’) par t _1 par t _2par t _3 p a r t _d ef ∞-∞ TO_DATE (‘01-FEB-2006’) TO_DATE ( ‘01- APR- 2006’) par t _1 par t _3p a r t _d ef ∞-∞ insert records insert r ecor ds ALTER TABLE par t _t abl e M ERGE PART I T I ON S par t _2, par t _3 INTO PARTITION p ar t _3 T ABLESPACE t bs_0 1; [그림 6-17] 범위 파티션드 객체에서의 아웃플레이스 합병 [그림 6-17]에서 4 개의 파티션을 갖는 파티션드 객체에서 part_2 와 part_3 를 part_3(new)로 합병하는 것을 설명하고 있다. ①새로운 파티션 part_3 가 생성되며, ②기존 part_2 와 part_3(old)에서 part_3(new)로 레코드 삽입이 진행된다. 마지막으로 ③part_2 와 part_3(old)가 물리적으로 삭제된다. 파티션 이름 변경 파티션 조건은 변경되지 않으며, 파티션 이름만 변경된다 파티션 레코드 삭제 378 ALTIBASE5 Administrator’s Manual 파티션 레코드 삭제(partition truncate)는 파티션 조건이 변경되지 않으며, 파티션에 저장되어 있는 모든 레코드들이 삭제된다. 리스트 파티션 리스트 파티션(list partition)은 파티션 키 값의 집합을 기준으로 파티션하는 방법이다. 파티션 칼럼 값의 범위가 크지 않을 경우(예: 1 월 ~ 12 월)에 자주 사용되는 파티션 방법이다. 리스트 파티션은 원칙적으로 파티션 칼럼에 다중키를 지원하지 않는다. 범위 파티션과 동일하게 기본 파티션을 지원하기 위해서 ‘DEFAULT’라는 구문을 지원한다. [그림 6-18]에서 나타난 것처럼 처음 3 개의 파티션은 특정 도시별로 데이터를 관리하며, 각 조건에 포함되지 않는 데이터를 관리하기 위해서 part_def 라는 기본 파티션을 생성하였다. “SEOU L” “I N CH EON ”“PUSAN” “JUNJU” “CH U N GJU ” “DAEJUN” DEFAULTpar t _1 par t _2 par t _3 par t _def [그림 6-18] 리스트 파티션드 테이블의 파티션 영역 즉 다음과 같이 위의 그림은 파티션 4 개를 리스트 파티션을 이용하여 part_table 을 생성하는 예제이다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) PARTITION BY LIST(sales_city) ( PARTITION part_1 VALUES ( ‘SEOUL’ , ‘INCHEON’ ), PARTITION part_2 VALUES ( ‘PUSAN’ , ‘JUNJU’ ), PARTITION part_3 VALUES ( ‘CHUNGJU’ , ‘DAEJUN’ ), PARTITION part_def VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; 리스트 파티션의 연산 파티션드 테이블 379 리스트 파티션드 객체에서 수행될 수 있는 연산의 종류는 5 가지이다. 리스트 파티션드 객체에서 제공하는 연산들은 파티션 분할, 파티션 삭제, 파티션 합병, 파티션 이름 변경, 파티션 레코드 삭제이다. 파티션 조건 변경은 지원하지 않으며, 범위 파티션과 동일한 SQL 구문을 사용한다. 파티션 분할 리스트 파티션에서의 파티션 분할은 범위 파티션과 동일하게 인플레이스 분할과 아웃플레이스 분할을 지원한다. 파티션을 분할할 때 파티션 이름이 같을 경우 테이블스페이스를 지정했는지에 따라 인플레이스 분할이나 아웃플레이스 분할로 사용된다. “SEOU L” “I N CH EON ”“PU SAN” “JU N JU ” “CH U NGJU ” “D AEJU N” DEFAULTpar t _1 par t _2 par t _3 par t _def par t _4 insert r ecor ds “SEOU L” “I N CH EON ”“JU N JU ” “CHUNGJU” “D AEJU N” DEFAULT “PU SAN ” ALTER TABLE par t _t abl e SPLI T PARTI TI ON par t _2 VALU ES( ‘ PU SAN ’ ) I NTO ( PARTI TI ON part_4, P AR T I T I O N part_2); del et e r ecor ds [그림 6-19] 리스트 파티션드 객체에서의 인플레이스 분할 위의 그림에서 보여준 예는 4 개의 파티션을 갖는 파티션드 객체에서 part_2 를 part_2 와 part_4 로 분할하는 것을 설명하고 있다. ①새로운 파티션 part_4 가 생성되며, ②기존 part_2 에서 part_4 로의 레코드 이동(MOVE: 삽입 행된다. 마지막으로 ③part_2 의 조건이 지정된 조건으로 축소({‘PUSAN’, ‘JUNJU’} -> {‘JUNJU’})된다. 380 ALTIBASE5 Administrator’s Manual “SEOU L” “I N CH EON ”“PU SAN” “JU N JU ” “CH U NGJU ” “D AEJU N” DEFAULTpar t _1 par t _2 par t _3 par t _def par t _4 insert r ecor ds “SEOU L” “I N CH EON ”“JU N JU ” “CHUNGJU” “D AEJU N” DEFAULT “PU SAN ” ALTER TABLE par t _t abl e SPLI T PARTI TI ON par t _2 VALU ES( ‘ PU SAN ’ ) I NTO ( PARTI TI ON part_4, P AR T I T I O N par t _2 TABLESPACE t bs_01); insert r ecor ds [그림 6-20] 리스트 파티션드 객체에서의 아웃플레이스 분할 위의 그림 예는 4 개의 파티션을 갖는 파티션드 객체에서 part_2 를 part_2 와 part_4 로 분할하는 것을 설명하고 있다. ①새로운 파티션 part_2 와 part_4 가 생성되며, ②part_2(old)에서 part_2(new)와 part_4 로의 레코드 삽입이 진행된다. 마지막으로 ③part_2(old)가 물리적으로 삭제된다. 파티션 삭제 리스트 파티션에서의 파티션 삭제는 범위 파티션과 유사하며, 다만 삭제될 파티션이 갖는 파티션 조건은 기본 파티션의 조건으로 흡수된다는 점만 다르다. “SEOU L” “I NCH EON”“PUSAN” “JUNJU” “CH UNGJU” “D AEJU N ” DEFAULTpar t _1 par t _2 par t _3 p a r t _d ef del et e r ecor ds “SEOU L” “I N CH EON ” “CH UNGJU” “D AEJU N ” DEFAULT ALTER TABLE par t _t able DROP PARTI TI ON part_2; [그림 6-21] 리스트 파티션드 객체에서 part_2를 삭제하는 예제 위의 그림에서 보여준 예는 4 개의 파티션을 갖는 파티션드 객체에서 part_2 를 삭제하는 것을 설명하고 있다. ①part_2 가 갖는 물리적인 공간(레코드, 메타정보)이 삭제되고, ② part_2 의 조건이 파티션드 테이블 381 기본 파티션 part_def 로 흡수된다. 파티션 합병 리스트 파티션에서의 파티션 합병은 범위 파티션과 동일하게 인플레이스 합병과 아웃플레이스 합병을 지원한다. 파티션을 합병할할 때 파티션 이름이 같을 경우 테이블스페이스를 지정했는지에 따라 인플레이스 합병이나 아웃플레이스 합병으로 사용된다. “SEOU L” “I N CH EON ”“PU SAN” “JU N JU ” “CHUNGJU” “DAEJUN” DEFAULTpar t _1 par t _2 par t _3 par t _def insert r ecor ds “SEOU L” “I N CH EON ” DEFAULT exp an d condition ALTER TABLE par t _t able MERGE PARTITIONS par t _2, par t _3 INTO PARTITION part_3; “PU SAN” “JU NJU ” “CH U N GJU ” “D AEJU N ” [그림 6-22] 리스트 파티션드 객체에서의 인플레이스 합병 위의 그림에서 보여준 예는 4 개의 파티션을 갖는 파티션드 객체에서 part_2 와 part_3 를 part_3(old)로 합병하는 것을 설명하고 있다. ①기존 part_3 의 조건이 확장되며, ②기존 part_2 에서 part_3 로 레코드 삽입이 진행된다. 마지막으로 ③part_2 가 물리적으로 삭제된다. “SEOU L” “I N CH EON ”“PU SAN” “JU N JU ” “CHUNGJU” “D AEJU N” DEFAULTpar t _1 par t _2 par t _3 par t _def insert records “SEOU L” “I N CH EON ”“PU SAN” “JU NJU ” “CHUNGJU” “D AEJU N ” DEFAULT insert records ALTER TABLE par t _t able MERGE PARTITIONS part_2, part_3 INTO PARTITION p ar t _3 T ABLESPACE t bs_0 1; [그림 6-23] 리스트 파티션드 객체에서 아웃플레이스 합병 382 ALTIBASE5 Administrator’s Manual 위의 그림에서 보여준 예는 4 개의 파티션을 갖는 파티션드 객체에서 part_2 와 part_3 를 part_3(new)로 합병하는 것을 설명하고 있다. ①새로운 파티션 part_3 가 생성되며, ②기존 part_2 와 part_3(old)에서 part_3(new)로의 레코드 삽입이 진행된다. 마지막으로 ③part_2 와 part_3(old)가 물리적으로 삭제된다. 파티션 이름 변경 파티션 조건은 변경되지 않으며, 파티션의 이름이 변경된다. 파티션 레코드 삭제 파티션 조건은 변경되지 않으며, 파티션에 저장되어 있는 모든 레코드들이 삭제된다. 해시 파티션 해시 파티션(Hash Partition)은 파티션 키의 해시(hash) 값을 기준으로 파티션하는 방법이다. 파티션 키는 다중 칼럼으로 구성될 수 있으며, 관리의 용이성보다는 데이터의 고른 분포를 요구하는 부하 분배에 많이 사용되는 방법이다. 해시 파티션은 해시의 특성으로 일반적인 파티션 연산에 제한을 받는다. 범위 파티션과 리스트 파티션과 달리 파티션 분할, 삭제, 합병(merge) 등의 작업을 수행할 수 없으며, 파티션 추가, 병합(coalesce)과 같은 해시 전용 작업은 수행이 가능하다. 해시 파티션은 범위 파티션과 리스트 파티션과 달리 기본 파티션을 지원하지 않는다. 이는 해시 자체가 파티션 키의 모든 값을 수용할 수 있기 때문이다. 널(null) 데이터가 삽입되는 위치는 널에 대한 해시 값에 의존한다. 널의 해시값은 고정된 상수지만, 데이터 타입마다 상이한 값을 갖는다. 널 데이터는 칼럼의 타입에 따라 저장되는 위치가 변경될 수 있다. 다음은 해시 파티션을 이용하여 4 개의 파티션을 part_table 로 생성하는 예제를 보여준다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) PARTITION BY HASH(sales_id) ( PARTITION part_1, PARTITION part_2, 파티션드 테이블 383 PARTITION part_3, PARTITION part_4 ) TABLESPACE SYS_TBS_DISK_DATA; 각 파티션은 HASH(sales_id, 4) 로 분리한 데이터를 관리한다. 위의 예를 도식화하면 [그림 6-24]와 같이 나타난다. par t _1 par t _2 par t _3 par t _4 H ASH ( sales_id, 4) [그림 6-24] 해시 파티션드 테이블의 파티션 영역 해시 파티션의 연산 해시 파티션드 객체에서 수행될 수 있는 연산의 종류는 4 가지이다. 해시 파티션드 객체에서 제공하는 연산들은 파티션 추가, 파티션 병합, 파티션 이름 변경, 파티션 레코드 삭제이다. 해시 파티션에서의 파티션 추가는 ‘Add Partition’을 이용한다. 파티션 병합은 ‘Coalesce Partition’을 이용하여 처리하며, 마지막 파티션이 삭제되고, 해당 파티션의 레코드는 기존 레코드들과 함께 파티션드 객체 전체가 재구성(reorganization)된다. 파티션 이름 변경은 ‘Rename Partition’으로 처리한다. 파티션 레코드 삭제(파티션에 저장된 모든 레코드 삭제)는 ‘Truncate Partition’을 이용해 처리한다. 파티션 추가 해시 파티션에서 파티션의 추가는 해시 키가 숫자적으로 커짐을 의미한다. 파티션의 추가는 기존의 모든 파티션에 영향을 미치게 된다. 해시 키가 변경되면 테이블의 레코드 전체가 변경된 파티션들로 재구성(reorganization)된다. 아래 그림은 이러한 파티션 추가를 설명하고 있다. 384 ALTIBASE5 Administrator’s Manual par t _1 par t _2 par t _3 par t _4 part_1 part_2 part_3 part_4 H ASH ( sales_id, 4) H ASH ( sales_id, 5) par t _5 add par t _5 n i z a t i on ALTER TABLE par t _t abl e ADD PARTI TI ON par t_5; [그림 6-25] 해시 파티션드 객체의 파티션 추가 위의 그림 예는 4 개의 파티션을 갖는 파티션드 객체에서 part_5 를 추가하는 것을 설명하고 있다. ①새로운 파티션 part_5 가 생성되며, ②기존 파티션 4 개의 레코드들이 기존 4 개의 파티션과 1 개의 새로 생성된 파티션으로 재분배된다. 파티션 병합 해시 파티션에서 파티션의 병합(Coalesce)은 해시 키가 숫자적으로 작아짐을 의미한다. 파티션의 병합은 기존의 모든 파티션에 영향을 미친다. 해시 파티션에서 파티션 병합은 마지막 파티션이 삭제되고, 해당 파티션의 레코드가 기존의 레코드들과 함께 파티션드 객체 전체가 재구성(reorganization)된다. 파티션 병합을 할 때 삭제될 파티션 이름은 정할 수 없고, 마지막 파티션부터 1 개씩 삭제된다. 예를 들어 4 개의 파티션(part_1, part_2, part_3, part_4)을 갖는 파티션드 객체를 병합하면 part_4 가 삭제되고 3 개의 파티션(part_1, part_2, part_3)을 갖는 파티션드 객체로 줄어든다. 아래 그림은 이러한 파티션 병합을 설명하고 있다. 파티션드 테이블 385 [그림 6-26] 해시 파티션드 객체의 파티션 병합 위의 그림은 4 개의 파티션을 갖는 파티션드 객체에서 파티션 병합하는 것을 설명하고 있다. ①기존 파티션 4 개의 레코드들이 part_1, part_2, part_3 으로 재분배되고, ②마지막 파티션 part_4 가 삭제된다. 파티션 이름 변경(Rename Partition) 파티션 조건은 변경되지 않으며, 파티션의 이름이 변경된다. 파티션 레코드 삭제(Truncate Partition) 파티션 조건은 변경되지 않으며, 파티션에 저장되어 있는 모든 레코드들이 삭제된다. 트랜잭션 관리 387 7. 트랜잭션 관리 사용자 트랜잭션의 동시성을 제어하고 데이터의 일관성을 유지하는 것이 데이터베이스의 가장 기본적인 기능의 하나다. 이장에서는 알티베이스의 트랜잭션 관리 기능에 대해서 알아보자. 388 ALTIBASE5 Administrator’s Manual 트랜잭션 트랜잭션의 정의 트랜잭션(Transaction)이란 하나 이상의 SQL 문장들로 이루어진 논리적인 작업 단위를 말한다. 은행에서 예금을 이체하는 작업이 트랜잭션의 대표적인 예가 될 수 있다. A 계좌에서 B 계좌로 100 을 이체한다고 가정하면 다음과 같은 작업들이 이뤄져야 한다. 1. A 계좌에서 100의 금액을 감소시킨다. 2. B 계좌에 100의 금액을 증가시킨다. 3. A에서 B계좌로 이체한 사실을 작업내용에 기록한다. 일관된(Consistent) 데이터베이스에서 정상적인 트랜잭션이 수행되면 다시 일관된 상태로 되어야 한다. 만일, 위의 트랜잭션이 열거한 세가지 작업 중 한 가지라도 정상적으로 수행되지 않으면, 데이터베이스의 무결성이 깨져서 A 계좌의 고객, B 계좌의 고객, 혹은 은행이 손해를 보는 경우가 발생한다. 정상적인 트랜잭션은 수행 후의 데이터베이스 무결성을 유지시키기 위해 다음과 같은 ACID 특성을 만족시켜야 한다. y Atomicity: 트랜잭션 내의 모든 문장이 모두(all) 반영되거나, 혹은 모두 반영되지 않아야(nothing) 한다. y Consistency: 트랜잭션의 수행으로 데이터베이스의 무결성이 깨어져서는 안 된다. y Isolation: 여러 개의 트랜잭션들이 동시에 수행될 때, 한 개의 트랜잭션이 다른 트랜잭션의 영향을 받지 않아야 한다. y Durability: 일단 수행이 완료된(Committed) 트랜잭션은 어떤 상황 하에서도 그 내용을 영구적으로 유지할 수 있어야 한다. 문장 문장(statement)은 트랜잭션 내에서 수행되는 SQL 문 하나 하나를 일컫는 말이다. 문장의 종류에는 다음과 같은 세 종류가 있다. y DCL (Data Control Language): 데이터베이스의 상태나 프로퍼티 혹은 물리적 구성을 변경시키는 문장들이다. y DDL (Data Definition Language): 데이터베이스의 논리적 구성 요소인 객체들(테이블, 인덱스, 시퀀스, …)의 생성, 변경 및 삭제를 수행하는 문장들이다. y DML (Data Manipulation Language): 데이터베이스 내에 트랜잭션 관리 389 저장되는 실제 데이터들의 삽입, 삭제, 변경 및 검색을 수행하는 문장들이다. 일반적으로 하나의 SQL 문이 하나의 문장이 되지만, 저장 프로시저나 함수 등이 호출되면 하나 이상의 하위 문장들이 생성되어 수행된다. 문장의 수행도 역시 데이터베이스의 무결성을 해치지 않아야 한다. 문장 수행 중 에러가 발생하면 해당 문장에서 수행한 모든 작업이 이전 상태로 되돌려진다. 이를 위해, 각 문장은 시작하기 전에 암묵적 저장점(Implicit Save Point)을 설정해 두고, 오류 발생시 이 지점까지의 복원을 수행한다. 트랜잭션의 커밋 트랜잭션의 커밋(commit)이란 지금까지 트랜잭션 안에서 수행한 모든 SQL 문의 결과를 데이터베이스에 영구적으로 반영하면서 해당 트랜잭션을 종료하는 연산이다. 트랜잭션의 커밋은 데이터베이스의 상태를 이전의 무결한 상태에서 또 다른 무결한 상태로 전이시킨다. 알티베이스에서 트랜잭션의 커밋으로 다음과 같은 작업을 수행한다. y 로그 파일에 커밋 로그를 기록한다. y 트랜잭션의 수행으로 발생된 해제 가능한 자원들의 정보를 가비지 콜렉터(Garbage Collector)에게 넘겨준다. y 트랜잭션의 상태를 커밋 상태로 변경시킨다. y 트랜잭션 수행 중에 할당 받은 자원들을 반환한다.(잠금, 임시 메모리 등) 트랜잭션의 롤백 트랜잭션의 수행 도중에 치명적인 오류가 있어 더 이상 진행할 수 없는 경우에는 지금까지 수행해 왔던 모든 SQL 문들을 다시 되돌려서, 데이터베이스를 트랜잭션 수행 이전 상태로 변경시켜야 한다. 이를 트랜잭션의 롤백이라고 한다. 트랜잭션의 롤백은 트랜잭션 수행 중에 기록한 각 로그들에 대한 보상(compensation) 연산을 수행함으로써 구현된다. 알티베이스에서 트랜잭션 롤백 시 수행하는 일들은 다음과 같다. y 로그 레코드를 기록 순서와 반대로 읽어가며 보상 연산을 수행한다. 390 ALTIBASE5 Administrator’s Manual y 트랜잭션의 롤백 로그를 기록한다. y 삽입 등의 연산으로 할당 받았던 자원들을 다시 가비지 콜렉터에게 반환한다. y 트랜잭션의 상태를 롤백 상태로 변경한다. y 트랜잭션 수행 중에 할당받은 자원들을 반환한다. (잠금, 임시 메모리 등) 명시적 저장점 하나의 긴 트랜잭션을 여러 개의 부분으로 나누어 관리하여야 하는 경우, 그 부분의 시작 지점에 명시적 저장점(Explicit Save Point)을 선언하여 사용할 수 있다. 명시적 저장점은 이름을 가지므로, 한 트랜잭션 내에 여러 개를 선언할 수도 있다. 명시적 저장점 선언 이후 오류가 발생하여 선언한 지점으로 데이터베이스를 다시 복원을 해야 하는 경우에는, 해당 저장점으로의 롤백을 수행하면 된다. 명시적 저장점으로의 롤백이 수행되면 이후에 잡았던 잠금(테이블, 레코드)등의 자원들이 모두 해제되며, 해당 저장점 이후에 선언된 다른 저장점들은 모두 해제된다. 트랜잭션 관리 391 잠금(Lock)의 개요 잠금 모드 잠금이란 데이터베이스 내에 존재하는 특정 객체에 대한 접근 권한을 설정한 것을 의미한다. 잠금에는 그 사용 대상에 따라 테이블 레벨 잠금과 레코드 레벨 잠금으로 나뉜다. 테이블 레벨 잠금 모드(Table Level Lock Modes) 잠금 모드 설명 기능 S Shared Lock 레코드 잠금의 획득 없이 테이블의 모든 레코드를 검색할 수 있으며 레코드 검색 만을 수행하는 다른 트랜잭션들과도 동시 에 수행될 수 있다. X Exclusive Lock 레코드 잠금의 획득 없이 테이블의 모든 레코드를 검색 및 변경할 수 있으며 그 테이블에 대해 오직 한 트랜잭션만이 검 색 및 수정 연산을 수행할 수 있다. IS Intensive Shared Lock 레코드 잠금을 획득한 후 레코드에 대한 검색을 할 수 있다는 점을 제외하고는 S 모드와 동일하다. IX Intensive Exclusive Lock 레코드 잠금을 획득한 후 레코드에 대한 검색 및 수정을 할 수 있다. 서로 다른 레코드를 수정하는 트랜잭션들은 동시에 여러 개 존재할 수 있다. SIX Intensive Exclusive Shared Lock 레코드 잠금을 획득한 후 레코드에 대한 검색 및 수정을 할 수 있다. 레코드에 대 한 수정 연산은 오직 한 트랜잭션만이 수 행할 수 있다. [표 7-1] 잠금 모드의 종류 의사 모드 잠금(Intention Mode Lock) - IS, IX, SIX 잠금을 걸 수 있는 객체는 여러 가지 일 수 있으며 그 객체들은 데이터베이스 내에서 사용되는 크기가 다양할 수 있다. 예를 들어 잠금을 걸 수 있는 객체는 데이터베이스 자체, 스키마, 테이블, 레코드, 칼럼 등이 될 수 있으며 이들의 크기는 다음 순서를 가진다. 데이터베이스 > 스키마 > 테이블 > 레코드 > 칼럼 이처럼 잠금을 걸 수 있는 대상이 되는 객체의 크기를 잠금 단위(granularity)라 한다. 잠금 단위가 큰 객체에 대해서만 잠금을 392 ALTIBASE5 Administrator’s Manual 지원하는 경우 그만큼 동시성 제어가 떨어진다. 왜냐하면 한 트랜잭션이 실제 작업 대상이 되는 객체는 레코드이기 때문에 레코드 이상의 객체에 대해서만 잠금 단위를 지원하는 경우 한 트랜잭션이 테이블 내의 레코드 하나에 대해서만 연산을 수행하더라도 그 테이블의 다른 레코드에 대해서 연산을 하고자 하는 다른 트랜잭션은 먼저 시작한 트랜잭션이 끝나기를 기다려야 하는 경우가 발생하기 때문이다. 따라서, 지원되는 잠금 단위는 최소 단위가 레코드인 것이 가장 효율적이다. 잠금 단위의 최소 단위에 대해 잠금을 획득하기 위해서는 최소 단위보다 상위 단위인 객체에 대해서도 잠금을 획득해야 하며 이를 잠금 단위 규약(granularity protocol)이라 한다. 상위 단위의 객체에 대해 잠금을 획득할 경우에는 잠금 모드를 다양하게 주어 어떤 트랜잭션이 그 테이블에 대해 연산을 수행하고 있다 하더라도 동일한 레코드에 대해서 연산을 하지 않는 다른 트랜잭션도 그 테이블에 대해 연산을 수행할 수 있게 하는 것이 바람직하다. 이를 위하여 사용되는 것이 의사 모드 잠금이다. 알티베이스에서 지원되는 잠금 단위는 테이블과 레코드이다. 잠금 호환성(Lock Compatibility) 잠금 호환성이란 이미 다른 트랜잭션이 해당 객체에 대해 잠금을 획득하고 있을 때 한 트랜잭션이 그 객체에 대해 특정 모드의 잠금을 요구하게 되는 경우 그 요구가 받아들여질 수 있는지의 여부를 결정하기 위해 사용되는 잠금 모드 간의 호환성을 의미한다. 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 - - - - - - [표 7-2] 잠금 모드간의 호환성 레코드 레벨 잠금 모드(Record Level Lock Modes) DML 연산 중 삽입, 삭제, 갱신 구문은 레코드에 대한 X 잠금을 잡게 되고, 검색 연산은 S 잠금을 잡게 된다. Lock Mode 설명 기능 S Shred Lock 레코드에 대해 검색만을 수행할 수 있다. 트랜잭션 관리 393 X Exclusive Lock 레코드에 대해 수정을 할 수 있다. [표 7-3] 레코드 레벨의 잠금 모드 일반적으로 레코드에 대한 S 잠금과 X 잠금은 서로 충돌하여 호환되지 않는다. 하지만 알티베이스의 경우는 다중 버전 동시성 제어 기법을 사용하기 때문에 서로 충돌하지 않는다. 따라서 갱신 중인 레코드에 대한 검색과 검색중인 레코드에 대한 갱신이 모두 허용된다. 394 ALTIBASE5 Administrator’s Manual 다중 버전 동시성 제어 기법 알티베이스는 동시성 제어를 위해 다중 버전 동시성 제어 (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 를 사용할 때 주의해야 할 사항들에 대해 설명한다. MVC 기법을 사용하지 않는 경우의 갱신 연산 MVCC 기법을 사용하는 경우와의 비교를 위해 MVCC 기법을 사용하지 않는 경우에 갱신 구문이 내부적으로 수행되는 방법에 대해 설명한다. 다음 그림은 MVCC 기법을 사용하지 않는 경우, 즉 갱신 연산이 발생하는 경우에 한 테이블의 레코드가 어떻게 변하는지를 나타낸다. 트랜잭션 관리 395 record A col1 = 1 Table T1 col1=1 -> col1=2 record A Table T1 (a) recordA의 col1의 초기 insert 상태 (b) recordA의 col1의 값을 2로 update [그림 7-1] MVCC 미 사용시의 트랜잭션 처리 위 그림의 (a)는 테이블 T1 에 레코드 A 가 최초로 삽입된 경우를 나타낸다. 이 레코드 A 에 대해 col1 의 값을 2 로 수정한 경우 위 그림의 (b)에서와 같이 레코드 A 의 원래 위치에 대해 수정이 됨으로써 T1 에 할당된 공간에 대해서는 변화가 없다. 삭제 구문의 경우도 갱신 구문과 마찬가지로 원래 레코드에 대해 삭제 연산이 수행된다. 위 그림과 같이 MVCC 기법을 사용하지 않는 경우에는 갱신/삭제에 의해 테이블에 할당된 공간이 늘어나지 않으며 한 테이블에 할당된 공간이 늘어날 수 있는 경우는 오직 삽입 구문에 의한 경우뿐이다. 메모리 테이블스페이스의 MVCC 알티베이스의 메모리 테이블스페이스에서 사용되는 Out-place MVCC 는 갱신 연산이 발생 할 때마다 새로운 버전(version)을 생성하고 이전 버전과 연결 시킴으로써 구현된다. 갱신(Update) 연산 다음 그림은 Out-place MVCC 기법을 사용하는 경우 갱신 구문의 수행 효과를 나타낸다. 그림의 (a)에서와 같이 테이블 T1 에 레코드 A 가 삽입된 상태에서 레코드 A 의 col1 의 값을 2 로 갱신하는 경우 (b)에서와 같이 갱신을 위해 동일한 레코드를 하나 생성한 후 그 레코드에 대해 값을 2 로 변경한다. 따라서, 테이블 T1 의 공간은 갱신 전의 상태와 비교하여 하나의 슬롯(slot)을 더 차지하게 된다. 396 ALTIBASE5 Administrator’s Manual 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 [그림 7-2] MVCC 사용시의 트랜잭션 처리 레코드 A 에 대해 하나의 버전이 추가로 생성되면 원래의 레코드 A 는 추가된 레코드가 무엇인지를 나타내기 위해 레코드 헤더에 하나의 포인터를 이용하여 새로 추가된 레코드를 가리키게 된다. 이렇게 함으로써 동일한 레코드에 대한 버전들을 관리할 수 있다. 위 그림의 (b) 상태에서 다시 레코드 A 에 대한 갱신 연산이 수행되면 위에서 설명한 바와 같이 추가로 하나의 레코드를 생성하여 그 레코드에 대해 갱신을 수행하게 된다. 그 결과 하나의 동일한 레코드에 대해 여러 번의 갱신 연산이 수행되면 갱신된 횟수만큼 동일한 레코드에 버전이 생기게 된다. 그렇다면 갱신 연산 수행 횟수만큼 테이블 공간은 무한정 커지는가? 동일한 레코드에 대하여 생긴 여러 개의 버전들은 갱신 연산을 수행한 각 트랜잭션이 커밋하게 되면 최근에 생긴 버전만 유효하며 이전 버전들은 데이터베이스에 저장되어 있을 필요가 없다. 이러한 불필요한 버전들은 가비지 콜렉터에 의해 알티베이스 운용 중에 삭제가 되며 삭제된 레코드들이 차지하고 있던 테이블 내의 공간들은 이후 발생하는 삽입/갱신 문에 의해 다시 재사용된다. 따라서, 갱신 연산이 일어난 횟수만큼 새로운 버전들이 생긴다 하더라도 데이터베이스 공간이 무한정 커지지는 않는다. 삭제 (Delete) 연산 삭제 연산도 갱신 연산과 마찬가지로 각 레코드에 대해 삭제 연산이 수행되면 하나의 새로운 버전이 생긴다. 삭제 연산의 경우 갱신 연산과 달리 삭제할 레코드에 대한 새로운 버전은 실제 아무런 데이터도 갖고 있지 않다. 따라서, 삭제 연산에 대한 버전은 각 레코드 별로 하나씩 생성할 수도 있고, 그렇게 하지 않는다 하더라도 데이터베이스 내의 데이터에는 아무런 영향을 미치지 않는다. 트랜잭션 관리 397 다음 그림은 삭제 연산 수행 시 각 레코드 별로 버전을 생성하는 경우와 그렇지 않은 경우에 대해 테이블 내의 공간 활용도를 보여준다. (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 [그림 7-3] MVCC 사용시의 삭제 트랜잭션 위 그림의 (a)는 각 레코드 별로 하나의 버전을 생성하는 경우이다. 한 트랜잭션이 하나의 삭제 구문을 이용하여 레코드 A, B 를 삭제하는 경우 두 레코드에 대해 각각의 버전을 생성하므로 테이블 T1 은 추가로 두 개의 레코드가 생성되었다. 위 그림의 (b)는 하나의 삭제 구문에 의해 여러 개의 레코드가 삭제되더라도 하나의 삭제 구문에 대해서는 하나의 버전만을 생성하는 경우이다. 위 그림에서 보여지는 것처럼 (b)의 경우가 불필요한 레코드 버전을 적게 만들기 때문에 공간 활용도가 훨씬 높다. 알티베이스는 위 398 ALTIBASE5 Administrator’s Manual 그림의 (b)와 같은 방법대로 메모리 테이블스페이스에 대해 삭제 연산을 수행한다. 디스크 테이블스페이스의 MVCC 알티베이스의 디스크 테이블스페이스에서 사용되는 In-place MVCC 는 갱신 연산이 발생 할 때, 기존의 레코드에서 변경되는 칼럼들을 언두 테이블스페이스에 존재하는 언두 페이지에 언두 로그 레코드라는 이름으로 기록하고, 변경 이후 값들을 기존 레코드의 해당 위치에 복사한다. 삽입 연산 최초로 레코드가 삽입되면 데이터 테이블스페이스에 레코드를 위한 영역을 할당 받아 레코드를 만들고, 다시 언두 테이블스페이스에서 삽입에 대한 언두 로그 레코드를 위한 영역을 할당받아서 로그 레코드를 작성한 후, 데이터 테이블스페이스의 실제 레코드에 있는 롤백 RID 에 이 언두 로그 레코드의 위치를 기록하여 연결을 시킨다. 갱신 연산 최초로 삽입된 레코드인 버전 1 이 있다고 가정하자. 이 버전이 갱신되어 버전 2 가 되고, 다시 한번 갱신되어 현재 버전 3 이 되었을 경우의 상황은 다음 그림과 같이 된다. 버전 3롤백 RID 데이터 테이블 스페이스언두 테이블 스페이스 이전 이미지2롤백 RID 이전 이미지1롤백 RID 버전 2 버전 1 버전 3이전 이미지2 = = + 버전 2 +이전 이미지1 [그림 7-4] 디스크 테이블스페이스의 MVCC 위의 그림과 같이 데이터 테이블스페이스에는 항상 최신의 레코드 이미지가 존재한다. 만일 어떤 문장이 버전 3 이 커밋되기 전에 시작되었다면 버전 3 을 읽을 수 없으므로, 더 이전의 이미지인 버전 2 를 읽어 가야 한다. 이럴 경우에는, 해당 문장은 버전 3 의 이미지를 자신의 특정 버퍼에 복사한 후, 그 레코드의 롤백 RID 가 가리키는 곳에 존재하는 이전 이미지 2 를 읽어다 버전 3 를 복사해 트랜잭션 관리 399 둔 곳에 반영하게 된다. 만일 이 버전 2 마저도 자신이 읽을 수 없는 버전이라면, 다시 같은 작업으로 이전 이미지 1 을 반영시켜 버전 1 을 만들어 내게 된다. 만일 버전 1 도 읽지 못한다면 이는 해당 문장이 레코드의 최초 삽입연산이 커밋되기 전에 시작된 것이므로 이 레코드를 없는 것으로 가정하고 무시하게 된다. 언두 로그 레코드 영역의 해제 디스크 테이블스페이스의 경우, 단시간에 다량의 갱신연산이 발생하면 데이터 테이블스페이스의 크기는 별 차이가 없지만, In- place MVCC 의 영향으로 언두 로그 레코드의 양이 많아져서 언두 테이블스페이스의 크기가 증가하게 된다. 언두 테이블스페이스의 크기는 최초 CREATE DATABASE 시에 프로퍼티로 정의되어 변경되지 않으므로 언두 로그 레코드는 재사용이 가능하여야 한다. 언두 로그 레코드는 트랜잭션이 커밋될 당시에 언두 테이블스페이스 헤더에 등록되어 연결 리스트(linked list)로 관리되어 있다가, 현재 시스템 내의 모든 트랜잭션이 해당 언두 로그 레코드를 참조할 필요가 없어지게 되면 바로 해제가 된다. 반면 트랜잭션이 롤백이 되면 언두 로그 레코드들은 언두 테이블스페이스에 등록되지 않고 바로 해제가 된다. 언두 로그 레코드들 중 삽입 연산에 의한 언두 로그 레코드들은 갱신 및 삭제 로그 레코드들과 따로 관리 되는데, 이유는 삽입 연산에 의한 언두 로그 레코드들을 트랜잭션 커밋 시점에 바로 해제할 수 있게 하기 위해서 이다. 삭제 연산 삭제 연산도 갱신 연산과 동일한 방식으로 수행된다. 단, 삭제 연산에 의해 변경되는 정보는 레코드의 헤더에 삭제 플래그(delete flag)가 설정되는 것이므로, 언두 로그 레코드의 이전 이미지에는 레코드의 헤더 정보만 기록된다. 삭제된 레코드는 바로 재사용되지 않고, 가비지 콜렉터가 해당 레코드에 대한 삭제 언두 로그 레코드를 삭제하기 전에, 해당 레코드에 대한 모든 인덱스의 키들을 삭제하고 실제 레코드를 삭제함으로써 다시 재사용이 가능하게 된다. In-place MVCC vs. Out-place MVCC 디스크 테이블스페이스에서의 In-place 방식은 메모리 테이블스페이스의 Out-place 와는 다른 버전 검사 방법을 사용한다. Out-place 방식은 각 버전마다 버전을 생성했던 트랜잭션의 400 ALTIBASE5 Administrator’s Manual Commit SCN 을 저장하고, 이를 이용하여 버전을 검사한다. 즉, 검색 트랜잭션은 자신의 SCN 보다 작은 Commit SCN 을 갖는 버전을 읽어 간다. 트랜잭션의 Commit SCN 은 트랜잭션 커밋시에 설정되며, 해당 트랜잭션이 생성한 모든 버전에 반영된다. 그러나 디스크 테이블스페이스에서의 트랜잭션은 Commit SCN 을 설정하기 위하여 자신이 생성한 모든 버전에 접근하는 것은 현실적으로 불가능하다. 왜냐하면, 디스크 입출력 비용으로 인하여 트랜잭션 성능이 심각하게 저하되기 때문이다. 따라서, 디스크 테이블스페이스를 위한 독특한 Commit SCN 검사 방법이 필요하며, 알티베이스에서는 TSS 를 이용하여 이를 해결한다. TSS(Transaction Status Slot) 는 트랜잭션의 현재 상태를 표현하고 있는 일종의 레코드를 의미하며, 해당 TSS 에 Commit SCN 이 기록된다. 이러한 TSS 는 Undo 테이블스페이스에 영구적으로 기록되며, 더이상 사용되지 않는 불필요한 경우, Ager 에 의해 삭제되고 삭제된 TSS 는 새로운 트랜잭션에 의해서 재활용된다. 커밋하는 트랜잭션은 자신이 생성한 모든 버전에 Commit SCN 을 설정하지 않으며 자신과 관련된 TSS 의 Commit SCN 만을 설정한다. 또한 레코드 갱신 연산시 TSS 식별자가 해당 레코드에 기록되며, 기록된 TSS 식별자는 버전 검사를 하는 트랜잭션에 의해서 이용된다. 즉, 레코드의 TSS 가 갖는 Commit SCN 과 자신의 SCN 과의 비교를 통해서 검사하며, 자신의 SCN 보다 작은 Commit SCN 을 갖는 레코드만을 읽어간다. MVC 사용 시 주의사항 알티베이스는 메모리와 디스크 테이블스페이스 모두를 MVCC 방식으로 동시성 제어 한다. MVCC 는 기존의 전통적인 SVCC(Single Version Concurrency Control)과 달라서, 아래와 같이 주의하여야 할 점들이 몇 가지 있다. 장시간 수행되는 트랜잭션에 의한 데이터베이스 크기 증가 특정 트랜잭션이 너무 오랫동안 커밋하지 않고 수행되고 있으면, 이 트랜잭션이 이전 이미지들을 읽을 가능성이 있기 때문에 가비지 콜렉터가 다른 트랜잭션들이 작성한 이전 이미지 정보들(메모리 테이블은 이전 버전, 디스크 테이블은 언두 로그 레코드 정보)과 해당 레코드의 인덱스 키들을 삭제할 수 없게 된다. 이에 따라 메모리 테이블의 크기가 증가되고, 디스크의 언두 테이블스페이스 크기가 증가하게 된다. 또한, 해당 트랜잭션이 롤백할 때를 대비해서 로그 파일도 삭제하지 못하므로, 로그 파일이 존재하는 파일 시스템이 꽉 찰 가능성이 있다. 트랜잭션 관리 401 동시 수행 트랜잭션 과다로 인한 데이터베이스 크기 증가 알티베이스는 MVCC 로 인해 생성된 이전 이미지 정보들의 해제를 가비지 콜렉터에게 맡기고 있다. 만일 동시에 수행되는 트랜잭션의 수가 해당 시스템의 CPU 개수 보다 현저히 많을 경우에는 가비지 콜렉터가 이전 이미지 정보들을 삭제할 여유를 가지지 못해 데이터베이스 크기가 계속 늘어날 수 있다. 대량의 갱신 연산으로 인한 데이터베이스의 크기 증가 한번에 대량의 이전 정보를 생성해야 하는 연산(bulk update)들이 자주 사용되면, 메모리 테이블은 그 크기가 커지며, 디스크 테이블은 언두 테이블스페이스가 커질 수 있다. 이전 이미지 정보 과다로 인한 성능 저하 위에 열거한 내용들로 인하여 이전 이미지 정보가 데이터베이스 내에 너무 많이 남아있으면 실제로 목적하는 레코드를 찾는데 더 많은 비용이 들어 갈 수 있어서 전체적으로 성능이 느려질 소지가 있다. Repeatable Read Vs. Consistent Read 일반적인 SVCC DBMS 들은 레코드를 읽었을 때 S 잠금이 잡히게 되므로 X 잠금과 충돌하여 읽는 동안 레코드가 변하지 않으므로, 데이터베이스의 격리도(Isolation Level)가 보통 Repeatable Read 로 동작한다. 반면 알티베이스는 검색 연산이 수행 중에도 동일 레코드에 대해 갱신 연산이 가능하여 Consistent Read 가 기본적인 격리도가 된다. 따라서, 한 트랜잭션이 커밋하지 않고 같은 테이블을 여러 번 검색하면 서로 다른 결과 집합을 보여 줄 수도 있다. 만일 이를 방지하려 한다면 격리도를 Repeatable Read 로 변경시키고 연산을 수행하거나, SELECT FOR UPDATE 구문을 사용하여 수행하여야 한다. 402 ALTIBASE5 Administrator’s Manual 트랜잭션의 영속성 일반적으로 트랜잭션이란 저장 객체(페이지 또는 레코드, DBMS 마다 구현이 차이가 있음)에 대한 일련의 판독과 갱신 작업의 독립된 작업 단위를 의미한다. 데이터베이스 관리 시스템은 성능향상을 위해서 여러 트랜잭션이 동시에 인터리빙(interleaving)해서 수행되도록 지원하고 있으며, 여러 트랜잭션이 어떤 순서로 수행되더라도 그 결과는 차례대로 하나씩 수행한 결과와 동일하도록 동시성 제어(concurrency control)를 해주고 있다. 따라서 예측하지 못한 모든 시스템 장애 상황에서도 모든 데이터를 정확하게 관리(crash recovery)하기 위해 다음과 같은 트랜잭션의 4 가지 속성을 보장하도록 설계되어 있다. y 원자성 (atomic) y 일관성 (consistency) y 격리성 (isolation) y 영속성 (durability) 영속성의 개념 트랜잭션의 4 가지 속성 중 영속성(durability)은 DBMS 가 사용자에게 트랜잭션 커밋(commit) 응답을 요청했을 경우, 데이터베이스 객체에 대한 해당 변경 사항이 디스크에 반영(flush)되기 전에 시스템 장애가 발생하였더라도 해당 트랜잭션의 커밋은 보장되어야 한다는 속성이다. 데이터베이스 관리 시스템은 트랜잭션의 영속성을 제공하기 위해 로그(log) 즉, 데이터베이스 객체의 갱신 작업에 대한 기록을 관리한다. 커밋된 트랜잭션에 의해 갱신된 내용이 디스크에 반영되기 전에 시스템 장애가 발생하면, 시스템 재구동시에 로그를 판독하여 변경된 내용을 복구하게 되는 것이다. 트랜잭션의 영속성은 트랜잭션의 처리 성능과 밀접한 관련이 있는 중요한 요소이다. 디스크 기반 DBMS 에 비해 성능이 수십배 더 좋은 메모리 기반 DBMS 에서 영속성을 보장하는 것은 디스크 기반 DBMS 에 비해 성능에 미치는 영향이 훨씬 크다. 예를 들어, DBMS 가 완벽한 트랜잭션 영속성을 위해서는 모든 데이터베이스 갱신에 대한 로그 기록을 빠짐없이 디스크의 로그파일에 반영해야 한다. 메모리 로그 버퍼에 존재하는 모든 로그들을 로그파일에 반영할 때는 디스크 I/O 가 발생하게 되며, 이 때 발생하는 디스크 I/O 는 트랜잭션 처리의 병목(bottleneck)으로 트랜잭션 관리 403 작용하게 되어 트랜잭션 처리 성능 저하의 원인으로 작용한다. 즉, 완벽한 트랜잭션 영속성과 트랜잭션 처리 성능 관계는 안정성과 성능이라는 상반되는 목표를 가지는 상충(tradeoff) 관계에 있다고 볼 수 있다. 알티베이스는 트랜잭션의 영속성을 완벽하게 보장하고 있으며, 여러 시스템 상황에 따라서 고성능의 트랜잭션 처리를 제공하기 위해 트랜잭션 처리 성능과 트랜잭션 영속성의 균형을 조절할 수 있도록 트랜잭션 영속성 관리 방법을 지원한다. 트랜잭션 영속성 관리 방법 알티베이스는 트랜잭션의 영속성(durability) 설정을 altibase.properties 파일의 [COMMIT_WRITE_WAIT_MODE] 프로퍼티와 [LOG_BUFFER_TYPE] 프로퍼티로 관리하고 있다. COMMIT_WRITE_WAIT_MODE 는 변경 로그가 디스크 로그 파일에 반영이 완료될 때까지 트랜잭션이 대기할 것인지를 설정한다. LOG_BUFFER_TYPE 는 변경 로그가 로그 파일에 기록될 때 사용할 로그 버퍼의 타입을 설정한다. 이 프로퍼티는 시스템 운영 중에 변경할 수 없다. 프로퍼티에 대한 보다 자세한 설명은 Starting User’s Manual 을 참조하기 바란다. 반영 완료시까지 대기하지 않음, 커널 로그 버퍼 사용 In OS Kernel memory In Altibase process logfile sync threads logfiles log buffer sync txtx [그림 7-5] 반영 완료시까지 대기하지 않음, 커널 로그 버퍼 사용 COMMIT_WRITE_WAIT_MODE, LOG_BUFFER_TYPE 를 (0, 0)으로 설정한다. 영속성 프로퍼티의 기본값으로 운영체제 커널 영역의 로그 버퍼를 사용하여 변경 로그를 기록하며 변경 로그가 로그 파일에 반영될 때까지 트랜잭션이 대기하지는 않는다. 404 ALTIBASE5 Administrator’s Manual 반영 완료시까지 대기하지 않음, 메모리 로그버퍼 사용 [그림 7-6] 반영 완료시까지 대기하지 않음, 메모리 로그버퍼 사용 COMMIT_WRITE_WAIT_MODE, LOG_BUFFER_TYPE 를 (0, 1)로 설정한다. 트랜잭션은 변경 로그를 메모리 로그 버퍼에 기록하고 sync 쓰레드가 자체적으로 로그 버퍼에 있는 로그를 로그 파일에 플러시하는 방식이다. 반영 완료시까지 대기, 커널 로그 버퍼 사용 [그림 7-7] 반영 완료시까지 대기, 커널 로그 버퍼 사용 COMMIT_WRITE_WAIT_MODE, LOG_BUFFER_TYPE 를 (1, 0)으로 설정한다. 트랜잭션이 변경 로그를 운영체제 커널의 로그 버퍼에 기록하고 직접 커밋 로그를 로그 파일까지 반영하는 방식이다. 트랜잭션 관리 405 반영 완료시까지 대기, 메모리 로그 버퍼 사용 [그림 7-8] 반영 완료시까지 대기, 메모리 로그 버퍼 사용 COMMIT_WRITE_WAIT_MODE, LOG_BUFFER_TYPE 를 (1, 1)로 설정한다. 트랜잭션이 변경 로그를 메모리의 로그버퍼에 기록하고 앞의 경우와 마찬가지로 직접 커밋 로그를 로그 파일까지 반영하는 방식이다. 버퍼 관리자 407 8. 버퍼 관리자 알티베이스 디스크 테이블스페이스의 데이터 객체가 접근 또는 갱신되기 위해서는 디스크로부터 메모리에 적재되어야 한다. 이렇게 임시로 사용되는 메모리를 버퍼라고 하며, 알티베이스는 버퍼 풀이라고 한다. 디스크의 모든 데이터를 버퍼 풀에 쌓아두면 어떤 데이터에 대한 접근이라도 I/O 없이 빠르게 수행된다. 하지만 한정된 메모리는 디스크 데이터의 일부만 버퍼 풀에 적재할 수 있다. 버퍼 풀에 적재된 데이터는 다른 데이터에 의해 제거되는데, 이를 데이터 교체라고 한다. 이 때 어떤 데이터를 버퍼에 오래 둘 것인가는 시스템 성능에 중요한 영향을 주기 때문에 효율적인 알고리즘을 사용해야 한다. 알티베이스는 버퍼 풀을 관리하는 주체를 버퍼 관리자(Buffer Manager)라고 한다. 버퍼 관리자의 주된 역할은 자주 접근되는 데이터를 보다 버퍼에 오래 두어 효율적으로 버퍼를 관리하는 것 있다. 이 장에서는 버퍼 관리자의 구조와 기능, 버퍼 풀 관리 및 관련 프로퍼티 등에 대해 설명한다. 408 ALTIBASE5 Administrator’s Manual 버퍼 관리자의 구조 버퍼 관리자 구성요소 버퍼 관리자의 구성요소는 버퍼 영역, 버퍼 풀, 버퍼 프레임, BCB(Buffer Control Block)가 있다. 버퍼 풀은 버퍼를 효율적으로 관리하기 위해 LRU 리스트, 프리페어 리스트, 플러시 리스트, 체크포인트 리스트, 해시 테이블을 가진다. 이 절에서는 이들 구성요소에 대해 설명한다. 버퍼 영역 (Buffer Area) 버퍼 풀이 버퍼 공간을 할당하는 영역이다. 버퍼 풀이 버퍼를 효율적으로 관리하는 주체라면, 버퍼 영역은 버퍼를 할당하고 버퍼 풀에게 자원을 제공해주는 수동적인 역할을 한다. 버퍼 관리자가 사용하는 버퍼 크기는 버퍼 영역의 크기에 따른다. 버퍼 풀 (Buffer Pool) 버퍼 관리자의 핵심 요소로, 버퍼를 교체하는 정책을 구현한다. 요청된 데이터 페이지를 버퍼에 적재하고 적재된 페이지 영역의 메모리 주소를 반환한다. 버퍼 풀은 내부적으로 해시 테이블과 LRU 리스트, 프리페어 리스트, 플러시 리스트들로 BCB 들을 관리한다. 버퍼 프레임(Buffer Frame) 메모리에 하나의 페이지를 적재할 수 있도록 확보한 공간으로, 하나의 버퍼 프레임은 하나의 페이지 크기와 같다. 버퍼 프레임이 모여서 버퍼 풀을 구성한다. BCB(Buffer Control Block) BCB 는 버퍼 프레임에 대한 정보를 갖으며, 하나의 BCB 는 하나의 버퍼 프레임에 대응된다. 버퍼 관리자에서 모든 버퍼에 적재된 페이지는 BCB 로 관리되며, 버퍼 프레임은 단지 페이지를 메모리에 적재할 수 있는 공간이다. BCB 는 대응하는 버퍼 프레임에 대한 주소를 유지한다. 다음의 그림과 표는 BCB 의 구조와 정보를 설명한다. 버퍼 관리자 409 [그림 8-1] BCB 구조 속성 설명 상태 BCB의 현재 상태를 나타내며, FREE, CLEAN, DIRTY가 있다. FREE : 버퍼에 페이지가 적재되지 않은 상태 CLEAN : 버퍼에 페이지가 적재되었지만 갱신되 지 않은 상태 DIRTY : 버퍼의 페이지가 갱신되었으나 디스크에 는 반영되지 않은 상태 버퍼 프레임 주 소 하나의 BCB에 해당하는 버퍼 프레임의 주소 테이블스페이스 식별자 페이지가 속한 테이블스페이스의 식별자 페이지 식별자 테이블스페이스에서 페이지들이 갖는 고유 번호 페이지를 소유 하는 자의 록 (Lock) 페이지에 접근하기 위해서는 우선 록을 획득해야 한다. 접근 모드는 Read, Write, Fix로 얻을 수 있다. BCB의 록이 특정 모드를 획득하면, 버퍼에 올라온 페이지에 해당 모드로 접근할 수 있다. 수정 LSN 버퍼에서 수정된 시점의 LSN(Log Sequence Number)이다. 이 값은 버퍼에 올라온 페이지가 플러시될 때 어느 시점의 로그까지 플러시할 것인 지 나타낸다. Fix 개수 페이지를 동시에 공유하고 있는 트랜잭션 개수이 다. 이 값이 1 이상이면 페이지를 교체할 수 없으 며, 0이면 교체가 가능하다. 접근 회수 (Touch Count) 페이지가 버퍼에 적재된 후 트랜잭션들이 접근한 회수이다. 이 값으로 버퍼의 hot, cold 유무를 판 단한다. [표 8-1] BCB 정보 410 ALTIBASE5 Administrator’s Manual 해시 테이블 알티베이스 서버는 페이지에 대한 요청이 들어오면 해시 테이블을 검색하여 해당 페이지가 버퍼에 적재되었는지 확인한다. 해시 테이블에는 버퍼에 적재된 각 페이지에 대한 BCB 가 등록되어 있다. LRU(Least Recently Used) List 접근한지 오래된 버퍼를 우선 교체 대상으로 선정하기 위해 사용한다. 알티베이스는 LRU 리스트를 hot-cold 영역으로 나누어 관리하고 있어 hot-cold LRU List 라고도 한다. 접근 빈도가 높은 버퍼들은 hot 영역에 넣고, 그렇지 않은 버퍼들을 cold 영역에 넣어 교체 대상 검색시 cold 영역만 확인하기 때문에 hot 버퍼들을 교체 대상에서 제외된다. 버퍼에 처음 페이지가 적재되면 mid point(LRU cold first)에 삽입된다. 이 때 새로운 데이터 페이지에 버퍼를 할당하는데 빈 버퍼가 없으면 이 리스트의 LRU-end(LRU cold last)부터 검색하여 교체한다. 버퍼 교체가 발생하면 교체 대상 버퍼인 victim 이 발생한다. [그림 8-2] hot-cold LRU list 검색하는 도중에 접근 빈도가 높은 버퍼는 hot 영역인 LRU hot first 로 옮겨진다. 또한 페이지가 갱신되었지만 디스크에 플러시되지 않은 dirty 버퍼는 Flush 리스트로 옮겨진다. 그리고 버퍼에 페이지가 올라왔지만 갱신되지 않은 clean 버퍼가 hot 영역이 아니면 교체 대상 버퍼로 선정된다. hot 영역의 비중은 HOT_LIST_PCT 에서 조정이 가능하다. 기본값은 50 이며, LRU 리스트의 절반을 hot 영역으로 사용한다는 의미이다. Flush List LRU 리스트에서 교체 대상을 검색할 때 dirty 버퍼가 나타나면 플러시 리스트로 옮겨진다. 플러시 리스트는 페이지가 갱신되었지만 디스크에는 아직 반영되지 않은 버퍼들이 모여있는 리스트이다. 그러나 모든 dirty 버퍼가 플러시 리스트에 있는 것은 아니다. 갱신된 시점에 플러시 리스트로 옮겨지는 것이 아니라 LRU 리스트에서 교체 대상을 검색하는 과정에서 플러시 리스트로 버퍼 관리자 411 옮겨지기 때문이다. 이 리스트는 교체 플러시(replacement flush)가 발생하면 갱신된 페이지를 디스크에 반영하고, clean 버퍼를 확보한다. Prepare List 플러시 리스트에서 디스크로 반영이 된 버퍼들은 모두 Prepare 리스트로 옮겨진다. 즉 Prepare 리스트는 플러시 작업을 마친 clean 버퍼들로 구성된 리스트이다. 버퍼 관리자는 교체 대상 버퍼를 찾을 때 우선 Prepare 리스트를 검색한다. 만약 Prepare 리스트에서 교체 대상 버퍼를 찾을수 없다면 LRU 리스트를 찾아본다. 그러나 버퍼가 Prepare 리스트에 있어도 갱신이 가능하기 때문에 항상 clean 상태인 것은 아니다. Checkpoint List LRU 리스트, 플러시 리스트, Prepare 리스트는 상호 배타적인 리스트이기 때문에 한 개의 버퍼는 두 개 이상의 리스트에 존재할 수 없다. 그러나 체크포인트 리스트는 세가지 리스트와 달리 독립적으로 관리가 가능하기 때문에 세가지 리스트에 존재하는 버퍼가 체크포인트 리스트에 속할수 있다. dirty 버퍼 즉 갱신된 버퍼들은 체크포인트 리스트에 존재하게 되며, 체크포인트 리스트의 모든 버퍼는 dirty 상태이다. 이 리스트는 버퍼가 처음에 갱신된 시점을 기준으로 LSN 을 부여하며, 정렬 관리한다. 체크포인트 리스트는 체크포인트 플러시 작업을 할 때 체크포인트 리스트의 LSN 이 작은 버퍼부터 플러시를 수행한다. [그림 8-3]은 LRU 리스트, 플러시 리스트, Prepare 리스트의 모든 버퍼들이 해시 테이블을 통해 접근이 가능한 것을 나타낸다. [그림 8-3] 버퍼 풀(Buffer Pool) List 다중화 LRU 리스트, 플러시 리스트, Prepare 리스트, 체크포인트 리스트는 각각의 리스트에 대해 다중화가 가능하다. 리스트 다중화를 통해 412 ALTIBASE5 Administrator’s Manual 다수의 데이터베이스 클라이언트가 동시에 서비스를 요청하여 리스트 록(LOCK) 경합이 발생하는 것을 방지한다. 각 리스트의 개수는 V$BUFFPOOL_STAT 의 LRU_LIST_COUNT, PREPARE_LIST_ COUNT, FLUSH_LIST_COUNT, CHECKPOINT_LIST_ COUNT 에서 설정할 수 있다. 그러나 서버가 운영중일 경우에는 변경이 불가하다. BCB 상태 변화 BCB 의 상태는 FREE, CREAN, DIRTY 3 가지 중에서 하나의 상태로 존재한다. FREE 버퍼에 어떤 페이지도 적재되지 않은 상태이다. 시스템이 처음 구동되면 대부분의 버퍼들이 free 상태가 된다. 또한 테이블스페이스가 drop 되거나 오프라인(offline)이 되면 해당 테이블스페이스에 속한 페이지의 버퍼들은 모두 free 로 된다. CLEAN 버퍼에 페이지가 적재되어 있지만 아직 갱신되지 않은 상태이다. 버퍼의 페이지 내용이 디스크의 페이지 내용과 동일한 상태이다. 해시 테이블로 접근할 수 있으며 LRU 리스트, 플러시 리스트, Prepare 리스트 중 하나에 있으나, 체크포인트 리스트에는 있을 수 없다. DIRTY 버퍼에 있는 페이지가 갱신은 되었으나, 디스크에는 반영되지 않은 상태이다. DIRTY 버퍼는 체크포인트 리스트에도 포함되며, LRU 리스트, 플러시 리스트, Prepare 리스트 중 하나에도 속한다. 플러시에 의해 CLEAN 상태로 변경된다. 플러셔 (Flusher) 플러셔(Flusher)는 교체할 모든 버퍼를 디스크에 반영하는 플러시(flush)를 수행한다. 알티베이스에서 제공하는 플러시는 교체 플러시(Replacement Flush)와 체크포인트 플러시(Checkpoint Flush)가 있다. y 교체 플러시(Replacement Flush) 버퍼 교체를 위해 갱신된 버퍼가 접근된지 오래된 것을 플러시 버퍼 관리자 413 y 체크포인트 플러시(Checkpoint Flush) 체크포인트 시간을 줄이기 위해 처음 갱신한 시점이 오래된 버퍼를 대상으로 플러시 교체 플러시는 주기적으로 발생하거나 교체 대상 버퍼를 찾지 못했을 때 강제적으로 수행한다. 체크포인트 플러시 역시 주기적으로 발생할 수 있으나 사용자가 ALTER SYSTEM CHECKPOINT 명령으로 수행할 수 있다. 플러셔는 교체 플러시를 먼저 수행한 후 해당 작업이 없을 때에만 주기적으로 체크포인트 플러시를 수행한다. 즉 플러셔는 일정 시간을 대기한 후 교체 플러시를 할 버퍼가 있으면 디스크에 반영한다. 플러셔는 DEFAULT_FLUSHER_WAIT_SEC 이상 MAX_FLUSHER_WAIT_SEC 미만의 시간을 대기한다. 교체 플러시 이후 다시 일정 시간을 대기하여 교체 플러시할 대상이 없으면 체크포인트 플러시의 작업 여부를 판단하여 플러시를 하거나 다시 대기한다. 체크포인트 플러시 작업을 위한 조건은 다음과 같다. y 마지막으로 플러셔가 플러시한 후 CHECKPOINT_FLUSH_MAX_WAIT_SEC이 지났을 때 y 시스템 재구동시 복구해야 하는 페이지들에 대한 로그 수가 일정 개수를 넘어설 때. 즉 플러시되지 않은 페이지들이 갖는 갱신 LSN 중에서 가장 작은 LSN이 CHECKPOINT_FLUSH_MAX_GAP 만큼 벌어졌을 때 그러나 플러셔가 오랜 시간을 대기하도록 설정되었다고 하더라도, 트랜잭션이 자주 발생하여 교체할 버퍼가 많이 발생하면 강제적인 플러셔도 가능하다. 플러셔가 교체 플러시와 체크포인트 플러시를 얼마나 수행할 것인지는 REPLACE_FLUSH_COUNT 와 CHECKPOINT_FLUSH_COUNT 로 조정할 수 있다. 또한 플러셔는 BUFFER_FLUSHER_CNT 를 조정하여 다수의 플러셔를 둘 수 있다. 그러나 서버 운영중에는 변경할 수 없다. 각각의 플러셔는 ALTER SYSTEM START/STOP FLUSHER 구문으로 구동 또는 정지시킬 수 있다. SQL 에 대한 자세한 내용은 SQL User’s Manual 을 참조하기 바란다. 414 ALTIBASE5 Administrator’s Manual 버퍼 관리 접근 모드(Lock 모드) 페이지에 접근하기 위해서는 우선 록(Lock)을 획득해야 한다. 접근 모드는 페이지에 대한 접근을 어떤 권한으로 허가해 줄 것인가에 따라 구분한다. 접근 모드는 다음과 같이 Read, Write, Fix 로 구분된다. 접근 모드 설명 Read(읽기) 버퍼에 올라온 페이지를 읽기 위해 접근한다. 여러 개의 트랜잭션이 동시에 접근할 수 있다. Write(쓰기) 버퍼에 올라온 페이지를 쓰기 위해 접근한다. 쓰기 모드는 한 시점에 하나의 트랜잭션만 페이지 접근이 가능하다. Fix 버퍼에 페이지를 올린 후, 버퍼 관리자에 의해 교 체되지 않는다. Fix 모드로 트랜잭션이 페이지를 접근하여 데이터 를 읽으면 그 데이터는 정확한 데이터임을 보장할 수 없다. 정확한 데이터를 읽기 위해서는 읽기 (Read) 모드로 접근해야 한다. [표 8-2] 버퍼 접근 모드 접근 모드간 허가 관계를 살펴보면 [표 8-3]과 같다. 타 트랜잭션 획득 모드 요청한 접근 모드 Read Write Fix Read O X O Write X X O Fix O O O [표 8-3] 접근 모드간 허가 관계 [표 8-3]은 트랜잭션이 write 모드를 요청한 경우, 이미 다른 트랜잭션이 read 나 write 를 획득했다면, 페이지에 대한 해당 접근 모드의 요청은 대기하거나 실패한다는 것을 나타낸다. 또는 read 를 요구한 경우라면 접근 모드가 read 로 획득되어 있는 경우에는 접근이 성공하지만, write 로 획득되어 있는 경우에는 실패한다. 대기 모드 대기 모드는 이미 다른 트랜잭션이 페이지를 사용하고 있어 요구한 버퍼 관리자 415 접근 모드를 허가해 줄 수 없는 경우, 대기할 것인가 혹은 대기하지 않고 바로 리턴할 것인가를 결정한다. 대기 모드 설명 대기 (Wait) 다른 트랜잭션이 작업을 마치고 록(Lock)을 해제할 때까지 대기한다. 대기 안 함 (No-Wait) 다른 트랜잭션이 작업을 마치는 것을 대기하지 않 고 리턴한다. [표 8-4] 대기 모드 페이지 요청 처리 절차 1. 해시 테이블 검색 버퍼 관리자는 페이지 식별자, 접근 모드, 대기 모드로 페이지 요청을 받는다. 요청을 받으면 먼저 해시 테이블에서 해당 BCB 가 있는지 검사한다. 페이지가 버퍼에 있다면 해당 페이지를 기술하는 BCB 는 해시 테이블에서 검색할 수 있다. 만약 해시 테이블에서 BCB 를 찾을 수 없다면 페이지는 버퍼에 올라오지 않은 것이므로, 디스크로부터 페이지를 읽어 버퍼에 적재(Read Page 과정)해야 한다. [그림 8-4] 해시 테이블 검색 416 ALTIBASE5 Administrator’s Manual 2. Lock 의 획득 알티베이스는 항상 정확한 데이터를 읽도록 보장하기 위해 디스크로부터 read 가 진행중인 페이지는 read 가 끝날 때까지 접근하지 않는다. 이를 위해 디스크로부터 read 를 수행하기 위해서는 write 권한을 획득한다. 따라서 임의의 트랜잭션이 한 페이지에 대해 read 혹은 write 권한을 획득할 수 있는 시점에는 디스크로부터 write 가 진행 중이 아님을 알 수 있다. Lock 의 허가는 [표 8-5]와 같이 접근 모드, 디스크로부터 페이지 읽기, 대기 모드에 따라 달라진다. [표 8-5]에서 나타나는 것처럼, 접근모드가 Fix 를 요청한 경우 현재 페이지가 어떤 권한으로 록(Lock)이 잡혀 있더라도 바로 허가해 줄 수 있으나 디스크로부터 페이지를 읽어오는 중이라면 read 가 끝날 때까지 대기한다. 또는 Read 또는 Write 권한과 대기를 하지 않는 경우로 요청되는 경우, 만약 디스크로부터 페이지를 읽어오는 중이라면 Read 가 끝날 때까지 대기한다. 접근 모드 디스크로부터 읽기 대기모드Lock 획득 결과 Fix O 상관없다읽기가 끝날 때까지 대기 후 허가 Fix X 상관없다 허가 Read O 대기 접근 모드가 허가되면 허가, 실패 시 대기 Read O 대기안함접근 모드가 허가되면 허가, 실패 시 대기 Read X 대기 접근 모드가 허가되면 허가, 실패 시 대기 Read X 대기안함접근 모드가 허가되면 허가, 실패 시 바로 리턴 Write O 대기 접근 모드가 허가되면 허가, 실패 시 대기 Write O 대기안함접근 모드가 허가되면 허가, 실패 시 대기 Write X 대기 접근 모드가 허가되면 허가, 실패 시 대기 Write X 대기안함접근 모드가 허가되면 허가, 실패 시 바로 리턴 [표 8-5] Lock 획득 허가 버퍼 관리자 417 디스크로부터 페이지 읽기 버퍼 관리자가 페이지를 요청하였을 때, 버퍼에 존재하지 않는다면 디스크로부터 페이지를 읽는 과정을 수행한다. 1. 사용 가능한 BCB 획득 알티베이스 서버가 버퍼에 존재하지 않는 페이지를 버퍼로 적재하기 위해서는 우선 BCB 를 확보해야 한다. 페이지를 적재할 버퍼를 찾기 위해 먼저 Prepare 리스트를 검색하여 free 버퍼를 검색하면 페이지 적재를 가장 쉽게 수행할 수 있다. 그러나 free 버퍼를 확보하지 못했다면 다음 단계인 버퍼 교체를 수행한다. free 버퍼는 시스템이 구동하는 초기에 존재하며, 테이블스페이스가 drop 또는 오프라인이 수행되지 않는 이상 버퍼 풀에 존재할 가능성은 낮다. 특히 플러시한 후에도 버퍼가 페이지 내용을 유지하기 때문에 free 버퍼가 새로 생기지 않는다. 2. 버퍼 교체 만약 prepare 리스트에 free 버퍼가 없다면, 버퍼 풀이 모두 사용중인 상태이다. 이런 상태에서는 일부 페이지(희생자)를 버퍼에서 디스크로 내리고 버퍼 풀의 공간을 우선 확보해야 한다. 교체 대상을 검색하기 위해서는 먼저 prepare 리스트를 검사한다. prepare 리스트는 플러시 리스트에서 플러시된 버퍼들을 보유하고 있는 리스트로써, clean 버퍼가 존재하기 때문이다. prepare 리스트에서 교체 대상 버퍼를 찾지 못했다면 LRU 리스트를 검색한다. 그러나 LRU 리스트를 검색했는데도 clean 버퍼를 찾지 못했다면, 또 다른 prepare 리스트를 검사한다. 이 과정을 clean 버퍼를 찾을 때까지 prepare 리스트 개수만큼 반복한다. 그러나 모든 prepare 리스트를 검색하여도 clean 버퍼를 찾지 못한다면, 플러셔들을 작동시키고, prepare 리스트에 버퍼가 삽입될 때까지 대기한다. 이 때 대기 시간은 BUFFER_VICTIM_SEARCH_INTERVAL 로 설정한다. 그러나 대기시간 동안에도 clean 버퍼를 찾지 못 할 경우, 다음 prepare 리스트로 이동한다. 이를 victim search warp 이라고 한다. V$BUFFPOOL_STAT 에서 VICTIM_SEARCH_WARP 값이 증가하고 있다면 버퍼 교체시 많은 대기를 하고 있다는 의미이다. 이러한 문제가 지속된다면 버퍼를 늘리거나 플러셔의 개수를 증가시켜 시스템을 재구동시켜야 할 것이다. LRU list 에서 버퍼 교체 대상이 되기 위해서는 다음의 조건을 418 ALTIBASE5 Administrator’s Manual 만족해야 한다. y 아무도 fix하지 않은 것 (fix count가 0인 버퍼) y 버퍼에 적재되었으나 아직 수정되지 않은 것 (clean 버퍼 상태) y 버퍼가 Hot하지 않는 것 (touch count가 HOT_TOUCH_CNT 미만인 버퍼) 교체 대상 버퍼를 찾으면 해시 테이블에서 제거를 한 후 다음 과정을 진행한다. 3. 읽기 후 페이지 검증 BCB 가 확보되면 디스크로부터 페이지를 버퍼에 적재한다. 그러나 디스크에 저장된 페이지는 하드 디스크 이상이나 정전 등의 예상하지 못한 이유로 일부 페이지의 내용이 유실될 수 있다. 이러한 상황을 인식하지 못하면 사용자는 잘못된 데이터를 볼 수 있기 때문에, 알티베이스 서버에서 이를 인식해야 한다. 이를 위해 알티베이스 서버는 디스크로부터 페이지를 버퍼에 적재한 후 바로 해당 페이지가 무결한지 검사한다. [그림 8-5] 페이지 검증 플러시(Flush) 1. 플러시 대상 선정 버퍼 관리자 419 버퍼에 적재된 이후 수정된 페이지는 희생자로 선택되거나 체크포인트를 할 때 디스크에 플러시된다. 버퍼에 적재된 페이지가 플러시되기 위해서는 다음의 조건을 만족해야 한다. y 한 번 이상 수정되어야 함 y fix 개수가 0이어야 함 플러시 중에 다른 트랜잭션에 의한 읽기는 아무런 문제 없이 동시에 가능하다. 따라서 read 모드로 권한을 획득하게 된다. 2. IO 버퍼에 복사 플러시 대상 페이지가 정해지면 이 페이지를 디스크에 기록하기 전에 먼저 IO 버퍼라는 메모리 공간에 복사를 한다. IO 작업은 메모리 연산에 비해 긴 시간을 소요하기 때문에 IO 버퍼라는 메모리 공간에 먼저 복사가 된 후, 디스크에 기록된다. 버퍼 페이지가 IO 버퍼에 복사되면 그 버퍼는 다른 트랜잭션에 의해 읽혀질 수도 있고, 재갱신될 수도 있다. 그러나 IO 버퍼를 사용하지 않는다면 페이지를 디스크에 기록하는 동안 (IO 작업이 일어나는 동안) 그 페이지는 갱신되거나 읽혀질 수 없다. 플러시 대상 선정과 IO 버퍼에 복사하는 두 가지 작업은 BUFFER_IO_BUFFER_SIZE 에서 설정한 만큼 반복되며, 되면, IO 버퍼가 가득차게 된다. 이 때 로그 플러시로 넘어간다. 3. 로그 플러시 수정된 페이지를 디스크에 반영하기 전에는 항상 수정된 내용에 대한 로그를 먼저 디스크에 반영해야 한다. 이를 WAL(write ahead logging) 프로토콜이라고 한다. 그리고 디스크로부터 버퍼에 페이지를 적재할 때 이 페이지의 데이터가 깨졌는지 확인할 수 있도록 체크 섬을 계산한다. 페이지를 디스크로부터 읽을 때 이 체크 섬을 다시 한번 계산하여 페이지의 체크 섬과 비교함으로써 페이지가 무결한지 여부를 가리게 된다. 4. IO 버퍼의 페이지들을 디스크에 기록 IO 버퍼의 페이지들을 디스크에 기록하는데, 이 때 더블 라이트 파일(Double write file)에 IO 버퍼의 내용을 모두 한 번에 기록한 후, 각각의 페이지를 데이터 파일에 기록한다. 이처럼 디스크에 두 번 기록하는 이유는 페이지를 디스크에 기록하는 중에 시스템 장애가 발생하면 디스크에는 부분 쓰기(partial write)된 페이지가 남게되는데 이를 복구할 방법이 없다. 일관성이 깨진 페이지에 대해서는 리두 로그(redo log)로도 복구가 불가능하기 때문이다. 420 ALTIBASE5 Administrator’s Manual 알티베이스는 DOUBLE_WRITE_DIRECTORY 프로퍼티에 의해 더블 라이트 파일이 저장될 디렉토리를 지정하고 있다. 이 파일은 시스템 구동시 데이터 파일의 정합성을 검증 또는 복구하기 위해 사용되며, 이 파일이 없으면 이 과정을 생략한다. [그림 8-6] 페이지 플러시 과정 버퍼 관리자 421 버퍼 관련 프로퍼티 버퍼 관리자를 사용하기 위해서는 알티베이스 프로퍼티 파일을 사용 목적에 맞게 수정해야 한다. 버퍼와 관련된 프로터티는 다음과 같다. 각 프로퍼티에 대한 상세한 설명은 Starting User’s Manual 을 참조한다. y BUFFER_AREA_CHUNK_SIZE y BUFFER_AREA_SIZE y BUFFER_CHECKPOINT_LIST_CNT y BUFFER_FLUSH_LIST_CNT y BUFFER_FLUSHER_CNT y BUFFER_HASH_BUCKET_DENSITY y BUFFER_HASH_CHAIN_LATCH_DENSITY y BUFFER_IO_BUFFER_SIZE y BUFFER_LRU_LIST_CNT y BUFFER_PINNING_COUNT y BUFFER_PINNING_HISTORY_COUNT y BUFFER_PREPARE_LIST_CNT y BUFFER_VICTIM_SEARCH_INTERVAL y BUFFER_VICTIM_SEARCH_PCT y CHECKPOINT_FLUSH_COUNT y CHECKPOINT_FLUSH_MAX_GAP y CHECKPOINT_FLUSH_MAX_WAIT_SEC y DEFAULT_FLUSHER_WAIT_SEC y HIGH_FLUSH_PCT y HOT_LIST_PCT y HOT_TOUCH_CNT y LOW_FLUSH_PCT y LOW_PREPARE_PCT y MAX_FLUSHER_WAIT_SEC y REPLACE_FLUSH_COUNT y TOUCH_TIME_INTERVAL 422 ALTIBASE5 Administrator’s Manual 버퍼 관리자 통계 정보 버퍼 관리자 통계 정보는 알티베이스가 제공하는 성능 뷰를 통해 확인할 수 있다. 성능 뷰에 대해서는 제 3 장 데이터 딕셔너리를 참조한다. 버퍼 풀과 관련된 정보는 V$BUFFPOOL_STAT 을 통해, 플러셔와 관련된 정보는 V$FLUSHINFO, 버퍼 매니저의 버퍼 프레임 통계 정보는 V$BUFFPAGEINFO, Undo 테이블스페이스의 버퍼 풀 관련 통계 정보는 V$UNDO_BUFF_STAT 를 통해 확인할 수 있다. 통계 정보는 서버가 시작한 이래로 계속 누적된 값이므로 특정 기간 동안의 값을 알기 위해서는 (현재의 값 - 측정 시작 시점의 값)을 모든 칼럼 값에 대해 계산해야 한다. Hit Ratio 구하기 V$BUFFPOOL_STAT 의 HIT_RATIO 칼럼을 통해 버퍼 풀의 누적된히트율을 확인할 수 있다. Hit Ratio 는 다음의 수식에 의해 구해진다. Hit Ratio = (GET_PAGES + FIX_PAGES - READ_PAGES) / (GET_PAGES + FIX_PAGES) 예제 iSQL> select hit_ratio from X$BUFER_POOL_STAT; 백업 및 복구 423 9. 백업 및 복구 시스템 정전 또는 디스크, 데이터 파일 손상 유실 등과 같은 예기치 않은 상황으로 인해 알티베이스에 저장된 데이터가 손실될 경우를 대비하여 알티베이스에서 지원하는 백업 및 복구에 대하여 설명한다. 424 ALTIBASE5 Administrator’s Manual 알티베이스 백업 이 절에서는 데이터베이스 모드에 따라 메모리/디스크 테이블스페이스에 대하여 지원되는 백업 정책과 유형에 대하여 설명한다. 알티베이스 백업 정책 알티베이스에서 제공하는 백업을 분류하면 다음과 같다. y 논리적 백업 유틸리티(Utility) 백업 y 물리적 백업 오프라인(Offline) 백업 온라인(Online) 백업 논리적 백업은 aexport 혹은 iLoader 를 이용하여 테이블, 인덱스 생성 스크립터 파일들과 테이블 레코드들을 기록한 파일들이 생성된다. 물리적 백업은 데이터베이스를 구성하는 데이터 파일들과 로그앵커 파일의 복사를 수행한다. 물리적 백업은 데이터 파일의 스냅샷(snapshot)을 복사할 때 서비스 중지 여부에 따라 온라인 백업과 오프라인 백업으로 구분된다. 오프라인 백업은 데이터베이스 서버를 정상 종료한 후에 모든 테이블스페이스 파일, 로그앵커 파일과 로그 파일들을 복사하는 것을 말한다. 온라인 백업은 서비스 중지 없이 데이터베이스의 데이터 파일들과 로그앵커 파일 등을 복사하는 것을 의미하며 이 데이터 파일들의 복사 과정에서 반영(commit)되지 않은 데이터들이 포함될 수 있다. 따라서 복구 시에 트랜잭션 철회(undo)를 수행하기 위해서는 로그 파일들이 필요하며 아카이브 로그 파일들이 생성되는 아카이브 로그 모드로 운영 될 때 온라인 백업이 가능하다. 온라인 백업은 데이터베이스 전체를 백업 할 수 있거나, 특정 테이블스페이스 또는 로그앵커를 백업 할 수 있다. y 데이터베이스 전체 백업 alter database backup database to '/backup_dir'; y 테이블스페이스 별 백업 alter database backup tablespace SYS_TBS_DISK_DATA to '/backup_dir'; alter tablespace SYS_TBS_DISK_DATA begin backup; cp SYS_TBS_DISK_DATA-DATA-FILES /backup_dir 백업 및 복구 425 … alter tablespace SYS_TBS_DISK_DATA end backup; 시스템 카탈로그 정보를 포함하는 메모리 테이블스페이스인 SYS_TBS_MEM_DIC 는 테이블스페이스 백업뿐 아니라 전체 데이터베이스 백업 시에도 백업이 이루어진다. 백업 종류 백업 방법 백업 객체 복구 방법 서비스 iLoader 이 용 iLoader의 out 명령 이용 사용자가 명 시한 테이블 iLoader의 in 명령 이용 O 온라인 백업 (DB전체) SQL 문 이용 alter database backup datbase to ‘backup_dir’; 시스템 전체 테이블스페이 스의 데이터 파일, 로그 앵 커파일 1> 유닉스 명령어 cp 이용. 2> alter database recover database; O 온라인 백업 (특정 테이 블스페이스) 1> SQL 문 이용 alter database backup tablespace 테이블스페이스이름 to ‘backup_dir’; 또는 alter tablespace 테이블스페이스 이름 begin backup; 2> cp 테이블스페이스 에_포함된_파일 backup_dir 3> Alter tablespace 테이블스페이스 이름 end backup; 테이블스페이 스의 모든 데 이터 파일 1> 유닉스 명령어 cp 이용. 2> alter database recover database; O 오프라인 백 업 1>데이터베이스 종료 2>유닉스 명령어 cp 이용 데이터베이스 전체 유닉스 명령어 cp 이용 X 백업시간 비 교 iLoader isql -silent -u sys -p manager -sysdba iSQL(sysdba)> startup control; iSQL(sysdba)> alter database archivelog; 데이터베이스 모드에 따른 온라인 백업 및 매체 복구 모드 백업방법 매체 복구 방법 노아카이브 로그 오프라인 백업 Full-DB 복구 아카이브 로그 온라인 백업 (오프라인 백업 가능) 완전 복구 Full-DB 불완전 복구 Until-Cancel Until-Time 상관없음 iloader Utility 백업 iloader 복구 [표 9-3] 데이터베이스 모드에 따른 백업 및 복구 방법 테이블스페이스 상태에 따른 온라인 백업 및 매체 복구 테이블스페이스 상태 온라인 백업 매체 복구 온라인(ONLINE) 가능 가능 오프라인(OFFLINE) 가능 가능 디스카드(DISCARDED) 불가능 불가능 삭제(DROPPED) 불가능 불가능 백업(BACKUP) 불가능 의미 없음 [표 9-4] 테이블스페이스 상태에 따른 온라인 백업과 매체 복구 백업 시 주의사항 428 ALTIBASE5 Administrator’s Manual 온라인 백업과 체크포인트는 동시에 수행될 수 없다. 체크포인트 시 메모리 상의 데이터베이스 내용이 디스크에 반영되고 온라인 백업은 백업할 바로 그 시점까지의 데이터만 백업됨을 보장하 기 때문에 체크포인트와 온라인 백업은 서로 배타적으로 수행된다. 체크포인트 수행 시 온라인 백업 요구가 들어오면 체크포인트가 완료 된 후에 온라인 백업이 시작된다. 마찬가지로 온라인 백업 진행 중 체크포인트 요구가 들어와도 온라인 백업이 완료된 후 체크포인트가 수행된다. 알티베이스는 하이브리드 데이터베이스 특성상 데이터베이스 백업 시에 메모리 테이블스페이 스, 디스크 테이블스페이스 순으로 백업을 진행한다. 메모리 테이블스페이스가 백업 중에는 체크 포인트가 수행 될 수 없 지만, 메모리 테이블스페이스의 백업이 완료되고 디스크 테이블스페 이스 백업 중에는, 메모리 테이블스페이스에 대한 체크 포인트는 수 행하고 디스크 테이블스페이스에 대한 체크 포인트는 수행하지 않는 다. 이중화가 걸려 있는 경우 이중화 정보도 그대로 백업된다. 백업을 받는 알티베이스에 이중화가 걸려 있는 경우 이중화 관련 정 보도 그대로 백업되기 때문에 백업된 데이터베이스를 동일하지 않은 시스템에 복구하는 경우 그 장비의 네트워크 주소가 달라지므로 알티 베이스 복구 후 이중화 사용에 문제가 발생할 수 있다. 따라서, 이중화가 걸려 있는 경우 (1) 이중화를 중지 및 삭제한 후 백 업을 수행하거나 또는 (2) 이중화를 사용하는 두 시스템에서 다른 시 스템의 백업 데이터로 데이터베이스를 복구할 경우 반드시 모든 시스 템의 이중화 기능을 중지하여 복구 중에 다른 시스템으로 이중화가 되는 것을 방지해야 한다. 백업 및 복구 429 알티베이스 복구 알티베이스 복구 정책 알티베이스에서 제공하는 복구를 분류하면 다음과 같다. y 재시작시 자동 복구 (Restart Recovery) y 매체 복구 (Media Recovery) 재 시작 시 자동 복구는 알티베이스 프로세스가 시스템이 crash 되거나 소프트웨어 오류로 비정상 종료된 경우, startup 단계에서 자동으로 수행되는 복구이다. 매체 복구는 특정 데이터 파일이 유실되거나 깨진 경우에 백업 받은 과거 데이터 파일의 스냅샷(snapshot)을 이용하여 백업 데이터 파일의 복구 시작 LSN 부터 현재 LSN 까지 재 수행하여 과거의 데이터 파일의 백업본으로부터 현재 시점의 데이터 파일까지 복구하는 것이다. 데이터 파일의 매체 복구가 필요한가에 대한 판단은 로그앵커 파일상의 해당 데이터 파일의 버전과 데이터 파일의 버전과 일치 여부에 따라 결정된다. [그림 9-1] 알티베이스 복구 절차 알티베이스에서는 매체 복구를 control startup 단계에서만 할 수 있다. 즉 오프라인 매체 복구(offline media recovery)만 지원한다. 430 ALTIBASE5 Administrator’s Manual 예제 매체 복구의 예를 살펴본다. TEST 테이블스페이스의 데이터 파일 ‘user1.dbf’ 파일이 유실되었다. 이틀 전에 온라인(Online) 백업받은 ‘user1.dbf’을 이용하여 현재 시점의 데이터 파일을 복구하는 예는 다음과 같다. Shell> cp /bck/user1.dbf $ALTIBASE_HOME/dbs Shell> isql -silent -u sys -p manager -sysdba [ERR-00000 : Connected to idle instance] iSQL(sysdba)> startup control; Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE : PROCESS TRANSITION TO PHASE : CONTROL Command execute success. iSQL(sysdba)> alter database recover database; Alter success. TEST 테이블스페이스의 데이터 파일 ‘user1.dbf’가 매체 복구되었다. iSQL(sysdba)> startup service; 매체복구가 완료되었기 때문에 서비스(service) 단계로 전이한다. 완전 복구와 불완전 복구 알티베이스 매체 복구 정책은 완전 복구와 불완전 복구를 모두 지원한다. 완전 복구라 하면 온라인 로그와 아카이브 로그의 유실 없이 현재 시점까지 데이터 파일 복원을 의미한다. 불완전 복구는 아카이브 로그 파일 또는 온라인 로그 파일이 유실되었거나, 특정 시각으로 복구하기 위하여 특정 과거 시점으로 데이터베이스 전체가 돌아가는 것이다. 완전 복구의 예는 다음과 같다. alter database recover database; 불완전 복구는 다음 2 가지 경우로 나눌 수 있다. y 과거의 특정 시점으로 데이터베이스 전체를 되돌리는 경우, 2007년 9월 10일에 받은 전체 DB 백업 파일을 복사하여 복구한다. alter database recover database until time ‘2007-09-10:17:55:00’; y 특정 온라인 로그 파일이 손상되어 현재 시점까지 redo를 할수 없는 경우, 손상된 온라인 로그 파일 바로 전까지 redo를 진행한다. 백업 및 복구 431 alter database recover database until cancel; control startup 단계에서 불완전 복구를 한 경우에 meta startup 단계로 넘어갈 때 반드시 다음 구문을 사용해야 한다. alter database db_name meta resetlogs; 데이터베이스가 특정 과거 시점으로 복원되었기 때문에, 재 시작 시 자동 복구(Restart Recover)를 수행하지 않기 위하여 온라인 로그를 초기화(resetlogs)한다. Startup meta 단계로 resetlogs 를 하면서 meta 단계로 전이 하였다면, 오프라인이나 온라인 백업으로 데이터베이스 전체 백업을 반드시 받아야 한다. 예를 들면, resetlogs 를 하고 meta 단계로 전이하고 나서 2 일 이후에 매체에 또 다시 에러가 발생한 경우에, resetlogs 이전까지만 복구가 가능하기 때문이다. 즉, resetlog 이후부터 2 일간의 데이터는 유실하게 된다. 매체 복구시 주의사항 매체 복구 알고리즘 때문에 가능하면 현재 로그 앵커 파일들을 이 용하여 매체 복구를 하여야 한다. 백업된 데이터 파일들만 복사하여 복구하고, 로그앵커 파일들은 특별 한 경우가 아닌 경우에는 백업 본을 사용하여 복구하면 안 된다. 특별한 경우는 사용자의 실수로 drop tablespace 명령으로 테이블스 페이스를 삭제 한 경우이며 이 때 현재 로그앵커 파일에 drop된 테이 블스페이스 정보가 없어서 과거의 백업된 로그앵커를 사용하는 경우 이다. 메모리 테이블스페이스의 데이터 파일을 복구 시 stable한 메모리 데이터 파일을 이용하여 unstable한 메모리 데이터 파일을 만들어 야 한다 알티베이스는 메모리 테이블스페이스에 대하여 핑퐁 체크포인트 (ping-pong checkpoint) 기법을 사용하기 때문에 디스크 상에서 메 모리 테이블스페이스에 대하여 데이터 파일을 2개로 유지한다. 동일 한 이미지를 기록하고 있는 1묶음(pair)의 데이터 파일은 MEM_DB_DIR 프로퍼티에 설정된 위치에 저장된다. 2개의 데이터 파일이 모두 존재해야만 알티베이스를 정상적으로 운용할 수 있다. 어느 한 시점에서는 메모리 테이블스페이스는 오직 1개의 데이터 파 일만 사용된다. 백업 시 백업 시간을 줄이기 위하여 메모리 테이블스페이스의 가장 최근 체크포인터가 수행된 한 개의 데이터 파일만 백업한다. 432 ALTIBASE5 Administrator’s Manual 따라서 백업된 메모리 테이블스페이스 데이터 파일을 이용하여 복구 할 경우 나머지 한 개의 데이터 파일을 동일한 이미지로 생성하여야 한다. 백업 받은 메모리 테이블스페이스의 데이터 파일이 다음과 같다. SYS_TBS_MEM_DIC-1-0, SYS_TBS_MEM_DIC-1-1, SYS_TBS_MEM_DIC-1-2 메모리 테이블스페이스의 데이터 파일의 복사는 다음과 같이 되어야 한다. shell> cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs; shell> cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-0; shell> cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs; shell> cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-1; shell> cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs; shell> cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-2; 테이블스페이스의 추가, 삭제 및 이름 변경 등이 이루어지면, 메모 리 테이블스페이스(SYS_TBS_MEM_DIC)의 백업이나 전체 데이터 베이스의 백업이 필요하다. iSQL(sysdba)> alter database backup tablespace SYS_TBS_MEM_DIC to ‘/backup_dir’; 로그앵커 파일은 데이터베이스의 테이블스페이스 정보를 포함하고 있 으므로 테이블스페이스 구조가 변경될 때마다 메모리 테이블스페이스 와 함께 백업되어야 한다. iSQL(sysdba)> alter database backup loganchor to '$ANCHOR_PATH'; 백업 및 복구 433 백업 및 복구 사례들 i Loader 를 이용한 테이블 백업 및 복구 임의의 테이블에만 문제가 발생할 것을 대비하거나, 특정 이유로 해당 테이블만 백업을 받으려고 하는 경우 사용한다. 백업 전 주의사항 백업하기 전에 반드시 백업하고자 하는 테이블의 스키마에 관한 정보 파일(FORM file)을 생성해야 한다. FORM 파일이란 테이블에 관한 기본 정보(칼럼 이름, 데이터 타입)를 가지고 있는 파일을 말한다. 예제) 테이블 t1 의 form file 생성 (t1.fmt 라는 파일 이름으로 생성됨) iLoader> formout -T t1 -f t1.fmt 백업 방법 iLoader 의 명령 중 out 을 사용한다. 사용자가 명시한 이름으로 테이블에 대한 백업 파일이 생성된다. 예제) 테이블 t1 의 백업 (이용할 form 파일은 t1.fmt 생성할 백업 파일은 t1.dat ) iLoader> out -d t1.dat -f t1.fmt 복구(restore) 방법 iLoader 의 명령 중 in 을 사용한다. 복구 시 테이블에 레코드가 존재하는 경우 그 레코드들을 유지하거나 덮어쓰게 할 수 있으며, 사용자가 명시하지 않는 경우 존재하는 레코드들의 내용은 유지된다. 예제) 테이블 t1 의 복구 iLoader> in -d t1.dat -f t1.fmt Ofl i ne 백업 및 복구 오프라인 백업 및 복구는 주로 노아카이브 로그 모드일 경우에 사용하는 방법이다. 백업 전 주의사항 백업 전 알티베이스와 관련된 모든 서비스를 중지한다. 서비스 진행 중에 오프라인 백업을 수행하면 로그 파일에 내용이 변경됨과 동시에 백업이 진행될 수 있어서 백업이 정확하게 수행되지 않을 수 434 ALTIBASE5 Administrator’s Manual 있다. 그러므로 반드시 알티베이스를 중지하고서 수행하여야 한다. 백업 방법 테이블스페이스의 데이터 파일들, 로그 파일, 로그 앵커 파일을 운영체제 복사 명령어인 cp 를 이용하여 백업한다. 알티베이스는 메모리 데이터 파일 뿐만 아니라 디스크 관련 테이블스페이스의 데이터 파일들과 로그 앵커파일을 백업한다. 메모리 테이블스페이스 데이터 파일 저장 위치는 알티베이스 프로퍼티 파일인 $ALTIBASE_HOME/conf/altibase.properties 파일 내에 MEM_DB_DIR 으로 설정되어있다. 메모리 테이블스페이스의 데이터 파일을 백업 받기 위해서는 MEM_DB_DIR 디렉토리를 모두 복사해야 한다. 로그 앵커 파일의 위치는 LOGANCHOR_DIR 프로퍼티로 $ALTIBASE_HOME/conf/altibase.properties 파일 내에 설정되어 있다. 로그 앵커 파일을 백업받기 위해서는 LOGANCHOR_DIR 디렉토리의 파일들을 복사해야 한다. 그리고 데이터 딕셔너리를 참조하여 디스크의 테이블스페이스의 데이터 파일들을 복사한다. 예제) $ALTIBASE_HOME/conf/altibase.properties 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 복구 방법 알티베이스 설정 파일은 백업될 당시의 설정 파일을 그대로 이용한다. 공유 메모리에 남아있는 데이터베이스를 삭제한다. 백업 시 받았던 파일들을 복사 명령어 cp 를 이용하여 복구한다. 예) 위에서 백업된 데이터베이스를 이용하여 복구 $cp -r /home/backup/dbs0 ALTIBASE_HOME/dbs0 $cp -r /home/backup/dbs1 $ALTIBASE_HOME/dbs1 $cp -r /home/backup/logs $ALTIBASE_HOME/logs $cp -r /home/backup/system*.dbf $ALTIBASE_HOME/dbs $cp -r /home/backup/undo.dbf $ALTIBASE_HOME/dbs $cp -r /home/backup/temp.dbf $ALTIBASE_HOME/dbs 백업 및 복구 435 데이터베이스 시스템에 의한 온라인 백업 데이터베이스 단위 온라인 백업 /backup_dir 에 전체 데이터베이스를 온라인 백업한다. iSQL(sysdba)> alter database backup database to‘/backup_dir’; shell> ls /backup_dir SYS_TBS_MEM_DIC-0-0 SYS_TBS_MEM_DATA-0-0 system001.dbf system002.dbf undo001.dbf loganchor0 loganchor2 loganchor1 테이블스페이스 단위 온라인 백업 /backup_dir 에 SYS_TBS_MEM_DIC 의 안정(stable) 버전 데이터 파일들을 온라인 백업한다. iSQL(sysdba)> alter database backup tablespace SYS_TBS_MEM_DIC to ‘/backup_dir’; shell> ls /backup_dir SYS_TBS_MEM_DIC-0-0 로그앵커 온라인 백업 /backup_dir 에 로그앵커 파일을 모두 온라인 백업한다. iSQL(sysdba)> alter database backup loganchor to ‘/backup_dir’; shell> ls /backup_dir loganchor0 loganchor1 loganchor2 DBA 에 의한 온라인 백업 테이블스페이스 단위 온라인 백업 /backup_dir 에 USER_MEMORY_TBS 와 USER_DISK_TBS 의 데이터 파일들을 온라인 백업 한다. 메모리 테이블스페이스 데이터 파일은 안정(stable) 버전 데이터 파일을 확인 후 온라인 백업한다. iSQL(sysdba)> alter tablespace USER_MEMORY_TBS begin backup; iSQL(sysdba)> select * from v$stable_mem_datafiles; V$STABLE_MEM_DATAFILES.MEM_DATA_FILE ------------------------ /altibase_home/dbs/USER_MEM_TBS-0-0 shell> cp $ALTIBASE_HOME/dbs/USER_MEMORY_TBS-0-0 /backup_dir/ 436 ALTIBASE5 Administrator’s Manual iSQL(sysdba)> alter tablespace USER_MEMORY_TBS end backup; iSQL(sysdba)> alter tablespace USER_DISK_TBS begin backup; shell> cp $ALTIBASE_HOME/dbs/USER_DISK_TBS.dbf /backup_dir/ iSQL(sysdba)> alter tablespace USER_DISK_TBS end backup; shell> ls /backup_dir USER_MEMORY_TBS-0-0 USER_DISK_TBS.dbf 온라인 백업 마무리 DBA 에 의한 직접 온라인 백업을 수행하였다면 마지막 절차가 남아있는데 백업과 관련된 로그 파일을 강제로 아카이브(archive) 하는 명령어이다. 해당 명령은 로그 파일을 다 쓰지 않았어도 닫고 다음 로그 파일에 기록을 하기 시작한다. iSQL(sysdba)> alter system switch logfile; altibase_sm.log 의 온라인 백업 완료 메시지가 남아 있는데, 방금 완료된 백업 버전은 logfile15341 로그파일을 아카이브 함으로써 완료됨을 나타낸다. [2007/09/18 14:42:38] [Thread-6] [Level-9] Waiting logfile15341 to archive [2007/09/18 14:42:43] [Thread-6] [Level-9] Database-Level Backup Completed [SUCCESS] 참고) 데이터베이스에 의한 온라인 백업을 수행하였다면 1 번 과정을 자동으로 수행하므로 2 번 과정을 백업 버전들과 함께 기록해 두면 된다. 매체복구 사례 1 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 백업하지 않은 데이터 파일 $ALTIBASE_HOME/dbs/abc.dbf 가 유실되었다. 참고) 메모리 테이블스페이스의 데이터 파일은 이와 같은 복구 방법을 지원하지 않는다. 복구 방법 완전 복구에 필요한 아카이브 로그 파일을 확인한다. iSQL(sysdba)> select name, create_lsn_lfgid, 백업 및 복구 437 create_lsn_fileno from v$datafiles; ------------------------ /altibase_home/dbs/abc.dbf 0 18320 마지막 삭제된 로그 파일을 확인하기 위해서는 유틸리티 ‘dumpla’를 이용하여 loganchor 의 내용을 확인한다. shell> dumpla loganchor0 [LOGANCHOR HEADER] Binary DB Version [ 5.3.3 ] Archivelog Mode [ Archivelog ] Begin Checkpoint LSN [ 0, 20345, 469859 ] End Checkpoint LSN [ 0, 20345, 47030 ] Disk Redo LSN [ 0, 20345, 469859 ] Global SN [ 9476323 ] Server Status [ SERVER SHUTDOWN ] Log File Group Count [ 1 ] Log File Group [ 0 ] End LSN [ 0, 20345,470341 ] ResetLog LSN [ 4294967295, 4294967295, 4294967295 Last Created Logfile Num [ 20350 ] Delete Logfile(s) Range [ 20344 ~ 20333 ] Update And Flush Count [ 316 ] New Tablespace ID [ 8 ] ARCHIVE_DIR(프로퍼티)에 정의된 디렉토리에 logfile18320 부터 logfile20344 까지 존재하는지 확인한다. 만약 존재하지 않는다면, 백업 저장 장치로부터 아카이브 로그파일을 ARCHIVE_DIR(프로퍼티) 디렉토리에 복사한다. logfile20345 이후 로그 파일은 모두 LOG_DIR(프로퍼티) 디렉토리에 존재하는 온라인 로그 파일이다. 즉, logfile18320 부터 logfile20345 이후까지는 유실된 abc.dbf 가 완전 복구하는데 반드시 필요한 로그 파일이다. ARCHIVE_DIR 과 LOG_DIR 간의 로그 파일 중복으로 인해 발생되는 디스크 공간 낭비를 제거하기 위해 알티베이스가 직접 ARCHIVE_DIR 의 로그 파일을 참고한다. CONTROL 단계에서 유실된 abc.dbf 파일을 생성한다. iSQL(sysdba)> alter database create datafile‘abc.dbf’; CONTROL 단계에서 완전 매체 복구를 수행한다. iSQL(sysdba)> alter database recover database; 매체복구 사례 2 438 ALTIBASE5 Administrator’s Manual 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 3 일 전에 테이블스페이스 USER_DISK_TBS 의 데이터 파일들을 백업하였다. 오늘 오전에 USER_DISK_TBS 테이블스페이스의 데이터 파일을 모두 잃어 버렸다. 백업 방법 3 일전에 수행했던 백업은 다음과 같다. iSQL(sysdba)> alter database backup tablespace USER_DISK_TBS to ‘/backup1’; iSQL(sysdba)> alter system switch logfile; shell> ls /backup1 USER_DISK_TBS01.dbf USER_DISK_TBS02.dbf USER_DISK_TBS03.dbf 복구 방법 완전 복구에 필요한 아카이브 로그 파일을 확인 확인하고 아카이브 디렉토리로 해당 파일들을 복사한다. 필요한 아카이브 로그 파일을 확인하는 방법은 해당 복구되는 데이터 파일의 헤더에 있는 정보를 참조해야 하는데 이를 확인하는 방법은 dumpddf 란 유틸리티를 이용하며 다음과 같이 수행하여 결과를 얻을 수 있다. shell> dumpddf -m -f USER_DISK_TBS01.dbf [BEGIN DATABASE FILE HEADER] Binary DB Version [ 5.3.3 ] Redo LSN [ 0, 4, 2257550 ] Create LSN [ 0, 0, 657403 ] [END DATABASE FILE HEADER] 상기의 결과는 백업된 데이터 파일은 아카이브 로그 파일 logfile4 이후 파일들을 필요로 한다. backup_dir 에 백업한 데이터 파일을 USER_DISK_TBS 의 데이터 파일이 있었던 $ALTIBASE_HOME/dbs/ 에 복사한다. shell> cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs; CONTROL 단계에서 완전 매체 복구를 수행한다. iSQL(sysdba)> alter database recover database; 매체복구 사례 3 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 7 일전에 테이블스페이스 USER_DISK_TBS 의 데이터 파일들을 백업하였다. 오늘 오후에 USER_DISK_TBS 테이블스페이스의 데이터 파일이 있는 /disk1 파일 시스템이 깨졌으며, /disk2 는 파일 시스템은 백업 및 복구 439 정상이다. 이 복구 방법은 /disk1 파티션이 깨졌으므로 정상 상태의 /disk2 파티션에 백업된 데이터 파일을 옮겨 매체 복구를 수행하는 방법이다. 백업 방법 7 일 전에 수행했던 백업은 다음과 같다. iSQL(sysdba)> alter database backup tablespace task to '/backup_dir’; iSQL(sysdba)>alter system switch logfile; shell> ls /backup_dir USER_DISK_TBS01.dbf USER_DISK_TBS02.dbf 복구 방법 완전 복구에 필요한 아카이브 로그 파일을 확인하고, 아카이브 디렉토리로 해당 파일들을 복사한다.backup_dir 에 백업한 USER_DISK_TBS 의 파일들을 온전한 /disk2 파일 시스템으로 복사한다. shell> cp /backup_dir/*.dbf /disk2/dbs; CONTROL 단계에서 USER_DISK_TBS 데이터 파일 경로를 변경한다. iSQL(sysdba)> alter database rename datafile '/disk1/dbs/USER_DISK_TBS01.dbf' to '/disk2/dbs/USER_DISK_TBS01.dbf'; iSQL(sysdba)> alter database rename datafile '/disk1/dbs/USER_DISK_TBS02.dbf' to '/disk2/dbs/USER_DISK_TBS02.dbf'; 참고) 위 명령과 동일한 명령으로 alter tablespace 명령을 사용할 수 있다. iSQL(sysdba)> alter tablespace USER_DISK_TBS rename datafile '/disk1/dbs/USER_DISK_TBS02.dbf' to /disk2/dbs/USER_DISK_TBS02.dbf'; 데이터 파일 경로가 정확히 변경되었는지 v$datafile 을 확인한다. iSQL(sysdba)> select * from v$datafiles; CONTROL 단계에서 완전 매체복구를 수행한다. iSQL(sysdba)> alter database recover database; 매체복구 사례 4 archivelog 모드로 데이터베이스를 운영하고 있으며, 유저의 실수로 summary 테이블을 DROP 하였다. A. 전체 온라인 백업 완료 시각 ( 2007 년 9 월 18 일 12 시 00 분 ) 440 ALTIBASE5 Administrator’s Manual B. 테이블이 DROP 된 시각 ( 2007 년 9 월 18 일 15 시 00 분 ) C. 현재 시각 ( 2007 년 9 월 18 일 18 시 00 분 ) summary 테이블을 복구하기 위해서는 현재 시각부터 약 3 시간 30 분 전인 2007 년 9 월 18 일 14 시 30 분 정각으로 데이터베이스를 불완전 매체 복구를 수행해야 한다. 백업 방법 지난번 백업 시 다음과 같이 전체 DB 백업을 하였다. iSQL(sysdba)> alter database backup database to‘/backup_dir’; iSQL(sysdba)> alter system switch logfile; 복구 방법 불완전 복구를 위해서는 전체 DB 백업이 필요하다. 1. 백업 받은 데이터 파일들을 원래 위치로 복사를 한다. shell> cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs; 2. 메모리 테이블스페이스는 핑퐁(ping pong) 체크 포인트 기법을 사용하고 있으며, 백업 시에는 메모리 테이블스페이스는 안전한 (stable)한 데이터 파일만 복사된다. 예) 백업받은 메모리 테이블스페이스의 데이터 파일이 다음과 같 다, SYS_TBS_MEM_DIC-1-0, SYS_TBS_MEM_DIC-1-1, SYS_TBS_MEM_DIC-1-2 SYS_TBS_MEM_DATA-0-0, SYS_TBS_MEM_DATA-0-1, SYS_TBS_MEM_DATA-0-2 3. 백업된 메모리 테이블스페이스는 안정한(stable) 데이터 파일이 기 때문에 안정한 버전의 확인 절차 없이 복사하면 된다. shell> cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs shell> cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs shell> cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs shell> cp SYS_TBS_MEM_DATA-0-0 $ALTIBASE_HOME/dbs shell> cp SYS_TBS_MEM_DATA-0-1 $ALTIBASE_HOME/dbs shell> cp SYS_TBS_MEM_DATA-0-2 $ALTIBASE_HOME/dbs 4. 불완전 복구는 백업된 로그앵커 파일을 사용한다. 백업 된 저장 장치로부터 로그앵커를 복사한다. shell> cp /backup_dir/loganchor* $ALTIBASE_HOME/logs 5. 불완전 복구에 필요한 아카이브 로그 파일을 아래와 같이 확인한 다. iSQL(sysdba)> select last_deleted_logfile from v$lfg; LAST_DELETED_LOGFILE ------------------ 백업 및 복구 441 15021 6. $ALTIBASE_HOME/trc 디렉토리에 생성되는 altibase_sm.log 파일에서 백업 완료 시 강제로 아카이브 처리된 파일을 확인한다. [2007/09/18 13:59:59] [Thread-6] [Level-9] Waiting logfile15341 to archive 7. 위 결과에 의해 로그 파일 15021부터 백업 완료 마무리 시 기 록해 두었던 마지막 아카이브 로그 파일 15341까지 모두 ARCHIVE_DIR (혹은 백업 장치)로부터 LOG_DIR(프로퍼티)에 복사한다. 불완전 매체 복구는 완전 복구와 달리 로그 파일 중복 을 불가피하게 허용해야 한다. 8. SYS_TBS_DISK_TEMP 는 백업되지 않기 때문에 해당 파일을 만들어 준다. iSQL(sysdba)> alter database create datafile 'temp001.dbf' 9. 불완전 매체 복구를 다음과 같이 수행한다. iSQL(sysdba)> alter database recover database until time ‘207-09-18:14:30:00'; 10. 복구가 완료된 메모리 테이블스페이스에 대해서 모든 안정한 데 이터 파일들을 사용하여 불안정한 버전을 생성한다. shell> cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-0; shell> cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-1; shell> cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-2; shell> cp SYS_TBS_MEM_DATA-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DATA-0-0; shell> cp SYS_TBS_MEM_DATA-1-1 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DATA-0-1; shell> cp SYS_TBS_MEM_DATA-1-2 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DATA-0-2; 11. 불완전 매체 복구를 수행하였기 때문에 meta startup 단계로 가 기 전에 resetlogs 를 하여야 한다. iSQL(sysdba)> alter database mydb meta resetlogs; 12. resetlogs 를 수행하였기 때문에 DB 전체 백업을 받는다. iSQL(sysdba)> alter database backup database to ‘backup_dir’; 매체복구 사례 5 아카이브 로그 모드로 데이터베이스를 운영하고 있다. 온라인 로그파일이 로그파일 499~ 600 가 있었으며, 중간 로그파일인 442 ALTIBASE5 Administrator’s Manual 570 번 로그 파일이 유실되었다. 복구 방법 logfile569 번까지의 데이터베이스 상태로 복구하려고 한다. 전체 백업 버전 데이터 파일과 관련된 logfile 은 499 부터 550 번까지이다. 불완전 복구에 필요한 데이터 파일과 로그앵커 파일을 백업 본으로부터 복사한다. 불완전 복구에 필요한 아카이브 로그 파일을 확인한다. Logfile499 부터 569 까지만 데이터베이스에 반영하고, logfile570 번 이후의 로그 파일에 대해서는 반영하지 않는다. iSQL(sysdba)> alter database recover database until cancel; 불완전 미디어 복구를 수행하였기 때문에 meta startup 단계로 가기 전에 resetlogs 를 하여야 한다. iSQL(sysdba)> alter database mydb meta resetlogs; resetlogs 를 수행하였기 때문에 DB 전체 백업을 받는다. iSQL(sysdba)> alter database backup database to ‘/backup_dir’; 매체복구 사례 6 노아카이브 로그 모드이지만 매체 복구를 할 수 있는 경우가 있다. 바로 임시(temporary) 테이블스페이스의 데이터 파일이 유실되는 경우이다. 임시 테이블스페이스에 대해서는 재 수행이 필요 없기 때문이다. 복구 방법 CONTROL 단계에서 SYS_TBS_DISK_TEMP 의 유실된 데이터 파일 대신에 새로운 temp001.dbf 를 생성한다. iSQL(sysdba)> alter database create datafile ‘temp001.dbf’; 서버를 구동한다. iSQL(sysdba)> alter database dbname service; 매체복구 사례 7 아카이브 로그 모드로 데이터베이스를 운영하고 있다. 메모리 테이블스페이스인 SYS_TBS_MEM_DIC 의 데이터 파일이 유실되었다. 백업 방법 백업 및 복구 443 SYS_TBS_MEM_DIC 테이블스페이스를 테이블스페이스 단위 백업한다. iSQL(sysdba)> alter database backup tablespace SYS_TBS_MEM_DIC to ‘/backup_dir’; 복구 방법 완전 복구에 필요한 아카이브 로그 파일을 확인 확인하고 아카이브 디렉토리로 해당 파일들을 복사한다. 필요한 아카이브 로그 파일을 확인하는 방법은 해당 복구되는 데이터 파일의 헤더에 있는 정보를 참조해야 하는데 이를 확인하는 방법은 dumpddf 란 유틸리티를 이용하며 다음과 같이 수행하여 결과를 얻을 수 있다. shell> dumpddf -m -f USER_DISK_TBS01.dbf [BEGIN DATABASE FILE HEADER] Binary DB Version [ 5.3.3 ] Redo LSN [ 0, 4, 2257550 ] Create LSN [ 0, 0, 657403 ] [END DATABASE FILE HEADER] 상기의 결과는 백업된 데이터 파일은 아카이브 로그 파일 logfile4 이후 파일들을 필요로 한다. 메모리 테이블스페이스 백업은 안정한(stable) 데이터 파일만 백업되며, 백업된 파일이 SYS_TBS_MEM_DIC-0-0 이면 복사는 다음과 같이 수행되어야 한다. shell> cp /backup_dir/SYS_TBS_MEM_DIC-0-0 $ALTIBASE_HOME/dbs; $ALTIBASE_HOME/bin/dumpla loganchor0 결과 중 테이블스페이스 이름이 SYS_TBS_MEM_DIC 인 TABLESPACE ATTRIBUTE 중 Stable Checkpoint Image Num 이란 항목을 참고한다. [ TABLESPACE ATTRIBUTE ] Tablespace ID [ 0 ] Tablespace Name [ SYS_TBS_MEM_DIC ] New Database File ID [ 0 ] Tablespace Status [ ONLINE ] TableSpace Type [ 0 ] Checkpoint Path Count [ 0 ] Autoextend Mode [ Autoextend ] Shared Memory Key [ 0 ] Stable Checkpoint Image Num. [ 1 ] Init Size [ 4 MBytes ( 129 Pages ) ] Next Size [ 4 MBytes ( 128 Pages ) ] Maximum Size [ 13421727 MBytes ( 4294967295 Pages ) ] Split File Size [ 1024 MBytes ( 32768 Pages ) ] [ MEMORY CHECKPOINT PATH ATTRIBUTE ] Tablespace ID [ 0 ] Checkpoint Path [ /home/altibase_home/dbs ] [ MEMORY CHECKPOINT IMAGE ATTRIBUTE ] 444 ALTIBASE5 Administrator’s Manual Tablespace ID [ 0 ] File Number [ 0 ] Create LSN [ 0, 0, 2028 ] Create On Disk (PingPong 0) [ Created ] Create On Disk (PingPong 1) [ Created ] SYS_TBS_MEM_DIC 은 백업의 안정한(stable) 버전이 [0]이고 데이터베이스의 안정한 버전은 [1]이므로 다음과 같이 복사한다. shell> cd $ALTIBASE_HOME/dbs shell> cp SYS_TBS_MEM_DIC-0-0 SYS_TBS_MEM_DIC-1-0 CONTROL 단계에서 미디어 복구를 수행한다. iSQL(sysdba)> alter database recover database; 복구가 완료된 메모리테이블스페이스에 대해서 안정한(stable) 데이터 파일을 사용하여 불안정한(unstable) 버전을 생성해준다. shell> cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-0; 미디어 복구가 완료되었으므로 자동복구를 수행한다. iSQL(sysdba)> alter database dbname service; 매체복구 사례 8 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 사용자의 실수로 테이블스페이스 USER_DISK_TBS 를 삭제하였다. 삭제 시점은 2007 년 4 월 6 일 22 시 30 분이었다. 테이블스페이스가 존재하는 10 분 전으로 데이터베이스를 복구하려고 한다. 백업 방법 마지막 백업 시 다음과 같이 전체 DB 를 백업하였다. iSQL(sysdba)>alter database backup database to ‘/backup_dir’; 복구 방법 불완전 복구에 필요한 데이터 파일과 로그앵커를 백업 본으로부터 복사한다. 백업 받은 데이터베이의 모든 디스크 테이블스페이스의 데이터 파일들을 원래 위치로 복사를 한다. shell> cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs shell> cp /backup_dir/SYS_TBS_* $ALTIBASE_HOME/dbs 불완전 복구에 필요한 아카이브 로그 파일을 확인한다. 불완전 복구는 백업된 로그앵커 파일을 사용한다. 백업된 저장 장치로부터 로그앵커를 복사한다. 백업 및 복구 445 shell> cp /backup_dir/loganchor* /ALTIBASE_HOME/logs; SYS_TBS_DISK_TEMP 는 백업되지 않기 때문에 해당 파일을 만들어 준다. iSQL(sysdba)> alter database create datafile ‘temp001.dbf’ 불완전 미디어 복구를 수행한다. iSQL(sysdba)> alter database recover database until time '2007-04-06:22:20:00'; 불완전 미디어 복구를 수행하였기 때문에 meta startup 단계로 이전에 resetlogs 를 하여야 한다. iSQL(sysdba)> alter database mydb meta resetlogs; 서버를 구동한다. iSQL(sysdba)> alter database mydb service; resetlogs 를 수행하였기 때문에 전체 데이터베이스의 백업을 수행하는 것이 좋다. iSQL(sysdba)> alter database backup database to ‘/backup_dir’; SQL 튜닝 447 10. SQL 튜닝 본 장에서는 질의 성능을 향상시키기 위한 SQL 튜닝 방법에 대하여 설명한다. 448 ALTIBASE5 Administrator’s Manual SQL 튜닝 개요 SQL 튜닝이란 SQL 문의 성능을 극대화하기 위해 조치하는 모든 일련의 작업을 의미한다. 따라서 SQL 튜닝 방법에는 SQL 문의 변경, 데이터베이스 스키마 변경, 알티베이스 프로퍼티 조정, 운영체제 커널 파라미터 조정 등의 작업들이 포함된다. SQL 튜닝 방법 중 SQL 문의 변경과 데이터베이스 스키마 변경의 경우는 알티베이스의 SQL 문 처리 방법과 제한 사항 등에 의해 영향을 받기 때문에 알티베이스의 SQL 문 처리에 대한 심도 높은 이해가 요구된다. 또한, 메모리 테이블과 디스크 테이블을 모두 사용할 수 있어 저장 매체의 특성에 따른 SQL 처리에 대한 이해가 필요하다. 본 절에서는 간략하게 성능 관련 이슈를 살펴보고 질의 튜닝을 위해 필요한 기본 개념에 대하여 설명한다. 성능 관련 이슈 실행 계획 트리(Execution plan tree) 클라이언트에서 SQL 문의 수행을 요구하면 질의 처리기는 구문 검사, 정당성 검사, 최적화 과정을 거쳐 실행 절차를 정의한 실행 계획 트리를 생성하고, 만약 주언어 변수가 존재하면 바인딩한 후 실행 계획에 따라 데이터베이스에 접근해 레코드를 검색하게 된다. 이러한 SQL 문의 수행 시간 중 대부분은 실행 과정의 시간으로, 복잡한 SQL 문의 경우 실행 계획 트리 구조가 성능의 큰 영향을 끼친다. SQL PLAN CACHE 알티베이스는 세션간에 SQL 구문의 수행 계획을 공유할 수 있다. 이 기능을 사용하면 매번 수행 계획을 만드는 비용을 줄여 성능 향상을 기대할 수 있다. 이 기능을 이용하기 위해서는 SQL PLAN CACHE 관련 프로퍼티인 SQL_PLAN_CACHE_SIZE 의 값을 설정해야 한다. 데이터베이스 스키마와 크기 우선적으로 응용프로그램의 특성 및 자원 활용의 효율에 따라 메모리 테이블 및 디스크 테이블의 사용을 적절히 고려하여야 하며, 일반적으로 자주 사용되는 데이터는 메모리 테이블로 접근 빈도가 낮은 데이터는 디스크 테이블로 관리하는 것이 유리하다. 응용 프로그램에서 사용할 SQL 문의 종류를 고려해 각 SQL 문 별로 테이블에 접근하는 회수, 접근하는 레코드 수 및 디스크 페이지 수가 최소 비용이 되도록 테이블 스키마의 구성과 인덱스 구성에 SQL 튜닝 449 유의해야 한다. 또한, 단순한 SQL 문 또는 레코드 건수가 많은 테이블에 대해서는 술어(predicate) 내 칼럼값의 비교 비용이 성능에 큰 영향을 미치므로 데이터 변환 비용을 최소화하고 비교 비용이 적은 적합한 데이터 타입의 선정이 중요하다. 따라서 가능한 적은 수의 레코드에 접근하도록 SQL 문을 작성하여 절대적 비교 회수를 줄여야 하며, 비교 연산 시 데이터 변환이 일어나지 않도록 칼럼의 데이터 타입과 비교값의 데이터 타입을 잘 선정해야 한다. 응용프로그램 로직(테이블 접근 순서) 만약 여러 클라이언트가 여러 연결을 맺어 많은 세션이 존재할 경우 각 클라이언트의 테이블 접근 순서가 성능에 영향을 미칠 수도 있다. 한 트랜잭션 내에서 DML 문을 여러 개 사용하고 여러 테이블에 접근하는 경우 응용프로그램에서 테이블에 접근하는 순서 등을 잘못 설계할 경우 lock 대기 시간(lock waiting time)으로 인해 전체 응용프로그램 성능이 저하될 수도 있으므로 유의해야 한다. 시스템 리소스 한 SQL문의 질의 처리 시 성능에 영향을 미치는 시스템 리소스는 가 용한 메모리의 크기, 메모리 버퍼의 크기, 디스크 성능과 CPU 성능 이다. 메모리 테이블만을 사용할 경우 검색 질의의 성능이 디스크의 성능에 영향을 받지 않으나, 디스크 테이블의 경우 디스크 성능 및 가용한 메모리 버퍼의 크기에 따라 질의 성능이 영향을 받게 된다. 이러한 점은 메모리 테이블을 사용할 경우 일정한 질의 응답 시간을 기대할 수 있는 반면, 디스크 테이블을 사용할 경우 질의 수행 시점의 환경 에 따라 많은 성능 차이를 보이게 되는 원인이 된다. ORDER BY, GROUP BY 등과 같이 질의 처리기 내에서 질의 처리 를 위해 sorting 기법이나 hashing 기법을 사용하는데 중간 결과를 저장하기 위해 메모리 임시 테이블 또는 디스크 임시 테이블을 사용 하게 된다. 중간 결과를 메모리 임시 테이블에 저장하는 경우, 사용하는 메모리 는 데이터베이스 영역에 잡혀 있는 메모리가 아니기 때문에 이 경우 테이블의 크기가 크다면 많은 메모리가 필요할 수 있으므로 질의 처 리시 메모리 스와핑으로 인한 성능 저하가 생기지 않도록 해야한다. 중간 결과를 디스크 임시 테이블에 저장하는 경우, 사용하는 자원은 디스크 임시 테이블스페이스의 디스크 영역과 메모리 버퍼 영역을 사 용하게 되며 가용한 메모리 버퍼 영역의 크기에 따라 성능에 커다란 영향을 미치게 된다. 450 ALTIBASE5 Administrator’s Manual 또한 질의 처리 작업은 연산자를 처리하기 위한 작업이 많아 CPU 를 많이 사용하게 되므로 CPU 점유율과 성능도 질의 성능에 영향을 많이 미친다. SQL 튜닝 일반 이 절에서는 알티베이스에서 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, INSERT, UPDATE, DELETE 등의 DML 문에 대해서 iSQL 상에서만 확인이 가능하다. DELETE 문과 UPDATE 문, MOVE 문은 SELECT 문 처리와 같은 최적화 과정을 거치므로 실제 내부적으로 같은 실행 계획 트리가 생성된다. 한 테이블에 대하여 하나의 SCAN 노드만 생성되므로 SCAN 노드의 정보에 대한 확인이 가능하다. INSERT 문의 경우 INSERT INTO SELECT 에 대해서 SELECT 문 SQL 튜닝 451 부분에 대한 실행 계획 트리의 확인이 가능하다. 일반적으로 실행 계획 트리에서 확인해야 할 일반적인 내용은 다음과 같으며, 자세한 내용은 다음 절에서 자세히 살펴본다. y 효율적인 액세스 방법을 사용하는가? y 조인 순서 및 방법은 바람직한가? y 적절한 데이터 타입 및 연산을 사용하는가? y 불필요한 hashing 및 sorting을 수행하는가? 질의 튜닝 실행 계획 트리를 통해 성능 저하 요소를 분석한 후 이에 대한 적절한 조치를 취함으로서 성능을 개선할 수 있다. 자세한 질의 튜닝 방법은 질의 최적화 과정 및 질의 실행기에 대한 개념 설명 과정에서 자세히 다룬다. 메모리 테이블과 디스크 테이블 알티베이스는 메모리 테이블과 디스크 테이블을 모두 지원하는 최초의 Hybrid MM DBMS 이다. 따라서, 메모리 테이블과 디스크 테이블에 대한 질의 처리에 대한 기본적인 차이를 이해하는 것은 질의 튜닝에 있어 큰 도움이 된다. 메모리 테이블과 디스크 테이블을 처리하기 위한 질의 처리기의 기본적인 차이는 다음과 같다. Query Processor Item Memory Table Disk Table Executor Object identifier Pointer OID(RID) Buffer management N/A Limited buffer Join methods One-pass algorithms Multi-pass algorithms Optimizer Main cost CPU Disk Index selection Minimize record access Minimize disk I/O Cost factor T(R), V(R.a), etc + B(R), M 참조 T(R): Table R의 레코드 개수, V(R.a): R.a 칼럼의 Value Cardinality B(R): Table R의 디스크 페이지 개수, M: 가용한 메모리 버퍼 개수 질의 처리기는 크게 최적화기(Optimizer)와 실행기(Executor)로 구분할 수 있으며, 최적화기는 비용 계산을 통해 실행 계획 트리를 생성하고 실행 계획 트리는 그 자체가 각각의 기능을 수행하는 실행기이다. 실행기(Executor) 실행기는 테이블의 저장 매체에 따라 위의 표에서와 같이 기본적인 개념 및 그 동작에 있어 차이점이 있다. 452 ALTIBASE5 Administrator’s Manual 먼저 레코드를 구별하는 객체 식별자(Object identifier)는 메모리 테이블의 경우 포인터가 되며 디스크 테이블의 경우 OID(RID)와 같은 특정 디스크 주소로 변환할 수 있는 식별자를 사용하게 된다. 이러한 차이는 레코드 접근에 있어 메모리 테이블은 직접 접근이 가능한 반면 디스크 테이블은 주소 변환에 의한 접근이 필요하다. 메모리 테이블에 대한 질의 처리는 버퍼를 사용하지 않아 이에 대한 고려가 필요없는 반면, 디스크 테이블에 대한 질의 처리는 제한된 메모리 버퍼 내에서 이루어지기 때문에 버퍼에 원하는 레코드가 없을 경우(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 를 발생하여 보다 나은 성능을 보일 수 있기 때문이다. SQL 튜닝 453 최적화기는 비용 계산을 위한 인자로 다양한 통계 정보를 사용하게 된다. 메모리 테이블에 대한 비용 계산에서는 테이블의 레코드 개수[T(R)], 칼럼내에 포함된 서로 다른 값의 개수[V(R.a)], 칼럼의 최소, 최대값 등의 통계 정보가 사용되는 반면, 디스크 테이블에 대한 비용 계산에서는 이 외에도 테이블이 사용하고 있는 디스크 페이지 개수[B(R)], 가용한 메모리 버퍼 페이지 개수[M]등의 추가적인 통계 정보를 이용하여 비용 계산을 하게 된다. 알티베이스의 실행기와 최적화기는 저장 매체의 차이를 충분히 반영 하는 반면, 이에 대한 별도의 구분 없이 실행 계획을 생성하고, 질의 처리시에 그 특성만을 반영하여 수행할 수 있도록 설계되어 있다. 즉, 메모리 테이블과 디스크 테이블의 혼용된 질의 처리에 있어서도 저장 매체의 특성은 충분히 반영하면서 동일한 처리 과정을 따르게 된다. 질의 처리 (Query Processing) 개요 SQL 문의 튜닝 시 항상 모든 응용 프로그램에 적용해 최적의 성능을 발휘하는 절대적인 규칙을 제시하기는 쉽지 않다. 데이터베이스의 설계 또는 응용 프로그램의 비지니스 로직에 따라 각 경우에 적용하는 방법은 매우 다양하다. 따라서 하나의 SQL 문이 어떠한 과정을 거쳐 처리되는지, 성능에 영향을 미치는 요소는 어떠한 것들이 있는지에 대해 설명하고 일반적인 방법론에 대해서만 제시한다. DBMS 에서 SQL 문 처리를 담당하는 모듈을 질의 처리기(Query Processor)라 한다. 질의 처리기는 사용자가 수행을 요구한 SQL 문에 대해 정당성을 검사한 후 데이터베이스에 접근하는 최적의 접근 순서와 방법을 결정하고, 이에 따라 조건에 맞는 레코드를 검색한 후 필요한 연산을 수행하여 클라이언트에게 처리한 값을 돌려주는 모듈이다. 질의 처리수행 과정을 개략적으로 도식화하면 다음과 같다. 454 ALTIBASE5 Administrator’s Manual Server Parsing Validation Optimization Binding Execution Database Client Prepare Bind Execute Fetch [그림 10-1] Query Processing 순서 각 단계별 처리 내용은 다음과 같다. 13. 구문 분석(Parsing): SQL 문 텍스트 문법 검사(syntax 검사)하 고 구문 분석 정보를 저장하는 파스 트리(Parse Tree) 생성한다. 14. 정당성 검사(Validation): SQL 문 의미상 정당성 검사(semantic 검사)하고 메타 테이블 검색하여 파스 트리 확장한다. 15. 최적화(Optimization): 주어진 파스 트리를 다양한 통계 정보와 접근 비용 계산을 통해 최적화된 실행 계획을 생성한다. 16. 바인딩(Binding): 주언어 변수값(host variable value) 을 생성 된 실행 계획에 연결한다. 17. 실행(Execution): 실행 계획 트리에 따라 SQL 문 실행한다. 질의를 튜닝하기 위해 알티베이스의 질의 최적화와 질의 실행 과정을 이해하는 것은 매우 중요하다. 다음 장에서 이를 기반으로 한 질의 튜닝 방법에 대하여 자세히 알아본다. SQL 튜닝 455 질의 최적화 과정 질의 최적화(optimization) 과정은 주어진 SQL 을 분석하여 가능한 실행 계획을 작성하고 이에 대한 비용 평가를 통해 가장 효율적인 실행 계획을 선택하는 과정이다. 질의 성능의 대부분이 이 과정에서 결정되며, 복잡한 질의일수록 질의 최적화 과정의 정확성에 의해서 성능이 좌우된다. 질의 최적화 개요 Optimizer 의 구조 Optimizer 는 주어진 질의문을 구문 분석(parsing), 의미 분석(validation) 과정을 거쳐 생성된 파싱 트리를 각종 비용 평가를 통해 효율적인 실행 계획 트리(plan tree)을 생성한다. 이러한 과정을 수행하는 optimizer 의 구조는 다음과 같다. Graph (Logical Operator) Parse Tree Plan Tree (Physical Operator) Optimizer Graph Manager Plan tree Manager Predicate Manager [그림 10-2] Query Processing 순서 Optimizer 는 크게 그래프 관리자, 실행 계획 관리자, Predicate 관리자로 구성된다. Optimizer 의 각 관리자가 하는 역할은 다음과 같다. 그래프 관리자는 주어진 파싱 트리를 이용하여 논리 연산자인 그래프를 생성하고 해당 그래프에 대한 비용을 계산하여 최적화 방법을 결정한다. 실행계획 관리자는 생성된 그래프를 이용하여 주어진 최적화 방법에 따라 실행 계획 트리를 생성한다. Predicate 관리자는 그래프 관리자와 실행 계획 관리자가 실행 계획 트리를 결정하고 생성하기 위해 필요한 정보를 제공한다. 그래프(논리 연산자)의 종류 그래프 관리자는 효율적으로 파싱 트리를 분석하고 실행 계획 456 ALTIBASE5 Administrator’s Manual 트리를 생성하기 위해 중간 단계인 그래프를 생성하여 처리한다. 그래프는 총 12 개로 구성되어 있으며 주요 그래프와 그 역할은 다음과 같다. 구분 그래프 기능 관련 SQL 구문 Critical path Selection 단일 테이블에 대한 접근 방법 FROM, WHERE Join 조인의 수행 순서 및 방법 FROM, WHERE Non critical path Grouping 그룹 연산의 수행 방법 GROUP BY, HAVING, aggregation 연산 Distinction 중복 제거의 수행 방법 DISTINCT Set 집합 연산의 수행 방법 UNION, UNION ALL, INTERSECT, MINUS Sorting 정렬 연산의 수행 방법 ORDER BY Projection 프로젝션 연산의 수행 방법 SELECT [표 10-1] 그래프의 종류 최적화기의 관점에서 검색 질의 성능에 가장 큰 영향을 미치는 부분은 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 는 기본적인 통계 정보뿐 아니라 최적화 과정을 통해 새로운 정보를 추정하고 비용 계산을 통해 다양한 예측 정보를 산출해낸다. 기호 설명 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 메모리 버퍼의 페이지 개수 [표 10-2] 실시간 통계 정보 SQL 튜닝 457 위와 같은 실시간 통계 정보는 데이터의 변경이 발생 할 때마다 별도의 부하 없이 변경되며, 사용자의 개입 없이 비교적 정확한 정보를 관리한다. Optimizer 는 이러한 실시간 통계 정보를 사용하기 때문에 다양한 실행 계획들에 대한 비용 평가가 가능하며 효율적인 실행 계획을 생성할 수 있다. 그러나, 통계 정보가 모든 질의를 위한 충분한 정보가 될 수 없으며, Optimizer 가 모든 환경에서 항상 효율적인 실행 계획을 생성할 수 있는 것은 아니다. 따라서, 특정 질의의 경우 사용자가 성능 향상을 위한 작업이 필요할 수 있으며 이를 위해서는 알티베이스 질의 최적화 개념을 이해하는 것이 매우 중요하다. 질의 최적화 과정 알티베이스의 optimizer 는 성능에 가장 큰 영향을 미치는 critical path 에 대한 최적화 방법을 우선적으로 결정하고, 이 후에 non- critical path 를 처리하는 bottom-up 방식의 최적화 순서를 따르고 있다. Critical path 에 대한 실행 방법을 결정하기 위한 최적화 과정은 다음과 같다. y 정규화: 사용자가 정의한 WHERE 절을 CNF와 DNF로 두 가지의 정규화된 형태로 변형한다. y 각 정규화된 형태의 조건절을 이용하여 critical path에 대한 비용을 결정하고 이를 비교하여 critical path의 실행 계획을 결정한다. CNF와 DNF에 대한 처리는 동일한 과정을 거치며 다음과 같은 단계로 처리된다. y 조건절의 분류: 정규화된 조건절을 하나의 테이블에 관계된 조건과 두 개 이상의 테이블이 관계된 조건으로 분류한다. y 액세스 방법 결정: 우선적으로 각 테이블에 대한 조건절을 기준으로 비용이 가장 적은 인덱스 선택 등의 액세스 방법을 결정한다. 여기서 선택된 액세스 방법은 조인 과정을 통해 재조정된다. y 조인 순서의 결정: 복잡한 질의 처리 과정에서 조인의 순서는 질의 성능에 가장 큰 영향을 미치는 요소이며 이는 join greedy algorithm을 통해 결정된다. y 조인 방법의 결정: 조인 순서의 결정 후 각 조인 순서별로 최적의 조인 방법을 선택한다. Non-critical path 의 실행 방법을 결정하는 최적화 과정은 critical path 에 대한 최적화 이후에 수행되며 그 과정은 다음과 같다. y 그룹 연산의 수행 방법 결정: 질의에 GROUP BY, HAVING, aggregation 연산이 포함되어 있을 경우 이를 처리하기 위한 수행 방법을 결정한다. y DISTINCT의 수행 방법 결정: 질의에 DISTINCT 가 포함되어 있을 경우 이를 처리하기 위한 수행 방법을 결정한다. 458 ALTIBASE5 Administrator’s Manual y SET의 수행 방법 결정: 질의에 UNION, UNION ALL, INTERSECT, MINUS 등이 있을 경우 이를 처리하기 위한 수행 방법을 결정한다. y ORDER BY의 수행 방법 결정: 질의에 ORDER BY가 포함되어 있을 경우 이를 처리하기 위한 수행 방법을 결정한다. y 프로젝션의 수행 방법 결정: SELECT 구문에 포함되어 있는 칼럼 등을 프로젝션하기 위한 수행 방법을 결정한다. Subquery내에 존재하는 SELECT 구문인 경우 다양한 최적화 방법들이 사용될 수 있다. 위의 질의 최적화 과정의 순서대로 각 과정을 보다 상세히 살펴보고 이를 통해 SQL 튜닝을 위한 방법을 설명한다. 정규화 정규화의 개념 사용자가 작성한 WHERE 의 조건절은 매우 다양한 형태로 표현된다. Optimizer 는 다양한 조건 처리를 일관적이고 효율적인 방법으로 처리하기 위해 사용자가 정의한 WHERE 절을 정형화된 형태로 변경하며 이러한 과정을 정규화라고 한다. 정규화는 AND, OR, NOT 등의 논리식을 기준으로 조건절을 확장하고 변형하는 과정이며, AND 를 최상위 논리식으로 표현하는 방법을 CNF(Conjunctive Normal Form)이라 하며, OR 를 최상위 논리식으로 표현하는 방법을 DNF(Disjunctive Normal Form)이라 한다. CNF 정규화는 주어진 조건절을 AND 를 최상위로 하여 하위에 OR 논리 연산자를 구성되도록 재배치하는 것이다. 예를 들어, 다음과 같은 조건절은 CNF 로 정규화 시 다음과 같은 구조로 변경된다. y WHERE (i1 = 1 AND i2 = 1) OR i3 = 1 y CNF: (i1 = 1 OR i3 = 1) AND (i2 = 1 OR i3 = 1) DNF 정규화는 주어진 조건절을 OR 를 최상위로 하여 하위에 AND 논리 연산자로만 재구성되도록 재배치하는 과정이다. 예를 들어, 다음과 같은 조건절은 DNF 로 정규화 시 다음과 같은 구조로 변경된다. y WHERE (i1 = 1 OR i2 = 1) AND i3 = 1 y DNF: (i1 = 1 AND i3 = 1) OR (i2 = 1 AND i3 = 1) 즉, optimizer 는 주어진 조건절을 CNF 로 구성했을 때의 실행 비용과, DNF 로 구성했을 때의 실행 비용을 비교하여 보다 나은 정규화 형태를 선택하게 된다. SQL 튜닝 459 일반적으로 optimizer 에 의해 선택되는 실행 계획은 CNF 를 기준으로 선택되며, 일부의 경우 DNF 로 선택된 실행 계획을 선택한다. 예를 들어, 다음과 같은 질의를 살펴보자. y SELECT * FROM T1 WHERE i1 = 1 OR i2 = 1; y CNF 정규화: AND (i1 = 1 OR i2 = 1) y 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 로만 동작하게 할 수 있다. y WHERE i1 = 1 OR i1 = 2 OR i1 = 3 y CNF 정규화: i1 IN (1, 2, 3) 유사한 예로 다음과 같은 질의는 CNF 또는 DNF 로의 질의 변형을 통해 불필요한 정규화 과정을 제거하고 동일한 조건 비교를 방지하여 성능을 향상할 수 있다. y WHERE (i1 = 1 AND i2 = 1) OR (i1 = 2 AND i2 = 2) y CNF 정규화: (i1, i2) IN ( (1,1), (2,2) ) y WHERE (i1 = 1 AND i2 = 1) OR ( i3 = 1 AND i4 = 1) y DNF 정규화: (i1, i2) = (1, 1) OR (i3, i4) = (1, 1) 물론 정규화 형태의 기술 시 테이블의 인덱스 정보 등을 반드시 고려하여야 한다. 사용자가 정규화 형태로 기술하였다 하더라도 optimizer 에 의해 원하지 않는 정규화 형태가 선택될 수 있으며, 이러한 경우 힌트를 통해 제어할 수 있다. 이는 힌트에 대한 설명 과정에서 자세히 다룬다. 460 ALTIBASE5 Administrator’s Manual 조건절의 분류 조건절의 구분 WHERE 절에 기술된 조건절은 정규화를 통해 일관된 형태로 변경되고 optimizer 는 조건절을 이용한 critical path 의 효율적 처리를 위해 각 조건을 분류한다. 조건절은 다음과 같이 크게 세 가지로 구분할 수 있다. y 한 테이블에만 관련된 조건: T1.i1 = 1 과 같이 하나의 테이블에만 관련된 조건 y 여러 테이블과 관련된 조건: T1.i1= T2.i1 또는 T1.i1 + T2.i1 > 0 과 같이 두 개 이상의 테이블과 관련된 조건 y 테이블과 관련 없는 조건: 1 = 1 또는 1 = ? 과 같은 테이블의 레코드와 관련이 없는 조건 이렇게 분류된 조건절은 액세스 방법의 선택, 조인 순서 및 조인 방법의 결정을 위해 사용되며 조건절의 적절한 기술은 SQL 튜닝의 가장 중요한 요소이다. Constant Filter 의 활용 1 = 1 또는 1 1 과 같이 테이블이 소유한 값에 관계 없이 항상 TRUE 또는 FALSE 를 결정하는 조건을 constant filter 라 한다. Constant filter 는 항상 같은 논리값을 갖기 때문에 질의 수행 과정에서 한 번만 비교하고 추가적인 비교 연산 비용이 소요되지 않는다. 즉, constant filter 의 논리값이 FALSE 인 경우에는 어떠한 검사도 추가적으로 발생하지 않으며, 테이블에 접근할 필요도 없다. 무의미해 보이는 constant filter 도 다음과 같이 매우 다양한 용도로 활용할 수 있다. 그 예로 Schema 만 구성하고 데이터는 구축하지 않고 싶은 경우에 constant filter 를 활용할 수 있다. 예를 들어 다음과 같은 질의가 이에 해당하는 예이다. CREATE TABLE T3 AS SELECT * FROM T1, T2 WHERE 1 1; 위와 같이 T1 과 T2 테이블의 모든 칼럼 정보를 가진 T3 테이블을 만들고 싶을 경우 constant filter 를 사용하면 T1, T2 의 데이터양에 관계 없이 원하는 작업을 수행할 수 있다. 또한, 다음 예와 같이 검색 권한을 제한하는 용도로 활용할 수 있다. SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND ? > 20; 위와 같이 나이값에 해당하는 호스트 변수를 지정하여 조건에 부합하지 않는 사용자가 질의 내용을 수행하거나 결과값이 없는 질의의 수행으로 인한 부하 등을 방지할 수 있다. SQL 튜닝 461 이 외에도 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 의 가장 일반적인 형태는 위에서 기술한 바와 같이 조건절을 분류하여 해당 테이블에 속하는 조건을 먼저 검사하도록 하는 것이 대표적인 형태이다. 예를 들어, 다음과 같은 질의를 살펴 보자. SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND T1.i2 = abc; 위의 질의에서 해당 조건절은 다양한 실행 계획의 생성이 가능하다. 즉, T1, T2 를 모두 조합한 후에 조건절을 비교할 수도 있으며, T1 테이블에 대한 조건을 이용하여 T1 의 결과 집합을 줄인 후에 조인을 수행하여 처리할 수 있다. 이와 같이 WHERE 절의 조건을 가능한 조인이 수행되기 전에 처리하도록 하는 것이 push selection 의 가장 일반적인 형태이다. Optimizer 는 비용 비교 및 수학적 일치성 등을 고려하여 push selection 의 다양한 형태를 고려하게 된다. Optimizer 에서 사용하는 대표적인 push selection 은 다음과 같은 기법들이 있다. y 뷰에 대한 push selection y Outer 조인에 대한 push selection y 조인에 대한 push selection 위 기법들의 개념과 이를 활용한 SQL 튜닝 방법에 대하여 알아 보자. 뷰에 대한 push selection 뷰에 대한 push selection 기법은 사용자가 정의한 뷰에 대하여 462 ALTIBASE5 Administrator’s Manual 질의를 수행 시 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 기법이다. 이는 뷰가 하나의 질의에서 반복해서 사용될 때 뷰의 결과를 질의 처리 과정 중에 임시로 저장하여 처리하는 기법이다. 예를 들어 다음과 같은 뷰의 정의와 관련 질의 예를 살펴 보자 CREATE VIEW V1(a1, a2) AS SELECT i1, SUM(i2) FROM T1 GROUP BY i1; SELECT * FROM V1 WHERE V1.a2 > (SELECT AVG(a2) FROM V1 WHERE a1 > 10 ); 위와 같은 질의에 대하여 view materialization 기법이 적용되면, V1 의 결과를 임시로 저장한 후 최상위의 질의와 subquery 가 함께 사용하게 된다. 즉, V1 의 결과를 얻기 위하여 뷰 내부의 질의를 반복하여 수행하지 않는 효과를 얻게 된다. 이러한 질의에 대하여 뷰에 대한 push selection 기법을 적용하도록 힌트를 주게 되면 오히려 느린 성능을 얻을 수도 있으므로 올바른 판단이 필요하다. Outer Join 에 대한 push selection SQL 튜닝 463 FROM 절에 outer join 이 사용될 경우 다양한 형태의 push selection 이 가능하다. 즉, WHERE 절에 기술된 조건을 outer join 의 조인 처리 이전에 수행되게 하는 기법이다. 예를 들어 다음과 같은 질의를 살펴 보자 SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 WHERE T1.i1 = 1; 위 질의는 push selection 기법이 적용될 경우 다음과 같은 개념의 질의 형태로 처리되게 된다. SELECT * FROM (SELECT * FROM T1 WHERE T1.i1 = 1) T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1; 즉, left outer join 에 대한 조인 조건을 처리하기 전에 T1.i1 = 1 조건을 미리 처리하여 T1 의 결과 집합을 줄이는 방법이다. 이러한 기법 역시 수학적 동치 여부 및 비용 평가를 통해 적용 여부가 결정된다. 예를 들어 다음과 같은 세 질의는 경우에 따라 서로 다른 결과를 생성하며, 동일한 질의가 아니다. SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 WHERE T2.a1 = 1; SELECT * FROM T1 LEFT OUTER JOIN (SELECT * FROM T2 WHERE T2.a1 = 1) T2 ON T1.i1 = T2.a1; SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 AND T2.a1 = 1; Optimizer 는 수학적 동치인 상태에서 동일한 결과를 얻기 위해서 위의 질의를 다음과 같은 형태로 push selection 을 적용한다. SELECT * FROM T1 LEFT OUTER JOIN (SELECT * FROM T2 WHERE T2.a1 = 1) T2 ON T1.i1 = T2.a1 WHERE T2.a1 = 1; 참고로, Left outer join 의 경우 WHERE 조건을 ON 절에 옮겨 처리하고 싶다면 다음과 같이 WHERE 절에 반드시 남겨 두어야 동일한 결과를 보장받을 수 있다. SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 AND T2.a1 = 1 WHERE T2.a1 = 1; 위의 최적화 기법을 보면, 사용자는 optimizer 가 outer join 에 대하여 push selection 을 적용하지 않더라도 임의로 질의 조건의 추가를 통해 유사한 효과를 기대할 수 있다. 물론, 조건 추가를 통해 동일한 결과를 얻음과 동시에 성능을 향상시킬 수 있음을 판단하는 것이 매우 중요하다. 조인에 대한 push selection 조인에 대한 push selection 기법은 조인 조건과 단일 테이블 조건이 존재할 때 유사한 단일 테이블 조건을 추가하여 성능을 464 ALTIBASE5 Administrator’s Manual 향상시키는 기법이다. 예를 들어 다음과 같은 질의를 살펴보자 SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND T1.i1 = 1; 해당 질의를 처리하기 위해 어떠한 인덱스도 사용할 수 없을 경우 다음과 같이 유사한 단일 테이블 조건을 추가하는 것은 많은 경우에 성능 향상에 도움이 된다. SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND T1.i1 = 1 AND T2.a1 = 1; 즉, T2 의 결과 집합의 개수를 줄임으로서 성능을 향상시킬 수 있다. 이러한 조인에 대한 push selection 기법은 특히 집합 연산을 통해 생성된 뷰에 대하여 처리할 때 매우 효과적이다. 예를 들어 다음과 같은 뷰와 이를 이용한 질의를 살펴 보자. CREATE VIEW V1(a1, a2) AS ( SELECT m1, m2 FROM T2 UNION AL SELECT x1, y1 FROM T3 ); SELECT * FROM T1, V1 WHERE T1.i1 = V1.a1 AND T1.i1 = 1; 위의 뷰 정의에서 T2.m1 과 T3.x1 칼럼에 모두 인덱스가 있다고 해도 해당 질의를 수행할 때 인덱스가 사용될 수 없다. 이 때 조인에 대한 push selection 기법을 적용하여 질의를 변경할 경우 다음과 같은 효과를 얻을 수 있다. SELECT * FROM T1, V1 WHERE T1.i1 = V1.a1 AND T1.i1 = 1 AND V1.a1 = 1; 위와 같이 기술된 질의는 뷰에 대한 push selection 과 집합에 대한 push selection 기법이 적용되어 다음과 같이 T2.m1 과 T3.x1 칼럼의 인덱스를 모두 사용할 수 있게 된다. 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 튜닝에 있어 가장 SQL 튜닝 465 중요하다고 할 수 있다. 조건절의 처리 유형 Optimizer 는 정규화와 조건절의 분류 과정을 통해 구분된 조건들을 기준으로 해당 테이블의 액세스 방법 및 조건의 처리 방법을 결정하게 된다. 조건절의 처리 순서 및 처리 방법에 따라 분류하면 다음과 같다. 분류 처리 순서 설명 예제 Key Range 2 인덱스를 사용하여 범위 검색이 가능한 조건 T1.i1 > 1 Key Filter 3 범위 검색은 안되나 인덱스의 키 값을 비교하여 검사가 가능한 조건 T1.i2 = 1 Constant Filter 1 테이블의 데이터와 관계 없이 한 번의 검사만으로 판단이 가능한 조건 ? = 1 Filter 4 데이터에 대한 직접적인 비교가 필요한 조건 T1.i4 = abc Subquery filter 5 Subquery를 포함하고 있는 조건 EXISTS () 예제 Index on T1(i1, i2, i3) 질의: SELECT * FROM T1 WHERE ? = 1 AND i1 > 1 AND i2 = 2 AND i4 = abc AND EXISTS ( SELECT * FROM T2 WHERE T2.a1 = T1.i3 ); [표 10-3] 조건절의 처리 위의 표에서 보는 바와 같이 모든 조건들은 다섯 가지 형태의 처리 방법에 의해 처리되게 된다. Key range 처리 방법은 해당 조건을 인덱스를 이용하여 조건에 부합하는 범위 검색에 의해 데이터를 검색하는 방법이다. 즉, 조건을 만족하는 최소값의 위치와 최대값의 위치만을 결정하고 해당 조건에 대한 별도의 비교 없이 해당 범위 내의 모든 데이터를 검사하게 된다. 따라서, 조건 비교 시 데이터에 대한 별도의 비교 연산이 필요 없어 매우 우수한 성능을 보장할 수 있다. Key filter 처리 방법은 인덱스를 이용하여 범위 검색은 할 수 없으나, 인덱스에 저장되어 있는 키값을 이용하여 비교 연산을 수행하는 방법이다. 즉, 인덱스를 저장하고 있는 페이지만을 접근하여 비교함으로서 데이터 페이지에 대한 접근 횟수를 줄여 성능을 향상시킬 수 있다. 이는 디스크 테이블의 인덱스에 대해서만 유효하며, 메모리 테이블의 인덱스의 경우 별도로 키값을 저장하지 않고 있어 filter 처리 방법과 비교하여 성능 향상 효과가 없다. Constant 처리 방법은 앞에서 살펴보았듯이 모든 조건에 우선하여 한 번만 처리하며, 논리값이 FALSE 인 경우 별도의 데이터 검색이 466 ALTIBASE5 Administrator’s Manual 필요 없다. Filter 처리 방법은 인덱스를 사용할 수 없는 일반적인 조건에 대한 비교 방법으로 데이터를 직접 읽어 비교 연산을 수행한다. Optimizer 는 여러 filter 에 대하여 처리 예상 비용을 비교하여 가장 비용이 적은 filter 를 우선적으로 처리하여 비교 비용을 최소화할 수 있도록 filter 의 처리 순서를 결정한다. Subquery filter 는 일반적으로 가장 많은 비용이 드는 비교 연산이며 모든 조건 비교가 완료된 후 마지막에 수행된다. Optimizer 는 이러한 Subquery filter 에 대하여 다양한 최적화 기법을 적용하여 성능 향상을 꾀하며, 이에 대해서는 이후의 Subquery 처리 과정에서 자세히 다룬다. 인덱스 생성 시 고려 사항 주어진 조건절을 처리하기 위한 가장 효율적인 key range 검색을 하기 위해서는 인덱스가 있어야 한다. 그러나, 인덱스를 생성하기 위해서는 다음과 같은 사항을 반드시 고려하여야 한다. 인덱스의 생성이 검색 연산의 성능을 향상시킬 수는 있으나, 인덱스를 관리하기 위한 저장 공간이 필요하여 시스템 자원을 소모한다. 또한, 과도한 인덱스의 생성은 삽입, 삭제, 갱신의 발생시 관련 인덱스의 정보를 유지하기 위한 비용으로 성능 저하를 유발할 수도 있다. 메모리 테이블의 경우 거의 모든 질의 처리에 있어 인덱스를 이용한 검색 방법이 테이블에 대한 전체 스캔보다 우수한 성능을 보인다. 그러나, 디스크 테이블의 경우 인덱스 스캔이 전체 스캔보다 반드시 효과적인 것은 아니다. 이는 전체 스캔이 데이터 페이지를 접근하는 패턴이 일정한 반면, 인덱스 스캔은 그 패턴이 일정하지 않아 경우에 따라 과도한 Disk I/O 를 유발할 수 있기 때문이다. 일반적으로 디스크 테이블의 경우 인덱스 스캔을 이용한 검색이 테이블의 전체 레코드 중 1/10 이하이거나 아주 적은 레코드만을 선택하는 경우에 한해 인덱스를 생성할 것을 권고하고 있다. 즉, 인덱스를 생성할 경우에는 질의의 사용 빈도, 인덱스 사용으로 인한 성능 향상 효과, 전체 시스템 자원, 갱신 질의의 성능 저하 정도를 고려하여야 한다. Optimizer 의 인덱스 선택 Optimizer 는 주어진 조건과 해당 테이블의 인덱스를 이용하여 가장 효율적인 액세스 방법을 결정한다. 이 과정에서 다양한 통계 정보를 이용하여 인덱스의 사용에 따른 비용 평가를 하며, 이 중 가장 효율적인 액세스 방법을 선택한다. 액세스 방법이 결정되면 모든 조건들에 대하여 key range 처리, SQL 튜닝 467 filter 처리 등의 처리 방법을 결정한다. Optimizer 가 액세스 방법에 대한 비용 계산을 위한 개략적인 개념은 다음과 같다. Access cost + Disk I/O cost Ful scan : T(R) Index Scan : log(T(R) + T(R) * MAX(1/V(Index), selectivity) Aces cost 계산의 개념 Ful 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 라 한다. 조건의 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 칼럼의 인덱스를 사용하는 것이 보다 효율적인 액세스 선택이 된다. 위와 같은 개념의 액세스 선택 방법이 보편적으로 올바른 실행 계획을 작성한다. 그러나 이 역시 비용 계산에 의한 선택이기 때문에 모든 상황에 있어 항상 좋은 액세스 방법이 선택되지는 않는다. 예를 들어, 다음과 같은 질의를 468 ALTIBASE5 Administrator’s Manual 살펴 보자. 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) 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 SQL 튜닝 469 검색을 할 수 있는 조건의 범위를 결정할 수 있다. 예를 들어 다음과 같은 질의가 빈번하게 사용되어 인덱스를 추가하려고 한다면 인덱스를 최대한 활용할 수 있도록 생성하는 것이 바람직하다. WHERE i1 > 0 AND i2 = 1 y 바람직한 인덱스: Index on T1(i2, i1) y 부적절한 인덱스: Index on T1(i1, i2) 인덱스와 비교 연산자 인덱스가 존재하고 해당 칼럼에 대한 조건이 존재한다고 해서 반드시 인덱스를 사용할 수 있는 것은 아니다. 즉, 조건절의 기술 형태와 비교 연산자의 종류에 따라 인덱스의 사용 가능 여부가 결정되므로 이에 대한 주의가 필요하다. 470 ALTIBASE5 Administrator’s Manual 비교 연산자의 종류와 인덱스 사용 가능 여부는 다음과 같다. 분류 비교 연산자가능여부비고 단순 비교 = O != O O >= O 범위 비교 BETWEEN O NOT BETWEEN O 멤버 비교 IN O NOT IN O 패턴 비교 LIKE O 가능: T1.i1 LIKE abc% 불가: T1.i1 LIKE %abc NOT LIKE X NULL 비 교 IS NULL O IS NOT NUL O 존재 비교 EXISTS X NOT EXISTS X UNIQUE X NOT UNIQUE X Quantify ANY =ANY O !=ANY O ANY O >=ANY O Quantify ALL =ALL O != ALL O ALL O >= ALL O [표 10-4] 비교 연산자에 따른 인덱스 사용 여부 SQL 튜닝 471 Geometry 관련 비교 연산자는 다음과 같으며, R-Tree 인덱스가 존재하는 경우에만 인덱스를 사용할 수 있다. 분류 비교 연산자 가능여부비고 Geometry 비교 CONTAINS O R-Tree index only CROSSES O DISJOINT O DISTANCE O EQUALS O INTERSECTS O ISEMPTY X ISSIMPLE X NOT CONTAINS X NOT CROSSES X NOT EQUALS X NOT OVERLAPS X NOT RELATE X NOT TOUCHES X NOT WITHIN X OVERLAPS O RELATE X TOUCHES O WITHIN O [표 10-5] Geometry 비교 연산자 사용 여부 위와 같이 인덱스가 존재하고 인덱스를 사용할 수 있는 비교 연산자라 하더라도 항상 인덱스를 사용할 수 있는 것은 아니다. 즉, 조건절의 형태에 따라 인덱스의 사용 가능 여부가 결정되며, 인덱스를 사용할 수 있는 조건절의 형태는 다음과 같다. (단, 조건절의 예제는 해당 칼럼이 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 [표 10-6] 조건절에 따른 인덱스 사용 여부 위와 같이 인덱스를 사용하기 위해서는 조건절의 기술에 주의를 472 ALTIBASE5 Administrator’s Manual 기울여야 하며, 특히 칼럼의 값이 연산이 필요하거나 변경이 발생하지 않도록 주의하여야 한다. 인덱스 사용을 고려한 데이터 타입과 데이터 변환에 대한 설명은 다음에서 자세히 설명한다. 인덱스와 데이터 타입 WHERE 절의 칼럼에 인덱스가 생성되어 있다고 해서 항상 인덱스 스캔이 가능한 것은 아니다. 데이터 타입과 데이터 변환에 따라 인덱스 스캔이 가능한 경우도 있고 그렇지 못한 경우도 있다. SELECT * FROM T1 WHERE T1.i1 = ? 위의 질의에서 i1 칼럼이 VARCHAR 타입이고 PRIMARY KEY 인 경우, iSQL 로 실행 계획을 확인하면 인덱스 스캔 가능으로 나타난다. 하지만 실제 변수를 바인딩할 때 INTEGER 등의 숫자형으로 바인딩을 하는 경우 칼럼 값을 숫자형으로 변환하여 비교해야 하므로 인덱스 스캔이 불가능하다. 따라서, iSQL 에서 인덱스 스캔으로 수행되는 질의인지 확인하고, 실행 계획이 인덱스 스캔이 가능한 것으로 표시되는 경우에도 실제 응용 프로그램에서 바인딩하는 값과 칼럼의 데이터 타입을 확인해야 한다. 그렇지 않으면 응용 프로그램에서는 전체 테이블을 스캔(full scan)하여 iSQL 상에서의 실행 속도에 비해 현격한 속도 차이가 날 수도 있으므로 주의해야 한다. 데이터 타입과 인덱스 사용 가능 여부는 다음과 같다. 검은 부분으로 표시되는 부분은 비교연산 수행시, 키 칼럼에 변환이 발생하게 된다. VALUE KEY CHAR VARCHAR SMALLINT INTEGER BIGINT NUMERIC FLOAT REAL DOUBLE DATE BLOB NIBBLE BYTE GEOMETR Y 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 OOOOOO - - - - - INTEGER X X O OOOOOO - - - - - BIGINT X X O O O OOOO - - - - - NUMERIC O O O OOOO OO - - - - - FLO A T O O O O OOO OO - - - - - REAL X X O OOOOO O - - - - - DOUBLE O O O OOOOOO- - - - - D A T E O O - - - - - - - O - - - - BLOB - - - - - - - - - - O - - - NIBBLE - - - - - - - - - - - O - - BYTE - - - - - - - - - - - - O - SQL 튜닝 473 GEOMETRY- - - - - - - - - - - - - O [ 표 10-7] 데이터 타입에 따른 인덱스 사용 여부 데이터 타입은 다음과 같이 크게 문자형 계열과 숫자형 계열로 구분할 수 있으며, 각 계열에 속하는 데이터 타입들간의 비교는 모두 인덱스를 사용할 수 있다. 문자형 계열 CHAR, VARCHAR 숫자형 계열 Native 정수형 BIGINT, INTEGER, SMALLINT 실수형 DOUBLE, REAL Non-Native (지수형) 고정 소수점형 NUMERIC, DECIMAL, NUMBER(p), NUMBER(p,s) 부동 소수점형 FLOAT, NUMBER 즉, 문자형 계열에 속하는 CHAR, VARCHAR 간의 비교, 숫자형 계열에 속하는 정수형, 실수형, 지수형간의 비교시에는 모두 인덱스 사용이 가능하다. y 문자형 계열 char_column = VARCHARabc varchar_column = CHARabc y 숫자형 계열 integer_column = DOUBLE1 number_column = DOUBLE1 integer_column = NUMBER1 숫자형 계열의 서로 다른 데이터 타입간 비교 연산에 대해서는 conversion matrix 에 의하여 다음과 같은 기준으로 비교하게 된다. 정수형 실수형 지수형 정수형 정수형 실수형 지수형 실수형 실수형 실수형 실수형 지수형 지수형 실수형 지수형 인덱스 칼럼에 변환이 존재하는 경우가 이에 해당되며, 인덱스에 변환이 발생하는 경우라 하더라도, 이 비교 기준에 의해 내부적으로 인덱스 칼럼의 변환된 값으로 비교연산을 수행하게 된다. 그러므로, bigint_col = NUMERIC1 과 같이 칼럼에 변환이 발생하는 index scan 은 bigint_col = BIGINT1 과 같이 칼럼에 변환이 발생하지 않는 index scan 보다 수행속도가 느리게 된다. 이 외에 인덱스 스캔과 별도로 두 값을 비교하는 비교 연산자의 수행 성능은 비교 대상 데이터 타입의 종류와 밀접한 관계가 있다. 같은 데이터 타입간의 비교일 경우에는 데이터 변환 비용이 474 ALTIBASE5 Administrator’s Manual 없으므로 최적의 성능을 발휘하겠지만 서로 다른 데이터 타입간의 비교라면 데이터 변환을 최소화하도록 해야 한다. 예를 들어 숫자형 타입과 문자형 타입을 비교할 경우 데이터 변환 비용만 고려한다면 FLOAT 과 VARCHAR 인 경우 가장 짧은 변환 패스를 가진다. 그러나 데이터 타입별로 데이터 저장 크기와 형식에 차이가 있으므로 이를 종합적으로 고려해 데이터 타입을 결정해야 한다. 다음은 데이터 타입 변환 패스를 도식화한 그림이다. SMALLINT BIGINT INTEGER REAL DOUBLE NUMERICFLOAT INTERVAL CHARVARCHAR DATE NULLALL <0+0+0><0+E+L> <0+E+0> <0+0+0> <0+E+0> <0+0+L> <0+E+0><0+0+L> <0+E+L> <0+E+0> <0+0+0> <0+0+0> <0+E+L> <0+0+0> <0+0+0> <0+0+0> <0+0+L> <0+0+L> AB A 와 C 를 비교하는 경우 항상 A가 C로 변환되거나 C가 A로 변환되는 것은 아니다. 연산자에 따라 A가 C로 변할 수도 있고, 그 반대인 경우도 있으며, A가 B로 변환되고 C가 B로 변환되어 연산을 수행하는 경우도 있다. C AB A 타입에서 B 타입으로 데이터 타입 변환 가능 G : Group Penalty E : Error Penalty G >> E >> L L : Loss Penalty [그림 10-3] 데이터변환 타입 패스 위와 같이 인덱스를 사용할 수 있도록 조건절을 기술하는 것은 매우 중요하며, 조건절의 유형에 따라 성능에 영향을 미칠 수 있으므로 WHERE 절의 기술 및 응용 프로그램의 작성 시 주의를 기울여야 한다. SQL 튜닝 475 Optimizer 가 개별 테이블에 대한 액세스 방법의 결정이 완료되면, 조인에 대한 처리를 수행하게 된다. 이 때, 개별 테이블에 대하여 결정된 액세스 방법은 절대적인 것이 아니며, 조인 처리 과정에서 재조정하게 된다. 조인 순서의 결정 복잡한 질의의 경우 조인의 순서 및 조인의 처리 방법은 질의 성능에 가장 큰 영향을 미치게 된다. 따라서, 적절한 조인 순서와 조인 방법이 선택되었는지를 판단하고 조정하는 것은 질의 성능 향상에 도움이 된다. Optimizer 는 조인을 처리하기 위하여 다음과 같은 단계를 따른다. 18. 조인 조건을 이용한 조인의 그룹화 19. 각 그룹의 조인 관계 표현 20. 각 그룹의 조인 순서 결정 21. 각 조인의 조인 방법 결정 22. 그룹간의 조인 순서 및 조인 방법 결정 이와 같이 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) 위의 예와 같이 두 그룹은 조인 관계가 전혀 설정되어 있지 않은 테이블이며, 조인 순서를 결정하기 위하여 모든 테이블을 한꺼번에 고려하여 처리하는 것은 비용만을 증가시킬 수 있다. 일반적인 경우 이러한 분류가 효율적이나 응용 프로그램의 성격 및 데이터 구성에 따라 적합하지 않을 수 있으므로, 이런 경우 조인 476 ALTIBASE5 Administrator’s Manual 순서 힌트를 통하여 이를 제어할 수 있다. 이와 같이 조인 그룹을 분류한 후 각 조인 그룹에 대하여 다음과 같은 과정을 통하여 조인 순서를 결정하게 된다. 조인 관계의 구성 각 조인 그룹에 대하여 조인 관계를 구성하는 것은 조인 순서 결정 시 직접적인 조인 관계가 없는 테이블간의 비교 비용을 줄여 보다 효율적인 조인 순서를 결정하기 위함이다. 예를 들어 다음과 같은 질의를 살펴 보자 SELECT * FROM T1, T2, T3, T4 WHERE T1.i1 = T2.a1 AND T2.a2 = T3.m2 AND T3.m3 = T4.x3; 위의 질의에서 조인 관계는 다음과 같이 표현될 수 있다. T1T2T3T4 죠인 관계 T1.i1 = T2.a1 T2.a2 = T3.m2 T3.m3 = T4.x3 위와 같이 조인 관계를 관리하고 조인 순서의 결정 시 조인 관계만을 고려하여 비용 평가를 함으로서 (T1, T4)와 같이 직접적인 조인 관계가 없는 테이블간의 조인이 우선적으로 결정되는 것을 방지한다. 조인 관계의 사용이 일반적으로 효율적인 조인 순서를 결정하는 데 도움이 되나, 반드시 올바른 조인 순서를 결정하지는 않는다. 따라서, 필요한 경우 조인 순서 힌트를 사용하여 제어할 수 있다. 조인 관계의 순서 결정 위에서 생성한 조인 관계를 이용하여 각 조인 관계들 중 가장 효율적인 조인 관계의 순서를 결정하게 된다. 조인 관계의 순서를 결정하는 방법은 조인 관계들 중 조인 선택도(selectivity)가 가장 효율적인 조인 관계를 우선 선택한다. 그리고 다시 선택된 관계로부터 관련된 조인 관계들 중에 효율적인 조인 관계를 선택해가는 방식으로 결정된다. 이 때, 조인 관계의 순서라 함은 실제 조인 순서가 아니라, 조인 방법의 결정을 통해 완성된다. SQL 튜닝 477 T1 JOIN T2 T3 JOIN JOIN T4 죠인 관계의 순서 T1 JOIN T2 T3 JOIN JOIN T4 죠인 방법 결정 후의 실제 죠인 순서 [그림 10-4] 조인 관계의 순서 결정 위의 그림에서 보듯이 이 과정에서의 조인 관계의 순서는 조인 관계의 깊이만을 결정할 뿐 실제 조인 순서는 조인 방법 선택에 의하여 결정된다. 조인 관계 순서의 가장 중요한 요소는 조인의 선택도이며, 두 테이블의 조합을 통해 생성되는 결과 집합의 비율을 의미한다. 즉, 조인 관계의 순서 결정시 조인을 통한 결과 집합의 크기의 대소를 비교하기 보다 얼마나 많이 줄어드는가를 기준으로 판단하게 된다. Optimizer 가 조인 selecitivty 계산을 위한 개략적인 개념은 다음과 같다. [T(R) * T(S) / MAX[V(R.a), V(S.a)]/ [T(R) + T(S)] Join 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 의 관계가 더 중요한 조인 관계가 된다. Optimizer 가 조인 관계를 이용하여 생성한 조인 순서가 모든 경우에 있어 항상 바람직함을 보장할 수는 없다. 이를 위해 조인 478 ALTIBASE5 Administrator’s Manual 순서 힌트를 사용하여 조인 순서를 제어할 수 있다. 조인 관계의 순서를 결정한 후에는 두 테이블간의 조인 방법을 결정하게 되고 최종적으로 조인 순서가 결정된다. 조인 방법의 결정 조인 관계의 순서가 결정되면, 두 테이블의 각 조인 관계에 대하여 조인 방법을 결정하게 된다. 이 때, 다양한 조인 방법의 비용 비교를 통해 조인의 순서 및 방향, 조인 방법을 결정하게 된다. 알티베이스는 조인 방법을 다음과 같이 크게 네 가지로 분류하고 있다. y Nested loop 조인 계열 y Sort 조인 계열 y Hash 조인 계열 y Merge 조인 계열 각 조인 방법 및 실행 가능 여부는 다음과 같다. 조인 계열 조인 방법 조인 방향 Left=>Right Right=>Left Nested Loop Full nested loop C, I, L C, I, R Full store nested loop C, I, L, F C, I, R, F Index nested loop I, L I, R Anti outer nested loop F F Sort-based One pass sort join I, L, F I, R, F Multi pass sort join I, L, F I, R, F Hash-based One pass hash join I, L, F I, R, F Multi pass hash join I, L, F I, R, F Merge-based Index merge join I I Sort merge join I I 사용 가능한 조인의 종류 C: Cartesian Product: 조인 관계를 갖지 않는 두 테이블의 조합 I: Inner Join: 조인 관계를 갖는 두 테이블의 일반적인 조인 L: Left outer join: Left outer 조인 관계를 갖는 두 테이블의 조인 R: Right outer join: Right outer 조인 관계를 갖는 두 테이블의 조인 F: Full outer join: Full outer 조인 관계를 갖는 두 테이블의 조인 [표 10-8] 조인방법에 따른 실행 가능 여부 Optimizer 는 위와 같은 다양한 조인 방법들 중 적용 가능한 조인 방법에 대하여 비용 평가를 통해 가장 효과적인 조인 방법을 선택하고 조인의 방향을 결정하게 된다. 조인 방법이 결정되면 기준 테이블은 왼쪽에 위치하고 반복 SQL 튜닝 479 테이블은 오른쪽에 위치하게 된다. 실행 계획 트리의 분석을 통해 어떠한 조인 방법이 선택되었는 지를 판단이 가능하며, 힌트를 사용하여 제어할 수 있다. 이에 대한 내용은 실행 계획 분석과 힌트에 대한 설명에서 자세히 다루며 여기서는 각 조인 계열의 조인 방법에 대한 내용을 살펴 본다. Nested Loop 조인 계열 조인 방법 중 nested loop 조인 계열은 다음과 같은 것들이 사용된다. y Full nested loop join y Full store nested loop join y Index nested loop join y 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 에 의하여 사용될 가능성이 높다. SELECT * FROM T1, T2 WHERE T1.i1 = 1 AND T2.i1 = 1; Index nested loop join 은 인덱스를 이용하여 조인 조건을 처리하는 방법이다. 기준 테이블의 레코드 수가 적고 반복 테이블에 인덱스가 존재하는 경우에 사용될 가능성이 높다. Index on T2(i1) SELECT * FROM T1, T2 WHERE T1.i1 = T2.i1 AND T1.i1 = 1; Anti outer nested loop join 은 FULL OUTER JOIN 에서만 사용되며, 조인 조건에 해당하는 칼럼에 대하여 기준 테이블과 반복 테이블이 모두 인덱스를 사용할 수 있을 때 사용 가능하며 이 경우 다른 조인 방법에 비해 선택될 가능성이 높다. Index on T1(i1), Index on T2(i1) SELELCT * FROM T1 FULL OUTER JOIN T2 ON T1.i1 = T2.i1; 각 조인 방법들의 개략적인 비용 계산 방법은 Access cost + Disk I/O cost 로 된다. 조인 방법 Access Cost Disk I/O cost 480 ALTIBASE5 Administrator’s Manual 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 [표 10-9] nested loop 조인 계열의 계산법 Sort-based 조인 계열 Sort-based 조인 방법은 반복 테이블을 정렬된 순서로 저장하고 조인 조건을 이용하여 범위 검색을 하는 방법이다. 일반적으로 인덱스가 없고 부등호 조인 조건을 처리할 때 선택될 가능성이 높다. SELECT * FROM T1, T2 WHERE T1.i1 > T2.i1; 조인 방법 중 sort-based 조인 계열에는 다음과 같은 것들이 있다. y One-pass sort-based join y Multi-pass sort-based join One-pass sort-based 조인은 반복되는 테이블의 데이터 양이 적어 버퍼 내에서 관리가 가능할 때 사용되며, 메모리 테이블이 반복 테이블로 사용될 경우 모두 one-pass 조인을 사용하게 된다. Multi-pass sort-based 조인은 반복되는 테이블의 데이터 양이 방대하여 버퍼의 범위 내에서 관리할 수 없을 때 사용하며 Disk I/O 를 줄이기 위한 방법이다. 기준 테이블과 반복 테이블을 모두 정렬하여 저장하며, 기준 테이블의 데이터 정렬 순서로 조인 조건을 검사하게 되어 반복 테이블의 동일한 디스크 페이지 접근 확률을 높이게 된다. 각 조인 방법들의 개략적인 비용 계산 방법은 Access cost + Disk I/O cost 로 된다. SQL 튜닝 481 조인 방법 Access Cost Disk I/O cost No Buffer Miss Buffer Miss One-pass sort S(R) + T(L) * [log(T(R)) + s * T(R)] B(L) + S(R) + B(R) B(L) + 3S(R) + T(L) * s * B(R) Multi-pass sort S(L) + S(R) + T(L) * [log(T(R)) + s * T(R)] S(L) + S(R) + B(L) + B(R) 3S(L) + 3S(R) + B(L) + B(R) 참조) L: 기준 테이블, R: 반복 테이블 T(): 레코드 개수, B(): 디스크 페이지 개수, S(): 정렬 저장 비용, M: 버퍼 페이지, s: 조인 조건의 selectivity [표 10-10] Sort-based 조인 계열의 계산법 Hash-based 조인 계열 조인 방법 중 hash-based 조인 계열에는 다음과 같은 것들이 있다. y One-pass hash-based join y 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 함수로 분할하여 여러 임시 테이블에 저장하며, 하나의 임시 테이블끼리 조인 조건을 검사하여 반복 테이블의 동일한 디스크 페이지 접근 확률을 높이게 된다. 각 조인 방법들의 개략적인 비용 계산 방법은 Access cost + Disk I/O cost 로 된다. 482 ALTIBASE5 Administrator’s Manual 조인 방법 Access Cost Disk I/O cost No Buffer Miss Buffer Miss One-pass hash H(R) + T(L) * s * T(R) B(L) + H(R) + B(R) B(L) + 3H(R) + T(L) * s * B(R) Multi-pass hash H(L) + H(R) + T(L) * s * T(R) H(L) + H(R) + B(L) + B(R) 3H(L) +3H(R) + B(L) + T(L) * s * B(R) 참조) L: 기준 테이블, R: 반복 테이블 T(): 레코드 개수, B(): 디스크 페이지 개수, H(): 해싱 저장 비용, M: 버퍼 페이지, s: 조인 조건의 selectivity [표 10-11] Hash-based 조인 계열의 계산법 Merge 조인 계열 Merge 조인은 두 테이블의 데이터가 정렬되었을 경우 매우 효율적인 방법이다. 기준 테이블과 반복 테이블의 개념이 없으며 양쪽 테이블을 순차적으로 진행하면서 조인 조건을 검사하는 방법이다. 양쪽 테이블이 모두 정렬되어야 하며, 정렬 여부에 따라 다음과 같이 구분된다. y Index merge join y Sort merge join 즉, 각각의 테이블이 인덱스를 통해 정렬되어 있다면 인덱스를 사용하고, 인덱스가 없다면 조인 조건에 부합하는 정렬을 수행한 후 정렬 순서대로 조인 조건을 비교하며 데이터의 대소 비교에 따라 검색할 다음 레코드를 결정한다. Merge 조인은 양쪽 모두 인덱스를 사용할 수 있고 단일 테이블의 결과 집합을 줄일 수 없을 때 사용될 가능성이 높다. Index on T1(i1), Index on T2(a1) SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1; Merge 조인의 개략적인 비용 계산 방법은 Access cost + Disk I/O cost 로 된다. 테이블의 유형 Access Cost Disk I/O cost No Buffer Miss Buffer Miss Indexed Table T(L) B(L) B(L) Non-index Table S(L) + T(L) S(L) + B(L) 3S(L) + B(L) 참조) Merge 조인 비용은 두 테이블의 비용을 합산함. L: 테이블 T(): 레코드 개수, B(): 디스크 페이지 개수, S(): 정렬 저장 비용 [표 10-12] Merge 조인 계열의 계산법 지금까지 질의 성능에 가장 큰 영향을 미치는 FROM 과 WHERE SQL 튜닝 483 절을 의미하는 critical path 의 최적화 과정에 대하여 살펴보았다. 이후의 최적화 과정은 non-critical path 에 대한 최적화 과정으로 각 구문의 형태에 따라 구분하여 설명한다. 그룹 연산의 최적화 Optimzers 는 critical path 에 대한 최적화 과정후에는 non- critical path 에 대한 최적화 과정이 이루어지고, GROUP BY, HAVING, aggregation 연산 등의 그룹 연산에 대한 최적화를 수행한다. 그룹 연산의 최적화는 기본적으로 hashing 방식과 sorting 방식에 대한 비용 계산을 통해 실행 방법을 결정하며, 아래와 같은 최적화 기법들이 적용 가능한 경우 이를 적용한다. y 정렬 순서를 이용한 GROUP BY y 정렬 순서를 이용한 MIN, MAX y MIN, MAX내의 DISTINCT 제거 y 정렬 순서를 이용한 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; 484 ALTIBASE5 Administrator’s Manual 위의 질의를 처리하기 위해 optimizer 는 critical path 처리 과정에서 IDX1 또는 IDX2 를 사용할 수 있다. IDX1 을 사용한다면 GROUP BY 를 처리하기 위해 hashing 및 sorting 이 필요한 반면에, IDX2 를 사용할 경우 별도의 저장 없이 처리할 수 있다. 사용자가 실행 계획 트리를 분석하여 IDX1 을 사용하고 있음을 확인했다면, 힌트를 통해 IDX2 를 강제적으로 사용하게 할 수 있다. 유사한 개념으로 다음 질의 수행 시 해당 테이블에 인덱스가 없는 경우를 고려해 보자 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 SQL 튜닝 485 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; 물론 optimzer 가 MIN 또는 MAX 내에 DISTINCT 가 존재할 경우 이를 제거하지만, 사용자가 의미 없는 구문을 기술하지 않는 것이 바람직하다. 정렬 순서를 이용한 DISTINCT agregation 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 에 기술된 칼럼은 인덱스의 칼럼 순서대로 기술될 필요는 없으나, 인덱스의 키 칼럼 순서로 모두 접근 가능해야 한다. 486 ALTIBASE5 Administrator’s Manual 즉, 다음과 같은 질의는 해당 인덱스를 사용할 수 없다. SELECT DISTINCT i1, i3 FROM T1; 이러한 특징을 잘 이해하고 있다면 다음과 같은 질의는 질의 변경을 통해 정렬 순서를 이용한 DISTINCT 최적화를 사용할 수 있다. SELECT DISTINCT i1, i3 FROM T1 WHERE i2 = 0; SELECT DISTINCT i1, i2, i3 FROM T1 WHERE i2 = 0; 위와 같이 i2 칼럼을 DISTINCT 구문에 추가하여 해당 최적화 기법이 사용되게 할 수 있다. 물론 이는 WHERE 절에 (i2 = 0) 과 같이 i2 값이 일정함을 보장할 수 있기 때문에 동일한 결과 집합을 추출할 수 있으므로 변경이 가능하다. 인덱스를 생성할 때에도 WHERE 구문뿐 아니라 빈번히 사용되는 DISTINCT 구문과 함께 고려하는 것이 바람직하다. 집합 연산의 최적화 UNION ALL 을 제외한 UNION, INTERSECT, MINUS 등의 집합 연산은 중간 결과의 관리를 필요로 한다. Optimizer 는 여러 개의 집합 연산이 중복되어 있을 때 결과 집합이 작은 순서로 해당 연산을 수행하도록 최적화하지만, 이 역시 비용 계산으로 이루어지므로 정확하지 않을수 있다. 따라서, 사용자가 결과 집합의 대소 여부를 알고 있다면 연산 순서를 명확히 하는 것이 바람직하다. SELECT * FROM large INTERSECT SELECT * FROM medium INTERSECT SELECT * FROM small; (SELECT * FROM small INTERSECT SELECT * FROM medium ) INTERSECT SELECT * FROM large; 일반적으로 집합 연산과 관련하여 사용자가 빈번히 범하는 오류는 UNION 과 UNION ALL 을 구분하지 않는다는 것이다. UNION 은 중복 결과를 제거하는 반면, UNION ALL 은 중복 결과를 제거하지 않는다. 즉, 동일한 테이블을 사용하는 경우 UNION 의 성능이 UNION ALL 보다 느릴 수 밖에 없다. 두 테이블의 결과가 중복된 것이 없음이 보장되거나 중복 제거가 필요 없는 경우라면 UNIOIN ALL 을 사용하는 것이 바람직하다. SQL 튜닝 487 ORDER BY 의 최적화 ORDER BY 구문은 정렬을 필요로 하는 구문이다. Optimizer 는 다음과 같은 최적화 기법을 적용할 수 있는 지의 여부를 검사하여 실행 계획을 결정한다. y 정렬 순서를 이용한 ORDER BY y 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 을 위해 전체 데이터를 위한 공간을 사용하지 않고 LIMIT 구문에 기술된 공간만큼을 사용하여 정렬을 수행하는 방법이다. 488 ALTIBASE5 Administrator’s Manual 예를 들어, 다음과 같은 질의는 정렬시 다섯 개의 레코드 공간만을 이용하여 정렬을 수행한다. SELECT * FROM T1 ORDER BY i1 LIMIT 5; 따라서, 전체 데이터에 대한 정렬 결과가 필요하지 않는 경우라면 LIMIT 구문을 이용하여 자원 효율 및 성능 향상을 기대할 수 있다. 파티션의 최적화 파티션드 테이블에 접근시 파티션 프루닝(pruning)과 필터링을 이용하여 불필요한 파티션을 제거하고 술어의 조건에 맞는 파티션만으로 실행계획 트리(plan tree)를 구성한다. 파티션 프루닝은 실행(execution)중에 조건이 바뀌지 않는 고정 술어(fixed predicate)를 최적화한다. 그러나 가변 술어(variable predicate)는 조건에 부합하는 파티션이 계속 바뀌어, 불필요한 파티션을 실행계획 트리에서 제거하거나 조건에 부합하는 파티션만으로 실행계획 트리를 구성할 수 없다. 이러한 가변 술어는 파티션 필터링으로 최적화를 한다. y 범위 파티션 프루닝 y 리스트 파티션 프루닝 y 해시 파티션 프루닝 y 파티션 필터링 범위 파티션 프루닝 범위 파티션 프루닝이 가능한 술어의 형태는 인덱스를 사용하여 검색이 가능한 조건과 형태가 동일하다. 호스트 변수가 포함되거나 조인 조건의 경우는 해당되지 않는다. 예제) I1 = 1, i1 between 1 and 10, i1 > 5 등 범위를 나타내는 인덱스 사용이 가능한 모든 술어 SQL 튜닝 489 t im e _id < 2006.04.01 Part_1 t im e _id < 2006.07.01 Part_2 t im e _id < 2006.10.01 Part_3 t im e _id >= 2006.10.01 Part_4 Sa le s (p a rtitio n key : tim e _id ) 2005.08.13 2006.01.21 2006.02.12 2006.03.31 ... 2006.04.01 2006.05.15 2006.06.12 ... ... 2006.08.17 2006.09.01 ... ... ... 2006.10.02 2006.11.11 2006.12.01 NULL ... SELECT sum (am ount_sold) FRO M s a le s WH ERE tim e_id <= t o _d a t e (‘20060918’, ‘YYYYM M D D ’); SCAN (P a r t _1) SCAN (P a r t _2) SCAN (P a r t _3) PROJ GRAG PCRD(Sales) [그림 10-5] 범위 파티션 프루닝의 예 위의 [그림 10-5]의 Sales 테이블은 시간을 기준으로 총 4 개의 파티션으로 분리된 파티션드 테이블이다. 파티션 키인 time_id 에 대한 술어를 통해 최적화 단계에서 파티션 프루닝이 되어 Plan Tree 의 스캔 대상은 술어 조건에 부합되는 Part_1, Part_2, Part_3 만이 남게된다. PCRD 는 Partition-Coordinator 실행 노드로, 파티션드 테이블의 각각의 파티션에 대한 SCAN 노드를 자식 노드로 가지는 노드이다. 리스트 파티션 프루닝 리스트 파티션 프루닝이 가능한 술어의 형태는 인덱스를 사용하여 검색이 가능한 조건과 형태가 동일하나, 등호(equality, =) 연산자만 가능하다. 호스트 변수가 포함되거나, 조인 조건의 경우는 이에 해당되지 않는다. 예제) I1 = 1, i1 in (4,5,6), i1 is null 등의 술어 490 ALTIBASE5 Administrator’s Manual depart = ‘RND1’ Part_1 Em ployee(partition key : departm ent) depart = ‘RND2’ Part _2 d ep art = ‘RN D 3’, ‘RN D 4’ Part _3 depart = ‘RND5’ Part_4 depart = DEFAULT Part _5 SELECT id FROM em p loyee WH ER E de part = ‘RND1’; PROJ SC AN ( P a r t _ 1 ) PCRD(Sa le s) SELEC T i d FROM em plo yee WH ER E de part > ‘RND1’ AND de part < ‘RND4’; PROJ SCAN(Pa rt _1) PCRD(Sales) SCAN(Pa rt _2) SCAN(Pa rt _3) SCAN(Pa rt _4) SCAN(Pa rt _5) SELEC T i d FROM em ployee WH ER E d e p a r t IN ( ‘RN D 1 ’, ‘RN D 3 ’, ‘RN D 5 ’); PROJ SC AN ( P a r t _ 1 ) PCRD(Sales) SC AN ( P a r t _ 3 ) SC AN ( P a r t _ 4 ) SELEC T i d FROM em plo yee WH ER E de part = ‘SUPPORT’; PROJ PCRD(Sales) SCAN(Pa rt _5) [그림 10-6] 리스트 파티션 프루닝의 예 [그림 10-6]의 Employee 테이블은 부서명을 기준으로 총 5 개의 파티션으로 분리된 파티션드 테이블이다. 파티션 키인 depart 에 대한 술어로 최적화 단계에서 파티션 프루닝이 되어 각각의 질의에 대한 실행계획 트리의 스캔 대상은 술어 조건에 부합되는 파티션으로 구성된다. 해시 파티션 프루닝 해시 파티션 프루닝이 가능한 술어의 형태는 인덱스를 사용하여 검색이 가능한 조건과 형태가 동일하며, 등호(equality, =)연산자만 가능하다. 호스트 변수가 포함되거나, 조인 조건의 경우는 이에 해당되지 않는다. 예제) I1 = 1, i1 in (4,5,6), i1 is null 등의 술어 SQL 튜닝 491 Part_1 Em p lo ye e (p a r t it io n ke y : id ) Part_2Part_4Part_3 0 4 12 1 5 9 13 3 15 19 10 18 SELECT departm ent FROM em p lo yee WH ERE id = 9; PROJ SC AN ( P a r t _ 2 ) PCRD(Sales) SELECT departm ent FROM em p lo yee WH ERE id IN ( 1, 9, 12, 13); PROJ SC AN ( P a r t _ 2 ) PCRD(Sales) SC AN ( P a r t _ 1 ) SELECT d e p a r t m e n t FROM em ployee WH ERE id < 15; PROJ SC AN ( P a r t _ 2 ) PCRD(Sales) SC AN ( P a r t _ 1 ) SC AN ( P a r t _ 3 ) SC AN ( P a r t _ 4 ) [그림 10-7] 해시 파티션 프루닝의 예 위의 [그림 10-7]의 Employee 테이블은 id 를 기준으로 총 4 개의 파티션으로 분리된 파티션드 테이블이다. 파티션 키인 id 에 대한 술어를 통해 최적화 단계에서 파티션 프루닝이 되어 각각의 질의에 대한 실행계획 트리의 스캔 대상은 술어 조건에 부합되는 파티션으로 구성된다. 파티션 필터링 파티션 필터링이 가능한 술어의 형태는 파티션 프루닝이 가능한 술어의 형태와 동일하나, 실행중에 변하는 조건인 조인 조건 또는 호스트 변수가 포함된 술어의 형태이다. 예제) I1 = ?, T1.i1 = T2.i1, I1 < ? 등 술어의 조건이 고정적이지 않은 형태 492 ALTIBASE5 Administrator’s Manual time _id s a le s _e ve nts 20060608 20060816 20060121 20060914 20060211 20060405 sa le s_pe r 25 10 5 7 40 50 time _id < 20 0 6. 0 4. 0 1 Pa rt_1 time _id < 20 0 6. 0 7. 0 1 Pa rt_2 time_id < 2006.10.01 Pa rt_3 DEFAULT Pa rt_4 S a le s ( pa rtition ke y : time _id) 20060101 20060102 ... 20060121 ... 20060331 20060401 20060102 ... 20060608 ... 20 0 60 731 20060801 ... 20060816 ... 20060931 ... 20060931 20061001 20061002 ... ... SCANPCRD JOIN 20060608 20060816 20060121 20060914 sales. time_id = sales_events. sales_per <= 30 [ Partitio n Filte r ] sale s_ e ve nts. time _id = sale s. time _id time _id 20060608 20060816 20060121 20060914 sa le s_pe r 25 10 5 7 sales. time_id = sales. time_id = sales. time_id = (1) (2) (3) (4) (1) (2) (3) (4) (1) (2)(3) (4) 파티션 필터링 (1) (2) (3) (4) sales_event 를scan 한결과 sales_event 를scan 한 결과의time _id가 조건에 들어감 SELECT SUM(SOLD_AMOUNT) F ROM SALE S _ E VENTS , S ALE S WHERE S ALE S _ E VENT. S ALES_PER < = 30 AND SALES_ EVENT. T IME_ ID = SALES. T IME_ ID; SCANSCANSCANSCAN [그림 10-8] 파티션 필터링의 예 [그림 10-8]은 실행시 파티션 필터링이 일어나는 과정을 나타낸다. 먼저 sales_event 테이블에서 조건에 맞는 레코드가 (1), (2), (3), (4) 순으로 한 건씩 찾고, 이 레코드의 time_id 칼럼이 가변 술어의 sales_events.time_id 가 되어 술어 조건에 맞는 파티션을 찾는다. (1)번 술어의 경우 2006.04.01 ~ 2006.06.29 범위를 갖는 파티션인 Part_2 에 포함되기 때문에 파티션 필터링에 의해 Part_2 에서만 조건에 맞는 레코드를 찾게 된다. 마찬가지로 (2), (3), (4)번 술어 역시 이와 동일한 방법으로 술어 조건에 부합하는 파티션을 찾아서 스캔한다. 이렇게 수행단계 중에 술어 조건에 맞는 파티션을 찾아서 스캔하는 기법을 파티션 필터링이라 한다. 프로젝션의 최적화 프로젝션은 전체 칼럼 정보로부터 SELECT 구문에 기술된 일부 칼럼 및 연산 결과를 추출하는 과정이다. SQL 튜닝 493 연산 순서의 고려 다음과 같이 항상 일정한 결과를 내는 연산은 한 번만 수행하고 다음 수행 시에는 이전의 결과를 사용한다. SELECT 1 + 1 FROM T1; 알티베이스는 사칙 연산과 같은 연산을 처리함에 있어 post-fix calculation 기법을 사용하며 이는 연산 순서를 어떻게 기술하느냐에 따라 성능에 영향을 줄 수 있다. 예를 들어 다음과 같은 질의는 동일한 결과를 얻는 질의이다. 질의 1: SELECT i1 * 2 * 3 FROM T1; 질의 2: SELECT i1 * (2 * 3) FROM T1; 질의 1 의 경우, [i1 * 2] * 3 과 같은 연산 순서로 처리되어 i1 값이 변함에 따라 매번 (* 2) 와 (* 3) 연산이 수행되어야 하지만, 질의 2 는 (2 * 3) 의 결과인 6 을 생성하고 i1 의 값의 변화에 따라 (i1 * 6)의 연산만 수행된다. 즉, 연산 순서를 어떻게 제어하느냐에 따라 성능 차이가 발생할 수 있다. 이는 SELECT 구문뿐 아니라 WHERE 절 등의 모든 영역에서 영향을 받는다. 질의 1: WHERE i1 + 3 > 100; 질의 2: WHERE i1 > 100 - 3; 즉, 위의 질의에서 질의 2 가 보다 나은 성능을 기대할 수 있다. 그러나, 이러한 수식의 변경 시에는 다음과 같은 점을 고려하여야 한다. 칼럼 i1 이 INTEGER 임을 가정할 때 다음과 같은 질의 1 은 질의 3 과 같이 기술하는 것이 효율적이다. 질의 1: WHERE i1 * 3 > 100; 질의 2: WHERE i1 > 100 / 3; 질의 3: WHERE i1 > 33; 질의 2 와 같이 변경할 경우 100/3 은 실수형 값이 되어 칼럼 i1 에 대하여 인덱스를 사용할 수 없다. 그러나, 질의 3 과 같이 변경할 경우 수학적 동치는 아니지만 i1 이 INTEGER 이므로 동일한 결과를 얻을 수 있으며 인덱스도 사용할 수 있다. 이와 같이 연산 순서와 데이터 타입을 잘 고려할 경우 동일한 질의 결과를 얻으면서 성능 향상을 기대할 수 있다. 프로젝션에 대한 최적화는 대부분 Subquery 내에 존재하는 SELECT 구문에 대한 최적화이며 이는 다음 SUBQUERY 의 최적화를 통해 자세히 설명한다. SUBQUERY 의 최적화 494 ALTIBASE5 Administrator’s Manual 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 의 실행 방법을 결정할 때 다음과 같은 최적화 기법들의 적용 가능 여부 및 비용 평가를 통해 해당 기법의 적용 여부를 결정한다. y EXISTS, UNIQUE 등의 SELECT 칼럼 제거 y Eliminate Quantify Rule y Transform NJ y Invariant Area y Store And Search y Subquery Key Range Subquery 유형 Optimizer 의 subquery 최적화 기법을 설명하기 전에 subquery 의 유형에 대하여 살펴보자. Subquery 의 유형에 따라 적용할 수 있는 최적화 기법이 다르므로 이를 이해하는 것은 매우 중요하다. Subquery 는 외부 칼럼의 참조 여부, 그룹 연산의 존재 여부에 따라 다음과 같이 4 가지로 분류한다. 여기서 그룹 연산의 존재는 GROUP BY, HAVING, aggregation 연산 중 하나라도 존재하는 경우를 의미한다. 외부 칼럼 비참조 외부 칼럼 참조 그룹 비존재 Type N Type J 그룹 존재 Type A Type JA [표 10-13] 서브쿼리의 유형 SQL 튜닝 495 y Type N 다음 예와 같이 외부 칼럼이 존재하지 않고 그룹 연산도 존재하지 않는 경우이다. SELECT * FROM T1 WHERE T1.i1 IN ( SELECT T2.a1 FROM T2 ); y Type J 다음 예와 같이 외부 칼럼을 참조하지만 그룹 연산은 없는 경우이다. SELECT * FROM T1 WHERE EXISTS ( SELECT * FROM T2.a1 = T1.i1 ); y Type A 다음 예와 같이 외부 칼럼을 참조하지는 않지만 그룹 연산이 있는 경우이다. SELECT * FROM T1 WHERE i1 > ( SELECT SUM(a1) FROM T2 ); y Type AJ 다음 예와 같이 외부 칼럼을 참조하고 그룹 연산이 존재하는 경우이다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a2 = T1.i2 GROUP BY a1 HAVING SUM(a2) > 0 ); Type N 과 type A 의 경우 외부 칼럼을 참조하지 않아 항상 동일한 결과를 생성하는 반면, type J 와 type JA 는 외부 칼럼을 참조하므로 외부 칼럼의 변경에 따라 항상 새로 실행하여야 한다. 즉, subquery 에 외부 칼럼을 사용하지 않고 질의를 작성할 수 있다면 보다 나은 성능을 기대할 수 있다. 위와 같은 subquery 의 유형에 따라 관련 최적화 기법을 적용할 수 있는 지의 여부가 결정된다. EXISTS, UNIQUE 의 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 496 ALTIBASE5 Administrator’s Manual 에서만 동일한 질의 결과임을 보장할 수 있으며, 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 ); 위와 같은 최적화 기법은 MIN, MAX 등의 하나의 값에 대해서만 검사하기 때문에 전체 레코드를 비교하는 것보다 많은 성능 향상을 기대할 수 있다. 또한, 이와 같은 질의 변경은 앞에서 언급한 정렬 순서를 이용한 MIN, MAX 최적화 등에 의하여 인덱스를 사용하여 성능을 향상시킬 수 있다. 그러나, 이러한 질의 변경도 T2 의 레코드가 존재하지 않는 경우 다른 결과를 생성하는 경우가 존재할 수 있어, optimizer 가 반드시 동일한 방식으로 질의를 변경하지는 않는다. 이는 type A, type J 에 대해서만 가능하며, optimizer 는 비용 비교를 통해 해당 최적화 기법의 적용 여부를 결정하게 된다. 따라서, 사용자가 위와 같은 최적화 기법을 이해하고 해당 질의가 동일한 결과를 얻을 수 있음이 보장된다면, optimizer 에 그 판단을 맡기지 않고 명시적으로 질의를 변경하는 것도 좋은 방법이다. Transform NJ Transform NJ 기법은 type N 또는 type J 의 subquery 를 type J 형으로 변경시키는 방법이다. 다음 예를 통해 해당 기법을 살펴보자. SQL 튜닝 497 SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 ); SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a1 = T1.i1 ); 위의 예에서, 원 질의는 type N 형의 subquery 로 외부 칼럼을 참조하지 않고 있으나, transform NJ 기법에 의하여 외부 칼럼을 참조하도록 질의를 변경하는 것이다. 마찬가지로, type J 형의 subquery 를 type J 형의 질의로 변경하는 예는 다음과 같다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a2 = 1 ); SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a1 = 1 AND T2.a1 = T1.i1 ); 이러한 최적화 기법은 T2.a1 칼럼의 인덱스를 사용하여 성능을 향상시키려 하는 방법이다. 해당 최적화 기법은 T2.a1 칼럼과 T1.i1 칼럼이 NULL 이 아님이 보장될 때 동일한 결과를 생성할 수 있으며, optimizer 는 이러한 제약 조건들과 함께 비용 평가를 통해 해당 기법의 적용 여부를 결정한다. 일반적으로 해당 최적화 기법은 외부 질의의 데이터보다 subquery 내의 데이터가 많은 경우에 효율적인 기법이며, 사용자는 위와 같은 질의 변경이 동일한 결과를 보장할 수 있음을 확신할 경우 명시적으로 질의를 변경하여 성능 향상을 기대할 수 있다. Subquery 의 불변 영역(invariant area) 외부 칼럼을 참조하는 type J, type JA 형의 subquery 라 하더라도 항상 모든 subquery 구문을 재수행해야 하는 것은 아니다. 예를 들어 다음과 같은 질의를 살펴 보자. SELECT * FROM T1 WHERE i2 > ( SELECT SUM(T2.a2 + T3.x2) FROM T2, T3 WHERE T2.a1 = T3.x1 AND T3.x1 = 1 AND T2.a1 = T1.i1 ); 위의 질의에서 subquery 는 T1.i1 칼럼을 참조하고 있는 type JA 형이지만, 이 중 (T3.x1 = 1) 과 같은 일부 조건은 반복적으로 재수행할 필요가 없다. 즉, 해당 조건의 중간 결과는 항상 재사용할 수 있으며, 이와 같이 항상 재사용할 수 있는 영역을 subquery 의 불변 영역라고 한다. Optimizer 는 이와 같은 불변 영역을 판단하고, 불변 영역에 대한 저장 및 재사용 여부를 비용 비교를 통해 결정하게 되며, 이는 실행 계획 분석을 통해 해당 기법의 적용 여부를 판단할 수 있다. 498 ALTIBASE5 Administrator’s Manual 이에 대한 분석 방법은 실행 계획 분석에서 설명한다. 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 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 WHERE i1 IN ( SELECT a1 FROM T2 ); T1.i1 칼럼을 인덱스를 사용하는 경우와 앞에서 설명한 transform NJ 기법을 사용하여 T2.a1 칼럼의 인덱스를 사용하는 것은 데이터 구성에 따라 서로 다른 성능을 낼 수 있다. 일반적으로 외부 질의의 데이터가 많은 경우는 subquery keyrange 를 사용하는 것이 효율적이며, subquery 의 데이터가 많은 경우는 transform NJ 기법을 사용하는 것이 효율적이다. 즉, 많은 데이터를 가진 질의 영역에서 인덱스를 사용하는 것이 보다 효율적일 가능성이 높다. 일반적으로 optimizer 가 비용 계산에 의하여 이를 처리하지만, 사용자가 명시적으로 질의를 변경하여 성능을 향상시킬 수도 있다. SQL 튜닝 499 즉, 다음 질의를 사용자가 원하는 최적화 기법을 적용할 수 있도록 변경할 수 있다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 ); Subquery keyrange 최적화 기법을 적용하고 싶은 경우 SELECT * FROM T1 WHERE i1 IN ( SELECT DISTINCT a1 FROM T2 ); Transform NJ 최적화 기법을 적용하고 싶은 경우 SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a1 = T1.i1 ); 이러한 질의 변경이 optimizer 가 해당 최적화 기법을 사용하는 데 도움을 줄 수는 있으나 반드시 적용되는 것은 아니며, 질의 변경 시 반드시 동일한 결과를 보장할 수 있음을 확신하는 것이 중요하다. 조인 질의로 변경 IN 또는 EXISTS 등의 subquery 는 특정 상황에 있어 조인으로 변경할 수 있으므로 질의 변경을 통한 성능 향상이 가능하다. 그러나, 조인으로의 질의 변경으로 반드시 성능 향상이 되거나, 항상 동일한 결과를 보장하는 것이 아니므로 주의해야 한다. 예를 들어, 다음과 IN subquery 질의는 T2.a1 이 UNIQUE 한 경우에 한해 아래와 같이 조인 형태로 변경이 가능하다. SELECT * FROM T1 WHERE T1.i1 IN ( SELECT T2.a1 FROM T2 ); SELECT T1.* FROM T1, T2 WHERE T1.i1 = T2.a1; 마찬가지로 아래의 EXISTS 질의도 T2.a1 이 UNIQUE 한 경우에 한해 아래와 같이 조인 형태로 변경이 가능하다. SELECT * FROM T1 WHERE EXISTS ( SELECT * FROM T2 WHERE T2.a1 = T1.i1 ); SELECT T1.* FROM T1, T2 WHERE T1.i1 = T2.a1; 지금까지 최적화 과정에 대한 설명과 최적화를 위한 질의 튜닝 방법등에 살펴보았다. 해당 질의가 적용된 최적화 기법들은 앞으로 설명할 실행 계획 분석 단계의 내용을 통해 판단할 수 있다. 500 ALTIBASE5 Administrator’s Manual 실행 계획 분석 SQL 튜닝을 위해서는 1 차적으로 실행 계획(plan tree)을 분석하는 것이 필수적이다. 여기서는 실행 계획 트리 정보를 추출하고 이를 해석하는 방법과 실행 계획 트리를 구성하는 각 실행 노드들의 정보를 분석하는 방법을 설명한다. 실행 계획 분석 방법 실행 계획 분석을 위한 SQL 구문 실행 계획 트리는 iSQL 을 통해 분석이 가능하다. 실행 계획 트리는 SELECT 구문에 대해서만 검색이 가능하며, 이를 위해서는 SELECT 구문의 수행 전에 다음 명령을 수행하여야 한다. ALTER SESION SET EXPLAIN PLAN = option; 여기서 option 은 ON, OFF, ONLY 의 세 가지 설정이 있으며, 기본 설정값은 OFF 이다. y ON: SELECT 문 실행 후 결과 레코드와 함께 Execution Plan 정보를 보여준다. y ONLY: SELECT 문에 대해 Prepare 과정만 수행한 후 Execution 과정을 수행하지 않고 단지 실행 계획 정보만 보여준다. 주 언어 변수 바인딩이 존재하는 SELECT 문 또는 실행 수행 시간이 오래 걸리는 질의에 대해 단순히 실행 계획만 확인할 경우 이 기능을 사용한다. y 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. iSQL> alter sesion set explain plan = on; Alter success. SQL 튜닝 501 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 으로 한 경우] PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) [TRCLOG_DETAIL_PREDICATE 을 설정하지 않고 EXPLAIN PLAN = ONLY 로 한 경우] PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCES: ??, SELF_ID: 2 ) EXPLAN PLAN = ONLY 인 경우 질의 실행 없이 실행 계획만 생성하므로 ACCESS 항목과 같이 실제 실행 후 그 값이 결정되는 항목들은 ??로 표시된다. 실행 계획 트리의 해석 각 실행 노드들이 트리 형태로 연결된 전체 실행 계획 트리에 따라 어떤 순서로 실행되는지에 대해 예제를 들어 실행 계획을 해석하는 방법을 간략히 설명한다. SELECT * FROM T1, T2, T3 WHERE T1.I1 = T2.I1 AND T2.I1 = T3.I1 질의의 실행 계획이 다음과 같은 경우 [EXECUTION PLAN] 6--------- PROJECT ( COLUMN_COUNT: 9, TUPLE_SIZE: 36 ) 5--------- JOIN ( REF_ID: 3 ) 3--------- JOIN ( REF_ID: 2 ) 1--------- SCAN ( TABLE: T1, FULL SCAN, ACCESS: 8, SELF_ID: 1 ) 2--------- SCAN ( TABLE: T2, INDEX: IDX2, ACCESS: 104, SELF_ID: 2 ) 4--------- SCAN ( TABLE: T3, INDEX: IDX3, ACCESS: 1144, SELF_ID: 3 ) 최상위 노드 최하위 노드 실행 계획 트리에서 하나의 노드는 한 행에 표시되고 왼쪽으로 들여쓰기가 많이 되어 있는 노드일수록 하위 노드에 해당하며 가장 먼저 수행된다. 위 예제에서 가장 최상위 노드는 PROJ 노드이며 최하위 노드는 T1 502 ALTIBASE5 Administrator’s Manual SCAN 노드와 T2 SCAN 노드이다. T1 SCAN 노드와 T2 SCAN 노드와 같이 같은 크기만큼 들여쓰기가 되어 있는 노드들은 먼저 나타나는 노드가 상위 노드의 왼쪽 노드에 해당한다. 질의 처리기에서 최상위 노드에 질의의 수행을 요구하면 해당 노드는 자신의 하위 노드에게 조건에 맞는 레코드를 요구하고 하위 노드는 조건에 맞는 레코드를 찾아 자신이 수행해야 할 작업을 수행한 후 상위 노드에게 레코드를 패치해 준다. 그러면 상위 노드는 그 레코드를 받아 하위 노드가 했던 방법과 같은 방법을 반복한다. 즉, 레코드 패치 요구는 TOP-DOWN 으로 이루어지고 처리한 레코드의 이동은 BOTTOM-UP 방식으로 이루어진다. 위의 예제에서 가장 먼저 데이터베이스에 접근하는 노드는 T1 SCAN 노드이고, 그 다음 T2 SCAN 노드, T3 SCAN 노드의 순서로 수행되며, 노드 옆에 명시한 숫자가 노드 수행 순서이다. 위의 예제에서 나타난 실행 계획을 트리 형태로 나타내면 다음과 같다. SCAN T3 JOIN PROJ SCAN T1 SCAN T2 JOIN T1, T2 2 6 3 5 4 1 레코드 이동 경로 레코드 패치 요구 경로 [그림 10-9] 레코드 패치 경로 실행 노드의 종류 실행 계획 트리는 다양한 실행 노드들로 구성된다. 실행 노드는 물리 연산자(physical operator)라고도 한다. 실행 노드는 질의를 직접 수행하는 연산자들로 앞에서 설명한 바와 같이 실행 계획 트리를 통해 연산이 수행되는 흐름을 판단할 수 있다. 실행 노드는 자식 노드의 개수와 중간 결과의 저장 여부에 따라 다음과 같이 구분한다. y 단일 비저장 노드(Unary Non-materialization Node): 하나 SQL 튜닝 503 이하의 자식 노드를 가지며, 중간 결과를 저장하지 않음 y 단일 저장 노드(Unary Materialization Node) : 하나 이하의 자식 노드를 가지며, 중간 결과를 저장함. y 이진 비저장 노드(Binary Non-materialization Node) : 두 개의 자식 노드를 가지며, 중간 결과를 저장하지 않음. y 이진 저장 노드(Binary Materialization Node) : 두 개의 자식 노드를 가지며, 중간 결과를 저장함. y 다중 비저장 노드(Multiple Non-materialization Node) : 하나 이상의 자식 노드를 가지며, 중간 결과를 저장하지 않음. 알티베이스의 실행 노드는 이러한 구분에 따라 다음과 같은 26 가지의 물리 연산자가 존재한다. 구분 약자 출력 이름 기능 단일 비저장 노드 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 자식 노드의 결과 조합 BUNI BAG-UNION BAG UNION의 흐름 관리 이진 저장 노드 SITS SET-INTERSECT SET INTERSECT 집합 연산 SDIF SET-DIFFERENCE SET DIFFERENCE 집합 연산 504 ALTIBASE5 Administrator’s Manual 다중 비저장 노드 PCRD PARTITION- COORDINATIOR 각각의 파티션에 대한 스캔을 관리하 는 노드 [표 10-14] 실행 노드의 종류 각 실행 노드의 약자는 이후의 설명 과정에서 실행 계획 트리의 흐름도를 표현하는 데 사용하며, 각 실행 노드에 대한 기능과 자세한 설명은 이후에 자세히 기술한다. 저장 노드의 특징 저장 노드들은 관련 연산을 수행하기 위하여 중간 결과를 저장하는 노드이다. 중간 결과를 저장하기 위하여 임시 테이블을 사용하며, 저장 매체의 종류에 따라 메모리 임시 테이블 또는 디스크 임시 테이블을 사용한다. 메모리 임시 테이블은 시스템 커널로부터 직접 할당 받은 메모리 영역을 저장 공간으로 사용하며, 질의 수행 후에 바로 제거된다. 디스크 임시 테이블은 사용자에게 지정된 임시 테이블스페이스 영역을 저장 공간으로 사용하며, 메모리 버퍼를 이용하여 데이터에 대한 관리가 이루어진다. 이 또한 질의 수행 후에 바로 제거된다. 메모리 임시 테이블 또는 디스크 임시 테이블을 사용하게 되는 기준은 다음과 같다. 저장 노드의 하위 자식 노드들이 메모리 테이블만을 사용하는 경우라면 메모리 임시 테이블을 사용하게 되며, 디스크 테이블이 하나 이상 포함되어 있는 경우에는 디스크 임시 테이블을 사용한다. 이러한 기준은 힌트를 이용하여 조정할 수 있다. 다음 예와 같이 메모리 테이블이 사용된 경우의 정렬과 디스크 테이블의 정렬을 위한 실행 계획을 살펴 보면 그 차이를 확인할 수 있다. 아래의 질의는 메모리 테이블에 대하여 중복 제거 및 정렬을 위하여 중간 결과를 저장하는 두 개의 저장 노드를 가지고 있다. 메모리 임시 테이블을 사용하는 경우 디스크 페이지에 대한 정보를 별도로 갖지 않는다. SQL 튜닝 505 iSQL> select distinct i3 from memory_table order by i3; I3 -------------- 0 1 2 3 4 5 rowselected. ------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SI ZE: 4 ) SORT( ITEM_SI ZE: 24, I TEM_COUNT: 5, ACCESS: 5, SELF_ID: 2, REF_ID: 0 ) DI STI NCT ( I TEM_ SI ZE: 24, I TEM_ COUNT: 5, BUCKET_ COUNT: 1024, ACES: 5, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: MEMORY_TABLE, FUL SCAN, ACCESS: 16384, SELF_I D: 0 ) ------------------------------------- 다음은 디스크 테이블에 대하여 중복 제거 및 정렬을 위하여 중간 결과를 저장하는 두 개의 저장 노드를 보이고 있다. 디스크 임시 테이블을 사용하는 경우 디스크 페이지에 대한 정보를 갖는다. 즉, 실행 노드의 정보 중 DISK_PAGE_COUNT 정보의 유무를 통해 임시 테이블의 저장 매체 정보를 판단할 수 있다. iSQL> select distinct i3 from disk_table order by i3; I3 -------------- 0 1 2 3 4 5 r ows sel ect ed. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SI ZE: 4 ) SORT ( ITEM_SIZE: 32, ITEM_COUNT: 5, DI SK_PAGE_ COUNT: 3, ACES: 5, SELF_ID: 2, REF_ID: 0 ) DI STI NCT( ITEM_SIZE: 24, ITEM_COUNT: 5, DI SK_ PAGE_COUNT: 6, ACES: 5, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: DISK_TABLE, FUL SCAN, ACES: 16384, DISK_PAGE_COUNT: 28, SELF_ID: 0 ) ------------------------------------------------------------ 모든 저장 노드들은 임시 저장 테이블에 저장된 데이터를 재구성할 필요가 있는 지를 판단하기 위한 정보를 갖는다. 이러한 정보는 REF_ID 로 표현되며, REF_ID 에 해당하는 실행 노드의 레코드가 변경될 경우 저장 노드는 임시 저장 테이블을 재구성하게 된다. 위의 예에서는 모두 자식 노드들을 참조하고 있어 별도의 재구성이 발생하지 않는 것을 알 수 있다. 단일 비저장 노드 단일 비저장 노드는 하나 이하의 자식 노드를 가지며, 해당 기능을 506 ALTIBASE5 Administrator’s Manual 수행하기 위해 별도의 저장 공간을 필요로 하지 않고 하나의 레코드만을 관리하는 노드이다. 위와 같은 특징을 갖는 각 실행 노드의 기능과, 실행 계획에서의 분석 방법에 대하여 살펴본다. SCAN 실행 노드 SCAN 실행 노드는 관계형 모델에서 검색(selection)연산을 수행하는 물리 연산자이다. 자식 노드를 갖지 않으며 테이블에 직접 접근하여 해당 테이블에 관련된 조건을 검사한다. SCAN 노드에서 검사되는 조건은 다음과 같이 5 가지의 처리 방법으로 처리된다. y Fixed key range y Variable key range y Constant filter y Filter y Subquery filter EXPLAIN PLAN 으로 표시되는 SCAN 노드의 정보는 다음과 같다. 구분 설명 비고 SCAN 실행 노드의 이름 TABLE 접근하는 테이블의 이 름 ACCESS 실제 접근한 레코드의 개수 DISK_PAGE_COUNT테이블의 디스크 페이 지 개수 메모리 테이블은 해당 정보가 없음 SELF_ID 실행 노드의 ID [표 10-15] SCAN 노드의 정보 메모리 테이블과 디스크 테이블 메모리 테이블과 디스크 테이블은 서로 표현하는 정보가 약간 다르며, 디스크 테이블의 경우에만 해당 테이블이 소유한 디스크 페이지 개수의 정보를 출력한다. 다음은 메모리 테이블과 디스크 테이블의 SCAN 노드의 출력 정보를 비교한 것이다. 다음 예는 SYS 사용자의 기본 테이블스페이스가 SYS_TBS_MEMORY 로 지정되어 있는 경우이며, 메모리 테이블의 SCAN 노드 정보를 보이고 있다. SQL 튜닝 507 iSQL> create table m1 ( i1 integer ); Create sucess. iSQL> select * from m1; M1.I1 ----------- No rows selected. --------------------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: M1, FULL SCAN, ACCESS: 0, SELF_I D: 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, FUL SCAN, ACES: 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, ACCES: 0, SELF_ID: 0 ) ----------------------------- 액세스 방법 및 액세스 회수 질의 튜닝에 있어 가장 중요한 정보는 전체 스캔을 하는 지 인덱스를 사용하는 지의 여부와 얼마나 많은 레코드 접근이 이루어졌는 지를 판단하는 것이다. 레코드 접근이 많을수록 성능 저하의 요인이 되므로 이에 대한 판단을 하는 것이 매우 중요하다. 다음은 전체 스캔에 의하여 해당 질의를 처리한 경우이다. WHERE 절을 비교하기 위하여 접근한 레코드 수를 보이고 있다. 508 ALTIBASE5 Administrator’s Manual 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 sucess. 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, ACCES: 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, ACCES: 1, SELF_ID: 2 ) -------------------------------------- 이 때, T1.i2 칼럼에 인덱스를 추가하고 해당 인덱스를 사용하도록 질의를 수행하면 다음과 같은 실행 계획을 볼 수 있다. 아래에서 보듯이 동일한 질의임에도 불구하고 다른 인덱스를 사용하면 접근 효율이 떨어짐을 볼 수 있다. SQL 튜닝 509 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, ACCES: 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 로 사용함을 알 수 있다. 510 ALTIBASE5 Administrator’s Manual iSQL> alter system set trclog_detail_predicate = 1; Alter success. iSQL> alter session set explain plan = on; Alter success. iSQL> select * from t1 where i1 = 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)연산을 수행하는 물리 연산자이다. 하나의 자식 노드를 가지며 테이블에 직접 접근하지 않고 관련 조건을 검사한다. SQL 튜닝 511 EXPLAIN PLAN 으로 표시되는 FILT 노드의 정보는 다음과 같다. 구분 설명 비고 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 실행 노드 512 ALTIBASE5 Administrator’s Manual PROJ 실행 노드는 관계형 모델에서 프로젝션(project)연산을 수행하는 물리 연산자이다. 하나의 자식 노드를 가지며 자식 노드의 결과 레코드로부터 필요한 칼럼만을 추출한다. EXPLAIN PLAN 으로 표시되는 PROJ 노드의 정보는 다음과 같다. 구분 설명 비고 PROJECT 실행 노드의 이름 COLUMN_COUNT 프로젝션하는 칼럼의 개수 TUPLE_SIZE 프로젝션으로 추출하는 레코드 의 크기 [표 10-16] PROJ 노드의 정보 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 실행 노드는 관계형 모델에서 정렬 기반의 중복 검사를 수행하는 물리 연산자이다. 하나의 자식 노드를 가지며 자식 노드의 결과 레코드로부터 이전 레코드와 현재 레코드가 동일한 지를 판단한다. 다음과 같은 질의를 수행하는 데 사용된다. y 정렬 순서를 이용한 동일한 그룹 여부 판단 y 정렬 순서를 이용한 중복 제거 y 정렬 순서를 이용한 DISTINCT aggregation의 처리 EXPLAIN PLAN 으로 표시되는 GRBY 노드의 정보는 다음과 같다. 구분 설명 비고 GROUPING 실행 노드의 이름 [표 10-17] GRBY 노드의 정보 GRBY 실행 노드는 이름 외에 별도의 정보를 표시하지 않는다. SQL 튜닝 513 정렬 순서를 이용한 동일한 그룹 여부 판단 GRBY 노드가 정렬 순서를 이용한 동일한 그룹 여부를 판단하기 위해서 사용되는 경우 다음과 같은 형태로 실행 계획이 출력된다. 아래의 예를 보면 GRBY 노드가 (GROUP BY I3)를 처리하기 위해서 사용되었으며, GROUP BY 를 처리하기 위하여 별도의 저장 공간을 사용하지 않고 처리되었음을 알 수 있다. 이는 최적화 과정의 정렬 순서를 이용한 GROUP BY 의 처리를 통해 설명하였다. iSQL> select sum(i1) from t1group by i3; SUM(I1) --------------- 26838630 26841907 26845184 26848461 26851738 5 rows selected. ------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACESS: 16384, SELF_ID: 1 ) ------------------------------------------- 정렬 순서를 이용한 중복 제거 GRBY 노드가 정렬 순서를 이용한 중복 제거를 위해서 사용되는 경우 다음과 같은 형태로 실행 계획이 출력된다. 아래의 실행 계획을 통해 GRBY 노드는 (DISTINCT i3)를 처리하기 위해 사용되었으며, DISTINCT 를 위해 별도의 저장 공간을 사용하지 않았음을 알 수 있다. 이는 최적화 과정에서 정렬 순서를 이용한 DISTINCT 최적화에서 설명하였다. iSQL> select distinct i3from t1; I3 ----------- 0 1 2 3 4 5 rows selected. ------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACESS: 16384, SELF_ID: 0 ) ------------------------------ 정렬 순서를 이용한 DISTINCT agregation 처리 GRBY 노드가 정렬 순서를 이용한 DISTINCT aggregation 을 처리하기 위해서 사용되는 경우 다음과 같은 형태로 실행 계획이 514 ALTIBASE5 Administrator’s Manual 출력된다. 아래의 예를 살펴보면 ( COUNT(DISTINCT i2) )를 처리하는 과정에서 (DISTINCT i2)의 중복 제거를 위해서 GRBY 노드가 사용되었다. 이는 최적화 과정에서 정렬 순서를 이용한 DISTINCT aggregation 최적화에서 설명하였다. iSQL> select count(di st i nct i2) from t1; COUNT(distinct I2) ----------- 10 1 r ow sel ected. ------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATI ON ( I TEM_SI ZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_I D: 3, REF_I D: 1 ) GR OUP I N G SCAN ( TABLE: T1, I NDEX: I DX2, ACES: 16384, SELF_I D: 1 ) --------------------------- AGGR 실행 노드 AGGR 실행 노드는 관계형 모델에서 aggregation 연산을 수행하는 노드이다. 하나의 자식 노드를 가지며 별도의 중간 결과를 저장하기 위한 공간을 사용하지 않는다. 동일 그룹의 레코드들에 대하여 aggregation 을 수행한다. 다음과 같은 질의를 수행하는 데 사용된다. y 정렬 순서를 이용한 aggregation의 수행 y DISTINCT를 포함하는 aggregation의 수행 EXPLAIN PLAN 으로 표시되는 AGGR 노드의 정보는 다음과 같다. 구분 설명 비고 AGGREGATION 실행 노드의 이름 ITEM_SIZE 하나의 그룹을 위한 레코드 크기 GROUP_COUNT 실행 노드가 생성한 그룹의 개수 [표 10-18] AGGR 노드의 정보 정렬 순서를 이용한 aggregation 수행 AGGR 노드가 정렬 순서를 이용한 aggregation 수행에서 사용될 경우 다음 예와 같은 실행 계획 정보가 출력된다. 아래의 예를 살펴 보면, GRBY 실행 노드가 구분한 정보를 이용하여 AGGR 노드는 SUM(i2)를 수행한다. 이 때 구성되는 레코드는 그룹을 위한 레코드로 SUM(i2)와 GROUP BY i3 의 값으로 구성된다. 예에서는 16byte 의 레코드 크기의 그룹이 다섯 개가 구성되었음을 알 수 있다. SQL 튜닝 515 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 10 1030 5 rows selected. ------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCES: 16384, SELF_ID: 1 ) ------------------------------ VIEW 실행 노드 VIEW 실행 노드는 관계형 모델에서 가상 테이블을 표현하기 위한 노드이다. 사용자가 정의한 뷰 또는 집합 연산을 통해 생성되는 결과 집합을 하나의 테이블 개념으로 전환하는 역할을 한다. EXPLAIN PLAN 으로 표시되는 VIEW 노드의 정보는 다음과 같다. 516 ALTIBASE5 Administrator’s Manual 구분 설명 비고 VIEW 실행 노드의 이름 뷰 이름 뷰의 이름 이름이 있는 경우 ACCESS 뷰 레코드의 접근 회수 SELF_ID 노드의 ID [표 10-19] VIEW 노드의 정보 사용자가 정의한 뷰에 대한 질의가 수행될 경우 생성되는 VIEW 노드의 출력 예는 아래와 같다. VIEW 실행 노드 하위의 노드들은 사용자가 정의한 뷰의 SELECT 문에 대한 실행 계획을 의미한다. iSQL> create view v1(a1, a2) as select i3, sum(i2) from t1 group by i3; Create sucess. iSQL> select * fromv1; 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, ACCES: 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 의 결과를 하나의 테이블의 개념으로 관리하기 위해 생성되었으며, 별도의 이름을 갖지 않는다. SQL 튜닝 517 iSQL> select i1, i3 from t1 intersect select i3, i1 from t1; I1 I3 ----------------------- 1 1 2 2 3 3 4 4 4 rowselected. ---------------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) VIEW ( ACES: 4, SELF_ID: 2 ) SET-INTERSECT ( ITEM_SIZE: 24, ITEM_COUNT: 16384, BUCKET_COUNT: 8192, ACES: 4, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCES: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCES: 16384, SELF_ID: 1 ) ---------------------------------------------- VSCN 실행 노드 VSCN 실행 노드는 관계형 모델에서 임시 저장 뷰에 대한 검색 연산을 수행한다. 하나의 자식 노드를 가지면, 이는 항상 VMTR 실행 노드이다. 질의 최적화 과정에서 뷰의 결과를 저장 후 처리하는 것이 효율적이라 판단될 때 생성된다. EXPLAIN PLAN 으로 표시되는 VSCN 노드의 정보는 다음과 같다. 구분 설명 비고 VSCN 실행 노드의 이름 VIEW 뷰의 이름 ACCESS 뷰 레코드의 접근 회수 SELF_ID 노드의 ID [표 10-20] VSCN 노드의 정보 VSCN 노드가 사용되는 예는 아래와 같다. 아래 질의는 동일한 뷰에 대한 접근이 외부 질의와 부질의에서 모두 등장한다. 최적화 과정에서 해당 뷰를 임시 저장하여 질의를 수행하는 것이 효율적으로 판단되어 VMTR 노드를 이용하여 저장하고 이를 VSCN 노드로 접근하고 있는 실행 계획을 나타낸다. 518 ALTIBASE5 Administrator’s Manual iSQL> select * from v1 x where x.a2 > ( select avg(y.a2) from v1 y ); X.A1 X.A2 ------------------ 3 165361 4 168638 2 rows selected. ------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) FILTER ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 2 ) STORE ( ITEM_SIZE: 32, ITEM_COUNT: 1, ACES: 10, SELF_ID: 1, REF_ID: 4 ) VIEW ( ACES: 1, SELF_ID: 10 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 2 ) GROUP-AGGREGATION ( ITEM_SIZE: 64, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACESS: 1, SELF_ID: 9, REF_ID: 4 ) VI EW-SCAN ( VI EW: V1 Y, ACES: 5, SELF_ID: 4 ) MATERIALIZATION ( ITEM_SIZE: 24, ITEM_COUNT: 5 ) VIEW ( ACES: 5, SELF_ID: 7 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) AGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACES: 16384, SELF_ID: 1 ) ::SUB-QUERY END VI EW-SCAN ( VI EW: V1 X, ACCESS: 5, SELF_I D: 2 ) ------------------------------ 위의 실행 계획에서 (V1 X) 뷰에 대한 VSCN 노드는 자식 노드를 갖지 않는 것으로 보인다. 그러나, 해당 VSCN 노드는 VMTR(MATERIALIZATION 으로 표시) 노드를 자식 노드로 갖는다. 위 실행 계획의 일부를 도식화하면 아래 그림과 같다. VSCN (V1 X) PROJ FILT PROJ ... VSCN (V1 Y) VMTR VIEW ... SQL 튜닝 519 위의 그림에서와 같이 VSCN(V1 X)와 VSCN(V1 Y) 실행 노드는 동일한 자식 노드를 갖고 있다. CUNT 실행 노드 CUNT 실행 노드는 관계형 모델에서 GROUP BY 가 존재하지 않는 COUNT(*)에 대한 특수 처리를 위한 실행 노드이다. EXPLAIN PLAN 으로 표시되는 CUNT 노드의 정보는 다음과 같으며, SCAN 실행 노드와 유사한 정보로 구성된다. 구분 설명 비고 COUNT 실행 노드의 이름 TABLE 접근하는 테이블의 이 름 ACCESS 실제 접근한 레코드의 개수 DISK_PAGE_COUNT테이블의 디스크 페이 지 개수 메모리 테이블은 해당 정보가 없 음 SELF_ID 실행 노드의 ID [표 10-21] CUNT 노드의 정보 다음은 CUNT 실행 노드가 사용된 예이다. 아래의 예를 살펴보면 인덱스를 사용함으로서 실제 데이터에는 접근하지 않고 COUNT(*) 값을 획득하고 있음을 보여준다. iSQL> select count(*) from t1 where i1 > 1000; COUNT ------- 15384 1 row selected. ---------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) COUNT( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2, REF_ID: 2 ) ------------------ HIER 실행 노드 HIER 실행 노드는 관계형 모델에 없는 특수한 연산으로 계층 질의를 수행하는 노드이다. 하나의 자식 노드를 가지며, 자식 노드는 항상 SCAN 실행 노드이다. EXPLAIN PLAN 으로 표시되는 HIER 노드의 정보는 다음과 같다. HIER 실행 노드의 대부분의 정보는 SCAN 실행 노드와 유사하다. 구분 설명 비고 HIER 실행 노드의 이름 TABLE 접근하는 테이블의 이름 520 ALTIBASE5 Administrator’s Manual ACCESS 실제 접근한 레코드의 개수 DISK_PAGE_COUNT테이블의 디스크 페이지 개수 메모리 테이블 은 해당 정보가 없음 SELF_ID 실행 노드의 ID [표 10-22] HIER 실행 노드의 정보 계층 질의에 대한 실행 계획의 예는 다음과 같다. iSQL> select count(*) from t1 start with i3 = 0 conect by prior i3 = i1 ignore loop; COUNT ------------------- 3276 1 row selected. ------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATI ON ( I TEM_SI ZE: 24, GROUP_ COUNT: 1, BUCKET_COUNT: 1, ACES: 1, SELF_ID: 5, REF_ID: 2 ) HI ER ( TABLE: T1, I NDEX: I DX1, ACCESS: 3276, SELF_I D: 2 ) SCAN ( TABLE: T1, INDEX: IDX3, ACES: 3276, SELF_I D: 2 ) ------------------------------------------------ 단일 저장 노드 단일 저장 노드는 하나 이하의 자식 노드를 가지며, 해당 기능을 수행하기 위해 별도의 저장 공간을 필요로하는 노드이다. 위와 같은 특징을 갖는 각 실행 노드의 기능과, 실행 계획 에서의 분석 방법에 대하여 살펴본다. SORT 실행 노드 SORT 실행 노드는 관계형 모델에서 정렬 연산을 수행하는 노드이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN 으로 표시되는 SORT 노드의 정보는 다음과 같다. 구분 설명 비고 SORT 실행 노드의 이름 ITEM_SIZE 정렬을 위한 레코드의 크기 ITEM_COUNT 정렬에 포함된 레코드의 개수 SQL 튜닝 521 DISK_PAGE_COUNT임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부의 기준 노드 ID [표 10-23] SORT 노드의 정보 SORT 실행 노드는 매우 다양한 용도로 사용되며, 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. ORDER BY에서의 사용 ORDER BY 구문이 존재하고 별도의 정렬이 필요한 경우 SORT 실행 노드가 사용된다. 아래의 예에서와 같이 SORT 실행 노드는 ORDER BY 를 처리하기 위하여 사용되었다. iSQL> select i3, sum(i2) from t1 group by i 3 order by 2; I3 SUM(I2) ------------------ 0 155530 1 158807 2 162084 3 165361 4 168638 5 rowselected. ------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) SORT( ITEM_SIZE: 24, ITEM_COUNT: 5, ACCESS: 5, SELF_ID: 5, REF_ID: 2 ) AGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPI NG SCAN ( TABLE: T1, INDEX: IDX3, ACES: 16384, SELF_ID: 2 ) ------------------------------ GROUP BY에서의 사용 SORT 실행 노드는 GROUP BY 의 동일한 그룹을 분류하기 위한 정렬을 수행하기 위하여 생성될 수 있다. 아래의 예는 GROUP BY i4 를 처리하기 위하여 SORT 실행 노드가 생성된 경우이다. 522 ALTIBASE5 Administrator’s Manual 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 rowselected. ------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SORT ( ITEM_SIZE: 16, ITEM_COUNT: 16384, ACCESS: 16384, SELF_ID: 2, REF_ID: 1 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ------------------------------ DISTINCT에서의 사용 SORT 실행 노드는 DISTINCT 를 정렬 방식으로 중복 제거를 하기 위하여 사용될 수 있다. 아래의 예는 DISTINCT i4 를 처리하기 위하여 SORT 실행 노드가 생성된 경우이다. iSQL> select DISTINCT i4from t1; I4 ---------- 0 1 2 3 4 5 rows selected. ------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) GROUPING SORT( ITEM_SIZE: 16, ITEM_COUNT: 16384, ACESS: 16384, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: T1, FUL SCAN, ACCES: 16384, SELF_ID: 0 ) ------------------------------------ 조인에서의 사용 SORT 실행 노드는 조인을 수행하기 위하여 사용될 수 있다. 아래의 예는 조인을 처리하기 위하여 SORT 실행 노드가 생성된 경우이다. T1.i1 = T2.i1 조인 조건을 검사하기 위하여 sort- based 조인이 수행되었고, 이를 위해 SORT 실행 노드가 생성되었다. SQL 튜닝 523 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, ACCES: 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, ACESS: 16384, SELF_ID: 2 ) ------------------------------------------- HASH 실행 노드 HASH 실행 노드는 관계형 모델에서 해싱 연산을 수행하는 노드이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN 으로 표시되는 HASH 노드의 정보는 다음과 같다. 구분 설명 비고 HASH 실행 노드의 이름 ITEM_SIZE 해싱을 위한 레코드의 크 기 ITEM_COUNT 해싱에 포함된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개수 DISK_PAGE_COUNT임시 저장 테이블의 디스 크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접 근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여 부의 기준 노드 ID [표 10-24] HASH 노드의 정보 HASH 실행 노드는 매우 다양한 용도로 사용되며, 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. 조인에서의 사용 HASH 실행 노드는 조인을 수행하기 위하여 사용될 수 있다. 아래의 예는 조인을 처리하기 위하여 HASH 실행 노드가 생성된 524 ALTIBASE5 Administrator’s Manual 경우이다. T1.i1 = T2.i1 조인 조건을 검사하기 위하여 hash- based 조인이 수행되었고, 이를 위해 HASH 실행 노드가 생성되었다. iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1; COUNT --------------- 16384 1 row selected. ------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCES: 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, ACESS: 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, ACCES: 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, ACCES: 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, ACESS: 16384, SELF_ID: 2 ) :SUB-QUERY END ------------------------------- GRAG 실행 노드 SQL 튜닝 525 GRAG 실행 노드는 관계형 모델에서 해싱 방식의 그룹 및 aggregation 연산을 수행하는 노드이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN 으로 표시되는 GRAG 노드의 정보는 다음과 같다. 구분 설명 비고 GROUP- AGGREGATION 실행 노드의 이름 ITEM_SIZE 그룹을 위한 레코드의 크기 GROUP_COUNT 그룹화된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개 수 DISK_PAGE_COUNT임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부의 기준 노드 ID [표 10-25] GRAG 노드의 정보 아래의 예는 해싱 방식의 그룹 구분과 aggregation 연산을 처리하기 위하여 GRAG 실행 노드가 사용된 경우이다. GRAG 노드는 GROUP BY i4 와 AVG(i1), SUM(i2)를 처리하기 위하여 사용되었다. iSQL> select avg(i 1), sum(i 2) from t1 group by i4; AVG(I1) SUM(I2) --------------------- 8191 158807 8192 162084 8193 165361 8194 168638 8192.5 155530 5 rowselected. ------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 32 ) GROUP-AGGREGATI ON ( ITEM_SIZE: 80, GROUP_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 5, SELF_ID: 2, REF_ID: 1 ) SCAN ( TABLE: T1, FULL SCAN, ACCES: 16384, SELF_ID: 1 ) ------------------------------------ HSDS 실행 노드 HSDS 실행 노드는 관계형 모델에서 해싱 방식의 중복 제거 연산을 526 ALTIBASE5 Administrator’s Manual 수행하는 노드이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN 으로 표시되는 HSDS 노드의 정보는 다음과 같다. 구분 설명 비고 DISTINCT 실행 노드의 이름 ITEM_SIZE 중복 제거를 위한 레코 드의 크기 ITEM_COUNT 중복 제거된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개 수 DISK_PAGE_COUNT임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부의 기준 노드 ID [표 10-26] HSDS 노드의 정보 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, ACCES: 16384, SELF_ID: 0 ) -------------------------------- SQL 튜닝 527 UNI ON 에서의 사용 HSDS 실행 노드는 UNION 을 처리하기 위하여 사용될 수 있다. 아래의 예는 HSDS 실행 노드가 UNION 을 처리하기 위하여 중복 제거를 위해 사용된 예이다. iSQL> select i3, i4 from t1 unionselect i3, i4 from t2; I3 I4 ---------------- 1 1 2 2 3 3 4 4 0 0 5 rows selected. ---------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) DISTINCT ( ITEM_SIZE: 24, ITEM_COUNT: 5, BUCKET_COUNT: 16384, ACCESS: 5, SELF_ID: 4, REF_ID: 2 ) VIEW ( ACCESS: 32768, SELF_ID: 2 ) BAG-UNION PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ---------------------------------------- Subquery key range를 위한 사용 HSDS 실행 노드는 subquery key range 를 처리하기 위하여 사용될 수 있다. 중복 제거를 통해 동일한 값으로 인덱스를 이용한 검색이 발생하지 않도록 하기 위하여 사용된다. 아래의 예는 HSDS 실행 노드가 subquery key range 을 처리하기 위하여 중복 제거를 위해 사용된 예이다. HSDS 실행 노드는 T2.i4 값의 중복 제거를 위해서 사용되었다. 528 ALTIBASE5 Administrator’s Manual iSQL> select i1 from t1 where i1 in ( select i4 from t2 ); I1 ----------- 1 2 3 4 4 rowselected. --------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 4, SELF_ID: 1 ) :SUB-QUERY BEGI N PROJECT ( COLUMN_COUNT: 1, TUPLE_SI ZE: 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, ACES: 16384, SELF_ID: 2 ) :SUB-QUERY END --------------------------------------------- VMTR 실행 노드 VMTR 실행 노드는 뷰에 대한 임시 저장 테이블을 생성하는 노드이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN 으로 표시되는 VMTR 노드의 정보는 다음과 같다. 구분 설명 비고 MATERIALIZATION 실행 노드의 이름 ITEM_SIZE 저장된 레코드의 크기 ITEM_COUNT 저장된 레코드의 개수 [표 10-27] VMTR 노드의 정보 VMTR 실행 노드의 사용 예는 VSCN 실행 노드의 사용 예를 참조한다. STOR 실행 노드 STOR 실행 노드는 질의의 일부 결과를 임시 저장하는 노드이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN 으로 표시되는 STOR 노드의 정보는 다음과 같다. 구분 설명 비고 STORE 실행 노드의 이름 ITEM_SIZE 저장 레코드의 크기 ITEM_COUNT 저장에 포함된 레코드의 개수 SQL 튜닝 529 DISK_PAGE_COUNT임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부의 기준 노드 ID [표 10-28] STOR 노드의 정보 STOR 실행 노드는 매우 다양한 용도로 사용되며, 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. 조인에서의 사용 STOR 실행 노드는 조인에 사용될 수 있다. 일반적으로 조인 조건이 없는 카티션 프로덕트(cartesian product)에 주로 사용되며, 일반적인 조인에 사용되더라도 조인 조건을 자체적으로 처리하지는 않는다. 아래의 예는 STOR 실행 노드가 카티션 프로덕트를 위하여 사용된 경우이다. T1 테이블에 대한 검색을 완료한 결과를 저장함으로서 반복적인 인덱스 사용을 방지하는 효과를 얻을 수 있다. iSQL> select count(*) from t1, t2where t1.i1 < 5 and t2.i3 = 1; COUNT ----------------------- 13108 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATI ON ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCES: 1, SELF_ID: 5, REF_ID: 2 ) JOIN SCAN ( TABLE: T2, FUL SCAN, ACES: 16384, SELF_ID: 3 ) STORE ( I T EM_SI ZE: 16, I TEM_COUNT: 4, ACCES: 13108, SELF_ID: 4, REF_ID: 2 ) SCAN ( TABLE: T1, INDEX: IDX1, ACES: 4, SELF_ID: 2 ) ------------------------------------------------------------ LMST 실행 노드 LMST 실행 노드는 관계형 모델에서 제한된 정렬 연산을 수행하는 노드이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN 으로 표시되는 LMST 노드의 정보는 다음과 같다. 구분 설명 비고 LIMIT-SORT 실행 노드의 이름 530 ALTIBASE5 Administrator’s Manual ITEM_SIZE 정렬을 위한 저장 레코드의 크기 ITEM_COUNT 사용된 레코드의 개수 STORE_COUNT 저장된 레코드의 개수 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부 의 기준 노드 ID [표 10-29] LMST 노드의 정보 LMST 실행 노드는 매우 다양한 용도로 사용되며 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. ORDER BY에서의 사용 LMST 실행 노드는 LIMIT 을 포함한 ORDER BY 에 사용될 수 있다. 아래의 예는 LMST 실행 노드가 ORDER BY 를 위하여 사용된 경우이다. 실행 계획 정보를 살펴 보면, 저장 공간은 3 개만 사용하여 16384 건의 레코드에 대한 정렬을 수행함을 알 수 있다. iSQL> select * from t1 order by i4 limit 3; T1.I1 T1.I2 T1.I3 T1.I4 ------------------------------------ 15 15 0 0 10 10 0 0 5 5 0 0 3 rows selected. ---------------------------------------- PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 16 ) LIMIT-SORT( ITEM_SIZE: 16, ITEM_COUNT: 16384, STORE_COUNT: 3, ACCES: 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 값 중 일부만을 저장하여 이에 대한 비교 연산의 비용을 줄일 수 있도록 한다. SQL 튜닝 531 iSQL> select i1 from t1 where i1 <=ANY ( select i4from t2 ); I1 -------------- 1 2 3 4 4 rowselected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, FUL SCAN, ACES: 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 ( ACESS: 16384, SELF_ID: 3 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T2, FUL SCAN, ACES: 16384, SELF_ID: 2 ) :SUB-QUERY END ------------------------------------------------------------ 이진 비저장 노드 이진 비저장 노드는 두 개의 자식 노드를 가지며, 해당 기능을 수행하기 위해 별도의 저장 공간이 필요하지 않은 노드이다. 위와 같은 특징을 갖는 각 실행 노드의 기능과, 실행 계획에서의 분석 방법에 대하여 살펴본다. JOIN 실행 노드 JOIN 실행 노드는 관계형 모델에서 조인 연산을 수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN 으로 표시되는 JOIN 노드의 정보는 다음과 같다. 구분 설명 비고 JOIN 실행 노드의 이름 [표 10-30] JOIN 노드의 정보 JOIN 실행 노드는 거의 모든 일반 조인 수행을 위하여 사용된다. 다음과 같은 다양한 조인 방법들이 어떠한 형태로 실행 계획 트리가 출력되는 지를 살펴 본다. y Full nested loop join y Full store nested loop join y Index nested loop join y One-pass sort join 532 ALTIBASE5 Administrator’s Manual y Multi-pass sort join y One-pass hash join y Multi-pass hash join 각 실행 계획은 동일한 질의 수행 시 다양한 조인 방법으로 수행된 실행 계획 트리의 정보를 보이고 있다. 좌측은 조인 수행 방법에 대한 실행 트리의 일부를 그림으로 도식화한 내용이며, 우측은 실제 실행 계획의 출력 내용이다. Ful nested lop 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-AGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCES: 3277, SELF_ID: 2 ) SCAN ( TABLE: T2, FULL SCAN, ACES: 53690368, SELF_ID: 3 ) ------------ JOIN SCANSCAN 위의 실행 계획에서 조인 조건은 우측 SCAN 노드에서 처리되며, T2 테이블에 대한 반복적인 전체 검색을 통해 처리된다. Full store nested loop join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----- 3277 1 row selected. --------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGREGATION ( 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, ACCES: 10738729, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACES: 16384, SELF_ID: 3 ) ------------ JOIN SCANSTOR FILT SCAN 위의 실행 계획에서 조인 조건은 JOIN 상위의 FILT 노드에서 처리된다. T2 테이블에 대한 검색은 한 번만 이루어지며 그 결과를 저장한 후 반복적으로 전체 검색을 통해 처리된다. Index nested lop join의 실행 계획 트리 SQL 튜닝 533 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-AGREGATION ( 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, ACCES: 3277, SELF_ID: 3 ) ------------ JOIN SCANSCAN 위의 실행 계획에서 조인 조건은 우측 SCAN 노드에서 인덱스를 이용하여 처리된다. One-pas sort j oin의 실행 계획 트리 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-AGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCES: 3277, SELF_ID: 2 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACES: 16384, SELF_ID: 3 ) ------------ JOIN SCANSORT SCAN 위의 실행 계획에서 조인 조건은 우측 SORT 노드에서 정렬된 데이터를 이용하여 처리된다. Multi-pas 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-AGREGATION ( 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, ACCES: 3277, SELF_ID: 2 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 5, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACES: 16384, SELF_ID: 3 ) ------------ JOIN SORTSORT SCANSCAN 위의 실행 계획에서 조인 조건은 우측 SORT 노드에서 정렬된 데이터를 이용하여 처리되지만, 좌측에서 SORT 노드가 생성된다. 534 ALTIBASE5 Administrator’s Manual 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-AGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCES: 3277, SELF_ID: 2 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 3277, BUCKET_COUNT: 1024, ACCES: 3277, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACES: 16384, SELF_ID: 3 ) ------------ JOIN HASH SCAN SCAN 위의 실행 계획에서 조인 조건은 우측 HASH 노드에서 해싱된 데이터를 이용하여 처리된다. Multi-pass hash join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----- 3277 1 row selected. --------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGREGATION ( 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, ACCES: 3277, SELF_ID: 4, REF_ID: 2 ) SCAN ( TABLE: T1, INDEX: IDX3, ACCES: 3277, SELF_ID: 2 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 3277, BUCKET_COUNT: 1024, ACCES: 3277, SELF_ID: 5, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACES: 16384, SELF_ID: 3 ) ------------ JOIN HASH SCAN HASH SCAN 위의 실행 계획에서 조인 조건은 우측 HASH 노드에서 정렬된 데이터를 이용하여 처리되지만, 좌측에서 HASH 노드가 생성된다. MGJN 실행 노드 MGJN 실행 노드는 관계형 모델에서 머지 조인 연산을 수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. MGJN 실행 노드는 자식 노드로 SCAN, SORT, MGJN 중 하나를 취한다. EXPLAIN PLAN 으로 표시되는 MGJN 노드의 정보는 다음과 같다. 구분 설명 비고 MERGE-JOIN 실행 노드의 이름 [표 10-31] MGJN 노드의 정보 MGJN 실행 노드는 일반 조인 수행을 위하여 사용되며, 좌우 자식 노드를 모두 정렬하거나 정렬된 순서를 이용하여 처리한다. SQL 튜닝 535 자식 노드의 종류에 따라 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-AGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) MERGE-JOIN SCAN ( TABLE: T1, INDEX: IDX1, ACCES: 16384, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 16384, SELF_ID: 3 ) ------------ MGJN SCANSCAN 위의 실행 계획에서 조인 조건은 MGJN 노드에서 처리되며 기본 테이블과 반복 테이블의 개념이 없이 조인 조건에 포함된 칼럼의 인덱스를 모두 사용한다. 정렬을 이용한 머지 조인 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----- 3277 1 row selected. --------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGREGATION ( 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, ACES: 16384, SELF_ID: 2 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 5, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACES: 16384, SELF_ID: 3 ) ------------ MGJN SORTSORT SCANSCAN 위의 실행 계획에서 조인 조건은 MGJN 노드에서 처리되며 조인 조건에 포함된 칼럼을 기준으로 정렬한 후 이를 이용한다. LOJN 실행 노드 LOJN 실행 노드는 관계형 모델에서 LEFT OUTER JOIN 연산을 수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN 으로 표시되는 LOJN 노드의 정보는 다음과 같다. 구분 설명 비고 LEFT-OUTER- JOIN 실행 노드의 이름 [표 10-32] LOJN 노드의 정보 536 ALTIBASE5 Administrator’s Manual 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-AGREGATION ( 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, ACES: 16384, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 3277, SELF_ID: 3 ) ------------ LOJN SCANSCAN FOJN 실행 노드 FOJN 실행 노드는 관계형 모델에서 FULL OUTER JOIN 연산을 수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN 으로 표시되는 FOJN 노드의 정보는 다음과 같다. 구분 설명 비고 FULL-OUTER- JOIN 실행 노드의 이름 [표 10-33] FOJN 노드의 정보 FOJN 실행 노드는 일반 조인과 마찬가지로 대부분의 조인 방법이 사용되며, 이는 JOIN 노드의 예를 참조한다. 여기서는 FOJN 실행 노드가 사용되는 간단한 실행 계획 트리만을 살펴본다. iSQL> select count(*) from t1 ful 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-AGREGATION ( 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, ACES: 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, ACES: 16384, SELF_ID: 3 ) ------------ FOJN HASHSCAN SCAN FULL OUTER JOIN 의 특성 상 우측에 저장을 위한 NODE 가 생성되며, 위의 예에서 ON 조건은 HASH 노드에서 처리된다. SQL 튜닝 537 AOJN 실행 노드 AOJN 실행 노드는 관계형 모델에서 ANTI OUTER JOIN 조인 연산을 수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN 으로 표시되는 AOJN 노드의 정보는 다음과 같다. 구분 설명 비고 ANTI-OUTER- JOIN 실행 노드의 이름 [표 10-34] AOJN 노드의 정보 AOJN 실행 노드는 FULL OUTER JOIN 만을 위해 사용되며, 아래와 같이 ON 조인 조건에 대하여 모든 칼럼에 대하여 인덱스를 사용할 수 있을 때 사용된다. iSQL> select count(*) from t1 ful 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-AGREGATION ( 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, FUL SCAN, ACES: 22938, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 22938, SELF_ID: 3 ) ANTI-OUTER-JOIN SCAN ( TABLE: T2, FUL SCAN, ACES: 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 실행 노드의 이름 [표 10-35] CONC 노드의 정보 CONC 실행 노드는 FULL OUTER JOIN 의 처리와 DNF 처리에서 사용된다. FULL OUTER JOIN 에서의 사용은 AOJN 실행 538 ALTIBASE5 Administrator’s Manual 노드에서 이미 그 예를 설명하였으며, 여기서는 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-AGREGATION ( 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 인덱스를 모두 사용할 수 있으며 위 결과를 조합하기 위하여 CONC 실행 노드를 사용한다. FILT 실행 노드는 좌측 SCAN 과 중복되는 결과를 제거하기 위하여 사용된다. BUNI 실행 노드 BUNI 실행 노드는 관계형 모델에서 UNION ALL 연산을 수행하는 노드이다. 두 개 이상의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN 으로 표시되는 BUNI 노드의 정보는 다음과 같다. 구분 설명 비고 BAG-UNION 실행 노드의 이름 [표 10-36] BUNI 노드의 정보 BUNI 노드가 수행되는 예를 보면 다음과 같다. SQL 튜닝 539 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, FUL SCAN, ACES: 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, FUL SCAN, ACES: 16384, SELF_ID: 2 ) ------------ BUNI PROJPROJ 위의 예를 보면 BUNI 실행 노드는 두 질의의 결과를 단순히 조합하여 UNION ALL 을 처리한다. 이진 저장 노드 이진 저장 노드는 두개의 자식 노드를 가지며, 해당 기능을 수행하기 위해 별도의 저장 공간을 필요로하는 노드이다. 위와 같은 특징을 갖는 각 실행 노드의 기능과, 실행 계획 에서의 분석 방법에 대하여 살펴본다. SITS 실행 노드 SITS 실행 노드는 관계형 모델에서 INTERSECT 연산을 수행하는 노드이다. 두개의 자식 노드를 가지며, 교집합을 얻기 위하여 중간 결과를 저장하여 처리한다. EXPLAIN PLAN 으로 표시되는 SITS 노드의 정보는 다음과 같다. 구분 설명 비고 SET-INTERSECT 실행 노드의 이름 ITEM_SIZE 교집합을 위한 저장 레 코드의 크기 ITEM_COUNT 저장된 레코드의 개수 540 ALTIBASE5 Administrator’s Manual BUCKET_COUNT 해싱을 위한 버킷의 개 수 DISK_PAGE_COUNT임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID L_REF_ID 임시 테이블의 재구성 여부의 왼쪽 질의 기준 노드 ID R_REF_ID 임시 테이블의 재구성 여부의 오른쪽 질의 기 준 노드 ID [표 10-37] SITS 노드의 정보 SITS 실행 노드가 INTERSECT 를 위해 수행되는 예를 보면 다음과 같다. 좌측 질의의 결과 데이터를 중복 제거하여 저장하고, 우측 질의의 결과 데이터를 이용하여 교집합에 해당하는 결과를 검색하게 된다. iSQL> select i1, i3 from t1 intersect select i3, i1 from t2; I1 I3 ------ 1 1 2 2 3 3 4 4 4 rows selected. --------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) VIEW ( ACCESS: 4, SELF_ID: 2 ) SET-INTERSECT ( ITEM_SIZE: 24, ITEM_COUNT: 16384, BUCKET_COUNT: 8192, ACCESS: 4, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FUL SCAN, ACES: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T2, FUL SCAN, ACES: 16384, SELF_ID: 1 ) ------------ SITS PROJPROJ SDIF 실행 노드 SDIF 실행 노드는 관계형 모델에서 MINUS 연산을 수행하는 노드이다. 두 개의 자식 노드를 가지며, 차집합을 얻기 위하여 중간 결과를 저장하여 처리한다. EXPLAIN PLAN 으로 표시되는 SDIF 노드의 정보는 다음과 같다. 구분 설명 비고 SET-DIFFERENCE 실행 노드의 이름 ITEM_SIZE 차집합을 위한 저장 레 코드의 크기 SQL 튜닝 541 ITEM_COUNT 저장된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개 수 DISK_PAGE_COUNT임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID L_REF_ID 임시 테이블의 재구성 여부의 왼쪽 질의 기준 노드 ID R_REF_ID 임시 테이블의 재구성 여부의 오른쪽 질의 기 준 노드 ID [표 10-38] SDIF 노드의 정보 SDIF 노드가 MINUS 를 위해 수행되는 예를 보면 다음과 같다. 좌측 질의의 결과를 중복 제거하여 저장하고, 우측 질의의 결과를 이용하여 교집합을 구한 후 교집합에 포함되지 않은 결과만을 검색한다. iSQL> select i1, i3 from t1 minus select i1, i3 from t2; I1 I3 ------ No rows selected. --------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) VIEW ( ACCESS: 0, SELF_ID: 2 ) SET-DIFFERENCE ( ITEM_SIZE: 24, ITEM_COUNT: 16384, BUCKET_COUNT: 8192, ACCESS: 0, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FUL SCAN, ACES: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T2, FUL SCAN, ACES: 16384, SELF_ID: 1 ) ------------ SDIF PROJPROJ 다중 비저장 노드 다중 비저장 노드는 두개 이상의 자식 노드를 가지며, 해당 기능을 수행하기 위해 별도의 저장 공간을 필요로 하지 않는 노드이다. 위와 같은 특징을 갖는 각 실행 노드의 기능과, 실행 계획에서의 분석 방법에 대하여 살펴본다. PCRD 실행 노드 PCRD(Partition-Coordinator) 실행 노드는 파티션드 테이블의 각각의 파티션에 대한 스캔을 관리하는 노드이다. 여러 개의 자식 542 ALTIBASE5 Administrator’s Manual 노드를 가지며, 파티션 필터링을 수행한다. EXPLAIN PLAN 으로 표시되는 PCRD 노드의 정보는 다음과 같다. 구분 설명 비고 PARTITION- COORDINATOR실행 노드의 이름 TABLE 접근하는 테이블의 이름 PARTITION 접근하는 파티션의 개수 ACCESS 실제 접근한 레코드의 개수 SELF_ID 실행 노드의 ID [표 10-39] PCRD 노드의 정보 PCRD 노드가 수행되는 예를 보면 다음과 같다. 자식 노드인 파티션에 대한 스캔 결과를 상위 노드로 전달한다. iSQL> SELECT COUNT(*) FROM PDT_RANGE WHERE F1 < 30; COUNT ----------------------- 3 1 row selected. --------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 6, REF_ID: 2 ) SCAN ( PARTITION: P3, FULL SCAN, ACCESS: 1, DISK_PAGE_COUNT: 2, SELF_ID: 3 ) SCAN ( PARTITION: P2, FULL SCAN, ACCESS: 1, DISK_PAGE_COUNT: 2, SELF_ID: 4 ) SCAN ( PARTITION: P1, FULL SCAN, ACCESS: 1, DISK_PAGE_COUNT: 2, SELF_ID: 5 ) -------------------------------------- SQL 튜닝 543 힌트의 활용 힌트는 SQL 문 실행 계획을 사용자가 명시적으로 변경하고자 할 때 사용하는 기능이다. 사용자가 생성 가능한 SQL 문의 종류는 그 수를 헤아릴 수가 없으며, 동일한 질의라 하더라도 데이터의 구성에 따라 서로 다른 실행 계획이 생성될 수 있다. 최적화 과정이 보편적으로 효율적인 실행 계획을 생성하기는 하나 모든 질의에 있어 가장 좋은 실행 계획을 생성할 수 있는 것은 아니다. 이러한 단점을 보완하기 위하여 사용자는 힌트를 사용하여 실행 계획을 명시적으로 변경하여 보다 나은 성능을 얻을 수 있다. 그러나, 모든 질의에 대하여 힌트를 사용하여 실행 계획을 변경하는 것은 매우 불합리하다. 이는 인덱스의 생성, 데이터 구성의 변경등에 대하여 모든 질의에 대하여 다시 힌트를 작성해야 하는 부하가 따르게 된다. 따라서, 시스템의 성능에 영향을 미치는 일부 치명적인 질의에 한하여 힌트를 사용하는 것이 바람직하다. 힌트 처리 정책 사용자가 정의한 힌트는 다음과 같은 정책에 의하여 처리된다. 사용자가 정의한 힌트가 문법적으로 오류가 없고 실행이 가능한 경우 무조건 힌트를 따른다. 즉, 문법적으로 오류가 있는 경우나 실행이 불가능한 힌트는 적용하지 않는다. 힌트 적용 시 사용자가 정의한 힌트에 단순히 가중치를 부여하는 것이 아니며, 사용자가 모든 정보를 고려하여 가장 효율적인 실행 계획을 이미 알고 있음을 가정한다. 힌트가 서로 상충할 경우 그 유형에 따라 다음과 같은 우선 순위를 따른다. y 최적화 적용 기준 y 정규화 형태 y 조인 순서 y 조인 방법 y 중간 결과 저장 매체 y 해싱 버켓 크기 y 그룹 처리 방법 y 중복 제거 처리 방법 y 뷰 최적화 방법 y 액세스 방법 544 ALTIBASE5 Administrator’s Manual 힌트의 종류 최적화 적용 기준 최적화를 규칙 기반으로 수행할 것인지, 비용 기반으로 수행할 것인지를 설정하는 힌트이다. y RULE: 비용을 배제한 실행 계획 생성 y COST: 비용을 고려한 실행 계획 생성 질의에 따라 항상 같은 실행 계획이 생성되길 원한다면 RULE 힌트를 지정하며, 데이터 양의 변경량이 커 조인 순서등에 많은 영향을 미친다면 COST 를 지정해 주는 것이 좋다. 해당 힌트를 사용하지 않을 경우 기본적으로 비용 기반 최적화를 수행한다. 정규화 형태 정규화 방법을 SQL 문 단위로 설정할 수 있게 하는 힌트이다. y CNF: Conjunctive Normal Form으로 정규화 y DNF: Disjunctive Normal Form으로 정규화 해당 힌트가 사용되지 않을 경우 두 정규화의 비용 비교를 통하여 하나의 정규화 방법을 선택한다. 조인 순서 조인 순서를 결정하는 힌트이다. y ORDERED: FROM절에 나열된 순서대로 조인 순서를 결정 해당 힌트가 사용되지 않을 경우 비용 비교를 통하여 조인 순서를 결정한다. 조인 방법 조인 방법을 결정하는 힌트이다. y USE_NL: Nested loop 계열의 조인 방법을 사용 y USE_SORT: Sort-based 계열의 조인 방법을 사용 y USE_HASH: Hash-based 계열의 조인 방법을 사용 y USE_MERGE: Merge 조인 계열의 조인 방법을 사용 조인 방법에 대한 힌트는 다음과 같은 처리 방법에 의하여 조인 방법을 결정한다. y 내부 테이블 순서로 조인 가능성 검사 예를 들어, USE_NL(T1, T2) 힌트인 경우 T1 => T2 로의 조인 가능 여부를 검사한다. y 내부 테이블 역순으로 조인 가능성 검사 위의 검사에서 해당 순서로 조인을 적용할 수 없는 경우 그 SQL 튜닝 545 역순의 T2 => T1 의 순서로 조인 가능 여부를 검사한다. y 두 순서를 모두 적용할 수 없는 조인 방법인 경우 비용 비교를 통하여 새로운 조인 방법을 선택한다. y ORDERED 힌트와 상충되는 경우 ORDERED 힌트와 USE_NL 힌트의 테이블 순서는 서로 상충되며 우선 순위에 의하여 ORDERED 힌트를 따른다. 예를 들어, 다음과 같은 질의가 있다고 가정하자 SELECT /*+ ORDERED USE_NL(T2, T1) */ FROM T1, T2 WHERE T1.i1 = T2.i1; y 동일 테이블들에 대하여 여러 가지 조인 방법 힌트가 사용될 경우 나열된 방법 중 비용 평가를 통해 가장 효율적인 것을 선택한다. USE_NL(T1, T2) USE_HASH(T2, T1) 중간 결과 저장 매체 중간 결과를 저장하기 위한 임시 테이블의 저장 매체를 지정하는 힌트이다. y TEMP_TBS_MEMORY: 질의에서 사용되는 모든 중간 결과 저장을 위해 메모리 임시 테이블을 사용한다. y TEMP_TBS_DISK: 질의에서 사용되는 모든 중간 결과 저장을 위해 디스크 임시 테이블을 사용한다. TEMP_TBS_MEMORY 의 경우 성능향상을 위해 저장되는 중간 결과의 크기가 적을 경우에 사용하는 것이 바람직하며, TEMP_TBS_DISK 는 성능 저하를 감안하더라도 리소스 절약을 위해 저장되는 중간 결과의 크기가 매우 큰 경우에 사용하는 것이 바람직하다. 해싱 버켓 크기 해싱 기법을 사용하는 실행 노드들의 버켓 개수를 조정하기 위하여 사용한다. y HASH BUCKET COUNT: HASH, HSDS 노드의 해시 버켓 수 변경 y GROUP BUCKET COUNT: GRAG, AGGR 노드의 해시 버켓 수 변경 y SET BUCKET COUNT: SITS, SDIF 노드의 해시 버켓 수 변경 그룹 처리 방법 GROUP BY 등의 처리 방법을 결정하기 위하여 사용한다. y GROUP_HASH: 해싱 방식에 의한 처리 y GROUP_SORT: 정렬 방식에 의한 처리 546 ALTIBASE5 Administrator’s Manual 중복 제거 처리 방법 DISTINCT 의 처리 방법을 결정하기 위하여 사용한다. y DISTINCT_HASH: 해싱 방식에 의한 처리 y DISTINCT_SORT: 정렬 방식에 의한 처리 뷰 최적화 방법 뷰 외부의 WHERE 절의 조건을 뷰 내부에서 처리할 것인지의 여부를 결정하기 위하여 사용한다. y NO_PUSH_SELECT_VIEW: 외부의 WHERE 절의 조건을 뷰 내부로 이동하여 처리하지 않는다. y PUSH_SELECT_VIEW: 외부의 WHERE 절의 조건 중 가능한 것은 모두 뷰 내부로 이동하여 처리 y PUSH_PRED: 외부의 WHERE절의 조건 중 뷰와 관계된 조인조건을 뷰 내부로 이동하여 처리 액세스 방법 테이블 접근 방법을 제어하는 힌트이다. y FULL SCAN: 테이블에 이용 가능한 인덱스가 존재하더라도 인덱스를 사용하지 않고 테이블 전체 스캔 y INDEX: 나열된 index중 하나를 이용해 인덱스 스캔 y INDEX ASC: 나열된 index중 하나를 이용해 인덱스 오름차순 스캔 (ascending index scan) y INDEX DESC: 나열된 index중 하나를 이용해 인덱스 내림 차순 스캔 (descending index scan) y NO INDEX: 나열된 인덱스들은 최적화 과정에서 배제 위의 힌트들은 뷰 내부에 사용된 테이블의 인덱스 이름을 힌트 구문에 사용하면, 뷰에 대해서도 일반 테이블처럼 인덱스 힌트를 줄 수 있다. 액세스 방법을 제어하는 힌트는 여러 개가 사용될 수 있으며 다음과 같은 정책에 의하여 처리된다. y 나열된 힌트가 상충하는 경우, 나열된 순서대로 힌트를 적용한다. 뒤의 힌트는 무시한다. 예제: INDEX(T1, IDX1) NO INDEX(T1, IDX1) y 상충되지 않을 경우 힌트에 나열된 액세스 방법 중 비용 계산에 의하여 보다 효율적인 액세스 방법을 선택한다. 예제: FULL SCAN(T1), INDEX(T1, IDX1) 조인 방법 힌트와 함께 사용될 경우 액세스 힌트와 조인 방법 힌트는 별개의 것으로 처리된다. USE_HASH(T1, T2), INDEX(T2, IDX2) SQL 튜닝 547 인덱스를 사용하나 Hash-based 조인 방법으로 처리한다. 즉, Index nested loop 조인 방법을 사용하지 않는다. Explain Plan 549 11. Explain Plan 550 ALTIBASE5 Administrator’s Manual Explain Plan 의 정의 질의를 최적화하는 것은 SQL 문이 얼마나 빨리 실행될 수 있는가에 있어서 크게 영향을 준다. Explain plan 은 알티베이스 DBMS 서버가 최적화된 질의를 실행하기 위해 수행하는 접근 경로를 설명한다. 즉, SQL 문의 성능을 향상시키고 execution plan (이하 plan tree)을 결정하기 위하여 explain plan 명령을 사용한다. Plan Tree 의 이해 많은 테이블들로부터 데이터를 검색하는 SQL 문은 같은 결과 집합을 얻기 위하여 다양한 방법 (테이블을 조인하는 방법, 조인 순서, 그리고 접근 경로 등)을 사용할 수 있다. 알티베이스는 다음과 같은 다양한 요소들을 근거로 한 기능들에 대한 적합한 경로를 분석한다. y 사용 가능한 인덱스들 y SQL문 내에서의 테이블들과 열들의 순서 y 최적화 기법 SQL 문의 plan tree 는 explain plan 명령을 통해 보여진다. 사용자들은 plan tree 를 검사함으로써 알티베이스가 SQL 문을 어떻게 실행하고 있는가를 정확하게 볼 수 있다. Plan Tree 의 분석 Explain plan 명령은 SQL 문을 직접 실행하지 않고도 plan tree 를 생성함으로써 SQL 문의 실행 방법뿐만 아니라 다른 plan tree 와 비교하여 SQL 문의 성능을 향상할 수 있다. Plan tree 에서는 다음과 같은 정보를 얻을 수 있다: y SQL문 최적화에 따른 실행 경로 y Objects (테이블, 인덱스, 등)의 속성 y 사용된 index y 사용된 조인 방법 y Optimization에 따른 조인 순서 성능 분석 개선된 SQL 문의 성능을 입증하는 방법은 다음과 같다. Explain Plan 551 y 새로운 SQL문을 실행하고 그 결과를 비교한다. y 새로운 plan tree를 생성하고, 그것을 이전의 plan tree와 비교한다. y Object(테이블, 인덱스 등)의 속성들이 정확한가를 확인하기 위하여 속성들을 재검토한다. Plan Tree Display 기능 iSQL 에서 EXPLAIN PLAN 을 설정(ALTER SESSION SET EXPLAIN PLAN = ON/OFF/ONLY;)한 후 selection 기능을 수행하는 SQL 문을 실행하면 다음 option 에 따라 plan tree 를 텍스트 형태로 볼 수 있다. y ON 질의 수행 후 출력하며, plan tree와 access 횟수, memory size 등을 출력 y OFF plan tree 출력하지 않음. y ONLY 질의 수행하지 않고, plan tree만 출력 iSQL> ALTER SESION SET EXPLAIN PLAN = ON; Alter success iSQL> SELECT ename FROM employe WHERE emp_job = PROGRAMER; ENAME ------------------ HYCHOI YHBAE 2 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 2 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) ----------------------------------- iSQL> ALTER SESION SET EXPLAIN PLAN = OFF; Alter success iSQL> SELECT ename FROM employe WHERE emp_job = PROGRAMMER; ENAME ------------------ HYCHOI YHBAE 2 rows selected. iSQL> ALTER SESION SET EXPLAIN PLAN = ONLY; Alter success iSQL> SELECT ename FROM employe 552 ALTIBASE5 Administrator’s Manual WHERE emp_job = PROGRAMMER; ENAME ------------------ No rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 2 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: ?, SELF_ID: 2 ) ----------------------------------- * EXPLAN PLAN = ONLY 인 경우 질의 실행 없이 실행 계획만 생성하므로 ACCESS 항목과 같이 실제 실행 후 그 값이 결정되는 항목들은 ??로 표시된다. Explain Plan 553 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 ------------------ DKIM 1 row selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 2 ) 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 ----------------------------------- 23. orders 테이블에 있는 주문 번호(ono)를 index 를 이용하여 검 색한다. index 를 이용한 access 회수는 20 임을 알 수 있다. (index 가 생성되지 않은 열을 이용하여 검색을 한다면 조건에 만족하는 열들을 찾기 위해서 orders 테이블을 full scan 해야 한다. 즉, 각각의 plan 에 대한 비용을 측정하고, 그 비용을 비교 해서 가장 비용이 적게 드는 plan 을 선택하기 위하여 full scan 을 이용할 것인가, index 를 생성해서 scan 을 할 것인가를 plan nodes 를 통해서 비교해 선택할 수 있다.) PROJECT SCAN PROJECT SCAN CUSTOMER ORDERS 4 3 2 1 5 4 3 2 1 554 ALTIBASE5 Administrator’s Manual 24. orders 테이블에서 cno 인 열을 찾아 열의 개수가 하나인 새로운 relation1 을 만든다. 25. c.cno = o.cno 를 검색하기 위해 full scan 을 한다. access 의 회수는 customer 테이블에 있는 레코드 개수(20)만큼이다. 26. customer 테이블에서 cname 인 열을 찾아 새로운 relation2 를 만든다. 27. relation2 를 출력한다. Explain Plan 555 Plan Nodes Plan Tree 는 특정한 SQL 문을 위해 생성된 실행 계획으로, Plan Nodes 는 Plan tree 를 구성하는 각 노드(node)를 의미한다. Plan Node 는 execution algebra 또는 relational algebra 라고도 한다. Plan Node 의 종류 Child Plan 의 개수 또는 구현(materialization) 여부에 의해 나눌 수 있다. Child Plan 의 개수에 따른 구분 y One-child Node Child node가 0개 또는 하나인 plan node를 의미한다. y Binary Node (Two-child Node) Child node가 두 개인 plan node를 의미한다. y Multi-child Node Child node가 두 개 이상인 plan node를 의미한다. Material ization 여부에 의한 구분 y Non-materialized Node 중간 결과를 저장하지 않고, 한 번에 한 개의 레코드를 처리하는 plan node를 의미한다. y Materialized Node Child에 해당하는 node를 모두 수행하여 그 중간 결과를 저장하는 plan node를 의미한다. 556 ALTIBASE5 Administrator’s Manual Node Non-materialized Materialized Name Meaning Name Meaning One- child 기 본 SCAN Selection SORT Sort FILTER Filter HASH Hash PROJECT Projection 그 룹 GROUPING Group By GROUP- AGGREGATION Group Aggregation AGGREGATION Aggregation COUNT Count(*) 뷰 VIEW View MATERIALIZA TION View Materialization VIEW-SCAN View Scan 기 타 HIERARCHICA L QUERY Hierarchy DISTINCT Hash Distinct LIMIT-SORT Limit Sort Two- child 조 인 JOIN Join MERGE-JOIN Merge Join LEFT-OUTER- JOIN Left Outer Join FULL- OUTER-JOIN Full Outer Join ANTI-OUTER- JOIN Anti Outer Join 집 합 함 수 BAG-UNION Bag Union SET- INTERSECT Set Intersect SET- DIFFERENCE Set Difference 기 타 CONCATENATI ON Concatenation Multi -child 기 타 PARTITION- COORDINATOR Partition- Coordinator [ 표 11-1] Plan Node의 종류 AGGREGATION 정의 중복이 제거된 집합(Distinct aggregation) 기능을 수행한다. Aggregation 수행 시 인자로서 distinct column 이 존재하면 distinct 대상이 되는 열의 유일성을 검사하기 위해서 GROUP- AGGREGATION node 와는 별도로 수행된다. 형식 Explain Plan 557 AGGREGATION ( ITEM_SIZE: item_size, GROUP_COUNT: group_count ) item_size 저장하는 item 의 크기 group_count 총 group 의 개수 예제 총 부서의 수와 모든 사원들의 평균 급여를 출력하라. iSQL> SELECT COUNT(DISTINCT dno), AVG(salary) FROM employee; COUNT(DISTINCT DNO) AVG(SALARY) --------------------------- 5 1836647.06 1 row selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 30 ) AGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 1 ) SCAN ( TABLE: EMPLOYE, 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 ----------------------------------- A01 응용기술팀 D01 엔진개발팀 C01 마케팅팀 C02 기획관리팀 F01 영업팀 A101 A102 B101 C101 C102 558 ALTIBASE5 Administrator’s Manual D101 D102 D103 D104 D105 D106 D107 D108 D109 D1010 D101 E101 E102 E103 E104 E105 E106 E107 E108 E109 E1010 E101 E1012 E1013 F101 35 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 29 ) CONCATENATION LEFT-OUTER-JOIN SCAN ( TABLE: DEPARTMENT D, FULL SCAN, ACESS: 35, SELF_ID: 1 ) SCAN ( TABLE: GOODS G, INDEX: GDS_IDX1, ACCES: 35, SELF_ID: 2 ) [ VARIABLE KEY ] OR AND D.DEP_LOCATION = G.GODS_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.GODS_LOCATION ----------------------------------- BAG-UNION 정의 Bag Union 기능을 수행하며 두 개 이상의 child node 를 갖는 node 이다. SQL 문의 UNION ALL 에 해당한다. 형식 Explain Plan 559 BAG-UNION 예제 이름이 KMLEE 와 급여가 2000000 보다 큰 사원의 이름과 급여를 출력하라. iSQL> SELECT ename, salary FROM employe WHERE ename = KMLE UNION AL SELECT ename, salary FROM employe WHERE salary > 200; ENAME SALARY ---------------------------- KMLEE 12000 SJKIM 250 YHBAE 40 MSKIM 2750 KCJUNG 2030 JHCHOI 230 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: EMPLOYE, FULL SCAN, ACCESS: 20, DISK_PAGE_COUNT: 2, SELF_ID: 2 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 29 ) SCAN ( TABLE: EMPLOYE, 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 을 수행한다. 형식 CONCATENATION 예제 ANTI-OUTER-JOIN node 예제 참고 COUNT 560 ALTIBASE5 Administrator’s Manual 정의 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: EMPLOYE, FULL SCAN, ACCESS: 1, SELF_ID: 1, REF_ID: 1 ) ----------------------------------- 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 이 될 경우 Explain Plan 561 DISTINCT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장한 item의 개수 bucket_count hash bucket의 개수 page_count, page의 개수 acc_num 접근 횟수 self_id node ID ref_id 참조하는 node의 ID 예제 상품 C111100001 을 주문한 고객이름을 출력하라. iSQL> SELECT DISTINCT customer.cname FROM customer WHERE customer.cno IN (SELECT orders.cno FROM orders WHERE orders.gno = BYTEC111100001); CNAME ------------------ YSKIM DKIM IJLE CHLE 4 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 2 ) DISTINCT ( ITEM_SIZE: 24, ITEM_COUNT: 4, BUCKET_COUNT: 1024, ACCESS: 4, SELF_ 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 ----------------------------------- 562 ALTIBASE5 Administrator’s Manual FILTER 정의 Selection 기능을 수행하며 하위 node 로부터 조건에 맞는지를 검사한다. 형식 FILTER 예제 2 개 이상 주문된 상품번호와 주문양을 출력하라. iSQL> SELECT gno, COUNT(*) FROM orders GROUP BY gno HAVING COUNT(*) > 2; GNO COUNT --------------------------- A102 3 C101 4 D108 3 E1012 3 4 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) FILTER AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 16 ) GROUPING SCAN ( TABLE: ORDERS, INDEX: ODR_IDX3, ACCES: 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; Explain Plan 563 DNO DNAME GNO ----------------------------------- A101 A102 B101 C101 C102 D101 D102 D103 D104 D105 D106 D107 D108 D109 D1010 D101 E101 E102 E103 E104 F02 headquarters E105 E106 E107 E108 E109 E1010 E101 E1012 E1013 F101 A01 응용기술팀 D01 엔진개발팀 C02 기획관리팀 C01 마케팅팀 F01 영업팀 B01 Quality Asurance 36 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 29 ) FUL-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, ACESS: 36, SELF_ID: 1 ) ----------------------------------- GROUP-AGGREGATION 정의 Group aggregation 기능을 수행하며 materialized node 이다. 형식 564 ALTIBASE5 Administrator’s Manual 1) 메모리에 materialization 이 될 경우 GROUP-AGGREGATION ( ITEM_SIZE: item_size, GROUP_COUNT: group_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) 2) 디스크에 materialization 이 될 경우 GROUP-AGGREGATION ( ITEM_SIZE: item_size, GROUP_COUNT: group_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 group_count 저장한 group의 개수 bucket_count Hash bucket의 개수 page_count Page의 개수 acc_num 접근 횟수 self_id node ID ref_id 참조하는 node ID 예제 각 부서내에서 각 직위에 대해 지급되는 급여 총액을 출력하라. (여러 열에 GROUP BY 절을 사용) iSQL> SELECT dno, emp_job, COUNT(emp_job) num_emp, SUM(salary) sum_sal FROM employee GROUP BY dno, emp_job; DNO EMP_JOB NUM_EMP SUM_SAL ----------------------------------- CEO 1 C02 DESIGNER 2 380 D01 ENGINER 3 630 A01 PROGRAMER 2 570 A01 MANAGER 1 50 D01 MANAGER 1 C02 PLANER 2 310 C01 WEBMASTER 2 3750 F01 SALESMAN 3 3690 C01 CEO 1 980 D01 CEO 1 2030 C02 CEO 1 140 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: EMPLOYE, FUL SCAN, ACES: 20, DISK_ P A G E_ C O UNT: 2, S E L F_ ID: 1 ) GROUPING Explain Plan 565 정의 하위 그룹으로부터 얻은 데이터가 동일한 group인지 판단한다. 형식 GROUPING 예제 각 사원이 담당한 고객들의 수와 각 고객에게 판매한 상품의 총 수를 출력하라. iSQL> SELECT eno, COUNT(DISTINCT cno), SUM(qty) FROM orders GROUP BY eno; ENO COUNT(DISTINCT CNO) SUM(QTY) ----------------------------------- 12 8 17870 19 5 25350 20 4 13210 3 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 24 ) AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 3 ) GROUPING SCAN ( TABLE: ORDERS, INDEX: ODR_IDX1, ACCESS: 30, DISK_PAGE_COUNT: 2, SELF_ID: 1 ) ----------------------------------- HASH 정의 Hash Search 기능을 수행하며, materialized node 이다. 형식 1) 메모리에 materialization이 될 경우 HASH ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) 2) 디스크에 materialization이 될 경우 HASH ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장한 item의 개수 bucket_count hash bucket의 개수 page_count page의 개수 acc_num 접근 횟수 566 ALTIBASE5 Administrator’s Manual self_id tuple set 내의 ID, node ID로 봐도 무관 ref_id 참조하는 node의 ID 예제 임의의 부서를 가지고 있는 관리자의 이름과 부서 이름을 출력하라. iSQL> CREATE TABLE manager( eno INTEGER PRIMARY KEY, mgr_no INTEGER, mname VARCHAR(20), address VARCHAR(60)) TABLESPACE user_data; Create success. iSQL> INSERT INTO manager VALUES(2, 1, HJNO, 1 Inyoung Bldg. Nonhyun-dong Kangnam-gu Seoul, Korea); 1 row inserted. iSQL> INSERT INTO manager VALUES(7, 2, HJMIN, 4-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: 4 ) JOIN SCAN ( TABLE: DEPARTMENT D, FUL SCAN, ACES: 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를 처리하는 노드이다. 형식 1) 인덱스 사용하는 경우 Explain Plan 567 HIER ( TABLE: table_name, FULL SCAN, ACCESS: acc_num, SELF_ID: node_id ) 2) 인덱스 사용하지 않는 경우 HIER ( TABLE: table_name, INDEX: index_name, ACCESS: acc_num, SELF_ID: node_id ) table_name table 이름 FULL SCAN index 사용 안함 index_name 사용하는 index acc_num record 접근 횟수 node_id tuple set 내에서의 ID (node의 ID로 간주) 예제 ID 열의 값이 0인 행을 루트로 하는 행들을 얻기 위한 계층적 질의문 은 다음과 같다. iSQL> CREATE TABLE hier_order(id INTEGER, parent INTEGER); Create success. iSQL> INSERT INTO hier_order VALUES(0, NULL); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(1, 0); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(2, 1); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(3, 1); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(4, 1); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(5, 0); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(6, 0); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(7, 6); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(8, 7); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(9, 7); 1 row inserted. iSQL> INSERT INTO hier_order VALUES(10, 6); 1 row inserted. iSQL> SELECT id, parent, level FROM hier_order START WITH id = 0 CONNECT BY PRIOR id = parent ORDER BY level; ID PARENT LEVEL ----------------------------------- 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 568 ALTIBASE5 Administrator’s Manual 8 7 4 9 7 4 11 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 16 ) SORT ( ITEM_SIZE: 24, ITEM_COUNT: 11, ACESS: 11, SELF_ID: 5, REF_ID: 2 ) HIER ( TABLE: HIER_ORDER, FULL SCAN, ACCES: 132, SELF_ID: 2 ) SCAN ( TABLE: HIER_ORDER, FULL SCAN, ACES: 132, SELF_ID: 2 ) ----------------------------------- 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; ENO ENAME DNO DNAME ----------------------------------- 0, NULL 1, 0 5, 0 6, 0 2, 1 3, 1 4, 1 7, 6 10, 6 8, 7 9, 7 Level 3 4 2 1 < 계층적 leaf 구조 > 루트/부모 부모/자식 자식/리프 부모/자식 자식/리프 자식/리프 자식/리프자식/리프 자식/리프자식/리프 부모/자식 Explain Plan 569 2 HJNO C02 기획관리팀 5 SJKIM D001 엔진개발팀 8 JDLEE D001 엔진개발팀 12 MYLE F01 영업팀 4 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 52 ) JOIN SCAN ( TABLE: EMPLOYE E, FULL SCAN, ACCES: 20, SELF_ID: 2 ) [ FILTER ] AND OR TO_CHAR(JOIN_DATE, YYYY-MM-DD HH:MI:SS) < 2000-01-01 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(BYTEB01, Quality Asurance, 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 ------------------------- A01 HYCHOI A01 HJMIN A01 YHBAE B01 C01 MSKIM C01 KWKIM C01 JHSEOUNG C02 HJNO C02 KMLE C02 JHCHOI C02 DIKIM C02 CHLE 570 ALTIBASE5 Administrator’s Manual D01 HSCHOI D001 KSKIM D01 SJKIM D01 JDLE D01 KCJUNG F01 MYLE F01 KMKIM F01 DIKIM F02 21 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 24 ) LEFT-OUTER-JOIN SCAN ( TABLE: DEPARTMENT D, INDEX: _SYS_IDX_ID_62, ACES: 7, SELF_ID: 1 ) SCAN ( TABLE: EMPLOYE E, INDEX: EMP_IDX1, ACES: 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, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장할 item의 개수 store_count 실제 정렬된 item의 개수 acc_num 접근 횟수 self_id tuple set 내의 ID, node ID로 봐도 무관 ref_id 참조하는 node의 ID 예제 모든 사원의 이름, 부서 번호 및 급여를 표시하고 부서 번호를 기준 으로 정렬한 후 급여를 기준으로 해서 내림차순으로 상위 10개만 출 력하라. (ORDER BY 목록의 순서가 정렬 순서임.) iSQL> SELECT ename, dno, salary FROM employee ORDER BY dno, salary DESC LIMIT 10; ENAME DNO SALARY ----------------------------------- YHBAE A001 4000000 HYCHOI A01 170 Explain Plan 571 HJMIN A01 50 MSKIM C01 2750 JHSEOUNG C001 1000000 KWKIM C01 980 JHCHOI C02 230 CHLE C02 190 HJNO C02 150 DIKIM C02 140 10 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 3 ) LIMIT-SORT ( ITEM_SIZE: 16, ITEM_COUNT: 20, STORE_COUNT: 10, ACCESS: 10, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: EMPLOYE, FULL SCAN, ACCESS: 20, SELF_ID: 0 ) ----------------------------------- MATERIALIZATION 정의 View의 빠른 처리를 위해 생성되는 node 이다. 하위 VIEW node에 의해 생성된 record를 하나의 가상 table (view)로 저장한다. 형식 MATERIALIZATION ( ACCESS: acc_num, SELF_ID: self_id ) acc_num 접근 횟수 self_id node ID 예제 해당 부서의 평균 급여보다는 급여를 많이 받고, 가장 높은 평균 급 여보다는 적게 받는 사원의 이름, 부서 번호, 급여를 출력하라. iSQL> CREATE VIEW v1 AS (SELECT dno, AVG(salary) avg_sal FROM employe GROUP BY dno); Create success. iSQL> SELECT ename, e.dno, e.salary FROM employee e, v1 WHERE e.dno = v1.dno AND e.salary > v1.avg_sal AND e.salary < (SELECT MAX(avg_sal) FROM v1); ENAME DNO SALARY ----------------------------------- CHLE C02 190 MYLE F01 1890 2 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 3 ) JOIN VIEW-SCAN ( VIEW: V1, ACESS: 6, SELF_ID: 3 ) MATERIALIZATION ( ITEM_SIZE: 32, ITEM_COUNT: 6 ) VIEW ( ACCESS: 6, SELF_ID: 8 ) 572 ALTIBASE5 Administrator’s Manual 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: EMPLOYE E, INDEX: EMP_IDX1, ACES: 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 ( ACES: 1, SELF_ID: 1 ) 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)가 존재하 여야 한다. 인덱스 스캔을 하므로 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-120145 D111100004 1000 19 0129010 70101-10101 E101 50 19 0123101 750625-12143 E1012 10000 19 0012100277 761012-120475 D111100008 2500 Explain Plan 573 19 0012300010 781225-1304 D111100010 2000 19 0012310008 730828-120145 D111100003 10 19 0012300005 720305-21014 D111100008 4000 19 0123104 761012-120475 E1010 5000 19 01231012 730828-120145 C101 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, ACES: 19, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: ORDERS O, FULL SCAN, ACCESS: 30, SELF_ID: 3 ) PROJECT 정의 Projection 기능을 수행하며, 지정한 column들을 추출해 낸다. 형식 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 1650 HSCHOI 20 … KMKIM 1980 DIKIM 20 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 4 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, DISK_PAGE_COUNT: 2, SELF_ID: 2 ) ----------------------------------- 574 ALTIBASE5 Administrator’s Manual SCAN 정의 Selection 기능을 수행하며, 특정 테이블을 Key Range, Filter등을 사용해 조건에 맞는 레코드를 검색한다. 형식 1) 메모리에 materialization이 될 경우 SCAN ( TABLE: table_name, FULL SCAN, ACCESS: acc_num, SELF_ID: node_id ) SCAN ( TABLE: table_name, INDEX: index_name, ACCESS: acc_num, SELF_ID: node_id ) 2) 디스크에 materialization이 될 경우 SCAN ( TABLE: table_name, FULL SCAN, ACCESS: acc_num, DISK_PAGE_COUNT: page_count, SELF_ID: node_id ) SCAN ( TABLE: table_name, INDEX: index_name, ACCESS: acc_num, DISK_PAGE_COUNT: page_count, SELF_ID: node_id ) table_name table 이름 FULL SCAN index 사용 안함 index_name 사용하는 index acc_num record 접근 횟수 page_count page의 개수 node_id tuple set 내에서의 ID (node의 ID로 간주) 예제 예제1) 생일이 상반기(6월 30일) 이전인 사원들의 이름, 부서 번호, 생일을 출력하라 iSQL> SELECT ename, dno, birth FROM employee WHERE birth CREATE INDEX emp_idx2 ON employee(birth); Create success. iSQL> SELECT ename, dno, birth FROM employee WHERE birth SELECT gno FROM goods MINUS SELECT gno FROM orders; GNO --------- A111100001 B11100001 C11100002 D111100001 D111100005 D111100006 D111100007 E111100006 D111100009 E111100003 E111100004 E111100005 E111100008 E11110001 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 정의 Explain Plan 577 Set Intersection 기능을 수행하며, binary node, materialized node 이다. SQL 문의 INTERSECT 에 해당한다. 형식 1) 메모리에 materialization 이 될 경우 SET-INTERSECT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, L_REF_ID: l_ref_id, R_REF_ID: r_ref_id ) 2) 디스크에 materialization 이 될 경우 SET-INTERSECT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, L_REF_ID: l_ref_id, R_REF_ID: r_ref_id ) item_size 저장하는 item의 크기 item_count 저장한 item의 개수 bucket_count hash bucket의 개수 page_count page의 개수 acc_num 접근 횟수 self_id node ID l_ref_id Left 참조 node ID. 만약 independent 하면 left-child의 data를 다시 저장할 필요가 없 음. r_ref_id Right 참조 node ID. 만약 independent 하면 right-child의 data를 다시 저장할 필요가 없 음. 예제 사원과 고객의 생일이 상반기(6 월 30 일 이전)인 사람들중 같은 이름을 가진 사람의 이름을 출력하라. iSQL> SELECT ename FROM employee WHERE birth SELECT ename, emp_job, join_date, salary FROM employee WHERE salary < 1000000 ORDER BY 4 DESC; Explain Plan 579 ENAME EMP_JOB JOIN_DATE SALARY ----------------------------------- KWKIM CEO 980000 HJMIN MANAGER 20/01/24 0:0:0 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: EMPLOYE, FUL SCAN, ACES: 20, DISK_ P A G E_ C O UNT: 2, S E L F_ ID: 2 ) ----------------------------------- VIEW 정의 In-line View 들을 처리하기 위한 node 이다. Projection 에 해당하는 column 들을 하나의 연속된 가상의 레코드로 인식하도록 한다. 형식 VIEW ( ACCESS: acc_num, SELF_ID: self_id ) acc_num 접근 횟수 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 40 A01 206.67 MSKIM 2750000 C001 1576.67 JHCHOI 230 C02 160 CHLE 190 C02 160 SJKIM 250 D01 2075750 MYLE 1890 F018450 6 rows selected. ----------------------------------- PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 56 ) JOIN VIEW ( ACCESS: 6, SELF_ID: 3 ) 580 ALTIBASE5 Administrator’s Manual PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 24 ) AGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 6 ) GROUPING SCAN ( TABLE: EMPLOYEE, INDEX: EMP_IDX1, ACCESS: 20, SELF_ID: 2 ) SCAN ( TABLE: EMPLOYE E, INDEX: EMP_IDX1, ACES: 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 참고 PARTITION-COORDINATOR 정의 파티션드 테이블의 각각의 파티션에 대한 스캔을 관리하는 노드이다. 여러 개의 자식 노드를 가지며, 파티션 필터링을 수행한다. 형식 PARTITION-COORDINATOR ( TABLE: table_name, PARTITION: partition_acc_cnt, ACCESS: acc_num,SELF_ID: self_id ) table_name table 이름 partition_acc_cnt 접근하는 파티션의 개수 acc_num 실제 접근한 레코드의 개수 self_id node ID Explain Plan 581 예제 iSQL> CREATE TABLE t1 ( i1 INTEGER ) PARTITION BY RANGE ( i1 ) ( PARTITION p1 VALUES LESS THAN ( 100 ), PARTITION p2 VALUES LESS THAN ( 200 ), PARTITION p3 VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; Create success. iSQL> INSERT INTO t1 VALUES ( 50 ); 1 row inserted. iSQL> INSERT INTO t1 VALUES ( 60 ); 1 row inserted. iSQL> INSERT INTO t1 VALUES ( 150 ); 1 row inserted. iSQL> INSERT INTO t1 VALUES ( 160 ); 1 row inserted. iSQL> alter sesion set explain plan = on; Alter success. iSQL> SELECT COUNT(*) FROM t1 WHERE i1 < 100; COUNT ----------------- 2 1 row selected. -------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 2 ) PARTITION-COORDINATOR ( TABLE: T1, PARTITION: 1/3, ACESS: 2, SELF_ID: 2 ) SCAN ( PARTITION: P1, FUL SCAN, ACES: 2, DISK_PAGE_COUNT: 2, SELF_ID: 3 ) -------------------------------------------- SQL Plan Cache 583 12. SQL Plan Cache 이 장은 알티베이스 SQL Plan Cache 기능에 대한 개념 및 특징에 대해 설명한다. 584 ALTIBASE5 Administrator’s Manual SQL Plan Cache 개요 알티베이스 SQL Plan Cache 기능은 SQL 문 수행시 필요한 수행 계획 정보를 공유할 수 있다. 공유한 수행 계획(SQL PLAN)을 실행할 때에는 Execution Context 를 다시 사용할 수 있게 한다. SQL Plan Cache 의 구조 [그림 12-1] 알티베이스 공유 캐쉬 구성도 알티베이스는 모든 세션이 공유하는 캐쉬(cache) 영역을 가지고 있다. 캐쉬 영역은 Shared SQL Plan Cache, Stored Procedure Cache, Meta Cache 로 구성된다. Shared SQL Plan Cache 는 새로운 SQL 수행 계획이 생성될 때마다 이 영역에 등록하여 모든 세션이 공유한다. Stored Procedure Cache 는 저장 프로시저의 수행 계획이 새로 생성될 때 이 영역에 저장되어 공유된다. Meta Cache 는 데이터베이스 객체에 대한 모든 정보를 수록하고 있는 메타 데이터를 빠르게 접근하기 위해서 캐쉬에 두고 사용된다. SQL Plan Cache 의 장점 알티베이스 SQL Plan Cache 를 사용함으로써 다음과 같은 몇 가지 장점을 얻을수 있다. SQL Plan Cache 585 y Direct Execution 위주의 퀴리가 자주 발생하는 운영 환경에서 성능 향상 y Prepare Execute만 사용하는 환경에서는 Prepare Memory의 대폭적인 절감 Direct Execution 위주의 퀴리가 자주 발생하는 환경에서는 이미 prepare 가 된 플랜을 공유하여 재사용이 가능하기 때문에 prepare 비용을 줄일수 있어 성능을 향상시킬수 있다. 또한 Prepare Execute 만 쓰는 환경에서는 prepare 비용 절감뿐 아니라 prepare 에 필요한 메모리까지 줄일 수 있는 효과를 얻는다. SQL Plan Cache 사용 구문 SQL Plan Cache 기능이 적용되는 SQL 구문은 다음과 같다. 각 구문에 대한 상세한 설명은 SQL User’s Manual 을 참조한다. y SELECT (SELECT FOR UPDATE) y INSERT (INSERT SELECT) y UPDATE y DELETE y MOVE y ENQUEUE y DEQUEUE 586 ALTIBASE5 Administrator’s Manual SQL Plan Cache 의 특징 알티베이스 SQL Plan Cache 의 특징을 살펴보면 다음과 같다. y 플랜 공유에 중점을 둔 체크-인(check-in) 방식이다. y SQL Plan Cache의 교체 정책은 최근 사용도뿐만 아니라 참조횟수(frequency)까지 고려한다. y 파싱 비용의 제거로 SQL 문장이 반드시 같아야 plan cache를 사용할 수 있다. 플랜 공유에 중점을 둔 체크-인 방식이란, 알티베이스의 SQL Plan Cache 가 플랜 공유에 중점은 둔 등록 방식을 사용한다는 의미이다. 즉, 새로운 공유 Plan 이 SQL Plan Cache 에 등록될 때 SQL_PLAN_CACHE_SIZE 에서 정의한 크기를 넘지 않는 범위 내에서 plan 을 등록하여 사용할 수 있다. 만약 새로운 plan 을 등록할 때 SQL_PLAN_CACHE_SIZE 에서 정의한 크기를 넘을 경우, 사용하지 않는 오래된 plan 이 있는지를 확인하여 삭제한 후 새로운 plan 을 등록한다. 그러나 SQL_PLAN_CACHE_SIZE 에 정의한 크기를 SQL PLAN 들이 초과하면서, 다른 구문들에 의해 모두 참조되고 있다면 새로운 SQL PLAN 을 등록할 수 없다. SQL Plan Cache 에 Plan 을 등록하지 못하는 경우, V$SQL_PLAN_CACHE 의 CACHE_IN_FAIL_COUNT 가 증가한다. SQL_PLAN_CACHE_SIZE 는 디폴트가 64MB 이고 사용자가 임의로 지정할 수 있다. 또한 SQL Plan Cache 의 교체 정책은 최근 사용도뿐 아니라 참조 횟수까지 고려하기 때문에, Cache 가 부족할 경우에도 자주 참조되는 Plan Cache 객체를 보호할 수 있다. 그러나 SQL Plan Cache 의 파싱 비용의 제거로 SQL 문장이 형식뿐 아니라 인자 값도 반드시 같아야 공유된 plan cache 를 사용할 수 있다. 예를 들어 다음과 두 문장은 SQL Plan Cache 에서는 다른 것으로 간주된다. INSERT INTO T1 VALUES(1,2); INSERT INTO T1 VALUES(2,3); 이런 경우에 다음과 같이 질의를 작성하여 Plan Cache 를 사용할 수 있도록 하여 성능을 향상시킬수 있어야 한다. INSERT INTO T1 VALUES(? , ?) SQL Plan Cache 587 SQL Plan Cache 관련 프로퍼티 SQL Plan Cache 를 사용하기 위해서는 알티베이스 프로퍼티 파일을 사용 목적에 맞게 수정해야 한다. SQL Plan Cache 과 관련된 프로터티는 다음과 같다. 각 프로퍼티에 대한 상세한 설명은 Starting User’s Manual 을 참조한다. y SQL_PLAN_CACHE_BUCKET_CNT y SQL_PLAN_CACHE_HOT_REGION_LRU_RATIO y SQL_PLAN_CACHE_PREPARED_EXECUTION_CONTEXT_ CNT y SQL_PLAN_CACHE_SIZE 588 ALTIBASE5 Administrator’s Manual PartⅢ 589 Part III 알티베이스 튜닝 591 13. 알티베이스의 보안 이 장에서는 알티베이스의 보안을 위해 사용 가능한 방법들과 보안 모듈 사용 방법에 대해 설명한다. 592 ALTIBASE5 Administrator’s Manual 보안의 개요 정보 보호의 중요성이 높아지고 개인 정보 등 민감하고 중요한 정보를 법령으로 제정하여 보호함에 따라 데이터베이스의 보안 관리 기능이 필수적으로 요구되고 있다. 데이타베이스의 보안은 의도하지 않은 내, 외부적 활동으로부터 데이타베이스를 보호하는 것을 목적으로 하며, 알티베이스에서는 사용자의 필요에 적합한 보안 모듈을 연동하여 데이터베이스를 효과적으로 보호할 수 있도록 보안 모듈 연동 기능을 제공한다. 이 장에서는 데이터 암호화를 위한 보안 모듈 연동 기능에 대해 설명한다. 알티베이스의 보안 모듈 연동 기능은 기존 시스템과의 독립적인 보안 모듈 구성과 응용 프로그램과의 완벽한 독립성을 바탕으로, 개인 정보 보호를 위한 강력한 암호화 관리를 지원한다. 신뢰할 수 있는 외부의 보안 모듈을 알티베이스의 기존 시스템과 연동하여 취약한 데이타베이스의 보안을 강화하며, 보안 모듈을 효과적으로 연동할 수 있는 API 를 지원한다. 보안 모듈을 통한 데이터 암호화, 접근 제어 및 감사 기능을 위한 기반 구조를 데이타베이스 레벨에서 지원한다. 보안과 관련된 모든 사항은 보안 모듈을 통해서 이루어진다. 암호화는 테이블의 칼럼을 대상으로 수행하며, 암호화가 적용된 칼럼의 데이터는 디스크뿐만 아니라 메모리 상에서도 암호화를 유지한다. 접근 제어 기능은 보안 대상의 선정 과정과 보안 대상에 대한 접근 권한의 분류를 통해 객체에 대한 사용자의 접근 유효성을 판단하는 과정으로 나뉘어진다. 접근 제어의 대상은 테이블 내의 칼럼 단위로 설정되며, 보안이 설정된 칼럼에 대해 접근을 하기 위해서는 각 사용자마다 해당 객체에 대한 필요 접근 권한을 부여 받아야 한다. 보안 대상의 설정과 보안 대상의 접근, 암호화 작업에 대해서는 감사 기록이 남겨진다. 알티베이스가 제공하는 보안 관련 기능은 다음과 같다. y 디스크 및 메모리에 데이타를 암호화하여 저장 관리 y 보안 권한에 따른 출력 데이타의 복호화 y 원본의 순서를 보장하는 인덱스 구성 y 암호 칼럼을 가지는 테이블의 이중화 알티베이스 튜닝 593 보안 기능의 구성 알티베이스와 보안 모듈은 독립적으로 구성되어 있으며, 보안 모듈에서 보안 정보와 보안 권한에 대한 사항을 별도로 관리한다. 보안 모듈이 연동되어 있지 않더라도, 알티베이스는 정상적으로 동작한다. 단, 암호 칼럼에 대한 질의 처리시 보안 모듈이 연동되어 있지 않으면, 해당 질의는 실패하게 된다. 알티베이스는 보안 모듈 관련 속성들과 SQL 문을 통해 보안 모듈을 연동을 지원한다. 보안 모듈이 연동되는 과정에서 두 모듈 간의 연결의 유효성을 평가하여 해당 연결에 대한 신뢰성을 보장한다. 알티베이스의 보안 정보(모듈 이름, 버전, 암호 칼럼들의 정보)와 보안 모듈의 정보를 비교하여 보안 모듈의 연결을 평가한다. 알티베이스와 연동하는 기존의 응용프로그램에 대한 수정 없이 데이터를 칼럼 단위로 암호화하여 관리한다. 암호 칼럼의 생성 및 삭제는 SQL 로 지원하며, 이를 제외한 기존의 응용프로그램에서 사용하는 질의의 변경은 없다. 알티베이스 메인 모듈의 역할은 다음과 같다. y 운영 중 보안 모듈 연동을 위한 환경변수 및 구문 지원 y 암호화된 데이타를 관리하기 위한 자료구조 및 메타 정보 지원 y 보안 관련 질의 구문 확장 y 이중화 지원 외부 보안 모듈의 역할은 다음과 같다. y 암호화 알고리즘 설정(암호화 알고리즘의 종류, 초기화 벡터 사용 여부 결정) y 칼럼의 암호화 정보 설정(암호화 알고리즘 선택, 암호화 및 복호화 권한 설정) y 데이타의 암호화 및 복호화 y 접근 제어 설정(IP 접근 제어, 사용자 접근 제어) y 감사(암호화 및 복호화 로그, 접근 제어 로그) 594 ALTIBASE5 Administrator’s Manual 보안 모듈 연동 방법 보안 모듈을 연동하기 위해 필요한 절차들을 설명한다. 하나의 서버에는 하나의 보안 모듈만 연동되며 보안 모듈을 연동하기 위해서는 보안 모듈의 이름, 보안 모듈의 경로, 순서를 보장하는 ECC 알고리즘의 보안 정책을 설정하고, 보안 모듈의 연동을 시작한다. 보안 모듈이 이미 연동되어 있는 상태에서 새로운 보안 모듈을 적용하고자 할 경우, 이전 보안 모듈의 연동을 종료하고 새로운 보안 모듈의 연동을 시작한다. 여기서 ECC 란 Encrypted Comparison Code 의 약자로 원본의 순서가 보장되는 해시값이다. ECC 로부터 원본으로의 변환이 불가능한 단방향 해시 알고리즘을 적용하여 ECC 를 구성한다. ECC 는 DBMS 내부에서 암호 컬럼에 대한 빠른 비교연산을 위해 이용되며, 관리자 또는 사용자에 노출되지 않는다. ECC 알고리즘은 ECC 를 생성하기 위해 적용된 해시 알고리즘을 의미한다. 외부 보안 모듈로부터 다양한 ECC 알고리즘의 지원이 가능하며, 서버 단위로 하나의 ECC 알고리즘을 선택하여 적용한다. 다음의 과정을 거쳐 연동한다. y 외부 보안 모듈 설치 y 알티베이스 환경 설정 y 보안 모듈 연동 시작, 종료 y 암호 칼럼 생성/해제 이 과정 중 외부 보안 모듈 설치 방법은 보안 모듈의 종류에 따라 다르므로 사용할 외부 보안 모듈의 설치 문서를 참고한다. 여기에서는 환경 설정, 연동 시작, 종료 방법 및 암호 칼럼 생성 방법에 대해 설명한다. 환경 설정 연동하기 위한 외부 보안 모듈의 경로를 알티베이스 속성 파일, $ALTIBASE_HOME/conf/altibase.properties 에 다음과 같이 정의한다. SECURITY_MODULE_NAME = altibase SECURITY_MODULE_LIBRARY = libsecurity.so SECURITY_EC_POLICY_NAME = ecc_policy1 프로퍼티의 값은 대, 소문자를 구별하므로 이에 주의해야 한다. 알티베이스 튜닝 595 SECURITY_MODULE_NAME 은 외부 보안 모듈의 이름으로 사용하는 보안 보듈에 따라 달리 설정한다. SECURITY_MODULE_LIBRARY 는 설치된 외부 보안 모듈 라이브러리의 이름을 나타낸다. SECURITY_ECC_POLICY_NAME 은 알티베이스 내부에서 보안 보듈을 구분하기 위한 이름으로 반드시 정의해야 한다. 이 속성들을 ALTER SYSTEM 구문으로 운영 도중에 설정하거나 변경할 수 있다. ALTER SYSTEM 구문으로 변경할 경우, SECURITY_MODULE_LIBRARY 에는 파일의 절대 경로를 표시해야 한다. ALTER SYSTEM SET SECURITY_MODULE_NAME = 'altibase'; ALTER SYSTEM SET SECURITY_MODULE_LIBRARY = '/altibase_home/lib/libsecurity.so'; ALTER SYSTEM SET SECURITY_EC_POLICY_NAME = 'ec_policy1'; 596 ALTIBASE5 Administrator’s Manual 보안 모듈 연동 구문 보안 모듈 연동을 위한 구문 및 암호화 방법에 대해 설명한다. 보안 모듈 연동 시작 보안 모듈 연동 프로퍼티가 모두 설정되었다면 보안 모듈 연동을 시 작한다. 보안 모듈 연동을 시작하면 내부적으로 다음 기능들이 수행 된다. 1. 보안 모듈 인증 상호 허용되지 않은 보안 모듈을 사용할 수 없도록 인증한다. 2. 보안 모듈 초기화와 유효성 검사 보안 모듈 자체의 설정 파일이나 라이센스를 검사한다. 3. ECC 보안 정책 검증 보안 모듈에 프로퍼티로 설정된 ECC 보안 정책이 유효한지 검사 한다. ALTER SYSTEM START SECURITY 문으로 보안 모듈 연동을 시 작한다. 시스템 관리자 권한으로 접속하여 실행하되 알티베이스 구동 상태가 PROCESS 상태에서 실행해야 한다. 예제 1. 시스템 관리자 권한으로 알티베이스에 접속한다. ISQL> CONNECT sys/manager 2. 알티베이스 구동 상태를 PROCESS 상태로 변경한다. ISQL> STARTUP PROCESS 3. 프로퍼티를 설정한다. ISQL> ALTER SYSTEM SET SECURITY_MODULE_NAME = 'altibase'; ISQL> ALTER SYSTEM SET SECURITY_MODULE_LIBRARY = '/altibase_home/lib/libsecurity.so'; ISQL> ALTER SYSTEM SET SECURITY_ECC_POLICY_NAME = 'ecc_policy1'; 4. 보안 모듈을 연동한다. ISQL> ALTER SYSTEM START SECURITY; 5. 보안 모듈 연동 상태를 확인한다. ISQL> SELECT * FROM SYSTEM_.SYS_SECURITY_; MODULE_NAME MODULE_VERSION ECC_POLICY_NAME ECC_POLICY_CODE -------------------------------------------- 알티베이스 튜닝 597 altibase 1.0 ec_policy1 abcde12345 6. 알티베이스 구동 상태를 SERVICE 상태로 변경하여 서비스를 진행한다. ISQL> STARTUP SERIVCE 보안 모듈 연동 종료 보안 모듈의 연동을 종료하고자 할 때는 시작과 마찬가지로 시스템 관리자 모드로 접속하여 구동 상태를 PROCESS 로 변경한 뒤 다음과 같이 수행한다. ISQL> ALTER SYSTEM STOP SECURITY; 다음과 같이 보안 모듈 연동 상태를 확인할 수 있다. ISQL> SELECT * FROM SYSTEM_.SYS_SECURITY_; MODULE_NAME MODULE_VERSION ECC_POLICY_NAME ECC_POLICY_CODE -------------------------------------------- No rows selected. 주의사항 보안 모듈의 연동 종료는 암호화 컬럼이 존재하지 않는 경우에만 수행할 수 있다. 암호 칼럼의 생성 데이터를 보호해야 하는 중요한 칼럼의 경우, 암호 칼럼으로 지정하여 보호할 수 있다. CHAR, VARCHAR 두 가지 자료형에 대해 암호화를 지원한다. 암호 칼럼은 CREATE TABLE 문으로 칼럼 생성시 암호 칼럼으로 지정하거나, ALTER TABLE 문으로 이미 생성된 테이블의 칼럼을 암호 칼럼으로 지정할 수 있다. 두 가지 모두 칼럼 정의시, ENCRYPT USING 구문으로 사용할 보안 정책 이름(SECURITY_ECC_POLICY_NAME)을 지정한다. 칼럼의 암호화 지정 여부는 DESC 구문을 통해 확인할 수 있다. 구문 CREATE TABLE table_name (column_name datatype [ENCRYPT USING ‘policy_name’]); 주의사항 598 ALTIBASE5 Administrator’s Manual 1. 암호 칼럼으로 설정된 대상을 다시 암호화할 수 없다. 2. 암호 칼럼으로 설정된 상태로 칼럼의 데이타 타입을 변경할 수 없다. 예제 질의 1> 테이블 생성시에 empID1, ssn1 을 암호 칼럼으로 생성한다. CREATE TABLE t1 (name1 varchar(5), empID1 varchar(10) ENCRYPT USING ‘policy_id’, sn1 char(12) ENCRYPT USING ‘policy_ssn’); 질의 2> 기존의 t1 테이블의 empID1 칼럼을 보안 정책 policy_ssn 을 사용하여 암호 칼럼으로 변경한다. ALTER TABLE t1 MODIFY (empID1 ENCRYPT USING ‘policy_ssn’); 질의 3> 테이블 구조에서 암호 칼럼을 확인한다. ISQL> DESC t1 -------------------------------------------- NAME TYPE IS NUL -------------------------------------------- NAME1 VARCHAR(10) FIXED EMPID1 VARCHAR(8) ENCRYPT FIXED SN CHAR(12) ENCRYPT FIXED 암호 칼럼으로 변경 일반 칼럼의 경우, ALTER TABLE 문을 사용하여 암호 칼럼으로 변경할 수 있다. 구문 ALTER TABLE table_name MODIFY (column_name [ENCRYPT USING ‘policy_name’]); 주의사항 1. 암호 칼럼으로 설정된 대상을 다시 암호화할 수 없다. 2. 암호 칼럼으로 설정된 상태로 칼럼의 데이타 타입을 변경할 수 없다. 예제 질의> t1 테이블의 empID1 칼럼을 암호 칼럼으로 지정한다. ALTER TABLE t1 MODIFY (empID1 ENCRYPT USING ‘policy_ssn’); 알티베이스 튜닝 599 암호 칼럼의 해제 암호 칼럼으로 지정되었을 때 ALTER TABLE 구문으로 암호화 설정을 해제할 수 있다. 구문 ALTER TABLE table_name MODIFY (column_name [DECRYPT]); 예제 질의> t1 테이블의 empID1 칼럼의 암호화 설정을 해제한다. ALTER TABLE t1 MODIFY (empID1 DECRYPT); 알티베이스 튜닝 601 14. 알티베이스 튜닝 이 장에서는 서버의 성능 향상을 위해서 알티베이스가 제공하는 다음 두 가지 기능에 대해서 설명한다. y 로그 파일 그룹(Log File Group) y 그룹 커밋(Group Commit) 602 ALTIBASE5 Administrator’s Manual 로그 파일 그룹 알티베이스에서 제공하는 로그 파일 그룹 기능에 대해서 기술한다. 로그 파일 그룹의 개념 로그파일그룹은 여러 트랜잭션들의 로그가 여러 개의 로그파일에 동시에 기록될 수 있도록 하여 시스템의 성능을 최적의 상태로 만들어준다. 알티베이스는 기본적으로 로그파일들을 LOG_DIR 프로퍼티에 설정된 하나의 디렉터리에 관리한다. 그리고 그 속의 로그파일들 중 오직 하나의 로그파일에 시스템 운영 중에 발생하는 로그를 기록한다. 트랜잭션의 영속성(Durability)보장을 위해서 로깅은 필수적이며, 일반적으로 여러 개의 트랜잭션이 동시에 수행되는 환경에서는 이와 같이 시스템 상에 하나 뿐인 로그파일에 로그를 기록하는 과정에서 병목현상이 발생한다. 이러한 병목 현상을 해결하기 위하여 알티베이스는 로그 파일이 기록되는 경로를 여러 개 지정할 수 있도록 로그파일그룹을 제공한다. 하나의 로그 경로 안에서 오직 하나의 로그파일에만 로그가 기록된다는 기존의 제약사항은 그대로 적용되지만, 이러한 로그 경로가 여러 개가 됨에 따라 동시에 로그를 기록할 수 있는 로그파일의 수도 여러개로 늘어난다. 이와 같이 하나의 로그 경로, 즉 여러 개의 로그파일을 지니는 로깅 시스템의 최소 단위를 로그파일그룹(Log File Group, LFG)라고 칭한다. 앞으로는 설명의 편의를 위하여 로그파일그룹을 간략하게 LFG 라고 통칭한다. 시스템상에 DB 에 변경을 가하는 트랜잭션이 많을수록, 커밋이 빈번하게 수행될수록 LFG 를 여러 개로 구성함에 따른 성능향상이 더욱 두드러진다. 로그 파일그룹의 구성요소 하나의 LFG 는 다음과 같은 물리적 구성 요소를 지닌다. y 로그 경로 (LOG_DIR 프로퍼티) 하나의 로그 경로에는 하나 혹은 그 이상의 로그 파일들이 존재하며, 그 중 오직 하나의 로그파일에만 로그를 기록할 수 있다. y 아카이브 로그 경로 (ARCHIVE_DIR 프로퍼티) 알티베이스 튜닝 603 아카이브로깅을 할 경우, 로그 경로안의 기록이 완료된 로그파일들을 아카이브 로그 경로로 복사하게 된다. 이러한 아카이브 로그파일은 데이터베이스 복구와 백업을 위해 사용된다. 이 프로퍼티의 수는 LOG_DIR프로퍼티의 수와 정확히 일치해야 한다. 아울러, LOG_DIR 프로퍼티가 여러 개인 경우 ARCHIVE_DIR프로퍼티들은 LOG_DIR 프로퍼티 값과 순서대로 1:1로 매핑될 수 있도록 기술한다. 하나의 LFG 에는 다음과 같은 세가지 종류의 쓰레드가 존재한다. y 로그파일 생성 쓰레드 (Log File Creation Thread) 알티베이스는 하나의 LFG에서 로그가 기록되는 로그파일을 끝까지 사용하였을 때, 새로운 로그파일에 로그를 기록하기 시작한다. 이 때, 새로운 로그파일이 필요한 시점에서 로그파일을 생성한다면, 로그를 기록하려는 트랜잭션들이 로그파일이 생성되는 동안 아무 작업도 수행하지 못한 채로 기다려야 한다는 문제점이 발생한다. 이 쓰레드는 로그 기록을 위한 새 로그파일이 필요하기 전에 미리 로그파일을 만들어 둔다. 참고로, 로그파일이 삭제되는 시점은 체크포인트가 끝난 후이며, 체크포인트 중에는 더 이상 사용되지 않는 로그파일들을 별도로 분류하여 삭제한다. y 로그 플러시 쓰레드 (Log Flush Thread) 해당 LFG에 기록된 로그를 주기적으로 디스크로 기록하는 쓰레드이다. 이 쓰레드가 로그를 미리 디스크에 기록해 두기 때문에, 커밋하려는 트랜잭션은 이 쓰레드가 이미 디스크에 기록한 로그를 다시 기록할 필요가 없으며, 디스크에 기록되지 않은 로그만 별도로 디스크에 기록하게 된다. 즉, 주기적으로 로그를 디스크로 기록하여 커밋하려는 트랜잭션이 디스크로 기록해야 할 로그의 양을 줄여주는 쓰레드이다. y 아카이브 로그 쓰레드 (Archive Log Thread) 해당 LFG에서 로그가 기록되고 있는 로그파일을 끝까지 사용하면 다른 새로운 로그파일에 로그를 기록하기 시작한다. 이때, 아카이브 쓰레드는 방금 전까지 로그가 기록되고 있던, 하지만 끝까지 다 기록되어 더이상 로그가 기록되지 않는 로그파일을 아카이브 로그파일로 복사한다. 사용 예 알티베이스는 같이 기본적으로 LOG_FILE_GROUP_COUNT 프로퍼티가 1 로 설정되어 LFG 를 한 개만 사용하도록 구성되어 604 ALTIBASE5 Administrator’s Manual 있다. 그리고 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 -rw------ 1 kmkim kmkim 10485760 Jun 22 15:46 logfile1 -rw------ 1 kmkim kmkim 10485760 Jun 22 15:46 logfile2 다음은 LFG 를 세 개로 구성한 경우의 알티베이스 프로퍼티 파일의 일부이다. LFG 의 수를 LOG_FILE_GROUP_COUNT 프로퍼티에 3 으로 기술하였으며, LOG_DIR 과 ARCHIVE_DIR 을 각각 세 개씩 기술하여 세 개의 LFG 에 해당하는 로그경로와 아카이브 로그 경로를 기술하고 있다. LOG_FILE_GROUP_COUNT = 3 # LFG의 수(3) LOG_DIR = ?/logs1 # 로그 경로 ( LFG#0 ) LOG_DIR = ?/logs2 # 로그 경로 ( LFG#1 ) LOG_DIR = ?/logs3 # 로그 경로 ( LFG#2 ) ARCHIVE_DIR = ?/arch_logs1 # 아카이브 로그 경로 ( LFG#0 ) ARCHIVE_DIR = ?/arch_logs2 # 아카이브 로그 경로 ( LFG#1 ) ARCHIVE_DIR = ?/arch_logs3 # 아카이브 로그 경로 ( LFG#2 ) 위에 기술한 로그 디렉터리들은 LFG 가 한 개일 때와 마찬가지로 알티베이스 홈 경로인 $ALTIBASE_HOME 에 logs1, logs2, logs3 를 사용자가 명시적으로 생성해 주어야 한다. LFG#0 는 $ALTIBASE_HOME/logs1 에 로그파일을 기록하며, 이 안의 로그파일 중 오직 하나에만 로그를 기록할 수 있다. 마찬가지 규칙이 LFG#1, LFG#2 에도 적용된다. 이와 같이 LFG 를 여러 개로 운영할 경우, 트랜잰셕의 영속성(Durability)를 보장하기 위해서 트랜잭션 커밋시 항상 로그가 디스크에 반영(Sync)될 때까지 기다린다. 즉 항상 COMMIT_WRITE_WAIT_MODE 가 1 상태로 서버가 운영된다. 알티베이스 튜닝 605 고려사항 LOG_FILE_GROUP_COUNT 를 1 보다 큰 값으로 2 개 이상의 LFG 를 쓰게 되면 서버는 COMMIT_WRITE_WAIT_MODE 프로퍼티 값을 무시하고 무조건 1 로 운영한다. 결과적으로 항상 트랜잭션의 커밋(Commit) 로그가 디스크에 내려갈 때까지 기다린다. 최적화 LFG 를 두 개 이상으로 사용하도록 설정한 경우, 다음과 같이 각 LFG 의 로그 경로를 물리적으로 서로 다른 위치에 두면 하나의 디스크에 여러 LFG 의 로그 기록 요청이 몰리는 것을 방지할 수 있다. 이와 같이 LFG 를 물리적으로 서로 다른 디스크에 둘 경우 각각의 디스크가 동시에 I/O 작업을 처리할 수 있어서 시스템의 성능이 한결 향상된다. LOG_FILE_GROUP_COUNT = 3 # LFG의 수(3) LOG_DIR = /disk1/logs # 로그 경로 ( LFG#0 ) LOG_DIR = /disk2/logs # 로그 경로 ( LFG#1 ) LOG_DIR = /disk3/logs # 로그 경로 ( LFG#2 ) ARCHIVE_DIR = /disk1/arch # 아카이브 로그 경로 ( LFG#0 ) ARCHIVE_DIR = /disk2/arch # 아카이브 로그 경로 ( LFG#1 ) ARCHIVE_DIR = /disk3/arch # 아카이브 로그 경로 ( LFG#2 ) 그리고 다음과 같이 하나의 디스크에 두 개 이상의 LFG 를 두도록 구성하면 디스크의 I/O 처리량(bandwidth)을 더 폭넓게 사용하게 되어 더 좋은 성능을 낼 수도 있다. 이와 같이 일반적으로 하나의 디스크에 두 개 이상의 LFG 를 두는 것이 더 좋은 성능을 내지만, 하나의 디스크에 하나의 LFG 를 둘 지, 아니면 둘 이상의 LFG 를 둘 지는 시스템의 성능과 디스크의 I/O 처리량, 시스템의 부하와 밀접한 연관이 있으므로, 실 상황에서 다양한 LFG 구성으로 직접 성능을 측정해 보는 것이 가장 좋다. LOG_FILE_GROUP_COUNT = 6 # LFG의 수(6) LOG_DIR = /disk1/logs1 # 로그 경로 ( LFG#0 ) LOG_DIR = /disk1/logs2 # 로그 경로 ( LFG#1 ) LOG_DIR = /disk2/logs1 # 로그 경로 ( LFG#2 ) LOG_DIR = /disk2/logs2 # 로그 경로 ( LFG#3 ) LOG_DIR = /disk3/logs1 # 로그 경로 ( LFG#4 ) LOG_DIR = /disk3/logs2 # 로그 경로 ( LFG#5 ) ARCHIVE_DIR = /disk1/arch1 # 아카이브 로그 경로 ( LFG#0 ) ARCHIVE_DIR = /disk1/arch2 # 아카이브 로그 경로 ( LFG#1 ) ARCHIVE_DIR = /disk2/arch1 # 아카이브 로그 경로 ( LFG#2 ) 606 ALTIBASE5 Administrator’s Manual ARCHIVE_DIR = /disk2/arch2 # 아카이브 로그 경로 ( LFG#3 ) ARCHIVE_DIR = /disk3/arch1 # 아카이브 로그 경로 ( LFG#4 ) ARCHIVE_DIR = /disk3/arch2 # 아카이브 로그 경로 ( LFG#5 ) 로그파일그룹 할당 시스템에 LFG 가 한 개뿐일 때에는 모든 트랜잭션이 해당 LFG 에 로그를 기록한다. 하지만 LFG 가 두 개 이상으로 구성된 경우에는 트랜잭션들을 여러 개의 LFG 에 골고루 분산시켜 주어야 한다. 이와 같이, 하나의 트랜잭션에 로그를 기록할 LFG 를 제공하는 것을 트랜잭션에 LFG 를 할당한다’라고 한다. 예를 들어 LFG 가 LFG#0, LFG#1, LFG#2, LFG#3 로 네 개로 구성된 경우 트랜잭션에 LFG 를 어떻게 할당하는지 알아보자. y 디스크 테이블을 변경한 적이 있는 디스크 트랜잭션의 경우, 첫 번째 LFG인 LFG#0에 할당된다. y 메모리 테이블만 변경한 메모리 트랜잭션의 경우 LFG#1, LFG#2, LFG#3에 번갈아가면서 하나씩 할당된다. y 메모리 트랜잭션이 디스크 테이블을 변경하여 디스크 트랜잭션이 되는 경우, 해당 트랜잭션은 사용중이던 LFG를 반납하고 LFG#0을 할당받는다. y 이외에 이미 삭제된 행들을 찾아서 공간을 반납하는 가비지 컬렉션 트랜잭션과 체크포인트 트랜잭션은 LFG#0을 사용한다. 한계와 제약사항 LFG 기능의 한계점 디스크 테이블을 한 번이라도 변경한 적이 있는 디스크 트랜잭션의 경우, 첫 번째 LFG 에만 할당되기 때문에, LFG 의 개수와 디스크 트랜잭션의 성능과는 아무런 상관이 없다. 단, LFG 를 두 개로 구성 하였을 때, 메모리 트랜잭션과 디스크 트랜잭션의 로그가 두 개의 LFG 로 분산되어 LFG 가 한 개일때에 비해 디스크 트랜잭션의 성능이 올라갈 수 있다. LFG 기능의 제약사항 y COMMIT_WRITE_WAIT_MODE를 항상 1로 운영한다. 사용자가 0으로 설정하여도 서버에서는 1로 운영을 하여 트랜잭션 커밋(Commit)시 매번 커밋 로그가 디스크에 반영될 때까지 기다린다. y LFG 개수를 정하여 데이터베이스를 생성하고 나면, LFG의 개수를 변경할 수 없다. 하지만, LFG의 로그 경로와 아카이브 알티베이스 튜닝 607 경로는 데이터베이스 생성 이후에도 변경이 가능하다. y 서로 다른 LFG가 동일한 로그 경로를 공유해서는 안된다. 즉, 모든 LFG의 로그 경로는 서로 달라야 한다. y 서로 다른 LFG가 동일한 아카이브 로그 경로를 공유해서는 안된다. 즉, 모든 LFG의 아카이브 로그 경로는 서로 달라야 한다. 608 ALTIBASE5 Administrator’s Manual 그룹 커밋 이 절에서는 트랜잭션 처리 성능 향상을 위해서 알티베이스가 제공하는 그룹 커밋 기능에 대해서 설명한다. 그룹 커밋의 개념 그룹 커밋은 트랜잭션의 커밋 요청을 모아서 한번에 처리하여 다수의 트랜잭션이 커밋을 하려는 환경에서 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 대기시간을 튜닝하는 방법에 대해서는 본 장의 ‘그룹 커밋 프로퍼티 튜닝’을 참조한다. 알티베이스 튜닝 609 하나의 트랜잭션이 커밋을 위해 로그를 기록하기 위한 디스크 I/O 를 수행할 때는 다음과 같은 체크를 수행한다. y 디스크로 기록하려고 하는 로그가 이미 다른 트랜잭션에 의해 디스크로 내려간 경우 이미 디스크로 기록된 로그를 재차 기록할 필요가 없기 때문에 트랜잭션은 디스크 I/O를 수행하지 않는다. y 마지막으로 I/O를 수행한 시각 이후로 사용자가LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정한 시간이 지나지 않은 경우 디스크 I/O를 실시하지 않고 대기한다. LFG_GROUP_COMMIT_RETRY_USEC 프로퍼티에 지정한 시간마다 한번씩 1, 2, 3을 다시 한번 체크한다. y 마지막으로 I/O를 수행한 시각 이후로 사용자가LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정한 시간이상 경과한 경우 디스크 I/O를 수행한 시각을 기록한다. 디스크 I/O를 위해 충분한 시간을 기다렸으므로, 로그의 맨 끝단까지 기록된 모든 로그를 디스크로 내리는 디스크 I/O를 수행한다. 그룹 커밋 수행 단위 앞서 LFG(Log File Group, 로그파일 그룹)기능에서 살펴본 바와 같이, 트랜잭션이 기록한 로그를 디스크로 기록하는 작업은 LFG 별로 각각 수행된다. 그러므로 그룹커밋도 서로 다른 LFG 간에 영향을 받지 않고 별개로 진행된다. 그룹 커밋 관련 프로퍼티 COMMIT_WRITE_WAIT_MODE 가 0 으로 설정된 경우, 정전시의 영속성(Durability)을 보장하지 않기 때문에, 트랜잭션 커밋시에 커밋 로그가 디스크에 반영되는 것을 기다리지 않는다. 그룹 커밋 기능은 트랜잭션의 영속성(Durability) 보장을 위한 디스크 I/O 를 모아서 처리하는 최적화 기법이다. 그러므로 COMMIT_WRITE_WAIT_MODE 가 1 로 설정되어 있을 경우에 의미가 있다. 1 로 설정된 경우에만 트랜잭션 커밋시 커밋 로그가 디스크에 반영될 때까지 기다리기 때문이다. 610 ALTIBASE5 Administrator’s Manual 그룹 커밋시 고려사항 그룹 커밋은 여러 트랜잭션이 동시에 커밋을 하려고 할 때에만 그 효과를 발휘한다. 예를 들어 시스템상에 오직 하나의 트랜잭션만이 커밋하려고 하는 경우에는 커밋하려는 다른 트랜잭션이 존재하지 않는 상황이 되며, 이 때에는 함께 모아서 처리할 추가적인 디스크 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 의 그룹 커밋 관련 통계값들은 다음과 같다. 알티베이스 튜닝 611 y UPDATE_TX_COUNT 해당 LFG에 속한 트랜잭션중 DB에 변경을 가한 트랜잭션의 개수를 실시간으로 보여주는 통계치이다. 이 값이 LFG_GROUP_COMMIT_UPDATE_TX_COUNT프로퍼티보다 클 때에만 해당 LFG에 대해 그룹 커밋을 실시한다. y GC_WAIT_COUNT 마지막으로 디스크 I/O를 수행한 시각 이후로 LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정한 만큼의 시간이 지나지 않아서 커밋을 위한 디스크 I/O를 수행하지 못하고 기다릴 때마다 1씩 증가하는 카운트 값이다. y GC_ALREADY_SYNC_COUNT 트랜잭션이 커밋을 위해 디스크로 기록해야 하는 로그의 내용이 이미 다른 트랜잭션에 의해 디스크로 기록된 경우에는 추가적인 디스크 I/O를 수행할 필요가 없다. 이와 같이 디스크 I/O를 수행하지 않고 바로 커밋 완료 응답 신호를 보내는 경우에 1씩 증가하는 카운트 값이다. y GC_REAL_SYNC_COUNT 실제 디스크 I/O를 수행하여 로그를 디스크로 기록한 경우 1씩 증가되는 카운트 값이다. 이는 두 가지 경우 중 하나이다. -하나의 트랜잭션이 커밋을 위해 로그를 디스크로 기록하려 하려는 시점에서 V$LFG의 UPDATE_TX_COUNT가 LFG_GROUP_COMMIT_UPDATE_TX_COUNT프로퍼티보다 작아서 그룹 커밋 기능이 활성화 되지 않아서 직접 로그 기록을 위한 디스크 I/O를 수행한 경우 -그룹 커밋이 활성화된 상황에서 마지막으로 디스크 I/O를 수행한 시각 이후로 LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정한 만큼의 시간이 지나서 실제 디스크 I/O를 수행한 경우 그룹 커밋 프로퍼티 튜닝 그룹 커밋 기능을 이용하기 위해서는 시스템 자체의 성능과 다수의 커밋하려는 트랜잭션이 발생하는 상황에서의 시스템의 부하를 종합적으로 고려하여 관련 프로퍼티를 최적값으로 설정해야 한다. 이제부터 각각의 프로퍼티값을 튜닝하는 방법에 대해 알아본다. y LFG_GROUP_COMMIT_UPDATE_TX_COUNT 이 프로퍼티의 값이 너무 작으면 DB에 변경을 가한 트랜잭션 수가 그다지 많지 않아도 그룹 커밋이 활성화된다. 이 경우, 로그를 기록하기 위한 디스크 I/O의 횟수가 증가하여 시스템 성능이 저하된다. 612 ALTIBASE5 Administrator’s Manual 이 프로퍼티의 값이 너무 크면 DB에 변경을 가한 트랜잭션의 수가 충분히 많음에도 불구하고 그룹커밋이 활성화되지 못한다. DBA는 시스템에 여러개의 트랜잭션이 몰리는 때에 V$LFG의UPDATE_TX_COUNT를 실시간으로 모니터링 하여 이 프로퍼티의 값을 적정한 값으로 결정할 수 있다. y LFG_GROUP_COMMIT_INTERVAL_USEC 이 프로퍼티의 값이 너무 작으면 빈번하게 I/O가 수행되어 시스템의 성능이 저하된다. 이러한 상황에서는 커밋을 위해 실제로 I/O를 수행하는 횟수가 많아지므로 V$LFG의 GC_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의 값이 점점 작아지면서 최적의 성능을 내는 상황이 이 프로퍼티가 최적의 값으로 설정된 것이다. GC_REAL_SYNC_COUNT의 값이 작아지는 것이 곧 최적의 성능을 내는 상황을 의미하지는 않는다. 앞서 설명한 대로 이 프로퍼티의 값이 너무 크면 커밋을 하려는 트랜잭션들이 디스크 I/O를 위해 불필요하게 많은 시간을 기다리게 되어 디스크 I/O를 수행할 수 있는데도 I/O를 수행하지 않고 대기하는 상황이 발생하기 때문이다. 또한 기본값인 1000에서 절반씩 감소시켜 가면서 같은 방법으로 최적의 TPS를 내는 상황을 찾아낸다. y LFG_GROUP_COMMIT_RETRY_USEC 이 프로퍼티의 값이 너무 작으면 디스크 I/O를 대기하는 트랜잭션들이 더 빈번하게 깨어나서 디스크 I/O를 수행해야 하는지 체크하게 된다. 이 경우 개별 트랜잭션의 커밋 후 응답시간은 짧아질 수 있지만, I/O가능 여부 체크를 너무 빈번하게 하게 되어서 CPU사용율이 높아지게 된다. 또한 이러한 상황에서는 빈번하게 I/O가능 여부를 체크한후 I/O를 위한 대기상태로 들어가기 때문에 V$LFG의 GC_WAIT_COUNT가 이 프로퍼티의 값이 클 때보다 빠른 속도로 증가한다. 이 프로퍼티의 값이 너무 크면 디스크 I/O를 대기하는 트랜잭션들의 디스크 I/O가 가능한지의 여부를 체크하는 횟수가 줄어들게 되며, CPU사용율이 낮아지게 된다. 하지만 I/O 가능 여부를 체크하기까지의 대기시간이 길어져서 개별 알티베이스 튜닝 613 트랜잭션의 커밋후 응답시간은 길어진다. DBA는 이 프로퍼티의 값을 변경하면서 Unix의 top 명령이나 Windows의 작업관리자를 통해 알티베이스 프로세스의 CPU 사용율을 모니터링하거나 개별 트랜잭션의 응답시간의 평균값을 측정하는 방식으로 이 프로퍼티 값을 최적의 값으로 설정할 수 있다. 알티베이스 모니터링 및 PBT 615 15. 알티베이스 모니터링 및 PBT 이 장에서는 알티베이스의 운영 상태를 확인하는 방법과 해당 내용을 분석하는 방법에 대해 설명한다. 616 ALTIBASE5 Administrator’s Manual 알티베이스 모니터링 알티베이스의 운영 상태를 확인하기 위해서는 Performance View 를 이용한다. Performance View 에 대한 자세한 설명은 데이터 딕셔너리의 성능 뷰를 참조하기 바란다. 세션/Statement 모니터링 알티베이스 운영 중 연결되어 있는 세션에 대한 정보를 확인한다. 하나의 세션은 여러 개의 Statement 1 를 할당 받아 사용할 수 있으며 세션 별로 세션 속성이 다르게 지정될 수 있다. 데이터베이스(테이블/인덱스) 정보 모니터링 생성된 테이블에 대한 정보를 확인한다. 전체 데이터베이스에 대한 정보와 테이블스페이스 각 테이블 및 인덱스 정보를 확인할 수 있다. 메모리 사용량 모니터링 알티베이스 서버가 운영하면서 사용하는 메모리 영역 정보를 확인한다. 메모리 테이블스페이스의 데이터(버전) 저장 영역 및 인덱스 저장 영역, 질의 처리를 위한 임시 영역, 세션 정보 저장 공간, 메모리 버퍼 풀 등의 메모리 사용량 정보를 확인할 수 있다. 상태 모니터링 이중화 상태 정보를 확인한다. 이중화 관련 쓰레드(Sender/Receiver) 상태와 이중화 데이터 전송 상태를 확인할 수 있다. 1 Statement 는 하나의 SQL 문을 처리하기 위해 내부적으로 사용되는 객체이며 하나의 statement 는 하나의 SQL 문을 처리한다. 알티베이스 모니터링 및 PBT 617 알티베이스 문제상황 분석 알티베이스 운영 중 발생할 수 있는 여러 가지 문제 상황에 대하여 점검 사항 및 분석 방법에 대해 설명한다. 실제 운영 환경에서는 다양한 형태의 문제가 발생되며 미리 형태를 예측할 수 없는 경우도 있으므로 반드시 여기서 설명하는 바와 같이 진행되는 것은 아니다. 하지만 예측 가능한 범위 내에서 형태별로 나누어 일반적인 방법을 제시하여 문제 상황에 대처할 수 있는 정보를 제공하고자 한다. 예측 가능한 문제 발생 형태는 크게 다음과 같이 생각해 볼 수 있다. y 알티베이스 프로세스 비정상 종료 및 재구동시 문제 y 알티베이스 서버 응답 상태 문제 y 디스크 사용량의 문제 y 메모리 사용량의 문제 y CPU 사용량의 문제 y 이중화 문제 y 응용프로그램 및 쿼리 수행시 문제 일반적인 문제상황 분석(PBT, Problem Tracking) 절차는 다음과 같다. [그림 15-1] 문제상황 분석 절차 알티베이스 관리자 로그란 $ALTIBASE_HOME/trc 디렉터리에 문제유형 알티베이스 관리자 로그 (altibase_XXX.log) 관련정보 수집 (알티베이스 모니터링 도구/시스템 모니터링 커맨드 사용) 원인 분석 및 문제해결 618 ALTIBASE5 Administrator’s Manual 생성되어 있는 텍스트 로그이다. altibase_boot.log, altibase_id.log, altibase_mt.log, altibase_qp.log, altibase_rp.log, altibase_sm.log 파일이 있다. 알티베이스 프로세스 비정상 종료 및 재구동 문제 프로세스 비정상 종료 알티베이스 프로세스가 비정상적으로 종료할 수 있는 원인은 다음과 같이 생각할 수 있다. y 가용 메모리가 부족한 상황 y 시스템 OS 패닉 상태 이러한 경우 관리자 로그의 에러 메시지를 통해 판단이 가능하며 가용 메모리 부족으로 인해 발생하는 경우를 제외하고는 전문 엔지니어에게 문의해야 한다. 가용 메모리가 부족한 경우라면 관리자 로그에 “Memory allocation failed.” 혹은 “Unable to invoke a system function, shmget().”와 같이 메모리 할당 관련 시스템 콜 에러 메시지가 기록된다. 이 경우에는 메모리 사용량을 점검해야 하며, 불필요하게 많이 사용하는 부분을 확인하고 이러한 부분이 있다면 해당 부분의 메모리를 해제하여 메모리를 확보하고 원인을 찾아 재발을 방지해야 한다. 만일 불필요하게 사용하는 부분이 없다면 시스템 메모리 업그레이드를 고려해야 한다. 메모리 관련 부분은 다음에 나올 메모리 사용량의 문제에서 좀 더 자세히 설명하기로 한다. 알티베이스 재구동 실패 알티베이스 재구동 시 실패할 수 있는 원인은 다음과 같은 것을 생각 해볼수 있다. y 동일한 서비스 포트(PORT_NO 프러퍼티)를 사용하는 알티베이스 프로세스가 이미 존재하는 경우 y 구동 또는 회복 시 필요한 파일이 없거나 파일에 대한 권한이나 파일 시스템 문제로 인해 접근이 안 되는 경우 관리자 로그에 파일 접근 관련 에러가 발생한다면 해당 파일들(모든 로그 파일, 모든 로그 앵커 파일, 모든 데이터 파일)이 존재하는지를 확인한다. 파일이 존재하고 접근이 가능함에도 불구하고 에러가 발생한다면 파일이 깨졌을 가능성이 있으며 이 경우 데이터베이스를 새로 생성해야 한다. y 공유메모리 모드로 사용 시 이전에 사용한 공유 메모리와 파일상의 데이터베이스 이미지가 호환이 안 되는 경우 알티베이스 모니터링 및 PBT 619 공유메모리 호환 문제로 인해 구동이 실패하는 경우 현재 공유메모리를 삭제하고 다시 구동하여야 한다. 공유메모리를 삭제하는 방법은 알티베이스 공유메모리 관리도구(shmutil)를 사용하거나 시스템 명령인 “ipcrm” 명령에 의해 가능하다. “ipcrm” 명령어를 사용하여 삭제할 공유메모리는 “ipcs” 명령어로 검색하면 된다. y 시스템 리소스 부족 시스템 리소스 부족으로 인한 구동 실패는 여러 가지 시스템 리소스 중 어떤 리소스가 부족한지를 확인하여 실제 시스템에 적재되어 있는 리소스 가용량을 확인하고 시스템 커널 설정을 확인하여 문제가 있는 부분을 해결해야 한다. 구동 시 주로 문제가 되는 리소스는 메모리, 세마포어이다. 메모리의 경우 시스템 커널 설정에서 한 프로세스 당 사용 가능한 메모리의 크기, 사용 가능한 공유메모리 크기, 공유메모리 세그먼트의 최대 크기등을 확인해 봐야 한다. 알티베이스 설정에서 공유메모리 모드로 사용할 경우 “STARTUP_SHM_CHUNK_SIZE”의 설정값이 사용 가능한 공유메모리 세그먼트의 최대크기를 넘으면 안된다. 세마포어의 경우 IPC 통신을 위해 필요하며 알티베이스 설정 중 “IPC_CHANNEL_COUNT”와 관련이 있다. IPC 통신에 필요한 시스템 자원을 확인해 보기 위해서는 알티베이스에서 제공하는 “checkipc” 도구를 이용하면 된다. “checkipc” 도구를 이용하여 검사를 해보면 시스템의 어떤 항목이 얼마나 필요한지와 실제 커널의 설정값을 확인해 볼 수 있으며 알티베이스 설정과 시스템 커널 설정을 적절하게 조정하여 해결이 가능하다. 알티베이스 서버 응답 상태 문제 알티베이스 서버가 실제로 질의를 처리하고 있지만 응답속도가 매우 늦다면 서버가 응답이 없는 상태로 오해할 수 있다. 질의 처리 요청 시 응답이 늦는 경우, 이유는 대부분 테이블을 풀스캔하는 경우와 메모리 부족으로 인해 스와핑이 발생하는 경우가 있을 수 있으며 세션정보 확인과 시스템 정보를 통해 해당 질의가 수행 중인지를 확인이 필요하다. CPU 사용량이 높거나 가용 메모리가 부족하여 스와핑이 발생한다면 실제로 질의를 처리하고 있는 경우일 가능성이 높다. 620 ALTIBASE5 Administrator’s Manual 자세한 사항은 다음에 나올 응용프로그램 및 쿼리 수행시 문제 에서 좀 더 자세히 설명하기로 한다. 또 다른 원인으로는 디스크 여유 공간이 부족하여 데이터 변경이나 입력 시 응답이 없는 경우를 생각할 수 있다. 이러한 경우에는 시스템 관리자 로그에 디스크의 여유 공간이 없음을 알리는 에러 메시지가 남게되며 디스크 공간이 확보되기 전까지 응답이 없는 상태로 남아있게 된다. 디스크 공간 부족으로 인한 문제 해결 방법은 다음에 나올 디스크 사용량의 문제에서 좀 더 자세히 설명하기로 한다. 이 외에 다른 문제로 알티베이스 서버가 응답이 없는 상태로 남아있다면 전문 엔지니어에게 문의해야 한다. 디스크 사용량의 문제 디스크 가용 공간 부족 알티베이스가 운영 중에 디스크 공간이 부족하게 되면 더 이상 데이터 변경작업이 이루어 지지 않고 멈춰있는 현상이 발생 할 수 있다. 이런 경우 먼저 여러 파일 시스템 중 어떤 곳의 공간이 부족한지를 확인해야 한다. 알티베이스가 운영 중에 사용하는 디스크 공간은 다음과 같다. y 로그 파일 저장 공간 y 각 테이블스페이스 파일 저장 공간 알티베이스는 운영 중에 액티브 로그와 아카이브 로그가 지속적으로 생성되며 액티브 로그 파일은 알티베이스 설정 파일(altibase.properties) 항목 중 “LOG_DIR”에 설정된 디렉터리에 저장이 되고 아카이브 로그 파일은 데이터베이스 모드가 ARCHIVE LOG 모드로 운영될 경우 자동으로 “ARCHIVE_DIR”에 설정된 디렉터리에 저장된다. 액티브 로그의 경우는 디스크 공간이 부족하여 더 이상 저장이 불가능 하면 알티베이스가 멈추게 되며 이런 경우 로그 파일과 로그 앵커파일을 지우게 되면 더 이상 복구가 불가능해지므로 해당 파일 시스템의 크기를 늘이거나 이외에 다른 불필요한 파일이 있다면 삭제하여 디스크 공간을 확보해야 한다. 아카이브 로그의 경우에는 설정 파일의 “ARCHIVE_FULL_ACTION” 항목의 설정값이 0 인 경우 아카이브 로그를 저장하지 않고 계속 운영되게 되며, 1 인 경우 해당 파일 시스템의 가용공간이 확보될 때까지 멈춰있게 된다. “LOG_DIR” 디렉터리에 로그 파일의 개수가 많아져 로그 저장 공간이 부족해 진 경우 먼저 관리자 로그 파일을 확인하여 알티베이스 모니터링 및 PBT 621 체크포인트가 정상적으로 이루어 지고 있는지를 확인해야 하며 알티베이스 설정 파일 내에 “CHECKPOINT_INTERVAL_IN_SEC” 항목과 “CHECKPOINT_INTERVAL_IN_LOG” 항목의 설정이 적절한지 확인하여야 한다. 만일 체크포인트가 정상적으로 이루어 지고 있음에도 불구하고 아카이브 로그 파일들이 “LOG_DIR” 디렉터리에 계속 남아 있다면 이중화 전송 상태를 확인해야 한다. 이중화 전송이 계속 밀리고 있거나 전송 불가능 상태라면 아카이브 로그를 처리하지 못하고 “LOG_DIR”에 계속 보관해야 하므로 로그 저장 공간이 부족해 질 수 있다. 이중화 관련 문제 해결 방법은 다음에 나올 이중화 문제에서 좀 더 자세히 설명하기로 한다 메모리 테이블스페이스와 각 시스템 테이블스페이스는 설정 파일 중 “MEM_DB_DIR” 항목에 설정된 디렉터리에 저장되게 된다. 테이블스페이스 관련 디스크 부족 현상이라면 이 부분 또는 사용자가 생성한 테이블스페이스 파일이 저장된 공간을 확인해야 한다. 테이블스페이스 저장하는 파일 시스템은 최소 해당 테이블스페이스의 NEXT SIZE 크기 이상 여유 공간이 있어야 한다. 메모리 테이블스페이스의 저장 공간은 체크포인트가 수행될 때 실제로 기록이 되기 때문에 메모리 상에 존재하는 테이블스페이스 크기 이상 여유 공간이 필요하다. 메모리 사용량의 문제 알티베이스 운영 중 가용메모리가 부족해 진다면 응답시간이 매우 느려질 수 있으며 알티베이스가 비정상적으로 종료될 수 있다. 이런 경우가 발생된다면 알티베이스가 사용하고 있는 메모리 영역을 검사하여 해당 크기가 적절한지를 판단하고 불필요하게 사용되고 있는 부분을 제거해야 한다. 만일 불필요하게 사용하고 있는 영역이 없다면 메모리 증설을 고려 하여야 한다. 알티베이스가 운영 중에 사용하는 메모리 공간은 크게 나누어 보면 다음과 같다. y 메모리 테이블스페이스 y 임시 메모리 공간 y 메모리 버퍼 메모리 테이블스페이스에는 메모리 테이블의 실제 레코드 및 MVCC 로 인한 이전 레코드 버전이 저장된다. 임시 메모리 공간은 메모리 테이블에 생성된 테이블의 인덱스와 메모리 테이블 조회 시 정렬공간, 세션들의 정보를 저장하는 용도 등으로 사용된다. 622 ALTIBASE5 Administrator’s Manual 메모리 버퍼는 디스크 테이블에 대한 연산 및 정렬을 위해 사용되는 공간이다. 메모리 과다 사용이 의심된다면 일정기간 동안 생성되는 문장의 개수와 임시 메모리 영역의 크기, 메모리 테이블스페이스의 사용량, 메모리 테이블의 인덱스 크기 등을 모니터링 하여 증가량을 확인하여야 하며 이와 함께 “ps”나 “top”과 같은 시스템 모니터링 명령으로 프로세스의 크기가 지속적으로 증가되는 지 확인해 보아야 한다. 알티베이스가 처음 가동된 이후에 일정 기간 동안은 임시 메모리 영역과 여러 버전의 레코드 생성, 세션 정보의 증가로 인해 메모리 사용량이 증가할 수 있으며 이는 정상적인 경우이다. 만일 일정 기간 운영 이후에도 지속적으로 증가한다면 메모리 누수와 같은 이상이 있는지를 의심해 볼 수 있으며 이러한 경우 전문 엔지니어에게 문의를 해야 한다. CPU 사용량의 문제 알티베이스가 갑자기 CPU 사용량이 늘었다면 다음과 같은 상황들을 의심해 볼 수 있다. y 메모리 테이블 질의 처리 시 인덱스를 사용하지 못함 y 디스크 테이블 질의 처리 시 디스크 사용 과다 y 메모리 부족으로 인한 스왑핑 발생 시스템 성능 모니터링 도구를 이용하여 메모리 사용량을 확인하고 가용 메모리가 부족하여 스와핑이 발생한다면 가용 메모리를 확보해야 한다. 이에 대한 내용은 메모리 사용량의 문제에서 좀 더 자세히 설명하기로 한다. 메모리 부족 사항이 아니고 질의 처리 시 메모리 테이블 풀 스캔이나 디스크 테이블에서 디스크를 과다하게 사용한다면 해당 쿼리나 테이블 등을 튜닝하여 해결이 가능하다. 이에 대한 내용은 다음에 나올 응용 프로그램 및 쿼리 수행시 문제에서 좀 더 자세히 설명하기로 한다. 이중화 문제 이중화 관련하여 발생 할 수 있는 문제는 다음과 같은 형태가 있다. y 이중화 시작 실패 y 이중화 반영 속도가 매우 느림 알티베이스 모니터링 및 PBT 623 y 이중화 중인 테이블의 건수가 서로 틀림 이중화 전송에 문제가 발생되면 로그 저장 공간에 아카이브 로그 파일이 계속 남아있게 되어 가용 공간이 부족해지고 이로 인해 서비스가 안되고 멈춰있는 현상이 발생될 수 있다. 이중화 관련 문제가 발생됐다면 먼저 관리자 로그 파일에 이중화 관련 에러 메시지가 기록되어 있는지 확인하고 해당 내용을 전문 엔지니어에게 전달해야 한다. 한쪽 시스템에 장애가 발생하고 장애 상황이 장시간 지속되면 이중화 데이터 전송을 하지 못하여 로그 저장 디렉터리의 가용 공간이 부족해 지는 현상이 발생한다. 따라서 장시간 문제 해결이 어려운 경우에는 이중화를 중단하고 이중화 객체를 삭제하여 현재 운영중인 시스템에 문제가 생기지 않도록 하는 것을 고려해야 하며 이런 경우 장애 상황이 해제된 이후 장애 발생 시스템의 데이터 복구 작업이 추가적으로 필요하다. 데이터 복구 방법으로는 iLoader 도구를 이용하는 방법과 이중화의 시작 모드 중 SYNC 모드를 이용하는 방법이 있다. 만일 이중화 객체 삭제가 어려운 경우 로그 저장 디렉터리의 가용 공간을 지속적으로 확인하여 모자란 경우 확보를 해주어야 한다. 마찬가지로 이중화 네트워크 라인의 문제가 발생했다던지 이중화에 문제가 생겨 장시간 이중화가 연결되지 못하는 경우에도 동일한 조치가 필요하다. 응용프로그램 및 쿼리 수행시 문제 응용프로그램 및 쿼리 수행에 관해 생각해 볼 수 있는 문제 상황은 다음과 같다. y 응용프로그램에서 알티베이스로의 접속 실패 y 응용프로그램에서 알티베이스로 쿼리 요청 이후 멈추어 있거나 정해진 시간 동안 처리하지 못하여 타임아웃 발생 알티베이스 접속 실패 응용프로그램에서 접속이 실패한다면 알티베이스 질의 처리 도구인 isql 을 이용하여 접속을 시도해봤을 때 정상적으로 접속이 되는지 확인한다. 알티베이스에서는 접속시 3 가지의 접속 방식을 제공하기 때문에 (TCP/IP 방식, socket domain 방식, IPC 방식) 응용프로그램에서 사용하고 있는 접속 방식을 사용하여 시험해봐야 한다. 접속 방식을 설정하는 방법은 ISQL_CONNECTION 환경변수를 지정하여 가능하다. (TCP, UNIX, IPC) 624 ALTIBASE5 Administrator’s Manual 만일 접속이 성공된다면 응용프로그램 안에서 접속정보 설정 시 문제가 있는 것이므로 해당 부분의 오류를 찾아 해결하면 되며, 접속이 성공하지 못한다면 다음 사항들을 고려해 볼 수 있다. y 접속된 세션 수가 알티베이스 설정 항목 중 MAX_CLIENT 설정값을 초과함. y 접속 방식이 IPC 방식인 경우 IPC 방식으로 접속된 세션 수가 IPC_CHANNEL_COUNT 설정값을 초과함. 응답이 없거나 타임 아웃으로 인해 세션이 끊어짐 질의 처리시 수행 속도가 느려 응답이 없는 경우 다음과 같은 상황을 생각해 볼 수 있다. y 메모리 가용량이 부족하여 스왑핑이 발생 y 테이블을 풀 스캔하여 처리 성능이 저하 y 특정 테이블에 록을 요청하고 기다리고 있는 상태 시스템 성능 모니터링 도구를 이용하여 CPU 사용량과 메모리 사용량을 점검하여 메모리 부족 상황인지를 먼저 판단해야 하며 만일 메모리가 부족한 상황이라고 판단되면 메모리 사용량의 문제 를 참고하여 문제를 해결하여야 한다. 메모리가 부족한 상황이 아니면서 CPU 사용량이 높다면 현재 처리 중인 쿼리 중 테이블 풀 스캔을 유발하는 쿼리가 있는지를 확인해야 한다. 현재 수행 중인 쿼리 목록을 확인하려면 isql 을 접속하여 V$STATEMENT 테이블의 QUERY 칼럼을 조회하면 된다. 수행 중인 쿼리 중 의심되는 쿼리를 선정하여 실행 계획을 확인하고 문제가 있다면 튜닝을 해야 한다. 쿼리 튜닝에 대한 자세한 내용은 이 매뉴얼의 SQL 튜닝 을 참조한다. 위의 두 경우에 해당하지 않는다면 록을 기다리고 있는 상태를 의심할 수 있다. 현재 록 정보를 확인하고 특정 세션이 불필요하게 록을 획득하고 있는 상태로 지속되고 있다면 해당 세션을 강제로 종료하여 해결할 수 있다. 부록 A: Trace Log 625 A. 부록: Trace Log 626 ALTIBASE5 Administrator’s Manual Trace Log 알티베이스 서버에서 수행되는 SQL 문의 정보, 에러 메시지 종류 또는 SQL 문의 수행 시간 등을 altibase_boot.log 파일에 기록하게 할 수 있는 프로퍼티로서 다음과 같은 내용을 altibase_boot.log 파일에 기록할 수 있다. 기본 값은 0 이며, 임의의 trace log 를 사용하기 위해 1 을 설정한다. 프로퍼티 파일에 명시된 값은 ALTER SYSTEM 문을 이용하여 변경할 수 있다. TRCLOG 설명 TRCLOG_DETAIL_PREDICATE explain plan 기능 사용 시 where 절의 predicate 분류 상태도 함께 display TRCLOG_SET_LOCK_TIME lock 설정 시간 기록 찾아보기 627 찾아보기 ㄱ 객체 접근 권한 ....................................... 298 교체 플러시 .............................................. 418 권한 .............................................................. 297 권한 해제 .................................................. 299 그룹 연산 .................................................. 489 그룹 커밋 .................................................. 616 글로벌 인덱스 ......................................... 372 기본 파티션 .............................................. 375 ㄴ 노-아카이브 로그 ................................... 432 논리적 백업 .............................................. 430 논파티션드 객체 ..................................... 366 논파티션드 인덱스 ................................ 370 ㄷ 다중 버전 동시성 제어 기법 ............ 400 다중 비저장 노드 ................................... 548 단일 비저장 노드 ................................... 512 단일 저장 노드 ....................................... 527 단일 키 인덱스 ....................................... 278 대기 모드 .................................................. 420 대용량 메모리 테이블.......................... 264 데이터 딕셔너리 ........................................ 17 데이터 테이블스페이스 ............................ 4 데이터베이스 객체 ................................ 260 데이터베이스 관련 프로퍼티 ................. 7 데이터베이스 링크 ................................ 262 데이터베이스 모드 ................................ 432 데이터베이스 생성 ..................................... 4 데이터베이스 정보 모니터링 ............ 624 데이터베이스 종료 ...................................... 7 데이터베이스 트리거 ............................ 261 디렉토리 ..................................................... 262 디스카드 ..................................................... 328 디스크 테이블 ................................ 264, 457 디스크 테이블스페이스 .............. 305, 317 디스크 테이블스페이스의 MVCC .... 404 디스크로부터 페이지 읽기 ................. 423 ㄹ 로그 파일 ........................................................ 5 로그 플러쉬 쓰레드 .............................. 611 로그파일 생성 쓰레드 .......................... 611 로그파일그룹 ............................................ 610 로우 구조 ................................................... 320 로우 마이그레이션 ................................. 321 로우 체이닝 .............................................. 321 로컬 인덱스 .............................................. 372 롤백 .............................................................. 395 리스트 파티션 .......................................... 384 리스트 파티션 프루닝 .......................... 495 ㅁ 매체 복구시 주의사항 .......................... 437 매체복구 ..................................................... 435 메모리 사용량 모니터링 ..................... 624 메모리 테이블 ................................ 264, 457 메모리 테이블스페이스 ................... 4, 309 메타 테이블 ................................................ 18 물리적 백업 .............................................. 430 628 ALTIBASE5 Administrator’s Manual ㅂ 백업 .............................................................. 430 백업 시 주의사항 ................................... 434 백업 정책 ................................................... 430 버퍼 관련 프로퍼티 .............................. 427 버퍼 관리 ................................................... 420 버퍼 관리자 구성요소 .......................... 414 버퍼 관리자 통계 정보 ........................ 428 버퍼 관리자의 구조 .............................. 414 버퍼 영역 ................................................... 414 버퍼 풀 ....................................................... 414 범위 파티션 .............................................. 377 범위 파티션 프루닝 .............................. 494 범위 파티션의 연산 .............................. 380 베이스 테이블 .......................................... 282 보안 기능의 구성 ................................... 601 보안 모듈 연동 구문 ............................ 604 보안 모듈 연동 방법 ............................ 602 보안의 개요 .............................................. 600 복구 .............................................................. 435 복구 정책 ................................................... 435 복합 키 인덱스 ....................................... 278 불완전 복구 .............................................. 436 뷰 ........................................................ 261, 282 비영구 저장 인덱스 .............................. 279 ㅅ 사용자 ............................................... 263, 295 상태 모니터링 .......................................... 624 상향식 인덱스 생성 .............................. 281 성능 관련 이슈 ....................................... 454 성능 뷰 ......................................................... 98 성능 뷰의 종류 ......................................... 99 세그먼트 ..................................................... 307 세션/statement 모니터링 .................... 624 스키마 객체 .............................................. 260 시노님 ............................................... 261, 287 시스템 접근 권한 .................................. 297 시스템 테이블 ......................................... 264 시퀀스 ............................................... 261, 284 실행 계획 .................................................. 507 실행 계획 트리 ....................................... 454 실행 노드 .................................................. 509 실행기 ......................................................... 458 ㅇ 아카이브 로그 ......................................... 432 아카이브 로그 쓰레드 ......................... 611 알티베이스 구동 ........................................ 12 알티베이스 모니터링 ............................ 624 알티베이스 문제상황 분석 ................ 625 알티베이스 종료 ........................................ 14 알티베이스 problem tracking ........... 625 암호 칼럼 .................................................. 605 암호 칼럼으로 변경 .............................. 606 암호 칼럼의 생성 .................................. 605 암호 칼럼의 해제 .................................. 607 암호화 ......................................................... 605 액세스 ......................................................... 471 언두 레코드 .............................................. 322 언두 테이블스페이스 ....................... 4, 322 언두 테이블스페이스 변경 ................ 326 언두 테이블스페이스 크기 계산 ..... 356 영구 저장 인덱스 .................................. 278 영속성 ......................................................... 408 오프라인 .................................................... 327 오프라인 백업 ......................................... 439 오프라인 백업 ......................................... 431 온라인 ......................................................... 327 온라인 백업 .............................................. 431 찾아보기 629 완전 복구 .................................................. 436 외래 키 제약조건 ................................... 274 유일 키 인덱스 ....................................... 278 유일 키 제약조건 ................................... 274 이중화 ......................................................... 262 이중화된 테이블 ..................................... 266 이진 비저장 노드 ................................... 538 이진 저장 노드 ....................................... 546 익스텐트 ..................................................... 307 인덱스 ............................................... 261, 277 인덱스 변경 .............................................. 280 인덱스 삭제 .............................................. 281 인덱스 생성 .............................................. 279 인덱스 종류 .............................................. 277 인덱스 활용 .............................................. 281 인덱스의 생성 옵션 .............................. 280 일반 사용자 테이블 .............................. 264 임시 테이블스페이스 ................................. 4 ㅈ 자동복구 ..................................................... 435 잠금 .............................................................. 397 저장 프로시저 ......................................... 289 저장 프로시저 및 저장 함수 ............ 261 저장 함수 .................................................. 289 저장점 ......................................................... 396 접근 모드 .................................................. 420 정규화 ......................................................... 464 제약조건 ..................................................... 260 제약조건 관리 ......................................... 274 제약조건의 종류 ..................................... 274 조건절 ......................................................... 466 조인 .............................................................. 484 조인 순서의 결정 ................................... 481 중복 키 인덱스 ....................................... 278 질의 처리 ................................................... 459 질의 최적화 .............................................. 461 집합 연산의 최적화 .............................. 492 ㅊ 체크포인트 플러시 ................................. 419 최적화기 ..................................................... 458 ㅋ 칼럼 제약조건 .......................................... 275 커밋 .............................................................. 395 큐 테이블 ................................................... 271 ㅌ 테이블.......................................................... 260 테이블 관리 .............................................. 264 테이블 제약조건 ..................................... 275 테이블스페이스 ............................. 263, 304 테이블스페이스 공간 관리 ................. 356 테이블스페이스 관리 ............................ 329 테이블스페이스 백업 ............................ 341 테이블스페이스 복구 ............................ 341 테이블스페이스 분류 ............................ 313 테이블스페이스 상태 ............................ 327 트랜잭션 ..................................................... 394 트랜잭션 세그먼트 ................................. 323 트랜잭션 영속성 관리 방법 ............... 409 트리거.......................................................... 293 트리거 액션 .............................................. 293 트리거 이벤트 .......................................... 293 트리거 조건 .............................................. 293 ㅍ 파티셔닝 ..................................................... 366 파티션 방법 .............................................. 377 파티션 전제조건 ..................................... 375 630 ALTIBASE5 Administrator’s Manual 파티션 조건 .............................................. 375 파티션 키 ................................................... 367 파티션 필터링 .......................................... 497 파티션드 객체 ................................ 366, 368 파티션드 인덱스 ........................... 369, 370 파티션드 테이블 ..................................... 368 파티션의 최적화 ..................................... 494 페이지 ............................................... 307, 311 페이지 구조 .............................................. 317 페이지 리스트 .......................................... 311 페이지 리스트 다중화 .......................... 266 페이지 요청 처리 절차 ........................ 421 프라이머리 제약조건 ............................ 274 프로젝션 ..................................................... 498 프로퍼티 .......................................................... 7 프로퍼티 튜닝 .......................................... 619 플러셔 ......................................................... 418 플러시 ......................................................... 425 ㅎ 해시 테이블 .................................... 416, 421 해시 파티션 .............................................. 388 해시 파티션 프루닝 .............................. 496 휘발성 테이블스페이스 ................... 5, 312 힌트 .............................................................. 550 힌트 처리 정책 ....................................... 550 힌트의 종류 .............................................. 551 Ａ AGGR 실행 노드 .................................... 521 AGGREGATION node ............................ 562 ANTI-OUTR-JOIN node ........................ 563 AOJN 실행 노드 ..................................... 544 Ｂ BAG-UNION node .................................. 565 BCB .............................................................. 414 BCB 상태 변화 ........................................ 418 b-tree 인덱스 .......................................... 277 Buffer Area ............................................... 414 Buffer frame ............................................. 414 Buffer pool................................................ 414 BUNI 실행 노드 ..................................... 545 Ｃ CACHE ........................................................ 285 Checkpoint Flush ................................... 419 Checkpoint List ....................................... 417 CNF .............................................................. 551 commit ....................................................... 395 CONC 실행 노드 ................................... 545 CONCATENATION node ..................... 566 constant filter .......................................... 471 constraint .................................................. 260 Control 단계 ................................................. 6 cost .............................................................. 551 COUNT node ........................................... 566 CUNT 실행 노드 .................................... 526 CYCLE .......................................................... 285 Ｄ Database Link .......................................... 262 database objects .................................... 260 DECRYPT .................................................... 607 directory .................................................... 262 Discard ....................................................... 328 disk table ................................................... 264 distinct ........................................................ 491 DISTINCT node ....................................... 567 DISTINCT_HASH ..................................... 553 DISTINCT_SORT ...................................... 553 DNF ............................................................. 551 찾아보기 631 Ｅ ENCRYPT USING ..................................... 605 exclusive lock ........................................... 397 execution plan ......................................... 556 execution plan tree ............................... 454 executor ..................................................... 458 Explain Plan의 정의 .............................. 556 extent .......................................................... 307 Ｆ FILT 실행 노드 ........................................ 517 filter ............................................................. 471 FILTER node ............................................. 568 Flush List .................................................... 416 Flusher ........................................................ 418 FOJN 실행 노드 ..................................... 543 foreign key 제약조건 ........................... 274 FULL SCAN ................................................ 553 FULL-OUTER-JOIN node ..................... 569 Ｇ GRAG 실행 노드 .................................... 532 grant ............................................................ 298 GRBY 실행 노드 ..................................... 519 GROUP BUCKET COUNT ..................... 552 Group Commit ........................................ 616 GROUP_HASH .......................................... 552 GROUP_SORT .......................................... 552 GROUP-AGGREGATION node ........... 570 GROUPING node .................................... 572 Ｈ HASH 실행 노드 .................................... 530 HASH BUCKET COUNT ........................ 552 HASH node ............................................... 572 hash-based join ...................................... 487 HIER 실행 노드 ....................................... 526 HIERARCHICAL QUERY node ............. 574 hint ............................................................... 550 Hit Ratio 구하기 ..................................... 428 HSDS 실행 노드 ..................................... 533 Ｉ INCREMENT BY ....................................... 285 index .................................................. 261, 277 INDEX .......................................................... 553 INDEX ASC ................................................ 553 INDEX DESC .............................................. 553 intensive exclusive lock ........................ 397 intensive exclusive shared lock ........ 397 intensive shared lock ............................ 397 Ｊ join................................................................ 484 JOIN 실행 노드 ....................................... 538 JOIN node ................................................. 576 Ｋ key filter ..................................................... 471 key range ................................................... 471 Ｌ LEFT-OUTER-JOIN node ...................... 576 LFG 기능의 제약사항 ........................... 615 LFG기능의 한계점 .................................. 614 limit .............................................................. 494 LIMIT-SORT node ................................... 578 LMST 실행 노드 ..................................... 536 lock ............................................................... 397 Lock .............................................................. 422 Log File Creation Thread ..................... 611 Log Flush Thread .................................... 611 632 ALTIBASE5 Administrator’s Manual LOJN 실행 노드 ...................................... 542 LRU List ....................................................... 416 Ｍ MATERIALIZATION node ..................... 579 materialized node .................................. 561 memory table .......................................... 264 merge join ................................................. 488 Message queue table ........................... 271 meta 단계 ...................................................... 6 MGJN 실행 노드 .................................... 541 MINVALUE ................................................. 285 Multiplexing .............................................. 196 MVCC .......................................................... 400 MVCC 사용 시 주의사항 .................... 406 Ｎ nested loop join ..................................... 485 NO INDEX .................................................. 553 NO_PUSH_SELECT_VIEW ...................... 553 non-materialized node ........................ 561 normalization ........................................... 464 NOT NULL 제약조건 ............................. 274 NULL 제약조건 ........................................ 274 Ｏ object privilege ....................................... 298 Offline ......................................................... 327 offline 백업 ............................................... 439 Online .......................................................... 327 optimization ............................................. 461 optimizer .................................................... 458 order by ..................................................... 493 ORDERED ................................................... 551 Ｐ page ............................................................ 307 PARTITION-COORDINATOR .............. 589 PCRD 실행 노드 .................................... 549 PCTFREE ........................................... 318, 361 PCTUSED ......................................... 319, 361 Plan Node의 종류 ................................. 561 Plan Nodes ............................................... 561 plan tree .................................................... 556 Plan Tree ................................................... 559 Plan Tree Display ................................... 557 Prepare List .............................................. 417 primary key 제약조건 .......................... 274 privilege ..................................................... 297 process 단계 ................................................. 6 PROJ 실행 노드 ..................................... 518 PROJECT node ........................................ 581 projection .................................................. 498 properties ....................................................... 7 push selection 기법 .............................. 467 PUSH_SELECT_VIEW .............................. 553 Ｑ query processing ................................... 459 QUEUE table ............................................ 271 Ｒ Replacement Flush ................................ 418 replication ................................................. 262 revoke ......................................................... 299 rollback ...................................................... 395 r-tree 인덱스 ........................................... 277 rule ............................................................... 551 Ｓ savepoint ................................................... 396 찾아보기 633 SCAN 실행 노드 .................................... 513 SCAN node ............................................... 581 schema objects ....................................... 260 SDIF 실행 노드 ....................................... 547 SECURITY_ECC_POLICY_NAME ......... 603 SECURITY_MODULE_LIBRARY............ 603 SECURITY_MODULE_NAME ................ 603 Segment .................................................... 307 sequence ......................................... 261, 284 SET BUCKET COUNT ............................. 552 SET-DIFFERENCE node ......................... 583 SET-INTERSECT node ........................... 585 shared lock ............................................... 397 shutdown abort ......................................... 15 shutdown immediate .............................. 14 shutdown normal ...................................... 14 SITS 실행 노드........................................ 546 SORT 실행 노드 ..................................... 527 SORT MERGE JOIN node .................... 580 SORT node ............................................... 586 sort-based join ........................................ 486 SQL 튜닝 ................................................... 454 SQL 튜닝 일반 ........................................ 456 SQL Plan Cache ...................................... 592 SQL Plan Cache 관련 프로퍼티 ....... 595 SQL Plan Cache의 특징 ....................... 594 START WITH ............................................. 285 startup 단계 ................................................ 13 startup process ............................................ 6 startup service ............................................ 12 STOR 실행 노드 ..................................... 535 stored function ....................................... 289 stored procedure ................................... 289 strore procedure or funuction .......... 261 subquery .................................................... 500 Subquery 유형 ........................................ 500 subquery filter ......................................... 471 synonym ..................................................... 261 synonym ..................................................... 287 SYS 사용자 ................................................ 295 SYS_COLUMNS_ ........................................ 22 SYS_COMMENTS_ ..................................... 26 SYS_CONSTRAINT_COLUMNS_ ........... 29 SYS_CONSTRAINTS_ ................................ 27 SYS_DATABASE_ ........................................ 31 SYS_DATABASE_LINKS_ .......................... 32 SYS_DIRECTORIES_ ................................... 34 SYS_ENCRYPTED_COLUMNS_ .............. 35 SYS_GRANT_OBJECT_ .............................. 37 SYS_GRANT_SYSTEM_ ............................. 39 SYS_INDEX_COLUMNS_ ......................... 40 SYS_INDEX_PARTITIONS_ ...................... 42 SYS_INDICES_ ............................................. 44 SYS_LOBS_ ................................................... 46 SYS_PART_INDICES_ ................................ 47 SYS_PART_KEY_COLUMNS_ .................. 49 SYS_PART_LOBS_ ...................................... 50 SYS_PART_TABLES_ .................................. 51 SYS_PRIVILEGES_ ....................................... 53 SYS_PROC_PARAS_................................... 57 SYS_PROC_PARSE_ ................................... 59 SYS_PROC_RELATED_ .............................. 60 SYS_PROCEDURES_ .................................. 54 SYS_REPL_HOSTS_ .................................... 65 SYS_REPL_ITEMS ....................................... 66 SYS_REPL_OFFLINE_DIR_ ........................ 68 SYS_REPL_OLD_COLUMNS_ .................. 69 SYS_REPL_OLD_INDEX_COLUMNS_ ... 71 SYS_REPL_OLD_INDICES_ ...................... 73 SYS_REPL_OLD_ITEMS_ ........................... 75 634 ALTIBASE5 Administrator’s Manual SYS_REPL_RECOVERY_INFOS_ ............. 77 SYS_REPLICATIONS_ ................................ 62 SYS_SECURITY_ .......................................... 36 SYS_SYNONYMS_ ..................................... 78 SYS_TABLE_PARTITIONS_ ...................... 83 SYS_TABLES_ ............................................... 79 SYS_TBS_USERS_ ....................................... 85 SYS_TRIGGER_DML_TABLES_ ................ 89 SYS_TRIGGER_STRINGS_ ........................ 90 SYS_TRIGGER_UPDATE_COLUMNS_ .. 91 SYS_TRIGGERS_.......................................... 86 SYS_USERS_ ................................................. 92 SYS_VIEW_PARSE_ .................................... 94 SYS_VIEW_RELATED_ ............................... 95 SYS_VIEWS_ ................................................. 93 SYS_XA_HEURISTIC_TRANS_ ................. 97 sysdba 시스템 권한 ................................ 12 system privilege ...................................... 297 system table ............................................. 264 SYSTEM_ 사용자 ..................................... 295 Ｔ table ............................................................. 260 tablespace ................................................. 263 TD R-tree 인덱스 ................................... 277 TIMESTAMP 제약조건 .......................... 274 Trace Log ................................................... 636 Transaction Durability .......................... 408 trigger ............................................... 261, 293 trigger action ........................................... 293 trigger envent .......................................... 293 trigger restriction ................................... 293 TSS ................................................................ 406 Ｕ unique key 제약조건 ............................ 274 USE_HASH ................................................. 551 USE_NL ....................................................... 551 user .................................................... 263, 295 user table .................................................. 264 USER_MERGE ........................................... 551 USER_SORT ............................................... 551 Ｖ V$ALLCOLUMN ....................................... 103 V$ARCHIVE ............................................... 104 V$BUFFPAGEINFO ................................. 105 V$BUFFPOOL_STAT ............................... 109 V$CATALOG ............................................. 115 V$DATABASE ........................................... 116 V$DATAFILES ........................................... 118 V$DATATYPE ............................................ 121 V$DB_FREEPAGELISTS .......................... 129 V$DB_PROTOCOL .................................. 130 V$DBA_2PC_PENDING ......................... 125 V$DBLINK_REMOTE_STATEMENT_INFO .................................................................. 126 V$DBLINK_REMOTE_TRANSACTION_IN FO ............................................................ 127 V$DBLINK_TRANSACTION_INFO ..... 128 V$DISK_BTREE_HEADER ...................... 133 V$DISKTBL_INFO .................................... 131 V$EVENT_NAME ..................................... 136 V$FILESTAT ............................................... 139 V$FLUSHINFO ......................................... 141 V$INDEX .................................................... 142 V$INSTANCE ............................................ 143 V$LATCH ................................................... 144 V$LFG ......................................................... 145 V$LINKER_STATUS ................................. 148 V$LOCK ...................................................... 149 찾아보기 635 V$LOCK_STATEMENT ........................... 150 V$LOCK_WAIT ......................................... 152 V$LOG ........................................................ 151 V$MEM_BTREE_HEADER...................... 158 V$MEM_BTREE_NODEPOOL .............. 160 V$MEM_RTREE_HEADER ..................... 162 V$MEM_RTREE_NODEPOOL .............. 164 V$MEM_TABLESPACE_CHECKPOINT_P ATHS ....................................................... 169 V$MEM_TABLESPACE_STATUS_DESC .................................................................. 170 V$MEM_TABLESPACES ......................... 166 V$MEMGC ................................................. 153 V$MEMSTAT ............................................ 155 V$MEMTBL_INFO ................................... 156 V$MUTEX .................................................. 171 V$NLS_PARAMETERS ............................ 172 V$PALNTEXT ............................................ 174 V$PROCTEXT ............................................ 175 V$PROPERTY ............................................ 176 V$REPEXEC ............................................... 177 V$REPGAP ................................................. 178 V$REPLOGBUFFER ................................. 180 V$REPOFFLINE_STATUS ....................... 181 V$REPRECEIVER ...................................... 182 V$REPRECEIVER_TRANSTBL ............... 185 V$REPRECOVERY .................................... 186 V$REPSENDER ......................................... 188 V$REPSENDER_TRANSTBL .................. 191 V$REPSYNC .............................................. 192 V$SEGMENT ............................................. 193 V$SEQ ......................................................... 194 V$SERVICE_THREAD .............................. 196 V$SESSION ............................................... 199 V$SESSION_EVENT ................................. 206 V$SESSION_WAIT ................................... 208 V$SESSIONMGR ...................................... 205 V$SESSTAT ................................................ 210 V$SQL_PLAN_CACHE ............................ 212 V$SQL_PLAN_CACHE_PCO.................. 214 V$SQL_PLAN_CACHE_SQLTEXT ........ 216 V$SQLTEXT ................................................ 211 V$STABLE_MEM_DATAFILES .............. 217 V$STATEMENT ......................................... 218 V$STATNAME ........................................... 224 V$SYSSTAT ................................................ 227 V$SYSTEM_CONFLICT_PAGE .............. 228 V$SYSTEM_EVENT .................................. 229 V$SYSTEM_WAIT_CLASS ...................... 231 V$TAB ............................................................ 98 V$TABLE ..................................................... 233 V$TABLESPACES ...................................... 234 V$TRACELOG ............................................ 237 V$TRANSACTION ................................... 240 V$TRANSACTION_MGR ....................... 245 V$TSSEGS .................................................. 246 V$TXSEGS .................................................. 248 V$UDSEGS ................................................. 250 V$UNDO_BUFF_STAT ............................ 252 V$VERSION ............................................... 253 V$WAIT_CLASS_NAME ......................... 254 V$XID ........................................................... 256 view .................................................... 261, 282 VIEW 실행 노드 ...................................... 522 VIEW Node ............................................... 587 VIEW-SCAN node ................................... 588 VMTR 실행 노드 .................................... 535 VSCN 실행 노드 ..................................... 524

ALTIBASE HDB Administration Administrator’s Manual Release 5.5.1 (January 16, 2013) ----------------------------------------------------------- ALTIBASE Administration Administrator’s Manual Release 5.5.1 Copyright ⓒ 2001~2011 ALTIBASE Corp. All Rights Reserved. 본 문서의 저작권은 ㈜알티베이스에 있습니다. 이 문서에 대하여 당사의 동의 없이 무단으로 복제 또는 전용할 수 없습니다. ㈜알티베이스 152-790 서울시 구로구 구로동 182-13 대륭포스트타워Ⅱ 10층 전화: 02-2082-1114 팩스: 02-2082-1099 고객서비스포털: http://support.altibase.com homepage: http://www.altibase.com ----------------------------------------------------------- 목차 I 목 차 서문 ................................................................................................... i 이 매뉴얼에 대하여 .............................................................................................. ii 1. 알티베이스 소개 .................................................................................. 3 Hybrid DBMS개념 ................................................................................................. 4 알티베이스 특징 ................................................................................................. 10 알티베이스 구조 ................................................................................................. 17 2. 알티베이스 구성요소 ......................................................................... 25 알티베이스 디렉토리 .......................................................................................... 26 실행 바이너리 .................................................................................................... 32 알티베이스 라이브러리 ....................................................................................... 35 3. 데이터베이스 생성 ............................................................................. 37 데이터베이스 생성.............................................................................................. 38 4. 알티베이스 구동 및 종료 ................................................................... 45 알티베이스의 구동.............................................................................................. 46 알티베이스의 종료.............................................................................................. 49 5. 데이터베이스 객체 및 권한 ................................................................ 53 데이터베이스 객체 개요 ..................................................................................... 54 테이블 ................................................................................................................. 58 큐........................................................................................................................ 66 제약조건 ............................................................................................................. 69 인덱스 ................................................................................................................. 72 뷰........................................................................................................................ 78 시퀀스 관리 ........................................................................................................ 80 시노님 ................................................................................................................. 83 저장 프로시저 및 저장 함수 .............................................................................. 85 트리거 ................................................................................................................. 90 데이터베이스 사용자 .......................................................................................... 93 권한 .................................................................................................................... 95 II Administrator’s Manual 6. 테이블스페이스 .................................................................................. 99 테이블스페이스 정의 및 구조 .......................................................................... 100 테이블스페이스 분류 ........................................................................................ 109 디스크 테이블스페이스..................................................................................... 114 언두 테이블스페이스 ........................................................................................ 119 테이블스페이스 상태 ........................................................................................ 124 테이블스페이스 관리 ........................................................................................ 126 테이블스페이스 사용 예제 ............................................................................... 142 테이블스페이스 공간 관리 ............................................................................... 155 7. 파티션드 객체 ................................................................................. 167 파티셔닝 정의 .................................................................................................. 168 파티션드 객체 .................................................................................................. 171 파티션 조건 ...................................................................................................... 179 파티셔닝 방법 .................................................................................................. 181 8. 트랜잭션 관리 ................................................................................. 198 트랜잭션 ........................................................................................................... 199 잠금(Lock) ........................................................................................................ 203 다중 버전 동시성 제어 기법 ............................................................................ 206 트랜잭션의 영속성 ........................................................................................... 215 9. 버퍼 관리자 ..................................................................................... 221 버퍼 관리자의 구조 .......................................................................................... 222 버퍼 관리 ......................................................................................................... 229 버퍼 관련 프로퍼티 .......................................................................................... 237 버퍼 관리자 통계 정보..................................................................................... 238 10. 백업 및 복구 ................................................................................... 239 데이터베이스 백업 ........................................................................................... 240 알티베이스 복구 ............................................................................................... 246 백업 및 복구 사례들 ........................................................................................ 251 11. SQL 튜닝 ........................................................................................ 267 SQL 튜닝 개요 ................................................................................................. 268 질의 최적화 과정 ............................................................................................. 275 실행 계획 분석 ................................................................................................. 322 힌트의 활용 ...................................................................................................... 366 12. Explain Plan..................................................................................... 373 목차 III 개요 .................................................................................................................. 374 Plan Tree 보기 ................................................................................................. 377 Plan Nodes ....................................................................................................... 379 13. SQL Plan Cache ...............................................................................414 개요 .................................................................................................................. 415 SQL Plan Cache의 특징 ................................................................................... 417 SQL Plan Cache 관련 프로퍼티 ....................................................................... 418 14. 서버/클라이언트 통신........................................................................419 통신 방법 ......................................................................................................... 420 15. 알티베이스의 보안 ............................................................................425 보안의 개요 ...................................................................................................... 426 보안 기능의 구성 ............................................................................................. 428 보안 모듈 연동 방법 ........................................................................................ 429 보안 모듈 구동과 데이터 암호화 ..................................................................... 431 16. 알티베이스 튜닝 ...............................................................................435 로그 파일 그룹 ................................................................................................. 436 그룹 커밋 ......................................................................................................... 442 17. 알티베이스 진단 모니터링 ................................................................449 알티베이스 모니터링 ........................................................................................ 450 알티베이스 문제상황 분석 ............................................................................... 451 A. 부록: Trace Log ..................................................................... 461 Trace Log ......................................................................................................... 462 B. 알티베이스 최대치 ................................................................ 463 Altibase 객체들의 최대값 ................................................................................. 464 찾아보기........................................................................................ 465 서문 ii Administrator’s Manual 이 매뉴얼에 대하여 이 매뉴얼은 알티베이스를 구성, 관리, 사용하기 위해 필요한 개념에 대해 설명한다. 대상 사용자 이 매뉴얼은 다음과 같은 알티베이스 사용자를 대상으로 작성되었다. 데이터베이스 관리자 시스템 관리자 성능 관리자 다음과 같은 배경 지식을 가지고 이 매뉴얼을 읽는 것이 좋다. 컴퓨터, 운영 체제 및 운영 체제 유틸리티 운용에 필요한 기본 지식 관계형 데이터베이스 사용 경험 또는 데이터베이스 개념에 대한 이해 데이터베이스 서버 관리, 운영 체제 관리 또는 네트워크 관리 경험 소프트웨어 환경 이 매뉴얼은 데이터베이스 서버로 알티베이스 버전 5.5.1을 사용한다는 가정 하에 작성되었다. 이 매뉴얼의 구성 이 매뉴얼은 다음과 같이 구성되어 있다. 제 1장 알티베이스 소개 이 장은 알티베이스 데이터베이스 서버를 이해하는데 필요한 개념, 특징 및 구조에 대한 개요를 제공한다. 제 2장 알티베이스 구성 요소 이 장은 알티베이스를 구성하고 있는 실행 바이너리 부문과 프로그래밍 라이브러리 부문 구성 요소들에 대해 설명한다. 제 3장 데이터베이스 생성 이 장은 데이터베이스를 구성하는 대표적 구성 요소인 테이블스페이스와 로깅 시스템의 종류 및 데이터베이스 생성 서문 iii 방법에 관하여 설명한다. 제 4장 알티베이스 구동 및 종료 이 장은 알티베이스를 구동 및 종료 시키는 방법과 알티베이스 다단계 구동 시 내부적으로 수행하는 작업에 대해 설명한다. 제 5장 데이터베이스 객체 및 권한 이 장은 특정 사용자에 의해 생성된 제약조건, 인덱스, 시퀀스, 이중화, 테이블, 사용자 등 데이터베이스 객체들에 대해 설명한다. 또한, 시스템 및 스키마 객체 수준의 권한에 대해 설명한다. 제 6장 테이블스페이스 관리 이 장은 데이터베이스의 논리적 구조를 이해함으로써 데이터베이스의 공간 관리를 작은 단위로 제어하고, 물리적 데이터 영역을 효율적으로 관리하는 방법에 대해 설명한다. 제 7장 파티션드 객체 이 장은 대용량 데이터베이스 테이블을 여러 개의 작은 조각으로 분할하여 관리하는 파티션드 테이블에 대해 설명한다. 제 8장 트랜잭션 관리 이 장은 트랜잭션을 정의하고 트랜잭션을 사용하여 작업을 관리하는 방법에 대해 설명한다. 제 9장 버퍼 관리자 알티베이스는 대용량의 데이터가 디스크에 저장될 수 있도록 지원하는데, 메모리의 공간은 한정되어 있으므로 이를 전부 메모리에 적재할 수 없으므로 테이블, 인덱스, 레코드 등 모든 데이터에 접근하기 위해서는 먼저 디스크의 데이터를 메모리에 적재해야 한다. 이 장은 이러한 메모리 공간을 할당하고, 메모리 공간이 부족한 경우 필요한 데이터를 제공할 수 있도록 메모리 공간을 유지 및 관리하느 버퍼 관리자에 대하여 설명한다. 제 10장 백업 및 복구 이 장은 시스템 정전 또는 디스크, 데이터 파일 손상 유실 등과 같은 예기치 않은 상황으로 인해 알티베이스에 저장된 데이터가 손실될 경우를 대비하여 알티베이스에서 지원하는 백업 및 복구에 대하여 설명한다. 제 11장 SQL 튜닝 이 장은 질의 성능을 향상시키기 위한 SQL 튜닝 방법에 대하여 설명한다. 제 12장 Explain Plan 이 장은 알티베이스 DBMS 서버가 최적화된 질의를 실행하기 위해 수행하는 접근 경로를 설명한다. 제 13장 SQL Plan Cache 이 장은 알티베이스 SQL Plan Cache 기능에 대한 개념 및 특징에 대해 설명한다. 제 14장 Communication Layer iv Administrator’s Manual 이 장은 알티베이스 데이터베이스 서버와 클라이언트 응용프로그램간의 접속 방법과 프로토콜에 대해 설명한다. 제 15장 알티베이스의 보안 이 장은 데이터베이스의 정보를 보호하기 위한 알티베이스의 보안 기능에 대해 설명한다. 제 16장 알티베이스 튜닝 이 장은 알티베이스의 성능 향상을 위한 로그 파일 그룹과 그룹 커밋에 대해 설명한다. 제 17장 알티베이스 모니터링 및 PBT 이 장은 알티베이스의 운영상태를 확인하는 방법과 해당 내용을 분석하는 방법에 대해 설명한다. 또한, 알티베이스 운영 중 발생할 수 있는 여러 가지 문제 상황에 대하여 점검 사항 및 분석 방법에 대해 설명한다. A. 부록: Trace Log 이 부록은 알티베이스 서버에서 실행되는 SQL문 관련 정보를 trace 로그로 남기는 방법을 설명한다. B. 부록: 알티베이스 최대치 이 부록은 알티베이스 객체들의 최대값을 기술한다. 문서화 규칙 이 절에서는 이 매뉴얼에서 사용하는 규칙에 대해 설명한다. 이 규칙을 이해하면 이 매뉴얼과 설명서 세트의 다른 매뉴얼에서 정보를 쉽게 찾을 수 있다. 여기서 설명하는 규칙은 다음과 같다. 구문 다이어그램 샘플 코드 규칙 구문 다이어그램 이 매뉴얼에서는 다음 구성 요소로 구축된 다이어그램을 사용하여, 명령문의 구문을 설명한다. 구성 요소 의미 예약어 명령문이 시작한다. 완전한 명령문이 아닌 구문 요소는 화살표로 시작한다. 명령문이 다음 라인에 계속된다. 완전한 명령문이 아닌 구문 요소는 이 기호로 종료한다. 명령문이 이전 라인으로부터 계속된다. 완전한 명령문이 아닌 구문 요소는 이 기호로 시작한다. ; 명령문이 종료한다. 서문 v SELECT 필수 항목 NOT 선택적 항목 ADD DROP 선택사항이 있는 필수 항목. 한 항목만 제공해야 한다. ASC DESC 선택사항이 있는 선택적 항목. , ASC DESC 선택적 항목. 여러 항목이 허용된다. 각 반복 앞부분에 콤마가 와야 한다. 샘플 코드 규칙 코드 예제는 SQL, Stored Procedure, iSQL, 또는 다른 명령 라인 구문들을 예를 들어 설명한다. 아래 테이블은 코드 예제에서 사용된 인쇄 규칙에 대해 설명한다. 규칙 의미 예제 [ ] 선택 항목을 표시 VARCHAR [(size)] [[FIXED |] VARIABLE] { } 필수 항목 표시. 반드시 하나 이 상을 선택해야 되는 표시 { ENABLE | DISABLE | COMPILE } | 선택 또는 필수 항목 표시의 인 자 구분 표시 { ENABLE | DISABLE | COMPILE } [ ENABLE | DISABLE | COMPILE ] . . . 그 이전 인자의 반복 표시 예제 코드들의 생략되는 것을 표 시 SQL> SELECT ename FROM employee; ENAME ------------------------ SWNO HJNO HSCHOI . . 20 rows selected. vi Administrator’s Manual 그 밖의 기호 위에서 보여진 기호 이 외에 기 호들 EXEC :p1 := 1; acc NUMBER(11,2); 기울임 꼴 구문 요소에서 사용자가 지정해 야 하는 변수, 특수한 값을 제공 해야만 하는 위치 지정자 SELECT * FROM table_name; CONNECT userID/password; 소문자 사용자가 제공하는 프로그램의 요소들, 예를 들어 테이블 이름, 칼럼 이름, 파일 이름 등 SELECT ename FROM employee; 대문자 시스템에서 제공하는 요소들 또 는 구문에 나타나는 키워드 DESC SYSTEM_.SYS_INDICES_; 관련 자료 자세한 정보를 위하여 다음 문서 목록을 참조하기 바란다. Installation Guide Getting Started Guide SQL Reference Stored Procedures Manual iSQL User’s Manual Utilities Manual Error Message Reference 온라인 매뉴얼 알티베이스 고객서비스포털(http://support.altibase.com/)에서 국문 및 영문 매뉴얼(PDF, HTML)을 받을 수 있다. 알티베이스는 여러분의 의견을 환영합니다. 이 매뉴얼에 대한 여러분의 의견을 보내주시기 바랍니다. 사용자의 의견은 다음 버전의 매뉴얼을 작성하는데 많은 도움이 됩니다. 보내실 때에는 아래 내용과 함께 고객서비스포털(http://support.altibase.com/)로 보내주시기 바랍니다. 사용 중인 매뉴얼의 이름과 버전 매뉴얼에 대한 의견 사용자의 성함, 주소, 전화번호 서문 vii 이 외에도 알티베이스 기술지원 설명서의 오류와 누락된 부분 및 기타 기술적인 문제들에 대해서 이 주소로 보내주시면 정성껏 처리하겠습니다. 기술적인 부분과 관련하여 즉각적인 도움이 필요한 경우에는 기술지원센터로 연락하시기 바랍니다. 여러분의 의견에 항상 감사드립니다. 1. 알티베이스 소개 이 장에서는 알티베이스를 처음 접하는 사용자들을 위해서 Hybrid DBMS의 등장 배경과 알티베이스의 구조 및 특징에 대해서 설명한다. 4 Administrator’s Manual Hybrid DBMS개념 알티베이스의 새로운 개념인 Hybrid Database Management System(이하 Hybrid DBMS) 에 대해서 설명한다. Hybrid DBMS 등장 배경 Hybrid DBMS의 등장은 데이터를 저장하는 두 가지 대표적인 기억 장치인 메모리와 디스크의 특징과 밀접한 관련이 있다. 첫째, 메모리는 전자 게이트로 구성되어 있고 접근시간이 수 ns(십억 분의 일초) 단위로서 매우 빠르며 접근시간이 균일하고 정전 시에는 데이터가 소실되는 특징을 가지고 있다. 즉, 메모리는 휘발성 저장 매체이다. 반면에, 디스크는 헤드암과 플래터로 구성되어 있다. 디스크 접근시간이 수 us(백만 분의 일초)로 메모리에 비해서 상대적으로 느리다. 게다가 접근시간이 균일하지 않다. 최근에 좀 더 대중화된 SSD(Solid State Drives) 조차도 휘발성 메모리에 비해서는 접근 시간이 좀 느리다. 그러나 정전이 되더라도 디스크의 데이터는 영구히 보존되는 특징을 가지고 있다. 둘째, 메모리는 메인보드와 시스템 버스로 연결되어 있어 메인보드의 특성에 따라 최대 저장 크기가 결정 된다. 메인보드에 장착된 CPU가 32비트이면 메모리의 최대 크기는 4GB, CPU가 64비트라고 해도 최대 크기는 현재 수백 GB(십억 바이트)까지만 장착 가능하다. 반면에, 디스크는 메인보드와 I/O버스로 연결되어 있어 메인보드의 특징과 거의 무관하게 수 TB(일조 바이트)까지 구성이 가능하다. 요약하면, 일반적으로 메모리는 디스크에 비해 접근 시간이 수백배 빠르며 성능이 균일한 반면, 정전시 데이터가 소실되고 저장용량에 한계가 있다. 이에 반해, 디스크는 데이터가 영구히 저장되며 저장용량의 한계가 거의 없는 반면, 접근 시간이 느리고 일정하지 않다. 이런 기억장치의 특징에 따라서 DBMS는 디스크에 데이터를 저장하는 Disk-Resident DBMS(이하 DRDBMS)와 메모리에 데이터를 저장하는 Main-Memory DBMS(이하 MMDBMS)가 존재해 왔다. Hybrid DBMS는 이 두 가지 구조의 장점을 수용하고, 단점을 보완하여 개발 되었다. DRDBMS 등장 알티베이스 소개 5 DRDBMS구조는 데이터가 디스크에 저장되어 있고, DRDBMS가 디스크에 있는 데이터를 메모리 버퍼로 읽어서 응용프로그램에게 전달해 주는 형태이다. 이런 구조는 응용프로그램이 표준 SQL을 통해서 데이터에 접근하고, DBMS가 동시성제어 및 복구를 통해 데이터를 보호하기 때문에 응용프로그램의 개발이 훨씬 간편해지며 데이터 공유가 쉬운 장점이 있다. 또한 데이터가 디스크에 저장되어 있기 때문에 대용량 데이터베이스를 구성할 수 있다. 이런 장점 때문에, 지금까지 전 산업분야에서 DRDBMS가 광범위하게 사용되어 왔다. 하지만, 사회전반에 걸쳐 정보화가 급격히 진전되고 정보처리의 요구 성능이 높아지면서 데이터 처리에 대한 수요는 많았으나, DRDBMS의 낮은 평균 처리속도와 처리속도의 기복(jitter)의 문제 때문에 DRDBMS를 사용하지 못하는 분야가 많았다. 따라서 고성능 및 균일 성능의 데이터 처리를 필요로 하는 산업 분야에서는 지금까지 Custom Designed Memory DB를 사용하였다. 그러나 범용적이지 않고 데이터 관리에 필요한 모든 것을 직접 개발해야 했기 때문에 개발 및 유지보수가 어렵고, 성능, 가용성, 확장성 등에서 문제가 있었다. MMDBMS 등장 MMDBMS의 구조는 데이터가 메모리에 저장되어 있고 MMDBMS가 메모리에 있는 데이터를 읽어서 응용프로그램에 전달하는 형태이다. 이런 구조는 DRDBMS의 장점인 표준 SQL을 통한 데이터 접근, 동시성 제어 및 복구을 통한 데이터 보호, 이를 통한 응용프로그램의 개발과 데이터 공유의 용이성 등의 장점을 그대로 가진다. 또한 MMDBMS는 데이터를 메모리에 저장하기 때문에 디스크에 데이터를 저장하는 DRDBMS에 비해 평균처리 속도가 매우 빠르며 메모리의 특징인 균일한 성능을 보장한다. 따라서 고성능 및 균일 성능의 필요성 때문에 DRDBMS를 사용할 수 없는 분야에서 각광을 받고 있다. 일반적으로 DRDBMS에 비해서 MMDBMS가 갱신 연산은 약 10배, 검색 연산은 약 3배 이상의 성능을 보인다. 갱신 연산이 DRDBMS에 비해서 수백배가 아닌 이유는 MMDBMS도 데이터 보호를 위해서 DRDBMS와 똑같이 로그파일을 디스크에 기록하기 때문이다. 그럼에도 불구하고 MMDBMS의 갱신 연산이 더 빠른 이유는 MMDBMS는 데이터 보호가 DRDBMS에 6 Administrator’s Manual 비해서 훨씬 단순하게 최적화되어 있기 때문이다. 또한 검색 연산이 DRDBMS에 비해서 수백배가 아닌 이유는 DRDBMS도 데이터접근 성능을 높이기 위해 메모리 버퍼를 사용하기 때문이다. 그럼에도 불구하고 MMDBMS의 검색 연산이 더 빠른 이유는 데이터접근이 단순하게 최적화되어 있고, 메모리 접근 시 성능의 기복(jitter)이 없기 때문이다. 이런 고성능 및 균일성능의 장점에도 불구하고 데이터를 메모리에 저장해야 하는 MMDBMS는 정보처리의 요구량이 방대하여 수백 GB이상의 데이터를 저장해야 하는 산업분야에서 다시 한계를 나타내게 되었다. MMDBMS와 DRDBMS 혼용 구조 등장 이런 문제점을 극복하기 위해서 현재 가장 일반적으로 사용되는 구조는 데이터를 구분하여 저장하는 형태이다. 고성능이 필요한 데이터는 MMDBMS에, 대용량이 필요한 데이터는 DRDBMS에 저장함으로써 MMDBMS와 DRDBMS를 혼용한다. 이러한 구조는 MMDBMS와 DRDBMS의 공통정보에 대해서 서로 동기화해야 한다는 문제, MMDBMS와 DRDBMS를 같이 처리해야 하는 응용프로그램은 양쪽에 동시에 접속해서 처리해야 한다는 문제, 또한 장애 복구가 복잡하다는 문제들을 가지고 있다. 하지만 이제까지는 고성능처리와 대용량처리를 함께 처리할 방법이 없었기 때문에, 고성능처리와 대용량 정보처리가 필요한 분야에서는 일반적으로 활용되고 있다. Hybrid DBMS 등장 Hybrid DBMS는 DRDBMS, MMDBMS, 그리고 MMDBMS와 DRDBMS를 혼용하는 각각의 구조들의 장점을 수용하고 문제점을 해결하기 위해서 등장하게 되었다. Hybrid DBMS는 데이터를 구분하여, 고성능이 필요한 데이터는 메모리에, 대용량이 필요한 데이터는 디스크에 저장하되, 이 두 가지 데이터를 처리하는 DBMS는 하나로 통합된 구조를 가지고 있다. 고성능 정보처리와 대용량 정보처리를 하나의 DBMS에서 통합, 처리하는 구조이기 때문에, 앞서 설명한 혼용구조의 동기화 문제, 복잡한 장애처리 문제, 응용프로그램이 복잡해지는 문제를 해결하게 되었다. 또한 MMDBMS 전용, DRDBMS 전용, Hybrid DBMS 등 다양한 구성이 가능하게 되었다. 요약하면, Hybrid DBMS는 고성능 정보처리를 가능하게 하는 MMDBMS와 대용량 정보처리를 가능하게 하는 DRDBMS의 장점을 알티베이스 소개 7 결합하여 데이터는 구분하여 저장하고 데이터 관리는 통합한 구조이다. 즉, Hybrid DBMS는 효율적인 시간 활용으로 고성능 정보 처리가 가능하고, 효율적인 자원활용으로 대용량 정보처리를 할 수 있게 되었다. Hybrid DBMS는 고성능 및 대용량 정보처리가 모두 필요한 분야를 포함하여 포괄적으로 사용이 가능해졌다. DR DBMS 스 이 이 MM DBMS Hybrid MM DBMS 스 이 이 대용 고 DR DBMS 스 이 DR DBMS 스 이 이 MM DBMS 이 MM DBMS Hybrid MM DBMS 스 이 이 Hybrid DBMS 스 이 이 [그림 1-1] 고성능 대용량 DBMS구조 Hybrid DBMS 알티베이스의 특징 Hybrid DBMS인 알티베이스는 저장 관리자(Storage Manager)와 질의 처리기(Query Processor), 그리고 메인 모듈(Main Module)로 구성되어 있다. 저장 관리자는 동시성 제어 및 회복을 통한 데이터보호를 담당하는 모듈이고 질의 처리기는 표준 SQL로부터 실행계획을 생성하여 데이터접근을 담당하는 모듈이다. 마지막으로, 메인 모듈은 여러 개의 클라이언트로부터 수신되는 요청(Request)들을 동시에 처리할 수 있도록 서버의 세션 (session)과 쓰레드 (thread)의 관리를 담당하는 모듈이다. 저장 관리자 저장 관리자는 복구 관리자와 동시성 제어 부분으로 구성되어 있다. 저장 관리자는 Layer 구조로 구성하여, 구현 복잡도를 개선하고 구조적 안정성을 확보하였으며 보다 손쉽게 Layer별 Unit Test를 할 수 있어 결함 발생률를 줄였다. 복구 관리자는 메모리 테이블과 디스크 테이블의 로그파일이 통합되어 최적의 검사점 수행알고리즘이 적용되었으며, 개발과정에서 자동 복구 시험 도구(Automatic Recovery Test Tool)을 사용하여 8 Administrator’s Manual 오류 가능성을 줄였다. 동시성 제어 부분은 Index Layer와 Transaction Layer, Application Layer, Interface Layer로 구성되어 있고, Out-place MVCC와 In-place MVCC가 통합되었고, Transaction Status Slot과 Start SCN List 기법이 적용되어 동시수행 성능이 향상되었다. 그리고, B+트리(B+Tree) 인덱스도 인덱스 구조 수정 연산 (Structure Modification Operation)이 발생하였을 때 B+트리 검색 과정 중에 Latch를 잡지 않는 구조로 되어 있어서 더욱 성능이 향상되었다. 메모리 테이블스페이스와 디스크 테이블스페이스의 인터페이스가 통합되어 메모리, 디스크 테이블스페이스 사용이 편리해졌고 서로 쉽게 호환된다. 질의 처리기 질의 처리기는 질의 실행기(Query Executor)와 질의 최적화기(Query Optimizer)로 구성되며, 메모리 쿼리, 디스크 쿼리, 하이브리드 쿼리를 통합한 투명한 구조로 구성되었다. 질의 실행기는 Tuple-Set Processing으로 인한 노드간 의존성이 완전히 제거됨으로써 최소 Plan Node로 다양한 조인이 구현되었다. 조인 방법이 10개에서 34개로 확장되었음에도 불구하고, Plan Node는 하나만 추가되었다. 질의 최적화기는 부하가 거의 없는 실시간 통계정보가 활용되었고, 메모리 쿼리, 디스크 쿼리, 하이브리드 쿼리 구분 없이 비용 계산(cost estimation)을 투명하게 하도록 구현되었다. 또한 Join Greedy Algorithm을 Join Ordering 알고리즘으로 사용하여 최적화기의 탐색공간이 최소화되었다. 메인 모듈 세션 관리자(Session Manager)는 세션을 관리하는 역할을 한다. 쓰레드 관리자(Thread Manager)는 데이터를 처리하는 쓰레드들을 관리한다. 알티베이스 소개 9 Database Memory chunk Checkpoint Image Log Buffer Log file and Control file Log Buffer Data file Hybrid DBMS ALTIBASE Storage Manager Recovery Logging Check point managing Resources Concurrency Control Locking Versioning Indicies B+ Tree R Tree Pages Collection Page Query Processor Executor Plan Nodes Records and Temporary Tables Mathematics Module Optimizer Graph Plan Tree Logic Main Module Session ManagerThread Manager [그림 1-2] 알티베이스 내부 구조 10 Administrator’s Manual 알티베이스 특징 고성능 대용량 하이브리드 데이터베이스 시스템인 알티베이스에 대한 일반적인 내용을 소개한다. 하이브리드 데이터베이스 시스템으로써 알티베이스가 갖는 특징, 구조, 기능 등에 관하여 간략하게 설명한다. 이에 대한 자세한 내용은 알티베이스 각각의 세부 매뉴얼을 참조한다. 데이터 모델 알티베이스의 데이터 모델은 관계 모델 (relational model)을 채택하고 있다. 관계 모델은 세 가지 주요 요소를 포함한다. 구조(structure)는 데이터베이스를 저장하거나 접근하는 객체 단위로 테이블, 뷰, 인덱스 등을 일컫는다. 이들은 곧 연산자의 조작 단위가 된다. 연산(operation)은 데이터베이스의 데이터와 구조를 사용자들이 조작할 수 있도록 허용하는 행위(action)들을 정의한 것으로써 무결성 규칙을 수반한다. 무결성 규칙(integrity rule)은 데이터와 구조에 허용된 연산을 다루기 위한 법칙으로, 데이터와 구조를 보호하기 위한 것이다. 관계 데이터베이스 관리 시스템은 다음과 같은 장점을 제공한다. 물리적 데이터와 논리적 데이터 독립성을 유지한다. 모든 데이터에 대한 접근이 다양하고 쉽다. 데이터베이스 설계가 유연하다. 데이터베이스 저장 공간과 데이터의 중복을 줄일 수 있다. 엔진 구조 알티베이스는 클라이언트-서버 구조를 제공한다. 클라이언트-서버 구조는 클라이언트가 통신망을 통해 서버에 접근하는 형태로 기존의 RDBMS가 제공하는 방식이다. 알티베이스 서버는 내부적으로 다중 쓰레드 구조를 갖고 있다. 클라이언트-서버 구조에서 한 개의 클라이언트는 한 개의 서버 쓰레드와 세션(session)을 구성한다. 알티베이스 소개 11 인터페이스 알티베이스는 기존의 실시간 데이터베이스 시스템과는 달리 범용성을 추구하는 일환으로 산업 표준 인터페이스를 지원한다. 알티베이스에서 제공하는 데이터베이스 질의어는 SQL92 표준을 따른다. 프로그래밍 인터페이스로는 ODBC,OLE DB, JDBC, C/C++ Precompiler 등을 지원하고 있으며, 기존에 작성된 데이터베이스 응용 프로그램을 변환할 필요 없이 그대로 사용할 수 있다. 알티베이스 SQL에 대한 자세한 내용은 SQL Reference 를 참조한다. 다중버전 기법 알티베이스는 다중버전 기법(이하 MVCC: Multi-Version Concurrency Control)을 이용한 동시성 제어를 수행한다. 다중 버전 기법은 하나의 데이터에 대해 여러 개의 버전을 유지하여 읽기와 쓰기 연산에 대한 충돌을 없앰으로서 최대의 성능을 발휘할 수 있도록 하는 것이다. 특히, 기존의 row locking 방식의 단점이었던 읽으려고 하는 데이터가 이미 다른 수정 연산에 의해 lock이 걸려 있거나, 수정하려는 데이터를 다른 읽기 연산이 읽는 중이어서 장기간 대기해야 하는 문제점을 제거하였으며, 필요 없는 오래된 데이터를 즉시 회수함으로서 메모리의 낭비를 방지하였다. 다중 버전 기법은 대규모 사용자가 접근하는 환경에서 최적의 성능을 발휘하고, 데이터베이스를 종료하지 않고도 즉시 백업할 수 있는 핫-백업(hot-backup) 시스템을 지원한다. 알티베이스는 메모리 테이블과 디스크 테이블에 대해 외형상으로는 같은 기능을 하지만, 서로 다른 방법으로 MVCC를 구현하였다. 메모리 테이블은 레코드의 변경시마다 새로운 버전을 생성하는 out- place MVCC로 구현되어 있으며, 디스크 테이블의 경우는 변경된 데이터를 기존의 레코드에 덮어 쓰고, 변경 이전의 정보를 undo 테이블스페이스에 저장하여 참조하는 in-place MVCC 방식을 채택하고 있다. 트랜잭션 12 Administrator’s Manual 알티베이스는 Hybrid DBMS의 구조에 맞추어 최고의 성능을 낼 수 있는 트랜잭션 구조와 이와 관련된 다양한 기능을 제공한다. 먼저 데이터베이스 내에서 동시에 수행될 수 있는 트랜잭션의 개수를 프로퍼티를 이용해서 조절할 수 있다. 또한 효율적인 서버 운영을 위해 AUTOCOMMIT 모드를 사용할 수 있다. 그리고 알티베이스가 제공하는 트랜잭션의 고립화 수준(isolation level)은 read committed(=0), repeatable read(=1), no phantom read(=2)가 있으며, 사용자의 필요에 맞추어 적절하게 선택하여 사용할 수 있다. 로깅 데이터베이스 안정성과 영속성을 위하여 알티베이스는 변경된 데이터베이스 내용에 대하여 로깅(logging)을 수행한다. 또한 시스템간의 이중화 (Replication) 작업 때의 성능을 극대화 시키기 위해 최적의 로그를 생성한다. 버퍼 풀 (Buffer Pool) 디스크 테이블스페이스에 접근하는 트랜잭션들의 성능을 향상시키기 위해 디스크에 대한 I/O 회수를 최소화해야 한다. 이를 위해 버퍼 풀을 사용함으로써 이전에 디스크로부터 읽은 페이지들 중 일정 부분을 메모리에 캐시해 두어 디스크에서 다시 읽어들이는 것을 방지한다. 버퍼 풀은 Hot-Cold LRU(Least Recently Used) 알고리즘에 의해 관리된다. 더블 라이트 (Double Write) 파일 알티베이스 시스템의 페이지 크기와 파일 시스템의 물리적 페이지 크기가 다를 경우, 디스크 I/O 수행 중에 알티베이스 서버가 비정상적으로 종료하면 페이지가 온전하지 못한 상태로 남아있을 수 있다. 이런 현상을 방지하기 위하여 알티베이스는 페이지를 플러시할 때, 같은 이미지를 디스크의 더블 라이트 파일에 저장한 후, 페이지 원래 위치에 다시 저장한다. 그리고 알티베이스를 재구동할 때 더블 라이트 파일의 내용과 실제 페이지의 내용을 비교하여 손상된 페이지를 복구한다. 더블 라이트 기능은 디스크의 결함을 보완해 주지만, 시스템의 성능을 떨어뜨릴 수 있다. 이 기능은 사용자가 성능을 위해 사용하지 알티베이스 소개 13 않을 수 있다. 퍼지 汰廣 알티베이스는 최근의 데이터베이스 상태를 안전하게 백업(backup) 데이터베이스로 반영하기 위해 퍼지 汰廣수행한다. 메인 메모리 데이터베이스에서의 퍼지 체크포인트(fuzzy checkpoint)는 모든 변경된 데이터 페이지가 백업 데이터베이스로 내려가 현재 수행중인 트랜잭션의 수행에 영향을 미칠 수 있기 때문에 퍼지 체크포인트와 더불어 핑퐁 체크포인트(ping pong checkpoint) 방식을 함께 수행한다. 즉, 백업 데이터베이스를 두 개로 관리함으로써, 체크포인트 과정에서 부하를 줄일 수 있어 트랙잭션 동작이 최대한의 성능을 발휘할 수 있다. 저장 프로시저 (Stored Procedure) 저장 프로시저는 입력 인자, 출력 인자, 입출력 인자를 가지고 바디(body) 내에 정의된 조건에 따라 여러 SQL 문을 한번에 수행하는 데이터베이스 프로시저다. 저장 프로시저의 종류는 리턴값 유무에 따라 프로시저와 함수로 나누어 진다. 자세한 내용은 Stored Procedures Manual을 참고한다. 데드락 감지 (Deadlock Detection) 데드락은 트랜잭션간의 리소스 할당이 자동으로 해제될 수 없는 비정상적인 트랜잭션 정지 상태이다. 이러한 경우 일반적으로 데드락을 감지하는 별도의 쓰레드 또는 프로세스를 두게 되는데, 이러한 감지 구조는 필연적으로 일시적인 서비스 중단 사태를 초래한다. 알티베이스는 별도의 데드락 감지 쓰레드를 두지 않고, 데드락이 발생되는 순간 데드락 상황을 감지하여, 신속히 조치를 취함으로써 어떠한 경우에도 서비스가 중지되지 않도록 하며, 지속적이고 안정적인 데이터베이스 운용을 보장한다. 테이블 컴팩션 14 Administrator’s Manual 데이터베이스 운용시, 실제로 특정 메모리 테이블이 필요한 메모리 공간 이상을 차지하는 경우가 발생한다. 주로 대량의 데이터가 삽입 된 후 변경 및 삭제가 이루어지는 경우가 그러하다. 이런 경우 해당 테이블에서 필요 없는 메모리를 시스템으로 반환할 수 있다면, 보다 효율적으로 메모리 사용이 가능하다. 이런 필요로 인해 알티베이스는 메모리 테이블에 대해 테이블 단위의 컴팩션(compaction) 기능을 제공하며, 이 기능을 이용하여 메모리 및 테이블의 효율적 관리가 가능하다. 데이터베이스 이중화 알티베이스는 시스템의 높은 가용성(high availability)과 무정지(fault tolerance) 시스템을 위하여 로그 기반의 데이터베이스 이중화(replication)를 제공한다. 로그 기반의 이중화 시스템 구조는 트랜잭션 로그를 기반으로 데이터베이스를 이중화시킴으로써, 알티베이스의 효율성을 높이고 시스템 부하를 줄일 수 있다. 서비스 중인 지역(local) 시스템의 이중화 관리 쓰레드는 로그 데이터를 원격(Remote) 시스템의 이중화 관리 쓰레드에 실시간으로 전달한다. 원격 시스템의 이중화 관리 쓰레드는 전달받은 로그 데이터를 분석하여 이것을 알티베이스 서버에게 전달하고 알티베이스 서버는 이 내용을 데이터베이스에 반영한다. 이렇게 함으로써 서비스 중인 컴퓨팅 시스템이 중단되었을 때, 시스템 복구 시간이 필요 없이 곧바로 다른 시스템을 사용하여 서비스할 수 있는 체제를 갖추고 있다. 알티베이스는 부하 분산(load balancing) 기능도 제공한다. 알티베이스의 데이터베이스 복제 운영 환경에서, 서비스하는 트랜잭션들을 두 그룹 이상으로 나누어 각각의 트랜잭션이 해당 서버에서 수행되도록 구성하면, 각 서버에서 변경되는 데이터베이스 내용은 이중화를 통해서 상대편 서버에 반영됨으로써 복제된 데이터베이스의 일관성(consistency)을 보장할 수 있다. 클라이언트-서버 프로토콜 알티베이스를 클라이언트-서버 구조로 운영할 때, 사용자는 응용 시스템의 구성에 적합한 클라이언트-서버 프로토콜을 선택하여 사용할 수 있다. 알티베이스가 제공하는 통신 프로토콜로는 TCP/IP, IPC와 Unix Domain socket이 있다. TCP/IP(Transmission Control Protocol/Internet Protocol) 프로토콜은 네트워크 상에서 클라이언트-서버 간에 사용되는 알티베이스 소개 15 사실상의 표준 통신 프로토콜이다. IPC(Inter Process Communication) 프로토콜은 알티베이스가 제공하는 프로토콜로서, 공유메모리(shared memory)를 활용하여 클라이언트와 서버 간에 통신을 하도록 하였다. IPC 방법은 통신 패킷에 대하여 마샬링(marshaling)이 필요 없고 공유 메모리를 이용하기 때문에 다른 통신 프로토콜보다 빠른 통신 속도를 낼 수 있다. 클라이언트 프로그램과 알티베이스 서버가 상이한 컴퓨터 시스템에 존재하는 경우에는 인터넷 소켓을 이용한 TCP/IP 프로토콜을 사용하여야 하며, 이들이 동일 컴퓨터 시스템에 존재하는 경우에는 도메인 소켓을 이용한 프로토콜이나 IPC 프로토콜을 사용할 수 있다. 각각의 통신 프로토콜에 대한 성능은 IPC, 도메인 소켓, 인터넷 소켓 순으로 IPC가 가장 빠르다. 데이터베이스 공간 알티베이스 데이터베이스는 데이터베이스의 모든 데이터를 모아 저장하는 하나 이상의 테이블스페이스로 구성되고, 테이블스페이스는 크게 메모리 공간과 디스크 공간으로 나누어진다. 알티베이스가 생성하는 시스템 테이블스페이스 외에 사용자가 메모리와 디스크 각각의 공간에 테이블스페이스를 추가할 수 있다. Direct-Path INSERT Direct-Path INSERT는 데이터를 입력할 때 페이지의 빈 공간을 찾아 들어가는 대신 새로운 페이지를 만들어 데이터를 입력한다. 즉 데이터를 입력할 때 테이블의 빈 공간(free space)을 사용하지 않고, 테이블스페이스로부터 익스텐트(extent)를 새로 할당받는다. 또한 버퍼 관리자를 사용하지 않고, 전용 버퍼(Private Buffer)를 사용하기 때문에 버퍼 공간에 대하여 여러 트랜잭션과의 경합을 줄인다. 그리고 INSERT를 APPEND 방식으로 수행하여 리두(Redo) 및 언두(Undo)를 하지 않거나 줄여 로깅에 들어가는 비용을 줄인다. 데이터베이스 링크 알티베이스 데이터베이스 링크는 지역적으로 분리되어 있으나, 네트워크로 연결된 이기종의 데이터 서버들을 연동하여 개별 데이터들을 통합해 하나의 결과를 생성할 수 있게 한다. 16 Administrator’s Manual iSQL 알티베이스는 iSQL을 이용해 데이터베이스를 관리할 수 있어 빠르고 간편하게 데이터베이스를 관리할 수 있다. Audit 알티베이스는 Audit 기능을 통해 두 데이터베이스를 테이블 단위로 비교, 검사하여 데이터간의 불일치 정보를 출력하는 기능과 불일치가 발생한 경우 두 데이터베이스를 일치시키는 기능 등을 제공한다. iLoader 알티베이스는 iLoader 유틸리티를 제공하여, 데이터베이스의 이전이 나 테이블 단위의 백업 등을 할 때 테이블 단위로 데이터를 다운로드 하거나 업로드할 수 있도록 지원한다. Admin Center 알티베이스는 GUI 형태의 Admin Center 유틸리티를 제공하여, 관 리자가 보다 쉽게 데이터베이스에 접근할 수 있도록 한다. 알티베이 스 연결 및 모니터링 뿐만 아니라 테이블 및 각종 객체들에 대한 관 리를 윈도우 시스템에서 시각적으로 관리할 수 있도록 지원한다. 알티베이스 소개 17 알티베이스 구조 본 절에서는 알티베이스의 클라이언트-서버 구조를 중심으로 한 전체 구성도, 서버 프로세스 내부 구조, 데이터베이스 구조에 관하여 살펴본다. 전체 구성도 알티베이스의 전체 구성은 데이터 저장 관리자와 질의 처리기로 구성된 서버 부분과 응용 프로그램 작성을 위한 클라이언트 라이브러리, 그리고 이들 간의 통신 모듈로 구성되어 있다. Physical Memory Integrated Storage ManagerIntegrated Storage Manager Recovery Manager Buffer Manager Integrated Query ProcessorIntegrated Query Processor ParserOptimizerExecutor Index Manager E/SQLCLIODBCJDBC IPCUnix Domain SocketTCP/IP Transaction Manager Stable Storage Checkpoint Image Log BufferDisk BufferMemory Tablespace Stable LogDisk Tablespace Application [그림 1-3] 알티베이스 구성도 18 Administrator’s Manual 서버 프로세스 내부 구조 알티베이스 서버 프로세스의 내부 구조를 보면 메인 쓰레드, 서비스 데몬 쓰레드, 체크 포인트 쓰레드, 세션 관리 쓰레드, 가비지 콜렉션 쓰레드, 로그 플러시 쓰레드, 버퍼 플러시 쓰레드 그리고 아카이브로그 쓰레드가 있다. 각각의 쓰레드는 다음과 같은 일을 수행한다. 메인 쓰레드 모든 쓰레드를 생성/종료시키고 생성한 쓰레드들을 관리한다. 서비스 데몬 쓰레드 클라이언트의 연결 요청이 있으면, 서비스 쓰레드 풀(pool)에서 대기 상태에 있는 서비스 쓰레드와 요청한 클라이언트를 연결시킨다. 서비스 쓰레드 풀 서버가 구동되면 설정(configuration) 정보에 명시된 값만큼 서비스 쓰레드를 생성하여 서비스 쓰레드 풀에 저장한다. 서비스 쓰레드는 질의를 처리하는 쓰레드이다. 체크포인트 쓰레드 고장 복구 시에 일의 양을 줄이기 위하여, 주기적 또는 임의로 현재의 데이터베이스 및 시스템에 대한 상황을 데이터파일에 기록하는 쓰레드이다. 세션 관리 쓰레드 클라이언트와 서비스 쓰레드 간에 연결된 세션의 상태 즉, 이 세션이 단절되었지의 여부를 감시하는 쓰레드이다. 가비지 콜렉션 쓰레드 다중 버전 기법에서는 한 데이터에 대해 필요없는 오래된 데이터가 생성될 수 있다. 가비지 콜렉션 쓰레드(garbage collection thread)는 이러한 데이터가 필요없게 된 순간 그 즉시 메모리 공간을 회수하여, 재사용할 수 있도록 조치를 취함으로서 메모리 사용의 효율성을 극대화한다. 로그 플러시 쓰레드 알티베이스 소개 19 로그 플러시 쓰레드(log flush thread)는 데이터베이스 내의 모든 트랜잭션이 생성한 로그를 관리하고, 로그 버퍼에 모여진 다량의 로그 데이터를 로그 디스크에 반영하는 기능을 한다. 디스크에 완전히 반영(sync)된 로그는 데이터베이스 시스템의 장애 및 재해 발생 시에 데이터베이스를 안전하게 복구하는데 사용된다. 버퍼 플러시 쓰레드 버퍼 풀의 모든 메모리가 사용 중이면 디스크 I/O를 발생시켜서 수행중인 트랜잭션에 성능 상의 기복(Jitter) 현상을 일으키게 된다. 버퍼 플러시 쓰레드는 주기적으로 버퍼를 체크하여 일정 양 이상의 가용 버퍼 메모리를 항시 유지하도록 하며, 사용하지 않는 페이지를 디스크에 내리고 메모리를 사용 가능하게 만드는 역할을 한다. 아카이브로그 쓰레드 매체 오류에 대한 복구를 지원하기 위해 주기적으로 온라인 로그 파일들을 프로퍼티에 지정된 위치로 복사하는 쓰레드이다. 복사할 경로는 ARCHIVE_DIR 프로퍼티로 지정하면 된다. 알티베이스가 아카이브 모드로 운영될 때만 동작한다. ...... ...... [그림 1-4] 알티베이스 프로세스의 내부 구조 데이터베이스의 물리적 구조 알티베이스 데이터베이스는 물리적으로 로그앵커 파일, 로그 파일, 데이터 파일로 구성되어 있다. 로그앵커 파일 20 Administrator’s Manual 로그앵커 (loganchor) 파일은 데이터 파일과 로그와의 관계를 나타내는 중요한 정보를 포함한다. 이는 로그를 기준으로 한 시점에서 데이터 파일의 총체적인 정보를 나타낸다. 이 파일은 데이터 파일과 함께 중요한 백업 대상이다. 로그 파일 로그 파일(“리두 로그 파일”로 불리기도 함)은 트랜잭션의 원자성(Atomicity)과 영속성(Durability)을 유지하기 위해 사용된다. 원자성은 트랜잭션의 철회(rollback)를 통해 트랜잭션 수행 이전의 상태로 복귀할 수 있도록 하는 것이고, 영속성은 정상적으로 종료(commit)된 트랜잭션이 다양한 데이터베이스 장애로부터 원래의 내용을 복구할 수 있도록 하는 것이다. 로그 파일은 prepare 로그 파일과 active 로그 파일, archive 로그 파일로 구분할 수 있다. active 로그 파일은 실행중인 트랜잭션의 로그가 기록되는 로그파일이다. Prepare 로그 파일은 로그 기록 성능을 향상시키기 위해 미리 만들어지는 로그 파일로 실제 로그가 기록되기 전까지는 비어있는 상태이다. archive 로그 파일은 복구를 위하여 백업된 로그 파일로 기록이 완료된 로그 파일들이다. 로그 파일은 현재의 데이터베이스 상태를 가지는 매우 중요한 파일로서, 만일 현재 로그 파일이 손상을 입었을 경우 당시 작업의 유무에 관계없이 데이터베이스 전체가 손상을 입게 된다. 기존 로그 파일은 일반적으로 데이터 파일이 손상될 경우 백업 파일과 함께 데이터베이스를 복구하는데 사용된다. 데이터 파일 데이터 파일 중 SYS_TBS_MEM_DATA에는 기본으로 생성되는 시스템 메모리 테이블스페이스가 저장되며, SYS_TBS_MEM_DIC에는 메타 테이블들이, system.dbf 파일에는 기본으로 생성되는 디스크 테이블스페이스 (SYS_TBS_DISK_DATA)가 저장된다. 또한 temp.dbf 파일에는 쿼리 수행 시 중간 결과들이 저장되는 임시 테이블스페이스가 저장되며, undo.dbf 파일에는 다중버전 기법(MVCC: Multi- Version Concurrency Control)에서 사용되는 이전 이미지 정보들이 저장되는 언두 테이블스페이스가 저장된다. 알티베이스는 페이지 단위로 데이터파일 내에서 저장 공간을 관리한다. 페이지는 데이터베이스에 의해 사용되는 데이터의 가장 작은 단위이다. 페이지는 데이터베이스를 관리하기 위한 정보를 담고 있는 카탈로그 페이지와 사용자 데이터를 저장하는 데이터 페이지로 나누어 진다. 카탈로그 페이지는 현재 생성된 데이터베이스에 대한 상세한 명세를 알티베이스 소개 21 담고 있으며, 알티베이스의 구동 및 종료 시 데이터베이스의 일관성 검사에 사용된다. 카탈로그 페이지는 데이터베이스에서 사용되는 자기 자신을 제외한 나머지 데이터 페이지에 대한 리스트 및 사용정보를 담고 있으며, 백업 데이터베이스의 가장 첫 번째 페이지에 위치하고 있는 매우 중요한 페이지 영역이다. 데이터 페이지는 실제로 사용자 데이터가 저장되는 영역이며, 페이지 헤더와 페이지 본체(body)로 나누어진다. 페이지 헤더는 서로 간의 리스트를 유지하기 위한 링크 정보와 타입, 그리고 자기 자신의 페이지 번호로 구성되어 있다. 페이지 본체는 여러 개의 슬롯으로 분할된다. 이 슬롯이 실제 데이터가 저장되는 최종 저장소이다. 데이터베이스 논리적 구조 알티베이스는 논리적으로 메모리와 디스크 테이블스페이스 내에 데이터를 저장하고, 물리적으로는 해당 테이블스페이스와 관련된 데이터파일 내에 저장한다. 알티베이스 데이터베이스를 구성하는 각각의 테이블스페이스는 하나 이상의 데이터파일로 구성된다. 단, 하나의 데이터파일은 하나의 테이블스페이스에만 소속된다. 데이터베이스, 테이블스페이스 그리고 데이터파일은 밀접한 관계가 있으며 이 관계를 정리하면 다음과 같다. 데이터베이스는 논리적으로 테이블스페이스라는 저장 단위로 구성되어 있다. 즉, 테이블스페이스는 데이터베이스의 모든 데이터를 저장하는 논리적인 공간이다. 데이터베이스는 물리적으로 데이터파일이라고 불리는 하나 이상의 파일들로 구성된다. 즉 데이터파일은 데이터베이스의 모든 데이터를 저장하는 물리적 공간이다. 다음 그림은 테이블스페이스와 데이터파일의 관계를 설명한다. 22 Administrator’s Manual DATABASE TABLESPACE A TABLESPACE B TABLESPACE C DATAFILE 1 1 DATAFILE 2 2 DATAFILE 3 DATAFILE 4 4 DATAFILE 5 5 DATAFILE 6 DATAFILE 7 7 DATAFILE 8 8 DATAFILE 9 [그림 1-5] 데이터베이스 논리적 구조 알티베이스는 데이터베이스 내의 모든 데이터에 논리적 데이터베이스 영역인 테이블스페이스를 할당한다. 데이터베이스 영역 할당의 단위로는 페이지(page), 익스텐트(extent) 그리고 세그먼트(segment)가 있다. 페이지는 가장 작은 논리적 저장 단위로, 모든 데이터는 페이지 내에 저장된다. 페이지의 논리적인 다음 단계는 익스텐트이다. 즉 일정 개수의 연속적인 페이지들이 모여서 익스텐트라는 데이타베이스 영역을 형성한다. 익스텐트 상위의 논리적 데이터베이스 저장 단계를 세그먼트라고 한다. 하나의 세그먼트는 일련의 익스텐트의 집합이며, 한 세그먼트 내의 모든 익스텐트는 같은 테이블스페이스에 저장된다. 자세한 내용은 Administrator’s Manual을 참조한다. 기타 제어 파일들 부트 로그 파일 (altibase_boot.log) 알티베이스 서버가 동작된 상태를 기록한다. 이 파일이 기록하고 있는 정보로는 알티베이스 구동 및 종료 시 얻어지는 시스템 정보에 대한 세부사항이 있으며, 또한 알티베이스의 비정상 종료 시 알티베이스의 오류 발생 상태를 기록한다. 프로퍼티 파일 (altibase.properties) 알티베이스 서버의 환경 설정을 위한 파일이며 알티베이스 서버의 알티베이스 소개 23 운용 방식과 튜닝에 관한 모든 구성 요소를 포함하고 있다. 에러 메시지 파일 데이터 저장 관리 모듈, 질의 처리 모듈, 알티베이스 서버 메인 모듈, 그리고 함수 실행이나 데이터 타입과 관련된 오류 메시지를 수록한 파일이다. 2. 알티베이스 구성요소 이 장에서는 알티베이스의 주요 구성요소에 대해서 설명한다. 사용자는 알티베이스 패키지 설치 후에 실행 바이너리 부문과 프로그래밍 라이브러리 부문 등의 구성요소에 대해서 확인할 수 있다. 26 Administrator’s Manual 알티베이스 디렉토리 알티베이스를 설치하면 다음의 디렉토리가 생성된다. 알티베이스 홈 디렉토리는 환경 변수 ALTIBASE_HOME에 지정된다. 이 홈 디렉토리는 bin, conf, lib, include, msg, dbs, logs, sample, install, audit, trc, admin, 그리고 arch_logs 디렉토리를 포함하고 있다. 각 디렉토리의 역할과 포함하는 내용에 관하여 설명한다. admin 디렉토리 알티베이스 시스템 정보와 관련된 view를 생성하는 adminview.sql 파일과 프로시져, 테이블 정보를 볼 수 있는 프로시져를 생성하는 SQL 파일들이다. arch_logs 디렉토리 복구를 위해 로그 파일을 백업하는 백업 디렉토리이다. 이 디렉토리의 위치 및 디렉토리 이름은 프로퍼티 파일에 명시할 수 있다. audit 디렉토리 이중화 동작 시 발생한 데이터베이스간의 데이터 불일치를 해결하는 알티베이스 유틸리티인 audit의 예제 스크립트 파일이 들어있는 디렉토리이다. 자세한 설명은 Audit User’s Manual을 참조한다. bin 디렉토리 알티베이스를 포함한 알티베이스 관리도구와 알티베이스를 사용하는데 필요한 지원 도구들의 실행 파일이 존재하는 디렉토리이다. bin 디렉토리에는 다음과 같은 파일이 존재한다. 각각의 유틸리티에 대한 자세한 설명은 Utilities Manual을 참조한다. 알티베이스 구성요소 27 aexport, altibase, altierr, altimon, altipasswd, altiPofile, audit, checkServer, dumpla, dumplf, iloader, isql, killCheckServer, server, apre, shmutil conf 디렉토리 알티베이스 라이선스 및 알티베이스가 취할 수 있는 다양한 옵션을 수록한 프로퍼티 파일(altibase.properties)이 존재하는 디렉토리이다. 알티베이스 서버가 실행될 때 라이선스를 확인하고 프로퍼티 파일을 참조하여 서버 상태를 초기화한다. 알티베이스의 프로퍼티에 대한 자세한 설명은 General Reference를 참조한다. dbs 디렉토리 기본 프로퍼티를 이용할 경우 데이터베이스의 파일들이 생성되는 디렉토리이다. 이 디렉토리의 위치 및 디렉토리 명은 프로퍼티에 명시되어 있다. SYS_TBS_MEM_DATA 파일에는 기본으로 생성되는 시스템 메모리 테이블스페이스가, SYS_TBS_MEM_DIC 파일에는 메타 테이블이, system001.dbf 파일에는 기본으로 생성되는 디스크 테이블스페이스, temp001.dbf 파일에는 쿼리 수행 시 필요한 임시 결과들이 저장된다. undo001.dbf 파일에는 SQL문 수행과 복구에 필요한 이전 이미지 정보들이 저장된다. .dwf 파일은 더블 라이트 버퍼 파일로서 디스크 페이지가 임시로 저장된다. include 디렉토리 ODBC 라이브러리를 이용하여 응용 프로그램을 작성할 때 필요한 헤더 파일을 수록한 디렉토리이다. alaAPI.h 알티베이스 로그 분석기(ALA)에서 사용하는 API 헤더 파일이다. sqlcli.h 28 Administrator’s Manual 클라이언트 응용 프로그램을 작성할 때 필요한 헤더 파일이다. sqltypes.h ODBC 응용 프로그램 개발시 필요한 기초 데이터 타입에 대한 정보를 담고 있다. sqlucode.h 유니코드 정의 헤더 파일이다. ulpLibInterface.h C/C++ 전처리기(Precompiler)로 응용 프로그램 개발시 오류 처리 SQL 문장 구조에 대한 정보를 담고 있다. install 디렉토리 알티베이스 응용프로그램 작성에 필요한 makefile을 위한 매크로 설정 등이 포함된 altibase_env.mk 파일과 README 파일이 있다. lib 디렉토리 응용 프로그램 작성에 필요한 라이브러리를 수록한 디렉토리이며 다음과 같은 파일을 갖고있다. 각각의 라이브러리를 이용하여 응용 프로그램을 작성하는 방법은 Getting Started Guide에서 설명한다. Altibase.jar 알티베이스를 자바 응용프로그램에서 사용하기 위한 JDBC 드라이버이다. 순수 자바 언어로 구현된 Type 4 드라이버이다. libapre.a 내장 SQL 프로그램을 작성할 때 필요한 라이브러리이다. 내장 SQL 프로그램 작성에 관한 자세한 내용은 Precompiler User’s Manual을 참조한다. libodbccli.a 알티베이스 클라이언트-서버용 응용프로그램 작성을 위한 라이브러리이다. 알티베이스 구성요소 29 logs 디렉토리 로그앵커 파일들과 로그 파일들이 존재하는 디렉토리다. 이 디렉토리의 위치 및 디렉토리 명은 프로퍼티 파일에 명시할 수 있다. 로그앵커 파일명과 로그 파일명은 알티베이스 시스템에 의해 자동으로 결정된다. 로그 앵커를 가진 파일 시스템의 오류에 대비하기 위해서는 프로퍼티를 변경하여 여러 개의 로그 앵커 파일들을 각각 서로 다른 파일 시스템에 두어 관리하는 것이 좋다. msg 디렉토리 오류 메시지를 수록한 파일들을 포함하는 디렉토리다. 다음과 같은 파일이 있다. 오류 메시지는 영문만 제공된다. E_SM_ US7ASCII.msb 자료 저장 관리 모듈에서 발생할 수 있는 오류 메시지를 수록한 파일이다. E_QP_ US7ASCII.msb 질의 처리 모듈에서 발생할 수 있는 오류 메시지를 수록한 파일이다. E_MM_ US7ASCII.msb 알티베이스 서버의 메인 모듈에서 발생할 수 있는 오류 메시지를 수록한 파일이다. E_CM_ US7ASCII.msb 알티베이스 통신 모듈에서 발생할 수 있는 오류 메시지를 수록한 파일이다. E_RP_ US7ASCII.msb 알티베이스 이중화 모듈에서 발생할 수 있는 오류 메시지를 수록한 파일이다. E_ST_ US7ASCII.msb 알티베이스 저장 프로시저 모듈에서 발생할 수 있는 오류 메시지를 수록한 파일이다. 30 Administrator’s Manual E_ID_US7ASCII.msb, E_MT_ US7ASCII.msb 함수 실행이나 데이터 타입과 관련된 오류 메시지를 수록한 파일이다. sample 디렉토리 알티베이스의 응용 프로그램을 샘플로 제공한 디렉토리다. JDBC, ODBC, C/C++ 전처리기(precompiler) 라이브러리를 이용하여 작성된 프로그램과 Makefile이 수록되어 있다. trc 디렉토리 알티베이스 운영 상태를 기록한 파일들이 존재한다. 서버내의 가 모듈은 해당하는 트레이스 파일에 기록한다. altibase_boot.log 알티베이스 서버가 동작된 상태를 기록하고 있다. 이 파일이 기록하고 있는 정보로는 알티베이스 구동 및 종료시 생성되는 시스템 정보에 대한 세부사항이 있다. 또한 알티베이스의 비정상 종료시 알티베이스의 오류 발생 상태를 기록한다. altibase_id.log 시스템 레벨에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파일들이다. altibase_sm.log 저장관리자 모듈에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파일들이다. altibase_mt.log 데이터 타입 및 빌트인 함수 모듈에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파일들이다. altibase_rp.log 알티베이스 구성요소 31 이중화 모듈에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파일들이다. altibase_qp.log 질의 처리 모듈에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파일들이다. altibase_mm.log 메인 모듈에서 발생하는 경고 메시지나 트레이스 메시지 등이 기록되는 파일들이다. altibase_IPC.log IPC로 접속시 생성된 자원(resource)들에 대한 정보가 기록되는 파일이다. 32 Administrator’s Manual 실행 바이너리 여기에 설명된 외의 이들 바이너리 파일에 대한 더 자세한 정보는 Utilities Manual을 참고하기 바란다.. aexport 알티베이스 버전을 업그레이드할 때 필요한 일련의 작업들을 수행할 수 있는 도구로, 업그레이드를 위한 SQL 스크립트 파일, iSQL 실행 쉘 파일, iLoader 실행 쉘 파일을 자동으로 만든다. altibase 클라이언트-서버 구조로 운영할 때의 서버이다. altierr 오류 코드에 대한 세부 내용을 검색하여 출력한다. altimon.sh 알티베이스의 동작 상태를 모니터링하는 쉘 스크립트 프로그램이다. altiProfile SQL 문의 통계정보(수행 횟수, 수행 시간)를 수집하는 도구이다. altipasswd sys 계정의 패스워드를 변경하기 위한 도구이다. audit 알티베이스 구성요소 33 audit은 두 데이터베이스를 테이블 단위로 비교, 검사하여 불일치 정보를 출력하는 기능과 불일치가 발생한 경우 두 데이터베이스를 일치시키는 기능 등 두 가지를 제공한다. 이에 대한 자세한 내용은 Audit User’s Manual을 참조한다. checkServer 알티베이스의 상태를 체크하여 비정상 종료시 수행해야 할 일을 스크립트 파일로 만들어 실행할 수 있도록 한다. dumpla 알티베이스 로그앵커 파일의 내용을 출력 및 검사한다. dumplf 알티베이스 로그 파일의 내용을 출력 및 검사한다. dump_stack.sh 알티베이스 비정상 종료시 프로세스의 콜 스택을 출력한다. iloader 데이터베이스의 특정 테이블을 로드 및 언로드할 수 있는 도구이다. 이 도구에 대한 자세한 내용은 iLoader User’s Manual을 참조한다. isql 대화형으로 알티베이스 데이터베이스 질의를 수행할 수 있는 도구이다. 이 도구에 대한 자세한 내용은 iSQL User’s Manual을 참조한다. 34 Administrator’s Manual killCheckServer 실행중인 checkServer를 종료시킨다. server 알티베이스의 구동 및 종료, 재시작 등의 동작을 수행할 수 있도록 작성된 쉘 스크립트 프로그램이다. apre 내장 SQL문을 사용하여 응용 프로그램을 작성한 후, 작성된 응용 프로그램을 전처리(precompile)하기 위한 전처리 실행 파일이다. 자세한 설명은 Precompiler User’s Manual을 참조한다. shmutil 공유메모리 데이터베이스 관리 도구이다. 알티베이스의 공유 메모리를 메인 메모리 데이터베이스로 사용하는 경우, shmutil로 공유메모리에 관련된 관리 작업을 한다. * 구체적인 참조 매뉴얼을 명시하지 않은 실행 파일은 Utilities Manual을 참조한다. 알티베이스 구성요소 35 알티베이스 라이브러리 알티베이스의 응용 프로그램을 작성할 때 필요한 구성 요소들로서, 다음과 같은 것들이 있다. C 또는 C++ 언어로 프로그램을 작성할 때 필요한 라이브러리 ODBC 인터페이스를 제공하는 라이브러리 (libodbccli.a) MS-Windows 환경에서 ODBC 프로그래밍할 수 있는 ODBC 드라이버 (altibase_odbc.dll) 자바 언어로 프로그래밍할 때 필요한 자바 클래스 라이브러리 (Altibase.jar) 프로그래밍에 필요한 헤더 파일들 이에 대해서는 Getting Started Guide에서 자세히 설명한다. 3. 데이터베이스 생성 알티베이스 설치 후에 데이터베이스 관리자는 사용자 데이터 발생량을 예측하여 데이터베이스를 생성하고 관리해야 한다. 이 장에서는 데이터베이스 생성시에 알고 있어야 할 주요사항들에 대해서 설명하고 있다. 38 Administrator’s Manual 데이터베이스 생성 알티베이스 데이터베이스는 데이터의 논리적 저장 단위인 테이블스페이스로 구성된다. 알티베이스는 데이터를 논리적으로는 테이블스페이스에, 물리적으로는 테이블스페이스에 대응하는 데이터파일에 저장한다. 데이터베이스 서버를 구동하기 전에, 데이터베이스를 미리 생성시켜 놓아야 한다. 여기에서는 테이블스페이스와 로깅 시스템의 종류 및 데이터베이스 생성 방법에 관하여 설명한다. 테이블스페이스의 종류 알티베이스의 데이터베이스는 여러 개의 테이블스페이스로 구성된다. 테이블 스페이스는 그 사용처와 데이터를 저장하는 방법에 따라서 여러 종류로 분류된다. 메모리 테이블스페이스 외의 각 테이블스페이스를 구성하는 파일들은 기본으로 *.dbf의 확장자를 가지며, CREATE DATABASE 시에 생성되는 파일의 위치는 $ALTIBASE_HOME/dbs/ 이다. Note: 사용자가 테이블스페이스를 생성하거나 테이블스페이스에 파일을 추가할 때 명시하는 파일의 확장자와 파일의 경로에는 제한이 없다. 알티베이스에서 제공하는 기본 테이블스페이스는 아래와 같다. 메모리 테이블스페이스 메모리 테이블스페이스는 메모리에 존재한다. 딕셔너리 테이블들과 메모리 테이블들, 그리고 이에 관련된 다양한 데이터베이스 객체들이 저장되는 테이블스페이스이다. 데이터 테이블스페이스 디스크 테이블들과 인덱스들이 저장되는 테이블스페이스이다. 이는 다시 시스템 데이터 테이블스페이스와 사용자 데이터 테이블스페이스로 구분된다. 언두 테이블스페이스(Undo Tablespace) 디스크 테이블에 존재하는 레코드들의 다중버전 동시성 제어 (MVCC: Multi-Versioned Concurrency Control)를 위해 변경 데이터베이스 생성 39 이전 이미지를 일정 기간 동안 저장해두는 테이블스페이스 이다. 임시 테이블스페이스(Temporary Tablespace) 질의를 처리하는 과정에서 발생되는 임시 테이블들과 인덱스들을 저장하는 테이블스페이스이다. 데이터 테이블스페이스와 마찬가지로 시스템 임시 테이블스페이스와 사용자 임시 테이블스페이스로 나뉜다. 휘발성 테이블스페이스(Volatile Tablespace) 디스크 입출력을 하지 않고, 메모리에 객체를 저장하는 테이블스페이스이므로 보다 빠른 성능이 보장된다. 데이터베이스 서비스 종료시 모든 휘발성 데이터 객체들이 사라진다. 휘발성 테이블스페이스의 크기는 시스템의 사용 가능한 물리적 메모리 공간을 초과할 수 없다. 로깅 시스템 데이터베이스 내의 데이터들은 어떤 상황 하에서도 영속성 (Durability)을 가져야 한다. 알티베이스는 다음의 두 가지 파일들로 로깅 시스템을 구성하여 데이터의 영속성을 보장한다. 로그 파일 트랜잭션 수행 중에 발생할 수 있는 비정상 종료에 대비하여 시스템 복구 (system recovery)를 할 수 있도록 작성되는 로그 레코드들을 기록하는 파일들이다. 로그 파일의 이름은 logfile**이다 (**은 로그 파일의 일련 번호이다). 로그 앵커(Log Anchor) 파일 테이블스페이스들에 대한 정보와 데이터파일들의 위치, 체크 포인트 관련 정보 등 서버 운용에 관련된 중요한 데이터가 저장된 파일이다. 서버가 정상적으로 구동 되려면 이 파일의 내용이 유효하여야 하며, 그렇지 않을 경우에는 서버를 구동 시킬 수 없다. 또한 로그 앵커 파일은 데이터베이스 복구시에도 사용된다. 최초 데이터베이스 생성시 로그 파일과 로그 앵커 파일들은 $ALTIBASE_HOME/logs/ 위치에 생성된다. 알티베이스는 이 로그 앵커 파일들을 3개로 유지하며, 데이터베이스 생성 시 로그 파일들과 같은 위치에 생성되지만, 3개의 로그 앵커 파일들을 서로 다른 파일 시스템에 두기를 권장하고 있다. 로그 앵커 40 Administrator’s Manual 파일의 위치에 관련된 프로퍼티는 LOGANCHOR_DIR 이다. 이 프로퍼티에 대한 자세한 설명은 Getting Started Guide을 참고하기 바란다. 데이터베이스 생성 준비 데이터베이스를 생성하려면 알티베이스 패키지에 제공되는 iSQL유틸리티를 사용한다. 먼저 iSQL 유틸리티를 SYSDBA 모드로 실행한다. $ isql -u sys -p manager -sysdba 이는 알티베이스가 실행되어 있지 않은 경우에는 데이터베이스에 접속하지 않고 isql을 관리자 모드 (admin mode)로 띄우는 것이며, 실행 결과는 아래와 같다. ------------------------------------------------ Altibase Client Query utility. Release Version 5.5.1.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. ------------------------------------------------ ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 iSQL(sysdba)> 위의 상태가 되면 일단 CREATE DATABASE 명령을 수행하기 위해 서버 프로세스를 구동 시켜야 한다. 서버의 구동은 다음과 같은 순서로 이루어 진다. 1. 1단계: Pre-Process 단계 서버를 구동하기 이전 단계로, 알티베이스는 데이터베이스 메모 리를 초기화한다. 데이터베이스의 생성은 Process 단계에서 가능하며, 이 단계에 서 Process 단계로 가려면 다음의 명령을 실행한다. iSQL> startup process Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE: PROCESS Command execute success. 2. 2단계: Process 단계 CREATE DATABASE 구문으로 데이터베이스를 생성하거나 알 티베이스 프로퍼티들을 조회하고 변경할 수 있는 단계이다. 3. 3단계: Control 단계 데이터베이스 파일이 모두 로드되어 있는 상태의 단계이다. 또한 데이터베이스 생성 41 재시작 복구 (restart recovery)를 위한 준비도 완료된 단계이다. 재시작 복구에 대한 설명은 8장의 “데이터베이스 복구” 절을 참 고한다. 4. 4단계: Meta 단계 복구가 완료된 단계이다. 이 단계에서는 메타 데이터의 업그레이 드와 온라인 로그의 리셋 (reset)이 가능하다. 5. 5단계: Service 단계 사용자에게 서비스를 제공할 준비가 된 최종 단계이다. 데이터베이스 생성 Process 단계에서 데이터베이스를 생성하기 위한 CREATE DATABASE 명령은 아래와 같이 수행한다. CREATE DATABASE 구문의 자세한 사용법은 SQL Reference를 참조한다. 여기서는 기본 옵션을 사용해서 데이터베이스를 생성하는 예를 보여주고 있다. iSQL> create database mydb initsize=50M noarchivelog character set ksc5601 national character set utf16; DB Info (Page Size = 32768) (Page Count = 1537) (Total DB Size = 50364416) (DB File Size = 1073741824) Creating MMDB FILES [SUCCESS] Creating Catalog Tables [SUCCESS] Creating DRDB FILES [SUCCESS] [SM] Rebuilding Indices [Total Count:0] [SUCCESS] DB Writing Completed. All Done. Create success. 데이터베이스 서버 종료 데이터베이스의 생성이 완료되면 이를 위해 띄웠던 서버를 종료하거나, 서비스 단계로 진행할 수 있다. 서버의 종료는 다음과 같이 수행한다. iSQL(sysdba)> shutdown abort iSQL(sysdba)> 서버를 종료하면 isql은 다시 서버에 접속하지 않은 Pre-Process 상태가 되며, 서버 프로세스도 종료된다. shutdown 명령의 옵션으로는 abort외에 immediate와 normal이 더 있으나, 이들은 서버가 service 단계일 때만 수행이 가능하다. 42 Administrator’s Manual 데이터베이스 생성 관련 프로퍼티 CREATE DATABASE 구문을 수행할 때 지정하지 않은 속성들은 알티베이스 프로퍼티 파일의 설정에 의해 결정되는데, 그 파일은 $ALTIBASE_HOME/conf/altibase.properties이다. 관련있는 프로퍼티들은 아래와 같다. 표에서 물음표 (“?”)는 환경변수 ALTIBASE_HOME에 설정된 경로를 가리킨다. 아래 표에 나열한 데이터베이스 초기화와 관련된 알티베이스 프로퍼티에 대해 완벽히 이해하기 바란다. 프로퍼티 이름 설명 기본값 DB_NAME 생성할 데이터베이스의 이름 mydb MEM_DB_DIR 데이터베이스 파일들이 위치할 디렉 터리. 최대 3개까지 지정할 수 있다. ?/dbs SERVER_MSGLOG_DIR 알티베이스 운용 중 발생되는 서버의 메시지를 기록하는 파일 (altibased_boot.log)이 위치하는 디 렉터리 ?/trc SHM_DB_KEY 공유 메모리 버전으로 알티베이스를 띄울 경우에 사용할 공유메모리의 키 값 0 (사용안 함) MEM_MAX_DB_SIZE 전체 메모리 테이블스페이스들의 최 대 크기 4G LOGANCHOR_DIR 로그 앵커 파일들이 위치할 디렉터 리. 최대 3개까지 지정할 수 있다 ?/logs LOG_DIR 로그 파일들이 위치할 디렉터리 ?/logs LOG_FILE_SIZE 로그 파일 하나의 크기 10M STARTUP_SHM_CHUNK_SIZE 알티베이스 구동 시 생성되는 공유메 모리 한 개의 최대 크기 1G EXPAND_CHUNK_PAGE_COUNT 한 번에 할당하는 메모리 테이블스페 이스 페이지의 개수 3200 TEMP_PAGE_CHUNK_COUNT 한 번에 할당하는 메모리 테이블스페 이스 임시 페이지의 개수 128 SYS_DATA_TBS_EXTENT_SIZE 시스템 데이터 테이블스페이스의 익 스텐트 한 개의 크기 256K SYS_DATA_FILE_INIT_SIZE CREATE DATABASE 구문 실행 시 생성되는 시스템 테이블스페이스를 위한 데이터 파일의 최초 크기 100M SYS_DATA_FILE_MAX_SIZE 시스템 테이블스페이스의 데이터 파 일의 최대 크기 2G SYS_DATA_FILE_NEXT_SIZE 시스템 테이블스페이스의 데이터 파 일이 자동 확장될 때의 확장 크기 1M 데이터베이스 생성 43 프로퍼티 이름 설명 기본값 SYS_TEMP_TBS_EXTENT_SIZE 임시 테이블스페이스의 익스텐트 한 개의 크기 256K SYS_TEMP_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 임시 테이블스페이스를 위한 데 이터 파일의 최초 크기 100M SYS_TEMP_FILE_MAX_SIZE 임시 테이블스페이스의 데이터 파일 의 최대 크기 2G SYS_TEMP_FILE_NEXT_SIZE 임시 테이블스페이스의 데이터 파일 이 자동 확장될 때의 확장 크기 1M SYS_UNDO_TBS_EXTENT_SIZE 언두 테이블스페이스의 익스텐트 한 개의 크기 128K SYS_UNDO_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 언두 테이블스페이스를 위한 데 이터 파일의 최초 크기 100M SYS_UNDO_FILE_MAX_SIZE 언두 테이블스페이스의 데이터 파일 의 최대 크기 2G SYS_UNDO_FILE_NEXT_SIZE 언두 테이블스페이스의 데이터 파일 이 자동 확장될 때의 확장 크기 1M USER_DATA_TBS_EXTENT_SIZE 사용자 데이터 테이블스페이스의 익 스텐트 한 개의 크기 256K USER _DATA_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 사용자 테이블스페이스를 위한 데이터 파일의 최초 크기 100M USER_DATA_FILE_MAX_SIZE 사용자 데이터 테이블스페이스의 데 이터 파일의 최대 크기 2G USER _DATA_FILE_NEXT_SIZE 사용자 데이터 테이블스페이스의 데 이터 파일이 자동 확장될 때의 확장 크기 1M USER_TEMP_TBS_EXTENT_SIZE 사용자 임시 테이블스페이스의 익스 텐트 한 개의 크기 256K USER_TEMP_FILE_INIT_SIZE CREATE DATABASE 실행 시 생성 되는 사용자 임시 테이블스페이스의 데이터 파일의 최초 크기 100M USER_TEMP_FILE_MAX_SIZE 사용자 임시 테이블스페이스의 데이 터 파일의 최대 크기 2G USER_TEMP_FILE_NEXT_SIZE 사용자 임시 테이블스페이스의 데이 터 파일이 자동 확장될 때의 확장 크 기 1M ADD_EXTENT_NUM_FROM_TBS _TO_SEG 세그먼트가 확장될 때 새로 할당되는 익스텐트의 개수 1 ADD_EXTENT_NUM_FROM_SYS테이블스페이스가 확장될 때 새로 할4 44 Administrator’s Manual 프로퍼티 이름 설명 기본값 TEM_TO_TBS 당되는 익스텐트의 개수 CHECKSUM_METHOD 페이지의 상태가 올바른지 체크하는 방법의 종류 1 프로퍼티에 대한 보다 자세한 내용은 General Reference를 참조하기 바란다. 4. 알티베이스 구동 및 종료 데이터베이스를 생성 후 서비스를 제공하기 위해서는 서버를 서비스 단계까지 구동하여야 한다. 이 장에서는 데이터베이스 구동과 종료 시에 참고할 사항들을 설명하고 있다. 46 Administrator’s Manual 알티베이스의 구동 알티베이스 서버를 구동하는 방법은 두 가지가 있다. 데이터베이스 관리자가 sys 계정으로 서버에 로그인 시 - sysdba 관리자로 서버에 접속하여 서버 구동 서버 스크립트 명령을 이용하여 서버 구동 알티베이스를 구동시키기 위해서는 데이터베이스 생성 시와 마찬가지로 우선 isql을 -sysdba 옵션으로 실행해야 한다. 다음은 iSQL을 -sysdba옵션으로 실행하는 것을 보여준다. $ isql -u sys -p manager -sysdba ---------------------------------------------- Altibase Client Query utility. Release Version 5.5.1.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. ---------------------------------------------- ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 iSQL(sysdba)> Note: STARTUP 명령어는 알티베이스 (isql 포함)를 설치한 유닉스 계정으로만 수행이 가능하다. 알티베이스를 구동하면, 알티베이스의 상태는 아래의 단계 순으로 전이한다. 1. PRE_PROCESS 2. PROCESS 3. CONTROL 4. META 5. SERVICE STARTUP 명령어는 아래의 단계 옵션과 함께 사용할 수 있다. STARTUP [PROCESS | CONTROL | META | SERVICE]; SERVICE 상태가 되어야 SYS사용자를 제외한 일반 사용자들이 데이터베이스에 접근할 수 있다. Note: 알티베이스의 상태는 다음 상태로 진행만 할 수 있으며, 이전 상태로 되돌아갈 수는 없다. SERVICE 상태로 전이시키는 예는 아래와 같다. iSQL> startup service; Trying Connect to Altibase..... Connected with Altibase. 알티베이스 구동 및 종료 47 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 Serial Bulk Loading . is 8192k: *..[SUCCESS] [SM] Recovery Phase - 3: Skipping Recovery Threads...[SUCCESS] Refining Disk Table [SUCCESS] [SM] Garbage Collection: ....................................... [SUCCESS] [SM] Rebuilding Indices [Total Count:61] ****************..................... .................................................... [SUCCESS] TRANSITION TO PHASE: SERVICE No IPC Initialize: Disabled --- STARTUP Process SUCCESS --- Command execute success. 구동의 각 단계에서 사용자가 할 수 있는 일은 다음과 같다. 단계 가능한 작업 PRE-PROCESS PROCESS 단계로 전이할 수 있다. PROCESS CREATE DATABASE구문으로 데이터베이스를 생성하거나 DROP DATABASE 구문으로 데이터베이스를 삭제할 수 있다. 제한된 개수의 성능 뷰들을 조회할 수 있다. 프로퍼티 값들을 변경시킬 수 있다. CONTROL 단계로 전이할 수 있다. CONTROL 미디어 복구 (Media Recovery)를 수행할 수 있다. META 단계로 전이할 수 있다. CONTROL 단계에서 불완전 복구를 한 경우 META 단계로 전이할 때 온라인 로그를 리셋(reset)해야 한다. META 메타 데이터 (Dictionary table)를 업그레이드할 수 있다. SERVICE 단계로 전이할 수 있다. SERVICE SYS사용자를 제외한 일반 사용자로부터 접속을 받을 수 있다. SHUTDOWN 48 Administrator’s Manual NORMAL/IMMEDIATE/ABORT 를 수행할 수 있다. 알티베이스 구동 및 종료 49 알티베이스의 종료 현재 구동중인 알티베이스 서버를 종료하려면 SHUTDOWN 구문을 사용한다. 아래의 옵션이 가능하다. SHUTDOWN [NORMAL | IMMEDIATE | ABORT]; SHUTDOWN NORMAL과 SHUTDOWN IMMEDIATE는 알티베이스가 SERVICE 상태일 때만 수행 가능하며, SHUTDOWN ABORT는 어떤 상태에서도 수행 가능하다. Note: SHUTDOWN 명령어는 알티베이스 (isql 포함)를 설치한 유닉스 계정으로만 수행이 가능하다. SHUTDOWN NORMAL 서버를 정상적으로 종료하는 방식이다. 서버는 모든 클라이언트들이 서버로부터 접속을 끊을 때까지 종료 작업을 대기한다. 서버 종료시 내부적으로 다음의 작업이 수행된다. 클라이언트-서버간 통신 세션을 감지하는 쓰레드의 종료 서비스 쓰레드의 종료 자료저장 관리자의 종료 마지막으로 알티베이스 서버 프로세스가 완전히 종료되기를 대기하는 일들을 수행함으로써 알티베이스 서버를 종료한다. 이 방식으로 알티베이스를 종료했을 때 다음과 같은 메시지가 출력된다. iSQL(sysdba)> shutdown normal; Ok..Shutdown Proceeding.... TRANSITION TO PHASE : Shutdown Altibase [RP] Finalization : PASS shutdown normal success. SHUTDOWN IMMEDIATE SHUTDOWN IMMEDIATE를 실행하면, 알티베이스 서버는 먼저 현재 연결된 세션들을 강제로 단절시킨 다음, 현재 실행 중이던 트랜잭션들을 철회(rollback) 시키고 알티베이스 서버를 종료한다. 이 방식으로 알티베이스를 종료했을 때 다음과 같은 메시지가 출력된다. iSQL(sysdba)> shutdown immediate 50 Administrator’s Manual O k . . Sh u t d o w n Pro c e e d i n g . . . . T R AN SI T I O N T O PH AS E : Sh u t d o w n A l t i b a s e [RP] Finalization : PASS shutdown immediate success. 서버 스크립트 명령을 이용하여 서버를 종료할 수도 있다. $ server stop ----------------------------------------------- Altibase Client Query utility. Release Version 5.5.1.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. ----------------------------------------------- ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 Alter success. Alter success. Alter success. Ok..Shutdown Proceeding.... TRANSITION TO PHASE : Shutdown Altibase [RP] Finalization : PASS shutdown immediate success. SHUTDOWN ABORT SHUTDOWN ABORT는 알티베이스 서버를 강제로 죽인다. 이 방법으로 알티베이스 서버를 종료하면, 데이터베이스가 완전하지 못한 상태가 되어 다음에 알티베이스 서버를 구동할 때 데이터베이스 복구 과정을 거쳐야 할 수도 있다. 이 방식으로 알티베이스를 종료했을 때 다음과 같은 메시지가 출력된다. iSQL(sysdba)> shutdown abort iSQL(sysdba)> 또는 서버 스크립트 명령을 이용할 수 있다. $ server kill -------------------------------------------------------- Altibase Client Query utility. Release Version 5.5.1.1 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved. 알티베이스 구동 및 종료 51 -------------------------------------------------------- ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20300 $ 5. 데이터베이스 객체 및 권한 이장에서는 알티베이스 데이터베이스 내의 객체 관리 및 권한 관리 방법에 대해서 설명한다. 54 Administrator’s Manual 데이터베이스 객체 개요 데이터베이스 객체는 특정 스키마에 속하여 관리되는 스키마 객체와 스키마와 관계없이 데이터베이스 전체에서 관리되는 비스키마 객체로 구분할 수 있다. 이 장에서는 스키마 객체와 비스키마 객체를 구분하고 각각에 포함되는 데이터베이스 객체에 대해 설명한다. 스키마 객체 스키마란 데이터 또는 객체들의 논리적 집합으로 한 데이터베이스 사용자는 하나의 스키마를 소유하고 SQL문에 의해 관리된다. 이러한 스키마에 포함되는 객체를 스키마 객체라고 하고 알티베이스는 다음과 같은 스키마 객체를 제공한다. 테이블 (Table) 테이블은 가장 기본적인 데이터 저장 단위로써 테이블은 칼럼들로 구성된 레코드들의 집합이다. 알티베이스 테이블은 데이터의 저장 공간에 따라 메모리 테이블과 디스크 테이블로 구별되고, 생성자에 따라 시스템이 생성하고 관리하는 시스템 테이블과 사용자가 생성하는 사용자 테이블로 구별된다. 또한 이중화 대상 테이블의 경우 테이블 관리가 특별하며 대용량 테이블의 경우에도 주의를 요하는 사항들이 있다. 이에 대해서는 테이블 관리에서 자세히 설명한다. 제약조건 (Constraint) 제약 조건이란 테이블의 데이터 삽입 또는 변경 시 데이터의 일관성을 유지할 수 있도록 부과한 조건이다. 제약조건의 대상에 따라 칼럼 제약조건과 테이블 제약조건으로 구별할 수 있고, 제약 사항에 따라 다음과 같은 종류의 제약조건을 제공한다. NOT NULL / NULL 제약조건 유일 키 (unique key) 제약조건 주 키 (primary key) 제약조건 외래 키 (foreign key) 제약조건 TIMESTAMP 제약조건 인덱스 (Index) 데이터베이스 객체 및 권한 55 인덱스는 특정 테이블에 선택적으로 생성하여 그 테이블 내 레코드들에 대한 빠른 접근이 가능하도록 한다. 즉, DML문의 처리 성능을 향상시킬 수 있다. 뷰 (View) 뷰는 실제 데이터 자체는 포함하지 않고, 하나 이상의 테이블 또는 뷰를 기반으로 한 논리적 테이블 (logical table)이다. 알티베이스는 변경가능 뷰 (Updatable view)와 머티어리얼라이즈 뷰 (materialized view)는 제공하지 않는다. 시퀀스 (Sequence) 알티베이스는 유일 키를 생성하기 위한 키생성자인 시퀀스를 제공한다. 시노님 (Synonym) 테이블, 시퀀스, 뷰, 저장 프로시저 및 저장 함수에 대한 별칭 (alias)을 부여하여 객체 사용에 대한 투명성을 보장할 수 있는 시노님을 제공한다. 저장 프로시저 및 저장 함수 (Stored Procedure or Function) 저장 프로시저 (Stored Prodedure)란 SQL문들과 흐름 제어문, 할당문, 오류 처리 루틴 등으로 구성된 데이터베이스 객체이다. 이를 이용해서 전체 업무 절차를 프로그래밍하여 하나의 모듈로 만든 후 데이터베이스에 영구적으로 저장해 두고, 모듈 이름만을 호출하여 전체 업무 절차를 서버에서 한번에 수행하도록 하는 데이터베이스 객체이다. 하나의 리턴 값을 가지지 않느냐와 가지느냐에 따라 저장 프로시저와 저장 함수로 구별된다. 데이터베이스 트리거 (Database Trigger) 트리거란 테이블에 데이터가 삽입, 삭제, 또는 갱신될 때 시스템에 의해 작동되어 특정 작업 절차를 자동으로 수행할 수 있도록 하는 저장 프로시저의 한 종류이다. 사용자는 테이블에 대해 제약조건과 트리거를 정의하여 데이터의 일관성을 유지할 수 있다. 데이터베이스 링크 (Database Link) 데이터베이스 링크는 지역적으로 분리되어 있으나 네트워크로 연결된 데이터 서버들을 연동하여 그 데이터들을 통합해서 하나의 56 Administrator’s Manual 결과를 생성할 수 있게 한다. 이에 대해서는 Database Link User’s Manual에 더 자세히 기술되어 있다. 비스키마 객체 특정 스키마에 소속되지 않고 전체 데이터베이스 수준에서 관리되는 객체를 비스키마 객체라고 한다. 알티베이스는 다음과 같은 비스키마 객체를 제공한다. 디렉터리 (Directory) 저장프로시저의 파일 제어 기능은 운영 체제의 텍스트 파일에 대한 읽기 및 쓰기 기능을 제공한다. 이 기능을 이용하여 사용자는 저장프로시저 실행에 대한 별도의 메시지 등을 파일에 남길 수도 있으며, 파일로 결과를 보고하거나 파일로부터 데이터를 읽어와 테이블에 삽입하는 등 다양한 작업을 수행할 수 있다. 디렉터리 객체는 이러한 저장프로시저에서 접근하는 파일들이 저장되어 있는 디렉터리에 대한 정보를 관리하는데 사용된다. 디렉터리 객체에 대한 자세한 기능은 SQL Reference를 참고한다. 저장프로시저 내에서의 파일 제어 방법은 Stored Procedures Manual을 참고한다. 이중화 (Replication) 이중화는 시스템이 자동으로 한 지역서버에서 원격 서버로 데이터를 전송해 다른 서버들간의 테이블 데이터를 동일하게 유지해 줄 수 있도록 하는 객체이다. 이중화 관리에 대해서는 Replication Manual을 참조한다. 테이블스페이스 (Tablespace) 테이블스페이스는 가장 큰 논리적 데이터 저장 단위로 데이터베이스는 여러 개의 테이블스페이스로 나뉘어져 관리된다. 테이블스페이스는 저장공간을 기준으로 크게 메모리 테이블스페이스와 디스크 테이블스페이스로 구분된다. 각 데이터베이스는 시스템 테이블스페이스를 가지는데, 이는 데이터베이스 생성시에 자동으로 만들어지며 사용자에 의해 삭제되지 않는다. 또 사용자는 필요에 따라 사용자 테이블스페이스를 자유롭게 생성하거나 삭제할 수 있다. 데이터베이스 객체 및 권한 57 테이블스페이스 관리에 대한 자세한 내용은 “5장 테이블스페이스 관리”를 참조한다. 사용자 (User) 사용자 계정은 알티베이스 접속을 위해 필요하며, 스키마의 소유자이기도 하다. 사용자는 시스템에 의해 생성되며, 전체 시스템 관리자인 시스템 사용자와 일반 사용자로 구분된다. 일반 사용자의 경우 데이터베이스에 접근하여 데이터를 조작하기 위해서는 적절한 권한이 필요한다. 58 Administrator’s Manual 테이블 테이블은 가장 기본적인 데이터 저장 단위이다. 테이블은 칼럼들로 구성되며 레코드들을 포함한다. 이 절에서는 테이블과 관련된 용어를 정의하고 테이블 관리 개념과 방법들에 대해 설명한다. 메모리 테이블과 디스크 테이블 테이블의 저장 공간에 따라 메모리 테이블과 디스크 테이블로 분류된다. 테이블 생성 시 그 테이블이 속한 테이블스페이스가 메모리 테이블스페이스인지 디스크 테이블스페이스인지에 따라서 메모리 테이블 또는 디스크 테이블이 된다. 시스템 테이블과 사용자 테이블 또한 테이블은 시스템이 내부적으로 생성하고 관리하는 시스템 테이블과 사용자에 의해 생성되고 관리되는 사용자 테이블로 분류된다. 데이터 딕셔너리로 알려진 시스템 테이블은, 데이터베이스 객체 정보를 저장하는 메타 테이블과 시스템 프로세스 정보를 저장하는 프로세스 테이블로 분류된다. 프로세스 테이블은 다시 고정 테이블 (fixed table)과 성능 뷰 (performance view)로 분류된다. 이에 대해서는 “3장 데이터 딕셔너리”를 참고한다. 대용량 메모리 테이블 대용량 메모리 테이블에 대해 SQL문 수행 시 다음과 같은 주의를 요한다. 대용량 메모리 테이블에 DDL 수행하기 대용량 테이블에 DDL 문을 수행하고자 하는 경우, 그 테이블에 ADD COLUMN 또는 DROP COLUMN을 직접 수행하는 것 보다 iLoader 유틸리티를 이용해서 데이터를 다운로드 받고 그 테이블은 삭제하고 새로운 스키마로 그 테이블을 재 생성한 후에 다운로드 받은 데이터를 iLoader 유틸리티를 이용해서 업로드하는 방식을 권장한다. 데이터베이스 객체 및 권한 59 대용량 메모리 테이블에 DML 수행하기 데이터 크기가 크지 않은 테이블에 대해 DML을 수행하는 것은 운영자가 잘못된 데이터 조작을 하지 않는 한 알티베이스의 성능이나 운용 상에 있어서 크게 문제를 발생시키지 않는다. 그러나 하나의 UPDATE 또는 DELETE 문 수행이 아주 많은 수의 레코드에 영향을 미친다면, 그 DML을 수행하는 트랜잭션은 오랜 시간 동안 진행 중인 상태로 있을 수 있다. 이처럼 오랜 시간 동안 진행 중인 트랜잭션 (long-duration transaction)이 존재하는 경우 알티베이스를 운용함에 있어 다음과 같은 심각한 문제를 야기할 수 있다. 테이블에 대한 배타적 접근 트랜잭션의 수행 시간이 길어지면 그 트랜잭션이 획득하고 있는 잠금 (lock) 때문에 그 테이블에 접근하고자 하는 다른 트랜잭션들은 모두 수행을 멈추게 된다. 또한 변경되는 레코드들의 전체 양이 LOCK_ESCALATION_MEMORY_SIZE 프로퍼티에 지정한 값 이상이 되면 lock escalation이 발생하므로, 검색만 하는 트랜잭션이라 하더라도 그 테이블에 대해 접근할 수 없는 경우가 발생할 수도 있다. 알티베이스 메모리 사용량 증가 알티베이스에서 사용되는 모든 레코드 (버전)에는 garbage collector가 삭제해야 할 레코드들을 구분하기 위해 SCN (System Commit Number)이 사용된다. 커밋되지 않은 트랜잭션이 사용하고 있는 SCN보다 작은 SCN을 가지는 레코드에 대해서만 garbage collector는 삭제 작업을 수행한다. 그러므로, 장기간 수행 중인 트랜잭션이 존재하면 garbage collector는 자신이 처리해야 할 레코드가 없는 것으로 간주하고 레코드 삭제 작업을 수행하지 않는다. 따라서, bulk update/delete를 장기간 수행하는 트랜잭션이 존재하는 경우 garbage collector의 동작이 멈추게 되어 불필요한 버전이 계속 쌓이는 현상이 발생하며 이에 따라 데이터베이스의 크기가 증가하게 되며 알티베이스 메모리 사용량이 증가하게 된다. 로그 파일의 축적 트랜잭션이 생성하는 로그 파일들은 이중화 또는 재시작 복구를 위해 필요한 로그들을 제외하고는 체크포인트 수행시 디스크에서 삭제된다. 재시작 복구에 필요한 로그 파일은 체크포인트 검사 시 수행 중이던 트랜잭션들이 생성한 로그 파일들 중 가장 오래된 로그 60 Administrator’s Manual 파일을 의미한다. 따라서, 장기간 수행 중인 트랜잭션이 존재하면 체크포인트가 발생하더라도 재시작 복구를 위해 로그 파일들은 계속 지워지지 않기 때문에 로그 파일이 저장되는 파일 시스템에 더 이상 로그를 저장하지 못하는 상태가 될 수 있다. 페이지 리스트 다중화 메모리 테이블의 경우 로그파일그룹 (Log File Group) 기능을 활성화하면 테이블에서 사용하는 페이지 리스트 역시 LFG와 같은 개수로 다중화 된다. 로그파일그룹 기능에 대한 상세한 정보는 이 매뉴얼 “15장 알티베이스 튜닝”의 해당 내용을 참조한다. 이중화된 테이블 알티베이스에서 이중화 대상인 테이블에 대하여 DDL 문의 실행이 가능하지만, 먼저 반드시 다음과 같이 프로퍼티를 설정해야 한다. REPLICATION_DDL_ENABLE 프로퍼티를 1로 설정한다. ALTER SESSION SET REPLICATION으로 설정할 수 있는 REPLICATION 세션 프로퍼티를 NONE 이외의 값으로 설정한다. 이중화 테이블 관리에 대한 자세한 내용은 Replication Manual을 참조한다. 생성 테이블은 CREATE TABLE문을 사용하여 생성할 수 있다. 테이블 생성 시에는 칼럼 정의, 제약조건, 테이블이 저장될 테이블스페이스, 테이블에 삽입할 수 있는 최대 레코드 수, 테이블을 위한 저장 관리자 내 페이지에 대한 공간 활용율 등을 명시할 수 있다. 예제 CREATE TABLE book( 데이터베이스 객체 및 권한 61 isbn CHAR(10) CONSTRAINT const1 PRIMARY KEY SET PERSISTENT = ON, title VARCHAR(50), author VARCHAR(30), edition INTEGER DEFAULT 1, publishingyear INTEGER, price NUMBER(10,2), pubcode CHAR(4)) MAXROWS 2 TABLESPACE user_data; CREATE TABLE dept_c002 AS SELECT * FROM employees WHERE dno = 4002; 메모리 테이블에서 칼럼 정의 시 주의 사항 VARCHAR 데이터 타입의 경우 FIXED 또는 VARIABLE 속성을 사용자가 지정할 수 있다. 사용자가 이 속성을 지정하지 않았다면, 데이터의 길이가 MEMORY_VARIABLE_COLUMN_IN_ROW_SIZ 프로퍼티에 지정한 값 이하인 데이터의 경우 FIXED영역에 저장되고 그렇지 않을 경우 VARIABLE 영역에 저장된다. FIXED영역에 저장될 경우에는 비록 데이터 타입이 VARCHAR일지라도 CHAR 데이터 타입처럼 저장공간을 해당 길이만큼 미리 할당받으며, VARIABLE영역에 저장될 경우에는 데이터 길이만큼만 저장공간에 할당된다. VARCHAR 데이터 타입의 데이터 비교 방식은 FIXED 또는 VARIABLE 속성에 관계 없이 non-blank padding 비교 방식을 따른다. 다음 그림은 FIXED 또는 VARIABLE로 선언된 칼럼이 레코드 내에서 저장되는 방식을 보여준다. FIXED일 경우에는 비록 데이터 타입이 VARCHAR일지라도 CHAR 데이터 타입처럼 메모리상에 미리 해당 길이만큼 할당받으며 VARIABLE일 경우에는 데이터 길이만큼만 메모리 상에 할당된다. 62 Administrator’s Manual CREATE TABLE item ( name varchar(20) FIXED, description varchar(1000) VARIABLE ); Record Headernamedescription real data of description 20 13 16 INSERT INTO item VALUES('msjung', 'variable test'); [그림 4-1] VARCHAR 칼럼 구조 테이블 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칼럼에 데이터 입력 시 서버는 실제 데이터를 저장할 수 있는 최적의 크기를 갖는 슬롯을 선택하여 데이터를 저장한다. 데이터베이스 객체 및 권한 63 기존 칼럼 삭제 칼럼 기본 값 칼럼 이름 제약 조건 추가 제약 조건 삭제 메모리 테이블 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; ALTER TABLE 문에 대한 자세한 설명은 SQL Reference를 참고한다. 삭제 테이블은 DROP TABLE문을 사용하여 삭제할 수 있다. 예제 DROP TABLE employee; TRUNCATE 테이블의 레코드는 DELETE문을 사용해 삭제할 수도 있지만 TRUNCATE TABLE문을 이용해 삭제할 수도 있다. DELETE문은 내부적으로 레코드를 건건이 삭제하는 것인 반면, TRUNCATE TABLE문은 내부적으로 DROP TABLE문을 수행하고 같은 정의의 테이블을 재생성하는 DDL문이다. 따라서 TRUNCATE TABLE문을 수행하면 그 테이블에 대해 테이블 수준의 잠금 (lock)이 잡히며, TRUNCATE TABLE문이 64 Administrator’s Manual 성공적으로 수행된 이후에는 ROLLBACK문을 사용해도 삭제된 데이터를 복구할 수 없다. 데이터 조작 테이블의 레코드들은 다음의 DML문을 사용하여 조작할 수 있다. INSERT DELETE UPDATE SELECT 위에서 언급한 바와 같이 알티베이스 운용 중에 대용량의 데이터에 대해 bulk UPDATE/DELETE를 수행하는 것은 위험하기 때문에, ODBC 혹은 전처리기 (APRE C/C++)를 이용하여 응용프로그램 작성 시 각 레코드에 대해 UPDATE/DELETE 작업 수행 후 커밋하는 것이 바람직하다. 다음은 bulk UPDATE/DELETE을 피하고 레코드 각각에 대해 UPDATE작업을 수행하는 C/C++ Precompiler 프로그램의 예이다. (a) isql 상에서 bulk-update 수행 iSQL >update t1 set col1=2 where col1 > 1000; (b) APRE C/C++를 이용하여 레코드별 update 수행 ....... EXEC SQL DECLARE update_cursor CURSOR FOR select col1 from t1 where col1 > 1000; EXEC SQL OPEN update_cursor; while (1) { EXEC SQL FETCH update_cursor INTO :t1_col; if (sqlca.sqlcode == SQL_NO_DATA) break; EXEC SQL update t1 set col1=2 where col1=:t1_col; } ....... 관련 SQL문 테이블에 대해 다음과 같은 SQL문이 지원된다. 이에 대한 자세한 설명은 SQL Reference를 참조한다. 데이터베이스 객체 및 권한 65 CREATE TABLE ALTER TABLE RENAME TABLE TRUNCATE TABLE LOCK TABLE INSERT DELETE UPDATE SELECT 66 Administrator’s Manual 큐 알티베이스 메시지 큐잉 기능은 데이터베이스와 사용자 프로그램간의 비동기 데이터 통신을 지원한다. 이 때 사용되는 큐 테이블은 데이터베이스 오브젝트의 하나로써 다른 데이터베이스 테이블과 마찬가지로 DDL과 DML구문으로 제어할 수 있다. 생성 사용자가 CREATE QUEUE 문장을 이용해서 큐를 생성하면, 데이터베이스는 사용자가 명시한 이름의 테이블을 생성한다. 이를 큐 테이블이라고 부른다. 큐 테이블은 다음과 같은 구조를 가진다. Column name Type Length Default Description MSGID BIGINT 8 - 메시지 식별자 로 알티베이스 에 의해 자동으 로 부여됨 MESSAGE VARCHA R Message length - 메시지 텍스트 CORRID INTEGE R 4 0 사용자가 지정 한 메시지 식별 자 ENQUEUE_TIME DATE 8 SYSDAT E 메시지가 큐에 들어온 시간 큐 테이블의 이름이나 칼럼 명은 사용자가 임의로 변경할 수 없으며, MSGID 칼럼에는 자동으로 주요 키 (Primary Key)가 생성된다. 알티베이스는 유일한 값의 MSGID를 생성하기 내부적으로 [QUEUE이름]_NEXT_MSG_ID라는 이름의 시퀀스를 생성한다. 사용자가 해당 시퀀스에 대한 정보를 조회하려면 SYS_TABLES_ 메타 테이블을 사용하면 된다. 시퀀스는 큐 테이블이 삭제될 때까지 유지되어야 하기 때문에 DROP SEQUENCE 문장으로 삭제되지 않는다. 큐 테이블은 SYS_TABLES_ 메타 테이블에 TABLE_TYPE이 ‘Q’로 저장된다. 사용자는 필요에 따라서 CREATE INDEX 문장을 이용해서 큐 테이블에 인덱스를 생성할 수 있다. 예제 CREATE QUEUE Q1(40); 데이터베이스 객체 및 권한 67 변경 CREATE QUEUE 문장으로 생성된 큐 테이블은 ALTER TABLE 등의 문장으로 구조를 변경할 수 없다. 오직 DROP QUEUE 문장으로 삭제될 수만 있다. 단, 사용자는 ENQUEUE/DEQUEUE, DELETE, SELECT 등의 문장으로 데이터 조작은 가능하다. 삭제 큐 테이블은 DROP QUEUE 문을 사용하여 삭제할 수 있다. 예제 DROP QUEUE Q1; 데이터 삭제 큐에 적재된 메시지만 모두 삭제하고자 하는 경우에는 TRUNCATE TABLE 문장을 이용할 수 있다. 예제 TRUNCATE TABLE Q1; 데이터 조작 큐 테이블의 레코드들은 다음과 같은 DML문을 사용하여 조작될 수 있다. ENQUEUE DEQUEUE DELETE SELECT 관련 SQL문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL Reference 을 참조한다. 68 Administrator’s Manual CREATE QUEUE DROP QUEUE ENQUEUE DEQUEUE 데이터베이스 객체 및 권한 69 제약조건 제약 조건은 테이블의 데이터 삽입 또는 변경에 제한을 두는 것이다. 이 절에서는 제약조건의 종류와 데이터 일관성을 유지할 수 있도록 제약조건을 관리하는 방법에 대해 설명한다. 종류 알티베이스는 다음과 같은 종류의 제약조건을 지원한다. NOT NULL/NULL NOT NULL은 칼럼에 NULL을 삽입되는 것을 막는 제약조건이다. 칼럼 단위로 정의할 수 있다. NULL을 명시하면 NULL값을 허용한다. 칼럼에 대해 NOT NULL 을 명시하지 않으면 기본적으로 NULL값을 허용한다. UNIQUE 하나 이상의 칼럼에 대해 정의할 수 있는 제약조건으로 칼럼 또는 칼럼의 조합에 대해 중복 값을 삽입되는 것을 방지한다. 유일 키 제약조건을 정의하면 내부적으로 유일 키 인덱스가 생성된다. PRIMARY KEY 프라이머리 키 제약조건은 유일 키 제약조건에 NOT NULL 제약조건까지 합쳐진 제약조건이다. 하나 이상의 칼럼에 대해 프라이머리 키 제약조건을 정의할 수 있다. 프라이머리 키가 생성될 때 내부적으로 유일 키 인덱스가 생성된다. 프라이머리 키에 포함되는 어떤 칼럼에도 NULL값을 삽입할 수 없다. FOREIGN KEY 참조 무결성 제약조건 (referential integrity constraint)으로 참조 관계에 있는 테이블 간의 데이터 일관성을 유지할 수 있도록 해 주는 제약조건이다. TIMESTAMP 칼럼의 값에 레코드의 삽입 또는 갱신 시 시스템 시간 값을 설정하는 제약조건이다. 주로 이중화 대상 테이블의 한 칼럼에 대해 이 제약조건을 정의한다. 70 Administrator’s Manual 칼럼 제약조건과 테이블 제약조건 칼럼 정의 시 하나의 칼럼에 대해 정의한 제약조건을 칼럼 제약조건이라 하고 여러 개의 칼럼들에 대해 하나의 제약조건을 테이블 정의 하단 부분에 정의하는 것을 테이블 제약조건이라고 한다. 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문을 이용해 정의된 제약조건을 삭제할 수 있다. 데이터베이스 객체 및 권한 71 예제 ALTER TABLE book DROP UNIQUE(bno); 관련 SQL문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL Reference 을 참조한다. CREATE TABLE ALTER TABLE 72 Administrator’s Manual 인덱스 인덱스는 테이블 내 레코드들에 대한 빠른 접근이 가능하도록 한다. 이 절에서는 인덱스의 알티베이스가 지원하는 인덱스의 종류와 속성, 인덱스 객체의 관리 및 활용 방법에 대해 설명한다. 인덱스 종류 알티베이스는 BTREE, RTREE 의 두 가지 인덱스를 지원한다. RTREE 는 다차원 인덱스로서 공간 질의 시 이용된다. B-tree 인덱스 공간 데이터 타입인 GEOMETRY 타입의 칼럼을 제외한 모든 타입의 칼럼에는 B-Tree 인덱스가 생성된다. B-Tree는 전통적으로 DBMS에서 사용해온 인덱스 구조로써 현재까지 많은 연구를 통해 여러가지 변이를 가지는데, 알티베이스는 이중 B+-Tree 형태의 인덱스를 지원한다. B+-Tree는 인덱스의 최하위 레벨에 존재하는 리프 노드 (Leaf Node)들과, 최상위 레벨에 존재하는 루트 노드 (Root Node), 그리고 리프와 루트의 사이에 존재하는 인터널 노드 (Internal Node)들로 구성된다. 키 값들은 모두 리프 노드에만 존재하며, 루트와 인터널 노드에는 좌측 자식 노드와 우측 자식 노드의 중간 값인 세퍼레이터 (Separator) 키들을 가진다. R-tree 인덱스 공간 데이터 타입인 GEOMETRY 칼럼에는 R-Tree 인덱스가 생성된다. R-Tree인덱스를 사용하여 대상 객체 검색시 알티베이스는 다음의 과정을 수행한다. 1. 각 공간 객체를 감싸는 최소 사각형인 MBR (Minimum Bounding Rectagle)을 이용하여 일차로 조건 필터링 (Filtering)을 수행한다. 2. 이 결과로 남은 객체에 대해 정확한 인덱스 검색 조건을 체크하 는 리파인먼트 (Refinement)를 수행한다. R-Tree의 삽입, 삭제, 노드 스플릿 (Split), 노드 머지 (Merge) 알고리즘은 MBR을 기준으로 한다는 점만 제외하고는 B-Tree와 유사하다. 데이터베이스 객체 및 권한 73 인덱스 속성 인덱스를 생성할 때 키 칼럼 구성 방법, 키 칼럼의 속성 등에 의해 해당 인덱스는 아래와 같은 인덱스 속성을 가진다. 메모리 테이블의 인덱스는 시스템 시작 시 부트 업 시간을 단축하기 위해 영구 인덱스(Persistent Index) 속성을 지원한다. 유일 키 인덱스 (Unique Index) 인덱스 칼럼에 대해 중복 값을 허용하지 않는 인덱스이다. 유일 키 (Unique Key)와 프라이머리 키 (Primary Key) 유일 키와 프라이머리 키 모두 중복 값을 허용하지 않는 것은 공통이다. 하지만 널 (NULL)의 허용 여부에 따라 유일 키와 프라이머리 키로 구별된다. 프라이머리 키의 경우 널 (NULL)을 허용하지 않는다. 중복 키 인덱스 (Non-unique Index) 인덱스 칼럼에 대해 중복 값을 허용하는 인덱스이다. 유일 키 옵션을 지정하지 않으면 기본적으로 중복 값을 허용하는 인덱스로 생성된다. 단일 키 인덱스 (Non-composite Index) 인덱스 대상 칼럼이 하나인 인덱스이다. 복합 키 인덱스 (Composite Index) 여러 개의 칼럼들의 조합에 대해 하나의 인덱스를 생성하는 경우 복합 키 인덱스라고 한다. 영구 저장 인덱스 (Persistent Index) 메모리 테이블 인덱스는 영구적 (Persistent) 데이터베이스 영역을 사용하지 않고 임시 메모리 영역에 존재한다. 그래서 모든 메모리 테이블 인덱스는 알티베이스를 시작할 때마다 다시 만들어진다. 만일 데이터베이스의 크기가 매우 크면 인덱스의 재생성 시간도 이에 비례하여 오래 걸린다. 이를 방지하려면 영구 저장 인덱스 속성을 부여하여 시스템이 정상 종료될 때 임시 메모리 영역에 존재하는 인덱스를 파일에 영구 저장 인덱스로 저장되도록 한다. 그 후에, 시스템이 다시 시작되면 인덱스는 이 파일로부터 복원되어 부트 업 시간을 단축시킬 것이다. 74 Administrator’s Manual 그러나 이 경우 알티베이스는 인덱스를 키 포인터 기반으로 생성하게 되어, 키 값 기반으로 인덱스를 생성하는 것보다 더 시간이 오래 걸릴 수 있다. 게다가 인덱스 저장 파일을 위한 디스크 공간이 추가로 더 필요하다. 그러므로 영구 저장 인덱스는 특히 다음의 경우에 사용됨을 잘 알고 있어야 한다. 인덱스 키 값의 크기가 너무 커서 키 값 기반으로 인덱스를 생성함에 따른 성능 이점이 없는 경우 빠른 구동 시간이 특히 요구되는 경우 비영구 저장 인덱스 (Non-persistent Index) 알티베이스 정상 종료 시에 파일로 저장되지 않는 일반 인덱스이다. 인덱스 생성시 PERSISTENT=ON 옵션을 주지 않으면, 기본적으로 비영구 저장 인덱스로 생성된다. 인덱스 관리 인덱스는 테이블의 레코드들에 대한 접근을 빠르게 하기 위해서 사용된다. 인덱스는 해당 테이블로부터 물리적, 논리적으로 독립적인 객체이기 때문에 테이블에 관계없이 생성, 삭제 또는 수정할 수 있다. 테이블의 레코드들이 수정되면 해당 인덱스들도 수정이 된다. 그러므로 필요한 경우에만 인덱스를 생성하고, 테이블에 대한 접근 유형에 따라 인덱스를 변경하거나 삭제하여 최적화된 인덱스를 관리한다. 인덱스 생성 인덱스는 테이블에 존재하는 하나 이상의 칼럼에 대해 생성된다. 인덱스는 테이블 제약조건을 통해서 자동으로 생성될 수도 있고, CREATE INDEX문을 사용해 사용자가 명시적으로 생성할 수도 있다. 예제 테이블 제약조건에 의한 인덱스 생성 CREATE TABLE TB1 (C1 INTEGER PRIMARY KEY, C2 INTEGER UNIQUE); 테이블 제약조건 변경에 의한 인덱스 생성 ALTER TABLE TB1 ADD PRIMARY KEY (C1); ALTER TABLE TB1 ADD UNIQUE (C2); 인덱스 생성시 칼럼 정렬 지정 CREATE INDEX TB1_IDX1 ON TB1 (C1 ASC, C2 DESC); 데이터베이스 객체 및 권한 75 인덱스 타입 지정 CREATE INDEX TB1_IDX1 ON TB1 (C1) INDEXTYPE IS BTREE ; UNIQUE 인덱스 생성 CREATE UNIQUE INDEX TB1_IDX ON TB1 (C1) ; PERSISTENT 인덱스 생성 CREATE INDEX TB1_IDX1 ON TB1(C1) SET PERSISTENT=ON; 디스크 B-tree 인덱스의 생성 옵션 (NOLOGGING, NOFORCE) 디스크 B-tree 인덱스 생성 시 인덱스 생성과 관련된 로그를 기록하도록 하여 시스템 오류 발생시 복구에 사용할 수 있다. 디스크 B-tree 인덱스를 생성할 때 기록되는 로그 양과 인덱스 생성 소요 시간을 단축하려면, NOLOGGING 옵션을 사용하면 된다. NOLOGGING 옵션을 사용하면 인덱스가 구축된 후 인덱스의 모든 페이지를 디스크에 즉시 반영해서 인덱스 생성 후에 시스템 고장이 발생하더라도 인덱스의 일관성을 보장할 수 있게 된다. 그러나 NOLOGGING 옵션으로 인덱스를 생성할 때 인덱스 페이지들을 즉시 디스크에 반영하지 않는 NOFORCE 옵션을 함께 명시하면, 인덱스를 구축하는 데 필요한 시간이 감소됨에도 불구하고 시스템이나 미디어 고장이 발생했을 경우 인덱스 일관성이 깨질수 있다. NOLOGGING과 NOFORCE 옵션을 모두 지정해서 생성된 인덱스의 영속성을 보장하기 위해서는 수동으로 미디어 백업을 수행해야 한다. 인덱스 생성시간 일관성 및 영속성 LOGGING 인덱스 생성 시간 + 로깅 시간 시스템 고장 및 미디어 고장 시 복구가능 NOLOGGING FORCE 인덱스 생성 시간 + 인덱스 페이지를 디 스크에 기록하는 시 간 시스템 고장 시 복구 가능하 지만, 미디어 고장 시 일관성 이 깨어질 수 있음 NOLOGGING NOFORCE 인덱스 생성 시간 시스템 고장 및 미디어 고장 시 일관성이 깨어질 수 있음 예제 로깅을 하지 않고 인덱스를 생성하고 인덱스를 디스크에 반영 CREATE INDEX TB1_IDX1 ON TB1(C1) NOLOGGING; 또는 CREATE INDEX TB1_IDX1 ON TB1(C1) NOLOGGING FORCE; 76 Administrator’s Manual 로깅을 하지 않고 (NOLOGGING) 인덱스를 생성한 후 디스크에 반영하지 않음 (NOFORCE) CREATE INDEX TB1_IDX1 ON TB1(C1) NOLOGGING NOFORCE; 인덱스 변경 인덱스 활성화 여부, 인덱스의 영구 저장 여부 속성을 ALTER INDEX문을 사용하여 변경할 수 있다. 예제 ALTER INDEX EMP_IDX1 SET PERSISTENT = ON; 인덱스 삭제 인덱스의 삭제는 DROP INDEX문을 사용하여 명시적으로 삭제하거나 관련 제약조건을 삭제하여 묵시적으로 삭제될 수 있다. 예제 DROP INDEX emp_idx1; 인덱스 활용 상향식 인덱스 생성 알티베이스는 상향식으로 인덱스를 구축 (Bottom-Up Index Building)한다. 그러므로 데이터를 업로드한 후 인덱스를 생성하는 것이 효율적이다. 테이블에 인덱스가 생성되어 있는 상태에서 대량의 데이터를 삽입할 경우, 레코드가 삽입될 때마다 인덱스에도 반영되므로 성능이 느려진다. 디스크 인덱스의 일관성 NOLOGGING 옵션으로 생성된 디스크 테이블 인덱스의 경우 시스템 고장이나 미디어 고장 발생 시 인덱스의 일관성을 보장할 수 없는 경우가 발생한다. 이런 경우, 디스크 인덱스의 일관성을 V$DISK_BTREE_HEADER성능 뷰로 확인해야 한다. 만약 IS_CONSISTENT가 ‘F’인 인덱스가 존재한다면 해당 인덱스를 삭제하고 필요할 경우 재생성하여 사용해라. 관련 SQL문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL Reference 을 참조한다. CREATE TABLE 데이터베이스 객체 및 권한 77 ALTER TABLE CREATE INDEX ALTER INDEX DROP INDEX 78 Administrator’s Manual 뷰 뷰(View)란 실제 데이터 자체는 포함하지 않는, 하나 이상의 테이블 또는 뷰를 기반으로 한 논리적 테이블 (logical table)이다. 이 절에서는 뷰의 관리 방법에 대해 설명한다. 베이스 (base) 테이블과 뷰 베이스 테이블이란 뷰가 접근하여 데이터를 읽어 오는 객체 (테이블 또는 뷰)이다. 여러 개의 베이스 테이블이 하나의 뷰에 연관될 수 있다. 알티베이스는 읽기 전용 뷰만 지원한다. 변경 가능 뷰 (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문이 데이터베이스 객체 및 권한 79 발생하여 베이스 테이블의 정의가 변경되는 경우 관련 뷰들은 수행 불가능한 무효한 상태가 될 수 있다. 이런 경우 ALTER VIEW문을 COMPILE 옵션과 함께 사용해서 재컴파일하면 유효한 상태로 만들 수 있다. 예제 ALTER VIEW avg_sal COMPILE; 삭제 뷰는 DROP VIEW문을 사용하여 삭제할 수 있다. 예제 DROP VIEW avg_sal; 관련 SQL문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL Reference을 참조한다. CREATE VIEW ALTER VIEW DROP VIEW SELECT 80 Administrator’s Manual 시퀀스 관리 알티베이스는 연속된 숫자 값 생성자로서 시퀀스 (sequence) 객체를 제공한다. 다음 시퀀스 값은 일관된 성능 보장을 위해 캐싱할 수 있다. 시퀀스의 용도 시퀀스 생성자는 디스크 I/O 또는 트랜잭션 잠금의 오버헤드 없이 연속된 유일한 숫자를 생성하기 위해서 다중 사용자 환경에서 특히 유용하다. 예를 들어, 두 사용자가 동시에 orders 테이블에 새로운 레코드를 삽입한다고 가정하자. Order_id 칼럼에 입력될 유일한 주문 번호를 생성하기 위해 시퀀스를 사용하면, 어느 사용자도 다음의 가능한 주문 번호를 입력하기 위해서 다른 사용자를 기다리지 않아도 된다. 시퀀스는 각 사용자를 위해서 유일한 값을 자동으로 생성한다. 시퀀스 (sequence)는 DML 문으로 임의의 칼럼에 입력할 키 값을 생성하기 위해 주로 사용된다. [sequence 이름].NEXTVAL과 [sequence 이름].CURRVAL은 시퀀스에 접근하기 위해 사용된다. [sequence 이름].NEXTVAL은 시퀀스의 다음 값을 구하기 위해 사용된다. [sequence 이름].CURRVAL은 시퀀스의 현재 값을 구하기 위해 사용된다. 시퀀스 생성 후 그 시퀀스에 대해서 최초로 수행하는 연산이 [sequence 이름].CURRVA일 수 없다. [sequence 이름].CURRVA을 사용하기 위해서는 시퀀스 생성 이후 반드시 [sequence 이름].NEXTVAL을 먼저 사용해야 한다. 시퀀스의 다음 값에 접근할 때마다 시퀀스의 값은 내부적으로 명시한 증감분 (increment by)만큼 증가한다. 시퀀스의 증감분은 시퀀스 생성시 명시적으로 그 값이 주어지지 않는 경우 기본적으로 1이다. INSERT문에서의 시퀀스 사용 시퀀스를 사용하여 키를 생성하여 레코드를 삽입하는 예제이다. 예제 데이터베이스 객체 및 권한 81 create sequence seq1; insert into t1 values (seq1.nextval); 위에 예제에서, 시퀀스 생성시 초기값은 1이므로 t1테이블에는 1이 입력되며 시퀀스의 다음 값은 1 증가한 2가 될 것이다. 생성 CREATE SEQUENCE문을 사용하여 시퀀스를 생성한다. 시퀀스 생 성 구문에 사용되는 옵션들은 다음과 같다. START WITH 시퀀스의 시작 값 INCREMENT BY 시퀀스의 증감 분 MAXVALUE 시퀀스의 최대값 MINVALUE 시퀀스의 최소값 CYCLE 이 옵션은 시퀀스가 최대값 또는 최소값에 도달했을 때 다음 값을 계속 생성하는 것을 보장한다. 시퀀스는 오름차순 시퀀스인 경우는 최소값부터, 내림차순 시퀀스인 경우는 최대값부터 다시 순환된다. CACHE 알티베이스는 시퀀스 값을 보다 빠르게 액세스하기 위하여 미리 생성하여 메모리에 캐시한다. 이렇게 캐시되는 시퀀스 값의 개수는 CACHE 옵션으로 지정할 수 있다. 시퀀스 캐시는 시퀀스가 처음 참조될 때 채워지며 다음 시퀀스 값을 요청할 때마다 캐시된 시퀀스에서 반환된다. 캐시된 마지막 시퀀스 값을 사용한 이후에 발생한 시퀀스 요청에 대해서는 새로 시퀀스 값을 생성하여 메모리에 캐시하고 그 캐시의 첫번째 값을 반환한다. 시퀀스 생성시 기본 CACHE 값은 20이다. 예제 기본적인 시퀀스 생성하기 (1부터 시작하며 1씩 증가) CREATE SEQUENCE seq1; 짝수를 생성하고 0에서 100까지 순환하는 시퀀스 생성하기 CREATE SEQUENCE seq1 START WITH 0 INCREMENT BY 2 82 Administrator’s Manual M AXV AL U E 1 0 0 C YC L E ; 변경 ALTER SEQUENCE문을 사용하여 START WITH의 값을 제외한 모든 시퀀스 옵션을 변경할 수 있다. 예제 ALTER SEQUENCE seq1 INCREMENT BY 1 MINVALUE 0 MAXVALUE 100; 삭제 DROP SEQUENCE문을 사용하여 명시한 시퀀스를 삭제할 수 있다. 예제 DROP SEQUENCE seq1; 관련 SQL문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL Reference 을 참조한다. CREATE SEQUENCE ALTER SEQUENCE DROP SEQUENCE 데이터베이스 객체 및 권한 83 시노님 알티베이스는 테이블, 뷰, 시퀀스, 저장 프로시저 및 저장 함수에 대한 별칭 (alias)으로서 시노님의 사용을 지원한다. 시노님의 장점 다음과 같은 경우 데이터베이스 시노님을 사용하면 많은 이점이 있다. 특정 객체를 생성한 사용자와 객체의 원래 이름을 숨기고 싶은 경우 SQL문 사용의 단순화하고자 하는 경우 사용자 변경에 따른 응용프로그램의 변경 최소화하고자 하는 경우 생성 CREATE SYNONYM문을 사용하여 생성한다. 예제 테이블 dept의 별칭으로 my_dept 시노님을 생성한다. CREATE SYNONYM my_dept FOR dept; 삭제 DROP SYNONYM문을 사용하여 명시한 시노님을 삭제한다. 예제 시노님 my_dept를 삭제한다. DROP SYNONYM my_dept; 관련 SQL문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL 84 Administrator’s Manual Reference을 참조한다. CREATE SYNONYM DROP SYNONYM 데이터베이스 객체 및 권한 85 저장 프로시저 및 저장 함수 저장 프로시저 (Stored Prodedure)란 SQL문들과 흐름 제어문, 할당문, 오류 처리 루틴 등의 조합으로 전체 업무 절차를 하나의 모듈로 프로그래밍한 것이다. 이 모듈은 데이터베이스에 데이터베이스 객체로서 영구적으로 저장되어, 모듈 이름만을 호출하여 전체 업무 절차를 서버에서 한번에 수행할 수 있다. 이 절에서는 저장 프로시저 관리 방법에 대해 설명한다. 저장 프로시저와 저장 함수는 하나의 리턴값의 존재 유무에 따라 구별된다. 그 외의 모든 점은 동일하므로, 특별한 언급이 없는 한 모든 설명들은 공통 사항이다. 이 절에서는 저장 프로시저 관리하는 방법을 보여주는 간단한 예제를 제공한다. 저장 프로시저의 용어와 개념, 자세한 관리 방법에 대해서는 Stored Procedures Manual을 참조한다. 종류 저장 프로시저 (Stored Procedure) 저장 프로시터는 입력 인자, 출력 인자, 입출력 인자를 가지고 바디(body) 내에 정의된 조건에 따라 여러 SQL문을 한번에 수행하는 데이터베이스 객체이다. 리턴값을 가지지 않으며 출력 인자와 입출력 인자들을 통해 클라이언트에게 값을 전달한다. 하나의 리턴 값을 갖지 않기 때문에 다른 SQL문의 expression 내에 피연산자로 사용될 수 없다. 저장 함수 (Stored Function) 저장 함수는 하나의 리턴 값을 가지는 것을 제외하면 저장 프로시저와 동일하다. 저장 프로시저와 달리 하나의 리턴 값을 가지므로 시스템 제공 함수들처럼 다른 SQL문의 expression 내에 피연산자로 사용될 수 있다. 타입 세트 (Type Set) 저장 프로시저 내에서 사용되는 사용자 정의 타입들을 정의한 집합이다. 이는 주로 저장 프로시저끼리 파라미터 또는 리턴값으로 사용자 정의 타입을 주고받을 때 사용된다. 86 Administrator’s Manual 저장 프로시저 관련 SQL 구문 저장 프로시저의 SQL 구문 종류를 살펴보면, 다음과 같다. 종류 관련 문장 설명 생성 CREATE [OR REPLACE] PROCEDURE 문 새로운 저장 프로시저를 생성하거나 이 미 생성된 저장 프로시저의 재정의하는 SQL문이다. CREATE [OR REPLACE] FUNCTION 문 새로운 저장 함수를 생성하거나 이미 생 성된 저장 함수의 재정의하는 SQL문이 다. CREATE [OR REPLACE] TYPESET 문 타입 세트를 생성 또는 변경하는 SQL 문이다. 변경 ALTER PROCEDURE 문 저장 프로시저 생성 이후 관련 객체들의 정의가 변경된다면 현재 저장 프로시저 의 실행 계획은 최적화된 상태가 아닐 것이다. 이 경우 이를 재 컴파일하여 최 적화된 실행 계획을 재 생성하는 SQL 문이다. ALTER FUNCTION 문 저장 함수 생성 이후 관련 객체들의 정 의가 변경된다면 현재 저장 함수의 실행 계획은 최적화된 상태가 아닐 것이다. 이 경우 이를 재 컴파일하여 최적화된 실행 계획을 재 생성하는 SQL문이다. 삭제 DROP PROCEDURE 문 생성된 저장 프로시저를 삭제하는 SQL 문이다. DROP FUNCTION 문 생성된 저장 함수를 삭제하는 SQL문이 다. DROP TYPESET 문 생성된 타입 세트를 삭제하는 SQL문이 다. 실행 EXECUTE 문 저장 프로시저 또는 저장 함수를 실행하 는 SQL문이다. [함수 이름] SQL문 내에서 built-in function과 같 은 저장 함수를 호출한다. [표 5-1] 저장 프로시저문의 종류 생성 저장 프로시저는 CREATE PROCEDURE문을 사용하여 생성한다. 예제 CREATE PROCEDURE proc1 데이터베이스 객체 및 권한 87 (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 88 Administrator’s Manual . . . EN D ; / 저장 프로시저에서 참조되는 테이블, 시퀀스, 다른 저장 프로시저 또는 저장 함수의 정의가 변경되어 생성 시의 정의와 달라지면 현재 이 저장 프로시저의 실행 계획으로는 저장 프로시저를 실행할 수 없게 된다. 이 경우 현재 이 저장 프로시저는 무효한 (invalid) 상태라고 한다. 예를 들면 처음 저장 프로시저 생성 시 존재하던 인덱스가 삭제된 경우 이전 실행 계획은 인덱스를 통해 테이블에 접근하도록 계획되어 있으므로 이전 실행 계획을 사용해 테이블에 접근할 수 없게 된다. ALTER PROCEDURE문은 무효한 저장 프로시저를 재 컴파일하여 유효한 (valid) 상태의 실행 계획을 재 생성하는 데 사용된다. 예제 ALTER PROCEDURE proc1 COMPILE; 삭제 저장 프로시저는 DROP PROCEDURE문을 사용하여 삭제할 수 있다. 예제 DROP PROCEDURE proc1; 관련 SQL문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 Stored Procedures Manual을 참조한다. CREATE PROCEDURE CREATE FUNCTION CREATE TYPESET ALTER PROCEDURE ALTER FUNCTION DROP PROCEDURE 데이터베이스 객체 및 권한 89 DROP FUNCTION DROP TYPE SET EXECUTE [함수 이름] 90 Administrator’s Manual 트리거 트리거란 테이블에 데이터가 삽입, 삭제, 또는 갱신될 때 시스템에 의해 작동되어 특정 작업 절차를 자동으로 수행하는 저장 프로시저의 한 종류이다. 이 절에서는 트리거 관리 방법에 대해 설명한다. 트리거 구성 요소 다음의 트리거 구성요소는 트리거 작동 시점, 트리거 작동 여부, 트리거 작업을 결정한다. 트리거 이벤트 (trigger event) 이는 수행시 트리거 작동을 유발하는 SQL문이다. 트리거 조건 (trigger condition (WHEN 절)) 이는 트리거를 작동시키기 위해 만족시켜야 하는 SQL 조건이다. 트리거 액션 (trigger action) 이는 트리거 조건이 TRUE일 때 트리거가 수행하는 저장 프로시저의 본체(body)이다. 트리거 이벤트 트리거 작동을 유발시키는 이벤트로서 다음 세 DML 구문 중 하나를 명시할 수 있다. DELETE 해당 테이블의 데이터를 삭제하는 DELETE 구문 수행 시마다 트리거가 동작된다. INSERT 해당 테이블의 데이터를 삽입하는 INSERT 구문 수행 시마다 트리거가 동작된다. UPDATE 해당 테이블의 데이터를 변경하는 UPDATE 구문 수행 시마다 트리거가 동작된다. UPDATE 트리거 이벤트에 OF 절이 있을 경우, OF 절에 지정된 칼럼의 데이터가 변경될 때만 트리거가 동작된다. Note: 데이터베이스의 무결성을 위해 이중화에 의한 테이블의 변경은 트리거 이벤트로 처리되지 않는다. 데이터베이스 객체 및 권한 91 생성 트리거는 CREATE TRIGGER문을 사용하여 생성할 수 있다. 예제 CREATE TRIGGER del_trigger AFTER DELETE ON orders REFERENCING OLD ROW old_row FOR EACH ROW AS BEGIN INSERT INTO log_tbl VALUES(old_row.ono, old_row.cno, old_row.qty, old_row.arrival_date, sysdate); END; / 변경 존재하는 트리거를 비활성화 시키거나 무효한 상태의 트리거를 재컴파일하는 경우 ALTER TRIGGER문을 사용할 수 있다. 트리거는 처음 생성될 때, 기본적으로 자동 활성화된다. ALTER TRIGGER 구문에 DISABLE과 ENABLE 절을 이용하여 트리거를 비활성화하고 활성화 시킬수 있다. 예제 ALTER TRIGGER del_trigger DISABLE; 삭제 DROP TRIGGER문을 사용해 트리거를 삭제할 수 있다. 예제 DROP TRIGGER del_trigger; 관련 SQL문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL Reference 을 참조한다. 92 Administrator’s Manual CREATE TRIGGER ALTER TRIGGER DROP TRIGGER 또한, 트리거는 저장 프로시저의 한 종류이므로 트리거 본체(body)에 대해서는 Stored Procedures Manual을 참조한다. 데이터베이스 객체 및 권한 93 데이터베이스 사용자 데이터베이스 생성 후 초기 데이터베이스 내에는 시스템 관리자인 SYSTEM_와 SYS 사용자만이 존재한다. 이 사용자들은 DBA (데이터베이스 관리자)이므로 일반 스키마를 구축하여 스키마 객체를 관리하기 위해서는 일반 사용자를 생성해야 한다. 이 절에서는 사용자를 생성하고 관리하는 방법에 대해 설명한다. SYSTEM_와 SYS 사용자 데이터베이스를 생성하면 시스템에 의해 생성되는 시스템 관리자로 일반 사용자와는 구별된다. 시스템 관리자로는 메타 테이블의 소유자로 메타 테이블에 대한 DDL문과 DML문 수행 권한을 가지고 있는 SYSTEM_ 사용자와, DBA로 일반 테이블에 대해 모든 권한을 가지고 있으며 시스템 수준의 모든 작업을 수행할 수 있는 권한을 기본적으로 가지고 있는 SYS 사용자가 있다. 이들 사용자는 DDL 구문을 사용하여 임의로 변경되거나 삭제될 수 없다. 생성 CREATE USER문을 사용하여 사용자를 생성한다. 이 구문을 실행하려면 CREATE USER 시스템 권한이 있어야 한다. 사용자 생성 시 비밀 번호를 지정하여야 하고, 부가적으로 사용자를 위한 기본 테이블스페이스를 설정할 수 있다. 예제 CREATE USER DLR IDENTIFIED BY DLR123 DEFAULT TABLESPACE user_data TEMPORARY TABLESPACE temp_data ACCESS sys_tbs_memory ON; 변경 ALTER USER문을 사용하여 사용자 비밀번호와 해당 사용자의 94 Administrator’s Manual 테이블스페이스 설정을 변경할 수 있다. 예제 사용자 비밀 번호 변경 ALTER USER dlr IDENTIFIED BY dlr12345; 기본 데이터 테이블스페이스 변경 ALTER USER dlr DEFAULT TABLESPACE dlr1_data; 임시 테이블스페이스 변경 ALTER USER dlr TEMPORARY TABLESPACE dlr1_tmp; 특정 테이블스페이스 접근 허용 여부 변경 ALTER USER dlr ACCESS dlr2_data ON; 삭제 사용자를 삭제하고자 하는 경우 DROP USER문을 사용한다. 해당 사용자의 소유로 되어 있는 모든 객체까지 한꺼번에 삭제하고자 할 경우 CASCADE 옵션을 이용한다. 해당 사용자의 스키마 내에 객체가 존재할 때 CASCADE 옵션을 사용하지 않는 경우 DROP USER문 수행 시 오류가 발생한다. 예제 DROP USER dlr CASCADE; 관련 SQL문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL Reference 을 참조한다. CREATE USER ALTER USER DROP USER 데이터베이스 객체 및 권한 95 권한 사용자가 데이터베이스 객체 또는 데이터에 접근하기 위해서는 적절한 권한이 필요하다. 이 절에서는 시스템 권한 및 객체 권한과 이를 관리하는 방법에 대해서 설명한다. 권한의 종류 알티베이스는 사용자가 권한 (privilege)을 관리할 수 있는 기능은 지원하지만 권한들의 묶음인 롤 (role)은 지원하지 않는다. 이 절은 알티베이스가 지원하는 권한의 종류에 대해 설명한다. 시스템 권한 (System Privilege) 시스템 권한은 일반적으로 DBA가 관리를 한다. 시스템 권한이 있는 사용자는 데이터베이스에 특정한 작업을 수행하거나 모든 스키마에 있는 객체들에 접근할 수 있다. 알티베이스가 지원하는 전체 시스템 접근 권한 목록은 다음과 같다. 각 권한에 대한 자세한 설명은 SQL Reference 을 참조한다. 시스템 권한 이름 DATABASE ALTER SYSTEM INDEXES CREATE ANY INDEX ALTER ANY INDEX DROP ANY INDEX PROCEDURES CREATE PROCEDURE CREATE ANY PROCEDURE ALTER ANY PROCEDURE DROP ANY PROCEDURE EXECUTE ANY PROCEDURE SEQUENCES CREATE SEQUENCE CREATE ANY SEQUENCE ALTER ANY SEQUENCE DROP ANY SEQUENCE SELECT ANY SEQUENCE SESSIONS CREATE SESSION TABLES CREATE TABLE CREATE ANY TABLE ALTER ANY TABLE DELETE ANY TABLE 96 Administrator’s Manual 시스템 권한 이름 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 O O DELETE O EXECUTE O INDEX O INSERT O REFERENCES O SELECT O O O UPDATE O 권한 부여 GRANT문을 사용하여 특정 사용자에게 명시적으로 권한을 부여할 수 있다. 데이터베이스 객체 및 권한 97 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; 관련 SQL문 다음과 같은 SQL문을 제공하며 이에 대한 자세한 설명은 SQL Reference 을 참조한다. GRANT 98 Administrator’s Manual REVOKE 테이블스페이스 99 6. 테이블스페이스 이 장에서는 관리자가 알아야할 테이블스페이스의 개념, 테이블스페이스 구조와 그 사용을 위해서 지원되는 기능에 대해서 설명하고, 효율적인 테이블스페이스 관리를 위해서 관리자들이 알아야 할 정보를 전달한다. 100 Administrator’s Manual 테이블스페이스 정의 및 구조 본 절에서는 테이블스페이스가 무엇인지 살펴본다. 또한, 테이블스페이스와 데이터베이스의 관계를 알아보고, 디스크 테이블스페이스, 메모리 테이블스페이스, 휘발성 테이블스페이스들이 각각 어떤 구조를 갖고 있는지 설명한다. 테이블스페이스의 정의 테이블스페이스는 테이블, 인덱스 등의 데이터베이스 객체들이 저장되는 논리적인 저장소 (Storage)이다. 데이터베이스는 올바른 운영을 위해 기본적으로 하나 이상의 테이블스페이스를 필요로 한다. 시스템 테이블스페이스는 데이터베이스 생성시 자동으로 생성된다. 그리고 사용자가 임의로 사용자 정의 테이블스페이스를 생성할 수 있다. 알티베이스는 사용자 정의 테이블스페이스를 데이터베이스 객체가 디스크에 상주하는 디스크 테이블스페이스와 메모리에 상주하는 메모리 테이블스페이스, 메모리에 상주하면서 로깅을 하지 않는 휘발성 테이블스페이스로 구분해 지원한다. 따라서 사용자는 테이블스페이스에 저장되는 데이터의 특성에 따라 디스크, 메모리, 또는 휘발성 테이블스페이스 중에서 어떤 것을 사용할 것인지 결정할 수 있다. 예를 들어 이력 데이터와 같은 대용량 데이터를 위해서는 디스크 테이블스페이스가 적합하다. 또한 접근 빈도가 높은 소용량 데이터는 메모리 테이블스페이스를, 빠른 처리를 위한 임시 데이터 처리는 휘발성 테이블스페이스를 사용하는 것이 적합하다. 데이터베이스 와 테이블스페이스의 관계 데이터베이스 생성시 4종류의 시스템 테이블스페이스 (시스템 딕셔너리 테이블스페이스, 시스템 데이터 테이블스페이스, 시스템 언두 테이블스페이스, 시스템 임시 테이블스페이스) 들이 자동으로 생성된다. 또한 사용자가 테이블스페이스가 필요할 경우 사용자 정의 테이블스페이스 (디스크, 메모리, 또는 휘발성 테이블스페이스)를 생성할 수 있다. 사용자 정의 테이블스페이스는 데이터 특성에 따라 디스크 또는 메모리에 선택적으로 생성할 수 있다. 테이블스페이스 101 [그림 5-1]은 데이터베이스와 테이블스페이스의 관계를 보여준다. 시스템 테이블스페이스 사용자 정의 테이블스페이스 (in Me m ory) 사용자 정의 테이블스페이스 (in Disk) 이 베이스 [그림 6-1] 테이블스페이스와 데이터베이스의 관계 디스크 테이블스페이스 구조 디스크 테이블스페이스는 모든 데이터가 디스크 공간에 저장되는 테이블스페이스이다. 물리적으로는 데이터 파일로 구성되며, 논리적으로 세그먼트, 익스텐트 및 페이지로 구성된다. 물리적 구조 디스크 테이블스페이스는 데이터 파일, 세그먼트와 밀접한 관계를 갖는다. [그림 5-2]는 디스크 테이블스페이스와 데이터 파일 및 세그먼트의 연관 관계를 설명한다. 디스크 테이블스페이스, 데이터 파일 및 세그먼트는 다음과 같은 특징을 갖는다. 디스크 테이블스페이스는 하나 이상의 데이터 파일로 구성되며, 데이터 파일은 운영체제에서 제공되는 파일 형태로 존재한다. 세그먼트는 논리적으로 테이블스페이스에 저장되며, 물리적으로 데이터 파일에 저장된다. 세그먼트는 특정 디스크 테이블스페이스에 종속적이며, 세그먼트가 참조하는 세그먼트는 다른 디스크 테이블스페이스에 저장될 수 있다. 102 Administrator’s Manual 스 테이블스페이스 테이블 세그먼트 인덱스 세그먼트 테이블 세그먼트 인덱스 세그먼트 테이블 세그먼트 인덱스 세그먼트 이 파일 이 파일 [그림 6-2] 디스크 테이블스페이스, 데이터 파일, 세그먼트의 연관 관계 논리적 구조 디스크 테이블스페이스는 논리적으로 세그먼트, 익스텐트 및 페이지로 구성된다. 이들의 관계를 살펴보면 [그림 5-3]과 같다. [그림 6-3] 디스크 테이블스페이스의 논리적 구조 테이블스페이스 103 세그먼트(Segment) 세그먼트는 익스텐트의 집합으로 테이블스페이스 내의 모든 객체가 여기에 저장된다. 세그먼트는 테이블스페이스 내에서 테이블 또는 인덱스를 할당하는 단위이다. 하나의 테이블 또는 인덱스는 논리적으로 하나의 세그먼트로 볼 수 있다. 알티베이스에서 사용하는 세그먼트의 종류는 다음과 같다. 종 류 설 명 Table 세그먼트 데이터베이스 안에 데이터를 저장하는 가장 기본적인 수단이다. 한 개의 테이블 세그먼 트에는 파티션 되지 않은 테이블의 전체 데 이터 또는 파티션드 테이블의 한 파티션의 전체 데이터가 저장될 수 있다. 테이블 생성시 알티베이스는 테이블스페이스 에 테이블 세그먼트를 할당한다. Index 세그먼트 한 개의 인덱스 세그먼트에는 한 인덱스의 모든 데이터 또는 파티션드 인덱스의 한 파 티션의 데이터가 저장될 수 있다. 인덱스 생성시 알티베이스는 테이블스페이스 에 인덱스 세그먼트를 할당한다. Undo 세그먼트 데이터베이스의 변경을 발생시키는 트랜잭션 에 의해 사용된다. 알티베이스는 테이블 또 는 인덱스를 변경하기 전에 변경 전 값 (즉, before-image)을 언두 세그먼트에 저장해 두어, 트랜잭션 롤백시에 변경을 언두할 수 있다. TSS 세그먼트 알티베이스 내부적으로 관리되는 TSS (Transaction Status Slot)를 관리하기 위한 세그먼트이며, 시스템 언두 테이블스페이스 내에 할당된다. [표 6-1] 세그먼트 종류 각 세그먼트는 내부적으로 프리 (Free) 익스텐트 리스트와 풀 (Full) 익스텐트 리스트를 관리한다. 프리 익스텐트가 부족하면 테이블스페이스에 익스텐트 추가를 요청한다. 익스텐트(Extent) 디스크 테이블스페이스에서 데이터 오브젝트를 저장하기 위해서 필요한 자원으로 연속된 여러 페이지를 할당하는 단위이다. 데이터를 저장할 때 저장 가능한 프리 페이지 (Free Page)가 부족하면, 테이블스페이스에서 익스텐트 단위로 페이지를 할당받는다. 104 Administrator’s Manual 한 개의 익스텐트는 기본 64개의 페이지 (512KB)로 구성된다. 알티베이스는 테이블스페이스마다 익스텐트 크기를 다르게 정할 수 있도록 지원한다. 페이지(page) 테이블과 인덱스의 레코드가 저장되는 최소 단위를 페이지라고 한다. 또한 I/O의 최소 단위이다. 알티베이스의 페이지 크기는 8KB이다. (알티베이스는 다양한 페이지 크기 (multiple page size)의 사용을 지원하지 않는다.) 페이지에 어떤 정보를 저장하느냐 따라 데이터 페이지, 인덱스 페이지, 언두 페이지 등 여러 종류의 페이지가 있다. 페이지의 일반적인 구조와 데이터 저장 방식을 살펴보면 다음과 같다. 페이지 구조 페이지는 페이지의 기본 정보와 free slot 등을 관리하기 위한 헤더를 가진다. 레코드는 헤더를 제외한 영역에 저장된다. 페이지는 내부적으로 다음 그림과 같이 5개 영역으로 나누어진다. 물리적 헤더 빈 공간 저장 데이터 페이지 푸터 논리적 헤더 [그림 6-4] 디스크 테이블스페이스의 페이지 구조 물리적 헤더 (Physical Header) 모든 데이터 페이지에 공통되는 정보를 가지고 있다. 논리적 헤더 (Logical Header) 페이지의 종류에 따라 필요한 정보를 가지고 있다. 빈 공간 (Free Space) 새로운 데이터를 저장된다. 테이블스페이스 105 저장 데이터 (Stored Procedure) 페이지 종류에 따라 로우, 인덱스, 언두 레코드 등이 저장된다. 페이지 푸터 (Page Footer) 페이지의 가장 아래쪽에 위치하며, 페이지의 무결성을 검사하기 위한 정보를 가지고 있다. 페이지 레코드 저장 방식 레코드는 페이지의 아래쪽에서 위쪽 (페이지의 시작) 방향으로 채워지며 빈 공간 영역에 저장된다. 페이지의 논리적 헤더는 페이지 아래 방향으로 확장되어 저장된다. 그 크기는 가변적이다. 데이터 1 페이지 푸터 페이지 헤더 데이터 2 데이터 3 [그림 6-5] 페이지 레코드 저장 방식 메모리 테이블스페이스 구조 메모리 테이블스페이스는 모든 데이터가 메모리 공간에 저장되는 테이블스페이스이다. 물리적 구조는 체크포인트 이미지 파일로 구성되며, 논리적으로는 페이지 리스트 및 페이지들로 구성된다. 물리적 구조 메모리 테이블스페이스는 체크포인트 이미지 파일과 밀접한 관계를 갖는다. 다음 그림에서는 메모리 테이블스페이스, 테이블 및 체크포인트 이미지 파일의 연관 관계를 설명한다. 106 Administrator’s Manual [그림 6-6] 메모리 테이블스페이스, 테이블 및 체크포인트 이미지 파일의 연관 관계 메모리 테이블스페이스, 테이블 및 체크포인트는 다음의 특징을 갖는다. 메모리 테이블스페이스는 디스크 테이블스페이스와 달리 데이터를 데이터 파일에 저장하지 않고, 선형적인 메모리 공간에 저장한다. 선형적인 메모리 공간은 페이지 단위로 분할되고, 이 페이지들의 리스트가 테이블을 구성한다. 디스크 테이블스페이스는 디스크 입출력 비용 및 대용량 테이블 관리를 위하여 페이지 단위가 아닌 익스텐트 단위로 관리한다. 세그먼트는 개념적으로 익스텐트의 리스트를 관리하기 논리적인 단위이다. 그러나 메모리 테이블스페이스의 목적은 대용량 데이터의 관리보다 빠른 접근을 지원하는 것이기 때문에, 세그먼트나 익스텐트의 개념이 필요하지 않다. 따라서 메모리 테이블스페이스의 테이블들은 페이지 리스트를 이용하여 관리된다. 메모리 테이블들은 체크포인트시에 물리적으로 체크포인트 이미지 파일에 저장된다. 체크포인트 이미지 파일의 용도는 디스크 테이블스페이스의 데이터 파일의 그것과는 다르다. 디스크 테이블스페이스의 데이터 파일은 객체들을 저장하기 위한 것인 반면, 메모리 테이블스페이스의 체크포인트 이미지 파일은 객체들을 백업하기 위한 것이다. 체크포인트 이미지 파일은 데이터베이스 운영에 직접적으로 필요하지 않다. 하지만 백업 및 복구 시간을 단축하기 위해서는 반드시 필요하다. 체크포인트 시 메모리 공간의 페이지들은 운영 체제에 의해 지원되는 파일에 저장된다. 알티베이스의 체크포인트 방식은 일명 “핑퐁 (ping-pong) 체크포인팅”으로, 이는 두 벌의 체크포인트 이미지 파일 (0번, 1번)을 유지하며, 체크포인트 발생시마다 0번과 1번 파일을 번갈아가며 사용한다. 또한 각 체크포인트 이미지 파일은 디스크 입출력 비용의 분산을 목적으로 다수의 작은 파일로 테이블스페이스 107 분리될 수 있다. 논리적 구조 메모리 테이블스페이스의 논리적 구성 요소에는 페이지 리스트와 페이지가 있다. 이들의 관계를 살펴보면 다음 그림과 같다. [그림 6-7] 메모리 테이블스페이스의 논리적 구조 페이지 리스트 (Page List) 페이지 리스트는 메모리 테이블스페이스 내에서 테이블을 구성하는 논리적인 개념이다. 페이지 리스트는 메모리 테이블스페이스의 메모리 공간을 분할한 단위인 페이지의 리스트이다. 메모리 테이블스페이스 객체 중에서 테이블은 페이지 리스트로 유지된다. 인덱스는 데이터베이스의 일관성을 유지하는 대상에 포함되지 않기 때문에 페이지 리스트를 사용하지 않는다. 시스템을 다시 시작할 때 메모리 테이블의 인덱스는 재구축 되는데, 이는 운영중에 인덱스 로깅을 함으로써 발생할 수 있는 부하를 제거한다. 페이지 (Page) 메모리 테이블스페이스의 페이지 구조 및 데이터 저장 방식은 디스크 테이블스페이스의 페이지와 다른 특징을 갖는다. 메모리 테이블스페이스는 디스크 테이블스페이스와 달리 디스크 입출력 비용을 고려할 필요가 없기 때문에 레코드 수정 방식으로 아웃 플레이스 갱신 (out-place update)을 사용한다. 아웃 플레이스 갱신이란 기존 레코드의 이미지를 직접적으로 변경하지 않고, 레코드의 새로운 버전을 위한 공간을 할당받아 처리하는 방식이다. 이러한 갱신 방식은 기존 레코드의 삭제와 108 Administrator’s Manual 새로운 레코드의 삽입 과정으로 이루어지기 때문에 기존 레코드를 재구성하는 비용이 들지 않는다. 또한 기존 레코드의 접근을 직접 할 수 있어 동시성 레벨이 높은 응용 분야에서 빠른 성능을 보장한다. 휘발성 테이블스페이스 구조 휘발성 테이블스페이스의 구조는 모든 데이터가 메모리 공간에 저장되는 메모리 테이블스페이스와 동일하다. 그러나 디스크상의 이미지 파일을 가지지 않는다는 점에서 메모리 테이블스페이스와 차이가 있다. 휘발성 테이블스페이스의 데이터는 메모리에만 상주한다. 휘발성 테이블스페이스에서 일어나는 작업들은 디스크 로깅 작업을 수반하지 않고 체크포인트 대상에서도 제외되기 때문에 디스크 입출력이 전혀 없다. 따라서 빠른 성능을 필요로 하는 경우에 휘발성 테이블스페이스가 유용하다. 논리적으로 페이지 리스트와 페이지로 구성된다. 물리적 구조 휘발성 테이블스페이스는 메모리에 데이터베이스 객체를 상주시킨다는 점에서 메모리 테이블스페이스와 동일하다. 그러나 휘발성 테이블스페이스는 체크포인트 이미지 파일을 갖지 않는다. 논리적 구조 메모리 테이블스페이스와 동일하게 페이지 리스트와 페이지로 구성된다. 테이블스페이스 109 테이블스페이스 분류 알티베이스가 제공하는 테이블스페이스는 아래 3가지 기준에 의해서 분류된다. 하나의 테이블스페이스는 아래에 분류된 다수의 속성들을 동시에 가질 수 있다. 저장 공간에 따른 분류 저장 내용에 따른 분류 생성 주체에 따른 분류 저장 공간에 따른 분류 알티베이스 테이블스페이스는 저장 공간에 따라 다음과 같이 분류된다. 메모리 상주 테이블스페이스 디스크 테이블스페이스 메모리 상주 테이블스페이스 메모리 상주 테이블스페이스는 로깅 수행 여부 및 디스크 이미지 파일의 존재 여부에 따라 메모리 테이블스페이스와 휘발성 테이블스페이스로 구분된다. 메모리 테이블스페이스는 메모리 기반 객체를 저장하기 위한 테이블스페이스이다. 해당 테이블스페이스 내에 저장되는 모든 객체에 메모리 기반 데이터베이스 기술이 적용됨으로써, 사용자가 실시간으로 데이터에 접근할 수 있다. 그러나 메모리 테이블스페이스의 크기는 시스템의 사용 가능한 물리적 메모리 공간을 초과할 수 없다. 휘발성 테이블스페이스는 디스크 I/O 작업 없이 메모리 기반 객체를 저장하는 테이블스페이스이다. 해당 테이블스페이스 내에 저장되는 모든 객체에 메모리 기반 데이터베이스 기술과 부가적 기술이 적용됨으로써, 사용자가 디스크 I/O 작업 없이 실시간으로 데이터에 접근할 수 있다. 그러나 휘발성 테이블스페이스의 크기는 시스템의 사용 가능한 물리적 메모리 공간을 초과할 수 없고, 데이터베이스 서버 종료시 모든 휘발성 데이터 객체들은 사라진다. 디스크 테이블스페이스 디스크 테이블스페이스는 디스크 기반 객체를 저장하기 위한 테이블스페이스이다. 데이터의 실시간 접근보다는 대용량 데이터를 110 Administrator’s Manual 관리하고 싶은 경우에 사용할 수 있는 테이블스페이스이다. 해당 테이블스페이스에 저장되는 객체들에 대한 접근은 디스크 입출력을 수반한다. 이러한 디스크 입출력 비용이 데이터 접근 시간의 대부분을 차지하기 때문에, 디스크 테이블스페이스는 디스크 입출력 비용을 줄이기 위해서 메모리 버퍼 공간을 사용한다. 저장 내용에 따른 분류 테이블스페이스에 저장되는 내용에 따라 다음과 같이 분류된다. 딕셔너리 테이블스페이스 (Dictionary Tablespace) 언두 테이블스페이스 (Undo Tablespace) 임시 테이블스페이스 (Temporary Tablespace) 데이터 테이블스페이스 (Data Tablespace) 딕셔너리 테이블스페이스 딕셔너리 테이블스페이스는 시스템의 운영상 필요한 메타 데이터를 저장하기 위한 테이블스페이스다. 데이터베이스 생성시 시스템에 의해서 생성되는 테이블스페이스이며, 데이터베이스 내에 하나만 존재할수 있다. 사용자는 딕셔너리 테이블스페이스 내에 객체를 생성할 수 없으며, 시스템만이 메타 데이터 유지 관리를 위한 시스템 객체를 생성할 수 있다. 메타 데이터에 대한 빠른 접근을 위하여 딕셔너리 테이블스페이스는 메모리에 존재한다. 딕셔너리 테이블스페이스가 붕괴 (crash)된 경우에는 전체 데이터베이스를 운영할 수 없다 (백업 및 매체 복구를 이용하여 데이터베이스를 복구시켜야 한다). 언두 테이블스페이스 언두 테이블스페이스는 디스크 객체에 대한 연산이 남긴 언두 이미지 (undo image)를 저장하기 위한 테이블스페이스이다. 알티베이스의 동시성 제어는 MVCC (Multi-Version Concurency Control) 기법이기 때문에 변경 이전의 이미지를 저장할 공간이 필요하다. 이러한 이전 이미지가 언두 테이블스페이스에 저장된다. 언두 테이블스페이스의 사용은 다량의 이전 이미지로 인해 데이터 테이블스페이스가 무한 확장되는 것을 막는다. 언두 테이블스페이스는 시스템에 하나만 존재하며, 데이터베이스 내의 모든 디스크 테이블스페이스에 의해 공유된다. 따라서, 언두 테이블스페이스도 딕셔너리 테이블스페이스와 마찬가지로 시스템 운영상 필수적인 시스템 테이블스페이스이다. 테이블스페이스 단위의 백업이 가능하다. 테이블스페이스 111 임시 테이블스페이스 임시 테이블스페이스는 질의 수행중 생성되는 임시 결과를 저장하기 위한 테이블스페이스이다. 따라서, 트랜잭션이 종료하는 시점에 해당 질의가 남긴 임시 테이블스페이스 내의 모든 데이터들은 사라지게 된다. 이러한 종류의 테이블스페이스는 동시성 제어 및 회복을 위한 로깅 등을 하지 않아 빠른 저장 및 검색이 가능하다. 사용자가 임의로 임시 테이블스페이스를 생성할 수 있으며, 다수의 임시 테이블스페이스가 시스템 내에 존재할 수 있다. 임시 테이블스페이스의 백업은 지원되지 않는다. 데이터 테이블스페이스 데이터 테이블스페이스는 사용자 정의 객체를 저장하기 위한 테이블스페이스이다. 다수의 데이터 테이블스페이스가 시스템 내에 존재할 수 있으며, 사용자는 테이블스페이스에 저장되는 데이터의 특성에 따라 메모리, 휘발성 또는 디스크 테이블스페이스로 생성할 수 있다. 생성 주체에 따른 분류 알티베이스 테이블스페이스는 생성 주체에 따라 다음과 같이 분류된다. 시스템 테이블스페이스 (System Tablespace) 사용자 정의 테이블스페이스( User-defined Tablespace) 시스템 테이블스페이스 시스템 테이블스페이스는 시스템 운영상 필요한 데이터들을 저장하기 위한 테이블스페이스이다. 시스템 딕셔너리 테이블스페이스, 시스템 언두 테이블스페이스, 시스템 데이터 테이블스페이스 및 시스템 임시 테이블스페이스가 이에 해당한다. 시스템 테이블스페이스는 데이터베이스 생성시 만들어지며, 사용자가 명시적으로 테이블스페이스 삭제하거나 이름을 변경할 수 없다. 또한 테이블스페이스 단위의 백업과 매체 복구 수행이 가능하다. 사용자 정의 테이블스페이스 사용자 정의 테이블스페이스는 사용자 정의 객체들의 내용을 112 Administrator’s Manual 저장하기 위한 테이블스페이스이다. 사용자 정의 테이블스페이스 내에 정의된 객체들의 메타 데이터는 딕셔너리 테이블스페이스에 저장된다. 사용자는 명시적으로 사용자 정의 테이블스페이스를 삭제하거나 이름을 변경할 수 있다. 또한 테이블스페이스 단위의 백업 및 복구 수행이 가능하다. 테이블스페이스 목록 데이터베이스가 생성시 다수의 테이블스페이스가 만들어진다. [표 5-2]와 같이 시스템 테이블스페이스, 언두 테이블스페이스, 임시 테이블스페이스, 그리고 사용자가 이용할 수 있는 기본적인 메모리 테이블스페이스와 디스크 테이블스페이스가 생성된다. 추가로 사용자가 ‘CREATE TABLESPACE’문으로 테이블스페이스들을 추가할 수 있다. ID 테이블스페이스 종류 저장 공간 테이블스페이스 이름 생성 시점 0 SYSTEM DICTIONARY TABLESPACE 메모리 SYS_TBS_MEM_DIC CREATE DATABASE 1 SYSTEM MEMORY DEFAULT TABLESPACE 메모리 SYS_TBS_MEM_DATA CREATE DATABASE 2 SYSTEM DISK DEFAULT TABLESPACE 디스크 SYS_TBS_DISK_DATA CREATE DATABASE 3 SYSTEM UNDO TABLESPACE 디스크 SYS_TBS_DISK_UNDO CREATE DATABASE 4 SYSTEM DISK TEMPORARY TABLESPACE 디스크 SYS_TBS_DISK_TEMP CREATE DATABASE 5이상 USER MEMORY DATA TABLESPACE 메모리 사용자 지정 CREATE MEMORY DATA TABLESPACE 5이상 USER DISK DATA TABLESPACE 디스크 사용자 지정 CREATE DISK DATA TABLESPACE 5이상 USER DISK TEMPORARY TABLESPACE 디스크 사용자 지정 CREATE DISK TEMPORARY TABLESPACE 5이상 USER VOLATILE DATA TABLESPACE 메모리 사용자 지정 CREATE VOLATILE DATA 테이블스페이스 113 ID 테이블스페이스 종류 저장 공간 테이블스페이스 이름 생성 시점 TABLESPACE [표 6-2] 테이블스페이스 목록 114 Administrator’s Manual 디스크 테이블스페이스 디스크 테이블스페이스는 모든 데이터가 디스크 공간에 저장되는 테이블스페이스이다. 이 절에서는 디스크의 데이터 페이지를 중심으로 구조 및 로우 데이터의 입력 방식에 대해 살펴본다. 데이터 페이지 구조 알티베이스가 데이터베이스의 저장 공간을 관리할 때 사용하는 데이터의 최소 단위를 페이지 (page)라고 한다. 페이지 크기는 8KB이고, 다양한 크기의 페이지 (multiple page size)는 지원되지 않는다. 데이터 페이지 (data page)는 여러 페이지 종류들 중의 한가지로, 로우 데이터 (row data)를 저장한다. 로우 데이터는 페이지 아래부터 채워가며 저장되며, 이 때 빈 공간 영역을 사용한다. 만약 빈 공간의 영역이 충분하지 않다면, 페이지 콤팩트 (page compact) 연산을 수행하여 단편화된 공간을 제거하고 연속된 빈 공간을 확보하도록 한다. 물리적 헤더 TTL(Touched Transaction Layer) 슬롯 디렉토리 빈 공간(Free space) 로우 데이터 페이지 푸터 [그림 6-8] 데이터 페이지의 구조 데이터 페이지의 영역은 위의 그림과 같이 6개의 영역으로 구성된다. 테이블스페이스 115 물리적 헤더 (Physical Header) 이 영역은 페이지 종류에 상관없이 모든 데이터 페이지들에 공통되는 정보를 가지고 있다. TTL (Touched Transaction Layer) 이 영역은 MVCC (Multi-Version Concurrency Control) 관련 정보를 가지고 있다. 슬롯 디렉터리 (Slot Directory) 이 영역은 로우가 저장된 페이지 내에서의 위치 (offset)에 대한 정보를 가지고 있다. 빈 공간 (Free Space) 이 영역은 입력이나 갱신 등의 연산을 할 때 사용할 수 있는 여유 공간이다. 로우 데이터 (Row Data) 페이지 푸터 (Page Footer) 이 영역은 페이지 구조의 가장 아래쪽에 위치하며, 페이지의 무결성을 확인하기 위한 정보를 가지고 있다. 디스크 테이블스페이스의 공간 관리 디스크 테이블스페이스는 PCTFREE와 PCTUSED 파라미터를 이용 하여 수동적으로 관리될 수 있다. PCTFREE와 PCTUSED 파라미터를 사용해서 로우 데이터에 대한 입력이나 갱신 연산을 할 때 빈 공간의 사용을 제어할 수 있다. 이들 파라미터의 값은 altibase.properties 파일의 PCTFREE와 PCTUSED 프로퍼티의 값으로 지정된다. 또한 테이블 생성(CREATE TABLE…) 또는 변경(ALTER TABLE…) 구문에서 테이블 별로 파라 미터 값을 명시할 수도 있다. PCTFREE PCTFREE는 페이지에 저장되어 있는 로우들이 갱신될 경우에 대비하여 미리 확보해두는 빈 공간의 최소 비율이다. 예를 들어 PCTFREE 값을 20으로 설정하면, 페이지의 80% 공간까지만 입력 (insert)할 수 있고, 나머지 20%의 공간은 기존의 로우들이 갱신될 때 사용을 위해서 남겨둔다. 116 Administrator’s Manual 빈 공간 20% Data Block PCTFREE=20 페이지의 80%가 될 때까지 로우를 입력할 수 있다. 나머지 20%는 페이지에 존재하는 로우의 갱신을 위해 필요한 공간이다. [그림 6-9] PCTFREE 와 페이지 구조 PCTUSED PCTUSED는 페이지가 갱신만 가능한 상태에서 다시 삽입이 가능 상태로 가기 위해서 감소해야 할 페이지 내 사용 공간의 최소 비율이다. PCTFREE 제한에 걸리게 되면, 해당 페이지에는 사용 공간의 비율이 PCTUSED 보다 낮아지기 전까지 새로운 로우를 입력할 수 없고, 이 페이지 내의 빈 공간은 오직 갱신 연산을 위해서만 사용된다. 이 상태는 사용 공간의 비율이 PCTUSED값 아래로 떨어질 때까지 지속된다. 테이블스페이스 117 빈 공간 61% Data Block PCTUSED=40 빈 공간의 비율이 40% 미만으로 될 때까지 새로운 로우의 입력을 하지 않는다. [그림 6-10] PCTUSED 와 페이지 구조 로우의 구조 로우는 하나 이상의 로우 조각 (row piece)들로 구성된다. 만약 로우 전체가 한 개의 페이지에 저장될 수 있다면, 로우는 하나의 로우 조각으로 저장된다. 그러나 로우 전체를 한 개의 페이지에 저장할 수 없다면, 로우는 여러 개의 로우 조각에 나뉘어서 저장된다. 이들 로우 조각들은 ROWID값에 의해 서로 연결된다 (chained). 로우 헤더(공통) ROWID (선택 가능) 칼럼의 길이 칼럼 값 로우 헤더로우 바디 [그림 6-11] 로우 조각의 구조 로우 조각은 로우 헤더 (row header)와 로우 바디(row body)로 구성된다. 118 Administrator’s Manual 로우 헤더에는 18 byte 크기의 헤더 정보가 저장된다. 연결된 로우 조각 (chained row piece)일 경우에는 6 byte의 ROWID 정보가 추가적으로 저장된다. 로우 바디에는 칼럼의 길이 (column length), 칼럼 값 (column value)이 쌍을 이뤄서 연속으로 저장된다. 칼럼 값의 길이가 250 byte 이하이면 칼럼 길이의 저장을 위해서 1byte만 필요하고, 칼럼 값의 길이가 250 byte를 초과하면 칼럼 길이의 저장을 위해서 3byte가 필요하다. 공간을 절약하기 위해서 칼럼 값이 널 (NULL)인 경우 칼럼의 길이 (0)만 저장하고 칼럼 값은 저장하지 않는다. 또한 칼럼 값이 널인 칼럼들이 마지막에 연속으로 올 경우에는 칼럼 값뿐 아니라 칼럼 길이도 저장하지 않는다. 칼럼은 테이블 생성 (CREATE TABLE…) 구문에서 나열한 순서대로 저장된다. 이 때 널을 많이 포함하는 칼럼을 마지막에 배치하면 로우를 저장하는데 필요한 공간을 절약할 수 있다. 로우 체이닝 및 마이그레이션 로우의 데이터가 너무 커서 한 개의 페이지에 저장할 수 없을 때 로우 체이닝 (row chaining)과 로우 마이그레이션 (row migration)이 발생한다. 로우 체이닝은 데이터를 입력할 때 데이터의 크기가 너무 커서 로우가 한 페이지에 저장될 수 없을 때 발생한다. 이 경우에는 로우의 데이터가 여러 개의 페이지에 나누어 저장되고, 이들은 서로 ROWID에 의해 연결된다. 로우 마이그레이션은 한 페이지 내에 저장되었던 로우가 갱신 과정에서 로우의 크기가 페이지의 크기를 넘어가는 경우 발생한다. 이 경우 전체 로우는 새로운 페이지로 마이그레이션 되고, 원래 로우는 옮겨진 로우가 저장된 새로운 위치를 가리키게 된다. 그러나 로우 마이그레이션이 발생하더라도 ROWID는 변경되지 않는다. 로우 체이닝 또는 로우 마이그레이션이 발생하면, DML 처리시에 한 페이지를 더 읽어야 하므로 디스크 I/O로 인한 성능저하가 발생한다. 테이블스페이스 119 언두 테이블스페이스 언두 테이블스페이스는 데이타베이스에 대한 변경 연산을 철회 (rollback)하는데 필요한 정보를 저장하는 테이블스페이스이다. 알티베이스는 다중 버전의 동시성 제어 기법 (MVCC)을 사용하기 때문에 변경 이전의 이미지를 저장할 공간이 필요하다. 언두 테이블스페이스는 데이터베이스에 하나만 존재하며, 데이터베이스 내의 모든 디스크 테이블스페이스에 의해 공유된다. 이 절에서는 언두 테이블스페이스의 특징 및 크기 계산 등 언두 테이블스페이스를 어떻게 관리하는지 설명한다. 언두 레코드 (Undo Record) 언두 테이블스페이스의 특징 트랜잭션 세그먼트의 관리 세그먼트 공간 재사용 언두 테이블스페이스 변경 언두 레코드 데이터베이스는 변경된 트랜잭션을 취소(롤백 또는 언두)하기 위하여 관련 정보들을 유지해야 한다. 이러한 정보들은 주로 트랜잭션이 커 밋되기 전에 언두 레코드들로 저장된다. 언두 레코드는 다음과 같은 목적으로 사용된다. 트랜잭션 철회 (rollback) 데이터베이스 복구 읽기 일관성 (Read Consistency) 보장 롤백 구문이 수행되면, 언두 레코드는 커밋되지 않은 트랜잭션에 의 한 데이터베이스 변경을 취소하기 위해 사용된다. 또한 언두 레코드는 데이터베이스를 복구하는 동안에도 사용된다. 로 그 파일에 기반한 트랜잭션 리두 (redo)에 의해 데이터베이스를 복원 한 후, 언두 레코드는 커밋되지 않은 변경에 대해서 취소하기 위해서 사용된다. 그리고 다른 트랜잭션에 의해 변경중인 레코드를 어떤 트랜잭션이 읽 을 때, 두 트랜잭션이 동시에 레코드에 접근하여도 레코드가 변경되 기 전의 이미지는 언두 레코드에 저장되어 있기 때문에 읽기 일관성 을 보장할 수 있다. 120 Administrator’s Manual 언두 테이블스페이스의 특징 언두 테이블스페이스의 특징을 살펴보면 다음과 같다. 시스템에 의해 자동으로 관리된다. 기본 언두 테이블스페이스 파일은 자동 확장 모드의 undo001.dbf 이다. 데이터 파일의 추가 및 크기 변경이 가능하다. 온라인 백업 (Online Backup)의 대상이다. TSS 세그먼트와 언두 세그먼트 이외의 데이터베이스 객체는 언두 테이블스페이스에 생성이 불가능하다. 언두 테이블스페이스는 시스템 테이블스페이스이므로, 테이블스페이스 오프라인 및 제거가 불가능하다. 서버가 재구동될 때마다 언두 테이블스페이스는 재구성 (Reset)된다. 알티베이스는 언두 테이블스페이스의 정보 및 공간을 관리할 때 시스 템에 의한 관리 방식을 사용한다. 시스템에 의한 관리 방식이란 기본 적으로 언두 테이블스페이스의 세그먼트들과 공간들을 서버가 자동으 로 관리하는 것을 의미한다. 언두 테이블스페이스는 데이터베이스 생성 과정에서 생성된다. 언두 테이블스페이스는 시스템 테이블스페이스로써, 데이터베이스내에 하나만 존재할 수 있다. 만약 언두 테이블스페이스가 존재하지 않는다면 부트 로그에 에러 메시지가 출력되고 서버 구동이 실패한다. 언두 테이블스페이스내에서는 트랜잭션 세그먼트 (TSS 세그먼트와 언두 세그먼트)가 관리된다. 사용자는 프로퍼티 TRANSACTION_SEGMENT_COUNT를 사용해서 트랜잭션 세그먼트의 개수를 변경할 수 있다. 사용자가 프로퍼티에서 지정한 개수만큼 TSS 세그먼트와 언두 세그먼트가 각각 생성된다. TRANSACTION_SEGMENT_COUNT 프로퍼티를 255로 설정하였다면, 서버 구동시마다 TSS 세그먼트 255개와 언두 세그먼트 255개가 생성된다. 프로퍼티 파일내에서 트랜잭션 세그먼트를 다른 개수로 변경하였다면, 다음 서버 구동시에 명시된 개수만큼 세그먼트들이 생성될 것이다. 트랜잭션 세그먼트의 관리 트랜잭션 세그먼트란 디스크 변경 트랜잭션에 반드시 필요한 한 개의 TSS 세그먼트와 한 개의 언두 세그먼트로 구성된다. 테이블스페이스 121 한 트랜잭션 세그먼트는 한 디스크 변경 트랜잭션에 바인딩 (Binding) 되고, 그 트랜잭션이 완료될 때 언바인딩 (Unbinding) 되기 때문에 다른 트랜잭션에 의해 동시에 공유될 수 없다. V$TXSEGS를 조회하면, 트랜잭션 세그먼트의 바인딩 여부를 확인할 수 있다. 디스크 변경 트랜잭션에 해당 트랜잭션 세그먼트가 바인딩되면 V$TXSEGS에 트랜잭션 세그먼트 ID, 트랜잭션 ID에 해당하는 레코드가 생성되고 바인딩이 해제되면 레코드는 삭제된다. 또한 TSS 세그먼트와 언두 세그먼트의 공간은 트랜잭션이 한 번 사용한 공간에 대해서는 어느 정도 시간이 지나면 재사용할 수 있는 구조로 설계되었다. 따라서 언두 트랜잭션의 공간이 필요한 경우에는 무조건 세그먼트를 생성하여 공간을 확장하는 것이 아니라 기간이 만료된 세그먼트가 다시 사용된다. TSS 세그먼트의 재사용 단위는 1M이며, 언두 세그먼트는 2M이다. 다음은 언두 테이블스페이스와 관련된 사용자 프로퍼티를 나타낸다. SYS_UNDO_FILE_INIT_SIZE 언두 테이블스페이스의 데이터 파일 생성시 초기 크기 SYS_UNDO_FILE_MAX_SIZE 언두 테이블스페이스의 데이터 파일 최대 크기 SYS_UNDO_TBS_NEXT_SIZE 언두 테이블스페이스의 데이터 파일 자동 확장 크기 SYS_UNDO_TBS_EXTENT_SIZE 언두 테이블스페이스 한 익스텐트의 페이지 개수 TRANSACTION_SEGMENT_COUNT 트랜잭션 세그먼트의 개수 세그먼트의 공간 재사용 트랜잭션 커밋 후에 언두 데이터는 트랜잭션 롤백이나 복구를 목적으 로 더 이상 필요하지 않다. 하지만 트랜잭션의 커밋 주기가 긴 Long-Term 트랜잭션은 읽기 일관성을 위해서 언두 데이터에 의존 하고 있는 레코드의 이전 버전이 필요하다. 그렇지만 어느 정도 시간 이 지나면 읽기 일관성을 위해서도 더 이상 언두 데이타는 필요하지 않게 된다. 따라서 알티베이스 데이타베이스는 커밋된 언두 데이터라고 하여도 최소한의 기간 동안만 유지하고, 그 기간이 지나면 그 언두 데이터가 차지했던 공간을 다른 트랜잭션이 재사용할 수 있도록 하고 있다. 만약 커밋된 트랜잭션을 위한 언두 데이터를 가지고 있는 공간에 접 근하는 온라인 트랜잭션들이 더 이상 존재하지 않는다면, 해당 언두 122 Administrator’s Manual 공간은 기간이 만료 (Expired)되었다고 한다. 반대로 그 언두 공간에 접근이 가능한 온라인 트랜잭션이 아직 존재한다면, 해당 언두 공간 은 기간이 유효 (Unexpired)하다고 한다. 기간이 만료된 언두 공간 은 다른 트랜잭션에 의해서 재사용 될수 있으나, 기간이 유효한 언두 공간은 재사용될 수 없다. 언두공간 #0 (e xp ire d ) 언두공간 #1 (e xp ire d ) 언두공간 #2 (e xp ire d ) 언두공간 #3 (une xp ire d ) 언두공간 #4 (une xp ire d ) 언두공간 #5 (curre nt) 언두공간 #0 (curre nt) 언두공간 #1 (e xp ire d ) 언두공간 #2 (e xp ire d ) 언두공간 #3 (une xp ire d ) 언두공간 #4 (une xp ire d ) 언두공간 #5 (une xp ire d ) [그림 6-12] 언두 세그먼트의 재사용 위 그림은 언두 세그먼트의 순환 구조가 언두 공간의 재사용을 어떻 게 허락하는지를 보여준다. 그림은 언두 공간 #0부터 시작해서 순서대로 사용되면서 현재 (Current)의 언두 공간 #5을 사용하고 있는 것을 나타낸다. 그리고 다음 차례의 언두 공간 #0이 만료된 것을 확인하고, 언두 공간 #5를 모두 사용하면 언두 세그먼트를 더 이상 확장하지 않고 언두 공간 #0 을 재사용한다. 언두공간 #0 (une xp ire d ) 언두공간 #1 (une xp ire d ) 언두공간 #2 (une xp ire d ) 언두공간 #3 (une xp ire d ) 언두공간 #4 (une xp ire d ) 언두공간 #5 (curre nt) 언두공간 #0 (e xp ire d ) 언두공간 #1 (une xp ire d ) 언두공간 #2 (une xp ire d ) 언두공간 #3 (une xp ire d ) 언두공간 #4 (une xp ire d ) 언두공간 #5 (une xp ire d ) 언두공간 #6 (curre nt) [그림 6-13] 언두 세그먼트의 확장 그러나 언두 공간 #0이 유효한 상태라면 위의 그림처럼 언두 세그먼 트는 익스텐트를 확장하여 언두 공간 #6을 추가하게 된다. 테이블스페이스 123 이와 같은 세그먼트 공간의 재사용성은 TSS 세그먼트에도 동일하게 적용된다. 언두 테이블스페이스 변경 언두 테이블스페이스는 ALTER TABLESPACE 구문을 사용하여 변경될 수 있다. 그러나 언두 테이블스페이스는 대부분이 시스템에 의해서 관리되므로, 다음과 같은 연산들에 대해서만 사용자가 수행할 수 있다. 데이터 파일 추가 및 제거 데이터 파일 크기 확장 및 축소 데이터 파일의 온라인 백업 시작 및 완료 언두 테이블스페이스에 용량 부족 또는 용량 부족과 관련된 에러가 발생하는 것을 방지하려면, 사용자는 데이터 파일들을 추가하거나 기존 데이터 파일의 크기를 확장해야 한다. 다음은 언두 테이블스페이스에 데이터 파일을 추가하는 예제이다. ALTER TABLESPACE SYS_TBS_DISK_UNDO ADD DATAFILE ‘undo002.dbf’ AUTOEXTEND ON NEXT 1M MAXSIZE 2G; ALTER TABLESPACE … DROP DATAFILE 구문으로 데이터 파일을 제거할 수도 있으며, ALTER TABLESPACE ... ALTER DATAFILE… 구문으로 파일의 크기를 확장하거나 축소할 수 있다. 그리고 ALTER TABLESPACE … BEGIN BACKUP 구문으로 데이터 파일의 백업을 시작할 수 있으며, ALTER TABLESPACE … END BACKUP 구문을 사용해서 백업 완료를 할 수 있다. 124 Administrator’s Manual 테이블스페이스 상태 테이블스페이스는 서비스 상태에 따라 온라인 (online), 오프라인 (offline), 또는 폐기 (discard) 상태로 있게 된다. 테이블스페이스 중에서 사용자가 생성한 디스크 테이블스페이스와 메모리 테이블스페이스의 상태는 온라인과 오프라인으로 변경할 수 있으나, 휘발성 테이블스페이스와 임시 테이블스페이스의 상태는 변경할 수 없다. 또한 테이블스페이스 내에 이중화가 걸려있는 테이블이 존재할 경우에도 변경 불가능하다. 상태를 변경하기 위해서는 ALTER TABLESPACE … ONLINE 과 ALTER TABLESPACE … OFFLINE 구문을 사용한다. 단, 테이블스페이스의 온라인/오프라인 상태 전이는 메타 (META) 단계와 서비스 (SERVICE) 구동 단계에서만 가능하다. 온라인 (Online) 테이블스페이스와 관련된 모든 자원이 할당되고 준비된 상태이며, 데이터베이스에서 테이블스페이스를 사용할 수 있게 설정된 상태이다. 테이블스페이스와 그 안에 존재하는 테이블과 인덱스에 대해 DML과 DDL을 수행할 수 있다. 만약 온라인 상태인 테이블스페이스와 테이블스페이스에 생성된 테이블 및 인덱스를 일시적으로 사용할 수 없게 하려면 ALTER TABLESPACE … OFFLINE 구문을 실행하면 된다. 오프라인 (Offline) 테이블스페이스와 관련된 모든 자원이 해제된 상태이며, 데이터베이스에서 테이블스페이스를 일시적으로 사용할 수 없게 설정된 상태이다. 테이블스페이스에 존재하는 테이블과 인덱스에 대한 DML과 DDL을 수행할 수 없다. 그러나 테이블스페이스에 대한 DROP TABLESPACE와 ALTER TABLESPACE ONLINE DDL구문은 사용할 수 있다. 테이블스페이스와 그 안에 생성된 테이블과 인덱스를 다시 사용할 수 있는 온라인 상태로 전이하기 위해서는 ALTER TABLESPACE … ONLINE 구문을 사용하면 된다. 메모리 테이블스페이스가 오프라인으로 되면 메모리 테이블스페이스 125 테이블스페이스의 객체는 메모리에 적재되지 않기 때문에, 메모리 한계 (메모리 부족) 상황이 발생했을 때 사용자는 메모리 테이블스페이스를 오프라인으로 변경해서 그 상황을 해소할 수 있다. 폐기 (Discard) 데이터의 일관성이 깨진 특정 테이블스페이스 때문에 정상적인 알티베이스 구동이 불가능한 경우, 깨진 테이블스페이스를 제외한 나머지에 대해서만이라도 정상적으로 데이터베이스 운영을 할 수 있어야 한다. 이를 위해서 해당 테이블스페이스는 폐기시켜야 한다. 특정 테이블스페이스를 폐기 상태로 전이시키기 위해서는 CONTROL 구동 단계에서 ALTER TABLESPACE … DISCARD 구문을 실행해야 한다. 그러나 한 번 폐기된 테이블스페이스는 제거 (DROP TABLESPACE)만 할 수 있기 때문에 ALTER TABLESPACE … DISCARD 구문을 수행할 때에는 주의해야 한다. 126 Administrator’s Manual 테이블스페이스 관리 본 절에서는 알티베이스에서 지원하는 테이블스페이스를 관리하는 방법에 대해 설명한다 생성 (CREATE) 테이블스페이스 생성은 SYS 사용자 또는 테이블스페이스 생성 권한을 가진 사용자만 할 수 있다. 테이블스페이스를 생성하려면 CREATE TABLESPACE … SQL 구문을 사용한다. 사용자 정의 데이터 테이블스페이스 (User-defined Data Tablespace)만 생성 가능하다. 즉 시스템 테이블스페이스들은 사용자가 임의로 생성할 수 없다. 디스크 테이블스페이스는 디스크 데이터 테이블스페이스와 디스크 임시 테이블스페이스로 분류된다. 메모리 테이블스페이스는 메모리 데이터 테이블스페이스만 있고, 메모리 임시 테이블스페이스는 없다. 마찬가지로 휘발성 테이블스페이스는 휘발성 데이터 테이블스페이스만 있고, 휘발성 임시 테이블스페이스는 없다. 다음은 테이블스페이스를 생성하는데 사용되는 SQL 구문이다. CREATE [DISK/MEMORY/VOLATILE] [DATA/TEMPORARY] TABLESPACE (1) 테이블스페이스 이름 (2) 디스크 데이터 파일 속성 (3) 디스크 임시 파일 속성 (4) 메모리 테이블스페이스 속성 (5) 휘발성 테이블스페이스 속성; 테이블스페이스에 저장된 객체의 크기 및 접근 빈도수와 같은 특성을 고려해서 메모리, 디스크, 또는 휘발성 테이블스페이스의 생성 여부를 결정해야 한다. 테이블스페이스 생성시 지정할 수 있는 테이블스페이스 속성들은 디스크, 메모리, 또는 휘발성에 따라 다르다. 메모리 테이블스페이스는 여러 개의 데이터 파일로 관리되는 디스크 테이블스페이스와는 달리 객체들이 하나의 선형적인 메모리 공간에 저장된다. 따라서, 디스크 테이블스페이스 생성의 경우 각 데이터 파일에 속성이 적용되지만, 메모리 테이블스페이스의 경우 그 메모리 테이블스페이스 전체에 적용된다. 즉 메모리 테이블스페이스에 초기 크기, 확장될 크기 등이 적용되며, 디스크 테이블스페이스는 데이터 테이블스페이스 127 파일에 해당 속성들이 적용된다. 테이블스페이스 이름 테이블스페이스 이름은 유일해야 한다. 동일한 이름의 객체가 두개 이상 생성될 수 없다. 디스크 테이블스페이스의 경우에는 데이터 파일들의 이름을 지정할 수 있지만, 메모리 테이블스페이스의 경우에는 체크포인트 이미지가 저장될 경로만을 지정할 수 있다. 체크포인트 이미지 이름은 테이블스페이스의 이름을 이용하여 자동으로 만들어진다. 디스크 데이터 파일 속성 데이터 파일 속성은 디스크 데이터 테이블스페이스에만 적용되며, 다음과 같은 구문을 갖는다. DATAFILE [①데이터 파일절 AUTOEXTEND [②자동확장절 MAXSIZE [③최대크기절] ] ] EXTENTSIZE [④익스텐트사이즈절] 각 데이터 파일은 다음과 같은 속성을 가질 수 있다. 데이터 파일절 DATAFILE {데이터 파일 경로 및 이름} SIZE integer [K/M/G] [REUSE] 데이터 파일 경로 및 이름을 지정한다. SIZE절 이하는 생략 가능하다. SIZE절은 데이터 파일이 생성될 때의 초기 데이터 파일의 크기를 명시하는데 사용된다. 각 데이터 파일에는 파일 헤더가 저장된다. SIZE는 파일 헤더 크기 (1 page)를 제외한 나머지 페이지들의 총 크기를 의미한다. 따라서, 지정한 초기 크기와 실제 데이터 파일의 크기가 정확히 일치하지는 않는다. 만약 운영 체제에서 지원하는 최대 파일 크기가 초기 크기보다 작을 경우 에러가 반환될 것이다. 자동확장절 AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 디스크 데이터 파일의 확장 여부를 결정한다. ON일 경우 시스템에 의해서 데이터 파일이 자동으로 확장된다. OFF일 경우 사용자가 명시적으로 파일을 확장해야 한다. 데이터 파일의 확장 단위는 사용자가 NEXT절에 명시할 수 있다. 데이터 파일이 확장될 때 해당 데이터 파일이 속한 128 Administrator’s Manual 테이블스페이스에서 수행되는 모든 연산은 해당 데이터 파일이 확장이 끝날 때까지 대기한다. 최대크기절 MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장절의 부속절로써, 데이터 파일이 확장될수 있는 최대 크기를 의미한다. 초기 크기와 마찬가지로 만약 운영 체제에서 지원하는 최대 파일 크기가 데이터 파일의 최대 크기보다 작을 경우 운영 체제의 최대 파일 크기로 설정된다. UNLIMITED로 설정된 경우에는 데이터 파일이 디스크의 가능한 공간을 모두 사용할 때까지 사이즈가 늘어난다. 익스텐트 사이즈절 EXTENTSIZE {{integer [K/M/G]}/{UNLIMITED}} 테이블스페이스에 저장되는 세그먼트 (테이블 또는 인덱스)가 할당받는 단위인 익스텐트의 사이즈를 정의한다. 익스텐트 사이즈를 명시하지 않을 경우 기본값으로 512K (64 pages)를 갖는다. 디스크 임시 파일 속성 임시 파일 속성은 디스크 임시 테이블스페이스에만 적용되며, 다음과 같은 구문을 갖는다. TEMPFILE {①임시 파일절} AUTOEXTED [②자동확장절 MAXSIZE [③최대크기절] ] EXTENDSIZE [④익스텐트사이즈절] 각 임시 파일은 다음과 같은 속성을 가질 수 있다. 임시 파일절 TEMPFILE {데이터 파일 경로 및 이름} SIZE integer [K/M/G] [REUSE] 이 절은 임시 파일 경로 및 이름을 지정하며, SIZE절 이하는 생략 가능하다. SIZE절은 임시 파일이 생성될 때의 초기 크기를 명시하는데 사용된다. 각 임시 파일에는 파일 헤더가 저장된다. SIZE는 파일 헤더 크기 (1 page)를 제외한 나머지 페이지들의 총 크기를 의미한다. 따라서, 지정한 초기 크기와 실제 임시 파일의 크기가 정확히 일치하지는 않는다. 만약 운영 체제에서 지원하는 최대 파일 크기가 초기 크기보다 작을 경우 에러가 반환될 것이다. 테이블스페이스 129 자동확장절 AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 디스크 임시 파일의 확장 여부를 결정한다. ON일 경우 시스템에 의해서 임시 파일이 자동으로 확장된다. OFF일 경우 사용자가 명시적으로 파일을 확장해야 한다. 임시 파일의 확장 단위는 사용자가 NEXT절에 명시할 수 있다. 최대크기절 MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장절의 부속절로써, 임시 파일이 확장될수 있는 최대 크기를 의미한다. 초기 크기와 마찬가지로 만약 운영 체제에서 지원하는 최대 파일 크기가 임시 파일의 최대 크기보다 작을 경우 운영 체제의 최대 파일 크기로 설정된다. UNLIMITED로 설정된 경우에는 임시 파일이 디스크의 가능한 공간을 모두 사용할 때까지 크기가 늘어난다. 익스텐트 사이즈절 EXTENTSIZE integer [K/M/G] 임시 테이블스페이스에 저장되는 세그먼트 (테이블 또는 인덱스)가 할당받는 단위인 익스텐트의 사이즈를 정의한다. 익스텐트 사이즈를 명시하지 않을 경우 기본값으로 256K (32 pages)를 갖는다. 메모리 테이블스페이스 속성 메모리 테이블스페이스에 적용되는 속성은 디스크 테이블스페이스의 데이터 파일 속성과 유사하지만, 추가적으로 체크포인트 이미지 경로를 포함한다. 구문은 다음과 같다. SIZE {①초기 크기절} AUTOEXTED [②자동확장절 MAXSIZE [③최대크기절] ] CHECKPOINT PATH [④체크포인트 이미지 경로절] 메모리 테이블스페이스는 다음과 같은 속성을 가질 수 있다. 초기 크기절 SIZE integer [K/M/G] 메모리 테이블스페이스 생성시 초기에 할당되어야할 메모리 크기를 130 Administrator’s Manual 나타낸다. 이 값은 메모리 테이블스페이스의 기본 확장 단위의 배수여야 한다. (EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 지정한 페이지 개수 * 메모리 테이블스페이스의 페이지 크기(32KB)2) 이 크기는 KiloBytes (K), Megabytes (M), 또는 Gigabytes (G) 단위로 명시할 수 있다. 이 단위를 명시하지 않을 경우 기본 단위는 KiloBytes (K)이다. 자동확장절 AUTOEXTEND [{ON NEXT integer [K/M/G]}/{OFF}] 메모리 테이블스페이스의 자동 확장 여부를 결정한다. ON일 경우 시스템에 의해서 테이블스페이스가 자동으로 확장되지만, OFF일 경우 사용자가 명시적으로 크기를 확장해야 한다. 확장되는 크기는 사용자가 NEXT절에 명시할 수 있다. 확장되는 크기는 초기 크기와 마찬가지로 EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 설정된 페이지 크기의 배수에 해당하는 크기로 지정하여야 한다. 자동 확장 크기가 너무 작으면 자동확장이 너무 빈번하게 발생할 수 있다. 알티베이스는 자동확장을 수행할 때 시스템에 존재하는 모든 메모리 테이블스페이스의 현재 크기를 합산하여 MEM_MAX_DB_SIZE 프로퍼티에 지정한 크기보다 작은지 비교한다. 이러한 연산을 빈번하게 수행하면 시스템의 성능이 저하될 수 있다. 최대크기절 MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장절의 부속절로써, 메모리 테이블스페이스가 확장될수 있는 최대 크기를 의미한다. 초기 크기와 마찬가지로 운영 체제에서 제공되는 메모리 공간의 크기를 초과할 수 없다. UNLIMITED로 설정된 경우에는 시스템에 존재하는 모든 메모리 테이블스페이스의 크기를 합친 전체 크기가 MEM_MAX_DB_SIZE 프로퍼티에 지정한 크기를 벗어나지 않는 한도 내에서 테이블스페이스가 자동확장된다. 체크포인트 이미지 경로절 2 예를 들어 EXPAND_CHUNK_PAGE_COUNT를 128로 지정하였다면, 메모리 테이블스페이스의 기본 확장 크기는 128 * 32K로 계산되며, 값은 4MB가 된다. 그러므로 SIZE로 지정할 수 있는 크기는 4MB의 배수이다. 테이블스페이스 131 CHECKPOINT PATH ‘체크포인트 이미지 경로 리스트’ SPLIT EACH integer [K/M/G] 체크포인트 이미지 경로는 메모리 테이블스페이스에만 적용된다. 알티베이스는 메모리 테이블스페이스의 고성능 트랜잭션 처리를 위하여 핑퐁(ping-pong) 체크포인트를 사용한다. 핑퐁 체크포인트를 위해서 두 벌의 체크포인트 이미지가 디스크에 생성된다. 각 체크포인트 이미지는 다수의 파일에 분할되어 저장될 수 있다. 체크포인트 이미지가 분할되는 크기는 SPLIT EACH절에 명시할 수 있다. 분할된 파일은 디스크 입출력 비용을 분산하기 위하여 다수의 경로에 저장될 수 있으며, 사용자가 임의로 분할의 크기 및 체크포인트 이미지들이 저장되는 경로들을 지정할 수 있다. 사용자는 체크포인트 이미지 경로를 추가하거나 변경할 수 있지만, 한번 지정된 분할의 크기를 변경할 수는 없다. 휘발성 테이블스페이스 속성 휘발성 테이블스페이스에 적용되는 속성은 체크포인트 이미지 경로를 제외하고는 메모리 테이블스페이스의 속성과 유사하다. SIZE {①초기 크기절} AUTOEXTED [②자동확장절 MAXSIZE [③최대크기절] ] 휘발성 테이블스페이스는 다음과 같은 속성을 가질 수 있다. 초기크기절 SIZE integer [K/M/G] 휘발성 테이블스페이스 생성시 초기에 할당되어야할 메모리 크기를 나타낸다. 이 값은 메모리 테이블스페이스의 기본 확장 단위의 배수여야 한다. (EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 지정한 페이지 개수 * 메모리 테이블스페이스의 페이지 크기(32KB)3) 이 크기는 KiloBytes (K), Megabytes (M), 또는 Gigabytes (G) 단위로 명시할 수 있다. 이 단위를 명시하지 않을 경우 기본 단위는 KiloBytes (K)이다. 자동확장절 3 예를 들어 EXPAND_CHUNK_PAGE_COUNT를 128로 지정하였다면, 메모리 테이블스페이스의 기본 확장 크기는 128 * 32K로 계산되며, 값은 4MB가 된다. 그러므로 SIZE로 지정할 수 있는 크기는 4MB의 배수이다. 132 Administrator’s Manual AU T O EXT EN D [ {O N N EX T i n t e g e r [ K / M / G ] }/ {O F F }] 휘발성 테이블스페이스의 자동 확장 여부를 결정한다. ON일 경우 시스템에 의해서 테이블스페이스가 자동으로 확장되지만, OFF일 경우 사용자가 명시적으로 크기를 확장해야 한다. 확장되는 크기는 사용자가 NEXT절에 명시할 수 있다. 확장되는 크기는 초기 크기와 마찬가지로 EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 설정된 페이지 크기의 배수에 해당하는 크기로 지정하여야 한다. 자동 확장 크기가 너무 작으면 자동확장이 너무 빈번하게 발생할 수 있다. 알티베이스는 자동확장을 수행할 때 시스템에 존재하는 모든 휘발성 테이블스페이스의 현재 크기를 합산하여 VOLATILE_MAX_DB_SIZE 프로퍼티에 지정한 크기보다 작은지 비교한다. 이러한 연산을 빈번하게 수행하면 시스템의 성능이 저하될 수 있다. 최대크기절 MAXSIZE {{integer [K/M/G]}/{UNLIMITED}} 자동확장절의 부속절로써, 휘발성 테이블스페이스가 확장될수 있는 최대 크기를 의미한다. 초기 크기와 마찬가지로 운영 체제에서 제공되는 메모리 공간의 크기를 초과할 수 없다. UNLIMITED로 설정된 경우에는 시스템에 존재하는 모든 휘발성 테이블스페이스의 크기를 합친 전체 크기가 VOLATILE_MAX_DB_SIZE프로퍼티에 지정한 크기를 벗어나지 않는 한도 내에서 테이블스페이스가 자동확장 된다. 예제 Ex.1) 세개의 데이터 파일을 가지는 디스크 데이터 테이블스페이스를 생성한다. iSQL> CREATE DISK DATA TABLESPACE user_data DATAFILE ‘/tmp/tbs1.user’ SIZE 10M AUTOEXTEND ON NEXT 1M MAXSIZE 1G, ‘/tmp/tbs2.user’ SIZE 10M AUTOEXTEND ON NEXT 1M MAXSIZE 500M, ‘/tmp/tbs3.user’ SIZE 10M AUTOEXTEND ON NEXT 1M MAXSIZE 1G; Create success. Ex.2) 메모리 데이터 테이블스페이스를 생성한다. iSQL> CREATE MEMORY DATA TABLESPACE user_data SIZE 12M AUTOEXTEND ON NEXT 4M MAXSIZE 500M CHECKPOINT PATH ‘/tmp/checkpoint_image_path1’, ‘/tmp/checkpoint_image_path2’ SPLIT EACH 12M; 테이블스페이스 133 Create success. Ex.3) 휘발성 데이터 테이블스페이스를 생성한다. iSQL> CREATE VOLATILE DATA TABLESPACE user_data SIZE 12M AUTOEXTEND ON NEXT 4M MAXSIZE 500M; Create success. 삭제 (DROP) 테이블스페이스 삭제는 SYS 사용자 또는 테이블스페이스 삭제 권한을 가진 사용자만이 할 수 있다. 테이블스페이스를 삭제하려면 DROP TABLESPACE … SQL 구문을 사용한다. 시스템 테이블스페이스들은 사용자에 의해서 삭제될 수 없다. 테이블스페이스의 삭제는 메모리나 디스크, 휘발성을 명시적으로 구분하지 않으며, 아래와 같은 구문을 갖는다. DROP TABLESPACE {테이블스페이스 이름} [{⑴객체 삭제절} [⑵데이터 파일 삭제절] [⑶제약사항 삭제절]]; 테이블스페이스의 이름을 이용하여 삭제를 수행하며 선택할 수 있는 옵션은 아래와 같다. 만약 아래 옵션들을 선택하지 않는다면 테이블스페이스의 스키마만이 로그앵커 (loganchor)에서 삭제된다. 객체 삭제절 INCLUDING CONTENTS 테이블스페이스내 객체 (테이블 또는 인덱스)들과 객체의 내용을 삭제한다. 만약 테이블스페이스 내에 하나 이상의 객체가 존재한다면 반드시 해당 옵션을 선택해야 한다. 그렇지 않을 경우, 테이블스페이스 삭제 연산은 실패할 것이다. 데이터 파일 삭제절 INCLUDING CONTENTS AND DATAFILES 객체 삭제절을 명시하였을 경우, 객체의 레코드및 인덱스 키가 삭제되지만 데이터 파일 자체가 삭제되는 것은 아니다. 따라서, 데이터 파일을 지우기 위해서는 데이터 파일 삭제절을 명시해야 한다. 데이터 파일 삭제절은 객체 삭제절의 부속절로써, 테이블스페이스가 가지고 있는 모든 데이터 파일을 물리적으로 삭제한다. 해당 옵션은 134 Administrator’s Manual 디스크 테이블스페이스에 국한된 옵션이며, 메모리 테이블스페이스의 경우에는 해당 옵션은 무시된다. 그리고 휘발성 테이블스페이스의 경우에 AND DATAFILES 구문을 사용하면 에러를 발생시킨다. 제약사항 삭제절 INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS 객체 삭제절의 부속절로써, 삭제하고자 하는 테이블스페이스 내의 객체들을 참조하는 제약사항 (constraints)이 다른 테이블스페이스에 존재하는 경우 테이블스페이스에 객체가 남아있다는 에러가 발생하며 실패하게 된다. 이럴 경우에 객체와 참조를 삭제하기 위해 CASCADE CONSTRATINS 절이 사용될 수 있다. 변경 (ALTER) 테이블스페이스 변경은 SYS 사용자 또는 테이블스페이스 삭제 권한을 가진 사용자만이 할 수 있다. 테이블스페이스를 변경하려면 ALTER TABLESPACE … SQL 구문을 사용한다. 이 구문은 기존의 테이블스페이스의 정의, 하나 이상의 데이터 파일 또는 임시 파일의 속성, 또는 메모리 테이블스페이스, 휘발성 테이블스페이스의 속성을 변경하는데 사용된다. 다음은 SQL 구문을 설명한다. ALTER TABLESPACE {테이블스페이스 이름} {{⑴디스크 데이터 파일 변경절}/ {⑵디스크 임시 파일 변경절}/ {⑶메모리 테이블스페이스 변경절}/ {⑷휘발성 테이블스페이스 변경절}/ {⑸테이블스페이스 상태 변경절}}; 디스크 데이터 파일 변경절 이 절은 디스크 시스템 테이블스페이스와 디스크 데이터 테이블스페이스에 사용할 수 있으며, 아래와 같은 옵션을 가진다. ALTER TABLESPACE {테이블스페이스 이름} {①테이터파일 추가절/ ②데이터 파일 삭제절/ ③데이터 파일 크기 변경절/ ④데이터 파일 이름 변경절} 데이터파일 추가절 ADD {DATAFILE} {데이터 파일절} 테이블스페이스 135 AUTOEXTEND [자동확장절 MAXSIZE [최대크기절] ] 이 절은 디스크 테이블스페이스에서 데이터를 저장할 공간을 확장하려 할 때 사용된다. 가능한 옵션은 테이블스페이스 생성시에 데이터 파일에 적용되는 구문과 동일하다. 데이터 파일 삭제절 DROP {DATAFILE} {데이터 파일명} 이 절은 디스크 테이블스페이스에서 데이터를 저장할 공간을 축소하려 할때 사용된다. 데이터 파일 추가에 의한 확장은 자유롭게 수행할 수 있지만, 데이터 파일의 삭제는 해당 데이터 파일이 현재 사용중이지 않을 때, 즉 해당 데이터 파일까지 익스텐트가 확장되지 않았을 때만 가능하다. 데이터 파일 크기 변경절 ALTER {DATAFILE} {데이터 파일명} {{AUTOEXTEND [자동 확장절]} / {SIZE [크기 변경절]}} 이 절은 디스크 테이블스페이스에 속하는 각 데이터 파일들의 현재 크기, 최대 크기, 확장 단위 및 자동확장 여부 등을 변경하는 데 사용된다. 명시되는 현재 크기 및 최대 크기는 현재 사용중인 크기보다 커야 한다. 데이터 파일 이름 변경절 RENAME {DATAFILE} {기존 데이터 파일 경로및 이름} TO {새로운 데이터 파일 경로및 이름} 데이터 파일의 위치를 변경함으로써 테이블스페이스의 데이터가 저장된 파일 시스템을 변경하는 것이다. 이 절은 온라인이나 오프라인에 상관없이 어떤 구동 단계에서도 수행 가능하다. 하지만, 서비스 단계에서는 오프라인 상태인 테이블스페이스에 대해서만 수행할 수 있다. 디스크 임시 파일 변경절 이 절은 디스크 임시 테이블스페이스에만 사용할 수 있다. 아래와 같은 옵션들을 가진다. 136 Administrator’s Manual A L T ER T AB L ES PAC E { 테이 블스페 이스 이름} {①임시 파일 추가절/ ② 임시 파일 삭제절/ ③ 임시 파일 크기 변경절/ ④ 임시 파일 이름 변경절} 임시 파일 추가절 ADD {TEMPFILE} {임시 파일절} AUTOEXTEND [자동확장절 MAXSIZE [최대크기절]] 이 절은 디스크 테이블스페이스에서 데이터를 저장할 공간을 확장하려 할 때 사용된다. 가능한 옵션은 테이블스페이스 생성시에 데이터 파일에 적용되는 구문과 동일하다. 임시 파일 삭제절 DROP {TEMPFILE} {임시 파일명} 디스크 임시 테이블스페이스에서 데이터를 저장할 공간을 축소하려 할때 사용한다. 데이터 파일 추가에 의한 확장은 자유롭게 수행할 수 있지만, 데이터 파일의 삭제는 해당 데이터 파일이 현재 사용중이지 않을 때, 즉 해당 데이터 파일까지 익스텐트가 확장되지 않았을 때만 가능하다. 임시 파일 크기 변경절 ALTER {TEMPFILE} {임시 파일명} {{AUTOEXTEND [자동 확장절]} / {SIZE [크기 변경절]}} 이 절은 디스크 임시 테이블스페이스에 속하는 각 임시 파일들의 현재 크기, 최대 크기, 확장 단위 및 자동확장 여부 등을 변경하는 데 사용된다. 명시되는 현재 크기 및 최대 크기는 현재 사용중인 크기보다 커야 한다. 임시 파일 이름 변경절 RENAME {TEMPFILE} {기존 임시 파일 경로및 이름} TO {새로운 임시 파일 경로및 이름} 임시 파일의 위치를 변경함으로써 테이블스페이스의 데이터가 저장된 파일 시스템을 변경하는 것이다. 해당 기능은 온라인이나 테이블스페이스 137 오프라인에 상관없이 어떤 구동 단계에서도 수행 가능하다. 하지만, 서비스 단계에서는 오프라인 상태인 테이블스페이스에 대해서만 수행할 수 있다. 메모리 테이블스페이스 변경절 이는 메모리 시스템 테이블스페이스와 메모리 사용자 정의 테이블스페이스에만 사용될 수 있으며, 아래와 같은 옵션들을 가진다. 체크포인트 경로에 대한 추가, 삭제 및 변경은 어느 구동 단계에서도 수행 가능하다. 그러나 서비스 단계에서는 오프라인 테이블스페이스만 변경이 가능하다. ALTER TABLESPACE {테이블스페이스 이름} {① 체크포인트 경로 추가절/ ② 체크포인트 경로 삭제절/ ③ 체크포인트 경로 변경절/ ④ 테이블스페이스 크기 변경절} 체크포인트 경로 추가절 ADD CHECKPOINT PATH {디렉터리 경로} 체크포인트 이미지 경로를 추가적으로 설정한다. 체크포인트 경로 삭제절 DROP CHECKPOINT PATH {디렉터리 경로} 기존 체크포인트 이미지 경로를 삭제한다. 체크포인트 경로 변경절 RENAME CHECKPOINT PATH {기존 디렉터리 경로} TO {새로운 디렉터리 경로} 기존 체크포인트 이미지 경로를 새로운 경로로 변경한다. 테이블스페이스 크기 변경절 ALTER {{AUTOEXTEND [자동 확장절]} / {SIZE [크기 변경절]}} 메모리 테이블스페이스의 최대 크기, 확장 단위, 자동확장 여부 등을 변경한다. 138 Administrator’s Manual 휘발성 테이블스페이스 변경절 이 절은 휘발성 사용자 정의 테이블스페이스만 사용될 수 있으며, 아래와 같은 옵션을 가진다. ALTER TABLESPACE {테이블스페이스 이름} {① 테이블스페이스 크기 변경절} 테이블스페이스 크기 변경절 ALTER {{AUTOEXTEND [자동 확장절]} / {SIZE [크기 변경절]}} 휘발성 테이블스페이스의 최대 크기, 확장 단위, 자동확장 여부 등을 변경한다. 테이블스페이스 상태 변경절 테이블스페이스의 상태는 온라인과 오프라인이 있으며, 다음과 같은 구문으로 상태를 설정할 수 있다. ALTER TABLESPACE {테이블스페이스 이름} {ONLINE/OFFLINE/DISCARD} 온라인 상태는 테이블스페이스에 속한 모든 객체에 사용자가 접근할 수 있는 일반적인 상태이다. 반면 오프라인 상태는 테이블스페이스 관련 DDL을 제외한 다른 연산에 의해 테이블스페이스 객체에 접근할 수 없는 상태이다. 이러한 오프라인 상태를 이용하여 한계 상황 극복이나 서비스 단계에서의 RENAME 연산 등을 할 수 있다. 단 시스템 테이블스페이스는 항상 온라인 상태로 유지되며, 오프라인으로 변경될 수 없다. 휘발성 테이블스페이스에 대해서는 이 구문을 사용할 수 없다. 디스카드 옵션은 알티베이스에서 운용중인 여러 테이블스페이스 중 특정 테이블스페이스의 데이터에 오류가 발생4하여 알티베이스가 기동되지 않는 문제가 발생할 경우에 사용될 수 있다. 해당 테이블스페이스를 디스카드 (DISCARD)함으로써 해당 4 예를 들어 DBA가 실수로 특정 메모리 테이블스페이스의 체크포인트 이미지 파일을 삭제했다고 가정하자. 이 경우 서버 기동시 해당 메모리 테이블스페이스를 로드할 수 없기 때문에 DBA는 매체 복구를 이용하여 삭제된 체크포인트 이미지를 재생성하는 방법을 먼저 생각해 볼 수 있다. 그러나, 아카이브 로깅을 사용하지 않고 있다면, 매체 복구가 불가능하기 때문에 이 방법은 사용할 수 없을 것이다. 이 때 만약 해당 테이블스페이스를 삭제해도 상관이 없다면, 디스카드 기능을 이용하여 해당 테이블스페이스를 제외하고 DB를 구동한 후 테이블스페이스를 제거하면 된다. 테이블스페이스 139 테이블스페이스를 버리는 대신, 나머지 테이블스페이스로 알티베이스를 기동할 수 있다. 한번 디스카드된 테이블스페이스는 제거 (DROP)외에 다른 연산은 사용이 불가하게 되므로, 사용에 신중을 기하여야 한다. 아울러, 테이블스페이스는 오직 컨트롤 (CONTROL) 단계에서만 디스카드 될 수 있다. 이 옵션은 디스크 테이블스페이스와 메모리 데이터 테이블스페이스에 사용될 수 있다. 테이블스페이스 백업 및 복구 이번 절에서는 테이블스페이스의 온라인/오프라인 백업의 개념 및 특징을 간단하게 설명한다. 백업 및 복구에 대한 자세한 설명은 이 매뉴얼의 해당 장과 Getting Started Guide을 참고한다. 테이블스페이스 온라인 백업 (HOT 백업) 테이블스페이스의 온라인 백업은 서비스 제공중인 테이블스페이스에 대한 백업을 하는 것이다. 온라인 백업은 트랜잭션 진행에는 영향을 주지 않기 때문에, 서비스 단계에서 이루어질 수 있다. 온라인 백업은 다음의 몇 가지 특징을 갖는다. 온라인 백업은 데이터베이스가 아카이브 로그 모드로 운영될 때만 가능하다. 아카이브 로그 모드에서는, 체크포인트와 로그 플러시 (Log Flush) 후에도 로그 파일을 별도의 스토리지에 백업하므로 대용량의 스토리지를 필수로 준비해야 한다. ALTER DATABASE BACKUP 구문을 이용해서 데이터베이스 운영 중에 온라인 백업을 할 수 있다. 장애로 인하여 데이터 파일이 손상되거나 지워지는 경우에도 데이터 파일을 현재 시점까지 매체 복구 (media recovery)가 가능하다. 140 Administrator’s Manual [그림 6-14] 매체 복구 (Media Recovery)의 개념 디스크 테이블스페이스의 데이터 파일 xyz가 손상되었을 경우에 이전에 HOT 백업해 두었던 데이터 파일을 이용해서 복구가 가능하다. 메모리 테이블스페이스의 경우는 이전에 HOT 백업해 두었던 체크포인트 이미지 파일을 이용해서 복구가 가능하다. 백업해 둔 데이터 파일의 헤더에 백업 시점에 최종 체크포인트된 SCN (140)과 recovery LSN (32:010)이 있으므로, 이를 기준으로 현재의 최종 체크포인트 SCN (200)까지 데이터 파일을 복원할 수 있다. 재시작 시점에 온라인 로그의 리두 (Redo)와 언두 (Undo) 로그를 이용해서 데이터 파일 또는 메모리 테이블스페이스의 가장 최근 상태 이미지로 복구된다. 테이블스페이스 오프라인 백업 (Cold 백업) 테이블스페이스의 오프라인 백업은 테이블스페이스의 서비스 진행을 중단하고, 백업하는 형태를 의미한다. 오프라인 백업 방식은 온라인 백업보다 빠르며, 회복에 걸리는 시간을 단축시킨다. 오프라인 백업은 다음과 같은 특징을 갖는다. 오프라인 백업은 데이터베이스가 노 아카이브 모드로 운영될 때 가능하다. 오프라인 백업이란 데이터베이스 서버를 정상 종료 시킨 후에 데이터 파일, 로그 파일, 로그 앵커(log anchor) 파일 등을 복사하는 방식이다. 장애로 인하여 데이터 파일이 손상되거나 지워지는 경우에는 최종 오프라인 백업된 시점까지만 복구가 가능하다. 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 테이블스페이스 141 오프라인 복구 복구는 백업 이미지를 바탕으로 데이터베이스를 일관적인 상태로 만드는 과정이다. 복구는 데이터베이스가 온라인 중에는 진행될 수 없으며, 반드시 오프라인으로 진행되어야 한다. 데이터베이스의 서비스를 중지한 상태에서 기존 데이터베이스를 오프라인 백업된 파일로 바꾼 후에 재시작함으로써 복구가 수행된다. 142 Administrator’s Manual 테이블스페이스 사용 예제 본 절에서는 메모리 테이블스페이스와 휘발성 테이블스페이스 사용 예제를 살펴본다. 메모리 테이블스페이스 메모리 테이블스페이스 생성 - 기본 메모리테이블스페이스를 생성하는 가장 간편한 방법은 SIZE절에 초기 크기를 명시하면서 CREATE MEMORY TABLESPACE 구문을 이용하는 것이다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M; Create success. 이 경우 기본적으로 자동확장 모드는 OFF가 되며, 테이블스페이스의 크기인 256M의 공간을 한번에 할당받게 된다. 해당 테이블스페이스에 공간을 추가로 할당하려 할 때5 테이블스페이스 공간이 부족하다는 에러 메시지가 발생한다. 또한 체크포인트 경로는 기본적으로 MEM_DB_DIR 프로퍼티에 지정한 하나 혹은 그 이상의 체크포인트 경로가 새로 생성된 테이블스페이스을 위한 체크포인트 경로로 사용된다. altibase.properties 에 아래의 예처럼 두 개의 체크포인트 경로가 명시되어 있다고 가정하자. MEM_DB_DIR프로퍼티의 값이 알티베이스 홈 디렉터리의 dbs1와 dbs2, 두 개로 지정되어 있다. # altibase.properties MEM_DB_DIR = ?/dbs1 MEM_DB_DIR = ?/dbs2 이와 같은 경우에 다음의 쿼리를 사용해서 앞서 생성한 USER_MEM_TBS테이블스페이스를 위한 체크포인트 경로로 MEM_DB_DIR에 지정한 dbs1과 dbs2가 지정된 것을 확인할 수 있다. iSQL> SELECT CHECKPOINT_PATH FROM V$MEM_TABLESPACE_CHECKPOINT_PATHS WHERE SPACE_ID = (SELECT SPACE_ID 5 테이블스페이스에 테이블을 생성, 이미 생성되어 있는 테이블에 입력, 또는 테이블의 데이터를 수정하는 경우 테이블스페이스로부터 공간을 추가로 할당하게 할당받는다. 테이블스페이스 143 FROM V$MEM_TABLESPACES WHERE SPACE_NAME='USER_MEM_TBS'); CHECKPOINT_PATH --------------------------------------------------- /altibase_home/dbs1 /altibase_home/dbs2 2 rows selected. 우선, 체크포인트 경로 안의 파일들을 살펴보자. dbs1 디렉터리 내에 다음과 같이 6개의 파일이 존재하는 것을 볼 수 있다. SYS_TBS_MEM_DATA-0-0 SYS_TBS_MEM_DATA-1-0 SYS_TBS_MEM_DIC-0-0 SYS_TBS_MEM_DIC-1-0 USER_MEM_TBS-0-0 USER_MEM_TBS-1-0 이 파일들은 모두 메모리 테이블스페이스의 체크포인트 이미지 파일이다. 파일 이름의 형식은 ‘테이블스페이스이름-{Ping Pong번호}-{파일번호}’이다. ‘Ping Pong 번호’는 0 또는 1로, 이는 두 개의 체크포인트 이미지 중 핑퐁 체크포인트6시에 사용된 하나를 가리킨다. 또한, 각 체크포인트 이미지들을 여러 개의 파일로 나누어 기록하는데, 파일 이름의 맨 마지막 ‘파일번호’가 바로 나누어진 체크포인트 이미지 파일의 번호이며, 0부터 시작하여 1씩 증가한다. 체크포인트 이미지 파일 하나의 크기는 CREATE TABLESPACE 구문의 SPLIT EACH절에 지정된다. 위의 CREATE MEMORY TABLESPACE 구문에서는 SPLIT EACH절을 사용하지 않기 때문에, 기본값으로 DEFAULT_MEM_DB_FILE_SIZE프로퍼티에 지정된 1GB 단위로 체크포인트 이미지 파일들을 분할하게 된다. 위 세 개의 테이블스페이스에 사용된 공간이 아직 1GB에 도달하지 않았기 때문에, 파일번호는 0까지만 존재하는 것을 볼 수 있다. 위에서 SYS_TBS_MEM_DIC은 메타 데이터를 지니는 시스템 딕셔너리 테이블스페이스이다. 이 테이블스페이스는 데이터베이스 생성시 자동으로 만들어진다. SYS_TBS_MEM_DATA는 기본 시스템 데이터 테이블스페이스이다. 사용자가 테이블스페이스를 명시하지 않고 테이블을 생성할 때, 테이블의 데이터는 이 테이블스페이스에 저장된다. 6 알티베이스는 메모리 상에 존재하는 테이블스페이스의 데이터의 영속성(Durability) 보장을 위해 디스크의 파일에 데이터를 저장한다. 이와 같이 테이블스페이스의 데이터가 저장되는 파일을 체크포인트 이미지라고 한다. 알티베이스가 사용하는 핑퐁 체크포인트 방식은 두 벌의 체크포인트 이미지를 두고, 하나씩 번갈아 가면서 테이블스페이스의 데이터가 저장된다. 144 Administrator’s Manual 마지막으로, USER_MEM_TBS가 바로 앞서 생성한 사용자 정의 데이터 테이블스페이스이다. 참고로, CREATE MEMORY TABLESPACE 구문에서 SIZE절에 지정하는 초기 크기는 확장 증가 크기의 배수여야 한다. 예를 들어 메모리 테이블스페이스가 확장될 때 증가할 페이지의 개수를 지정하는 EXPAND_CHUNK_PAGE_COUNT프로퍼티의 값이 128이면, 하나의 메모리 페이지는 32KB 이므로, 메모리 테이블스페이스의 기본 확장 증가 크기는 4MB가 된다. 만약 SIZE절에 지정한 크기가 확장 증가 크기로 나누어 떨어지지 않을 경우, 다음과 같이 에러가 발생한다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 1M; [ERR-110EE : The initial size of the tablespace should be a multiple of expand chunk size ( EXPAND_CHUNK_PAGE_COUNT * PAGE_SIZE(32K) = 4096K )] 메모리 테이블스페이스 생성 - 종합 메모리 테이블스페이스의 다양한 생성 방법에 대해 알아본다. 다음은 테이블스페이스의 초기 크기를 256M, 자동확장 모드를 ON으로 하고 한번 확장시마다 128M씩 확장하되, 최대 1G이상 확장되지 않도록 하는 예제이다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M AUTOEXTEND ON NEXT 128M MAXSIZE 1G; Create success. 이 때, 테이블스페이스의 자동확장 증가 크기는 테이블스페이스의 초기 크기와 마찬가지로 (EXPAND_CHUNK_PAGE_COUNT 프로퍼티 * 한 페이지의 크기)의 배수로 설정되어야 한다. 자세한 내용은 ‘메모리 테이블스페이스의 생성 - 기본’을 참고한다. 다음과 같이 MAXSIZE를 제한하지 않도록 테이블스페이스를 생성할 수 있다. MAXSIZE절을 지정하지 않는 경우에 UNLIMITED를 지정한 것과 같이 동작한다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M AUTOEXTEND ON NEXT 128M MAXSIZE UNLIMITED; Create success. 이 경우 USER_MEM_TBS는 시스템에 존재하는 모든 메모리 테이블스페이스에 할당된 크기가 MEM_MAX_DB_SIZE를 벗어나지 않는 한도 내에서 확장된다. 다음과 같이 체크포인트 경로를 명시하여 메모리 테이블스페이스를 생성할 수도 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M 테이블스페이스 145 CHECKPOINT PATH 'dbs1', '/new_disk/dbs2'; Create success. 위의 예제처럼, 상대경로 dbs1을 체크포인트 경로로 지정하는 것은 $ALTIBASE_HOME/dbs1을 지정하는 것과 동일하다. 또한, CREATE TABLESPACE 구문에 지정한 체크포인트 경로를 실제로 파일 시스템에 생성하고, 거기에 쓰기와 실행 권한을 주는 작업은 테이블스페이스를 생성하기 전에 DBA가 수동으로 해야 한다. 다음과 같이 체크포인트 이미지 파일의 분할 크기를 결정할 수도 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M SPLIT EACH 512M; Create success. 체크포인트 이미지 파일의 분할 크기 역시 테이블스페이스의 초기크기와 마찬가지로 (EXPAND_CHUNK_PAGE_COUNT 프로퍼티 * 한 페이지의 크기)의 배수에 해당하는 크기로 지정되어야 한다. 자세한 내용은 ‘메모리 테이블스페이스의 생성 - 기본’편을 참고한다. 테이블스페이스를 오프라인(OFFLINE) 상태로 생성해두고, 나중에 해당 테이블스페이스를 사용하기 전에 온라인(ONLINE) 상태로 전이할 수도 있다. 메모리 테이블스페이스의 경우 생성된 크기만큼 시스템의 메모리를 차지하게 되므로, 생성 후 즉시 사용하지 않을 경우, 이와 같은 방법으로 시스템의 리소스를 최적으로 활용할 수 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M OFFLINE; Create success. iSQL> ALTER TABLESPACE USER_MEM_TBS ONLINE; Alter success. 지금까지 살펴본 메모리 테이블스페이스 생성 옵션을 조합하여 테이블스페이스를 생성할 수도 있다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M AUTOEXTEND ON NEXT 128M MAXSIZE 1G CHECKPOINT PATH 'dbs1', '/new_disk/dbs2' SPLIT EACH 512M OFFLINE; Create success. 메모리 테이블스페이스에 체크포인트 경로 추가 이 절에서는 메모리 테이블스페이스에 체크포인트 경로를 추가하는 절차에 대해 알아본다. 메모리 테이블스페이스를 위한 체크포인트 146 Administrator’s Manual 경로는 컨트롤(CONTROL) 구동 단계에서만 설정이 가능하다. 우선 알티베이스 서버를 종료 시킨 후에 다음과 같이 컨트롤 단계까지 알티베이스를 기동한다. $ isql -u sys -p manager -sysdba iSQL(sysdba)> startup process iSQL(sysdba)> startup control 컨트롤 단계에서는 테이블스페이스 관련 성능 뷰인 V$TABLESPACES를 조회할 수 있다. 메모리 테이블스페이스 특유의 속성들을 볼 수 있는 성능 뷰인 V$MEM_TABLESPACES는 메타(META) 단계 이후에만 조회가 가능하다. 대신, 컨트롤 단계에서는 V$TABLESPACES를 이용하여 메모리 테이블스페이스 조회가 가능하다. 앞서 생성한 USER_MEM_TBS 테이블스페이스를 위한 체크포인트 경로를 조회하기 위해서는 V$MEM_TABLESPACE_CHECKPOINT_PATHS성능 뷰를 이용하면 된다. 만약 테이블스페이스의 데이터가 빈번하게 변경되어 체크포인트시 디스크 I/O의 양이 증가했다면, 이는 다음과 같이 기존의 체크포인트 경로와 물리적으로 다른 디스크에 새로운 체크포인트 경로를 추가해서 경감시킬 수 있다. USER_MEM_TBS에 /new_disk/dbs3경로를 새로 추가해보자. 우선, 추가하고자 하는 체크포인트 경로와 디렉터리를 생성하고, 알티베이스 프로세스가 해당 디렉터리에 쓰기와 실행권한을 가지도록 권한을 설정해야 한다. 알티베이스 프로세스를 수행하는 운영체제의 사용자 계정이 altibase라고 가정한다. $ su - root $ mkdir /new_disk/dbs3 $ chown altibase /new_disk/dbs3 이제 다음과 같이 ADD CHECKPOINT PATH구문을 이용하여 체크포인트 경로를 추가할 수 있다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS ADD CHECKPOINT PATH '/new_disk/dbs3'; Alter success. 기존의 체크포인트 경로에 존재하는 체크포인트 이미지 파일들을 새로 추가된 체크포인트 경로로 이동시키는 것은 DBA의 책임이다. 알티베이스는 체크포인트 경로가 추가된 이후에 체크포인트가 발생할 경우, 새로 체크포인트 이미지 파일을 생성할 때, 추가된 테이블스페이스 147 체크포인트 경로에 체크포인트 이미지 파일을 생성한다.7 메모리 테이블스페이스의 체크포인트 경로 변경 이 절에서는 메모리 테이블스페이스의 체크포인트 경로를 변경하는 절차에 대해 알아본다. 메모리 테이블스페이스를 위한 체크포인트는 컨트롤(CONTROL) 구동 단계에서만 설정이 가능하다. 앞서 ‘메모리 테이블스페이스에 체크포인트 경로 추가’ 절에서 알아본 것과 같이 우선 알티베이스 서버를 종료 시킨 후에 컨트롤 단계까지 알티베이스를 기동한다. 본 예제는 기존의 체크포인트 경로인 알티베이스 홈 디렉터리의 dbs1을 새로 설치한 디스크인 /new_disk로 옮기는 절차를 보여준다. 체크포인트 경로를 변경하기 위해서는 기존의 체크포인트 경로를 절대경로로 정확히 입력해 주어야 한다. 컨트롤 단계에서 테이블스페이스의 체크포인트 경로를 보는 방법은 위의 ‘메모리 테이블스페이스에 체크포인트 경로 추가’절을 참고한다. 체크포인트 경로를 변경할 때에는 체크포인트 경로를 추가할때와 마찬가지로 다음과 같이 변경할 체크포인트 경로와 디렉터리를 DBA가 직접 생성하고, 그 디렉터리에 대한 쓰기 및 실행 권한을 알티베이스 프로세스를 수행하는 OS 사용자 계정에 부여해야 한다. 알티베이스 프로세스를 수행하는 사용자 계정이 altibase라고 가정한다. $ su - root $ mkdir /new_disk/dbs1 $ chown altibase /new_disk/dbs1 이제, 다음과 같이 RENAME CHECKPOINT PATH를 이용하여 알티베이스 홈의 dbs1이라는 체크포인트 경로를 새로 추가한 디스크인 /new_disk/dbs1으로 변경할 수 있다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS RENAME CHECKPOINT PATH '/opt/altibase_home/dbs1' TO '/new_disk/dbs1'; Alter success. 마지막으로 기존의 알티베이스 홈 디렉터리의 dbs1안의 USER_MEM_TBS테이블스페이스의 체크포인트 이미지들을 모두 /new_disk/dbs1으로 옮겨주어야 한다. $ mv $ALTIBASE_HOME/dbs1/USER_MEM_TBS* /new_disk/dbs1 7 체크포인트시 테이블스페이스의 체크포인트 이미지 파일을 새로 생성할 경우 테이블스페이스에 속한 각각의 모든 체크포인트 경로를 하나씩 번갈아가면서 사용한다. 148 Administrator’s Manual 메모리 테이블스페이스의 체크포인트 경로 제거 이 절에서는 메모리 테이블스페이스의 체크포인트 경로를 제거하는 절차에 대해 알아본다. 메모리 테이블스페이스를 위한 체크포인트는 컨트롤(CONTROL) 구동 단계에서만 설정이 가능하다. 앞서 ‘메모리 테이블스페이스에 체크포인트 경로 추가’절에서 알아본 것과 같이 우선 알티베이스 서버를 종료 시킨 후 컨트롤 단계까지 알티베이스를 기동한다. 본 예제는 기존의 체크포인트 경로인 알티베이스 홈 디렉터리의 dbs2를 제거하는 절차를 보여준다. 체크포인트 경로를 변경하기 위해서는 기존의 체크포인트 경로를 절대경로로 정확히 입력해 주어야 한다. 컨트롤 단계에서 테이블스페이스에 속한 체크포인트 경로를 보는 방법은 위의 ‘메모리 테이블스페이스에 체크포인트 경로 추가’절을 참고한다 이제, 다음과 같이 DROP CHECKPOINT PATH 명령을 이용하여 알티베이스 홈 디렉터리의 dbs2라는 체크포인트 경로를 제거할 수 있다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS DROP CHECKPOINT PATH '/opt/altibase_home/dbs2' Alter success. 마지막으로 기존의 알티베이스 홈 디렉터리의 dbs2안의 USER_MEM_TBS테이블스페이스를 위한 체크포인트 이미지들을 USER_MEM_TBS의 다른 체크포인트 경로중 하나로 옮겨주어야 한다. $ mv $ALTIBASE_HOME/dbs2/USER_MEM_TBS* /new_disk/dbs1 메모리 테이블스페이스의 자동확장 설정 변경 이 절에서는 메모리 테이블스페이스의 자동확장 설정을 변경하는 절차에 대해 알아본다. 메모리 테이블스페이스 생성시 자동확장 구문을 명시하지 않으면, 기본으로 해당 테이블스페이스는 자동확장이 되지 않도록 설정된다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M; Create success. 이 때 자동확장을 하도록 설정하는 가장 간단한 구문은 다음과 같다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON; Alter success. 위 예에서 테이블스페이스는 메모리 테이블스페이스의 기본 테이블스페이스 149 확장단위인 EXPAND_CHUNK_PAGE_COUNT 프로퍼티에 설정한 페이지 개수에 해당하는 크기만큼씩 확장될 것이다. 또한 최대 크기로 UNLIMITED을 지정한 것과 같이 동작하여 시스템내의 모든 메모리 테이블스페이스의 현재 크기의 총합이 MEM_MAX_DB_SIZE 프로퍼티를 벗어나지 않는 한도내에서 테이블스페이스는 확장될 것이다. 메모리 테이블스페이스는 디스크 테이블스페이스와 달리, 체크포인트 이미지 파일을 DBA가 직접 관리할 필요가 없다. 자동확장이 필요한 경우 알티베이스가 체크포인트 이미지파일을 자동으로 생성하기 때문이다. 메모리 테이블스페이스의 확장단위를 지정하기 위해서는 다음과 같은 구문을 사용한다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON NEXT 128M; Alter success. 메모리 테이블스페이스의 최대 크기를 지정하기 위해서는 다음과 같은 구문을 사용한다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON MAXSIZE 1G; Alter success. 메모리 테이블스페이스의 확장 크기와 최대 크기를 함께 지정하기 위해서는 다음과 같은 구문을 사용한다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND ON NEXT 128M MAXSIZE 1G; Alter success. 메모리 테이블스페이스의 자동확장 설정을 끄기 위해서는 다음과 같은 구문을 사용한다. iSQL> ALTER TABLESPACE USER_MEM_TBS ALTER AUTOEXTEND OFF; Alter success. 메모리 테이블스페이스의 온라인(ONLINE) 및 오프라인(OFFLINE)으로의 전이 본 예제는 메모리 테이블스페이스를 온라인 상태에서 오프라인 상태로, 그리고 그 반대로 전이하는 방법을 보여준다. 알티베이스 메모리 테이블스페이스의 모든 데이터는 메모리에 적재된다. 이로 인하여 메모리 테이블스페이스가 사용중인 공간만큼 시스템의 메모리가 할당된다. 알티베이스는 이러한 메모리 사용을 DBA가 손쉽게 제어할 수 있도록, 메모리 테이블스페이스에 150 Administrator’s Manual 메모리를 할당하고 메모리를 반납할 수 있는 기능을 제공한다. 물론, 메모리 테이블스페이스의 메모리가 반납된 상황에서는 해당 테이블스페이스 안에 생성된 모든 객체를 일시적으로 사용할 수 없게 된다. 메모리 테이블스페이스의 메모리를 반납하기 위해서는 테이블스페이스를 오프라인으로 전이하면 된다. iSQL> ALTER TABLESPACE USER_MEM_TBS OFFLINE; Alter success. 추후 해당 메모리 테이블스페이스 안에 생성된 테이블을 사용하기 위해서는 다음과 같이 테이블스페이스를 온라인으로 전이한다. iSQL> ALTER TABLESPACE USER_MEM_TBS ONLINE; Alter success. 휘발성 테이블스페이스 휘발성 테이블스페이스 생성 기본적으로 휘발성 테이블스페이스 생성, 변경, 삭제 구문은 메모리 테이블스페이스의 생성, 변경, 삭제 구문과 거의 동일하다. 다만 체크포인트 이미지 파일 관련 구문은 사용할 수 없다는 차이점이 있다. 다음 구문으로 256M 크기의 휘발성 테이블스페이스를 생성할 수 있다. iSQL> CREATE VOLATILE DATA TABLESPACE USER_VOL_TBS SIZE 256M; Create success. 이 경우 테이블스페이스의 크기는 256MB로 고정되어 있어 자동확장은 불가능하다. 다음 구문은 자동 확장되는 테이블스페이스를 생성한다. iSQL> CREATE VOLATILE DATA TABLESPACE USER_VOL_TBS SIZE 256M AUTOEXTEND ON; Create success. 이 경우 테이블스페이스의 초기 크기는 256MB이지만 자동 확장 되며, VOL_MAX_DB_SIZE 프로퍼티의 값이 허용하는 만큼 확장될 수 있다. 자동 확장 단위는 4MB이다. 자동 확장 단위를 8MB로, 최대 512MB까지만 확장할 수 있게 하려면 다음 구문으로 생성하면 된다. iSQL> CREATE VOLATILE DATA TABLESPACE USER_VOL_TBS SIZE 256M AUTOEXTEND ON NEXT 8M MAXSIZE 512M; 테이블스페이스 151 Create success. 휘발성 테이블스페이스 변경 휘발성 테이블스페이스에 대해 자동 확장 모드, 자동 확장 단위, 최대 크기 등을 변경할 수 있다. 다음 구문은 자동 확장이 안되는 휘발성 테이블스페이스를 자동 확장 모드로 변경한다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND ON; Alter success. 위 구문을 이미 자동 확장 모드가 가능하도록 설정된 테이블스페이스에 사용하면 에러가 발생한다. 다음 구문은 자동 확장 모드로 바꾸면서 자동 확장 단위를 8MB로, 최대 512MB까지 확장할 수 있도록 변경한다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND ON NEXT 8M MAXSIZE 512M; Alter success. 다음 구문은 자동 확장 모드를 끈다. 이 구문은 자동 확장 모드가 켜진 테이블스페이스에 사용할 수 있다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND OFF; Alter success. 자동 확장 모드이면서 자동 확장 단위가 4MB인 테이블스페이스를 자동 확장 단위 8MB로 바꾸려면, 다음처럼 먼저 자동 확장 모드를 끈 후 다시 켜야 한다. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND OFF; Alter success. iSQL> ALTER TABLESPACE USER_VOL_TBS ALTER AUTOEXTEND ON NEXT 8M; Alter success. 테이블스페이스의 삭제(DROP) - 디스크, 메모리, 휘발성 공통 테이블스페이스 폐기(Discard) - 데이터가 손상된 테이블스페이스를 제거 이 절에서는 테이블스페이스를 폐기하는 절차에 대해 알아본다. DBA가 실수로 디스크 테이블스페이스의 데이터 파일이나 메모리 테이블스페이스의 체크포인트 이미지 파일을 삭제한 경우, 혹은 매체 오류로 인하여 해당 파일의 내용이 유실된 경우에 알티베이스 기동이 불가능해진다. 152 Administrator’s Manual 이런 경우에, 매체 복구를 통해서 해당 파일을 복원하는 방법을 먼저 생각해 볼 수 있다. 하지만 매체 복구는 아카이브 로깅이 수행되어 기존의 로그파일이 별도의 아카이브 공간에 모두 남아 있을 때에만 가능하다. 이와 같이 매체 복구가 불가능한 경우, 데이터 파일이나 체크포인트 이미지 파일이 유실된 특정 테이블스페이스를 ALTER TABLESPACE DISCARD 구문을 사용해서 폐기시켜 버리고 나머지 테이블스페이스들만으로 알티베이스를 기동할 수 있다. 테이블스페이스가 ALTER TABLESPACE DISCARD 구문을 이용하여 한 번 폐기되면, 그 안에 생성된 객체에 대한 접근이 불가능해지고, 추후 그 테이블스페이스에 대해 할 수 있는 액션은 그것을 제거(DROP)하는 것뿐이다. 그러므로 이 구문 사용시 신중해야 한다. 다음 예제는 메모리 테이블스페이스인 USER_MEM_TBS를 생성한 후, 체크포인트 이미지를 삭제한 상태에서 해당 테이블스페이스만 제외한 나머지 테이블스페이스들로 알티베이스를 기동하는 과정을 보여준다. 우선 다음과 같이 메모리 테이블스페이스를 생성한다. iSQL> CREATE MEMORY TABLESPACE USER_MEM_TBS SIZE 256M; Create success. 이제 알티베이스를 종료하고, 해당 테이블스페이스에 속한 체크포인트 이미지 파일을 지운다. 이제 알티베이스를 재기동하면 다음과 같은 에러가 발생한다. [SM-WARNING] CANNOT IDENTIFY DATAFILE [TBS:USER_MEM_TBS, PPID-0-FID-0] Datafile Not Found [SM-WARNING] CANNOT IDENTIFY DATAFILE [TBS:USER_MEM_TBS, PPID-1-FID-0] Datafile Not Found [FAILURE] The data file does not exist. Startup Failed.... [ERR-91015 : Communication failure.] 알티베이스는 이와 같이 일부 테이블스페이스의 데이터 파일이나 체크포인트 이미지 파일이 존재하지 않는 경우 에러를 발생시킨다. 이제 USER_MEM_TBS를 디스카드 할 차례이다. 디스카드 구문은 컨트롤(CONTROL) 단계에서만 수행이 가능하다. 알티베이스를 컨트롤 단계까지 기동한다. $ isql -u sys -p manager -sysdba iSQL(sysdba)> startup control 테이블스페이스 153 이제 체크포인트 이미지 파일이 유실된 테이블스페이스 USER_MEM_TBS를 디스카드 한다. iSQL(sysdba)> ALTER TABLESPACE USER_MEM_TBS DISCARD; Alter success. 그리고 다음과 같이 STARTUP SERVICE명령을 수행하여 알티베이스를 서비스 단계로 진입시킨다. iSQL(sysdba)> startup service Command execute success. 디스카드 명령은 해당 테이블스페이스를 버리겠다고 선언하는 것에 불과하다. 그렇기 때문에 해당 테이블스페이스 및 그 안의 객체는 DROP TABLESPACE INCLUDING CONTENTS 구문을 이용하여 직접 제거하여야 한다. iSQL> DROP TABLESPACE USER_MEM_TBS INCLUDING CONTENTS AND DATAFILES; Drop success. 마찬가지로 디스크 테이블스페이스의 데이터 파일이 유실되거나, 매체 오류 때문에 데이터 파일의 내용중 일부가 깨진 경우에도 해당 테이블스페이스를 디스카드시키는 방법으로 알티베이스를 가동할 수 있다. 테이블스페이스의 제거 본 사용예에서는 테이블스페이스를 제거하는 방법을 보여준다. 테이블스페이스 안에 어떠한 객체도 생성되어 있지 않은 경우, 다음과 같이 간편하게 테이블스페이스를 제거할 수 있다. 단, 이 경우 디스크 테이블스페이스의 데이터 파일과 메모리 테이블스페이스의 체크포인트 이미지 파일은 파일 시스템에서 제거되지 않는다. iSQL> DROP TABLESPACE MY_TBS; Drop success. 만약, 테이블스페이스 안에 객체가 존재한다면 다음과 같이 INCLUDING CONTENTS절을 주어서 테이블스페이스 안의 모든 객체가 삭제되도록 한다. 이 경우에도 데이터 파일이나 체크포인트 이미지 파일이 파일 시스템에서 삭제되지는 않는다. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS; Drop success. 만약 삭제하고자 하는 테이블스페이스 안의 테이블을 참조하는 다른 테이블스페이스의 테이블들로부터 참조 제약(Referential 154 Administrator’s Manual Constraint)를 제거 하려면 다음과 같이 INCUDING CONTENTS절과 함께 CASCADE CONSTRAINTS를 함께 주면 된다. 이 경우에도 데이터 파일이나 체크포인트 이미지 파일이 파일 시스템에서 삭제되지는 않는다. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS CASCADE CONSTRAINTS; Drop success. 디스크 테이블스페이스의 데이터 파일이나 메모리 테이블스페이스의 체크포인트 이미지 파일을 삭제하려면 다음과 같이 INCLUDING CONTENTS절 바로 뒤에 AND DATAFILES절을 주면 된다. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS AND DATAFILES; Drop success. iSQL> DROP TABLESPACE MY_TBS INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS; Drop success. 테이블스페이스 155 테이블스페이스 공간 관리 이 절에서는 알티베이스의 테이블스페이스 공간을 관리하는 방법에 대하여 설명한다. 언두 테이블스페이스 크기 계산 언두 테이블스페이스(Undo Tablespace)는 언두 세그먼트를 저장하기 위해 사용된다. 언두 테이블스페이스가 부족할 경우 트랜잭션 성능에 영향을 줄 수 있으므로 DBA는 이를 적절한 크기로 관리해야 한다. 만약 업무 시스템에서 변경 트랜잭션, 특히 오랜 시간동안 구문이 실행되는 트랜잭션이 자주 발생하는 경우에는 언두 세그먼트가 계속 확장될 것이다. 이는 언두 테이블스페이스의 공간 부족을 초래할 수 있다. 사용자는 언두 테이블스페이스를 자동 확장 모드로 설정하거나, 대략적인 최대 크기를 예측하여 그 예측치를 최대 크기로 지정한 고정 크기 모드로 설정할 수 있다. 언두 테이블스페이스의 자동 확장 모드 사용자가 처음으로 애플리케이션을 수행하는 경우 얼마만큼의 언두 테이블스페이스 공간이 필요한지 알기가 쉽지 않다. 이런 경우에는 언두 테이블스페이스의 자동 확장 모드를 활성화하여 필요한 공간까지 자동으로 확장되도록 한다. 알티베이스는 애플리케이션 개발 환경에서 언두 테이블스페이스의 용량을 계획하기 쉽도록 자동 확장 모드를 제공한다. 기본적으로 언두 테이블스페이스는 자동 확장 모드로 설정되며, ALTER TABLESPACE 구문으로 변경할 수 있다. 언두 테이블스페이스의 고정 크기 모드 사용자가 고정 크기의 언두 테이블스페이스를 사용하고 싶다면, 필요한 용량을 예측해야 한다. 이를 위해서 사용자는 애플리케이션이 수행되는 동안 사용되는 TSS 세그먼트 공간과 언두 세그먼트 공간의 사용 패턴을 수집하여 분석해야 한다. 필요한 언두 테이블스페이스 크기는 일반적으로 다음과 같은 계산식으로 대략적인 산출이 가능하다. 156 Administrator’s Manual 언두 테이블스페이스 크기 = Long-Term 트랜잭션 수행 시간(sec) x (초당 할당되는 언두 페이지 개수 + 초당 할당되는 TSS 페이지 개수) x 페이지 크기(8KB) 예를 들어 Long-Term 트랜잭션의 수행 시간이 600초(10분)이고 초당 언두 페이지 1000개와 TSS 페이지 24개가 할당된다면, 10 x 60 x (1000 + 24) x 8K = 4800MB이므로 약 4.7G 정도가 필요하다. 이와 같이 예측하는 것이 어렵다면, 디스크 공간이 허락하는 한 충분히 넉넉한 크기를 언두 테이블스페이스에 할당하는 것도 방법이다. 언두 테이블스페이스의 확장 업무 시스템에서 변경 트랜잭션 (특히 Long-Term 트랜잭션, 즉 트랜잭션이 커밋되기까지 긴 시간이 소요되는 트랜잭션)이 자주 발생하는 경우에 언두 테이블스페이스의 공간 부족이 발생할 수 있다. 이러한 경우에 ALTER TABLESPACE 구문을 이용하여 언두 테이블스페이스에 적정한 크기의 데이터 파일을 추가하거나 파일의 크기를 적당히 늘려준다. 메모리 테이블의 크기 추정 데이터 크기 계산 메모리 테이블의 데이터 크기는 각 칼럼의 데이터 타입, 칼럼 정렬 (alignment)를 위한 패딩(padding) 등에 기반해서 예측이 가능하다. 수학 공식으로 표현하면 다음과 같다: 데이터 크기 = [ (각 칼럼의 추정 크기의 합 + 각 칼럼을 위한 패딩 크기의 합) * 데이터 레코드 개수] 데이터 타입 별 추정 크기는 다음 표에서 보여준다. P = Precision, V = Value length) 자료형 예측 칼럼 크기 INTEGER 4 SMALLINT 2 BIGINT 8 DATE 8 DOUBLE 8 테이블스페이스 157 CHAR 2 + P VARCHAR 10 + V NCHAR 2 + P NVARCHAR 10 + V BIT 4 + (P/8) VARBIT 12 + (P/8) FLOAT 4 + (P/2)/2 NUMERIC 12 + (P/2)/2 위 도표에서 P(Precision)는 테이블 생성시 결정된 칼럼의 크기를 가리킨다. P보다 긴 데이터는 해당 데이터 타입의 칼럼에 입력될 수 없다. V(Value length)는 입력된 데이터의 실제 길이로, V는 P보다 클 수 없다. CHAR, NCHAR, BIT 타입 같은 고정 길이 칼럼은 P 만큼의 공간을 항상 점유하므로, 칼럼의 길이는 데이터의 실제 길이에 상관없이 고정된다. 그러나 VARCHAR, NVARCHAR, VARBIT같은 가변 길이 칼럼은 점유하는 공간이 데이터 길이에 따라서 가변적이다. 디스크 테이블과 달리, 메모리 테이블은 데이터 접근 속도를 높이기 위한 패딩 공간을 포함한다. 이 공간의 크기는 데이터 타입과 칼럼의 위치에 따라서 가변적이다. 인덱스 크기 추정 메모리 인덱스는 테이블 데이터가 저장되는 테이블스페이스에 저장되지 않는다. 대신에 이는 메모리 공간에 독립적으로 저장된다. 데이터 저장 위치를 가리키는 포인터가 메모리 인덱스 노드의 각 버킷에 저장되기 때문에, 인덱스 크기는 데이터 타입에 상관없이 포인터 크기와 테이블에 현재 저장된 레코드의 개수에 기반하여 추정할 수 있다. 인덱스 크기 = (데이터 레코드의 개수) * p ( p = 포인터 크기 ) 위 공식에서 p는 포인터 크기, 즉 한 포인터를 저장하는데 필요한 크기이다. 32-bit 시스템에서는 이 크기가 4바이트이고, 64-bit 시스템에서는 이 크기가 8바이트이다. 이 공식에서, 인덱스의 크기는 모든 리프 노드 (즉, B트리의 최하위의 노드)의 총 크기만큼이다. 리프 노드에 더해서 B트리에는 인터널 노드 (즉, 리프 노드의 상위 노드)가 있는데, 이의 총 크기는 리프 노드 크기의 1/128 에 불과하므로 무시해도 된다. 인덱스 관리에 사용되는 추가 정보를 저장하는 크기도 리프 노드 크기의 1/16 정도로 무시할만큼 작다. 그러므로 모든 리프 노드의 총 크기에 기반해서 인덱스의 총 크기를 계산하면 된다. 158 Administrator’s Manual 그러나 이 공식은 리프 노드의 모든 버킷이 그 안에 키 값을 가지고 있는 상황만을 고려한 것이기 때문에, 이 공식을 이용해서 추정된 값은 인덱스의 실제 크기와 다를 수 있다. 즉, 노드 내에 빈 버킷이 많이 있다면 인덱스의 실제 크기는 추정된 크기보다 많이 클 수 있다. 이 경우 인덱스 재구축을 통해서 인덱스 크기를 줄일 수 있다. 예제 1 아래처럼 테이블이 생성된 경우 데이터 크기를 추정해 보자. CREATE TABLE T1 ( C1 Integer, C2 char(1024), C3 varchar(1024) ) tablespace user_data01; 이 테이블의 칼럼 C1과 칼럼 C2는 고정 길이 칼럼이고 C3는 가변 길이 칼럼이다. 그러므로 한 레코드의 크기는 칼럼 C3에 따라 변할 것이다. 이를 고려하여 한 레코드의 크기를 계산하면, 아래처럼 T1테이블의 데이터 크기는 (한 레코드 크기 * 레코드 개수)와 같다. [record header] = 24 bytes [column C1] = 4 bytes [column C2] = 2+P bytes = 2+1024 bytes [column C3] = 10+V bytes 칼럼 C3의 데이터 길이가 200바이트이면: [record size] = 24 + ( 4 ) + (2+1024) + (10+200) + padding = (1264 + padding) bytes 칼럼 C3의 데이터 길이가 200바이트이면: [record size] = 24 + ( 4 ) + (2+1024) + (10+500) + padding = (1564 + padding) bytes 예제 2 아래 구문으로 생성된 테이블 T1의 인덱스 크기를 계산해 보자. 테이 블 T1에는 현재 500,000 레코드가 있고, 시스템은 64-bit이다. CREATE TABLE T1 ( C1 Integer, C2 char(300), C3 varchar(500)) tablespace user_data01; CREATE INDEX T1_IDX1 ON T1( C1, C2, C3 ); [index size] = 500,000 records * 8 = 3.814 Megabytes 예제 3 아래 구문으로 생성된 테이블의 데이터와 인덱스 크기를 계산해 보 자. 테이블에는 현재 1,000,000 레코드가 있고, 시스템은 64-bit이 다. 테이블스페이스 159 CREATE TABLE TEST001 ( C1 char(8) primary key, C2 char(128), N1 integer, IN_DATE date) tablespace user_data01; 한 레코드의 크기와 총 데이터 크기 [The size of a record] = 24[header size] + (2+8) + (2+128) + (4) + (8) = 176 bytes [The total size of all records] = [ 176 ] * 1,000,000 records = 167.84 Mbytes 인덱스 크기 [total index size] = 8 * 1,000,000 records = 7.629 Megabytes 이 값은 데이터 크기와 리프 노드의 크기에 기반해서 계산되었기 때문에, 실제로는 페이지 헤더, 인덱스 노드, 그리고 프리 (free) 페이지 관리를 위한 메모리에 사용되는 추가 공간이 있을 것이다. 디스크 테이블의 크기 추정 알티베이스의 디스크 테이블 크기는 자료형과 데이터의 구성을 바탕으로 계산할 수 있으며 [테이블 로우의 총 길이 * 데이터 건 수] 의 값을 가진다. 다음 표는 자료형 별 길이를 보여준다. (P = Precision, V = Value length) 자료형 추정되는 칼럼 크기 Null 250바이트 이하 251바이트 이상 Integer 1 5 X SmallInt 1 3 X BigInt 1 9 X Date 1 9 X Double 1 9 X Char 1 1+P 3+P Varchar 1 1+V 3+V NChar 1 1+P 3+P NVarchar 1 1+V 3+V Bit 1 5+(P/8) 7+(P/8) Varbit 1 5+(V/8) 7+(V/8) Float 1 4+(V+2) / 2 6 +(V+2) / 2 Numeric 1 4+(V+2) / 2 6 +(V+2) / 2 160 Administrator’s Manual 위 도표에서 P(Precision)는 테이블 생성시 결정된 칼럼의 최대 크기이다. P 보다 큰 길이를 갖는 데이터는 그 타입의 칼럼에 입력되지 않는다. 또한 고정길이 칼럼인 CHAR, NCHAR, BIT 등은 항상 P 만큼의 공간을 점유하기 때문에, 데이터의 길이와 상관없이 칼럼의 길이는 일정하다. V(Value length)는 실제로 삽입된 데이터의 실제 길이로, P보다 클 수 없다. 또한 가변 길이 칼럼인 VARCHAR, NVARCHAR, VARVIT등은 데이터의 크기에 따라 점유하는 공간의 크기가 달라진다. 따라서 데이터의 크기에 따라 칼럼의 크기가 변한다. 로우(row) 크기 추정 이 절에서는 테이블 스키마가 다음과 같을 경우, 로우 크기를 계산하는 방법에 대해 설명한다. CREATE TABLE T1 ( C1 char(32), C2 char(1024), C3 varchar(512) ) tablespace user_data02; 이 스키마에서 C1 칼럼과 C2 칼럼은 고정길이 칼럼이며, C3 칼럼은 가변길이 칼럼이다. 따라서 C3 칼럼의 크기에 따라 로우의 크기가 변 한다. 또한 칼럼에 널(NULL)이 존재하는지 여부에 따라 로우의 크기 가 변한다. 이를 고려하여 로우의 크기를 계산하면 아래와 같으며, 테이블 T1의 크기는 (한 로우의 총 길이 * 데이터 건 수)가 된다. [로우 헤더] 34 바이트 [C1 칼럼] 1+P 바이트 = 1+32 바이트 [C2 칼럼] 3+P 바이트 = 3+1024 바이트 [C3 칼럼] 3+V 바이트 C3 칼럼의 데이터 크기가 200 바이트인 경우 [총 길이] 34 + (1+32) + (3+1024) + (3+200) = 1297 바이트 C3 칼럼의 데이터 크기가 500 바이트인 경우 [총 길이] 34 + (1+32) + (3+1024) + (3+500) = 1597 바이트 C2 칼럼이 널이고, C3 칼럼의 데이터 크기가 300 바이트인 경우 [총 길이] 34 + (1+32) + (1) + (3+300) = 371 바이트 C3 컬림이 널인 경우 [총 길이] 34 + (1+32) + (3+1024) + (0) = 1094 바이트 인덱스(index) 크기 추정 인덱스의 크기 역시 자료형과 데이터의 구성을 바탕으로 계산할 수 있다. 다음 표는 인덱스 크기 계산 시 사용할 자료형 별 길이를 테이블스페이스 161 보여준다. (P = Precision, V = Value length) 자료형 인덱스 키의 크기 Null 250바이트 이하 251바이트 이상 Integer 4 4 X SmallInt 2 2 X BigInt 8 8 X Date 8 8 X Double 8 8 X Char 1 1+P 3+P Varchar 1 1+V 3+V NChar 1 1+P 3+P NVarchar 1 1+V 3+V Bit 1 5+(P/8) 7+(P/8) Varbit 1 5+(V/8) 7+(V/8) Float 1 4+(V+2) / 2 6+(V+2) / 2 Numeric 1 4+(V+2) / 2 6+(V+2) / 2 위 도표에서 P(Precision)와 V(Value length)는 각각 테이블 생성시 결정된 칼럼의 최대 크기와 실제로 삽입된 데이터의 크기를 의미한다. 한 인덱스의 크기는 다음과 같다. [ 10(헤더 길이) + (키 칼럼 길이의 합) ] * 데이터 건 수 위의 계산 공식은 leaf node (B*Tree에서 최하위의 노드)의 대략적인 크기이다. 이 외에 internal node(leaf node의 상위 노드)의 크기의 경우, 키 칼럼(key column)의 크기가 작을 경우에는 무시할 수 있을 정도로 그 크기가 작다. 하지만 키 칼럼의 크기가 2K이상일 경우에는 B*Tree의 깊이가 깊어지고, internal node의 크기가 전체 Leaf Node 크기의 50% 정도까지 될 수 있으므로 이런 경우에는 internal node의 크기를 계산에 포함해야 한다. 다음은 테이블 및 인덱스의 스키마가 다음과 같을 경우, 인덱스의 크기를 계산하는 방법을 보여준다. CREATE TABLE T1 ( C1 Integer, C2 varchar(500)) tablespace user_data02; CREATE INDEX T1_IDX1 ON T1( C1, C2 ); C1 칼럼은 Integer 형이므로 항상 4 byte로 크기가 결정된다. C2는 가변길이 칼럼으로 데이터의 크기에 따라 길이가 가변적으로 변한다. 162 Administrator’s Manual [ 키 헤더 ] 1 0 b y t e [ C 1 칼럼 ] 4 b y t e [ C 2 칼럼 ] 1 + V b y t e C2 칼럼의 데이터 크기가 50 바이트인 경우 [총 길이] 10 + 4 + (1+50) = 65 바이트 C2 칼럼의 데이터 크기가 500 바이트인 경우 [총 길이] 10 + 4 + (3+500) = 517 바이트 C2 칼럼이 널인 경우 [총 길이] 10 + 4 + 1 = 15 바이트 테이블 크기 계산 예제 테이블 스키마가 다음과 같고 데이터 건 수가 100만 건일 경우에, 로우의 크기와 인덱스의 크기를 포함한 테이블의 크기를 다음과 같이 계산한다. CREATE TABLE TEST001 ( C1 char(8) primary key, C2 char(128), N1 integer, IN_DATE date) tablespace user_data02; 로우 크기 및 전체 데이터 크기 로우 크기: 34[헤더] + (1+8) + (1+130) + (1+4) + (1+8) = 188 바이트 전체 데이터 크기: [ 188 ] * 100만 건 = 179.29 M 바이트 인덱스 크기 한 로우의 인덱스 크기: 10[헤더] + (1+8)[C1] = 19 바이트 전체 인덱스 크기: 19 * 100만건 = 18.12 M 바이트 TEST001 테이블 전체가 차지하는 디스크 크기 179.29 (데이터 크기) + 18.12(인덱스 크기) = 197.41 M 바이트 이것은 데이터의 크기만 계산한 것으로, 실제로는 페이지 헤더, internal node, 세그먼트 관리 영역 등을 추가로 사용하며 그만큼 공 간을 더 사용한다. 이러한 부분을 고려하면, 총 테이블 스페이스는 약 240M 바이트를 사용하게 될 것이다. 테이블 저장 공간 계산 위에서 테이블의 크기 계산에 사용된 테이블 TEST001을 기준으로 테이블의 레코드와 인덱스를 모두 저장할 수 있는 테이블의 적정 테이블스페이스 163 사이즈를 계산한다. 적정한 테이블 크기를 계산하기 위해서 다음과 같은 사항을 고려해야 한다. 트랜잭션의 유형의 상대 빈도를 고려한다 특정 테이블에 대하여 갱신 (Update) 트랜잭션이 많이 발생할 경우에는 트랜잭션의 성능을 높이기 위해 PCTFREE를 크게 하고, PCTUSED를 작게 하여 변경 작업을 위해 필요한 빈 공간(free space)을 많이 확보하는 것이 좋다. 변경 트랜잭션이 적고 입력(Insert) 트랜잭션이 주로 발생하는 테이블의 경우에는 반대로 PCTFREE를 작게하고, PCTUSED를 크게 하여 불필요한 빈 공간(free space)을 최소화해야 한다. PCTFREE 기본값은 10으로, 디스크 테이블 생성시 0에서 99 사이의 값을 명시할 수 있다. 이는 테이블의 각 페이지에서 기존 레코드에 대한 변경 연산 등을 위하여 미리 예약한 여유 공간의 비율이다. 따라서 PCTFREE가 10이고 입력(Insert) 트랜잭션만 발생한다고 가정할 경우에 테이블의 전체 크기가 100M 라면 테이블의 레코드와 인덱스를 위해 사용될 수 있는 공간은 90M가 된다. PCTUSED 기본값은 40이며 디스크 테이블 생성시 0에서 99 사이의 값을 명시할 수 있다. 특정 페이지가 PCTFREE에서 명시한 비율에 도달한 후에 변경과 삭제로 인해서 빈 공간의 비율이 40% 미만(39%)으로 될 때까지 해당 페이지에는 삽입 연산이 일어나지 않는다. 따라서 변경이 많이 발생하는 테이블일 경우에는 테이블의 크기를 산정할 때 여유 공간을 많이 확보해야 한다. 상황 테이블 사이즈 계산 대부분이 Read Only 트랜잭션이거나 UPDATE 시에 레코드 의 크기가 증가 되지 않 을 경우 PCTFREE를 5로 지정하고, PCTUSED를 90으 로 지정한 경우 ① 최소 테이블 크기 계산: TEST001(전체사이즈=215.53M)테이블을 저장 하기 위해서 필요한 최소 사이즈는 다음과 같은 공식으로 계산한다. 테이블 전체 사이즈 / [1-(PCTFREE / 100)] = 215.53/0.95 ≒ 227M ② 가중치 계산: 최소 사이즈에 적절한 크기의 가중치를 추가한 다. 가중치는 시스템 상황에 따라 달라질 수 있 다. 다음은 가중치 계산의 한가지 예이다. 164 Administrator’s Manual 최소사이즈 * [ 1- (PCTUSED / 100) ] * 2 = 227 * 0.1 * 2 ≒ 45M ③ 따라서 테이블을 총 272M 정도의 사이즈로 생성한다. UPDATE가 빈번하고, UPDATE 시에 레코드 의 크기가 증가될 경우 PCTFREE를 20으로 지정하고, PCTUSED를 40으로 지정한 경우 ① 최소 테이블 크기 계산: TEST001(전체사이즈=213.63M)테이블을 저장 하기 위해서 필요한 최소사이즈는 다음과 같은 공식으로 계산한다. 테이블전체사이즈 / [1-(PCTFREE / 100) = 213.63/0.8 ≒ 267M ② 가중치 계산: 최소 사이즈에 적절한 가중치를 추가한다. 다음 은 가중치 계산의 한가지 예이다. 최소 사이즈 * [ 1- (PCTUSED / 100) ] * 2 = 267 * 0.6 * 2 ≒ 320M ③ 따라서 테이블을 총 587M 정도의 사이즈로 생성한다. INSERT와 UPDATE 가 자주 발생하지만 UPDATE를 할 때 레코 드의 크기가 증가되지 않을 경우 PCTFREE를 10으로 지정하고, PCTUSED를 60으로 지정한다. [표 6-3]트랜잭션 유형의 상대 빈도에 따른 테이블 크기 계산 Note: 위의 표에서 설명한 테이블의 사이즈 계산은 절대적인 기준이 아니다. 시스템이 비정상 동작하여 데이터가 갑자기 증가하는 등의 장애 상황에 대한 고려가 필요하다. 적정한 백업 사이즈를 고려한다. 실제 업무에서 하나의 테이블스페이스에 하나의 테이블만 저장되는 경우는 드물다. 업무단위 또는 백업단위로 테이블을 묶어서 하나의 테이블스페이스에 생성하는 것이 더 효율적이다. 이 경우 테이블스페이스에 대한 백업 소요 시간 등을 고려하여 한 개 테이블스페이스의 적정사이즈를 설정해야 한다. 다음 그림은 데이터베이스 내에서 테이블스페이스를 업무단위 및 백업사이즈를 고려하여 적정사이즈로 분리하여 생성한 것을 보여준다. 테이블스페이스 165 [그림 6-15] 백업을 고려한 테이블스페이스 테이블스페이스 정보 알티베이스는 테이블스페이스를 관리하기 위해서 테이블스페이스의 상태를 점검하거나 모니터링 하기 위한 성능 뷰와 메타 테이블을 제공한다. SYSTEM_.SYS_TBS_USERS_ 또한 다음의 성능 뷰를 통해 사용자들이 사용하는 데이터베이스의 크기, 사용량, 상태 등의 정보를 확인할 수 있다. V$TABLESPACES, V$DATAFILES, V$MEM_TABLESPACES DB VERSION TBS_SALES INVOICE COMP PRODUCT DEPT TBS_CUSTS ORDER EMP PROJ 2G 1G 파티션드 객체 167 7. 파티션드 객체 168 Administrator’s Manual 파티셔닝 정의 파티셔닝(partitioning)은 더 쉬운 관리를 위하여 대용량 데이터베이스 객체를 여러 개의 작은 조각으로 분할하는 것을 말한다. 파티셔닝으로 분할된 대용량 데이터베이스 객체를 “파티션드 객체 (partitioned object)”라고 하고, 파티션드 객체가 갖는 분할된 작은 조각을 “파티션 (partition)”이라고 한다. 파티션드 객체와 논파티션드 객체 일반 사용자(end user)가 파티션드 객체를 이용할 때 논파티션드 객체(non-partitioned object)와 차이를 알아채지 못한다. 즉, 사용자 입장에서는 파티션드 객체와 논파티션드 객체는 데이터베이스 객체로 인식될 뿐이지, 해당 객체의 파티션 유무는 인식하지 못하기 때문이다. 따라서 사용자는 객체의 파티션 유무에 관계없이 질의 및 DML(레코드 삽입, 삭제, 갱신) 등의 구문을 동일한 방법으로 사용할 수 있다. 파티션드 객체와 논파티션드 객체의 차이점을 데이터베이스 구조적 측면에서 살펴보면 다음과 같다. 내부 구조 논파티션드 객체는 하나의 테이블스페이스에 종속된 객체로, 하나의 논파티션드 객체는 하나의 테이블스페이스에만 저장된다. 파티션드 객체는 다수의 테이블스페이스에 걸쳐 저장될 수 있다. 이는 [그림 6-1]으로 설명된다. 테이블 스페이스 테이블 스페이스 논파티션드 객체 A 파티션드 객체 A 논파티션드 객체 B 파티션드 객체 C파티션드 객체 B [그림 7-1] 테이블스페이스, 파티션드 객체 및 논파티션드 객체의 관계 파티션드 객체는 내부적으로 다수의 파티션으로 이루어진다. 각 파티션드 객체 169 파티션은 논파티션드 객체와 같은 제약 조건을 가지며, 하나의 파티션은 하나의 테이블스페이스에만 종속된다. 이러한 다수의 테이블스페이스에 존재하는 파티션을 하나의 객체로 인식하게 만드는 것이 파티션드 객체이다. [그림 6-2]는 파티션드 객체의 내부구조를 보여준다. 테이블 스페이스 테이블 스페이스 파티션드 객체파티션드 객체파티션드 객체 파티션 [그림 7-2] 파티션드 객체의 내부구조 파티션드 객체의 장점 이런 구조상의 특징으로 인해 파티션드 객체는 다음과 같은 장점들을 갖는다. 데이터 로딩 및 인덱스 재구축(rebuilding)이 빠르다. 부분 삭제(partial delete)가 빠르다. 테이블 스캔(table scan) 및 인덱스 스캔(index scan)이 빠르다. 디스크 붕괴(disk failure)에 유연하다. 파티션 키 파티션 키(Partition Key)는 테이블을 분할하는 기준이다. 파티션 키는 분할될 테이블의 하나 이상의 칼럼으로 구성된다. 이러한 칼럼들을 파티션 키 칼럼(partition key columns)이라고 한다. 파티션 키 칼럼은 반드시 대소 비교(<, >, =)가 가능한 데이터 타입이어야 하며, 이러한 칼럼만이 파티션 키 칼럼으로 선정될 수 있다. 예를 들어 레코드 삽입시, 삽입될 레코드가 어떤 파티션에 저장되어야 하는지 명확해야 한다. 이를 만족하기 위해서는 파티션 키 칼럼과 과련 조건간의 명확한 대소비교가 가능해야 한다. 따라서, 170 Administrator’s Manual BINARY, GEOMETRY, BLOB, 및 CLOB 등과 같은 대소 비교가 불가능한 타입은 파티션 키 칼럼이 될 수 없다. 파티션드 객체 171 파티션드 객체 데이터베이스 객체중 테이블과 인덱스는 파티션이 될 수 있는 객체이다. 테이블이 분할 되는 경우 해당 테이블을 “파티션드 테이블 (partitioned table)”이라고 하며, 인덱스가 분할 되는 경우는 “파티션드 인덱스 (partitioned index)”라고 한다. 이러한 파티션드 테이블과 파티션드 인덱스를 “파티션드 객체( partitioned object)”라고 한다. 파티션드 객체는 반드시 다음과 같은 규칙을 만족시켜야 한다. non-partitioned_object ≡ ∑partition……………………rule1 위의 규칙은 논파티션드 객체 (non-partitioned_object)는 이를 분할한 파티션의 합과 동치여야 함을 의미한다. 즉, 논파티션드 객체의 일부분만을 파티션시킬 수 없다. 파티션드 테이블 “파티션드 테이블 (Partitioned Table)”은 파티셔닝 조건 (범위, 리스트, 해시)에 따라 다수의 파티션으로 분리한 대용량 테이블을 의미한다. 이는 [그림 6-3]로 설명된다. [그림 6-3]은 논파티션드 테이블을 색깔(color)을 기준으로 분할하였으며, 결과적으로 파티션 3개로 구성된 파티션드 테이블이 된다. 파티션드 테이블은 구조적 측면에서 기존 데이터베이스 객체중 유니온 뷰(Union View)와 비슷한 개념을 갖는다. 유니온 뷰는 다수의 테이블들을 하나의 객체로 인식하기 위해서 논리적으로 유니온 시킨 것뿐이며, 어떠한 물리적 공간을 차지하지는 않는다. 이와 마찬가지로 파티션드 테이블에 참여하는 파티션들이 물리적인 공간을 가지는 것뿐이지 파티션드 테이블 자체가 물리적 공간을 갖는 것은 아니다. 유니온 뷰와 규별되는 파티션드 테이블의 몇 가지 특징은 다음과 같다. 갱신 가능성 파티션드 테이블은 갱신이 가능하다. 반면 유니온 뷰는 개별 테이블을 통한 레코드 갱신은 가능하지만, 유니온 뷰를 통한 레코드 갱신은 불가능하다. 인덱스 구축 범위 172 Administrator’s Manual 파티션드 테이블에는 인덱스를 구축할 수 있다. 그러나 유니온 뷰는 개별 테이블에는 인덱스를 구축할 수 있지만, 유니온 뷰에는 인덱스를 구축할 수 없다. 파티션드 테이블 논파티션드 테이블 파티셔닝 조건 (color) [그림 7-3] 파티션드 테이블과 논파티션드 테이블 결론적으로 파티션드 테이블은 레코드 갱신 및 인덱스 구축이 가능한 유니온 뷰 (updatable and indexable union view)라고 생각할 수 있다. 파티션드 테이블은 파티션들이 저장되는 매체의 종류에 따라서 다음과 같이 분류된다. 알티베이스는 파티션드 디스크 테이블만 지원한다. 파티션드 메모리 테이블 (Partitioned Memory Table): 모든 파티션들이 메모리 테이블스페이스에 저장된 파티션드 테이블 파티션드 디스크 테이블 (Partitioned Disk Table): 모든 파티션들이 디스크 테이블스페이스에 저장된 파티션드 테이블 파티션드 인덱스 파티션드 객체 173 파티션드 테이블을 위한 인덱스들을 다음과 같이 분류할 수 있다. 분할 여부에 따른 분류 파티션드 인덱스 vs. 논파티션드 인덱스 테이블과 인덱스 관계에 따른 분류 글로벌 인덱스 vs. 로컬 인덱스 파티션드 인덱스와 논파티션드 인덱스 인덱스는 그 분할 여부에 따라 파티션드 인덱스와 논파티션드 인덱스로 구분된다. “논파티션드 인덱스 (non-partitioned index)”는 파티션으로 분할되지 않은 인덱스를 의미하며, “파티션드 인덱스 (partitioned index)”는 파티션드 테이블과 마찬가지로 파티션 조건에 따라 분할된 대용량 인덱스를 의미한다. 이는 [그림 6-4]로 설명된다. 논파티션드 인덱스 파티션드 인덱스 파티셔닝 조건 (color) [그림 7-4] 파티션드 인덱스와 논파티션드 인덱스 [그림 6-4]는 논파티션드 인덱스를 색깔(color)을 기준으로 분할하였으며, 결과적으로 파티션 3개로 구성된 파티션드 인덱스가 된다. 파티션 조건에 따라 분리된 파티션드 인덱스는 인덱스 파티션 키와 인덱스 키의 관계에 따라 프리픽스드 인덱스와 논프리픽스드 174 Administrator’s Manual 인덱스로 구분한다. 프리픽스드 인덱스 (Prefixed Index) 프리픽스드 인덱스는 인덱스 키의 첫번째 칼럼이 인덱스 파티션 키의 첫번째 칼럼과 동일하다. 논프리픽스드 인덱스 (Non-prefixed Index) 논프리픽스드 인덱스는 인덱스 키의 첫번째 칼럼이 인덱스 파티션 키의 첫번째 칼럼과 동일하지 않다. create table tbl_sales( sales_id integer, sales_date date ) partition by range( sales_date ) ( partition p1 values less than( to_date('2007-05-01', 'YYYY-MM-DD' ) ), partition p2 values less than( to_date('2007-09-01', 'YYYY-MM-DD' ) ), partition p3 values default ) tablespace sys_tbs_disk_data; sales_idsales_date 21월 410월 112월 63월 84월 55월 38월 711월 96월 테이블(TBL_SALES) 3월1월4월6월5월8월11월10월12월 IDX_PART_1IDX_PART_2IDX_PART_3 프리픽스드 인덱스(IDX_PREFIX) sales_date < 5월sales_date < 9월default create index idx_prefix on tbl_sales( sales_date ) local ( partition idx_part_1 on p1, partition idx_part_2 on p2, partition idx_part_3 on p3 ); sales_date=sale_date 628539417 IDX_PART_1IDX_PART_2IDX_PART_3 논프리픽스드 인덱스(IDX_NON_PREFIX) sales_date < 5월sales_date < 9월default create index idx_non_prefix on tbl_sales( sales_id ) local ( partition idx_part_1 on p1, partition idx_part_2 on p2, partition idx_part_3 on p3 ); sales_id!=sale_date [그림 7-5] 프리픽스드 인덱스와 논프리픽스드 인덱스의 예 [그림 6-5]는 프리픽스드 인덱스와 논프리픽스드 인덱스의 차이를 sales_id와 sale_date로 이루어진 테이블을 사용해서 설명하고 있다. 위의 그림에서 인덱스들은 sales_date 칼럼에 의해서 분할된다. 각 인덱스는 어떠한 키로 구성되느냐에 따라 프리픽스드 인덱스 또는 논프리픽스드 인덱스로 분류된다. 그림에서 프리픽스드 인덱스는 sales_date를 키로 갖는다. 즉, 파티션드 객체 175 인덱스 파티션 키와 인덱스 키가 같은 칼럼 기반이다. 이러한 인덱스를 “프리픽스드 인덱스 (prefixed index)”라고 한다. 반면, 그림에서의 논프리픽스드 인덱스는 sales_id로 정렬되어 있다. 이러한 인덱스는 인덱스 파티션 키와는 다른 칼럼에 의해서 정렬된 인덱스로 “논프리픽스드 인덱스 (non-prefixed index)”라고 한다. 프리픽스드와 논프리픽스드로 구분하는 이유는 유니크 (Unique) 속성과 관련이 있다. 프리픽스드 인덱스의 키는 인덱스 파티션 키와 동일하기 때문에, 알티베이스 서버는 유니크 검사시 파티션드 인덱스에 속한 모든 파티션들을 검색하지 않고도 유니크 검사를 할 수 있다. 그러나 논프리픽스드 인덱스의 경우에는 알티베이스 서버는 파티션드 인덱스에 포함된 모든 파티션들을 검색해야 한다. [그림 6-6]이 이의 예를 보여준다. sales_idsales_date 21월 410월 112월 63월 84월 55월 38월 96월 91월 테이블(TBL_SALES) 628539417 IDX_PART_1IDX_PART_2IDX_PART_3 논프리픽스드 인덱스(IDX_NON_PREFIX) sales_date < 5월sales_date < 9월default 9 인덱스 : sales_date 인덱스 : sales_id [그림 7-6] 논프리픽스드 인덱스를 이용한 유니크 검사의 예 (불가능함) [그림 6-6]의 예제에서 인덱스 파티션 키는 sales_date칼럼이며 sales_id칼럼은 유니크 제약조건을 갖는다. sales_id칼럼을 인덱스 키로 갖는 논프리픽스드 인덱스(IDX_NON_PREFIX)가 구축된다면, 다음의 구문으로 레코드 삽입시 알티베이스가 인덱스 IDX_NON_PREFIX를 이용해서 유니크 검사를 할 수 있을지 생각해보자: INSERT INTO TBL_SALES VALUES(9, 1월); 우선 삽입하려는 레코드의 sales_date칼럼의 값이 “1월”이기 때문에, 키는 IDX_PART_1 파티션에 삽입될 것이다. 삽입시 IDX_PART_2 파티션 sales_id 칼럼에 9의 키 값이 있음에도 불구하고 IDX_PART_1 파티션에 정상적으로 삽입될 것이다. 따라서 알티베이스 서버는 논프리픽스드 인덱스를 이용해서 유니크 검사를 할 경우에는 각 파티션내의 인덱스를 모두 검색해야만 한다. 글로벌 인덱스와 로컬 인덱스 176 Administrator’s Manual 인덱스는 테이블 파티션 키와 인덱스 파티션 키의 관계에 따라 글로벌 인덱스와 로컬 인덱스로 구분된다. “글로벌 인덱스 (global index)”는 인덱스 파티션 키가 테이블 파티션 키와 일치하지 않는 인덱스를 의미한다 (index_partition_key != table_partition_key). “로컬 인덱스 (local index)”는 인덱스 파티션 키가 테이블 파티션 키와 일치하는 인덱스를 의미한다 (index_partition_key == table_partition_key). sales_idsales_date 21월 410월 112월 63월 84월 55월 38월 711월 96월 테이블(TBL_SALES) 3월1월4월6월5월8월11월10월12월 IDX_PART_1IDX_PART_2IDX_PART_3 로컬인덱스(IDX_LOCAL) sales_date < 5월sales_date < 9월default create index idx_local on tbl_sales( sales_date ) local ( partition idx_part_1 on p1, partition idx_part_2 on p2, partition idx_part_3 on p3 ); sales_date=sale_date 8월1월12월5월3월10월6월4월11월 IDX_PART_1IDX_PART_2IDX_PART_3 글로벌인덱스(IDX_GLOBAL) sales_id < 4sales_id < 7default create index idx_global on tbl_sales( sales_date ) global partition by range(sales_id) ( partition idx_part_1 values less than (4) partition idx_part_2 values less than (7) partition idx_part_3 values less than (MAXVALUE) ); create table tbl_sales( sales_id integer, sales_date date ) partition by range( sales_date ) ( partition p1 values less than( to_date('2007-05-01', 'YYYY-MM-DD' ) ), partition p2 values less than( to_date('2007-09-01', 'YYYY-MM-DD' ) ), partition p3 values default ) tablespace sys_tbs_disk_data; sales_date!=sale_id 3월1월4월8월5월6월12월10월11월 드 테이블(TBL_SALES) sales_date < 5월sales_date < 9월default [그림 7-7] 로컬 인덱스와 글로벌 인덱스의 예 [그림 6-7]은 글로벌 인덱스와 로컬 인덱스의 차이를 sales_id 와 sale_date 칼럼으로 이루어진 테이블을 사용해서 설명하고 있다. 그림에서 인덱스들은 sales_date에 의해서 정렬되어 있고, 각 인덱스를 어떠한 인덱스 파티션 키로 분할하느냐에 따라 로컬 인덱스 또는 글로벌 인덱스로 분류된다. 아래 그림에서 로컬 인덱스는 sales_date칼럼을 기준으로 3개의 파티션으로 분할된다. 이렇게 인덱스 파티션 키 (sale_date)와 테이블 파티션 키 (sales_date)가 동일한 파티션드 인덱스를 로컬 인덱스라고 한다. 반면, 그림 하단의 글로벌 인덱스는 sales_id칼럼에 의해서 분할되어 있다. 즉, 인덱스 파티션 키 (sales_id)와 테이블 파티션 키(sales_date)가 동일하지 않다. 이런 유형의 파티션드 인덱스를 글로벌 인덱스라고 한다. 인덱스를 글로벌 또는 로컬 인덱스로 구분하는 이유는 테이블 파티션 키와 인덱스 파티션 키의 동치 여부에 따라 다른 특징을 파티션드 객체 177 갖기 때문이다. 테이블 파티션 키와 다른 칼럼을 기준으로 구축된 파티션드 인덱스는 글로벌 인덱스의 한 인덱스 파티션 내의 키들이 서로 다른 테이블 파티션들을 가리키고 있음을 의미한다. 이는 파티션드 테이블에 대한 변경 구문 (ALTER TABLE .... MERGE ...) 실행은 글로벌 인덱스의 재구축 (rebuild)으로 이어질수 있음을 의미한다. 반면 로컬 인덱스의 경우는 파티션드 테이블에 대한 변경 구문은 변경되는 파티션의 로컬 인덱스에만 영향을 미치기 때문에, 전체적인 동시성 효율을 떨어뜨리지 않는다. 인덱스의 종류 지금까지 설명한 인덱스의 종류를 정리하면 [그림 6-8]과 같다. (파티션드) 글로벌 프 픽스드 인덱스 (파티션드) 글로벌 논프 픽스드 인덱스 (파티션드) 로컬 프 픽스드 인덱스 (파티션드) 로컬 논프 픽스드 인덱스 논파티션드 글로벌 인덱스 인덱스 파티션 유무 index_part_key == table_part_key index_part_key == index_key index_part_key == index_key YESNo YESNo YESNoYESNo [그림 7-8] 인덱스의 종류 현재 알티베이스는 로컬 인덱스만 지원한다. 글로벌 인덱스는 지원되지 않는다. 이것을 테이블과 연관지어 정리하면 다음과 같다. 논파티션드 인덱스만 논파티션드 테이블 위에 구축될 수 있으며, 논파티션드 테이블 파티션드 테이블 (파티션드)로컬 프리픽스드 인덱스 (파티션드)로컬 논프리픽스드 인덱스 (파티션드)글로벌 프리픽스드 인덱스 (파티션드)글로벌 논프리픽스드 인덱스 논파티션드 글로벌 인덱스 지원가 지원불가 178 Administrator’s Manual 로컬 프리픽스드 인덱스와 로컬 논프리픽스드 인덱스만이 파티션드 테이블 위에 구축될 수 있다. 파티션드 객체 179 파티션 조건 본 절에서는 파티션 조건과 기본 파티션을 설명한다. 파티션 전제조건 파티션 조건 (partition condition)은 파티션을 분할하는 기준을 의미한다. 이러한 기준은 다음과 같은 규칙을 준수해야 한다. partition_conditioni ∩ partition_conditioni+1 = ∮…………rule2 위의 규칙은 파티션드 테이블을 위한 파티션 조건들간에 교집합이 존재해서는 안됨을 의미한다. 교집합이 존재한다는 것은 레코드가 어느 파티션으로 삽입되어야 하는지 명확하지 않다는 것이다. 따라서, 파티션드 객체 생성시 이러한 규칙을 만족하지 않으면 파티션 생성은 실패한다. 또한 파티션 조건은 어떠한 경우에도 항상 동일한 값을 표현해야 한다. 레코드가 t라는 시점에 A 파티션에 삽입되었다고 가정할 경우, 동일 레코드가 t+1시점에 삽입되는 경우에도 A파티션에 삽입되어야 한다. 이러한 조건을 만족시키기 위해서 파티션 조건에 기술되는 파티션 조건 값은 항상 상수 또는 결정가능한 내장 함수 (deterministic built-in function)여야 한다. 결정가능한 내장함수란 시점에 상관없이 동일한 값을 리턴하는 시스템 내부에서 제공하는 함수(non-user-defined function)를 의미한다. 기본 파티션 알티베이스에서 파티션 조건은 다음과 같은 규칙을 항상 만족해야 한다. column_domain ≡ ∪partition_condition ……………… rule3 위의 규칙은 파티션 조건에 참여하는 칼럼의 도메인 (column domain)이 파티션 조건들의 합집합과 동치관계여야 함을 의미한다. 이는 파티션드 테이블 생성시에 모든 파티션 조건들을 명시적으로 기술해야 함을 의미한다. 그러나 현실적으로 질의문을 기술하는 사용자가 모든 파티션 조건을 기술한다는 것은 불가능하기 때문에 알티베이스에서는 기본 파티션 (default partition)이라는 개념을 제공한다. [그림 6-9]에서는 3개의 파티션을 갖는 파티션드 객체를 예를 들어 180 Administrator’s Manual 기본 파티션을 설명하고 있다. 아래 구문에서 사용자는 P1및 P2파티션에 대한 파티션 조건 (partition_condition1, partition_condition2)을 명시하였으며, P3에 대해서 기본 파티션을 선언하였다. 이러한 경우, 삽입되는 레코드가 partition_condition1과 partition_condition2조건에 걸리지 않는다면 P3파티션에 삽입된다. 즉, 기본 파티션은 파티션 키 칼럼이 갖는 전체 도메인에서 사용자가 지정한 파티션 조건들을 뺀 나머지 도메인 부분과 같다. [그림 7-9] 기본 파티션 사용 예제 기본 파티션은 파티션드 객체 생성시 반드시 명시해야 한다. 만약 기본 파티션을 명시하지 않는다면 파티션드 객체 생성은 실패한다. create table(…) partition by range(…) ( partition P1 partion_condition1, partition P2 partion_condition2, partition P3 default ) TABLESPACE SYS_TBS_DISK_DATA; P1 P2 P3(default partition) 파티션드 객체 181 파티셔닝 방법 객체는 다음 세 가지 방법으로 분할될 수 있다: 범위 파티셔닝, 리스트 파티셔닝, 해시 파티셔닝. 범위 파티셔닝은 객체를 파티션 키 값의 범위 (range)를 기준으로 분할하는 방법이다. 범위 파티셔닝은 선형적 (linear) 범위로 파티션을 구성할 때 적합하다. 리스트 파티셔닝은 파티션 키 값의 집합을 기준으로 분할하는 방법으로 이산적 (discrete) 범위의 파티션을 구성하고 싶은 경우에 적합하다. 해시 파티셔닝은 파티션 키 값에 해당하는 해시(hash) 값을 기준으로 분할하는 방법이다. 위 방법으로 생성된 각 파티션에 대해 다음과 같은 연산이 가능한다. 범위 파티셔닝으로 생성된 파티션 리스트 파티셔닝으 로 생성된 파티션 해시 파티셔닝으로 생성된 파티션 추가 X X ○ 병합 X X ○ 삭제 ○ ○ X 합병 ○ ○ X 이름 변경 ○ ○ ○ 분할 ○ ○ X 레코드 삭제 ○ ○ ○ [표 7-1] 파티션 별 지원 연산 범위 파티셔닝 범위 파티셔닝(range partitioning)은 분할할 때 날짜(DATE) 타입을 많이 이용하며, 이력 데이터(historical data)를 다루는 분야에서 사용된다. 파티션 정의시 사용할 수 있는 유일한 파티션 조건은 ‘LESS THAN’이다. 기본 파티션은 ‘DEFAULT’ 절을 사용해서 정의할 수 있다. 다음은 범위 파티셔닝의 예제이다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) 182 Administrator’s Manual PAR T I T I O N BY R AN G E(s a l e s _ d a t e ) ( PAR T I T I O N p a rt _ 1 VA L U ES L ES S T H A N ( T O _ D AT E( ‘01-FEB-2006’) ), PARTITION part_2 VALUES LESS THAN ( TO_DATE(‘01-MAR-2006’) ), PARTITION part_3 VALUES LESS THAN ( TO_DATE(‘01-APR-2006’) ), PARTITION part_def VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; 위의 예제는 part_table테이블을 생성하면서 범위 파티셔닝 방법을 이용하여 파티션 4개로 분할한다. 처음 세 개의 파티션은 각각 FEB, MAR, 및 APR이전의 데이터를 다루며, part_def라는 기본 파티션은 어떤 조건에도 포함되지 않는 데이터를 다룬다. 위의 예를 그래피컬 방식으로 표현하면 [그림 6-10]과 같다. TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-MAR-2006’) TO_DATE (‘01-APR-2006’) part_1part_2part_3part_def ∞-∞ [그림 7-10] 범위 파티션드 테이블의 파티션 영역 다중칼럼 파티셔닝 다중칼럼 파티셔닝(Multicolumn Partitioning)은 다중칼럼으로 구성된 파티션 키를 이용하여 객체를 분할하는 것을 말한다. 다중칼럼 파티셔닝은 다중키를 갖는 인덱스와 동일한 개념을 갖는다. 다음 그림은 두 개 칼럼(i1, i2)으로 구성된 파티션 키를 1차원 형태로 표현한 것이다. -∞∞ -∞∞ -1 (i1, i2) -∞∞ 0 -∞∞ 1...... [그림 7-11] 다중칼럼 파티셔닝의 파티션 영역 다음은 다중칼럼 파티셔닝을 SQL구문으로 예를 들어 설명하고 있다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, 파티션드 객체 183 s a l e s _ c i t y V AR C H AR ( 2 0 ) , . . . . ) PARTITION BY RANGE(sales_date, sales_id) ( PARTITION part_1 VALUES LESS THAN ( TO_DATE(‘01-FEB-2006’), 200), PARTITION part_2 VALUES LESS THAN ( TO_DATE(‘01-MAR-2006’), 100), PARTITION part_3 VALUES LESS THAN ( TO_DATE(‘02-MAR-2006’)), PARTITION part_4 VALUES LESS THAN ( TO_DATE(‘01-APR-2006’) ), PARTITION part_def VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; 위의 테이블 생성 구문을 그림으로 설명하면 다음과 같다. -∞∞ -∞∞ (i1, i2) -∞∞-∞∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-MAR-2006’) TO_DATE (‘01-APR-2006’) 100200100200100200 ...... part_1part_2part_3part_defpart_4 [그림 7-12] SQL 구문 예제의 파티션 영역 다음 표는 삽입될 레코드의 값에 따라 레코드가 삽입될 파티션과 해당 파티션에 삽입을 유도한 포함 조건이 무엇인지 보여주고 있다. 삽입될 레코드의 값(sales_date, sales_id) 레코드가 삽입될 파티션 TO_DATE(‘15-JAN-2006’), 100 part_1 TO_DATE(‘01-FEB-2006’), 100 part_1 TO_DATE(‘01-FEB-2006’), 200 part_2 TO_DATE(‘15-FEB-2006’), NULL part_2 TO_DATE(‘01-MAR-2006’), 50 part_2 TO_DATE(‘01-MAR-2006’), NULL part_3 TO_DATE(‘15-MAR-2006’), 200 part_4 NULL, 100 part_def NULL, NULL part_def 범위 파티션드 객체에 대한 연산 184 Administrator’s Manual 범위 파티션드 객체에 수행될 수 있는 연산의 종류는 5가지이다. 이 연산들은 파티션 분할, 파티션 삭제, 파티션 합병, 파티션 이름 변경, 파티션 레코드 삭제이다. 파티션 조건 변경은 현재는 지원되지 않는다. 범위 파티션드 객체에 파티션이 추가되는 과정은 파티션 조건이 분할되는 과정과 동일하기 때문에 ‘SPLIT PARTITION’을 이용하도록 한다. 마찬가지로 파티션 삭제는 파티션 조건을 삭제하는 것과 동일하므로 ‘DROP PARTITION’을 사용하도록 한다. 파티션 삭제시, 삭제된 파티션 조건은 이웃한 파티션의 조건에 포함된다. 또한 레코드의 삭제 여부에 따라서 ‘DROP PARTITION’과 ‘MERGE PARTITION’으로 구분된다. 파티션 이름 변경은 ‘RENAME PARTITION’을 사용하면 된다. 파티션의 레코드를 삭제하려면 ‘TRUNCATE PARTITION’을 이용하도록 한다. 이는 파티션 내에 저장된 모든 레코드를 삭제한다. 파티션 분할 (SPLIT PARTITION) 파티션 분할은 파티션드 객체가 갖는 한 파티션을 2개의 파티션으로 분할하는 연산이다. 파티션 분할은 분할 방식에 따라 다음의 2가지 경우로 나뉜다. 인플레이스 분할(In-place Split) 기존 파티션의 레코드 일부를 잘라 새로운 파티션에 이동하는 분할 방식으로, 기존 파티션의 내용이 변경된다. 새로운 파티션의 이름이 기존 파티션의 이름과 같고, 새 파티션이 생성될 테이블스페이스를 지정하지 않으면 인플레이스 분할 방식이 사용된다. ([그림 6-13] 참조) 아웃플레이스 분할(Out-place Split) 기존 파티션의 내용은 변경되지 않는다. 대신 새로운 2개의 파티션을 생성하여, 기존 파티션의 레코드를 복사하는 분할 방식이다. 새로운 두 파티션의 이름을 기존 파티션의 이름과 다르게 지정했을 때 이 방식이 사용된다. 새 파티션 중 하나의 이름이 기존 파티션의 이름과 같더라도 그 파티션이 생성될 테이블스페이스를 지정한 경우에 사용된다. ([그림 6-14] 참조) 위의 아웃플레이스와 인플레이스 분할 방식은 성능과 효율성에서 차이가 날 수 있다. 인플레이스 분할시에는 기존 파티션이 새로운 두 파티션 중 하나와 같기 때문에 한 개의 새로운 파티션만이 생성된다. 따라서, 인플레이스 분할은 공간적인 측면에서 이득이다. 아웃플레이스 분할시에는 새로운 두 개의 파티션을 생성하고 각각의 파티션에 레코드 삽입 연산이 이루어진다. 인플레이스 분할에서의 파티션드 객체 185 레코드에 대한 연산은 이동 연산으로 이는 삽입과 삭제로 구성된다. MVCC 환경에서 레코드 삭제 연산은 레코드 삽입 연산에 비해 성능이 많이 떨어진다. 따라서, 인플레이스 분할은 저장 공간이 부족할 때 효율적이며, 아웃플레이스 분할은 저장 공간이 충분한 MVCC 환경에서 좋은 성능을 나타낸다. TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-MAR-2006’) TO_DATE (‘01-APR-2006’) part_1part_2part_3part_def ∞-∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-MAR-2006’) TO_DATE (‘01-APR-2006’) part_1part_2part_3part_def ∞-∞ part_4 TO_DATE (‘15-FEB-2006’) ALTER TABLE part_table SPLIT PARTITION part_2 AT(TO_DATE(‘15-FEB-2006’)) INTO (PARTITION part_2, PARTITION part_4); shrink condition ecords insert records [그림 7-13] 범위 파티션드 객체에서 인플레이스 분할 위의 그림에서 보여준 예는 4개의 파티션을 갖는 파티션드 객체의 part_2를 part_2와 part_4로 분할하고 있다. ①새로운 파티션 part_4가 생성되며, ②기존 part_2에서 part_4로의 레코드 이동(MOVE: 삽입 幣碩홱 마지막으로 ③part_2의 조건이 지정된 조건으로 축소된다. TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-MAR-2006’) TO_DATE (‘01-APR-2006’) part_1part_2part_3part_def ∞-∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-MAR-2006’) TO_DATE (‘01-APR-2006’) part_1part_2part_3part_def ∞-∞ part_4 TO_DATE (‘15-FEB-2006’) ALTER TABLE part_table SPLIT PARTITION part_2 AT(TO_DATE(‘15-FEB-2006’)) INTO (PARTITION part_2 TABLESPACE tbs_01, PARTITION part_4); insert records insert records [그림 7-14] 범위 파티션드 객체에서 아웃플레이스 분할 위의 그림에서 보여준 예는 4개의 파티션을 갖는 파티션드 객체에서 part_2를 part_2와 part_4로 분할하고 있다. ①새로운 파티션 part_2와 part_4가 생성되며, ②part_2(old)에서 part_2(new)와 part_4로의 레코드 삽입이 진행된다. 마지막으로 ③part_2(old)가 물리적으로 삭제된다. 기본 파티션 분할시에는, INTO절 두 번째 파티션이 자동으로 기본 186 Administrator’s Manual 파티션으로 설정된다. 이는 INTO하위절에 기본 파티션을 지정할수 있는 구문을 지원하지 않기 때문이다. 파티션 삭제(DROP PARTITION) 파티션 삭제는 파티션드 객체가 갖는 파티션들 중에 지정된 파티션을 삭제하는 연산이다. 파티션 삭제시 삭제될 파티션이 갖는 모든 레코드와 메타 정보들은 물리적으로 삭제된다. 또한 삭제된 파티션의 조건은 이웃한 파티션으로 흡수된다. TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-MAR-2006’) TO_DATE (‘01-APR-2006’) part_1part_2part_3part_def ∞-∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-APR-2006’) part_1part_3part_def ∞-∞ ALTER TABLE part_table DROP PARTITION part_2; delete records expand condition [그림 7-15] 범위 파티션드 객체에서 파티션 삭제 위의 그림은 4개의 파티션을 갖는 파티션드 객체에서 part_2파티션이 삭제되는 과정을 보여주고 있다. ①part_2의 물리적 공간(레코드, 메타정보)이 삭제되고, ②이웃한 파티션(part_2의 조건을 포함할수 있는 조건을 가진 파티션)인 part_3으로 파티션 조건이 흡수된다. 파티션 합병(MERGE PARTITION) 파티션 합병은 파티션드 객체가 갖는 파티션들 중 지정된 파티션 두 개를 하나의 파티션으로 합병하는 연산이다. 합병할 파티션들은 반드시 이웃해야 한다. 파티션 합병은 합병 방식에 따라 인플레이스 합병과 아웃플레이스 합병으로 나뉜다. 인플레이스 합병(In-place Merge) 기존의 두개 파티션이 하나의 파티션으로 합쳐지면서, 기존 파티션의 레코드가 여기에 삽입되는 방식이다. 새로운 파티션의 이름이 기존 파티션 중 하나의 이름과 같고, 새로운 파티션이 생성될 테이블스페이스를 지정하지 않은 경우에 사용된다. ([그림 6-16] 참조) 아웃플레이스 합병(Out-place Merge) 새로운 파티션이 추가로 생성되어 기존 파티션들의 레코드들이 새로운 파티션으로 복사되는 방식이다. 새로운 파티션의 이름이 파티션드 객체 187 기존 파티션의 이름과 다른 경우에 사용된다. 또한 새로운 파티션의 이름이 기존 파티션 중 하나의 이름과 같더라도 새로운 파티션이 생성될 테이블스페이스를 지정한 경우에 사용된다. ([그림 6-17] 참조) 인플레이스 합병과 아웃플레이스 합병은 성능과 효율성에서 차이가 날 수 있다. 인플레이스 합병은 새로운 파티션을 생성하지 않고, 레코드 삽입 연산만 하기 때문에 성능면에서 아웃플레이스 합병보다 유리하다. TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-MAR-2006’) TO_DATE (‘01-APR-2006’) part_1part_2part_3part_def ∞-∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-APR-2006’) part_1part_3part_def ∞-∞ insert records expand condition ALTER TABLE part_table MERGE PARTITIONS part_2, part_3 INTO PARTITION part_3; [그림 7-16] 범위 파티션드 객체에서의 인플레이스 합병 위의 그림은 4개의 파티션을 갖는 파티션드 객체의 part_2와 part_3를 part_3(old)로 합병하는 것을 보여주고 있다. ①기존 part_3의 조건이 확장되며, ②기존 part_2에서 part_3로의 레코드 삽입이 진행된다. 마지막으로 ③part_2가 물리적으로 삭제된다. TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-MAR-2006’) TO_DATE (‘01-APR-2006’) part_1part_2part_3part_def ∞-∞ TO_DATE (‘01-FEB-2006’) TO_DATE (‘01-APR-2006’) part_1part_3part_def ∞-∞ insert records insert records ALTER TABLE part_table MERGE PARTITIONS part_2, part_3 INTO PARTITION part_3 TABLESPACE tbs_01; [그림 7-17] 범위 파티션드 객체에서의 아웃플레이스 합병 [그림 6-17]은 4개의 파티션을 갖는 파티션드 객체의 part_2와 part_3를 part_3(new)로 합병하는 것을 설명하고 있다. ①새로운 파티션 part_3가 생성되며, ②기존 part_2와 part_3(old)에서 part_3(new)로 레코드 삽입이 진행된다. 마지막으로 ③part_2와 part_3(old)가 물리적으로 삭제된다. 188 Administrator’s Manual 파티션 이름 변경(RENAME PARTITION) 파티션 조건은 변경되지 않으며, 파티션 이름만 변경된다 파티션 레코드 삭제(TRUNCATE PARTITION) 파티션 레코드 삭제는 파티션 조건이 변경되지 않으며, 파티션에 저장되어 있는 모든 레코드들이 삭제된다. 리스트 파티셔닝 리스트 파티셔닝(list partitioning)은 객체를 파티션 키 칼럼 값의 집합을 기준으로 분할하는 방법이다. 리스트 파티셔닝은 파티션 키 칼럼 값의 범위가 넓지 않을 경우(예: 1월 ~ 12월)에 자주 사용되는 분할 방법이다. 리스트 파티셔닝은 원칙적으로 파티션 칼럼으로 다중키를 지원하지 않는다. 범위 파티셔닝처럼 기본 파티션 생성을 위해서 DEFAULT 절이 지원된다. 다음은 리스트 파티셔닝의 예제이다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) PARTITION BY LIST(sales_city) ( PARTITION part_1 VALUES ( ‘SEOUL’ , ‘INCHEON’ ), PARTITION part_2 VALUES ( ‘PUSAN’ , ‘JUNJU’ ), PARTITION part_3 VALUES ( ‘CHUNGJU’ , ‘DAEJUN’ ), PARTITION part_def VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; 위의 예제에서, 테이블은 리스트 파티셔닝으로 분할되어 4개의 파티션을 갖는 파티션드 테이블 part_table이 생성된다. 처음 세 개의 파티션은 특정 도시별로 데이터를 관리하며, part_def라는 기본 파티션은 각 조건에 포함되지 않는 데이터를 관리한다. 이를 그림으로 표현하면 아래와 같다. 파티션드 객체 189 “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def [그림 7-18] 리스트 파티션드 테이블의 파티션 영역 리스트 파티션드 객체에 대한 연산 리스트 파티션드 객체에 수행될 수 있는 연산의 종류는 5가지이다. 이 연산들은 파티션 분할, 파티션 삭제, 파티션 합병, 파티션 이름 변경, 파티션 레코드 삭제이다. SQL 구문은 범위 파티션드 객체를 위한 구문과 동일하다. 파티션 조건 변경은 지원되지 않는다. 파티션 분할(SPLIT PARTITION) 리스트 파티셔닝은 범위 파티셔닝과 동일하게 인플레이스 분할과 아웃플레이스 분할을 지원한다. 파티션을 분할할 때 지정한 새로운 파티션 중 하나의 이름이 기존 파티션의 이름과 같을 경우, 테이블스페이스 지정 여부에 따라 인플레이스 분할이나 아웃플레이스 분할이 사용된다. “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def part_4 insert records “SEOUL” “INCHEON”“JUNJU” “CHUNGJU” “DAEJUN” DEFAULT “PUSAN” ALTER TABLE part_table SPLIT PARTITION part_2 VALUES(‘PUSAN’) INTO (PARTITION part_4, PARTITION part_2); delete records [그림 7-19] 리스트 파티션드 객체에서의 인플레이스 분할 위의 그림에서 보여준 예는 4개의 파티션을 갖는 파티션드 객체에서 part_2를 part_2와 part_4로 분할하는 것을 설명하고 있다. ①새로운 파티션 part_4가 생성되며, ②기존 part_2에서 190 Administrator’s Manual part_4로의 레코드 이동(MOVE: 삽입 행된다. 마지막으로 ③part_2의 조건이 지정된 조건으로 축소({‘PUSAN’, ‘JUNJU’} -> {‘JUNJU’})된다. “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def part_4 insert records “SEOUL” “INCHEON”“JUNJU” “CHUNGJU” “DAEJUN” DEFAULT “PUSAN” ALTER TABLE part_table SPLIT PARTITION part_2 VALUES(‘PUSAN’) INTO (PARTITION part_4, PARTITION part_2 TABLESPACE tbs_01); insert records [그림 7-20] 리스트 파티션드 객체에서의 아웃플레이스 분할 위의 그림 예는 4개의 파티션을 갖는 파티션드 객체에서 part_2를 part_2와 part_4로 분할하는 것을 설명하고 있다. ①새로운 파티션 part_2와 part_4가 생성되며, ②part_2(old)에서 part_2(new)와 part_4로의 레코드 삽입이 진행된다. 마지막으로 ③part_2(old)가 물리적으로 삭제된다. 파티션 삭제(DROP PARTITION) 리스트 파티션드 객체에서의 파티션 삭제는 범위 파티션드 객체와 유사하며, 다만 삭제될 파티션의 파티션 조건이 이웃 파티션이 아닌 기본 파티션의 조건으로 흡수된다는 점만 다르다. “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def delete records “SEOUL” “INCHEON” “CHUNGJU” “DAEJUN” DEFAULT ALTER TABLE part_table DROP PARTITION part_2; [그림 7-21] 리스트 파티션드 객체에서 파티션 삭제 파티션드 객체 191 위의 그림에서 보여준 예는 4개의 파티션을 갖는 파티션드 객체에서 part_2를 삭제하는 것을 설명하고 있다. ①part_2가 갖는 물리적인 공간(레코드, 메타정보)이 삭제되고, ② part_2의 조건이 기본 파티션 part_def로 흡수된다. 파티션 합병(MERGE PARTITION) 리스트 파티션드 객체에서의 파티션 합병은 범위 파티션드 객체와 동일하게 인플레이스 합병과 아웃플레이스 합병이 있다. 지정한 새로운 파티션의 이름이 합병할 파티션들 중 하나의 이름과 같을 경우, 테이블스페이스를 지정했는지에 따라 인플레이스 합병이나 아웃플레이스 합병이 사용된다. “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def insert records “SEOUL” “INCHEON” DEFAULT expand condition ALTER TABLE part_table MERGE PARTITIONS part_2, part_3 INTO PARTITION part_3; “PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” [그림 7-22] 리스트 파티션드 객체에서의 인플레이스 합병 위의 그림에서 보여준 예는 4개의 파티션을 갖는 파티션드 객체에서 part_2와 part_3를 part_3(old)로 합병하는 것을 설명하고 있다. ①기존 part_3의 조건이 확장되며, ②기존 part_2에서 part_3로 레코드 삽입이 진행된다. 마지막으로 ③part_2가 물리적으로 삭제된다. 192 Administrator’s Manual “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULTpart_1 part_2 part_3 part_def insert records “SEOUL” “INCHEON”“PUSAN” “JUNJU” “CHUNGJU” “DAEJUN” DEFAULT insert records ALTER TABLE part_table MERGE PARTITIONS part_2, part_3 INTO PARTITION part_3 TABLESPACE tbs_01; [그림 7-23] 리스트 파티션드 객체에서 아웃플레이스 합병 위의 그림에서 보여준 예는 4개의 파티션을 갖는 파티션드 객체에서 part_2와 part_3를 part_3(new)로 합병하는 것을 설명하고 있다. ①새로운 파티션 part_3가 생성되며, ②기존 part_2와 part_3(old)에서 part_3(new)로의 레코드 삽입이 진행된다. 마지막으로 ③part_2와 part_3(old)가 물리적으로 삭제된다. 파티션 이름 변경(RENAME PARTITION) 파티션 조건은 변경되지 않으며, 파티션의 이름이 변경된다. 파티션 레코드 삭제(TRUNCATE PARTITION) 파티션 조건은 변경되지 않으며, 파티션에 저장되어 있는 모든 레코드들이 삭제된다. 해시 파티셔닝 해시 파티셔닝(Hash Partitioning)은 객체를 파티션 키의 해시(hash) 값을 기준으로 분할하는 방법이다. 파티션 키는 다중 칼럼으로 구성될 수 있다. 해시 파티셔닝은 관리의 용이성보다는 데이터의 고른 부하 분배를 위해 많이 사용되는 방법이다. 해시 파티셔닝은 해시의 특성으로 인해 일반적인 파티션 연산에 제한을 받는다. 범위 파티션과 리스트 파티션과 달리 해시 파티션에는 파티션 분할, 삭제, 합병(merge) 등의 작업을 수행할 수 없으며, 파티션 추가, 병합(coalesce)과 같은 해시 전용 작업은 수행이 가능하다. 파티션드 객체 193 범위 파티셔닝과 리스트 파티셔닝과 달리 해시 파티셔닝에는 기본 파티션이 지원되지 않는다. 이는 해시 함수 자체가 파티션 키의 모든 값을 수용할 수 있기 때문이다. 널(null) 파티션 키 값을 갖는 레코드가 삽입되는 위치는 널에 대한 해시 값에 의존한다. 널의 해시값은 고정된 상수지만, 데이터 타입마다 상이한 값을 갖는다. 널 파티션 키 값을 갖는 레코드는 칼럼의 타입에 따라 저장되는 위치가 변경될 수 있다. 다음은 해시 파티셔닝의 예제이다. CREATE TABLE part_table ( sales_date DATE, sales_id NUMBER, sales_city VARCHAR(20), .... ) PARTITION BY HASH(sales_id) ( PARTITION part_1, PARTITION part_2, PARTITION part_3, PARTITION part_4 ) TABLESPACE SYS_TBS_DISK_DATA; 위 예제는 해시 파티셔닝을 이용해서 4개의 파티션을 갖는 테이블 part_table이 생성되는 것을 보여준다. 각 파티션은 해시 함수 HASH(sales_id, 4) 에 따라 나누어진 데이터를 관리한다. 위의 예를 도식화하면 [그림6-24]와 같다. part_1part_2part_3part_4 HASH( sales_id, 4) [그림 7-24] 해시 파티션드 테이블의 파티션 영역 해시 파티션드 객체에 대한 연산 194 Administrator’s Manual 해시 파티션드 객체에 수행될 수 있는 연산의 종류는 4가지이다. 이 연산들은 파티션 추가, 파티션 병합, 파티션 이름 변경, 파티션 레코드 삭제이다. 해시 파티션드 객체에 파티션을 추가하려면 ‘ADD PARTITION’을 이용한다. 파티션은 삭제하지만 그 데이터는 유지하려면 ‘COALESCE PARTITION’을 이용한다. 이 연산은 마지막 파티션을 삭제하고, 해당 파티션의 레코드는 기존 레코드들과 함께 파티션드 객체 전체를 재구성 (reorganization)한다. 파티션 이름을 변경하려면 ‘RENAME PARTITION’을 사용한다. 파티션 레코드를 삭제(파티션에 저장된 모든 레코드 삭제)하려면 ‘TRUNCATE PARTITION’을 이용한다. 파티션 추가(ADD PARTITION) 해시 파티션드 객체에 파티션을 추가하는 것은 해시 키의 개수가 늘어남을 의미한다. 파티션의 추가는 기존의 모든 파티션에 영향을 미치게 된다. 해시 키가 변경되면 테이블의 레코드 전체가 변경된 파티션들로 재구성(reorganization)된다. 아래 그림은 이러한 파티션 추가를 설명하고 있다. part_1part_2part_3part_4 part_1part_2part_3part_4 HASH( sales_id, 4) HASH( sales_id, 5) part_5 add part_5 ation ALTER TABLE part_table ADD PARTITION part_5; 파티션드 객체 195 [그림 7-25] 해시 파티션드 객체의 파티션 추가 위의 그림 예는 4개의 파티션을 갖는 파티션드 객체에서 part_5를 추가하는 것을 설명하고 있다. ①새로운 파티션 part_5가 생성되며, ②기존 파티션 4개의 레코드들이 기존 4개의 파티션과 1개의 새로 생성된 파티션으로 재분배된다. 파티션 병합(COALESCE PARTITION) 해시 파티션드 객체의 파티션을 병합(Coalesce)하는 것은 해시 키의 개수가 줄어드는 것을 의미한다. 파티션의 병합은 기존의 모든 파티션에 영향을 미친다. 마지막 파티션이 삭제되고, 해당 파티션의 레코드가 기존의 레코드들과 함께 파티션드 객체 전체가 재구성(reorganization)된다. 파티션 병합을 할 때 삭제될 파티션 이름은 지정할 수 없다. 마지막 파티션부터 1개씩 삭제된다. 예를 들어 4개의 파티션(part_1, part_2, part_3, part_4)을 갖는 파티션드 객체를 병합하면 part_4가 삭제되고 3개의 파티션(part_1, part_2, part_3)을 갖는 파티션드 객체로 줄어든다. 아래 그림은 이러한 파티션 병합 과정을 설명하고 있다. 196 Administrator’s Manual [그림 7-26] 해시 파티션드 객체의 파티션 병합 위의 그림은 4개의 파티션을 갖는 파티션드 객체에서 파티션 병합하는 것을 설명하고 있다. ①기존 파티션 4개의 레코드들이 part_1, part_2, part_3으로 재분배되고, ②마지막 파티션 part_4가 삭제된다. 파티션 이름 변경(RENAME PARTITION) 파티션 조건은 변경되지 않으며, 파티션의 이름이 변경된다. 파티션 레코드 삭제(TRUNCATE PARTITION) 파티션 조건은 변경되지 않으며, 파티션에 저장되어 있는 모든 레코드들이 삭제된다. 파티션드 객체 197 198 Administrator’s Manual 8. 트랜잭션 관리 사용자 트랜잭션의 동시성을 제어하고 데이터의 일관성을 유지하는 것이 데이터베이스의 가장 기본적인 기능의 하나다. 이장에서는 알티베이스의 트랜잭션 관리 기능에 대해서 알아보자. 트랜잭션 관리 199 트랜잭션 트랜잭션(Transaction)이란 하나 이상의 SQL 문장들로 이루어진 작업의 논리적인 단위를 말한다. 트랜잭션은 사용자에 의해 첫 SQL 구문의 실행으로 시작되고, 트랜잭션이 커밋 또는 롤백 될 때 끝난다. 커밋 또는 롤백은 명시적인 COMMIT 또는 ROLLBACK 구문으로 수행할 수도 있고, DDL 구문 실행으로 인해 암묵적으로 행해 질 수도 있다. 트랜잭션의 정의 트랜잭션은 한 트랜잭션 내의 SQL 구문들이 논리적으로 그룹지어 있는 한 사용자에게 데이터 변경의 일관성을 보장해 준다. 한 트랜잭션에는 작업의 논리적 단위를 위해 필요한 모든 부분이 포함되어야 한다. 트랜잭션이 시작되기 전에 일관된 상태였던 참조되는 모든 테이블의 데이터는 트랜잭션이 끝나 후에도 일관된 상태로 유지되어야 한다. 은행에서 예금을 이체하는 작업이 트랜잭션의 대표적인 예가 될 수 있다. A 계좌에서 B 계좌로 $100을 이체한다고 가정하면 다음과 같은 작업들이 이뤄져야 한다. 1. A 계좌에서 $100의 금액을 감소시킨다. 2. B 계좌에 $100의 금액을 증가시킨다. 3. A에서 B계좌로 이체한 사실을 작업내용에 기록한다. 일관된(Consistent) 상태의 데이터베이스에서 정상적인 트랜잭션이 수행되면, 데이터베이스는 여전히 일관된 상태로 되어야 한다. 만일, 위에서 열거한 트랜잭션의 세가지 작업 중 한 가지라도 정상적으로 수행되지 않으면, 데이터베이스의 무결성이 깨져서 A 계좌의 고객, B 계좌의 고객, 혹은 은행이 손해를 보는 경우가 발생할 것이다. 데이터베이스 무결성을 유지시키기 위해 정상적으로 수행되는 트랜잭션은 다음과 같은 ACID 특성을 만족시켜야 한다. 원자성 (Atomicity): 트랜잭션 내의 모든 구문(Statement)이 모두 반영되거나, 혹은 모두 반영되지 않아야 한다. 즉, 트랜잭션은 부분적으로 성공될 수 없다. 일관성 (Consistency): 트랜잭션의 수행으로 인해 데이터베이스의 무결성이 깨어져서는 안 된다. 격리성 (Isolation): 여러 개의 트랜잭션들이 동시에 수행될 때, 어떤 트랜잭션도 다른 트랜잭션의 결과에 영향을 받아서는 200 Administrator’s Manual 안된다. 영속성 (Durability): 일단 트랜잭션이 완료(Commit) 되면, 시스템 장애 같은 어떤 상황 하에서도 그 변경 내용을 영구적으로 유지할 수 있어야 한다. 트랜잭션 종료 트랜잭션은 다음의 하나가 발생할 때 종료될 것이다. 트랜잭션은 사용자가 SAVEPOINT 절 없이 ROLLBACK 구문을 실행하거나, COMMIT 구문을 실행할 때 종료된다. 사용자가 DDL 구문을 실행할 때 트랜잭션은 커밋된다. 사용자가 알티베이스 서버로부터의 연결을 해제하면 트랜잭션은 커밋된다. 사용자 세션이 비정상적으로 종료되면 현재 트랜잭션은 롤백된다. 문장 문장(statement)은 트랜잭션 내에서 수행되는 SQL 문 하나 하나를 일컫는 말이다. 문장의 종류에는 다음과 같은 세 종류가 있다. DCL (Data Control Language): 데이터베이스의 상태나 프로퍼티 혹은 물리적 구성을 변경시키는 문장들이다. DDL (Data Definition Language): 데이터베이스의 논리적 구성 요소인 객체들(테이블, 인덱스, 시퀀스, 등)의 생성, 변경 및 삭제를 수행하는 문장들이다. DML (Data Manipulation Language): 데이터베이스 내에 저장되는 실제 데이터들의 삽입, 삭제, 변경 및 검색을 수행하는 문장들이다. 일반적으로 하나의 SQL 문이 하나의 문장이 되지만, 저장 프로시저나 함수 등이 호출되면 하나 이상의 하위 문장들이 수행된다. 문장의 수행도 역시 데이터베이스의 무결성을 해치지 않아야 한다. 문장 수행 중 에러가 발생하면 해당 문장에서 수행한 모든 작업이 이전 상태로 되돌려진다. 이를 위해, 알티베이스는 각 문장을 시작하기 전에 “암묵적 저장점(Implicit Save Point)”을 설정해 두고, 오류 발생시 이 지점까지의 복원을 수행한다. 트랜잭션 관리 201 트랜잭션의 커밋 트랜잭션의 커밋(commit)이란 지금까지 트랜잭션 안에서 수행한 모든 SQL 문의 결과를 데이터베이스에 영구적으로 반영하면서 해당 트랜잭션을 종료하는 연산이다. 트랜잭션의 커밋은 데이터베이스의 상태를 이전의 무결한 상태에서 또 다른 무결한 상태로 전이시킨다. 트랜잭션이 커밋될 때, 알티베이스는 다음과 같은 작업을 수행한다. 트랜잭션 커밋 로그를 로그 파일에 기록한다. 트랜잭션의 수행으로 발생된 해제 가능한 자원들의 정보를 가비지 콜렉터(Garbage Collector)에게 넘겨준다. 트랜잭션의 상태를 커밋 상태(“committed”)로 변경시킨다. 트랜잭션 수행 중에 할당 받은 자원들(잠금, 임시 메모리 등)을 반환한다 트랜잭션의 롤백 트랜잭션의 수행 도중에 치명적인 오류가 있어 더 이상 진행할 수 없는 경우에는 지금까지 수행해 왔던 모든 SQL 문들을 다시 되돌려서, 데이터베이스를 트랜잭션 수행 이전 상태로 바꿔야 한다. 이를 트랜잭션의 롤백이라고 한다. 트랜잭션의 롤백은 트랜잭션 수행 중에 기록한 각 로그들에 대한 보상(compensation) 연산을 수행함으로써 구현된다. 트랜잭션 롤백 시 알티베이스는 다음과 같은 작업을 수행한다. 로그 레코드를 기록 순서와 반대로 읽어가며 보상 연산을 수행한다. 트랜잭션 롤백 로그를 기록한다. 삽입 등의 연산으로 할당 받았던 자원들을 다시 가비지 콜렉터에게 반환한다. 트랜잭션의 상태를 롤백 상태(“rolled back”)로 변경한다. 트랜잭션 수행 중에 할당받은 자원들(잠금, 임시 메모리 등)을 반환한다. 명시적 저장점 하나의 긴 트랜잭션을 여러 개의 부분으로 나누어 관리하여야 하는 경우, 그 부분의 시작 지점에 명시적 저장점(Explicit Save Point)을 선언할 수 있다. 202 Administrator’s Manual 명시적 저장점은 이름을 가지므로, 한 트랜잭션 내에 여러 개가 선언될 수도 있다. 명시적 저장점 선언 이후 오류가 발생하여 선언한 지점으로 데이터베이스를 다시 복원을 해야 하는 경우에는, 해당 저장점으로의 롤백을 수행하면 된다. 명시적 저장점으로의 롤백이 수행되면 이후에 잡았던 테이블과 레코드 잠금 등의 자원들이 모두 해제되며, 해당 저장점 이후에 선언된 다른 저장점들은 모두 해제된다. 트랜잭션 관리 203 잠금(Lock) 잠금의 목적은 데이터베이스 내에 존재하는 특정 객체에 대한 접근 권한을 설정하는 것이다. 알티베이스는 데이터에 대한 동시 접근을 제어하기 위해 잠금을 사용한다. 데이터가 갱신될 때, 갱신이 완료될 때까지 그 데이터에는 잠금이 걸린다. 이는 시스템에서 데이터의 무결성을 보장하는 데 도움이 된다. 잠금 모드 잠금에는 그 사용 대상에 따라 테이블 레벨 잠금과 레코드 레벨 잠금으로 나뉜다. 테이블 레벨 잠금 모드(Table Level Lock Modes) 잠금 모드 설명 기능 S Shared Lock (공유 락) 이 잠금의 소유자는 잠금을 획득한 테이블의 모 든 레코드를 읽을 수 있다. 그 테이블을 읽기만 하는 다른 트랜잭션들과도 동시에 수행될 수 있 다. X Exclusive Lock (배타적 락) 이 잠금의 소유자는 잠금을 획득한 테이블의 모 든 레코드를 읽고 갱신할 수 있다. 다른 어떤 트랜잭션도 그 테이블을 읽거나 갱신할 수 없 다. IS Intent Shared Lock (공유 락 의도) 테이블 내의 어떤 레코드에 대한 공유 락 획득 의 의도를 가지고 그 레코드가 속한 테이블에 대해 IS 락을 먼저 획득한다. 이 잠금의 소유자 는 레코드에 대해 S 잠금을 획득한 후 그 레코 드를 읽을 수 있다. IX Intent Exclusive Lock (배타적 락 의도) 테이블 내의 어떤 레코드에 대한 배타적 락 획 득의 의도를 가지고 그 레코드가 속한 테이블에 대해 IX 락을 먼저 획득한다. 이 잠금의 소유자 는 레코드에 대해 X 잠금을 획득한 후 그 레코 드를 읽고 갱신할 수 있다. 서로 다른 레코드를 갱신하는 여러 트랜잭션들은 동시에 존재할 수 있다. SIX Shared with Intent Exclusive Lock 이 잠금의 소유자는 잠금을 획득한 테이블의 모 든 레코드를 읽을 수 있으며, 그 테이블에 대해 204 Administrator’s Manual (배타적 락 의도를 가 진 공유 락) X 락을 획득한 후에는 그 테이블을 갱신할 수 도 있다. 다른 트랜잭션은 그 테이블을 갱신할 수 없으며 읽기는 가능하다. [표 8-1] 잠금 모드 의사 모드 잠금(Intention Mode Lock) - IS, IX, SIX 잠금을 걸 수 있는 객체의 종류는 여러 가지가 있다. 그 객체들의 크기 또한 다양하다. 예를 들어 잠금을 걸 수 있는 객체는 데이터베이스 자체, 스키마, 테이블, 레코드, 칼럼 등이 될 수 있으며 이들의 크기는 다음 순서를 가진다. 데이터베이스 > 스키마 > 테이블 > 레코드 > 칼럼 이처럼 잠금을 걸 수 있는 대상이 되는 객체의 크기를 잠금 단위(granularity)라 한다. 잠금 단위가 큰 객체에 대해서만 잠금을 지원하는 경우 그만큼 동시성 제어가 떨어진다. 왜냐하면 한 트랜잭션이 실제 작업 대상이 되는 객체는 레코드이기 때문에 레코드 이상의 객체에 대해서만 잠금 단위를 지원하는 경우 한 트랜잭션이 테이블 내의 레코드 하나에 대해서만 연산을 수행하더라도 그 테이블의 다른 레코드에 대해서 연산을 하고자 하는 다른 트랜잭션은 먼저 시작한 트랜잭션이 끝나기를 기다려야 하는 경우가 발생하기 때문이다. 따라서, 지원되는 잠금 단위는 최소 단위가 레코드인 것이 가장 효율적이다. 잠금의 최소 단위에 대해 잠금을 획득하기 위해서는 최소 단위보다 큰 객체에 대해서도 잠금을 획득해야 하며 이를 “잠금 단위 규약 (lock granularity protocol)”이라 한다. 더 큰 객체에 대해 잠금을 획득할 경우에는 잠금 모드를 다양하게 주어 어떤 트랜잭션이 그 테이블에 대해 연산을 수행하고 있다 하더라도 동일한 레코드에 대해서 연산을 하지 않는 다른 트랜잭션도 그 테이블에 대해 연산을 수행할 수 있게 하는 것이 바람직하다. 이를 위하여 사용되는 것이 “의사 모드 잠금 (intention mode lock)”이다. 잠금 호환성(Lock Compatibility) 잠금 호환성이란 이미 다른 트랜잭션이 해당 객체에 대해 잠금을 획득하고 있을 때 한 트랜잭션이 그 객체에 대해 특정 모드의 잠금을 요구하게 되는 경우 그 요구가 받아들여질 수 있는지의 여부를 결정하기 위해 사용되는 잠금 모드 간의 호환성을 의미한다. Granted Mode 트랜잭션 관리 205 Requested Mode NONE IS IX SIX S X IS O O O O O - IX O O O - - - SIX O O - - - - S O O - - O - X - - - - - - [표 8-2] 잠금 모드간의 호환성 레코드 레벨 잠금 모드(Record Level Lock Modes) DML 연산 중 삽입(INSERT), 삭제(DELETE), 갱신(UPDATE) 구문은 개별 레코드에 대한 X 잠금을 잡게 되고, 조회(SELECT)구문은 S 잠금을 잡게 된다. Lock Mode 설명 기능 S Shred Lock 레코드에 대해 조회 작업만 수행할 수 있 다. X Exclusive Lock 레코드에 대해 조회, 변경 작업을 수행할 수 있다. [표 8-3] 레코드 레벨의 잠금 모드 일반적으로 레코드에 대한 S 잠금과 X 잠금은 서로 충돌하기 때문에 호환되지 않는다. 하지만 알티베이스의 경우는 다중 버전 동시성 제어 기법(MVCC)을 사용하기 때문에 서로 충돌하지 않는다. 따라서 갱신 중인 레코드에 대한 조회와 조회중인 레코드에 대한 갱신이 모두 허용된다. 206 Administrator’s Manual 다중 버전 동시성 제어 기법 알티베이스는 동시성 제어를 위해 다중 버전 동시성 제어 (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 기법이 사용되지 않을 때 갱신 연산으로 인해 한 테이블의 레코드가 어떻게 변하는지를 나타낸다. 트랜잭션 관리 207 record A col1 = 1 Table T1 col1=1 -> col1=2 record A Table T1 (a) recordA의 col1칼럼에 1 입력 (b) recordA의 col1의 값을 2로 갱신 [그림 8-1] MVCC 미 사용시의 트랜잭션 처리 위 그림의 (a)는 테이블 T1에 레코드 A가 최초로 삽입된 경우를 나타낸다. 이 레코드 A에 대해 col1의 값을 2로 수정한 경우 위 그림의 (b)에서와 같이 레코드 A의 원래 위치에서 수정이 됨으로써 T1에 할당된 공간은 변화가 없다. 삭제 구문의 경우도 갱신 구문과 마찬가지로 원래 레코드에 대해 삭제 연산이 수행된다. 위 그림과 같이 MVCC 기법을 사용하지 않는 경우에는 갱신 또는 삭제에 의해 테이블에 할당된 공간이 늘어나지 않으며 한 테이블에 할당된 공간이 늘어날 수 있는 경우는 오직 삽입 구문에 의한 경우뿐이다. 메모리 테이블스페이스의 MVCC 알티베이스의 메모리 테이블스페이스에서 사용되는 Out-place MVCC 기법은 갱신 연산이 발생 할 때마다 새로운 버전(version)의 레코드를 생성하고 이전 버전의 레코드과 연결 시킴으로써 구현된다. 갱신(Update) 연산 다음 그림은 Out-place MVCC 기법을 사용하는 경우 갱신 구문의 수행 효과를 보여준다. 208 Administrator’s Manual record A nextoid col1 = 1 record A nextoid col1 = 2 record A nextoid col1 = 3 Table T1 (a) recordA의 col1의 초기 insert 상태 (b) recordA의 col1의 값을 2로 update (c) recordA의 col1의 값을 3으로 update [그림 8-2] MVCC 사용시의 트랜잭션 처리 그림의 (a)에서와 같이 테이블 T1에 레코드 A가 삽입된 상태에서 레코드 A의 col1의 값을 2로 갱신하는 경우 (b)에서와 같이 갱신을 위해 동일한 레코드를 하나 생성한 후 그 레코드에 대해 값을 2로 변경한다. 따라서, 테이블 T1의 공간은 갱신 전의 상태와 비교하여 하나의 슬롯(slot)을 더 차지하게 된다. 레코드 A의 새로운 버전이 추가로 생성되면 레코드 A의 원래 버전의 헤더내의 포인터를 이용하여 새로 추가된 레코드를 가리키게 된다. 이렇게 함으로써 동일한 레코드의 다른 버전들이 동시에 관리될 수 있다. 위 그림의 (b) 상태에서 다시 레코드 A에 대한 갱신 연산이 수행되면 위에서 설명한 바와 같이 추가로 하나의 레코드를 생성하여 그 레코드에 대해 갱신을 수행하게 된다. 그 결과 하나의 동일한 레코드에 대해 여러 번의 갱신 연산이 수행되면 갱신된 횟수만큼 동일한 레코드에 대한 버전이 생기게 된다. 그렇다면 갱신 연산 수행 횟수만큼 테이블 공간은 무한정 커지는가? 특정 레코드에 대해 갱신 연산을 수행하는 각 트랜잭션이 커밋되면, 가장 최근에 생긴 버전만 유효하며 이전 버전들은 데이터베이스에 저장되어 있을 필요가 없다. 이러한 불필요한 버전들은 가비지 콜렉터에 의해 알티베이스 운용 중에 삭제가 되며 삭제된 레코드들이 차지하고 있던 테이블 내의 공간들은 이후 발생하는 삽입/갱신 문에 의해 다시 재사용된다. 따라서, 갱신 연산이 일어난 횟수만큼 레코드의 새로운 버전들이 생긴다 하더라도 데이터베이스 공간이 무한정 커지지는 않는다. 삭제 (Delete) 연산 트랜잭션 관리 209 삭제 연산도 갱신 연산과 마찬가지로 각 레코드에 대해 삭제 연산이 수행되면 하나의 새로운 버전이 생긴다. 삭제 연산의 경우 갱신 연산과 달리 삭제할 레코드에 대한 새로운 버전은 실제 아무런 데이터도 갖고 있지 않다. 따라서, 삭제 연산에 대한 새로운 버전은 삭제되는 레코드 별로 하나씩 생성할 필요가 없다. 삭제된 레코드들을 표시하는 한 개의 버전만 생성하는 것으로 충분하다. 다음 그림은 삭제 연산 수행 시 각 레코드 별로 버전을 생성하는 경우와 그렇지 않은 경우에 대해 테이블 내의 공간 활용도를 보여준다. (a) 삭제되는 든 레코드 별로 새로운 전을 생 하는 경우 (b) 삭제 연산을 위해 한 테이블 내에서 커서 별로 하나의 새 전을 생 하는 경우 Table T1 nextoid DeleteRow nextoid Record A nextoid Record B Table T1 nextoid Record A nextoid DeleteRow Record Bnextoid nextoid DeleteRow-1 [그림 8-3] MVCC 사용시의 삭제 트랜잭션 위 그림의 (a)는 각 레코드 별로 새로운 버전을 생성하는 경우이다. 한 트랜잭션이 하나의 삭제 구문을 이용하여 레코드 A, B를 삭제하는 경우 두 레코드에 대해 각각의 버전을 생성하므로 테이블 210 Administrator’s Manual T1은 추가로 두 개의 레코드가 생성되었다. 위 그림의 (b)는 하나의 삭제 구문에 의해 여러 개의 레코드가 삭제되더라도 하나의 삭제 구문에 대해서는 하나의 새 버전만을 생성하는 경우이다. 위 그림에서 보여지는 것처럼 (b)의 경우가 불필요한 레코드 버전을 적게 만들기 때문에 공간 활용도가 훨씬 높다. 알티베이스는 위 그림의 (b)와 같은 방법으로 메모리 테이블스페이스에 대해 삭제 연산을 수행한다. 디스크 테이블스페이스의 MVCC 알티베이스의 디스크 테이블스페이스에서 사용되는 In-place MVCC 기법은 갱신 연산이 발생 할 때, 기존의 레코드에서 변경되는 칼럼들의 값을 언두 테이블스페이스에 존재하는 언두 페이지에 언두 로그 레코드라는 이름으로 기록하고, 변경 이후 값들을 기존 레코드의 해당 위치에 쓴다. 삽입 연산 최초로 레코드가 삽입되면 알티베이스는 데이터 테이블스페이스에 레코드를 위한 영역을 할당 받아 레코드를 만든다. 알티베이스는 또한 언두 테이블스페이스에 언두 로그 레코드를 위한 영역을 할당받아서 로그 레코드를 작성한다. 마지막으로 알티베이스는 데이터 테이블스페이스의 실제 레코드에 있는 롤백 RID에 이 언두 로그 레코드의 위치를 기록하여 연결 시킨다. 갱신 연산 최초로 삽입된 레코드인 버전1이 있다고 가정하자. 이 버전이 갱신되어 버전2가 되고, 다시 한번 갱신되어 현재 버전3이 되었을 경우의 상황은 다음 그림과 같이 된다. 트랜잭션 관리 211 전 3롤백 RID 이 테이블 스페이스언두 테이블 스페이스 이전 이미지2롤백 RID 이전 이미지1롤백 RID 전 2 전 1 전 3이전 이미지2= = + 전 2+이전 이미지1 [그림 8-4] 디스크 테이블스페이스의 MVCC 위의 그림과 같이 데이터 테이블스페이스에는 항상 최신의 레코드 이미지가 존재한다. 만일 어떤 문장(statement)이 버전3이 커밋되기 전에 시작되었다면 그 문장은 버전3을 읽을 수 없으므로, 더 이전의 이미지인 버전2를 읽어 가야 한다. 이럴 경우에는, 해당 문장은 버전3의 이미지를 자신의 특정 버퍼에 복사한 후, 그 레코드의 롤백 RID가 가리키는 곳에 존재하는 이전 이미지2를 읽어다 버전3를 복사해 둔 곳에 반영하게 된다. 만일 이 버전2마저도 자신이 읽을 수 없는 버전이라면, 다시 그 과정을 반복하여 이전 이미지1을 반영시켜 버전1을 만들어 내게 된다. 만일 버전 1도 읽지 못하는 경우라면 이는 해당 문장이 레코드의 최초 삽입연산이 커밋되기 전에 시작된 것이므로 이 레코드를 없는 것으로 가정하고 무시하게 된다. 언두 로그 레코드 영역의 해제 디스크 테이블스페이스의 경우, 단시간에 다량의 갱신연산이 발생하면 데이터 테이블스페이스의 크기는 별 차이가 없지만, In- place MVCC의 영향으로 언두 로그 레코드의 양이 많아져서 언두 테이블스페이스의 크기가 증가하게 된다. 언두 테이블스페이스의 크기는 최초 CREATE DATABASE 시에 설정되어 변경될 수 없으므로 언두 로그 레코드의 재사용이 필요하다. 언두 로그 레코드는 트랜잭션이 커밋될 때 언두 테이블스페이스 헤더에 등록되어 연결 리스트(linked list)로 관리되다가, 현재 시스템 내의 모든 트랜잭션이 해당 언두 로그 레코드를 참조할 필요가 없어지게 되면 바로 해제 된다. 반면 트랜잭션이 롤백이 되면 언두 로그 레코드들은 언두 테이블스페이스에 등록되지 않고 바로 해제 된다. 삽입 연산에 의해 생성된 언두 로그 레코드들은 갱신 및 삭제 212 Administrator’s Manual 연산에 의해 생성된 로그 레코드들과 따로 관리된다. 이는 삽입 연산에 의해 생성된 언두 로그 레코드들이 트랜잭션 커밋 시점에 바로 해제될 수 있게 하기 위해서이다. 삭제 연산 삭제 연산도 갱신 연산과 동일한 방식으로 수행된다. 단, 삭제 연산에 의해 변경되는 정보는 레코드의 헤더에 삭제 플래그(delete flag)가 설정되는 것이므로, 언두 로그 레코드의 이전 이미지에는 레코드의 헤더 정보만 기록된다. 삭제된 레코드가 점유하던 공간은 바로 재사용되지 않는다. 먼저 해당 레코드에 대한 모든 인덱스의 키들이 삭제되고 실제 레코드가 삭제된 후에, 가비지 콜렉터가 해당 레코드에 대한 삭제 언두 로그 레코드를 삭제한다. 그 뒤에 삭제된 레코드가 점유하던 공간은 재사용 가능하게 된다. In-place MVCC vs. Out-place MVCC 디스크 테이블스페이스에서의 In-place방식은 메모리 테이블스페이스의 Out-place와는 다른 레코드 버전 검사 방법을 사용한다. Out-place방식은 레코드의 새 버전을 생성했던 트랜잭션의 Commit SCN을 그 버전에 저장하고, 이를 이용하여 레코드 버전을 검사한다. 즉, 조회 트랜잭션은 자신의 SCN보다 작은 Commit SCN을 갖는 버전을 읽어 간다. 트랜잭션의 Commit SCN은 트랜잭션 커밋시에 설정되며, 해당 트랜잭션이 생성한 모든 버전에 기록된다. 그러나 디스크 테이블스페이스에서 트랜잭션의 Commit SCN을 설정하는 것은 그 트랜잭션이 생성한 모든 레코드 버전에 대한 접근을 필요로 하는데 이는 실질적으로 불가능하다. 왜냐하면, 디스크 입출력 비용으로 인하여 트랜잭션 성능이 심각하게 저하되기 때문이다. 따라서, 디스크 테이블스페이스를 위한 독특한 Commit SCN검사 방법이 필요하며, 알티베이스에서는 TSS를 이용하여 이를 해결한다. TSS(Transaction Status Slot) 는 트랜잭션의 현재 상태를 표현하고 있는 일종의 레코드이다. 각 TSS에는 Commit SCN이 기록된다. 이러한 TSS는 언두 테이블스페이스에 영구적으로 기록되며, 더이상 사용되지 않는 불필요한 경우, Ager에 의해 삭제된다. 삭제된 TSS는 새로운 트랜잭션에 의해서 재사용된다. 커밋중인 트랜잭션은 자신이 생성한 모든 버전에 Commit SCN을 설정하지 않으며 자신과 관련된 TSS에만 Commit SCN을 설정한다. 트랜잭션 관리 213 또한 레코드 갱신 연산시 TSS 식별자가 해당 레코드에 기록되며, 기록된 TSS 식별자는 레코드 버전 검사를 하는 트랜잭션에 의해서 이용된다. 즉, 트랜잭션은 레코드의 TSS가 갖는 Commit SCN과 자신의 SCN을 비교하여, 자신의 SCN보다 작은 Commit SCN을 갖는 레코드만을 읽어간다. MVCC 사용 시 주의사항 알티베이스는 메모리와 디스크 테이블스페이스 모두를 MVCC 방식으로 동시성 제어 한다. MVCC 는 기존의 전통적인 SVCC(Single Version Concurrency Control)과 달라서 아래와 같이 주의하여야 할 점들이 몇 가지 있다. 장시간 수행되는 트랜잭션에 의한 데이터베이스 크기 증가 특정 트랜잭션이 너무 오랫동안 커밋하지 않고 수행되고 있으면, 이 트랜잭션이 이전 이미지들을 읽을 가능성이 있기 때문에 가비지 콜렉터가 다른 트랜잭션들이 작성한 이전 이미지 정보들(메모리 테이블은 이전 버전, 디스크 테이블은 언두 로그 레코드 정보)과 해당 레코드의 인덱스 키들을 삭제할 수 없게 된다. 이에 따라 메모리 테이블의 크기가 증가되고, 디스크의 언두 테이블스페이스 크기가 증가하게 된다. 또한, 해당 트랜잭션이 롤백할 때를 대비해서 로그 파일도 삭제하지 못하므로, 로그 파일이 존재하는 파일 시스템이 꽉 찰 가능성이 있다. 동시 수행 트랜잭션 과다로 인한 데이터베이스 크기 증가 알티베이스는 MVCC로 인해 생성된 이전 이미지 정보들의 해제를 가비지 콜렉터에게 맡기고 있다. 만일 동시에 수행되는 트랜잭션의 수가 해당 시스템의 CPU개수 보다 현저히 많을 경우에는 가비지 콜렉터가 이전 이미지 정보들을 삭제할 여유를 가지지 못해 데이터베이스 크기가 계속 늘어날 수 있다. 대량의 갱신 연산으로 인한 데이터베이스의 크기 증가 한번에 대량의 이전 정보를 생성해야 하는 연산(bulk update)들이 자주 수행되면, 메모리 테이블은 그 크기가 커지며, 디스크 테이블은 언두 테이블스페이스가 커질 수 있다. 이전 이미지 정보 과다로 인한 성능 저하 위에 열거한 내용들로 인하여 이전 이미지 정보가 데이터베이스 내에 너무 많이 남아있으면 실제로 목적하는 레코드를 찾는데 더 많은 비용이 들어 갈 수 있어서 전체적으로 성능이 느려질 소지가 있다. Repeatable Read Vs. Consistent Read SVCC 로 구현된 일반적인 DBMS들은 레코드를 읽었을 때 S 잠금이 잡히게 되므로 X 잠금과 충돌하여 읽는 동안 레코드가 214 Administrator’s Manual 변하지 않으므로, 데이터베이스의 격리도(Isolation Level)가 보통 Repeatable Read로 동작한다. 반면 알티베이스는 검색 연산이 수행 중에도 동일 레코드에 대해 갱신 연산이 가능하여 Consistent Read가 기본적인 격리도가 된다. 따라서, 한 트랜잭션이 커밋되지 않고 같은 테이블을 여러 번 조회하면 매번 서로 다른 결과 집합을 얻을 수도 있다. 만일 이를 방지하려면 격리도를 Repeatable Read로 변경시키고 연산을 수행하거나, SELECT FOR UPDATE 구문을 사용하여 연산을 수행하여야 한다. 트랜잭션 관리 215 트랜잭션의 영속성 일반적으로 트랜잭션이란 저장 객체(페이지 또는 레코드, DBMS마다 구현 차이가 있음)에 대한 일련의 조회와 갱신 작업의 독립된 작업 단위를 의미한다. 데이터베이스 관리 시스템은 성능향상을 위해서 여러 트랜잭션이 동시에 인터리빙(interleaving)해서 수행되도록 지원하고 있으며, 여러 트랜잭션이 어떤 순서로 수행되더라도 그 결과는 차례대로 하나씩 수행한 결과와 동일하도록 동시성 제어(concurrency control)를 해주고 있다. 따라서 예측하지 못한 모든 시스템 장애 상황에서도 모든 데이터를 정확하게 관리(crash recovery)하기 위해 다음과 같은 트랜잭션의 4가지 속성을 보장하도록 설계되어 있다. 원자성 (atomicity) 일관성 (consistency) 격리성 (isolation) 영속성 (durability) 영속성의 개념 트랜잭션의 4가지 속성 중 영속성(durability)은 한 트랜잭션이 커밋된 후에 데이터베이스 객체에 대한 해당 변경 사항이 디스크에 반영(flush)되기 전에 시스템 장애가 발생하더라도, 해당 커밋된 트랜잭션은 보장되어야 한다는 속성이다. 데이터베이스 관리 시스템은 트랜잭션의 영속성을 지키기 위해 트랜잭션 로그(log) 즉, 데이터 변경 작업에 대한 정보가 기록된 리두 로그 레코드를 관리한다. 커밋된 트랜잭션에 의해 갱신된 내용이 디스크에 반영되기 전에 시스템 장애가 발생하면, 시스템 재구동시에 로그를 판독하여 변경된 내용을 복구하게 되는 것이다. 트랜잭션의 영속성은 트랜잭션의 처리 성능과 밀접한 관련이 있는 중요한 요소이다. 디스크 기반 DBMS에 비해 성능이 수십배 더 좋은 메모리 기반 DBMS에서 영속성을 보장하는 것은 디스크 기반 DBMS에 비해 성능에 미치는 영향이 훨씬 크다. 예를 들어, DBMS가 완벽한 트랜잭션 영속성을 제공하기 위해서는 모든 데이터베이스 갱신에 대한 로그 기록이 빠짐없이 디스크의 로그파일에 반영되어야 한다. 메모리 로그 버퍼에 존재하는 모든 로그들을 로그파일에 반영할 때는 디스크 I/O가 발생하게 되며, 이 때 발생하는 디스크 I/O는 트랜잭션 처리의 병목(bottleneck)으로 216 Administrator’s Manual 작용하게 되어 트랜잭션 처리 성능 저하의 원인으로 작용한다. 즉, 완벽한 트랜잭션 영속성과 트랜잭션 처리 성능 관계는 안정성과 성능이라는 상반되는 목표를 가지는 상충(tradeoff) 관계에 있다고 볼 수 있다. 알티베이스는 트랜잭션의 영속성을 완벽하게 보장하고 있으며, 여러 시스템 상황에 따라서 고성능의 트랜잭션 처리를 제공하기 위해 트랜잭션 처리 성능과 트랜잭션 영속성의 균형을 조절할 수 있도록 트랜잭션 영속성 관리 방법을 지원한다. 트랜잭션 영속성 관리 방법 알티베이스는 트랜잭션의 영속성(durability)을 altibase.properties 파일의 COMMIT_WRITE_WAIT_MODE 프로퍼티와 LOG_BUFFER_TYPE 프로퍼티로 관리한다. COMMIT_WRITE_WAIT_MODE는 변경 로그가 디스크 로그 파일에 반영이 완료될 때까지 트랜잭션이 대기할 것인지 여부를 설정한다. 이 프로퍼티는 전체 시스템 또는 각 세션별로 설정될 수 있다. LOG_BUFFER_TYPE는 변경 로그가 로그 파일에 기록될 때 사용될 로그 버퍼의 타입을 설정한다. 이 프로퍼티는 시스템 운영 중에 변경할 수 없다. 프로퍼티에 대한 보다 자세한 설명은 General Reference를 참조하기 바란다. 트랜잭션이 로그가 디스크에 기록될 때까지 대기하지 않고 커널 로그 버퍼가 사용되는 경우 In OS Kernel memory In Altibase process logfile sync threads logfiles log buffer sync txtx [그림 8-5] 트랜잭션이 로그가 디스크에 기록될 때까지 대기하지 않고 커널 로그 버퍼가 사용되는 경우의 영속성 트랜잭션 관리 217 COMMIT_WRITE_WAIT_MODE와 LOG_BUFFER_TYPE를 모두 0으로 설정한다. 영속성 프로퍼티의 기본값으로 운영체제 커널 영역의 로그 버퍼를 사용하여 변경 로그를 기록하며 변경 로그가 로그 파일에 반영될 때까지 트랜잭션이 대기하지는 않는다. 트랜잭션이 로그가 디스크에 기록될 때까지 대기하지 않고 메모 리 로그 버퍼가 사용되는 경우 In Altibase process log bufferlogfile sync threads logfiles sync txtx [그림 8-6] 트랜잭션이 로그가 디스크에 기록될 때까지 대기하지 않고 메모리 로그 버퍼가 사용되는 경우의 영속성 COMMIT_WRITE_WAIT_MODE와 LOG_BUFFER_TYPE를 0과 1로 각각 설정한다. 트랜잭션은 변경 로그를 메모리 로그 버퍼에 기록하고 sync 쓰레드가 자체적으로 로그 버퍼에 있는 로그를 로그 파일에 플러시한다. 트랜잭션이 로그가 디스크에 기록될 때까지 대기하고 커널 로그 버퍼가 사용되는 경우 In OS Kernel memory In Altibase process logfile sync threads logfiles log buffer sync txtx [그림 8-7] 트랜잭션이 로그가 디스크에 기록될 때까지 대기하고 커널 로그 버퍼가 사용되는 경우의 영속성 218 Administrator’s Manual COMMIT_WRITE_WAIT_MODE와 LOG_BUFFER_TYPE를 1과 0으로 각각 설정한다. 트랜잭션이 변경 로그를 운영체제 커널의 로그 버퍼에 기록하고 직접 커밋 로그를 로그 파일까지 반영한다. 트랜잭션 관리 219 트랜잭션이 로그가 디스크에 기록될 때까지 대기하고 메모리 로 그 버퍼가 사용되는 경우 In Altibase process log buffer logfile sync threads logfiles txtxtx txtx sync [그림 8-8] 트랜잭션이 로그가 디스크에 기록될 때까지 대기하고 메모리 로그 버퍼가 사용되는 경우의 영속성 COMMIT_WRITE_WAIT_MODE와 LOG_BUFFER_TYPE를 모두 1로 설정한다. 트랜잭션이 변경 로그를 메모리의 로그버퍼에 기록하고 앞의 경우와 마찬가지로 직접 커밋 로그를 로그 파일까지 반영한다. 버퍼 관리자 221 9. 버퍼 관리자 알티베이스 디스크 테이블스페이스의 데이터 객체가 접근 또는 갱신되기 위해서는 디스크로부터 메모리에 적재되어야 한다. 이렇게 임시로 사용되는 메모리를 버퍼라고 하며, 알티베이스에서는 이 메모리를 일괄적으로 버퍼 풀이라고 한다. 디스크의 모든 데이터를 버퍼 풀에 쌓아두면 어떤 데이터에 대한 접근이라도 디스크 I/O 없이 빠르게 수행된다. 하지만 한정된 메모리로 인해 디스크 데이터의 일부만 버퍼 풀에 적재할 수 있다. 버퍼 풀에 적재된 데이터는 다른 데이터에 의해 제거될 수 있는데, 이를 데이터 교체라고 한다. 이 때 어떤 데이터를 버퍼에 오래 둘 것인가는 시스템 성능에 중요한 영향을 주기 때문에 효율적인 알고리즘이 사용되어야 한다. 알티베이스에서는 버퍼 풀을 관리하는 주체를 버퍼 관리자 (Buffer Manager)라고 한다. 버퍼 관리자의 주된 역할은 자주 접근되는 데이터를 보다 버퍼에 오래 두어 효율적으로 버퍼를 관리하는 데 있다. 이 장에서는 버퍼 관리자의 구조와 기능, 버퍼 풀 관리 방법 및 관련 프로퍼티 등에 대해 설명한다. 222 Administrator’s Manual 버퍼 관리자의 구조 버퍼 관리자 구성요소 버퍼 관리자의 구성요소에는 버퍼 영역, 버퍼 풀, 버퍼 프레임, 및 BCB (Buffer Control Block)가 있다. 버퍼 풀의 버퍼들은 효율적인 관리를 위해 LRU 리스트, 프리페어(prepare) 리스트, 플러시(flush) 리스트, 체크포인트(checkpoint) 리스트, 해시(hash) 테이블로 구성된다. 이 절에서는 버퍼 관리자의 구성요소에 대해 설명한다. 버퍼 영역 (Buffer Area) 버퍼 영역은 준비된 메모리 공간으로 이는 버퍼 풀에 할당된다. 버퍼 관리자에 의해 관리되는 버퍼 크기는 버퍼 영역의 크기에 따른다. 버퍼 풀 (Buffer Pool) 버퍼 풀은 버퍼 관리자의 핵심 요소로, 버퍼를 교체하는 정책을 구현한다. 요청된 데이터 페이지를 버퍼에 적재하고 적재된 페이지 영역의 메모리 주소를 반환한다. 버퍼 풀은 내부적으로 해시 테이블과 LRU 리스트, 프리페어 리스트, 및 플러시 리스트들로 BCB들을 관리한다. 버퍼 프레임 (Buffer Frame) 버퍼 프레임은 메모리에 하나의 페이지를 적재할 수 있도록 확보된 공간으로, 하나의 버퍼 프레임은 하나의 페이지와 크기가 같다. 버퍼 프레임이 모여서 버퍼 풀을 구성한다. BCB (Buffer Control Block) BCB는 버퍼 프레임에 대한 정보를 가지며, 하나의 BCB는 하나의 버퍼 프레임에 대응된다. 버퍼 관리자는 버퍼에 적재된 모든 페이지에 대한 정보를 BCB로 관리하며, 버퍼 프레임은 단지 페이지가 메모리에 적재되는 공간이다. 각 BCB는 대응하는 버퍼 프레임에 대한 주소를 유지한다. 다음의 그림과 표는 BCB의 구조와 정보를 설명한다. 버퍼 관리자 223 BCBBCBBCBBCB 버퍼 프레임버퍼 프레임버퍼 프레임버퍼 프레임 [그림 9-1] BCB 구조 속성 설명 BCB 상태 (BCB Status) BCB의 현재 상태를 나타낸다. 가능한 값은FREE, CLEAN, DIRTY이다. FREE: 버퍼에 페이지가 적재되지 않은 상태 CLEAN: 버퍼에 페이지가 적재되었지만 갱신되지 않은 상태 DIRTY: 버퍼의 페이지가 갱신되었으나 디스크에는 반영되지 않은 상태 버퍼 프레임 주소 (Buffer Frame Address) 이 BCB에 해당하는 버퍼 프레임의 주소 테이블스페이스 식별자 (Space ID) 페이지가 속한 테이블스페이스의 식별자 페이지 식별자 (Page ID) 테이블스페이스내의 페이지들이 갖는 고유 번호 페이지 소유자의 록 (Page Owner Lock) 페이지에 접근하기 위해서는 우선 록을 획득해야 한 다. Read, Write, 또는 Fix 모드로 얻을 수 있다. 페이지에 대응하는 BCB에 대해 록을 특정 모드로 획득한 후에, 버퍼에 올라온 페이지에 해당 모드로 접근할 수 있다. 수정 LSN (Modified LSN) 버퍼내의 페이지가 수정된 시점의 LSN(Log Sequence Number)이다. 이 값은 플러셔가 버퍼에 올라온 페이지를 플러시할 때 어느 시점의 로그에 해당하는 변경까지 플러시할 것인지 나타낸다. Fix 개수 (Fix Count) 페이지에 동시에 접근하고 있는 트랜잭션의 개수이 다. 이 값이 1 이상이면 그 페이지는 교체될 수 없 으며, 0이면 교체가 가능하다. 224 Administrator’s Manual 접근 회수 (Touch Count) 페이지가 버퍼에 적재된 후 트랜잭션들이 접근한 회 수이다. 이 값은 버퍼의 hot, cold 여부를 판단하는 데 사용된다. [표 9-1] BCB 정보 해시 테이블 알티베이스 서버는 페이지에 대한 요청이 들어오면 해당 페이지가 버퍼에 적재되었는지 확인하기 위해 해시 테이블내에서 그 페이지의 BCB를 찾는다. 해시 테이블에는 버퍼에 적재된 모든 페이지에 대한 BCB가 등록되어 있다. LRU (Least Recently Used) List 이는 접근한지 오래된 버퍼를 우선 교체 대상으로 선정하기 위해 사용된다. 알티베이스는 LRU 리스트를 hot-cold 영역으로 나누어 관리하고 있어 “hot-cold LRU List”라고도 한다. 접근 빈도가 높은 버퍼들은 hot 영역에 넣고, 그렇지 않은 버퍼들을 cold 영역에 넣어 교체 대상 검색시 cold 영역만 확인하기 때문에 hot 버퍼들은 교체 대상에서 제외된다. 버퍼에 페이지가 처음 적재될 때, 이는 mid-point(LRU cold first)에 삽입된다. 새로운 데이터 페이지에 버퍼를 할당할 때, Prepare리스트에 빈 버퍼가 없으면 이 리스트의 마지막(LRU cold last)부터 검색하여 cold 버퍼가 교체된다. 교체되는 버퍼를 “victim”이라고 한다. HOT COLD LRU hot firstLRU hot lastmid point 또는 LRU cold firstLRU cold last 그림 9-2 hot-cold LRU list 검색하는 도중에 접근 빈도가 높은 버퍼는 hot 영역인 LRU hot first로 옮겨진다. 또한 페이지가 갱신되었지만 디스크에 플러시되지 않은 dirty 버퍼는 Flush 리스트로 옮겨진다. 그리고 버퍼에 페이지가 올라왔지만 갱신되지 않은 clean 버퍼가 hot 영역에 있지 않으면 교체 대상 버퍼로 선정된다. hot 영역의 비중은 HOT_LIST_PCT프로퍼티로 조정이 가능하다. 기본값은 50이며, 이는 LRU 리스트의 절반을 hot 영역으로 사용한다는 의미이다. 버퍼 관리자 225 Flush List LRU 리스트에서 교체 대상을 검색할 때 dirty 버퍼가 나타나면 플러시 리스트로 옮겨진다. 플러시 리스트는 페이지가 갱신되었지만 디스크에는 아직 반영되지 않은 버퍼들이 모여있는 리스트이다. 그러나 모든 dirty 버퍼가 플러시 리스트에 있는 것은 아니다. 갱신된 시점에 플러시 리스트로 옮겨지는 것이 아니라 LRU 리스트에서 교체 대상을 검색하는 과정에서 플러시 리스트로 옮겨지기 때문이다. 교체 플러시(replacement flush)가 발생하면 이 리스트의 갱신된 페이지는 디스크에 반영되고, clean 버퍼가 확보된다. Prepare List 플러시 리스트에서 디스크로 반영이 된 버퍼들은 모두 Prepare 리스트로 옮겨진다. 즉 Prepare 리스트는 플러시 작업을 마친 clean 버퍼들로 구성된 리스트이다. 버퍼 관리자는 교체 대상 버퍼를 찾을 때 우선 Prepare 리스트를 검색한다. 만약 Prepare 리스트에서 적합한 버퍼를 찾을 수 없다면 LRU 리스트를 찾아본다. 그러나 버퍼가 Prepare 리스트에 있어도 갱신이 가능하기 때문에 항상 clean 상태인 것은 아니다. Checkpoint List LRU 리스트, Flush 리스트, Prepare 리스트는 상호 배타적인 리스트이기 때문에 한 개의 버퍼는 이 중의 두 개 이상의 리스트에 존재할 수 없다. 그러나 체크포인트 리스트는 세가지 리스트와 달리 독립적으로 관리가 가능하기 때문에 다른 세가지 리스트에 존재하는 버퍼가 체크포인트 리스트에 속할수 있다. dirty 버퍼 즉 갱신된 버퍼들은 체크포인트 리스트에 존재하게 되며, 체크포인트 리스트의 모든 버퍼는 dirty 상태이다. 이 리스트의 버퍼들에는 처음에 갱신된 시점에 해당하는 LSN이 부여되며, 이를 기준으로 정렬 관리된다. 체크포인트 리스트가 플러시될 때 체크포인트 리스트의 LSN이 작은 버퍼부터 플러시 된다. [그림 8-3]은 LRU 리스트, Flush 리스트, Prepare 리스트의 모든 버퍼들이 해시 테이블을 통해 접근이 가능한 것을 나타낸다. 226 Administrator’s Manual BCB 해시테이블 LRU List Flush List Prepare List Checkpoint List 그림 9-3 버퍼 풀(Buffer Pool) List 다중화 LRU 리스트, Flush 리스트, Prepare 리스트, 체크포인트 리스트는 각각 다중화가 가능하다. 리스트 다중화를 통해 다수의 데이터베이스 클라이언트가 동시에 서비스 요청시 리스트 록(LOCK) 경합이 발생하는 것을 방지한다. 각 종류별 리스트의 개수는 BUFFER_LRU_LIST_CNT, BUFFER_PREPARE_LIST_CNT, BUFFER_FLUSH_LIST_CNT, 및 BUFFER_CHECKPOINT_LIST_CNT프로퍼티에 설정할 수 있고, 설정된 값은 V$BUFFPOOL_STAT성능 뷰의 LRU_LIST_COUNT, PREPARE_LIST_COUNT, FLUSH_LIST_COUNT, 및 CHECKPOINT_LIST_ COUNT 칼럼을 조회해서 확인할 수 있다. 그러나 서버가 운영중일 경우에는 이들 값의 변경이 불가하다. BCB 상태 전이 각 BCB의 상태는 항상 FREE, CREAN, DIRTY 3가지 중의 하나이다. FREE 버퍼에 어떤 페이지도 적재되지 않은 상태이다. 시스템이 처음 구동되면 대부분의 버퍼들이 free 상태가 된다. 또한 테이블스페이스가 삭제(drop)되거나 오프라인(offline)으로 되면 해당 테이블스페이스에 속한 페이지에 해당하는 모든 버퍼들은 free상태로 된다. CLEAN 버퍼에 페이지가 적재되어 있지만 아직 갱신되지 않은 상태이다. 즉, 버퍼의 페이지 내용이 디스크의 페이지 내용과 동일한 상태이다. 이 버퍼 관리자 227 버퍼는 해시 테이블로 접근될 수 있다. LRU 이 버퍼는 리스트, 플러시 리스트, Prepare 리스트 중 하나에 있을 수 있으나, 체크포인트 리스트에는 있을 수 없다. DIRTY 버퍼에 있는 페이지가 갱신은 되었으나, 디스크에는 반영되지 않은 상태이다. DIRTY 버퍼는 체크포인트 리스트에 포함되며, LRU 리스트, 플러시 리스트, Prepare 리스트 중 하나에도 속한다. 더티 버퍼는 플러시 된 후 CLEAN 상태로 변경된다. 플러셔 (Flusher) 플러셔(Flusher)는 교체될 모든 버퍼를 디스크에 반영하는 플러시(flush)를 수행한다. 알티베이스에서는 두 종류의 플러시가 행해지는데, 교체 플러시(Replacement Flush)와 체크포인트 플러시(Checkpoint Flush)가 있다. 교체 플러시(Replacement Flush) 버퍼 교체를 위해 접근된지 오래된 갱신된 버퍼를 플러시 체크포인트 플러시(Checkpoint Flush) 체크포인트 시간을 줄이기 위해 처음 갱신한 시점이 오래된 버퍼를 플러시 교체 플러시는 주기적으로 발생하거나 교체 대상 버퍼를 찾지 못했을 때 강제적으로 수행된다. 체크포인트 플러시 역시 주기적으로 발생할 수 있으나 사용자가 ALTER SYSTEM CHECKPOINT 명령으로 수행할 수 있다. 플러셔는 교체 플러시를 먼저 수행한 후 해당 작업이 없을 때에만 주기적으로 체크포인트 플러시를 수행한다. 즉 플러셔는 일정 시간을 대기한 후 교체 플러시를 할 버퍼가 있으면 디스크에 반영한다. 플러셔는 DEFAULT_FLUSHER_WAIT_SEC이상 MAX_FLUSHER_WAIT_SEC 미만의 시간을 대기한다. 교체 플러시 이후 다시 일정 시간을 대기하여 교체 플러시할 대상이 없으면 체크포인트 플러시의 작업 여부를 판단하여 플러시를 하거나 다시 대기한다. 체크포인트 플러시가 발생하기 위한 조건은 다음과 같다. 마지막으로 플러셔가 플러시한 후 CHECKPOINT_FLUSH_MAX_WAIT_SEC이 지났을 때 시스템 재구동시 복구해야 하는 페이지들에 대한 로그 수가 일정 개수를 넘어설 때. 즉 갱신되었으나 디스크에 플러시되지 228 Administrator’s Manual 않은 페이지들이 갖는 LSN 중에서 가장 작은 LSN이 CHECKPOINT_FLUSH_MAX_GAP 만큼 벌어졌을 때 그러나 플러셔가 오랜 시간을 대기하도록 설정되었다고 하더라도, 트랜잭션이 자주 발생하여 교체할 버퍼가 많이 발생하면 강제적인 플러셔도 가능하다. 체크포인트 플러시를 위해 플러셔가 한 번의 주기에서 플러시 할 수 있는 버퍼 페이지(프레임)의 개수는 CHECKPOINT_FLUSH_COUNT 프로퍼티를 사용해서 명시할 수 있다. 또한 BUFFER_FLUSHER_CNT프로퍼티의 값을 조정하여 다수의 플러셔를 둘 수 있다. 그러나 이 프로퍼티는 서버 운영중에는 변경될 수 없다. 각각의 플러셔는 ALTER SYSTEM START/STOP FLUSHER 구문으로 구동 또는 정지시킬 수 있다. SQL에 대한 자세한 내용은 SQL Reference를 참조하기 바란다. 버퍼 관리자 229 버퍼 관리 접근 모드 페이지에 접근하기 위해서는 우선 록(Lock)이 획득되어야 한다. 접근 모드는 페이지에 대한 접근을 어떤 권한으로 허가해 줄 것인가에 따라 다음과 같이 Read, Write, Fix로 구분된다. 접근 모드 설명 Read(읽기) 버퍼에 올라온 페이지를 읽기 위한 접근 모드이다. 여러 개의 트랜잭션이 동시에 페이지에 접근할 수 있다. Write(쓰기) 버퍼에 올라온 페이지에 쓰기 위한 접근 모드이다. 쓰기 모드로는 한 시점에 하나의 트랜잭션만 같은 페이지 접근이 가능하다. Fix 이 접근 모드로 버퍼에 페이지를 올리면, 이 페이 지는 버퍼 관리자에 의해 교체되지 않는다. Fix 모 드로 트랜잭션이 페이지에 접근하여 데이터를 읽으 면 그 데이터가 정확한 데이터임이 보장되지 않는 다. 정확한 데이터를 읽기 위해서는 페이지에 읽기 (Read) 모드로 접근해야 한다. [표 9-2] 버퍼 접근 모드 접근 모드간 허가 관계를 살펴보면 [표 8-3]과 같다. 타 트랜잭션 획득 모드 요청한 접근 모드 Read Write Fix Read O X O Write X X O Fix O O O [표 9-3] 접근 모드간 허가 관계 [표 8-3]은 트랜잭션이 write 모드를 요청한 경우, 이미 다른 트랜잭션이 read나 write를 획득중이라면, 페이지에 대한 해당 접근 모드의 요청은 대기하거나 실패한다는 것을 나타낸다. 또는 read를 요구한 경우에 이미 다른 트랜잭션이 그 페이지에 read 접근 모드로 락을 획득하고 있다면 접근이 성공하지만, write 접근 모드로 락을 획득하고 있다면 이 요청은 실패한다. 230 Administrator’s Manual 대기 모드 대기 모드는 이미 다른 트랜잭션이 페이지를 사용하고 있어 요구한 접근 모드를 허가해 줄 수 없는 경우, 대기할 것인가 혹은 대기하지 않고 바로 에러를 리턴할 것인가를 결정한다. 대기 모드 설명 대기 (Wait) 다른 트랜잭션이 작업을 마치고 록(Lock)을 해제할 때까지 해당 트랜잭션이 대기한다. 대기 안 함 (No-Wait) 다른 트랜잭션이 작업을 마치는 것을 대기하지 않 고 해당 트랜잭션은 바로 에러를 리턴한다. [표 9-4] 대기 모드 페이지 요청 처리 절차 1. 해시 테이블 검색 버퍼 관리자는 페이지 식별자, 접근 모드, 및 대기 모드가 포함되어 있는 페이지 요청을 받는다. 버퍼 관리자가 요청을 받으면, 먼저 해시 테이블에 해당 BCB가 있는지 검사한다. 요청된 페이지가 이미 버퍼에 적재되어 있다면, 해당 페이지를 기술하는 BCB는 해시 테이블에서 검색될 것이다. 만약 해시 테이블에서 그 BCB를 찾을 수 없다면 페이지는 버퍼에 올라오지 않은 것이므로, 버퍼 관리자느 디스크로부터 페이지를 읽어 버퍼에 적재해야 한다. 버퍼 관리자 231 Hash Table BCBBCBBCB BCBBCBBCB TBS IDPage ID 1. 페이지 2. 3. 페이지 DB 4. 스 에서 페이지 어 [그림 9-4] 해시 테이블 검색 2. Lock 획득 알티베이스는 항상 정확한 데이터를 읽도록 보장하기 위해 디스크로부터 read가 진행중인 페이지는 read가 끝날 때까지 접근하지 않는다. 이를 위해 알티베이스는 디스크로부터 read를 수행할 때 write 권한을 획득한다. 임의의 트랜잭션이 한 페이지에 대해 read 혹은 write 권한을 획득할 수 있다면, 그 시점에는 디스크로부터 read가 진행 중이 아님을 의미한다. Lock의 허가는 [표 8-5]와 같이 접근 모드, 디스크로부터 페이지 읽기, 및 대기 모드에 따라 달라진다. 접근 모드 디스크로부터 읽기 대기 모드 Lock 획득 결과 Fix O 상관없다 읽기가 끝날 때까지 대기 후 허가 Fix X 상관없다 허가 Read O 대기 접근 모드가 허가되면 허가, 실패 시 대기 Read O 대기안함 접근 모드가 허가되면 허가, 실패 시 대기 232 Administrator’s Manual Read X 대기 접근 모드가 허가되면 허가, 실패 시 대기 Read X 대기안함 접근 모드가 허가되면 허가, 실패 시 바로 에러 리턴 Write O 대기 접근 모드가 허가되면 허가, 실패 시 대기 Write O 대기안함 접근 모드가 허가되면 허가, 실패 시 대기 Write X 대기 접근 모드가 허가되면 허가, 실패 시 대기 Write X 대기안함 접근 모드가 허가되면 허가, 실패 시 바로 에러 리턴 [표 9-5] Lock 획득 허가 [표 8-5]에서 나타나는 것처럼, Fix모드로 접근을 요청한 경우 현재 페이지가 어떤 권한으로 록(Lock)이 잡혀 있더라도 바로 허가 될 것이다. 그러나 디스크로부터 페이지를 읽어오는 중이라면 read가 끝날 때까지 그 요청은 대기한다. 또는 Read 또는 Write 권한과 대기를 하지 않는 모드로 접근이 요청되는 경우, 만약 디스크로부터 페이지를 읽어오는 중이라면 Read가 끝날 때까지 그 요청은 대기한다. 디스크로부터 페이지 읽기 버퍼 관리자가 페이지를 요청하였을 때, 버퍼에 존재하지 않는다면 디스크로부터 페이지를 읽는 과정을 수행한다. 1. 사용 가능한 BCB 획득 알티베이스 서버가 버퍼에 존재하지 않는 페이지를 버퍼로 적재하기 위해서는 우선 BCB를 확보해야 한다. 페이지가 적재될 버퍼를 찾기 위해 먼저 Prepare 리스트를 검색한다. Prepare 리스트에서 free 버퍼를 찾으면 페이지 적재를 가장 쉽게 수행할 수 있다. 그러나 이 방법으로 free 버퍼를 확보하지 못하면, 다음 단계로 교체할 버퍼를 찾는다. 시스템 구동 초기에는 많은 free 버퍼가 존재하지만, 테이블스페이스가 삭제(drop) 또는 오프라인으로 되지 않는 이상 버퍼 풀에 free 버퍼가 존재할 가능성은 낮다. 특히 플러시한 후에도 버퍼에는 페이지 내용이 유지되기 때문에 free 버퍼가 새로 생기지는 않는다. 2. 버퍼 교체 버퍼 관리자 233 교체할 버퍼를 검색할 때 먼저 prepare 리스트가 검사된다. prepare 리스트는 플러시 되어 플러시 리스트로부터 옮겨진 clean 버퍼를 보유하고 있기 때문이다. prepare 리스트에서 적합한 교체 대상 버퍼를 찾지 못했다면 LRU 리스트가 검색된다. 그러나 LRU 리스트를 검색했는데도 clean 버퍼를 찾지 못했다면, 또 다른 prepare 리스트를 검사한다. 이 과정을 clean 버퍼를 찾을 때까지 prepare 리스트 개수만큼 반복한다. 그러나 모든 prepare 리스트를 검색하여도 clean 버퍼를 찾지 못한다면, 플러셔들을 작동시키고, prepare 리스트에 버퍼가 삽입될 때까지 대기한다. 이 대기 시간은 BUFFER_VICTIM_SEARCH_INTERVAL프로퍼티로 설정된다. 그러나 대기시간 동안에도 clean 버퍼를 찾지 못 할 경우, 다음 prepare 리스트에서 검색을 진행한다. 이를 victim search warp이라고 한다. V$BUFFPOOL_STAT성능 뷰에서 VICTIM_SEARCH_WARP 값이 증가하고 있다면 버퍼 교체를 위해 많은 대기를 하고 있다는 의미이다. 이러한 문제가 지속된다면 버퍼의 크기를 늘리거나 플러셔의 개수를 증가시켜 시스템을 재구동시켜야 할 것이다. LRU list에서 버퍼 교체 대상이 되기 위해서는 다음의 조건을 만족해야 한다. 아무도 fix하지 않은 것 (fix count가 0인 버퍼) 버퍼에 적재되었으나 아직 갱신되지 않은 페이지 (clean 버퍼 상태) 버퍼가 Hot하지 않는 것 (touch count가 HOT_TOUCH_CNT 미만인 버퍼) 교체 대상 버퍼를 찾으면 해시 테이블에서 제거를 한 후 다음 과정을 진행한다. 3. 읽기 후 페이지 검증 BCB가 확보되면 디스크로부터 페이지를 버퍼에 적재한다. 그러나 디스크에 저장된 페이지는 하드 디스크 이상이나 정전 등의 예상하지 못한 이유로 일부 페이지의 내용이 유실될 수 있다. 이러한 상황을 인식하지 못하면 사용자는 잘못된 데이터를 볼 수 있기 때문에, 알티베이스 서버는 이를 인식할 수 있어야 한다. 이를 위해 알티베이스 서버는 디스크로부터 페이지를 버퍼에 적재한 후 바로 해당 페이지가 무결한지 검사한다. 234 Administrator’s Manual 1. free BCB DB 2. read from disk Free List BCBBCBBCBBCB 3. validate pageRead Success [그림 9-5] 페이지 검증 플러시(Flush) 1. 플러시할 버퍼 선정 버퍼에 적재된 이후 수정된 페이지는 희생자로 선택되거나 체크포인트를 할 때 디스크에 플러시된다. 버퍼에 적재된 페이지가 플러시되기 위해서는 다음의 조건을 만족해야 한다. 적어도 한 번 수정되어야 함 fix 개수가 0이어야 함 플러시 중에 다른 트랜잭션에 의한 읽기는 동시에 가능하다. 즉 플러시 수행을 위해서는 read 모드 권한이 획득된다. 2. IO 버퍼에 페이지 복사 플러시 대상 페이지가 정해지면 이 페이지는 디스크에 기록되기 전에 먼저 I/O 버퍼라는 메모리 공간에 복사된다. 디스크 I/O 작업은 메모리 연산에 비해 긴 시간을 소요하기 때문에 I/O 버퍼라는 메모리 공간에 먼저 복사가 된 후, 디스크에 기록된다. 버퍼 페이지가 I/O 버퍼에 복사되면 그 버퍼는 다른 트랜잭션에 의해 읽혀질 수도 있고, 재갱신될 수도 있다. 그러나 /O 버퍼가 버퍼 관리자 235 사용되지 않는다면 페이지가 디스크에 기록되는 동안 (즉, 디스크 I/O 작업이 일어나는 동안) 그 페이지는 갱신되거나 읽혀질 수 없을 것이다. 3. 로그 플러시 수정된 페이지가 디스크에 반영되기 전에 수정된 내용에 대한 로그가 먼저 디스크에 반영되어야 한다. 이를 WAL(Write-Ahead Logging) 프로토콜이라고 한다. 그리고 디스크로부터 버퍼에 페이지가 적재될 때 이 페이지의 데이터가 깨졌는지 확인하기 위해서 체크 섬이 계산된다. 페이지를 디스크로부터 읽을 때마다 이 체크 섬을 계산하여 페이지의 체크 섬과 비교함으로써 페이지가 무결한지 여부를 가리게 된다. 4. I/O 버퍼의 페이지들을 디스크에 기록 I/O 버퍼의 페이지들이 디스크에 기록될 때 이 버퍼의 내용은 더블 라이트 파일(Double-write file)에 모두 한 번에 기록된 후, 각각의 페이지가 데이터 파일에 기록된다. 이처럼 디스크에 두 번 기록하는 이유는 페이지를 디스크에 기록하는 중에 시스템 장애가 발생하면 디스크에는 부분 쓰기(partial write)된 페이지가 남게 되는데 이는 복구가 불가능하기 때문이다. 일관성이 깨진 페이지에 대해서는 리두 로그(redo log)로도 복구가 불가능하다. 알티베이스에서는 DOUBLE_WRITE_DIRECTORY 프로퍼티를 사용해서 더블 라이트 파일이 저장될 디렉터리가 지정된다. 이 파일은 시스템 구동시 데이터 파일의 정합성을 검증 또는 복구하기 위해 사용되며, 이 파일이 없으면 이 과정은 생략된다. 236 Administrator’s Manual 1. Flush 대상 정 2. Flush Log 3. Checksum 산 BCB Flush List BCBBCBBCB Log Page DBDW 파일 4 . DW 에 복사 IO Buffer 5. DW 에 write 6 . DB 에 write [그림 9-6] 페이지 플러시 과정 버퍼 관리자 237 버퍼 관련 프로퍼티 버퍼 관리자를 사용하기 위해서는 알티베이스 프로퍼티 파일의 프로퍼티들을 사용 목적에 맞게 설정해야 한다. 버퍼와 관련된 프로터티는 다음과 같다. 각 프로퍼티에 대한 상세한 설명은 General Reference 를 참조한다. BUFFER_AREA_CHUNK_SIZE BUFFER_AREA_SIZE BUFFER_CHECKPOINT_LIST_CNT BUFFER_FLUSH_LIST_CNT BUFFER_FLUSHER_CNT BUFFER_HASH_BUCKET_DENSITY BUFFER_HASH_CHAIN_LATCH_DENSITY BUFFER_LRU_LIST_CNT BUFFER_PINNING_COUNT BUFFER_PINNING_HISTORY_COUNT BUFFER_PREPARE_LIST_CNT BUFFER_VICTIM_SEARCH_INTERVAL BUFFER_VICTIM_SEARCH_PCT CHECKPOINT_FLUSH_COUNT CHECKPOINT_FLUSH_MAX_GAP CHECKPOINT_FLUSH_MAX_WAIT_SEC DEFAULT_FLUSHER_WAIT_SEC HIGH_FLUSH_PCT HOT_LIST_PCT HOT_TOUCH_CNT LOW_FLUSH_PCT LOW_PREPARE_PCT MAX_FLUSHER_WAIT_SEC TOUCH_TIME_INTERVAL 238 Administrator’s Manual 버퍼 관리자 통계 정보 버퍼 관리자 통계 정보는 알티베이스가 제공하는 성능 뷰를 통해 확인할 수 있다. 성능 뷰에 대해서는 General Reference를 참조한다. 버퍼 풀과 관련된 정보는 V$BUFFPOOL_STAT을 통해 확인할 수 있고, 플러셔와 관련된 정보는 V$FLUSHINFO와 V$FLUSHER을 통해 확인할 수 있다. 버퍼 매니저의 버퍼 프레임 통계 정보는 V$BUFFPAGEINFO을 통해 확인할 수 있고, 언두 테이블스페이스의 버퍼 풀 관련 통계 정보는 V$UNDO_BUFF_STAT를 통해 확인할 수 있다. 통계 정보는 서버가 시작한 이래로 계속 누적된 값이므로 특정 기간 동안의 값을 알기 위해서는 모든 칼럼에 대해 다음의 방법으로 계산해야 한다: (현재의 값 - 측정 시작 시점의 값). Hit Ratio 계산 V$BUFFPOOL_STAT성능 뷰의 HIT_RATIO 칼럼을 통해 버퍼 풀의 누적된 히트율을 확인할 수 있다. 히트율은 다음의 수식에 의해 구해진다. Hit Ratio = (GET_PAGES + FIX_PAGES - READ_PAGES) / (GET_PAGES + FIX_PAGES) 예제 iSQL> select hit_ratio from V$BUFFPOOL_STAT; 백업 및 복구 239 10. 백업 및 복구 디스크 데이터 파일 손상 또는 유실 등과 같은 예기치 않은 상황으로 인해 알티베이스에 저장된 데이터가 손실될 경우를 대비하여 알티베이스에서 제공하는 기능인 백업 및 복구에 대하여 설명한다. 240 Administrator’s Manual 데이터베이스 백업 이 절에서는 데이터베이스가 아카이브로그 모드 여부에 따라 메모리 및 디스크 테이블스페이스에 대하여 지원되는 백업 방법과 정책에 대하여 설명한다. 알티베이스 백업 정책 알티베이스에서 지원하는 백업을 분류하면 다음과 같다. 논리적 백업 유틸리티(Utility) 백업 물리적 백업 오프라인(Offline) 백업 온라인(Online) 백업 논리적 백업은 aexport 혹은 iLoader를 이용하여 테이블과 인덱스를 생성하는 스크립트 파일들과 테이블 레코드들이 저장된 파일들을 생성하는 것을 말한다. 물리적 백업은 데이터베이스를 구성하는 데이터 파일들과 로그앵커 파일을 복사하는 것을 말한다. 물리적 백업은 데이터 파일의 스냅샷(snapshot)을 복사하는 동안의 서비스 중단 여부에 따라 온라인 백업과 오프라인 백업으로 구분된다. 오프라인 백업은 데이터베이스 서버를 정상 종료한 후에 모든 테이블스페이스 파일, 로그앵커 파일과 로그 파일들을 복사하는 것을 말한다. 온라인 백업은 서비스 중단 없이 데이터베이스의 데이터 파일들과 로그앵커 파일 등을 복사하는 것을 말한다. 이 데이터 파일들의 복사 과정에서 커밋(commit)되지 않은 데이터들이 백업될 수도 있다. 따라서 복구 시에 이들 커밋되지 않은 트랜잭션들을 철회(undo) 하기 위해서는 로그 파일들이 필요하다. 또한, 아카이브 로그 파일들이 생성되는 아카이브 로그 모드로 운영 될 때만 온라인 백업이 가능하다. 온라인 백업으로는 데이터베이스 전체를 백업 할 수 있거나, 특정 테이블스페이스 또는 로그앵커를 백업 할 수 있다. 다음의 구문이 각 경우에 사용된다. 데이터베이스 전체 백업 iSQL> alter database backup database to '/backup_dir'; 백업 및 복구 241 테이블스페이스 별 백업 iSQL> alter database backup tablespace SYS_TBS_DISK_DATA to '/backup_dir'; iSQL> alter tablespace SYS_TBS_DISK_DATA begin backup; $ cp SYS_TBS_DISK_DATA-DATA-FILES /backup_dir … iSQL> alter tablespace SYS_TBS_DISK_DATA end backup; 시스템 카탈로그 데이터를 포함하는 메모리 테이블스페이스인 SYS_TBS_MEM_DIC는 테이블스페이스 백업으로 백업될 수도 있고 전체 데이터베이스 백업 시에도 백업이 이루어진다. 다음의 표는 알티베이스의 다양한 백업 모드를 설명한다. 백업 종류 백업 방법 백업 객체 복구 방법 온라인 중에 가능? iLoader를 이용한 백업 iLoader의 out 명령 이 용 사용자가 명 시한 테이블 iLoader의 in 명령 이용 O 전체 데이터 베이스의 온 라인 백업 SQL 문 이용 ALTER DATABASE BACKUP DATBASE TO ‘BACKUP_DIR’; 시스템 전체 테이블스페이 스의 데이터 파일과 로그 앵커파일 1> 유닉스 명령어 cp 이용 2> ALTER DATABASE RECOVER DATABASE; O 특정 테이블 스페이스의 온라인 백업 1> SQL 문 이용 ALTER DATABASE BACKUP TABLESPACE 테이블스페이스이름 TO ‘backup_dir’; 또는 1> ALTER TABLESPACE 테이블스페이스 이름 BEGIN BACKUP; 2> 유닉스 명령어 cp 사용 cp <원본 파일> 3> ALTER TABLESPACE 테이블스페이스 이름 END BACKUP; 테이블스페이 스의 모든 데 이터 파일 1> 유닉스 명령어 cp 이용. 2> ALTER DATABASE RECOVER DATABASE; O 오프라인 백 업 1>데이터베이스 종료 2>유닉스 명령어 cp 이 용 전체 데이터 베이스 유닉스 명령어 cp 이용 X 242 Administrator’s Manual 백업시간 비 교 iLoader startup control; iSQL(sysdba)> alter database archivelog; 데이터베이스 모드에 따른 온라인 백업 및 매체 복구 모드 백업방법 매체 복구 방법 노아카이브 로그 오프라인 백업 Full 데이터베이스 복 구 아카이브 로그 온라인 백업 (오프라인 백업 가능) 완전 복구 - Full 데이터베이스 복구 불완전 복구 244 Administrator’s Manual - Cancel 기반 복구 - Time 기반 복구 상관없음 iloader Utility를 이용 한 백업 iloader Utility를 이 용한 복구 [표 10-3] 데이터베이스 모드에 따른 백업 및 복구 방법 테이블스페이스 상태에 따른 온라인 백업 및 매체 복구 테이블스페이스 상태 온라인 백업 매체 복구 온라인(ONLINE) 가능 가능 오프라인(OFFLINE) 가능 가능 디스카드(DISCARDED) 불가능 불가능 삭제(DROPPED) 불가능 불가능 백업(BACKUP) 불가능 의미 없음 [표 10-4] 테이블스페이스 상태에 따른 온라인 백업과 매체 복구 백업 시 주의사항 온라인 백업과 체크포인트는 동시에 수행될 수 없다. 체크포인트 중에 메모리 상의 데이터베이스 내용이 디스크에 반영되 고 온라인 백업은 백업하는 바로 그 시점까지의 데이터만 백업됨을 보장하기 때문에, 체크포인트와 온라인 백업은 서로 배타적으로 수행 되고, 동시에는 수행될 수 없다. 체크포인트 수행 중에 온라인 백업 요구가 들어오면 체크포인트가 완 료된 후에 온라인 백업이 시작된다. 마찬가지로 온라인 백업 진행 중에 체크포인트 요구가 들어와도 온라 인 백업이 완료된 후 체크포인트가 시작된다. 알티베이스는 하이브리 드 데이터베이스 특성상 데이터베이스 백업 시에 메모리 테이블스페 이스, 디스크 테이블스페이스 순으로 백업을 진행한다. 메모리 테이블스페이스 백업 중에는 체크 포인트가 수행 될 수 없지 만, 메모리 테이블스페이스의 백업이 완료되고 디스크 테이블스페이 스 백업 중에는, 메모리 테이블스페이스에 대한 체크 포인트는 수행 되고 디스크 테이블스페이스에 대한 체크 포인트는 수행되지 않는다. 이중화가 걸려 있는 경우 이중화 정보도 그대로 백업된다. 백업 및 복구 245 백업을 받는 알티베이스에 이중화가 걸려 있는 경우 이중화 관련 정 보도 그대로 백업된다. 그러므로 백업된 데이터베이스가 동일하지 않 은 시스템에서 복구되는 경우 그 장비의 네트워크 주소가 다르기 때 문에 알티베이스 복구 후 이중화 사용에 문제가 발생할 수 있다. 따라서, 이중화가 걸려 있는 경우 (1) 이중화를 중지 및 이중화 객체 삭제 후 백업을 수행하거나 또는 (2) 이중화를 사용하는 두 시스템에 서 다른 시스템의 백업 데이터로 데이터베이스를 복구할 경우 반드시 모든 시스템의 이중화 기능을 중지하여 복구 중에 다른 시스템으로 이중화가 되는 것을 방지해야 한다. 246 Administrator’s Manual 알티베이스 복구 데이터베이스 시스템에서는 언제든지 시스템 또는 하드웨서 장애가 발생할 가능성이 있다. 데이터베이스에 영향을 미치는 장애가 발생하면 데이터베이스 복원을 위해서 복구가 수행되어야 한다. 이런 장애 후의 목표는 모든 커밋된 트랜잭션의 결과들을 복구된 데이터베이스에 유지시키고 가능한 빨리 데이터베이스의 정상 운영이 가능하도록 하는데 있다. 알티베이스 복구 정책 알티베이스는 다음의 복구 유형을 지원한다. 재시작시 자동 복구 (Restart Recovery) 매체 복구 (Media Recovery) 재시작시 자동 복구는 알티베이스 프로세스가 시스템 crash 또는 소프트웨어 오류로 비정상 종료된 경우, 구동 단계에서 자동으로 수행되는 복구이다. 매체 복구는 특정 데이터 파일이 유실되거나 손상된 경우에 백업 받은 과거 데이터 파일의 스냅샷(snapshot)을 이용하여 백업 데이터 파일의 복구 시작 LSN부터 현재 LSN까지 재 수행하여 과거의 데이터 파일의 백업본으로부터 현재 시점의 데이터 파일로 복구하는 것이다. 데이터 파일의 매체 복구가 필요한가에 대한 판단은 로그앵커 파일상의 해당 데이터 파일의 버전과 현재 데이터 파일의 버전이 일치하는지 여부에 따라 결정된다. 백업 및 복구 247 logfile 20logfile 21 logfile 100logfile 101 user1.dbf 복구LSN (32:345698) USER1.DBF 정보 파일생 LSN(20:012284) checkpoint LSN (102:172168) archive logs directory user1.dbf 현재LSN (102:172168) 매체복구 프로세스 archived loganchor user1.dbf 생 LSN (20:012284) (방법 2) 백업된 user1.dbf을 복사하여 복구한다. (방법 1) 새로운 user1.dbf를 생 하여 복구한다. REDO 로그 재수행 ALTER DATABASE RECOVER DATABASE; 복구 완료 current archivedarchived online logs directory [그림 10-1] 알티베이스 복구 절차 알티베이스에서는 매체 복구를 control 구동 단계에서만 할 수 있다. 즉 알티베이스는 오프라인 매체 복구(offline media recovery)만 지원한다. 예제 다음은 매체 복구의 예제이다. TEST 테이블스페이스의 데이터 파일 ‘user1.dbf’ 파일이 유실되었다. 이 예제는 이틀 전에 온라인(Online) 백업받은 ‘user1.dbf’을 이용하여 유실된 데이터 파일을 현재 시점으로 복원한다. $ cp /bck/user1.dbf $ALTIBASE_HOME/dbs $ isql -silent -u sys -p manager -sysdba [ERR-00000 : Connected to idle instance] iSQL(sysdba)> startup control; Trying Connect to Altibase.. Connected with Altibase. TRANSITION TO PHASE : PROCESS TRANSITION TO PHASE : CONTROL Command execute success. iSQL(sysdba)> alter database recover database; Alter success. TEST 테이블스페이스의 데이터 파일 ‘user1.dbf’가 매체 복구되었다. iSQL(sysdba)> startup service; 248 Administrator’s Manual 매체복구가 완료되었기 때문에 서비스(service) 단계로 전이한다. 완전 복구 vs. 불완전 복구 알티베이스 매체 복구 정책은 완전 복구와 불완전 복구를 모두 지원한다. “완전 복구(Complete recovery)”는 온라인 로그와 아카이브 로그의 유실이 없는 경우에 현재 시점까지 데이터 파일을 복원하는 것을 의미한다. “불완전 복구(Incomplete recovery)”는 아카이브 로그 파일 또는 온라인 로그 파일이 유실된 경우에 로그 파일이 유실되기 바로 직전의 시점으로 데이터베이스를 복구하거나, 데이터베이스를 특정 시각으로 복원하기 위하여 특정 과거 시점으로 데이터베이스 전체를 되돌리는 경우를 말한다. 완전 복구의 예는 다음과 같다. ALTER DATABASE RECOVER DATABASE; 불완전 복구는 다음 2가지 경우로 나눌 수 있다. 과거의 특정 시점으로 데이터베이스 전체를 되돌리는 경우: 2007년 9월 10일에 생성된 전체 데이터베이스 백업 파일을 복사한 후 이를 이용하여 복구를 수행한다. ALTER DATABASE RECOVER DATABASE UNTIL TIME ‘2007-09-10:17:55:00’; 특정 온라인 로그 파일이 손상되어 현재 시점까지 데이터베이스를 복원할 수 없는 경우, 다음의 구문을 이용하여 온라인 로그 파일이 손상되기 바로 직전 시점으로 데이터베이스를 복원한다. ALTER DATABASE RECOVER DATABASE UNTIL CANCEL; control 구동 단계에서 불완전 복구를 수행한 경우에 meta 구동 단계로 넘어가기 위해서 반드시 다음 구문을 사용해야 한다. ALTER DATABASE db_name META RESETLOGS; 데이터베이스가 특정 과거 시점으로 복원되었기 때문에, 재 시작 시 자동 복구(Restart Recover)가 수행되지 않도록 할 필요가 있다. 이를 위하여 RESETLOGS 옵션으로 온라인 로그를 초기화(resetlogs)하는 것이다. 데이터베이스가 resetlogs를 하면서 meta 구동 단계로 전이 되었다면, 오프라인이나 온라인 백업으로 데이터베이스 전체 백업을 반드시 해야 한다. 백업 및 복구 249 그 이유는 다음과 같다: resetlogs를 하면서 meta 구동 단계로 전이하고 나서 이틀 후에 매체에 또 다시 에러가 발생한다면, 로그를 리셋하기 이전까지만 데이터 복구가 가능하기 때문이다. 즉, 로그를 리셋한 이후부터 이틀간의 데이터는 유실될 것이다. 매체 복구시 주의사항 매체 복구 알고리즘 때문에 가능하면 현재 로그 앵커 파일들을 이용하여 매체 복구를 하여야 한다. 복구 수행시, 백업된 데이터 파일들만 복사하여 복원해야 한다. 특별 한 경우가 아니라면 로그앵커 파일들은 백업 본을 사용하여 복구하면 안 된다. 특별한 경우는 사용자의 실수로 DROP TABLESPACE 구문으로 테 이블스페이스를 삭제 한 경우이다. 이 경우 현재 로그앵커 파일에는 삭제된 테이블스페이스 정보가 없기 때문에 백업된 로그앵커를 사용 할 수 밖에 없다. 메모리 테이블스페이스의 데이터 파일 복구 시 stable한 메모리 데이터 파일을 이용하여 unstable한 메모리 데이터 파일을 만들어 야 한다. 알티베이스는 메모리 테이블스페이스에 대하여 핑퐁 체크포인트 (ping-pong checkpoint) 기법을 사용하기 때문에, 디스크 상에서 각 메모리 테이블스페이스에 대하여 2개의 데이터 파일을 유지한다. 동일한 이미지를 기록하고 있는 1묶음(pair)의 데이터 파일은 MEM_DB_DIR 프로퍼티에 설정된 위치에 저장된다. 2개의 데이터 파일이 모두 존재해야만 알티베이스가 정상적으로 운용된다. 어느 한 시점에서는 메모리 테이블스페이스는 이 묶음 중 오직 1개의 데이터 파일만 사용한다. 백업 수행 시간을 줄이려면 메모리 테이블스페이스의 가장 최근 체크 포인터가 수행된 한 개의 데이터 파일만 백업한다. 따라서 백업된 메모리 테이블스페이스 데이터 파일을 이용하여 복구 할 경우 나머지 한 개의 동일한 이미지의 데이터 파일을 생성해 주어 야 한다. 백업 받은 메모리 테이블스페이스의 데이터 파일이 다음과 같다면: SYS_TBS_MEM_DIC-1-0, SYS_TBS_MEM_DIC-1-1, SYS_TBS_MEM_DIC-1-2 메모리 테이블스페이스를 위한 데이터 파일의 복사는 다음과 같이 250 Administrator’s Manual 되어야 한다. $ cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs; $ cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC- 0-0; $ cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs; $ cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC- 0-1; $ cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs; $ cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC- 0-2; 테이블스페이스의 추가, 삭제 또는 이름 변경 등이 이루어지면, 딕셔너리 테이블스페이스(SYS_TBS_MEM_DIC)의 백업이나 전체 데이터베이스의 백업이 필요하다. iSQL(sysdba)> ALTER DATABASE BACKUP TABLESPACE SYS_TBS_MEM_DIC TO ‘/backup_dir’; 로그앵커 파일은 데이터베이스 내 테이블스페이스 정보를 포함하고 있으므로, 이는 테이블스페이스 구조가 변경될 때마다 딕셔너리 테이 블스페이스와 함께 백업되어야 한다. iSQL(sysdba)> ALTER DATABASE BACKUP LOGANCHOR TO 'anchor_path'; 백업 및 복구 251 백업 및 복구 사례들 iLoader유틸리티를 이용한 테이블 백업 및 복구 임의의 테이블에만 문제가 발생할 것을 대비하거나, 특정 이유로 해당 테이블만 백업을 받으려고 하는 경우 사용한다. 백업 전 백업하기 전에 반드시 백업하고자 하는 테이블의 스키마에 관한 정보 파일(FORM file)을 생성해야 한다. FORM 파일은 테이블에 관한 기본 정보(칼럼 이름, 데이터 타입)를 가지고 있다. 예제) 테이블 t1의 form 파일 생성 (t1.fmt라는 파일 이름으로 생성됨) iLoader> formout -T t1 -f t1.fmt 백업 iLoader의 명령 중 out을 사용한다. 사용자가 명시한 이름으로 테이블에 대한 백업 파일이 생성된다. 예제) 테이블 t1의 백업 (이용할 form 파일은 t1.fmt 생성할 백업 파일은 t1.dat ) iLoader> out -d t1.dat -f t1.fmt 복원(restore) iLoader의 명령 중 in을 사용한다. 복구 시 테이블에 레코드가 존재하는 경우 그 레코드들을 유지하거나 덮어쓰게 할 수 있으며, 사용자가 명시하지 않는 경우 존재하는 레코드들의 내용은 유지된다. 예제) 테이블 t1의 복원 iLoader> in -d t1.dat -f t1.fmt Offline 백업 및 복구 오프라인 백업 및 복구는 주로 노아카이브 로그 모드로 데이터베이스를 운영하는 경우에 사용하는 방법이다. 252 Administrator’s Manual 오프라인 백업 수행시 주의사항 백업 전 알티베이스와 관련된 모든 서비스를 중지한다. 데이터베이스 운영 중에 오프라인 백업이 수행되면 백업 중에 로그 파일의 내용이 변경될 수 있어 백업이 정확하게 수행되지 않을 수 있다. 그러므로 반드시 알티베이스를 중지하고서 오프라인 백업을 수행하여야 한다. 백업 방법 모든 테이블스페이스의 데이터 파일들, 로그 파일, 및 로그 앵커 파일 모두를 운영체제의 복사 명령어 (UNIX의 경우 cp)를 이용하여 백업한다. 알티베이스에서는 메모리 데이터 파일 뿐만 아니라 디스크 관련 테이블스페이스의 데이터 파일들과 로그 앵커파일이 백업되어야 한다. 메모리 테이블스페이스 데이터 파일 저장 위치는 알티베이스 프로퍼티 파일인 $ALTIBASE_HOME/conf/altibase.properties 파일 내에 MEM_DB_DIR으로 설정된다. 메모리 테이블스페이스의 데이터 파일을 백업하려면 MEM_DB_DIR 디렉터리를 모두 복사해야 한다. 로그 앵커 파일의 위치는 $ALTIBASE_HOME/conf/altibase.properties 파일 내에 LOGANCHOR_DIR 프로퍼티로 설정된다. 로그 앵커 파일을 백업하려면 LOGANCHOR_DIR 디렉터리의 파일들을 복사해야 한다. 그리고 데이터 딕셔너리를 참조하여 디스크 테이블스페이스의 데이터 파일들을 복사해야 한다. 예제) $ALTIBASE_HOME/conf/altibase.properties MEM_DB_DIR=$ALTIBASE_HOME/dbs0 MEM_DB_DIR =$ALTIBASE_HOME/dbs1 LOGANCHOR_DIR =$ALTIBASE_HOME/logs 백업해야 하는 디스크 테이블스페이스에는 시스템 테이블스페이스,언두 테이블스페이스와 임시 테이블스페이스만 있다. 백업 파일이 저장될 위치가 /home/backup라면 $cp -r $ALTIBASE_HOME/dbs0 /home/backup $cp -r $ALTIBASE_HOME/dbs1 /home/backup $cp -r $ALTIBASE_HOME/logs /home/backup $cp -r $ALTIBASE_HOME/dbs/system*.dbf /home/backup $cp -r $ALTIBASE_HOME/dbs/undo.dbf /home/backup 백업 및 복구 253 $cp -r $ALTIBASE_HOME/dbs/temp.dbf /home/backup 복구 방법 알티베이스 프로퍼티 설정 파일은 백업 수행 당시에 사용되었던 프로퍼티 파일을 그대로 이용해야 한다. 공유 메모리에 남아있는 데이터베이스를 삭제한다. 백업 시 받았던 파일들을 복사 명령어 cp를 이용하여 복원한다. 이들 파일에 접근하려면 충분한 권한이 있어야 한다. 예) 아래의 예제에서는 위에서 백업된 데이터베이스가 복원된다. $cp -r /home/backup/dbs0 ALTIBASE_HOME/dbs0 $cp -r /home/backup/dbs1 $ALTIBASE_HOME/dbs1 $cp -r /home/backup/logs $ALTIBASE_HOME/logs $cp -r /home/backup/system*.dbf $ALTIBASE_HOME/dbs $cp -r /home/backup/undo.dbf $ALTIBASE_HOME/dbs $cp -r /home/backup/temp.dbf $ALTIBASE_HOME/dbs 데이터베이스 시스템에 의한 온라인 백업 데이터베이스 단위 온라인 백업 전체 데이터베이스가 /backup_dir디렉터리에 온라인 백업된다. iSQL(sysdba)> alter database backup database to‘/backup_dir’; $ ls /backup_dir SYS_TBS_MEM_DIC-0-0 SYS_TBS_MEM_DATA-0-0 system001.dbf system002.dbf undo001.dbf loganchor0 loganchor2 loganchor1 테이블스페이스 단위 온라인 백업 SYS_TBS_MEM_DIC데이터 파일 중에서 안정(stable)된 버전이 /backup_dir디렉터리에 온라인 백업된다. iSQL(sysdba)> alter database backup tablespace SYS_TBS_MEM_DIC to ‘/backup_dir’; $ ls /backup_dir SYS_TBS_MEM_DIC-0-0 254 Administrator’s Manual 로그앵커 온라인 백업 모든 로그앵커 파일이 /backup_dir 디렉터리에 온라인 백업된다. iSQL(sysdba)> alter database backup loganchor to ‘/backup_dir’; $ ls /backup_dir loganchor0 loganchor1 loganchor2 DBA에 의한 온라인 백업 테이블스페이스 단위 온라인 백업 /backup_dir에 USER_MEMORY_TBS와 USER_DISK_TBS테이블스페이스의 데이터 파일들을 온라인 백업 한다. 메모리 테이블스페이스 데이터 파일은 안정(stable) 버전 데이터 파일 확인 후 온라인 백업한다. iSQL(sysdba)> alter tablespace USER_MEMORY_TBS begin backup; iSQL(sysdba)> select * from v$stable_mem_datafiles; V$STABLE_MEM_DATAFILES.MEM_DATA_FILE ------------------------------ /altibase_home/dbs/USER_MEM_TBS-0-0 $ cp $ALTIBASE_HOME/dbs/USER_MEMORY_TBS-0-0 /backup_dir/ iSQL(sysdba)> alter tablespace USER_MEMORY_TBS end backup; iSQL(sysdba)> alter tablespace USER_DISK_TBS begin backup; $ cp $ALTIBASE_HOME/dbs/USER_DISK_TBS.dbf /backup_dir/ iSQL(sysdba)> alter tablespace USER_DISK_TBS end backup; $ ls /backup_dir USER_MEMORY_TBS-0-0 USER_DISK_TBS.dbf 온라인 백업 마무리 DBA에 의한 직접 온라인 백업을 수행하였다면 마지막 절차는 백업과 관련된 로그 파일을 강제로 아카이브(archive) 하는 명령을 수행해야 하는 것이다. 이 명령은 현재 로그 파일을 다 쓰지 백업 및 복구 255 않았어도 닫고 다음 로그 파일에 로깅을 계속한다. iSQL(sysdba)> ALTER SYSTEM SWITCH LOGFILE; 온라인 백업 완료 메시지가 altibase_sm.log에 남겨진다. 이 수동 백업의 예제에서는, logfile15341 로그파일이 아카이브 되었다는 메지지에 의해 백업이 완료됨을 나타낸다. [2007/09/18 14:42:38] [Thread-6] [Level-9] Waiting logfile15341 to archive [2007/09/18 14:42:43] [Thread-6] [Level-9] Database-Level Backup Completed [SUCCESS] 매체복구 사례 1 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 백업되지 않은 데이터 파일 $ALTIBASE_HOME/dbs/abc.dbf가 유실되었다. 참고) 메모리 테이블스페이스의 데이터 파일은 이와 같은 방법으로 복구될 수 없다. 복구 절차 완전 복구에 필요한 아카이브 로그 파일을 확인한다. iSQL(sysdba)> SELECT NAME, CREATE_LSN_LFGID, CREATE_LSN_FILENO FROM V$DATAFILES; ------------------------------ … /altibase_home/dbs/abc.dbf 0 18320 가장 최근 삭제된 로그 파일을 확인하기 위해서는 유틸리티 ‘dumpla’를 이용하여 loganchor의 내용을 확인한다. $ dumpla loganchor0 [LOGANCHOR HEADER] Binary DB Version [ 5.3.3 ] Archivelog Mode [ Archivelog ] Begin Checkpoint LSN [ 0, 20345, 469859 ] End Checkpoint LSN [ 0, 20345, 470300 ] Disk Redo LSN [ 0, 20345, 469859 ] Global SN [ 9476323 ] Server Status [ SERVER SHUTDOWN ] Log File Group Count [ 1 ] Log File Group [ 0 ] 256 Administrator’s Manual En d L SN [ 0, 20345,470341 ] ResetLog LSN [ 4294967295, 4294967295, 4294967295 ] Last Created Logfile Num [ 20350 ] Delete Logfile(s) Range [ 20344 ~ 20333 ] Update And Flush Count [ 316 ] New Tablespace ID [ 8 ] ARCHIVE_DIR 프로퍼티에 정의된 디렉터리에 logfile18320부터 logfile20344까지 존재하는지 확인한다. 만약 존재하지 않는다면, 아카이브 로그파일을 백업 저장 장치로부터 ARCHIVE_DIR 프로퍼티에 지정된 디렉터리로 복사한다. logfile20345 이후의 로그 파일은 모두 LOG_DIR 프로퍼티에 지정된 디렉터리에 존재하는 온라인 로그 파일이다. 즉, logfile18320부터 logfile20345까지의 로그 파일들은 유실된 abc.dbf 를 완전 복구하기 위해 반드시 필요하다. ARCHIVE_DIR과 LOG_DIR프로퍼티에 지정된 디렉터리에 존재하는 로그 파일의 중복으로 인해 발생되는 디스크 공간 낭비를 제거하기 위해서, 알티베이스가 직접 ARCHIVE_DIR프로퍼티에 지정된 디렉터리의 로그 파일을 읽는다. CONTROL 구동 단계에서 다음 구문으로 유실된 abc.dbf 파일을 생성한다. iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE‘abc.dbf’; CONTROL 구동 단계에서 다음 구문으로 완전 매체 복구를 수행한다. iSQL(sysdba)> alter DATABASE RECOVER DATABASE; 매체복구 사례 2 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 3일 전에 테이블스페이스 USER_DISK_TBS의 데이터 파일들을 백업하였다. 오늘 오전에 USER_DISK_TBS 테이블스페이스의 데이터 파일을 모두 잃어 버렸다. 백업 절차 3일전에 다음과 같이 백업을 수행했다. iSQL(sysdba)> ALTER DATABASE BACKUP TABLESPACE user_disk_tbs TO ‘/backup1’; iSQL(sysdba)> ALTER SYSTEM SWITCH LOGFILE; 백업 및 복구 257 $ ls /backup1 USER_DISK_TBS01.dbf USER_DISK_TBS02.dbf USER_DISK_TBS03.dbf 복구 절차 완전 복구에 필요한 아카이브 로그 파일을 확인 확인한 후, 아카이브 디렉터리로 해당 파일들을 복사한다. 필요한 아카이브 로그 파일을 확인하는 방법은 복구될 데이터 파일의 헤더에 있는 정보를 참조하는 것이다. 헤더 정보는 dumpddf 유틸리티를 이용하여 다음과 같이 확인해 볼 수 있다. $ dumpddf -m -f USER_DISK_TBS01.dbf [BEGIN DATABASE FILE HEADER] Binary DB Version [ 5.4.1 ] Redo LSN [ 0, 4, 2257550 ] Create LSN [ 0, 0, 657403 ] [END DATABASE FILE HEADER] 위 결과는 백업된 데이터 파일을 이용하여 데이터베이스를 복원하려면 아카이브 로그 파일 logfile4 이후 파일들을 필요로 함을 나타낸다. backup_dir디렉터리의 데이터 파일 백업을 USER_DISK_TBS테이블스페이스의 데이터 파일이 원래 있었던 $ALTIBASE_HOME/dbs/ 디렉터리에 복사한다. $ cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs; CONTROL 구동 단계에서 다음 구문으로 완전 매체 복구를 수행한다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE; 매체복구 사례 3 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 7일전에 테이블스페이스 USER_DISK_TBS의 데이터 파일들을 백업하였다. 오늘 오후에 USER_DISK_TBS 테이블스페이스의 데이터 파일이 있는 /disk1 파일 시스템이 깨졌으나, /disk2파일 시스템은 정상이다. 이 경우 /disk1 파티션이 깨졌으므로 정상 상태의 /disk2 파티션에 백업된 데이터 파일을 옮겨 매체 복구를 수행한다. 258 Administrator’s Manual 백업 절차 7일 전에 같이 백업을 수행했다. iSQL(sysdba)> ALTER DATABASE BACKUP TABLESPACE user_disk_tbs TO '/backup_dir’; iSQL(sysdba)>ALTER SYSTEM SWITCH LOGFILE; $ ls /backup_dir USER_DISK_TBS01.dbf USER_DISK_TBS02.dbf 복구 절차 완전 복구에 필요한 아카이브 로그 파일을 확인하고, 아카이브 디렉터리로 해당 파일들을 복사한다.backup_dir디렉터리에 있는 USER_DISK_TBS테이블스페이스의 백업 파일들을 온전한 /disk2파일 시스템으로 복사한다. $ cp /backup_dir/*.dbf /disk2/dbs; CONTROL 구동 단계에서 USER_DISK_TBS 테이블스페이스의 데이터 파일 경로를 변경한다. iSQL(sysdba)> ALTER DATABASE RENAME DATAFILE '/disk1/dbs/USER_DISK_TBS01.dbf' TO '/disk2/dbs/USER_DISK_TBS01.dbf'; iSQL(sysdba)> ALTER DATABASE RENAME DATAFILE '/disk1/dbs/USER_DISK_TBS02.dbf' TO '/disk2/dbs/USER_DISK_TBS02.dbf'; Note: 이 작업 수행을 위해서 alter tablespace 명령을 사용할 수도 있다. iSQL(sysdba)> ALTER TABLESPACE user_disk_tbs RENAME DATAFILE '/disk1/dbs/USER_DISK_TBS02.dbf' TO '/disk2/dbs/USER_DISK_TBS02.dbf'; 데이터 파일 경로가 정확히 변경되었는지 v$datafile성능 뷰를 확인한다. iSQL(sysdba)> SELECT * FROM V$DATAFILES; CONTROL 구동 단계에서 다음 구문으로 완전 매체복구를 수행한다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE; 매체복구 사례 4 백업 및 복구 259 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 사용자 실수로 summary테이블을 DROP 하였다. A. 가장 최근의 전체 온라인 백업 완료 시각: 2007년 9월 18일 12시 00분 B. 테이블이 DROP된 시각: 2007년 9월 18일 15시 00분 C. 현재 시각: 2007년 9월 18일 18시 00분 summary 테이블을 복구하기 위해서는 현재 시각의 약 3시간 30분 전인 2007년 9월 18일 14시 30분 정각으로 데이터베이스를 불완전 매체 복구를 수행해야 한다. 백업 절차 지난번 백업 시 다음과 같이 전체 데이터베이스를 백업하였다. iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO‘/backup_dir’; iSQL(sysdba)> alter SYSTEM SWITCH LOGFILE; 복구 절차 1. 백업 받은 데이터 파일들을 원래 위치로 복사 한다. $ cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs; 2. 메모리 테이블스페이스는 핑퐁(ping pong) 체크 포인트 기법을 사용하고 있기 때문에, 백업 시에는 메모리 테이블스페이스의 안 전한(stable)한 데이터 파일만 복사되었다. 예) 백업받은 메모리 테이블스페이스의 데이터 파일이 다음과 같 다, SYS_TBS_MEM_DIC-1-0, SYS_TBS_MEM_DIC-1-1, SYS_TBS_MEM_DIC-1-2 SYS_TBS_MEM_DATA-0-0, SYS_TBS_MEM_DATA-0-1, SYS_TBS_MEM_DATA-0-2 3. 백업된 메모리 테이블스페이스는 안정한(stable) 데이터 파일이 기 때문에 안정한 버전의 확인 절차 없이 복사하면 된다. $ cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DATA-0-0 $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DATA-0-1 $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DATA-0-2 $ALTIBASE_HOME/dbs 4. 불완전 복구는 백업된 로그앵커 파일을 사용한다. 백업 된 저장 260 Administrator’s Manual 장치로부터 로그앵커를 복사한다. $ cp /backup_dir/loganchor* $ALTIBASE_HOME/logs 5. 불완전 복구에 필요한 아카이브 로그 파일을 아래와 같이 확인한 다. iSQL(sysdba)> select last_deleted_logfile from v$lfg; LAST_DELETED_LOGFILE ------------------------ 15021 6. $ALTIBASE_HOME/trc 디렉터리에 생성되는 altibase_sm.log 파일에서 백업 완료 시 강제로 아카이브 처리된 파일을 확인한다. [2007/09/18 13:59:59] [Thread-6] [Level-9] Waiting logfile15341 to archive 7. 위 결과에 의해 logfile15021부터 백업 완료 마무리 시 기록해 두었던 마지막 아카이브 로그파일인 logfile 15341까지 모두 ARCHIVE_DIR 프로퍼티에 지정된 디렉터리 (혹은 백업 장치)로 부터 LOG_DIR 프로퍼티에 지정된 디렉터리에 복사한다. 불완전 매체 복구는 완전 복구와 달리 로그 파일 중복이 불가피하게 허 용된다. 8. SYS_TBS_DISK_TEMP는 백업되지 않기 때문에 해당 파일을 만들어 준다. iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf' 9. 불완전 매체 복구를 다음과 같이 수행한다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL TIME ‘2007-09-18:14:30:00'; 10. 복구가 완료된 메모리 테이블스페이스에 대해서 모든 안정한 데 이터 파일들을 사용하여 불안정한 버전을 생성한다. $ cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC- 0-0 $ cp SYS_TBS_MEM_DIC-1-1 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC-0-1 $ cp SYS_TBS_MEM_DIC-1-2 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC- 0-2 $ cp SYS_TBS_MEM_DATA-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DATA-0-0 $ cp SYS_TBS_MEM_DATA-1-1 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DATA-0-1 $ cp SYS_TBS_MEM_DATA-1-2 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DATA-0-2 백업 및 복구 261 11. 불완전 매체 복구를 수행하였기 때문에 meta 구동 단계로 가면 서 resetlogs옵션을 사용하여야 한다. iSQL(sysdba)> ALTER DATABASE MYDB META RESETLOGS; 12. resetlogs를 수행하였기 때문에 데이터베이스 전체 백업을 받는 다. iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO ‘backup_dir’; 매체복구 사례 5 아카이브 로그 모드로 데이터베이스를 운영중이며, 온라인 로그파일이 499번부터 600번까지 있고, 중간 로그파일인 570번 로그 파일이 유실되었다. 복구 절차 불완전 복구에 필요한 데이터 파일과 로그앵커 파일을 백업 본으로부터 복사한다. 불완전 복구에 필요한 아카이브 로그 파일을 확인한다. Logfile499부터 569까지의 리두 로그만 데이터베이스에 반영하고, logfile570번 이후의 로그 파일의 리두 로그는 반영하지 않는다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL; 불완전 미디어 복구를 수행하였기 때문에 meta 구동 단계로 가면서 resetlogs옵션을 사용하여야 한다. iSQL(sysdba)> ALTER DATABASE MYDB META RESETLOGS; resetlogs를 수행하였기 때문에 데이터베이스 전체 백업을 받는다. iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO ‘/backup_dir’; 매체복구 사례 6 노아카이브 로그 모드로 운영중인 데이터베이스이지만 매체 복구를 수행할 수 있는 경우가 있다. 바로 임시(temporary) 테이블스페이스의 데이터 파일이 유실되는 경우이다. 임시 테이블스페이스에 대해서는 변경의 재수행이 필요 없기 때문이다. 복구 절차 CONTROL 구동 단계에서 SYS_TBS_DISK_TEMP 262 Administrator’s Manual 테이블스페이스의 유실된 데이터 파일 대신에 새로운 temp001.dbf를 생성한다. iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE ‘temp001.dbf’; 서버를 구동한다. iSQL(sysdba)> ALTER DATABASE dbname SERVICE; 매체복구 사례 7 아카이브 로그 모드로 데이터베이스를 운영중이며, SYS_TBS_MEM_DIC 딕셔너리 테이블스페이스의 데이터 파일이 유실되었다. 백업 절차 SYS_TBS_MEM_DIC 테이블스페이스를 테이블스페이스 단위 백업한다. iSQL(sysdba)> ALTER DATABASE BACKUP TABLESPACE SYS_TBS_MEM_DIC to ‘/backup_dir’; 복구 절차 완전 복구에 필요한 아카이브 로그 파일을 확인한 후, 아카이브 디렉터리로 해당 파일들을 복사한다. 필요한 아카이브 로그 파일을 확인하는 방법은 복구될 데이터 파일의 헤더에 있는 정보를 참조하는 것이다. 헤더 정보는 dumpci 유틸리티를 이용하여 다음과 같이 확인해 볼 수 있다 % dumpci -m -f SYS_TBS_MEM_DIC-0-0 [BEGIN CHECKPOINT IMAGE HEADER] Binary DB Version [ 5.4.1 ] LogFileGroup Count [ 1 ] LogFileGroup-0 Redo LSN [ 0, 4, 2257550 ] LogFileGroup-0 Create LSN [ 0, 0, 657403 ] [END CHECKPOINT IMAGE HEADER] 위 결과는 백업된 데이터 파일을 사용하여 데이터베이스를 복원하기 위해서는 logfile4 아카이브 로그 파일 이후의 파일들을 필요로 함을 나타낸다. 메모리 테이블스페이스의 안정한(stable) 데이터 파일만 백업된다. 백업된 파일이 SYS_TBS_MEM_DIC-0-0이라면 아래와 같이 데이터 파일을 복사하도록 한다. $ cp /backup_dir/SYS_TBS_MEM_DIC-0-0 $ALTIBASE_HOME/dbs; 백업 및 복구 263 $ALTIBASE_HOME/bin/dumpla loganchor0 결과 중 테이블스페이스 이름이 SYS_TBS_MEM_DIC인 테이블스페이스 속성들 중 Stable Checkpoint Image Num이란 항목을 참고한다. % dumpla loganchor0 [ TABLESPACE ATTRIBUTE ] Tablespace ID [ 0 ] Tablespace Name [ SYS_TBS_MEM_DIC ] New Database File ID [ 0 ] Tablespace Status [ ONLINE ] TableSpace Type [ 0 ] Checkpoint Path Count [ 0 ] Autoextend Mode [ Autoextend ] Shared Memory Key [ 0 ] Stable Checkpoint Image Num. [ 1 ] Init Size [ 4 MBytes ( 129 Pages ) ] Next Size [ 4 MBytes ( 128 Pages ) ] Maximum Size [ 134217727 MBytes ( 4294967295 Pages ) ] Split File Size [ 1024 MBytes ( 32768 Pages ) ] [ MEMORY CHECKPOINT PATH ATTRIBUTE ] Tablespace ID [ 0 ] Checkpoint Path [ /home/altibase_home/dbs ] [ MEMORY CHECKPOINT IMAGE ATTRIBUTE ] Tablespace ID [ 0 ] File Number [ 0 ] Create LSN [ 0, 0, 2028 ] Create On Disk (PingPong 0) [ Created ] Create On Disk (PingPong 1) [ Created ] 백업 데이터 파일의 번호는 [0]이고 현재 안정한 데이터 파일의 번호는 [1]이므로, 다음과 같이 복사한다. $ cd $ALTIBASE_HOME/dbs $ cp SYS_TBS_MEM_DIC-0-0 SYS_TBS_MEM_DIC-1-0 CONTROL 구동 단계에서 미디어 복구를 수행한다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE; 위의 과정에 의해 복구가 완료된 데이터 파일의 복사본을 생성한다. $ cp SYS_TBS_MEM_DIC-1-0 $ALTIBASE_HOME/dbs/SYS_TBS_MEM_DIC- 0-0 미디어 복구가 완료되었으므로 재시작 자동복구를 수행한다. 264 Administrator’s Manual i SQ L (s y s d b a )> ALTER DATABASE dbname SERVICE; 매체복구 사례 8 아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 사용자 실수로 테이블스페이스 USER_DISK_TBS가 삭제되었다. 삭제 시점은 2007년 4월 6일 22시 30분이었다. 테이블스페이스가 존재했던 10분 전의 상태로 데이터베이스를 복구하려고 한다. 백업 절차 마지막 백업 시 다음과 같이 전체 DB를 백업하였다. iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO ‘/backup_dir’; 복구 절차 불완전 복구에 필요한 데이터 파일과 로그앵커 파일을 백업 본으로부터 복사한다. 백업 받은 데이터베이스의 모든 디스크 테이블스페이스의 데이터 파일들을 데이터 파일들의 원래 위치로 복사한다. $ cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs $ cp /backup_dir/SYS_TBS_* $ALTIBASE_HOME/dbs 불완전 복구에 필요한 아카이브 로그 파일을 확인한다. 불완전 복구는 백업된 로그앵커 파일을 사용한다. 백업 저장 장치로부터 로그앵커 파일을 복사한다. $ cp /backup_dir/loganchor* /ALTIBASE_HOME/logs; SYS_TBS_DISK_TEMP테이블스페이스는 백업되지 않기 때문에 해당 파일을 새로 만들어 준다. iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE ‘temp001.dbf’ 불완전 미디어 복구를 수행한다. iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL TIME '2007-04-06:22:20:00'; 불완전 미디어 복구를 수행하였기 때문에 meta 구동 단계로 가면서 resetlogs 옵션을 사용하여야 한다. iSQL(sysdba)> ALTER DATABASE mydb META RESETLOGS; 서버를 구동한다. iSQL(sysdba)> ALTER DATABASE mydb SERVICE; 로그가 리셋되었기 때문에 전체 데이터베이스의 백업을 수행하는 백업 및 복구 265 것이 좋다. iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO ‘/backup_dir’; SQL 튜닝 267 11. SQL 튜닝 본 장에서는 질의 성능을 향상시키기 위한 SQL 튜닝 방법에 대하여 설명한다. 268 Administrator’s Manual SQL 튜닝 개요 SQL 튜닝이란 SQL문의 성능을 극대화하기 위해 조치하는 모든 일련의 작업을 의미하며, 다음이 포함된다. SQL문 재작성 데이터베이스 스키마 재설계 알티베이스 프로퍼티 조정 운영체제 커널 파라미터 조정 SQL 튜닝 방법 중 SQL문의 재작성과 데이터베이스 스키마 재설계의 경우는 알티베이스내의 쿼리 처리 방법과 제한 사항 등에 의해 쿼리 성능이 영향을 받기 때문에 알티베이스내의 쿼리 처리 방법에 대한 심도 높은 이해가 요구된다. 또한, 메모리 테이블과 디스크 테이블을 모두 사용할 수 있기 때문에 저장 매체의 특성에 따라서 쿼리 처리에 어떻게 영향을 미치는지에 대한 이해가 필요하다. 본 절에서는 간략하게 성능 관련 이슈를 살펴보고 질의 튜닝을 위해 필요한 기본 개념에 대하여 설명한다. 성능 관련 이슈 실행 계획 트리(Execution plan tree) 클라이언트에서 SQL문의 수행을 요구하면 질의 처리기는 구문 검사, 정당성 검사, 및 최적화 과정을 거쳐 실행 절차를 정의한 실행 계획 트리를 생성한다. 만약 호스트 변수가 존재하면 알티베이스는 이들 변수를 바인딩한 후 실행 계획에 따라 데이터베이스에 접근해 레코드를 검색할 것이다. 이러한 SQL문의 수행에 소요되는 시간 중 대부분은 실제로 구문을 실행하는 시간으로, 복잡한 SQL문의 경우 실행 계획 트리 구조가 성능에 큰 영향을 끼친다. SQL Plan Cache 알티베이스에서는 세션간에 SQL 구문의 실행 계획이 공유될 수 있다. 이는 SQL 구문 수행시마다 매번 실행 계획을 만드는 비용을 줄인다. 이 기능을 이용하려면 SQL Plan Cache와 관련된 SQL_PLAN_CACHE_SIZE 프로퍼티의 값을 적절히 설정해야 한다. 데이터베이스 스키마와 데이터 용량 SQL 튜닝 269 우선적으로 응용프로그램의 특성 및 자원 활용의 효율에 따라 메모리 테이블 및 디스크 테이블의 사용을 적절히 고려하여야 한다. 일반적으로 자주 사용되는 데이터는 메모리 테이블에, 접근 빈도가 낮은 데이터는 디스크 테이블에 저장하여 관리하는 것이 유리하다. 응용 프로그램에서 사용되는 SQL문의 종류를 고려해 각 SQL문 별로 테이블에 접근하는 회수, 접근하는 레코드 수 및 디스크 페이지 수가 최소 비용이 되도록 테이블 스키마의 구성과 인덱스 구성에 유의해야 한다. 또한, 단순한 SQL문 또는 레코드 건수가 많은 테이블에 대해서는 술어(predicate) 내 칼럼값의 비교 비용이 성능에 큰 영향을 미친다. 그러므로 데이터 변환과 비교 비용을 최소화할 수 있는 적합한 데이터 타입의 선정이 중요하다. 따라서 가능한 적은 수의 레코드에 접근하도록 SQL문을 작성하여 절대적 비교 회수를 줄여야 하며, 비교 연산 시 데이터 변환이 일어나지 않도록 칼럼의 데이터 타입과 비교되는 값의 데이터 타입을 잘 선정해야 한다. 응용프로그램 로직(테이블 접근 순서) 만약 여러 클라이언트가 알티베이스 데이터베이스에 세션으로 연결된 경우, 각 클라이언트의 테이블 접근 순서가 성능에 영향을 미칠 수도 있다. 한 트랜잭션 내에서 DML문을 여러 개 사용하여 여러 테이블에 접근하는 경우, 응용프로그램에서 테이블에 접근하는 순서 등을 잘못 설계했다면 lock 을 획득하기 위해 대기하는 시간(lock waiting time)으로 인해 전체 응용프로그램 성능이 저하될 수도 있다. 따라서 클라이언트 응용프로그램의 로직 설계에 유의해야 한다. 시스템 리소스 한 SQL문의 처리 시 성능에 영향을 미치는 시스템 리소스는 가용한 메모리의 크기, 메모리 버퍼의 크기, 디스크 성능과 CPU 성능이다. 검색 질의의 성능은 물론 메모리 테이블만을 사용할 경우 디스크 성 능에 영향을 받지 않는다. 그러나, 디스크 테이블을 검색할 경우 디 스크 성능 및 가용한 메모리 버퍼의 크기에 따라 질의 성능이 영향을 받게 된다. 이러한 점은 메모리 테이블을 검색할 경우 일정한 질의 응답 시간을 기대할 수 있는 반면, 디스크 테이블을 검색할 경우 질 의 수행 시점의 환경에 따라 많은 성능 차이를 보이게 되는 원인이 된다. ORDER BY 절 또는 GROUP BY 절 등이 포함된 질의를 처리할때, 질의 처리기는 sorting 기법이나 hashing 기법을 사용하는데 이 처 270 Administrator’s Manual 리의 중간 결과를 저장하기 위해 메모리 임시 테이블 또는 디스크 임 시 테이블을 사용하게 된다. 중간 결과가 메모리 임시 테이블에 저장되는 경우, 사용되는 메모리 는 데이터베이스 영역에 잡혀 있는 메모리가 아니다. 그러므로 메모 리 테이블의 크기가 크다면 많은 메모리가 필요할 수 있으므로 질의 처리시 메모리 스와핑으로 인한 성능 저하가 생기지 않도록 주의해야 한다. 중간 결과가 디스크 임시 테이블에 저장되는 경우, 사용되는 자원은 디스크 임시 테이블스페이스의 디스크 영역과 메모리 버퍼 영역이다. 가용한 메모리 버퍼 영역의 크기에 따라 성능에 커다란 영향을 미치 게 된다. 또한 질의 처리 작업은 연산자를 처리하기 위한 작업이 많아 CPU를 많이 사용한다. 그러므로 CPU 점유율과 CPU 성능도 질의 성능에 영향을 많이 미친다. SQL 튜닝 일반 이 절에서는 알티베이스 사용자를 위한 일반적인 튜닝 방법론에 대해 간략하게 설명한다. SQL 성능 측정 방법 APRE, ODBC, 또는 JDBC 등을 사용한 응용프로그램 개발시, 쿼리 처리 동안 경과된 시간은 시간을 구하는 함수를 이용하여 응용프로그램 내에서 측정될 수 있다. 또한 iSQL에서 다음 iSQL명령어를 이용해 쿼리 수행 시간을 측정할 수도 있다. SET TIMING ON; 메모리 테이블의 경우 iSQL로 질의를 반복 수행 시 거의 유사한 성능을 얻을 수 있으나, 디스크 테이블의 경우는 반복 수행 시 버퍼 교체가 적게 발생하여 최초 수행 때보다 다음 수행 시 보다 나은 성능을 얻게 된다. 이는 디스크 테이블에 대하여 동시 수행되는 질의들이 많을 경우 버퍼 교체로 인해 그 성능의 일정함을 보장할 수 없음을 의미한다. 그러나 일반적으로 iSQL상에서 SQL 문을 튜닝하여 성능을 향상시킨 SQL 문의 경우 실제 응용프로그램에서도 같은 비율의 성능 향상을 볼 수 있다. 실행 계획 트리의 분석 SQL 튜닝 271 SELECT, INSERT, UPDATE, DELETE 등의 SQL DML문의 실행 계획 트리는 iSQL 상에서만 확인이 가능하다. DELETE 문, UPDATE 문, 및 MOVE 문은 SELECT 문 처리와 같은 최적화 과정을 거치므로 내부적으로 같은 실행 계획 트리가 생성된다. INSERT문의 경우 INSERT INTO SELECT 의 SELECT문 부분에 대한 실행 계획 트리의 확인이 가능하다. 일반적으로 실행 계획 트리에서 확인해야 할 내용은 다음과 같다. 자세한 내용은 다음 절에서 살펴본다. 액세스 방법이 효율적인가? 조인 순서 및 방법은 바람직한가? 적절한 데이터 타입 및 연산을 사용하는가? 불필요한 hashing 및 sorting을 수행하는가? 질의 튜닝 실행 계획 트리를 사용해서 성능 저하 요소를 분석한 후 이에 대한 적절한 조치를 취함으로서 성능을 개선할 수 있다. 질의 튜닝 방법은 질의 최적화 과정 및 질의 실행기에 대한 개념 설명 과정에서 자세히 다룬다. 메모리 테이블과 디스크 테이블 알티베이스는 메모리 테이블과 디스크 테이블을 모두 지원하는 최초의 HDB (Hybrid Database)이다. 따라서, 메모리 테이블과 디스크 테이블에 대한 질의 처리 방법의 차이를 이해하는 것은 질의 튜닝에 있어 큰 도움이 된다. 메모리 테이블과 디스크 테이블을 위한 질의 처리기의 기본적인 차이는 다음과 같다. Query Processor Item Memory Table Disk Table Executor Object identifier Pointer OID(RID) Buffer management N/A Limited buffer Join methods One-pass algorithms Multi-pass algorithms Optimizer Main cost CPU Disk Index selection Minimize record access Minimize disk I/O Cost factor T(R), V(R.a), etc + B(R), M 참조 T(R): Table R의 레코드 개수, V(R.a): R.a 칼럼의 Value Cardinality B(R): Table R의 디스크 페이지 개수, M: 가용한 메모리 버퍼 개수 272 Administrator’s Manual 질의 처리기는 크게 최적화기(Optimizer)와 실행기(Executor)로 구분된다. 최적화기는 비용 계산을 통해 실행 계획 트리를 생성한다. 실행기는 실행 계획 트리의 각 노드에 따라 실제로 구문을 실행한다. 알티베이스의 실행기와 최적화기는 저장 매체의 차이를 충분히 반영 하는 반면, 이에 대한 별도의 구분 없이 실행 계획을 생성하고, 질의 처리시에 그 특성만을 반영하여 수행할 수 있도록 설계되어 있다. 즉, 메모리 테이블과 디스크 테이블의 혼용된 질의 처리에 있어서도 각 저장 매체의 특성은 충분히 반영하면서 동일한 처리 과정을 따르 게 된다. 실행기(Executor) 실행기는 테이블의 저장 매체에 따라 위의 표에서와 같이 기본적인 개념 및 그 동작에 있어 차이점이 있다. 먼저 레코드를 구별하는 “객체 식별자(Object identifier)”는 메모리 테이블의 경우 포인터이며 디스크 테이블의 경우 OID(RID)와 같은 특정 디스크 주소로 변환할 수 있는 식별자이다. 이러한 차이는 레코드 접근에 있어 메모리 테이블은 직접 접근이 가능한 반면 디스크 테이블은 주소 변환에 의한 접근이 필요함을 의미하다. 메모리 테이블에 대한 질의 처리시에는 버퍼를 사용하지 않아 이에 대한 고려가 필요없다. 반면, 디스크 테이블에 대한 질의 처리는 제한된 메모리 버퍼 내에서 이루어지기 때문에 버퍼에 원하는 레코드가 없을 경우(Buffer miss) 디스크 I/O를 유발하는 버퍼 교체(Buffer replacement)가 수반된다. 조인 방법은 크게 다음으로 분류된다. nested loop join hash-based join sort-based join merge join 각 조인 방법을 위해서 필요에 따라 중간 결과가 저장된다. 이 때 제한된 메모리에 이 결과를 모두 적재할 수 있는 지의 여부에 따라 one-pass 또는 multi-pass 알고리즘으로 처리된다. One-pass 알고리즘의 경우 가용 메모리 버퍼에 중간 결과를 모두 적재할 수 있을 때 사용되는 반면, multi-pass 알고리즘은 중간 결과를 메모리상에 모두 적재할 수 없을 때 버퍼 교체를 최소화하기 위해 사용된다. 메모리 테이블에 대한 조인의 경우 버퍼 제한이 없어 one-pass 알고리즘이 사용될 수 있는 반면, 디스크 테이블의 경우 버퍼 제한을 고려하여 one-pass 또는 two-pass 알고리즘이 사용된다. 위와 같이 실행기의 처리 방식은 저장 매체에 따라 근본적으로 SQL 튜닝 273 다르며, 성능에 있어서도 큰 차이를 보이게 된다. 최적화기(Optimizer) 질의 최적화기는 테이블이 저장된 저장 매체에 따라 위의 표와 같이 기본적인 개념 및 그 동작에 있어 차이점이 있다. 최적화기는 메모리 테이블을 조회할 경우 CPU 비용을 최소화할 수 있도록 실행 계획을 생성한다. 반면, 디스크 테이블을 조회할 경우 디스크 I/O를 최소화할 수 있도록 실행 계획을 생성한다. 즉, 저장 매체에 따라 질의 성능에 가장 큰 영향을 미치는 자원 사용을 최소화할 수 있는 실행 계획을 생성한다. 최적화기는 테이블에 접근하는 방법(Access method)을 선택할 때, 메모리 테이블의 경우 읽을 레코드 수를 최소화할 수 있는 인덱스를 선택하는 반면, 디스크 테이블의 경우 디스크 I/O를 최소화할 수 있는 접근 방법을 선택하게 된다. 이러한 차이는 메모리 테이블의 경우 대부분의 경우 인덱스를 사용하는 것이 전체 테이블 스캔보다 나은 성능을 보장하지만, 디스크 테이블의 경우 데이터의 분포에 따라 인덱스를 사용하는 것보다 전체 테이블 스캔이 오히려 적은 디스크 I/O를 발생시켜 보다 나은 성능을 보일 수 있기 때문이다. 최적화기는 비용 계산을 위한 인자로 다양한 통계 정보를 사용한다. 메모리 테이블에 대한 비용 계산시에는 테이블의 레코드 개수[T(R)], 칼럼내의 서로 다른 값의 개수[V(R.a)], 및 칼럼의 최소와 최대값 등의 통계 정보가 사용되는 반면, 디스크 테이블에 대한 비용 계산시에는 이 외에도 테이블이 사용하고 있는 디스크 페이지 개수[B(R)], 가용한 메모리 버퍼 페이지 개수[M]등의 추가적인 통계 정보가 이용된다. 질의 처리 (Query Processing) 개요 SQL문의 튜닝 시 항상 모든 응용 프로그램에 적용해 최적의 성능을 발휘하는 절대적인 규칙을 제시하기는 쉽지 않다. 데이터베이스의 설계 또는 응용 프로그램의 비지니스 로직에 따라 SQL 튜닝 방법은 매우 다양하다. 따라서 이 절에서는 하나의 SQL문이 어떠한 과정을 거쳐 처리되는지, 성능에 영향을 미치는 요소는 어떠한 것들이 있는지에 대해 설명하고 일반적인 방법론에 대해서만 제시한다. DBMS에서 SQL문 처리를 담당하는 모듈을 질의 처리기(Query Processor)라 한다. 질의 처리기는 사용자가 수행을 요구한 SQL문에 대해 정당성을 검사한 후 데이터베이스에 접근하는 최적의 접근 순서와 방법을 결정하고, 이에 따라 조건에 맞는 레코드를 검색한 후 필요한 연산을 수행하여 마지막으로 클라이언트에게 274 Administrator’s Manual 처리한 값을 돌려주는 모듈이다. 질의 처리수행 과정을 개략적으로 도식화하면 다음과 같다. Server Parsing Validation Optimization Binding Execution Database Client Prepare Bind Execute Fetch [그림 11-1] Query Processing 순서 각 단계별 수행 작업은 다음과 같다. 1. 구문 분석(Parsing): SQL문의 문법을 검사(syntax 검사)하고 구문 분석 정보를 저장하는 파스 트리(Parse Tree)를 생성한다. 2. 정당성 검사(Validation): SQL문의 의미상 정당성을 검사 (semantic 검사)하고 메타 테이블을 검색하여 파스 트리를 확장 한다. 3. 최적화(Optimization): 주어진 파스 트리에 기반하여 다양한 통 계 정보와 접근 비용 계산을 통해 최적화된 실행 계획을 생성한 다. 4. 바인딩(Binding): 호스트 변수값(host variable value) 을 생성 된 실행 계획에 연결한다. 5. 실행(Execution): 실행 계획 트리에 따라 SQL문을 실행한다. 질의를 튜닝하기 위해 알티베이스의 질의 최적화와 질의 실행 과정을 이해하는 것은 매우 중요하다. 다음 장에서 이를 기반으로 한 질의 튜닝 방법에 대하여 자세히 알아본다. SQL 튜닝 275 질의 최적화 과정 질의 최적화(optimization) 과정은 주어진 SQL을 분석하여 가능한 실행 계획을 작성하고 이에 대한 비용 평가를 통해 가장 효율적인 실행 계획을 선택하는 과정이다. 질의 성능의 대부분이 이 과정에서 결정된다. 복잡한 질의일수록 질의 최적화 과정의 정확성에 의해서 성능이 좌우된다. 질의 최적화 개요 Optimizer의 구조 최적화 이전 단계에서는 주어진 질의문이 구문 분석(parsing)과 의미 분석(validation) 과정을 거치게 되며, 이 과정에서 파싱 트리가 생성된다. Optimizer는 이 파싱 트리로부터 각종 비용 평가를 통해 효율적인 실행 계획 트리(plan tree)을 생성한다. 이러한 과정을 수행하는 optimizer의 구조는 다음과 같다. Graph (Logical Operator) Parse Tree Plan Tree (Physical Operator) Optimizer Graph Manager Plan tree Manager Predicate Manager [그림 11-2] Query Processing 순서 Optimizer는 크게 그래프 관리자, 실행 계획 관리자, Predicate 관리자로 구성된다. Optimizer의 각 관리자의 역할은 다음과 같다. 그래프 관리자는 주어진 파싱 트리를 이용하여 논리 연산자로 구성된 그래프를 생성하고 해당 그래프에 대한 구문 실행 비용을 계산하여 최적화 방법을 결정한다. 실행계획 관리자는 생성된 그래프를 이용하여 주어진 최적화 방법에 따라 실행 계획 트리를 생성한다. Predicate 관리자는 그래프 관리자와 실행 계획 관리자가 실행 계획 트리를 결정하고 생성하기 위해 필요한 정보를 제공한다. 그래프 요소(논리 연산자)의 종류 276 Administrator’s Manual 그래프는 총 12개 요소로 구성되며, 주요 그래프 요소의 기능은 다음과 같다. 구분 그래프 요소 기능 관련 SQL 구문 Critical path Selection 단일 테이블에 대한 접근 방법 FROM, WHERE Join 조인의 수행 순서 및 방법 FROM, WHERE Non critical path Grouping 그룹과 aggregation 연산의 수 행 방법 GROUP BY, HAVING, aggregation 연산 Distinction 중복 레코드 제거의 수행 방법 DISTINCT Set 집합 연산의 수행 방법 UNION, UNION ALL, INTERSECT, MINUS Sorting 정렬 연산의 수행 방법 ORDER BY Projection 프로젝션 연산의 수행 방법 SELECT [표 11-1] 그래프의 종류 Optimizer의 관점에서 검색 질의 성능에 가장 큰 영향을 미치는 부분은 FROM 과 WHERE 절로 이를 critical path라 한다. 이 외의 GROUP BY 와 ORDER BY 절 등과 같은 부분을 non- critical path라 한다. Optimizer는 critical path의 처리를 위해 selection과 join 등의 그래프 요소를 사용하여 이에 대한 수행 방법을 결정하며, non- critical path의 처리를 위해 grouping, distinction, set, sorting, 및 projection과 같은 그래프 요소를 사용하여 수행 방법을 결정하게 된다. 실시간 통계 정보 Optimizer는 다양한 실행 계획의 비용 계산을 위해 실시간 통계 정보를 사용한다. Optimizer는 기본적인 통계 정보를 사용할 뿐만 아니라 최적화 과정을 통해 새로운 정보를 추정하고 비용 계산을 통해 다양한 예측 정보를 산출해낸다. 기호 설명 T( R ) 테이블 R의 레코드 수 V(I) 인덱스 I 의 Value Cardinality, 인덱스 키값의 서 로 다른 값의 개수 V(R.a) 칼럼 R.a의 Value Cardinality, 서로 다른 값의 개수 MIN(R.a) 칼럼 R.a의 최소값 MAX(R.a) 칼럼 R.a의 최대값 B( R ) 테이블 R의 디스크 페이지 개수 M 메모리 버퍼의 페이지 개수 SQL 튜닝 277 [표 11-2] 실시간 통계 정보 위와 같은 실시간 통계 정보는 데이터의 변경이 발생 할 때마다 별도의 부하 없이 변경되며, 사용자의 개입 없이 데이터베이스 서버에 의해 비교적 정확한 정보가 관리된다. Optimizer는 이러한 실시간 통계 정보를 사용하기 때문에 다양한 실행 계획들에 대한 비용 평가가 가능하며 효율적인 실행 계획을 생성할 수 있다. 그러나, 통계 정보가 모든 질의 최적화를 위한 충분한 정보가 될 수 없으며, Optimizer가 모든 환경에서 항상 효율적인 실행 계획을 생성할 수 있는 것은 아니다. 따라서, 특정 질의의 경우 사용자의 성능 향상을 위한 작업이 필요할 수 있으며 이를 위해서는 알티베이스 질의 최적화 개념을 이해하는 것이 매우 중요하다. 질의 최적화 과정 알티베이스의 optimizer는 성능에 가장 큰 영향을 미치는 critical path에 대한 최적화 방법을 우선적으로 결정하고, 이 후에 non- critical path를 처리하는 bottom-up 방식의 최적화 순서를 따르고 있다. Critical path에 대한 실행 방법을 결정하기 위한 최적화 과정은 다음과 같다. 1. 정규화: 사용자가 정의한 WHERE 절을 CNF(Conjunctive Normal Form)와 DNF(Disjunctive Normal Form) 두 가지의 정규화된 형태로 변형한다. 2. 각 정규화된 형태(CNF와 DNF)는 다음과 같은 단계로 처리된다. 조건절의 분류: 정규화된 조건절을 하나의 테이블에 관계된 조건과 두 개 이상의 테이블이 관계된 조건으로 분류한다. 액세스 방법 결정: 우선적으로 각 테이블에 대한 조건절을 기준으로 비용이 가장 적은 인덱스 선택 등의 액세스 방법을 결정한다. 여기서 선택된 액세스 방법은 조인 과정을 통해 재조정된다. 조인 순서의 결정: 복잡한 질의 처리 과정에서 조인의 순서는 질의 성능에 가장 큰 영향을 미치는 요소이며 이는 join greedy algorithm을 통해 결정된다. 조인 방법의 결정: 조인 순서의 결정 후 각 조인 순서별로 최적의 조인 방법을 선택한다. Non-critical path의 실행 방법을 결정하는 최적화 과정은 critical path에 대한 최적화 이후에 수행되며 그 과정은 다음과 같다. 1. 그룹/Aggregate 연산의 수행 방법 결정: 질의에 GROUP BY 또는 HAVING절이나, aggregation 연산이 포함되어 있을 경우 278 Administrator’s Manual 이를 처리하기 위한 수행 방법을 결정한다. 2. DISTINCT절의 수행 방법 결정: 질의에 DISTINCT 절이 포함 되어 있을 경우 이를 처리하기 위한 수행 방법을 결정한다. 3. SET 절의 수행 방법 결정: 질의에 UNION, UNION ALL, INTERSECT, 또는 MINUS 절 등이 있을 경우 이를 처리하기 위한 수행 방법을 결정한다. 4. ORDER BY절의 수행 방법 결정: 질의에 ORDER BY절이 포함 되어 있을 경우 이를 처리하기 위한 수행 방법을 결정한다. 5. 프로젝션의 수행 방법 결정: SELECT 구문에 포함되어 있는 칼 럼 등을 위한 프로젝션 수행 방법을 결정한다. subquery내에 존 재하는 SELECT 구문인 경우 다양한 최적화 방법들이 사용될 수 있다. 질의 정규화 정규화의 개념 사용자가 작성한 WHERE 조건절은 매우 다양한 형태로 표현된다. Optimizer는 다양한 조건 처리를 일관적이고 효율적인 방법으로 처리하기 위해 사용자가 정의한 WHERE절을 정형화된 형태로 변경한다. 이러한 과정을 정규화라고 한다. 정규화는 AND, OR, NOT 등의 논리식을 사용해서 조건절을 확장하고 변형하는 과정이다. AND연산자를 최상위 논리식으로 표현하는 방법을 CNF (Conjunctive Normal Form)이라 하며, OR연산자를 최상위 논리식으로 표현하는 방법을 DNF (Disjunctive Normal Form)이라 한다. CNF 정규화는 주어진 조건절을 AND연산자를 최상위로 하여 하위에 OR 논리 연산자가 구성되도록 재배치하는 것이다. 다음 예는 조건절이 CNF정규화를 사용해서 변환될 때 결과로 나타나는 구조를 보여준다. WHERE (i1 = 1 AND i2 = 1) OR i3 = 1 CNF: (i1 = 1 OR i3 = 1) AND (i2 = 1 OR i3 = 1) DNF 정규화는 주어진 조건절을 OR 연산자를 최상위로 하여 하위에 AND 논리 연산자로만 재구성되도록 재배치하는 과정이다. 다음 예는 조건절이 DNF 정규화를 사용해서 변환될 때 결과로 나타나는 구조를 보여준다. WHERE (i1 = 1 OR i2 = 1) AND i3 = 1 DNF: (i1 = 1 AND i3 = 1) OR (i2 = 1 AND i3 = 1) SQL 튜닝 279 즉, optimizer는 주어진 조건절을 CNF로 변환했을 때의 실행 비용과, DNF로 변환했을 때의 실행 비용을 비교하여 보다 나은 정규화 형태를 선택하게 된다. 일반적으로 optimizer는 CNF 기반의 실행 계획을 선택하며, 일부의 경우 DNF 기반의 실행 계획을 선택한다. 예를 들어, 다음과 같은 질의를 살펴보자. SELECT * FROM T1 WHERE i1 = 1 OR i2 = 1; CNF 정규화: AND (i1 = 1 OR i2 = 1) DNF 정규화: (i1 = 1 AND ) OR (i2 = 1 AND ) 위의 조건절은 T1 테이블에 인덱스가 없거나 하나의 칼럼에만 인덱스가 있는 경우는 CNF로 처리된다. 즉, T1 테이블을 전체 스캔하여 질의를 처리하는 것이 가장 효율적이다. 그러나, i1과 i2 칼럼에 각각 인덱스가 있는 경우는 DNF로 정규화하여 각각의 인덱스를 모두 사용하여 (i1 = 1) 의 결과와 (i2 = 1)의 결과를 따로 얻어 합치는 것이 보다 효율적이다. 이와 같이 동일한 조건식이라 하더라도 인덱스의 유무에 따라 다른 타입의 정규화가 선택된다. 이는 optimizer가 각 경우의 실행 비용을 비교하여 결정한다. 물론, 논리 연산자가 없거나 OR 연산자가 존재하지 않는 경우라면 optimizer는 CNF 정규화만을 사용하게 되며, OR 연산자가 존재하는 경우에는 CNF와 DNF를 모두 구성하고 각각의 비용을 비교하여 실행 계획을 생성한다. 정규화 튜닝 앞에서 살펴 보았듯이 정규화 과정은 조건절의 확장을 불가피하게 한다. 따라서, 조건절 기술 시 정규화된 형태로 구성하는 것은 조건절의 확장을 방지하여 불필요한 비교 연산을 제거할 수 있다. 예를 들어, 다음 조건절은 CNF 또는 DNF로 수행이 가능하지만, 이는 질의 변경을 통해 CNF로만 동작하게 할 수 있다. WHERE i1 = 1 OR i1 = 2 OR i1 = 3 CNF 정규화: i1 IN (1, 2, 3) 유사한 예로 다음과 같은 질의는 CNF 또는 DNF로의 질의 변형을 통해 불필요한 정규화 과정을 제거하고 동일한 조건 비교를 방지하여 성능을 향상할 수 있다. WHERE (i1 = 1 AND i2 = 1) OR (i1 = 2 AND i2 = 2) CNF 정규화: (i1, i2) IN ( (1,1), (2,2) ) WHERE (i1 = 1 AND i2 = 1) OR ( i3 = 1 AND i4 = 1) 280 Administrator’s Manual 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 튜닝 281 CREATE TABLE T3 AS SELECT * FROM T1, T2 WHERE 1 1; 위와 같이 T1과 T2 테이블의 데이터는 가지지 않으면서 모든 칼럼 정보를 가진 T3 테이블을 만들고 싶을 경우 constant filter를 사용하면 원하는 작업을 수행할 수 있다. 또한, 다음 예와 같이 검색 권한을 제한하는 용도로 활용할 수 있다. SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND ? > 20; 위와 같이 나이값에 해당하는 호스트 변수를 지정하여 조건에 부합하지 않는 사용자가 질의를 수행하거나 결과값이 없는 질의의 수행으로 인한 부하 등을 방지할 수 있다. 이 외에도 optimizer는 다음과 같이 subquery를 포함하고 있는 조건절도 constant filter로 처리하여 한 번만 수행하고 subquery가 반복적으로 수행되지 않게 할 수 있다. SELECT * FROM T1 WHERE EXISTS ( SELECT * FROM T2 WHERE T2.date = SYSDATE ); 위의 예제에서 EXISTS 조건은 T1의 데이터와 전혀 관계 없는 constant filter이다. Push Selection 기법 정규화와 조건절의 분류 과정을 통해 구분된 단일 테이블에 대한 조건절은 액세스 방법을 결정하는 데 가장 중요한 요소이다. Optimizer는 조건절의 형태에 따라 다양한 최적화 기법들을 적용할 수 있다. Optimizer에서 조건절을 이용한 가장 일반적인 최적화 방법이 push selection 기법이다. 이는 조건절을 분류하여 해당 테이블에 속하는 조건이 먼저 검사되도록 하는 것이다. 예를 들어, 다음과 같은 질의를 살펴 보자. SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND T1.i2 = abc; 위의 질의에서 조건절을 위해 다양한 실행 계획의 생성이 가능하다. 구체적으로 말하면, optimizer는 T1과 T2테이블을 먼저 조합한 후에 조건절을 비교할 수도 있으며, T1 테이블에 대한 조건을 먼저 이용하여 T1의 결과 집합을 줄인 후에 T2 테이블과 조인을 수행할 수도 있다. 이와 같이 조인이 수행되기 전에 WHERE절의 조건을 처리하는 것이 push selection의 가장 일반적인 형태이다. Optimizer는 실행 비용 및 수학적 일치성 등을 고려하여 push selection의 다양한 형태를 고려하게 된다. Optimizer가 사용하는 대표적인 push selection 기법은 다음과 같다. 뷰에 대한 push selection 282 Administrator’s Manual Outer 조인에 대한 push selection 조인에 대한 push selection 뷰에 대한 Push Selection 뷰에 대한 push selection 기법은 사용자 정의 뷰에 대하여 질의를 수행 시 WHERE 절에 기술된 조건을 뷰의 내부에 적용하는 기법이다. 예를 들어, 다음과 같이 정의된 뷰와 이에 대한 질의가 있다고 하자. CREATE VIEW V1(a1, a2) AS SELECT i1, i2 FROM T1 WHERE i2 > 20; SELECT * FROM V1 WHERE a1 = 1; Optimizer는 해당 질의의 최적화 과정에서 뷰에 대한 push selection 기법을 사용하는 것이 보다 효율적인 실행 계획이라고 판단하면, WHERE 절의 조건이 내부적으로 다음과 같은 형태로 처리되도록 결정한다. 이를 개념적으로 표현한 질의는 다음과 같다. SELECT * FROM ( SELECT i1, i2 FROM T1 WHERE i2 > 20 AND i1 =1 ) V1; 즉, 위와 같은 질의 변형을 통해 T1.i1 칼럼의 인덱스를 활용할 수 있도록 한다. 그러나, Optimizer가 항상 이런 종류의 push selection을 사용하도록 결정하지는 않는다. 사용자가 뷰 내부의 구조를 파악하고 있다면 적절한 조건절의 사용을 통해 Optimizer가 뷰에 대한 push selection기법을 선택하도록 할 수 있다. 또한, 사용자는 힌트를 사용하여 optimizer가 명시적으로 뷰에 대한 push selection기법을 선택하도록 할 수 있다. 그러나, 뷰에 대한 push selection을 사용하는 것이 원래 질의와 동등하거나 더 나은 성능을 반드시 보장하지는 않는다. 뷰에 대한 push selection과 상충되는 최적화 기법이 바로 view materialization 기법이다. 이는 뷰가 하나의 질의에서 반복해서 사용될 때 질의 처리 과정 중에 뷰의 결과를 임시로 저장하여 처리하는 기법이다. 예를 들어 다음과 같은 뷰의 정의와 관련 질의를 살펴 보자 CREATE VIEW V1(a1, a2) AS SELECT i1, SUM(i2) FROM T1 GROUP BY i1; SELECT * FROM V1 WHERE V1.a2 > (SELECT AVG(a2) FROM V1 WHERE a1 > 10 ); 위와 같은 질의에 대하여 view materialization 기법이 사용되면, V1뷰의 결과는 임시로 저장되고 최상위 질의와 subquery는 이를 사용하게 된다. 즉, V1의 결과를 얻기 위하여 뷰를 정의한 질의를 반복하여 수행하지 않아도 되는 효과를 얻게 된다. SQL 튜닝 283 이러한 질의에 대하여 뷰에 대한 push selection 기법을 사용하도록 힌트를 주면 오히려 느린 성능을 얻을 수도 있으므로 올바른 판단이 필요하다. Outer Join에 대한 Push Selection FROM 절에 outer join이 사용된 경우 다양한 형태의 push selection 이 가능하다. 이들 기법의 공통된 점은 WHERE 절에 기술된 조건을 outer join 의 조인 처리 이전에 수행되게 한다는 것이다. 예를 들어 다음과 같은 질의를 살펴 보자 SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 WHERE T1.i1 = 1; 위 질의에 push selection 기법이 적용될 경우 개념적으로 다음과 같은 질의 형태로 처리된다. SELECT * FROM (SELECT * FROM T1 WHERE T1.i1 = 1) T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1; 즉, left outer join에 대한 조인 조건을 처리하기 전에 T1.i1 = 1 조건을 먼저 처리하여 T1의 결과 집합을 줄인다. 이러한 기법 역시 수학적 동치 여부 및 비용 평가를 통해 적용 여부가 결정된다. 예를 들어 다음의 세 질의는 경우에 따라 서로 다른 결과를 생성하며, 동일한 질의가 아니다. SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 WHERE T2.a1 = 1; SELECT * FROM T1 LEFT OUTER JOIN (SELECT * FROM T2 WHERE T2.a1 = 1) T2 ON T1.i1 = T2.a1; SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 AND T2.a1 = 1; Optimizer는 수학적 동치인 상태에서 동일한 결과를 얻기 위해서 위의 질의를 다음과 같은 형태로 push selection을 적용한다. SELECT * FROM T1 LEFT OUTER JOIN (SELECT * FROM T2 WHERE T2.a1 = 1) T2 ON T1.i1 = T2.a1 WHERE T2.a1 = 1; Left outer join의 경우 WHERE 조건을 ON 절에 옮겨 처리하고 싶다면 다음과 같이 WHERE 절에 반드시 남겨 두어야 동일한 결과를 보장받을 수 있다. SELECT * FROM T1 LEFT OUTER JOIN T2 ON T1.i1 = T2.a1 AND T2.a1 = 1 WHERE T2.a1 = 1; 284 Administrator’s Manual 위의 최적화 기법을 보면, optimizer가 outer join에 대하여 push selection을 적용하지 않더라도 사용자는 임의로 질의 조건의 추가를 통해 유사한 효과를 기대할 수 있다. 물론, 조건 추가를 통해 동일한 결과를 얻음과 동시에 성능을 향상시킬 수 있는지 여부를 판단하는 것이 매우 중요하다. 조인에 대한 Push Selection 조인에 대한 push selection 기법은 조인 조건과 단일 테이블 조건이 존재할 때 유사한 다른 단일 테이블 조건을 추가하여 성능을 향상시키는 기법이다. 예를 들어 다음과 같은 질의를 살펴보자 SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND T1.i1 = 1; 해당 질의를 처리하기 위해 어떠한 인덱스도 사용할 수 없을 경우 다음과 같이 유사한 단일 테이블 조건을 추가하는 것은 많은 경우에 성능 향상에 도움이 된다. SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1 AND T1.i1 = 1 AND T2.a1 = 1; 즉, T2 의 결과 집합의 크기를 줄임으로서 성능을 향상시킬 수 있다. 이러한 조인에 대한 push selection 기법은 특히 집합 연산을 통해 생성된 뷰에 대하여 처리할 때 매우 효과적이다. 예를 들어 다음과 같은 뷰와 이를 이용한 질의를 살펴 보자. CREATE VIEW V1(a1, a2) AS ( SELECT m1, m2 FROM T2 UNION ALL SELECT x1, y1 FROM T3 ); SELECT * FROM T1, V1 WHERE T1.i1 = V1.a1 AND T1.i1 = 1; 위의 뷰 정의에서 T2.m1 과 T3.x1 칼럼에 모두 인덱스가 있다고 해도 해당 질의를 수행할 때 어떤 인덱스도 사용되지 않는다. 이 때 조인에 대한 push selection 기법을 적용하여 질의를 변경할 경우 다음과 같은 효과를 얻을 수 있다. SELECT * FROM T1, V1 WHERE T1.i1 = V1.a1 AND T1.i1 = 1 AND V1.a1 = 1; 위와 같이 기술된 질의는 뷰에 대한 push selection과 집합에 대한 push selection 기법이 적용되어 다음과 같이 T2.m1 과 T3.x1 칼럼의 인덱스를 모두 사용할 수 있게 된다. 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 튜닝 285 반드시 좋은 성능을 보장하지는 못하며, 경우에 따라 잘못된 조건절의 추가는 비교 연산 비용만 증가시킬 수 있음을 유념하여야 한다. 액세스 방법의 결정 SQL 튜닝 시 가장 우선적으로 고려해야 하는 부분이 테이블에 대한 접근 시 인덱스를 사용하는 지의 여부를 판단하는 것이다. 대부분의 질의 처리 성능의 문제는 인덱스의 사용 여부에 따라 결정되며 이에 대한 판단이 SQL 튜닝에 있어 가장 중요하다고 할 수 있다. 조건절의 처리 유형 Optimizer 는 정규화와 조건절의 분류 과정을 통해 구분된 조건들을 기준으로 해당 테이블의 액세스 방법 및 조건의 처리 방법을 결정하게 된다. 조건절을 처리 순서 및 처리 방법에 따라 분류하면 다음과 같다. 처리 방법 처리 순서 설명 예제 Key Range 2 인덱스를 사용하여 범위 검색이 가능한 조건 T1.i1 > 1 Key Filter 3 범위 검색은 안되나 인덱스의 키 값을 비교하여 검사가 가능한 조건 T1.i2 = 1 Constant Filter 1 테이블의 데이터에 관계 없이 한 번의 검사만으로 판단이 가능한 조건 ? = 1 Filter 4 데이터에 대한 직접적인 비교가 필요한 조건 T1.i4 = abc Subquery filter 5 Subquery를 포함하고 있는 조건 EXISTS () 예제 Index on T1(i1, i2, i3) 질의: SELECT * FROM T1 WHERE ? = 1 AND i1 > 1 AND i2 = 2 AND i4 = abc AND EXISTS ( SELECT * FROM T2 WHERE T2.a1 = T1.i3 ); [표 11-3] 조건절의 처리 위의 표에서 보는 바와 같이 모든 조건들은 다섯 가지 처리 방법 중 하나에 의해 처리된다. Key range 처리 방법은 인덱스를 이용하여 조건에 부합하는 범위내의 데이터를 검색하는 방법이다. 즉, 조건을 만족하는 최소값의 위치와 최대값의 위치만을 결정하고 해당 조건에 대한 별도의 비교 없이 그 범위 내의 모든 데이터를 검사하게 된다. 286 Administrator’s Manual 따라서, 이 방법은 조건 비교 시 데이터에 대한 별도의 비교 연산이 필요 없어 매우 우수한 성능을 보장한다. Key filter 처리 방법은 인덱스를 이용하여 범위 검색은 할 수 없으나, 인덱스에 저장되어 있는 키값을 이용하여 비교 연산을 수행하는 방법이다. 즉, 이 방법은 인덱스를 저장하고 있는 페이지만을 접근하여 비교함으로서 데이터 페이지에 대한 접근 횟수를 줄여 성능을 향상시킬 수 있다. 이는 디스크 테이블의 인덱스에 대해서만 사용 가능하며, 메모리 테이블의 인덱스의 경우 별도로 키값을 저장하지 않고 있어 filter 처리 방법과 비교하여 성능 향상의 효과가 없다. Constant 처리 방법은 앞에서 살펴보았듯이 조건절을 다른 모든 조건에 우선하여 한 번만 처리하며, 논리값이 FALSE인 경우 별도의 데이터 검색이 필요 없다. Filter 처리 방법은 인덱스를 사용할 수 없는 일반적인 조건에 대한 비교 방법으로 데이터를 직접 읽어 비교 연산을 수행한다. 다수의 filter가 있는 경우, Optimizer는 각 filter에 대하여 예상되는 처리 비용을 비교하여 가장 비용이 적은 filter를 우선적으로 처리하여 비교 비용을 최소화할 수 있도록 filter의 처리 순서를 결정한다. subquery filter는 일반적으로 가장 많은 비용이 드는 비교 연산이다. 따라서 이는 모든 조건 비교가 완료된 후 마지막으로 수행된다. Optimizer는 이러한 subquery filter에 대하여 다양한 최적화 기법을 적용하여 성능 향상을 꾀한다. 이에 대해서는 이후의 subquery 처리 과정에서 자세히 다룬다. 인덱스 생성 시 고려 사항 주어진 조건절을 처리하는데 가장 효율적인 key range 검색을 하기 위해서는 인덱스가 있어야 한다. 그러나, 인덱스를 생성하기 위해서는 다음과 같은 사항을 반드시 고려하여야 한다. 인덱스의 생성이 검색 연산의 성능을 향상시킬 수는 있으나, 인덱스를 관리하기 위한 저장 공간이 필요하여 시스템 자원을 추가로 소모할 수 있다. 또한, 과도한 인덱스의 생성은 삽입, 삭제, 또는 갱신 발생시 관련 인덱스의 정보를 유지하기 위한 비용으로 인해 성능 저하를 유발할 수도 있다. 메모리 테이블의 경우 거의 모든 질의 처리에 있어 인덱스를 이용한 검색 방법(index scan이라 함)이 테이블에 대한 전체 스캔(full table scan이라 함)보다 우수한 성능을 보인다. 그러나, 디스크 테이블의 경우 인덱스 스캔(index scan)이 전체 테이블 스캔(full table scan)보다 반드시 효과적인 것은 아니다. SQL 튜닝 287 이는 전체 테이블 스캔이 데이터 페이지를 접근하는 패턴이 일정한 반면, 인덱스 스캔은 그 패턴이 일정하지 않아 경우에 따라 과도한 Disk I/O를 유발할 수 있기 때문이다. 일반적으로 디스크 테이블의 경우 인덱스 스캔을 이용한 검색이 테이블의 전체 레코드 중 1/10 이하 또는 아주 작은 수의 레코드만을 선택하는 경우에 한해 인덱스를 생성할 것을 권고하고 있다. 그러므로, 인덱스 생성 여부 결정시 질의의 수행 빈도수, 인덱스 사용으로 인한 성능 향상 효과, 전체 시스템 자원, 및 갱신 질의 (INSERT, DELETE, UPDATE)의 성능 저하 정도를 고려하여야 한다. Optimizer의 인덱스 선택 Optimizer는 주어진 조건과 해당 테이블의 인덱스를 이용하여 가장 효율적인 액세스 방법을 결정한다. 이 과정에서 Optimizer는 다양한 통계 정보를 이용하여 각 인덱스의 사용에 따른 비용을 평가하며, 이 중 가장 효율적인 액세스 방법을 선택한다. 액세스 방법이 결정되면 Optimizer는 각 조건들에 대하여 처리 방법 (key range 처리, filter 처리 등)을 결정한다. Optimizer가 각 액세스 방법의 비용을 계산하기 위해 사용하는 개념적인 공식은 다음과 같다. Access cost + Disk I/O cost Full scan : T(R) Index Scan : log(T(R)) + T(R) * MAX(1/V(Index), selectivity) 개념적인 Access cost 산 Full scan : B(R) Index Scan : Buffer Miss : [T(R) / V(R.a)] * ( 1- M/B(R) ) No Buffer Miss : B(R) * ( 1 - (log V(R.a)/logT(R)) ) 개념적인 Disk I/O cost 산 Optimizer는 접근 비용(access cost)과 디스크 I/O 비용(disk I/O cost)을 모두 통합하여 계산한다. 메모리 테이블의 경우 디스크 페이지가 존재하지 않아 디스크 I/O 비용은 수식에 의하여 자동으로 계산되지 않는다. Optimizer는 각 인덱스에 대한 비용 계산 시 인덱스를 이용하여 처리할 수 있는 조건을 선택하고 이를 기반으로 비용을 계산한다. 이 때, 비용에 가장 큰 영향을 미치는 것이 인덱스에 관련된 조건의 288 Administrator’s Manual 효율성이다. 이를 조건의 selectivity라 한다. 조건의 selectivity는 전체 레코드 중 조건에 의해 선택되는 레코드들의 비율을 의미한다. 즉, 조건의 selectivity가 낮을수록 결과 레코드의 수가 줄어 들어 성능을 향상시킬 수 있다. 예를 들어 다음과 같은 조건을 살펴 보자. WHERE i1 = 1 AND i2 = 1 위의 조건에서 i1과 i2 칼럼에 각각 인덱스가 존재한다면 어떠한 인덱스를 선택할 것인가를 결정할 때 가장 중요한 요소는 해당 조건의 selectivity이다. 예를 들어, i1 컬럼에 서로 다른 값의 종류가 100 [V(i1) = 100] 개가 있고, i2 칼럼에는 서로 다른 값의 종류가 1000 [V(i2) = 1000] 이라면 각 조건의 selectivity는 다음과 같이 계산된다. (i1 = 1)의 selectivity = 1/V(i1) = 1/100 (i2 = 1)의 selectivity = 1/V(i2) = 1/1000 즉, 해당 질의를 처리하기 위해 i2 칼럼의 인덱스를 사용하는 것이 보다 효율적인 액세스 방법이다. 위와 같은 개념의 액세스 선택 방법이 보편적으로 올바른 실행 계획을 작성한다. 그러나 이 역시 비용 계산에 의한 선택이기 때문에 모든 상황에 있어 항상 좋은 액세스 방법이 선택되지는 않는다. 예를 들어, 다음과 같은 질의를 살펴 보자. SELECT * FROM soldier WHERE gender = 'female' AND rank = 'lieutenant'; 위의 질의에서 gender와 rank 칼럼에 모두 인덱스가 있다고 할 때, optimizer는 비용 계산을 통해 rank 칼럼에 대한 조건을 처리하기 위한 인덱스를 사용하는 것이 바람직하다고 판단할 것이다. 그러나, (gender = 'female') 의 조건을 만족하는 결과 집합이 아주 작다는 것을 사용자가 알고 있다면 힌트등을 통해 인덱스 선택을 달리하는 것이 바람직하다. Composite 인덱스의 활용 Optimizer는 composite 인덱스를 사용할 때 조건절을 비교하여 최대한 많은 조건을 key range 검색할 수 있도록 선택한다. 이 때 key range 검색으로 처리될 수 있는 조건이 많을수록 보다 나은 성능을 기대할 수 있다. 정의된 인덱스를 참조하는 조건절을 사용자가 어떻게 기술하는 가에 따라 인덱스를 이용한 성능은 매우 차이가 나므로, composite 인덱스의 동작 원리를 이해하는 것은 SQL 튜닝에 매우 큰 도움이 된다. SQL 튜닝 289 예를 들어, 다음과 같은 composite 인덱스가 존재할 때 다양한 조건들이 어떻게 처리되는 지를 살펴보자. Composite index on T1(i1, i2, i3, i4) WHERE i1 = 1 AND i2 = 1 AND i3 = 1 AND i4 = 1 위의 WHERE절에 포함되어 있는 모든 조건은 composite 인덱스를 이용하여 모두 key range 처리가 가능하다. WHERE i1 = 1 AND i2 > 0 AND i3 = 1 AND i4 = 1 Key Range : i1 = 1, i2 > 0 Filter(or Key filter) : i3 = 1, i4 = 1 위의 예에서 key range 처리로 검색할 수 있는 조건은 두 개로 결정되고 나머지는 filter 로 처리가 된다. 이는 key range 처리는 최소값과 최대값을 결정할 수 있는 영역 내에서만 가능하기 때문에 부등호 연산 이후의 조건절은 key range 처리를 할 수 없다. WHERE i1 = 1 AND i3 = 1 AND i4 = 1 Key Range : i1 = 1 Filter : i3 = 1, i4 = 1 위의 예에서는 모두 등호 연산을 사용하고 있지만, key range 처리가 가능한 조건은 하나뿐이다. 이는 composite 인덱스를 구성하고 있는 칼럼들의 순서에 모두 부합하는 조건이 있을 경우에만 key range처리가 가능하기 때문이다. 즉, i2 칼럼에 대한 조건이 없어 i3, i4 에 대한 조건은 key range처리를 할 수 없다. 위와 같이 composite 인덱스의 경우에는 조건들이 칼럼의 누락 없이 키 칼럼의 순서에 부합할 때와 해당 조건이 등호 연산으로 이루어져 있을 때 key range 처리를 사용하여 평가될 수 있다. 예를 들어 다음과 같은 질의가 빈번하게 사용되어 인덱스를 추가하려고 한다면 인덱스를 최대한 활용할 수 있도록 생성하는 것이 바람직하다. WHERE i1 > 0 AND i2 = 1 바람직한 인덱스: Index on T1(i2, i1) i2 와 i1 칼럼을 참조하는 조건들을 평가하기 위해 filer 없이 key range 처리가 사용될 수 있다. 부적절한 인덱스: Index on T1(i1, i2) i1 칼럼을 참조하는 조건을 평가하는데는 key range 처리가 사용될 수 있으나, i2 칼럼을 참조하는 조건을 평가하기 위해서는 filter 처리가 사용된다. 그러므로 이 인덱스가 더 비효율적이다. 인덱스와 비교 연산자 인덱스가 존재하고 해당 칼럼에 대한 조건이 존재한다고 해서 290 Administrator’s Manual 반드시 인덱스를 사용될 수 있는 것은 아니다. 즉, 조건절의 기술 형태와 비교 연산자의 종류에 따라 인덱스의 사용 가능 여부가 결정되므로 이에 대한 주의가 필요하다. 비교 연산자의 종류와 인덱스 사용 가능 여부는 다음과 같다. 종류 비교 연산자 인덱스 사용 가능 여부 비고 단순 비교 = O != O O >= O 범위 비교 BETWEEN O NOT BETWEEN O 멤버 비교 IN O NOT IN O 패턴 비교 LIKE O 가능: T1.i1 LIKE abc% 불가: T1.i1 LIKE %abc NOT LIKE X NULL 비 교 IS NULL O IS NOT NUL O 존재 비교 EXISTS X NOT EXISTS X UNIQUE X NOT UNIQUE X Quantify ANY =ANY O !=ANY O ANY O >=ANY O Quantify ALL =ALL O != ALL O ALL O SQL 튜닝 291 >= ALL O [표 11-4] 비교 연산자에 따른 인덱스 사용 여부 Geometry 데이터 타입 관련 비교 연산자는 다음과 같다. R-Tree 인덱스가 존재하는 경우에만 geometry 데이터 타입 칼럼에 정의된 인덱스를 사용할 수 있다. 종류 비교 연산자 인덱스 사용 가능 여부 비고 Geometry 비교 CONTAINS O R-Tree index only CROSSES O DISJOINT O DISTANCE O EQUALS O INTERSECTS O ISEMPTY X ISSIMPLE X NOT CONTAINS X NOT CROSSES X NOT EQUALS X NOT OVERLAPS X NOT RELATE X NOT TOUCHES X NOT WITHIN X OVERLAPS O RELATE X TOUCHES O WITHIN O [표 11-5] Geometry 비교 연산자 사용 여부 위와 같이 인덱스가 존재하고 인덱스를 사용할 수 있는 비교 연산자라 하더라도 항상 인덱스가 사용될 수 있는 것은 아니다. 즉, 조건절의 형태에 따라 인덱스의 사용 가능 여부가 결정된다. 인덱스가 사용될 수 있는 조건절의 형태는 다음과 같다. (단, 조건절의 예제에서 해당 칼럼이 INTEGER 타입임을 가정한다.) 조건절의 형태 가능한 예 불가능한 예 인덱스 사용이 가능한 비교 연산자 여야 한다. T1.i1 = 1 T1.i1 NOT LIKE a 칼럼이 있어야한다. T1.i1 = 1 1 = 3 칼럼에 대한 연산이 없어야한다. T1.i1 = 1 + 1 T1.i1 + 1 = 3 292 Administrator’s Manual 연산자의 한쪽에만 칼럼이 있어야한 다. (T1.i1, T1.i2) = (1, 1) T1.i1 = T2.i1 (T1.i1, 1) = (1, T1.i2) T1.i1 = T1.i2 칼럼의 타입(값)이 변경되지 않아야 한다. T1.i1 = SMALLINT'1' T1.i1 = 1.0 [표 11-6] 조건절에 따른 인덱스 사용 여부 위와 같이 인덱스를 사용하기 위해서는 조건절의 기술에 주의를 기울여야 한다. 특히 칼럼의 값에 대한 연산이나 타입 변환이 발생하지 않도록 주의하여야 한다. 인덱스 사용을 고려한 데이터 타입과 데이터 변환에 대한 설명은 다음 절(인덱스와 데이터 타입)에서 자세히 설명한다. 인덱스와 데이터 타입 WHERE 절에서 참조하는 칼럼에 인덱스가 생성되어 있다고 해서 항상 인덱스 스캔이 가능한 것은 아니다. 데이터 타입과 데이터 변환에 따라 인덱스 스캔이 가능한 경우도 있고 그렇지 않은 경우도 있다. SELECT * FROM T1 WHERE T1.i1 = ? 위의 질의에서 i1 칼럼이 VARCHAR 타입이고 PRIMARY KEY인 경우, iSQL로 이 쿼리의 실행 계획을 확인하면 인덱스 스캔 가능으로 나타난다. 하지만 실제 변수를 바인딩할 때 INTEGER 등의 숫자형으로 바인딩을 하는 경우 칼럼 값을 숫자형으로 변환하여 비교해야 하므로 인덱스 스캔이 불가능하다. 따라서, iSQL에서 인덱스 스캔으로 수행되는 질의인지 확인하고, 실행 계획이 인덱스 스캔이 가능한 것으로 표시되는 경우에도 실제 응용 프로그램에서 바인딩하는 값과 칼럼의 데이터 타입을 확인해야 한다. 그렇지 않으면 응용 프로그램에서는 전체 테이블을 스캔(full table scan)하여 iSQL상에서의 실행 속도에 비해 현격한 속도 차이가 날 수도 있다. 데이터 타입과 인덱스 사용 가능 여부는 다음과 같다. 검은 부분으로 표시되는 부분은 비교연산 수행시, 키 칼럼에 타입 변환이 발생하게 된다. VALUE KEY CHAR VARCHAR SMALLINT INTEGER BIG INT NUMERIC FLOAT REAL DOUBLE DATE BLOB NIBBLE BYTE GEOMETRY CHAR O O X X X X X X X X - - - - VARCHAR O O X X X X X X X X - - - - SQL 튜닝 293 SMALLINT X X O O O O O O O - - - - - INTEGER X X O O O O O O O - - - - - BIGINT X X O O O O O O O - - - - - NUMERIC O O O O O O O O O - - - - - FLOAT O O O O O O O O O - - - - - REAL X X O O O O O O O - - - - - DOUBLE O O O O O O O O O - - - - - DATE O O - - - - - - - O - - - - BLOB - - - - - - - - - - O - - - NIBBLE - - - - - - - - - - - O - - BYTE - - - - - - - - - - - - O - GEOMETRY - - - - - - - - - - - - - O [표 11-7] 데이터 타입에 따른 인덱스 사용 여부 데이터 타입은 다음과 같이 크게 문자형 계열과 숫자형 계열로 구분할 수 있으며, 각 계열에 속하는 데이터 타입들간의 비교는 모두 인덱스를 사용할 수 있다. 문자형 계열 CHAR, VARCHAR 숫자형 계열 Native 정수형 BIGINT, INTEGER, SMALLINT 실수형 DOUBLE, REAL Non-Native (지수형) 고정 소수점형 NUMERIC, DECIMAL, NUMBER(p), NUMBER(p,s) 부동 소수점형 FLOAT, NUMBER 즉, 문자형 계열에 속하는 CHAR, VARCHAR간의 비교 또는 숫자형 계열에 속하는 정수형, 실수형, 지수형간의 비교시에는 모두 인덱스 사용이 가능하다. 문자형 계열 char_column = VARCHAR’abc’ varchar_column = CHAR’abc’ 숫자형 계열 integer_column = DOUBLE’1’ number_column = DOUBLE’1’ integer_column = NUMBER’1’ 숫자형 계열의 서로 다른 데이터 타입간 비교 연산에 대해서는 다음의 변환표를 기준으로 변환하고 비교한다. 정수형 실수형 지수형 294 Administrator’s Manual 정수형 정수형 실수형 지수형 실수형 실수형 실수형 실수형 지수형 지수형 실수형 지수형 인덱스 칼럼에 변환이 발생하는 경우가 이에 해당되는데, 인덱스 칼럼의 값에 변환이 발생한다 할지라도, 이 비교 기준에 의해 내부적으로 인덱스 칼럼의 변환된 값으로 비교연산을 수행하게 된다. 그러므로, bigint_col = NUMERIC’1’과 같이 칼럼에 변환이 발생하는 index scan은 bigint_col = BIGINT’1’과 같이 칼럼에 변환이 발생하지 않는 index scan보다 수행속도가 느리게 된다. 이 외에 인덱스 스캔과 별도로 두 값을 비교하는 비교 연산자의 수행 성능은 비교 대상 데이터의 타입과 밀접한 관계가 있다. 같은 데이터 타입간의 비교일 경우에는 데이터 변환 비용이 없으므로 최적의 성능을 발휘하겠지만 서로 다른 데이터 타입간의 비교라면 데이터 변환이 최소화되도록 해야 한다. 예를 들어 숫자형 타입과 문자형 타입을 비교할 경우 데이터 변환 비용만 고려한다면 FLOAT과 VARCHAR인 경우 가장 짧은 변환 경로를 가진다. 그러나 데이터 타입별로 데이터 저장 크기와 형식에 차이가 있으므로 이를 종합적으로 고려해 데이터 타입을 결정해야 한다. 다음은 데이터 타입 변환 경로를 도식화한 그림이다. SQL 튜닝 295 SMALLINT BIGINT INTEGER REAL DOUBLE NUMERICFLOAT INTERVAL CHARVARCHAR DATE NULLALL <0+0+0> <0+E+L> <0+E+0> <0+0+0> <0+E+0> <0+0+L> <0+E+0><0+0+L> <0+E+L> <0+E+0> <0+0+0> <0+0+0> <0+E+L> <0+0+0> <0+0+0> <0+0+0> <0+0+L> <0+0+L> ABA와 C를 비교하는 경우 항상 A가 C로 변환되거나 C가 A로 변환되는 것은 아니다. 연산자에 따라 A가 C로 변할 수도 있고, 그 반대인 경우도 있으며, A가 B로 변환되고 C가 B로 변환되어 연산을 수행하는 경우도 있다. C ABA 타입에서 B 타입으로 이 타입 변환 가 G : Group Penalty E : Error Penalty G >> E >> L L : Loss Penalty [그림 11-3] 데이터변환 타입 경로 위와 같이 인덱스가 사용될 수 있도록 조건절을 기술하는 것은 매우 중요하다. 조건절의 유형에 따라 성능에 영향을 미칠 수 있으므로 WHERE절의 기술 및 응용 프로그램의 작성 시 주의를 기울여야 한다. Optimizer가 개별 테이블에 대한 액세스 방법의 결정이 완료되면, 조인에 대한 처리를 수행하게 된다. 이 때, 개별 테이블에 대하여 결정된 액세스 방법은 절대적인 것이 아니며, 조인 처리 과정에서 재조정될 수도 있다. 조인 순서의 결정 296 Administrator’s Manual 복잡한 질의의 경우 조인의 순서 및 조인의 처리 방법은 질의 성능에 가장 큰 영향을 미치게 된다. 따라서, 적절한 조인 순서와 조인 방법이 선택되었는지를 판단하고 조정하는 것은 질의 성능 향상에 큰 도움이 된다. Optimizer는 조인을 처리하기 위하여 다음과 같은 단계를 따른다. 1. 조인 조건을 이용한 조인의 그룹화 2. 각 그룹의 조인 관계 표현 3. 각 그룹의 조인 순서 결정 4. 각 조인의 조인 방법 결정 5. 그룹간의 조인 순서 및 조인 방법 결정 이와 같이 optimizer가 각 단계를 수행하는 과정을 이해하는 것은 SQL 튜닝에 도움이 된다. 이 절에서는 optimizer가 조인 순서를 결정하는 과정에 대하여 알아본다. 조인 순서는 조인 selectivity를 이용한 Join greedy algorithm를 기반으로 결정된다. 조인 그룹의 분류 조인 관계가 없는 테이블들을 모두 고려하여 조인 순서를 결정하는 것은 일반적으로 부하만을 증가시킬 뿐 올바른 조인 순서를 결정하는데 큰 도움이 되지 않는다. 즉, 조인 관계가 있는 테이블끼리 하나의 그룹으로 묶어 처리하고 이후 각 그룹에 대한 조인 순서를 결정하는 것이 효율적이다. 예를 들어, 다음과 같은 질의를 살펴보자. SELECT * FROM T1, T2, T3, T4, T5 WHERE T1.i1 = T2.a1 AND T2.a2 = T3.m1 AND T4.x1 = T5.z1; 조인 그룹의 분류: (T1, T2, T3), (T4, T5) 위의 예와 같이 두 그룹은 조인 관계가 전혀 없는 테이블이다. 그러므로, 조인 순서를 결정하기 위하여 모든 테이블을 한꺼번에 고려하여 처리하는 것은 비용을 증가시킬 뿐이다. 일반적인 경우 이러한 분류 방법이 효율적이나 응용 프로그램의 성격 및 데이터 구성에 따라 적합하지 않을 수 있다. 이런 경우 힌트를 통하여 조인 순서를 제어할 수 있다. 이와 같이 조인 그룹을 분류한 후 각 조인 그룹에 대하여 다음과 같은 과정을 통하여 조인 순서를 결정하게 된다. 조인 관계의 구성 SQL 튜닝 297 각 조인 그룹에 대하여 조인 관계를 구성하는 것은 조인 순서 결정 시 직접적인 조인 관계가 없는 테이블간의 비교 비용을 줄여 보다 효율적인 조인 순서를 결정하기 위함이다. 예를 들어 다음과 같은 질의를 살펴 보자 SELECT * FROM T1, T2, T3, T4 WHERE T1.i1 = T2.a1 AND T2.a2 = T3.m2 AND T3.m3 = T4.x3; 위의 질의에서 조인 관계는 다음과 같이 표현될 수 있다. T1T2T3T4 조인 관 T1.i1 = T2.a1T2.a2 = T3.m2T3.m3 = T4.x3 위와 같이 조인 관계를 관리하며, 조인 순서 결정 시 조인 관계만을 고려하여 비용 평가를 함으로서 (T1, T4)와 같이 직접적인 조인 관계가 없는 테이블간의 조인이 우선적으로 결정되는 것을 방지한다. 조인 관계를 고려하는 것이 일반적으로 효율적인 조인 순서를 결정하는 데 도움이 되나, 반드시 올바른 조인 순서를 결정하지는 않는다. 따라서, 필요한 경우 힌트를 사용하여 조인 순서를 제어할 수 있다. 조인 관계의 순서 결정 위에서 생성한 조인 관계를 이용하여 각 조인 관계들 중 가장 효율적인 조인 관계 순서를 결정하게 된다. 조인 관계의 순서를 결정하는 방법은 조인 관계들 중 조인 선택도(selectivity)가 가장 효율적인 조인 관계를 우선 선택한다. 그리고 다시 선택된 관계로부터 관련된 조인 관계들 중에 효율적인 조인 관계를 선택해 가는 방식으로 결정된다. 이 때, 조인 관계의 순서라 함은 실제 조인 순서가 아니다. 실제 조인 순서는 조인 방법의 결정을 통해 완성된다. 298 Administrator’s Manual T1 JOIN T2 T3 JOIN JOIN T4 조인 관 의 순서 T1 JOIN T2 T3 JOIN JOIN T4 조인 방법 결정 후의 실제 조인 순서 [그림 11-4] 조인 관계의 순서 결정 위의 그림에서 보듯이 이 과정에서의 조인 관계의 순서는 조인 관계의 깊이만을 결정할 뿐이다. 실제 조인 순서는 조인 방법 선택에 의하여 결정된다. 조인 관계 순서의 가장 중요한 요소는 조인의 선택도 (selectivity)이며, 두 테이블의 조합을 통해 생성되는 결과 집합의 원래 테이블 크기에 대한 비율을 의미한다. 즉, 조인 관계의 순서 결정시 조인을 통한 결과 집합의 크기의 대소를 비교하기 보다 결과 집합의 크기가 원래 테이블의 레코드 개수에 비해서 얼마나 많이 줄어드는가를 기준으로 판단하게 된다. Optimizer는 조인 selecitivty 를 아래처럼 계산한다. 이 공식의 자세한 설명은 이 문서의 범위를 벗어난다. [T(R) * T(S) / MAX[V(R.a), V(S.a)]/ [T(R) + T(S)] 개념적인 Join selectivity 산 이와 같은 join selecitivty 를 이용한 조인 관계 순서의 결정은 보다 효율적인 비율로 결과 집합을 줄일 수 있는 조인 관계를 우선적으로 선택하게 되며, 추후 조인 방법 결정에 의하여 비교적 정확한 조인 순서가 결정된다. 예를 들어, 하나의 질의에 포함된 각 테이블의 레코드 개수와 조인으로 생성되는 결과의 개수가 다음과 같을 때를 살펴보자. T(R) = 10, T(S) = 10, T(R JOIN S) = 10 T(T) = 1000, T(U) = 1000, T(T JOIN U) = 100 위의 예에서 테이블 R과 S를 조인한 결과의 개수가 T와 U를 조인한 결과의 개수보다 적지만, 오히려 결과 집합을 아주 큰 비율로 줄일 수 있는 T와 U의 관계가 더 중요한 조인 관계가 된다. SQL 튜닝 299 Optimizer가 조인 관계를 이용하여 생성한 조인 순서가 모든 경우에 있어 항상 바람직함을 보장할 수는 없다. 이를 위해 조인 순서 힌트를 사용하여 조인 순서를 제어할 수 있다. 조인 관계의 순서를 결정한 후에는 두 테이블간의 조인 방법을 결정하게 되고 최종적으로 조인 순서가 결정된다. 조인 방법의 결정 조인 관계의 순서가 결정되면, 두 테이블의 각 조인 관계에 대하여 조인 방법을 결정하게 된다. 이 때, 각 조인 방법의 비용 비교를 통해 조인의 순서, 방향, 및 조인 방법을 결정하게 된다. 알티베이스가 지원하는 조인 방법은 다음과 같이 크게 네 가지 계열에 속한다. Nested loop 조인 계열 Sort-based 조인 계열 Hash-based 조인 계열 Merge 조인 계열 각 계열 별 조인 방법 및 실행 가능 여부는 다음과 같다. 조인 계열 조인 방법 조인 방향 Left=>Right Right=>Left Nested Loop Full nested loop C, I, L C, I, R Full store nested loop C, I, L, F C, I, R, F Index nested loop I, L I, R Anti outer nested loop F F Sort-based One pass sort join I, L, F I, R, F Multi pass sort join I, L, F I, R, F Hash-based One pass hash join I, L, F I, R, F Multi pass hash join I, L, F I, R, F Merge-based Index merge join I I Sort merge join I I 사용 가능한 조인의 종류 C (Cartesian Product): 조인 관계를 갖지 않는 두 테이블의 조합 I (Inner Join): 조인 관계를 갖는 두 테이블의 일반적인 조인 L (Left outer join): Left outer 조인 관계를 갖는 두 테이블의 조인 R (Right outer join): Right outer 조인 관계를 갖는 두 테이블의 조인 F (Full outer join): Full outer 조인 관계를 갖는 두 테이블의 조인 [표 11-8] 조인방법에 따른 실행 가능 여부 Optimizer는 위와 같은 다양한 조인 방법들 중 적용 가능한 조인 300 Administrator’s Manual 방법에 대한 비용 평가를 통해 가장 효과적인 조인 방법을 선택하고 조인의 방향을 결정한다. 조인 방법이 결정되면 기준 테이블 (outer table)은 왼쪽에 위치시키고 반복 테이블 (inner table)은 오른쪽에 위치시킨다. 실행 계획 트리의 분석을 통해 어떠한 조인 방법이 선택되었는 지를 판단 가능하며, 힌트를 사용하여 제어할 수 있다. 이 절에서는 각 조인 계열의 조인 방법에 대한 내용을 살펴 본다. Nested Loop 조인 계열 nested loop 조인 계열에는 다음과 같은 조인 방법들이 있다. Full nested loop join Full store nested loop join Index nested loop join Anti outer nested loop join Full nested loop join방법은 한 테이블의 모든 레코드를 다른 테이블의 모든 레코드와 조인하는 방법이다. 이 방법은 일반적으로 조인 관계가 존재하지 않는 두 테이블간의 조인시 사용될 가능성이 높다. SELECT * FROM T1, T2; Full store nested loop join 방법은 반복 테이블(inner table)의 결과를 저장한 후 full nested loop join을 적용하는 방법이다. 이 방법은 조인 조건 이외의 조건 처리에 의하여 결과 집합이 매우 줄어드는 경우 적용될 가능성이 높으며, 일반적으로 조인 그룹간의 Cartesian product (교차 조인)에 의하여 사용될 가능성이 높다. SELECT * FROM T1, T2 WHERE T1.i1 = 1 AND T2.i1 = 1; Index nested loop join 방법은 인덱스를 이용하여 조인 조건을 처리하는 방법이다. 기준 테이블 (outer table)의 레코드 수가 적고 반복 테이블 (inner table)에 인덱스가 존재하는 경우에 사용될 가능성이 높다. Index on T2(i1) SELECT * FROM T1, T2 WHERE T1.i1 = T2.i1 AND T1.i1 = 1; Anti outer nested loop join 방법은 FULL OUTER JOIN에서만 사용되며, 기준 테이블 (outer table)과 반복 테이블 (inner table) 모두 조인 조건에 해당하는 칼럼에 대하여 인덱스가 정의되어 있을 때 사용 가능될 수 있다. 이 경우 다른 조인 방법에 비해 이 방법이 선택될 가능성이 높다. Index on T1(i1), Index on T2(i1) SELELCT * FROM T1 FULL OUTER JOIN T2 ON T1.i1 = T2.i1; SQL 튜닝 301 각 조인 방법들의 수행 비용은 개략적으로 Access cost + Disk I/O cost로 계산된다. 조인 방법 Access Cost Disk I/O cost No Buffer Miss Buffer Miss Full nested T(L) * T(R) B(L) + B(R) B(L) + T(L) * B(R) Full store nested T(L) * T(R) + S(R) B(L) + S(R) + B(R) B(L) + S(R) + T(L) * B(R) Index nested T(L) * [log(T(R)) + s * T(R)] B(L) + B(R) * [1 + (log s/log T(R))] B(L) + T(L) * s * [1 - M/B(R)] Anti outer T(L) * [log(T(R)) + s * T(R)] B(L) + B(R) * [1 + (log s/log T(R))] B(L) + T(L) * s * [1 - M/B(R)] 참조) L: 기준 테이블, R: 반복 테이블 T(): 레코드 개수, B(): 디스크 페이지 개수, S(): 저장 비용, M: 버퍼 페이지, s: 조인 조건의 selectivity [표 11-9] nested loop 조인 계열의 비용 계산법 Sort-based 조인 계열 sort-based 조인 계열에는 다음과 같은 조인 방법들이 있다. One-pass sort-based join Multi-pass sort-based join Sort-based 조인 방법은 반복 테이블(inner table)을 정렬된 순서로 저장하고 조인 조건을 이용하여 범위 검색을 하는 방법이다. 일반적으로 이 방법은 인덱스가 없고 부등호 조인 조건을 처리할 때 선택될 가능성이 높다. SELECT * FROM T1, T2 WHERE T1.i1 > T2.i1; One-pass sort-based 조인 방법은 반복 테이블(inner table)의 데이터 양이 적어 버퍼 내에서 관리가 가능할 때 사용된다. 이 방법은 메모리 테이블이 반복 테이블(inner table)로 사용될 경우 항상 사용된다. Multi-pass sort-based 조인 방법은 반복 테이블(inner table)의 데이터 양이 방대하여 버퍼의 범위 내에서 관리할 수 없을 때 사용된다. 이 방법은 디스크 I/O를 줄이기 위해 사용된다. 이 방법은 기준 테이블(outer table)과 반복 테이블(inner table)을 모두 정렬하여 저장한다. 기준 테이블(outer table)의 데이터 정렬 순서로 조인 조건을 검사하게 되어 반복 테이블(inner table)의 동일한 디스크 페이지 접근 확률을 높이게 된다. 이 때문에 디스크 I/O 비용이 줄어들게 된다. 302 Administrator’s Manual 각 조인 방법들의 수행 비용은 개략적으로 Access cost + Disk I/O cost로 계산된다. 조인 방법 Access Cost Disk I/O cost No Buffer Miss Buffer Miss One-pass sort S(R) + T(L) * [log(T(R)) + s * T(R)] B(L) + S(R) + B(R) B(L) + 3S(R) + T(L) * s * B(R) Multi-pass sort S(L) + S(R) + T(L) * [log(T(R)) + s * T(R)] S(L) + S(R) + B(L) + B(R) 3S(L) + 3S(R) + B(L) + B(R) 참조) L: 기준 테이블(outer table), R: 반복 테이블(inner table) T(): 레코드 개수, B(): 디스크 페이지 개수, S(): 정렬 저장 비용, M: 버퍼 페이지, s: 조인 조건의 selectivity [표 11-10] Sort-based 조인 계열의 비용 계산법 Hash-based 조인 계열 hash-based 조인 계열에는 다음과 같은 조인 방법들이 있다. One-pass hash-based join Multi-pass hash-based join Hash-based 조인 방법은 반복 테이블(inner table)을 hash 구조로 저장하고 조인 조건을 이용하여 범위 검색을 하는 방법이다. 이 방법은 등호 연산자를 사용한 조인 조건만을 처리할 수 있으며 인덱스가 없을 때 선택될 가능성이 높다. SELECT * FROM T1, T2 WHERE T1.i1 = T2.i1; One-pass hash-based 조인 방법은 반복 테이블(inner table)의 데이터 양이 적어 버퍼 내에서 관리가 가능할 때 사용되며, 메모리 테이블이 반복 테이블(inner table)로 사용될 경우는 항상 이 방법이 사용된다. Multi-pass hash-based 조인 방법은 반복 테이블(inner table)의 데이터 양이 방대하여 버퍼의 범위 내에서 관리할 수 없을 때 사용되며 디스크 I/O를 줄이기 위한 방법이다. 기준 테이블 (outer table)과 반복 테이블(inner table)은 모두 동일한 hash 함수를 사용하여 분할되어 여러 임시 테이블에 저장된다. 그러므로, 이 방법은 각 임시 테이블끼리 조인 조건을 검사하여 반복 테이블(inner table)의 동일한 디스크 페이지 접근 확률을 높이게 된다. 각 조인 방법들의 수행 비용은 개략적으로 Access cost + Disk I/O cost로 계산된다. SQL 튜닝 303 조인 방법 Access Cost Disk I/O cost No Buffer Miss Buffer Miss One-pass hash H(R) + T(L) * s * T(R) B(L) + H(R) + B(R) B(L) + 3H(R) + T(L) * s * B(R) Multi-pass hash H(L) + H(R) + T(L) * s * T(R) H(L) + H(R) + B(L) + B(R) 3H(L) +3H(R) + B(L) + T(L) * s * B(R) 참조) L: 기준 테이블(outer table), R: 반복 테이블(inner table) T(): 레코드 개수, B(): 디스크 페이지 개수, H(): 해싱 저장 비용, M: 버퍼 페이지, s: 조인 조건의 selectivity [표 11-11] Hash-based 조인 계열의 비용 계산법 Merge 조인 계열 Merge 조인 방법은 두 테이블의 데이터가 정렬될 경우 매우 효율적인 방법이다. 이 방법에는 기준 테이블과 반복 테이블의 개념이 없으며 양쪽 테이블을 순차적으로 진행하면서 조인 조건을 검사한다. 양쪽 테이블이 모두 조인 키를 기준으로 정렬되어야 한다. 그러나 각각의 테이블이 인덱스를 통해 정렬되어 있다면 테이블을 정렬할 필요가 없어진다.. Index on T1(i1), Index on T2(a1) SELECT * FROM T1, T2 WHERE T1.i1 = T2.a1; Merge 조인 방법의 수행 비용은 개략적으로 Access cost + Disk I/O cost로 계산된다. 테이블의 유형 Access Cost Disk I/O cost No Buffer Miss Buffer Miss Indexed Table T(L) B(L) B(L) Non-index Table S(L) + T(L) S(L) + B(L) 3S(L) + B(L) 참조) Merge 조인 비용은 두 테이블의 비용을 합산함. L: 테이블 T(): 레코드 개수, B(): 디스크 페이지 개수, S(): 정렬 저장 비용 [표 11-12] Merge 조인 계열의 비용 계산법 지금까지 질의 성능에 가장 큰 영향을 미치는 FROM과 WHERE 절을 의미하는 critical path의 최적화 과정에 대하여 살펴보았다. 이후의 최적화 과정은 non-critical path에 대한 최적화 과정으로 각 구문의 형태에 따라 구분하여 설명한다. 304 Administrator’s Manual 그룹 연산의 최적화 critical path에 대한 최적화 과정후에 Optimizer는 non-critical path, 즉 GROUP BY, HAVING, 및 aggregation 연산 등의 그룹 연산에 대한 최적화를 수행한다. 그룹 연산의 최적화시 기본적으로 hashing과 sorting에 대한 비용 계산을 통해 실행 방법이 결정된다. 아래와 같은 최적화 기법들이 적용 가능한 경우 이를 적용한다. 정렬 순서를 이용한 GROUP BY 최적화 정렬 순서를 이용한 MIN/MAX 최적화 MIN 또는 MAX 연산내의 DISTINCT 제거 정렬 순서를 이용한 DISTINCT aggregation 정렬 순서를 이용한 GROUP BY 최적화 GROUP BY에 기술된 칼럼별로 그룹을 구분하기 위해 기본적으로 hashing 또는 sorting을 필요로 한다. 이러한 연산은 내부적으로 많은 저장 공간과 높은 CPU 사용을 요구한다. Optimizer는 GROUP BY를 처리하기 위한 인덱스가 존재하거나 critical path 최적화 과정에서 해당 칼럼의 순서가 보장될 경우 이 방법을 사용할 수 있다. Optimizer는 다음의 경우에 hashing 및 sorting을 사용하는 것을 피한다. GROUP BY 절의 칼럼에 인덱스가 있는 경우 이전 작업에서 GROUP BY 절의 칼럼을 기준으로 데이터가 이미 정렬된 경우 예제로 든 다음 쿼리에서, Optimizer는 별도의 hashing 또는 sorting이 수행될 필요성을 제거한 실행 계획 트리를 생성한다. 않도록 실행 계획을 생성한다. 모든 질의에 항상 이러한 최적화가 가능한 것은 아니므로, 실행 계획 분석을 통하여 적용 가능 여부를 판단할 필요가 있다. Index on T1(i1) SELECT SUM(i2) FROM T1 GROUP BY i1; SELECT SUM(i2) FROM T1 WHERE i1 > 0 GROUP BY i1; 다음 예를 통해 GROUP BY 절에서 참조된 인덱스가 있는 칼럼을 최적화에 활용하는 방법에 대하여 알아 보자. Index IDX1 on T1(i1, i2), Index IDX2 on T1(i1, i3) SELECT * FROM T1 WHERE i1 > 0 GROUP BY i1, i3; SQL 튜닝 305 위의 질의를 처리하기 위해 optimizer는 critical path 처리 과정에서 IDX1 또는 IDX2 를 사용할 수 있다. IDX1을 사용한다면 GROUP BY절을 처리하기 위해 hashing 및 sorting이 필요한 반면에, IDX2를 사용할 경우 별도의 저장이 필요없다. 사용자가 실행 계획 트리를 분석하여 IDX1을 사용하고 있음을 확인했다면, 힌트를 사용해서 IDX2를 강제적으로 사용하게 할 수 있다. 유사한 개념으로 다음 질의 수행 시 해당 테이블에 인덱스가 없는 경우를 고려해 보자 SELECT * FROM T1 WHERE i3 > 0 GROUP BY i1, i3; 위의 경우 T1(i3, i1) 칼럼에 Composite 인덱스를 생성하면 질의 성능을 향상시킬 수 있다. GROUP BY i1, i3 와 GROUP BY i3, i1 구문은 결과 집합의 레코드 순서만 다를 뿐 결과 집합은 동일하기 때문에 GROUP BY 절의 칼럼 순서는 중요하지 않다. 사용자가 T1(i3, i1) 칼럼에 Composite 인덱스를 생성하면, i3>0, 범위 검색은 이 predicate을 검사하기 위해서 사용될 수 없다. 정렬 순서를 이용한 MIN/MAX 최적화 GROUP BY 절이 없는 MIN 또는 MAX aggregation의 경우 인덱스를 이용하여 최소값과 최대값을 쉽게 검색할 수 있다. 이러한 기법을 정렬 순서를 이용한 MIN, MAX 최적화 기법이라 한다. 즉, 다음과 같은 질의의 경우 optimizer는 인덱스를 사용하여 MIN 또는 MAX를 처리할 수 있도록 한다. 즉, MIN의 경우 인덱스를 가장 작은 값으로부터 검색하고, MAX의 경우 인덱스를 가장 큰 값으로부터 검색한다. Index on T1(i1) SELECT MIN(i1) FROM T1; SELECT MAX(i1) FROM T1 WHERE i1 < 0; 최소값 또는 최대값을 얻는 질의가 빈번하게 사용된다면 해당 칼럼에 인덱스를 생성하는 것이 전체 데이터를 비교하지 않아도 되기 때문에 성능 향상에 큰 도움이 된다. 그러나, 다음과 같이 MIN과 MAX를 함께 사용하는 경우는 인덱스를 한 쪽 방향으로만 검색할 수 없기 때문에 별도의 최적화가 불가능하다. SELECT MIN(i1), MAX(i1) FROM T1; 그러므로 다음과 같이 질의를 작성하는 것이 성능 향상에 도움이 된다. SELECT MIN(i1) FROM T1 306 Administrator’s Manual U N I O N AL L SEL EC T M AX( i 1 ) F R O M T 1 ; MIN 또는 MAX연산 내의 DISTINCT 제거 다음의 두 질의는 수학적으로 완전 동치이다. 즉, DISTINCT 키워드는 무의미하다. SELECT MIN(DISTINCT i2) FROM T1 GROUP BY i1; SELECT MIN(i2) FROM T1 GROUP BY i1; 물론 optimzer가 MIN 또는 MAX내에 DISTINCT가 존재할 경우 이를 제거하지만, 사용자가 의미 없는 구문을 기술하지 않는 것이 바람직하다. 정렬 순서를 이용한 DISTINCT aggregation SUM(DISTINCT i1) 과 같이 DISTINCT 칼럼을 인자로 같는 aggregation 연산은 중복 제거를 위해 별도의 저장 및 hashing 작업이 필요하다. 그러나, GROUP BY절 없이 사용된 DISTINCT aggregation의 경우, 인덱스가 사용되거나 이전의 최적화 과정에서 해당 칼럼이 적절히 정렬되었다면, 중복 제거를 위한 별도의 저장 공간을 필요로 하지 않는다. SELECT SUM(DISTINCT i1) FROM T1; SELECT COUNT(DISTINCT i1) FROM T1 WHERE i1 > 0; 위와 같은 질의가 빈번히 사용될 경우 해당 칼럼에 인덱스를 생성하면 중복 제거를 위한 별도의 저장 공간 및 hashing 비용이 필요 없게 되어 성능 향상을 꾀할 수 있다. DISTINCT절의 최적화 DISTINCT 절은 기본적으로 hashing 또는 sorting으로 처리가 가능하며, optimizer는 비용 비교를 통해 수행 방법을 결정한다. Optimizier는 DISTINCT 절에 기술된 칼럼에 대하여 인덱스가 존재하거나 하위 구문의 최적화 과정에서 정렬 순서가 보장된다면 별도의 저장 공간 없이 처리할 수 있도록 최적화한다. 이를 “정렬 순서를 이용한 DISTINCT 최적화” 기법이라 한다. 예를 들어 다음과 같은 질의는 “정렬 순서를 이용한 DISTINCT 최적화”가 적용되어 별도의 저장 공간 없이 처리가 가능하다. Index on T1(i1, i2, i3) SQL 튜닝 307 SELECT DISTINCT i1, i2, i3 FROM T1; SELECT DISTINCT i2, i1 FROM T1 WHERE i1 > 0; DISTINCT 절에 기술된 칼럼은 인덱스의 칼럼 순서대로 기술될 필요는 없으나, 인덱스의 키 칼럼 순서로 모두 접근 가능해야 한다. 즉, 다음과 같은 질의에는 해당 인덱스를 사용할 수 없다. SELECT DISTINCT i1, i3 FROM T1; 이러한 특징을 잘 이해하고 있다면 다음과 같은 질의는 질의 변경을 통해 “정렬 순서를 이용한 DISTINCT 최적화”가 사용되게 할 수 있다. SELECT DISTINCT i1, i3 FROM T1 WHERE i2 = 0; SELECT DISTINCT i1, i2, i3 FROM T1 WHERE i2 = 0; 위와 같이 i2 칼럼을 DISTINCT 절에 추가하여 해당 최적화 기법이 사용되게 할 수 있다. 물론 이는 WHERE 절에 (i2 = 0) 과 같이 i2 값의 일정함을 보장하는 조건이 있기 때문에 동일한 결과 집합을 추출할 수 있으므로 쿼리 변경이 가능하다. 그러므로 인덱스를 생성할 때에도 WHERE 절 뿐 아니라 빈번히 사용되는 DISTINCT 절도 함께 고려하는 것이 바람직하다. 집합 연산의 최적화 UNION ALL 을 제외한 UNION, INTERSECT, MINUS등의 집합 연산은 중간 결과의 관리를 필요로 한다. Optimizer는 여러 개의 집합 연산이 중복되어 있을 때 결과 집합이 작은 순서로 해당 연산을 수행하도록 최적화하지만, 이 역시 비용 계산을 기반으로 이루어지므로 정확하지 않을수 있다. 따라서, 사용자가 결과 집합의 대소 여부를 알고 있다면 연산 순서를 명확히 하는 것이 바람직하다. SELECT * FROM large INTERSECT SELECT * FROM medium INTERSECT SELECT * FROM small; (SELECT * FROM small INTERSECT SELECT * FROM medium ) INTERSECT SELECT * FROM large; 308 Administrator’s Manual 일반적으로 집합 연산과 관련하여 사용자가 빈번히 범하는 오류는 UNION과 UNION ALL을 구분하지 않는다는 것이다. UNION은 중복 결과를 제거하는 반면, UNION ALL은 중복 결과를 제거하지 않는다. 즉, 동일한 테이블을 사용하는 경우 UNION의 성능이 UNION ALL보다 느릴 수 밖에 없다. 그러므로, 두 테이블의 결과가 중복된 것이 없음이 보장되거나 중복 제거가 필요 없는 경우라면 UNIOIN ALL을 사용하는 것이 바람직하다. ORDER BY절의 최적화 ORDER BY 절은 정렬을 필요로 한다. Optimizer는 다음과 같은 최적화 기법을 적용할 수 있는 지의 여부를 검사하여 실행 계획을 결정한다. 정렬 순서를 이용한 ORDER BY LIMIT sorting 정렬 순서를 이용한 ORDER BY Optimizer는 인덱스를 사용할 수 있거나 하위의 최적화 과정에서 ORDER BY 절에서 참조되는 칼럼의 정렬 순서가 보장된다면 별도의 sorting없이 처리할 수 있다. 예를 들어 Optimizer는 다음과 같은 질의의 경우 별도의 sorting없이 ORDER BY절을 처리한다. Index on T1(i1, i2, i3) SELECT * FROM T1 ORDER BY i1, i2, i3; SELECT * FROM T1 WHERE i1 = 0 ORDER BY i1, i2; ORDER BY 절의 칼럼이 인덱스 칼럼과 동일한 순서일 경우에만 해당 최적화 기법의 적용이 가능하다. 그러므로, 실행 계획의 분석을 통해 힌트등을 사용하여 ORDER BY절을 위한 sorting과정을 제거할 수 있다. Index IDX1 on T1(i1, i2), Index IDX2 on T1(i3) SELECT * FROM T1 WHERE i3 IS NOT NULL ORDER BY i1, i2; SELECT /*+ INDEX(T1, IDX1) */ * FROM T1 WHERE i3 IS NOT NULL ORDER BY i1, i2; 위의 예제에서는 IDX2인덱스를 이용하여 WHERE절을 처리하는 SQL 튜닝 309 것보다 IDX1 인덱스를 사용하여 ORDER BY절의 sorting비용을 제거하는 것이 효율적이라면 힌트를 사용하는 것이 바람직하다. LIMIT 절과 정렬 LIMIT 구문은 질의 결과의 전체 집합 중에서 일부만을 결과 집합으로 구성하는 구문이다. 아래 질의는 T1 테이블의 전체 레코드 중 5개의 결과만을 반환한다. SELECT * FROM T1 LIMIT 5; ORDER BY구문과 LIMIT 구문이 함께 사용되면, Optimizer는 LIMIT sorting 최적화를 수행한다. 이는 전체 레코드를 위한 공간을 사용하지 않고 LIMIT 구문에 기술된 개수만큼의 공간을 사용하여 정렬을 수행하는 방법이다. 예를 들어, 다음과 같은 질의는 정렬시 다섯 개의 레코드 공간만을 이용하여 정렬을 수행한다. SELECT * FROM T1 ORDER BY i1 LIMIT 5; 따라서, 전체 데이터에 대한 정렬 결과가 필요하지 않는 경우라면 LIMIT 구문을 이용하여 자원 효율 및 성능 향상을 기대할 수 있다. 파티션의 최적화 파티션드 테이블에 접근시 파티션 프루닝(pruning)과 필터링을 이용하여 불필요한 파티션을 제거하고 술어의 조건에 맞는 파티션만 참조하는 실행계획 트리(execution plan tree)가 생성된다. 파티션 프루닝은 실행(execution)중에 조건이 바뀌지 않는 고정 술어(fixed predicate)를 최적화한다. 그러나 가변 술어(variable predicate)는 조건에 부합하는 레코드가 저장된 파티션이 계속 바뀌므로, 불필요한 파티션을 실행계획 트리에서 제거하거나 조건에 부합하는 파티션만을 포함하는 실행계획 트리의 생성이 불가능하다. 이러한 가변 술어는 다음의 파티션 필터링으로 최적화된다. 범위 파티션 프루닝 리스트 파티션 프루닝 해시 파티션 프루닝 파티션 필터링 범위 파티션 프루닝 범위 파티션 프루닝이 가능한 술어의 형태는 인덱스를 사용하여 검색이 가능한 조건과 형태가 동일하다. 호스트 변수가 포함된 310 Administrator’s Manual 조건이거나 조인 조건의 경우는 해당되지 않는다. 이런 술어에는 범위를 나타내는 인덱스 사용이 가능한 모든 술어들이 포함되는데, 그 예는 다음과 같다. I1 = 1 i1 between 1 and 10 i1 > 5 tim e_id < 2006.04.01 Part_1 tim e_id < 2006.07.01 Part_2 tim e_id < 2006.10.01 Part_3 tim e_id >= 2006.10.01 Part_4 Sales (partition key : tim e_id) 2005.08.13 2006.01.21 2006.02.12 2006.03.31 ... 2006.04.01 2006.05.15 2006.06.12 ... ... 2006.08.17 2006.09.01 ... ... ... 2006.10.02 2006.11.11 2006.12.01 NULL ... SELECT sum (am ount_sold) FROM sales WHERE tim e_id <= to_date(‘20060918’, ‘YYYYMMDD’); SCAN(Part_1) SCAN(Part_2) SCAN(Part_3) PROJ GRAG PCRD(Sales) [그림 11-5] 범위 파티션 프루닝의 예 위의 [그림 10-5]의 Sales 테이블은 시간을 기준으로 총 4개의 파티션으로 분리된 파티션드 테이블이다. 파티션 키인 time_id를 참조하는 술어를 통해 최적화 단계에서 파티션 프루닝이 수행된다. 그리하여 Plan Tree의 스캔 대상은 술어 조건에 부합되는 Part_1, Part_2, Part_3만이 남게 된다. PCRD는 Partition-Coordinator 실행 노드로, 파티션드 테이블의 각각의 파티션에 대한 SCAN노드를 자식 노드로 가지는 노드이다. 리스트 파티션 프루닝 리스트 파티션 프루닝이 가능한 술어의 형태는 인덱스를 사용하여 검색이 가능한 조건과 형태가 동일하나, 등호(equality, =) 연산자만 가질 수 있다. 호스트 변수가 포함된 조건이거나, 조인 조건의 경우는 이에 해당되지 않는다. 이런 술어의 예는 다음과 같다. SQL 튜닝 311 I1 = 1 i1 in (4,5,6) i1 is NULL depart = ‘RND1’ Part_1 Employee(partition key : department) depart = ‘RND2’ Part_2 depart = ‘RND3’, ‘RND4’ Part_3 depart = ‘RND5’ Part_4 depart = DEFAULT Part_5 SELECT id FROM employee WHERE depart = ‘RND1’; PROJ SCAN(Part_1) PCRD(Sales) SELECT id FROM employee WHERE depart > ‘RND1’ AND depart < ‘RND4’; PROJ SCAN(Part_1) PCRD(Sales) SCAN(Part_2) SCAN(Part_3) SCAN(Part_4) SCAN(Part_5) SELECT id FROM employee WHERE depart IN ( ‘RND1’, ‘RND3’, ‘RND5’); PROJ SCAN(Part_1) PCRD(Sales) SCAN(Part_3) SCAN(Part_4) SELECT id FROM employee WHERE depart = ‘SUPPORT’; PROJ PCRD(Sales) SCAN(Part_5) [그림 11-6] 리스트 파티션 프루닝의 예 [그림 10-6]의 Employee 테이블은 부서명을 기준으로 총 5개의 파티션으로 분리된 파티션드 테이블이다. 최적화 단계에서 파티션 키인 depart를 참조하는 술어로 파티션 프루닝이 되어, 각각의 질의에 대한 실행계획 트리의 스캔 대상은 술어 조건에 부합되는 파티션이 된다. 해시 파티션 프루닝 해시 파티션 프루닝이 가능한 술어의 형태는 인덱스를 사용하여 검색이 가능한 조건과 형태가 동일하며, 등호 (equality, =)연산자만 가질 수 있다. 호스트 변수가 포함된 조건이거나, 조인 조건의 경우는 이에 해당되지 않는다. 이런 술어의 예는 다음과 같다. I1 = 1 i1 in (4,5,6) i1 is NULL 312 Administrator’s Manual Part_1 Employee(partition key : id) Part_2Part_4Part_3 0 4 12 1 5 9 13 3 15 19 10 18 SELECT department FROM employee WHERE id = 9; PROJ SCAN(Part_2) PCRD(Sales) SELECT department FROM employee WHERE id IN ( 1, 9, 12, 13); PROJ SCAN(Part_2) PCRD(Sales) SCAN(Part_1) SELECT department FROM employee WHERE id < 15; PROJ SCAN(Part_2) PCRD(Sales) SCAN(Part_1) SCAN(Part_3) SCAN(Part_4) [그림 11-7] 해시 파티션 프루닝의 예 위의 [그림 10-7]의 Employee 테이블은 id를 기준으로 총 4개의 파티션으로 분리된 파티션드 테이블이다. 최적화 단계에서 파티션 키인 id를 참조하는 술어를 통해 파티션 프루닝이 되어 각각의 질의에 대한 실행계획 트리의 스캔 대상은 술어 조건에 부합되는 파티션이 된다. 파티션 필터링 파티션 필터링이 가능한 술어의 형태는 파티션 프루닝이 가능한 술어의 형태와 동일하며, 실행중에 변하는 조인 조건 및 호스트 변수가 포함된 술어의 형태도 포함한다. 술어의 조건이 고정적이지 않은 형태의 예제는 다음과 같다. I1 = ? T1.i1 = T2.i1 I1 < ? SQL 튜닝 313 time_id sales_events 20060608 20060816 20060121 20060914 20060211 20060405 sales_per 25 10 5 7 40 50 time_id < 2006.04.01 Part_1 time_id < 2006.07.01 Part_2 time_id < 2006.10.01 Part_3 DEFAULT Part_4 Sales ( partition key : time_id) 20060101 20060102 ... 20060121 ... 20060331 20060401 20060102 ... 20060608 ... 20060731 20060801 ... 20060816 ... 20060931 ... 20060931 20061001 20061002 ... ... SCANPCRD JOIN 20060608 20060816 20060121 20060914 sales.time_id = sales_events.sales_per <= 30 [ Partition Filter ] sales_events.time_id = sales.time_id time_id 20060608 20060816 20060121 20060914 sales_per 25 10 5 7 sales.time_id = sales.time_id = sales.time_id = (1) (2) (3) (4) (1) (2) (3) (4) (1)(2)(3)(4) 파티션 필 링 (1) (2) (3) (4) sales_event를 scan한 결과 sales_event를 scan한 결과의 time_id가 조건에 들어감 SELECT SUM(SOLD_AMOUNT) FROM SALES_EVENTS, SALES WHERE SALES_EVENT.SALES_PER <= 30 AND SALES_EVENT.TIME_ID = SALES.TIME_ID; SCANSCANSCANSCAN [그림 11-8] 파티션 필터링의 예 [그림 10-8]은 실행시 파티션 필터링이 일어나는 과정을 나타낸다. 먼저 sales_event 테이블에서 조건에 맞는 레코드가 (1), (2), (3), (4) 순으로 한 건씩 찾아지고, 이 레코드의 time_id 칼럼이 가변 술어의 sales_events.time_id가 되어 술어 조건에 부합하는 파티션이 결정된다. (1)번 술어의 경우 2006.04.01 ~ 2006.06.29 범위를 갖는 파티션인 Part_2에 포함되기 때문에 파티션 필터링에 의해 Part_2에서만 조건에 맞는 레코드를 찾게 된다. 마찬가지로 (2), (3), (4)번 술어 역시 이와 동일한 방법으로 술어 조건에 부합하는 파티션을 찾아서 스캔한다. 이렇게 수행단계 중에 술어 조건에 맞는 파티션을 찾아서 스캔하는 기법을 파티션 필터링이라 한다. 프로젝션의 최적화 프로젝션은 전체 칼럼으로 구성된 데이터로부터 SELECT 구문에 314 Administrator’s Manual 기술된 일부 칼럼 및 연산 결과를 추출하는 과정이다. 연산 순서의 고려 다음과 같이 항상 일정한 결과를 내는 연산은 한 번만 수행되고 다음 수행 시에는 이전의 결과가 사용된다. SELECT 1 + 1 FROM T1; 알티베이스는 사칙 연산과 같은 연산을 처리함에 있어 post-fix calculation 기법을 사용하는데, 이는 연산 순서를 어떻게 기술하느냐에 따라 성능에 영향을 줄 수 있다. 예를 들어 다음의 두 질의는 동일한 결과를 얻는다. 질의 1: SELECT i1 * 2 * 3 FROM T1; 질의 2: SELECT i1 * (2 * 3) FROM T1; 질의 1의 경우, [i1 * 2] * 3 과 같은 연산 순서로 처리되어 i1 값이 변함에 따라 매번 (* 2) 와 (* 3) 연산이 수행되어야 하지만, 질의 2는 (2 * 3) 의 결과인 6을 생성하고 i1의 값의 변화에 따라 (i1 * 6)의 연산만 수행된다. 즉, 연산 순서를 어떻게 제어하느냐에 따라 성능 차이가 발생할 수 있다. 이는 SELECT 구문뿐 아니라 WHERE절 등의 모든 영역에서 영향을 받는다. 질의 1: WHERE i1 + 3 > 100; 질의 2: WHERE i1 > 100 - 3; 즉, 위의 질의에서 질의 2가 보다 나은 성능을 기대할 수 있다. 그러나, 이러한 수식의 변경 시에는 다음과 같은 점을 고려하여야 한다. 칼럼 i1 이 INTEGER임을 가정할 때 다음의 질의 1은 질의 3과 같이 기술하는 것이 더 효율적이다. 질의 1: WHERE i1 * 3 > 100; 질의 2: WHERE i1 > 100 / 3; 질의 3: WHERE i1 > 33; 질의 2와 같이 변경할 경우 100/3 은 실수형 값이 되어 칼럼 i1에 대한 인덱스 사용이 불가능해진다. 그러나, 질의 3과 같이 변경할 경우 수학적 동치는 아니지만 i1이 INTEGER이므로 동일한 결과를 얻을 수 있으며 인덱스도 사용된다. 이와 같이 연산 순서와 데이터 타입을 잘 고려할 경우 동일한 질의 결과를 얻으면서 성능 향상을 기대할 수 있다. 프로젝션에 대한 최적화는 대부분 subquery내에 존재하는 SELECT 구문에 대한 최적화이며 이는 다음 절의 “SUBQUERY의 최적화”를 통해 자세히 설명한다. SQL 튜닝 315 SUBQUERY의 최적화 subquery는 조인과 더불어 성능에 아주 큰 영향을 미치는 구문이다. 무엇보다 중요한 것은 subquery의 사용을 최소화 하고, 더 나아가 불필요한 subquery를 적게 사용하는 것이다. 예를 들어 다음과 같은 질의를 살펴 보자. SELECT * FROM T1 WHERE (T1. i1 = 1 AND T1.i2 IN ( SELECT a2 FROM T2 WHERE T2.a1 = T1.i1 ) ) OR (T1. i1 = 2 AND T1.i2 IN ( SELECT a2 FROM T2 WHERE T2.a1 = T1.i1 ) ); SELECT * FROM T1 WHERE T1. i1 IN (1, 2) AND T1.i2 IN ( SELECT a2 FROM T2 WHERE T2.a1 = T1.i1 ) ); 위의 두 질의는 수학적으로 동일한 질의이며, 위와 같이 불필요한 subquery의 개수를 줄이는 것이 중요하다. Optimizer 는 subquery에 대하여 매우 다양한 최적화 기법을 적용하며, 최저 비용과 수학적 동치가 보장될 때 해당 최적화 기법을 적용한다. Optimizer가 적용하는 최적화 기법을 이해하고 있다면 적절한 질의 변형을 통하여 질의 성능을 대폭 향상시킬 수 있다. Optimizer 는 subquery의 실행 방법을 결정할 때 다음과 같은 최적화 기법들의 적용 가능 여부 및 비용 평가를 통해 해당 기법의 적용 여부를 결정한다. EXISTS, UNIQUE 절의 subquery에서 SELECT 칼럼 제거 Eliminate Quantified Predicates NJ Transformation Subquery의 불변 영역 (Invariant Area) Store And Search Subquery Key Range Subquery 유형 Optimizer의 subquery 최적화 기법을 설명하기 전에 subquery의 유형에 대하여 살펴보자. subquery의 유형에 따라 적용될 수 있는 최적화 기법이 다르므로 이를 이해하는 것은 매우 중요하다. subquery는 외부 칼럼의 참조 여부와 그룹 연산의 존재 여부에 316 Administrator’s Manual 따라 다음과 같이 4가지로 분류된다. 여기서 그룹 연산이란 GROUP BY, HAVING, aggregation 연산 중 하나라도 포함된 것을 의미한다. 외부 칼럼 비참조 외부 칼럼 참조 그룹 연산 비존재 Type N (No) Type J (Join) 그룹 연산 존재 Type A (Aggregation) Type JA (Join + Aggregation) [표 11-13] 서브쿼리의 유형 Type N: 다음 예와 같이 외부 칼럼이 존재하지 않고 그룹 연산도 존재하지 않는 경우이다. SELECT * FROM T1 WHERE T1.i1 IN ( SELECT T2.a1 FROM T2 ); Type J: 다음 예와 같이 외부 칼럼을 참조하지만 그룹 연산은 없는 경우이다. SELECT * FROM T1 WHERE EXISTS ( SELECT * FROM T2.a1 = T1.i1 ); Type A: 다음 예와 같이 외부 칼럼을 참조하지는 않지만 그룹 연산이 있는 경우이다. SELECT * FROM T1 WHERE i1 > ( SELECT SUM(a1) FROM T2 ); Type AJ: 다음 예와 같이 외부 칼럼을 참조하고 그룹 연산이 존재하는 경우이다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a2 = T1.i2 GROUP BY a1 HAVING SUM(a2) > 0 ); Type N과 type A의 경우 외부 칼럼을 참조하지 않아 항상 동일한 결과를 생성하는 반면, type J와 type JA는 외부 칼럼을 참조하므로 외부 칼럼의 변경에 따라 항상 다시 실행되어야 한다. 즉, subquery에 외부 칼럼을 사용하지 않고 질의를 작성할 수 있다면 보다 나은 성능을 기대할 수 있다. 위와 같이 subquery의 유형에 따라 관련 최적화 기법의 적용 가능 여부가 결정된다. EXISTS, UNIQUE 절의 subquery에서 SELECT 칼럼 제거 EXISTS, UNIQUE 절의 subquery에서는 많은 경우 SELECT 절에 기술된 칼럼이 의미가 없다. SQL 튜닝 317 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 Quantified Predicates subquery에 ANY, ALL과 같은 quantified predicate와 부등호 연산자가 함께 사용될 경우 다음과 같이 quantified predicate를 제거할 수 있다. 위와 같은 최적화 기법을 eliminate quantified predicate 기법이라 한다. SELECT * FROM T1 WHERE i1 >=ANY ( SELECT a1 FROM T2 ); => SELECT * FROM T1 WHERE i1 >= ( SELECT MIN(a1) FROM T2 ); SELECT * FROM T1 WHERE i1 >ALL ( SELECT a1 FROM T2 ); => SELECT * FROM T1 WHERE i1 > ( SELECT MAX(a1) FROM T2 ); 위와 같은 최적화 기법은 MIN 또는 MAX등의 하나의 값에 대해서만 검사하기 때문에 전체 레코드를 비교하는 것보다 많은 성능 향상을 기대할 수 있다. 또한, 이와 같은 질의 변경은 앞에서 318 Administrator’s Manual 언급한 정렬 순서를 이용한 MIN/MAX 최적화 등에 의하여 인덱스를 사용하는 것이 가능해져 성능을 향상시킬 수 있다. 그러나, 이러한 질의 변경도 T2테이블에 레코드가 존재하지 않는 경우에는 그 결과가 다를 수 있어, optimizer가 반드시 동일한 방식으로 질의를 변경하지는 않는다. 이는 type A, type J 에 대해서만 가능하다. optimizer는 비용 비교를 통해 해당 최적화 기법의 적용 여부를 결정하게 된다. 따라서, 사용자가 위와 같은 최적화 기법을 이해하고 해당 질의로 동일한 결과를 얻을 수 있음이 보장된다면, optimizer에 그 판단을 맡기지 않고 명시적으로 질의를 변경하는 것도 좋은 방법이다. NJ Transformation NJ Transformation 기법은 type N 또는 type J의 subquery를 type J형으로 변경시키는 방법이다. 다음 예를 통해 해당 기법을 살펴보자. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 ); SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a1 = T1.i1 ); 위의 예에서, 원 질의는 type N 형의 subquery로 외부 칼럼을 참조하지 않고 있으나, NJ Transformation 기법에 의하여 외부 칼럼을 참조하도록 질의를 변경한 것이다. 다음 예제는 type J 형의 subquery를 어떻게 변경하는지 보여준다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a2 = 1 ); SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a1 = 1 AND T2.a1 = T1.i1 ); 이러한 최적화 기법은 T2.a1 칼럼의 인덱스를 사용하여 성능을 향상시키려 하는 방법이다. 해당 최적화 기법은 T2.a1 칼럼과 T1.i1 칼럼의 데이터가 NULL이 아님이 보장될 때 동일한 결과를 생성할 수 있기 때문에, optimizer는 이러한 제약 조건과 함께 비용 평가를 통해 해당 기법의 적용 여부를 결정한다. 일반적으로 해당 최적화 기법은 외부 질의의 데이터보다 subquery내의 데이터가 많은 경우에 효율적인 기법이다. 사용자는 위와 같은 질의 변경이 동일한 결과를 보장할 수 있음을 확신할 SQL 튜닝 319 경우 명시적으로 질의를 변경하여 성능 향상을 기대할 수 있다. 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는 비용 평가와 최적화 기법의 적용 가능 여부를 판단하여 이 기법을 사용할 것인지를 결정한다. 320 Administrator’s Manual Subquery Key Range Store and search 최적화 기법을 적용할 수 있는 환경에서 i1 칼럼에 인덱스가 존재할 경우에는 그 인덱스가 사용될 수 있다. 이를 subquery key range 최적화 기법이라 한다. SELECT * FROM T1 WHERE i1 IN ( SELECT SUM(a2) FROM T2 GROUP BY a1 ); subquery key range 최적화 기법이 반드시 효율적인 것은 아니며, Type N의 경우 다음과 같은 점을 고려해야 한다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 ); T1.i1 칼럼의 인덱스를 사용하는 경우와 앞에서 설명한 NJ transformation 기법을 사용하여 T2.a1 칼럼의 인덱스를 사용하는 것은 데이터 구성에 따라 서로 다른 성능을 낼 수 있다. 일반적으로 외부 질의의 데이터가 많은 경우는 subquery key range를 사용하는 것이 효율적이며, subquery의 데이터가 많은 경우는 NJ transformation 기법을 사용하는 것이 효율적이다. 즉, 많은 데이터를 가진 질의 영역에 인덱스를 사용하는 것이 보다 효율적일 가능성이 높다. 일반적으로 optimizer가 비용 계산에 의하여 이를 선택하지만, 사용자가 명시적으로 질의를 변경하여 성능을 향상시킬 수도 있다. 다음 질의를 사용자가 원하는 최적화 기법이 적용되도록 변경할 수 있다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 ); Subquery Key Range 최적화 기법을 적용하고 싶은 경우, 아래처럼 변경하면 된다. SELECT * FROM T1 WHERE i1 IN ( SELECT DISTINCT a1 FROM T2 ); NJ Transformation 최적화 기법을 적용하고 싶은 경우, 아래처럼 변경하면 된다. SELECT * FROM T1 WHERE i1 IN ( SELECT a1 FROM T2 WHERE T2.a1 = T1.i1 ); 이러한 질의 변경이 optimizer가 해당 최적화 기법의 사용을 SQL 튜닝 321 결정하는데 도움을 줄 수는 있으나 반드시 적용되는 것은 아니다. 또한, 질의 변경 시 반드시 동일한 결과를 보장할 수 있음을 확신하는 것이 중요하다. 조인 질의로 변경 IN또는 EXISTS 등의 subquery는 특정 상황에서 조인으로 변경할 수 있으므로 질의 변경을 통한 성능 향상이 가능하다. 그러나, 조인으로의 질의 변경으로 반드시 성능이 향상되거나, 동일한 결과가 보장되는 것이 아니므로 주의해야 한다. 예를 들어, 다음의 IN subquery 질의는 T2.a1이 UNIQUE한 경우에 한해 아래와 같이 조인 형태로 변경이 가능하다. SELECT * FROM T1 WHERE T1.i1 IN ( SELECT T2.a1 FROM T2 ); SELECT T1.* FROM T1, T2 WHERE T1.i1 = T2.a1; 마찬가지로 아래의 EXISTS subquery도 T2.a1 이 UNIQUE한 경우에 한해 아래와 같이 조인 형태로 변경이 가능하다. SELECT * FROM T1 WHERE EXISTS ( SELECT * FROM T2 WHERE T2.a1 = T1.i1 ); SELECT T1.* FROM T1, T2 WHERE T1.i1 = T2.a1; 지금까지 최적화 과정과 질의 튜닝 방법을 살펴보았다. 질의에 어떤 최적화 기법들이 적용되었는지는 앞으로 설명할 실행 계획 분석 단계의 내용을 통해 판단할 수 있다. 322 Administrator’s Manual 실행 계획 분석 SQL 구문 튜닝을 위해서는 1차적으로 실행 계획(execution plan)을 분석하는 것이 필수적이다. 여기서는 실행 계획 트리 정보를 추출하고 이를 해석하는 방법과 실행 계획 트리를 구성하는 각 실행 노드들의 정보를 분석하는 방법을 설명한다. 분석 방법 실행 계획 분석을 위한 SQL 구문 실행 계획 트리는 iSQL을 통해서만 볼 수 있다. 실행 계획 트리는 SELECT 구문에 대해서만 제공된다. 이를 얻기 위해서는 SELECT 구문의 수행 전에 iSQL에서 다음 명령을 수행하여야 한다. ALTER SESSION SET EXPLAIN PLAN = option; option 에는 ON, OFF, 또는 ONLY 가 올 수 있다. 기본 설정값은 OFF이다. ON: SELECT 문 실행 후 결과 레코드와 함께 Execution Plan 정보를 보여준다. ONLY: SELECT 문에 대해 Prepare 과정만 수행한 후 실제 Execution 과정을 수행하지 않고 단지 실행 계획 정보만 보여준다. 주 언어 변수 바인딩이 존재하는 SELECT 문 또는 실행 수행 시간이 오래 걸리는 질의에 대해 단순히 실행 계획만 확인려면 이 기능을 사용하도록 한다. OFF: SELECT문 실행 후 Execution Plan 정보는 보여주지 않고 결과 레코드만 보여준다. 사용자가 기술한 WHERE절에 존재하는 조건들의 처리 방법에 대한 정보 등, 보다 자세한 정보가 필요한 경우는 다음 명령을 사용한다. ALTER SYSTEM SET TRCLOG_DETAIL_PREDICATE = 1; 위의 구문처럼 해당 프로퍼티에 1을 설정하여 ON시키면, 실행 계획 정보에 WHERE절의 조건들이 FIXED KEY RANGE, VARIABLE KEY RANGE, 또는 FILTER 등으로 자세하게 분류되어 표시된다. 따라서 사용자는 WHERE절을 복잡하게 사용한 경우 어떤 술어들이 인덱스 스캔을 통해 수행되는지 확인할 수 있다. 단, 특정 최적화 기법에 의해 질의가 변경된 경우는 이러한 정보가 출력되지 않을 수 있다. 다음은 쿼리 문의 실행 결과 출력 예이다. SQL 튜닝 323 iSQL> alter system set trclog_detail_predicate = 1; Alter success. iSQL> alter session set explain plan = on; Alter success. iSQL> select * from t1 where i1 = 1; T1.I1 -------------- 1 1 row selected. [TRCLOG_DETAIL_PREDICATE = 1 이고 EXPLAIN PLAN = ON인 경우] PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) [ FIXED KEY ] OR I1 = 1 [TRCLOG_DETAIL_PREDICATE = 0 이고 EXPLAIN PLAN = ON인 경우] PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) [TRCLOG_DETAIL_PREDICATE = 0 이고 EXPLAIN PLAN = ONLY인 경우] PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: ??, SELF_ID: 2 ) EXPLAN PLAN = ONLY인 경우 질의 실행 없이 실행 계획만 생성하므로 ACCESS 항목과 같이 실제 실행 후 그 값이 결정되는 항목들은 물음표(“??”)로 표시된다. 실행 계획 트리의 해석 여기에서는 실행 계획을 해석하는 방법을 예제를 들어 간략히 설명한다. 각 실행 노드들이 트리 형태로 연결된 전체 실행 계획 트리를 따라가면서 실행 순서가 결정된다. 324 Administrator’s Manual SELECT * FROM T1, T2, T3 WHERE T1.I1 = T2.I1 AND T2.I1 = T3.I1 질의의 실행 이 다음과 같은 경우 [EXECUTION PLAN] 6--------- PROJECT ( COLUMN_COUNT: 9, TUPLE_SIZE: 36 ) 5--------- JOIN ( REF_ID: 3 ) 3--------- JOIN ( REF_ID: 2 ) 1--------- SCAN ( TABLE: T1, FULL SCAN, ACCESS: 8, SELF_ID: 1 ) 2--------- SCAN ( TABLE: T2, INDEX: IDX2, ACCESS: 104, SELF_ID: 2 ) 4--------- SCAN ( TABLE: T3, INDEX: IDX3, ACCESS: 1144, SELF_ID: 3 ) 최상위 노드 최하위 노드 실행 계획 트리에서 하나의 노드는 한 행에 표시된다. 왼쪽으로 들여쓰기가 많이 되어 있는 노드일수록 하위 노드이며 가장 먼저 수행된다. 위 예제에서 가장 최상위 노드는 PROJ 노드이며 최하위 노드는 테이블 T1의 SCAN 노드와 테이블 T2의 SCAN 노드이다. T1 SCAN 노드와 T2 SCAN 노드와 같이 같은 크기만큼 들여쓰기가 되어 있는 노드들의 경우 먼저 나타나는 노드가 상위 노드의 왼쪽 노드에 해당한다. 레코드 fetch 요구는 TOP-DOWN으로 이루어지고 처리된 레코드는 BOTTOM-UP 방식으로 반환된다. 위의 예제에서 가장 먼저 데이터베이스에 접근하는 노드는 T1 SCAN 노드이고, 그 다음 T2 SCAN 노드, T3 SCAN 노드의 순서로 수행된다. 노드 옆에 명시한 숫자가 노드 수행 순서이다. 위의 예제에서 나타난 실행 계획을 트리 형태로 나타내면 다음 그림과 같다. SCAN T3 JOIN PROJ SCAN T1 SCAN T2 JOIN T1, T2 2 6 3 5 4 1 레코드 이동 경로 레코드 패치 구 경로 [그림 11-9] 레코드 요구와 패치(fetch) 경로 SQL 튜닝 325 실행 노드의 종류 실행 계획 트리는 다양한 실행 노드들로 구성된다. 실행 노드는 물리 연산자(physical operator)라고도 한다. 실행 노드는 질의를 직접 수행하는 연산자들로 앞에서 설명한 바와 같이 실행 계획 트리를 통해 연산이 수행되는 흐름을 확인할 수 있다. 실행 노드는 자식 노드의 개수와 중간 결과의 저장 여부에 따라 다음과 같이 구분된다. 단일 비저장 노드(Unary Non-materialization Node): 하나 이하의 자식 노드를 가지며, 중간 결과를 저장하지 않음 단일 저장 노드(Unary Materialization Node) : 하나 이하의 자식 노드를 가지며, 중간 결과를 저장함 이진 비저장 노드(Binary Non-materialization Node) : 두 개의 자식 노드를 가지며, 중간 결과를 저장하지 않음 이진 저장 노드(Binary Materialization Node) : 두 개의 자식 노드를 가지며, 중간 결과를 저장함 다중 비저장 노드(Multiple Non-materialization Node) : 하나 이상의 자식 노드를 가지며, 중간 결과를 저장하지 않음 이러한 구분에 따라 알티베이스에는 다음과 같이 26가지의 물리 연산자가 존재한다. 각 실행 노드의 약자는 이후의 실행 계획 트리에 대한 설명시에 사용된다. 구분 약자 출력 이름 기능 단일 비저장 노드 SCAN SCAN 다양한 액세스 방법을 사용해서 테 이블에서 데이터 검색 FILT FILTER 액세스 방법으로 filtering 되지 않 는 데이터의 filtering 처리 PROJ PROJECT 프로젝션 처리 GRBY GROUPING 그룹 처리 AGGR AGGREGATION Aggregation 연산 수행 VIEW VIEW 뷰 레코드 구성 VSCN VIEW-SCAN 임시 저장 뷰에 대한 검색 COUNT COUNT 특수 COUNT(*)의 처리 HIER HIER 계층 질의의 처리 단일 저장 노드 SORT SORT 레코드의 정렬 HASH HASH 레코드의 해싱 GRAG GROUP- AGGREGATION 해싱 방식에 의한 그룹 구분과 aggregation 연산 수행 HSDS DISTINCT 해싱 방식에 의한 중복 제거 VMTR MATERIALIZATION 임시 저장 뷰의 관리 STOR STORE 레코드의 저장 326 Administrator’s Manual LMST LIMIT-SORT LIMIT 절을 위한 정렬 이진 비저장 노드 JOIN JOIN 조인 처리 MGJN MERGE-JOIN 머지 조인 처리 LOJN LEFT-OUTER- JOIN LEFT OUTER 조인 처리 FOJN FULL-OUTER- JOIN FULL OUTER 조인 처리 AOJN ANTI-OUTER- JOIN ANTI OUTER 조인 처리 CONC CONCATENATION 자식 노드의 결과 조합 BUNI BAG-UNION BAG UNION의 처리 이진 저장 노드 SITS SET-INTERSECT SET INTERSECT 집합 연산 수행 SDIF SET-DIFFERENCE SET DIFFERENCE 집합 연산 수행 다중 비저장 노드 PCRD PARTITION- COORDINATIOR 파티션드 테이블의 각 파티션에 대 한 스캔을 관리하는 노드 [표 11-14] 실행 노드의 종류 저장 노드의 특징 저장 노드(Materialization node)는 관련 연산을 수행하기 위하여 중간 결과를 저장하는 노드이다. 중간 결과는 임시 테이블에 저장되는데, 이는 저장 매체의 종류에 따라 메모리 임시 테이블 또는 디스크 임시 테이블이 될 수 있다. 메모리 임시 테이블은 시스템 커널로부터 직접 할당 받은 메모리 영역에 저장되는데, 이는 질의 수행 후에 바로 제거된다. 디스크 임시 테이블은 사용자에 의해 지정된 임시 테이블스페이스 영역에 저장되며, 이 데이터는 메모리 버퍼를 이용하여 관리된다. 이 또한 질의 수행 후에 바로 제거된다. 메모리 임시 테이블 또는 디스크 임시 테이블을 사용하게 되는 기준은 다음과 같다. 저장 노드의 하위 자식 노드들이 모두 메모리 테이블만을 사용하는 경우라면 메모리 임시 테이블이 사용된다. 디스크 테이블이 하나 이상 포함되어 있는 경우에는 디스크 임시 테이블이 사용된다. 이러한 기준은 힌트를 이용하여 변경할 수 있다. 다음 예와 같이 메모리 테이블 또는 디스크 테이블이 사용되는지에 따라서 정렬이 다르게 다뤄지는 것을 실행 계획에서 확인할 수 있다. 아래의 질의의 실행 계획은 메모리 테이블에 대하여 중복 제거 및 정렬을 위하여 중간 결과를 저장하는 두 개의 저장 노드를 가지고 있다. 메모리 임시 테이블이 사용되는 경우 디스크 페이지에 대한 정보를 별도로 갖지 않는다. SQL 튜닝 327 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에 해당하는 실행 노드의 레코드가 변경될 경우 임시 저장 테이블이 재구성된다. 위의 예에서는 모두 자식 노드들을 참조하고 있어 별도의 재구성이 발생하지 않는 것을 알 수 있다. 단일 비저장 노드 328 Administrator’s Manual 단일 비저장 노드는 하나 이하의 자식 노드를 가지며, 해당 기능을 수행하기 위해 별도의 저장 공간을 필요로 하지 않고 하나의 레코드만을 관리하는 노드이다. 위와 같은 특징을 갖는 각 실행 노드의 기능과 실행 계획내에서 이를 분석하는 방법에 대하여 살펴본다. SCAN 노드 SCAN 노드는 관계형 모델에서 검색(select)연산을 수행하는 물리적인 개체이다. SCAN 노드는 자식 노드를 갖지 않으며 테이블에 직접 접근하여 해당 테이블에서 레코드를 가져온다. SCAN 노드에서 검사되는 조건은 다음과 같이 5가지의 처리 방법으로 처리된다. Fixed key range Variable key range Constant filter Filter Subquery filter EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 SCAN 노드의 정보는 다음과 같다. 구분 설명 비고 SCAN 실행 노드의 이름 TABLE 접근하는 테이블의 이 름 ACCESS 실제 접근한 레코드의 개수 DISK_PAGE_COUNT 테이블의 디스크 페이 지 개수 메모리 테이블은 해당 정보가 없음 SELF_ID 실행 노드의 ID [표 11-15] SCAN 노드의 정보 메모리 테이블과 디스크 테이블 메모리 테이블과 디스크 테이블은 서로 출력되는 정보가 약간 다르다. 디스크 테이블의 경우에만 해당 테이블이 소유한 디스크 페이지 개수가 출력된다. 아래는 메모리 테이블과 디스크 테이블의 SCAN 노드의 출력 정보를 비교한 것이다. 다음 예는 SYS 사용자의 기본 테이블스페이스가 SYS_TBS_MEMORY로 지정되어 있는 경우이며, 메모리 테이블의 SQL 튜닝 329 SCAN 노드 정보를 보이고 있다. 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 sucess. iSQL> select * from d1; D1.I1 -------------- No rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: D1, FUL SCAN, ACCESS: 0, DISK_PAGE_COUNT: 2, SELF_ID: 0 ) ------------------------------------------------------------ 테이블 이름 아래의 예에서와 같이 SCAN 노드가 접근하고 있는 테이블의 이름을 보여주며, 질의에 alias 이름을 지정할 경우 다음과 같이 출력된다. iSQL> select * from t1 v1; V1.I1 -------------- No rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1 V1, FULL SCAN, ACCESS: 0, SELF_ID: 0 ) ------------------------------------------------------------ 액세스 방법 및 레코드 액세스 횟수 질의 튜닝에 있어 가장 중요한 정보는 전체 스캔을 하는 지 인덱스를 사용하는 지의 여부와 얼마나 많은 레코드 접근이 이루어졌는 지를 판단하는 것이다. 레코드 접근이 많을수록 성능 저하의 요인이 되므로 이에 대한 판단을 하는 것이 매우 중요하다. 330 Administrator’s Manual 다음은 전체 스캔에 의하여 해당 질의를 처리한 경우이다. WHERE절을 비교하기 위하여 레코드에 접근한 수를 보이고 있다. 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 튜닝 331 iSQL> create index idx2 on t1(i2); Create success. iSQL> select /*+ INDEX(T1, idx2) */* from t1 where i1 = 1000 and i2 = 0; T1.I1 T1.I2 --------------------------- 10 0 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, INDEX: IDX2,ACCESS: 163, SELF_ID: 2 ) ------------------------------------------------------------ 아래와 같이 별도의 힌트를 주지 않을 경우, optimizer는 비용 비교를 통해 보다 우수한 인덱스를 선택하게 된다. iSQL> select * from t1 where i1 = 1000 and i2 = 0; T1.I1 T1.I2 --------------------------- 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 프로퍼티를 1로 지정하면 SCAN노드에서 조건들이 어떠한 방식으로 처리되는지에 대한 정보를 출력한다. 이 프로퍼티는 해당 조건이 인덱스를 사용하고 있는 지를 판단하는 데 있어 유용하게 사용될 수 있다. 다음과 같이 각 조건을 처리하기 위해 어떠한 방법을 사용하고 있는지를 알 수 있다. 즉, 아래의 예에서는 (i1 = 1000) 조건은 인덱스를 사용한 fixed key range로 처리되고, (i2 = 0) 조건은 filter로 처리됨을 알 수 있다. 332 Administrator’s Manual iSQL> alter system set trclog_detail_predicate = 1; Alter success. iSQL> alter session set explain plan = on; Alter success. iSQL> select * from t1 where i1 = 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 노드는 관계형 모델에서 검색(select)연산을 수행하는 물리적 개체이다. 하나의 자식 노드를 가지며 테이블에 직접 접근하지 않고 관련 조건을 검사한다. SQL 튜닝 333 EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 FILT 노드의 정보는 다음과 같다 구분 설명 비고 FILTER 실행 노드의 이름 FILT 노드는 노드 이름 외에 별도의 정보를 포함하지 않는다. Filter에 의해 처리되는 조건 정보를 출력하기 위해서는 TRCLOG_DETAIL_PREDICATE 프로퍼티를 설정한다. FILT 노드 정보의 출력 다음 예를 보면 FILT 노드는 이름만을 출력할 뿐 별도의 다른 정보를 출력하지 않는다. 이 예에서 FILT 노드는 (having i2 < 2) 조건을 처리하기 위하여 사용되었다. iSQL> select sum(i1) from t1 group by i2 having i2 < 2; SUM(I1) ----------------------- 1336600 1336764 2 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) FILTER AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 100 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX2, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ 이러한 정보를 확인하려면 TRCLOG_DETAIL_PREDICATE 프로퍼티를 1로 설정함으로써 가능하다. 아래와 같이 FILT 노드가 (i2 < 2) 조건을 처리하기 위하여 사용되었음을 확인할 수 있다. 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 ) ------------------------------------------------------------ 334 Administrator’s Manual PROJ 노드 PROJ 노드는 관계형 모델에서 프로젝션(project)연산을 수행하는 물리적 개체이다. 하나의 자식 노드를 가지며 자식 노드의 결과 레코드로부터 필요한 칼럼만을 추출한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 PROJ 노드의 정보는 다음과 같다. 구분 설명 비고 PROJECT 실행 노드의 이름 COLUMN_COUNT 프로젝션되는 칼럼의 개수 TUPLE_SIZE 프로젝션으로 추출하는 레코드 의 크기 [표 11-16] PROJ 노드의 정보 PROJ 노드의 출력 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의 처리 SQL 튜닝 335 EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 GRBY 노드의 정보는 다음과 같다. 구분 설명 비고 GROUPING 실행 노드의 이름 [표 11-17] GRBY 노드의 정보 GRBY 실행 노드는 이름 외에 별도의 정보를 표시하지 않는다. 정렬 순서를 이용한 그룹화 GRBY 노드가 정렬 순서를 이용한 동일한 그룹 여부를 판단하기 위해서 사용되는 경우 다음과 같은 형태로 실행 계획이 출력된다. 아래의 예를 보면 GRBY 노드가 (GROUP BY I3) 절을 처리하기 위해서 사용되었으며, GROUP BY를 처리하기 위하여 별도의 저장 공간을 사용하지 않고 처리되었음을 알 수 있다. 이는 앞서 최적화 과정의 정렬 순서를 이용한 GROUP BY의 처리를 통해 설명하였다. iSQL> select sum(i1) from t1group by i3; SUM(I1) ----------------------- 26838630 26841907 26845184 26848461 26851738 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ 정렬 순서를 이용한 중복 제거 GRBY 노드가 정렬 순서를 이용한 중복 제거를 위해서 사용되는 경우 다음과 같은 형태로 실행 계획이 출력된다. 아래의 실행 계획에서 GRBY 노드는 (DISTINCT i3) 절을 처리하기 위해 사용되었으며, DISTINCT를 위해 별도의 저장 공간을 사용하지 않았음을 알 수 있다. 이는 앞서 최적화 과정에서 정렬 순서를 이용한 DISTINCT 최적화에서 설명하였다. 336 Administrator’s Manual iSQL> select distinct i3from t1; I3 -------------- 0 1 2 3 4 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 0 ) ------------------------------------------------------------ 정렬 순서를 이용한 DISTINCT aggregation 처리 GRBY 노드가 정렬 순서를 이용한 DISTINCT aggregation을 처리하기 위해서 사용되는 경우 다음과 같은 형태로 실행 계획이 출력된다. 아래의 예를 살펴보면 (COUNT(DISTINCT i2) )를 처리하는 과정에서 (DISTINCT i2) 절의 중복 제거를 위해서 GRBY 노드가 사용되었다. 이는 앞서 최적화 과정에서 정렬 순서를 이용한 DISTINCT aggregation 최적화에서 설명하였다. 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 수행 SQL 튜닝 337 EXPLAIN PLAN을 ON (또는 ONLY)로 설정하여 표시되는 AGGR 노드의 정보는 다음과 같다. 구분 설명 비고 AGGREGATION 실행 노드의 이름 ITEM_SIZE 하나의 그룹을 위한 레코드 크기 GROUP_COUNT 실행 노드에 의해 생성된 그룹의 개수 [표 11-18] AGGR 노드의 정보 정렬 순서를 이용한 aggregation 수행 AGGR 노드가 정렬 순서를 이용한 aggregation 수행을 위해 사용될 경우 다음 예와 같은 실행 계획 정보가 출력된다. 아래의 예를 살펴 보면, GRBY 실행 노드가 구분한 정보를 이용하여 AGGR노드는 SUM(i2)를 수행한다. 이 때 구성되는 레코드는 SUM(i2)와 GROUP BY i3를 사용해서 그룹화된다. 아래 예에서는 16byte의 크기의 레코드를 포함하는 그룹이 다섯 개가 구성되었음을 알 수 있다. 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)를 처리하기 위해서 사용되었다. 338 Administrator’s Manual iSQL> select sum( distinct i2 ) from t1 group by i3; SUM( distinct I2 ) ----------------------- 950 970 990 1010 1030 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ VIEW 노드 VIEW 노드는 관계형 모델에서 가상 테이블을 표현하기 위해 사용되는 노드이다. 이 노드는 사용자가 정의한 뷰를 표현하거나 집합 연산을 통해 생성되는 결과 집합을 하나의 테이블 개념으로 전환하는 역할을 한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 VIEW 노드의 정보는 다음과 같다. 구분 설명 비고 VIEW 실행 노드의 이름 뷰 이름 뷰의 이름 이름이 있는 경우 ACCESS 뷰 레코드의 접근 회수 SELF_ID 노드의 ID [표 11-19] VIEW 노드의 정보 사용자가 정의한 뷰에 대한 질의가 수행될 경우 생성되는 VIEW 노드의 출력 예는 아래와 같다. VIEW 노드의 하위 노드들은 사용자가 정의한 뷰의 SELECT문에 대한 실행 계획을 의미한다. SQL 튜닝 339 iSQL> create view v1(a1, a2) as select i3, sum(i2) from t1 group by i3; Create success. iSQL> select * fromv1; V1.A1 V1.A2 ------------------------------------ 0 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 노드는 관계형 모델에서 임시 저장 뷰에 대한 검색(SELECT) 연산을 수행한다. 하나의 자식 노드를 가지면, 이는 항상 VMTR 실행 노드이다. 이 노드는 질의 최적화 과정에서 뷰의 결과를 저장 후 처리하는 것이 효율적이라 판단될 때 생성된다. 340 Administrator’s Manual EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 VSCN 노드의 정보는 다음과 같다. 구분 설명 비고 VSCN 실행 노드의 이름 VIEW 뷰의 이름 ACCESS 뷰 레코드의 접근 회수 SELF_ID 노드의 ID [표 11-20] VSCN 노드의 정보 VSCN 노드가 사용되는 예는 아래와 같다. 아래 질의에는 동일한 뷰에 대한 접근이 외부 질의와 부질의(subquery)에서 모두 등장한다. Optimizer는 최적화 과정에서 해당 뷰를 임시 저장하여 질의를 수행하는 것이 효율적이라고 판단해서, 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: 2 ) STORE ( ITEM_SIZE: 32, ITEM_COUNT: 1, ACCESS: 10, SELF_ID: 1, REF_ID: 4 ) VIEW ( ACCESS: 1, SELF_ID: 10 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 2 ) GROUP-AGGREGATION ( ITEM_SIZE: 64, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 9, REF_ID: 4 ) VIEW-SCAN ( VIEW: V1 Y, ACCESS: 5, SELF_ID: 4 ) MATERIALIZATION ( ITEM_SIZE: 24, ITEM_COUNT: 5 ) VIEW ( ACESS: 5, SELF_ID: 7 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) AGGREGATION ( ITEM_SIZE: 16, GROUP_COUNT: 5 ) GROUPING SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 16384, SELF_ID: 1 ) :SUB-QUERY END VIEW-SCAN ( VIEW: V1 X, ACCESS: 5, SELF_ID: 2 ) ------------------------------------------------------------ 위의 실행 계획에서 (V1 X) 뷰에 대한 VSCN 노드는 자식 노드를 갖지 않는 것으로 보인다. 그러나, 해당 VSCN 노드는 VMTR 노드(MATERIALIZATION으로 표시)를 자식 노드로 갖는다. 위 실행 계획의 일부를 도식화하면 아래 그림과 같다. SQL 튜닝 341 VSCN (V1 X) PROJ FILT PROJ ... VSCN (V1 Y) VMTR VIEW ... 위의 그림에서와 같이 VSCN(V1 X)와 VSCN(V1 Y) 실행 노드는 동일한 자식 노드를 갖고 있다. COUNT 노드 COUNT 노드는 관계형 모델에서 GROUP BY절이 존재하지 않는 COUNT(*) 연산을 특별히 처리하기 위한 실행 노드이다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 COUNT 노드의 정보는 다음과 같이 SCAN 실행 노드와 유사하다. 구분 설명 비고 COUNT 실행 노드의 이름 TABLE 접근하는 테이블의 이 름 ACCESS 실제 접근한 레코드의 개수 DISK_PAGE_COUNT 테이블의 디스크 페이 지 개수 메모리 테이블은 해당 정보가 없 음 SELF_ID 실행 노드의 ID [표 11-21] COUNT 노드의 정보 다음은 COUNT 노드가 사용된 예이다. 아래의 예를 살펴보면 인덱스를 사용함으로써 실제 데이터에는 접근하지 않고 COUNT(*) 값을 획득하고 있음을 알수 있다. 342 Administrator’s Manual iSQL> select count(*) from t1 where i1 > 1000; COUNT ----------------------- 15384 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) COUNT( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2, REF_ID: 2 ) ------------------------------------------------------------ HIER 노드 HIER 노드는 관계형 모델에 없는 특수한 연산으로 계층 질의를 수행하는 노드이다. 이 노드는 하나의 자식 노드를 가지며, 자식 노드는 항상 SCAN 노드이다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 HIER 노드의 정보는 다음과 같다. HIER 노드의 대부분의 정보는 SCAN 노드와 유사하다. 구분 설명 비고 HIER 실행 노드의 이름 TABLE 접근하는 테이블의 이름 ACCESS 실제 접근한 레코드의 개수 DISK_PAGE_COUNT 테이블의 디스크 페이지 개수 메모리 테이블 은 해당 정보가 없음 SELF_ID 실행 노드의 ID [표 11-22] HIER 노드의 정보 계층 질의 수행시 HIER 노드가 사용된 예는 다음과 같다. iSQL> select count(*) from t1 start with i3 = 0 connect by prior i3 = i1 ignore loop; COUNT ----------------------- 3276 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 2 ) HIER ( TABLE: T1, INDEX: IDX1, ACCESS: 3276, SELF_ID: 2 ) SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3276, SELF_ID: 2 ) ------------------------------------------------------------ SQL 튜닝 343 단일 저장 노드 단일 저장 노드는 하나 이하의 자식 노드를 가지며, 해당 기능을 수행하기 위해 별도의 저장 공간을 필요로 하는 노드이다. 위와 같은 특징을 갖는 각 실행 노드의 기능과, 실행 계획 내에서 이를 분석하는 방법에 대하여 살펴본다. SORT 실행 노드 SORT 노드는 관계형 모델에서 정렬 연산을 수행하는 물리적 개체이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 SORT 노드의 정보는 다음과 같다. 구분 설명 비고 SORT 실행 노드의 이름 ITEM_SIZE 정렬을 위한 레코드의 크기 ITEM_COUNT 정렬에 포함된 레코드의 개수 DISK_PAGE_COUNT 임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부를 결정하는데 사용 되는 노드의 ID [표 11-23] SORT 노드의 정보 SORT 노드는 매우 다양한 용도로 사용된다. 아래에서 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. ORDER BY절에서의 사용 ORDER BY 절이 존재하고 별도의 정렬이 필요한 경우 SORT 노드가 사용된다. 아래의 예에서 SORT 노드는 ORDER BY절을 처리하기 위하여 사용되었다. 344 Administrator’s Manual 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에서의 사용 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 노드가 생성된 경우이다. SQL 튜닝 345 iSQL> select DISTINCT i4from t1; I4 -------------- 0 1 2 3 4 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) GROUPING SORT( ITEM_SIZE: 16, ITEM_COUNT: 16384, ACCESS: 16384, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) ------------------------------------------------------------ 조인에서의 사용 SORT 노드는 조인을 수행하기 위하여 사용될 수 있다. 아래의 예는 조인을 처리하기 위하여 SORT 노드가 생성된 경우이다. T1.i1 = T2.i1 조인 조건을 검사하기 위한 sort-based 조인을 수행하기 위해 SORT 노드가 생성되었다. iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1; COUNT ----------------------- 16384 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 2 ) JOIN SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) SORT( ITEM_SIZE: 16, ITEM_COUNT: 16384, ACCESS: 16384, SELF_ID: 3, REF_ID: 2 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ HASH 노드 HASH 노드는 관계형 모델에서 해싱 연산을 수행하는 노드이다. 이 노드는 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 HASH 노드의 정보는 다음과 같다. 346 Administrator’s Manual 구분 설명 비고 HASH 실행 노드의 이름 ITEM_SIZE 해싱을 위한 레코드의 크 기 ITEM_COUNT 해싱에 포함된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개수 DISK_PAGE_COUNT 임시 저장 테이블을 구성 하는 디스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접 근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여 부를 결정하는데 사용되 는 노드의 ID [표 11-24] HASH 노드의 정보 HASH 노드는 매우 다양한 용도로 사용된다. 아래에서 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. 조인에서의 사용 HASH 노드는 조인을 수행하기 위하여 사용될 수 있다. 아래의 예는 조인을 처리하기 위하여 HASH 노드가 생성된 경우이다. T1.i1 = T2.i1 조인 조건을 검사하기 위하여 hash- based 조인이 수행되는데, 이를 위해 HASH 노드가 생성되었다. iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1; COUNT ----------------------- 16384 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 2 ) JOIN SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) HASH( ITEM_SIZE: 24, ITEM_COUNT: 16384, BUCKET_COUNT: 1024, ACCESS: 16384, SELF_ID: 3, REF_ID: 2 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ SQL 튜닝 347 Subquery 검색에서의 사용 HASH 노드는 subquery와의 비교 연산을 수행하기 위하여 사용될 수 있다. 아래의 예는 i4 in ( select i4 from t2 ) 를 처리하기 위하여 HASH 실행 노드가 사용된 경우이다. HASH 노드는 t2.i4 값을 해싱하여 저장하고 각 t1.i4 에 부합하는 값이 HASH에 존재하는 지를 검사한다. iSQL> select count(*) from t1 where i4 in ( select i4 from t2 ); COUNT ----------------------- 16384 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 1 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 16384, SELF_ID: 4, REF_ID: 2 ) VIEW ( ACCESS: 16384, SELF_ID: 3 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ::SUB-QUERY END ------------------------------------------------------------ GRAG 노드 GRAG 노드는 관계형 모델에서 해싱 방식의 그룹 및 aggregation 연산을 수행하는 노드이다. 이 노드는 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 GRAG 노드의 정보는 다음과 같다. 구분 설명 비고 GROUP- AGGREGATION 실행 노드의 이름 ITEM_SIZE 그룹 연산을을 위해 해 싱 되는 각 레코드의 크 기 GROUP_COUNT 그룹화된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개 수 348 Administrator’s Manual DISK_PAGE_COUNT 임시 저장 테이블을 구 성하는 디스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부를 결정하는데 사용 되는 노드의 ID [표 11-25] GRAG 노드의 정보 아래의 예는 해싱 방식의 그룹화와 aggregation 연산을 처리하기 위하여 GRAG 노드가 사용된 경우이다. GRAG 노드는 GROUP BY i4와 AVG(i1), SUM(i2)를 처리하기 위하여 사용되었다. iSQL> select avg(i1), sum(i2) from t1 group by i4; AVG(I1) SUM(I2) ------------------------------------ 8191 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을 ON(또는 ONLY)로 설정하여 표시되는 HSDS 노드의 정보는 다음과 같다. 구분 설명 비고 DISTINCT 실행 노드의 이름 ITEM_SIZE 중복 제거를 위한 레코 드의 크기 ITEM_COUNT 중복 제거된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개 수 SQL 튜닝 349 DISK_PAGE_COUNT 임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부를 결정하는데 사용 되는 노드의 ID [표 11-26] HSDS 노드의 정보 HSDS 실행 노드는 매우 다양한 용도로 사용된다. 아래에서 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. DISTINCT에서의 사용 HSDS 노드는 DISTINCT를 처리하기 위하여 사용될 수 있다. 아래의 예는 DISTINCT를 처리하기 위하여 HSDS 노드가 사용된 것을 보여준다. iSQL> select distinct i4 from t1; I4 -------------- 1 2 3 4 0 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) DISTINCT( ITEM_SIZE: 24, ITEM_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 5, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) ------------------------------------------------------------ UNION 에서의 사용 HSDS 노드는 UNION을 처리하기 위하여 사용될 수 있다. 아래의 예제에서는 UNION을 처리하기 위하여 HSDS 노드가 중복 제거를 위해 사용되었다. 350 Administrator’s Manual iSQL> select i3, i4 from t1 unionselect i3, i4 from t2; I3 I4 --------------------------- 1 1 2 2 3 3 4 4 0 0 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) DISTINCT ( ITEM_SIZE: 24, ITEM_COUNT: 5, BUCKET_COUNT: 16384, ACCESS: 5, SELF_ID: 4, REF_ID: 2 ) VIEW ( ACCESS: 32768, SELF_ID: 2 ) BAG-UNION PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ Subquery key range를 위한 사용 HSDS 노드는 subquery key range를 처리하기 위하여 사용될 수 있다. 중복 제거를 통해 동일한 값으로 인덱스를 이용한 검색이 발생하지 않도록 하기 위하여 사용된다. 아래의 예는 HSDS 실행 노드가 subquery key range을 처리하기 위하여 중복 제거를 위해 사용된 예이다. HSDS 실행 노드는 T2.i4 값의 중복 제거를 위해서 사용되었다. iSQL> select i1 from t1 where i1 in ( select i4 from t2 ); I1 -------------- 1 2 3 4 4 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 4, SELF_ID: 1 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) DISTINCT ( ITEM_SIZE: 24, ITEM_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 10, SELF_ID: 4, REF_ID: 2 ) VIEW ( ACCESS: 16384, SELF_ID: 3 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ::SUB-QUERY END ------------------------------------------------------------ VMTR 노드 SQL 튜닝 351 VMTR 노드는 뷰에 대한 임시 저장 테이블을 생성하는 노드이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 VMTR 노드의 정보는 다음과 같다. 구분 설명 비고 MATERIALIZATION 실행 노드의 이름 ITEM_SIZE 저장된 레코드의 크기 ITEM_COUNT 저장된 레코드의 개수 [표 11-27] VMTR 노드의 정보 VMTR 노드의 사용 예는 VSCN 노드의 사용 예를 참조한다. STOR 노드 STOR 노드는 질의의 일부 결과를 임시 저장하는 노드이다. 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 STOR 노드의 정보는 다음과 같다. 구분 설명 비고 STORE 실행 노드의 이름 ITEM_SIZE 저장 레코드의 크기 ITEM_COUNT 저장에 포함된 레코드의 개수 DISK_PAGE_COUNT 임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부를 결정하는 기준 노드 ID [표 11-28] STOR 노드의 정보 STOR 노드는 매우 다양한 용도로 사용된다. 아래에서 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. 조인에서의 사용 352 Administrator’s Manual STOR 노드는 조인에 사용될 수 있다. 이 노드는 조인 조건이 없는 카티션 프로덕트(cartesian product)에 주로 사용된다. 이 노드가 일반적인 조인에 사용되더라도 조인 조건을 자체적으로 처리하지는 않는다. 아래의 예는 STOR 노드가 카티션 프로덕트를 위하여 사용된 경우이다. T1 테이블에 대한 검색이 완료된 결과를 저장함으로서 반복적인 인덱스 사용을 방지하는 효과를 얻을 수 있다. iSQL> select count(*) from t1, t2where t1.i1 < 5 and t2.i3 = 1; COUNT ----------------------- 13108 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 2 ) JOIN SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) STORE ( ITEM_SIZE: 16, ITEM_COUNT: 4, ACCESS: 13108, SELF_ID: 4, REF_ID: 2 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 4, SELF_ID: 2 ) ------------------------------------------------------------ LMST 노드 LMST 노드는 관계형 모델에서 제한된 정렬 연산을 수행하는 노드이다. 이는 하나의 자식 노드를 가지며, 중간 결과를 저장하기 위하여 임시 테이블을 사용한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 LMST 노드의 정보는 다음과 같다. 구분 설명 비고 LIMIT-SORT 실행 노드의 이름 ITEM_SIZE 정렬을 위한 저장 레코드의 크기 ITEM_COUNT 사용된 레코드의 개수 STORE_COUNT 저장된 레코드의 개수 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID REF_ID 임시 테이블의 재구성 여부 를 결정하는 기준 노드 ID [표 11-29] LMST 노드의 정보 SQL 튜닝 353 LMST 노드는 매우 다양한 용도로 사용된다. 아래에서 각 용도별로 사용될 때의 실행 계획 트리를 살펴 본다. ORDER BY에서의 사용 LMST 노드는 LIMIT을 포함한 ORDER BY에 사용될 수 있다. 아래의 예는 LMST 노드가 ORDER BY를 위하여 사용된 경우이다. 실행 계획 정보를 살펴 보면, 3개의 저장 공간만 사용하여 16384건의 레코드에 대한 정렬을 수행함을 알 수 있다. iSQL> select * from t1 order by i4 limit 3; T1.I1 T1.I2 T1.I3 T1.I4 ----------------------------------------------------- 15 15 0 0 10 10 0 0 5 5 0 0 3 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 16 ) LIMIT-SORT( ITEM_SIZE: 16, ITEM_COUNT: 16384, STORE_COUNT: 3, ACCESS: 3, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) ------------------------------------------------------------ Subquery 검색에서의 사용 LMST 노드는 subquery 검색을 위하여 사용될 수 있다. 아래의 예는 LMST 노드가 일부 레코드만 정렬 저장하여 subquery 검색을 수행하고 있음을 보이고 있다. 여기서 LMST 노드는 질의 처리에 필요한 t2.i4 값 중 일부만을 저장하여 이에 대한 비교 연산의 비용을 줄이고 있다. 354 Administrator’s Manual iSQL> select i1 from t1 where i1 <=ANY ( select i4from t2 ); I1 -------------- 1 2 3 4 4 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) LIMIT-SORT( ITEM_SIZE: 16, ITEM_COUNT: 16384, STORE_COUNT: 2, ACCESS: 32768, SELF_ID: 4, REF_ID: 2 ) VIEW ( ACCESS: 16384, SELF_ID: 3 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ::SUB-QUERY END ------------------------------------------------------------ 이진 비저장 노드 이진 비저장 노드는 두 개의 자식 노드를 가지며, 해당 기능을 수행하기 위해 별도의 저장 공간이 필요하지 않다. 위와 같은 특징을 갖는 각 실행 노드의 기능과 실행 계획내에서 이를 분석하는 방법에 대하여 살펴본다. JOIN 노드 JOIN 노드는 관계형 모델에서 조인 연산을 수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 JOIN 노드의 정보는 다음과 같다. 구분 설명 비고 JOIN 실행 노드의 이름 [표 11-30] JOIN 노드의 정보 JOIN 노드는 거의 모든 일반 조인 수행을 위하여 사용된다. 아래에서 다음과 같은 다양한 조인 방법들이 어떠한 형태의 실행 계획 트리로 출력되는지를 살펴 본다. Full nested loop join SQL 튜닝 355 Full store nested loop join Index nested loop join One-pass sort join Multi-pass sort join One-pass hash join Multi-pass hash join 아래의 예제에서 동일한 질의가 다양한 조인 방법으로 처리되며, 각 방법에 대한 실행 계획 트리의 정보를 보여준다. 좌측은 조인 수행 방법에 대한 실행 계획 트리의 일부를 그림으로 도식화한 것이며, 우측은 실제 실행 계획이다. Full nested loop join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 53690368, SELF_ID: 3 ) ------------------------------------------------------------ JOIN SCANSCAN 위의 실행 계획에서 조인 조건은 우측 SCAN 노드에서 처리된다. T2 테이블에 대한 반복적인 전체 검색을 통해 처리된다. Full store nested loop join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) FILTER JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) STORE ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 10738729, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ JOIN SCANSTOR FILT SCAN 위의 실행 계획에서 조인 조건은 JOIN 상위의 FILT 노드에서 처리된다. T2 테이블에 대한 검색은 한 번만 이루어지며 그 결과를 저장한 후 반복적으로 전체 검색을 통해 처리된다. Index nested loop join의 실행 계획 트리 356 Administrator’s Manual iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 3277, SELF_ID: 3 ) ------------------------------------------------------------ JOIN SCANSCAN 위의 실행 계획에서 조인 조건은 우측 SCAN 노드에서 인덱스를 이용하여 처리된다. One-pass sort join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ JOIN SCANSORT SCAN 위의 실행 계획에서 조인 조건은 우측 SORT 노드에서 정렬된 데이터를 이용하여 처리된다. Multi-pass sort join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 6, REF_ID: 3 ) JOIN SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 4, REF_ID: 2 ) SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 5, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ JOIN SORTSORT SCANSCAN 위의 실행 계획에서 조인 조건은 우측 SORT 노드에서 정렬된 SQL 튜닝 357 데이터를 이용하여 처리되지만, 좌측에도 SORT 노드가 생성된다. One-pass hash join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) JOIN SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 3277, BUCKET_COUNT: 1024, ACCESS: 3277, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ JOIN HASH SCAN SCAN 위의 실행 계획에서 조인 조건은 우측 HASH 노드에서 해싱된 데이터를 이용하여 처리된다. Multi-pass hash join의 실행 계획 트리 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 6, REF_ID: 3 ) JOIN HASH ( ITEM_SIZE: 24, ITEM_COUNT: 3277, BUCKET_COUNT: 1024, ACCESS: 3277, SELF_ID: 4, REF_ID: 2 ) SCAN ( TABLE: T1, INDEX: IDX3, ACCESS: 3277, SELF_ID: 2 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 3277, BUCKET_COUNT: 1024, ACCESS: 3277, SELF_ID: 5, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ JOIN HASH SCAN HASH SCAN 위의 실행 계획에서 조인 조건은 우측 HASH 노드에서 정렬된 데이터를 이용하여 처리되지만, 좌측에도 HASH 노드가 생성된다. MGJN 노드 MGJN 노드는 관계형 모델에서 머지 조인 연산을 수행하는 노드이다. 이는 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. MGJN 실행 노드는 자식 노드로 SCAN, SORT, MGJN 중 하나를 취한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 MGJN 노드의 정보는 다음과 같다. 구분 설명 비고 358 Administrator’s Manual MERGE-JOIN 실행 노드의 이름 [표 11-31] MGJN 노드의 정보 MGJN 노드는 일반 조인 수행을 위하여 사용되며, 좌우 자식 노드를 모두 정렬하거나 정렬된 순서를 이용하여 처리한다. 자식 노드의 종류에 따라 9가지의 머지 조인의 형태가 가능하며, 여기서는 대표적인 두 가지의 실행 계획 트리에 대해서만 살펴 본다. 인덱스를 이용한 머지 조인 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) MERGE-JOIN SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 16384, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ MGJN SCANSCAN 위의 실행 계획에서 조인 조건은 MGJN 노드에서 처리되며 기본 테이블과 반복 테이블의 개념 없이 조인 조건에 포함된 칼럼의 인덱스가 모두 사용된다. 정렬을 이용한 머지 조인 iSQL> select count(*) from t1, t2 where t1.i1 = t2.i1 and t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 7, REF_ID: 3 ) MERGE-JOIN SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 4, REF_ID: 2 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 3277, ACCESS: 3277, SELF_ID: 5, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ MGJN SORTSORT SCANSCAN 위의 실행 계획에서 조인 조건은 MGJN 노드에서 처리되며 조인 조건에 포함된 칼럼을 기준으로 정렬한 후 이를 이용한다. LOJN 노드 LOJN 노드는 관계형 모델에서 LEFT OUTER JOIN 연산을 수행하는 노드이다. 이는 두개의 자식 노드를 가지며, 별도의 중간 SQL 튜닝 359 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 LOJN 노드의 정보는 다음과 같다. 구분 설명 비고 LEFT-OUTER- JOIN 실행 노드의 이름 [표 11-32] LOJN 노드의 정보 LOJN 노드는 일반 조인과 마찬가지로 대부분의 조인 방법에 사용되며, 이는 JOIN 노드의 예를 참조한다. 여기서는 LOJN 실행 노드가 사용되는 간단한 실행 계획 트리만을 살펴본다. iSQL> select count(*) from t1 left outer join t2 on t1.i1 = t2.i1 where t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 3 ) FILTER LEFT-OUTER-JOIN SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 3277, SELF_ID: 3 ) ------------------------------------------------------------ LOJN SCANSCAN FOJN 노드 FOJN 노드는 관계형 모델에서 FULL OUTER JOIN 연산을 수행하는 노드이다. 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 FOJN 노드의 정보는 다음과 같다. 구분 설명 비고 FULL-OUTER- JOIN 실행 노드의 이름 [표 11-33] FOJN 노드의 정보 FOJN 실행 노드는 일반 조인과 마찬가지로 대부분의 조인 방법에 사용되며, 이는 JOIN 노드의 예를 참조한다. 여기서는 FOJN 실행 노드가 사용되는 간단한 실행 계획 트리만을 살펴본다. 360 Administrator’s Manual iSQL> select count(*) from t1 full outer join t2 on t1.i1 = t2.i1 where t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 5, REF_ID: 3 ) FILTER FULL-OUTER-JOIN SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 3277, BUCKET_COUNT: 1024, ACCESS: 3277, SELF_ID: 4, REF_ID: 3 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 3 ) ------------------------------------------------------------ FOJN HASHSCAN SCAN FULL OUTER JOIN의 특성 상 우측에 저장을 위한 NODE가 생성되며, 위의 예에서 ON 조건은 HASH 노드에서 처리된다. AOJN 노드 AOJN 노드는 관계형 모델에서 ANTI OUTER JOIN 조인 연산을 수행하는 노드이다. 이는 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 AOJN 노드의 정보는 다음과 같다. 구분 설명 비고 ANTI-OUTER- JOIN 실행 노드의 이름 [표 11-34] AOJN 노드의 정보 AOJN 노드는 FULL OUTER JOIN만을 위해 사용되며, 아래와 같이 ON 조인 조건에서 참조되는 모든 칼럼에 대하여 인덱스를 사용할 수 있을 때 사용된다. iSQL> select count(*) from t1 full outer join t2 on t1.i1 = t2.i1 where t1.i3 = 1 and t2.i4 = 1; COUNT ----------------------- 3277 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 3 ) FILTER CONCATENATION LEFT-OUTER-JOIN SCAN ( TABLE: T1, FULL SCAN, ACCESS: 22938, SELF_ID: 2 ) SCAN ( TABLE: T2, INDEX: IDX11, ACCESS: 22938, SELF_ID: 3 ) ANTI-OUTER-JOIN SCAN ( TABLE: T2, FULL SCAN, ACCESS: 22938, SELF_ID: 3 ) SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 22938, SELF_ID: 2 ) ------------------------------------------------------------ CONC AOJNLOJN SQL 튜닝 361 위의 예에서와 같이 FULL OUTER JOIN을 처리하기 위하여 AOJN 노드는 항상 LOJN 노드와 부모로 CONC 노드를 갖는다. 이 때, ON 절의 조인 조건은 LOJN과 AOJN 에서 모두 처리된다. CONC 노드 CONC 실행 노드는 관계형 모델에서 concatenation 연산을 수행하는 노드이다. 이는 두개의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 CONC 노드의 정보는 다음과 같다. 구분 설명 비고 CONCATENATION 실행 노드의 이름 [표 11-35] CONC 노드의 정보 CONC 노드는 FULL OUTER JOIN의 처리와 DNF 처리에서 사용된다. FULL OUTER JOIN에서의 사용은 AOJN 노드에서 이미 그 예를 설명하였으며, 여기서는 DNF로 처리 시에 CONC 노드가 사용되는 예를 살펴 본다. iSQL> select sum(i3) from t1 where i1 = 1000 or i2 = 100; SUM(I3) ----------------------- 0 1 row selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 3, REF_ID: 2 ) CONCATENATION SCAN ( TABLE: T1, INDEX: IDX1, ACCESS: 1, SELF_ID: 2 ) FILTER SCAN ( TABLE: T1, INDEX: IDX2, ACCESS: 1, SELF_ID: 2 ) ------------------------------------------------------------ CONC FILTSCAN SCAN 여기서 (i1 = 1000) 조건은 왼쪽 SCAN 실행 노드에서 처리되며, (i2 = 100) 조건은 오른쪽 SCAN 실행 노드에서 처리된다. 이렇게 함으로서 IDX1 과 IDX2 인덱스가 모두 사용될 수 있으며 위 결과를 조합하기 위하여 CONC 실행 노드가 사용된다. FILT 노드는 좌측 SCAN과 중복되는 결과를 제거하기 위하여 사용된다. BUNI 노드 BUNI 노드는 관계형 모델에서 UNION ALL 연산을 수행하는 노드이다. 이는 두 개 이상의 자식 노드를 가지며, 별도의 중간 결과를 만들지 않으며 자식 노드들의 수행 흐름을 제어한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 BUNI 노드의 정보는 다음과 같다. 362 Administrator’s Manual 구분 설명 비고 BAG-UNION 실행 노드의 이름 [표 11-36] BUNI 노드의 정보 BUNI 노드가 수행되는 예를 보면 다음과 같다. iSQL> select i3, sum(i2) from t1 group by i3 union all select i3, avg(i2) from t2 group by i3; I3 SUM(I2) --------------------------- 1 158807 2 162084 3 165361 4 168638 0 155530 1 48.4610925 2 49.4610925 3 50.4610925 4 51.4610925 0 47.47558 10 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 26 ) VIEW ( ACCESS: 10, SELF_ID: 3 ) BAG-UNION PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) GROUP-AGGREGATION ( ITEM_SIZE: 32, GROUP_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 5, SELF_ID: 4, REF_ID: 1 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 26 ) GROUP-AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 5, BUCKET_COUNT: 1024, ACCESS: 5, SELF_ID: 5, REF_ID: 2 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 2 ) ------------------------------------------------------------ BUNI PROJPROJ 위의 예를 보면 BUNI 노드는 두 질의의 결과를 단순히 조합하여 UNION ALL을 처리한다. 이진 저장 노드 이진 저장 노드는 두개의 자식 노드를 가지며, 해당 기능을 수행하기 위해 별도의 저장 공간을 필요로 한다. 위와 같은 특징을 갖는 각 실행 노드의 기능과 실행 계획 내에서 이를 분석하는 방법에 대하여 살펴본다. SITS 노드 SITS 노드는 관계형 모델에서 INTERSECT 연산을 수행하는 노드이다. 이는 두개의 자식 노드를 가지며, 교집합을 얻기 위하여 중간 결과를 저장하여 처리한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 SITS SQL 튜닝 363 노드의 정보는 다음과 같다. 구분 설명 비고 SET-INTERSECT 실행 노드의 이름 ITEM_SIZE 교집합을 위한 저장 레 코드의 크기 ITEM_COUNT 저장된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개 수 DISK_PAGE_COUNT 임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID L_REF_ID 임시 테이블의 재구성 여부를 결정하는 왼쪽 질의의 기준 노드 ID R_REF_ID 임시 테이블의 재구성 여부를 결정하는 오른쪽 질의의 기준 노드 ID [표 11-37] SITS 노드의 정보 SITS 노드가 INTERSECT를 위해 수행되는 예는 다음과 같다. 좌측 질의의 결과 데이터를 중복 제거하여 저장하고, 우측 질의의 결과 데이터를 이용하여 교집합에 해당하는 결과를 검색하게 된다. iSQL> select i1, i3 from t1 intersect select i3, i1 from t2; I1 I3 --------------------------- 1 1 2 2 3 3 4 4 4 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) VIEW ( ACCESS: 4, SELF_ID: 2 ) SET-INTERSECT ( ITEM_SIZE: 24, ITEM_COUNT: 16384, BUCKET_COUNT: 8192, ACCESS: 4, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ SITS PROJPROJ SDIF 노드 SDIF 노드는 관계형 모델에서 MINUS 연산을 수행하는 노드이다. 이는 두 개의 자식 노드를 가지며, 차집합을 얻기 위하여 중간 결과를 저장하여 처리한다. 364 Administrator’s Manual EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 SDIF 노드의 정보는 다음과 같다. 구분 설명 비고 SET-DIFFERENCE 실행 노드의 이름 ITEM_SIZE 차집합을 위한 저장 레 코드의 크기 ITEM_COUNT 저장된 레코드의 개수 BUCKET_COUNT 해싱을 위한 버킷의 개 수 DISK_PAGE_COUNT 임시 저장 테이블의 디 스크 페이지 개수 메모리 임시 테 이블은 해당 정 보가 없음 ACCESS 저장된 레코드에 대한 접근 횟수 SELF_ID 실행 노드의 ID L_REF_ID 임시 테이블의 재구성 여부를 결정하는 왼쪽 질의 기준 노드 ID R_REF_ID 임시 테이블의 재구성 여부를 결정하는 오른쪽 질의 기준 노드 ID [표 11-38] SDIF 노드의 정보 SDIF 노드가 MINUS를 위해 수행되는 예는 다음과 같다. 좌측 질의의 결과를 중복 제거하여 저장하고, 우측 질의의 결과를 이용하여 교집합을 구한 후 교집합에 포함되지 않은 결과만을 검색한다. iSQL> select i1, i3 from t1 minus select i1, i3 from t2; I1 I3 --------------------------- No rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) VIEW ( ACCESS: 0, SELF_ID: 2 ) SET-DIFFERENCE ( ITEM_SIZE: 24, ITEM_COUNT: 16384, BUCKET_COUNT: 8192, ACCESS: 0, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T1, FULL SCAN, ACCESS: 16384, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 8 ) SCAN ( TABLE: T2, FULL SCAN, ACCESS: 16384, SELF_ID: 1 ) ------------------------------------------------------------ SDIF PROJPROJ 다중 비저장 노드 다중 비저장 노드는 두개 이상의 자식 노드를 가지며, 해당 기능을 SQL 튜닝 365 수행하기 위해 별도의 저장 공간을 필요로 하지 않는다. 위와 같은 특징을 갖는 각 실행 노드의 기능과 실행 계획내에서 이를 분석하는 방법에 대하여 살펴본다. PCRD 노드 PCRD(Partition-Coordinator) 노드는 파티션드 테이블의 각각의 파티션에 대한 스캔을 관리하는 노드이다. 여러 개의 자식 노드를 가지며, 파티션 필터링을 수행한다. EXPLAIN PLAN을 ON(또는 ONLY)로 설정하여 표시되는 PCRD 노드의 정보는 다음과 같다. 구분 설명 비고 PARTITION- COORDINATOR 실행 노드의 이름 TABLE 접근하는 테이블의 이름 PARTITION 접근하는 파티션의 개수 ACCESS 실제 접근한 레코드의 개수 SELF_ID 실행 노드의 ID [표 11-39] PCRD 노드의 정보 PCRD 노드가 수행되는 예는 다음과 같다. 자식 노드인 파티션에 대한 스캔 결과를 상위 노드로 전달한다. iSQL> SELECT COUNT(*) FROM PDT_RANGE WHERE F1 < 30; COUNT ----------------------- 3 1 row selected. --------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 6, REF_ID: 2 ) PARTITION-COORDINATOR ( TABLE: PDT_RANGE, PARTITION: 3/4, ACCESS: 3, SELF_ID: 2 ) SCAN ( PARTITION: P3, FULL SCAN, ACCESS: 1, DISK_PAGE_COUNT: 2, SELF_ID: 3 ) SCAN ( PARTITION: P2, FULL SCAN, ACCESS: 1, DISK_PAGE_COUNT: 2, SELF_ID: 4 ) SCAN ( PARTITION: P1, FULL SCAN, ACCESS: 1, DISK_PAGE_COUNT: 2, SELF_ID: 5 ) -------------------------------------- PCRD SCANSCANSCAN... 366 Administrator’s Manual 힌트의 활용 힌트는 SQL문 실행 계획을 사용자가 명시적으로 변경하고자 할 때 사용하는 기능이다. 사용자가 생성 가능한 SQL문은 그 수를 헤아릴 수가 없으며, 동일한 질의라 하더라도 데이터의 구성에 따라 서로 다른 실행 계획이 생성될 수 있다. Optimizer는 보편적으로 효율적인 실행 계획을 생성하기는 하나 모든 질의에 있어 가장 좋은 실행 계획을 생성할 수 있는 것은 아니다. 이러한 단점을 보완하기 위하여 사용자는 힌트를 사용하여 실행 계획을 명시적으로 변경하여 보다 나은 성능을 얻을 수 있다. 그러나, 모든 질의에 대하여 힌트를 사용하여 실행 계획을 변경하는 것은 매우 불합리하다. 이는 인덱스의 생성, 데이터 구성의 변경등에 대하여 모든 질의에 대하여 다시 힌트를 작성해야 하는 부하가 따르게 되기 때문이다. 따라서, 시스템의 성능에 영향을 미치는 일부 치명적인 질의에 한하여 힌트를 사용하는 것이 바람직하다. 힌트 처리 정책 사용자가 정의한 힌트는 다음과 같은 정책에 의하여 처리된다. 사용자가 정의한 힌트가 문법적으로 오류가 없고 실행이 가능한 경우 무조건 힌트를 따른다. 즉, 문법적으로 오류가 있는 경우나 실행이 불가능한 힌트는 적용되지 않는다. 힌트 적용 시 사용자가 정의한 힌트에 단순히 가중치를 부여하는 것이 아니며, 사용자가 이미 모든 정보를 고려하여 가장 효율적인 실행 계획을 결정했음을 가정한다. 힌트가 서로 상충할 경우 그 유형에 따라 다음과 같은 우선 순위를 따른다. 최적화 적용 기준 정규화 형태 조인 순서 조인 방법 중간 결과 저장 매체 해싱 버킷 크기 그룹 처리 방법 중복 제거 처리 방법 뷰 최적화 방법 액세스 방법 SQL 튜닝 367 힌트의 종류 최적화 적용 기준 최적화를 규칙 기반으로 수행할 것인지, 비용 기반으로 수행할 것인지를 설정하는 힌트이다. RULE: 비용을 배제한 실행 계획 생성 COST: 비용을 고려한 실행 계획 생성 질의에 따라 항상 같은 실행 계획이 생성되길 원한다면 RULE 힌트를 지정하며, 데이터 양의 변경량이 커 조인 순서 등에 많은 영향을 미친다면 COST를 지정해 주는 것이 좋다. 해당 힌트를 사용하지 않을 경우 기본적으로 비용 기반 최적화가 수행된다. 정규화 형태 정규화 방법을 SQL문 단위로 설정할 수 있게 하는 힌트이다. CNF: Conjunctive Normal Form으로 정규화 Conjunctive Normal Form에서는 AND 연산자가 최상위 레벨의 논리 연산자이고 OR 연산자는 낮은 레벨의 연산자이다. CNF 힌트 사용시 알티베이스는 실행 계획을 생성할 때 SELECT 문을 Conjunctive Normal Form 으로 변환한다. 그러나 가끔은 Conjunctive Normal Form으로 변환할 경우 아주 복잡한 조건절로 변환되고 이는 과도한 시스템 자원의 소모를 초래하게 된다. 이런 경우에는 힌트가 지정되었더라도 알티베이스는 CNF 를 사용하지 않는다. DNF: Disjunctive Normal Form으로 정규화 Disjunctive Normal Form에서는 OR 연산자가 최상위 레벨의 논리 연산자이고 AND 연산자는 낮은 레벨의 연산자이다. DNF 힌트를 사용하면 SELECT 문을 Disjunctive Normal Form 으로 변환하는 실행 계획이 생성된다. 따라서 각 조건절은 각자의 인덱스를 사용하여 따로 처리된다. 단 SQL구문에 어떤 OR 절도 포함되어 있지 않다면, 이 힌트는 무시된다. 또한, 조건절의 속성에 따라서 DNF로 변환 시 너무 많은 수의 조건절이 생성될 수도 있고 이는 과도한 시스템 자원의 소모를 수반한다. 이런 경우에는 힌트가 지정되었더라도 알티베이스는 DNF 를 사용하지 않는다. 해당 힌트가 사용되지 않을 경우 두 정규화의 비용 비교를 통하여 하나의 정규화 방법이 선택된다. 조인 순서 368 Administrator’s Manual 조인 순서를 결정하는 힌트이다. ORDERED: FROM절에 나열된 순서대로 조인 순서를 결정 해당 힌트가 사용되지 않을 경우 비용 비교를 통하여 조인 순서를 결정한다. 조인 방법 조인 방법을 결정하는 힌트이다. USE_NL: Nested loop 조인 계열의 조인 방법을 사용 USE_NL 힌트는 명시된 테이블을 조인하기 위해 Nested loop 조인을 사용하도록 지정하는 힌트이다. USE_SORT: Sort-based 조인 계열의 조인 방법을 사용 USE_SORT 힌트는 명시된 테이블을 조인하기 위해 Sort 조인을 사용하도록 지정하는 힌트이다. 단 sorting 술어가 하나도 없을 경우 Nested loop 조인이 사용된다. USE_HASH: Hash-based 조인 계열의 조인 방법을 사용 USE_HASH 힌트는 명시된 테이블을 조인하기 위해 Hash 조인을 사용하도록 지정하는 힌트이다. 단 hasing 술어가 하나도 없을 경우 Nested loop 조인이 사용된다. USE_MERGE: Merge 조인 조인 계열의 조인 방법을 사용 USE_MERGE 힌트는 명시된 테이블을 조인하기 위해 Sort Merge 조인을 사용하도록 지정하는 힌트이다. 단 sorting 술어가 하나도 없을 경우 Nested loop 조인이 사용된다. 조인 방법에 대한 힌트는 조인 방법을 결정하기 위해 다음과 같이 처리된다. Optimizer는 내부 테이블이 나열된 순서로 조인 가능성 여부를 검사한다. 예를 들어, USE_NL(T1, T2) 힌트인 경우 T1 => T2 로의 조인 가능 여부를 검사한다. Optimizer는 내부 테이블이 나열된 역순으로 조인 가능성 여부를 검사한다. 위의 검사에서 해당 순서로 조인을 적용할 수 없는 경우 그 역순인 T2 => T1 의 순서로 조인 가능 여부를 검사한다. 위의 두 경우에 모두 해당하지 않으면, 비용 비교를 통하여 새로운 조인 방법을 선택한다. ORDERED 힌트와 상충되는 경우 예를 들어, 다음과 같은 질의가 있다고 가정하자. SELECT /*+ ORDERED USE_NL(T2, T1) */ FROM T1, T2 WHERE T1.i1 = T2.i1; ORDERED 힌트와 USE_NL 힌트의 테이블 순서는 서로 상충되며 우선 순위에 의하여 ORDERED 힌트를 따르게 된다. SQL 튜닝 369 동일 테이블에 대하여 여러 가지 조인 방법 힌트가 지정될 경우 나열된 방법 중 비용 평가를 통해 가장 효율적인 힌트가 선택된다. USE_NL(T1, T2) USE_HASH(T2, T1) 중간 결과 저장 매체 중간 결과를 저장하기 위한 임시 테이블의 저장 매체를 지정하는 힌트이다. TEMP_TBS_MEMORY: 질의 처리 중에 생성되는 모든 중간 결과를 저장하기 위해 메모리 임시 테이블을 사용한다. TEMP_TBS_DISK: 질의 처리 중에 생성되는 모든 중간 결과를 저장하기 위해 디스크 임시 테이블을 사용한다. TEMP_TBS_MEMORY의 경우 저장되는 중간 결과의 크기가 적을 경우에 성능향상을 위해 사용하는 것이 바람직하며, TEMP_TBS_DISK는 성능 저하를 감안하더라도 저장되는 중간 결과의 크기가 매우 큰 경우에 리소스 절약을 위해 사용하는 것이 바람직하다. 해시 버킷 크기 이 힌트는 해싱 기법을 사용하는 실행 노드들의 버킷 개수를 조정하기 위하여 사용된다. Optimizer는 GROUP BY, UNION, INTERSECT, MINUS, DISTINCT, HASH JOIN 및 aggregate functions 같은 구문을 처리하기 위해 해싱을 사용한다. 할당된 해시 버킷의 개수가 처리될 레코드의 개수에 적합하다면 질의 처리 속도가 향상될 것이다. 비용 기반 최적화에서 해시 버킷의 적절한 개수는 내부적으로 레코드 개수에 기반해서 결정된다. 그러나, 다음의 버킷의 개수를 임의로 지정하고 싶다면 힌트를 사용하면 된다. HASH BUCKET COUNT: HASH와 HSDS 노드의 해시 버킷 수 변경 GROUP BUCKET COUNT: GRAG와 AGGR 노드의 해시 버킷 수 변경 SET BUCKET COUNT: SITS와 SDIF 노드의 해시 버킷 수 변경 그룹 처리 방법 GROUP BY절의 처리 방법을 지정하기 위하여 사용하는 힌트이다. GROUP_HASH: 해싱 방식에 의한 처리 370 Administrator’s Manual GROUP_SORT: 정렬 방식에 의한 처리 중복 제거 처리 방법 DISTINCT의 처리 방법을 지정하기 위하여 사용하는 힌트이다. DISTINCT_HASH: 해싱 방식에 의한 처리 DISTINCT_SORT: 정렬 방식에 의한 처리 뷰 최적화 방법 뷰 외부의 WHERE절의 조건을 뷰 내부에서 처리할 것인지의 여부를 결정하기 위하여 사용하는 힌트이다. NO_PUSH_SELECT_VIEW: 외부의 WHERE 절의 조건을 뷰 내부로 이동하여 처리하지 않는다. PUSH_SELECT_VIEW: 외부의 WHERE 절의 조건 중 가능한 것은 모두 뷰 내부로 이동하여 처리 Push Predicate 방법 뷰 외부의 WHERE절의 조인 조건을 뷰 내부에서 처리할 것인지의 여부를 결정하기 위하여 사용하는 힌트이다. PUSH_PRED: 외부의 WHERE절의 조건 중 뷰와 관계된 조인 조건을 뷰 내부로 이동하여 처리 액세스 방법 테이블 접근 방법을 제어하는 힌트이다. FULL SCAN: 테이블에 이용 가능한 인덱스가 존재하더라도 인덱스를 사용하지 않고 테이블 전체 스캔 INDEX: 나열된 index중 하나를 이용해 인덱스 스캔 INDEX ASC: 나열된 index중 하나를 이용해 인덱스 오름차순 스캔 (ascending index scan) INDEX DESC: 나열된 index중 하나를 이용해 인덱스 내림 차순 스캔 (descending index scan) NO INDEX: 나열된 인덱스들은 최적화 과정에서 배제 뷰 내부에 사용된 테이블의 인덱스 이름을 위의 힌트 구문에 사용하면, 뷰에 대해서도 일반 테이블처럼 인덱스 힌트를 줄 수 있다. 액세스 방법을 제어하는 힌트는 여러 개가 사용될 수 있다. 이들 힌트는 다음과 같은 정책에 의하여 처리된다. 나열된 힌트가 상충하는 경우, 나열된 순서대로 힌트가 적용되고 뒤의 힌트는 무시된다. SQL 튜닝 371 예제: INDEX(T1, IDX1) NO INDEX(T1, IDX1) 나열된 힌트가 상충되지 않을 경우 힌트에 나열된 액세스 방법 중 비용 계산에 기반하여 보다 효율적인 액세스 방법이 선택된다. 예제: FULL SCAN(T1), INDEX(T1, IDX1) 액세스 방법 힌트가 조인 방법 힌트와 함께 사용될 경우 액세스 방법 힌트와 조인 방법 힌트는 별개의 것으로 처리된다. 예제: USE_HASH(T1, T2), INDEX(T2, IDX2) 인덱스를 사용하여 접근되며 Hash-based 조인 방법으로 처리된다. Explain Plan 373 12. Explain Plan 374 Administrator’s Manual 개요 Explain Plan은 알티베이스 데이터베이스 서버가 최적화된 질의를 실행하기 위해 수행하는 접근 경로를 보여준다. 즉, EXPLAIN PLAN 을 ON 또는 ONLY로 설정하고 SQL구문을 실행하면, optimizer는 그 구문을 위한 실행 계획을 결정하고 실행 계획을 설명하는 데이터가 그 SQL문을 실행했던 클라이언트로 반환된다. Plan Tree 정의 질의를 최적화하는 것은 SQL문이 얼마나 빨리 실행될 수 있는가에 크게 영향을 준다. 알티베이스 EXPLAIN PLAN은 서버가 최적화된 질의를 실행하는 방법을 설명한다. 즉 EXPLAIN PLAN은 SQL 문의 성능 향상과 실행 계획 (execution plan, 이하 “plan tree”라 칭함)을 결정하는데 도움을 주기 위해 사용된다. Plan Tree의 이해 많은 테이블들로부터 데이터를 검색하는 SQL문 실행시, 같은 결과 집합을 얻는 다양한 최적화 방법 (테이블을 조인하는 방법, 조인 순서, 그리고 접근 경로 등)이 사용될 수 있다. 알티베이스는 다음과 같은 다양한 요소들을 근거로 적합한 방법을 결정한다. 사용 가능한 인덱스들 SQL문 내에서의 테이블들과 열들의 순서 최적화 기법 SQL문의 plan tree는 EXPLAIN PLAN 프로퍼티를 적절히 설정함으로써 볼 수 있다. 사용자들은 plan tree를 검사함으로써 알티베이스가 SQL문을 어떻게 실행하고 있는가를 정확하게 이해할 수 있다. Plan Tree의 분석 EXPLAIN PLAN 프로퍼티를 적절히 설정하면 SQL문을 직접 실행하지 않고도 plan tree를 볼 수 있으므로, SQL문의 실행 방법을 볼 수 있을 뿐만 아니라 다른 plan tree와 비교할 수도 있어 SQL문의 성능을 향상할 수 있다. Explain Plan 375 Plan tree 에서는 다음과 같은 정보를 얻을 수 있다: Optimizer에 의해 생성된 실행 계획 Objects (테이블, 인덱스, 등)의 속성 사용된 index 사용된 조인 방법 최적화된 조인 순서 성능 분석 개선된 SQL문의 성능을 입증하는 방법은 다음과 같다. 새로운 SQL문을 실행하고 그 결과를 이전 SQL문의 실행 결과와 비교한다. 새로운 plan tree를 생성하고, 그것을 이전의 plan tree와 비교한다. Object(테이블, 인덱스 등)의 속성들이 정확한가를 확인하기 위하여 속성들을 재검토한다. Plan Tree 출력 기능 iSQL에서 다음 구문으로 EXPLAIN PLAN을 적절한 값으로 설정한다. ALTER SESSION SET EXPLAIN PLAN = ON/OFF/ONLY; 그 다음에 SQL문을 실행한다. 다음 EXPLAIN PLAN 옵션에 따라 plan tree를 텍스트 형태로 볼 수 있다. ON 질의 수행 후 plan tree, 레코드 접근 횟수, 및 튜플이 점유한 메모리 양 등을 출력 OFF plan tree 출력하지 않음. ONLY 질의를 실제로 실행하지는 않고, plan tree만 출력 iSQL> ALTER SESSION SET EXPLAIN PLAN = ON; iSQL> SELECT e_firstname, e_lastname FROM employees WHERE emp_job = 'PROGRAMMER'; E_FIRSTNAME E_LASTNAME ----------------------------------------------- 376 Administrator’s Manual R y u M o m o i El i z a b e t h B a e 2 ro w s s e l e c t e d . ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 44 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) ------------------------------------------------------------ iSQL> ALTER SESSION SET EXPLAIN PLAN = OFF; Alter success. iSQL> SELECT e_firstname, e_lastname FROM employees WHERE emp_job = 'PROGRAMMER'; E_FIRSTNAME E_LASTNAME ----------------------------------------------- Ryu Momoi Elizabeth Bae 2 rows selected. iSQL> ALTER SESSION SET EXPLAIN PLAN = ONLY; Alter success. iSQL> SELECT e_firstname, e_lastname FROM employees WHERE emp_job = 'PROGRAMMER'; E_FIRSTNAME E_LASTNAME ----------------------------------------------- No rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 44 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: ??, SELF_ID: 2 ) ------------------------------------------------------------ EXPLAN PLAN을 ONLY로 설정하면 질의를 실제로 실행하지 않고 실행 계획만 생성하므로 ACCESS 항목과 같이 실제 실행 후 그 값이 결정되는 항목들은 물음표(“??”)로 표시된다. Explain Plan 377 Plan Tree 보기 Plan tree는 plan 노드들과 각 노드 간의 연결 관계로 이루어진다. 자식 노드는 부모 노드보다 한 칸 아래에 첫머리가 안으로 들어가 나타난다. 또한 subquery는 ::SUB-QUERY BEGIN과 ::SUB- QUERY END 사이에 보여진다. iSQL> SELECT c.cname FROM customer c WHERE c.cno IN (SELECT o.cno FROM orders o WHERE o.ono = 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 ----------------------------------------------- PROJECT SCAN PROJECT SCAN CUSTOMER ORDERS 1 2 3 4 5 1. orders 테이블에 있는 주문 번호(ono)를 인덱스를 이용하여 검 색한다. 인덱스를 이용한 접근 회수는 20임을 알 수 있다. 인덱 스가 생성되지 않은 열을 기준으로 orders 테이블을 검색한다면 조건에 만족하는 열들을 찾기 위해서 전체 orders 테이블을 스 캔(full scan) 해야 할 것이다. 즉, 사용자는 full scan을 수행할 4 3 2 1 378 Administrator’s Manual 것인가, 인덱스를 사용해서 scan을 할 것인가를 plan 노드의 비 용 정보를 비교해서 선택할 수 있다. 2. orders 테이블에서 cno인 열을 찾아 열의 개수가 하나인 새로운 relation1을 만든다. 3. c.cno = o.cno 조건을 만족하는 레코드를 검색하기 위해 전체 customer 테이블을 full scan 한다. access의 회수는 customer 테이블에 있는 레코드 개수(20)만큼이다. 4. customer 테이블에서 cname인 열을 찾아 새로운 relation2를 만든다. 5. relation2를 출력한다. Explain Plan 379 Plan Nodes Plan Tree는 특정한 SQL문을 위해 생성된 실행 계획이다. Plan Nodes는 Plan tree를 구성하는 각 노드(node)를 의미한다. Plan Node의 종류 Plan Node는 Child Plan의 개수 또는 구현(materialization, 즉 중간 결과가 물리적으로 저장) 여부에 의해 구분된다. Child Node의 개수에 따른 구분 One-child Node Child node가 0개 또는 하나인 plan node를 의미한다. Binary Node (Two-child Node) Child node가 두 개인 plan node를 의미한다. Multi-child Node Child node가 두 개 이상인 plan node를 의미한다. Materialization 여부에 의한 구분 Non-materialized Node 중간 결과를 저장하지 않고, 한 번에 한 개의 레코드를 처리하는 plan node를 의미한다. Materialized Node 모든 Child node를 수행한 결과를 중간 결과로 저장하는 plan node를 의미한다. 380 Administrator’s Manual Node Non-materialized Materialized Name Meaning Name Meaning One- child 기 본 SCAN Selection SORT Sort FILTER Filter HASH Hash PROJECT Projection 그 룹 GROUPING Group By GROUP- AGGREGATION Group Aggregation AGGREGATION Aggregation COUNT Count(*) 뷰 VIEW View MATERIALIZA TION View Materialization VIEW-SCAN View Scan 기 타 HIERARCHICA L QUERY Hierarchy DISTINCT Hash Distinct LIMIT-SORT Limit Sort Two- child 조 인 JOIN Join MERGE-JOIN Merge Join LEFT-OUTER- JOIN Left Outer Join FULL- OUTER-JOIN Full Outer Join ANTI-OUTER- JOIN Anti Outer Join 집 합 함 수 BAG-UNION Bag Union SET- INTERSECT Set Intersect SET- DIFFERENCE Set Difference 기 타 CONCATENATI ON Concatenation Multi -child 기 타 PARTITION- COORDINATOR Partition- Coordinator [표 12-1] Plan Node의 종류 AGGREGATION 정의 이 노드는 중복이 제거된 집합(Distinct aggregation) 기능을 수행한다. Aggregation 수행 시 인자로서 distinct 칼럼이 존재하면 distinct 대상이 되는 열에서 중복 값을 제거하기 위해서 이 노드가 사용되며, GROUP-AGGREGATION node와는 별도로 수행된다. Explain Plan 381 형식 AGGREGATION ( ITEM_SIZE: item_size, GROUP_COUNT: group_count ) item_size 저장하는 item의 크기 group_count group의 총 개수 예제 총 부서의 수와 모든 사원들의 평균 급여를 출력하라. iSQL> SELECT COUNT(DISTINCT dno), AVG(salary) FROM employee; COUNT(DISTINCT DNO) AVG(SALARY) ------------------------------------ 8 1836.64706 1 row selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 30 ) AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 1 ) SCAN ( TABLE: EMPLOYEE, FULL SCAN, ACCESS: 20, SELF_ID: 1 ) ----------------------------------------------- ANTI-OUTER-JOIN 정의 FULL-OUTER-JOIN의 빠른 처리를 위해 부가적으로 생성되는 노드이며, binary node 이다. 형식 ANTI-OUTER-JOIN 예제 부서의 위치와 상품을 모아 놓은 장소가 같은 곳의 부서 번호, 부서 이름, 상품 번호를 출력하라. iSQL> CREATE INDEX dep_idx2 ON department(dep_location); Create success. iSQL> CREATE INDEX gds_idx1 ON goods(goods_location); Create success. iSQL> SELECT d.dno, d.dname, g.gno FROM department d FULL OUTER JOIN goods g 382 Administrator’s Manual O N d . d e p _ l o c a t i o n = g . g o o d s _ l o c a t i o n ; D N O D N A M E G N O -------------------------------------------- A001 Applied Technology Team D001 Engine Development Team C001 Marketing Team C002 Planning Management Team F001 Sales Team A111100001 A111100002 B111100001 C111100001 C111100002 D111100001 D111100002 D111100003 D111100004 D111100005 D111100006 D111100007 D111100008 D111100009 D111100010 D111100011 E111100001 E111100002 E111100003 E111100004 E111100005 E111100006 E111100007 E111100008 E111100009 E111100010 E111100011 E111100012 E111100013 F111100001 35 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 29 ) CONCATENATION LEFT-OUTER-JOIN Explain Plan 383 SCAN ( TABLE: DEPARTMENT D, FULL SCAN, ACCESS: 35, SELF_ID: 1 ) SCAN ( TABLE: GOODS G, INDEX: GDS_IDX1, ACCESS: 35, SELF_ID: 2 ) [ VARIABLE KEY ] OR AND D.DEP_LOCATION = G.GOODS_LOCATION ANTI-OUTER-JOIN SCAN ( TABLE: GOODS G, FULL SCAN, ACCESS: 35, SELF_ID: 2 ) SCAN ( TABLE: DEPARTMENT D, INDEX: DEP_IDX2, ACCESS: 35, SELF_ID: 1 ) [ VARIABLE KEY ] OR AND D.DEP_LOCATION = G.GOODS_LOCATION ----------------------------------------------- BAG-UNION 정의 Bag Union 기능을 수행하며 두 개 이상의 child node를 갖는 node 이다. SQL문 중 UNION ALL에 해당한다. 형식 BAG-UNION 예제 직업이 판매원인 사원과 급여가 2000000 보다 큰 모든 사원의 이름과 급여를 출력하라. iSQL> SELECT e_firstname, e_lastname, emp_job, salary FROM employees WHERE emp_job = 'SALES REP' UNION ALL SELECT e_firstname, e_lastname, emp_job, salary FROM employees WHERE salary > 2000; E_FIRSTNAME E_LASTNAME EMP_JOB SALARY --------------------------------------------------------------------------- 384 Administrator’s Manual SAN D R A H A M M O N D SAL ES R E P 1 8 9 0 AL VAR M AR Q U EZ S AL E S R EP 1 8 0 0 W I L L I A M B L AKE SA L ES R EP F AR H AD G H O R BAN I PL 2 5 0 0 EL I Z ABET H B AE PR O G R A M M E R 4 0 0 0 Z H EN L I U W EB M AS T ER 2 7 5 0 YU U M I U R A P M 2 0 0 3 W EI - W EI C H EN M AN AG ER 2 3 0 0 8 ro w s s e l e c t e d . ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 70 ) VIEW ( ACCESS: 8, SELF_ID: 4 ) BAG-UNION PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 70 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 70 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 3 ) ------------------------------------------------------------ CONCATENATION 정의 OR 조건(DNF)의 빠른 처리를 위한 노드이다. 이 노드는 바이너리 노드로 left child와 right child를 순차적으로 수행한다. 또한, 이 노드는 Full Outer Join을 위한 concatenation을 수행한다. 형식 CONCATENATION 예제 ANTI-OUTER-JOIN node의 예제를 참고하기 바란다. Explain Plan 385 COUNT 정의 COUNT(*)의 빠른 처리를 위한 노드이다. 형식 1) 인덱스가 사용되는 경우: COUNT (TABLE: tbl_name, INDEX: index_name, ACCESS: acc_num, SELF_ID: node_id, REF_ID: ref_id ) 2) 인덱스가 사용되지 않는 경우: COUNT (TABLE: tbl_name, FULL SCAN, ACCESS: acc_num, SELF_ID: node_id, REF_ID: ref_id ) table_name 테이블 이름 FULL SCAN 인덱스 사용 안함 index_name 사용되는 인덱스 acc_num 레코드 접근 횟수 node_id tuple set 내에서의 ID (노드의 ID로 간주) ref_id 참조하는 노드 ID 예제 사원의 총 수를 계산하라. iSQL> SELECT COUNT(*) rec_count FROM 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 ) ----------------------------------------------- DISTINCT 정의 386 Administrator’s Manual DISTINCT 연산을 수행하는 materialized node 이다. 형식 1) 중간 결과가 메모리에 저장되는 경우 DISTINCT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) 2) 중간 결과가 디스크에 저장되는 경우 DISTINCT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장한 item의 개수 bucket_count hash bucket의 개수 page_count page의 개수 acc_num 레코드 접근 횟수 self_id node ID ref_id 참조하는 node의 ID 예제 상품 C111100001을 주문한 고객의 이름을 출력하라. iSQL> SELECT DISTINCT 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_ID: 6, REF_ID: 2 ) Explain Plan 387 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, SELF_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 388 Administrator’s Manual C 1 1 1 1 0 0 0 0 1 4 D 1 1 1 1 0 0 0 0 8 3 E1 1 1 1 0 0 0 1 2 3 4 ro w s s e l e c t e d . ----------------------------------------------- PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 16 ) FILTER AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 16 ) GROUPING SCAN ( TABLE: ORDERS, INDEX: ODR_IDX3, ACCESS: 30, SELF_ID: 2 ) ----------------------------------------------- FULL-OUTER-JOIN 정의 Full Outer Join 기능을 수행하며, binary node 이다. 형식 FULL-OUTER-JOIN 예제 부서의 위치와 상품을 모아 놓은 장소가 같은 곳의 부서 번호, 부서 이름, 상품 번호를 출력하라. iSQL> INSERT INTO department VALUES(BYTE'F002', 'headquarters', 'CE0002', 100); 1 row inserted. iSQL> SELECT d.dno, d.dname, g.gno FROM department d FULL OUTER JOIN goods g ON d.dep_location = g.goods_LOCATION; DNO DNAME GNO -------------------------------------------- A111100001 A111100002 B111100001 C111100001 C111100002 D111100001 D111100002 D111100003 Explain Plan 389 D111100004 D111100005 D111100006 D111100007 D111100008 D111100009 D111100010 D111100011 E111100001 E111100002 E111100003 E111100004 F002 headquarters E111100005 E111100006 E111100007 E111100008 E111100009 E111100010 E111100011 E111100012 E111100013 F111100001 A001 Applied Technology Team D001 Engine Development Team C002 Planning Management Team C001 Marketing Team F001 Sales Team B001 Quality Assurance 36 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 29 ) FULL-OUTER-JOIN SCAN ( TABLE: GOODS G, FULL SCAN, ACCESS: 36, SELF_ID: 2 ) HASH ( ITEM_SIZE: 24, ITEM_COUNT: 7, BUCKET_COUNT: 1024, ACCESS: 36, SELF_ID: 3, REF_ID: 1 ) SCAN ( TABLE: DEPARTMENT D, FULL SCAN, ACCESS: 36, SELF_ID: 1 ) ----------------------------------------------- GROUP-AGGREGATION 정의 390 Administrator’s Manual 이 노드는 Group aggregation 기능을 수행하며 materialized node 이다. 형식 1) 중간 결과가 메모리에 저장되는 경우 GROUP-AGGREGATION ( ITEM_SIZE: item_size, GROUP_COUNT: group_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) 2) 중간 결과가 디스크에 저장되는 경우 GROUP-AGGREGATION ( ITEM_SIZE: item_size, GROUP_COUNT: group_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 group_count 저장한 group의 개수 bucket_count Hash bucket의 개수 page_count Page의 개수 acc_num 레코드 접근 횟수 self_id node ID ref_id 참조하는 node ID 예제 각 부서내의 각 직위에 대해 지급되는 급여 총액을 출력하라. (여러 열에 GROUP BY 절을 사용) iSQL> SELECT dno, emp_job, COUNT(emp_job) num_emp, SUM(salary) sum_sal FROM employees GROUP BY dno, emp_job; DNO EMP_JOB NUM_EMP SUM_SAL ----------------------------------------------- . . . 16 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 55 ) GROUP-AGGREGATION ( ITEM_SIZE: 56, GROUP_COUNT: 16, BUCKET_COUNT: 1024, ACCESS: 16, SELF_ID: 2, REF_ID: 1 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 1 ) ------------------------------------------------------------ Explain Plan 391 GROUPING 정의 이 노드는 하위 노드으로부터 가져온 데이터가 이전 데이터와 동일한 그룹에 속하는지 검사한다. 형식 GROUPING 예제 각 사원이 담당하는 고객들의 수와 각 고객에게 판매한 상품의 총 수 를 출력하라. iSQL> SELECT eno, COUNT(DISTINCT cno), SUM(qty) FROM orders GROUP BY eno; ENO COUNT(DISTINCT CNO) SUM(QTY) ----------------------------------------------- 12 8 17870 19 5 25350 20 4 13210 3 rows selected. ----------------------------------------------- PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 24 ) AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 3 ) GROUPING SCAN ( TABLE: ORDERS, INDEX: ODR_IDX1, ACCESS: 30, DISK_PAGE_COUNT: 2, SELF_ID: 1 ) ----------------------------------------------- HASH 정의 이 노드는 Hash Search 기능을 수행하며, materialized node 이다. 형식 1) 중간 결과가 메모리에 저장될 경우 392 Administrator’s Manual HASH ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) 2) 중간 결과가 디스크에 저장될 경우 HASH ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장한 item의 개수 bucket_count hash bucket의 개수 page_count page의 개수 acc_num 레코드 접근 횟수 self_id tuple set 내의 ID. node ID로 봐도 무방 ref_id 참조하는 node의 ID 예제 모든 부서 관리자의 이름과 부서 이름을 출력하라. iSQL> CREATE TABLE manager( eno INTEGER PRIMARY KEY, mgr_no INTEGER, mname VARCHAR(20), address VARCHAR(60)) TABLESPACE user_data; Create success. iSQL> INSERT INTO manager VALUES(2, 1, 'HJNO', '11 Inyoung Bldg. Nonhyun-dong Kangnam-guSeoul, Korea'); 1 row inserted. iSQL> INSERT INTO manager VALUES(7, 2, 'HJMIN', '44-25 Youido-dong Youngdungpo-gu Seoul, Korea'); 1 row inserted. iSQL> INSERT INTO manager VALUES(8, 7, 'JDLEE', '3101 N. Wabash Ave. Brooklyn, NY'); 1 row inserted. iSQL> INSERT INTO manager VALUES(12, 7, 'MYLEE', '130 Gongpyeongno Jung-gu Daegu, Korea'); 1 row inserted. iSQL> SELECT m.mname, d.dname FROM department d, manager m WHERE d.mgr_no = m.mgr_no; MNAME DNAME ----------------------------------------------- HJNO Application Technology Team Explain Plan 393 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)를 처리하는 노드이다. 형식 1) 인덱스가 사용되는 경우 HIER ( TABLE: table_name, FULL SCAN, ACCESS: acc_num, SELF_ID: node_id ) 2) 인덱스가 사용되지 않는 경우 HIER ( TABLE: table_name, INDEX: index_name, ACCESS: acc_num, SELF_ID: node_id ) table_name 테이블 이름 FULL SCAN 인덱스 사용 안함 index_name 사용하는 인덱스 acc_num 레코드 접근 횟수 node_id tuple set 내에서의 ID (node의 ID로 간주) 예제 ID 칼럼의 값이 0인 행을 루트로 하여 계층적으로 연결된 행들을 얻 기 위한 계층적 질의문은 다음과 같다. iSQL> CREATE TABLE hier_order(id INTEGER, parent INTEGER); Create success. iSQL> INSERT INTO hier_order VALUES(0, NULL); 1 row inserted. 394 Administrator’s Manual i SQ L > I N S ER T I N T O h i e r_ o r d e r VAL U ES( 1 , 0 ); 1 ro w i n s e rt e d . i SQ L > I N S ER T I N T O h i e r_ o r d e r VAL U ES( 2 , 1 ); 1 ro w i n s e rt e d . i SQ L > I N S ER T I N T O h i e r_ o r d e r VAL U ES( 3 , 1 ); 1 ro w i n s e rt e d . i SQ L > I N S ER T I N T O h i e r_ o r d e r VAL U ES( 4 , 1 ); 1 ro w i n s e rt e d . i SQ L > I N S ER T I N T O h i e r_ o r d e r VAL U ES( 5 , 0 ); 1 ro w i n s e rt e d . i SQ L > I N S ER T I N T O h i e r_ o r d e r VAL U ES( 6 , 0 ); 1 ro w i n s e rt e d . i SQ L > I N S ER T I N T O h i e r_ o r d e r VAL U ES( 7 , 6 ); 1 ro w i n s e rt e d . i SQ L > I N S ER T I N T O h i e r_ o r d e r VAL U ES( 8 , 7 ); 1 ro w i n s e rt e d . i SQ L > I N S ER T I N T O h i e r_ o r d e r VAL U ES( 9 , 7 ); 1 ro w i n s e rt e d . i SQ L > I N S ER T I N T O h i e r_ o r d e r VAL U ES( 1 0 , 6 ) ; 1 ro w i n s e rt e d . i SQ L > SE L EC T i d , p a r e n t , l e v e l F R O M h i e r_ o r d e r ST A R T W I T H i d = 0 C O N N EC T B Y PR I O R i d = p a re n t O R D ER BY l e v e l ; I D PAR EN T L EVE L ----------------------------------------------- 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 1, 0 5, 0 6, 0 Level 2 1 루트/부모 부모/자식 자식/리프 부모/자식 Explain Plan 395 JOIN 정의 이 노드는 교차 곱(Cartesian Product )기능을 수행한다. JOIN 조건 은 right child가 수행한다. 형식 JOIN 예제 성(last name)이 ‘Marquez’인 직원의 직원 번호, 주문 번호, 상품 번호, 주문양을 출력하라. iSQL> SELECT e.eno, ono, cno, gno, qty FROM employees e, orders o WHERE e.eno = o.eno AND e.e_lastname = 'Marquez'; ENO ONO CNO GNO QTY --------------------------------------------------------------------------- 19 11290100 11 E11110000 1500 19 12100277 5 D111100008 2500 396 Administrator’s Manual 1 9 1 2 3 0 0 0 0 1 1 D 1 1 1 1 0 0 0 0 4 1 0 0 0 1 9 1 2 3 0 0 0 0 5 4 D 1 1 1 1 0 0 0 0 8 4 0 0 0 1 9 12300010 16 D111100010 2000 19 12310004 5 E111100010 5000 19 12310008 1 D111100003 100 19 12310011 15 E111100012 10000 19 12310012 1 C111100001 250 9 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 5, TUPLE_SIZE: 40 ) JOIN SCAN ( TABLE: EMPLOYEES E, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) SCAN ( TABLE: ORDERS O, INDEX: ODR_IDX1, ACCESS: 9, SELF_ID: 3 ) ------------------------------------------------------------ LEFT-OUTER-JOIN 정의 이 노드는 Left-Outer Join 기능을 수행하며, binary node 이다. 형식 LEFT-OUTER-JOIN 예제 모든 부서에 대한 부서 번호와 모든 사원 이름을 출력하라. (사원이 전혀 없는 부서 번호 5001도 출력된다.) iSQL> INSERT INTO departments VALUES(5001, 'Quality Assurance', 'Mokpo', 22); 1 row inserted. iSQL> SELECT d.dno, e.e_firstname, e.e_lastname FROM departments d LEFT OUTER JOIN employees e ON d.dno = e.dno ORDER BY d.dno; DNO E_FIRSTNAME E_LASTNAME Explain Plan 397 ------------------------------------------------------------ 1001 Ken Kobain 1001 Wei-Wei Chen 1002 Ryu Momoi 1002 Mitch Jones 1003 Elizabeth Bae 1003 Zhen Liu 1003 Yuu Miura 1003 Jason Davenport 2001 Takahiro Fubuki 3001 Aaron Foster 3002 Chan-seung Moon 3002 Farhad Ghorbani 4001 Xiong Wang 4001 Curtis Diaz 4001 John Huxley 4002 Gottlieb Fleischer 4002 Sandra Hammond 4002 Alvar Marquez 4002 William Blake 5001 20 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 46 ) LEFT-OUTER-JOIN SCAN ( TABLE: DEPARTMENTS D, INDEX: __SYS_IDX_ID_137, ACCESS: 9, SELF_ID: 1 ) SCAN ( TABLE: EMPLOYEES E, INDEX: EMP_IDX1, ACCESS: 20, SELF_ID: 2 ) ------------------------------------------------------------ LIMIT-SORT 정의 이 노드는 Limit Sorting을 수행한다. 모든 데이터를 저장 할 필요가 없으므로 일정한 저장 공간만을 사용하여 정렬한다.. 형식 398 Administrator’s Manual LIMIT-SORT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, STORE_COUNT: store_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장할 item의 개수 store_count 실제 정렬된 item의 개수 acc_num 레코드 접근 횟수 self_id tuple set 내의 ID, node ID로 봐도 무관 ref_id 참조하는 node의 ID 예제 모든 사원의 이름, 부서 번호 및 급여를 표시하고 부서 번호와 급여 를 기준(부서 번호는 올림차순, 그리고 급여는 내림차순으로)으로 정 렬해서 상위 10개만 출력하라. (ORDER BY 절의 목록의 순서가 정 렬 순서이다.) iSQL> SELECT e_firstname, e_lastname, dno, salary FROM employees ORDER BY dno, salary DESC LIMIT 10; E_FIRSTNAME E_LASTNAME DNO SALARY ------------------------------------------------------------------------- Wei-Wei Chen 1001 2300 Ken Kobain 1001 2000 Ryu Momoi 1002 1700 Mitch Jones 1002 980 Elizabeth Bae 1003 4000 Zhen Liu 1003 2750 Yuu Miura 1003 2003 Jason Davenport 1003 1000 Takahiro Fubuki 2001 1400 Aaron Foster 3001 1800 10 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 55 ) LIMIT-SORT ( ITEM_SIZE: 16, ITEM_COUNT: 20, STORE_COUNT: 10, ACCESS: 10, SELF_ID: 1, REF_ID: 0 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 0 ) ------------------------------------------------------------ Explain Plan 399 MATERIALIZATION 정의 뷰의 빠른 처리를 위해 생성되는 노드이다. 하위 VIEW node에 의해 생성된 레코드를 하나의 가상 테이블(즉 뷰)로 저장한다. 형식 MATERIALIZATION ( ACCESS: acc_num, SELF_ID: self_id ) acc_num 레코드 접근 횟수 self_id node ID 예제 자신이 속한 부서의 평균 급여보다는 많은 급여를 받고, 가장 높은 평균 급여를 갖는 부서의 평균 급여보다는 적게 받는 사원의 이름, 부서 번호, 급여를 출력하라. iSQL> CREATE VIEW v1 AS (SELECT dno, AVG(salary) avg_sal FROM employees GROUP BY dno); Create success. iSQL> SELECT e_firstname, e_lastname, e.dno, e.salary FROM employees e, v1 WHERE e.dno = v1.dno AND e.salary > v1.avg_sal AND e.salary < (SELECT MAX(avg_sal) FROM v1); E_FIRSTNAME E_LASTNAME DNO SALARY ------------------------------------------------------------------------- Wei-Wei Chen 1001 2300 Ryu Momoi 1002 1700 John Huxley 4001 1900 Sandra Hammond 4002 1890 Alvar Marquez 4002 1800 5 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 55 ) JOIN VIEW-SCAN ( VIEW: V1, ACCESS: 9, SELF_ID: 3 ) MATERIALIZATION ( ITEM_SIZE: 40, ITEM_COUNT: 9 ) VIEW ( ACCESS: 9, SELF_ID: 8 ) 400 Administrator’s Manual PR O J EC T ( C O L U M N _ C O U N T : 2 , T U P L E_ SI Z E: 2 5 ) AG G R EG AT I O N ( I T EM _ S I Z E: 7 2 , G R O U P_ C O U N T : 9 ) G R O U PI N G SC AN ( T AB L E: E M PL O YEES, I N D E X: E M P_ I D X1 , AC C ES S: 2 0 , SEL F _ I D : 2 ) SCAN ( TABLE: EMPLOYEES E, INDEX: EMP_IDX1, ACCESS: 19, SELF_ID: 1 ) ::SUB-QUERY BEGIN PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 23 ) STORE ( ITEM_SIZE: 32, ITEM_COUNT: 1, ACCESS: 14, SELF_ID: 12, REF_ID: 5 ) VIEW ( ACCESS: 1, SELF_ID: 11 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 23 ) GROUP-AGGREGATION ( ITEM_SIZE: 40, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 10, REF_ID: 5 ) VIEW-SCAN ( VIEW: V1, ACCESS: 9, SELF_ID: 5 ) ::SUB-QUERY END ------------------------------------------------------------ MERGE-JOIN 정의 이 노드는 Merge Join 기능을 수행한다. 형식 MERGE-JOIN 예제 2010년 1월 1일 이전에 입사한 모든 사원의 사원번호, 이름, 소속된 부서의 부서 번호와 부서 이름을 출력하라. (두 테이블 모두 조인 술 어와 관련된 칼럼에 인덱스가 존재하여야 한다. 인덱스 스캔을 하므 로 이 노드의 좌, 우 노드들(SCAN node)로부터 dno 값으로 정렬되 어 레코드가 반환된다. 따라서, 두 값의 대소 차이가 발생하는 이후 의 레코드는 검색하지 않고 다시 같은 값을 가지는 레코들를 만날 때 까지 두 테이블의 커서를 이동하여 검색한다.) iSQL> SELECT e.eno, e_lastname, d.dno, dname FROM employees e, departments d WHERE e.dno = d.dno Explain Plan 401 AND TO_CHAR(join_date, 'YYYY-MM-DD HH:MI:SS') < '2010-01-01 00:00:00'; ENO E_LASTNAME DNO DNAME --------------------------------------------------------------------------- 5 Ghorbani 3002 PRESALES DEPT 8 Wang 4001 MARKETING DEPT 18 Huxley 4001 MARKETING DEPT 7 Fleischer 4002 BUSINESS DEPT 12 Hammond 4002 BUSINESS DEPT 20 Blake 4002 BUSINESS DEPT 6 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 60 ) MERGE-JOIN SCAN ( TABLE: DEPARTMENTS D, INDEX: __SYS_IDX_ID_137, ACCESS: 9, SELF_ID: 3 ) SCAN ( TABLE: EMPLOYEES E, INDEX: EMP_IDX1, ACCESS: 19, SELF_ID: 2 ) ------------------------------------------------------------ PROJECT 정의 이 노드는 Projection 기능을 수행하며, 지정한 칼럼들을 추출해 낸 다. 형식 PROJECT ( COLUMN_COUNT: col_count, TUPLE_SIZE: tuple_size ) col_count 칼럼들의 개수 tuple_size projection에 의해 선택된 tuple의 실제크기 예제 전 사원의 급여를 10% 인상 시 전 사원의 이름과 급여를 출력하라. iSQL> SELECT e_firstname, e_lastname, salary * 1.1 FROM employees; E_FIRSTNAME E_LASTNAME SALARY * 1.1 ------------------------------------------------------------- . . 402 Administrator’s Manual . 2 0 r o w s s e l e c t e d . ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 3, TUPLE_SIZE: 67 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) ------------------------------------------------------------ SCAN 정의 이 노드는 Selection 기능을 수행하며, Key Range, Filter등을 사용 해 조건에 맞는 레코드를 테이블에서 검색한다. 형식 1) 중간 결과가 메모리에 저장될 경우 SCAN ( TABLE: table_name, FULL SCAN, ACCESS: acc_num, SELF_ID: node_id ) SCAN ( TABLE: table_name, INDEX: index_name, ACCESS: acc_num, SELF_ID: node_id ) 2) 중간 결과가 디스크에 저장될 경우 SCAN ( TABLE: table_name, FULL SCAN, ACCESS: acc_num, DISK_PAGE_COUNT: page_count, SELF_ID: node_id ) SCAN ( TABLE: table_name, INDEX: index_name, ACCESS: acc_num, DISK_PAGE_COUNT: page_count, SELF_ID: node_id ) table_name 테이블 이름 FULL SCAN 인덱스 사용 안함 index_name 사용하는 인덱스 acc_num 레코드 접근 횟수 page_count 페이지의 개수 node_id tuple set 내에서의 ID (node의 ID로 간주) 예제 예제1) 1980년 1월 1일 이전에 태어난 모든 사원들의 이름, 부서 번 호, 생일을 출력하라. iSQL> SELECT e_firstname, e_lastname, dno, birth FROM employees WHERE birth > '800101'; E_FIRSTNAME E_LASTNAME DNO BIRTH Explain Plan 403 --------------------------------------------------------------------- Aaron Foster 3001 820730 Gottlieb Fleischer 4002 840417 Xiong Wang 4001 810726 Sandra Hammond 4002 810211 Mitch Jones 1002 801102 Jason Davenport 1003 901212 6 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 54 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) ------------------------------------------------------------ 예제2) 1980년 1월 1일 이전에 태어난 모든 사원들의 이름, 부서 번 호, 생일을 출력하라. (인덱스를 이용하라.) iSQL> CREATE INDEX emp_idx2 ON employees(birth); Create success. iSQL> SELECT e_firstname, e_lastname, dno, birth FROM employees WHERE birth > '800101'; E_FIRSTNAME E_LASTNAME DNO BIRTH --------------------------------------------------------------------- Mitch Jones 1002 801102 Sandra Hammond 4002 810211 Xiong Wang 4001 810726 Aaron Foster 3001 820730 Gottlieb Fleischer 4002 840417 Jason Davenport 1003 901212 6 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 54 ) SCAN ( TABLE: EMPLOYEES, INDEX: EMP_IDX2, ACCESS: 6, SELF_ID: 2 ) ------------------------------------------------------------ SET-DIFFERENCE 정의 이 노드는 Set Difference 기능을 수행한다. 이 노드는 binary node 이며 materialized node 이다. 이 노드는 SQL문의 MINUS 처리에 사용된다. 404 Administrator’s Manual 형식 1) 중간 결과가 메모리에 저장될 경우 SET-DIFFERENCE ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, L_REF_ID: l_ref_id, R_REF_ID: r_ref_id ) 2) 중간 결과가 디스크에 저장될 경우 SET-DIFFERENCE ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, L_REF_ID: l_ref_id, R_REF_ID: r_ref_id ) item_size 저장하는 item의 크기 item_count 저장한 item의 개수 bucket_count hash bucket의 개수 page_count page의 개수 acc_num 레코드 접근 횟수 self_id node ID l_ref_id Left 참조 node ID. 만약 independent 하면 left-child의 data를 다시 저장할 필요가 없 음. r_ref_id Right 참조 node ID. 만약 independent 하면 right-child의 data를 다시 저장할 필요가 없 음. 예제 주문되지 않은 상품들의 상품번호를 출력하라. iSQL> SELECT gno FROM goods MINUS SELECT gno FROM orders; GNO -------------- A111100001 B111100001 C111100002 D111100001 D111100005 D111100006 D111100007 E111100006 D111100009 E111100003 Explain Plan 405 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처리를 위해 사용된다. 형식 1) 중간 결과가 메모리에 저장될 경우 SET-INTERSECT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, BUCKET_COUNT: bucket_count, ACCESS: acc_num, SELF_ID: self_id, L_REF_ID: l_ref_id, R_REF_ID: r_ref_id ) 2) 중간 결과가 디스크에 저장될 경우 SET-INTERSECT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, L_REF_ID: l_ref_id, R_REF_ID: r_ref_id ) item_size 저장하는 item의 크기 item_count 저장한 item의 개수 bucket_count hash bucket의 개수 406 Administrator’s Manual page_count page의 개수 acc_num 레코드 접근 횟수 self_id node ID l_ref_id Left 참조 node ID. 만약 independent 하면 left-child의 data를 다시 저장할 필요가 없 음. r_ref_id Right 참조 node ID. 만약 independent 하면 right-child의 data를 다시 저장할 필요가 없 음. 예제 goods 테이블에서 한 번이라도 주문된 아이템의 목록을 출력하라. iSQL> SELECT gno FROM goods INTERSECT SELECT gno FROM orders; GNO -------------- A111100002 E111100001 D111100008 D111100004 C111100001 E111100002 D111100002 D111100011 D111100003 D111100010 E111100012 F111100001 E111100009 E111100010 E111100007 E111100013 16 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 12 ) VIEW ( ACCESS: 16, SELF_ID: 2 ) SET-INTERSECT ( ITEM_SIZE: 32, ITEM_COUNT: 30, BUCKET_COUNT: 1024, ACCESS: 16, SELF_ID: 4, L_REF_ID: 0, R_REF_ID: 1 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 12 ) SCAN ( TABLE: GOODS, FULL SCAN, ACCESS: 30, SELF_ID: 0 ) PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 12 ) SCAN ( TABLE: ORDERS, FULL SCAN, ACCESS: 30, SELF_ID: 1 ) ------------------------------------------------------------ Explain Plan 407 SORT 정의 이 노드는 Sorting 기능을 수행하며 materialized node 이다. 형식 1) 중간 결과가 메모리에 저장될 경우 SORT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) 2) 중간 결과가 디스크에 저장될 경우 SORT ( ITEM_SIZE: item_size, ITEM_COUNT: item_count, DISK_PAGE_COUNT: page_count, ACCESS: acc_num, SELF_ID: self_id, REF_ID: ref_id ) item_size 저장하는 item의 크기 item_count 저장한 item의 개수 page_count page의 개수 acc_num 레코드 접근 횟수 self_id Tuple set 내의 ID (node ID로 봐도 무방) ref_id 참조하는 node ID로 Dependency 검사 대상 Node * Dependency란 Materialized node에 저장된 데이터의 유효성을 판단하는 기준이다. 만약 참조하는 node가 dependant node이면, 다시 수행하여 결과를 구해야 하며, independent node이면 결과가 동일할 것이기 때문에 다시 수행할 필요가 없다. 예제 월 급여가 $1500 USD 이하인 직원의 이름, 업무, 입사일, 급여를 급여 순서로 정렬하라. iSQL> SELECT e_firstname, e_lastname, emp_job, salary FROM employees WHERE salary < 1500 ORDER BY 4 DESC; E_FIRSTNAME E_LASTNAME EMP_JOB SALARY ---------------------------------------------------------------------------- Takahiro Fubuki PM 1400 Curtis Diaz planner 1200 Jason Davenport webmaster 1000 408 Administrator’s Manual M i t c h J o n e s P M 9 8 0 G o t t l i e b F l e i s c h e r m a n a g e r 5 0 0 5 ro w s s e l e c t e d . ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 4, TUPLE_SIZE: 70 ) SORT ( ITEM_SIZE: 16, ITEM_COUNT: 5, ACCESS: 5, SELF_ID: 3, REF_ID: 2 ) SCAN ( TABLE: EMPLOYEES, FULL SCAN, ACCESS: 20, SELF_ID: 2 ) ------------------------------------------------------------ VIEW 정의 In-line View들을 처리하기 위한 node 이다. 이 노드는 Projection에 해당하는 칼럼들을 연속된 칼럼으로 구성된 가상 레코드로 인식하도록 하기 위해서 사용된다. 형식 VIEW ( ACCESS: acc_num, SELF_ID: self_id ) acc_num 레코드 접근 횟수 self_id node ID 예제 자신이 속한 부서의 평균 급여보다 급여를 많이 받는 모든 사원의 이름, 급여, 부서 번호 및 그 부서의 평균 급여를 출력하라. iSQL> SELECT e.e_firstname, e.e_lastname, e.salary, e.dno, v1.salavg FROM employees e, (SELECT dno, AVG(salary) salavg FROM employees GROUP BY dno) v1 WHERE e.dno = v1.dno AND e.salary > v1.salavg; E_FIRSTNAME E_LASTNAME SALARY DNO SALAVG --------------------------------------------------------------------------- Wei-Wei Chen 2300 1001 2150 Ryu Momoi 1700 1002 1340 Explain Plan 409 Elizabeth Bae 4000 1003 2438.25 Zhen Liu 2750 1003 2438.25 John Huxley 1900 4001 1550 Sandra Hammond 1890 4002 1396.66667 Alvar Marquez 1800 4002 1396.66667 7 rows selected. ------------------------------------------------------------ PROJECT ( COLUMN_COUNT: 5, TUPLE_SIZE: 79 ) JOIN VIEW ( ACCESS: 9, SELF_ID: 3 ) PROJECT ( COLUMN_COUNT: 2, TUPLE_SIZE: 25 ) AGGREGATION ( ITEM_SIZE: 72, GROUP_COUNT: 9 ) GROUPING SCAN ( TABLE: EMPLOYEES, INDEX: EMP_IDX1, ACCESS: 20, SELF_ID: 2 ) SCAN ( TABLE: EMPLOYEES E, INDEX: EMP_IDX1, ACCESS: 19, SELF_ID: 1 ) ------------------------------------------------------------ VIEW-SCAN 정의 이 노드는 MATERIALIZATION node에 의해 생성된 가상 테이블(즉, 뷰)에 대한 scan 기능을 수행한다. 형식 VIEW-SCAN ( VIEW: view_name, SELF_ID: self_id ) view_name 뷰 이름 self_id node ID 예제 MATERIALIZATION Node 의 설명을 참고하기 바란다. 410 Administrator’s Manual PARTITION-COORDINATOR 정의 파티션드 테이블의 각각의 파티션에 대한 스캔을 관리하는 노드이다. 여러 개의 자식 노드를 가지며, 파티션 필터링을 수행한다. 형식 PARTITION-COORDINATOR ( TABLE: table_name, PARTITION: partition_acc_cnt, ACCESS: acc_num,SELF_ID: self_id ) table_name 테이블 이름 partition_acc_cnt 접근한 파티션의 개수 acc_num 접근한 레코드의 개수 self_id node ID 예제 iSQL> CREATE TABLE t1 ( i1 INTEGER ) PARTITION BY RANGE ( i1 ) ( PARTITION p1 VALUES LESS THAN ( 100 ), PARTITION p2 VALUES LESS THAN ( 200 ), PARTITION p3 VALUES DEFAULT ) TABLESPACE SYS_TBS_DISK_DATA; Create success. iSQL> INSERT INTO t1 VALUES ( 50 ); 1 row inserted. iSQL> INSERT INTO t1 VALUES ( 60 ); 1 row inserted. iSQL> INSERT INTO t1 VALUES ( 150 ); 1 row inserted. iSQL> INSERT INTO t1 VALUES ( 160 ); 1 row inserted. iSQL> alter session set explain plan = on; Alter success. iSQL> SELECT COUNT(*) FROM t1 WHERE i1 < 100; COUNT ----------------------- 2 1 row selected. Explain Plan 411 -------------------------------------------------------- PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 8 ) GROUP-AGGREGATION ( ITEM_SIZE: 24, GROUP_COUNT: 1, BUCKET_COUNT: 1, ACCESS: 1, SELF_ID: 4, REF_ID: 2 ) PARTITION-COORDINATOR ( TABLE: T1, PARTITION: 1/3, ACCESS: 2, SELF_ID: 2 ) SCAN ( PARTITION: P1, FULL SCAN, ACCESS: 2, DISK_PAGE_COUNT: 2, SELF_ID: 3 ) -------------------------------------------------------- Explain Plan 413 414 Administrator’s Manual 13. SQL Plan Cache 이 장은 알티베이스 SQL Plan Cache 기능에 대한 개념 및 특징에 대해 설명한다. SQL Plan Cache 415 개요 알티베이스 SQL Plan Cache 기능의 목적은 SQL 문 수행시 필요한 실행 계획을 공유하는데 있다. 공유된 실행 계획(SQL Plan)이 실행될 때에는 Execution Context (이전에 실행되었던 상황에 대한 정보)가 재사용될 수 있다. SQL Plan Cache의 구조 S Checkpoint Image Stable Log Disk Tablespace Shared SQL Plan Cache Stored Procedure Cache Meta Cache Memory TablespaceLog BuferDisk Bufer Stable Storage Physical MemoryCache [그림 13-1] 알티베이스 공유 캐쉬 구성도 알티베이스는 모든 세션이 공유하는 캐쉬(cache) 영역을 가지고 있다. 캐쉬 영역은 SQL Plan Cache, Stored Procedure Cache, Meta Cache로 구성된다. 새로운 SQL 실행 계획이 생성될 때마다 실행 계획은 SQL Plan Cache 영역에 저장되며 모든 세션이 이를 공유하게 된다. 저장 프로시저의 실행 계획이 새로 생성될 때 Stored Procedure Cache 영역에 저장되어 공유된다. 데이터베이스 객체에 대한 모든 정보를 수록하고 있는 메타 데이터는 빠른 접근을 위해서 Meta Cache에 저장된다. 장점 416 Administrator’s Manual 알티베이스 SQL Plan Cache를 사용함으로써 다음과 같은 몇 가지 장점을 얻을수 있다. Direct Execution 의 성능 향상 (Direct Execution은 SQL문을 수행하는 가장 기본적인 방법이다. 응용프로그램은 SQL문을 가지는 문자열을 만들어 이를 SQLExecDirect 함수를 사용해서 실행한다.) Direct Execution 위주의 퀴리가 자주 발생하는 환경에서는 이미 prepare가 된 플랜이 공유되어 재사용되기 때문에 prepare 비용을 줄일수 있어 성능이 향상된다. Prepare Execution만 사용하는 환경에서 Prepare Memory의 대폭적인 절감 (Prepare Execution은 반복 수행되는 SQL 구문의 수행 비용을 줄일 수 있는 방법이다.) 또한 Prepare Execute만 쓰는 환경에서는 prepare 비용 절감뿐 아니라 prepare에 필요한 메모리까지 줄일 수 있는 효과를 얻는다.. SQL Plan Cache 사용 구문 SQL Plan Cache 기능이 적용되는 SQL 구문은 다음과 같다. 각 구문에 대한 상세한 설명은 SQL Reference 를 참조한다. SELECT (SELECT FOR UPDATE) INSERT (INSERT SELECT) UPDATE DELETE MOVE ENQUEUE DEQUEUE SQL Plan Cache 417 SQL Plan Cache의 특징 알티베이스 SQL Plan Cache의 특징을 살펴보면 다음과 같다. 플랜 공유에 중점을 둔 체크-인(check-in) 방식이 사용된다. SQL Plan Cache의 교체 정책은 최근 사용도뿐만 아니라 참조횟수(frequency)까지 고려한다. 파싱 비용을 줄이기 위해서 SQL 문장이 반드시 같아야 plan cache의 execution plan 이 사용될 수 있다. 플랜 공유에 중점을 둔 체크-인 방식이란, 알티베이스의 SQL Plan Cache가 플랜 공유에 중점은 둔 등록 방식을 사용한다는 의미이다. 즉, 새로운 공유 Plan은 SQL_PLAN_CACHE_SIZE 프로퍼티에서 정의한 크기를 넘지 않는 범위 내에서 SQL Plan Cache에 등록될 수 있다. 만약 새로운 plan이 등록될 경우 SQL_PLAN_CACHE_SIZE 프로퍼티에서 정의한 크기를 넘는다면, 사용하지 않는 오래된 plan이 있는지를 확인하여 이를 삭제한 후 새로운 plan을 등록한다. 그러나 새로운 plan이 등록될 경우, SQL_PLAN_CACHE_SIZE 프로퍼티에 정의한 크기를 초과할 뿐만 아니라 SQL Plan Cache내의 Plan들이 다른 구문들에 의해 모두 참조되고 있다면, 새로운 plan은 등록될 수 없다. SQL Plan Cache에 Plan을 등록하지 못하는 경우, V$SQL_PLAN_CACHE 성능 뷰의 CACHE_IN_FAIL_COUNT값이 증가한다. SQL_PLAN_CACHE_SIZE프로퍼티의 디폴트 값은 64MB이지만, 사용자가 임의로 지정할 수 있다. 또한 SQL Plan Cache의 교체 정책은 최근 사용도뿐 아니라 참조 횟수까지 고려하기 때문에, Cache가 부족할 경우에도 자주 참조되는 Plan Cache 객체는 보호된다. 그러나 SQL 문장의 형식뿐 아니라 인자 값도 반드시 같아야 공유된 plan cache가 사용될 수 있다. 그 이유는 SQL Plan Cache가 파싱 비용을 완전히 제거하는 방식으로 구현되었기 때문이다. 예를 들어 다음 두 문장은 SQL Plan Cache에서는 다른 것으로 간주된다. INSERT INTO T1 VALUES(1,2); INSERT INTO T1 VALUES(2,3); 이런 경우에 다음과 같이 질의를 작성하여 Plan Cache가 사용되도록 하면 성능을 향상시킬수 있다. INSERT INTO T1 VALUES(? , ?) 418 Administrator’s Manual SQL Plan Cache 관련 프로퍼티 SQL Plan Cache를 사용하기 위해서는 알티베이스 프로퍼티 파일 내의 몇몇 프로퍼티를 사용 목적에 맞게 수정해야 한다. SQL Plan Cache과 관련된 프로퍼티는 다음과 같다. 각 프로퍼티에 대한 상세한 설명은 General Reference 를 참조한다. SQL_PLAN_CACHE_BUCKET_CNT SQL_PLAN_CACHE_HOT_REGION_LRU_RATIO SQL_PLAN_CACHE_PREPARED_EXECUTION_CONTEXT_ CNT 서버/클라이언트 통신 419 14. 서버/클라이언트 통신 이 장은 알티베이스 데이터베이스 서버와 클라이언트 응용프로그램간의 접속 방법과 프로토콜을 설명한다. 420 Administrator’s Manual 통신 방법 네크워크 상의 서로 다른 두 컴퓨터에 존재하는 프로세스간의 통신 또는 같은 컴퓨터에 존재하는 프로세스간의 통신 방법에는 몇 가지가 있다. 이 절에서는 알티베이스 데이터베이스 서버와 클라이언트 응용프로그램에서 사용할 수 있는 통신 방법을 설명한다. 알티베이스에서 제공하는 통신 방법은 아래와 같다. TCP/IP Unix Domain 소켓 공유 메모리를 이용한 IPC TCP/IP Transmission Control Protocol/Internet Protocol (TCP/IP)은 산업계 표준 네크워크 프로토콜로 글로벌 인터넷을 구축하는데도 사용되었다. TCP는 두 네크워크 호스트간의 정확한 데이터 교환을 위한 프로토콜이고, IP는 패킷을 목적지까지 전송하는 역할을 하는 프로토콜이다. 알티베이스는 인터넷 프로토콜 버전 4(IPv4)와 인터넷 프로토콜 버전 6(IPv6)을 모두 지원한다. IPv6주소체계는 IPv4주소를 신규로 할당하는 것을 중단하는 시점에 대비하여 설계되었다. IPv4주소와 가장 큰 차이점은 IP주소 저장 공간의 길이가 32bit에서 128bit로 확대되어 보다 많은 인터넷 주소를 사용할 수 있다는 점이다. IPv6에 대한 자세한 정보는 Internet Protocol Version 6 (IPv6) Specification, RFC 2460 (http://tools.ietf.org/html/rfc2460)를 참고하기 바란다. IPv6 주소 표기법 IPv6 주소는 16bit크기의 16진수 8개가 콜론(:)으로 구분되어 표기된다. 다음은 유효한 IPv6 주소의 예이다: 2001:cdba:0000:0000:0000:0000:3257:9652 IPv6 주소내의 네 개의 0으로 표시된 부분은 각각 한 개의 0으로 줄여서 표기할 수 있거나 모두 생략할 수도 있다. 그러므로 다음의 IPv6 주소들은 모두 같은 주소를 나타낸다. 2001:cdba:0000:0000:0000:0000:3257:9652 2001:cdba:0:0:0:0:3257:9652 서버/클라이언트 통신 421 2 0 0 1 : c d b a : : 3 2 5 7 : 9 6 5 2 위 주소를 위한 URL 형식은 다음과 같다: http://[2001:cdba:0000:0000:0000:0000:3257:9652]/ 알티베이스는 RFC2732에 명세화된 표준 IPv6 주소 표기법을 지원한다. 알티베이스 데이터베이스 서버에 연결할 때, IPv6 주소는 사각 괄호([ ])로 감싸여야 한다. 다음은 알티베이스에서 유효한 IPv6 주소의 예이다: [::1] [2002:c0a8:101:1:216:e6ff:fed2:7aea] $ isql -s [2002:c0a8:101:1:216:e6ff:fed2:7aea] -u sys FE80로 시작하는 링크 로컬 주소의 경우, 영역 인덱스가 퍼센트 표시(%)로 구분되어 주소 뒤에 붙는다. 영역 인덱스는 링크 로컬 주소가 할당된 인터페이스를 위한 색인이다. 리눅스 시스템에서 알티베이스 서버에 연결하려면 링크 로컬 주소의 영역을 표시하는 영역 인덱스를 붙여야 한다. (예외로 JDBC 응용프로그램을 위해서는 영역 인덱스가 필요없다.) 영역 인덱스를 사용한 예는 다음과 같다: [fe80::221:86ff:fe94:f51f%eth0] $ isql -s [fe80::221:86ff:fe94:f51f%eth0] -u sys IP 스택 호스트 장비에는 여러 다른 프로토콜 스택8이 설치되어 있을 수 있다. 두 가지 프로토콜의 지원 여부에 따라 다음 세 타입의 IP 호스트로 구분된다. IPv4-only host IPv4 스택만 설치되어 있는 호스트. IPv4-only host에서는 IPv6 주소를 사용할 수 없다. IPv6/IPv4 host 듀얼 스택이 설치되어 있는 호스트로 IPv4와 IPv6 모두 지 원한다. IPv6-only host IPv6 스택만 설치되어 있는 호스트. IPv6-only host는 IPv4 주소를 지원하지 않는다. IPv6 클라이언트/서버 연결 “네트워크 연결”이란 둘 이상의 컴퓨터 사이에 네트워크를 통해서 접속과 통신을 수립하는 것을 말한다. 다음 표는 설치된 프로토콜 스택에 따라서 서버와 클라이언트 간 통신을 위해 사용될 수 있는 프로토콜 버전을 보여준다. 아래의 8 프로토콜 스택이란 계층화된 구조로 모여있는 프로토콜 집합의 소프트웨어적인 구현을 말한다. 422 Administrator’s Manual 표에서 Supportd (v6)는 IPv6를 지원하는 프로토콜 스택이 설치된 클라이언트/서버 호스트를 의미하며, 이 호스트는 IPv6 인터페이스를 사용해서 다른 호스트에 연결할 수 있다. IPv4-only 서버 듀얼 스택 서버 IPv6-only 서버 IPv4-only 클라이언트 Supported (v4) Supported (v4) Not supported 듀얼 스택 클라이언트 Supported (v4) Supported (v4, v6) Supported (v6) IPv6-only 클라이언트 Not supported Supported (v6) Supported (v6) Note: 알티베이스는 듀얼 스택 프로토콜을 제공하지 않는 Windows NT 5.2 이하 버전에서는 듀얼 스택 서버를 지원하지 않는다. 알티베이스는 SPARC SunOS 에서 IPv6-only 서버를 지원하지 않는다. 알티베이스의 IPv6 지원 ALTIBASE HDB 5.5.1 에서의 IPv6 지원은 위의 “IPv6 클라이언트/서버 연결” 절의 표에 잘 나타나 있다. 서버 IPv6를 사용하려면, altibase.properties 파일에서 NET_CONN_IP_STACK 프로퍼티를 1 또는 2로 설정해야 한다. 이 프로퍼티에 대한 자세한 설명은 General Reference를 참고하기 바란다. 클라이언트 IPv6 를 사용해서 접속하려면, DSN 속성을 IPv6 주소로 지정하거나, 또는 DSN 속성은 호스트 이름으로 명시하고 PREFER_IPV6 속성을 TRUE로 지정하면 된다. 호스트 이름을 지정할 경우, 알티베이스 클라이언트는 getaddrinfo() 호출로 반환되는 모든 IP 주소로의 접속을 연결이 성공할 때까지 시도한다. 한 개 이상의 IP 주소가 반환될 경우, 알티베이스 클라이언트는 PREFER_IPV6 속성에 의한 순서대로 각 IP 주소로의 연결을 시도한다. PREFER_IPV6 속성이 지정되지 않거나 FALSE로 지정한 경우, 먼저 IPv4 주소로 연결을 시도한다. 연결이 실패하면 클라이언트는 반환되었던 IPv6 주소로 접속을 시도할 것이다. PREFER_IPV6 속성을 TRUE로 지정하면, IPv6 주소로 먼저 접속을 시도한다. 이것이 실패하면 클라이언트는 반환되었던 IPv4 주소로의 접속을 시도한다. PREFER_IPV6 속성에 대한 자세한 설명은 ODBC Reference를 참고하기 바란다. 서버/클라이언트 통신 423 Unix Domain 소켓 유닉스 플랫폼 상에서 클라이언트와 알티베이스 데이터베이스 서버가 모두 동인한 장비에 설치되었을 때, 유닉스 도메인 소켓을 통신에 사용할 수 있다. 유닉스 도메인 소켓을 사용하면 TCP/IP 사용시보다 나은 성능을 낼 수 있다. 유닉스 도메인 소켓을 사용하려면, ODBC/CLI 응용 프로그램에서는 CONNTYPE 속성을 지정하고, 알티베이스 유틸리티에서는 ISQL_CONNECTION 환경 변수를 설정한다. 더 자세한 설명은 ODBC Reference 와 각각의 유틸리티에 대한 매뉴얼을 참고하기 바란다. 공유 메모리를 이용한 IPC 이 절에서는 알티베이스에서 제공하는 공유 메모리를 이용한 프로세스간 통신 (inter-process communication, IPC) 즉, 동시에 실행 중인 프로세스들 사이에서 데이터를 교환하는 방법에 대해서 설명한다. 클라이언트와 알티베이스 데이터베이스 서버가 동일한 장비에 설치되어 있는 경우, 이 통신 방법을 사용하면 클라이언트 응용프로그램은 보다 향상된 성능을 보여줄 것이다. 공유 메모리를 이용한 IPC는 최고의 성능을 제공하지만, 메모리를 추가로 더 많이 사용하게 된다. 이 통신 방법을 사용하려면, 먼저 다음을 수행해야 한다: altibase.properties 파일에서 관련 서버 프로퍼티를 설정한다. General Reference를 참고하기 바란다. ODBC/CLI 응용 프로그램에서는 CONNTYPE 속성을 지정하고, iSQL과 iLoader 같은 알티베이스 유틸리티에서는 ISQL_CONNECTION 환경 변수를 설정한다. 자세한 설명은 ODBC Reference 와 각각의 유틸리티 매뉴얼을 참고하기 바란다. 윈도우에서는 IPC로 알티베이스 데이터베이스 서버에 접속 시도시, TCP/IP도 사용된다. IPC로 연결할 때, 클라이언트는 다음 절차에 따라 TCP/IP 접속을 먼저 시도하고, 연결이 성공 한 후 IPC로 통신하게 된다. PREPER_IPV6 속성이 지정되지 않거나, FALSE로 지정된 경우, 클라이언트는 먼저 로컬 호스트의 IPv4 주소 (127.0.0.1)로 접속을 시도한다. 접속이 실패하면 다음으로 클라이언트는 해당하는 IPv6 주소 ([::1])로 접속을 시도한다. PREPER_IPV6 속성이 TRUE로 지정된 경우, 클라이언트는 424 Administrator’s Manual 먼저 IPv6 주소로 접속을 시도한다. 접속이 실패하면, 클라이언트는 IPv4 주소로 접속을 시도한다. 알티베이스의 보안 425 15. 알티베이스의 보안 이 장에서는 알티베이스의 보안을 위해 사용 가능한 방법들과 보안 모듈 사용 방법에 대해 설명한다. 426 Administrator’s Manual 보안의 개요 정보 보호의 중요성이 높아지고 개인 정보 등 민감하고 중요한 정보를 법령으로 제정하여 보호함에 따라 데이터베이스의 보안 관리 기능이 필수적으로 요구되고 있다. 데이타베이스의 보안은 의도하지 않은 내, 외부적 활동으로부터 데이타베이스를 보호하는 것을 목적으로 하며, 알티베이스에서는 사용자의 필요에 적합한 보안 모듈을 연동하여 데이터베이스를 효과적으로 보호할 수 있도록 보안 모듈 연동 기능을 제공한다. 이 장에서는 데이터 암호화를 위한 보안 모듈 연동 기능에 대해 설명한다. 알티베이스의 보안 모듈 연동 기능은 기존 알티베이스 시스템과의 독립적인 보안 모듈 구성과 응용 프로그램과의 완벽한 독립성을 바탕으로, 개인 정보 보호를 위한 강력한 암호화 관리를 지원한다. 알티베이스는 취약한 데이타베이스의 보안을 강화하기 위하여 신뢰할 수 있는 외부의 보안 모듈을 알티베이스의 시스템과 연동을 지원하면, 보안 모듈을 효과적으로 연동할 수 있는 인터페이스를 제공한다. 알티베이스는 보안 모듈을 통한 데이터 암호화, 접근 제어 및 감사 기능을 위한 기반 구조를 데이타베이스 레벨에서 지원한다. 보안과 관련된 모든 작업은 알티베이스 서버 내에서가 아니라 보안 모듈을 통해서 이루어진다. 암호화는 테이블의 칼럼을 대상으로 수행되며, 암호화가 적용된 칼럼의 데이터는 디스크뿐만 아니라 메모리 상에서도 암호화를 유지한다. 접근 제어 기능은 크게 보안 대상의 선정 과정과 보안 대상에 대한 접근 권한의 분류를 통해 객체에 대한 사용자의 접근 유효성을 판단하는 두 과정으로 나뉘어진다. 접근 제어의 대상은 테이블 내의 칼럼 단위로 설정되며, 보안이 설정된 칼럼에 대해 접근을 하기 위해서 각 사용자는 해당 객체에 대한 필요 접근 권한을 부여 받아야 한다. 보안 대상의 설정과 보안 대상의 접근, 암호화 작업에 대해서는 감사 기록이 남겨진다. 알티베이스가 제공하는 보안 관련 기능은 다음과 같다. 디스크 및 메모리의 데이타를 암호화하여 저장 관리 보안 권한에 따른 출력 데이타의 복호화 원래 데이터의 순서를 보장하는 인덱스 구성 알티베이스의 보안 427 암호 칼럼을 가지는 테이블의 이중화 가능 428 Administrator’s Manual 보안 기능의 구성 알티베이스와 보안 모듈은 서로 독립적이다. 암호 키, 보안 정책과 보안 권한에 대한 정보는 보안 모듈에서 별도로 관리한다. 보안 모듈이 연동되어 있지 않더라도, 알티베이스는 정상적으로 동작한다. 단, 암호 칼럼에 대한 질의 처리시 보안 모듈이 연동되어 있지 않으면, 해당 질의는 실패하게 된다. 알티베이스는 보안 모듈 관련 속성들의 설정과 SQL문 실행을 통해 보안 모듈을 연동한다. 알티베이스는 보안 모듈이 연동되는 과정에서 두 모듈 간의 연결의 유효성을 평가하여 해당 연결에 대한 신뢰성을 보장한다. 알티베이스는 자신이 가진 보안 모듈에 대한 정보(모듈 이름, 버전, 암호 칼럼들의 정보)와 보안 모듈이 가진 정보를 비교하여 보안 모듈과의 연결을 평가한다. 알티베이스에 연결하는 기존 응용프로그램을 수정할 필요 없이 데이터를 칼럼 단위로 암호화할 수 있다. 암호 칼럼의 생성 및 삭제는 SQL로 지원된다. 이 외의 기존 응용 프로그램에서 사용하는 질의를 변경할 필요는 없다. 보안 관련 알티베이스 메인 모듈의 역할은 다음과 같다. 데이터베이스 운영 중 보안 모듈 연동을 위한 환경변수 및 SQL 구문 지원 암호화된 데이타를 관리하기 위한 자료구조 및 메타 정보 지원 보안 관련 확장된 질의 구문 지원 이중화 지원 외부 보안 모듈의 역할은 다음과 같다. 암호화 알고리즘 설정 (암호화 알고리즘의 종류, 초기화 벡터 사용 여부 결정) 칼럼의 암호화 정보 설정 (암호화 알고리즘 선택, 암호화 및 복호화 권한 설정) 데이타의 암호화 및 복호화 접근 제어 설정 (IP 접근 제어, 사용자 접근 제어) 감사 (암호화 및 복호화 로그, 접근 제어 로그) 알티베이스의 보안 429 보안 모듈 연동 방법 이 절에서는 보안 모듈을 연동하기 위해 필요한 절차들을 설명한다. 하나의 서버에는 하나의 보안 모듈만 연동될 수 있다. 보안 모듈을 연동하기 위해서는 보안 모듈의 이름, 보안 모듈의 위치 경로, 암호화된 데이터의 순서가 원본 데이터의 순서와 같음을 보장하는 ECC알고리즘의 보안 정책 (알티베이스의 ECC 알고리즘은 Order Preserving Encryption방식이다)을 설정한다. 그 다음에 보안 모듈의 연동을 시작한다. 여기서 ECC란 Encrypted Comparison Code의 약자로 암호화된 데이터의 순서가 원본 데이터의 순서와 같음을 보장하는 해시값이다. ECC로부터 원본으로의 변환이 불가능한 단방향 해시 알고리즘을 적용하여 ECC를 구성한다. ECC는 DBMS내부에서 암호 컬럼에 대한 빠른 비교연산을 위해 이용되며, 관리자 또는 사용자에 노출되지 않는다. ECC알고리즘은 ECC를 생성하기 위해 적용된 해시 알고리즘을 의미한다. 외부 보안 모듈로부터 다양한 ECC알고리즘의 지원이 가능하며, 서버 단위로 하나의 ECC 알고리즘이 선택되어 적용된다. 보안 모듈을 알티베이스에 연동하려면 다음의 과정을 수행한다. 외부 보안 모듈 설치 알티베이스 환경 설정 보안 모듈 구동 암호 칼럼 생성 이 과정 중 외부 보안 모듈 설치 방법은 보안 모듈의 종류에 따라 다르므로 사용할 외부 보안 모듈의 설치 문서를 참고한다. 여기에서는 그 다음 과정인 알티베이스 환경 설정, 보안 모듈 구동 및 암호 칼럼 생성에 더하여 보안 모듈 종료와 암호 칼럼 해제에 대해서 설명한다. 알티베이스 보안 환경 설정 연동할 외부 보안 모듈의 경로를 알티베이스 속성 파일, $ALTIBASE_HOME/conf/altibase.properties에 다음과 같이 정의한다. SECURITY_MODULE_NAME = altibase SECURITY_MODULE_LIBRARY = libsecurity.so SECURITY_ECC_POLICY_NAME = ecc_policy1 430 Administrator’s Manual 프로퍼티의 값은 대, 소문자를 구별하므로 이에 주의해야 한다. SECURITY_MODULE_NAME프로퍼티는 외부 보안 모듈의 식별자로 보안 보듈에 따라 달리 설정한다. SECURITY_MODULE_LIBRARY는 설치된 외부 보안 모듈 라이브러리의 이름을 나타낸다. SECURITY_ECC_POLICY_NAME은 알티베이스 내부에서 보안 정책을 구분하기 위한 이름으로 반드시 정의해야 한다. 이 프로퍼티들의 값은 ALTER SYSTEM 구문으로 운영 도중에 설정하거나 변경할 수 있다. ALTER SYSTEM 구문으로 변경할 경우, SECURITY_MODULE_LIBRARY에는 파일의 절대 경로를 지정해야 한다. ALTER SYSTEM SET SECURITY_MODULE_NAME = 'altibase'; ALTER SYSTEM SET SECURITY_MODULE_LIBRARY = '/altibase_home/lib/libsecurity.so'; ALTER SYSTEM SET SECURITY_ECC_POLICY_NAME = 'ecc_policy1'; 알티베이스의 보안 431 보안 모듈 구동과 데이터 암호화 이 절에서는 보안 모듈 구동 및 데이터 암호화 방법에 대해 설명하고 관련 구문을 소개한다. 보안 모듈 구동 보안 모듈 관련 프로퍼티가 모두 설정되었다면 보안 모듈을 구동할 수 있다. 보안 모듈을 구동하면 내부적으로 다음 기능들이 수행된다. 1. 보안 모듈 인증 상호 허용되지 않은 보안 모듈을 사용할 수 없도록 인증한다. 2. 보안 모듈 초기화와 유효성 검사 보안 모듈 자체의 설정 파일이나 라이센스를 검사한다. 3. ECC 보안 정책 검증 보안 모듈에 프로퍼티로 설정된 ECC 보안 정책이 유효한지 검사 한다. ALTER SYSTEM START SECURITY 문으로 보안 모듈을 구동한다. 이 구문은 적절한 권한을 가진 관리자로 접속해서 실행해야 한다. 예제 1. 적절한 권한이 있는 관리자로 알티베이스에 접속한다. ISQL> CONNECT sys/manager 2. 보안 모듈 관련 프로퍼티를 설정한다. ISQL> ALTER SYSTEM SET SECURITY_MODULE_NAME = 'altibase'; ISQL> ALTER SYSTEM SET SECURITY_MODULE_LIBRARY = '/altibase_home/lib/libsecurity.so'; ISQL> ALTER SYSTEM SET SECURITY_ECC_POLICY_NAME = 'ecc_policy1'; 3. 보안 모듈을 구동한다. ISQL> ALTER SYSTEM START SECURITY; 4. 보안 모듈 구동 상태를 확인한다. iSQL> SELECT * FROM SYSTEM_.SYS_SECURITY_; MODULE_NAME MODULE_VERSION ECC_POLICY_NAME ECC_POLICY_CODE -------------------------------------------------------- altibase 1.0 ecc_policy1 abcde12345 432 Administrator’s Manual 보안 모듈 종료 보안 모듈 구동과 마찬가지로 보안 모듈을 종료하고자 할 때는 적절한 권한이 있는 관리자로 접속해야 한다. 그 다음에 다음 구문을 실행한다. ISQL> ALTER SYSTEM STOP SECURITY; 다음과 같이 보안 모듈 연동 상태를 확인할 수 있다. ISQL> SELECT * FROM SYSTEM_.SYS_SECURITY_; MODULE_NAME MODULE_VERSION ECC_POLICY_NAME ECC_POLICY_CODE -------------------------------------------------------- No rows selected. Note: 보안 모듈의 종료는 암호화 컬럼이 존재하지 않는 경우에만 수행할 수 있다. 암호 칼럼 생성 데이터를 보호해야 하는 중요한 칼럼의 경우, 칼럼을 암호화하여 데이터를 보호할 수 있다. CHAR, VARCHAR 두 가지 자료형에 대해 암호화를 지원한다. CREATE TABLE 문으로 칼럼 생성시 암호 칼럼으로 지정하여 생성하거나, ALTER TABLE 문으로 이미 생성된 테이블의 칼럼을 암호 칼럼으로 변경할 수 있다. 두 경우 모두 사용할 보안 정책 이름(SECURITY_ECC_POLICY_NAME)을 암호화할 칼럼의 ENCRYPT USING 절에 지정한다. 칼럼의 암호화 여부는 DESC 구문을 통해 확인할 수 있다. 구문 CREATE TABLE table_name (column_name datatype [ENCRYPT USING ‘policy_name’]); 주의사항 암호화된 칼럼의 데이타 타입을 변경할 수 없다. 예제 질의 1> 테이블 생성시에 empID1, ssn1칼럼을 암호 칼럼으로 지정한다. CREATE TABLE t1 (name1 varchar(5), empID1 varchar(10) ENCRYPT USING ‘policy_id’, 알티베이스의 보안 433 ssn1 char(12) ENCRYPT USING ‘policy_ssn’); 질의 2> 테이블에 암호 칼럼이 있는지 확인한다. ISQL> DESC t1 -------------------------------------------------------- NAME TYPE IS NULL -------------------------------------------------------- NAME1 VARCHAR(10) FIXED EMPID1 VARCHAR(8) ENCRYPT FIXED SSN CHAR(12) ENCRYPT FIXED 암호 칼럼으로 변경 일반 칼럼의 경우, ALTER TABLE 문을 사용하여 암호 칼럼으로 변경할 수 있다. 구문 ALTER TABLE table_name MODIFY (column_name [ENCRYPT USING ‘policy_name’]); 주의사항 1. 암호 칼럼을 다시 암호화할 수 없다. 2. 암호화된 칼럼의 데이타 타입을 변경할 수 없다. 예제 질의> 기존의 t1 테이블의 empID1 칼럼을 보안 정책 policy_ssn을 사용하여 암호 칼럼으로 변경한다. ALTER TABLE t1 MODIFY (empID1 ENCRYPT USING ‘policy_ssn’); 암호 칼럼의 해제 ALTER TABLE 구문을 사용하여 암호화된 칼럼을 일반 칼럼으로 변경할 수 있다. 구문 ALTER TABLE table_name MODIFY (column_name [DECRYPT]); 예제 질의> t1 테이블의 empID1 칼럼의 암호화 설정을 해제한다. 434 Administrator’s Manual AL T ER T AB L E t 1 M O D I F Y (e m p I D 1 D EC R YP T ); 알티베이스 튜닝 435 16. 알티베이스 튜닝 이 장에서는 서버의 성능 향상을 위해서 알티베이스가 제공하는 다음 두 가지 기능에 대해서 설명한다. 로그 파일 그룹 (Log File Group) 그룹 커밋 (Group Commit) 436 Administrator’s Manual 로그 파일 그룹 이 절에서는 알티베이스에서 제공하는 로그 파일 그룹 기능에 대해서 기술한다. 로그 파일 그룹의 개념 로그파일그룹은 여러 트랜잭션들의 로그가 동시에 여러 개의 로그파일에 기록될 수 있도록 하여 시스템의 성능을 향샹시킨다. 알티베이스는 기본적으로 로그파일들을 LOG_DIR프로퍼티에 설정된 하나의 디렉터리에서 관리한다. 그리고 그 로그파일들 중 오직 하나의 로그파일에 데이터베이스 서버 운영 중에 발생하는 로그가 기록된다. 트랜잭션의 영속성(Durability)보장을 위해서 로깅은 필수적이며, 일반적으로 여러 개의 트랜잭션이 동시에 수행되는 환경에서는 이와 같이 하나의 로그파일에 로그를 기록하는 과정에서 병목현상이 발생한다. 이러한 병목을 제거하기 위하여 알티베이스는 여러 개의 로그 파일 경로를 사용하는 로그파일그룹을 지원한다. 한 경로 내에서는 오직 하나의 로그파일에만 로그가 기록된다는 기존의 제약사항은 그대로 적용되지만, 이러한 로그 경로가 여러 개가 됨에 따라 동시에 로그가 기록되는 로그파일의 수도 여러개로 늘어난다. 이와 같이 하나의 로그 경로, 즉 여러 개의 로그파일을 지니는 로깅 시스템의 최소 단위를 로그파일그룹 (Log File Group, LFG)라고 칭한다. 앞으로는 설명의 편의를 위하여 로그파일그룹을 간략하게 LFG라고 통칭한다. 데이터베이스에 변경을 가하는 트랜잭션이 많고 트랜잭션의 커밋이 빈번하게 수행될수록, LFG를 여러 개로 구성함에 따른 성능향상이 더욱 두드러진다. LFG의 구성요소 하나의 LFG는 다음과 같은 구성 요소를 지닌다. 로그 파일 경로 (LOG_DIR 프로퍼티) LOG_DIR 프로퍼티는 로그 파일이 저장되는 디렉터리 경로를 지정한다. 이 디렉터리는 하나 혹은 그 이상의 로그 파일들이 존재한다. 알티베이스는 그 중 오직 하나의 로그파일에만 로그를 기록할 수 있다. 알티베이스 튜닝 437 아카이브 로그 파일 경로 (ARCHIVE_DIR 프로퍼티) 데이터베이스가 아카이브로그 모드로 운영중이라면, LOG_DIR 프로퍼티에 지정된 디렉터리에 위치하는 기록이 완료된 로그파일들은 ARCHIVE_DIR 프로퍼티에 지정된 디렉터리로 복사된다. 이러한 아카이브 로그파일은 데이터베이스 복구와 백업을 위해 사용된다. 이 프로퍼티의 수는 LOG_DIR프로퍼티의 수와 정확히 일치해야 한다. 아울러, LOG_DIR 프로퍼티가 여러 개인 경우 ARCHIVE_DIR 프로퍼티들은 LOG_DIR 프로퍼티 값과 순서대로 1:1로 매핑되도록 기술해야 한다. 하나의 LFG를 위해서 다음과 같은 세가지 종류의 쓰레드가 존재한다. 로그파일 생성 쓰레드 (Log File Creation Thread) 한 LFG 내의 기록 중인 로그 파일이 꽉 차게 되면, 알티베이스는 새로운 로그파일에 로그를 기록하기 시작한다. 이 때, 새로운 로그파일로의 교체가 필요한 시점에 알티베이스가 새로운 로그파일을 생성한다면, 로그를 기록하려는 트랜잭션은 로그파일이 생성되는 동안 아무 작업도 수행하지 못한 채로 기다려야 한다는 문제점이 발생한다. 이 쓰레드는 로그 기록을 계속하기 위한 새 로그파일이 필요한 시점 전에 로그파일을 미리 만들어 둔다. 참고로, 체크포인트 중에 더 이상 사용되지 않는 로그파일들을 별도로 분류하여 체크포인트가 완료되는 시점에 이를 삭제한다. 로그 플러시 쓰레드 (Log Flush Thread) 최근에 기록된 로그를 주기적으로 디스크로 기록하는 쓰레드이다. 트랜잭션이 커밋될 때, 알티베이스 트랜잭션은 이 쓰레드가 관련 로그를 벌써 디스크에 쓰지 않았는지 검사하고, 기록되지 않은 로그만 디스크에 쓰게 된다. 즉, 이 쓰레드는 주기적으로 로그를 디스크에 기록함으로써 트랜잭션이 커밋되는 시점에 디스크에 기록할 로그의 수를 줄여주게 된다. 아카이브 로그 쓰레드 (Archive Log Thread) 한 LFG 내에서 로그가 기록되고 있는 로그파일이 가득 차게 되면 다른 새로운 로그파일에 로그 기록이 계속된다. 이때, 아카이브 로그 쓰레드는 방금 전까지 로그가 기록되고 있던, 하지만 끝까지 다 기록되어 더이상 로그가 기록되지 않는 이전 로그파일을 아카이브 로그파일로 복사한다. 사용 예 438 Administrator’s Manual LFG에 관련된 프로퍼티는 아래의 3개가 있다. LOG_FILE_GROUP_COUNT LOG_DIR ARCHIVE_DIR LOG_FILE_GROUP_COUNT 프로퍼티는 기본으로 1로 설정되어 알티베이스는 한 개의 LFG만 사용하도록 설정된다. 그리고 LOG_DIR과 ARCHIVE_DIR프로퍼티를 사용해서 따로 로그 경로와 아카이브 로그 경로가 지정된다. 다음은 LFG를 한 개로 구성한 경우의 알티베이스 프로퍼티 파일의 일부를 보여준다. LOG_FILE_GROUP_COUNT = 1 # LFG의 수 LOG_DIR = ?/logs # 로그 경로 ARCHIVE_DIR = ?/arch_logs # 아카이브 로그 경로 물음표(“?”)는 알티베이스 홈($ALTIBASE_HOME) 디렉터리를 나타내므로, 로그가 기록되는 경로는 $ALTIBASE_HOME/logs가 된다. 데이터베이스를 생성한 후 로그 경로 안의 내용을 살펴보면 다음과 같이 logfile0부터 logfile2까지 세 개의 로그파일이 존재하는 것을 볼 수 있다. 이들 중 오직 하나의 로그파일에만 트랜잭션이 데이터베이스에 변경을 가하면서 발생하는 로그가 기록된다. -rw------- 1 kmkim kmkim 10485760 Jun 22 15:46 logfile0 -rw------- 1 kmkim kmkim 10485760 Jun 22 15:46 logfile1 -rw------- 1 kmkim kmkim 10485760 Jun 22 15:46 logfile2 다음은 LFG를 세 개로 구성한 경우의 알티베이스 프로퍼티 파일의 일부를 보여준다. LFG의 수를 지정하는 LOG_FILE_GROUP_COUNT 프로퍼티에 3을 설정하였다. 각각의 LFG에 대응하는 로그경로와 아카이브 로그 경로를 LOG_DIR과 ARCHIVE_DIR 프로퍼티에 세 개씩 기술하고 있다. LOG_FILE_GROUP_COUNT = 3 # LFG의 수(3) LOG_DIR = ?/logs1 # 로그 경로 ( LFG#0 ) LOG_DIR = ?/logs2 # 로그 경로 ( LFG#1 ) LOG_DIR = ?/logs3 # 로그 경로 ( LFG#2 ) ARCHIVE_DIR = ?/arch_logs1 # 아카이브 로그 경로 ( LFG#0 ) ARCHIVE_DIR = ?/arch_logs2 # 아카이브 로그 경로 ( LFG#1 ) ARCHIVE_DIR = ?/arch_logs3 # 아카이브 로그 경로 ( LFG#2 ) 위에 기술한 로그 디렉터리들은 사용자가 명시적으로 생성해 주어야 알티베이스 튜닝 439 한다. 여기에서 새로운 디렉터리들은 LFG가 한 개일 때와 마찬가지로 알티베이스 홈 경로인 $ALTIBASE_HOME에 생성되어야 한다. 첫 번째 로그파일그룹인 LFG#0는 첫 번째 디렉터리인 $ALTIBASE_HOME/logs1의 로그파일 중 하나에 로그를 기록한다. 다른 로그파일그룹은 각각 대응하는 디렉터리의 로그파일에 로그를 기록한다. 이와 같이 LFG를 여러 개로 운영할 경우, 트랜잰셕의 영속성(Durability)를 보장하기 위해서 트랜잭션은 항상 로그가 디스크에 반영(Sync)될 때까지 기다린다. 즉 항상 COMMIT_WRITE_WAIT_MODE가 1 상태로 서버가 운영된다. 로그파일그룹 최적화 LFG를 두 개 이상으로 사용하도록 설정한 경우, 다음과 같이 각 LFG의 로그 경로를 물리적으로 서로 다른 위치에 두면 하나의 디스크에 여러 LFG의 로그 기록 요청이 몰리는 것을 방지할 수 있다. 이와 같이 LFG를 물리적으로 서로 다른 디스크에 둘 경우 각각의 디스크가 동시에 I/O작업을 처리할 수 있어서 시스템의 성능이 한결 향상된다. LOG_FILE_GROUP_COUNT = 3 # LFG의 수(3) LOG_DIR = /disk1/logs # 로그 경로 ( LFG#0 ) LOG_DIR = /disk2/logs # 로그 경로 ( LFG#1 ) LOG_DIR = /disk3/logs # 로그 경로 ( LFG#2 ) ARCHIVE_DIR = /disk1/arch # 아카이브 로그 경로 ( LFG#0 ) ARCHIVE_DIR = /disk2/arch # 아카이브 로그 경로 ( LFG#1 ) ARCHIVE_DIR = /disk3/arch # 아카이브 로그 경로 ( LFG#2 ) 반면, 다음과 같이 하나의 디스크에 두 개 이상의 LFG를 두도록 구성하면 디스크의 I/O 처리량이 높아지게 되어 더 좋은 성능을 낼 수도 있다. 이와 같이 일반적으로 하나의 디스크에 두 개 이상의 LFG를 두는 것이 더 좋은 성능을 내지만, 하나의 디스크에 하나의 LFG를 둘 지, 아니면 둘 이상의 LFG를 둘 지는 시스템의 성능과 디스크의 I/O처리량, 및 시스템의 부하와 밀접한 연관이 있으므로, 실 상황에서 다양한 LFG 구성으로 직접 성능을 측정해 보는 것이 가장 좋다. 440 Administrator’s Manual L O G _ F I L E_ G R O U P_ C O U N T = 6 # L F G 의 수 ( 6 ) L O G _ D I R = / d i s k 1 / l o g s 1 # 로그 경로 ( LFG#0 ) LOG_DIR = /disk1/logs2 # 로그 경로 ( LFG#1 ) LOG_DIR = /disk2/logs1 # 로그 경로 ( LFG#2 ) LOG_DIR = /disk2/logs2 # 로그 경로 ( LFG#3 ) LOG_DIR = /disk3/logs1 # 로그 경로 ( LFG#4 ) LOG_DIR = /disk3/logs2 # 로그 경로 ( LFG#5 ) ARCHIVE_DIR = /disk1/arch1 # 아카이브 로그 경로 ( LFG#0 ) ARCHIVE_DIR = /disk1/arch2 # 아카이브 로그 경로 ( LFG#1 ) ARCHIVE_DIR = /disk2/arch1 # 아카이브 로그 경로 ( LFG#2 ) ARCHIVE_DIR = /disk2/arch2 # 아카이브 로그 경로 ( LFG#3 ) ARCHIVE_DIR = /disk3/arch1 # 아카이브 로그 경로 ( LFG#4 ) ARCHIVE_DIR = /disk3/arch2 # 아카이브 로그 경로 ( LFG#5 ) 로그파일그룹 할당 데이터베이스 시스템에 LFG가 한 개뿐일 때에는 모든 트랜잭션이 한 LFG에 로그를 기록한다. 하지만 LFG가 두 개 이상으로 구성된 경우에는 트랜잭션 로그들을 여러 개의 LFG에 골고루 분산시켜 주어야 한다. 한 트랜잭션의 모든 로그는 같은 LFG에 기록된다. 이와 같이, 하나의 트랜잭션에 로그를 기록할 LFG를 제공하는 것을 “트랜잭션에 LFG를 할당한다”라고 한다. 예를 들어 LFG가 LFG#0, LFG#1, LFG#2, LFG#3로 네 개로 구성된 경우 트랜잭션에 LFG를 어떻게 할당하는지 알아보자. 디스크 테이블을 변경한 적이 있는 디스크 트랜잭션들의 경우, 첫 번째 LFG인 LFG#0 을 할당받는다. 메모리 테이블만 변경한 메모리 트랜잭션들의 경우 LFG#1, LFG#2, LFG#3을 번갈아가면서 할당받는다. 메모리 트랜잭션이 디스크 테이블을 변경하여 디스크 트랜잭션이 되는 경우, 해당 트랜잭션은 사용중이던 LFG를 반납하고 LFG#0을 할당받는다. 이 트랜잭션들 외에 이미 삭제된 행들을 찾아서 공간을 반납하는 가비지 컬렉션 트랜잭션과 체크포인트 관련 트랜잭션은 LFG#0을 할당받는다. 한계와 제약사항 알티베이스 튜닝 441 LFG기능의 한계점 디스크 테이블을 한 번이라도 변경한 적이 있는 디스크 트랜잭션의 경우, 첫 번째 LFG만 할당받기 때문에, LFG의 개수가 늘어나더라도 디스크 트랜잭션의 성능이 향상되지는 않는다. 단, LFG를 두 개로 구성 하였을 때, 메모리 트랜잭션과 디스크 트랜잭션의 로그가 두 개의 LFG로 분산되기 때문에 LFG가 한 개일 때에 비해 디스크 트랜잭션의 성능이 올라갈 수 있다. LFG 기능의 제약사항 COMMIT_WRITE_WAIT_MODE가 1로 설정된 것 처럼 데이터베이스 시스템이 운영된다. 사용자가 이 프로퍼티를 0으로 설정하여도 서버는 1로 운영을 하여 트랜잭션 커밋(Commit)시 트랜잭션은 커밋 로그가 디스크에 반영될 때까지 기다린다. 데이터베이스를 생성하고 나면, LFG의 개수를 변경할 수 없다. 하지만, LFG의 로그 경로와 아카이브 로그 경로는 데이터베이스 생성 이후에도 변경이 가능하다. 서로 다른 LFG가 동일한 로그 경로를 공유해서는 안된다. 즉, 각 LFG의 로그 경로는 서로 달라야 한다. 서로 다른 LFG가 동일한 아카이브 로그 경로를 공유해서는 안된다. 즉, 각 LFG의 아카이브 로그 경로는 서로 달라야 한다. 442 Administrator’s Manual 그룹 커밋 이 절에서는 트랜잭션 처리 성능 향상을 위해서 알티베이스가 제공하는 그룹 커밋 기능에 대해서 설명한다. 그룹 커밋의 개념 그룹 커밋은 여러 트랜잭션들의 커밋 요청을 모아서 한번에 처리하여 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대기시간을 튜닝하는 방법에 대해서는 알티베이스 튜닝 443 본 장의 ‘그룹 커밋 관련 프로퍼티 튜닝’을 참조한다. 그룹 커밋이 지정되어 있다면, 어떤 트랜잭션이 커밋을 위해 로그를 디스크로 내릴지를 결정할 때, 다음의 단계대로 작업을 수행한다. 1. 이 트랜잭션이 디스크로 기록하려는 로그가 이미 다른 트랜잭션 에 의해 디스크로 내려간 경우, 디스크 I/O를 수행하지 않는다. 그렇지 않을 경우, 2번을 수행한다. 2. 데이터베이스에 변경을 가한 트랜잭션의 수가 LFG_GROUP_COMMIT_UPDATE_TX_COUNT 프로퍼티에 지 정된 값보다 작을 경우, 디스크 I/O를 수행하지 않고 대기한다. 그렇지 않을 경우 3번을 수행한다. 3. 가장 최근에 로그를 디스크로 기록한 이후로 LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정한 시간이 경과하지 않은 경우, 디스크 I/O를 수행하지 않고 대기 한다. 그렇지 않을 경우 4번을 수행한다. 4. 디스크 I/O가 발생한 시각을을 기록하고 디스크 I/O를 수행하 여, 모든 대기하던 로그를 디스크에 기록한다. 그룹 커밋 수행 단위 앞서 LFG(Log File Group, 로그파일 그룹)기능에서 살펴본 바와 같이, 트랜잭션이 기록한 로그를 디스크로 기록하는 작업은 LFG별로 각각 수행된다. 그러므로 그룹커밋도 서로 다른 LFG간에 영향을 받지 않고 별개로 진행된다. 그룹 커밋 관련 프로퍼티 COMMIT_WRITE_WAIT_MODE가 0으로 설정된 경우, 트랜잭션 커밋시에 커밋 로그가 디스크에 반영되는 것을 기다리지 않기 때문에 정전시의 영속성(Durability)은 보장되지 않는다. 그룹 커밋 기능은 트랜잭션의 영속성(Durability) 보장을 위한 디스크 I/O를 모아서 처리하는 최적화 기법이다. 그러므로 이는 COMMIT_WRITE_WAIT_MODE가 1로 설정되어 있을 경우에 의미가 있다. 이 프로퍼티가 1로 설정된 경우에만 트랜잭션 커밋시 커밋 로그가 디스크에 반영될 때까지 트랜잭션이 기다리기 때문이다. 그룹 커밋시 고려사항 444 Administrator’s Manual 그룹 커밋은 여러 트랜잭션이 동시에 커밋을 하려고 할 때에만 그 효과를 발휘한다. 예를 들어 시스템상에 오직 하나의 트랜잭션만이 커밋하려고 하는 경우, 즉 커밋하려는 다른 트랜잭션이 존재하지 않는 경우, 이 때에는 함께 모아서 디스크 I/O를 처리할 트랜잭션이 없다. 이런 경우 그룹커밋을 하지 않고 바로 디스크 I/O를 수행하는 것이 더 좋은 성능을 낸다. 앞서 ‘그룹 커밋 수행 단위 ’에 기술한 바와 같이, 그룹 커밋은 LFG별로 독립적으로 이루어진다. 그룹 커밋을 수행할지의 여부도 LFG별로 그 LFG내에 커밋되지 않은 트랜잭션의 개수를 기반으로 독립적으로 결정하게 된다. 알티베이스는 데이터베이스에 변경을 가한 트랜잭션 수를 각 LFG별로 센다. DBA는 시스템의 특성을 고려해 LFG_GROUP_COMMIT_UPDATE_TX_COUNT의 최적값을 찾아야 한다. 이 프로퍼티의 기본값은 80이다. 그룹 커밋은 시스템이 특정 시간동안 가능한한 많은 트랜잭션의 커밋 요청을 처리할 수 있도록 돕는다. 하지만 그룹 커밋을 사용할 경우 여러 트랜잭션의 커밋 요청을 몰아서 한번에 처리하기 때문에, 개별 트랜잭션에 대한 응답 시간은 그룹 커밋을 사용하지 않을 때보다 길어질 수 있다. 그룹 커밋 관련 통계치 알티베이스는 DBA가 그룹 커밋의 동작을 모니터링 할 수 있는 통계치를 제공한다. 그룹 커밋은 LFG별로 독립적으로 이루어지기 때문에, 그룹 커밋의 통계치는 V$LFG성능 뷰에 존재한다. V$LFG성능 뷰의 그룹 커밋 관련 통계값들은 다음과 같다. UPDATE_TX_COUNT 해당 LFG에 속한 트랜잭션중 데이터베이스에 변경을 가한 트랜잭션의 개수를 실시간으로 보여주는 통계치이다. 이 값이 LFG_GROUP_COMMIT_UPDATE_TX_COUNT 프로퍼티에 설정된 값보다 클 때에만 해당 LFG에 대해 그룹 커밋을 실시한다. GC_WAIT_COUNT 이 통계값은 가장 최근 디스크 I/O 발생 이후 디스크 I/O가 연기된 회수를 보여준다. 이 카운트는 LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정한 만큼의 시간이 지나지 않아서 디스크 I/O를 수행하지 못할 때마다 1씩 증가한다. 알티베이스 튜닝 445 GC_ALREADY_SYNC_COUNT 트랜잭션이 커밋을 위해 디스크로 기록해야 하는 로그의 내용이 이미 다른 트랜잭션에 의해 디스크로 기록된 경우에는 추가적인 디스크 I/O를 수행할 필요가 없다. 이와 같이 디스크 I/O를 수행하지 않고 바로 커밋 완료 응답 신호를 보내는 경우에 1씩 증가하는 카운트 값이다. GC_REAL_SYNC_COUNT 실제 디스크 I/O를 수행하여 로그를 디스크로 기록한 경우 1씩 증가되는 카운트 값이다. 이는 다음 두 가지 경우 중 하나일 때 증가된다. -하나의 트랜잭션이 커밋을 위해 로그를 디스크로 기록하려 하려는 시점에 V$LFG 성능 뷰의 UPDATE_TX_COUNT 값이 LFG_GROUP_COMMIT_UPDATE_TX_COUNT 프로퍼티의 값보다 작으면 그룹 커밋 기능이 활성화 되지 않고, 따라서 직접 로그 기록을 위한 디스크 I/O를 수행한 경우 -그룹 커밋이 활성화된 상황에서 마지막으로 디스크 I/O를 수행한 시각 이후로 LFG_GROUP_COMMIT_INTERVAL_USEC 프로퍼티에 지정한 만큼의 시간이 지나서 실제 디스크 I/O를 수행한 경우 그룹 커밋 관련 프로퍼티 튜닝 그룹 커밋 기능을 이용하기 위해서는 시스템 자체의 성능과 다수의 커밋하려는 트랜잭션이 발생하는 상황에서의 시스템의 부하를 종합적으로 고려하여 관련 프로퍼티를 최적값으로 설정해야 한다. 이 절에서는 각각의 그룹 커밋 관련 프로퍼티값을 튜닝하는 방법에 대해 알아본다. LFG_GROUP_COMMIT_UPDATE_TX_COUNT 이 프로퍼티의 값이 너무 작으면 데이터베이스에 변경을 가한 트랜잭션 수가 그다지 많지 않아도 그룹 커밋이 활성화된다. 이 경우, 로그를 기록하기 위한 디스크 I/O의 횟수가 증가하여 시스템 성능이 저하된다. 반면, 이 프로퍼티의 값이 너무 크면 비록 데이터베이스에 변경을 가한 트랜잭션의 수가 충분히 많더라도 그룹커밋이 활성화되지 못한다. 데이터베이스 시스템에 여러개의 트랜잭션이 몰리는 때에 DBA는 V$LFG 성능 뷰의 UPDATE_TX_COUNT 값을 실시간으로 모니터링 하여 이 프로퍼티의 값을 적정한 값으로 결정하면 된다. LFG_GROUP_COMMIT_INTERVAL_USEC 이 프로퍼티의 값이 너무 작으면 빈번하게 디스크 I/O가 446 Administrator’s Manual 수행되어 시스템 성능이 저하된다. 이러한 상황에서는 커밋을 위해 실제로 디스크 I/O를 수행하는 횟수가 많아지므로 V$LFG 성능 뷰의 GC_REAL_SYNC_COUNT 값이 빠른 속도로 증가한다. 반대로, 이 프로퍼티의 값이 너무 크면 이용 가능한 디스크 I/O 용량이 충분히 활용하지 못하여 시스템의 성능이 저하된다. 이러한 상황에서는 디스크 I/O를 위해 대기하는 횟수가 많아지므로 V$LFG 성능 뷰의 GC_WAIT_COUNT 값이 빠른 속도로 증가한다. 이 프로퍼티를 최적으로 설정하려면 우선 이 프로퍼티의 값을 기본값인 1000 (1ms)에서부터 시작하여 2배씩 증가시켜가면서 시스템의 전체 성능 (TPS - Transaction Per Second)을 측정해 본다. GC_REAL_SYNC_COUNT의 값이 점점 작아지면서 최적의 성능을 낼 때 이 프로퍼티가 최적화 됐음을 의미한다. GC_REAL_SYNC_COUNT의 값이 작아지는 것이 곧 최적의 성능을 내는 상황을 의미하지는 않는다. 앞서 설명한 대로 이 프로퍼티의 값이 너무 크면 커밋을 하려는 트랜잭션들이 디스크 I/O를 위해 불필요하게 많은 시간을 기다리게 되어 디스크 I/O를 수행할 수 있는데도 디스크 I/O를 수행하지 않고 대기하는 상황이 발생하기 때문이다. 이 경우에는 위와 같은 방법으로 기본값인 1000에서 절반씩 감소시켜 가면서 최적의 TPS를 내는 상황을 찾아낸다. LFG_GROUP_COMMIT_RETRY_USEC 이 프로퍼티의 값이 너무 작으면 디스크 I/O를 대기하는 트랜잭션들이 더 빈번하게 깨어나서 디스크 I/O를 수행해야 하는지 체크하게 된다. 이 경우 개별 트랜잭션의 커밋에 대한 응답시간은 짧아질 수 있지만, 디스크 I/O가능 여부 체크를 너무 빈번하게 하게 되어서 CPU 사용율이 높아지게 된다. 또한 이러한 상황에서는 빈번하게 디스크 I/O가능 여부를 체크한후 디스크 I/O를 위한 대기상태로 들어갈 수 있기 때문에 이 프로퍼티의 값이 클 때에 비해서 V$LFG 성능 뷰의 GC_WAIT_COUNT 값이 빠른 속도로 증가할 것이다. 반면, 이 프로퍼티의 값이 너무 크면 디스크 I/O를 대기하는 트랜잭션들이 디스크 I/O가 가능한지의 여부를 체크하는 횟수가 줄어들게 되며, CPU사용율이 낮아지게 된다. 하지만 디스크 I/O 가능 여부를 체크하기까지의 대기시간이 길어져서 개별 트랜잭션의 커밋에 대한 응답시간은 길어진다. DBA는 이 프로퍼티의 값을 변경할 때, Unix의 top 명령이나 Windows의 작업관리자를 통해 알티베이스 프로세스의 CPU 사용율을 모니터링하거나 개별 트랜잭션의 응답시간의 평균값을 측정하는 방법으로 이 프로퍼티 값을 최적의 값으로 설정할 수 알티베이스 튜닝 447 있다. 알티베이스 진단 모니터링 449 17. 알티베이스 진단 모니터링 이 장에서는 알티베이스 데이터베이스의 운영 상태를 확인하고 분석하는 방법에 대해 설명한다. 450 Administrator’s Manual 알티베이스 모니터링 알티베이스 데이터베이스의 운영 상태를 확인하기 위해서는 성능 뷰를 이용한다. 성능 뷰에 대한 자세한 설명은 General Reference의 데이터 딕셔너리 장의 오류! 참조 원본을 찾을 수 없습니다.를 참조하기 바란다. 모니터링 해야할 주된 개체는 다음과 같다. 세션과 Statement 알티베이스 운영 중 연결되어 있는 세션에 대한 정보를 성능 뷰로 확인한다. 하나의 세션에는 여러 개의 Statement1가 할당될 수 있다. 세션 속성은 세션 별로 다르게 지정될 수 있다. 데이터베이스(테이블/인덱스) 정보 전체 데이터베이스에 대한 정보와 각 테이블스페이스, 테이블 및 인덱스 정보를 성능 뷰로 확인할 수 있다. 메모리 사용량 알티베이스 서버가 운영하면서 사용하는 메모리 영역 정보를 성능 뷰로 확인한다. 여기에는 메모리 테이블스페이스의 데이터(레코드의 예전 버전 포함) 저장 영역 및 인덱스 저장 영역, 질의 처리를 위한 임시 영역, 세션 정보 저장 공간, 메모리 버퍼 풀 등이 포함된다. 이중화 상태 이중화 상태 정보를 성능 뷰로 확인한다. 이중화 관련 쓰레드(Sender/Receiver)의 상태와 이중화 데이터 전송 상태를 확인할 수 있다. 1 Statement는 하나의 SQL문을 처리하기 위해 내부적으로 사용되는 객체이며 하나의 statement는 하나의 SQL문을 처리한다. 알티베이스 진단 모니터링 451 알티베이스 문제상황 분석 이 절은 알티베이스 운영 중 발생할 수 있는 여러 가지 문제 상황에 대한 점검 사항 및 분석 방법에 대해 설명한다. 실제 운영 환경에서는 다양한 형태의 문제가 발생되며 미리 형태를 예측할 수 없는 경우도 있으므로 반드시 여기서 설명하는 바와 같이 진행되는 것은 아니다. 하지만 예측 가능한 범위 내에서 형태별로 나누어 일반적인 방법을 제시하여 문제 상황에 대처할 수 있는 정보를 제공하고자 한다. 예측 가능한 문제 발생 형태는 크게 다음과 같이 생각해 볼 수 있다. 알티베이스 프로세스 비정상 종료 및 재구동시 문제 알티베이스 서버 응답 시간 문제알티베이스 서버 응답 시간 문제 디스크 사용량의 문제 메모리 사용량의 문제 CPU 사용량의 문제 이중화 문제 응용프로그램 및 쿼리 수행시 문제 일반적인 문제상황 분석(PBT, Problem Tracking) 절차는 다음과 같다. [그림 17-1] 일반적인 문제 분석 절차 문제 유형 판단 알티베이스 관리자 로그 (altibase_XXX.log) 확인 관련정보 수집 (알티베이스 모니터링 도구/시스템 모니터링 커맨드 사용) 원인 분석 및 문제해결 452 Administrator’s Manual 알티베이스 관리자 로그란 $ALTIBASE_HOME/trc 디렉터리에 생성되고 유지되는 “*.log” 이름을 가지는 파일의 텍스트 로그이다. 이 디렉터리에는 다음의 트레이스 로그 파일들이 있다. 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 the shmget() system function”와 같이 메모리 할당 관련 시스템 함수 호출 에러 메시지가 기록된다. 이 경우에는 현재 메모리 사용량을 점검해야 하며, 불필요하게 많이 사용하는 부분을 있는지 확인한다. 이러한 부분이 있다면 해당 부분의 메모리를 해제하여 메모리를 확보하고 과도한 메모리 사용의 원인을 찾아 재발을 방지해야 한다. 만일 불필요하게 사용하는 부분이 없다면 시스템 메모리 업그레이드를 고려해야 한다. 메모리 관련 문제는 다음 절에 나올 메모리 사용량의 문제에서 좀 더 자세히 설명하기로 한다. 알티베이스 재구동 실패 알티베이스 재구동 시 실패할 수 있는 원인으로 다음의 것을 생각해 볼수 있다. 동일한 서비스 포트 번호(PORT_NO 프로퍼티)를 사용하는 알티베이스 진단 모니터링 453 알티베이스 프로세스가 이미 존재하는 경우 구동 또는 회복 시 필요한 파일이 없거나 파일에 대한 권한이나 파일 시스템 문제로 인해 접근이 안 되는 경우 관리자 로그에 파일 접근 관련 에러가 발생한다면 해당 파일들(모든 로그 파일, 모든 로그 앵커 파일, 모든 데이터 파일)이 존재하는지를 확인한다. 파일이 존재하고 접근이 가능함에도 불구하고 에러가 발생한다면 파일이 깨졌을 가능성이 있으며 이 경우 데이터베이스를 새로 생성해야 한다. 공유메모리 모드로 사용 시 비정상 종료 후, 이전에 사용한 공유 메모리와 파일상의 데이터베이스 이미지가 호환이 안 되는 경우 공유메모리 호환 문제로 인해 재구동이 실패하는 경우 현재 공유메모리를 삭제하고 알티베이스를 다시 구동하여야 한다. 공유메모리를 삭제하려면 알티베이스 공유메모리 관리도구(shmutil)를 사용하거나 “ipcrm” 시스템 명령에 의해 가능하다. “ipcrm” 명령어를 사용하여 삭제할 공유메모리 정보는 삭제하기 전에 “ipcs” 명령어로 검색해 볼 수 있다. 시스템 리소스 부족 시스템 리소스 부족으로 인해 시스템 구동이 실패했다면, 여러 가지 시스템 리소스 중 어떤 리소스가 부족한지를 확인하여 실제 시스템에 적재되어 있는 리소스 가용량을 확인하고 시스템 커널 설정을 확인하여 문제가 있는 부분을 해결해야 한다. 구동 시 주로 문제가 되는 리소스는 메모리 또는 세마포어이다. 메모리 관련 문제의 경우 시스템 커널 설정에서 한 프로세스 당 사용 가능한 메모리의 크기, 사용 가능한 공유메모리 크기, 및 공유메모리 세그먼트의 최대 크기등을 확인해 봐야 한다. 알티베이스를 공유메모리 모드로 사용할 경우 STARTUP_SHM_CHUNK_SIZE 프로퍼티의 설정값이 사용 가능한 공유메모리 세그먼트의 최대크기를 넘으면 안된다. IPC 통신을 하려면 세마포어가 필요하며 이는 알티베이스 설정 중 IPC_CHANNEL_COUNT 프로퍼티와 관련이 있다. IPC 통신에 필요한 시스템 자원을 확인해 보기 위해서는 알티베이스에서 제공하는 checkipc 도구를 이용하면 된다. checkipc 도구를 이용하여 검사를 해보면 시스템의 어떤 항목이 얼마나 필요한지와 실제 커널의 설정값을 확인해 볼 수 있다. 이 값을 참조하여 알티베이스 설정과 시스템 커널 설정을 적절하게 조정하면 문제 해결이 가능하다. 알티베이스 서버 응답 시간 문제 알티베이스 서버가 실제로 질의를 처리하고 있지만 응답속도가 매우 늦다면 사용자는 서버가 응답이 없다고 오해할 수 있다. 454 Administrator’s Manual 질의 처리 요청 시 응답이 늦는 경우, 이유는 대부분 테이블을 풀스캔하하거나 메모리 부족으로 인해 스와핑이 발생하기 때문이다. 이 경우 세션정보 확인과 시스템 정보를 통해 해당 질의가 실제로 수행 중인지를 확인한다. CPU 사용량이 높거나 가용 메모리가 부족하여 스와핑이 발생한다면 실제로 질의를 처리하고 있는 경우일 가능성이 높다. 자세한 설명은 다음에 나올 “응용프로그램 및 쿼리 수행시 문제 ”에서 좀 더 자세히 설명하기로 한다. 또 다른 원인으로는 디스크 여유 공간이 부족하여 데이터 변경이나 입력 시 응답이 없는 경우를 생각할 수 있다. 이러한 경우에는 시스템 관리자 로그에 디스크의 여유 공간이 없음을 알리는 에러 메시지가 남게되며 디스크 공간이 확보되기 전까지 응답이 없는 상태로 남아있게 된다. 디스크 공간 부족으로 인한 문제 해결 방법은 다음에 나올 “디스크 사용량의 문제”에서 좀 더 자세히 설명하기로 한다. 이 외에 다른 문제로 알티베이스 서버가 응답이 없는 상태로 남아있다면 전문 시스템 엔지니어에게 문의해야 한다. 디스크 사용량의 문제 디스크 가용 공간 부족 알티베이스 운영 중에 디스크 공간이 부족하게 되면 알티베이스가 더 이상 데이터 변경작업을 하지 않고 멈춰있는 현상이 발생 할 수 있다. 이런 경우 먼저 여러 파일 시스템 중 어떤 곳의 공간이 부족한지를 확인해야 한다. 알티베이스가 운영 중에 사용하는 디스크 공간은 다음과 같다. 로그 파일 저장 공간 각 테이블스페이스 파일 저장 공간 알티베이스 운영 중에 액티브 로그와 아카이브 로그가 지속적으로 생성되며 액티브 로그 파일은 알티베이스 설정 파일(altibase.properties) 항목 중 LOG_DIR프로퍼티에 설정된 디렉터리에 저장이 되고 아카이브 로그 파일은 데이터베이스가 아카이브 로그 모드로 운영될 경우 자동으로 ARCHIVE_DIR 프로퍼티에 설정된 디렉터리에 저장된다. 액티브 로그의 경우는 디스크 공간이 부족하여 더 이상 로그 저장이 불가능해지면 알티베이스가 멈추게 된다. 이런 경우 로그 파일과 로그 앵커파일을 지우게 되면 복구가 불가능해지므로 해당 파일 시스템의 크기를 알티베이스 진단 모니터링 455 늘리거나 이외에 다른 불필요한 파일을 삭제하여 디스크 공간을 확보해야 한다. 아카이브 로그의 경우에는 설정 파일의 ARCHIVE_FULL_ACTION 프로퍼티 항목의 설정값이 0인 경우 아카이브 로그를 저장하지 않고 계속 운영되게 되며, 1인 경우 해당 파일 시스템의 가용공간이 확보될 때까지 알티베이스가 멈춰있게 된다. LOG_DIR 프로퍼티에 지정된 디렉터리에 로그 파일의 개수가 많아져 로그 저장 공간이 부족해 진 경우 먼저 관리자 로그 파일을 확인하여 체크포인트가 정상적으로 이루어 지고 있는지를 확인해야 하며 알티베이스 설정 파일 내에 CHECKPOINT_INTERVAL_IN_SEC 프로퍼티와 CHECKPOINT_INTERVAL_IN_LOG 프로퍼티의 설정이 적절한지 확인하여야 한다. 만일 체크포인트가 정상적으로 이루어 지고 있음에도 불구하고 아카이브 로그 파일들이 LOG_DIR 프로퍼티에 지정된 디렉터리에 계속 남아 있다면 이중화 전송 상태를 확인해 본다. 이중화 전송이 계속 밀리고 있거나 전송 불가능 상태라면 로그 파일들은 아카이브 되지 않거나 지워지지 않아서 LOG_DIR 프로퍼티에 지정된 디렉터리에 계속 보관되므로 로그 저장 공간이 부족해 질 수 있다. 이중화 관련 문제 해결 방법은 다음에 나올 “이중화 문제”에서 좀 더 자세히 설명하기로 한다 메모리 테이블스페이스와 각 시스템 테이블스페이스는 설정 파일내의 MEM_DB_DIR 프로퍼티에 설정된 디렉터리에 저장된다. 테이블스페이스 관련 디스크 부족 현상이라면 이 부분 또는 사용자가 생성한 테이블스페이스 파일이 저장된 공간을 확인해야 한다. 테이블스페이스를 저장하는 파일 시스템은 최소 해당 테이블스페이스가 증가되는 크기 이상의 여유 공간이 있어야 한다. 메모리 테이블스페이스의 저장 공간은 체크포인트가 수행될 때 실제로 기록이 되기 때문에 메모리 상에 존재하는 테이블스페이스 크기 이상의 여유 공간이 필요하다. 메모리 사용량의 문제 알티베이스 운영 중 가용메모리가 부족해 진다면 응답시간이 매우 느려질 수 있으며 알티베이스가 비정상적으로 종료될 수 있다. 이런 경우 알티베이스가 사용하고 있는 메모리 영역을 검사하여 해당 크기가 적절한지를 판단하고 불필요하게 사용되고 있는 부분을 제거해야 한다. 만일 불필요하게 사용하고 있는 영역이 없다면 메모리 증설을 고려 하여야 한다. 456 Administrator’s Manual 알티베이스가 운영 중에 사용하는 메모리 공간은 크게 나누어 보면 다음과 같다. 메모리 테이블스페이스 임시 메모리 공간 메모리 버퍼 메모리 테이블스페이스에는 메모리 테이블의 실제 레코드 및 MVCC 를 지원하는데 필요한 레코드의 이전 버전들이 저장된다. 임시 메모리 공간은 메모리 테이블에 생성된 테이블의 인덱스와 메모리 테이블 조회 시 레코드를 정렬하기 위한 공간, 세션들의 정보를 저장하는 용도 등으로 사용된다. 메모리 버퍼는 디스크 테이블 레코드에 대한 연산 및 정렬 등을 위해 사용되는 공간이다. 메모리 과다 사용이 의심된다면 일정기간 동안 생성되는 문장(statement)의 개수와 임시 메모리 영역의 크기, 메모리 테이블스페이스의 사용량, 및 메모리 테이블의 인덱스 크기 등을 모니터링 하여 증가량을 확인하여야 하며 이와 함께 “ps”나 “top”과 같은 시스템 모니터링 명령으로 프로세스의 크기가 지속적으로 증가되는 지 확인해 보아야 한다. 알티베이스가 처음 가동된 이후에 일정 기간 동안은 임시 메모리 영역 할당, 여러 이전 버전의 레코드 생성, 및 세션 정보의 증가로 인해 메모리 사용량이 증가할 수 있는데, 이는 정상이다. 그러나 만일 일정 기간 운영 이후에도 지속적으로 증가한다면 메모리 누수와 같은 이상이 있는지를 의심해 볼 수 있으며 이러한 경우 전문 시스템 엔지니어에게 문의를 해야 한다. CPU 사용량의 문제 갑자기 알티베이스의 CPU 사용량이 늘었다면 다음과 같은 상황들을 의심해 볼 수 있다. 메모리 테이블 질의 처리 시 인덱스를 사용하지 못함 디스크 테이블 질의 처리 시 디스크 사용 과다 메모리 부족으로 인한 스와핑 발생 시스템 성능 모니터링 도구를 이용하여 메모리 사용량을 확인하고 가용 메모리가 부족하여 스와핑이 발생한다면 추가 메모리를 확보해야 한다. 이에 대한 내용은 “메모리 사용량의 문제”에서 자세히 설명하였다. 메모리 부족 상항이 아니고 질의 처리 시 메모리 테이블 전체 알티베이스 진단 모니터링 457 스캔이나 디스크 테이블에서 디스크를 과다하게 사용한다면 해당 쿼리나 테이블 등을 튜닝하여 해결이 가능하다. 이에 대한 내용은 다음에 나올 “응용 프로그램 및 쿼리 수행시 문제”에서 좀 더 자세히 설명하기로 한다. 이중화 문제 이중화 관련하여 발생 할 수 있는 문제는 다음과 같은 것들이 있다. 이중화 시작 실패 이중화 반영 속도가 매우 느림 이중화 중인 테이블의 레코드 건수가 서로 틀림 이중화 전송에 문제가 발생되면 로그 저장 공간에 아카이브 로그 파일이 계속 남아있게 되어 가용 공간이 부족해지고 이로 인해 서비스가 안되고 알티베이스가 멈춰있는 현상이 발생될 수 있다. 이중화 관련 문제가 발생했다면 먼저 관리자 로그 파일에 이중화 관련 에러 메시지가 기록되어 있는지 확인하고 해당 내용을 전문 엔지니어에게 전달해야 한다. 한쪽 시스템에 장애가 발생하고 장애 상황이 장시간 지속되면 이중화 데이터 전송을 하지 못하여 로그 저장 디렉터리의 가용 공간이 부족해 지는 현상이 발생한다. 따라서 단시간 내에 문제 해결이 어려울 경우에는 이중화를 중단하고 이중화 객체를 삭제하여 현재 운영중인 시스템에 문제가 생기지 않도록 하는 것을 고려해야 한다. 이런 경우 장애 상황이 해제된 이후 장애 발생 시스템의 데이터 복구 작업이 추가적으로 필요하다. 데이터 복구 방법으로는 iLoader 도구를 이용하는 방법과 이중화를 SYNC 모드로 구동하는 방법이 있다. 만일 이중화 객체 삭제가 어려운 경우 로그 저장 디렉터리의 가용 공간을 지속적으로 확인하여 모자란 경우 확보를 해주어야 한다. 마찬가지로 이중화 네트워크 라인에 문제가 발생했다던지 이중화에 문제가 생겨 장시간 이중화가 연결되지 못하는 경우에도 동일한 조치가 필요하다. 응용프로그램 및 쿼리 수행시 문제 응용프로그램 및 쿼리 수행에 관한 문제 발생시 크게 다음 두 가지 상황을 생각해 볼 수 있다. 458 Administrator’s Manual 응용프로그램에서 알티베이스로의 접속 실패 응용프로그램에서 알티베이스로 쿼리 요청 이후 멈추어 있거나 정해진 시간 동안 처리하지 못하여 타임아웃 발생 알티베이스 접속 실패 응용프로그램에서 접속이 실패한다면 알티베이스 질의 처리 도구인 iSQL을 이용하여 접속을 시도해tj 정상적으로 접속이 되는지 확인한다. 알티베이스에서는 접속시 3가지의 접속 방식을 제공하기 때문에 (TCP/IP, socket domain, IPC) 응용프로그램에서 사용하고 있는 접속 방식을 사용하여 시험해봐야 한다. 접속 방식을 설정하는 방법은 ISQL_CONNECTION 환경변수를 지정하여 가능하다. (TCP, UNIX, IPC) 만일 iSQL로 접속이 성공한다면 응용프로그램 안에서 접속정보 설정 시 문제가 있는 것이므로 해당 부분의 오류를 찾아 해결하면 되며, 접속이 성공하지 못한다면 다음 사항들을 고려해 볼 수 있다. 현재 서버에 접속된 세션 수가 MAX_CLIENT 알티베이스 프로퍼티의 설정값을 초과함. 접속 방식이 IPC 방식인 경우 IPC 방식으로 접속된 세션 수가 IPC_CHANNEL_COUNT 설정값을 초과함. 응답이 없거나 타임 아웃으로 인해 세션이 끊어짐 질의 처리시 수행 속도가 느려 응답이 없는 경우 다음과 같은 상황을 생각해 볼 수 있다. 메모리 가용량이 부족하여 스왑핑이 발생 테이블을 풀 스캔하여 처리 성능이 저하 특정 테이블에 록을 요청하고 기다리고 있는 상태 먼저 시스템 성능 모니터링 도구를 이용하여 CPU 사용량과 메모리 사용량을 점검하여 메모리 부족 상황인지를 판단해야 하며 만일 메모리가 부족한 상황이라고 판단되면 위의 “메모리 사용량의 문제 를 참고한다. 메모리가 부족한 상황이 아니면서 CPU 사용량이 높다면 현재 처리 중인 쿼리 중 테이블 풀 스캔을 유발하는 쿼리가 있는지를 확인해야 한다. 현재 수행 중인 쿼리 목록을 확인하려면 iSQL로 서버에 접속하여 V$STATEMENT 성능 뷰의 QUERY 칼럼을 조회하면 된다. 수행 중인 쿼리 중 의심되는 쿼리를 선정하여 실행 계획을 확인하고 문제가 있다면 튜닝을 해야 한다. 알티베이스 진단 모니터링 459 쿼리 튜닝에 대한 자세한 내용은 이 매뉴얼의 “SQL 튜닝 ”장을 참조한다. 위의 두 경우에 해당하지 않는다면 록을 기다리고 있는 상태를 의심할 수 있다. 현재 록 정보를 V$LOCK 과 V$LOCK_WAIT 성능 뷰로 확인하고 특정 세션이 불필요하게 록을 획득하고 있는 상태로 지속되고 있다면 해당 세션을 강제로 종료하여 해결할 수 있다. 부록 A: Trace Log 461 A. 부록: Trace Log 462 Administrator’s Manual Trace Log 아래 프로퍼티는 알티베이스 서버에서 수행되는 SQL문의 정보, 에러 메시지 종류 및 SQL 문의 수행 소요 시간 등을 altibase_boot.log 파일에 기록하게 할 수 있는 프로퍼티이다. 이 프로퍼티의 기본 값은 0이며, 위의 정보들을 trace log로 기록하려면 1을 설정한다. 프로퍼티 파일에 명시된 값은 ALTER SYSTEM 문을 이용하여 변경할 수 있다. 프로퍼티에 대한 자세한 설명은 General Reference와 이 매뉴얼 11장의 “실행 계획 분석”절을 참고하기 바란다. TRCLOG 설명 TRCLOG_DETAIL_PREDICATE EXPLAIN PLAN 을 ON(또는 ONLY)로 설정시, where 절의 predicate 분류 상태도 함께 출력할지 를 지정함 부록 B: 알티베이스 최대치 463 B. 알티베이스 최대치 464 Administrator’s Manual Altibase 객체들의 최대값 아래의 표는 Altibase 객체들에 대한 최대 값을 정리한 내용으로 다음과 같다. 구분 객체의 최대값 비고 DB_NAME 길이 128 데이터베이스 이름의 최대 길이 OBJECT 길이 40 데이터베이스 객체 이름의 최대 길이 테이블스페이스 개수 64K (시스템 테이블스페이스 포함) 한 DB내의 테이블스페이스 최대 개수 데이터 파일 개수 1,024 한 테이블스페이스의 데이터 파일 최대 개수 67,108,864 (64K * 1024) 한 DB내의 데이터 파일 최대 개수 사용자 개수 2,147,483,638(시스템 사용자 포함) 한 DB내의 사용자 최대 개수 테이블 개수 2,097,151(메타 테이블 포함) 한 DB내의 테이블 최대 개수 인덱스 개수 64 테이블 당 인덱스 최대 개수 컬럼 개수 1,024 테이블 당 컬럼 최대 개수 32 인덱스 키 컬럼의 최대 개수 로우 개수 무한 개수 테이블 당 로우 최대 개수 파티션 개수 2,147,483,638 한 DB내의 파티션 최대 개수 제약사항 개수 2,147,483,638 한 DB내의 제약사항 최대 개수 찾아보기 465 찾아보기 Ａ active 로그 ....................................................20 admin 디렉토리 ..........................................26 aexport ............................................................32 AGGR 노드 ................................................. 336 AGGREGATION node............................. 380 alaAPI.h ...........................................................27 altibase ............................................................32 Altibase.jar ............................................. 28, 35 altibase.properties.............................. 22, 27 altibase_boot.log ................................ 22, 30 altibase_id.log ..............................................30 altibase_IPC.log ...........................................31 altibase_mt.log ............................................30 altibase_odbc.dll .........................................35 altibase_qp.log.............................................31 altibase_rp.log ..............................................30 altibase_sm.log ............................................30 altierr ................................................................32 altimon ............................................................32 altipasswd ......................................................32 altiprofile ........................................................32 ANTI-OUTR-JOIN node ........................ 381 AOJN 노드 ................................................. 360 arch_logs 디렉토리 ...................................26 audit .................................................................32 audit 디렉토리 ............................................26 Ｂ BAG-UNION node .................................. 383 BCB ................................................................ 222 BCB 상태 변화 ......................................... 226 bin 디렉토리 ................................................ 26 b-tree 인덱스 .............................................. 72 Buffer Area ................................................. 222 Buffer frame .............................................. 222 Buffer pool ................................................. 222 BUNI 노드 .................................................. 361 Ｃ CACHE ............................................................. 81 Checkpoint Flush..................................... 227 Checkpoint List ........................................ 225 checkServer ................................................... 33 CNF ................................................................ 367 commit ......................................................... 201 COMMIT_WRITE_WAIT_MODE .......... 443 CONC 노드 ................................................ 361 CONCATENATION node ...................... 384 conf 디렉토리 .............................................. 27 consistency.................................................... 14 constant filter............................................ 285 constraint ....................................................... 54 Control 단계 ................................................ 40 cost ................................................................ 367 COUNT node ............................................ 385 COUNT 노드 ............................................. 341 CYCLE .............................................................. 81 Ｄ Database Link .............................................. 55 database objects ........................................ 54 datafile ............................................................ 20 466 Administrator’s Manual dbs 디렉토리 ............................................... 27 DECRYPT ..................................................... 433 directory ......................................................... 56 DIRECT-PATH INSERT .............................. 15 Discard ......................................................... 125 disk table ....................................................... 58 distinct ......................................................... 306 DISTINCT node ........................................ 385 DISTINCT_HASH ...................................... 370 DISTINCT_SORT ....................................... 370 DNF ............................................................... 367 DRDMBS ...........................................................4 dump_stack.sh ............................................. 33 dumpla ........................................................... 33 dumplf ............................................................ 33 Ｅ ENCRYPT USING ..................................... 432 exclusive lock ............................................ 203 execution plan.......................................... 374 execution plan tree ................................ 268 executor ...................................................... 272 Explain Plan의 개요 ............................... 374 extent ........................................................... 103 Ｆ fault tolerance ............................................. 14 FILT 노드..................................................... 332 filter ............................................................... 285 FILTER node............................................... 387 Flush List ..................................................... 225 Flusher ......................................................... 227 FOJN 노드 .................................................. 359 foreign key 제약조건 ............................... 69 FULL SCAN ................................................. 370 FULL-OUTER-JOIN node ...................... 388 Ｇ GRAG 노드 ................................................. 347 grant ................................................................ 96 GRBY 노드 .................................................. 334 GROUP BUCKET COUNT ...................... 369 Group Commit .......................................... 442 GROUP_HASH ........................................... 369 GROUP_SORT ............................................ 370 GROUP-AGGREGATION node ........... 389 GROUPING node ..................................... 391 Ｈ HASH BUCKET COUNT ......................... 369 HASH node................................................. 391 HASH 노드 ................................................. 345 hash-based join ........................................ 302 HIER 노드 .................................................... 342 HIERARCHICAL QUERY node ............. 393 high availability .......................................... 14 hint ................................................................. 366 Hit Ratio 구하기 ...................................... 238 HSDS 노드 .................................................. 348 Hybrid DBMS .................................................. 4 Ｉ iloader ............................................................. 33 include 디렉토리 ....................................... 27 INCREMENT BY........................................... 81 index ........................................................ 54, 72 INDEX ............................................................ 370 INDEX ASC .................................................. 370 INDEX DESC ............................................... 370 install 디렉토리 .......................................... 28 integrity rule ................................................ 10 intensive exclusive lock ........................ 203 찾아보기 467 intensive exclusive shared lock......... 203 intensive shared lock ............................. 203 IPC .....................................................................14 isql .....................................................................33 Ｊ join ................................................................. 299 JOIN node .................................................. 395 JOIN 노드 ................................................... 354 Ｋ key filter....................................................... 285 key range .................................................... 285 killCheckServer ............................................34 Ｌ LEFT-OUTER-JOIN node ....................... 396 LFG 기능의 제약사항 ............................ 441 LFG기능의 한계점 ................................... 441 lib 디렉토리 ..................................................28 libodbccli.a ....................................................35 libodbccli.ar ...................................................28 libsesc.a ...........................................................28 limit ................................................................ 309 LIMIT-SORT node .................................... 397 LMST 노드 .................................................. 352 load balancing .............................................14 lock ................................................................ 203 Lock ............................................................... 231 log anchor file .............................................19 log file .............................................................20 Log File Creation Thread ..................... 437 Log Flush Thread .................................... 437 loganchor 파일 ...........................................29 logs 디렉토리 ..............................................29 LOJN 노드 .................................................. 358 LRU List ........................................................ 224 Ｍ makefile .......................................................... 30 MATERIALIZATION node ..................... 399 materialized node ................................... 379 memory table .............................................. 58 merge join .................................................. 303 message file ................................................. 23 Message queue table .............................. 66 meta 단계 ..................................................... 41 MGJN 노드 ................................................ 357 MINVALUE ..................................................... 81 MMDBMS ........................................................ 5 msg 디렉토리 .............................................. 29 MVCC ....................................................11, 206 MVCC 사용 시 주의사항 .................... 213 Ｎ nested loop join ...................................... 300 NO INDEX................................................... 370 NO_PUSH_SELECT_VIEW ...................... 370 non-materialized node ......................... 379 normalization ............................................ 278 NOT NULL 제약조건 ................................ 69 NULL 제약조건 ........................................... 69 Ｏ object privilege ........................................... 96 Offline ........................................................... 124 offline 백업 ................................................ 251 Online ........................................................... 124 optimization .............................................. 275 optimizer ..................................................... 273 order by....................................................... 308 ORDERED .................................................... 368 468 Administrator’s Manual Ｐ page .............................................................. 104 PARTITION-COORDINATOR .............. 410 PCRD 노드 ................................................. 365 PCTFREE ............................................ 115, 163 PCTUSED ........................................... 116, 163 Plan Nodes ................................................ 379 Plan Node의 종류 .................................. 379 plan tree...................................................... 374 Plan Tree ..................................................... 377 Plan Tree 출력 ......................................... 375 Prepare List ................................................ 225 primary key 제약조건 .............................. 69 privilege.......................................................... 95 process 단계 ................................................ 40 PROJ 노드 .................................................. 334 PROJECT node ......................................... 401 projection ................................................... 313 properties ...................................................... 42 push selection 기법............................... 281 PUSH_SELECT_VIEW ............................... 370 Ｑ query processing .................................... 273 QUEUE table ................................................ 66 Ｒ relational model ......................................... 10 Replacement Flush ................................. 227 replication ............................................. 14, 56 revoke ............................................................. 97 rollback ................................................. 20, 201 r-tree 인덱스 ............................................... 72 rule ................................................................ 367 Ｓ sample 디렉토리 ....................................... 30 savepoint ..................................................... 201 SCAN node ................................................. 402 SCAN 노드 ................................................. 328 schema objects ........................................... 54 SDIF 노드 .................................................... 363 SECURITY_ECC_POLICY_NAME .......... 430 SECURITY_MODULE_LIBRARY ............ 430 SECURITY_MODULE_NAME ................. 430 Segment....................................................... 103 sequence ............................................... 55, 80 server ............................................................... 34 ses.h ................................................................. 28 sesc .................................................................. 34 SET BUCKET COUNT .............................. 369 SET-DIFFERENCE node .......................... 403 SET-INTERSECT node ............................. 405 shared lock ................................................. 203 shmutil ............................................................ 34 SHUTDOWN ABORT ................................ 50 SHUTDOWN IMMEDIATE ...................... 49 SHUTDOWN NORMAL............................ 49 SITS 노드 ..................................................... 362 SORT MERGE JOIN node ..................... 400 SORT node ................................................. 407 SORT 노드 .................................................. 343 sort-based join ......................................... 301 SQL Plan Cache 관련 프로퍼티........ 418 SQL Plan Cache의 특징 ........................ 417 SQL 튜닝 ..................................................... 268 SQL 튜닝 일반 .......................................... 270 SQL92 .............................................................. 11 sqlcli.h ............................................................. 27 sqltypes.h ...................................................... 28 찾아보기 469 sqlucode.h .....................................................28 START WITH .................................................81 startup service .............................................46 startup 단계..................................................47 STOR 노드 .................................................. 351 stored function ............................................85 stored procedure .......................................85 strore procedure or funuction .............55 subquery ..................................................... 315 subquery filter .......................................... 285 Subquery 유형 ......................................... 315 synonym .........................................................55 synonym .........................................................83 SYS 사용자 ....................................................93 sysdba 시스템 권한 ..................................46 system privilege ..........................................95 system table .................................................58 SYSTEM_ 사용자 .........................................93 Ｔ table .................................................................54 tablespace......................................................56 TCP/IP ..............................................................14 TIMESTAMP 제약조건 ..............................69 Trace Log .................................................... 462 transaction .....................................................11 Transaction Durability ........................... 215 trc 디렉토리..................................................30 trigger ...................................................... 55, 90 trigger action ...............................................90 trigger envent ..............................................90 trigger restriction .......................................90 TSS ................................................................. 212 Ｕ unique key 제약조건 ................................69 Unix Domain socket ................................. 14 USE_HASH .................................................. 368 USE_NL ......................................................... 368 user ........................................................... 57, 93 user table ....................................................... 58 USER_MERGE ............................................ 368 USER_SORT ................................................ 368 Ｖ view .......................................................... 55, 78 VIEW Node ................................................ 408 VIEW 노드 .................................................. 338 VIEW-SCAN node ................................... 409 VMTR 노드................................................. 350 VSCN 노드 ................................................. 339 ㄱ 가비지 콜렉션 쓰레드 ............................. 18 가용성 .............................................................. 14 객체 .................................................................. 10 객체 접근 권한 ........................................... 96 관계 모델 ....................................................... 10 교체 플러시 ............................................... 227 권한 .................................................................. 95 권한 해제 ....................................................... 97 그룹 연산 .................................................... 304 그룹 커밋 .................................................... 442 그룹 커밋 관련 프로퍼티 튜닝 ........ 445 글로벌 인덱스 .......................................... 175 기본 파티션 ............................................... 179 ㄴ 노-아카이브 로그 .................................... 242 논리적 백업 ............................................... 240 논파티션드 객체 ...................................... 168 논파티션드 인덱스 ................................. 173 470 Administrator’s Manual ㄷ 다중 버전 동시성 제어 기법 ............ 206 다중 비저장 노드 ................................... 364 다중버전 기법 ............................................. 11 단일 비저장 노드 ................................... 327 단일 저장 노드 ........................................ 343 단일 키 인덱스 ........................................... 73 대기 모드.................................................... 230 대용량 메모리 테이블 ............................. 58 더블 라이트 .................................................. 12 데드락 감지 .................................................. 13 데이터 독립성 ............................................. 10 데이터 모델 .................................................. 10 데이터 암호화 .......................................... 431 데이터 테이블스페이스 ........................... 38 데이터베이스 객체 .................................... 54 데이터베이스 공간 .................................... 15 데이터베이스 관련 프로퍼티 ............... 42 데이터베이스 링크 .................................... 55 데이터베이스 모드 ................................. 242 데이터베이스 생성 .................................... 38 데이터베이스 이중화 ............................... 14 데이터베이스 정보 모니터링 ............ 450 데이터베이스 종료 .................................... 41 데이터베이스 트리거 ............................... 55 데이터베이스의 논리적 구조 ............... 21 데이터베이스의 물리적 구조 ............... 19 디렉토리 ......................................................... 56 디스카드 ...................................................... 125 디스크 테이블 ................................... 58, 271 디스크 테이블스페이스 .............. 101, 114 디스크 테이블스페이스의 MVCC .... 210 디스크로부터 페이지 읽기 ................. 232 ㄹ 라이브러리 .................................................... 35 로그 파일 ...................................................... 39 로그 플러쉬 쓰레드 ............................... 437 로그 플러시 쓰레드 ................................. 18 로그파일 생성 쓰레드 ........................... 437 로그파일그룹 ............................................. 436 로깅 .................................................................. 12 로우 구조 .................................................... 117 로우 마이그레이션 .................................. 118 로우 체이닝 ................................................ 118 로컬 인덱스 ................................................ 175 롤백 ................................................................ 201 리스트 파티셔닝 ...................................... 188 리스트 파티션 프루닝 ........................... 310 리스트 파티션드 객체에 대한 연산 .................................................................... 189 ㅁ 매체 복구시 주의사항 ........................... 249 매체복구....................................................... 246 메모리 사용량 모니터링 ...................... 450 메모리 테이블 ................................... 58, 271 메모리 테이블스페이스................. 38, 105 메시지 파일 .................................................. 23 메인 모듈 ......................................................... 8 무결성 규칙 .................................................. 10 무정지 시스템 ............................................. 14 물리적 백업 ................................................ 240 ㅂ 백업 ................................................................ 240 백업 시 주의사항 .................................... 244 백업 정책 .................................................... 240 버퍼 관련 프로퍼티 ............................... 237 찾아보기 471 버퍼 관리 .................................................... 229 버퍼 관리자 구성요소 .......................... 222 버퍼 관리자 통계 정보 ........................ 238 버퍼 관리자의 구조 ............................... 222 버퍼 영역 .................................................... 222 버퍼 풀................................................. 12, 222 버퍼 플러시 쓰레드 ..................................19 범위 파티셔닝 ........................................... 181 범위 파티션 프루닝 ............................... 309 범위 파티션드 객체에 대한 연산 ... 183 베이스 테이블 ..............................................78 보안 기능의 구성 .................................... 428 보안 모듈 구동 ........................................ 431 보안 모듈 연동 방법 ............................. 429 보안의 개요 ............................................... 426 복구................................................................ 246 복구 정책 .................................................... 246 복합 키 인덱스 ...........................................73 부트 파일 .......................................................22 부하 분산 .......................................................14 불완전 복구 ............................................... 248 뷰 ............................................................... 55, 78 비영구 저장 인덱스 ..................................74 ㅅ 사용자 ...................................................... 57, 93 상태 모니터링 ........................................... 450 상향식 인덱스 생성 ..................................76 서버 프로세스 ..............................................18 서비스 데몬 쓰레드 ..................................18 서비스 쓰레드 풀 .......................................18 성능 관련 이슈 ........................................ 268 세그먼트 ...................................................... 103 세션 관리 쓰레드 .......................................18 세션/statement 모니터링 .................... 450 스키마 객체 .................................................. 54 시노님 ...................................................... 55, 83 시스템 접근 권한....................................... 95 시스템 테이블 ............................................. 58 시퀀스 ...................................................... 55, 80 실행 계획 .................................................... 322 실행 계획 트리 ........................................ 268 실행 노드 .................................................... 325 실행 바이너리 ............................................. 32 실행기 ........................................................... 272 ㅇ 아카이브 로그 .......................................... 242 아카이브 로그 쓰레드 .......................... 437 아카이브 쓰레드 ......................................... 19 알티베이스 problem tracking ........... 451 알티베이스 개념 ........................................... 4 알티베이스 구동 ......................................... 46 알티베이스 구성도 .................................... 17 알티베이스 구조 ......................................... 17 알티베이스 디렉토리................................ 26 알티베이스 모니터링............................. 450 알티베이스 문제상황 분석 ................. 451 알티베이스 종료 ......................................... 49 알티베이스 특징 ......................................... 10 알티베이스 프로퍼티 파일 .................... 27 암호 칼럼 .................................................... 432 암호 칼럼으로 변경 ............................... 433 암호 칼럼의 생성.................................... 432 암호 칼럼의 해제.................................... 433 암호화 ........................................................... 432 액세스 ........................................................... 285 언두 레코드 ............................................... 119 언두 테이블스페이스......................38, 119 언두 테이블스페이스 변경 ................. 123 472 Administrator’s Manual 언두 테이블스페이스 크기 계산 ..... 155 엔진 구조....................................................... 10 영구 저장 인덱스 ...................................... 73 영속성 .......................................................... 215 오프라인 ...................................................... 124 오프라인 백업 .......................................... 251 오프라인 백업 .......................................... 241 온라인 .......................................................... 124 온라인 백업 ............................................... 241 완전 복구.................................................... 248 외래 키 제약조건 ...................................... 69 원격(Remote) 시스템 ............................... 14 유일 키 인덱스 ........................................... 73 유일 키 제약조건 ...................................... 69 이중화 ..................................................... 14, 56 이중화된 테이블 ......................................... 60 이진 비저장 노드 ................................... 354 이진 저장 노드 ........................................ 362 익스텐트 ...................................................... 103 인덱스 ..................................................... 54, 72 인덱스 변경 .................................................. 76 인덱스 삭제 .................................................. 76 인덱스 생성 .................................................. 74 인덱스 종류 .................................................. 72 인덱스 활용 .................................................. 76 인덱스의 생성 옵션 .................................. 75 인터페이스 .................................................... 11 일관성 ............................................................. 14 일반 사용자 테이블 .................................. 58 임시 테이블스페이스 ............................... 39 ㅈ 자동복구 ...................................................... 246 자바 클래스 라이브러리 ........................ 35 잠금 ............................................................... 203 저장 관리자 ..................................................... 7 저장 프로시저 ..................................... 13, 85 저장 프로시저 및 저장 함수 ............... 55 저장 함수 ...................................................... 85 저장점 ........................................................... 201 접근 모드 .................................................... 229 정규화 ........................................................... 278 제약조건......................................................... 54 제약조건 관리 ............................................. 69 제약조건의 종류 ........................................ 69 조건절 ........................................................... 280 조인 ................................................................ 299 조인 순서의 결정 .................................... 295 중복 키 인덱스 ........................................... 73 지역(local) 시스템 ..................................... 14 질의 처리 .................................................... 273 질의 처리기 ..................................................... 8 질의 최적화 ................................................ 275 집합 연산의 최적화 ............................... 307 ㅊ 체크포인트 쓰레드 .................................... 18 체크포인트 플러시 .................................. 227 최적화기....................................................... 273 ㅋ 칼럼 제약조건 ............................................. 70 커밋 ................................................................ 201 큐 테이블 ...................................................... 66 클라이언트-서버 ......................................... 10 ㅌ 테이블 ............................................................. 54 테이블 관리 .................................................. 58 테이블 제약조건 ........................................ 70 테이블/데이터베이스 컴팩션 ............... 13 찾아보기 473 테이블스페이스 ................................ 56, 100 테이블스페이스 공간 관리 ................. 155 테이블스페이스 관리 ............................. 126 테이블스페이스 백업 ............................. 139 테이블스페이스 복구 ............................. 139 테이블스페이스 분류 ............................. 109 테이블스페이스 상태 ............................. 124 트랜잭션 ...................................................... 199 트랜잭션 세그먼트 ................................. 120 트랜잭션 영속성 관리 방법 ............... 216 트랜잭션의 철회 .........................................20 트리거 ..............................................................90 트리거 액션 ..................................................90 트리거 이벤트 ..............................................90 트리거 조건 ..................................................90 ㅍ 파티셔닝 ...................................................... 168 파티셔닝 방법 ........................................... 181 파티션 전제조건 ...................................... 179 파티션 조건 ............................................... 179 파티션 키 .................................................... 169 파티션 필터링 ........................................... 312 파티션드 객체 ................................. 168, 171 파티션드 인덱스 ............................ 172, 173 파티션드 테이블 ...................................... 171 파티션의 최적화 ...................................... 309 퍼지 汰廣............................ 13 페이지 ................................................. 104, 107 페이지 구조 ............................................... 114 페이지 리스트 .......................................... 107 페이지 리스트 다중화 ............................. 60 페이지 요청 처리 절차 ........................ 230 프라이머리 제약조건................................ 69 프로젝션 ...................................................... 313 프로토콜 ......................................................... 14 프로퍼티 ......................................................... 42 프로퍼티 파일 ............................................. 22 플러셔 ........................................................... 227 플러시 ........................................................... 234 ㅎ 해시 테이블 ..................................... 224, 230 해시 파티셔닝 .......................................... 192 해시 파티션 프루닝 ............................... 311 해시 파티션드 객체에 대한 연산 ... 193 휘발성 테이블스페이스 .................39, 108 힌트 ............................................................... 366 힌트 처리 정책 ........................................ 366 힌트의 종류 ............................................... 367

ALTIBASE HDB DA 6.5.1 Release Notes (2015/05) ALTIBASE HDB DA 6.5.1.0.0 Release Notes ALTIBASE HDB DA 목차 목차 ............................................................................................................................. 2 1. 시스템 요구사항 ............................................................................................ 3 하드웨어 최저 사양 ...................................................................... 4 운영 체제 및 플랫폼 .................................................................... 4 2. 릴리스 정보...................................................................................................... 5 2.1 ALTIBASE HDB DA 6.5.1의 새로운 기능 .............................. 6 2.2 변경 사항 .............................................................................. 11 2.3 패키지 .................................................................................. 13 2.4 다운로드 ............................................................................... 14 ALTIBASE HDB DA 6.5.1.0.0 Release Notes ALTIBASE HDB DA 1. 시스템 요구사항 ALTIBASE HDB DA 6.5.1.0.0 Release Notes ALTIBASE HDB DA 하드웨어 최저 사양 1GB RAM (권장: 2GB) 1 CPU (권장: 2 CPUs) 4GB 하드 디스크 여유 공간 (권장: 12GB) 운영 체제 및 플랫폼 ALTIBASE HDB DA 6.5.1은 아래 표에 나열된 운영체제와 플랫폼 상에서 운영 가능하다. OS CPU Version Bit (Server) Bit (Client) LINUX x86, x86-64 (GNU glibc 2.12 이상) redhat 6.0 and higher 64-bit 64-bit Java 버전: ALTIBASE HDB DA 6.5.1은 JDK 1.5 이상에서 호환된다. 2. 릴리스 정보 ALTIBASE HDB DA 6.5.1.0.0 Release Notes ALTIBASE HDB DA 2.1 ALTIBASE HDB DA 6.5.1의 새로운 기능 2.1.1 기능 개선 - SQL 확장 LATERAL, CROSS APPLY, OUTER APPLY 지원 LATERAL 키워드를 사용해서 FROM 절의 인라인 뷰를 lateral 뷰로 지정하면, lateral 뷰는 FROM 절에서 그보다 왼쪽에 있는 객체(테이블, 뷰 등)들을 참조할 수 있다. ROW 트리거 지원 기존에 BEFORE UPDATE 트리거의 경우 ROW 트리거로 생성할 수 없었다. 6.5.1 버전 부터 FOR EACH ROW 옵션을 사용하여 BEFORE UPDATE 트리거를 ROW 트리거로 생성할 수 있다. 문자열 패딩 함수 DESENCRYPT, DESDECRYPT, AESENCRYPT, AESDECRYPT 같은 암복호화 함수와 함께 사용하면 편리한 문자열 패딩, 언패딩 함수가 지원된다. PKCS7PAD16 PKCS7UNPAD16 FLASHBACK 및 PURGE 지원 DROP 구문으로 제거된 테이블이 RECYCLEBIN_ENABLE 프로퍼티의 값에 따라 시스템에서 바로 삭제되거나 휴지통으로 옮겨질 수 있다. 휴지통에 있는 테이블은 FLASHBACK 구문으로 테이블을 복원할 수 있고, PURGE 구문으로 시스템에서 제거될 수 있다. 집계 함수 및 윈도우 함수 추가 집계 함수와 윈도우 함수에서 사용할 수 있는 역분포 함수, 칼럼의 값을 나열할 수 있는 LISTAGG 함수, 일원 분석 함수를 아래와 같이 지원된다. PERCENTILE_CONT PERCENTILE_DISC LISTAGG STATS_ONE_WAY_ANOVA 2.1.2 기능 개선 - 응용 프로그램 개발 인터페이스 확장 및 개선 데이터베이스 링크 기능 추가 알티베이스의 새로운 데이터베이스 링크는 기존의 위치 표시자(@)를 사용해서 접근하는 방식에 추가적으로 SQL문 전체를 원격 서버로 직접 전송하는 pass-through 방식을 제공한다. Monitoring API 기능 추가 Monitoring API는 외부 모니터링 툴 개발자를 위해 제공되는 인터페이스이다. ALTIBASE HDB DA 6.5.1.0.0 Release Notes ALTIBASE HDB DA 애플리케이션에서 ALTIBASE HDB의 성능 뷰를 직접 조회하여 모니터링 정보를 수집할 수도 있으나, Monitoring API를 사용하면 개발자들이 모니터링 툴을 좀 더 쉽게 개발할 수 있다. Log Analyzer Log Analyzer는 ALTIBASE의 DBMS와 타사 DBMS의 연동 또는 DBMS 내부의 변경 사항을 DBMS 외부에서 감지 및 처리할 수 있는 용도로 사용할 수 있다. 2.1.3 기능 개선 - 데이터베이스 객체 데이터베이스 권한(Role) 권한들의 묶음인 롤을 지원한다. 여러 개의 권한을 사용자들에게 부여할 때 롤을 사용하는 것이 용이하다. 롤 지원을 위해 아래의 메타 테이블이 변경되거나 추가되었다. SYS_USERS_ SYS_USER_ROLES_ 메모리 파티션드 테이블 메모리 테이블의 파티셔닝을 지원하지만, 파티션드 메모리 테이블에는 글로벌 논파티션드 인덱스를 생성할 수 없다 2.1.4 성능 향상 - 다국어 지원 MS936 캐릭터셋 중국어 문자 집합 중 하나인 MS936 캐릭터셋이 지원된다. MS936 캐릭터셋은 타 제품의 GBK, ZHS16GBK, CP936 등과 동일한 캐릭터 셋이다. 2.1.5 성능 향상 - 데이터 타입 문자형 데이터 타입의 기본 크기 제어 문자형 데이터 타입의 기본 크기를 설정하는 프로퍼티가 추가되었다. 기존에는 크기를 지정하지 않을 경우 기본 크기는 항상 1이었다. 추가된 프로퍼티는 아래와 같다. CHAR_DEFAULT_PRECISION VARCHAR_DEFAULT_PRECISION NCHAR_DEFAULT_PRECISION NVARCHAR_DEFAULT_PRECISION 2.1.6 성능 향상 - 내장 함수 DBMS Stats 함수 통계 자료를 설정하는 아래 내장 함수들의 인자가 변경되었다. SET_INDEX_STATS ALTIBASE HDB DA 6.5.1.0.0 Release Notes ALTIBASE HDB DA SET_TABLE_STATS 통계 자료를 삭제하는 내장 함수들이 추가되었다. DELETE_SYSTEM_STATS DELETE_DATABASE_STATS DELETE_TABLE_STATS DELETE_INDEX_STATS DELETE_COLUMN_STATS 2.1.7 성능 향상 - 클라이언트 툴 iSQL 명령어 추가 스크립트 파일 실행의 결과 및 명령어를 화면상에 보여줄지를 결정하는 명령어가 추가되었다. iSQL '/NOLOG' 옵션 추가 iSQL을 실행하기 위한 커맨드에 '/NOLOG' 옵션을 추가하여 데이터베이스에 접속하지 않고, iSQL을 실행할 수 있다. iSQL 출력 포맷 개선 iSQL 유틸리티에 SET NUMWIDTH 명령어가 추가되었다. 이 명령어는 NUMERIC, DECIMAL, NUMBER, FLOAT 타입의 SELECT 결과를 표시할 자리수를 설정한다. 데이터베이스 감사(Database Auditing) 데이터베이스 관리자가 객체, 구문 및 DDL 문에 대하여 감사(Audit)를 수행하여 데이터에 대한 보안 관리가 가능하다. 2.1.8 효율성 - 서버 성능 향상 메모리 테이블 업데이트 성능 개선 메모리 테이블에 인덱스가 없는 칼럼을 갱신할 때 불필요한 인덱스 갱신을 제거하여 성능이 개선되었다. 직접 키 인덱스(Direct Key Index) Direct Key 인덱스를 지원한다. 직접 키 인덱스는 인덱스 노드에 레코드 포인터와 함께 실제 레코드도 저장하기 때문에 인덱스 스캔 비용을 줄일 수 있다. 2.1.9 효율성 - 자원 효율성 쓰레드 개수 제한 알티베이스 서버 내에서 생성할 수 있는 쓰레드들의 총 개수를 설정하는 프로퍼티가 추가되었다. 이 프로퍼티는 알티베이스의 리소스를 제한하기 위해 사용할 수 있다. ALTIBASE HDB DA 6.5.1.0.0 Release Notes ALTIBASE HDB DA MAX_THREAD_COUNT 테이블 칼럼 압축 6.5.1부터 메모리 테이블의 압축을 지원한다. 시그널 핸들러 개선 ALTIBASE 서버가 운영 중에 xdbcatlog, xdbtailog 유틸리티를 사용하여 트레이스 로그 파일을 표준 출력에 출력하도록 한다. 트레이스 로그 기록 ALTIBASE를 시작한 이후부터 발생하는 경고 메시지나 트레이스 메시지 등이 altibase_trc.log에 기록된다. 이 로그 파일에는 발생하는 경고 메시지 등이 프로세스와 쓰레드 별로 저장되기 때문에 이를 통한 문제 추적 등이 가능하다. 2.1.10 보안 강화- 사용자 비밀번호 사용자 비밀번호 데이터베이스에서 사용자 비밀번호의 대소문자를 구분할 수 있는 기능이 추가되었다. 2.1.11 보안 강화- 암호화 암호화함수 16바이트 블록 암호화 알고리즘인 AES를 사용하는 암복호화 함수가 추가되었다. 추가된 함수는 아래와 같다. AESDECRYPT AESENCRYPT PSM 암호화 저장 프로시저 및 저장 함수 등의 PSM 코드 프로그램을 altiwrap 유틸리티로 암호화하여 노출되는 것을 방지할 수 있다. 2.1.12 보안 강화- 테이블/파티션 접근 모드 테이블/파티션 접근 모드 테이블 또는 파티션드 테이블의 각 파티션에 대한 접근 모드를 설정할 수 있다. 2.1.13 고가용성 증분백업 알티베이스는 기존의 전체 백업을 하던 방식에 추가적으로 증분 백업 및 이를 이용한 복구 방식을 제공한다. Altibase Heartbeat 분산 데이터베이스 환경에서 각 데이터베이스 노드의 장애를 감지하고, DBA가 ALTIBASE HDB DA 6.5.1.0.0 Release Notes ALTIBASE HDB DA 장애에 대한 조치를 할 수 있도록 Altibase Heatbeat 유틸리티가 제공된다. 2.1.14그 외 변경사항 실행 계획 출력 형식 변경 SQL 실행 계획에서 테이블과 인덱스 같은 스키마 객체의 소유자 이름의 출력 여부를 결정하는 TRCLOG_DETAIL_SCHEMA 프로퍼티가 없어지고, 소유자 이름이 항상 출력되도록 변경되었다. 날짜 변환 함수 추가 TIMESTAMP 형식의 값을 DATE 타입으로 변환하는 함수를 추가하였다. 추가된 함수는 아래와 같다. DATE_TO_UNIX UNIX_TO_DATE xdbaudit 유틸리티 'xdbaltiComp'로 이름 변경 ALTIBASE 6.5.1부터 'xdbaudit'으로 사용되던 유틸리티의 이름이 'xdbaltiComp'로 변경된다. xdbaltiComp는 기존의 audit과 기능이 동일한 유틸리티로써, 이중화로 운영중인 데이터베이스를 비교 및 검사하여 불일치하는 데이터를 출력하고, 일치시켜주는 기능을 제공한다. DCI 함수 제거 ALTIBASE 6.5.1부터 DCI(Direct Call Interface)를 제공하지 않는다 2.2 변경 사항 DBA와 개발자가 알아야 할 추가, 변경, 및 제거된 기능을 아래에서 설명한다. 데이터베이스 버전 데이터베이스 구성 요소 별 최신 버전 ALTIBASE HDB DA 버전 데이터베이스 바이너리 버전 통신 프로토콜 버전 메타 버전 이중화 프로토콜 버전 6.5.1 1.0.0 8.1.1 5.6.2 6.1.1 호환성 데이터베이스 바이너리 버전 NONE 통신 프로토콜 버전 NONE 메타 버전 NONE 이중화 프로토콜 버전 NONE 프로퍼티 AUDIT_FILE_SIZE AUDIT_LOG_DIR AUDIT_OUTPUT_METHOD AUDIT_TAG_NAME_IN_SYSLOG CASE_SENSITIVE_PASSWORD CONCURRENT_EXEC_DEGREE_DEFAULT CONCURRENT_EXEC_DEGREE_MAX CONCURRENT_EXEC_WAIT_INTERVAL DBLINK_GLOBAL_TRANSACTION_LEVEL DBLINK_REMOTE_STATEMENT_AUTOCOMMIT DBLINK_DATA_BUFFER_BLOCK_SIZE DBLINK_DATA_BUFFER_BLOCK_COUNT ALTIBASE HDB DA 6.5.1.0.0 Release Notes ALTIBASE HDB DA DBLINK_DATA_BUFFER_ALLOC_RATIO DBLINK_ALTILINKER_CONNECT_TIMEOUT FAILED_LOGIN_ATTEMPTS MEMORY_RECYCLEBIN_SIZE NCHAR_DEFAULT_PRECISION NVARCHAR_DEFAULT_PRECISION PASSWORD_LOCK_TIME PASSWORD_LIFE_TIME PASSWORD_GRACE_TIME PASSWORD_REUSE_TIME PASSWORD_REUSE_MAX PASSWORD_VERIFY_FUNCTION RECYCLEBIN_ENABLE REPLICATION_ALLOW_DUPLICATE_HOSTS TRC_MSGLOG_COUNT TRC_MSGLOG_FILE TRC_MSGLOG_SIZE TRC_MSGLOG_RESERVE_SIZE TRC_MSGLOG_ SIZE VARCHAR_DEFAULT_PRECISION 성능 뷰 V$MEMSTAT V$SESSION V$DBLINK_ALTILINKER_STATUS V$DBLINK_DATABASE_LINK_INFO V$DBLINK_GLOBAL_TRANSACTION_INFO V$DBLINK_LINKER_CONTROL_SESSION_INFO V$DBLINK_LINKER_DATA_SESSION_INFO V$DBLINK_LINKER_SESSION_INFO V$DBLINK_REMOTE_STATEMENT_INFO V$DBLINK_REMOTE_TRANSACTION_INFO 2.3 패키지 OS Version CPU Archive Name LINUX Redhat 6.0 X86 altibase-HDB-DA-server-6.5.1.0.4-LINUX-X86-64bit-release.run altibase-HDB-DA-client-6.5.1.0.4-LINUX-X86-64bit-release.run 2.4 다운로드 위치 Package http://support.altibase.com Manual http://support.altibase.com 설치 ALTIBASE HDB DA Installation Guide 참고

Altibase 7.1.0.0.0 Release Notes (2016.11) Altibase 7.1.0.0.0 Release Notes Altibase 목차 목차 ............................................................................................................................. 2 1. 시스템 요구사항 .............................................................................................. 3 하드웨어 최저 사양 ...................................................................... 4 운영 체제 및 플랫폼 .................................................................... 4 2. 릴리스 정보 ........................................................................................................ 5 2.1 Altibase 7.1의 새로운 기능 .................................................... 6 2.2 변경 사항 ............................................................................. 13 2.3 패키지 .................................................................................. 17 2.4 다운로드 ............................................................................... 18 Altibase 7.1.0.0.0 Release Notes Altibase 1. 시스템 요구사항 Altibase 7.1.0.0.0 Release Notes Altibase 하드웨어 최저 사양 1GB RAM (권장: 2GB) 1 CPU (권장: 2 CPUs) 4GB 하드 디스크 여유 공간 (권장: 12GB) 운영 체제 및 플랫폼 Altibase 7.1은 아래 표에 나열된 운영체제와 플랫폼 상에서 운영 가능하다. OS CPU Version Bit (Server) Bit (Client) AIX PowerPC 6.1 tl03 and higher 64-bit 64-bit HP-UX IA64 11.31 and higher 64-bit 64-bit LINUX x86-64, PowerPC (GNU glibc 2.12 and higher) redhat 6.0 and higher 64-bit 64-bit Java 버전: Altibase 7.1은 JDK 1.5 이상에서 호환된다. Altibase 7.1부터 윈도우용 서버 및 클라이언트를 지원하지 않는다. 2. 릴리스 정보 Altibase 7.1.0.0.0 Release Notes Altibase 2.1 Altibase 7.1의 새로운 기능 2.1.1 기능 개선 2.1.1.1 SQL 확장 논 파티션드 테이블 및 파티션드 테이블 변환 지원(Partition Exchange) CONJOIN TABLE: 이 구문은 논 파티션드 테이블을 테이블의 파티션으로 변환한다. 리스트 파티션과 범위 파티션은 지원하며, 해시 파티션은 지원하지 않는다. 대상 테이블의 데이터는 전부 생성된 파티션으로 이동한다. DISJOIN TABEL: 이 구문은 파티션드 테이블의 파티션을 논 파티션드 테이블로 변환한다. 해시 파티션은 지원하지 않으며, 논 파티션드 테이블은 기존 파티션의 속성을 그대로 갖는다. 테이블의 테이블스페이스 변경 테이블의 테이블스페이스 저장 공간을 이동할 수 있으며, 이 때 인덱스와 LOB 칼럼도 함께 이동한다. 단 논파티션드 테이블만이 지정한 테이블스페이스에 레코드를 이동할 수 있으며, 파티션드 테이블은 레코드 이동이 불가하다. 큐 생성시 사용자 정의 칼럼 지원 큐를 생성할 때 사용자가 칼럼을 정의할 수 있다. COMPACT, AGING 구문 확장 파티션드 테이블에 파티션 단위로 COMPACT 및 AGING구문을 수행할 수 있다. NOWAIT, WAIT 지원 INSERT, FOR UPDATE, DEQUEUE 문에 NOWAIT, WAIT옵션을 지원한다. NOCOPY 옵션 지원 저장 프로시저와 저장 함수에서 사용되는 매개 변수 및 지역 변수에 NOCOPY옵션을 지원한다. 이 옵션은 참조(reference)값을 활용하여 인자를 할당하는 방식이다. NOCOPY옵션은 ASSOCIATIVE ARRAY타입만 지원한다. 패키지 서브프로그램 다중정의(overloading) 지원 저장패키지에서 서브프로그램을 다중정의(overloading)할 수 있다. 즉, 서브프로그램의 이름은 같지만, 인자이름 및 데이터 타입 등을 다르게 정의할 수 있다. FETCH구문에 BULK COLLECTION 지원 Fetch 구문에서 BULK COLLECT INTO기능을 지원한다. 커서 사용시 정적 SQL 지원 OPEN FOR구문에서 동적 SQL뿐만 아니라 정적 SQL을 사용할 수 있다. 정적SQL은 USING 절과 함께 사용할 수 없다. 자율 트랜잭션 및 예외 초기화 프라그마 지원 컴파일 옵션을 지정하는 프라그마(Pragma)를 지원한다. 지원하는 프라그마는 PSM객체가 Altibase 7.1.0.0.0 Release Notes Altibase 트랜잭션 내에서 독립적으로 작동하는 자율 트랜잭션 프라그마(Autonomous_Transaction Pragma)와 예외 변수를 Altibase의 에러 코드로 초기화 할 수 있는 예외 초기화 프라그마(Exception_Init Pragma)가 있다. 집계 함수 및 윈도우 함수 추가 집계 함수와 윈도우 함수에서 사용할 수 있는 백분율 순위, 비율 분석 함수, 그룹의 누적 분포도, 정렬 함수, 상관 계수, 표본 공분산, 모공 분산 등을 지원한다. PERCENT_RANK CUME_DIST RATIO_TO_REPORT NTILE CORR COVAR_SAMP COVAR_POP 사용자 잠금(user lock) 함수 추가 사용자가 세션에서 사용자 잠금을 요청하거나 해제할 수 있는 함수가 지원된다. USER_LOCK_REQUEST USER_LOCK_RELEASE 기타 함수 추가 현재 세션에 접속한 환경 정보(context)를 반환하는 함수가 지원된다. SYS_CONTEXT VARBYTE 타입의 문자열을 인코딩 또는 디코딩하여 반환하는 함수를 아래와 같이 지원한다. BASE64_DECODE BASE64_ENCODE Quoted printable형태로 변환된 VARBYTE 타입의 문자열을 디코딩 또는 인코딩하여 VARBAYTE 타입의 문자열로 반환하는 함수를 아래와 같이 지원한다. QUOTE_PRINTABLE_DECODE QUOTE_PRINTABLE_ENCODE 특정 스키마에 소속되지 않고 전체 데이터베이스 수준에서 관리되는 알티베이스 파이프(PIPE)방식의 함수를 추가하였다. 추가된 함수는 아래와 같다. MSG_CREATE_QUEUE MSG_DROP_QUEUE MSG_SND_QUEUE MSG_RCV_QUEUE LOCK TABLE에 'UNTIL NEXT DDL' 구문 지원 세션이 NON-AUTOCOMMIT 모드일 때 테이블에 DDL(데이터 정의어)을 수행하면, DDL이 실행되기 직전에 자동으로 커밋을 수행한다. 그러나 lock_mode에서 EXCLUSIVE 모드를 지정하면, DDL을 수행하기 직전에 자동으로 커밋을 수행하지 않는다. Altibase 7.1.0.0.0 Release Notes Altibase ENABLE, DISABLE 지원 트리거 생성할 때 활성화(enable) 상태와 비활성화(disable) 상태를 설정할 수 있다. ALTER TIGGER 구문으로 상태를 변경할 수 있다. 2.1.1.2 응용 프로그램 개발 인터페이스 확장 및 개선 JDBC 로깅 JDBC 로깅(JDBC Logging)은 Altibase JDBC 드라이버에서 발생하는 각종 로그를 기록하는 것을 의미하며, java.util.logging 패키지를 이용하여 관련된 로그를 기록할 수 있다. 2.1.1.3 데이터 타입 날짜형 데이터 형식 지원 요일과 상관없이 일 년 중 몇 번째 주인지를 반환하는 'WW2' 데이터 형식을 지원한다. 2.1.1.4 내장 함수 DBMS Stats 함수 파티션의 통계 자료를 복사할 수 있는 내장 함수가 추가되었다. COPY_TABLE_STATS 그 외 함수들 V$SESSION 정보를 설정하는 저장 프로시저가 추가되었다. SET_CLIENT_INFO SET_MODULE 2.1.1.5 클라이언트 툴 altimon.sh 개선 Altibase 서버와 altiMon이 설치된 호스트 장비를 모니터링 하기 위해 altimon.sh를 개선하였다. altiMon은 주로 OS 정보와 DB정보를 모니터링 하며, OS 정보를 수집하기 위해서는 PICL 라이브러리를 사용할 수 있는 운영체제에서 가능하다. 호스트 변수 선언되는 호스트변수의 기본값이 변경되었다. isql 명령어 추가 iSQL에서 SELECT 결과의 칼럼에 대한 표시 형식을 설정할 수 있는 명령어가 추가되었다. SET NUMF[ORMAT] : 숫자 데이터 타입의 표시 형식 설정 COLUMN : 문자형 또는 숫자형 타입의 칼럼 표시 형식 설정 CL[EAR] COL[UMNS] : COLUMN명령어로 설정된 모든 칼럼의 설정을 해제 iLoader의 -prefetch_rows 지원 iLoader의 out모드에서 사용할 수 있는 -prefetch_rows옵션을 지원한다. select쿼리 수행 시에 데이터 베이스에서 한번에 가져오는 레코드 개수를 지정할 수 있다. Altibase 7.1.0.0.0 Release Notes Altibase 파티션 정보 출력 DESC 명령어를 사용하여 테이블 구조를 볼 때 파티션에 대한 정보도 함께 보여주는 기능이다. aexport 프로퍼티 추가 aexport 유틸리티의 프로퍼티들이 아래와 같이 추가되었다. ILOADER_ARRAY ILOADER_COMMIT ILOADER_ERRORS ILOADER_PARALLEL 2.1.2 효율성 2.1.2.1 서버 성능 향상 패키지 지원 Altibase에서 추가된 시스템 정의 저장 패키지는 아래와 같다. DBMS_ALERT DBMS_APPLICATION_INFO DBMS_CONCURRENT_EXEC DBMS_LOCK DBMS_OUPUT DBMS_RANDOM DBMS_SQL DBMS_STATS DBMS_RECYCLEBIN DBMS_UTILITY UTL_FILE UTL_RAW UTL_TCP Result Cache 지원 Result Cache를 사용하여 처음 실행한 쿼리의 중간 결과나 최종 결과를 서버에 저장하여, 같은 쿼리가 다시 실행되면 결과를 재사용할 수 있다. DBLink의 Two-Phase Commit (2PC) Level 지원 알티베이스와 이기종 데이터베이스 시스템 간에 수행하는 글로벌 트랜잭션의 정합성을 보장하기 위해 DB Link는 2PC 프로토콜을 제공한다. 자동 통계정보 수집 옵티마이저가 사용할 수 있는 통계정보를 자동으로 수집할 수 있다. 힌트 추가 정규화 형태, 조인방법, 조인순서, 테이블 접근방법, 병렬 질의 처리에 대한 힌트가 추가되었다. INDEX_ASC INDEX_DESC Altibase 7.1.0.0.0 Release Notes Altibase LEADING NO_EXPAND NO_INDEX NO_PARALLEL NO_USE_HASH NO_USE_MERGE NO_USE_NL NO_USE_SORT USE_CONCAT 실행 계획의 지연 기능 실행 계획의 그래프를 기준으로 sorting, windowing, grouping, set, distinction의 계층적 실행(hierarchy execute)이 Fetch에서 수행되는 것을 지연시키는 기능을 제공한다. 사용자는 실행 계획에서 상위 PROJECTION 아래에 DELAY 플랜이 추가된 것을 확인할 수 있다. IPCDA 프로토콜 지원 IPCDA(Inter Process Communication Direct Attach)는 Altibase에서 제공하는 프로토콜로써, IPC와 마찬가지로 공유 메모리를 이용하여 클라이언트와 데이터베이스 서버간에 데이터를 교환한다. IPCDA는 IPC보다 데이터 읽기, 쓰기를 단순화하고 클라이언트, 서버 사이의 유휴 시간을 줄여 성능이 향상되었다. IPC와 마찬가지로 CLI, ODBC는 지원하지만, JDBC는 지원하지 않는다. 또한 IPCDA를 사용할 때는 LOB 데이터를 사용할 수 없다. 현재는 Linux 운영체제에서만 사용할 수 있다. ACCESS LIST 관리 확장 외부 파일에 기술된 IP 패킷의 접근 및 차단을 허용할 수 있도록 ACCESS_LIST_FILE 프로퍼티를 추가하였다 2.1.2.2 자원 효율성 메모리 인덱스 재구성(Reorganization) 지원 메모리 인덱스의 리프 노드를 통합하여 인덱스 공간을 재구성한다. 데이터에 비해 인덱스의 범위가 클 때, 특정 인덱스에 단편화 현상이 있을 경우에 사용하면 공간 효율성이 향상된다. 메모리 B-tree인덱스만 사용할 수 있다. 2.1.3 고가용성 하이브리드 파티션드 테이블(Hybrid Partitioned Table) 지원 하이브리드 파티션드 테이블을 지원하여, 파티션드 테이블이 디스크 테이블스페이스에서 메모리/휘발성 테이블스페이스로, 메모리/휘발성 테이블스페이스에서 디스크 테이블스페이스로 데이터를 이동할 수 있다. 단 글로벌 인덱스는 지원되지 않는다. PSM 문자형 데이터 크기 결정 저장 프로시저와 저장 함수에서 사용하는 문자형 데이터 타입의 크기를 결정하는 프로퍼티가 추가되었다. PSM_CHAR_DEFAULT_PRECISION PSM_NCHAR_UTF8_DEFAULT_PRECISION Altibase 7.1.0.0.0 Release Notes Altibase PSM_NCHAR_UTF16_DEFAULT_PRECISION PSM_NVARCHAR_UTF8_DEFAULT_PRECISION PSM_NVARCHAR_UTF16_DEFAULT_PRECISION PSM_PARAM_AND_RETURN_WITHOUT_PRECISION_ENABLE PSM_VARCHAR_DEFAULT_PRECISION 문자형 데이터 타입의 기본 크기를 설정하는 프로퍼티는 제거되었다. CHAR_DEFAULT_PRECISION NCHAR_DEFAULT_PRECISION NVARCHAR_DEFAULT_PRECISION VARCHAR_DEFAULT_PRECISION 일괄처리(Batch) 지원 REMOTE 함수 알티베이스 데이터베이스 링크가 일괄처리(Batch)할 수 있는 Remote함수와 관련 함수를 추가하였다. 그리고 추가된 함수는 저장 프로시저 내에서만 사용할 수 있다. JDBC Adapter JDBC Adapter는 알티베이스 데이터베이스에서 변경된 데이터를 JDBC를 지원하는 다른(타사의) 데이터베이스에 적용하는 유틸리티 이다. 이는 알티베이스에서 제공하는 ALA(Alibase Log Analysis API) 와 JDBC(Java DataBase Connectivity) 를 이용하여 변경된 데이터를 타겟 데이터베이스에 복제하는 구조이다. 현재는 Linux 운영체제에서만 사용할 수 있으며, JRE 7 이상에서 동작한다. 2.1.4 기타 2.1.4.1 그 외 변경사항 윈도우 플랫폼 지원 중단 Altibase 7.1부터 윈도우용 서버 및 클라이언트를 지원하지 않는다. Table Function 지원 TABLE FUNCTION은 사용자 정의 함수에서 반환하는 associative array 타입이나 record 타입의 변수를 테이블 형태로 변환하여 출력한다. 이 기능은 함수가 아니다. 동적 SQL의 메소드4추가 동적SQL에 메소드4를 추가한다. 이 메소드는 프로그램 실행 중에 사용자가 파라미터 마커의 값을 입력할 수 있다. BIND VARIABLES, SELECT LIST, ARRAY SIZE SET함수가 추가되었고 OPEN, FETCH, EXECUTE함수가 개선되었다. Hibernate와 연동지원 Altibase가 비표준SQL을 제공할 수 있도록 Hibernate의 dialect클래스를 지원한다. Hibernate 공식 라이브러리는 AltibaseDialect.class을 포함하지 않기 때문에 AltibaseDialect.java파일을 컴파일하고 포팅해야 사용할 수 있다. JRE 1.5 지원 JDK, JRE1.5 이상을 지원한다. Altibase 7.1.0.0.0 Release Notes Altibase DataPort 기능 제거 데이터를 이전할 수 있던 DataPort 기능 및 유틸리티(convdp)를 지원하지 않는다. 공유 메모리 기능 미지원 공유 메모리(Shared Memory) 모드를 7.1부터 지원하지 않는다. 공유 메모리를 지원하는 관리 도구 'shmutil' 및 프로퍼티를 삭제한다. 2.2 변경 사항 DBA와 개발자가 알아야 할 추가, 변경, 및 제거된 기능을 아래에서 설명한다. 데이터베이스 버전 데이터베이스 구성 요소 별 최신 버전 Altibase 버전 데이터베이스 바이너리 버전 통신 프로토콜 버전 메타 버전 이중화 프로토콜 버전 6.5.1 6.3.1 7.1.3 8.1.1 7.4.2 7.1 6.5.1 7.1.3 8.1.1 7.4.2 호환성 데이터베이스 바이너리 버전 데이터베이스 바이너리 버전은 데이터베이스 이미지 파일과 로그 파일의 호환성을 나타낸다. 데이터베이스 이미지 및 로그 파일의 형식이 변경되었으므로, 데이터베이스 업그레이드 시 기존 데이터베이스는 마이그레이션 되어야 한다. Altibase 버전 데이터베이스 바이너리 버전 6.5.1 6.3.1. 7.1 6.5.1 통신 프로토콜 버전 통신 프로토콜 버전은 변경되지 않았다. Altibase 버전 통신 프로토콜 버전 6.5.1 7.1.3 7.1 7.1.3 메타 버전 메타 버전은 변경되지 않았다. Altibase 버전 메타 버전 6.5.1 8.1.1 7.1 8.1.1 Altibase 7.1.0.0.0 Release Notes Altibase 이중화 프로토콜 버전 이중화 프로토콜 버전이 변경되지 않았다. 따라서 Altibase 6.5.1 과 7.1 간의 이중화가 가능하다. Altibase 버전 이중화 프로토콜 버전 6.5.1 7.4.2 7.1 7.4.2 프로퍼티 아래의 프로퍼티들이 추가 및 삭제되었다. 각 프로퍼티에 대한 자세한 내용은 General Reference를 참고하기 바란다. Altibase의 새로운 프로퍼티 ACCESS_LIST_FILE DBLINK_RECOVERY_MAX_LOGFILE IPCDA_CHANNEL_COUNT IPCDA_DATABLOCK_SIZE IPCDA_FILEPATH LOCK_MGR_CACHE_NODE LOCK_MGR_DETECTDEADLOCK_INTERVAL LOCK_MGR_MAX_SLEEP LOCK_MGR_MIN_SLEEP LOCK_MGR_SPIN_COUNT LOCK_MGR_TYPE LOCK_NODE_CACHE_COUNT MEM_INDEX_KEY_REDISTRIBUTION MEM_INDEX_KEY_REDISTRIBUTION_STANDARD_RATE MSG_QUEUE_PERMISSION OPTIMIZER_AUTO_STATS OPTIMIZER_DELAYED_EXECUTION OPTIMIZER_PERFORMANCE_VIEW PSM_CURSOR_OPEN_LIMIT PSM_CHAR_DEFAULT_PRECISION PSM_NCHAR_UTF8_DEFAULT_PRECISION PSM_NCHAR_UTF16_DEFAULT_PRECISION PSM_NVARCHAR_UTF8_DEFAULT_PRECISION PSM_NVARCHAR_UTF16_DEFAULT_PRECISION PSM_PARAM_AND_RETURN_WITHOUT_PRECISION_ENABLE PSM_VARCHAR_DEFAULT_PRECISION RESULT_CACHE_ENABLE Altibase 7.1.0.0.0 Release Notes Altibase RESULT_CACHE_MEMORY_MAXIMUM TABLE_LOCK_MODE TOP_RESULT_CACHE_MODE USER_LOCK_POOL_INIT_SIZE USER_LOCK_REQUEST_CHECK_INTERVAL USER_LOCK_REQUEST_LIMIT USER_LOCK_REQUEST_TIMEOUT Altibase 의 삭제된 프로퍼티 CHAR_DEFAULT_PRECISION DATAPORT_FILE_DIRECTORY DATAPORT_IMPORT_COMMIT_UNIT DATAPORT_IMPORT_STATEMENT_UNIT IPC_PORT_NO NCHAR_DEFAULT_PRECISION NVARCHAR_DEFAULT_PRECISION SHM_DB_KEY SHM_PAGE_COUNT_PER_KEY STARTUP_SHM_CHUNK_SIZE VARCHAR_DEFAULT_PRECISION 메타 테이블 아래의 메타 테이블이 삭제되었다. 각 메타 테이블에 대한 자세한 내용은 General Reference를 참고하기 바란다. Altibase 의 삭제된 메타 테이블 SYS_DATA_PORTS_ 성능 뷰 아래의 성능 뷰 들이 추가되었다. 각 성능 뷰에 대한 자세한 내용은 General Reference를 참고하기 바란다. Altibase 의 새로운 성능 뷰 V$ACCESS_LIST V$DBLINK_NOTIFIER_TRANSACTION_INFO Altibase 의 수정된 성능 뷰 V$DBLINK_LINKER_DATA_SESSION_INFO V$DBLINK_GLOBAL_TRANSACTION_INFO Altibase 7.1.0.0.0 Release Notes Altibase V$DBLINK_REMOTE_STATEMENT_INFO V$DBLINK_REMOTE_TRANSACTION_INFO V$SESSION V$REPSENDER V$REPSENDER_PARALLEL 2.3 패키지 OS CPU Archive Name AIX PowerPC altibase- server-7.1.0.0.0-AIX-POWERPC-64bit-release.run altibase- client-7.1.0.0.0-AIX-POWERPC-64bit-release.run HP-UX IA64 altibase- server-7.1.0.0.0-HPUX-IA64-64bit-release.run altibase- client -7.1.0.0.0-HPUX-IA64-64bit-release.run LINUX X86 altibase- server-7.1.0.0.0-LINUX-X86-64bit-release.run altibase- client-7.1.0.0.0-LINUX-X86-64bit-release.run PowerPC altibase- server-7.1.0.0.0-LINUX-POWERPC-64bit-release.run altibase- client-7.1.0.0.0-LINUX-POWERPC-64bit-release.run 2.4 다운로드 위치 Package http://support.altibase.com Manual http://support.altibase.com 설치 Altibase Installation Guide 참고

ALTIBASE HDB 6.5.1.6.6 Patch Notes ALTIBASE HDB Patch Notes 6.5.1.6.6 2 / 10 목차 BUG-46878 java version 9 이상을 사용할 경우 DBLink 시작 실패 ......................... 3 BUG-46892 Mathematics 사용 메모리 제한 기능과 Mathematics Temp 사용 모니터링 기능 추가 ........................................................................................... 4 BUG-46938 MT function data 전체를 재사용하기 위해 getStatus, setStatus 추가 시 성능이슈 수정 ..................................................................................... 5 BUG-46957 Invalid operation 에러의 Cause와 Action을 보강해야 합니다. ...... 6 BUG-47048 aexport로 수행 후 생성된 스크립트에 QUEUE의 테이블스페이스 지정절이 누락됩니다. ....................................................................................... 7 BUG-47051 set explainplan on/only 후 프로시저를 실행하면 Function sequence error ................................................................................................... 8 ALTIBASE HDB Patch Notes 6.5.1.6.6 2 / 10 ALTIBASE HDB Patch Notes 6.5.1.6.6 3 / 10 BUG-46878 java version 9 이상을 사용할 경우 DBLink 시작 실패 Module dblink Category Functional Error 재현빈도 Always Reproducing Conditions 재현절차 N/A 수행결과 N/A 예상결과 N/A 증상 java version 9이상에서 dblink start가 실패하는 문제가 있어, 수정하였습니다. Java version 9이상에서 dblink start 하면, altibase_error.log 에 아래의 에러가 기록될 수 있으나, 무시해도 됩니다. java version 9 이상에서 -d64 옵션이 제거되어 발생하는 에러로, 내부적으로 해당 옵션을 제거하고 다시 dblink start 시도하기 때문입니다. Unrecognized option: -d64 Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.6.6 4 / 10 BUG-46892 Mathematics 사용 메모리 제한 기능과 Mathematics Temp 사용 모니터링 기능 추가 Module mt-function Category Memory Error 재현빈도 Always Reproducing Conditions 재현절차 N/A 수행결과 N/A 예상결과 N/A 증상 Mathematics 사용 메모리 제한 기능과 Mathematics Temp 사용 모니터링 기능을 추가합니다. Mathematics은 일반적인 연산 함수나 Listagg와 같은 분석 함수에서 사용하는 메모리를 합해서 보여줍니다. 특히 분석 함수는 데이터 분포에 따라 메모리를 많이 사용할 수 있습니다. 따라서 모니터링을 위해, v$statement에 MATHEMATICS_TEMP_MEMORY 정보를 추가하였습니다. 또한 Mathematics Temp의 메모리 사용 제한을 위해서 Property를 제공합니다. 변경사항 Performance View -V$STATEMENT 컬럼 추가) MATHEMATICS_TEMP_MEMORY :분석함수에서 사용하는 MATHEMATICS TEMP 메모리 사용량를 보여준다. Property - 속성 이름 : MATHEMATICS_TEMP_MEMORY_MAXIMUM - 속성 설명 : 분석함수에서 사용하는MATHEMATICS TEMP 메모리 용량을 제어한다. - 변경/추가/삭제 : 추가 - 공개/비공개 : 공개 - 최소값, 최대값, 기본값 : 0, ULong Max, 0 Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.6.6 5 / 10 BUG-46938 MT function data 전체를 재사용하기 위해 getStatus, setStatus 추가 시 성능이슈 수정 Module mt-function Category Maintainability 재현빈도 Always Reproducing Conditions 재현절차 N/A 수행결과 N/A 예상결과 N/A 증상 MT function data 전체를 재사용하기 위해 getStatus, setStatus 추가 시 성능 하락이 있어, 수정하였습니다. 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.6.6 6 / 10 BUG-46957 Invalid operation 에러의 Cause와 Action을 보강해야 합니다. Module doc Category Manual 재현빈도 Always Reproducing Conditions 재현절차 N/A 수행결과 N/A 예상결과 N/A 증상 CAUSE, ACTION을 사용자 관점에서 보강하였습니다. 4, cmERR_ABORT_INVALID_OPERATION = Invalid operation # *Cause: Client version is higher than Server version or internal error occurs while interpreting protocol. # *Action: Make sure Client version is same or lower than Server version, or contact Altibase's Support Center(http://support.altibase.com). 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.6.6 7 / 10 BUG-47048 aexport로 수행 후 생성된 스크립트에 QUEUE의 테이블스페이스 지정절이 누락됩니다. Module ux-aexport Category Functional Error 재현빈도 Always Reproducing Conditions 재현절차 N/A 수행결과 N/A 예상결과 N/A 증상 DISK_SYSTEM_DATA 테이블스페이스에 생성한 Queue를 aexport 로 수행 후 생성된 스크립트에 QUEUE의 테이블 스페이스 지정절이 누락되는 문제가 있어, 수정하였습니다. 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround N/A ALTIBASE HDB Patch Notes 6.5.1.6.6 8 / 10 BUG-47051 set explainplan on/only 후 프로시저를 실행하면 Function sequence error Module ux-isql Category Functionality 재현빈도 Always Reproducing Conditions 재현절차 CREATE OR REPLACE PACKAGE STANDARD AS TYPE SYS_REFCURSOR IS REF CURSOR; END; / DROP TABLE t1; CREATE TABLE t1 (id INT, val VARCHAR(10)); CREATE OR REPLACE PROCEDURE proc1 (oc OUT SYS_REFCURSOR) AS BEGIN OPEN oc FOR 'SELECT * FROM t1'; END; / set explainplan on; EXEC proc1(); set explainplan only; EXEC proc1(); set explainplan off; EXEC proc1(); 수행결과 iSQL> set explainplan on; iSQL> EXEC proc1(); ID VAL --------------------------- No rows selected. [ERR-4103A : Invalid statement processing request] iSQL> set explainplan only; iSQL> EXEC proc1(); ID VAL --------------------------- No rows selected. ALTIBASE HDB Patch Notes 6.5.1.6.6 9 / 10 [ERR-4103A : Invalid statement processing request] iSQL> set explainplan off; iSQL> EXEC proc1(); ID VAL --------------------------- No rows selected. Execute success. 예상결과 set explainplan on; EXEC proc1(); Create success. iSQL> set explainplan on; iSQL> EXEC proc1(); EXEC proc1(); ID VAL --------------------------- No rows selected. ------------------------------------------------------------ NO PLAN ------------------------------------------------------------ Execute success. iSQL> set explainplan only; iSQL> EXEC proc1(); set explainplan off; ID VAL --------------------------- No rows selected. ------------------------------------------------------------ NO PLAN ------------------------------------------------------------ Execute success. iSQL> set explainplan off; iSQL> EXEC proc1(); ALTIBASE HDB Patch Notes 6.5.1.6.6 10 / 10 ID VAL --------------------------- No rows selected. Execute success. 증상 set explainplan on/only 상태에서 ResultSet을 반환하는 프로시저를 실행하면, Function sequence error 또는 Invalid statement processing request 에러 발생하는 문제를 수정하였습니다. 변경사항 Performance View N/A Property N/A Compile Option N/A Error Code N/A Workaround N/A

ALTIBASE HDB 6.3.1.5.2 Patch Notes ALTIBASE HDB Patch Notes 6.3.1.5.2 2/6 Table of Contents BUG-40397 이중화 갭(gap)을 모니터링하기 위한 API를 추가한다. 3 BUG-41284 디스크 임시 테이블을 사용할 때 비정상 종료될 수 있다. 3 BUG-41720 동일한 패키지 내에서 associate array 변수를 return 절에 사용할 경우 오류가 발생한다. 3 BUG- 41741 Array 수행시 지시자에 SQL_DATA_AT_EXEC를 사용하면 수행 결과에 오류가 발생할 수 있다. 4 BUG-41818 패키지의 서브 프로그램(subprogram)으로 외부 프로시저를 사용할 때, return 값이 geometry type이면 package 생성이 제한된다. 4 BUG-41820 함수 기반 인덱스(function based index)를 가지고 있는 테이블을 이중화하면 서버가 비정상 종료될 수 있다. 6 ALTIBASE HDB Patch Notes 6.3.1.5.2 3/6 BUG-40397 이중화 갭(gap)을 모니터링하기 위한 API를 추가한다. - Module: mm-altibaseMonitor - Category: Functionality - Reproducibility: Always - Reproducing Conditions: NONE - Symptoms: 이중화 갭(gap)을 모니터링하기 위한 API를 추가한다. - Changes: 아래와 같이 2개의 데이터 구조체를 지원한다. ABIGetRepGap ABIGetRepSentLogCount - Workaround: NONE BUG-41284 디스크 임시 테이블을 사용할 때 비정상 종료될 수 있다. - Module: sm - Category: Functional Error - Reproducibility: Always - Reproducing Conditions: NONE - Symptoms: 디스크 임시 테이블을 사용할 때 비정상 종료될 수 있다. - Changes: NONE - Workaround: NONE BUG-41720 동일한 패키지 내에서 associate array 변수를 return 절에 사용할 경우 오류가 발생한다. ALTIBASE HDB Patch Notes 6.3.1.5.2 4/6 - Module: qp-psm-trigger-pvo - Category: Functionality - Reproducibility: Always - Reproducing Conditions: 재현 create or replace package pkg1 as type rec1 is record(c1 integer, c2 varchar(20)); type arr1 is table of rec1 index by integer; function sub1( p1 integer ) return arr1; end; / 실제 결과 [ERR-3112F : Unsupported data type for parameter, RETURN, or local variable. In SUB1 0005 : function SUB1( P1 INTEGER ) return ARR1; 예상 결과 Create success. - Symptoms: 동일한 패키지 내에서 associate array 변수를 return 절에 사용할 경우 오류가 발생한다. - Changes: NONE - Workaround: NONE BUG- 41741 Array 수행시 지시자에 SQL_DATA_AT_EXEC를 사용하면 수행 결과에 오류가 발생할 수 있다. - Module: ul-odbc - Category: Reliability - Reproducibility: Always - Reproducing Conditions: NONE - Symptoms: Array 수행시지시자에 SQL_DATA_AT_EXEC를 사용하면 수행 결과에 오류가 발생할 수 있다. - Changes: NONE - Workaround: NONE BUG-41818 패키지의 서브 프로그램(subprogram)으로 외부 프로시저를 사용할 때, return 값이 geometry type이면 package 생성이 제한된다. ALTIBASE HDB Patch Notes 6.3.1.5.2 5/6 - Module: qp-psm-trigger-pvo - Category: Functional Error - Reproducibility: Always - Reproducing Conditions: 재현 create or replace function func_geometry( p1 integer ) return geometry as language c library lib1 name "andy_upper" parameters( p1 ); / create or replace package pkg_geometry as function func_geometry( p1 integer ) return geometry; end; / 실제 결과 $T0> create or replace function func_geometry( p1 integer ) return geometry as language c library lib1 name "andy_upper" parameters( p1 ); / [ERR-3112F : Unsupported data type for parameter, RETURN, or local variable. In FUNC_GEOMETRY 0001 : create or replace function FUNC_GEOMETRY( P1 INTEGER ) return GEOMETRY as ^ ^ ] $T0> create or replace package pkg_geometry as function func_geometry( p1 integer ) return geometry; end; / Create success. 예상 결과 $T0> create or replace package pkg_geometry as function func_geometry( p1 integer ) return geometry; end; / [ERR-3112F : Unsupported data type for parameter, RETURN, or local variable. In FUNC_GEOMETRY ALTIBASE HDB Patch Notes 6.3.1.5.2 6/6 0002 : function FUNC_GEOMETRY( P1 INTEGER ) return GEOMETRY; ^ ^ ] - Symptoms: 패키지의 서브 프로그램(subprogram)으로 외부 프로시저를 사용할 때, return 값이 geometry type이면 package 생성이 제한된다. - Changes: NONE - Workaround: NONE BUG-41820 함수 기반 인덱스(function based index)를 가지고 있는 테이블을 이중화하면 서버가 비정상 종료될 수 있다. - Module: sm - Category: Functional Error - Reproducibility: Always - Reproducing Conditions: NONE - Symptoms: 함수 기반 인덱스를 갖고 있는 테이블을 이중화하면 서버가 비정상 종료될 수 있다. - Changes: NONE - Workaround: NONE