管理の手引き


回復方式: バージョン回復

バージョン回復は、BACKUP コマンドとともに RESTORE コマンドを使用します。 復元回復を実行すると、データベースは前回保管されたときの状態になります。 この回復方式は、回復不能データベース (つまり、 管理者がアーカイブ・ログを持っていないデータベース) に使用します。 WITHOUT ROLLING FORWARD オプションを使用して、 回復可能データベースでこの方式を使用することもできます。

この節では、計画についての考慮事項、 および特定のユーティリティーまたはコマンドを呼び出して回復方式を実行する方法について説明します。 その後、この方式を効率的に使用するための概念や、その他の関連事項を示します。

この部分では、次の点について説明します。

データベースのバックアップ

データベースのバックアップ・コピーを作成するためには、 BACKUP コマンドまたはコントロール・センターを使用します。 コントロール・センターでは、バックアップをとるデータベースを選択した後、 バックアップ・アクションを選択します。

図 53. データベース・イメージの作成


SQLD0BKP

区分データベース・システムでは、 BACKUP DATABASE コマンドを使用してデータベース区画を個別にバックアップします。 この操作は、コマンドを出すデータベース区画サーバーでローカルに行われます。 しかし、インスタンスのいずれかのデータベース区画サーバーから db2_all を出すことで、 サーバーのリスト (ノード番号で識別) について BACKUP コマンドを実行依頼することができます。 これを実行する場合は、最初にカタログ・ノードのバックアップをとり、次に、 他のデータベース区画のバックアップをとる必要があります。 また、コントロール・センターを使用してデータベース区画をバックアップすることもできます。

区分データベース・システムでは、LIST NODES コマンドを使用して、 ユーザー表が存在するノード (データベース区画) のリストを決定することができます。 この回復方式はロールフォワード回復をサポートしていないため、 このノード・リストについてデータベースを定期的にバックアップします。

分散要求システムでは、BACKUP および RESTORE コマンドは、 当該データベース・カタログに保管されている分散要求データベースおよびメタデータ (ラッパー、 サーバー、ニックネームなど) に適用されます。 データ・ソース・オプジェクト (表および視点) は、 これらのオブジェクトが分散要求データベースに保管されていないかぎり、 バックアップまたは復元されません。

使用する回復方式を念頭に置いて作業を行う必要があります。 次の部分では、この作業に適用される要件その他の考慮事項について扱います。

注:以下の節で "ページ"について言及する場合、 それはバックアップおよび復元ユーティリティーに特有のページを指して用いられています。 これらのページのサイズは必ず 4 KB です。 データベース・データで許可されている複数ページ・サイズと混同しないようにしてください。

BACKUP コマンド使用の計画

計画考慮事項には、以下のことを含めてください。

DATALINK 列を含む表がある場合、バックアップ・ユーティリティーについての考慮事項も参照してください。

磁気テープ装置を使用するには、 UnixWare 7 上の DB2 ユーザーは BUFFER を 16 に指定しなければなりません。 BUFFER のデフォルト値は、1024ページです。 BUFFER がゼロに設定されている場合には、 データベース・マネージャー構成パラメーター backbufsz は 16 に設定されていなければなりません。

バックアップ時のテープ使用の計画

表スペースまたはデータベースのバックアップをとる場合、 ブロック・サイズおよびバッファー・サイズを正しく設定しなければなりません。 これは、 特に可変長のブロック・サイズを使用する場合 (たとえば、 AIX でブロック・サイズがゼロに設定されている場合など) に当てはまります。

バックアップ時に使用できる FIXED ブロック・サイズ数には制限があります。 このような制限があるのは、 バックアップ・イメージ・ヘッダーを 4 KB ブロックとして書き出すためです。 DB2 がサポートしている固定ブロック・サイズは 512、1024、2048、 および 4096 バイトです。 固定ブロック・サイズを使用する場合、 バックアップ用には任意のバッファー・サイズを指定できます。 ただし、 固定ブロック・サイズが上記のサイズのいずれかでない場合、 バックアップが正常に完了しない場合があります。

データベース・データが巨大な場合、 上記の固定ブロック・サイズを使用すると、 バックアップに時間がかかります。 可変長ブロック・サイズを使用することもできます。

