1. 성능 튜닝 소개#

이 장은 Altibase 성능 튜닝에 대한 개략적인 정보를 제공한다.

성능 튜닝 개요
데이터베이스 서버 튜닝
SQL 튜닝

성능 튜닝 개요#

데이터베이스 시스템 튜닝이란 성능 향상을 목표로 수행하는 일련의 작업을 의미한다. 성능 향상을 좀 더 구체적으로 표현하면 아래와 같다.

데이터베이스 서버의 전체 처리량 최대화
쿼리의 응답시간 최소화
리소스 사용율 최소화

이 문서는 성능 향상을 위해 사용자가 취할 수 있는 Altibase의 튜닝에 관련된 정보를 아래와 같이 분류하여 제공한다.

데이터베이스 서버 튜닝
SQL 튜닝

데이터베이스 서버 튜닝#

아래는 Altibase 서버 튜닝에 관련된 주 요소들이다.

성능 관련 프로퍼티
성능 관련 통계정보
운영 체제 리소스 관리
메모리 구성과 사용
I/O 구성 및 설계

사용자는 성능 문제가 발생할 수 있는 병목 현상을 방지하기 위해 데이터베이스의 초기 설계에 주의를 기울여야 한다. 또한 서버 운영에 있어 아래의 사항도 함께 고려해야 한다.

체크포인트 I/O
로그 파일 쓰기
서비스 쓰레드 병목
메모리 에이저
버퍼
SQL Plan Cache

서버 운영에 관련된 튜닝 요소는 다음 장에서 자세히 설명한다.

성능 관련 프로퍼티#

성능 최적화를 위해 Altibase 프로퍼티 파일을 사용 목적에 맞게 수정해야 한다. 다음은 성능과 관련된 프로퍼티의 목록이다. 각 프로퍼티에 대한 상세한 설명은 General Reference > 2장. Altibase 프로퍼티 > 성능 관련 프로퍼티절을 참조한다.

AGER_WAIT_MAXIMUM
AGER_WAIT_MINIMUM
BUFFER_VICTIM_SEARCH_INTERVAL
BUFFER_VICTIM_SEARCH_PCT
BULKIO_PAGE_COUNT_FOR_DIRECT_PATH_INSERT
CHECKPOINT_BULK_SYNC_PAGE_COUNT
CHECKPOINT_BULK_WRITE_PAGE_COUNT
CHECKPOINT_BULK_WRITE_SLEEP_SEC
CHECKPOINT_BULK_WRITE_SLEEP_USEC
CHECKPOINT_FLUSH_COUNT
CHECKPOINT_FLUSH_MAX_GAP
CHECKPOINT_FLUSH_MAX_WAIT_SEC
CM_BUFFER_MAX_PENDING_LIST
CM_DISPATCHER_SOCK_POLL_TYPE
DATABASE_IO_TYPE
DATAFILE_WRITE_UNIT_SIZE
DB_FILE_MULTIPAGE_READ_COUNT
DEDICATED_THREAD_CHECK_INTERVAL
DEDICATED_THREAD_INIT_COUNT
DEDICATED_THREAD_MAX_COUNT
DEDICATED_THREAD_MODE
DEFAULT_FLUSHER_WAIT_SEC
DIRECT_IO_ENABLED
DISK_INDEX_BUILD_MERGE_PAGE_COUNT
EXECUTE_STMT_MEMORY_MAXIMUM
EXECUTOR_FAST_SIMPLE_QUERY
FAST_START_IO_TARGET
FAST_START_LOGFILE_TARGET
HASH_AREA_SIZE
HASH_JOIN_MEM_TEMP_PARTITIONING_DISABLE
HASH_JOIN_MEM_TEMP_AUTO_BUCKET_COUNT_DISABLE
HIGH_FLUSH_PCT
HOT_LIST_PCT
HOT_TOUCH_CNT
INDEX_BUILD_THREAD_COUNT
INDEX_INITRANS
INDEX_MAXTRANS
INSPECTION_LARGE_HEAP_THRESHOLD
LFG_GROUP_COMMIT_INTERVAL_USEC
LFG_GROUP_COMMIT_RETRY_USEC
LFG_GROUP_COMMIT_UPDATE_TX_COUNT
LOB_CACHE_THRESHOLD
LOCK_ESCALATION_MEMORY_SIZE
LOG_IO_TYPE
LOW_FLUSH_PCT
LOW_PREPARE_PCT
MAX_FLUSHER_WAIT_SEC
MAX_THREAD_COUNT
MEM_INDEX_KEY_REDISTRIBUTION
MEM_INDEX_KEY_REDISTRIBUTION_STANDARD_RATE
MULTIPLEXING_CHECK_INTERVAL
MULTIPLEXING_MAX_THREAD_COUNT
MULTIPLEXING_THREAD_COUNT
NORMALFORM_MAXIMUM
OPTIMIZER_FEATURE_ENABLE
OPTIMIZER_MODE
OPTIMIZER_UNNEST_AGGREGATION_SUBQUERY
OPTIMIZER_UNNEST_COMPLEX_SUBQUERY
OPTIMIZER_UNNEST_SUBQUERY
OUTER_JOIN_OPERATOR_TRANSFORM_ENABLE
PARALLEL_LOAD_FACTOR
PARALLEL_QUERY_THREAD_MAX
PARALLEL_QUERY_QUEUE_SIZE
PREPARE_STMT_MEMORY_MAXIMUM
QUERY_REWRITE_ENABLE
REFINE_PAGE_COUNT
SHM_PAGE_COUNT_PER_KEY
SECONDARY_BUFFER_ENABLE
SECONDARY_BUFFER_FILE_DIRECTORY
SECONDARY_BUFFER_FLUSHER_CNT
SECONDARY_BUFFER_SIZE
SECONDARY_BUFFER_TYPE
SORT_AREA_SIZE
SQL_PLAN_CACHE_BUCKET_CNT
SQL_PLAN_CACHE_HOT_REGION_LRU_RATIO
SQL_PLAN_CACHE_PREPARED_EXECUTION_CONTEXT_CNT
SQL_PLAN_CACHE_SIZE
STATEMENT_LIST_PARTIAL_SCAN_COUNT
TABLE_INITRANS
TABLE_LOCK_ENABLE
TABLE_MAXTRANS
TABLESPACE_LOCK_ENABLE
TEMP_STATS_WATCH_TIME
THREAD_CPU_AFFINITY
TIMED_STATISTICS
TIMER_RUNNING_LEVEL
TIMER_THREAD_RESOLUTION
TOTAL_WA_SIZE
INIT_TOTAL_WA_SIZE
TOUCH_TIME_INTERVAL
TRANSACTION_SEGMENT_COUNT
TRX_UPDATE_MAX_LOGSIZE

