コメント

CACHEヒントは、全表スキャンの実行時に、この表に対して取り出されたブロックを、バッファ・キャッシュ内のLRUリストの最高使用頻度側に入れるようオプティマイザに指定します。このヒントは、小規模な参照表で有効です。

次の例では、CACHEヒントが表のデフォルト・キャッシュ仕様を上書きします。

SELECT /*+ FULL (hr_emp) CACHE(hr_emp) */ last_name
  FROM employees hr_emp;

CACHEおよびNOCACHEヒントは、V$SYSSTATデータ・ディクショナリ・ビューで示すように、システム統計情報table scans (long tables)およびtable scans (short tables)に影響を与えます。

CHANGE_DUPKEY_ERROR_INDEXヒント

図「change_dupkey_error_index.gif」の説明

注意:

CHANGE_DUPKEY_ERROR_INDEXヒント、IGNORE_ROW_ON_DUPKEY_INDEXヒントおよびRETRY_ON_ROW_CHANGEヒントは、セマンティクスに影響を与えるという点で他のヒントとは異なります。これら3つのヒントには、「ヒント」で説明されている一般的な原則は当てはまりません。

CHANGE_DUPKEY_ERROR_INDEXヒントは、指定した列セットまたは指定した索引に対する一意キー違反を明確に識別するメカニズムを提供します。指定した索引に対して一意キー違反が発生すると、ORA-001のかわりにORA-38911エラーが報告されます。

このヒントは、INSERT操作およびUPDATE操作に適用されます。索引を指定する場合は、その索引が存在するとともに一意であることが必要です。索引のかわりに列リストを指定する場合は、列の数と順序が列リストのものと一致する一意索引が存在する必要があります。

特定の規則に違反した場合、このヒントの使用によってエラー・メッセージが戻されます。詳細は、「IGNORE_ROW_ON_DUPKEY_INDEXヒント」を参照してください。

注意:

このヒントを使用すると、APPENDモードおよびパラレルDMLの両方が無効になります。

関連項目:

このヒントの詳細は、「IGNORE_ROW_ON_DUPKEY_INDEXヒント」を参照してください。また、オンライン・アプリケーション・アップグレードに関連するヒントの使用方法については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

CLUSTERヒント

図「cluster_hint.gif」の説明

CLUSTERヒントは、クラスタ・スキャンを使用して、指定した表にアクセスするようオプティマイザに指示します。このヒントは、索引クラスタ内の表にのみ適用されます。

CURSOR_SHARING_EXACTヒント

図「cursor_sharing_exact_hint.gif」の説明

Oracleでは、置換しても安全な場合には、SQL文内のリテラルをバインド変数に置き換えることができます。この置換処理は、CURSOR_SHARING初期化パラメータを使用して制御します。CURSOR_SHARING_EXACTヒントは、この動作を行わないようオプティマイザに指示します。このヒントを指定すると、Oracleは、リテラルのバインド変数への置換を試行せずにSQL文を実行します。

DRIVING_SITEヒント

図「driving_site_hint.gif」の説明

DRIVING_SITEヒントは、データベースによって選択されたサイトとは異なるサイトで問合せを実行するようオプティマイザに指示します。このヒントは、分散化された問合せの最適化を使用している場合に有効です。

次に例を示します。

SELECT /*+ DRIVING_SITE(departments) */ * 
  FROM employees, departments@rsite 
  WHERE employees.department_id = departments.department_id;

この問合せがヒントなしで実行されている場合、departmentsからの行がローカル・サイトに送信され、そこで結合が実行されます。このヒントを使用している場合、employeesからの行がリモート・サイトに送信され、そこで問合せが実行されて結果セットがローカル・サイトに戻されます。

DYNAMIC_SAMPLINGヒント

図「dynamic_sampling_hint.gif」の説明

DYNAMIC_SAMPLINGヒントは、動的なサンプリングを制御する方法をオプティマイザに指示し、より正確な述語の選択性と表および索引に対する統計情報を調べることでサーバーのパフォーマンスを改善します。

DYNAMIC_SAMPLINGの値は、0から10の範囲で設定できます。このレベルが高いほど、コンパイラは多くのリソースを動的なサンプリングに費やし、その適用範囲も広がります。tablespecを指定しない場合、サンプリングのデフォルトは、カーソルのレベルになります。

integerの値は0から10となり、サンプリングの度合いを示します。

カーディナリティ統計情報が表にすでに存在する場合、オプティマイザはその情報を使用します。存在しない場合、オプティマイザは動的なサンプリングによってカーディナリティ統計情報を推定します。

tablespecを指定しており、カーディナリティ統計情報がすでに存在している場合は、次のようになります。

単一表述語(1つの表のみを評価するWHERE句)がない場合、オプティマイザは既存の統計情報を信頼し、このヒントを無視します。たとえば、employeesが分析される場合、次の問合せは動的なサンプリングにはなりません。
```
SELECT /*+ DYNAMIC_SAMPLING(e 1) */ count(*)
  FROM employees e;
```
単一表述語がある場合、オプティマイザは既存のカーディナリティ統計情報を使用し、この既存の統計情報を使用して述語の選択性を推定します。

動的なサンプリングを特定の表に適用するには、次の形式のヒントを使用します。

SELECT /*+ DYNAMIC_SAMPLING(employees 1) */ *
  FROM employees 
  WHERE ...

関連項目:

動的なサンプリングおよび設定可能なサンプリング・レベルの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

FACTヒント

図「fact_hint.gif」の説明

FACTヒントは、スター型変換のコンテキストで使用されます。これは、tablespecで指定された表をファクト表とみなすようオプティマイザに指示するためのものです。

FIRST_ROWSヒント

図「first_rows_hint.gif」の説明

FIRST_ROWSヒントは、最初のn行を最も効率的に戻す計画を選択し、個々のSQL文を最適化して応答時間を速くするようOracleに指示します。integerには、戻される行数を指定します。

たとえば、オプティマイザは問合せの最適化アプローチを使用して、次の文を最善の応答時間に最適化します。

SELECT /*+ FIRST_ROWS(10) */ employee_id, last_name, salary, job_id
  FROM employees
  WHERE department_id = 20;

この例では、各部門に多数の従業員がいます。ユーザーは、部門20の最初の10人の従業員を迅速に表示する必要があります。

オプティマイザは、DELETEおよびUPDATEの文ブロック、およびソートまたはグループ化などのブロッキング操作を含むSELECT文ブロックではこのヒントを無視します。Oracle Databaseでは最初の行を戻す前に、この文でアクセスされるすべての行を取り出す必要があるため、このような文は最善の応答時間に最適化することができません。このヒントをこのような文で指定する場合は、データベースを最善のスループットに最適化します。

関連項目:

FIRST_ROWSヒントと統計情報の詳細は、「ALL_ROWSヒント」を参照してください。

FULLヒント

図「full_hint.gif」の説明

FULLヒントは、指定した表に対して全表スキャンを実行するようオプティマイザに指示します。次に例を示します。

SELECT /*+ FULL(e) */ employee_id, last_name
  FROM hr.employees e 
  WHERE last_name LIKE :b1;

