Hitachi

ノンストップデータベース HiRDB Version 9 システム定義(Windows(R)用)


9.2.7 HiRDBの処理方式に関するオペランド

◆ pd_dbsync_point = sync|commit

データベースの更新内容をファイルに反映するタイミングを指定します。

sync:

シンクポイント時点でデータベースの更新内容をファイルに反映します。シンクポイント間で同一ページを更新するようなトランザクションが多く起動される場合に性能が向上します。COMMIT文が発行されてもファイルに更新情報を反映しないため,入出力の負荷が軽減されます。ただし,commitを指定したときに比べて全面回復処理が遅くなります。

commit:

COMMIT文発行時点でデータベースの更新内容をファイルに反映します。トランザクションの完了時点でデータベースの内容が保証されるため,シンクポイント時点からデータベースを回復する必要がなく,全面回復処理に要する時間が短縮できます。ただし,シンクポイント間で同一ページを更新するようなトランザクションが多く起動される場合は,syncを指定したときに比べて性能が低下します。

《備考》

LOB用RDエリアはこのオペランドの影響を受けません。ディレクトリ部はCOMMIT文発行時点で反映されます。データ部はLOB用グローバルバッファを割り当てているかどうかによって処理が異なります。LOB用グローバルバッファを割り当てていない場合は更新要求時にすぐに反映されます。LOB用グローバルバッファを割り当てている場合はCOMMIT文発行時点で反映されます。ただし,グローバルバッファが満杯になったときはその時点で反映されます。

《ほかのオペランドとの関連》

このオペランドはpd_system_dbsync_pointオペランドと関連があります。

《各見積もり式への影響》

pd_dbsync_pointオペランドの指定値を変更すると,次の見積もり式に影響があります。

マニュアル「HiRDB Version 9 システム導入・設計ガイド」:

  • 「HiRDB/シングルサーバのメモリ所要量の見積もり」の「メモリ所要量の計算式」

  • 「HiRDB/パラレルサーバのメモリ所要量の見積もり」の「メモリ所要量の計算式」

  • 「シングルサーバが使用する共用メモリの計算式」

  • 「ディクショナリサーバが使用する共用メモリの計算式」

  • 「バックエンドサーバが使用する共用メモリの計算式」

◆ pd_system_dbsync_point = sync|commit

次に示すRDエリアの更新内容をファイルに反映するタイミングを指定します。

  • マスタディレクトリ用RDエリア

  • データディレクトリ用RDエリア

  • データディクショナリ用RDエリア

  • データディクショナリLOB用RDエリア

  • レジストリ用RDエリア

  • レジストリLOB用RDエリア

sync:

シンクポイント時点で前記のRDエリアの更新内容をファイルに反映します。COMMIT文が発行されてもファイルに更新情報を反映しないため,定義系SQLの処理性能がcommitを指定したときに比べて若干向上します。ただし,全面回復処理がcommitを指定したときに比べて遅くなります。

commit:

COMMIT文発行時点で前記のRDエリアの更新内容をファイルに反映します。トランザクションの完了時点で前記のRDエリアの更新内容が保証されるため,前記のRDエリアをシンクポイント時点から回復する必要がなく,全面回復処理に要する時間が短縮できます。ただし,syncを指定したときに比べて,定義系SQLの処理性能が若干低下します。

《ほかのオペランドとの関連》

このオペランドはpd_dbsync_pointオペランドと関連があります。pd_dbsync_pointオペランドとの関連を次に示します。

pd_dbsync_pointオペランドの値

pd_system_dbsync_pointオペランドの値

sync

commit(省略値)

sync(省略値)

全RDエリアの更新内容をシンクポイント時点で反映します。

前記のRDエリアの更新内容はCOMMIT文発行時点で反映します。そのほかのRDエリアの更新内容はシンクポイント時点で反映します。

commit

全RDエリアの更新内容をCOMMIT文発行時点で反映します。

《各見積もり式への影響》

pd_system_dbsync_pointオペランドの指定値を変更すると,次の見積もり式に影響があります。