성능 관련 통계정보#

서버의 쓰레드들이 작업을 계속하기 위해서 어떤 이벤트에 대해 대기해야 할 때 대기 이벤트 관련 통계치의 값이 증가된다. 특정 대기 이벤트에 대한 통계값이 높다면 해당 대기 이벤트가 성능에 영향을 미치고 있는 원인일 수도 있다.

대기 이벤트에 관련된 성능 뷰는 아래와 같다. 각 성능 뷰에 대한 상세한 설명은 General Reference > 3장. 데이터 딕셔너리를 참고한다.

V$SESSION_EVENT
V$SESSION_WAIT
V$SESSION_WAIT_CLASS
V$SYSTEM_EVENT
V$SYSTEM_WAIT_CLASS

아래는 Altibase의 여러 가지 통계정보(메모리 사용량, 프로세스 상태, 세션이나 버퍼 풀 관련 통계정보 등)를 저장하는 성능 뷰이다. 각 성능 뷰에 대한 상세한 설명은 General Reference > 3장. 데이터 딕셔너리를 참고한다.

V$BUFFPAGEINFO
V$BUFFPOOL_STAT
V$DBMS_STATS
V$FLUSHER
V$FLUSHINFO
V$LATCH
V$LOCK_WAIT
V$MEMSTAT
V$SERVICE_THREAD
V$SESSTAT
V$SYSSTAT
V$UNDO_BUFF_STAT

운영 체제 리소스 관리#

아래와 같이 운영 체제가 제공하는 명령어와 모니터링 툴을 사용해서 Altibase 서버의 리소스 사용량을 확인할 수 있다.

	AIX	HPUX	LINUX
Performance Monitor	top topas nmon	top glance	top
System Activity Reporter	sar	sar	sar
Virtual Memory Statistics	vmstat	vmstat	vmstat
I/O Statistics	iostat	iostat	iostat
Error Log	errpt	dmesg	dmesg

SQL 튜닝#

