データ・リカバリーと高可用性

バックアップの概要

以下の制限事項に注意してください。 |

|
• DMS 表スペースのオンライン・バックアップ操作を開始できるのは、同一表スペース内の表をオンラインで再編成している場合です。 |切り捨て段階で、再編成操作のロック待機が生じることがあります。
|
• SMS 表スペースのオンライン・バックアップ操作は、同一表スペース内の表をオンラインで再編成している場合には開始できません。 |どちらの操作の場合も、排他ロックが必要です。

バックアップの使用

バックアップ・ユーティリティーには、以下の制限が適用されます。

|
• 別々の表スペースが関係している場合でも、 |表スペースのバックアップ操作と表スペースのリストア操作とを同時に実行することはできません。
|
• パーティション・データベース環境でロールフォワード・リカバリーを使用できるようにしたい場合は、 |定期的にノード・リストについてデータベースのバックアップをとる必要があり、また、 |システム内の残りのノードのバックアップ・イメージも少なくとも 1 つは作成する必要があります (該当するデータベースに関するユーザー・データを含んでいない場合でも)。 |データベースに関するユーザー・データを含んでいないデータベース・パーティション・サーバーで、 |データベース・パーティションのバックアップ・イメージが必要となるのは、次の 2 つの場合です。 | |
  |
  • 最後のバックアップを作成した後にデータベース・システムにデータベース・パーティション・サーバーを追加し、 |このデータベース・パーティション・サーバーについて順方向リカバリーを実行する必要がある場合。
  |
  • 特定時点のリカバリーを使用する場合。 |この場合は、システム内のすべてのデータベース・パーティションがロールフォワード・ペンディング状態でなければなりません。
  |
  • DMS 表スペースのオンライン・バックアップ操作は、以下の操作との互換はありません。 | |
    |
    • ロード
    |
    • 再編成 (オフラインのみ)。(バックアップされる表スペース内の表のオンライン再編成を使用できます。ただし、再編成操作の切り捨て段階でロック待機が生じることがあります)。
    |
    • 表スペースのドロップ
    |
    • 表の切り捨て
    |
    • 索引の作成
    |
    • NOT LOGGED INITIALLY (CREATE TABLE および ALTER TABLE ステートメントと共に使用)

高可用性災害時リカバリーの概要

START HADR、STOP HADR、または TAKEOVER HADR コマンドを実行すると、対応するエラー・コード (理由コード 98 の SQL01767N、SQL01769N、または SQL01770N) が生成されることがあります。理由コードは、コマンドが実行されたサーバー上に HADR のインストール済みライセンスが存在しないことを示します。 問題を訂正するには、db2licm を使用して有効な HADR ライセンスをインストールするか、またはディストリビューションの一部として有効な HADR ライセンスを含むサーバーのバージョンのインストールします。

クロスプラットフォームでのバックアップおよび復元のサポート

DB2 Universal Database^(TM) (UDB) は、クロスプラットフォームでのバックアップおよび復元操作をサポートしています。

DB2^(R) UDB バージョン 8、32 ビット Windows^(R) プラットフォーム版で作成されたデータベースを、DB2 UDB バージョン 8、64 ビット Windows プラットフォーム版に復元したり、その逆に復元したりすることが可能です。

DB2 UDB バージョン 8、32 ビット Linux^(TM) x86 プラットフォーム版で作成されたデータベースを、DB2 UDB バージョン 8、64 ビット Linux x86-64 または IA64 プラットフォーム版に復元したり、その逆に復元したりすることが可能です。

DB2 UDB バージョン 8、AIX^(R)、HP-UX、または Linux PPC、Linux zSeries^(R)、Solaris オペレーティング環境プラットフォーム版 (32 ビットまたは 64 ビット) で作成されたデータベースを、DB2 UDB バージョン 8、AIX、HP-UX、Linux PPC、Linux zSeries、または Solaris オペレーティング環境プラットフォーム版 (32 ビットまたは 64 ビット) に復元できます。

テープへのバックアップ (Linux)

