ログ・アーカイブを使用したログ・ファイルの管理

Db2® サーバー・ログ・ファイルのアーカイブは、さまざまなオペレーティング・システムのファイル処理やスケジューリングの問題によって複雑になります。 例えば、Db2 データベース・マネージャーがログ・ファイルのキューをアーカイブしているときにディスクで障害が発生する場合、そのログ・ファイルおよびそれに含まれるトランザクション・データが失われてしまうこともあり得ます。 データベース・ロギングを正しく構成することで、そうした問題によって可用性やリカバリー・ストラテジーが損なわれることを防ぐことができます。
以下の一般的な考慮事項は、すべてのログ・アーカイブのメソッドに当てはまります。
  • logarchcompr1 データベース構成パラメーターでは、データベース・マネージャーが logarchmeth1 に指定されているロケーションに含まれるログ・ファイルを圧縮するかどうかを指定します。 logarchmeth1 構成パラメーターが DISK、 TSM、 VENDOR以外の値の場合、 または DB2REMOTEの場合、 logarchcompr1 構成パラメーターの設定に関係なく、ログ・アーカイブ圧縮は効果がありません。
  • logarchcompr2 データベース構成パラメーターでは、データベース・マネージャーが logarchmeth2 に指定されているロケーションに含まれるログ・ファイルを圧縮するかどうかを指定します。 logarchmeth2 構成パラメーターが DISK、 TSM、 VENDOR以外の値の場合、 または DB2REMOTEの場合、 logarchcompr2 構成パラメーターの設定に関係なく、ログ・アーカイブ圧縮は効果がありません。
  • logarchmeth1 データベース構成パラメーターを指定すると、データベースのロールフォワード・リカバリー中に、指定したメソッドを使用してデータベース・マネージャーによってログ・ファイルがアーカイブされるか、ログ・ファイルがリトリーブされます。 ログ・ファイルのリトリーブ要求は、ロールフォワード・ユーティリティーで、 ログ・パス・ディレクトリーにないログ・ファイルが必要となるときに行われます。 ログ・ファイルは、logpath 構成パラメーターで指定されているパスからアーカイブされます。

    logarchmeth2 データベース構成パラメーターを指定すると、データベース・マネージャーによってログ・ファイルの追加のコピーがアーカイブされます。 ミラー・ロギングを構成すると、logarchmeth2 パラメーターで指定されているパスにアーカイブされているログ・ファイルが、ミラー・ログのパスから取られます。 ミラー・ロギングを構成しない場合、logarchmeth2 パラメーターで指定されているパスにアーカイブされているログ・ファイルは、現行のログ・パスから取られます。

  • 以下のいずれかの機能を使用している場合には、ログ・ファイルの保管で、ローカル接続された磁気テープ・ドライブを使用するべきではありません。
    • 無限ロギング
    • 表スペース・レベルでのオンライン・リカバリー
    • レプリケーション
    • db2ReadLog API
    • 高可用性災害時リカバリー (HADR)
    上記のどの機能もログ・ファイルのリトリーブ操作を呼び出す場合があり、その際にログ・アーカイブ操作と競合する可能性があります。 また、 Db2 pureScale® 環境では、ローカル接続された磁気テープ・ドライブを使用できません。これは、ログ・マージ操作を実行する メンバー が、他の メンバーのログを取得する必要があるためです。
  • ログ・アーカイブを使用している場合、ログ・マネージャーはアクティブ・ログが満杯になるとそのアーカイブを試みます。 場合によっては、ログ・マネージャーがアーカイブの成功を記録する前にデータベースが非活動状態になっていると、ログ・マネージャーはデータベースの活動状態のときにも再びログをアーカイブしようとするかもしれません。 したがって、ログ・ファイルが複数回アーカイブされることがあります。
  • アーカイブの際、ログ・ファイルがまだアクティブで通常の処理に必要な場合でも、ログ・ファイルが満杯になると、ログ・マネージャーに渡されます。 このプロセスにより、揮発性メディアからできるだけ速くデータのコピーを移動させることができます。 ログ・マネージャーに渡されたログ・ファイルは、通常の処理に必要なくなるまで、ログ・パス・ディレクトリーに保持されます。 必要なくなった時点で、ディスク・スペースは再使用されます。
  • ログ・ファイルがアーカイブされ、そのログ・ファイルにオープン・トランザクションが含まれない場合、Db2 データベース・マネージャーはそのファイルを削除しませんが、そのようなファイルが必要とされるときには、次のログ・ファイルとして名前を変更します。 このプロセスにより、パフォーマンスが向上します。ファイルの名前を変更する代わりに新しいログ・ファイルを作成する場合は、必要なディスク・スペースまたは他のストレージ・スペースが使用可能であることを保証するために、すべてのページを書き出すことになるためです。 データベース・マネージャーは、名前変更の目的で、アクティブ・ログ・パスに最大 8 個の追加ログ・ファイルを保持します。
  • クラッシュ・リカバリー中、メンバー・クラッシュ・リカバリー中 ( Db2 pureScale 環境)、または実行時ロールバック中に、 Db2 データベース・マネージャーはログ・ファイルを取得しません。ただし、 logsecond データベース構成パラメーターを -1 に設定した場合 (つまり、無限ロギングを有効にした場合) を除きます。 Db2 pureScale 環境では、無限ロギングを有効にしていない場合でも、グループ・クラッシュ・リカバリー中にデータベース・マネージャーがアーカイブ・ログを取得しなければならないことがあります。
  • デフォルトでは、取得されたログ・ファイルは、アクティブ・ログ・パスのサブディレクトリーの下に配置されます。 ただし、代わりにオーバーフロー・ログ・パスが構成されている場合、取得されたログ・ファイルは、その構成済みオーバーフロー・ログ・パスに配置されます。
  • ログ・アーカイブを構成しても、障害の時点までのロールフォワード・リカバリーは保証されませんが、障害期間を短くすることが試行されます。 ログ・ファイルが満杯になると、ログ・マネージャーはログを非同期的にアーカイブします。 ログ・ファイルが満杯になる前にログのあるディスクで障害が起きた場合は、そのログ・ファイル内のデータは失われます。 また、ファイルはアーカイブ用にキューに入れられるので、すべてのファイルがコピーされる前にディスクに障害が起こり、キュー内のすべてのログ・ファイルが失われることがあります。

    ログ・パスがあるディスクまたは装置の障害によってログ・ファイルが完全に失われてしまうことを防ぐために、mirrorlogpath データベース構成パラメーターを使用して、ログを 2 次パスに書き込むことができます。 1 次ディスクまたは装置と一緒に 2 次パスに障害が起きることがない場合、このログ・ファイルを使用してリカバリーできます。

    mirrorlogpath と logarchmeth2 の両方の構成パラメーターを設定すると、logarchmeth2 構成パラメーターは、現行のログ・パスにあるログ・ファイルの追加のコピーをアーカイブする代わりに、ミラー・ログ・パスからログ・ファイルをアーカイブします。 このログ・アーカイブの振る舞いを利用して、ロールフォワード・リカバリーの際の回復力を向上させることができます。 なぜなら、現行のログ・パスにある 1 次ログ・ファイルが、アーカイブの前にディスク障害により破損した場合でも、ミラー・ログ・パスにある使用可能なアーカイブ・ログ・ファイルを使用してデータベースのリカバリー操作を続行できる可能性があるからです。

  • ログ・ファイルの構成サイズは、ログ・アーカイブに直接影響します。 個々のログ・ファイルが非常に大きい場合、ディスクに障害が起こると、 大量のデータが失われることがあります。 小さなログ・ファイルを使用するようにデータベースを構成すると、ログ・マネージャーがログをアーカイブする頻度が高くなります。

    しかし、テープなど比較的低速の装置にデータを移動している場合は、 比較的大きいサイズのログ・ファイルを使用して、 キューが作成されないようにすることもできます。 各ファイルのアーカイブで、テープ装置の巻き戻しやアーカイブ・メディアへの接続の確立など、 実際のオーバーヘッドが必要になる場合にも、大きいログ・ファイルを使用することをお勧めします。

  • ログ・アーカイブを使用している場合、ログ・マネージャーは 1 次ログが満杯になるとそのアーカイブを試みます。 満杯になる前にログ・マネージャーがログをアーカイブする場合もあります。 これが行われるのは、データベースの非アクティブ化、ARCHIVE LOG コマンドの発行、 オンライン・バックアップの最後への到達、または SET WRITE SUSPEND コマンドの発行によって、ログ・ファイルが切り捨てられる場合です。
    注: 未使用のログ・スペースを解放するために、ログ・ファイルはアーカイブされる前に切り捨てられます。
  • 磁気テープ・ドライブにログおよびバックアップ・イメージをアーカイブする場合には、バックアップ・イメージとアーカイブ・ログの保存先が、同じ磁気テープ・ドライブにならないようにする必要があります。 いくつかのログのアーカイブは、バックアップ操作の進行中に行われる可能性があるため、2 つのプロセスが同時に同じ磁気テープ・ドライブに書き込もうとすると、エラーが起きるかもしれません。
