log_disk_cap - アクティブ・ログ・スペース・ディスク容量構成パラメーター
このパラメーターでは、アクティブ・ログ・パスに格納するトランザクション・ログ・レコードのための最大ディスク容量を指定できます。
- まだアーカイブされていない (failarchpath に移動されていない) 非アクティブ・ログ・ファイル。
- ログ・ファイルの取得 (overflowlogpath パラメーターが設定されていない場合)。
- 拡張ログ・スペース管理が有効な場合の抽出ログ・ファイル。
log_disk_cap が構成されている場合は、処理中のトランザクションの使用に関するガイダンスとして構成パラメーター logprimary および logsecond が使用されます。 ただし、処理中のトランザクションのロギング用にディスク上に作成されるファイルの数は、他の使用量に基づいて調整される可能性があります。 logfilsiz 構成パラメーターは引き続き、アクティブ・ログ・ファイルのサイズを指定する目的で使用されます。
アクティブ・ログ・パスに、この構成で設定された量をサポートするのに十分なディスク容量があることが求められます。 mirrorlogpath 構成パラメーターが設定されている場合は、この構成で設定された量をサポートするのに十分なディスク・スペースがミラー・ログ・パスで使用可能であることも求められます。
pureScale 環境では、すべてのメンバーのアクティブ・ログ・パスに単一のファイル・システムが使用されます。 log_disk_cap の構成は、単一のメンバーによるディスク使用量を制限します。 したがって、すべてのメンバーによる使用をサポートするために、ファイル・システムで十分なディスク・スペースが使用可能であることが期待されます。 log_disk_cap * number_of_members。
DPF 環境では、各パーティションのロギングに別々のファイル・システムを使用することをお勧めします。 データベースが複数のパーティションのロギングに単一のファイル・システムを使用するように構成されている場合は、すべてのパーティションによる使用をサポートするのに十分なディスク容量がファイル・システム内にあることが求められます。
データベースのアクティブ化が正常に行われるには、すべての 1 次ログ・ファイル用に使用可能なディスク・スペースがなければなりません。 log_disk_cap が構成されている場合にデータベースのアクティブ化が正常に行われるには、少なくとも 2 つのログ・ファイル用に十分なディスク・スペースが必要になります。
- 構成タイプ
- データベース
- パラメーター・タイプ
- 構成可能
- デフォルト [範囲]
- 0 [-1 - 2147483647]
0 は、このパラメーターを使用しないという意味です。現在構成されているログ・スペースが使用されます。
-1 は、ファイル・システムがサポートできる範囲であれば、使用量に制限がないという意味です。 - 単位
- MB
推奨: アプリケーションが SQL0964N エラーを受け取るのを回避するためには、ワークロード (つまり、データベースへのすべての接続によって加えられたインフライトの変更) をサポートするための十分なディスク・スペースが必要です。
log_disk_cap がディスク上のすべてのログ関連ファイルで現在使用されているディスク・スペースよりも小さい値に構成されると、要求値は受け入れられるものの、ログのディスク・スペース使用量が要求された log_disk_cap 値を下回るまで有効になりません。
さらに、アーカイブできなかったログ・ファイルを保持するための追加のディスク容量を提供するために、failarchpath データベース構成パラメーターを設定することを強くお勧めします。 これにより、構成されたすべてのディスク・スペースを、ワークロードをサポートするために使用できます。
- (例えば Q レプリケーションや CDC レプリケーションなどの複製製品による) db2ReadLog() API の使用では、アクティブ・ログ・パスで見つからなくなったログ・ファイルからの読み取りが必要となる場合がある
- オンラインの表スペースの ROLLFORWARD 操作では、アーカイブからのログ・ファイルの取得が必要となる場合がある
- オンラインの BACKUP 操作では、バックアップ・イメージに含めるためにログ・ファイルを取得する必要が生じることがある
- スタンバイ・データベースが遅延したときは、HADR プライマリーがリモート・キャッチアップをサポートするためにログ・ファイルを取得する必要が生じることがある
無限ロギングを使用している場合 (logsecond = -1)、ログ・アーカイブが低速になったり、アーカイブ・ログ・パスがエラー状態になったりする可能性があります。 その場合、アクティブ・ログ・ファイルはアーカイブできず、アクティブ・ログ・パスから適時削除されます。 このような場合、 Db2 は、構成されているすべての (logprimary) ログ・ファイルに書き込まれている可能性があります。その場合、 Db2 は、構成されている制限を超えるアクティブ・ログ・ファイルを作成しません。 これが発生すると、ログ・アーカイブがキャッチアップするかエラーが解決されるまでの間、アプリケーションではパフォーマンスの遅れを検出する可能性があります。 この動作は、log_disk_cap がデフォルト値の 0 に設定されている場合に発生します。 このようなパフォーマンス動作を回避するには、 log_disk_cap を何らかの non-0 値に設定することを検討してください。これにより、 Db2 は、 log_disk_cap で指定された値まで、構成された制限を超える追加のログ・ファイルを作成します (-1 は無制限であるため、 Db2 は、アクティブ・ログ・パスが存在するファイル・システムの物理制限を使用しようとします)。 時間の経過とともに、追加ログ・スペースの必要性は低下してログ・ファイルの数は削減され、構成された数に戻ります。
無限ロギングを使用していて (logsecond = -1)、拡張ログ・スペース管理が有効である場合、抽出率などのスロットルの理由のため、抽出スキャンが低速になったりアイドル状態になったりする可能性があります。 その場合、新規ログ・データを抽出できるようにするには、アクティブ・ログ・ファイルを再使用する必要が生じる可能性があります。 これは、構成された (logprimary) ログ・ファイル数に達した場合に発生することがあります。 この場合、処理中のトランザクションに必要なログ・データがローカルで見つからない可能性があるため、ロールバックまたはクラッシュ・リカバリー用に、ログ・ファイルをアーカイブから取得しなければならないことがあります。 これを防ぐには、log_disk_cap を -1 に設定するか、追加のアクティブ・ログ・ファイルを作成するのに十分な値に設定します。