マニュアル「HiRDB Version 9 システム導入・設計ガイド」:

  • 「シングルサーバが使用する共用メモリの計算式」

  • 「ディクショナリサーバが使用する共用メモリの計算式」

◆ pd_process_terminator = resident|fixed|nonresident

HiRDBのプロセスが異常終了した場合,HiRDBは後処理を実行するプロセス(これを後処理プロセスといいます)を起動して後処理をします。このオペランドでは,後処理プロセスをHiRDBの開始時に起動しておくかどうかを指定します。

resident:

HiRDBの開始時に後処理プロセスを一つ起動します。HiRDB/パラレルサーバの場合は,一つのユニットに一つの後処理プロセスを起動します。

複数のプロセスが同時に異常終了した場合,HiRDBが規定した数まで後処理プロセスを起動して後処理を並列実行します。メモリ不足などで後処理プロセスを新たに起動できない場合は,既に起動している後処理プロセスで後処理を順次実行します。

なお,メモリ不足などによって,HiRDBが規定した数まで後処理プロセスを起動できない場合,HiRDB(HiRDB/パラレルサーバの場合は該当するユニット)が異常終了することがあります。

fixed:

HiRDBの開始時に,pd_process_terminator_maxオペランドで指定した数の後処理プロセスを起動します。HiRDB/パラレルサーバの場合は,ユニットごとにpd_process_terminator_maxオペランドで指定した数の後処理プロセスを起動します。メモリ不足などで後処理プロセスを起動できない場合はHiRDB(HiRDB/パラレルサーバの場合は該当するユニット)を開始しません。

pd_process_terminator_maxオペランドの値を超えるプロセスが同時に異常終了した場合,後処理プロセスを追加起動しません。この場合,既に起動している後処理プロセスで後処理を順次実行します。

nonresident:

HiRDBの開始時に後処理プロセスを起動しません。プロセスが異常終了するたびに後処理プロセスを起動します。

複数のプロセスが同時に異常終了した場合,複数の後処理プロセスを同時に起動して後処理を並列実行します。メモリ不足などで後処理プロセスを起動できない場合,HiRDB(HiRDB/パラレルサーバの場合は該当するユニット)が異常終了することがあります。

《指定値の目安》
  • 信頼性を向上する場合はresident又はfixedを指定します。後処理についての性能面はresidentよりfixedの方が優れていますが,fixedの方がより多くのメモリを必要とします。

  • nonresidentを指定すると,オンデマンドに後処理プロセスが起動されます。このため,メモリ不足が発生すると,後処理プロセスが起動できなくなります。また,プロセスの異常終了が重なった場合,複数の後処理プロセスが起動されるため,性能面でも好ましくありません。

  • 後処理プロセスを起動できない場合に,HiRDBが異常終了することを防止したいときは,fixedの指定を推奨します。

《注意事項》

指定値をfixedに変更する場合は注意が必要です。HiRDBの開始時に後処理プロセスを起動するため,より多くのメモリが必要になります。メモリ不足などで後処理プロセスを起動できない場合はHiRDB(HiRDB/パラレルサーバの場合は該当するユニット)を開始しません。

◆ pd_process_terminator_max = 後処理プロセスの最大常駐数

〜<符号なし整数>((1〜100))《Max(3,↑pd_max_usersの値÷100↑)》

pd_process_terminatorオペランドを省略するか,又はfixedを指定した場合にこのオペランドを指定します。このオペランドには,HiRDBの開始時に起動する後処理プロセスの数を指定します。メモリ不足などで,ここで指定した数の後処理プロセスを起動できない場合は,HiRDB(HiRDB/パラレルサーバの場合は該当するユニット)を開始しません。

《指定値の目安》
  • 必要になる後処理プロセス数は,pd_max_usersの値に比例します。値が小さいと回復処理が遅延するおそれがあり,値が大きいと余分にメモリを消費します。

◆ pd_process_desktopheap_size = 1プロセス当たりのデスクトップヒープ消費量

〜<符号なし整数>((50〜10000))(単位:バイト)《5000》

HiRDBの1プロセス当たりのデスクトップヒープ消費量を指定します。

