| Oracle® TimesTen In-Memory Databaseオペレーション・ガイド リリース11.2.1 B56047-02 |
|
 戻る |
 次へ |
TimesTenでは、データへのACID（Atomic: 原子性、Consistent: 一貫性、Isolated: 独立性、Durable: 永続性）アクセスを提供するトランザクションがサポートされています。
TimesTenのトランザクションでは、ANSIシリアライズ可能分離レベルおよびANSIコミット読取り分離レベルがサポートされています。ANSI Serializableは、トランザクションでの最も厳密な分離レベルです。ANSIコミット読取りに設定すると、並行性をより高くできます。デフォルトはコミット読取りです。これは、ほとんどのアプリケーションに適した分離レベルです。
アプリケーションでは、接続属性または接続オプションを使用して必要なトランザクション機能を構成します。分離レベルおよび永続性オプションの設定方法の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の接続属性に関する説明を参照してください。
この章の主な内容は次のとおりです。
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を発行します。
TimesTenリリース11.2.1では、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メソッドを実行します。
表8-1では、いずれかのオプションをもう一方のオプションと組み合せて有効または無効にした場合に実行される動作を示しています。
ロギングおよびロックによって、トランザクションの原子性、一貫性、独自性および永続性（ACID）セマンティクスが保証されます。トランザクションでデータベースのデータが変更されるため、ロックおよびトランザクション・ログによってACIDセマンティクスが次のように保証されます。
ロック: TimesTenでは、トランザクションで書込みを行うデータ項目と、トランザクション分離レベルに応じて、読取りを行うデータ項目に対してロックを取得します。「分離およびロックによる並行性制御」を参照してください。
トランザクション・ログ: データベースへの変更はトランザクション・ログに記録されます。「トランザクションのロギング」を参照してください。
次の表に、TimesTenでのロックおよびトランザクション・ログの使用方法を示します。
| 条件 | 結果 |
|---|---|
| トランザクションが正常に終了した（コミット済）。 |
|
| トランザクションがロールバックされた。 |
|
| システムで障害が発生した（データは未コミット）。 |
|
| アプリケーションでエラーが発生した。 |
|
TimesTenでは、チェックポイントが基本的に含まれていない一時データベースがサポートされています。ただし、トランザクションをロールバックできるようにトランザクション・ログが用意されています。このようなデータベースに対してリカバリが実行されることはありません。一時データベースは、データベースまたはアプリケーションがシャットダウンまたは失敗すると破棄されます。
すべてのTimesTenトランザクションには原子性があります。トランザクションの結果は、データベースに完全に適用されるか、または完全に適用されないかのいずれかになります。原子性は、トランザクションがロールバックされた場合、トランザクション・ログを使用してその結果を元に戻すことで実現されます。ロールバックは、アプリケーションが明示的に実行する場合があります。また、障害が発生した時点でトランザクションがコミットされていなかったために、データベースのリカバリ中に実行される場合もあります。
TimesTen Data Managerは、チェックポイント処理およびトランザクション・ロギングの組合せによる永続性を備えています。
チェックポイント処理では、現在のインメモリー・データベース・イメージがディスク上のチェックポイント・ファイルに書き込まれ、チェックポイント処理時点でコミットされているすべてのトランザクションが永続的になります。
すべてのトランザクションは、インメモリー・トランザクション・ログ・バッファに記録され、次のいずれかの方法でディスクに書き込まれます。
次の項では、TimesTenアプリケーションの永続性オプションについて説明します。
永続性は、チェックポイント処理とロギングの組合せで実装されます
チェックポイント・ファイル: チェックポイント処理では、現在のデータベース・イメージがディスク上のチェックポイント・ファイルに書き込まれ、チェックポイント処理以前にコミットされたすべてのトランザクションの結果に永続性が与えられます。
トランザクション・ログ・ファイル: 最後のチェックポイント後にコミットされたトランザクションに対しては、従来のロギングによる方法によって永続性が与えられます。トランザクションが処理されるたびに、そのトランザクションによるデータベースの変更内容がインメモリー・トランザクション・ログに記録されます。コミットが行われると、トランザクション・ログ内の該当部分がディスクにフラッシュされます。このログ・フラッシュ処理によって、該当するトランザクションおよび以前コミット済のすべてのトランザクションに永続性が与えられます。
トランザクション・ログ・データがディスクに永続的に書き込まれると、アプリケーションに制御が戻ります。永続的にコミットされたトランザクションは、システム障害が発生しても失われることはありません。
永続性の保証を有効にするには、アプリケーションでDurableCommits属性を1に設定します。
最新のチェックポイント・イメージがトランザクション・ログとともに使用され、トランザクションに一貫性がある最新の状態でデータベースが再構築されます。
|
注意: あるトランザクションを永続的にコミットすると、そのトランザクションだけでなく、以前のすべてのトランザクションが永続的になります。非永続トランザクションは、永続的にコミットされたトランザクションと同様、データベース障害の発生時にも失われる可能性はありません。 |
ほとんどのトランザクションが永続的にコミットされた場合、LogFlushMethod初期接続属性を2に設定する場合があります。この接続属性では、TimesTenでログ・データをトランザクション・ログ・ファイルに書き込む方法および同期する方法を構成します。詳細は、「永続コミットの適切な使用」を参照してください。
永続性遅延モードでは、永続性保証モードの場合と同様に、トランザクションによってデータベースが変更されるたびに、インメモリー・トランザクション・ログにレコードが書き込まれます。ただし、トランザクションが永続性遅延モードでコミットされると、そのトランザクションはディスクへのトランザクション・ログの書込みを待機せず、制御がアプリケーションに戻されます。このため、非永続トランザクションはデータベースで障害が発生した場合に失われる可能性があります。ただし、永続トランザクションに比べて実行にかかる時間がかなり短縮されます。最終的にトランザクションは、データベースのサブデーモン・プロセスによりディスクにフラッシュされます。またはインメモリー・ログ・バッファに空きがない場合にもフラッシュされます。
アプリケーションではDurableCommits属性を0に設定して、永続性遅延モードをリクエストします。これはデフォルトかつ推奨するオプションです。永続性遅延を使用している接続と、永続性保証を使用している接続を共存させることができます。
永続性遅延モードによるパフォーマンス上の利点が必要で、わずかな数のトランザクションであれば失うことを許容できるアプリケーションの場合は、バックグラウンドで永続コミットを定期的に実行できます。この場合、最後の永続コミット後に非永続的にコミットしたトランザクションのみが、システム障害が発生すると失われる可能性があります。
複数の同時実行トランザクションをグループ・コミットすると、永続コミットのパフォーマンス・コストを低下します。多くのスレッドを同時に実行する場合で、そのスレッドが短時間のトランザクションである場合は、ほとんど同時にコミットされる場合があります。その後、1回のディスク書込みによって同時トランザクションのグループが永続コミットされます。グループ・コミットでは、いずれのコミット処理のレスポンス時間も向上しません（永続コミットのたびに、ディスク書込みの終了を待機する必要があります）。ただし、一連の同時トランザクションのスループットは大幅に向上します。
TimesTenでは、永続コミットが頻繁に使用される場合、トランザクションが短時間であるかぎり、CPUの数を超える数の接続をサポートできます。これは、それぞれの接続で、CPUを使用する時間よりコミットの完了を待つ時間の方が長いため可能になります。または、永続コミットが頻繁に実行されないアプリケーションでは、各接続のワークロードに対するTimesTen関連のCPU使用率が非常に高くなります。
最適なレスポンス時間を必要としない、トランザクションの多少の消失は許容できるアプリケーションでは、定期的な永続コミットの実行を選択できます。これにより、非永続的にコミットされているすべてのトランザクションに比べて、トランザクションが失われる可能性は低くなります。永続コミットをn個のトランザクションごとにのみ実行するか、またはn秒ごとに実行すると、トランザクションの消失の可能性がある時間枠を小さくし、レスポンス時間を短縮できます。ユーザーは、金融取引を扱うトランザクションなど、消失の危険があるクリティカルなトランザクションを永続的にコミットすることもできます。
定期的な永続コミットを有効にするために、アプリケーションで次のことが実行されます。
属性DurableCommits=0を設定して接続します。これにより、トランザクションが非永続的にコミットされます。
永続コミットが必要な場合は、コミットする前にアプリケーションから組込みプロシージャttDurableCommitをコールできます。ttDurableCommit組込みプロシージャは、実際にトランザクションはコミットしません。コミットの実行時にそのコミットに永続性を与えるのみです。
トランザクション・ログには、各データベースの更新、コミットおよびロールバックに関するログ・レコードが含まれます。データベースごとにトランザクション・ログが1つ作成され、すべての同時接続によって共有されます。
TimesTenでは、各データベースの更新、コミットおよびロールバックに関するトランザクション・ログ・レコードが作成されます。ただし、読取り専用のトランザクションにトランザクション・ログ・レコードは生成されません。ログ・レコードはまず、データベースと同じ共有メモリー・セグメントに格納されているトランザクション・ログ・バッファに書き込まれます。その後、ログ・バッファの内容はディスク上の最新のトランザクション・ログ・ファイルにフラッシュされます。
トランザクション内で行ったすべての更新はトランザクション・ログを使用して追跡され、トランザクションがロールバックされると、それらの更新は元に戻すことができます。
トランザクション・ロギングによって、システム障害の発生後、最後のチェックポイント処理を実行した時点からコミットされたトランザクションを、チェックポイント・ファイルやトランザクション・ログからリカバリできます。ログ・バッファ内にあるコミットされた非永続トランザクションで、ディスクにフラッシュされていないものは、システム障害が発生すると失われる可能性があります。
次の項では、トランザクション・ログ・バッファおよびファイルの構成方法について説明します。
トランザクション・ログ・バッファ: 各データベースにはトランザクション・ログ・ファイルが1つあり、トランザクション・ログ・バッファのサイズはDSN属性LogBufMBを使用して構成できます。各トランザクション・ログ・バッファは複数のストランドを持つことができます。トランザクション・ログ・バッファのストランド数は、LogBufParallelism属性で構成します。
トランザクション・ログ・ファイル: トランザクション・ログ・ファイルの最大サイズは、DSN属性LogFileSizeを使用して設定できます。すべてのトランザクション・ログ・ファイルは、LogDir属性で別の場所が指定されていないかぎり、チェックポイント・ファイルと同じディレクトリに作成されます。トランザクション・ログ・ファイル名は、ds_name.lognという形式になっています。ds_nameは、DSN属性DataStoreによって指定され、データベースのDSNで表示されるデータベース・パス名です。接尾辞のnは、トランザクション・ログ・ファイル番号で、0から始まります。
|
注意: TimesTenでは、パフォーマンスを最適にするため、アプリケーションでLogDir属性を使用して、トランザクション・ログ・ファイルをチェックポイント・ファイルとは別の物理デバイスに格納することをお薦めします。別の場所に格納することで、チェックポイントのI/O操作とトランザクション・ログに対するI/O操作が相互にブロックすることがなくなります。 |
次の項では、トランザクションの分離レベルおよびロック・レベルについて説明します。
トランザクションに独立性があることで、アクティブな各トランザクションは、他のアクティブなトランザクションがシステム内に存在していない場合と同様に動作できます。分離レベルでは、読取り処理の実行時に行レベル・ロックを設定するかどうかを決定します。表を更新するために文が発行されると、更新トランザクションが完了し、ロックが解除されるまで、他のトランザクションが同じデータを変更しないようにロックが設定されます。
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シリアライズ可能分離レベル: トランザクション内で読取り処理または書込み処理によって設定されたすべてのロックは、トランザクションがコミットまたはロールバックされるまでそのままになります。読取り処理によって書込み処理がブロックされ、書込み処理によって読取り処理がブロックされます。そのため、あるトランザクションで読み取られた行は、そのトランザクションが終了するまで、別のトランザクションから更新または削除することはできません。同様に、あるトランザクションによって挿入、更新または削除された行は、そのトランザクションが終了するまで、別のトランザクションからはアクセスできません。
シリアライズ可能分離レベルでは、同時実行性が低下するかわりに、リピータブル・リードが実現し、分離度が向上します。同じ問合せを同じトランザクション内で複数回実行するトランザクションは、毎回同じ結果セットが戻されることが保証されます。他のトランザクションで、戻された行に対してUPDATEまたはDELETEを実行することはできません。また、問合せ条件を満たす新しい行に対してINSERTを実行することもできません。
分離レベルをシリアライズ可能に設定するには、次のいずれかの処理を行います。
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に設定すると、オプティマイザで行ロックの使用を選択できます。
表レベル・ロック: 表レベル・ロックは、同時実行トランザクションで他の表にアクセスする場合や、トランザクションで特定の表のほとんどの行にアクセスする場合にお薦めします。表レベル・ロックでは、データベース・レベル・ロックに比べ、同時実行性が高くなります。行レベル・ロックでは、表レベル・ロックに比べ、同時実行性が高くなります。表レベル・ロックでは、一時パーティションにわずかな領域があれば、ロック情報を保存できます。
表レベル・ロックでは、次の場合に最大のパフォーマンスが得られます。
問合せで表の多数の行にアクセスする場合
表にアクセスする同時トランザクションの数が非常に少ない場合
一時領域が不十分で、大量の挿入または削除などの処理で設定する可能性がある行ロックをすべて格納できない場合
表レベル・ロックを有効にするには、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ではチェックポイント処理中、どのチェックポイント・ファイルに一貫性のある最新のイメージを格納するかを決定してから、データベースの次のインメモリー・イメージを他のファイルに書き込みます。したがって、これらの2つのファイルには、最新のデータベース・イメージおよびその1つ前のデータ・ストア・イメージのいずれかが含まれていることになります。
TimesTenでは、一貫性のある最新のチェックポイント・ファイルとトランザクション・ログを使用して、データベースをシャットダウン後またはシステム障害発生後の、トランザクションに一貫性のある最新の状態にリカバリします。この処理中にエラーが発生した場合、または新しい方のチェックポイント・イメージが不完全な場合は、もう一方のチェックポイント・ファイルを使用してリカバリが再度開始されます。
また、TimesTenによって、各データベースにdsName.resnファイルが作成されます。これらのファイルは、トランザクション・ログ・ファイルと同じサイズに事前に割り当てられています。.resファイルには、トランザクション・ログ・ディレクトリに空きがない場合に使用される、事前割当て済の領域が含まれています。その場合、トランザクションで新しいログ・レコードを書き込むことはできません。トランザクションがこのような書込みを行おうとすると、強制ロールバックが実行されます。
TimesTenでは、2つのタイプのデータベース・チェックポイント処理がサポートされています。
ファジー・チェックポイント（非ブロッキング・チェックポイント）では、チェックポイント処理の実行中にデータベースに対してトランザクションを実行できます。ファジー・チェックポイントでは、ロックは設定されません。このため、他のデータベース・アクティビティへの影響は最小限になります。トランザクションはチェックポイント処理が進行中でもデータベースを変更できるため、作成されるチェックポイント・ファイルにコミット・トランザクションと非コミット・トランザクションの両方が含まれる場合があります。また、チェックポイント・イメージの全体に、同一時点の状態が反映されているとはかぎりません。たとえば、ある部分は、あるトランザクションのコミット前に書き込まれ、別の部分は、コミット後に書き込まれる場合があります。ファジー・チェックポイントという用語は、データベース・イメージの状態がファジー（あいまい）であることから名付けられています。
ファジー・チェックポイント処理でチェックポイント・ファイルが生成された際にデータベースをリカバリするには、TimesTenでは、データベースをトランザクションに一貫性のある最新の状態にリカバリするために、一貫性がある最新のチェックポイント・ファイルとトランザクション・ログが必要になります。
トランザクション一貫性チェックポイント（ブロッキング・チェックポイントとも呼ばれる）では、チェックポイント処理の一部でデータベースに排他ロックが設定され、その間はデータベースへのアクセスがブロックされます。その結果得られるチェックポイント・イメージには、チェックポイント処理でデータベースを排他ロックしたときより前のすべてのコミット済トランザクションが含まれます。データベース・ロックが保持されている間はアクティブなトランザクションが許容されないため、実行中のトランザクションで行われた変更はチェックポイント・イメージに含まれません。
TimesTenでは、一貫性のある最新のチェックポイント・ファイルを使用して、データベースを最後のチェックポイント処理が正しく終了した時点の、トランザクションに一貫性のある最新の状態にリカバリします。また、トランザクション・ログ・ファイルを使用して、データベースをシャットダウン後またはシステム障害発生後の、トランザクションに一貫性のある最新の状態にリカバリします。
トランザクション一貫性チェックポイントをリクエストするには、アプリケーションでttCkptBlocking組込みプロシージャを使用します。実際のチェックポイント処理は、リクエストを行ったトランザクションがコミットまたはロールバックされてから実行されます。両方のチェックポイント・ファイルがすでに最新となっているデータベースに対してトランザクション一貫性チェックポイントをリクエストすると、そのリクエストは無視されます。
TimesTenチェックポイントのデフォルト動作は次のとおりです。
TimesTenでは、定期的なファジー・チェックポイント処理がバックグラウンドで実行されます。この動作は変更できます。詳細は、「バックグラウンドのチェックポイント処理の設定または無効化」を参照してください。
TimesTenでは、データベースをメモリーからアンロードする直前に、データベースに対してトランザクション一貫性チェックポイント処理を実行します。「トランザクション一貫性チェックポイント」を参照してください。
次の接続属性および組込みプロシージャを使用して、チェックポイントを管理および監視できます。
CkptFrequency属性
CkptLogVolume属性
CkptRate属性
ttCkpt組込みプロシージャ
ttCkptBlocking組込みプロシージャ
ttCkptConfig組込みプロシージャ
ttCkptHistory組込みプロシージャ
次の項では、チェックポイント処理の管理方法について説明します。
デフォルトのTimesTenでは、定期的なファジー・チェックポイント処理がバックグラウンドで実行されます。このため、アプリケーションで手動チェックポイントを発行する必要はほとんどありません。ただし、手動チェックポイントを発行する必要がある場合は、ttCkpt組込みプロシージャをコールしてファジー・チェックポイントをリクエストするか、またはttCkptBlocking組込みプロシージャをコールしてトランザクション一貫性チェックポイントをリクエストできます。
属性または組込みプロシージャを使用すると、トランザクション・ログ・ファイルの特定の量のデータが含まれた時点でチェックポイント処理を実行するか、特定の頻度でチェックポイント処理を実行するかを構成できます。
TimesTenでチェックポイント処理を構成するには、次の処理を行います。
CkptFrequencyおよびCkptLogVolume接続属性を次のように構成します。
CkptFrequency接続属性で、TimesTenがバックグラウンド・チェックポイント処理を実行する頻度（秒）を制御します。デフォルトは600秒です。
CkptLogVolume接続属性で、次回のバックグラウンド・チェックポイント処理までにログに収集するデータ量（MB）を制御します。このデータ量を増やすと、チェックポイント処理の頻度を減らすことができます。デフォルトは0です。
バックグラウンドのチェックポイント処理を無効にするには、CkptFrequencyおよびCkptLogVolume接続属性を0に設定します。
または、ttCkptConfig組込みプロシージャを実行して、バックグラウンド・チェックポイント処理を構成または無効化できます。ttCkptConfigで設定された値は、接続属性で設定された値より優先されます。
|
注意: デフォルト値および使用方法の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。 |
ttCkptHistory組込みプロシージャを使用して、過去8つのチェックポイント処理に関する情報を表示します。実行中のチェックポイント処理の進行状況は、Percent_Complete列で監視できます。
デフォルトでは、チェックポイント・データがディスクに書き込まれる速度に制限はありません。CkptRate属性またはttCkptConfig組込みプロシージャを使用して、バックグラウンドでチェックポイント・データがディスクに書き込まれる最大速度を設定できます。リカバリ時に行われるチェックポイント処理および最後のチェックポイント処理ではこの速度は保持されず、無制限になります。
|
注意: これらの機能の使用の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。 |
速度を低く設定しすぎると、チェックポイント処理に過度の時間がかかり、次の問題が発生する場合があります。
不要なトランザクション・ログ・ファイルのパージが遅延します。
バックアップ処理の開始が遅延します。
リカバリ時間が増加します。
速度を選択する場合は、通常のチェックポイント処理で書き込まれるデータの量およびチェックポイント処理に通常かかる時間について考慮する必要があります。これらの情報は両方ともttCkptHistory組込みプロシージャを使用して入手できます。
実行中のチェックポイント処理の進行状況をttCkptHistory結果セットのPercent_Complete列で確認した結果、遅すぎると思われる場合は、ttCkptConfig組込みプロシージャをコールして、速度を上げることができます。ttCkptConfigをコールして速度を変更すると、新しい速度は即時に有効になり、実行中のチェックポイント処理に対しても反映されます。
チェックポイント処理速度を計算するには次の処理を行います。
ttCkptHistory組込みプロシージャをコールします。
任意のチェックポイントに対して、終了時間から開始時間を引きます。
書き込まれたバイト数をこの経過時間（秒）で割って1秒当たりのバイト数を取得します。
この数字を1024×1024で割って1秒当たりのMB数を取得します。
チェックポイント処理速度の設定時には、次のことを考慮する必要があります。
指定したチェックポイント処理速度は概算です。チェックポイント処理の実際の速度は、ハードウェア、システム・ロードなどの要因によって、指定した速度より遅くなる場合があります。
前述の方法ではチェックポイント処理速度が実際より低く計算されることがあります。これは、開始時間と終了時間の間に、チェックポイント・ファイルへの使用済ブロックの書込みのみでなく他のチェックポイント処理が含まれるためです。
ttCkptHistoryコールのPercent_Completeフィールドに、チェックポイント処理が実際に完了する前に100%が表示される場合があります。Percent_Completeフィールドには、使用済ブロックの書込み状況のみが表示され、チェックポイント処理終了時の追加のブックキーピングは含まれていません。
また、チェックポイント処理速度を調整する場合は、低速にするとチェックポイント処理により時間がかかり、チェックポイント処理を開始してから次に開始するまでの間の最短時間が事実上長くなるため、チェックポイント処理頻度も調整する必要があります。
