チェックポイント処理
チェックポイント処理では、TimesTenインメモリー・データベースの現在の状態を、最新のディスク・チェックポイント・ファイルの状態と同期します。
チェックポイント処理では、最後のチェックポイント処理以降に変更されたインメモリー・データベースのすべてのリージョンが書き込まれます。チェックポイント処理は2つのチェックポイント・ファイル間で交互に行われるため、常に最新のチェックポイント・イメージと最新 – 1のチェックポイント・イメージをリカバリに使用できます。チェックポイント処理が完了すると、関連するトランザクション・ログ・ファイル(現在はチェックポイントの一部)は不要になるため、TimesTenはこれらをパージします。
デフォルトで、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 Classicでは、アプリケーションは、ttCkptBlocking
組込みプロシージャを使用してブロッキング・チェックポイントをリクエストします。実際のチェックポイント処理は、リクエストを行ったトランザクションがコミットまたはロールバックされてから実行されます。両方のチェックポイント・ファイルがすでに最新となっているデータベースに対してブロッキング・チェックポイントをリクエストすると、そのチェックポイント・リクエストは無視されます。
チェックポイントの設定および管理
TimesTenチェックポイントにはデフォルトの動作があります。
-
TimesTenでは、定期的なファジー・チェックポイント処理がバックグラウンドで実行されます。この動作は変更できます。「バックグラウンドのチェックポイント処理の構成または無効化」を参照してください。
-
TimesTenでは、データベースをメモリーからアンロードする直前に、データベースに対してブロッキング・チェックポイント処理を実行します。「ブロッキング・チェックポイント」を参照してください。
次の項では、チェックポイント処理の管理方法について説明します。
TimesTen Classicでのプログラムによるチェックポイントの実行
デフォルトの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
システム・ビューから選択します。
ノート:
ttCkptHistory
組込みプロシージャを使用してこの情報を表示することもできます。
たとえば、確認できる情報の一部は次のとおりです。
-
チェックポイント処理にかかる時間(チェックポイント処理の開始時刻から完了時刻を減算)。
-
チェックポイントのタイプ: ファジー、ブロッキング、静的またはなし。「チェックポイントのタイプ」を参照してください。
-
チェックポイント処理のステータス: 進行中、完了、または失敗。チェックポイント履歴を調べる場合は、最新のチェックポイント処理が失敗したかどうかを確認します(
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を参照してください。
処理中のチェックポイントの例を次に示します。
% 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> >
この例は、チェックポイントの履歴出力を示しています。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を参照してください。