可変長ブロック・サイズを使用する場合、 BACKUP コマンドで指定するバッファー・サイズを、 使用するテープ装置で許容される上限のサイズ以下にしなければなりません。 パフォーマンスを最大にするには、 バッファー・サイズを、 使用する装置のブロック・サイズの上限に等しくしなければなりません。

ブロック・サイズが可変長の場合、 バックアップ・イメージからの復元でエラーが戻される場合があるので、 注意してください。 エラーが戻された場合、 適当なブロック・サイズを使用してイメージを再書き込みしなければならない場合があります。 AIX の場合のこの作業の例を以下に示します。

   tcl -b 0 -Bn -f /dev/rmt0 read > backup_filename.file
   dd if=backup_filename.file of=/dev/rmt0/ obs=4096 conv=sync

これにより、 "backup_filenam.file" というファイルにバックアップ・イメージのダンプが取られます。 次に、"dd" コマンドにより、 ブロック・サイズ 4096 を使用して、イメージのダンプが再びテープに取られます。

イメージが大き過ぎてファイルにダンプを取ることができない場合、 この方法で修正するのは困難です。 そのような巨大なイメージの場合に取ることのできる解決方法の 1 つは、 "dd" コマンドを使用して、 テープ装置から別のテープ装置にダンプを行うことです。 ただし、イメージが複数のテープにまたがっている場合、この方法は使用できません。 2 つのテープ装置を使用する場合、 以下の "dd" コマンドを使用します。

   dd if=/dev/rmt1 of=/dev/rmt0 obs=4096

2 つのテープ装置を使用することができない場合、 "dd" コマンドを使用して生装置にイメージのダンプを行ってから、 その生装置からテープにそのイメージのダンプを行うことができます。 この方法の難点は、 生装置にダンプが行われたブロックの数を、 "dd" コマンドが必ず把握していなければならない点です。 ダンプが行われたブロックの数を、 イメージをテープに戻すときに指定しなければなりません。 "dd" コマンドを使用して生装置からテープにイメージのダンプを行う場合、 このコマンドは生装置の全体のサイズのダンプをテープに取ります。 "dd" コマンドでは、 イメージを保持するのに使用される生装置のサイズを指定することはできません。

BACKUP コマンドを使用する場合、 使用するテープ装置のブロック・サイズの上限を知っていなければなりません。 以下は、その例です。
装置 接続 ブロック・サイズの上限 DB2 バッファー・サイズの上限 (4 KB ページ単位)
8 mm scsi 131 072 32
3420 s370 65 536 16
3480 s370 65 536 16
3490 s370 65 536 16
3490E s370 65 536 16
7332 (4 mm)* scsi 262 144 64
3490e scsi 262 144 64
3590** scsi 2 097 152 512
3570 (Magstar MP) 262 144 64

注:

  1. * 7332 では、ブロック・サイズの上限が設定されていません。 256 KB は単なる推奨値です。 ブロック・サイズの上限は親アダプターによって決まります。

  2. ** 3590 は 2 MB のブロック・サイズをサポートしていますが、 必要とされるパフォーマンスに応じて、 それよりも小さい値 (256 KB など) を使用してみることもできます。

  3. 装置の上限については、その装置の資料を参照するか、 またはその装置のベンダーに問い合わせて (あるいはその両方を行って) ください。

BACKUP コマンドの呼び出し

以下の考慮事項は、BACKUP コマンドの実行時に役立ちます。

BACKUP によって作成されるバックアップ・イメージ

バックアップ・イメージは、 BACKUP コマンドを呼び出すときに指定したバックアップ先に作成されます。

データベース全体をバックアップまたは復元すると、 回復活動記録ファイルが要約情報によって自動的に更新されます。 このファイルは、データベース内の復元のアクティビティーを記録する機能として便利です。 このファイルは、データベース構成ファイルと同じディレクトリーに作成されます。 回復活動記録ファイルについては、回復活動記録ファイルの情報を参照してください。

UNIX ベースの環境では、ディスクに作成されるファイル名は、 以下の情報をピリオドで区切って連結したもので構成されます。 他のプラットフォームでは、4 レベルから構成されるサブディレクトリー・ツリーが使用されます。

