DB 데이터베이스 | 튜닝 용어 정리

 

- 파싱 -
요청한 SQL문을 DBMS에서 실행가능 형태로 변경하기 위해 수행하는 과정

- 하드파싱 -
SQL 실행계획을 캐시에서 찾지못해 최적화 과정을 거치고 난뒤 실행단계로 넘어가는 경우

- 소프트파싱 - 
SQL 실행계획을 캐시에서 찾아 곧바로 실행단계로 넘어가는 경우

 

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

- 옵티마이저 -
요청한 SQL을 가장빠르고 효율적으로 수행 하기위해 최적의 처리경로를 선택해주는 DBMS 핵심엔진

- 규칙기반 옵티마이저(RBO) -
미리 정해놓은 규칙에 따라 액세스 경로를 평가하고 실행계획을 선택한다.
*규칙이란
인덱스구조, 연산자, 조건절 형태가 순위를 결정짓는 주 요인이다.

- 비용기반 옵티마이저(CBO) -
미리 구해놓은 테이블과 인덱스등 여러 통계정보를 기초로 오퍼레이션 단계별 예상 비용을 산정하고
이를 합산한 총 비용이 가장 낮은 실행계획을 선택한다.

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

- 선택도 -
전체대상 레코드 중에서 특정조건에 의해 선택될 것으로 예상되는 레코드 비율을 말한다.

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

- 카디널리티 -
특정 액세스 단계를 거치고 난 후 출력될것으로 예상되는 결과 건수
총로우수 x 선택도

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

- 조건절이행 -
(A = B) 이고 (B = C) 이면 (A = C) 이다" 라는 추론을 통해 새로운 조건절을 
내부적으로 생성해 주는 쿼리변환 A테이블에 사용된 필터 조건이 조인 조건절을 타고 
반대편 B테이블에 대한 필터 조건으로 이행한 테이블 내에서도 두 컬럼간 관계정보를 이용해 조건절 이행

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

- NL Join(Nested Loop Join) 원리 -
*선행 (driving) table의 조건에 맞는 data와 매치되는 값을 다른(후행)table에서 참조
*두개의 결과를 순차적으로 검증하면서 Join
*별도의 결과 대기 영역이 필요없다.
*FIRST_ROWS에 최적화

- INDEX 생성에 따른여파 -
*Index를 적절히 설정하면 가장 빠른 성능을 보장
*Index를 잘못 설계한 경우 최악의 성능 가능

- 어떤 경우에  NL_JOIN이 효과 적인가 -
Index를 적절히 설정하면 했을때 최고의 성능

- NL Join(Nested Loop Join) 의 특징 -
*조인되는 후행 테이블의 조인 컬럼에 인덱스가 존재하지 않으면 후행 테이블을 반복 full scan으로 성능이 나쁨
*random access발생
*single Block i/o
*처리해야 되는 범위가 소량이며 부분범위 처리시 유리
*거래내역,주문리스트,게시판 등 한페이지에 많은 건수를 보여줄 필요가 없이 특정부분만 보여주는 oltp 시스템에 유리

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

- Hash Join -
*CBO에서만 가능
*Equi-Join에서만 가능(가상적으로 집합을 만들어서 유도 가능)
*hash_area_size에 의해 성능 결정
*CPU POWER에 의존적
*대용량의 자료를 Access 하는 경우 Sort Merge Join,Nested Join보다 빠름
*hash_join_enabled=true의 상태에서 가능
*Hash_multiblock_io_count 개수만큼의 블록들을 동시에 read/write 가능(Hash Partition)
*절반의 부분범의 처리
*선행 table은 가능하면 작은 cardinality,조건에 의해 선택도가 적은 것을 선택
*USE_HASH hint
*Batch Job에서 Parallel SQL와 함께 사용가능

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

- IOT(INDEX ORGRANIZED TABLE) -
일반 테이블에서 인덱스를 통해서 레코드를 액세스 할 때에는 키 값을 가지고 인덱스를 탐색해서 
ROWID를 얻은 다음에 다시 ROWID를 이용해서 테이블을 읽는 두 번의 과정을 거쳐야 합니다.? 
또한 키 컬럼이 인덱스와 테이블 양 쪽에 중복해서 저장되므로 키 값이 큰 경우에는 디스크의 낭비 또한 무시할 수 없습니다. 
이러한 문제점을 해결하고자 고안된 것이 IOT(Index Organized Table)입니다.

IOT는 인덱스 안에 테이블을 넣어 버린 구조로 되어 있기 때문에 인덱스를 읽는 것으로 모든 작업이 완료 됩니다.
키 값에 해당되는 레코드를 테이블에서 읽을 필요도 없고, 데이터의 중복 문제도 자연스럽게 해결할 수 있습니다.
IOT는 겉보기에는 테이블이지만 실제로는 기본 키(primary key)를 근간으로 한 인덱스이기 때문에 전제 조건으로 Primary Key를 필요로 합니다.
IOT를 생성하면 인덱스와 테이블이 같은 저장 구조에 생성되어 SQL 문이 실행되면,
무조건 IOT 인덱스를 통해 데이터를 검색하여 빠른 데이터 검색이 가능하고 저장 공간이 적게 사용 합니다.


