ヘッダーをスキップ
Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド
リリース7.0
E05173-02
  目次へ
目次
索引へ
索引

前へ
前へ
次へ
次へ
 

アプリケーションが遅い

アプリケーションとTimesTenデータ・ストアのパフォーマンスを最大にする方法については、次を参照してください。

この項では、パフォーマンスを低下させるいくつかの問題について説明します。

考えられる原因
対処
クライアント/サーバー・モードを使用している
データベース統計が古い
トランザクションのコミットの頻度が高すぎる
  • 『Oracle TimesTen In-Memory Database C開発者およびリファレンス・ガイド』の自動コミット・モードの無効化に関する説明を参照
  • 『Oracle TimesTen In-Memory Database Java開発者およびリファレンス・ガイド』の自動コミット・モードの無効化に関する説明を参照
DurableCommits属性が有効になっている
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の永続コミットの適切な使用に関する説明を参照
複数回使用するSQL文を準備していない
  • 『Oracle TimesTen In-Memory Database C開発者およびリファレンス・ガイド』の文の事前準備に関する説明を参照
  • 『Oracle TimesTen In-Memory Database Java開発者およびリファレンス・ガイド』の文の事前準備に関する説明を参照
索引の種類が間違っている、索引が多すぎる、ハッシュ索引のサイズが間違っている
  • 『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のハッシュ索引またはTツリー索引の適切な選択に関する説明を参照
  • 『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のハッシュ索引の適切なサイズ設定に関する説明を参照
ロックの使用方法が効率的でない
マテリアライズド・ビューが適切に構成されていない
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のマテリアライズド・ビューのパフォーマンスの改善に関する説明を参照
レプリケーションを使用している場合は、レプリケーション・スキームの構成またはネットワーク環境がアプリケーションに影響を与えている可能性がある
Cache Connectを使用している場合は、Cache Connectの構成または環境がアプリケーションに影響を与えている可能性がある
表のパーティションが多すぎる
1つ以上のTimesTenコンポーネントに対してトレースが不必要に有効になっている

接続モードを検討する

クライアント/サーバー接続は、TimesTenデータ・ストアへの直接接続よりも遅くなります。また、ドライバ・マネージャ接続でも、パフォーマンスに影響を与えます。クライアント/サーバー接続の場合は、データ・ストアとのすべての通信にネットワーク待機時間を伴うため、かなりのパフォーマンスのオーバーヘッドが発生する可能性があります。

データ・ストアをホスティングしているマシンとは別のマシンでアプリケーションを実行する必要がある場合は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のクライアント/サーバーのチューニングに関する説明を参照してください。

表の統計を更新する

通常、TimesTen問合せオプティマイザは、最も効率的な問合せ計画の選択に優れています。ただし、最適な計画を選択するためには、複雑な問合せに関連する表の情報が必要になります。表の行数と列値のデータ分布を把握することにより、オプティマイザは、その表にアクセスするための効率的な問合せ計画を選択できるようになります。

TimesTen表にアクセスする問合せを準備する前に、ttOptUpdateStatsプロシージャを使用して、その表の統計を更新できます。表の統計を更新する場合は、表にデータをロードしてから問合せを準備するまでの間に統計を更新すると、最高の結果が得られます。たとえば、データを移入する前に表の統計を更新すると、表に行がない(または小数の行しかない)ものとして、問合せが最適化されます。その後、数百万行のデータを表に移入してから問合せを実行すると、表にほとんど行がない状況で適切に動作した計画は非常に遅くなります。

統計の更新の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTen問合せオプティマイザに関する説明を参照してください。

ロック・レベルと分離レベルを検証する

複数のアプリケーションがどのようにデータ・ストアに同時アクセスするかで、パフォーマンスが大きく影響を受けることがあります。

アプリケーションは、データ・ストア全体、個々の表および個々の行に対してロックを取得できます。それとは別に、トランザクションがコミットまたはロールバックするまで読取りロックや更新ロックを保持するかどうかを決定する分離レベルも設定できます。

SYS.MONITOR表を確認するか、またはttXactAdminユーティリティを使用して、アプリケーションがロックの待機に時間を費やしているかどうかを検出できます。詳細は、「デッドロックとタイムアウトを確認する」および「ttXactAdminユーティリティの使用」を参照してください。

ロックの競合が激しい場合は、次のように実装することによって、システム全体のパフォーマンスを改善できる場合があります。

ロックの競合を最小になるように前述のとおり設定しても、多数の競合が発生する場合は、競合がアプリケーション自体に関係している可能性もあります。たとえば、同時実行のスレッドが、繰り返し同じ行にアクセスしているような場合です。このような競合の検出には、ttXactAdminユーティリティが役立つことがあります。また、このような状況では、トレースが有効なこともあります。

ロック・レベルと分離レベルの詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の並行性制御に関する説明を参照してください。

トレースの設定を確認する

ttTraceMon -e show「ttTraceMonユーティリティの使用」を参照)を使用して、すべてのTimesTenコンポーネントに対してトレースが無効(OFF)になっていることを確認します。ERRは1に設定され、他のすべてのコンポーネントは0に設定されている必要があります。データ・ストアが再ロードされてもトレース・レベルは保持されます。

Windowsの場合、ODBCトレースが無効になっていることを確認します。コントロール・パネルで「ODBC」をダブルクリックして、ODBCデータソース・アドミニストレータを開きます。「トレース」タブを選択して、トレースが無効になっていることを確認します。「ODBCトレースの使用」を参照してください。

表のパーティション数を確認する

表の作成時、パーティションは1つです。ALTER TABLE ADD COLUMNを使用して新しい列を追加すると、新しいパーティションが表に追加されます。1回のALTER TABLE ADD COLUMN文で複数の列を追加した場合、追加されるパーティションは1つのみです。

表当たりのパーティション数の制限は255です。この数を超えると8204エラーが生成されます。ただし、新しいパーティションを表に追加するたびに不要な読取りが発生し、表に追加された列に対する問合せパフォーマンスがわずかに低下することに注意してください。

各表のパーティション値は、システム表SYS.TABLESの列SYS16で追跡されます。表のパーティション数は、次の問合せで取得します。

SELECT tblname, sys16 FROM SYS.TABLES;

表に含まれるパーティションが多すぎることが検出された場合は、表を再作成するか、ttMigrate create(-c -noRepUpgrade)の後にttRestore(-r -noRepUpgrade)を使用して、表を保存およびリストアします。ALTER TABLE DROP COLUMNでは、表からパーティションは削除されません。