26.5.2　HiRDBに関する準備

(a)　共有ディスクの割り当て

共有ディスクの割り当てを次の図に示します。

図26‒87　共有ディスクの割り当て

〔説明〕

サーバ単位の切り替えのためサーバごとに共有ディスクを割り当てます。複数のサーバに関する情報を一つの共有ディスクに配置することはできません。

共有ディスク装置には次に示すHiRDBファイルシステム領域を作成します。

• RDエリア用のHiRDBファイルシステム領域

• システムファイル用のHiRDBファイルシステム領域

• バックアップファイル用のHiRDBファイルシステム領域

• アンロードログファイル用のHiRDBファイルシステム領域

• インデクス情報ファイル用HiRDBファイルシステム領域（プラグインインデクス遅延一括作成機能を使用する場合）

注意事項

• これらのHiRDBファイルシステム領域は両方（現用系及び予備系）のHiRDBから同じパス名で参照できるように設定してください。また，HAグループ内のすべてのユニットから同一パス名で参照できるように設定してください。ただし，ユニットステータスファイルはサーバステータスファイル，システムログファイル，シンクポイントダンプファイルと異なる独立した非共有ディスクに作成してください。

• 共用RDエリア用HiRDBファイルシステム領域を作成した共有ディスクは全ユニットから読み書きモードでアクティブにしておく必要があります。このため，系切り替え機能に伴って非アクティブ化，及びアクティブ化をしてはなりません。

• 通常ファイルでは，ディスクに反映されない状態（例えば，HiRDBで書き込み完了していても，OSキャッシュ上に残っている状態など）で系が切り替わると，更新内容が失われることがあるため，キャラクタ型スペシャルファイルを推奨します。ただし，系切り替えが発生してもOSがデータを保証する通常ファイル（ジャーナルファイルシステム）であれば，次に示すファイルを共有ディスク上に配置してもかまいません。

  ・pdlogunldコマンド又は自動ログアンロード機能でアンロードするアンロードログファイル

  ・データベース複写ユティリティ（pdcopy）で取得するバックアップファイル

  ・データベース再編成ユティリティ（pdrorg）で作成するアンロードデータファイル

(b)　共有ディスクのアクセス制御

系切り替え機能を使用する場合，系の切り替え元と切り替え先の両方から同時に共有ディスクにアクセスが行われると，データベースが壊れる可能性があります。そのため，両方の系から共有ディスクをアクセスできないように制御を行う必要があります。共有ディスクのアクセス制御は，クラスタソフトウェアが行うか，又はHiRDBが行います。

なお，通常は，「クラスタソフトウェアによる共有ディスクのアクセス制御」の方法で共有ディスクのアクセス制御を行います。「HiRDBによる共有ディスクのアクセス制御」の方法は，HAモニタ 01-08以降が前提条件になります。

クラスタソフトウェアによる共有ディスクのアクセス制御

クラスタソフトウェアが共有ディスクのアクセス制御を行います。実行系をアクティブに，待機系及び停止中の系を非アクティブに制御し，実行系だけが共有ディスクにアクセスできるようにします。クラスタソフトウェアによる共有ディスクのアクセス制御を次の図に示します。

図26‒88　クラスタソフトウェアによる共有ディスクのアクセス制御

〔説明〕

非アクティブの系からは共有ディスクをアクセスできません。そのため，実行系だけが共有ディスクにアクセスできます。

共有ディスクの切り替え方法（アクティブ，非アクティブの切り替え方法）については，クラスタソフトウェアのマニュアルを参照してください。

なお，HAモニタを使用している場合は，HAモニタのserver定義文のdiskオペランドを指定してください。

HiRDBによる共有ディスクのアクセス制御

HiRDBによる共有ディスクのアクセス制御は，HAモニタ 01-08以降が前提条件になります。

HiRDBが共有ディスクのアクセス制御を行います。この場合，共有ディスクの切り替え（アクティブ，非アクティブの切り替え）は行いません。次に示す流れで系が切り替わります。

1. 系が切り替わる障害が発生しました。

2. 切り替え元の系ですべてのサーバプロセスが終了したことをHiRDBが確認します。

3. 系が切り替わります。

4. 切り替え先の系から共有ディスクへのアクセスを開始します。

HiRDBによる共有ディスクのアクセス制御を次の図に示します。

図26‒89　HiRDBによる共有ディスクのアクセス制御

• 適用基準

  次に示す場合にHiRDBによる共有ディスクのアクセス制御を行ってください。

  • 共用RDエリアを使用する場合

    共用RDエリアを使用する場合，バックエンドサーバがあるすべてのサーバマシンから，共用RDエリアがある共有ディスクをアクティブにする必要があります。そのため，更新可能BESと参照専用BESが同一サーバマシンにある場合に，更新可能BESが系切り替え対象となり，共有ディスクの切り替えが発生すると，参照専用BESから共用RDエリアが参照できなくなります。そのため，「クラスタソフトウェアによる共有ディスクのアクセス制御」の方法が使用できません。

  • ログ同期方式のリアルタイムSANレプリケーションを使用する場合

    ログ同期方式のリアルタイムSANレプリケーションを使用する場合，ログ適用サイトにTrueCopyを使用してシステムファイルをリモートコピーします。TrueCopyを使用する場合はLVMを使用できませんが，HAモニタがアクセス制御できる共有ディスクはLVMを前提としているため，「クラスタソフトウェアによる共有ディスクのアクセス制御」の方法が使用できません。

• HiRDBの環境設定

  HiRDBシステム定義に次に示すオペランドを指定してください。

  • pd_ha_prc_cleanup_check = Y

    このオペランドにYを指定すると，ユニット内の全サーバプロセスの終了後に系を切り替えます。影響分散スタンバイレス型系切り替え機能の場合は，バックエンドサーバ内の全サーバプロセスの終了後に系を切り替えます。

  • pd_ha_switch_timeout = Y

    ディスクへの入出力処理中などが原因で，サーバプロセスが終了しないために系を切り替えられないことがあります。このオペランドにYを指定すると，このような場合に，HAモニタがサーバ（HiRDB）のスローダウンとして系をリセットし，系を切り替えられます。

• HAモニタの環境設定

  HAモニタのserver定義文に次に示すオペランドを指定してください。

  • pairdown

    このオペランドにuse：serv_slowを指定してください。

    系の切り替え元でサーバプロセスが終了しない場合や，HiRDBがスローダウンした場合など，サーバプロセスの終了が確認できないことがあります。このような現象が発生すると，系を切り替えられません。このオペランドを指定すると，スローダウンなどによってサーバプロセスの終了を確認できない場合に，系をリセットして系を切り替えられます。

  • disk

    HAモニタで共有ディスクのアクセス制御をしないため，このオペランドを省略してください。

(a)　HiRDBシステム定義ファイルの構成