Oracle Databaseは、WHERE句内の条件によって使用可能になるlast_name列に索引がある場合でも、employees表に対して全表スキャンを実行し、この文を実行します。

employees表は、FROM句の中に別名eを持つため、ヒントは表名ではなく別名で表を参照する必要があります。スキーマ名がFROM句の中で指定されている場合でも、ヒントではスキーマ名を指定しないでください。

HASHヒント

図「hash_hint.gif」の説明

HASHヒントは、ハッシュ・スキャンを使用して、指定した表にアクセスするようオプティマイザに指示します。このヒントは、ハッシュ・クラスタ内の表にのみ適用されます。

IGNORE_ROW_ON_DUPKEY_INDEXヒント

図「ignore_row_on_dupkey_index.gif」の説明

注意:

IGNORE_ROW_ON_DUPKEY_INDEXヒントが適用されるのは、単一表INSERT操作のみです。UPDATE、DELETE、MERGEおよびマルチテーブル・インサート操作に対してはサポートされません。IGNORE_ROW_ON_DUPKEY_INDEXを指定すると、その文では、指定の列セットまたは指定の索引に対する一意キー違反が無視されます。一意キー違反が発生したときは、行レベルのロールバックが行われ、実行は次の入力行から再開します。データを挿入するときにこのヒントを指定した場合は、DMLエラー・ロギングが有効になっていても、一意キー違反はログに記録されず、文は終了しません。

特定の規則に違反した場合、このヒントによるセマンティクスへの影響によってエラー・メッセージが戻されます。

索引を指定する場合は、その索引が存在するとともに一意であることが必要です。そうでない場合は、ORA-38913が発生します。
索引は、1つのみ指定する必要があります。索引を指定しなかった場合、ORA-38912が発生します。複数の索引を指定した場合、ORA-38915が発生します。
INSERT文にCHANGE_DUPKEY_ERROR_INDEXまたはIGNORE_ROW_ON_DUPKEY_INDEXのいずれかのヒントを指定できますが、両方を指定することはできません。両方を指定した場合、ORA-38915が発生します。

すべてのヒントと同様に、ヒント内の構文エラーは特に警告もなく無視されます。その結果、ヒントを使用しなかった場合と同じように、ORA-00001が発生します。

注意:

このヒントを使用すると、APPENDモードおよびパラレルDMLの両方が無効になります。

関連項目:

このヒントの詳細は、「CHANGE_DUPKEY_ERROR_INDEXヒント」を参照してください。また、オンライン・アプリケーション・アップグレードに関連するヒントの使用方法については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

INDEXヒント

図「index_hint.gif」の説明

INDEXヒントは、指定した表について索引スキャンを使用するようオプティマイザに指示します。ファンクション索引、ドメイン索引、Bツリー索引、ビットマップ索引およびビットマップ結合索引について、INDEXヒントを使用できます。

ヒントの動作は、indexspecの仕様によって異なります。

INDEXヒントが使用可能な単一の索引を指定すると、データベースはこの索引でスキャンを実行します。オプティマイザは、全表スキャンおよび表上の別の索引のスキャンを考慮しません。
複数の索引の組合せに対してヒントを指定する場合は、INDEXではなく、より多目的なヒントであるINDEX_COMBINEを使用することをお薦めします。INDEXヒントで索引のリストが指定されている場合は、オプティマイザはこのリスト内の各索引のスキャンのコストを計算してから、コストが最低である索引スキャンを実行します。あるいは、このリストの複数の索引をスキャンしてその結果をマージするというアクセス・パスが選択されることもあります(そのようなアクセス・パスのコストが最低になる場合)。全表スキャンや、ヒントで指定されていない索引のスキャンが検討されることはありません。
INDEXヒントが索引を指定しない場合、オプティマイザは、表にある使用可能な各索引でのスキャンのコストを検討し、最低のコストで索引スキャンを実行します。アクセス・パスのコストが最低となる場合、データベースは複数の索引をスキャンするように選択し、結果をマージすることもあります。オプティマイザは全表スキャンを検討しません。

次に例を示します。

SELECT /*+ INDEX (employees emp_department_ix)*/ employee_id, department_id
  FROM employees 
  WHERE department_id > 50;

INDEX_ASCヒント

図「index_asc_hint.gif」の説明

INDEX_ASCヒントは、指定した表について索引スキャンを使用するようオプティマイザに指示します。文で索引レンジ・スキャンを使用する場合、Oracle Databaseは索引付きの値の昇順で索引エントリをスキャンします。各パラメータは、「INDEXヒント」と同じ目的で使用されます。

レンジ・スキャンのデフォルトの動作は、索引エントリを索引値の昇順で(降順索引の場合は降順で)スキャンするというものです。このヒントを指定しても、索引のデフォルトの順序が変わることはなく、したがってINDEXヒントを指定したのと同じことになります。ただし、INDEX_ASCヒントを使用すると、デフォルトの動作が変更された場合に昇順レンジ・スキャンを明示的に指定できます。

INDEX_COMBINEヒント

図「index_combine_hint.gif」の説明

INDEX_COMBINEヒントは、表へのビットマップ・アクセス・パスを使用するようオプティマイザに指示します。indexspecがINDEX_COMBINEヒントから省略されている場合、オプティマイザは、表のスキャンにかかるコスト効率が最大になる索引のブールの組合せを使用します。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ヒント

図「index_desc_hint.gif」の説明

INDEX_DESCヒントは、指定した表に降順索引スキャンを使用するようオプティマイザに指示します。文で索引レンジ・スキャンを使用しており、索引が昇順の場合、Oracleは索引付きの値の降順で索引エントリをスキャンします。パーティション索引では、結果は各パーティション内で降順になります。降順索引の場合、このヒントは降順を効果的に取り消すため、索引エントリは昇順でスキャンされます。各パラメータは、「INDEXヒント」と同じ目的で使用されます。次に例を示します。

SELECT /*+ INDEX_DESC(e emp_name_ix) */ *
  FROM employees e;

関連項目:

全体スキャンの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

INDEX_FFSヒント

図「index_ffs_hint.gif」の説明

INDEX_FFSヒントは、全表スキャンではなく高速全索引スキャンを実行するようオプティマイザに指示します。

各パラメータは、「INDEXヒント」と同じ目的で使用されます。次に例を示します。

SELECT /*+ INDEX_FFS(e emp_name_ix) */ first_name
  FROM employees e;

INDEX_JOINヒント

図「index_join_hint.gif」の説明

INDEX_JOINヒントは、アクセス・パスとして索引結合を使用するようオプティマイザに指示します。ヒントが正しく機能するためには、問合せの解決に必要なすべての列を含む索引が最小限の数だけ存在している必要があります。

各パラメータは、「INDEXヒント」と同じ目的で使用されます。たとえば、次に示す問合せでは索引結合を使用してmanager_id列とdepartment_id列にアクセスしています(どちらの列もemployees表内で索引が付けられています)。

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ヒント

図「index_ss_hint.gif」の説明

INDEX_SSヒントは、指定した表について索引スキップ・スキャンを実行するようオプティマイザに指示します。文で索引レンジ・スキャンを使用する場合、Oracleは索引付きの値の昇順で索引エントリをスキャンします。パーティション索引では、結果は各パーティション内で昇順になります。

