DB2データベース・システム 回復管理の基礎 内容 １．回復の対象

DB2 UDB 運用管理
DB2回復管理の基礎
DB2データベース・システム
回復管理の基礎
お断り：当資料は、DB2 UDB V7.2（
UNIX,PC) をベースに作成されています。
＜第１．０１版＞２００２年４月
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
内容
１．回復の対象
２．回復の種類
３．バックアップ
４．ロギング
５．データベースの回復（リストア）
６．運用フェーズでの管理作業
おことわり
当資料の内容は、DB2 UDB/AIX V7.1を使用して作成しております。OSに依存しない内容
については、他のOSについても同様であるとお考えの上、ご利用下さい。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 1-2 )
DB2 UDB 運用管理
DB2回復管理の基礎
１．回復の対象
１−１．DB2 UDBでの回復の対象
１−２．DB2 UDBでは回復対象外のものと対応策
１−３．RAWデバイスに関する回復の考慮事項
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
IBM Japan Systems Engineering C0.,Ltd.
( 3-4 )
DB2 UDB 運用管理
DB2回復管理の基礎
1-1. DB2 UDBでの回復の対象
BACKUP/RESTORE/ROLLFORWARD/故障回復 で回復できるもの
物理的対象
DB2データベース内のオブジェクト
CREATEコマンドにより、データベース内に作成されたデータベース・オブジェクトとデータ
（表スペース、表、索引、視点（ビュー）、ユーザー定義タイプ、トリガー、スキーマ、権限など）
DB2データベース外に作成されるオブジェクトについては対象外
ストアド・プロシージャーの実行可能モジュール、UDFの実行可能モジュール
PSM(Persistent Stored Module：SQLプロシージャー）については、回復可能
以下のいづれかの方法をとることが必要
１．RESTOREの前に、データベースのDROPを行う
２．上書きRESTOREの場合、RESTOREの前にｄｂ２の再起動（db2stop/db2start)を行う
３．上書きRESTORE完了後、PSMのディレクトリーを削除する（AIXの例： sqllib/runction/routine/sqlproc/データベース名 以下）
論理的対象
作業単位(Unit Of Work)
論理作業単位(Logical Unit of Work),回復単位(Unit of Recovery)とも言う
作業結果ををデータベースシステムが保証しなければならない処理単位であり、同期点により保証される
同期点
ｼﾝｸﾎﾟｲﾝﾄ,ｺﾐｯﾄﾎﾟｲﾝﾄとも言う
明示的な同期点： COMMIT
暗黙的な同期点： プログラムの正常終了 または
CONNECT RESET (CONNECTタイプ1の場合,内部的にcommitが発行される)
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：1-1. DB2 UDBでの回復の対象
ＤＢ２システムで使用する資源の中で、ＢＡＣＫＵＰ/RESTORE/ROLLFORWARD/故障回復といった、回復のコマンドやしくみで回復
の対象となるものと、回復の対象ではないので、別途対応をしなければならないものがあります。
DB2オブジェクト（ＣＲＥＡＴＥステートメントで作成するもの）は、回復対象となります。ＳＱＬプロシージャーは、ストアド・プロシー
ジャーですが、ＣＲＥＡＴＥでデータベース内に格納されているものですので、回復対象です。
ＳＱＬプロシージャーは、ＤＲＯＰデータベースの際に、モジュールがＳＱＬプロシージャーが格納されているディレクトリーから削除さ
れます。ＲＥＳＴＯＲＥおよびＲＯＬＬＦＯＲＷＡＲＤ時に回復されるのではなく、データベースに最初の接続が入った際に、再生成されま
す。この時、接続可能なユーザーであればユーザーＩ
Ｄは、問いません。再生成された旨のメッセージは、db2diag.logに出力されま
す。
上書きでRESTOREを行う場合には、RESTOREの前にdb2の再起動（db2stop/db2start）を行う必要があります。上書きRESTOREの
場合、RESTORE後の最初の接続時に、既存のPSMのディレクトリーを削除し、再作成します。db2の再起動を行っていないと、
SQL2048N(RC=7)が発生し、PSMの再生および接続が失敗します。SQL2048Nが発生した場合には、PSMのディレクトリー（AIXの
例： sqllib/runction/routine/sqlproc/データベース名 以下）を手動で削除することにより、PSMの再生および接続を成功させること
ができます。
ＳＱＬプロシージャーのモジュール再生成時の、db2diag.logの内容
2001-05-09-16.25.47.132006 Instance:db2v7 Node:000
PID:57286(db2agent (V7DB)) Appid:*LOCAL.db2v7.010509062030
buffer_pool_services sqlbStartPools Probe:0 Database:V7DB
Starting the database. ＜＝＝データベースへの接続
2001-05-09-16.25.47.279624 Instance:db2v7 Node:000
PID:57286(db2agent (V7DB)) Appid:*LOCAL.db2v7.010509062030
PSM - SQL Procedure psm_recover_all_procs Probe:8 Database:V7DB
SQL procedure executables recovery has been initiated.
2001-05-09-16.25.47.526054 Instance:db2v7 Node:000
PID:57286(db2agent (V7DB)) Appid:*LOCAL.db2v7.010509062030
PSM - SQL Procedure psm_recover_all_procs Probe:36 Database:V7DB
SQL procedure executables recovery ended. RC: 0000 0000
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 5-6 )
DB2 UDB 運用管理
DB2回復管理の基礎
1-2. DB2 UDBでは回復対象外のものと対応策（１）
BACKUP/RECOVERY/ROLLFORWARDでは回復できない要素
別の方法での回復を行う必要がある
rootvgに作成されるもの（AIX)
rootvgのバックアップにより回復可能
/etc/services： ポート番号、サービス名
/etc/rc.db2： DB2自動起動のシェル
/var/ifor/nodelock： ライセンス (DB2の再導入によってもDB2のライセンスについては再生可能）
/var/db2/vxx(バージョン番号）以下のファイル： 環境変数とインスタンス名のファイル
インスタンス・
ディレクトリー下のユーザー定義のファイル
ファイルを保存する
ｄｂ２ｓｙｓｔｍ（DBM構成パラメーターのファイル）＝＞ファイル/UPDATEコマンド/GETコマンドの出力のどれかを保存
USEREXITプログラム ＝＞プログラムの保存
UDF ＝＞プログラムの保存
ストアド・プロシージャ ＝＞プログラムの保存
レジストリー変数の設定 ＝＞db2setコマンド/db2setでの設定状況出力のいづれかの保存 または インスタンス・ディレクトリーsqllibの下のprofile.env ファイルを保存
db2profileファイル ＝＞ファイルの保存
ディレクトリー
CATALOGコマンドの保存、または、LISTコマンドの出力を保存
他のノードにあるデータベースのDBディレクトリー、ノード・ディレクトリー、DCSディレクトリー
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
1-2. DB2 UDBでは回復対象外のものと対応策（２）
他の方法で回復可能なもの
データベース構成パラメーター
データベース・バックアップの中に保存されているため、データベース・バックアップのリストア
により回復可能
インスタンス・ディレクトリー
インスタンスの再作成により回復
ライセンス
DB2のdb2setupによる再導入、またはdb2licmコマンドによる再登録により回復可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 7-8 )
DB2 UDB 運用管理
DB2回復管理の基礎
1-3. RAWデバイスに関する回復の考慮事項
以下の際には、OWNERがrootに戻るので、インスタンスIDへの変更が
必要（AIX)
ｍｋｓｙｓｂでのバックアップを戻した時
ｉ
ｍｐ
ｏ
ｒ
ｔ
ｖ
ｇ
でディスクを戻した時
varyonvgでは、rootに戻ることはない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
IBM Japan Systems Engineering C0.,Ltd.
( 9-10 )
DB2 UDB 運用管理
DB2回復管理の基礎
２．回復の種類
２−１．復元回復（Restore Recovery）
２−２．ロールフォワード回復
２−３．故障回復
２−４．その他の回復方法
２−５．回復しない指定
２−６．DBの状況に関するDB構成パラメーター
２−７. 表スペースの状況を確認
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
2-1．復元回復（Restore Recovery）
目的：バックアップを使用してデータベースを回復する
バージョン回復とも言う
方法：RESTOREコマンド
オンライン・バックアップ：サービス稼動中に取得するバックアップ
オフライン・
バックアップ：サービスを停止してから取得するバックアップ
差分（インクリメンタル）・バックアップ：前回のバックアップからの差分のみをバックアップ
ロギングに関する条件：
オフライン・
データベース・バックアップのRESTORE
：循環／アーカイブ・ロギング両方可能
オンライン・データベース・バックアップ または 表スペース・バックアップのRESTORE
：アーカイブ・ロギングであること
回復の単位
データベース
表スペース
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 11-12 )
DB2 UDB 運用管理
DB2回復管理の基礎
解説：2-1．復元回復（Restore Recovery）
取得しておいたバックアップをリストアすることにより、データベースの回復を行うことを、復元回復と言います。
１
SQL処理
２
X月X日
障害発生
BACKUP
RESTORE
３
X月X日
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：2-1．復元回復（Restore Recovery）
RESTOREコマンド (詳細は、「DB2 UDB コマンド解説書をご参照ください。」
>>-RESTORE----+-DATABASE-+--source-database-alias--------------->
'-DB-------'
>-----+-| restore-options |------+----------------------------------><
+-CONTINUE------------+
'-ABORT--------------- '
restore-options
|---+---------------------------------------+------------------->
'-USER--username--+------------------+---'
'-USING--password--'
>-----+--------------------------------------------------------+>
+-TABLESPACE ONLINE----------------------------------------|-----------------------------|-------------+
|
.-,----------------.
|
'- INCREMENTAL -|-------------'|
|
V
|
|
'- AUTOMATIC-'
+-TABLESPACE--(-----tablespace-name---+---)--+---------+-+
|- ABOUT
-|
|
'-ONLINE--' |
'-HISTORY FILE--+---------+------------------------------'
'-ONLINE--'
>-----+---------------------------------------------------------+>
+-USE TSM--+-------------------------------+-------------+
|
'-OPEN--num-sessions--SESSIONS--'
|
|
.-,----------------.
|
|
V
|
|
+-FROM------+-directory-+--+------------------------------+
|
'-device----'
|
'-LOAD--shared-library--+-------------------------------+-'
'-OPEN--num-sessions--SESSIONS--'
>-----+----------------------+---+------------------+---+---------------------------+---+-------------------------+->
'-TAKEN AT--date-time--' '-TO--target-directory--'
'-INTO--target-database-alias--'
'-NEWLOGPATH--directory--'
>-----+-----------------------------+----+--------------------+------------------------+--->
'-WITH--num-buffers--BUFFERS--'
'-BUFFER--buffer-size--' '-DLREPORT--filename--'
>----+------------------+---+----------+----+-----------------+->
'-REPLACE EXISTING-' '-REDIRECT-' '-PARALLELISM--n--'
>----+-------------------------+---+-------------------+---+---------------------+------>
'-WITHOUT ROLLING FORWARD-' '-WITHOUT DATALINK-' '-WITHOUT PROMPTING-'
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 13-14 )
DB2 UDB 運用管理
DB2回復管理の基礎
2-2．ロールフォワード回復
目的：ログを適用し、データベースをある時点までの状態に戻す
方法：ROLLFORWARDコマンド
RESTOREの後
ROLLFORWARD保留になった時
条件：アーカイブ・
ロギングであること
回復の指定
END OF LOGS指定： ログ・パス上にある、順序番号が最後のログ・ファイルまでを適用
POINT IN TIME指定： 指定した時間のログ・ファイルまでを適用
処理内容
ログ・ファイルに記述されている処理を再度実行する
REORG、コンテナの追加・変更、LOADなども再実行されることになる
考慮事項
表スペース・バックアップをリストア後のROLLFORWARD
最後のDDLを越えた時間を指定しなければならない
Ｖ６．１までのＤＢ２では、ユーザーEXITルーチンによるログ・ファイルの取り出しは行われない
Ｖ７．１以降のＤＢ２では、ユーザーEXITルーチンによるログ・ファイルの取り出しは行われる
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：2-2．ロールフォワード回復
ROLLFORWARDコマンドは、ログを適用して、更新処理を反映させます。
１
２
更新処理
X月X日
障害発生
アーカイブ・ロギング
BACKUP
RESTORE
４
３
X月X日
障害発生の直前の時点まで戻す
ROLLFORWARD
アーカイブ・ロギング
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 15-16 )
DB2 UDB 運用管理
DB2回復管理の基礎
解説：2-2．ロールフォワード回復
ROLLFORWARDコマンド
>>-ROLLFORWARD----+-DATABASE-+---database-alias----------------->
>-----+---------------------------------------+----------------->
'-USER--username--+------------------+--'
'-USING--password--'
>-----+----------------------------------------------------------------+>
+-TO--+-isotime--+--------------+-----------+---+--------------+-+
|
|
'-ON ALL NODES-'
| +-AND COMPLETE-+ |
|
'-END OF LOGS--+--------------------+-' '-AND STOP-----' |
|
'-| On Node clause |----'
|
'--+-COMPLETE------+---+--------------------+--------------------'
+-STOP-----------+
'--| On Node clause |---'
+-CANCEL---------+
'-QUERY STATUS---'
>----+---------------------------------------------------------------+>
'-TABLESPACE----+-ONLINE-------------------------------------+--'
| .-,------------------.
|
| V
|
|
'-(-----tablespace-name---+---)--+---------+-----'
'-ONLINE--'
>-----+---------------------------------------------------------------------------+>
'-OVERFLOW LOG PATH--(--log-directory--+-----------------------------+---)--'
'-,--| Log Overflow clause |-------'
>-----+-------------------------------------------------------------+>
'-RECOVER DROPPED TABLE--drop-table-id--TO--export-directory--'
>--------------------------------------------------------------><
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：2-2．ロールフォワード回復
ROLLFORWARDコマンド（続き）
On Node clause
|---ON--+-| Node List clause |----------------------------+--------|
'-ALL NODES--+-------------------------------+-'
-EXCEPT--|
'
Node List clause |-----'
Node List clause
.-,--------------------------------------.
V
|
|---+-NODE---+--(-------node-number1--+-------------------+--+-->
'-NODES--'
'-TO--node-number2--'
>----)----------------------------------------------------------|
Log Overflow clause
.-,------------------------.
V
|
|------log-directory--ON NODE--node-number1---+-----------------|
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 17-18 )
DB2 UDB 運用管理
DB2回復管理の基礎
2-3．破損回復(Crush Recovery) （１）
目的：障害（停電など）で中断された更新処理による、データベースの
データの不整合を修正する
COMIITされている更新処理のデータを、ロールフォワードによりディスクに反映
COMMIT前に、ディスクに反映されてしまった更新データを、ロールバックにより除去
破損回復（
リスタート処理）が正常終了しない限り、データベースには接続不可能
方法：手動(方法１)と自動実行(方法２)がある
方法１：
コマンド実行時に実行
１．AUTORESTART DB構成パラメーターをOFFに指定＝＞データベース接続時
にデータベースの不整合があると、RESTARTが必要である旨のSQLエラーが戻る
２．RESTART DATABASEコマンド
方法２：
データベース接続時に実行
AUTORESTART DB構成パラメーターのON指定（省略時値） 考慮点
AUTORESTART=ON（省略時値）
の場合、誰かがデータベース接続を行った瞬間にクラッ
シュ・リカバリーが自動実行され、終了するまでデータベースは使用不可能となる
AUTORESTART=OFFであれば、接続時にRESTARTが必要である旨のSQLエラーが戻る
意図的にRESTARTを行うためには、AUTORESTART DB構成パラメーターをOFFに指定する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：2-3．破損回復(Crush Recovery) （１）
停電などの障害によって中断されたトランザクション（作業単位（LUW))によるデータベースの矛盾を排除するのが、破損回復（クラッ
シュ・リカバリー）です。
障害発生！
LUW1
ROLLBACKして更新内容を更新前に戻すことが必要
LUW２
LUW３
LUW４
RESTARTコマンド
RESTART DATABASE データベース名 [ USER user名 [ USING パスワード ] ]
[ DROP PENDING TABLESPACES ( 表スペース名、.. ）]
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 19-20 )
DB2 UDB 運用管理
DB2回復管理の基礎
2-3．破損回復(Crush Recovery) （２）
破損回復時に表スペースに問題が発生しても、RESTARTを正常終了
させる方法
RESTART DATABASE DB名 DROP PENDING TABLESPACES ［表スペース名 ，］
循環ロギングでのみ使用可能なオプション
指定した表スペースに問題があった場合でも、RESTARTを正常終了させることが可能
指定した表スペースに障害があった場合には、DROP PENDING状態となり、DROPのみ可能となる
表スペースはＤＲＯＰしかできない状態になるので、再作成が必要となる
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
2-3．破損回復(Crush Recovery) （３）
SOFTMAX DB CFG
ページ･クリーナーを起動するトリガーとなる値
SOFTMAXの値までログ・ファイルが使用されると、ページ･クリーナーは、COMMIT／未COMMITにかかわらず、更新
データをディスクに書き出す。
１ログ・ファイルのサイズに対する使用率をパーセンテージ（％）で指定
例） SOFTMAX=３00、LOGFILSIZ=1000 (4MB) の場合
ログ・ファイル３つ分（３000ページ（１２MB））が使用された時点で、ページ・クリーナーが書き出しを行う
ログ・コントロール・ファイルがディスクに書き出されるタイミング
SOFTMAXの値に達した時 あるいは ログ・ファイルが一杯になったとき
ログ・コントロール・ファイル：故障回復の際に当てるべきログ・ファイル情報を含む
softmaxの値が小さい場合
故障回復の時間が少なくなる可能性がある
ただし、長いトランザクションで少しのCOMMITしかでないものについては、少なくならない
softmaxの値が大きい場合 故障回復の時間が多くなる可能性がある
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 21-22 )
DB2 UDB 運用管理
DB2回復管理の基礎
2-4．その他の回復方法
Redirect Restore
Dropped Table Recovery（V6.1より）
表スペースのOFFLINEステータスを利用した回復（V6.1より）
その他
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
IBM Japan Systems Engineering C0.,Ltd.
( 23-24 )
DB2 UDB 運用管理
DB2回復管理の基礎
Redirect Restore
RESTORE時に表スペースのコンテナの追加・変更・削除が可能
SMS表スペースでもコンテナを増やすことが可能
DMS表スペースのコンテナのFILE＜＝＞DEVICEの変更が可能
DMS表スペース＜＝＞SMS表スペースの変更は不可能
手順(例）
１．リダイレクト・
リストアを通知
db2 restore database データベース名 form /database/path/backups redirect
２．表スペースID２のコンテナリストを変更（
コンテナの追加・削除・
変更を行う）
RAWデバイスに変更する場合には、事前にRAWデバイスの作成が必要
db2 set tablespace containers for 2 using (path '/database/patj/tbspace1',path '/dadtabase/path/tbspace2');
３．リストア先変更後のリストアを再開
db2 restore database データベース名 continue;
考慮点
必要なオプションは、REDIRECTオプションをつける最初のRESTOREコマンドで全て指定する
必要な一連のコマンドは、同一のウインドウ、または、CLPセッションから行う
手順の途中でエラーが発生した場合、以下のコマンドを実行し、RESTOREを中断する
db2 RESTORE DATABASE データベース名 ABORT
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Redirect Restore
SET TABLESPACE CONTAINERSコマンド
>>-SET TABLESPACE CONTAINERS FOR--tablespace-id----------------->
>-----+-------------------------------------------------------+------>
| .-REPLAY--.
|
'--+-IGNORE--+---ROLLFORWARD CONTAINER OPERATIONS--'
>----USING------------------------------------------------------>
.-,--------------.
V
|
>--+-(-----PATH--"container-string"---+---)---------------------------+>
|
.-,------------------------------------------------.
|
|
V
|
|
'-(------+-FILE---+---"container-string"--number-of-pages---+---)----'
'-DEVICE-'
>--------------------------------------------------------------><
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 25-26 )
DB2 UDB 運用管理
DB2回復管理の基礎
Dropped Table Recovery（１）
DROPしてしまった表を回復可能
前準備
１．表スペースの作成時に、dropped table recovery onの指定
db2 "create tablespabe 表スペース名 ...... dropped table recovery on "
２．表の作成
db2 "create table 表名 (col1 integer, col2 integer ) in 表スペース名"
回復手順
１．履歴ファイルの表ID(Backup ID) と DDLを参照しておく
db2 list history dropped table all for データベース名
２．RESTORE （データベースまたは表スペース）
db2 "restore database データベース名 ....... "
３．ROLLFORWARD時にrecover dropped tableの指定
db2 "rollforward database データベース名 ..... recover dropped table 表ID to /出力先ディレクトリー"
表IDはLIST HISTORYコマンドで調べたものを指定する
４．履歴ファイルからのDDLを元に表を再作成
CREATE TABLE ....
５．ＲＯＬＬＦＯＲＷＡＲＤ中に作成されるデータ・ファイルを使用してデータをIMPORT/LOAD
IMPORT FROM /出力先ディレクトリー/..
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Dropped Table Recovery（１）
ＤＲＯＰされた表のＰＩ
Ｔ回復については、Ｖ６．１から使用可能です。
あらかじめ、DROPPED TABLE RECOVERY ONオプションをつけたALTER TABLESPACE / CREATE TABLESPACE
より、回復すべき表を持つ表スペースに、削除された表を回復可能な性質を追加する必要があります。
に
時には誤って表が削除されてしまうことがあります。一度コミットされてしまうと、ＤＲＯＰステートメントをロールバックすることは
できません。表を回復するためにはデータベースのフル・バックアップ・イメージをリストアし、ＤＲＯＰが行われる直前までポイン
トインタイム指定でロールフォワードすることが必要です。しかしこの方法では、ロールフォワードの終了までデータベース全体
が使用不可能になってしまいます。また、表を削除した後のトランザクションは失われてしまいます。現在はロールフォワードは
ＤＲＯＰ ＴＡＢＬＥと同じかそれ以降のポイントインタイム指定でなければならないので、表スペース・バックアップのリストアと
ロールフォワードを使用することは出来ません。
”dropped table recovery”が有効に設定されている場合、DROP TABLEステートメントが実行されると、DB2はログ・ファイルに追
加のエントリを書き込みます。このエントリーは以下の項目を含みます。
(a) 削除された表名
(b) タイムスタンプ
(c) GXID - グローバル・トランザクションＩ
Ｄ。この番号は各トランザクションでユニークでありパーティションを
通して定数。
(d) TID - 表スペースＩ
Ｄ
(e) FID - 表Ｉ
Ｄ
DB2は更に履歴ファイルにもエントリーを書き込みます。そのエントリーには上記のログ・レコードのコピーだけでなく、表を再作
成するためのＤＤＬステートメントも含んでいます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 27-28 )
DB2 UDB 運用管理
DB2回復管理の基礎
解説：Dropped Table Recovery（１）
LIST HISTORY DROPPED TABLE ALL FOR sample コマンドを使用して、削除された表の履歴をリストします。
Backup IDの値が表IDです。
Operationの D は Dropped tableを意味します。Object のT は表です。Table ID と 表を再作成するためのDDLも履歴ファイルに
記録されています。
＜LIST HISTORYコマンドの出力＞
sample の履歴ファイルのリスト
突き合せファイル項目数 = 1
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID
-- --- ------------------ ---- --- ------------ ------------ -------------D T 19990608172055
00000000000002ac0002000e
表ID
---------------------------------------------------------------------------"UDBV61 "."EMPLOYEE2 " は 1 表スペースに常駐します :
00001 USERSPACE1
---------------------------------------------------------------------------コメント: DROP TABLE
開始時刻: 19990608172055
終了時刻: 19990608172055
---------------------------------------------------------------------------00001
DDL: CREATE TABLE "UDBV61 "."EMPLOYEE2" ( "EMPNO" CHAR(6) NOT NULL , "FIRSTNME" VARCHAR(12) NOT NULL
, "MIDINIT" CHAR(1) NOT NULL , "LASTNAME" VARCHAR(15) NOT NULL , "WORKDEPT" CHAR(3) , "PHONENO" CHAR(4) ,
"HIREDATE" DATE , "JOB" CHAR(8) , "EDLEVEL" SMALLINT NOT NULL , "SEX" CHAR(1) , "BIRTHDATE" DATE ,
"SALARY" DECIMAL(9,2) , "BONUS" DECIMAL(9,2) , "COMM" DECIMAL(9,2) ) IN "USERSPACE1" ;
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
IBM Japan Systems Engineering C0.,Ltd.
( 29-30 )
DB2 UDB 運用管理
DB2回復管理の基礎
Dropped Table Recovery（２）
Ｅｘｐｏｒ
ｔ
されるデータ・
ファイルの名前
/出力先ディレクトリー/NODEnnnn/data
nnnn ：ノード番号
考慮事項
１回に１つの表のみを回復可能
REGULAR 表スペースのみのサポート
LONGデータ、LOBデータはＥＸＰＯＲＴされない
EEE環境では、出力先ディレクトリーは、全てのノードからアクセス可能であること
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Dropped Table Recovery（２）
DROPPED TABLE RECOVER ONオプション(ON あるいは OFF)はREGULAR表スペースにのみ使用可能です。
ＲＥＧＵＬＡＲではないタイプの表スペースに、このオプションを指定して作成する と、”矛盾するキーワードがある” 旨
のＳＱＬ0628エラーとなります。
たとえ、ＬＯＮＧデータを、ＲＥＧＵＬＡＲデータと同じ表スペースに格納していたとしても、ＬＯＮＧデータはＥＸＰＯＲＴされません。
ＲＯＬＬＦＯＲＷＡＲＤ時に、回復させるべき表のＩ
Ｄを間違えた場合、ＲＯＬＬＦＯＲＷＡＲＤは正常に完了し、最後にデータが取り出
せなかった旨のＳＱＬ４９７９Ｗの警告エラーが戻されます。表スペースは、ＲＯＬＬＦＯＲＷＡＲＤが正常終了したため、ステータス
がＮＯＲＭＡＬに戻ります。表スペースのステータスがＮＯＲＭＡＬに戻っているために、これ以上ＲＯＬＬＦＯＲＷＡＲＤを行うことは
できません。
表スペース・レベルのＲＥＳＴＯＲＥおよびＲＯＬＬＦＯＲＷＡＲＤで、回復することも可能です。
１回のＲＯＬＬＦＯＲＷＡＲＤで１つの表データをＥＸＰＯＲＴすることが可能です。従って、異なる表スペースにある表であれば、表
スペース単位にＲＥＳＴＯＲＥおよびＲＯＬＬＦＯＲＷＡＲＤを行うことにより、各表スペースについて、１つずつの表データをＥＸＰＯＲ
Ｔすることが可能です。
ＲＯＬＬＦＯＲＷＡＲＤ中にＥＸＰＯＲＴされるデータの形式は、ＤＥＬ形式（区切り文字つきＡＳＣＩ
Ｉ
）
です。
１度に１つの表のみ回復することが可能です。誤って削除されてしまった複数の表を回復するためには、回復手順を複数回実
行する必要があります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 31-32 )
DB2 UDB 運用管理
DB2回復管理の基礎
表スペースのOFFLINEステータスを利用した回復（V6.1より)
循環ロギングで一時表スペースが壊れた場合の対応が可能
REGULAR、LONG、TEMPORARYの表スペースが壊れても、その表スペースはOFFLINEス
テータスになり、データベースへの接続は可能
データベースへの接続後に新規の一時表スペースをCREATEし、壊れた一時表スペースをDROPする
データベース接続時にクラッシュ・リカバリーが必要で、かつ、一時表スペースに障害が発生している場合には、まずま
ずRESTARTコマンドで、DROP PENDING TABLESPACEオプションを指定して実行し、正常終了させること
カタログ用表スペースが壊れた場合には、データベース接続不可能
アーカイブ・ロギングで、データベース接続時に表スペース・
コンテナに
接続不可能だった場合の回復
データベース接続時に表スペース・コンテナにアクセス不可能な場合、表スペースがOFFLINEというステータスになる
（V6.1より）。UNMOUNTされていたなど一時的なI/Oエラーだった場合、アクセス可能な状態にして再度接続することに
より、表スペースのステータスは正常に戻る。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
その他
異なるインスタンスのデータベース・バックアップのリストアは可能
注意点
SCHEMAが異なるインスタンス・ユーザーになっているデータベース・オブジェクトがある
インスタンス・ユーザーに多くの権限が与えられている
別の筐体で、インスタンス名が同じ場合は、注意点は特に無し
db2look
機能
統計情報を取り出しファイルに書き出す
SYSSTAT.XXXXXX表の統計情報をUPDATEするSQLを生成しファイルに書き出す
データベースにあるデータベース・オブジェクトのDDLを生成しファイルに書き出す
目的
統計情報を変更してベンチマークを行う場合
統計情報、DDLを保管しておきたい場合
db2move
機能
指定したデータベース内にある表のEXPORT/IMPORT/LOADを、PC/IXFファイルで行う
目的
異なるOSをまたがって、表の移行が可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 33-34 )
DB2 UDB 運用管理
DB2回復管理の基礎
2-5. 回復しない指定
処理効率を上げるために、ログをとらない指定が可能
ただし、ログをとらないため、回復は不可能
CREATE TABLEのNOT LOGGED INITALLY属性
LOBデータタイプのNOT LOGGEDオプション
LOADのNONRECOVERABLEオプション
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
IBM Japan Systems Engineering C0.,Ltd.
( 35-36 )
DB2 UDB 運用管理
DB2回復管理の基礎
CREATE TABLEのNOT LOGGED INITALLY属性（１）
CREATEまたはALTERステートメントと同じ作業単位内の、更新処理の
ログをとらない
更新処理： INSERT,DELETE,UPDATE,CREATE INDEX,DROP INDEX, ALTER TABLE
ROLLFORWARDした場合
ROLLFORWARD完了後は、表はアクセス不可能となり、DROPのみ可能となる
用途
一時的に必要な表で、ROLLFORWARD完了後にDROPしてもよい場合
処理を行った後に、バックアップを取得する場合
関連するシステム・
カタログ
SYSCAT.TABLESのLOG_ATTRIBUTE列 が １ （NOT LOGGED INITIALLY）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
CREATE TABLEのNOT LOGGED INITALLY属性（２）
考慮点１
同じ作業単位内でエラーが発生すると、作業単位はロールバックされ、
表は使用不可能となる
SQL1477 ”表’表名’にアクセスできません”
考慮点２
カタログ表にロックを取得し続けることで発生するロックの競合を防ぐため、
以下の手順での使用が望ましい
１．NOT LOGGED INTIALLY属性付きでCREATE TABLE後にCOMMITを行うことで、DB2カタログ表のロックを外す
２．別の作業単位でALTER TABLEによりNOT LOGGED INTIALLY属性の活動化を行う
３．更新処理を行う
４．COMMIT
CREATE TABLE ......
COMMIT ;
ALTER TABLE ......
更新処理 ; COMMIT ;
NOT LOGGED INITIALLY ;
ACTIVATE NOT LOGGED INITIALLY ;
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 37-38 )
DB2 UDB 運用管理
DB2回復管理の基礎
LOBデータタイプのNOT LOGGEDオプション
LOB列のログをとらない指定
LOB列を定義する時の指定： LOGGED(省略時値) または NOT LOGGED
（例）
CREATE TABLE 表名 ( COL1 CLOB (10MB) NOT LOGGED ,
LOB列のロギング
１GB以上のLOBはログできない
１０MB以上のLOBはログすべきではない
NOT LOGGEDのLOB列をROLLFORWARDした場合
LOB列の値は、ゼロでパディングされる
故障回復でのデータの整合性は保証される
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
LOADのNONRECOVERABLEオプション
LOAD時にログ（COPY)をとらない
COPY NOの指定と違い、バックアップ保留にはならない
NONRECOVERABLE付きでLOADした表をROLLFORWARDした場合
ROLLFORWARDは、NONRECOVERABLE付きのLOADについては、処理を行わず、表に
INVALIDのマークをつける。さらに、適用するログ・ファイル内にある、その表に対する処理に
ついても処理を行わない
ROLLFORWARD完了後は、表はDROPのみ可能となる
用途
再作成可能な表
一時的に必要な表
NONRECOVERABLEで複数表にLOADを行った後に、バックアップを取得する場合
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 39-40 )
DB2 UDB 運用管理
DB2回復管理の基礎
2-6. DBの状況に関するDB構成パラメーター
データベースに障害が発生した場合には、チェックが必要
db2 get db cfg for データベース名 の実行により表示
表示のみの構成パラメーター
バックアップ保留状態（YES/NO)
バックアップが要求されているかどうかを意味する
YESの場合、データベースのフル・バックアップの取得が必要
循環ロギングからアーカイブ・ロギングに変更したときにのみ、YESがセットされる
整合状態のデータベース（YES/NO)
データベースのディスク上のデータとメモリー（バッファープール）上のデータに整合性があるかどうかを意味する
更新処理中にNOになることがあるが、その場合には、ディスクとメモリー上のデータに一時的に不整合が発生したとい
う意味であり、問題はない
データベースへの接続が全て切断された状態、またはDEACTIVATE DATABASEを実行後もNOの場合、クラッシュ・
リカバリーが必要
ロールフォワード保留状態（NO/DATABASE/TABLESPACE)
ロールフォワードが要求されているかどうかを意味する
DATABASEの場合、データベースに対するロールフォワードが必要
TABLESPACEの場合、TABLESPACEに対するロールフォワードが必要
復元保留中（YES/NO)
RESTOREが要求されているかどうかを意味する
YESの場合、RESTOREが必要
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
2-7. 表スペースの状況を確認
表スペースに障害が発生した場合には、チェックが必要
db2 list tablespaces [show detail] の実行により表示
出力結果に、表スペースのステータスが表示される
正常
回復保留
ロールフォワード保留
ロールフォワード進行中
LOAD保留
バックアップ保留
など
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 41-42 )
DB2 UDB 運用管理
DB2回復管理の基礎
３．バックアップ
バックアップ：ある時点でのデータベース／表スペースの複製ファイル
バックアップの種類
データベース・バックアップ(オンライン／オフライン）
データベース・バックアップを使用して、表スペース・バックアップをRESTOREすることも可能
表スペース・バックアップ(オンライン／オフライン）
既存の表スペースのリカバリーに使用する
リストア後は、最後のDDLを越えた時点まで、ROLLFORWARDすることが必須
オフライン・
データベース・バックアップ
バックアップ取得中は、データベースへのアクセス不可能
オンライン・データベース・バックアップ
バックアップ取得中でも、データベースへのアクセス可能
リストア後は、バックアップ中のログ・ファイルをROLLFORWARDすることが必須
増分（インクリメンタル）・バックアップ
デルタ：前回の差分バックアップからの更新部分を取得
インクリメンタル：前回のフル・バックアップからの更新部分を取得
LOAD時のコピー（
アーカイブ・
ロギングのときのみ）
LOADコマンドのCOPYオプションでCOPYの取得有無を指定
LOAD時はLOGを書かないが、更新内容をLOAD時のCOPYとして記録するか、LOAD後に表スペースのバックアップを
取得するかの選択が必要
LOAD時のCOPYは、ROLLFORWARD時に使用
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：バックアップ
BACKUPコマンド
>>-BACKUP----+-DATABASE-+---database-alias---------------------->
'-DB-------'
>-----+---------------------------------------+----------------->
'-USER--username--+------------------+--'
'-USING--password--'
>-----+--------------------------------------------+------------>
| .-,----------------.
|
|
V
|
|
'-TABLESPACE--(-----tablespace-name---+---)--'
>-----+---------+----------------------------------------------->
'-ONLINE--'
>-----+-+----------------+----------------------------------------+->
| '- INCREMENTAL -+'
| '- DELTA
-'
+-USE TSM--+-------------------------------+----------+
|
'-OPEN--num-sessions--SESSIONS--'
|
|
.-,-----.
|
|
V
|
|
+-TO----+-dir-+--+--------------------------------------+
| '-dev-'
|
'-LOAD--library-name--+---------------------------------+-'
'-OPEN--num-sessions--SESSIONS--'
>-----+-----------------------------+--------------------------->
'-WITH--num-buffers--BUFFERS--'
>-----+----------------------+---+-----------------+------------>
'-BUFFER--buffer-size---'
'-PARALLELISM--n--'
>----+-------------------+-------------------------------------><
'-WITHOUT PROMPTING-'
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 43-44 )
DB2 UDB 運用管理
DB2回復管理の基礎
バックアップ・ファイル
バックアップ・ファイル名と意味
ファイル名(UNIX) ：DB別名．タイプ．インスタンス名 ．NODExxxx．CATxxxxx．タイムスタンプ．ファイル番号
その他のOSの場合：DB別名．タイプ￥インスタンス名．NODExxxx￥CATxxxxx￥yyyymmdd¥hhmmss.number．ファイ
ル番号
タイプ
０ ： データベース・バックアップ
３ ： 表スペース・バックアップ
４ ： LOAD時のコピー
ファイル順序番号（００１から開始）
バックアップ先を複数指定した場合のファイルの順序番号
BACKUPコマンドで出力先に複数ディレクトリーを指定した場合、ファイルの順序番号が００１からふられる
ディスクにとる1バックアップ・ファイルの最大サイズは６４GB
AIXのラージ・ファイル・イネーブルのファイルシステムに対応
バックアップされる領域は、使用されているEXTENT
list tablespace show detailコマンドの”使用したページ”が目安
１．TABLESPACEをCREATEしただけでは、そのスペースはBACKUP対象とはならない
２．アロケーションされたEXTENTは、たとえ全データがDELETEされていてもBACKUP対象となる
３．TABLEをDROPすることによりEXTENTが解放されれば、BACKUP対象とはならない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：バックアップ・ファイル
バックアップされる領域について、以下の順で処理をするテストを行いました。
１．既存のデータベースをBACKUP ＝＞２９MB
２．２０MBのTABLESPACEをCREATEしてBACKUP ＝＞２９MB
３．TABLEをCREATEし、４MBのデータをLOADしてBACKUP ＝＞３３．６MB
４．TABLEの全データをDELETEしてBACKUP
＝＞３３．６MB
５．TABLEをDROPしてBACKUP
＝＞２９MB
上記の結果から、バックアップの対象となる領域は、使用されているEXTENTであると言えます。
１．TABLESPACEをCREATEしただけでは、そのスペースはBACKUP対象とはならない
２．アロケーションされたEXTENTは、たとえ全データがDELETEされていてもBACKUP対象となる
３．TABLEをDROPすることによりEXTENTが解放されれば、BACKUP対象とはならない
CREATEしたばかりのTABLESPACEのバックアップすべきデータ量は、大きさに関係無く、２MB(４KB TBS)、４MB（３２KB TBS)
程度であり、これが表スペースのコントロール情報を含むデータ部分です。ただし、バックアップ・サイズはバックアップ・バッ
ファーにより異なります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 45-46 )
DB2 UDB 運用管理
DB2回復管理の基礎
db2ckbkp ユーティリティー（Ｖ7.1より）
機能
バックアップ・
ファイルがリストア可能なファイルかどうかを検査
複数ファイルにまたがる場合には、同時に全てのファイル名を指定
バックアップ・
ヘッダーに格納されたバックアップに関する情報の表示
ユーティリティーには誰でもアクセス可能
ただし、このユーティリティーを実行するために、ユーザーにはバックアップ・ファイルへの読み取り権限が必要
ファイルに使用可能
db2ckbkpはファイル／テープにあるバックアップ・
バックアップが TSMにある場合、 db2adutl を使用可能
使用方法:
db2ckbkp [ [-H] | [-h] [-o] [-d] [-c] [-a] ] ファイル名１ [<ファイル名２> ..]
出力例: バックアップファイルの検査
c:\db2ckbkp
MUSICDB.0\DB2CTLSV\NODE0000\catn0000\20000426\112011.001
[1] Buffers processed:
####
Image Verification Complete - successful.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：db2ckbkp ユーティリティー
バックアップ・イメージに関する情報を表示する、バックアップ・ファイル検査のためのユーティリティーがあります。
db2ckbkpユー
ティリティーです。これにより、以下のことが可能です。
バックアップ・イメージの整合性のテストを行い、リストア可能なファイルかどうかを決定
バックアップ・ヘッダーに格納されたバックアップに関する情報の表示
１つ以上のバックアップ・イメージの部分を検査可能
考慮点:
ユーティリティーには誰でもアクセス可能です。
ただし、このユーティリティーを実行するために、ユーザーにはバックアップ・イメージへの読み取り権限が必要です。
db2ckbkp はファイル／テープにあるのバックアップ・ファ璃うに使用可能です。
バックアップがTSMにある場合、 db2adutl を使用可能して下さい。
db2ckbkpは、単一のバックアップ・イメージ、あるいは、複数ファイルにわたるバックアップ・イメージを検査します。１つ以上のオプショ
ンを指定して、情報を表示することが可能です。
なし - オプション省略時には、バックアップ・イメージが使用可能かどうかを検査
-a - 全ての情報を表示
-c - ページ検査結果を表示 -d - DMS表スペースのデータに関する情報を表示
-h - メディアのヘッダー情報を表示
-H - メディアのヘッダー情報のみを表示
-l - LFH (Log File Header) データを表示
-o - データベース・オブジェクトの詳細情報を表示
使用方法: db2ckbkp [ [-H] | [-h] [-o] [-d] [-c] [-a] ] <バックアップ・ファイル名> [<バックアップ・ファイル名> ...]
注意:
(1) データベース・バックアップを複数ファイルに取得した場合には、最初のファイルを１番目に指定する必要があります。
(2) '-H'オプションは、バックアップ・ファイルの検査を行わず、ヘッダー情報のみを表示します。
(3)複数ファイルに渡るバックアップの場合、検査を完了するには、全てのファイルを指定して同時に検査を行う必要があ ります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 47-48 )
DB2 UDB 運用管理
DB2回復管理の基礎
解説：db2ckbkp ユーティリティー
バックアップが複数セッションを使用して取得された場合で、バックアップ・ファイルの検査を行うためには、db2ckbkpコマンドには、同
時に全てのファイルを指定する必要があります。また、順序番号００１番のファイルを最初のファイルとして指定する必要があります。
例１）2つのファイルにまたがるバックアップ・ファイルのうち1つを指定した場合
$ls -la
-rw-r----- 1 udbv7
-rw-r----- 1 udbv7
v7gp
v7gp
8421376 Jun 06 16:30 SAMPLE.0.udbv7.NODE0000.CATN0000.20000606162959.001
4198400 Jun 06 16:30 SAMPLE.0.udbv7.NODE0000.CATN0000.20000606162959.002
$ db2ckbkp SAMPLE.0.udbv7.NODE0000.CATN0000.20000606162959.002
[1] Buffers processed: ##
ERROR! Only 1 of 2 backup images in this set were checked!
ERROR! No backup tail found!
Image Verification Complete - ERRORS DETECTED: 2 ＜＝＝ バックアップ・ファイルの検査は不成功
例１）2つのファイルにまたがるバックアップ・ファイルの全てを指定した場合
$ db2ckbkp SAMPLE.0.udbv7.NODE0000.CATN0000.20000606162959.001 SAMPLE.0.udbv7.NODE0000.CATN0000.20000606162959.002
[1] Buffers processed: ###
[2] Buffers processed: ##
Image Verification Complete - successful. ＜＝＝ バックアップ・ファイルの検査は成功
このユーティリティーは、テープにあるバックアップ・イメージも検査することができます。RESTOREの際と同様にテープを準備し、テー
プデバイス名を指定してユーティリティーを実行します。
例) UNIXベースのシステムの場合には、
db2ckbkp -h /dev/rmt0
Windows NTシステムの場合には、
db2ckbkp -d \\.\tape1
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：db2ckbkp ユーティリティー
C:\backups>db2ckbkp -H MUSICDB.0\DB2CTLSV\NODE0000\catn0000\20000426\112011.001
=====================
MEDIA HEADER REACHED:
=====================
Server Database Name
-- MUSICDB
Server Database Alias
-- MUSICDB
Client Database Alias
-- MUSICDB
Timestamp
-- 20000426112011
Node
-- 0
Instance
-- DB2CTLSV
Sequence Number
-- 1
Release ID
-- 900
Database Seed
-- 396A88EE
DB Comment's Codepage (Volume) -- 0
DB Comment (Volume)
-DB Comment's Codepage (System) -- 0
DB Comment (System)
-Authentication Value
-- 255
Backup Mode
-- 0
Backup Type
-- 0
Backup Gran.
-- 0
Status Flags
-- 11
System Cats inc
-- 1
Catalog Node Number
-- 0
DB Codeset
-- IBM-1252
DB Territory
-Backup Buffer Size
-- 4194304
Number of Sessions
-- 1
Platform
-- 5
The proper image path would be:
MUSICDB.0\DB2CTLSV\NODE0000\CATN0000\20000426\112011.001
Image header dumped -- NO VERIFICATION PERFORMED.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 49-50 )
DB2 UDB 運用管理
DB2回復管理の基礎
４．ロギング
ログとは
データベースへのすべての更新内容を発生順に記録しておくファイル
ログ・データがバッファーからディスクに書き出されるタイミング
COMMIT時 または ログ・
バッファーが一杯になったとき
ＭＩ
ＮＣＯＭＭＩ
Ｔ
データベース構成パラメーターにより、ログを書き出すまでのＣＯＭＭＩ
Ｔ回数を指定可能
ただし、１秒経過するとログは書き出される
ログ・バッファーの中のデータ部分だけが書き出される
ログ・バッファー・サイズ単位で書き出されるわけではない
ログはデータより必ず先にディスクに書き出される
障害時におけるデータの整合性を保証するため（WLA: WRITE LOG AHEAD）
ロールバック・ロールフォワードに使用される
ロールバック ：最後の同期点取得時点の状態にまでデータを戻す
ロールフォワード：最新の同期点取得時点の状態にまでデータを更新する
ロギング方法
循環ロギング：アーカイブ・ログは、上書きして再利用される
アーカイブ・
ロギング：アーカイブ・ログを残す
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：４．ロギング
ログ・データがバッファーからディスクに書き出されるタイミングは、COMMIT時 または ログ・バッファーが一杯になった時です。
ただし、ＭＩ
ＮＣＯＭＭＩ
Ｔ
データベース構成パラメーターが、１より大きく設定されていた場合には、設定された回数のＣＯＭＭＩ
Ｔ
が実
行されるか、または、１秒経過するかのどちらか早い方のタイミングで、ログ・データがバッファーから書き出されます。
ＭＩ
ＮＣＯＭＭＩ
Ｔ
データベース構成パラメーターを設定した方が良い場合は、非常に多くのトランザクションが短時間に同時にＣＯＭＭ
Ｉ
Ｔ
を実行する可能性が大きい場合です。ＭＩ
ＮＣＯＭＭＩ
Ｔデータベース構成パラメーターは、設定後に即時に反映されます。データ
ベースへの接続を全て切断する必要はありません。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 51-52 )
DB2 UDB 運用管理
DB2回復管理の基礎
ログの状態
アクティブ・
ログ
現在使用中のログ・ファイルで、クラッシュ・リカバリーに使用される
絶対に削除してはいけない ＝＞データベース・バックアップからの回復が必要となる
メモリーからディスクへの書き込みがまだ行われていない処理内容で, COMMIT済みの処理,
未COMMITの処理を含む
データベース・ログパス・
ディレクトリー上に配置される
オンライン・アーカイブ・ログ
クラッシュ・リカバリーには使用されないログ・ファイル
アクティブ・ログが満杯になり、かつ、含まれている処理内容がすべてCOMMIT済みになり、ディスクへの書き込みも完
了した時、そのログ・ファイルはクローズされオンライン・アーカイブ・ログになる
データベースに対する接続が全て切断された時には、たとえアクティブ・ログが満杯になっていなくても、ファイルはク
ローズされオンライン・アーカイブ・ ログになる
ROLLFORWARD回復に使用される
データベース・ログパス・
ディレクトリー上に配置される
オフライン・アーカイブ・ログ
データベース・ログパス・
ディレクトリー以外の場所にコピーされた、アーカイブ・
ログ・ファイル
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ログの状態
ログ・ファイルの状態
アクティブ・ログ
オンライン
アーカイブ・ログ
オフライン
アーカイブ・ログ
S0000001.LOG
COMMIT前のトランザクション、
ディスクに反映されていない
更新データがある
クラッシュ・リカバリーに必要
絶対に削除してはいけない
S0000001.LOG
COMMITされ、
更新データが全て
ディスクに書きこまれた
S0000001.LOG
ファイルはクローズされる USEREXITなどで別の場所に移す
ログ・パス上に存在する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 53-54 )
DB2 UDB 運用管理
DB2回復管理の基礎
１次ログ・２次ログについて
１次ログ・
ファイルとは
データベース接続時に、LOGPRIMARYの個数分のファイルが最初に割り振られる
アーカイブ・
ロギングでは、使用可能なログ・ファイルが常にLOGPRIMARYの数を保つように、
１次ログ・ファイルが割り振られる
LOGPRIMARYの個数内でアクティブ・ログをまかなえることが望ましい
２次ログ・
ファイルとは
アクティブ・ログの数が１次ログ・ファイルの数に達した時にのみ、追加のアクティブ・ログとし
て割り振られるファイル
ファイル・
サイズについて
１次ログで、アクティブ・ログをまかなえることが望ましい
ファイルサイズを大きくした場合には、SOFTMAX DB構成パラメーターで、非同期更新のタイ
ミングを調整し、クラッシュ・リカバリーに長時間要することのないよう考慮する
アクティブ・
ログ・ファイルの最大は３２GB (V7.1より）
(LOGPRIMARY + LOGSECOND) ＊ LOGFILSIZ ＜＝ ３２GB （V6.1までは４GB）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：１次ログ・２次ログについて
ファイルのサイズとクラッシュ・リカバリー
省略時値で、SOFTMAX=100％、LOGFILSIZ=１０００ページ の場合、
１ログ・ファイルが一杯になった時点で、更新データがディスクに書きこまれます。
この後障害が発生し、クラッシュ・リカバリーが行われると、未COMMITの更新データはROLLBACKされます。
頻繁にCOMMITがある場合には、クラッシュ・リカバリー時にROLLBACKする未COMMITの更新データは少ないので時間も短く
なりますが、COMMITが非常に少ない場合には、ROLLBACKしなければならない更新データも多くなり、時間もかかります。
ファイルが一杯になるまで更新データはディスクに書きこまれませんので、ファイルのサイズが大きいと、クラッシュ・リカバリー
の処理に時間がかかります。
アクティブ・ログ・ファイルの最大値が、Ｖ７．１で３２ＧＢになりました。ＥＥＥ環境の場合、この上限はパーティションごとになります。
ログ・
ファイルが一杯
UPDATE
COMMIT
DELETE
COMMIT
INSERT
更新データをディスクに書き出す
UPDATE
COMMIT
DELETE
COMMIT
INSERT
この後、障害が発生し、クラッシュ・リカバリーが行われると、
UPDATE
COMMIT
DELETE
COMMIT
INSERT
COMMITされていない更新データを
ROLLBACKする
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 55-56 )
UPDATE
COMMIT
DELETE
COMMIT
INSERT
DB2 UDB 運用管理
DB2回復管理の基礎
ログの保管場所
データベース・ログパス・ディレクトリー（
Unix）
(例）/データベース・
ディレクトリー/ｲﾝｽﾀﾝｽ名/SQL0000x/SQLOGDIR
データベース・ディレクトリー
CREATE DATABASEコマンドでデータベースを作成する際に指定する,データベースの作成場所のディレクトリー
(例) ”CREATE DATABASE SAMPLE ON /dbpath” をinst1のインスタンスで実行すると
/dbpath/inst1/SQL00001/SQLOGDIRの下にログ・ファイルが作成される。
データベース・ログパス・ディレクトリー（
Windows）
(例）Ｄ：￥ＤＢ２￥¥NODE0000¥SQL00001¥SQLOGDIR¥
ログの保管場所の考慮点
ディスク障害に備えて、データベースとは別の物理ディスクに配置する
ミラーリングを行う、またはRAID5構成にする
NEWLOGPATH DB構成パラメーターにより、パスを変更可能
ログ・ファイル名
S0000000.LOG - S9999999.LOGまでを順に使用する
最後の順序番号まで使用した場合には、再度最初の番号から使用される
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
IBM Japan Systems Engineering C0.,Ltd.
( 57-58 )
DB2 UDB 運用管理
DB2回復管理の基礎
ログに関するDB構成パラメーター（１）
構成可能なもの
LOGRETAIN (RECOVERY/CAPTURE/OFF 省略時OFF) RECOVERY： アーカイブ・ロギングし、ロールフォワード・リカバリーを可能にする
CAPTURE： CAPTUREプログラムのためにアーカイブ・ロギングするが、ロールフォワード・リカバリーは不可能
OFF： 循環ロギング。ロールフォワード・リカバリーは不可能
USEREXIT (ON/OFF 省略時OFF)
ON： アーカイブ・ログの保管と取り出しをユーザー出口プログラムを使用して行う。ロールフォワード・リカバリー可能
OFF： アーカイブ・ログの保管と取り出しをユーザー出口プログラムを使用しない。
LOGPRIMARY (省略時 3)
１次ログファイルの数 (最低限２つは必要）。データベース接続時にアロケーションされる。
LOGSECOND (省略時 2)
２次ログファイルの数
LOFILSIZ (省略時 1000）
ログファイルのサイズをページ数で指定する（４ＫＢ／ページ）
LOGBUFSZ (省略時 8)
ログ・レコードを書き出すためのバッファーのサイズをページ数で指定する（４ＫＢ／ページ）
OLTP系の処理では、大きくする
NEWLOGPATH
アクティブ・ログファイルを書き出す先を変更する場合に指定する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ログに関するDB構成パラメーター（２）
SOFTMAX（省略時 100)
１ログ・ファイル・サイズに対するパーセンテージ（％）を指定する
ページ・クリーナー起動のためのソフト・チェックポイントになる
表示のみ
ログ・ファイルのパス
ロギングに使用されている現在のパス
最初の活動ログ・
ファイル
最初のアクティブ・ログのログファイル名
”次の活動ログ・ファイル”の表示は、V7.1よりなし
構成パラメーターの設定確認
GET DB CFG FOR データベース名
db2 "get db cfg for DBNAME"の出力例（一部を抜粋）
ログ・ファイルのサイズ (4KB)
1 次ログ・ファイル数
2 次ログ・ファイル数
ログ・ファイル用に変更されたパス
ログ・ファイルのパス
最初のアクティブ・
ログ・ファイル
(LOGFILSIZ) = 250
(LOGPRIMARY) = 3
(LOGSECOND) = 2
(NEWLOGPATH) =
= C:¥DB2¥NODE0000¥SQL00001¥SQLOGDIR¥
=
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 59-60 )
DB2 UDB 運用管理
DB2回復管理の基礎
循環ロギング
目的
ロールフォワードを必要としない場合のロギング方法
クラッシュ・リカバリーに必要のないアーカイブ・
ログは再利用する
指定方法
ＬＯＧＲＥＴＡＩ
Ｎ（ＤＢ ＣＦＧ）＝ＮＯまたはＯＦＦ、あるいはＣＡＰＴＵＲＥ（Ｖ６．１）
CAPTURE 指定の場合、アーカイブ・ログはCAPTUREプログラムが使用するために維持されるが、CAPTUREプログラ
ムにより削除される
ＵＳＥＲＥＸＩ
Ｔ（ＤＢ ＣＦＧ）＝ＮＯまたはＯＦＦ
特徴
内容が全てＣＯＭＭＩ
Ｔされ、ディスクに書き出された１次ログ・ファイルは再利用される
ロールフォワード・リカバリーはできない
クラッシュ・リカバリーは行う
アクティブ・ログのみを使用して、あくまでも各ＬＵＷの整合性の維持のみを行う
1
"n"
PRIMARY
2
1
"n"
SECONDARY
3
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：循環ロギング
ログ・ファイルは、そのファイルに記録されているトランザクションが終了し、かつ、ディスクに反映された場合、再使用可能となりま
す。
いずれのロギング・タイプであっても、トランザクションは、全てのプライマリーとセカンダリ−のログ・ファイルがアクティブな状態で
杯になる前に、終了する必要があります。終了しない場合には、ログ・フル・エラーとなります。
プライマリー・ログがすべてアクティブな状態で一杯になると、セカンダリー・ログがアロケートされます。
セカンダリー・ログは、一旦作成されると、データベースが非活動化（Ｄｅａｃｔｉ
ｖ
ａ
ｔ
ｅ
）
されるまでアロケートされたまま残ります。データ
ベースが非活動化された状態とは、全ての接続が切断された時、もしくは、明示的にDeactivateコマンドが実行されて正常終了した
時を指します。
ＬＯＧＲＥＴＡＩ
Ｎ＝CAPTURE
ログはＣａ
ｐ
ｔ
ｕ
ｒ
ｅ
プログラムがＣＤ表にログ・ファイル内の変更を書き込むためだけに保存される
ロールフォワード・リカバリーを使用不可能
Ｃａｐｔｕｒｅプログラムが完了した時に、Ｃａ
ｐ
ｔ
ｕ
ｒ
ｅ
プログラムはPRUNE LOGFILEコマンドを呼び出し、ログファイルを削除する :
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 61-62 )
DB2 UDB 運用管理
DB2回復管理の基礎
循環ロギングのしくみ
循環ロギングのしくみ
正常処理時(１次ログのみが使用されているパターン）
LOGPRIMARYで指定した数を越えてアクティブ・ログが作成されることがないため、必要なくなったオンライン・アーカイ
ブ・ログが上書きで再利用されていく
理想的なパターン
DB構成パラメーター
LOGPRIMARY 3
LOGSECOND 2
LOGFILSIZ
1000
LOGRETAIN NO
USEREXIT
NO
Ｐ２
Ｐ１
Ｐ３
正常処理時(２次ログも使用されているパターン）
LOGPRIMARYで指定した数を越えてアクティブ・ログを必要とするため、２次ログが作成されている。
２次ログの最大個数に達するまでに１次ログ・ファイルがオンライン・アーカイブ・ログになり、再利用されていくので、ロ
グ・フル・エラーにはならない
DB構成パラメーター
Active
Active
Active
Ｐ１
Ｐ２
Ｓ１
Active
Ｐ３
Full
!!
LOGPRIMARY
LOGSECOND
LOGFILSIZ
LOGRETAIN
USEREXIT
3
2
1000
NO
NO
Ｓ２
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：循環ロギングのしくみ
正常処理時(１次ログのみが使用されているパターン）
ＬＯＧＰＲＩ
ＭＡＲＹの数の１次ログファイルが作成され、順に使用されます。
正常処理時(２次ログも使用されているパターン）
１次ログファイル中の処理内容が全てＣＯＭＭＩ
Ｔされ、ディスクに書き出された時点で、そのファイルは再使用可能な状態にな
り、１次ログファイルは順に上書きされて再利用されます。
１次ログファイルがアクティブな状態で一杯になり、かつ、再使用可能な状態の１次ログファイルがない場合、２次ログファイルが
１つずつ作成されます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 63-64 )
DB2 UDB 運用管理
DB2回復管理の基礎
循環ロギング時のログ・フルエラー
ロギングに関するエラー：データベース処理ができなくなる
SQL0964C”トランザクション･ログが一杯です”
２次ログの最大個数を越えてアクティブ・ログが必要になってしまう
対応策：
- LOGPRIMARY、LOGSECOND、LOGFILSIZの値の増加を検討する
- ＣＯＭＭＩ
Ｔ
回数を増やす
Active
Active
Active
Ｐ１
Ｐ２
Ｓ１
Active
Ｐ３
Full
!!
Full
!!
Active
Ｓ２
Full
!!
LOGPRIMARY 3
LOGSECOND 2
LOGFILSIZ
1000
LOGRETAIN NO
USEREXIT
NO
SQL0964C ログ・フル・エラー !!
ログ・パス・ディレクトリーのあるディスクが一杯になる
ログ・ファイルのアロケーションができなくなる
対応策：
- ログ・パス・ディレクトリーのあるファイル･システムを広げる
- LOGPRIMARY、LOGSECOND、LOGFILSIZの値の縮小を検討する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：循環ロギング時のログ・フルエラー
ログ・ファイルのアロケーション・エラーが発生するのは以下のいづれかの場合です。
ディスク容量はあるが、アクティブ・ログ・ファイルの数が、１次ログ・ファイルと２次ログ・ファイルの合計数を越えてしまう場合
ログ・ファイルをアロケーションするためのディスク容量がない場合
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 65-66 )
DB2 UDB 運用管理
DB2回復管理の基礎
循環ロギング使用時の考慮事項（１）
用途
照会のみのデータベース
更新データの回復が他の方法で可能な場合
最新のデータが他の場所に存在するので、データの再ＬＯＡＤが可能
トランザクションの再実行が可能
バックアップ時間が短く、かつ、バックアップ時までの回復で問題ない場合
ロールフォワード回復はできない
オンライン・バックアップ／表スペース・バックアップからの回復はできない
LOAD時のCOPYは必要なし
COPY NOでLOAD後も、表スペースがバックアップ保留にならない
オフライン・データベース・
バックアップを定期的に取得する必要あり
アクティブ・
ログは絶対に削除してはいけない
データベース・バックアップからの回復が必要となる
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
循環ロギング使用時の考慮事項（２）
表スペースの障害
一時表スペースが壊れた場合の回復が可能（
V6.1より）
REGULAR、LONG、TEMPORARYの表スペースが壊れても、その表スペースはOFFLINEステータスになり、
データベースへの接続は可能。ただし、カタログ用表スペースが壊れた場合には、データベース接続不可能
データベースへの接続後に新規の一時表スペースをCREATEし、壊れた一時表スペースをDROPする
カタログ用ではないREGULAR表スペースがOFFLINEの場合、削除することは可能
表スペースに障害が発生しても、クラッシュ・リカバリーを正常終了させることが可能
RESTART DATABASE DB名 DROP PENDING TABLESPACES 表スペース名 ［ ，］
循環ロギングでのみ使用可能なオプション
指定した表スペースに問題があった場合でも、RESTARTを正常終了させることが可能
指定した表スペースに障害があった場合には、DROP PENDING状態となり、DROPのみ可能となる
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 67-68 )
DB2 UDB 運用管理
DB2回復管理の基礎
アーカイブ・ロギング
目的
ROLLFORWARD回復により、ログを適用した回復を目的とする
指定方法：以下のいづれか
LOGRETAIN=ONまたは、ＲＥＣＯＶＥＲＹ（
Ｖ６．１より）
ログ・ファイルをログパス上に保存する
USEREXIT=ON
ユーザーＥＸＩ
Ｔルーチンにより、ログ・ファイルをログパス以外の場所に移して保存する
データベースに対するROLLFORWARD時には、ユーザーEXITルーチンにより、ログ・ファイルの取りだしが行われる
V7.1以降では、表スペースに対するROLLFORWARD時にも、ユーザーEXITルーチンにより、ログ・ファイルの取りだし
が行われる
上記両方をONにした場合には、USEREXITの指定が優先となる
特徴
ログ・ファイルは全て保存される
LOGRETAIN=ONでは、常に使用可能な１次ログ・ファイルの数が保持されるように、ログ・ファ
イルが割り振られる
USEREXT=ONでは、コピー済みのオンライン・アーカイブ・
ログ・ファイルは再利用される
２次ログファイルの割り振りのしくみは循環ロギングに同じ
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：アーカイブ・ロギング
アーカイブ・ロギングとは、データベース／表スペースのリストア後に、ログ・ファイルを適用して、ある時点まで、またはログ・パス上
にある最後のログ・ファイルまでの更新処理内容を反映させるために、ログを残しておくロギング方法です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 69-70 )
DB2 UDB 運用管理
DB2回復管理の基礎
LOGRETAIN=ON/RECOVERY
LOGRETAIN時のアーカイブ・ロギングのしくみ
正常処理時(１次ログのみが使用されているパターン）
LOGPRIMARYで指定した数を越えてアクティブ・ログが作成されることがない
理想的なパターン
最初に割り振られたファイル
Archive
P1
Archive Archive
P2
P3
Archive
Active
P4
P5
LOGPRIMARY 3
LOGSECOND 2
LOGFILSIZ
1000
LOGRETAIN YES
USEREXIT
NO
正常処理時(２次ログも使用されているパターン）
２次ログの最大個数に達するまでに１次ログ・ファイルがオンライン・アーカイブ・ログになるので、ログ・フル・エラーに
はならない
最初に割り振られたファイル
Archive Archive
P1
P2
Active
Active
Active
P3
P4
S1
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：LOGRETAIN=ON/RECOVERY
正常処理の場合１
１．ＬＯＧＰＲＩ
ＭＡＲＹの数の１次ログファイルが作成され、順に使用される
２．１次ログファイル中の処理内容が全てＣＯＭＭＩ
Ｔされ、ディスクへの書き出しも完了した時点で、そのログファイルはクローズ
され、アーカイブ・ログとなる。
３．１次ログファイルはＬＯＧＰＲＩ
ＭＡＲＹで設定された数が常に作成されているよう、使用するログが切り替わるたびに新しいロ
グファイルが作成される
４・データベースに対する接続が全て切断されると、使用されたログファイルはクローズされる。
次回の接続からは新規の１次ログファイルが作成されるが、前回作成されていて使用されなかったログファイルは、再使用され
る。
正常処理の場合２
ＬＯＧＰＲＩ
ＭＡＲＹの数のログファイルが全て、アクティブ・ログになった場合には、ＬＯＧＳＥＣＯＮＤの数まで、追加でアクティブ・ロ
グ用のログ・ファイルを作成することができる。
アクティブ・ログの中のトランザクションが全てコミットされ、ディスクに書き出されれば、アーカイブ・ログとなり、ファイルはクロー
ズされる。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 71-72 )
DB2 UDB 運用管理
DB2回復管理の基礎
USEREXIT=OＮのログ・アーカイブ処理
USEREXIT時のアーカイブ・
ロギングのしくみは
LOGRETAIN=ON/RECOVERY時と同じ
ファイルのアーカイブがUSEREXITルーチンにより行われる
USEREXITルーチンが起動されるタイミング
ログ・ファイルが一杯になったとき
USEREXITルーチンは、ファイルのアーカイブを行う
db2cartプロセス（UNIX)が、USEREXITをコールする
アーカイブされ、更新処理が全てCOMMITされ,、更新データがディスクに書き出されたログ・
ファイルは、RENAMEされ、新規のログ・
ファイルとして再利用される
新規のファイルを割り振る負荷を軽減
１．ログ・ファイル
が一杯！
1-1
LOG1
２．
アーカイブが完了し、
更新データはCOMMITされ、
ディスクに書き出し済み！
DB2
２
1-2
再利用
可
ARC１
1-3 ログ・ファイルを
アーカイブ
USEREXIT
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：USEREXIT=ON
ＵＳＥＲＥＸＩ
Ｔ
＝ＯＮの場合、アーカイブ先のディスク容量が足りないために、ＵＳＥＲＥＸＩ
Ｔ
プログラムがログ・ファイルをアーカイブで
きず、それが原因となり、ログ・ファイルをアロケーションができなくなってしまうことに注意してください。アーカイブ先にも十分な容量
を確保しておくことが必要です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 73-74 )
DB2 UDB 運用管理
DB2回復管理の基礎
アーカイブ・ロギング時のログ・フルエラー
ロギングに関するエラー：データベース処理ができなくなる
SQL0964C”トランザクション･ログが一杯です”
２次ログの最大個数を越えてアクティブ・ログが必要になってしまう
対応策：
- LOGPRIMARY、LOGSECOND、LOGFILSIZの値の増加を検討する
LOGPRIMARY 3
LOGSECOND 2
LOGFILSIZ
1000
LOGRETAIN YES
USEREXIT
NO
最初に割り振られたファイル
Active
Active
Active
P1
P2
P3
Active
Active
S１
S２
SQL0964C Log full error
Full!! !!
ログ・パス・ディレクトリーのあるディスクが一杯になる
ログ・ファイルのアロケーションができなくなる
対応策：
- ログ・パス・ディレクトリーのあるファイル･システムを広げる
- LOGPRIMARY、LOGSECOND、LOGFILSIZの値の縮小を検討する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：アーカイブ・ロギング時のログ・フルエラー
ログフル・エラーの場合
ＬＯＧＰＲＩ
ＭＡＲＹ，ＬＯＧＳＥＣＯＮＤを足した数分のログファイルがアクティブ・ログとなり、それ以上のログ・ファイルを必要とした
場合には、ログフル・エラーが発生する ログフル・エラーを避けるには
必要となるアクティブ・ログの数をＬＯＧＰＲＩ
ＭＡＲＹの数に設定する
２次ログファイルの割り振りにはオーバーヘッドがかかるため、なるべく通常は割り振られないように、十分な１次ログを用意して
おく。
ディスク・フル・エラー
ログ・パスが存在するディスクに空き容量がなくなってしまった場合には、ディスク・フル・エラーが発生する
ＬＯＧＲＥＴＡＩ
Ｎ＝ＯＮにより、ログ・パス上にログを保存しておく方法をとった場合には、ディスクの空き容量に注意する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 75-76 )
DB2 UDB 運用管理
DB2回復管理の基礎
アーカイブ・ロギング使用時の考慮点
アーカイブ・ロギング時の注意
正しいバックアップと、全てのログ・ファイルが使用可能である必要がある
ログ・ファイルを安全に保管しておくこと
アクティブ・ログファイルを削除しないこと
ログ・パスのディスク容量が十分であること
ユーザーEXITルーチンで退避先のディスク容量が十分であること
EEE環境では
全てのパーティションについてバックアップを取る必要がある
①カタログ・パーティション②その他、の順でリストアする必要がある
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
IBM Japan Systems Engineering C0.,Ltd.
( 77-78 )
DB2 UDB 運用管理
DB2回復管理の基礎
５．データベースの回復（リストア）
データベース回復には以下が必要
循環ロギング
の場合
アーカイブ・
ロギング
の場合
故障回復
復元回復
（
クラッシュ・
リカバリー） （
RESTOREリカバリー）
ロールフォワード回復
アクティブ・ログ
オフライン・
バックアップ
不可
アクティブ・ログ
オフライン・
バックアップ
アーカイブ・ログ
または
および
オンライン・バックアップ
LOAD時のコピー
（
ロールフォワード必須）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：５．データベースの回復（リストア）
データベース回復に必要なものは、上記の表のとおりです。必要なファイルをまとめて管理しておくことが重要です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 79-80 )
DB2 UDB 運用管理
DB2回復管理の基礎
リストア
リストアとは
バックアップ・
イメージを戻して、データベース／表スペースの回復を行う
データベースのリストアはオフラインで行う
表スペースのリストアはオフライン／オンライン両方可能
新規の作成／既存のデータベースをREPLACE の両方可能
リストアの考慮点
異なるOSをまたがって、バックアップをリストアすることはできない
V7.2（V7.1+Fixpak3)より、ＨＰとＳｏｌ
ａ
ｒ
ｉ
ｓ
間については、可能
異なるインスタンスのバックアップ・ファイルを使用してのリストアは可能
システム・カタログもリストアされるため、すでにGRANTされている権限、データベース・オブジェクトのスキーマ名に注
意
リストアによりコードページを変更することはできない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：RESTOREコマンド（V7.1)
RESTOREコマンド (詳細は、「DB2 UDB コマンド解説書をご参照ください。」
>>-RESTORE----+-DATABASE-+--source-database-alias--------------->
'-DB-------'
>-----+-| restore-options |------+----------------------------------><
+-CONTINUE------------+
'-ABORT--------------- '
restore-options
|---+---------------------------------------+------------------->
'-USER--username--+------------------+---'
'-USING--password--'
>-----+--------------------------------------------------------+>
+-TABLESPACE ONLINE----------------------------------------|-----------------------------|-------------+
|
.-,----------------.
|
'- INCREMENTAL -|-------------'|
|
V
|
|
'- AUTOMATIC-'
+-TABLESPACE--(-----tablespace-name---+---)--+---------+-+
|- ABOUT
-|
|
'-ONLINE--' |
'-HISTORY FILE--+---------+------------------------------'
'-ONLINE--'
>-----+---------------------------------------------------------+>
+-USE TSM--+-------------------------------+-------------+
|
'-OPEN--num-sessions--SESSIONS--'
|
|
.-,----------------.
|
|
V
|
|
+-FROM------+-directory-+--+------------------------------+
|
'-device----'
|
'-LOAD--shared-library--+-------------------------------+-'
'-OPEN--num-sessions--SESSIONS--'
>-----+----------------------+---+------------------+---+---------------------------+---+-------------------------+->
'-TAKEN AT--date-time--' '-TO--target-directory--'
'-INTO--target-database-alias--'
'-NEWLOGPATH--directory--'
>-----+-----------------------------+----+--------------------+------------------------+--->
'-WITH--num-buffers--BUFFERS--'
'-BUFFER--buffer-size--' '-DLREPORT--filename--'
>----+------------------+---+----------+----+-----------------+->
'-REPLACE EXISTING-' '-REDIRECT-' '-PARALLELISM--n--'
>----+-------------------------+---+-------------------+---+---------------------+------>
'-WITHOUT ROLLING FORWARD-' '-WITHOUT DATALINK-' '-WITHOUT PROMPTING-'
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 81-82 )
DB2 UDB 運用管理
DB2回復管理の基礎
バックアップとリストア方法の概要
オフライン・データベース・
バックアップのリストア
オンライン・データベース・バックアップのリストア
表スペース・
バックアップのリストア
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
IBM Japan Systems Engineering C0.,Ltd.
( 83-84 )
DB2 UDB 運用管理
DB2回復管理の基礎
オフライン・DBバックアップをRESTOREする
回復したい時点に応じて以下の２通り
オフライン・DBバックアップ取得時点の状態に戻す①+②
RESTOREコマンド+ ROLLFORWARDのSTOPオプション（ログは当てない）
オフライン・DBバックアップ取得以降の更新ログも適用する①+③+④
RESTOREコマンド+ ROLLFORWARDのEND OF LOGSオプション
ログ・パスに存在するある最終ログまでを適用
RESTOREコマンド+ ROLLFORWARDで適用するログの時間を指定（POINT IN TIME回復）
回復時点となる時間を指定する
①
RESTORE
コマンド
BACKUP
ファイル
RESTORE完了
②
ROLLFORWARD
保留
②
③
ROLLFORWAD
コマンド
STOP
ROLLFORWAD
コマンド
ログ・
ファイル
④
ROLLFORWAD
コマンド
STOP
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
オンライン・DBバックアップをRESTOREする
基本的にはオフライン・DBバックアップのRESTOREと同じ
オンライン・DBバックアップのRESTORE後は、オンライン・DBバックアッ
プ中に出力されたアーカイブ・ログ・ファイルを使用して、
ROLLFORWARDすることが必須 ②
オンライン・バックアップ中の更新処理は、ログに記録されているため、ROLLFORWARDを行
い、データの整合性を合わせる必要がある
オンライン・バックアップをRESTOREしただけでは、データベースに接続不可能
①
RESTORE
コマンド
BACKUP
ファイル
RESTORE完了
②
ROLLFORWARD
保留
②
ROLLFORWAD
コマンド
（必須） ③
ROLLFORWAD
コマンド
（任意）
ログ・
ファイル
バックアップ取得完了
時までのログ・ファイル
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 85-86 )
④
ROLLFORWAD
コマンド
STOP
DB2 UDB 運用管理
DB2回復管理の基礎
TBS（表スペース）バックアップをRESTOREする
回復したい時点に応じて以下の２通り
TBSバックアップ取得時点の状態に戻す①+②
RESTOREコマンド+ ROLLFORWARDのSTOPオプション
TBSバックアップ取得以降の更新ログも適用する①+③+④
RESTOREコマンド+ ROLLFORWARDのEND OF LOGSオプション
ログ・パスにある最終ログまでを適用
RESTOREコマンド+ ROLLFORWARDで適用するログの時間を指定（POINT IN TIME回復）
回復時点となる時間を指定する
①
RESTORE
コマンド
BACKUP
ファイル
RESTORE完了
②
ROLLFORWARD
保留
②
ROLLFORWAD
コマンド
STOP
③
ROLLFORWAD
コマンド
ログ・
ファイル
④
ROLLFORWAD
コマンド
STOP
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
TBSバックアップのRESTOREに関する考慮事項
時間指定のROLLFORWARDは、最後のDDLを越えた時点を指定する
こと
TBSバックアップは、TBSの回復にのみ使用可能
全てのTBSバックアップが存在しても、データベースの復元はできない
既存のデータベース、またはデータベース・バックアップが必要
一度DROPした後、全く同じ定義内容で表スペースを再作成しても、DROPした表スペースから
取得していたバックアップのリストアを行うことはできない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 87-88 )
DB2 UDB 運用管理
DB2回復管理の基礎
６．運用フェーズでの管理作業
１．REORG（再編成）
２．RUNSTATS（統計情報の収集）
３．コンテナ追加・コンテナ・
サイズの変更
(ALTER TABLESPACEステートメント)
ADD CONTAINER
RESIZE／EXTEND
４．コンテナの変更に関する考慮点
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
IBM Japan Systems Engineering C0.,Ltd.
( 89-90 )
DB2 UDB 運用管理
DB2回復管理の基礎
6-1. REORG（再編成）（１）
目的
表データのフラグメンテーションを解消することによる、
１．ディスク容量の削減
２．データ読み取りの処理効率向上
指定した索引順にデータを並べ替えることによる、
１．索引スキャンのパフォーマンス向上
２．順次先読みの効率向上
REORGが必要な時
SQLによる更新(DELETE/INSERT/UPDATE)でのフラグメンテーションが発生する場合
クラスター率の低下により、索引スキャン・順次先読みの効率が悪化した場合
REORGが必要ないケース
SQLによる更新処理のない、読み取りのみの表
ユニーク索引の列を条件とした１件検索の場合には、クラスター率が低くても問題なし
クラスター索引との併用
クラスター索引により索引順を維持する
ＡＬＴＥＲ ＴＡＢＬＥステートメントで、ＰＣＴＦＲＥＥに空きスペースを指定することを考慮する
ＲＥＯＲＧにより高いクラスター率を維持させる
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：6-1. REORG（１）
REROG（再編成）とは、データのフラグメンテーションをなくし、索引順にデータを並び替えることにより、データへのアクセスの処理
効率を向上し、ディスク・スペースの削減を行うためのユーティリティーです。REORGコマンド実行時に、索引名を指定した場合、そ
の索引列順にデータを並び替えます。索引名を指定しなかった場合で、かつ、クラスター索引が作成されていた場合には、クラス
ター索引の列順にデータを並び替えます。索引名を指定しなかった場合で、かつ、クラスター索引が存在しない場合には、フラグメ
ンテーションをなくすように、データが隙間無く詰められます。ただし、PCTFREEの値が設定されている場合には、１ページあたり、
PCTFREEの割合（％）が余白として残されます。
PCTFREEの値分の空きスペースが確保されるのは、ＲＥＯＲＧ，ＬＯＡＤの場合です。
REORG処理の最中は、データにアクセスすることができません。
REORG処理が何らかの理由で失敗した場合、ワーク領域として使用された、一時表スペースにあるファイルを削除しないで下さい。
REORG処理のリカバリーに使用されます。
クラスター索引とは、できる限り索引列順に、表のデータを並べて格納する機能を持つ索引です。CREATE INDEXの際にCLUSTER
オプションを指定します。
構文
>>-REORG TABLE--table-name----+--------------------+------------>
'-INDEX--index-name--'
>-----+-----------------------+--------------------------------><
'-USE--tablespace-name--'
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 91-92 )
DB2 UDB 運用管理
DB2回復管理の基礎
6-1. REORG（２）
REORGCHK
再編成が必要かどうかを検査するユーティリティー
出力のREORG列に＊が多いほど、REORGが推奨される
REORG時の一時表スペースに関する考慮点
同時にREORGする表のデータ量の１−２倍の一時表スペース領域を確保すること
領域が足りない場合には、エラーとなり、処理はロールバックされる
REORGする表の表スペースと同じページ・サイズの一時表スペースを、REORGコマンドで指
定することが必要
REORGコマンドで一時表スペースを指定しない場合には、表が格納されている表スペースを、一時表スペースとして
使用する
表のある表スペースに容量がある場合には、一時表スペースを指定せずに、同じ表スペース
上でREORGを行った方が処理効率が良く速いが、一般的には、一時表スペースを使用する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：6-1. REORG（２）
REORGCHKは、６つの数式から値を算出し、REORGの必要性を＊で、不必要性を-で、表示します。
構文
>>-REORGCHK------+------------------------------+------------------->
| .-UPDATE---.
|
'--+-CURRENT-+---STATISTICS--'
>------+----------------------------+----------------------------><
|
.-USER-------. |
'-ON TABLE--+-SYSTEM----+--'
+-ALL--------+
'-table-name---'
出力例：
Table statistics:
F1: 100*OVERFLOW/CARD < 5
F2: 100*TSIZE / ((FPAGES-1) * (TABLEPAGESIZE-76)) > 70
F3: 100*NPAGES/FPAGES > 80
CREATOR NAME
CARD OV NP FP TSIZE F1 F2 F3 REORG
------------------------------------------------------------------------------SYSIBM SYSINDEXES
57 17 3 5 9063 29 56 60 ***
SYSIBM SYSKEYCOLUSE
4 0
1 1 268 0 - 100 --SYSIBM SYSPLAN
22 0 2 2
154 0 3 100 -* Index statistics:
F4: CLUSTERRATIO or normalized CLUSTERFACTOR > 80
F5: 100*(KEYS*(ISIZE+8)+(CARD-KEYS)*4) / (NLEAF*INDEXPAGESIZE) > 50
F6: (100-PCTFREE)*(INDEXPAGESIZE-96)/(ISIZE+12)**(NLEVELS-2))*(INDEXPAGESIZE-96)/
(KEYS*(ISIZE+8)+(CARD-KEYS)*4) < 100
CREATOR NAME
CARD LEAF LVLS ISIZE KEYS F4 F5 F6 REORG
------------------------------------------------------------------------------able: SYSIBM.SYSCOLUMNS
SYSIBM IBM01
735 12
2 33
735 97 64 11 --SYSIBM IBM24
735
1
1
20
10
85 - --(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 93-94 )
DB2 UDB 運用管理
DB2回復管理の基礎
6-2. RUNSTATS（統計情報の収集）
RUNSTATSの処理内容：
統計情報を最新の状態に更新する
効果
現時点の統計情報に更新することで、最新の統計情報によるアクセス・パスが選択される
静的SQLの場合、BIND時に既にアクセス・パスが決まっており、RUNSTATS後にREBINDしない限り、アクセス・パスへ
の影響は受けない
動的SQLの場合、実行時にBINDが行われアクセス・パスが決まるので、RUNSTATS後のパフォーマンスは変化する可
能性有り
オプション：詳細な情報収集のオプションをつけた場合には、完了に時間を要する
ＡＮＤ Ｉ
ＮＤＥＸＥＳオプション：索引の統計情報を収集
DELTAILEDオプション：拡張索引統計を収集
ＷＩ
Ｔ
Ｈ ＤＩ
ＳＴＲＩ
ＢＵＴＩ
ＯＮオプション：非一様分布統計情報を収集
RUNSTATS実行中のデータへのアクセス
SHRLEVEL CHANGE：RUNSTATS実行中でも、該当表を変更可能
SHRLEVEL REFERENCE：RUNSTATS実行中は、該当表は読み取りのみ可能
RUNSTATSのタイミング
索引が作成された時
表のデータがＲＥＯＲＧされた時
表および索引のデータの１０−２０％がUPDATE/DELETE/INSERTされた時
アプリケーションをＢＩ
ＮＤする前
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：6-2. RUNSTATS（統計情報の収集）
ＲＵＮＳＴＡＴＳは、表のデータ内容が大きく変化した場合に、統計情報を最新の状態に更新するために実行します。動的ＳＱＬは、動
的にＢＩ
ＮＤを実行するため、ＲＵＮＳＴＡＴＳで統計情報を変更することによりアクセス・パスが変わる可能性があります。
構文
>-RUNSTATS ON TABLE--table-name-------------------------------->
>-----+-+--------------------------------------------------------------------+-+>
| '-WITH DISTRIBUTION--+--------------------------------------------+--' |
|
'-AND--+----------+--+-INDEXES ALL--------+--'
|
|
'-DETAILED-' '-INDEX--index-name--'
|
'-+--------------------------------------------------+-------------------'
'--+-AND-+---+----------+--+-INDEXES ALL--------+--'
'-FOR-' '-DETAILED-' '-INDEX--index-name--'
>-----+-----------------------------+-----------------------------><
|
.-CHANGE----. |
'-SHRLEVEL--+-REFERENCE-+--'
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 95-96 )
DB2 UDB 運用管理
DB2回復管理の基礎
6-3. コンテナ追加とコンテナ・サイズの変更
DMS表スペースについてのみ可能
EEE環境の場合、新規ノードにコンテナを追加するのであれば、ＳＭＳ表スペースでも可能
コンテナの追加
ADD：
コンテナの追加
例：10000ページのデバイス・コンテナを追加する
ALTER TABLESPACE TBS1
ADD （DEVICE '/dev/rhdisk9' 10000)
コンテナ・
サイズの増加
RESIZE：指定した値（ページ）にコンテナ・サイズを変更する
例：２つのデバイス・コンテナのサイズを２０００ページに変更
ALTER TABLESPACE mytbsp
RESIZE (DEVICE '/dev/rhd7' 2000, DEVICE '/dev/rhd8' 2000)
例：全てのコンテナのサイズを、２０００ページに変更
ALTER TABLESPACE yourtbsp RESIZE (ALL CONTAINERS 2000)
EXTEND：指定した値（ページ）だけ、コンテナを拡張する
例：２つのデバイス・コンテナのサイズを１０００ページ拡張
ALTER TABLESPACE mytbsp
EXTEND (DEVICE '/dev/rhd11' 1000, DEVICE '/dev/rhd12' 1000)
例：全てのコンテナ・サイズを１０００ページ拡張
ALTER TABLESPACE yourtbsp EXTEND (ALL CONTAINERS 1000)
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：6-3. コンテナ追加とコンテナ・サイズの変更
DMS表スペースの１つ、または複数のコンテナのサイズを増やすことが可能です。
ＥＥＥ環境の場合には、新規のノードでコンテナを追加するのであれば、ＳＭＳ表スペースに対しても可能です。
以下のケースのように、その区画に何もコンテナーがない場合にのみ、コンテナー追加が可能です。従って、既にコンテナが作成さ
れているノードでもう一度以下のようなコマンドを実行すると、エラーになります。
alter tablespace tbs1 add ('dir3') on node (1);
例
create nodegroup ng1 on node (0);
create tablespace tbs1 in ng1 managed by system using ('dir1');
alter nodegroup ng1 add node (1) without tablespaces;
alter tablespace tbs1 add ('dir2') on node (1);
RESIZE：
RESIZEは、既存のコンテナのサイズを変更します。ただし、値の増加のみ可能です。指定するサイズは、コンテナの新しいサイズで
す。全てのコンテナについて指定した場合、全てのコンテナのサイズが指定したサイズになります。
EXTEND
EXTENDは、既存のコンテナに追加するサイズを指定します。全てのコンテナについて指定した場合、全てのコンテナについて、指
定したサイズ分のスペースが追加されます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 97-98 )
DB2 UDB 運用管理
DB2回復管理の基礎
解説：6-3. コンテナ追加とコンテナ・サイズの変更
新規のコンテナを追加する場合と同様、表スペースの内容は、全てのコンテナに渡ってリバランスされます。リバランス実行中の表
スペースへのアクセスは制限されません。
テスト例：TESTSPACE1表スペースのサイズを変更します。
１．$ db2 "create tablespace testspace1 managed by database using (FILE '/db2data/udbv7/sample/testspace1/cont1' 120)"
２．$ db2 list tablespaces show detail
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
正常
合計ページ数
使用可能ページ数
使用したページ
空きページ
最高水準点 (ページ)
ページ・
サイズ (バイト)
エクステント・
サイズ (バイト)
プリフェッチ・サイズ (バイト)
コンテナー数
最小回復時間
=3
= TESTSPACE1
= データベース管理スペース
= 任意のデータ
= 0x0000
= 120
= 112
= 48
= 64
= 48
= 4096
= 16
= 32
=1
= 2000-06-02-01.31.46.000000
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：6-3.コンテナ追加とコンテナ・サイズの変更
３．$ db2 "alter tablespace testspace1 resize (FILE '/db2data/udbv7/sample/testspace1/cont1' 150)"
４．$ db2 list tablespaces show detail
表スペース ID
=3
名前
= TESTSPACE1
タイプ
= データベース管理スペース
内容
= 任意のデータ
状況
= 0x0000
詳しい説明:
正常
合計ページ数
= 150
使用可能ページ数
= 144
使用したページ
= 48
空きページ
= 96
最高水準点 (ページ)
= 48
ページ・
サイズ (バイト)
= 4096
エクステント・
サイズ (バイト)
= 16
プリフェッチ・サイズ (バイト)
= 32
コンテナー数
=1
最小回復時間
= 2000-06-02-01.38.35.000000
５．$db2 list history all for sample
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID
-- --- ------------------ ---- --- ------------ ------------ -------------T P 20000602103835
C
---------------------------------------------------------------------------1 個の表スペースを含みます:
00001 TESTSPACE1
---------------------------------------------------------------------------コメント: ALTER TABLESPACE
開始時刻: 20000602103835
終了時刻: 20000602103835
---------------------------------------------------------------------------00064 ロケーション:
DDL: alter tablespace testspace1 resize (FILE '/db2data/udbv7/sample/testspace1/cont1' 150)
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 99-100 )
DB2 UDB 運用管理
DB2回復管理の基礎
6-4. コンテナの変更に関する考慮点
DMS表スペースについてのみ可能
ＥＥＥ環境の場合には、新規のノードでコンテナ追加する場合にのみ、ＳＭＳ表スペースでも
可能
リバランスについて
リバランス中でも、表スペースへのアクセスは可能
リバランスの終了は、db2diag.logに出力される
リバランス中にdb2stopを行った場合、リバランスは中断され、データベースが次に活動化され
た時に、処理が続行される
コンテナ・
サイズの縮小はできない
ADD,RESIZE,EXTENDは、同一ステートメントに記述できない
複数コンテナのRESIZE/EXTENDは、１つのステートメントで実行する
リバランスが１度で済むので効率がよい
１作業単位内で、複数ALTERステートメントにより、コンテナ・サイズの変更が行われた場合に
は、エラーとなる（SQLSTATE５５０４１）
ALTERステートメントは、回復履歴ファイルに記録される
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：6-4. コンテナの変更に関する考慮点
以下の処理を行った時のdb2diag.logの出力です。（DIAGLEVEL=４）リバランスが途中から再始動されることがわかります。
テスト手順
1.alter tablespace
2.db2stop
3.db2start
4.connect to database
db2diag.logの出力
-----------------------------------------------------------------------2000-12-06-14.00.01.168859 Instance:udbv71 Node:000
PID:16120(db2rebal) Appid:none
buffer_pool_services sqlb_rebalance Probe:2204
Rebalancer for tablespace 3 started.
2000-12-06-14.00.01.865884 Instance:udbv71 Node:000
PID:16120(db2rebal) Appid:none
buffer_pool_services sqlb_rebalance Probe:2708
Rebalancer for tablespace 3 stopping. Last extent moved 117.
2000-12-06-14.00.02.061041 Instance:udbv71 Node:000
PID:19962(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.001206045957
buffer_pool_services sqlbStopPools Probe:0 Database:SAMPLE
Stopping the database. (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
IBM Japan Systems Engineering C0.,Ltd.
( 101-102 )
DB2 UDB 運用管理
DB2回復管理の基礎
解説：6-4. コンテナの変更に関する考慮点
db2diag.logの出力（続き）
2000-12-06-15.12.43.350135 Instance:udbv71 Node:000
PID:10814(db2agent (SAMPLE)) Appid:*LOCAL.udbv71.001206061242
buffer_pool_services sqlbStartPools Probe:0 Database:SAMPLE
Starting the database.
2000-12-06-15.12.43.641996 Instance:udbv71 Node:000
PID:20728(db2rebal) Appid:none
buffer_pool_services sqlb_rebalance Probe:2204
Rebalancer for tablespace 3 started. ＜＝＝リバランスが再び開始される
2000-12-06-15.12.44.924662 Instance:udbv71 Node:000
PID:20728(db2rebal) Appid:none
buffer_pool_services sqlb_rebalance Probe:2435
Rebalancer for tablespace 3 moving extent 140. Last extent to move 151.
2000-12-06-15.12.45.462010 Instance:udbv71 Node:000
PID:20728(db2rebal) Appid:none
buffer_pool_services sqlb_rebalance Probe:2876
Rebalancer for tablespace 3 completed successfully. Last extent moved 151.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
IBM Japan Systems Engineering C0.,Ltd.
( 103-104 )