影響分散スタンバイレス型系切り替え使用時のシステム定義ファイルの運用方法を次の表に示します。

表26‒37　影響分散スタンバイレス型系切り替え使用時のシステム定義ファイルの運用方法

定義種別	定義ファイルの運用方法
システム共通定義	システム内全ユニットにファイルをコピーします。 バックエンドサーバ定義のデフォルト値として設定するパラメタは，システム共通定義に記述してください。
ユニット制御情報定義	次のオペランド（システム共通定義に記述できないオペランド）だけを記述してください。 pd_aud_file_name※ pd_down_watch_proc pd_unit_id pd_hostname pd_ha_unit pd_rpl_hdepath pd_ha_acttype pd_ha_agent pd_ha_max_act_guest_servers pd_ha_max_server_process pd_ha_resource_act_wait_time pd_ha_process_count pd_lck_deadlock_check pd_lck_deadlock_check_interval pd_prf_file_count pd_prf_file_size pd_prf_level pd_prf_output_directory pd_rpc_trace_name※ pd_registered_port※ pd_service_port pd_syssts_file_name_1〜7 pd_syssts_subfile_name_1〜7 pd_syssts_initial_error pd_syssts_last_active_file pd_syssts_last_active_subfile pd_syssts_last_active_side pd_syssts_last_active_side_sub pd_syssts_singleoperation pd_tmp_directory pd_trn_rcvmsg_store_buflen 上記以外のオペランドはシステム共通定義，又はバックエンドサーバ定義に記述してください。上記以外のオペランドを記述した場合は，エラーとなります（メッセージKFPS05618-Eを出力します）。
サーバ共通定義	HAグループ内全ユニットにファイルをコピーします。
バックエンドサーバ定義	HAグループ内全ユニットにファイルをコピーします。

注※

同一サーバマシンに複数のユニットを配置する場合，このオペランドには，ユニットごとに異なる値を指定してください。

(b)　影響分散スタンバイレス型系切り替えの場合に設定するHiRDBシステム定義のオペランド

ここでは，影響分散スタンバイレス型系切り替えを使用した場合に設定するHiRDBシステム定義のオペランドについて説明します。関連するオペランドを次の表に示します。

表26‒38　影響分散スタンバイレス型系切り替えの場合に設定するHiRDBシステム定義のオペランド

オペランド名		説明及び注意事項
pd_ha		系切り替え機能を使用する場合に指定します。
pd_ha_unit		ユニットに系切り替え機能を適用している場合は指定しないでください。 システム内で系切り替え機能を適用しないユニットがある場合，又はシステム内に回復不要FESユニットがある場合は，そのユニットのユニット制御情報定義のpd_ha_unitオペランドにnouseを指定します。
pd_ha_acttype		系切り替え機能をモニタモードで運用するか，サーバモードで運用するかを指定します。 monitor：系切り替え機能をモニタモードで運用します。 server：系切り替え機能をサーバモードで運用します。 サーバモードを使用する場合は，serverを指定してください。
pd_ha_agent		影響分散スタンバイレス型系切り替え機能を使用する場合は，activeunitsを指定します。
pd_ha_transaction pd_ha_trn_queuing_wait_time pd_ha_trn_restart_retry_time		トランザクションキューイング機能を使用する場合に指定します。 pd_ha_transactionオペランドにqueuingを指定した場合，系の切り替え中に最大同時接続数（pd_max_usersオペランドの値）を超えたときに，HiRDBサーバへの接続処理をpd_ha_trn_queuing_wait_time＋pd_ha_trn_restart_retry_timeの時間だけHiRDBクライアントでリトライします。
pd_ha_switch_timeout		このオペランドはサーバモードの場合に指定できます。モニタモードの場合にこのオペランドを指定しても無効になります。 系切り替え時のユニットの内部停止処理がサーバ障害監視時間を超えた場合に，HiRDBの内部停止処理を待たないで系を切り替えるかどうかを指定します。ここでいうサーバ障害監視時間とは，HAモニタ又はHitachi HA Toolkit Extensionのpatrolオペランドに指定した時間のことです。 HAモニタのpatrolオペランドについては，マニュアル「高信頼化システム監視機能 HAモニタ」を参照してください。Hitachi HA Toolkit Extensionのpatrolオペランドについては，マニュアル「Hitachi HA Toolkit」を参照してください。 Y：系切り替え時のHiRDBの内部停止処理がサーバ障害監視時間を超えた場合，HiRDBの内部停止処理を待たないで系を切り替えます。このとき，HiRDBのスローダウンとして系を切り替えます。 N：系切り替え時のHiRDBの内部停止処理が終わるまで系を切り替えません。
pd_ha_prc_cleanup_check		サーバプロセスが終了するまで系の切り替え処理を待ち合わせるかどうかを指定します。詳細については，「共有ディスクのアクセス制御」を参照してください。
pd_mode_conf		HiRDB（ユニット）の開始方法に関するオペランドです。指定値の目安を次に示します。 サーバモードの場合は次のように指定してください。 HAモニタ又はHitachi HA Toolkit Extensionのserver定義文のswtichtypeオペランドにswitchを指定した場合は，MANUAL2を指定してください。 HAモニタ又はHitachi HA Toolkit Extensionのserver定義文のswtichtypeオペランドにrestart又はmanualを指定した場合は，MANUAL1を指定してください。
pd_hostname		ユニットの標準ホスト名を指定します（系切り替え機能を使用しない場合と同じです）。
pdunit	-x	ユニットのホスト名を指定します（系切り替え機能を使用しない場合と同じです）。
	-u	ユニット識別子を指定します。
	-d	HiRDB運用ディレクトリ名を指定します。HAグループ内の全ユニットで同じディレクトリ名を指定してください。
	-p	HiRDBのポート番号を指定します。HAグループ内の全ユニットで同じポート番号を指定してください。
	-s	スケジューラのポート番号を指定します。HAグループ内の全ユニットで同じポート番号を指定してください。
	-t	トランザクションサーバのポート番号を指定します。HAグループ内の全ユニットで同じポート番号を指定してください。
pdstart	-g	サーバの移動先となるユニットの集合であるHAグループの識別子を指定します。
pdbuffer	-c	代替中に代替部が使用するグローバルバッファを割り当てる場合にこのオプションを指定します。「グローバルバッファの定義（影響分散スタンバイレス型系切り替え機能の場合）」を参照してください。
pdhagroup	-g	サーバの切り替え先となるユニットの集合としてHAグループを定義します。システム内でHAグループを一意に識別するための識別子を指定します。
	-u	HAグループを構成するユニットのユニット識別子を指定します。