各パラメータは、「INDEXヒント」と同じ目的で使用されます。次に例を示します。

SELECT /*+ INDEX_SS(e emp_name_ix) */ last_name
  FROM employees e
  WHERE first_name = 'Steven';

関連項目:

索引スキップ・スキャンの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

INDEX_SS_ASCヒント

図「index_ss_asc_hint.gif」の説明

INDEX_SS_ASCヒントは、指定した表について索引スキップ・スキャンを実行するようオプティマイザに指示します。文で索引レンジ・スキャンを使用する場合、Oracle Databaseは索引付きの値の昇順で索引エントリをスキャンします。パーティション索引では、結果は各パーティション内で昇順になります。各パラメータは、「INDEXヒント」と同じ目的で使用されます。

レンジ・スキャンのデフォルトの動作は、索引エントリを索引値の昇順で(降順索引の場合は降順で)スキャンするというものです。このヒントを指定しても、索引のデフォルトの順序が変わることはなく、したがってINDEX_SSヒントを指定したのと同じことになります。ただし、INDEX_SS_ASCヒントを使用すると、デフォルトの動作が変更された場合に昇順レンジ・スキャンを明示的に指定できます。

関連項目:

索引スキップ・スキャンの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

INDEX_SS_DESCヒント

図「index_ss_desc_hint.gif」の説明

INDEX_SS_DESCヒントは、指定した表について索引スキップ・スキャンを実行するようオプティマイザに指示します。文で索引レンジ・スキャンを使用しており、索引が昇順の場合、Oracleは索引付きの値の降順で索引エントリをスキャンします。パーティション索引では、結果は各パーティション内で降順になります。降順索引の場合、このヒントは降順を効果的に取り消すため、索引エントリは昇順でスキャンされます。

各パラメータは、「INDEXヒント」と同じ目的で使用されます。次に例を示します。

SELECT /*+ INDEX_SS_DESC(e emp_name_ix) */ last_name
  FROM employees e
  WHERE first_name = 'Steven';

関連項目:

索引スキップ・スキャンの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

LEADINGヒント

図「leading_hint.gif」の説明

LEADINGヒントは、実行計画において、指定した一連の表を接頭辞として使用するようオプティマイザに指示します。このヒントは、ORDEREDヒントより多目的なヒントです。次に例を示します。

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;

図形結合の依存性により、指定の表を指定の順序の最初に結合できない場合、LEADINGヒントは無視されます。2つ以上の競合するLEADINGヒントを指定すると、指定したすべてのヒントが無視されます。ORDEREDヒントを指定すると、このヒントがすべてのLEADINGヒントに優先します。

MERGEヒント

図「merge_hint.gif」の説明

MERGEヒントを使用すると、問合せ内のビューをマージできます。

ビューの問合せブロックにGROUP BY句、またはSELECTリスト内のDISTINCT演算子が含まれている場合、複雑なビューのマージが可能であれば、オプティマイザはビューをアクセス文のみにマージできます。複雑なマージは、副問合せに相関関係がない場合、IN副問合せをアクセス文にマージする際に使用することもできます。

次に例を示します。

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;

引数なしでMERGEヒントを使用する場合、ビューの問合せブロック内に配置する必要があります。ビュー名を引数としてMERGEヒントを使用する場合、周囲の問合せに挿入する必要があります。

MODEL_MIN_ANALYSISヒント

図「model_min_analysis_hint.gif」の説明

MODEL_MIN_ANALYSISヒントは、スプレッドシート・ルールのコンパイル時間の最適化(主に、詳細な依存グラフ分析)を省略するようオプティマイザに指示します。スプレッドシートのアクセス構造に選択的に移入するためのフィルタの作成や制限されたルールのプルーニングなど、他のスプレッドシートの最適化は、引き続きオプティマイザによって使用されます。

スプレッドシート・ルールの数が数百を超えると、スプレッドシート分析に長い時間がかかることがあるため、このヒントによってコンパイル時間を減らします。

MONITORヒント

図「monitor_hint.gif」の説明

MONITORヒントは、文の実行時間が長くない場合でも、問合せのリアルタイムのSQL監視を強制します。このヒントは、パラメータCONTROL_MANAGEMENT_PACK_ACCESSがDIAGNOSTIC+TUNINGに設定されている場合にのみ有効です。

関連項目:

リアルタイムのSQL監視の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

NATIVE_FULL_OUTER_JOINヒント

図「native_foj_hint.gif」の説明

NATIVE_FULL_OUTER_JOINヒントは、ネイティブ完全外部結合を使用するようオプティマイザに指示します。ネイティブ完全外部結合は、ハッシュ結合に基づくネイティブ実行メソッドです。

関連項目:

NO_NATIVE_FULL_OUTER_JOINヒント
ネイティブ完全外部結合の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

NOAPPENDヒント

図「noappend_hint.gif」の説明

NOAPPENDヒントは、INSERT文が有効な間、パラレル・モードを無効にして従来型のINSERTを使用するようにオプティマイザに指示します。従来型のINSERTはシリアル・モードでのデフォルトです。また、ダイレクト・パスINSERTはパラレル・モードでのデフォルトです。

NOCACHEヒント

図「nocache_hint.gif」の説明

NOCACHEヒントは、全表スキャンの実行時に、この表に対して取り出されたブロックを、バッファ・キャッシュ内のLRUリストの最低使用頻度側に入れるようオプティマイザに指定します。これは、バッファ・キャッシュ内のブロックの通常動作です。次に例を示します。

SELECT /*+ FULL(hr_emp) NOCACHE(hr_emp) */ last_name
  FROM employees hr_emp;

CACHEおよびNOCACHEヒントは、V$SYSSTATビューで示すように、システム統計情報table scans(long tables)およびtable scans(short tables)に影響を与えます。

関連項目:

表のサイズによって異なる表の自動キャッシングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

NO_EXPANDヒント

図「no_expand_hint.gif」の説明

NO_EXPANDヒントは、OR条件を持つ問合せ用のOR拡張、またはWHERE句内にあるINリストを検討しないようオプティマイザに指示します。通常、オプティマイザは、OR拡張を使用しない場合よりもコストが低減できると判断すると、OR拡張の使用を検討します。次に例を示します。

SELECT /*+ NO_EXPAND */ *
  FROM employees e, departments d
  WHERE e.manager_id = 108
     OR d.department_id = 110;

関連項目:

「USE_CONCATヒント」を参照してください(このヒントの反対の機能です)。

NO_FACTヒント

図「no_fact_hint.gif」の説明

NO_FACTヒントは、スター型変換のコンテキストで使用されます。これは、問合せ対象の表をファクト表とみなさないようオプティマイザに指示するためのものです。

NO_INDEXヒント

図「no_index_hint.gif」の説明

NO_INDEXヒントは、指定した表について1つ以上の索引を使用しないようオプティマイザに指示します。次に例を示します。

SELECT /*+ NO_INDEX(employees emp_empid) */ employee_id 
  FROM employees 
  WHERE employee_id > 200;