최적화되지 않은 쿼리는 불필요한 데이터에 대한 액세스나 리소스 사용을 증가시켜 데이터베이스 서버의 성능을 전반적으로 떨어뜨린다. SQL 튜닝은 이러한 요인을 제거하여 쿼리를 최적화하는 일련의 작업을 의미하며, 다음의 작업들이 포함된다.

SQL문 재작성
데이터베이스 스키마 재설계
Altibase 프로퍼티 조정
운영체제 커널 파라미터 조정

SQL 튜닝 방법 중 SQL문의 재작성과 데이터베이스 스키마 재설계는 Altibase의 쿼리 처리 방법과 제한 사항 등에 의해 쿼리 성능이 영향을 받기 때문에 Altibase의 쿼리 처리 방법에 대한 심도 깊은 이해가 요구된다. 또한, 메모리 테이블과 디스크 테이블을 모두 사용할 수 있기 때문에 저장 매체의 특성에 따라서 쿼리 처리에 어떻게 영향을 미치는지에 대한 이해가 필요하다.

본 절에서는 간략하게 성능 관련 이슈를 살펴보고 SQL 튜닝을 위해 필요한 기본 개념에 대하여 설명한다.

성능 관련 이슈#

실행 계획#

클라이언트에서 SQL문의 수행을 요구하면 질의 처리기는 구문 검사, 정당성 검사, 최적화 과정을 거쳐 실행 절차를 정의한 실행 계획을 생성한다. 실행 계획은 트리 구조로 구축되기 때문에 본 매뉴얼에서 실행 계획 트리 또는 plan tree라고 호칭되기도 한다. 쿼리 옵티마이저가 가장 효율적이라는 판단에 의해 결정된 실행 계획은 실제로 SQL문의 실행 시간에 큰 영향을 끼친다.

SQL Plan Cache#

Altibase에서는 세션간에 SQL 구문의 실행 계획이 공유될 수 있다. 이는 SQL 구문 수행시마다 매번 실행 계획을 만드는 비용을 줄인다. 이 기능을 이용하려면 SQL Plan Cache와 관련된 SQL_PLAN_CACHE_SIZE 프로퍼티의 값을 적절히 설정해야 한다.

자세한 설명은 7장. SQL Plan Cache을 참고하기 바란다.

데이터베이스 스키마와 데이터 용량#

우선적으로 응용프로그램의 특성 및 자원 활용의 효율에 따라 메모리 테이블 및 디스크 테이블의 사용을 적절히 고려하여야 한다. 일반적으로 자주 사용되는 데이터는 메모리 테이블에, 접근 빈도가 낮은 데이터는 디스크 테이블에 저장하여 관리하는 것이 유리하다.

응용 프로그램에서 사용되는 SQL문의 종류를 고려해 각 SQL문 별로 테이블에 접근하는 회수, 접근하는 레코드 수 및 디스크 페이지 수가 최소 비용이 되도록 테이블 스키마의 구성과 인덱스 구성에 유의해야 한다.

또한, 단순한 SQL문 또는 레코드 건수가 많은 테이블에 대해서는 술어(predicate) 내 칼럼값을 비교하는데 발생하는 비용이 성능에 큰 영향을 미친다. 그러므로 데이터 변환과 비교 비용을 최소화할 수 있는 적합한 데이터 타입을 선정하는 것이 중요하다.

따라서 가능한 적은 수의 레코드에 접근하도록 SQL문을 작성하여 비교하는 회수를 줄이고, 비교 연산 시 데이터 변환이 일어나지 않도록 칼럼의 데이터 타입과 비교되는 값의 데이터 타입을 잘 선정해야 한다.

응용프로그램 로직(테이블 접근 순서)#

만약 여러 클라이언트가 Altibase 데이터베이스에 연결된 경우, 각 클라이언트의 테이블 접근 순서가 성능에 영향을 미칠 수도 있다. 한 트랜잭션 내에서 DML문을 여러 개 사용하여 여러 테이블에 접근하는 경우, 응용프로그램에서 테이블에 접근하는 순서 등을 잘못 설계했다면 잠금을 획득하기 위해 대기하는 시간(lock waiting time)으로 인해 전체 응용프로그램 성능이 저하될 수도 있다. 따라서 클라이언트 응용프로그램의 로직 설계에 유의해야 한다.

시스템 리소스#

한 SQL문의 처리 시 성능에 영향을 미치는 시스템 리소스는 가용한 메모리의 크기, 메모리 버퍼의 크기, 디스크 성능과 CPU 성능이다.