pd_ha_max_act_guest_servers		該当ユニット内で同時に実行系として稼働できるゲストBES数の最大値を指定します。
pd_ha_max_server_process		該当ユニット内の最大起動ユーザサーバプロセス数を指定します。
pd_ha_resource_act_wait_time		ユニットを開始するときに，実行系サーバのリソースが活性化されるまでの最大待ち時間を指定します。
pd_service_port		同一サーバマシン内複数ユニット構成の場合にこのオペランドを指定するときは注意が必要です。同一サーバマシン内複数ユニット構成の場合，このオペランドはユニット制御情報定義でユニットごとに別々のポート番号を指定してください。 次に示す指定をした場合は，ユニットの起動に失敗します。 システム共通定義のpd_service_portオペランドを指定した（ユニット制御情報定義のpd_service_portオペランドは指定していない） ユニット制御情報定義のpd_service_portオペランドに，ほかのユニット制御情報定義のpd_service_portオペランドと同じポート番号を指定した

(c)　切り替え先の指定

影響分散スタンバイレス型系切り替え機能では，ほかの系切り替え機能とは異なり，切り替え先の定義方法が大きく異なります。

受け入れユニット

影響分散スタンバイレス型系切り替え機能では，切り替え単位がサーバのためサーバごとに切り替え先を指定する必要があります。サーバは複数の受け入れユニットを指定できます。複数の受け入れユニットはHAグループとして定義します。各サーバの切り替え先にはHAグループを指定します。

また，影響分散スタンバイレス型系切り替え機能では，ユニットごとに同時に稼働できるゲストBES数の最大値（pd_ha_max_act_guest_servers）を指定できます。

HAグループの構成例を次の図に示します。

図26‒90　HAグループの構成例（その1）

pdhagroup -g hag1 -u unt1,unt2,unt3,unt4
 
pdstart -t BES -s bes1A -u unt1 -g hag1
pdstart -t BES -s bes1B -u unt1 -g hag1
pdstart -t BES -s bes1C -u unt1 -g hag1
pdstart -t BES -s bes2A -u unt2 -g hag1
pdstart -t BES -s bes2B -u unt2 -g hag1
pdstart -t BES -s bes2C -u unt2 -g hag1
pdstart -t BES -s bes2D -u unt2 -g hag1
pdstart -t BES -s bes3A -u unt3 -g hag1
pdstart -t BES -s bes3B -u unt3 -g hag1
pdstart -t BES -s bes3C -u unt3 -g hag1
pdstart -t BES -s bes4A -u unt4 -g hag1
pdstart -t BES -s bes4B -u unt4 -g hag1

図26‒91　HAグループの構成例（その2）

pdhagroup  -g hag1 -u unt1,unt2
pdhagroup  -g hag2 -u unt3,unt4
 
pdstart -t BES -s bes1A -u unt1 -g hag1
pdstart -t BES -s bes1B -u unt1 -g hag1
pdstart -t BES -s bes1C -u unt1 -g hag1
pdstart -t BES -s bes2A -u unt2 -g hag1
pdstart -t BES -s bes2B -u unt2 -g hag1
pdstart -t BES -s bes2C -u unt2 -g hag1
pdstart -t BES -s bes2D -u unt2 -g hag1
pdstart -t BES -s bes3A -u unt3 -g hag2
pdstart -t BES -s bes3B -u unt3 -g hag2
pdstart -t BES -s bes3C -u unt3 -g hag2
pdstart -t BES -s bes4A -u unt4 -g hag2
pdstart -t BES -s bes4B -u unt4 -g hag2

HAグループ定義

HiRDBシステム定義のpdhagroup の-gオプションにHAグループ名を指定し，-uオプションにHAグループを構成するユニットのユニット識別子を指定します。

（例）

pdhagroup  -g hag1 -u unt1,unt2　　　…1.
pdhagroup  -g hag2 -u unt3,unt4　　　…2.

1. unt1及びunt2で構成するHAグループhag1を定義します。

2. unt3及びunt4で構成するHAグループhag2を定義します。

HAグループには次の制限があります。

• HAグループ内のユニット数は32までです。

• HAグループ内のユニットはすべて同一のネットワークセグメント内に配置してください。

• HAグループ内のユニットに定義できるホストBES数とゲストBES領域数（＝最大アクティブゲストBES数）の合計は34までです。

HAグループを構成するユニットは次の条件をすべて満たさなければなりません。

1. ホストBESがないユニット（受け入れ専用ユニット）は，HAグループに属せません。

2. このため，HAグループに属するユニットには，一つ以上のホストBESがなければなりません。

3. HAグループに属するユニットを構成するサーバはバックエンドサーバだけです。このため，サーバ種別が「BES」以外のサーバはあってはなりません。

4. HAグループに属するユニットには影響分散スタンバイレス型系切り替え以外の系切り替えを適用できません。このため，HAグループに属するユニットでは，pd_ha_agentに「activeunits」以外の値は設定できません。

5. HAグループに属するユニットは，複数のHAグループに属することはできません。

受け入れユニットの指定方法

HiRDBのシステム定義でpdstartの-gオプションに受け入れユニットの属するHAグループを指定します。

影響分散スタンバイレス型系切り替えを適用したユニットに属するすべてのサーバに対して-gオプションを指定しなければなりません。

（例）pdstart -t BES -s bes1A -u unt1 -g hag1

unt1，又はbes1異常終了時，bes1の処理はHAグループhag1に属するユニットが受け入れます。

-gオプションを指定する場合の注意事項を次に示します。

1. 正規ユニット及び受け入れユニットを構成するサーバはバックエンドサーバだけです。

   ・-tオプションに「BES」が指定されていなければなりません。

   ・-gオプションで指定したHAグループに属するユニットにも，サーバ種別が「BES」以外のサーバがあってはなりません。

2. 正規ユニットを構成するサーバの数と受け入れユニットを構成するサーバの数が同じ必要はありません。

   ・-uオプションで指定したユニット（正規ユニット）のサーバの数と-gオプションで指定したHAグループに属するユニット（受け入れユニット）のサーバの数が同じ必要はありません。

同時稼働ゲストBES数最大値の指定

ユニット制御情報定義のpd_ha_max_act_guest_serversオペランドに，ユニット内で同時に実行系として稼働できるゲストBES数の最大値を指定します。この指定によって，ゲストBES用のリソース所要量を削減できます。また，過剰な負荷の上昇を抑えられます。

（例） pd_ha_max_act_guest_servers = 2

pd_ha_max_act_guest_serversオペランドの上限値は，HAグループ内のサーバ数から自ユニット内サーバ数を引いた値です。この上限値以上の値を指定しても，pd_ha_max_act_guest_serversオペランドには上限値が設定されます。ホストBESの数とpd_ha_max_act_guest_serversオペランドの値の合計は34に制限されます。

