ページの先頭行へ戻る
Symfoware Server V11.0.0 Mirroring Controller運用ガイド
Symfoware

5.8.6 データベース二重化処理の異常

副系ノードにおけるDBミラーリングシステムの運用中に、データベース二重化処理が異常となった場合のリカバリ方法について示します。
以下の表では、データベース二重化処理の異常原因を示します。

表5.10 異常原因

異常原因

対象資源名

リカバリ方法

メディア障害

BCログ管理ファイル

5.8.6.1 BCログ管理ファイルの異常”を参照

RLCファイル

5.9 DCUの再構築”を参照
(注1)(注2)

RLM

RERUNログ抽出ファイル

RERUNログ抽出作業域

RERUNログ引継ぎファイル

BC管理DB

ディスク容量不足
(注3)

RERUNログ抽出ファイル

5.9 DCUの再構築
(注1)(注2)または
E.2 RERUNログ抽出処理異常からのリカバリ方法”を参照

RERUNログ抽出作業域

RERUNログ引継ぎファイル

5.9 DCUの再構築”を参照
(注1)(注2)

BC管理DB

B.3 容量監視と容量拡張”を参照

データベースの
ノード間不一致

データベースの論理障害
(注4)

5.8.6.4 ログ破棄を利用したリカバリ”を参照

データベース定義不整合

5.8.6.4 ログ破棄を利用したリカバリ”または
E.3.2 データベース定義不整合からのリカバリ”を参照

データベース定義の関連付け未定義

5.8.6.4 ログ破棄を利用したリカバリ”または
E.3.3 データベース定義の関連付け未定義からのリカバリ”を参照

DSI非活性/未フォーマット

5.8.6.4 ログ破棄を利用したリカバリ”または
E.3.4 DSI非活性/未フォーマットのリカバリ”を参照

メモリ不足

-

メモリ不足を解決してからDBミラーリングサービスを開始
(注5)

リモートコピー環境などの異常

ディスコネクション状態

5.8.6.3 ディスコネクション状態からのリカバリ”を参照

注1)RLMなどにメディア障害が発生した場合にはRLPが閉塞されることがあります。

注2) 一部の異常事象によっては、DCUの再構築以外の方法でリカバリすることも可能です。詳細は"付録E データベース二重化処理での異常の詳細なリカバリ手順"を参照してください。

注3)データベース二重化処理では、テンポラリログファイルの容量不足が発生する可能性があります。

注4)データベースの論理障害とは、正系ノードのデータベースと副系ノードのデータベースのデータが異なっている状態です。データベース二重化処理は以下の事象を検知した場合に異常となります。

注5) DBミラーリングサービスをリカバリ停止した後に、DBミラーリングサービスを開始します。

注意

データベース二重化処理では、上記に示す以外のSymfoware/RDB資源(データベースやSymfoware/RDBのシステムファイルなど)の異常も検知することがあります。その場合は、副系ノードにおけるSymfoware/RDBの異常時の手順で対処してださい。

参照

5.8.6.1 BCログ管理ファイルの異常

BCログ管理ファイルの異常時は、正系ノードでのBCログ管理ファイルのリカバリ手順と同じです。

参照

BCログ管理ファイルの異常時の、正系ノードでのBCログ管理ファイルのリカバリ手順については“5.7.5.2 BCログ管理ファイルの異常”を参照してください。

5.8.6.2 RLP閉塞

副系ノードでのDBミラーリングシステム資源に対するメディア障害などが発生した場合や、モニタデーモンのダウンが発生した場合に、データベース二重化処理が継続できなくなり、副系ノードのRLPが閉塞します。

RLPが閉塞した場合には、副系ノードから正系ノードへの切替えが不可能となり、利用者業務を停止した後に、DCUの再構築が必要となります。
RLP閉塞となった原因については、出力されたメッセージを参照し、再構築手順内でリカバリも実施してください。

参照

DCUの再構築ついては“5.9 DCUの再構築”を参照してください。

5.8.6.3 ディスコネクション状態からのリカバリ

DBミラーリングシステムの運用では、RLPを配置しているリモートコピー環境の異常や相手先データベースが停止した場合に、ディスコネクション状態になります。

参照

ディスコネクション状態からのリカバリについては “5.7.5.4 ディスコネクション状態からのリカバリ”を参照してください。

5.8.6.4 ログ破棄を利用したリカバリ

ログ破棄は、以下の場合に利用します。以降ではログ破棄を利用したリカバリについて説明します。

注意

Symfoware Serverのrdbinhコマンドにより、表のDSIを閉塞し、ログ破棄を利用することで、任意の資源へのRERUNログを破棄することも可能です。

ログ破棄を利用したリカバリが可能な障害

ログ破棄が可能なデータベース二重化処理のエラー原因を以下に示します。

表5.11 ログ破棄が可能なデータベース二重化処理のエラー原因

エラー原因

メッセージID

考えられる原因

リカバリ方法

RERUNログレコード不整合

qdg20178u:データベース内でデータの不整合を検出しました

ノード間のデータベースのデータが不一致

全件複写

データベース定義不整合

qdg20180u:データベース内で定義の不整合を検出しました

データベースの定義および変更操作の不一致

表定義の再作成および全件複写

表定義の不一致

qdg20186u:反映に必要なインデックスが存在しません

インデックスのDSO未定義

qdg20187u:表のDSIに対応するインデックスのDSIが定義されていません

インデックスのDSI未定義

未フォーマット

qdg20179u:初期化または創成が行われていません

