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

バックアップの概要

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

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 バイトです。

表 33. Linux 上の 3480 および 3490 磁気テープ装置の最大ブロック・サイズ限度
装置	接続	ブロック・サイズの限度	DB2 バッファー・サイズの限度(4KB ページ単位)
3480	s370	61 440	15
3490	s370	61 440	15

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 に復元されます。

db2 connect to my_database
db2 list tablespaces show detail
注:

db2 list tablespaces show detail コマンドを実行して、すべての表スペースの状況を表示し、ステップ 5 で必要となる表スペース ID 番号を取得します。
db2 stop hadr on database my_database
db2 "restore database my_database tablespace (my_tablespace) online redirect"
db2 "set tablespace containers for my_tablespace_ID_# ignore rollforward container operations using (path '/my_new_container_path/')"
db2 "restore database my_database continue"
db2 rollforward database my_database to end of logs and stop tablespace "(my_tablespace)"
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 で失敗します。

| | |

障害モニターとヘルス・モニターの比較

ヘルス・モニターおよび障害モニターは、単一のデータベース・インスタンスで作動するツールです。 |ヘルス・モニターはヘルス・インディケーターを使用して、データベース・マネージャー・パフォーマンスまたはデータベース・パフォーマンスの特定の局面の正常性を評価します。ヘルス・インディケーターは、表スペースなどのデータベース・オブジェクトの特定のクラスのいくつかの局面の正常性を測定します。ヘルス・インディケーターは、データベース・オブジェクトのそのクラスの正常性を判断するため、特定の基準に対して評価できます。さらに、ヘルス・インディケーターはアラートを生成して、インディケーターがしきい値を超えたとき、またはデータベース・オブジェクトの状態が異常であることを示すときに通知します。

比較すると障害モニターは、モニターしている稼働中のインスタンスを単に保持する役割があるだけです。モニター中の DB2 UDB インスタンスが突然終了すると、障害モニターはインスタンスを再開します。 |障害モニターは Windows では使用できません。

| | |

障害モニターをオフにする

データベース・インスタンス DB2INST1 について障害モニターをオフにするには、DB2 UDB コマンド・ウィンドウから以下のコマンドを入力します。 |

      db2fm -i db2inst1 -f no

| |

注:

障害モニターのレジストリー・ファイルが存在しない場合、デフォルト値が使用されます。

障害モニターがもう DB2INST1 について実行していないことを確認するには、UNIX システム上では、以下のコマンドを入力します。 |

      ps -ef|grep -i fm

Linux システム上では、以下のコマンドを入力します。 |

      ps auxw|grep -i fm

db2fmd および DB2INST1 を示す項目は、障害モニターがまだそのインスタンスで実行中であることを示しています。障害モニターをオフにするには、インスタンス所有者として以下のコマンドを入力します。 |

      db2fm -i db2inst1 -D

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