ユニット内の受け入れ可能状態ゲストBESの数は制限しません。ただし，ユニット内で実行系として稼働しているゲストBES数がpd_ha_max_act_guest_serversオペランドに指定した値に達すると，すべての非稼働中のゲストBESについて受け入れ可能状態を解除します。

また，HAグループ内の障害BES数がHAグループ内の稼働中ユニットの空きゲスト用領域数の合計を超えると，障害によって一部のサーバの処理が停止します。

(d)　系切り替え後のサーバプロセスの割り当て

影響分散スタンバイレス型系切り替えでの系切り替え後の受け入れユニットでは，実行中ゲストサーバ数がpd_ha_max_act_guest_serversオペランドの値になるまでゲストサーバを受け入れできます。

受け入れユニットではホストBES，ゲストBESがそれぞれ独自の最大起動プロセス数（pd_max_bes_processオペランドの値）の範囲でサーバプロセスを起動しますが，そのほかにユニット内のサーバプロセス数合計値がpd_ha_max_server_processオペランドに制限されます。この結果，受け入れユニットの過剰な負荷上昇を抑止できます。ただし，系切り替え発生後に同時に処理できるサービス要求数の上限が制限されることがありますので注意が必要です。系切り替え発生後のユニットの負荷上昇，及び同時に処理できるサービス要求数の両方を考慮してpd_ha_max_server_processオペランドを設定してください。

また，系切り替え発生前の状態でホストBESの常駐プロセス数（pd_process_countオペランドの値）に余裕があり，サービス要求処理中でないプロセスが常駐している状態では，系切り替え発生後にサービス要求処理中でない常駐プロセスをゲストBESの処理に利用できるため，処理性能が向上します。一方で，常駐プロセス数を必要以上に大きくすると，非サービス要求処理中プロセスによってサーバプロセス数がpd_ha_max_server_processオペランドの値に達し，ほかのサーバで起動済みサーバプロセス数がpd_max_bes_processオペランドの値に満たない状態でも追加のサービス要求処理ができないことがあります。一般に，ユニット内の常駐プロセス数の合計と最大実行プロセス数の合計の比率はゲストサーバ受け入れ前後で同じにすることを推奨します。この目的で，ゲストサーバを受け入れた後のユニット内の常駐プロセス数の合計をpd_ha_process_countオペランドで制限します。実際の常駐プロセス数は，pd_ha_process_countオペランドをユニットで実行中サーバのpd_process_countオペランドで比例配分した数とpd_process_countオペランドの小さい方となります。

サーバプロセス数に関連するオペランドの意味を次に示します。

• pd_ha_max_act_guest_servers：受け入れ可能なゲストBES数

• pd_ha_max_server_process：ゲストBESとホストBESの実行プロセス数の合計値の上限

• pd_ha_process_count：ゲストBESとホストBESの常駐プロセス数の合計値の上限

影響分散スタンバイレス型系切り替えでの系切り替え発生後のサーバプロセス割り当て（その1）を次の図に示します。

図26‒92　影響分散スタンバイレス型系切り替えでの系切り替え発生後のサーバプロセス割り当て（その1）

系切り替え発生前はホストBES（bes1,bes2）はそれぞれのpd_max_bes_processオペランドの値まで同時に処理できます。また，それぞれのpd_process_countオペランドの値までサーバプロセスを常駐します。

系切り替えが発生するとホストBES（bes1,bes2）の常駐プロセスを流用してゲストBES（bes3）のサーバプロセスを用意します。このため，ゲストBES（bes3）用のサーバプロセスを起動する必要がなく，切り替え後すぐにゲストBES（bes3）の処理が開始できます。また，系切り替え発生前にゲストBES（bes3）用のサーバプロセスを待機起動する必要もありません。

各サーバは必要に応じてそれぞれのpd_max_bes_processオペランドの値までバックエンドサーバプロセスを起動しますが，ユニット内のサーバプロセスの総計はpd_ha_max_server_processオペランドの値に制限されます。

また，常駐プロセス数の総数がユニット内でpd_ha_process_countオペランドの値となるよう，各サーバの常駐プロセスが調整されます。調整後の各サーバの常駐プロセス数は各サーバのpd_process_countオペランドの比率を保つよう，pd_ha_process_countオペランドの値を比例配分します。

影響分散スタンバイレス型系切り替えでの系切り替え発生後のサーバプロセス割り当て（その2）を次の図に示します。

図26‒93　影響分散スタンバイレス型系切り替えでの系切り替え発生後のサーバプロセス割り当て（その2）

系切り替え後，ゲストBES（bes3）受け入れ中は，ユニット内のバックエンドサーバプロセス数がpd_ha_max_server_processオペランドの範囲で，必要に応じてホストBES（bes1,bes2），及びゲストBES（bes3）のバックエンドサーバプロセスを起動します。

特定のホストBES（例えばbes1）への処理要求が特に多い場合は，該当ホストBES（bes1）のpd_max_bes_processオペランドの値まで同時に処理できます。ただし，その分，他サーバ（例えばbes3）の同時要求処理数が少なくなります。

(a)　ユニット単位のグローバルバッファ設計手順

最初に，共用化設計とするか非共用化設計とするかを選択します。系切り替えで縮退する場合のグローバルバッファ設計には次の考え方があります。

1. 共用化設計

   縮退時，受け入れユニットのグローバルバッファ資源を共用することでメモリを有効に利用します。これを共用化設計といいます。共用化設計には次の特徴があります。

   • メリット：縮退時には受け入れユニットのグローバルバッファ資源を共用利用するのでメモリ効率が良い

   • デメリット：縮退時，共用するサーバ数に対応してバッファヒット率は低下する

2. 非共用化設計

   縮退時にだけ使用するグローバルバッファ資源を受け入れユニットに確保しておき，切り替え時はそれを使用します。これを非共用化設計といいます。非共用化設計には次の特徴があります。

   • メリット：縮退時も縮退前と同じバッファ資源数を使用できるのでヒット率を維持できる

   • デメリット：縮退時用のグローバルバッファ資源を受け入れユニットすべてに確保するため，メモリ効率が悪い

影響分散スタンバイレス型系切り替え機能の目的はリソース共有，負荷分散にあるため，「1.　共用化設計」をお勧めします。メモリを効率的に利用できるからです。

非共用化設計の場合，受け入れユニットすべてにサーバ専用のグローバルバッファを確保します。そのため，HAグループ全体で，通常のグローバルバッファ用の共用メモリ見積もり値を，HAグループを構成するユニット数で乗算した分のグローバルバッファ用共用メモリ量が必要となります。見積もりを満足する共用メモリがあれば縮退時にも性能を維持できるため，「2.　非共用化設計」を選んでください。

共用化設計の手順

ここではグローバルバッファの共用を行う場合の設計手順について説明します。