검색 질의의 성능은 물론 메모리 테이블만을 사용할 경우 디스크 성능에 영향을 받지 않는다. 그러나, 디스크 테이블을 검색할 경우 디스크 성능 및 가용한 메모리 버퍼의 크기에 따라 질의 성능이 영향을 받게 된다. 이러한 점은 메모리 테이블을 검색할 경우 일정한 질의 응답 시간을 기대할 수 있는 반면, 디스크 테이블을 검색할 경우 질의 수행 시점의 환경에 따라 많은 성능 차이를 보이게 되는 원인이 된다.

ORDER BY 절 또는 GROUP BY 절 등이 포함된 질의를 처리할때, 질의 처리기는 sorting 기법이나 hashing 기법을 사용하는데 이 처리의 중간 결과를 저장하기 위해 메모리 임시 공간 또는 디스크 임시 공간을 사용하게 된다.

중간 결과가 메모리 임시 공간에 저장되는 경우, 사용되는 메모리는 데이터베이스 영역에 잡혀 있는 메모리가 아니다. 그러므로 메모리 테이블의 크기가 크다면 많은 메모리가 필요할 수 있으므로 질의 처리시 메모리 스와핑으로 인한 성능 저하가 생기지 않도록 주의해야 한다.

중간 결과가 디스크 임시 공간에 저장되는 경우, 사용되는 자원은 디스크 임시 테이블스페이스의 디스크 영역과 메모리 버퍼 영역이다. 가용한 메모리 버퍼 영역의 크기에 따라 성능에 커다란 영향을 미치게 된다.

또한 질의 처리 작업은 연산자를 처리하기 위한 작업이 많아 CPU를 많이 사용한다. 그러므로 CPU 점유율과 CPU 성능도 질의 성능에 영향을 많이 미친다.

SQL 튜닝 방법론#

쿼리의 응답시간을 최소화하기 위해 iSQL을 사용해서 사용자가 수행할 수 있는 기초적인 튜닝 절차는 아래와 같다.

Profiling 기능을 사용해서 응답시간이 오래 걸리는 질의문을 찾는다.
iSQL에서 Explain Plan을 볼 수 있도록 설정한다.
iSQL에서 쿼리 수행에 걸리는 시간을 볼 수 있도록 SET TIMING ON을 설정한다.
쿼리를 실행해서 실행 계획을 확인한다.
SQL문 변경, 인덱스 설정, 힌트 등을 사용하여 쿼리의 응답 시간을 감소시킨다.

이 절에서는 SQL 튜닝을 하기 위해 사용할 수 있는 도구와 방법에 대해 간단히 설명한다.

프로파일링(Profiling)#

프로파일링은 사용자가 요청한 SQL문에 대해 아래와 같은 정보를 수집하는 기능이다.

쿼리를 요청한 클라이언트
실행 시각
쿼리문
수행 소요 시간
사용된 인덱스
버퍼/디스크 접근 비용
실행 계획

프로파일링 기능은 ALTER SYSTEM SET ... 구문으로 프로퍼티 QUERY_PROF_FLAG의 값을 설정하여 사용할 수 있다. 이 프로퍼티에 설정하는 값에 따라 수집되는 정보가 다르다.

자세한 정보는 General Reference > 2장. Altibase 프로퍼티를 참조하기 바란다.

SQL 성능 측정 방법#

APRE, ODBC, 또는 JDBC 등을 사용한 응용프로그램 개발시, 응용프로그램 내에서 시간을 구하는 함수를 이용하여 쿼리 처리에 소요되는 시간을 측정할 수 있다. 또한 iSQL에서 다음 iSQL명령어를 이용해 쿼리 수행 시간을 측정할 수도 있다.

SET TIMING ON;

메모리 테이블의 경우 iSQL로 질의를 반복 수행 시 거의 유사한 성능을 얻을 수 있다. 하지만 디스크 테이블의 경우는 반복 수행 시 버퍼 교체가 적게 발생하여 최초 수행 때보다 다음 수행 시 보다 나은 성능을 얻게 된다. 이는 디스크 테이블에 대하여 동시 수행되는 질의들이 많을 경우 버퍼 교체로 인해 성능의 일정함을 보장할 수 없음을 의미한다.

그러나 일반적으로 iSQL상에서 SQL 문을 튜닝하여 성능을 향상시킨 SQL 문의 경우 실제 응용프로그램에서도 같은 비율의 성능 향상을 볼 수 있다.

실행 계획 분석#

