Sort Merge Join이란 양쪽 테이블의 처리범위를 각자 액세스하여 정렬한 결과를 차례로 스캔하면서 연결고리의 조건으로 머지해 가는 방식을 말한다. 이 방식은 경우에 따라 Nested Loop Join보다 훨씬 빨라지는 경우도 많이 있으며 랜덤 액세스가 줄어들어 시스템의 부하를 감소시키지만 일반적으로 Nested Loop Join 보다는 사용되는 빈도가 적은 편이다.

이 방식의 가장 큰 특징은 상대방에게 아무런 값도 받지 않고 자신이 가지고 있는 조건만으로 처리범위가 정해지며, 랜덤 액세스를 줄일 수는 있으나 항상 전체범위처리를 한다는 것이다.

1. 특징
1) 동시적으로 처리된다. 테이블 각자가 자신의 처리범위를 액세스하여 정렬해 둔다.
2) 각 테이블은 다른 테이블에서 어떠한 상수값도 제공받지 않는다. 즉, 자신에게 주어진 상수값에 의해서만 범위를 줄인다.
3) 결코 부분범위처리를 할 수가 없으며, 항상 전체범위처리를 한다.
4) 주로 스캔방식으로 처리된다. 자신의 처리범위를 줄이기 위해 인덱스를 사용하는 경우만 랜덤 액세스이고 머지작업은 스캔방식이다.
5) 주어진 조건에 있는 모든 컬럼들이 인덱스를 가지고 있더라도 모두가 사용되는 것은 아니다. 연결고리가 되는 컬럼은 인덱스를 전혀 사용하지 않는다.
6) 조인의 방향과는 전혀 무관하다.
7) 스스로 자신의 처리범위를 줄이기 위해 사용되는 인덱스는 대개 가장 유리한 한가지만 사용되어진다. 그러나 그 외의 조건들은 비록 인덱스를 사용하지 못하더라도 작업대상을 줄여 주기 때문에 중요한 의미를 가진다.

2. 사용기준
1) 전체 범위처리를 하는 경우에 주로 유리해진다.
2) 상대방 테이블에서 어떤 상수값을 받지 않고도 처리범위를 줄일 수 있는 상태인 경우 주로 유리해 질 수 있다. 상수값을 받아 처리(Nested Loop Join)한 범위의 크기와 처리범위를 줄여 처리(Sort Merge Join)한 범위의 크기를 대비해보아 상수값을 받아 줄여진 범위가 약 30% 이상이라면 Sort Merge Join이 일반적으로 유리해진다. 그러나 부분범위처리가 되는 경우라면 전혀 달라질 수 있다. 이런 경우는 처리할 전체범위를 비교하지 말고 첫번째 운반단위에 도달하기 위해 액세스하는 범위애 대해서 판단해야 한다.
3) 주로 처리량이 많은 경우 (항상 전체 범위처리를 해야 하는 경우)에 유리해진다. 그것은 처리방식이 주로 스캔방식이므로 많은 양의 랜덤 액세스를 줄일 수가 있기 때문이다.
4) 연결고리 이상 상태에 영향을 받지 않으므로 연결고리를 위한 인덱스를 생성할 필요가 없을 때 유용하게 사용할 수 있다.
5) 스스로 자신의 처리범위를 어떻게 줄일 수 있느냐가 수행 속도에 많은 영향을 미치므로 보다 효율적으로 액세스할 수 있는 인덱스 구성이 중요한다.
6) 전체범위처리를 하므로 운반단위의 크기가 수행 속도에 영향을 미치지 않는다. 가능한 운반단위를 크게 하는 것이 페치(Fetch) 횟수를 줄여준다. 물론 지나치게 큰 운반단위는 시스템에 나쁜 영향을 미친다.
7) 처리할 데이터량이 적은 온라인 애플리케이션에서는 Nested Loop Join이 유리한 경우가 많으므로 함부로 Sort Merge Join을 사용하지 말아야 한다.
8) 옵티마이저 목표(Goal)가  "ALL_ROWS"인 경우는 자주 Sort Merge Join으로 실행계획이 수립되므로 부분범위처리를 하고자 한다면 이 옵티마이져 목표가 어떻게 지정되어 있는지에 주의하여야 한다.

