HADR スタンバイ・データベースでの表スペース・エラーのリカバリー

HADR 環境では、スタンバイ・データベースの表スペースが無効な状態またはエラー状態になると、その表スペース上でのトランザクションの再生が停止します。 ただし、他の有効な表スペース上でのトランザクションの再生は続けられます。 1 次データベースへの影響はなく、スタンバイ上のその表スペースの状態が検出されることもありません。

スタンバイ・データベースでこのような表スペースの状態が発生した場合は、その後にスタンバイ・データベースで TAKEOVER 操作が実行されるときに、その表スペースが使用不可であることがアプリケーションに影響を与える可能性があります。 スタンバイ・データベースのエラー状態の表スペースをリカバリーするには、対象の表スペースを再初期化するか、データベース全体を再初期化します。

スタンバイでエラー状態の表スペースをモニターして特定する

この状態をモニターし、エラーのある表スペースを識別するための手法は、技術情報 HADR スタンバイ・データベースでの無効またはエラー状態にある表スペースのモニターおよび識別に記述されています。

エラー状態の表スペースの原因を特定して修正する

エラー状態の表スペースを特定したら、エラー状態の原因を調べる必要があります。 一般的な原因としては、ファイル・システムのスペースが十分でない、ファイル・システムがマウントされていない、ファイル・システムにエラーがある、ロードの COPY YES のイメージが見つからないなどがあります。 重大なログ再生エラーが原因である場合もあります。

管理通知ログ (<instance_name>.nfy) と db2diag.log を確認する必要があります。

エラーのタイプによっては、管理通知ログ (<instance name>.nfy) に次のような警告メッセージが記録されています。
2016-03-15-22.51.15.490605 Instance:rsiinp16 Node:000
     PID:10551302(db2redow (MYDB1) 0) TID:19277 Appid:*LOCAL.DB2.160221104421
     buffer pool services sqlbIncPoolState Probe:3604 Database:MYDB1
     ADM12512W Log replay on the HADR standby has stopped on table space "MYTBSPACE3"
     (ID "7") because it has been put into "ROLLFORWARD PENDING" state.
     
2016-03-15-22.51.15.565961 Instance:rsiinp16 Node:000 
     PID:10551302(db2redow (MYDB1) 0) TID:19277 Appid:*LOCAL.DB2.160221104421
     data management sqldHandleBadPool Probe:40 Database:MYDB1
     ADM5550C The table space "MYTBSPACE3" (ID "7") is being removed from the
     rollforward set. The SQLCODE is "-980".
また、db2diag.log にも、この例のディスク書き込みエラーなどのように、詳細な情報を含むエラー・メッセージが記録されている場合があります。
2016-03-15-22.51.15.189467-240 E763181A1307 LEVEL: Error (OS)
     PID : 10551302 TID : 19277 PROC : db2sysc 0
     INSTANCE: myinst1 NODE : 000 DB : MYDB1APPHDL : 0-8 
     APPID: *LOCAL.DB2.160221104421
     HOSTNAME: somehost.ibm.com
     EDUID : 19277 EDUNAME: db2redow (MYDB1) 0
     FUNCTION: Db2 UDB, oper system services, sqloseekwrite64, probe:40
     MESSAGE : ZRC=0x860F0003=-2045837309=SQLO_DERR "disk error occurred (DOS)"
     DIA8402C A disk error has occurred.
     CALLED : OS, -, pwrite
     OSERR : EIO (5) "I/O error"

エラー状態の原因が、ファイル・システム・スペースの不足、ファイル・システムの問題などのローカライズされた問題であると判別された場合は、スタンバイ上の表スペースの再初期化に進む前に、その問題を修正する必要があります。

エラー状態の原因が重大な再生エラーまたは Db2 内部エラーであって、局所的な原因が見つからなかった場合は、すべての診断情報を用意して PMR をオープンしてください。

スタンバイ・データベースのエラー状態の表スペースを再初期化する

Db2® のバージョンに応じて、スタンバイ・データベース上のエラーのある表スペースを再初期化するためのそれぞれのリンクを参照してください。