表のDSI未フォーマット

全件複写

インデックスのDSI未フォーマット

反映対象資源のアクセス異常

qdg20188u:アクセス禁止状態のため動作できません

表のDSIの閉塞

メディアリカバリ
または全件複写

データベース定義の関連付け未定義

qdg20183u:データベース定義の関連付けが行われていません

資源識別子の未登録

資源識別子の関連付けおよび全件複写

注意

インデックスのDSIをログ破棄対象とするためには、インデックスの属する表のDSIをSymfoware Serverのrdbinhコマンドで閉塞に設定します。

参照

Symfoware Serverのrdbinhコマンドについては“ コマンドリファレンス”を参照してください。

ログ破棄の設定方法

ログ破棄を利用する場合は、RLP動作環境ファイルのREF_LOG_PURGEパラメタを編集します。

REF_LOG_PURGEパラメタの指定値は、リカバリ方法によって決定します。

表5.12 リカバリ方法とREF_LOG_PURGEパラメタの指定値

リカバリ方法

REF_LOG_PURGEパラメタの設定値

すでにREF_LOG_PURGEパラメタが指定されている場合の設定値

全件複写

DSI

すでにREF_LOG_PURGE = MAPが指定されている場合はALLを設定してください。

表定義の再作成および全件複写

DSI

メディアリカバリ

DSI

資源識別子の関連付け

MAP

すでにREF_LOG_PURGE = DSIが指定されている場合はALLを設定してください。

REF_LOG_PURGEパラメタの変更は、以下の手順で実施してください。

  1. DBミラーリングサービスの保守停止

  2. 主系RLPのRLP動作環境ファイルの編集

  3. DBミラーリングサービスを開始

参照

  • RLP動作環境ファイルのREF_LOG_PURGEパラメタの詳細については“Mirroring Controller セットアップガイド”の“DBミラーリングシステムの環境設定”を参照してください。

  • DBミラーリングサービスの保守停止については“2.2.2.2 DBミラーリングサービスの保守停止”を参照してください。

  • RLP動作環境ファイルの編集については“Mirroring Controller セットアップガイド”の“RLP動作環境ファイルの編集”を参照してください。

  • DBミラーリングサービスを開始については“2.1.5 DBミラーリングサービスの開始”を参照してください。

ログ破棄

REF_LOG_PURGEパラメタを以下のとおり指定してDBミラーリングサービスを開始すると、DBミラーリングシステムがデータベース二重化処理を実行します。

このとき、データベース二重化処理では、表のDSIが閉塞となっている資源、または資源の関連付けが未実施でデータベースへの反映が不可能なRERUNログのみを破棄し、データベース二重化処理を続行します。RERUNログを破棄すると、以下のメッセージが出力されます。

REF_LOG_PURGE=DSI指定時

rdb: INFO: qdg20172i:ログ破棄オプションに従ってRERUNログを破棄しました 表のDSI名='表のDSI名' RLP名='RLP名'

REF_LOG_PURGE=MAP指定時

rdb: INFO: qdg20173i:ログ破棄オプションに従ってRERUNログを破棄しました 資源種別='資源種別' 複写元資源識別子='複写元資源識別子' RLP名='RLP名'

ログ破棄の実施後に、同様の異常を検知した場合は、REF_LOG_PURGEパラメタに設定したログ破棄指示に従ってログ破棄を継続します。

ポイント

  • RERUNログを破棄した資源が複数ある場合、メッセージも複数出力されます。

  • インデックスのDSIを指定したSymfoware ServerのrdbfmtコマンドのRERUNログについては、インデックスのDSIが閉塞となっている場合も破棄されます。

ログ破棄の解除方法

ログ破棄を利用した後、リカバリが完了してDBミラーリングサービスを開始する前に、必ずログ破棄を解除する必要があります。

ログ破棄の解除は、RLP動作環境ファイルのREF_LOG_PURGEパラメタに“NONE”を指定します。

REF_LOG_PURGE = NONE

ポイント

  • REF_LOG_PURGEパラメタの変更は、DBミラーリングサービスが通常停止状態で行います。

  • REF_LOG_PURGEパラメタの変更は、主系RLPのRLP動作環境ファイルで行います。

  • REF_LOG_PURGEパラメタの変更は、DBミラーリングサービスを開始すると有効となります。

参照

RLP動作環境ファイルのREF_LOG_PURGEパラメタの詳細については、“Mirroring Controller セットアップガイド”の“DBミラーリングシステムの環境設定”を参照してください。

ログ破棄中の注意事項

ログ破棄の利用中に、インデックスのDSIでアクセス禁止を検知した場合は、以下の対処を行い、ログ破棄を継続してください。

副系ノードでの操作
  1. dxsvstopコマンドのmオプションを実行して、DBミラーリングサービスを保守停止します。

    $ dxsvstop -m
  2. Symfoware Serverのrdbrcvコマンドを実行して、表のDSIの内容をもとにインデックスのDSIをリカバリします。

  3. dxsvstartコマンドのrオプションを実行して、DBミラーリングサービスを開始します。

    $ dxsvstart -r

なお、上記以外に表のDSIに対してSymfoware Serverのrdbinhコマンドで閉塞設定を行うことで、ログ破棄を行う方法もあります。その場合、ログ破棄の解除を行ったときには、表のDSIに対する全件複写が必要です。

参照

Symfoware Serverのrdbrcvコマンドおよびrdbinhコマンドについては“ コマンドリファレンス”を参照してください。