'Database > Oracle' 카테고리의 다른 글

오라클 기본 용어들  (0) 2010.04.08
오라클 옵션  (1) 2010.04.02
Nested Loop Join - 중첩 루프 조인  (0) 2010.04.01
드라이빙 테이블이란?  (0) 2010.03.30
hint 종류  (0) 2010.03.30

Nested Loop Join이란 먼저 어떤 테이블의 처리범위를 하나씩 액세스하면서 그 추출된 값으로 연결할 테이블을 조인하는 방식이다.

1. 특징
1) 순차적으로 처리된다. 선행테이블(Driving table)의 처리범위에 있는 각각의 로우들이 순차적으로 수행될 뿐만 아니라 테이블간의 연결도 순차적이다.
2) 먼저 액세스되는 테이블(Driving Table)의 처리범위에 의해 처리량이 결정된다.
3) 나중에 처리되는 테이블은 앞서 처리된 값을 받아 액세스된다. 즉, 자신에게 주어진 상수값에 의해 스스로 범위를 줄이는 것이 아니라 값을 받아서 처리범위가 정해진다.
4) 주로 랜덤 액세스 방식으로 처리된다. 선행 테이블의 인덱스 액세스는 첫번째 로우만 랜덤 액세스이고 나머지는 스캔이며 연결작업은 모두 랜덤 액세스이다.
5) 주어진 조건에 있는 모든 컬럼들이 인덱스를 가지고 있더라도 모두가 사용되는 것은 아니다. 연결되는 방향에 따라 사용되는 인덱스들이 전혀 달라질 수 있다.
6) 연결고리가 되는 인덱스에 의해 연결작업이 수행되므로 연결고리 상태가 매우 중요하다. 연결고리의 인덱스 유무에 따라 액세스 방향 및 수행속도에 많은 차이가 발생된다.
7) 연결작업 수행 후 마지막으로 check되는 조건은 부분범위처리를 하는 경우에는 조건의 범위가 넓을수록, 아예 없다면 오히려 빨라진다.

2. 사용기준
1) 부분범위처리를 하는 경우에 주로 유리해진다.
2) 조인되는 어느 한쪽이 상대방 테이블에서 추출된 결과를 받아야 처리범위를 줄일 수 있는 상태라면 항상 유리해진다.
3) 주로 처리량이 적은 경우(많더라도 부분범위처리가 가능한 경우)에 유리해진다. 그것은 처리방식이 주로 랜덤 액세스방식이므로 많은 양의 랜덤 액세스가 발생한다면 수행속도가 당연히 나빠지기 때문이다.
4) 가능한 한 연결고리 이상 상태를 만들지 않도록 주의해야 한다.
5) 순차적으로 처리되기 때문에 어떤 테이블이 먼저 액세스되느냐에 따라 수행속도에 많은 영향을 미치므로 최적의 액세스 순서가 되도록 적절한 조치가 요구된다.
6) 부분범위처리를 하는 경우에는 운반단위 크기가 수행속도에 많은 영향을 미칠 수 있다. 운반단위가 적을 수록 빨리 운반단위를 채울 수 있으나, 폐치(Fetch) 횟수에서는 불리해지는 이중성을 가지고 있다.
7) 선행 테이블의 처리 범위가 많거나 연결 테이블의 랜덤 액세스의 양이 아주 많다면 Sort Merge 조인보다 불리해지는 경우가 많다.

'Database > Oracle' 카테고리의 다른 글

오라클 옵션  (1) 2010.04.02
Sort Merge Join  (0) 2010.04.01
드라이빙 테이블이란?  (0) 2010.03.30
hint 종류  (0) 2010.03.30
대량의 데이터 INSERT(HINT)  (0) 2010.02.01