各パラメータは「INDEXヒント」と同じ目的で使用されますが、次の変更が加えられています。

このヒントが使用可能な単一の索引を指定すると、オプティマイザはこの索引でのスキャンを検討しません。その他の指定されていない索引については、スキャンを検討します。
このヒントが使用可能な索引のリストを指定すると、オプティマイザは指定された索引でのスキャンを検討しません。リスト内に指定されていないその他の索引については、スキャンを検討します。
このヒントが索引を指定しない場合、オプティマイザは表のいずれの索引でのスキャンを考慮しません。この動作は、表について使用可能なすべての索引のリストを指定するNO_INDEXヒントと同様になります。

NO_INDEXヒントは、ファンクション索引、Bツリー索引、ビットマップ索引、クラスタ索引およびドメイン索引に適用されます。NO_INDEXヒントと索引ヒント(INDEX、INDEX_ASC、INDEX_DESC、INDEX_COMBINEまたはINDEX_FFS)の両方が同じ索引を指定する場合、データベースは、NO_INDEXヒントと、指定した索引の索引ヒントの両方を無視し、これらの索引を文の実行中に使用することを検討します。

NO_INDEX_FFSヒント

図「no_index_ffs_hint.gif」の説明

NO_INDEX_FFSヒントは、指定された表の指定された索引の高速全索引スキャンを除外するようオプティマイザに指示します。各パラメータの目的は、「NO_INDEXヒント」と同じです。次に例を示します。

SELECT /*+ NO_INDEX_FFS(items item_order_ix) */ order_id
  FROM order_items items;

NO_INDEX_SSヒント

図「no_index_ss_hint.gif」の説明

NO_INDEX_SSヒントは、指定された表の指定された索引のスキップ・スキャンを除外するようオプティマイザに指示します。各パラメータの目的は、「NO_INDEXヒント」と同じです。

関連項目:

索引スキップ・スキャンの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

NO_MERGEヒント

図「no_merge_hint.gif」の説明

NATIVE_FULL_OUTER_JOINヒント

NO_MERGEヒントは、外部問合せとインライン・ビュー問合せを結合して単一の問合せにしないようオプティマイザに指示します。

このヒントを使用すると、ビューへのアクセス方法に強い影響を与えることができます。たとえば、次の文は、ビューseattle_deptがマージされないようにします。

SELECT /*+ NO_MERGE(seattle_dept) */ e1.last_name, seattle_dept.department_name
  FROM employees e1,
       (SELECT location_id, department_id, department_name
          FROM departments
          WHERE location_id = 1700) seattle_dept
  WHERE e1.department_id = seattle_dept.department_id;

ビューの問合せブロック内でNO_MERGEヒントを使用する場合は、引数なしで指定します。また、周囲の問合せでNO_MERGEを指定する場合には、ビュー名を引数として指定します。

NO_MONITORヒント

図「no_monitor_hint.gif」の説明

NO_MONITORヒントは、問合せの実行時間が長い場合でも、問合せのSQLのリアルタイム監視を無効にします。

NO_NATIVE_FULL_OUTER_JOINヒント

図「no_native_foj_hint.gif」の説明

NO_NATIVE_FULL_OUTER_JOINヒントは、指定された各表を結合する場合にネイティブ実行メソッドを除外するようオプティマイザに指示します。かわりに、完全外部結合は、左側外部結合とアンチ結合の論理和として実行されます。

関連項目:

NO_PARALLELヒント

図「no_parallel_hint.gif」の説明

NO_PARALLELヒントは、文をシリアルで実行するようにオプティマイザに指示します。このヒントは、PARALLEL_DEGREE_POLICY初期化パラメータの値をオーバーライドします。また、表を作成するか変更したDDL内のPARALLELパラメータを上書きします。たとえば、次のSELECT文はシリアルで実行されます。

ALTER TABLE employees PARALLEL 8;
SELECT /*+ NO_PARALLEL(hr_emp) */ last_name
  FROM employees hr_emp;

関連項目:

パラレル・ヒントの詳細は、「パラレル・ヒントの注意事項」を参照してください。
PARALLEL_DEGREE_POLICY初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

NOPARALLELヒント

NOPARALLELヒントは現在非推奨になっています。NO_PARALLELヒントをかわりに使用します。

NO_PARALLEL_INDEXヒント

図「no_parallel_index_hint.gif」の説明

NO_PARALLEL_INDEXヒントは、索引を作成するか変更したDDL内のPARALLELパラメータを上書きし、パラレル索引スキャン操作を防止します。

関連項目:

パラレル・ヒントの詳細は、「パラレル・ヒントの注意事項」を参照してください。

NOPARALLEL_INDEXヒント

NOPARALLEL_INDEXヒントは現在非推奨になっています。NO_PARALLEL_INDEXヒントをかわりに使用します。

NO_PUSH_PREDヒント

図「no_push_pred_hint.gif」の説明

NO_PUSH_PREDヒントは、結合述語をビューにプッシュしないようオプティマイザに指示します。次に例を示します。

SELECT /*+ NO_MERGE(v) NO_PUSH_PRED(v) */ *
  FROM employees e,
       (SELECT manager_id
          FROM employees) v
  WHERE e.manager_id = v.manager_id(+)
    AND e.employee_id = 100;

NO_PUSH_SUBQヒント

図「no_push_subq_hint.gif」の説明

NO_PUSH_SUBQヒントは、実行計画における最後の手順として、マージされていない副問合せを評価するようオプティマイザに指示します。これにより、副問合せのコストが比較的高い場合や、副問合せによって行数が大幅に減少しない場合に、パフォーマンスが向上する場合があります。

NO_PX_JOIN_FILTERヒント

図「no_px_join_filter_hint.gif」の説明

このヒントは、オプティマイザがパラレル結合のビットマップ・フィルタ処理を使用するのを防ぎます。

NO_QUERY_TRANSFORMATIONヒント

図「no_query_transformatn_hint.gif」の説明

NO_QUERY_TRANSFORMATIONヒントは、すべての問合せ変換(OR拡張、ビュー・マージ、副問合せのネスト解除、スター型変換、マテリアライズド・ビュー・リライトなど)をスキップするようオプティマイザに指示するためのものです。次に例を示します。

SELECT /*+ NO_QUERY_TRANSFORMATION */ employee_id, last_name
  FROM (SELECT * FROM employees e) v
  WHERE v.last_name = 'Smith';

NO_RESULT_CACHEヒント

図「no_result_cache_hint.gif」の説明

RESULT_CACHE_MODE初期化パラメータがFORCEに設定されていると、オプティマイザは、問合せ結果を結果キャッシュにキャッシュします。この場合、NO_RESULT_CACHEヒントにより、このような現行の問合せのキャッシュが無効になります。

問合せがOCIクライアントから実行され、OCIクライアントの結果キャッシュが有効になっている場合、NO_RESULT_CACHEヒントにより現行の問合せキャッシュが無効になります。

NO_REWRITEヒント

図「no_rewrite_hint.gif」の説明

NO_REWRITEヒントは、パラメータQUERY_REWRITE_ENABLEDの設定を上書きして、問合せブロック用のクエリー・リライトを無効にするようオプティマイザに指示します。次に例を示します。