1. 同じバッファプールを共用するRDエリアの決定

   • 同じ種類のRDエリア同士で共用する

     データ格納RDエリア，インデクス格納RDエリア，LOB用RDエリアなど，同じ種類のRDエリアをpdbufferの-rオプションで指定し，共用するようにします。このとき同じページサイズのRDエリア，又は同じアクセス頻度のRDエリアで共用するとメモリ効率が良くなります。

   • 横分割した表，又はインデクスのRDエリアで共用する

     横分割した表格納RDエリア，又は横分割したインデクスのインデクス格納RDエリアをpdbufferの-rオプションで指定して共用するようにします。横分割した表とインデクスが同じRDエリアに格納されている場合はpdbuffer -iオプションを指定してインデクス専用バッファを割り当てます。

   また，共用を組むRDエリアのサーバ配置，及びユニット配置によって次の特長が得られます。特長を参考にして共用するRDエリアを選択してください。

   • 異なるユニットに配置されたサーバのRDエリアを共用した場合

     縮退前はグローバルバッファを占有して使用できるので縮退前の性能を重視した割り当てができます。ただし，縮退時のグローバルバッファ資源割り当てがユニット間で不均衡となります。

   • 同一ユニットに配置されたサーバのRDエリア，及び異なるユニットに配置されたサーバのRDエリアで共用した場合

     縮退時のバッファ割り当てをユニット間で均等とする設計ができます。

2. 共用するグローバルバッファのバッファ面数の決定

   -nオプションで指定するバッファ面数は，共用するHAグループのサーバ間で均等に分配して使用します。そのためバッファ面数が不足しないように共用するサーバ数に見合ったバッファ面数を設定する必要があります。次の式を目安にバッファ面数を決定してください。

   １サーバでの必要面数×（ホストBES数＋ゲストBES数）

なお，縮退時も縮退前のバッファ性能を必用とするRDエリアがある場合には，そのRDエリアだけは次に示す「非共用化設計の手順」を参考にサーバ専用のグローバルバッファを割り当ててください。

非共用化設計の手順

ここではグローバルバッファの共用をしない場合の設計手順について説明します。

サーバ専用のグローバルバッファは一つのRDエリアに対して割り当てる方法と，同じサーバに属する複数のRDエリアに割り当てる方法があります。

• 一つのRDエリア専用に割り当てる場合

  pdbufferの-rオプションに一つのRDエリアを指定します。ほかのRDエリアとの競合がないので最も性能を重視した割り当てができます。なお，pdbufferの-iオプションに非分割インデクスを指定して，インデクス専用バッファを割り当てても同じ効果が得られます。

• 同じサーバに属する複数のRDエリアに割り当てる場合

  pdbufferの-rオプションに同じサーバに属する複数のRDエリアを指定します。指定するRDエリアの種類はデータ格納RDエリア，インデクス格納RDエリア，LOB用RDエリアなど，同じ種類のRDエリアを指定してください。

(b)　RDエリア用，及びLOB用グローバルバッファの割り当て（-rオプション又は-bオプション指定）

RDエリア用，及びLOB用のユニット単位のグローバルバッファの割り当ては，指定するRDエリアの組み合わせによって，4種類に分類されます。グローバルバッファの共用形態別の推奨条件（-rオプション又は-bオプション指定）を次の表に示します。

表26‒39　グローバルバッファの共用形態別の推奨条件（-rオプション又は-bオプション指定）

指定方法（-r又は-bで指定したRDエリアの組み合わせ）			バッファ共用形態	メリット	推奨条件
異なるサーバのRDエリア	同じユニットのRDエリア	異なるユニットのRDエリア
なし	なし	なし	非共用	他サーバと共用しないため，多重障害時でも定常時のバッファ性能を維持できる	すべての受け入れユニットにバッファを確保するためメモリに余裕がある環境で，縮退時も縮退前のバッファ性能を維持したいRDエリアに対する適用をお勧めします。
あり	あり	なし	ユニット内サーバ共用	多重障害でも定常時のバッファ性能を維持できる	非共用タイプ同様縮退時も縮退前のバッファ性能を維持できますが，初回切り替え時のメモリ効率が悪いので非共用タイプをお勧めします。
あり	なし	あり	ユニット間サーバ共用	現用系のバックエンドサーバでは指定バッファ面数をすべて使用できる 縮退時は受け入れユニットの資源を共用するのでメモリ効率が良い	現用時の性能を重視し，縮退時にバッファ資源の共用を実現したい場合の適用をお勧めします。
あり	あり	あり	ユニット内ユニット間サーバ共用	縮退時は受け入れユニットの資源を共用するのでメモリ効率が良い 共用サーバ数を均等にすることで縮退時の負荷分散を均等に設計できる	縮退時，バッファ資源の共用，及び均等負荷分散を実現したい場合の適用をお勧めします。

次に示す-r，-b指定のバッファの設計指針を参考に適切な共用形態を選択してください。影響分散スタンバイレス型系切り替え機能はリソース共有，負荷分散が目的でもあるため，ユニット間で共用する構成となるユニット間サーバ共用，又はユニット内ユニット間サーバ共用をお勧めします。縮退時に性能を低下させたくない場合は，非共用，又はユニット内サーバ共用としてください。

-r，-b指定のバッファの設計指針

1. メモリに余裕のある環境で縮退時もバッファヒット率を低下させたくないRDエリアの場合：非共用，又はユニット内サーバ共用を選択します。

2. 現用時はバッファ資源を特定のサーバで独占して使用し，縮退時はほかのサーバと共用したい場合：ユニット間サーバ共用を選択します。

3. 1.及び2.のどちらにも当てはまらない場合：ユニット内ユニット間サーバ共用を選択します。

非共用グローバルバッファの割り当て方法

一つのバックエンドサーバに属するRDエリアだけをpdbufferオペランドの-rオプション，又は-bオプションに指定します。システム構成例を次に示します。

●システム構成例

●グローバルバッファの定義

pdbuffer -a gbuf01 -r RDAREA11,RDAREA12 -n 2000 -c
pdbuffer -a gbuf02 -r RDAREA21 -n 1000 -c
pdbuffer -a gbuf03 -r RDAREA31 -n 1000 -c

〔説明〕

同一サーバに属するRDエリアだけをpdbufferオペランドの-rオプション，又は-bオプションに指定します。

BES11，BES21，BES31に非共用バッファgbuf01，gbuf02，gbuf03を割り当てます。

系切り替え時もBES11専用のgbuf01を使用するのでヒット率は低下しませんが，すべての受け入れユニットで切り替え時使用するためのバッファが確保されるのでメモリを多く消費します。

注

• 受け入れユニットすべてに同一グローバルバッファが作成されます。このグローバルバッファは代替されるまで使用されません。

• メモリ効率を向上するためには同じページサイズのRDエリアを指定するようにします。

ユニット内サーバ共用のグローバルバッファの割り当て方法