Linux 上の 3480 および 3490 磁気テープ装置の最大ブロック・サイズ限度は 61 440 バイトです。

Tivoli Storage Manager

BACKUP DATABASE コマンドまたは RESTORE DATABASE コマンドを呼び出す時に、Tivoli^(R) Storage Manager (TSM) 製品を使用してデータベースまたは表スペースのバックアップの管理または復元操作の管理を行うことを指定できます。以下のシステムを除き、TSM クライアント API の必要最小レベルは、バージョン 4.2.0 です。

• 64 ビット Solaris システムでは、TSM クライアント API バージョン 4.2.1 が必要です。
• 64 ビット Windows NT^(R) オペレーティング・システムでは、TSM クライアント API バージョン 5.1 が必要です。
• 32 ビット Linux for iSeries^(TM) and pSeries^(R) では、TSM クライアント API バージョン 5.1.5 以上が必要です。
• |64 ビット Linux for iSeries and pSeries では、TSM クライアント API バージョン 5.3 以上が必要です。
• 64 ビット Linux on AMD Opteron システムでは、TSM クライアント API バージョン 5.2.0 以上が必要です。
• 64 ビット Linux for zSeries では、TSM クライアント API バージョン 5.2.2 以上が必要です。

HADR ローカル・ホスト・パラメーターおよびローカル・サービス・パラメーターの値の制約事項

update database configuration コマンドの準備中に、高可用性災害時リカバリー (HADR) ローカル・ホスト・パラメーターおよびローカル・サービス・パラメーター (HADR_LOCAL_SVC および HADR_REMOTE_SVC) の値を指定する場合は、その値は他のサービスに使用されていないポートでなければなりません。これらのパラメーターを Linux または UNIX^(R) コマンド行を使用して構成する場合は、値を /etc/services ファイルにも設定する必要があります。

高可用性災害時リカバリーの追加システム要件

1 次データベースに表スペースを作成してある場合で、コンテナーを使用できないためにログ再生がスタンバイ・データベースで失敗しても、1 次データベースはログ再生が失敗したというエラー・メッセージを受け取りません。

ログ再生エラーがないかどうかを確認するには、新しい表スペースの作成時にスタンバイ・データベース上の db2diag.log および管理ログをモニターする必要があります。

テークオーバー操作が行われる場合、新しい 1 次データベースでは作成した新しい表スペースを使用できません。この状態から回復するには、表スペースをバックアップ・イメージから新しい 1 次データベースに復元します。

以下の例では、表スペース MY_TABLESPACE が、新しい 1 次データベースとして使用される前にデータベース MY_DATABASE に復元されます。

1. db2 connect to my_database
2. db2 list tablespaces show detail
   注:
   db2 list tablespaces show detail コマンドを実行して、すべての表スペースの状況を表示し、ステップ 5 で必要となる表スペース ID 番号を取得します。
3. db2 stop hadr on database my_database
4. db2 "restore database my_database tablespace (my_tablespace) online redirect"
5. db2 "set tablespace containers for my_tablespace_ID_# ignore rollforward container operations using (path '/my_new_container_path/')"
6. db2 "restore database my_database continue"
7. db2 rollforward database my_database to end of logs and stop tablespace "(my_tablespace)"
8. db2 start hadr on database my_database as primary

高可用性災害時リカバリー用の複製されない操作

バージョン 8.2 の資料には、次の説明があります。

BLOB および CLOB は複製されません。ただし、それらのスペースは、スタンバイ・データベースに割り振られます。

この記述は、正しくは次のとおりです。

ログに記録されていない BLOB および CLOB は複製されません。ただし、それらのスペースは、 スタンバイ・データベースに割り振られます。

HADR でのロー・ログの非サポート

高可用性災害時リカバリー (HADR) では、データベース・ログ・ファイルでのロー I/O (直接ディスク・アクセス) の使用はサポートされていません。START HADR コマンドを使用して HADR が開始されている場合、または HADR が構成された状態でデータベースが再始動されている場合で、ロー・ログが検出されると、関連するコマンドは SQL1768N 理由コード 9 で失敗します。