SELECT /*+ NO_REWRITE */ sum(s.amount_sold) AS dollars
  FROM sales s, times t
  WHERE s.time_id = t.time_id
  GROUP BY t.calendar_month_desc;

NOREWRITEヒント

NOREWRITEヒントは現在非推奨になっています。NO_REWRITEヒントをかわりに使用します。

NO_STAR_TRANSFORMATIONヒント

no_star_transformation_hint.gifの説明が続きます。

図「no_star_transformation_hint.gif」の説明

NO_STAR_TRANSFORMATIONヒントは、問合せのスター型問合せ変換を実行しないようオプティマイザに指示します。

NO_STATEMENT_QUEUINGヒント

図「no_statement_queuing_hint.gif」の説明

NO_STATEMENT_QUEUINGヒントは、パラレル文のキューイングによって文がキューに入れられるかどうかに影響します。

PARALLEL_DEGREE_POLICYがAUTOに設定されている場合、このヒントにより文がパラレル文キューをバイパスできるようになります。ただし、キューを回避した文が原因となって、PARALLEL_SERVERS_TARGET初期化パラメータの値で定義されたパラレル実行サーバーの最大数をシステムが超過する可能性があります(この初期化パラメータで定義された制限値を超えるとパラレル文のキューイングが開始されます)。

パラレル文キューを回避した文が要求どおりの数のパラレル実行サーバーを受け取れる保証はありません。割当てが可能なのは、システム上で使用可能なパラレル実行サーバーのみであり、その数は最大でPARALLEL_MAX_SERVERS初期化パラメータの値までです。

次に例を示します。

SELECT /*+ NO_STATEMENT_QUEUING */ emp.last_name, dpt.department_name
  FROM employees emp, departments dpt
  WHERE emp.department_id = dpt.department_id;

関連項目:

「STATEMENT_QUEUINGヒント」

NO_UNNESTヒント

図「no_unnest_hint.gif」の説明

NO_UNNESTヒントを使用するとネスト解除をオフに切り替えます。

NO_USE_HASHヒント

図「no_use_hash_hint.gif」の説明

NO_USE_HASHヒントは、指定された表を内部表として使用して、指定された各表を別の行のソースに結合する際にハッシュ結合を除外するようオプティマイザに指示します。次に例を示します。

SELECT /*+ NO_USE_HASH(e d) */ *
  FROM employees e, departments d
  WHERE e.department_id = d.department_id;

NO_USE_MERGEヒント

図「no_use_merge_hint.gif」の説明

NO_USE_MERGEヒントは、指定された表を内部表として使用して、指定された各表を別の行のソースに結合する際にソート/マージ結合を除外するようオプティマイザに指示します。次に例を示します。

SELECT /*+ NO_USE_MERGE(e d) */ *
   FROM employees e, departments d
   WHERE e.department_id = d.department_id
   ORDER BY d.department_id;

NO_USE_NLヒント

図「no_use_nl_hint.gif」の説明

NO_USE_NLヒントは、指定された表を内部表として使用して、指定された各表を別の行のソースに結合する際に、ネストしたループ結合を除外するようオプティマイザに指示します。次に例を示します。

SELECT /*+ NO_USE_NL(l h) */ *
  FROM orders h, order_items l
  WHERE l.order_id = h.order_id
    AND l.order_id > 2400;

このヒントを指定すると、指定された表についてハッシュ結合とソート/マージ結合のみが検討されます。ただし、ネストしたループのみを使用して表を結合する場合もあります。この場合、オプティマイザは、それらの表に関するヒントを無視します。

NO_XML_QUERY_REWRITEヒント

図「no_xml_query_rewrite_hint.gif」の説明

NO_XML_QUERY_REWRITEヒントは、SQL文のXPath式のリライトを禁止するようオプティマイザに指示します。このヒントは、XPath式のリライトを禁止することで、現行の問合せでのXMLIndex索引の使用も禁止します。次に例を示します。

SELECT /*+NO_XML_QUERY_REWRITE*/ XMLQUERY('<A/>' RETURNING CONTENT)
  FROM DUAL;

関連項目:

「NO_XMLINDEX_REWRITEヒント」

NO_XMLINDEX_REWRITEヒント

図「no_xmlindex_rewrite_hint.gif」の説明

NO_XMLINDEX_REWRITEヒントは、現行の問合せにXMLIndex索引を使用しないようにオプティマイザに指示します。次に例を示します。

SELECT /*+NO_XMLINDEX_REWRITE*/ count(*) 
  FROM warehouses
  WHERE existsNode(warehouse_spec, '/Warehouse/Building') = 1;

関連項目:

XMLIndexの使用を無効にするもう1つの方法については、「NO_XML_QUERY_REWRITEヒント」を参照してください。

OPT_PARAMヒント

図「opt_param_hint.gif」の説明

OPT_PARAMヒントを使用すると、現行の問合せ中にのみ初期化パラメータを設定できます。このヒントは、パラメータOPTIMIZER_DYNAMIC_SAMPLING、OPTIMIZER_INDEX_CACHING、OPTIMIZER_INDEX_COST_ADJ、OPTIMIZER_SECURE_VIEW_MERGINGおよびSTAR_TRANSFORMATION_ENABLEDに対してのみ有効です。たとえば、次のヒントは、ヒントを追加した文のパラメータSTAR_TRANSFORMATION_ENABLEDをTRUEに設定します。

SELECT /*+ OPT_PARAM('star_transformation_enabled' 'true') */ *
  FROM ... ;

文字列のパラメータ値は、一重引用符で囲まれます。数値のパラメータ値は、一重引用符で囲まずに指定されます。

ORDEREDヒント

図「ordered_hint.gif」の説明

ORDEREDヒントは、FROM句に現れる順序で表を結合するようOracleに指示します。ORDEREDヒントより多目的なLEADINGヒントを使用することをお薦めします。

結合を要求するSQL文からORDEREDヒントを削除すると、オプティマイザが表の結合順序を選択します。各表から選択した行数をオプティマイザが把握していないと考えられる場合、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;

PARALLELヒント

パラレル・ヒントの注意事項

Oracle Database 11gリリース2 (11.2.0.1)以上では、PARALLELヒントとNO_PARALLELヒントは文レベルのヒントであり、以前のオブジェクト・レベルのPARALLEL_INDEXヒントとNO_PARALLEL_INDEXヒント、および以前に指定したPARALLELヒントとNO_PARALLELヒントより優先されます。PARALLELでintegerを指定すると、並列度は文に対して使用されます。integerを指定しない場合は、データベースで並列度が計算されます。パラレル化を使用できるすべてのアクセス・パスで、指定した並列度または計算された並列度が使用されます。

次の構文図で、parallel_hint_statementは文レベルのヒントの構文を示し、parallel_hint_objectはオブジェクト・レベルのヒントの構文を示します。オブジェクト・レベルのヒントは下位互換性のためにサポートされており、文レベルのヒントの方が優先されます。

parallel_hint_statement::=

図「parallel_hint_statement.gif」の説明

parallel_hint_object::=

