3.3 실행계획의 제어 3.3.1 힌트(Hint)의 활용 기준 3.3.2 최적화 목표(Goal) 제어 힌트 - ALL_ROWS : 쿼리 전체 결과를 모두 수행하는 것에 대한 최적화를 목표로 최저 비용의 실행계획을 수립하도록 유도 : Minimum total resource consumption - CHOOSE : SQL에서 액세스하는 테이블에 대한 통계정보 유무에 따라 규칙, 비용기준을 적용하여 최적화를 수행 : CHOOSE 모드에서 테이블의 통계정보를 참조할 수 있는 경우는 ALL_ROWS 방식으로 처리 - FIRST_ROWS : 최적 응답시간(Best response time)을 목표로 최저 비용의 실행계획을 수립하도록 유도 : Minimum resource usage to return first t..
전체 글
3.2 실행계획의 유형 3.2.1 스캔의 기본유형 3.2.1.1 전체 테이블 스캔 - 옵티마이저가 전체 테이블 스캔을 사용하는 경우 * 적용가능 인덱스의 부재 : 쿼리가 존재하는 인덱스를 전혀 사용할 수 없을 때. 경우에 따라 인덱스 스킵 스캔이 적용되면 인덱스 사용가능 * 넓은 범위의 데이터 액세스 : 처리 범위가 넓어서 전체 테이블 스캔이 보다 적은 비용이 든다면 인덱스 스캔을 포기할 수 있음 * 소량의 테이블 액세스 : 최고수위 표시 내 블록이 DB_FILE_MULTIBLOCK_READ_COUNT 내에 있다면 발생 가능 * 병렬처리 액세스 : 병렬처리로 수행되는 실행계획을 수립할 때는 항상 전체 테이블 스캔을 선택 * ‘FULL’ 힌트를 적용했을 때 : 쿼리 내에서 ‘FULL(table_alias)..
![](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FcOApsx%2FbtqDCZ4wb6d%2Foe8rBTLrhyJVlKQx5YueSk%2Fimg.png)
제 3장 SQL의 실행계획(Explain Plan) 3.1 SQL과 옵티마이저 3.1.1 옵티마이저와 우리의 역할 Optimizer : 다양한 사용자 요구에 따라 그 때마다 최적의 경로(처리 절차)를 찾아 주는 장치 3.1.2 옵티마이저의 형태 - 규칙기준 옵티마이저(RBO, Rule-Based Optimizer) * 인덱스 구조나 사용 연산자에 부여된 순위로써 최적 경로 결정 * 통계정보를 전혀 가지지 않음 * 경우에 따라 비현실적인 처릭경로 수림 * 수립될 처리경로 예측 가능 * 사용자가 원하는 처리경로로 유도하기가 용이 * 일반적인 보편타당성 있음 - 비용기준 옵티마이저(CBO, Cost-Based Optimizer) * 통계정보로 실제 비용을 계산하여 최소 비용 선택 * 데이터의 상태에 따른 현실..
![](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbnE08R%2FbtqDA5j6Iq0%2F4U2sdiVlg8SCsnHGAEnllK%2Fimg.png)
제 2장 인덱스의 유형과 특징 2.1. B-Tree index 2.1.1. B-Tree index의 구조 - Root/Branch/Leaf Block으로 나누어져 있음 - Rowid의 구조 * Data Obbject number : database segment 식별 정보 * Relative File number : tablespace에 상대적 datafile 번호 * Block number : Row를 포함하는 data block 번호 * Row number : block에서의 row의 slot - 인덱스 블록의 감소 전략 * 최대한 인덱스 컬럼 수를 줄인다 * 큰 블록 사이즈(DB_BLOCK_SIZE)를 지정한다 * RCTFREE를 가능한 최소로 정의한다 * 키 압축(Key compression)을 ..
![](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2Fxy3Bu%2FbtqDCaL0HQc%2FoMomB2MzfrviAMRmkE7BE1%2Fimg.png)
제 1장 데이터 저장구조와 특징 1.1 table, index 분리형 - 관계형 DB 이전에는 key의 역할이 중요 key를 Access 할 때, data의 위치를 바로 파악할 수 있으면? -> data와 key를 함께 둘 필요가 X 하지만, key에서 다시 data를 찾아가는 번거로움은 감수해야 함 대용량 관계형 DB의 가장 일반적인 구조 1.1.1 분리형 테이블의 구조 저장될 data가 들어왔을 때, block 하나가 선택되어 data 값과 무관하게 저장됨 * 저장시 부하가 낮지만, 액세스 시 부담이 증가 block 하단 ‘free Space’는 row length 변화시 사용하는 공간(table 정의시에 파라메타(PCTFREE)로 저장 가능 * Tablespace : DB 내 실제 데이터를 저장하는..
-- tablespace 총량 select spcname, pg_size_pretty(pg_tablespace_size(spcname)) from pg_tablespace; -- table size (index 미포함) select pg_relation_size('table'); -- index size select pg_relation_size('idx1'); -- total size(data + index) select pg_total_relation_size('table1'); -- DB size 단위적용 : pg_size_pretty() select pg_total_relation_size('DBname');