トランザクションのチューニング

別々の物理デバイスへのチェックポイント・ファイルとトランザクション・ログ・ファイルの配置

パフォーマンスを向上させるために、チェックポイント・ファイルがある物理デバイスとは別の物理デバイスにトランザクション・ログ・ファイルを配置します。ログ・ファイルの保存場所は、LogDir接続属性によって決定されます。

このマニュアル内の「トランザクション・ログのバッファおよびファイルの管理」、および『Oracle TimesTen In-Memory Databaseリファレンス』のLogDirを参照してください。

トランザクション・サイズの適切な設定

パフォーマンスへの影響: 大

トランザクション・ログ・レコードを生成する各トランザクション(INSERT、DELETEまたはUPDATEを実行するトランザクションなど)では、コミット時にファイル・システム書込み処理が発生します。ファイル・システムI/Oは、レスポンス時間に影響を及ぼし、グループ・コミットの有効性によっては、スループットに影響を及ぼす可能性があります。

パフォーマンスを重視するアプリケーションでは、コミット時に不要なファイル・システム書込み処理を回避する必要があります。パフォーマンス分析ツールを使用して、アプリケーションでファイル・システム書込み処理にかかる時間を(CPU時間と比較して)測定します。I/Oが過剰であると思われる場合は、次の2つのステップを実行してコミット時に書込みが行われないようにできます。

トランザクション・サイズを調整します。
トランザクションのコミット時にファイル・システム書込み処理を実行するかどうかを調整します。「永続コミットの適切な使用」を参照してください。

長時間のトランザクションでは、短時間のトランザクションと比較して単位時間当たりのファイル・システム書込み処理が少なくなります。ただし、長時間のトランザクションによって、同時実行性が低下する可能性があります。「トランザクション管理」を参照してください。

データベースでアクティブな接続が1つのみの場合、長時間のトランザクションによってパフォーマンスが向上する可能性があります。ただし、長時間のトランザクションには、ロールバック操作が長時間になるなどのデメリットがあります。
複数の接続が存在する場合は、トランザクション・ログのI/Oによる遅延とロックによる遅延のバランスを考慮する必要があります。この場合、トランザクションは、その原子性および永続性に関する要件によって決定される自然な長さのままにすることをお薦めします。

永続コミットの適切な使用

パフォーマンスへの影響: 大デフォルトでは、TimesTenのトランザクションをコミットするたびに、ファイル・システム書込み処理が発生します。これによって、システムまたはアプリケーションで障害が発生した場合でも、コミット済のトランザクションは失われなくなります。非永続コミットを実行すると、アプリケーションでこれらのファイル・システム書込み処理の一部またはすべてを回避できます。

非永続コミットでは、ファイル・システムへのトランザクション・ログの書込みを除き、永続コミットで実行されるすべての処理が実行されます。ロックは解放され、カーソルはクローズされますが、ファイル・システム書込み処理は実行されません。

ノート:

一部のドライバは、キャッシュ・メモリーへのデータの書込みも、ファイル・システムへの書込みも、オペレーティング・システムが書込み完了通知を受け取って一定時間が経過してから行います。この場合、停電が発生すると、永続コミットしたと思われていた一部の情報が失われる可能性があります。このようなデータの損失を回避するには、完了通知の前に記録メディアに書き込むようにファイル・システムを構成するか、または無停電電源装置を使用します。

非永続コミットのメリットは、レスポンス時間が短くなりスループットが向上する可能性があることです。デメリットは、システムで障害が発生した場合に、一部のトランザクションが失われる可能性があることです。アプリケーションでは、定期的に永続コミットまたはチェックポイントを実行してトランザクション・ログを強制的にファイル・システムに永続化することによって、失われる可能性があるデータの量を減らすことができます。また、TimesTen自体でも、内部バッファが一杯になった場合にトランザクション・ログをファイル・システムに定期的にフラッシュしているため、失われる可能性があるデータの量が制限されます。

トランザクションは、接続ごとに永続的にすることも、非永続的にすることもできます。アプリケーションでttDurableCommitプロシージャをコールして、特定のトランザクションの永続コミットを強制実行できます。

永続コミットを使用するアプリケーションでは、書込みおよびフラッシュのかわりに同期書込みを使用することをお薦めします。同期書込みを有効にするには、初期接続属性LogFlushMethod=1を設定します。LogFlushMethod属性は、TimesTenでデータをトランザクション・ログ・ファイルに書き込む方法および同期する方法を制御します。アプリケーションのパフォーマンスはこの属性によって影響を受ける場合がありますが、トランザクションの永続性は影響を受けません。『Oracle TimesTen In-Memory Databaseリファレンス』のLogFlushMethodを参照してください。

SYS.SYSTEMSTATS表のtxn.commits.durable列は、永続コミットを実行したトランザクションの数を示します。

手動チェックポイントの回避

パフォーマンスへの影響: 大

可能な場合は、手動チェックポイントの実行を回避することをお薦めします。バックグラウンド・チェックポイントは、ttCkptConfig組込みプロシージャを使用して構成する必要があります。バックグラウンド・チェックポイントはほとんど影響がなく、非ブロッキング(ファジー)チェックポイントを使用します。

手動チェックポイントは、TimesTen Classicにのみ適用されます。手動チェックポイントは、TimesTen Scaleoutではサポートされていません。

手動チェックポイントが必要な場合、通常は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文の回避

パフォーマンスへの影響: 大

DELETE文が大量にならないようにすることをお薦めします。

DELETE FROM文の回避

1つのSQL文で表から(100,000以上)大量の行を削除しようとすると、処理に時間がかかる場合があります。

TimesTenでは、処理でロールバックが必要な場合に備えて削除された各行を記録しますが、ファイル・システムへのすべてのトランザクション・ログ・レコードの書込みには非常に時間がかかります。

このような大量のDELETE処理のもう1つの問題は、書込み集中型の削除トランザクションの発生中は他のデータベース操作が遅くなることです。1つのトランザクションで何百万行も削除するには、完了するまでに数分かかります。

何百万もの行を一度に削除することによる別の問題は、この表がレプリケートされるときに発生します。レプリケーションではコミット済のトランザクションのみが転送されるため、単一の、数百MB (またはGB)からなるトランザクションを転送することでレプリケーション・エージェントが遅くなります。TimesTenのレプリケーションは、多数の小規模なトランザクション用に最適化されているため、何百万もの行が1つのトランザクションで削除されるとパフォーマンスが低下します。

『Oracle TimesTen In-Memory Database SQLリファレンス』のDELETEを参照してください。

DELETE FIRST句の使用の検討

大量の行を削除する必要があり、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単位で指定できます。この設定のスコープは、現在のセッションです。

「再要求操作についてのコミット・バッファの構成」を参照してください。