以下の考慮事項が、ログ・ファイルのアーカイブとリトリーブのためのユーザー出口プログラムまたはベンダー・プログラムの呼び出しに適用されます。
  • Db2 データベース・マネージャーは、ユーザー出口プログラムが開始してログ・ファイルをアーカイブすると、 読み取りモードでこのファイルをオープンします。 このため、オペレーティング・システムによっては、ユーザー出口プログラムでログ・ファイルを削除することができません。 AIX® オペレーティング・システムなどの他のオペレーティング・システムでは、ユーザー出口プログラムを含むプロセスがログ・ファイルを削除できます。 ログ・ファイルはアーカイブ後も依然としてアクティブで、クラッシュ・リカバリーに必要なので、このようなファイルを決してユーザー出口プログラムで削除してはなりません。 ログ・ファイルがアーカイブされると、Db2 データベース・マネージャーによりディスク・スペースの再使用が管理されます。
  • アーカイブ要求が複数あり、最初のアーカイブ操作が正常実行された後にそのファイルが削除されたために、存在しなくなったファイルのアーカイブ要求をユーザー出口プログラムまたはベンダー・プログラムが受け取ることがあります。 また、別のディレクトリーにあるために存在しないファイル、またはログの最後に達したために存在しなくなったファイルのリトリーブ要求を、ユーザー出口プログラムまたはベンダー・プログラムが受け取ることもあります。 どちらの場合も、ユーザー出口プログラムまたはベンダー・プログラムはこの要求を無視し、正常な戻りコードを渡す必要があります。
  • Windows オペレーティング・システムでは、REXX ユーザー出口を使用してログをアーカイブすることはできません。
  • ユーザー出口プログラムまたはベンダー・プログラムは、ポイント・イン・タイム・リカバリーの後で、同じ名前の別のログ・ファイルが存在できるようにする必要があります。 その両方のログ・ファイルを保存し、正しいリカバリー・パスと関連付けるようにユーザー出口プログラムまたはベンダー・プログラムを作成する必要があります。
  • ログ・ファイルをアーカイブするために同一の磁気テープ装置を使用している複数のデータベースに対して、ユーザー出口プログラムまたはベンダー・プログラムを使用可能にしており、そのデータベースの 1 つでロールフォワード操作が行われている場合、それ以外のデータベースをアクティブにしてはなりません。 ロールフォワード操作が進行中に別のデータベースがログ・ファイルをアーカイブしようとすると、次のいずれかの状況が生じる可能性があります。
    • ロールフォワード操作に必要なログが見つからない可能性があります。
    • 磁気テープ装置にアーカイブされた新しいログ・ファイルが、その磁気テープ装置に以前に保管したログ・ファイルを上書きしてしまう可能性があります。
    上記のどちらの状態も生じないようにするために、以下のいずれかのステップを行うことができます。
    • ユーザー出口プログラムを呼び出すデータベース・パーティション上の他のデータベースが、ロールフォワード操作中にオープンしていないようにすることができます。
    • この状態を処理するようにユーザー出口プログラムを作成することができます。