図「parallel_hint_object.gif」の説明

PARALLELヒントは、指定された数の同時サーバーをパラレル操作に使用するようオプティマイザに指示します。このヒントは、PARALLEL_DEGREE_POLICY初期化パラメータの値をオーバーライドします。このヒントは、文のSELECT、INSERT、MERGE、UPDATEおよびDELETE部分と表のスキャン部分に適用されます。パラレル制限に違反すると、ヒントは無視されます。

注意:

ソート操作またはグループ操作も実行する場合、使用可能なサーバー数はPARALLELヒントの値の2倍となります。

文レベルのPARALLELヒントでは、次のように動作します。

PARALLEL: 文は常にパラレルで実行され、データベースは並列度(2以上)を計算します。
PARALLEL (DEFAULT): オプティマイザは並列度を計算します。並列度は、すべての関係するインスタンスで使用可能なCPUの数に、初期化パラメータPARALLEL_THREADS_PER_CPUの値を掛けたものです。
PARALLEL (AUTO): データベースは並列度を計算します(結果は1以上になります)。計算された並列度が1の場合、文はシリアルで実行されます。
PARALLEL (MANUAL): オプティマイザは強制的に、文の中のオブジェクトのパラレル設定を使用します。
PARALLEL (integer): オプティマイザは、integerに指定された並列度を使用します。

次の例では、オプティマイザは並列度を計算します。文は常にパラレルで実行されます。

SELECT /*+ PARALLEL */ last_name
  FROM employees;

次の例では、オプティマイザは並列度を計算しますが、並列度は1の場合があります。その場合、文はシリアルで実行されます。

SELECT /*+ PARALLEL (AUTO) */ last_name
  FROM employees;

次の例では、PARALLELヒントは、表自体に現在適用されている並列度(5)を使用するようオプティマイザに指示します。

CREATE TABLE parallel_table (col1 number, col2 VARCHAR2(10)) PARALLEL 5; 

SELECT /*+ PARALLEL (MANUAL) */ col2
  FROM parallel_table;

オブジェクト・レベルのPARALLELヒントでは、次のように動作します。

PARALLEL: 問合せコーディネータはデフォルトの並列度を決定するために初期化パラメータの設定を検証する必要があります。
PARALLEL (integer): オプティマイザは、integerに指定された並列度を使用します。
PARALLEL (DEFAULT): オプティマイザは並列度を計算します。並列度は、すべての関係するインスタンスで使用可能なCPUの数に、初期化パラメータPARALLEL_THREADS_PER_CPUの値を掛けたものです。

次の例では、PARALLELヒントが、employees表定義内で指定された並列度を上書きします。

SELECT /*+ FULL(hr_emp) PARALLEL(hr_emp, 5) */ last_name
  FROM employees hr_emp;

次の例では、PARALLELヒントが、employees表定義内で指定された並列度を上書きし、並列度を計算するようにオプティマイザに指示します。並列度は、すべての関係するインスタンスで使用可能なCPUの数に初期化パラメータPARALLEL_THREADS_PER_CPUの値を掛けたものです。

SELECT /*+ FULL(hr_emp) PARALLEL(hr_emp, DEFAULT) */ last_name
  FROM employees hr_emp;

パラレル実行の詳細は、「CREATE TABLE」および『Oracle Database概要』を参照してください。

関連項目:

パラレル実行の詳細は、「CREATE TABLE」および『Oracle Database概要』を参照してください。
DBMS_PARALLEL_EXECUTEパッケージ(行のチャンクの変更を表に適用するメソッドを含むパッケージ)の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。エラーがない場合は、各チャンクに対する変更が個別にコミットされます。
PARALLEL_DEGREE_POLICY初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
NO_PARALLELヒント

PARALLEL_INDEXヒント

図「parallel_index_hint.gif」の説明

PARALLEL_INDEXヒントは、パーティション索引について索引レンジ・スキャン、全体スキャンおよび高速全体スキャンをパラレル化するために、指定された数の同時サーバーを使用するようオプティマイザに指示します。

integer値は、指定された索引の並列度を示します。DEFAULTを指定するか、いかなる値も指定しない場合、問合せコーディネータはデフォルトの並列度を決定するために初期化パラメータの設定を検証する必要があります。たとえば、次のヒントは、3つのパラレル実行プロセスが使用されることを示します。

SELECT /*+ PARALLEL_INDEX(table1, index1, 3) */

関連項目:

パラレル・ヒントの詳細は、「パラレル・ヒントの注意事項」を参照してください。

PQ_DISTRIBUTEヒント

図「pq_distribute_hint.gif」の説明

PQ_DISTRIBUTEヒントは、プロデューサおよびコンシューマ問合せサーバーに行を分散させる方法をオプティマイザに指示します。結合またはロードのいずれかで行の分散を制御できます。

ロードでの分散の制御パラレルINSERT ... SELECT文およびパラレルCREATE TABLE ... AS SELECT文で行の分散を制御し、プロデューサ(問合せ)およびコンシューマ(ロード)サーバー間で行を分散する方法を指示できます。構文の上位ブランチを使用するには、1つの分散方法を指定します。表3-22に、分散方法の値とそのセマンティクスを示します。

表3-22 ロードでの分散処理の値

分散	説明
`NONE`	分散処理なし。したがって、問合せおよびロード操作は、問合せサーバーごとに組み合されます。すべてのサーバーがすべてのパーティションをロードします。分散を行わないことで、偏りがない場合に行の分散によって発生するオーバーヘッドを避けることができます。偏りは、空のセグメントによって発生したり、文の条件で問合せによって評価されるすべての行が排除される場合に発生することがあります。この方法を使用することで偏りが発生する場合、かわりに`RANDOM`または`RANDOM_LOCAL`のいずれかの分散を使用します。注意: この分散方法は、慎重に使用してください。ロードされる各パーティションに対し、プロセスごとに512 KB以上のPGAメモリーが必要です。圧縮も同時に使用している場合、サーバーごとに約1.5 MBのPGAメモリーが消費されます。
`PARTITION`	この方法は、`tablespec`のパーティション情報を使用して、問合せサーバーからロード・サーバーへ行を分散します。この分散方法は、問合せおよびロード操作を組み合せることができない(または望ましくない)場合、すなわち、ロードされるパーティションの数がロード・サーバーの数以上で、ロードされるパーティション間で入力データが均等に分散される(偏りがない)場合に使用します。
`RANDOM`	この方法は、プロデューサの行をラウンドロビン法でコンシューマに分散します。この分散方法は、入力データの偏りが大きい場合に使用します。
`RANDOM_LOCAL`	この方法は、特定のパーティションの集合を保持する役割を果たすサーバーの集合に対して、プロデューサの行を分散します。2つ以上のサーバーが同じパーティションをロードする可能性はありますが、すべてのパーティションをロードするサーバーは存在しません。この分散方法は、入力データが偏っており、メモリーの制約によって問合せおよびロード操作を組み合せることができない場合に使用します。

たとえば、次のダイレクト・ロードINSERT操作の問合せおよびロード部分は、問合せサーバーごとに組み合されます。