データベース別名
バックアップ・コマンドの呼び出し時に指定した 1〜8 文字のデータベース別名。

タイプ
作成されたバックアップのタイプで、"0" であればデータベース全体。 "3" であれば、表スペース・バックアップ。 "4" であれば、 LOAD...COPY TO コマンドで生成されたバックアップ。

インスタンス名
DB2INSTANCE 環境変数からとられる データベース・マネージャーの 1〜8 文字の現行インスタンス名。

ノード番号
ノード番号。

カタログ・ノード番号
データベースのカタログ・ノードのノード番号。

タイム・スタンプ
バックアップが実行された日付と時刻を 14 文字で表記したもの。 タイム・スタンプは yyyymmddhhnnss という形式です。 ただし、
yyyy は年 (1995 〜 9999)
mm は月 (01 〜 12)
dd は日 (01 〜 31)
hh は時 (00 〜 23)
nn は分 (00 〜 59)
ss は秒 (00 〜 59)

順序番号
ファイル拡張子として使用する 3 桁の順序番号。

UNIX ベースのオペレーティング・システムでは、形式は次のようになります。

Database alias.Type.Instance name.NODEnnnn
.CATNnnnn.timestamp.number

他のオペレーティング・システムでは、形式は次のようになります。

Database alias.Type\Instance name.NODEnnn
\CATNnnn\yyyymmdd\hhmmss.number

たとえば、UNIX ベースの環境では、 DB201 インスタンスの STAFF という名前のデータベースはディスク上の次の名前のファイルにバックアップできます。

STAFF.0.DB201.NODE0000.CATN0000.19950922120112.001

テープに出力する場合、ファイル名は作成されません。しかし、後で検査するために、 上記の情報がバックアップ・ヘッダーに保管されます。

注:

  1. データベース・バックアップおよび復元操作にテープ媒体を使用したい場合は、 テープ装置が標準オペレーティング・システム・インターフェースを介して使用可能でなければなりません。 しかし、大規模な区分データベース・システムでは、 テープ装置を各データベース区画サーバーに専用接続することは実際的でないことがあります。 この場合は、複数のテープ装置を 1 つまたは複数の TSM サーバーに接続することができます。 これは、これらのテープ装置に対するアクセスを、 各データベース区画サーバーから可能にするためです。

  2. 区分データベース・システムでは、REELlibrarian 4.2 または CLIO/S などの仮想テープ装置機能を提供している製品を使用することもできます。 これらの製品を使用し、疑似テープ装置を介して他のノード (データベース区画サーバー) に接続されているテープ装置にアクセスすることができます。 リモート・テープ装置へのアクセスはユーザーが意識せずに実行され、 標準オペレーティング・システム・インターフェースを介して疑似テープ装置にアクセスできます。

バックアップ情報の表示

既存のバックアップ・イメージに関する情報を表示するための、 バックアップ・ユーティリティーがあります。 このユーティリティーは db2ckbkp といい、 これを使用することにより、以下を行うことができます。

このユーティリティーを使用する場合、 指定するバックアップ・イメージに関する読み取り許可が必要です。

単にバックアップ・イメージが存在するかどうか検査する場合、 以下のようにユーティリティーを使用することができます。

   db2ckbkp STAFF.0.DB201.NODE0000.CATNOOOO.19950922120112.001

このユーティリティーからの出力例を以下に示します。

   [1] Buffers processed:  ##
 
   Image Verification Complete - successful.

このユーティリティーの詳細については、 コマンド解説書 を参照してください。

データベースの復元

次の部分では、RESTORE コマンドに適用される要件その他の考慮事項について扱います。

図 54. バックアップ・イメージを使用してのデータベースの復元


SQLD0RSD

RESTORE コマンド使用の計画

次の点を考慮してください。

DATALINK 列を含む表がある場合、 復元およびロールフォワードについての考慮事項 および ロールフォワードせずにデータベースをオフライン・バックアップから復元する の両方を参照してください。

RESTORE コマンドの呼び出し

以下の考慮事項は、RESTORE コマンドの実行時に役立ちます。

RESTORE 実行時の表スペース・コンテナーの再定義

