| Oracle TimesTen In-Memory Databaseオペレーション・ガイド
リリース6.0 B25767-03 |
|
 前へ |
 次へ |
アプリケーションでは、トランザクションに永続性を与えるかどうかおよびログ・ファイルを作成するかどうかを設定できます。
特定のトランザクションの永続性を保証するには、実行中のアプリケーションからTimesTen組込みプロシージャttDurableCommitをコールして、接続時に設定したトランザクションの永続性遅延を上書きします。
共有データ・ストアの場合、永続接続は永続性が保証されていない接続と共存できます。
同じデータ・ストア対するすべての同時接続で、Logging属性の設定が同じである必要があります。MatchLogOptsが設定されていないかぎり、接続属性が既存の接続と異なる接続のリクエストは拒否されます。
行レベル・ロックを使用する場合またはOracle表をキャッシュする場合は、ディスクへのロギングまたはディスクレス・ロギングのいずれかを使用する必要があります。
多くのスレッドが同時に実行される場合、永続コミットのパフォーマンス・コストは、「グループ・コミット」と呼ばれる効果によって軽減できます。グループ・コミットでは、1回のディスク書込みによって同時トランザクションのグループが永続コミットされます。グループ・コミットでは、いずれのコミット処理のレスポンス時間も向上しません（永続コミットのたびに、ディスク書込みの終了を待機する必要があります）。ただし、一連の同時トランザクションのスループットは大幅に向上します。
TimesTenでは、永続コミットが頻繁に使用される場合、トランザクションが短時間であるかぎり、CPUの数を超える数の接続をサポートできます。これは、それぞれの接続で、CPUを使用する時間よりコミットの完了を待つ時間のほうが長いため可能になります。これは、永続コミットが頻繁に実行されないアプリケーションとは対照的です。このようなアプリケーションでは、各接続のワークロードに対するTimesTen関連のCPU使用率が非常に高くなる傾向があります。この場合にプロセッサの数より多い数の接続を使用すると、CPUの競合が原因でパフォーマンスが低下することがあります。
レスポンス時間を短くする必要があり、トランザクションの多少の消失は許容できるアプリケーションでは、定期的な永続コミットの実行を選択できます。永続コミットをn個のトランザクションごとにのみ実行するか、またはn秒ごとに（通常はバックグラウンド・プロセスで）実行すると、トランザクションの消失の可能性がある時間枠を小さくし、レスポンス時間を短縮できます。
永続コミットでは、そのトランザクションのみでなく、以前コミット済のすべてのトランザクション（他のスレッドまたはプロセスで実行されたものも含む）が永続コミットされるため、永続コミットをn個のトランザクションごとに実行するアプリケーションでは、最後のn個のトランザクションを失う危険性のみがあります。
同様に、永続コミットをn秒ごとに実行するアプリケーションでは、最後のn秒間のトランザクションにのみ危険性があります。
定期的な永続コミットを有効にするには、Logging=1およびDurableCommits=0の設定でアプリケーションを接続し、トランザクションがデフォルトで非永続的にコミットされるようにします。永続コミットが必要な場合は、コミットする前にアプリケーションから組込みプロシージャttDurableCommitをコールします。すべてのSQL文の場合と同様に、ttDurableCommitを頻繁に使用する場合は、ttDurableCommitへのコールを事前に準備しておくことをお薦めします。ttDurableCommit組込みプロシージャは、実際にトランザクションはコミットしません。コミットの実行時にそのコミットに永続性を与えるのみです。
データが失われないようにするもう1つの方法は、永続コミットのかわりにTimesTenレプリケーションを使用して、データのコピーを2つのメモリーに保持しておく方法です。2つのメモリーはディスクより永続性が劣りますが、レプリケーションを行うと、データ・ストアをリカバリしなくてもフェイルオーバーが可能になるため、データの可用性が向上します。このようなトレードオフは、高パフォーマンスのシステムでは一般的です。TimesTenレプリケーションの詳細は、『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』を参照してください。
ディスクへのロギングが有効になっている場合は、LogDir属性が指定されていないかぎり、データ・ストア・ファイルと同じディレクトリにログ・ファイルが生成されます。1つのデータ・ストアに対して、複数のログ・ファイルが存在する場合があります。ログ・ファイルには、ds_name.lognの形式の名前が付けられます。ここで、ds_nameはデータ・ストアのDSNに指定されているデータ・ストア・パス名で、nは（0から始まる）ログ・ファイル番号です。
デフォルトでは、アーカイブ・ログ・ファイルはチェックポイント時に自動的に削除されます。アーカイブ・ログ・ファイルを保持するには、LogPurge属性を0に設定します。データ・ストア接続に対してLogPurge属性が設定されていない場合、リカバリの実行に不要となったログ・ファイルは、TimesTenによってds_name.logn.archという名前に変更されます。この場合、これらの不要なログ・ファイルは、アプリケーションで削除する必要があります。ログ・ファイルをパージする方法の詳細は、「LogPurge」を参照してください。
ログ・ファイルの大きさがLogFileSize属性の値を超えると、そのファイルは閉じられ、新しいログ・ファイルでの処理が開始されます。
