| Oracle TimesTen In-Memory Databaseオペレーション・ガイド
リリース7.0 E05167-03 |
|
 前へ |
 次へ |
全体のロギング、ロック、I/Oの方針の決定後、個々のSQL文をできるだけ効率的に実行できるようにしてください。
すべての文が効率的に実行されているかどうかをチェックします。たとえば、使用する問合せは、必要な結果セットを生成するために必要な行のみを参照するようにします。表t1のcol1のみが必要であれば、次の文を使用します。
SELECT col1 FROM t1...
または、次の文を使用します。
SELECT * FROM t1...
「TimesTen問合わせオプティマイザ」では、TimesTenで文を実行するために使用される計画の表示方法について説明します。また、ttIsql showplanコマンドを使用して、計画を表示できます。アプリケーションで頻繁に実行される各文の計画を表示します。索引が条件を評価するために使用されていない場合は、索引を使用できるように、新しい索引の作成または文や問合せの再作成を検討してください。たとえば、比較条件（一致および不一致）の一方、またはBETWEEN条件に単一の列が表示される場合に、索引をWHERE句を評価するためにのみ使用できます。
この比較条件が頻繁に評価される場合は、再作成するのが妥当です。
WHERE c1+10 < c2+20
WHERE c1 < c2+10
c1に索引を作成します。
索引が存在することにより、UPDATE、INSERT、DELETE、CREATE VIEWなどの書込み操作の処理速度が遅くなります。アプリケーションでの読取りが少ないものの、表への書込みが多い場合は、その表の索引によってパフォーマンスが向上するのではなく、低下する可能性があります。
FIRSTキーワードは、SQL文の特定の数の行、SELECT、UPDATEおよびDELETEでの操作で使用できます。この属性は、スループットおよびレスポンス時間を改善できます。また、アプリケーションで、問合せに対して最大1行をフェッチすることを計画し、一意の索引が行のフェッチに使用されていない場合、アプリケーションでSQL_MAX_ROW_COUNTを1に設定する必要があります。詳細は、『Oracle TimesTen In-Memory Database APIリファレンス・ガイド』を参照してください。
場合によっては、問合せ評価の処理速度を向上するために、システムによって一時索引が作成される場合があります。このような場合が頻繁にある場合は、アプリケーション自体で索引を作成する方が効率的です。MONITOR表のCMD_TEMP_INDEXES列は、問合せ評価時に一時索引が作成された回数を示します。
表またはキャッシュ・グループに対して時間ベースのエージングを実装している場合は、タイムスタンプ列に索引を作成すると、エージングのパフォーマンスが向上します。詳細は、「時間ベースのエージング」を参照してください。
TimesTen Data Managerでは、ハッシュ索引およびTツリー索引の両方がサポートされています。ハッシュ索引は、主キーを宣言する表のために作成します。Tツリー索引は、CREATE INDEX文で作成します。
索引構造には、それぞれの長所があります。主キーのすべての列に対する完全一致キー検索の場合、ハッシュ索引はTツリー索引より処理が高速です。ただし、ハッシュ索引には次の制限があります。
Tツリー索引でも完全一致キー検索を高速化できます。Tツリー索引は柔軟性が高く、他の問合せの高速化にも利用できます。問合せにLESS THANまたはGREATER THANの比較がある場合は、Tツリー索引を選択します。また、Tツリー索引は、接頭辞問合せの高速化にも利用できます。接頭辞問合せでは、指定されている最後のキー列以外のすべての列に一致条件を指定できます。接頭辞問合せの最後の列には、一致条件または不一致条件を指定できます。
次の表および索引の定義について考えてみます。
CREATE TABLE T(i1 integer, i2 integer, i3 integer, ...);
CREATE INDEX IXT on T(i1, i2, i3);
索引IXTを使用すると、次の問合せを高速化できます。
SELECT * FROM T WHERE i1>12;
SELECT * FROM T WHERE i1=12 and i2=75;
SELECT * FROM T WHERE i1=12 and i2 BETWEEN 10 and 20;
SELECT * FROM T WHERE i1=12 and i2=75 and i3>30;
SELECT * FROM T WHERE i2=12;
接頭辞プロパティが満たされていないためです。i1に一致条件が指定されていません。
SELECT * FROM T WHERE i1=12 and i2<50 and i3=630;
Tツリー索引の構造は、表サイズの変更に対応して自動的に調整される動的構造です。Tツリー索引は、一意にすることも一意にしないこともできます。NULL値可能列に対して宣言することもできます。また、レコードの挿入後、索引付けされた列の値を変更することもできます。Tツリー索引は、ほとんどの場合、同等のハッシュ索引より単純です。
TimesTenでは、ハッシュ索引を使用して主キー制約を適用しています。ハッシュ索引で使用されるバケットの数は、CREATE TABLE文のUNIQUE HASH ON句で指定するPAGESパラメータで決まります。PAGESの値は、表の予想行数を256で割った値にする必要があります。小さい値を指定すると、競合の数が増加してパフォーマンスが低下します。一方、大きい値を指定すると、パフォーマンスが多少向上する場合がありますが、索引で使用する追加の領域が必要になります。
索引付けする値の数が大きく変動する場合は、大きい索引を作成することをお薦めします。表のサイズを正確に予測できない場合は、CREATE INDEXでTツリー索引を使用することを検討してください。また、索引付けする列が大きいCHAR値またはバイナリ値の場合、あるいは索引付けする列が多い場合は、一意索引の使用を検討してください。これらの場合は、一意索引の方がハッシュ索引より高速になる場合があります。
表のサイズが大きくなるにつれてレコード挿入のパフォーマンスが低下する場合は、表の予想サイズを小さく見積りすぎていた可能性があります。ALTER TABLE文を使用してUNIQUE HASH ON句のPAGES値を再設定することによって、ハッシュ索引のサイズを変更できます。
外部キーを宣言しても、SELECT問合せのパフォーマンスには影響ありません。ただし、外部キーが定義された表でINSERTおよびUPDATEを実行する場合、および外部キーで参照される表でUPDATEおよびDELETEを実行する場合は、パフォーマンスが低下します。この低下は、表を参照する外部キーの数または表に定義されている外部キーの数に比例します。
データ・ストア内のデータに関する統計が利用できる場合、TimesTenオプティマイザは、コマンドを準備する際に、それらの統計を使用してデータへの最適なパスを決定します。統計がない場合、TimesTenオプティマイザは、データ配布に関して一般的な予測を行います。パフォーマンス上の理由から、TimesTenでは、統計が計算される際に表または行のロックは保持されません。
文に対して生成された計画を確認し（「TimesTen問合せオプティマイザ」を参照）、それが最適ではないと考えられる場合は、文を準備する前に統計を計算し、計画を再度確認することを検討してください。
計画を確認していない場合は、統計を計算することをお薦めします。この情報によって効率的な計画を生成できる可能性が高くなります。
統計の計算用にはttOptUpdateStatsおよびttOptEstimateStatsの2つの組込みプロシージャがあります。ttOptUpdateStatsは、対象となる表の各行を参照し、厳密な統計を計算します。ttOptEstimateStatsは、対象となる表の一部の行を参照し、見積り統計を計算します。統計の見積りはかなり高速に実行できますが、計算結果は正確性に劣る場合があります。処理時間が問題にならない場合は、通常、ttOptUpdateStatsを使用することをお薦めします。ただし、アプリケーション全体のパフォーマンスに影響を及ぼす場合は、見積りの方が有効です。一般的に、10パーセントのサンプルで統計を計算すると、正確な統計を計算するより処理が約10倍速くなり、通常は同じ実行計画が生成されます。統計の計算には時間がかかるため、データ・ストアをロードした後で（コマンドを準備する前に）1回計算し、それ以降はデータの編成を大きく変更した場合にのみ計算することをお薦めします。
アプリケーションでALTER TABLE文を使用すると、表に対して列の追加および破棄を実行することができます。ALTER TABLE文自体は、ほとんどの場合、非常に高速に実行できますが、表に行った変更が原因で発生する後続の処理に時間がかかることがあります。アプリケーションで発生する実際のパフォーマンスの低下の程度は、表の変更回数および表に対して実行される処理の種類によって異なります。
VARCHAR列およびVARBINARY列の破棄は、他のデータ型の列の破棄より時間がかかります。これは、破棄対象の列内の既存のVARCHAR値およびVARBINARY値に割り当てられている領域を解放するために、表をスキャンする必要があるためです。
TimesTenでは、いくつかの制限付きで問合せのネストがサポートされています。ただし、パフォーマンスは一定ではなく、通常は最適化されていません。副問合せの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。