TABLE에 대한 JOIN시 먼저 ACCESS되서 ACCESS PATH를 주도하는 TABLE을 DRIVING TABLE이라 한다.
DRIVING TABLE로 결정되는 것은 INDEX의 존재 및 우선순위 혹은 FROM절에서의 TABLE지정순서에 영향을 받으며 어느 TABLE이 먼저 ACCESS되느냐에 따라 속도의 차이가 크게 날 수 있으므로 매우 중요하다. 기본적으로 대상 TABLE의 행 중 작업대상이 되는 행의 수 가 적은 쪽이 먼저 ACCESS되어야 전체 일 양이 줄어든다. Driving table의 결정 규칙은 다음과 같다.

. JOIN 되는 컬럼의 한쪽에만 INDEX가 있는 경우는 INDEX가 지정된 TABLE이 DRIVING TABLE이 된다.

WHERE emp.deptno = dept.deptno 문장에서 dept.deptno에 index가 있는 경우는 Dept 테이블이드라이빙 테이블이 된다.
WHERE emp.deptno = dept.deptno 문장에서 emp.deptno에 index가 있는 경우는 Emp 테이블이 드라이빙 테이블이 된다.

WHERE emp.deptno = dept.deptno
AND emp.empno=7788
AND loc like 'Ca%'

deptno, empno컬럼이 조합해서 인덱스 . loc와 deptno컬럼이 조합해서 인덱스가 이루어져 있는경우 Dept 테이블이 드라이빙 테이블이 되고 만일 인덱스가 empno와deptno컬럼이 조합해서 인덱스, deptno와loc컬럼이 조합해서 인덱스로 구성되어 있으면 Emp 테이블이 드라이빙 테이블이 된다..조건절에 두 테이블 조인 조건외에 다른 비교 조건이 지정된 경우 INDEX의 우선순위에 따라 먼저 수행된는 테이블이 드라이빙 테이블이 된다.

WHERE emp.deptno = dept.deptno
AND emp.empno = 1166
AND dept.loc like 'da%'
emp.deptno, dept.deptno, empno,loc에 인덱스가 있는 경우는 empno와 loc중 우선순위가 높은 empno 인덱스를 먼저 사용하여 검색한다. 만일 이때 loc 라는 인덱스를 사용하고 싶으면 emp.empno=1166을 rtrim(empno)=1166 로 바꾸어 사용하면 empno의 인덱스 사용을 억제할수 있다.

더욱 이해를 돕기위해 다음의 예를 살펴보자.
DEPT.DEPTNO 컬럼에 Unique 인덱스
LOC 컬럼에 Unique 인덱스
EMP.JOB 과 EMP.ENAME 컬럼을 조합한 Unique Index
EMP.DEPTNO 에 인덱스 가 있다고 가정하자

WHERE d.deptno = e.deptno AND job='PRESIDENT'
AND ename='KING' AND loc='NEW YORK'
AND dname='ACCOUNTING' 의 문장 수행을 위한 내부적인 수행은 다음과 같다.

만일 DEPT 테이블이 드라이빙 테이블이라면
loc='NEW YORK'
dname = 'ACCOUNTING'

만일 EMP 테이블이 드라이빙 테이블이라면
job= 'PRESIDENT'
ename =' KING' 이다.

즉 DEPT 테이블이 unique 인덱스 를 사용하고 EMP 테이블은 컬럼이 조합된 unique 인덱스를 사용하므로 우선순위가 높은 DEPT 테이블이 DRIVING TABLE이 된다.

'Database > Oracle' 카테고리의 다른 글