pureScale 環境および非pureScale 環境の場合、 バージョン 10.5 フィックスパック 8 およびそれ以前のフィックスパック: pureScale 環境の場合、 バージョン 10.5 フィックスパック 9 以降のフィックスパック、またはバージョン 11.1.0.0 または 11.1.1.1:pureScale 以外の環境の場合、 バージョン 10.5 フィックスパック 9 以降のフィックスパック、またはバージョン 11.1.0.0 または 11.1.1.1:pureScale 環境および非 pureScale 環境のバージョン 11.1.2.2 以降のモディフィケーション・パック:
スタンバイ・データベースのエラー状態の表スペースを再初期化する手順
  1. スタンバイ・ホストで、スタンバイ・データベースを非アクティブにします。
    [Standby]$db2 "deactivate db MYDB1"
  2. 1 次ホストで、バックアップ操作の前に FLUSH BUFFERPOOL 操作を実行します。 これは、ステップ 3 で取られるバックアップ・イメージが、スタンバイ・データベースのリカバリー開始点よりも後のリカバリー開始点を持つようにするためです。 この操作は、スタンバイ・データベースの表スペースを修復するために必要です。
    [Primary]$db2"flush bufferpools all"
    注: ワークロードが高いデータベースでは、FLUSH BUFFERPOOL 操作中に積極的な入出力が行われるため、パフォーマンスの問題が短時間で発生する可能性があります。
  3. 1 次ホストで、エラー状態の表スペースのバックアップを実行します。 (注: 「オンライン」バックアップでは、バックアップ操作中も 1 次データベースは使用可能な状態が維持されます)。
    [Primary]$db2 "backup db MYDB1 tablespace MYTBSPC3 online to /bkp_image_path_pri/ "
    バージョン 11.1.0.0 または 11.1.1.1 の場合のみ、スタンバイ・ホストで STOP HADR 操作を実行します。
    [Standby]$db2 "stop hadr on db MYDB1"
  4. バックアップ・イメージを 1 次ホストのパス (この例の場合は /bkp_image_path_pri/) からスタンバイ・ホストのパス (この例の場合は /bkp_image_path_stdby/) にコピーまたは FTP で転送します。 スタンバイ・ホストで、バックアップ・イメージから表スペースのオフライン・リストアを実行します。
    [Standby]$db2 "restore db MYDB1 tablespace (MYTBSPC3) from /bkp_image_path_stdby/"
    バージョン 11.1.0.0 または 11.1.1.1 の場合のみ、スタンバイ・ホストで START HADR AS STANDBY 操作を実行します。
    [Standby]$db2 start hadr on db MYDB1 as standby
  5. スタンバイ・ホストで、データベースを再アクティブ化します (バージョン 11.1.0.0 または 11.1.1.1 の場合は、上記の start hadr 操作を行ったため、このステップは必要ありません)。
    [Standby]$db2 "activate db MYDB1"
この文書の先頭の説明に従って、スタンバイ上の表スペースの状態をモニターします。 リカバリーされた表スペースは、次のテークオーバー操作まで引き続き ROLLFORWARD_IN_PROGRESS (x40) 状態であることに注意してください。この状態が原因で問題が起きることはありません。

スタンバイ上の表スペースが無効であることが分かる前に TAKEOVER 操作が実行された場合、以下のようになります。

TAKEOVER 操作を既に実行した後に新しい 1 次データベース上の 1 つ以上の表スペースが無効であることに気付いた場合、それらの表スペースが照会または操作によってアクセスされると、SQL0290N エラーが返されることがあります。
SQL0290N Table space access is not allowed SQLSTATE=55039
また、新しい 1 次の db2diag.log に、次のようなメッセージが書き込まれる場合があります。

   yyyy-mm-dd-hh.mm.ss...       I32132788A530      LEVEL: Warning
   PID     : ...                TID  : ...         PROC : db2sysc 0
   INSTANCE: ...                NODE : ...         DB   : ...
   APPHDL  : ...                APPID: ...
   EDUID   : ...                EDUNAME: db2agent (...) 0
   FUNCTION: Db2 UDB, recovery manager, sqlpGetTablespacesForFilter,probe:1570
   DATA #1 : preformatted
   Tablespace 6 is in rollforward pending state. Another rollforward will
   be needed to bring this tablespace online.

どの表スペースがロールフォワード・ペンディング状態であるかを確認するには、技術情報 (#1993013)「 HADR スタンバイ・データベースでの無効な表スペースまたはエラー状態の表スペースのモニターおよび識別」で説明されているように、 db2pd -tablespaces コマンドを使用できます。

この状態を解決するには、以下の 3 つの方法があります。

以前の 1 次データベースがまだオンラインの場合: 以前の 1 次データベースで TAKEOVER 操作を実行することによって、それを再度 1 次データベースに設定できます。その後、上記の手順を使用して、スタンバイ・データベース上の無効な表スペースを再初期化できます。 アプリケーションが表スペース・データにアクセスできない期間が短縮されるため、この方法は推奨されます。

以前の 1 次データベースがオンラインでないか、アクセスできない場合: 新しい 1 次データベースでロールフォワード操作を実行して、表スペースを通常の状態に戻す必要があります。 まず、新しい 1 次データベースで、表スペースが無効になった時点以降の必要なリカバリー・ログ・ファイルをすべて使用できるようにする必要があります (この期間を特定するために、db2diag.log をかなりさかのぼって調べなければならない場合があります)。 ログ・ファイルは、アクティブ・ログ・パスにコピーできます。また、別個のパスに保管して、下記の後続のロールフォワード操作で「オーバーフロー・ログ・パス」オプションを使用することもできます。 (ログ・ファイルを削除したり、上書き/置換したりないでください。この種のログ・ファイル操作を実行する場合は、必ずコピーを保存しておいてください。) 次に、新しい 1 次データベースを標準 (非 HADR) データベースに変更する必要があります。 (そうしない場合、それ以降のロールフォワード操作を HADR データベースで実行しようとすると、「SQL1774N Table space restore or rollforward cannot be issued on an HADR primary or HADR standby database」で失敗します。)

   db2 deactivate db sample
   db2 stop hadr on db sample
ロールフォワード操作を実行します。

   db2 rollforward db dbname to end of logs
ロールフォワードが完了すると、表スペースが正常な状態になるため、HADR スタンバイ・データベースを再初期化する必要があります。