付録A.2　シンクポイントダンプファイルに関する質問

KFPS02179-Iメッセージ（シンクポイントダンプの取得契機を迎えたが，以前のシンクポイントダンプ取得処理が完了していないため，取得契機を無視した）が多発していますが，問題ありませんか？

このメッセージは，次の場合に出力されます。

• システムログファイルのスワップ間隔が短い

• シンクポイントダンプの取得間隔に対して，UAPのトランザクションの実行時間が長い

• デファードライト処理によってシンクポイントダンプの取得が遅延している

このメッセージが頻繁に出力される場合は，factor codeによって次の対処を行ってください。

• factor code = A01-01の場合

  「デファードライト処理適用時のシンクポイント処理時間のチューニング」に従って対策してください。

• factor code = A01-02の場合

  前回のシンクポイントダンプ取得時に未決着状態だったトランザクションがまだ決着していません。シンクポイントダンプの取得間隔に対してUAPのトランザクションが長いことが原因です。続いて出力されるKFPS04374-Iメッセージに従って対策してください。対策後もこのメッセージが出力される場合は，「上記以外の場合」に従って対策してください。

• 上記以外の場合

  pd_log_sdintervalオペランドの値を大きくしてください。又は，システムログファイルの容量を大きくするなどの対策を実施してください。それでも頻繁にこのメッセージが出力される場合は，UAPを見直して，実行時間が長いトランザクションを複数のトランザクションに分割し，1トランザクション当たりの実行時間を短くできないか検討してください。

なお，このメッセージが出力されても，スワップ先にできる状態のシステムログファイルが十分に用意してある場合は，オンラインの続行，及び再開始に支障はありません。ただし，HiRDBの再開始に時間が掛かることがあります。システムログファイルの数及び容量が十分でない場合は，上書きできる状態のファイルがなくなり（KFPS01256-Eメッセージが出力される），HiRDB又はユニットが異常終了することがあります。次に示す見直しをしてこのようなトラブルを防いでください。

データベースやディクショナリを更新してからコミットするまでの時間が長いトランザクションの場合

対策案を次に示します。

• 途中でCOMMIT文を発行できないか検討してください。

• 更新後に大量検索をするトランザクションは，更新と大量検索の順番を入れ替えて，トランザクション内の最初の更新からコミットまでを短くできないか検討してください。

システムログファイルの数及び容量が十分でない場合

対策案を次に示します。

• 出力されるシステムログをすべて格納できるだけの総ファイル容量を用意することをお勧めします。無理な場合は，少なくともマニュアル「HiRDB システム導入・設計ガイド」に記載してある最低容量以上は確保するようにしてください。

• 大量更新するトランザクションにはデータベースの更新ログを取得しないようにします。データベースの更新ログを取得するかどうかは，クライアント環境定義のPDDBLOGオペランドで指定します。ただし，データベースの更新ログを取得しない場合は，UAP実行時に障害が発生すると，バックアップ取得時点にしかデータベースを回復できないため注意してください。

シンクポイントダンプファイルの有効保証世代数とは何のことでしょうか？

HiRDBの再開始に備えてシステムログファイルをどの位置から読み始めればよいかなどの情報がシンクポイントダンプファイルに格納されています。シンクポイントダンプファイルに格納した位置情報以降のシステムログファイルは再開始時に使用される可能性があるため，上書きできない状態にします。

有効保証世代数とは，「何世代前のシンクポイントダンプファイルに対応するシステムログファイルを上書きできない状態にして保護するか」ということです。例えば，有効保証世代数が1の場合は，最新のシンクポイントダンプファイルに対応するシステムログファイルが上書きできない状態になります。有効保証世代数が2の場合は，最新のシンクポイントダンプファイル及び1世代前のシンクポイントダンプファイルに対応するシステムログファイルが上書きできない状態になります。このように有効保証世代数を2にすると，上書きできない状態のシステムログファイルが増える可能性があります。

シンクポイントダンプファイルの有効保証世代数はpd_spd_assurance_countオペランドで指定します。