Sort Merge Join  (0) 2010.04.01
Nested Loop Join - 중첩 루프 조인  (0) 2010.04.01
hint 종류  (0) 2010.03.30
대량의 데이터 INSERT(HINT)  (0) 2010.02.01
Oracle Function Reference  (0) 2009.12.30
/*+ ALL_ROWS */
explicitly chooses the cost-based approach to optimize a statement block with a goal of best throughput (that is, minimum total resource consumption)
가장 좋은 단위 처리량의 목표로 문 블록을 최적화하기 위해 cost-based 접근 방법을 선택합니다. (즉, 전체적인 최소의 자원 소비)

/*+ CHOOSE */
causes the optimizer to choose between the rule-based approach and the cost-based approach for a SQL statement
based on the presence of statistics for the tables accessed by the statement
최적자(optimizer)가 그 문에 의해 접근된 테이블을 위해 통계의 존재에 근거를 두는 SQL 문을 위해 rule-based 접근 방법과 cot-based 접근 방법 사이에 선택하게 합니다.

/*+ FIRST_ROWS */
explicitly chooses the cost-based approach to optimize a statement block with a goal of best response time (minimum
resource usage to return first row)
가장 좋은 응답 시간의 목표로 문 블록을 최적화하기 위해 cost-based 접근 방법을 선택합니다. (첫번째 행을 되돌려 주는 최소의 자원 사용)

/*+ RULE */
explicitly chooses rule-based optimization for a statement block
문 블록을 위하여, rule-based 최적화를 고르는

/*+ AND_EQUAL(table index) */
explicitly chooses an execution plan that uses an access path that merges the scans on several single-column indexes
그만큼 실행 계획을 선택합니다. 그리고 여럿의 single-column 색인에 그 scan을 합병하는 접근 경로를 사용합니다.

/*+ CLUSTER(table) */
explicitly chooses a cluster scan to access the specified table
선택합니다. 그리고, 클러스터는 그 명시된 테이블을 접근하기 위해 살핍니다.

/*+ FULL(table) */
explicitly chooses a full table scan for the specified table
그 명시된 테이블을 위하여, 전체 테이블 scan을 고르는

/*+ HASH(table) */
explicitly chooses a hash scan to access the specified table
선택합니다. 그리고, 해쉬는 그 명시된 테이블을 접근하기 위해 운율을 살핍니다.

/*+ HASH_AJ(table) */
transforms a NOT IN subquery into a hash antijoin to access the specified table
변환, 그 명시된 테이블을 접근하는 해쉬 antijoin으로의 NOT IN 부속 조회

/*+ HASH_SJ (table) */
transforms a NOT IN subquery into a hash anti-join to access the specified table
변환, 그 명시된 테이블을 접근하는 해쉬 anti-join으로의 NOT IN 부속 조회

/*+ INDEX(table index) */
explicitly chooses an index scan for the specified table 그 명시된 테이블을 위하여, 색인 scan을 고르는

/*+ INDEX_ASC(table index) */
explicitly chooses an ascending-range index scan for the specifiedtable
그 명시된 테이블을 위하여, ascending-range 색인 scan을 고르는

/*+ INDEX_COMBINE(table index) */
If no indexes are given as arguments for the INDEX_COMBINE hint, the optimizer uses whatever Boolean combination
of bitmap indexes has the best cost estimate. If particular indexes are given as arguments, the optimizer tries to use
some Boolean combination of those particular bitmap indexes.
어떤 색인도 INDEX_COMBINE 암시를 위해 인수로서 주어지지 않는다면, bitmap 색인의 결합이 어떤 부울의를 가장 좋은 수행 난이도 평가를 가지고 있든지 최적자는 이용합니다.
특별한 색인이 인수로서 주어진다면, 최적자는 그 특별한 bitmap 색인의 몇몇의 부울의 결합을 사용하려고 노력합니다.

/*+ INDEX_DESC(table index) */
explicitly chooses a descending-range index scan for the specified table
그 명시된 테이블을 위하여, descending-range 색인 scan을 고르는

/*+ INDEX_FFS(table index) */
causes a fast full index scan to be performed rather than a full table scan
빠른 전체 색인 scan이 전체 테이블 scan이라기보다는 수행되게 합니다.

