バージョン回復は、BACKUP コマンドとともに RESTORE コマンドを使用します。 復元回復を実行すると、データベースは前回保管されたときの状態になります。 この回復方式は、回復不能データベース (つまり、 管理者がアーカイブ・ログを持っていないデータベース) に使用します。 WITHOUT ROLLING FORWARD オプションを使用して、 回復可能データベースでこの方式を使用することもできます。
この節では、計画についての考慮事項、 および特定のユーティリティーまたはコマンドを呼び出して回復方式を実行する方法について説明します。 その後、この方式を効率的に使用するための概念や、その他の関連事項を示します。
この部分では、次の点について説明します。
データベースのバックアップ・コピーを作成するためには、 BACKUP コマンドまたはコントロール・センターを使用します。 コントロール・センターでは、バックアップをとるデータベースを選択した後、 バックアップ・アクションを選択します。
![]() |
区分データベース・システムでは、 BACKUP DATABASE コマンドを使用してデータベース区画を個別にバックアップします。 この操作は、コマンドを出すデータベース区画サーバーでローカルに行われます。 しかし、インスタンスのいずれかのデータベース区画サーバーから db2_all を出すことで、 サーバーのリスト (ノード番号で識別) について BACKUP コマンドを実行依頼することができます。 これを実行する場合は、最初にカタログ・ノードのバックアップをとり、次に、 他のデータベース区画のバックアップをとる必要があります。 また、コントロール・センターを使用してデータベース区画をバックアップすることもできます。
区分データベース・システムでは、LIST NODES コマンドを使用して、 ユーザー表が存在するノード (データベース区画) のリストを決定することができます。 この回復方式はロールフォワード回復をサポートしていないため、 このノード・リストについてデータベースを定期的にバックアップします。
分散要求システムでは、BACKUP および RESTORE コマンドは、 当該データベース・カタログに保管されている分散要求データベースおよびメタデータ (ラッパー、 サーバー、ニックネームなど) に適用されます。 データ・ソース・オプジェクト (表および視点) は、 これらのオブジェクトが分散要求データベースに保管されていないかぎり、 バックアップまたは復元されません。
使用する回復方式を念頭に置いて作業を行う必要があります。 次の部分では、この作業に適用される要件その他の考慮事項について扱います。
注: | 以下の節で "ページ"について言及する場合、 それはバックアップおよび復元ユーティリティーに特有のページを指して用いられています。 これらのページのサイズは必ず 4 KB です。 データベース・データで許可されている複数ページ・サイズと混同しないようにしてください。 |
計画考慮事項には、以下のことを含めてください。
OS/2 では、ディスケットまたはユーザー出口にバックアップをとることもできます。
bufferpages <= ST_MAX_BUFFERS * ST_BUFFER_BLOCKS / 4ここで、bufferpages は、 backbufsz または restbufsz のいずれかの値です。 ST_MAX_BUFFERS および ST_BUFFER_BLOCKS は、 drivers/scsi ディレクトリーの下で、Linux カーネルに定義されています。
UNIX ベースのオペレーティング・システムおよび Windows NT では、 固有なテープ・サポートが使用可能です。
注: | 磁気テープ装置で可変長のブロック・サイズを使用するときは、 DB2 バッファー・サイズが磁気テープ装置で構成されている可変長ブロック・サイズの最大値以下であることを確認してください。 そうでないと、バックアップ自体は正常に実行されますが、 生成されるイメージが回復可能であることはかぎりません。 |
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 |
注:
以下の考慮事項は、BACKUP コマンドの実行時に役立ちます。
このパラメーターを使用して、 バックアップを完了するために必要な時間を劇的に短縮することができます。 PARALLELISM パラメーターは、 データベースからデータを読み取るために開始される処理またはスレッドの数を定義します。 それぞれの処理またはスレッドが、特定の表スペースをバックアップするために割り当てられます。 処理またはスレッドが、表スペースのバックアップを完了させると、 別の表スペースを要求します。 しかし、それぞれの処理またはスレッドでは、 メモリーと CPU の両方のオーバーヘッドが必要になることに注意してください。 したがって、負荷の大きいシステムでは PARALLELISM パラメーターをデフォルト値の 1 のままにしておく必要があります。
複数のバッファーと入出力チャネルを使用する場合、 少なくともチャネルの 2 倍のバッファーを使用し、 チャネルがデータを待つ状態にならないようにします。 使用されるバッファーのサイズは、バックアップ操作のパフォーマンスに影響します。 理想的なバックアップのバッファー・サイズは、 表スペースのエクステント・サイズの倍数です。
複数の表スペースがありそれぞれエクステント・サイズが異なる場合は、 最大エクステント・サイズの倍数の値を指定します。
BACKUP コマンドの呼び出し時には、バックアップ・バッファーごとに、 使用するページの数を指定することもできます。 ページ数の最小値は 16 です。 ページ数を指定しない場合、 それぞれのバッファーはデータベース・マネージャー構成パラメーター backbufsz に基づいて割り振られます。 バッファー割り振りに使用できるメモリーが不足している場合は、エラーになります。
この構成パラメーターの詳細は、第 32 章, DB2 の構成を参照してください。
データベースの移行については、付録 B, データベース移行の計画を参照してください。
バックアップ・プロセス時にエラーが発生してオープン・コンテナーがクローズできない場合は、 同じターゲット・ドライブに対する他のバックアップ・プロセスにはアクセス・エラーが発生することがあります。 それらのアクセス・エラーを訂正するには、 エラーが発生したバックアップ・プロセスを完全に終了し、 バックアップ先装置との接続も切断する必要があります。
バックアップ・イメージは、 BACKUP コマンドを呼び出すときに指定したバックアップ先に作成されます。
データベース全体をバックアップまたは復元すると、 回復活動記録ファイルが要約情報によって自動的に更新されます。 このファイルは、データベース内の復元のアクティビティーを記録する機能として便利です。 このファイルは、データベース構成ファイルと同じディレクトリーに作成されます。 回復活動記録ファイルについては、回復活動記録ファイルの情報を参照してください。
UNIX ベースの環境では、ディスクに作成されるファイル名は、 以下の情報をピリオドで区切って連結したもので構成されます。 他のプラットフォームでは、4 レベルから構成されるサブディレクトリー・ツリーが使用されます。
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
テープに出力する場合、ファイル名は作成されません。しかし、後で検査するために、 上記の情報がバックアップ・ヘッダーに保管されます。
注:
既存のバックアップ・イメージに関する情報を表示するための、 バックアップ・ユーティリティーがあります。 このユーティリティーは db2ckbkp といい、 これを使用することにより、以下を行うことができます。
このユーティリティーを使用する場合、 指定するバックアップ・イメージに関する読み取り許可が必要です。
単にバックアップ・イメージが存在するかどうか検査する場合、 以下のようにユーティリティーを使用することができます。
db2ckbkp STAFF.0.DB201.NODE0000.CATNOOOO.19950922120112.001
このユーティリティーからの出力例を以下に示します。
[1] Buffers processed: ## Image Verification Complete - successful.
このユーティリティーの詳細については、 コマンド解説書 を参照してください。
次の部分では、RESTORE コマンドに適用される要件その他の考慮事項について扱います。
図 54. バックアップ・イメージを使用してのデータベースの復元
![]() |
このオプションが指定されており、 DATALINK データを含む DB2 データ・リンク・マネージャーを使用できない場合には、 使用不能のサーバー上の DATALINK 値のある表を含むすべての表スペースは、 RESTORE PENDING 状態に入れられます。 そのような表スペースは、 データ・リンク・サーバーが使用可能になったときに復元される必要があります。
DATALINK 列を含む表がある場合、 復元およびロールフォワードについての考慮事項 および ロールフォワードせずにデータベースをオフライン・バックアップから復元する の両方を参照してください。
以下の考慮事項は、RESTORE コマンドの実行時に役立ちます。
RESTORE コマンドの呼び出し時には、 復元バッファーごとに、使用するページの数を指定することもできます。 指定する値は、バックアップ・バッファーに指定したページ数の倍数でなければなりません。 ページ数の最小値は 16 です。 ページ数を指定しない場合、 それぞれのバッファーはデータベース・マネージャー構成パラメーター restbufsz に基づいて割り振られます。 バッファー割り振りに使用できるメモリーが不足している場合は、エラーになります。
この構成パラメーターの詳細は、第 32 章, DB2 の構成を参照してください。
部分的なタイム・スタンプを指定することもできます。 たとえば、2 種類の異なったバックアップがあり、 タイム・スタンプが 19971001010101 および 19971002010101 であるものとします。 TAKEN AT に 19971002 を指定すると、19971002010101 バックアップが使用されます。
TSM を使用して TAKEN AT パラメーターを指定しない場合、 TSM は最新のバックアップ・コピーを検出します。
OS/2 では、データベースのバックアップ・コピーは、ディスケットに保管させることもでき、 またユーザー出口から書き込み先を指定することもできます。
サポートされている Windows オペレーティング・システムでは、 データベースのバックアップ・コピーをディスケットに保管させることもできます。
データベースのバックアップ時に、バックアップされる表スペースが使用しているすべての表スペース・コンテナーについて記録がとられます。 RESTORE 実行時に、バックアップ中にリストされているすべてのコンテナーの検査が行われ、 現在存在していてアクセス可能かどうかが調べられます。 媒体障害 (あるいは他の理由) により 1 つまたは複数のコンテナーがアクセスできない場合は、 RESTORE は失敗します。 このような場合でも復元できるようにするために、RESTORE 実行時に表スペース・コンテナーをリダイレクトすることがサポートされています。 表スペース・コンテナーの追加、変更、除去がサポートされています。
バックアップ中にリストされているコンテナーがシステムにない場合でも、 復元したい場合があります。 たとえば、バックアップを取ってあるシステム以外のシステムで 災害時回復を行いたい場合などが該当します。 新規のシステムでは、必須コンテナーが定義されていない可能性があります。 このような場合でも RESTORE を実行できるようにするために、 代替コンテナーの RESTORE 時に表スペース・コンテナーを リダイレクトすることがサポートされています。
どちらの場合も、この種類の RESTORE は一般的にリダイレクト回復と呼ばれます。
表スペース・コンテナーは、 コントロール・センターから復元作業を実行することで再定義できます。 また、RESTORE コマンドの REDIRECT パラメーターを使用し、 リダイレクトを指定することもできます。 コントロール・センターを使用する場合は、 「データベース復元 (Restore Database)」ノートブックの 「コンテナー (Containers)」ページを使用してリダイレクト回復を実行することもできます。 このページには、新しいコンテナーを追加したり、既存コンテナーのパスを変更したり、 コンテナーを削除したりする機能が用意されています。 データベース復元操作時に無効なコンテナー・パスが検出されると、 コントロール・センターはそのコンテナー・パスを変更するか、 またはコンテナーを削除するように指示します。
注:
データベース全体のバックアップ・コピーを、既存のデータベースに復元することもできます。 既存のデータベースに復元するには、SYSADM、SYSCTRL、 または SYSMAINT 権限が必要です。 バックアップ・イメージの別名、データベース名、またはデータベース・シードは、 既存のデータベースとは異なる場合があります。
データベース・シードとは、データベースの持続期間中ずっと固定されている、 そのデータベース固有の識別子のことです。 このシードは、データベースの初回作成時にデータベース・マネージャーによって割り当てられます。 バックアップが異なったデータベース・シードを持っている場合でも、 シードはバックアップの復元後も変わりません。 DB2 は、常にバックアップからのシードを使用します。
既存データベースに復元する場合は、復元タスクにより以下の機能が実行されます。
データベースを既存のデータベースに復元する代わりに、 新規のデータベースを作成して、データのバックアップを復元することもできます。 新規のデータベースに復元するには、SYSADM または SYSCTRL 権限が必要です。
注: | バックアップとターゲット・データベースのコード・ページは一致していなければなりません。 一致していない場合は、正しいコード・ページを指定している新規データベースを作成した後、 復元してください。 |
新規のデータベースに復元すると、RESTORE コマンドにより以下の機能が実行されます。