《指定値の目安》
  • 通常は,このオペランドを指定する必要はありません。

  • HiRDBのデスクトップヒープ消費量は,次の計算式から求めてください。

    HiRDBのデスクトップヒープ消費量=HiRDBが作成するデスクトップ数×デスクトップ1面のデスクトップヒープ消費量※1(単位:バイト)

    HiRDBが作成するデスクトップ数=↑(pd_max_server_processオペランドの指定値+50)÷デスクトップ1面のデスクトップヒープ消費量※1×pd_process_desktopheap_sizeオペランドの指定値↑

    サーバマシン全体のデスクトップヒープの使用量には,上限値※2があります。ほかに起動しているプロセスを含めたデスクトップヒープの合計が上限値※2を超える場合は,次に示す操作を実施してください。

    ・HiRDBのデスクトップヒープ消費量を計算し,pd_max_server_processオペランドの指定値を小さくしてからHiRDBを再起動する

    ・ほかに起動しているプロセスを停止する

    注※1 OSのレジストリに指定されている非対話型デスクトップヒープの使用量です。

    注※2 OSによってデスクトップヒープの上限値は異なります。

◆ pd_pageaccess_mode = SNAPSHOT|NORMAL

データベース検索時のページアクセス方式を指定します。

SNAPSHOT:

ページアクセス方式をスナップショット方式にします。グローバルバッファへの初回アクセス時,探索条件に一致する行をプロセス固有メモリにコピーします。2回目の検索要求時にはプロセス固有メモリを参照して検索結果を返します。スナップショット方式については,マニュアル「HiRDB Version 9 システム導入・設計ガイド」を参照してください。

NORMAL:

ページアクセス方式を通常方式にします。検索要求ごとにグローバルバッファをアクセスします。

《指定値の目安》

グループ分け高速化機能など,性能向上を目的とした機能を使用できない場合に,スナップショット方式の適用を検討してください。通常の検索SQLでは,指定された探索条件に一致する行の数とほぼ同じ回数分だけグローバルバッファへのアクセスを行っています。このため,検索SQLの実行が重なるとグローバルバッファへのアクセスが集中して,期待した性能が得られないことがあります。このような場合にスナップショット方式を適用すると,検索SQLのグローバルバッファへのアクセス回数を削減できるため,検索性能が向上することがあります。ただし,スナップショット方式を適用した場合,HiRDBが使用するプロセス固有メモリが増加します。スナップショット方式を適用した場合のプロセス固有メモリの計算式については,マニュアル「HiRDB Version 9 システム導入・設計ガイド」を参照してください。

《各見積もり式への影響》

pd_pageaccess_modeオペランドの指定値を変更すると,次の見積もり式に影響があります。

マニュアル「HiRDB Version 9 システム導入・設計ガイド」:

  • 「HiRDB/シングルサーバのメモリ所要量の見積もり」の「スナップショット方式指定時に必要なメモリ所要量の求め方」

  • 「HiRDB/パラレルサーバのメモリ所要量の見積もり」の「スナップショット方式指定時に必要なメモリ所要量の求め方」

◆ pd_cmdhold_precheck = Y|N

RDエリアの閉塞状態のチェックをRDエリアの排他処理の前に行うかどうかを指定します。

Y:

RDエリアの閉塞状態のチェックをRDエリアの排他処理の前に行います。

N:

RDエリアの閉塞状態のチェックをRDエリアの排他処理の前に行いません。排他取得後に行います。

チェック対象になる閉塞の種類を次に示します。

  • コマンド閉塞

  • 参照可能閉塞

  • 参照可能バックアップ閉塞

《指定値の目安》

通常はこのオペランドを省略するか,又はYを指定してください。Yを指定したときと,Nを指定したときの違いを次に示します。

項目

Yを指定した場合

Nの場合

HiRDBの処理

