Hitachi

ノンストップデータベース　HiRDB Version 10 システム運用ガイド（UNIX(R)用）

26.4.3　HiRDBに関する準備

実行者　HiRDB管理者

ここでは，HiRDBに関する準備方法について説明します。

〈この項の構成〉

(1)　前提条件及び注意事項

ページの先頭へ

(2)　共有ディスク装置の準備

現用系と予備系（正規BESと代替BES）で共有する外付けハードディスクが必要です。このハードディスクを共有ディスク装置といいます。

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

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

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

[図データ]
〔説明〕

ユニット単位の切り替えのためユニットごとに共有ディスクを割り当てます。

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

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

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

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

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

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

注意事項

  • これらのHiRDBファイルシステム領域は，正規BESユニットと代替BESユニットの両方から同じパス名で参照できるように設定してください。

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

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

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

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

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

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

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

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

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

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

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

[図データ]
〔説明〕

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

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

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

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

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

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

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

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

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

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

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

図26‒79　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モニタで共有ディスクのアクセス制御をしないため，このオペランドを省略してください。

ページの先頭へ

(3)　HiRDBシステム定義の作成

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

正規BESユニットのユニット制御情報定義ファイル及びバックエンドサーバ定義ファイルを代替BESユニットにコピーします。そのとき，ユニット制御情報定義ファイルの名称を次に示すように変更してください。

　pdutsys.正規BESユニットのユニット識別子

この定義ファイルに指定したオペランドのうち，代替中に設定値が有効になるオペランドを次に示します。次に示すオペランド以外は代替BESユニットのユニット制御情報定義ファイルに設定したオペランドの値が有効になります。

  • pd_syssts_file_name_1〜7

  • pd_syssts_singleoperation

  • pd_syssts_initial_error

  • pd_syssts_last_active_file

  • pd_syssts_last_active_side

  • pd_audit

  • pd_aud_file_name

  • pd_aud_max_generation_size

  • pd_aud_max_generation_num

  • pd_aud_async_buff_size

  • pd_aud_async_buff_count

  • pd_ha_switch_timeout

  • pd_rpl_hdepath

スタンバイレス型系切り替え機能使用時のHiRDBシステム定義ファイルの構成例（相互代替構成の場合）を次の図に示します。

図26‒80　スタンバイレス型系切り替え機能使用時のHiRDBシステム定義ファイルの構成例（相互代替構成の場合）

[図データ]
〔説明〕

  • 正規BESユニット（BES1）のユニット制御情報定義ファイル及びバックエンドサーバ定義ファイルを代替BESユニット（BES2）にコピーします。そのとき，ユニット制御情報定義ファイルの名称をpdutsys.UNT1に変更します。

  • 正規BESユニット（BES2）のユニット制御情報定義ファイル及びバックエンドサーバ定義ファイルを代替BESユニット（BES1）にコピーします。そのとき，ユニット制御情報定義ファイルの名称をpdutsys.UNT2に変更します。

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

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

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

オペランド名

説明及び注意事項

pd_ha

系切り替え機能を使用する場合に指定します。

pd_ha_unit

ユニットに系切り替え機能を適用している場合は指定しないでください。

システム内で系切り替え機能を適用しないユニットがある場合，又はシステム内に回復不要FESユニットがある場合は，そのユニットのユニット制御情報定義のpd_ha_unitオペランドにnouseを指定します。

pd_ha_acttype

系切り替え機能をモニタモードで運用するか，サーバモードで運用するかを指定します。

monitor：系切り替え機能をモニタモードで運用します。

server：系切り替え機能をサーバモードで運用します。

サーバモードを使用する場合は，serverを指定してください。

pd_ha_agent

1：1スタンバイレス型系切り替え機能を使用する場合は，serverを指定します。

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_trn_queuing_initial

フロントエンドサーバを配置したユニットの起動直後からトランザクションキューイング機能を有効にする場合に指定します。

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運用ディレクトリ名を指定します。正規BESユニットと代替BESユニットで同じディレクトリ名を指定してください。

-p

HiRDBのポート番号を指定します。正規BESユニットと代替BESユニットのポート番号※１は同じ番号を指定してください。

-s

スケジューラのポート番号を指定します。正規BESユニットと代替BESユニットのポート番号※２は同じ番号を指定してください。

-t

トランザクションサーバのポート番号を指定します。正規BESユニットと代替BESユニットのポート番号※３は同じ番号を指定してください。

pdstart

-c

