| Oracle Databaseパフォーマンス・チューニング・ガイド 11gリリース1（11.1） E05743-02 |
|
 戻る |
 次へ |
この章では、索引およびクラスタを使用してパフォーマンスを強化できる、または低下させるデータ・アクセス方法の概要を説明します。
この章には次の項があります。
この項では、次の項目について説明します。
問合せの最適化は、問合せ実行におけるあまり有効ではない索引の使用を避けるために役立ちますが、SQLエンジンは、表に対して定義されている索引が使用されているかどうかにかかわらず、継続的にすべての索引をメンテナンスします。書込み集中型アプリケーションでは、索引のメンテナンスにCPUとI/Oリソースが大量に必要となる場合があります。したがって、必要がなければ索引を作成しないでください。
最適なパフォーマンスを保つために、アプリケーションで使用していない索引を削除してください。使用されていない索引は、典型的なワークロードがかかる期間にALTER INDEX MONITORING USAGEファンクションを使用することで検出できます。この監視機能は、索引が使用されたかどうかを記録します。使用されていない索引が検出された場合は、削除してください。サンプリングした負荷以外の負荷で使用されている索引を削除しないように、典型的な負荷を監視していることを確認してください。
また、アプリケーション内では、文の実行計画の調査ですぐには明らかにならない索引の使用方法もあります。その例が、共有ロックが子表上に取り出されないようにする親表上の外部キー索引です。
|
関連項目:
|
また、新しい索引を作成してSQL文をチューニングするかどうかを決める場合、オプティマイザがアプリケーションの実行時にこれらの索引を使用するかどうかを判断するために、EXPLAIN PLAN文を使用することもできます。新しい索引を作成して現在解析中の文をチューニングする場合は、Oracleはその文を無効にします。
その文が次に解析されるとき、オプティマイザは、新しい索引を使用する可能性のある新しい実行計画を自動的に選択します。新しい索引をリモート・データベース上に作成して分散型の文をチューニングする場合は、その文が次に解析されるとき、オプティマイザがこれらの索引について検討します。
索引を作成してある文をチューニングした場合、他の文の実行計画に対するオプティマイザの選択に影響を及ぼす場合があるので注意してください。たとえば、ある文によって使用される索引を作成した場合、オプティマイザは、アプリケーションの他の文に対しても、その索引の使用を選択する場合があります。このため、最初にチューニング対象と判断した文をチューニングした後、アプリケーションのパフォーマンスおよび実行計画を再検査し、SQLトレース機能を利用します。
SQLアクセス・アドバイザは、どの索引が必要であるかを手動で判別する作業に対する代替機能です。このアドバイザをOracle Enterprise Managerから起動するか、DBMS_ADVISORパッケージAPIを介して実行すると、索引セットを推奨します。SQLアクセス・アドバイザはワークロードの使用を推奨するか、または指定のスキーマに関する仮定的なワークロードを生成します。SQLキャッシュの現在の内容、ユーザー定義のSQL文セットまたはSQLチューニング・セットなど、様々なワークロード・ソースが使用可能です。SQLアクセス・アドバイザにより指定のワークロードに関して推奨事項のセットを生成され、その中から実装する索引を選択できます。実装スクリプトが用意されており、手動で実行するか、またはOracle Enterprise Managerを介して自動的に実行できます。SQLアクセス・アドバイザの詳細は、「SQLアクセス・アドバイザの概要」を参照してください。
キーは、索引を付ける列または式です。次のガイドラインに従って、索引を付けるキーを選択します。
WHERE句で頻繁に使用されるキーに索引を付けることを検討します。
SQL文で表を結合するために頻繁に使用されるキーに索引を付けることを検討します。結合の最適化の詳細は、「パフォーマンスを考慮したハッシュ・クラスタの使用方法」を参照してください。
高度な選択性の索引キーを選択します。索引の選択性は、索引を付けるキーについて同じ値を持つ行の表内での割合です。同じ値を持つ行がほとんどない場合、索引の選択性は最適です。
|
注意: Oracleでは、整合性制約を使用して定義されるすべての一意キーおよび主キーのキーと式に、暗黙に索引を作成するか、既存の索引を使用します。 |
選択性の低い列への索引付けは、データ配分が偏っているために、1つまたは2つの値がその他の値よりはるかに使用頻度が低い場合に便利です。
個別値をほとんど持たないキーまたは式には標準のBツリー索引は使用しません。通常そのようなキーや式は選択性が劣っているので、頻繁に選択されるキー値がその他のキー値に比べて少ない場合を除くと、パフォーマンスは最適化されません。このような場合には、ビットマップ索引を使用すると効果的です。ただし、同時実行性の高いOLTPアプリケーションのように、索引が頻繁に変更される場合には向きません。
頻繁に修正される列には索引を付けません。索引付きの列を修正するUPDATE文および索引付きの表を修正するINSERT文とDELETE文では、索引がない場合よりも、処理に長い時間が必要となります。このようなSQL文は、表のデータのみでなく、索引のデータも修正する必要があります。また、取消しと再実行も追加的に生成されます。
ファンクションや演算子を含むWHERE句のみに指定されるキーには索引を付けません。索引付きのキーにMINやMAX以外のファンクションや演算子を使用するWHERE句は、ファンクション索引を除く索引を使用するアクセス・パスを選択しません。
同時実行の数多くのINSERT文およびUPDATE文、DELETE文が親表と子表をアクセスする場合、参照整合性制約の外部キーに索引を付けることを検討します。このような索引を使用すると、子表を共有ロックせずに親表でUPDATEおよびDELETEを実行できます。
索引を付けるキーを選択するとき、問合せのパフォーマンス向上が、INSERT、UPDATE、DELETEのパフォーマンス損失および索引を格納するために必要となる領域の使用に見合う価値があるかどうか検討してください。SQL文の処理時間を索引の有無によって実際に比較することをお薦めします。SQLトレース機能で処理時間を測定できます。
|
関連項目: ロックへの外部キーの影響の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
コンポジット索引には複数のキー列が含まれています。コンポジット索引には、次のような単一列索引を上回る利点があります。
場合によっては、それぞれの選択性が劣る複数の列や式を組み合せてコンポジット索引にすると、より高い選択性を得ることができます。
問合せによって選択される列がすべてコンポジット索引に含まれている場合、Oracleは、表にアクセスすることなく、索引からこれらの値を戻すことができます。
SQL文にコンポジット索引の先頭部分を利用する条件が含まれていれば、その文はコンポジット索引に関係するアクセス・パスを使用します。
索引の先頭部分とは、その索引を作成したCREATE INDEX文で列リストの先頭から連続的に指定された1つ以上の列の組合せのことです。次のCREATE INDEX文を例とします。
CREATE INDEX comp_ind ON table1(x, y, z);
x、xy、xyzの各列の組合せは、索引の先頭部分です。
yz、y、zの各列の組合せは、索引の先頭部分ではありません。
コンポジット索引を構成するキーを選択するために、次のガイドラインに従ってください。
WHERE句の条件で、頻繁にAND演算子で結合して使用されるキー・セットに対して、コンポジット索引を作成することを検討します。特に結合したときの選択性が個々のキーの選択性よりも優れている場合、コンポジット索引を作成してください。
複数の問合せが1つ以上のキー値に基づいて同じキー・セットを選択する場合、これらのキーのすべてを含むコンポジット索引を作成することを検討します。
もちろん、索引を作成するときの、一般的なパフォーマンスの利点およびトレードオフに関する前述のガイドラインを検討してください。
索引を作成しても、単に索引が存在するのみでは、オプティマイザはその索引を使用するアクセス・パスを選択できません。オプティマイザは、SQL文にアクセス・パスを使用可能にする構造が含まれている場合にかぎり、そのようなアクセス・パスを選択できます。索引アクセス・パスを使用するというオプションを問合せオプティマイザで可能にするには、文が索引アクセス・パスを使用可能にする構文になっていることを確認してください。
場合によっては、既存の索引を使用するアクセス・パスをSQL文で使用しないことも可能です。索引の選択性があまり優れておらず、全表スキャンの方が効率的であることがわかっている場合がそうです。そのような索引アクセス・パスを使用可能にする条件が文に含まれている場合は、次に示す方法の1つを使用して、オプティマイザに全表スキャンを使用するように強制できます。
NO_INDEXヒントを使用して特定索引の使用を禁止にし、問合せオプティマイザに最大限の柔軟性を持たせることができます。
INDEXヒントまたはINDEX_COMBINEヒントを使用し、オプティマイザに、ある索引（またはリストされている索引セット）を別の索引（または索引セット）のかわりに使用するように指示します。
パラレル実行は、索引を効果的に利用します。このオプションはパラレル索引レンジ・スキャンは実行しませんが、ネステッド・ループ結合を実行するためにパラレル索引参照を実行します。索引の選択性が高い（各索引エントリの行数が少ない）場合は、パラレル表スキャンよりも順次索引参照を使用することをお薦めします。
索引を縮小し分断化された領域を最小化するため、または索引の記憶特性を変更するために索引を再作成する場合があります。既存の索引のサブセットとなる新しい索引を作成するとき、または既存の索引を新しい記憶特性で再構築するとき、Oracleは、実表ではなく既存の索引を使用して索引作成のパフォーマンスを向上させる場合があります。
ただし、既存の索引よりも実表を使用した方が効果的な場合もあります。多くの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では、制約を使用可能または規定するときに、既存の索引を使用できます。索引を複製しないので、領域を大幅に節約できます。ただし、既存の索引がパーティション化されている場合は、索引のパーティション・キーもUNIQUEキーのサブセットである必要があります。サブセットでなければ、Oracleはさらに一意索引を追加作成し、制約を規定します。
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）に含まれている列があります。ファンクション索引により、索引で計算集中型の式を保存できます。
変換された列または式でファンクション索引を定義すると、そのファンクションまたは式をWHERE句またはORDER BY句で使用するとき、その索引を使用してデータを戻すことができます。これにより、Oracleは、SELECT文およびDELETE文を処理する際に式の値の計算をバイパスできます。したがって、ファンクション索引は、頻繁に実行されるSQL文のWHERE句またはORDER BY句の中に変換列（または式の中の列）が含まれているときに有益です。
Oracleでは、降順の索引は、ファンクション索引として処理されます。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では、レンジ・パーティション化およびハッシュ・パーティション化されたグローバル索引をどちらもサポートしています。レンジ・パーティション化されたグローバル索引では、各索引パーティションに、パーティション・バウンドで定義された値が含まれます。ハッシュ・パーティション化されたグローバル索引では、各パーティションに、Oracleのハッシュ関数により決定された値が含まれます。
マルチユーザーのOLTP環境で、索引内の少数のリーフ・ブロックに競合が多い場合、ハッシュ・メソッドにより索引のパフォーマンスが向上します。OLTPアプリケーションによっては、索引の右端にのみ索引が挿入される場合があります。これは、単調に増える列について索引が定義されている場合に行われます。このような場合、索引ページ、バッファ、更新のラッチ、および追加索引メンテナンス・アクティビティの競合により、索引の右端がホットスポットとなり、パフォーマンスが低下します。
ハッシュ・パーティション化されたグローバル索引では、索引エントリはパーティション・キーおよびパーティション数に基づいて異なるパーティションにハッシュされます。これにより、定義済のパーティション数全体に競合が拡散され、スループットが向上します。ハッシュ・パーティション化されたグローバル索引を使用すると、バッファ・ラッチの競合が複数のパーティションにわたって拡散されるため、大規模PDMLとして大きなファクト表に実行されるTPC-Hリフレッシュ関数には有効です。
ハッシュ・パーティション化では、索引エントリはOracleで生成されたハッシュ値に基づいて特定の索引パーティションにマップされます。ハッシュ・パーティション化されたグローバル索引を作成するための構文は、ハッシュ・パーティション表と非常によく似ています。索引パーティション・キーについての等価述語および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データ・ウェアハウス・ガイド』を参照してください。 |
ドメイン索引は、ユーザー定義の索引タイプで指定された索引作成論理で作成されます。索引タイプを使用すると、特定の演算子の述部に合うデータに効率よくアクセスできます。通常、ユーザー定義の索引タイプは、Spatialオプションと同様Oracleのオプションの一部です。たとえば、SpatialIndextypeを使用すると、ある条件ボックスにオーバーラップするSpatialデータを効率よく取り出せます。
ドメイン索引の作成と保守で指定できるパラメータは、カートリッジによって異なります。同様に、ドメイン索引のパフォーマンスと記憶域の特性は、カートリッジ固有のマニュアルを参照してください。
次の情報は、適切なカートリッジ・マニュアルを参照してください。
索引付けできるデータ型
使用できる索引タイプ
索引タイプで使用できる演算子
ドメイン索引を作成およびメンテナンスする方法
問合せで演算子を効率よく使用する方法
パフォーマンス特性の内容
|
注意: 索引の型はCREATE INDEXTYPE文でも作成できます。 |
|
関連項目: SpatialIndextypeの詳細は、『Oracle Spatial開発者ガイド』を参照してください。 |
クラスタとは、物理的にまとめて格納される1つ以上の表のグループです。それらの表は、共通の列を共有しており、通常、一緒に使用されるため、まとめて格納されます。関連する行が物理的にまとめて格納されているため、ディスク・アクセス時間が短縮されます。
クラスタを作成するには、CREATE CLUSTER文を使用します。
|
関連項目: クラスタの詳細は、『Oracle Database概要』を参照してください。 |
表をクラスタ化するかどうかを判断するために、次のガイドラインに従ってください。
アプリケーションが結合処理で頻繁にアクセスする表をクラスタ化します。
アプリケーションが表の結合を頻繁には行わない場合、または共通の列の値を頻繁に修正する場合、それらの表はクラスタ化しません。表をクラスタ化した場合、Oracleは修正された行を別のブロックへ移行して、クラスタをメンテナンスする必要もあります。このため、非クラスタ化表の値を修正する場合よりも、行のクラスタ・キー値を修正する場合の処理時間は長くなる可能性があります。
アプリケーションが複数の表の1つについてのみ頻繁に全表スキャンを行う場合、それらの表はクラスタ化しません。クラスタ化表の全表スキャンに要する処理時間は、非クラスタ化表の全表スキャンよりも長くなる可能性があります。複数の表があわせて格納されているため、Oracleが読み取る必要のあるブロックは多くなります。
マスター・レコードを選択してからディテール・レコードを選択することがよくある場合、マスター/ディテール表をクラスタ化します。ディテール・レコードはマスター・レコードと同じデータ・ブロックに格納されるため、選択時にそれらがメモリー内に存在している可能性が高くなり、OracleによるI/O処理が少なくなる場合があります。
同じマスターについて多くのディテール・レコードを選択することがよくある場合、ディテール表のみをクラスタに格納します。このようにすれば、同じマスターについて多くの詳細レコードを選択する問合せのパフォーマンスが改善され、マスター表に対する全表スキャンのパフォーマンスも低下させずに済みます。別の方法として、索引構成表を使用する方法があります。
同じクラスタ・キー値を持つすべての表からのデータが、1つまたは2つのOracleブロックを超える場合、それらの表はクラスタ化しません。クラスタ化表の行をアクセスする場合、Oracleはその値を持つ行を含んでいるブロックをすべて読み取ります。これらの行が複数のブロックを使用している場合、単一行をアクセスすることによって、非クラスタ化表で同じ行をアクセスする場合よりも多くの読取り処理が必要になる場合があります。
各クラスタ・キー値の行数が大きく異なっている場合は表をクラスタ化しないてください。クラスタ化した場合、カーディナリティの低いキー値の場合には領域が無駄になり、カーディナリティの高いキー値の場合には衝突が発生します。衝突が発生するとパフォーマンスが下がります。
アプリケーションのニーズに応じて、クラスタの長所と短所を検討してください。たとえば、結合文のパフォーマンス向上が、クラスタ・キー値を修正する文のパフォーマンス低下を上回る場合もあります。表をクラスタ化した場合と別々に格納した場合について実験して、処理時間を比較してください。
|
関連項目: クラスタの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
ハッシュ・クラスタは、ハッシュ関数をそれぞれの行のクラスタ・キー値に適用することによって、表データをグループ分けします。同じクラスタ・キー値を持つすべての行が、ディスク上にまとめて格納されます。アプリケーションのニーズに応じて、ハッシュ・クラスタの長所と短所を検討してください。特定の表をハッシュ・クラスタに格納する場合と、索引付きで単独に格納する場合を実験して、処理時間を比較してください。
ハッシュ・クラスタを使用する場合を判断するために、次のガイドラインに従ってください。
同じ列または列の組合せを使用する等価条件がWHERE句に含まれる場合、WHERE句を持つSQL文により頻繁にアクセスされる表を格納するために、ハッシュ・クラスタが使用されます。この列または列の組合せをクラスタ・キーとして指定します。
将来挿入する行およびすぐに挿入する行を含めて、特定のクラスタ・キー値を持つすべての行を保持するために必要な領域を判断できる場合、ハッシュ・クラスタに表を格納します。
ハッシュ関数の各値に対応する行が特定の列において昇順でソートされる場合、ソートされたクラスタ・データを操作することでレスポンス時間を改善できるのであれば、ソートされたハッシュ・クラスタを使用します。
アプリケーションが全表スキャンを実行する場合が多く、表が拡大することを見越してハッシュ・クラスタに大きな領域を割り当てる必要がある場合は、その表をハッシュ・クラスタに格納しません。そのような全表スキャンでは、いくつかのブロックにはほとんど行が含まれていなくても、ハッシュ・クラスタに割り当てられているブロックをすべて読み取る必要があります。表を単独で格納することによって、全表スキャンにより読み取られるブロック数が減少します。
アプリケーションがクラスタ・キー値を頻繁に修正する場合、ハッシュ・クラスタに表は格納しません。表をクラスタ化した場合、Oracleは修正された行を別のブロックへ移行して、クラスタをメンテナンスする必要もあります。このため、非クラスタ化表の値を修正する場合よりも、行のクラスタ・キー値を修正する場合の処理時間は長くなる可能性があります。
前述の考慮事項に基づいてハッシングが適切であるかぎり、他の表と頻繁に結合されるかどうかにかかわらず、単一の表をハッシュ・クラスタに格納することは有益です。
|
関連項目:
|