UAP又はコマンドの実行時,RDエリアの排他を取得する前に,アクセスする可能性があるすべてのRDエリアの閉塞状態をチェックします。例えば,RDエリア1〜4に横分割されている表にアクセスする場合,RDエリア1〜4の閉塞状態をチェックします。ただし,キーレンジ分割,又はFIXハッシュ分割で条件を指定して,UAP側でアクセスする可能性があるRDエリアを絞り込んでいる場合,アクセスする可能性がないRDエリアが閉塞していてもエラーにはなりません。

UAP又はコマンドの実行時,RDエリアの排他を取得した後に,アクセスする可能性があるすべてのRDエリアの閉塞状態をチェックします。例えば,RDエリア1〜4に横分割されている表にアクセスするとします。インデクスを使用してアクセスするRDエリアを絞り込んだ結果,アクセス対象RDエリアがRDエリア1の場合,RDエリア1に対してだけ閉塞状態をチェックします。これはHiRDB Version 5.0以前の処理方式です。

閉塞中のRDエリアにUAPがアクセスした場合

RDエリアの排他を取得する前に閉塞チェックをするため,RDエリアが閉塞していることを,Nを指定したときよりも早く検知できます。

RDエリアの排他を取得した後に閉塞チェックをするため,閉塞中のRDエリアにUAPがアクセスした場合,RDエリアの排他によるタイムアウトエラー(KFPA11770-E)が発生することがあります。

また,アクセス対象RDエリアがデータロード又は再編成で閉塞中の場合,データロード又は再編成処理の終了後にUAPが閉塞エラー(KFPA11920-E)になることがあります。

非横分割インデクスを使用してアクセスするRDエリアを絞り込む場合

表が横分割されていてインデクスが横分割されていない場合に注意が必要です。非横分割インデクスを使用してアクセス対象RDエリアを絞り込む場合,アクセス対象外のRDエリアが閉塞していても,閉塞エラー(KFPA11920-E)になります。HiRDBの処理で説明した例の場合,RDエリア1〜4のどれかが閉塞していると,UAPが閉塞エラー(KFPA11920-E)になります。

非横分割インデクスを使用してアクセス対象RDエリアを絞り込む場合,アクセス対象外のRDエリアが閉塞していても,UAP又はコマンドを実行できます。HiRDBの処理で説明した例の場合,RDエリア2〜4が閉塞していても,UAPを実行できます。

注※ RDエリアが閉塞状態では実行できないUAP及びコマンドが対象になります。

◆ pd_db_io_error_action = dbhold|unitdown

RDエリア(マスタディレクトリ用RDエリアを除く)の入出力エラーが発生したときのHiRDBの処理を指定します。なお,マスタディレクトリ用RDエリアに入出力エラーが発生した場合,このオペランドの指定に関係なく常にHiRDB(HiRDB/パラレルサーバの場合はユニット)が異常終了します。RDエリアの入出力エラーが発生したときの対処方法については,マニュアル「HiRDB Version 9 システム運用ガイド」を参照してください。

ここでいう入出力エラーとは,HiRDBがファイルを操作したときにHiRDBが判別できない理由でファイル操作に失敗したエラーを意味し,HiRDBファイルシステムに対するアクセス要求から返されるエラーコードに-1544が出力されるエラーのことです。

dbhold:

RDエリアの入出力エラーが発生した場合,そのRDエリアを障害閉塞します。

unitdown:

RDエリアの入出力エラーが発生した場合,HiRDB(HiRDB/パラレルサーバの場合はユニット)を異常終了します。ただし,異常終了後に再度入出力エラーが発生した場合,そのRDエリアを障害閉塞します。再び,unitdownの指定を有効にするには,次に示すどちらかの方法を実行してください。

  • HiRDBを正常開始する

  • システム構成変更コマンド(pdchgconfコマンド)を実行する

《指定値の目安》

マニュアル「HiRDB Version 9 システム運用ガイド」の「RDエリアの入出力エラーが発生したときの対処方法」を参照して,このオペランドの指定値を決めてください。

