重要なデータが失われないようにするには、 環境の回復が非常に大切になります。 環境を管理し、 十分なレベルまでデータまたはトランザクションを回復するのに使用できるパラメーターがいくつかあります。 この種のパラメーターは、次のカテゴリーに分けることができます。
次のパラメーターは、 データベースのロギングで使用するファイルの数、 サイズおよび状況について記述しています。
このパラメーターは、 個々の 1 次および 2 次ログ・ファイルのサイズを定義します。 これらのログ・ファイル・サイズは、 ログ・ファイルに書き込むことができるログ・レコードの数を制限します。 ログ・ファイルがいっぱいになると、新しいログ・ファイルが必要になります。
1 次および 2 次ログ・ファイルの使用法、 またログ・ファイルがいっぱいになったときのアクションは、 実行しているロギングのタイプによって異なります。
1 次ログ・ファイルに記録されていた変更をコミットすると、 その 1 次ログ・ファイルを再利用することができます。 ログ・ファイルのサイズが小さいのに、 アプリケーションがデータベースに対する多数の変更内容をコミットせずに処理すると、 1 次ログ・ファイルはすぐにいっぱいになってしまいます。 1 次ログ・ファイルがすべていっぱいになると、 データベース・マネージャーは新しいログ・レコードを保持するために 2 次ログ・ファイルを割り振ります。
1 次ログ・ファイルがいっぱいになると、そのログは保存され、 新しい 1 次ログ・ファイルが割り振られます。
推奨事項: ログ・ファイルのサイズは、1 次ログ・ファイルの数を考慮に入れて決めてください。
注: | ログ・ファイルの合計サイズの限界は、32 GB です。 つまり、 ログ・ファイルの数 (logprimary + logsecond) に各ログ・ファイルのサイズ (バイト単位) (logfilsiz * 4096) を掛けた値が、 32 GB より小さくなければなりません。 |
ログ・ファイルが小さすぎると、古いログ・ファイルの保存、新しいログ・ファイルの割り振り、 および使用可能なログ・ファイルができるまでの待機などでオーバーヘッドが生じるため、 システム・パフォーマンスに影響が及ぶことがあります。
ログ・ファイルが大きすぎると、媒体がログ・ファイル全体を保持できないことがあるので、 保存されたログ・ファイルやログ・ファイルのコピーを管理するときの柔軟性が低くなることがあります。
ログ保存を使用する場合は、 最後のアプリケーションがデータベースから切断されると、 現行のアクティブ・ログ・ファイルはクローズされ、切り捨てられます。 データベースに次回接続するときには、 次のログ・ファイルが使用されます。 したがって、並行アプリケーションのロギング要件を知っていると、 過度の量を割り振ってスペースを無駄にすることがないようログ・ファイル・サイズを決定することができます。
詳しくは、 管理の手引き: インプリメンテーション の『データベース・ロギングの構成パラメーター』の中のこのパラメーターの説明を参照してください。
1 次ログ・ファイルは、 回復ログ・ファイルに割り振る記憶域の固定量を確立します。 このパラメーターを使用して、 事前に割り振る 1 次ログ・ファイルの数を指定することができます。
循環ログの場合、 1 次ログは繰り返し順序どおりに使用されます。 つまり、ログがいっぱいになると、次の順序の 1 次ログが利用可能であれば、 それが使用されます。 ログ・レコードを含む作業単位がすでにコミットまたはロールバックされていると、 ログは利用可能とみなされます。 次の順序の 1 次ログが利用可能でないと、 2 次ログが割り振られて使用されます。 次の順序の 1 次ログが利用可能になるまで、 または logsecond パラメーターで設定された限界に達するまで、 追加の 2 次ログが割り振られます。 データベース・マネージャーでこれらの 2 次ログ・ファイルが必要なくなると、 動的に割り振り解除されます。
1 次および 2 次ログ・ファイルは、次の条件を満たしていなければなりません。
推奨事項: このパラメーターの値を設定するときは、使用しているロギングのタイプ、 ログ・ファイルのサイズ、および処理環境のタイプ (たとえば、 トランザクションの長さやコミットの頻度) など、数多くの要素を考慮に入れなければなりません。
この値を大きくすると、データベースに最初に接続した時点で 1 次ログ・ファイルが事前割り振りされるので、 ログのディスク所要量は増えます。
2 次ログの割り振りが頻繁に行われるようであれば、 ログ・ファイルのサイズ (logfilsiz) または 1 次ログの数を増やすことによって、 システムのパフォーマンスを改善することもできます。
頻繁にアクセスしないデータベースについては、ディスク記憶域を節約するため、 パラメーターを 2 に設定してください。 ロールフォワード回復が使用できるデータベースの場合には、 新規のログを即時に割り振る際にオーバーヘッドが生じないよう、 このパラメーターの値は 2 より大きく設定してください。
1 次ログ・ファイルのサイズを設定する際は、データベース・システム・モニターを利用することができます。
詳細については、 システム・モニター 手引きおよび解説書 の中の以下のモニター要素の説明を参照してください。
これらのモニター値を少しの時間観察すると平均値が読み取れますが、 この平均値は現在の要件をよく表しているので、調整する際に役立ちます。
このパラメーターは、 回復ログ・ファイル用に (必要に応じて) 作成されて使用される 2 次ログ・ファイルの数を指定します。 1 次ログ・ファイルがいっぱいになると、 logfilsiz で指定されたサイズの 2 次ログ・ファイルが必要に応じて一度に 1 つずつ割り振られます。 このパラメーターは、その最大数を制御します。 このパラメーターで指定した数より多くの 2 次ログ・ファイルが必要になると、 エラー・コードがアプリケーションに戻され、データベースは遮断されます。
2 次ログの使用法については、1 次ログ・ファイルの数 (logprimary)を参照してください。
推奨方法: 2 次ログ・ファイルは、 定期的に大量のログ・スペースが必要になるデータベースに使用してください。 たとえば、月に 1 回だけ実行するアプリケーションの場合、 1 次ログ・ファイルのログ・スペースより大きなスペースが必要になる可能性があります。 2 次ログ・ファイルは永続的なファイル・スペースを必要としないので、 このような状況では利点が多いといえます。
このパラメーターでは、最大 242 バイトのストリングを指定して、 ログ・ファイルを保管する場所を変更できます。 このストリングはパス名を指す場合もあれば、 生装置を指す場合もあります。 ストリングがパス名を指す場合は、 相対パス名ではなく、完全修飾パス名を指定してください。
注: | 区分データベース環境では、 パスには自動的にノード番号が付けられます。 ノード番号は、 複数の論理ノード構成において、パスを固有にしておくために付けられます。 |
装置を指定するには、 オペレーティング・システムが装置として識別するストリングを指定します。 次に例を示します。
注: | 装置にログを書き込むには、 Windows NT バージョン 4.0 (サービス・パック 3 付き) をインストールしておく必要があります。 |
注: | AIX、Windows NT、 および Solaris プラットフォーム上の装置だけを指定できます。 |
次の条件が両方とも満たされないと、 新しい設定は logpath の値に反映されません。
初めてデータベースに新規接続した時点で、 データベース・マネージャーはログを logpath が指定した新しい場所に移動します。
以前のログ・パスにログ・ファイルが存在し、 そのようなログ・ファイルがアーカイブされていない場合があります。 そのようなログ・ファイルは手動でアーカイブしなければなりません。 また、そのデータベースで複製を実行している場合、 複製では、ログ・パスの変更以前のログ・ファイルも引き続き必要です。 ユーザー出口可能 (userexit) データベース構成パラメーターを "Yes" に設定してデータベースを構成し、 すべてのログ・ファイルが DB2 によって自動的に、 あるいは手動でアーカイブされている場合、 DB2 がログ・ファイルの検索を行い、 複製プロセスを完了することができます。 それ以外の場合は、 手動でそれらのファイルを以前のログ・パスから新しいログ・パスへコピーできます。
推奨事項: 理想的には、 ログ・ファイルは入出力が多くない物理ディスクに置きます。 たとえば、 オペレーティング・システムや高ボリューム・データベースと同じディスクにログを置かないでください。 このようにすると、入出力に関連したオーバーヘッドは最小に抑えられ、 ロギング・アクティビティーは向上します。
データベース・システム・モニターを使って、 データベースのロギングに関連した入出力の数をトラックすることができます。
詳細については、 システム・モニター 手引きおよび解説書 にある以下のモニター要素の説明を参照してください。
これらのデータ要素は、 データベース・ロギングに関連する入出力活動量を戻します。 オペレーティング・システム・モニター・ツールを使用して、 他のディスクの入出力活動を収集し、 この 2 つの入出力活動を比較することができます。
このパラメーターは、 ロギングで使用するカレント・パスを示します。 このパラメーターは、 newlogpath パラメーターに対する変更が有効になった後でデータベース・マネージャーにより設定されるため、 ユーザーが直接変更することはできません。
データベースを作成すると、 そのデータベースが含まれているディレクトリーのサブディレクトリーに、 回復ログ・ファイルが作成されます。 省略時では、そのサブディレクトリーには SQLOGDIR という名前が付けられ、 データベースのディレクトリーに置かれます。
このパラメーターには、現在活動状態になっているログ・ファイルの名前が入ります。
次のパラメーターは、 データベース・ロギングのタイプおよびパフォーマンスを制御します。
このパラメーターを使うと、最低限の回数のコミットが実行されるまで、 ログ・レコードのディスク書き込みを遅らせることができるようになります。 この遅延によりログ・レコード書き込みに関連するデータベース・マネージャーのオーバーヘッドが少なくなるため、 データベースに対して複数のアプリケーションを実行しており、 それらのアプリケーションによって非常に短い時間フレームに多数のコミットが要求される場合のパフォーマンスを向上させることができます。
このようにコミットがグループ化されることは、このパラメーターの値が 1 より大きく、 データベースに接続したアプリケーションの数がこのパラメーターの値と同じかそれよりも大きい場合だけ行われます。 コミットがグループ化されている間、アプリケーションから出されるコミット要求は、1 秒が経過するまで、 またはコミット要求の数がこのパラメーターの値に達するまで保留されます。
このパラメーターに指定した値はただちに反映されます。 データベースからすべてのアプリケーションが切断されるまで待つ必要はありません。
推奨事項: 複数の読み取り / 書き込みアプリケーションが通常並行してデータベース・コミットを行うように要求する場合は、 この値を省略時値より大きくしてください。 このようにすることにより、データベース・コミットが同時に行われる頻度が低くなるので、 ロギング・ファイルの入出力がより効率的になり、 同時データベース・コミットが要求されるたびに、 より多くのログ・レコードを書き込むことができるようになります。
1 秒あたりのトランザクション数をサンプルとして調べ、 1 秒あたりのトランザクション数のピーク (またはそれに近い数) に対応できるようこのパラメーターを調整することもできます。 ピーク時のアクティビティーに対応できると、多重ロード時の、 ログ・レコード書き込みに関連したオーバーヘッドを最小に抑えることができます。
mincommit の値を大きくした場合、 いっぱいになったログ・バッファーが多重ロード時に書き込まれるのを避けるために、 logbufsz パラメーターも大きくする必要があるかもしれません。 この場合、 logbufsz が次の計算値と等しくなるようにしてください。
mincommit * (トランザクションで使用される平均ログ・スペース)
データベース・システム・モニターを使用して、 次の方法でパラメーターを調整することができます。
サンプルとして通常の 1 日をモニターして、 多重ロード時に相当する時間を調べることができます。 次のモニター要素を追加すると、 トランザクションの合計を計算することができます。
この情報および利用可能なタイム・スタンプを使って、1 秒あたりのトランザクション数を計算することができます。
次のモニター要素を使って、一定時間および一定数のトランザクションに関してサンプルを調べると、 使用されるログ・スペースの平均を計算することができます。
データベース・システム・モニターの詳細については、 システム・モニター 手引きおよび解説書 を参照してください。
このパラメーターは、次のために使用されます。
破損回復に必要なログ数を有効にするために、データベース・マネージャーはこのパラメーターを使用して、 ページ・クリーナーを活動させ、指定された回復ウィンドウよりも古いページがすでにディスクに書き込まれていることを確認します。
電源障害などの原因でデータベース障害が発生した場合、 次のような変更がデータベースに加えられていることがあります。
データベースを再始動すると、 データベースの破損を回復してデータベースの一貫性を保つ (つまり、 コミットされたすべてのトランザクションがデータベースに適用され、 コミットされていないトランザクションが適用されない状態) ためにログ・ファイルが使用されます。
ログ・ファイルのどのレコードをデータベースに適用する必要があるかを判別するために、 データベース・マネージャーはログ制御ファイルを使用します。 このログ制御ファイルは定期的にディスクに書き出されます。このイベントの頻度に基づいて、 データベース・マネージャーは、コミットされたトランザクションのログ・レコードを適用するか、 またはすでにバッファー・プールからディスクに書き出されている変更を記述しているログ・レコードを適用することができます。 これらのログ・レコードはデータベースには影響しませんが、 これらのログ・レコードを適用しようとすると、 データベースの再始動処理で多少のオーバーヘッドが生じます。
ログ・ファイルがいっぱいになったとき、 およびソフト・チェックポイントをとるときには、 ログ制御ファイルは必ずディスクに書き込まれます。 この構成パラメーターを使って、 追加のソフト・チェックポイントのトリガーとすることができます。
ソフト・チェックポイントの時点は、「現在の状態」と「記録済み状態」の差によって決まります。 これは logfilsiz のパーセントとして示されます。 「記録済み状態」は、ディスクのログ制御ファイル中で一番古い有効なレコードにより判別され、 「現在の状態」はメモリー上のログ制御情報によって判別されます。 (一番古い有効ログ・レコードは、回復処理で最初に読み取られるログ・レコードです。) 次の式で計算した値がこのパラメーターの値より大きいか等しい場合に、 ソフト・チェックポイントが使用されます。
( (記録済み状態と現在の状態の間のスペース) / logfilsiz ) * 100 * logprimary
推奨事項: 受け入れ可能な回復ウィンドウが 1 ログ・ファイルより大きいか小さいかに基づいて、 このパラメーターの値を大きくしたり小さくしたりすることができます。 このパラメーターの値を小さくすると、データベース・マネージャーはページ・クリーナーをより頻繁に使用するとともに、 ソフト・チェックポイントもより頻繁に行うことになります。 これによって、処理する必要のあるログ・レコードの数、および、 破損回復で処理される冗長ログ・レコードの数を少なくすることができます。
しかし、ページ・クリーナーの使用が多くなり、ソフト・チェックポイントの頻度が高くなると、 データベースのロギングに関連したオーバーヘッドが増加するため、 データベース・マネージャーのパフォーマンスに影響が出ることに注意してください。 さらに、次の状態では、 ソフト・チェックポイントの頻度が高くなってもデータベースの再始動にかかる時間は短くなりません。
どちらの状態も、メモリーに保持されているログ制御情報は頻繁に変更されないので、 未変更のログ制御情報をディスクに書き込んでもあまり効果はありません。
値は以下のとおりです。
logretain が "Recovery" に設定されているか、 または userexit が "Yes" に設定されていると、 アクティブ・ログ・ファイルはロールフォワード回復で使用できるよう保存され、 オンライン・アーカイブ・ログ・ファイルになります。 このアクティビティーは、ログ保存ロギングといいます。
logretain を "Recovery" に設定した後、 または userexit を "Yes" に設定した後 (または両方の後) には、 データベースの全バックアップを実行する必要があります。 この状態は、backup_pending フラグ・パラメーターで示されます。
logretain が "No" に設定されていて userexit が "No" に設定されている場合、 ロールフォワード回復はデータベースで使用できません。
logretain が "Capture" に設定されていると、 収集プログラムは PRUNE LOGFILE コマンドを呼び出して、 収集プログラムの終了時にログ・ファイルを削除します。 データベースでロールフォワード回復を実行する場合には、 logretain を "Capture" に設定しないでください。
logretain が "No" に設定されていて userexit が "No" に設定されていると、 ログは保存されません。 この場合、データベース・マネージャーは logpath ディレクトリー内のログ・ファイルをすべて (オンライン・アーカイブ・ログ・ファイルも含めて) 削除し、 新規のアクティブ・ログ・ファイルを割り振り、循環ログに戻ります。
このパラメーターを使用可能にすると、logretain パラメーターの設定値に関係なくログ保存ロギングが実行されます。 このパラメーターは、 ログ・ファイルの保存および検索を行う際にユーザー出口プログラムを使用する必要があることも示します。 ログ・ファイルは、データベース・マネージャーがログ・ファイルを閉じたときに保存されます。 また、ROLLFORWARD ユーティリティーがデータベースを復元する際にログ・ファイルが必要になったときに検索されます。
logretain または userexit のいずれか (または両方) のパラメーターが使用可能な場合には、 データベースの全バックアップを実行する必要があります。 この状態は、backup_pending フラグ・パラメーターで示されます。
どちらのパラメーターも選択を解除すると、ログは保存されなくなるので、 データベースのロールフォワード回復は利用できなくなります。 この場合、データベース・マネージャーは logpath ディレクトリー内のログ・ファイルをすべて (オンライン・アーカイブ・ログ・ファイルも含めて) 削除し、 新規のアクティブ・ログ・ファイルを割り振り、循環ログに戻ります。
ユーザー出口プログラムの詳細については、 管理の手引き: インプリメンテーション の『データベース回復用のユーザー出口』を参照してください。
次のパラメーターは、データベース回復のさまざまな要素を制御します。
分散作業単位回復も参照してください。
次のパラメーターは、Tivoli Storage Manager (TSM) で作業する際に使用されます。
このパラメーターを On にすると、アプリケーションがデータベースに接続したときに、 データベース・マネージャーが必要に応じて再始動データベース・ユーティリティーを自動的に呼び出します。 データベース再始動ユーティリティーは、 破損回復 と呼ばれる操作を実行します。 アプリケーションがデータベースに接続しているときに、 データベースが異常終了すると、 この操作が実行されます。 データベース異常終了の原因としては、 電源障害やシステム・ソフトウェア障害などが考えられます。 障害が生じた時点で、 データベースのバッファー・プールには含まれていたがディスクには書き込まれていなかったコミット済みトランザクションがあれば、 そのトランザクションが適用されます。 また、ディスクに書き込まれたコミットされていないトランザクションがあると、 そのトランザクションは取り消されます。
autorestart が使用可能でない場合に、 破損回復を必要としている (再始動する必要がある) データベースに対してアプリケーションが接続を試みると、 SQL1015N エラーが戻されます。 この場合、アプリケーションからデータベース再始動ユーティリティーを呼び出すか、 または回復ツールから再始動操作を選択してデータベースを再始動することができます。
このパラメーターは、 無効な索引をデータベース・マネージャーが再作成する時点を示します。 次の 3 つの設定値があります。
これらの値と等価な数値と API 定数については、 管理 API 解説書 を参照してください。
致命的なディスク問題が発生したときに、 索引が無効になることがあります。 データ自体に問題があった場合は、 そのデータは失われる可能性があります。 一方、索引に問題があった場合は、 索引を再作成すれば回復します。 ユーザーがデータベースに接続しているときに索引を再作成すると、 次の 2 つの問題が生じることがあります。
推奨事項: ユーザーが多いサーバーで、かつ再始動時について心配する必要がない状況では、 このオプションの最適な選択は、破損後にデータベースをオンラインに復帰させる処理の一部として、 DATABASE RESTART 時に索引を再作成することです。
このパラメーターを「ACCESS」に設定すると、 索引が再作成されている間は、 データベース・マネージャーのパフォーマンスが低下します。 この特定の索引または表にアクセスしているユーザーは、 再作成が完了するまで待機しなければなりません。
このパフォーマンスを「RESTART」に設定すると、 索引を再作成する際のデータベースの再始動にかかる時間は長くなりますが、 データベースがオンラインに復帰されると、通常の処理には何の影響もありません。
このパラメーターは、 表ロードの回復で使用するセッションの省略時数を指定します。 ロード・コピーを検索するのに最適な入出力セッションの数を設定してください。 ロード・コピーの検索は、 復元操作と似ています。 環境変数 DB2LOADREC で指定されたコピー位置ファイルの項目を使って、 このパラメーターを指定変更することができます。
ロード検索で使用される省略時のバッファー数は、 このパラメーターの値より 2 つ多い数です。 コピー位置ファイル中のバッファー数を指定変更することができます。
このパラメーターは、ロールフォワード回復が使用可能な場合に限り適用されます。
ロード回復について詳しくは、データ移動ユーティリティー 手引きおよび解説書 を参照してください。
このパラメーターは、 データベース用に保持するデータベース・バックアップの数を指定します。 バックアップが指定した数に達すると、 以前のバックアップには回復活動記録ファイル内で有効期限切れというマークが付けられます。 有効期限が切れたデータベースのバックアップに関連する表スペース・バックアップとロード・コピー・バックアップの回復活動記録ファイル項目にも、 有効期限切れというマークが付けられます。 バックアップに有効期限切れというマークが付けられると、 物理バックアップを格納場所 (たとえば、ディスク、テープ、ADSM) から消去することができます。 次のデータベース・バックアップでは、 有効期限が切れた項目が回復活動記録ファイルから除去されます。
データベース・バックアップに活動記録ファイルで有効期限切れというマークが付けられると、 DB2 データ・リンク・マネージャーを介してリンクされている対応するファイルのバックアップすべてが、 アーカイブ・サーバーから消去されます。
rec_his_retentn 構成パラメーターは、 num_db_backups の値と互換性のある値に設定されます。 たとえば、num_db_backup が大きな値に設定される場合、 rec_his_retentn の値は、 その数のバックアップを十分サポートできる大きさにする必要があります。
このパラメーターは、 バックアップの活動記録情報を保存しておく日数を指定します。 バックアップ、復元、およびロードの情報を得るのに回復活動記録ファイルが必要ない場合は、 このパラメーターに小さい数字を設定することができます。
このパラメーターを -1 に設定すると、回復活動記録ファイルは、 使用可能なコマンドか API を明示的に発行したときだけ削除されます。 -1 でない場合は、 完全データベース・バックアップを実行するたびに回復活動記録ファイルは削除されます。
このパラメーターの値は num_db_backups パラメーターの値を指定変更しますが、 rec_his_retentn と num_db_backups はともに機能する必要があります。 num_db_backups が大きな値に設定される場合、 rec_his_retentn の値は、 その数のバックアップを十分サポートできる大きさにする必要があります。
PRUNE ユーティリティーで FORCE オプションを使用しない限り、保存期間の長さに関係なく、 最新の完全データベース・バックアップとその復元の集まりは必ず保持されます。 このユーティリティーについての詳細は、 コマンド解説書 を参照してください。
Tivoli Storage Manager 管理クラスは、バックアップがとられているオブジェクトについて、 TSM サーバーによるバックアップ・バージョン管理方法を示します。
省略時値は、「TSM 管理クラスなし」です。
管理クラスは Tivoli Storage Manager の管理者によって割り当てられます。 割り当てた後は、 このパラメーターに管理クラス名を設定する必要があります。 TSM バックアップの実行時点で、 データベース・マネージャーはこのパラメーターを使用して、 管理クラスを TSM に渡します。
Tivoli Storage Manager に関する詳細については、 管理の手引き: インプリメンテーション の『Tivoli Storage Manager』を参照してください。
このパラメーターは、 Tivoli Storage Manager (TSM) 製品に関連したパスワードの省略時設定を一時変更するために使用します。 別のノードから TSM にバックアップされたデータベースを復元するには、 パスワードが必要です。
注: | DB2 によるバックアップで、 tsm_nodename を指定変更する (たとえば、 BACKUP DATABASE コマンドによって) 場合は、 tsm_password も設定する必要があります。 |
省略時値を使用できるのは、 バックアップを行ったものと同じノードにある TSM からデータベースを復元するために限られます。 tsm_nodename は、 DB2 によるバックアップ時に指定変更されることがあります。
Tivoli Storage Manager に関する詳細については、 管理の手引き: インプリメンテーション の『Tivoli Storage Manager』を参照してください。
このパラメーターは、 Tivoli Storage Manager (TSM) 製品に関連したノード名の省略時設定を一時変更するために使用します。 別のノードから TSM にバックアップされたデータベースを復元するには、 ノード名が必要です。
省略時値を使用できるのは、 バックアップを行ったものと同じノードにある TSM からデータベースを復元するために限られます。 tsm_nodename は、 DB2 によるバックアップ時に指定変更される (たとえば、 BACKUP DATABASE コマンドで) ことがあります。
Tivoli Storage Manager に関する詳細については、 管理の手引き: インプリメンテーション の『Tivoli Storage Manager』を参照してください。
このパラメーターは、 Tivoli Storage Manager (TSM) 製品に関連した所有者の省略時設定を一時変更するために使用します。 別のノードから ADSM にバックアップされたデータベースを復元するには、 所有者名が必要です。 tsm_owner は、 DB2 によるバックアップ時に指定変更される (たとえば、 BACKUP DATABASE コマンドで) ことがあります。
注: | 所有者名には大文字小文字の区別があります。 |
省略時値を使用できるのは、 バックアップを行ったものと同じノードにある TSM からデータベースを復元するために限られます。
Tivoli Storage Manager に関する詳細については、 管理の手引き: インプリメンテーション の『Tivoli Storage Manager』を参照してください。
以下のパラメーターは、 分散作業単位 (DUOW) トランザクションの回復に影響します。
このパラメーターは、 DB2 インスタンスごとにトランザクション・マネージャー (TM) データベースの名前を識別します。 TM データベースには、以下のデータベースを使用することができます。
TM データベースとは、 ログ機能および調整プログラムとして使用されるデータベースで、 未確定トランザクションの回復を実行するときに使用されます。
このパラメーターに 1ST_CONN を設定すると、 ユーザーは最初に TM データベースに接続するようになります。
分散作業単位に関する詳細については、 管理の手引き: 計画 の『分散データベース』を参照してください。
推奨事項: 管理と操作を単純化するために、 多数のインスタンスに対して少数のデータベースを作成し、 それらのデータベースを TM データベース専用にすることができます。
このパラメーターは、 トランザクション・マネージャー (TM)、リソース・マネージャー (RM)、 または同期点管理機能 (SPM) で未解決の未確定トランザクションが見つかった場合に、 TM、RM、または SPM が回復を試行する時間の間隔を秒単位で指定します。 このパラメーターは、 分散作業単位 (DUOW) 環境でトランザクションを実行している場合に適用されます。
分散作業単位に関する詳細については、 管理の手引き: 計画 の『分散データベース』を参照してください。
推奨事項: ユーザーの環境で、 未確定トランザクションがデータベースに対する他のトランザクションを妨害しないようであれば、 このパラメーターの値を大きくすることができます。 DB2 コネクト・ゲートウェイを用いて DRDA2 アプリケーション・サーバーにアクセスしている場合は、 ローカル・データ・アクセスへの妨害がなくても、 アプリケーション・サーバーに未確定トランザクションがあっても影響がないかどうかを考慮する必要があります。 未確定トランザクションがない場合は、パフォーマンスの影響はごくわずかです。
このパラメーターは、 同期点管理機能 (SPM) ログが作成されるディレクトリーを指定します。 省略時では、ログは sqllib/spmlog ディレクトリーに書き込まれます。 その結果、高ボリューム・トランザクション環境では、 入出力ボトルネックが起きる可能性があります。 このパラメーターを使って、 現在の sqllib/spmlog ディレクトリーよりも高速のディスクに SPM ログ・ファイルを置いてください。 こうすることにより、SPM エージェント間の並行性が向上します。
同期点管理機能の詳細については、インストールおよび構成 補足 を参照してください。
未確定 DRDA トランザクションの回復の詳細については、 管理の手引き: 計画 の『ホスト上の未確定トランザクションの回復』を参照してください。
このパラメーターは、データベース・マネージャーに対して、 同期点管理機能 (SPM) のインスタンスの名前を識別します。
同期点管理機能の詳細については、インストールおよび構成 補足 を参照してください。
未確定 DRDA トランザクションの回復の詳細については、 管理の手引き: 計画 の『ホスト上の未確定トランザクションの回復』を参照してください。
このパラメーターは、 4 KB ページの同期点管理機能 (SPM) のログ・ファイル・サイズを識別します。 ログ・ファイルは sqllib の下の spmlog サブディレクトリーに入っており、 SPM が初めて開始したときに作成されます。
同期点管理機能の詳細については、インストールおよび構成 補足 を参照してください。
未確定 DRDA トランザクションの回復の詳細については、 管理の手引き: 計画 の『ホスト上の未確定トランザクションの回復』を参照してください。
推奨事項: 同期点管理機能ログ・ファイルのサイズは、 パフォーマンスを維持するのに十分な大きさでなければなりませんが、 スペースを浪費しないような大きさである必要があります。 必要なサイズは、保護会話を用いるトランザクションの数と、 COMMIT または ROLLBACK が出される頻度によって決まります。
SPM ログ・ファイルのサイズを変更するには、次のようにします。
このパラメーターは、 再同期操作を同時に実行できるエージェントの数を識別します。
未確定 DRDA トランザクションの回復の詳細については、 管理の手引き: 計画 の『ホスト上の未確定トランザクションの回復』を参照してください。
同期点管理機能の詳細については、インストールおよび構成 補足 を参照してください。