| Oracle® TimesTen In-Memory Databaseオペレーション・ガイド 11gリリース2 (11.2.2) B66441-07 |
|
 前 |
 次 |
TimesTenでは、データへのACID(Atomic: 原子性、Consistent: 一貫性、Isolated: 独立性、Durable: 永続性)アクセスを提供するトランザクションがサポートされています。次の項では、トランザクション機能を構成する方法について説明します。
TimesTenデータベースに対するすべての処理は、アプリケーション・データへの変更やアクセスを行わない場合でも、トランザクション内で実行します。処理を実行する時点で未処理トランザクションが存在しない場合は、アプリケーションのかわりにトランザクションが自動的に開始します。トランザクションは、明示的または暗黙的なコミットやロールバックによって完了します。完了後は、ロックやカーソルなど、トランザクションによって取得または開かれたリソースは解放されます。
トランザクションをコミットまたはロールバックするには、次のSQL文を使用します。
SQL COMMIT文は、現行のトランザクションをコミットします。トランザクションで行った更新は、同時実行トランザクションで有効になります。
SQL ROLLBACK文は、現行のトランザクションをロールバックします。トランザクションで行ったすべての更新は、元に戻されます。
|
注意: COMMITおよびROLLBACK文の構文の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のSQL文に関する説明を参照してください。 |
読取り専用トランザクションにコミットは必要ありません。書込み処理を実行するときは、ロックを解除するためにトランザクションを完了します。可能な場合は、書込みトランザクションの時間を短くしてください。長時間実行トランザクションは、ロックが保持される時間が長くなり、同時実行トランザクションがブロックされるため、同時実行性およびスループットが低下することがあります。また、長時間実行トランザクションによって、トランザクション・ログ・ファイルがパージされずに、ディスクに蓄積されることがあります。
1つの接続で許可される未処理トランザクションは1つのみです。また、オープン状態のトランザクションが存在する場合、接続は明示的に閉じることはできません。
次の項では、アプリケーションで暗黙的なコミット動作が有効か、またはアプリケーションでDML文またはDDL文の暗黙的なコミット動作が必要かを構成する方法を説明します。
自動コミットでは、DML文またはDDL文の後に暗黙的なコミットを発行するかどうかを構成します。デフォルトでは、ODBCおよびJDBCの仕様に従って、自動コミットは有効です。
自動コミットが有効になっている場合、次の動作が実行されます
暗黙的なコミットは、文が正常に実行された直後に発行されます。
暗黙的なロールバックは、主キー違反など、文の実行が失敗した直後に発行されます。
文によってカーソルを開く結果セットが生成された場合、そのカーソルおよびトランザクション内の他のオープン・カーソルを明示的に閉じるまで、自動コミットは発行されません。カーソルが開いている状態で文を実行した場合、すべてのカーソルを閉じるまでその文はコミットされません。
結果セットのすべての行をフェッチしても、カーソルは自動的に閉じません。結果セットの処理後、コミット読取り分離レベルを使用している場合はカーソルを明示的に閉じる必要があり、シリアライズ可能分離レベルを使用している場合はトランザクションを明示的にコミットまたはロールバックする必要があります。
|
注意: 永続コミットおよび自動コミットが有効でも、障害が発生した場合またはカーソルをクローズする前にアプリケーションが終了した場合は、作業内容が失われることがあります。 |
自動コミットが有効になっている場合に、ODBCまたはJDBCのバッチ処理を使用して、1回のコールで複数行に対してINSERT、UPDATEまたはDELETEを実行すると、コミットはバッチ処理全体が終了してから実行されます。バッチ処理中にエラーが発生した場合は、正常に変更された行がこのトランザクション内でコミットされます。特定の行の問題が原因でエラーが発生した場合は、エラーが発生した行の前の行で、正しく変更された行のみがこのトランザクション内でコミットされます。ODBC SQLParamOptions関数のpirowパラメータには、バッチで問題が発生した行の番号が含まれます。
各文の後にコミットを暗黙的に行うと、パフォーマンス・コストが高くなり、煩わしくなる可能性があります。TimesTenでは、すべてのコミットを意図的に行うようにするため、自動コミットを無効にすることをお薦めします。自動コミットを無効にすると、すべての文の後に暗黙的なコミットを実行することはないため、トランザクションの境界を制御したり、1つのトランザクションで複数の文を実行したり、パフォーマンスを向上することができます。
自動コミットを無効にすると、次のいずれかの処理を実行した後に、コミットまたはロールバックでトランザクションを明示的に完了する必要があります。
トランザクションで実行することになっていた作業をすべて完了した後。
トランザクション一貫性(ブロッキング)チェックポイント・リクエストを発行した後。
問合せオプティマイザが使用する列統計および表統計を更新した後。
ttLockWaitなどのプロシージャで指定した新しい設定を有効にするために、結果セットを生成しないTimesTen組込みプロシージャをコールした後。
自動コミット設定を変更する前に、データベース接続を確立する必要があります。自動コミットを無効にするには、次のいずれかの処理をします。
通常、TimesTenデータベースでは、DDL文は現在のトランザクションの一部として実行され、トランザクションの残りの部分とともにコミットまたはロールバックされます。ただし、Oracle Databaseのデフォルトの動作では、DDL文の前後に暗黙的なCOMMITを発行します。
DDLCommitBehavior接続属性を使用して次のいずれかの動作を構成できます。
0 - Oracle Databaseの動作。各DDL文の実行前に暗黙的なトランザクション・コミット、実行後に永続コミットを実行します。これがデフォルトです。
1 - TimesTenの従来の動作。DDL文を実行しても、暗黙的なトランザクション・コミットはトリガーされません。
表、ビュー、ユーザー、プロシージャ、索引などのデータベース・オブジェクトに対するCREATE、ALTERおよびDROP文。
TRUNCATE
GRANTおよびREVOKE
DDLCommitBehavior=0を設定すると次のような結果になります。
DDLによる変更をロールバックできません。
グローバル一時表がON COMMIT PRESERVE ROWS句を使用して作成された場合を除いて、DDL文によってグローバル一時表からレコードが削除されます。
作成した表はCREATE TABLE . . .AS SELECT文を使用した場合、すぐに表示されます。
TRUNCATE文が自動的にコミットされます。ただし、親表および子表は別のトランザクションで切り捨てる必要があり、その際には、子表が先に取り捨てられます。子表が空でなければ、親表は切り捨てられません。子表および親表の切捨てを同じトランザクションで実行できるのはDDLCommitBehaviorを1に設定している場合のみです。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のDDLCommitBehaviorについての説明を参照してください。
自動コミットおよびDDLCommitBehaviorでは、どのような場合にSQL文に対する暗黙的なコミットを実行するかを設定します。
自動コミットはDDL文およびDML文の両方に適用されます。DDL文の暗黙的なコミットを有効にすると、両方のオプションで重複が発生します。自動コミットが有効でDDLCommitBehaviorが無効な場合、自動コミットはDDL文の後にのみ実行されます。ただし、自動コミットおよびDDLCommitBehaviorの両方が有効な場合、暗黙的なコミットはDDL文の前後に実行されます。
DDLCommitBehaviorを有効にするには、DSN属性DDLCommitBehaviorを設定します。自動コミットを有効または無効にするには、アプリケーションでODBC関数またはJDBCメソッドを実行します。
表7-1では、いずれかのオプションをもう一方のオプションと組み合せて有効または無効にした場合に実行される動作を示しています。
リレーショナル・データベースとして、TimesTenはACIDに準拠しています。
原子性: すべてのTimesTenトランザクションは原子性であり、1つのトランザクションのすべてのデータベース操作が実行されるか、1つも実行されないかのいずれかです。
一貫性: トランザクションは一貫性を保持したままデータベースの状態を変更できます。
独立性: トランザクションは分離されています。TimesTenにはコミット読取りとシリアライズ可能の2つの独立性レベルがあり、これらと行レベルロックを合わせてマルチユーザー並行性制御が提供されます。
永続性: トランザクションを一度コミットすると、コミットされた状態が保たれます。
次の項では、TimesTenがトランザクションのACIDセマンティクスを確認する方法について説明します。
トランザクションでデータベースのデータが変更されるため、ロックおよびトランザクション・ログによってACIDセマンティクスが次のように保証されます。
ロック: TimesTenでは、トランザクションで書込みを行うデータ項目と、トランザクション分離レベルに応じて、読取りを行うデータ項目に対してロックを取得します。「分離およびロックによる並行性制御」を参照してください。
トランザクションのロギング: すべてのTimesTenトランザクションはアトミックです。トランザクションの結果は、データベースに完全に適用されるか、完全に適用されないかのいずれかになります。データベースへの変更はトランザクション・ログに記録されます。原子性は、トランザクションがロールバックされた場合、トランザクション・ログを使用してその結果を元に戻すことで実現されます。ロールバックは、アプリケーションが明示的に実行したり、障害が発生した時点でトランザクションがコミットされていなかったために、データベースのリカバリ中に実行される場合もあります。「トランザクションのロギング」を参照してください。
次の表に、TimesTenでのロックおよびトランザクション・ログの使用方法を示します。
| 条件 | 結果 |
|---|---|
| トランザクションが正常に終了した(コミット済)。 |
|
| トランザクションがロールバックされた。 |
|
| システムで障害が発生した(データは未コミット)。 |
|
| アプリケーションでエラーが発生した。 |
|
TimesTenでは、チェックポイントが基本的に含まれていない一時データベースがサポートされています。ただし、トランザクションをロールバックできるようにトランザクション・ログが用意されています。このようなデータベースに対してリカバリが実行されることはありません。一時データベースは、データベースまたはアプリケーションがシャットダウンまたは失敗すると破棄されます。一時データベースの詳細は、「データベースの概要」の説明を参照してください。
TimesTenのトランザクションでは、ANSIシリアライズ可能分離レベルおよびANSIコミット読取り分離レベルがサポートされています。ANSIシリアライズ可能分離レベルは、最も厳密なトランザクションの分離レベルです。ANSIコミット読取りに設定すると、同時実行性をより高くできます。デフォルトはコミット読取りで、これはほとんどのアプリケーションに適した分離レベルです。
次の項では、トランザクションの分離レベルおよびロック・レベルについて説明します。
トランザクションに独立性があることで、アクティブな各トランザクションは、他のアクティブなトランザクションがシステム内に存在していない場合と同様に動作できます。分離レベルでは、読取り処理の実行時に行レベル・ロックを設定するかどうかを決定します。表を更新するために文が発行されると、更新トランザクションが完了し、ロックが解除されるまで、他のトランザクションが同じデータを変更しないようにロックが設定されます。
Isolation接続属性では、接続の分離レベルを設定します。データベース・レベルのロックを使用している場合は、トランザクションを同時実行できないため、分離レベルによる影響はありません。分離レベルをトランザクション中に変更することはできません。
TimesTenでは、次の2つのトランザクション分離レベルがサポートされています。
ANSIコミット読取り分離: コミット読取り分離レベルは、ほとんどのアプリケーションに適した処理モードで、デフォルト・モードでもあります。これによって、データを読み取っているトランザクションを、同じデータを更新している他のトランザクションと同時に実行できるようになります。TimesTenでは、データ項目の複数のバージョンが作成されるため、シリアライズ可能ではない読取りおよび書込み処理をパラレルで実行できます。
同じデータの読取りおよび書込みが行われる場合も、読取り処理により書込み処理がブロックされることも、書込み処理により読取り処理がブロックされることもありません。読取り処理では、スキャンされた行にロックを設定しません。書込み処理では、トランザクションがコミットまたはロールバックされるまで、ロックを設定します。読取りユーザーはコミットされたデータのコピーを共有し、書取りユーザーは非コミット・バージョンを保有します。したがって、実行中のトランザクションによって更新処理が行われている項目を別のトランザクションで読み取ると、その項目のコミットされたバージョンが表示されます。処理中のトランザクションの非コミット・バージョンは表示されません。
コミット読取り分離レベルでは、トランザクション内の非リピータブル・リードまたはファントム行のため分離度が低下するかわりに、同時実行性が向上します。アプリケーションが同じトランザクション内で同じ問合せを何度も実行すると、別のトランザクションからの更新のコミットによって、読取り処理の結果が別のものになることがあります。ファントム行は、トランザクション時に読取りのロックが早く解放されたため、同じトランザクション内に2つの異なる読取り形式で表示されます。
コミット読取り分離レベルを設定するには(このデフォルト設定が変更されている場合)、次のいずれかの処理を行います。
ODBCアプリケーションで、SQL_TXN_ISOLATIONフラグをSQL_TXN_READ_COMMITTEDに設定し、ODBC関数SQLSetConnectOptionを実行します。
接続文字列をisolation=1にして接続します。
ttIsqlを使用している場合は、ISOLATION 1またはISOLATION READ_COMMITTEDを実行します。
ANSIシリアライズ可能分離レベル: トランザクション内で読取り処理または書込み処理によって設定されたすべてのロックは、トランザクションがコミットまたはロールバックされるまでそのままになります。読取り処理によって書込み処理がブロックされ、書込み処理によって読取り処理がブロックされます。そのため、あるトランザクションで読み取られた行は、そのトランザクションが終了するまで、別のトランザクションから更新または削除することはできません。同様に、あるトランザクションによって挿入、更新または削除された行は、そのトランザクションが終了するまで、別のトランザクションからはアクセスできません。
シリアライズ可能分離レベルでは、同時実行性が低下するかわりに、リピータブル・リードが実現し、分離度が向上します。同じ問合せを同じトランザクション内で複数回実行するトランザクションは、毎回同じ結果セットが戻されることが保証されます。他のトランザクションで、戻された行を更新したり、削除したり、問合せ条件を満たす新しい行に対して挿入を実行することもできません。
分離レベルをシリアライズ可能に設定するには、次のいずれかの処理を行います。
ODBCアプリケーションで、SQL_TXN_ISOLATIONフラグをSQL_TXN_SERIALIZABLEに設定し、ODBC関数SQLSetConnectOptionを実行します。
接続文字列をisolation=0にして接続します。
ttIsqlを使用している場合は、isolation 0またはisolation serializableを実行します。
マテリアライズド・ビューを常に一貫性がある状態に保つために、すべてのビュー・メンテナンス処理は、トランザクションがコミット読取り分離レベルの場合も、シリアライズ可能分離レベルで実行されます。これは、トランザクションで、ビュー・メンテナンス時に読み取られるすべてのデータ項目に読取りロックを設定することを意味します。ただし、読取りロックは、トランザクションが終了するまで保持されるのではなく、ビュー・メンテナンス処理をトリガーしたINSERT、UPDATE、CREATE VIEW文が終了すると解除されます。
|
注意: ttXactAdminユーティリティで生成されるレポートには、すべての未処理トランザクションに関するロックの保持と待機が表示されます。このレポートは、処理がブロックされたロックの競合問題、またはロック・タイムアウトおよびデッドロックなどのエラーが発生した場合、トラブルシューティングに使用できます。また、特定のトランザクションをロールバックする場合にも使用できます。 |
TimesTenでは、行レベル・ロック、表レベル・ロックおよびデータベース・レベル・ロックがサポートされています。
|
注意: 異なるロック・レベルの異なる接続が同時に存在することは可能ですが、データベース・レベルのロックを使用する接続が1つでもある場合は、同時実行性が低下します。パフォーマンスの詳細は、「最適なロック方法の選択」を参照してください。 |
行レベル・ロック: 通常、トランザクションはアクセスする各行にロックを設定します。行レベル・ロックは、同時実行性制御の粒度が最も細かくなるため、処理モードとしてお薦めします。同時実行トランザクションで、同じ表の異なる行を更新できます。ただし、行レベル・ロックには、データベースの一時メモリー領域にロック情報を保存するための領域が必要になります。
行レベル・ロックはデフォルトです。ただし、別のタイプのロックに変更されている場合で、行レベル・ロックを再度有効にする場合は、次のいずれかの処理を行います。
LockLevelの接続属性を0に設定します。
lockLevelパラメータをRowに設定してttLockLevel組込みプロシージャをコールします。このプロシージャは、次のトランザクション、およびこの接続でその後に実行されるすべてのトランザクションの行レベル・ロックとデータベース・レベル・ロックを変更します。
ttOptSetFlagプロシージャを実行して、RowLockパラメータを1に設定すると、オプティマイザで行ロックの使用を選択できます。
|
注意: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「LockLevel」、「ttLockLevel」および「ttOptSetFlag」を参照してください。 |
表レベル・ロック: 表レベル・ロックは、同時実行トランザクションで他の表にアクセスする場合や、トランザクションで特定の表のほとんどの行にアクセスする場合にお薦めします。表レベル・ロックでは、データベース・レベル・ロックに比べ、同時実行性が高くなります。行レベル・ロックでは、表レベル・ロックに比べ、同時実行性が高くなります。表レベル・ロックでは、一時メモリー領域にわずかな領域があれば、ロック情報を保存できます。
表レベル・ロックでは、次の場合に最大のパフォーマンスが得られます。
問合せで表の多数の行にアクセスする場合
表にアクセスする同時トランザクションの数が非常に少ない場合
一時領域が不十分で、大量の挿入または削除などの処理で設定する可能性がある行ロックをすべて格納できない場合
表レベル・ロックを有効にするには、ttOptSetFlagプロシージャを実行して、TblLockパラメータを1に設定すると、オプティマイザで行ロックの使用を選択できます。また、オプティマイザで行レベル・ロックの使用を選択しない場合は、RowLockを0に設定します。
表レベル・ロックと行レベル・ロックの両方が無効になっている場合、TimesTenではデフォルトで行レベル・ロックが設定されています。表レベル・ロックと行レベル・ロックの両方が有効になっている場合、TimesTenはパフォーマンスが高いと予想されるロック・スキームを選択します。表レベル・ロックはロック処理のオーバーヘッドが少ないため、行レベル・ロックよりも高いパフォーマンスが得られますが、オプティマイザでは多くの場合、同時実行性が高い行レベル・ロックが選択されます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttOptSetFlag」を参照してください。
|
注意: 同じトランザクション内で複数のロックが取得されている場合、トランザクションが終了すると、ロックは順次解放されます。 |
データベース・レベル・ロック: データベース・レベル・ロックは、すべてのトランザクションをシリアライズし、データベースの同時実行性を実質的に禁止します。トランザクションを開始すると、データベースに排他ロックが設定され、データベース内のアクティブなトランザクション数は常に1つになります。トランザクションが完了すると、ロックが解除されます。
データベース・レベル・ロックは、ロック処理のオーバーヘッドが少ないため、通常は行レベル・ロックより高いパフォーマンスが得られます。また、バルク・ロード処理など、単一のトランザクション・ストリームを実行する場合、行レベル・ロックに比べスループットが高くなります。ただし、このロックは、複数の同時トランザクションを実行することがないアプリケーションにのみ適用されます。データベース・レベル・ロックを設定すると、同時トランザクションが許可されないため、すべてのトランザクションがANSIシリアライズ可能分離レベルで効率的に実行されます。
データベース・レベル・ロックを有効にするには、次のいずれかの処理を行います。
LockLevelの接続属性を1に設定します。
lockLevelパラメータをDSに設定してttLockLevel組込みプロシージャをコールします。このプロシージャは、次のトランザクション、およびこの接続でその後に実行されるすべてのトランザクションの行レベル・ロックとデータベース・レベル・ロックを変更します。
LockWait接続属性を、文がロックの設定を待機する、この時間をすぎるとタイムアウトする最長時間に設定します。デフォルトは10秒です。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のLockWaitに関する説明を参照してください。
トランザクション内の文がロックを待機していて、ロック待機時間が過ぎた場合は、エラーが戻されます。エラーを受信した後、アプリケーションは文を再発行できます。
ロック・タイムアウトを検出するためのデータベースの管理サブデーモン・プロセスのスケジュールにより、ロック待機時間は正確ではありません。タイムアウトが0秒に設定されている場合はすぐにレポートされるため、不正確ではありません。ロック待機時間は、ブロッキング・チェックポイントには適用されません。
データベースの管理サブデーモン・プロセスでは、同時実行トランザクションの中にデッドロックがないか、2秒ごとにデータベースをチェックします。デッドロックが発生した場合、デッドロック・サイクルに入ったトランザクションのうちの1つにエラーが戻されます。デッドロックが発生したもう一方のトランザクションが実行できるようになるには、エラーを受け取ったトランザクションをロールバックする必要があります。
チェックポイント処理では、データベースのインメモリー・イメージを、チェックポイント・ファイルと呼ばれるディスク・ファイルに保存します。デフォルトでは、TimesTenはバックグラウンドのチェックポイント処理を一定間隔で実行します。チェックポイント処理の実行時、データベースのサイズおよび最新のチェックポイント以降に行われたデータベースへの変更の回数に応じて、大量のI/Oアクティビティが発生し、実行時間が長くなる場合があります。
|
注意: アプリケーションでプログラムによってチェックポイント処理を開始することもできます。詳細は、「チェックポイントの設定および管理」を参照してください。一時データベースではチェックポイントは開始されません。一時データベースの詳細は、「データベースの永続性」を参照してください。 |
次の項では、チェックポイント処理およびその管理方法について説明します。
チェックポイント処理には、2つの主な目的があります。
リカバリを開始できるデータベース・イメージをより最新の状態で提供するため、データベース・リカバリの所要時間を短縮します。
トランザクション・ログの一部を将来のデータベースのリカバリ処理で不要にします(通常は、これで1つ以上のトランザクション・ログ・ファイルを削除できます)。
これらの2つの機能は、TimesTenアプリケーションにとって非常に重要です。リカバリ時間の短縮は、データベースのリカバリに必要なトランザクション・ログの量が、システム障害の発生後にアプリケーションで発生するダウンタイムに直接影響するため重要になります。不要なトランザクション・ログ・ファイルの削除は、新しいトランザクション・ログ・ファイルで使用可能なディスク領域を解放できるため重要になります。また、トランザクション・ログ・ファイルの数が減るため、データベースをメモリーにロードする所要時間が短縮されます。これらのファイルが削除されない場合、最終的に、トランザクション・ログ・ディレクトリのファイル・システムで使用可能なすべての領域がすべてこれらのファイルによって消費され、データベース処理が、ログ領域不足のため失敗することになります。
TimesTenでは、データベースごとにdsname.ds0およびdsname.ds1の2つのチェックポイント・ファイルがあります(ここで、dsnameは、データベースのDSNで指定されるデータベース・パス名やファイル名の接頭辞です)。TimesTenは、チェックポイント処理中、どのチェックポイント・ファイルに一貫性のある最新のイメージが格納されているかを決定してから、データベースの次のインメモリーのイメージをもう1つのファイルに書き込みます。したがって、これらの2つのファイルには、最新の2つのデータベース・イメージが含まれることになります。
TimesTenでは、一貫性のある最新のチェックポイント・ファイルとトランザクション・ログを使用して、データベースをシャットダウン後またはシステム障害発生後の、トランザクションに一貫性のある最新の状態にリカバリします。この処理中にエラーが発生した場合、または新しい方のチェックポイント・イメージが不完全な場合は、もう一方のチェックポイント・ファイルを使用してリカバリが再度開始されます。
データベースが作成されると、dsname.res0、dsname.res1およびdsname.res2という名前の3つのトランザクション・ログ・ファイルがTimesTenによって作成されます。これらのファイルには、予約済トランザクション・ログ領域として機能する事前割当て済の領域が含まれています。予約済トランザクション・ログ領域によって、トランザクション・ログ・ファイルを保持するファイル・システムが一杯になった場合に、トランザクションのロギングを制限付きで継続できます。ファイル・システムが一杯になった場合は、トランザクションで新しいログ・レコードを書き込むことはできません。トランザクションがこのような書込みを行おうとすると、強制ロールバックが実行されます。
TimesTenでは、2つのタイプのデータベース・チェックポイント処理がサポートされています。
ファジー・チェックポイント(非ブロッキング・チェックポイント)では、チェックポイントの処理中にデータベースに対してトランザクションを実行できます。ファジー・チェックポイントでは、ロックをまったく取得しないので、他のデータベース・アクティビティへの影響は最小限になります。チェックポイントの処理中でもトランザクションによってデータベースが変更されるので、作成されるチェックポイント・ファイルにコミット・トランザクションと非コミット・トランザクションの両方が含まれてしまう場合があります。また、チェックポイント・イメージの別の部分では、別の時点のものが反映される可能性もあります。たとえば、ある部分は、あるトランザクションのコミット前に書き込まれ、別の部分は、コミット後に書き込まれる場合があります。ファジー・チェックポイントという用語は、データベース・イメージの状態があいまいであることに由来します。
ファジー・チェックポイント処理でチェックポイント・ファイルが生成された際にデータベースをリカバリするには、TimesTenでは、データベースをトランザクションに一貫性のある最新の状態にリカバリするために、一貫性がある最新のチェックポイント・ファイルとトランザクション・ログが必要になります。
トランザクション一貫性チェックポイント(ブロッキング・チェックポイントとも呼ばれる)では、チェックポイント処理の一部でデータベースに排他ロックが設定され、その間はデータベースへのアクセスがブロックされます。その結果得られるチェックポイント・イメージには、チェックポイント処理でデータベースを排他ロックしたときより前のすべてのコミット済トランザクションが含まれます。データベース・ロックが保持されている間はアクティブなトランザクションが許容されないため、実行中のトランザクションで行われた変更はチェックポイント・イメージに含まれません。
TimesTenでは、一貫性のある最新のチェックポイント・ファイルを使用して、データベースを最後のチェックポイント処理が正しく終了した時点の、トランザクションに一貫性のある最新の状態にリカバリします。トランザクション・ログ・ファイルを使用して、データベースをシャットダウン後またはシステム障害発生後の、トランザクションに一貫性のある最新の状態にリカバリします。
トランザクション一貫性チェックポイントをリクエストするには、アプリケーションでttCkptBlocking組込みプロシージャを使用します。実際のチェックポイント処理は、リクエストを行ったトランザクションがコミットまたはロールバックされてから実行されます。両方のチェックポイント・ファイルがすでに最新となっているデータベースに対してトランザクション一貫性チェックポイントをリクエストすると、そのリクエストは無視されます。
TimesTenチェックポイントのデフォルト動作は次のとおりです。
TimesTenでは、定期的なファジー・チェックポイント処理がバックグラウンドで実行されます。この動作は変更できます。詳細は、「バックグラウンドのチェックポイント処理の設定または無効化」を参照してください。
TimesTenでは、データベースをメモリーからアンロードする直前に、データベースに対してトランザクション一貫性チェックポイント処理を実行します。「トランザクション一貫性チェックポイント」を参照してください。
次の接続属性および組込みプロシージャを使用して、チェックポイントを管理および監視できます。
CkptFrequency属性
CkptLogVolume属性
CkptRate属性
CkptReadThreads属性
ttCkpt組込みプロシージャ
ttCkptBlocking組込みプロシージャ
ttCkptConfig組込みプロシージャ
ttCkptHistory組込みプロシージャ
次の項では、チェックポイント処理の管理方法について説明します。
デフォルトのTimesTenでは、定期的なファジー・チェックポイント処理がバックグラウンドで実行されます。このため、アプリケーションで手動チェックポイントを発行する必要はほとんどありません。ただし、手動チェックポイントを発行する必要がある場合は、ttCkpt組込みプロシージャをコールしてファジー・チェックポイントをリクエストするか、またはttCkptBlocking組込みプロシージャをコールしてトランザクション一貫性チェックポイントをリクエストできます。
属性または組込みプロシージャを使用すると、トランザクション・ログ・ファイルの特定の量のデータが含まれた時点でチェックポイント処理を実行するか、特定の頻度でチェックポイント処理を実行するかを構成できます。
TimesTenでチェックポイント処理を構成するには、次の処理を行います。
CkptFrequencyおよびCkptLogVolume接続属性を次のように構成します。
CkptFrequency接続属性で、TimesTenがバックグラウンド・チェックポイント処理を実行する頻度(秒)を制御します。デフォルトは600秒です。バックグラウンドのチェックポイント処理をCkptLogVolume接続属性で制御する場合は、CkptFrequency接続属性を0に設定します。
CkptLogVolume接続属性で、次回のバックグラウンド・チェックポイント処理までにトランザクション・ログ・ファイルに収集するデータ量(MB)を制御します。このデータ量を増やすと、チェックポイント処理の頻度を減らすことができます。デフォルトは0です。バックグラウンドのチェックポイント処理をCkptLogVolume接続属性で制御する場合は、CkptFrequency接続属性を0に設定します。
バックグラウンドのチェックポイント処理を無効にするには、CkptFrequencyおよびCkptLogVolume接続属性を0に設定します。
または、ttCkptConfig組込みプロシージャをコールしてバックグラウンド・チェックポイント処理を構成するか、無効化できます。ttCkptConfigで設定された値は、接続属性で設定された値より優先されます。
|
注意: デフォルト値および使用方法の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptFrequencyに関する説明、CkptLogVolumeに関する説明およびttCkptConfigに関する説明を参照してください。 |
ttCkptHistory組込みプロシージャをコールして、過去8つのチェックポイント処理に関する情報を表示します。実行中のチェックポイント処理の進行状況は、Percent_Complete列で監視できます。
デフォルトでは、チェックポイント・データがディスクに書き込まれる速度に制限はありません。CkptRate属性またはttCkptConfig組込みプロシージャを使用して、バックグラウンドでチェックポイント・データがディスクに書き込まれる最大速度を設定できます。リカバリ時に行われるチェックポイント処理および最後のチェックポイント処理ではこの速度は保持されず、無制限になります。
|
注意: これらの機能の使用の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptRateに関する説明およびttCkptConfigに関する説明を参照してください。 |
速度を低く設定しすぎると、チェックポイント処理に過度の時間がかかり、次の問題が発生する場合があります。
不要なトランザクション・ログ・ファイルのパージが遅延します。
バックアップ処理の開始が遅延します。
リカバリ時間が増加します。
速度を選択する場合は、通常のチェックポイント処理で書き込まれるデータの量およびチェックポイント処理に通常かかる時間について考慮する必要があります。これらの情報は両方ともttCkptHistory組込みプロシージャを使用して入手できます。
実行中のチェックポイント処理の進行状況をttCkptHistory結果セットのPercent_Complete列で確認した結果、遅すぎると思われる場合は、ttCkptConfig組込みプロシージャをコールして、速度を上げることができます。ttCkptConfigをコールして速度を変更すると、新しい速度は即時に有効になり、実行中のチェックポイント処理に対しても反映されます。
チェックポイント処理速度を計算するには次の処理を行います。
ttCkptHistory組込みプロシージャをコールします。
任意のチェックポイントに対して、終了時間から開始時間を引きます。
書き込まれたバイト数をこの経過時間(秒)で割って1秒当たりのバイト数を取得します。
この数字を1024×1024で割って1秒当たりのMB数を取得します。
チェックポイント処理速度の設定時には、次のことを考慮する必要があります。
指定したチェックポイント処理速度は概算です。チェックポイント処理の実際の速度は、ハードウェア、システム・ロードなどの要因によって、指定した速度より遅くなる場合があります。
前述の方法ではチェックポイント処理速度が実際より低く計算されることがあります。これは、開始時間と終了時間の間に、チェックポイント・ファイルへの使用済ブロックの書込みのみでなく他のチェックポイント処理が含まれるためです。
ttCkptHistoryコールのPercent_Completeフィールドに、チェックポイント処理が実際に完了する前に100%が表示される場合があります。Percent_Completeフィールドには、使用済ブロックの書込み状況のみが表示され、チェックポイント処理終了時の追加のブックキーピングは含まれていません。
また、チェックポイント処理速度を調整する場合は、低速にするとチェックポイント処理により時間がかかり、チェックポイント処理を開始してから次に開始するまでの間の最短時間が事実上長くなるため、チェックポイント処理頻度も調整する必要があります。
デフォルトでは、TimesTenはチェックポイント・ファイルを単一のスレッドでシリアルに読み込みます。CkptReadThreads接続属性を使用して、データベースをメモリーにロードするときTimesTenがチェックポイント・ファイルの読込みに使用するスレッドの数を設定します。
n個のスレッドを使用すると、TimesTenはチェックポイント・ファイルをサイズの等しいn個の部分に分割します。各スレッドが、ファイルの一部を同時にメモリーに読み込みます。すべてのスレッドがチェックポイント・ファイルの各部分を正常に読み込むと、TimesTenはデータベースの一貫性をチェックします。
|
注意: 詳細は、このマニュアルのCkptReadThreadsの設定に関する項と、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptReadThreadsに関する項を参照してください。 |
TimesTenでは、すべての同時接続によって共有されるトランザクション・ログをデータベースごとに1つ作成します。トランザクション・ログ・レコードは、データベースの更新、コミットおよびロールバックごとに作成されます。ただし、読取り専用のトランザクションにトランザクション・ログ・レコードは生成されません。ログ・レコードはまず、データベースと同じ共有メモリー・セグメントに格納されているトランザクション・ログ・バッファに書き込まれます。その後、ログ・バッファの内容はディスク上の最新のトランザクション・ログ・ファイルにフラッシュされます。
トランザクション内で行ったすべての更新はトランザクション・ログを使用して追跡され、トランザクションがロールバックされると、それらの更新は元に戻すことができます。
トランザクション・ロギングによって、システム障害の発生後、最後のチェックポイント処理を実行した時点からコミットされたトランザクションを、チェックポイント・ファイルやトランザクション・ログからリカバリできます。ログ・バッファ内にあるコミットされた非永続トランザクションで、ディスクにフラッシュされていないものは、システム障害が発生すると失われる可能性があります。
次の項では、トランザクション・ログ・バッファおよびファイルの構成方法について説明します。
次の項では、トランザクション・ログ・バッファおよびファイルの構成方法について説明します。
トランザクション・ログ・バッファ: トランザクション・ログ・バッファはデータベースごとに1つあり、トランザクション・ログ・バッファのサイズはDSN属性LogBufMBを使用して構成できます。各トランザクション・ログ・バッファは複数のストランドを持つことができます。トランザクション・ログ・バッファのストランド数は、LogBufParallelism属性で構成します。
トランザクション・ログ・ファイル: トランザクション・ログ・ファイルの最大サイズは、DSN属性LogFileSizeを使用して設定できます。トランザクション・ログ・ファイルは、LogDir属性で別の場所が指定されていないかぎり、チェックポイント・ファイルと同じディレクトリに作成されます。トランザクション・ログ・ファイル名は、ds_name.lognという形式になっています。ds_nameは、DSN属性DataStoreによって指定され、データベースのDSNで表示されるデータベース・パス名です。接尾辞のnは、トランザクション・ログ・ファイル番号で、0から始まります。
|
注意: TimesTenでは、パフォーマンスを最適にするため、アプリケーションでLogDir属性を使用して、トランザクション・ログ・ファイルをチェックポイント・ファイルとは別の物理デバイスに格納することをお薦めします。別の場所に格納することで、チェックポイントのI/O操作とトランザクション・ログに対するI/O操作が相互にブロックすることがなくなります。
データベースのトランザクション・ログ・ファイルおよびチェックポイント・ファイルが同じデバイスにある場合は、TimesTenによりサポート・ログにメッセージが書き込まれます。 |
トランザクション・ログ・ファイルが過度に蓄積されないよう、保持されているトランザクション・ログがないことを頻繁に確認することが重要です。非常に多くのトランザクション・ログのファイルが蓄積され、利用可能なディスク領域がなくなると、トランザクション・ログの保持が進行して、次のチェックポイント操作によってトランザクション・ログ・ファイルがパージされるまで、TimesTenデータベースでは新しいトランザクションを開始できません。
次の項では、トランザクション・ログ操作、ログの保持、ログ・ファイルの蓄積について説明します。
すべてのトランザクション・ログ・ファイルは、TimesTenがパージを行うと判断する次の状況まで保持されます。
ファイルにログ記録が書き込まれるか、トランザクションがコミットされるか、ロールバックされたとき。これは、ローカル・データベース・トランザクションまたはXAトランザクションのいずれでもかまいません。
ファイルに記録された変更が、両チェックポイント・ファイルに書き込まれたとき。
レプリケーションが有効な場合に、ファイルに記録された変更がレプリケートされたとき。
TimesTen Cacheが使用され、この動作が構成されている場合、ファイルに記録された変更がOracle Databaseに伝播されたとき。
XLAが使用されている場合、ファイルに記録された変更がXLAにレポートされたとき。
通常のTimesTenの処理では、不要なトランザクション・ログ・ファイルはチェックポイントが開始されるたびにパージされます。チェックポイントは、構成可能な接続属性CkptFrequency接続属性を使用した時間間隔、CkptLogVolume接続属性で構成可能なログ量、または手動やバックグラウンドのチェックポイント・アプリケーション・スレッドを使用してコールできるttCkpt組込み関数を使用して開始できます。
ログ・ファイルの累積のためにディスク領域がなくなっている場合は、CkptFrequency接続属性のかわりにCkptLogVolume接続属性を使用します。また、ttLogHolds組込みプロシージャを頻繁に実行する場合は、ログの再利用がブロックされているかどうかがわかります。
|
注意: パフォーマンスを向上させるために、チェックポイント・ファイルがあるディスク・パーティションとは別のディスク・パーティションにログ・ファイルを配置します。ログ・ファイルの保存場所は、LogDir接続属性によって決定されます。詳細は、本書の「トランザクション・ログ・バッファおよびファイルの管理」または『Oracle TimesTen In-Memory Databaseリファレンス』のLogDirに関する説明を参照してください。 |
一般的な情報については、Oracle TimesTen Application-Tier Database Cache概要のチェックポイントに関する説明を参照してください。CkptFrequencyおよびCkptLogVolumeの詳細は、「バックグラウンド・チェックポインティングの構成または無効化」を参照してください。また、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptFrequency、CkptLogVolume、ttCkptおよびttLogHoldsに関する説明も参照してください。
TimesTenのいくつかのコンポーネントまたは処理によって、トランザクション・ログが保持される場合があります。ある時点以降、トランザクション・ログの保持により、ログ・ファイルは不要になるまでパージされなくなります。通常の場合は、ログの保持の位置は定期的に進行し、ログ・ファイルは適切にパージされます。ただし、操作が正常に動作せず、保持の位置が進まないと、その位置以降にログ・ファイルが過度に蓄積されてパージができなくなり、利用可能なディスク領域がなくなってしまいます。
これらのコンポーネントおよび操作は、次のとおりです。
レプリケーション: 受信側のホストがログ・ファイルを完全に処理したことを送信側のレプリケーション・エージェントが確認するまでトランザクション・ログは保持されます。
次のようなときに、障害状態となることがあります。
ネットワークが停止しているか、スタンバイがクラッシュし、1つ以上のサブスクライバにデータを配信できないとき。必要に応じ、ログをこれ以上保持しないようアプリケーションが指示を出し、通常の処理が再開されたらスタンバイにマスター・データベースを複製するようにできます。これの実行の基準は、複製に必要な時間、ログ・ファイルに利用可能なマスター上のディスク領域量、トランザクション・ログの増加率などになります。
レプリケーションでアクティブ・データベースおよびスタンバイ・データベースの同期を保つことができないほど、データベース全体のトランザクション率が高くなっているとき。アプリケーションで、アプリケーションのトランザクション率またはレプリケートされる表数を削減できます。
詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の「レプリケーションのパフォーマンスの向上」およびOracle TimesTen In-Memory Databaseトラブルシューティング・ガイドの「レプリケーションのトラブルシューティング」を参照してください。
XLA: XLAブックマークが進行するまでトランザクション・ログは保持されます。
XLAアプリケーションが予期せず終了したり、そのブックマークが削除されないまま切断されたり、変更トラッキングを無効にせずにブックマークがスタックとなると、障害状態になる場合があります。ブックマークが遅すぎた場合は、アプリケーションで削除できます。XLAリーダー・プロセスがまだアクティブな場合は、別のXLAプロセスが接続しブックマークを削除できるよう、まず終了する必要があります。
AWTキャッシュ・グループをレプリケートするアクティブなスタンバイのペア: ログが保持されているトランザクションがOracle Databaseでコミットされたことをレプリケーション・エージェントが確認するまで、トランザクション・ログは保持されます。アクティブ・スタンバイ・ペアでは、通常、アクティブ・データベースがスタンバイ・データベースから確認を受信します。スタンバイ・データベースが停止している場合、レプリケーション・エージェントはOracle Databaseから直接確認を受け取ります。
次のようなときに、障害状態となることがあります。
Oracle Databaseが停止またはロックされているか、リソースの競合があります。
ネットワークが停止しているか、遅いか、飽和しています。
アクティブ・スタンバイ・ペアで、スタンバイ・データベースに対するレプリケーションが遅れています。スタンバイ・データベースでチェック・ログが保持されています。
TimesTenがOracle Databaseに継続的に伝播できる最大の率よりもTimesTenへのトランザクション率が高くなっています。
詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のAWTキャッシュ・グループの監視に関する説明およびOracle TimesTen In-Memory Databaseトラブルシューティング・ガイドのAWTキャッシュ・グループのトラブルシューティングに関する説明を参照してください。
AUTOREFRESHが構成されたキャッシュ・グループ: アクティブ・データベースのレプリケーション・エージェントが、ログ・ファイルがスタンバイ・データベースによって正常に処理されたことを確認するまで、トランザクション・ログは保持されます。
次のようなときに、障害状態となることがあります。
AUTOREFRESHモードの結果による大量のワークロードにより、アクティブ・データベースからスタンバイ・データベースへのレプリケーションでスタンバイ・データベースに遅れが生じています。
停止またはリカバリ中のスタンバイ・データベースが、ユーザー・アプリケーションまたはOracle Clusterwareから開始されるttRepStateSave組込みプロシージャへのコールを介してFAILEDとマークされていません。アクティブ・データベースは、スタンバイ・データベースの状態がFAILEDとマークされるまで、Oracle Databaseへの伝播を引き継ぎません。スタンバイ・データベースが停止またはリカバリ中の場合、トランザクション・ログ・ファイルはOracle Databaseのために保持されます。
詳細は、Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドの自動リフレッシュ・キャッシュ・グループの監視に関する説明を参照してください。
TimesTenの増分バックアップ: バックアップが完了するまで、トランザクション・ログは保持されます。
トランザクション・ログの最新のエントリに対して、増分バックアップが大きく遅れるとき、障害状態が発生することがあります。たとえば、トランザクション・アクティビティが予期せずに激増した場合、バックアップが非常に古いログ・ファイルを保持しているために、利用可能なトランザクション・ログ用のディスク領域が一杯にならないようにする必要があります。この問題を解決するには、アプリケーションで再度増分バックアップを実行します。
長時間実行のトランザクションまたはXAトランザクション: トランザクション・ログが完了するまで、トランザクション・ログは保持されます。
アプリケーション・トランザクションが長時間コミットまたはロールバックされず、アプリケーションが長時間実行のトランザクションを終了しなければならない場合、障害状態になる場合があります。
必要に応じて、ttXactAdminユーティリティを-xactIdRollbackオプションを使用して実行すると、トランザクションをロールバックできます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttXactAdminに関する説明を参照してください。
トランザクション・ログの過度の蓄積を定期的に監視するオプションは、次のとおりです。
保持されているログの詳細な結果セットが返される、ttLogHolds組込みプロシージャをコールします。該当する場合、この情報は次になります。
ログ・ファイルの番号、保持されている位置のオフセット、およびチェックポイント、レプリケーション、バックアップ、XLA、長時間実行のトランザクションまたは長時間実行のXAトランザクションの種類の保持
チェックポイントによる保持の場合のチェックポイント・ファイル名
サブスクライバ名およびレプリケーションで使用するパラレル・トラックID
バックアップによる保持の場合のバックアップ・パス
永続サブスクリプション名およびXLA用にオープンする最後のプロセスのプロセスID
長時間実行のトランザクションのトランザクションID
長時間実行のXAトランザクションのXA XID
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttLogHoldsに関する説明を参照してください。
ttCkptHistory組込みプロシージャをコールし、最後のいくつかのチェックポイントを確認し、返された行に1つもFAILEDの状態がないことを確認します。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCkptHistoryに関する説明を参照してください。
操作メトリックについては、SYS.SYSTEMSTATS表を確認してください。各トランザクション・ログ・ファイルには、一意の順序番号があります(最初のログ・ファイルが0で開始し、以降の各ログ・ファイルは1ずつ増分します)。現在のログ・ファイルの番号は、SYS.SYSTEMSTATS.log.file.latestにあります。まだ消去されていない一番古いログ・ファイルの番号は、SYS.SYSTEMSTATS.log.file.earliestにあります。順序番号の差が不適切しきい値を超過した場合、エラーまたは警告が発生するようにします。
詳細は、『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』のSYS.SYSTEMSTATSに関する説明を参照してください。
XLAについては、ブックマークがスタックまたは遅行している原因の診断の助けとなる、接続されているアプリケーションのプロセスIDなどのブックマークの情報が記載されているSYS.TRANSACTION_LOG_API表を確認してください。
詳細は、『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』のSYS.TRANSACTION_LOG_APIに関する説明を参照してください。
次の項では、トランザクション・ロギングの永続性オプションについて説明します。
永続性は、チェックポイント処理とロギングの組合せで実装されます。
チェックポイント・ファイル: チェックポイント処理では、現在のデータベース・イメージがディスク上のチェックポイント・ファイルに書き込まれ、チェックポイント処理以前にコミットされたすべてのトランザクションの結果に永続性が与えられます。
トランザクション・ログ・ファイル: 最後のチェックポイント後にコミットされたトランザクションに対しては、従来のロギングによる方法によって永続性が与えられます。トランザクションが処理されるたびに、そのトランザクションによるデータベースの変更内容がインメモリー・トランザクション・ログに記録されます。コミットが行われると、トランザクション・ログ内の該当部分がディスクにフラッシュされます。このログ・フラッシュ処理によって、該当するトランザクションおよび以前コミット済のすべてのトランザクションに永続性が与えられます。
トランザクション・ログ・データがディスクに永続的に書き込まれると、アプリケーションに制御が戻ります。永続的にコミットされたトランザクションは、システム障害が発生しても失われることはありません。
永続性の保証を有効にするには、DurableCommits属性を1に設定します。
最新のチェックポイント・イメージがトランザクション・ログとともに使用され、トランザクションに一貫性がある最新の状態でデータベースが再構築されます。
|
注意: あるトランザクションを永続的にコミットすると、そのトランザクションだけでなく、以前のすべてのトランザクションが永続的になります。非永続トランザクションは、永続的にコミットされたトランザクションと同様、データベース障害の発生時にも失われる可能性はありません。 |
ほとんどのトランザクションが永続的にコミットされた場合、LogFlushMethod初期接続属性を2に設定する場合があります。この接続属性では、TimesTenでログ・データをトランザクション・ログ・ファイルに書き込む方法および同期する方法を構成します。詳細は、「永続コミットの適切な使用」を参照してください。
永続性遅延モードでは、永続性保証モードの場合と同様に、トランザクションによってデータベースが変更されるたびに、インメモリーのトランザクション・ログにレコードが書き込まれます。ただし、トランザクションが永続性遅延モードでコミットされると、そのトランザクションはディスクへのトランザクション・ログの書込みを待機せず、制御がアプリケーションに戻されます。このため、非永続トランザクションはデータベースで障害が発生した場合に失われる可能性があります。ただし、これは永続トランザクションに比べてかなり短時間で実行できます。最終的にトランザクションは、データベースのサブデーモン・プロセスにより、またはインメモリーのログ・バッファに空きがない場合はディスクにフラッシュされます。
アプリケーションではDurableCommits属性を0に設定して、永続性遅延モードをリクエストします。これはデフォルトかつ推奨するオプションです。永続性遅延を使用している接続と、永続性保証を使用している接続を共存させることができます。
永続性遅延モードによるパフォーマンス上の利点が必要で、わずかな数のトランザクションであれば失うことを許容できるアプリケーションの場合は、バックグラウンドで永続コミットを定期的に実行できます。この場合、最後の永続コミット後に非永続的にコミットしたトランザクションのみが、システム障害が発生すると失われる可能性があります。
複数の同時実行トランザクションをグループ・コミットすると、永続コミットのパフォーマンス・コストを低下できます。多くのスレッドを同時に実行する場合で、そのスレッドが短時間のトランザクションである場合は、ほとんど同時にコミットできます。その後、1回のディスク書込みによって同時トランザクションのグループが永続的にコミットされます。永続コミットのたびに、ディスク書込みの終了を待機する必要があるため、グループ・コミットでは、いずれのコミット処理のレスポンス時間も向上しませんが、一連の同時トランザクションのスループットは大幅に向上します。
TimesTenでは、永続コミットが頻繁に使用される場合、トランザクションが短時間であるかぎり、CPUの数を超える数の接続をサポートできます。これは、それぞれの接続で、CPUを使用する時間よりコミットの完了を待つ時間の方が長いため可能になります。または、永続コミットが頻繁に実行されないアプリケーションでは、各接続のワークロードに対するTimesTen関連のCPU使用率が非常に高くなります。
最適なレスポンス時間を必要としない、トランザクションの多少の消失は許容できるアプリケーションでは、定期的な永続コミットの実行を選択できます。これにより、非永続的にコミットされているすべてのトランザクションに比べて、トランザクションが失われる可能性は低くなります。永続コミットをn個のトランザクションごとにのみ実行するか、またはn秒ごとに実行すると、トランザクションの消失の可能性がある時間枠を小さくし、レスポンス時間を短縮できます。ユーザーは、金融取引を扱うトランザクションなど、消失の危険があるクリティカルなトランザクションを永続的にコミットすることもできます。
定期的な永続コミットを有効にするために、アプリケーションで次のことが実行されます。
属性DurableCommits=0を設定して接続します。これにより、トランザクションが非永続的にコミットされます。
永続コミットが必要な場合は、コミットする前にアプリケーションから組込みプロシージャttDurableCommitをコールします。ttDurableCommit組込みプロシージャは、実際にトランザクションはコミットせず、コミットの実行時にそのコミットに永続性を与えるのみです。
トランザクションがTimesTenによってコミット済としてマークされた後、コミットの再要求段階があり、この間にデータベース・リソースが再要求されます。この項では、この再要求操作について、次の内容で説明します。
トランザクションのコミットの再要求段階の間に、TimesTenのリソース・クリーンアップが発生します。たとえば、DELETE操作を含むトランザクションを考えてみます。SQL操作は削除した行を削除済としてマークしますが、これらの行が占有する領域とリソースは、実際にはトランザクションのコミットの再要求フェーズまでは解放されません。
再要求の間、TimesTenはトランザクションの開始時点からのすべてのトランザクション・ログ記録を再調査し、実行する必要がある再要求操作を決定してから、これらの操作を実行します。
パフォーマンス向上のため、数件のトランザクション・ログ・レコードをキャッシュしてディスク上のトランザクション・ログへのアクセスを減らすことができます。このキャッシュはコミット・バッファと呼ばれ、その大きさは、次の「コミット・バッファを再要求操作用に構成する」の項で説明しているように構成可能です。
|
注意:
|
大きなトランザクション・コミットの再利用要求段階では大量の処理が必要になり、リソースを大量に消費します。(このため、より小さなトランザクションを一般的に推奨します。)ただし、コミット・バッファの最大サイズを増やすことでパフォーマンスを向上させることができます。コミット・バッファとは、再利用要求操作で使用されるトランザクション・ログ記録のキャッシュです。
TimesTenのCommitBufferSizeMax接続属性を使用して、コミット・バッファの最大サイズをMB単位で指定できます。この設定のスコープは、現在のセッションです。効率性の向上のため、初期のメモリー割当ては最大値より大幅に小さくなっていますが、関連するログ・レコードがコミット・バッファに収まるように必要に応じて自動的に増えていき、割当ての最大値まで達します。その後、再要求フェーズのたびに、割当てが元の割当てに戻ります。デフォルトでは、最大値128KB、初期割当て16KBです。(『Oracle TimesTen In-Memory Databaseリファレンス』のCommitBufferSizeMaxに関する説明も参照してください。)
コミット・バッファの最大サイズを大きくすると、一時領域が対応して増加する場合があります。指定可能な最大サイズには、整数の最大値以外に特定の制限はありませんが、利用可能な一時領域を超えるとエラーが発生します。
次の関連機能に留意してください。
一連のセッションの中でALTER SESSIONを使用して次のようにコミット・バッファの最大サイズを変更できます。ここでnはMB単位の最大値です。(『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER SESSIONに関する説明も参照してください。)
ALTER SESSION SET COMMIT_BUFFER_SIZE_MAX = n
ttCommitBufferStats組込みプロシージャを使用して接続に関する統計を収集し、コミット・バッファの最大サイズのチューニングに役立てることができます。この組込みパラメータはパラメータを取らず、コミット・バッファ・オーバーフローの合計数と、トランザクション・ログ・レコードの再要求操作に使用された最大メモリー量を、バイト単位で返します。バッファ・オーバーフローがある場合、コミット・バッファの最大サイズを増やすことを検討してください。オーバーフローがなく、最大メモリー使用量がコミット・バッファの最大サイズより大幅に少ない場合は、最大サイズを減らすことを検討してください。
ttCommitBufferStatsReset組込みプロシージャは、これらの統計を0 (ゼロ)にリセットします。これは、コミット・バッファの最大サイズに新しい値を設定し、統計を最初からやり直したい場合などに便利です。
(『Oracle TimesTen In-Memory Databaseリファレンス』のttCommitBufferStatsとttCommitBufferStatsResetに関する説明も参照してください。)
システム全体のコミット・バッファ・オーバーフローの数も、SYS.SYSTEMSTATS表内のTimesTen統計、txn.commits.buf.overflowedに記録されます。(『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』のSYS.SYSTEMSTATSに関する説明も参照してください。)
CommitBufferSizeMaxの現在の設定を確認するには、ttConfiguration組込みプロシージャを呼び出します。
システム障害やプロセス障害によって、データベースが無効になったり破損したりすると、データベースへのすべての接続が無効になります。アプリケーションが障害のあったデータベースに再接続すると、サブデーモンがデータベースに新しいメモリー・セグメントを割り当て、チェックポイント・ファイルおよびトランザクション・ログ・ファイルからそのデータをリカバリします。
リカバリ中に、最新のチェックポイント・ファイルがメモリーに読み込まれます。最後のチェックポイント以降にコミットされ、ログ・レコードがディスク上に存在するすべてのトランザクションが、適切なトランザクション・ログ・ファイルからロールフォワードされます。ただし、このようなトランザクションには、永続的にコミットされたすべてのトランザクションのみでなく、ログ・レコードがインメモリーのログ・バッファからエージ・アウトされたすべてのトランザクションも含まれることに注意してください。コミットされていないトランザクション、またはロールバックされたトランザクションはリカバリされません。チェックポイントとトランザクション・ログ・ファイルの詳細は、「チェックポイント処理」および「トランザクションのロギング」を参照してください。
