システムログファイルの障害回復

システムログファイルに関連する障害の対策方法を次の表に示します。

表 5‒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)　システムログファイルで障害，ユニットダウンした場合の対策

1. 障害が発生して閉塞しているシステムログファイルに対して pdlogunld を実行します。

システムログファイルへの I/O エラーでコマンドが失敗した場合，該当システムログファイルを pdloginit で再初期化します。ほかの理由で pdlogunld コマンドが失敗した場合，エラーメッセージに 従って障害原因を取り除いて，再度 pdlogunld コマンドを実行します。

2. ダウンしたユニットを再起動します。

HiRDB の再開始では，直前の HiRDB 稼働中に最後に有効になったシンクポイントをシステムログか ら最新のシステムログファイルまでを入力にしてデータベースの回復を行います。したがって，これら の期間のシステムログファイルが一つ以上（システムログを二重化している場合はある時点のシステム ログファイルの両系）を失ってしまった場合，再開始に失敗するか，またはデータベース不正が発生し ます。

この場合，失われたシステムログファイルのアンロードログファイルを取得していれば，データベース 回復ユティリティ（pdrstr）を使うことで回復できます。

3. 追い付き反映処理を中止（pdorend -u コマンド）します。

以降，HiRDB はレプリカ RD エリアで業務を継続することができます。オリジナル RD エリアはデー タ不整合が発生しているため，データを参照しないでください。

4. レプリカ RD エリアで業務を続行したあとに，マスタ DB の修復を行う方法については，表「更新可能

なオンライン再編成の取り消し」を参照してください。

マスタ DB の回復後は，データベースの静止化コマンド（pdorbegin）からオンライン再編成をやり直 せます。

(2)　システムログファイルで障害，レプリカ DB への更新が継続している場 合の対策

1. 追い付き反映処理を中止（pdorend -u コマンド）します。

以降，HiRDB はレプリカ RD エリアで業務を継続することができます。オリジナル RD エリアはデー タ不整合が発生しているため，データを参照しないでください。

2. 障害が発生して閉塞しているシステムログファイルを再作成して，閉塞を解除します。

3. レプリカ RD エリアで業務を続行したあとに，マスタ DB の修復を行う方法については，表「更新可能

なオンライン再編成の取り消し」を参照してください。

マスタ DB の回復後は，データベースの静止化コマンド（pdorbegin）からオンライン再編成をやり直 せます。

(3)　ログ満杯でユニットダウン，再編成を継続したい場合の対策

1. システムログファイル不足発生時の回復方法に従って HiRDB を起動します。

システムログファイルの容量不足に関する詳細については，マニュアル「HiRDB システム運用ガイ ド」を参照してください。

このとき追加するシステムログファイルは，次のようにしてください。

• バージョン 09-04 より前の HiRDB を使用している場合

マニュアル「HiRDB システム運用ガイド」の計算式で求めた値の 2 倍にしてください。

• バージョン 09-04 以降の HiRDB を使用している場合

マニュアル「HiRDB システム運用ガイド」の計算式で求めた値にしてください。

2. 障害が発生したサーバへの更新処理（オンライン業務）を抑止します。

業務抑止はユーザごとの運用手順に従って実行してください。

3. 追い付き反映処理コマンド（pdorend）を実行します。

4. 更新可能なオンライン再編成が正常終了したら，更新処理（オンライン業務）の抑止を解除して，業務 を再開します。

(4)　ログ満杯でユニットダウン，HiRDB 稼働を継続させたい場合の対策

1. システムログファイル不足発生時の回復方法に従って HiRDB を起動します。

システムログファイルの容量不足に関する詳細については，マニュアル「HiRDB システム運用ガイ ド」を参照してください。

2. 追い付き反映処理を中止（pdorend -u コマンド）します。

以降，HiRDB はレプリカ RD エリアで業務を継続することができます。オリジナル RD エリアはデー タ不整合が発生しているため，データを参照しないでください。

3. レプリカ RD エリアで業務を続行したあとに，マスタ DB の修復を行う方法については，表「更新可能

なオンライン再編成の取り消し」を参照してください。

マスタ DB の回復後は，データベースの静止化コマンド（pdorbegin）からオンライン再編成をやり直 せます。

(5)　システムログが上書きされ，追い付き反映できない場合の対策

1. 追い付き反映処理を中止（pdorend -u コマンド）します。

以降，HiRDB はレプリカ RD エリアで業務を継続することができます。オリジナル RD エリアはデー タ不整合が発生しているため，データを参照しないでください。

2. レプリカ RD エリアで業務を続行したあとに，マスタ DB の修復を行う方法については，表「更新可能

なオンライン再編成の取り消し」を参照してください。

マスタ DB の回復後は，データベースの静止化コマンド（pdorbegin）からオンライン再編成をやり直 せます。