《注意事項》
  • unitdownを指定したときに入出力エラーが発生するとHiRDBが異常終了するため,次の場合に,処理対象のRDエリアが障害閉塞することがあります。

    ・更新前ログ取得モード又はログレスモードでUAPやユティリティを実行している場合

    ・CREATE TABLEのRECOVERYオペランドでNOを指定してログレスモードにしたユーザLOB用RDエリアに対して,UAP又はユティリティを実行している場合

    物理エラー検知時ユニットダウン機能を使用する場合は,できるだけこれらの運用は避けてください。もし,これらの運用が必要な場合は,RDエリアが閉塞しても最新の状態に回復できるよう,UAP又はユティリティの実行前にバックアップを取得してください。バックアップの取得については,マニュアル「HiRDB Version 9 システム運用ガイド」を参照してください。

  • 開始処理中又は終了処理中の入出力エラーについては,unitdownを指定してもHiRDBを異常終了しません。

  • データベース回復ユティリティ(pdrstr)での回復処理中は,unitdownを指定していてもHiRDBを異常終了しません。この場合は,データベース回復ユティリティ(pdrstr)を再度実行して回復してください。

《ほかのオペランドとの関連》

このオペランドは次に示すオペランドと関連があります。

  • pd_mode_confオペランド

  • pd_db_access_error_actionオペランド

  • pd_db_hold_actionオペランド

なお,pd_db_io_error_actionオペランド,pd_db_access_error_actionオペランド,及びpd_db_hold_actionオペランドのうち,複数のオペランドでunitdownを指定した場合は,次の順序でオペランドの指定値が有効になります。

  1. pd_db_io_error_actionオペランド

  2. pd_db_access_error_actionオペランド

  3. pd_db_hold_actionオペランド

そのため,RDエリアの入出力エラー,ファイルアクセスエラー,及び物理エラーのうち複数のエラーが同時に起こった場合,どのエラー要因によってユニットダウンしたのかは,この優先順位を参考に判断してください。また,出力されたメッセージを参照してください。

◆ pd_connect_errmsg_hide = Y|N

CONNECT失敗時に出力されるメッセージで,エラーの要因を隠すかどうかを指定します。

Y:CONNECT失敗時にエラーの要因を隠します。

N:CONNECT失敗時にエラーの要因を隠しません。

このオペランドの指定値によってCONNECT失敗時に出力されるメッセージが変わることがあります。詳細を次に示します。

エラー要因

出力されるメッセージ

Yを指定した場合

N(省略値)を指定した場合

認可識別子の不正(指定されたユーザは存在しない)

KFPA19632-E

KFPA11561-E

パスワードの不正(指定されたパスワードが一致しない)

KFPA19632-E

KFPA11560-E

◆ pd_rpc_bind_loopback_address = Y|N|S

受信用ポートの生成時,ループバックアドレスでbind()するかどうかを指定します。

Y:

ループバックアドレスでbind()します。

N:

ループバックアドレスでbind()しません。

S:

HiRDBサーバ内のプロセスからだけ接続要求を受け付けるプロセスは,ループバックアドレスでbind()します。HiRDBクライアントから接続要求を受け付けるプロセス(システムマネジャプロセス及びスケジューラプロセス)は,ループバックアドレスでbind()しません。

《前提条件》

このオペランドにYを指定する場合

次に示す条件をすべて満たしている必要があります。

  • HiRDB/シングルサーバだけでHiRDBシステムが構成されているか,又はモニタモードでIPアドレスを引き継ぐ系切り替え機能を使用している

  • pdunitオペランドの-xオプションとクライアント環境定義のPDHOSTオペランドにループバックアドレスを指定している

注※

HiRDB/シングルサーバだけでHiRDBシステムが構成されているとは,次に示す条件を満たすことをいいます。

・HiRDBクライアントとHiRDBサーバが同一マシンにある(HiRDBクライアントが別マシンにない)

このオペランドにSを指定する場合

次に示す条件をすべて満たしている必要があります。

  • HiRDB/シングルサーバである

  • 次のどれかのシステム定義でスケジューラプロセスのポート番号を指定している

    ・pd_scd_portオペランド

    ・pd_service_portオペランド

    ・pdunitオペランドの-sオプション

  • pdunitオペランドの-xオプションにループバックアドレスを指定している

  • HiRDBクライアントがHiRDBサーバとは異なるサーバマシンから接続する場合,高速接続機能を使用し,かつ接続するHiRDBクライアントのクライアント環境定義で次のオペランドを指定している

    ・PDSERVICEGRP

    ・PDSERVICEPORT

    ・PDSRVTYPE=PC

