ARCHIVE LOGコマンドによる ログのアーカイブ 内容 ・ARCHIVE LOGコマンドによるログのアーカイブ

DB2 UDB (PC&Unix) V7.2
ARCHIVE LOGコマンドによる
ログのアーカイブ
お断り：当資料は、DB2 UDB V7.2（
UNIX,PC)をベースに作成されています。
＜第１．００版＞２００１年６月
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
内容
・ARCHIVE LOGコマンドによるログのアーカイブ
・ARCHIVE LOGコマンド使用時の考慮点
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 1-2 )
DB2 UDB (PC&Unix) V7.2
ARCHIVE LOGコマンドによるログのアーカイブ
ARCHIVE LOGコマンドで、現在書き込み中のアクティブ・
ログ・ファイル
に対するアーカイブ要求を行う
コマンド実行により、ログ・
バッファーにあるデータのディスクへのフラッシュし、アクティブ・ログ
のクローズ、USEREXITへのアーカイブ要求を行う
ARCHIVE LOGコマンド実行時点までの、完全なログ・ファイル一式を取得可能
ROLLFORWARD回復可能なデータベースでのみ使用可能
ＦＬＵＳＨ ＬＯＧ機能を、ユーザーが使用できるようにコマンドとして提供したもの
インターフェース
ARCHIVE LOGコマンド または db2ArchiveLog API
現行ログ・
パス
ARCHIVE LOG
SQL0000001.LOG
SQL0000002.LOG
SQL0000003.LOG
CLOSE
アーカイブ・
パス
SQL0000001.LOG
USEREXITによるコピー
SQL0000002.LOG
SQL0000002.LOG
SQL0000003.LOG
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ARCHIVE LOGコマンドによるログのアーカイブ
DB2 ではV7.2より、ROLLFORWARD回復可能データベースのアクティブ・ログを、ユーザーがコマンドによりクローズすることができ
ます。 また、LOGRETAIN=USEREXITの設定になっている場合であれば、USEREXITにアーカイブ要求を出します。ある時点までの
ログ・ファイルの完全なセットを収集し、それらのログ・ファイルを 使用してスタンドバイ・データベースを更新することができます。
オンデマンド・ログ・アーカイブは、DB2 ARCHIVE LOG コマンド、 またはdb2ArchiveLog API を呼び出すことによって実行できます。
NODEオプションがブランクのままの場合には、全てのノードに対して実行されます。
構文
>>-ARCHIVE LOG FOR-+-DATABASE-+-database-alias-->
'-DB-------'
>-+------------------------------+-|Node オプション-| ><
'-USER-name-+---------------+-'
'-USING-password-'
Nodeオプション
|---ON--+-| Node List clause |-------------------------+--------|
'-ALL NODES---+-------------------------- +-------'
'-EXCEPT--| Node List clause |--'
Node Listオプション
.-,----------------------------------------------.
V
|
|---+-NODE---+--(-------node-number1--+-------------------+--+-->
'-NODES--'
'-TO--node-number2--'
>----)----------------------------------------------------------|
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 3-4 )
DB2 UDB (PC&Unix) V7.2
ARCHIVE LOGコマンド使用時の考慮点
考慮事項
コマンドを実行するユーザーは、対象とするデータベースに接続していないこと
コマンド実行時に内部的にデータベースに接続するが、既に接続がある場合には、エラーが戻される
コマンドを発行するユーザーが保持する未COMMITの処理を、強制的にCOMMITしてしまうのを防ぐため
コマンドの完了が、USEREXITにより、ログ・ファイルがアーカイブ先のディレクトリーに
移動したことを保証するわけではない
ログ・バッファーへの書き込みがある他のトランザクションは、コマンド実行による
ログ・バッファーのフラッシュが完了するまで待つ
EEE環境で、ARCHIVE LOGコマンドでノード番号を指定しない場合には、全てのノードで
コマンドが実行される
実行に必要な権限：dbadm、sysmaint、sysctrl、sysadmのいづれか
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ARCHIVE LOGコマンドによるログのアーカイブ
ARCHIVE LOGコマンドを実行するユーザーが、事前にデータベースに接続している場合には、実行時にエラーが戻されます。これ
は、実行ユーザーがデータベース接続を維持しており、かつ、未コミットのトランザクションを保持している状態でＡＲＣＨＩ
ＶＥ ＬＯＧコ
マンドを実行し、未コミットのトランザクションが強制的にコミットされてしまうのを防ぐためです。ＡＲＣＨＩ
ＶＥ ＬＯＧコマンドは、完了前
に、ＣＯＭＭＩ
Ｔのログを書き込むからです。
ARCHIVE LOGコマンドがエラーとなる主なケース
SQL2417N: データベースがＲＯＬＬＦＯＲＷＡＲＤ回復可能ではない
SQL1493N: コマンド実行ユーザーが既にデータベースに接続している
オンデマンド・ログ・アーカイブの実行完了は、ログ・バッファーのデータをディスクにフラッシュさせ、アクティブ・ログ・ファイルをク
ローズし、USEREXITにアーカイブ要求を出しますが、ログ・ファイルがUSEREXITにより、すぐにアーカイブされることを保証している
わけではありません。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 5-6 )
DB2 UDB (PC&Unix) V7.2
ログ・ミラーリング
お断り：当資料は、DB2 UDB V7.2（
UNIX,PC)をベースに作成されています。
＜第１．００版＞２００１年６月
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
内容
・ログ・ミラーリング
・ログ・ミラーリングの使用手順
・ログ・ミラーリングの考慮点
・ログ・ミラーリングとROLLFORWARD時のログの検索順序
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 7-8 )
DB2 UDB (PC&Unix) V7.2
ログ・ミラーリング
ログ・ディレクトリーが１つである場合、Sigle point of failureとなる
誤ったアクティブ・ログの削除、Ｈ／Ｗ障害によるアクティブ・ログの破損
データベース・バックアップからの回復が必要
ログ・ディレクトリーのディスクが一杯になった場合
アプリケーションにエラーが戻される
ログ・ファイルを２次ログ・パスにも作成可能
ログ・ディレクトリーのSigle point of failureをなくす
１次ログ・パスにエラーが発生しても、２次ログ・パスが使用可能であればエラーは戻されない
ログ・バッファーが一杯になるか、またはコミット時点で、両方のログ・パスにデータを出力
DB2_NEWLOGPATH2レジストリー変数の設定が必要
db2set DB2_NEWLOGPATH２=ON [1,ON,YES] (省略時値はＯＦＦ）
DB2の再起動（db2stop/db2start)が必要
newlogpathで指定したディレクトリー名に ２ がつく名前が２次ログ・
パス名となる
将来的にはログ・パス名は明示的に指定できるようになる予定
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ログ・ミラーリング
ログ・ミラーリング
DB2 はV7.１+Fixpak3より、データベース・レベルでのログ・ミラーリングをサポートしています。 ログ・ファイルのミラーリングは、
以下の状況からデータベースを保護するために役立ちます。
意図しないアクティブ・ログの削除
ハードウェア障害によるデータ破壊
アクティブ・ログの損傷 (ディスク破損の結果として) が考えられる場合、 ＤB2 レジストリー変数 DB2_NEWLOGPATH2 を使用
し、ログ・ディレクトリーの 2 次ログ・パスを指定して アクティブ・ログのコピーを２重化して管理し、ログが保管されているボ
リュームをミラーリングすることを 考慮しなければなりません。DB2_NEWLOGPATH2 レジストリー変数によって、データベース
は、ログ・ファイルの同一コピーを別のパスに書き込むことができます。 物理的に別のディスク (可能であれば、別のディスク・コ
ントローラー上のディスク) に 2 次ログ・パスを 設定するようお勧めします。 これで、ディスク・コントローラーが障害の原因にな
ることはありません。
注: Windows NT および OS/2 では任意のパス名に装置をマウントできないため、これらのプラットフォームで 2 次パスを
別の装置に指定することはできません。
1 次または 2 次ログ・パスのいずれかで書き込みエラーが発生した場合、データベースは 問題のあるパスを「不良」とマーク
し、db2diag.log ファイルにメッセージを書き込み、 後続のログ・レコードを問題のない「良好」ログ・パスにのみ書き込みます。
DB2 は、現行ログ・ファイルが満杯になるまで「不良」パスを再び使い始めるための検査をしません。DB2 は、次のログ・ファイ
ルに書き込みを開始する時点で、「不良」であったパスが有効であるかどうかを検査します。 有効であれば、パスの使用を開始
します。 有効でなければ、さらに次のログ・ファイルが作成されるまで、そのパスを使用しません。DB2 は、発生したアクセス・
エラーに関する 情報を保管し、ログ・ファイルのアーカイブ時に正しいパスを使用できるようにします。両方のパスについて、書
き込み中に障害が発生した場合、データベースは異常終了します。
Ｒollforward時には、プライマリーまたはセカンダリーからLOG取得を行います。
DPROPR Capture コンポーネント
プライマリーまたはセカンダリーパスからのLog Read APIを使用した取り出しが可能です。
Logretain=Capture設定時には、自動削除が行われます。.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 9-10 )
DB2 UDB (PC&Unix) V7.2
ログ・ミラーリングの使用手順
使用手順
１．db2 "update db cfg for dbname using newlogpath /db2log/logpath "
２．db2set DB2_NEWLOGPATH２=ON
３．/db2log/logpath2 ディレクトリー（２次ログ・パスのディレクトリー）の作成
４．db2start
２次ログ・
パス名
non-MPP環境でのログ・
パス
１次ログ・パス：/db2log/logpath
２次ログ・パス：/db2log/logpath２
MPP環境でのログ・
パス
１次ログ・パス：/db2log/logpath/NODE0000
２次ログ・パス：/db2log/logpath２/NODE0000
ログバッファー
NEWLOGPATH
NEWLOGPATH２
S0000000.LOG
S0000000.LOG
DB2
S0000001.LOG
S0000001.LOG
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ログ・ミラーリングの使用手順
２次ログ・パスのディレクトリーは、事前にユーザーが作成しておく必要があります。
DB2_NEWLOGPATH2レジストリー変数を設定しておく必要があります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 11-12 )
Userexit
DB2 UDB (PC&Unix) V7.2
解説：ログ・ミラーリング使用時のdb2diag.log
DB2_NEWLOGPATH2を設定した後の、CONNECT時のdb2diag.log（正常終了時）
DIAGLEVEL=４の場合（破線で囲んだ部分は、DIAGLEVEL=３の出力
2001-05-27-10.21.46.192932 Instance:udbv71 Node:000
PID:22884(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527012146
data_protection sqlpgnlp Probe:605 Database:SAMPLE
Current Logpath2: 1, Old Logpath2: 0, ＜＝＝NEWLOGPATHを設定して最初の接続 だったので、Old Logpath2は０ 2001-05-27-10.21.46.227934 Instance:udbv71 Node:000
PID:22884(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527012146
data_protection sqlpgnlp Probe:74 Database:SAMPLE
Active logpath2: /v7dblog2/ ＜＝＝ ２次ログ・パスの活動化実施
（このメッセージ出力されていても、活動化が
成功したわけではなく、この後エラーとなる場合もある） 2001-05-27-10.21.47.318411 Instance:udbv71 Node:000
PID:22884(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527012146
buffer_pool_services sqlbStartPools Probe:0 Database:SAMPLE
Starting the database. ＜＝＝ データベースの活動化完了
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ログ・ミラーリング使用時のdb2diag.log
DB2_NEWLOGPATH2を設定した後の、CONNECT時のdb2diag.log。CONNECT前に、１次ログ・パスをumountで外し、アクセス不可
能にしたケース。
DIAGLEVEL=４の出力
2001-05-27-11.06.42.061627 Instance:udbv71 Node:000
PID:18872(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527020641
data_protection sqlpgnlp Probe:605 Database:SAMPLE
Current Logpath2: 1, Old Logpath2: 1,
2001-05-27-11.06.42.078612 Instance:udbv71 Node:000
PID:18872(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527020641
data_protection sqlpglpc Probe:50 Database:SAMPLE
attrib 00000080
2001-05-27-11.06.42.095014 Instance:udbv71 Node:000
PID:18872(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527020641
data_protection sqlpgnlp Probe:250 Database:SAMPLE
Invalid current log path: 2f76 3764 626c 6f67 2f
/v7dblog/ ＜＝＝１次ログ・パスにアクセスできない
2001-05-27-11.06.42.114874 Instance:udbv71 Node:000
PID:18872(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527020641
data_protection sqlpgnlp Probe:711 Database:SAMPLE
Initialize path2 to /v7dblog2/ ＜＝＝２次ログ・パスを初期化する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 13-14 )
DB2 UDB (PC&Unix) V7.2
解説：ログ・ミラーリング使用時のdb2diag.log
続き
2001-05-27-11.06.42.132121 Instance:udbv71 Node:000
PID:18872(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527020641
data_protection sqlpgnlp Probe:250 Database:SAMPLE
Path 2 is okay !2f76 3764 626c 6f67 322f
/v7dblog2/ ＜＝＝ ２次ログ・パスの初期化成功
2001-05-27-11.06.42.213533 Instance:udbv71 Node:000
PID:27374(db2loggr) Appid:none
data_protection sqlpgole Probe:510
file 1 open error = ffff e60a ＜＝＝ １次ログ・ファイルの割り振りを１次ログ・パスに対して行いエラーが発生
....
（２次ログ・パスに対しての割り振りエラーの場合には、" file 2 open error " となる）
2001-05-27-11.06.42.234694 Instance:udbv71 Node:000
PID:27374(db2loggr) Appid:none
oper_system_services sqloopenp Probe:36
errno: 0000 000d
....
2001-05-27-11.06.42.255913 Instance:udbv71 Node:000
PID:27374(db2loggr) Appid:none
data_protection sqlpgole Probe:515
file 1 copy error = ffff c601
2001-05-27-11.06.42.275339 Instance:udbv71 Node:000
PID:27374(db2loggr) Appid:none
data_protection sqlpgole Probe:520
open error: extnum 127ffff c601
....
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ログ・ミラーリング使用時のdb2diag.log
続き
１次ログ・パスに対するエラーは発生しているが、２次ログ・パスが使用可能なので、データベースの活動化は完了します。
実線囲みの部分は、DIAGLEVEL=4の場合に出力される
....
2001-05-27-11.06.42.294535 Instance:udbv71 Node:000
PID:27374(db2loggr) Appid:none
data_protection sqlpgole Probe:115
Error opening database log extent /v7dblog/S0000127.LOG: on path 1 ffff e50d ＜＝＝新規にログ・ファイルを
割り振る度に１次ログ・パスへの作成を試みるので、その都度エラーが発生し、db2diag.logに出力される
このケースはデータベースへの最初の接続時のdb2diag,logなので、この後、LOGPRIMARYの数分、ファイルの
OPENエラーが記録されている（ffff e50d は Bad Log File)
2001-05-27-11.04.05.306483 Instance:udbv71 Node:000
PID:27372(db2loggr) Appid:none
data_protection sqlpgifl Probe:20
DIA3501C 資源 "" のアクセスが否認されました、オペレーティ
ング・システム・戻りコードは "" です。
ZRC=FFFFC601
＜＝＝ C601は Access Denied
2001-05-27-11.04.06.075842 Instance:udbv71 Node:000
PID:22020(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527012146
buffer_pool_services sqlbStartPools Probe:0 Database:SAMPLE
Starting the database.
＜＝＝ データベースの活動化完了
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 15-16 )
....
DB2 UDB (PC&Unix) V7.2
ログ・ミラーリングの考慮点（１）
２つのログ・
パスは、別の物理ディスクに配置する
Windows環境では別の物理ディスクに配置できないので、ログ・ミラーリングの効果は無し
ディスク容量は２倍必要になり、２つのログ・パスのディスク容量の監視
を行う必要あり
ログ・パス２は、レジストリー変数を設定後にdb2を再起動し、最初に
データベースが活動化された時から使用される
データベースの活動化： ＡＣＴＩ
ＶＡＴＥ ＤＡＴＡＢＡＳＥ実行時 または 最初のデータベースへ
の接続時
最初の接続の前に、２次ログ・
パスのディレクトリーを作成しておく
必要がある
ログ・ディレクトリーが使用不可能な問題が発生した場合には、
db2diag.logにメッセージが出力される
問題の発生を検知するには、db2diag.logの監視が必要
USEREXITプログラムでは、DB2から引数として、現行のログ・
パスが渡
されるので、現行のログ・パスを意識する必要はない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ログ・ミラーリングの考慮点（２）
データベースのRESTORE時に１次ログ・
パスがアクセス不可能な場
合、および、データベース接続時に、両方のログ・パスにアクセス不可
能である場合、１次ログ・
パスが省略時のログ・
パスに変更され、２次ロ
グ・パスは省略時のログ・パス名+２になる
データベース構成パラメーターの”
ログ・ファイルのパス”
も変更される
省略時のログ・パス名+２ のディレクトリーは、RESTORE時/データベース接続時に
自動作成され、アプリケーションにエラーは戻されないことに注意が必要
ログ・パス変更の発生については、db2diag.logまたはDB構成パラメーターの確認が必要
データベース接続時に、片方のログ・パスのみアクセス不可能である場合には、有効なログ・
パスが使用される
省略時のログ・パス (AIX)： "データベース・ディレクトリー/インスタンス名/NODE0000/SQL00001/SQLOGDIR"
ログ・フル・エラーに備え、DB2_BLOCK_ON_DISK_FULLレジストリー
変数との併用を考慮する
ログ・ミラーリングを使用し、USEREXIT=OFF、
LOGRETAIN=RECOVERYの場合、２つのパスのどちらのファイルが
正しいのか（障害は無かったのか）判別するのは難しい
両方のログ・
パスに十分な容量を準備しておき、ログ・ファイルを保存しておく必要がある
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 17-18 )
DB2 UDB (PC&Unix) V7.2
解説：ログ・ミラーリングの考慮点
１次ログ・パスと２次ログ・パスは、物理的に別のディスク (可能であれば、別のディスク・コントローラー上のディスク) に 2 次ログ・
パスを 設定するようお勧めします。
データベースのRETORE時に、１次ログ・パスが使用不可能（２次ログ・パスは使用可能）であった場合、または、データベース接続
時に両方のログ・パスが使用不可能であった場合には、省略時のログ・パスに変更され、さらに２次ログ・パスのディレクトリー名も
それに伴い変更されます。また、データベース構成パラメーター”ログファイルの・パスも変更されます。
データベースのRESTORE時にも、db2diag.logの確認が必要です。
ただし、データベースのRESTORE時に、２次ログ・パスが使用不可能であっても、省略時のログ・パスに変更されることはありませ
ん。
2001-05-27-12.36.38.827753 Instance:udbv71 Node:000
PID:18872(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527033604
data_protection sqlpgnlp Probe:250 Database:SAMPLE
Invalid current log path: 2f76 3764 626c 6f67 2f
＝＝＞ １次ログ・パスが有効でない
/v7dblog/
2001-05-27-12.36.38.846582 Instance:udbv71 Node:000
PID:18872(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527033604
data_protection sqlpgnlp Probe:75 Database:SAMPLE
Initialize path2 to /home/udbv71/udbv71/NODE0000/SQL00001/SQLOGDIR2/ ＝＝＞ ２次ログ・パスが省略時の１次ログ・パス+２ に設定される 2001-05-27-12.36.38.863374 Instance:udbv71 Node:000
PID:18872(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527033604
data_protection sqlpgnlp Probe:270 Database:SAMPLE
Defaulting to log path: /home/udbv71/udbv71/NODE0000/SQL00001/SQLOGDIR/ ＝＝＞ １次ログ・パスが省略時のパスに設定される
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ログ・ミラーリングの考慮点
ディスク・フル・エラーが発生した場合、どちらかのログ・パスに空き容量があれば、空き容量があるログ・パスが使用されるが、両
方のログ・パス共にディスク・フルになってしまった場合には、DB2_BLOCK_ON_DISK_FULL＝ONを設定することにより、更新処理を
ブロックすることが可能です。
ログ・ミラーリングの機能を使用していて、USEREXITを使用しないアーカイブ・ロギングで運用した場合、ログ・ファイルに問題が発
生した場合には、２つのパスの、どちらのログ・ファイルが正しいファイルかを、db2diag.logから判断するのは非常に難しいと言えま
す。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 19-20 )
DB2 UDB (PC&Unix) V7.2
ログ・ミラーリングとROLLFORWARD時のログの検索
順序
USEREXIT=OFF, LOGRETAIN=RECOVERYの場合
１．ROLLFORWARDコマンドで指定した、OVERFLOW LOGPATH
２．現行ログ・パス（1次ログ・２次ログのどちらか有効な方）
USEREXIT=ON, LOGRETAIN=RECOVERYの場合
１．ROLLFORWARDコマンドで指定した、OVERFLOW LOGPATH
２．現行ログ・パス（1次ログ・２次ログのどちらか有効な方）
３．USEREXITにより、リトリーブ・パスから現行ログ・パスへのアーカイブ・ログ・ファイルの
コピーが行われる
現行ログ・パスにコピーされたログ・ファイルは、ROLLFORWARD実行後に削除される
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
( 21-22 )
DB2 UDB (PC&Unix) V7.2
DB2_BLOCK_ON_LOG_DISK_FULL
お断り：当資料は、DB2 UDB V7.2（
UNIX,PC)をベースに作成されています。
＜第１．００版＞２００１年６月
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
内容
・DB2_BLOCK_ON_LOG_DISK_FULL
・DB2_BLOCK_ON_LOG_DISK_FULLとログ・ミラーリング
・＜参考＞ログのエラー：SQL９６８C
・＜参考＞ログのエラー：SQL９６４C
・＜参考＞ログのエラー：SQL１００４C
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 23-24 )
DB2 UDB (PC&Unix) V7.2
DB2_BLOCK_ON_LOG_DISK_FULL
ログ・ディスク容量不足時に、更新処理をブロック
新しい環境変数：DB2_BLOCK_ON_LOG_DISK_FULLをYESに設定
db2set DB2_BLOCK_ON_LOG_DISK_FULL=YES
省略時値は、NO
アクティブ・
ログ・パスのディスク容量が満杯になった場合でも、
DB2はディスク・フル・
エラーを戻さない
ログ作成が不可能な場合には、５分ごとに、ログ・ファイル作成を試みるという情報をdb2diag.log
に出力
更新アプリケーションは、ログが作成されるまで処理がブロックされる
更新アプリケーションは、処理がブロックされるので、ハングしたように見える
list applications コマンドで見ると、ブロックされたアプリケーションは、UOW EXECUTINGとなっている
照会処理は、通常影響されない
照会処理が、更新処理によってロックされた列に関連していれば、処理はブロックされる
ログ・ディスクの使用状況の監視は必要
ＳＡＰに対応する機能追加
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DB2_BLOCK_ON_LOG_DISK_FULL
DB2_BLOCK_ON_LOG_DISK_FULL
この DB2 レジストリー変数の設定によって、 活動状態のログ・パスに DB2 が新 しいログ・ファイルを作成できないときに ディ
スク・フル・エラーを戻すのを防ぐことができます。 代わりに、DB2 は成功するまで 5 分ごとにログ・ファイルを作成しようとしま
す。 DB2 は作成を試みるたびにメッセージを db2diag.log ファイルに 書き込み ます。 ログ・ディスクがいっぱいの状態であるた
めアプリケーションがハングし ていることを 確認する唯一の方法はdb2diag.log ファイルを モニターすることです。 ログ・ファイル
が正常に作成されるまで、表データを更新しようとするユーザ ー・アプリケーションは、トランザクションをコミットできません。 読
み取り専用 の照会が直接影響を受けることはありませんが、更新要求により排他 ロックされてい るデータへのアクセス、また
は、更新アプリケーションにより読み込まれてロックがかけられている、データ・ページへのアクセスが、照会で必要になった場
合には、 読み取り専用照会もハングしているように見える状態になります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 25-26 )
DB2 UDB (PC&Unix) V7.2
DB2_BLOCK_ON_LOG_DISK_FULLとログ・ミラーリング
以下の２つの条件に合致した場合、更新トランザクションがブロックされ
るかどうかが、DB2_BLOCK_ON_LOG_DISK_FULLの設定に依存する
条件１：
ログ・ミラーリングを使用
条件２：
USEREXITが何らかの障害で、ログ・ファイルをアーカイブできない状況が発生した結
果、LFHの５エントリーを全て使用しきった場合
DB2_BLOCK_ON_LOG_DISK_FULL＝OFFの場合
LFHのエントリーを上書きする
上書きされたエントリーにあった、アーカイブされていないログ・ファイルは、ユーザー責任でアーカイブする必要
がある
DB2_BLOCK_ON_LOG_DISK_FULL＝ONの場合
ログ・ファイルのアーカイブを優先させ、データベースへの更新処理をブロック
list applications コマンドで見ると、ブロックされたアプリケーションは、UOW EXECUTINGとなっている
LFHの５エントリー
LFH（
Log Control File Header)には、ログ・パスに障害が発生した時点と復旧した時点を記録
するエントリーが５つ用意されている
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DB2_BLOCK_ON_LOG_DISK_FULLとログ・ミラーリング
ＬＦＨ（Log control File Header)には、現在のアーカイブ・パスに問題が発生した時期と、問題が発生したパスが有効になった時期を
示すセクションが追加されています。アーカイブ・パスとは、ログ・ファイルの複写元のパスを意味します。最初は、１次ログ・パスが、
アーカイブ・パスになります。１次ログ・パスに問題が発生した場合、２次ログ・パスがアーカイブ・パスになり、２次ログ・パスに問題
が発生するまで続きます。２次ログ・パスに問題が発生した時点で、１次ログ・パスが使用可能になっていれば、１次ログ・パスが
アーカイブ・パスになります。LFHには、USEREXITがどちらのパスからファイルをアーカイブすべきかの情報が記録されているので
す。
ＬＦＨは、ログ・パスの障害について、最新の情報を５つまで記録します。通常は、ログ・パス障害は頻繁に発生するものではないの
で、５つで適当であるという考えに基づいています。ただ、もし、ログ・パス障害が頻発し、さらにログのアーカイブが順調に行われず
に滞った場合、５つでは足りなくなります。そのような状況になった場合には、ＤＢ２は最も古い情報にあるアーカイブすべきログ・
ファイルを直ちにアーカイブする処理が実行されます。成功すれば、ログ・ファイルがアーカイブされます。もし、アーカイブが成功し
ない場合には、DB2_BLOCK_ON_DISK_FULLレジストリー変数を見て、ＤＢ２をブロックしてログのアーカイブを優先させるか、データ
ベース処理を続行させ、ＬＦＨの情報を失うかを決定します。ユーザーがDB2_BLOCK_ON_DISK_FULLレジストリー変数をＯＮに設定
していれば、データベース処理は抑止され、アーカイブ処理を優先実行します。ユーザーがDB2_BLOCK_ON_DISK_FULLレジストリー
変数をＯＦＦに設定していた場合には、ＬＦＨのアーカイブ情報が失われた旨のメッセージが、db2diag.logに出力されます。記録され
たパスにあるログ・ファイルは、ＤＢ２は２度とアーカイブしようとはしません。従って、これらログ・ファイルについては、ユーザーが
アーカイブしなければなりません。
LFHが上書きされる時の、db2diag.logの出力です。テストでは、SQL0000233.LOGから５つのファイルを、１次ログ・パス、２次ログ・パ
スで、５回、交互にログ・ファイルにエラーが発生するようにしておき、db2diag.logへの出力を確認しました。
SQL0000２３３．LOGのLFH情報が上書きされているので、USEREXITはSQL0000２３３．LOGをアーカイブできなくなります。
2001-05-28-15.38.15.888583 Instance:udbv71 Node:000
PID:24698(db2loggr) Appid:none
data_protection sqlpgwlp Probe:998
Dual log array is full. DB2 will overwrite useful information.
2001-05-28-15.38.15.904535 Instance:udbv71 Node:000
PID:24698(db2loggr) Appid:none
data_protection sqlpgwlp Probe:999
Overwriting: FirstArchNum 233, ExtNum 238, Start 233, End 233 , Path 9
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 27-28 )
DB2 UDB (PC&Unix) V7.2
＜参考＞ログのエラー：SQL0968C
１．SQL0968C ファイル・システムが一杯です
原因：トランザクション処理中に、ログ・パスのディスク容量が一杯になってしまった場合
対応：ログ・パスのディスク容量を増加
USEREXITによりログが退避されているかを確認
BLOCK_ON_LOG_DISK_FULL＝ONを設定し、ログ・ファイルの退避などにより、ログ・ パスのディスク容量を拡張すれば、DB2を停止せずに自動的に復旧可能
BLOCK_ON_LOG_DISK_FULL＝ONを設定した場合の状況：
照会のみのアプリケーションは、実行可能
更新処理のアプリケーションは、ハングしたようにみえる
未コミットの更新処理がロックを取得するデータに対する照会処理は、ハングしたように見える
状況：全てのデータベース・アクセスはエラーとなる
エラー出力（db2diag.log) BLOCK_ON_LOG_DISK_FULL＝ONの場合
2001-05-27-15.44.35.123424 Instance:udbv71 Node:000
PID:19726(db2loggr) Appid:none
data_protection sqlpgifl Probe:50
DIA3612C ディスクがいっぱいです。
ZRC=FFFFD60C
2001-05-27-15.44.35.142611 Instance:udbv71 Node:000
PID:19726(db2loggr) Appid:none
data_protection sqlpgadf Probe:550
Disk full on active log path. DB2 will attempt to create log file again in 5 minutes.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
＜参考＞ログのエラー：SQL964C
２．SQL964C トランザクション・ログが一杯です
原因：Logprimary+Logsecond分のアクティブ・ログを使い切ってしまった場合
対応：アクティブ・ログ・ファイル容量（数・サイズ）の増加、またはアプリケーションによる COMMITの増加
状況：照会のみのアプリケーションは実行可能
更新処理のアプリケーションにはSQL964Cが戻される
未コミットの更新処理がロックを取得するデータに対する照会処理は、LOCKWAIT
エラー出力（db2diag.log)
2001-05-27-15.40.42.083483 Instance:udbv71 Node:000
PID:24142(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527064020
data_protection sqlpgrsp Probe:50 Database:SAMPLE
Log Full -- active log held by appl. handle 0
End this application by COMMIT, ROLLBACK or FORCE APPLICATION.
2001-05-27-15.40.42.099036 Instance:udbv71 Node:000
PID:24142(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.010527064020
data_protection sqlpWriteLR Probe:80 Database:SAMPLE
DIA3609C ログ・ファイルがいっぱいです。
ZRC=FFFFD509
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 29-30 )
DB2 UDB (PC&Unix) V7.2
＜参考＞ログのエラー：SQL1004C
３．SQL1004C コマンドの処理に十分な記憶域がファイル・システムに
ありません。
原因：データベース接続時（
またはACTIVATE DATABASE時）に、ディスク容量不足でログ・
ファイルがアロケーションできない
対応：ログ・パスのディスク容量を増やす
USEREXITでログ・ファイルが退避できているかどうかを確認 状況：アプリケーションには、SQL1004Cが戻され、データベースへの接続は失敗する
他のアプリケーションも全て、データベースに接続することはできない
ログ・
パスが２重化されており、片方のログ・パスに容量があれば、そのパスが使用さ れ、エラーは戻されない
２重化されたログ・
パスの両方ともディスク領域がない場合には、エラーが戻される
エラー出力（db2diag.log)
2001-05-27-16.42.35.804812 Instance:udbv71 Node:000
PID:28950(db2agent(SAMPLE) Appid:*LOCAL.udbv71.010527074259
data_protection sqlpgifl Probe:50 Database:SAMPLE
DIA3612C ディスクがいっぱいです。
ZRC=FFFFD60C
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
( 31-32 )
DB2 UDB (PC&Unix) V7.2
パラレル・リカバリー
お断り：当資料は、DB2 UDB V7.2（
UNIX,PC)をベースに作成されています。
＜第１．００版＞２００１年６月
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
内容
・パラレル・リカバリー
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 33-34 )
DB2 UDB (PC&Unix) V7.2
パラレル・リカバリー
クラッシュ・リカバリー,および、データベース・レベルのロールフォワード
時のＲＥＤＯ処理を、複数プロセスで行う
表スペース・レベルのロールフォワード処理では、パラレル処理は行われない
ＵＮＤＯ処理は、１プロセスで行う
並行処理のために起動されるエージェントの数（ｄｂ２ａｇｎｓｃプロセス）
SMP環境： ＤＢ２がＣＰＵ数に応じて決定 (CPU数＋１）
Uniプロセッサー環境： ３つ
処理内容
INSERT/DELETE/UPDATE/ADD KEY/DELETE KEYのログ・レコードについて、
ＲＥＤＯをパラレル処理
ＣＯＭＭＩ
ＴやＲＥＯＲＧなど、他のＲＥＤＯ処理を待って行わなければならない処理は、
パラレル処理されない
ログ・レコードは、ページ単位でパラレル処理
１ページのログ・レコードは同じプロセスが処理する
ＲＥＤＯ／ＵＮＤＯ
ＲＥＤＯ：更新処理をディスクに反映する
ＵＮＤＯ：
ＣＯＭＭＩ
Ｔされていなかった更新処理をＲＯＬＬＢＡＣＫする処理で、
ＲＥＤＯフェーズの完了後に行われる
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：パラレル・リカバリー
パラレルリカバリー
DB2 V7.2より、複数のエージェントを使用して、クラッシュ・リカバリと データベース・ロールフォワード・リカバリのＲＥＤＯ処理を
実行します。 その結果、対称型マルチプロセッサー (SMP) マシンの場合、データベース・リカバリ中に 複数のエージェントを使
用することによって、パフォーマンスが飛躍的に向上しました。この拡張によって導入された新しいエージェント・プロセスは
db2agnsc です。DB2は、マシンの CPU の数に基づいて、データベース・リカバリに使用する エージェントの数を選択します。
SMP マシンの場合、使用されるエージェントの数は CPUの数 + 1 になります。DB2 は、エージェント・プロセスにページ単位で
ログ・レコードを配布し、各プロセスは１ページのログ・レコードを並行処理します。
単一CPUのマシンでは、ログの読み取り、ログ・レコードの処理、およびデータ・ページの プリフェッチ処理に、３つのエージェント
が使用されています。
DB2_USE_PARALLEL_RECOVERY レジストリー変数 の設定により、パラレル・リカバリー処理を行うかどうかを変更可能です。
省略時値はＯＮで、パラレル・リカバリーを行います。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 35-36 )
DB2 UDB (PC&Unix) V7.2
解説：パラレル・リカバリー
クラッシュリカバリー時の動き
Connect to DB
バッファープール、ロックリストなどの初期化
整合性のフラグを
検査
DBは整合性がある
DBが不整合
LFHを検査し
RESTARTするLSNを決定する
データベース
のリスタート
処理
ログの中で、RESTARTする
ＬＳＮを見つける
全ての後続のトランザクショ
ンを適用
未コミットのトランザクションの
ロールバック
ログの再初期化
接続の完了
LFH： Log congrol Ｆile Ｈeader
LSN： Log Sequence Number
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：パラレル・リカバリー
クラッシュリカバリー時のdb2diag.logの記録
2001-03-23-19.28.11.115328 Instance:db2v7 Node:000
PID:14966(db2agent (SAMPLE)) Appid:*LOCAL.db2v7.010323102810
base_sys_utilities sqledint Probe:0 Database:SAMPLE
Crash Recovery is needed.
2001-03-23-19.28.11.463671 Instance:db2v7 Node:000
PID:14966(db2agent (SAMPLE)) Appid:*LOCAL.db2v7.010323102810
recovery_manager sqlpresr Probe:1 Database:SAMPLE
DIA3908W 破損回復が開始しています。Lowtran LSN は "000000BB800C"
であり、Minbuff LSN は "000000BB800C" です。
2001-03-23-19.28.11.549291 Instance:db2v7 Node:000
PID:14966(db2agent (SAMPLE)) Appid:*LOCAL.db2v7.010323102810
recovery_manager sqlprecm Probe:125 Database:SAMPLE
Using parallel recovery with 3 agents 3 QSets 21 queues and 2 chunks
2001-03-23-19.28.12.168244 Instance:db2v7 Node:000
PID:14966(db2agent (SAMPLE)) Appid:*LOCAL.db2v7.010323102810
recovery_manager sqlprecm Probe:400 Database:SAMPLE
DIA3916W 破損回復のフォワード・フェーズが完了しました。 次の LSN は
"000000BBB1D8" です。
2001-03-23-19.28.12.355060 Instance:db2v7 Node:000
PID:14966(db2agent (SAMPLE)) Appid:*LOCAL.db2v7.010323102810
recovery_manager sqlpresr Probe:170 Database:SAMPLE
DIA3909W 破損回復が完了しました。 次の LSN は "000000BBB1D8" です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 37-38 )