A 索引および表クラスタに関するガイドライン
この付録では、索引およびクラスタを使用してパフォーマンスを強化できる、または低下させるデータ・アクセス方法の概要を説明します。
この付録の内容は次のとおりです。
A.1 索引パフォーマンスのチューニングに関するガイドライン
パフォーマンスのすべての問題が索引によって解決するわけではありません。これらを使用するタイミングと方法は、慎重に考慮する必要があります。
この項では、次の項目について説明します。
A.1.1 論理構造のチューニングに関するガイドライン
書込み集中型アプリケーションでは、索引のメンテナンスにCPUとI/Oリソースが大量に必要となる場合があります。
問合せの最適化により、問合せの実行における非選択的索引の使用を回避できますが、SQLエンジンは、索引が問合せで使用されるかどうかにかかわらず、表に対して定義されたすべての索引を継続的に維持する必要があります。したがって、必要がないかぎり索引を作成しないでください。
最適なパフォーマンスを保つために、アプリケーションで使用していない索引を削除してください。使用されていない索引は、典型的なワークロードのかかる期間にわたってALTER INDEX MONITORING USAGE
機能を使用することで検出できます。この監視機能は、索引が使用されたかどうかを記録します。サンプリングした負荷以外の負荷で使用されている索引を削除しないように、典型的な負荷を監視していることを確認してください。
また、アプリケーション内では、文の実行計画の調査ですぐには明らかにならない索引の使用方法もあります。その例が、共有ロックが子表上に取り出されないようにする親表上の外部キー索引です。
新しい索引を作成して文のチューニングを行うかどうかを決定する場合、EXPLAIN PLAN
文を使用して、アプリケーションの実行時にオプティマイザがこれらの索引を使用するかどうかを調べることもできます。新しい索引を作成して現在解析中の文をチューニングする場合、Oracle Databaseはその文を無効にします。
その文が次に解析されるとき、オプティマイザは、新しい索引を使用する可能性のある新しい実行計画を自動的に選択します。新しい索引をリモート・データベース上に作成して分散型の文をチューニングする場合は、その文が次に解析されるとき、オプティマイザがこれらの索引について検討します。
索引を作成して、ある文をチューニングした場合、他の文の実行計画に対するオプティマイザの選択に影響を及ぼす場合があります。たとえば、ある文によって使用される索引を作成した場合、オプティマイザは、アプリケーションの他の文に対しても、その索引の使用を選択する場合があります。このため、最初にチューニング対象と判断した文をチューニングした後、アプリケーションのパフォーマンスおよび実行計画を再検査し、SQLトレース機能を利用します。
関連項目:
-
外部キーについて学習するには、Oracle Database開発者ガイドを参照してください
-
ALTER INDEX MONITORING USAGE
文の構文およびセマンティクスの詳細は、Oracle Database SQL言語リファレンスを参照してください
A.1.2 SQLアクセス・アドバイザの使用方法に関するガイドライン
SQLアクセス・アドバイザは、どの索引が必要であるかを手動で判別する作業に対する代替機能です。
SQLアクセス・アドバイザをOracle Enterprise Manager Cloud Control (Cloud Control)から起動するか、DBMS_ADVISOR
パッケージAPIで実行すると、索引のセットが推奨されます。SQLアクセス・アドバイザはワークロードの使用を推奨するか、または指定のスキーマに関する仮定的なワークロードを生成します。
ワークロードのソースには、SQLキャッシュの現在の内容、ユーザー定義のSQL文のセットまたはSQLチューニング・セットなどを使用できます。ワークロードを指定すると、SQLアクセス・アドバイザにより推奨事項のセットが生成され、実装する索引を選択できます。SQLアクセス・アドバイザは、手動で実行またはCloud Controlを介して自動的に実行できる実装のためのスクリプトを提供します。
関連項目:
A.1.3 索引を付ける列と式の選択に関するガイドライン
キーは、索引を付ける列または式です。
次のガイドラインに従って、索引を付けるキーを選択します。
-
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概要を参照してください
A.1.4 コンポジット索引の選択に関するガイドライン
コンポジット索引(連結索引とも呼ばれる)は、表の中の複数の列に対して作成される索引です。
コンポジット索引には、次のような単一列索引を上回る利点があります。
-
選択性の向上
選択性の低い複数の列または式を組み合せることで、選択性の高いコンポジット索引を作成できる場合があります。
-
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
の各列の組合せは、索引の先頭部分ではありません。
この項では、次の項目について説明します。
関連項目:
A.1.4.1 コンポジット索引のキーの選択に関するガイドライン
コンポジット索引の効果は、正しい列をキーとして選択するかどうかに依存します。
コンポジット索引を構成するキーを選択するために、次のガイドラインに従ってください。
-
AND
演算子で結合してWHERE
句の条件で頻繁に使用されるキー、特に、各キーの個別の選択性と比較して、キーを組み合せることで選択性が高くなる場合、コンポジット索引の作成を検討します。 -
複数の問合せが1つ以上のキー値に基づいて同じキー・セットを選択する場合、これらのキーのすべてを含むコンポジット索引を作成することを検討します。
これまでの項で説明した、索引による一般的なパフォーマンス上のメリットとトレードオフに関連するガイドラインを検討してください。
A.1.4.2 コンポジット索引のキーの順序付けに関するガイドライン
コンポジット索引では、キーの順序が問合せのパフォーマンスに影響する場合があります。
コンポジット索引内でのキーの順序を指定するために次のガイドラインに従ってください。
-
WHERE
句で使用されるキーが先頭部分を構成するように、索引を作成してください。 -
一部のキーが
WHERE
句で頻繁に使用される場合は、これらのキーのみを使用する文が索引を使用できるように、頻繁に選択されるキーが先頭部分を構成するように索引を作成します。 -
すべてのキーが
WHERE
句で均等に使用され、そのキーの1つでデータが物理的に順序付けられている場合には、そのキーをコンポジット索引の先頭にしてください。
A.1.5 索引を使用するSQL文の記述に関するガイドライン
オプティマイザは、索引を使用するアクセス・パスを選択しない場合があります。
オプティマイザは、アクセス・パスを使用可能にする構成が含まれている場合にかぎり、アクセス・パスを選択します。問合せオプティマイザが索引アクセス・パスを使用できるようにするには、そのようなアクセス・パスを使用可能にする構成が文に含まれていることを確認してください。
A.1.6 索引を使用しないSQL文の記述に関するガイドライン
場合によって、SQL文が索引アクセス・パスを使用しないようにできます。たとえば、索引の選択性が高くなく、全表スキャンのほうが効率的であるとわかっています。
そのような索引アクセス・パスを使用可能にする条件が文に含まれている場合は、次に示す方法の1つを使用して、オプティマイザに全表スキャンを使用するように強制できます。
-
NO_INDEX
ヒントを使用して特定索引の使用を禁止にし、問合せオプティマイザに最大限の柔軟性を持たせることができます。 -
FULL
ヒントを使用し、オプティマイザに対して索引スキャンのかわりに全表スキャンを選択するように指示します。 -
INDEX
ヒントまたはINDEX_COMBINE
ヒントを使用し、オプティマイザに、ある索引(またはリストされている索引セット)を別の索引(または索引セット)のかわりに使用するように指示します。
パラレル実行は、索引を効果的に利用します。このオプションは、パラレル索引レンジ・スキャンを実行しませんが、ネステッド・ループ・ジョインをパラレル実行するためにパラレル索引参照を実行します。索引の選択性が高い(各索引エントリの行数が少ない)場合は、パラレル表スキャンよりも順次索引参照をお薦めします。
関連項目:
NO_INDEX
、FULL
、INDEX
、INDEX_COMBINE
およびヒントの詳細は、「オプティマイザへの影響」を参照してください
A.1.7 順序生成キーで索引のシリアライズを回避するガイドライン
順序生成された主キーの挿入によって、以前からある索引競合の問題が発生します。
アプリケーションでは、頻繁に順序を使用して主キーを生成します。主キーで索引への挿入を行うと、すべて同じ索引ブロックにアクセスする必要があるため、競合する可能性があります。この索引ブロックはすべてのインスタンスがアクセスする必要があり、そのためにはキャッシュ・フュージョンを使用するブロック転送が必要になるため、この競合がOracle RACでは深刻です。
Oracle Database 18c以降では、SCALE
属性を使用して順序を作成できます。この機能により、Oracle RACノード間で索引ブロックを競合をなくすことができます。SCALE
を指定する場合、データベースによって、順序に数値オフセットの接頭辞が付けられます。オフセットはiii||sss||という形式で、変数には次のように指定します。
-
iiiには、(instance_id % 100) + 100で計算される3桁のインスタンス・オフセットを指定します
-
sssには、(session%1000)によって計算される3桁のセッション・オフセットを指定します
-
||は連結演算子です
この方法を使用すると、異なるOracle RACインスタンスのセッションが、同じ索引ブロックで隣接するスロットを占有するようなキーを生成しません。
例A-1 スケーラブルな順序の作成
この例では、スケーラブルな順序キーを作成します。これは、deptable
の主キーを移入するために使用します。
DROP TABLE deptable;
DROP SEQUENCE my_seq;
DROP TRIGGER my_trig;
CREATE TABLE deptable (ID NUMBER(10) NOT NULL, DESCR VARCHAR2(10));
ALTER TABLE deptable ADD (CONSTRAINT deptable_pk PRIMARY KEY (ID));
CREATE SEQUENCE my_seq START WITH 1 MAXVALUE 100 SCALE EXTEND;
CREATE OR REPLACE TRIGGER my_trig
BEFORE INSERT ON deptable
FOR EACH ROW
BEGIN
SELECT my_seq.NEXTVAL
INTO :new.id
FROM DUAL;
END;
/
INSERT INTO deptable(descr) VALUES (1,'id value');
COMMIT;
表の問合せでは、インスタンス1のセッション43が行を挿入したことを示しています。
SQL> SELECT * FROM deptable;
ID DESCR
---------- ----------
101043001 id value
インスタンス4のセッション25からの挿入では、次の値が生成されます。
SQL> SELECT * FROM deptable;
ID DESCR
---------- ----------
104025002 id value
関連項目:
CREATE SEQUENCE
のセマンティクスおよび構文については、『Oracle Database SQL言語リファレンス』を参照してください
A.1.8 索引の再作成に関するガイドライン
索引を縮小し分断化された領域を最小化するため、または索引の記憶特性を変更するために索引を再作成する場合があります。
既存の索引のサブセットとなる新しい索引を作成する場合、または新しい記憶特性を使用して既存の索引を再構築する場合、Oracle Databaseでは、実表ではなく既存の索引を使用することで索引作成のパフォーマンスが向上する場合があります。ただし、既存の索引ではなく、実表を使用することが有効な場合もあります。多くのDMLが実行された表の索引を考えてみてください。DMLのために索引のサイズが大きくなり、各ブロックが50%以下しか満たされなくなる場合があります。索引が表のほとんどの列を参照している場合、索引が表よりも大きくなりかねません。その場合は、索引よりも実表を使用した方が、索引の再作成が速くできます。
既存の索引を再編成または縮小するため、または既存の索引の記憶特性を変更するには、ALTER INDEX . . . REBUILD
文を使用します。REBUILD
文は、新しい索引の基礎として既存の索引を使用します。STORAGE
(エクステントの割当て用)、TABLESPACE
(索引を新しい表領域に移動する)およびINITRANS
(エントリの最初の数を変更する)などのすべての索引記憶用の文がサポートされています。
ALTER INDEX . . . REBUILD
は、高速全体スキャン機能を使用するので、通常は索引を削除して再作成するよりも高速です。この文は、マルチブロックI/Oを使用して索引ブロックをすべて読み取ってから、ブランチ・ブロックを廃棄します。さらに、このアプローチには、再作成の実行中の問合せには、旧索引を利用できるという利点があります。
関連項目:
CREATE INDEX
文とALTER INDEX
文、および索引の再作成に関する制限の詳細は、Oracle Database SQL言語リファレンスを参照してください
A.1.9 索引の縮小に関するガイドライン
COALESCE
オプションを持つALTER INDEX
文を使用して索引のリーフ・ブロックを結合できます。
このオプションでは、索引のリーフ・レベルを結合して空きブロックにし、再利用できます。また、索引をオンラインで再作成することもできます。
関連項目:
この文の構文の詳細は、『Oracle Database SQL言語リファレンス』および『Oracle Database管理者ガイド』を参照してください
A.1.10 一意でない索引による一意性の規定の使用方法に関するガイドライン
UNIQUE制約、またはPRIMARY
KEY制約の一意性の側面に関して、一意性を規定するために、
表の既存の一意でない索引を使用できます。
このアプローチの利点は、制約が使用禁止にされているときでも索引が使用可能であり、妥当であるということです。したがって、使用禁止にされているUNIQUE
制約またはPRIMARY KEY
制約を使用可能にするために、その制約に対応付けられている一意索引を再作成する必要はありません。この手法により、大規模表で操作を使用可能にする際に時間を大幅に節約できます。
さらに、一意でない索引を使用して一意性を規定すると、索引の重複を排除できます。主キー列がコンポジット索引の接頭辞として組み込まれている場合、その列に対する一意索引は不要です。制約を使用可能または規定するときに、既存の索引を使用できます。また、索引を複製しないので、領域を大幅に節約できます。ただし、既存の索引がパーティション化されている場合は、索引のパーティション・キーもUNIQUE
キーのサブセットである必要があります。サブセットでない場合、Oracle Databaseでは、一意索引が追加作成され、制約を規定します。
A.1.11 ENABLE NOVALIDATE制約の使用方法に関するガイドライン
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概要を参照してください
A.2 パフォーマンスを考慮したファンクション索引の使用方法に関するガイドライン
ファンクション索引には、ファンクション(たとえば、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言語リファレンスを参照してください
A.3 パフォーマンスを考慮したパーティション索引の使用方法に関するガイドライン
パーティション表と同様に、パーティション索引を使用すると、管理性、可用性、パフォーマンスおよびスケーラビリティが向上します。パーティション索引は、個別にパーティション化するか(グローバル索引)、または表のパーティション・メソッドに自動的にリンクできます(ローカル索引)。
Oracle Databaseでは、レンジ・パーティション化およびハッシュ・パーティション化されたグローバル索引をサポートします。レンジ・パーティション化されたグローバル索引では、各索引パーティションに、パーティション・バウンドで定義された値が含まれます。ハッシュ・パーティション化されたグローバル索引では、各パーティションに、Oracle Databaseハッシュ関数により決定された値が含まれます。
マルチユーザーのOLTP環境で、索引内の少数のリーフ・ブロックに競合が多い場合、ハッシュ・メソッドにより索引のパフォーマンスが向上します。OLTPアプリケーションによっては、索引の右端にのみ索引が挿入される場合があります。この状況は、単調に増える列に対して索引を定義した場合に起こります。この状況では、索引ページ、バッファ、更新のラッチおよび追加索引メンテナンス・アクティビティの競合により、索引の右端がホット・スポットとなり、パフォーマンスが低下します。
ハッシュ・パーティション化されたグローバル索引では、索引エントリはパーティション・キーおよびパーティション数に基づいて異なるパーティションにハッシュされます。これにより、定義済のパーティション数全体に競合が拡散され、スループットが向上します。ハッシュ・パーティション化されたグローバル索引を使用すると、バッファ・ラッチの競合が複数のパーティションにわたって拡散されるため、大規模PDMLとして大きなファクト表に実行されるTPC-Hリフレッシュ関数には有効です。
ハッシュ・パーティション化では、索引エントリはOracle Databaseで生成されたハッシュ値に基づいて特定の索引パーティションにマップされます。ハッシュ・パーティション化されたグローバル索引を作成するための構文は、ハッシュ・パーティション表と非常によく似ています。索引パーティション・キーについての等価述語およびIN
述語を伴う問合せでは、グローバル・ハッシュ・パーティション索引を効率的に使用して問合せにすばやく回答できます。
関連項目:
グローバル索引表の詳細は、Oracle Database概要およびOracle Database管理者ガイドを参照してください
A.4 パフォーマンスを考慮した索引構成表の使用方法に関するガイドライン
索引構成表は、表のデータが関連付けられている索引に保存されるため、通常の表とは異なります。
新しい行の追加、行の更新、行の削除など、表データを変更すると、索引のみが更新されます。データ行は索引に格納されるため、索引構成表では完全一致、範囲検索またはその両方を含む問合せの表データに対するさらに高速なキー・ベースのアクセスが可能になります。
親/子関係は、索引構成表を保証する状況の一例です。たとえば、メンバー
表に電話番号を含む子表があるとします。メンバーの電話番号は、時間の経過とともに変更および追加されます。ヒープ構成表では、行は適合するデータ・ブロックに挿入されます。ただし、メンバー
表を問い合せる場合、電話番号は常に子表から取得されます。取得の効率性を高めるために、指定のメンバーの電話レコードが互いにデータ・ブロック内の近くに挿入されるように、索引構成表に電話番号を格納できます。
特定の状況では、索引構成表の方がヒープ構成表よりもパフォーマンスの面で利点があります。たとえば、問合せに必要なキャッシュ内のブロック数が比較的少ない場合、データベースではバッファ・キャッシュがより効率的に使用されます。問合せに必要な個別のブロック数が比較的少ない場合は、1回の物理I/Oによって必要なデータがすべて取得されるため、各問合せに必要なI/Oの量はわずかで済みます。
グローバル・ハッシュ・パーティション索引は索引構成表でサポートされており、マルチユーザーのOLTP環境でパフォーマンスが向上します。索引構成表は、関連するデータをまとめて格納する場合、またはデータを特定の順序で物理的に格納する場合に役立ちます。
関連項目:
-
索引構成表の概要は、Oracle Database概要を参照してください
-
索引構成表の管理方法を学習するには、『Oracle Database管理者ガイド』を参照してください。
A.5 パフォーマンスを考慮したビットマップ索引の使用方法に関するガイドライン
ビットマップ索引を使用すると、特定の問合せのパフォーマンスを大幅に向上させることができます。
一般に、問合せが次のすべての特性を備えている場合に最適なパフォーマンスが得られます。
-
カーディナリティが低いか中位である列に関する述語が
WHERE
句に複数含まれています。 -
カーディナリティが低いか中位である列に関する個々の述語が多数の行を選択しています。
-
カーディナリティが低いか中位である列の一部または全部に対して、問合せで使用されるビットマップ索引が作成されています。
-
問合せの表に多数の行が含まれています。
複数のビットマップ索引を使用して、単独の表に対する条件を評価できます。このため、ビットマップ索引は、長いWHERE
句を含む複合非定型問合せにとって非常に有効です。ビットマップ索引は、集合問合せでもスター・スキーマでの結合の最適化でも最適なパフォーマンスを提供します。
関連項目:
-
ビットマップ索引の概要は、『Oracle Database概要』を参照してください。
-
アプリケーションでビットマップ索引を使用する方法を学習するには、Oracle Databaseデータ・ウェアハウス・ガイドを参照してください
A.6 パフォーマンスを考慮したビットマップ結合索引の使用方法に関するガイドライン
単一表のビットマップ索引の他に、ビットマップ結合索引を作成できます。これは、複数の表の結合に対するビットマップ索引です。
ビットマップ結合索引では、事前に制限事項を実行することで、結合する必要のあるデータ量を削減して領域を節約できます。ビットマップ結合索引は、表の列の値ごとに、別の表の対応する行のROWIDを格納します。データ・ウェアハウスでは、結合条件はディメンション表の主キー列とファクト表の外部キー列の間の内部等価結合です。
ビットマップ結合索引は、記憶域に関して、事前に結合をマテリアライズするマテリアライズド結合ビューよりも効率的です。マテリアライズド結合ビューは、ファクト表のROWIDを圧縮しません。
関連項目:
ビットマップ結合索引の例および制限は、Oracle Databaseデータ・ウェアハウス・ガイドを参照してください
A.7 パフォーマンスを考慮したドメイン索引の使用方法に関するガイドライン
ドメイン索引は、ユーザー定義の索引タイプで指定された索引作成論理で作成されます。索引タイプは、ドメインの(アプリケーション固有の)索引を管理するルーチンを指定するオブジェクトです。
索引タイプを使用すると、特定の演算子の述部に合うデータに効率よくアクセスできます。通常、ユーザー定義の索引タイプは、Oracle Spatial and Graphオプションのように、Oracle Databaseオプションの一部です。
ドメイン索引の作成と保守で指定できるパラメータは、カートリッジによって異なります。同様に、ドメイン索引のパフォーマンスと記憶域の特性は、カートリッジ固有のマニュアルを参照してください。
次の情報は、適切なカートリッジ・マニュアルを参照してください。
-
索引付けの可能なデータ型
-
使用できる索引タイプ
-
索引タイプで使用できる演算子
-
ドメイン索引を作成およびメンテナンスする方法
-
問合せで演算子を最も効率よく使用する方法
-
パフォーマンス特性の内容
ノート:
索引タイプは
CREATE INDEXTYPE
文でも作成できます。
関連項目:
spatialデータの索引付けについてさらに学習するには、Oracle Spatial and Graph開発者ガイドを参照してください
A.8 表クラスタの使用に関するガイドライン
表クラスタは、共通の列を共有し、通常はSQL文で同時に使用されるため、物理的にまとめて格納される1つ以上の表のグループです。
CREATE CLUSTER
文を使用します。
次の場合は、表のクラスタ化を検討します。
-
結合処理で、アプリケーションが表に頻繁にアクセスする場合。
-
マスター/ディテール表において、アプリケーションがマスター・レコードを選択してから対応するディテール・レコードを選択することがよくある場合。
ディテール・レコードはマスター・レコードと同じデータ・ブロックに格納されるため、選択する際にそれらがメモリー内に存在している可能性があります。これにより、Oracle Databaseでは、必要なI/O処理が減少します。
-
アプリケーションが、同じマスターについて多数のディテール・レコードを選択することがよくある場合。
この場合、ディテール表のみをクラスタに格納します。このようにすれば、同じマスターについて多くの詳細レコードを選択する問合せのパフォーマンスが改善され、マスター表に対する全表スキャンのパフォーマンスも低下させずに済みます。別の方法として、索引構成表を使用する方法があります。
次の場合は、表をクラスタ化しません。
-
アプリケーションが表の結合を頻繁には行わない場合、または共通の列の値を頻繁に変更する場合。
Oracle Databaseでは、行のクラスタ・キー値を変更すると、クラスタを維持するために変更された行を別のブロックに移行することが必要になる場合があるため、非クラスタ化表の値を変更する場合よりも時間がかかります。
-
アプリケーションが複数の表の1つについてのみ頻繁に全表スキャンを行う場合。
クラスタ化表の全表スキャンに要する処理時間は、非クラスタ化表の全表スキャンよりも長くなる可能性があります。表がまとめて格納されているため、より多くのブロックの読取りが必要になる可能性があります。
-
同じクラスタ・キー値を持つすべての表のデータのブロック数が、1つや2つではない場合。
Oracle Databaseでは、クラスタ化表の行にアクセスする際に、その値を持つ行を含むすべてのブロックを読み取ります。これらの行が複数のブロックを使用している場合、単一行にアクセスすることによって、非クラスタ化表で同じ行にアクセスする場合よりも多くの読取り処理が必要になる場合があります。
-
各クラスタ・キー値の行数が大きく異なっている場合。
カーディナリティの低いキー値の場合には領域が無駄になります。カーディナリティの高いキー値の場合には衝突が発生します。衝突が発生するとパフォーマンスが下がります。
アプリケーションでのクラスタの長所と短所を検討してください。たとえば、結合文のパフォーマンス向上が、クラスタ・キー値を修正する文のパフォーマンス低下を上回る場合もあります。表をクラスタ化した場合と別々に格納した場合について実験して、処理時間を比較してください。
関連項目:
-
表クラスタの詳細は、Oracle Database概要を参照してください
-
表クラスタの作成の詳細は、Oracle Database管理者ガイドを参照してください
A.9 パフォーマンスを考慮したハッシュ・クラスタの使用方法に関するガイドライン
ハッシュ・クラスタは、ハッシュ関数をそれぞれの行のクラスタ・キー値に適用することによって、表データをグループ分けします。
同じクラスタ・キー値を持つすべての行が、ディスク上にまとめて格納されます。アプリケーションでのハッシュ・クラスタの長所と短所を検討してください。特定の表について、ハッシュ・クラスタの場合と、索引付きで単独の場合とで実験を行って処理時間を比較してください。
ハッシュ・クラスタを使用する場合を判断するために、次のガイドラインに従ってください。
-
同じ列または列の組合せを使用する等価条件が
WHERE
句に含まれる場合、WHERE
句を持つSQL文により頻繁にアクセスされる表を格納するために、ハッシュ・クラスタが使用されます。この列または列の組合せをクラスタ・キーとして指定します。 -
即時および将来において挿入する行を含め、特定のクラスタ・キー値を持つすべての行を保持するのに必要な領域を判断できる場合は、ハッシュ・クラスタに表を格納します。
-
ハッシュ関数の各値に対応する行が特定の列において昇順でソートされる場合、ソートされたクラスタ・データで操作のレスポンス時間が改善される場合は、ソートされたハッシュ・クラスタを使用します。
-
次の場合には、ハッシュ・クラスタに表を格納しません。
-
アプリケーションが頻繁に全表スキャンを実行する場合。
-
表が拡大することを見越してハッシュ・クラスタに大きな領域を割り当てる必要がある場合。
全表スキャンでは、いくつかのブロックにはほとんど行が含まれていなくても、ハッシュ・クラスタに割り当てられているブロックをすべて読み取る必要があります。表を単独で格納することによって、全表スキャンにより読み取られるブロック数が減少します。
-
-
アプリケーションがクラスタ・キー値を頻繁に修正する場合、ハッシュ・クラスタに表は格納しません。Oracle Databaseでは、行のクラスタ・キー値を変更すると、クラスタを維持するために変更された行を別のブロックに移行することが必要になる場合があるため、非クラスタ化表の値を変更する場合よりも時間がかかる可能性があります。
このリストの検討事項に基づいた表のハッシングが適切な場合、単一の表をハッシュ・クラスタに格納することは有益です。表が他の表と頻繁に結合されるかどうかにかかわらず同じことが言えます。
関連項目:
-
ハッシュ・クラスタの管理方法を学習するには、Oracle Database管理者ガイドを参照してください
-
CREATE CLUSTER
文について学習するには、Oracle Database SQL言語リファレンスを参照してください