특징
*IOT는 table data를 primary key에 대한 B*Tree index에 적재하는 구조를 갖습니다.
*IOT의 index row들은 인덱스 키 값과 non-key 값을 포한 합니다.
*IOT의 index에는 ROWID 정보가 없습니다.

장점
*RANGE SEARCH, EXACT MATCH를 수행하는 경우 일반적인 TABLE보다 빠른 KEY-BASED ACCESS가 가능 합니다.
*FULL TABLE SCAN 시 PRIMARY KEY에 대한 FULL INDEX SCAN이 이루어지므로 자동적인 ORDERING이 이루어 집니다.
*INDEX KEY COLUMN과 ROWID에 대한 STORAGE 중복을 피할 수 있어 STORAGE가 절약 됩니다

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

#세그먼트
오라클의 세그먼트(segment)는 디스크의 저장공간을 사용하는 객체다.

* 클러스터(Cluster): 클러스터 세그먼트는 테이블을 저장하는 세그먼트며, B*Tree 방식과 해시 방식이 존재한다.
클러스터는 다수 개 테이블의 데이터를 미리 조인하여 같은 데이터 블록에 함께 저장하거나 
하나의 테이블에서 관련된 데이터를 함께 저장하기 위해 사용된다.
클러스터라는 용어의 의미는 관련된 정보를 물리적으로 함께 묶는 기능을 말한다.

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

- 클러스터 -
조인이나 자주 사용되는 테이블의 데이터를 디스크의 같은 위치에 저장시키는 방법 입니다 
왜?) 디스크로부터 데이터를 읽어오는 시간을 줄이기 위해서 

- 클러스터된  테이블과  클러스터  되지  않은  테이블의  차이 -
테이블이 처음 생성될 때 행은 일반적으로 세그먼트의 첫 익스텐트의 첫 블록부터 삽입됩니다
정규 테이블로 저장될 경우 EMP와 DEPT은 서로 다른 세그먼트에 위치하게 됩니다. 이 말은 테이블이 자신들 고유의 블록을 사용한다는 뜻입니다.
즉, EMP 테이블의 행을 저장하는데 사용된 블록은 DEPT 테이블의 데이터를 저장하지 않습니다. 그 반대의 경우도 마찬가지입니다.
테이블 EMP와 DEPT의 클러스터로 저장되면 동일 클러스터 세그먼트를 공유하게 됩니다. 이 세그먼트의 블록은 양 테이블의 행을 모두 저장할 수 있습니다.
테이블이 클러스터로 저장되면 클러스터는 물리적 저장 단위가 되고 테이블은 논리적 엔티티 즉, 클러스터의 일부분이 됩니다.

- 클러스터의 장점 -
* 그룹된 컬럼 데이터 행들이 같은 데이터 Block에 저장되기 때문에 디스크 I/O를 줄여 줍니다.
* 클러스터된 테이블 사이에 조인이 발생할 경우 그 처리 시간이 단축 됩니다.
* 클러스터키 열을 공유하여 한번만 저장하므로 저장 영역의 사용을 줄입니다.

- 클러스터의 특징 -
클러스터는 데이터 조회 성능을 향상 시키지만 데이터 저장, 수정, 삭제 또는 한 테이블 전체 Scan의 성능을 감소 시킵니다 

- 클러스터 하기 좋은 테이블 -
* 주로 조회가 자주 발생하고 수정이 거의 발생하지 않는 테이블
* 컬럼안의 많은 중복 데이터를 가지는 테이블
* 자주 Join되는 테이블

- 클러스터 Key가 되기 좋은 컬럼 -
* 데이터 값의 범위가 큰 컬럼
* 테이블 간의 조인에 사용되는 컬럼

- 클러스터 key가 되기 나쁜 컬럼 -
* 특정 데이터 값이 적은 컬럼
* 자주 데이터 수정이 발생하는 컬럼
* LONG, LONG RAW 컬럼은 포함할 수 없습니다.

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

- 파티셔닝 -
테이블과 인덱스 데이터를 파티션단위로 나누어 저장하는 것을 말한다. 
파티셔닝하면 하나의 테이블일지라도 파티션 키에 따라 물리적으로 별도의 세그먼트에 데이터가 저장됨, 인덱스도

- 파티션 테이블 장점 -
* 데이터 액세스시 범위를 액세스 범위를 줄여 Performance 향상을 가져올 수 있습니다.
* 여러 분할 영역으로 관리되어 데이터 훼손 가능성이 감소 되고, I/O 성능 향상을 가져 올 수 있습니다.
* 각 분할 영역을 독립적으로 백업하고 복구 할 수 있습니다
--------------------------------------------------------------------------------------------------------------------------