代替BES名を指定します。

pdbuffer

-c

代替中に代替部が使用するグローバルバッファを割り当てる場合にこのオプションを指定します。「グローバルバッファの定義（1：1スタンバイレス型系切り替え機能の場合）」を参照してください。

pd_service_port

同一サーバマシン内複数ユニット構成の場合（相互系切り替え構成を含みます）にこのオペランドを指定するときは注意が必要です。同一サーバマシン内複数ユニット構成の場合（相互系切り替え構成を含みます），このオペランドはユニット制御情報定義でユニットごとに別々のポート番号を指定してください。

次に示す指定をした場合は，どちらかのユニットへの系の切り替えに失敗します。

  • システム共通定義のpd_service_portオペランドを指定した（ユニット制御情報定義のpd_service_portオペランドは指定していない）

  • ユニット制御情報定義のpd_service_portオペランドに，ほかのユニット制御情報定義のpd_service_portオペランドと同じポート番号を指定した

pd_max_ard_process

正規BESとそれに対応する代替BESに同じ値を指定してください。
注※１

システム定義のpd_name_portオペランド及びpdunitオペランドの-pオプションを指します。

注※２

システム定義のpd_scd_portオペランド及びpdunitオペランドの-sオプションを指します。

注※３

システム定義のpd_trn_portオペランド及びpdunitオペランドの-tオプションを指します。

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

1：1スタンバイレス型系切り替えでの系切り替え後の代替BESユニットでは，代替BESが本来の処理をするとともに，正規BESの処理を代行します。このとき，サーバプロセスは代替BES本来の処理用と正規BESの処理用に割り当てられます。代替BES本来の処理をしているサーバプロセスと正規BESの処理を代行しているサーバプロセスの数は必要に応じて変化しますが，代替BESの最大起動プロセス数（pd_max_bes_processオペランドの値）が両者の合計プロセス数の上限となります。この結果，系切り替え発生後の代替BESユニットでの過剰な負荷上昇を抑止できますが，一方で，系切り替え発生後には同時に処理できるサービス要求数の上限が平均で半数に制限されますので注意が必要です。系切り替え発生後のユニットの負荷上昇，及び同時に処理できるサービス要求数の両方を考慮して代替BESのpd_max_bes_processオペランドを設定してください。

また，系切り替え発生前の状態で常駐プロセス数（pd_process_countオペランドの値）に余裕があり，サービス要求処理中でないサーバプロセスが常駐している状態では，系切り替え発生後にサービス要求処理中でない常駐プロセスを正規BESの処理を代行するために利用できます。このため，切り替え時の処理性能が向上します。

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

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

[図データ]

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

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

また，常駐プロセスを使い切った場合は必要に応じてサーバプロセスを追加起動しますが，サーバプロセス数は代替BES（bes1）のpd_max_bes_processオペランドの値までに制限されます。

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

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

[図データ]

系切り替え後，代替BES（bes1）が正規BES（bes2）の処理を代行中には，代替BESのpd_max_bes_processオペランドの範囲で，必要に応じて起動したサーバプロセスを代替BES（bes1）の処理，及び正規BES（bes2）処理用に振り分けます。

代替BES（bes1）への処理要求だけの場合には，代替BES（bes1）のpd_max_bes_processオペランドの値まで，同時に代替BES（bes1）の処理ができます。

また，正規BES（bes2）への処理要求だけの場合には，代替BES（bes1）のpd_max_bes_processオペランドの値まで，同時に正規BES（bes2）の処理ができます。

ページの先頭へ

(4)　RDエリアの作成

共有ディスクに作成したRDエリア用のHiRDBファイルシステム領域にRDエリアを定義します。ユーザ用RDエリアとシステム用RDエリアをそれぞれ異なる共有ディスクのHiRDBファイルシステム領域に作成するときの定義例を次に示すシステム構成例を基に説明します。

図26‒83　HiRDB/シングルサーバのシステム構成例

[図データ]

●create rdarea文の指定例

create rdarea SMAST for masterdirectory                   1
  file name "/sds0111/srd01" initial 10 segments;
create rdarea SDIR for datadirectory                      2
  file name "/sds0112/srd02" initial 5 segments;
create rdarea SDIC for datadictionary                     3
  file name "/sds0113/srd03" initial 20 segments;
create rdarea SUSR01 for user used by PUBLIC              4
  file name "/sds0121/srd04" initial 500 segments;