SELECT, INSERT, UPDATE, DELETE 등의 SQL DML문의 실행 계획은 iSQL 상에서만 확인이 가능하다. DELETE 문, UPDATE 문, 및 MOVE 문은 SELECT 문 처리와 같은 최적화 과정을 거치므로 내부적으로 동일한 실행 계획이 생성된다.

INSERT문의 경우 INSERT INTO SELECT 의 SELECT문 부분에 대한 실행 계획만 확인할 수 있다.

일반적으로 실행 계획에서 확인해야 할 내용은 다음과 같다. 자세한 내용은 다음 절에서 살펴본다.

액세스 방법이 효율적인가?
조인 순서 및 방법은 바람직한가?
적절한 데이터 타입 및 연산을 사용하는가?
불필요한 hashing 및 sorting이 수행되지 않는가?

실행 계획을 분석해서 성능 저하 원인을 파악한 후, 이에 대한 적절한 조치를 취함으로서 성능을 개선할 수 있다.

SQL 튜닝 방법#

다음은 SQL 튜닝의 기본적인 방법이다. 각각의 방법에 대해서는 본 매뉴얼의 "3장. 쿼리 옵티마이저" 장과 "6장. SQL 힌트" 장을 참고한다.

효율적인 인덱스를 사용하는지 확인하라. 필요하다면 인덱스를 추가하라.
조인 순서와 조인 방법을 최적화하라.
sorting과 hashing 작업을 최소화하라.
힌트를 활용하라.

질의 처리 (Query Processing) 개요#

SQL문의 튜닝 시 항상 모든 응용 프로그램에 적용해 최적의 성능을 발휘하는 절대적인 규칙을 제시하기란 쉽지 않다. 데이터베이스의 설계 또는 응용 프로그램의 비지니스 로직에 따라 SQL 튜닝 방법은 매우 다양하다. 최적의 SQL문을 작성하기 위해서는 Altibase의 질의 처리에 대한 이해가 필수적이다.

이 절에서는 하나의 SQL문이 어떠한 과정을 거쳐 처리되는지, 성능에 영향을 미치는 요소는 어떠한 것들이 있는지에 대해 설명한다.

질의 처리 과정#

DBMS에서 SQL문 처리를 담당하는 모듈을 질의 처리기(Query Processor)라 한다. 질의 처리기는 사용자가 수행을 요구한 SQL문에 대해 정당성을 검사한 후 데이터베이스에 접근하는 최적의 접근 순서와 방법을 결정하고, 이에 따라 조건에 맞는 레코드를 검색한 후 필요한 연산을 수행하여 마지막으로 클라이언트에게 처리한 값을 돌려준다.

질의 처리수행 과정을 개략적으로 도식화하면 다음과 같다.

각 단계 별 수행 작업은 다음과 같다.

구문 분석(Parsing)

SQL문의 문법을 검사하고 구문 분석 정보를 저장하는 파스 트리(Parse Tree)를 생성한다.
정당성 검사(Validation)

SQL문의 의미 상 정당성을 검사하고 메타 테이블을 검색하여 파스 트리를 확장한다.
최적화(Optimization)

주어진 파스 트리에 기반하여 다양한 통계 정보와 접근 비용 계산을 통해 최적화된 실행 계획을 생성한다.
바인딩(Binding)

호스트 변수값을 생성된 실행 계획에 연결한다.
실행(Execution)

실행 계획 트리에 따라 SQL문을 실행한다.

질의를 튜닝하기 위해 Altibase의 질의 최적화와 질의 실행 과정을 이해하는 것은 매우 중요하다. 본 문서에서는 이를 기반으로 한 질의 튜닝 방법에 대하여 자세히 알아본다.

메모리 테이블과 디스크 테이블#

Altibase는 메모리 테이블과 디스크 테이블을 모두 지원하는 데이터베이스 관리 시스템이다. 따라서, 메모리 테이블과 디스크 테이블에 대한 질의 처리 방법의 차이를 이해하는 것은 질의 튜닝에 있어 큰 도움이 된다.

메모리 테이블과 디스크 테이블을 위한 질의 처리기의 기본적인 차이는 다음과 같다.

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 칼럼에서 서로 다른 값의 개수 (Cardinality) B(R): Table R의 디스크 페이지 개수 M: 가용한 메모리 버퍼 개수

질의 처리기는 크게 옵티마이저(Optimizer)와 실행기(Executor)로 구분된다. 옵티마이저는 비용 계산을 통해 실행 계획 트리를 생성한다. 실행기는 실행 계획 트리의 각 노드에 따라 실제로 구문을 실행한다.

