前回（DB2のインストール ）新しくDB2をインストールしましたので、早速バックアップとリカバリコマンドを使ってみたいと思います。

まずは現状の確認を。データベース全体を見ていくと大変なので、"staff"テーブルを対象としていきます。

テーブルの設計については"DESCRIBE TABLE table_name"で確認することができます。


中身については全件選択してみましょう。"SELECT * FROM STAFF"
35レコードあります。


では、データベースのバックアップです。"BACKUP DATABASE SAMPLE TO backup_directory"


バックアップファイルはコマンドに指定したフォルダーに作成されます。


今回は下記のファイル名で作成されました。
"SAMPLE.0.DB2.NODE0000.CATN0000.20090923183402.001"

ファイル名の意味は下記の通りになります。
Alias.Type.Instance.Node.Catalogue.YYYYMMDDHHMMSS.Sequence
<IBM Developer Worksの「IBM DB2 UDBとOracleのバックアップおよびリカバリーの比較: 第 1 回」を参照>

それでは、どきどきしながらも、サクッとテーブルを消します。
"DROP TABLE STAFF"


ちゃんと消えてます。


消えました・・・

でも、バックアップをとっているので安心です。すかさずテーブルを復旧してみましょう。

"RECOVERY DATABASE SAMPLE TO END OF LOGS"


SQLエラーが出たのでInformation Centerを見てみた。
「
SQL1260N

データベース name は、ノード node-list でのロールフォワード・リカバリー用に構成されていません。

説明
指定されたデータベースは指定されたノードで、ロールフォワード・リカバリー用に構成されません。 ",..." がノード・リストの終わりに表示されている場合、ノードの完全なリストを見るには管理通知ログを調べてください。

データベースは指定のノードでロールフォワードされません。

(注: パーティション・データベース・サーバーを使用している場合、 ノード番号は、エラーの発生しているノードを示しています。 そうでない場合、これは関係のないものなので無視してください。)

ユーザーの処置
指定ノードでリカバリーが必要か確認して、 次にこのノードでデータベースの最新のバックアップ・バージョンをリストアしてください。
」

RECOVERYコマンドは"RESTORE DATABASE + ROLLFORWARD"なので、ROLLFORWARDしてくれようとしたんだと思います。次回確認しようと思います。

テーブルとデータは以前の通りに戻っているでしょうか？



戻っていますね。よかった。

BACKUPコマンドは、バックアップした場所の物理的な場所を覚えているため、RECOVERYコマンドを実行するときにバックアップファイルを指定する必要がありません。
ただ、バックアップファイルを移動したりしてコマンドを実行したときと違う場所に移動した場合にはRECOVERYコマンドが失敗します。


Information Centerを見てみた。
「
SQL2542N

指定されたソース・データベースの別名 database-alias とタイム・スタンプ timestamp に一致する、データベース・イメージ・ファイルがありません。

説明
バックアップ・イメージ・ファイルのファイル名は、データベース別名とタイム・スタンプのコンポーネントで構成されています。ファイル名は、ソース・データベース別名と、Database Restore 呼び出しに指定されたタイム・スタンプ・パラメーターから作成されます。 指定されたソース・データベースの別名とタイム・スタンプに一致する ファイル名が、ソース・ディレクトリーに存在しません。
以下の状態が適用される可能性があります。
１．バックアップへのパスがリストア・コマンドで誤って指定された。
２．バックアップ・イメージ、またはバックアップ・イメージがあるディレクトリーにアクセスする許可がない。
３．自動増分リストア操作を実行しており、データベース履歴内のタイム・スタンプとロケーションに基づいて必要イメージが見つからなかった。
４．パーティション・データベース環境でデータベースをリストアしており、そのデータベースがもう存在せず、さらにリストアされる最初のデータベース・パーティションがカタログ・パーティションではない。
５．TSM メディアからリストアしようとしており、現在のインスタンスにより使用される TSM API クライアント構成はバックアップ・イメージにアクセスできない。

ユーザーの処置
上記の状態に対する適切な応答は以下のとおりです。
１．データベース・バックアップ・イメージが、メディア・ソースに 存在することを確認してください。 結果的に一致するバックアップ・イメージへの正しいパスおよび正しいタイム・スタンプを指定して、操作を 再サブミットしてください。 リストア・コマンドの使用についての詳細は、DB2 インフォメーション・センターで、"using restore database utility" などの語句を使用して検索してください。
２．バックアップ・イメージ、およびバックアップ・イメージがあるディレクトリーにアクセスする許可があることを確認してください。
３．データベース履歴を調べて対応するバックアップ項目を確かめてから、 リストされているロケーションがバックアップ・イメージの実際のロケーションに一致することを確認してください。 データベース履歴を更新して、結果が一致するように操作をやり直すか、 または RESTORE INCREMENTAL ABORT コマンドを発行して、処理中に作成されたリソースをすべてクリーンアップしてください。
４．パーティション・データベースをリストアするときには、常にカタログ・パーティションを最初にリストアしてください。パーティション・データベース環境でのリストアについての詳細は、DB2 インフォメーション・センターで、"restore utility partitioned database" などの語句を使用して検索してください。
５．イメージを TSM から取得できるかを検査するには、db2adutl ユーティリティーに QUERY オプションを付けて使用します。別のサーバー上の別のインスタンスから取得したバックアップ・イメージをリストアする場合、オプション NODENAME、OWNER を必ず使用してください。またオプションで、バックアップ・イメージが最初にとられた TSM ノードの TSM 設定に対応する PASSWORD を使用してください。イメージを取得できることの確認が完了すると、同じオプションを RESTORE コマンドのオプション・ストリングに渡すことができます。db2adutl ユーティリティーについての詳細は、DB2 インフォメーション・センターで、"db2adutl" などの語句を使用して検索してください。
」

フォルダーへの定期バックアップであればバックアップファイルが見あたらないと言うことはないのでしょうが、テープから戻す場合には出やすいのかもしれませんね。
ログファイル・ヒストリーファイルを指定する項目があるので指定間違いの際にも出るでしょう。ログファイル・ヒストリーファイルをいじったパターンも試してみることにします。