create rdarea SUSR02 for user used by PUBLIC              5
  file name "/sds0131/srd05" initial 500 segments;
〔説明〕

  1. マスタディレクトリ用RDエリア（SMAST）を共有ディスクAのHiRDBファイルシステム領域に作成します。

  2. データディレクトリ用RDエリア（SDIR）を共有ディスクAのHiRDBファイルシステム領域に作成します。

  3. データディクショナリ用RDエリア（SDIC）を共有ディスクAのHiRDBファイルシステム領域に作成します。

  4. ユーザ用RDエリア（SUSR01）を共有ディスクBのHiRDBファイルシステム領域に作成します。

  5. ユーザ用RDエリア（SUSR02）を共有ディスクCのHiRDBファイルシステム領域に作成します。

    図26‒84　HiRDB/パラレルサーバのシステム構成例

    [図データ]

●create rdarea文の指定例

create rdarea PMAST for masterdirectory                      1
    server name DIC file name "/dic0111/prd01"
    initial 10 segments;
create rdarea PDIR for datadirectory                         2
    server name DIC file name "/dic0112/prd02"
    initial 5 segments;
create rdarea PDIC for datadictionary                        3
    server name DIC file name "/dic0113/prd03"
    initial 20 segments;
create rdarea PUSR01 for user used by PUBLIC                 4
    server name BACK01 file name "/back0121/prd04"
    initial 500 segments;
create rdarea PUSR02 for user used by PUBLIC                 5
    server name BACK02 file name "/back0231/prd05"
    initial 500 segments;
〔説明〕

  1. マスタディレクトリ用RDエリア（PMAST）を共有ディスクAのHiRDBファイルシステム領域に作成します。

  2. データディレクトリ用RDエリア（PDIR）を共有ディスクAのHiRDBファイルシステム領域に作成します。

  3. データディクショナリ用RDエリア（PDIC）を共有ディスクAのHiRDBファイルシステム領域に作成します。

  4. ユーザ用RDエリア（PUSR01）を共有ディスクBのHiRDBファイルシステム領域に作成します。

  5. ユーザ用RDエリア（PUSR02）を共有ディスクCのHiRDBファイルシステム領域に作成します。

ページの先頭へ

(5)　グローバルバッファの定義（1：1スタンバイレス型系切り替え機能の場合）

正規BES下のRDエリアが使用するグローバルバッファを定義するとき，pdbufferオペランドに-cオプションを指定してください。-cオプションを指定すると，代替中に代替部が使用するグローバルバッファを確保できます。

なお，pdbufferオペランドの-c及び-oオプションの両方を省略した場合は，代替BESユニットを開始できません。

(a)　データ用グローバルバッファ（-rオプションのグローバルバッファ）の場合

代替中のデータ用グローバルバッファの割り当て方式を説明します。次に示すシステム構成を例にします。

●システム構成例1

[図データ]

pdbuffer -a gbuf01 -r RDAREA01,RDAREA02 -n 1000 -c
pdbuffer -a gbuf02 -r RDAREA03,RDAREA04 -n 1000
〔説明〕

  • 正規BESと代替BESで同じ名称のグローバルバッファを使用していない構成です。

  • -cオプションを指定すると代替BES下にもgbuf01が確保されます。代替中はこのグローバルバッファを使用します。ただし，正常時にはこのグローバルバッファは使用されません。

  • 代替BESユニットでグローバルバッファが使用する共用メモリを見積もるときにgbuf01の分を加算する必要があります。

  • 代替中もバッファヒット率が低下しません。

●システム構成例2

[図データ]

pdbuffer -a gbuf01 -r RDAREA01,RDAREA02,RDAREA03,RDAREA04 -n 1000 -c
〔説明〕

  • 正規BESと代替BESで同じ名称のグローバルバッファを使用している構成です。

  • -cオプションを指定すると代替中は代替BESのgbuf01を使用します。

  • 代替中はバッファヒット率が低下することがあります。

  • 代替BES下のgbuf01のバッファサイズは，正規BES及び代替BES下のRDエリアの最大ページ長になります。

-cオプションを省略した場合

-cオプションを省略すると，代替中は-oオプションのグローバルバッファを使用します。

(b)　インデクス用グローバルバッファ（-iオプションのグローバルバッファ）の場合

代替中のインデクス用グローバルバッファの割り当て方式を説明します。次に示すシステム構成を例にします。

●システム構成例

[図データ]