使用できる共用メモリが十分にある環境で，多点障害時でも定常時と同じバッファ性能を維持したい場合に指定します。同一ユニット内のバックエンドサーバに配置されたRDエリアをpdbufferオペランドの-rオプション，又は-bオプションに指定します。

●システム構成例

●グローバルバッファの定義

pdbuffer -a gbuf01 -r RDAREA11,RDAREA12 -n 1000 -c
pdbuffer -a gbuf02 -r RDAREA21,RDAREA22 -n 1000 -c
pdbuffer -a gbuf03 -r RDAREA31,RDAREA32 -n 1000 -c

〔説明〕

同一ユニット内のサーバに配置されたRDエリアをpdbufferオペランドの-rオプション，又は-bオプションに指定します。

ユニット内サーバ共用のグローバルバッファgbuf01，gbuf02，gbuf03を割り当てます。

系切り替え時もgbuf01を使用するのでヒット率は低下しませんが，すべての受け入れユニットに切り替え時使用するためのグローバルバッファが確保されるのでメモリを多く消費します。

注

• 受け入れユニットすべてに同一グローバルバッファが作成されます。このグローバルバッファは代替されるまで使用されません。

• この指定のグローバルバッファは複数サーバ間で共用して使用されます。

• pdbufferオペランドの-lオプション省略時のバッファサイズは，指定したRDエリアの内の最大ページサイズとなります。

ユニット間サーバ共用のグローバルバッファの割り当て方法

同一ユニット内のサーバに配置されたRDエリアを指定しないで，異なるユニットのサーバに配置されたRDエリアをpdbufferオペランドの-rオプション，又は-bオプションに指定します。

●システム構成例

●グローバルバッファの定義

pdbuffer -a gbuf01 -r RDAREA11,RDAREA21,RDAREA31 -n 1000 -c

〔説明〕

異なるユニットに配置されたサーバのRDエリアを指定します。

同一ユニット内のサーバに配置されたRDエリア間で共用化しないで，異なるユニットのサーバに配置されたRDエリアを共用化します。

縮退前はgbuf01のリソース（バッファ数）をBES11で占有して使用できます。縮退時はBES21とBES11で共用するので使用できるリソース（バッファ数）は半分になります。

注

• 移動先が一つのユニットになるのでそのユニットのグローバルバッファだけ負荷が高くなります。ユニット間サーバ共用バッファを複数定義し各ユニットの負荷が均等になるように設計してください

• 受け入れユニットすべてに同一グローバルバッファが作成されます。

• この指定のグローバルバッファは現用時には一つのサーバで占有して使用され，縮退時には複数サーバ間で共用して使用されます。

• pdbufferオペランドの-lオプション省略時のバッファサイズは指定したRDエリアの内の最大ページサイズとなります。

ユニット内ユニット間サーバ共用のグローバルバッファの割り当て方法

ユニット内ユニット間サーバ共用のRDエリアをpdbufferオペランドの-rオプション，又は-bオプションに指定します。

●システム構成例

●グローバルバッファの定義

pdbuffer -a gbuf01 -r RDAREA11,RDAREA12,RDAREA21,RDAREA22,RDAREA31,RDAREA32 -n 1000 -c

〔説明〕

ユニット内ユニット間サーバ共用のRDエリアをpdbufferオペランドの-rオプション，又は-bオプションに指定します。

ユニット内ユニット間サーバ共用のRDエリアでグローバルバッファを共用することで，縮退時の負荷分散が均等になるようなバッファを割り当てます。定常時は各ユニットが二つのバックエンドサーバ間でgbuf01を共用するので一つのバックエンドサーバに割り当てられるバッファ面数は半分です。縮退時は三つのバックエンドサーバ間でgbuf01を共用するので一つのバックエンドサーバに割り当てるバッファ面数は各ユニットが1/3と均等になります。

注

• 縮退時に受け持つサーバ数が各受け入れユニットで均等になるように設計してください。

• 受け入れユニットすべてに同一グローバルバッファが作成されます。

• この指定のグローバルバッファは複数サーバ間で共用して使用されます。

• pdbufferオペランドの-lオプション省略時のバッファサイズは指定したRDエリアの内の最大ページサイズとなります。

(c)　インデクス用グローバルバッファの割り当て方法（-iオプション指定）

特定のインデクスのインデクスページをバッファリングしたい場合にインデクス用グローバルバッファを割り当てます。インデクス格納RDエリアにそのインデクスしか格納されていない場合には，そのRDエリアにRDエリア用グローバルバッファ（-rオプション指定）を割り当てても同じ効果が得られます。インデクスに対するユニット単位グローバルバッファの割り当ては，指定するインデクスのインデクス格納RDエリアの配置によって4種類に分類されます。グローバルバッファの共用形態別の推奨条件（-iオプション指定）を次の表に示します。

表26‒40　グローバルバッファの共用形態別の推奨条件（-iオプション指定）

指定方法（-iオプションで指定したインデクス格納用RDエリア）			インデクス分割形式	バッファ共用形態	メリット	推奨条件
異なるサーバのRDエリア	同一ユニットのRDエリア	異なるユニットのRDエリア
なし	なし	なし	非分割で同一サーバ内分割	非共用	他サーバと共用しないため，多重障害時でも定常時のバッファ性能を維持できる	すべての受け入れユニットにバッファを確保するためメモリに余裕がある環境で，縮退時も縮退前のバッファ性能を維持したいインデクスに対する適用をお勧めします。
あり	あり	なし	同一ユニット内分割	ユニット内サーバ共用	多重障害でも定常時のバッファ性能を維持できる	すべての受け入れユニットにバッファを確保するためメモリに余裕がある環境で，縮退時も縮退前のバッファ性能を維持したいインデクスに対する適用をお勧めします。
あり	なし	あり	ユニット間分割で同一ユニット内分割なし	ユニット間サーバ共用	現用系のバックエンドサーバでは指定バッファ面数をすべて使用できる 縮退時は受け入れユニットの資源を共用するのでメモリ効率が良い	現用時の性能を重視し，縮退時にバッファ資源を共用したい場合の適用をお勧めします。
あり	あり	あり	ユニット間分割で同一ユニット内分割あり	ユニット内ユニット間サーバ共用	縮退時は受け入れユニットの資源を共用するのでメモリ効率が良い 共用サーバ数を均等にすることで縮退時の負荷分散を均等に設計できる	縮退時，バッファ資源の共用，及び均等負荷分散を実現したい場合の適用をお勧めします。

次に示す-iオプション指定のバッファ設計指針を参考にインデクス専用バッファを割り当てるかどうか選択してください。

-iオプション指定のバッファ設計指針

1. 非分割インデクス，同一サーバ内分割インデクス，又は同一ユニット内分割インデクスの場合：同一HAグループの各ユニットにグローバルバッファを確保できるだけメモリに余裕があれば専用バッファを定義します。

