페이지 이력
...
| 힌트 | 설명 (원문) | 설명 (번역) | 예제 |
|---|---|---|---|
| ALL_ROWS | The ALL_ROWS hint instructs the optimizer to optimize a statement block with a goal of best throughput, which is minimum total resource consumption. If you specify either the ALL_ROWS or the FIRST_ROWS hint in a SQL statement, and if the data dictionary does not have statistics about tables accessed by the statement, then the optimizer uses default statistical values, such as allocated storage for such tables, to estimate the missing statistics and to subsequently choose an execution plan. These estimates might not be as accurate as those gathered by the DBMS_STATS package, so you should use the DBMS_STATS package to gather statistics. If you specify hints for access paths or join operations along with either the ALL_ROWS or FIRST_ROWS hint, then the optimizer gives precedence to the access paths and join operations specified by the hints. | ALL_ROWS 힌트는 최소 총 리소스 소비인 최상의 처리량을 목표로 구문 블록을 최적화하도록 옵티마이저에 지시합니다. SQL 문에 ALL_ROWS 또는 FIRST_ROWS 힌트를 지정한 경우 데이터 딕셔너리에에 구문에서 액세스한 테이블에 대한 통계가 없는 경우 옵티마이저는 해당 테이블에 대해 할당된 스토리지와 같은 기본 통계 값을 사용하여 누락된 통계를 추정하고 실행 계획을 선택합니다. 이러한 추정치는 DBMS_STATS 패키지에서 수집한 추정치만큼 정확하지 않을 수 있으므로 DBMS_STATS 패키지를 사용하여 통계를 수집해야 합니다. ALL_ROWS 또는 FIRST_ROWS 힌트와 함께 액세스 경로 또는 조인 작업에 대한 힌트를 지정하면 옵티마이저은 힌트로 지정된 액세스 경로 및 조인 작업에 우선 순위를 부여합니다. | SELECT /*+ ALL_ROWS */ employee_id, last_name, salary, job_id FROM employees WHERE employee_id = 107; |
| APPEND | The APPEND hint instructs the optimizer to use direct-path INSERT with the subquery syntax of the INSERT statement. - Conventional INSERT is the default in serial mode. In serial mode, direct path can be used only if you include the APPEND hint. - Direct-path INSERT is the default in parallel mode. In parallel mode, conventional insert can be used only if you specify the NOAPPEND hint. The decision whether the INSERT will go parallel or not is independent of the APPEND hint. In direct-path INSERT, data is appended to the end of the table, rather than using existing space currently allocated to the table. As a result, direct-path INSERT can be considerably faster than conventional INSERT. The APPEND hint is only supported with the subquery syntax of the INSERT statement, not the VALUES clause. If you specify the APPEND hint with the VALUES clause, it is ignored and conventional insert will be used. To use direct-path INSERT with the VALUES clause, refer to "APPEND_VALUES Hint". | APPEND 힌트는 옵티마이저가 INSERT 문의 서브 쿼리 구문과 함께 direct-path INSERT를 사용하도록 지시합니다. - 일반적인 INSERT는 serial 모드에서 기본값입니다. serial 모드에서는 APPEND 힌트를 포함해야만 direct-path를 사용할 수 있습니다. - Direct-path INSERT는 parallel 모드에서 기본값입니다. parallel 모드에서 기존 INSERT는 NOAPPEND 힌트를 지정한 경우에만 사용할 수 있습니다. INSERT가 parallel로 진행될지 여부는 APPEND 힌트와 무관합니다. direct-path INSERT에서는 테이블에 현재 할당된 기존 공간을 사용하지 않고 테이블 끝에 데이터를 추가합니다. 결과적으로 direct-path INSERT는 일반적인 INSERT보다 훨씬 빠를 수 있습니다. APPEND 힌트는 VALUES 절이 아닌 INSERT 문의 서브 쿼리 구문에서만 지원됩니다. VALUES 절과 함께 APPEND 힌트를 지정하면 무시되고 일반적인 insert가 사용됩니다. VALUES 절과 함께 direct-path INSERT를 사용하려면 "APPEND_VALUES 힌트"를 참조하십시오. | |
| APPEND_VALUES | The APPEND_VALUES hint instructs the optimizer to use direct-path INSERT with the VALUES clause. If you do not specify this hint, then conventional INSERT is used. In direct-path INSERT, data is appended to the end of the table, rather than using existing space currently allocated to the table. As a result, direct-path INSERT can be considerably faster than conventional INSERT. The APPEND_VALUES hint can be used to greatly enhance performance. Some examples of its uses are: - In an Oracle Call Interface (OCI) program, when using large array binds or array binds with row callbacks - In PL/SQL, when loading a large number of rows with a FORALL loop that has an INSERT statement with a VALUES clause The APPEND_VALUES hint is only supported with the VALUES clause of the INSERT statement. If you specify the APPEND_VALUES hint with the subquery syntax of the INSERT statement, it is ignored and conventional insert will be used. To use direct-path INSERT with a subquery, refer to "APPEND Hint". | ADPEND_VALUE 힌트는 옵티마이저에 VALUE 절과 함께 direct-path INSERT를 사용하도록 지시합니다. 이 힌트를 지정하지 않으면 일반적인 INSERT가 사용됩니다. Direct-path INSERT에서는 테이블에 현재 할당된 기존 공간을 사용하지 않고 테이블 끝에 데이터가 추가됩니다. 결과적으로 direct-path INSERT는 일반적인 INSERT보다 상당히 빠를 수 있습니다. ADPEND_VALUE 힌트를 사용하여 성능을 크게 향상시킬 수 있습니다. 사용 예는 다음과 같습니다: - OCI(Oracle Call Interface) 프로그램에서 큰 어레이 바인딩 또는 행 콜백이 있는 어레이 바인딩을 사용하는 경우 - PL/SQL에서 VALUE 절이 있는 INSERT 문이 있는 FORALL 루프로 많은 행을 로드하는 경우 APPEND_VALUE 힌트는 INSERT 문의 VALUE 절에서만 지원됩니다. INSERT 문의 서브 쿼리 구문과 함께 ADPEND_VALUE 힌트를 지정하면 무시되고 일반적인 INSERT가 사용됩니다. 서브 쿼리와 함께 direct-path INSERT를 사용하려면 "APPEND 힌트"를 참조하십시오. | |
| CACHE | The CACHE hint instructs the optimizer to place the blocks retrieved for the table at the most recently used end of the LRU list in the buffer cache when a full table scan is performed. This hint is useful for small lookup tables. The CACHE and NOCACHE hints affect system statistics table scans (long tables) and table scans (short tables), as shown in the V$SYSSTAT data dictionary view. | CACHE 힌트는 풀 테이블 스캔이 수행될 때 버퍼 캐시에서 가장 최근에 사용된 LRU 목록 끝에 있는 테이블에 대해 검색된 블록을 배치하도록 옵티마이저에 지시합니다. 이 힌트는 작은 조회 테이블에 유용합니다. CACHE 및 NOCACHE 힌트는 V$SYSSTAT 데이터 딕셔너리 뷰에 표시된 것처럼 시스템 통계 테이블 스캔(긴 테이블) 및 테이블 스캔(짧은 테이블)에 영향을 미칩니다. | SELECT /*+ FULL (hr_emp) CACHE(hr_emp) */ last_name FROM employees hr_emp; |
| CHANGE_DUPKEY_ERROR_INDEX | |||
| CLUSTER | |||
| CLUSTERING | |||
| CONTAINERS | |||
| CURSOR_SHARING_EXACT | Oracle can replace literals in SQL statements with bind variables, when it is safe to do so. This replacement is controlled with the CURSOR_SHARING initialization parameter. The CURSOR_SHARING_EXACT hint instructs the optimizer to switch this behavior off. When you specify this hint, Oracle executes the SQL statement without any attempt to replace literals with bind variables. | Oracle은 안전한 경우 SQL 문의 리터럴을 바인드 변수로 바꿀 수 있습니다. 이러한 대체는 CURSOR_SHARING 초기화 파라미터로 제어됩니다. CURSOR_SHARING_EXACT 힌트는 옵티마이저에 이 동작을 끄도록 지시합니다. 이 힌트를 지정하면 Oracle은 리터럴을 바인드 변수로 바꾸려고 시도하지 않고 SQL 문을 실행합니다. | |
| DISABLE_PARALLEL_DML | |||
| DRIVING_SITE | The DRIVING_SITE hint instructs the optimizer to execute the query at a different site than that selected by the database. This hint is useful if you are using distributed query optimization. | DRIVING_SITE 힌트는 옵티마이저가 데이터베이스에서 선택한 사이트가 아닌 다른 사이트에서 쿼리를 실행하도록 지시합니다. 이 힌트는 분산 쿼리 최적화를 사용하는 경우에 유용합니다. | SELECT /*+ DRIVING_SITE(departments) */ * FROM employees, departments@rsite WHERE employees.department_id = departments.department_id; 이 쿼리가 힌트 없이 실행되면 departments의 행이 로컬 사이트로 전송되고 조인이 실행됩니다. 힌트를 사용하면 employees의 행이 원격 사이트로 전송되고 그곳에서 쿼리가 실행되고 결과 집합이 로컬 사이트로 반환됩니다. |
| DYNAMIC_SAMPLING | |||
| ELIMINATE_JOIN | |||
| ENABLE_PARALLEL_DML | |||
| FACT | |||
| FIRST_ROWS | The FIRST_ROWS hint instructs Oracle to optimize an individual SQL statement for fast response, choosing the plan that returns the first n rows most efficiently. For integer, specify the number of rows to return. The optimizer ignores this hint in DELETE and UPDATE statement blocks and in SELECT statement blocks that include any blocking operations, such as sorts or groupings. Such statements cannot be optimized for best response time, because Oracle Database must retrieve all rows accessed by the statement before returning the first row. If you specify this hint in any such statement, then the database optimizes for best throughput. | FIRST_ROWS 힌트는 빠른 응답을 위해 개별 SQL 문을 최적화하고 처음 n개 행을 가장 효율적으로 반환하는 계획을 선택하도록 Oracle에 지시합니다. 정수에는 반환할 행 수를 지정합니다. 옵티마이저는 DELETE 및 UPDATE 문 블록과 정렬 또는 그룹화와 같은 차단 작업을 포함하는 SELECT 문 블록에서 이 힌트를 무시합니다. Oracle Database는 첫 번째 행을 반환하기 전에 구문에서 액세스한 모든 행을 검색해야 하므로 이러한 구문은 최상의 응답 시간을 위해 최적화할 수 없습니다. 이러한 구문에 이 힌트를 지정하면 데이터베이스가 최적의 처리량을 위해 최적화됩니다. | SELECT /*+ FIRST_ROWS(10) */ employee_id, last_name, salary, job_id FROM employees WHERE department_id = 20; |
| FRESH_MV | |||
| FULL | The FULL hint instructs the optimizer to perform a full table scan for the specified table | FULL 힌트는 옵티마이저가 지정된 테이블에 대해 전체 테이블 스캔을 수행하도록 지시합니다. | SELECT /*+ FULL(e) */ employee_id, last_name FROM hr.employees e WHERE last_name LIKE :b1; |
| GATHER_OPTIMIZER_STATISTICS | |||
| GROUPING | |||
| HASH | The HASH hint instructs the optimizer to use a hash scan to access the specified table. This hint applies only to tables in a hash cluster. | HASH 힌트는 지정된 테이블에 액세스하기 위해 해시 스캔을 사용하도록 옵티마이저에 지시합니다. 이 힌트는 해시 클러스터의 테이블에만 적용됩니다. | |
| HASH_AJ | |||
| HASH_SJ | |||
| IGNORE_ROW_ON_DUPKEY_INDEX | |||
| INDEX | The INDEX hint instructs the optimizer to use an index scan for the specified table. You can use the INDEX hint for function-based, domain, B-tree, bitmap, and bitmap join indexes. - If the INDEX hint specifies a single available index, then the database performs a scan on this index. The optimizer does not consider a full table scan or a scan of another index on the table. - For a hint on a combination of multiple indexes, Oracle recommends using INDEX_COMBINE rather than INDEX, because it is a more versatile hint. If the INDEX hint specifies a list of available indexes, then the optimizer considers the cost of a scan on each index in the list and then performs the index scan with the lowest cost. The database can also choose to scan multiple indexes from this list and merge the results, if such an access path has the lowest cost. The database does not consider a full table scan or a scan on an index not listed in the hint. - If the INDEX hint specifies no indexes, then the optimizer considers the cost of a scan on each available index on the table and then performs the index scan with the lowest cost. The database can also choose to scan multiple indexes and merge the results, if such an access path has the lowest cost. The optimizer does not consider a full table scan. | INDEX 힌트는 지정된 테이블에 대해 인덱스 스캔을 사용하도록 옵티마이저에 지시합니다. 함수 기반, 도메인, B-트리, 비트맵 및 비트맵 조인 인덱스에 INDEX 힌트를 사용할 수 있습니다. - INDEX 힌트가 사용 가능한 단일 인덱스를 지정하는 경우 데이터베이스는 이 인덱스에 대해 스캔을 수행합니다. 옵티마이저는 전체 테이블 스캔 또는 테이블의 다른 인덱스 스캔을 고려하지 않습니다. - 여러 인덱스의 조합에 대한 힌트는 INDEX보다 활용도가 높은 INDEX_COMBINE을 사용하는 것이 좋습니다. INDEX 힌트가 사용 가능한 인덱스 목록을 지정하면 옵티마이저는 목록의 각 인덱스에 대한 스캔 비용을 고려한 다음 가장 낮은 비용으로 인덱스 스캔을 수행합니다. 데이터베이스는 또한 이러한 액세스 경로의 비용이 가장 낮은 경우 이 목록에서 여러 인덱스를 스캔하고 결과를 병합하도록 선택할 수 있습니다. 데이터베이스는 전체 테이블 스캔 또는 힌트에 나열되지 않은 인덱스에 대한 스캔을 고려하지 않습니다. - INDEX 힌트가 인덱스를 지정하지 않으면 옵티마이저는 테이블에서 사용 가능한 각 인덱스에 대한 스캔 비용을 고려한 다음 가장 낮은 비용으로 인덱스 스캔을 수행합니다. 이러한 액세스 경로의 비용이 가장 낮은 경우 데이터베이스는 여러 인덱스를 스캔하고 결과를 병합하도록 선택할 수도 있습니다. 옵티마이저는 전체 테이블 스캔을 고려하지 않습니다. | SELECT /*+ INDEX (employees emp_department_ix)*/ employee_id, department_id FROM employees WHERE department_id > 50; |
| INDEX_ASC | The INDEX_ASC hint instructs the optimizer to use an index scan for the specified table. If the statement uses an index range scan, then Oracle Database scans the index entries in ascending order of their indexed values. Each parameter serves the same purpose as in INDEX Hint. The default behavior for a range scan is to scan index entries in ascending order of their indexed values, or in descending order for a descending index. This hint does not change the default order of the index, and therefore does not specify anything more than the INDEX hint. However, you can use the INDEX_ASC hint to specify ascending range scans explicitly should the default behavior change. | INDEX_ASC 힌트는 지정된 테이블에 대해 인덱스 스캔을 사용하도록 옵티마이저에 지시합니다. 명령문이 인덱스 범위 스캔을 사용하는 경우 Oracle Database는 인덱스 항목을 인덱스 값의 오름차순으로 스캔합니다. 각 파라미터는 INDEX 힌트와 동일한 용도로 사용됩니다. 범위 스캔의 기본 동작은 인덱스 값의 오름차순 또는 내림차순 인덱스의 경우 내림차순으로 인덱스 항목을 스캔하는 것입니다. 이 힌트는 인덱스의 기본 순서를 변경하지 않으므로 INDEX 힌트 외에는 아무것도 지정하지 않습니다. 그러나 기본 동작이 변경되면 INDEX_ASC 힌트를 사용하여 오름차순 범위 스캔을 명시적으로 지정할 수 있습니다. | |
| INDEX_COMBINE | The INDEX_COMBINE hint can use any type of index: bitmap, b-tree, or domain. If you do not specify indexspec in the INDEX_COMBINE hint, the optimizer implicitly applies theINDEX hint to all indexes, using as many indexes as possible. If you specify indexspec, then the optimizer uses all the hinted indexes that are legal and valid to use, regardless of cost. Each parameter serves the same purpose as in INDEX Hint. | INDEX_COMBINE 힌트는 비트맵, B-트리 또는 도메인과 같은 모든 유형의 인덱스를 사용할 수 있습니다. INDEX_COMBINE 힌트에 indexspec을 지정하지 않으면 옵티마이저는 가능한 한 많은 인덱스를 사용하여 암시적으로 INDEX 힌트를 모든 인덱스에 적용합니다. indexspec을 지정하면 옵티마이저가 비용에 관계없이 사용하기에 적법하고 유효한 모든 힌트 인덱스를 사용합니다. 각 파라미터는 INDEX 힌트와 동일한 용도로 사용됩니다. | SELECT /*+ INDEX_COMBINE(e emp_manager_ix emp_department_ix) */ * FROM employees e WHERE manager_id = 108 OR department_id = 110; |
| INDEX_DESC | The INDEX_DESC hint instructs the optimizer to use a descending index scan for the specified table. If the statement uses an index range scan and the index is ascending, then Oracle scans the index entries in descending order of their indexed values. In a partitioned index, the results are in descending order within each partition. For a descending index, this hint effectively cancels out the descending order, resulting in a scan of the index entries in ascending order. Each parameter serves the same purpose as in INDEX Hint. | INDEX_DESC 힌트는 지정된 테이블에 대해 내림차순 인덱스 스캔을 사용하도록 옵티마이저에 지시합니다. 명령문이 인덱스 범위 스캔을 사용하고 인덱스가 오름차순인 경우 Oracle은 인덱스 값의 내림차순으로 인덱스 항목을 스캔합니다. 분할된 인덱스에서 결과는 각 분할 내에서 내림차순으로 표시됩니다. 내림차순 인덱스의 경우 이 힌트는 내림차순을 효과적으로 취소하여 인덱스 항목을 오름차순으로 스캔합니다. 각 파라미터는 INDEX 힌트와 동일한 용도로 사용됩니다. | SELECT /*+ INDEX_DESC(e emp_name_ix) */ * FROM employees e; |
| INDEX_FFS | The INDEX_FFS hint instructs the optimizer to perform a fast full index scan rather than a full table scan. | INDEX_FFS 힌트는 전체 테이블 스캔이 아닌 빠른 전체 인덱스 스캔을 수행하도록 옵티마이저에 지시합니다. | SELECT /*+ INDEX_FFS(e emp_name_ix) */ first_name FROM employees e; |
| INDEX_JOIN | The INDEX_JOIN hint instructs the optimizer to use an index join as an access path. For the hint to have a positive effect, a sufficiently small number of indexes must exist that contain all the columns required to resolve the query. | INDEX_JOIN 힌트는 인덱스 조인을 액세스 경로로 사용하도록 옵티마이저에 지시합니다. 힌트가 긍정적인 효과를 가지려면 쿼리를 해결하는 데 필요한 모든 열을 포함하는 충분히 적은 수의 인덱스가 있어야 합니다. | SELECT /*+ INDEX_JOIN(e emp_manager_ix emp_department_ix) */ department_id FROM employees e WHERE manager_id < 110 AND department_id < 50; |
| INDEX_SS | The INDEX_SS hint instructs the optimizer to perform an index skip scan for the specified table. If the statement uses an index range scan, then Oracle scans the index entries in ascending order of their indexed values. In a partitioned index, the results are in ascending order within each partition. | INDEX_SS 힌트는 옵티마이저가 지정된 테이블에 대해 인덱스 스킵 스캔을 수행하도록 지시합니다. 명령문이 인덱스 범위 스캔을 사용하는 경우 Oracle은 인덱스 값의 오름차순으로 인덱스 항목을 스캔합니다. 파티션 인덱스에서 결과는 각 파티션 내에서 오름차순으로 표시됩니다. | SELECT /*+ INDEX_SS(e emp_name_ix) */ last_name FROM employees e WHERE first_name = 'Steven'; |
| INDEX_SS_ASC | The INDEX_SS_ASC hint instructs the optimizer to perform an index skip scan for the specified table. If the statement uses an index range scan, then Oracle Database scans the index entries in ascending order of their indexed values. In a partitioned index, the results are in ascending order within each partition. Each parameter serves the same purpose as in INDEX Hint. The default behavior for a range scan is to scan index entries in ascending order of their indexed values, or in descending order for a descending index. This hint does not change the default order of the index, and therefore does not specify anything more than the INDEX_SS hint. However, you can use the INDEX_SS_ASC hint to specify ascending range scans explicitly should the default behavior change. | INDEX_SS_ASC 힌트는 지정된 테이블에 대해 인덱스 스킵 스캔을 수행하도록 옵티마이저에 지시합니다. 명령문이 인덱스 범위 스캔을 사용하는 경우 Oracle 데이터베이스는 인덱스 항목을 인덱스 값의 오름차순으로 스캔합니다. 파티션 인덱스에서 결과는 다음과 같습니다. 각 파티션 내에서 오름차순으로 각 파라미터는 INDEX 힌트와 동일한 용도로 사용됩니다. 범위 스캔의 기본 동작은 인덱스 값의 오름차순 또는 내림차순 인덱스의 경우 내림차순으로 인덱스 항목을 스캔하는 것입니다. 이 힌트는 인덱스의 기본 순서를 변경하지 않으므로 INDEX_SS 힌트 외에는 아무것도 지정하지 않습니다. 그러나 기본 동작이 변경되면 INDEX_SS_ASC 힌트를 사용하여 오름차순 범위 스캔을 명시적으로 지정할 수 있습니다. | |
| INDEX_SS_DESC | The INDEX_SS_DESC hint instructs the optimizer to perform an index skip scan for the specified table. If the statement uses an index range scan and the index is ascending, then Oracle scans the index entries in descending order of their indexed values. In a partitioned index, the results are in descending order within each partition. For a descending index, this hint effectively cancels out the descending order, resulting in a scan of the index entries in ascending order. | INDEX_SS_DESC 힌트는 지정된 테이블에 대해 인덱스 스킵 스캔을 수행하도록 옵티마이저에 지시합니다. 명령문이 인덱스 범위 스캔을 사용하고 인덱스가 오름차순인 경우 Oracle은 인덱스 값의 내림차순으로 인덱스 항목을 스캔합니다. 파티션 인덱스에서 결과는 각 파티션 내에서 내림차순으로 표시됩니다. 내림차순 인덱스의 경우 이 힌트는 내림차순을 효과적으로 취소하여 인덱스 항목을 오름차순으로 스캔합니다. | SELECT /*+ INDEX_SS_DESC(e emp_name_ix) */ last_name FROM employees e WHERE first_name = 'Steven'; |
| INLINE | This hint disables automatic transformations to temp tables forced by Oracle optimizer and each WITH is processed in line. Another option to control materialization is to use hidden parameter “_with_subquery” | 이 힌트는 optimizer가 오라클 옵티마이저가 강제로 적용한 임시 테이블로의 자동 변환을 비활성화하고 각 WITH를 일렬로 처리합니다. 구체화를 제어하는 또 다른 옵션은 숨겨진 히든 파라미터 "_with_subquery"를 사용하는 것입니다 | |
| INMEMORY | |||
| INMEMORY_PRUNING | |||
| LEADING | The LEADING hint is a multitable hint that can specify more than one table or view. LEADING instructs the optimizer to use the specified set of tables as the prefix in the execution plan. The first table specified is used to start the join. This hint is more versatile than the ORDERED hint. The LEADING hint is ignored if the tables specified cannot be joined first in the order specified because of dependencies in the join graph. If you specify two or more conflicting LEADING hints, then all of them are ignored. If you specify the ORDERED hint, it overrides all LEADING hints. | LEADING 힌트는 둘 이상의 테이블 또는 뷰를 지정할 수 있는 다중 테이블 힌트입니다. LEADING은 지정된 테이블 집합을 실행 계획의 선두로 사용하도록 옵티마이저에 지시합니다. 지정된 첫 번째 테이블은 조인을 시작하는 데 사용됩니다. 이 힌트는 ORDERED 힌트보다 다재다능합니다. 조인 그래프의 종속성 때문에 지정된 테이블을 지정된 순서대로 먼저 조인할 수 없는 경우 LEADING 힌트가 무시됩니다. 충돌하는 LEADING 힌트를 두 개 이상 지정하면 모두 무시됩니다. ORDERED 힌트를 지정하면 모든 LEADING 힌트를 무시합니다. | SELECT /*+ LEADING(e j) */ * FROM employees e, departments d, job_history j WHERE e.department_id = d.department_id AND e.hire_date = j.start_date; |
| MATERIALIZE | This hint is very nice extension for WITH clause. It forces Oracle to transform data generated by particular WITH into temporary table. Another option to control materialization is to use hidden parameter “_with_subquery” | 이 힌트는 WITH 절을 확장한 것으로, 오라클이 특정 WITH에서 생성한 데이터를 임시 테이블로 변환하도록 강제합니다. 구체화를 제어하는 또 다른 옵션은 숨겨진 히든 파라미터 "_with_subquery"를 사용하는 것입니다 | |
| MERGE | The MERGE hint lets you merge views in a query. If a view's query block contains a GROUP BY clause or DISTINCT operator in the SELECT list, then the optimizer can merge the view into the accessing statement only if complex view merging is enabled. Complex merging can also be used to merge an IN subquery into the accessing statement if the subquery is uncorrelated. When the MERGE hint is used without an argument, it should be placed in the view query block. When MERGE is used with the view name as an argument, it should be placed in the surrounding query. | MERGE 힌트를 사용하면 쿼리에서 뷰를 병합할 수 있습니다. 뷰의 쿼리 블록이 SELECT 목록에 GROUP BY 절 또는 DISTINCT 연산자를 포함하는 경우, 복합 뷰 병합이 활성화된 경우에만 옵티마이저가 액세스 구문에 뷰를 병합할 수 있습니다. 서브 쿼리가 상관되지 않은 경우, 복합 병합을 사용하여 IN 서브 쿼리를 액세스하는 구문으로 병합할 수도 있습니다. MERGE 힌트를 인수 없이 사용하는 경우 뷰 쿼리 블록에 넣어야 합니다. 뷰 이름을 인수로 MERGE를 사용하는 경우 주변 쿼리에 배치해야 합니다. | SELECT /*+ MERGE(v) */ e1.last_name, e1.salary, v.avg_salary FROM employees e1, (SELECT department_id, avg(salary) avg_salary FROM employees e2 GROUP BY department_id) v WHERE e1.department_id = v.department_id AND e1.salary > v.avg_salary ORDER BY e1.last_name; |
| MODEL_MIN_ANALYSIS | |||
| MONITOR | The MONITOR hint forces real-time SQL monitoring for the query, even if the statement is not long running. This hint is valid only when the parameter CONTROL_MANAGEMENT_PACK_ACCESS is set to DIAGNOSTIC+TUNING. | MONITOR 힌트는 구문이 오래 실행되지 않은 경우에도 쿼리에 대한 실시간 SQL 모니터링을 강제로 수행합니다. 이 힌트는 COLTROL_MANAGENT_PACK_ACCESS 파라미터가 DIALOGIC+TUNING으로 설정된 경우에만 유효합니다. | |
| NATIVE_FULL_OUTER_JOIN | The NATIVE_FULL_OUTER_JOIN hint instructs the optimizer to use native full outer join, which is a native execution method based on a hash join. | Native_FULL_OUTER_JOIN 힌트는 옵티마이저에 해시 조인을 기반으로 하는 네이티브 실행 방법인 네이티브 전체 외부 조인을 사용하도록 지시합니다. | |
| NLJ_BATCHING | |||
| NLJ_PREFETCH | |||
| NL_AJ | |||
| NL_SJ | |||
| NOAPPEND | |||
| NOCACHE | |||
| NO_CLUSTERING | |||
| NO_CPU_COSTING | |||
| NO_ELIMINATE_JOIN | |||
| NO_EXPAND | The NO_EXPAND hint instructs the optimizer not to consider OR-expansion for queries having OR conditions or IN-lists in the WHERE clause. Usually, the optimizer considers using OR expansion and uses this method if it decides that the cost is lower than not using it. The USE_CONCAT Hint, which is the opposite of this hint. | NO_EXPAND 힌트는 WHERE 절에 OR 조건 또는 IN 목록이 있는 쿼리에 대해 OR 확장을 고려하지 않도록 옵티마이저에 지시합니다. 일반적으로 옵티마이저는 OR 확장 사용을 고려하고, 사용하지 않는 것보다 비용이 절약된다고 판단되면 이 방법을 사용합니다. 이 힌트의 반대는 USE_CONCAT 힌트입니다. | SELECT /*+ NO_EXPAND */ * FROM employees e, departments d WHERE e.manager_id = 108 OR d.department_id = 110; |
| NO_FACT | |||
| NO_GATHER_OPTIMIZER_STATISTICS | |||
| NO_INDEX | The NO_INDEX hint instructs the optimizer not to use one or more indexes for the specified table. Each parameter serves the same purpose as in INDEX Hint with the following modifications: - If this hint specifies a single available index, then the optimizer does not consider a scan on this index. Other indexes not specified are still considered. - If this hint specifies a list of available indexes, then the optimizer does not consider a scan on any of the specified indexes. Other indexes not specified in the list are still considered. - If this hint specifies no indexes, then the optimizer does not consider a scan on any index on the table. This behavior is the same as a NO_INDEX hint that specifies a list of all available indexes for the table. The NO_INDEX hint applies to function-based, B-tree, bitmap, cluster, or domain indexes. If a NO_INDEX hint and an index hint (INDEX, INDEX_ASC, INDEX_DESC, INDEX_COMBINE, or INDEX_FFS) both specify the same indexes, then the database ignores both the NO_INDEX hint and the index hint for the specified indexes and considers those indexes for use during execution of the statement. | NO_INDEX 힌트는 옵티마이저가 지정된 테이블에 대해 하나 이상의 인덱스를 사용하지 않도록 지시합니다. 각 파라미터는 INDEX 힌트와 동일한 용도로 사용되며 다음과 같이 수정됩니다: - 이 힌트가 사용 가능한 단일 인덱스를 지정하는 경우, 옵티마이저는 이 인덱스에 대한 스캔을 고려하지 않습니다. 지정되지 않은 다른 인덱스는 계속 고려됩니다. - 이 힌트가 사용 가능한 인덱스 목록을 지정하는 경우, 옵티마이저는 지정된 인덱스에 대한 스캔을 고려하지 않습니다. 목록에 지정되지 않은 다른 인덱스는 계속 고려됩니다. - 이 힌트가 인덱스를 지정하지 않으면, 옵티마이저는 테이블의 인덱스에 대한 스캔을 고려하지 않습니다. 이 동작은 테이블에 사용 가능한 모든 인덱스 목록을 지정하는 NO_INDEX 힌트와 동일합니다. NO_INDEX 힌트는 함수 기반, B-트리, 비트맵, 클러스터 또는 도메인 인덱스에 적용됩니다. NO_INDEX 힌트와 인덱스 힌트(INDEX, INDEX_ASC, INDEX_DESC, INDEX_COMBINE 또는 INDEX_FFS)가 모두 동일한 인덱스를 지정하면 데이터베이스는 지정된 인덱스에 대한 NO_INDEX 힌트와 인덱스 힌트를 모두 무시하고 구문을 실행하는 동안 해당 인덱스를 사용하도록 간주합니다. | SELECT /*+ NO_INDEX(employees emp_empid) */ employee_id FROM employees WHERE employee_id > 200; |
| NO_INDEX_FFS | |||
| NO_INDEX_SS | |||
| NO_INMEMORY | |||
| NO_INMEMORY_PRUNING | |||
| NO_MERGE | |||
| NO_MONITOR | |||
| NO_NATIVE_FULL_OUTER_JOIN | |||
| NO_NLJ_BATCHING | |||
| NO_NLJ_PREFETCH | |||
| NO_PARALLEL | The NO_PARALLEL hint instructs the optimizer to run the statement serially. This hint overrides the value of the PARALLEL_DEGREE_POLICY initialization parameter. It also overrides a PARALLEL parameter in the DDL that created or altered the table The NOPARALLEL hint has been deprecated. Use the NO_PARALLEL hint instead. | NO_PARALLEL 힌트는 구문을 serial로 실행하도록 옵티마이저에 지시합니다. 이 힌트는 PARALLEL_DEGREE_POLICY 초기화 파라미터 값을 무시합니다. 또한 테이블을 생성하거나 변경한 DDL의 PARALLEL 파라미터를 재정의합니다. NOPARALLEL 힌트는 더 이상 사용되지 않습니다. 대신 NO_PARALLEL 힌트를 사용하십시오. | ALTER TABLE employees PARALLEL 8; SELECT /*+ NO_PARALLEL(hr_emp) */ last_name FROM employees hr_emp; |
| NO_PARALLEL_INDEX | The NO_PARALLEL_INDEX hint overrides a PARALLEL parameter in the DDL that created or altered the index, thus avoiding a parallel index scan operation. The NOPARALLEL_INDEX hint has been deprecated. Use the NO_PARALLEL_INDEX hint instead. | NO_PARALLEL_INDEX 힌트는 인덱스를 생성하거나 변경한 DDL의 PARALLEL 파라미터를 재정의하여 병렬 인덱스 스캔 작업을 방지합니다. NOPARALLEL_INDEX 힌트는 더 이상 사용되지 않습니다. 대신 NO_PARALLEL_INDEX 힌트를 사용하십시오. | |
| NO_PQ_CONCURRENT_UNION | |||
| NO_PQ_SKEW | |||
| NO_PUSH_PRED | |||
| NO_PUSH_SUBQ | |||
| NO_PX_JOIN_FILTER | |||
| NO_QUERY_TRANSFORMATION | |||
| NO_RESULT_CACHE | |||
| NO_REWRITE | |||
| NOREWRITE | |||
| NO_STAR_TRANSFORMATION | |||
| NO_STATEMENT_QUEUING | |||
| NO_SWAP_JOIN_INPUTS | |||
| NO_UNNEST | |||
| NO_USE_BAND | |||
| NO_USE_CUBE | |||
| NO_USE_HASH | |||
| NO_USE_HASH_AGGREGATION | |||
| NO_USE_MERGE | |||
| NO_USE_NL | |||
| NO_XML_QUERY_REWRITE | |||
| NO_XMLINDEX_REWRITE | |||
| NO_ZONEMAP | |||
| OPTIMIZER_FEATURES_ENABLE | OPTIMIZER_FEATURES_ENABLE acts as an umbrella parameter for enabling a series of optimizer features based on an Oracle release number. | OPTIMIZER_FEATURES_ENABLE은 Oracle 릴리스 번호를 기반으로 한 일련의 최적화 기능을 활성화하기 위한 파라미터 역할을 합니다. | |
| OPT_PARAM | The OPT_PARAM hint lets you set an initialization parameter for the duration of the current query only. This hint is valid only for the following parameters: APPROX_FOR_AGGREGATION, APPROX_FOR_COUNT_DISTINCT, APPROX_FOR_PERCENTILE, OPTIMIZER_DYNAMIC_SAMPLING, OPTIMIZER_INDEX_CACHING, OPTIMIZER_INDEX_COST_ADJ, OPTIMIZER_SECURE_VIEW_MERGING, and STAR_TRANSFORMATION_ENABLED. Parameter values that are strings are enclosed in single quotation marks. Numeric parameter values are specified without quotation marks. | OPT_PARAM 힌트를 사용하면 현재 쿼리 구간 동안만 초기화 파라미터를 설정할 수 있습니다. 이 힌트는 다음 파라미터에 대해서만 유효합니다. ACTULT_FOR_COUNT_DISTINCT, ACTULT_FOR_PERCENTIZER, OPTIMIZER_INDEX_CACHING, OPTIMIZER_IND_COST_ADJ, OPTIMIZER_SECURE_VIENT 및 STAR_ENABLENT_ENED. 문자열인 파라미터 값은 작은 따옴표로 묶입니다. 숫자 파라미터 값은 따옴표 없이 지정됩니다. | SELECT /*+ OPT_PARAM('star_transformation_enabled' 'true') */ * FROM ... ; |
| ORDERED | The ORDERED hint instructs Oracle to join tables in the order in which they appear in the FROM clause. Oracle recommends that you use the LEADING hint, which is more versatile than the ORDERED hint. When you omit the ORDERED hint from a SQL statement requiring a join, the optimizer chooses the order in which to join the tables. You might want to use the ORDERED hint to specify a join order if you know something that the optimizer does not know about the number of rows selected from each table. Such information lets you choose an inner and outer table better than the optimizer could. | ORDERED 힌트는 Oracle이 FROM 절에 나타나는 순서대로 테이블을 조인하도록 지시합니다. Oracle은 ORDERED 힌트보다 다재다능한 LEADING 힌트를 사용할 것을 권장합니다. 조인이 필요한 SQL 문에서 ORDERED 힌트를 생략하면 옵티마이저가 테이블 조인 순서를 선택합니다. 옵티마이저가 각 테이블에서 선택한 행 수에 대해 모르는 것을 알고 있는 경우 조인 순서를 지정하기 위해 ORDERED 힌트를 사용할 수 있습니다. 이러한 정보를 통해 옵티마이저보다 더 나은 내부 및 외부 테이블을 선택할 수 있습니다. | SELECT /*+ ORDERED */ o.order_id, c.customer_id, l.unit_price * l.quantity FROM customers c, order_items l, orders o WHERE c.cust_last_name = 'Taylor' AND o.customer_id = c.customer_id AND o.order_id = l.order_id; |
| ORDERED_PREDICATES | |||
| PARALLEL | |||
| PARALLEL_INDEX | |||
| PQ_CONCURRENT_UNION | |||
| PQ_DISTRIBUTE | |||
| PQ_FILTER | |||
| PQ_SKEW | |||
| PUSH_PRED | The PUSH_PRED hint instructs the optimizer to push a join predicate into the view. | PUSH_PRED 힌트는 옵티마이저에게 조인 속성을 뷰에 푸시하도록 지시합니다. | SELECT /*+ NO_MERGE(v) PUSH_PRED(v) */ * FROM employees e, (SELECT manager_id FROM employees) v WHERE e.manager_id = v.manager_id(+) AND e.employee_id = 100; |
| PUSH_SUBQ | The PUSH_SUBQ hint instructs the optimizer to evaluate nonmerged subqueries at the earliest possible step in the execution plan. Generally, subqueries that are not merged are executed as the last step in the execution plan. If the subquery is relatively inexpensive and reduces the number of rows significantly, then evaluating the subquery earlier can improve performance. This hint has no effect if the subquery is applied to a remote table or one that is joined using a merge join. | PUSH_SUBQ 힌트는 옵티마이저가 실행 계획의 가능한 가장 빠른 단계에서 병합되지 않은 서브 쿼리를 평가하도록 지시합니다. 일반적으로 병합되지 않은 서브 쿼리는 실행 계획의 마지막 단계로 실행됩니다. 서브 쿼리가 상대적으로 저비용이고 행 수가 크게 적은 경우 서브 쿼리를 더 일찍 평가하면 성능이 향상될 수 있습니다. 이 힌트는 서브 쿼리가 원격 테이블이나 병합 조인을 사용하여 조인된 테이블에 적용되는 경우에는 적용되지 않습니다. | |
| PX_JOIN_FILTER | |||
| QB_NAME | Use the QB_NAME hint to define a name for a query block. This name can then be used in a hint in the outer query or even in a hint in an inline view to affect query execution on the tables appearing in the named query block. If two or more query blocks have the same name, or if the same query block is hinted twice with different names, then the optimizer ignores all the names and the hints referencing that query block. Query blocks that are not named using this hint have unique system-generated names. These names can be displayed in the plan table and can also be used in hints within the query block, or in query block hints. | QB_NAME 힌트를 사용하여 쿼리 블록의 이름을 정의합니다. 그런 다음 이 이름을 외부 쿼리의 힌트 또는 인라인 뷰의 힌트에 사용하여 명명된 쿼리 블록에 나타나는 테이블의 쿼리 실행에 영향을 줄 수 있습니다. 둘 이상의 쿼리 블록의 이름이 동일하거나 동일한 쿼리 블록이 다른 이름으로 두 번 암시되는 경우 옵티마이저는 해당 쿼리 블록을 참조하는 모든 이름과 힌트를 무시합니다. 이 힌트를 사용하여 이름이 지정되지 않은 쿼리 블록에는 고유한 시스템 생성 이름이 있습니다. 이러한 이름은 실행 계획표에 표시될 수 있으며 쿼리 블록 내 힌트 또는 쿼리 블록 힌트에도 사용될 수 있습니다. | SELECT /*+ QB_NAME(qb) FULL(@qb e) */ employee_id, last_name FROM employees e WHERE last_name = 'Smith'; |
| RESULT_CACHE | |||
| RETRY_ON_ROW_CHANGE | |||
| REWRITE | |||
| STAR_TRANSFORMATION | |||
| STATEMENT_QUEUING | |||
| SWAP_JOIN_INPUTS | |||
| UNNEST | The UNNEST hint instructs the optimizer to unnest and merge the body of the subquery into the body of the query block that contains it, allowing the optimizer to consider them together when evaluating access paths and joins. Before a subquery is unnested, the optimizer first verifies whether the statement is valid. The statement must then pass heuristic and query optimization tests. The UNNEST hint instructs the optimizer to check the subquery block for validity only. If the subquery block is valid, then subquery unnesting is enabled without checking the heuristics or costs. | UNNEST 힌트는 옵티마이저에게 서브 쿼리의 본문을 포함하는 쿼리 블록의 본문에 중첩 및 병합하도록 지시하므로 옵티마이저가 액세스 경로 및 조인을 평가할 때 이들을 함께 고려할 수 있습니다. 서브 쿼리가 중첩 해제되기 전에 옵티마이저는 먼저 구문이 유효한지 여부를 확인합니다. 그런 다음 휴리스틱 및 쿼리 최적화 테스트를 통과해야 합니다. UNNEST 힌트는 옵티마이저에게 서브 쿼리 블록의 유효성만 확인하도록 지시합니다. 서브 쿼리 블록이 유효하면 휴리스틱 또는 비용을 확인하지 않고 서브 쿼리 중첩이 활성화됩니다 | |
| USE_BAND | The USE_BAND hint instructs the optimizer to join each specified table with another row source using a band join. The order the tables are listed in the USE_BAND hint does not specify a join order. To hint a specific join order, the LEADING hint is required. | USE_BAND 힌트는 옵티마이저에게 밴드 조인을 사용하여 지정된 각 테이블을 다른 행 소스와 조인하도록 지시합니다. USE_BAND 힌트에 테이블이 나열된 순서는 조인 순서를 지정하지 않습니다. 구체적인 조인 순서를 지정하려면 LEADING 힌트가 필요합니다. | SELECT /*+ USE_BAND(e1 e2) */ e1.last_name || ' has salary between 100 less and 100 more than ' || e2.last_name AS "SALARY COMPARISON" FROM employees e1, employees e2 WHERE e1.salary BETWEEN e2.salary - 100 AND e2.salary + 100; |
| USE_CONCAT | The USE_CONCAT hint instructs the optimizer to transform combined OR-conditions in the WHERE clause of a query into a compound query using the UNION ALL set operator. Without this hint, this transformation occurs only if the cost of the query using the concatenations is cheaper than the cost without them. The USE_CONCAT hint overrides the cost consideration. The NO_EXPAND Hint, which is the opposite of this hint | USE_CONCAT 힌트는 옵티마이저에 UNION ALL 집합 연산자를 사용하여 쿼리의 WHERE 절에 있는 결합된 OR 조건을 복합 쿼리로 변환하도록 지시합니다. 이 힌트가 없으면 연결을 사용하는 쿼리 비용이 연결을 사용하지 않는 비용보다 저렴한 경우에만 이 변환이 발생합니다. USE_CONCAT 힌트는 비용 고려 사항을 무시합니다. 이 힌트의 반대인 NO_EXPAND 힌트입니다. | SELECT /*+ USE_CONCAT */ * FROM employees e WHERE manager_id = 108 OR department_id = 110; |
| USE_CUBE | When the right-hand side of the join is a cube, the USE_CUBE hint instructs the optimizer to join each specified table with another row source using a cube join. If the optimizer decides not to use the cube join based on statistical analysis, then you can use USE_CUBE to override that decision. | 조인의 오른쪽이 큐브인 경우 USE_CUBE 힌트는 최적화 도구에 큐브 조인을 사용하여 지정된 각 테이블을 다른 행 소스와 조인하도록 지시합니다. 최적화 도구가 통계 분석을 기반으로 큐브 조인을 사용하지 않기로 결정한 경우 USE_CUBE를 사용하여 해당 결정을 재정의할 수 있습니다. | |
| USE_HASH | The USE_HASH hint instructs the optimizer to join each specified table with another row source using a hash join. The order the tables are listed in the USE_HASH hint does not specify a join order. To hint a specific join order, the LEADING hint is required. | USE_HASH 힌트는 옵티마이저에게 해시 조인을 사용하여 지정된 각 테이블을 다른 행 소스와 조인하도록 지시합니다. USE_HASH 힌트에 테이블이 나열되는 순서는 조인 순서를 지정하지 않습니다. 특정 조인 순서를 지정하려면 LEADING 힌트가 필요합니다. | SELECT /*+ USE_HASH(l h) */ * FROM orders h, order_items l WHERE l.order_id = h.order_id AND l.order_id > 2400; |
| USE_HASH_AGGREGATION | |||
| USE_MERGE | The USE_MERGE hint instructs the optimizer to join each specified table with another row source using a sort-merge join. Use of the USE_NL and USE_MERGE hints is recommended with the LEADING and ORDERED hints. The optimizer uses those hints when the referenced table is forced to be the inner table of a join. The hints are ignored if the referenced table is the outer table. | USE_MERGE 힌트는 sort-merge 조인을 사용하여 지정된 각 테이블을 다른 행 소스와 조인하도록 옵티마이저에 지시합니다. LEADING 및 ORDERED 힌트와 함께 USE_NL 및 USE_MERGE 힌트를 사용하는 것이 좋습니다. 옵티마이저는 참조된 테이블이 조인의 내부 테이블이 되도록 강제할 때 이러한 힌트를 사용합니다. 참조된 테이블이 외부 테이블인 경우 힌트가 무시됩니다. | SELECT /*+ USE_MERGE(employees departments) */ * FROM employees, departments WHERE employees.department_id = departments.department_id; |
| USE_NL | The USE_NL hint instructs the optimizer to join each specified table to another row source with a nested loops join, using the specified table as the inner table. Use of the USE_NL and USE_MERGE hints is recommended with the LEADING and ORDERED hints. The optimizer uses those hints when the referenced table is forced to be the inner table of a join. The hints are ignored if the referenced table is the outer table. | USE_NL 힌트는 지정된 테이블을 내부 테이블로 사용하여 중첩 루프 조인을 사용하여 지정된 각 테이블을 다른 행 소스에 조인하도록 옵티마이저에 지시합니다. LEADING 및 ORDERED 힌트와 함께 USE_NL 및 USE_MERGE 힌트를 사용하는 것이 좋습니다. 옵티마이저는 참조된 테이블이 조인의 내부 테이블이 되도록 강제할 때 이러한 힌트를 사용합니다. 참조 테이블이 외부 테이블인 경우 힌트가 무시됩니다. | SELECT /*+ USE_NL(l h) */ h.customer_id, l.unit_price * l.quantity FROM orders h, order_items l WHERE l.order_id = h.order_id; |
| USE_NL_WITH_INDEX | The USE_NL_WITH_INDEX hint instructs the optimizer to join the specified table to another row source with a nested loops join using the specified table as the inner table. - If no index is specified, then the optimizer must be able to use some index with at least one join predicate as the index key. - If an index is specified, then the optimizer must be able to use that index with at least one join predicate as the index key. | USE_NL_WITH_INDEX 힌트는 지정된 테이블을 내부 테이블로 사용하여 중첩 루프 조인을 사용하여 지정된 테이블을 다른 행 소스에 조인하도록 옵티마이저에 지시합니다. - 인덱스가 지정되지 않은 경우 옵티마이저는 적어도 하나의 조인 속성이 있는 일부 인덱스를 인덱스 키로 사용할 수 있어야 합니다. - 인덱스가 지정된 경우 옵티마이저는 적어도 하나의 조인 속성과 함께 해당 인덱스를 인덱스 키로 사용할 수 있어야 합니다. | SELECT /*+ USE_NL_WITH_INDEX(l item_product_ix) */ * FROM orders h, order_items l WHERE l.order_id = h.order_id AND l.order_id > 2400; |