《指定値の目安》

このオペランドの指定値によって,Windowsファイアウォールの例外リストへ登録する内容が次に示すとおり異なります。Y又はSを指定すると,Windowsファイアウォールの例外リストへ登録するHiRDBが使用するポート番号やプログラムをなくす,又は減らすことができます。

pd_rpc_bind_loopback_addressオペランドの指定値

Windowsファイアウォールの例外リストへ登録するHiRDBが使用するポート番号やプログラム

Y

なし

N

HiRDBが使用するすべてのポート番号やプログラム

S

  • ポート番号を登録する場合

    HiRDBのポート番号※1,及びスケジューラプロセスのポート番号※2

  • プログラム名を登録する場合

    %PDDIR%\lib\servers\pdrdmd.exe

    %PDDIR%\lib\servers\pdscdd.exe

注※1

次のどちらかのシステム定義で指定した値です。

  • pd_name_portオペランド

  • pdunitオペランドの-pオプション

注※2

次のどれかのシステム定義で指定した値です。

  • pd_scd_portオペランド

  • pd_service_portオペランド

  • pdunitオペランドの-sオプション

Windowsファイアウォールの例外リストへの登録方法については,マニュアル「HiRDB Version 9 システム導入・設計ガイド」を参照してください。

《ほかのオペランドとの関連》

このオペランドは次に示すオペランドと関連があります。

  • pd_name_port

  • pd_scd_port

  • pd_service_port

  • pdunit -p

  • pdunit -s

  • pdunit -x

  • PDHOST

  • PDSERVICEGRP

  • PDSERVICEPORT

  • PDSRVTYPE=PC

◆ pd_cancel_down_msgchange = Y|N

サーバプロセスの強制終了が発生した場合に,出力されるエラーメッセージを変更するかどうかを指定します。

Y:

エラーメッセージを警告メッセージに変更します。エラーメッセージを変更する機能をトランザクションキャンセル時のプロセスダウンメッセージ変更機能といいます。

N:

エラーメッセージを変更しません。

このオペランドの指定値と出力されるエラーメッセージの関係を次に示します。

条件

出力されるメッセージ

Y(省略値)を指定した場合

Nを指定した場合

次に示す原因によってサーバプロセスの強制終了が発生した場合

  • ユーザ操作による意図的な強制終了

  • タイムアウトによる強制終了

  • クライアント側の障害による強制終了

  • KFPS01852-W

  • KFPO00115-W

  • KFPS01820-E

  • KFPO00105-E

上記以外の原因によってサーバプロセスの強制終了が発生した場合

  • KFPS01820-E

  • KFPO00105-E

サーバプロセスの強制終了の原因をHiRDBが判断できない場合

注※

メッセージの変更が発生する原因はほかにもあります。詳細については,マニュアル「HiRDB Version 9 システム運用ガイド」の「トランザクションキャンセル時のプロセスダウンメッセージ変更機能」を参照してください。

《利点》

このオペランドにYを指定すると,サーバプロセスの強制終了が発生した原因で出力されるメッセージを切り分けられます。

《備考》

KFPS01820-E及びKFPO00105-Eメッセージが出力された場合,その原因がHiRDBの不正検知によるものか,又はトランザクションキャンセルなどのユーザ操作による意図的なものかをメッセージIDから判断できません。判断するには,各メッセージに出力されるプロセスIDを比較する必要があります。

JP1を使用してメッセージを監視している場合,複数のメッセージ情報を比較できないため,KFPS01820-E及びKFPO00105-Eメッセージが出力されたときに対処が難しくなることがあります。このオペランドにYを指定すると,出力されるメッセージがエラー原因によって切り分けられるため,対処が特定しやすくなります。したがって,JP1を使用してメッセージを監視している場合,このオペランドにYを指定することをお勧めします。