| Oracle® Database SQLチューニング・ガイド 12c リリース1 (12.1) B71277-09 |
|
 前 |
 次へ |
この付録では、索引およびクラスタを使用してパフォーマンスを強化できる、または低下させるデータ・アクセス方法の概要を説明します。
この付録の内容は次のとおりです。
ここでは、以下の項目について説明します。
書込み集中型アプリケーションでは、索引のメンテナンスにCPUとI/Oリソースが大量に必要となる場合があります。
問合せの最適化により、問合せの実行における非選択的索引の使用を回避できますが、SQLエンジンは、索引が問合せで使用されるかどうかにかかわらず、表に対して定義されたすべての索引を継続的にメンテナンスする必要があります。したがって、必要がないかぎり索引を作成しないでください。
最適なパフォーマンスを保つために、アプリケーションで使用していない索引を削除してください。使用されていない索引は、典型的なワークロードのかかる期間にわたってALTER INDEX MONITORING USAGE機能を使用することで検出できます。この監視機能は、索引が使用されたかどうかを記録します。サンプリングした負荷以外の負荷で使用されている索引を削除しないように、典型的な負荷を監視していることを確認してください。
また、アプリケーション内では、文の実行計画の調査ですぐには明らかにならない索引の使用方法もあります。その例が、共有ロックが子表上に取り出されないようにする親表上の外部キー索引です。
新しい索引を作成して文のチューニングを行うかどうかを決定する場合、EXPLAIN PLAN文を使用して、アプリケーションの実行時にオプティマイザがこれらの索引を使用するかどうかを調べることもできます。新しい索引を作成して現在解析中の文をチューニングする場合、Oracle Databaseはその文を無効にします。
その文が次に解析されるとき、オプティマイザは、新しい索引を使用する可能性のある新しい実行計画を自動的に選択します。新しい索引をリモート・データベース上に作成して分散型の文をチューニングする場合は、その文が次に解析されるとき、オプティマイザがこれらの索引について検討します。
索引を作成して、ある文をチューニングした場合、他の文の実行計画に対するオプティマイザの選択に影響を及ぼす場合があります。たとえば、ある文によって使用される索引を作成した場合、オプティマイザは、アプリケーションの他の文に対しても、その索引の使用を選択する場合があります。このため、最初にチューニング対象と判断した文をチューニングした後、アプリケーションのパフォーマンスおよび実行計画を再検査し、SQLトレース機能を利用します。
関連項目:
ALTER INDEX MONITORING USAGE文の構文およびセマンティクスの詳細は、Oracle Database SQL言語リファレンスを参照してください
外部キーの詳細は、Oracle Database開発者ガイドを参照してください
SQLアクセス・アドバイザは、どの索引が必要であるかを手動で判別する作業に対する代替機能です。このアドバイザを、Oracle Enterprise Manager Cloud Control (Cloud Control)から起動するか、DBMS_ADVISORパッケージAPIで実行すると、索引セットが推奨されます。SQLアクセス・アドバイザはワークロードの使用を推奨するか、または指定のスキーマに関する仮定的なワークロードを生成します。
ワークロードのソースには、SQLキャッシュの現在の内容、ユーザー定義のSQL文のセットまたはSQLチューニング・セットなどを使用できます。ワークロードを指定すると、SQLアクセス・アドバイザにより推奨事項のセットが生成され、実装する索引を選択できます。SQLアクセス・アドバイザは、手動で実行またはCloud Controlを介して自動的に実行できる実装のためのスクリプトを提供します。
関連項目:
キーは、索引を付ける列または式です。
次のガイドラインに従って、索引を付けるキーを選択します。
WHERE句に頻出するキーの索引付けを検討します。
SQL文で表の結合に頻繁に使用されるキーの索引付けを検討します。
選択性の高い索引キーを選択します。索引の選択性は、索引付けするキー値と同じ値を持つ行が表に含まれる割合です。同じ値を持つ行がほとんどない場合、索引の選択性は最適です。
注意:
整合性制約で定義されたキーおよび一意キーと主キーの式では、Oracle Databaseが自動的に索引を作成するか、既存の索引が使用されます。
データ配分に偏りがあるため、他の値と比較して1つまたは2つの値の発生が非常に少ない場合、選択性の低い列の索引付けが役立つ場合もあります。
個別値をほとんど持たないキーまたは式には、標準のBツリー索引を使用しません。通常、そのようなキーや式は非選択性であるため、頻繁に選択されるキー値がその他のキー値に比べてそれほど多くない場合を除くと、パフォーマンスは最適化されません。このような場合には、ビットマップ索引を使用すると効果的です。ただし、同時実行性の高いOLTPアプリケーションのように、索引が頻繁に変更される場合には向きません。
変更が頻繁に行われる列は、索引付けしないでください。索引付きの列を修正するUPDATE文および索引付きの表を修正するINSERT文とDELETE文では、索引がない場合よりも、処理に長い時間が必要となります。このようなSQL文では、索引のデータおよび表のデータの変更が必要です。また、追加のUNDOおよびREDOも作成されます。
ファンクションや演算子を含むWHERE句のみに指定されるキーには索引を付けません。索引付きのキーにMINやMAX以外のファンクションや演算子を使用するWHERE句は、ファンクション索引を除く索引を使用するアクセス・パスを選択しません。
同時実行の数多くのINSERT文およびUPDATE文、DELETE文が親表と子表にアクセスする場合、参照整合性制約の外部キーに索引を付けることを検討します。このような索引を使用すると、子表を共有ロックせずに親表でUPDATEおよびDELETEを実行できます。
索引を付けるキーを選択するとき、問合せのパフォーマンス向上が、INSERT、UPDATE、DELETE文のパフォーマンス損失および索引を格納するために必要となる領域の使用に見合う価値があるかどうか検討してください。SQL文の処理時間を索引の有無によって実際に比較することをお薦めします。SQLトレース機能で処理時間を測定できます。
関連項目:
ロックへの外部キーの影響の詳細は、Oracle Database概要を参照してください
コンポジット索引には複数のキー列が含まれます。
コンポジット索引には、次のような単一列索引を上回る利点があります。
選択性の向上
選択性の低い複数の列または式を組み合せることで、選択性の高いコンポジット索引を作成できる場合があります。
I/Oの削減
Oracle Databaseでは、問合せで選択されるすべての列がコンポジット索引に含まれている場合、表にアクセスすることなく、索引でこれらの値を戻すことができます。
SQL文の構成メンバーが索引の先頭部分を使用する場合、その文はコンポジット索引を含むアクセス・パスを使用できます。
注意:
このことは、索引スキップ・スキャンには現在、該当しなくなっています。
索引の先頭部分とは、その索引を作成したCREATE INDEX文で列リストの先頭から連続的に指定された1つ以上の列の組合せのことです。次のCREATE INDEX文について考えてみます。
CREATE INDEX comp_ind ON table1(x, y, z);
x、xy、xyzの各列の組合せは、索引の先頭部分です。
yz、y、zの各列の組合せは、索引の先頭部分ではありません。
関連項目:
コンポジット索引を構成するキーを選択するために、次のガイドラインに従ってください。
AND演算子で結合してWHERE句の条件で頻繁に使用されるキー、特に、各キーの個別の選択性と比較して、キーを組み合せることで選択性が高くなる場合、コンポジット索引の作成を検討します。
複数の問合せが1つ以上のキー値に基づいて同じキー・セットを選択する場合、これらのキーのすべてを含むコンポジット索引を作成することを検討します。
また、索引を作成する際の一般的なパフォーマンスの利点およびトレードオフに関する前述のガイドラインも検討してください。
場合によって、SQL文が索引アクセス・パスを使用しないようにできます。たとえば、索引の選択性が高くなく、全表スキャンのほうが効率的であるとわかっています。
そのような索引アクセス・パスを使用可能にする条件が文に含まれている場合は、次に示す方法の1つを使用して、オプティマイザに全表スキャンを使用するように強制できます。
NO_INDEXヒントを使用して特定索引の使用を禁止にし、問合せオプティマイザに最大限の柔軟性を持たせることができます。
FULLヒントを使用し、オプティマイザに対して索引スキャンのかわりに全表スキャンを選択するように指示します。
INDEXヒントまたはINDEX_COMBINEヒントを使用し、オプティマイザに、ある索引(またはリストされている索引セット)を別の索引(または索引セット)のかわりに使用するように指示します。
パラレル実行は、索引を効果的に利用します。このオプションは、パラレル索引レンジ・スキャンを実行しませんが、ネステッド・ループ・ジョインをパラレル実行するためにパラレル索引参照を実行します。索引の選択性が高い(各索引エントリの行数が少ない)場合は、パラレル表スキャンよりも順次索引参照をお薦めします。
関連項目:
NO_INDEX、FULL、INDEX、INDEX_COMBINEおよびヒントの詳細は、「オプティマイザへの影響」を参照してください
索引を縮小し分断化された領域を最小化するため、または索引の記憶特性を変更するために索引を再作成する場合があります。既存の索引のサブセットとなる新しい索引を作成する場合、または新しい記憶特性を使用して既存の索引を再構築する場合、Oracle Databaseでは、実表ではなく既存の索引を使用することで索引作成のパフォーマンスが向上する場合があります。
ただし、既存の索引ではなく、実表を使用することが有効な場合もあります。多くのDMLが実行された表の索引を考えてみてください。DMLのために索引のサイズが大きくなり、各ブロックが50%以下しか満たされなくなる場合があります。索引が表のほとんどの列を参照している場合、索引が表よりも大きくなりかねません。その場合は、索引よりも実表を使用した方が、索引の再作成が速くできます。
既存の索引を再編成または縮小するため、または既存の索引の記憶特性を変更するには、ALTER INDEX . . . REBUILD文を使用します。REBUILD文は、新しい索引の基礎として既存の索引を使用します。STORAGE(エクステントの割当て用)、TABLESPACE(索引を新しい表領域に移動する)およびINITRANS(エントリの最初の数を変更する)などのすべての索引記憶用の文がサポートされています。
ALTER INDEX . . . REBUILDは、高速全体スキャン機能を使用するので、通常は索引を削除して再作成するよりも高速です。この文は、マルチブロックI/Oを使用して索引ブロックをすべて読み取ってから、ブランチ・ブロックを廃棄します。さらに、このアプローチには、再作成の実行中の問合せには、旧索引を利用できるという利点があります。
関連項目:
CREATE INDEX文とALTER INDEX文、および索引の再作成に関する制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください
COALESCEオプションを持つALTER INDEX文を使用して索引のリーフ・ブロックを結合できます。
このオプションでは、索引のリーフ・レベルを結合して空きブロックにし、再利用できます。また、索引をオンラインで再作成することもできます。
関連項目:
この文の構文の詳細は、『Oracle Database SQL言語リファレンス』および『Oracle Database管理者ガイド』を参照してください
UNIQUE制約、またはPRIMARY KEY制約の一意性の側面に関して、一意性を規定するために、表の既存の一意でない索引を使用できます。このアプローチの利点は、制約が使用禁止にされているときでも索引が使用可能であり、妥当であるということです。したがって、使用禁止にされているUNIQUE制約またはPRIMARY KEY制約を使用可能にするために、その制約に対応付けられている一意索引を再作成する必要はありません。これにより、大規模表で操作を使用可能にする際に時間を大幅に節約できます。
さらに、一意でない索引を使用して一意性を規定すると、索引の重複を排除できます。主キー列がコンポジット索引の接頭辞として組み込まれている場合、その列に対する一意索引は不要です。制約を使用可能または規定するときに、既存の索引を使用できます。また、索引を複製しないので、領域を大幅に節約できます。ただし、既存の索引がパーティション化されている場合は、索引のパーティション・キーもUNIQUEキーのサブセットである必要があります。サブセットでない場合、Oracle Databaseでは、一意索引が追加作成され、制約を規定します。
ENABLE NOVALIDATE制約は、新しいデータのENABLE VALIDATE制約と同じように動作します。制約をENABLE NOVALIDATE状態にすることは、表に入力された新規データが制約に準拠する必要があることを意味します。既存のデータはチェックされません。制約をENABLE NOVALIDATE状態にすることにより、表をロックしないで制約を使用可能にできます。
制約を使用禁止から使用可能に変更する場合、表をロックする必要があります。使用可能にする際に、表に対する操作が制約に準拠していることを確認できないため、新しいDML、問合せまたはDDLは実行できません。ENABLE NOVALIDATE状態では、制約に違反する操作を表に対して実行できません。
表のパラレル一貫読取り問合せにより、ENABLE NOVALIDATE制約を検証して、制約に違反するデータがあるかどうかを判断できます。ロックされないため、表の読取りも書込みも使用可能化操作によってブロックされません。さらに、ENABLE NOVALIDATE制約はパラレルで検査できます。複数の制約を同時に検査し、パラレル問合せを使用して各制約の妥当性をチェックできます。
制約と索引を持つ表を作成する手順は次のとおりです。
制約を持つ表を作成します。
NOT NULL制約には名前を付けなくても構いませんが、使用可能かつ検証済で作成してください。他のすべての制約(CHECK、UNIQUE、PRIMARY KEYおよびFOREIGN KEY)に名前を付け、使用禁止で作成します。
注意:
デフォルトでは、制約はENABLED状態で作成されます。
旧データを表にロードします。
制約に必要な索引を含め、すべての索引を作成します。
未検査の制約をすべて使用可能にします。これは、外部キーの前に主キーに対して行ってください。
ユーザーがデータを問合せおよび変更できるようにします。
制約ごとに別個のALTER TABLE文を使用して、すべての制約を検証します。これは、外部キーの前に主キーに対して行ってください。次に例を示します。
CREATE TABLE t (a NUMBER CONSTRAINT apk PRIMARY KEY DISABLE, b NUMBER NOT NULL); CREATE TABLE x (c NUMBER CONSTRAINT afk REFERENCES t DISABLE);
ここで、表tにデータをロードします。
CREATE UNIQUE INDEX tai ON t (a); CREATE INDEX tci ON x (c); ALTER TABLE t MODIFY CONSTRAINT apk ENABLE NOVALIDATE; ALTER TABLE x MODIFY CONSTRAINT afk ENABLE NOVALIDATE;
この時点で、ユーザーは、表tでINSERT、UPDATE、DELETEおよびSELECTの各操作を実行できます。
ALTER TABLE t ENABLE CONSTRAINT apk; ALTER TABLE x ENABLE CONSTRAINT afk;
これで、制約はENABLE VALIDATEになりました。
関連項目:
整合性制約の詳細は、『Oracle Database概要』を参照してください。
ファンクション索引には、ファンクション(たとえば、UPPERファンクション)で変換される列、または式(たとえば、col1 + col2)に含まれている列があります。
ファンクション索引は、頻繁に実行されるSQL文のWHERE句やORDER BY句の中に変換列(または式の中の列)が含まれている場合に有益です。変換された列または式でファンクション索引を定義すると、データベースは、そのファンクションまたは式をWHERE句またはORDER BY句で使用するときに、その索引を使用できます。このようにして、SELECT文およびDELETE文を処理する際に式の計算を回避できます。
Oracle Databaseでは、降順の索引は、ファンクション索引として処理されます。DESCのマークのある列は、降順でソートされます。
たとえば、UPPER(column_name)キーワードまたはLOWER(column_name)キーワードで定義されたファンクション索引を使用すると、大/小文字を区別しない検索ができます。次の文で索引を発行したとします。
CREATE INDEX uppercase_idx ON employees (UPPER(last_name));
前述の索引を使用すると、次のような問合せの処理が容易になります。
SELECT * FROM employees WHERE UPPER(last_name) = 'MARKSON';
関連項目:
ファンクション索引の使用の詳細は、『Oracle Database開発ガイド』および『Oracle Database管理者ガイド』を参照してください
CREATE INDEX文の詳細は、Oracle Database SQL言語リファレンスを参照してください
パーティション表と同様に、パーティション索引を使用すると、管理性、可用性、パフォーマンスおよびスケーラビリティが向上します。個別にパーティション化(グローバル索引)することも、表のパーティション化メソッド(ローカル索引)に自動的にリンクすることも可能です。
Oracle Databaseでは、レンジ・パーティション化およびハッシュ・パーティション化されたグローバル索引をサポートします。レンジ・パーティション化されたグローバル索引では、各索引パーティションに、パーティション・バウンドで定義された値が含まれます。ハッシュ・パーティション化されたグローバル索引では、各パーティションに、Oracle Databaseハッシュ関数により決定された値が含まれます。
マルチユーザーのOLTP環境で、索引内の少数のリーフ・ブロックに競合が多い場合、ハッシュ・メソッドにより索引のパフォーマンスが向上します。OLTPアプリケーションによっては、索引の右端にのみ索引が挿入される場合があります。この状況は、単調に増える列に対して索引を定義した場合に起こります。この状況では、索引ページ、バッファ、更新のラッチおよび追加索引メンテナンス・アクティビティの競合により、索引の右端がホット・スポットとなり、パフォーマンスが低下します。
ハッシュ・パーティション化されたグローバル索引では、索引エントリはパーティション・キーおよびパーティション数に基づいて異なるパーティションにハッシュされます。これにより、定義済のパーティション数全体に競合が拡散され、スループットが向上します。ハッシュ・パーティション化されたグローバル索引を使用すると、バッファ・ラッチの競合が複数のパーティションにわたって拡散されるため、大規模PDMLとして大きなファクト表に実行されるTPC-Hリフレッシュ関数には有効です。
ハッシュ・パーティション化では、索引エントリはOracle Databaseで生成されたハッシュ値に基づいて特定の索引パーティションにマップされます。ハッシュ・パーティション化されたグローバル索引を作成するための構文は、ハッシュ・パーティション表と非常によく似ています。索引パーティション・キーについての等価述語およびIN述語を伴う問合せでは、グローバル・ハッシュ・パーティション索引を効率的に使用して問合せにすばやく回答できます。
関連項目:
グローバル索引表の詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。
索引構成表は、表のデータが、対応付けられた索引に保持されるという点で普通の表とは異なります。新しい行の追加、行の更新、行の削除など、表データを変更すると、索引のみが更新されます。データ行は索引に格納されるため、索引構成表では完全一致、範囲検索またはその両方を含む問合せの表データに対するさらに高速なキー・ベースのアクセスが可能になります。
親/子関係は、索引構成表を保証する状況の一例です。たとえば、メンバー表に電話番号を含む子表があるとします。メンバーの電話番号は、時間の経過とともに変更および追加されます。ヒープ構成表では、行は適合するデータ・ブロックに挿入されます。ただし、メンバー表を問い合せる場合、電話番号は常に子表から取得されます。取得の効率性を高めるために、指定のメンバーの電話レコードが互いにデータ・ブロック内の近くに挿入されるように、索引構成表に電話番号を格納できます。
特定の状況では、索引構成表の方がヒープ構成表よりもパフォーマンスの面で利点があります。たとえば、問合せに必要なキャッシュ内のブロック数が比較的少ない場合、データベースではバッファ・キャッシュがより効率的に使用されます。問合せに必要な個別のブロック数が比較的少ない場合は、1回の物理I/Oによって必要なデータがすべて取得されるため、各問合せに必要なI/Oの量はわずかで済みます。
グローバル・ハッシュ・パーティション索引は索引構成表でサポートされており、マルチユーザーのOLTP環境でパフォーマンスが向上します。索引構成表は、関連するデータをまとめて格納する場合、またはデータを特定の順序で物理的に格納する場合に役立ちます。
関連項目:
索引構成表の詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。
ビットマップ索引は、次のすべての特性を持つ問合せのパフォーマンスを大幅に向上できます。
カーディナリティが低いか中位である列に関する述語がWHERE句に複数含まれています。
カーディナリティが低いか中位である列に関する個々の述語が多数の行を選択しています。
カーディナリティが低いか中位である列の一部または全部に対して、問合せで使用されるビットマップ索引が作成されています。
問合せの表に多数の行が含まれています。
複数のビットマップ索引を使用して、単独の表に対する条件を評価できます。このため、ビットマップ索引は、長いWHERE句を含む複合非定型問合せにとって非常に有効です。ビットマップ索引は、集合問合せでもスター・スキーマでの結合の最適化でも最適なパフォーマンスを提供します。
関連項目:
ビットマップ索引の詳細は、『Oracle Database概要』および『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください
単一表のビットマップ索引の他に、ビットマップ結合索引を作成できます。この索引は、複数の表を結合するためのビットマップ索引です。ビットマップ結合索引では、事前に制限事項を実行することで、結合する必要のあるデータ量を削減して領域を節約できます。ビットマップ結合索引は、表の列の値ごとに、別の表の対応する行のROWIDを格納します。データ・ウェアハウス環境では、結合条件は、ディメンション表の主キー列、およびファクト表の外部キー列との間の等価内部結合です。
ビットマップ結合索引は、マテリアライズド結合ビューより格納の効率がはるかによく、事前に結合をマテリアライズする方法の代替手段です。マテリアライズド結合ビューは、ファクト表のROWIDを圧縮しません。
関連項目:
ビットマップ結合索引の例および制限については、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。
ドメイン索引は、ユーザー定義の索引タイプで指定された索引作成論理で作成されます。索引タイプは、ドメインの(アプリケーション固有の)索引を管理するルーチンを指定するオブジェクトです。
索引タイプを使用すると、特定の演算子の述部に合うデータに効率よくアクセスできます。通常、ユーザー定義の索引タイプは、Oracle Spatial and Graphオプションのように、Oracle Databaseオプションの一部です。
ドメイン索引の作成と保守で指定できるパラメータは、カートリッジによって異なります。同様に、ドメイン索引のパフォーマンスと記憶域の特性は、カートリッジ固有のマニュアルを参照してください。
次の情報は、適切なカートリッジ・マニュアルを参照してください。
索引付けの可能なデータ型
使用できる索引タイプ
索引タイプで使用できる演算子
ドメイン索引を作成およびメンテナンスする方法
問合せで演算子を最も効率よく使用する方法
パフォーマンス特性の内容
注意:
索引タイプはCREATE INDEXTYPE文でも作成できます。
関連項目:
spatialデータの索引付けの詳細は、Oracle Spatial and Graph開発者ガイドを参照してください
表クラスタは、共通の列を共有し、通常はSQL文で同時に使用されるため、物理的にまとめて格納される1つ以上の表のグループです。
CREATE CLUSTER文を使用します。次の場合は、表のクラスタ化を検討します。
結合処理で、アプリケーションが表に頻繁にアクセスする場合。
マスター/ディテール表において、アプリケーションがマスター・レコードを選択してから対応するディテール・レコードを選択することがよくある場合。
ディテール・レコードはマスター・レコードと同じデータ・ブロックに格納されるため、選択する際にそれらがメモリー内に存在している可能性があります。これにより、Oracle Databaseでは、必要なI/O処理が減少します。
アプリケーションが、同じマスターについて多数のディテール・レコードを選択することがよくある場合。
この場合、ディテール表のみをクラスタに格納します。このようにすれば、同じマスターについて多くの詳細レコードを選択する問合せのパフォーマンスが改善され、マスター表に対する全表スキャンのパフォーマンスも低下させずに済みます。別の方法として、索引構成表を使用する方法があります。
次の場合は、表をクラスタ化しません。
アプリケーションが表の結合を頻繁には行わない場合、または共通の列の値を頻繁に変更する場合。
Oracle Databaseでは、行のクラスタ・キー値を変更すると、クラスタを維持するために変更された行を別のブロックに移行することが必要になる場合があるため、非クラスタ化表の値を変更する場合よりも時間がかかります。
アプリケーションが複数の表の1つについてのみ頻繁に全表スキャンを行う場合。
クラスタ化表の全表スキャンに要する処理時間は、非クラスタ化表の全表スキャンよりも長くなる可能性があります。表がまとめて格納されているため、より多くのブロックの読取りが必要になる可能性があります。
同じクラスタ・キー値を持つすべての表のデータのブロック数が、1つや2つではない場合。
Oracle Databaseでは、クラスタ化表の行にアクセスする際に、その値を持つ行を含むすべてのブロックを読み取ります。これらの行が複数のブロックを使用している場合、単一行にアクセスすることによって、非クラスタ化表で同じ行にアクセスする場合よりも多くの読取り処理が必要になる場合があります。
各クラスタ・キー値の行数が大きく異なっている場合。
カーディナリティの低いキー値の場合には領域が無駄になります。カーディナリティの高いキー値の場合には衝突が発生します。衝突が発生するとパフォーマンスが下がります。
アプリケーションでのクラスタの長所と短所を検討してください。たとえば、結合文のパフォーマンス向上が、クラスタ・キー値を修正する文のパフォーマンス低下を上回る場合もあります。表をクラスタ化した場合と別々に格納した場合について実験して、処理時間を比較してください。
関連項目:
表クラスタの詳細は、Oracle Database概要を参照してください
表クラスタの作成の詳細は、Oracle Database管理者ガイドを参照してください
ハッシュ・クラスタは、ハッシュ関数をそれぞれの行のクラスタ・キー値に適用することによって、表データをグループ分けします。
同じクラスタ・キー値を持つすべての行が、ディスク上にまとめて格納されます。アプリケーションでのハッシュ・クラスタの長所と短所を検討してください。特定の表について、ハッシュ・クラスタの場合と、索引付きで単独の場合とで実験を行って処理時間を比較してください。
ハッシュ・クラスタを使用する場合を判断するために、次のガイドラインに従ってください。
同じ列または列の組合せを使用する等価条件がWHERE句に含まれる場合、WHERE句を持つSQL文により頻繁にアクセスされる表を格納するために、ハッシュ・クラスタが使用されます。この列または列の組合せをクラスタ・キーとして指定します。
即時および将来において挿入する行を含め、特定のクラスタ・キー値を持つすべての行を保持するのに必要な領域を判断できる場合は、ハッシュ・クラスタに表を格納します。
ハッシュ関数の各値に対応する行が特定の列において昇順でソートされる場合、ソートされたクラスタ・データで操作のレスポンス時間が改善される場合は、ソートされたハッシュ・クラスタを使用します。
次の場合には、ハッシュ・クラスタに表を格納しません。
アプリケーションが頻繁に全表スキャンを実行する場合。
表が拡大することを見越してハッシュ・クラスタに大きな領域を割り当てる必要がある場合。
全表スキャンでは、いくつかのブロックにはほとんど行が含まれていなくても、ハッシュ・クラスタに割り当てられているブロックをすべて読み取る必要があります。表を単独で格納することによって、全表スキャンにより読み取られるブロック数が減少します。
アプリケーションがクラスタ・キー値を頻繁に修正する場合、ハッシュ・クラスタに表は格納しません。Oracle Databaseでは、行のクラスタ・キー値を変更すると、クラスタを維持するために変更された行を別のブロックに移行することが必要になる場合があるため、非クラスタ化表の値を変更する場合よりも時間がかかる可能性があります。
このリストの検討事項に基づいた表のハッシングが適切な場合、単一の表をハッシュ・クラスタに格納することは有益です。表が他の表と頻繁に結合されるかどうかにかかわらず同じことが言えます。
関連項目:
ハッシュ・クラスタの管理方法の詳細は、Oracle Database管理者ガイドを参照してください
CREATE CLUSTER文の詳細は、Oracle Database SQL言語リファレンスを参照してください
