| Oracle® TimesTen In-Memory Databaseオペレーション・ガイド リリース18.1 E98635-05 |
|
 前 |
 次 |
TimesTenでは、データへのACID(Atomic: 原子性、Consistent: 一貫性、Isolated: 独立性、Durable: 永続性)アクセスを提供するトランザクションがサポートされています。次の項では、トランザクション機能を構成する方法について説明します。
TimesTenデータベースに対するすべての処理は、アプリケーション・データへの変更やアクセスを行わない場合でも、トランザクション内で実行します。処理を実行する時点で未処理トランザクションが存在しない場合は、アプリケーションのかわりにトランザクションが自動的に開始します。トランザクションは、明示的または暗黙的なコミットやロールバックによって完了します。完了後は、トランザクションによって取得または開かれたリソース(ロックや結果セットなど)は解放されます。
SQL文またはサポートされているAPI (ODBCやJDBCなど)を使用してトランザクションをコミットまたはロールバックする場合:
現在のトランザクションをコミットすると、そのトランザクションで行われた更新は同時トランザクションで有効になります。
現在のトランザクションをロールバックすると、そのトランザクションで行われたすべての更新が元に戻されます。
読取り専用トランザクションは最小限のリソースを保持するため、すべての読取り処理をコミットする必要はありません。書込み処理を実行するときは、ロックを解放するためにトランザクションをコミットします。可能な場合は、書込みトランザクションの時間を短くしてください。長時間実行トランザクションは、ロックが保持される時間が長くなり、同時実行トランザクションがブロックされるため、同時実行性およびスループットが低下することがあります。また、長時間実行トランザクションによって、トランザクション・ログ・ファイルがパージされずに、ファイル・システムに蓄積されることがあります。
1つの接続で許可される未処理トランザクションは1つのみです。また、オープン状態のトランザクションが存在する場合、接続は明示的に閉じることはできません。
次の項では、アプリケーションで暗黙的なコミット動作が有効か、またはアプリケーションでDML文またはDDL文の暗黙的なコミット動作が必要かを構成する方法を説明します。
自動コミットでは、DML文またはDDL文の後に暗黙的なコミットを発行するかどうかを構成します。一部のデータベースAPI (ODBCやJDBCなど)では自動コミットがサポートされており、これらのAPIを使用する場合はデフォルトで有効になっています。その他のAPI (OCIなど)では、自動コミット機能は提供されません。
自動コミットが有効になっている場合、次の動作が実行されます
暗黙的なコミットは、文が正常に実行された直後に発行されます。
暗黙的なロールバックは、主キー違反など、文の実行が失敗した直後に発行されます。
文によって結果セットが生成された場合、その結果セットおよびトランザクション内で開いている他の結果セットを明示的に閉じるまで、自動コミットは発行されません。結果セットが開いているときに実行された文は、すべての結果セットが閉じられるまでコミットされません。
結果セットのすべての行をフェッチしても、結果セットは自動的に閉じません。結果セットの処理後、コミット読取り分離レベルを使用している場合は結果セットを明示的に閉じる必要があり、シリアライズ可能分離レベルを使用している場合はトランザクションを明示的にコミットまたはロールバックする必要があります。
|
ノート: 永続コミットおよび自動コミットが有効でも、障害が発生した場合または結果セットを閉じる前にアプリケーションが終了した場合は、作業内容が失われることがあります。 |
自動コミットが有効になっている場合に、ODBCまたはJDBCのバッチ処理を使用して、1回のコールで複数行に対してINSERT、UPDATEまたはDELETEを実行すると、コミットはバッチ処理全体が終了してから実行されます。バッチ処理中にエラーが発生した場合は、正常に変更された行がこのトランザクション内でコミットされます。特定の行の問題が原因でエラーが発生した場合は、エラーが発生した行の前の行で、正しく変更された行のみがこのトランザクション内でコミットされます。ODBC SQLParamOptions関数のpirowパラメータには、バッチで問題が発生した行の番号が含まれます。
各文の後にコミットを暗黙的に行うと、パフォーマンス・コストが高くなり、煩わしくなる可能性があります。TimesTenでは、すべてのコミットを意図的に行うようにするため、自動コミットを無効にすることをお薦めします。自動コミットを無効にすると、すべての文の後に暗黙的なコミットを実行することはないため、トランザクションの境界を制御したり、1つのトランザクションで複数の文を実行したり、パフォーマンスを向上することができます。
自動コミットを無効にすると、次のいずれかの処理を実行した後に、コミットまたはロールバックでトランザクションを明示的に完了する必要があります。
トランザクションで実行することになっていた作業をすべて完了した後。
トランザクション一貫性(ブロッキング)チェックポイント・リクエストを発行した後。
問合せオプティマイザが使用する列統計および表統計を更新した後。
ttLockWaitなどのプロシージャで指定した新しい設定を有効にするために、結果セットを生成しないTimesTen組込みプロシージャをコールした後。
自動コミット設定を変更する前に、データベース接続を確立する必要があります。自動コミットを無効にするには、次のいずれかの処理をします。
TimesTenデータベースでは、DDL文の前後に暗黙的なCOMMITが発行されます。各DDL文の実行後に永続コミットが実行されます。この動作は、Oracle Databaseと同じです。
表、ビュー、ユーザー、プロシージャ、索引などのデータベース・オブジェクトに対するCREATE、ALTERおよびDROP文。
TRUNCATE
GRANTおよびREVOKE
次の点に注意してください。
DDLによる変更をロールバックできません。
グローバル一時表がON COMMIT PRESERVE ROWS句を使用して作成された場合を除いて、DDL文によってグローバル一時表からレコードが削除されます。
作成した表はCREATE TABLE . . .AS SELECT文を使用した場合、すぐに表示されます。
TRUNCATE文が自動的にコミットされます。ただし、親表および子表は別のトランザクションで切り捨てる必要があり、その際には、子表が先に取り捨てられます。子表が空でなければ、親表は切り捨てられません。
リレーショナル・データベースとして、TimesTenはACIDに準拠しています。
原子性: すべてのTimesTenトランザクションは原子性であり、1つのトランザクションのすべてのデータベース操作が実行されるか、1つも実行されないかのいずれかです。
一貫性: トランザクションは一貫性を保持したままデータベースの状態を変更できます。
独立性: トランザクションは分離されています。TimesTenにはコミット読取りとシリアライズ可能の2つの独立性レベルがあり、これらと行レベルロックを合わせてマルチユーザー並行性制御が提供されます。
永続性: トランザクションを一度コミットすると、コミットされた状態が保たれます。
次の項では、TimesTenがトランザクションのACIDセマンティクスを確認する方法について説明します。
トランザクションでデータベースのデータが変更されるため、ロックおよびトランザクション・ログによってACIDセマンティクスが次のように保証されます。
ロック: TimesTenでは、トランザクションで書込みを行うデータ項目と、トランザクション分離レベルに応じて、読取りを行うデータ項目に対してロックを取得します。詳細は、「分離およびロックによる並行性制御」を参照してください。
トランザクションのロギング: すべてのTimesTenトランザクションはアトミックです。トランザクションの結果は、データベースに完全に適用されるか、完全に適用されないかのいずれかになります。データベースへの変更はトランザクション・ログに記録されます。原子性は、トランザクションがロールバックされた場合、トランザクション・ログを使用してその結果を元に戻すことで実現されます。ロールバックは、アプリケーションが明示的に実行したり、障害が発生した時点でトランザクションがコミットされていなかったために、データベースのリカバリ中に実行される場合もあります。詳細は、「トランザクションのロギング」を参照してください。
次の表に、TimesTenでのロックおよびトランザクション・ログの使用方法を示します。
| 条件 | 結果 |
|---|---|
| トランザクションが正常に終了した(コミット済)。 |
|
| トランザクションがロールバックされた。 |
|
| システムで障害が発生した(データは未コミット)。 |
|
| アプリケーションでエラーが発生した。 |
|
TimesTenは、チェックポイント処理およびトランザクション・ロギングの組合せによる一貫性と永続性を備えています。
チェックポイント処理では、現在のインメモリー・データベース・イメージがファイル・システムのチェックポイント・ファイルに書き込まれます。
TimesTen Classicでは、チェックポイント処理が正常に行われると、チェックポイント処理時点でコミットされているすべてのトランザクションが一貫性を備え、永続的になります。
TimesTen Scaleoutでは、データベース内のデータは複数の要素に分散されます。各要素は、独自のチェックポイントおよびトランザクション・ログ・ファイルを保持します。その結果、各要素に格納されたデータは独立して永続します。
グリッド内の各データ・インスタンスはデータベースの1つの要素を管理します。障害が発生した場合は、1つのデータ・インスタンスでチェックポイント・ファイルおよびトランザクション・ログ・ファイルから、その要素に格納されているデータを自動的にリカバリでき、残りのデータ・インスタンスでアプリケーションの提供を続行します。K-safety値が2以上の場合は、障害が発生した要素をレプリカ・セット内の別の要素からリカバリできます。
すべてのトランザクションは、インメモリー・トランザクション・ログ・バッファに記録されます。これは、永続トランザクションまたは非永続トランザクションのいずれかを使用してファイル・システムに書き込まれます。詳細は、「永続性オプション」を参照してください。
TimesTenのトランザクションでは、ANSIシリアライズ可能分離レベルおよびANSIコミット読取り分離レベルがサポートされています。ANSIシリアライズ可能分離レベルは、最も厳密なトランザクションの分離レベルです。ANSIコミット読取りに設定すると、同時実行性をより高くできます。デフォルトはコミット読取りで、これはほとんどのアプリケーションに適した分離レベルです。
次の項では、トランザクションの分離レベルおよびロック・レベルについて説明します。
トランザクションに独立性があることで、アクティブな各トランザクションは、他のアクティブなトランザクションがシステム内に存在していない場合と同様に動作できます。分離レベルでは、読取り処理の実行時に行レベル・ロックを設定するかどうかを決定します。表を更新するために文が発行されると、更新トランザクションがコミットまたはロールバックされてそのロックが解放されるまで、他のトランザクションが同じデータを変更しないようにロックが設定されます。
Isolation接続属性では、接続の分離レベルを設定します。分離レベルをトランザクション中に変更することはできません。
TimesTenでは、次の2つのトランザクション分離レベルがサポートされています。
ANSIコミット読取り分離: コミット読取り分離レベルは、ほとんどのアプリケーションに適した処理モードで、デフォルト・モードでもあります。これによって、データを読み取っているトランザクションを、同じデータを更新している他のトランザクションと同時に実行できるようになります。TimesTenでは、データ項目の複数のバージョンが作成されるため、シリアライズ可能ではない読取りおよび書込み処理をパラレルで実行できます。
同じデータの読取りおよび書込みが行われる場合も、読取り処理により書込み処理がブロックされることも、書込み処理により読取り処理がブロックされることもありません。読取り処理では、スキャンされた行にロックを設定しません。書込み処理では、トランザクションがコミットまたはロールバックされるまで、ロックを設定します。読取りユーザーはコミットされたデータのコピーを共有し、書取りユーザーは非コミット・バージョンを保有します。したがって、実行中のトランザクションによって更新処理が行われている項目を別のトランザクションで読み取ると、その項目のコミットされたバージョンが表示されます。処理中のトランザクションの非コミット・バージョンは表示されません。
コミット読取り分離レベルでは、トランザクション内の非リピータブル・リードまたはファントム行のため分離度が低下するかわりに、同時実行性が向上します。アプリケーションが同じトランザクション内で同じ問合せを何度も実行すると、別のトランザクションからの更新のコミットによって、2番目の読取り処理の結果が別のものになることがあります。トランザクション時に読取りのロックが早く解放されると、ファントム行が同じトランザクション内の2つの異なる読取り処理に(変更された形式で)表示される可能性があります。
コミット読取り分離レベルを設定するには(このデフォルト設定が変更されている場合)、次のいずれかの処理を行います。
Isolation接続属性を1に設定して接続します。この値は、ALTER SESSION SQL文で変更することもできます。
ALTER SESSION SET ISOLATION_LEVEL=READ COMMITTED;
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のIsolationに関する項または『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER SESSIONに関する項を参照してください。
ttIsqlを使用している場合は、isolation 1またはisolation READ_COMMITTEDを実行します。
ODBCアプリケーションで、SQL_TXN_ISOLATIONフラグをSQL_TXN_READ_COMMITTEDに設定し、ODBC関数SQLSetConnectOptionを実行できます。詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』のODBC 2.5 SQLSetConnectOptionおよびSQLGetConnectOptionのオプションのサポートに関する項を参照してください。
JDBCアプリケーションで、ConnectionオブジェクトのsetTransactionIsolation JDBCメソッドをTRANSACTION_READ_COMMITTEDに対して実行できます。
ANSIシリアライズ可能分離レベル: トランザクション内で読取り処理または書込み処理によって設定されたすべてのロックは、トランザクションがコミットまたはロールバックされるまでそのままになります。読取り処理によって書込み処理がブロックされ、書込み処理によって読取り処理がブロックされます。ただし、読取り処理は他の読取り処理をブロックしません。
最初のトランザクションが行を読み取る場合、2番目のトランザクションもその行を読み取ることができます。
最初のトランザクションによって読み取られた行は、最初のトランザクションがコミットまたはロールバックされるまで、2番目のトランザクションは更新または削除できません。ただし、2番目のトランザクションは、最初のトランザクションによってロックされている範囲外の行を挿入できます。たとえば、最初のトランザクションが行1から行10を読み取っている場合、2番目のトランザクションは行1から行10を更新できません。ただし、2番目のトランザクションは10より後の行に挿入できます。
最初のトランザクションによって挿入、更新または削除された行には、その最初のトランザクションがコミットまたはロールバックされるまで、2番目のトランザクションはどのような方法でもアクセスできません。
シリアライズ可能分離レベルでは、同時実行性が低下するかわりに、リピータブル・リードが実現し、分離度が向上します。同じ問合せを同じトランザクション内で複数回実行するトランザクションは、毎回同じ結果セットが戻されることが保証されます。他のトランザクションで、戻された行を更新したり、削除したり、問合せ条件を満たす新しい行に対して挿入を実行することもできません。
分離レベルをシリアライズ可能分離に設定するには、次のいずれかの処理を行います。
Isolation接続属性を0に設定して接続します。この値は、ALTER SESSION SQL文で変更することもできます。
ALTER SESSION SET ISOLATION_LEVEL=SERIALIZABLE ;
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のIsolationに関する項または『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER SESSIONに関する項を参照してください。
ttIsqlを使用している場合は、isolation 0またはisolation SERIALIZABLEを実行します。
ODBCアプリケーションで、SQL_TXN_ISOLATIONフラグをSQL_TXN_SERIALIZABLEに設定し、ODBC関数SQLSetConnectOptionを実行できます。
JDBCアプリケーションで、ConnectionオブジェクトのsetTransactionIsolation JDBCメソッドをTRANSACTION_SERIALIZABLEに対して実行できます。
マテリアライズド・ビューを常に一貫性がある状態に保つために、すべてのビュー・メンテナンス処理は、トランザクションがコミット読取り分離レベルの場合も、シリアライズ可能分離レベルで実行されます。これは、トランザクションで、ビュー・メンテナンス時に読み取られるすべてのデータ項目に読取りロックを設定することを意味します。ただし、読取りロックは、トランザクションが終了するまで保持されるのではなく、ビュー・メンテナンス処理をトリガーしたINSERT、UPDATE、CREATE VIEW文が終了すると解除されます。
|
ノート: ttXactAdminユーティリティで生成されるレポートには、すべての未処理トランザクションに関するロックの保持と待機が表示されます。このレポートは、処理がブロックされたロックの競合問題、またはロック・タイムアウトおよびデッドロックなどのエラーが発生した場合、トラブルシューティングに使用できます。また、特定のトランザクションをロールバックする場合にも使用できます。 |
TimesTenでは、行レベル・ロック、表レベル・ロックおよびデータベース・レベル・ロックがサポートされています。
異なるロック・レベルの異なる接続が同時に存在することは可能ですが、データベース・レベルのロックを使用する接続が1つでもある場合は、同時実行性が低下します。パフォーマンスの詳細は、「最適なロック方法の選択」を参照してください。
|
ノート: 同じトランザクション内で複数のロックが取得されている場合、トランザクションが終了すると、ロックは順次解放されます。 |
行レベル・ロック: 通常、トランザクションはアクセスする各行にロックを設定します。行レベル・ロックは、同時実行性制御の粒度が最も細かくなるため、処理モードとしてお薦めします。同時実行トランザクションで、同じ表の異なる行を更新できます。ただし、行レベル・ロックには、データベースの一時メモリー領域にロック情報を保存するための領域が必要になります。
行レベル・ロックはデフォルトです。ただし、別のタイプのロックに変更されている場合で、行レベル・ロックを再度有効にする場合は、次のいずれかの処理を行います。
LockLevelの接続属性を0に設定します。
TimesTen Classicでは、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に設定します。
TimesTen Classicでは、lockLevelパラメータをDSに設定してttLockLevel組込みプロシージャをコールします。このプロシージャは、次のトランザクション、およびこの接続でその後に実行されるすべてのトランザクションの行レベル・ロックとデータベース・レベル・ロックを変更します。
LockWait接続属性を、文がロックの設定を待機する、この時間をすぎるとタイムアウトする最長時間に設定します。デフォルトは10秒です。トランザクション内の文がロックを待機していて、ロック待機時間が過ぎた場合は、エラーが戻されます。エラーを受信した後、アプリケーションは文を再発行できます。
ロック・タイムアウトを検出するためのデータベースの管理サブデーモン・プロセスのスケジュールにより、ロック待機時間は正確ではありません。タイムアウトが0秒に設定されている場合はすぐにレポートされるため、不正確ではありません。ロック待機時間は、ブロッキング・チェックポイントには適用されません。
データベースの管理サブデーモン・プロセスでは、同時実行トランザクションの中にデッドロックがないか、2秒ごとにデータベースをチェックします。デッドロックが発生した場合、デッドロック・サイクルに入ったトランザクションのうちの1つにエラーが戻されます。デッドロックが発生したもう一方のトランザクションが実行できるようになるには、エラーを受け取ったトランザクションをロールバックする必要があります。
ロック競合の可能性が高いワークロードを実行する際には、LockWait接続属性を小さい値に設定してアプリケーションに制御を迅速に戻すか、LockWaitを大きな値に設定してロック付与率を増加する(スループットが減少するリスクがある)ことを検討してください。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のLockWaitに関する説明を参照してください。
チェックポイント処理では、データベースのインメモリー・イメージを、チェックポイント・ファイルと呼ばれるファイルに保存します。デフォルトでは、TimesTenはバックグラウンドのチェックポイント処理を一定間隔で実行します。チェックポイント処理の実行時、データベースのサイズおよび最新のチェックポイント以降に行われたデータベースへの変更の回数に応じて、大量のI/Oアクティビティが発生し、実行時間が長くなる場合があります。
次の項では、チェックポイント処理およびその管理方法について説明します。
チェックポイント処理には、2つの主な目的があります。
リカバリを開始できるデータベース・イメージをより最新の状態で提供するため、データベース・リカバリの所要時間を短縮します。
トランザクション・ログの一部を将来のデータベースのリカバリ処理で不要にします(通常は、これで1つ以上のトランザクション・ログ・ファイルを削除できます)。
これらの2つの機能は、TimesTenアプリケーションにとって非常に重要です。リカバリ時間の短縮は、データベースのリカバリに必要なトランザクション・ログの量が、システム障害の発生後にアプリケーションで発生するダウンタイムに直接影響するため重要になります。不要なトランザクション・ログ・ファイルの削除は、新しいトランザクション・ログ・ファイルで使用可能なファイル・システム領域を解放できるため重要になります。これらのファイルがパージされなかった場合、最終的に、これらのファイルによってトランザクション・ログ・ファイル・ディレクトリのすべての使用可能領域が消費され、ログ領域不足のためデータベース処理が失敗することになります。
TimesTenでは、データベースごとに2つのチェックポイント・ファイル(dsname.ds0およびdsname.ds1)が作成されます。dsnameは、データベースDSNで指定されたデータベース・パス名およびファイル名の接頭辞です。TimesTenは、チェックポイント処理中、どのチェックポイント・ファイルに一貫性のある最新のイメージが格納されているかを決定してから、データベースの次のインメモリーのイメージをもう1つのファイルに書き込みます。したがって、これらの2つのファイルには、最新の2つのデータベース・イメージが含まれることになります。
TimesTen Classicでは、データベースに、チェックポイント・ファイルとトランザクション・ログ・ファイルのセットが1つ保持されます。
TimesTen Scaleoutでは、各要素に、専用の独立したチェックポイント・ファイルとトランザクション・ログ・ファイルのセットが保持されます。詳細は、『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』のTimesTen Scaleoutでの分散トランザクションの理解に関する項を参照してください。
データベースの停止後またはシステム障害発生後に、最新のチェックポイント・ファイルとトランザクション・ログ・ファイルを使用して、トランザクションに一貫性のある最新の状態にデータベースをリカバリします。(最新のトランザクション・ログ・ファイルは、チェックポイント処理以降に書き込まれたトランザクション・ログ・ファイルです)。この処理中にエラーが発生した場合、または新しい方のチェックポイント・イメージが不完全な場合は、もう一方のチェックポイント・ファイルを使用してリカバリが再度開始されます。トランザクション・ロギングの詳細は、「トランザクションのロギング」を参照してください。
TimesTenでは、最新のチェックポイント・ファイルを使用して、データベースを最後のチェックポイント処理が正しく終了した時点の、トランザクションに一貫性のある最新の状態にリカバリします。トランザクション・ログ・ファイルを使用して、データベースをシャットダウン後またはシステム障害発生後の、トランザクションに一貫性のある最新の状態にリカバリします。
TimesTenでは、2つのタイプのデータベース・チェックポイント処理がサポートされています。
ファジー・チェックポイント(非ブロッキング・チェックポイント)では、チェックポイントの処理中にデータベースに対してトランザクションを実行できます。ファジー・チェックポイントでは、ロックを取得しないので、他のデータベース・アクティビティへの影響は最小限になります。チェックポイントの処理中でもトランザクションによってデータベースが変更されるので、作成されるチェックポイント・ファイルにコミット・トランザクションと非コミット・トランザクションの両方が含まれてしまう場合があります。また、チェックポイント・イメージの別の部分では、別の時点のものが反映される可能性もあります。たとえば、ある部分は、あるトランザクションのコミット前に書き込まれ、別の部分は、コミット後に書き込まれる場合があります。ファジー・チェックポイントという用語は、データベース・イメージの状態があいまいであることに由来します。
ファジー・チェックポイント処理でチェックポイント・ファイルが生成された際にデータベースをリカバリするには、TimesTenでは、データベースをトランザクションに一貫性のある最新の状態にリカバリするために、最新のチェックポイント・ファイルとトランザクション・ログが必要になります。
TimesTenチェックポイントのデフォルト動作は次のとおりです。
TimesTenでは、定期的なファジー・チェックポイント処理がバックグラウンドで実行されます。この動作は変更できます。詳細は、「バックグラウンドのチェックポイント処理の設定または無効化」を参照してください。
TimesTenでは、データベースをメモリーからアンロードする直前に、データベースに対してブロッキング・チェックポイント処理を実行します。詳細は、「ブロッキング・チェックポイント」を参照してください。
次の項では、チェックポイント処理の管理方法について説明します。
デフォルトのTimesTenでは、定期的なファジー・チェックポイント処理がバックグラウンドで実行されます。このため、アプリケーションで手動チェックポイントを発行する必要はほとんどありません。ただし、アプリケーションでTimesTen Classicデータベースに対して手動チェックポイントを発行する場合は、ttCkpt組込みプロシージャをコールしてファジー・チェックポイントをリクエストするか、またはttCkptBlocking組込みプロシージャをコールしてブロッキング・チェックポイントをリクエストできます。ただし、推奨はされていません。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCkptに関する項およびttCkptBlockingに関する項を参照してください。
接続属性または組込みプロシージャを使用すると、チェックポイント処理をトランザクション・ログ・ファイルに特定の量のデータが含まれた時点で実行するか特定の頻度で実行するかを構成できます。
TimesTenでチェックポイント処理を構成するには、次の処理を行います。
CkptFrequencyおよびCkptLogVolume接続属性を次のように構成します。
CkptFrequency接続属性で、TimesTenがバックグラウンド・チェックポイント処理を実行する頻度(秒)を制御します。デフォルトは600秒です。バックグラウンドのチェックポイント処理をCkptLogVolume接続属性で制御する場合は、CkptFrequency接続属性を0に設定します。
CkptLogVolume接続属性で、次回のバックグラウンド・チェックポイント処理までにトランザクション・ログ・ファイルに収集するデータ量(MB)を制御します。このデータ量を増やすと、チェックポイント処理の頻度を減らすことができます。デフォルトは0です。バックグラウンドのチェックポイント処理をCkptLogVolume接続属性で制御する場合は、CkptFrequency接続属性を0に設定します。
ほとんどの場合、CkptFrequencyは、データベース・トランザクションのレートを考慮しないため、CkptFrequencyよりもCkptLogVolumeを使用することをお薦めします。CkptFrequency属性とCkptLogVolume属性の両方が0より大きい値に設定されている場合、チェックポイントは2つの条件のいずれかがtrueになったときに実行されます。
または、ttCkptConfig組込みプロシージャをコールしてバックグラウンド・チェックポイント処理を構成するか、無効化できます。ttCkptConfigで設定された値は、接続属性で設定された値より優先されます。
|
ノート: デフォルト値および使用方法の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptFrequencyに関する説明、CkptLogVolumeに関する説明およびttCkptConfigに関する説明を参照してください。 |
最新の8つのチェックポイントおよびチェックポイント試行に関する情報を表示するには、SYS.GV$CKPT_HISTORYまたはSYS.V$CKPT_HISTORYシステム・ビューから選択します。
たとえば、確認できる情報の一部は次のとおりです。
チェックポイント処理にかかる時間(チェックポイント処理の開始時刻から完了時刻を減算)。
チェックポイントのタイプ: ファジー、ブロッキング、静的またはなし。詳細は、チェックポイントのタイプを参照してください。
チェックポイント処理のステータス: 進行中、完了、または失敗。チェックポイント履歴を調べる場合は、最新のチェックポイント処理が失敗したかどうかを確認します(FAILEDというステータスが示される)。チェックポイント処理が失敗した場合、エラーまたはその他の詳細の列に理由が表示されます。
チェックポイントの起動側。ユーザー・レベルのアプリケーション(TimesTenユーティリティを含む)、バックグラウンド・チェックポイント・リクエストまたはデータベースの管理サブデーモンから。
チェックポイント処理が発生した理由。最も一般的な理由は、データベース作成後、リカバリ後、停止後の最終チェックポイント、ユーザーが組込みプロシージャを実行した後、またはフラッシュ処理の後などです。
チェックポイントが失敗した場合の失敗の理由。
一般的なチェックポイント処理によって書き込まれたデータの量(合計バイト数)。
チェックポイント処理速度。提供されるデータからチェックポイント処理速度を計算する方法の詳細は、「チェックポイント処理速度の設定」を参照してください。
完了したチェックポイント処理の割合。処理中のチェックポイントがある場合に、完了したチェックポイントの割合を示します。
このチェックポイント処理によってパージされた実際のトランザクション・ログ・ファイルの数。この列にゼロが表示されている場合でも、トランザクション・ログ・ファイル内のログ・レコードがパージされなかったという意味ではありません。かわりに、トランザクション・ログ・ファイル内のログ・レコードを継続的にパージできます。この列には、ファイル・システム領域の解放時に示される、パージされたトランザクション・ログ・ファイルの実際の数が表示されます。
トランザクション・ログに保持が設定されている場合は、TimesTenで一部のトランザクション・ファイルをパージできないことがあります。たとえば、この値は、長時間実行トランザクションによって、またはトランザクション・ログ・ファイル内でかなり前にレプリケーション・ブックマークがあることが原因で、チェックポイント処理でトランザクション・ログ・ファイルをパージできない場合に示される可能性があります。
1つ以上のトランザクション・ログの削除を妨げているブックマーク名(トランザクション・ログの保持の理由)。この名前は、トランザクション・ログ・ファイルが予想よりも長くファイル・システムに残っている理由を識別するために役立ちます。様々なブックマーク(トランザクション・ログの保持)名の詳細は、「TimesTenのコンポーネントまたは処理によるログの保持」を参照してください。
トランザクション・ログがパージされない理由について十分な背景がこの情報で示されない場合は、ttXactAdmin組込みプロシージャを実行してトランザクション・ログの詳細を知ることもできます。
これらのビューの詳細は、『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』のSYS.GV$CKPT_HISTORYに関する項、SYS.V$CKPT_HISTORYに関する項、SYS.GV$LOG_HOLDSに関する項またはSYS.V$LOG_HOLDSに関する項を参照してください。組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCkptHistoryに関する項、ttLogHoldsに関する項またはttXactAdminに関する項を参照してください。
例7-1 進行中のチェックポイント処理
処理中のチェックポイントの例を次に示します。
% SELECT * FROM SYS.V$CKPT_HISTORY; < 2019-02-05 16:56:34.169520, <NULL>, Fuzzy , In Progress , User , BuiltIn , <NULL>, 0, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, 13, 6, 0, <NULL>, <NULL> > < 2019-02-05 16:55:47.703199, 2019-02-05 16:55:48.188764, Fuzzy , Completed , Checkpointer , Background , <NULL>, 1, 0, 8964304, 294, 33554432, 291, 5677288, 27, 1019512, 1065408, <NULL>, 5, 0, Checkpoint, <NULL> > < 2019-02-05 16:54:47.106110, 2019-02-05 16:54:47.723379, Static , Completed , Subdaemon , FinalCkpt , <NULL>, 0, 0, 8960328, 294, 33554432, 291, 5677288, 256, 33157172, 5321548, <NULL>, 4, 0, Checkpoint, <NULL> > < 2019-02-05 16:54:41.633792, 2019-02-05 16:54:42.568469, Blocking , Completed , User , BuiltIn , <NULL>, 1, 0, 8958160, 294, 33554432, 291, 5677288, 31, 1162112, 6604976, <NULL>, 3, 0, Checkpoint, <NULL> > < 2019-02-05 16:54:37.438827, 2019-02-05 16:54:37.977301, Static , Completed , User , DbCreate , <NULL>, 0, 0, 1611984, 93, 33554432, 92, 1853848, 93, 33554432, 1854052, <NULL>, 2, 0, Checkpoint, <NULL> > < 2019-02-05 16:54:36.861728, 2019-02-05 16:54:37.438376, Static , Completed , User , DbCreate , <NULL>, 1, 0, 1609936, 93, 33554432, 92, 1853848, 93, 33554432, 1854052, <NULL>, 1, 0, Checkpoint, <NULL> >
この例は、ユーザーが開始したチェックポイントである最後のチェックポイントの試行中に発生したエラーを示しています。
% SELECT * FROM SYS.V$CKPT_HISTORY; < 2019-02-05 16:57:14.476860, 2019-02-05 16:57:14.477957, Fuzzy , Failed , User , BuiltIn , 847, 1, <NULL>, <NULL>, 0, 0, 0, 0, 0, 0, 0, <NULL>, 7, 0, <NULL>, Errors 1: TT0847: 16:57:14 (2019-02-05) > < 2019-02-05 16:56:34.169520, 2019-02-05 16:56:59.715451, Fuzzy , Completed , User , BuiltIn , <NULL>, 0, 0, 8966472, 294, 33554432, 291, 5677288, 5, 522000, 532928, <NULL>, 6, 0, Checkpoint, <NULL> > < 2019-02-05 16:55:47.703199, 2019-02-05 16:55:48.188764, Fuzzy , Completed , Checkpointer , Background , <NULL>, 1, 0, 8964304, 294, 33554432, 291, 5677288, 27, 1019512, 1065408, <NULL>, 5, 0, Checkpoint, <NULL> > < 2019-02-05 16:54:47.106110, 2019-02-05 16:54:47.723379, Static , Completed , Subdaemon , FinalCkpt , <NULL>, 0, 0, 8960328, 294, 33554432, 291, 5677288, 256, 33157172, 5321548, <NULL>, 4, 0, Checkpoint, <NULL> > < 2019-02-05 16:54:41.633792, 2019-02-05 16:54:42.568469, Blocking , Completed , User , BuiltIn , <NULL>, 1, 0, 8958160, 294, 33554432, 291, 5677288, 31, 1162112, 6604976, <NULL>, 3, 0, Checkpoint, <NULL> > < 2019-02-05 16:54:37.438827, 2019-02-05 16:54:37.977301, Static , Completed , User , DbCreate , <NULL>, 0, 0, 1611984, 93, 33554432, 92, 1853848, 93, 33554432, 1854052, <NULL>, 2, 0, Checkpoint, <NULL> > < 2019-02-05 16:54:36.861728, 2019-02-05 16:54:37.438376, Static , Completed , User , DbCreate , <NULL>, 1, 0, 1609936, 93, 33554432, 92, 1853848, 93, 33554432, 1854052, <NULL>, 1, 0, Checkpoint, <NULL> >
例7-2 チェックポイントの履歴出力の理解
この例では、ttCkptHistory組込みプロシージャを使用して、チェックポイント履歴から特定の列を選択します。
% SELECT type, reason, bookmarkname, logsPurged FROM ttCkptHistory;; < Fuzzy , BuiltIn , Oldest Transaction Undo, 0 > < Static , FinalCkpt , Checkpoint, 6 > < Blocking , BuiltIn , Checkpoint, 0 > < Blocking , BuiltIn , Checkpoint, 0 > < Blocking , BuiltIn , Checkpoint, 0 > < Blocking , BuiltIn , Backup, 5 > < Blocking , BuiltIn , Backup, 0 > < Blocking , BuiltIn , Backup, 0 >
この例での出力は、増分バックアップによってログ保持が設定されていたため、最も古いチェックポイント処理(表示された最後の行)でトランザクション・ログ・ファイルがパージされなかった(logsPurged列内の0で示される)ことを示しています。バックアップによってトランザクション・ログ・ファイルが蓄積されました。ただし、最終的には、ログ保持が削除され、5つのトランザクション・ログ・ファイルをパージできました。
チェックポイント操作が下から4行目で開始されます。チェックポイント処理により、トランザクション・ログ・ファイルがパージされないようにするログ保持が配置されます。6つのトランザクション・ログ・ファイルが最終チェックポイント(FinalCkpt)操作によってパージされました。
最新のチェックポイント処理で、それが、最も古いトランザクションを元に戻すというログ保持が設定されたファジー・チェックポイントであることが示されます。この保持では、チェックポイント・ログ・パージ操作が通過できない、トランザクションのポイントがマークされます。連続する複数の行にこのメッセージが表示されているときには、これは、長時間実行トランザクションが原因でトランザクション・ログ・ファイルが蓄積される可能性があること示している場合があります。
デフォルトでは、チェックポイント・データがファイル・システムに書き込まれる速度に制限はありません。CkptRate接続属性またはttCkptConfig組込みプロシージャを使用すると、バックグラウンドのチェックポイント・データをファイル・システムに書き込む最高速度を設定できます。リカバリ時に行われるチェックポイント処理および最後のチェックポイント処理ではこの速度は保持されず、無制限になります。
|
ノート: これらの機能の使用の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptRateに関する説明およびttCkptConfigに関する説明を参照してください。 |
速度を低く設定しすぎると、チェックポイント処理に過度の時間がかかり、次の問題が発生する場合があります。
不要なトランザクション・ログ・ファイルのパージが遅延します。
バックアップ処理の開始が遅延します。
設定した速度が高すぎると、チェックポイント処理でファイル・システムのバッファ・キャッシュの帯域幅の消費が多くなりすぎ、次のことが起こる可能性があります。
トランザクション・ログを通常速度でファイル・システムに書き込めなくなるため、データベースのトランザクションのスループット全体が低下します。
ファイル・システムのその他のI/O操作との競合が起こります。
速度を選択する場合は、通常のチェックポイント処理で書き込まれるデータの量およびチェックポイント処理に通常かかる時間について考慮する必要があります。これらの情報は両方とも、SYS.GV$CKPT_HISTORYまたはSYS.V$CKPT_HISTORYシステム・ビュー、あるいはttCkptHistory組込みプロシージャを使用して取得できます。
実行中のチェックポイント処理の進行状況が遅すぎるように思われる場合は、このチェックポイント処理の進行状況をSYS.GV$CKPT_HISTORYまたはSYS.V$CKPT_HISTORYシステム・ビューのPercent_Complete列で評価します。速度を上げるには、ttCkptConfig組込みプロシージャをコールします。ttCkptConfigをコールして速度を変更すると、新しい速度は即時に有効になり、実行中のチェックポイント処理に対しても反映されます。
チェックポイント処理速度を計算します(SYS.GV$CKPT_HISTORYまたはSYS.V$CKPT_HISTORYシステム・ビューを表示するか、ttCkptHistory組込みプロシージャをコールします)。
任意のチェックポイントに対して、終了時間から開始時間を引きます。
書き込まれたバイト数をこの経過時間(秒)で割って1秒当たりのバイト数を取得します。
この数字を1024×1024で割って1秒当たりのMB数を取得します。
チェックポイント処理速度の設定時には、次のことを考慮する必要があります。
指定したチェックポイント処理速度は概算です。チェックポイント処理の実際の速度は、ハードウェア、システム・ロードなどの要因によって、指定した速度より遅くなる場合があります。
前述の方法ではチェックポイント処理速度が実際より低く計算されることがあります。これは、開始時間と終了時間の間に、チェックポイント・ファイルへの使用済ブロックの書込みのみでなく他のチェックポイント処理が含まれるためです。
Percent_Completeフィールドに、チェックポイント処理が実際に完了する前に100%と表示される場合があります。Percent_Completeフィールドには、使用済ブロックの書込み状況のみが表示され、チェックポイント処理終了時の追加のブックキーピングは含まれていません。
また、チェックポイント処理速度を調整する場合は、低速にするとチェックポイント処理により時間がかかり、チェックポイント処理を開始してから次に開始するまでの間の最短時間が事実上長くなるため、チェックポイント処理頻度も調整する必要があります。
デフォルトでは、TimesTenはチェックポイント・ファイルを単一のスレッドでシリアルに読み込みます。CkptReadThreads接続属性を使用して、データベースをメモリーにロードするときTimesTenがチェックポイント・ファイルの読込みに使用するスレッドの数を設定します。
n個のスレッドを使用すると、TimesTenはチェックポイント・ファイルをサイズの等しいn個の部分に分割します。各スレッドが、ファイルの一部を同時にメモリーに読み込みます。すべてのスレッドがチェックポイント・ファイルの各部分を正常に読み込むと、TimesTenはデータベースの一貫性をチェックします。
|
ノート: 詳細は、このマニュアルのCkptReadThreadsの設定に関する項と、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptReadThreadsに関する項を参照してください。 |
TimesTenでは、トランザクションがロールバックされた場合に更新内容を元に戻すことができるように、データベースごとにトランザクション・ログが保持され、各トランザクション内で行われた更新がすべて追跡されます。システム障害発生後の最後のチェックポイント処理の時点から書き込まれた、最新のチェックポイント・ファイルと最新のトランザクション・ログの両方を使用して、トランザクションがリカバリされます。
トランザクション・ログ・レコードは、データベースの変更、コミットおよびロールバックごとに作成されます。ただし、読取り専用のトランザクションにトランザクション・ログ・レコードは生成されません。ログ・レコードはまず、データベースと同じ共有メモリー・セグメントに格納されているトランザクション・ログ・バッファに書き込まれます。その後、ログ・バッファの内容は最新のトランザクション・ログ・ファイルにフラッシュされます。
トランザクション・ログは、論理的に順序付けされた一連のトランザクション・ログ・レコードですが、物理的には、1つ以上の一連のトランザクション・ログ・ファイルと、TimesTenデータベース内のインメモリー・ログ・バッファで構成されています。このログは、すべての同時接続によって共有されます。
次の項では、トランザクション・ログ・バッファおよびファイルの構成方法について説明します。
次の項では、トランザクション・ログ・バッファおよびファイルの構成方法について説明します。
トランザクション・ログ・バッファ: トランザクション・ログ・バッファはデータベースごとに1つあり、トランザクション・ログ・バッファのサイズはDSN接続属性LogBufMBを使用して構成できます。
ストランドにより、トランザクション・ログ・バッファの使用可能メモリーがいくつかの異なる領域に分割され、これらの領域には異なる接続によって同時にアクセスできます。トランザクション・ログ・バッファのストランド数は、LogBufParallelism接続属性で構成します。その後、各接続は、それぞれに独自のトランザクション・ログ・バッファがあるかのように、これらのストランドを使用してデータに依存しないDML文をパラレルで実行できます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のLogBufParallelismに関する項を参照してください。
トランザクション・ログ・ファイル: トランザクション・ログ・ファイルは、LogDir接続属性で指定された場所に作成されます。
|
ノート: LogDir接続属性はオプションであり、指定されていない場合、トランザクション・ログ・ファイルは、チェックポイント・ファイルと同じディレクトリに作成されます。ただし、TimesTenでは、パフォーマンスを最適にするため、LogDir接続属性を使用して、トランザクション・ログ・ファイルをチェックポイント・ファイルとは別の物理デバイスに格納することをお薦めします。別の場所に格納することで、チェックポイントのI/O操作とトランザクション・ログに対するI/O操作が相互にブロックすることがなくなります。
データベースがすでにRAMにロードされており、データベースのトランザクション・ログ・ファイルとチェックポイント・ファイルが同じ物理デバイス上にある場合、TimesTenはデーモン・ログ・ファイルにメッセージを書き込みます。 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のLogDirに関する項および『Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイド』のファイル・システム領域のトランザクション・ログ・ファイルの使用の確認に関する項を参照してください。 |
トランザクション・ログ・ファイルの最大サイズは、LogFileSize DSN接続属性で構成できます。デフォルト値は64MBです。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のLogFileSizeに関する項を参照してください。
トランザクション・ログ・ファイル名は、dsname.lognという形式になっています。dsnameは、DSN接続属性DataStoreによって指定され、データベースのDSN内で示されるデータベース・パス名です。接尾辞のnは、トランザクション・ログ・ファイル番号で、0から始まります。
データベースが作成されると、TimesTenはdsname.res0、dsname.res1、dsname.res2という名前の予約ファイルを作成します。これらのファイルには、予約済トランザクション・ログ領域として機能する事前割当て済の領域が含まれています。予約済トランザクション・ログ領域によって、トランザクション・ログ・ファイルを保持するファイル・システムが一杯になった場合に、トランザクションのロギングを制限付きで継続できます。トランザクション・ログを含むファイル・システムが一杯になった場合は、データベースによって、新しいトランザクションの開始が許可されません。進行中のトランザクションは、コミットまたはロールバックされるまで、予約ファイルを使用して続行できます。進行中のトランザクションがあり、予約ファイルがすべて消費されると、ログ・ファイルを生成するすべてのデータベース操作がブロックされます。
NFSでマウントされたファイル・システム上(Linuxプラットフォーム上のみ)に、TimesTenのチェックポイント・ファイルおよびトランザクション・ログ・ファイルを配置できるようにするには、timesten.confファイルでallow_network_files=1を確認します。allow_network_files=1構成がデフォルト設定です。
詳細は、Oracle TimesTen In-Memory Databaseリファレンスの第1章TimesTenインスタンス構成ファイルのオプション属性を参照してください。
トランザクション・ログ・ファイルが過度に蓄積されないよう、保持されているトランザクション・ログがないことを頻繁に確認することが重要です。非常に多くのトランザクション・ログ・ファイルが蓄積され、利用可能なファイル・システム領域がなくなると、トランザクション・ログの保持が進行して、次のチェックポイント処理によってトランザクション・ログ・ファイルがパージされるまで、TimesTenデータベースでは新しいトランザクションを開始できません。
次の項では、トランザクション・ログ操作、ログの保持、ログ・ファイルの蓄積について説明します。
TimesTenのいくつかのコンポーネントまたは処理によって、トランザクション・ログが保持される場合があります。ある時点以降、トランザクション・ログの保持により、ログ・ファイルは不要になるまでパージされなくなります。通常の場合は、ログの保持の位置は定期的に進行し、ログ・ファイルは適切にパージされます。ただし、処理が正常に動作せず、保持の位置が進まないと、その保持の位置以降にログ・ファイルが過度に蓄積されてパージができなくなり、利用可能なファイル・システム領域がなくなってしまいます。
これらのコンポーネントおよび操作は、次のとおりです。
トランザクション・ログ・ファイルにログ・レコードを書き込むトランザクションがコミットされるか、ロールバックされたとき。これは、ローカル・データベース・トランザクションまたはXAトランザクションのいずれでもかまいません。
トランザクション・ログ・ファイルに記録された変更が、両方のチェックポイント・ファイルに書き込まれたとき。
レプリケーション: 受信側のホストがログ・ファイルを完全に処理したことを送信側のレプリケーション・エージェントが確認するまでトランザクション・ログは保持されます。
次のようなときに、障害状態となることがあります。
ネットワークが停止しているか、スタンバイがクラッシュし、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の増分バックアップ: 増分バックアップを手動で実行するまで、およびそのバックアップが完了するまでログは保持されます。
障害が発生する可能性が高いのは、増分バックアップ(ログ・ファイルを保持しているTimesTenを起動する)を構成しているが、実際には増分バックアップを実行していないため、ログ・ファイルの保持が解放される場合です。
その他には、トランザクション・ログの最新のエントリに対して、増分バックアップが大きく遅れるとき、障害が発生することがあります。たとえば、トランザクション・アクティビティが予期せずに激増した場合、バックアップが非常に古いログ・ファイルを保持しているために、利用可能なトランザクション・ログ用のファイル・システム領域が一杯にならないようにする必要があります。この問題を解決するには、アプリケーションで再度増分バックアップを実行します。
長時間実行のトランザクションまたはXAトランザクション: トランザクションがコミットまたはロールバックされるまで、トランザクション・ログは保持されます。
アプリケーション・トランザクションが長時間コミットまたはロールバックされず、アプリケーションが長時間実行のトランザクションを終了しなければならない場合、障害状態になる場合があります。
または、ttXactAdminユーティリティを-xactIdRollbackオプションを使用して実行すると、トランザクションをロールバックできます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttXactAdminに関する説明を参照してください。
最も古いトランザクションを元に戻す: まだコミットまたはロールバックされていない各トランザクションはログを保持しています。この保持は、トランザクションの最初(最も古い)のログ・レコードから開始され、チェックポイント・ログ・パージ処理が通過できないトランザクションのポイントがマークされます。このログ保持情報は、SYS.GV$CKPT_HISTORYまたはSYS.V$CKPT_HISTORYシステム・ビュー、あるいはttCkptHistory組込みプロシージャの出力から取得できます。
いずれのトランザクション・ログ・ファイルも、TimesTenによってパージ可能と判断されるまで保持されます。通常のTimesTenの処理では、不要なトランザクション・ログ・ファイルはチェックポイントが開始されるたびにパージされます。チェックポイント処理は、CkptFrequency接続属性を使用して構成可能な時間間隔で開始することも、CkptLogVolume接続属性を使用して構成可能なログ・ボリュームで開始することもできます。TimesTen Classicでは、ttCkpt組込み関数を使用して、チェックポイント処理(手動またはバックグラウンドのチェックポイント・アプリケーション・スレッドを使用)を開始することもできます。
ログ・ファイルの累積のためにファイル・システム領域がなくなっている場合は、CkptFrequency接続属性のかわりにCkptLogVolume接続属性を使用します。また、SYS.GV$LOG_HOLDSまたはSYS.V$LOG_HOLDSシステム・ビューから頻繁に選択する場合や、ttLogHolds組込みプロシージャを頻繁にコールする場合は、再利用をブロックするかどうかを指定できます。
|
ノート: パフォーマンスを向上させるために、チェックポイント・ファイルがある物理デバイスとは別の物理デバイスにログ・ファイルを配置します。詳細は、「トランザクション・ログのバッファおよびファイルの管理」を参照してください。 |
チェックポイント処理の一般的な情報は、『Oracle TimesTen In-Memory Database概要』のチェックポイント処理に関する項を参照してください。CkptFrequency接続属性およびCkptLogVolume接続属性の詳細は、「バックグラウンドのチェックポイント処理の構成または無効化」を参照してください。
ログの保留の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のSYS.GV$LOG_HOLDSまたはSYS.V$LOG_HOLDSに関する項、または『Oracle TimesTen In-Memory Databaseリファレンス』のttLogHoldsに関する項を参照してください。
また、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptFrequencyに関する項、CkptLogVolumeに関する項およびttCkptに関する項も参照してください。
トランザクション・ログの過度の蓄積を定期的に監視するオプションは、次のとおりです。
すべてのログの保持の詳細は、SYS.GV$LOG_HOLDSまたはSYS.V$LOG_HOLDSシステム・ビューから選択するか、ttLogHolds組込みプロシージャをコールします。該当する場合、この情報は次になります。
ログ・ファイルの番号、保持されている位置のオフセット、およびチェックポイント、レプリケーション、バックアップ、XLA、長時間実行のトランザクションまたは長時間実行のXAトランザクションの種類の保持
チェックポイントによる保持の場合のチェックポイント・ファイル名
サブスクライバ名およびレプリケーションで使用するパラレル・トラックID
バックアップによる保持の場合のバックアップ・パス
永続サブスクリプション名およびXLA用にオープンする最後のプロセスのプロセスID
長時間実行のトランザクションのトランザクションID
長時間実行のXAトランザクションのXA XID
詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のSYS.GV$LOG_HOLDSに関する項またはSYS.V$LOG_HOLDSに関する項、または『Oracle TimesTen In-Memory Databaseリファレンス』のttLogHoldsに関する項を参照してください。
SYS.GV$CKPT_HISTORYまたはSYS.V$CKPT_HISTORYシステム・ビューから選択するか、ttCkptHistory組込みプロシージャをコールして最後の複数のチェックポイントを確認し、返されたすべての行のステータスがFAILEDでないことを確認します。
詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のSYS.GV$CKPT_HISTORYに関する項またはSYS.V$CKPT_HISTORYに関する項、または『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に関する説明を参照してください。
TimesTenのデータベースは、電源障害やクラッシュ時にも持続します。TimesTenでは、次のものを定期的にディスクに保存することで、永続性が実現されます。
チェックポイント・ファイル: チェックポイント処理では、現在のデータベース・イメージがファイル・システム上のチェックポイント・ファイルに書き込まれ、チェックポイント処理以前にコミットされたすべてのトランザクションが永続的になります。
トランザクション・ログ・ファイル: 最後のチェックポイント後にコミットされたトランザクションに対しては、従来のロギングによる方法によって永続性が与えられます。トランザクションが処理されるたびに、そのトランザクションによるデータベースの変更内容がインメモリー・トランザクション・ログに記録されます。コミットが行われると、トランザクション・ログ内の該当部分がファイル・システムにフラッシュされます。このログ・フラッシュ処理によって、該当するトランザクションおよび以前コミット済のすべてのトランザクションに永続性が与えられます。
トランザクション・ログ・データがファイル・システムに永続的に書き込まれると、アプリケーションに制御が戻ります。永続的にコミットされたトランザクションは、システム障害が発生しても失われることはありません。
最新のチェックポイント・イメージがトランザクション・ログとともに使用され、トランザクションに一貫性がある最新の状態でデータベースが再構築されます。
トランザクションをコミットする際、TimesTenは複数の同時実行トランザクションをグループ・コミットして、永続コミットのパフォーマンス・コストを削減します。TimesTenでは、単一のファイル・システム書込み処理が実行され、同時トランザクションのグループが永続的にコミットされます。永続コミットのたびに、ファイル・システム書込み処理の完了を待機する必要があるため、グループ・コミットでは、いずれのコミット処理のレスポンス時間も向上しませんが、一連の同時トランザクションのスループットは大幅に向上します。
次の項では、TimesTen ScaleoutおよびTimesTen Classicの永続性実装オプションについて説明します。
TimesTen Scaleoutでは、データベースのデータは要素に分散されます。各要素は、独自のチェックポイントおよびトランザクション・ログ・ファイルを保持します。その結果、各要素に格納されたデータは独立して永続します。グリッド内の各データ・インスタンスはデータベースの1つの要素を管理します。障害が発生した場合は、1つのデータ・インスタンスでチェックポイント・ファイルおよびトランザクション・ログ・ファイルから、その要素に格納されているデータを自動的にリカバリでき、残りのデータ・インスタンスでアプリケーションの提供を続行します。
TimesTen Scaleoutでもデータの複数のコピーを保持し、永続性とフォルト・トレランスを向上させることができます。K-safety値が2以上の場合は、障害が発生した要素をレプリカ・セット内の別の要素からリカバリできます。K-safetyの詳細は、『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』の高可用性とフォルト・トレランスに関する項およびグリッドの作成に関する項を参照してください。
また、パフォーマンスおよびデータ永続性の必要性に応じて、データベースの永続性設定を変更できます。たとえば、高いパフォーマンス・レベルで操作するために、データをコミットごと、または定期的にバッチでディスクにフラッシュするかどうかを選択できます。次の項では、これらの永続性設定について説明します。
TimesTen Scaleoutでは、Durablity接続属性を使用してトランザクションの永続性を構成します。Durability属性を1に設定すると、参加者が分散トランザクションの永続コミットの準備ログ・レコードおよび非永続コミット・ログ・レコードを書き込みます。Durability属性を1に設定すると、コミットされたトランザクションが失敗した場合にリカバリ可能になります。詳細は、『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』の永続性設定に関する項を参照してください。
Durability接続属性を0に設定して、参加者が分散トランザクションの非永続コミットの準備ログ・レコードおよびコミット・ログ・レコードを書き込めるようにします。
K-safetyには、障害リカバリのメソッドが用意されています。K-safetyを使用すると、2つのデータ・コピーを指定することで、ほぼ間断なく可用性またはワークロード分散を実現できます。そのため、1つのコピーが失敗した場合、データの別のコピーが存在します。
レプリカ・セットのいずれかの要素が、レプリカ・セット内の他の要素で失敗した場合は、失敗した要素がリカバリされるまで、永続コミットの準備ログ・レコードが書き込まれます。これにより、K-safetyが2に設定され、Durabilityが0に設定されたグリッド内のトランザクションが通常の条件下で永続的になります。レプリカ・セットの両方の要素で同時に障害が発生した場合にのみ、トランザクションが非永続になります。
TimesTen Scaleoutでは、定期的にトランザクションをエポック・トランザクションに昇格させます。エポック・トランザクションでマークされたグローバルに一貫性のある時点にデータベースをリカバリできるため、エポック・トランザクションとその前にコミットされたすべてのトランザクションには、重大な障害に対するより高いリジリエンスがあります。各エポック・コミット・ログ・レコードは、各要素の特定のチェックポイント・ファイルに関連付けられます。要素に予期しない障害が発生した場合、リカバリ・プロセスでは、最新のエポック・コミット・ログ・レコードに関連付けられている各要素のチェックポイント・ファイルを使用する必要があります。このチェックポイントは、必ずしもその要素の最新のチェックポイントではありません。
デフォルトでは、TimesTen Scaleoutでは、1秒ごとに1つのエポック・トランザクションが生成されます。EpochInterval初期接続属性を使用して、エポック・トランザクションが自動的に生成される頻度を構成できます。また、ttEpochCreateまたはttDurableCommit組込みプロシージャを使用して、トランザクションをエポック・トランザクションに手動で昇格させることができます。
エポック・トランザクションの詳細およびトランザクションをエポック・トランザクションに昇格させる方法は、『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』のDurabilityを0に設定に関する項を参照してください。
TimesTen Classicでは、最新のチェックポイント・イメージがトランザクション・ログとともに使用され、トランザクションに一貫性がある最新の状態でデータベースが再構築されることにより、永続性を実現します。トランザクション・ログ・レコードは、トランザクションの完了に対して非同期または同期でディスクに書き込まれ、トランザクション・レベルでアプリケーションによって制御されます。
データ整合性を維持する必要がある場合に、データを失うことなく、永続性が保証された環境を作成できます。
最大スループットが最優先であるが、最低限のデータ損失を許容できる場合に、永続性の環境を作成できます。
TimesTen Classicレプリケーションは、パフォーマンスへの影響を最小限に抑えて、アプリケーションのデータの可用性を高めます。レプリケーションでは、2つ以上のホスト間で更新を送信することによって、ほぼ間断なく可用性またはワークロード分散を実現できます。マスター・ホストは更新を非同期で送信するように構成され、サブスクライバ・ホストはそれらの更新を受信するように構成されます。
非同期ライトスルー(AWT)キャッシュ・グループを使用すると、TimesTen Cacheは、TimesTenキャッシュ表とキャッシュされたOracle Database表の間でコミットされた更新を転送して、2つのデータベースでこれらの表の同期が確保されます。非同期ライトスルー・キャッシュ・グループの詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』の非同期ライトスルー(AWT)キャッシュ・グループに関する項を参照してください。
永続性保証により、データ整合性を維持する必要がある場合に、(パフォーマンスを犠牲にして)データの損失がないことが保証されます。
すべてのトランザクションの永続性を保証するには、少なくとも次のいずれかを実行する必要があります。(これらのオプションを両方使用することの利点はほとんどありません。)
RETURN TWOSAFEサービスで有効化されたレプリケーションを使用して、トランザクションをレプリケートします。RETURN TWOSAFEサービスでは、更新がマスターでコミットされる前に、サブスクライバで受信およびコミットされたことがレプリケーションで確認されるまでアプリケーションをブロックすることによって、完全な同期化が行われます。これにより、アプリケーションでは、後でマスターで障害が発生した場合でも、コミットされたトランザクションの結果が永続的であることが高度なレベルで保証されます。このオプションは、通常、永続コミットよりも高速です。詳細は、『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』のRETURN TWOSAFEレプリケーションに関する項を参照してください。
DurableCommits接続属性を1に設定して、永続コミット処理を構成します。これにより、アプリケーションが待機している間、トランザクションがトランザクション・ログ・ファイルに同期的に書き込まれます。この接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のDurableCommitsに関する項を参照してください。
|
ノート: ほとんどのトランザクションが永続的にコミットされる場合、LogFlushMethod初期接続属性を1に設定できます。この接続属性では、TimesTenでログ・データをトランザクション・ログ・ファイルに書き込む方法および同期する方法を構成します。詳細は、「永続コミットの適切な使用」を参照してください。 |
非永続トランザクションは、永続トランザクションに比べてかなり短時間で実行できます。非永続トランザクションを使用している接続と、永続性保証を使用している接続を共存させることができます。
永続性保証と同様に、各トランザクションによってデータベースが変更されるたびに、インメモリー・トランザクション・ログ・バッファにレコードが書き込まれます。ただし、トランザクションが非永続モードでコミットされると、ファイル・システムにトランザクション・ログ・バッファが書き込まれるのを待機せず、制御がアプリケーションに戻されます。そのため、非同期レプリケーションまたは非同期ライトスルー・キャッシュ・グループを構成していない場合は、データベースで障害が発生した場合に非永続トランザクションが失われる可能性があります。最終的に、トランザクションは、データベース・サブデーモン・プロセスによって、またはインメモリー・トランザクション・ログ・バッファに空きがない場合はファイル・システムにフラッシュされます。
データ損失を最小限に抑えながらトランザクションで非常に高いスループットが必要となる場合は、次のオプションの両方を実行することを検討してください。
これらのいずれかの方法を使用して、別のデータベース(TimesTenデータベースまたはOracleデータベース)へのデータの非同期書込み処理を実行します。
マスターからサブスクライバにコミット済トランザクションをレプリケートするデフォルトの非同期レプリケーションを使用します。デフォルトの非同期レプリケーションを使用した場合、アプリケーションはマスター・データベースを更新すると、サブスクライバがその更新を受信および適用するのを待機せずに処理を続行します。非同期レプリケーションでは、最高のパフォーマンスが実現しますが、レプリケート対象の更新がサブスクライバ・データベースでコミットされたことを示す確認応答はアプリケーションに送信されません。詳細は、『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』のデータベース間での更新のコピーに関する項を参照してください。
非同期ライトスルー(AWT)キャッシュ・グループを設定して、TimesTenキャッシュ表でコミット済の更新が、キャッシュされたOracle Database表に自動的に非同期で伝播されるようにします。TimesTenデータベースでのトランザクション・コミット処理は、Oracleデータベースでのコミットとは非同期に実行されます。これにより、アプリケーションはOracle Databaseトランザクションの完了を待機することなく、継続してTimesTenデータベースに対してトランザクションを発行できます。ただし、アプリケーションでは、Oracle Database上でトランザクションが完了するタイミングを確認できません。AWTキャッシュ・グループの詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』の非同期ライトスルー(AWT)キャッシュ・グループに関する項を参照してください。
DurableCommits接続属性を0に設定して非永続トランザクション用を構成します。これにより、非永続コミット・ログ・レコードがトランザクション・ログ・ファイルに非同期で書き込まれます。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のDurableCommitsに関する項を参照してください。
システム障害が発生した場合に損失が発生しやすいトランザクションは、最後の永続コミットの後に非永続的にコミットされ、障害の発生前にレプリケートされていないトランザクションのみです。
ただし、データ損失を許容できない重要なトランザクションがある場合は、次のいずれかを行うことができます。
ttRepSubscriberWait組込みプロシージャを実行して、マスター・データベースからサブスクライバ・データベースにそれらのトランザクションを同期的にレプリケートします。
サブスクライバ・データベースのDSNおよびホストを使用してマスター・データベースでttRepSubscriberWait組込みプロシージャを実行すると、コール元は、コール前にコミットされたすべてのトランザクションがサブスクライバに送信されるまで待機します。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepSubscriberWaitに関する項を参照してください。
ttDurableCommits組込みプロシージャを使用して、個々のトランザクションを、トランザクション・ログ・ファイルに永続的にコミットします。あるトランザクションを永続的にコミットすると、そのトランザクションだけでなく、以前のすべてのトランザクションが永続的になります。ただし、これは、トランザクションがレプリケートされるのを待機しません。
永続コミットが必要な場合は、コミットする前にアプリケーションでttDurableCommit組込みプロシージャをコールできます。ttDurableCommit組込みプロシージャは、実際にトランザクションはコミットせず、コミットの実行時にそのコミットに永続性を与えるのみです。
これにより、非永続的にコミットされているすべてのトランザクションに比べて、トランザクションが失われる可能性は低くなります。永続コミットをn個のトランザクションごとにのみ実行するか、またはn秒ごとに実行すると、トランザクションの消失の可能性がある時間枠を小さくし、レスポンス時間を短縮できます。ユーザーは、金融取引を扱うトランザクションなど、消失の危険があるクリティカルなトランザクションを永続的にコミットすることもできます。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDurableCommitに関する項を参照してください。
トランザクションがTimesTenによってコミット済としてマークされた後、コミットの再要求フェーズがあります。
トランザクションのコミットの再要求段階の間に、TimesTenのリソース・クリーンアップが発生します。たとえば、DELETE操作を含むトランザクションを考えてみます。SQL操作は削除した行を削除済としてマークしますが、これらの行が占有する領域は、実際にはトランザクションのコミットの再要求フェーズまでは解放されません。
再要求の間、TimesTenはトランザクションの開始時点からのすべてのトランザクション・ログ記録を再調査し、実行する必要がある再要求操作を決定してから、これらの操作を実行します。
パフォーマンス向上のため、数件のトランザクション・ログ・レコードをキャッシュしてトランザクション・ログ・ファイルへのアクセスを減らすことができます。このキャッシュはコミット・バッファと呼ばれ、その大きさは、次の「コミット・バッファを再要求操作用に構成する」の項で説明しているように構成可能です。
|
ノート:
|
大きなトランザクション・コミットの再利用要求段階では大量の処理が必要になり、リソースを大量に消費します。(このため、より小さなトランザクションを一般的に推奨します。)ただし、コミット・バッファの最大サイズを増やすことでパフォーマンスを向上させることができます。コミット・バッファとは、再利用要求操作で使用されるトランザクション・ログ記録のキャッシュです。
|
ノート: 非常に大規模なトランザクション・コミット(100万行など)を実行することは、リソースを大量に消費するため、お薦めしません。非常に大規模なトランザクションをコミットした場合は、取り消さないでください。これは、トランザクションが完了するまでの時間がさらに長くなる可能性があるためです。これは、トランザクションが完了していない場合に取り消すと、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組込みプロシージャを使用して接続に関する統計を収集し、コミット・バッファの最大サイズのチューニングに役立てることができます。この組込みパラメータはパラメータを取らず、コミット・バッファ・オーバーフローの合計数と、トランザクション・ログ・レコードの再要求操作に使用された最大メモリー量を、バイト単位で返します。バッファ・オーバーフローがある場合、コミット・バッファの最大サイズを増やすことを検討してください。オーバーフローがなく、最大メモリー使用量がコミット・バッファの最大サイズより大幅に少ない場合は、最大サイズを減らすことを検討してください。
TimesTen Classicでは、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組込みプロシージャを呼び出します。
システム障害やプロセス障害によって、データベースが無効になったり破損したりすると、データベースへのすべての接続が無効になります。アプリケーションが障害のあったデータベースに再接続すると、サブデーモンがデータベースに新しいメモリー・セグメントを割り当て、チェックポイント・ファイルおよびトランザクション・ログ・ファイルからそのデータをリカバリします。
リカバリ中に、最新のチェックポイント・ファイルがメモリーに読み込まれます。最後のチェックポイント以降にコミットされ、ログ・レコードがファイル・システム上に存在するすべてのトランザクションが、適切なトランザクション・ログ・ファイルからロールフォワードされます。ただし、このようなトランザクションには、永続的にコミットされたすべてのトランザクションのみでなく、ログ・レコードがインメモリーのログ・バッファからエージ・アウトされたすべてのトランザクションも含まれることに注意してください。コミットされていないトランザクション、またはロールバックされたトランザクションはリカバリされません。チェックポイント・ファイルおよびトランザクション・ログ・ファイルの詳細は、「チェックポイント処理」、「トランザクションのロギング」および「エラー、警告および情報メッセージ」を参照してください。