/*+ MERGE_AJ (table) */
transforms a NOT IN subquery into a merge anti-join to access the specified table
변환, NOT IN 부속 조회, 그 명시된 테이블을 접근하기 위해 anti-join을 합병합니다.

/*+ MERGE_SJ (table) */
transforms a correlated EXISTS subquery into a merge semi-join to access the specified table
변환, 관련된 EXISTS 부속 조회, 접근으로 semi-join을 합병합니다, 그 명시된 테이블

/*+ ROWID(table) */
explicitly chooses a table scan by ROWID for the specified table
그 명시된 테이블을 위하여, ROWID에 의해 테이블 scan을 고르는

/*+ USE_CONCAT */
forces combined OR conditions in the WHERE clause of a query to be transformed into a compound query using the
UNION ALL set operator
힘은 질의의 WHERE 문절에 있는 UNION ALL 집합 연산자를 사용하는 합성의 질의로 변형되는 OR 조건을 합쳤습니다.

/*+ ORDERED */
causes Oracle to join tables in the order in which they appear in the FROM clause
오라클이 어느 것에 순서로 테이블을 결합시키게 합니다.

/*+ STAR */
forces the large table to be joined last using a nested-loops join on the index
큰 있는 테이블이 최종 사용/회전율에 nested-loops를 결합시킨 힘은 그 색인에 결합합니다.

/*+ DRIVING_SITE (table) */
forces query execution to be done at a different site from that selected by Oracle
힘은 그것과 다른 오라클에 의해 선택된 사이트에 되는 실행을 질의합니다.

/*+ USE_HASH (table) */
causes Oracle to join each specified table with another row source with a hash join
오라클이 테이블이 다른 행 자원으로 해쉬 접합으로 명시되면서 각자와 합치게 합니다.

/*+ USE_MERGE (table) */
causes Oracle to join each specified table with another row source with a sort-merge join
오라클이 테이블이 다른 행 자원으로 sort-merge 접합으로 명시되면서 각자와 합치게 합니다.

/*+ USE_NL (table) */
causes Oracle to join each specified table to another row source with a nested-loops join using the specified table as the inner table
오라클이 그 명시된 테이블을 그 안의 테이블로 사용하는 nested-loops 접합과 각자와 다른 행 자원에 대한 명시된 테이블을 합치게 합니다.

/*+ APPEND */ , /*+ NOAPPEND */
specifies that data is simply appended (or not) to a table; existing free space is not used. Use these hints only following the INSERT keyword.
데이타가 테이블로 단순히 덧붙여진다는 (or not)것 명시합니다; 무료인 현존하는 영역은 사용되지 않습니다.
단지 그 삽입 키 핵심어를 따르는 이 암시를 사용하시오.

/*+ NOPARALLEL(table) */
disables parallel scanning of a table, even if the table was created with a PARALLEL clause
그 테이블이 PARALLEL 문절로 새로 만들어졌다면 테이블의 평행의 순차 검색을 무능하게 만듭니다.

/*+ PARALLEL(table, instances) */
allows you to specify the desired number of concurrent slave processes that can be used for the operation.
DELETE, INSERT, and UPDATE operations are considered for parallelization only if the session is in a PARALLEL DML
enabled mode. (Use ALTER SESSION PARALLEL DML to enter this mode.)
당신이 그 연산을 위해 사용될 수 있는 동시의 슬레이브(slave) 프로세스의 요구된 수를 명시하는 것을 허락합니다.
그 세션이 가능하게 된 PARALLEL DML에 모드를 있다면, DELETE, INSERT, UPDATE 연산은 단지 parallelization에 대해 고려됩니다. (사용은 이 모드에 들어가기 위해 평행의 세션 DML을 변경합니다.) 

PARALLEL hint를 사용하면 query에 포함된 table의 degree를 설정할 수 있습니다.
 