データベースのバックアップ時に、バックアップされる表スペースが使用しているすべての表スペース・コンテナーについて記録がとられます。 RESTORE 実行時に、バックアップ中にリストされているすべてのコンテナーの検査が行われ、 現在存在していてアクセス可能かどうかが調べられます。 媒体障害 (あるいは他の理由) により 1 つまたは複数のコンテナーがアクセスできない場合は、 RESTORE は失敗します。 このような場合でも復元できるようにするために、RESTORE 実行時に表スペース・コンテナーをリダイレクトすることがサポートされています。 表スペース・コンテナーの追加、変更、除去がサポートされています。

バックアップ中にリストされているコンテナーがシステムにない場合でも、 復元したい場合があります。 たとえば、バックアップを取ってあるシステム以外のシステムで 災害時回復を行いたい場合などが該当します。 新規のシステムでは、必須コンテナーが定義されていない可能性があります。 このような場合でも RESTORE を実行できるようにするために、 代替コンテナーの RESTORE 時に表スペース・コンテナーを リダイレクトすることがサポートされています。

どちらの場合も、この種類の RESTORE は一般的にリダイレクト回復と呼ばれます。

表スペース・コンテナーは、 コントロール・センターから復元作業を実行することで再定義できます。 また、RESTORE コマンドの REDIRECT パラメーターを使用し、 リダイレクトを指定することもできます。 コントロール・センターを使用する場合は、 「データベース復元 (Restore Database)」ノートブックの 「コンテナー (Containers)」ページを使用してリダイレクト回復を実行することもできます。 このページには、新しいコンテナーを追加したり、既存コンテナーのパスを変更したり、 コンテナーを削除したりする機能が用意されています。 データベース復元操作時に無効なコンテナー・パスが検出されると、 コントロール・センターはそのコンテナー・パスを変更するか、 またはコンテナーを削除するように指示します。

注:

  1. ディレクトリー・コンテナーおよびファイル・コンテナーは、 存在していなければ自動的に作成されます。 これらのコンテナーが何らかの理由でアクセス不能な場合に限り、 宛先変更が必要になります。 データベース・マネージャーは、装置コンテナーを自動的には作成しません。

  2. RESTORE 実行時にコンテナーの宛先変更を実行できることにより、 表スペース・コンテナーを管理するうえで非常に柔軟な対応ができます。 たとえば、コンテナーを SMS 表スペースに追加することは直接にはサポートされていませんが、 リダイレクト回復時に追加コンテナーを指定するだけでこのことを行えます。 同様に、DMS 表スペースをファイル・コンテナーから装置コンテナーに移動することもできます。

  3. リダイレクト回復は多くの API でもサポートされています。 特定の場合にリダイレクト回復を実行するようにプログラムを作成することもできますが、 これらの API は基本的には汎用ユーティリティーを作成しようとしている開発者を想定しています。

既存データベースへの復元

データベース全体のバックアップ・コピーを、既存のデータベースに復元することもできます。 既存のデータベースに復元するには、SYSADM、SYSCTRL、 または SYSMAINT 権限が必要です。 バックアップ・イメージの別名、データベース名、またはデータベース・シードは、 既存のデータベースとは異なる場合があります。

データベース・シードとは、データベースの持続期間中ずっと固定されている、 そのデータベース固有の識別子のことです。 このシードは、データベースの初回作成時にデータベース・マネージャーによって割り当てられます。 バックアップが異なったデータベース・シードを持っている場合でも、 シードはバックアップの復元後も変わりません。 DB2 は、常にバックアップからのシードを使用します。

既存データベースに復元する場合は、復元タスクにより以下の機能が実行されます。

新規データベースへの復元

データベースを既存のデータベースに復元する代わりに、 新規のデータベースを作成して、データのバックアップを復元することもできます。 新規のデータベースに復元するには、SYSADM または SYSCTRL 権限が必要です。
注:バックアップとターゲット・データベースのコード・ページは一致していなければなりません。 一致していない場合は、正しいコード・ページを指定している新規データベースを作成した後、 復元してください。

新規のデータベースに復元すると、RESTORE コマンドにより以下の機能が実行されます。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]