2. 1.に当てはまらない場合：インデクス用グローバルバッファを定義します。共用するサーバに見合ったバッファ面数を割り当ててください。

非分割インデクス用グローバルバッファの割り当て方法

非分割インデクスをpdbufferオペランドの-iオプションで指定します。

●システム構成例

●グローバルバッファの定義

pdbuffer -a gbuf01 -i USER01.INDEX01 -n 200 -c

〔説明〕

非分割インデクスUSER01.INDEX01を指定します。

非分割インデクスの共用グローバルバッファへの割り当て例です。ほかのサーバとはグローバルバッファを共用しないで，占有します。系切り替え時もBES11専用のgbuf01を使用するのでヒット率は低下しませんが，すべての受け入れユニットに対して切り替え時，使用するためのバッファが確保されるのでメモリを多く消費します。

注

受け入れユニットすべてに同じグローバルバッファが作成されます。このバッファは代替されるまで使用されません。

同一サーバ内分割インデクス用グローバルバッファの割り当て方法

同一サーバ内に分割されたインデクスをpdbufferオペランドの-iオプションで指定します。

●システム構成例

●グローバルバッファの定義

pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c

〔説明〕

サーバ内横分割インデクスUSER01.INDEX01を指定します。

同一サーバ内に分割されたインデクスの共用グローバルバッファへの割り当て例です。ほかのサーバとは共用しないで，占有します。系切り替え時もBES11専用のgbuf01を使用するのでヒット率は低下しませんが，すべての受け入れユニットに切り替え時使用するためのバッファが確保されるのでメモリを多く消費します。

注

• 受け入れユニットすべてに同じグローバルバッファが作成されます。このグローバルバッファは代替されるまで使用されません。

• インデクス格納用RDエリアのページサイズを同じにすることでメモリ効率が向上します。

同一ユニット内分割インデクス用グローバルバッファの割り当て方法

同一ユニット内に分割されたインデクスをpdbufferオペランドの-iオプションで指定します。

●システム構成例

●グローバルバッファの定義

pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c

〔説明〕

同一ユニット内に分割されたインデクスの共用グローバルバッファへの割り当て例です。系切り替え時もgbuf01を使用するのでヒット率は低下しませんが，すべての受け入れユニットに切り替え時使用するためのグローバルバッファが確保されるのでメモリを多く消費します。

注

• 受け入れユニットすべてに同じグローバルバッファが作成されます。このグローバルバッファは代替されるまで使用されません。

• この指定のグローバルバッファは複数サーバ間で共用されます。

• インデクス格納用RDエリアのページサイズを同じにすることでメモリ効率が向上します。

• pdbufferオペランドの-lオプション省略時のバッファサイズは指定したインデクス格納用RDエリア内の最大ページサイズとなります。

ユニット間分割で同一ユニット内分割なしインデクス用グローバルバッファの割り当て方法

異なるユニット間のサーバに分割されたインデクスをpdbufferオペランドの-iオプションで指定します。

●システム構成例

●グローバルバッファの定義

pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c

〔説明〕

異なるユニット間のサーバに横分割されたインデクスUSER01.INDEX01を指定します。

ユニット間分割で同一ユニット内分割なしのインデクスに対するグローバルバッファの割り当て例です。縮退前はgbuf01のリソース（バッファ数）をBES11で占有します。縮退時はBES21とBES11で共用するので使用できるリソース（バッファ数）は半分となります。

注

• 移動先が一つのユニットになるのでそのユニットのグローバルバッファだけ負荷が高くなります。ユニット間サーバ共用バッファを複数定義し，各ユニットの負荷が均等になるように設計してください。

• 受け入れユニットすべてに同じグローバルバッファが作成されます。

• この指定のグローバルバッファは現用時には一つのサーバで占有され，縮退時には複数サーバ間で共用されます。

• インデクス格納用RDエリアのページサイズを同じにすることでメモリ効率が向上します。

• pdbufferオペランドの-lオプション省略時のバッファサイズは，指定したインデクス格納用RDエリアの内の最大ページサイズとなります。

ユニット間分割で同一ユニット内分割ありインデクスのグローバルバッファの割り当て方法

ユニット間分割で同一ユニット内で分割されたインデクスをpdbufferオペランドの-iオプションで指定します。

●システム構成例

●グローバルバッファの定義

pdbuffer -a gbuf01 -i USER01.INDEX01 -n 1000 -c

〔説明〕

ユニット間分割ありのサーバ間横分割インデクスUSER01.INDEX01を指定します。

ユニット間分割で同一ユニット内で分割されたインデクスの共用グローバルバッファへの割り当て例です。定常時は各ユニットが二つのバックエンドサーバ間でgbuf01を共用するので一つのバックエンドサーバに割り当てられるバッファ面数は半分です。縮退時は三つのバックエンドサーバ間でgbuf01を共用するので一つのバックエンドサーバに割り当てるバッファ面数は各ユニットが1/3と均等になります。

注

• 縮退時受け持つサーバ数が各受け入れユニットで均等になるように設計してください。

• 受け入れユニットすべてに同じグローバルバッファが作成されます。

• この指定のグローバルバッファは複数サーバ間で共用されます。

• インデクス格納用RDエリアのページサイズを同じにすることでメモリ効率が向上します。

• pdbufferオペランドの-lオプション省略時のバッファサイズは指定したインデクス格納用RDエリアの内の最大ページサイズとなります。

(d)　OTHER用グローバルバッファの割り当て方法（-oオプション指定）

OTHER用グローバルバッファは，影響分散スタンバイレス型系切り替え機能の適用ユニットすべてに確保されます。次に示すように割り当てられます。

• pdbufferオペランドの-cオプション指定のOTHER用バッファ定義はシステムで一つだけ指定できます。-cオプション指定のOTHER用バッファを複数定義した場合は，システム共通定義で最初に記述されている定義を有効とします。

• 影響分散スタンバイレス型系切り替え機能の適用ユニット内で稼働するホストBES，及びゲストBESに配置されたRDエリアのうち，-rオプション指定のグローバルバッファが未割り当てのRDエリアに割り当てられます。

• pdbufferオペランドの-lオプションでバッファサイズを省略した場合，同一HAグループ内で-cオプションと-ｒオプションを指定したグローバルバッファを割り当てていないRDエリアがある場合には，同一HAグループ内で-cオプションと-ｒオプションを指定したグローバルバッファを割り当てていないRDエリア中の最大ページサイズとなります。同一HAグループのすべてに-cオプションと-ｒオプションを指定したグローバルバッファを割り当てている場合には，同一HAグループ内のRDエリアの最大ページサイズとなります。