Altibase의 실행기와 옵티마이저는 저장 매체의 차이를 충분히 반영하는 반면, 이에 대한 별도의 구분 없이 실행 계획을 생성하고, 질의 처리시에 그 특성만을 반영하여 수행할 수 있도록 설계되었다.

실행기(Executor)#

실행기는 테이블의 저장 매체에 따라 위의 표에서와 같이 기본적인 개념 및 그 동작에 있어 차이점이 있다.

먼저 레코드를 구별하는 "객체 식별자(Object identifier)"는 메모리 테이블의 경우 포인터이며 디스크 테이블의 경우 OID(RID)와 같은 특정 디스크 주소로 변환할 수 있는 식별자이다. 이러한 차이는 레코드 접근에 있어 메모리 테이블은 직접 접근이 가능한 반면 디스크 테이블은 주소 변환에 의한 접근이 필요함을 의미하다.

메모리 테이블에 대한 질의 처리시에는 버퍼를 사용하지 않아 이에 대한 고려가 필요없다. 반면, 디스크 테이블에 대한 질의 처리는 제한된 메모리 버퍼 내에서 이루어지기 때문에 버퍼에 원하는 레코드가 없을 경우(Buffer miss) 디스크 I/O를 유발하는 버퍼 교체(Buffer replacement)가 수반된다.

조인 연산을 수행하기 위해서 필요에 따라 중간 결과가 저장된다. 이 때 제한된 메모리에 이 결과를 모두 적재할 수 있는가에 따라 one-pass 또는 multi-pass 알고리즘으로 처리된다. One-pass 알고리즘의 경우 가용 메모리 임시 공간에 중간 결과를 모두 적재할 수 있을 때 사용되는 반면, multi-pass 알고리즘은 중간 결과를 메모리상에 모두 적재할 수 없을 때 버퍼 교체를 최소화하기 위해 사용된다. 메모리 테이블에 대한 조인의 경우 버퍼 제한이 없어 one-pass 알고리즘이 사용될 수 있는 반면, 디스크 테이블의 경우 버퍼 제한을 고려하여 one-pass 또는 two-pass 알고리즘이 사용된다.

위와 같이 실행기의 처리 방식은 저장 매체에 따라 근본적으로 다르며, 성능에 있어서도 큰 차이를 보이게 된다.

옵티마이저(Optimizer)#

쿼리 옵티마이저는 테이블이 저장된 저장 매체에 따라 위의 표와 같이 기본적인 개념 및 그 동작에 있어 차이점이 있다.

옵티마이저는 메모리 테이블을 조회할 경우 CPU 비용을 최소화할 수 있도록 실행 계획을 생성한다. 반면, 디스크 테이블을 조회할 경우 디스크 I/O를 최소화할 수 있도록 실행 계획을 생성한다. 즉, 저장 매체에 따라 질의 성능에 가장 큰 영향을 미치는 자원 사용을 최소화할 수 있는 실행 계획을 생성한다.

옵티마이저는 테이블에 접근하는 방법(Access method)을 선택할 때, 메모리 테이블의 경우 읽을 레코드 수를 최소화할 수 있는 인덱스를 선택한다. 그러나 디스크 테이블은 디스크 I/O를 최소화할 수 있는 접근 방법을 선택한다. 이러한 차이는 메모리 테이블의 경우 대부분 인덱스를 사용하는 것이 전체 테이블 스캔보다 나은 성능을 보장하지만, 디스크 테이블의 경우 데이터의 분포에 따라 인덱스를 사용하는 것보다 전체 테이블 스캔이 오히려 적은 디스크 I/O를 발생시키기 때문이다.

옵티마이저는 비용 계산을 위한 인자로 다양한 통계 정보를 사용한다. 메모리 테이블에 대한 비용 계산시에는 테이블의 레코드 개수[T(R)], 칼럼내의 서로 다른 값의 개수[V(R.a)], 칼럼의 최소값과 최대값 등의 통계 정보가 사용된다. 그리고 디스크 테이블에 대한 비용 계산시에는 메모리 테이블에 대한 비용 계산 방법 외에도 테이블이 사용하고 있는 디스크 페이지 개수[B(R)], 가용한 메모리 버퍼 페이지 개수[M]등의 통계 정보가 추가적으로 이용된다.

Administrator

Reference

Developer

Tools

External Tools