INSERT /*+ APPEND PARALLEL(target_table, 16) PQ_DISTRIBUTE(target_table, NONE) */
  INTO target_table
  SELECT * FROM source_table;

次の表を作成する例では、オプティマイザは、target_tableのパーティション化を使用して行を分散します。

CREATE /*+ PQ_DISTRIBUTE(target_table, PARTITION) */ TABLE target_table
  NOLOGGING PARALLEL 16
  PARTITION BY HASH (l_orderkey) PARTITIONS 512
  AS SELECT * FROM source_table;

結合での分散の制御構文図の下位ブランチに示すように、2つの分散方法(外部表への分散処理と内部表への分散処理)を指定することで、結合での分散方法を制御できます。

outer_distributionは、外部表への分散処理です。
inner_distributionは、内部表への分散処理です。

分散の値は、HASH、BROADCAST、PARTITIONおよびNONEです。表3-23で説明するとおり、6つの組合せの表分散のみが有効です。

表3-23 結合での分散処理の値

分散	説明
`HASH`、`HASH`	各表の行は、結合キーにハッシュ関数を使用して、コンシューマ問合せサーバーにマップされます。マッピングが完了すると、各問合せサーバーは、結果として生成されるパーティションの組で結合を実行します。この分散は、表のサイズがほぼ等しく、結合操作がハッシュ結合またはソート/マージ結合で実施される場合にお薦めします。
`BROADCAST`、`NONE`	外部表のすべての行が各問合せサーバーにブロードキャストされます。内部表の行は、ランダムにパーティション化されます。この分散は、外部表のサイズが内部表よりもきわめて小さい場合にお薦めします。一般的に、内部表のサイズに問合せサーバーの数を乗じた数値が外部表のサイズよりも大きい場合、この分散を使用します。
`NONE`、`BROADCAST`	内部表のすべての行が各コンシューマ問合せサーバーにブロードキャストされます。外部表の行は、ランダムにパーティション化されます。この分散は、内部表のサイズが外部表よりもきわめて小さい場合にお薦めします。一般的に、内部表のサイズに問合せサーバーの数を乗じた数値が外部表のサイズより小さい場合、この分散を使用します。
`PARTITION`、`NONE`	外部表の行は、内部表のパーティション化を使用してマップされます。内部表は、結合キーでパーティション化されている必要があります。この分散は、外部表のパーティションの数が問合せサーバーの数と等しいかほぼ等しい(たとえば、パーティション数が14で問合せサーバー数が15)場合にお薦めします。注意: オプティマイザは、内部表がパーティション化されていないか、パーティション化キーと等価結合関係にない場合、このヒントを無視します。
`NONE`、`PARTITION`	内部表の行は、外部表のパーティション化を使用してマップされます。外部表は、結合キーでパーティション化されている必要があります。この分散は、外部表のパーティションの数が問合せサーバーの数と等しいかほぼ等しい(たとえば、パーティション数が14で問合せサーバー数が15)場合にお薦めします。注意: オプティマイザは、外部表がパーティション化されていないか、パーティション化キーと等価結合関係にない場合、このヒントを無視します。
`NONE`、`NONE`	各問合せサーバーは、各表から抽出した一致パーティションの組で結合操作を実行します。両方の表は、結合キーに基づいて同一レベルでパーティション化されている必要があります。

たとえば、rとsという2つの表がハッシュ結合によって結合されている場合、次の問合せには、ハッシュ分散を使用するためのヒントが含まれます。

SELECT /*+ORDERED PQ_DISTRIBUTE(s HASH, HASH) USE_HASH (s)*/ column_list
  FROM r,s
  WHERE r.c=s.c;

外部表rをブロードキャストするための問合せは、次のとおりです。

SELECT /*+ORDERED PQ_DISTRIBUTE(s BROADCAST, NONE) USE_HASH (s) */ column_list
  FROM r,s
  WHERE r.c=s.c;

関連項目:

Oracleでの結合操作のパラレル化の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

PUSH_PREDヒント

図「push_pred_hint.gif」の説明

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ヒント

図「push_subq_hint.gif」の説明

PUSH_SUBQヒントは、実行計画の初期段階で実行可能な手順で、マージされていない副問合せを評価するようオプティマイザに指示します。通常、マージされていない副問合せは、実行計画の最終手順で実行されます。副問合せのコストが比較的低く、副問合せによって行数が大幅に減少する場合、副問合せの早期評価によってパフォーマンスが向上する可能性があります。

このヒントは、副問合せがリモート表か、マージ結合によって結合されている表に適用される場合には効果がありません。

PX_JOIN_FILTERヒント

図「px_join_filter_hint.gif」の説明

このヒントは、パラレル結合のビットマップ・フィルタ処理の使用をオプティマイザに強制します。

QB_NAMEヒント

図「qb_name_hint.gif」の説明

QB_NAMEヒントを使用すると、問合せブロックの名前を定義できます。この名前は外部問合せ内のヒントまたはインライン・ビュー内のヒントで使用でき、名前が付けられた問合せブロックにある表で実行する問合せに影響をおよぼします。

2つ以上の問合せブロックに同じ名前が付いている場合や、同じ問合せブロックに対して2回、それぞれ異なる名前でヒントが適用されている場合は、オプティマイザはすべての名前を無視し、その問合せブロックを参照しているヒントも無視します。このヒントを使用して名前が付けられてはいない問合せブロックには、システムによって生成された一意の名前が付けられます。この名前は計画表に表示できます。また、問合せブロック内のヒントや問合せブロック・ヒントでも使用できます。次に例を示します。

SELECT /*+ QB_NAME(qb) FULL(@qb e) */ employee_id, last_name
  FROM employees e
  WHERE last_name = 'Smith';

RESULT_CACHEヒント

図「result_cache_hint.gif」の説明

RESULT_CACHEヒントは、メモリー内の現行の問合せまたは問合せのフラグメントの結果をキャッシュし、今後の問合せまたは問合せのフラグメントの実行時にキャッシュした結果を使用するようデータベースに指示します。このヒントは、トップレベル問合せ、subquery_factoring_clauseまたはFROM句のインライン・ビューで認識されます。キャッシュ結果は、共有プールの結果のキャッシュ・メモリー部分に保存されます。

作成に使用されたデータベース・オブジェクトが正常に修正されると、キャッシュ結果は自動的に無効化されます。このヒントは、RESULT_CACHE_MODE初期化パラメータの設定よりも優先されます。

問合せが結果キャッシュに使用できるのは、問合せで必要とされるすべてのファンクション(たとえば、組込みファンクション、ユーザー定義ファンクションまたは仮想列)が決定的である場合にかぎられます。

問合せがOCIクライアントから実行され、OCIクライアントの結果キャッシュが有効になっている場合、RESULT_CACHEヒントにより現行の問合せのクライアントのキャッシュが有効になります。

関連項目:

このヒントの使用方法については『Oracle Databaseパフォーマンス・チューニング・ガイド』、RESULT_CACHE_MODE初期化パラメータの詳細は『Oracle Databaseリファレンス』、OCI結果キャッシュの詳細および使用のガイドラインについては『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

RETRY_ON_ROW_CHANGEヒント

