このページは、Oracle TimesTen In-Memory Databaseを使用して最適なパフォーマンスを実現するためのスキーマの使用方法について、上位3つの推奨事項を示します。

- 適切な索引を作成する - 統計を更新する - 問合せ計画を確認し、計画に従って処理する

適切な索引を作成する

TimesTen In-Memory Databaseには、コスト・ベースのオプティマイザがあります。オプティマイザは、問合せを実行するために最適な計画を選択します。最適なデータベース・パフォーマンスを得るために作成する索引の数を判断するのは容易ではありませんが、通常、問合せ計画を適切に検討することで容易になります。

TimesTenデータベースは、ハッシュ索引と範囲索引の2種類の索引をサポートします。ハッシュ索引は完全一致検索に、範囲索引は範囲検索に使用されます。完全一致検索では、適切にチューニングされたハッシュ索引の方が、対応する範囲索引よりも検索が高速です。ハッシュ索引を範囲問合せに使用することはできません。範囲索引は、完全一致検索と範囲検索の両方、およびソート（ORDER BY、GROUP BYまたはDISTINCTを含むSQL問合せなど）に使用できます。

主キーで独自のハッシュ索引を指定しなかった場合は、自動的に範囲索引が作成されます。一意のハッシュ索引を指定する場合は、適切なサイズで索引を設定してください。CREATE TABLE文のPAGES=オプションを使用して、表の予想サイズを指定します。指定するページ数は、表の予想行数を256で割った値です。例:

CREATE TABLE EMP (
ID \x{00a0}\x{00a0}\x{00a0} NUMBER NOT NULL PRIMARY KEY,
NAME\x{00a0}\x{00a0} VARCHAR2(100)
) UNIQUE HASH ON (ID) PAGES=500;

どちらか一方の索引を使用できる場合、等価条件については、範囲索引よりもハッシュ索引の方がパフォーマンスが優れています。ただし、ハッシュ索引は、範囲索引よりも多くの領域を必要とします。索引に指定するページ数が多すぎると、領域の浪費になります。指定するページ数が少なすぎると、ハッシュ・バケットのオーバーフローが原因でパフォーマンスが損なわれます。ハッシュ索引のサイズ設定が適切でない場合、範囲索引より速度が非常に低下します。また、表の内容が大幅に増加した場合は、ALTER TABLE文を使用してハッシュ索引のサイズを変更する必要があります。

統計を更新する

TimesTen問合せオプティマイザは、通常、適切な問合せ計画を選択します。ただし、オプティマイザが適切な計画を選択するには、複雑な問合せに関係する表に関する追加の情報が必要です。

表統計は、オプティマイザが適切な計画を選択する際に必要不可欠です。表の行数および列値のデータ分布がわかっていると、オプティマイザが、その表にアクセスするための効率的な問合せ計画を選択する可能性が高くなります。

一般的に、表にアクセスする問合せを準備する前に、データベースのすべての表で統計を更新することをお薦めします。
データが移入される前に表の統計を更新すると、表に行がないか、行数が非常に少ないという前提で問合せが最適化されます。その後でその表に数百万の行を移入して問合せを実行した場合、行がほとんどない表で適切に処理されていた計画は、現在の表のデータ・セット用に最適化されていないため、速度が非常に遅くなります。

最適なパフォーマンスを得るには、表の統計を更新して、現在の表の移入状態を反映する必要があります。表に対して多数の行の追加または削除を行った後は、特にその必要があります。表統計の更新の完了後に、問合せを準備します。

統計の更新の詳細は、リファレンス・ガイドの組込みプロシージャに関する項で、組込みプロシージャttOptUpdateStatsおよびttOptEstimateStatsについての説明を参照してください。

問合せ計画を確認し、計画に従って処理する

特定の問合せの実行速度が予想よりも遅い場合、TimesTenオプティマイザが、その問合せに応答するための最適な問合せ計画を選択していない可能性があります。問合せ計画を生成して確認する必要があります。問合せ計画の生成と計画の表示方法の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』を参照してください。

ttIsqlコマンドライン・ユーティリティからオプティマイザ計画を表示するには、次のコマンドを使用します。

autocommit 0;
showplan 1;

問合せ計画を確認する際は、問合せ評価に関係しながらも索引付けされていない条件に注意してください。可能な場合には、索引付けされていない条件に作成を作成することで問合せパフォーマンスが向上します。次に、サンプルの問合せを検討します。

次の例に、メイン表（SHIPMENT）の規模が比較的大きいテスト問合せの中から、手順の1つを抜粋しました。1千万を超える行が含まれます。最初の問合せの実行で、完了まで約800秒かかりました。これは処理速度が遅すぎるうえに、予測とは異なっています。次に、問合せ計画を生成し、手順の1つで次の計画が使用されているのを確認しました。

STEP:\x{00a0}\x{00a0}\x{00a0} 10
LEVEL:\x{00a0}\x{00a0} \x{00a0}8
OPERATION: \x{00a0}TblLkTtreeScan
TBLNAME:\x{00a0} \x{00a0}SHIPMENT
IXNAME:\x{00a0}\x{00a0} SHIPMENT_IDX1
INDEXED:\x{00a0}  <NULL>
NOT INDEXED: \x{00a0}TBL1.OB_FLG <> 'Y'
AND TBL1.SHIPMENT_ID = CLIENT.SHIPMENT_ID
AND TBL1.SHIPMENT_QUAL = CLIENT.SHIPMENT_QUAL
AND TBL1.CARRIER = CLIENT.CARRIER
AND TBL1.ROLE = 'Y'

NOT INDEXED行に複数の条件がリストされているうえ、INDEXED行には条件がリストされていませんでした。SHIPMENT_ID、SHIPMENT_QUALおよびCARRIER列に索引がないため、オプティマイザは、各条件を評価するために表全体をスキャンする必要がありました。これら3つの列に索引を作成することで問題を修正すると、次に示すように手順10の計画が大きく改善されました。

STEP:\x{00a0}\x{00a0}\x{00a0} 10
LEVEL:\x{00a0}\x{00a0} \x{00a0}8
OPERATION: \x{00a0}RowLkTtreeScan
TBLNAME:\x{00a0} \x{00a0}SHIPMENT
IXNAME:\x{00a0}\x{00a0} SHIPMENT_IDX0
INDEXED:\x{00a0}  TBL1.SHIPMENT_ID = CLIENT.SHIPMENT_ID
AND TBL1.SHIPMENT_QUAL = CLIENT.SHIPMENT_QUAL
AND TBL1.CARRIER = CLIENT.CARRIER
NOT-INDEXED: \x{00a0}TBL1.OB_FLG <> 'Y' AND TBL1.ROLE = 'Y'

非常に良い計画になりました。オプティマイザは、適切な索引を使用して行ロックを選択し、条件を評価します。これによって問合せ時間が400倍短縮されました。変更後の問合せは2秒で実行されます（変更前は800秒）。

すべてのパフォーマンス・チューニングと同様に、効果は変動します。ここで重要なのは、問合せ計画を確認して、問合せのパフォーマンス向上に必要な変更を行う時間を設けることです。