예를 들어, 다음과 같이 hint를 적어 degree 4로 parallel query option을  실행하도록 할 수 있습니다.
이 때 parallel이란 글자와 괄호( ’(’ )사이에 blank를 넣지 않도록 주의해야 합니다.
  
SQL>SELECT /*+ PARALLEL(emp, 4) */   * FROM emp;
 
* DEGREE의 의미 및 결정
 
Parallel Query에서 degree란 하나의 operation 수행에 대한 server process의 개수 입니다.
이러한 degree 결정에 영향을 주는 요인들에는 다음과 같은 것들이 있습니다.
(1)  system의 CPU 갯수
(2)  system의 maximum process 갯수
(3)  table이 striping되어 있는 경우, 그 table이 걸쳐있는 disk의 갯수
(4)  data의 위치 (즉, memory에 cache되어 있는지, disk에 있는지)
(5)  query의 형태 (예를 들어 sorts 혹은 full table scan)
 
한 사용자만이 parallel query를 사용하는 경우, sorting이 많이 필요한 작업과 같은 CPU-bound 작업의 경우는 CPU 갯수의 1 ~ 2배의 degree가 적당하며, sorting보다는 table scan과 같은 I/O bound 작업의 경우는 disk drive 갯수의 1 ~ 2배가 적당합니다.
 
동시에 수행되는 parallel query가 많은 경우에는 위의 각 사용자의 degree를 줄이거나 동시에 사용하는 사용자 수를 줄여야 합니다.

PARALLEL QUERY PROCESSING이 사용되어질 수 있는 SQL 문장의 종류

(1) SELECT 문장
(2) UPDATE, INSERT, DELETE 문 내의 subquery
(3) CREATE TABLE ... AS SELECT 문
(4) CREATE INDEX 문
위와 같은 문장 내에 최소한 하나의 full table scan operation이 포함되어야 query가 parallelize된다.

병렬로 수행하기 위해서는 세션을 'ALTER SESSION ENABLE PARALLEL DML'로 지정해야만 사용 가능하다.
반대 'ALTER SESSION DISABLE PARALLEL DML'

/*+ PARALLEL_INDEX
allows you to parallelize fast full index scan for partitioned and nonpartitioned indexes that have the PARALLEL attribute
parallelize에 당신에게 빠른 가득한 색인 scan을 허락합니다. 그런데, 그것은 PARALLEL 속성을 가지고 있는 색인을 분할했고 nonpartitioned했습니다.

/*+ NOPARALLEL_INDEX */
overrides a PARALLEL attribute setting on an index
병렬이 색인을 나아가는 것을 속하게 하는 대체

/*+ CACHE */
specifies that the blocks retrieved for the table in the hint are placed at the most recently used end of the LRU list in the
buffer cache when a full table scan is performed
그 블록이 찾아서 가져왔다는 것을 명시합니다. 그리고 그 테이블을 위해 그 암시에 놓여집니다. 그런데, 그것은 가장 요즈음 사용된 언제 그 버퍼 캐쉬, 가득한 테이블 scan에 있는 LRU 리스트의 끝입니다. 수행됩니다.

/*+ NOCACHE */
specifies that the blocks retrieved for this table are placed at the least recently used end of the LRU list in the buffer cache when a full table scan is performed
그 명시합니다. 그리고, 그 블록은 이 테이블을 위해 검색되면서 요즈음 사용된 언제 그 버퍼 캐쉬, 가득한 테이블 scan에 있는 LRU 리스트의 가장 작은 끝에 놓여집니다. 수행됩니다.

/*+ MERGE (table) */
causes Oracle to evaluate complex views or subqueries before the surrounding query
오라클이 그 둘러싸는 질의 전에 복잡한 뷰나 부속 조회를 평가하게 합니다.

/*+ NO_MERGE (table) */
causes Oracle not to merge mergeable views
오라클이 mergeable 뷰를 합병하지 않게 하지 않습니다

/*+ PUSH_JOIN_PRED (table) */
causes the optimizer to evaluate, on a cost basis, whether or not to push individual join predicates into the view
개개 접합을 미는 것이 그 뷰 안으로 단정 하든 간에 비용 방식으로 최적자가 평가하게 합니다.

/*+ NO_PUSH_JOIN_PRED (table) */
Prevents pushing of a join predicate into the view
접합 술부 중에서 그 뷰로 밀면서, 막는

/*+ PUSH_SUBQ */
causes nonmerged subqueries to be evaluated at the earliest possible place in the execution plan
원인은 그 실행 계획에서의 가장 이른 가능한 장소에 평가되는 부속 조회를 nonmerged했습니다.

/*+ STAR_TRANSFORMATION */
makes the optimizer use the best plan in which the transformation has been used.
최적자가 그 변형이 사용된 가장 좋은 계획을 사용하는 제작


*오라클 힌트 사용표

INDEX ACCESS OPERATION 관련 HINT
HINT 내용 사용법
INDEX  INDEX를 순차적으로 스캔 INDEX(TABLE명, INDEX명)
INDEX_DESC INDEX를 역순으로 스캔 INDEX_DESC(TABLE명, INDEX명)
INDEX_FFS INDEX FAST FULL SCAN INDEX_FFS(TABLE명, INDEX명)
PARALLEL_INDEX INDEX PARALLEL SCAN PARALLEL_INDEX(TABLE명,INDEX명)
NOPARALLEL_INDEX INDEX PARALLEL SCAN 제한 NOPARALLEL_INDEX(TABLE명,INDEX명)
AND_EQUALS INDEX MERGE 수행 AND_EQUALS(INDEX_NAME, INDEX_NAME)
FULL FULL SCAN FULL(TALBE명)
JOIN ACCESS OPERATION 관련 HINT
HINT 내용 사용법
USE_NL NESTED LOOP JOIN USE_NL(TABLE1, TABLE2)
USE_MERGE SORT MERGE JOIN USE_MERGE(TABBLE1, TABLE2)
USE_HASH HASH JOIN USE_HASH(TABLE1, TABLE2)
HASH_AJ HASH ANTIJOIN HASH_AJ(TABLE1, TABLE2)
HASH_SJ HASH SEMIJOIN HASH_SJ(TABLE1, TABLE2)
NL_AJ NESTED LOOP ANTI JOIN NL_AJ(TABLE1, TABLE2)
NL_SJ NESTED LOOP SEMIJOIN NL_SJ(TABLE1, TABLE2)
MERGE_AJ SORT MERGE ANTIJOIN MERGE_AJ(TABLE1, TABLE2)
MERGE_SJ SORT MERGE SEMIJOIN MERGE_SJ(TABLE1, TABLE2)
JOIN시 DRIVING 순서 결정 HINT
HINT 내용
ORDERED FROM 절의 앞에서부터 DRIVING
DRIVING 해당 테이블을 먼저 DRIVING- driving(table)
기타 힌트
HINT 내용
append insert 시 direct loading
parallel select, insert 시 여러 개의 프로세스로 수행- parallel(table, 개수)
cache 데이터를 메모리에 caching
nocache 데이터를 메모리에 caching하지 않음
push_subq subquery를 먼저 수행
rewrite query rewrite 수행
norewrite query rewrite 를  수행 못함
use_concat in절을 concatenation access operation으로 수행
use_expand in절을 concatenation access operation으로 수행 못하게 함
merge view merging 수행
no_merge view merging 수행 못하게 함

'Database > Oracle' 카테고리의 다른 글

Nested Loop Join - 중첩 루프 조인  (0) 2010.04.01
드라이빙 테이블이란?  (0) 2010.03.30
대량의 데이터 INSERT(HINT)  (0) 2010.02.01
Oracle Function Reference  (0) 2009.12.30
환경알기  (0) 2009.12.30

+ Recent posts