図「retry_on_row_change.gif」の説明

注意:

このヒントが有効になるのは、UPDATE操作およびDELETE操作に対してのみです。INSERT操作およびMERGE操作に対してはサポートされません。このヒントを指定すると、変更対象の行セットが決定された時点から、ブロックが実際に変更される時点までの間に、セット内の1つ以上の行のORA_ROWSCNが変更された場合に、操作が再試行されます。

関連項目:

これらのヒントの詳細は、「IGNORE_ROW_ON_DUPKEY_INDEXヒント」および「CHANGE_DUPKEY_ERROR_INDEXヒント」を参照してください。また、オンライン・アプリケーション・アップグレードに関連するヒントの使用方法については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

REWRITEヒント

図「rewrite_hint.gif」の説明

REWRITEヒントは、可能な場合、コストを考慮することなく、マテリアライズド・ビューに関する問合せをリライトするようオプティマイザに指示します。REWRITEヒントは、ビュー・リストとともに、またはビュー・リストなしで使用します。ビュー・リストとともにREWRITEを使用し、リストに適切なマテリアライズド・ビューが含まれている場合、Oracleはコストを考慮せずにそのビューを使用します。

Oracleでは、リスト外のビューを検討しません。ビュー・リストを指定しない場合、Oracleは適切なマテリアライズド・ビューを検索し、最終計画のコストを考慮することなく常にそのビューを使用します。

関連項目:

マテリアライズド・ビューの詳細は、『Oracle Database概要』および『Oracle Databaseアドバンスト・レプリケーション』を参照してください。
マテリアライズド・ビューでREWRITEを使用する場合の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

STAR_TRANSFORMATIONヒント

図「star_transformation_hint.gif」の説明

「NO_STATEMENT_QUEUINGヒント」

STAR_TRANSFORMATIONヒントは、変換を行う際に最適な計画を使用するようオプティマイザに指示します。このヒントを使用しない場合、オプティマイザは、変換された問合せ用の最適な計画のかわりに、変換なしで生成された最適な計画を使用するという、問合せの最適化に関する決定を行う場合があります。次に例を示します。

SELECT /*+ STAR_TRANSFORMATION */ s.time_id, s.prod_id, s.channel_id
  FROM sales s, times t, products p, channels c
  WHERE s.time_id = t.time_id
    AND s.prod_id = p.prod_id
    AND s.channel_id = c.channel_id
    AND c.channel_desc = 'Tele Sales';

ヒントが指定された場合でも、変換が実行される保証はありません。オプティマイザは、妥当と考えられる場合にかぎって副問合せを生成します。副問合せが生成されない場合には、変換された問合せが存在しないため、ヒントに関係なく、未変換の問合せに関する最適な計画が使用されます。

関連項目:

スター型変換の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。
STAR_TRANSFORMATION_ENABLED初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

STATEMENT_QUEUINGヒント

図「statement_queuing_hint.gif」の説明

NO_STATEMENT_QUEUINGヒントは、パラレル文のキューイングによって文がキューに入れられるかどうかに影響します。

PARALLEL_DEGREE_POLICYをAUTOに設定しない場合は、このヒントによって文がパラレル文キューイング用として認識され、リクエストされたDOPで十分なパラレル処理が可能な場合にのみ実行できるようにします。キューイングが有効にされる前の時点で使用可能なパラレル実行サーバーの数は、PARALLEL_SERVERS_TARGET初期化パラメータで定義されたシステム内で許可されるパラレル実行サーバーの最大数と使用中のパラレル実行サーバーの数との差です。

次に例を示します。

SELECT /*+ STATEMENT_QUEUING */ emp.last_name, dpt.department_name
  FROM employees emp, departments dpt
  WHERE emp.department_id = dpt.department_id;

関連項目:

UNNESTヒント

図「unnest_hint.gif」の説明

UNNESTヒントは、副問合せの本体のネストを解除し、その副問合せを含む問合せブロック本体にマージするようオプティマイザに指示します。これによって、アクセス・パスおよび結合の評価時に、オプティマイザが副問合せと問合せブロックを総合して考慮できるようになります。

副問合せのネストを解除する前に、オプティマイザは、文が有効かどうかをまず検討します。文は、経験則に基づくテストと問合せ最適化テストに合格する必要があります。UNNESTヒントは、副問合せブロックの有効性のみをチェックするようオプティマイザに指示します。副問合せブロックが有効な場合、経験則またはコストをチェックすることなく副問合せのネストを解除できます。

関連項目:

ネスト化された副問合せのネスト解除、および副問合せブロックが有効となる条件については、「コレクションのネスト解除例:」を参照してください。
副問合せのネスト解除の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

USE_CONCATヒント

図「use_concat_hint.gif」の説明

USE_CONCATヒントは、問合せのWHERE句内で組み合されたOR条件を、集合演算子UNION ALLを使用して複合問合せに変換するようオプティマイザに指示します。このヒントを使用しない場合、この変換は、連結を使用した問合せのコストが、使用しない場合よりも低い場合にのみ実行されます。USE_CONCATヒントは、コストより優先します。次に例を示します。

SELECT /*+ USE_CONCAT */ *
  FROM employees e
  WHERE manager_id = 108
     OR department_id = 110;

関連項目:

「NO_EXPANDヒント」を参照してください(このヒントの反対の機能です)。

USE_HASHヒント

図「use_hash_hint.gif」の説明

USE_HASHヒントは、指定された各表を、ハッシュ結合を使用して別の行のソースに結合するようオプティマイザに指示します。次に例を示します。

SELECT /*+ USE_HASH(l h) */ *
  FROM orders h, order_items l
  WHERE l.order_id = h.order_id
    AND l.order_id > 2400;

USE_MERGEヒント

図「use_merge_hint.gif」の説明

USE_MERGEヒントは、指定された各表を、ソート/マージ結合を使用して別の行のソースに結合するようオプティマイザに指示します。次に例を示します。

SELECT /*+ USE_MERGE(employees departments) */ * 
  FROM employees, departments 
  WHERE employees.department_id = departments.department_id;

LEADINGおよびORDEREDヒントとともに、USE_NLおよびUSE_MERGEヒントを使用することをお薦めします。オプティマイザは、参照表を結合の内部表にする必要がある場合に、これらのヒントを使用します。参照表が外部表の場合、ヒントは無視されます。

USE_NLヒント

USE_NLヒントは、指定された表を内部表として使用し、指定された各表をネストしたループ結合とともに別の行のソースに結合するようオプティマイザに指示します。

図「use_nl_hint.gif」の説明

次の例では、ネストしたループがヒントによって強制される場合、全表スキャンを介してordersがアクセスされ、各行にフィルタ条件l.order_id = h.order_idが適用されます。フィルタ条件を満たす各行については、索引order_idを介してorder_itemsがアクセスされます。

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;

INDEXヒントを問合せに追加すると、ordersの全表スキャンを回避し、より大規模なシステムで使用される実行計画と同様の実行計画を生成できる場合があります。ただし、ここでは特に効果的ではない場合があります。

USE_NL_WITH_INDEXヒント

図「use_nl_with_index_hint.gif」の説明