pdbuffer -a gbuf01 -i USER01.INDX01 -n 1000 -c
〔説明〕

  • 非横分割インデクスINDX01が使用するグローバルバッファに-cオプションを指定すると，代替BES下にもgbuf01が確保されます。代替中はこのグローバルバッファを使用します。ただし，正常時にはこのグローバルバッファは使用されません。

  • 代替BESユニットでグローバルバッファが使用する共用メモリを見積もるときにgbuf01の分を加算する必要があります。

●システム構成例

[図データ]

pdbuffer -a gbuf02 -i USER01.INDX02 -n 1000 -c
〔説明〕

  • 横分割インデクスINDX02が使用するグローバルバッファに-cオプションを指定すると，代替BES下にgbuf02と同じグローバルバッファgbuf02が確保されます。代替中はこのグローバルバッファを使用するため，BES2下のINDX02とアクセス競合は発生しません。ただし，正常時にはこのグローバルバッファは使用されません。

  • 代替BESユニットでグローバルバッファが使用する共用メモリを見積もるときにgbuf02の分を2倍する必要があります。

-cオプションを省略した場合

-cオプションを省略すると，代替中は次に示す優先順位でグローバルバッファを使用します。

  1. インデクス格納RDエリアにグローバルバッファを割り当てていて，そのグローバルバッファに-cオプションを指定している場合は，(a)で説明した方式に従います。

  2. -oオプションのグローバルバッファを使用します。

(c)　LOB用グローバルバッファ（-bオプションのグローバルバッファ）の場合

代替中のLOB用グローバルバッファの割り当て方式はデータ用グローバルバッファと同じです。ただし，-cオプションを省略した場合は，グローバルバッファを使用しないで直接RDエリアに対して読み込み及び書き込みをします。

(d)　-oオプションのグローバルバッファの場合

代替BES下の-oオプションのグローバルバッファを代替中は正規BES下のRDエリアも使用します。グローバルバッファのバッファサイズは正規BES及び代替BES下のRDエリアの最大ページ長になります。

(e)　グローバルバッファの設計方針

基本的には，正規BES下のRDエリア，インデクス，及びLOB用RDエリアが使用するグローバルバッファに-cオプションを指定してください。

  • -cオプションを指定すると，代替中に使用するグローバルバッファを代替BES下に作成します。このため，代替BESユニットでグローバルバッファが使用する共用メモリがその分だけ余計に必要になります。共用メモリに余裕がない場合は-cオプションを指定しないでください。

  • 代替BES下のグローバルバッファを正規BES下のRDエリアにも使用させる場合，そのグローバルバッファのバッファサイズは正規BES及び代替BES下のRDエリアの最大ページ長になります。したがって，RDエリアのページ長も考慮して-cオプションを指定してください。

ページの先頭へ

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

実行者　HiRDB管理者，及び監査人

監査証跡ファイルはHiRDB管理者が共有ディスクに作成します。HiRDB管理者，及び監査人は，共有ディスク上の監査証跡ファイルを運用してください。

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

監査証跡ファイルは，HiRDB管理者が共有ディスクに作成します。

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

系切り替えが発生した場合，HiRDBは共有ディスク上の監査証跡ファイルに監査事象を記録します。監査事象の記録に関する監査証跡ファイルの運用については，「監査証跡ファイルの運用」を参照してください。

(c)　監査証跡の取得

系切り替えが発生した場合，監査証跡取得状態の引き継ぎについては，切り替え元ユニットの停止状態に依存します。切り替え先の系が再開始の場合は系を切り替える前の状態を引き継ぎます。切り替え先の系が正常開始の場合はpd_auditオペランドの指定に従います。

(d)　pdloadの実行

HiRDB管理者は，監査証跡ファイルを入力情報として，pdloadを実行してください（認証は監査人）。ただし，障害などで系が切り替わった場合，HiRDBは切り替わる直前の監査事象を正しく取得しません。このため，pdloadを実行しても切り替え直前のデータを取得できない場合があります。

ページの先頭へ

(7)　NetBackup連携機能を使用する場合の注意事項

系切り替え構成でNetBackup連携機能を使用する場合で，バックアップを取得したNetBackupクライアントとは別のNetBackupクライアントで回復を行うときは，次の環境設定と運用が必要です。ただし，この環境設定と運用は，JP1/VERITAS NetBackup 5.0以降を使用している場合にだけ適用してください。

ページの先頭へ

商品名称に関する表示

All Rights Reserved. Copyright (C) 2018, 2022, Hitachi, Ltd.