• pdbufferオペランドの-cオプションを指定したOTHER用グローバルバッファと-cオプションを指定しないOTHER用グローバルバッファの定義は重複指定できます。OTHER用グローバルバッファ定義の重複指定時の関係を次の表に示します。

  表26‒41　OTHER用グローバルバッファ定義の重複指定時の関係

  -cオプションを指定したOTHER用グローバルバッファ定義	-cオプションを指定しないOTHER用グローバルバッファ定義	影響分散スタンバイレス型系切り替え機能の適用ユニット	影響分散スタンバイレス型系切り替え機能の非適用ユニット
  あり	あり	-cオプションありで定義を割り当てる	-cオプションなしで定義を割り当てる
  あり	なし	-cオプションありで定義を割り当てる	-cオプションありで定義を割り当てる
  なし	あり	OTHER用バッファを割り当てない	-cオプションなしで定義を割り当てる
  なし	なし	OTHER用バッファを割り当てない	OTHER用バッファを割り当てない

OTHER用グローバルバッファの推奨条件

• オンライン中でRDエリアを追加するシステム

• アクセス頻度が少ないRDエリア

• アクセスページ数の少ないRDエリア

• 格納ページ数が非常に多いRDエリア（バッファヒットを期待しないRDエリア）

OTHER用グローバルバッファの注意事項

• ユニットに確保したOTHER用グローバルバッファ資源はOTHER用バッファを割り当てたサーバ間で均等に分割して使用します。したがって，使用するサーバ数に見合ったバッファ面数をpdbufferオペランドの-nオプションで指定するようにしてください。

• オンライン中でRDエリアを追加するシステムでは，今後追加が予想されるRDエリアのページサイズを考慮し，pdbufferオペランドの-lオプションでバッファサイズを設定してください。

OTHER用グローバルバッファの割り当て方法の例

pdbufferオペランドの-oオプションを指定します。

●システム構成例

●グローバルバッファの定義

pdbuffer -a gbuf01 -r RDAREA11 -n 500 -c
pdbuffer -a gbuf02 -o -n 1000 -c

〔説明〕

pdbufferオペランドの-oオプションと-cオプションを指定します。

RDAREA11に専用バッファを割り当て，そのほかのRDエリアにはOTHER用バッファを割り当てます。OTHER用バッファは影響分散スタンバイレス型系切り替え機能の適用ユニットすべてに作成されます。

(e)　構成変更時のグローバルバッファの割り当て（データベース構成変更ユティリティ）

データベース構成変更ユティリティの制御文のglobalbufferオペランドに，既にあるグローバルバッファ名を指定して実施します。グローバルバッファはpdbuflsコマンドで確認できます。

●システム構成例

●構成変更定義

create rdarea RDAREA13 globalbuffer gbuf01 server name BES11
　　　　　　　　：

〔説明〕

追加RDエリアに共用グローバルバッファgbuf01を割り当てます。追加したRDエリアは系切り替え時もgbuf01を使用します。

〔設計指針〕

• 系の切り替え時，及び系の切り戻し時もglobalbufferオペランドで指定したグローバルバッファを割り当てます。

• インデクス用グローバルバッファ，及びLOB用グローバルバッファは割り当てられません。

• 指定するグローバルバッファの長さは，追加するRDエリアのページ長より長くなければなりません。グローバルバッファ長は，pdbuflsコマンドで確認できます。

• ここで指定したグローバルバッファの割り当ては，サーバの正常終了（HiRDBシステムの正常終了，計画停止，ユニットの正常終了，又はサーバ単独の正常終了）時に無効となります。そのため，次回のサーバの正常開始時には，あらかじめシステム共通定義のpdbufferオペランドでグローバルバッファを割り当てておかなければなりません。ただし，-oオプション指定のグローバルバッファを割り当てている場合はそのグローバルバッファに割り当てますのでシステム共通定義を変更する必要はありません。

• HiRDBがグローバルバッファの割り当てに失敗した場合，RDエリアは追加されません。

(a)　監査証跡ファイルの作成

監査証跡ファイルはHiRDB管理者が共有ディスクに作成します。このとき，作成先ディスクには，各サーバに対応する共有ディスク（各サーバのシステムログファイル，シンクポイントダンプファイル，サーバ用ステータスファイルを格納するディスク）以外のディスクを選ぶ必要があります。

各サーバに対応する共有ディスクに監査証跡ファイルを作成すると，系の切り替えによってディスクが別のホストに切り替わるため，ユニット内のほかの稼働中サーバが監査証跡を出力できなくなります。なお，系の切り替え先では，受け入れユニットの監査証跡ファイルを使用します。

(b)　監査証跡ファイルの運用

系切り替えが発生した場合，HiRDBは切り替え先の受け入れユニットが使用中の監査証跡ファイルに監査事象を記録します。このとき，監査事象の記録に関する監査証跡ファイルの運用は，受け入れユニットでの運用に統一されます。

影響分散スタンバイレス型系切り替え機能を適用したシステムで監査証跡を取得する場合は，全ユニットで監査証跡を取得してください。

(c)　監査証跡の取得

系切り替えが発生した場合，監査証跡取得については，受け入れユニットの状態に従います。影響分散スタンバイレス型系切り替え機能での監査証跡の取得状況を次の表に示します。

表26‒42　影響分散スタンバイレス型系切り替え機能での監査証跡の取得状況

ユニット種別	ユニットの状態	受け入れユニット
		取得中	取得していない
正規ユニット	取得中	取得する	取得しない
	取得していない	取得する	取得しない

影響分散スタンバイレス型系切り替え機能適用時の監査証跡取得状況の例を次の図に示します。

図26‒96　影響分散スタンバイレス型系切り替え機能適用時の監査証跡取得状況の例

(d)　pdloadの実行

HiRDB管理者は，正規ユニット及び受け入れユニットの監査証跡ファイルを入力情報として，pdloadを実行してください（認証は監査人）。なお，系切り替え中のサーバの監査証跡は，受け入れユニットに属するサーバの情報として処理されます。

障害などで系が切り替わった場合，HiRDBは切り替わる直前の監査事象を正しく取得しません。このため，pdloadを実行しても切り替え直前のデータを取得できない場合があります。

なお，系切り替えなどによって影響分散スタンバイレス型系切り替え対象ユニットに実行系サーバが0個となった場合，そのユニットに対する監査証跡ファイルのpdloadは実行できません。この場合は，該当するユニットに実行系サーバを1個以上系切り替えした後で，pdloadを実行してください。

障害中の運用：

障害中の監査証跡のロード運用は次のとおりです。

1. 稼働中ホストで系切り替え前の監査証跡ファイルを格納したディスクを手動で活動化

2. 正規ユニット及び受け入れユニットの監査証跡ファイルを入力情報としてpdload実行

障害復旧後の運用：

障害復旧後の監査証跡のロード運用は障害発生前と同じです。