| Oracle® TimesTen In-Memory Databaseオペレーション・ガイド リリース18.1 E98635-05 |
|
 前 |
 次 |
TimesTenを使用したアプリケーションは、従来のRDBMSを使用したアプリケーションと比較すると、データ・アクセスのパフォーマンスが数倍向上します。ただし、アプリケーションの設計とチューニングが適切でなければ、TimesTenのメリットを活かしきれない場合もあります。この章では、TimesTenアプリケーションのパフォーマンスに影響する要因について説明します。この要因には、データ変換のように影響の少ないものから、実行時のコマンド準備などのように影響が大きいものまで様々な要因があります。
この章では、あらゆる要因を説明します。これらの要因では、次のような設問が重要になります。
どのようにして問題を検出するか。
パフォーマンスへの潜在的な影響はどの程度か。
パフォーマンスが向上するタイミングはいつか。
パフォーマンスの代償は何か。
次の項では、パフォーマンスの問題をチューニングし特定する方法について説明します。
|
ノート: パフォーマンス上の問題は、SYS.SYSTEMSTATS表を調査することによっても特定できます。 |
TimesTen Javaアプリケーションのチューニングの詳細は、『Oracle TimesTen In-Memory Database Java開発者ガイド』の「Javaアプリケーションのチューニング」に関する説明を参照してください。TimesTen Cアプリケーションのチューニングの詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』の「ODBCアプリケーションのチューニング」に関する説明を参照してください。
次の項では、システムおよびデータベースのチューニングに関するヒントを示します。
パフォーマンスへの影響: 大
データベース全体がメイン・メモリーに収まるように、システムを構成してください。仮想メモリーを使用すると、パフォーマンスが大幅に低下します。パフォーマンス監視ツールによって、過度のページングや仮想メモリー・アクティビティが示される場合は、データベース(作業セット)のサイズは適切ではありません。大容量の共有メモリーをプロセスに割り当てるには、物理メモリーの追加やシステム・ソフトウェアの設定が必要な場合もあります。
Linuxシステムの場合、共有メモリー・セグメントの最大サイズが、データベースの共有メモリー・セグメントの合計サイズを格納するのに十分な大きさになるように、Linux共有メモリーを構成する必要があります。
TimesTen Classicでは、データベース全体が単一の共有メモリー・セグメントに保持されます。TimesTen Scaleoutでは、各ホストの共有メモリー・セグメントの設定を行います。shmmax、shmall、memlockおよびHugePagesに、適切なオペレーティング・システムのカーネル・パラメータを設定します。詳細は、『Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイド』のオペレーティング・システムの前提条件に関する項および『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』のオペレーティング・システムのカーネル・パラメータの構成に関する項を参照してください。
データベース内の表のサイズ見積りには、TimesTenのttSizeユーティリティを使用できます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttSize」を参照してください。
パフォーマンスへの影響: 不定
Linuxでは、データベースがメモリーにロードされている間に、データベースによって使用される実際のメモリーをロックするかどうかをMemoryLock接続属性で指定します。データベースによって使用されるメモリーのページングを回避するには、MemoryLockを4に設定します。MemoryLockを4に設定しないと、データベースで使用される共有メモリー・セグメントの一部がスワップ領域にページアウトされ、データベースのパフォーマンスが低下する可能性があります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のMemoryLockに関する項を参照してください。
パフォーマンスへの影響: 不定
データベースの作成時には、そのサイズを指定する必要があります。具体的には、データベースの永続メモリー領域および一時パーティションのサイズを指定します。データベースと共有メモリーのサイズを指定する方法の詳細は、このマニュアルの「データベースのメモリー領域サイズの指定」および『Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイド』のshmmaxとshmallの構成に関する項を参照してください。
パフォーマンスへの影響: 不定
PL/SQLランタイム・システムでは、TimesTenのPL/SQLオブジェクトに関するメタデータ、および現在実行中のPL/SQLプログラム・ユニットまたは最近実行されたPL/SQLプログラム・ユニットの実行可能コードの保持に、共有メモリーの領域が使用されます。この共有メモリー領域のサイズは、PLSQL_MEMORY_SIZE初期接続属性によって制御されます。
新しいPL/SQLプログラム・ユニットは、実行の準備時に共有メモリーにロードされます。共有メモリー領域を使用できない場合は、十分な共有メモリー領域を使用できるようになるまで、キャッシュされている最近実行されたプログラム・ユニットがメモリーから廃棄されます。現在実行中のプログラム・ユニットによってすべてのPL/SQL共有メモリーが使用されている場合、新しい接続でPL/SQLの実行を試行すると、領域不足のエラー(ORA-04031など)が発生する可能性があります。この場合は、PLSQL_MEMORY_SIZEを増やします。
そのような領域不足のエラーが発生しなくても、PLSQL_MEMORY_SIZEが小さすぎる場合があります。共有メモリーにキャッシュされているPL/SQLプロシージャを実行する方が、キャッシュされていないPL/SQLプロシージャを実行するよりCPU時間において低コストになります。本番アプリケーションでは、PLSQL_MEMORY_SIZEの値を十分に大きく設定して、頻繁に実行されるPL/SQLユニットが常にキャッシュされるようにする必要があります。TimesTenの組込みプロシージャttPLSQLMemoryStatsを使用すると、この状況が発生する頻度を判断できます。PinHitRatio値として、0から1の間の実数が返されます。
1.0: すべてのPL/SQLがキャッシュから実行されたことを意味します。
0.0: 実行ごとに、プログラム・ユニットを共有メモリーにロードする必要があったことを意味します。
PLSQL_MEMORY_SIZEの適切な値は、アプリケーションによって異なります。非常に少数のPL/SQLプログラム・ユニットが繰り返し実行される場合、必要なサイズは小さい可能性があります。数百のPL/SQLプログラム・ユニットを使用するアプリケーションの場合、必要なメモリーは大きくなります。
PinHitRatioの値が大きくなると、パフォーマンスは大幅に向上します。アプリケーション・プログラムで多数のPL/SQLストアド・プロシージャを繰り返し実行して、一連の検証を行いました。PLSQL_MEMORY_SIZEに大きい値を設定した場合、このアプリケーションのPinHitRatioは約90%となり、1つのPL/SQLプロシージャの平均実行時間は0.02秒となりました。PLSQL_MEMORY_SIZEに小さい値を設定した場合、キャッシュの競合が増加したため、PinHitRatioは66%となりました。この検証における平均実行時間は、0.26秒でした。
PLSQL_MEMORY_SIZEのデフォルト値は、LinuxおよびUNIXシステムでは128 MBです。この値は、適度に複雑な数百個のPL/SQLプログラム・ユニットの実行に十分なサイズです。本番のワークロードでしばらく実行した後、PinHitRatioの値を確認します。値が0.90より小さい場合は、PLSQL_MEMORY_SIZEを増やすことを検討してください。
パフォーマンスへの影響: 不定
TimesTenデータベースへの多数の同時接続を保持するマルチスレッド・アプリケーションでは、オペレーティング・システムが各プロセスに許可しているデフォルトのオープン・ファイル数が少なすぎる場合があります。オープン・ファイル数の新しい制限の設定方法の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のオープン・ファイル数の制限に関する項を参照してください。
パフォーマンスへの影響: 大
LogBufMBおよびLogFileSizeの値を大きくすると、パフォーマンスが大幅に向上する可能性があります。LogBufMBは、LogFileSize接続属性に関連しており、最適なパフォーマンスのために、LogBufMBの同じ値または倍数に設定する必要があります。
ログ・バッファ待機は、アプリケーション処理が、トランザクション・データをログ・バッファに挿入できず、停止してログ・バッファ領域が解放されるのを待機する必要があるときに発生します。通常この理由は、ログ・フラッシャ・スレッドが十分な速さでデータをクリアしていなかったためです。これは、ログ・バッファ領域が不十分、ファイル・システムの転送速度が不十分、ファイル・システムへの書込みに時間がかかりすぎる、またはログ・フラッシャがCPUの能力に依存していることを示していることが考えられます。
小さいLogBufMBは、これらのトランザクションがredoロギング用の領域を確保するためにログ・フラッシュ処理を待機する必要がある場合に、トランザクションの書込みを遅らせる可能性があります。オーバーサイズのログ・バッファは、余分なメモリーを消費すること以外には影響しません。LOG_BUFFER_WAITSの値は、ログ・バッファが一杯であったために、トランザクション・ログ・レコードをログ・バッファに挿入しようとしている間にスレッドが遅延した回数を示します。通常、この値が増大している場合は、ログ・バッファが小さすぎることを示します。
LogFileSize属性では、各トランザクション・ログ・ファイルの最大サイズをMB単位で指定します。LogFileSizeが小さすぎると、TimesTenはトランザクション・ログのフラッシュ処理で複数のログ・ファイルを作成する必要があります。ファイル作成のオーバーヘッドによって、LOG_BUF_WAITSイベントが発生し、パフォーマンスが大きく影響を受けることがあります。
ワークロードの実行中にLOG_BUFFER_WAITSメトリックが増加したかどうかを確認するには、(SYS.MONITOR表またはttIsql monitorコマンドを使用して)このメトリックの値を調べます。その後、LogBufMBの値を増やして、データベースのパフォーマンスを向上させることができます。
LogBufMBの値を大きくすることで生じるデメリットは、メモリーにバッファされるトランザクションが増え、プロセスがクラッシュしたときに失われるトランザクションが多くなる可能性があることです。DurableCommitsが有効になっている場合は、LogBufMB値を大きくしてもパフォーマンスは改善されません。
LogBufMBおよびLogFileSizeの値を大きくした後もログ・バッファ待機が続いている場合、前述のその他の起こり得る可能性のある問題を確認してください。
LogBufParallelism接続属性は、トランザクション・ログ・バッファ・ストランドの数を指定します。この属性によって、複数の接続が書込みトランザクションを同時に実行する場合のトランザクション・スループットが向上します。これを、システム上のCPUコア数と書込みトランザクションを実行する同時接続数のうちの小さいほうの値に構成します。
|
ノート: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のLogBufMB、LogFileSizeおよびLogBufParallelismに関する項を参照してください。 |
パフォーマンスへの影響: 大
アイドル状態のデータベースは、接続のないデータベースです。デフォルトでは、最初の接続が確立されると、TimesTenによってアイドル状態のデータベースがメモリーにロードされます。最後のアプリケーションのデータベースへの接続が切断されると、ファイル・システムへのデータベースの書込み時に遅延が発生します。アプリケーションとデータベース間の接続と切断が連続して行われる場合は、メモリーへのデータベースのロードとアンロードも連続して行われる可能性があるため、過度のファイル・システムI/Oおよびパフォーマンスの低下が発生します。同様に、使用するデータベースが非常に大きい場合は、アプリケーションでデータベースが使用される前に、メモリーにデータベースをロードしておくようにしてください。
データベースがメモリーにロードされるまでの待機時間を回避するために、TimesTen ClassicデータベースのRAMポリシーを変更して、データベースが常にメモリーに残るようにできます。この方法のデメリットは、TimesTen Classicデータベースがメモリーからアンロードされないため、最後の接続を切断してもチェックポイントが発生しないことです。そのため、アプリケーションでは、ttCkptConfig組込みプロシージャを使用して、頻繁にチェックポイントを構成する必要があります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCkptConfigに関する項を参照してください。
また、一定期間だけTimesTen Classicデータベースをメモリーに常駐させ、新しい接続を受け入れるように指定することもできます。この期間に新しい接続が確立されなかった場合、データベースはメモリーからアンロードされ、チェックポイント処理が実行されます。また、システム管理者がデータベースを手動でメモリーからのロードとアンロードを実行できるようにも設定できます。
TimesTen ClassicデータベースのRAMポリシーを変更するには、ttAdminユーティリティを使用します。RAMポリシーおよびttAdminユーティリティの詳細は、このマニュアルの「RAMポリシーの指定」および『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。
パフォーマンスへの影響: 大
ttRepAdmin -duplicateユーティリティを使用してこのデータベースを複製する前に、ttAdmin -ramLoadコマンドを使用してTimesTen Classicデータベースをメモリーにロードします。これにより、データベースは、ブロッキング・チェックポイントでアンロードされるのではなく、接続可能な状態でメモリーに配置されます。詳細は、このガイドの「TimesTen Classicデータベースの接続オーバーヘッドの回避」、および『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する項とttRepAdminに関する項を参照してください。
パフォーマンスへの影響: 大
データベースが無効化された後TimesTen Classicが復旧すると、新しいデータベースがリロードされます。ただし、無効化されたデータベースはそのデータベースへの接続がすべて閉じられるまでアンロードされません。したがって、無効化されたデータベースとリカバリ後のデータベースの両方が同時にRAMに存在することがあります。
無効なデータベースがメモリーにまだ存在している間に大きなデータベースをメモリーにリロードすると、使用可能RAMが一杯になることがあります。データベースの自動リロードを防止する方法の詳細は、「自動リカバリ失敗後のデータベースのリロードを防止する」を参照してください。
パフォーマンスへの影響: 大
データベースで競合が発生すると、アプリケーションのパフォーマンスが大幅に低下する可能性があります。
アプリケーションでの競合を軽減するには、次の手順を実行します。
適切なロック方法を選択します。詳細は、「最適なロック方法の選択」を参照してください。
複数の表またデータベースにデータを効果的に分散します。
ロックの競合および同時実行性の低下が原因でアプリケーションのパフォーマンスが低下している場合は、パフォーマンスを向上させるために、まず競合を軽減する必要があります。
ロックの競合の詳細は、SYS.SYSTEMSTATS表内のlock.locks_granted.immediate列、lock.locks_granted.wait列およびlock.timeouts列を参照してください。
lock.locks_granted.immediateでは、ロックが使用可能になり、ロック・リクエスト時に即時に付与された回数がカウントされます。
lock.locks_granted.waitでは、ロックが使用可能になるまでリクエストしたユーザーが待機した後でロック・リクエストが付与された回数がカウントされます。
lock.timeoutsでは、ロックが使用可能になるまでリクエストしたユーザーが待機しなかったためロックが付与されなかった回数がカウントされます。
同時実行性が制限されたためスループットが低下している場合、またはレスポンス時間が問題となっている場合は、アプリケーションでAPI (JDBC、ODBC、またはOCI)コールを行うスレッドまたはプロセスの数を削減できます。使用するスレッドを減らすには、アプリケーション側でキューイングとスケジューリングが必要であり、この場合、競合および待機時間を減らすためにCPU時間が多少長くなります。結果として、データベースに大部分の時間を使う同時実行性の低いアプリケーションのパフォーマンスが向上します。
パフォーマンスへの影響: 中
最初のロードなど、特別な処理を実行する場合は、通常とは異なる別のオプションを選択できます。特に、バルク・ロードを行う場合はttBulkCpまたはttMigrateなどを使用し、データベース・レベル・ロックを使用することを検討してください。これらの設定により、ロード時のパフォーマンスを2倍にすることも可能です。
データベース・レベル・ロックに代わる方法として、同時実行性を利用する方法があります。-notblLockオプションを使用すると、ttBulkCp -iのコピーを複数実行できます。ttBulkCpの最適なバッチ処理は、-xp 256オプションを追加することで行われます。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttBulkCp」および「ttMigrate」を参照してください。
パフォーマンスへの影響: 大
TimesTen Data Managerドライバには、プラットフォームごとに、デバッグ・バージョンと本番バージョンの2種類があります。デバッグを実行しないときは、本番バージョンを使用してください。デバッグ・ライブラリを使用すると、処理がかなり遅くなることがあります。各種プラットフォームのTimesTen Data Managerドライバについては、「LinuxおよびUNIXでのTimesTen ClassicのDSNの作成」および「ODBCドライバおよびJDBCドライバを使用したTimesTenへの接続」を参照してください。
Windowsの場合は、ODBC Driver Managerを使用するアプリケーションが、適切なTimesTenドライバにアクセスするDSNを使用していることを確認してください。アプリケーションでは、適切なTimesTenドライバにリンクされていることを確認してください。直接接続アプリケーションの場合、TimesTen Data Managerドライバを使用します。アプリケーションからは、SQL_DRIVER_NAME引数を指定してODBC SQLGetInfo関数をコールし、使用するドライバを決定できます。
パフォーマンスへの影響: 大
ODBCとJDBCには、その両方にアプリケーションをデバッグするためのトレース機能があります。パフォーマンスを重視している場合は、アプリケーションのデバッグ時を除き、トレース機能を無効に設定してください。
JDBCのトレース機能を有効にするには、次のメソッドを使用します。
DriverManager.setLogStream method: DriverManager.setLogStream(new PrintStream(System.out, true));
デフォルトでは、トレース機能は無効です。このメソッドをコールしてから、JDBCドライバをロードする必要があります。トレース機能を有効にした後、アプリケーションの実行中はトレース機能を無効にできません。
パフォーマンスへの影響: 不定
ttStatsユーティリティを使用して、データベース・メトリックを収集および表示できます。ttStatsユーティリティでは、次の機能を実行できます。
パフォーマンス・メトリックをリアルタイムでモニタリングおよび表示し、前のインターバルからの変化率を計算する。
メトリックのスナップショットを収集してデータベースに格納し、値と変更率を記載したレポートを、指定したスナップショットのペアから生成する(これらの機能はTT_STATS PL/SQLパッケージへのコールを介して実行)。
ttStatsユーティリティは、TimesTenシステム表、ビューおよび組込みプロシージャからメトリックを収集します。レポートには、メモリー使用量、接続およびロード・プロファイルの概要などの情報に続き(必要に応じて)SQL文、トランザクション、PL/SQLメモリー、レプリケーション、ログとログの保持、チェックポイント、キャッシュ・グループ、ラッチ、ロック、XLAおよびTimesTen接続属性に関するメトリックが含められます。
ttStatsConfig組込みプロシージャをコールして、ttStatusユーティリティに影響を与える統計収集パラメータを変更します。ttStatsConfig組込みプロシージャのパラメータの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatsConfigに関する項を参照してください。
ttStatsユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatsに関する説明を参照してください。TT_STATS PL/SQLパッケージの詳細は、『Oracle TimesTen In-Memory Database PL/SQLパッケージ・リファレンス』のTT_STATSに関する説明を参照してください。
パフォーマンスへの影響: 不定
データベースの移行時に文字セット変換がリクエストされた場合は、文字セット変換がリクエストされない場合よりパフォーマンスが低下します。
パフォーマンスへの影響: 不定
領域を節約して計算のパフォーマンスを高めるために、TimesTenのネイティブ整数データ型(NUMBERデータ型ではなく、TT_TINYINT、TT_SMALLINT、TT_INTEGERまたはTT_BIGINT)を指定して表の列タイプを宣言します。TimesTenでは、内部的にSMALLINT、INTEGER、INT、DECIMAL、NUMERICおよびNUMBERデータ型をNUMBERデータ型にマップします。表の列タイプを定義するときには、列のオーバーフローを回避するために、必ず、適切なネイティブ整数データ型を選択してください。ネイティブ整数データ型とNUMBERデータ型の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の数値データ型に関する項を参照してください。
Oracle Databaseの読取りおよび書込みを行うTimesTenキャッシュ・グループを作成するとき、TimesTenのネイティブ整数データ型を使用する場合は、TimesTenキャッシュ・グループおよびOracle Databaseの列のデータ型に互換性があることを確認してください。Oracle Databaseデータ型とTimesTenデータ型の間のマッピングの詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Databaseデータ型とTimesTenデータ型の間のマッピングに関する項を参照してください。
パフォーマンスへの影響: 大
TimesTenでは、パフォーマンスを最適にするため、LogDir接続属性を使用して、トランザクション・ログ・ファイルをチェックポイント・ファイルとは別の物理デバイスに格納することをお薦めします。これは、アプリケーションで一貫したレスポンス時間とスループットが必要な場合に重要です。TimesTenでは、DataStore接続属性で指定された場所にチェックポイント・ファイルを格納します。これは、データベースのフルパス名およびファイル名の接頭辞です。トランザクション・ログ・ファイルとチェックポイント・ファイルが別の物理デバイス上にある場合、チェックポイントのI/O操作とトランザクション・ログに対するI/O操作が相互にブロックすることがなくなります。トランザクション・ロギングの詳細は、「トランザクションのロギング」を参照してください。
LogDirおよびDataStore接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のLogDirに関する項およびDataStoreに関する項を参照してください。
|
ノート: データベースがすでにRAMにロードされており、データベースのトランザクション・ログ・ファイルとチェックポイント・ファイルが同じ物理デバイス上にある場合、TimesTenはデーモン・ログ・ファイルにメッセージを書き込みます。 |
次の項では、クライアント/サーバーのチューニングに関するヒントを示します。
パフォーマンスへの影響: 不定
クライアント/サーバーのパフォーマンスは、SYS.SYSTEMSTATS表で追跡される次の統計で分析できます。これはttStatsユーティリティまたはTT_STATS PL/SQLパッケージでも表示できます。
|
ノート: SYS.SYSTEMSTATS表の詳細は、『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』のSYS.SYSTEMSTATSに関する説明を参照してください。ttStatsユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatsに関する説明を参照してください。TT_STATS PL/SQLパッケージの詳細は、『Oracle TimesTen In-Memory Database PL/SQLパッケージ・リファレンス』のTT_STATSに関する説明を参照してください。 |
クライアント/サーバー・アプリケーションからの総実行回数。
サーバーによるINSERT、UPDATE、DELETE、SELECT、MERGE、ALTER、CREATE、DROP文の総実行回数。
サーバーによるトランザクションのコミットまたはロールバックの総回数。
サーバーによる、表への行の挿入、更新または削除の総回数。
クライアント/サーバーのラウンドトリップの総回数。
サーバーが転送または受信したバイトの総数。
クライアント/サーバーの切断の総回数。
パフォーマンスへの影響: 大
TimesTen Clientを使用してリモート・サーバー・システムにあるデータベースにアクセスする場合、接続に対してネットワーク上のオーバーヘッドが発生します。可能な場合は常に、ダイレクト・ドライバを使用してローカルにTimesTenにアクセスするようアプリケーションを記述し、TimesTenにアプリケーションを直接リンクします。
パフォーマンスへの影響: 不定
デフォルトでは、接続はTimesTen ClientおよびTimesTen Serverがネットワーク操作を完了するまで60秒待機します。TTC_Timeout属性では、タイムアウトする前にTimesTen Clientアプリケーションがそれに対応するTimesTen Serverプロセスの結果を待機する最大秒数を指定します。
TTC_ConnectTimeout属性では、クライアントがSQLDriverConnectリクエストまたはSQLDisconnectリクエストを待機する最大秒数を指定します。これは、それらのリクエストに対するTTC_Timeoutの値を上書きします。接続リクエストが、問合せリクエストに指定されたタイムアウトとは異なる時間枠でタイムアウトするようにする場合は、TTC_ConnectTimeoutを設定します。たとえば、接続に長時間かかることがわかっている場合は、接続のタイムアウトを長く設定できますが、他のすべての問合せのタイムアウトは短く設定できます。
SQLDriverConnectコールに割り当てられた全体の経過時間は、自動クライアント・フェイルオーバーが構成されているかどうかによって決まります。
TTC_SERVERn接続属性が1つのみ定義されている場合、自動クライアント・フェイルオーバーは構成されておらず、初期接続試行に割り当てられる全体の経過時間は10秒に制限されます。
自動クライアント・フェイルオーバーが定義されており、TTC_SERVERn接続属性が複数構成されている場合、全体の経過時間はタイムアウト値(TTC_TimeoutまたはTTC_ConnectTimeoutのいずれか)の4倍になります。たとえば、ユーザーがTTC_TIMEOUT=10を指定し、複数のTTC_SERVERnサーバーが構成されている場合、SQLDriverConnectコールは最大40秒かかります。
ただし、この全体の経過タイムアウト内で、各接続試行はTTC_TimeoutまたはTTC_ConnectTimeoutの値で指定された時間を要することがあります。TTC_ConnectTimeoutの値は、TTC_Timeoutの値より優先されます。
TTC_TimeoutとTTC_ConnectTimeoutがSQLおよびPL/SQLのタイムアウトとどのように関連するかの詳細は、「SQLおよびPL/SQLのタイムアウト値の選択」を参照してください。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のTTC_Timeoutに関する項およびTTC_ConnectTimeoutに関する項を参照してください。
パフォーマンスへの影響: 不定
デフォルトでは、接続は10秒待機してロックを設定します。ロックのタイムアウト間隔を変更するには、LockWait接続属性を設定するか、ttLockWait組込みプロシージャを使用します。ロック競合の可能性が高いワークロードを実行する際には、LockWait接続属性を小さい値に設定してアプリケーションに制御を迅速に戻すか、LockWaitを大きな値に設定してロック付与率を増加する(スループットが減少するリスクがある)ことを検討してください。
詳細は、このマニュアルの「ロック取得の待機時間の設定」または『Oracle TimesTen In-Memory Databaseリファレンス』のLockWaitに関する項またはttLockWaitに関する項を参照してください。
パフォーマンスへの影響: 不定
複数の接続で同時にデータベースにアクセスする場合、TimesTenは、ロックを使用して様々なトランザクションが明示的に分離されて処理されるようにします。TimesTenでは、第7章「トランザクション管理」で説明される分離レベルをサポートしています。また、データベース・レベル・ロック、表レベル・ロックおよび行レベル・ロックのロック・レベルをサポートしています。LockLevel接続属性を使用すると、データベース・レベル・ロックと行レベル・ロックのどちらを使用するか指定できます。表ロックを使用するかどうかを示すオプティマイザ・ヒントを設定するには、ttOptSetFlagプロシージャを使用します。デフォルトのロック粒度は行レベル・ロックです。
|
ノート: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「LockLevel」および「ttOptSetFlag」を参照してください。 |
データベースで競合がほとんど発生しない場合は、表レベル・ロックを使用します。これによって、パフォーマンスが改善され、デッドロックの可能性も低くなります。通常、トランザクションが短時間の場合または接続が少ない場合は、データベースで競合はほとんど発生しません。この場合、トランザクションが重複する可能性は低くなります。
また、表レベル・ロックは、文が表のほぼすべての行にアクセスする場合にも有効です。このような文には、1つのトランザクションで実行される問合せ、更新、削除、複数の挿入などがあります。
データベース・レベル・ロックは、単一のトランザクションに対するデータベース・アクセスを完全に制限するため、通常の操作には推奨されません。データベース・レベル・ロックを使用して長時間実行されるトランザクションは、データベースへの他のアクセスをすべてブロックし、データベースの監視と保守に必要な各種のバックグラウンド・タスクにさえ影響します。
通常、同じ行にアクセスする必要がほとんどない同時トランザクションが多数存在する場合は、行レベル・ロックを使用することを薦めします。プロセッサ数が十分で、同時実行性能が高い最新のシステム、たとえば複数のttBulkCpプロセスでは、行レベル・ロックのほうがデータベース・レベル・ロックよりパフォーマンスが高いのが普通です。
|
ノート: ttBulkCpユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttBulkCpに関する説明を参照してください。 |
行レベル・ロックを使用している場合、アプリケーションでは、トランザクションをSERIALIZABLEまたはREAD_COMMITTEDの分離レベルで実行できます。デフォルトの分離レベルはREAD_COMMITTEDです。Isolation接続属性を使用すると、これらの分離レベルのいずれかを新しい接続に指定できます。
SERIALIZABLEトランザクション分離レベルで実行すると、トランザクションの間、TimesTenではすべてのロックが維持されます。
行を更新するトランザクションでは、トランザクションがコミットされるまで書込みユーザーがブロックされます。
行を読み込むトランザクションでは、トランザクションがコミットされるまで書込みユーザーがブロックされます。
READ_COMMITTEDトランザクション分離レベルで実行すると、トランザクションの間、TimesTenでは更新のロックのみが維持されます。
行を更新するトランザクションでは、トランザクションがコミットされるまで、この行に対する書込みユーザーはブロックされます。この行を読み取るユーザーは、この行の以前コミットされたバージョンを受け取ります。
ファントム行が発生する場合があります。ファントム行とは、トランザクション時に読取りのロックが早く解放されたため、同じトランザクションにおいて、その行が、ある読取りでは表示されるが別の読取りでは表示されなかったり、2つの異なる読取りが異なる形式で表示されることが発生することです。
タイムアウトおよびデッドロックのエラー(エラー6001、6002および6003)をチェックすると、システムに競合が過度に存在しているかどうかを確認できます。この情報は、SYS.SYSTEMSTATS表のlock.timeouts列およびlock.deadlocks列でも確認できます。
分離レベルの詳細は、「トランザクションの分離レベル」を参照してください。
パフォーマンスへの影響: 不定
TimesTen Clientは、通常、TCP/IPソケットを使用してTimesTen Serverと通信します。TimesTen ClientとTimesTen Serverの両方が同一システム上にある場合は、プロセス間の通信(IPC)に共有メモリー・セグメントまたはUNIXドメイン・ソケットを使用することで、クライアント・アプリケーションのパフォーマンスが改善されます。
共有メモリー・セグメントをIPCとして使用するには、timesten.confファイルでサーバー・オプションを設定する必要があります。サーバー・オプションの詳細は、「TimesTen Server属性の変更」を参照してください。
また、IPCに共有メモリー・セグメントを使用するアプリケーションでは、ネットワーク・アドレスとしてttShmHostを使用して、クライアントDSNに対する論理サーバー名を設定する必要があります。詳細は、「LinuxおよびUNIXでのクライアントDSNの作成および構成」を参照してください。
この機能は共有メモリーを大量に必要とする可能性があります。TimesTen Serverは、既存の接続数や全接続内の文の数にかかわりなく、共有メモリー・セグメントを事前に割り当てます。
LinuxまたはUNIXシステムでアプリケーションを実行しているときにメモリーの使用量が懸念される場合は、UNIXドメイン・ソケットを通信に使用すると、TimesTen Client ODBCドライバを使用しているアプリケーションのパフォーマンスを改善できる場合があります。UNIXドメイン・ソケットの使用によるパフォーマンスの改善は、ShmIPCを使用した場合ほど大きくありません。
ローカル接続にUNIXドメイン・ソケットを使用するアプリケーションでは、ネットワーク・アドレスとしてttLocalHostを使用して、クライアントDSNに対する論理サーバー名を設定する必要があります。詳細は、「LinuxおよびUNIXでのクライアントDSNの作成および構成」を参照してください。また、システム・カーネル・パラメータが、必要な接続数を許容するように設定されていることも確認してください。
詳細は、Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイドのLinuxの前提条件を参照してください。
パフォーマンスへの影響: 不定
TimesTen拡張機能により、アプリケーションでは、クライアント/サーバー・アプリケーションの読取り専用問合せのパフォーマンスを最適化できます。プリフェッチ・クローズを有効化すると、サーバーでは、結果セット全体が読取り専用の問合せに対してフェッチされた後でカーソルが閉じられ、トランザクションがコミットされます。これによって、クライアントとサーバー間のネットワーク・ラウンドトリップが減少するため、パフォーマンスが向上します
ODBC: SQLSetConnectOptionを使用してTT_PREFETCH_CLOSE ODBC接続オプションを設定します。詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』の問合せのパフォーマンスの最適化に関する項を参照してください。
JDBC: trueを設定してTimesTenConnectionメソッドsetTtPrefetchClose()をコールします。詳細は、『Oracle TimesTen In-Memory Database Java開発者ガイド』の問合せのパフォーマンスの最適化に関する項を参照してください。
パフォーマンスへの影響: 大
SQLTransactをコールする場合は、常に、有効なHDBCハンドルおよびnullの環境ハンドルを使用する必要があります。
SQLTransact (SQL_NULL_HENV, ValidHDBC, fType)
非nullの環境ハンドルおよびnullの接続ハンドルを使用してSQLTransactをコールできますが、プロセスのすべてのトランザクションが突然コミットされたりロールバックされ、処理に時間がかかり、アプリケーションの予期しない動作が発生する可能性があるため、使用することはお薦めしません。
MaxConnsPerServer接続属性は、TimesTenサーバー・プロセスに許可される最大同時接続数を設定します。デフォルトでは、MaxConnsPerServerは1に設定されています。つまり、各TimesTenサーバー・プロセスは1つのクライアント接続のみを処理できます。
MaxConnsPerServerを1より大きい値に設定すると、データベースに対してマルチスレッド・モードが有効になり、プロセスではなくスレッドを使用してクライアント接続を処理できます。これにより、アプリケーションが新しい接続を確立するのに必要な時間が短縮され、多数の同時クライアント/サーバー接続を使用する構成の全体的な効率が向上します。
詳細は、「LinuxまたはUNIXシステム上のTimesTen ServerのサーバーDSNの定義」を参照してください。
全体のロックおよびI/Oの方針の決定後、個々のSQL文をできるだけ効率的に実行できるようにしてください。次の項では、SQL文を簡素化する方法について説明します。
パフォーマンスへの影響: 大
すべての文が効率的に実行されているかどうかをチェックします。たとえば、使用する問合せは、必要な結果セットを生成するために必要な行のみを参照するようにします。表t1のcol1のみが必要であれば、次の文を使用します。
SELECT col1 FROM t1...
または、次の文を使用します。
SELECT * FROM t1...
TimesTenで文を実行するために使用される計画の表示方法については、第9章「TimesTen問合せオプティマイザ」を参照してください。また、計画は、ttIsql showplanコマンドを使用して表示することもできます。アプリケーションで頻繁に実行される各文の計画を表示します。索引が条件を評価するために使用されていない場合は、索引を使用できるように、新しい索引の作成または文や問合せの再作成を検討してください。たとえば、WHERE句の評価に索引を使用できるのは、比較条件(一致および不一致)の一方に単一の列が出現する場合か、BETWEEN条件内のみとなります。
この比較条件が頻繁に評価される場合は、再作成するのが妥当です。
WHERE c1+10 < c2+20
これを次のように書きなおします。
WHERE c1 < c2+10
c1に索引を作成します。
索引が存在することにより、UPDATE、INSERT、DELETE、CREATE VIEWなどの書込み操作の処理速度が遅くなります。アプリケーションでの読取りが少ないものの、表への書込みが多い場合は、その表の索引によってパフォーマンスが向上するのではなく、低下する可能性があります。
場合によっては、問合せ評価の処理速度を向上するために、システムによって一時索引が作成される場合があります。このような場合が頻繁にある場合は、アプリケーション自体で索引を作成する方が効率的です。MONITOR表のCMD_TEMP_INDEXES列は、問合せ評価時に一時索引が作成された回数を示します。
表またはキャッシュ・グループに対して時間ベースのエージングを実装している場合は、タイムスタンプ列に索引を作成すると、エージングのパフォーマンスが向上します。詳細は、「時間ベースのエージング」を参照してください。
パフォーマンスへの影響: 不定
TimesTenには、SQL操作の実行時間を測定して表示することでSQL文のパフォーマンスを判断できる組込みプロシージャがあります。追跡のかわりに、組込みプロシージャがSQL文の実行中に実行時間をサンプリングします。この組込みプロシージャは、SQLExecute API内で実行の時間を測定することで、SQL文の実行時間を測定します。
ttStatsConfig組込みプロシージャと次の名前と値のペアを使用して、サンプリング・レートと実行時間の収集方法を構成できます。
|
ノート: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatsConfigに関する説明を参照してください。 |
表10-1 ttStatsConfigパラメータと値の説明
| パラメータ | 説明 |
|---|---|
|
|
SQL文と実行時間タイミングのサンプルを収集する方法を構成します。デフォルトは0です。これはサンプリングをオフにするという意味です。たとえば10に設定すると、TimesTenはSQL文の実行のウォール・クロック時間を、10個の文ごとにキャプチャします。 |
|
|
個々の接続でSQL文のサンプルを収集する頻度を構成します。値は2個のパラメータがカンマで区切られ、引用符で囲まれているため、単一の値のように見えます。1番目の値は接続IDです。2番目の値は |
|
|
0以外の値に設定すると、SQL実行時間のヒストグラム・データがクリアされます。 |
|
|
使用する統計レベルを設定します。値は |
次は、ttStatsConfig組込みプロシージャで名前と値のペアを設定する方法の例です。
|
ノート: すべてのトランザクションをサンプリングするかわりに、ttStatsConfig組込みプロシージャのConnSampleFactorパラメータを使用して代表的な接続を選択すると、最良の結果が得られます。小さなサンプリング係数ですべてのトランザクションをサンプリングすると、パフォーマンスが低下するおそれがあります。
意味のある結果を得るには、データベースをメモリーに読み込んだままにする必要があります。データベースのアンロードとリロードを行うと、SQLコマンドキャッシュが空になるためです。 |
接続1で文を5個ごとにサンプリングします。
Command> call ttStatsConfig('ConnSampleFactor', '1,5');
< CONNSAMPLEFACTOR, 1,5 >
1 row found.
接続1のサンプリングをオフにします。
Command> call ttStatsConfig('ConnSampleFactor', '1,0');
< CONNSAMPLEFACTOR, 1,0 >
1 row found.
すべてのコマンドをサンプリングします。
Command> call ttStatsConfig('SqlCmdSampleFactor',1);
< SQLCMDSAMPLEFACTOR, 1 >
1 row found.
サンプリングの設定を確認します。
Command> call ttStatsConfig('SqlCmdSampleFactor');
< SQLCMDSAMPLEFACTOR, 1 >
1 row found.
データベース統計の現在の収集レベルを確認します。
Command> call ttStatsConfig('StatsLevel');
< STATSLEVEL, TYPICAL >
1 row found.
データベース統計収集をNONEに設定してオフにします。
Command> call ttStatsConfig('StatsLevel','None');
< STATSLEVEL, NONE >
1 row found.
収集する統計の構成の完了後、ttSQLCmdCacheInfo組込みプロシージャを使用すると、収集された統計が表示されます。実行時間のヒストグラムをコマンドレベルまたはデータベースレベルで表示するには、ttSQLExecutionTimeHistogram組込みプロシージャを使用します。
ttSQLCmdCacheInfo組込みプロシージャは、SQL実行時間統計に関する次の情報を表示します。
この文のために内部的に行われたフェッチの実行回数です。
文が開始したときのタイムスタンプです。
この文の最大ウォール・クロック実行時間が秒単位で表示されます。
最後に測定された実行時間が秒単位で表示されます。
最小実行時間が秒単位で表示されます。
次の例では、ディスプレイには末尾の5つの値に次の統計が表示されます。
Command> vertical call ttSQLCmdCacheInfo(135680792); SQLCMDID: 135680792 PRIVATE_COMMAND_CONNECTION_ID: -1 EXECUTIONS: 97414 PREPARES: 50080 REPREPARES: 1 FREEABLE: 1 SIZE: 3880 OWNER: ORATT QUERYTEXT: select min(unique2) from big1 FETCHCOUNT: 40 STARTTIME: 2018-04-10 13:10:46.808000 MAXEXECUTETIME: .001319 LASTEXECUTETIME: .000018 MINEXECUTETIME: .000017 EXECLOC: 0 GRIDCMDID: 00000000000000000000 TEMPSPACEUSAGE: 0 MAXTEMPSPACEUSAGE: 0 1 row found.
ttSQLCmdCacheInfo組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttSQLCmdCacheInfoに関する説明を参照してください。
ttSQLExecutionTimeHistogram組込みプロシージャは、SQL実行時間のヒストグラムを、単一のSQLコマンドまたはコマンドキャッシュにあるすべてのSQLコマンドに対して表示します。その際、サンプリングが有効になっていると仮定されます(SQLCmdSampleFactorが0より大きい)。
ヒストグラムには、ヒストグラムのバケットごとに1つの行が表示されます。各行には次の情報が含まれます。
TimesTenデータベースを開始した時点、またはttStatsConfig組込みプロシージャを使用して統計をリセットした時点のいずれか以降に測定された、SQL文の実行時間操作の数。
累積ウォール・クロック実行時間。
各時間フレームを示す実行時間制限。
最後の行は、特定の時間フレーム内に実行されたSQL文の数を示します。
次の例は、ttSQLExecutionTimeHistogram組込みプロシージャの出力を示します。
次のttSQLExecutionTimeHistogram組込みプロシージャの例は、合計1919個の文が実行されたことを示します。1919個の文すべての合計実行時間は1.090751秒でした。この例は、SQL文が次のタイムフレーム内で実行されたことを示します。
0.00001562秒以下のタイムフレーム内で、278個の文が実行されました。
0.00001562秒より大きく0.000125秒以下のタイムフレームで、1484個の文が実行されました。
0.000125秒より大きく0.001秒以下のタイムフレームで、35個の文が実行されました。
0.001秒より大きく0.008秒以下のタイムフレームで、62個の文が実行されました。
0.008秒より大きく0.064秒以下のタイムフレームで、60個の文が実行されました。
Command> call ttSQLExecutionTimeHistogram; < 1919, 1.090751, .00001562, 278 > < 1919, 1.090751, .000125, 1484 > < 1919, 1.090751, .001, 35 > < 1919, 1.090751, .008, 62 > < 1919, 1.090751, .064, 60 > < 1919, 1.090751, .512, 0 > < 1919, 1.090751, 4.096, 0 > < 1919, 1.090751, 32.768, 0 > < 1919, 1.090751, 262.144, 0 > < 1919, 1.090751, 9.999999999E+125, 0 > 10 rows found.
パフォーマンスへの影響: 不定
TimesTenデータベースでは、ハッシュ索引と範囲索引がサポートされています。次に、それぞれの索引の種類をいつ使用するのが適切か説明します。
ハッシュ索引は、1つ以上の列で完全一致する行を検索する場合に有効です。ハッシュ索引は、一致検索の実行に便利です。ハッシュ索引は次のいずれかの方法で作成されます。
CREATE [UNIQUE] HASH INDEX文を使用すると、ハッシュ索引または一意のハッシュ索引を作成できます。
CREATE TABLE... UNIQUE HASH ON文を使用すると、表の作成時に一意のハッシュ索引を作成できます。一意のハッシュ索引は、表の主キー列に対して指定します。
範囲索引は、デフォルトではCREATE TABLE文で作成します(CREATE [UNIQUE] HASH INDEX文で作成することも可能です)。範囲索引では完全一致のキーの検索を高速化でき、より柔軟性が高く、他の問合せの高速化にも利用できます。問合せにLESS THANまたはGREATER THANの比較がある場合は、範囲索引を選択します。範囲索引は、カーディナリティの高いデータ(CUSTOMER_NAMEまたはPHONE_NUMBERなどの使用可能な値が多数あるデータ)に対して効果的です。範囲索引はインメモリーのデータ管理に最適化されています。
また、範囲索引は、接頭辞問合せの高速化に使用することもできます。接頭辞問合せでは、指定されている最後のキー列以外のすべての列に一致条件を指定できます。接頭辞問合せの最後の列には、一致条件または不一致条件を指定できます。
次の表および索引の定義について考えてみます。
Command> CREATE TABLE T(i1 tt_integer, i2 tt_integer, i3 tt_integer, ...); Command> CREATE INDEX IXT on T(i1, i2, i3);
索引IXTを使用すると、次の問合せを高速化できます。
Command> SELECT * FROM T WHERE i1>12; Command> SELECT * FROM T WHERE i1=12 and i2=75; Command> SELECT * FROM T WHERE i1=12 and i2 BETWEEN 10 and 20; Command> SELECT * FROM T WHERE i1=12 and i2=75 and i3>30;
索引IXTは次の問合せには使用されません。接頭辞プロパティが条件を満たしていないためです。
Command> SELECT * FROM T WHERE i2=12;
i1に一致条件が指定されていません。
次のような問合せの場合、索引IXTは使用されますが、一致検索は最初の2列のみに対して実行されます。
Command> SELECT * FROM T WHERE i1=12 and i2<50 and i3=630;
範囲索引の構造は、表サイズの変更に対応して自動的に調整される動的構造です。範囲索引は、一意にすることも一意にしないこともでき、またNULL値可能列に対して宣言することもできます。また、レコードの挿入後、索引付けされた列の値を変更することもできます。範囲索引は、ほとんどの場合、同等のハッシュ索引より単純です。
パフォーマンスへの影響: 不定
TimesTenはハッシュ索引を、主キーの制約として、およびCREATE INDEX文の一部として指定された場合の両方で使用します。ハッシュ索引のサイズは、CREATE TABLEおよびCREATE INDEX文のUNIQUE HASH ON句で指定するPAGESパラメータで決まります。PAGESの値は、表の予想行数を256で除算した値にします。たとえば、256,000行の表の場合、PAGES = 1000とします。小さい値を指定すると、ハッシュ競合の数が増加してパフォーマンスが低下し、大きい値を指定すると、パフォーマンスが多少向上するかわりに索引で追加の領域が必要になります。
表の行数が大幅に変動し、パフォーマンスが主な検討事項である場合、大きな索引を作成するのが最善です。表のサイズを正確に予測できない場合は、範囲索引を使用することを検討してください。また、索引付けする列が大きいCHAR値またはバイナリ値の場合、あるいは索引付けする列が多い場合は、一意索引の使用を検討してください。これらの場合は、一意索引の方がハッシュ索引より高速になる場合があります。
表のサイズが大きくなるにつれてレコード挿入のパフォーマンスが低下する場合は、表の予想サイズを小さく見積りすぎていた可能性があります。ALTER TABLE文を使用してUNIQUE HASH ON句のPAGES値を再設定することによって、ハッシュ索引のサイズを変更できます。SET PAGESの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER TABLEに関する説明を参照してください。
パフォーマンスへの影響: 不定
外部キーを宣言しても、SELECT問合せのパフォーマンスには影響ありませんが、外部キーが定義された表でINSERTおよびUPDATE操作を実行する場合、および外部キーで参照される表でUPDATEおよびDELETE操作を実行する場合は、パフォーマンスが低下します。この低下は、表を参照する外部キーの数または表に定義されている外部キーの数に比例します。
パフォーマンスへの影響: 大
データベース内のデータに関する統計が利用できる場合、TimesTenオプティマイザは、コマンドを準備する際に、それらの統計を使用してデータへの最適なパスを決定します。統計がない場合、オプティマイザは、データ配布に関して一般的な予測を行います。
情報によって問合せオプティマイザの計画がより効率的になる可能性があるため、文を準備する前に統計を計算する必要があります。パフォーマンスは統計収集プロセスの影響を受けるため、統計を収集する場合は、新しい統計を収集するとき、およびその頻度を決定する必要があります。収集の頻度は、統計収集プロセスで起こるオーバーヘッドの処理に対し、オプティマイザの正確な統計を出すタスクのバランスをとる必要があります。
統計の計算は時間がかかる処理のため、次のガイドラインを使用して統計を計算してください。
データベースのロード後またはアプリケーションのメジャー・アップグレード後に、統計を更新します。
トランザクションのロードが大きいときに統計を更新しないでください。
表、列またはPL/SQLオブジェクトに相当な作成および変更がある場合は、統計を更新します。
データベースで相当数の表、列またはPL/SQLオブジェクトを作成または変更した場合、システム表SYS.TABLES、SYS.COLUMNSおよびSYS.OBJ$に対応したデータ・ディクショナリのオプティマイザ統計を更新する必要があります。
バルク・ロードや一括削除など、バッチ操作で表を大幅に変更する場合、バッチ操作の一環としてこれらの表の統計を収集できます。
表が増分的に変更されるだけの場合は、1週間に1回や1か月に1回程度の頻度で、統計を更新します。
トランザクション負荷が低い時間帯は、定期的に実行されるスクリプトまたはバッチ・ジョブの一環として統計を更新します。
複数の大規模な表の統計を更新する場合は、「大規模な表の表統計のパラレルでの更新」を参照してください。
|
ノート: パフォーマンス上の理由から、TimesTenでは、統計が計算される際に表または行のロックは保持されません。 |
統計を計算するために、ttIsql statsupdateコマンド、ttOptUpdateStatsまたはttOptEstimateStatsを使用します。表名として空の文字列を指定すると、現行ユーザーのスキーマ内のすべての表の統計が更新されます。
ttIsql内のstatsupdateコマンドは、対象の表の各行を評価し、正確な統計を計算します。
ttOptUpdateStats組込みプロシージャは、対象となる表のすべての行を評価し、正確な統計を計算します。
ttOptEstimateStats組込みプロシージャは、対象となる表の一部の行のみを評価し、見積り統計を計算します。これは高速に実行できますが、統計の正確性に劣ることがあります。10パーセントのサンプルで統計を計算すると、正確な統計を計算するより処理が約10倍速くなり、通常は同じ実行計画が生成されます。
|
ノート: ttIsqlまたは組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の「ttIsql」および「組込みプロシージャ」に関する説明を参照してください。 |
パフォーマンスへの影響: 大
すべてのTimesTen表で表統計を最新の状態に保つことは重要です。ただし、この処理を大規模な表で実行すると、時間がかかり、パフォーマンスに負荷がかかります。複数の大規模な表の統計を更新する場合は、ttOptUpdateStats組込みプロシージャをパラレルでコールすることを検討してください。
|
ノート: 100万行より少ない行が含まれている場合、TimesTen表は小規模な表とみなされます。1億行を超える行が含まれている場合、TimesTen表は大規模な表とみなされます。 |
表統計を更新する場合は、すべての大規模な表に対してttOptUpdateStats組込みプロシージャをコールします。それぞれのttOptUpdateStats組込みプロシージャをパラレルでコールしてください。ttOptUpdateStats組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttOptUpdateStatsに関する説明を参照してください。
Command> call ttOptUpdateStats('table1',0,0);
Command> call ttOptUpdateStats('table2',0,0);
...
...
Command> call ttOptUpdateStats('finaltable',0,0);
ttOptUpdateStats組込みプロシージャのコールが完了したら、表統計を更新した大規模なTimesTen表に対するトランザクションのアクセス数を確認します。トランザクション・ロード時間が短い間はttOptCmdCacheInvalidate('',1)組込みプロシージャを実行します。ttOptCmdCacheInvalidate組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttOptCmdCacheInvalidateに関する説明を参照してください。トランザクション・ロード時間が長いときに、次の組込みプロシージャを実行し、各ttOptCmdCacheInvalidate組込みプロシージャはパラレルでコールします。
Command> call ttOptCmdCacheInvalidate('table1',1);
Command> call ttOptCmdCacheInvalidate('table2',1);
...
...
Command> call ttOptCmdCacheInvalidate('finaltable',1);
表の表統計が更新され、SQLコマンド・キャッシュのコンパイルされたコマンドは無効になりました。
パフォーマンスへの影響: 不定
表統計を現在の状態にリストアできるttOptStatsExport組込みプロシージャを使用して、SQLスクリプトを生成できます。これらの文を適用する場合、同じ環境を再作成します。表統計の再作成は、SQLパフォーマンスの診断に使用できます。
ttOptStatsExport組込みプロシージャをコールして、表統計を現在の状態にリストアするために必要な一連の文を返します。表を指定しない場合、ttOptStatsExportは、コール元のユーザーがアクセス権限を持っているすべてのユーザー表についての表統計をリストアするために必要な一連の文を返します。
|
ノート: この組込みプロシージャの詳細および構文は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttOptStatsExport」を参照してください。 |
次の例では、employees表の統計をリストアするための実行に必要な一連の組込みプロシージャ・コマンドを返します。
Command> call ttOptStatsExport('hr.employees');
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'EMPLOYEE_ID', 0, (6, 0, 107, 107,
(20, 20, 1 ,100, 120, 101), (20, 20, 1 ,121, 141, 122), (20, 20, 1 ,142, 162,
143), (20, 20, 1 ,163, 183, 164), (20, 20, 1 ,184, 204, 185), (1, 1, 1 ,205, 206,
205))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'FIRST_NAME', 0, (1, 0, 89, 107,
(89, 107, 0, 'Adam', 'Winston', 'Adam'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'LAST_NAME', 0, (1, 0, 97, 107, (97,
107, 0, 'Abel', 'Zlotkey', 'Abel'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'EMAIL', 0, (6, 0, 107, 107, (20,
20, 1, 'ABANDA', 'DGREENE', 'ABULL'), (20, 20, 1, 'DLEE', 'JKING', 'DLORENTZ'),
(20, 20, 1, 'JLANDRY', 'LOZER', 'JLIVINGS'), (20, 20, 1, 'LPOPP', 'RMATOS',
'LSMITH'), (20, 20, 1, 'RPERKINS', 'WGIETZ', 'SANDE'), (1, 1, 1, 'WSMITH',
'WTAYLOR', 'WSMITH'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'PHONE_NUMBER', 0, (1, 0, 103, 107,
(103, 107, 0, '011.44.1343.329268', '650.509.4876', '011.44.1343.329268'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'HIRE_DATE', 0, (1, 0, 90, 107, (90,
107, 0 ,'1987-06-17 00:00:00', '2000-04-21 00:00:00', '1987-06-17 00:00:00'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'JOB_ID', 0, (4, 0, 19, 107, (11,
16, 5, 'AC_ACCOUNT', 'PR_REP', 'FI_ACCOUNT'), (3, 11, 30, 'PU_CLERK', 'SA_REP',
'SA_REP'), (1, 20, 20, 'SH_CLERK', 'ST_CLERK', 'ST_CLERK'), (0, 0, 5, 'ST_MAN',
'ST_MAN', 'ST_MAN'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'SALARY', 0, (1, 0, 57, 107, (57,
107, 0 ,2100, 24000, 2100))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'COMMISSION_PCT', 0, (1, 72, 7, 107,
(7, 35, 0 ,0.1, 0.4, 0.1))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'MANAGER_ID', 0, (1, 1, 18, 107,
(18, 106, 0 ,100, 205, 100))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'DEPARTMENT_ID', 0, (3, 1, 11, 107,
(4, 10, 45 ,10, 50, 50), (2, 6, 34 ,60, 80, 80), (2, 5, 6 ,90, 110, 100))); >
< call ttoptsettblstats('HR.EMPLOYEES', 107, 0); >
12 rows found.
パフォーマンスへの影響: 不定
TimesTenは、コンパイルされたコマンドをSQLコマンド・キャッシュにキャッシュします。これらのコマンドは無効化できます。無効になったコマンドは、通常、再実行される直前に再度自動的に準備されます。1つのコマンドが何度も準備されることがあります。
統計を計算するとき、特定の表にある同一のロックについて、コマンドの更新とコンパイルのプロセスが競合することがあります。複数のトランザクションで統計を収集していて、統計の更新ごとにコマンドを無効にしていると、次の問題が発生することがあります。
複数の表を参照する結合問合せが無効化され、2回以上再コンパイルされることがあります。
再コンパイルに必要なロックが統計の更新に差し支え、その結果デッドロックが発生することがあります。
これらの問題を回避するには、コマンドがSQLコマンド・キャッシュで無効化されるタイミングを制御します。さらに、表と索引の基数が今後大幅に変更されることがわかっている場合には、すべてのコマンドの無効化を延期することも考えられます。
コマンドの無効化は次のように制御できます。
SQLコマンド・キャッシュでコマンドを無効化せずに、統計を計算します。ttIsql statsupdateコマンド、ttOptUpdateStats組込みプロシージャまたはttOptEstimateStats組込みプロシージャで、invalidateオプションを0に設定します。
すべての統計がttOptCmdCacheInvalidate組込みプロシージャでコンパイルされたら、SQLコマンド・キャッシュ内でコマンドを手動で無効にします。
ttOptCmdCacheInvalidate組込みプロシージャを使用すると、ある表のみに関連付けられたコマンドや、SQLコマンド・キャッシュ内にあるすべてのコマンドを無効化できます。さらに、無効化したコマンドを再コンパイルするか、使用不可としてマークするかを指定できます。
|
ノート: 統計を最適に計算するタイミングの詳細は、「正確な統計または推定統計の計算」を参照してください。また、『Oracle TimesTen In-Memory Databaseリファレンス』のttIsql、ttOptUpdateStats、ttOptEstimateStatsまたはttOptCmdCacheInvalidateに関する項を参照してください。 |
パフォーマンスへの影響: 不定
アプリケーションでALTER TABLE文を使用すると、表に対して列の追加および破棄を実行することができます。ALTER TABLE文自体は、ほとんどの場合、非常に高速に実行できますが、これによって表に加えられた変更が原因で、表の後続のDML文および問合せの実行に時間がかかることがあります。アプリケーションで発生する実際のパフォーマンスの低下の程度は、表の変更回数および表に対して実行される処理の種類によって異なります。
VARCHAR2列およびVARBINARY列の削除は、削除対象の列内の既存のVARCHAR2値およびVARBINARY値に割り当てられている領域を解放するために、表をスキャンする必要があるため、他のデータ型の列の削除より時間がかかります。
パフォーマンスへの影響: 不定
多くの行の実体化が必要な問合せのネストを回避するため、可能でばれば問合せをリライトすることをお薦めします。
次のネストした問合せの例では、実体化が必要になり、多くの行が作成される場合があります。
GROUP BYを使用するネストした集合問合せ
ROWNUMを参照するネストした問合せ
UNION、INTERSECTまたはMINUSを使用するネストした問合せ
ORDER BYを使用するネストした問合せ
たとえば、次のネストした集合問合せによって、パフォーマンスに大きく影響します。
Command> SELECT * FROM (SELECT SUM(x1) sum1 FROM t1 GROUP BY y1), (SELECT sum(x2) sum2 FROM t2 GROUP BY y2) WHERE sum1=sum2;
次に、ROWNUMを参照するネストした問合せの例を示します。
Command> SELECT * FROM (SELECT rownum rc, x1 FROM t1 WHERE x1>100), (SELECT ROWNUM rc, x2 FROM t2 WHERE x2>100) WHERE x1=x2;
次に、UNIONを使用するネストした問合せの例を示します。
Command> SELECT * FROM (SELECT x1 FROM t1 UNION SELECT x2 FROM t2), (SELECT x3 FROM t3 GROUP BY x3) WHERE x1=x3;
副問合せの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の副問合せに関する説明を参照してください。
パフォーマンスへの影響: 大
同じ文を複数回生成し、その生成のたびに異なる値を検索するアプリケーションが存在する場合は、パラメータ化した文を準備して、コンパイル時間を短縮します。たとえば、アプリケーションで次のような文が生成されるとします。
SELECT A FROM B WHERE C = 10; SELECT A FROM B WHERE C = 15;
これらの文は、次の単一の文に置き換えることができます。
SELECT A FROM B WHERE C = ?;
TimesTenでは、準備済の文はコミットされると自動的に共有されます。したがって、文の実行を準備するためのアプリケーションによるリクエストは、その文の準備済バージョンがすでにシステムに存在する場合は非常に高速に処理されます。また、同じ文を実行するリクエストを繰り返し行う場合は、その文の事前準備済バージョンを共有することによって、準備でのオーバーヘッドを回避できます。
TimesTenで準備済の文を共有できる場合でも、パフォーマンス上の理由から、パラメータ化した文を使用することをお薦めします。パラメータ化した文を使用すると、文の共有による軽減に加えて、準備でのオーバーヘッドをさらに軽減することができます。
パフォーマンスへの影響: 大
SQL文の準備は高コストの処理であるため、アプリケーションでは準備APIのコール回数を最小限にする必要があります。ほとんどのアプリケーションでは、接続の開始時に一連の文を準備し、接続中にこれらの文を使用します。この方法は、数百または数千のトランザクションで構成されている長時間の接続に適しています。ただし、接続が比較的短時間の場合でも、すべてのスレッドまたはプロセスのために文を準備して実行する長時間の接続を確立することをお薦めします。この場合、通信でのオーバーヘッドと準備でのオーバーヘッドのバランスを考慮する必要があり、アプリケーションごとに調べることができます。準備済の文は、接続がクローズされると無効になります。
関連情報については、『Oracle TimesTen In-Memory Databaseリファレンス』のttSQLCmdCacheInfoGetに関する説明を参照してください。
パフォーマンスへの影響: 大
TimesTenには、パフォーマンスは低下しますが、データをより効率的に保存する、列レベルでの表圧縮機能があります。この仕組みでは、列の値の重複による表内の冗長な領域が排除され、表の領域が削減されるので、全表スキャンを実行するSQL問合せのパフォーマンスが向上します。
TimesTen表の列を圧縮する場合は、次の点を考慮してください。
国または州の名前などの全体にわたって値が繰り返されている場合は、列を圧縮します。
複数の列に同時に頻繁にアクセスする場合は、列を圧縮します。
TT_TINYINTなどの少量の記憶域を必要とするデータ型を含む列は圧縮しません。
TimesTenはNULL値を圧縮しません。
表の圧縮される1つ以上の列(圧縮列グループと呼ばれる)を定義できます。各表に1つ以上の圧縮列グループを定義できます。
各圧縮列グループに対して、圧縮列グループのすべての個別値の列を含むディクショナリ表が作成されます。圧縮列グループには、ディクショナリ表の適切な値の行へのポインタが含まれます。このポインタの幅は、ディクショナリ表に対して定義した最大エントリ数に応じて、1、2または4バイトです。そのため、圧縮されている列グループ内の列の幅の合計が、1、2または4バイトのポインタの幅より広い場合、およびこれらの列値に多くの重複する値が存在する場合は、表で使用される領域を削減しました。
図10-1に、ディクショナリ表内の適切な行を指す、表内の圧縮列グループを示します。
ディクショナリ表には、各個別値へのポインタの列があります。ユーザーが圧縮列グループの個別エントリの最大数を構成すると、圧縮列グループのサイズが次のように設定されます。
エントリの最大数が255(28-1)の場合は1バイト。最大数が1から255の場合、ディクショナリのサイズは255(28-1)に設定され、圧縮列グループのポインタ列は1バイトになります。
エントリの最大数が65,535(216-1)の場合は2バイト。最大数が256から65,535の場合、ディクショナリのサイズは65,535(216-1)に設定され、圧縮列グループのポインタ列は2バイトになります。
エントリの最大数が4,294,967,295(232-1)の場合は4バイト。最大数が65,536から4,294,967,295の場合、ディクショナリのサイズは4,294,967,295(232-1)に設定され、圧縮列グループのポインタ列は4バイトになります。これがデフォルトです。
圧縮列グループは、表の作成時に追加するか、ALTER TABLE文を使用して後で追加できます。ALTER TABLE文を使用して、圧縮列グループ全体を削除できます。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER TABLEに関する説明およびCREATE TABLEに関する説明を参照してください。
ttSize組込みプロシージャをコールして、TimesTenが圧縮された表に対して実行した圧縮のレベルを確認できます。ttSize組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttSizeに関する説明を参照してください。
パフォーマンスへの影響: 不定
TimesTenは読取り処理および書込み処理を同時に最適に処理します。ttOptSetFlag ('tblLock',1)などのトランザクション・レベル・オプティマイザ・ヒントまたは/*+ tt_tbllock(1) tt_rowlock(0) */などの文レベル・オプティマイザ・ヒントを使用すると、読取り専用同時実行性に対して読取り処理を最適化できます。読取り最適化問合せと同時に処理する書込み処理は競合する可能性があります。
ttDBWriteConcurrencyModeSet組込みプロシージャにより、同時書込み処理時に読取り最適化を制御できます。この組込みプロシージャにより、標準モードと拡張書込み同時モードを切り替えることができます。標準モードでは、オプティマイザは読取り最適化のヒントを考慮します。拡張書込み同時モードでは、オプティマイザは読取り最適化のヒントを無視し、共有の読込み表ロックまたは書込み表ロックを使用しません。
|
ノート: 表ロックの詳細は、「ロックの粒度」を参照してください。オプティマイザ・ヒントの詳細は、「オプティマイザ・ヒントを使用して実行計画を変更する」を参照してください。 トランザクション・レベル・オプティマイザ・ヒントの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttOptSetFlagに関する説明を参照してください。 |
ttDBWriteConcurrencyModeSet組込みプロシージャのmodeを1に設定して、拡張書込み同時モードを有効にし、読取り最適化を無効にします。modeを0に設定して、拡張書込み同時モードを無効にし、読取り最適化を再有効化します。
modeを1に設定すると、すべてのトランザクションおよび文の表ロック・オプティマイザ・ヒントが無視されます。これは次に影響します。
SELECT問合せの共有読取り表レベル・ロックおよびオプティマイザ・ヒントでトリガーされる副問合せ。
オプティマイザ・ヒントでトリガーされるDML文の書込み表ロック。
modeの設定にかかわらず、オプティマイザ・ヒントでトリガーされない表ロックは影響を受けません。
ttDBWriteConcurrencyModeSet組込みプロシージャのwaitを0に設定して、通知せずにモード切替えを実行します。ttDBWriteConcurrencyModeSet組込みプロシージャのwaitを1に設定して、モード切替えが完了するまで組込みプロシージャが待機するように強制します。
特定のSQL文を実行するとttDBWriteConcurrencyModeSet組込みプロシージャのモードが移行中のままになります。このようなSQL文は次の2つの条件に一致します。
書込み同時実行モードの影響を受ける場合。
異なる書込み同時実行モードでコンパイルされた場合。
ttDBWriteConcurrencyModeSet組込みプロシージャのモードは、このようなSQL文がすべて完了するまで移行中のままになります。ttDBWriteConcurrencyModeSet組込みプロシージャは、モード移行時にロック取得を使用して待機します。ttDBWriteConcurrencyModeSet組込みプロシージャが現在の接続のタイムアウト時間内にロックを許可されない場合、エラーが返されます。
|
ノート: ttDBWriteConcurrencyModeSet、ttLockWait、ttDBWriteConcurrencyModeGet組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDBWriteConcurrencyModeSetに関する項、ttLockWaitに関する項およびttDBWriteConcurrencyModeGetに関する項を参照してください。 |
パフォーマンスへの影響: 不定
タイムアウト値を設定する場合は、次の属性間の関係を考慮してください。
SQLQueryTimeoutまたはSQLQueryTimeoutMSec: SQL文がタイムアウトする前に実行される時間の長さを制御します。
デフォルトでは、SQL文はタイムアウトしません。場合によっては、SQLQueryTimeoutまたはSQLQueryTimeoutMSec接続属性の値を指定して、時間制限を秒またはミリ秒単位で設定し、この制限内でデータベースのSQL文が実行されるようにできます。(これは、問合せだけでなく、すべてのSQL文に適用されることに注意してください。)
SQLQueryTimeoutおよびSQLQueryTimeoutMsec属性はどちらも、1つのタイムアウト値(ミリ秒)に内部的にマップされます。これらの属性に異なる値が指定された場合は、1つの値のみが保持されます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のSQLQueryTimeoutに関する項およびSQLQueryTimeoutMSecに関する項を参照してください。
PLSQL_TIMEOUT: PL/SQLブロックがタイムアウトする前に実行される時間の長さを制御します。
デフォルトでは、PL/SQLプログラム・ユニット(PL/SQLプロシージャ、無名ブロックおよび関数)は、自動的に終了されるまで30秒間実行できます。場合によっては、PL/SQLプログラム・ユニットの追加時間を実行できるようにPLSQL_TIMEOUT接続属性値を変更します。実行時にALTER SESSION文を使用してこの属性を変更することもできます。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のPLSQL_TIMEOUTに関する項を参照してください。
TTC_Timeout: TimesTen ClientがTimesTen ServerにSQL文またはPL/SQLブロックの実行をリクエストしたときにTimesTen ClientがTimesTen Serverからのレスポンスを待機する時間の長さを制御します。
TTC_ConnectTimeout: SQLDriverConnectリクエストまたはSQLDisconnectリクエストをクライアントが待機する時間を制御します。これは、それらのリクエストに対するTTC_Timeoutの値を上書きします。
「クライアントのタイムアウト接続属性の選択」も参照してください。
TimesTen Client/Serverを使用する場合、SQLQueryTimeout(またはSQLQueryTimeoutMSec)およびPLSQL_TIMEOUT (PL/SQLに関連する)をTTC_Timeoutより大幅に小さい値に設定して、クライアントが誤ってレスポンスのないサーバーに対してSQL文またはPL/SQLブロックを長時間実行しないようにします。
PL/SQLを使用する場合、SQLQueryTimeout (またはSQLQueryTimeoutMSec)とPLSQL_TIMEOUTの間の関係は、PL/SQLブロックで使用するSQL文の数によって異なります。ない場合、関係はありません。PL/SQLブロック内のSQL文の最大数がnである場合、PLSQL_TIMEOUTは少なくともn x SQLQueryTimeout (またはn x 1000 x SQLQueryTimeoutMSec)である必要があります(PL/SQLでの処理時間の考慮を含む)。
|
ノート: SQLQueryTimeout (またはSQLQueryTimeoutMSec)およびPLSQL_TIMEOUTがTTC_Timeoutより十分小さい値に設定されていない場合に、クライアントが誤ってレスポンスのないサーバーに対してSQL文またはPL/SQLブロックを長時間実行して接続を終了すると、サーバーが接続の終了を検知した時点ですぐにSQL文またはPL/SQLブロックが取り消されます。 |
次の項では、マテリアライズド・ビューのパフォーマンスの向上に関するヒントを示します。
パフォーマンスへの影響: 不定
結合行の数が多くなると、パフォーマンスが低下します。結合条件を制御することで、結合行の数および結合される表の数を制限できます。たとえば、ある表の1行を他の表の1行または最大数行にマップする一致条件のみを使用します。
パフォーマンスへの影響: 不定
結合を作成するSELECT文に指定されているディテール表の列に対して索引を作成します。また、マテリアライズド・ビュー自体に対して索引を作成することも検討します。これによって、マテリアライズド・ビューを継続して更新する場合のパフォーマンスを向上させることができます。
ディテール表でのUPDATEまたはDELETE処理が列に対する条件に基づくことが多い場合、可能であれば、その列でマテリアライズド・ビューの索引の作成を試行します。
たとえば、cust_orderは、2つの表に基づいた顧客注文のマテリアライズド・ビューです。それらの表は、customerおよびbook_orderです。前者には2つの列(cust_idおよびcust_name)があり、後者には3つの列(order_id、bookおよびcust_id)があります。特定の注文を変更するために、条件book_order.order_id=constを使用してbook_order表を更新することが多い場合は、cust_order.order_idの索引を作成します。また、条件book_order.cust_id=constに基づいて更新することが多い場合は、Cust_order.cust_idの索引を作成します。
両方の条件を使用して更新することが多く、両方の索引を作成する十分な領域がない場合は、ビューにbook_order.ROWIDを追加し、これに対して索引を作成します。この場合、TimesTenは、ビュー内のすべての行を直接同時に更新するのではなく、ディテール行の更新ごとにビューを更新します。更新する行を検索するスキャンは行スキャンではなく索引スキャンであるため、結合行を生成する必要はありません。
実行計画でViewUniqueMatchScanが使用されている場合、実行速度が遅くなったり、実行に必要以上の領域が必要になる場合があります。ViewUniqueMatchScanは、マテリアライズド・ビューの直接更新または直接削除に変換できない更新または処理に使用され、結合行とマテリアライズド・ビュー内の関連行間に一意のマッピングは存在しません。これは、更新または削除される各ディテール表に対して一意キーを選択すると修正できます。
パフォーマンスへの影響: 不定
結合列またはGROUP BY列の更新には古い値の削除および新しい値の挿入を実行する必要があるため、結合列の更新は行わないようにしてください。
複数の表を参照する式の更新は行わないようにしてください。この式の中のある値が更新されると、新しい値を取得する別の結合処理がTimesTenによって実行される可能性があるため、ビューを直接更新できなくなる場合があります。
次のいずれかの場合、更新または削除に基づくビュー・メンテナンスにより多くのコストがかかります。
ビューを直接更新できない場合。たとえば、ディテール表のUPDATEまたはDELETE文に指定されているすべての列がビューで選択されているわけではありません。
ビューの行から結合行への1対1マッピングの指示がない場合。
次に例を示します。
Command> CREATE MATERIALIZED VIEW v1 AS SELECT x1 FROM t1, t2 WHERE x1=x2; Command> DELETE FROM t1 WHERE y1=1;
結合行によって1つのビュー行のみが影響を受けるようにするために追加の処理が必要であるため、追加のコストがかかります。
この問題は、x1がUNIQUEであるか、またはt1の一意キーがビューの選択リストに含まれている場合は解決されます。ROWIDは、常に一意キーとして使用できます。
パフォーマンスへの影響: 不定
内部表に対して変更を行うと、外部結合のメンテナンスにより多くのコストがかかるため、外部結合の内部表への変更は行わないようにしてください。可能な場合は、内部表でINSERT処理を実行してから、関連する結合行を外部表に挿入します。同様に、可能な場合は、外部表でDELETE処理を実行してから、内部表での削除を実行してください。これによって、一致しない行を一致する行に変換したり、その逆の処理を行う必要がなくなります。
パフォーマンスへの影響: 不定
ビューSelectListに投影される列の数はパフォーマンスに影響する可能性があります。選択リスト内の列の数が増えると、ディテール表に対する処理の準備時間が長くなります。また、ビューのディテール表に対する処理の実行時間も長くなります。必要のない値または式は選択しないでください。
ビューのディテール表に対する処理を準備する際に、オプティマイザは一時索引の使用を検討します。これは、処理およびビューによっては、準備時間を大幅に長くする可能性があります。準備時間が長い場合は、ttOptSetFlagを使用して、一時範囲索引および一時ハッシュ・スキャンを無効にすることを検討してください。
次の項では、トランザクション使用時のパフォーマンスを向上させる方法について説明します。
パフォーマンスを向上させるために、チェックポイント・ファイルがある物理デバイスとは別の物理デバイスにトランザクション・ログ・ファイルを配置します。ログ・ファイルの保存場所は、LogDir接続属性によって決定されます。詳細は、本書の「トランザクション・ログ・バッファおよびファイルの管理」または『Oracle TimesTen In-Memory Databaseリファレンス』のLogDirに関する説明を参照してください。
パフォーマンスへの影響: 大
トランザクション・ログ・レコードを生成する各トランザクション(INSERT、DELETEまたはUPDATEを実行するトランザクションなど)では、コミット時にファイル・システム書込み処理が発生します。ファイル・システムI/Oは、レスポンス時間に影響を及ぼし、グループ・コミットの有効性によっては、スループットに影響を及ぼす可能性があります。
パフォーマンスを重視するアプリケーションでは、コミット時に不要なファイル・システム書込み処理を回避する必要があります。パフォーマンス分析ツールを使用して、アプリケーションでファイル・システム書込み処理にかかる時間を(CPU時間と比較して)測定します。I/Oが過剰であると思われる場合は、次の2つのステップを実行してコミット時に書込みが行われないようにできます。
トランザクション・サイズを調整します。
トランザクションのコミット時にファイル・システム書込み処理を実行するかどうかを調整します。詳細は、「永続コミットの適切な使用」を参照してください。
長時間のトランザクションでは、短時間のトランザクションと比較して単位時間当たりのファイル・システム書込み処理が少なくなります。ただし、長時間のトランザクションによって、同時実行性が低くなる可能性もあります(第7章「トランザクション管理」を参照)。
パフォーマンスへの影響: 大
デフォルトでは、TimesTenのトランザクションをコミットするたびに、ファイル・システム書込み処理が発生します。これによって、システムまたはアプリケーションで障害が発生した場合でも、コミット済のトランザクションは失われなくなります。非永続コミットを実行すると、アプリケーションでこれらのファイル・システム書込み処理の一部またはすべてを回避できます。非永続コミットでは、トランザクション・ログをファイル・システムに書き込むことを除き、永続コミットで実行されるすべての処理が実行されます。ロックは解放され、カーソルはクローズされますが、ファイル・システム書込み処理は実行されません。
|
ノート: 一部のドライバは、キャッシュ・メモリーへのデータの書込みも、ファイル・システムへの書込みも、オペレーティング・システムが書込み完了通知を受け取って一定時間が経過してから行います。この場合、停電が発生すると、永続コミットしたと思われていた一部の情報が失われる可能性があります。このようなデータの損失を回避するには、完了通知の前に記録メディアに書き込むようにファイル・システムを構成するか、または無停電電源装置を使用します。 |
非永続コミットのメリットは、レスポンス時間を減らし、スループットを向上させることができることです。デメリットは、システムで障害が発生した場合に、一部のトランザクションが失われる可能性があることです。アプリケーションでは、定期的に永続コミットまたはチェックポイントを実行してトランザクション・ログを強制的にファイル・システムに永続化することによって、失われる可能性があるデータの量を減らすことができます。また、TimesTen自体でも、内部バッファが一杯になった場合にトランザクション・ログをファイル・システムに定期的にフラッシュしているため、失われる可能性があるデータの量が制限されます。
トランザクションは、接続ごとに永続的にすることも、非永続的にすることもできます。アプリケーションでttDurableCommitプロシージャをコールして、特定のトランザクションの永続コミットを強制実行できます。
永続コミットを使用するアプリケーションでは、書込みおよびフラッシュのかわりに同期書込みを使用することをお薦めします。同期書込みを有効にするには、初期接続属性LogFlushMethod=1を設定します。LogFlushMethod属性は、TimesTenでデータをトランザクション・ログ・ファイルに書き込む方法および同期する方法を制御します。アプリケーションのパフォーマンスはこの属性によって影響を受ける場合がありますが、トランザクションの永続性は影響を受けません。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のLogFlushMethodに関する項を参照してください。
SYS.SYSTEMSTATS表のtxn.commits.durable列は、永続コミットを実行したトランザクションの数を示します。
パフォーマンスへの影響: 大
手動チェックポイントは、TimesTen Classicにのみ適用されます。手動チェックポイントは、TimesTen Scaleoutではサポートされていません。
可能な場合は、手動チェックポイントの実行を回避することをお薦めします。バックグラウンド・チェックポイントは、ttCkptConfig組込みプロシージャを使用して構成する必要があります。バックグラウンド・チェックポイントはほとんど影響がなく、非ブロッキング(ファジー)チェックポイントを使用します。
手動チェックポイントが必要な場合、通常はttCkptをコールして非ブロッキング(ファジー)チェックポイントを実行する方が、ttCkptBlockingをコールしてブロッキング・チェックポイントを実行するより効率的です。ブロッキングまたは(トランザクション一貫性)チェックポイントは、データベースへの排他アクセスが必要であるため、パフォーマンスに大きな影響を与える可能性があります。非ブロッキング・チェックポイントの方が時間がかかる可能性がありますが、他のトランザクションでデータベースに対して同時に処理を実行できるため、全体的なオーバーヘッドを抑えることができます。連続するチェックポイント間の間隔(ttCkptConfig組込みプロシージャのckptLogVolumeパラメータ)を増やすには、トランザクション・ログ・ファイルの蓄積に使用できるファイル・システム領域の量を増やします。
トランザクション・ログのサイズが大きくなると(チェックポイント間の間隔が長い場合)、リカバリ時間もそれに応じて長くなります。システム・クラッシュまたはアプリケーション障害後のリカバリ時間を減らす必要がある場合は、ttCkptConfig組込みプロシージャを適切にチューニングすることが重要です。SYS.SYSTEMSTATS表のckpt.completed列は、チェックポイント処理が正常に実行された回数を示します。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCkptConfigに関する項を参照してください。
パフォーマンスへの影響: 大
AUTOCOMMITモードはデフォルトで有効になっており、文ごとにコミットが実行されます。ただし、文を実行するたびにコミットを実行すると、パフォーマンスが大幅に低下する可能性があります。このため、通常は、プログラム環境に適したAPIを使用して、AUTOCOMMITを無効にすることをお薦めします。
SYS.SYSTEMSTATS表のtxn.commits.count列は、トランザクションのコミット数を示します。
|
ノート: アプリケーションで明示的なコミットを指定しなかった場合、メモリー、ロックなどの重要なリソースを不必要に使い果たしてしまう可能性があります。すべてのアプリケーションで、定期的なコミットを実行する必要があります。 |
パフォーマンスへの影響: 大
誤ったデータまたはアプリケーション障害のためトランザクションに問題が発生した場合、トランザクションはTimesTenによって自動的にロールバックされます。また、アプリケーションでは、多くの場合、トランザクションのロールバックが明示的に実行され、デッドロックまたはタイムアウトの状態からリカバリされます。これは、パフォーマンスの観点から見ると、ロールバックはリソースを浪費し、トランザクション全体が無駄になってしまうため望ましくありません。
アプリケーションでは、不要なロールバック操作が行われないようにする必要があります。つまり、可能なかぎり、競合が発生しないようにアプリケーションを設計し、アプリケーションまたは入力データを事前にチェックしてエラーを検出する必要があります。SYS.SYSTEMSTATS表のtxn.rollbacks列は、ロールバックされたトランザクションの数を示します。
パフォーマンスへの影響: 大
大量のDELETE文を回避するために次のような方法を考慮します。
1つのSQL文で表から(100,000以上)大量の行を削除しようとすると、処理に時間がかかる場合があります。TimesTenでは、処理でロールバックが必要な場合に備えて削除された各行を記録しますが、ファイル・システムへのすべてのトランザクション・ログ・レコードの書込みには非常に時間がかかります。
このような大量のDELETE処理のもう1つの問題は、書込み集中型の削除トランザクションの発生中は他のデータベース操作が遅くなることです。1つのトランザクションで何百万行も削除するには、完了するまでに数分かかります。
何百万もの行を一度に削除することによる別の問題は、この表がレプリケートされるときに発生します。レプリケーションではコミット済のトランザクションのみが転送されるため、単一の、数百MB (またはGB)からなるトランザクションを転送することでレプリケーション・エージェントが遅くなります。TimesTenのレプリケーションは、多数の小規模なトランザクション用に最適化されているため、何百万もの行が1つのトランザクションで削除されるとパフォーマンスが低下します。
DELETE SQL文の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のDELETEに関する説明を参照してください。
大量の行を削除する必要があり、TRUNCATE TABLEが適切でない場合は、DELETE FIRST NumRows句を使用して表から行をバッチで削除することを検討します。DELETE FIRST NumRows構文では、「DELETE FROM TableName WHERE . . .」を一連の「DELETE FIRST 10000 FROM TableName WHERE . . .」操作に変更できます。
大量のDELETE操作をより小さい操作のバッチに分割することで、行ははるかに高速に削除され、システムおよびレプリケーション全体の同時実行性は影響を受けません。
DELETE FIRST句の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のDELETEに関する説明を参照してください。
パフォーマンスへの影響: 大
トランザクションのコミットの再要求段階の間に、TimesTenのリソース・クリーンアップが発生します。再利用要求の間、TimesTenはトランザクションの開始時点からのすべてのトランザクション・ログ記録を再調査し、実行する必要がある再利用要求操作を決定します。
大きなトランザクション・コミットの再利用要求段階では大量の処理が必要になり、リソースを大量に消費します。ただし、コミット・バッファの最大サイズを増やすことでパフォーマンスを向上させることができます。コミット・バッファとは、再利用要求操作で使用されるトランザクション・ログ記録のキャッシュです。
TimesTenのCommitBufferSizeMax接続属性を使用して、コミット・バッファの最大サイズをMB単位で指定できます。この設定のスコープは、現在のセッションです。
詳細は、「コミット・バッファの再利用操作用の構成」を参照してください。
次の項では、データベースのシャットダウン後またはシステム障害の発生後に、データベース・リカバリのパフォーマンスを向上させるためのヒントを示します。
パフォーマンスへの影響: 大
RecoveryThreadsは、データベース・リカバリ時に索引の再構築に使用されるパラレル・スレッド数を定義します。パフォーマンス上の理由から、TimesTenは索引の変更内容を記録しません。クラッシュが発生した場合は、すべての索引を再構築する必要があります。索引の再構築時間を短縮するには、RecoveryThreads属性をCPUの数に設定してリカバリのパフォーマンスを向上させます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のRecoveryThreadsに関する項を参照してください。
パフォーマンスへの影響: 大
データベースに大量のチェックポイント・ファイル(数GB単位)がある場合、初期接続またはリカバリ操作が十分に機能せず、極端な場合には完了までに数時間もかかることがあります。リカバリのパフォーマンスを改善するには、CkptReadThreads接続属性を使用して、データベースをメモリーにロードする際にチェックポイント・ファイルの読込みに使用される同時スレッドの数を増やします。これにより、パラレル・スレッドがTimesTenデータベース・チェックポイント・ファイルを読み取ることができるようになるため、TimesTenデータベースをメモリーにロードする時間が短縮されます。
CkptReadThreads属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptReadThreadsに関する項を参照してください。
次の項では、複数CPUのパフォーマンスの向上に関するヒントを示します。
パフォーマンスへの影響: 不定
TimesTenで実行される概算スケーリングを確認する方法の1つとして、使用しているシステムでいずれかのスケーラブル・デモ・アプリケーション(tptbmなど)を実行する方法があります。
tptbmアプリケーションには、マルチユーザーのスループット・ベンチマークが実装されています。これでは、TimesTen処理およびSELECT、UPDATE、INSERTなどを組み合せたトランザクションを実行するプロセス数を変更するオプションを含め、その実行方法を制御できます。tptbm -helpを実行すると、オプションの完全なリストが表示されます。
デフォルトでは、このデモは、トランザクションごとに1つの処理を実行します。トランザクションごとの処理数を増やして、実際のアプリケーションに近づけることができます。トランザクションが大きくなると、アプリケーションのプロファイルによって、スケーラビリティが向上する場合と低下する場合があります。
このデモのマルチプロセッサ・バージョンを実行すると、複数CPUシステムでのアプリケーションのパフォーマンスを予測して評価できます。デモでのスケーラビリティが高く、アプリケーションでのスケーラビリティが低い場合は、アプリケーションを簡略化して問題の箇所を確認します。TimesTenのコールをコメント・アウトしても、アプリケーションに問題があるためスケーリングが不十分なままになる場合があります。
また、たとえば、シミュレートされたアプリケーション・データの一部が正しく生成されていないため、数行の同じ行がすべての処理でアクセスされていることが発見される場合があります。アクセスでデータが変更される場合、そのタイプのローカライズされたアクセスは、スケーラビリティを大幅に阻害することになります。
tptbmおよびその他のデモ・アプリケーションの詳細は、クイック・スタートのホームページ(installation_dir/quickstart.html)を参照してください。「Sample Programs」の下のODBCリンクに移動してください。
パフォーマンスへの影響: 不定
SYS.SYSTEMSTATS表のlock.timeoutsフィールドまたはlock.locks_granted.waitフィールドを確認します。これらの値が大きい場合は、過度の競合が発生している可能性を示し、スケーリングが不十分になることがあります。
TimesTenはCPU集中型であるため、CPU当たりのデータベース集中型の接続の数を1つのみにすることで、最適なスケーリングが実現されます。4CPUシステムまたはハイパースレッド機能を持つ2CPUシステムを使用する場合、4プロセッサ・アプリケーションのパフォーマンスは良好ですが、8プロセッサ・アプリケーションのパフォーマンスは低くなります。アクティブなスレッド間での競合が多くなりすぎます。ただし、多くのトランザクションが永続的にコミットされる場合、このルールは適用されません。この場合、ファイル・システムへのI/O操作が増加するために接続が極度にCPU集中型にはならず、システムでより多くの同時接続をサポートできるようになります。
パフォーマンスへの影響: 不定
読取り処理のスケーラビリティは、書込み処理より優れています。読取りと書込みのバランスが、アプリケーションの実際のワークロードを反映していることを確認してください。
パフォーマンスへの影響: 不定
準備はリソースを大量に消費する操作であり、SQL実行操作よりもスケーラビリティがありません。可能なかぎり、パラメータ化されたSQL文を使用し、常に、複数回実行される文を事前に準備してください。SYS.SYSTEMSTATS表のstmt.prepares.count列は、アプリケーションによって文が直接準備された頻度を示します。stmt.prepares.count列の値が大きい場合は、次のことを確認します。
アプリケーションでパラメータ化された文が使用されています。
アプリケーションでは該当するSQL文を1回のみ準備し、単一の実行ごとには準備していません。
アプリケーションではデータベースから頻繁に接続および切断しません。している場合は、存続期間が長い接続を使用することを検討してください。
接続および切断操作は、リソースを大量に消費し、スケーラビリティを損なう操作となります。アプリケーションでの接続および切断操作の数を最小化してください。パフォーマンスを高めるために、存続期間が長い接続で、パラメータ化され、事前準備されたSQL文を使用します。
アプリケーションで頻繁な接続および切断操作を回避できない場合、または存続期間が長い接続を使用するようにアプリケーションを変更できない場合は、接続プーリングを使用することを検討してください。接続プーリングは、接続および切断操作の頻度を減らし、アプリケーションがデータベースから頻繁に接続および切断する場合よりも準備済の文の利用率を向上させることができます。
パフォーマンスへの影響: 不定
マルチプロセッサ・システムでは、RecoveryThreadsを最小値(使用可能なCPUの数、索引の数)に設定すると、リカバリが必要な場合に、索引をパラレルで再構築できるようになります。再構築が必要な場合、進行状況はユーザー・ログで確認できます。RecoveryThreadsを使用可能なCPUの数より大きい値に設定すると、リカバリに必要な時間が、シングルスレッドの場合より長くなります。
次の項では、XLAのパフォーマンスの向上に関するヒントを示します。
パフォーマンスへの影響: 大
XLAを使用する場合は、トランザクション・ログ・バッファのサイズを大きくすることをお薦めします。XLAが有効になっている場合は、XLAに関する追加情報を格納するために追加のトランザクション・ログ・レコードが生成されます。トランザクション・ログ・バッファのサイズが適切かどうかを確認するには、SYS.MONITOR表のエントリLOG_FS_READSおよびLOG_BUFFER_WAITSの変更に注意します。パフォーマンスを最適にするには、この2つの値が0のままである必要があります。これらの値を0のままにするには、トランザクション・ログ・バッファのサイズの増加が必要な場合があります。トランザクション・ログ・バッファのサイズを変更する方法の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のLogBufMBに関する項を参照してください。
パフォーマンスへの影響: 中
複数の更新レコードを一度にプリフェッチする処理は、XLAから各更新レコードを個々に取得する処理より効率的です。AUTO_ACKNOWLEDGEモードを使用すると、更新がプリフェッチされないため、他のモードよりも時間がかかります。可能な場合は、更新を重複して行うことができるようにアプリケーションを設計すると、DUPS_OK_ACKNOWLEDGEの使用、または更新の明示的な確認が可能になります。各メッセージを個々に確認しないことがアプリケーションで許容される場合は、明示的に更新を確認すると、最も高いパフォーマンスを得ることができます。
レプリケーション・スキーム使用時のパフォーマンス向上に関する推奨事項は、『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』のレプリケーションのパフォーマンス向上に関する項を参照してください。
キャッシュ・グループ使用時のパフォーマンス向上に関する推奨事項の詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』の「キャッシュ・パフォーマンス」を参照してください。
