3. 回復の手順 （補足資料） DB2 UDB運用管理

DB2 UDB運用管理
3. 回復の手順
3. 回復の手順
（補足資料）
お断り：当資料は、DB2 UDB V7.1（UNIX,PC)　をベースに作成されています。
(一部、Fixpackに含まれるV7.2の機能についてもふれています。）
＜第１．００版＞２００１年６月
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
3. 回復の手順（補足資料）内容
1. テープデバイスに関する質問と回答
2. バックアップ・ファイル・サイズに関する質問と回答
この補足資料は、IBM製品に対する技術的なQ&Aシステムである「Smart Answer」に入力された質問の中から
参考となるQ&Aを抜き出したものです。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
（補足） 1-2
DB2 UDB運用管理
3. 回復の手順
1. テープデバイスに関する質問と回答
Q1.
SmartLibrary
2001
テープ装置へのDB2バックアップについて
<<< QUESTION >>>
2001/03/06 11:22:58
お世話になります。
H/W：S80、テープ装置：LTO（3581）
S/W：AIX、DB2 UDBV7.1EE(7.1.0.24)
を使用しております。
データベースのサイズが大きいため（使用したテーブルスペースが70GBくらい）、LTOにバックアップしたところ、
SQL2025Nが戻されました。試したところ、LTOのBlock Sizeが0（可変長）から1024と固定長したらバックアップが
取得できました。
データベースのバックアップを取得するときはテープ装置のBlock Sizeは固定長でないとだめなのでしょうか？
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
A1.
<<< ANSWER >>>
2001/03/08 14:50:27
データベースのバックアップを行う際、バックアップイメージを保存する対象のデバイスがテープ装置の場合、
DB2がサポートするテープ装置の固定ブロックサイズは"512byte","1024byte","2048byte","4096byte"となっております。
これはバックアップイメージヘッダを4KBのブロックとして書き出す為です。
また、テープ装置のブロックサイズを可変長(ブロックサイズ = 0)にしバックアップを行う事も可能です。
但し可変長ブロックサイズを使用したバックアップを行う場合にはBACKUPコマンドで指定するBUFFER パラメータの値に
使用するテープ装置で許容される最大のブロックサイズ(3581の場合、最大16M)より小さい値を明示的に指定する必要が
あります。
上記の方法によりテープ装置のブロックサイズを可変長にした場合、BACKUPコマンドのBUFFERパラメータの値を指定し
バックアップの実行をお試し下さい。
Copyright 2001, IBM Japan Systems Engineering Co.,Ltd.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
（補足） 3-4
DB2 UDB運用管理
3. 回復の手順
1. テープデバイスに関する質問と回答
Q2.
SmartLibrary
2001
UDB7.1 テープにデータベースのバックアップをとりましたがリストアすることができません
<<< QUESTION >>>
01/02/15 12:31:30
環境
DB2UDB7.1 WE FIXなし
WindowsNT4.0 SP6a
xSeries 200
テープ装置 型NS 09N4042NS10-20G SICIテープ駆動機構
状況
・テープにデータベースのバックアップをとり、同一マシン上の既存のデータベースにリストアすることができません。また、
別の名前でリストアを行った場合にも同じ状況です。
・WindowsNTのバックアップは問題なくでき、復元も可能です。
・テープ装置を使わず、ハードディスクを使用した場合にはバックアップ、リストアができました。
backup database sample to \\.\tape0
「バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは20010213120427です」
restore database sample from \\.\tape0
「SQL2530N バックアップ・イメージが壊れています。このバックアップ・イメージからのデータベースの復元は不可能です。」
質問
こちらの環境でもお客様の環境でもこのような現象が起きています。テープ装置をデータベースのバックアップとして使用した
場合に、このような現象は起こりうるのでしょうか。何か原因として考えられることがありますか。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
A2.
<<< ANSWER >>>
2001/02/16 16:17:34
こちらでWindows NT/EXABYTE 8505テープ装置を使用して、ご指摘の手順でデータベースのバックアップ・リストアを
行いましたが、正常終了しました。
したがって、ご指摘の問題はテープ装置に依存する問題ではないか、と考えます。
「管理の手引き」－「第19章 データベースの回復」－「データベースのバックアップ」には、「バックアップ時の
テープ使用の計画」として次のような記述があります。
表スペースまたはデータベースのバックアップをとる場合、ブロック・サイズおよびバッファー・サイズを正しく
設定しなければなりません。これは、特に可変長のブロック・サイズを使用する場合 (たとえば、 AIX でブロック
・サイズがゼロに設定されている場合など) に当てはまります。
（略）
ブロック・サイズが可変長の場合、バックアップ・イメージからの復元でエラーが戻される場合があるので、注意して
ください。エラーが戻された場合、適当なブロック・サイズを使用してイメージを再書き込みしなければならない場合
があります。
ご指摘の問題がブロック・サイズの問題かどうかはわかりませんが、「管理の手引き」の記述をご参照の上、
BACKUP DATABASEコマンドおよびRESTORE DATABASEコマンドのBUFFERオプションを適切な値に指定してお試しください。
<<< COMMENT >>>
2001/02/21 13:41:29
以下のようにブロックサイズ、バッファーサイズを指定したところうまく動作しました。
initialize tape using 4096
backup database sample to \\.\tape0 buffer 16
リストアする際にも
restore database sample from \\.\tape0 buffer 16
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
（補足） 5-6
DB2 UDB運用管理
3. 回復の手順
1. テープデバイスに関する質問と回答
Q3.
SmartLibrary
2001
SQL2061Nでテープにバックアップできない
<<< QUESTION >>>
01/01/12 21:03:11
DB2 UDB WE V7.1 for Linuxを使用しています。
BACKUP DATABASEでテープ装置を指定すると、SQL2061Nでバックアップができません。
SQL2061N An Attempt to Access Media /dev/st0 is denyed.
SQL2061Nのエラーの意味はデバイスに対して許可されていないため発生するエラーのようですが、
tarコマンドでTAPEに書き込むことは可能です。
何か考えられることはありますか。
環境
DB2 UDB WE V7.1
Redhat V6.2
テープ：DDS-4（DAT）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
A3.
<<< ANSWER >>>
2001/01/14 23:51:34
Linux のほとんどのバージョンでは、SCSI テープ装置でbackupやrestoreを行うときに、
DB2の省略時のバッファー・サイズを使用すると、SQL2025Nが表示されます。 Linux内部 SCSIバッファーが
オーバーフローするからです。
これを防ぐには、以下の式を使用してください。
bufferpages <= ST_MAX_BUFFERS * ST_BUFFER_BLOCKS / 4
ここでbufferpages は、backbufszまたはrestbufszのいずれかか、backupコマンドまたはrestoreコマンドの
bufferの値です。
またST_MAX_BUFFERS および ST_BUFFER_BLOCKS は、 drivers/scsiディレクトリーの下で、Linux カーネルに
定義されています。
<<< COMMENT >>>
2001/01/19 11:43:30
ご指摘のように、BACKBUFSZを変更したところ、BACKUPが成功しました。
Copyright 2001, IBM Japan Systems Engineering Co.,Ltd.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
（補足） 7-8
DB2 UDB運用管理
3. 回復の手順
1. テープデバイスに関する質問と回答
Q4.
SmartLibrary
2001
4mmテープ装置からのDBリストア
<<< QUESTION >>>
2001/01/19 22:00:37
4mmテープ装置へのDBバックアップ、テープ装置からのDBリストアは以下のコマンドにより可能ですが、
# db2 backup db DB名 to /dev/rmt0
# db2 restore db DB 名 from /dev/rmt0
これを、4mmテープ装置から直接リストアするのではなく、一度ディスクにバックアップイメージを取得することは
可能でしょうか？
TSMを介在させた場合には可能であるようですが、tar、ddコマンド等を使用して実現できないものかと考えております。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
A4.
<<< ANSWER >>>
2001/01/22 17:52:14
ご指摘のコマンドで、テープ装置にBACKUP取得/テープ装置からBACKUPをRESTORE することは可能です。
DB2のBACKUPコマンドでテープにBACKUPを取得し、そのテープからバックアップ・イメージをファイルとして
tarまたはddでディスクに落とすことができるか、というご質問ですね。
以下の手順でRESTOREのテストを行いましたが、問題なく使用可能でした。
１．BKUPをテープへ取得
db2 "backup database dbname to /dev/rmt0 without prompting "
２．テープ内容をｄｄでディスクにコピー
dd if=/dev/rmt0 of=bkupfile ibs=1024 obs=512
(ibsはテープ装置のBACKUP時のBLOCKサイズ、obsは、ディスクのBLOCKサイズ）
３．コピーしたファイルの名前をバックアップ・ファイル名に変更
mv bkupfile SAMPLE.0.udbv61.NODE0000.CATN0000.20010122165259.001
４．db2 "restore database sample from /temp taken at 20010122165259 to sample "
５．db2 connect to sample
このように、リストア対象のファイル名を正しく変更すれば、問題なくリストアすることが可能です。
Copyright 2001, IBM Japan Systems Engineering Co.,Ltd.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
（補足） 9-10
DB2 UDB運用管理
3. 回復の手順
2. バックアップ・ファイル・サイズに関する質問と回答
Q1.
SmartLibrary
2000
バックアップイメージの圧縮率
<<< QUESTION >>>
2000/07/10 8:34:43 PM
DB2 for AIX V4.1で復元回復やロールフォワード回復のため、バックアップイメージを取得する際、
そのバックアップイメージは実際のデータを単にコピーしたものなのでしょうか。それとも圧縮したもの
なのでしょうか。
もし圧縮したものである場合、圧縮率が決まっているのであれば教えて下さい。
またDB2 for AIX V4.1では扱えるファイルサイズの上限が2GBとなっておりますが、バックアップイメージの
サイズが2GBを超えた場合でも何らかの方法で取得する必要があります。何か良い代替手段があれば教えて下さい。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
A1.
<<< ANSWER >>>
2000/07/11 13:42:18
DB2はバックアップ・イメージを圧縮しません。
バックアップ・イメージのサイズが２GBを越える場合、以下の方法により取得可能です。
-バックアップ先のメディアとしてテープを使用する
-BACKUPコマンドのバックアップ先のディレクトリーを複数指定する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
（補足） 11-12
DB2 UDB運用管理
3. 回復の手順
2. バックアップ・ファイル・サイズに関する質問と回答
Q2.
SmartLibrary
2001
DBバックアップについて
<<< QUESTION >>>
2001/02/27 20:41:59
現在バックアップの運用についてお客様と検討しています。
環境
UDBV5.2（Fixpack10）
AIX4.3.2
以下についてお教えください。
Ｑ１．バックアップ前の大きさ40GB（テーブルスペース使用率50％）の場合に、backup databaseコマンドにて
ファイルイメージにすると、どれぐらいの大きさになるのでしょうか。（目安で結構です）
Ｑ２．バックアップ前の大きさ40GB（テーブルスペース使用率50％）の場合に、backup databaseコマンドにて
Tape Diveに取得する場合、マルチボリューム（複数Tapeにまたがる）はサポートしていますか。
Ｑ３．バックアップ前の大きさ40GB（テーブルスペース使用率50％）の場合に、backup databaseコマンドにて
ファイルイメージにする場合にファイルを分割してイメージを分けることは可能ですか。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
A2.
<<< ANSWER >>>
2001/03/02 18:54:31
A1.
バックアップファイルサイズの大きさに関しては、残念ながら公開されている見積もり式はありません。
こちらでテストを行ったところ、大雑把な見積もりとしては、表スペースの「使用したページ」の大きさから
見積もることができると思われますが、個々のケースで異なる部分も大きいと考えられるため、ご使用の環境で
ご確認ください。
また、データをDELETEしてもページはアロケートされたままであるため、バックアップファイルのサイズは小さく
ならないことにご注意ください。
A2.
BACKUP DATABASE コマンドでは、複数のテープにまたがってバックアップイメージを取得することが可能です。
一つ目のテープがいっぱいになると、SQL2059Wのメッセージが出力され、ユーザーから「テープを入れ替えて
続行(c)/この装置のみ終了(d)/バックアップ処理の終了(t)」のいずれかの入力を待ちます。
二つ目以降のテープにおいても同様です。
A3.
BACKUP DATABASE コマンドでは、TOの後に複数のターゲット・ディレクトリ（または装置）を指定することにより、
複数のあて先を指定してバックアップイメージを取得することができます。
この場合、1番目に指定されたターゲット・ディレクトリ（または装置）にヘッダー、構成ファイル、回復履歴
ファイルなどが格納され、その他のデータは指定された複数のディレクトリで均等にラウンド・ロビン方式で
格納されます。
もし、ある一つのターゲット・ディレクトリ（または装置）がいっぱいになると、A2.で述べたようにSQL2059Wの
エラーが出力され、ユーザーからの応答を待ちます。
BACKUP DATABASE コマンドの詳細については、「コマンド解説書」をご覧下さい。
Copyright 2001, IBM Japan Systems Engineering Co.,Ltd.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
（補足） 13-14
DB2 UDB運用管理
3. 回復の手順
2. バックアップ・ファイル・サイズに関する質問と回答
Q3.
SmartLibrary
2000
BACKUP時間の見積り方法について
<<< QUESTION >>>
2000/03/06 9:40:23
DBのBACKUP後のファイルのサイズがもとのＤＢサイズに比べてかなり増加してるのですが、
BACKUP時間を見積る場合、どちらの大きさで見積るべきでしょうか。
また、なぜ大きさがこれほど増加するのでしょうか。制御情報等が付加されるためでしょか。
通常、BACKUP時間の見積りは、DBの大きさとテープの転送速度等より見積ると思うのですが、
DBの大きさではなく、BACKUPファイルの大きさを使用するべきなのでしょうか。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
A3.
<<< ANSWER >>>
2000/03/06 (月) 10:29:58
”もとのデータベース・サイズに比べてバックアップ・ファイルが増加している”ということですが、
バックアップ・バッファーのサイズにより、バックアップ・ファイルのサイズは変化します。より小さい
バッファー・サイズを選択することにより、バックアップ・ファイルが元のデータベース・サイズに近くなります。
反対に、より大きいバッファー・サイズを選択することにより、バックアップ・ファイルが元のデータベース・
サイズより大きくなります。
つまり、バッファー・サイズにより出力ファイルの大きさが異なり、それによりＢＡＫＣＵＰの処理速度も
異なります。
バックアップ時間を見積もる場合ですが、以下のどれかを指標にして算出して下さい。
-データベース・サイズ　-データ量（フラット・ファイルの量）
-バックアップ・ファイル・サイズ
考慮点：バックアップ・ファイルのサイズはバックアップ・バッファーにより異なります。従って、指定する
バッファーから、バックアップ・ファイルサイズをある程度予測する必要があります。ただし、
算出式はありません。
なお、バッファー・サイズは、２５６バイトが最もパフォーマンスが良く、かつ元のデータ量に近いバックアップ・
サイズになっていますので、２５６を使用されることをお薦めいたします。
バックアップ・ファイルのサイズは算出式がないため、厳密には、取得してみなければ大きさがわからないという
ところがやっかいですが、２５６であればかなりデータ量に近似になります。
Copyright 2000, IBM Japan Systems Engineering Co.,Ltd.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
（補足） 15-16