5.1.3 システムログファイルの障害回復
システムログファイルに関連する障害の対策方法を次の表に示します。
|
現象 |
状況・その後の運用 |
対策 |
|---|---|---|
|
両系※1のシステムログファイルでファイル障害が発生した。 追い付き反映処理で更新ログレコードが入力できない。 |
［状況］ 更新可能なオンライン再編成の対象であったレプリカRDエリアが閉塞して，ユニットダウンしている。 |
システムログファイルをアンロード（pdlogunld）したあと，ダウンしたユニットを起動して，追い付き反映処理を中止します。運用は，レプリカのRDエリアで続けます。 詳細については，「システムログファイルで障害，ユニットダウンした場合の対策」を参照してください。 |
|
［状況］ 更新可能なオンライン再編成の対象であったレプリカRDエリアに対する更新処理が正常に継続している。 |
追い付き反映処理を中止したあと，レプリカのRDエリアで運用を続けます。システムログファイルは再作成します。 詳細については，「システムログファイルで障害，レプリカDBへの更新が継続している場合の対策」を参照してください。 |
|
|
更新可能なオンライン再編成の上書き禁止状態によりスワップ先にできるシステムログファイルがなくなり，ログ満杯でユニットダウンした。更新可能なオンライン再編成は継続できる。 |
［その後の運用］ 更新可能なオンライン再編成を継続したい。 |
システムログファイル不足発生時の回復を行いHiRDBを起動し，障害が発生したサーバへの業務を抑止後，追い付き反映処理を行います。 詳細については，「ログ満杯でユニットダウン，再編成を継続したい場合の対策」を参照してください。 |
|
［その後の運用］ HiRDBの稼働を継続したい。 |
システムログファイル不足発生時の回復を行いHiRDBを起動し，追い付き反映処理を中止します。 詳細については，「ログ満杯でユニットダウン，HiRDB稼働を継続させたい場合の対策」を参照してください。 |
|
|
追い付き反映処理に使用するシステムログファイルが，KFPS01175-Wメッセージが出力されたあと上書きされた。 そのため，追い付き反映処理ができなくなった※2。 |
［その後の運用］ HiRDBの稼働を継続したい。 |
追い付き反映処理を中止し，レプリカのRDエリアで運用を続けます。 詳細については，「システムログが上書きされ，追い付き反映できない場合の対策」を参照してください。 |
- 注※1
-
pd_log_dual=Nを指定している場合は，片系のシステムログファイルでの障害になります。
- 注※2
-
pd_log_org_no_standby_file_opr=continueを指定している場合に発生します。
- 〈この項の構成〉
(1) システムログファイルで障害，ユニットダウンした場合の対策
-
障害が発生して閉塞しているシステムログファイルに対してpdlogunldを実行します。
システムログファイルへのI/Oエラーでコマンドが失敗した場合，該当システムログファイルをpdloginitで再初期化します。ほかの理由でpdlogunldコマンドが失敗した場合，エラーメッセージに従って障害原因を取り除いて，再度pdlogunldコマンドを実行します。
-
ダウンしたユニットを再起動します。
HiRDBの再開始では，直前のHiRDB稼働中に最後に有効になったシンクポイントをシステムログから最新のシステムログファイルまでを入力にしてデータベースの回復を行います。したがって，これらの期間のシステムログファイルが一つ以上（システムログを二重化している場合はある時点のシステムログファイルの両系）を失ってしまった場合，再開始に失敗するか，またはデータベース不正が発生します。
この場合，失われたシステムログファイルのアンロードログファイルを取得していれば，データベース回復ユティリティ（pdrstr）を使うことで回復できます。
-
追い付き反映処理を中止（pdorend -uコマンド）します。
以降，HiRDBはレプリカRDエリアで業務を継続することができます。オリジナルRDエリアはデータ不整合が発生しているため，データを参照しないでください。
-
レプリカRDエリアで業務を続行したあとに，マスタDBの修復を行う方法については，表「更新可能なオンライン再編成の取り消し」を参照してください。
マスタDBの回復後は，データベースの静止化コマンド（pdorbegin）からオンライン再編成をやり直せます。
(2) システムログファイルで障害，レプリカDBへの更新が継続している場合の対策
-
追い付き反映処理を中止（pdorend -uコマンド）します。
以降，HiRDBはレプリカRDエリアで業務を継続することができます。オリジナルRDエリアはデータ不整合が発生しているため，データを参照しないでください。
-
障害が発生して閉塞しているシステムログファイルを再作成して，閉塞を解除します。
-
レプリカRDエリアで業務を続行したあとに，マスタDBの修復を行う方法については，表「更新可能なオンライン再編成の取り消し」を参照してください。
マスタDBの回復後は，データベースの静止化コマンド（pdorbegin）からオンライン再編成をやり直せます。
(3) ログ満杯でユニットダウン，再編成を継続したい場合の対策
-
システムログファイル不足発生時の回復方法に従ってHiRDBを起動します。
システムログファイルの容量不足に関する詳細については，マニュアル「HiRDB システム運用ガイド」を参照してください。
このとき追加するシステムログファイルは，次のようにしてください。
-
バージョン09-04より前のHiRDBを使用している場合
マニュアル「HiRDB システム運用ガイド」の計算式で求めた値の2倍にしてください。
-
バージョン09-04以降のHiRDBを使用している場合
マニュアル「HiRDB システム運用ガイド」の計算式で求めた値にしてください。
-
-
障害が発生したサーバへの更新処理（オンライン業務）を抑止します。
業務抑止はユーザごとの運用手順に従って実行してください。
-
追い付き反映処理コマンド（pdorend）を実行します。
-
更新可能なオンライン再編成が正常終了したら，更新処理（オンライン業務）の抑止を解除して，業務を再開します。
(4) ログ満杯でユニットダウン，HiRDB稼働を継続させたい場合の対策
-
システムログファイル不足発生時の回復方法に従ってHiRDBを起動します。
システムログファイルの容量不足に関する詳細については，マニュアル「HiRDB システム運用ガイド」を参照してください。
-
追い付き反映処理を中止（pdorend -uコマンド）します。
以降，HiRDBはレプリカRDエリアで業務を継続することができます。オリジナルRDエリアはデータ不整合が発生しているため，データを参照しないでください。
-
レプリカRDエリアで業務を続行したあとに，マスタDBの修復を行う方法については，表「更新可能なオンライン再編成の取り消し」を参照してください。
マスタDBの回復後は，データベースの静止化コマンド（pdorbegin）からオンライン再編成をやり直せます。
(5) システムログが上書きされ，追い付き反映できない場合の対策
-
追い付き反映処理を中止（pdorend -uコマンド）します。
以降，HiRDBはレプリカRDエリアで業務を継続することができます。オリジナルRDエリアはデータ不整合が発生しているため，データを参照しないでください。
-
レプリカRDエリアで業務を続行したあとに，マスタDBの修復を行う方法については，表「更新可能なオンライン再編成の取り消し」を参照してください。
マスタDBの回復後は，データベースの静止化コマンド（pdorbegin）からオンライン再編成をやり直せます。