| Oracle TimesTen In-Memory Databaseオペレーション・ガイド
リリース7.0 E05167-03 |
|
 前へ |
 次へ |
TimesTen Data Managerは、チェックポイント処理とロギングを組み合せて永続性を実現しています（「チェックポイント」および「ログ・ファイル」を参照）。
トランザクションをサポートすると実行時間が長くなるため、TimesTenでは、次のオプションをアプリケーションで選択できます。
次の表に、原子性および永続性のオプションの保証および制限の概要を示します。
この項の後半では、これらのオプションの詳細について説明します。
(Logging=1, DurableCommits=1）
デフォルトでは、TimesTenのすべてのトランザクションに永続性があります。トランザクションの結果は維持され、システムに障害が発生した場合でも失われません。
永続性は、チェックポイント処理とロギングの組合せで実装されます（「チェックポイント」および「ログ・ファイル」を参照）。チェックポイント処理では、現在のデータ・ストア・イメージがディスク上のチェックポイント・ファイルに書き込まれ、チェックポイント処理以前にコミットされたすべてのトランザクションの結果に永続性が与えられます。最後のチェックポイント後にコミットされたトランザクションに対しては、従来のロギングによる方法によって永続性が与えられます。トランザクションが処理されるたびに、そのトランザクションによるデータ・ストアの変更内容がインメモリー・ログに記録されます。コミットが行われると、ログ内の該当部分がディスクにフラッシュされます。このログ・フラッシュ処理によって、該当するトランザクションおよび以前コミット済のすべてのトランザクションに永続性が与えられます。
システム障害が発生すると、最新のチェックポイント・イメージがログとともに使用され、トランザクションに一貫性がある最新の状態でデータ・ストアが再構築されます。
デフォルトでは、すべてのTimesTenトランザクションに、永続性のみでなく原子性もあります。トランザクションの結果は、データ・ストアに完全に適用されるか、または完全に適用されないかのいずれかになります。
原子性は、トランザクションがロールバックされた場合、ログを使用してその結果を元に戻すことで実現されます。ロールバックは、ODBC SQLTransact関数またはJDBC Connection.rollbackメソッドを使用するか、または障害発生時にトランザクションがコミットされなかったことによるデータ・ストアのリカバリ中に、アプリケーションによって明示的に発生させることができます。
原子性および永続性を保証するには、アプリケーションでLogging属性およびDurableCommits属性を1に設定する必要があります。
(Logging=1, DurableCommits=0）
ロギングを有効にし、永続性の保証は無効にしてデータ・ストアに接続できます。この場合、トランザクションの原子性は保証されますが、永続性は保証されません。このモードは、永続性遅延モードと呼ばれます。
永続性遅延モードでは、永続性保証モードの場合と同様に、トランザクションによってデータ・ストアが変更されるたびに、インメモリー・ログにレコードが書き込まれます。ただし、トランザクションが永続性遅延モードでコミットされると、そのトランザクションはディスクへのログの書込みを待機せず、制御がアプリケーションに戻されます。システム障害が発生するとインメモリー・ログの内容が失われる可能性があるため、このモードでコミットされるトランザクションには永続性がありません。
通常、非永続的にコミットされるトランザクションは、永続コミットが行われるトランザクションよりレスポンス時間が短くなります。これは、トランザクションのコミットにI/Oが不要なためです。非永続的にコミットされるトランザクションには、チェックポイント処理（「チェックポイント」を参照）または後続のトランザクションを永続コミットして永続性を与えることができます。永続性保証モードの場合と同様に、チェックポイント処理を実行すると、チェックポイント処理前にコミットされたすべてのトランザクションに永続性を与えることができます。トランザクションの永続コミットでは、そのトランザクションおよび以前コミット済のすべてのトランザクションがコミットされます。
永続性遅延モードによるパフォーマンス上のメリットを利用し、少数のトランザクションの消失のみ許容できるアプリケーションの場合、バックグラウンドで永続コミットを定期的に実行できます。この場合、最後の永続コミット後に非永続的にコミットしたトランザクションのみ、システム障害が発生すると失われる可能性があります。
アプリケーションで永続性遅延モードをリクエストするには、Logging属性を1（デフォルト）に、DurableCommits属性を0に設定します。このモードでアプリケーションから組込みプロシージャttDurableCommitをコールすると、現行のトランザクションのコミット時に、永続コミットを実行できます。
(Logging=0, DurableCommits=0）
レスポンス時間を最小にするために、アプリケーションですべてのロギングを無効にできます。ただし、これにより、永続性および原子性の両方が失われる危険があります。このため、非ロギング・モードは、注意して使用する必要があります（『Oracle TimesTen In-Memory Database APIリファレンス・ガイド』のロギングに関する説明を参照）。
ロギングが無効になっている場合にトランザクションの永続性を確保する方法は、データ・ストアに対してチェックポイント処理を実行する方法のみです。このため、システム障害が発生すると、最後のチェックポイント後にコミットしたすべてのトランザクションが失われます。また、ロギングを有効にすると原子的に失敗する処理は、ロギングを無効にすると非原子的に失敗します。たとえば、SQL UPDATE文で1行以上の行を更新した後にエラーが発生した場合、更新済の行の内容はリストアされません。このような状況が発生すると、処理が非原子的に失敗したことを示す警告が戻されます。
ロギングが無効になっている場合は、トランザクションによるデータ・ストアへの変更のログがないため、トランザクションをロールバックすることはできません。したがって、すべてのトランザクションをコミットする必要があります。非ロギング・モードでトランザクションをロールバックしようとすると、エラーが発生します。ロギングが無効になっているときは、行レベル・ロックも無効になっています。アプリケーションでは、データ・ストア・レベル・ロックを使用する必要があります。
非ロギング・モードには多くの制限があるため、エラー発生時に再開が可能な用途（新しいデータ・ストアへのデータのロードなど）でのみ使用する必要があります。これ以外の用途で使用すると、コミットされていないデータが保持され、一貫性がなくなる場合があります。
非ロギング・モードを使用するには、アプリケーションでLogging=0を設定する必要があります。また、他の属性（LockLevel=1、DurableCommits=0およびLogPurge=0）も設定する必要があります。
