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

8 8 8

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

8

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

7 7 7

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

7

DB2 Universal Database(TM) (UDB) は、クロスプラットフォームでのバックアップおよび復元操作をサポートしています。DB2(R) UDB バージョン 8、32 ビット Windows(R) プラットフォーム版で作成されたデータベースを、DB2 UDB バージョン 8 、64 ビット Windows プラットフォーム版に復元したり、その逆に復元したりすることが可能です。 7DB2 UDB バージョン 8、32 ビット Linux(TM) x86 プラットフォーム版で作成されたデータベースを、DB2 UDB バージョン 8、64 ビット Linux x86-64 または IA64 プラットフォーム版に復元したり、その逆に復元したりすることが可能です。 7DB2 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 ビット) に復元できます。

7 7 7

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

7

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

7

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

Tivoli Storage Manager

7

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

77 7 7

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

7

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

7 7 7

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

7

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

7

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

7

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

7

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

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

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

7

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

7

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

7

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

7

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

7 7 7

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

7

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

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