ノンストップデータベース　HiRDB Version 10 システム導入・設計ガイド（Windows(R)用）

解説・手引・操作書

3020-6-553-B0

前書き

対象製品

●適用OS：Windows Server 2019，Windows Server 2022，Windows Server 2025，Pro (x64)，Windows 10 Enterprise (x64)，Windows 11

P-2962-91A4 HiRDB Server Version 10 10-11

P-2962-7PA4 HiRDB Accelerator Version 10 10-00

P-2962-7HA4 HiRDB Non Recover Front End Server Version 10 10-00

P-2962-7JA4 HiRDB Advanced High Availability Version 10 10-00

●適用OS：Windows Server 2019，Windows Server 2022，Windows Server 2025，Windows 10，Windows 11

P-2662-11A4 HiRDB/Run Time Version 10 10-11

P-2662-12A4 HiRDB/Developer's Kit Version 10 10-11

P-2662-32A4 HiRDB Developer's Suite Version 10 10-11

●適用OS：Windows Server 2019，Windows Server 2022，Windows Server 2025，Windows 10 Home (x64)，Windows 10 Pro (x64)，Windows 10 Enterprise (x64)，Windows 11

P-2962-11A4 HiRDB/Run Time Version 10(64) 10-11

P-2962-12A4 HiRDB/Developer's Kit Version 10(64) 10-11

これらのプログラムプロダクトのほかにもこのマニュアルをご利用になれる場合があります。詳細は「リリースノート」でご確認ください。

輸出時の注意

本製品を輸出される場合には、外国為替および外国貿易法の規制ならびに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

記載の会社名、製品名などは、それぞれの会社の商標もしくは登録商標です。

発行

2026年4月　3020-6-553-B0

著作権

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

変更内容

変更内容(3020-6-553-B0)　HiRDB Version 10 10-11

追加・変更内容 | 変更個所
HiRDB/シングルサーバの，ユニットコントローラが使用する共用メモリの計算式を変更しました。 | 15.1.3(1)，15.1.3(2)
HiRDB/パラレルサーバの，ユニットコントローラが使用する共用メモリの計算式を変更しました。 | 15.2.3(2)

単なる誤字・脱字などはお断りなく訂正しました。

変更内容(3020-6-553-A0)　HiRDB Version 10 10-10

追加・変更内容

表のアクセス権限を一括で管理できるロール機能をサポートしました。これによって，権限の管理や移行が容易になるだけでなく，アクセス制御の一貫性が向上し，セキュリティの強化にもつながります。

HiRDB用Power BIコネクタを使用することで，Power BIからHiRDBに接続できるようにしました。これによって，HiRDBに格納されているデータをPower BIで分析及び可視化できます。

HiRDB/シングルサーバの，ユニットコントローラが使用する共用メモリの計算式を変更しました。

HiRDB/パラレルサーバの，ユニットコントローラが使用する共用メモリの計算式を変更しました。

データディクショナリ用RDエリアの容量の表の格納ページ数の計算方法を変更しました。

ロール機能使用時に出力されるシステムログファイルの容量の見積もり式を追加しました。

HiRDBの適用OSに次のOSを追加しました。

Windows Server 2025

変更内容(3020-6-553-90)　HiRDB Version 10 10-09

追加・変更内容

ODBCドライバで発生したエラーの情報をODBCエラーログファイルへ出力する機能をサポートしました。

これによって，エラー発生時のトラブルシュートが容易になります。

pdvrupコマンド実行時のデータディクショナリ用RDエリアに必要な空きセグメント数の計算式を変更しました。

HiRDB用Tableauコネクタを使用することで，TableauからHiRDBに接続できるようにしました。

これによって，HiRDBに格納されているデータをTableauで分析及び可視化できます。

HiRDB/シングルサーバの，共用メモリが使用するメモリ所要量の見積り式を変更しました。

HiRDB/シングルサーバの，シングルサーバが使用するメモリ所要量の計算式と変数を変更しました。

HiRDB/シングルサーバの，シングルサーバが使用する共用メモリの計算式と変数を変更しました。

HiRDB/パラレルサーバの，共用メモリが使用するメモリ所要量の見積り式を変更しました。

HiRDB/パラレルサーバの，各ユニットが使用するメモリ所要量の計算式と変数を変更しました。

HiRDB/パラレルサーバの，各ユニットが使用する共用メモリの計算式と変数を変更しました。

HiRDBが自動計算に用いる計算式を変更しました。

HiRDB/シングルサーバの，リソース数に関連する環境変数に設定する値の計算式を変更しました。

HiRDB/パラレルサーバの，リソース数に関連する環境変数に設定する値の計算式を変更しました。

変更内容(3020-6-553-80)　HiRDB Version 10 10-08

追加・変更内容

デッドロック検知時に，デッドロックSQL情報ファイルにユーザ識別子ごとのSQLオブジェクト情報を出力できるようにしました。

これによって，デッドロック情報ファイルとデッドロックSQL情報ファイルに出力されるユーザ識別子を対応づけて，デッドロック発生要因のSQL文を確認できます。

クライアントとサーバ間のネットワーク上で送受信するデータを暗号化する機能をサポートしました。

これによって，パケットスニファリングなどで悪意のあるユーザが不正にデータを参照することを防止できます。

一つのグローバルバッファを複数に分割する機能をサポートしました。

これによって，一つの大きなグローバルバッファを定義してもグローバルバッファの競合を減らすことができ，グローバルバッファの設計を容易にできます。

HiRDB/シングルサーバのシングルサーバが使用する共用メモリの計算式を変更しました。

HiRDB/シングルサーバのグローバルバッファが使用する共用メモリの計算式を変更しました。

HiRDB/パラレルサーバのディクショナリサーバが使用する共用メモリの計算式を変更しました。

HiRDB/パラレルサーバのバックエンドサーバが使用する共用メモリの計算式を変更しました。

HiRDB/パラレルサーバの各サーバが使用する共用メモリの計算式で使用する変数を変更しました。

HiRDB/パラレルサーバのグローバルバッファが使用する共用メモリの計算式を変更しました。

HiRDB/シングルサーバのリソース数に関連する環境変数のの計算式を変更しました。

HiRDB/パラレルサーバのリソース数に関連する環境変数のの計算式を変更しました。

はじめに

このマニュアルは，プログラムプロダクト　ノンストップデータベース　HiRDB Version 10のシステムの構築方法，データベースの作成方法及びシステムとデータベースの設計方法について説明したものです。なお，ここに記載されていない前提情報については，マニュアル「HiRDB Version 10 解説」を参照してください。

対象読者

HiRDB Version 10（以降，HiRDBと表記します）を使ってリレーショナルデータベースシステムを構築／運用する方々を対象にしています。

このマニュアルは次に示す知識があることを前提に説明しています。

Windowsのシステム管理の基礎的な知識

SQLの基礎的な知識

また，このマニュアルは，マニュアル「HiRDB Version 10 解説」を前提としていますので，あらかじめお読みいただくことをお勧めします。

図中で使用している記号

このマニュアルの図中で使用している記号を次のように定義します。

1　HiRDBのシステム構築の概要

この章では，HiRDBのシステム構築手順，HiRDBのファイル構成及びバージョンアップ手順について説明します。

1.1　オペランド省略時動作の概要

HiRDBでは，HiRDBのバージョン，リビジョンごとにHiRDBシステム定義のオペランド，ユティリティのオプション，及びSQLのオプションの省略値を見直して変更しています。省略値の変更に伴い，バージョン09-50以降，オペランド省略時動作として，推奨値を仮定する推奨モードと，特定のバージョンの省略値を仮定する互換モードを提供しています。通常は，より安全なシステムを構築するために，指定が必要なオペランド数を大幅に削減した推奨モードの適用を検討してください。

09-50より前のバージョンからバージョンアップを行う場合は，省略値変更によるメリット及びデメリットについて，「HiRDBシステム定義のオペランド省略値の確認」，及び「そのほかの省略値の確認」で確認してください。確認の結果，旧バージョンとの互換性を重視する場合は，旧バージョンと同等の省略値になる互換モードを適用してください。ただし，この場合はすべてのオペランドが旧バージョンの省略値となりますので，各オペランドに推奨値を指定することを検討してください。

修正版HiRDBへの入れ替えを行う場合は，既に適用しているオペランド省略時動作を適用してください。

オペランド省略時動作は，HiRDBのインストールで選択できます。また，pdntenvコマンドで変更できます。

1.2　システム構築手順

ここでは，HiRDBを新規導入するときのシステム構築手順について説明します。

1.2.1　HiRDBを新規導入するときのシステム構築手順

HiRDBを新規導入するときのシステム構築手順を次の図に示します。

図1‒1　HiRDBを新規導入するときのシステム構築手順

[picture]

注※1

手順については，「インストール」を参照してください。

注※2

HiRDBの環境設定は次に示すどれかの方法で実施します。

簡易セットアップツールを使用する方法

コマンドを使用する方法

バッチファイルを使用する方法

各環境設定方法について次の表に示します。

表1‒1　各環境設定方法

環境設定方法 | 概要
簡易セットアップツールを使用する方法 | 簡易セットアップツールを使用する方法については，「簡易セットアップツールによる環境設定」を参照してください。
コマンドを使用する方法 | HiRDBのコマンドを使用してHiRDBの環境設定を行います。 コマンドを使用する方法については，「コマンドによる環境設定」を参照してください。
バッチファイルを使用する方法 | バッチファイルを実行してHiRDBの環境設定を行います。 バッチファイルを使用する方法については，「バッチファイルによる環境設定」を参照してください。

注※3

手順については，「データベースの作成」を参照してください。

なお，HiRDBを24時間連続稼働するときにお勧めする運用方法，及び注意事項について，マニュアル「HiRDB システム運用ガイド」で説明しています。必要に応じて参照してください。

1.2.2　HiRDBの環境設定の概要

HiRDB管理者は，次に示すどれかの方法でHiRDBの環境設定をしてください。

簡易セットアップツールを使用する方法

コマンドを使用する方法

バッチファイル（SPsetup.bat）を使用する方法

ポイント

初めてHiRDBの環境を構築する場合は，簡易セットアップツールの使用をお勧めします。

各環境設定方法のメリット及びデメリットを次の表に示します。

表1‒2　各環境設定方法のメリット及びデメリット

環境設定方法 | 概要 | メリット | デメリット
簡易セットアップツールを使用する方法 | HiRDBの環境設定情報を，表示される画面に従って入力していきます。その入力情報を基にHiRDBの環境設定が行われます。 簡易セットアップツールを使用する方法については，「簡易セットアップツールによる環境設定」を参照してください。 | ほかの方法よりも手軽にHiRDBの環境設定ができます。簡易セットアップツールを使用して標準セットアップ又はウィザードセットアップを行えば，テスト環境を構築できます。また，既存のシステム定義の指定値を変更することもできます。※1 | HiRDBのシステム構成が簡易セットアップツールで設定できる範囲に限定されます。
コマンドを使用する方法※2 | HiRDBのコマンドを使用してHiRDBの環境設定を行います。 コマンドを使用する方法については，「コマンドによる環境設定」を参照してください。 | HiRDBのシステム構成を自由に決められます。 | HiRDBの環境設定をするのに，ある一定以上の知識が必要になります。具体的には，このマニュアルで説明している機能や設定内容を理解しておく必要があります。そのため，ほかの方法よりも，環境設定方法が難しくなります。
バッチファイル（SPsetup.bat）を使用する方法※3 | バッチファイルを実行してHiRDBの環境設定を行います。 バッチファイルを使用する方法については，「バッチファイルによる環境設定」を参照してください。 | コマンドを使用する方法よりも手軽にHiRDBの環境設定ができます。バッチファイルを使用してHiRDBの環境設定をすれば，取りあえずHiRDBを開始できるようになります。 | HiRDBのシステム構成がバッチファイルで設定できる範囲に限定されます。

注※1

簡易セットアップツールが生成する値は，あくまでHiRDBのテスト環境を想定したものです。本番環境に適用する場合は，簡易セットアップツールが生成した値をそのまま使用するのではなく，適切な値を見積もって指定してください。

注※2

本番用のシステムを構築する前に簡易導入をお試しください。サンプルファイルを使ってテスト用のシステムでHiRDBの構築手順を一通り実行しておけば，本番用のシステムをより適切に構築できます。

簡易導入の方法については，「サンプルファイル」を参照してください。

注※3

バッチファイルを使用する方法は，HiRDB/シングルサーバのときだけ使えます。HiRDB/パラレルサーバの環境設定については，%PDDIR%¥HiRDEF¥readme.txtを参照してください。

注意事項

簡易セットアップツールの場合，プラグインの環境設定はできません。

バッチファイルの場合，HiRDBの環境設定情報を自動的に設定します。設定し終わった内容を基に，HiRDB管理者が適切な環境に変更します。

1.2.3　ほかの製品と連携する場合の環境設定

ほかの製品と連携する場合の環境設定を次に示します。

(1)　レプリケーション機能を使用する場合

レプリケーション機能を使用するには，HiRDB Datareplicator，HiRDB Dataextractorが必要になります。レプリケーション機能の環境設定方法については，「レプリケーション機能との連携」を参照してください。

(2)　OLTPと連携する場合

OLTPと連携する場合の環境設定方法については，「OLTPとの連携」を参照してください。

(3)　系切り替え機能を使用する場合

系切り替え機能を使用する場合は，クラスタソフトウェアが必要になります。クラスタソフトウェアはプラットフォームごとに異なります。クラスタソフトウェア，及び系切り替え機能の環境設定方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

1.2.4　Windows Terminal Serviceの使用

Windows Terminal Serviceを使用してHiRDBの運用・操作ができます。これによって，遠隔地のマシンや，コンソールがないマシンに対してもHiRDBの運用・操作を行うことが可能となります。Windows Terminal Serviceの詳細については，OSのマニュアルを参照してください。

(1)　注意事項

(a)　 OSがインストールされているディレクトリ下のファイルアクセス

Windows Terminal Serviceを経由してアプリケーションを操作する場合，OSがインストールされているディレクトリ下（例えばc:¥windows）の初期化ファイル（ファイル拡張子がINIのファイル）ではなく，ユーザごとに作成されるディレクトリ下（例えばc:¥windows¥Document and Setting¥ログインユーザ名¥Windows）の初期化ファイルが有効になるときがあります。

このとき，OSがインストールされているディレクトリ下のHiRDB.INIファイルの内容を，ユーザごとに作成されるディレクトリ下のHiRDB.INIファイルに設定する必要があります。ただし，運用コマンド，ユティリティ，クライアントプログラムを実行するコマンドプロンプトなどの実行環境に，クライアント環境定義を設定することでHiRDB.INIファイルの場所の違いによる影響を回避できます。クライアント環境定義の設定方法については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(b)　セキュリティ上の注意事項

Windows Terminal Serviceを使用した場合，サーバのコンソールがログインしていない状態であっても，クライアント側の画面がログインした状態のときがあります。このため，サーバ及びクライアントに次の設定又は運用を行うなどの注意が必要となります。

スクリーンセーバーのパスワードによる保護を付ける

クライアントからの操作が終了した場合，ログオフする

1.3　HiRDBのディレクトリ及びファイル構成

1.3.1　最初に作成するファイル

(1)　HiRDB管理者が作成するディレクトリ及びファイル

HiRDB管理者が作成するディレクトリ及びファイル構成を次の表に示します。

表1‒3　HiRDB管理者が作成するディレクトリ及びファイル構成

ファイル又はディレクトリ名 | 説明
%PDDIR%¥conf¥pdsys | システム共通定義を格納するファイル
%PDDIR%¥conf¥pdutsys | ユニット制御情報定義を格納するファイル
%PDDIR%¥conf¥pdsvrc | サーバ共通定義を格納するファイル
%PDDIR%¥conf¥サーバ名 | 各サーバ定義を格納するファイル
%PDDIR%¥conf¥pduapenv | UAP環境定義を格納するディレクトリ
%PDDIR%¥conf¥chgconf | システム構成変更用定義ファイルを格納するディレクトリ

(2)　HiRDBが作成するディレクトリ及びファイル

HiRDBが作成するディレクトリ及びファイル構成を次の表に示します。

表1‒4　HiRDBが作成するディレクトリ及びファイル構成

ファイル又はディレクトリ名 | 説明
%PDDIR%¥bin | HiRDBのコマンド及びユティリティを格納するディレクトリ
%PDDIR%¥lib | HiRDBの共用ライブラリ，及びメッセージテキストファイルを格納するディレクトリ
%PDDIR%¥lib¥sysconf | HiRDBシステム定義の定義解析用ファイルを格納するディレクトリ
%PDDIR%¥lib¥sysdef
%PDDIR%¥lib¥sysdef_r
%PDDIR%¥lib¥sysdef_v94
%PDDIR%¥lib¥servers | HiRDBサーバの実行ファイル及びライブラリを格納するディレクトリ
%PDDIR%¥lib¥chinese | EUC中国語漢字コードパーサライブラリを格納するディレクトリ
%PDDIR%¥lib¥chinese-gb18030 | 中国語漢字コードパーサライブラリを格納するディレクトリ
%PDDIR%¥lib¥lang-c | 単一バイト文字コードパーサライブラリを格納するディレクトリ
%PDDIR%¥lib¥sjis | シフトJIS漢字コードパーサライブラリを格納するディレクトリ
%PDDIR%¥lib¥utf-8 | Unicode（UTF-8）パーサライブラリを格納するディレクトリ
%PDDIR%¥lib¥utf-8_ivs | Unicode（IVS対応UTF-8）パーサライブラリを格納するディレクトリ
%PDDIR%¥client¥lib | HiRDBクライアントのライブラリを格納するディレクトリ
%PDDIR%¥client¥xds¥lib | バージョン09-50より前のHiRDBとの互換のためのディレクトリ
%PDDIR%¥client¥utl | HiRDBクライアントのコマンド及びユティリティを格納するディレクトリ
%PDDIR%¥client¥include | UAPを作成するときに使用するヘッダ情報を格納するディレクトリ
%PDDIR%¥include | UAPを作成するときに使用するヘッダ情報を格納するディレクトリ
%PDDIR%¥spool | HiRDBの作業ファイルを格納するディレクトリ
%PDDIR%¥spool¥save※１ | 退避コアファイルを格納するディレクトリ
%PDDIR%¥spool¥pdshmdump※１ | 共用メモリダンプファイルを格納するディレクトリ
%PDDIR%¥spool¥pdlckinf※１ | デッドロック・タイムアウト情報ファイル，排他資源管理テーブル情報ファイル，及びデッドロックSQL情報ファイルを格納するディレクトリ
%PDDIR%¥spool¥pdsysdump※１ | システム共通の簡易ダンプファイルを格納するディレクトリ
%PDDIR%¥spool¥pdsdsdump※１ | シングルサーバ用の簡易ダンプファイルを格納するディレクトリ
%PDDIR%¥spool¥pdfesdump※１ | フロントエンドサーバ用の簡易ダンプファイルを格納するディレクトリ
%PDDIR%¥spool¥pddicdump※１ | ディクショナリサーバ用の簡易ダンプファイルを格納するディレクトリ
%PDDIR%¥spool¥pdbesdump※１ | バックエンドサーバ用の簡易ダンプファイルを格納するディレクトリ
%PDDIR%¥spool¥pdstj1，pdstj2 | 統計ログファイル
%PDDIR%¥spool¥pdlog1，pdlog2 | メッセージログファイル
%PDDIR%¥spool¥pdjnlinf | システムログ情報出力ファイルを格納するディレクトリ
%PDDIR%¥spool¥pdjnlinf¥errinf | システムログエラー情報出力ファイルを格納するディレクトリ
%PDDIR%¥spool¥scdqid1，scdqid2 | HiRDB内部のスケジュールキュー情報を格納するファイル
%PDDIR%¥spool¥oslmqid | メッセージキューのIDを格納するファイル
%PDDIR%¥spool¥oslsmid | セマフォのIDを格納するファイル
%PDDIR%¥spool¥pdprcsts | prcステータスファイル
%PDDIR%¥spool¥~pdatmode | 開始・終了用ステータスファイル
%PDDIR%¥spool¥~pdipcid | セマフォのIDを管理するファイル
%PDDIR%¥spool¥~pdommenv | 共用メモリの情報を格納するファイル
%PDDIR%¥spool¥cmdlog¥cmdlog1，cmdlog2 | 実行したコマンドの履歴ファイル
%PDDIR%¥spool¥errlog¥errlog1，errlog2 | HiRDBの内部稼働履歴ファイル
%PDDIR%¥spool¥olkfifs | HiRDB内部用ワークディレクトリ
%PDDIR%¥spool¥olkrsfs | HiRDB内部用ワークディレクトリ
%PDDIR%¥spool¥cnctusrinf | 正常停止又は計画停止コマンド実行時にHiRDBに接続しているユーザがいた場合，接続ユーザ情報を格納するファイル
%PDDIR%¥spool¥cnctusrdtl | 正常停止又は計画停止コマンド実行時にHiRDBに接続しているユーザがいた場合，pdls -d act，pdls -d prc，pdls -d trnのコマンド実行結果を格納するファイル
%PDDIR%¥spool¥pdsqldump※１ | アクセスパス情報ファイルを格納するディレクトリ
%PDDIR%¥spool¥pdprf | PRFトレースファイル出力ディレクトリ
%PDDIR%¥spool¥pdeeinf | バージョン09-50より前のHiRDBとの互換のためのディレクトリ
%PDDIR%¥spool¥pduaperr | SQLエラーレポートファイルディレクトリ
%PDDIR%¥spool¥pdcwwrn | SQL実行時間警告情報ファイルディレクトリ
%PDDIR%¥spool¥utlrpt | 処理性能情報ファイル出力ディレクトリ
%PDDIR%¥spool¥pdrshs1.log，pdrshs2.log | リモート系コマンドの情報を格納するファイル
%PDDIR%¥spool¥pdsha1.log，pdsha2.log | 系切り替え機能の情報を格納するファイル
任意※２ | RPCトレースファイル
%PDDIR%¥tmp※３ | HiRDB内部用ワークディレクトリ
%PDDIR%¥tmp¥pdommenv | 共用メモリの情報を格納するファイル
%PDDIR%¥tmp¥home¥HiRDBが管理する識別子のディレクトリ | カレントワーキングディレクトリ
%PDDIR%¥conf | HiRDBシステム定義ファイルを格納するディレクトリ
%PDDIR%¥conf¥backconf | システム構成変更コマンド実行時の，変更前のHiRDBシステム定義を格納するディレクトリ
%PDDIR%¥.dbenv | HiRDBデータベース環境情報ファイルを格納するディレクトリ
%PDCLTPATH%¥pdsql1.trc，pdsql2.trc※４ | UAPが実行したSQLのトレース情報を格納するファイル
%PDCLTPATH%¥pderr1.trc，pderr2.trc※４ | UAPとサーバ間の通信エラー情報を格納するファイル
%PDDIR%¥plugin | HiRDBプラグイン運用ディレクトリを統括するディレクトリ
%PDDIR%¥plugin¥lib | プラグインライブラリを格納するディレクトリ
%PDDIR%¥plugin¥プラグイン名称 | プラグイン運用ディレクトリ
%PDDIR%¥plugin¥プラグイン名称¥bin | プラグイン専用コマンドを格納するディレクトリ
%PDDIR%¥plugin¥プラグイン名称¥etc | 各プラグイン共通に必要なファイルを格納するディレクトリ
%PDDIR%¥plugin¥プラグイン名称¥conf | プラグイン用コンフィグレーションファイルを格納するディレクトリ
%PDDIR%¥jre※５ | Java実行環境
%PDDIR%¥renew | 修正版HiRDBの入れ替え用ディレクトリ
%PDDIR%¥renew_bak | 修正版HiRDBに入れ替えるときの，稼働中のHiRDBのバックアップ用ディレクトリ
%PDDIR%¥pdistup | 簡易セットアップツールを格納するディレクトリ
%PDDIR%¥sample | サンプルデータベースの実行環境を格納しているディレクトリ
%PDDIR%¥HiRDEF | HiRDB定義支援の実行環境を格納しているディレクトリ
%PDDIR%¥UXPLDIR | システムコールの仕様差吸収ライブラリが使用するディレクトリ
%PDDIR%¥UXPLDIR¥spool¥uxpllog1.txt，uxpllog2.txt | システムコールの仕様差吸収ライブラリが出力する情報を格納するファイル
%PDDIR%¥Setup.ini | インストール情報を管理するファイル
%PDDIR%¥spool¥tmp | 作業用一時ファイル格納ディレクトリ

注※１

このディレクトリは，HiRDBがトラブルシュート情報を出力するディレクトリで，容量が増え続ける可能性があります。そのため，定期的に削除する必要があります。pdcspoolコマンドで定期的に削除してください。

なお，次のオペランドでトラブルシュート情報を定期的に削除する設定ができます。オペランドの詳細は，マニュアル「HiRDB システム定義」を参照してください。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

注※２

pd_rpc_trace_nameオペランドでファイル名を指定します。

注※３

HiRDBが内部的に使用するディレクトリです。このディレクトリ下にディレクトリ及びファイルを作成しないでください。また，HiRDBがファイルを作成するディレクトリにこのディレクトリを指定しないでください（例えば，pd_rpc_trace_nameオペランドなど）。このディレクトリはユニットを開始するときに毎回削除及び新規作成されます。

注※４

このファイルは，PDCLTPATHで指定したディレクトリに二つ出力されます。PDCLTPATHの指定がない場合，UAPを起動したときのカレントディレクトリ（OpenTP1から起動されるUAPの場合，%DCDIR%¥tmp¥home¥サーバ名xxのディレクトリ）下に出力されます。

作成されるファイル名は，X/Openに従ったAPI（TX_関数）の使用の有無によって異なります。TX_関数の使用時に作成されるファイル名は次のようになります。

pdsqlxxxxx-1.trc，pdsqlxxxxx-2.trc

pderrxxxxx-1.trc，pderrxxxxx-2.trc

（凡例）xxxxx：UAP実行時のプロセスID

ファイル名がプロセスIDになるため，UAP実行時のサーバプロセス数分のファイルが出力される可能性があるので注意が必要です。

注※５

バージョン07-03より前の場合は作成されます。バージョン07-03以降の場合は，JREが同梱されないため，作成されません。

1.3.2　単調増加ファイル

HiRDBを使用すると単調増加するファイルを情報の種別ごとに示します。

なお，*は任意の英数字です。また，ファイル名又はディレクトリ名には，標準のパス名を記載しています。システムによっては異なる場合があります。

また，サポートバージョンとは，サポートを開始したバージョンを示します。例えば，サポートバージョンが初期の場合は，全バージョンでサポートしていることになります。

表中の凡例を次に示します。

○：オプションなどで最大サイズを制限できます。

×：最大サイズを制限できません。

S：HiRDB/シングルサーバ

P：HiRDB/パラレルサーバ

DK：HiRDB/Developer's Kit

RT：HiRDB/Run Time

(1)　簡易ダンプ

項番 | ファイル名又はディレクトリ名 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン

1

%PDDIR%¥spool¥pdfesdump¥*

フロントエンドサーバ用の簡易ダンプファイルです。pdfesプロセスセグメンテーション障害，又はアボート時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数MB（不定）

ディレクトリ：

%PDDIR%¥spool¥pdfesdump，pdfesdump1，pdfesdump2でディレクトリ3世代のループ

ファイル：

ディレクトリ下に無制限

×

P

初期

2

%PDDIR%¥spool¥pddicdump¥*

ディクショナリサーバ用の簡易ダンプファイルです。pddicプロセスセグメンテーション障害，アボート，ディクショナリ用RDエリア閉塞時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数MB（不定）

ディレクトリ：

%PDDIR%¥spool¥pddicdump，pddicdump1，pddicdump2でディレクトリ3世代のループ

ファイル：

ディレクトリ下に無制限

×

P

初期

3

%PDDIR%¥spool¥pdbesdump¥*

バックエンドサーバ用の簡易ダンプファイルです。pdbesプロセスセグメンテーション障害，アボート，ユーザ用RDエリア閉塞時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数MB（不定）

ディレクトリ：

%PDDIR%¥spool¥pdbesdump，pdbesdump1，pdbesdump2でディレクトリ3世代のループ

ファイル：

ディレクトリ下に無制限

×

P

初期

4

%PDDIR%¥spool¥pdsdsdump¥*

シングルサーバ用の簡易ダンプファイルです。pdsdsプロセスセグメンテーション障害，アボート，ユーザ用RDエリア閉塞時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数MB（不定）

ディレクトリ：

%PDDIR%¥spool¥pdsdsdump，pdsdsdump1，pdsdsdump2でディレクトリ3世代のループ

ファイル：

ディレクトリ下に無制限

×

S

初期

5

%PDDIR%¥spool¥pdsysdump¥*

システム共通の簡易ダンプファイルです。HiRDBシステムを制御するプロセスの異常終了時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数〜数十MB（不定）

ディレクトリ：

%PDDIR%¥spool¥pdsysdump，pdsysdump1，pdsysdump2でディレクトリ3世代のループ

ファイル：

ディレクトリ下に無制限

×

S，P

初期

(2)　エラー情報

項番 | ファイル名又はディレクトリ名 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン

1

%PDDIR%¥spool¥pdlckinf¥*出力日時

デッドロック・タイムアウト情報ファイルです。排他制御エラー発生時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数KB

無制限

×

S，P

初期

2

%PDDIR%¥spool¥pdlckinf¥出力日時.mem

排他資源管理テーブル情報ファイルです。排他資源管理テーブル不足発生時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数KB

無制限

×

S，P

初期

3

%PDDIR%¥spool¥pdlckinf¥出力日時_サーバ名_トランザクション識別子_スレッドID.sql

デッドロックSQL情報ファイルです。デッドロック発生時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数〜数十KB

無制限

×

S，P

10-08

4

%PDDIR%¥spool¥pdjnlinf¥*

システムログファイルの空き容量監視機能のシステムログファイルの状態情報ファイルです。システムログファイルの空き容量が警告値未満になったときに1ファイル生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

2729〜3521バイト程度

サーバごとに1ファイル

×

S，P

07-00

5

%PDDIR%¥spool¥pdjnlinf¥errinf¥*

システムログエラー情報出力ファイルです。リラン時，システムログ読み込みエラー時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。又はpdstartコマンド実行時（オプションなし，-iオプション指定時，又はdbdestroyオプション指定時）にも削除されます。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

最大値はpd_log_max_data_sizeオペランドの指定値

ログ世代数分（有限個）

×

S，P

初期

6 | %PDCLTPATH%¥pderr1.trc, pderr2.trc | クライアントエラー情報ファイルです。UAP実行時に生成されます。OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDUAPERLOGで指定（省略値は4096バイト） | 2ファイルをラップで使用 | ○ | S，P，DK，RT | 初期
7 | %PDCLTPATH%¥pderrxxxxx-1.trc, pderrxxxxx-2.trc （xxxxx：UAP実行時のプロセスID） | クライアントエラー情報ファイルです （X/Openに従ったAPI（TX_関数）を使用した場合）。UAP実行時に生成されます。OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDUAPERLOGで指定（省略値は4096バイト） | UAPのプロセスIDごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 07-01
8 | %PDCLTPATH%¥pdodberr1.trc, pdodberr2.trc | ODBCエラーログファイル ODBCドライバ内で特定のエラーを検知した場合に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDODBERRTRCSIZEで指定（省略値は65535バイト） | 2ファイルを作成し，ラップで使用 | 〇 | DK，+RT | 10-09

(3)　チューニング情報

項番 | ファイル名又はディレクトリ名 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン

1

%PDDIR%¥spool¥pdsqldump¥*

アクセスパス情報ファイルです。クライアント環境変数PDVWOPTMODEに1以上を指定している場合，SQL文実行時（前処理ごと）に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

（数KB〜数百KB）×トランザクション内SQL数

トランザクションごと

×

S，P

04-03

(4)　トラブルシュート情報

項番 | ファイル名又はディレクトリ名 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン

1

%PDDIR%¥spool¥save¥abcode.*

サーバプロセス異常終了情報（アボートコードなど）です。サーバプロセスの異常終了時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

32ビットモードの場合：40バイト

64ビットモードの場合：72バイト

無制限

×

S，P

初期

2

%PDDIR%¥spool¥save¥*

サーバプロセス異常終了情報（コアファイル）です。サーバプロセスの異常終了時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数MB〜数十MB

ダウンしたサーバ名[1-3]でファイル3世代のループ

（サーバ名が不明な場合，サーバ名が数字となる場合があります）

×

S，P

初期

3

%PDDIR%¥spool¥save¥*.deb

サーバプロセス異常終了情報です。サーバプロセスの異常終了時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数MB〜十数MB

ダウンしたサーバ名[1-3].debでファイル3世代のループ

（サーバ名が不明な場合，サーバ名が数字となる場合があります）

×

S，P

初期

4

%PDDIR%¥spool¥save¥コマンド名*.txt

pdload，pdrorg，pdreclaim，pdpgbfonコマンドのトラブルシュート情報です。コマンドのタイムアウト時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数KB〜数十KB（そのときに実行していたHiRDBのプロセス数や，排他待ち資源数によって変化します）

コマンドのプロセスIDごとに1ファイル

×

S，P

06-02

5

%PDDIR%¥spool¥save¥*.cwaitover

サーバプロセスの異常終了情報です。pd_client_waittime_over_abortオペランドにYを指定している場合，サーバプロセス異常終了時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数MB〜十数MB

無制限

×

S，P

04-05

6

%PDDIR%¥spool¥save¥*.shmdump

共用メモリダンプファイルです。pd_client_waittime_over_abortオペランドにYを指定している場合，HiRDBを起動してから，初回のPDCWAITTIMEオーバに伴うサーバプロセス異常終了時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数百MB〜数GB（pdls -d memコマンドで共用メモリを使用するプロセスの属性が"MANAGER"と表示された共用メモリセグメントのサイズとほぼ同じです）

HiRDBを起動してから初回のPDCWAITTIMEオーバに伴うサーバプロセス異常終了時に１個生成します。※

×

S，P

04-05

7

%PDDIR%¥spool¥pdshmdump¥*

共用メモリダンプファイルです。サーバプロセス異常終了時，ユニット異常終了時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数百MB〜数GB（pdls -d memコマンドで共用メモリを使用するプロセスの属性が"MANAGER"と表示された共用メモリセグメントのサイズとほぼ同じです）

shmdumpとshmdump.oldのファイル2世代でループ

×

S，P

初期

8

%PDDIR%¥spool¥pdshmdump¥*.ucb.*

共用メモリダンプファイルです。サーバプロセス異常終了時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数KB

無制限

×

S，P

初期

9

%PDDIR%¥spool¥pdshmdump¥*.rmb.*

共用メモリダンプファイルです。サーバプロセス異常終了時に生成されます。

自動で削除する場合：

次のオペランドを指定します。

pd_spool_cleanup_interval

pd_spool_cleanup_interval_level

pd_spool_cleanup

pd_spool_cleanup_level

手動で削除する場合：

pdcspoolコマンドを実行します。

なお，%PDDIR%下が容量不足となった場合はユニットダウンします。

数KB

無制限

×

S，P

初期

注※

pd_clt_waittime_over_dump_levelオペランドにshm_fesonlyを指定した場合，クライアントが接続したFESユニットで共用メモリダンプが生成されます。

(5)　インデクス作成用一時ファイル

項番 | ファイル名又はディレクトリ名 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン
1 | pd_plugin_ixmk_dir指定ディレクトリ¥インデクス名称.RDエリア名称 （pd_plugin_ixmk_dirにディレクトリを指定した場合） | プラグインインデクスのインデクス情報ファイルです。SQL文実行時に生成されます。 プラグインインデクスの一括作成が正常終了したとき，プラグインインデクスの再作成を実行したときに，自動で削除されます。 手動で削除する場合はOSのdelコマンドなどを実行します。 | マニュアル「HiRDB システム運用ガイド」の「プラグインインデクスの遅延一括作成」の「注意事項」を参照してください。 | プラグイン数×インデクス格納RDエリア数（更新の発生したRDエリア数） | × | S，P | 05-06

(6)　運用コマンド作業用一時ファイル

項番 | ファイル名又はディレクトリ名 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン
1 | %PDDIR%¥tmp¥CMr* | 運用コマンド一時ファイルです。運用コマンド実行時に生成されます。 運用コマンド実行終了時に自動的に削除されます。 | MAX（1024バイト×グローバルバッファ数，512バイト×RDエリア数） | コマンドのプロセスIDごとに1ファイル | ○ | S，P | 初期
2 | %PDDIR%¥tmp¥CMs* | 運用コマンド一時ファイルです。運用コマンド実行時に生成されます。 運用コマンド実行終了時に自動的に削除されます。 | 128バイト×RDエリア数 | コマンドのプロセスIDごとに1ファイル | ○ | S，P | 初期
3 | %PDDIR%¥tmp¥CMb* | pdbuflsコマンドの差分情報ファイルです。pdbuflsコマンド（-k sts指定，又はオプション指定なし）実行時に生成されます。 HiRDB開始時に自動で削除されます。手動で削除する場合は，pdbuflsコマンドを実行していないときにOSのdelコマンドなどを実行します。 | 16バイト＋124バイト×グローバルバッファ数 | コマンドのプロセスIDごとに1ファイル | ○ | S，P | 初期
4 | %PDDIR%¥tmp¥pdcmd* | 運用コマンド結果ファイルです。運用コマンド実行時に生成されます。運用コマンド実行終了時に自動的に削除されます。 なお，このファイルはHiRDB/パラレルサーバでディクショナリサーバとシステムマネジャが別ノードの場合にだけ使用されます。 | MAX（1024バイト×グローバルバッファ数，512バイト×RDエリア数） | コマンドのプロセスIDごとに1ファイル | ○ | P | 初期
5 | %TMP%¥pddefrev.exp.*（pd_tmp_directoryオペランドは無効です） | pddefrevコマンド作業用一時ファイルです。pddefrevコマンド実行開始時に生成されます。 pddefrevコマンド実行終了時に自動的に削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。 | 搬出対象の資源数×70バイト | コマンドのプロセスIDごとに1ファイル | × | S，P | 04-01
6 | %PDDIR%¥spool¥tmp¥* | 運用コマンド一時ファイルです。運用コマンド実行時に生成されます。運用コマンド実行終了時に自動的に削除されます。 | 最大1024バイト | コマンドのプロセスIDごとに1ファイル | × | S，P | 09-04
7 | %PDDIR%¥tmp¥CMp* | pdchpathfコマンド作業用一時ファイルです。pdchpathfコマンド実行時に作成されます。 pdchpathfコマンド実行終了時に自動的に削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。 | 制御文に指定したarea数×524＋制御文に指定したHiRDBファイルシステム領域内のHiRDBファイル数×72＋330 | pdchpathfの制御文数＋1 | × | S，P | 09-65

(7)　ユティリティ結果ファイル

項番 | ファイル名又はディレクトリ名 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン
1 | %TMP%¥pdcp1*，-pオプション指定ディレクトリ¥pdcp1*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdcopy結果ファイルです。pdcopy実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | 3500バイト×RDエリア数 | pdcopyの-pオプションなしの場合に毎回異なるファイル名で1ファイル | ○ | S，P | 初期
2 | %TMP%¥pdrs1*，-wオプション指定ディレクトリ¥pdrs1*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdrstr結果一時ファイルです（ログ指定回復時のロールバックログ格納一時ファイル）。pdrstr実行時に生成されます。 ロールバック完了時に自動で削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。 | ロールバックログ量に依存します。 | pdrstrの対象RDエリアが属するサーバ数 | × | S，P | 初期
3 | %TMP%¥pdrs2*，-pオプション指定ディレクトリ¥pdrs2*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdrstr結果ファイルです。pdrstr実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | 3500バイト×RDエリア数 | pdrstrの-pオプションなしの場合に毎回異なるファイル名で1ファイル | ○ | S，P | 初期
4 | %TMP%¥pdrs4*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdrstr結果一時ファイルです（メッセージをコンソールに出力するための一時ファイル）。pdrstr実行時に生成されます。 pdrstr実行終了時に自動で削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。 | 256バイト | 1（コマンド実行ノードだけ） | ○ | S，P | 初期
5 | %TMP%¥REPORT*（バージョン08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdrbal処理結果ファイルです。pdrbal実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | 「リバランスユティリティ（pdrbal）実行時のファイルの容量」を参照してください。 | report制御文指定なしの場合に毎回異なるファイル名で1ファイル | × | S，P | 06-00
6 | %TMP%¥CONSTCK-REPORT-*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdconstck処理結果ファイルです。pdconstck実行開始時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | 「整合性チェックユティリティ（pdconstck）実行時のファイルの容量」を参照してください。 | コマンドのプロセスIDごとに1ファイル | × | S，P | 07-03

(8)　ユティリティ作業用一時ファイル

項番 | ファイル名又はディレクトリ名 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン
1 | %TMP%¥pdcp3*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdcopy結果一時ファイル（メッセージをコンソールに出力するための一時ファイル）です。pdcopy実行時に生成されます。 pdcopy実行終了時に自動的に削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。 | 256バイト | 1（コマンド実行ノードだけ） | ○ | S，P | 初期
2 | %TMP%¥pdcp4*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdcopy結果一時ファイル（メッセージ格納一時ファイル）です。pdcopy実行開始時に生成されます。 pdcopy実行終了時に自動的に削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。 | 256バイト×pdcopy対象RDエリア数 | pdcopyの対象RDエリアが属するサーバ数＋2 | ○ | S，P | 初期
3 | %TMP%¥pdrs5*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdrstr結果一時ファイル（メッセージ格納一時ファイル）です。pdrstr実行開始時に生成されます。 pdrstr実行終了時に自動的に削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。 | 256バイト×pdrstr対象RDエリア数 | 対象RDエリアが属するサーバ数＋2 ただし，対象サーバ数が2以上，又は回復対象ユニット以外に存在するログを入力する場合には，さらに+1。 | ○ | S，P | 初期
4 | %TMP%¥ERROR*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdload入力データ格納情報の結果ファイル（エラー情報ファイル）です。pdload実行時に生成されます。OSのdelコマンドなどを実行して手動で削除します。 | 「データベース作成ユティリティ（pdload）実行時のファイルの容量」を参照してください。 | source文でerrorオペランドを指定しない場合，毎回異なるファイル名で1ファイル | × | S，P | 初期
5 | %TMP%¥*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdloadエラー情報ファイル作成用一時ファイルです。pdload実行時に生成されます。OSのdelコマンドなどを実行して手動で削除します。 なお，このファイルはHiRDB/パラレルサーバの場合だけ使用されます。 | 「データベース作成ユティリティ（pdload）実行時のファイルの容量」を参照してください。 | データロード対象表格納サーバ数 | × | S，P | 初期
6 | %TMP%¥LOBMID*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdload BLOB列ロード用ワークファイルです。pdload実行開始時に生成されます。OSのdelコマンドなどを実行して手動で削除します。 | 「データベース作成ユティリティ（pdload）実行時のファイルの容量」を参照してください。 | オプション-kにd以外を指定し，lobmid文を省略してBLOB列を持つ表にデータロードする場合に，毎回異なるファイル名で1ファイル | × | S，P | 03-00

7

%TMP%¥INDEX*，idxwork制御文指定ディレクトリ¥INDEX*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下）

pdload，pdrorg，pdrbalのインデクス情報ファイルです。pdload，pdrorg，pdrbal実行時に生成されます。

インデクスロード完了時に自動的に削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。

次の箇所を参照してください。

「データベース作成ユティリティ（pdload）実行時のファイルの容量」

「データベース再編成ユティリティ（pdrorg）実行時のファイルの容量」

「リバランスユティリティ（pdrbal）実行時のファイルの容量」

インデクス一括作成モード選択時，毎回異なるファイル名でインデクス数×インデクス格納RDエリア数分

×

S，P

初期

8

%TMP%¥rs*，sort制御文指定ディレクトリ¥rs*（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下）

pdload，pdrorg，pdrbalのソート用ワークファイルです。pdload，pdrorg，pdrbal実行時に生成されます。

インデクスロード完了時に自動的に削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。

次の箇所を参照してください。

「データベース作成ユティリティ（pdload）実行時のファイルの容量」

「データベース再編成ユティリティ（pdrorg）実行時のファイルの容量」

「リバランスユティリティ（pdrbal）実行時のファイルの容量」

インデクス一括作成モード選択時，毎回異なるファイル名でインデクス格納サーバ数分

×

S，P

初期

9 | %TMP%¥*.dbst.data，%TMP%¥*.dbst.msg，%TMP%¥*.dbst.head，%TMP%¥*.dbst.stor（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pddbstコマンド一時ファイルです。pddbst実行開始時に生成されます。 pddbst実行終了時に自動的に削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。 | 「データベース状態解析ユティリティ（pddbst）実行時のファイルの容量」を参照してください。 | コマンドのプロセスIDごとにそれぞれ1ファイル | × | S，P | 初期
10 | %TMP%¥*.syi，*.syo，*.uai，*.uao，*.sqi，*.sqo，*.pci，*.pco，*.soi，*.soo，*.doi，*.doo，*.bui，*.buo，*.fii，*.fio，*.dfi，*.dfo，*.ixi，*.ixo，*.isi，*.iso，*.cni，*.cno，*.qhi，*.qho，*.shi，*.sho，*.obi，*.obo，*.fsi，*.fso，*.hbi，*.hbo， -wオプション指定ディレクトリ¥***（08-02以降でpd_tmp_directoryオペランド指定時はpd_tmp_directoryディレクトリ下） | pdsteditコマンド作業用一時ファイルです。pdstedit実行開始時に生成されます。 pdstedit実行終了時に自動的に削除されます。手動で削除する場合は，OSのdelコマンドなどを実行します。 | 「統計解析ユティリティ（pdstedit）実行時のファイルの容量」を参照してください。 | コマンドのプロセスIDごと，かつ解析対象の情報ごとに1ファイル | × | S，P | 初期

(9)　トレース情報

項番 | ファイル名又はディレクトリ名 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン
1 | %PDCLTPATH%¥pdsql1.trc，pdsql2.trc | SQLトレース情報（クライアント環境変数PDSQLTRCFMTに1を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDSQLTRACEで指定 | 2ファイルをラップで使用 | ○ | S，P，DK，RT | 初期
2 | %PDCLTPATH%¥pdsqlxxxxx-1.trc，pdsqlxxxxx-2.trc xxxxx：UAP実行時のプロセスID） | SQLトレース情報（X/Openに従ったAPI（TX_関数を使用，かつクライアント環境変数PDSQLTRCFMTに1を指定した場合）を使用した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDSQLTRACEで指定 | UAPのプロセスIDごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 07-01
3 | %PDCLTPATH%¥pdjsqlxxxxxxxx_ppppp_1.trc，pdjsqlxxxxxxxx_ppppp_2.trc xxxxxxxx：接続したサーバ名 ppppp：クライアント側の受信ポート番号 | SQLトレース情報（Type4 JDBCドライバを使用，かつクライアント環境変数PDSQLTRCFMTに1を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDSQLTRACEで指定 | 接続したサーバ名とクライアント側の受信ポート番号ごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 08-00
4 | %PDTRCPATH%¥pdjsqlxxxxxxxx_ppppp_1.trc，pdjsqlxxxxxxxx_ppppp_2.trc xxxxxxxx：接続したサーバ名 ppppp：クライアント側の受信ポート番号 | 動的SQLトレース（クライアント環境変数PDSQLTRCFMTに1を指定，pdtrcmgrコマンドを使用，かつType4 JDBCドライバを使用した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | pdtrcmgr -sコマンドで指定 | 接続したサーバ名とクライアント側の受信ポート番号ごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 08-00
5 | pdoletrc.txt | OLEDBメソッドトレースです。OLEDBプロバイダアクセス時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | サイズ指定はありません。 | 1ファイル | × | S，P，DK，RT | 05-06
6 | %PDJDBFILEDIR%¥pdexc1.trc，pdexc2.trc | Exceptionトレースログです。Type4 JDBCドライバ内で例外発生時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | マニュアル「HiRDB UAP開発ガイド」の「Exceptionトレースログ」を参照してください。 | 2ファイルをラップで使用 | ○ | S，P，DK，RT | 08-00
7 | ユーザ指定（DriverManagerクラスのsetLogWriterメソッド，DataSourceインタフェースのsetLogWriterメソッドで指定） | JDBCインタフェースメソッドトレースです。Type4 JDBCドライバ内で例外発生時，Connection.closeメソッド実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | ↑180×n×m÷1024↑　キロバイト n：接続時に指定するユーザプロパティのTRC_NOで指定（省略値は500） m：接続から切断までの例外発生回数＋1 | 1ファイル | ○ | S，P，DK，RT | 08-00
8 | %PDTRCPATH%¥pdcHHMMSSmmm_XXX_1.trc，pdcHHMMSSmmm_XXX_2.trc HHMMSSmmm：CONNECT時間 XXX：CONNECT通番 | 動的SQLトレース（pdtrcmgrコマンドを使用，かつクライアント環境変数PDSQLTRCFMTに1を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | pdtrcmgr -sコマンドで指定 | コネクトごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 06-00
9 | %PDDIR%¥spool¥pdhrslog_*.log | Windowsダンプの出力情報です。インストール時に生成されます。OSのdelコマンドなどを実行して手動で削除します。 | 5MB | 2ファイルをラップで使用 | × | S，P | 09-04
10 | %PDCLTPATH%¥pdrcnct1.trc，pdrcnct2.trc | 再接続トレースです。自動再接続機能で自動的に接続したときに生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDRCTRACEで指定 | 2ファイルをラップで使用 | ○ | S，P，DK，RT | 07-01
11 | %PDCLTPATH%¥pddndpxxxx_yyy_1.trc，pddndpxxxx_yyy_2.trc xxxx：プロセスID yyy：コネクト通番 | HiRDBデータプロバイダ for .NET Frameworkのメソッドトレースです。サーバとの接続中，HiRDBデータプロバイダ for .NET Frameworkのメソッド及びプロパティ呼び出し時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDDNDPTRACEで指定 | 接続ごとに2ファイルをラップで使用 | ○ | DK，RT | 08-05
12 | %PDJDBFILEDIR%¥pdjdataerr1.trc，pdjdataerr2.trc | 不正電文トレースです。Type4 JDBCドライバ内で不正電文受信時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | マニュアル「HiRDB UAP開発ガイド」の「不正電文トレース」を参照してください。 | 2ファイルをラップで使用 | ○ | S，P，DK，RT | 09-60
13 | %PDCLTPATH%¥pdXXXXXXXXyyyyyyyyyy_1.trc，pdXXXXXXXXyyyyyyyyyy_2.trctrc XXXXXXXX：接続したサーバ名 yyyyyyyyyy：サーバプロセスID | 動的SQLトレース（pdclttrcコマンドを使用，かつクライアント環境変数PDSQLTRCFMTに1を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | pdclttrcコマンドの-oで指定 | コネクトごとに2ファイルを作成し，ラップで使用 | 〇 | S，P，DK，RT | 07-01
14 | %PDCLTPATH%¥pdjsqlxxxxxxxx_ppppp_1.trc，pdjsqlxxxxxxxx_ppppp_2.trc xxxxxxxx：接続したサーバ名 ppppp：クライアント側の受信ポート番号 | 動的SQLトレース（pdclttrcコマンドを使用，Type4 JDBCドライバを使用，かつクライアント環境変数PDSQLTRCFMTに1を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | pdclttrcコマンドの-oで指定 | 接続したサーバ名とクライアント側の受信ポート番号ごとに2ファイルを作成し，ラップで使用 | 〇 | S，P，DK，RT | 08-00
15 | %PDCLTPATH%¥pdjsql1.trc，pdjsql2.trc | SQLトレース情報（Type4 JDBCドライバを使用しサーバと接続できなかった場合，かつクライアント環境変数PDSQLTRCFMTに1を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDSQLTRACEで指定 | 2ファイルをラップで使用 | 〇 | S，P，DK，RT | 08-00
16 | %PDCLTPATH%¥pd2sql1.trc，pd2sql2.trc | SQLトレース情報（クライアント環境変数PDSQLTRCFMTに2を指定し，サーバと接続できなかった場合又はクライアント環境変数PDXATRCFILEMODEにLUMPを指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDSQLTRACEで指定 | 2ファイルをラップで使用 | 〇 | S，P，DK，RT | 09-50

17

%PDCLTPATH%¥pd2sqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc，pd2sqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

SQLトレース情報（クライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

クライアント環境変数PDSQLTRACEで指定

コネクトごとに2ファイルを作成し，ラップで使用

〇

S，P，DK，RT

09-50

18

%PDTRCPATH%¥pd2csqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc，

pd2csqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

動的SQLトレース（pdtrcmgrコマンドを使用，かつクライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

pdtrcmgr -sコマンドで指定

コネクトごとに2ファイルを作成し，ラップで使用

〇

S，P，DK，RT

09-50

19 | %PDCLTPATH%¥pd2XXXXXXXXyyyyyyyyyy_1.trc，pd2XXXXXXXXyyyyyyyyyy_2.trc XXXXXXXX：接続したサーバ名 yyyyyyyyyy：サーバプロセスID | 動的SQLトレース（pdclttrcコマンドを使用，かつクライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | pdclttrcコマンドの-oで指定 | コネクトごとに2ファイルを作成し，ラップで使用 | 〇 | S，P，DK，RT | 09-50
20 | %PDCLTPATH%¥pd2jsql1.trc，pd2jsql2.trc | SQLトレース情報（Type4 JDBCドライバを使用しサーバと接続できなかった場合，かつクライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDSQLTRACEで指定 | 2ファイルをラップで使用 | 〇 | S，P，DK，RT | 09-50

21

%PDCLTPATH%¥pd2jsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc，pd2jsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

SQLトレース情報（Type4 JDBCドライバを使用，かつクライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

クライアント環境変数PDSQLTRACEで指定

コネクトごとに2ファイルを作成し，ラップで使用

〇

S，P，DK，RT

09-50

22

%PDTRCPATH%¥pd2jcsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc，pd2jcsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

動的SQLトレース（pdtrcmgrコマンドを使用，Type4 JDBCドライバを使用，かつクライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

pdtrcmgr -sコマンドで指定

コネクトごとに2ファイルを作成し，ラップで使用

〇

S，P，DK，RT

09-50

23 | %PDCLTPATH%¥pd2jXXXXXXXXyyyyyyyyyy_1.trc，pd2jXXXXXXXXyyyyyyyyyy_2.trc XXXXXXXX：接続したサーバ名 yyyyyyyyyy：サーバプロセスID | 動的SQLトレース（pdclttrcコマンドを使用，Type4 JDBCドライバを使用，かつクライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | pdclttrcコマンドの-oで指定 | コネクトごとに2ファイルを作成し，ラップで使用 | 〇 | S，P，DK，RT | 09-50
24 | %PDCLTPATH%¥pdrcnct_ppppp_1.trc，pdrcnct_ppppp_2.trc ppppp：クライアント側の受信ポート番号 | 再接続トレース（Type4 JDBCドライバを使用した場合）です。自動再接続機能で自動的に接続したときに生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDRCTRACEで指定 | クライアント側の受信ポート番号ごとに2ファイルを作成し，ラップで使用 | 〇 | S，P，DK，RT | 08-00
25 | %PDWRTLNPATH%¥pdwrtln1.trc，pdwrtln2.trc | WRITE LINE文の値式の値を出力するファイルです。WRITE LINE文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDWRTLNFILSZで指定 | 2ファイルをラップで使用 | 〇 | S，P，DK，RT | 07-00
26 | %PDWRTLNPATH%¥pdwrtlnxxxxx-1.trc，pdwrtlnxxxxx-2.trc xxxxx：クライアントプロセスID | WRITE LINE文の値式の値を出力するファイル（X/Openに従ったAPI（TX_関数）を使用した場合）です。WRITE LINE文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDWRTLNFILSZで指定 | クライアントプロセスごとに2ファイルを作成しラップで使用 | 〇 | S，P，DK，RT | 07-00
27 | %PDWRTLNPATH%¥pdwrtlnXXXXXXXX_ppppp_1.trc，pdwrtlnXXXXXXXX_ppppp_2.trc XXXXXXXX：接続したサーバ名 ppppp：クライアント側の受信ポート番号 | WRITE LINE文の値式の値を出力するファイル（Type4 JDBCドライバを使用した場合）です。WRITE LINE文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDWRTLNFILSZで指定 | 接続したサーバ名とクライアント側の受信ポート番号ごとに2ファイルを作成し，ラップで使用 | 〇 | S，P，DK，RT | 08-00

28

%PDCLTPATH%¥pdjsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc，pdjsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

SQLトレース情報（Type4 JDBCドライバを使用，クライアント環境変数PDSQLTRCFMTに1を指定，かつクライアント環境変数PDCONTYPEにACTIVEを指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

クライアント環境変数PDSQLTRACEで指定

コネクトごとに2ファイルを作成し，ラップで使用

〇

S，P，DK，RT

10-07

29

%PDTRCPATH%¥pdjsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc，pdjsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

動的SQLトレース（pdtrcmgrコマンドを使用，Type4 JDBCドライバを使用，クライアント環境変数PDSQLTRCFMTに1を指定，かつクライアント環境変数PDCONTYPEにACTIVEを指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

pdtrcmgr -sコマンドで指定

コネクトごとに2ファイルを作成し，ラップで使用

〇

S，P，DK，RT

10-07

30

%PDCLTPATH%¥pdjsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc，pdjsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

動的SQLトレース（pdclttrcコマンドを使用，Type4 JDBCドライバを使用，クライアント環境変数PDSQLTRCFMTに1を指定，かつクライアント環境変数PDCONTYPEにACTIVEを指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

pdclttrcコマンドの-oで指定

コネクトごとに2ファイルを作成し，ラップで使用

〇

S，P，DK，RT

10-07

31

%PDCLTPATH%¥pdrcnct_HHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc，pdrcnct_HHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

再接続トレース（Type4 JDBCドライバを使用，かつクライアント環境変数PDCONTYPEにACTIVEを指定した場合）です。自動再接続機能で自動的に接続したときに生成されます。

OSのdelコマンドなどを実行して手動で削除します。

クライアント環境変数PDRCTRACEで指定

コネクトごとに2ファイルを作成し，ラップで使用

〇

S，P，DK，RT

10-07

32

%PDWRTLNPATH%¥pdwrtlnHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc，pdwrtlnHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

WRITE LINE文の値式の値を出力するファイル（Type4 JDBCドライバを使用，かつクライアント環境変数PDCONTYPEにACTIVEを指定した場合）です。WRITE LINE文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

クライアント環境変数PDWRTLNFILSZで指定

コネクトごとに2ファイルを作成し，ラップで使用

〇

S，P，DK，RT

10-07

(10)　統計情報

項番 | ファイル名又はディレクトリ名 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン
1 | %PDREPPATH%¥pdHHMMSSmmm_XXX_1.trc，pdHHMMSSmmm_XXX_2.trc HHMMSSmmm：CONNECT時間 XXX：CONNECT通番 | UAP統計レポート（クライアント環境変数PDSQLTRCFMTに1を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDSQLTRACEで指定 | コネクトごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 06-00
2 | %PDREPPATH%¥pdjsqlxxxxxxxx_ppppp_1.trc，pdjsqlxxxxxxxx_ppppp_2.trc xxxxxxxx：接続したサーバ名 ppppp：クライアント側の受信ポート番号 | UAP統計レポート（クライアント環境変数PDSQLTRCFMTに1を指定，かつType4 JDBCドライバを使用した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | クライアント環境変数PDSQLTRACEで指定 | 接続したサーバ名とクライアント側の受信ポート番号ごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 08-00
3 | %PDREPPATH%¥pdXXXXXXXXyyyyyyyyyy_1.trc，pdXXXXXXXXyyyyyyyyyy_2.trc XXXXXXXX：接続したサーバ名 yyyyyyyyyy：サーバプロセスID | 動的UAP統計レポート（pdclttrcコマンドを使用，かつクライアント環境変数PDSQLTRCFMTに1を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | pdclttrcコマンドの-oで指定 | コネクトごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 07-01
4 | %PDREPPATH%¥pdjsqlxxxxxxxx_ppppp_1.trc，pdjsqlxxxxxxxx_ppppp_2.trc xxxxxxxx：接続したサーバ名 ppppp：クライアント側の受信ポート番号 | 動的UAP統計レポート（pdclttrcコマンドを使用，クライアント環境変数PDSQLTRCFMTに1を指定，かつType4 JDBCドライバを使用した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | pdclttrcコマンドの-oで指定 | 接続したサーバ名とクライアント側の受信ポート番号ごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 08-00

5

%PDREPPATH%¥pd2sqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc，pd2sqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

UAP統計レポート（クライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

クライアント環境変数PDSQLTRACEで指定

コネクトごとに2ファイルを作成し，ラップで使用

○

S，P，DK，RT

09-50

6 | %PDREPPATH%¥pd2XXXXXXXXyyyyyyyyyy_1.trc, pd2XXXXXXXXyyyyyyyyyy_2.trc XXXXXXXX：接続したサーバ名 yyyyyyyyyy：サーバプロセスID | 動的UAP統計レポート（pdclttrcコマンドを使用，かつクライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | pdclttrcコマンドの-oで指定 | コネクトごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 09-50

7

%PDREPPATH%¥pd2jsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc, pd2jsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

UAP統計レポート（Type4 JDBCドライバを使用，かつクライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

クライアント環境変数PDSQLTRACEで指定

コネクトごとに2ファイルを作成し，ラップで使用

○

S，P，DK，RT

09-50

8 | %PDREPPATH%¥pd2jXXXXXXXXyyyyyyyyyy_1.trc, pd2jXXXXXXXXyyyyyyyyyy_2.trc XXXXXXXX：接続したサーバ名 yyyyyyyyyy：サーバプロセスID | 動的UAP統計レポート（pdclttrcコマンドを使用，Type4 JDBCドライバを使用，かつクライアント環境変数PDSQLTRCFMTに2を指定した場合）です。SQL文実行時に生成されます。 OSのdelコマンドなどを実行して手動で削除します。 | pdclttrcコマンドの-oで指定 | コネクトごとに2ファイルを作成し，ラップで使用 | ○ | S，P，DK，RT | 09-50

9

%PDREPPATH%¥pdjsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc, pdjsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

UAP統計レポート（Type4 JDBCドライバを使用，クライアント環境変数PDSQLTRCFMTに1を指定,かつクライアント環境変数PDCONTYPEにACTIVEを指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

クライアント環境変数PDSQLTRACEで指定

コネクトごとに2ファイルを作成し，ラップで使用

○

S，P，DK，RT

10-07

10

%PDREPPATH%¥pdjsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_1.trc, pdjsqlHHMMSSfff_XXXXXXXX_YYYYYYYYYY_2.trc

HHMMSSfff：コネクト要求時間（HH：時，MM：分，SS：秒，fff：ミリ秒）

XXXXXXXX：接続したサーバ名

YYYYYYYYYY：コネクト通番

動的UAP統計レポート（pdclttrcコマンドを使用，Type4 JDBCドライバを使用，クライアント環境変数PDSQLTRCFMTに1を指定，かつクライアント環境変数PDCONTYPEにACTIVEを指定した場合）です。SQL文実行時に生成されます。

OSのdelコマンドなどを実行して手動で削除します。

pdclttrcコマンドの-oで指定

コネクトごとに2ファイルを作成し，ラップで使用

○

S，P，DK，RT

10-07

(11)　Windowsのダンプ

項番 | ファイル名又はディレクトリ名※1，※2 | 説明 | ファイルサイズの概算値 | ファイル数 | 最大サイズの制限可否 | 出力される製品種別 | サポートバージョン
1 | ユーザ指定値¥CrashDumps¥pdsds.exe¥* | セグメンテーション障害発生時に生成されます。削除する場合はOSのdelコマンドなどを実行して手動で削除します。 | 32ビットモードの場合：30MB 64ビットモードの場合：50MB | 10世代でループ | × | S | 09-04
2 | ユーザ指定値¥CrashDumps¥pdfes.exe¥* | セグメンテーション障害発生時に生成されます。削除する場合はOSのdelコマンドなどを実行して手動で削除します。 | 32ビットモードの場合：30MB 64ビットモードの場合：50MB | 10世代でループ | × | P | 09-04
3 | ユーザ指定値¥CrashDumps¥プロセス名¥* | セグメンテーション障害発生時に生成されます。削除する場合はOSのdelコマンドなどを実行して手動で削除します。 | 2MB | 10世代でループ | × | S，P | 09-04

注※1

pdntenv -wdコマンドでディレクトリを確認できます。

注※2

ディレクトリのデフォルト値

OSのドライブ:¥Users¥ユーザー名¥AppData¥Local¥CrashDumps¥プロセス名

1.4　HiRDBのバージョンアップ

HiRDBをバージョンアップする方法について説明します。

バージョンアップとは，HiRDBのバージョン又はリビジョンをアップグレードすること（VV-RR-ZZの形式で示すHiRDBのバージョン番号のうち，VV又はRRが上がること）を指します。

HiRDB/パラレルサーバをバージョンアップする場合は，すべてのユニットをバージョンアップして，HiRDB/パラレルサーバを構成するすべてのユニット間のバージョンを合わせてください。

注意事項

HiRDBをバージョンアップするときに，旧バージョンのHiRDBをアンインストールしないでください。新バージョンのHiRDBを上書きインストールしてください。

セキュリティ監査機能を使用している場合にバージョンアップするときは，注意事項があります。注意事項については，マニュアル「HiRDB システム運用ガイド」を参照してください。

Javaストアドプロシジャ及びJavaストアドファンクションを使用している場合に07-03以降にバージョンアップするときは，注意事項があります。注意事項については，「Javaストアドプロシジャ及びJavaストアドファンクションを使用する場合」を参照してください。

暗号化列を含む表を使用している場合，10-05以前から10-06以降へのバージョンアップについては，「暗号化列を含む表を使用している場合」を参照してください。

1.4.1　バージョンアップ前にすること

バージョンアップをする前に，次に示す内容を必ず実施してください。

また，セキュリティ監査機能を使用している場合は，マニュアル「HiRDB システム運用ガイド」の「バージョンアップ時の注意事項」も参照してください。

以降，Windowsの［コマンドプロンプト］の画面を使って，コマンドとユティリティを実行してください。

(1)　空き領域の確認

データベース状態解析ユティリティ（pddbst）で，データディクショナリ用RDエリアに必要な空き領域があるかどうかを確認してください。空き領域がない場合は，次に示すどちらかの方法で空き領域を確保してください。

データベース再編成ユティリティ（pdrorg）でディクショナリ表を再編成します。

データベース構成変更ユティリティ（pdmod）でデータディクショナリ用RDエリアを拡張します。

この空き領域の確認は，旧バージョンと新バージョンを入れ替えるときにだけ必要です。修正版HiRDBへの入れ替えの場合は不要です。

ユティリティを実行する方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

バージョンアップに必要な空き領域

バージョンアップをする前のHiRDBのバージョンに応じて，次の表に示す空き領域があるかどうかを確認してください。空き領域が不足していると，バージョンアップ後のHiRDB開始時又はpdvrupコマンド実行時に容量不足でエラーとなることがあります。

表1‒5　バージョンアップするのに必要な空き領域

データディクショナリ用 RDエリアに格納している ディクショナリ表 | データディクショナリ用RDエリアに 必要な空きセグメント数

08-00以降

から

バージョン

アップ

する場合

09-00以降

から

バージョン

アップ

する場合

10-00以降

から

バージョン

アップ

する場合

SQL_COLUMNS表 | ↑34÷S↑ | ↑22÷S↑ | ↑2÷S↑
SQL_INDEXES表 | ↑5÷S↑ | ↑4÷S↑ | −
SQL_INDEX_COLINF表 | ↑5÷S↑ | ↑5÷S↑ | ↑5÷S↑
SQL_VIEWS表 | ↑23÷S↑ | ↑16÷S↑ | ↑4÷S↑
SQL_VIEW_DEF表 | ↑122÷S↑ | ↑83÷S↑ | ↑20÷S↑
SQL_VIEW_TABLE_USAGE表 | ↑5÷S↑ | ↑5÷S↑ | −
SQL_TABLES表 | ↑9÷S↑ | ↑9÷S↑ | −
SQL_TABLE_PRIVILEGES表 | ↑5÷S↑ | ↑5÷S↑ | −
SQL_USER表 | ↑2÷S↑ | ↑2÷S↑ | ↑2÷S↑
SQL_ACCESS_SECURITY表 | ↑2÷S↑ | ↑2÷S↑ | ↑2÷S↑
SQL_ROUTINES表※ | ↑14÷S↑ | − | −
SQL_ROUTINE_PARAMS表※ | ↑10÷S↑ | − | −

（凡例）

−：該当しません。

S：対象表を格納するデータディクショナリ用RDエリアのセグメントサイズ

注※

データディクショナリLOB用RDエリアを定義していない場合は不要です。

(2)　システム用RDエリアのバックアップの取得

データベース複写ユティリティ（pdcopy）で，次に示すRDエリアのバックアップを取得してください。

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

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

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

監査証跡表を格納しているRDエリア（セキュリティ監査機能を使用している場合）

ただし，バージョンアップに成功した後にバージョンダウンを行う場合（例えば，テストのために一度バージョンアップした後，バージョンダウンして元の運用に戻す場合など）は，全RDエリアのバックアップを取得しておく必要があります。

バックアップの取得手順

pdstopコマンドでHiRDBを正常終了させます。

pdstart -rコマンドでHiRDBを開始します。

データベース複写ユティリティ（pdcopy）でRDエリアのバックアップを取得します。このとき，参照・更新不可能モード（-M x指定）を指定してください。バックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」又は「HiRDB コマンドリファレンス」を参照してください。

(3)　HiRDBがオンライン状態であるかどうかの確認

pdlsコマンドですべてのユニットがACTIVEと表示されているかどうかを確認してください。ACTIVEと表示されている場合，pdstopコマンドで正常終了させてください。

(4)　HiRDBの正常終了

バージョンアップする前にHiRDBを正常終了させてください。HiRDB/パラレルサーバの場合はシステムマネジャがあるマシンから終了させてください。HiRDBが既に終了している場合は，次に示す情報を参照してHiRDBが正常終了しているかどうかを確認してください。

メッセージログファイル又はイベントログ

正常終了していない場合は，pdstartコマンドでいったんHiRDBを開始して，pdstopコマンドで正常終了させてください。

(5)　HiRDBの状態確認

HiRDBをバージョンアップするユニットの状態を確認するため，pdls -d ustコマンドを実行します。

終了ステータスが4の場合（ユニットの状態がSTARTING又はSTOPPING）：

HiRDBが開始処理の途中，又は停止処理の途中です。処理が終了してからpdls -d ustコマンドを再度実行してください。

終了ステータスが8の場合（ユニットの状態がPAUSE）：

障害によって，プロセスサービスの再起動を中断した状態です。KFPS00715-Eメッセージ及びこのメッセージ以前のイベントログに出力されたメッセージを参照して障害の原因を取り除いてから，サービスを開始してください。その後，ユニットを再開始して，pdstopコマンドで正常終了させてください。

(6)　HiRDBのサービスの停止

バージョンアップする前にバージョンアップするHiRDBのサービスを停止してください。サービスの停止方法及び確認方法については，OSのマニュアルを参照してください。

(7)　コマンド，ユティリティ，アプリケーション，及びHiRDBと連携している製品の停止

コマンド，ユティリティ，アプリケーションは終了させてください。また，HiRDB Datareplicator，HiRDB Dataextractor，及びJP1/PFMなどのHiRDBにアクセスする連携製品についても，あらかじめ停止しておいてください。これらを停止しないと，実行形式ファイルや共用ライブラリの削除に失敗し，バージョンアップに失敗することがあります。

(8)　HiRDBシステム定義のオペランド省略値の確認

HiRDBでは，HiRDBのバージョン，リビジョンごとにHiRDBシステム定義の省略値を見直して変更しています。バージョン09-50以降，オペランド省略時動作として，推奨値を仮定する推奨モードと，特定のバージョンの省略値を仮定する互換モードを提供しています。通常は，より安全なシステムを構築するために，指定が必要なオペランド数を大幅に削減した推奨モードの適用を検討してください。バージョン09-50以降，特定のバージョンの省略値を仮定する場合は互換モードを適用し，pd_sysdef_default_optionオペランドは指定しないでください。

バージョン09-50より前のバージョンからバージョンアップを行う場合

省略値変更によるメリット及びデメリットについて，マニュアル「HiRDB システム定義」の「バージョン，リビジョンによるHiRDBシステム定義の変更点」で確認してください。確認の結果，旧バージョンとの互換性を重視する場合は，旧バージョンと同等の省略値になる互換モードを適用してください。ただし，この場合はすべてのオペランドが旧バージョンの省略値となりますので，各オペランドに推奨値を指定することを検討してください。

バージョン07-00以前からのバージョンアップを行う場合，又はpd_sysdef_default_optionオペランドを指定している場合

前述の「バージョン09-50より前のバージョンからバージョンアップを行う場合」の変更に加えて，マニュアル「HiRDB システム定義」の「バージョン09-50より前のバージョンで省略値が変更になったオペランド，及び指定不要になったオペランド」のメリットの説明を参照して，各オペランドの指定値に推奨値を指定することを検討してください。

(9)　そのほかの省略値の確認

HiRDBでは，ユティリティのオプション，SQLのオプション，及びリソース数に関連する環境変数をHiRDBのバージョン，リビジョンごとに見直して変更しています。

バージョン09-50より前のバージョンからバージョンアップを行う場合は，省略値変更によるメリット及びデメリットを次の箇所で確認してください。確認の結果，旧バージョンとの互換性を重視する場合は，旧バージョンと同等の省略値になる互換モードを適用してください。ただし，この場合はすべてのオペランドが旧バージョンの省略値となりますので，各オペランドに推奨値を指定することを検討してください。

マニュアル「HiRDB コマンドリファレンス」の「バージョンアップによって省略値が変更，又は指定不要になったオプション及び制御文」

マニュアル「HiRDB SQLリファレンス」の「バージョン，リビジョンによるSQL構文の省略時解釈の変更点」

「リソース数に関連する環境変数の見積もり」

(10)　メモリ所要量の確認

HiRDBをバージョンアップすると，HiRDBのメモリ所要量が増えることがあります。「HiRDBのメモリ所要量」を参照してHiRDBのメモリ所要量を確認してください。

(11)　ステータスファイルの容量の確認

HiRDBをバージョンアップすると，HiRDBのステータスファイル容量が増えることがあります。「ステータスファイルの容量の見積もり」を参照してHiRDBのステータスファイルの容量を確認してください。

(12)　シンクポイントダンプファイルの容量の確認

HiRDBをバージョンアップすると，HiRDBのシンクポイントダンプファイルの容量が増えることがあります。「シンクポイントダンプファイルの容量の見積もり」を参照してHiRDBのシンクポイントダンプファイルの容量を確認してください。

(13)　システムログファイルの総レコード数の確認

バージョンアップする場合は，上書きできる状態のシステムログファイルの総レコード数を確認してください。次の表に示す総レコード数より少ないと，バージョンアップに失敗することがあります。

表1‒6　バージョンアップするのに必要なシステムログファイルの総レコード数

対象バージョン | 総レコード数※
システムログファイルのレコード長
1024の場合 | 2048の場合 | 4096の場合
08-00以降から バージョンアップする場合 | 2850 | 1530 | 870
09-00以降から バージョンアップする場合 | 1880 | 1020 | 600
10-00以降から バージョンアップする場合 | 450 | 250 | 150

なお，HiRDB/パラレルサーバの場合は，ディクショナリサーバのシステムログファイル（上書きできる状態）の総レコード数を確認してください。

注※

次に示すどちらかの方法でシステムログファイルの総レコード数を確認してください。

pdloginitコマンドの-nオプションの指定値の合計が総レコード数となります。

pdlogls -d sys -s サーバ名 -eコマンドを実行してください。実行結果のRecode-countの先頭部分に出力されたレコード数（16進数）の合計が総レコード数となります。

(14)　HiRDB運用ディレクトリ下のファイルのバックアップの取得

バージョンアップの失敗に備えて，HiRDB運用ディレクトリ下（%PDDIR%¥conf下）のファイルのバックアップを取得してください。取得したバックアップは，新バージョンの動作確認後に削除してください。

(15)　付加PPのバージョンアップ

バージョンアップ前のHiRDBで付加PPを使用していた場合，HiRDBと同じバージョンの付加PPをインストールする必要があります。付加PPについては，「付加PPのインストール時の注意」を参照してください。

(16)　追加された予約語の確認

SQLの拡張に伴って，HiRDBの各バージョンで次の予約語を追加しています。SQL文中に，予約語と同じ名前を引用符で囲まないで使用している場合は，バージョンアップ後にSQL文が文法エラーになることがあります。

HiRDBのバージョン | 追加した予約語
06-00 | GET_JAVA_STORED_ROUTINE_SOURCE， IS_USER_CONTAINED_IN_HDS_GROUP
06-01 | なし
06-02 | BIT_AND_TEST

07-00

CONDITION，

EXIT，

HANDLER，

TIMESTAMP_FORMAT，

VARCHAR_FORMAT

07-01 | FREE， LOCATOR
07-02 | なし
07-03 | OVER
08-00 | ENCRYPT
08-01 | なし

08-02

COUNT_FLOAT，

SQLCODE_OF_LAST_CONDITION，

SQLERRM_OF_LAST_CONDITION，

XML，

XMLAGG，

XMLEXISTS，

XMLQUERY，

XMLSERIALIZE

08-03 | なし
08-04 | XMLPARSE
08-05 | なし
09-00 | なし
09-01 | なし
09-02 | なし
09-03 | COMPRESSED
09-04 | TRUNCATE

引用符で囲んでいない名前が，追加された予約語と重複している場合は，マニュアル「HiRDB SQL リファレンス」の「SQLの予約語と重複したときの対応」を参照して，対処してください。

1.4.2　旧バージョンと新バージョンを入れ替える場合

旧バージョンと新バージョンを入れ替える場合の操作手順を次の図に示します。

図1‒2　旧バージョンと新バージョンを入れ替える場合の操作手順

[picture]

注※1

HiRDBを旧バージョンに戻さないといけなくなった場合，旧バージョンのインストールディレクトリにインストールする必要があります。旧バージョンのインストールディレクトリを控えておいてください。

注※2

手順については，「HiRDBシステム定義（UAP環境定義を除く）の変更方法」を参照してください。

注※3

手順は，「インストール」を参照して下さい。

注※4

手順については，「システムファイルの作成」を参照してください。

注※5

システム共通定義でpd_auto_vrup = Nを指定すると，pdvrupコマンドは自動起動しません。この場合，KFPS05203-Qメッセージ（pdvrupコマンドの入力要求メッセージ）が出力されたら，HiRDB管理者がpdvrupコマンドを入力してください。

修正版HiRDBへの入れ替えの場合，pdvrupコマンドは自動起動しません。次の手順に進んでください。

注※6

pdvrupコマンドの実行結果は，メッセージログファイル又はイベントログにあるKFPX24404-Iメッセージを検索して確認してください。

注※7

「バージョンアップに失敗した場合」を参照してください。

1.4.3　HiRDBのプラグインをバージョンアップする場合

HiRDBをバージョンアップするときは，プラグインもバージョンアップする必要がある場合があります。プラグインの前提になるHiRDBのバージョンとプラグインのバージョンアップの手順については，該当するプラグインのマニュアル及び「プラグインのバージョンアップ」を参照してください。

1.4.4　Javaストアドプロシジャ及びJavaストアドファンクションを使用する場合

Javaストアドプロシジャ及びJavaストアドファンクションを使用する場合の注意事項を次に示します。

使用前にJREを入手しておく必要があります（各プラットフォームのベンダのホームページからJREに関する情報を入手できます）。Javaストアドプロシジャ及びJavaストアドファンクションを使用するために必要なJREのバージョンについては，マニュアル「HiRDB システム運用ガイド」を参照してください。

使用するJREのルートディレクトリをpd_java_runtimepathオペランドに指定する必要があります。また，必要に応じてJava仮想マシンのライブラリが格納されているディレクトリをpd_java_libpathオペランドに指定します。pd_java_runtimepathオペランド及びpd_java_libpathオペランドについては，マニュアル「HiRDB システム定義」を参照してください。

1.4.5　バージョンアップに失敗した場合

ここでは，次に示す現象が発生した場合の対処方法について説明します。

pdvrupコマンドを入力して5以上のリターンコードが返ってきた

HiRDB開始時にリターンコードが5以上のKFPX24404-Iメッセージが出力された

この場合，一緒に出力されたメッセージを参照して対策してください。

(1)　HiRDBを終了させなくてもよいとき

失敗の原因を取り除いた後に，再度pdvrupコマンドを入力してください。

(2)　HiRDBを終了させないといけないとき

HiRDBを終了しないと，失敗の原因が取り除けない場合は，いったんHiRDBを終了してください。そして，失敗の原因を取り除いた後に，pdstartコマンドでHiRDBを開始してください。開始すると，pdvrupコマンドの入力要求メッセージ（KFPS05203-Q）が出力されるので，再度pdvrupコマンドを入力してください。

(3)　HiRDBを旧バージョンに戻さないといけないとき

失敗の原因によっては，HiRDBを旧バージョンに戻して対処する必要があります。例えば，データディクショナリ用RDエリアの容量が不足していてバージョンアップに失敗した場合は，HiRDBを旧バージョンに戻してデータベース構成変更ユティリティ（pdmod）で対策する必要があります。このような場合は，いったんHiRDBを旧バージョンに戻して，失敗の原因を取り除き，その後で再度バージョンアップをしてください。

HiRDBを旧バージョンに戻す手順を次の図に示します。

図1‒3　HiRDBを旧バージョンに戻す手順（バージョンアップに失敗した場合）

[picture]

注※1

バージョン08-02以降から，バージョン08-02より前のHiRDBに戻す場合は，NOへ進みます。このとき，新バージョンのHiRDBをアンインストールしないで旧バージョンのHiRDBをインストールした場合は，新バージョンがインストールしたレジストリの情報，ディレクトリ，及びファイルが残ってしまいます。これらが残ったままでも旧バージョンのHiRDBは動作しますが，［コントロールパネル］−［アプリケーションの追加と削除］の「現在インストールされているプログラム」に，同じセットアップ識別子のHiRDBが二つ表示されます。その場合は，「現在インストールされているプログラム」で，両方のプログラムを削除した後，OSを再起動し，旧バージョンのHiRDBをインストールし直してください。

注※2

バックアップがない場合でも，%PDDIR%¥conf下のシステム定義ファイルが残っていれば，それらのファイルをそのまま使用できます。バックアップがなく，かつ%PDDIR%¥conf下のファイルも削除してしまった場合は，システム定義ファイルを作り直してください。

注※3

手順については，次の図を参照してください。

新バージョンで作成したシステムファイルの削除，又は再作成する手順を次の図に示します。

図1‒4　新バージョンで作成したシステムファイルの削除又は再作成手順

[picture]

1.4.6　HiRDBを旧バージョンに戻す場合

HiRDBのバージョンアップに成功した後にバージョンダウンを行う場合（例えば，テストなどで一度HiRDBをバージョンアップした後に，バージョンダウンして元の運用に戻したい場合など）は，旧バージョンで再構築する必要があります。

(1)　前提条件

旧バージョンで再構築する場合には，バージョンアップ前にすべてのRDエリアのバックアップ，及びシステム定義ファイルのバックアップを取得しておく必要があります。バックアップは，データベース複写ユティリティ（pdcopy）で取得します。

(2)　再構築の手順

再構築の手順は，最初にHiRDBをインストール及び環境設定する手順と基本的に同じです。旧バージョンで再構築する場合の手順を次に示します。

HiRDBを停止します（pdstopコマンド）。

新バージョンのHiRDBをアンインストールします。

HiRDBを旧バージョンに戻すことで付加PPの前提バージョンを満たさなくなる場合，付加PPをアンインストールします。

OSを再起動します。

旧バージョンをインストールします。手順2.で付加PPをアンインストールした場合，旧バージョンの付加PPをインストールします。

旧バージョンの環境設定を行います。

HiRDBファイルシステム領域を作成します（pdfmkfsコマンドを実行）。※

HiRDBファイルシステム領域に，システムファイル（システムログファイル，シンクポイントダンプファイル，ステータスファイル）を作成します（pdloginitコマンド，及びpdstsinitコマンドを実行）。

なお，新バージョンのHiRDBでシステム定義を変更した場合，バージョンアップ前に取得した旧バージョンのシステム定義ファイルに変更する（旧バージョンのHiRDBのシステム定義に戻す）必要があります。

データベース回復ユティリティ（pdrstr）を起動するため，pdstart -rコマンドでHiRDBを開始します。

データベース回復ユティリティ（pdrstr）で，バージョンアップ前に取得したバックアップファイルからデータベースを回復します（全RDエリアのリストア）。このとき，バージョンアップ後のHiRDBで更新したログを含むアンロードログファイルは使用しないでください。

HiRDBを停止します（pdstopコマンド）。

HiRDBを開始します（pdstartコマンド）。

注※

新バージョンのHiRDBでpdfmkfsコマンドを実行していない場合，旧バージョンでのHiRDBファイルシステム領域の作成は不要です。

(3)　注意事項

旧バージョンに戻す場合の注意事項を次に示します。

系切り替え機能を使用している場合

現用系，予備系ともに旧バージョンに戻してください。

セキュリティ監査機能を使用している場合

再構築の手順5.で，システムファイルを作成するとき，監査証跡ファイルも作成してください。

HiRDB Datareplicatorとのデータ連動機能を適用している場合

再構築の手順1.〜4.の間にHiRDB Datareplicatorも同時に旧バージョンに戻す必要があります。

再構築の手順9.の後にHiRDB，HiRDB Datareplicator連動環境を再初期化する必要があります。

1.4.7　バージョンアップ時の留意事項

(1)　バージョンアップ時のディクショナリ表メンテナンス

HiRDBのバージョンアップ後に，データベース再編成ユティリティ（pdrorg）を実行することで，ディクショナリ表のメンテナンスを行います。運用手順の詳細は，マニュアル「HiRDB コマンドリファレンス」の「データベース再編成ユティリティ」の「ディクショナリ表のメンテナンス」を参照してください。

(2)　バージョン10-05以前とのFLOAT型・SMALLFLT型の差異について

FLOAT型・SMALLFLT型について，バージョン10-05以前の場合と比較して，次の差異があります。

(a)　文字列から数値への変換精度の向上

次の文字列から数値への変換が伴う操作をした際に，仮数部が17桁を超える文字列を数値変換すると，バージョン10-05以前の場合とは，変換結果が変わることがあります。

SQL中にFLOAT型，SMALLFLT型の値を文字列として埋め込む場合

CAST関数等によって文字列をFLOAT型，SMALLFLT型に変換する場合

データベース作成ユティリティによってDAT形式，又は文字で記述した固定長データ形式の入力データファイルを使用してFLOAT型，SMALLFLT型列を持つ表へデータロードする場合

(b)　数値から文字列への変換時の形式変更

数値から指数形式文字列への変換形式が，バージョン10-05以前の場合とは異なります。

10-05以前：指数部が常に3桁の指数形式

（例）

+1.000000000000000E+000

10-06以降：　指数部が2桁以内に収まる場合は2桁で出力

（例）

+1.000000000000000E+00

これによって，次の操作でバージョン10-05以前の場合とは，変換結果が変わることがあります。

CAST関数，XQueryなどによってFLOAT型，SMALLFLT型の値を文字列に変換する場合

データベース再編成ユティリティによってFLOAT型，SMALLFLT型列を含む表のdat，extdat，fixtext形式pdload用アンロードファイルを作成する場合

1.4.8　暗号化列を含む表を使用している場合

暗号化列を含む表がHiRDBに定義されていると，pdvrupコマンドが異常終了します。暗号化列を含む表を使用している場合，10-05以前から10-06以降にHiRDBをバージョンアップする際，バージョンアップ前に，暗号化列を含む表はすべて搬出し暗号化列を含む表を削除してください。バージョンアップ後に，搬出した表を再定義し，データを搬入してください。

暗号化列を含む表を使用している場合の，HiRDB 10-05以前から10-06以降にバージョンアップする前，及びバージョンアップ後に必要な手順を次の図に示します。

(1)　バージョンアップ前の手順

注※1

次のSQL文で暗号化列を含む表の一覧が取得できます。

SELECT TABLE_SCHEMA,TABLE_NAME FROM MASTER.SQL_TABLES WHERE CONSTRUCTOR_TYPE IS NOT NULL WITHOUT LOCK NOWAIT;

注※2

次のSQL文で暗号化列を含む表を使用しているビュー表の一覧が取得できます。

SELECT VIEW_SCHEMA,VIEW_NAME FROM MASTER.SQL_VIEW_TABLE_USAGE AS V INNER JOIN MASTER.SQL_TABLES AS T ON V.BASE_OWNER=T.TABLE_SCHEMA AND V.BASE_TABLE_NAME= T.TABLE_NAME WHERE CONSTRUCTOR_TYPE IS NOT NULL WITHOUT LOCK NOWAIT;

注※3

暗号化列を含む表を使用した次の定義についても，バージョンアップ後に再定義が必要になります。

暗号化列を含む表を操作している手続き

暗号化列を含む表の更新で動作するトリガー

暗号化列を含む表を操作しているトリガー

暗号化列を含む表を参照制約で使用している表

注※4

次のオプションを指定して表移行用アンロードファイルを作成してください。

pdrorg -k unld -W bin -w -t [暗号化列を含む表名]  [コントロールファイル]

(2)　バージョンアップ後の手順

注※1

暗号化列を含む表を使用した次の定義についても，バージョンアップ後に再定義が必要になります。

暗号化列を含む表を操作している手続き

暗号化列を含む表の更新で動作するトリガー

暗号化列を含む表を操作しているトリガー

暗号化列を含む表を参照制約で使用している表

注※2

次のオプションを指定して表移行用アンロードファイルをインポートしてください。

pdload -W -w all -b  [暗号化列を含む表名]  [コントロールファイル]

注※3

「バージョンアップ後の手順」後，再定義していたルーチンのSQLオブジェクトを再登録するため，ALTER ROUTINE文で再登録を行ってください。

1.5　修正版HiRDBへの入れ替え

修正版HiRDBとは，07-02-/Aのように，稼働中のHiRDBとバージョン番号及びリビジョン番号が同じで，「-mn」のコードがあるものです（下線部がコード）。07-03より前のバージョンの場合，mは/，英字（I，O，P〜Tを除く），又は数字，nはA〜Zのアルファベットです。07-03以降はm，nは共に数字です。

修正版HiRDBへの入れ替えは，既存のHiRDBを終了しないで，稼働中に実行できます。ただし，MSFCを導入して系切り替え機能を使用する場合に，MSFCの汎用サービスにHiRDBのサービスを登録していると，HiRDBの稼働中に入れ替えることはできません。

HiRDBを終了して修正版HiRDBを入れ替える場合は，既に適用しているオペランド省略時動作を適用してください。

1.5.1　修正版HiRDBへの入れ替え方法

修正版HiRDBへの入れ替えには，次の方法があります。

HiRDBを終了して入れ替え

HiRDBの稼働中に入れ替え

それぞれについて説明します。

1.5.2　HiRDBを終了して入れ替え

HiRDBを終了して入れ替えるには，次の方法があります。

インストーラによる入れ替え

インストーラを使用して修正版HiRDBと入れ替えます。

修正パッチをWebから入手して適用

稼働中のHiRDBと，バージョン及びリビジョン番号が同じ場合，修正パッチを適用することで最新版に入れ替えできます。修正パッチは，Webからダウンロードして入手できます。

(1)　入れ替えの手順

(a)　インストーラによる入れ替え

インストーラを使用して修正版HiRDBと入れ替えます。

入れ替え方法は「旧バージョンと新バージョンを入れ替える場合」と同じです。次の箇所を参照して，修正版への入れ替えを行ってください。

「HiRDBのバージョンアップ」の説明及び注意

「旧バージョンと新バージョンを入れ替える場合」の操作手順※

注※　手順の中のpdvrupコマンドに関する操作は不要です。

また，修正版への入れ替え前に次のことを行ってください。

HiRDBがオンライン状態であるかどうかの確認

pdlsコマンドですべてのユニットがACTIVEと表示されているかどうかを確認してください。ACTIVEと表示されている場合，手順2.に進んでください。HiRDBが既に終了している場合は，手順3.へ進んでください。

HiRDBの終了

HiRDBを任意の終了モードで停止してください。HiRDB/パラレルサーバの場合はすべてのHiRDBのユニットを停止してください。

HiRDBのユニットの状態確認

HiRDBのユニットの状態を確認するため，pdls -d ustコマンドを実行してください。終了ステータスが4の場合（ユニットの状態がSTARTING又はSTOPPING），HiRDBが開始処理の途中，又は停止処理の途中です。処理が終了してからpdls -d ustコマンドを再度実行してください。

HiRDB/パラレルサーバの場合はすべてのHiRDBのユニットでpdls -d ustコマンドを実行して，HiRDBのユニットの状態を確認してください。

HiRDBのサービスの停止

「バージョンアップ前にすること」の「HiRDBのサービスの停止」を行ってください。

コマンド，ユティリティ，アプリケーション，及びHiRDBと連携している製品の停止

「バージョンアップ前にすること」の「コマンド，ユティリティ，アプリケーション，及びHiRDBと連携している製品の停止」を行ってください。

(b)　修正パッチをWebから入手して適用

稼働中のHiRDBと，バージョン及びリビジョン番号が同じ場合，修正パッチを適用することで最新版に入れ替えできます。修正パッチは，Webからダウンロードして入手できます。

適用手順については，修正パッチに添付されているRELEASE.TXTを参照してください。

ただし，HiRDBの場合，同梱している製品があるため，パッチを適用する製品を選択する画面が表示されます。次の画面で選択した製品の修正パッチを適用します。

1.5.3　HiRDBの稼働中に入れ替え

HiRDBの稼働中に入れ替えるには，次の方法があります。

インストーラによる入れ替え

インストーラを使用して修正版HiRDBと入れ替えます。

修正パッチをWebから入手して適用

稼働中のHiRDBと，バージョン及びリビジョン番号が同じ場合，修正パッチを適用することで最新版に入れ替えできます。修正パッチは，Webからダウンロードして入手できます。

(1)　前提条件

HiRDBの稼働中に入れ替えができるのは，次の条件を満たしている場合です。

バージョン，HiRDBサーバの種別，アドレッシングモード

修正版HiRDBと稼働中のHiRDBとで次に示す項目が同じである必要があります。なお，次の項目はpdadmvrコマンドで確認できます。

バージョン番号，リビジョン番号

HiRDBサーバの種別（HiRDB/シングルサーバか，HiRDB/パラレルサーバか）

アドレッシングモード（32ビットモードか，64ビットモードか）

ディスクの空き容量

HiRDB運用ディレクトリに，現在稼働中のHiRDBと修正版HiRDBの両方が格納できる程度のディスクの空き容量が必要です。修正版HiRDBを格納するのに必要な空き容量はリリースノートを参照してください。このほかに，修正版HiRDBを新規にインストールをする必要があり，そのためのディスク容量も必要となります。

HiRDBクライアント

オンライン業務をしているHiRDBクライアントは，入れ替えをするHiRDBサーバ以外で稼働している必要があります。HiRDBクライアントが入れ替えをするHiRDBサーバ上で稼働している場合，HiRDBクライアントを停止し，オンライン業務を停止する必要があります。

クライアントライブラリ

オンライン業務をしているHiRDBクライアントが利用しているHiRDB/Developer's Kit及びHiRDB/Run Timeのバージョンは07-00以降である必要があります。07-00より前のバージョンを使用している場合，入れ替えの途中で接続中のHiRDBクライアントとの接続が切断されます。

自動再接続機能の適用

HiRDBに接続するHiRDBクライアントは，自動再接続機能（PDAUTORECONNECT=YES）を使用する必要があります。自動再接続機能を使用していない場合，入れ替えの途中で接続中のクライアントとの接続が切断されます。自動再接続機能については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(2)　入れ替え前にすること

HiRDB/パラレルサーバの場合，修正版HiRDBへの入れ替えをする前にOS環境ファイルを設定してください。

全ユニットのサーバマシンでSERVICESファイル（%windir%¥system32¥drivers¥etc¥SERVICES）に連絡用ポートのサービス名（pdrshsrv-RNW）と，リモートコマンドシェルの接続用ポート番号を設定します。設定するポート番号は全ユニットのサーバマシンで同一とします。また，マシン内では同じ番号は使用しないでください。

(3)　入れ替えの手順

修正版HiRDBへの入れ替え手順を次に示します。

修正版HiRDBのインストール

修正版HiRDBをインストールする場合の注意事項を次に示します。

修正版HiRDBは，上書きインストールではなく，新規にインストールしてください。

［プログラムメンテナンス用セットアップ］でインストールしたHiRDBは入れ替えのためだけに利用できます。

HiRDB/パラレルサーバの場合，全ユニットで同一パス名のディレクトリに修正版HiRDBをインストールしてください。

インストールする修正版HiRDBの媒体によって手順が異なります。媒体ごとに手順を示します。

インストーラ（HiRDBインストール用CD-ROM）の場合（HiRDB 07-01以前）

次の手順でインストールしてください。

1.　修正版HiRDBのインストール用CD-ROM中の01_srv¥Setup.exeをダブルクリックし，インストーラを起動します。

2.　インストーラ実行中に表示される［セットアップ方法］画面で［プログラムメンテナンス用セットアップ］を選択して，稼働中のHiRDBとは異なるディレクトリに修正版HiRDBをインストールします。

インストーラ（統合CD-ROM）の場合（HiRDB 07-02以降）

1.　修正版HiRDBの統合CD-ROM中のhcd_inst.exeを実行して，日立総合インストーラを起動します。

2.　［日立総合インストーラ］画面で，HiRDB/シングルサーバの場合は［HiRDB/Single Server］を，HiRDB/パラレルサーバの場合は［HiRDB/Parallel Server］を選択して，HiRDBのインストーラを起動します。

3.　HiRDBのインストーラの［プログラムプロダクトの選択］画面で，HiRDB/シングルサーバの場合は［HiRDB/Single Server］を，HiRDB/パラレルサーバの場合は［HiRDB/Parallel Server］を選択して，HiRDB/Single Server又はHiRDB/Parallel Serverのインストーラを起動します。

4.　HiRDB/Single Server又はHiRDB/Parallel Serverのインストーラ実行中に表示される［セットアップ方法］画面で［プログラムメンテナンス用セットアップ］を選択して，稼働中のHiRDBとは異なるディレクトリに修正版HiRDBをインストールします。

修正パッチ（HiRDB 07-03以降）の場合

1.　稼働中のHiRDBをインストールした時に使用した統合CD-ROM中のhcd_inst.exeを実行して，日立総合インストーラを起動します。

2.　「インストーラ（統合CD-ROM）の場合（HiRDB 07-02以降）」の手順2〜4と同じ操作をして，HiRDBをインストールします。

3.　修正版HiRDBの修正パッチを実行して，2.でインストールしたHiRDBにパッチを適用します。適用手順については，修正パッチに添付しているRELEASE.TXTを参照してください。なお，最新版の修正パッチには過去の修正内容が含まれているため，過去に発行された修正パッチを適用する必要はありません。

修正版HiRDBサービスの開始（HiRDB/パラレルサーバの場合だけ）

次の手順で修正版HiRDBのサービスを開始してください。

1.　［コントロールパネル］の［サービス］をダブルクリックしてください。

2.　［サービス］リストボックスから修正版HiRDBのサービス「HiRDB/ParallelServer-RNW」を選択して，［スタートアップ］ボタンをクリックしてください。

3.　［ログオン］がシステムアカウントに設定されているので，アカウントを選択してください。アカウントの右にあるボタンをクリックして，［ユーザーの追加］画面を表示させます。

4.　［名前の一覧］からHiRDB管理者を選択します。［追加］をクリックし，［OK］をクリックしてください。

5.　［パスワード］画面でHiRDB管理者のパスワードを入力してください。同じパスワードを［パスワードの確認入力］画面にも入力して，［OK］をクリックしてください。

6.　［サービス］リストボックスから修正版HiRDBのサービスを選択して，［開始］をクリックしてください。

入れ替え用ディレクトリに修正版HiRDBをコピー

［スタート］−［プログラム］−［HiRDBSingleServer-RNW］又は［HiRDBParallelServer-RNW］−［HiRDBコマンドプロンプト］を選択して，修正版HiRDBの作業用コンソールを起動します。この作業用コンソールで，"pdprgcopy 稼働中のHiRDB運用ディレクトリ"コマンドを実行して，修正版HiRDBを稼働中のHiRDB運用ディレクトリ下の入れ替え用ディレクトリ（%PDDIR%¥renew）にコピーしてください。HiRDB/パラレルサーバの場合はシステムマネジャがあるユニットで作業用コンソールを起動してpdprgcopyコマンドを実行してください。

入れ替え対象のHiRDBがオンライン状態であるかどうかの確認

［スタート］−［プログラム］−［HiRDBSigleServer］又は［HiRDBParallelServer］−［HiRDBコマンドプロンプト］（セットアップ識別子を指定してインストールした場合は，［HiRDBSigleServerセットアップ識別子］又は［HiRDBParallelServerセットアップ識別子］になります）をクリックして，稼働中のHiRDBの作業用コンソールを起動し，pdlsコマンドで全ユニットが「ACTIVE」と表示されていることを確認してください。確認が終了したら，HiRDBコマンドプロンプトは終了してください。

ほかのプログラムの終了

稼働中のHiRDB運用ディレクトリにアクセスしているプログラム（エクスプローラ，コマンドプロンプトなど）や，レジストリにアクセスしているプログラム（regeditなど），HiRDB運用コマンドはすべて終了してください。

修正版HiRDBへの入れ替え

修正版HiRDBの作業用コンソール上で"pdprgrenew 稼働中のHiRDB運用ディレクトリ"コマンドを実行して，HiRDBの入れ替えをします。このコマンドを実行すると，稼働中のHiRDBをバックアップ用ディレクトリ（%PDDIR%¥renew_bak）に退避した後，稼働中のHiRDBを3.でコピーした入れ替え用ディレクトリの修正版HiRDBと入れ替えます。HiRDB/パラレルサーバの場合はシステムマネジャがあるユニットの作業用コンソール上でpdprgrenewコマンドを実行してください。

修正版HiRDBサービスの停止（HiRDB/パラレルサーバの場合だけ）

［コントロールパネル］−［サービス］を選択して，修正版HiRDBのサービス「HiRDB/ParallelServer-RNW」を停止してください。

修正版HiRDBのアンインストール

［スタート］−［プログラム］−［HiRDBSingleServer-RNW］又は［HiRDBParallelServer-RNW］−［HiRDBSingleServerのアンインストール］又は［HiRDBParallelServerのアンインストール］を選択して，1.でインストールした修正版HiRDBをアンインストールしてください。なお，アンインストール時に修正版HiRDBの運用ディレクトリ下のファイル及びディレクトリの一部が削除されなかった場合，手動で運用ディレクトリ下のファイル及びディレクトリを削除してください。

OS環境ファイルの設定（HiRDB/パラレルサーバの場合だけ）

「入れ替え前にすること」で設定した連絡用ポートのサービス名とポート番号をSERVICESファイル（%windir%¥system32¥drivers¥etc¥SERVICES）から削除してください。

(4)　系切り替え機能使用時の入れ替え手順

系切り替え機能を使用している場合，HiRDBの稼働中に入れ替えができるのは次の場合です。

スタンバイ型系切り替えの場合

実行系が現用系で稼働中のときだけです。実行系が予備系で稼働中のときは，系を切り替えてコマンドを実行してください。

スタンバイレス型系切り替えの場合

すべての正規BESが稼働中のときだけです。代替中は入れ替えできません。

系切り替え機能使用時の修正版HiRDBへの入れ替え手順を次に示します。

サーバモードで運用している場合

スタンバイ型系切り替え

予備系が実行系の場合，現用系が実行系になるように系を切り替えてください。

待機系のHiRDBを停止してください。

実行系で修正版HiRDBへの入れ替えを実行してください。

待機系に修正版HiRDBを上書きインストールしてください。

1.で停止させた待機系のHiRDBを再起動します。待機系のHiRDBでpdstartコマンド（HiRDB/パラレルサーバの場合はpdstart -qコマンド）を実行してください。

1：1スタンバイレス型系切り替え

代替BESが稼働中の場合，系を切り戻してください。

代替BESユニットの代替部の待機状態を解除してください。解除方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

実行系の正規BESユニットで修正版HiRDBへの入れ替えを実行してください。

2.で待機状態を解除した代替部はpdprgrenewコマンドを実行すると自動的に待機状態になるため，これ以降の操作は不要です。

影響分散スタンバイレス型系切り替え

受け入れユニットのゲストBESが稼働中の場合，正規ユニットに系を切り戻してください。

HAグループに属する，すべての稼働していないゲストBESの受け入れ可能状態を解除してください。

実行系の正規ユニットで修正版HiRDBへの入れ替えを実行してください。

2.で受け入れ可能状態を解除したゲストBESは，pdprgrenewコマンドを実行すると自動的に受け入れ可能状態になるため，これ以降の操作は不要です。

モニタモードで運用している場合

予備系が実行系の場合，現用系が実行系になるように系を切り替えてください。

実行系で修正版HiRDBへの入れ替えを実行してください。

待機系に修正版HiRDBを上書きインストールしてください。

(5)　注意事項

修正版HiRDBへ入れ替えの実行不可

HiRDBの稼働状況によっては，修正版HiRDBの入れ替えが実行できないことがあります。詳細については，マニュアル「HiRDB コマンドリファレンス」のpdprgrenewコマンドの説明を参照してください。

UAPのレスポンス遅延

pdprgrenewコマンドを実行している時間は，UAPのレスポンスが遅くなります。このため，比較的トラフィックが低い時間帯に実行することをお勧めします。

定義の変更

修正版HiRDBへの入れ替えに伴って，必要となるメモリサイズが変わり，システム定義の変更が必要となる場合があります。その場合は事前にシステム構成変更コマンド（pdchgconfコマンド）でHiRDBシステムの定義を変更する必要があります。システム構成変更コマンドの使用方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

運用コマンド，ユティリティの実行

pdprgrenewコマンド実行中は運用コマンドやユティリティを実行しないでください。実行すると，HiRDBが停止している旨のエラーが表示されたり，HiRDBの入れ替え作業が失敗することがあります。

系切り替え機能使用不可

修正版への入れ替え中は系切り替え機能は使用できません。

ホールダブルカーソルの無効

修正版への入れ替えではカーソル保持ができないので，ホールダブルカーソルを使用するUAPは入れ替え前後で実行できません。そのため，UAPはエラーとなります。

UNTIL DISCONNECT指定のLOCK文が無効

修正版への入れ替えではUNTIL DISCONNECT指定の排他を保持できないため，UNTIL DISCONNECT指定のLOCK文を使用するUAPは修正版への入れ替え前後で実行できません。そのため，UAPはエラーとなります。

(6)　運用上の注意事項

修正版HiRDBへ入れ替えるときの運用上の注意事項を次に示します。

データベース構成変更ユティリティ（pdmod）で割り当てたグローバルバッファが無効になります。そのため，入れ替え後に再度グローバルバッファを割り当てる必要があります。

pd_spool_cleanup_intervalオペランドの時間のカウント開始時点が入れ替え時の時刻にリセットされます。

pd_spool_cleanupオペランドにnormal，又はforceを指定している場合，入れ替え時に出力済みのトラブルシュート情報は削除されます。

pdstbeginコマンドやpdstendコマンドを使用して，統計情報の取得条件をpd_statisticsオペランドやpdstbeginオペランドの指定と異なる値に変更していた場合，次のようになります。

pd_statisticsオペランドやpdstbeginオペランドを指定しないで起動した環境でpdstbeginコマンドで統計情報を取得していた場合，入れ替え後には統計情報を取得しなくなります。そのため，再度pdstbeginコマンドを実行する必要があります。

pd_statisticsオペランドにA若しくはYを指定，又はpdstbeginオペランドを指定して起動した環境でpdstendコマンドで統計情報取得を中止した場合や，pdstbeginコマンドを実行して取得する統計情報の種類を変更していた場合，入れ替え後にはシステム共通定義に記述した指定で統計情報を取得します。そのため，再度pdstendコマンドやpdstbeginコマンドを実行する必要があります。

絞込み検索で使用しているリストがなくなるため，入れ替え後にASSIGN LIST文でリストを再作成する必要があります。

pdchprcコマンドで変更した常駐プロセス数はHiRDBシステム定義で指定した常駐プロセス数に戻るため，入れ替え後に再度pdchprcコマンドを実行する必要があります。

修正版HiRDBへの入れ替えをすると，システムログファイルが切り替わります。入れ替え前に，スワップできるシステムログファイルがあることを確認し，不足している場合は次の対処をしてください。

スワップできるシステムログファイルがない場合

アンロード待ち状態のファイルがあれば，アンロードしてください。アンロード待ち状態のファイルがなければ，システム構成変更コマンド（pdchgconfコマンド）を使用してスワップできるログファイルを追加してください。システム構成変更コマンドの使用方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

スワップできるシステムログファイルがない状態で入れ替えを実行すると，KFPS01256-Eメッセージを出力後，Psjnf07又はPsjn381のコードでアボートしてHiRDBが停止します。この場合は，スワップできるファイルを準備してからpdstartコマンドでHiRDBを起動してください。

スワップできるシステムログファイルが一つだけの場合

修正版HiRDBへの入れ替えはできますが，入れ替え中にスワップできるファイルがないことを示すKFPS01224-Iメッセージが出力されます。入れ替え後にスワップできるシステムログファイルを準備してください。

修正版HiRDBへの入れ替えをすると，メッセージログファイルが切り替わります。ただし，メッセージログファイルの切り替えを知らせるメッセージ（KFPS01910-Iなど）は表示されません。メッセージログファイル中のメッセージを保存したい場合は，入れ替え前にメッセージログファイルをバックアップしてください。

修正版HiRDBへの入れ替えをすると，入れ替え対象のHiRDBのサービスや，MSFCのリソースが一時的に停止，又はオフラインになります。

(7)　関連製品の制限及び注意事項

プラグイン

プラグインを利用している場合もHiRDBの稼働中に修正版HiRDBへ入れ替えができます。ただし，プラグインの入れ替えはできません。

HiRDB Datareplicator連携機能

HiRDB Datareplicatorを使用してデータ抽出中のHiRDBに対してpdprgrenewコマンドを実行しないでください。オンライン業務を停止しないで修正版HiRDBへの入れ替えをする場合，抽出側のHiRDB Datareplicatorを終了させる必要があります。ただし，HiRDB Datareplicator連携は中止させないでください（pdrplstopコマンドは実行しないでください）。HiRDB Datareplicator連携を中止させると，抽出側DBと反映側DBが不整合になることがあります。pd_rpl_init_startオペランドの値とpdprgrenewコマンドの実行可否を次の表に示します。

表1‒7　pd_rpl_init_startオペランドの値とpdprgrenewコマンドの実行可否

pd_rpl_init_startオペランドの値 | HiRDB Datareplicatorのデータ抽出機能の実行状況 | pdprgrenewコマンドの実行可否
Y | 実行中 | 〇
pdrplstopコマンドによって停止中 | ×
N（省略値） | 停止中 | 〇
pdrplstartコマンドによって実行中 | ×

（凡例）

○：実行できます。

×：実行できません。

(8)　障害時の運用

(a)　エラー発生時の対処

修正版HiRDBへの入れ替え実行中にエラーが発生した場合，pdprgrenewコマンドは自動的に入れ替え前のHiRDBに戻してHiRDBを動作させようとします。エラー発生後に，コマンドがリターンコード12のKFPS04646-Iメッセージを出力して終了した場合，HiRDBを入れ替え前に戻す作業が失敗しています。そのため，標準エラー出力やイベントログに出力されたエラーメッセージとKFPS04647-Iメッセージを参照して対処してください。

修正版HiRDBへの入れ替え中にエラーが発生した場合の対処方法を次の図に示します。

図1‒5　修正版HiRDBへの入れ替え中にエラーが発生した場合の対処方法

[picture]

pdprgrenewコマンドがエラーになった要因を取り除いて，pdprgrenewコマンドを再度実行してください。

HiRDBのサーバプロセスがあれば，pdstop -fコマンドでHiRDBを強制終了してからpdprgrenew -bコマンドを実行してください。HiRDBのサーバプロセスがなければ，pdprgrenew -bコマンドを実行してください。pdprgrenew -bコマンドを実行すると，回復処理として，入れ替え前のHiRDBで再開始しようとします。

また，HiRDBの終了処理失敗に関するエラーメッセージ及びアボートコードが表示されることがあります。メッセージの対処方法に従って，入れ替え前のHiRDBの稼働環境を確認し，対処してください。

HiRDBのサーバプロセスがあれば，pdstop -fコマンドでHiRDBを強制終了してからpdprgrenew -bコマンドを実行してください。HiRDBのサーバプロセスがなければ，pdprgrenew -bコマンドを実行してください。pdprgrenew -bコマンドを実行すると，回復処理として，修正版HiRDBを入れ替え用ディレクトリに戻します。

また，HiRDBの開始処理失敗に関するエラーメッセージ及びアボートコードが表示されることがあります。入れ替え後の修正版HiRDBが動作するための環境に問題がある可能性があるので，表示されるメッセージに従って対処してください。

(b)　入れ替え失敗時にHiRDBが入れ替え前の状態に戻っているかどうかの確認

修正版HiRDBへの入れ替えに失敗したとき，入れ替え前のHiRDBに戻っているかどうかは，次の項目をチェックして確認できます。次の項目を満たしていれば，入れ替え前のHiRDBに戻っています。

pdadmvr -sコマンドで表示されるバージョンが入れ替え前のHiRDBバージョンと一致する

HiRDBがオンライン状態（pdlsコマンドの結果，全ユニットが「ACTIVE」と表示）である

バックアップ用ディレクトリ（%PDDIR%¥renew_bak）がない

1.6　64ビットモードのHiRDBへの移行方法

同一マシンで，32ビットモードのHiRDBから64ビットモードのHiRDBに移行する方法について説明します。

1.6.1　64ビットモードに移行する際の考慮点

(1)　互換性がないファイル

32ビットモードのHiRDBで使用していたファイルは，基本的に64ビットモードのHiRDBで使用できます。ただし，次に示すファイルは互換性がないため，64ビットモードのHiRDBで使用できません。

バックアップファイル

マスタディレクトリ用RDエリア及びデータディレクトリ用RDエリアを構成するHiRDBファイル

(2)　省略値が変わるオペランド

HiRDBを32ビットモードから64ビットモードにすると，一部のHiRDBシステム定義のオペランドの省略値が変わります。マニュアル「HiRDB システム定義」の「32ビットモードと64ビットモードで省略値が異なるオペランド」を参照して，変更内容を確認してください。

(3)　メモリ所要量の違い

HiRDBを32ビットモードから64ビットモードにすると，メモリ所要量が増えます。メモリ所要量の計算方法については，「HiRDBのメモリ所要量」を参照してください。

(4)　UOCインタフェースの違い

HiRDBを64ビットモードにすると，データベース作成ユティリティ（pdload）及びデータベース再編成ユティリティ（pdrorg）のUOCインタフェースが変わるため，UOCを作成し直す必要があります。UOCインタフェースについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

1.6.2　64ビットモードへの移行手順

64ビットモードへの移行手順を次の図に示します。

図1‒6　64ビットモードへの移行手順

[picture]

pdstopコマンドでHiRDBを正常終了します

pdstsinitコマンドでステータスファイルの容量を大きくします

「ステータスファイルの容量の見積もり」を参照して，ステータスファイルの容量を見積もり直してください。必要があれば，pdstsinitコマンドでステータスファイルの容量を大きくしてください。

システム共通定義のpdpluginオペランドを削除します

システム共通定義のpdpluginオペランドを削除してください。この操作をしないと，HiRDBを64ビットモードにバージョンアップした後，正常開始できなくなります。

HiRDBを64ビットモードにバージョンアップします

64ビットモードのHiRDBにバージョンアップしてください。バージョンアップの方法については，「HiRDBのバージョンアップ」を参照してください。

64ビットモードのHiRDBにバージョンアップする前に，データディクショナリ用RDエリアの空き領域を調べます。このとき，「バージョンアップ前にすること」に記載されている空き領域に加えて，次の表に示す空き領域が必要になります。

表1‒8　64ビットモードにバージョンアップするのに必要な空き領域

データディクショナリ用 RDエリアに格納している ディクショナリ表 | データディクショナリ用RDエリアに 必要な空きセグメント数
SQL_TABLES表 | ↑3÷S↑
SQL_VIEW_DEF表 | ↑214÷S↑
SQL_ROUTINE_PARAMS表※ | ↑3÷S↑

（凡例）

S：対象表を格納するデータディクショナリ用RDエリアのセグメントサイズ

注※

データディクショナリLOB用RDエリアを定義していない場合は不要です。

pdobjconvコマンドが自動的に起動します

バージョンアップ操作の中で，pdvrupコマンドの実行があります。このpdvrupコマンドが正常終了すると，pdobjconvコマンド※1が自動的に実行されます。このコマンドのリターンコード※2が0又は4ならば，64ビットモードへの移行は終了です。0又は4以外の場合は，「SQLオブジェクトの移行に失敗した場合」に示す方法で，64ビットモードへの移行作業を継続してください。

注※1

32ビットモードで作成したビュー表，手続き及び関数のSQLオブジェクトを64ビットモードでも使用できるようにするコマンドです。

注※2

KFPX21002-Iメッセージにリターンコードが表示されます。このメッセージはシステムログファイル及びイベントログに出力されます。リターンコードが8又は12の場合は，標準エラー出力にも出力されます。リターンコードの意味を次に示します。

0：

pdobjconvコマンドが正常終了しました。

4：

警告レベルのエラーはありますが，pdobjconvコマンドを正常終了します。

8：

一部のSQLオブジェクトの移行に失敗しました。メッセージ又はpdobjconvコマンドの処理結果情報（SQLオブジェクト移行情報）を参照して，エラーとなった要因を調査して取り除いてください。

又は，ユティリティ実行上のエラーが発生しました。

12：

pdobjconvコマンドが異常終了しました。メッセージ又はpdobjconvコマンドの処理結果情報（SQLオブジェクト移行情報）を参照して，エラーとなった要因を調査して取り除いてください。

pdcancelコマンドでpdobjconvコマンドをキャンセルしたり，pdobjconvコマンドのプロセスで異常が発生したりすると，リターンコードが12になります。

pdstopコマンドでHiRDBを正常終了します

HiRDBのサービスを停止します

32ビットモードのプラグインをアンインストールします

32ビットモードのプラグインをアンインストールします。アンインストールの方法については，該当するプラグインのマニュアルを参照してください。

64ビットモードのプラグインをインストールします

64ビットモードのプラグインをインストールします。インストールの方法については，該当するプラグインのマニュアルを参照してください。

HiRDBのサービスを開始します

システム共通定義のpdpluginオペランドを指定します

64ビットモードのプラグインのプラグイン名称をシステム共通定義のpdpluginオペランドに指定してください。

pdstartコマンドでHiRDBを正常開始します

1.6.3　SQLオブジェクトの移行に失敗した場合

ここでは，pdobjconvコマンドのリターンコードが8又は12の場合の処置について説明します。

(1)　リターンコードが8の場合

一部のSQLオブジェクトの移行に失敗しました。SQLオブジェクト移行情報を参照して，移行に失敗したSQLオブジェクトを確認してください。SQLオブジェクト移行情報の見方については，マニュアル「HiRDB コマンドリファレンス」のpdobjconvコマンドを参照してください。

移行に失敗したSQLオブジェクトを移行する場合は，出力されたメッセージを参照して失敗の原因を取り除いてください。その後，pdobjconvコマンドを実行してください。なお，HiRDBをいったん終了した場合は，HiRDBを開始した後にpdobjconvコマンドを実行してください。

(2)　リターンコードが12の場合

pdobjconvコマンドが異常終了しました。出力されたメッセージを参照して異常終了の原因を取り除いてください。その後，pdobjconvコマンドを実行してください。なお，HiRDBをいったん終了した場合は，HiRDBを開始した後にpdobjconvコマンドを実行してください。

1.6.4　64ビットモードへの移行に失敗した場合（旧バージョンに戻す場合）

64ビットモードへの移行に失敗して，HiRDBを旧バージョンに戻す場合の方法については，「バージョンアップに失敗した場合」を参照してください。

なお，「バージョンアップに失敗した場合」の方法を実施した後に，pdstsinitコマンドで全ステータスファイルを初期化してください。この操作をしないと，HiRDBを正常開始できません。

2　インストール

この章では，インストール前後に必要な作業，HiRDBのインストール手順，付加PPインストール時の注意，及びHiRDBのアンインストールについて説明します。

また，Windowsファイアウォールの例外リストへの登録方法と削除方法についても説明します。

2.1　インストール前に必要な作業

ここでは，HiRDBをインストールする前に必要な作業について説明します。説明する項目を次に示します。

サーバマシン環境の確認

HiRDB管理者の登録

OS環境ファイルの設定

ホスト名の登録

2.1.1　サーバマシン環境の確認

HiRDBをWindowsにインストールする前に，使用するサーバマシンの環境を確認してください。

(1)　適用機種の確認

HiRDBはWindowsのPC/AT互換機版しか対応していません。PC/AT互換機版のWindowsであることを確認してください。

HiRDB/パラレルサーバの場合，すべてのサーバマシンで同じバージョンのWindowsを使用してください。

HiRDB/パラレルサーバをインストールする形態は単一ドメインの形態をお勧めします。

(2)　システム環境変数TZの確認

サーバマシンのシステム環境変数TZにJST-9が設定されているかどうかを確認してください。システム環境変数TZの確認手順を次に示します。

［コントロールパネル］の［システム］をダブルクリックしてください。

［システムのプロパティ］の［環境］タブを選択してください。

システム環境変数の変数「TZ」がJST-9になっているかどうかを確認してください。

TZがない場合はTZを追加してください。TZの値がJST-9でない場合は，JST-9に変更してください。

注意事項

システム環境変数TZの値と，HiRDBシステム定義の設定内容（システム共通定義のTZオペランドの設定値）が同じである必要があります。TZにJST-9以外の値を設定する場合は，システム共通定義のTZオペランドの指定値を変更する必要があります。

(3)　ディスク容量の確認

インストーラでもディスク容量をチェックしていますが，インストールする前にディスクの空き容量が十分かどうか確認してください。必要な空き容量の目安を次に示します。

（インストール時に必要な容量）＋（HiRDB動作時に自動的に確保する容量）

インストール時に必要な容量：

HiRDB/シングルサーバの場合：93.4MB

HiRDB/パラレルサーバの場合：95.9MB

なお，バージョンによってこの数値は変動する場合があります。リリースノートのメモリ所要量とディスク占有量を参照してください。

HiRDB動作時に自動的に確保する容量：1MB＋共用メモリサイズ

共用メモリサイズの見積もりについては，「HiRDBのメモリ所要量」を参照してください。

(4)　仮想メモリの確認

サーバマシンの仮想メモリの容量（実メモリ容量＋ページングファイルの容量の合計値）の設定を確認してください。

HiRDBの動作に必要な仮想メモリ容量は，HiRDBの共用メモリの割り当て先によって変わります。各共用メモリの割り当て先と，必要仮想メモリ容量について次に示します。

共用メモリの割り当て先※1 | 概要 | 必要仮想メモリ容量※2 | メリット | デメリット
ページングファイル （page） （推奨） | 共用メモリをOSのページングファイルで管理します。 | プロセス固有メモリサイズ＋共用メモリサイズ | システム安定性が高くなります。 | OSのページングファイルを多量に使用するため，事前に仮想メモリ容量を見積もり，OSの設定を変更しておく必要があります。
通常ファイル（regular） （非推奨） | 共用メモリをHiRDB運用ディレクトリ下の通常ファイルで管理します。 | プロセス固有メモリサイズ | OSのページングファイルを圧迫しません。 | システム安定性が低くなります。 HiRDB運用ディレクトリのあるドライブのディスク容量を圧迫するため，容量不足が発生しやすくなります。 NTFSキャッシュフラッシュ※3によって長時間システムが停止し，HiRDBにユニットダウンなどの障害が発生するおそれがあります。

注※1

共用メモリの割り当て先をpdntenv -shmfileコマンドによって変更する際の，コマンドに指定するオプション値です。pdntenv -shmfileコマンドの詳細については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

注※2

メモリ容量の見積もり式については「HiRDBのメモリ所要量」を参照してください。

メモリ所要量の具体例として，簡易セットアップツールの標準セットアップを使用してHiRDBの環境設定をした場合の簡易的な見積もり式をリリースノートに記載しています。リリースノートのメモリ所要量とディスク占有量を参照してください。

注※3

regularでは共用メモリを通常ファイル上に割り当てるため，共用メモリに対する更新がNTFSキャッシュ上にキャッシュされます。このNTFSキャッシュは，通常，OSによってディスクへ遅延書き込みされますが，ユーザによるディスク操作などを契機として更新ページが一斉にディスクに書き込まれることがあります。これをNTFSキャッシュフラッシュと呼びます。

NTFSキャッシュフラッシュが発生すると，スローダウンによる系切り替えやユニットダウンなど，HiRDBに様々な障害が発生するおそれがあるため，pageの使用を推奨しています。

NTFSキャッシュフラッシュの詳細については，マニュアル「HiRDB システム運用ガイド」の「NTFSキャッシュのフラッシュが発生した場合の対処」を参照してください。

サーバマシンの仮想メモリ容量は，［コントロールパネル］の［システム］をダブルクリックして表示される［システムのプロパティ］で確認できます。ページングファイルの容量は［システムのプロパティ］の［パフォーマンス］タブで確認及び変更できます。ページングファイルは，同じドライブに連続した領域を作成するように，初期サイズと最大サイズを同じ値（固定値）にしてください。ページングファイルを連続で使用できない場合，HiRDBがメモリ不足で異常終了します。

また，実際に指定する値には，Windowsやほかのプログラムが使用する容量を加えてください。仮想メモリを変更した場合には，必ずWindowsを再起動してください。

仮想メモリの容量に関する注意事項

共用メモリの割り当て先は，pdntenvコマンドで指定します。指定方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

HiRDB Datareplicatorのメモリ所要量については，マニュアル「HiRDBデータ連動機能 HiRDB Datareplicator」を参照してください。

HiRDB Dataextractorのメモリ所要量については，マニュアル「データベース抽出・反映サービス機能 HiRDB Dataextractor」を参照してください。

(5)　システムキャッシュの確認

Windowsで使用するファイルのシステムキャッシュは，設定方法によっては使用できるメモリを圧迫することがあります。システムキャッシュの設定を変更する手順を次に示します。

［コントロールパネル］の［ネットワーク］をダブルクリックします。

［ネットワーク］の［サービス］タブを選択します。

［サーバー］を選択して，［プロパティ］をクリックします。

［サーバー］のダイアログボックスの値が「ファイル共有のスループットを最大にする」に設定されていたら，［ネットワークアプリケーションのスループットを最大にする］を選択して［OK］ボタンをクリックします。

Windowsを再起動します。

(6)　ファイルシステムの確認

HiRDBが使用するファイルシステムにNTFSとFATを使用できます。ただし，FATについてはパス名の英字の全角大文字と小文字を区別しません。このため，同一名称がある場合は同一ファイルと認識するため，動作を保証できません。NTFS及びFATについては，Windowsのドキュメントを参照してください。

HiRDBをNTFSにインストールする場合，HiRDB運用ディレクトリ下のファイル（環境変数PDDIRで指定したディレクトリ）を圧縮しないでください。このディレクトリを圧縮した場合，HiRDBは正常に動作しません。

(7)　リソース数に関連する環境変数の見積もり

一つのサーバマシン内で使用するリソース数を見積もってください。見積もり方法については，「リソース数に関連する環境変数の見積もり」を参照してください。

2.1.2　HiRDB管理者の登録

Windowsのシステム管理者（Administrators権限を持つユーザ）をHiRDB管理者としてください。HiRDB/パラレルサーバの場合，又はIPアドレスを引き継がない系切り替え機能を使用する場合は各サーバマシンを同じシステム管理者にしてください。

HiRDB/パラレルサーバの場合

各サーバマシンで同じ名称のActive Directoryアカウントのドメインユーザをシステム管理者（HiRDB管理者）に設定するか，各サーバマシンで同じ名称のローカルアカウントをシステム管理者（HiRDB管理者）に設定してください。

IPアドレスを引き継がない系切り替え機能を使用する場合

各サーバマシンで同じ名称のActive Directoryアカウントのドメインユーザをシステム管理者（HiRDB管理者）に設定してください。

Active Directoryアカウントのドメインユーザは，プライマリ・ドメインコントローラ上の［管理ツール］−［Active Directoryユーザーとコンピュータ］で登録します。ローカルアカウントは，各マシンの［管理ツール］−［コンピューターの管理]の［ローカルユーザーとグループ］で登録します。登録方法の詳細は，OSのマニュアルを参照してください。

なお，HiRDBの予約語は認可識別子として使用しないでください。予約語については，次に示すマニュアルを参照してください。

「HiRDB UAP開発ガイド」

「HiRDB SQLリファレンス」

HiRDB/パラレルサーバの場合，又は系切り替え機能を使用する場合は，HiRDB管理者をHiRDBサービスのログオンアカウントとして設定する必要があります。HiRDBサービスのログオンアカウントを，OS標準のローカルシステムアカウントからHiRDB管理者に変更する場合，次に示すユーザ権利※1の付与が必要となります。なお，ファイルセキュリティ強化機能を使用する場合，又はインストール時にHiRDB管理者を登録する場合※2はHiRDBが自動で付与するため，手動での付与は必要ありません。

ユーザ権利 | 説明
サービスとしてログオン | HiRDB管理者をHiRDBサービスのログオンアカウントとして設定する際に必要となる権利です。サービスのプロパティから手動で設定する場合は，OSが自動的に付与しています。
メモリ内のページのロック | HiRDB管理者をHiRDBサービスのログオンアカウントに設定し，かつ共用メモリのページ固定機能を使用する場合に必要となる権利です。HiRDBサービスのログオンアカウントをローカルシステムアカウントとした場合は，標準で付与されています。 共用メモリのページ固定機能を使用しない場合には，削除しても問題ありません。

注※1

[ローカルセキュリティポリシー]の[ユーザー権利の割り当て]で設定できる項目です。

注※2

インストール時の[セキュリティオプションの設定-2]画面で[HiRDB管理者を登録する]を選択した場合を示します。

HiRDBサービスのログオンアカウント設定については，マニュアル「HiRDB システム運用ガイド」の「HiRDB開始時の注意事項」及び「系切り替え機能の運用」を参照してください。

ファイルセキュリティ強化機能の詳細は，「ファイルセキュリティ強化機能」を参照してください。

共用メモリのページ固定機能については，HiRDB/シングルサーバの場合は「共用メモリのページ固定」を，HiRDB/パラレルサーバの場合は「共用メモリのページ固定」を参照してください。

2.1.3　HiRDBグループを設定する

HiRDBグループを設定すると，グループ以外のユーザによるファイルのアクセスを制限できるため，HiRDBの機密保護を強化できます。

また，マルチHiRDB構成の場合，それぞれのHiRDBで異なるグループを設定することによって，別のHiRDBへの誤アクセスを防止できます。

HiRDBグループの設定要否は，HiRDBインストール時の条件によって変わります。

HiRDBグループの設定要否について，次の表に示します。

表2‒1　HiRDBインストール条件によるHiRDBグループ設定要否一覧

HiRDBインストール条件 | HiRDBグループの設定
ファイルセキュリティ強化機能を使用しない | 望ましい
ファイルセキュリティ強化機能を使用する | 推奨アクセス権設定を使用しない
推奨アクセス権設定を使用する | 必須

HiRDBグループに対しては，次に示すユーザ権利※1の付与が必要です。なお，ファイルセキュリティ強化機能を使用する場合※2はHiRDBが自動で付与するため，手動での付与は必要ありません。

ユーザ権利 | 説明
グローバルオブジェクトの作成 | すべてのセッションから利用できるグローバルオブジェクトを作成する場合に必要なユーザ権利です。HiRDBでは，Windows Terminal Serviceの使用や，ユニット間での通信を行うためにグローバルオブジェクトを作成しているため，このユーザ権利の付与が必要です。

注※1

[ローカルセキュリティポリシー]−[ユーザー権利の割り当て]で設定できる項目です。

注※2

ファイルセキュリティ強化機能については，「ファイルセキュリティ強化機能」を参照してください。

2.1.4　OS環境ファイルの設定

次に示す環境下ではリモートシェルを使用します。

HiRDB/パラレルサーバの場合

IPアドレスを引き継がない系切り替え機能を使用する場合

そのため，コマンドを発行するクライアントマシンと，サーバマシンのSERVICESファイル（%windir%¥system32¥drivers¥etc¥SERVICES）に，連絡用ポートのサービス名※とクライアントマシンで起動するリモートシェル接続用のポート番号が必要になります。設定するポート番号はHiRDBをインストールするそれぞれのマシンで同じにしてください。また，マシン内では同じ番号は使用しないでください。指定例を次に示します。

（例）

pdrshsrv　29999/tcp

連絡用ポートのサービス名としてpdrshsrvを指定します。

任意のポート番号を指定します。省略値は29999です。

注※

マルチHiRDBを使用して複数のHiRDBシステムを構成する場合，HiRDBシステム単位に連絡用ポートのサービス名を指定できます。指定方法については，「マルチHiRDBのシステム設計」を参照してください。

注意事項

HiRDB/シングルサーバでIPアドレスを引き継がない系切り替え機能を使用する場合，pdntenvコマンドの-roオプションでリモート系コマンドを使用するように指定する必要があります。pdntenvコマンドについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

2.1.5　ホスト名の登録

HiRDBが使用するホスト名（システム定義及びクライアント環境定義で指定するホスト名）をhostsファイル又はDNSなどに登録し，名前解決してください。HiRDBが使用するホスト名は32文字以内にしてください。

システム定義及びクライアント環境定義中にホスト名を指定する場合，ホスト名，IPアドレス，又はFQDNのどれかの形式で指定します。

また，HiRDB/シングルサーバだけでHiRDBシステムが構成されている※場合，システム定義及びクライアント環境定義中にループバックアドレスを指定できます。ループバックアドレスを指定すると，ホスト名の登録が不要になります。

注※

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

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

参考

ループバックアドレスとは，127.0.0.0〜127.255.255.255の範囲のIPアドレス（例：127.0.0.1）のことです。ループバックアドレスとして使用できるIPアドレスはOSの仕様に依存します。

また，HiRDBでは，localhostを通常のホスト名として扱うため，システム定義などにホスト名としてlocalhostを指定する場合はホスト名を登録し，名前解決しておく必要があります。

ホスト名は，次の表に示すシステム定義及びクライアント環境定義に指定できます。システム定義の詳細についてはマニュアル「HiRDB システム定義」を参照してください。クライアント環境定義の詳細についてはマニュアル「HiRDB UAP開発ガイド」を参照してください。

表2‒2　ホスト名を指定するシステム定義

システム定義の オペランド | 指定するホスト名※1
標準ホスト名※2※4 | 標準ホスト名以外のホスト名※3
pdunit -xオプション | ○ | ○
pdunit -cオプション | ○ | ○
pdstart -xオプション | ○ | ○
pdstart -mオプション | ○ | ○
pdstart -nオプション | ○ | ○
pdstbegin -xオプション | ○ | ○
pd_hostname | ○ | ×
pd_security_host_group | ○ | ○

（凡例）

○：指定できます

×：指定できません

注※1

別名は指定できません。

注※2

標準ホスト名とは，コマンドプロンプトでhostnameコマンドを実行して表示されたホスト名を指します。

注※3

標準ホスト名以外のホスト名とは，複数起動したIPアドレスに対して設定した，標準ホスト名とは異なるホスト名を指します。

注※4

複数のIPアドレスが起動しているマシン上では，IPアドレスの形式で指定してください。標準ホスト名をホスト名又はFQDNの形式で指定した場合は，通信エラーとなることがあります。

表2‒3　ホスト名を指定するクライアント環境定義

クライアント環境定義のオペランド | 指定するホスト名※1
標準ホスト名※2※4 | 標準ホスト名以外のホスト名※3
PDHOST | ○ | ○
PDFESHOST | ○ | ○
PDCLTRCVADDR | ○ | ○
HiRDB_PDHOST | ○ | ○
PDASTHOST | ○ | ○

（凡例）

○：指定できます

注※1

別名は指定できません。

注※2

標準ホスト名とは，コマンドプロンプトでhostnameコマンドを実行して表示されたホスト名を指します。

注※3

標準ホスト名以外のホスト名とは，複数起動したIPアドレスに対して設定した，標準ホスト名とは異なるホスト名を指します。

注※4

複数のIPアドレスが起動しているマシン上では，IPアドレスの形式で指定してください。標準ホスト名をホスト名又はFQDNの形式で指定した場合は，通信エラーとなることがあります。

2.2　HiRDBのインストール手順

実行者　HiRDB管理者

ここでは，HiRDBのインストール手順について説明します。ここで説明する項目を次に示します。

インストール前の注意

HiRDBサーバのインストール手順

インストールが終わると設定される環境変数

インストール後の注意

インストール時に1073エラーになったときの対処

2.2.1　インストール前の注意

HiRDBのインストールは，HiRDB管理者が実行してください。HiRDB管理者にはAdministrators権限が必要です。Administrators権限がないユーザがインストールを実行すると，エラーダイアログを表示してインストールを中止します。誤ってHiRDB管理者以外のユーザでインストールを実行してしまった場合に，インストール完了後にHiRDB管理者を変更する方法については，「HiRDB管理者の変更に関する質問」を参照してください。

電源投入時にはネットワークドライブは接続されていないため，サービスを起動できません。このため，ネットワークドライブにはインストールしないでください。

アンインストール後にインストールをする場合は，アンインストールを実行した後に必ずWindowsを再起動してください。再起動しないでインストールした場合，インストール終了直後に1073エラーが表示されます。このときの対処については，「インストール時に1073エラーになったときの対処」を参照してください。

2.2.2　HiRDBのインストール手順

〈手順〉

インストールする前に，すべてのWindowsアプリケーションを終了させてください。

統合CD-ROM中のhcd_inst.exeを実行して，日立総合インストーラを起動してください。

［日立総合インストーラ］画面で，HiRDB/シングルサーバの場合は［HiRDB/Single Server］を，HiRDB/パラレルサーバの場合は［HiRDB/Parallel Server］を選択して，［インストール実行］をクリックしてください。HiRDBのインストーラが起動します。

HiRDBのインストーラの［プログラムプロダクトの選択］画面で，HiRDB/シングルサーバの場合は［HiRDB/Single Server］を，HiRDB/パラレルサーバの場合は［HiRDB/Parallel Server］を選択して，［次へ］をクリックしてください。選択したプログラムプロダクトのインストーラが起動します。

［セットアップ方法］画面でセットアップ方法を選択します。通常は［標準セットアップ］を選択します。マルチHiRDBを使用する場合は，［識別子付きセットアップ］を選択します。マルチHiRDBについては，「マルチHiRDBのインストール」を参照してください。

［セットアップ識別子の設定］画面でセットアップ識別子を指定します。セットアップ識別子は4文字以内の半角英数字で指定します。なお，［標準セットアップ］を選択した場合は，［セットアップ識別子の設定］画面は表示されません。

［ユーザの情報］画面で，ユーザの情報として名前と会社名を入力します。

［インストール先の選択］画面で，インストールディレクトリを指定します。省略値を次に示します。

なお，この章では，これ以降「Windowsのインストール先ドライブ」をC:と仮定します。

HiRDB/シングルサーバの場合：Windowsのインストール先ドライブ¥win32app¥hitachi¥hirdb_s

HiRDB/パラレルサーバの場合：Windowsのインストール先ドライブ¥win32app¥hitachi¥hirdb_p

セットアップ識別子を指定してインストールした場合は，「hirdb_s」又は「hirdb_p」にセットアップ識別子が付いたディレクトリ名称となります。

（例）Windowsのインストール先ドライブ¥win32app¥hitachi¥hirdb_sUNT1

省略値で問題なければ，そのまま［次へ］をクリックしてください。

インストール先ディレクトリ名を変更する場合，次のことに注意してください。

・ドライブで始まり，次の要素で構成される文字列で指定してください。

　英数字

　_（下線）

　.（ピリオド）

　△（空白）

　（ （左括弧）

　） （右括弧）

　パス区切りの¥

・ドライブだけの指定はできません。

・全角文字，及び特殊記号はディレクトリ名に使用できません。

・パス名の長さは200文字（バイト）以内にしてください。

・ジャンクションポイント，又はシンボリックリンクを含むパスにはインストールできません。

［オペランド省略時動作の選択］画面で，オペランド省略時動作を選択します。オペランド省略時動作の選択基準については，「オペランド省略時動作の概要」を参照してください。

［共用メモリの割り当て先の選択］画面で，共用メモリの割り当て先を選択します。共用メモリの割り当て先については，「仮想メモリの確認」を参照してください。選択すると，確認のポップアップメッセージが表示されますので，内容を確認して，問題がなければ［OK］をクリックしてください。

［Windowsファイアウォールへの登録］画面で，HiRDBサーバのプログラムをWindowsファイアウォールの例外リストに登録するかどうかを選択できます。Windowsファイアウォールを有効にしている環境でHiRDBを使用する場合は，例外リストに登録してください。

さらに，［セキュリティが強化されたファイアウォール］の詳細設定ができます。詳細設定では，HiRDBを登録するプロファイルを選択します。選択基準を次に示します。

項番 | HiRDBを登録するプロファイル | 選択基準
1 | アクティブ | HiRDBインストール時にOSが使用しているプロファイルに例外登録する場合に選択します。
2 | すべてのプロファイル | ドメイン，プライベート，パブリックのすべてのプロファイルに例外登録する場合に指定します。 OSが動的にネットワークの場所を変更することがあるため，その際，通信エラーによってHiRDBが不当にタイムアウトやサーバダウンとなる現象を回避できます。 上記以外の場合は，OSが動的にネットワークの場所を変更することはありませんが，OSのネットワークの場所を手動で変更したときに，併せてHiRDBに対するネットワークの場所も変更されます。
3 | ドメイン | ネットワークの場所を個別に指定する場合に選択します。セキュリティ強化のため，HiRDBが使用するネットワークの場所を限定する場合に選択します。
4 | プライベート
5 | パブリック

［標準セットアップ］の場合，システムの環境変数にHiRDBの環境変数を設定するかどうかを選択してください（Windows (x64)の場合を除く）。HiRDBの環境変数については，「HiRDBの環境変数」を参照してください。

［トラブルシュート情報の出力先の設定］画面で，Windowsダンプの出力先を設定します。Windowsダンプ出力については，「Windowsダンプ出力」を参照してください。

［セキュリティオプションの設定-1］画面で，ファイルセキュリティ強化機能を使用するかどうかを選択します。ファイルセキュリティ強化機能については，「ファイルセキュリティ強化機能」を参照してください。

［セキュリティオプションの設定-2］画面で，HiRDB管理者及びHiRDBグループの入力をします。

［ファイルコピーの開始］画面で，設定した内容を確認して，問題がなければ［次へ］をクリックしてください。インストールが始まります。

インストールが終了すると，［セットアップの完了］画面が表示されます。

再起動してもよい場合は，［はい，直ちにコンピュータを再起動します。］を選択して，［完了］をクリックしてください。

ほかのプログラムプロダクトをインストールするなど，すぐに再起動しない場合は，［いいえ，後でコンピュータを再起動します。］を選択して，［完了］をクリックしてください。ただし，HiRDBを使う前に必ずWindowsを再起動してください。

2.2.3　HiRDBの環境変数

(1)　設定される環境変数

インストール時に，システムの環境変数にHiRDBの環境変数を設定する選択をした場合，インストールが終わると次の表に示す環境変数がシステム環境変数に設定されます。システム環境変数は［コントロールパネル］の［システム］をダブルクリックして，［システムのプロパティ］の［環境］タブで確認できます。

表2‒4　システム環境変数に設定される環境変数

環境変数 | 設定する内容
PDDIR※1 | HiRDB運用ディレクトリ（インストールディレクトリ）が設定されます。 （例）C:¥win32app¥hitachi¥hirdb_s
PDCONFPATH※1 | HiRDBシステム定義ファイルを格納するディレクトリが設定されます。 （例）C:¥win32app¥hitachi¥hirdb_s¥CONF

PATH※2

%PDDIR%¥CLIENT¥UTL及び%PDDIR%¥BINが追加されます。

（例）C:¥win32app¥hitachi¥hirdb_s¥CLIENT¥UTL

　　 C:¥win32app¥hitachi¥hirdb_s¥BIN

なお，%PDDIR%¥BINは，PATHの最後に追加されます。

PDUXPLDIR | HiRDBの作業ディレクトリが設定されます。 （例）C:¥win32app¥hitachi¥hirdb_s¥UXPLDIR

注※1

PDDIRの絶対パス名長は，200バイト以内，PDCONFPATHの絶対パス名長は，213バイト以内で設定してください。

注※2

PATHの設定値が512バイト以上の場合，表で示す環境変数が正しく設定されません。この場合，環境変数の設定値を確認して，必要ならば設定値を修正してください。

なお，LANG環境変数は設定されません。そのため，マニュアル「HiRDB UAP開発ガイド」を参照して，ユーザが設定してください。

備考

pd_tmp_directoryオペランドを指定していない場合，環境変数TMPを省略すると，pd_tmp_directoryオペランドを省略した場合と同様のディレクトリ下に一時ファイル（テンポラリファイル）を作成します。また，環境変数TMPを設定するときは，ディレクトリパス長を200バイト以内で設定してください。

(2)　注意事項

標準セットアップの場合，システム全体に影響を与えないように，HiRDBの環境変数を設定するかどうかを選択できます（Windows (x64)の場合を除く）。HiRDBの環境変数の設定方法選択時の注意事項を次に示します。

システム環境変数にHiRDBの環境変数を設定しなかった場合の注意事項

運用方法がマルチHiRDBと同じになります。マルチHiRDBについては，「マルチHiRDBの設計」を参照してください。

HiRDBの標準セットアップを前提とした製品を使用する場合，環境変数を設定する必要があります。詳細は，関連製品のリリースノート，又はマニュアルを参照してください。

マルチHiRDBに対応した関連製品でも，HiRDBの環境変数の設定する必要な場合があります。設定の必要な環境変数については，関連製品のリリースノート，又はマニュアルを参照してください。

システムの環境変数にHiRDBの環境変数を設定した場合の注意事項

ほかの製品がHiRDBのVCランタイム（msvcr71.dll）を参照する場合があります。HiRDBが提供するVCランタイムが，ほかの製品が提供するVCランタイムより古い場合，ほかの製品が意図しない動作をするおそれがあります。そのため，HiRDBのディレクトリをPATH環境変数の最後に設定する必要があります。HiRDBのインストール直後は，PATH環境変数の最後にHiRDBのディレクトリを設定しますが，ほかの製品をインストールした場合などは，HiRDBのディレクトリがPATH環境変数の最後にならなくなることがあるため，注意してください。

そのほかの注意事項

08-02より前のバージョンでは，インストール時にPATH環境変数に登録したHiRDBのインストールパスを削除していないため，PATH環境変数に使用していないHiRDBのインストールパスが残っていることがあります。08-02以降のバージョンでは，使用していないHiRDBのインストールパスはPATH環境変数から削除されます。

2.2.4　インストール後の注意

HiRDB/パラレルサーバの場合，又はIPアドレスを引き継がない系切り替え機能を使用する場合，次のように設定する必要があります。

サービスのスタートアップ種別：自動

サービス実行時に使用するログオンのアカウント：HiRDB管理者

設定方法についてはOSのマニュアルを参照してください。

HiRDBをインストールした後には，必ずWindowsを再起動してください。

HiRDBで使用する文字コードは，シフトJIS漢字コード（SJIS）が設定されています。

2.2.5　インストール時に1073エラーになったときの対処

アンインストール後にインストールをする場合は，アンインストールを実行した後に必ずリブートしてください。リブートをしないでインストールした場合，インストール終了直後に1073エラーが表示されます。ここでは，1073エラーが表示されたときの対処方法を説明します。

Windowsを再起動して，アンインストール時のレジストリ及びサービス登録の内容が反映されるようにします。

通常と同じようにインストールしてWindowsを再起動します。インストール先はエラーになったときと同じディレクトリに指定してください。なお，ここでHiRDBを開始しようとしてもサービスが登録されていないため，開始できません。

アンインストール※してください。ただし，このときはDLLやEXEファイルは残ったままの状態となります。

残っているファイルを削除します。後でインストールしたときに回復させるため，定義情報があるCONFディレクトリ下にあるファイルを退避しておいてください。その後，インストールしたディレクトリを削除してください（省略値でインストールしている場合は，HiRDB/シングルサーバのときはC:¥win32app¥hitachi¥hirdb_s，HiRDB/パラレルサーバのときはC:¥win32app¥hitachi¥hirdb_pとなります）。

Windowsを再起動してください。

通常と同じ要領でインストールしてWindowsを再起動してください。

退避していたHiRDBシステム定義ファイルを%PDDIR%¥confディレクトリ下にコピーしてください。

HiRDB開始準備（システムファイルなどの割り当て，初期化）をしてから開始してください。

1.〜5. を実行すると，異常状態のレジストリ及びサービス登録を正常状態（初期状態）に戻します。6. 以降は通常のインストール手順となります。

注※

アンインストール時にクライアント用の定義情報hirdb.iniファイルも削除されるため，必要に応じて退避しておいてください。

2.2.6　Windowsダンプ出力

HiRDBの実行中にアプリケーション例外が発生した場合，Windowsがプログラムエラーを検知します。このプログラムエラーの情報を取得するためには，Windowsのダンプが必要になります。

ダンプはWindows Error Reportingの機能を使用して出力します。HiRDBでは，インストール時の［トラブルシュート情報の出力先の設定］画面で，このダンプの出力先を設定します。

ここでは，Windowsダンプの出力に関する注意事項，及びアプリケーション例外発生時の対処ついて説明します。

(1)　Windowsダンプの出力に関する注意事項

ダンプ出力時の入出力の負荷を軽減するため，次の場所を出力先に指定しないでください。

HiRDBの運用ディレクトリ

Windowsのページングファイルがあるドライブ

Windowsダンプの最大容量は，およそ5ギガバイトです。指定したディレクトリに十分な空き領域がない場合，ダンプが出力できなくなり，障害調査のための情報が取得できなくなるおそれがあります。そのため，ダンプの出力先には十分な空き領域があるディレクトリを指定してください。また，出力されたダンプは障害調査後には不要になるため削除してください。

マルチHiRDBなどの理由によって複数のHiRDBシステムがマシンにある場合，最後にインストールしたHiRDBのダンプ出力先が有効になります。出力先を確認する場合にはpdntenv -wdコマンドを実行してください。

マルチHiRDBなどの理由によって複数のHiRDBシステムがマシンにある場合，すべてのHiRDBがダンプ出力対象となります。

ダンプ出力先に指定したディレクトリを削除した場合，ダンプ出力時にディレクトリを再作成します。

(2)　アプリケーション例外発生時の対処

次のどちらかによって，アプリケーション例外が発生したことを確認できます。

Windowsのイベントログに次のメッセージが出力されている

ログの種類：アプリケーション

レベル：情報

ソース名：Windows Error Reporting

問題の署名のP1：問題が発生しているプロセス名

Windowsのポップアップメッセージが表示されている

プロセスの停止を通知するWindowsのポップアップメッセージが表示されます。メッセージには，動作を停止したプロセス名が表示されます。

アプリケーション例外が発生した場合は，次の手順でダンプを取得してください。

〈手順〉

前述のイベントログ又はポップアップメッセージに表示されたプロセス名を確認します。

1.で確認したプロセス名を指定してpdntenv -wdコマンドを実行します。

2.で表示された出力先のダンプを取得します。

2.3　インストール後の作業

ここでは，製品をインストールした後の作業について説明します。

2.3.1　文字コードの選択

HiRDBで使用する文字コードを選択します。新規インストール後はシフトJIS漢字コードが設定されています。単一バイト文字コード，Unicode（UTF-8），Unicode（IVS対応UTF-8），EUC中国語漢字コード，及び中国語漢字コード（GB18030）を使用する場合は，pdntenvコマンドで使用する文字コードを変更してください。

注意事項

データベースの構築後に文字コードを変更する場合は，データベースを再構築する必要があります。

2.3.2　HiRDB運用ディレクトリ下のファイルの削除

サーバプロセス，又はクライアントの強制終了時などに，HiRDBは%PDDIR%¥spool下にトラブルシュート情報を出力します。また，ワークファイルの出力先を特に指定していない場合にコマンド又はユティリティを［Ctrl＋C］キーを押すなどして途中終了させると，%PDDIR%¥tmp下にコマンド又はユティリティが出力した作業用一時ファイルが削除されないで残ります。これらのファイルを残しておくと，HiRDB運用ディレクトリがあるディスクの容量を圧迫する原因になります。HiRDB運用ディレクトリがあるディスクの容量が不足するとHiRDBが異常終了することがあるため，HiRDBは次に示すファイルを定期的に削除します。

トラブルシュート情報ファイル（%PDDIR%¥spool下のファイル）

作業用一時ファイル（%PDDIR%¥tmp下のファイル）

pd_tmp_directoryオペランドに指定したディレクトリ下のファイル

これらの単調増加するファイルについては，「単調増加ファイル」を参照してください。

なお，通常はこれらのファイルを24時間ごとに削除します。この削除間隔をpd_spool_cleanup_intervalオペランドで変更できます。また，pd_spool_cleanup_interval_levelオペランドで指定した日より前に出力されたファイルだけを削除するという指定ができます。

このほかにも，トラブルシュート情報（%PDDIR%¥spool下のファイル）を一括して削除する方法があります。

pdcspoolコマンドでトラブルシュート情報ファイルを削除できます。作業用一時ファイル（%PDDIR%¥tmp下のファイル）も削除できます。

HiRDBの開始時に自動的にトラブルシュート情報ファイルを削除します。pd_spool_cleanupオペランドでトラブルシュート情報ファイルを削除するかどうかを指定します。このオペランドの省略値は「削除する」です。また，pd_spool_cleanup_levelオペランドで指定した日より前に出力されたトラブルシュート情報ファイルだけを削除するという指定ができます。

備考

pdcspoolコマンドのオプション，pd_spool_cleanup_level，又はpd_spool_cleanup_intervalオペランドの指定で，削除するトラブルシュート情報を選択できます。

2.3.3　ワークファイル出力先ディレクトリの作成

実行者　HiRDB管理者

HiRDBが出力するワークファイルの出力先となるディレクトリを作成してください。コマンドやユティリティの実行時に生成される様々なワークファイルの出力先として，ここで作成したディレクトリを指定します。これによって，出力先がユニット単位で1か所になるため，煩雑になりやすいワークファイルの管理が容易になります。

ワークファイル出力先ディレクトリを作成する場合のグループ名又はユーザ名に付与するアクセス許可については，次に示すとおり設定してください。

ファイルセキュリティ強化機能未使用時

グループ名又はユーザ名：Everyone

アクセス許可：フルコントロール

ファイルセキュリティ強化機能使用時

次の表に示すアクセス許可と同等以上のセキュリティ設定をしてください。

項番 | グループ名又はユーザ名 | アクセス許可
1 | HiRDB管理者 | フルコントロール
2 | HiRDBグループ | フルコントロール

ワークファイル出力先ディレクトリを作成しない運用もできますが，その場合はワークファイルの出力先が一定にならないため，pdcspoolコマンドによるワークファイルの削除ができなくなります。そのため，ワークファイル出力先ディレクトリを作成しておくことをお勧めします。

なお，ファイルセキュリティ強化機能の詳細については，「ファイルセキュリティ強化機能」を参照してください。

(1)　ワークファイル出力先ディレクトリの容量の見積もり

ワークファイル出力先ディレクトリ下の空き領域は，次の値以上に設定してください。ワークファイル出力中にHiRDB又はコマンドが異常終了した場合，ワークファイルは削除されません。そのため，pdcspoolコマンドを実行する前にディスク容量が不足しないように，ワークファイル出力先ディレクトリの空き領域には十分に余裕のある値を設定してください。

ワークファイル出力先ディレクトリの容量（単位：キロバイト）＝

178224＋ａ＋ｂ＋ｃ＋ｅ＋ｆ＋ｇ＋ｈ

変数 | 説明 | 計算式，又は計算式の参照箇所
ａ | pdconstck実行時の処理結果ファイルの容量 | 「整合性チェックユティリティ（pdconstck）実行時のファイルの容量」
ｂ | pddbst実行時の次のファイルの容量 ワーク用ファイル ソート用ワークファイル | 「データベース状態解析ユティリティ（pddbst）実行時のファイルの容量」

ｃ

pdload実行時の次のファイルの容量

インデクス情報ファイル

エラー情報ファイル

エラー情報ファイル作成用一時ファイル

LOB中間ファイル

ソート用ワークファイル

「データベース作成ユティリティ（pdload）実行時のファイルの容量」

ｅ | pdrbal実行時の次のファイルの容量 インデクス情報ファイル ソート用ワークファイル | 「リバランスユティリティ（pdrbal）実行時のファイルの容量」
ｆ | pdrorg実行時の次のファイルの容量 インデクス情報ファイル ソート用ワークファイル | 「データベース再編成ユティリティ（pdrorg）実行時のファイルの容量」
ｇ | pdrstr -w実行時のソート用ワークディレクトリの容量 | マニュアル「HiRDB コマンドリファレンス」

ｈ

pdstedit実行時の次のファイルの容量

ワーク用ファイル

ソート用ワークファイル

DAT形式ファイル

「統計解析ユティリティ（pdstedit）実行時のファイルの容量」

(2)　ワークファイル出力先ディレクトリの指定

ワークファイルの出力先を1か所にするには，pd_tmp_directoryオペランドに作成したディレクトリを指定します。

pd_tmp_directoryオペランドを指定していない場合，HiRDBは各コマンド及びユティリティによって決められたディレクトリにワークファイルを出力します。なお，コマンドやユティリティ実行時のワークファイル出力先は次の順番で決定されます。

コマンドのオプション，又はユティリティの制御文で指定した出力先

1.の指定がない場合，pd_tmp_directoryオペランドで指定した出力先

2.の指定がない場合，システム環境変数TMPで指定した出力先

3.の指定がない場合，%PDDIR%¥tmp

(3)　ワークファイルの削除

HiRDBは通常，24時間ごとにワークファイルを削除します。この削除間隔をpd_spool_cleanup_intervalオペランドで変更できます。また，pd_spool_cleanup_interval_levelオペランドで指定した日より前に出力されたファイルだけを削除するという指定ができます。このとき，pd_tmp_directoryオペランドで指定したワークファイル出力先ディレクトリ下のファイルを削除します。

また，コマンドやユティリティが出力したワークファイルのうち，HiRDBが削除しないものについては，pdcspoolコマンドによって定期的に削除する必要があります。この場合にも，pd_tmp_directoryオペランドで指定したワークファイル出力先ディレクトリ下のファイルを削除します。

ワークファイルの削除については，「HiRDB運用ディレクトリ下のファイルの削除」を参照してください。

2.3.4　HiRDBファイルシステム領域を作成する準備

(1)　事前準備

実行者　Administrator

次の作業を行います。

ハードディスクを用意します。

初期化したハードディスクにパーティションを設定します。

NTFS領域上にHiRDBファイルシステム領域を作成する場合は，ディスクの初期化を行います。

これらの作業方法については，OSのマニュアルを参照してください。

(2)　HiRDBファイルシステム領域の作成

実行者　HiRDB管理者

pdfmkfsコマンドを実行して，NTFS領域上にHiRDBファイルシステム領域を作成します。又は，ダイレクトディスクアクセス（raw I/O）を使用する場合，ディスクパーティション（論理ドライブ）上にHiRDBファイルシステム領域を作成します。

(3)　HiRDBファイルシステム領域のアクセス権の設定

HiRDBファイルシステム領域のアクセス権は，ファイルセキュリティ強化機能を使用していない場合，すべてのユーザに対してすべての権限を与える「Everyoneフルコントロール」となります。このため，不特定多数のユーザが領域にアクセスできる状態になっています。

不特定多数のユーザからのアクセスを防止するには，ファイルセキュリティ強化機能を使用してください。詳細は，「ファイルセキュリティ強化機能」を参照してください。

(4)　OS又はデバイスドライバの機能で，物理ボリューム及び論理ボリュームの入出力エラーを検知するまでの時間設定

実行者　Administrator

入出力処理が無応答状態になると，そのほかのUAP，ユティリティ，又は運用コマンドもその影響を受けて停滞します。

OS又はデバイスドライバの機能※で物理ボリューム又は論理ボリュームの入出力エラーを検知するまでの時間を設定できる場合は，入出力処理が無応答にならないよう，設定を行ってください。

注※

詳細については，OS又はデバイスドライバのマニュアルを参照してください。

入出力処理が無応答となった場合，UAPやティリティの強制終了も停滞する可能性があるため，設定値は，オペランド又はオプションで指定できるUAP又はユティリティの監視時間より小さくしてください。

オペランド又はオプションで指定できるUAP又はユティリティの監視時間については，マニュアル「HiRDB システム運用ガイド」の「UAP又はユティリティの実行時間の監視（無応答障害時の影響を抑える方法）」を参照してください。

2.3.5　Windowsファイアウォールの設定を有効にしている場合

Windowsファイアウォールの設定を有効にしている場合，例外リストにHiRDBが使用するポート番号やプログラムを登録する必要があります。登録方法については，「Windowsファイアウォールの例外リストへの登録」を参照してください。

2.3.6　暗号化通信環境の構築

通信暗号化機能を使用する場合の，暗号化通信環境の構築手順について説明します。

(1)　秘密鍵の生成

サーバ証明書に登録する秘密鍵を生成します。

次のアルゴリズムの秘密鍵を生成してください。

RSA

ECDSA

(2)　サーバ証明書の生成

(1)の秘密鍵を指定してサーバ証明書を生成します。

(3)　HiRDBシステム定義の設定

次の表に示すHiRDBシステム定義を設定する必要があります。

表2‒5　通信暗号化機能を使用する場合に指定するシステム定義

システム定義 | 設定内容
pd_crypto_service_port | クライアントからの暗号化通信の接続要求を受け付けるポート番号を指定します。
pd_crypto_private_key | 秘密鍵のファイルパスを指定します。
pd_crypto_certificate_file | サーバ証明書のファイルパスを指定します。

(4)　HiRDBクライアントの設定

通信暗号化機能を使用するクライアントでは，次の表に示すクライアント環境定義を設定する必要があります。

表2‒6　通信暗号化機能を使用するクライアントで指定するクライアント環境定義

設定項目 | 設定内容
通信暗号化機能 | PDSOCKETCRYPTO=YESを指定します。
接続方式 | PDCONTYPE=ACTIVEを指定します。

接続形態

次のどちらかを指定して高速接続を使用します。

PDFESGRP

PDFESHOST，PDSERVICEGRP，PDSERVICEPORT

PDFESGRP又はPDSERVICEPORTのポート番号にはHiRDBシステム定義pd_crypto_service_portに指定したポート番号を指定します。

2.4　付加PPのインストール時の注意

付加PPをインストールする場合の，規則及び注意について説明します。

HiRDBの付加PPの機能を使用する場合は，付加PPをインストールします。付加PPの機能及び付加PPをインストールするサーバを次の表に示します。

表2‒7　付加PPの機能とインストール先サーバ

製品名 | 付加PPを導入すると使用できる機能 | インストール先サーバマシン
HiRDB Advanced High Availability | 1：1スタンバイレス型系切り替え機能 影響分散スタンバイレス型系切り替え機能 | すべてのサーバマシン
グローバルバッファの動的変更（pdbufmodコマンド）
システム構成変更コマンド（pdchgconfコマンド）
表のマトリクス分割
分割格納条件の変更（ALTER TABLE）
HiRDB Non Recover FES | 回復不要FES
HiRDB Accelerator | インメモリデータ処理

規則及び注意事項

付加PPはキーモジュールで提供されます。

付加PPのキーモジュールは，HiRDBインストールディレクトリの直下にコピーされます。

付加PPをインストールする場合は，HiRDBサービスを停止した状態で実行してください。HiRDBサービスが起動中の場合はインストールを中止します。

HiRDBをバージョンアップした場合は，HiRDBのバージョンに対応する付加PPをインストールする必要があります。また，HiRDBのインストールディレクトリを変更した場合は，付加PPを再インストールする必要があります。

付加PPのインストールを実行できるのは，Administratorsグループのユーザです。

HiRDBがインストールされていないと，付加PPはインストールできません。

付加PPをアンインストールする場合は，HiRDBサービスを停止した状態で実行してください。アンインストールすると，インストール時にコピー及び設定したすべての情報が削除されます。

セットアップ識別子付きのHiRDBに付加PPをインストールする場合は，インストール先のHiRDBと同じセットアップ識別子を指定して付加PPをインストールしてください。

2.5　HiRDBのアンインストール手順

HiRDBのアンインストールは，今後このサーバマシンでHiRDBを使用しないときだけ実施してください。それ以外でアンインストールを実施することはお勧めしません。

2.5.1　HiRDBをアンインストールするユニットの状態を確認

HiRDBをアンインストールする前に，HiRDBをアンインストールするユニットの状態を確認します。該当するユニットでpdls -d ustコマンドを実行します。

終了ステータスが0の場合（ユニットの状態がONLINE）：

HiRDBが稼働中です。HiRDBをpdstopコマンドで正常終了させてください。

終了ステータスが4の場合（ユニットの状態がSTARTING，又はSTOPPING）：

HiRDBが開始処理の途中，又は停止処理の途中です。処理が終了してからpdls -d ustコマンドを再度実行してください。

終了ステータスが8の場合（ユニットの状態がPAUSE）：

障害によって，プロセスサーバプロセスの再起動を中断した状態です。この状態で，アンインストールを実行する場合は，「HiRDBのアンインストール」へ進んでください。

アンインストールを実行しない場合は，KFPS00715-Eメッセージ及びこのメッセージ以前のイベントログに出力されたメッセージを参照して障害の原因を取り除いてから，サービスを開始し，ユニットを再開始してください。

終了ステータスが12の場合の場合（ユニットの状態がSTOP）：

HiRDBが停止状態です。サービスを停止してください。

終了ステータスが16の場合（セットアップ状態がUNSETUP）：

アンインストールを実行できます。

2.5.2　HiRDBのサービスの停止

アンインストールするHiRDBのサービスが開始しているかどうかを［コントロールパネル］−［サービス］で確認してください。開始している場合はHiRDBのサービスを停止してから，アンインストールを実行してください。

2.5.3　HiRDBのアンインストール

HiRDBをアンインストールする場合は，コマンド，ユティリティ，アプリケーション，HiRDB Datareplicator，及びHiRDB Dataextractorはあらかじめ停止しておいてください。これらを停止しないと，実行形式ファイルや共用ライブラリの削除に失敗することがあります。

注意事項

アンインストールを行う前に，Windowsファイアウォールの例外リストからHiRDBが使用するポート番号やプログラムを削除してください。アンインストールを行った後では正しく削除できません。

削除する前にアンインストールしてしまった場合は，HiRDBを再度インストールし，その後に例外リストから削除する必要があります。

例外リストからの削除方法については，「Windowsファイアウォールの例外リストからの削除」を参照してください。

(1)　HiRDBのアンインストール

HiRDB/シングルサーバのアンインストール手順を次に示します。

〈手順〉

［スタート］−［プログラム］−［HiRDBSingleServer］−［HiRDBSingleServerのアンインストール］を選択します。

［HiRDBSingleServerのアンインストール］が登録されていないバージョンの場合は，［コントロールパネル］−［アプリケーションの追加と削除］の［インストールと削除］を表示します。一覧の中から「HiRDB/SingleServer」を選択し，［追加と削除］をクリックし，［OK］ボタンをクリックします。

アンインストールが始まります。しばらくすると，［共有ファイルを削除しますか？］という問い合わせのメッセージが表示されることがあります。表示されたら，［いいえ］をクリックしてください。

アンインストールが終わると，「HiRDB/Single Serverの再インストールは，コンピュータを再起動した後に行ってください」というメッセージが表示されます。［OK］ボタンをクリックしてください。

次に［コンピュータからプログラムを削除］ダイアログボックスの［OK］ボタンをクリックしてください。これで，アンインストールは終了です。

アンインストールが成功していない場合，考えられる原因と対策を次に示します。

考えられる原因 | 対策
コマンド，ユティリティ，HiRDB Datareplicator，又はHiRDB Dataextractorのどれかが実行されています。 | コマンド，ユティリティ，HiRDB Datareplicator，又はHiRDB Dataextractorを停止して，アンインストールを再度実行してください。
そのほか（障害が発生しているなど） | イベントログに出力されたメッセージを参照して，障害原因を取り除いてから，アンインストールを再度実行してください。

アンインストールしても，インストール後に作成されたディレクトリ及びファイルは，インストールディレクトリ下に残ります。インストールディレクトリがデフォルトの場合は，エクスプローラなどを使用して，「C:¥win32app¥hitachi」ディレクトリ下の「hirdb_s」ディレクトリを削除してください。ただし，HiRDB Control Manager - Agentをアンインストールしていない場合には，先にHiRDB Control Manager - Agentをアンインストールしてから，「hirdb_s」ディレクトリを削除してください。

(2)　HiRDB/パラレルサーバのアンインストール

HiRDB/パラレルサーバをアンインストールする場合は，HiRDB/パラレルサーバを構成するすべてのサーバマシンでアンインストールを実施します。アンインストール手順を次に示します。

〈手順〉

［スタート］−［プログラム］−［HiRDBParallelServer］−［HiRDBParallelServerのアンインストール］を選択します。

［HiRDBParallelServerのアンインストール］が登録されていないバージョンの場合は，［コントロールパネル］−［アプリケーションの追加と削除］の［インストールと削除］を表示します。一覧の中から「HiRDB/ParallelServer」を選択し，［追加と削除］をクリックし，［OK］ボタンをクリックします。

アンインストールが始まります。しばらくすると，［共有ファイルを削除しますか？］という問い合わせのメッセージが表示されることがあります。表示されたら，［いいえ］をクリックしてください。

アンインストールが終わると，「HiRDB/Parallel Serverの再インストールは，コンピュータを再起動した後に行ってください」というメッセージが表示されます。［OK］ボタンをクリックしてください。

次に［コンピュータからプログラムを削除］ダイアログボックスの［OK］ボタンをクリックしてください。これで，アンインストールは終了です。

アンインストールが成功していない場合，考えられる原因と対策を次に示します。

考えられる原因 | 対策
コマンド，ユティリティ，HiRDB Datareplicator，又はHiRDB Dataextractorのどれかが実行されています。 | コマンド，ユティリティ，HiRDB Datareplicator，又はHiRDB Dataextractorを停止して，アンインストールを再度実行してください。
そのほか（障害が発生しているなど） | イベントログに出力されたメッセージを参照して，障害原因を取り除いてから，アンインストールを再度実行してください。

アンインストールしても，インストール後に作成されたディレクトリ及びファイルは，インストールディレクトリ下に残ります。インストールディレクトリがデフォルトの場合は，エクスプローラなどを使用して，「C:¥win32app¥hitachi」ディレクトリ下の「hirdb_p」ディレクトリを削除してください。ただし，HiRDB Control Manager - Agentをアンインストールしていない場合には，先にHiRDB Control Manager - Agentをアンインストールしてから，「hirdb_p」ディレクトリを削除してください。

2.5.4　注意事項

HiRDBをアンインストールした後に，HiRDB運用ディレクトリ下にファイルが残ることがあります。この場合，ファイルを削除してください。

2.6　Windowsファイアウォールの例外リストへの登録

Windowsファイアウォールを有効にしている環境でHiRDBを使用する場合，HiRDBが使用するポート番号やプログラムを例外リストに登録してください。ここでは，Windowsファイアウォールの設定の確認，及び例外リストの登録方法について説明します。

Windowsファイアウォールを有効にしている場合，次に示すプログラム及びポート番号を例外リストに登録します。

HiRDBサーバのプログラム

リモートシェル実行時に使用するポート番号

UAP

注意事項

Windowsファイアウォールを有効にしている環境で，前記のプログラムやポート番号を例外リストに登録しないと，HiRDBが開始できない，UAPがHiRDBに接続できないなどの不具合が起きることがあります。

参考

HiRDB/シングルサーバで，HiRDBサーバとHiRDBクライアントが同一マシン上にある場合，設定によって例外リストへの登録が不要になります。詳細については，「例外リストへの登録が不要になるケース」を参照してください。

また，HiRDB/シングルサーバで，HiRDBサーバとHiRDBクライアントが同一サーバに存在しない場合，Windowsファイアウォールの例外リストへの登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定できます。詳細については，「HiRDBサーバのプログラムを例外リストに登録する」を参照してください。

2.6.1　Windowsファイアウォールの設定を確認する

HiRDBとの通信が許可されているかどうか，Windowsファイアウォールの設定で確認します。

［コントロールパネル］−［管理ツール］−［セキュリティが強化されたファイアウォール］の［ローカルコンピュータのセキュリティが強化されたファイアウォール］のアクティブなプロファイルで確認します。

Windowsファイアウォールが有効で，受信接続又は送信接続がブロックされる状態の場合，以降で説明する例外リストへの登録が必要です。

2.6.2　HiRDBサーバのプログラムを例外リストに登録する

HiRDBサーバのプログラムを例外リストに登録します。なお，登録はHiRDBサーバを停止した状態で行ってください。

(1)　前提条件

HiRDBのインストール時に，［Windowsファイアウォールへの登録］画面でHiRDBサーバのプログラムをWindowsファイアウォールの例外リストに登録済みの場合は，(2)で説明する作業は必要ありません。「リモートシェル実行時に使用するポート番号を例外リストに登録する」にお進みください。

HiRDB/シングルサーバで，HiRDBサーバとHiRDBクライアントが同一サーバに存在しない場合，次に示す設定を行うとWindowsファイアウォールの例外リストへの登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定できます。この場合の登録方法については，「登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定する場合」で説明します。

pdunitオペランドの-xオプションにループバックアドレス（127.0.0.1）を指定する

pd_rpc_bind_loopback_addressオペランドにSを指定する

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

pd_service_portオペランド

pd_scd_portオペランド

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

次のクライアント環境定義を指定し，高速接続機能を使用してHiRDBサーバに接続する

PDSERVICEPORT

PDSERVICEGRP

PDSRVTYPE = PC

(2)　登録方法

(a)　登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定しない場合

HiRDBコマンドプロンプトを起動し，次に示すバッチファイルを実行してください。

%PDDIR%¥BIN¥pdsetfw.bat "セットアップ識別子"

また，pdsetfw.batコマンドを実行して登録する方法もあります。pdsetfw.batコマンドについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

(b)　登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定する場合

HiRDBをインストールした後に，HiRDBクライアントから接続要求を受け付けるプロセス（pdrdmd及びpdscdd）のポート番号，又はプログラム名（.exeファイル）をWindowsファイアウォールの例外リストに登録してください。それぞれの手順を次に示します。

ポート番号を指定して登録する場合

次のバッチファイルを作成します。

echo on
netsh firewall set portopening tcp HiRDBのポート番号※1 "HiRDB/Single Server セットアップ識別子※2 (pdrdmd port)"
netsh firewall set portopening tcp スケジューラプロセスのポート番号※3 "HiRDB/Single Server セットアップ識別子※2 (pdscdd port)"
netsh firewall set portopening tcp スケジューラプロセスの暗号化通信接続用のポート番号※4 "HiRDB/Single Server セットアップ識別子※2 (pdscdd SSL port)"※5

HiRDBコマンドプロンプトを起動して，作成したバッチファイルを実行します。

注※1

HiRDBのポート番号は，次のどちらかのシステム定義で指定した値です。

pd_name_portオペランド

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

注※2

インストール時に指定したセットアップ識別子を指定してください。標準セットアップを指定してインストールを行った場合は，セットアップ識別子を省略してください。

注※3

スケジューラプロセスのポート番号は，次のどれかのシステム定義で指定した値です。

pd_service_portオペランド

pd_scd_portオペランド

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

注※4

スケジューラプロセスの暗号化通信接続用のポート番号は，次のシステム定義で指定した値です。

pd_crypto_service_portオペランド

注※5

通信暗号化機能を使用する場合に指定してください。

プログラム名を指定して登録する場合

次のバッチファイルを作成します。

echo on
netsh firewall set allowedprogram "%PDDIR%¥lib¥servers¥pdrdmd.exe" "HiRDB/Single Server セットアップ識別子※ (pdrdmd.exe)"
netsh firewall set allowedprogram "%PDDIR%¥lib¥servers¥pdscdd.exe" "HiRDB/Single Server セットアップ識別子※ (pdscdd.exe)"

HiRDBコマンドプロンプトを起動して，作成したバッチファイルを実行します。

注※

インストール時に指定したセットアップ識別子を指定してください。標準セットアップを指定してインストールを行った場合は，セットアップ識別子を省略してください。

注意事項

空白文字に対応するために，バッチファイル本文中の「 " 」（ダブルクォーテーション）は，必ず指定してください。

参考

Windowsファイアウォールの［例外］タブを参照すると，HiRDBサーバのプログラムが登録されていることが確認できます。

≪簡易セットアップツール使用時の注意事項≫

簡易セットアップツールを使用してHiRDB/シングルサーバの環境設定をする場合は，次のように作業してください。

前述の手順に従って，HiRDBクライアントから接続要求を受け付けるプロセスのポート番号，又はプログラム名をWindowsファイアウォールの例外リストに登録します。

HiRDB/シングルサーバを構築するマシンで簡易セットアップツールを実行します。

簡易セットアップツールのホスト選択画面でホスト名にループバックアドレスを指定します。

簡易セットアップツールの詳細定義画面で次の指定をします。

・pd_rpc_bind_loopback_addressオペランドにSを指定する

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

　・pd_service_portオペランド

　・pd_scd_portオペランド

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

このように作業しない場合，HiRDBサーバのプログラムがWindowsファイアウォールによってブロックされるため，簡易セットアップツールを実行してもHiRDBを開始できません。

2.6.3　リモートシェル実行時に使用するポート番号を例外リストに登録する

リモートシェル実行時に使用するポート番号を例外リストに登録します。なお，登録はHiRDBクライアントを停止した状態で行ってください。

(1)　前提条件

次に示す条件を一つでも満たす場合は，(2)で説明する作業を行ってください。該当しない場合は，ここで説明する作業は必要ありません。「UAPを例外リストに登録する」にお進みください。

HiRDB/パラレルサーバの場合

IPアドレスを引き継がない系切り替え機能を使用する場合

(2)　登録方法

登録手順を次に示します。

手順

コントロールパネルからWindowsファイアウォールを起動します。

［例外］タブの［ファイルとプリンタの共有］を選択し，［編集］ボタンをクリックします。

［TCP 445］のチェックボックスをチェックし，［スコープの変更］ボタンをクリックします。

［スコープの変更］で，［ユーザーのネットワーク（サブネット）のみ］又は［カスタムの一覧］で関連するPCを設定します。

さらに，ドメインに属していないサーバマシンでHiRDB/パラレルサーバを構成している場合は，HiRDB運用ディレクトリを次に示す手順で共有化します。

手順

エクスプローラでHiRDB運用ディレクトリを右クリックし，［共有とセキュリティ］を選択します。

［ネットワーク上での共有とセキュリティ］の［ネットワーク上でこのフォルダを共有する］及び［ネットワークユーザによるファイルの変更を許可する］のチェックボックスをチェックします。

2.6.4　UAPを例外リストに登録する

UAPを例外リストに登録する方法は二つあります。どちらかの方法で例外リストに登録してください。

ポート番号を例外リストに登録する方法

クライアント環境定義のPDCLTRCVPORTオペランドに指定したポート番号（HiRDBサーバとHiRDBクライアントが通信を行う場合に使用する受信ポート番号）をすべて例外リストに登録します。

UAPの実行ファイルを例外リストに登録する方法

コントロールパネルからWindowsファイアウォールを起動して，［例外］タブを選択し，［プログラムの追加］からUAPの実行ファイルをすべて登録してください。

2.6.5　例外リストへの登録が不要になるケース

HiRDB/シングルサーバで，HiRDBサーバとHiRDBクライアントが同一マシン上にある場合，次に示す設定を行うとWindowsファイアウォールの例外リストへの登録が不要になります。

pdunitオペランドの-xオプションにループバックアドレス（127.0.0.1）を指定する

pd_rpc_bind_loopback_addressオペランドにYを指定する

クライアント環境定義のPDHOSTオペランドにループバックアドレスを指定する

クライアント環境定義のPDCLTBINDLOOPBACKADDRオペランドにYESを指定する

簡易セットアップツール使用時の注意事項

簡易セットアップツールを使用してHiRDB/シングルサーバの環境設定をする場合は，次のように作業してください。

HiRDB/シングルサーバを構築するマシンで簡易セットアップツールを実行する

簡易セットアップツールの開始画面でホスト名にループバックアドレスを指定する

簡易セットアップツールの詳細定義画面でpd_rpc_bind_loopback_addressオペランドにYを指定する

このように作業しない場合，HiRDBサーバのプログラムがWindowsファイアウォールによってブロックされるため，簡易セットアップツールを実行してもHiRDBを開始できません。

2.7　Windowsファイアウォールの例外リストからの削除

HiRDBをアンインストールする場合，Windowsファイアウォールの例外リストに登録したHiRDBが使用するポート番号やプログラムを削除する必要があります。ここでは，その削除方法について説明します。

注意事項

アンインストールを行う前に，HiRDBが使用するポート番号やプログラムを例外リストから削除してください。アンインストールを行った後では正しく削除できません。削除する前にアンインストールしてしまった場合は，HiRDBを再度インストールし，その後に例外リストから削除してください。

2.7.1　HiRDBサーバのプログラムを例外リストから削除する

HiRDBサーバのプログラムを例外リストから削除します。なお，削除はHiRDBサーバを停止した状態で行ってください。

(1)　前提条件

削除方法は，HiRDBサーバのプログラムを例外リストに登録したときの登録方法によって異なります。登録方法については，「HiRDBサーバのプログラムを例外リストに登録する」を参照してください。

登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定しなかった場合

登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定しなかった場合は，「登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定しなかった場合」で説明する作業を行ってください。

登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定した場合

登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定した場合は，「登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定した場合」で説明する作業を行ってください。

HiRDBのインストール時に，［Windowsファイアウォールへの登録］画面でHiRDBサーバのプログラムを例外リストに登録した場合は，(2)で説明する作業は必要ありません。「リモートシェル実行時に使用するポート番号を例外リストから削除する」にお進みください。

参考

インストール時にHiRDBサーバのプログラムを例外リストに登録した場合は，HiRDBをアンインストールするときに，例外リストからHiRDBサーバのプログラムが自動的に削除されます。

(2)　削除方法

(a)　登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定しなかった場合

HiRDBコマンドプロンプトを起動し，次に示すバッチファイルを実行してください。

%PDDIR%¥BIN¥pddelfw.bat

このバッチファイルを実行すると，Windowsファイアウォールの例外リストからHiRDBサーバのプログラムが削除されます。

また，pddelfw.batコマンドを実行して削除する方法もあります。pddelfw.batコマンドについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

(b)　登録対象をHiRDBクライアントから接続要求を受け付けるプロセスに限定した場合

HiRDBクライアントから接続要求を受け付けるプロセス（pdrdmd及びpdscdd）のポート番号，又はプログラム名（.exeファイル）をWindowsファイアウォールの例外リストから削除してください。それぞれの手順を次に示します。

ポート番号を削除する場合

次のバッチファイルを作成します。

HiRDBのポート番号とスケジューラプロセスのポート番号には，Windowsファイアウォールの例外リストに登録したポート番号をそれぞれ指定してください。

echo on
netsh firewall delete portopening protocol = TCP port = HiRDBのポート番号※1
netsh firewall delete portopening protocol = TCP port = スケジューラプロセスのポート番号※2
netsh firewall delete portopening protocol = TCP port = スケジューラプロセスの暗号化通信接続用のポート番号※3

HiRDBコマンドプロンプトを起動して，作成したバッチファイルを実行します。

注※1

HiRDBのポート番号は，次のどちらかのシステム定義で指定した値です。

pd_name_portオペランド

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

注※2

スケジューラプロセスのポート番号は，次のどれかのシステム定義で指定した値です。

pd_service_portオペランド

pd_scd_portオペランド

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

注※3

スケジューラプロセスの暗号化通信接続用のポート番号は，次のシステム定義で指定した値です。

pd_crypto_service_portオペランド

プログラム名を削除する場合

次のバッチファイルを作成します。

echo on
netsh firewall delete allowedprogram "%PDDIR%¥lib¥servers¥pdrdmd.exe"
netsh firewall delete allowedprogram "%PDDIR%¥lib¥servers¥pdscdd.exe"

HiRDBコマンドプロンプトを起動して，作成したバッチファイルを実行します。

注意事項

空白文字に対応するために，バッチファイル本文中の「 " 」（ダブルクォーテーション）は，必ず指定してください。

2.7.2　リモートシェル実行時に使用するポート番号を例外リストから削除する

リモートシェル実行時に使用するポート番号を例外リストから削除します。

(1)　前提条件

リモートシェル実行時に使用するポート番号を「リモートシェル実行時に使用するポート番号を例外リストに登録する」の説明に従って例外リストに登録した場合に，(2)で説明する作業を行ってください。該当しない場合は，ここで説明する作業は必要ありません。「UAPを例外リストから削除する」にお進みください。

(2)　削除方法

削除手順を次に示します。

手順

コントロールパネルからWindowsファイアウォールを起動します。

［例外］タブの［ファイルとプリンタの共有］を選択し，［編集］ボタンをクリックします。

［TCP 445］のチェックボックスをオフにします。

参考

この設定を行うとHiRDB以外のプログラムで支障が発生する場合は，この設定を行う必要はありません。

2.7.3　UAPを例外リストから削除する

UAPを例外リストから削除します。

(1)　前提条件

UAPを「UAPを例外リストに登録する」の説明に従って例外リストに登録した場合に，(2)で説明する作業を行ってください。該当しない場合は，ここで説明する作業は必要ありません。

(2)　削除方法

削除方法を次に示します。

ポート番号を例外リストに登録した場合

クライアント環境定義のPDCLTRCVPORTオペランドに指定したポート番号（HiRDBサーバとHiRDBクライアントが通信を行う場合に使用する受信ポート番号）をすべて例外リストから削除します。

UAPの実行ファイルを例外リストに登録した場合

コントロールパネルからWindowsファイアウォールを起動して，［例外］タブを選択します。［プログラムおよびサービス］に登録したUAPの実行ファイルを選択し，削除してください。

参考

HiRDB以外のプログラムがこれらのポート番号又はUAPを使用する場合は，例外リストから削除する必要はありません。

2.8　ファイルセキュリティ強化機能

ファイルセキュリティ強化機能とは，HiRDBが使用・作成するディレクトリ・ファイルなどのOS資源に対してアクセス権を設定する機能です。

ファイルセキュリティ強化機能を有効にすると，次に示す設定ができるようになります。

HiRDBがファイルやディレクトリを作成する際，アクセス権を上位ディレクトリから継承するようにします。

HiRDB運用ディレクトリ下のファイルに対するアクセスを，HiRDB管理者及びHiRDBグループだけに許可するように設定します。

HiRDBサービスのログオンアカウントとしてHiRDB管理者を自動的に設定し，必要なユーザ権利を付与※します。

なお，ファイルセキュリティ強化機能を使用しない場合，HiRDBが作成するファイル及びディレクトリのアクセス権は，Everyoneフルコントロールになります。

注※

付与するユーザ権利については，「HiRDB管理者の登録」を参照してください。

2.8.1　適用基準

HiRDBやHiRDBが作成するファイルに対する操作を，HiRDB管理者やHiRDBグループに登録しているユーザに限定し，システムのセキュリティを強化したい場合に有効にします。

2.8.2　適用方法

ファイルセキュリティ強化機能を適用する方法を次に示します。

インストール時に，次に示す手順でファイルセキュリティ強化機能を有効にします。

［セキュリティオプションの設定-1］画面で，「ファイルセキュリティ強化機能を使用する」を選択します。

［セキュリティオプションの設定-2］画面で，HiRDB管理者及びHiRDBグループを指定します。

インストール後に有効／無効を変更することもできます。pdsetaclコマンドを使用して変更します。pdsetaclコマンドの使用方法は，マニュアル「HiRDB コマンドリファレンス」を参照してください。

HiRDBファイルシステム領域を作成するディレクトリや，ワークファイル出力先ディレクトリを運用ディレクトリ以外の場所に作成する場合，各ディレクトリに対して，運用ディレクトリと同等のアクセス権を設定します。設定はpdsetaclコマンドを使用します。pdsetaclコマンドの使用方法は，マニュアル「HiRDB コマンドリファレンス」を参照してください。

2.8.3　設定するアクセス権

この機能を有効にした場合の，HiRDBが作成するファイル及びディレクトリのアクセス権を次の表に示します。

この機能では，表に示したユーザ，及びグループに対してだけ，アクセス権を設定します。

表2‒8　HiRDBが作成するファイル及びディレクトリのアクセス権

項番 | アクセス権種別 | アクセス権設定有無
HiRDB運用ディレクトリ（%PDDIR%）※1 | %PDDIR%¥tmp及びpd_tmp_directory※2
HiRDB管理者 | Administratorsグループ | HiRDBグループ | 作成者（CREATOR OWNER） | HiRDB管理者 | Administratorsグループ | HiRDBグループ
1 | フルコントロール | ○ | ○ | − | ○ | ○ | ○ | ○
2 | フォルダのスキャン／ファイルの実行 | ○ | ○ | ○ | ○ | ○ | ○ | ○
3 | フォルダの一覧／データの読み取り | ○ | ○ | ○ | ○ | ○ | ○ | ○
4 | 属性の読み取り | ○ | ○ | ○ | ○ | ○ | ○ | ○
5 | 拡張属性の読み取り | ○ | ○ | ○ | ○ | ○ | ○ | ○
6 | ファイルの作成／データの書き込み | ○ | ○ | ○ | ○ | ○ | ○ | ○
7 | フォルダの作成／データの追加 | ○ | ○ | ○ | ○ | ○ | ○ | ○
8 | 属性の書き込み | ○ | ○ | ○ | ○ | ○ | ○ | ○
9 | 拡張属性の書き込み | ○ | ○ | ○ | ○ | ○ | ○ | ○
10 | サブフォルダとファイルの削除 | ○ | ○ | − | ○ | ○ | ○ | ○
11 | 削除 | ○ | ○ | − | ○ | ○ | ○ | ○
12 | アクセス許可の読み取り | ○ | ○ | ○ | ○ | ○ | ○ | ○
13 | アクセス許可の変更 | ○ | ○ | − | ○ | ○ | ○ | ○
14 | 所有権の取得 | ○ | ○ | − | ○ | ○ | ○ | ○

（凡例）

○：権限を付与します。

−：権限を付与しません。

注※1

%PDDIR%¥BIN¥PDSEVMSG.DLLファイルだけ，%PDDIR%に設定するアクセス権に加えて，LOCAL SERVICEアカウントに対して次の項目を設定します。

・フォルダの一覧／データの読み取り（項番3）

・属性の読み取り（項番4）

・拡張属性の読み取り（項番5）

・アクセス許可の読み取り（項番12）

注※2

pd_tmp_directoryオペランドにHiRDB運用ディレクトリ，又はそのサブディレクトリが指定された場合，HiRDB運用ディレクトリのセキュリティ設定よりも低い設定となってしまうため，%PDDIR%¥tmpのアクセス権を付与しません。

2.8.4　注意事項

HiRDBのファイルを作成するディレクトリは，HiRDB専用のディレクトリとしてください。該当するディレクトリ内にHiRDBとは無関係のファイルが存在した場合，そのファイルを使用するプログラムからアクセスできなくなるおそれがあります。

アクセス権やHiRDB管理者，HiRDBグループを変更する場合は，必ずpdsetaclコマンドで変更してください。pdsetaclコマンドを使用しないでこれらの変更をした場合は，HiRDBの動作を保証できません。

HiRDB管理者以外のユーザがコマンドを実行する場合，マニュアル「HiRDB コマンドリファレンス」の「一般ユーザによるコマンド実行時の注意事項」の内容を参照してください。

2.8.5　関連プログラムプロダクトに関する注意事項

ファイルセキュリティ強化機能を有効にする場合，HiRDBのディレクトリ，ファイルにアクセスする関連PPについて，次に示す条件を満たす必要があります。

関連プログラムプロダクトのコマンド実行は，HiRDB管理者，HiRDBグループ又は管理者グループ（Administrators）に属するユーザで行ってください。

関連プログラムプロダクトのコマンドには，HiRDB管理者，HiRDBグループ又は管理者グループ（Administrators）に対する読み込み，実行権限を与えてください。

関連プログラムプロダクトのWindowsサービスがHiRDBのディレクトリ，ファイルにアクセスする場合，サービスアカウントにHiRDB管理者，HiRDBグループ又は管理者グループ（Administrators）に属するユーザを設定してください。

3　簡易セットアップツールによる環境設定

この章では，簡易セットアップツールを使用したHiRDBの環境設定方法について説明します。

3.1　簡易セットアップツールの概要

ここでは，簡易セットアップツールを使ってできることと，簡易セットアップツールの稼働環境について説明します。

3.1.1　簡易セットアップツールとは

簡易セットアップツールとは，HiRDBの環境構築を支援するツールで，GUIで次に示す作業を実施できます。

環境設定

簡易セットアップツールでは，次のどれかを選択して環境設定ができます。

標準セットアップ

環境設定をするマシンのホスト名，HiRDB運用ディレクトリ，及びセットアップディレクトリだけを指定すれば容易に環境設定ができます。

ウィザードセットアップ

システム構成，ユニット構成，及びシステムログの運用方法を，対話形式で設定できます。

カスタムセットアップ

HiRDBの規模，HiRDB識別子，ポート番号，ユニット識別子，システムファイル及びRDエリアの作成ディレクトリなど，より詳細な設定ができます。

定義の更新

作成済みの%PDDIR%¥conf下のシステム定義を更新します。

定義情報の保存と読み込み

簡易セットアップツールで作成した詳細定義情報を単一ファイル形式，又はディレクトリ形式で保存できます。また，保存した詳細定義情報を読み込むことができます。

注意事項

簡易セットアップツールで環境設定をすると，デフォルトではRDエリアの自動増分機能，及びシステムログファイルの自動拡張機能が適用されます。RDエリアの自動増分，及びシステムログファイルの自動拡張については，マニュアル「HiRDB システム運用ガイド」を参照してください。

なお，これらの機能を使用しない場合は，カスタムセットアップで適用を解除してください。解除する方法を次に示します。

≪RDエリアの自動増分機能の適用を解除する場合≫

［HiRDBファイルシステム領域編集］ダイアログボックスで「領域を自動増分する」のチェックを外してください。

≪システムログファイルの自動拡張機能の適用を解除する場合≫

［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウで各サーバ定義を表示し，次のどちらかの設定をしてください。

・pd_log_auto_expand_sizeオペランドを削除する

・pd_log_auto_expand_sizeオペランドの1回当たりに拡張するサイズに0を指定する

3.1.2　環境設定

簡易セットアップツールで環境設定をすると，次のことができます。

HiRDBシステム定義の作成

HiRDBファイルシステム領域の作成

システムファイルの作成

RDエリアの作成

HiRDBの開始

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

サンプルデータベースの作成

簡易セットアップツールによる環境設定手順を次の図に示します。

図3‒1　簡易セットアップツールによる環境設定手順

[picture]

注※1

手順は，「簡易セットアップツールの起動」を参照してください。

注※2

手順は，「標準セットアップ」を参照してください。

注※3

手順は，「ウィザードセットアップ」を参照してください。

注※4

手順は，「カスタムセットアップ（詳細定義）」を参照してください。

注※5

手順は，「カスタムセットアップ」を参照してください。

簡易セットアップツールを使用して環境設定をした場合に作成されるファイルを次に示します。

システム定義ファイル

バッチファイル及び制御文

サンプルデータベース関連ファイル

ログファイル

バックアップファイル

HiRDBクライアント環境定義ファイル

それぞれのファイルについて説明します。

(1)　システム定義ファイル

%PDCONFPATH%下に作成されます。作成されるシステム定義ファイル名を次に示します。

定義 | ファイル名
システム共通定義 | pdsys
ユニット定義 | pdutsys
サーバ共通定義 | pdsvrc
シングルサーバ定義※１ | sds01※３
ディクショナリサーバ定義※２ | dic1※３
フロントエンドサーバ定義※２ | fes1※３
バックエンドサーバ定義※２ | bes1，bes2※３

注※１　

HiRDB/シングルサーバの場合に作成されます。

注※２　

HiRDB/パラレルサーバの場合に作成されます。

注※３　

サーバ名を変更することでファイル名は変更できます。サーバ名の変更については，「サーバ名の設定」を参照してください。また，フロントエンドサーバ定義及びバックエンドサーバ定義はユーザが指定したサーバと同数のファイルを作成します。

注意事項

HiRDBシステム定義ファイルのパーミッションは，ファイルの所有者（HiRDB管理者）にだけ，読み込み権限及び書き込み権限を持たせるように設定，維持するようにしてください。

(2)　バッチファイル及び制御文

%PDCONFPATH%下に作成されます。作成されるバッチファイル及び制御文のファイル名を次に示します。

ファイル名 | 種別 | 使用するコマンド，又はユティリティ | 概要
fmkfile.bat | バッチファイル | pdfmkfsコマンド | HiRDBファイルシステム領域の初期設定
fmkfs.bat | バッチファイル | pdfmkfsコマンド | HiRDBファイルシステム領域の初期設定
mkinit | 制御文 | create rdarea文 | RDエリアの初期設定
initdb.bat | バッチファイル | データベース初期設定ユティリティ（pdinit） | RDエリアの初期設定
sysfint.bat | バッチファイル | pdstsinitコマンド pdloginitコマンド | ステータスファイル，ログ関係ファイルの初期設定

(3)　サンプルデータベース関連ファイル

HiRDBのサンプルデータベースを作成するためのバッチファイル及びデータファイルは，環境設定の処理の中で自動的に%PDDIR%¥pdistup¥sample下に作成されます。作成されるファイルを次に示します。

ファイル名 | 種別 | 使用するユティリティ，又はSQL文 | 概要
PDI_SampleDef.bat | バッチファイル | データベース定義ユティリティ（pddef） | スキーマの定義
PDI_SampleLod.bat | バッチファイル | データベース作成ユティリティ（pdload） | データのロード
PDI_CreateUser | DDL | 定義系SQLのGRANT文 | ユーザの定義
PDI_CreateTable | DDL | 定義系SQLのCREATE TABLE文 | 表の定義
PDI_Custom.csv | CSV | なし | 表CUSTOM用のデータ
PDI_Goods.csv | CSV | なし | 表GOODS用のデータ
PDI_Stock.csv | CSV | なし | 表STOCK用のデータ
PDI_Vendor.csv | CSV | なし | 表VENDOR用のデータ

簡易セットアップツールで作成するサンプルデータベースについては，「簡易セットアップツールで作成するサンプルデータベース」を参照してください。

(4)　ログファイル

簡易セットアップツールは，HiRDB起動処理中のエラーを少なくするために起動処理（pdstartコマンドの実行）前に定義をチェック（pdconfchkコマンドの実行）します。チェック結果がエラーとなった場合は，セットアップエラー（HiRDBの開始エラー）となり，チェック結果をログファイルに出力します。また，ログファイルには簡易セットアップツールの実行履歴も出力します。

ログファイル名は，%PDDIR%¥pdistup¥pdi_log.txtです。

セットアップ処理実行でエラーが発生した場合にはエラー情報がログファイルに出力されますが，出力されるログは中断の原因となった最終的なエラーです。イベントビューアにもエラー情報が出力されている可能性があるため，ログ情報とともにイベントビューアの内容を参照することをお勧めします。

(5)　バックアップファイル

バックアップファイルを作成するディレクトリに同じ名称のファイルがある場合，既存ファイルのバックアップを作成します。バックアップファイルは，ファイル名に「_001〜999」を付加します。ただし，_001〜999のすべてが既に使用されている場合はエラーになります。

(6)　HiRDBクライアント環境定義ファイル

HiRDBクライアント環境定義ファイル（HiRDB.ini）は簡易セットアップツール実行環境のWindowsシステムディレクトリに作成されます。

作成されたHiRDBクライアント環境定義ファイルには，次の表に示す内容が設定されます。必要に応じて，ユーザ環境に合わせたクライアント環境定義を追加してください。また，簡易セットアップツールの実行環境以外のマシンに環境設定を行う場合は，このファイルを参考にしてクライアント環境定義をしてください。

クライアント環境定義については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

表3‒1　簡易セットアップツールが設定するクライアント環境定義

項番 | クライアント環境定義 | 設定条件 | 設定値
1 | PDHOST | 必ず設定されます。 | HiRDBの環境を設定する設定先のホスト名称
2 | PDNAMEPORT | pd_name_portオペランドの指定値
3 | PDUSER | "USER1"/"USER1"
4 | PDSERVICEPORT | 次のすべての条件を満たしている場合に設定されます。 HiRDB/シングルサーバの環境設定をしている場合 pdunitオペランドの-sオプションを指定している場合 | pdunitオペランドの-sオプションの指定値
5 | PDSERVICEGRP | pdstartオペランドの-sオプションの指定値
6 | PDSRVTYPE | PC

注意事項

クライアント環境定義ファイルがWindowsシステムディレクトリ下に既に存在する場合，簡易セットアップツールはこれらのクライアント環境変数の値を更新してファイルを上書きします。

簡易セットアップツールはHiRDB/シングルサーバの場合にだけ高速接続の設定をします。HiRDB/パラレルサーバで高速接続をする場合は，そのためのクライアント環境定義を追加してください。高速接続機能を使用するための設定については，マニュアル「HiRDB UAP開発ガイド」のクライアント環境変数PDSERVICEPORTの説明を参照してください。

3.1.3　定義の更新

簡易セットアップツールによるHiRDBシステム定義の更新手順を次の図に示します。

図3‒2　簡易セットアップツールによるHiRDBシステム定義の更新手順

[picture]

注※1

手順は，「簡易セットアップツールの起動」を参照してください。

注※2

手順は，「定義の更新」を参照してください。

3.1.4　簡易セットアップツールの稼働環境

Windows版HiRDBの環境設定をする場合は，HiRDBをインストールしたWindowsマシンで簡易セットアップツールを実行します。

注意事項

古いバージョンの簡易セットアップツールを使用しないでください。操作対象のHiRDBと同じバージョンの簡易セットアップツールを使用してください。

マルチHiRDB環境を構築する場合，二つのHiRDBを簡易セットアップツールで同時に環境設定できません。一つのHiRDBを簡易セットアップツールで環境設定した後に，もう一つのHiRDBを簡易セットアップツールで環境設定してください。

(1)　Windows版HiRDBに対して簡易セットアップツールを使用する場合

HiRDB/シングルサーバの環境設定を行う場合は，HiRDB/シングルサーバをインストールしたサーバマシンで簡易セットアップツールを実行してください。HiRDB/パラレルサーバの環境設定を行う場合は，HiRDB/パラレルサーバを構成するサーバマシンの一つで簡易セットアップツールを実行してください。

簡易セットアップツールを使用したWindows版HiRDBの環境設定の概要を次の図に示します。

図3‒3　簡易セットアップツールを使用したWindows版HiRDBの環境設定の概要（HiRDB/パラレルサーバの場合）

[picture]

〔説明〕

サーバマシン1で簡易セットアップツールを実行し，サーバマシン1，サーバマシン2，及びサーバマシン3のHiRDB/パラレルサーバの環境設定を行います。

図3‒4　簡易セットアップツールを使用したWindows版HiRDBの環境設定の概要（HiRDB/シングルサーバで系切り替え機能を使用する場合）

[picture]

〔説明〕

サーバマシン1で簡易セットアップツールを実行し，サーバマシン1を現用系に，サーバマシン2を予備系に指定してHiRDB/シングルサーバの環境設定を行います。

(2)　簡易セットアップツールを実行するマシン環境

簡易セットアップツールを実行するマシンの前提OSと，Windows版HiRDBのセットアップ可否を次の表に示します。

表3‒2　簡易セットアップツールを実行するマシンの前提OSと，Windows版HiRDBのセットアップ可否

プラットフォーム | 前提OS | Windows版HiRDBのセットアップ
Windows(x86) | Windows Server 2008 | ○
Windows 7 | ○
Windows 8 | ○
Windows 10 | ○
Windows (x64)※ | Windows Server 2008 | ○
Windows Server 2012 | ○
Windows Server 2016 | ○
Windows 7 | ○
Windows 8 | ○
Windows 10 | ○

（凡例）

○：セットアップできます。

注※

32ビットエミュレーションモードで動作します。

3.1.5　簡易セットアップツールを実行する前に確認すること

簡易セットアップツールを実行する前に次に示すことを確認してください。

(1)　Windows版HiRDBに対して簡易セットアップツールを使用する場合

次に示すことを確認してください。

操作対象のHiRDBのサービスが起動中であるかを確認してください。起動中でない場合はサービスを起動してください。

簡易セットアップツールを実行するサーバマシンと簡易セットアップツールを適用するサーバマシンの，HiRDBサービスのユーザ名とパスワードが一致しているか確認してください。

簡易セットアップツールを使用してHiRDB/シングルサーバの環境を構築する場合，pdntenvコマンド（-roオプションにonを指定）でリモート系コマンドを使用する設定を行ってください。その後，HiRDBサービスを再起動してください。

簡易セットアップツールを使用して環境構築を行うサーバマシンのSERVICESファイルに，サービス名pdrshsrvとポート番号49999を設定してください。セットアップ識別子付きでインストールした場合は，サービス名をpdrshsrv[識別子]としてください。ポート番号は，簡易セットアップツール以外のアプリケーションと重複しないようにしてください。SERVICESファイルの設定例については，「OS環境ファイルの設定」を参照してください。

(2)　HiRDB/パラレルサーバに対して簡易セットアップツールを使用する場合

次に示すことを確認してください。

ネットワーク形態は，単一ドメインの環境をお勧めします。

正常開始以外の開始モードで開始したサーバが一つ以上ある場合，HiRDBを一度正常終了してください。

(3)　Windowsの設定について

Windowsの画面の解像度が，標準の96dpiであることを確認してください。

3.2　簡易セットアップツールの起動

3.2.1　簡易セットアップツールを実行するユーザ

簡易セットアップツールはAdministrators権限を持っているユーザが実行できます。ただし，環境設定をするHiRDBのホスト名を指定するときにOSに登録しているHiRDB管理者用のユーザ名及びパスワードを指定してください。HiRDB管理者のデフォルトは，HiRDBをインストールしたユーザになります。

3.2.2　簡易セットアップツールの起動手順

簡易セットアップツールの起動方法には次の二つがあります。

HiRDB/シングルサーバの場合，［スタート］−［プログラム］−［HiRDBSingleServer］−［簡易セットアップツール］を選択してください。

HiRDB/パラレルサーバの場合，［スタート］−［プログラム］−［HiRDBParallelServer］−［簡易セットアップツール］を選択してください。

%PDDIR%¥pdistup¥bin¥pdistup.exeを実行してください。

簡易セットアップツールを起動すると，［HiRDBセットアップツール−開始］ウィンドウが表示されます。

この章では，HiRDB/パラレルサーバの場合のウィンドウで説明します。

注意事項

簡易セットアップツールは複数起動できません。

異なるマシンでそれぞれ簡易セットアップツールを起動し，同じホストに対して環境設定を実行しないでください。

Windows Terminal Serviceを使用してセットアップツールを実行する場合，複数のWindows Terminal Serviceのクライアントから同時にセットアップツールを実行しないでください。

簡易セットアップツールが標準ホスト名の取得に失敗した場合，［ローカルマシン名入力］画面が表示されます。この場合，自マシン（簡易セットアップツールを実行するマシン）のホスト名を指定して，［OK］ボタンをクリックしてください。簡易セットアップツールの起動処理が再度行われます。

3.3　標準セットアップ

簡易セットアップツールの初期値で環境設定する場合は，［HiRDBセットアップツール−開始］ウィンドウから直接開始できます。環境設定をするマシンのホスト名，運用ディレクトリ，及びセットアップディレクトリの指定だけで，容易にHiRDB環境を構築できます。

3.3.1　標準セットアップの場合の環境設定手順

［HiRDBセットアップツール−開始］ウィンドウで必要な項目を入力します。

標準セットアップの場合は，次に示す値で環境設定されます。

HiRDBの規模：小規模

システムID：HRD1

ポート番号：22200

ユニットID：UNT1

サンプルデータベースの作成：作成する

標準セットアップの環境設定手順を次に示します。

環境設定をするマシンのホスト名を指定します。

［ホスト選択］ラベルには，［hostsファイルからホスト名を選択］ダイアログボックスで指定したホスト名がホスト名，FQDN，又はIPアドレスの形式で表示されます。

初期値はHiRDBインストールディレクトリです。環境設定をするマシンのホスト名を変更する場合，［hostsファイルからホスト名を選択］をクリックして，［hostsファイルからホスト名を選択］ダイアログボックスで，ホスト名，Windowsディレクトリ，ユーザ名，及びパスワードを指定します。

それぞれの項目について説明します。

項目名 | 説明
ホスト名 | 環境設定をするマシンのホスト名を指定します。［hostsファイルのホスト名一覧］リストから選択するか，又は直接入力してください。入力できる形式は，ホスト名，FQDN，又はIPアドレスです。また，簡易セットアップツールを実行しているマシンの場合は，ループバックアドレスも指定できます。 なお，ホスト名を変更した場合，［ユーザ名］及び［パスワード］の内容はリセットされるため，入力し直してください。
Windowsディレクトリ | Windowsインストールディレクトリをフルパスで指定します。 セパレータは¥と/のどちらも使用できますが，混在して指定できません。また，「ドライブ名:¥」と「/ドライブ名」のどちらも指定できます。
ユーザ名 | 環境設定をするサーバマシンのHiRDB管理者用のユーザ名を指定します。ドメインユーザの場合はドメインを付けて指定する必要はありません。
パスワード | ［ユーザ名］に指定したユーザのパスワードを指定します。

なお，簡易セットアップツールで環境設定をすると，HiRDBに次に示す認可識別子を登録してDBA権限を付与します。

ユーザ：root

パスワード：root

また，この設定のリモートホスト接続処理で，セットアップ先にワーク領域を作成します。ワーク領域には，セットアップ先に正常に接続しているかを確認するためのバッチファイルや，バッチファイルの実行結果を保存したファイルを格納します。ワーク領域は，次の場所に作成されます。

%windir%¥Temp¥[ログインユーザ名]

［運用ディレクトリ］テキストボックスでHiRDB運用ディレクトリを指定します。セパレータは¥と/のどちらも使用できますが，混在して指定できません。また，「ドライブ名:¥」と「/ドライブ名」のどちらも指定できます。初期値はHiRDBインストールディレクトリです※1。Windowsの場合，HiRDB運用ディレクトリとは，HiRDBのインストールディレクトリのことです。HiRDB運用ディレクトリの指定を省略したり，存在しないHiRDB運用ディレクトリを指定すると，エラーメッセージが表示されます。

［...］をクリックして，［フォルダの参照］ダイアログボックスからディレクトリを選択することもできます。

［フォルダの参照］ダイアログボックスに表示される内容は，環境設定をするホストの内容です。表示される項目を次に示します。

未フォーマット状態のパーティション（ただし，ドライブ文字割り当て済み）

ドライブ

ディレクトリ

ファイル※2

注※1

%PDDIR%¥pdistup¥bin下から簡易セットアップツールを起動しなかった場合は，空になります。

注※2

HiRDBファイルシステム領域を編集する場合だけ表示されます。

［セットアップディレクトリ］テキストボックスでセットアップディレクトリ（システムファイル及びRDエリアを作成するディレクトリ）を指定します。初期値は，%PDDIR%¥areaです※。なお，Windowsのショートパス名（例えば，C:¥PROGRA~1など）の指定はできません。

HiRDB運用ディレクトリの指定と同様に，［...］をクリックして，［フォルダの参照］ダイアログボックスからディレクトリを選択することもできます。

注※

%PDDIR%¥pdistup¥bin下から簡易セットアップツールを起動しなかった場合は，空になります。

［標準セットアップ］をクリックすると，セットアップが開始されます。

3.3.2　標準セットアップで設定される環境

標準セットアップを実行すると設定される環境を次に示します。

標準セットアップを実行すると登録されるDBA権限を持つ認可識別子

認可識別子：root

パスワード：root

サンプルデータベースの作成

作成されます。

(1)　HiRDB/シングルサーバの場合

標準セットアップで作成されるシステム構成を次の図に示します。

図3‒5　標準セットアップで作成されるシステム構成（HiRDB/シングルサーバ）

[picture]

標準セットアップで作成されるHiRDBファイルシステム領域の構成を次の図に示します。HiRDBファイルシステム領域は，セットアップディレクトリ下に作成されます。

図3‒6　標準セットアップで作成されるHiRDBファイルシステム領域の構成（HiRDB/シングルサーバ）

[picture]

(2)　HiRDB/パラレルサーバの場合

標準セットアップで作成されるシステム構成を次の図に示します。

図3‒7　標準セットアップで作成されるシステム構成（HiRDB/パラレルサーバ）

[picture]

標準セットアップでは，簡単にHiRDBのシステムを構築するために，サーバマシンは1台だけという構成で環境設定します。HiRDB/パラレルサーバは，複数のサーバマシンで動作し，データの検索などの処理を並列に実行できるシステムのため，「HiRDB/パラレルサーバの環境設定をする場合」を参照して，カスタマイズしてください。

標準セットアップで作成されるHiRDBファイルシステム領域の構成を次の図に示します。HiRDBファイルシステム領域は，セットアップディレクトリ下に作成されます。

図3‒8　標準セットアップで作成されるHiRDBファイルシステム領域の構成（HiRDB/パラレルサーバ）

[picture]

3.3.3　簡易セットアップツールで作成するサンプルデータベース

次に示す場合にサンプルデータベースが作成されます。

標準セットアップを実行した場合

ウィザードセットアップを実行した場合※

カスタムセットアップで［サンプルデータベースの作成］を選択して実行した場合※

注※

詳細定義画面で系切り替え機能の設定を行った場合，サンプルデータベースは作成されません。

この場合，サンプルデータベースとして次に示す表が作成されます。

表名：

CUSTOM，GOODS，VENDOR，TAKEODR，STOCK，WAREHUS，SHIPMNT，SENDODR，LAYIN

このうち，CUSTOM，GOODS，VENDOR，及びSTOCK表には，サンプルのデータが格納されます。

また，このとき，HiRDBに認可識別子がUSER1（パスワードはUSER1）のユーザが登録され，簡易セットアップツールを実行したマシンのHiRDB.iniファイル中のPDUSERに，この認可識別子とパスワード（PDUSER=USER1/USER1）が自動的に設定されます。

3.4　ウィザードセットアップ

ウィザードセットアップでは，次に示す項目を対話形式で指定するだけで環境設定ができます。

システム構成

ユニット構成

システムログの運用方法

3.4.1　ウィザードセットアップの場合の環境設定手順

ウィザードセットアップの場合の環境設定手順を次に示します。

(1)　システム構成を設定します

［HiRDBセットアップツール−開始］ウィンドウで，［ウィザードセットアップ］を選択すると，［HiRDBセットアップツール−ウィザードセットアップ［システム構成］］ウィンドウが表示されます。

HiRDBのシステム構成を設定します。

このウィンドウで設定する項目について説明します。

項目名 | 説明
HiRDB識別子 | 環境設定をするHiRDBの識別子を指定します。 4文字で指定します。初期値は［HRD1］です。
ポート番号 | 環境設定をするHiRDBが使用するポート番号を指定します。 5001〜65535の範囲で指定します。初期値は22200です。
ユニット数 | HiRDBシステムで構築するユニット数を指定します。HiRDB/パラレルサーバの場合に指定できます。 1〜999の範囲で指定します。初期値は1です。
最大同時接続ユーザ数 | 最大同時接続ユーザ数を指定します。 1〜pd_max_usersオペランドの上限値の範囲で指定します。初期値は8です。 なお，最大同時接続ユーザ数を変更した場合は，HiRDBの規模が再設定されます。

HiRDBの規模

HiRDBの規模を，全ユニットで使用するディスク容量のサイズで指定します。

初期値〜9,999,999ギガバイトの範囲で指定します。初期値は，HiRDB/シングルサーバの場合は490メガバイト，HiRDB/パラレルサーバの場合は550メガバイトになります。

ユニット数，又は最大同時接続ユーザ数を変更した場合は，1サーバ当たりに必要なRDエリア容量×サーバ台数（デフォルトの構成として，1ユニット当たりフロントエンドサーバ1台，バックエンドサーバ2台を仮定），及びそのRDエリア容量に必要なシステムファイル容量を加算した値が再設定されます。

なお，HiRDB開始後の運用によっては，規模が拡大する場合があります。その場合の詳細については，「HiRDBファイルシステム領域を編集します」の注を参照してください。

RDエリア容量の割合 | HiRDBの規模で指定した容量のうち，RDエリアに使用する領域の割合を指定します。指定できる範囲，及び初期値は，HiRDBの規模によって異なります。

［次へ］をクリックすると，設定内容が保存され，HiRDB/シングルサーバの場合は［HiRDBセットアップツール−ウィザードセットアップ［システムログ運用方法］］ウィンドウ，HiRDB/パラレルサーバの場合は［HiRDBセットアップツール−ウィザードセットアップ［ユニット構成］］ウィンドウが表示されます。

なお，HiRDBの規模が十分な大きさでも，データベースの構成（サーバ台数や最大同時接続ユーザ数）によってRDエリア容量の割合が適切ではない場合は，次のとおり最適なRDエリア容量に自動調整されます。

RDエリアの容量が不足する場合は，最小RDエリア容量に自動調整します。

システムファイル容量が不足する場合は，最大RDエリア容量に自動調整します。

(2)　ユニット構成を設定します

HiRDB/パラレルサーバの場合に，［HiRDBセットアップツール−ウィザードセットアップ［システム構成］］ウィンドウで［次へ］をクリックすると，［HiRDBセットアップツール−ウィザードセットアップ［ユニット構成］］ウィンドウが表示されます。

HiRDB/パラレルサーバのユニット構成を設定します。［HiRDBセットアップツール−ウィザードセットアップ［システム構成］］ウィンドウで指定したユニット数分のユニット構成を設定します。

このウィンドウで設定する項目について説明します。

項目名 | 説明
ユニット識別子 | 設定するユニットの識別子を指定します。 4文字で指定します。初期値は［u001］です。［HiRDBセットアップツール−ウィザードセットアップ［システム構成］］ウィンドウでユニット数に2以上を指定した場合，二つ目のユニットの初期値は［u002］となります。
ホスト名 | ［マシン情報編集］ボタンで［マシン情報編集］ダイアログボックスを表示し，サーバマシンの情報を設定します。［マシン情報編集］ダイアログボックスについては，「マシン情報の編集」を参照してください。
フロントエンドサーバ | フロントエンドサーバを設置する場合にチェックします。チェックがない場合は，サーバ定義を作成しません。なお，台数の編集はできません。

バックエンドサーバ

バックエンドサーバを設置する場合にチェックします。チェックがない場合はサーバ定義を作成しません。また，ユニットに設置するバックエンドサーバの台数を指定します。

バックエンドサーバの台数は0〜34の範囲で指定します。初期値は2です。

＜注意事項＞

バックエンドサーバの台数を増やしたときは，次のことに注意してください。

簡易セットアップツールで指定できるすべてのユニットのバックエンドサーバの合計台数は，1,998台です。

リソース数に関連する環境変数の設定が必要になる場合があります。リソース数に関連する環境変数の見積もりについては，「リソース数に関連する環境変数の見積もり」を参照してください。

ユニット用ステータスファイルが不足することがあります。その場合は，［HiRDBセットアップツール−ウィザードセットアップ（システム構成）］ウィンドウでRDエリア容量の割合を調整するか，又は［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウでユニット用ステータスファイルの容量を再設定してください。

HiRDBファイルシステム領域の見積もり計算でエラーが発生する場合があります。この場合は，エラーメッセージを参照して対策してください。

［次へ］をクリックすると，設定内容を保存し，［HiRDBセットアップツール−ウィザードセットアップ［システムログ運用方法］］ウィンドウを表示します。

(3)　システムログファイルの運用方法を設定します

HiRDB/シングルサーバの場合は，［HiRDBセットアップツール−ウィザードセットアップ［システム構成］］ウィンドウで［次へ］をクリックすると，［HiRDBセットアップツール−ウィザードセットアップ［システムログ運用方法］］ウィンドウが表示されます。

HiRDB/パラレルサーバの場合は，［HiRDBセットアップツール−ウィザードセットアップ［ユニット構成］］ウィンドウで［次へ］をクリックすると，［HiRDBセットアップツール−ウィザードセットアップ［システムログ運用方法］］ウィンドウが表示されます。

システムログファイルの運用方法を設定します。

このウィンドウで設定する項目について説明します。

項目名 | 説明
ユニット選択 | 自動ログアンロードディレクトリを設定するユニットを選択します。
システムログの運用方法 | システムログの運用方法を選択します。初期値は［システムログをアンロードする運用］です。
自動ログアンロードディレクトリ | 自動ログアンロードディレクトリを設定します。初期値はユニット構成で設定したシステムファイル格納ディレクトリ名を表示します。 システムログの運用方法で［システムログをアンロードする運用］を選択した場合に指定できます。

［次へ］をクリックすると，設定内容が保存され，［HiRDBセットアップツール−ウィザードセットアップ［確認］］ウィンドウが表示されます。

(4)　設定内容を確認します

［HiRDBセットアップツール−ウィザードセットアップ［システムログ運用方法］］ウィンドウでシステムログファイルの運用方法の設定が完了すると［HiRDBセットアップツール−ウィザードセットアップ［確認］］ウィンドウが表示されます。

ウィザードセットアップでの設定内容，及びHiRDBファイルシステム領域の割り当て容量（システムファイル用とRDエリア用の容量）の計算結果を表示します。

HiRDBファイルシステム領域のシステムファイル用の容量は，ステータスファイルの容量見積もりの計算結果，及びシンクポイントダンプファイルの容量見積もりの計算結果を反映し，ユーザが指定したシステムファイル容量に収まるように割り当てられます。

［詳細定義］をクリックすると，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウが表示されます。カスタムセットアップ（詳細定義）では，ウィザードセットアップで指定した値を変更できます。カスタムセットアップ（詳細定義）については，「カスタムセットアップ（詳細定義）」を参照してください。

［セットアップ開始］をクリックすると，セットアップが開始されます。

3.5　カスタムセットアップ

カスタムセットアップでは，次に示す項目の指定だけで環境設定ができます。

HiRDBの規模

HiRDB識別子

ポート番号

ユニット識別子

システムファイル及びRDエリアの作成ディレクトリ

3.5.1　カスタムセットアップの場合の環境設定手順

カスタムセットアップの場合の環境設定手順を次に示します。

［HiRDBセットアップツール−開始］ウィンドウで［カスタムセットアップ］をクリックすると，［HiRDBセットアップツール−カスタム］ウィンドウが表示されます。

HiRDBの規模，HiRDB定義，セットアップディレクトリ，サンプルデータベースの作成有無を指定します。それぞれの項目について説明します。

項目名 | 説明

HiRDBの規模

HiRDBの規模を指定します。初期値は［小規模］です。

小規模

約500メガバイトのディスク容量を使用するHiRDB環境を作成します。

中規模

約1ギガバイトのディスク容量を使用するHiRDB環境を作成します。

大規模

約2ギガバイトのディスク容量を使用するHiRDB環境を作成します。

詳細定義画面で変更が行われると不活性になり，その後は編集できなくなります。また，定義情報の読み込みを実行すると不活性となり，その後は編集できなくなります。

HiRDB開始後の運用によっては，規模が拡大する場合があります。その場合の詳細については，「HiRDBファイルシステム領域を編集します」の注を参照してください。

HiRDB定義

環境設定をするHiRDBの識別子，使用するポート番号，ユニット識別子を指定します。

HiRDB識別子

４文字で指定します。初期値は［HRD1］です。

ポート番号

5001〜65535の範囲で指定します。初期値は22200です。

ユニット識別子

４文字で指定します。初期値は［unt1］です。

セットアップディレクトリ

システムファイルとRDエリアの格納先を分ける場合に指定します。初期値は［HiRDBセットアップツール−開始］ウィンドウの［セットアップディレクトリ］指定値です。

システムファイル格納先

システムファイルを作成するディレクトリを指定します。

RDエリア格納先

RDエリア用のファイルを作成するディレクトリを指定します。

なお，HiRDB/パラレルサーバの場合，ここで指定する格納先はシステムマネジャがあるサーバです。システムマネジャがあるサーバ以外のサーバの格納先を指定する場合は，［マシン情報編集］ダイアログボックスで指定してください。［マシン情報編集］ダイアログボックスについては，「マシン情報の編集」を参照してください。

サンプルデータベースの作成 | サンプルデータベースを作成するかどうかを指定します。

注意事項

ポート番号の指定で，次の場合はエラーメッセージが表示されます。

範囲外の値が指定された場合

指定したポート番号が別プログラムで使用されている場合

別プログラムで使用されているポート番号とは，%windir%¥system¥etc¥drivers¥servicesファイルに指定されているポート番号です。

ただし，HiRDBサーバ間での重複チェックはしません。

［詳細定義］をクリックすると，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウが表示されます。カスタムセットアップ（詳細定義）では，ここで指定した値を変更できます。カスタムセットアップ（詳細定義）については，「カスタムセットアップ（詳細定義）」を参照してください。

［セットアップ開始］をクリックすると，セットアップが開始されます。

3.6　カスタムセットアップ（詳細定義）

カスタムセットアップで詳細定義をすることによって，次の項目を設定できます。

サーバマシンの情報の定義

ユニット制御情報定義の編集

HiRDBファイルシステム領域の指定

RDエリアの指定

ユニット用ステータスファイルの指定

シングルサーバ定義，又は各サーバ定義の編集

サーバ用ステータスファイルの指定

システムログファイルの指定

シンクポイントダンプファイルの指定

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

系切り替え機能の設定

リソース所要量の計算

3.6.1　メニュー一覧

カスタムセットアップで詳細定義する場合，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウで指定します。また，ウィザードセットアップで環境設定をした後に，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウで，より詳細に環境設定を行うこともできます。ウィザードセットアップについては，「ウィザードセットアップ」を参照してください。

［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウを次の図に示します。また，このウィンドウのメニュー一覧を表「［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウのメニュー一覧」に示します。

図3‒9　［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウ

[picture]

表3‒3　［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウのメニュー一覧

メニュー | ドロップダウンメニュー | 説明
ファイル（F） | システム定義の更新（U）... | HiRDBのシステム定義を更新します。定義更新時だけ選択できます。 システム定義のチェックで問題ない場合だけ更新できます。チェックで問題がある場合は選択できません。
システム定義のチェック（C）... | システム定義の内容をチェックします（pdconfchkコマンドの実行）。
システム定義のチェック結果（R）... | 前回のシステム定義のチェック結果を表示します。システム定義が一度もチェックされていない場合は選択できません。
詳細定義情報の読み込み（L） | ローカルディスク上に単一ファイル形式，又はディレクトリ構造形式で保存した詳細定義情報を読み込みます。定義更新時は選択できません。
詳細定義情報の上書き保存（S）※９ | 詳細定義情報を上書き保存します。一度も詳細定義情報の保存をしていない場合は，名前を付けて保存します。システム定義のチェックで問題ない場合だけ保存できます。チェックで問題がある場合，及び定義更新時は選択できません。
詳細定義情報の保存（A）※９ | ローカルディスク上に，詳細定義情報を名前を付けて保存します。システム定義のチェックで問題ない場合だけ保存できます。チェックで問題がある場合，及び定義更新時は選択できません。
終了（X） | 詳細定義を終了します。
編集（E） | 追加（A）※１ | マシン（M）※２ | システム構成ツリービューにサーバマシンを追加します（「サーバマシンを追加します」参照）。マシンを追加すると，ユニット制御情報定義，サーバ共通定義，及びバックエンドサーバ定義も追加されます。
ユニット（U）※３ | システム構成ツリービューにユニット制御情報定義を追加します。ユニットを追加すると，サーバ共通定義及びバックエンドサーバ定義も追加されます。
サーバ共通定義（C）※４ | システム構成ツリービューにサーバ共通定義を追加します。
ディクショナリサーバ（D）※４ | システム構成ツリービューにディクショナリサーバ定義を追加します。
フロントエンドサーバ（F）※４ | システム構成ツリービューにフロントエンドサーバ定義を追加します。
バックエンドサーバ（B）※４ | システム構成ツリービューにバックエンドサーバ定義を追加します。
オペランド（O）... | ［追加オペランド選択］ダイアログボックスを表示します（「オペランド又はオプションフラグの追加」参照）。
オプションフラグ（P）...※５ | ［追加オプションフラグ選択］ダイアログボックスを表示します「オペランド又はオプションフラグの追加」参照）。
編集（E）※６ | HiRDBファイルシステム領域（H）...※４ | ［HiRDBファイルシステム領域編集］ダイアログボックスを表示します（「HiRDBファイルシステム領域を編集します」参照）。
RDエリア（R）...※４ | ［RDエリア編集］ダイアログボックスを表示します（「RDエリアを編集します」参照）。
ステータスファイル（S）...※４，※７ | ［ステータスファイル編集］ダイアログボックスを表示します（ユニット用ステータスファイルの場合は「ユニット用ステータスファイルを編集します」参照，サーバ用ステータスファイルの場合は「サーバ用ステータスファイルを編集します」参照）。
システムログファイル（L）...※７ | ［システムログファイル編集］ダイアログボックスを表示します（「システムログファイル及びシンクポイントダンプファイルを編集します」参照）。
シンクポイントダンプファイル（D）...※７ | ［システムログファイル編集］ダイアログボックスを表示します（「システムログファイル及びシンクポイントダンプファイルを編集します」参照）。
グローバルバッファ（G）...※２ | ［グローバルバッファ編集］ダイアログボックスを表示します（「グローバルバッファを定義します」参照）。
マシン情報（M）...※３ | ［マシン情報編集］ダイアログボックスを表示します（「マシン情報の編集」参照）。
系切り替え機能の設定（A）...※２ | ［系切り替え機能の設定］ダイアログボックスを表示します（「系切り替え機能の設定」参照）。
サーバ名（N）...※７ | ［サーバ名設定］ダイアログボックスを表示します（「サーバ名の設定」参照）。
オペランド（O）... | オペランドの形式に応じた［オペランド値編集］ダイアログボックスを表示します（「オペランド値の編集」参照）。
削除（D） | 選択した項目を削除します。
コピー（C） | 選択した項目をコピーしてバッファに保存します。
貼り付け（P） | バッファにコピーした内容を貼り付けます。
表示（V） | ツールバー（T） | ツールバーの表示，又は非表示を指定します。
ステータスバー（S） | ステータスバーの表示，又は非表示を指定します。
リソース（R）※８ | リソース所要量の計算（C） | ［リソース所要量結果］ダイアログボックスを表示します（「リソース所要量を確認します」参照）。
ヘルプ（H） | バージョン情報（A）... | ［バージョン情報］ダイアログボックスを表示します。

注※１

HiRDB/シングルサーバの環境設定時，及び定義更新時は［オペランド］以外は選択できません。

注※２

システム構成ツリービューで［システム共通定義］を選択している場合にだけ，選択できます。

注※３

システム構成ツリービューで［マシン情報］を選択している場合にだけ，選択できます。

注※４

システム構成ツリービューで［ユニット制御情報定義］を選択している場合にだけ，選択できます。

注※５

オペランド情報リストビューでコマンド形式オペランドを選択している場合にだけ，選択できます。

注※６

定義更新時は［系切り替え機能の設定］及び［オペランド］以外は選択できません。

注※７

システム構成ツリービューで各サーバ（［サーバ共通定義］を除く）を選択している場合にだけ，選択できます。

注※８

簡易セットアップツールで環境設定していない環境で定義更新をした場合，リソース所要量の計算に必要なファイルがないため，選択できません。

注※９

詳細定義情報は単一ファイル形式，又はディレクトリ構造形式でローカルディスク上に保存します。このとき，ホスト名やパス名を変数に置き換えて保存します。読み込み時は，それらの変数を実際のホスト名やパス名に置き換えて読み込みます。保存時，及び読み込み時に置き換える変数名を次に示します。

変数名 | 保存時 | 読み込み時
?MASTDIR? | マスタディレクトリ用RDエリアの先頭のHiRDBファイル名がRDエリア格納先ディレクトリで始まっている場合に置き換えます。 | ［HiRDBセットアップツール−開始］ウィンドウから読み込んだ場合：［HiRDBセットアップツール−開始］ウィンドウで設定したセットアップディレクトリと，読み込みファイル内のマスタディレクトリ用RDエリアの先頭のHiRDBファイル名を連結した値に置き換えます。 ［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウからから読み込んだ場合：RDエリア格納先ディレクトリと，読み込む定義ファイル内のマスタディレクトリ用RDエリアの先頭のHiRDBファイル名を連結した値に置き換えます。
?HOST? | [マシン情報編集]ウィンドウの[ホスト名]に指定した文字列を変数に置き換えます。 | ［HiRDBセットアップツール−開始］ウィンドウで設定したホスト名に置き換えます。 HiRDB/パラレルサーバで複数のサーバマシンを指定した場合は，保存時に設定したホスト名に置き換えます。それ以外のホスト名はHOST1，HOST2，のように仮のホスト名に置き換えます。仮のホスト名については，詳細定義情報を読み込んだ後で[マシン情報編集]ウィンドウの[ホスト名]，[HiRDB運用ディレクトリ]，[システムファイル格納先]，及び[RDエリア格納先]を設定し直してください。
?HIDIR? | [マシン情報編集]の[HiRDB運用ディレクトリ]に指定した文字列を変数に置き換えます。 | ［HiRDBセットアップツール−開始］ウィンドウで設定した運用ディレクトリに置き換えます。
?RDDIR? | [マシン情報編集]の[システムファイル格納先]に指定した文字列を変数に置き換えます。 | ［HiRDBセットアップツール−開始］ウィンドウから読み込んだ場合：開始ウィンドウで設定したセットアップディレクトリに置き換えます。 ［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウから読み込んだ場合：RDエリア格納先ディレクトリに置き換えます。
?SYSDIRA? | [マシン情報編集]の[RDエリア格納先]に指定した文字列を変数に置き換えます。 | ［HiRDBセットアップツール−開始］ウィンドウから読み込んだ場合：開始ウィンドウで設定したセットアップディレクトリに置き換えます。 ［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウから読み込んだ場合：システムファイル格納先ディレクトリに置き換えます。
?SYSDIRB? | 置き換えません。 | 置き換えません。

3.6.2　カスタムセットアップ（詳細定義）の場合の環境設定手順

カスタムセットアップ（詳細定義）の場合の環境設定手順を次に示します。

(1)　［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウを表示させます

「カスタムセットアップの場合の環境設定手順」の手順1.〜2.を実行して，［詳細定義］をクリックします。［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウが表示されます。

(2)　詳細定義情報を読み込みます

ローカルディスク上に保存した詳細定義情報を読み込む場合は，メニューの［ファイル］−［詳細定義情報の読み込み］を選択します。［詳細定義情報の読み込み］ダイアログボックスが表示されます。

保存した詳細定義情報ファイル（ディレクトリ）を選択します。

このダイアログボックスで指定する項目について説明します。

項目名 | 説明
詳細定義情報ファイル（ディレクトリ） | 読み込む詳細定義情報ファイル又はディレクトリをフルパスで指定します。 ディレクトリ構造形式で保存した場合は指定ディレクトリ直下に“conf”及び“ini”ディレクトリが作成されますが，詳細定義情報の保存で指定したディレクトリ名を入力又は選択してください。
ディレクトリ形式で読み込む | 詳細定義情報をディレクトリ形式で読み込む場合にチェックします。
HiRDBの規模 | ［ディレクトリ形式で読み込む］をチェックしている場合に選択できます。指定した規模の定義情報が保存されていない場合はエラーになります。

［読み込み］をクリックすると，詳細定義情報を読み込み，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウに戻ります。

注意事項

HiRDB/パラレルサーバで複数のサーバマシンを指定した場合は，保存時に設定したホスト名に置き換えます。それ以外のホスト名はHOST1，HOST2，のように仮のホスト名に置き換えます。仮のホスト名については，詳細定義情報を読み込んだ後で[マシン情報編集]ウィンドウの[ホスト名]，[HiRDB運用ディレクトリ]，[システムファイル格納先]，及び[RDエリア格納先]を設定し直してください。

(3)　サーバマシンの情報を定義します

環境設定をするHiRDBがインストールされているサーバマシンの情報を定義します。なお，HiRDB/パラレルサーバでサーバマシンを追加する場合は，「HiRDB/パラレルサーバの環境設定をする場合」を参照してください。

(a)　マシン情報の編集

環境設定をするHiRDBがインストールされているマシンのホスト名，HiRDB運用ディレクトリ，システムファイル及びRDエリアの格納先を編集します。

システム構成ツリービューで［マシン情報］を選択した状態で，メニューの［編集］−［編集］−［マシン情報］を選択すると，［マシン情報編集］ダイアログボックスが表示されます。

［ホスト名］には，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウのシステム構成ツリービューで選択しているマシンのホスト名が，ホスト名，FQDN，又はIPアドレスの形式で表示されます。

ここでは，システムマネジャノードのHiRDB運用ディレクトリを変更しないでください。変更する場合は開始画面で変更してください。

環境設定をするマシンのホスト名を変更する場合，［hostsファイルからホスト名を選択］をクリックします。

［hostsファイルからホスト名を選択］ダイアログボックスが表示されるので，ホスト名，Windowsディレクトリ，ユーザ名，及びパスワードを指定します。

項目名 | 説明
ホスト名 | 環境設定をするマシンのホスト名を指定します。［hostsファイルのホスト名一覧］から選択するか，又は直接入力してください。入力できる形式は，ホスト名，FQDN，又はIPアドレスです。また，簡易セットアップツールを実行しているマシンの場合は，ループバックアドレスも指定できます。 なお，ホスト名を変更した場合，［ユーザ名］及び［パスワード］の内容はリセットされるため，入力し直してください。ただし，システムマネジャがあるサーバのホスト名は変更しないでください。
Windowsディレクトリ | Windowsインストールディレクトリをフルパスで指定します。通常は変更する必要はありません。 セパレータは¥と/のどちらも使用できますが，混在して指定できません。また，「ドライブ名:¥」と「/ドライブ名」のどちらも指定できます。
ユーザ名 | 環境設定をするサーバマシンのHiRDB管理者用のユーザ名を指定します。ドメインユーザの場合はドメインを付けて指定する必要はありません。
パスワード | ［ホスト名］で設定したホストのHiRDB管理者のパスワードを指定します。 選択したホストにアクセスするとき，このパスワードを併用するため，選択したホストのログインユーザと一致させてください。

なお，簡易セットアップツールで環境設定をすると，HiRDBに次に示す認可識別子を登録してDBA権限を付与します。

ユーザ：root

パスワード：root

また，この設定のリモートホスト接続処理で，セットアップ先にワーク領域を作成します。ワーク領域には，セットアップ先に正常に接続しているかを確認するためのバッチファイルや，バッチファイルの実行結果を保存したファイルを格納します。ワーク領域は，次の場所に作成されます。

%windir%¥Temp¥[ログインユーザ名]

［HiRDB運用ディレクトリ］でHiRDB運用ディレクトリを指定します。

セパレータは¥と/のどちらも使用できますが，混在して指定できません。また，「ドライブ名:¥」と「/ドライブ名」のどちらも指定できます。

ただし，次の場合のセパレータは¥になります。

簡易セットアップツールが作成するシステム定義ファイル中のパス

簡易セットアップツールの画面に表示されるパス

［システムファイル格納先］でシステムファイルの格納先ディレクトリを指定します。

初期値は%PDDIR%¥areaです。セパレータは¥と/のどちらも使用できますが，混在して指定できません。また，「ドライブ名:¥」と「/ドライブ名」のどちらも指定できます。

［RDエリア格納先］でRDエリアの格納先ディレクトリを指定します。

初期値は%PDDIR%¥areaです。セパレータは¥と/のどちらも使用できますが，混在して指定できません。また，「ドライブ名:¥」と「/ドライブ名」のどちらも指定できます。

［OK］をクリックすると，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウに戻ります。

(b)　サーバ名の設定

環境設定をするHiRDBがインストールされているマシンのサーバ名を設定します。

システム構成ツリービューで各サーバを選択した状態で，メニューの［編集］−［編集］−［サーバ名］を選択すると，［サーバ名設定］ダイアログボックスが表示されます。

変更後のサーバ名を1〜8文字で指定します。

［OK］をクリックすると，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウに戻ります。

(4)　ユニット制御情報定義を編集します

ユニット制御情報定義で定義する内容を編集します。

(a)　HiRDBファイルシステム領域を編集します

システム構成ツリービューで［ユニット制御情報定義］を選択した状態で，メニューの［編集］−［編集］−［HiRDBファイルシステム領域］を選択すると，［HiRDBファイルシステム領域編集］ダイアログボックスが表示されます。

簡易セットアップツールで作成するHiRDBファイルシステム領域を，［作成するHiRDBファイルシステム領域の一覧］リストに［一覧に追加］で追加します。このダイアログボックス表示時は，初期値のHiRDBファイルシステム領域が表示されるので，リストで選択して，［一覧を更新］又は［一覧から削除］で編集したり，削除したりできます。

このダイアログボックスで指定する項目について説明します。

項目名 | 説明
ファイル名 | 作成するHiRDBファイルシステム領域名をフルパスで指定します。
領域サイズ | HiRDBファイルシステム領域として割り当てる容量をメガバイト単位で指定します。
最大ファイル数 | HiRDBファイルシステム領域内に作成するHiRDBファイル数の上限を指定します。
増分回数 | HiRDBファイルシステム領域内のHiRDBファイルの増分回数の上限値を指定します。
使用目的 | HiRDBファイルシステム領域の使用目的を指定します。SDBは指定できません。また，系切り替え機能を使用する（pd_haオペランドにuseを指定）場合，SVRは指定できません。指定すると［OK］時にエラーになります。
領域を自動増分する | HiRDBファイルシステム領域の自動増分を行う場合に指定します。 使用目的がDB，SYS，又はWORKのときだけチェックできます。また，使用目的がDB，又はSYSのときにこの項目を指定すると，最大ファイル数と増分回数が変更できなくなります。 HiRDBの規模を拡大させたくない場合については，「簡易セットアップツールとは」の「注意」を参照してください。
領域を初期化する | HiRDBファイルシステム領域を最初から初期化する場合に指定します。系切り替え機能使用時は，この項目を必ずチェックしてください。チェックしないと［OK］時にエラーになります。
セクタ長 | セクタ長を変更する必要があるHiRDBファイルシステム領域を作成する際に指定します。pdfmkfsコマンドでのセクタ長の変更要否については，マニュアル「HiRDB コマンドリファレンス」を参照してください。 指定内容に誤りがある場合，セットアップを開始したときに簡易セットアップツールがエラー（KFPX29680-E）となります。

複製ディスク使用

複製ディスクを使用する場合に指定します。複製ディスクの使用方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

使用目的がDB，SYS，UTL，又はWORKのときだけチェックできます。

この機能を使用する場合は，あらかじめ必要な準備を行った上で指定してください。使用方法に誤りがある場合，セットアップを開始したときに簡易セットアップツールがエラー（KFPX29680-E）となります。また，この機能は，Linux限定機能であるため，Linux以外のOSに対する環境設定を行う際にチェックを入れた状態にすると，使用方法誤りとして，セットアップを開始したときに簡易セットアップツールがエラー（KFPX29680-E）となります。

［HiRDBファイルシステム領域編集］ダイアログボックスで［OK］をクリックすると，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウへ戻ります。

(b)　RDエリアを編集します

システム構成ツリービューで［ユニット制御情報定義］を選択した状態で，メニューの［編集］−［編集］−［RDエリア］を選択すると，［RDエリア編集］ダイアログボックスが表示されます。

簡易セットアップツールで作成するRDエリアを，［RDエリアの一覧］リストに［一覧に追加］で追加します。このダイアログボックス表示時は，初期値のRDエリアが表示されるので，リストで選択して，［一覧を更新］又は［一覧から削除］で編集したり，削除したりできます。また，作成するRDエリアに割り当てるHiRDBファイルを［RDエリアを割り当てるHiRDBファイルの指定］ダイアログボックスで指定します。

［RDエリア編集］ダイアログボックスで［OK］をクリックすると，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウへ戻ります。

●RDエリアの編集

［RDエリア編集］ダイアログボックスで指定する項目について説明します。

項目名 | 説明
RDエリア名 | 作成するRDエリア名を1〜30文字で指定します。

RDエリアの種類

RDエリアの種類を選択します。選択できるRDエリアを次に示します。

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

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

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

LOB used by HiRDB(SQL_ROUTINES)：データディクショナリLOB用RDエリア

user used by PUBLIC：ユーザ用RDエリア

LOB used by PUBLIC：ユーザLOB用RDエリア

list：リスト用RDエリア

user used by PUBLIC(temporary table use shared)：SQLセッション間共有属性の一時表用RDエリア

user used by PUBLIC(temporary table use occupied)：特定SQLセッション占有属性の一時表用RDエリア

なお，レジストリ用RDエリア及びレジストリLOB用RDエリアは指定できません。

サーバ名 | RDエリアを管理するサーバを選択します。なお，HiRDB/シングルサーバの場合は指定できません。
ページ長 | RDエリアを構成するHiRDBファイルのページ長を2,048の倍数のバイト単位で指定します。
セグメントサイズ | 1セグメントの大きさをページ数で指定します。
最大リスト登録数 | リスト用RDエリアを指定する場合の最大リスト登録数を指定します。シングルサーバ又はバックエンドサーバのときだけ指定できます。
自動増分を適用する | 自動増分を適用するかどうかを指定します。ただし，次のRDエリアの場合は選択できません。 マスタディレクトリ用RDエリア データディレクトリ用RDエリア
増分セグメント数 | 自動増分を適用する場合の増分セグメント数を指定します。

●作成したRDエリアに割り当てるHiRDBファイルの指定

［RDエリア編集］ダイアログボックスの［RDエリアに割り当てるHiRDBファイルの指定］をクリックすると，［RDエリアを割り当てるHiRDBファイルの指定］ダイアログボックスが表示されます。

作成するRDエリアに割り当てるHiRDBファイルがあるHiRDBファイルシステム領域，HiRDBファイル名（1〜30文字），及びそのHiRDBのセグメント数を指定します。［OK］をクリックすると，［RDエリア編集］ダイアログボックスに戻ります。

(c)　HiRDBファイルシステム領域及びRDエリアの編集時の注意事項

raw I/O機能を使用する場合，［HiRDBファイルシステム領域編集］ダイアログボックスの［ファイル名］には，「¥¥.¥ドライブ名:」の形式で指定してください。リモートで環境設定をする場合，［フォルダの参照］ダイアログボックスで，未フォーマットのパーティションの論理ドライブを選択できます。このときも［ファイル名］には「¥¥.¥ドライブ名:」の形式で指定してください。

raw I/O機能を適用したHiRDBファイルシステム領域には制限があります。制限の詳細については，「raw I/O機能の適用範囲」を参照してください。

(d)　ユニット用ステータスファイルを編集します

簡易セットアップツールで作成するユニット用ステータスファイルは，［ステータスファイル編集］ダイアログボックスでリストに［一覧に追加］で追加します。このダイアログボックス表示時は，初期値の値が表示されるので，リストで選択して，［一覧を更新］又は［一覧から削除］で編集したり，削除したりできます。

ユニット用の［ステータスファイル編集］ダイアログボックスを表示するには，システム構成ツリービューで［ユニット制御情報定義］を選択した状態で，メニューの［編集］−［編集］−［ステータスファイル］を選択します。

作成できるステータスファイルは7個のため，［作成するステータスファイルの一覧］リストのファイルが7個になると，［一覧に追加］ボタンはクリックできなくなります。また，［作成するステータスファイルの一覧］リストのファイルが3個になると，［一覧から削除］ボタンはクリックできなくなります。

このダイアログボックスで指定する項目について説明します。

項目名 | 説明

論理ファイル名

作成するステータスファイルの論理ファイル名を英数字1〜8文字で指定します。初期値を次に示します。

サーバの場合

[サーバ名]sts[論理ファイル数の通番]

ただし，8文字を超える場合は次の名称とします。

[サーバ種別※（1文字）][サーバの通番]s[論理ファイル数の通番]

注※

　d：ディクショナリサーバ

　f：フロントエンドサーバ

　b：バックエンドサーバ

ユニットの場合

[ユニット名の1，2，4文字]sts[論理ファイル数の通番]

ただし，8文字を超える場合は次の名称とします。

u[ユニットの通番]s[論理ファイル数の通番]

A系HiRDBファイルシステム領域名

作成するA系ステータスファイルを格納するHiRDBファイルシステム領域名をドロップダウンリストで選択します。種別がSYSとSVR以外のHiRDBファイルシステム領域は選択できません。初期値を次に示します。

サーバの場合

[ファイルの格納先]¥[サーバ名]¥syssts[サーバの種類][サーバ数の通番]¥

ユニットの場合

[ファイルの格納先]¥dic1¥sysstsut¥

A系ステータスファイル名 | 作成するA系ステータスファイル名を英数字で指定します。初期値は「[サーバ名]sts[論理ファイル数の通番]a」です。

B系HiRDBファイルシステム領域名

作成するB系ステータスファイルを格納するHiRDBファイルシステム領域名をドロップダウンリストで選択します。種別がSYSとSVR以外のHiRDBファイルシステム領域は選択できません。初期値を次に示します。

サーバの場合

[ファイルの格納先]¥[サーバ名]¥syssts[サーバの種類][サーバ数の通番]¥

ユニットの場合

[ファイルの格納先]¥dic1¥sysstsut¥

B系ステータスファイル名 | 作成するB系ステータスファイル名を英数字で指定します。初期値は「[サーバ名]sts[論理ファイル数の通番]b」です。
レコード長 | ステータスファイルのレコード長をバイト単位で指定します。
レコード数 | ステータスファイルのレコード数を指定します。

［ステータスファイル編集］ダイアログボックスで［OK］をクリックすると，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウへ戻ります。

(5)　シングルサーバ定義，又は各サーバ定義を編集します

簡易セットアップツールで作成するサーバ用ステータスファイル，システムログファイル，及びシンクポイントダンプファイルは，それぞれの編集ダイアログボックスでリストに［一覧に追加］で追加します。それぞれの編集ダイアログボックス表示時は，初期値の値が表示されるので，リストで選択して，［一覧を更新］又は［一覧から削除］で編集したり，削除したりできます。

それぞれのファイルについて説明します。

(a)　サーバ用ステータスファイルを編集します

サーバ用の［ステータスファイル編集］ダイアログボックスを表示するには，システム構成ツリービューで各サーバ※の定義を選択した状態で，メニューの［編集］−［編集］−［ステータスファイル］を選択します。

注※　

シングルサーバ，ディクショナリサーバ，バックエンドサーバ，及びフロントエンドサーバのことです。

サーバ用の［ステータスファイル編集］ダイアログボックスで指定する項目については，「ユニット用ステータスファイルを編集します」を参照してください。

(b)　システムログファイル及びシンクポイントダンプファイルを編集します

編集ダイアログボックスを表示する手順は次のとおりです。

このダイアログボックスは，システム構成ツリービューで各サーバの定義を選択した状態で，メニューの［編集］−［編集］−［システムログファイル］又は［シンクポイントダンプファイル］を選択すると表示されます。

●システムログファイル

作成できるファイルグループは200個までのため，［作成するシステムログファイルの一覧］リストのファイルグループが200個になると，［一覧に追加］ボタンはクリックできなくなります。また，［作成するシステムログファイルの一覧］リストのファイルグループが2個（pd_log_rerun_swap=Y，又はpd_spd_assurance_count=2の場合は3個）になると，［一覧から削除］ボタンはクリックできなくなります。

●シンクポイントダンプファイル

作成できるファイルグループは60個までのため，［作成するシンクポイントダンプファイルの一覧］リストのファイルグループが60個（［ONL（HiRDB稼働開始と同時にオープン）］をチェックしている場合は30個）になると，［一覧に追加］ボタンはクリックできなくなります。また，［作成するシンクポイントダンプファイルの一覧］リストのファイルグループが2個になると，［一覧から削除］ボタンはクリックできなくなります。

システムログファイル又はシンクポイントダンプファイルを二重化（pd_log_dual又はpd_spd_dualオペランドにYを指定）する場合，B系HiRDBファイルシステム領域名を指定してください。なお，二重化しているファイルと二重化していないファイルを［作成するシステムログファイルの一覧］リストに混在させることはできません。混在した状態で［OK］をクリックするとエラーになります。どちらかに統一してください。

このダイアログボックスで指定する項目について説明します。

項目名 | 説明

ファイルグループ名

作成するシステムログファイル又はシンクポイントダンプファイルのファイルグループ名を英数字1〜8文字で指定します。初期値を次に示します。

システムログファイルの場合

[サーバ名]log[ファイルグループ数の通番]

ただし，8文字を超える場合は次の名称とします。

[サーバ種別※（1文字）][サーバの通番]l[ファイルグループ数の通番]

シンクポイントダンプファイルの場合

[サーバ名]spd[ファイルグループ数の通番]

ただし，8文字を超える場合は次の名称とします。

[サーバ種別※（1文字）][サーバの通番]d[ファイルグループ数の通番]

注※

d：ディクショナリサーバ

f：フロントエンドサーバ

b：バックエンドサーバ

A系HiRDBファイルシステム領域名

作成するA系システムログファイル又はA系シンクポイントダンプファイルを格納するHiRDBファイルシステム領域名をドロップダウンリストで選択します。種別がSYSとSVR以外のHiRDBファイルシステム領域は選択できません。初期値を次に示します。

システムログファイルの場合

[ファイルの格納先]¥[サーバ名]¥syslog[サーバの種類][サーバ数の通番]¥

シンクポイントダンプファイルの場合

[ファイルの格納先]¥[サーバ名]¥sysspd[サーバの種類][サーバ数の通番]¥

A系システムログファイル名又はA系シンクポイントダンプファイル名

作成するA系システムログファイル名又はA系シンクポイントダンプファイルを英数字で指定します。初期値を次に示します。

システムログファイルの場合

[サーバ名]log[ファイルグループ数の通番]a

シンクポイントダンプファイルの場合

[サーバ名]spd[ファイルグループ数の通番]a

B系HiRDBファイルシステム領域名 | 作成するB系システムログファイル又はB系シンクポイントダンプファイルを格納するHiRDBファイルシステム領域名をドロップダウンリストで選択します。種別がSYSとSVR以外のHiRDBファイルシステム領域は選択できません。システムログファイルを二重化する場合，障害発生に備えて，A系とB系のシステムログファイルは別々のハードディスクに作成することをお勧めします。A系と異なるハードディスクのHiRDBファイルシステム領域を選択してください。初期値は空です。
B系システムログファイル名又はB系シンクポイントダンプファイル名 | 作成するB系システムログファイル名又はB系シンクポイントダンプファイル名を英数字で指定します。初期値は空ですが，B系HiRDBファイルシステム領域名が選択されると，「[サーバ名]log[ファイルグループ数の通番]b」又は「[サーバ名]spd[ファイルグループ数の通番]b」が表示されます。
レコード数 | システムログファイル又はシンクポイントダンプファイルのレコード数を指定します。
ONL | このシステムログファイル又はシンクポイントダンプファイルのファイルグループを，HiRDB開始と同時に使用できる状態（オープン状態）にする場合にチェックします。

［システムログファイル編集］又は［シンクポイントダンプファイル編集］ダイアログボックスで［OK］をクリックすると，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウへ戻ります。

(6)　必要に応じて定義の指定値を編集します

HiRDBシステム定義の指定値を簡易セットアップツールの初期値から変更したい場合，HiRDBシステム定義を編集します。システム構成ツリービューで作成する定義を選択します。オペランド情報リストビューに初期値が表示されるので，オペランドを追加又は削除したり，指定値を変更したりします。なお，HiRDBシステム定義を編集する場合の注意事項については，「HiRDBシステム定義を編集する場合の注意事項」を参照してください。簡易セットアップツールで作成できる定義については，「システム定義ファイル」を参照してください。

注意事項

簡易セットアップツールでは次の定義は作成できません。

UAP環境定義

SQL予約語定義

(a)　オペランド又はオプションフラグの追加

オペランド，又はオプションフラグを追加します。オプションフラグを追加できるのは，オペランド情報リストビューでコマンド形式のオペランドを選択している場合です。追加手順を次に示します。

オペランドの追加手順

メニューの［編集］−［追加］−［オペランド］を選択します。

［追加オペランド選択］ダイアログボックスのオペランドの一覧から，追加するオペランドを選択します。

［OK］をクリックすると，［オペランド値編集］ダイアログボックスが表示されます。オペランド値の編集については，「オペランド値の編集」を参照してください。

オプションフラグの追加手順

メニューの［編集］−［追加］−［オプションフラグ］を選択します。

［追加オプションフラグ選択］ダイアログボックスのオプションフラグの一覧から，追加するオプションフラグを選択します。

［OK］をクリックすると，［オペランド値編集］ダイアログボックスが表示されます。オペランド値の編集については，「オペランド値の編集」を参照してください。

(b)　オペランド値の編集

オペランドの指定値を編集します。

次のどちらかの操作をして，オペランドの形式に応じた［オペランド値編集］ダイアログボックスを表示させます。

メニューの［編集］−［編集］−［オペランド］を選択

［追加オペランド選択］及び［追加オプションフラグ選択］ダイアログボックスでオペランドを選択して［OK］をクリック

なお，オペランドの形式によってタイトルバーの表示が異なります。「単一値」，「複数値」，「単一選択」，「複数選択」，及び「単一選択または任意」の5種類のダイアログボックスが表示されます。

オペランドの形式に応じてオペランドの指定値を編集します。

指定値が一つの場合，オペランドの値を指定します。指定値を選択する場合，ドロップダウンリストになっているので，一つ又は複数選択します。

指定値を一つ選択するか，又は任意の値を入力して編集する場合，ドロップダウンリスト中の選択肢から値を選択します。またテキスト部に任意の値を直接入力することもできます。

必要に応じてユーザコメントを入力します。

ユーザコメントは任意です。コマンド形式オペランドのオプションフラグの場合は，そのオペランド全体に対するコメントになります。最大で半角78文字まで入力できます。

(c)　オペランドの削除

削除するオペランドを，オペランド情報リストビューから選択して，メニューの［編集］−［削除］を選択します。

(7)　グローバルバッファを定義します

システム構成ツリービューで［システム共通定義］を選択した状態で，メニューの［編集］−［編集］−［グローバルバッファ］を選択すると，［グローバルバッファ編集］ダイアログボックスが表示されます。

簡易セットアップツールで定義するグローバルバッファを，［グローバルバッファの一覧］リストに［一覧に追加］で追加します。このダイアログボックス表示時は，初期値のグローバルバッファが表示されるので，リストで選択して，［一覧を更新］又は［一覧から削除］で編集したり，削除したりできます。また，作成するグローバルバッファを割り当てるRDエリアを［グローバルバッファを割り当てるRDエリアの指定］ダイアログボックスで指定します。

［グローバルバッファ編集］ダイアログボックスで［OK］をクリックすると，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウへ戻ります。

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

［グローバルバッファ編集］ダイアログボックスで指定する項目について説明します。

項目名 | 説明
バッファ名 | グローバルバッファの名称を1〜16文字で指定します。
バッファ面数 | グローバルバッファの面数を指定します。
残りの全てのRDエリアにグローバルバッファを割り当てる | pdbufferオペランドの-rオプションで指定していない全RDエリアにグローバルバッファを割り当てる場合にチェックします。なお，この項目をチェックしていると，［グローバルバッファを割り当てるRDエリアの指定］はクリックできません。

●作成したグローバルバッファを割り当てるRDエリアの指定

［グローバルバッファ編集］ダイアログボックスの［グローバルバッファを割り当てるRDエリアの指定］をクリックすると，［グローバルバッファを割り当てるRDエリアの指定］ダイアログボックスが表示されます。

グローバルバッファを割り当てるRDエリアを［残りのRDエリア］（グローバルバッファが割り当てられていないRDエリアの一覧）から［割り当てるRDエリア］に［追加］します。又は，［割り当てるRDエリア］から［削除］します。［OK］をクリックすると，［グローバルバッファ編集］ダイアログボックスに戻ります。

(8)　HiRDBシステム定義のチェックをします

HiRDBシステム定義の値を変更した場合，メニューの［ファイル］−［システム定義のチェック］を選択して，HiRDBシステム定義のチェックをする必要があります。チェックをしないと指定値の変更は有効になりません。チェック結果は［システム定義のチェック結果］ダイアログボックスに表示されます。

HiRDBシステム定義のチェックでエラーがあると，セットアップはできません。エラーの原因を取り除いてから再度HiRDBシステム定義のチェックをしてください。

(9)　リソース所要量を確認します

簡易セットアップツールで設定したHiRDBシステム定義で必要となるメモリ所要量とディスク容量を計算できます。セットアップを開始する前にメモリ所要量とディスク容量が十分かどうか確認してください。

メニューの［リソース］−［リソース所要量の計算］を選択すると，［リソース所要量計算結果］ダイアログボックスに計算結果が表示されます。計算はメガバイト単位で行い，端数は繰り上げます。

ディスク容量は，「システムファイル格納先」と「RDエリア格納先」が同じ場合は「セットアップディレクトリ」として表示し，異なる場合は別々に表示します。また，「システムファイル格納先」と「RDエリア格納先」以外に作成するように指定した場合，「その他」として，ドライブごとの合計値を表示します。

［リソース所要量結果］ダイアログボックスを表示したまま，ほかのシステム定義を設定するダイアログボックスで指定を変更できます。オペランドを追加又は値を編集して，メニューの［リソース］−［リソース所要量の計算］を選択すると計算結果が更新されます。［HiRDBセットアップツール−詳細定義］ウィンドウを閉じると，［リソース所要量結果］ダイアログボックスも閉じます。

計算対象とするリソースを次の表に示します。

表3‒4　リソース所要量の計算対象となるリソース

リソース
メモリ所要量 | ユニットコントローラが使用する共用メモリ
各サーバが使用する共用メモリ
グローバルバッファが使用する共用メモリ
RDエリアの容量 | ユーザ用RDエリアの容量
データディクショナリ用RDエリアの容量
マスタディレクトリ用RDエリアの容量
データディレクトリ用RDエリアの容量
データディクショナリ用RDエリアの容量
データディクショナリLOB用RDエリアの容量
ユーザLOB用RDエリアの容量
リスト用RDエリアの容量
システムファイルの容量 | システムログファイルの容量
シンクポイントダンプファイルの容量
ステータスファイルの容量
作業表用ファイルの容量 | 作業表用ファイルの容量
ユティリティ実行時の容量 | ユティリティ用のHiRDBファイルシステムの容量

メモリ所要量は，指定された定義オペランドを基に見積もります。また，ディスク所要量は，［HiRDBファイルシステム領域編集］ダイアログボックスで作成するように指定されたHiRDBファイルシステム領域について，指定値を基に見積もります。

なお，ここで表示されるのは，HiRDB構築時のディスク所要量です。HiRDB開始後の運用によっては，規模が拡大する場合があります。その場合の詳細については，「HiRDBファイルシステム領域を編集します」の注を参照してください。

(10)　詳細定義情報を保存します

名前を付けて保存する場合

設定した詳細定義情報をローカルディスク上に名前を付けて保存する場合は，メニューの［ファイル］−［詳細定義情報の保存］を選択します。

［詳細定義情報の保存］ダイアログボックスが表示されます。

詳細定義情報ファイル（ディレクトリ）名を指定します。

このダイアログボックスで指定する項目について説明します。

項目名 | 説明
詳細定義情報ファイル（ディレクトリ） | 詳細定義情報ファイル名又はディレクトリ名をフルパスで指定します。ファイル形式で保存する場合，拡張子はdatとしてください。
ディレクトリ形式で保存する | 詳細定義情報をディレクトリ形式で保存する場合にチェックします。
HiRDBの規模 | ［ディレクトリ形式で保存する］をチェックしている場合に選択できます。 ディレクトリ構造形式では，異なる規模の詳細定義情報を同じディレクトリ下に保存できます。ただし，サーバ種別が異なる場合（HiRDB/パラレルサーバとHiRDB/シングルサーバなど）は，同じディレクトリ下には保存できません。

［保存］をクリックすると，確認メッセージを表示した後に詳細定義情報を保存し，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウに戻ります。

上書き保存する場合

設定した詳細定義情報をローカルディスク上に上書き保存する場合は，メニューの［ファイル］−［詳細定義情報の上書き保存］を選択します。確認メッセージを表示した後に詳細定義情報を保存し，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウに戻ります。

(11)　セットアップを開始します

メニューの［ファイル］−［終了］を選択すると，［HiRDBセットアップツール−カスタム］ウィンドウに戻ります※。［セットアップ開始］をクリックすると，セットアップが開始されます。

注※

ウィザードセットアップで環境設定をした後に詳細定義を行った場合は，［HiRDBセットアップツール−ウィザードセットアップ［確認］］ウィンドウに戻ります。

3.7　詳細定義情報の読み込み

ローカルディスク上に保存した詳細定義情報を読み込みます。

［HiRDBセットアップツール−開始］ウィンドウで［詳細定義情報の読み込み］をクリックすると，［詳細定義情報の読み込み］ダイアログボックスが表示されます。そこで詳細定義情報を読み込むと，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウが開きます。

詳細定義情報の読み込みについては，「詳細定義情報を読み込みます」を参照してください。

注意事項

［HiRDBセットアップツール−開始］ウィンドウから［詳細定義情報の読み込み］を選択して詳細定義情報を読み込む場合，［システムファイル格納先ディレクトリ］と［RDエリア格納先ディレクトリ］として，［セットアップディレクトリ］が使用されます。

バージョン08-02の簡易セットアップツールで保存した詳細定義情報を，バージョン08-03以降の簡易セットアップツールで読み込むことができます。

3.8　定義の更新

作成済みのHiRDBシステム定義を更新します。既存のHiRDBシステムがない場合は選択できません。なお，簡易セットアップツールを使って設定していない環境の場合，HiRDBシステム定義ファイルの記述方法によっては，簡易セットアップツールが対応できないでエラーとなるときがあります。このようなときは，手動でHiRDBシステム定義を更新してください。

3.8.1　定義を更新する前に

定義を更新する場合，HiRDBを停止し，アンロード待ち状態のシステムログファイルをアンロードしておく必要があります。また，次のオペランドの変更時はpdloginitコマンドでシステムログファイルを初期化する必要があります。

pd_log_dual

pdstart

3.8.2　定義の更新手順

定義の更新手順を次に示します。

［HiRDBセットアップツール−開始］ウィンドウで［定義更新］をクリックします。

［HiRDBセットアップツール−詳細定義（定義更新）］ウィンドウが表示されます。

システム構成ツリービューで作成する定義を選択して，オペランドを追加又は削除したり，指定値を変更したりします。なお，HiRDBシステム定義を編集する場合の注意事項については，「HiRDBシステム定義を編集する場合の注意事項」を参照してください。

メニューの［ファイル］−［システム定義のチェック］を選択して，HiRDBシステム定義のチェックをします。

HiRDBシステム定義のチェックでエラーがあると，定義の更新はできません。エラーの原因を取り除いてから再度HiRDBシステム定義のチェックをしてください。

メニューの［ファイル］−［システム定義の更新］を選択すると，HiRDBシステム定義が更新されます。

メニューの［ファイル］−［終了］を選択すると，定義の更新を終了します。

注意事項

簡易セットアップツールはファイルの文字コード種別をSJISとして扱います。システム定義ファイルをSJIS以外で保存した場合，［システム定義の更新］でオペランドのコメント欄の文字コード種別依存文字がGUI画面上で文字化けすることがありますが，［システム定義の更新］に影響ありません（［システム定義のチェック］は正常終了します）。

文字コード種別をUTF-8でファイル保存した場合，ファイル先頭にUTF-8を示すBOM（Byte Order Mark：0xEFBBBF）が付加されることがあります。HiRDBを文字コード種別UTF-8でインストールしている場合だけ，簡易セットアップツールはシステム定義の更新時にユーザが作成したシステム定義ファイルのBOMを読みとばして，システム定義の更新実行後のファイルからはBOMを削除します。UTF-8以外の文字コードでセットアップしている場合は，BOMはデータの一部として読み込みます。そのため，［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウのオペランド一覧に不正なオペランドが表示されることがあり，［システム定義のチェック］がエラーとなってシステム定義の更新を実行することはできません。

3.9　注意事項

3.9.1　HiRDBシステム定義を編集する場合の注意事項

HiRDBシステム定義を編集する場合の注意事項を次に示します。

(1)　ファイル名の長さ

ファイル名はフルパスで167バイト以下にしてください。特にHiRDB/パラレルサーバでは，システムファイル及びRDエリアを次のディレクトリ下に作成するため，注意が必要です。

ユーザが指定したセットアップディレクトリ¥fes1¥

ユーザが指定したセットアップディレクトリ¥dic1¥

ユーザが指定したセットアップディレクトリ¥bes1¥

ユーザが指定したセットアップディレクトリ¥bes2¥

ただし，ステータスファイルの編集，システムログファイルの編集，シンクポイントダンプファイルの編集のダイアログでファイルの追加又は編集を行う場合は，64バイト以下にしてください。

(2)　pd_system_idオペランドの変更

システム共通定義（pdsys）のpd_system_idオペランドは，セットアップ時だけ変更できます。定義更新時に編集しようとするとエラーになります。

(3)　pd_unit_idオペランドの変更

ユニット制御情報定義（pdutsys）のpd_unit_idオペランド（ユニット識別子）を変更すると，ユニット識別子を指定しているシステム共通定義の次のオペランドの値も自動的に更新されます。

pdunit -u（ユニット識別子）

pdstart -u（ユニット識別子）

(4)　マシン情報の変更

［マシン情報編集］ダイアログボックスでホスト名やHiRDB運用ディレクトリを変更すると，それらの値を指定するシステム共通定義の次のオペランドの値も自動的に更新されます。

pdunit -x（ホスト名）

pdunit -d（HiRDB運用ディレクトリ）

pdunit -c（ホスト名）

pdstart -x（ホスト名）

pdstart -m（ホスト名）

pdstart -n（ホスト名）

(5)　サーバ名の変更

サーバ名を変更すると，サーバ名を指定するpdstartオペランドの-sオプションの値も自動的に更新されます。

(6)　ユニットの追加，又は削除

ユニットを追加，又は削除すると，pdunitオペランドの値も自動的に追加，又は削除されます。

(7)　サーバの追加，又は削除

サーバを追加，又は削除すると，pdstartオペランドの値も自動的に追加，又は削除されます。

(8)　マシン情報，ユニット，又はサーバのコピーと貼り付け

マシン情報，ユニット，又はサーバをコピーして貼り付けた場合，次の内容はコピー元の定義内容を引き継ぎます。

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

RDエリアの情報（RDエリア名，サーバ名，及びRDエリアに割り当てたHiRDBファイル）

各サーバの情報（ステータスファイル，システムログファイル，及びシンクポイントダンプファイル）

各サーバのサーバ定義中の各オペランド値

(9)　サーバ名とマシン情報のHiRDB運用ディレクトリの変更

サーバ名とマシン情報のHiRDB運用ディレクトリを変更した場合も，(8)に示す情報は自動的に変更後の値に更新されます。

3.10　HiRDB/パラレルサーバの環境設定をする場合

3.10.1　HiRDB/パラレルサーバの環境設定手順

簡易セットアップツールの初期値では，サーバマシンが一つの構成のため，HiRDB/パラレルサーバの場合はサーバマシンを追加することから始めます。ここでは，バックエンドサーバ（BES）を追加する例を示しながらHiRDB/パラレルサーバの環境設定手順を説明します。

(1)　サーバマシンを追加します

［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウで，次のどちらかの方法でサーバマシンを追加します。

新規追加

システム構成ツリービューで［システム共通定義］を選択した状態で，メニューの［編集］−［追加］−［マシン］を選択します。

［マシン情報編集］ダイアログボックスが表示されるので，追加するマシンの情報を設定します。［マシン情報編集］ダイアログボックスについては，「マシン情報の編集」を参照してください。

既存のマシン情報をコピー

システム構成ツリービューで既存の［マシン情報］を選択した状態で，メニューの［編集］−［コピー］を選択します。システム構成ツリービューで［システム共通定義］を選択した状態で，メニューの［編集］−［貼り付け］を選択します。

コピーしたサーバマシンと同じ内容のサーバマシン情報が追加されます。不要な情報は削除します。

1.の場合はHiRDBファイルシステム領域やRDエリアの情報などが設定されません。2.の場合は既存の情報がそのままコピーされ，既存の情報を基に編集できるため，2.をお勧めします。

サーバマシンを追加した［HiRDBセットアップツール−詳細定義（セットアップ）］ウィンドウを次の図に示します。

図3‒10　サーバマシンの追加例

[picture]

(2)　追加したBESの情報を編集します

［マシン情報編集］ダイアログボックスで，追加したBESのホスト名，HiRDB運用ディレクトリ，システムファイル及びRDエリア格納先の情報を編集します。

(3)　追加したBESのHiRDBファイルシステム領域を編集します

システム構成ツリービューで，追加したBESの［ユニット制御情報定義］を選択した状態で，メニューの［編集］−［編集］−［HiRDBファイルシステム領域］を選択して，［HiRDBファイルシステム領域編集］ダイアログボックスを表示し，各HiRDBファイルシステム領域の情報を編集します。ここでは，次に示す値を指定します。

追加したBESのHiRDBファイルシステム領域の定義（ユニット制御情報定義unt2の定義）

ファイル名※ | 領域サイズ | 最大ファイル数 | 使用目的 | 増分回数 | 初期化
%PDDIR%¥area¥unt2¥sysstsut | 5 | 10 | SYS | 1 | ○
%PDDIR%¥area¥bes3¥rdworkb3 | 25 | 10 | WORK | 255 | ○
%PDDIR%¥area¥bes3¥rddatb3 | 20 | 10 | DB | 1 | ○
%PDDIR%¥area¥bes3¥rdlobb3 | 10 | 10 | DB | 1 | ○
%PDDIR%¥area¥bes3¥sysstsb3 | 30 | 10 | SYS | 1 | ○
%PDDIR%¥area¥bes3¥sysspdb3 | 5 | 10 | SYS | 1 | ○
%PDDIR%¥area¥bes3¥syslogb3 | 70 | 10 | SYS | 1 | ○

（凡例）

○：［領域を初期化する（-iオプション）］チェックボックスをチェックしています。

注※　%PDDIR%は，追加したサーバマシンのHiRDB運用ディレクトリです。

なお，既存のサーバマシンをコピーしてサーバマシン情報を追加した場合，コピー元のサーバマシンの情報が設定されているため，上記以外の情報をすべて削除してください。

(4)　追加したBESのRDエリアを編集します

システム構成ツリービューで，追加したBESの［ユニット制御情報定義］を選択した状態で，メニューの［編集］−［編集］−［RDエリア］を選択して，［RDエリア編集］ダイアログボックスを表示し，各RDエリアの情報を編集します。ここでは，次に示す値を指定します。

追加したBESのRDエリアの定義（ユニット制御情報定義unt2の定義）

各RDエリアの情報

RDエリア名 | RDエリアの種類 | サーバ名 | ページ長 | セグメントサイズ
bes3data | user used by PUBLIC | bes3 | 4,096 | 10
bes3indx | user used by PUBLIC | bes3 | 4,096 | 10
bes3lob | LOB used by PUBLIC | bes3 | 8,192 | 1

各RDエリアに割り当てるHiRDBファイルの情報

RDエリア名 | HiRDBファイル名※ | セグメント数
bes3data | %PDDIR%¥area¥bes3¥rddatb3¥bes3data | 300
bes3indx | %PDDIR%¥area¥bes3¥rddatb3¥bes3indx | 100
bes3lob | %PDDIR%¥area¥bes3¥rddatb3¥bes3lob | 400

注※　%PDDIR%は，追加したサーバマシンのHiRDB運用ディレクトリです。

なお，既存のサーバマシンをコピーしてサーバマシン情報を追加した場合，コピー元のサーバマシンの情報が設定されているため，上記以外の情報をすべて削除してください。

(5)　追加したBESのユニットステータスファイルを編集します

システム構成ツリービューで，追加したBESの［ユニット制御情報定義］を選択した状態で，メニューの［編集］−［編集］−［ステータスファイル］を選択して，［ステータスファイル編集］ダイアログボックスを表示し，各ステータスファイルの情報を編集します。ここでは，次に示す値を指定します。

追加したBESのユニットステータスファイルの定義（ユニット制御情報定義unt2の定義）

論理ファイル名 | A系ステータスファイル名※ | B系ステータスファイル名※ | レコード長 | レコード数
ut2sts1 | %PDDIR%¥area¥unt2¥sysstsut¥ut2sts1a | %PDDIR%¥area¥unt2¥sysstsut¥ut2sts1b | 4,096 | 40
ut2sts2 | %PDDIR%¥area¥unt2¥sysstsut¥ut2sts2a | %PDDIR%¥area¥unt2¥sysstsut¥ut2sts2b | 4,096 | 40
ut2sts3 | %PDDIR%¥area¥unt2¥sysstsut¥ut2sts3a | %PDDIR%¥area¥unt2¥sysstsut¥ut2sts3b | 4,096 | 40

注※　%PDDIR%は，追加したサーバマシンのHiRDB運用ディレクトリです。

(6)　追加したBESのステータスファイルを編集します

システム構成ツリービューで，追加したBESの定義を選択した状態で，メニューの［編集］−［編集］−［ステータスファイル］を選択して，［ステータスファイル編集］ダイアログボックスを表示し，各ステータスファイルの情報を編集します。ここでは，次に示す値を指定します。

追加したBESのサーバステータスファイルの定義（バックエンドサーバ定義bes3の定義）

論理ファイル名 | A系ステータスファイル名※ | B系ステータスファイル名※ | レコード長 | レコード数
bes3sts1 | %PDDIR%¥area¥bes3¥sysstsb3¥bes3sts1a | %PDDIR%¥area¥bes3¥sysstsb3¥bes3sts1b | 4,096 | 800
bes3sts2 | %PDDIR%¥area¥bes3¥sysstsb3¥bes3sts2a | %PDDIR%¥area¥bes3¥sysstsb3¥bes3sts2b | 4,096 | 800
bes3sts3 | %PDDIR%¥area¥bes3¥sysstsb3¥bes3sts3a | %PDDIR%¥area¥bes3¥sysstsb3¥bes3sts3b | 4,096 | 800

注※　%PDDIR%は，追加したサーバマシンのHiRDB運用ディレクトリです。

(7)　追加したBESのシステムログファイルを編集します

システム構成ツリービューで，追加したBESの定義を選択した状態で，メニューの［編集］−［編集］−［システムログファイル］を選択して，［システムログファイル編集］ダイアログボックスを表示し，各システムログファイルの情報を編集します。ここでは，次に示す値を指定します。

追加したBESのシステムログファイルの定義（バックエンドサーバ定義bes3の定義）

ファイルグループ名 | A系システムログファイル名※ | B系システムログファイル名 | レコード数 | ONL
bes3log1 | %PDDIR%¥area¥bes3¥syslogb3¥bes3log1 | 指定なし | 16,000 | ○
bes3log2 | %PDDIR%¥area¥bes3¥syslogb3¥bes3log2 | 指定なし | 16,000 | ○
bes3log3 | %PDDIR%¥area¥bes3¥syslogb3¥bes3log3 | 指定なし | 16,000 | ○
bes3log4 | %PDDIR%¥area¥bes3¥syslogb3¥bes3log4 | 指定なし | 16,000 | ○

（凡例）

○：［ONL（HiRDB稼働開始と同時にオープン）］チェックボックスをチェックしています。

注※　%PDDIR%は，追加したサーバマシンのHiRDB運用ディレクトリです。

(8)　追加したBESのシンクポイントダンプファイルを編集します

システム構成ツリービューで，追加したBES定義を選択した状態で，メニューの［編集］−［編集］−［シンクポイントダンプファイル］を選択して，［シンクポイントダンプファイル編集］ダイアログボックスを表示し，各シンクポイントダンプファイルの情報を編集します。ここでは，次に示す値を指定します。

追加したBESのシンクポイントダンプファイルの定義（バックエンドサーバ定義bes3の定義）

ファイルグループ名 | シンクポイントダンプファイル名※ | レコード数 | ONL
bes3spd1 | %PDDIR%¥area¥bes3¥sysspdb3¥bes3spd1 | 42 | ○
bes3spd2 | %PDDIR%¥area¥bes3¥sysspdb3¥bes3spd2 | 42 | ○
bes3spd3 | %PDDIR%¥area¥bes3¥sysspdb3¥bes3spd3 | 42 | ○

（凡例）

○：［ONL（HiRDB稼働開始と同時にオープン）］チェックボックスをチェックしています。

注※　%PDDIR%は，追加したサーバマシンのHiRDB運用ディレクトリです。

(9)　pd_log_auto_unload_pathオペランドを編集します

追加したBESのpd_log_auto_unload_pathオペランドを編集し，自動ログアンロード機能を使用するようにします。アンロードログファイルの出力先ディレクトリを指定します。ここでは，バックエンドサーバ定義［bes3］に「%PDDIR%¥area¥bes3¥unloadlog¥」を指定します。%PDDIR%は，追加したHiRDBサーバのHiRDB運用ディレクトリです。

(10)　pdwork -vオペランドを編集します

追加したBESのpdwork -vオペランドを編集し，作業表用ファイル用のHiRDBファイルシステム領域の名称を指定します。ここでは，バックエンドサーバ定義［bes3］に「%PDDIR%¥area¥bes3¥rdworkb3」を指定します。%PDDIR%は，追加したHiRDBサーバのHiRDB運用ディレクトリです。

(11)　追加したBESのRDエリアにグローバルバッファを割り当てます

［グローバルバッファ編集］ダイアログボックスを表示し，追加したBESのRDエリアにグローバルバッファを割り当てます。ここでは，特に編集しないで，［残りの全てのRDエリアにグローバルバッファを割り当てる］チェックボックスをチェックします。［残りの全てのRDエリアにグローバルバッファを割り当てる］をチェックする場合，バッファ面数は十分確保してください。［バッファ面数（4〜460000）］を指定しないときは10,000が仮定されます。

(12)　HiRDBシステム定義をチェックし，セットアップを開始します

設定したHiRDBシステム定義をチェックして，問題がなければセットアップを開始します。

3.11　系切り替え機能の設定

3.11.1　系切り替え機能を使用する場合の設定項目

系切り替え機能を使用する場合，システム構成ツリービューで［システム共通定義］を選択した状態で，メニューの［編集］−［編集］−［系切り替え機能の設定］を選択します。［系切り替え機能の設定］ダイアログボックスが表示されるので，HiRDBシステム定義の系切り替え機能に関するオペランドを設定します。

簡易セットアップツールでは次の作業ができます。

HiRDBシステム定義の系切り替え機能に関するオペランドの設定

共有ディスクへのHiRDBファイルシステム領域の作成

HiRDBシステム定義ファイルの予備系への配布

簡易セットアップツールでの系切り替え機能の設定可否を次に示します。

系切り換え機能 | 設定可否
スタンバイ型系切り替え | ユーザサーバホットスタンバイ | ○
高速系切り替え機能 | ○
スタンバイレス型系切り替え | 1：1スタンバイレス型系切り替え機能 | ×
影響分散スタンバイレス型系切り替え機能 | ×

（凡例）

○：設定できます。

×：設定できません。

系切り替え機能の詳細については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(1)　［系切り替え機能の設定］ダイアログボックスで指定する項目

［系切り替え機能の設定］ダイアログボックスで指定する項目について説明します。

項目名 | 説明 | 注意事項
系切り替え機能を使用する | 系切り替え機能を使用するかどうかを指定します。系切り替え機能を使用する場合はチェックします。また，系切り替え機能を使用する場合は，各ユニット制御情報定義（pdutsys）のpd_hostnameオペランドに現用系の標準ホスト名（マシン情報のホスト名）が自動的に設定されます。 | 定義更新時は選択できません。
IPアドレスを引き継ぐ | 系切り替え時にIPアドレスを引き継ぐかどうかを指定します。IPアドレスを引き継ぐ場合はチェックします。 | この項目をチェックすると，次のチェックボックスは選択できません。 ［ユーザサーバホットスタンバイを使用する］ ［高速系切り替え機能を使用する］
HiRDB（パラレルサーバの場合はユニット）の開始方法 | HiRDB（HiRDB/パラレルサーバの場合はユニット）の開始方法を指定します。ここで指定した方法で全ユニットが開始します。 | ［モニタモードの系切り替え］を指定した場合，次のチェックボックスは選択できません。 ［ユーザサーバホットスタンバイを使用する］ ［高速系切り替え機能を使用する］
ユーザサーバホットスタンバイを使用する | ユーザサーバホットスタンバイを使用するかどうかを指定します。使用する場合はチェックします。チェックすると，全ユニットに対してユーザサーバホットスタンバイを使用します。 | 次のように指定していない場合，この項目は選択できません。 IPアドレスを引き継がない サーバモードの系切り替え
高速系切り替え機能を使用する | 高速系切り替え機能を使用するかどうかを指定します。使用する場合はチェックします。チェックすると，全ユニットに対して高速系切り替え機能を使用します。 | 次のように指定していない場合，この項目は選択できません。 IPアドレスを引き継がない サーバモードの系切り替え

［系切り替え機能の設定］ダイアログボックスの［ユニット一覧］には，各ユニットの系切り替えに関する情報が表示されます。［ユニット一覧］でユニットを選択して，［ユニットの系切り替え機能の設定］をクリックすると，［ユニットの系切り替え機能の設定］ダイアログボックスが表示されます。［ユニット一覧］に選択項目がない場合は選択できません。

このダイアログボックスで，現用系のホスト名，予備系のホスト名，ポート番号などを指定します。指定する項目について説明します。

項目名 | 説明 | 注意事項
現用系のホスト名 | 現用系のホスト名を1〜32文字で指定します。IPアドレスを引き継ぐ場合は仮想ネットワーク名（現用系，予備系の両方で共通のホスト名）を指定します。［ホスト名選択］をクリックすると，［hostsファイルからホスト名を選択］ダイアログボックスが表示され，ホスト名を選択できます。 | −
予備系のホスト名 | 予備系のホスト名を1〜32文字で指定します。予備系ホストへのシステム定義ファイルのコピー先となるので必ず指定してください。［ホスト名選択］をクリックすると，［hostsファイルからホスト名を選択］ダイアログボックスが表示され，ホスト名を選択できます。 | −
ポート番号 | 各ユニットのポート番号を指定します。 | HiRDB/シングルサーバの場合は指定できません。
ユーザサーバホットスタンバイを使用する | ユーザサーバホットスタンバイを使用するかどうかを指定します。使用する場合はチェックします。ユーザサーバホットスタンバイを使用する場合，そのユニットはIPアドレスを引き継がない指定になります。ユーザサーバホットスタンバイを使用しない場合，IPアドレスを引き継ぐかどうかは，［系切り替え機能の設定］ダイアログボックスの［IPアドレスを引き継ぐ］の指定に依存します。 | モニタモードの場合は選択できません。
高速系切り替え機能を使用する | 高速系切り替え機能を使用するかどうかを指定します。使用する場合はチェックします。高速系切り替え機能を使用する場合，そのユニットはIPアドレスを引き継がない指定となります。高速切り替え機能を使用しない場合，IPアドレスを引き継ぐかどうかは，［系切り替え機能の設定］ダイアログボックスの［IPアドレスを引き継ぐ］の指定に依存します。 | モニタモードの場合，及びHiRDBが06-02-/Eより前のバージョンの場合は選択できません。

（凡例）−：該当しません。

(2)　系切り替え機能を使用する場合の注意事項

簡易セットアップツールで系切り替えの設定をする場合の注意事項を次に示します。

簡易セットアップツールは現用系マシンで実行してください。

共有ディスクにHiRDBファイルシステム領域を作成する場合，［HiRDBファイルシステム領域編集］ダイアログボックスで，作成先のパスを共有ディスク上のパスに変更してください。なお，系切り替え機能使用時は次の制限があるので，確認してください。

pdfmkfsコマンドの-kオプションにはSVRを指定しない

pdfmkfsコマンドの-iオプションは指定する

簡易セットアップツールは，セットアップ実行時及びHiRDBシステム定義更新時に，自動的に予備系へシステム定義ファイルを配布します。このため，次のようにしてください。

現用系及び予備系でHiRDBのサービス（HiRDB/SingleServer又はHiRDB/ParallelServer）を起動しておく

サービスのログオンをユーザアカウントで起動する

HiRDB/シングルサーバで06-02-/Eより前のバージョンの場合，コマンドプロンプトからpdntenv -ro onを実行し，リモート系コマンドを使用できる状態（予備系への配布ができる状態）にする

系切り替え機能を使用する場合，セットアップが完了してもHiRDBを開始しません。手動で開始してください。このとき，HiRDBはpdstartコマンド実行後に初期設定終了待ち状態になるため，この状態でデータベース初期設定ユティリティ（pdinit）を実行する必要があります。データベース初期設定ユティリティに指定する制御文ファイル名には簡易セットアップツールが作成したファイル（%PDCONFPATH%¥mkinit）を指定します。データベース初期設定ユティリティについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

また，系切り替え機能を使用する場合，サンプルデータベースは自動的に作成されません。サンプルデータベースが必要なときはHiRDB開始後にサンプルデータベース作成用のバッチファイルを実行してください。サンプルデータベース作成用のバッチファイルについては，「サンプルデータベース関連ファイル」を参照してください。

系切り替え機能を使用する場合，システム共通定義（pdsys）のpd_mode_confオペランドがAUTOのときは，自動的にMANUAL2に変更されるので注意してください。

HiRDBファイルシステム領域の作成先となる共有ディスク（物理ディスク）は，クラスタアドミニストレータでオンライン状態にしておいてください。

4　コマンドによる環境設定

この章では，コマンドを使用してHiRDBの環境を設定する方法について説明します。

4.1　コマンドによる環境設定の概要

4.1.1　コマンドによる環境設定手順

(1)　環境設定の前に設計する項目

HiRDBの環境設定をする前に，システムの構成を設計してください。次に示す項目について設計します。

ユニット及びサーバ構成

HiRDBファイルシステム領域の構成

システムファイルの構成

作業表用ファイルの構成

RDエリアの構成

上記の項目の構成を「HiRDB/シングルサーバの設計」又は「HiRDB/パラレルサーバの設計」を参照して決めてください。その後，4.2以降の説明に従ってHiRDBの環境を設定してください。

(2)　環境設定手順

コマンドによるHiRDBの環境設定手順を次の図に示します。

図4‒1　コマンドによるHiRDBの環境設定手順

[picture]

注※1

詳細は，「HiRDBシステム定義の作成」を参照してください。

注※2

詳細は，「HiRDBファイルシステム領域の作成」を参照してください。

注※3

詳細は，「システムファイルの作成」を参照してください。

注※4

詳細は，「システム用RDエリアの作成」を参照してください。

注※5

詳細は，「HiRDBの初期開始」を参照してください。

注※6

詳細は，「ユーザ用RDエリアの作成」以降を参照してください。

設定する内容

データベース初期設定ユティリティ（pdinit）でシステム用RDエリア（マスタディレクトリ用RDエリア，データディレクトリ用RDエリア及びデータディクショナリ用RDエリア）を作成して，HiRDBをまず開始できるようにします。

その後，データベース構成変更ユティリティ（pdmod）で，必要なRDエリア（ユーザ用RDエリア，データディクショナリLOB用RDエリア，ユーザLOB用RDエリア又はリスト用RDエリア）を追加します。

なお，ユーザ用RDエリア，データディクショナリLOB用RDエリア，ユーザLOB用RDエリア及びリスト用RDエリアは，データベース初期設定ユティリティ（pdinit）でシステム用RDエリアと一緒に作成することもできます。

4.2　HiRDBシステム定義の作成

実行者　HiRDB管理者

設計したシステム構成及び稼働環境に従ってHiRDBシステム定義を作成します。ここで説明する項目を次に示します。

HiRDBシステム定義の作成

HiRDBシステム定義の変更方法

UAP環境定義の追加又は変更方法

HiRDBシステム定義の各オペランドについては，マニュアル「HiRDB システム定義」を参照してください。

留意事項

HiRDBシステム定義を作成した後に，pdconfchkコマンドでHiRDBシステム定義の内容の整合性をチェックしてください。このコマンドはHiRDBを開始するために必要な定義の整合性をチェックします。pdconfchkコマンドでチェックできるオペランドについては，マニュアル「HiRDB システム定義」を参照してください。

HiRDBシステム定義ファイルのパーミッションは，ファイルの所有者（HiRDB管理者）にだけ，読み込み権限及び書き込み権限を持たせるように設定，維持するようにしてください。

HiRDBシステム定義を変更した後に，%PDDIR%¥conf下のファイルのバックアップを取得してください。HiRDB運用ディレクトリがあるディスクの障害などに備えて，HiRDB運用ディレクトリ下のファイル（%PDDIR%¥conf下のファイル）のバックアップを取得します。HiRDB運用ディレクトリを回復するには，%PDDIR%¥conf下のファイルのバックアップが必要になります。

4.2.1　HiRDBシステム定義の作成（HiRDB/シングルサーバの場合）

(1)　システム共通定義の作成

システム共通定義にはHiRDBの構成及び共通情報を定義します。システム共通定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥pdsys

システム共通定義では，ユニット構成，サーバ構成，及びグローバルバッファの定義をします。

なお，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド，又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

(2)　ユニット制御情報定義の作成

ユニット制御情報定義にはユニットの実行環境を定義します。ユニット制御情報定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥pdutsys

ユニット制御情報定義ではユニット用ステータスファイルの定義をします。

なお，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド，又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

(3)　シングルサーバ定義の作成

シングルサーバ定義にはシングルサーバの実行環境を定義します。シングルサーバ定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥サーバ名※

HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド，又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

シングルサーバ定義で指定する項目の例を次に示します。

システムログファイル

シンクポイントダンプファイル

サーバ用ステータスファイル

作業表用ファイル

注※

システム共通定義のpdstartオペランドの-sオプションに指定するサーバ名と同じにしてください。「pdstart -s sds1」と指定した場合は，次に示すファイルに格納してください。

%PDDIR%¥conf¥sds1

(4)　UAP環境定義の作成（任意）

UAPの実行環境を定義します。必要に応じてUAP環境定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥pduapenv¥任意の名称※

なお，HiRDB管理者はUAP環境定義を使用するユーザに対して，%PDDIR%¥conf¥pduapenvディレクトリの読み込み権限（r）と実行権限（x）を与えてください。また，UAP環境定義ファイルには読み込み権限（r）を与えてください。

また，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド，又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

UAP環境定義で指定する項目の例を次に示します。

ローカルバッファを使用してアクセスするRDエリア又はインデクスがほかのユーザに使用されている場合のUAPの動作

UAPが使用するローカルバッファ

注※

ファイル名称は先頭がアルファベットの英数字列（最大8文字）にしてください。大文字と小文字は同じ文字とします。例えば，Aとaは同じとします。ファイル名ABCとabcは同じファイル名となります。

(5)　SQL予約語定義の作成（任意）

SQL予約語削除機能を使用する場合，UAPごとに削除する予約語を定義します。必要に応じてSQL予約語定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥pdrsvwd¥任意の名称※

なお，HiRDB管理者はSQL予約語定義を使用するユーザに対して，%PDDIR%¥conf¥pdrsvwdディレクトリの読み込み権限（r）と実行権限（x）を与えてください。また，SQL予約語削除ファイルには読み込み権限（r）を与えてください。

また，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド，又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

注※

ファイル名称は先頭がアルファベットの英数字列（最大8文字）にしてください。大文字と小文字は同じ文字とします。例えば，Aとaは同じとします。ファイル名ABCとabcは同じファイル名となります。

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

HiRDBシステム定義ファイルの構成例を次の図に示します。

図4‒2　HiRDBシステム定義ファイルの構成例（HiRDB/シングルサーバの場合）

[picture]

4.2.2　HiRDBシステム定義の作成（HiRDB/パラレルサーバの場合）

(1)　システム共通定義の作成

システム共通定義にはHiRDBの構成及び共通情報を定義します。システム共通定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥pdsys

各サーバマシンに同じ内容のシステム共通定義を作成してください。

システム共通定義では，ユニット構成，サーバ構成，及びグローバルバッファの定義をします。

なお，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド，又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

(2)　ユニット制御情報定義の作成

ユニット制御情報定義にはユニットの実行環境を定義します。ユニット制御情報定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥pdutsys

各サーバマシンにユニット制御情報定義を作成してください。

ユニット制御情報定義では，ユニット用ステータスファイルの定義をします。

なお，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド，又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

(3)　サーバ共通定義の作成（任意）

サーバ共通定義には，(4)〜(6)で説明するサーバ定義のオペランドの省略値を定義します。必要に応じて各サーバマシンにサーバ共通定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥pdsvrc

次に示す場合にサーバ共通定義を作成すると便利です。

1サーバマシンに定義するサーバ数が多い場合

各サーバの定義内容に共通部分が多い場合

サーバ共通定義で指定した内容は，そのサーバマシンに定義したすべてのサーバに対して有効となります。各サーバの定義内容に共通部分が多い場合は，共通部分をサーバ共通定義で指定し，異なる部分を各サーバ定義で指定することをお勧めします。

また，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

(4)　フロントエンドサーバ定義の作成

フロントエンドサーバ定義にはフロントエンドサーバの実行環境を定義します。フロントエンドサーバ定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥サーバ名※

フロントエンドサーバを定義するサーバマシンに，フロントエンドサーバ定義を作成してください。

フロントエンドサーバ定義で指定する項目の例を次に示します。

フロントエンドサーバ用のシステムログファイル

フロントエンドサーバ用のシンクポイントダンプファイル

フロントエンドサーバ用のステータスファイル

注※

システム共通定義のpdstartオペランドの-sオプションに指定するサーバ名と同じにしてください。例えば，「pdstart -s f001」と指定した場合は，次に示すファイルに格納してください。

%PDDIR%¥conf¥f001

なお，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

(5)　ディクショナリサーバ定義の作成

ディクショナリサーバ定義にはディクショナリサーバの実行環境を定義します。ディクショナリサーバ定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥サーバ名※

ディクショナリサーバを定義するサーバマシンに，ディクショナリサーバ定義を作成してください。

ディクショナリサーバ定義で指定する項目の例を次に示します。

ディクショナリサーバ用のシステムログファイル

ディクショナリサーバ用のシンクポイントダンプファイル

ディクショナリサーバ用のステータスファイル

作業表用ファイル

注※

システム共通定義のpdstartオペランドの-sオプションに指定するサーバ名と同じにしてください。例えば，「pdstart -s dic」と指定した場合は，次に示すファイルに格納してください。

%PDDIR%¥conf¥dic

なお，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

(6)　バックエンドサーバ定義の作成

バックエンドサーバ定義にはバックエンドサーバの実行環境を定義します。バックエンドサーバ定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥サーバ名※

バックエンドサーバを定義するサーバマシンに，バックエンドサーバ定義を作成してください。

バックエンドサーバ定義で指定する項目の例を次に示します。

バックエンドサーバ用のシステムログファイル

バックエンドサーバ用のシンクポイントダンプファイル

バックエンドサーバ用のステータスファイル

作業表用ファイル

注※

システム共通定義のpdstartオペランドの-sオプションに指定するサーバ名と同じにしてください。例えば，「pdstart -s b001」と指定した場合は，次に示すファイルに格納してください。

%PDDIR%¥conf¥b001

なお，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

(7)　UAP環境定義の作成（任意）

UAPの実行環境を定義します。必要に応じてUAP環境定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥pduapenv¥任意の名称※

UAP環境定義はフロントエンドサーバがあるユニットに作成します。マルチフロントエンドサーバの場合は，UAP環境定義を適用したいフロントエンドサーバに定義してください。

なお，HiRDB管理者はUAP環境定義を使用するユーザに対して，%PDDIR%¥conf¥pduapenvディレクトリの読み込み権限（r）と実行権限（x）を与えてください。また，UAP環境定義ファイルには読み込み権限（r）を与えてください。

また，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

UAP環境定義で指定する項目の例を次に示します。

ローカルバッファを使用してアクセスするRDエリア又はインデクスがほかのユーザに使用されている場合のUAPの動作

UAPが使用するローカルバッファ

注※

ファイル名称は先頭がアルファベットの英数字列（最大8文字）にしてください。大文字と小文字は同じ文字とします。例えば，Aとaは同じとします。ファイル名ABCとabcは同じファイル名となります。

(8)　SQL予約語定義の作成（任意）

SQL予約語削除機能を使用する場合，UAPごとに削除する予約語を定義します。必要に応じてSQL予約語定義を作成して次に示すファイルに格納します。

%PDDIR%¥conf¥pdrsvwd¥任意の名称※

SQL予約語定義はフロントエンドサーバがあるユニットに作成します。マルチフロントエンドサーバの場合は，UAP環境定義を適用したいフロントエンドサーバに定義してください。

なお，HiRDB管理者はSQL予約語定義を使用するユーザに対して，%PDDIR%¥conf¥pdrsvwdディレクトリの読み込み権限（r）と実行権限（x）を与えてください。また，SQL予約語削除ファイルには読み込み権限（r）を与えてください。

また，HiRDBのコマンドやユティリティは，この定義ファイルの内容に従って動作するため，HiRDBのコマンド又はユティリティを実行するユーザ（OS上のユーザ）に対して，この定義ファイルに対する読み込み権限（r）を与えてください。

注※

ファイル名称は先頭がアルファベットの英数字列（最大8文字）にしてください。大文字と小文字は同じ文字とします。例えば，Aとaは同じとします。ファイル名ABCとabcは同じファイル名となります。

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

HiRDBシステム定義ファイルの構成例を次の図に示します。

図4‒3　HiRDBシステム定義ファイルの構成例（HiRDB/パラレルサーバの場合）

[picture]

4.2.3　HiRDBシステム定義（UAP環境定義を除く）の変更方法

HiRDBシステム定義を変更する手順を説明します。

留意事項

HiRDBシステム定義を変更した後に，%PDDIR%¥conf下のファイルのバックアップを取得してください。HiRDB運用ディレクトリがあるディスクの障害などに備えて，HiRDB運用ディレクトリ下のファイル（%PDDIR%¥conf下のファイル）のバックアップを取得します。HiRDB運用ディレクトリを回復するには，%PDDIR%¥conf下のファイルのバックアップが必要になります。また，%PDCONFPATH%がHiRDB運用ディレクトリ下にある場合は，同様にバックアップを取得してください。

HiRDB/パラレルサーバの場合，ユニットごとに%PDDIR%¥conf及び%PDCONFPATH%下にサブディレクトリを作成して，HiRDBシステム定義の内容をチェックしてください。

(1)　HiRDBシステム定義の変更手順

HiRDBシステム定義の変更手順を次に示します。なお，%PDDIR%¥confはユニット制御情報定義ファイルを格納しているディレクトリを意味しています。%PDCONFPATH%はそれ以外のHiRDBシステム定義ファイルを格納しているディレクトリを意味しています。

〈手順〉

%PDDIR%¥conf及び%PDCONFPATH%下にサブディレクトリを作成します。この例ではサブディレクトリとしてworkを作成します。

ユニット制御情報定義ファイルを%PDDIR%¥conf¥work下にコピーします。そのほかのHiRDBシステム定義ファイルを%PDCONFPATH%¥work下にコピーします。

%PDDIR%¥conf¥work及び%PDCONFPATH%¥work下にコピーしたHiRDBシステム定義を変更します。

pdconfchk -d workコマンドで，%PDDIR%¥conf¥work及び%PDCONFPATH%¥work下のHiRDBシステム定義の内容をチェックします。エラーがある場合はHiRDBシステム定義を修正して，再度pdconfchkコマンドを実行してください。

pdstopコマンドでHiRDBを正常終了します。

pdlogunldコマンドで，アンロード待ち状態のシステムログファイルをアンロードします。

3で変更したHiRDBシステム定義ファイルを%PDDIR%¥conf又は%PDCONFPATH%下にコピーして，HiRDBシステム定義ファイルを置き換えます。

次に示すオペランドの指定値を変更した場合は，pdloginitコマンドでシステムログファイルを初期化します。

pd_log_dual

pdstart

pdstartコマンドでHiRDBを正常開始します。

(2)　システム構成変更コマンドを使用したHiRDBシステム定義の変更手順

システム構成変更コマンド（pdchgconfコマンド）を使用すると，HiRDBの稼働中にHiRDBシステム定義を変更できるため，HiRDBを終了する必要はありません。ただし，このコマンドを使用する場合はHiRDB Advanced High Availabilityが必要になります。システム構成変更コマンドを使用したHiRDBシステム定義の変更手順を次に示します。

〈手順〉

%PDDIR%¥conf¥chgconfディレクトリを作成します。

使用中のHiRDBシステム定義ファイルを1で作成したディレクトリ下にコピーします。

%PDDIR%¥conf¥chgconf下のHiRDBシステム定義を変更します。

pdconfchkコマンドで，%PDDIR%¥conf¥chgconf下のHiRDBシステム定義のチェックを行います。エラーがある場合はHiRDBシステム定義を修正して，再度pdconfchkコマンドを実行してください。

pdchgconfコマンドで，HiRDBシステム定義を変更後のHiRDBシステム定義に置き換えます。

pdchgconfコマンドを実行すると，使用中（変更前）のHiRDBシステム定義ファイルが%PDDIR%¥conf¥backconf下に退避されます。そして，%PDDIR%¥conf¥chgconf下の変更後のHiRDBシステム定義ファイルが%PDDIR%¥conf下にコピーされます。

注意事項

pdchgconfコマンドの入力後，15分以上トランザクション又はユティリティが動き続けた場合，pdchgconfコマンドが異常終了します。

システム構成変更コマンドを使用したHiRDBシステム定義の変更には制限事項があります。制限事項については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(3)　注意事項

システム共通定義を修正する場合は，すべてのサーバマシンのシステム共通定義を同じように修正してください（HiRDB/パラレルサーバの場合）。

稼働中のHiRDBが使用しているHiRDBシステム定義は，変更又は削除しないでください。変更又は削除した場合，そのHiRDBの動作は保証できません。

HiRDBが計画停止，強制終了，又は異常終了した場合，HiRDBシステム定義のオペランドで変更できるものと変更できないものがあります。詳細については，マニュアル「HiRDB システム定義」を参照してください。

4.2.4　UAP環境定義の追加又は変更方法

UAP環境定義の追加又は変更手順を次に示します。

〈手順〉

UAP環境定義を使用するUAPが実行中でないか確認します。UAPの実行中にUAP環境定義を追加又は変更すると，実行中のUAPは変更前のUAP環境定義が適用されます。ただし，タイミングによっては変更後のUAP環境定義が適用されることがあります。

UAP環境定義を追加又は変更します。

追加又は変更したUAP環境定義を使用してUAPを実行します。

4.3　HiRDBファイルシステム領域の作成

実行者　HiRDB管理者

HiRDBファイルを作成する領域（HiRDBファイルシステム領域）をpdfmkfsコマンドで作成します。

4.3.1　HiRDBファイルシステム領域の種類

HiRDBファイルシステム領域は，次の表に示す用途ごとに作成してください。用途はpdfmkfsコマンドの-kオプションで指定します。

表4‒1　HiRDBファイルシステム領域の種類

項番 | HiRDBファイルシステム領域の種類 | -kオプションの指定
1 | RDエリア用 | DB
2 | 共用RDエリア用 | SDB
3 | システムファイル用 | SYS
4 | 作業表用ファイル用 | WORK
5 | ユティリティ用（Windowsのキャッシュを使用しない） | UTL
6 | リスト用RDエリア用 | WORK

HiRDBを稼働するためには，1，3，及び4のHiRDBファイルシステム領域が必要です。

HiRDBファイルシステム領域の設計方法については，HiRDB/シングルサーバの場合は，「HiRDBファイルシステム領域の設計」，HiRDB/パラレルサーバの場合は，「HiRDBファイルシステム領域の設計」を参照してください。

注意事項

作成するHiRDBファイルシステムの領域長は，パーティションの領域長と等しいか又は小さくしてください。パーティションの領域長より大きくすると，そのパーティションに物理的に続くパーティションを破壊する場合があります。

HiRDBファイルシステム領域の最大長

HiRDBファイルシステム領域の最大長は，1,048,575メガバイトです。

4.3.2　raw I/O機能を使用したHiRDBファイルシステム領域の作成

パーティション又は論理ドライブをファイルと同様にアクセスするWindowsのダイレクトディスクアクセス（raw I/O）を使用するHiRDBファイルシステム領域を作成できます。この機能をraw I/O機能といいます。raw I/O機能を使用すると，HiRDBはWindowsのファイルキャッシュの動作による影響を受けなくなります。そのため，グローバルバッファ制御などによって安定した性能を維持できるようになります。

(1)　raw I/O機能の適用範囲

raw I/O機能を適用できるHiRDBファイルシステム領域のサポート範囲を次に示します。

使用目的※1 | サポートの有無
DB | ○
SDB | ○
SYS | ○
WORK | ○
SVR | ○
UTL※2 | ○

（凡例）

○：raw I/O機能を適用できます。

注※1

pdfmkfsコマンドの-kオプションで指定するHiRDBファイルシステム領域の使用目的です。

注※2

raw I/O機能を適用できるユティリティ用ファイルを次に示します。

バックアップファイル

アンロードログファイル

アンロードデータファイル

差分バックアップ管理ファイル

インデクス情報ファイル

(2)　raw I/O機能を使用するための準備

raw I/O機能を使用する場合，pdfmkfsコマンドを実行する前に，ここで説明する準備が必要です。

(a)　ディスクについて

raw I/O機能では，1ドライブを1HiRDBファイルシステム領域に割り当てます。このとき，1ドライブは1ディスクで構成されている必要があります。1ディスクは，OSから一つの記憶域として見えればよいため，ハードウェアRAIDは使用できますが，1ドライブを複数ディスクで構成するソフトウェアRAIDは使用できません。

なお，raw I/O機能を使用できるドライブは，セクタ長512バイトの固定ディスクだけです。

ディスクの種類とパーティションスタイルの組み合わせによるHiRDBのサポート状況を次に示します。

ディスクの種類 | パーティションスタイル | サポート状況
32ビットモードのHiRDB | 64ビットモードのHiRDB
ベーシックディスク | MBR（マスタブートレコード） | ○ | ○
GPT（GUIDパーティションテーブル） | × | ○
ダイナミックディスク | MBR（マスタブートレコード） | × | ×
GPT（GUIDパーティションテーブル） | × | ×

（凡例）

○：サポートしています。

×：サポートしていません。

(b)　パーティション及び論理ドライブの作成方法

raw I/O機能を使用するには，未フォーマット状態のパーティション，又は論理ドライブを用意します。このとき，1ドライブは，1プライマリパーティション，又は1論理ドライブで構成されている必要があります。

パーティションはWindowsの［コンピュータの管理］−［ディスクの管理］で作成します。パーティションのサイズには，HiRDBファイルシステム領域のサイズより大きい値を指定してください。ただし，パーティションのサイズを大きくし過ぎると，むだな領域ができますので，注意してください。

また，作成したパーティションには，ドライブ文字を割り当ててください。

パーティション，又は論理ドライブの作成方法，及びドライブ文字の割り当て方法の詳細については，Windowsの［ディスクの管理］のヘルプを参照してください。

4.3.3　例題1（RDエリア用のHiRDBファイルシステム領域の作成）

RDエリア用のHiRDBファイルシステム領域を作成する例を次に示します。

（例）

RDエリア用のHiRDBファイルシステム領域を作成します。

pdfmkfs -n 50 -l 10 -k DB -i C:¥dbarea01

〔説明〕

-n：HiRDBファイルシステム領域の領域長をメガバイト単位で指定します。

-l：HiRDBファイルシステム領域内に作成するHiRDBファイル数の上限値を指定します。

-k：HiRDBファイルシステム領域の用途を指定します。

RDエリア用のHiRDBファイルシステム領域なので，DBを指定します。

-i：HiRDBファイルシステム領域の全領域を初期化する場合に指定します。

-iオプションを指定すると，領域全体を確保します。-iオプションを省略すると，HiRDBファイルシステム領域の管理情報だけを作成します。

C:¥dbarea01：作成するHiRDBファイルシステム領域の名称を指定します。

コマンドの実行後，実行結果が正しいかどうかを確認することをお勧めします。コマンドの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

4.3.4　例題2（システムファイル用のHiRDBファイルシステム領域の作成）

システムファイル用のHiRDBファイルシステム領域を作成する例を次に示します。

（例）

システムファイル用のHiRDBファイルシステム領域を作成します。

pdfmkfs -n 50 -l 20 -k SYS -i C:¥sysarea01

〔説明〕

-n：HiRDBファイルシステム領域の領域長をメガバイト単位で指定します。

-l：HiRDBファイルシステム領域内に作成するHiRDBファイル数の上限値を指定します。

-k：HiRDBファイルシステム領域の用途を指定します。

システムファイル用のHiRDBファイルシステム領域なので，SYSを指定します。

-i：HiRDBファイルシステム領域の全領域を初期化する場合に指定します。

-iオプションを指定すると，領域全体を確保します。-iオプションを省略すると，HiRDBファイルシステム領域の管理情報だけを作成します。

C:¥sysarea01：作成するHiRDBファイルシステム領域の名称を指定します。

コマンドの実行後，実行結果が正しいかどうかを確認することをお勧めします。コマンドの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

4.3.5　例題3（作業表用ファイル用のHiRDBファイルシステム領域の作成）

作業表用ファイル用のHiRDBファイルシステム領域を作成する例を次に示します。

（例）

作業表用ファイル用のHiRDBファイルシステム領域を作成します。

pdfmkfs -n 50 -l 20 -k WORK -e 3300 -i -a C:¥workarea01

〔説明〕

-n：HiRDBファイルシステム領域の領域長をメガバイト単位で指定します。

領域長の見積もり方法については，「作業表用ファイルの容量の見積もり」を参照してください。

-l：HiRDBファイルシステム領域内に作成するHiRDBファイル数の上限値を指定します。

-k：HiRDBファイルシステム領域の用途を指定します。

作業表用ファイル用のHiRDBファイルシステム領域なので，WORKを指定します。

-e：HiRDBファイルシステム領域内のHiRDBファイルの増分回数を指定します。

-i：HiRDBファイルシステム領域の全領域を初期化する場合に指定します。

-iオプションを指定すると，領域全体を確保します。-iオプションを省略すると，HiRDBファイルシステム領域の管理情報だけを作成します。

-a：自動的にHiRDBファイルシステム領域を拡張するときに指定します。

RDエリアの自動増分や作業表を使用するSQLの実行などで，-nオプションで指定したサイズを超えても，自動的に必要な分だけHiRDBファイルシステム領域を拡張するときに指定します。

C:¥workarea01：

作成するHiRDBファイルシステム領域の名称を指定します。HiRDBシステム定義のpdworkオペランドで指定した名称を指定します。

コマンドの実行後，実行結果が正しいかどうかを確認することをお勧めします。コマンドの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

4.3.6　例題4（ユティリティ用のHiRDBファイルシステム領域の作成）

ユティリティ用のHiRDBファイルシステム領域を作成する例を次に示します。ユティリティ用のHiRDBファイルシステム領域には，次に示すファイルを作成します。

バックアップファイル

アンロードデータファイル

アンロードログファイル

差分バックアップ管理ファイル

インデクス情報ファイル

（例）

ユティリティ用のHiRDBファイルシステム領域を作成します。

pdfmkfs -n 50 -l 10 -k UTL -i C:¥utlarea01

〔説明〕

-n：HiRDBファイルシステム領域の領域長をメガバイト単位で指定します。

-l：HiRDBファイルシステム領域内に作成するHiRDBファイル数の上限値を指定します。

-k：HiRDBファイルシステム領域の用途を指定します。

ユティリティ用のHiRDBファイルシステム領域なので，UTLを指定します。

-i：HiRDBファイルシステム領域の全領域を初期化する場合に指定します。

-iオプションを指定すると，領域全体を確保します。-iオプションを省略すると，HiRDBファイルシステム領域の管理情報だけを作成します。

C:¥utlarea01：作成するHiRDBファイルシステム領域の名称を指定します。

コマンドの実行後，実行結果が正しいかどうかを確認することをお勧めします。コマンドの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

4.3.7　例題5（リスト用RDエリア用のHiRDBファイルシステム領域の作成）

リスト用RDエリア用のHiRDBファイルシステム領域を作成する例を次に示します。

（例）

リスト用RDエリア用のHiRDBファイルシステム領域を作成します。

pdfmkfs -n 50 -l 10 -k WORK -i C:¥listarea01

〔説明〕

-n：HiRDBファイルシステム領域の領域長をメガバイト単位で指定します。

-l：HiRDBファイルシステム領域内に作成するHiRDBファイル数の上限値を指定します。

-k：HiRDBファイルシステム領域の用途を指定します。

リスト用RDエリア用のHiRDBファイルシステム領域なので，WORKを指定します。

-i：HiRDBファイルシステム領域の全領域を初期化する場合に指定します。

-iオプションを指定すると，領域全体を確保します。-iオプションを省略すると，HiRDBファイルシステム領域の管理情報だけを作成します。

C:¥listarea01：作成するHiRDBファイルシステム領域の名称を指定します。

コマンドの実行後，実行結果が正しいかどうかを確認することをお勧めします。コマンドの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

4.3.8　例題6（raw I/O機能を使用するHiRDBファイルシステム領域の作成）

raw I/O機能を使用するHiRDBファイルシステム領域を作成するには，次に示す形式でHiRDBファイルシステム領域名を指定します。

¥¥.¥ドライブ名:

ドライブ名には，事前に準備したドライブ文字を指定します。

（例）

RDエリア用のHiRDBファイルシステム領域を作成します。

pdfmkfs -n 100 -l 50 -e 1 -k DB ¥¥.¥J:

〔説明〕

-n：HiRDBファイルシステム領域の領域長をメガバイト単位で指定します。

-l：HiRDBファイルシステム領域内に作成するHiRDBファイル数の上限値を指定します。

-e：HiRDBファイルシステム領域内のHiRDBファイルの増分回数を指定します。

-k：HiRDBファイルシステム領域の用途を指定します。

RDエリア用のHiRDBファイルシステム領域なので，DBを指定します。

¥¥.¥J:：論理ドライブJをHiRDBファイルシステム領域として作成します。

4.4　システムファイルの作成

実行者　HiRDB管理者

「HiRDBファイルシステム領域の作成」で作成したシステムファイル用のHiRDBファイルシステム領域に，次に示すファイル（システムファイル）を作成します。

システムログファイル

シンクポイントダンプファイル

ステータスファイル

システムファイルの設計方法については，HiRDB/シングルサーバの場合は「システムファイルの設計」，HiRDB/パラレルサーバの場合は「システムファイルの設計」を参照してください。

4.4.1　システムログファイルの作成

pdloginitコマンドで，HiRDBファイルシステム領域にシステムログファイルを作成します。

（例）

HiRDBファイルシステム領域（C:¥sysarea01）にシステムログファイル（log01）を作成します。

pdloginit -d sys -s b001 -f C:¥sysarea01¥log01 -n 1024

〔説明〕

-d sys：システムログファイルを作成する場合に指定します。

-s：システムログファイルを作成するサーバの名称を指定します。

HiRDB/シングルサーバの場合は指定は不要です。

-f：システムログファイルの名称を指定します。

HiRDBシステム定義のサーバ定義のpdlogadpf -d sysオペランドで指定した名称を指定します。

-n：システムログファイルのレコード数を指定します。

1システムログファイルの容量はレコード長×レコード数（バイト）になります。システムログファイルのレコード長は通常1024バイトですが，pd_log_rec_lengオペランドを指定している場合はpd_log_rec_lengオペランドの指定値になります。

コマンドの実行後，実行結果が正しいかどうか確認することをお勧めします。コマンドの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

HiRDBシステム定義との関係

HiRDBシステム定義のサーバ定義の次に示すオペランドと関係があります。

pdlogadfg -d sys

pdlogadpf -d sys

作成したシステムログファイルは，これらのオペランドで定義しておく必要があります。

4.4.2　シンクポイントダンプファイルの作成

pdloginitコマンドで，HiRDBファイルシステム領域にシンクポイントダンプファイルを作成します。

（例）

HiRDBファイルシステム領域（C:¥sysarea01）にシンクポイントダンプファイル（sync01）を作成します。

pdloginit -d spd -s b001 -f C:¥sysarea01¥sync01 -n 64

〔説明〕

-d spd：シンクポイントダンプファイルを作成する場合に指定します。

-s：シンクポイントダンプファイルを作成するサーバの名称を指定します。

HiRDB/シングルサーバの場合は指定は不要です。

-f：シンクポイントダンプファイルの名称を指定します。

HiRDBシステム定義のサーバ定義のpdlogadpf -d spdオペランドで指定した名称を指定します。

-n：シンクポイントダンプファイルのレコード数を指定します。

1シンクポイントダンプファイルの容量は4096×レコード数（バイト）になります。

コマンドの実行後，実行結果が正しいかどうか確認することをお勧めします。コマンドの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

HiRDBシステム定義との関係

HiRDBシステム定義のサーバ定義の次に示すオペランドと関係があります。

pdlogadfg -d spd

pdlogadpf -d spd

作成したシンクポイントダンプファイルは，これらのオペランドで定義しておく必要があります。

4.4.3　ステータスファイルの作成

pdstsinitコマンドで，HiRDBファイルシステム領域にステータスファイルを作成します。ステータスファイルは，ユニット用ステータスファイルとサーバ用ステータスファイルの両方を作成します。

（例）

HiRDBファイルシステム領域（C:¥sysarea01）にサーバ用ステータスファイル（sts01）を作成します。

pdstsinit -s b001 -f C:¥sysarea01¥sts01 -l 4096 -c 256

〔説明〕

-s：サーバ用ステータスファイルを作成するサーバの名称を指定します。

-f：サーバ用ステータスファイルの名称を指定します。

HiRDBシステム定義のサーバ定義のpd_sts_file_nameオペランドで指定した名称を指定します。

-l：ステータスファイルのレコード長を指定します。

-c：ステータスファイルのレコード数を指定します。

1ステータスファイルの容量はレコード長×レコード数（バイト）になります。

コマンドの実行後，実行結果が正しいかどうか確認することをお勧めします。コマンドの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

HiRDBシステム定義との関係

HiRDBシステム定義の次に示すオペランドと関係があります。

pd_syssts_file_name（ユニット用ステータスファイル）

pd_sts_file_name（サーバ用ステータスファイル）

作成したステータスファイルは，これらのオペランドで定義しておく必要があります。

4.4.4　システムファイルの作成例（HiRDB/シングルサーバの場合）

次に示すシステム構成のシステムファイルの作成例を説明します。

HiRDBファイルシステム領域の構成

(1)　システムファイルの定義（HiRDBシステム定義の指定）

HiRDBシステム定義にシステムファイルを定義します。

(a)　ユニット制御情報定義（ユニット用ステータスファイルの定義）

ユニット制御情報定義にユニット用ステータスファイルを定義します。

定義例

set pd_syssts_file_name_1="usts1","C:¥sysarea01¥usts01a"¥
                                 ,"C:¥sysarea02¥usts01b"
set pd_syssts_file_name_2="usts2","C:¥sysarea02¥usts02a"¥
                                 ,"C:¥sysarea03¥usts02b"
set pd_syssts_file_name_3="usts3","C:¥sysarea03¥usts03a"¥
                                 ,"C:¥sysarea01¥usts03b"

(b)　シングルサーバ定義

シングルサーバ定義にシステムログファイル，シンクポイントダンプファイル，及びサーバ用ステータスファイルを定義します。

システムログファイルの定義例

pdlogadfg -d sys -g log1 ONL
pdlogadfg -d sys -g log2 ONL
pdlogadfg -d sys -g log3 ONL
pdlogadpf -d sys -g log1 -a "C:¥sysarea01¥log01a"¥
                         -b "C:¥sysarea02¥log01b"
pdlogadpf -d sys -g log2 -a "C:¥sysarea02¥log02a"¥
                         -b "C:¥sysarea03¥log02b"
pdlogadpf -d sys -g log3 -a "C:¥sysarea03¥log03a"¥
                         -b "C:¥sysarea01¥log03b"

シンクポイントダンプファイルの定義例

pdlogadfg -d spd -g sync1 ONL
pdlogadfg -d spd -g sync2 ONL
pdlogadfg -d spd -g sync3 ONL
pdlogadpf -d spd -g sync1 -a "C:¥sysarea01¥sync01"
pdlogadpf -d spd -g sync2 -a "C:¥sysarea02¥sync02"
pdlogadpf -d spd -g sync3 -a "C:¥sysarea03¥sync03"

サーバ用ステータスファイルの定義例

set pd_sts_file_name_1="ssts1","C:¥sysarea01¥ssts01a"¥
                              ,"C:¥sysarea02¥ssts01b"
set pd_sts_file_name_2="ssts2","C:¥sysarea02¥ssts02a"¥
                              ,"C:¥sysarea03¥ssts02b"
set pd_sts_file_name_3="ssts3","C:¥sysarea03¥ssts03a"¥
                              ,"C:¥sysarea01¥ssts03b"

(2)　HiRDBファイルシステム領域の作成

pdfmkfsコマンドでHiRDBファイルシステム領域を作成します。

コマンドの入力例

pdfmkfs -n 50 -l 20 -i -k SYS C:¥sysarea01
pdfmkfs -n 50 -l 20 -i -k SYS C:¥sysarea02
pdfmkfs -n 50 -l 20 -i -k SYS C:¥sysarea03

(3)　システムファイルの作成

(a)　システムログファイルの作成

pdloginitコマンドでシステムログファイルを作成します。

コマンドの入力例

pdloginit -d sys -f C:¥sysarea01¥log01a -n 1024
pdloginit -d sys -f C:¥sysarea01¥log03b -n 1024
pdloginit -d sys -f C:¥sysarea02¥log02a -n 1024
pdloginit -d sys -f C:¥sysarea02¥log01b -n 1024
pdloginit -d sys -f C:¥sysarea03¥log03a -n 1024
pdloginit -d sys -f C:¥sysarea03¥log02b -n 1024

(b)　シンクポイントダンプファイルの作成

pdloginitコマンドでシンクポイントダンプファイルを作成します。

コマンドの入力例

pdloginit -d spd -f C:¥sysarea01¥sync01 -n 64
pdloginit -d spd -f C:¥sysarea02¥sync02 -n 64
pdloginit -d spd -f C:¥sysarea03¥sync03 -n 64

(c)　サーバ用ステータスファイルの作成

pdstsinitコマンドでサーバ用ステータスファイルを作成します。

コマンドの入力例

pdstsinit -s sds1 -f C:¥sysarea01¥ssts01a -l 4096 -c 256
pdstsinit -s sds1 -f C:¥sysarea01¥ssts03b -l 4096 -c 256
pdstsinit -s sds1 -f C:¥sysarea02¥ssts02a -l 4096 -c 256
pdstsinit -s sds1 -f C:¥sysarea02¥ssts01b -l 4096 -c 256
pdstsinit -s sds1 -f C:¥sysarea03¥ssts03a -l 4096 -c 256
pdstsinit -s sds1 -f C:¥sysarea03¥ssts02b -l 4096 -c 256

(d)　ユニット用ステータスファイルの作成

pdstsinitコマンドでユニット用ステータスファイルを作成します。

コマンドの入力例

pdstsinit -u unt1 -f C:¥sysarea01¥usts01a -l 4096 -c 256
pdstsinit -u unt1 -f C:¥sysarea01¥usts03b -l 4096 -c 256
pdstsinit -u unt1 -f C:¥sysarea02¥usts02a -l 4096 -c 256
pdstsinit -u unt1 -f C:¥sysarea02¥usts01b -l 4096 -c 256
pdstsinit -u unt1 -f C:¥sysarea03¥usts03a -l 4096 -c 256
pdstsinit -u unt1 -f C:¥sysarea03¥usts02b -l 4096 -c 256

4.4.5　システムファイルの作成例（HiRDB/パラレルサーバの場合）

次に示すシステム構成のシステムファイルの作成例を説明します。

（凡例）

MGR：システムマネジャ

FES：フロントエンドサーバ

DS：ディクショナリサーバ

BES：バックエンドサーバ

HiRDBファイルシステム領域の構成

〔説明〕

ユニットAのHiRDBファイルシステム領域の構成例です。以降の例題では，ユニットAのシステムファイルの作成例についてだけ説明します。

(1)　システムファイルの定義（HiRDBシステム定義の指定）

HiRDBシステム定義にシステムファイルを定義します。

(a)　ユニット制御情報定義（ユニット用ステータスファイルの定義）

ユニット制御情報定義にユニット用ステータスファイルを定義します。

定義例

set pd_syssts_file_name_1="u1sts1","C:¥sysarea01¥u1sts01a"¥
                                  ,"C:¥sysarea02¥u1sts01b"
set pd_syssts_file_name_2="u1sts2","C:¥sysarea02¥u1sts02a"¥
                                  ,"C:¥sysarea03¥u1sts02b"
set pd_syssts_file_name_3="u1sts3","C:¥sysarea03¥u1sts03a"¥
                                  ,"C:¥sysarea01¥u1sts03b"

(b)　FES1のフロントエンドサーバ定義

FES1のフロントエンドサーバ定義にシステムログファイル，シンクポイントダンプファイル，及びサーバ用ステータスファイルを定義します。

システムログファイルの定義例

pdlogadfg -d sys -g f1log1 ONL
pdlogadfg -d sys -g f1log2 ONL
pdlogadfg -d sys -g f1log3 ONL
pdlogadpf -d sys -g f1log1 -a "C:¥sysarea01¥f1log01a"¥
                           -b "C:¥sysarea02¥f1log01b"
pdlogadpf -d sys -g f1log2 -a "C:¥sysarea02¥f1log02a"¥
                           -b "C:¥sysarea03¥f1log02b"
pdlogadpf -d sys -g f1log3 -a "C:¥sysarea03¥f1log03a"¥
                           -b "C:¥sysarea01¥f1log03b"

シンクポイントダンプファイルの定義例

pdlogadfg -d spd -g f1sync1 ONL
pdlogadfg -d spd -g f1sync2 ONL
pdlogadfg -d spd -g f1sync3 ONL
pdlogadpf -d spd -g f1sync1 -a "C:¥sysarea01¥f1sync01"
pdlogadpf -d spd -g f1sync2 -a "C:¥sysarea02¥f1sync02"
pdlogadpf -d spd -g f1sync3 -a "C:¥sysarea03¥f1sync03"

サーバ用ステータスファイルの定義例

set pd_sts_file_name_1="f1sts1","C:¥sysarea01¥f1sts01a"¥
                               ,"C:¥sysarea02¥f1sts01b"
set pd_sts_file_name_2="f1sts2","C:¥sysarea02¥f1sts02a"¥
                               ,"C:¥sysarea03¥f1sts02b"
set pd_sts_file_name_3="f1sts3","C:¥sysarea03¥f1sts03a"¥
                               ,"C:¥sysarea01¥f1sts03b"

(c)　BES1のバックエンドサーバ定義

BES1のバックエンドサーバ定義にシステムログファイル，シンクポイントダンプファイル，及びサーバ用ステータスファイルを定義します。

システムログファイルの定義例

pdlogadfg -d sys -g b1log1 ONL
pdlogadfg -d sys -g b1log2 ONL
pdlogadfg -d sys -g b1log3 ONL
pdlogadpf -d sys -g b1log1 -a "C:¥sysarea01¥b1log01a"¥
                           -b "C:¥sysarea02¥b1log01b"
pdlogadpf -d sys -g b1log2 -a "C:¥sysarea02¥b1log02a"¥
                           -b "C:¥sysarea03¥b1log02b"
pdlogadpf -d sys -g b1log3 -a "C:¥sysarea03¥b1log03a"¥
                           -b "C:¥sysarea01¥b1log03b"

シンクポイントダンプファイルの定義例

pdlogadfg -d spd -g b1sync1 ONL
pdlogadfg -d spd -g b1sync2 ONL
pdlogadfg -d spd -g b1sync3 ONL
pdlogadpf -d spd -g b1sync1 -a "C:¥sysarea01¥b1sync01"
pdlogadpf -d spd -g b1sync2 -a "C:¥sysarea02¥b1sync02"
pdlogadpf -d spd -g b1sync3 -a "C:¥sysarea03¥b1sync03"

サーバ用ステータスファイルの定義例

set pd_sts_file_name_1="b1sts1","C:¥sysarea01¥b1sts01a"¥
                               ,"C:¥sysarea02¥b1sts01b"
set pd_sts_file_name_2="b1sts2","C:¥sysarea02¥b1sts02a"¥
                               ,"C:¥sysarea03¥b1sts02b"
set pd_sts_file_name_3="b1sts3","C:¥sysarea03¥b1sts03a"¥
                               ,"C:¥sysarea01¥b1sts03b"

(d)　BES2のバックエンドサーバ定義

BES2のバックエンドサーバ定義にシステムログファイル，シンクポイントダンプファイル，及びサーバ用ステータスファイルを定義します。

システムログファイルの定義例

pdlogadfg -d sys -g b2log1 ONL
pdlogadfg -d sys -g b2log2 ONL
pdlogadfg -d sys -g b2log3 ONL
pdlogadpf -d sys -g b2log1 -a "C:¥sysarea01¥b2log01a"¥
                           -b "C:¥sysarea02¥b2log01b"
pdlogadpf -d sys -g b2log2 -a "C:¥sysarea02¥b2log02a"¥
                           -b "C:¥sysarea03¥b2log02b"
pdlogadpf -d sys -g b2log3 -a "C:¥sysarea03¥b2log03a"¥
                           -b "C:¥sysarea01¥b2log03b"

シンクポイントダンプファイルの定義例

pdlogadfg -d spd -g b2sync1 ONL
pdlogadfg -d spd -g b2sync2 ONL
pdlogadfg -d spd -g b2sync3 ONL
pdlogadpf -d spd -g b2sync1 -a "C:¥sysarea01¥b2sync01"
pdlogadpf -d spd -g b2sync2 -a "C:¥sysarea02¥b2sync02"
pdlogadpf -d spd -g b2sync3 -a "C:¥sysarea03¥b2sync03"

サーバ用ステータスファイルの定義例

set pd_sts_file_name_1="b2sts1","C:¥sysarea01¥b2sts01a"¥
                               ,"C:¥sysarea02¥b2sts01b"
set pd_sts_file_name_2="b2sts2","C:¥sysarea02¥b2sts02a"¥
                               ,"C:¥sysarea03¥b2sts02b"
set pd_sts_file_name_3="b2sts3","C:¥sysarea03¥b2sts03a"¥
                               ,"C:¥sysarea01¥b2sts03b"

(2)　HiRDBファイルシステム領域の作成

pdfmkfsコマンドでHiRDBファイルシステム領域を作成します。

コマンドの入力例

pdfmkfs -n 50 -l 20 -i -k SYS C:¥sysarea01
pdfmkfs -n 50 -l 20 -i -k SYS C:¥sysarea02
pdfmkfs -n 50 -l 20 -i -k SYS C:¥sysarea03

(3)　システムファイルの作成

(a)　システムログファイルの作成

pdloginitコマンドでシステムログファイルを作成します。

コマンドの入力例（FES1用）

pdloginit -d sys -s f001 -f C:¥sysarea01¥f1log01a -n 1024
pdloginit -d sys -s f001 -f C:¥sysarea01¥f1log03b -n 1024
pdloginit -d sys -s f001 -f C:¥sysarea02¥f1log02a -n 1024
pdloginit -d sys -s f001 -f C:¥sysarea02¥f1log01b -n 1024
pdloginit -d sys -s f001 -f C:¥sysarea03¥f1log03a -n 1024
pdloginit -d sys -s f001 -f C:¥sysarea03¥f1log02b -n 1024

コマンドの入力例（BES1用）

pdloginit -d sys -s b001 -f C:¥sysarea01¥b1log01a -n 1024
pdloginit -d sys -s b001 -f C:¥sysarea01¥b1log03b -n 1024
pdloginit -d sys -s b001 -f C:¥sysarea02¥b1log02a -n 1024
pdloginit -d sys -s b001 -f C:¥sysarea02¥b1log01b -n 1024
pdloginit -d sys -s b001 -f C:¥sysarea03¥b1log03a -n 1024
pdloginit -d sys -s b001 -f C:¥sysarea03¥b1log02b -n 1024

コマンドの入力例（BES2用）

pdloginit -d sys -s b002 -f C:¥sysarea01¥b2log01a -n 1024
pdloginit -d sys -s b002 -f C:¥sysarea01¥b2log03b -n 1024
pdloginit -d sys -s b002 -f C:¥sysarea02¥b2log02a -n 1024
pdloginit -d sys -s b002 -f C:¥sysarea02¥b2log01b -n 1024
pdloginit -d sys -s b002 -f C:¥sysarea03¥b2log03a -n 1024
pdloginit -d sys -s b002 -f C:¥¥syarea03¥b2log02b -n 1024

(b)　シンクポイントダンプファイルの作成

pdloginitコマンドでシンクポイントダンプファイルを作成します。

コマンドの入力例（FES1用）

pdloginit -d spd -s f001 -f C:¥sysarea01¥f1sync01 -n 64
pdloginit -d spd -s f001 -f C:¥sysarea02¥f1sync02 -n 64
pdloginit -d spd -s f001 -f C:¥sysarea03¥f1sync03 -n 64

コマンドの入力例（BES1用）

pdloginit -d spd -s b001 -f C:¥sysarea01¥b1sync01 -n 64
pdloginit -d spd -s b001 -f C:¥sysarea02¥b1sync02 -n 64
pdloginit -d spd -s b001 -f C:¥sysarea03¥b1sync03 -n 64

コマンドの入力例（BES2用）

pdloginit -d spd -s b002 -f C:¥sysarea01¥b2sync01 -n 64
pdloginit -d spd -s b002 -f C:¥sysarea02¥b2sync02 -n 64
pdloginit -d spd -s b002 -f C:¥sysarea03¥b2sync03 -n 64

(c)　サーバ用ステータスファイルの作成

pdstsinitコマンドでサーバ用ステータスファイルを作成します。

コマンドの入力例（FES1用）

pdstsinit -s f001 -f C:¥sysarea01¥f1sts01a -l 4096 -c 256
pdstsinit -s f001 -f C:¥sysarea01¥f1sts03b -l 4096 -c 256
pdstsinit -s f001 -f C:¥sysarea02¥f1sts02a -l 4096 -c 256
pdstsinit -s f001 -f C:¥sysarea02¥f1sts01b -l 4096 -c 256
pdstsinit -s f001 -f C:¥sysarea03¥f1sts03a -l 4096 -c 256
pdstsinit -s f001 -f C:¥sysarea03¥f1sts02b -l 4096 -c 256

コマンドの入力例（BES1用）

pdstsinit -s b001 -f C:¥sysarea01¥b1sts01a -l 4096 -c 256
pdstsinit -s b001 -f C:¥sysarea01¥b1sts03b -l 4096 -c 256
pdstsinit -s b001 -f C:¥sysarea02¥b1sts02a -l 4096 -c 256
pdstsinit -s b001 -f C:¥sysarea02¥b1sts01b -l 4096 -c 256
pdstsinit -s b001 -f C:¥sysarea03¥b1sts03a -l 4096 -c 256
pdstsinit -s b001 -f C:¥sysarea03¥b1sts02b -l 4096 -c 256

コマンドの入力例（BES2用）

pdstsinit -s b002 -f C:¥sysarea01¥b2sts01a -l 4096 -c 256
pdstsinit -s b002 -f C:¥sysarea01¥b2sts03b -l 4096 -c 256
pdstsinit -s b002 -f C:¥sysarea02¥b2sts02a -l 4096 -c 256
pdstsinit -s b002 -f C:¥sysarea02¥b2sts01b -l 4096 -c 256
pdstsinit -s b002 -f C:¥sysarea03¥b2sts03a -l 4096 -c 256
pdstsinit -s b002 -f C:¥sysarea03¥b2sts02b -l 4096 -c 256

(d)　ユニット用ステータスファイルの作成

pdstsinitコマンドでユニット用ステータスファイルを作成します。

コマンドの入力例

pdstsinit -u unt1 -f C:¥sysarea01¥u1sts01a -l 4096 -c 256
pdstsinit -u unt1 -f C:¥sysarea01¥u1sts03b -l 4096 -c 256
pdstsinit -u unt1 -f C:¥sysarea02¥u1sts02a -l 4096 -c 256
pdstsinit -u unt1 -f C:¥sysarea02¥u1sts01b -l 4096 -c 256
pdstsinit -u unt1 -f C:¥sysarea03¥u1sts03a -l 4096 -c 256
pdstsinit -u unt1 -f C:¥sysarea03¥u1sts02b -l 4096 -c 256

4.5　システム用RDエリアの作成

実行者　HiRDB管理者

HiRDBを初期開始するときは，データベース初期設定ユティリティ（pdinit）でシステム用RDエリアを作成する必要があります。

データベース初期設定ユティリティ（pdinit）は，HiRDBを初期開始する場合（インストールしてから最初にpdstartコマンドを実行するとき）に，コマンドの入力要求が来たときに実行します。それ以外のタイミングでデータベース初期設定ユティリティ（pdinit）は実行できません。

ここでは，データベース初期設定ユティリティ（pdinit）の引数として指定する制御文ファイルの内容とデータベース初期設定ユティリティ（pdinit）の実行例について説明します。システム用RDエリアは，create rdarea文で作成します。

システム用RDエリアとは，次に示すRDエリアのことです。

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

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

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

4.5.1　基本事項

システム用RDエリアは，「HiRDBファイルシステム領域の作成」で作成したRDエリア用のHiRDBファイルシステム領域に作成します。

HiRDB/パラレルサーバの場合，ディクショナリサーバを定義したサーバマシンのHiRDBファイルシステム領域にシステム用RDエリアを作成します。

システム用RDエリアの設計方法については，HiRDB/シングルサーバの場合は「RDエリアの配置」を，HiRDB/パラレルサーバの場合は「RDエリアの配置」を参照してください。

HiRDB/パラレルサーバの場合，システムマネジャを定義したサーバマシンでデータベース初期設定ユティリティ（pdinit）を実行してください。

ここの説明では，データベース初期設定ユティリティ（pdinit）のcreate rdarea文でシステム用RDエリアしか作成しません。これはシステム用RDエリアがHiRDBの稼働に必要であるためです。ただし，次に示すRDエリアもデータベース初期設定ユティリティ（pdinit）のcreate rdarea文で定義できます。

ユーザ用RDエリア

ユーザLOB用RDエリア

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

リスト用RDエリア

4.5.2　例題1（HiRDB/シングルサーバの場合）

次に示すRDエリア用のHiRDBファイルシステム領域に，システム用RDエリアを作成します。

C:¥rdarea01

(1)　制御文ファイルの作成

データベース初期設定ユティリティ（pdinit）の引数に指定する制御文ファイルを作成します。制御文ファイルを作成する場所は任意ですが，ここでは次に示すファイル名で作成することにします。

C:¥hirdb¥pdinit01

制御文ファイルの内容

create rdarea RDMAST for masterdirectory                      1
    file name "C:¥rdarea01¥rdmast01"
          initial 10 segments;
create rdarea RDDIR for datadirectory                         2
    file name "C:¥rdarea01¥rddir01"
          initial 5 segments;
create rdarea RDDIC for datadictionary                        3
    extension use 50 segments
    file name "C:¥rdarea01¥rddic01"
          initial 20 segments;

〔説明〕

マスタディレクトリ用RDエリアの定義

HiRDBファイルシステム領域にrdmast01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を10とします。

データディレクトリ用RDエリアの定義

HiRDBファイルシステム領域にrddir01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を5とします。

データディクショナリ用RDエリアの定義

HiRDBファイルシステム領域にrddic01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を20とします。

RDエリアの自動増分機能を使用します。増分量を50セグメントとします。

(2)　データベース初期設定ユティリティ（pdinit）の実行

コマンドの入力例

pdinit -d C:¥hirdb¥pdinit01

〔説明〕

-d：（1）で作成した制御文ファイルのファイル名を指定します。

4.5.3　例題2（HiRDB/パラレルサーバの場合）

次に示すRDエリア用のHiRDBファイルシステム領域に，システム用RDエリアを作成します。システム用RDエリアは，ディクショナリサーバを定義したサーバマシンに作成します。

C:¥rdarea01

(1)　制御文ファイルの作成

データベース初期設定ユティリティ（pdinit）の引数に指定する制御文ファイルを作成します。制御文ファイルを作成する場所は任意ですが，ここでは次に示すファイル名で作成することにします。

C:¥hirdb¥pdinit01

制御文ファイルの内容

create rdarea RDMAST for masterdirectory                      1
    server name dic
    file name "C:¥rdarea01¥rdmast01"
         initial 10 segments;
create rdarea RDDIR for datadirectory                         2
    server name dic
    file name "C:¥rdarea01¥rddir01"
         initial 5 segments;
create rdarea RDDIC for datadictionary                        3
    server name dic
    extension use 50 segments
    file name "C:¥rdarea01¥rddic01"
         initial 20 segments;

〔説明〕

マスタディレクトリ用RDエリアの定義

マスタディレクトリ用RDエリアを管理するディクショナリサーバの名称（dic）を指定します。HiRDBファイルシステム領域にrdmast01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を10とします。

データディレクトリ用RDエリアの定義

データディレクトリ用RDエリアを管理するディクショナリサーバの名称（dic）を指定します。HiRDBファイルシステム領域にrddir01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を5とします。

データディクショナリ用RDエリアの定義

データディクショナリ用RDエリアを管理するディクショナリサーバの名称（dic）を指定します。HiRDBファイルシステム領域にrddic01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を20とします。

RDエリアの自動増分機能を使用します。増分量を50セグメントとします。

(2)　データベース初期設定ユティリティ（pdinit）の実行

コマンドの入力例

pdinit -d C:¥hirdb¥pdinit01

〔説明〕

-d：（1）で作成した制御文ファイルのファイル名を指定します。

4.6　HiRDBの初期開始

4.6.1　HiRDBの初期開始で行うこと

実行者　HiRDB管理者

「システム用RDエリアの作成」で説明したデータベース初期設定ユティリティ（pdinit）は，HiRDBの初期開始コマンド（pdstartコマンド）を実行してから，その実行途中でだけ実行できます。

(1)　HiRDBの初期開始の方法

HiRDBファイルシステム領域を作成してからHiRDBを最初に開始（初期開始）するときは，pdstartコマンドを実行します。初期開始のためにpdstartコマンドを実行すると，データベース初期設定ユティリティ（pdinit）の実行を要求するメッセージが表示されます。

HiRDB/シングルサーバを開始する場合は，シングルサーバを定義したサーバマシンからpdstartコマンドを実行してください。

HiRDB/パラレルサーバを開始する場合は，システムマネジャを定義したサーバマシンからpdstartコマンドを実行してください。

(2)　RDエリアの作成の前提条件

次に示すRDエリアを作成するときは，HiRDBが稼働中であることが前提です。事前にHiRDBを開始しておいてください。

ユーザ用RDエリア

ユーザLOB用RDエリア

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

リスト用RDエリア

4.7　ユーザ用RDエリアの作成

実行者　HiRDB管理者

表及びインデクスを格納するユーザ用RDエリアを作成します。ユーザ用RDエリアは，データベース構成変更ユティリティ（pdmod）のcreate rdarea文で作成します。

4.7.1　基本事項

「HiRDBファイルシステム領域の作成」で作成したRDエリア用のHiRDBファイルシステム領域に，ユーザ用RDエリアを作成します。

HiRDB/パラレルサーバの場合，バックエンドサーバを定義したサーバマシンのHiRDBファイルシステム領域にユーザ用RDエリアを作成します。

ユーザ用RDエリアの設計方法については，HiRDB/シングルサーバの場合は「RDエリアの配置」を，HiRDB/パラレルサーバの場合は「RDエリアの配置」を参照してください。

HiRDB/パラレルサーバの場合，システムマネジャを定義したサーバマシンでデータベース構成変更ユティリティ（pdmod）を実行してください。

ユーザ用RDエリアを作成する前に，HiRDBが稼働しているかどうかをpdlsコマンドで確認してください。HiRDB/パラレルサーバの場合は，システムマネジャを定義したサーバマシンからpdlsコマンドを入力してください。

HiRDBが稼働していない場合，pdstartコマンドでHiRDBを開始してください。HiRDB/パラレルサーバを開始する場合は，システムマネジャを定義したサーバマシンからpdstartコマンドを入力してください。

4.7.2　例題1（HiRDB/シングルサーバの場合）

次に示すRDエリア用のHiRDBファイルシステム領域に，ユーザ用RDエリアを作成します。

C:¥rdarea02

(1)　制御文ファイルの作成

データベース構成変更ユティリティ（pdmod）の引数に指定する制御文ファイルを作成します。制御文ファイルを作成する場所は任意ですが，ここでは次に示すファイル名で作成することにします。

C:¥hirdb¥pdmod01

制御文ファイルの内容

create rdarea USER01 for user used by PUBLIC                  1
    extension use 50 segments
    file name "C:¥rdarea02¥user01"
         initial 500 segments;
create rdarea USER02 for user used by PUBLIC                  2
    extension use 50 segments
    file name "C:¥rdarea02¥user02"
         initial 500 segments;

〔説明〕

ユーザ用RDエリア（USER01）の定義

USER01を公用RDエリア（PUBLIC）とします。HiRDBファイルシステム領域にuser01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を500とします。

RDエリアの自動増分機能を使用します。増分量を50セグメントとします。

ユーザ用RDエリア（USER02）の定義

USER02を公用RDエリア（PUBLIC）とします。HiRDBファイルシステム領域にuser02というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を500とします。

RDエリアの自動増分機能を使用します。増分量を50セグメントとします。

(2)　データベース構成変更ユティリティ（pdmod）の実行

コマンドの入力例

pdmod -a C:¥hirdb¥pdmod01

〔説明〕

-a：（1）で作成した制御文ファイルのファイル名を指定します。

4.7.3　例題2（HiRDB/パラレルサーバの場合）

次に示すRDエリア用のHiRDBファイルシステム領域に，ユーザ用RDエリアを作成します。ユーザ用RDエリアは，バックエンドサーバを定義したサーバマシンに作成します。

C:¥rdarea02

(1)　制御文ファイルの作成

データベース構成変更ユティリティ（pdmod）の引数に指定する制御文ファイルを作成します。制御文ファイルを作成する場所は任意ですが，ここでは次に示すファイル名で作成することにします。

C:¥hirdb¥pdmod01

制御文ファイルの内容

create rdarea USER01 for user used by PUBLIC                  1
    server name b001
    extension use 50 segments
    file name "C:¥rdarea02¥user01"
         initial 500 segments;
create rdarea USER02 for user used by PUBLIC                  2
    server name b001
    extension use 50 segments
    file name "C:¥rdarea02¥user02"
         initial 500 segments;

〔説明〕

ユーザ用RDエリア（USER01）の定義

USER01を公用RDエリア（PUBLIC）とします。USER01を管理するバックエンドサーバの名称（b001）を指定します。HiRDBファイルシステム領域にuser01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を500とします。

RDエリアの自動増分機能を使用します。増分量を50セグメントとします。

ユーザ用RDエリア（USER02）の定義

USER02を公用RDエリア（PUBLIC）とします。USER02を管理するバックエンドサーバの名称（b001）を指定します。HiRDBファイルシステム領域にuser02というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を500とします。

RDエリアの自動増分機能を使用します。増分量を50セグメントとします。

(2)　データベース構成変更ユティリティ（pdmod）の実行

コマンドの入力例

pdmod -a C:¥hirdb¥pdmod01

〔説明〕

-a：（1）で作成した制御文ファイルのファイル名を指定します。

4.8　ユーザLOB用RDエリアの作成

実行者　HiRDB管理者

LOB属性のデータを使用する場合，LOB属性のデータを格納するユーザLOB用RDエリアが必要になります。ユーザLOB用RDエリアは，データベース構成変更ユティリティ（pdmod）のcreate rdarea文で作成します。

4.8.1　基本事項

「HiRDBファイルシステム領域の作成」で作成したRDエリア用のHiRDBファイルシステム領域に，ユーザLOB用RDエリアを作成します。

HiRDB/パラレルサーバの場合，バックエンドサーバを定義したサーバマシンのHiRDBファイルシステム領域にユーザLOB用RDエリアを作成します。

ユーザLOB用RDエリアの設計方法については，HiRDB/シングルサーバの場合は「RDエリアの配置」を，HiRDB/パラレルサーバの場合は「RDエリアの配置」を参照してください。

HiRDB/パラレルサーバの場合，システムマネジャを定義したサーバマシンでデータベース構成変更ユティリティ（pdmod）を実行してください。

ユーザLOB用RDエリアを作成する前に，HiRDBが稼働しているかどうかをpdlsコマンドで確認してください。HiRDB/パラレルサーバの場合は，システムマネジャを定義したサーバマシンからpdlsコマンドを入力してください。

HiRDBが稼働していない場合，pdstartコマンドでHiRDBを開始してください。HiRDB/パラレルサーバを開始する場合は，システムマネジャを定義したサーバマシンからpdstartコマンドを入力してください。

4.8.2　例題1（HiRDB/シングルサーバの場合）

次に示すRDエリア用のHiRDBファイルシステム領域に，ユーザ用RDエリアを作成します。このユーザ用RDエリアには，LOB列構成基表を格納します。

C:¥rdarea03

さらに，次に示すRDエリア用のHiRDBファイルシステム領域にユーザLOB用RDエリアを作成します。このユーザLOB用RDエリアには，LOB属性のデータを格納します。

C:¥rdarea04

(1)　制御文ファイルの作成

データベース構成変更ユティリティ（pdmod）の引数に指定する制御文ファイルを作成します。制御文ファイルを作成する場所は任意ですが，ここでは次に示すファイル名で作成することにします。

C:¥hirdb¥pdmod02

制御文ファイルの内容

create rdarea USER03 for user used by PUBLIC                  1
    extension use 50 segments
    file name "C:¥rdarea03¥user03"
         initial 500 segments;
create rdarea ULOB03 for LOB used by PUBLIC                   2
    extension use 50 segments
    file name "C:¥rdarea04¥ulob03"
         initial 20000 segments;

〔説明〕

ユーザ用RDエリア（USER03）の定義

USER03を公用RDエリア（PUBLIC）とします。HiRDBファイルシステム領域にuser03というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を500とします。

RDエリアの自動増分機能を使用します。増分量を50セグメントとします。

ユーザLOB用RDエリア（ULOB03）の定義

ULOB03を公用RDエリア（PUBLIC）とします。HiRDBファイルシステム領域にulob03というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を20000とします。

RDエリアの自動増分機能を使用します。増分量を50セグメントとします。

(2)　データベース構成変更ユティリティ（pdmod）の実行

コマンドの入力例

pdmod -a C:¥hirdb¥pdmod02

〔説明〕

-a：（1）で作成した制御文ファイルのファイル名を指定します。

4.8.3　例題2（HiRDB/パラレルサーバの場合）

次に示すRDエリア用のHiRDBファイルシステム領域にユーザ用RDエリアを作成します。このユーザ用RDエリアには，LOB列構成基表を格納します。

C:¥rdarea03

さらに，次に示すRDエリア用のHiRDBファイルシステム領域にユーザLOB用RDエリアを作成します。このユーザLOB用RDエリアには，LOB属性のデータを格納します。

C:¥rdarea04

(1)　制御文ファイルの作成

データベース構成変更ユティリティ（pdmod）の引数に指定する制御文ファイルを作成します。制御文ファイルを作成する場所は任意ですが，ここでは次に示すファイル名で作成することにします。

C:¥hirdb¥pdmod02

制御文ファイルの内容

create rdarea USER03 for user used by PUBLIC                 1
    server name b001
    extension use 50 segments
    file name "C:¥rdarea03¥user03"
         initial 500 segments;
create rdarea ULOB03 for LOB used by PUBLIC                  2
    server name b001
    extension use 50 segments
    file name "C:¥rdarea04¥ulob03"
         initial 20000 segments;

〔説明〕

ユーザ用RDエリア（USER03）の定義

USER03を公用RDエリア（PUBLIC）とします。USER03を管理するバックエンドサーバの名称（b001）を指定します。HiRDBファイルシステム領域にuser03というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を500とします。

RDエリアの自動増分機能を使用します。増分量を50セグメントとします。

ユーザLOB用RDエリア（ULOB03）の定義です。

ULOB03を公用RDエリア（PUBLIC）とします。ULOB03を管理するバックエンドサーバの名称（b001）を指定します。HiRDBファイルシステム領域にulob03というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を20000とします。

RDエリアの自動増分機能を使用します。増分量を50セグメントとします。

(2)　データベース構成変更ユティリティ（pdmod）の実行

コマンドの入力例

pdmod -a C:¥hirdb¥pdmod02

〔説明〕

-a：（1）で作成した制御文ファイルのファイル名を指定します。

4.9　データディクショナリLOB用RDエリアの作成

実行者　HiRDB管理者

ストアドプロシジャ又はストアドファンクションを使用する場合，データディクショナリLOB用RDエリアが必要になります。データディクショナリLOB用RDエリアは，データベース構成変更ユティリティ（pdmod）のcreate rdarea文で作成します。

データディクショナリLOB用RDエリアは，次に示す用途ごとに用意する必要があります。

ストアドプロシジャ又はストアドファンクションの定義ソース格納用のデータディクショナリLOB用RDエリア

ストアドプロシジャ又はストアドファンクションのSQLオブジェクト格納用のデータディクショナリLOB用RDエリア

4.9.1　基本事項

「HiRDBファイルシステム領域の作成」で作成したRDエリア用のHiRDBファイルシステム領域に，データディクショナリLOB用RDエリアを作成します。

HiRDB/パラレルサーバの場合，ディクショナリサーバを定義したサーバマシンのHiRDBファイルシステム領域にデータディクショナリLOB用RDエリアを作成します。

データディクショナリLOB用RDエリアの設計方法については，HiRDB/シングルサーバの場合は「RDエリアの配置」を，HiRDB/パラレルサーバの場合は「RDエリアの配置」を参照してください。

HiRDB/パラレルサーバの場合，システムマネジャを定義したサーバマシンでデータベース構成変更ユティリティ（pdmod）を実行してください。

データディクショナリLOB用RDエリアを作成する前に，HiRDBが稼働しているかどうかをpdlsコマンドで確認してください。HiRDB/パラレルサーバの場合は，システムマネジャを定義したサーバマシンからpdlsコマンドを入力してください。

HiRDBが稼働していない場合，pdstartコマンドでHiRDBを開始してください。HiRDB/パラレルサーバを開始する場合は，システムマネジャを定義したサーバマシンからpdstartコマンドを入力してください。

4.9.2　例題1（HiRDB/シングルサーバの場合）

次に示すRDエリア用のHiRDBファイルシステム領域に，データディクショナリLOB用RDエリアを作成します。

C:¥rdarea05

(1)　制御文ファイルの作成

データベース構成変更ユティリティ（pdmod）の引数に指定する制御文ファイルを作成します。制御文ファイルを作成する場所は任意ですが，ここでは次に示すファイル名で作成することにします。

C:¥hirdb¥pdmod03

制御文ファイルの内容

create rdarea DICLOB01 for LOB used by HiRDB(SQL_ROUTINES)    1
    extension use 1000 segments
    file name "C:¥rdarea05¥diclob01"
        initial 10000 segments;
create rdarea DICLOB02 for LOB used by HiRDB(SQL_ROUTINES)    2
    extension use 1000 segments
    file name "C:¥rdarea05¥diclob02"
        initial 10000 segments;

〔説明〕

データディクショナリLOB用RDエリア（DICLOB01）の定義

DICLOB01は，定義ソース格納用のデータディクショナリLOB用RDエリアになります。最初に定義したデータディクショナリLOB用RDエリアが定義ソース格納用になります。HiRDBファイルシステム領域にdiclob01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を10000とします。

RDエリアの自動増分機能を使用します。増分量を1000セグメントとします。

データディクショナリLOB用RDエリア（DICLOB02）の定義

DICLOB02は，SQLオブジェクト格納用のデータディクショナリLOB用RDエリアになります。2番目に定義したデータディクショナリLOB用RDエリアがSQLオブジェクト格納用になります。HiRDBファイルシステム領域にdiclob02というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を10000とします。

RDエリアの自動増分機能を使用します。増分量を1000セグメントとします。

(2)　データベース構成変更ユティリティ（pdmod）の実行

コマンドの入力例

pdmod -a C:¥hirdb¥pdmod03

〔説明〕

-a：（1）で作成した制御文ファイルのファイル名を指定します。

4.9.3　例題2（HiRDB/パラレルサーバの場合）

次に示すRDエリア用のHiRDBファイルシステム領域に，データディクショナリLOB用RDエリアを作成します。

C:¥rdarea05

(1)　制御文ファイルの作成

データベース構成変更ユティリティ（pdmod）の引数に指定する制御文ファイルを作成します。制御文ファイルを作成する場所は任意ですが，ここでは次に示すファイル名で作成することにします。

C:¥hirdb¥pdmod03

制御文ファイルの内容

create rdarea DICLOB01 for LOB used by HiRDB(SQL_ROUTINES)   1
    server name dic
    extension use 1000 segments
    file name "C:¥rdarea05¥diclob01"
        initial 10000 segments;
create rdarea DICLOB02 for LOB used by HiRDB(SQL_ROUTINES)   2
    server name dic
    extension use 1000 segments
    file name "C:¥rdarea05¥diclob02"
        initial 10000 segments;

〔説明〕

データディクショナリLOB用RDエリア（DICLOB01）の定義

DICLOB01は，定義ソース格納用のデータディクショナリLOB用RDエリアになります。最初に定義したデータディクショナリLOB用RDエリアが定義ソース格納用になります。データディクショナリLOB用RDエリアを管理するディクショナリサーバの名称（dic）を指定します。HiRDBファイルシステム領域にdiclob01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を10000とします。

RDエリアの自動増分機能を使用します。増分量を1000セグメントとします。

データディクショナリLOB用RDエリア（DICLOB02）の定義

DICLOB02は，SQLオブジェクト格納用のデータディクショナリLOB用RDエリアになります。2番目に定義したデータディクショナリLOB用RDエリアがSQLオブジェクト格納用になります。データディクショナリLOB用RDエリアを管理するディクショナリサーバの名称（dic）を指定します。HiRDBファイルシステム領域にdiclob02というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を10000とします。

RDエリアの自動増分機能を使用します。増分量を1000セグメントとします。

(2)　データベース構成変更ユティリティ（pdmod）の実行

コマンドの入力例

pdmod -a C:¥hirdb¥pdmod03

〔説明〕

-a：（1）で作成した制御文ファイルのファイル名を指定します。

4.10　リスト用RDエリアの作成

実行者　HiRDB管理者

絞込み検索をする場合は，リスト用RDエリアが必要になります。リスト用RDエリアは，データベース構成変更ユティリティ（pdmod）のcreate rdarea文で作成します。

4.10.1　基本事項

「HiRDBファイルシステム領域の作成」で作成したリスト用RDエリア用のHiRDBファイルシステム領域に，リスト用RDエリアを作成します。

HiRDB/パラレルサーバの場合，バックエンドサーバ（基表があるバックエンドサーバ）を定義したサーバマシンのHiRDBファイルシステム領域にリスト用RDエリアを作成します。

リスト用RDエリアの設計方法については，HiRDB/シングルサーバの場合は「RDエリアの配置」を，HiRDB/パラレルサーバの場合は「RDエリアの配置」を参照してください。

HiRDB/パラレルサーバの場合，システムマネジャを定義したサーバマシンでデータベース構成変更ユティリティ（pdmod）を実行してください。

リスト用RDエリアを作成する前に，HiRDBが稼働しているかどうかをpdlsコマンドで確認してください。HiRDB/パラレルサーバの場合は，システムマネジャを定義したサーバマシンからpdlsコマンドを入力してください。

HiRDBが稼働していない場合，pdstartコマンドでHiRDBを開始してください。HiRDB/パラレルサーバを開始する場合は，システムマネジャを定義したサーバマシンからpdstartコマンドを入力してください。

4.10.2　例題1（HiRDB/シングルサーバの場合）

次に示すリスト用RDエリア用のHiRDBファイルシステム領域に，リスト用RDエリアを作成します。

C:¥listarea01

(1)　制御文ファイルの作成

データベース構成変更ユティリティ（pdmod）の引数に指定する制御文ファイルを作成します。制御文ファイルを作成する場所は任意ですが，ここでは次に示すファイル名で作成することにします。

C:¥hirdb¥pdmod04

制御文ファイルの内容

create rdarea LIST01 for list
    page 4096 characters storage control segment 2 pages      1
    file name "C:¥listarea01¥list01"
        initial 1000 segments;

〔説明〕

リスト用RDエリア（LIST01）の定義

RDエリアのページ長及びセグメントサイズを指定します。HiRDBファイルシステム領域にlist01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を1000とします。

(2)　データベース構成変更ユティリティ（pdmod）の実行

コマンドの入力例

pdmod -a C:¥hirdb¥pdmod04

〔説明〕

-a：（1）で作成した制御文ファイルのファイル名を指定します。

4.10.3　例題2（HiRDB/パラレルサーバの場合）

次に示すリスト用RDエリア用のHiRDBファイルシステム領域に，リスト用RDエリアを作成します。

C:¥listarea01

(1)　制御文ファイルの作成

データベース構成変更ユティリティ（pdmod）の引数に指定する制御文ファイルを作成します。制御文ファイルを作成する場所は任意ですが，ここでは次に示すファイル名で作成することにします。

C:¥hirdb¥pdmod04

制御文ファイルの内容

create rdarea LIST01 for list                                   1
    server name b001
    page 4096 characters storage control segment 2 pages
    file name "C:¥listarea01¥list01"
        initial 1000 segments;

〔説明〕

リスト用RDエリア（LIST01）の定義

LIST01を管理するバックエンドサーバの名称（b001）を指定します。

RDエリアのページ長及びセグメントサイズを指定します。HiRDBファイルシステム領域にlist01というHiRDBファイルを作成します。HiRDBファイル内のセグメント数を1000とします。

(2)　データベース構成変更ユティリティ（pdmod）の実行

コマンドの入力例

pdmod -a C:¥hirdb¥pdmod04

〔説明〕

-a：（1）で作成した制御文ファイルのファイル名を指定します。

5　プラグインの環境設定

プラグインの環境設定は，HiRDBの環境設定の後で実施します。この章では，プラグインの環境設定方法，バージョンアップ方法及び削除（アンインストール）方法について説明します。

5.1　プラグインの環境設定の概要

HiRDBのプラグインの環境を設定する方法について説明します。

5.1.1　環境設定手順

実行者　HiRDB管理者

ここでは，コマンドを使用したプラグインの環境設定方法について説明します。ここでの説明は，HiRDBの環境設定が終了している（HiRDBが既に稼働している）ことを前提として説明します。

プラグインの環境設定手順を次に示します。

〈手順〉

プラグインを組み込むのに必要なリソースの見積もり

稼働中のHiRDBの終了

プラグインのインストール

HiRDBの開始

データディクショナリLOB用RDエリア，ユーザ用RDエリア及びユーザLOB用RDエリアの追加※1

プラグインの登録

レジストリ機能の初期設定※2

HiRDBの終了

pdpluginオペランドの追加

HiRDBの開始

レジストリ情報の登録

注※1

データディクショナリLOB用RDエリアは，既にストアドファンクション，ストアドプロシジャ又はプラグインを使用している場合は不要です。ユーザ用RDエリア（ユーザLOB用RDエリア）は，新規追加したプラグイン用に表を作成した場合に必要です。

注※2

使用するプラグインによっては不要な場合があります。

(1)　リソースの見積もり

プラグインをHiRDBに組み込む前に次に示すリソースを見積もる必要があります。

プラグインを実行するために必要なメモリ所要量

プラグインをインストールするときのディスク容量

プラグインを組み込むときに必要なリソースの見積もり方法については，該当するプラグインのマニュアルを参照してください。

(2)　HiRDBの終了

プラグインをセットアップする前に，pdstopコマンドで現在稼働しているHiRDBを終了してください。

(3)　プラグインのインストール

プラグインをインストールします。インストール方法については，該当するプラグインのマニュアルを参照してください。

(4)　HiRDBの開始

pdstartコマンドでHiRDBを開始します。

(5)　RDエリアの追加

HiRDBにプラグインを登録する前に，データベース構成変更ユティリティ（pdmod）のcreate rdarea文で必要なRDエリアを追加してください。追加する必要があるRDエリアを次に示します。

ユーザ用RDエリア※1

ユーザLOB用RDエリア※1

データディクショナリLOB用RDエリア※2（既にストアドプロシジャ，ストアドファンクション，プラグインを使用している場合は不要です）

RDエリアの追加方法については，「ユーザ用RDエリアの作成」，「ユーザLOB用RDエリアの作成」又は「データディクショナリLOB用RDエリアの作成」を参照してください。

なお，既にデータベース環境を構築している場合には，プラグインインストール後のRDエリアの追加は不要です。

注※1

プラグイン用に別の表を作成し，その表を格納するためのRDエリアを新しく用意したい場合に必要です。

注※2

レジストリ機能初期設定ユティリティ（pdreginit）を実行する場合に，あらかじめHiRDBがストアドプロシジャ機能を使用できるようにしておく必要があるため，このRDエリアが必要です。

(6)　プラグインの登録

pdplgrgstコマンドでプラグインをHiRDBに登録してください。pdplgrgstコマンドは，任意のサーバマシンから入力してください。

プラグインの登録の流れを次の図に示します。

図5‒1　プラグインの登録の流れ

[picture]

(a)　pdplgrgstコマンドの入力形式

pdplgrgstコマンドの入力形式を次に示します。

pdplgrgst　プラグイン定義ファイル名　PICファイル名

HiRDB Text Search Plug-inの場合の指定例

データ型プラグインの場合：

pdplgrgst _phsgml.adt _phsgml.pic

（カレントディレクトリがC:¥TSPlugin¥_phsgml¥etcの場合）

インデクス型プラグインの場合：

pdplgrgst _phngram.idx _phngram.pic

（カレントディレクトリがC:¥TSPlugin¥_phngram¥etcの場合）

注意事項

インデクス型プラグインを登録する場合，あらかじめ対応するデータ型プラグインが登録されていなければなりません。

データ型プラグインとインデクス型プラグインは，必ず同じスキーマ内に登録してください。

(b)　プラグインの所有者

プラグインの所有者（プラグインが提供する抽象データ型，インデクス型及び関数の所有者）はMASTERになります。したがって，プラグインが提供する関数を呼び出す処理をSQL文に記述する場合，認可識別子を省略できます。

MASTER以外にする場合

所有者をMASTERではなく，pdplgrgstコマンドの実行者にできます。pdplgrgstコマンドに-uオプションを指定すると，プラグインの所有者はpdplgrgstコマンドの実行者（クライアント環境定義のPDUSERオペランドに指定した認可識別子）になります。ただし，この場合，次に示す注意があります。

注意事項

pdplgrgstコマンド実行者のスキーマが既に定義されている必要があります。

プラグインが抽象データ型及びインデクス型の両方を提供している場合は，必ず同じ所有者にしてください。

プラグインの削除又はバージョンアップは，プラグインの所有者しかできません。また，pdplgrgstコマンドに-uオプションを指定してプラグインを削除又はバージョンアップしてください。

プラグイン所有者のスキーマを削除すると，プラグインも同時に削除されます。この場合，次に示す作業が必要です。

・システム共通定義からpdpluginオペランドを削除します。

複数のプラグインで，関数名及びパラメタ数が同じである関数を提供している場合，一方のプラグインを登録し，そのプラグインが提供する関数を呼び出す関数をユーザが定義した後，もう一方のプラグインを登録します。このとき，ユーザが定義した関数のパラメタ，又は戻り値のデータ型に抽象データ型を使用し，かつ，その関数をビュー定義に使用している場合は，プラグインの登録時にエラーとなります。この場合，その関数を使用したビュー表を削除した後，再度プラグインの登録を行う必要があります。

(7)　レジストリ機能の初期設定

プラグインによっては，レジストリ機能が必要な場合があります。その場合，レジストリ機能初期設定ユティリティ（pdreginit）のcreate rdarea文で次に示すRDエリアを作成してください。ただし，既にプラグインでレジストリ機能を使用している場合は不要です。

レジストリ用RDエリア

レジストリLOB用RDエリア

なお，レジストリ機能初期設定ユティリティ（pdreginit）は，すべてのプラグインを登録するまでの間で一度だけ実行します。

また，レジストリ用RDエリア及びレジストリLOB用RDエリアには，レジストリ情報が格納されます。どちらのRDエリアに格納されるかは，登録されるデータの長さによって自動的に決定されます。

レジストリ用RDエリア，レジストリLOB用RDエリアの作成の手順を次の図に示します。

図5‒2　レジストリ用RDエリア，レジストリLOB用RDエリアの作成の手順

[picture]

(8)　HiRDBの終了

プラグインを使用できる状態にするため，いったんpdstopコマンドでHiRDBを正常終了させます。再度開始するまでは，登録したプラグインを使用した表の定義やインデクスの定義などは実行できません。

HiRDB終了後，更新したRDエリアのバックアップを必ず取得してください。

(9)　pdpluginオペランドの追加

HiRDBが正常終了したら，システム共通定義にpdpluginオペランドを指定してください。pdpluginオペランドには，使用するプラグインの名称を指定します。

HiRDB/パラレルサーバの場合，すべてのサーバマシン上のシステム共通定義にpdpluginオペランドを追加してください。追加漏れがあるとHiRDBを開始できません。

(10)　HiRDBの開始

pdstartコマンドでHiRDBを開始します。

(11)　レジストリ情報の登録

レジストリ機能の初期設定の完了後，プラグインの必要に応じてレジストリ情報を登録します。登録すると，プラグイン及びレジストリ機能を使用できる状態になります。レジストリ情報の登録については，該当するプラグインのマニュアルを参照してください。

5.1.2　プラグイン使用時の注意

(1)　HiRDBの設定／開始時の状態とプラグインの使用可否

HiRDB（ユニット）の設定／開始時の状態とプラグインの使用可否を次の表に示します。

表5‒1　HiRDB（ユニット）の設定／開始時の状態とプラグインの使用可否

プラグインの利用宣言（pdpluginオペランド） | プラグインの登録（pdplgrgst） | プラグインの 初期化エラー | ユニット 開始可否 | プラグイン 使用可否
なし | 登録済み | なし | ○ | ×
あり | ○ | ×
未登録 | なし | ○ | ×
あり | ○ | ×
あり | 登録済み | なし | ○ | ○
あり | ○ | ×
未登録 | なし | ○ | ×
あり | ○ | ×

（凡例）

○：ユニットを開始できます。及びプラグインを利用できます。

×：ユニットを開始できません。及びプラグインを利用できません。

(2)　プラグイン初期化エラーが発生したとき

プラグインの初期化は，HiRDB開始時に自動的に実行されます。システム共通定義に複数のpdpluginオペランドが記述され，一部のプラグインの初期化でエラーが発生した場合，ユニット内のすべてのプラグインが利用できません。

(3)　ユニット間でプラグインの使用可否が異なる場合

次に示す場合，ユニット間で利用できるプラグインが異なります。

ユニット間でシステム共通定義に記述されたプラグイン利用宣言（pdpluginオペランド）が異なる場合

プラグイン初期化処理時にエラーが発生し，そのユニットでプラグインが利用できなくなった場合

プラグインの呼び出しを伴うSQL文で利用できるプラグインだけ呼び出した場合は成功しますが，一つでも利用できないプラグインが呼び出された場合は，SQL文の実行は失敗します。

5.2　プラグインのバージョンアップ

5.2.1　バージョンアップの手順

HiRDBに導入済みのプラグイン（データ型プラグイン，インデクス型プラグイン）をバージョンアップする手順について説明します。プラグインのバージョンアップとは，次に示す内容を削除しないでプラグインのバージョンを上げることです。

プラグインの提供するデータ型を使用した表やビュー表

プラグインの提供するインデクス型を使用したインデクス

プラグインの提供する関数

なお，プラグインをバージョンアップする場合の注意事項については，マニュアル「HiRDB コマンドリファレンス」の「pdplgrgst（プラグインの登録・削除）」の「注意事項」を参照してください。

バージョンアップの手順を次に示します。

(1)　バックアップの取得

障害時に備えて，データベース複写ユティリティ（pdcopy）で次に示すRDエリアのバックアップを取得します。なお，データベース複写ユティリティ（pdcopy）に-M xオプションを指定してください。

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

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

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

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

バックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(2)　HiRDBの終了

pdstopコマンドでHiRDBを正常終了させます。

(3)　必要なファイルの退避

次に示す場所にあるファイルのうち，必要なものを退避します。

%PDDIR%¥plugin¥プラグイン名 のディレクトリ

どのファイルを退避するかについては，該当するプラグインのマニュアルを参照してください。HiRDBがセットアップされたすべてのサーバマシンでファイルを退避してください。

(4)　新バージョンのプラグインのインストール

HiRDBの各サーバマシンで，新しいバージョンのプラグインをインストールします。インストール方法については，各プラグイン提供のマニュアルを参照してください。

(5)　システム共通定義の変更

システム共通定義から，バージョンアップ対象のプラグインのpdpluginオペランドを削除します。システム共通定義ファイルがあるすべてのサーバマシンから削除してください。

(6)　退避したファイルの復旧

HiRDBがセットアップされたすべてのサーバマシンで，（3）で退避したファイルを復旧してください。

(7)　HiRDBの開始

pdstartコマンドでHiRDBを開始します。

(8)　新バージョンのプラグインの登録

pdplgrgstコマンドに-aオプションを指定して実行し，プラグインを更新登録します。

(9)　HiRDBの終了

pdstopコマンドでHiRDBを正常終了させます。

(10)　システム共通定義の変更

HiRDBが正常終了したら，システム共通定義にpdpluginオペランドを指定してください。pdpluginオペランドには，バージョンアップしたプラグインの名称を指定します。

HiRDB/パラレルサーバの場合，すべてのサーバマシン上のシステム共通定義にpdpluginオペランドを追加してください。追加漏れがあるとHiRDBを開始できません。

(11)　HiRDBの開始

pdstartコマンドでHiRDBを開始します。開始すると，バージョンアップ前に定義していた表，インデクスを使用できるようになります。さらに，バージョンアップ後のプラグインが新しい機能を提供する場合，その機能を利用できます。

5.3　プラグインの削除

5.3.1　プラグインを削除する手順

ここでは，HiRDBに登録されたプラグインを削除する方法と手順について説明します。なお，プラグインの削除とは，次に示す内容を削除することです。

ディクショナリに登録されたプラグインの定義情報

プラグインが提供する関数，抽象データ型及びインデクス型

ただし，プラグインファイルセットを含むプラグイン提供のファイルは削除しません。プラグインを削除する手順を次に示します。

(1)　プラグインが提供する機能を使用したデータベース資源の削除

プラグインを削除する前に，次に示すデータベース資源を削除する必要があります。これらを削除するために発行するSQL文を次の表に示します。

削除するプラグインの提供する抽象データ型を利用した表，ビュー表，関数，手続き，抽象データ型（ユーザが定義した抽象データ型の中で，プラグインが提供する抽象データ型を一つの属性として指定した場合）

削除するプラグインの提供するインデクス型を利用したインデクス

削除するプラグインの提供する関数を利用した関数，手続き

表5‒2　データベース資源を削除するためのSQL

削除する対象となるデータベース資源 | 削除するためのSQL
表 | DROP TABLE
インデクス | DROP INDEX
ビュー表 | DROP VIEW
関数 | DROP FUNCTION
手続き | DROP PROCEDURE
抽象データ型 | DROP DATA TYPE ※

注※　プラグインが提供するデータ型を削除してはいけません。

(2)　登録したプラグインの削除

削除する個々のプラグインについて次に示すコマンドを実行します。

pdplgrgst -d　プラグイン定義ファイル名　PICファイル名

注意事項

データ型プラグインを削除する場合で，そのデータ型のインデクス機能を提供するインデクス型プラグインも登録されているときは，インデクス型プラグインを先に削除する必要があります。

プラグインの所有者がMASTER以外の場合，プラグインを削除するときに次に示すことに注意してください。

プラグインの削除はプラグインの所有者だけができます。クライアント環境定義のPDUSERオペランドにプラグインの所有者の認可識別子とパスワードを指定してください。そして，pdplgrgstコマンドを実行するときに-uオプションを指定してください。

プラグイン所有者のスキーマを削除した場合，プラグインも同時に削除されます。プラグインが削除された後の処理については，（3）以降を参照してください。

(3)　レジストリの削除

レジストリに登録した情報を削除する方法については，各プラグインで提供しているマニュアルを参照してください。

(4)　HiRDBの終了

pdstopコマンドでHiRDBを正常終了させます。

(5)　システム共通定義の変更

HiRDBが正常終了したら，システム共通定義からpdpluginオペランドを削除します。

(6)　プラグインのアンインストール

プラグインをサーバマシンからアンインストールします。アンインストール方法については，該当するプラグインでの手順に従ってください。

6　データベースの作成

この章では，スキーマ，表，インデクスを作成し，データを格納するまでの方法について説明します。

6.1　データベース作成の概要

ここでは，データベース（表及びインデクス）を作成する前に理解しておくことについて説明します。ここで説明する項目を次に示します。

データベースの作成前に必要な作業

データベースの作成手順

データベースの更新ログ取得方式

ユニークインデクスを定義した表にデータロードする場合の注意

大量のデータをロードする場合（同期点指定のデータロード）

横分割表にデータをロードする場合（パラレルローディング機能）

横分割表にデータをロードする場合（分割入力データファイルの作成）

自動採番機能を使用したデータロード

入力データファイルUOC

不要なRDエリアの確認

6.1.1　データベースを作成する前に必要な作業

実行者　HiRDB管理者

データベースを作成する前に必要な作業について説明します。

(1)　クライアント環境定義の設定

次に示すクライアント環境定義を設定してください。クライアント環境定義の設定方法については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

PDHOST

PDUSER

PDNAMEPORT

(2)　パスワードの変更

HiRDB管理者用の認可識別子のパスワードが，認可識別子と同じ文字列になっている場合，定義系SQLのGRANTでパスワードを変更してください。データベース定義ユティリティ（pddef）又はHiRDB SQL Executerで次に示すSQLを実行します。

GRANT DBA TO HiRDB管理者用の認可識別子 IDENTIFIED BY 新しいパスワード;

(3)　スキーマの定義

定義系SQLのCREATE SCHEMAでスキーマを定義します。CREATE SCHEMAは，データベース定義ユティリティ（pddef）又はHiRDB SQL Executerで実行してください。なお，1ユーザに対して1個のスキーマを定義します。

(4)　HiRDB管理者以外がデータベースを作成する場合

HiRDB管理者以外がデータベースを作成する場合，ユーザ権限を与える作業が必要になります。定義系SQLのGRANTで，データベースを作成するユーザに必要なユーザ権限を与えてください。必要なユーザ権限を次に示します。

CONNECT権限

スキーマ定義権限

RDエリア利用権限

ユーザ権限については，マニュアル「HiRDB システム運用ガイド」を参照してください。

（例）

表を作成するユーザ（認可識別子：USER002，パスワード：HIRDB002）に，CONNECT権限，スキーマ定義権限，RDエリア利用権限（RDエリア名：RDAREA01）を与えます。

  GRANT CONNECT TO USER002 IDENTIFIED BY HIRDB002;
  GRANT SCHEMA TO USER002;
  GRANT RDAREA RDAREA01 TO USER002;

(5)　データの変換方式の設定

データをデータベースに格納するとき，データの形式を変換する機能があります。次に示す機能を適用するかどうかを検討してください。これらの機能については，マニュアル「HiRDB システム運用ガイド」を参照してください。

空白変換機能

DECIMAL型の符号正規化機能

6.1.2　データベースの作成手順

データベースの作成手順を次の図に示します。

図6‒1　データベースの作成手順

[picture]

注

CREATE TABLE及びCREATE INDEXは次に示すどちらかの方法で実行します。

データベース定義ユティリティ（pddef）

HiRDB SQL Executer

6.1.3　データベースの更新ログ取得方式

データベース作成ユティリティ（pdload）で表にデータを格納するときに，データベースの更新ログ取得方式を指定します。データベースの更新ログ取得方式は，データベース作成ユティリティ（pdload）の-lオプションで指定します。

(1)　データベースの更新ログ取得方式の種類

データベースの更新ログ取得方式には，次に示す3種類のモードがあります。

ログ取得モード

ロールバック及びロールフォワードに必要なデータベース更新ログを取得します。データ件数が少ない場合に使用します。

更新前ログ取得モード

ロールバックに必要なデータベース更新ログだけを取得します。データ件数が多いときに使用します。

ログレスモード

データベース更新ログを取得しません。そのため，データロードの処理時間が最も掛かりません。一つのRDエリアに一つの表だけ（分割格納している場合は一つの横分割表）を格納している場合で，関連するインデクスも一つのRDエリア内にあるときに使用します。

これらのモードの機能詳細については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(2)　データの格納先がユーザLOB用RDエリアの場合

データの格納先がユーザLOB用RDエリアの場合，CREATE TABLEのRECOVERYオペランドでデータベースの更新ログ取得方式を指定します。

ユーザLOB用RDエリアのデータベースの更新ログ取得方式（CREATE　TABLEのRECOVERYオペランド指定値）は，pdloadの-lオプションの指定値によって変わることがあります。pdloadの-lオプションの指定値によって変わるユーザLOB用RDエリアのデータベースの更新ログ取得方式を次の表に示します。

表6‒1　pdloadの-lオプションの指定値によって変わるユーザLOB用RDエリアのデータベースの更新ログ取得方式

pdloadの -lオプションの指定値 | CREATE TABLEのRECOVERYオペランドの指定値
ALL | PARTIAL | NO
a（ALL指定相当） | ALL | PARTIAL | NO
p（PARTIAL指定相当） | PARTIAL※ | PARTIAL※ | NO
n（NO指定相当） | NO | NO | NO

（凡例）

ALL：ログ取得モード

PARTIAL：更新前ログ取得モード

NO：ログレスモード

例えば，CREATE TABLEのRECOVERYオペランドにPARTIALを指定し，pdloadの-lオプションにnを指定した場合，NO（ログレスモード）がユーザLOB用RDエリアに設定されます。

注※

プラグインが出力するログの場合は，ALL（ログ取得モード）が仮定されます。

(3)　モードの選択基準

基本的には省略値である更新前ログ取得モードを選択してください。ただし，次に示す条件を満たすような場合はほかのモードの選択を検討してください。

条件 | 選択するモード
RDエリアにデータロード対象表（インデクス）だけを格納していて，かつ初期ロードである | ログレスモード
入力データ量が多く，データロードに時間が掛かる
入力データ量が少ない | ログ取得モード

(4)　運用方法の違い

選択したモードによってデータロードするときの運用が異なります。運用方法の違いを次の図に示します。

図6‒2　データベースの更新ログ取得方式による運用方法の違い（データロード）

[picture]

注※１

ログレスモードを選択したときに必要な操作です。ログレスモードのpdloadコマンドが異常終了した場合，このバックアップを使用してRDエリアを回復します。ただし，「データロードの前にバックアップを取得しないでよい場合」で説明している条件を満たすときはバックアップを取得する必要はありません。

ただし，更新ログ取得方式に関係なく，プラグインインデクスを定義した表にインデクス一括作成モードで追加データロードをする場合はバックアップを取得してください。理由は，pdloadコマンドが異常終了した場合のデータベース回復には既存データ部分を含め，全プラグインインデクスの再作成が必要となり，データベース回復に長時間必要となるためです。

注※２

更新前ログ取得モード又はログレスモードを選択したときに必要な操作です。ここでバックアップを取得しないと，pdrstrコマンドでRDエリアを回復する必要が生じた場合，RDエリアを最新の状態に回復できません（データロード実行後の反映処理を回復できません）。RDエリアはデータロード実行前の状態にしか回復できません。

補足事項

更新前ログ取得モード又はログレスモードを選択した場合，前記の手順1〜4の間はデータロード対象RDエリアを閉塞したままにしてください。手順4でバックアップを取得する前にRDエリアの内容が更新された場合，pdrstrコマンドでRDエリアを回復する必要が生じたときにその更新内容を回復できません。RDエリアはデータロード実行前の状態にしか回復できません。pdrstrコマンドでRDエリアを回復するとき，入力情報のシステムログ中に更新前ログ取得モード又はログレスモードで取得したログが入っているとpdrstrコマンドがエラーになります。

(5)　データロードの前にバックアップを取得しないでよい場合

ログレスモードでデータロードを実行する場合は，データロードの実行前にバックアップを取得する必要があります。ただし，次表に示す1，2の条件のうちどちらかを満たす場合は，pdloadコマンドが異常終了したときにRDエリアの状態をデータロード実行前の状態に戻すことができるため，バックアップの取得を省略できます。

項番 | 条件 | 障害発生時のRDエリア回復方法
1 | 初期ロードの場合 | データロード対象RDエリアにはデータロード対象の表，及びその表のインデクスだけを格納している場合 | データロード対象RDエリアをデータベース構成変更ユティリティ（pdmodコマンド）で再初期化した後に，再度データロードすると回復できます。
作成モードでデータロードを実行する場合
2 | データロード対象RDエリアにデータロード対象表（インデクス）以外の表（インデクス）がある場合 | バックアップとシステムログを使用してデータロード実行前の状態にRDエリアを回復できる場合 | pdcloseコマンドでデータロード対象RDエリアをクローズした後に，pdlogswapコマンドでシステムログファイルをスワップして，データベース回復ユティリティ（pdrstrコマンド）にここまでのシステムログを入力すれば回復できます。
追加モードでデータロードを実行する場合

注

項番2の条件の場合は，バックアップを取得した方がRDエリアを回復するときの運用が簡単なため，基本的にはバックアップを取得することをお勧めします。特に，インデクス一括作成モードのpdloadが異常終了した場合は，ログ取得モードであっても更新前ログ取得モードであっても，ロールバックではインデクスは回復されません。pdloadが異常終了して，すぐにデータロード前の状態に回復する必要がある場合は必ずバックアップを取得してください。

6.1.4　ユニーク属性のインデクスを定義した表にデータロードする場合の注意

主キーインデクス（PRIMARYインデクス），又はユニークインデクス（UNIQUE指定のインデクス）を定義した表にデータロードをする場合は，次に示す注意が必要です。

入力データファイル中にキー値が重複するデータがある場合，インデクス一括作成モードでデータロードをしないでください。

インデクス一括作成モードでデータロードをすると，データを表に格納し，インデクスのキー情報をインデクス情報ファイルに出力します。この段階ではキー値の重複チェックはされません。キー値の重複チェックは，その後のインデクスデータの格納段階でチェックされます。キー値が重複していると，インデクスの作成処理はロールバックされますが，データは既に格納されています（コミットされて元に戻りません）。この場合，バックアップを使用してRDエリアを回復する必要があります。

したがって，キー値の重複データがある入力データファイルを使用してデータロードをする場合は，必ずインデクス更新モードを指定してください。このモードはデータを格納するごとにインデクスを更新するのでキー値の重複をすぐに検知し，該当するデータはデータベースに格納しません。

インデクス一括作成モード及びインデクス更新モードは，データベース作成ユティリティ（pdload）の-iオプションで指定します。なお，省略値がインデクス一括作成モードになっているので注意してください。

6.1.5　大量のデータをロードする場合（同期点指定のデータロード）

大量のデータを表にロードする場合，同期点指定のデータロードを実施するかどうかを検討してください。

通常，データロード処理では全データの格納処理を完了するまでトランザクションを決着できません。このため，データベース作成ユティリティ実行中はシンクポイントダンプを有効化できません。したがって，大量データのロード中にHiRDBが異常終了すると，HiRDBの再開始処理に長い時間を必要とします。これを防ぐために，データロード時に任意の件数で同期点を設定してトランザクションを決着できます。これを同期点指定のデータロードといいます。

同期点指定のデータロードをするには，データベース作成ユティリティのoption文で同期点行数（何件データを格納したら同期点を取得するか）を指定してください。

注意事項

この機能を適用しない場合よりも同期点処理が実行される分，処理性能が低下します。

ユティリティが異常終了したとき，そのタイミングによって対処方法が異なります。異常終了時の対処方法については，「同期点指定のデータロード実行中にユティリティが異常終了したときの対処方法」を参照してください。特に，インデクス一括作成モードでデータロードをしたときにユティリティが異常終了すると，対処方法が複雑になるため注意してください。

同期点のたびに新しいページからデータの格納を開始するので，この機能を適用しない場合よりも格納ページ数が多く必要になります。

6.1.6　横分割表にデータをロードする場合（パラレルローディング機能）

パラレルローディング機能とは，一つの入力データファイルから横分割表を構成する複数のRDエリアに対してデータロードを並列実行する機能です。pdparaloadコマンドを実行することで，複数のRDエリアに対するデータロードを一度に実行できます。

パラレルローディング機能の概要を次の図に示します。

図6‒3　パラレルローディング機能の概要

[picture]

〔説明〕

ユーザがpdparaloadコマンドを実行すると，横分割表を構成するRDエリアの数だけpdloadコマンドが自動的に実行されます。このとき，pdparaloadコマンドがpdloadコマンドの制御文ファイルを生成します。

各pdloadコマンドが入力データファイルを参照し，該当するデータを抽出してRDエリア内の横分割表に格納します。

(1)　効果

パラレルローディング機能を使うことで得られる効果は，次の二つです。

データロードに掛かる処理時間を短縮できます。

pdparaloadを実行すると複数のpdloadコマンドが並列で実行されます。そのため，一つのpdloadコマンドで実行する表単位データロードと比べ，データロードに掛かる処理時間が短くなります。

一つの入力データファイルと1回のコマンド入力で済むため，運用が容易です。

分割入力データファイルを使用したRDエリア単位のデータロードの場合でもpdloadコマンドの並列実行はできますが，その際，入力データファイルを分割したり，pdloadコマンドを複数回入力したりと，運用が煩雑です。パラレルローディング機能を使う場合，入力データファイルをRDエリア単位に分割する必要はありません。また，コマンドの入力も1回で済みます。

このように，パラレルローディング機能は，RDエリア単位データロードの高速処理性能と，表単位データロードの運用容易性という両方の長所を併せ持った機能です。

(2)　コマンド実行前に準備しておくこと

パラレルローディングを実行する前に，次の準備をしてください。

(a)　リソース使用量の見積もり

パラレルローディングでは，複数のpdloadコマンドを並列実行します。例えば，表を三つのRDエリアに分割して格納する場合，三つのpdloadコマンドが同時に実行されるため，リソースも三つ分必要になります。これを考慮して必要なリソース使用量を見積もってください。

(b)　入力データの準備

表に入力するデータを入力データファイルとして準備します。pdparaloadコマンドの入力データファイルは一つです。

(3)　運用手順

パラレルローディングの運用手順を次の図に示します。

図6‒4　パラレルローディングの運用手順

[picture]

注※1

この手順は，データベースの更新ログ取得方式（-lオプション）の指定によって，必要かどうかが異なります。

注※2

この手順は，インデクスの作成方法（-iオプション）にn（インデクス情報出力モード），又はx（インデクス情報出力抑止モード）を指定した場合に必要です。また，c（インデクス一括作成モード）を指定している場合でも，非分割キーインデクスを定義しているときには必要になります。

(4)　制限事項

パラレルローディング機能を使用してデータロードをする場合の制限事項を次に示します。

フレキシブルハッシュ分割を定義している表はデータロードできません。

同期点指定のデータロードはできません。

パラレルローディングを実行中の表に対して，NOWAIT検索はできません。

LOB列構成基表とLOBデータを別々にロードすることはできません。

テープ装置を媒体とする入力データファイルは使用できません。

pdparaloadコマンドのオプションや制御文には，pdloadコマンドのオプションや制御文と同様の指定ができますが，一部指定できないものもあります。指定可否の詳細については，マニュアル「HiRDB コマンドリファレンス」の「pdparaload」を参照してください。

(5)　性能に影響を及ぼす条件

パラレルローディング機能の性能は，入力データのデータ配置など，データロードの実行環境に左右されます。そのため，実行環境によっては，パラレルローディング機能を使用してもデータロードに掛かる時間が短縮されないことがあります。したがって，実際に運用を開始する前に，一度パラレルローディング機能を使用して，データロードに掛かる時間を計測してください。その結果，パラレルローディング機能を使用することでデータロードに掛かる時間が短縮された場合に，パラレルローディング機能を使用してください。期待する処理性能が得られなかった場合は，表単位のデータロード，又は入力データファイルを分割してRDエリア単位のデータロードを行ってください。分割入力データファイルの作成については，「横分割表にデータをロードする場合（分割入力データファイルの作成）」を参照してください。

パラレルローディング機能の性能に影響を及ぼす条件について以降で説明します。

(a)　サーバ間横分割

パラレルローディング機能は，サーバ間横分割をしている場合に効果が得られます。サーバ内横分割をしている表にもパラレルローディングは実行できます。しかし，サーバが分かれている方が，データを格納するときに一つのpdloadコマンドの処理がサーバを占有できるため，その分早くデータロードできます。

(b)　入力データのデータ配置

パラレルローディングを実行すると，複数のpdloadコマンドが一つの入力データファイルからデータを読み込みます。このとき，読み込み処理が効率良くできるようなデータ配置にしておくと，処理時間が短くなります。次の図に示すように，入力データが分割キーに対して均等に配置されていると，効率良く読み込み処理ができます。

図6‒5　入力データのデータ配置と読み込み効率の関係

[picture]

なお，サーバ内横分割をしている表のデータをpdrorgコマンドで一つのファイルにアンロードした場合，アンロードデータファイルは図の「偏ったデータ配置の例」のようになります。そのため，これを入力データファイルとしてパラレルローディングを実行する場合も性能が低下するおそれがあります。

(c)　入力データのデータ形式

パラレルローディング機能では，pdloadコマンドでデータロードできるすべてのデータ形式でデータロードできます。ただし，大量のデータを扱う場合には，入力データのデータ形式をバイナリ形式にすることをお勧めします。DAT形式や固定長データ形式の場合，データベースにデータを格納する際にデータ形式の変換処理が必要になります。これによって，CPU使用率が上がり，データロードの並列処理の性能が低下するおそれがあるためです。

(d)　LOB作成種別

処理対象の表にLOB列やLOBパラメタを持つ抽象データ型の列を定義している場合は，データロードのLOB作成種別（-kオプション）にfを指定することをお勧めします。fを指定したデータロードの場合，LOB入力ファイルとしてLOBデータごとにファイルを用意します。そのため，データロードを並列実行する際にLOBデータを重複して読み込むことがなく，入出力を削減できます。

LOB作成種別にdを指定する場合，入力データファイル中にすべてのLOBデータを格納します。そうすると，各RDエリア単位のデータロードで，処理対象外のLOBデータを読み飛ばすという処理が発生するため，性能低下の原因になります。

(6)　運用例

ここでは，パラレルローディングの運用例について説明します。

運用例1はLOB列の定義がある場合について説明します。

運用例2は非分割キーインデクスの定義がある場合について説明します。

運用例のデータロードの条件を次の表に示します。

表6‒2　パラレルローディングの運用例の条件

運用例 | 表定義 | インデクス定義 | 入力データの形式 | インデクス作成方法 | ログ取得方式
横分割 | LOB列 | 分割キーインデクス | 非分割キーインデクス
運用例1 | ○ | ○ | ○ | × | バイナリ形式 | インデクス一括作成モード | 更新前ログ取得モード
運用例2 | ○ | × | ○ | ○ | バイナリ形式 | インデクス一括作成モード | 更新前ログ取得モード

（凡例）

○：定義します。

×：定義しません。

(a)　運用例1（LOB列の定義がある場合）

LOB列を定義した表2にパラレルローディング機能を使用してデータロードします。LOB作成種別（-kオプション）にfを指定して，LOBデータごとにファイルを作成します。

●表定義とインデクス定義

表定義

create table "表2"(
  col001    int not null,
  col002    varchar(20),
  col003    blob(1M) in ((LOB01),(LOB02),(LOB03)),
  col004    decimal(10,3)
) fix hash hashf by col001
in (RDUSER11,RDUSER21,RDUSER31);

インデクス定義

create index "インデクス2" on "表2"(col001,col002)
in ((RDUSER12),(RDUSER22),(RDUSER32));

●データロードの手順

pdholdコマンドでデータロード対象のRDエリアを閉塞します。

pdhold -r LOB01,LOB02,LOB03,RDUSER11,RDUSER21,RDUSER31,RDUSER12,RDUSER22,RDUSER32

pdparaloadコマンドの制御文ファイルを作成します。

source：サーバ名，入力データファイル，エラー情報ファイルを指定します。HiRDB/パラレルサーバの場合は，サーバ名を必ず指定してください。

lobdata：LOB入力ファイルを指定します。

idxwork：インデクス情報ファイルの格納ディレクトリを指定します。

sort：ソート用ワークファイルの格納ディレクトリを指定します。

report：処理結果ファイル名を指定します。

source fes01:c:¥users¥data¥input_file error=c:¥users¥rep¥error_file
lobdata c:¥users¥data¥lob
idxwork bes01 c:¥users¥work
idxwork bes02 c:¥users¥work
idxwork bes03 c:¥users¥work
sort bes01 c:¥users¥work
sort bes02 c:¥users¥work
sort bes03 c:¥users¥work
report file=c:¥users¥rep¥result_file

pdparaloadコマンドでデータロードを行います。

-d：作成モードでデータロードします。

-b：バイナリ形式の入力データファイルを使用します。

-k：LOB作成種別を指定します。LOBデータごとにファイルを作成します（f）。

-i：インデクス一括作成モード（c）を指定します。

-l：更新前ログ取得モード（p）を指定します。

pdparaload -d -b -k f -i c -l p "表2" c:¥users¥cntl¥control_file

pdcopyコマンドでRDエリアのバックアップを取得します。

pdcopy -m c:¥users¥rdarea¥mast¥mast01 -M r -p c:¥users¥pdcopy¥list¥list01
-b c:¥users¥pdcopy¥backup¥backup01
-r LOB01,LOB02,LOB03,RDUSER11,RDUSER21,RDUSER31,RDUSER12,RDUSER22,RDUSER32

pdrelsコマンドでRDエリアの閉塞を解除します。

pdrels -r LOB01,LOB02,LOB03,RDUSER11,RDUSER21,RDUSER31,RDUSER12,RDUSER22,RDUSER32

(b)　運用例2（非分割キーインデクスの定義がある場合）

非分割キーインデクスを定義した表3にパラレルローディング機能を使用してデータロードします。非分割キーインデクスを定義しているため，pdparaloadコマンド実行後に，pdrorgコマンドでインデクスの一括作成をする必要があります。インデクスの一括作成時には，pdparaloadコマンドで出力されたインデクス情報ファイルを指定します。

●表定義とインデクス定義

表定義

create table "表3"(
  col001    int not null,
  col002    varchar(20),
  col003    char(32),
  col004    decimal(10,3)
) partitioned by col001
in ((RDUSER11) 10000000, (RDUSER21) 20000000, (RDUSER31));

インデクス定義（分割キーインデクス）

create index "インデクス3" on "表3"(col001,col002)
in ((RDUSER12),(RDUSER22),(RDUSER32));

インデクス定義（非分割キーインデクス）

create index "インデクス4" on "表3"(col003)
in ((RDUSER13));

●データロードの手順

pdholdコマンドでデータロード対象のRDエリアを閉塞します。

pdhold -r RDUSER11,RDUSER21,RDUSER31,RDUSER12,RDUSER22,RDUSER32,RDUSER13

pdparaloadコマンドの制御文ファイルを作成します。

source：入力データファイル，エラー情報ファイルを指定します。HiRDB/パラレルサーバの場合は，サーバ名を必ず指定してください。

idxwork：インデクス情報ファイルの格納ディレクトリを指定します。データロード後は，ここに作成されたインデクス情報ファイルを使ってインデクスの一括作成をします。

sort：ソート用ワークファイルの格納ディレクトリを指定します。

report：処理結果ファイル名を指定します。

source c:¥users¥data¥input_file error=c:¥users¥rep¥error_file
idxwork c:¥users¥work
sort c:¥users¥work
report file=c:¥users¥rep¥result_file

pdparaloadコマンドでデータロードを行います。

-d：作成モードでデータロードします。

-b：バイナリ形式の入力データファイルを使用します。

-i：インデクス一括作成モード（c）を指定します。

-l：更新前ログ取得モード（p）を指定します。

pdparaload -d -b -i c -l p "表3" c:¥users¥cntl¥control_file

pdrorgコマンドの制御文ファイルを作成します。

index文に，pdparaloadコマンドで出力されたインデクス情報ファイルを指定します。

index "インデクス4" RDUSER13 "c:¥users¥work¥INDEX-インデクス4-RDUSER13-faaG4MnMf"
index "インデクス4" RDUSER13 "c:¥users¥work¥INDEX-インデクス4-RDUSER13-caa34EnEc"
index "インデクス4" RDUSER13 "c:¥users¥work¥INDEX-インデクス4-RDUSER13-caa06MnMc"
sort c:¥users¥work
report file=c:¥users¥rep¥result_file2

pdrorgコマンドでインデクスの一括作成をします。

pdrorg -k ixmk -l p -t "表3" c:¥users¥cntl¥control_rorg

pdcopyコマンドでRDエリアのバックアップを取得します。

pdcopy -m c:¥users¥rdarea¥mast¥mast01 -M r -p c:¥users¥pdcopy¥list¥list01
-b c:¥users¥pdcopy¥backup¥backup01
-r RDUSER11,RDUSER21,RDUSER31,RDUSER12,RDUSER22,RDUSER32,RDUSER13

pdrelsコマンドでRDエリアの閉塞を解除します。

pdrels -r RDUSER11,RDUSER21,RDUSER31,RDUSER12,RDUSER22,RDUSER32,RDUSER13

(7)　コマンドエラーが発生した場合の運用

pdparaloadコマンドの実行時に発生するエラーと対処には，大きく分けて次の二つがあります。

RDエリア単位データロード（pdloadコマンド）実行中のエラー

この場合，一部のRDエリアへのデータロードに失敗しています。エラーになったそれぞれのRDエリアについてエラーの対処をした後，pdloadコマンドでRDエリア単位のデータロードを再実行します。

RDエリア単位データロード（pdloadコマンド）開始前のエラー

この場合，すべてのRDエリアへのデータロードに失敗しています。エラーに対処した後，pdparaloadコマンドを再実行します。

pdparaloadコマンドの実行時に発生するエラーと対処の詳細について説明します。まず最初に，pdparaloadコマンドの実行でエラーが発生した場合の対処の流れを次に示します。

図6‒6　pdparaloadコマンドの実行でエラーが発生した場合の対処の流れ

[picture]

注

図中の(a)から(e)は，以降の(a)から(e)と対応しています。

(a)　エラー発生のタイミングを特定します

エラー発生のタイミングを特定します。次の両方のメッセージが出力されているかどうかを確認してください。

KFPL00791-Iメッセージ

KFPL00792-Iメッセージ

≪両方のメッセージが出力されている場合≫

RDエリア単位データロードの実行中にエラーが発生しています。これによって，一部のRDエリアへのデータロードに失敗しています。この場合は，(b)以降の手順に従ってエラーに対処してください。その後，pdloadコマンドでRDエリア単位のデータロードを再実行してください。

≪どちらかのメッセージが出力されていない場合≫

RDエリア単位データロードの開始前にエラーが発生しています。つまり，すべてのRDエリアへのデータロードに失敗しています。この場合は，KFPL00794-Iメッセージの直前に出力されたエラーメッセージに従って対処してください。その後，pdparaloadコマンドを再実行してください。

(b)　対処が必要なRDエリアを特定します

pdparaloadコマンドを実行したコマンドプロンプト又はイベントログに出力されたメッセージからKFPL00793-Iメッセージを抽出し，対処が必要なRDエリアを特定します。メッセージを抽出する際には，次の項目を検索キーにしてください。

メッセージID（KFPL00793-I）

認可識別子

表識別子

メッセージ抽出例

KFPL00793-I Pdload execution abnormal terminated, table=user1."T1", RDAREA=RDAREA1, return code=8, pdload process id=1385412 (1212478)
　：
KFPL00793-I Pdload execution abnormal terminated, table=user1."T1", RDAREA=RDAREA2, return code=8, pdload process id=1385433 (1212478)

［説明］

認可識別子（user1）と表識別子（T1）を基に，KFPL00793-Iメッセージを抽出します。これによって，データロードに失敗したRDエリア（RDAREA1，RDAREA2）を特定できます。

特定したRDエリアに対して，KFPL00793-Iメッセージのリターンコードによって，次の対処をしてください。

≪リターンコードが4の場合≫

pdloadコマンドが出力したエラー情報ファイルを参照して，エラーに対処してください。エラー情報ファイルは，pdparaloadコマンドのsource文のerrorオプションで指定しています（ファイル名には自動的にRDエリア名称が付加されます）。指定を省略した場合は，次のディレクトリとファイル名称で作成されます。

エラー情報ファイルの格納ディレクトリ

1.　pd_tmp_directoryオペランドで指定したディレクトリ

2.　1.の指定がない場合，システム環境変数TMPで指定したディレクトリ

3.　2.の指定がない場合，%PDDIR%¥tmpディレクトリ

エラー情報ファイルの名称

(c)で特定するプロセスIDとメッセージID（KFPL00793-I）が含まれるファイル名

エラーに対処したら，(e)の手順に従って，RDエリア単位のデータロードを再実行してください。

≪リターンコードが8の場合≫

(c)，(d)の手順に従って，エラーの内容を特定し，対処してください。

その後，(e)の手順に従って，RDエリア単位のデータロードを再実行してください。

(c)　実行していたプロセスのIDを特定します

メッセージログファイルから，pdparaloadコマンドが実行したpdload制御プロセスとサーバプロセスのIDを特定します。次の手順でプロセスIDを抽出してください。

pdcatコマンドで，pdparaloadコマンドの実行開始（KFPL00791-Iメッセージ）から終了（KFPL00794-Iメッセージ）までの間のメッセージログをファイルに出力します。

1.で出力した内容からプロセスの開始を示すKFPL00711-Iメッセージを抽出します。メッセージを抽出する際には，次の項目を検索キーにしてください。

メッセージID（KFPL00711-I）

認可識別子

表識別子

(b)で特定したRDエリア名

メッセージ抽出例

1572976 2010/11/04 15:55:48 0mload1 lod KFPL00711-I pdloadm started, table=user1."T1", RDAREA=RDAREA1
1728690 2010/11/04 15:55:48 bes1    lod KFPL00711-I pdbes started, table=user1."T1", RDAREA=RDAREA1

［説明］

認可識別子（user1）と表識別子（T1）とRDエリア名（RDAREA1）を基に，KFPL00711-Iメッセージを抽出します。これによって，エラーが発生したプロセスのID（1572976，1728690）を特定できます。

この場合，それぞれのIDは次のプロセスを示しています。

1572976は，プロセス名がpdloadmであるため，pdload制御プロセスです。

1728690は，プロセス名がpdbesであるため，バックエンドサーバプロセスです。

(d)　エラーの内容を特定します

メッセージログファイルから，エラーの内容を特定します。(c)で特定したプロセスIDを検索キーにして，(c)の手順1.で取得したメッセージログファイルから対処が必要なエラーメッセージを抽出してください。

メッセージ抽出例（pdload制御プロセス）

1572976 2010/11/04 15:55:48 0mload1 lod KFPL00711-I pdloadm started, table=user1."T1", RDAREA=RDAREA1
1572976 2010/11/04 15:55:48 0mload1 lod KFPL00704-I Pdload terminated, return code=8

メッセージ抽出例（バックエンドサーバプロセス）

1728690 2010/11/04 15:55:48 bes1 lod KFPL00711-I pdbes started, table=user1."T1", RDAREA=RDAREA1
1728690 2010/11/04 15:55:48 bes1 lod KFPL00709-I Error information file was created, file=c:/tmp/ERROR-4cd258f41728690
1728690 2010/11/04 15:55:48 bes1 lod KFPL00709-I Lobmid file was created, file=c:/tmp/LOBMID-T1-4cd258f41728690
1728690 2010/11/04 15:55:48 bes1 lod KFPL00702-I Pdload started, table=user1."T1", generation=0
1728690 2010/11/04 15:55:48 bes1 lod KFPL00710-I Index information file assigned, index=user1."T1NX", RDAREA="USER01", file=c:/tmp/INDEX-T1NX-USER01-GN0-daan_ylid
1728690 2010/11/04 15:55:48 bes1 lod KFPL00723-I 0 rows loaded, table=user1."T1", RDAREA="USER01"
1728690 2010/11/04 15:55:48 bes1 lod KFPLxxxxx-E YYYYYY

［説明］

プロセスID（1572976，1728690）を基に，メッセージを抽出します。この場合，バックエンドサーバプロセスでエラーメッセージ（KFPLxxxxx-E）が出力されていることが分かります。このエラーメッセージに従って，対処します。

エラーに対処したら，(e)の手順に従って，RDエリア単位のデータロードを再実行してください。

(e)　RDエリア単位のデータロード（pdloadコマンド）を再実行します

pdloadコマンドでRDエリア単位のデータロードを再実行します。この際，pdparaloadコマンドが生成したpdloadコマンドの制御文を再利用することをお勧めします。pdparaloadコマンドが生成したpdloadコマンドの制御文ファイルの格納ディレクトリとファイル名を次に示します。これを基にpdloadの制御文ファイルを作成してください。

pdload制御文の格納ディレクトリ

1.　pd_tmp_directoryオペランドで指定したディレクトリ

2.　1.の指定がない場合，システム環境変数TMPで指定したディレクトリ

3.　2.の指定がない場合，%PDDIR%¥tmpディレクトリ

pdload制御文のファイル名

LOD_CTL_認可識別子_表識別子_RDエリアID

注意事項

RDエリア単位のデータロードを再実行する際には，pdloadのoption文でdivermsg=offを指定してください。

RDエリア単位にデータロードする場合，入力データ中にRDエリアの格納条件と一致しない行データがあると，エラーデータ情報を出力し，pdloadコマンドはリターンコード4で終了します。divermsg=offを指定すると，このエラーデータ情報の出力が抑止され，pdloadコマンドをリターンコード0で終了できます。

RDエリア単位データロードを再実行する場合の，pdloadコマンドの制御文とコマンドラインの例を次に示します。

制御文の例

option divermsg=off
source "RDUSER02" fes01:c:¥users¥data¥input_file error=¥users¥rep¥error_file_RDUSER02_101
lobdata c:¥users¥data¥lob
idxwork bes02 c:¥users¥work
sort bes02 c:¥users¥work
report file=c:¥users¥rep¥result_file_RDUSER02_101

［説明］

option文にdivermsg=offを指定することによって，エラーデータ情報の出力を抑止します。

RDエリア単位データロードのため，source文には対象とするRDエリア名称を指定します。

コマンドラインの例

pdload -d -b -k f -i c -l p "表2" "c:¥users¥tmp¥LOD_CTL_USER02_表2_101"

6.1.7　横分割表にデータをロードする場合（分割入力データファイルの作成）

横分割表にデータをロードする場合は，パラレルローディング機能を使う方法もあります。パラレルローディング機能については，「横分割表にデータをロードする場合（パラレルローディング機能）」を参照してください。パラレルローディング機能で期待する効果が得られない場合には，ここで説明する分割入力データファイルを使用したデータロードを適用してください。

横分割表にデータをロードする場合，格納するRDエリア単位に入力データファイルを分割してデータロードを並列実行すると，データロードに掛かる時間を短縮でき，表の占有時間が短縮できます。制御情報ファイルにsrc_work文を指定してデータベース作成ユティリティ（pdload）を実行すると，ユーザが作成した入力データファイルから，RDエリア単位の入力データファイルが作成できます。これによって，RDエリア単位にデータロードを実行できます。このとき，データベース作成ユティリティ（pdload）が作成するファイルを分割入力データファイルといいます。分割入力データファイルを作成する場合のオプション及び制御文については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

6.1.8　自動採番機能を使用したデータロード

順序数生成子を使用すると，自動的に採番ができます。これを自動採番機能といいます。データロード時に，順序数生成子が生成した順序番号を，表の列に格納できます。ここでは，順序番号の取得方式と格納方式の選択基準について説明します。

なお，自動採番機能についてはマニュアル「HiRDB UAP開発ガイド」を，自動採番機能を使用したデータロードの詳細についてはマニュアル「HiRDB コマンドリファレンス」を参照してください。

(1)　順序番号の取得方式の選択基準

順序番号の取得方式には，次の3種類があります。

全数一括取得方式：

データロード完了後に一括して順序数生成子の値を使用した順序番号にします。

指定単位取得方式：

指定した単位ごとに順序番号を取得しながらデータロードします。

バッファ単位取得方式：

入力バッファに読み込める行数分の順序番号を取得しながらデータロードします。

順序番号の取得方式は，次の表に示す特徴を考慮して選択してください。

表6‒3　順序番号の取得方式ごとの特徴

検討項目 | 特徴
全数一括取得方式 | 指定単位取得方式 | バッファ単位取得方式
正常時の欠番発生 | 発生しません。 | データロードした行数が指定した単位の倍数でなければ，欠番が発生します。 | 発生しません。※2
ロールバック時の大量の欠番発生 | 発生しません。 | 現在値はロールバックが発生しても回復されないため，大量の欠番が発生します。 | 現在値はロールバックが発生しても回復されないため，大量の欠番が発生します。
順序数生成子への採番要求時の通信オーバヘッド※1 | データロードのコミットの回数分しか採番要求をしないため，採番処理による性能への影響は小さくなります。 | 取得する単位を大きくすることで，採番要求の回数を抑え，性能への影響を小さくできます。 | 入力バッファ長を大きくすることで，採番要求の回数を抑え，性能への影響を小さくできます。ただし，1回に取得する単位は入力バッファ長と列の定義長から算出した行長で決まるため，行長が大きいと入力バッファに多くのメモリを必要とします。
同じ順序数生成子を使用するUAPとの同時実行 | 同時実行はできません。データロード中は順序数生成子に排他が掛かかります。 | 同時実行できます。 | 同時実行できます。
RDエリア単位のデータロードの並列実行 | 同時実行はできません。データロード中は順序数生成子に排他が掛かかります。 | 並列実行できます。 | 並列実行できます。

注※1

HiRDB/パラレルサーバの場合，データベース作成ユティリティが入力データを読み込むサーバと順序数生成子が定義されたサーバが異なるとき，順序番号の取得時に通信が発生します。そのため，採番要求が頻繁に行われると，通信回数が多くなり，データロードの性能に影響します。

注※2

順序番号の格納方式が列データ全置換以外の場合は，欠番が発生する可能性があります。

(2)　順序番号の格納方式の選択基準

順序番号の格納方式には，次の3種類があります。それぞれの選択基準について説明します。

列データ全置換：

順序番号を格納する列に対して，入力データファイル中の該当する列データをすべて順序番号に置き換えます。該当する列の値に，すべて新しく番号を振り直す場合に選択します。

列データ一部置換：

順序番号を格納する列に対して，入力データファイル中の該当する列データのうち，指定した置換条件に一致するデータだけ順序番号に置き換えます。例えば，入力データファイルがDAT形式，又は拡張DAT形式で，NULL値の部分だけ順序番号に置き換える場合などに選択します。

列データ追加：

順序番号を格納する列に対応するデータが入力データファイル中にない場合，順序番号を入力データとして追加します。番号を格納する列を新しく追加する場合に選択します。なお，入力データファイルがバイナリ形式の場合，この方式は指定できません。

6.1.9　入力データファイルUOC

任意に作成したプログラムで，データロードするデータを編集できます。編集されたデータは，直接pdloadに渡されます。そのため，入力ファイルを編集するプログラムで，いったんワークファイルを作成しない形でデータロードができます。

データを編集するためにユーザが作成したプログラムをUOC（ユーザオウンコーディング）といいます。UOCは，データベースに格納したいデータファイルがpdloadの入力データファイルのフォーマットと異なる場合や，データベースに格納したいデータがHiRDBの文字コードと異なる場合など，入力データの編集が必要なときに使用できます。

6.1.10　不要なRDエリアの削除

データベースを作成後，ディクショナリ表のSQL_RDAREAS表を検索して，表やインデクスが定義されなかったユーザ用RDエリア又はLOB列が定義されなかったユーザLOB用RDエリアがないかどうか確認することをお勧めします。もし不要なRDエリアがあれば，削除できます。不要なRDエリアを削除することで，ディスク所要量を削減できます。

ディクショナリ表の検索方法とSQL_RDAREAS表についてはマニュアル「HiRDB UAP開発ガイド」を，RDエリアの削除方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

6.2　横分割表の作成

6.2.1　横分割表の作成例

商品表を作成します。商品表の作成条件を次に示します。

商品表を横分割します。ユーザ用RDエリアRDAREA01〜RDAREA02に商品表を格納します。

商品表に分割キーインデクス（INDX1）を定義します。ユーザ用RDエリアRDAREA03〜RDAREA04にINDX1を格納します。

商品表に非分割キーインデクス（INDX2）を定義します。ユーザ用RDエリアRDAREA05にINDX2を格納します。HiRDB/パラレルサーバの場合は，ユーザ用RDエリアRDAREA05〜RDAREA06にINDX2を格納します。

RDAREA01〜RDAREA06にはデータロード対象表（インデクス）だけを格納していて，初期ロードとします。

データロードをするときにインデクスを一括作成（省略値）します。

ログレスモードでデータロードをします。

分割キーインデクス及び非分割キーインデクスについては，「インデクスの横分割」を参照してください。

また，横分割表にデータをロードする場合には，パラレルローディング機能を使う方法もあります。パラレルローディング機能については，「横分割表にデータをロードする場合（パラレルローディング機能）」を参照してください。

(1)　商品表の定義

CREATE TABLEで商品表を定義します。定義例を次に示します。

(a)　キーレンジ分割の場合

格納条件指定

    CREATE TABLE 商品表
    (商品番号 CHAR(5) NOT NULL,
     商品名 NCHAR(15),
     標準単価 INTEGER,
     数量 INTEGER
    )IN ((RDAREA01)商品番号<='10000',(RDAREA02));

境界値指定の場合

    CREATE TABLE 商品表
    (商品番号 CHAR(5) NOT NULL,
     商品名 NCHAR(15),
     標準単価 INTEGER,
     数量 INTEGER
     )PARTITIONED BY 商品番号
     IN ((RDAREA01)'10000',(RDAREA02));

(b)　フレキシブルハッシュ分割，FIXハッシュ分割の場合

    CREATE TABLE 商品表
    (商品番号 CHAR(5) NOT NULL,
     商品名 NCHAR(15),
     標準単価 INTEGER,
     数量 INTEGER
     )[FIX]※ HASH HASH6 BY 商品番号
     IN (RDAREA01,RDAREA02);

注※　FIXハッシュ分割の場合に指定します。

(2)　インデクスの定義

CREATE INDEXで商品表にインデクスを定義します。定義例を次に示します。

(a)　HiRDB/シングルサーバの場合

CREATE INDEX INDX1 ON 商品表 (商品番号)
    IN ((RDAREA03),(RDAREA04));
CREATE INDEX INDX2 ON 商品表 (数量)
    IN (RDAREA05);

(b)　HiRDB/パラレルサーバの場合

CREATE INDEX INDX1 ON 商品表 (商品番号)
    IN ((RDAREA03),(RDAREA04));
CREATE INDEX INDX2 ON 商品表 (数量)
    IN ((RDAREA05),(RDAREA06));

(3)　表へのデータの格納

データベース作成ユティリティ（pdload）で表にデータを格納します。格納手順を次に示します。

〈手順〉

pdholdコマンドで，データロード対象RDエリア（RDAREA01〜RDAREA05）を閉塞します。HiRDB/パラレルサーバの場合はRDAREA01〜RDAREA06を閉塞します。

pdloadコマンドで，入力データファイルを表にデータロードします。RDエリアにはデータロード対象表（インデクス）だけを格納していて，かつ初期ロードのため，データベースの更新ログ取得方式にログレスモードを選択します。また，インデクスの作成方法にインデクス一括作成モード（省略値）を選択します。pdloadコマンドに指定するオプションについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

ログレスモードでpdloadコマンドを実行しているため，データロード対象RDエリアのバックアップを取得します。RDエリア単位のバックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

pdrelsコマンドで，データロード対象RDエリアの閉塞を解除します。

上記のコマンドとユティリティの詳細及びこれらのコマンドとユティリティの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

補足事項

ログレスモードでpdloadコマンドを実行するため，前記の手順1〜3の間はデータロード対象RDエリアを閉塞したままにしてください。

改竄防止表に対してpdloadコマンドでデータロードするとき，-dオプションは使用できません。

インデクス一括作成中にエラーが発生した場合の対処方法については，「インデクス一括作成中に発生したエラーの対処方法」を参照してください。

(4)　データの格納状態の確認

データロードをした場合は，運用を開始する前にデータベース状態解析ユティリティ（pddbst）を実行して，データの格納状態を確認することをお勧めします。設計どおりにデータベースを作成できたかどうかを確認できます。データベース状態解析ユティリティ（pddbst）を実行すると，次に示す情報を取得できます。

ユーザ用RDエリア単位のデータの格納状態

表又はインデクス単位のデータの格納状態

6.3　LOB列を定義した表の作成

6.3.1　LOB列を定義した表の作成例

商品表を作成します。商品表の作成条件を次に示します。

商品表を横分割します。ユーザ用RDエリアRDAREA01〜RDAREA02に商品表のLOB列構成基表を格納します。

ユーザLOB用RDエリアLOBAREA01〜LOBAREA02にLOB列のデータを格納します。

商品表に分割キーインデクス（INDX1）を定義します。ユーザ用RDエリアRDAREA03〜RDAREA04にINDX1を格納します。

RDAREA01〜RDAREA04，LOBAREA01〜LOBAREA02にはデータロード対象表（インデクス）だけを格納していて，初期ロードとします。

データロードをするときにインデクスを一括作成（省略値）します。

ログレスモードでデータロードをします。

なお，横分割表にデータをロードする場合には，パラレルローディング機能を使う方法もあります。パラレルローディング機能については，「横分割表にデータをロードする場合（パラレルローディング機能）」を参照してください。

補足事項

一つのユーザLOB用RDエリアには，表中の一つのLOB列だけを格納します。また，一つの表に複数のLOB列がある場合には，それぞれ別のユーザLOB用RDエリアに格納する必要があります。

LOB列が横分割表の場合には，LOB列ごとにユーザLOB用RDエリアと，表を格納しているユーザ用RDエリアの数を1対1に対応させる必要があります。

(1)　商品表の定義

CREATE TABLEで商品表を定義します。定義例を次に示します。

(a)　キーレンジ分割の場合

格納条件指定

CREATE TABLE 商品表
(商品番号 CHAR(5),
 商品名 NCHAR(15),
 標準単価 INTEGER,
 数量 INTEGER,
 商品画像 BLOB(64K) IN ((LOBAREA01),(LOBAREA02))
)IN ((RDAREA01) 商品番号<='10000',(RDAREA02));

境界値指定

CREATE TABLE 商品表
(商品番号 CHAR(5),
 商品名 NCHAR(15),
 標準単価 INTEGER,
 数量 INTEGER,
 商品画像 BLOB(64K) IN ((LOBAREA01),(LOBAREA02))
)PARTITIONED BY 商品番号
IN ((RDAREA01)'10000',(RDAREA02));

(b)　フレキシブルハッシュ分割，FIXハッシュ分割の場合

CREATE TABLE 商品表
(商品番号 CHAR(5),
 商品名 NCHAR(15),
 標準単価 INTEGER,
 数量 INTEGER,
 商品画像 BLOB(6000) IN ((LOBAREA01),(LOBAREA02))
)[FIX]※ HASH HASH6 BY 商品番号
 IN (RDAREA01,RDAREA02);

注※　FIXハッシュ分割の場合に指定します。

(2)　インデクスの定義

CREATE INDEXで商品表にインデクスを定義します。定義例を次に示します。

CREATE INDEX INDX1 ON 商品表 (商品番号)
    IN ((RDAREA03),(RDAREA04));

(3)　表へのデータの格納

データベース作成ユティリティ（pdload）で表にデータを格納します。格納手順を次に示します。

〈手順〉

pdholdコマンドで，データロード対象RDエリア（RDAREA01〜RDAREA04，LOBAREA01〜LOBAREA02）を閉塞します。

pdloadコマンドで，入力データファイルを表にデータロードします。RDエリアにはデータロード対象表（インデクス）だけを格納していて，かつ初期ロードのため，データベースの更新ログ取得方式にログレスモードを選択します。また，インデクスの作成方法にインデクス一括作成モード（省略値）を選択します。pdloadコマンドに指定するオプションについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

ログレスモードでpdloadコマンドを実行しているため，データロード対象RDエリアのバックアップを取得します。RDエリア単位のバックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

pdrelsコマンドで，データロード対象RDエリアの閉塞を解除します。

上記のコマンドとユティリティの詳細及びこれらのコマンドとユティリティの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

補足事項

ログレスモードでpdloadコマンドを実行するため，前記の手順1〜3の間はデータロード対象RDエリアを閉塞したままにしてください。

改竄防止表に対してpdloadコマンドでデータロードするとき，-dオプションは使用できません。

インデクス一括作成中にエラーが発生した場合の対処方法については，「インデクス一括作成中に発生したエラーの対処方法」を参照してください。

(4)　データの格納状態の確認

データロードをした場合は，運用を開始する前にデータベース状態解析ユティリティ（pddbst）を実行して，データの格納状態を確認することをお勧めします。設計どおりにデータベースを作成できたかどうかを確認できます。データベース状態解析ユティリティ（pddbst）を実行すると，次に示す情報を取得できます。

ユーザ用RDエリア又はユーザLOB用RDエリア単位のデータの格納状態

表又はインデクス単位のデータの格納状態

(5)　補足事項

LOB列を定義した表にデータロードする場合，LOB列構成基表とLOBデータを別々にデータロードすることもできます。このときの手順を次に示します。

なお，データベースの更新ログ取得方式にログレスモードを，インデクスの作成方法にインデクス一括作成モード（省略値）を選択したとします。

〈手順〉

pdholdコマンドで，データロード対象RDエリア（RDAREA01〜RDAREA04，LOBAREA01〜LOBAREA02）を閉塞します。

pdloadコマンドで，入力データファイルを表（LOB列構成基表及びインデクス）にデータロードします。このときのデータロード対象RDエリアはRDAREA01〜RDAREA04になります。このとき，LOB中間ファイルにLOB列のデータロード時に必要な情報を出力するようにしてください。pdloadコマンドに指定するオプションについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

pdloadコマンドで，ユーザLOB用RDエリアLOBAREA01〜LOBAREA02にデータロードします。このとき，LOB入力ファイルと2.で作成したLOB中間ファイルを指定します。

ログレスモードでpdloadコマンドを実行しているため，データロード対象RDエリアのバックアップを取得します。RDエリア単位のバックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

pdrelsコマンドで，データロード対象RDエリアの閉塞を解除します。

上記のコマンドとユティリティの詳細及びこれらのコマンドとユティリティの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

6.4　プラグインが提供する抽象データ型を定義した表の作成

ここでは，プラグインが提供する抽象データ型（SGMLTEXT型，XML型）を定義した表の作成について説明します。

SGMLTEXT型を使用する場合にはHiRDB Text Search Plug-in，XML型を使用する場合にはHiRDB XML Extensionが必要です。プラグインの環境設定については，「プラグインの環境設定」を参照してください。なお，プラグインの所有者はMASTERにしてください。

6.4.1　SGMLTEXT型

ここでは，HiRDB Text Search Plug-inが提供する抽象データ型（SGMLTEXT型）を定義した表の作成方法について説明します。

ここでは，薬品管理表を作成します。薬品管理表の作成条件を次に示します。

薬品管理表を横分割します。ユーザ用RDエリアRDAREA01〜RDAREA02に薬品管理表のLOB列構成基表を格納します。

ユーザLOB用RDエリアLOBAREA01〜LOBAREA02にSGMLTEXT型の列のデータを格納します。

ユーザLOB用RDエリアLOBAREA03〜LOBAREA04にプラグインインデクスを格納します。

RDAREA01〜RDAREA02，LOBAREA01〜LOBAREA04にはデータロード対象表（インデクス）だけを格納していて，初期ロードとします。

データロードをするときにインデクスを一括作成（省略値）します。

ログレスモードでデータロードをします。

〔説明〕

薬品ID（MCHAR型）をユーザ用RDエリアに格納し，取扱説明書（SGMLTEXT型）をユーザLOB用RDエリアに格納します。

(1)　薬品管理表の定義

CREATE TABLEで薬品管理表を定義します。定義例を次に示します。

(a)　キーレンジ分割の場合

格納条件指定

CREATE TABLE 薬品管理表(
薬品ID MCHAR(15),
取扱説明書 SGMLTEXT          …1
  ALLOCATE(SGMLTEXT IN((LOBAREA01),(LOBAREA02)))  …2
  PLUGIN'<DTD>medicine.dtd</DTD>'       …3
  )IN((RDAREA01)薬品ID<='薬品10',(RDAREA02));    …4

境界値指定

CREATE TABLE 薬品管理表(
薬品ID MCHAR(15),
取扱説明書 SGMLTEXT          …1
  ALLOCATE(SGMLTEXT IN((LOBAREA01),(LOBAREA02)))  …2
  PLUGIN'<DTD>medicine.dtd</DTD>'       …3
  )PARTITIONED BY 薬品ID
  IN((RDAREA01)'薬品10',(RDAREA02));             …4

〔説明〕

プラグインモジュールで提供されたデータ型を指定します。

薬品管理表中のLOB列（SGMLTEXT）をユーザLOB用RDエリアLOBAREA01及びLOBAREA02に分割して格納します。

プラグインオプションを指定します。指定方法については，プラグインのマニュアルを参照してください。

薬品管理表のLOB列構成基表をユーザ用RDエリアRDAREA01，RDAREA02に分割して格納します。

(b)　フレキシブルハッシュ分割，FIXハッシュ分割の場合

CREATE TABLE 薬品管理表(
薬品ID MCHAR(15),
取扱説明書 SGMLTEXT               …1
  ALLOCATE(SGMLTEXT IN((LOBAREA01),(LOBAREA02)))  …2
  PLUGIN'<DTD>medicine.dtd</DTD>'       …3
  )[FIX]※ HASH HASH6 BY 薬品ID
  IN(RDAREA01,RDAREA02)                 …4

注※　FIXハッシュ分割の場合に指定します。

〔説明〕

プラグインモジュールで提供されたデータ型を指定します。

薬品管理表中のLOB列SGMLTEXTをユーザLOB用RDエリアLOBAREA01及びLOBAREA02に分割して格納します。

プラグインオプションを指定します。指定方法については，プラグインのマニュアルを参照してください。

薬品管理表のLOB列構成基表をユーザ用RDエリアRDAREA01，RDAREA02に分割して格納します。

(2)　プラグインインデクスの定義

プラグインによって提供されたデータ検索用のインデクス型をインデクスに定義するとデータを高速に検索できます。プラグインから提供されたインデクス型を定義したインデクスをプラグインインデクスといいます。ここでは，HiRDB Text Search Plug-inが提供するインデクス型（NGRAM）を使用したプラグインインデクスの定義方法について説明します。

CREATE INDEXで薬品管理表にプラグインインデクスを定義します。定義例を次に示します。

  CREATE INDEX PLGINDX1
          USING TYPE NGRAM
          ON 薬品管理表(取扱説明書)
          IN ((LOBAREA03),(LOBAREA04));

〔説明〕

プラグインインデクスPLGINDX1を横分割した薬品管理表に対応させて，ユーザLOB用RDエリアLOBAREA03及びLOBAREA04に分割して格納します。なお，プラグインインデクスPLGINDX1を構成する列に取扱説明書列を指定しています。

(3)　表へのデータの格納

データベース作成ユティリティ（pdload）で表にデータを格納します。格納手順を次に示します。

〈手順〉

pdholdコマンドで，データロード対象RDエリア（RDAREA01〜RDAREA02，LOBAREA01〜LOBAREA04）を閉塞します。

pdloadコマンドで，入力データファイルを表にデータロードします。RDエリアにはデータロード対象表（インデクス）だけを格納していて，かつ初期ロードのため，データベースの更新ログ取得方式にログレスモードを選択します。また，インデクスの作成方法にインデクス一括作成モード（省略値）を選択します。また，コンストラクタ関数やコンストラクタ関数に渡すデータ型の情報を列構成情報ファイルに指定します。pdloadコマンドに指定するオプションについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

ログレスモードでpdloadコマンドを実行しているため，データロード対象RDエリアのバックアップを取得します。RDエリア単位のバックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

pdrelsコマンドで，データロード対象RDエリアの閉塞を解除します。

上記のコマンドとユティリティの詳細及びこれらのコマンドとユティリティの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

補足事項

ログレスモードでpdloadコマンドを実行するため，前記の手順1〜3の間はデータロード対象RDエリアを閉塞したままにしてください。

改竄防止表に対してpdloadコマンドでデータロードするとき，-dオプションは使用できません。

インデクス一括作成中にエラーが発生した場合の対処方法については，「インデクス一括作成中に発生したエラーの対処方法」を参照してください。

(4)　データの格納状態の確認

データロードをした場合は，運用を開始する前にデータベース状態解析ユティリティ（pddbst）を実行して，データの格納状態を確認することをお勧めします。設計どおりにデータベースを作成できたかどうかを確認できます。データベース状態解析ユティリティ（pddbst）を実行すると，次に示す情報を取得できます。

ユーザ用RDエリア及びユーザLOB用RDエリア単位（物理解析だけ）のデータの格納状態

レジストリ用RDエリア及びレジストリLOB用RDエリア単位（物理解析，論理解析）のデータの格納状態

(5)　ハッシュ関数で分割条件を指定している表にRDエリア単位でデータロードする場合

表分割ハッシュ関数を使用したUAPを作成し，RDエリア単位に入力データファイルを作成できます。これによって，各RDエリアに格納されるデータ量が確認できるため，均等に分割できるハッシュ関数を選択できます。表分割ハッシュ関数を使用したUAPの作成方法については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

6.4.2　XML型

ここでは，HiRDB XML Extensionが提供する抽象データ型（XML型）を定義した表の作成方法について説明します。

ここでは，書籍管理表を作成します。書籍管理表の作成条件を次に示します。

ユーザ用RDエリアRDAREA01に書籍管理表を格納します。

ユーザ用RDエリアRDAREA02に部分構造インデクスを格納します。

ユーザLOB用RDエリアLOBAREA01にXML型全文検索用インデクスを格納します。

RDAREA01，RDAREA02，LOBAREA01にはデータロード対象表（インデクス）だけを格納していて，初期ロードとします。

データロードをするときにインデクスを一括作成（省略値）します。

ログレスモードでデータロードをします。

(1)　書籍管理表の定義

CREATE TABLEで書籍管理表を定義します。定義例を次に示します。

XML型の列を含む表の定義例

CREATE TABLE 書籍管理表 (書籍ID INTEGER, 書籍情報 XML) IN RDAREA01

(2)　インデクスの定義

(a)　部分構造インデクス（B-tree）

XML型の列には，特定の部分構造をキーとし，その値をキー値としたインデクスを定義できます。このインデクスを利用すると，XMLEXISTS述語やXMLQUERY関数のXQuery式中に，部分構造インデクスを定義した構造に対する述語を指定した場合，行の絞り込みの処理時間を削減できることがあります。

部分構造インデクスを利用できるXQuery式中の述語を次に示します。

キーである部分構造に対する比較式（=，!=，>，>=，<，<=，<>，eq，ne，lt，le，gt，ge）

キーである部分構造に対するfn:contains関数，fn:starts-with関数，fn:ends-with関数

インデクスの使用条件については，「インデクスの使用条件」で説明します。

部分構造インデクスを使用した検索については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(b)　XML型全文検索用インデクス（n-gram）

XML型の列には，XML型の値に対する全文検索用のn-gramインデクス（IXXML）を定義できます。XML型全文検索用インデクスを定義することで，XMLEXISTS述語のXQuery式中で文字列一致などの全文検索条件を含む述語を記述した場合に，行の絞り込みの処理時間を削減できることがあります。

XML型全文検索の条件となるXQuery式中の述語を次に示します。

文字列（xs:string型）同士の完全一致（=）

fn:contains関数

fn:starts-with関数

fn:ends-with関数

hi-fn:contains関数

インデクスの使用条件については，「インデクスの使用条件」で説明します。

XML型全文検索用インデクスを使用した検索については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(3)　表へのデータの格納

表へデータを格納する場合の入力データには，次の二つがあります。入力データの種類によって，データの格納方法が異なります。

XML文書をXML挿入データに変換したESIS-B形式

この場合は，XML変換コマンド（phdxmlcnv）又はXML変換ライブラリ（Javaライブラリ）を使用してXML文書を解析し，XML挿入データ（ESIS-B形式といいます）を生成します。このESIS-B形式のデータをバイナリ形式にして出力し，pdload又はINSERT文を使用して表へ格納します。

XML変換コマンド及びXML変換ライブラリについては，マニュアル「HiRDB XML Extension」を参照してください。

XML文書

この場合は，データベース作成ユティリティ（pdload）又はXMLPARSE関数を使用してXML文書をXML挿入データ（ESIS-B形式）に変換し，表へ格納します。XML文書からESIS-B形式への変換はpdload又はXMLPARSE関数の中で行われます。pdload内でESIS-B形式への変換を行う場合には，-Gオプションを指定します。

(a)　データロード

データベース作成ユティリティ（pdload）で表にデータを格納する場合の手順を次に示します。

〈手順〉

pdholdコマンドで，データロード対象RDエリア（RDAREA01，RDAREA02，LOBAREA01）を閉塞します。

pdloadコマンドで，入力データファイルを表にデータロードします。

XML文書をそのまま入力データとする場合は-Gオプションを指定します。

RDエリアにはデータロード対象表（インデクス）だけを格納していて，かつ初期ロードのため，データベースの更新ログ取得方式にログレスモードを選択します。

インデクスの作成方法にインデクス一括作成モード（省略値）を選択します。

コンストラクタ関数やコンストラクタ関数に渡すデータ型の情報を列構成情報ファイルに指定します。

入力データファイルの形式をバイナリ形式に設定します。

pdloadコマンドに指定するオプションについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

ログレスモードでpdloadコマンドを実行しているため，データロード対象RDエリアのバックアップを取得します。RDエリア単位のバックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

pdrelsコマンドで，データロード対象RDエリアの閉塞を解除します。

上記のコマンドとユティリティの詳細及びこれらのコマンドとユティリティの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

補足事項

ログレスモードでpdloadコマンドを実行するため，前記の手順1〜3の間はデータロード対象RDエリアを閉塞したままにしてください。

改竄防止表に対してpdloadコマンドでデータロードするとき，-dオプションは使用できません。

インデクス一括作成中にエラーが発生した場合の対処方法については，「インデクス一括作成中に発生したエラーの対処方法」を参照してください。

(b)　XML文書の挿入

ESIS-B形式のデータを表へ挿入又は更新する場合

INSERT文の挿入値，又はUPDATE文の更新値にXMLコンストラクタ関数を指定し，その引数に生成したESIS-B形式のデータを設定します。

書籍管理表に埋込み変数bookinfoに格納されたXML文書（ESIS-B形式）の値を挿入する例を次に示します。

XML文書（ESIS-B形式）の挿入例

INSERT INTO 書籍管理表
  VALUES ( 310494321, XML(:bookinfo AS BINARY(102400)))

XML文書を表へ挿入又は更新する場合

INSERT文の挿入値，又はUPDATE文の更新値にXMLPARSE関数を指定し，その引数にXML文書を設定します。

書籍管理表に埋込み変数bookdocに格納されたXML文書の値を挿入する例を次に示します。

XML文書の挿入例

INSERT INTO 書籍管理表
  VALUES ( 310494321, XMLPARSE(DOCUMENT :bookdoc AS BINARY(32000)))

(4)　インデクスの使用条件

ここでは，(2)で説明した二つのインデクスの使用条件について説明します。

部分構造インデクスの使用条件

部分構造インデクスを定義した場合，次の表に示す部分構造インデクスの使用条件を満たすと，インデクスが使用されます。

表6‒4　部分構造インデクスの使用条件

USING UNIQUE TAGの指定 | XQuery指定箇所 | XQuery中の演算子又は関数 | 部分構造インデクスの使用条件※1
あり | XMLEXISTS述語 | = | (a)1，2，3※2，3 (b)1，2，5，6，7※2，8，9

!=，>，>=，<，<=，<>，eq，ne，gt，ge，lt，le，

fn:contains，

fn:starts-with，

fn:ends-with

(a)1，2，3※2，3

(b)1，2，4，6，7※2，8，9

XMLQUERY関数 | = | (c)1，2，3
なし | XMLEXISTS述語 | = | (a)1，2，3※2，3 (b)1，3，5，6，7※2，8，9，11※3
!=，>，>=，<，<=，<> | (a)1，2，3※2，3 (b)1，3，4，6，7※2，8，9，11※3
fn:contains fn:starts-with fn:ends-with | (a)1，2，3※2，3 (b)1，3，4，6，7※2，8，10，11※3
XMLQUERY関数 | = | (c)1，2，3

注※1

(a)は，(a)で説明する部分構造インデクス及びXML型全文検索用インデクス共通の使用条件を示します。

(b)は，(b)で説明する部分構造インデクスの使用条件を示します。

(c)は，(c)で説明するXMLQUERY関数のXQueryに関する部分構造インデクスの使用条件を示します。

また，数字は(a)，(b)，及び(c)での項番に対応しています。

注※2

XMLEXISTS述語のXQuery問合せにXQuery論理式（OR）を指定する場合，インデクスが使用されます。

注※3

XMLEXISTS述語のXQuery問合せにXQuery論理式（AND）を指定する場合，インデクスが使用されます。

XML型全文検索用インデクスの使用条件

XML型全文検索用インデクスを定義した場合，次の表に示すXML型全文検索用インデクスの使用条件を満たすと，インデクスが使用されます。

表6‒5　XML型全文検索用インデクスの使用条件

XQuery指定箇所 | XQuery中の演算子又は関数 | XML型全文検索用インデクスの使用条件※1

XMLEXISTS述語

fn:contains

fn:starts-with

fn:ends-with

=

(a)1，2，3※2，3

(d)1，2，4，5，6，7，8

hi-fn:contains | (a)1，2，3※2，3 (d)1，3，4，5，6，7，8

注※1

(a)は，(a)で説明する部分構造インデクス及びXML型全文検索用インデクス共通の使用条件を示します。

(d)は，(d)で説明するXML型全文検索用インデクスの使用条件を示します。

また，数字は(a)及び(d)での項番に対応しています。

注※2

XMLEXISTS述語のXQuery問合せにXQuery論理式（OR）を指定する場合，インデクスが使用されます。

注※3

XMLEXISTS述語のXQuery問合せにXQuery論理式（AND）を指定する場合，インデクスが使用されます。

複数のインデクスを使用できる演算子又は関数の場合

部分構造インデクスとXML型全文検索用インデクスの両方を使用できるXQuery中の演算子又は関数を使用して検索を行う場合，評価に使用するインデクスは演算子又は関数によって決まります。演算子又は関数ごとに，どのインデクスが使用されるかを次の表に示します。

表6‒6　複数のインデクスが使用できる演算子又は関数の評価に使用するインデクス

項番 | 演算子又は関数 | 評価に使用するインデクス
1 | = | 部分構造インデクス
2 | fn:contains | XML型全文検索用インデクス
3 | fn:starts-with | 部分構造インデクス
4 | fn:ends-with | XML型全文検索用インデクス

使用するインデクスを指定したい場合は，使用インデクスのSQL最適化指定をします。詳細については，マニュアル「HiRDB SQLリファレンス」の「使用インデクスのSQL最適化指定」を参照してください。

なお，HiRDBが見積もるアクセスコストによっては，これらのインデクスを使用しないことがあります。インデクスを使用した検索が行われたかどうかについては，アクセスパス表示ユティリティ（pdvwopt）で確認してください。

また，XMLEXISTS述語のXQuery問合せ中に指定した，部分構造インデクス，又はXML型全文検索インデクスを使用できる述語については，最大で255個しかインデクスを用いて評価しません。

(a)　部分構造インデクス及びXML型全文検索用インデクス共通の使用条件

部分構造インデクス及びXML型全文検索用インデクス共通の使用条件を次に示します。

なお，次のように定義したインデクスを例文中で使用します。

create index idx1 on t1(c1) key using unique tag from '/root/elm1/@attr1' as varchar(10)

XMLEXISTS述語のXML問合せ引数にXML問合せ文脈項目を指定している。

（例）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 eq "ABC"]'
        passing by value c1,'DEF' as A)

注　アンダーライン部分がXML問合せ文脈項目です。

XMLEXISTS述語のXQuery問合せ中に指定した文脈項目式（ピリオド）をすべてXQuery述語中に指定している。

（例）

select c2 from t1
  where xmlexists('/root/elm1[./@attr1 eq "ABC"]' passing by value c1)

注　アンダーライン部分がXQuery述語中に指定した文脈項目式です。

XMLEXISTS述語のXQuery問合せ中のXQuery論理式（AND，OR）をすべてXQuery述語中に指定している。

（例）

select c2 from t1
  where xmlexists('/root[elm1/@attr1 = "ABC" or elm1/@attr1 = "DEF"]'
        passing by value c1)

注　アンダーライン部分がXQuery述語中に指定したXQuery論理式です（OR）。

(b)　XMLEXISTS述語のXQueryに関する部分構造インデクスの使用条件

XMLEXISTS述語のXQueryに関する部分構造インデクスの使用条件を次に示します。

なお，1.，2.，4.〜9.では，次のように定義したインデクスを例文中で使用します。

　create index idx1 on t1(c1) key using unique tag from '/root/elm1/@attr1' as varchar(10)
　create index idx4 on t1(c1) key using unique tag from '/root/elm1/elm2' as varchar(10)

3.，10.，11.では，次のように定義したインデクスを例文中で使用します。

　create index idx2 on t1(c1) key from '/root/elm1/@attr1' as varchar(10)
　create index idx5 on t1(c1) key from '/root/elm1/elm2' as varchar(10)

インデクスの部分構造指定と，XMLEXISTS述語のXQuery問合せ中で条件として指定した部分構造パスが一致する。

（例）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 eq "ABC"]' passing by value c1)

注　アンダーライン部分が一致する部分構造パスです。

USING UNIQUE TAGの指定がある部分構造インデクスの場合，汎用比較，値比較，fn:contains関数，fn:starts-with関数，又はfn:ends-with関数を使用して，XMLEXISTS述語のXQuery問合せ中で条件として指定した部分構造パスを比較する。

（例）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 eq "ABC"]' passing by value c1)

注　アンダーライン部分がXQuery比較式です（値比較）。

USING UNIQUE TAGの指定がない部分構造インデクスの場合，汎用比較，fn:contains関数，fn:starts-with関数，又はfn:ends-with関数を使用して，XMLEXISTS述語のXQuery問合せ中で条件として指定した部分構造パスを比較する。

（例）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 = "ABC"]' passing by value c1)

注　アンダーライン部分がXQuery比較式です（汎用比較）。

汎用比較又は値比較と，fn:contains関数，fn:starts-with関数，又はfn:ends-with関数の場合に分けて説明します。

＜汎用比較，又は値比較の場合＞

汎用比較，又は値比較で比較する対象は，XMLEXISTS述語のXQuery問合せ中で条件として指定した部分構造パスと，一つのXQuery定数又はXQuery変数である。

（例）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 >= "ABC"]' passing by value c1)

注　アンダーライン部分が部分構造パスとXQuery定数の比較です。

＜fn:contains関数，fn:starts-with関数，又はfn:ends-with関数の場合＞

fn:contains関数，fn:starts-with関数，又はfn:ends-with関数の第1引数がXMLEXISTS述語のXQuery問合せ中で条件として指定した部分構造パスで，かつ第2引数が一つのXQuery定数又はXQuery変数である。

（例）

select c2 from t1
  where xmlexists('/root/elm1[fn:starts-with(@attr1,"ABC")]' passing by value c1)

注　アンダーライン部分が部分構造パスとXQuery定数の比較です。

=で比較する対象は，XMLEXISTS述語のXQuery問合せ中で条件として指定した部分構造パスと，システム共通定義pd_apply_search_ats_numオペランドの指定値以下のXQuery定数又はXQuery変数から成るXQueryシーケンス連結式である。

（例）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 = ("ABC","DEF","GHI")]'
        passing by value c1)

注　アンダーライン部分がシステム共通定義pd_apply_search_ats_numオペランドの指定値以下のXQuery定数から成るXQueryシーケンス連結式です。

部分構造インデクス定義時に指定したキー値のデータ型が，XMLEXISTS述語のXQuery問合せ中で条件として指定した部分構造パスと比較するXQuery定数若しくはXQuery問合せ中のXQuery変数に渡す値式のデータ型と同じ，又は変換可能である。

（例）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 = "ABC"]' passing by value c1)

注　アンダーライン部分が，キー値のデータ型であるVARCHAR型と同じstring型データです。

XMLEXISTS述語のXQuery問合せに指定したXQuery論理式（OR）オペランドに部分構造インデクスを使用できる条件だけを含む。

（例）

select c2 from t1
  where xmlexists('/root[elm1/@attr1 = "ABC" or elm1/@attr1 = "DEF"]'
        passing by value c1)

注　アンダーライン部分が，すべて部分構造インデクスを使用できる条件です。

4.又は5.で，条件として指定した部分構造パスと比較する値としてXQuery変数を指定した場合，そのXQuery変数に渡す値式が次のどれかである。

定数

USER値関数

値式が?パラメタ，SQLパラメタ，又はSQL変数のCAST指定

外への参照なしスカラ副問合せ

（例1）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 eq $A]'
        passing by value c1,'ABC' as A)

注　アンダーライン部分がXQuery問合せ中のXQuery変数に渡す値式です（定数）。

（例2）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 eq $A]'
        passing by value c1,cast(? as varchar(256)) as A)

注　アンダーライン部分が，XQuery問合せ中のXQuery変数に渡す値式（値式が?パラメタ，SQLパラメタ，又はSQL変数のCAST指定）です。

値比較，又は汎用比較で比較する対象の部分構造パスが次の形式で指定されている。又は，USING UNIQUE TAGの指定がある部分構造インデクスの場合で，かつfn:contains関数，fn:starts-with関数，又はfn:ends-with関数の第1引数を含む部分構造パスが次の形式で指定されている。

部分構造パス:: = 〔XML名前空間宣言〕…部分構造パス式
XML名前空間宣言::=｛declare namespace 接頭辞 = XML名前空間URI;
                  | declare default element namespace XML名前空間URI;｝
部分構造パス式:: = 〔/ステップ式…〕/ステップ式
ステップ式:: = {〔{child:: | attribute:: | @ }〕 修飾名 | 文脈項目式｝
文脈項目式:: = ピリオド
ピリオド::= .
修飾名:: = 〔接頭辞:〕局所名

＜値比較又は汎用比較を使用した例＞

次の（例1）〜（例3）は，値比較又は汎用比較を使用した例です。これらの例で値比較演算子eqにほかの値比較又は汎用比較を指定した場合も，インデクスを使用します。なお，USING UNIQUE TAGの指定有無に関するインデクスの使用条件については，2.及び3.を参照してください。

（例1）ステップ式に@又はattribute::と，修飾名を指定した場合（@とattribute::は同じ意味）

select c2 from t1
  where xmlexists('/root/child::elm1[@attr1 eq "ABC"]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例2）ステップ式にchild::を指定，又はchild::を省略し，修飾名を指定した場合

select c2 from t1
  where xmlexists('/root/child::elm1[child::elm2 eq "ABC"]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例3）ステップ式に文脈項目式を指定した場合（値比較は使用条件2.に該当する場合だけ）

select c2 from t1
  where xmlexists('/root/child::elm1/elm2[ . eq "ABC"]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

＜XQuery関数を使用した例＞

次の（例4）〜（例6）は，XQuery関数を使用した例です。これらの例でfn:starts-with関数にほかのXQuery関数を指定した場合も，インデクスを使用します。

（例4）ステップ式に@又はattribute::と，修飾名を指定した場合（@とattribute::は同じ意味）

select c2 from t1
  where xmlexists('/root/elm1[fn:starts-with(@attr1 ,"ABC")]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例5）ステップ式にchild::を指定，又はchild::を省略し，修飾名を指定した場合

select c2 from t1
  where xmlexists('/root/elm1[fn:starts-with(elm2 ,"ABC")]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例6）ステップ式に文脈項目式を指定した場合

select c2 from t1
  where xmlexists('/root/elm1/@attr1[fn:starts-with( . ,"ABC")]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

USING UNIQUE TAGの指定がない部分構造インデクスの場合で，かつfn:contains関数，fn:starts-with関数，又はfn:ends-with関数の第1引数を含む部分構造パスが次の形式で指定されており，さらに第1引数が次のステップ式終端の形式で指定されている。

部分構造パス:: = 〔XML名前空間宣言〕…部分構造パス式
XML名前空間宣言::=｛declare namespace 接頭辞 = XML名前空間URI;
                  | declare default element namespace XML名前空間URI;｝
部分構造パス式:: = 〔/ステップ式…〕/ステップ式終端
ステップ式:: = {〔{child:: | attribute:: | @ }〕 修飾名 | 文脈項目式｝
ステップ式終端:: = {{attribute:: | @ } 修飾名 | 文脈項目式｝
文脈項目式:: = ピリオド
ピリオド::= .
修飾名:: = 〔接頭辞:〕局所名

次に示す例でfn:starts-with関数にほかのXQuery関数を指定した場合も，インデクスを使用します。

（例1）ステップ式終端に@又はattribute::と，修飾名を指定した場合（@とattribute::は同じ意味）

select c2 from t1
  where xmlexists('/root/elm1[fn:starts-with(@attr1 ,"ABC")]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例2）ステップ式終端に文脈項目式を指定した場合

select c2 from t1
  where xmlexists('/root/elm1/@attr1[fn:starts-with( . ,"ABC")]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

USING UNIQUE TAGの指定がない部分構造インデクスで，次のどちらかの条件を満たす。

XMLEXISTS述語のXQuery問合せのXQuery論理式（AND）オペランドに同じノードを複数回指定していない。

XMLEXISTS述語のXQuery問合せのXQuery論理式（AND）オペランドに同じノードを複数回指定しているが，汎用比較，又はfn:contains関数，fn:starts-with関数，若しくはfn:ends-with関数の第1引数で指定する同じノードが，次のステップ式終端の形式で指定されている。

　ステップ式終端 ：：＝ ｛｛attribute:: | @｝ 修飾名 | 文脈項目式｝
　修飾名 ：：＝ 〔接頭辞:〕局所名
　文脈項目式 ：：＝ ピリオド
　ピリオド ：：＝ .

＜部分構造インデクスを使用する例＞

XMLEXISTS述語のXQuery問合せのXQuery論理式（AND）オペランドに同じノードを複数回指定していない場合の例

（例1）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 >= "A01" and elm2 <= "A99"]'
        passing by value c1);

　注　アンダーライン部分が同じノードを複数回指定していない部分構造パスです。

（例2）

select c2 from t1
  where xmlexists('/root/elm1[fn:starts-with(@attr1 ,"A01") and elm2 = "A01"]'
        passing by value c1);

　注　アンダーライン部分が同じノードを複数回指定していない部分構造パスです。

XMLEXISTS述語のXQuery問合せのXQuery論理式（AND）オペランドに同じノードを複数回指定した場合の例

（例3）汎用比較の比較項に@又はattribute::と，修飾名を指定した場合（@とattribute::は同じ意味）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 >= "A01" and @attr1 <= "A99"]'
        passing by value c1);

　注　アンダーライン部分が形式と一致する部分構造パスです。

（例4）fn:contains関数，fn:starts-with関数，又はfn:ends-with関数の第1引数に@又はattribute::と，修飾名を指定した場合（@とattribute::は同じ意味）

select c2 from t1
  where xmlexists('/root/elm1[fn:starts-with(@attr1 ,"A") and fn:ends-with(@attr1 ,"01")]'
        passing by value c1);

　注　アンダーライン部分が形式と一致する部分構造パスです。

（例5）汎用比較の比較項に文脈項目式を指定した場合

select c2 from t1
  where xmlexists('/root/elm1/elm2[. >= "A01" and . <= "A99"]'
        passing by value c1);

　注　アンダーライン部分が形式と一致する部分構造パスです。

（例6）fn:contains関数，fn:starts-with関数，又はfn:ends-with関数の第1引数に文脈項目式を指定した場合

select c2 from t1
  where xmlexists('/root/elm1/elm2 [fn:contains(. ,"A") and fn:contains(. ,"01")]'
        passing by value c1);

　注　アンダーライン部分が形式と一致する部分構造パスです。

＜部分構造インデクスを使用しない例＞

（例1）汎用比較の比較項の@attr1の前にelm1が指定されているため，形式と一致しない場合

select c2 from t1
  where xmlexists('/root[elm1/@attr1 >= "A01" and elm1/@attr1 <= "A99"]'
        passing by value c1);

　注　アンダーライン部分が形式と一致しない部分構造パスです。

（例2）fn:contains関数，fn:starts-with関数，又はfn:ends-with関数の第1引数の@attr1の前にelm1が指定されているため，形式と一致しない場合

select c2 from t1
  where xmlexists('/root[fn:starts-with(elm1/@attr1 ,"A")
                 and fn:ends-with(elm1/@attr1 ,"01")]'
        passing by value c1);

　注　アンダーライン部分が形式と一致しない部分構造パスです。

（例3）汎用比較の比較項に，属性又は文脈項目以外の同じノードが複数回指定されているため，形式と一致しない場合

select c2 from t1
  where xmlexists('/root/elm1[elm2 >= "A01" and elm2 <= "A99"]'
        passing by value c1);

　注　アンダーライン部分が形式と一致しない部分構造パスです。

（例4）fn:contains関数，fn:starts-with関数，又はfn:ends-with関数の第1引数に，属性又は文脈項目以外の同じノードが複数回指定されているため，形式と一致しない場合

select c2 from t1
  where xmlexists('/root/elm1[fn:starts-with(elm2 ,"A") and fn:ends-with(elm2 ,"01")]'
        passing by value c1);

　注　アンダーライン部分が形式と一致しない部分構造パスです。

(c)　XMLQUERY関数のXQueryに関する部分構造インデクスの使用条件

XMLQUERY関数のXQueryに関する部分構造インデクスの使用条件を次に示します。

なお，1.及び2.では，次のように定義したインデクスを例文中で使用します。

　create index idx1 on t1(c1) key using unique tag from '/root/elm1' as varchar(10)

SQLが次のすべての条件を満たす。

SELECT文，又はINSERT〜SELECT文である

主問合せの選択式が一つである

上記の主問合せの選択式がXMLQUERYである（ただし，XMLSERIALIZEの引数がXMLQUERYでもよい）

上記のXMLQUERYのXML問合せ引数がXML問合せ変数一つで，かつ変数に渡す値式はXMLAGGである

上記のXML問合せ変数に指定したXMLAGGの引数は列指定単独である

表の結合を指定していない

集合演算を指定していない

副問合せを指定していない

集合関数を指定していない

GROUP BY句を指定していない

HAVING句を指定していない

WHERE句が指定されている場合，ANDの指定数が255以下である

SQLの例については，2.の例を参照してください。

XMLQUERY関数に指定したXQueryが次のすべての条件を満たす。

a. XML問合せ変数をルートとするパス式である

b. 最も外側のXQuery述語の指定が一つだけ存在する

c. b.の述語で汎用比較'='による比較を行っている

d. c.の比較が，XML列の特定の部分構造とXQuery変数をルートとするパス式の比較である

（例）

select xmlserialize(xmlquery('$VAR1/root[elm1 = $VAR1/root[elm2 = "ABC"]/elm1]/elm1'
  passing by value xmlagg(c1) as VAR1 empty on empty) as varchar(32000)) from t1

注　アンダーライン部分が上記の条件と一致する箇所です。

2.のd.のXML列の特定の部分構造，及びXQuery変数をルートとするパス式に，同じデータ型の部分構造インデクスを定義している（これらのインデクスは同一のものでもかまいません）。

(d)　XML型全文検索用インデクスの使用条件

XML型全文検索用インデクスの使用条件を次に示します。

検索対象のXML型の列に全文検索インデクスを定義している。

（例）

create index idx3 using type ixxml on t2(c1) in (LOB1)

fn:contains関数，fn:starts-with関数，又はfn:ends-with関数の第1引数を含む部分構造パスが次の形式で指定されており，さらに第1引数が次のテキストステップ式終端，又は属性ステップ式終端の形式で指定されている。又は=で比較する対象の部分構造パスが次の形式で指定されており，XQuery述語中に指定した部分構造パスが次のテキストステップ式終端又は属性ステップ式終端の形式で指定されている。

部分構造パス:: = 〔XML名前空間宣言〕… 部分構造パス式
XML名前空間宣言:: = ｛declare default element namespace
                   "http://www.w3.org/XML/1998/namespace";
                 ｜declare namespace 接頭辞 = XML名前空間URI;※
                 ｜declare default element namespace XML名前空間URI;※｝
部分構造パス式:: = 〔｛/ | //※｝ステップ式 …〕
                     ｛/ | //※｝｛テキストステップ式 | 属性ステップ式終端｝
ステップ式:: = ｛〔child::〕 名前テスト | 文脈項目式}
テキストステップ式:: = 〔{child::｜descendant::}〕テキストテスト
                          /テキストステップ式終端
テキストステップ式終端:: = 文脈項目式
属性ステップ式終端:: = {{attribute:: | @} 名前テスト
                   | 〔{attribute:: | @}〕 属性テスト}
文脈項目式:: = ピリオド
ピリオド:: = .
名前テスト:: = ｛修飾名｜*※｜接頭辞:*※｜*:局所名※}
修飾名:: = 〔接頭辞:〕局所名

注※　HiRDB XML Extensionのバージョンが08-04以降の場合に指定できます。

次に示す例でfn:contains関数にほかのXQuery関数を指定した場合も，インデクスを使用します。

（例1）第1引数に@又はattribute::と，名前テストを指定した場合（@とattribute::は同じ意味）

select c2 from t2
  where xmlexists('/root/child::elm1[fn:contains(@attr1,"ABC")]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例2）第1引数に@又はattribute::と，属性テストを指定した場合（@とattribute::は同じ意味）

select c2 from t2
  where xmlexists('/root/child::elm1[fn:contains(@attribute(),"ABC")]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例3）第1引数に属性テストだけを指定した場合

select c2 from t2
  where xmlexists('/root/child::elm1[fn:contains(attribute(),"ABC")]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例4）第1引数に文脈項目式を指定した場合

select c2 from t2
  where xmlexists('/root/child::elm1/text()[fn:contains( . ,"ABC")]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

hi-fn:contains関数の第1引数を含む部分構造パスが次の形式で指定されており，さらに第1引数が次のテキストステップ式，テキストステップ式終端，又は属性ステップ式終端の形式で指定されている。また，HiRDB XML Extensionのバージョンが08-04以降である。

部分構造パス:: = 〔XML名前空間宣言〕… 部分構造パス式
XML名前空間宣言:: = {declare namespace 接頭辞 = XML名前空間URI;
                   ｜declare default element namespace XML名前空間URI;｝
部分構造パス式:: = 〔｛/ | //｝ステップ式 …〕
                    ｛/ | //｝｛テキストステップ式 | 属性ステップ式終端｝
ステップ式:: = {〔child::〕 名前テスト | 文脈項目式}
テキストステップ式:: = 〔{child::｜descendant::}〕テキストテスト
                       〔/テキストステップ式終端〕
テキストステップ式終端:: = 文脈項目式
属性ステップ式終端:: = {{attribute:: | @} 名前テスト
                   | 〔{attribute:: | @}〕 属性テスト}
文脈項目式:: = ピリオド
ピリオド:: = .
名前テスト:: = {修飾名 | * | 接頭辞:* | *:局所名}
修飾名:: = 〔接頭辞:〕局所名

（例1）第1引数にテキストテストを指定した場合

select c2 from t2
  where xmlexists('/root/elm1[hi-fn:contains(text(),”””ABC AND DEF”””)]'
        passing by value c1)

select c2 from t2
  where xmlexists('/root/elm1[hi-fn:contains(descendant::text(),”””ABC AND DEF”””)]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例2）第1引数にテキストテスト及び文脈項目式を指定した場合

select c2 from t2
  where xmlexists('/root/elm1[hi-fn:contains(text()/.,”””ABC AND DEF”””)]'
        passing by value c1)

select c2 from t2
  where xmlexists('/root/elm1[hi-fn:contains(descendant::text()/.,”””ABC AND DEF”””)]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例3）第1引数に文脈項目式を指定した場合

select c2 from t2
  where xmlexists('/root/elm1/text()[hi-fn:contains( . ,”””ABC AND DEF”””)]'
        passing by value c1)

select c2 from t2
  where xmlexists('/root/elm1/ descendant::text()[hi-fn:contains( . ,”””ABC AND DEF”””)]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例4）第1引数に@又はattribute::と，名前テストを指定した場合（@とattribute::は同じ意味）

select c2 from t2
  where xmlexists('/root/elm1[hi-fn:contains(@attr1,”””ABC AND DEF”””)]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例5）第1引数に@又はattribute::と，属性テストを指定した場合（@とattribute::は同じ意味）

select c2 from t2
  where xmlexists('/root/elm1[hi-fn:contains(@attribute(),”””ABC AND DEF”””)]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

（例6）第1引数に属性テストだけを指定した場合

select c2 from t2
  where xmlexists('/root/elm1[hi-fn:contains(attribute(),”””ABC AND DEF”””)]'
        passing by value c1)

　注　アンダーライン部分が上記の形式と一致する部分構造パスです。

XMLEXISTS述語のXQuery問合せ中に指定した文字列の長さが32,000バイト以下である。

（例）

select c2 from t2
  where xmlexists('/root/elm1[fn:contains(@attr1,"ABCDEF")]'
        passing by value c1)

注　アンダーライン部分が32,000バイト以下の文字列です。

2.又は3.の形式で指定した部分構造パスと比較する値が文字列のXQuery定数である。

（例）

select c2 from t2
  where xmlexists('/root/child::elm1[fn:contains(@attr1,"ABC")]'
        passing by value c1)

注　アンダーライン部分が文字列のXQuery定数です。

XMLEXISTS述語のXQuery問合せ中の部分構造パス式に指定した，/，//，@，及び局所名の長さの和（部分構造パス式の1文字目の/は除く）が1,024バイト以下である。

（例）

select c2 from t2
  where xmlexists('/root/elm1[fn:contains(@attr1,"ABCDEF")]'
        passing by value c1)

注　アンダーライン部分が1,024バイト以下の部分構造パス式です。

XMLEXISTS述語のXQuery問合せ中に指定した部分構造パス式中での//の指定が一つ以内である。

（例）

select c2 from t2
  where xmlexists('/root/elm1[fn:contains(@attr1,"ABCDEF")]'
        passing by value c1)

注　アンダーライン部分が//の指定が一つ以内の部分構造パス式です。

検索対象のXML型の列に定義した全文検索インデクスに，次のどのプラグインオプションも指定していない。

DELcode=ファイル名

NOindex=ファイル名

ENGLISH

ENGLISH_STANDARD

プラグインオプションの詳細については，マニュアル「HiRDB XML Extension」を参照してください。

（例）

create index idx6 using type ixxml on t2(c1) in (LOB1)
PLUGIN'SAMECASE=ON,SAMEWIDE=ON,SAMEY=ON,SAMED=ON,DELcode=ON'

注　アンダーライン部分がインデクスを使用できるオプションだけを指定した全文検索インデクスです。

(e)　インデクスを使用しない場合

次に示す場合は，部分構造インデクス又はXML型全文検索用インデクスを使用しません。

なお，1.及び3.では，次のように定義したインデクスを例文中で使用します。

　create index idx1 on t1(c1) key using unique tag from '/root/elm1/@attr1' as varchar(10)

2.，及び4.では，次のように定義したインデクスを例文中で使用します。

　create index idx3 using type ixxml on t2(c1) in (LOB1)

‘/root[elm1/@attr1’が”ABC”又は”DEF”であるかを評価するXQueryをXMLEXISTS述語のXQuery問合せに指定する場合

次の例では，XMLEXISTS述語のXQuery問合せ中のXQuery論理式（AND，OR）すべてをXQuery述語中に指定していないため，インデクスを使用しません。この指定方法では，XMLEXISTS述語の引数のXQuery問合せ（XQuery述語中を除く）に直接XQuery論理式を指定しているため，XQuery問合せの結果は必ず真か偽どちらかのブーリアン値になります。このため，XQuery問合せの結果は空のシーケンスではないのでXMLEXISTS述語の結果は常に真となり，意図した結果になりません（XMLEXISTS述語はXQuery問合せの結果が空のシーケンスの場合だけ偽になり，それ以外は真になる）。

（例：変更前）

select c2 from t1
  where xmlexists('/root[elm1/@attr1 = "ABC"] or /root[elm1/@attr1 = "DEF"]'
        passing by value c1)

注　アンダーライン部分がXQuery述語中に指定していないXQuery論理式（OR）です。

次のように変更すると，インデクスを使用するようになります。

（例：変更後）

select c2 from t1
  where xmlexists('/root[elm1/@attr1 = "ABC" or elm1/@attr1 = "DEF"]'
        passing by value c1)

注　アンダーライン部分がXQuery述語中に指定したXQuery論理式（OR）です。

‘/root/elm1’以下のテキストノードを検索するXQueryをXMLEXISTS述語のXQuery問合せに指定する場合

次の例では，contains関数の第1引数を含む部分構造パスのテキストステップ式終端が，(4)(c)の2.で示した形式と一致しないため，インデクスを使用しません。

（例：変更前）

select c2 from t2
  where xmlexists('/root[fn:contains(elm1/text(),"ABC")]' passing by value c1)

注　アンダーライン部分が，(4)(c)の2.で示した形式と一致しない部分構造パスです。

次のように変更すると，インデクスを使用するようになります。

（例：変更後）

select c2 from t2
  where xmlexists('/root/elm1/text()[fn:contains( . ,"ABC")]'
        passing by value c1)

注　アンダーライン部分が，(4)(c)の2.で示した形式と一致する部分構造パスです。

‘/root/elm1/@attr1/’が”ABC”であるかを評価するXQueryをXMLEXISTS述語のXQuery問合せに指定する場合

XMLEXISTS述語のXQuery問合せ中で条件として指定した部分構造パスの部分構造パス式が，(4)(b)の9.で示した形式と一致しないため，インデクスを使用しません。

（例：変更前）

select c2 from t1
  where xmlexists('$A/root/elm1[@attr1 eq "ABC"]'
        passing by value c1,c1 as A)

注　アンダーライン部分が，(4)(b)の9.で示した形式と一致しない部分構造パスです。

次のように変更すると，インデクスを使用するようになります。

（例：変更後）

select c2 from t1
  where xmlexists('/root/elm1[@attr1 eq "ABC"]'
        passing by value c1,c1 as A)

注　アンダーライン部分が，(4)(b)の9.で示した形式と一致する部分構造パスです。

論理演算子（OR，AND）でXMLEXISTS述語を多数連結した場合

HiRDBが見積もるアクセスコストによって，インデクスを使用しない方が最適なアクセスパスとなると判断し，XMLEXISTS述語の評価にインデクスを使用しません。hi-fn:contains関数を指定した場合はインデクスだけで評価できないため，SQLエラーとなります。

（例：変更前）

select c2 from t2
  where xmlexists('/root/elm1[hi-fn:contains(text(),””"01ABC””")]'
        passing by value c1)
     or xmlexists('/root/elm1[hi-fn:contains(text(),””"02ABC””")]'
        passing by value c1)
        …（省略）…
     or xmlexists('/root/elm1[hi-fn:contains(text(),"””30ABC"””)]'
        passing by value c1)

注　アンダーライン部分が，単独の指定ではインデクスを使用するXMLEXISTS述語を30個指定した条件です。

次のように使用インデクスのSQL最適化指定をすると，インデクスを使用するようになります。

（例：変更後）

select c2 from t2 with index(idx3,idx3)
  where xmlexists('/root/elm1[hi-fn:contains(text(),””"01ABC””")]'
        passing by value c1)
     or xmlexists('/root/elm1[hi-fn:contains(text(),””"02ABC””")]'
        passing by value c1)
        …（省略）…
     or xmlexists('/root/elm1[hi-fn:contains(text(),"””30ABC"””)]'
        passing by value c1)

注　アンダーライン部分が，複数インデクス利用の実行に必要な種類のインデクスを指定した，インデクスのSQL最適化指定です。

6.5　ユーザが定義した抽象データ型を定義した表の作成

6.5.1　抽象データ型の定義

抽象データ型とルーチンを使用して，複雑な構造を持つデータ型とその操作を独自に定義し，利用できます。

(1)　定義方法

任意の構造を持つデータ型（抽象データ型）を定義するには，定義系SQLのCREATE TYPEを実行します。CREATE TYPEでは，データ構造とそのデータに対する操作を定義します。ここでは，次に示すデータ構造を持つ抽象データ型「t_従業員」を定義し，それに対する操作を関数として定義します。

データ構造

氏名，性別，役職，入社年月日，顔写真，基本給というデータ構造を定義します。

データ操作

現在の日付と入社年月日から勤続年数を算出します。

勤続年数に応じた報酬率を算出します。

基本給に報酬率を乗じて従業員の報酬を算出します。

（例）

 CREATE TYPE t_従業員 (             …1
    PUBLIC    氏名    NCHAR(16),
              性別    CHAR(1),
              役職    NCHAR(10),
    PRIVATE   入社年月日 date,      …2
    PUBLIC    顔写真  BLOB(64K),
    PROTECTED 基本給  INTEGER,      …3

    PUBLIC FUNCTION t_従業員(p_氏名 NCHAR(16),   …4
                  p_性別 CHAR(1),
                  p_役職 NCHAR(10),
                  p_入社年月日 date,
                  p_顔写真 BLOB(64K),
                  p_基本給 INTEGER)
             RETURNS t_従業員
        BEGIN
             DECLARE d_従業員 t_従業員;    …5
             SET d_従業員=t_従業員();      …6
             SET d_従業員..氏名=p_氏名;    …7
             SET d_従業員..性別=p_性別;    …7
             SET d_従業員..役職=p_役職;    …7
             SET d_従業員..入社年月日=p_入社年月日;   …7
             SET d_従業員..顔写真=p_顔写真;    …7
             SET d_従業員..基本給=p_基本給;    …7
             RETURN d_従業員;                  …8
        END,

    PUBLIC FUNCTION 勤続年数(p t_従業員) RETURNS INTEGER   …9
        BEGIN
             DECLARE working_years INTERVAL YEAR TO DAY;
             SET working_years=CURRENT_DATE - p..入社年月日;
             RETURN YEAR(working_years);
        END,

    PROTECTED FUNCTION 報酬率(p t_従業員) RETURNS FLOAT    …10
        BEGIN
             DECLARE rate FLOAT;
             SET rate=勤続年数(p)*0.2/30;
             RETURN rate;
        END,

    PUBLIC FUNCTION 報酬(p t_従業員) RETURNS INTEGER   …11
        BEGIN
             DECLARE bonus INTEGER;
             SET bonus=p..基本給*報酬率(p);
             RETURN bonus;
        END
  )

〔説明〕

データ構造の定義です。抽象データ型「t_従業員」を定義します。

「t_従業員」型の属性「入社年月日」は，報酬査定の算出に使用します。この属性は，外部から直接参照又は変更する必要がないため，隠蔽レベル「PRIVATE」を指定しています。隠蔽レベルについては，「抽象データ型を含む表」を参照してください。

「t_従業員」型の属性「基本給」は，報酬査定の算出に使用します。この属性も，外部から直接参照又は変更する必要がありません。ただし，この属性はサブタイプでも共通に参照するため，隠蔽レベル「PROTECTED」を指定しています。隠蔽レベルについては，「抽象データ型を含む表」を参照してください。

ユーザ定義のコンストラクタ関数を定義します。

値（インスタンス）を生成し，関数の戻り値とするためのSQL変数をt_従業員型で宣言します。

システムが提供するデフォルトコンストラクタ関数によって，すべての属性の値がナル値である値（インスタンス）を生成します。デフォルトコンストラクタ関数は，引数なしのt_従業員型と同じ名称の関数です。

6.で指定した値に対し，コンポネント指定による代入文で，各属性の値を代入します。コンストラクタ関数の引数から得た値を設定したり，その値を使ってデータを加工したものを代入したりできます。

RETURN文によって，新しく生成した値（インスタンス）を戻り値とします。戻り値のデータ型は，t_従業員型でなければなりません。これは，抽象データ型名と同じ名前のコンストラクタ関数であること及びRETURNS句で型を決めているためです。

データ操作のための関数です。従業員の勤続年数を返します。現在の日付と入社年月日から算出します。隠蔽レベル「PRIVATE」が指定されている属性「入社年月日」にアクセスする関数です。

データ操作のための関数です。従業員の報酬率を返します。勤続年数に応じて算出します。

データ操作のための関数です。従業員の報酬を返します。基本給に報酬率を乗じて，勤続年数に応じた従業員の報酬を算出します。

(2)　継承を利用する場合の定義方法

抽象データ型「t_従業員」をスーパタイプとするサブタイプ「t_営業部員」の定義例を次に示します。

（例）

CREATE TYPE t_営業部員 UNDER t_従業員
(       PUBLIC 担当顧客       NCHAR(15),
        PUBLIC FUNCTION 報酬(p t_営業部員) RETURNS INTEGER
          BEGIN
              DECLARE salebonus INTEGER;
              SET salebonus = 顧客総数(・・・)*1000+p..基本給*報酬率(p);
              RETURN salebonus;
          END
)

(3)　抽象データ型のナル値

操作系SQLのINSERT文で値が明示的に指定されない場合，抽象データ型全体の値はナル値になります。

(4)　抽象データ型のサブタイプを削除する方法

表定義で，ある抽象データ型を直接指定していない場合でも，その抽象データ型の上位の抽象データ型（スーパタイプ）が列の型に指定されている場合，代替可能性によってその抽象データ型（サブタイプ）の値は表に格納されている場合があります。このため，抽象データ型（サブタイプ）を削除する場合には注意が必要です。

次の図に示す代替可能性を利用した抽象データ型を含む表の場合にサブタイプを削除する方法について説明します。

図6‒7　代替可能性を利用した抽象データ型を含む表の例

[picture]

社員表を削除します。

t_従業員のサブタイプ「t_営業部員」を削除します。

t_従業員を削除します。

t_A社従業員のサブタイプ「t_A社営業部員」を削除します。

t_A社従業員を削除します。

抽象データ型のサブタイプを削除できないケースについては，「注意」を参照してください。

(5)　注意

コンストラクタ関数を指定して値を生成している場合，抽象データ型を構成する各属性の値がナル値であっても，抽象データ型全体としての値はナル値にはなりません。

ある抽象データ型及びそのスーパタイプが表で定義されている場合，その抽象データ型のサブタイプは削除できません。

ある抽象データ型及びそのスーパタイプが，ほかの抽象データ型の属性に指定されている場合，その抽象データ型のサブタイプは削除できません。

サブタイプを定義する場合，作成するデータ型の上位のデータ型に次に示す条件を満足するストアドプロシジャ及びストアドファンクションがあると，それらは無効状態になります。

ストアドプロシジャ及びストアドファンクションのSQLパラメタに指定したデータ型

関数の戻り値のデータ型

ストアドプロシジャ及びストアドファンクションから呼び出している関数の引数及び戻り値のデータ型

ストアドプロシジャ及びストアドファンクション中で指定しているデータ型（コンポネント指定で抽象データ型をアクセスする場合，その途中のデータ型を含みます）

6.5.2　表の定義

表を構成する列のデータ型の違いによって，RDエリアに格納する単位が異なります。ここでは，社員No，文書データ（LOBデータ）及び抽象データ型「t_従業員」から構成される社員表の例について説明します。

なお，抽象データ型の列を含む表のうち，抽象データ型の列を除いた部分で構成される表を抽象データ型列構成基表といいます。

〔説明〕

社員表をディスクA,Bのユーザ用RDエリアRDAREA01とRDAREA02に，社員表中の文書データ（LOB列）をユーザLOB用RDエリアLOBAREA01とLOBAREA02に，社員表中の抽象データ型（LOB属性）顔写真の列をユーザLOB用RDエリアLOBAREA03とLOBAREA04に分割して格納します。

(1)　キーレンジ分割の場合

格納条件指定

CREATE TABLE 社員表
(社員番号 CHAR(6),
 文書データ BLOB(64K) IN ((LOBAREA01),(LOBAREA02)),
 従業員 t_従業員 ALLOCATE(顔写真
     IN ((LOBAREA03),(LOBAREA04)))
    )IN ((RDAREA01)社員番号<=700000,(RDAREA02));

境界値指定

CREATE TABLE 社員表
(社員番号 CHAR(6),
 文書データ BLOB(64K) IN ((LOBAREA01),(LOBAREA02)),
 従業員 t_従業員 ALLOCATE(顔写真
     IN ((LOBAREA03),(LOBAREA04)))
    )PARTITIONED BY 社員番号
     IN ((RDAREA01)800000,(RDAREA02));

(2)　フレキシブルハッシュ分割，FIXハッシュ分割の場合

CREATE TABLE 社員表
(社員番号 CHAR(6),
 文書データ BLOB(64K) IN ((LOBAREA01),(LOBAREA02)),
 従業員 t_従業員 ALLOCATE(顔写真
     IN ((LOBAREA03),(LOBAREA04)))
    )[FIX]※ HASH HASH6 BY 社員番号
     IN (RDAREA01,RDAREA02);

注※　FIXハッシュ分割の場合に指定します。

6.5.3　インデクスの定義

「社員番号」列にインデクスを定義します。なお，抽象データ型の列にはインデクスを定義できません。

（例）

CREATE INDEX INDX1 ON 社員表 (社員番号)
 IN ((RDAREA03),(RDAREA04));

〔説明〕

分割キーインデクスINDX1を横分割した社員表に対応させて，ユーザ用RDエリアRDAREA03とRDAREA04に分割して格納します。なお，インデクスINDX1を構成する列に社員番号を指定しています。

6.5.4　表へのデータの格納

ユーザが定義した抽象データ型を定義した表にデータを格納するには，操作系SQLのINSERT文を実行します。データベース作成ユティリティ（pdload）でデータロードはできません。データを挿入するには，関数を定義して値を生成したものをINSERT文で挿入します。抽象データ型の列を含む表にデータを挿入するときの手順を次の図に示します。

図6‒8　抽象データ型の列を含む表にデータを挿入する手順

[picture]

6.5.5　データベースの更新ログ取得方式

(1)　データベースの更新ログ取得方式の種類

データベースの更新ログ取得方式には，次に示す3種類のモードがあります。

ログ取得モード

ロールバック及びロールフォワードに必要なデータベース更新ログを取得します。データ件数が少ない場合の追加データ作成，再編成の場合に使用します。

更新前ログ取得モード

ロールバックに必要なデータベース更新ログだけを取得します。データ件数が多いときの初期作成，追加データ作成及び再編成の場合に使用します。

ログレスモード

データベース更新ログを取得しません。一つのRDエリアに一つの表だけ（分割格納している場合は一つの横分割表）格納している場合で，関連するインデクスも一つのRDエリア内にあるときの初期作成，再編成の場合に使用します。

(2)　データベースの更新ログ取得方式の指定方法

データベースの更新ログ取得方式の指定方法は，次に示すものがあります。

クライアント環境定義のPDDBLOGに指定する方法※1

CREATE TABLEのRECOVERYオペランドに指定する方法※2

注※1

ユーザ用RDエリアを更新するUAPの，データベースの更新ログ取得方式を指定するオペランドです。

注※2

ユーザLOB用RDエリアを更新するUAPの，データベースの更新ログ取得方式を指定するオペランドです。

注意事項

ユーザLOB用RDエリアのデータベースの更新ログ取得方式（CREATE　TABLEのRECOVERYオペランド指定値）は，クライアント環境定義の指定値によって変わることがあります。クライアント環境定義によって変わるユーザLOB用RDエリアのデータベースの更新ログ取得方式を次の表に示します。

表6‒7　クライアント環境定義によって変わるユーザLOB用RDエリアのデータベースの更新ログ取得方式

クライアント環境定義 PDDBLOG | CREATE TABLEのRECOVERYオペランドの指定値
ALL | PARTIAL | NO
ALL | ALL | PARTIAL | NO
NO | NO | NO | NO

（凡例）

ALL：ログ取得モード

PARTIAL：更新前ログ取得モード

NO：ログレスモード

例えば，CREATE TABLEのRECOVERYオペランドに「PARTIAL」を指定し，クライアント環境定義のログ取得モードが「NO」の場合，NO（ログレスモード）がユーザLOB用RDエリアに設定されます。

6.5.6　データの格納状態の確認

抽象データ型の列を含む表にデータを挿入した場合は，運用を開始する前にデータベース状態解析ユティリティ（pddbst）を実行して，データの格納状態を確認することをお勧めします。設計どおりにデータベースを作成できたかどうかを確認できます。

データベース状態解析ユティリティ（pddbst）を実行すると，RDエリア単位のデータの格納状態（物理解析だけ）の情報を取得できます。

6.6　インデクス一括作成中に発生したエラーの対処方法

インデクス一括作成中にエラーが発生した場合，表へのデータ格納は完了しても，インデクスは未完成という不整合な状態になります。ここでは，この状態を回復する方法について説明します。データベース作成ユティリティ（pdload）でインデクス一括作成中にエラーが発生した場合のインデクスの状態を次の図に示します。

図6‒9　データベース作成ユティリティ（pdload）でインデクス一括作成中にエラーが発生した場合のインデクスの状態

[picture]

6.6.1　ログ取得モード又は更新前ログ取得モードでデータロードをしていた場合

更新前ログ取得モード又はログ取得モードでデータロードをしていた場合の対処方法を説明します。

なお，プラグインインデクスを定義している場合，そのプラグインにプラグインインデクス一括作成部分回復機能があることを前提とします。プラグインにプラグインインデクス一括作成部分回復機能がない場合は，「ログレスモードでデータロードをしていた場合」を参照してください。

発生したエラー原因に応じて，インデクス格納RDエリアを回復します。次に示す手順で回復してください。

(1)　インデクス格納RDエリアの容量不足がエラー原因の場合

インデクス格納RDエリアを拡張します。

インデクスを作成します。データベース作成ユティリティ（pdload）が作成したインデクス情報ファイルを基にインデクスを一括作成します。

なお，データベース作成ユティリティ（pdload）が作成したインデクス情報ファイルが残っていない場合は，データベース再編成ユティリティ（pdrorg）でインデクスを再作成します。

(2)　ソート処理エラー（KFPL15062-Eメッセージが出力）又はpdcancelコマンドによるユティリティの強制終了が原因の場合

インデクスを作成します。データベース作成ユティリティ（pdload）が作成したインデクス情報ファイルを基にインデクスを一括作成します。

なお，データベース作成ユティリティ（pdload）が作成したインデクス情報ファイルが残っていない場合は，データベース再編成ユティリティ（pdrorg）でインデクスを再作成します。

(3)　ディスク障害が原因の場合

障害となったディスクを交換し，バックアップからユティリティ実行前の状態に戻します。ただし，手順2で実行するインデクスロードが完了するまでアクセスされないように，RDエリアを閉塞状態にしてください。

データベース再編成ユティリティ（pdrorg）でインデクスを再作成します。

6.6.2　ログレスモードでデータロードをしていた場合

ログレスモードでデータロードをしていた場合又はプラグインにプラグインインデクス一括作成部分回復機能がない場合の対処方法を説明します。

発生したエラー原因に応じて，インデクス格納RDエリアを回復します。次に示す手順で回復してください。

(1)　インデクス格納RDエリアの容量不足がエラー原因の場合

インデクス格納RDエリアを再初期化します。

なお，バックアップからも回復できますが，その場合はインデクスロードが完了するまでアクセスされないよう，RDエリアを閉塞状態にしてください。また，次の場合はバックアップから回復する必要があります。

インデクス格納RDエリアに該当インデクスとは別の表やインデクス，又は改竄防止表が格納されている

インデクス格納RDエリアを拡張します。

データベース再編成ユティリティ（pdrorg）でインデクスを再作成します。

(2)　ソート処理エラー（KFPL15062-Eメッセージが出力）又はpdcancelコマンドによるユティリティの強制終了が原因の場合

インデクス格納RDエリアを再初期化します。

なお，バックアップからも回復できますが，その場合はインデクスロードが完了するまでアクセスされないよう，RDエリアを閉塞状態にしてください。また，次の場合はバックアップから回復する必要があります。

インデクス格納RDエリアに該当インデクスとは別の表やインデクス，又は改竄防止表が格納されている

データベース再編成ユティリティ（pdrorg）でインデクスを再作成します。

(3)　ディスク障害が原因の場合

障害となったディスクを交換し，バックアップからユティリティ実行前の状態に戻します。

データベース再編成ユティリティ（pdrorg）でインデクスを再作成します。

6.7　同期点指定のデータロード実行中にユティリティが異常終了したときの対処方法

ここでは，同期点指定のデータロードの実行中に，データベース作成ユティリティが異常終了したときの対処方法を説明します。

6.7.1　対処方法の概要

異常終了したタイミングによって対処方法が異なります。同期点指定のデータロード実行中にユティリティが異常終了したときの対処方法を次の図に示します。

図6‒10　同期点指定のデータロード実行中にユティリティが異常終了したときの対処方法

[picture]

〔説明〕

総データロード件数を300万件，同期点行数を100万件としています。

1，3，5の時点でユティリティが異常終了した場合は，データロードを再実行してください。

2，4の時点でユティリティが異常終了した場合は，作成に失敗したプラグインインデクスをデータベース再編成ユティリティのインデクス一括作成機能（-k ixmk）で作成してください。その後，データロードを再実行してください。

6の時点でユティリティが異常終了した場合は，作成に失敗したプラグインインデクスをデータベース再編成ユティリティのインデクス一括作成機能（-k ixmk）で作成してください。その後，データベース再編成ユティリティのインデクス再作成機能（-k ixrc）でB-treeインデクスを作成してください。

7の時点でユティリティが異常終了した場合，インデクス情報ファイルが作成されていれば（KFPL00710-Iメッセージが出力されていれば），データベース再編成ユティリティのインデクス一括作成機能（-k ixmk）でB-treeインデクスを作成してください。インデクス情報ファイルが作成されていなければ，データベース再編成ユティリティのインデクス再作成機能（-k ixrc）でB-treeインデクスを作成してください。

6.7.2　例題

300万件のデータロード中にデータベース作成ユティリティが異常終了しました。インデクス一括作成モードで，同期点行数は100万件とします。

(1)　メッセージを確認します

次に示すメッセージが出力されています。

KFPL00800-I Loading until 2000000th row committed

KFPL00710-I Index information file assigned, index=k87m271."INDX01",
RDAREA="LOB02", file=/pdrorg/INDX01_2

KFPL00715-I Index load started at bes2, index=k87m271."INDX01", RDAREA="LOB02"

〔説明〕

KFPL00800-Iメッセージから，200万件までデータロード処理が完了していることが分かります。

KFPL00715-Iメッセージから，プラグインインデクスの作成処理が開始されていることが分かります。それに対応する完了メッセージ（KFPL00716-I）が出力されていません。

これによって，100〜200万件のプラグインインデクス作成中に，ユティリティが異常終了したことが分かります。

(2)　pdrorgコマンドでプラグインインデクスを一括作成します

データベース再編成ユティリティで，100万件（100〜200万件）分のプラグインインデクスを一括作成します。

pdrorg -k ixmk -t TABLE1 C:¥pdrorg¥rorg01

〔説明〕

-k：プラグインインデクスを一括作成するためixmkを指定します。

-t：表の名称を指定します。

C:¥pdrorg¥rorg01：

pdrorgコマンドの制御文ファイル名を指定します。制御文ファイルの内容を次に示します。制御文ファイル中に指定するインデクス情報ファイルは(1)で出力されるKFPL00710-Iメッセージから分かります。

index INDX01 LOB02 C:¥pdrorg¥INDX01_2

(3)　データロードを再実行します

pdload TABLE1 C:¥pdload¥load01

〔説明〕

オプションの指定を変更する必要はありません。

(4)　データロード対象RDエリアのバックアップを取得します

データロード対象RDエリアのバックアップを取得します。RDエリア単位のバックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(5)　pdrelsコマンドでデータロード対象RDエリアの閉塞を解除します

pdrels -r DATA01,DATA02,DATA03,INX01,INX02,INX03,LOB01,LOB02,LOB03

コマンドの実行後，実行結果が正しいかどうか確認することをお勧めします。コマンドの実行結果の確認方法については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

7　ほかの製品との連携

この章では，HiRDBとほかの製品とを連携する方法について説明します。

7.1　レプリケーション機能との連携

HiRDBのレプリケーション機能（HiRDB Datareplicator，HiRDB Dataextractor）を使用するときに指定する項目について説明します。

7.1.1　HiRDB Datareplicatorとの連携

HiRDB Datareplicatorを使用すると，HiRDBのデータベースの更新に連動して自動的にデータを抽出し，そのデータベース更新内容をほかのHiRDBのデータベースに反映できます。HiRDB Datareplicatorを使用するには，HiRDBシステム定義で次に示すオペランドを指定します。

pd_rpl_init_startオペランド

HiRDB Datareplicator連携機能をHiRDB開始時から使用するかどうかを指定します。

pd_rpl_hdepathオペランド

抽出側HiRDB Datareplicator運用ディレクトリ名を指定します。ここで指定するディレクトリ名は，抽出側HiRDB Datareplicatorの環境変数HDEPATHで指定した名称にしてください。

pd_log_rpl_no_standby_file_oprオペランド

HiRDB Datareplicator連携機能の使用時に，HiRDB Datareplicatorでのシステムログの抽出が完了していないため，すべてのシステムログファイルがスワップ先にできない状態でスワップ要求が発生した場合の運用方法を指定します。

HiRDB Datareplicatorを使用してデータ連動する場合のシステムの環境設定及び運用方法については，マニュアル「HiRDBデータ連動機能 HiRDB Datareplicator」を参照してください。

注意事項

HiRDB DatareplicatorがサポートしていないHiRDBの機能を使用した場合，データ連動機能が使えなくなることがあります。詳細については，マニュアル「HiRDBデータ連動機能 HiRDB Datareplicator」を参照してください。また，最新の情報については，HiRDBのホームページで公開しているオンラインマニュアルを参照してください。

回復不要FESを使用する場合

回復不要FESでは，反映側HiRDB Datareplicatorの同期点処理方式に二相コミット方式を利用（反映システム定義commitment_methodオペランドにfxa_sqleを指定）した反映処理を実行できないため，回復不要FES以外のフロントエンドサーバを使用して反映処理を実行する必要があります。詳細は，「回復不要FES」を参照してください。

7.1.2　HiRDB Dataextractorとの連携

HiRDB Dataextractorを使用すると，メインフレーム又はHiRDBのデータベースのデータをまとめて抽出し，HiRDBのデータベースへ順次格納できます。HiRDB Dataextractorの特長を次に示します。

基幹データベースのある時点の情報を部門データベースに一括して反映できます。これによって，部門データベースの表の初期作成又は全データのリフレッシュができます。

基幹データベースから部分的にデータを抽出し，各業務に適した部門データベースを作成できます。

HiRDB Dataextractorについては，マニュアル「データベース抽出・反映サービス機能 HiRDB Dataextractor」を参照してください。

7.2　OLTPとの連携

ここでは，HiRDBがX/Open XAインタフェースを使用して，OLTPと連携する方法について説明します。ここで説明する項目は次のとおりです。

OLTPと連携できる製品

HiRDB XAライブラリ

OLTPと連携したHiRDBシステムの構成例

トランザクションの移行

トランザクションマネジャへの登録

トランザクションマネジャに登録する情報

トランザクションマネジャへの登録例

トランザクションマネジャへの登録の変更

トランザクションマネジャとHiRDB間のコネクションが切断されたときの再接続方法

注意事項

7.2.1　OLTPと連携できる製品

HiRDBでは次に示すOLTP製品と連携できます。

OpenTP1

TPBroker for C++

TUXEDO

7.2.2　HiRDB XAライブラリ

X/Open XAインタフェースとは，分散トランザクション処理（DTP：Distributed Transaction Processing）システムのトランザクションマネジャ（TM：Transaction Manager）とリソースマネジャ（RM：Resource Manager）の接続インタフェースを規定したX/Openの標準仕様です。XAインタフェースを使用すると，リソースマネジャのトランザクション処理をトランザクションマネジャで制御できます。リソースマネジャのトランザクション処理をトランザクションマネジャで制御するには，リソースマネジャが提供するライブラリとトランザクションマネジャが提供するライブラリをUAPにリンケージします。

HiRDBのUAPの処理をトランザクションマネジャで制御するために，HiRDBはHiRDB XAライブラリを提供しています。HiRDB XAライブラリは，X/Open DTPソフトウェアアーキテクチャのXAインタフェースの仕様に準拠しています。

X/Open DTPモデルでのHiRDBの位置づけを次の図に示します。

図7‒1　X/Open DTPモデルでのHiRDBの位置づけ

[picture]

なお，X/Open XAインタフェースを使用するUAPから回復不要FESに接続すると，SQLがエラーリターンします。クライアント環境定義のPDFESHOST及びPDSERVICEGRPを指定して，回復不要FESではないフロントエンドサーバに接続してください。

(1)　HiRDB XAライブラリが提供する機能

HiRDB XAライブラリが提供する機能を次の表に示します。

表7‒1　HiRDB XAライブラリが提供する機能

機能 | 説明
トランザクションの移行 | トランザクションのコミット処理をUAPがHiRDBにアクセスしたときと異なるプロセスで実行する機能です。ここでいうUAPとは，HiRDB XAライブラリを使用してHiRDBに接続するUAPのことです。 トランザクションの移行を使用するかどうかは，クライアント環境定義のPDXAMODEオペランドで指定します。トランザクションの移行については，「トランザクションの移行」を参照してください。
一相最適化 | 二相コミット制御を一相に最適化する機能です。 一相最適化を使用する場合，トランザクションの完了種別がトランザクションマネジャとHiRDBで一致しないことがあります。詳細については，「一相最適化に関する注意事項」を参照してください。
読み取り専用 | プリペア要求でHiRDBのリソースが更新されていない場合，トランザクションマネジャが二相目にコミット要求をしないで最適化する機能です。
動的トランザクションの登録 | UAPを実行する直前に，HiRDBが動的にトランザクションを登録する機能です。
複数接続機能 | 一つのプロセスからHiRDBサーバに対して複数のCONNECTを別々に実行する機能です。X/Open XAインタフェース環境下での複数接続機能については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

注

HiRDB XAライブラリでは，非同期XA呼び出し（トランザクションマネジャが非同期にHiRDB XAライブラリを呼び出す機能）を提供していません。

(2)　マルチスレッド対応のXAインタフェース

マルチスレッド対応のXAインタフェースを利用すると，TPBroker for C++とHiRDBでOTS（Object Transaction Service）連携ができます。

なお，マルチスレッド用のライブラリはC言語又はC++言語でだけ使用できます。COBOL言語では使用できません。

マルチスレッド対応のXAインタフェースを使用するには専用のHiRDBクライアントライブラリをリンクしてください。バージョン05-06より前のHiRDBクライアントライブラリはマルチスレッドに対応していません。マルチスレッド用のライブラリは，既存のHiRDBクライアントが接続できるすべてのHiRDBサーバに対して使用できます。マルチスレッド用のライブラリを使用すると，スレッドの間で接続を共有できます。

7.2.3　OLTPと連携したHiRDBシステムの構成例

OLTPと連携したHiRDBシステムについて，OpenTP1を使用した例で説明します。

(1)　HiRDB/シングルサーバとの連携

HiRDB/シングルサーバとOLTP（OpenTP1）を連携すると，複数のHiRDB/シングルサーバの更新処理を一つのトランザクションとして実行できます。この場合，データベースはキーレンジ分割などで分割配置し，各サーバマシンで稼働するOLTP（OpenTP1）が，各HiRDB/シングルサーバへ処理を振り分けます。処理を振り分けることで，高速にトランザクション処理を実行できるようにしています。複数のHiRDB/シングルサーバを統合化する場合は，OLTPとの連携を検討してください。HiRDB/シングルサーバとOLTP（OpenTP1）との連携を次の図に示します。

図7‒2　HiRDB/シングルサーバとOLTP（OpenTP1）との連携

[picture]

(2)　HiRDB/パラレルサーバとの連携

HiRDB/パラレルサーバとOLTP（OpenTP1）を連携すると，HiRDB/パラレルサーバで負荷分散したデータベースの更新処理をトランザクション処理として実行できます。HiRDB/パラレルサーバとOLTP（OpenTP1）との連携を次の図に示します。

図7‒3　HiRDB/パラレルサーバとOLTP（OpenTP1）との連携

[picture]

(3)　複数のOLTP（OpenTP1）とHiRDBとの連携

複数のOLTP（OpenTP1）と一つのHiRDB間でクライアント／サーバ型で通信して連携する形態です。異なるOLTP（OpenTP1）から一つのHiRDBに，同時に接続できます。この場合，各OLTP（OpenTP1）のOLTP識別子（クライアント環境定義のPDTMID）が異なるようにしてください。複数のOLTP（OpenTP1）とHiRDBとの連携を次の図に示します。

図7‒4　複数のOLTP（OpenTP1）とHiRDBとの連携

[picture]

(4)　一つのOLTP（OpenTP1）と複数のHiRDBとの連携

一つのOLTP（OpenTP1）と複数のHiRDBで連携する形態です。異なるサーバマシンのHiRDBに同時に接続してSQL文を実行できます。この場合，複数接続機能を使用する必要があります。一つのOLTP（OpenTP1）と複数のHiRDBとの連携を次の図に示します。

図7‒5　一つのOLTP（OpenTP1）と複数のHiRDBとの連携

[picture]

複数接続機能については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

7.2.4　トランザクションの移行

HiRDB XAライブラリを使用してHiRDBに接続するUAPでは，HiRDBにアクセスしたときと異なるプロセスでトランザクションのコミット処理を実行できます。このことをトランザクションの移行といいます。トランザクションの移行の概要を次の図に示します。

図7‒6　トランザクションの移行の概要

[picture]

メリット

トランザクションの移行を使用すると，トランザクションマネジャのUAP処理はトランザクションの完了を待たなくても次回のサービス要求を受け付けられます。このため，この機能を使用しないときに比べて，少ないプロセス数でUAPを実行できます。ただし，HiRDBが使用するサーバプロセス数及び排他待ち※回数が増える場合があります。

注※

トランザクションが完了するまでの間，次回のサービス要求によるHiRDBへのアクセスは，排他待ちになる場合が増えます。

適用基準

トランザクションマネジャがトランザクションの移行を使用する場合は，HiRDBもトランザクションの移行を使用してください。

トランザクションマネジャがトランザクションの移行を使用しない場合は，HiRDBもトランザクションの移行を使用しないでください。

トランザクションマネジャがトランザクションの移行の使用可否を設定できる場合は，次に示す点に考慮してトランザクションの移行の使用可否を設定してください。

HiRDBへのアクセス負荷より，UAP自身の処理の負荷が大きい場合にトランザクションの移行を使用します。

運用方法

トランザクションの移行を使用する場合は，クライアント環境定義のPDXAMODEオペランドに1を指定してください。この機能を使用しない場合は，このオペランドに0を指定するか，このオペランドを省略してください。

PDXAMODEオペランドについては，マニュアル「HiRDB UAP開発ガイド」を参照してください。

注意事項

トランザクションマネジャとHiRDBの間で，トランザクションの移行を使用するかどうかの設定が合っていないと，トランザクションが決着できなかったり，HiRDBが異常終了したり，トランザクションマネジャにエラーリターンしたりすることがあります。

この機能を使用すると，LOCK文のLOCK TABLE UNTIL DISCONNECTの有効範囲が変わります。LOCK TABLE UNTIL DISCONNECTの有効範囲については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(1)　トランザクションマネジャがOpenTP1の場合

トランザクションの移行を使用すると，OpenTP1のコミット最適化及びプリペア最適化にHiRDBが対応します。したがって，OpenTP1のtrnstringオペランドの-dオプションを省略した場合は，この機能を使用してください。-dオプションを指定した場合は，この機能を使用しないでください。

OpenTP1システム定義のトランザクションサービス定義のtrnstringオペランドとHiRDBのPDXAMODEオペランドの関係を次の表に示します。

表7‒2　OpenTP1のtrnstringオペランドとHiRDBのPDXAMODEオペランドの関係

trnstringオペランドの指定 | PDXAMODE オペランドの値
-dオプションを省略 | 1
-dオプションを指定 | 0

注

trnstringオペランドとPDXAMODEオペランドの指定が合っていないと，HiRDBがトランザクションを決着できません。このとき，HiRDBはOpenTP1に対してXA関数エラーリターンコード（−6）を返します。

trnstringオペランドについては，マニュアル「OpenTP1 システム定義」を参照してください。コミット最適化又はプリペア最適化については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

7.2.5　トランザクションマネジャへの登録

OLTPと連携するには，HiRDBをトランザクションマネジャに登録する必要があります。HiRDBをトランザクションマネジャに登録するには，各トランザクションマネジャのコマンド又は機能を使用します。

OpenTP1の場合：trnlnkrmコマンドでHiRDBを登録します。

TPBroker for C++の場合：tslnkrmコマンドでHiRDBを登録します。

TUXEDOの場合：%TUXDIR%¥udataobj¥RMにHiRDBを登録します。%TUXDIR%は，TUXEDOシステム・ソフトウェアがあるディレクトリの絶対パス名を示しています。

(1)　動的登録と静的登録

HiRDBをトランザクションマネジャに登録するときに，次に示すどちらかの方法を選択してください。

動的登録

静的登録

なお，一つのトランザクションマネジャに対して，動的登録と静的登録を混在して使用できません。

(a)　動的登録とは

HiRDBをトランザクションマネジャに動的登録すると，トランザクション内で最初のSQL文を発行したときに，UAPがトランザクションマネジャの制御下に入ります。UAPがHiRDBを含む複数のリソースマネジャをアクセスする場合，又はUAPがHiRDBをアクセスするとは限らない場合などに，トランザクションマネジャからのHiRDBに対するトランザクション制御のオーバヘッドを削減できます。

(b)　静的登録とは

HiRDBをトランザクションマネジャに静的登録すると，UAPがSQL文を発行するかどうかに関係なく，トランザクションの開始時に常にトランザクションマネジャの制御下に入ります。

トランザクションマネジャがOpenTP1の場合，UAPとHiRDBとのコネクションが切断されたとき（ユニットの異常終了，又はサーバプロセスの異常終了などのとき）に，OpenTP1にはトランザクション開始時に再接続をする機能があるため，UAPの再起動が不要になります。

(2)　動的登録と静的登録の違い

動的登録と静的登録の違いを次の表に示します。

表7‒3　動的登録と静的登録の違い

差異のポイント | 動的登録 | 静的登録
トランザクション開始時 | 管理しない | コネクション確立中かの確認 トランザクションマネジャ制御下でのトランザクションの管理を開始 コネクション確立※1

トランザクション内で最初のSQL発行時

トランザクションマネジャの制御下での管理を開始

HiRDBのトランザクション開始

SQL処理

コネクション確立※1

HiRDBのトランザクション開始

SQL処理

トランザクション処理中のトランザクションマネジャとHiRDB間の通信回数 | SQL文数＋コミット処理通信回数＋１（コネクション確立用通信分）※1 | SQL文数＋コミット処理通信回数＋１（トランザクション開始処理用の通信分）＋１（コネクション確立用通信分）※1
トランザクションマネジャとHiRDB間のコネクションが，途中で切断したときの再接続方法※2 | 次回のトランザクション開始時に自動的に再接続※3 | 次回のトランザクション開始時に自動的に再接続※4

注※1

マルチスレッド対応のXAインタフェース使用時にする処理です。

注※2

ネットワーク障害による切断は検知できません。ただし，トランザクションマネジャがTPBroker for C++の場合はトランザクション開始時に接続を確立するため，再接続できます。

注※3

トランザクションマネジャがOpenTP1/Server Baseの場合は，OpenTP1/Server Baseのtrn_rm_open_close_scopeオペランドにtransactionを指定することで，ネットワーク障害による切断の場合でも再接続できます。

注※4

トランザクションマネジャがOpenTP1/Server Baseの場合は，ネットワーク障害による切断の場合でも再接続できます。

7.2.6　トランザクションマネジャに登録する情報

HiRDBをリソースマネジャとしてトランザクションマネジャに登録する方法については，トランザクションマネジャのマニュアルを参照してください。このとき，次に示す情報をトランザクションマネジャに指定します。

(1)　RMスイッチ名

動的登録にするか又は静的登録にするかは，RMスイッチ名の指定で決まります。HiRDBのRMスイッチ名（xa_switch_t 構造体名）を次に示します。

動的登録の場合：pdtxa_switch

静的登録の場合：pdtxa_switch_y

(2)　RM名

RMスイッチ（xa_switch_t 構造体）で定義されているRM名（リソースマネジャ名）は，HiRDB_DB_SERVERです。

(3)　オープン文字列

トランザクションマネジャがxa_openでリソースマネジャをオープンするときに使用するオープン文字列は，複数接続機能を使用する場合に指定してください。複数接続機能を使用しない場合はオープン文字列を指定する必要はありません。トランザクションマネジャがTUXEDOの場合は，複数接続機能を使用できません。

複数接続機能を使用する場合は，トランザクションマネジャに複数のHiRDBを登録し，各HiRDBに対してオープン文字列を指定します。オープン文字列には次に示す項目を指定します。

接続先で有効にする環境変数を設定したファイルの絶対パス名，又は接続先で有効にする環境変数をレジストリ登録したときに指定した環境変数グループ名（環境変数をレジストリ登録する方法については，マニュアル「HiRDB UAP開発ガイド」を参照）

環境変数グループ識別子

次のどちらかの書式で記述します。

"環境変数グループ識別子＋環境変数設定ファイル名又は環境変数グループ名"

"環境変数グループ識別子＊環境変数設定ファイル名又は環境変数グループ名"

これ以外の形式で指定した場合は，オープン文字列が無視されます。また，環境変数グループ識別子は4バイト固定，オープン文字列は全体で257バイト以上にできません。

トランザクションマネジャがOpenTP1又はTPBroker for C++の場合のオープン文字列の登録例を次に示します。

(a)　OpenTP1の場合

OpenTP1のトランザクションサービス定義のtrnstringオペランドでオープン文字列を登録します。ここでは二つのHiRDBをOpenTP1に登録します。登録条件は次のとおりとします。

リソースマネジャ | 環境変数グループ識別子 | 環境変数設定ファイル名又は環境変数グループ名
HiRDB1 | HDB1 | hirdb11 hirdb12
HiRDB2 | HDB2 | hirdb21 hirdb22

オープン文字列の登録例を次に示します。

trnstring -n HiRDB_DB_SERVER -i H1 -o "HDB1*hirdb11" -O "HDB1+hirdb12"
trnstring -n HiRDB_DB_SERVER -i H2 -o "HDB2*hirdb21" -O "HDB2+hirdb22"

〔説明〕

-n：リソースマネジャ名を指定します。

-i：リソースマネジャ拡張子を指定します。

-o：トランザクションサービス用xa_open関数用文字列を指定します。

OpenTP1のトランザクションサービスプロセスが使用するオープン文字列を指定します。

"環境変数グループ識別子＊環境変数設定ファイル名又は環境変数グループ名"の形式で指定します。

-O：ユーザサーバ用xa_open関数用文字列を指定します。

ユーザサーバプロセスが使用するオープン文字列を指定します。

"環境変数グループ識別子＋環境変数設定ファイル名又は環境変数グループ名"の形式で指定します。

-oと-Oには同じ環境変数グループ識別子を指定してください。

-oと-Oに指定するファイル又はレジストリで設定する環境変数は同じ内容にしてください。

備考

OpenTP1のユーザサービス定義のtrnrmidオペランドで，ユーザサービスから接続するHiRDBを選択します。HiRDB1とHiRDB2に接続する例を次に示します。

trnrmid -n HiRDB_DB_SERVER -i H1,H2

(b)　TPBroker for C++の場合

TPBroker for C++のリソースマネジャ定義のxa_open_string_infoオペランドでオープン文字列を登録します。ここでは二つのHiRDBをTPBroker for C++に登録します。登録条件は次のとおりとします。

リソースマネジャ | 環境変数グループ識別子 | 環境変数設定ファイル名又は環境変数グループ名
HiRDB1 | HDB1 | hirdb11 hirdb12
HiRDB2 | HDB2 | hirdb21 hirdb22

オープン文字列の登録例を次に示します。

tsdefvalue /OTS/RM/HiRDB_DB_SERVER_1/DMN/xa_open_string_info     1
-s "HDB1*hirdb11"
tsdefvalue /OTS/RM/HiRDB_DB_SERVER_1/xa_open_string_info         2
-s "HDB1+hirdb12"

tsdefvalue /OTS/RM/HiRDB_DB_SERVER_2/DMN/xa_open_string_info     1
-s "HDB2*hirdb21"
tsdefvalue /OTS/RM/HiRDB_DB_SERVER_2/xa_open_string_info         2
-s "HDB2+hirdb22"

〔説明〕

/OTS/RM/RM名/DMN/xa_open_string_infoには，TPBroker for C++の回復プロセスが使用するオープン文字列を指定します。環境変数グループ識別子と，環境変数設定ファイル又は環境変数グループ名の間の文字には＊を指定してください。

/OTS/RM/RM名/xa_open_string_infoには，アプリケーションプログラムプロセス及び決着プロセスが使用するオープン文字列を指定します。環境変数グループ識別子と，環境変数設定ファイル又は環境変数グループ名の間の文字には＋を指定してください。

RM名が同じ場合は，同じ環境変数グループ識別子を指定してください。

RM名が同じ場合は，各環境変数設定ファイル又は環境変数グループに設定する環境変数を同じ内容にしてください。

決着プロセスに対して環境変数TPRMINFOを設定している場合，/OTS/RM/RM名/（TPRMINFO設定値）/xa_open_string_infoに指定するオープン文字列には/OTS/RM/RM名/xa_open_string_infoと同じ文字列を指定してください。また，決着プロセスに対してTPRMINFOを設定しない場合でも，複数接続機能を使用するときは/OTS/completion_process_envにデフォルトとして'TPRMINFO='を指定してください。指定例を次に示します。

（例）tsdefvalue /OTS completion_process_env -a 'TPRMINFO='

(4)　クローズ文字列

トランザクションマネジャがxa_closeでリソースマネジャをクローズするときに使用するクローズ文字列は指定不要です。

(5)　RM関連オブジェクト名

RM関連オブジェクト名には，コンパイル，及びリンケージをするときに指定するライブラリのファイル名を指定します。指定するファイル名については，次の表を参照してください。

マニュアル「HiRDB UAP開発ガイド」の「コンパイル，リンケージ時に指定するライブラリ」の表「コンパイル，及びリンケージをするときに指定するライブラリ（OLTP下の場合（Windows環境））」

マニュアル「HiRDB UAP開発ガイド」の「Windowsクライアントのディレクトリ及びファイル構成」の表「各トランザクションマネジャが使用するライブラリ一覧（Windowsクライアント）」

(6)　クライアント環境定義

トランザクションマネジャにHiRDBのトランザクション処理を制御させるためには，HiRDBのクライアント環境定義をトランザクションマネジャの定義に設定する必要があります。OLTP環境下でのクライアント環境定義の設定方法については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(a)　OpenTP1の場合

トランザクションマネジャがOpenTP1の場合，クライアント環境定義を次に示すOpenTP1のシステム定義に指定する必要があります。

システム環境定義

ユーザサービスデフォルト定義

ユーザサービス定義

トランザクションサービス定義

これらの定義については，マニュアル「OpenTP1 システム定義」を参照してください。

なお，複数のOpenTP1と接続する場合は，次に示すクライアント環境定義を必ず指定してください。

HiRDB_PDTMID又はPDTMID

(b)　TPBroker for C++の場合

クライアント環境定義はTPBroker for C++のシステム定義に指定してください。

(c)　TUXEDOの場合

TUXEDOコンフィギュレーション・ファイル（UBBCONFIGファイル）のENVFILEパラメタで指定したファイルに，クライアント環境定義を指定してください。TUXEDOコンフィギュレーション・ファイルについては，TUXEDOのマニュアルを参照してください。

7.2.7　トランザクションマネジャへの登録例

(1)　OpenTP1の場合

HiRDBをOpenTP1に登録するには，OpenTP1のtrnlnkrmコマンドを使用します。trnlnkrmコマンドの指定例を次に示します。

(a)　動的登録の場合

trnlnkrm -a HiRDB_DB_SERVER -s pdtxa_switch
-o C:¥win32app¥hitachi¥hirdb_s¥client¥lib¥pdcltx32.lib

〔説明〕

-a：RM名を指定します。

-s：RMスイッチ名（XAスイッチ構造体の名称）を指定します。RMスイッチ名は，登録方法（動的登録又は静的登録）によって異なります。

-o：RM関連オブジェクト名（共用ライブラリのファイル名）を指定します。

(b)　静的登録の場合

trnlnkrm -a HiRDB_DB_SERVER -s pdtxa_switch_y
-o C:¥win32app¥hitachi¥hirdb_s¥client¥lib¥pdcltx32.lib

〔説明〕

-a：RM名を指定します。

-s：RMスイッチ名（XAスイッチ構造体の名称）を指定します。RMスイッチ名は，登録方法（動的登録又は静的登録）によって異なります。

-o：RM関連オブジェクト名（共用ライブラリのファイル名）を指定します。

(2)　TPBroker for C++の場合

HiRDBをTPBroker for C++に登録するには，TPBroker for C++のtslnkrmコマンドを使用します。tslnkrmコマンドの指定例を次に示します。

(a)　動的登録の場合

tslnkrm -a HiRDB_DB_SERVER_1 -s pdtxa_switch
-o 'C:¥win32app¥hitachi¥hirdb_s¥client¥lib¥pdcltxm.lib' -r -m
tslnkrm -a HiRDB_DB_SERVER_2 -s pdtxa_switch
-o 'C:¥win32app¥hitachi¥hirdb_s¥client¥lib¥pdcltxm.lib' -r -m

〔説明〕

-a：RM名を指定します。

-s：RMスイッチ名（XAスイッチ構造体の名称）を指定します。RMスイッチ名は，登録方法（動的登録又は静的登録）によって異なります。

-o：RM関連オブジェクト名（共用ライブラリのファイル名）を指定します。

-r：動的登録する場合に指定します。

-m：OTSのデーモンがマルチスレッドで動作するようになります。

(b)　静的登録の場合

tslnkrm -a HiRDB_DB_SERVER_1 -s pdtxa_switch_y
-o 'C:¥win32app¥hitachi¥hirdb_s¥client¥lib¥pdcltxm.lib' -r -m
tslnkrm -a HiRDB_DB_SERVER_2 -s pdtxa_switch_y
-o 'C:¥win32app¥hitachi¥hirdb_s¥client¥lib¥pdcltxm.lib' -r -m

〔説明〕

-a：RM名を指定します。

-s：RMスイッチ名（XAスイッチ構造体の名称）を指定します。RMスイッチ名は，登録方法（動的登録又は静的登録）によって異なります。

-o：RM関連オブジェクト名（共用ライブラリのファイル名）を指定します。

-r：静的登録する場合に指定します。

-m：OTSのデーモンがマルチスレッドで動作するようになります。

(3)　TUXEDOの場合

%TUXDIR%¥udataobj¥RMファイルでHiRDBをTUXEDOに登録します。%TUXDIR%は，TUXEDOシステム・ソフトウェアがあるディレクトリの絶対パス名を示しています。RMファイルの指定例を次に示します。

(a)　動的登録の場合

HiRDB_DB_SERVER;pdtxa_switch;C:¥HiRDB¥client¥lib¥pdcltxs.lib

(b)　静的登録の場合

HiRDB_DB_SERVER;pdtxa_switch_y;C:¥HiRDB¥client¥lib¥pdcltxs.lib

7.2.8　トランザクションマネジャへの登録の変更

トランザクションマネジャへの登録を変更する場合（静的登録から動的登録，若しくは動的登録から静的登録），又はRM関連オブジェクト名に指定するライブラリを変更する場合には，次に示す手順に従ってトランザクションマネジャにHiRDBを登録し直してください。

(1)　OpenTP1の場合

〈手順〉

OpenTP1のtrnlnkrmコマンドで，トランザクションマネジャにHiRDBを登録し直します。

OpenTP1のtrnmkobjコマンドで，トランザクション制御用オブジェクトファイルを再作成します。

2で再作成したトランザクション制御用オブジェクトファイル，及び「トランザクションマネジャに登録する情報」に示した情報を基に，HiRDBのXAライブラリとリンクしていたすべてのUAPを再リンケージしてください。再リンケージをしないと，UAPの動作を保証できません。

(2)　TPBroker for C++の場合

〈手順〉

TPBroker for C++のtslnkrmコマンドで，トランザクションマネジャにHiRDBを登録し直します。

TPBroker for C++のtsmkobjコマンドで，トランザクション制御用オブジェクトファイルを再作成します。

2で再作成したトランザクション制御用オブジェクトファイル，及び「トランザクションマネジャに登録する情報」に示した情報を基に，HiRDBのXAライブラリとリンクしていたすべてのUAPを再リンケージしてください。再リンケージをしないと，UAPの動作を保証できません。

(3)　TUXEDOの場合

〈手順〉

%TUXDIR%¥udataobj¥RMでトランザクションマネジャにHiRDBを登録し直します。

TUXEDOのbuildtmsコマンドで，「トランザクションマネジャに登録する情報」に示した情報を基にトランザクションマネジャサーバのロードモジュールを再作成します。

TUXEDOのbuildserverコマンドで，「トランザクションマネジャに登録する情報」に示した情報を基にサーバのロードモジュールを再作成します。

TUXEDOのbuildclientコマンドで，「トランザクションマネジャに登録する情報」に示した情報を基にクライアントモジュールを再作成します。

7.2.9　トランザクションマネジャとHiRDB間のコネクションが切断されたときの再接続方法

(1)　UAPで対処する方法

コネクションが切断された場合，実行中のUAPを終了後，再起動してください。再起動すると，自動的にコネクションが再接続されます。

UAPを再起動したくない場合は，コネクションが切断されたことを示すエラーがUAPに返ったときに，tx_open関数を再発行してください。そうすれば，UAPを終了しなくてもサービスを続行できます。tx_open関数を再発行するときのコーディング例を次に示します。

コーディング例

int connection = 1;
void service(char *in_data,long *in_len,char *out_data,long *out_len) {
    if (connection == 0) {
       tx_close();
       tx_open();           ………コネクション切断時のtx_open再発行処理
    }
    tx_begin();
    EXEC SQL INSERT INTO ......;                ……… SQL文発行
    if (SQLCODE == 0) {
        tx_commit();
        *out_data = “OK”;
    } else {
        tx_rollback();
        *out_data = “NG”;
        if (SQLCODE == -563 || SQLCODE == -722) {
            connection = 0;              ………………コネクション切断を記憶
        }
    }
}

(2)　連携するOLTP製品がTPBroker for C++の場合

トランザクションの開始又は終了時にHiRDBとのコネクションを確立又は切断するため，途中で切断した場合も次回のトランザクション開始時にコネクションが再接続されます。

(3)　OpenTP1の機能を使用する

動的登録の場合は，OpenTP1/Server Baseのtrn_rm_open_close_scopeオペランドにtransactionを指定してください。そうすれば，OpenTP1/Server Baseはトランザクションの開始又は終了でHiRDBとのコネクションを確立又は切断します。したがって，途中でコネクションが切断されても，次回のトランザクションの開始時にコネクションが再接続されます。

静的登録の場合は，トランザクションの開始時にHiRDBとのコネクションが確立されているかどうかをトランザクションマネジャが確認します。コネクションが切断されている場合は，自動的に再接続されて，トランザクションを開始します。

(4)　HiRDBのXAインタフェースに対応したクライアントライブラリの再接続

トランザクションマネジャでトランザクションを開始して，最初にHiRDBにアクセスするSQL文を実行するまでに，HiRDBとのコネクションが切断されていた場合，SQL文の実行時にHiRDBクライアントライブラリでコネクションが再接続されます。ただし，ネットワーク障害による切断は検知できないため，再接続されません。

7.2.10　注意事項

(1)　SQL関連の注意事項

リソースマネジャへの接続や切断を行う権限は，トランザクションマネジャにあります。UAPにリソースマネジャへの接続又は切断を行うSQL文を記述しないでください。また，トランザクションの進行を調整し監視する権限も，トランザクションマネジャにあります。UAPにトランザクションをロールバック又はコミットするSQL文を記述しないでください。したがって，EXEC SQL COMMIT WORK文，EXEC COMMIT WORK RELEASE文などもエラーになります。

定義系SQL文はエラーとなります。CREATE TABLEなどの定義系SQL文は自動的にコミットを指示するため，UAPに定義系SQL文を記述しないでください。

(2)　マルチスレッド用のライブラリに関する注意事項

一つのトランザクションからHiRDBサーバに対して複数のスレッドを使用して別々に接続できません。マルチスレッド環境であってもトランザクションから接続するHiRDBサーバのサーバプロセスは一つです。したがって，一つのトランザクションから同時に実行できるスレッドは一つであり，同一トランザクション内で複数のスレッドを使用してSQL文を同時に実行できません。

(3)　一相最適化に関する注意事項

HiRDBはトランザクションマネジャがサポートしている一相最適化に対応しています。トランザクションマネジャはトランザクションブランチによって変更した共有リソースがHiRDBだけの場合，トランザクションブランチに対して一相コミットを要求できます。トランザクションマネジャが一相最適化を使用して一相コミットを要求してきた場合，HiRDBはトランザクションブランチの結果を決めた後，トランザクションブランチの情報を削除してトランザクションマネジャへ応答を返します。

一相最適化を使用しているトランザクションマネジャでは，グローバルトランザクションに関して安定ストレージに記憶する必要もなく，何らかの障害が発生してもその結果を知る必要もありません。したがって，次に示す条件をすべて満たす場合，トランザクションの完了種別がトランザクションマネジャとHiRDBで一致しないことがあります。

一相最適化を使用するトランザクションマネジャとXAインタフェースを使用して接続している

更新系トランザクションのコミットメント制御をトランザクションマネジャが一相最適化している

コミットメント処理中にトランザクションマネジャのUAPが異常終了する

これらの条件下では，HiRDBのトランザクションブランチの結果を，トランザクションマネジャが発生した障害の結果として知ることができません。そのため，トランザクションの完了種別がトランザクションマネジャとHiRDBで一致しないことがあります。

これを防ぐには，更新系トランザクションのコミットメント制御をする場合，トランザクションマネジャの一相最適化を使用しないでください。

(4)　高速系切り替え機能を使用している場合の注意事項

次に示す条件をすべて満たす場合は注意が必要です。

HiRDB/パラレルサーバの場合はシステムマネジャがあるユニットを高速系切り替え機能の対象にしている

X/Openに従ったAPIを使用したOLTP製品（OpenTP1又はTPBroker for C++など）と連携している

HiRDBクライアントのバージョンが06-02-/A以前である

OLTP製品のクライアント環境変数PDHOSTに指定している現用系が待機系として待機完了状態になっている

この場合，OLTP製品が未決着トランザクションの回復処理をすると，X/Openに従ったAPIがエラーリターンしてトランザクションが回復されないことがあります。この現象が発生する場合は，HiRDBクライアントのバージョンを06-02-/B以降にバージョンアップしてください。業務を停止させたくないなどの理由でHiRDBクライアントのバージョンアップがすぐにできない場合は，現用系のHiRDB（ユニット）を待機系から実行系に系を切り替えてください。ただし，これは一時的な対応策です。HiRDBクライアントのバージョンアップで対応してください。

7.3　Java EEアプリケーションサーバとの連携

7.3.1　Java EEアプリケーションサーバとは

Java EEとは，Javaで大規模な企業システムを構築する場合に使用される規格であり，その実行環境を提供する製品をJava EEアプリケーションサーバと呼びます。

Java EEは幾つかの標準仕様の集合として構成されているため，ユーザアプリケーションはServlet/JSP/EJB/jBatchなどを実装したJava EEアプリケーションとして作成します。JDBC/JTA/JPAなどを介してデータベースと連携します。

図7‒7　Java EEアプリケーションサーバでの構成イメージ

[picture]

7.3.2　連携できるJava EEアプリケーションサーバ

HiRDBでは，次に示すJava EEアプリケーションサーバと連携できます。

Cosminexus

JBoss Enterprise Application Platform

(1)　Cosminexus

CosminexusをサポートしているJDBCドライバの種別を次の表に示します。

表7‒4　CosminexusをサポートしているJDBCドライバの種別

JDBCドライバ種別 | サポート
Type2 JDBCドライバ | ×
Type4 JDBCドライバ | JDBC2.0版 | ○
JDBC4.0版 | ○

（凡例）

○：サポート

×：未サポート

(a)　設定方法

設定方法についてはCosminexusのマニュアルを参照してください。

(b)　Cosminexus連携時に考慮が必要になる機能

●各種トレースファイル，監査証跡ファイル

・トレースファイル名

システムプロパティejbserver.serverNameによって指定されるJ2EEサーバのサーバ名からトレースファイル名が決まります。トレースファイル名を次の表に示します。

表7‒5　トレースファイルの種類とトレースファイル名

トレースファイルの種類 | トレースファイル名
Exceptionトレースログ | <サーバ名>exc{1|2}.trc
不正電文トレース | <サーバ名>dataerr{1|2}.trc

・トレースファイルの出力先

JDBCドライバが出力する各種トレースファイルは，クライアント環境定義PDCLTPATHなどで出力先を明示的に指定していない場合，J2EEサーバのカレントディレクトリに出力します。具体的な出力先を次に示します。

J2EEサーバの作業ディレクトリがデフォルトの場合

<インストール先ディレクトリ>¥CC¥Server¥public¥ejb¥<サーバ名>

J2EEサーバの作業ディレクトリを変更している場合

<作業ディレクトリ>¥ejb¥<サーバ名>

J2EEサーバのカレントディレクトリについて，詳細はCosminexusのマニュアルを参照してください。

・ルートアプリケーション情報

ルートアプリケーション情報とはCosminexusのPRFトレースに出力される情報であり，Cosminexusを呼び出すクライアントからの個々のリクエストを識別するために使用できます。HiRDBでは次のファイルで出力しているため，ルートアプリケーション情報によってCosminexusのPRFトレースと関連づけることで，どのリクエストの延長で出力された情報であるかを判別できます。

監査証跡ファイル

PRFトレース

SQLトレース

Exceptionトレースログ

・再接続トレース機能

自動再接続機能で再接続された場合，再接続トレース機能を使用すると，CosminexusのPRFトレース機能で出力されるトレース中の接続情報を追跡できます。

詳細はマニュアル「HiRDB UAP開発ガイド」の「再接続トレース機能」を参照してください。

●クライアント環境定義

・UAP名称

クライアント環境定義PDCLTAPNAMEを省略した場合，システムプロパティejbserver.serverNameによってJ2EEサーバのサーバ名からUAP名称が決まります。UAP名称を次の表に示します。なお，PDCLTAPNAME以外のUAP名称の指定方法については，マニュアル「HiRDB UAP開発ガイド」の「接続情報の優先順位」を参照してください。

表7‒6　JDBCドライバとUAP名称

JDBCドライバ | UAP名称
JDBC2.0版 | JDBC20_<サーバ名>
JDBC4.0版 | JDBC40_<サーバ名>

(c)　注意事項

クライアント環境定義PDUSERで指定したユーザ名／パスワードは無効になります。ユーザ名／パスワードは，CosminexusのConnector属性ファイルのプロパティ値として設定してください。

使用するJDBCドライバをDABroker for JavaからType4 JDBCドライバへ移行する場合，UAPの修正が必要になることがあります。詳細はマニュアル「HiRDB UAP開発ガイド」の「DABroker for Javaからの移行」を参照してください。

(2)　JBoss Enterprise Application Platform

次に示すバージョンのJBoss Enterprise Application Platform（以降，JBossと表記）と連携できます。

JBoss Enterprise Application Platform 7.0.1〜7.1，7.4，8.0

JBossをサポートしているJDBCドライバの種別を次の表に示します。

表7‒7　JBossをサポートしているJDBCドライバの種別

JDBCドライバ種別 | JBoss
7 | 8
Type2 JDBCドライバ | × | ×
Type4 JDBCドライバ | JDBC2.0版 | × | ×
JDBC4.0版 | ○ | ×
JDBC4.3版 | ○ | ○

（凡例）

○：サポート

×：未サポート

(a)　設定方法

JDBCドライバを使用するまでの手順を次に示します。

1.JDBCドライバをコアモジュールとして追加

2.JDBCドライバの登録

3.データソースの追加

2,3については，管理CLI又は管理コンソールを使用します。管理CLIを使用した場合の手順を次に示します。

JDBCドライバをコアモジュールとして追加

モジュールとは，JBossでのクラスローディング及び依存関係管理に使用されるクラスの論理グループのことを指します。JDBCドライバにクラスパスを通すために，JDBCドライバ（pdjdbc4.jar）をコアモジュールとして追加します。

モジュール名をcom.hirdbとした場合の設定例を次に示します。

次のディレクトリを作成してください。

<JBossインストールディレクトリ>¥modules¥com¥hirdb¥main¥

作成したディレクトリに，次に示すmodule.xmlファイルとJDBCドライバを格納してください。JDBC4.3版のJDBCドライバを使用する場合は，pdjdbc4.jarではなくpdjdbc43.jarをコアモジュールとして追加します。

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.hirdb">
    <resources>
        <resource-root path="pdjdbc4.jar"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

JDBCドライバの登録

管理CLIコマンドで次のコマンドを実行してください。

/subsystem=datasources/jdbc-driver=<JDBCドライバ名>:
add(driver-name=<JDBCドライバ名>,driver-module-name=<モジュール名>,
driver-xa-datasource-class-name=JP.co.Hitachi.soft.HiRDB.JDBC.PrdbXADataSource,
driver-class-name=JP.co.Hitachi.soft.HiRDB.JDBC.HiRDBDriver)

JDBCドライバ登録時の設定項目を次の表に示します。

表7‒8　JDBCドライバ登録時の設定項目

項目 | 概要
JDBCドライバ名 | JDBCドライバの識別子
モジュール名 | 1.で追加したモジュールのモジュール名

JDBCドライバの登録例を次に示します。

/subsystem=datasources/jdbc-driver=hirdb:
add(driver-name=hirdb,driver-module-name=com.hirdb,
driver-xa-datasource-class-name=JP.co.Hitachi.soft.HiRDB.JDBC.PrdbXADataSource,
driver-class-name=JP.co.Hitachi.soft.HiRDB.JDBC.HiRDBDriver)

データソースの追加

管理CLIコマンドで次のコマンドを実行してください。

非XAデータソース

data-source add --name=<データソース名> --jndi-name=<JNDI名>
--driver-name=<JDBCドライバ名> --connection-url=<接続URL>
--user-name=<ユーザ名> --password=<パスワード>
--valid-connection-checker-class-name=
org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
--exception-sorter-class-name=
org.jboss.jca.adapters.jdbc.extensions.novendor.ListExceptionSorter
--exception-sorter-properties=FatalExceptions=
"563,720,722,723,728,732,735,932,1700"※1
--validate-on-match=true※2

XAデータソース

xa-data-source add --name=<データソース名> --jndi-name=<JNDI名>
--driver-name=<JDBCドライバ名> --user-name=<ユーザ名> --password=<パスワード>
--valid-connection-checker-class-name=
org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
--xa-datasource-properties={"description"=>"<環境変数グループ識別子>",
"XAOpenString"=>"<XAオープン文字列>"}
--validate-on-match=true※2

注※1

--exception-sorter-class-nameに指定しているListExceptionSorterは，発生した例外のSQLCODEの絶対値が--exception-sorter-propertiesに指定されている場合，致命的な例外と判定しコネクションを破棄します。

注※2

コネクションプールからのコネクションオブジェクト取得時に，取得したコネクションオブジェクトが有効であるかを検証します。

データソース追加時の設定項目を次の表に示します。

表7‒9　データソース追加時の設定項目

項目 | 概要
データソース名 | データソースの識別子
JNDI名 | データソースのlookupに使用するJNDI名
JDBCドライバ名 | 表「JDBCドライバ登録時の設定項目」のJDBCドライバ名
ユーザ名 | ユーザ名／パスワード（他で設定している場合は省略できます）
パスワード
接続URL | DriverManagerクラスのgetConnectionメソッドに指定するURL
環境変数グループ識別子 | XADataSourceクラスのsetDescriptionメソッドに指定するHiRDBの環境変数グループ識別子
XAオープン文字列 | XADataSourceクラスのsetXAOpenStringメソッドに指定するXAオープン文字列

ユーザ名，パスワード以外は必須項目になります。また，表に記載していない項目については，必要に応じて追加してください。

データソースの追加例を次に示します。

非XAデータソース

data-source add --name=HiRDBDS --jndi-name=java:jboss/HiRDBDS --driver-name=hirdb
--connection-url=jdbc:hitachi:hirdb://DBID=22200,DBHOST=localhost
--user-name=admin --password=admin
--valid-connection-checker-class-name=
org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
--exception-sorter-class-name=
org.jboss.jca.adapters.jdbc.extensions.novendor.ListExceptionSorter
--exception-sorter-properties=FatalExceptions=
"563,720,722,723,728,732,735,932,1700"
--validate-on-match=true

XAデータソース

xa-data-source add --name=HiRDBXADS --jndi-name=java:jboss/HiRDBXADS
--driver-name=hirdb --user-name=admin --password=admin
--valid-connection-checker-class-name=
org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
--xa-datasource-properties=
{"description"=>"HDB1","XAOpenString"=>"HDB1+C:¥home¥hirdb¥HiRDB.ini"}
--validate-on-match=true

(b)　注意事項

JBossで使用できない機能を次の表に示します。

表7‒10　JBossで使用できない機能

使用できない機能 | 概要 | 対策
HiRDBを格納先とするトランザクションオブジェクトストア | JBossがトランザクションログを格納するための場所 | トランザクションオブジェクトストアとして次を使用してください。 ファイルストア（デフォルト） ほかのデータベースのJDBCデータソース
データソースのパラメタ | connectable=true （未設定とするか，falseを設定してください） | Commit Markable Resource（非XAデータソースをXAトランザクションに参加させるための機能） | XADataSourceを使用してください。
share-prepared-statements=true （未設定とするか，falseを設定してください） | 前処理済みのステートメントをクローズしないで，再度同一SQL文を指定して前処理済みのステートメントを取得した場合に，キャッシュされた同一のステートメントを取得する | なし （2つ目のステートメントは新規に作成されます）
interleaving=true （未設定とするか，falseを設定してください） | 同一コネクション上で複数のXAトランザクションを切り替えて使用する | なし （XAトランザクションが完了するまで，コネクションを占有します）

7.3.3　Java EEアプリケーションサーバの機能

Java EEアプリケーションサーバが提供する一般的な機能について説明します。

(1)　コネクションプーリング

(a)　コネクションプーリングとは

ユーザアプリケーションを呼び出す度にデータベースと接続/切断するのではなく，接続済みのコネクションオブジェクトをプールして使い回す仕組みのことを，コネクションプーリングと呼びます。

図7‒8　コネクションプーリング

[picture]

(b)　コネクションプーリング使用時の注意事項

クライアント環境定義などのJDBCドライバの設定を変更しても無効となります。設定変更を反映させるには，Java EEアプリケーションサーバの再起動やコネクションプール内のコネクションオブジェクトを破棄するなどして，再接続する必要があります。具体的な方法については，各Java EEアプリケーションサーバのマニュアルを参照してください。

HiRDBサーバと常時接続しているUAPでは，クライアント環境定義PDSWATCHTIMEでのタイムアウトによって，接続が切断されることがあります。クライアント環境定義PDSWATCHTIMEを設定する場合の注意事項については，マニュアル「HiRDB UAP開発ガイド」の「クライアント環境定義の設定内容」のPDSWATCHTIMEを参照してください。

ステートメントのcloseメソッド実行時にSQL前処理を破棄するように設定している場合，ステートメントのclose後にトランザクションを決着する必要があります。詳細はマニュアル「HiRDB UAP開発ガイド」の次の個所を参照してください。

ステートメントのcloseメソッド実行時にSQL前処理を破棄する方法

「接続情報の優先順位」の「ステートメントのcloseメソッド実行時のSQL前処理の破棄」

ステートメントのclose後にトランザクションを決着する方法

「ユーザプロパティ」の「HiRDB_for_Java_STATEMENT_CLOSE_BEHAVIOR」

SET ROLE文を実行し現在ロールを設定後にコネクションをcloseすると，現在ロールが設定されたままのコネクションがプールされ再利用されます。このため，次のどちらかの対処をしてください。

コネクションをcloseする前にSET ROLE文（NONE指定）を実行し現在ロールの設定を解除する。

コネクション取得時には，SET ROLE文を実行し現在ロールを設定する。

JDBC4.3版 Type4 JDBCドライバのsetSchemaメソッドを使用して認可識別子を設定後にコネクションをクローズすると，認可識別子が設定されたままのConnectionオブジェクトがプールされます。そのため，Connectionオブジェクト再利用時，意図しないリソースにアクセスしてしまうおそれがあります。Connectionオブジェクト取得時又はクローズ前は，必ず接続時の認可識別子を設定してください。

(2)　ステートメントプーリング／ステートメントキャッシュ

(a)　ステートメントプーリング／ステートメントキャッシュとは

同一のSQL文を指定して前処理済みのステートメントオブジェクト（PreparedStatement,CallableStatement）を作成するユーザアプリケーションを呼び出す場合などで，ステートメントオブジェクトをプールして使い回す仕組みのことをステートメントプーリング／ステートメントキャッシュと呼びます。

ステートメントオブジェクトはコネクションをまたがって使い回すことはできないため，コネクションプーリングを使用していることが前提の機能となります。

図7‒9　ステートメントプーリング／ステートメントキャッシュ

[picture]

(b)　ステートメントプーリング／ステートメントキャッシュ使用時の注意事項

前処理済みのステートメントオブジェクトがプーリングされている間，関連するスキーマ資源（表やインデクスなど）に対して排他を取得します。これらの資源に対して定義系SQLを実行する場合は，クライアント環境定義PDDDLDEAPRPEXEを指定してください（ホールダブルカーソルを使用している場合はPDDDLDEAPRPも指定してください）。

ただし，定義系SQLを実行した場合，前処理結果が無効になるため，Java EEアプリケーションサーバの再起動やコネクションプール内のコネクションオブジェクトを破棄する必要があります。

詳細は，マニュアル「HiRDB UAP開発ガイド」の「クライアント環境定義の設定内容」のPDDDLDEAPRPEXEを参照してください。

自動再接続機能を使用して再接続した場合，再接続前からプーリングされているステートメントオブジェクトが使い回されると，実行時に例外が発生します。ステートメントプーリング／ステートメントキャッシュ機能を使用する場合には，自動再接続機能は使用しないでください。

ステートメントのcloseメソッド実行時にSQL前処理を破棄しないよう，システムプロパティHiRDB_for_Java_STATEMENT_CLOSE_BEHAVIORにFALSEを設定するか，又は指定を省略してください。詳細はマニュアル「HiRDB UAP開発ガイド」の次の個所を参照してください。

システムプロパティHiRDB_for_Java_STATEMENT_CLOSE_BEHAVIORの設定方法

「ユーザプロパティ」の「HiRDB_for_Java_STATEMENT_CLOSE_BEHAVIOR」

上記以外の設定方法

「接続情報の優先順位」の「ステートメントのcloseメソッド実行時のSQL前処理の破棄」

SELECT文，INSERT文，DELETE文，UPDATE文，PURGE TABLE文，及びCALL文以外のSQL文では，コミット時に前処理済みのSQL文が無効になります。

前処理が無効となるSQL文についてはPreparedStatement／CallableStatementオブジェクトを使用せず，Statementオブジェクトを使用して実行してください。SQL文による切り分けができない場合は，ステートメントプーリング／ステートメントキャッシュを使用しないでください。

1つのConnectionオブジェクトに対し，使用中のステートメントオブジェクト（Statement，PreparedStatement，及びCallableStatementなど）の数の合計が4096以上となった場合，SQLExceptionを投入します。詳細はマニュアル「HiRDB UAP開発ガイド」の「Statementインタフェース」の「注意事項」を参照してください。

プーリングされているステートメントオブジェクトに対応するSQLオブジェクトは，SQLオブジェクト用バッファに保存されているため，SQLオブジェクト用バッファ長の見積もり時は，コネクションプーリング数及びステートメントプーリング数を考慮して必要なバッファ長を算出してください。

詳細は，マニュアル「HiRDB システム定義」の「バッファに関するオペランド」のpd_sql_object_cache_sizeを参照してください。

7.4　BIツールとの連携

7.4.1　Tableauとの連携

(1)　機能概要

コネクタを使用することによって，HiRDBに格納されているデータをTableauを利用して分析及び可視化できます。

(2)　前提

HiRDB用Tableauコネクタの利用にあたり，次のどれかの製品が必要となります。

Windows版のHiRDBサーバ

Windows版のHiRDB/Run Time

Windows版のHiRDB/Developer's Kit

(a)　接続先HiRDBサーバ

10-09以降のHiRDBに対して接続できます。

プラットフォーム，シングルサーバ，パラレルサーバの条件は問いません。

(b)　HiRDBクライアント

Windows環境であり，JDBC Type4が使用できる環境。

(3)　利用方法

(a)　インストール

HiRDB用Tableauコネクタは，HiRDBをインストールすると同時にインストールされます。インストール後は，次のファイル構成となります。

HiRDBサーバ（Windows版）の場合

HiRDB¥client¥utl¥hirdb_tableau_connector_jdbc.taco

HiRDB/Run Time（Windows版），HiRDB/Developer's Kit（Windows版）の場合

HiRDB¥utl¥hirdb_tableau_connector_jdbc.taco

注

下線で示す部分は，HiRDBのインストールディレクトリを指定します。

(b)　コネクタの利用方法

HiRDB用TableauコネクタをTableau製品の規定の場所に配置すると，TableauからHiRDBに接続できます。

詳細は，取扱説明書「Tableau向けHiRDBコネクタ」を参照してください。

7.4.2　Power BIとの連携

(1)　機能概要

このコネクタは次のツールからのHiRDBへの接続，及びデータ分析をできるようにします。

Power BI Desktop

Microsoft Fabric （Power BI）

(2)　前提

HiRDB用Power BIコネクタの利用にあたり，次のどちらかの製品が必要です。

Windows版のHiRDB/Run Time(64)

Windows版のHiRDB/Developer's Kit(64)

(a)　接続先HiRDBサーバ

10-10以降のHiRDBに対して接続できます。

プラットフォーム，シングルサーバ，パラレルサーバの条件は問いません。

(b)　HiRDBクライアント

Windows環境で，かつHiRDB用ODBC3.5ドライバ（64bit）が使用できる環境が必要です。

(3)　利用方法

(a)　インストール

HiRDB用Power BIコネクタは，HiRDB/Run Time，HiRDB/Developer's Kitをインストールすると同時にインストールされます。インストール後は，次のファイル構成となります。

HiRDB¥utl¥hirdb_powerbi_connector_odbc_<バージョン>.pqx

注

下線で示す部分は，HiRDBのインストールディレクトリを指定します。

(b)　コネクタの利用方法

HiRDB用Power BIコネクタをPower BI製品の規定の場所に配置すると，Power BIからHiRDBに接続できます。詳細は，取扱説明書「Power BI向けHiRDBコネクタ」を参照してください。

8　HiRDB/シングルサーバの設計

この章では，HiRDB/シングルサーバのシステム構成，HiRDBファイルシステム領域の設計方法，システムファイルの設計方法及びRDエリアの配置方法の考慮点について説明します。

8.1　HiRDB/シングルサーバのシステム設計

ここでは，HiRDB/シングルサーバのシステム設計とシステム構成について説明します。

8.1.1　システム設計

(1)　HiRDB/シングルサーバが使用するメモリ

HiRDB/シングルサーバが使用するメモリについて説明します。

HiRDB/シングルサーバは次に示すメモリを使用します。

共用メモリ

プロセス固有メモリ

(a)　メモリ所要量

HiRDB/シングルサーバが必要とするメモリ所要量を見積もってください。HiRDB/シングルサーバのメモリ所要量については，「HiRDB/シングルサーバのメモリ所要量の見積もり」を参照してください。

(b)　共用メモリの割り当て先

HiRDBでは，共用メモリを次の場所に割り当てできます。

OSのページングファイル（仮想メモリ）

運用ディレクトリ下のファイル（初期設定）

共用メモリの割り当て先は，ページングファイルにすることを推奨します。

ページングファイルにする場合，仮想メモリを見積る必要がありますが，運用ディレクトリ下のファイルに割り当てる場合に比べて，NTFSのキャッシュフラッシュによる影響を受けにくくなります。

共用メモリの割り当て先は，pdntenvコマンドの-shmfileオプションで設定できます。pdntenvコマンドについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

(c)　共用メモリのページ固定

HiRDBでは，次に示す共用メモリを実メモリ上に固定できます。

ユニットコントローラ用共用メモリ

グローバルバッファ用共用メモリ

動的変更したグローバルバッファが使用する共用メモリ

インメモリデータバッファ用共用メモリ

共用メモリを実メモリ上に固定すると，ページの入出力が少なくなるため，性能が安定します。

共用メモリを固定すると，共用メモリのページサイズが通常のページサイズ（4KB）からラージページサイズ（2MB）に拡大されます。ページサイズが拡大すると，仮想アドレスを実アドレスに変換するための管理領域（PTE：Page Table Entry）を通常よりも小さくできるため，メモリ不足を防止できます。また，仮想アドレスと物理アドレスの変換回数が少なくなり，ページフォルトの発生を抑えることができます。これによって，トランザクション性能が向上することがあります。

PTEサイズの概算見積もり式については，「メモリ所要量の計算式」を参照してください。

前提条件

共用メモリのページ固定をするための前提条件を次に示します。

Windowsのバージョン

Windowsでは，Large Pageの機能を使用してページ固定をします。そのため，Large PageがサポートされているバージョンのWindowsであることが前提となります。Windowsがページ固定に対応しているかどうかは，pdntenv -osコマンドで確認してください。

ページロックの権限

共用メモリのページ固定をする場合，メモリ内のページをロックできる権限が必要です。サービス実行時に使用するログオンのアカウントによって，この権限の有無が異なります。権限の設定方法を次に示します。

サービス実行時に使用するログオンのアカウント | 権限の設定方法
HiRDB管理者 | HiRDB管理者を，OSの［ローカル セキュリティ設定］−［ローカル ポリシー］−［ユーザー権利の割り当て］で，「メモリ内のページのロック」に設定してください。
ローカルシステムアカウント | ローカルシステムアカウントにはメモリ内のページをロックできる権限があります。そのため，権限の設定は必要ありません。

動作環境の設定

共用メモリのページ固定をするには，共用メモリの割り当て先の指定が必要です。pdntenvコマンドの-shmfileオプションでpageを指定し，共用メモリの割り当て先をページングファイル（仮想メモリ）に設定してください。

ページ固定の方法

共用メモリのページ固定の方法について，共用メモリの種別ごとに説明します。

ユニットコントローラ用共用メモリ

システム共通定義，又はユニット制御情報定義のpd_shmpool_attributeオペランドにfixedを指定します。

グローバルバッファ用共用メモリ

システム共通定義，又はユニット制御情報定義のpd_dbbuff_attributeオペランドにfixedを指定します。

動的変更したグローバルバッファが使用する共用メモリ

システム共通定義，又はユニット制御情報定義のpd_dbbuff_attributeオペランドにfixedを指定します。これによって，pdbufmodコマンドを実行して動的変更したグローバルバッファが使用する共用メモリも実メモリ上に固定されます。

インメモリデータバッファ用共用メモリ

pdmemdbコマンドの-pオプションにfixedを指定します。

注意事項

実メモリ上に連続した領域が確保できなかった場合，共用メモリのページ固定ができません。ページ固定に失敗した場合のHiRDBの動作を次に示します。

ユニットコントローラ用，又はグローバルバッファ用共用メモリの場合

ページ固定をしないで共用メモリを確保し処理を続行します。

動的変更したグローバルバッファが使用する共用メモリ，又はインメモリデータバッファ用共用メモリの場合

HiRDB，又はコマンドが異常終了します。

(d)　共用メモリ再利用機能

HiRDBでは，ユニットコントローラ用共用メモリと，グローバルバッファ用共用メモリをHiRDB開始時に確保します。これらの共用メモリの解放有無は共用メモリ再利用機能の適用有無で制御できます。

共用メモリ再利用機能を適用しない場合，HiRDB停止後にHiRDBを開始する際，前回稼働時に使用していた共用メモリを解放し，新たに共用メモリを確保します。共用メモリのページ固定を使用している場合は，メモリの断片化によって，物理メモリが確保できなくなり，HiRDBの開始に失敗したり，共用メモリのページ固定に失敗したりすることがあります。

共用メモリ再利用機能を適用する場合，HiRDB停止後にHiRDBを開始する際，前回稼働時に使用していた共用メモリを解放せずに再利用します。これによって，共用メモリ確保失敗によるHiRDBの開始失敗を防げます。

共用メモリ再利用機能は，次に示す共用メモリに適用できます。

ユニットコントローラ用共用メモリ

グローバルバッファ用共用メモリ

動的変更したグローバルバッファが使用する共用メモリ

共用メモリ再利用機能の適用方法

システム共通定義，又はユニット制御情報定義のpd_shm_reuseオペランドにYを指定します。

注意事項

共用メモリ再利用機能を適用すると，ユニットコントローラ用共用メモリ及びグローバルバッファ用共用メモリのサイズが大きくなります。「ユニットコントローラが使用する共用メモリの計算式」及び「グローバルバッファが使用する共用メモリの計算式」を参照して共用メモリ所要量を見積もってください。

共用メモリ再利用機能を適用すると，HiRDBが停止した状態でのメモリ使用量がグローバルバッファ用共用メモリのサイズ分多くなります。HiRDBが停止した状態でのメモリ使用量を削減する場合は，OSを再起動してください。

動的変更したグローバルバッファが使用する共用メモリは，前回稼働時に確保した共用メモリサイズと同一サイズになるようなグローバルバッファ定義を追加し，HiRDBを開始した場合に再利用します。

次に示すどちらかの運用をしてからHiRDBを開始すると，ユニットコントローラ用共用メモリとグローバルバッファ用共用メモリを解放し，再度確保します。その際，メモリ不足によってHiRDBの開始に失敗する場合や共用メモリのページ固定に失敗する場合もあります。この場合は，OSを再起動してください。

定義変更によって，ユニットコントローラ用共用メモリのサイズが変更になる。

HiRDBサービスを開始又は再起動する。

次に示すどちらかの運用をしてからHiRDBを開始すると，グローバルバッファ用共用メモリを解放し，再度確保します。その際，メモリ不足によってHiRDBの開始に失敗する場合や共用メモリのページ固定に失敗する場合もあります。この場合は，OSを再起動してください。

SHMMAXオペランドの値を変更する。

サーバ名（pdstartオペランドの-sオプション指定値）を変更する。

共用メモリのページ固定に失敗した場合，ページ固定していない共用メモリを再利用し続けることがあります。共用メモリ再利用機能を適用してもページ固定に失敗した場合は，OSを再起動し，KFPO00107-E(shmget(omminit(fixed)))又はKFPH23045-Wメッセージの対処を実施した後に共用メモリ再利用機能を適用してください。

8.1.2　HiRDB/シングルサーバのシステム構成

HiRDB/シングルサーバのシステム構成例を次の図に示します。

HiRDB/シングルサーバのシステム構成は，HiRDBシステム定義で定義します。HiRDBシステム定義の定義例については，マニュアル「HiRDB システム定義」を参照してください。

図8‒1　HiRDB/シングルサーバのシステム構成

[picture]

8.2　HiRDBファイルシステム領域の設計

HiRDBのシステム構築時に，HiRDBファイルを作成するHiRDBファイルシステム領域を作成します。ここでは，HiRDBファイルシステム領域を作成するときの設計方針について説明します。

HiRDBファイルシステム領域は，次に示す用途ごとに作成することをお勧めします。これによって，用途やアクセス特性の異なるファイルへの入出力が競合することを回避できます。

RDエリア用

システムファイル用

作業表用ファイル用

ユティリティ用

リスト用RDエリア用

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

RDエリア用のHiRDBファイルシステム領域の設計方針について説明します。

(1)　信頼性向上のための方針

特にありません。

(2)　性能向上のための方針

RDエリアを作成するHiRDBファイルシステム領域は，次に示すRDエリア用ごとに作成することをお勧めします。

システム用RDエリア

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

ユーザ用RDエリア

ユーザLOB用RDエリア

レジストリ用RDエリア

レジストリLOB用RDエリア

システムファイル用のHiRDBファイルシステム領域と，RDエリア用のHiRDBファイルシステム領域は，別々のハードディスクに作成することをお勧めします。これによって，シンクポイントダンプを取得するときに入出力の分散ができ，シンクポイントダンプの取得処理時間を短縮できます。

8.2.2　システムファイル用のHiRDBファイルシステム領域の設計

システムファイル用のHiRDBファイルシステム領域の設計方針について説明します。

(1)　信頼性向上のための方針

システムファイル用のHiRDBファイルシステム領域は二つ以上作成してください。一つしか作成しないと，システムファイルがあるハードディスクに障害が発生した場合，HiRDBが稼働できなくなります。

システムファイル用のHiRDBファイルシステム領域は別々のハードディスクに作成してください。そうすれば，どちらかのハードディスクに障害が発生しても，HiRDBを再開始できます。

(2)　性能向上のための方針

システムファイル用のHiRDBファイルシステム領域と，RDエリア用のHiRDBファイルシステム領域は，別々のハードディスクに作成することをお勧めします。これによって，シンクポイントダンプを取得するときに入出力の分散ができ，シンクポイントダンプの取得処理時間を短縮できます。

8.2.3　作業表用ファイル用のHiRDBファイルシステム領域の設計

作業表用ファイル用のHiRDBファイルシステム領域の設計方針について説明します。

(1)　設計方針

作業表用ファイル用のHiRDBファイルシステム領域長は，そのHiRDBファイルシステム領域に作成する作業表用ファイルの総容量より大きくしてください。なお，pdfmkfsコマンドで-aオプションを指定すると，HiRDBファイルシステム領域を自動的に拡張できます。作業表用ファイルの総容量がHiRDBファイルシステム領域長に達した場合，自動でHiRDBファイルシステム領域を拡張できるため，-aオプションを指定することをお勧めします。※

作業表用ファイルの容量については，「作業表用ファイルの容量の見積もり」を参照してください。

注※

HiRDB再開始時に作業表用ファイル用のHiRDBファイルシステム領域のディスク占有サイズを削減したい場合は，HiRDB再開始前にpdfmkfsコマンドを実行して作業表用ファイル用のHiRDBファイルシステム領域を再初期化してください。

(2)　最大使用量を調べる方法

作業表用ファイル用のHiRDBファイルシステム領域の最大使用量を次に示す方法で調べられます。

pdfstatfs　-d　作業表用のHiRDBファイルシステム領域名

-d：

HiRDBファイルシステム領域の最大使用量を表示するオプションです。出力情報のpeak capacityが最大使用量です。なお，上記の最大使用量はpdfstatfsコマンドでクリアできます。

pdfstatfs　-c　作業表用のHiRDBファイルシステム領域名

-c：

HiRDBファイルシステム領域の最大使用量をクリアするオプションです。

8.2.4　ユティリティ用のHiRDBファイルシステム領域の設計

ユティリティ用（バックアップファイル，アンロードデータファイル，アンロードログファイル作成用）のHiRDBファイルシステム領域の設計方針について説明します。ユティリティ用のHiRDBファイルシステム領域には，次に示すファイルを作成します。

バックアップファイル

アンロードデータファイル

アンロードログファイル

差分バックアップ管理ファイル

(1)　設計方針

バックアップファイル作成用にする場合は，HiRDBファイルシステム領域長をバックアップ対象RDエリアの総容量より大きくしてください。RDエリアの容量については，「RDエリアの容量の見積もり」を参照してください。

系切り替え機能使用時は，アンロードログファイルを共有ディスク上に作成してください。

アンロードログファイル作成用にする場合は，pdfmkfsコマンドのオプションに次に示す値を指定してください。

-kオプション：使用目的にはUTL（ユティリティ用のHiRDBファイルシステム領域）を指定します。

-nオプション：HiRDBファイルシステム領域長には次に示す計算式の値を指定します。

（アンロードするシステムログファイルの総レコード数※１×システムログファイルのレコード長）※２×作成するアンロードログファイル数×1.2÷1048576

-lオプション：最大ファイル数には，作成するアンロードログファイル数を指定します。

-eオプション：最大増分回数には，作成するアンロードログファイル数×23を指定します。

注※1

システムログファイルの自動拡張機能を適用している場合，pd_log_auto_expand_sizeオペランドの拡張上限サイズに指定した値で計算してください。

注※2

システムログファイルの概算値です。

(2)　最大使用量を調べる方法

ユティリティ用のHiRDBファイルシステム領域の最大使用量を次に示す方法で調べられます。

pdfstatfs　-d　ユティリティ用のHiRDBファイルシステム領域名

-d：

HiRDBファイルシステム領域の最大使用量を表示するオプションです。出力情報のpeak capacityが最大使用量です。なお，上記の最大使用量はpdfstatfsコマンドでクリアできます。

pdfstatfs　-c　ユティリティ用のHiRDBファイルシステム領域名

-c：

HiRDBファイルシステム領域の最大使用量をクリアするオプションです。

8.2.5　リスト用RDエリア用のHiRDBファイルシステム領域の設計

リスト用RDエリア用のHiRDBファイルシステム領域の設計方針について説明します。

(1)　設計方針

リストは検索の一時的な中間結果を保存するものなので，ほかのRDエリアほど信頼性は要求されません。

(2)　性能向上のための方針

リスト用RDエリア用のHiRDBファイルシステム領域は，次に示すHiRDBファイルシステム領域とは別々のハードディスクに作成することをお勧めします。別々のハードディスクに作成すると，リストを検索するときに入出力を分散できるため，処理時間を短縮できます。

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

ユーザLOB用RDエリア用のHiRDBファイルシステム領域

作業表用ファイル用のHiRDBファイルシステム領域

8.2.6　HiRDBファイルシステム領域の最大長

HiRDBファイルシステム領域の最大長は，1,048,575メガバイトです。

8.2.7　系切り替え機能使用時の注意事項

系切り替え機能で使用するHiRDBファイルシステム領域を作成する場合の注意事項を次に示します。

pdfmkfsコマンドの-iオプションを指定してください。-iオプションを指定しないと，HiRDBファイルシステム領域の拡張とサーバマシンの電源異常が同時に発生した場合にファイルが破壊されることがあります。

pdfmkfsコマンドの-kオプションにSVR（省略値）を指定しないでください。-kオプションにSVRを指定して作成したHiRDBファイルシステム領域に対して，HiRDBはWindowsのファイルキャッシュに書き込んだ時点で処理を続行します。このため，ディスク上にデータが書き込まれる前に異常が発生するとファイルの整合性がとれなくなります。

8.3　システムファイルの設計

ここでは，システムファイルの設計方針について説明します。

8.3.1　システムログファイルの設計

システムログファイルの設計方針について説明します。

(1)　設計方針

すべてのシステムログファイルのレコード長及びレコード数を同じにしてください。

作成できるシステムログファイルは，2〜200グループです（ただし，6グループ以上作成することを推奨します）。

一つのサーバに対して，次の式を満たすようにシステムログファイルを作成します。

100（単位：ギガバイト）×（200−サーバに割り当てるシステムログファイルグループ数）≧サーバに割り当てるシステムログファイルの総容量×3

これは，システムログファイルの容量不足によって異常終了したHiRDBを再開始する場合に必要になります。システムログファイルが容量不足になった状況や運用によっては，サーバに割り当てられている3倍の容量のシステムログファイルを作成し，サーバに追加して対処する必要があるためです。

アンロードする回数を少なくしたい場合は，システムログファイルの1ファイル容量を大きくします。

HiRDB運用ディレクトリがあるディスクに大量に入出力が発生するファイル（システムログのアンロードログファイルなど）を作成しないでください。

全システムログファイルの容量（二重化している場合は片系の容量だけを対象とする）は，次に示す二つの条件を満たす必要があります。

条件1

「システムログファイルの総容量の求め方」で見積もった容量以上の値にしてください。

条件2

長大トランザクションが終了するまでは，長大トランザクション開始以降のシステムログファイルの上書きができません。また，シンクポイントダンプファイルの有効保証世代とカレント世代のシステムログファイルは上書きできません。そのため，これらの分のシステムログファイル容量を確保してください。次の計算式で求めます。

システムログファイルの総容量（バイト）≧3×a×（b＋1）

ａ：

データベースを更新するトランザクションのうち，実行時間が最大のトランザクション実行中に該当するサーバで出力されることのあるシステムログ量

システムログ量の見積もり式については，「システムログファイルの容量の見積もり」を参照してください。

ｂ：pd_spd_assurance_countオペランドの値

シンクポイントダンプファイルの有効保証世代数です。

(a)　システムログファイルの世代数と運用への影響

システムログファイルの総容量が同じ場合，システムログファイルの世代数によって，1世代当たりの容量が変化します。システムログファイルの世代数と運用への影響を次の表に示します。システムログファイルの総容量は同じとします。

表8‒1　システムログファイルの世代数と運用への影響

比較項目 | システムログファイルの構成
世代数を少なくした場合 | 世代数を多くした場合
システムログファイル1世代当たりの容量 | 大きくなります。 | 小さくなります。
スワップ間隔 | システムログファイル1世代当たりの容量が大きくなるため，スワップ間隔は長くなります。 | システムログファイル1世代当たりの容量が小さくなるため，スワップ間隔は短くなります。
アンロード回数 | スワップ間隔が長くなるため，アンロード回数は少なくなります。 | スワップ間隔が短くなるため，アンロード回数は多くなります。
ディスク障害などでシステムログファイルの数世代が使用できなくなった場合のシステムログ容量への影響 | システムログファイル1世代当たりの容量が大きくなるため，ディスク障害時にデータベースの回復に用いるログ量は多くなり，データベース回復に掛かる時間は長くなります。 システムログ容量の減少幅が大きいため，システムログの容量が減少したことによるHiRDBの稼働に及ぼす影響は大きくなります。 | システムログファイル1世代当たりの容量が小さくなるため，ディスク障害時にデータベースの回復に用いるログ量は少なくなり，データベース回復に掛かる時間は短くなります。 システムログ容量の減少幅が小さいため，システムログの容量が減少したことによるHiRDBの稼働に及ぼす影響は小さくなります。

通常の運用では，システムログファイルの世代数を少なくした場合の方がスワップ間隔及びアンロード回数の点で利点があります。ただし，障害発生時には，世代数を多くした場合の方が障害の影響が小さくなります。

(2)　信頼性向上のための方針

(a)　システムログファイルの二重化

システムログファイルを二重化すると，HiRDBは両方の系に同じシステムログを取得します。取得したシステムログを読み込むとき，片方のファイルに異常が発生しても，もう一方のファイルからシステムログを読み込めるため，システムの信頼性を向上できます。なお，二重化する場合，ディスクをミラー化して二重化するより，HiRDB管理下で二重化することをお勧めします。システムログファイルを二重化する場合は，それぞれの系のファイルを別々のハードディスクに作成してください。

システムログファイルを二重化する場合は，サーバ定義で次に示すオペランドを指定してください。

pd_log_dual = Y

pdlogadpfオペランドの-bオプション（B系のシステムログファイル名を指定します）

(b)　システムログファイルの片系運転

システムログファイルの片系運転は，システムログファイルを二重化する場合に適用されます。

システムログファイルに障害が発生して，両系とも使用できるシステムログファイルがない場合でも，HiRDBのユニットを異常終了しないで正常な系だけで処理を続行できます。これをシステムログファイルの片系運転といいます。システムログファイルの片系運転をする場合は，サーバ定義でpd_log_singleoperation = Yを指定してください。

システムログファイルの片系運転に対し，両方のシステムログファイルで処理を続行すること（通常の処理形態）をシステムログファイルの両系運転といいます。

(c)　システムログファイルの自動オープン

HiRDBを再開始するときに，上書きできる状態のシステムログファイルがない場合，予約のファイルがあればHiRDBが予約のファイルをオープンして上書きできる状態にし，処理を続行します。これをシステムログファイルの自動オープンといいます。

システムログファイルの自動オープンをする場合は，サーバ定義でpd_log_rerun_reserved_file_open = Yを指定してください。

(3)　可用性向上のための方針

(a)　システムログファイルの空き容量監視機能

システムログファイルのスワップ時に，スワップ先にできる状態のシステムログファイルがないとHiRDBは異常終了します。これを予防するため，HiRDBにはシステムログファイルの空き容量を監視する機能（システムログファイルの空き容量監視機能）があります。この機能は，システムログファイルの空き率が警告値未満になったときに作動します。次に示す二つのレベルのどちらかを選択できます。

レベル1：

システムログファイルの空き率が警告値未満になった場合，警告メッセージKFPS01162-Wを出力します。

レベル2：

システムログファイルの空き率が警告値未満になった場合，新規トランザクションのスケジューリングを抑止して，サーバ内の全トランザクションを強制終了します。このとき，KFPS01160-Eメッセージを出力します。これによって，システムログの出力量を抑えます。

レベル2を選択した場合，システムログファイルの空き容量が不足したときにサーバ内の全トランザクションが強制終了されます。このため，システムログファイルの設計をより正確に行う必要があります。

システムログファイルの空き容量監視機能については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(b)　システムログファイルの自動拡張機能

システムログファイルの容量不足が発生すると，HiRDBシステム（又はユニット）が異常終了します。これを回避するため，自動的にシステムログファイルの容量を拡張する機能（システムログファイルの自動拡張機能）を提供しています。この機能を適用することで，システムログファイルの容量不足によるHiRDBシステム（又はユニット）の異常終了の頻度を低減できます。

システムログファイルの自動拡張機能については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(c)　シンクポイントダンプ有効化のスキップ回数監視機能

UAPが無限ループしてデータベースを更新し続けるとシンクポイントが有効化できないため，上書きできない状態のシステムログファイルが増えてしまいます。上書きできない状態のシステムログファイルが増えて全システムログファイルが上書きできない状態になると，HiRDBが異常終了します。

また，上書きできない状態のシステムログファイルが，全システムログファイルの1/3以上になったときにHiRDBが異常終了又は強制終了すると，HiRDBを再開始するときのロールバック処理でシステムログファイルが不足する場合があります。この場合，システムログファイルを新規追加しないと，HiRDBを再開始できません。そして，この再開始処理に要する時間も長くなります。

このようなことを防ぐために，HiRDBではシンクポイントダンプ有効化のスキップ回数監視機能を設けています。

シンクポイントダンプ有効化のスキップ回数監視機能については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(4)　システムログファイルのレコード長（既にHiRDBを稼働している場合）

レコード長が1024以外の場合，システムログの格納効率を良くするために1024に変更することをお勧めします。

システムログファイルのレコード長の変更方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(5)　システムログファイルの定義

作成したシステムログファイルをどのファイルグループに対応させるかをサーバ定義のpdlogadfg及びpdlogadpfオペランドで定義します。

8.3.2　シンクポイントダンプファイルの設計

シンクポイントダンプファイルの設計方針について説明します。

(1)　設計方針

作成できるシンクポイントダンプファイルは，2〜60グループです。pdlogadfg -d spdオペランドにONLを指定した場合は，2〜30グループです。

HiRDBはpdlogadfg -d spdオペランドの指定順にシンクポイントダンプファイルを使用します。

4個以上のシンクポイントダンプファイルを作成することをお勧めします。

シンクポイントダンプファイルの容量が不足すると，HiRDBを開始できません。このため，シンクポイントダンプファイルのレコード数は，システム共通定義の最大同時接続数（pd_max_usersオペランド）の指定値より大きな値にしてください。詳細なシンクポイントダンプファイルの容量計算式については，「シンクポイントダンプファイルの容量の見積もり」を参照してください。

シンクポイントダンプファイルを二重化する場合は，有効保証世代数は1をお勧めします。二重化しない場合は，有効保証世代数に2を設定することをお勧めします。有効保証世代数に2を設定する場合は，システムログファイル不足によるHiRDB異常終了が発生しないようにシステムログファイルの容量を考慮してください。

(2)　信頼性向上のための方針

(a)　ファイル構成例

ハードディスク障害に備えて，シンクポイントダンプファイルをそれぞれ別々のハードディスクに作成してください。そのような構成を取れない場合は，隣り合わせの世代を別々のハードディスクに作成する構成にしてください。例を次の図に示します。

図8‒2　隣り合わせの世代を別々のハードディスクに作成する構成例

[picture]

(b)　シンクポイントダンプファイルの二重化

シンクポイントダンプファイルを二重化すると，HiRDBはA系及びB系の両方に同じシンクポイントダンプを取得します。取得したシンクポイントダンプを読み込むとき，片方のファイルに異常が発生しても，もう一方のファイルからシンクポイントダンプを読み込めるため，システムの信頼性を向上できます。また，二重化している場合，有効保証世代数を1世代にすると，信頼性を損ねることなく上書きできない状態のシンクポイントダンプファイル数を削減できます。

シンクポイントダンプファイルを二重化する場合は，サーバ定義で次に示すオペランドを指定してください。

pd_spd_dual = Y

pdlogadpfオペランドの-bオプション（B系のシステムログファイル名を指定します）

(c)　シンクポイントダンプファイルの片系運転

シンクポイントダンプファイルの片系運転は，シンクポイントダンプファイルを二重化する場合に適用されます。シンクポイントダンプファイルは，片方のファイルに異常が発生しても，正常な系だけで処理を続行します。これをシンクポイントダンプファイルの片系運転といいます。

(d)　シンクポイントダンプファイルの有効保証世代数

一つのシンクポイントダンプファイルには，HiRDBが1回に取得するシンクポイントダンプが格納されます。HiRDBは，シンクポイントダンプファイルを世代という概念で管理しています。HiRDB管理者は，何世代前までのシンクポイントダンプファイルに対応するシステムログファイルを上書きできない状態にするかを指定できます。これをシンクポイントダンプファイルの有効保証世代数といいます。シンクポイントダンプファイルの有効保証世代数を次の図に示します。

図8‒3　シンクポイントダンプファイルの有効保証世代数

[picture]

〔説明〕

有効保証世代を2とすると，2世代前までのシンクポイントダンプファイル及びそのシンクポイントダンプファイルに対応するシステムログファイルが，上書きできない状態になります。3世代前より前の世代のシンクポイントダンプファイル及びそのシンクポイントダンプファイルに対応するシステムログファイルは，上書きできる状態になります。

シンクポイントダンプファイルの運用に必要なファイル数は，有効保証世代数＋1となります。シンクポイントダンプファイルの有効保証世代数は，サーバ定義のpd_spd_assurance_countオペランドで指定してください。

なお，シンクポイントダンプファイルを二重化している場合，必要な有効保証世代数は1世代をお勧めします。二重化していない場合，2世代をお勧めします。

(e)　シンクポイントダンプファイルの縮退運転

シンクポイントダンプファイルに障害が発生して，使用できるシンクポイントダンプファイル数が運用に必要なファイル数（有効保証世代数＋1）未満になった場合でも，最低二つのファイルで処理を続行できます。これをシンクポイントダンプファイルの縮退運転といいます。

シンクポイントダンプファイルの縮退運転をする場合は，サーバ定義のpd_spd_reduced_modeオペランドを指定してください。

(f)　シンクポイントダンプファイルの自動オープン

シンクポイントダンプファイルに障害が発生して，使用できるシンクポイントダンプファイル数が運用に必要なファイル数（有効保証世代数＋1）未満になった場合，予約のファイルがあればHiRDBが予約のファイルをオープンして上書きできる状態にし，処理を続行します。これをシンクポイントダンプファイルの自動オープンといいます。

シンクポイントダンプの自動オープンをする場合は，サーバ定義でpd_spd_reserved_file_auto_open = Yを指定してください。

(3)　シンクポイントダンプファイルの定義

作成したシンクポイントダンプファイルをどのファイルグループに対応させるかをpdlogadfg及びpdlogadpfオペランドで定義します。

なお，pdlogadfgオペランドだけを指定しておくと，HiRDB稼働中にシンクポイントダンプファイルを追加できます。

8.3.3　ステータスファイルの設計

ステータスファイルの設計方針について説明します。

(1)　設計方針

両系のファイルに障害が起きないように，A系とB系のファイルは別々のディスクに作成します。

ステータスファイルの容量不足によるHiRDBの異常終了を防ぐため，見積もったファイル容量よりも大きい容量の予備ファイルを幾つか作成してください。ステータスファイルは，容量が満杯になると予備ファイルとスワップしますが，満杯になったステータスファイルと予備ファイルの容量が同じ場合，スワップ先のファイルでも容量不足になり，HiRDBは異常終了します。そのため，例えばステータスファイルを6組作成する場合，そのうちの2組以上のファイル容量をほかのファイル容量より大きくすることをお勧めします。

A系とB系のファイルのレコード長及びレコード数を同じにしてください。

作成できるユニット用ステータスファイルは1〜7組です。

作成できるサーバ用ステータスファイルは1〜7組です。

(2)　信頼性向上のための方針

ステータスファイルは3組（二重化×3=6ファイル）以上用意し，ディスク障害によってすべてのステータスファイルが障害とならないように配置します。

容量不足によるHiRDBの異常終了を防ぐため，ステータスファイルの容量は見積もった容量の1.2倍以上の容量を準備することをお勧めします。

ステータスファイルには，HiRDBの再開始処理でシステムの状態を回復するために必要な情報を格納しています。予備ファイルがない状態で現用ファイルに障害が発生すると，システムの状態が回復できません。したがって，常に予備ファイルがあるように運用し，現用ファイルの障害に備えてください。

(a)　お勧めする構成

ディスク障害発生時から回復時までの安全性を考えると，ステータスファイルは四つのディスクに6組（二重化×6=12ファイル）用意し，次の図のように配置することをお勧めします。また，片系運転中に正常な系に障害が発生すると，HiRDBを再開始できなくなるため，ステータスファイルの片系運転は適用しない（pd_syssts_singleoperation及びpd_sts_singleoperationにstopを指定）ことをお勧めします。

四つのディスクにステータスファイルを6組配置する例を次の図に示します。

図8‒4　四つのディスクに6組のステータスファイルを配置する例

[picture]

〔説明〕

このように配置すると，あるディスクで障害が発生した後に，更に別のディスクで障害が発生しても，残りの二つのディスクに両系とも正常なファイルが残るため，障害が発生していないディスクのステータスファイルを現用としてHiRDBを稼働し続けることができます。例えば，ディスクAに障害が発生し，その後ディスクBにも障害が発生した場合でも，ディスクC及びDにある両系のステータスファイル（sts-3aとsts-3b）を現用ファイルとして稼働し続けます。この状態で，更に現用ファイルの片系に障害が発生した場合，HiRDBは異常終了しますが，現用ファイルの片系ファイルが正常のため，障害が発生したディスクのどれか一つを回復するとHiRDBを再開始できます。

(3)　ステータスファイルの定義

pdstsinitコマンドで作成したステータスファイルをどの論理ファイルに対応させるかをpd_syssts_file_name_1〜7及びpd_sts_file_name_1〜7オペランドで定義します。

ユニット用ステータスファイルは，pd_syssts_file_name_1〜7オペランドで定義します。サーバ用ステータスファイルは，pd_sts_file_name_1〜7オペランドで定義します。

なお，pd_syssts_file_name_2〜7オペランド又はpd_sts_file_name_2〜7オペランドに，実体のないステータスファイルを定義しておくと，HiRDB稼働中にステータスファイルを追加できます。ただし，この場合，次に示すオペランドを指定しておく必要があります。

ユニット用ステータスファイルの場合

pd_syssts_initial_error

pd_syssts_last_active_file

サーバ用ステータスファイルの場合

pd_sts_initial_error

pd_sts_last_active_file

(4)　ステータスファイルの片系運転

予備ファイルがない状況で現用ファイルの片系に障害が発生した場合，正常な系（片方の系）だけで処理を続行することをステータスファイルの片系運転といいます。ステータスファイルが片系運転になると，KFPS01044-Iメッセージが出力されます。

片系運転中に現用ファイルに障害が発生すると，HiRDBを再開始できなくなるため，ステータスファイルの片系運転の適用は推奨しません。ステータスファイルの組数を増やし，予備ファイルがない状況が発生しないような運用をしてください。

なお，ステータスファイルの片系運転に対し，両方の系のステータスファイルで処理を続行すること（通常の処理形態）をステータスファイルの両系運転といいます。

(a)　ステータスファイルの片系運転適用のメリット及びデメリット

メリット

予備ファイルがない状況で現用ファイルの片系に障害が発生しても，処理を続行できます。このため，ステータスファイルの障害によってHiRDBが停止する可能性が低くなります。

デメリット

片系運転中に正常な系に障害が発生したり，又はステータスファイルの更新中にHiRDBが異常終了したりすると，現用ファイルの内容が失われるため，HiRDBを再開始できなくなります。

(b)　指定方法

ユニット用ステータスファイルの片系運転をする場合は，ユニット制御情報定義でpd_syssts_singleoperation = continueを指定してください。サーバ用ステータスファイルの片系運転をする場合は，サーバ定義でpd_sts_singleoperation = continueを指定してください。なお，pd_syssts_singleoperationとpd_sts_singleoperationの指定値を同じにしてください。

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

pd_syssts_singleoperation及びpd_syssts_initial_errorオペランド，又はpd_sts_singleoperation及びpd_sts_initial_errorオペランドの指定値の組み合わせによって，HiRDBの起動時にステータスファイルの障害を検知した場合のHiRDBの動作が決定します。したがって，これら二つのオペランドの指定値は一緒に考えるようにしてください。HiRDBの起動時にステータスファイルの障害を検知した場合のHiRDBの動作については，マニュアル「HiRDB システム定義」の，pd_syssts_initial_error又はpd_sts_initial_errorオペランドの説明を参照してください。

(c)　適用の目安

ステータスファイルの片系運転の適用の目安を次に示します。

HiRDBが再開始できない状態を避けることを重視した運用の場合は，適用しないでください。

HiRDBがオンラインダウンとなる状態を避けることを重視した運用の場合は，適用してください。

系切り替え構成を適用している場合など，HiRDBの再開始を自動で行う運用の場合は，適用しないでください。

(d)　片系運転適用時の注意

片系運転適用の有無によるHiRDBの動作及びHiRDB管理者の処置について次の表に示します。ステータスファイルに障害が発生したときの対処方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

表8‒2　片系運転適用の有無によるHiRDBの動作及びHiRDB管理者の処置

条件 | ステータスファイルの片系運転 （pd_syssts_singleoperation又はpd_sts_singleoperationオペランドの指定値）
適用する（continue指定） | 適用しない（省略又はstop指定）

予備ファイルがある

現用ファイルに障害が発生

HiRDBの動作

ステータスファイルをスワップします。

HiRDB管理者の処置

障害が発生したステータスファイルの障害対策をしてください。

現用ファイルの両系に，同時に障害が発生

HiRDBの動作

異常終了します。HiRDBは再開始できません。

HiRDB管理者の処置

マニュアル「HiRDB システム運用ガイド」の「ステータスファイルに障害が発生したときの対処方法」を参照してください。

予備ファイルがない

現用ファイルの片系に障害が発生

HiRDBの動作

片系運転を適用し，処理を続行します。

HiRDB管理者の処置

早急に予備のファイルを作成して，両系運転の状態に戻してください。

HiRDBの動作

異常終了します。

HiRDB管理者の処置

予備ファイルを作成し，HiRDBを再開始してください。

現用ファイルの両系に，同時に障害が発生

HiRDBの動作

異常終了します。HiRDBは再開始できません。

HiRDB管理者の処置

マニュアル「HiRDB システム運用ガイド」の「ステータスファイルに障害が発生したときの対処方法」を参照してください。

片系運転中に，正常な系に障害が発生

HiRDBの動作

異常終了します。HiRDBは再開始できません。

HiRDB管理者の処置

マニュアル「HiRDB システム運用ガイド」の「ステータスファイルに障害が発生したときの対処方法」を参照してください。

−

（凡例）−：該当しません。

(5)　ステータスファイルの障害に関する注意事項（重要）

現用ファイルの両系に同時に障害が発生した場合，HiRDBが異常終了し，再開始できなくなります。対策として，物理ディスクの多重化（ミラーリング）が考えられます。

HiRDBの開始前に，現用ファイル（終了時の現用ファイル）を削除，又はpdstsinitコマンドでステータスファイルを初期化した場合，HiRDBは再開始できなくなります。

8.4　RDエリアの配置

ここでは，次に示すRDエリアを配置するときの考慮点について説明します。

システム用RDエリア

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

ユーザ用RDエリア

ユーザLOB用RDエリア

リスト用RDエリア

8.4.1　システム用RDエリアの配置

システム用RDエリアは，ユーザ用RDエリアの配置を考慮して配置します。システム用RDエリアを配置するときの考慮点を次に示します。

ユーザ用RDエリアを配置するディスクとは異なるディスクに配置するようにします。

システム用RDエリアのうち，特にデータディクショナリ用RDエリアとデータディレクトリ用RDエリアは，SQL文の解析などのためにHiRDBにアクセスされることが多くなります。このため，ユーザ用RDエリアを配置するディスクと同じディスクに配置すると，SQL文の解析などのためのアクセスと，表に対するアクセスがディスク上で競合するため，どちらか一方が他方のアクセスが終了するまで待たされることになります。

ディスクアクセスの競合を発生させないためのシステム用RDエリアの配置例を次の図に示します。

図8‒5　システム用RDエリアの配置例（HiRDB/シングルサーバの場合）

[picture]

8.4.2　データディクショナリLOB用RDエリアの配置

ディスクに対するアクセスの競合をなくすため，ほかのRDエリアを配置するディスクとは異なるディスクに配置するようにします。データディクショナリLOB用RDエリアの配置例を次の図に示します。

図8‒6　データディクショナリLOB用RDエリアの配置例（HiRDB/シングルサーバの場合）

[picture]

データディクショナリ用RDエリアとの関連

ストアドプロシジャ又はストアドファンクションを管理するディクショナリ表をほかのディクショナリ表とは別のデータディクショナリ用RDエリアに格納できます。

8.4.3　ユーザ用RDエリアの配置

(1)　システムログファイルとの関連

システムログファイルを配置したディスクとは異なるディスクに，ユーザ用RDエリアを配置するようにします。このようにすることで，シンクポイント時のシステムログファイルとユーザ用RDエリアを構成するHiRDBファイルへの入出力処理を複数のディスクに分散できるため，シンクポイントでの処理時間を削減できます。

(2)　システム用RDエリアとの関連

システム用RDエリアを配置したディスクとは異なるディスクにユーザ用RDエリアを配置するようにします。

(3)　表を横分割した場合

表を横分割した場合，横分割表を格納するRDエリアを異なるディスクに配置します。ユーザ用RDエリアの配置例を次の図に示します。

図8‒7　ユーザ用RDエリアの配置例（HiRDB/シングルサーバの場合）

[picture]

8.4.4　ユーザLOB用RDエリアの配置

ディスクに対するアクセスの競合をなくすため，ユーザLOB用RDエリア以外のRDエリアを配置したディスクとは異なるディスクにユーザLOB用RDエリアを配置するようにします。

また，表を横分割した場合，横分割表を格納するRDエリアを異なるディスクに配置します。ユーザLOB用RDエリアの配置例を次の図に示します。

図8‒8　ユーザLOB用RDエリアの配置例（HiRDB/シングルサーバの場合）

[picture]

8.4.5　リスト用RDエリアの配置

ディスクに対するアクセスの競合をなくすため，リスト用RDエリア以外のRDエリアを配置したディスクとは異なるディスクにリスト用RDエリアを配置するようにします。

なお，リスト用RDエリアを一つ以上作成すれば，すべてのユーザ用RDエリアに格納されている表に対するリストを作成できます。

リスト用RDエリアの配置例を次の図に示します。

図8‒9　リスト用RDエリアの配置例（HiRDB/シングルサーバの場合）

[picture]

9　HiRDB/パラレルサーバの設計

この章では，HiRDB/パラレルサーバのシステム構成，HiRDBファイルシステム領域の設計方法，システムファイルの設計方法及びRDエリアの配置方法の考慮点について説明します。

9.1　HiRDB/パラレルサーバのシステム設計

ここでは，HiRDB/パラレルサーバのシステム設計とシステム構成について説明します。

9.1.1　システム設計

(1)　サーバ構成

フロントエンドサーバ，ディクショナリサーバ及びバックエンドサーバをそれぞれ一つのサーバマシンに配置するのが，HiRDB/パラレルサーバの基本的なサーバ構成です。ただし，各サーバマシンのCPUの処理負荷が高くない場合，一つのサーバマシンに複数のサーバを配置してもかまいません。一つのサーバマシンに複数のサーバを配置すると，必要とする共用メモリが増加します。共用メモリが不足すると，ユニットが開始できなくなるため，メモリ所要量を十分見積もってください。

設置できるサーバ数の範囲を次の表に示します。

表9‒1　設置できるサーバ数の範囲

項目 | 設置できるサーバ数の範囲
システムマネジャ数 | 1
フロントエンドサーバ数 | 1〜1,024
ディクショナリサーバ数 | 1
バックエンドサーバ数 | 1〜16,382
1ユニットに作成できるサーバ数 | 1〜34

(2)　システムマネジャの設置

次に示す理由のため，システムマネジャを定義するサーバマシンはHiRDB管理者が運用しやすい場所に設置することをお勧めします。

HiRDB管理者はコマンドでHiRDBを操作しますが，大部分のコマンドはシステムマネジャを定義するサーバマシンから入力する必要がある

(3)　フロータブルサーバの設置

HiRDBは結合処理のような複雑な検索処理をする場合，データベースを持たないバックエンドサーバを優先的に使用して，処理性能を向上します。サーバマシンに余裕があり，複雑な検索処理をする場合にフロータブルサーバの設置を検討してください。フロータブルサーバを設置する場合，作業表用ファイル用のHiRDBファイルシステム領域を作成してください。作業表用ファイル用のHiRDBファイルシステム領域の名称は，バックエンドサーバ定義のpdworkオペランドで指定します。

(4)　フロントエンドサーバの複数化

SQL処理のCPU負荷が高く，一つのフロントエンドサーバで処理しきれない場合，フロントエンドサーバを複数設定します。これをマルチフロントエンドサーバといいます。マルチフロントエンドサーバについては，「マルチフロントエンドサーバの設定」を参照してください。

(5)　HiRDB/パラレルサーバが使用するメモリ

HiRDB/パラレルサーバが使用するメモリについて説明します。

HiRDB/パラレルサーバは次に示すメモリを使用します。

共用メモリ

プロセス固有メモリ

(a)　メモリ所要量

HiRDB/パラレルサーバが必要とするメモリ所要量をサーバマシンごとに見積もってください。HiRDB/パラレルサーバのメモリ所要量については，「HiRDB/パラレルサーバのメモリ所要量の見積もり」を参照してください。

(b)　共用メモリの割り当て先

HiRDBでは，共用メモリを次の場所に割り当てできます。

OSのページングファイル（仮想メモリ）

運用ディレクトリ下のファイル（初期設定）

共用メモリの割り当て先は，ページングファイルにすることを推奨します。

ページングファイルにする場合，仮想メモリを見積る必要がありますが，運用ディレクトリ下のファイルに割り当てる場合に比べて，NTFSのキャッシュフラッシュによる影響を受けにくくなります。

共用メモリの割り当て先は，pdntenvコマンドの-shmfileオプションで設定できます。pdntenvコマンドについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

(c)　共用メモリのページ固定

HiRDBでは，次に示す共用メモリを実メモリ上に固定できます。

ユニットコントローラ用共用メモリ

グローバルバッファ用共用メモリ

動的変更したグローバルバッファが使用する共用メモリ

インメモリデータバッファ用共用メモリ

共用メモリを実メモリ上に固定すると，ページの入出力が少なくなるため，性能が安定します。

共用メモリを固定すると，共用メモリのページサイズが通常のページサイズ（4KB）からラージページサイズ（2MB）に拡大されます。ページサイズが拡大すると，仮想アドレスを実アドレスに変換するための管理領域（PTE：Page Table Entry）を通常よりも小さくできるため，メモリ不足を防止できます。また，仮想アドレスと物理アドレスの変換回数が少なくなり，ページフォルトの発生を抑えることができます。これによって，トランザクション性能が向上することがあります。

PTEサイズの概算見積もり式については，「メモリ所要量の計算式」を参照してください。

前提条件

共用メモリのページ固定をするための前提条件を次に示します。

Windowsのバージョン

Windowsでは，Large Pageの機能を使用してページ固定をします。そのため，Large PageがサポートされているバージョンのWindowsであることが前提となります。Windowsがページ固定に対応しているかどうかは，pdntenv -osコマンドで確認してください。

ページロックの権限

共用メモリのページ固定をする場合，メモリ内のページをロックできる権限が必要です。サービス実行時に使用するログオンのアカウントによって，この権限の有無が異なります。権限の設定方法を次に示します。

サービス実行時に使用するログオンのアカウント | 権限の設定方法
HiRDB管理者 | HiRDB管理者を，OSの［ローカル セキュリティ設定］−［ローカル ポリシー］−［ユーザー権利の割り当て］で，「メモリ内のページのロック」に設定してください。
ローカルシステムアカウント | ローカルシステムアカウントにはメモリ内のページをロックできる権限があります。そのため，権限の設定は必要ありません。

動作環境の設定

共用メモリのページ固定をするには，共用メモリの割り当て先の指定が必要です。pdntenvコマンドの-shmfileオプションでpageを指定し，共用メモリの割り当て先をページングファイル（仮想メモリ）に設定してください。

ページ固定の方法

共用メモリのページ固定の方法について，共用メモリの種別ごとに説明します。

ユニットコントローラ用共用メモリ

システム共通定義，又はユニット制御情報定義のpd_shmpool_attributeオペランドにfixedを指定します。

グローバルバッファ用共用メモリ

システム共通定義，又はユニット制御情報定義のpd_dbbuff_attributeオペランドにfixedを指定します。

動的変更したグローバルバッファが使用する共用メモリ

システム共通定義，又はユニット制御情報定義のpd_dbbuff_attributeオペランドにfixedを指定します。これによって，pdbufmodコマンドを実行して動的変更したグローバルバッファが使用する共用メモリも実メモリ上に固定されます。

インメモリデータバッファ用共用メモリ

pdmemdbコマンドの-pオプションにfixedを指定します。

注意事項

実メモリ上に連続した領域が確保できなかった場合，共用メモリのページ固定ができません。ページ固定に失敗した場合のHiRDBの動作を次に示します。

ユニットコントローラ用，又はグローバルバッファ用共用メモリの場合

ページ固定をしないで共用メモリを確保し処理を続行します。

動的変更したグローバルバッファが使用する共用メモリ，又はインメモリデータバッファ用共用メモリの場合

HiRDB，又はコマンドが異常終了します。

(d)　共用メモリ再利用機能

HiRDBでは，ユニットコントローラ用共用メモリと，グローバルバッファ用共用メモリをHiRDB開始時に確保します。これらの共用メモリの解放有無は共用メモリ再利用機能の適用有無で制御できます。

共用メモリ再利用機能を適用しない場合，HiRDB停止後にHiRDBを開始する際，前回稼働時に使用していた共用メモリを解放し，新たに共用メモリを確保します。共用メモリのページ固定を使用している場合は，メモリの断片化によって，物理メモリが確保できなくなり，HiRDBの開始に失敗したり，共用メモリのページ固定に失敗したりすることがあります。

共用メモリ再利用機能を適用する場合，HiRDB停止後にHiRDBを開始する際，前回稼働時に使用していた共用メモリを解放せずに再利用します。これによって，共用メモリ確保失敗によるHiRDBの開始失敗を防げます。

共用メモリ再利用機能は，次に示す共用メモリに適用できます。

ユニットコントローラ用共用メモリ

グローバルバッファ用共用メモリ

動的変更したグローバルバッファが使用する共用メモリ

共用メモリ再利用機能の適用方法

システム共通定義，又はユニット制御情報定義のpd_shm_reuseオペランドにYを指定します。

注意事項

共用メモリ再利用機能を適用すると，ユニットコントローラ用共用メモリ及びグローバルバッファ用共用メモリのサイズが大きくなります。「ユニットコントローラが使用する共用メモリの計算式」及び「グローバルバッファが使用する共用メモリの計算式」を参照して共用メモリ所要量を見積もってください。

共用メモリ再利用機能を適用すると，HiRDBが停止した状態でのメモリ使用量がグローバルバッファ用共用メモリのサイズ分多くなります。HiRDBが停止した状態でのメモリ使用量を削減する場合は，OSを再起動してください。

動的変更したグローバルバッファが使用する共用メモリは，前回稼働時に確保した共用メモリサイズと同一サイズになるようなグローバルバッファ定義を追加し，HiRDBを開始した場合に再利用します。

次に示すどちらかの運用をしてからHiRDBを開始すると，ユニットコントローラ用共用メモリとグローバルバッファ用共用メモリを解放し，再度確保します。その際，メモリ不足によってHiRDBの開始に失敗する場合や共用メモリのページ固定に失敗する場合もあります。この場合は，OSを再起動してください。

定義変更によって，ユニットコントローラ用共用メモリのサイズが変更になる。

HiRDBサービスを開始又は再起動する。

次に示すどれかの運用をしてからHiRDBを開始すると，グローバルバッファ用共用メモリを解放し，再度確保します。その際，メモリ不足によってHiRDBの開始に失敗する場合や共用メモリのページ固定に失敗する場合もあります。この場合は，OSを再起動してください。

SHMMAXオペランドの値を変更する。

サーバ名（pdstartオペランドの-sオプション指定値）を変更する。

影響分散スタンバイレス型系切り替え機能を適用したユニットのユニット名（pdunitオペランドの-uオプション指定値）を変更する。共用メモリのページ固定に失敗した場合，ページ固定していない共用メモリを再利用し続けることがあります。共用メモリ再利用機能を適用してもページ固定に失敗した場合は，OSを再起動し，KFPO00107-E(shmget(omminit(fixed)))又はKFPH23045-Wメッセージの対処を実施した後に共用メモリ再利用機能を適用してください。

9.1.2　HiRDB/パラレルサーバのシステム構成

HiRDB/パラレルサーバのシステム構成例を次の図に示します。

HiRDB/パラレルサーバのシステム構成は，HiRDBシステム定義で定義します。HiRDBシステム定義の定義例については，マニュアル「HiRDB システム定義」を参照してください。

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

[picture]

9.1.3　マルチフロントエンドサーバの設定

HiRDB/パラレルサーバでは複数のSQLを複数のバックエンドサーバを使用して並列に処理しています。フロントエンドサーバは，SQLの解析処理，SQLの最適化処理，各バックエンドサーバへ処理の指示や検索結果の編集処理などをしています。したがって，高トラフィックなシステムではフロントエンドサーバの負荷が高くなり，そのため処理性能が向上しなくなります。こういう場合は，フロントエンドサーバを複数設定して，フロントエンドサーバの負荷を分散させてください。これをマルチフロントエンドサーバといいます。

メリット

フロントエンドサーバが稼働するサーバマシンの処理能力ネックを解消し，スケーラブル性をより向上します。

適用基準

SQL処理のCPU負荷が高く，一つのサーバマシンだけで処理しきれない場合に適用します。

規則

フロントエンドサーバは最大1024個設定できます。

サーバマシンとの関係

一つのユニットに複数のフロントエンドサーバを設定できません。また，特定のユニットにフロントエンドサーバを設定しないこともできます。マルチフロントエンドサーバの構成例を次の図に示します。

図9‒2　マルチフロントエンドサーバの構成例

[picture]

(1)　接続するフロントエンドサーバの選択

複数あるフロントエンドサーバのうち，UAPがどのフロントエンドサーバに接続するかは，次に示すどちらかが決定します。

クライアントユーザ

接続するフロントエンドサーバをクライアント環境定義のPDFESHOSTオペランドなどで指定します。

HiRDB

接続するフロントエンドサーバをHiRDBが自動的に決定します。

接続するフロントエンドサーバをクライアント環境定義で指定しない場合，HiRDBが任意のフロントエンドサーバにUAPを接続させます。

(2)　環境設定

マルチフロントエンドサーバを実行するために，特に指定は必要ありません。

ただし，次に示すオペランドの指定値に注意してください。このオペランドの指定値の目安については，マニュアル「HiRDB システム定義」を参照してください。

pd_max_dic_process

pd_max_bes_process

(3)　HiRDB管理者の運用

HiRDBシステム定義のオペランドの指定やシステムファイルの作成個数などの環境設定方法は変わりますが，運用方法は変わりません。

(4)　マルチフロントエンドサーバ構成での，挿入又は更新時刻による並べ替え

マルチフロントエンドサーバ構成で，表定義時にCURRENT_TIMESTAMPを既定値とするDEFAULT句を指定した時刻印型の列を含む表を，行の挿入又は更新時刻で並べ替える場合，注意が必要です。

マルチフロントエンドサーバの場合，UAPと接続したフロントエンドサーバが現在の時刻印を取得し，その値を時刻印列の既定値として設定します。ただし，フロントエンドサーバがあるユニット間でシステムの時刻が異なることがあるため，時刻印列の値で並べ替えた順番と，実際に行を挿入又は更新した時刻で並べ替えた順番が一致しない場合があります。

順番を一致させるには，表定義時にCURRENT_TIMESTAMP USING BESを既定値とするDEFAULT句を時刻印列に指定します。USING BESを指定すると，その列に既定値を挿入又は既定値で更新時，挿入又は更新する行を格納するRDエリアを管理するバックエンドサーバで現在の時刻印を取得し，その値を挿入，又はその値で更新します。そのため，時刻印型の列で並べ替えた順番と，実際に行を挿入又は更新した時刻で並べ替えた順番は，行を格納するRDエリアを管理するバックエンドサーバがあるユニット単位で一致させることができます。

USING BESの指定有無と現在の時刻印を取得するサーバを次の表に示します。

表9‒2　USING BESの指定有無と現在の時刻印を取得するサーバ

USING BESの指定有無 | 現在の時刻印を取得するサーバ
なし | UAPと接続したフロントエンドサーバ
あり | 挿入，又は更新する行を格納するRDエリアを管理するバックエンドサーバ

注意事項

表を分割していて，表格納用RDエリアを管理するバックエンドサーバが複数のユニットにわたっている場合，時刻印型の列の値で並べ替えた順番と，実際に行を挿入又は更新した時刻で並べ替えた順番とが一致しないことがあります。

共用表の場合，排他モードで表に排他を掛けた後でないと，時刻印型の列に既定値を挿入したり，既定値で更新したりできません。

データベース作成ユティリティ（pdload）を使用して表にデータを格納する場合，起動したユニットでユティリティを起動した時刻印が設定されます。

(5)　クライアントユーザの運用

接続するフロントエンドサーバをクライアントユーザが決める場合は，接続するフロントエンドサーバをクライアント環境定義で指定します。高速接続機能を使用する場合とFESホストダイレクト接続機能を使用する場合とで指定するクライアント環境定義が異なります。指定する必要があるクライアント環境定義を次の表に示します。クライアント環境定義については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

表9‒3　マルチフロントエンドサーバ時に指定するクライアント環境定義

クライアント環境定義 のオペランド | 接続する フロントエンドサーバ を指定しない場合 | 接続するフロントエンドサーバ を指定する場合
FESホスト ダイレクト接続 | 高速接続
PDHOST | ○ | ○ | ○
PDFESHOST | − | ○ | ○
PDNAMEPORT | ○ | ○ | ○
PDSERVICEPORT | − | − | ○
PDSERVICEGRP | − | ○ | ○
PDSRVTYPE | − | − | ○

（凡例）

○：必ず指定します。

−：指定する必要はありません。

(a)　どのフロントエンドサーバを指定するかの目安

アクセスするRDエリアを管理するバックエンドサーバがあるサーバマシンのフロントエンドサーバを指定することをお勧めします。

用途に応じて接続するフロントエンドサーバを使い分けることをお勧めします。例えば，一般の情報検索処理用，バッチUAP処理用，OLTP下のUAP処理用などにフロントエンドサーバを使い分けることをお勧めします。

(b)　HiRDBサーバへの接続時間

HiRDBサーバへの接続時間は，次に示す順番どおりに短縮されます（1が最も短縮されます）。

高速接続機能

FESホストダイレクト接続機能

接続するフロントエンドサーバを指定しない場合

9.1.4　回復不要FES

フロントエンドサーバがあるユニットで障害が発生して異常終了すると，そのフロントエンドサーバから実行していたトランザクションは未決着状態になることがあります。未決着状態のトランザクションは，データベースの排他を確保しているため，一部のデータベースに対する参照又は更新が制限されます。通常，未決着状態のトランザクションの決着処理をするためには，フロントエンドサーバの障害を取り除いて再開始する必要がありますが，異常終了したフロントエンドサーバが回復不要FESであれば，HiRDBが自動的に未決着状態になっていたトランザクションを決着します。これによって，ほかのフロントエンドサーバやバックエンドサーバを使用して，データベースの更新を再開できます。回復不要FESがあるユニットを回復不要FESユニットといいます。回復不要FESを使用する場合としない場合の運用を次の図に示します。

図9‒3　回復不要FESを使用する場合としない場合の運用

[picture]

なお，回復不要FESを使用するためには，HiRDB Non Recover FESが必要です。

メリット

障害が発生したフロントエンドサーバを再開始しないで，残りのフロントエンドサーバでオンライン運用を続行できます。

適用基準

24時間連続稼働が必要なシステムの場合に適用をお勧めします。

ほかのフロントエンドサーバとの関係

回復不要FESは，単独で構成されるユニットに配置してください。

回復不要FESでは，X/Open XAインタフェースを使用して接続するUAPは実行できません。クライアント環境定義のPDFESHOST及びPDSERVICEGRPを指定して，回復不要FES以外のフロントエンドサーバに接続してください。

回復不要FES，及び回復不要FESユニットが停止していても，pdrplstartコマンド，及びpdrplstopコマンドは実行できます。

回復不要FESを使用したシステムの構成例を次の図に示します。

図9‒4　回復不要FESを使用したシステムの構成例

[picture]

回復不要FESでは，反映側Datareplicatorの同期点処理方式に二相コミット方式を利用（反映システム定義commitment_methodオペランドにfxa_sqleを指定）した反映処理を実行できません。反映側Datareplicatorの同期点処理方式に二相コミット方式を利用する場合，反映側HiRDBに回復不要FES以外のフロントエンドサーバを一つ以上配置し，反映側Datareplicatorにクライアント環境変数PDFESHOST及びPDSERVICEGRPを設定して，回復不要FES以外のフロントエンドサーバに接続してください。

ほかの機能との関連

回復不要FESユニットでは，系切り替え機能を適用できません。系切り替え機能を適用するシステムの場合，回復不要FESユニットのユニット制御情報定義のpd_ha_unitオペランドに必ずnouseを指定してください。

(1)　設定方法

回復不要FESを使用するには，pdstartオペランドの-kオプションにstlsを指定します。

(2)　注意事項

HiRDBを起動する場合に回復不要FESユニットが開始しないとき，HiRDBはpd_start_levelオペランドの指定値に関係なく，そのユニットを除いてHiRDBを開始します。すべてのフロントエンドサーバを回復不要FESにする場合，一つ以上のフロントエンドサーバが開始しないとHiRDBシステムの起動は完了しません。

回復不要FESユニットは独自に縮退起動をするため，pd_start_skip_unitオペランドに回復不要FESユニットの名称を指定しても無視します。

回復不要FESユニットが異常終了した場合，フロントエンドサーバ及びユニットのステータス情報はSTOP(A)になりますが，通常のSTOP(A)とは異なり，pdstopコマンドでHiRDBのシステムマネジャとほかのユニットを正常停止，又は計画停止できます。また，回復不要FESユニットを強制停止した場合，フロントエンドサーバ及びユニットのステータス情報はSTOP(F)になりますが，pdstopコマンドでHiRDBのシステムマネジャとほかのユニットを正常停止，又は計画停止できます。

回復不要FESユニットは，次の場合以外，常に正常開始でユニットを開始します。

ユニットを正常終了以外で停止していて，かつ前回稼働時にpdstartオペランドの-kオプションにstlsを指定していなかった場合

回復不要FESユニットのステータス情報がSTOP(A)になっていると，その回復不要FESにCONNECTしたUAPからのSQL要求をHiRDBが受け付けなくなります。この場合，KFPS01820-Eメッセージに表示される回復不要FESのプロセス終了状態は「c800」になります。また，SQLで操作しようとしたデータを持つバックエンドサーバやディクショナリサーバなどのサーバプロセスの終了状態は，KFPS01820-Eメッセージに「c900」と表示されることがあります。KFPS01820-Eメッセージが表示された場合，プロセス終了状態が「c800」と表示されたフロントエンドサーバがあるユニットをpdstop -zで停止し，STOP(A)になった原因を対策してから再度開始してください。

回復不要FESユニットが稼働しているのに，ネットワーク障害などでそのユニットのステータス情報がSTOP(A)になった場合，障害が回復してシステムマネジャからそのユニットに通信できるようになると，システムマネジャがそのユニットを自動的に強制停止してから再度開始します。自動的に強制停止してから再度開始する契機を次に示します。

ユニットの稼働状況を監視するユニット監視プロセスが，ステータス情報がSTOP(A)となった回復不要FESユニットが稼働中であることを確認し，KFPS05288-Iメッセージが出力されたとき

システムマネジャがあるユニットが再度開始する際に全ユニットの稼働状況を確認し，ステータス情報がSTOP(A)となった回復不要FESユニットが稼働中であることを確認したとき

自動的に強制停止してから再度開始する処理が行われた場合，回復不要FESユニットでKFPS05110-Iメッセージが出力されていることを確認してください。このメッセージが出力されていれば，回復不要FESユニットの起動処理が正常に終了しています。自動的に強制停止し，再度開始する契機が発生してから，システム共通定義のpd_system_complete_wait_timeオペランドに指定した時間が経過してもKFPS05110-Iメッセージが出力されない場合，起動処理が正常に終了していません。この場合の対処方法を次に示します。

（1）システムマネジャがあるユニット，及びディクショナリサーバがあるユニットの稼働状態をpdls -d ustコマンドで確認します。

それらのユニットが稼働していない場合，pdstartコマンドで開始します。

それらのユニットが稼働している場合，又はそれらのユニットを開始してもKFPS05110-Iメッセージが出力されない場合，（2）の対処をします。

（2）回復不要FESユニットの稼働状態をpdls -d ustコマンドで確認し，実行結果に応じて，次に示す対処をします。

回復不要FESユニットの稼働状態（pdls -d ustコマンドの実行結果） | 対処方法
STOP（停止状態） | pdstart -qコマンドを実行して，回復不要FESユニットを再開始してください。
PAUSE（プロセスサーバプロセスの再起動中断状態） | KFPS00715-Eメッセージ，及びそれ以前にイベントログに出力されたメッセージを参照して，障害要因を取り除いた後，HiRDBのサービスを再起動してください。 pdstart -qコマンドを実行して，回復不要FESユニットを再開始してください。
STARTING（開始途中） | pdstop -zコマンドを実行して，回復不要FESユニットを強制終了してください。 pdstart -qコマンドを実行して，回復不要FESユニットを再開始してください。
ONLINE（稼働状態）
STOPPING（停止途中）

なお，システムマネジャからそのユニットに通信できるようになる前にユニットが停止した場合は，システムマネジャは強制停止及び再度開始をしません。

回復不要FESから分岐して，ほかのサーバで実行しているトランザクションは，コミット決着時に分岐先のサーバ間で決着の同期合わせを行います。このため，同期合わせのときに，分岐先サーバのどれかがトランザクション処理を実行できない状態（系切り替え中，サーバ停止状態，サーバ開始準備中，又はサーバ停止準備中）になっていると，トランザクション第1状態がREADY又はCOMMITで待ち合わせを行うことがあります。この場合，トランザクション処理を実行できない状態になっている原因を該当するサーバで対策して，トランザクションの決着処理が続行できるようにしてください。

回復不要FES機能を使用するFESに接続して実行したトランザクションは，トランザクション第1状態，第2状態に関係なく，pdcmt，pdrbk，pdfgtコマンドを使用してトランザクションを強制的に終了できないことがあります。この場合，マニュアル「HiRDB システム運用ガイド」の「未決着状態のトランザクションを決着する方法」を参照してトランザクションを自動決着させてください。

9.2　HiRDBファイルシステム領域の設計

HiRDBのシステム構築時に，HiRDBファイルを作成するHiRDBファイルシステム領域を作成します。ここでは，HiRDBファイルシステム領域を作成するときの設計方針について説明します。

HiRDBファイルシステム領域は，次に示す用途ごとに作成することをお勧めします。これによって，用途やアクセス特性の異なるファイルへの入出力が競合することを回避できます。

RDエリア用

共用RDエリア用

システムファイル用

作業表用ファイル用

ユティリティ用

リスト用RDエリア用

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

RDエリア用のHiRDBファイルシステム領域の設計方針について説明します。

(1)　信頼性向上のための方針

RDエリア用のHiRDBファイルシステム領域は，次に示すサーバを定義するサーバマシンに作成します。

ディクショナリサーバ

バックエンドサーバ

次に示すRDエリアを作成するHiRDBファイルシステム領域は，ディクショナリサーバを定義するサーバマシンに作成します。

システム用RDエリア

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

レジストリ用RDエリア

レジストリLOB用RDエリア

次に示すRDエリアを作成するHiRDBファイルシステム領域は，バックエンドサーバを定義するサーバマシンに作成します。

ユーザ用RDエリア

ユーザLOB用RDエリア

(2)　性能向上のための方針

RDエリアを作成するHiRDBファイルシステム領域は，次に示すRDエリア用ごとに作成することをお勧めします。

システム用RDエリア

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

ユーザ用RDエリア

ユーザLOB用RDエリア

レジストリ用RDエリア

レジストリLOB用RDエリア

システムファイル用のHiRDBファイルシステム領域と，RDエリア用のHiRDBファイルシステム領域は，別々のハードディスクに作成することをお勧めします。これによって，シンクポイントダンプを取得するときに入出力の分散ができ，シンクポイントダンプの取得処理時間を短縮できます。

9.2.2　システムファイル用のHiRDBファイルシステム領域の設計

システムファイル用のHiRDBファイルシステム領域の設計方針について説明します。

(1)　信頼性向上のための方針

システムファイル用のHiRDBファイルシステム領域は二つ以上作成してください。一つしか作成しないと，システムファイルがあるハードディスクに障害が発生した場合，HiRDBが稼働できなくなります。

システムファイル用のHiRDBファイルシステム領域は別々のハードディスクに作成してください。そうすれば，どちらかのハードディスクに障害が発生しても，HiRDBを再開始できます。

(2)　性能向上のための方針

システムファイル用のHiRDBファイルシステム領域と，RDエリア用のHiRDBファイルシステム領域は，別々のハードディスクに作成することをお勧めします。これによって，シンクポイントダンプを取得するときに入出力の分散ができ，シンクポイントダンプの取得処理時間を短縮できます。

9.2.3　作業表用ファイル用のHiRDBファイルシステム領域の設計

作業表用ファイル用のHiRDBファイルシステム領域の設計方針について説明します。

(1)　設計方針

作業表用ファイル用のHiRDBファイルシステム領域長は，そのHiRDBファイルシステム領域に作成する作業表用ファイルの総容量より大きくしてください。なお，pdfmkfsコマンドで-aオプションを指定すると，HiRDBファイルシステム領域を自動的に拡張できます。作業表用ファイルの総容量がHiRDBファイルシステム領域長に達した場合，自動でHiRDBファイルシステム領域を拡張できるため，-aオプションを指定することをお勧めします。※

作業表用ファイルの容量については，「作業表用ファイルの容量の見積もり」を参照してください。

作業表用ファイル用のHiRDBファイルシステム領域は，次に示すサーバを定義するサーバマシンに作成してください。

ディクショナリサーバ

バックエンドサーバ

注※

HiRDB再開始時に作業表用ファイル用のHiRDBファイルシステム領域のディスク占有サイズを削減したい場合は，HiRDB再開始前にpdfmkfsコマンドを実行して作業表用ファイル用のHiRDBファイルシステム領域を再初期化してください。

(2)　最大使用量を調べる方法

作業表用ファイル用のHiRDBファイルシステム領域の最大使用量を次に示す方法で調べられます。

pdfstatfs　-d　作業表用のHiRDBファイルシステム領域名

-d：

HiRDBファイルシステム領域の最大使用量を表示するオプションです。出力情報のpeak capacityが最大使用量です。なお，上記の最大使用量はpdfstatfsコマンドでクリアできます。

pdfstatfs　-c　作業表用のHiRDBファイルシステム領域名

-c：

HiRDBファイルシステム領域の最大使用量をクリアするオプションです。

9.2.4　ユティリティ用のHiRDBファイルシステム領域の設計

ユティリティ用（バックアップファイル，アンロードデータファイル，又はアンロードログファイル作成用）のHiRDBファイルシステム領域の設計方針について説明します。ユティリティ用のHiRDBファイルシステム領域には，次に示すファイルを作成します。

バックアップファイル

アンロードデータファイル

アンロードログファイル

差分バックアップ管理ファイル

(1)　設計方針

バックアップファイル作成用にする場合は，HiRDBファイルシステム領域長をバックアップ対象RDエリアの総容量より大きくしてください。RDエリアの容量については，「RDエリアの容量の見積もり」を参照してください。

差分バックアップ管理ファイル作成用のHiRDBファイルシステム領域は，システムマネジャがあるサーバマシンに作成してください。

アンロードログファイル作成用にする場合は，pdfmkfsコマンドのオプションに次に示す値を指定してください。

-kオプション：使用目的にはUTL（ユティリティ用のHiRDBファイルシステム領域）を指定します。

-nオプション：HiRDBファイルシステム領域長には次に示す計算式の値を指定します。

（アンロードするシステムログファイルの総レコード数※１×システムログファイルのレコード長）※２×作成するアンロードログファイル数×1.2÷1048576

-lオプション：最大ファイル数には，作成するアンロードログファイル数を指定します。

-eオプション：最大増分回数には，作成するアンロードログファイル数×23を指定します。

注※1

システムログファイルの自動拡張機能を適用している場合，pd_log_auto_expand_sizeオペランドの拡張上限サイズに指定した値で計算してください。

注※2

システムログファイルの概算値です。

(2)　最大使用量を調べる方法

ユティリティ用のHiRDBファイルシステム領域の最大使用量を次に示す方法で調べられます。

pdfstatfs　-d　ユティリティ用のHiRDBファイルシステム領域名

-d：

HiRDBファイルシステム領域の最大使用量を表示するオプションです。出力情報のpeak capacityが最大使用量です。なお，上記の最大使用量はpdfstatfsコマンドでクリアできます。

pdfstatfs　-c　ユティリティ用のHiRDBファイルシステム領域名

-c：

HiRDBファイルシステム領域の最大使用量をクリアするオプションです。

9.2.5　リスト用RDエリア用のHiRDBファイルシステム領域の設計

リスト用RDエリア用のHiRDBファイルシステム領域の設計方針について説明します。

(1)　設計方針

リストは検索の一時的な中間結果を保存するものなので，ほかのRDエリアほど信頼性は要求されません。

リスト用RDエリア用のHiRDBファイルシステム領域は，基表と同じバックエンドサーバに作成してください。

(2)　性能向上のための方針

リスト用RDエリア用のHiRDBファイルシステム領域は，次に示すHiRDBファイルシステム領域とは別々のハードディスクに作成することをお勧めします。別々のハードディスクに作成すると，リストを検索するときに入出力を分散できるため，処理時間を短縮できます。

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

ユーザLOB用RDエリア用のHiRDBファイルシステム領域

作業表用ファイル用のHiRDBファイルシステム領域

9.2.6　HiRDBファイルシステム領域の最大長

HiRDBファイルシステム領域の最大長は，1,048,575メガバイトです。

9.2.7　系切り替え機能使用時の注意事項

系切り替え機能で使用するHiRDBファイルシステム領域を作成する場合の注意事項を次に示します。

pdfmkfsコマンドの-iオプションを指定してください。-iオプションを指定しないと，HiRDBファイルシステム領域の拡張とサーバマシンの電源異常が同時に発生した場合にファイルが破壊されることがあります。

pdfmkfsコマンドの-kオプションにSVR（省略値）を指定しないでください。-kオプションにSVRを指定して作成したHiRDBファイルシステム領域に対して，HiRDBはWindowsのファイルキャッシュに書き込んだ時点で処理を続行します。このため，ディスク上にデータが書き込まれる前に異常が発生するとファイルの整合性がとれなくなります。

9.3　システムファイルの設計

ここでは，システムファイルの設計方針について説明します。

9.3.1　システムログファイルの設計

システムログファイルの設計方針について説明します。

(1)　設計方針

システムログファイルはシステムマネジャを除いた各サーバに必要です。

サーバ内の全システムログファイルのレコード長及びレコード数を同じにしてください。

各サーバに作成できるシステムログファイルは，2〜200グループです（ただし，6グループ以上作成することを推奨します）。

一つのサーバに対して，次の式を満たすようにシステムログファイルを作成します。

100（単位：ギガバイト）×（200−サーバに割り当てるシステムログファイルグループ数）≧サーバに割り当てるシステムログファイルの総容量×3

これは，システムログファイルの容量不足によって異常終了したHiRDBを再開始する場合に必要になります。システムログファイルが容量不足になった状況や運用によっては，サーバに割り当てられている3倍の容量のシステムログファイルを作成し，サーバに追加して対処する必要があるためです。

アンロードする回数を少なくしたい場合は，システムログファイルの1ファイル容量を大きくします。

HiRDB運用ディレクトリがあるディスクに大量に入出力が発生するファイル（システムログのアンロードログファイルなど）を作成しないでください。

全システムログファイルの容量（二重化している場合は片系の容量だけを対象とする）は，次に示す二つの条件を満たす必要があります。

条件1

「システムログファイルの総容量の求め方」で見積もった容量以上の値にしてください。

条件2

長大トランザクションが終了するまでは，長大トランザクション開始以降のシステムログファイルの上書きができません。また，シンクポイントダンプファイルの有効保証世代とカレント世代のシステムログファイルは上書きできません。そのため，これらの分のシステムログファイル容量を確保してください。次の計算式で求めます。

全システムログファイルの総容量（バイト）≧3×a×（b＋1）

a：

データベースを更新するトランザクションのうち，実行時間が最大のトランザクション実行中に該当するサーバで出力されることのあるシステムログ量

システムログ量の見積もり式については，「システムログファイルの容量の見積もり」を参照してください。

ｂ：pd_spd_assurance_countオペランドの値

シンクポイントダンプファイルの有効保証世代数です。

(a)　システムログファイルの世代数と運用への影響

システムログファイルの総容量が同じ場合，システムログファイルの世代数によって，1世代当たりの容量が変化します。システムログファイルの世代数と運用への影響を次の表に示します。システムログファイルの総容量は同じとします。

表9‒4　システムログファイルの世代数と運用への影響

比較項目 | システムログファイルの構成
世代数を少なくした場合 | 世代数を多くした場合
システムログファイル1世代当たりの容量 | 大きくなります。 | 小さくなります。
スワップ間隔 | システムログファイル1世代当たりの容量が大きくなるため，スワップ間隔は長くなります。 | システムログファイル1世代当たりの容量が小さくなるため，スワップ間隔は短くなります。
アンロード回数 | スワップ間隔が長くなるため，アンロード回数は少なくなります。 | スワップ間隔が短くなるため，アンロード回数は多くなります。
ディスク障害などでシステムログファイルの数世代が使用できなくなった場合のシステムログ容量への影響 | システムログファイル1世代当たりの容量が大きくなるため，ディスク障害時にデータベースの回復に用いるログ量は多くなり，データベース回復に掛かる時間は長くなります。 システムログ容量の減少幅が大きいため，システムログの容量が減少したことによるHiRDBの稼働に及ぼす影響は大きくなります。 | システムログファイル1世代当たりの容量が小さくなるため，ディスク障害時にデータベースの回復に用いるログ量は少なくなり，データベース回復に掛かる時間は短くなります。 システムログ容量の減少幅が小さいため，システムログの容量が減少したことによるHiRDBの稼働に及ぼす影響は小さくなります。

通常の運用では，システムログファイルの世代数を少なくした場合の方がスワップ間隔及びアンロード回数の点で利点があります。ただし，障害発生時には，世代数を多くした場合の方が障害の影響が小さくなります。

(2)　信頼性向上のための方針

(a)　システムログファイルの二重化

システムログファイルを二重化すると，HiRDBは両方の系に同じシステムログを取得します。取得したシステムログを読み込むとき，片方のファイルに異常が発生しても，もう一方のファイルからシステムログを読み込めるため，システムの信頼性を向上できます。なお，二重化する場合，ディスクをミラー化して二重化するより，HiRDB管理下で二重化することをお勧めします。システムログファイルを二重化する場合は，それぞれの系のファイルを別々のハードディスクに作成してください。

システムログファイルを二重化する場合は，サーバ定義で次に示すオペランドを指定してください。

pd_log_dual = Y

pdlogadpfオペランドの-bオプション（B系のシステムログファイル名を指定します）

(b)　システムログファイルの片系運転

システムログファイルの片系運転は，システムログファイルを二重化する場合に適用されます。

システムログファイルに障害が発生して，両系とも使用できるシステムログファイルがない場合でも，HiRDBのユニットを異常終了しないで正常な系だけで処理を続行できます。これをシステムログファイルの片系運転といいます。システムログファイルの片系運転をする場合は，サーバ定義でpd_log_singleoperation = Yを指定してください。

システムログファイルの片系運転に対し，両方のシステムログファイルで処理を続行すること（通常の処理形態）をシステムログファイルの両系運転といいます。

(c)　システムログファイルの自動オープン

HiRDBを再開始するときに，上書きできる状態のシステムログファイルがない場合，予約のファイルがあればHiRDBが予約のファイルをオープンして上書きできる状態にし，処理を続行します。これをシステムログファイルの自動オープンといいます。

システムログファイルの自動オープンをする場合は，サーバ定義でpd_log_rerun_reserved_file_open = Yを指定してください。

(3)　可用性向上のための方針

(a)　システムログファイルの空き容量監視機能

システムログファイルのスワップ時に，スワップ先にできる状態のシステムログファイルがないとHiRDB（ユニット）は異常終了します。これを予防するため，HiRDBにはシステムログファイルの空き容量を監視する機能（システムログファイルの空き容量監視機能）があります。この機能は，システムログファイルの空き率が警告値未満になったときに作動します。次に示す二つのレベルのどちらかを選択できます。

レベル1：

システムログファイルの空き率が警告値未満になった場合，警告メッセージKFPS01162-Wを出力します。

レベル2：

システムログファイルの空き率が警告値未満になった場合，新規トランザクションのスケジューリングを抑止して，サーバ内の全トランザクションを強制終了します。このとき，KFPS01160-Eメッセージを出力します。これによって，システムログの出力量を抑えます。

レベル2を選択した場合，システムログファイルの空き容量が不足したときにサーバ内の全トランザクションが強制終了されます。このため，システムログファイルの設計をより正確に行う必要があります。

システムログファイルの空き容量監視機能については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(b)　システムログファイルの自動拡張機能

システムログファイルの容量不足が発生すると，HiRDBシステム（又はユニット）が異常終了します。これを回避するため，自動的にシステムログファイルの容量を拡張する機能（システムログファイルの自動拡張機能）を提供しています。この機能を適用することで，システムログファイルの容量不足によるHiRDBシステム（又はユニット）の異常終了の頻度を低減できます。

システムログファイルの自動拡張機能については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(c)　シンクポイントダンプ有効化のスキップ回数監視機能

UAPが無限ループしてデータベースを更新し続けるとシンクポイントが有効化できないため，上書きできない状態のシステムログファイルが増えてしまいます。上書きできない状態のシステムログファイルが増えて全システムログファイルが上書きできない状態になると，HiRDBが異常終了します。

また，上書きできない状態のシステムログファイルが，全システムログファイルの1/3以上になったときにHiRDBが異常終了又は強制終了すると，HiRDBを再開始するときのロールバック処理でシステムログファイルが不足する場合があります。この場合，システムログファイルを新規追加しないと，HiRDBを再開始できません。そして，この再開始処理に要する時間も長くなります。

このようなことを防ぐために，HiRDBではシンクポイントダンプ有効化のスキップ回数監視機能を設けています。

シンクポイントダンプ有効化のスキップ回数監視機能については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(4)　システムログファイルのレコード長（既にHiRDBを稼働している場合）

レコード長が1024以外の場合，システムログの格納効率を良くするために1024に変更することをお勧めします。

システムログファイルのレコード長の変更方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

(5)　システムログファイルの定義

作成したシステムログファイルをどのファイルグループに対応させるかをサーバ定義のpdlogadfg及びpdlogadpfオペランドで定義します。

9.3.2　シンクポイントダンプファイルの設計

シンクポイントダンプファイルの設計方針について説明します。

(1)　設計方針

シンクポイントダンプファイルはシステムマネジャを除いた各サーバに必要です。

各サーバに作成できるシンクポイントダンプファイルは，2〜60グループです。pdlogadfg -d spdオペランドにONLを指定した場合は，2〜30グループです。

HiRDBはpdlogadfg -d spdオペランドの指定順にシンクポイントダンプファイルを使用します。

各サーバに4個以上のシンクポイントダンプファイルを作成することをお勧めします。

シンクポイントダンプファイルの容量が不足すると，HiRDBを開始できません。このため，シンクポイントダンプファイルのレコード数は，システム共通定義の最大同時接続数（pd_max_usersオペランド）の指定値より大きな値にしてください。詳細なシンクポイントダンプファイルの容量計算式については，「シンクポイントダンプファイルの容量の見積もり」を参照してください。

シンクポイントダンプファイルを二重化する場合は，有効保証世代数は1をお勧めします。二重化しない場合は，有効保証世代数に2を設定することをお勧めします。有効保証世代数に2を設定する場合は，システムログファイル不足によるHiRDB異常終了が発生しないようにシステムログファイルの容量を考慮してください。

(2)　信頼性向上のための方針

(a)　ファイル構成例

ハードディスク障害に備えて，シンクポイントダンプファイルをそれぞれ別々のハードディスクに作成してください。そのような構成を取れない場合は，隣り合わせの世代を別々のハードディスクに作成するような構成にしてください。例を次の図に示します。

図9‒5　隣り合わせの世代を別々のハードディスクに作成する構成例

[picture]

(b)　シンクポイントダンプファイルの二重化

シンクポイントダンプファイルを二重化すると，HiRDBはＡ系及びＢ系の両方に同じシンクポイントダンプを取得します。取得したシンクポイントダンプを読み込むとき，片方のファイルに異常が発生しても，もう一方のファイルからシンクポイントダンプを読み込めるため，システムの信頼性を向上できます。また，二重化している場合，有効保証世代数を1世代にすると，信頼性を損ねることなく上書きできない状態のシンクポイントダンプファイル数を削減できます。

シンクポイントダンプファイルを二重化する場合は，サーバ定義で次に示すオペランドを指定してください。

pd_spd_dual = Y

pdlogadpfオペランドの-bオプション（B系のシステムログファイル名を指定します）

(c)　シンクポイントダンプファイルの片系運転

シンクポイントダンプファイルの片系運転は，シンクポイントダンプファイルを二重化する場合に適用されます。シンクポイントダンプファイルは，片方のファイルに異常が発生しても，正常な系だけで処理を続行します。これをシンクポイントダンプファイルの片系運転といいます。

(d)　シンクポイントダンプファイルの有効保証世代数

一つのシンクポイントダンプファイルには，HiRDBが1回に取得するシンクポイントダンプが格納されます。HiRDBは，シンクポイントダンプファイルを世代という概念で管理しています。HiRDB管理者は，何世代前までのシンクポイントダンプファイルに対応するシステムログファイルを上書きできない状態にするかを指定できます。これをシンクポイントダンプファイルの有効保証世代数といいます。シンクポイントダンプファイルの有効保証世代数を次の図に示します。

図9‒6　シンクポイントダンプファイルの有効保証世代数

[picture]

〔説明〕

有効保証世代を2とすると，2世代前までのシンクポイントダンプファイル及びそのシンクポイントダンプファイルに対応するシステムログファイルが，上書きできない状態になります。3世代前より前の世代のシンクポイントダンプファイル及びそのシンクポイントダンプファイルに対応するシステムログファイルは，上書きできる状態になります。

シンクポイントダンプファイルの運用に必要なファイル数は，有効保証世代数＋1となります。シンクポイントダンプファイルの有効保証世代数は，サーバ定義のpd_spd_assurance_countオペランドで指定してください。

なお，シンクポイントダンプファイルを二重化している場合，必要な有効保証世代数は1世代をお勧めします。二重化していない場合，2世代をお勧めします。

(e)　シンクポイントダンプファイルの縮退運転

シンクポイントダンプファイルに障害が発生して，使用できるシンクポイントダンプファイル数が運用に必要なファイル数（有効保証世代数＋1）未満になった場合でも，最低二つのファイルで処理を続行できます。これをシンクポイントダンプファイルの縮退運転といいます。

シンクポイントダンプファイルの縮退運転をする場合は，サーバ定義のpd_spd_reduced_modeオペランドを指定してください。

(f)　シンクポイントダンプファイルの自動オープン

シンクポイントダンプファイルに障害が発生して，使用できるシンクポイントダンプファイル数が運用に必要なファイル数（有効保証世代数＋1）未満になった場合，予約のファイルがあればHiRDBが予約のファイルをオープンして上書きできる状態にし，処理を続行します。これをシンクポイントダンプファイルの自動オープンといいます。

シンクポイントダンプの自動オープンをする場合は，サーバ定義でpd_spd_reserved_file_auto_open = Yを指定してください。

(3)　シンクポイントダンプファイルの定義

作成したシンクポイントダンプファイルをどのファイルグループに対応させるかをpdlogadfg及びpdlogadpfオペランドで定義します。

なお，pdlogadfgオペランドだけを指定しておくと，HiRDB稼働中にシンクポイントダンプファイルを追加できます。

9.3.3　ステータスファイルの設計

ステータスファイルの設計方針について説明します。

(1)　設計方針

両系のファイルに障害が起きないように，A系とB系のファイルは別々のディスクに作成します。

ステータスファイルの容量不足によるHiRDBの異常終了を防ぐため，見積もったファイル容量よりも大きい容量の予備ファイルを幾つか作成してください。ステータスファイルは，容量が満杯になると予備ファイルとスワップしますが，満杯になったステータスファイルと予備ファイルの容量が同じ場合，スワップ先のファイルでも容量不足になり，HiRDBは異常終了します。そのため，例えばステータスファイルを6組作成する場合，そのうちの2組以上のファイル容量をほかのファイル容量より大きくすることをお勧めします。

各サーバマシンにユニット用ステータスファイルが必要です。

システムマネジャを除いた各サーバにサーバ用ステータスファイルが必要です。

A系とB系のファイルのレコード長及びレコード数を同じにしてください。

一つのユニットに作成できるユニット用ステータスファイルは1〜7組です。

一つのサーバに作成できるサーバ用ステータスファイルは1〜7組です。

(2)　信頼性向上のための方針

ステータスファイルは3組（二重化×3=6ファイル）以上用意し，ディスク障害によってすべてのステータスファイルが障害とならないように配置します。

容量不足によるHiRDBの異常終了を防ぐため，ステータスファイルの容量は見積もった容量の1.2倍以上の容量を準備することをお勧めします。

ステータスファイルには，HiRDBの再開始処理でシステムの状態を回復するために必要な情報を格納しています。予備ファイルがない状態で現用ファイルに障害が発生すると，システムの状態が回復できません。したがって，常に予備ファイルがあるように運用し，現用ファイルの障害に備えてください。

(a)　お勧めする構成

ディスク障害発生時から回復時までの安全性を考えると，ステータスファイルは四つのディスクに6組（二重化×6=12ファイル）用意し，次の図のように配置することをお勧めします。また，片系運転中に正常な系に障害が発生すると，HiRDBを再開始できなくなるため，ステータスファイルの片系運転は適用しない（pd_syssts_singleoperation及びpd_sts_singleoperationにstopを指定）ことをお勧めします。

四つのディスクにステータスファイルを6組配置する例を次の図に示します。

図9‒7　四つのディスクに6組のステータスファイルを配置する例

[picture]

〔説明〕

このように配置すると，あるディスクで障害が発生した後に，更に別のディスクで障害が発生しても，残りの二つのディスクに両系とも正常なファイルが残るため，障害が発生していないディスクのステータスファイルを現用としてHiRDBを稼働し続けることができます。例えば，ディスクAに障害が発生し，その後ディスクBにも障害が発生した場合でも，ディスクC及びDにある両系のステータスファイル（sts-3aとsts-3b）を現用ファイルとして稼働し続けます。この状態で，更に現用ファイルの片系に障害が発生した場合，HiRDBは異常終了しますが，現用ファイルの片系ファイルが正常のため，障害が発生したディスクのどれか一つを回復するとHiRDBを再開始できます。

(3)　ステータスファイルの定義

pdstsinitコマンドで作成したステータスファイルをどの論理ファイルに対応させるかをpd_syssts_file_name_1〜7及びpd_sts_file_name_1〜7オペランドで定義します。

ユニット用ステータスファイルは，pd_syssts_file_name_1〜7オペランドで定義します。サーバ用ステータスファイルは，pd_sts_file_name_1〜7オペランドで定義します。

なお，pd_syssts_file_name_2〜7オペランド又はpd_sts_file_name_2〜7オペランドに，実体のないステータスファイルを定義しておくと，HiRDB稼働中にステータスファイルを追加できます。ただし，この場合，次に示すオペランドを指定しておく必要があります。

ユニット用ステータスファイルの場合

pd_syssts_initial_error

pd_syssts_last_active_file

サーバ用ステータスファイルの場合

pd_sts_initial_error

pd_sts_last_active_file

(4)　ステータスファイルの片系運転

予備ファイルがない状況で現用ファイルの片系に障害が発生した場合，正常な系（片方の系）だけで処理を続行することをステータスファイルの片系運転といいます。ステータスファイルが片系運転になると，KFPS01044-Iメッセージが出力されます。

片系運転中に現用ファイルに障害が発生すると，HiRDBを再開始できなくなるため，ステータスファイルの片系運転の適用は推奨しません。ステータスファイルの組数を増やし，予備ファイルがない状況が発生しないような運用をしてください。

なお，ステータスファイルの片系運転に対し，両方の系のステータスファイルで処理を続行すること（通常の処理形態）をステータスファイルの両系運転といいます。

(a)　ステータスファイルの片系運転適用のメリット及びデメリット

メリット

予備ファイルがない状況で現用ファイルの片系に障害が発生しても，処理を続行できます。このため，ステータスファイルの障害によってHiRDBが停止する可能性が低くなります。

デメリット

片系運転中に正常な系に障害が発生したり，又はステータスファイルの更新中にHiRDBが異常終了したりすると，現用ファイルの内容が失われるため，HiRDBを再開始できなくなります。

(b)　指定方法

ユニット用ステータスファイルの片系運転をする場合は，ユニット制御情報定義でpd_syssts_singleoperation = continueを指定してください。サーバ用ステータスファイルの片系運転をする場合は，サーバ定義でpd_sts_singleoperation = continueを指定してください。なお，pd_syssts_singleoperationとpd_sts_singleoperationの指定値を同じにしてください。

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

pd_syssts_singleoperation及びpd_syssts_initial_errorオペランド，又はpd_sts_singleoperation及びpd_sts_initial_errorオペランドの指定値の組み合わせによって，HiRDBの起動時にステータスファイルの障害を検知した場合のHiRDBの動作が決定します。したがって，これら二つのオペランドの指定値は一緒に考えるようにしてください。HiRDBの起動時にステータスファイルの障害を検知した場合のHiRDBの動作については，マニュアル「HiRDB システム定義」の，pd_syssts_initial_error又はpd_sts_initial_errorオペランドの説明を参照してください。

(c)　適用の目安

ステータスファイルの片系運転の適用の目安を次に示します。

HiRDBが再開始できない状態を避けることを重視した運用の場合は，適用しないでください。

HiRDBがオンラインダウンとなる状態を避けることを重視した運用の場合は，適用してください。

系切り替え構成を適用している場合など，HiRDBの再開始を自動で行う運用の場合は，適用しないでください。

(d)　片系運転適用時の注意

片系運転適用の有無によるHiRDBの動作及びHiRDB管理者の処置について次の表に示します。ステータスファイルに障害が発生したときの対処方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

表9‒5　片系運転適用の有無によるHiRDBの動作及びHiRDB管理者の処置

条件 | ステータスファイルの片系運転 （pd_syssts_singleoperation又はpd_sts_singleoperationオペランドの指定値）
適用する（continue指定） | 適用しない（省略又はstop指定）

予備ファイルがある

現用ファイルに障害が発生

HiRDBの動作

ステータスファイルをスワップします。

HiRDB管理者の処置

障害が発生したステータスファイルの障害対策をしてください。

現用ファイルの両系に，同時に障害が発生

HiRDBの動作

異常終了します。HiRDBは再開始できません。

HiRDB管理者の処置

マニュアル「HiRDB システム運用ガイド」の「ステータスファイルに障害が発生したときの対処方法」を参照してください。

予備ファイルがない

現用ファイルの片系に障害が発生

HiRDBの動作

片系運転を適用し，処理を続行します。

HiRDB管理者の処置

早急に予備のファイルを作成して，両系運転の状態に戻してください。

HiRDBの動作

異常終了します。

HiRDB管理者の処置

予備ファイルを作成し，HiRDBを再開始してください。

現用ファイルの両系に，同時に障害が発生

HiRDBの動作

異常終了します。HiRDBは再開始できません。

HiRDB管理者の処置

マニュアル「HiRDB システム運用ガイド」の「ステータスファイルに障害が発生したときの対処方法」を参照してください。

片系運転中に，正常な系に障害が発生

HiRDBの動作

異常終了します。HiRDBは再開始できません。

HiRDB管理者の処置

マニュアル「HiRDB システム運用ガイド」の「ステータスファイルに障害が発生したときの対処方法」を参照してください。

−

（凡例）−：該当しません。

(5)　ステータスファイルの障害に関する注意事項（重要）

現用ファイルの両系に同時に障害が発生した場合，HiRDBが異常終了し，再開始できなくなります。対策として，物理ディスクの多重化（ミラーリング）が考えられます。

HiRDBの開始前に，現用ファイル（終了時の現用ファイル）を削除，又はpdstsinitコマンドでステータスファイルを初期化した場合，HiRDBは再開始できなくなります。

9.4　RDエリアの配置

ここでは，次に示すRDエリアを配置するときの考慮点について説明します。

システム用RDエリア

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

ユーザ用RDエリア

ユーザLOB用RDエリア

リスト用RDエリア

9.4.1　システム用RDエリアの配置

システム用RDエリアは，ユーザ用RDエリアの配置を考慮して配置します。システム用RDエリアを配置するときの考慮点を次に示します。

システム用RDエリアはディクショナリサーバに配置します。

ディクショナリサーバとバックエンドサーバが同一のサーバマシンにある場合は，ユーザ用RDエリアを配置するディスクとは異なるディスクにシステム用RDエリアを配置するようにします。

システム用RDエリアのうち，特にデータディクショナリ用RDエリアとデータディレクトリ用RDエリアは，SQL文の解析などのためにHiRDBにアクセスされることが多くなります。このため，ユーザ用RDエリアを配置するディスクと同じディスクに配置すると，SQL文の解析などのためのアクセスと，表に対するアクセスがディスク上で競合するため，どちらか一方が他方のアクセスが終了するまで待たされることになります。

ディスクアクセスの競合を発生させないためのシステム用RDエリアの配置例を次の図に示します。

図9‒8　システム用RDエリアの配置例（HiRDB/パラレルサーバの場合）

[picture]

9.4.2　データディクショナリLOB用RDエリアの配置

ディスクに対するアクセスの競合をなくすため，ほかのRDエリアを配置するディスクとは異なるディスクに配置するようにします。データディクショナリLOB用RDエリアの配置例を次の図に示します。

図9‒9　データディクショナリLOB用RDエリアの配置例（HiRDB/パラレルサーバの場合）

[picture]

データディクショナリ用RDエリアとの関連

ストアドプロシジャ又はストアドファンクションを管理するディクショナリ表をほかのディクショナリ表とは別のデータディクショナリ用RDエリアに格納できます。

9.4.3　ユーザ用RDエリアの配置

(1)　システムログファイルとの関連

システムログファイルを配置したディスクとは異なるディスクに，ユーザ用RDエリアを配置するようにします。このようにすることで，シンクポイント時のシステムログファイルとユーザ用RDエリアを構成するHiRDBファイルへの入出力処理を複数のディスクに分散できるため，シンクポイントでの処理時間を削減できます。

(2)　システム用RDエリアとの関連

システム用RDエリアを配置したディスクとは異なるディスクにユーザ用RDエリアを配置するようにします。

(3)　表を横分割した場合

表を横分割した場合，横分割表を格納するRDエリアを異なるバックエンドサーバに配置します。また，横分割表を格納するRDエリアを異なるディスクに配置します。ユーザ用RDエリアの配置例を次の図に示します。

図9‒10　ユーザ用RDエリアの配置例（HiRDB/パラレルサーバの場合）

[picture]

(4)　フロータブルサーバの設置

複数のバックエンドサーバにわたる結合処理やソート処理などの，表に対する複雑な問い合わせ処理をするときは，ユーザ用RDエリアの配置に注意します。

すべてのバックエンドサーバにユーザ用RDエリアを配置すると，あるバックエンドサーバがユーザ用RDエリアに対するアクセスのほか，複雑な問い合わせ処理をするため，このバックエンドサーバの負荷が高くなります。このため，システム全体のスループットが低下することがあります。

よって，サーバマシンの台数に余裕がある場合，ユーザ用RDエリアを配置しないバックエンドサーバ（フロータブルサーバ）を設置します。フロータブルサーバを設置すると，複雑な問い合わせ処理をフロータブルサーバに割り当てるため，各バックエンドサーバの負荷を軽減できます。

9.4.4　ユーザLOB用RDエリアの配置

ディスクに対するアクセスの競合をなくすため，ユーザLOB用RDエリア以外のRDエリアを配置したディスクとは異なるディスクにユーザLOB用RDエリアを配置するようにします。

また，LOBデータを格納しているユーザLOB用RDエリアと，LOB列構成基表を格納しているユーザ用RDエリアとは同一のバックエンドサーバに配置します。ユーザLOB用RDエリアの配置例を次の図に示します。

図9‒11　ユーザLOB用RDエリアの配置例（HiRDB/パラレルサーバの場合）

[picture]

9.4.5　リスト用RDエリアの配置

基表があるバックエンドサーバにリスト用RDエリアを配置します。リスト用RDエリアを一つ以上作成すれば，そのバックエンドサーバにあるすべての表に対するリストを作成できます。

また，ディスクに対するアクセスの競合をなくすため，リスト用RDエリア以外のRDエリアを配置したディスクとは異なるディスクにリスト用RDエリアを配置するようにします。リスト用RDエリアの配置例を次の図に示します。

図9‒12　リスト用RDエリアの配置例（HiRDB/パラレルサーバの場合）

[picture]

9.5　ユニット数又はサーバ数が多いシステムを構築する場合の考慮点

ここでは，ユニット数又はサーバ数が多いシステムを構築，運用する場合の考慮点について説明します。目安として，10ユニット以上，又は10サーバ以上のシステムを構築して運用する場合にお読みください。

なお，ここでいうサーバとは，フロントエンドサーバ，ディクショナリサーバ，及びバックエンドサーバのことです。これらのサーバが10サーバ以上の場合にお読みください。

9.5.1　システム構築時の考慮点

(1)　システム定義の設定

ユニット数又はサーバ数が多いシステムを構築する場合，HiRDBで使用するポートを固定して通信負荷を軽減する必要があります。そのため，次の表に示すシステム定義のオペランドを指定してください。

表9‒6　通信負荷を軽減するために指定する必要があるオペランド

項番 | オペランド名 | 説明
1 | pd_name_fixed_port_lookup=Y | このオペランドにYを指定して，自ユニットの共用メモリ情報を使って，ほかのユニットと通信をするようにしてください。また，併せて項番2のオペランドを指定してください。

2

pd_mlg_port又はpdunitの-mオプション

pd_alv_port又はpdunitの-aオプション

pd_trn_port又はpdunitの-tオプション

pd_scd_port又はpdunitの-sオプション

pd_name_port又はpdunitの-pオプション

−

3

pd_ipc_conn_nblock_time

HiRDBのサーバ間通信を行う際に，稼働していないサーバがあると，このオペランドに指定した時間まで次の処理を待ち合わせます。そのため，このオペランドの指定値が大き過ぎると，性能低下の原因になります。

ネットワークの負荷が高くないシステムの場合は，このオペランドに2（秒）を指定してください。

ネットワーク負荷の高いシステムの場合は，次に示すどちらかの処置をしてください。

ネットワーク環境に合わせて，このオペランドの指定値を決める

ネットワーク環境を見直して，ネットワーク環境の増強を検討する

4 | pd_bes_connection_hold=Y | 特にありません。
5 | pd_bes_conn_hold_trn_interval | UAPの接続時間（SQLのCONNECTからDISCONNECTまでの間）が短い場合は，このオペランドに0を指定してください。

（凡例）−：該当しません。

(2)　高速接続機能の設定

高速接続機能を使用して通信負荷を軽減してください。高速接続機能については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(3)　影響分散スタンバイレス型系切り替え機能の設定

一つのHAグループに定義できるユニット数の上限は32です。そのため，ユニット数が33以上の場合は，HAグループを複数定義してください。影響分散スタンバイレス型系切り替え機能については，マニュアル「HiRDB システム運用ガイド」を参照してください。

9.5.2　システム運用時の考慮点

トランザクション又はコマンド（ユティリティを含む）の実行時，次に示す現象が発生して通信エラーとなることがあります。その結果，トランザクション又はコマンドがエラーとなったり，ホスト間監視によって，ユニットの異常が検知（KFPS05289-Eメッセージが出力）されたりすることがあります。

システムで使用するポート数が不足する

ユニット又はサーバ数が多い場合，HiRDBのサーバ間通信の接続数が増加し，システムで使用するポート数が不足することがあります。

ネットワーク帯域が不足する

ユニット又はサーバ数が多い場合，HiRDBのサーバ間通信の接続数が増加し，ネットワーク帯域が不足することがあります。

このような現象が発生した場合，次に示す方法で通信負荷を軽減してください。

(1)　pdloadコマンドの実行時に通信負荷を軽減する方法

pdloadコマンドを実行する場合，入力ファイルを分割格納条件ごとに作成し，RDエリア単位にpdloadコマンドを実行すると，通信負荷を軽減できます。

また，作成した複数の入力ファイルを1か所（同一サーバマシン上）に配置するのではなく，表格納RDエリアがあるサーバマシンに配置すると，通信負荷を軽減できます。

(2)　pdrorgコマンドの実行時に通信負荷を軽減する方法

pdrorgコマンドで表の再編成，表のアンロード，表のリロードを実行する場合，RDエリア単位又はサーバ単位でpdrorgコマンドを実行すると，通信負荷を軽減できます。

pdrorgコマンドでインデクスの再作成，インデクスの再編成，インデクスの一括作成を実行する場合，インデクス単位又はサーバ単位でpdrorgコマンドを実行すると，通信負荷を軽減できます。

(3)　pdcopy又はpdrstrコマンドの実行時に通信負荷を軽減する方法

pdcopy又はpdrstrコマンドを実行する場合，次に示す方法で通信負荷を軽減できます。

-sオプションにサーバ名を一つだけ指定してコマンドを実行する

-rオプションに複数のRDエリア名を指定する場合，同じバックエンドサーバに属するRDエリアだけを指定してコマンドを実行する

また，コマンドの処理対象となるサーバマシンにバックアップファイルを配置すると，通信負荷を軽減できます。

(4)　SQLの実行時に通信負荷を軽減する方法

一つのトランザクションで複数のバックエンドサーバ下のデータをアクセスする場合，サーバ間でデータ通信が発生するため，サーバ間のデータ通信経路を極力減らすようにしてください。次に示す条件を一つでも満たす場合，複数のバックエンドサーバ下のデータをアクセスします。

複数のバックエンドサーバに横分割した表を指定したSQLを発行する

FROM句に二つ以上の表を指定したSQLを発行する

副問合せを指定したSQLを発行する

集合演算を指定したSQLを発行する

共用表のデータを更新するSQLを発行する

同一トランザクション内に複数のSQLを発行する場合，それぞれのSQLのFROM句に異なるバックエンドサーバに定義された表を指定する

これらの条件を一つでも満たす場合は，次に示す対策をして，サーバ間のデータ通信経路を削減してください。

横分割表の分割数を少なくする

SQLの探索条件に分割キーに対する条件を指定する

表の結合時は，対象となる表の分割を合わせ，結合キーを分割キーとする

トランザクションがアクセスする複数の表のデータを同じバックエンドサーバに格納する

(5)　フロータブルサーバの使用時に通信負荷を軽減する方法

フロータブルサーバを使用すると通信負荷が上がるため，フロータブルサーバを極力使用しないでください。次に示す条件を一つでも満たす場合，フロータブルサーバが使用されます。

FROM句に二つ以上の表を指定したSQLを発行する（結合方式にネストループジョインを適用する場合を除く）

副問合せを指定したSQLを発行する

集合演算を指定したSQLを発行する

ORDER BY句を指定したSQLを発行する（ORDER BYのためのソート処理をしなくても，インデクスを検索することでORDER BYに含まれる列のソート順を保証できる場合を除く）

GROUP BY句を指定したSQLを発行する

DISTINCTを指定したSQLを発行する

ビュー表，WITH句，又はFROM句に導出表を指定したSQLを発行する（ビュー表，WITH句を指定したSQLで内部導出表を作成しない場合を除く）

内部導出表を作成する条件については，マニュアル「HiRDB SQLリファレンス」を参照してください。

FOR READ ONLY句を指定したSQLを発行する

これらの条件を一つでも満たす場合は，次に示す対策をすると，使用するフロータブルサーバ数を削減できることがあります。

SQL最適化オプションに"FLTS_ONLY_DATA_BES"を指定する

SQL最適化オプションに"SORT_DATA_BES"を指定する

SQL最適化オプションについては，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(6)　共用表の使用時に通信負荷を軽減する方法

複数のフロントエンドサーバを経由して共用表を更新すると，通信負荷が上がります。そのため，共用表の更新をする場合は，HiRDBクライアントが接続するフロントエンドサーバができるだけ同じになるようにしてください。

(7)　ユティリティの同時実行数に関する注意事項

バックエンドサーバ数が多い場合，ユティリティの同時実行数が多いと，ユティリティが異常終了することがあります。この場合，同時に実行するユティリティの数を減らすなどの対処をしてください。

(8)　制限事項

ユニット数が65以上の場合，MIBパフォーマンス情報監視機能は使用できません。

10　マルチHiRDBの設計

この章では，マルチHiRDBのシステム設計で検討する項目について説明します。

10.1　マルチHiRDBのシステム設計

マルチHiRDBのシステムを設計する場合に，通常のHiRDBと設計方法が異なる箇所についてだけ説明します。

10.1.1　マルチHiRDBのインストール

マルチHiRDBをインストールする場合に気を付けることについて説明します。

(1)　HiRDB管理者の登録

マルチHiRDBのサーバでは，HiRDBごとに別々のHiRDB管理者を登録してください。HiRDB管理者の登録については，「HiRDB管理者の登録」を参照してください。

(2)　HiRDBをインストールするときの注意

既にHiRDBが「標準セットアップ」でインストールされているサーバマシンに，更にHiRDBをインストールする場合は，インストール時に「識別子付きセットアップ」を選んで，セットアップ識別子を指定してください。セットアップ識別子には，単一サーバマシンで一意な4文字以内の空白を含まない任意の半角英数字（英文字は大文字）を指定します。セットアップ識別子はHiRDBの環境を識別するために指定します。

HiRDBごとに異なるインストールディレクトリを指定してインストールしてください。

複数のHiRDBをインストールできるのはHiRDB 05-05以降です。05-04以前のバージョンを混在しないでください。

HiRDB/シングルサーバとHiRDB/パラレルサーバを混在できるのは，HiRDB 07-00以降です。06-02以前のバージョンと混在しないでください。

マルチHiRDBに対応していない関連製品を使用する場合，HiRDBを標準セットアップ（セットアップ識別子の付かない形式）を選択してインストールする必要があります。

HiRDBのインストールについては，「HiRDBのインストール手順」を参照してください。

(3)　連絡用ポートのサービス名及びサービスポート番号の設定（HiRDB/パラレルサーバの場合又はHiRDB/シングルサーバで系切り替え機能を使用する場合）

セットアップ識別子を指定してインストールした場合，HiRDBのサービスが起動する前に連絡用ポートのサービス名及び連絡用ポートのサービスポート番号をSERVICESファイルに設定する必要があります。連絡用ポートのサービス名とサービスポート番号の決定から設定まで手順を次に示します。

(a)　システムの構成の確認

HiRDBシステムで同一，単一サーバマシンで一意な連絡用ポートのサービス名及びサービスポート番号を決定します。HiRDBのユニットをどのように構成するかを確認してください。

(b)　サービスポート番号のOSへの登録

（a）で決定した連絡用ポートのサービス名と，HiRDBシステムで同一，単一サーバマシンで一意なサービスポート番号をSERVICESファイル（「%windir%¥system32¥drivers¥etc」下のファイル）に登録します。

(c)　連絡用ポートのサービス名の変更

（b）で登録した連絡用ポートのサービス名を各ユニットに設定します。HiRDBサーバ内のユニットは同じ連絡用ポートのサービス名，サービスポート番号にしてください。サービスポート番号は，pdntenvコマンドで設定します。

インストール直後の連絡用ポートのサービス名には，標準セットアップした場合はpdrshsrv，セットアップ識別子を指定してインストールした場合はpdrshsrvにセットアップ識別子を付けた名称が仮定されます。標準セットアップしたHiRDB/パラレルサーバと，セットアップ識別子（P001）を指定したHiRDB/パラレルサーバで，マルチHiRDBを構成したときの連絡用ポートのサービス名とサービスポート番号の設定例を次の図に示します。

図10‒1　連絡用ポートのサービス名とサービスポート番号の設定例

[picture]

〔説明〕

SERVICESファイルに連絡用ポートのサービス名pdrshsrvとサービスポート番号29999を設定します。

セットアップ識別子P001のHiRDB/パラレルサーバの連絡用ポートのサービス名をpdntenvコマンドでpdrshsrvに変更します。

10.1.2　マルチHiRDBの環境設定

(1)　HiRDBサーバの環境変数の設定

マルチHiRDBのサーバで別々に設定したHiRDB管理者は，それぞれが操作する対象のHiRDBを環境変数PDDIRで判別します。HiRDB管理者別に，HiRDB運用ディレクトリを環境変数PDDIRに指定します。

また，環境変数PATHに各HiRDBの%PDDIR%¥binを設定すると，PATH中で先に指定したHiRDBの運用コマンドしか使用できません。そこで，各HiRDBを操作し分けるには，それぞれのHiRDB用のウィンドウを用意し，それぞれのウィンドウで環境変数を設定して運用することをお勧めします。

(2)　HiRDBシステム定義の設定

HiRDBごとにHiRDBシステム定義を作成してください。HiRDBシステム定義に指定する次に示す情報は，HiRDBごとに変えてください。

HiRDB識別子（システム共通定義のpd_system_idオペランド）

HiRDBのポート番号（システム共通定義のpd_name_portオペランド）

ユニット識別子（ユニット制御情報定義のpd_unit_idオペランド）

(3)　クライアント環境定義の設定

クライアントからどのHiRDBにアクセスするかは，クライアント環境定義のPDNAMEPORTオペランドで指定します。アクセスするHiRDBのポート番号をPDNAMEPORTオペランドに指定してください。クライアント環境定義については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

10.2　運用上の注意

10.2.1　運用コマンド及びユティリティ

セットアップ識別子を指定してインストールしたHiRDBに対して，HiRDBの運用コマンド及びユティリティを実行する場合は，環境変数を設定する必要があります。HiRDBでは，運用コマンド及びユティリティを実行する環境に合わせた環境変数を設定した作業用コンソール及び環境変数設定用バッチファイルを提供しています。

(1)　作業用コンソールの使用方法

［スタート］−［プログラム］−［HiRDBSingleServerセットアップ識別子］又は［HiRDBParallelServerセットアップ識別子］−［HiRDB コマンドプロンプト］をクリックして作業用コンソールを起動します。この作業用コンソールで，運用コマンド及びユティリティを実行します。

(2)　環境変数設定用バッチファイルの使用方法

環境変数設定用バッチファイル（%PDDIR%¥SAMPLE¥sampleconf¥HiRDBCMD.BAT）を直接カスタマイズすると，更新インストール時に上書きされるため，このバッチファイルを別名でコピーし，必要な環境変数の設定などのカスタマイズをします。そして，運用コマンド及びユティリティの実行に利用してください。

標準のコマンドプロンプト上で実行する場合は，次に示す環境変数の設定が必要です。

環境変数 | 説明
PDDIR | HiRDBのインストールディレクトリを指定します。
PDCONFPATH | HiRDBシステム定義ファイルを格納するディレクトリを絶対パスで指定します。ただし，ユニット制御情報は，この指定に関係なく%PDDIR%¥conf下のファイルを使用します。
PATH | PATH環境変数の先頭に%PDDIR%¥BIN;%PDDIR%¥CLIENT¥UTL;を追加します。
PDUXPLDIR | %PDDIR%¥UXPLDIRを指定します。

10.2.2　クライアントからの接続用ポート番号の設定

クライアントからの接続用のHiRDBポート番号は，各HiRDBで異なるポート番号を設定してください。ポート番号は，システム共通定義のpd_name_portオペランドで指定します。pd_name_portオペランドについては，マニュアル「HiRDB システム定義」を参照してください。

10.2.3　セットアップ識別子付きのHiRDBの起動と終了

セットアップ識別子を指定してインストールをした場合，起動又は停止するサービス名にセットアップ識別子が付きます。サービスを起動又は停止する場合は，指定したセットアップ識別子の付いたサービス名で操作してください。

10.2.4　系切り替え機能との関連

(1)　MSFCへの登録方法

MSFCに登録してHiRDBを系切り替え構成にする場合は，現用系と予備系のセットアップ識別子を同じにしておく必要があります。

(2)　相互系切り替え構成への移行について

MSFCを利用してHiRDBを系切り替え構成にする場合は，同じサービス名を別サーバマシンで起動します。既存の環境があるときはサービス名が重複するため，既存のサービス名を変更する必要があります。サービス名を変更する場合は，既存のHiRDBをアンインストールした後，同じディレクトリに再度インストールしてください。また，ディレクトリ構成が重複していた場合は，HiRDBサーバを移行して，環境を新規に作成する必要があります。HiRDBサーバの移行については，マニュアル「HiRDB システム運用ガイド」を参照してください。

11　グローバルバッファ，ローカルバッファの設計

この章では，グローバルバッファ，ローカルバッファを設計する上で検討する項目について説明します。

11.1　グローバルバッファの割り当て

グローバルバッファとは，ディスク上のRDエリアに格納されているデータを入出力するためのバッファの集まりのことで，共用メモリ上に確保されます。データを更新するためにバッファ上で更新され，データベースには未反映のバッファを更新バッファといいます。また，データを参照するためのバッファ，及びデータベースに反映済みのバッファを参照バッファといいます。

データを格納するRDエリア又はインデクスには，必ずグローバルバッファを割り当てます。グローバルバッファには次に示す種類があります。

インデクス用グローバルバッファ

データ用グローバルバッファ

LOB用グローバルバッファ

また，HiRDBの稼働中にグローバルバッファを追加，変更，又は削除することをグローバルバッファの動的変更といいます。動的変更をするには，pdbufmodコマンドを使用します。グローバルバッファの動的変更の詳細は，マニュアル「HiRDB システム運用ガイド」を参照してください。

それぞれのグローバルバッファと割り当て方法について説明します。

11.1.1　インデクス用グローバルバッファの割り当て

アクセス頻度が高いインデクスがある場合，特に，クラスタキーやUNIQUEを指定したインデクスがある場合は，そのインデクスに専用のグローバルバッファを割り当てるようにします。これでインデクスが常駐できるため，インデクスにアクセスするときの入出力回数が削減できます。

インデクス専用のグローバルバッファを割り当てると，このグローバルバッファは，表の行を格納したユーザ用RDエリアのグローバルバッファとは独立して管理されます。このため，グローバルバッファ内でインデクスページとデータページが共用されることがありません。しかし，あるインデクスに対して，表やほかのインデクスと同一のグローバルバッファを割り当てると，ほかの表のデータなどが一時的に大量に入力された場合，このインデクスの情報がグローバルバッファ上から追い出されてしまうことがあります。

インデクス専用のグローバルバッファの概要を次の図に示します。

図11‒1　インデクス用グローバルバッファの概要

[picture]

11.1.2　データ用グローバルバッファの割り当て

(1)　異なるページ長のRDエリアが複数ある場合

異なるページ長のRDエリアが複数ある場合は，同じか又は近いページ長のRDエリアをまとめて一つのグローバルバッファに割り当てます。これによって，メモリの使用効率が良くなります。

異なるページ長のRDエリアをまとめて一つのグローバルバッファに割り当てると，ページ長が最も大きいRDエリアに合わせてグローバルバッファが確保されます。このため，ページ長が小さいRDエリアに対してデータページの入出力をした場合，グローバルバッファ一面に使用されない領域ができることになり，メモリの使用効率が下がります。

グローバルバッファの割り当ての例を次の図に示します。

図11‒2　グローバルバッファの割り当ての例

[picture]

HiRDB/パラレルサーバの場合は，サーバごとにページ長が最も大きいRDエリアに合わせてグローバルバッファが確保されます。例えば，ページ長が最も大きいRDエリアのページ長がバックエンドサーバ1は4096バイト，バックエンドサーバ2は8192バイトの場合，割り当てられるグローバルバッファサイズはバックエンドサーバ1が4096バイト，バックエンドサーバ2が8192バイトになります。

(2)　一つのグローバルバッファに複数のRDエリアを割り当てる場合

複数のRDエリアを構成するHiRDBファイルが一つのHiRDBファイルシステム領域に含まれる場合は，これらのRDエリアを一つのグローバルバッファに割り当てるようにします。

(3)　UAPからのアクセス方法が異なるRDエリアが複数ある場合

同じページ長でも，UAPからのアクセス方法が異なるRDエリアが複数ある場合，例えば，用途が異なるRDエリア，順次処理が多くて更新が少ないRDエリア，追加や更新が多いRDエリアなどがある場合は，それぞれ異なるグローバルバッファを割り当てるようにします。

(4)　RDエリアの追加が予想される場合

データベース構成変更ユティリティ（pdmod）で追加できるRDエリアを次に示します。

ユーザ用RDエリア

ユーザLOB用RDエリア

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

ストアドプロシジャを管理するディクショナリ表を格納するデータディクショナリ用RDエリア

リスト用RDエリア

また，フレキシブルハッシュ分割した表を格納しているRDエリアは，ALTER TABLEでRDエリアを追加できます。追加したRDエリアを使用するためには，グローバルバッファを割り当てる必要があります。このため，RDエリアの追加が予想される場合は，追加が予想されるRDエリアの最大ページを見込んで，システム共通定義のpdbufferオペランドで-oオプションを指定したグローバルバッファを用意しておきます。

なお，あらかじめグローバルバッファを割り当てていなかった場合は，システム共通定義のpdbufferオペランドで，追加したRDエリアへの割り当てを再度定義します。これによって，追加したRDエリアを使用できます。

(5)　リスト用RDエリアにグローバルバッファを割り当てるときの注意

リスト用RDエリアにグローバルバッファを割り当てる場合，ユーザ用RDエリアにグローバルバッファを割り当てるときの設計に加え，次に示す点に注意してください。

リスト用RDエリアのグローバルバッファと，表やインデクスのグローバルバッファを共用したときに大量のリストを作成すると，表やインデクスのデータがグローバルバッファから追い出されてしまうことがあります。したがって，なるべく共用しないで，リスト用RDエリア専用のグローバルバッファを割り当ててください。

リスト用RDエリアのグローバルバッファのバッファ面数には，なるべく「同時にアクセスするリスト数×1.5」以上の値を指定してください。

リスト用RDエリアのグローバルバッファと，表やインデクスのグローバルバッファとを共用する場合，ページ長が同じか又はページ長が近いRDエリアを共用してください。

リスト用RDエリアのグローバルバッファにプリフェッチ機能を指定した場合，次に示すSQL文が実行されたときにセグメントサイズ分のページを一括して入力します。

SELECT文でリストを介した表の検索をする場合，リストページを一括して入力します。

ASSIGN LIST文でリストからリストを作成する場合，FROM句に指定したリストのリストページを一括して入力します。

11.1.3　LOB用グローバルバッファの割り当て

次に示す場合に，LOB用RDエリアにグローバルバッファを割り当てるようにします。これによって，LOB用RDエリアに格納されているデータの入出力回数が削減されます。

プラグインインデクスを格納している場合

データ量がそれほど多くなく，バッファリング効果が望める場合

アクセス頻度の高いLOBデータを格納している場合

なお，RDエリア間のバッファリングの干渉を避けるため，単独のRDエリアに割り当てることをお勧めします。次に示すLOB用RDエリアにグローバルバッファを割り当てられます。

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

ユーザLOB用RDエリア

レジストリLOB用RDエリア

11.1.4　グローバルバッファの割り当て方法

(1)　インデクス用グローバルバッファを割り当てる場合

システム共通定義のpdbufferオペランドの-iオプションに，インデクス用グローバルバッファを割り当てるインデクスを，「認可識別子．インデクス識別子」の形式で指定します。

クラスタキーの場合はインデクス識別子をHiRDBが決定するため，クラスタキーを指定した表を定義した後に，ディクショナリ表のSQL_INDEXES表のINDEX_NAME列を検索してインデクス識別子を確認してください。クラスタキーのインデクス識別子は，次のように表示されます。

(CLUSTER表番号)

ディクショナリ表の検索方法とSQL_INDEXES表については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

定義したインデクスにインデクス用グローバルバッファを割り当てる場合は，いったんHiRDBを正常終了し，pdbufferオペランドを指定してインデクス用グローバルバッファを割り当ててください。この作業を行わない場合，定義したインデクスはインデクス格納RDエリアに割り当てられているデータ用グローバルバッファを使用します。

●グローバルバッファ面数を見積もるときの考え方

グローバルバッファ面数は，インデクスの総ページ数（インデクスの格納ページ数として算出した値）以上とすることを原則とし，そこからインデクスの重要度によってグローバルバッファ面数を減らしてください。

インデクスの使用ページ数は，データベース状態解析ユティリティ（pddbst）で確認できます。

(2)　データ用グローバルバッファを割り当てる場合

システム共通定義のpdbufferオペランドの-rオプションでグローバルバッファに割り当てるRDエリア名を指定します。

(3)　LOB用グローバルバッファを割り当てる場合

次に示す手順で割り当てます。

システム共通定義のpdbufferオペランドの-rオプションでグローバルバッファに割り当てるLOB用RDエリア名を指定します。

システム共通定義のpdbufferオペランドの-bオプションでグローバルバッファに割り当てるLOB用RDエリア名を指定します。

(4)　グローバルバッファの定義例

RDエリアの構成

RDエリアの構成は次のとおりとします。

RDエリアの種類 | RDエリア名
マスタディレクトリ用RDエリア | RDMAST
データディレクトリ用RDエリア | RDDIR
データディクショナリ用RDエリア | RDDIC
ユーザ用RDエリア | USER01，USER02，USER03
ユーザLOB用RDエリア | ULOB03
データディクショナリLOB用RDエリア | DICLOB01，DICLOB02
リスト用RDエリア | LIST01

定義例

グローバルバッファの定義例を次に示します。

pdbuffer -a DGB1 -n 1000 -r RDMAST,RDDIR,RDDIC              1
pdbuffer -a DGB2 -n 1000 -r USER01,USER02
pdbuffer -a DGB3 -n 1000 -r USER03
pdbuffer -a DGB4 -n 1000 -r ULOB03
pdbuffer -a DGB5 -n 1000 -r DICLOB01
pdbuffer -a DGB6 -n 1000 -r DICLOB02
pdbuffer -a DGB7 -n 1000 -r LIST01

pdbuffer -a LGB1 -n 1000 -b ULOB03                          2
pdbuffer -a LGB2 -n 1000 -b DICLOB01
pdbuffer -a LGB3 -n 1000 -b DICLOB02

pdbuffer -a IGB1 -n 1000 -i USER1.INDX01                    3
pdbuffer -a IGB2 -n 1000 -i USER1.INDX02

〔説明〕

データ用グローバルバッファの定義です。作成するすべてのRDエリアを-rオプションで指定します。

LOB用グローバルバッファの定義です。

-bオプションに指定しているRDエリアは，-rオプションでも指定しておく必要があります。

インデクス用グローバルバッファの定義です。-iオプションにインデクスの認可識別子とインデクス識別子を指定します。

この定義例に出てくるpdbufferオペランドのオプションを簡単に説明します。

-a：グローバルバッファの名称を指定します。

-n：グローバルバッファの面数を指定します。

-r：データ用グローバルバッファを割り当てるRDエリアを指定します。

-b：LOB用グローバルバッファを割り当てるLOB用RDエリアを指定します。

-i：インデクス用グローバルバッファを割り当てるインデクスを指定します。

11.2　グローバルバッファのバッファ面数の設定

11.2.1　グローバルバッファのバッファ面数の設定するときの考慮点

(1)　共用メモリの上限を考慮した設定

グローバルバッファは，共用メモリ上に確保されます。この共用メモリは，HiRDBの運用ディレクトリがあるディスク上にファイルとして確保されます。そのため，ディスクの空き容量を十分に確保しておく必要があります。

共用メモリのセグメントサイズは，システム共通定義のSHMMAXで指定した値で最大512個分までしか確保されません。そのため，SHMMAX値［MB］×512の範囲に収まるようにグローバルバッファを定義する必要があります。

なお，１個の共用メモリセグメントに確保できないグローバルバッファを定義すると，複数の共用メモリセグメントが確保されるため，共用メモリに対するアクセスのオーバヘッドが大きくなります。

(2)　バッファヒット率を考慮した設定

グローバルバッファは，共用メモリ上に確保されます。必要以上にグローバルバッファのバッファ面数を設定すると，共用メモリが増加して，システムのディスク容量及びメモリを圧迫します。また，グローバルバッファを検索するためのオーバヘッドも大きくなります。このため，必要最低限の入出力性能が得られるように設定する必要があります。

必要最低限の入出力性能が得られるように設定するには，グローバルバッファ全体のヒット率（更新バッファヒット率＋参照バッファヒット率）及び参照バッファヒット率が高くなるように設定します。このためには，次に示す方法があります。

グローバルバッファのバッファ面数を大きくします。

グローバルバッファに割り当てるRDエリア又はインデクスを異なるグローバルバッファに分けます。

なお，上記の方法でバッファ面数を設定してHiRDBを稼働してから性能向上を図る場合は，pdbuflsコマンド又は統計解析ユティリティ（pdstedit）を指定します。

pdbuflsコマンドの場合には，編集項目である，グローバルバッファ全体のヒット率を高くなるように面数を設定します。

統計解析ユティリティ（pdstedit）の場合には，編集項目である，更新バッファヒット率及び参照バッファヒット率を参照して，グローバルバッファ全体のヒット率が高くなるように面数を設定します。

(3)　設定方法

システム共通定義のpdbufferオペランドの-nオプションでバッファ面数を指定します。

11.3　プリフェッチ機能の指定

プリフェッチ機能とは，グローバルバッファ（又はローカルバッファ）上に複数のページを一括して入力することです。

11.3.1　プリフェッチ機能の効果

ダイレクトディスクアクセス（raw/IO）を使用して大量検索をする場合に入出力時間を短縮できます。特にインデクスを使用しない検索又はインデクスを使用して昇順検索をする表で，データ件数が多い場合に有効です。

11.3.2　適用基準

プリフェッチ機能は次に示すSQL文又はユティリティの場合にページを一括して入力します。

インデクスを使用しないSELECT，UPDATE，DELETE文の場合にデータページを一括して入力します。

インデクスを使用した昇順検索をするSELECT，UPDATE，DELETE文（=条件，IN条件を除く）の場合にインデクスリーフページを一括して入力します。

クラスタキーを使用した昇順検索をするSELECT，UPDATE，DELETE文（=条件，IN条件を除く）の場合にインデクスリーフページ及びデータページを一括して入力します。

ローカルバッファを使用しないデータベース再編成ユティリティ（pdrorg）のアンロードの場合にインデクスリーフページ及びデータページを一括して入力します。

11.3.3　指定方法

(1)　グローバルバッファの場合

プリフェッチ機能を動作させるには，システム共通定義のpdbufferオペランドの-mオプションに1以上を指定します。また，一括して入力するページ数は，pdbufferオペランドの-pオプションに指定します。

(2)　ローカルバッファの場合

プリフェッチ機能を使用するには，pdlbufferオペランドの-pオプションに一括して入力するページ数を指定します。

11.3.4　指定上の考慮点

プリフェッチ機能を使用する場合，グローバルバッファ（又はローカルバッファ）とは別に一括入力専用のバッファが取られます。これによって，グローバルバッファ用の共用メモリが増加します。グローバルバッファが使用する共用メモリの計算式については，「HiRDBのメモリ所要量」を参照してください。

プリフェッチ機能が有効に動作しているかどうかは統計解析ユティリティ（pdstedit）又はpdbuflsコマンドのプリフェッチヒット率を参照してください。

11.4　非同期READ機能の指定

11.4.1　非同期READ機能の効果と指定方法

プリフェッチ機能を使用してグローバルバッファ上に複数のページを一括入力するとき，一括入力用のバッファにDB処理サーバプロセスから同期処理で一括入力して先読みをしています。非同期READ機能とは，プリフェッチ機能使用時に一括入力用のバッファを2面用意し，DB処理が一つのバッファを使用中にDB処理とは非同期に非同期READプロセスがもう一つのバッファに先読み入力をする機能です。DB処理と先読み入力を同時に実行させることで処理時間を短縮できます。また，HiRDB/パラレルサーバの場合は，入出力の待ち時間にスレッドを切り替えて処理することで入出力待ち時間を削減できます。

なお，非同期READ機能はローカルバッファには使用できません。また，SCHEDULE属性のRDエリアには適用されません。プリフェッチ機能で動作します。

(1)　非同期READ機能の効果

プリフェッチ機能と同じですが，プリフェッチ機能だけを使用した場合と比べて，非同期READ機能は処理負荷が高いジョイン処理などで有効です。非同期READ機能は，入出力処理時間が長いダイレクトディスクアクセス（raw/IO）を使用している場合，特に効果があります。逆に，入出力時間が掛からないWindowsのファイルシステム又は日立ディスクアレイシステムのディスクなどを使用している場合は余り効果が得られないことがあります。

(2)　指定方法

プリフェッチ機能の指定（pdbufferオペランドの-mオプションに1以上を指定）をしていることが前提です。

pd_max_ard_processオペランドで，非同期READプロセス数を指定します。0を指定するか，又はこのオペランドを省略した場合，非同期READ機能は動作しません。

(3)　指定上の考慮点

プリフェッチ機能を使用する場合，グローバルバッファとは別に一括入力専用のバッファが2面取られます。これによって，グローバルバッファ用の共用メモリが増加します。グローバルバッファが使用する共用メモリの計算式については，「HiRDBのメモリ所要量」を参照してください。

11.5　デファードライト処理の指定

11.5.1　デファードライト処理の効果と指定方法

デファードライト処理とは，グローバルバッファ上で更新されたページをCOMMIT文が発行されてもディスクに書き込まないで，更新ページ数がある一定の値に達した時点でディスクに書き込む処理のことです。なお，更新ページ数がある一定の値（HiRDBが決定する値）に達した時点をデファードライトトリガといいます。ディスクに書き込む更新ページの数は，システム共通定義のpdbufferオペランドの-wオプションで指定した，デファードライトトリガでの更新ページの出力比率を基にHiRDBが決定します。なお，次のRDエリアはデファードライト処理の対象ではありません。

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

ユーザLOB用RDエリア

レジストリLOB用RDエリア

リスト用RDエリア

(1)　デファードライト処理の効果

COMMIT文が発行されてもディスクに書き込まないため，入出力処理の負荷が軽減します。

(2)　指定方法

pd_dbsync_pointオペランドにsyncを指定するか，指定を省略してください。また，pdbufferオペランドの-wオプションに，デファードライトトリガでの更新ページ出力比率を指定します。

(3)　指定上の考慮点

グローバルバッファに割り当てるRDエリアに格納された表やインデクスに対する更新が多い場合は，デファードライトトリガでの更新ページの出力比率を低めに設定します。

グローバルバッファに対する更新が多くても，同じデータに対する更新がほとんど発生しない場合は，デファードライトトリガでの更新ページの出力比率を高めに設定します。

HiRDBを稼働してから，更に性能の向上を図る場合は，pdbuflsコマンドを使用します。それぞれの編集項目である各グローバルバッファの更新要求ヒット率を参照して，次に示すように設定します。

更新要求バッファヒット率が高い場合は，デファードライトトリガでの更新ページの出力比率を低く設定します。

更新要求バッファヒット率が低い場合は，デファードライトトリガでの更新ページの出力比率を高く設定します。

(4)　注意

デファードライトトリガでの更新ページ出力比率を必要以上に高くすると，デファードライト処理でのディスクへの書き込みが多くなります。このため，同時に実行しているトランザクションが入出力待ちになることがあり，レスポンスタイムが悪くなることがあります。

また，必要以上に低くすると，シンクポイントダンプの出力時に，データベースに書き出すページ数が多くなることがあります。このため，同時に実行しているトランザクションが入出力待ちになることがあり，レスポンスタイムが悪くなることがあります。

11.6　デファードライト処理の並列WRITE機能の指定

11.6.1　デファードライト処理の並列WRITE機能の効果と指定方法

デファードライト処理の並列WRITE機能とは，デファードライトの書き込み処理を複数のプロセスで並列に実行する機能です。並列WRITE機能を使用する場合としない場合の概要を次の図に示します。

図11‒3　デファードライト処理の並列WRITE機能の概要

[picture]

(1)　デファードライト処理の並列WRITE機能の効果

書き込み処理を複数のデファードライト処理用並列WRITEプロセスで実行するため，ディスクへの書き込み時間が短縮されます。

(2)　指定方法

pd_dfw_awt_processオペランドに書き込み処理をするデファードライト処理用並列WRITEプロセス数を指定します。また，デファードライトトリガの要求比率をpd_dbbuff_rate_updpageオペランドに指定します。なお，pd_dfw_awt_processオペランドの記述がない場合，デファードライト処理の並列WRITE機能は無効になります。

(3)　指定上の考慮点

デファードライト処理の並列WRITE機能を指定すると，デファードライト処理用並列WRITEプロセス数が増加するため，CPU利用率が上がります。

11.7　コミット時反映処理の設定

11.7.1　コミット時反映処理の効果と指定方法

コミット時反映処理とは，グローバルバッファ上で更新されたページをCOMMIT文発行時にディスクに書き込む処理のことです。

(1)　コミット時反映処理の効果

COMMIT文の発行時にデータベースの更新内容をディスクに書き込むため，トランザクションの完了時点でデータベースの内容が保証されます。そのため，全面回復処理時に，シンクポイント時点からデータベースを回復する必要がなく，全面回復処理の時間が短縮できます。

(2)　指定方法

pd_dbsync_pointオペランドにcommitを指定します。

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

(3)　指定上の考慮点

pdbuflsコマンドで取得した情報を参照して，ディスクへの出力回数が多くて更新要求ヒット率が低い場合には，グローバルバッファのバッファ面数を大きく設定します。

11.8　グローバルバッファのLRU管理方式

HiRDBでは，業務の種類（オンライン業務又はバッチ業務）によって，グローバルバッファのLRU管理方式を選択できます。

11.8.1　LRUの管理方式

LRUの管理方式には，次に示す2種類があります。

参照バッファ及び更新バッファの独立したLRUでの管理

グローバルバッファの一括したLRUでの管理

(1)　参照バッファ及び更新バッファの独立したLRUでの管理

参照バッファ及び更新バッファをそれぞれ独立したLRUで管理します。

グローバルバッファの不足時には，グローバルバッファ内のアクセスした参照バッファの中で，最も古いバッファがメモリから追い出されます。

(a)　適用基準

参照バッファ及び更新バッファをそれぞれ独立したLRUで管理した方がよい場合を次に示します。

検索処理に比べて，更新処理の割合が比較的少ない場合で更新バッファヒット率が高い場合（オンライン業務のように1トランザクション当たりの参照，更新件数が比較的少ない場合）

(b)　指定方法

システム共通定義のpd_dbbuff_lru_optionオペランドにSEPARATEを指定します。

(c)　注意事項

大量の更新処理が発生した場合，参照バッファヒット率が低下し，検索処理が遅くなります。

次のどちらかに該当する場合は，無条件にpd_dbbuff_lru_optionオペランドにMIXを仮定します。そのため，参照バッファ及び更新バッファの独立したLRUでの管理はできません。

pd_dbsync_pointオペランドにcommitを指定している場合

pd_dbbuff_binary_data_lruオペランドにNを指定している場合

(2)　グローバルバッファの一括したLRUでの管理

グローバルバッファを一括したLRUで管理します。グローバルバッファの不足時には，グローバルバッファ内のアクセスしたバッファで，最も古いバッファがメモリから追い出されます。

(a)　適用基準

グローバルバッファを一括したLRUで管理した方がよい場合を次に示します。

検索処理に比べて，更新処理の割合が多い場合，突発的な大量検索又は大量更新が発生する場合（オンライン業務とバッチ業務など，大量検索，大量更新が共存する場合）

(b)　指定方法

システム共通定義のpd_dbbuff_lru_optionオペランドにMIXを指定します。

システム共通定義のpdbufferオペランドの-wオプションに，デファードライトトリガでの更新ページの出力比率を指定します。

(c)　注意事項

更新バッファヒット率が高い場合には，大量検索によって更新バッファが一時的にメモリから追い出されます。このような場合には，更新処理の延長でファイルの読み込みが発生し，処理が遅くなる場合があります。

pd_dbsync_point=syncの指定又は省略時には，検索処理の延長でファイルへの書き込みが発生し，検索処理が遅くなる場合があります。

11.8.2　UAPごとのLRU管理抑止設定

OLTP環境で，UAPの大量検索や大量更新によってグローバルバッファにキャッシュされた直近の内容がメモリから追い出され，OLTP性能を一時的に低下させてしまうことがあります。このとき，大量検索や大量更新をするUAPを特定できるのであれば，UAPごとにLRU管理を抑止する設定をすることで，OLTP性能の低下を回避できます。

参考

LRU管理を抑止できるのはUAPからのアクセスだけです。コマンドやユティリティからのアクセスの場合は，LRU管理が行われます。ただし，次のコマンドはLRU管理が抑止されます。

データベース状態解析ユティリティ（pddbst）

次のどちらかの条件に該当する場合，LRU管理が抑止されます。

・-sオプションを指定しない

・-sオプションと-bオプションを指定する

空きページ解放ユティリティ（pdreclaim）

globalbuffer_lru文の値がnoの場合，LRU管理が抑止されます。

(1)　適用基準

OLTP環境で，グローバルバッファを使用して大量検索や大量更新をするUAPを実行する場合に適用することをお勧めします。

(2)　適用の効果

LRU管理を抑止したUAPがアクセスしたページはアクセス頻度に関係なく，最も古い時にアクセスしたページとしてグローバルバッファ上にキャッシュされます。そのため，LRU管理を適用したUAPがアクセスしたページより先にメモリから追い出されるようになり，LRU管理を適用したUAPがアクセスしたページはメモリから追い出されなくなります。ただし，LRU管理を抑止するUAPとLRU管理を抑止しないUAPが同じページにアクセスする場合，そのページはLRU管理されます。

(3)　指定方法

クライアント環境定義のPDDBBUFLRUオペランドにNOを指定します。

(4)　注意事項

LRU管理を抑止するUAPがアクセスしたページは，アクセス頻度に関係なく，バッファ不足が発生すると，メモリからの追い出し対象となります。そのため，LRU管理を抑止するUAPはバッファヒット率の低下に伴う入出力回数の増加によって，レスポンス性能が低下することがあります。

UAPは1〜4面のバッファを同時に確保します。そのため，LRU管理を抑止する設定をした場合でも，UAPごとにグローバルバッファにキャッシュされているページの中で1〜4ページはキャッシュから追い出されるおそれがあります。

更新を行うUAPに対してLRU管理を抑止した場合，DBへの書き込み回数が多く，ログ出力契機が頻繁に発生するため，LRU管理を抑止しない場合に比べて，出力されるログ量が多くなります。容量が不足しないように次のようにしてください。

システムログファイルの容量を再度見積もりする

ログレスモードで実行できる場合，クライアント環境定義のPDDBLOGにNOを指定する

LRU管理を抑止する場合のログ量は，次に示す計算式で求めます。なお，pd_log_rec_lengオペランドの指定値を1024にすると，LRU管理を抑止する場合に出力されるログ量を最小に抑えられます。

更新GET数※×pd_log_rec_lengオペランドの値

注※

更新GET数は，UAP統計レポートのDIDUCの値，又はUAPに関する統計情報のDIDUCの値で確認できます。

LRU管理を抑止するUAPでも，ロールバックが発生した場合はLRU管理されることがあります。LRU管理されるかどうかはロールバックのタイミングによって次のように異なります。

ロールバックのタイミング | LRU管理されるかどうか
SQLでタイミングを定義する場合 | 制御系SQLのROLLBACK文を指定して，ROLLBACK文が実行される直前のコミット時点までロールバックされるとき | LRU管理は抑止されます。
HiRDBによって自動的にロールバックされる場合 | SQL実行時に処理が続行できなくなり，HiRDBによって直前のコミット時点まで暗黙的にロールバックされるとき | LRU管理は抑止されます。
UAPの異常終了時にHiRDBによって直前のコミット時点までロールバックされるとき | LRU管理が行われます。
ディレードリランによってロールバックされるとき | LRU管理が行われます。

11.8.3　UAPがアクセスするバイナリデータのLRU管理抑止設定

サイズの大きなバイナリデータを大量にアクセスするUAPを実行する場合，バイナリデータがグローバルバッファにキャッシュされると，グローバルバッファにキャッシュされた直近の内容がメモリから追い出され，性能が一時的に低下することがあります。このとき，バイナリデータのアクセス頻度が低い場合は，バイナリデータの分岐行ページのLRU管理だけを抑止することで，性能の低下を回避できます。

なお，この設定はBINARY型のバイナリデータの場合に有効です。BLOB型のバイナリデータの場合は無効となります。

参考

LRU管理を抑止できるのはUAPからのアクセスだけです。コマンドやユティリティからのアクセスの場合は，LRU管理が行われます。ただし，次のコマンドはLRU管理が抑止されます。

プラグインが提供するコマンド

pddbst

次のどちらかの条件に該当する場合，LRU管理が抑止されます。

・-sオプションを指定しない

・-sオプションと-bオプションを指定する

pdreclaim

globalbuffer_lru文の値がnoの場合，LRU管理が抑止されます。

また，次のコマンドの場合，LRU管理は抑止できませんが，グローバルバッファにキャッシュされた直近の内容がメモリから追い出されることを回避できます。

pdload，pdrorg，pdrbal

-nオプションを指定してローカルバッファを使用すると，グローバルバッファから基本行内のデータが追い出されるのを回避できます。

pdpgbfon

-bオプションを省略すると，バイナリデータの分岐行ページをアクセスしません。

(1)　適用基準

次のすべての条件を満たす場合に適用することをお勧めします。

BINARY型や，BINARY型の属性を含む抽象データ型，XML型などのサイズの大きなバイナリデータを含む表がある場合

バイナリデータへのアクセスはまれである場合

注意事項

頻繁にバイナリデータをアクセスする場合には，適用しないでください。

(2)　適用の効果

バイナリデータが格納された分岐行はアクセス頻度に関係なく，最も古い時にアクセスしたページとしてグローバルバッファ上にキャッシュされます。そのため，分岐行ページが基本行ページより先にメモリから追い出されるようになり，基本行内のデータがメモリから追い出されなくなります。

(3)　指定方法

システム共通定義のpd_dbbuff_binary_data_lruオペランドにNを指定します。

(4)　注意事項

LRU管理を抑止した場合，UAPがアクセスするバイナリデータの分岐行ページは，アクセス頻度に関係なく，バッファ不足が発生するとメモリからの追い出し対象となります。そのため，バイナリデータの分岐行をアクセスするUAPはバッファヒット率の低下に伴う入出力回数の増加によって，レスポンス性能が低下することがあります。

UAPは1〜4面のバッファを同時に確保します。そのため，LRU管理を抑止する設定をした場合でも，UAPごとにグローバルバッファにキャッシュされているページの中で1〜4ページはキャッシュから追い出されるおそれがあります。

LRU管理を抑止した場合，バイナリデータの分岐行ページの更新を行うUAPを実行するときにDBへの書き込み回数が多く，ログ出力契機が頻繁に発生します。そのため，LRU管理を抑止しない場合に比べて，出力されるログ量が多くなります。容量が不足しないように次のようにしてください。

システムログファイルの容量を再度見積もる

ログレスモードで実行できる場合，クライアント環境定義のPDDBLOGにNOを指定する

LRU管理を抑止する場合のログ量は，次に示す計算式で求めます。なお，pd_log_rec_lengオペランドの指定値を1024にすると，LRU管理を抑止する場合に出力されるログ量を最小に抑えられます。

バイナリデータをアクセスするUAPの更新GET数※×pd_log_rec_lengオペランドの値

注※

更新GET数は，UAP統計レポートのDIDUCの値，又はUAPに関する統計情報のDIDUCの値で確認できます。

LRU管理を抑止するUAPでも，ロールバックが発生した場合はLRU管理されることがあります。LRU管理されるかどうかはロールバックのタイミングによって次のように異なります。

ロールバックのタイミング | LRU管理されるかどうか
SQLでタイミングを定義する場合 | 制御系SQLのROLLBACK文を指定して，ROLLBACK文が実行される直前のコミット時点までロールバックされるとき | LRU管理は抑止されます。
HiRDBによって自動的にロールバックされる場合 | SQL実行時に処理が続行できなくなり，HiRDBによって直前のコミット時点まで暗黙的にロールバックされるとき | LRU管理は抑止されます。
UAPの異常終了時にHiRDBによって直前のコミット時点までロールバックされるとき | LRU管理が行われます。
ディレードリランによってロールバックされるとき | LRU管理が行われます。

この機能を適用した場合，無条件にpd_dbbuff_lru_optionオペランドにMIXを仮定します。そのため，参照バッファ及び更新バッファの独立したLRUでの管理はできません。

11.9　スナップショット方式によるページアクセス

11.9.1　スナップショット方式によるページアクセスの効果と指定方法

性能向上を目的とした機能（グループ分け高速化機能など）を適用できない検索をするとき，条件に合致する行数とほぼ同数回グローバルバッファにアクセスしています。スナップショット方式では，最初のアクセス時にバッファ内の探索条件に一致するすべての行をプロセス固有メモリ上にコピーし，2回目以降の同一ページのアクセスはプロセス固有メモリ上を参照して検索結果を返します。スナップショット方式の概要を次の図に示します。

図11‒4　スナップショット方式の概要

[picture]

(1)　スナップショット方式によるアクセスの効果

最初に探索条件に一致する行をプロセス固有メモリにコピーするため，2回目以降のアクセス時に掛かる検索時間を短縮できます。また，グローバルバッファへのアクセス回数を削減し，同一グローバルバッファへのアクセスの集中を防ぎます。

(2)　指定方法

pd_pageaccess_modeオペランドにSNAPSHOT（省略値）を指定します。

(3)　指定上の考慮点

スナップショット方式を指定すると，表又はインデクスの格納RDエリアのページサイズに基づいて，動的にプロセス固有メモリが確保されます。確保されるプロセス固有メモリの計算式については，HiRDB/シングルサーバの場合「スナップショット方式指定時に必要なメモリ所要量の求め方」を参照してください。HiRDB/パラレルサーバの場合「スナップショット方式指定時に必要なメモリ所要量の求め方」を参照してください。

(4)　スナップショット方式の適用可否

検索時にスナップショット方式を適用するかどうかを次の表に示します。

適用可否が×になっている場合は，システム定義のpd_pageaccess_modeオペランドでSNAPSHOTを指定しても，スナップショット方式が適用されません。

表11‒1　検索時のスナップショット方式の適用可否

条件 | 適用可否
表 | インデクス

次のどれかに該当する

ホールダブルカーソルを使用

対象表がディクショナリ表

プラグインインデクスを使用（PLUGIN INDEX SCAN，PLUGIN KEY SCAN）

行識別子を使用（ROWID FETCH）

×

×

上記以外

テーブルスキャン（TABLE SCAN）

次の列を指定している検索

定義長256バイト以上のVARCHAR，MVARCHAR，NVARCHAR型の列

繰返し列

抽象データ型の列

LOB列

定義長256バイト以上のBINARY型の列

×

−

上記以外 | ○ | −
インデクススキャン（INDEX SCAN，MULTI COLUMNS INDEX SCAN） | システム定義にpd_indexlock_mode=KEYを指定した場合に次の条件を満たさない検索 WITHOUT LOCK NOWAIT指定の検索 LOCK TABLE前提の検索 | × | ×
WITHOUT LOCK WAIT指定の検索 | × | ×
上記以外 | × | ○
キースキャン（KEY SCAN，MULTI COLUMNS KEY SCAN） | システム定義にpd_indexlock_mode=KEYを指定した場合に次の条件を満たさない検索 WITHOUT LOCK NOWAIT指定の検索 LOCK TABLE前提の検索 | − | ×
上記以外 | − | ○

（凡例）

○：適用します。ただし，ページ内のヒット行が1件のときは適用されません。

×：適用しません。

−：条件に依存しません。又は該当しません。

11.10　グローバルバッファの先読み入力

11.10.1　グローバルバッファの先読み入力の効果と実行方法

グローバルバッファの先読み入力とは，指定した表やインデクスのデータをあらかじめグローバルバッファに読み込みしておく機能です。概要を次の図に示します。

図11‒5　グローバルバッファの先読み入力の概要

[picture]

〔説明〕

グローバルバッファの先読み入力をしない場合

HiRDB開始直後にUAPが表にアクセスする時，グローバルバッファにはデータがないため，表からデータを読み込みます（物理的な入出力が発生します）。以降，この表のデータにアクセスする時は，グローバルバッファに読み込まれているページについては表からの読み込みは発生しません。ただし，ほかのページのデータにアクセスする時は，読み込み処理が発生します。

グローバルバッファの先読み入力をする場合

あらかじめ表のデータをグローバルバッファに読み込んでいるため，表からデータを読み込まないで表にアクセスできます（物理的な入出力は発生しません）。以降，この表にアクセスする時，表からの読み込みはありません。

(1)　グローバルバッファの先読み入力の効果

指定した表やインデクスのデータを先読み入力しておくため，バッファヒット率が高くなります。HiRDB開始直後，オンライン業務開始前などに，入出力が多いと思われる表やインデクスを先読みしておくことで，高いバッファヒット率が期待できます。

(2)　実行方法

先読み入力する表やインデクスを指定し，グローバルバッファ常駐化ユティリティ（pdpgbfon）を実行します。

(3)　使用上の考慮点

グローバルバッファの面数は，先読み入力する表やインデクスが格納されているページ数より多く必要です。

グローバルバッファの面数が十分でない場合，LRU管理方式によってグローバルバッファから古いページ情報が追い出されます（システム定義のpd_dbbuff_lru_optionオペランドの値に従って，アクセスしたグローバルバッファ中の最も古いページが追い出されます）。そのため，グローバルバッファの面数が十分でない場合，pdpgbfonを実行しても意味がありません。

グローバルバッファ常駐化ユティリティ（pdpgbfon）で先読みする場合，格納ページ順の読み込みとなるため，プリフェッチ機能が有効となります。グローバルバッファを定義する場合，プリフェッチ数を指定することで実行時間の短縮が図れます。

11.11　ローカルバッファ

ローカルバッファとは，ディスク上のRDエリアに格納されているデータを入出力するためのバッファのことで，プロセス固有メモリ上に確保されます。ローカルバッファには次に示す種類があります。

インデクス用ローカルバッファ

インデクスデータの入出力に使用されるローカルバッファです。インデクス用ローカルバッファはインデクス単位に割り当てます。

データ用ローカルバッファ

データの入出力に使用されるローカルバッファです。データ用ローカルバッファはRDエリア単位に割り当てます。

ローカルバッファは，UAPごとにUAP環境定義で定義できます。UAPに専用のローカルバッファを割り当てることで，他UAPによるグローバルバッファの占有やバッファの排他処理による待ち状態を避けられます。UAP環境定義の詳細は，マニュアル「HiRDB システム定義」を参照してください。

次に示す条件をすべて満たす場合にローカルバッファを定義します。

大量のデータを検索又は更新する

アクセス対象のRDエリアがほかのUAPからアクセスされない

なお，HiRDBに常時接続するUAPはシステムへの影響（メモリの圧迫，サーバプロセスの占有など）が大きいため，ローカルバッファを定義しないでください。

11.11.1　インデクス用ローカルバッファの割り当て

データ用ローカルバッファとインデクス用ローカルバッファを分けて定義すると，データの検索とインデクスの検索を同時に実行しても互いが独立して動作します。そのため，大量データの全件検索時などでもインデクスの入出力回数を削減でき，処理時間を短縮できます。

表データとインデクスデータそれぞれにローカルバッファを割り当てた場合のインデクス用ローカルバッファの概要を次の図に示します。

図11‒6　インデクス用ローカルバッファの概要

[picture]

11.11.2　データ用ローカルバッファの割り当て

(1)　異なるページ長のRDエリアが複数ある場合

異なるページ長のRDエリアが複数ある場合は，同じか又は近いページ長のRDエリアをまとめて一つのローカルバッファに割り当てます。これによって，メモリの使用効率が良くなります。

異なるページ長のRDエリアをまとめて一つのローカルバッファに割り当てると，ページ長が最も大きいRDエリアに合わせてローカルバッファが確保されます。このため，ページ長が小さいRDエリアに対してデータページの入出力をした場合，1面のローカルバッファに使用されない領域ができることになり，メモリの使用効率が下がります。

(2)　UAPからのアクセス方法が異なるRDエリアが複数ある場合

同じページ長でも，UAPからのアクセス方法が異なるRDエリアが複数ある場合，例えば，用途が異なるRDエリア，順次処理が多くて更新が少ないRDエリア，追加や更新が多いRDエリアなどがある場合は，それぞれ異なるローカルバッファを割り当てるようにします。

11.11.3　ローカルバッファの割り当て方法

インデクス用ローカルバッファを割り当てる場合，pdlbufferオペランドの-iオプションでインデクス用のローカルバッファを割り当てるインデクスの名称（認可識別子．インデクス識別子）を指定します。

データ用ローカルバッファを割り当てる場合，pdlbufferオペランドの-rオプションでデータ用のローカルバッファを割り当てるRDエリアの名称を指定します。

ローカルバッファの定義例を次に示します。

pdlbuffer -a localbuf01 -r RDAREA01,RDAREA02 -n 1000       1
pdlbuffer -a localbuf02 -i USER01.INDX01 -n 1000           2

〔説明〕

RDエリア（RDAREA01，RDAREA02）にデータ用ローカルバッファを割り当てます。

インデクス（USER01.INDX01）にインデクス用ローカルバッファを割り当てます。

11.11.4　ローカルバッファ使用時の注意

ローカルバッファの使用時にサーバプロセスが異常終了すると，アボートコードPhb3008を出力してHiRDB（HiRDB/パラレルサーバの場合はユニット）が異常終了することがあります。サーバプロセスの異常終了時に更新ページがあると，トランザクション回復プロセスで回復処理ができないことがあります。その場合，HiRDBの再開始時に回復処理を行います。ローカルバッファを使用している場合に障害が発生したときのHiRDBの処理と対処方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

11.12　グローバルバッファの分割

11.12.1　グローバルバッファの分割の効果と指定方法

(1)　グローバルバッファの分割の効果

一つのグローバルバッファを複数のプロセスで同時に操作すると，グローバルバッファの操作でシリアライズされ，同時実行性に影響が出ます。そこで，グローバルバッファを分割することで，シリアライズする資源が分割され，同時実行性への影響を低減できます。

(2)　指定方法

pdbufferオペランドに-D 分割数を指定します。

(3)　指定上の考慮点

一つの大きなグローバルバッファにアクセス頻度の高いRDエリアを定義する場合，グローバルバッファの分割を検討してください。分割数は，10から20程度を目安に指定してください。

ただし，以下のRDエリアの場合は別々のグローバルバッファに分けて定義してください。

ページサイズの異なるRDエリア

グローバルバッファにページを常駐させたいRDエリア

統計情報及びpdbuflsコマンドでアクセス頻度を確認したいRDエリア

12　表の設計

この章では，表を設計する上で検討する項目について説明します。

12.1　表を設計するときの検討項目

HiRDBのデータベースはリレーショナルデータベースです。その論理構造である表をどのように設計するかを検討します。

まず，表を正規化しておくことが必要です。ただし，同じように正規化した表であっても，ユーザ用RDエリアへの格納の仕方などによって，表に対する処理性能が異なります。また，処理性能よりも操作性を重視する場合もあるため，期待する効果を考慮した表の設計が必要になります。表を設計するときの検討項目を次の表に示します。

表12‒1　データベースの表を設計するときの検討項目

設計作業ごとの検討項目 | 長所 | 短所 | 記載箇所
表の正規化 | 表の格納効率や処理効率が向上します。 | 表の検索時に，正規化後の表同士の結合検索が必要になる場合は，処理性能が落ちることがあります。 | 「表の正規化」を参照してください。
表の横分割 | 表の横分割の指定 | RDエリアごとの運用ができます。 HiRDB/パラレルサーバの場合は，表にアクセスする処理を複数のRDエリアにわたって並列化できるため，表に対するアクセスの高速化及び負荷の分散が図れます。 | RDエリアの数が増えます。 この表に作成するインデクスを横分割しないと，インデクスでの排他制御によって，同時実行性が低下することがあります。 | 「表の横分割」を参照してください。
キーレンジ分割 | 表のデータをどのRDエリアに格納したかが分かります。 各業務に関連する部分のデータを別々のRDエリアにまとめて格納し，RDエリアごとの運用ができます。 | キーレンジを意識しないと，RDエリアに均等に格納できません。
フレキシブルハッシュ分割※ | キーレンジを意識しなくても，データを均等にRDエリアに格納できます。 RDエリア，ハッシュ関数を変更しやすくなります。 CPU，ディスクの追加に対応できます。 | 表のデータをどのRDエリアに格納したかが分かりません。 特定のキーに偏りや重複があるとデータが均等に格納できません。 キーの一意性のチェックができません。

FIXハッシュ分割※

キー値によって,データを格納するRDエリアが一意に決定されます。

キーレンジを意識しなくても，データを均等にRDエリアに格納できます。

CPU，ディスクを追加しやすくなります。

表分割ハッシュ関数を使用したUAPを作成し，入力データをRDエリアごとに格納できます。

表にデータが格納されているとユーザ用RDエリアの追加及びハッシュ関数の変更ができません。

表のマトリクス分割 | キーレンジ分割したデータを，さらに別の列値で分割できるため，通常のキーレンジ分割よりも，SQLの高速処理，運用時間の短縮が期待できます。 キーレンジ分割とハッシュ分割の組み合わせで分割できるため，適用業務の幅が広がります。 | 通常の横分割に比べ，RDエリアを更に細分化できるため，運用や管理が複雑になります。 | 「表のマトリクス分割」を参照してください。
トリガの定義 | ある表への操作を契機として，自動的にSQL文を実行するようにできます。 | 特にありません。 | 「トリガの定義」を参照してください。
ビュー表の作成 | ほかのユーザに実表のアクセス権限を与えないで，ビュー表だけのアクセス権限を与えると，アクセス可能な実表の範囲を行又は列単位で制限できます。 複雑な問い合わせ指定をした場合に検索できるデータであらかじめビュー表を作成すると，表を参照する操作が手軽になります。 ビュー表を通して実表を参照又は更新できます。 | 特にありません。 | 「ビュー表の作成」を参照してください。
FIX属性の指定 | 行単位インタフェースを使用する場合は列数が多くてもアクセス性能を向上できます。 FIX属性の表に対する入力データにナル値を許さないように制約できます。 列数の多い表の場合はディスク所要量を削減できます。 | 特にありません。 | 「FIX属性の指定」を参照してください。
主キー（プライマリキー）の指定 | 主キーを定義した列には，一意性制約と非ナル値制約が適用されます。 | 特にありません。 | 「主キー（プライマリキー）の指定」を参照してください。

クラスタキーの指定

範囲を指定した行の検索，更新，削除などをするときやクラスタキー順の検索，更新などをするときに入出力時間を削減できます。

クラスタキーにUNIQUEを指定すると，クラスタキーの構成列の値がすべての行で重複しないように制約できます。

表を作成するときの入力データがクラスタキーの昇順又は降順に並んでいるかどうかをデータベース作成ユティリティ（pdload）で確認できます。

表を再編成するときに，アンロードした行のクラスタキーと，リロードするクラスタキーが一致しているかどうかをデータベース再編成ユティリティ（pdrorg）で確認できます。

クラスタキーを構成する列の値を更新できません。

クラスタキーを構成する列の値にナル値を挿入できません。

クラスタキーを指定した表にデータを追加するとき，追加しようとするキー値に近接するキー値を持ったページを探すためのオーバヘッドが発生します。

「クラスタキーの指定」を参照してください。

サプレスオプションの指定 | ディスク所要量を削減できます。 全件検索などの検索処理での入出力時間を削減できます。 | 特にありません。 | 「サプレスオプションの指定」を参照してください。
ノースプリットオプションの指定 | データの格納効率を向上できるため，ディスク所要量を削減できます。 | 特にありません。 | 「ノースプリットオプションの指定」を参照してください。
バイナリデータ列の指定 | 文書，画像，音声などの可変長データを指定できます。 | 特にありません。 | 「バイナリデータ列の指定」を参照してください。
文字集合の指定 | 表の列ごとに異なる文字集合の文字列データを格納できます。これによって，次のことができます。 VOS3システムからHiRDBに移行した場合に，データベースに格納していた文字データをVOS3システムの文字列データの照合順で検索，代入，比較ができます。 UTF-16で文字データの検索，代入，比較ができます。 | 特にありません。 | 「文字集合の指定」を参照してください。
WITHOUT ROLLBACKオプションの指定 | 採番業務で使用する表を定義する場合，表に対する更新処理完了を契機に更新行に対する排他が解除されるため，排他待ちの発生を削減できます。 | 特にありません。 | 「WITHOUT ROLLBACKオプションの指定」を参照してください。
改竄防止機能の指定 | 表データを誤って，又は不当に更新されることを防止できます。 | 改竄防止表があるRDエリアに対して使用できない機能や，SQL，ユティリティ，コマンドの実行に制限があります。 | 「改竄防止機能の指定」を参照してください。
繰返し列を含む表 | 複数の表の結合が不要になります。 重複する情報がなくなるため，ディスク容量を削減できます。 関連データ（繰返しデータ）が近くに格納されるため，別の表にするよりもアクセス性能が優れています。 | 特にありません。 | 「繰返し列を含む表」を参照してください。
抽象データ型を含む表 | 複雑な構造のデータを表に格納して，通常の表データと同様に操作できます。 | 特にありません。 | 「抽象データ型を含む表」を参照してください。
共用表 | 複数バックエンドサーバ間の接続やデータ転送によるオーバヘッドが削減できます。 トランザクションの多重実行時など，並列処理の効率が上がります。 | 共用表を更新する場合，全バックエンドサーバで，更新する共用表があるRDエリアに排他を掛けるので，共用RDエリアのほかの表にアクセスする業務があると，デッドロックが発生することがあります。 | 「共用表」を参照してください。
参照制約 | 複数の表間のデータの整合性チェック，及びデータ操作を自動化できます。 | 被参照表や参照表を更新する場合，データの整合性をチェックするため，チェックに掛かる処理時間が増加します。 | 「参照制約」を参照してください。
検査制約 | データの追加又は更新時のチェックを自動化できます。 | 検査制約が定義された表を更新する場合，データの整合性をチェックするため，チェックに掛かる処理時間が増加します。 | 「検査制約」を参照してください。
圧縮表 | 表データの格納効率が向上し，データベースの容量を削減できます。 HiRDBがデータ圧縮をするため，UAP開発時にデータ圧縮処理が不要になります。 | 圧縮列のデータをSQLやユティリティで操作する場合，圧縮処理や伸張処理のオーバヘッドが掛かります。 | 「圧縮表」を参照してください。
一時表 | トランザクション又はSQLセッションごとに専用の表を作成するため，ほかのユーザの影響を受けないで処理できます。 一時表に中間処理結果を格納してさらに加工して最終的な結果を得るなど，複雑な処理ができます。 一時表は自動的に削除されるため，後処理が不要です。 | HiRDB開始時，又は一時表に最初にINSERT文が実行された時に，一時表用RDエリアを初期化するオーバヘッドが発生します。 | 「一時表」を参照してください。

注※

次に示す場合は，ハッシュ分割表のリバランス機能を使用することをお勧めします。

表をハッシュ分割する場合

データ量の増加が見込まれる場合

ハッシュ分割表のデータ量が増加したためRDエリアを追加すると（表の横分割数を増やすと），既存のRDエリアと新規追加したRDエリアとの間でデータ量の偏りが生じます。ハッシュ分割表のリバランス機能を使用すると，表の横分割数を増やすときにデータ量の偏りを修正できます。ハッシュ分割表のリバランス機能については，マニュアル「HiRDB システム運用ガイド」を参照してください。

12.2　表の正規化

12.2.1　表の正規化の概要

表を正規化することは，表の格納効率や処理効率の向上を図る上で重要です。表を正規化する際は，表の構成列を検討します。ここでは，次に示す正規化について説明します。

表の格納効率を向上させる正規化

表の処理効率を向上させる正規化

(1)　表の格納効率を向上させる正規化

一つの表に同じような情報を持つ列が複数ある場合は，この表を複数の表に分けて，それぞれの表に同じような情報を持つ列がなくなるように正規化します。これによって，表に対するデータの格納効率が良くなります。これを次の図の例で説明します。

図12‒1　表に同じような情報を持つ列が複数ある場合

[picture]

〔説明〕

正規化前のZAIKO表のSCODEの列とSNAMEの列は1対1で対応し，それぞれの列の情報は冗長になっています。このような場合は，ZAIKO表から，SCODEの列とSNAMEの列で構成されるSHOHIN表をほかに作成します。このとき，SHOHIN表では，SCODEの列とSNAMEの列に重複した情報を持たないようにします。

(2)　表の処理効率を向上させる正規化

(a)　複数の業務で同一の表を使用する場合

複数の業務で同一の表を使用する場合は，それぞれの業務で使用する列によって，この表を業務ごとの表に正規化します。これによって，それぞれの表に対する同時実行性が向上します。これを次の図の例で説明します。

図12‒2　複数の業務で同一の表を使用する場合

[picture]

〔説明〕

正規化前のSKANRI表（商品管理表）を在庫管理業務と受注管理業務で使用しています。このような場合は，SKANRI表を在庫管理業務だけで使用するZAIKO表と，受注管理業務だけで使用するJUTYU表に正規化します。

(b)　アクセス頻度の高い列と低い列がある場合

一つの表に，アクセス頻度が高いと考えられる列と低いと考えられる列がある場合は，この表をアクセス頻度が高い列で構成した表と，アクセス頻度が低い列で構成した表に正規化します。これを次の図の例で説明します。

図12‒3　アクセス頻度の高い列と低い列がある場合

[picture]

〔説明〕

正規化前のZAIKO表を検索する場合，SNO及びSURYOの列と，SNAME及びTANKAの列の間で，検索頻度の比率が9：1であるとします。このような場合は，ZAIKO表を検索頻度の高い列の集まり（ZAIKO2表）と検索頻度の低い列の集まり（SHOHIN表）の二つの表に正規化します。

例えば，ZAIKO表を全件検索するのに，10000回の物理的な入出力が必要であるとします。ZAIKO表をZAIKO2表とSHOHIN表に分割したことで，ZAIKO2表の検索が4500回（=5000×0.9），SHOHIN表の検索が500回（=5000×0.1），合計5000回の物理的な入出力で済むことになり，全体としての表の処理効率が向上します。

12.3　表の横分割

ここでは，表の横分割の設計方法について説明します。

12.3.1　表の横分割の概要

一つの表を複数のユーザ用RDエリアに分割して格納することを表の横分割といいます。また，横分割した表を横分割表といいます。なお，表を横分割するRDエリアは，それぞれ異なるディスクに配置することを原則とします。

(1)　適用基準

次に示す場合に表を横分割することをお勧めします。

データ量が多い場合

特定の時間帯にアクセスが集中する場合

表の分割単位でユーザ用RDエリアの運用（表へのデータの格納，表の再編成，バックアップの取得など）をする場合

(2)　定義方法

定義系SQLのCREATE TABLEで定義します。定義例は「横分割表の作成」を参照してください。

12.3.2　表の横分割の種類

表を横分割する方法には，次に示す2種類があります。

キーレンジ分割

ハッシュ分割（フレキシブルハッシュ分割，FIXハッシュ分割）

(1)　キーレンジ分割

キーレンジ分割とは，表を構成する列のうち，特定の列が持つ値の範囲を条件として表を横分割することです。なお，表を横分割するときの条件にした特定の列を分割キーといいます。表のデータがどのRDエリアに格納されているかどうかを意識したい場合に使用します。横分割の指定方法には，次に示す2種類があります。

(a)　格納条件指定

比較演算子を使用して，それぞれのRDエリアへの格納条件を指定します。一つのRDエリアに対して，格納条件で指定された一つの範囲だけを指定できます。

(b)　境界値指定

定数を使用して，それぞれのRDエリアに格納するデータの，境界となる値を指定します。一つのRDエリアに対して，境界値で区切られた複数の範囲を指定できます。なお，境界値指定の場合，マトリクス分割もできます。マトリクス分割については，「表のマトリクス分割」を参照してください。

(2)　ハッシュ分割

ハッシュ分割とは，表を構成する列が持つ値をハッシュ関数を使用して，均等にRDエリアに格納し，表を横分割することです。表を横分割するときに指定した特定の列を分割キーといいます。キーの範囲を意識しないで，表のデータをRDエリアに均等に格納したい場合に使用します。ハッシュ分割は，境界値指定のキーレンジ分割と組み合わせてマトリクス分割ができます。マトリクス分割については，「表のマトリクス分割」を参照してください。

ハッシュ分割にはフレキシブルハッシュ分割とFIXハッシュ分割があります。

フレキシブルハッシュ分割では，表を分割してRDエリアに格納する場合，どのRDエリアに分割されるか定まりません。このため，検索処理では，該当する表があるすべてのバックエンドサーバが対象になります。

FIXハッシュ分割では，表がどのRDエリアに分割されたかをHiRDBが認識します。このため，検索処理では，該当するデータがあると予測されるバックエンドサーバだけが対象になります。

(a)　分割キーの選択方法

分割キーには次に示すようなキーを指定してください。

キー値の偏りが少ない

キーの値に重複が少ない

また，ハッシュ分割では，分割キーに単一列と複数列が選択できます。単一列を指定した場合，分割列のキー値の種類が少なかったり，キー値に偏りがあるとデータを均等に分割できないことがあります。この場合，分割する列名を複数指定して，データをRDエリアに均等に分割させるようにします。

(b)　ハッシュ関数の種類

ハッシュ分割で使用するハッシュ関数には，次のものがあります。

HASH0

HASH1

HASH2

HASH3

HASH4

HASH5

HASH6

HASHA

HASHB

HASHC

HASHD

HASHE

HASHF

HASHZ

リバランス表でない場合，又はマトリクス分割表の第2次元にハッシュ関数を指定する場合

HASH0〜HASH6又はHASHZのどれかを指定してください。HASH6が最も均等にハッシングされるので，通常はHASH6を指定してください。ただし，分割キーのデータによっては均等にならない場合もあるので，そのときにはほかのハッシュ関数を指定してください。

リバランス表の場合

HASHA〜HASHFのどれかを指定してください。HASHFが最も均等にハッシングされるので，通常はHASHFを指定してください。ただし，分割キーのデータによっては均等にならない場合もあるので，そのときにはほかのハッシュ関数を指定してください。

各ハッシュ関数の詳細については，マニュアル「HiRDB SQLリファレンス」の「CREATE TABLE（表定義）」の「オペランド」のハッシュ関数名の説明を参照してください。

(c)　ハッシュ関数の選択方法

実際にデータベースにデータを格納して選択する方法

この場合のハッシュ関数の選択手順を次に示します。

分割キーに対応して有効なハッシュ関数を指定します。

データベース状態解析ユティリティ（pddbst）でRDエリアごとに格納されている行数を確認します。

RDエリアごとに格納している行数に偏りがある場合には，ハッシュ関数を変更し，RDエリアごとの格納行数が均等になるようにします。

3.の方法で格納行数が均等にならない場合は，格納行数の少ないRDエリアを重複して指定することで，格納行数が均等になるようにします。この場合の例を次の図に示します。

図12‒4　ハッシュ分割で表格納用RDエリアを重複指定する例

[picture]

表分割ハッシュ関数を使用したUAPを作成し，ハッシュ関数を選択する方法

この場合のハッシュ関数の選択手順を次に示します。

HiRDBからライブラリとして提供されている，表分割ハッシュ関数（分割キーのデータ値を入力すると分割条件指定順序を出力する関数）を使用して，RDエリアごとのデータ件数の偏りを求めるUAPを作成します。

ハッシュ関数ごとに，表分割ハッシュ関数が出力する分割条件指定順序ごとの件数を求め，最も偏りが少ないハッシュ関数を選択します。

表分割ハッシュ関数を使用したUAPの作成方法については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(d)　ハッシュ関数が使用されるタイミング

ハッシュ関数は次に示すときに使用されます。

表単位のデータロード時

データの追加時

表単位のデータのリロード時

(3)　キーレンジ分割，フレキシブルハッシュ分割及びFIXハッシュ分割の相違点

キーレンジ分割，フレキシブルハッシュ分割及びFIXハッシュ分割の相違点を次の表に示します。

表12‒2　キーレンジ分割，フレキシブルハッシュ分割及びFIXハッシュ分割の相違点

相違点 | キーレンジ分割 | フレキシブル ハッシュ分割 | FIXハッシュ分割
データベース設計 | キーレンジを考慮して，データベースを設計する必要があります。 | キーレンジを考慮しないでデータベースを設計できます。 | キーレンジを考慮しないでデータベースを設計できます。

検索

検索条件によって，該当データが存在する可能性のあるバックエンドサーバだけ検索します。※1

対象表のある全バックエンドサーバで検索します。

分割列に対して次に示す探索条件を指定した場合に，該当データが存在する可能性のあるRDエリアだけ検索します。※1

ハッシュ関数にHASH1〜HASH6，HASHA〜HASHFを指定した場合

比較述語（=）

IN述語

ハッシュ関数にHASH0，HASHZを指定した場合

比較述語（=）

IN述語

比較述語（<，>，<=，>=）による範囲条件

BETWEEN述語

（前方一致比較の）LIKE述語

（前方一致比較の）SIMILAR述語

データ増加時の 対応 | キーが増加するデータの場合，データの格納が特定のRDエリアに偏ります。 | データが増加しても，常に均等にRDエリアに格納されます。 | データが増加しても，常に均等にRDエリアに格納されます。
RDエリア閉塞時の運用 | 閉塞しているRDエリアをアクセスしない検索条件であればSQLを実行できます。※2 | 検索する表が格納されているRDエリアを一つでも閉塞すると，検索条件にかかわらずSQLを実行できません。 | 閉塞しているRDエリアをアクセスしない検索条件であればSQLを実行できます。※2
表の分割数の変更 | 表の再作成及び表の再編成が必要です。 | ALTER TABLEでRDエリアを追加でき，表の再編成は必須ではありません。 | 表の再作成及び表の再編成が必要です。ただし，表にデータが入っていないときだけALTER TABLEでRDエリアを追加できます。
RDエリア単位のデータロード・リロード | 該当するRDエリアに格納するデータかどうかをチェックします。 | 該当するRDエリアに格納するデータかどうかをチェックしません。 | 該当するRDエリアに格納するデータかどうかをチェックします。
データロード時のRDエリア単位による入力データファイルの作成方法 | キーレンジを考慮して，入力データをRDエリアごとに分類します。 | RDエリアごとのデータ件数が均等になるように，任意の方法で分類します。 | 表分割ハッシュ関数※3を使用したアプリケーションを作成し，入力データをRDエリアごとに分類します。
分割キーの更新 | 同値更新だけできます。 | 更新できます。 | 同値更新だけできます。
クラスタキーのUNIQUE定義及びUNIQUE指定のインデクス定義 | UNIQUEを指定できます。 | UNIQUEを指定できません。 | UNIQUEを指定できます。
ALTER TABLEによる分割格納条件の変更 | 次の分割方法の場合に変更できます。 境界値指定 格納条件指定（格納条件の比較演算子に=だけを使用している場合） | 変更できません。ただし，ALTER TABLEでRDエリアの追加はできます。 | 変更できません。ただし，ALTER TABLEでRDエリアの追加はできます。

注※1

ASSIGN LIST文の場合，検索条件に該当しないバックエンドサーバにも負荷が掛かります。

注※2

ASSIGN LIST文の場合，表全体が閉塞扱いになります。

注※3

表分割ハッシュ関数を使用したUAPの作成方法については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(4)　表の横分割定義時の指定規則

表の横分割定義時の指定規則を次に示します。

キーレンジ分割の場合

指定できる分割キー※１は1個です。分割キーの更新はできません。

格納条件指定※２の場合，同じRDエリアを複数指定できません。境界値指定※３の場合，同じRDエリアを複数指定できますが，連続して同じRDエリアを指定することはできません。

ハッシュ分割の場合

指定できる分割キー※１は最大16個です。ただし，同じ分割キーを重複して指定することはできません。フレキシブルハッシュ分割は，分割キーの更新ができますが，FIXハッシュ分割は分割キーの更新はできません。

注※１

次のデータ型の列及び繰返し列は，分割キーに指定できません。

定義長が256バイト以上のCHAR，VARCHAR，MCHAR，MVARCHAR型

定義長が28文字以上のNCHAR，NVARCHAR型

BLOB型

BINARY型

抽象データ型

既定値にCURRENT_TIMESTAMP USING BESを指定したTIMESTAMP型

注※２

格納条件を複数指定した場合，格納条件の指定順に条件を評価し，最初に真となった格納条件に指定したRDエリアに格納します。すべての条件で真とならない場合，格納条件を指定していないRDエリアに格納します。ただし，格納条件を指定していないRDエリアがない場合，どのRDエリアにも格納されません。また，条件を評価した結果，行が1行も格納されないRDエリアがある指定の表定義はできません。

注※３

境界値には定数を指定します。ただし，長さが0の文字列定数は指定できません。境界値を複数指定する場合，昇順となるように指定してください。また，境界値を指定しないRDエリアを最後に必ず指定してください。

(5)　キーレンジ分割（格納条件指定）の例

キーレンジ分割（格納条件指定）の例を次の図に示します。

図12‒5　キーレンジ分割（格納条件指定）の例

[picture]

〔説明〕

ZAIKO表の商品コード列（SCODE）の範囲（100L〜399Sと400L〜699S）を条件として，複数のユーザ用RDエリア（USR01とUSR02）に横分割します。

(6)　キーレンジ分割（境界値指定）の例

キーレンジ分割（境界値指定）の例を次の図に示します。

図12‒6　キーレンジ分割（境界値指定）の例

[picture]

〔説明〕

ZAIKO表の商品コード列（SCODE）の302S，591Sを境界値として，複数のユーザ用RDエリア（USR01とUSR02）に横分割します。

(7)　フレキシブルハッシュ分割及びFIXハッシュ分割の例

フレキシブルハッシュ分割，FIXハッシュ分割の例を次の図に示します。

図12‒7　フレキシブルハッシュ分割，FIXハッシュ分割の例

[picture]

〔説明〕

ZAIKO表の商品コード列（SCODE）を分割キーとして，ハッシュ関数HASH6を使用して複数のユーザ用RDエリア（USR01とUSR02）に横分割します。

なお，実際のデータの格納先RDエリアはこの例と異なることがあります。

12.3.3　表の横分割の形態

表の横分割の基本的な形態には，次に示す2種類があります。

サーバ内の横分割（HiRDB/シングルサーバでの形態）

サーバ間の横分割（HiRDB/パラレルサーバでの形態）

それぞれの形態を次の図に示します。

図12‒8　表の横分割の形態（HiRDB/シングルサーバの場合）

[picture]

図12‒9　表の横分割の形態（HiRDB/パラレルサーバの場合）

[picture]

12.3.4　表の横分割の効果

表を横分割して得られる効果を次に示します。

(1)　HiRDB/シングルサーバの場合

操作性の向上

ユーザ用RDエリアごとに，表へのデータの格納，表の再編成，バックアップの取得などの運用ができます。

キーレンジ分割の場合

ディクショナリ表のSQL_DIV_TABLE表を検索することで，表のデータをどのユーザ用RDエリアに格納したかが分かります。このため，ユーザ用RDエリアに障害が発生した場合に，どのデータが利用できないかが分かります。なお，ディクショナリ表の検索方法とSQL_DIV_TABLE表については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(2)　HiRDB/パラレルサーバの場合

性能の向上

表にアクセスする処理を複数のユーザ用RDエリアにわたって並列化できるため，表に対するアクセスの高速化が図れます。

表にアクセスする処理の負荷を複数のバックエンドサーバに分散できます。

操作性の向上

効果はHiRDB/シングルサーバの場合と同様です。

12.3.5　設計上の考慮点

(1)　HiRDB/シングルサーバとHiRDB/パラレルサーバでの共通の考慮点

HiRDB/シングルサーバとHiRDB/パラレルサーバでの共通の考慮点を次に示します。

(a)　ディスクに対するアクセスの競合を考慮した横分割

複数のUAPがそれぞれ別々の表に同時にアクセスする場合は，これらの表をそれぞれ異なるディスク上の異なるユーザ用RDエリアにわたって横分割します。ディスクに対するアクセスの競合を考慮した横分割の概要を次の図に示します。

図12‒10　ディスクに対するアクセスの競合を考慮した横分割の概要

[picture]

〔説明〕

表Aと表Bをそれぞれ異なるディスク上のユーザ用RDエリアUSR01〜USR02とUSR03〜USR04にわたって横分割しています。このため，UAP1とUAP2が同時に表Aと表Bにアクセスしても，ディスクに対するアクセスの競合による待ちが発生しないため，待ち時間を短くできます。

しかし，一つのディスク上のユーザ用RDエリアに複数の表を格納した場合，これらの表に対して複数のUAPが同時にアクセスすると，ディスクに対するアクセスの競合が発生します。このため，この表にアクセスできた一つのUAPのアクセスが終了するまで，ほかのUAPが待たされることになり，待ち時間が長くなります。

(b)　操作性を考慮した横分割

操作性を考慮した横分割の概要を次の図を基に説明します。

図12‒11　操作性を考慮した横分割の概要

[picture]

〔説明〕

表とインデクスの同一ユーザ用RDエリアへの格納

検索性能よりはむしろ，表の作成，表の再編成，ユーザ用RDエリアのバックアップの取得，RDエリアの回復などの運用の操作性を重視する場合は，横分割した表とそれに対応するインデクスを同じユーザ用RDエリアに格納します。これによって，ユーザ用RDエリアごとの独立した運用が便利になります。

図「操作性を考慮した横分割の概要」の例では，表ABのうち，業務Aに関係する部分の表とインデクスを専用のユーザ用RDエリアUSR01にまとめて格納しています。これによって，例えば，業務Aを停止する場合は，pdholdコマンド（RDエリアの閉塞）で運用できます。また，データベース複写ユティリティ（pdcopy）を使用した業務単位でのバックアップが取得しやすくなります。

関連するユーザ用RDエリアの同一ディスクへの配置

横分割した表とそれに対応するインデクスをそれぞれ異なるユーザ用RDエリアに格納する場合は，これらの互いに関連するユーザ用RDエリアを同一のディスクに配置します。これによって，ディスクごとに独立したユーザ用RDエリアの運用ができます。

図「操作性を考慮した横分割の概要」の例では，表CDのうち，業務Dに関係する部分の表とインデクスをそれぞれ格納したユーザ用RDエリアUSR04とUSR06を同一のディスクに配置しています。これによって，ディスクごとに業務の運用ができます。

(2)　HiRDB/パラレルサーバ固有の考慮点

HiRDB/パラレルサーバ固有の考慮点を次に示します。

(a)　ディスクに対するアクセスの負荷を考慮した横分割

複数のバックエンドサーバにわたる横分割

一つのバックエンドサーバのディスクに複数のユーザ用RDエリアを配置したとき，それぞれのユーザ用RDエリアに格納された表のアクセス頻度がどれも高い場合，このバックエンドサーバでのディスクに対するアクセスの負荷が高くなります。

このため，アクセス頻度の高い表は，複数のバックエンドサーバの異なるディスク上のユーザ用RDエリアにわたって横分割します。このとき，それぞれのバックエンドサーバでの表に対するアクセス頻度が均等になるようにします。

複数のサーバマシンにわたるディスクアクセスの並列化

あるサーバマシンの一つのバックエンドサーバのユーザ用RDエリアに格納された表に対する処理が，入出力が主体でCPUの負荷が低い場合，ディスクに対するアクセスの負荷が複数のサーバマシンにわたって均等にならないため，並列処理の効率が下がります。

このため，サーバマシン内のCPUビジー率に余裕がある場合は，このサーバマシンに更にバックエンドサーバとユーザ用RDエリアを配置して，ディスクに対するアクセスの並列度を向上させるようにします。

(b)　入出力処理の並列度を考慮した横分割

表をできるだけ多くのサーバマシンにわたって横分割すると，並列処理によって表に対する入出力処理時間が短縮できます。横分割できるサーバマシン数に限界があれば，各サーバマシンにバックエンドサーバとディスクを増やして表を横分割することで，入出力処理の並列効果が得られます。表を横分割するバックエンドサーバの数に伴う入出力処理性能の概要を次の図に示します。

図12‒12　表を横分割するバックエンドサーバの数に伴う入出力処理性能の概要

[picture]

ただし，表を横分割するバックエンドサーバの数が多過ぎると，各バックエンドサーバでの処理結果をフロントエンドサーバに返すための通信量が増加します。このため，データベースの運用やSQL処理（容量の大きい表から大量のデータを検索するSQL処理かどうか）を考慮して，表を横分割するバックエンドサーバの数を決定する必要があります。

(c)　表に対するアクセス頻度を考慮した横分割

それぞれのバックエンドサーバでの表に対するアクセス頻度が均等になるように表を横分割します。

アクセス頻度を均等にするための考慮点を次に示します。

キーレンジ分割の場合

表の横分割を定義する場合に，分割キーにUNIQUEを指定して，データ量が均等になるようにします。

表を横分割する場合に，あるキーレンジのデータに対するアクセス回数が，ほかのキーレンジのデータに対するアクセス回数よりも多いと予想できるときは，アクセス回数が多いと予想できるキーレンジのデータを更にキーレンジで分割します。

フレキシブルハッシュ分割，FIXハッシュ分割の場合

ハッシュ関数を変更して，データ量が均等になるように調整します。

分割キーに偏りや重複がないものを選択して，データ量が均等になるように調整します。

複数のバックエンドサーバにわたって表を横分割する場合でも，表に対するアクセス頻度が均等になるように横分割した場合と，均等にならないように横分割した場合とでは，表に対する並列処理の性能に差が生じます。表に対するアクセス頻度の違いによる並列処理性能の違いを次の図に示します。

図12‒13　表に対するアクセス頻度の違いに伴う並列処理性能の違い

[picture]

〔説明〕

アクセス頻度が均等になるように表を横分割した場合と，均等にならないように表を横分割した場合とでは，削減できる処理時間が異なります。均等にならないように表を横分割した場合は，バックエンドサーバBES2での処理が終了するまで，表に対する処理は終了しないため，並列処理の効果が得られません。

(d)　複雑な検索処理を考慮した横分割

大量のデータの検索や結合処理をするなど，複雑な検索処理を考慮した表の横分割をする場合，次に示す手順で設計します。

ディスクに対する処理時間とディスクの台数の決定

データの規模と処理のパターンから，ディスクへのアクセス頻度（利用率）を求め，これを基にデータをディスクに配分して，ディスクに対する処理時間の目標値を決めます。なお，結合処理をする場合は，結合処理に必要なワークディスク（ソートマージ用に使用する作業表用ファイルを作成するHiRDBファイルシステム領域の数）を除いてデータを配分します。結合処理に必要な時間は，ディスクに対する処理時間の目標値から除きます。ディスクへのデータ配分から，ディスクの台数を決定します。

サーバマシンの台数の決定

データの処理パターンから，サーバマシンでの処理のオーバヘッド時間を求めます。ディスクに対する処理時間とサーバマシンでのオーバヘッド時間が，それぞれ均等になるようにサーバマシンの台数（バックエンドサーバを配置するサーバマシンの台数）を決定します。

結合処理をするサーバマシンの台数の決定

データの処理パターンから，結合処理をするときに掛かるサーバマシンでのオーバヘッド時間を求めます。この時間とディスクに対する処理時間を基に，必要とするフロータブルマシンの台数を決定します。

フロータブルマシンとは，結合処理のような複雑な検索処理をするための専用のバックエンドサーバ（フロータブルサーバ）を配置するサーバマシンのことです。フロータブルサーバとするバックエンドサーバは，ユーザ用RDエリアを割り当てないバックエンドサーバとして定義します。

ワークディスクの台数の決定

フロータブルマシンには，結合処理の対象となるデータが各バックエンドサーバから均等に分配されます。このときに予想されるデータ量を基に，ワークディスク（作業表用ファイルを作成するHiRDBファイルシステム領域）の台数を求めます。

システム構成の決定

以上で決定したサーバマシンとディスクの台数から，システム全体の構成を決定します。

以上の手順で設計した，複雑な検索処理を考慮した横分割のシステム構成の概念を次の図に示します。

図12‒14　複雑な検索処理を考慮した横分割のシステム構成

[picture]

〔説明〕

バックエンドサーバBES1〜BES3とバックエンドサーバBES4〜BES6が，それぞれ表Aと表Bから結合処理の対象となるデータを読み出します。フロータブルサーバBES7〜BES9は，バックエンドサーバBES1〜BES6が読み出したデータを受け取り，並列に突き合わせる処理をします。

このようなシステム構成にすることで，バックエンドサーバBES1〜BES6での負荷を軽減でき，処理時間を短縮できます。なお，フロータブルサーバを配置しなかった場合は，フロータブルサーバで実行していた結合処理をバックエンドサーバBES1〜BES6のどれかが実行することになります。

12.3.6　表を横分割する場合の注意

表を横分割した場合は，この表に作成するインデクスも横分割してください。インデクスを一つのユーザ用RDエリアに格納して，表を横分割して運用すると，インデクスでの排他制御によって，同時実行性が低下することがあります。インデクスの横分割については，「インデクスの横分割」を参照してください。

次に示す場合は，ハッシュ分割表のリバランス機能を使用することをお勧めします。

表をハッシュ分割する場合

データ量の増加が見込まれる場合

ハッシュ分割表のデータ量が増加したためRDエリアを追加すると（表の横分割数を増やすと），既存のRDエリアと新規追加したRDエリアとの間でデータ量の偏りが生じます。ハッシュ分割表のリバランス機能を使用すると，表の横分割数を増やすときにデータ量の偏りを修正できます。ハッシュ分割表のリバランス機能については，マニュアル「HiRDB システム運用ガイド」を参照してください。

12.4　表のマトリクス分割

12.4.1　表のマトリクス分割の効果と定義方法

表の二つの列を分割キーとして，分割方法の指定を組み合わせて分割することをマトリクス分割といいます。一つ目の分割キーとなる列を第1次元分割列，二つ目の分割キーとなる列を第2次元分割列といいます。マトリクス分割は，第1次元分割列で境界値指定のキーレンジ分割をし，分割されたデータをさらに第2次元分割列で分割します。第2次元分割列に指定できる分割方法を次に示します。

境界値指定のキーレンジ分割

フレキシブルハッシュ分割※

FIXハッシュ分割※

注※　

指定できるハッシュ関数はHASH0〜HASH6とHASHZです。HASHA〜HASHFは指定できません。

マトリクス分割によって分割された表をマトリクス分割表といいます。

なお，表をマトリクス分割するためには，HiRDB Advanced High Availabilityが必要です。

(1)　表のマトリクス分割の効果

複数の列を分割キーとして分割することで得られる効果を次に示します。

SQL処理の高速化

SQLの処理を並列に実行したり，複数のキーによる検索で検索範囲を絞り込んで高速に処理したりできます。

運用時間の短縮

より細かな分割ができるため，1RDエリアの大きさを小さくして，再編成，バックアップの取得，障害発生時の回復作業などに要する時間を短縮できます。

(2)　適用基準

次の場合，境界値指定のキーレンジ分割の組み合わせをお勧めします。

第1次元分割列による分割では，各境界値に該当するデータ量が多大となる

表にアクセスするUAPで指定できる探索条件に指定する列が複数あり，複数の列でアクセスするRDエリアを限定したい，又は一つのSQL文中でn番目に指定した列だけでアクセスするRDエリアを限定したい

次の場合，境界値指定のキーレンジ分割とハッシュ分割の組み合わせをお勧めします。

第1次元分割列による分割では，各境界値に該当するデータ量が多大となる

第1次元分割列で分割された範囲のデータを，均等に細分化して格納したい

次の場合，境界値指定のキーレンジ分割とハッシュ分割の組み合わせで，ハッシュ分割に指定するRDエリア名を重複指定することをお勧めします。同じRDエリア名を重複指定することによって，分割数はそのままで，実際に使用するRDエリア数を減らすことができます。また，各RDエリアに格納するデータ量も均等にできます。RDエリア名を重複指定する場合については，図「ハッシュ分割で表格納用RDエリアを重複指定する例」を参照してください。

1RDエリアのサイズを一定にすることで各RDエリアの再編成処理の時間を一定にしたいが，第1次元分割列の境界値による分割ではデータ量を均等に分ける境界値の指定が難しいため，一定にできない

分割数が検索時の性能に影響しているため，分割数を減らしたい

(3)　定義方法

定義系SQLのCREATE TABLEのPARTITIONED BY MULTIDIMオペランドで次の指定をします。

RDエリアへの表の割り当て

マトリクス分割の方法（分割キー，分割方法）

定義時の規則を次に示します。

第2次元分割列が境界値指定のキーレンジ分割の場合

分割キーの指定可能数は2（第1次元分割列の分割キー＋第2次元分割列の分割キー）です。第1次元分割列と第2次元分割列で同じ分割キーは指定できません。

第2次元分割列がハッシュ分割の場合

分割キーの指定可能数は2〜16です。フレキシブルハッシュ分割のとき，第2次元分割列の分割キーだけは更新できます。FIXハッシュ分割のとき，分割キーの更新はできません。

定義例は「マトリクス分割の例」を参照してください。

(4)　マトリクス分割の例

(a)　境界値指定のキーレンジ分割の組み合わせの場合

顧客表の登録日及び店番号に境界値を指定し，登録日と店番号によって，表をマトリクス分割します。それぞれの顧客データを次のようにユーザ用RDエリア（USR01〜USR06）に格納します。格納するのに必要なユーザ用RDエリア数は，（境界値数＋1）×（境界値数＋1）なので，この例の場合，3×2＝6です。

登録日 | 店番号
100以下 | 100より大きい
2000年以前 | USR01 | USR02
2001年 | USR03 | USR04
2002年以降 | USR05 | USR06

マトリクス分割する表を定義するSQL文を次に示します。

CREATE FIX TABLE 顧客表
  (登録日 DATE, 店番号 INT, 顧客名 NCHAR(10))
  PARTITIONED BY MULTIDIM(
  登録日 (('2000-12-31'),('2001-12-31')), …1.
  店番号 ((100))                          …2.
  )IN ((USR01,USR02),(USR03,USR04),(USR05,USR06))

〔説明〕

第1次元分割列名（一つ目の分割キーとなる列名）と，その境界値リストを指定します。

第2次元分割列名（二つ目の分割キーとなる列名）と，その境界値リストを指定します。

マトリクス分割の例を次の図に示します。

図12‒15　マトリクス分割の例（境界値指定のキーレンジ分割の組み合わせ）

[picture]

(b)　境界値指定のキーレンジ分割とハッシュ分割の組み合わせの場合

第2次元分割列でFIXハッシュ分割する場合の例について説明します。

顧客表の登録日に境界値を指定し，店番号と地域コードをハッシュ関数で三分割することによって，表をマトリクス分割します。それぞれの顧客データを次のようにユーザ用RDエリア（USR01〜USR09）に格納します。格納するのに必要なユーザ用RDエリア数は，（境界値数＋1）×（ハッシュ関数で分割するユーザ任意の数）なので，この例の場合，3×3＝9です。

登録日 | 店番号と地域コード（ハッシュ関数で三分割）
2002年以前 | USR01 | USR02 | USR03
2003年 | USR04 | USR05 | USR06
2004年以降 | USR07 | USR08 | USR09

マトリクス分割する表を定義するSQL文を次に示します。

CREATE FIX TABLE 顧客表
  (登録日 DATE, 店番号 INT, 地域コード INT, 顧客名 NCHAR(10))
  PARTITIONED BY MULTIDIM
  (登録日 (('2002-12-31'),('2003-12-31')), …1.
  FIX HASH HASH6 BY 店番号, 地域コード     …2.
  )IN ((USR01,USR02,USR03),
       (USR04,USR05,USR06),
       (USR07,USR08,USR09))

〔説明〕

第1次元分割列名（一つ目の分割キーとなる列名）と，その境界値リストを指定します。

第2次元列分割名（二つ目の分割キーとなる列名）と，ハッシュ関数名を指定します。

マトリクス分割の例を次の図に示します。

図12‒16　マトリクス分割の例（境界値指定のキーレンジ分割とハッシュ分割の組み合わせ）

[picture]

12.5　トリガの定義

トリガを定義すると，ある表への操作（更新，挿入，及び削除）を契機に自動的にSQL文を実行させることができます。トリガは，定義する表，トリガを動作させる契機となるSQL（トリガ契機となるSQL），自動的に実行させるSQL文（トリガSQL文），その動作が実行される条件（トリガ動作の探索条件）などを指定して定義します。トリガを定義した表にトリガ動作の探索条件を満たすSQL文が実行されると，トリガSQL文が自動的に実行されます。トリガの概要を次の図に示します。

図12‒17　トリガの概要

[picture]

〔説明〕

UAPからトリガ契機となるSQLが実行されると，トリガを定義した表Aでトリガが呼び出され，トリガ動作の探索条件を満たしている場合，自動的にトリガSQL文（この場合，表Bへの行の挿入や表Cへの行の更新）が実行されます。

前提条件

トリガを定義する場合，データディクショナリLOB用RDエリアを作成しておく必要があります。データディクショナリLOB用RDエリアは，データベース構成変更ユティリティ（pdmod）で作成します。

なお，トリガを表に定義すると，その表を使用する関数，手続き及びトリガのSQLオブジェクトは無効になるため，SQLオブジェクトを再作成する必要があります。また，トリガが使用しているリソース（表，インデクスなど）が定義，定義変更，又は削除された場合，トリガのSQLオブジェクトは無効になるため，SQLオブジェクトを再作成する必要があります。詳細は「トリガの管理」を参照してください。

12.5.1　適用基準

UAPで次のような処理をする場合，トリガの使用をお勧めします。

ある表の更新に伴ってほかの表を必ず更新する

ある表の更新に伴って，その更新行中のある列を必ず更新する（列と列を関連づける）

例えば，商品管理表の価格が変更されると商品管理履歴表に変更内容を蓄積するという場合，トリガを使用しないと，商品管理表を更新するUAPは常に商品管理履歴表も更新する必要があります。トリガを使用すると，商品管理履歴表への操作を自動化できるため，商品管理表を更新するUAPは商品管理履歴表の更新を考慮する必要がありません。このように，トリガを適切に使用するとUAPを作成するときの負荷を軽減できます。

12.5.2　トリガの定義

(1)　定義の準備

トリガを定義すると，指定したトリガSQL文を基にトリガ動作手続きのSQLオブジェクトが自動的に作成され，データディクショナリLOB用RDエリアに格納されます。そのため，トリガを定義する場合，データディクショナリLOB用RDエリアに十分な容量を確保しておく必要があります。データディクショナリLOB用RDエリアの容量の見積もりについては，「データディクショナリLOB用RDエリアの容量の見積もり」を参照してください。

また，トリガ契機となるSQLを実行するためには，SQLオブジェクト用バッファ長を指定するときにトリガのSQLオブジェクトについても考慮しておく必要があります。SQLオブジェクト用バッファ長の見積もりについては，マニュアル「HiRDB システム定義」を参照してください。

(2)　定義方法

トリガの定義，SQLオブジェクトの再作成，及び削除には次の定義系SQLを使用します。

CREATE TRIGGER

トリガを定義します。トリガは所有する表にだけ定義でき，他ユーザが所有する表には定義できません。次の項目を指定します。

トリガ動作の実行時期

トリガ動作は表への操作の前（BEFORE），又は後（AFTER）に実行できます。なお，トリガ動作時期にBEFOREを指定したトリガをBEFOREトリガ，AFTERを指定したトリガをAFTERトリガといいます。

トリガ動作の実行契機

トリガ動作を実行する契機には，INSERT文，DELETE文，又はUPDATE文の実行があります。

トリガを定義する表

トリガは実表にだけ定義できます。

トリガ契機となるSQLの実行前後の行の名称（新旧値別名）

トリガ契機となるSQLで更新する行に，SQL実行前の名称（旧値相関名），又は実行後の名称（新値相関名）を指定します。ここで指定した名称を使ってトリガの動作内容を指定できます。

トリガ動作

トリガ動作には次の三つの要素があります。

・トリガSQL文（自動的に実行させるSQL文）

・トリガ動作の探索条件（トリガSQL文が実行される条件）

・動作が実行されるのが行単位か文単位かの種別

トリガSQL文はトリガ動作の探索条件を満たす場合にだけ実行され，条件を省略した場合はトリガ契機となるSQLが実行されると常にトリガSQL文が実行されます。

ALTER TRIGGER

既に定義されているトリガのSQLオブジェクトを再作成します。定義系SQLのALTER ROUTINEでも再作成できます。

DROP TRIGGER

トリガを削除します。

(3)　トリガの定義例

(a)　トリガを使用した例

商品管理表の価格が更新された場合，変更前に比べ変更後の価格上昇が10,000円を超えるとき，商品管理履歴表に更新前後の価格を挿入するトリガの定義例とトリガ動作を次に示します。

CREATE TRIGGER TR1　　　　…トリガ名
       AFTER　　　　…トリガ動作の実行時期
       UPDATE OF 価格　　　　…トリガ動作の実行契機
       ON 商品管理表　　　　…トリガを定義する表
       REFERENCING OLD ROW AS X1　　　　…更新前の行に指定する名称
                   NEW ROW AS Y1　　　　…更新後の行に指定する名称
       FOR EACH ROW　　　　…行単位か文単位かの種別
       WHEN(Y1.価格 - X1.価格 > 10000)　　　　…トリガ動作の探索条件
       INSERT INTO 商品管理履歴表 VALUES　　　　…トリガSQL文
                       (X1.品番, X1.価格, Y1.価格)

(b)　トリガ動作にSQL制御文（代入文）を使用した例

代入文は，指定した値を指定した列に代入するSQLです。トリガでは表に対する操作の前に動作するトリガ動作で代入文を使用できます。トリガ動作に代入文を使用すると列と列の関係付けができます。

社員表の職種列が更新されると，更新された内容によって手当て列の値を変更するトリガの定義例とトリガ動作を次に示します。

社員表に挿入される行に対して，職種がAの場合は給料の8％，Bの場合は10％，AとB以外の場合は0％を手当ての列に設定するトリガ

CREATE TRIGGER 手当て設定トリガ1
       BEFORE
       INSERT
       ON 社員表
       REFERENCING NEW ROW AS X1
       FOR EACH ROW
       SET X1.手当て=CASE X1.職種 WHEN 'A' THEN X1.給料*0.08
                                  WHEN 'B' THEN X1.給料*0.1
                                  ELSE 0 END

職種と給料が更新された行に対して，職種がAの場合は給料の8％，Bの場合は10％，AとB以外の場合は0％を手当ての列に設定するトリガ

CREATE TRIGGER 手当て設定トリガ2
       BEFORE
       UPDATE OF 職種,給料
       ON 社員表
       REFERENCING NEW ROW AS X1
       FOR EACH ROW
       SET X1.手当て=CASE X1.職種 WHEN 'A' THEN X1.給料*0.08
                                  WHEN 'B' THEN X1.給料*0.1
                                  ELSE 0 END

〔説明〕

INSERT文が契機となり，手当て設定トリガ1が実行され，行が追加されました。INSERT文では手当てに0を設定していますが，代入文の結果が格納されます。

次に，UPDATE文が契機となり，手当て設定トリガ2が実行され，手当てが0に変更されました。

(c)　トリガ動作にSQL制御文（複合文）を使用した例

複合文は，複数のSQLをまとめて一つのSQLとして実行するSQLです。ある表に対する更新を契機に複数の表を更新する場合，トリガ動作に複合文を使用すると一つのトリガを定義するだけで複数の表を更新できます。

在庫マスタ表が更新された後，その更新内容を広島在庫及び仙台在庫に反映するトリガの定義例を次に示します。複合文を使用しない場合，トリガを二つ定義しなければなりません。

CREATE TRIGGER 地方在庫表更新トリガ
       AFTER
       UPDATE OF 在庫数
       ON 在庫マスタ
       REFERENCING NEW ROW 更新後
                   OLD ROW 更新前
       BEGIN
         UPDATE 広島在庫 SET 在庫数=更新後.在庫数
                WHERE 商品コード=更新前.商品コード;
         UPDATE 仙台在庫 SET 在庫数=更新後.在庫数
                WHERE 商品コード=更新前.商品コード;
       END

(d)　トリガ動作にSQL診断文（SIGNAL文）を使用した例

SIGNAL文はエラーを発生させるSQLです。表への操作の前にSIGNAL文を指定したトリガ動作を実行させれば，操作が不正な場合にSIGNAL文を実行してその操作を抑止できます。

社員情報表を更新する前に，自分の情報以外を更新しようとした場合にSIGNAL文でエラーを発生させ，更新を抑止するトリガの定義例を次に示します。

CREATE TRIGGER 更新抑止トリガ
       BEFORE
       UPDATE
       ON 社員情報
       REFERENCING OLD ROW AS X1
       WHEN(X1.社員名<>USER) SIGNAL SQLSTATE '99001'

12.5.3　トリガの使用上の注意

行単位トリガの定義によっては，トリガ契機となるSQL実行時にHiRDBの内部処理に依存して異なる結果（更新の場合は異なる更新内容）になる場合があります。

〔説明〕

表Aの行1の更新時，トリガ動作で更新，削除，又は挿入する表Bの行と，行2の更新時，トリガ動作で参照，更新，又は削除する表Bの行に同一の行（重なり合った部分）があります。行1と行2の更新順序はHiRDBの内部処理に依存するため，この部分で異なる結果が得られる場合があります。

12.5.4　トリガの管理

(1)　トリガの定義

トリガを定義すると，トリガを定義する表を使用する関数，手続き及びトリガのSQLオブジェクトは無効になるため，再作成する必要があります。トリガを定義する前にディクショナリ表のSQL_ROUTINE_RESOURCES表を参照すると，SQLオブジェクトが無効になる関数，手続き及びトリガを確認できます。無効になるSQLオブジェクトを確認して，再作成してください。

(a)　トリガの定義によってSQLオブジェクトが無効になる関数，手続き及びトリガの確認

トリガの定義によってSQLオブジェクトが無効になる関数，手続き及びトリガを確認するSQLの例を次に示します。なお，無効になるのがトリガの場合はTRIGGER_NAMEとしてそのトリガ識別子が得られます。関数及び手続きの場合はTRIGGER_NAMEがNULLになります。

SELECT DISTINCT B.ROUTINE_SCHEMA, B.ROUTINE_NAME, B.SPECIFIC_NAME, A.TRIGGER_NAME
FROM MASTER.SQL_ROUTINE_RESOURCES B LEFT JOIN MASTER.SQL_TRIGGERS A
ON B.ROUTINE_SCHEMA=A.TRIGGER_SCHEMA
AND B.SPECIFIC_NAME=A.SPECIFIC_NAME
WHERE B.BASE_TYPE='R'
AND B.BASE_OWNER='トリガを定義する表の所有者の認可識別子'
AND B.BASE_NAME='トリガを定義する表の識別子'
AND (B.列名※ ='Y'
  OR (  B.INSERT_OPERATION IS NULL
    AND B.UPDATE_OPERATION IS NULL
    AND B.DELETE_OPERATION IS NULL))

注※　

INSERTを契機とするトリガを定義すると無効になるSQLオブジェクトを検索する場合には，列名にINSERT_OPERATIONを，UPDATEを契機とするトリガの場合はUPDATE_OPERATIONを，DELETEを契機とするトリガの場合はDELETE_OPERATIONを指定します。

(2)　トリガのSQLオブジェクトの再作成

トリガが使用している表，インデクスなどのリソースが定義，定義変更，又は削除されるとトリガのSQLオブジェクトは無効になります。また，トリガが使用している表にインデクスを定義したり，又はトリガが使用している表のインデクスを削除したりすると，トリガのSQLオブジェクトのインデクス情報が無効になります。

トリガのSQLオブジェクトが無効又はSQLオブジェクトのインデクス情報が無効の場合，トリガ契機となるSQLは実行できません。トリガのSQLオブジェクトの無効又はSQLオブジェクトのインデクス情報の無効を解除するには，定義系SQLのALTER TRIGGER又はALTER ROUTINEでトリガのSQLオブジェクトを再作成する必要があります。

(a)　トリガが使用しているリソースを確認する方法

ディクショナリ表のSQL_ROUTINE_RESOURCES，SQL_TRIGGER_USAGE，及びSQL_ROUTINE_PARAMSを参照すると，トリガが使用しているリソースの情報を得ることができます。

トリガ動作条件で使用するリソースを確認するSQLの例

SELECT B.* FROM MASTER.SQL_TRIGGERS A, MASTER.SQL_TRIGGER_USAGE B
WHERE A.TRIGGER_SCHEMA='スキーマ名'
  AND A.TRIGGER_NAME='トリガ識別子'
  AND A.TRIGGER_SCHEMA=B.TRIGGER_SCHEMA
  AND A.TRIGGER_NAME=B.TRIGGER_NAME

新旧値別名を指定したトリガSQL中で使用する列リソースを確認するSQLの例

SELECT B.* FROM MASTER.SQL_TRIGGERS A, MASTER.SQL_ROUTINE_PARAMS B
WHERE A.TRIGGER_SCHEMA='スキーマ名'
  AND A.TRIGGER_NAME='トリガ識別子'
  AND A.TRIGGER_SCHEMA=B.ROUTINE_SCHEMA
  AND A.SPECIFIC_NAME=B.SPECIFIC_NAME

上記以外でトリガが使用するリソースを確認するSQLの例

SELECT B. * FROM MASTER.SQL_TRIGGERS A, MASTER.SQL_ROUTINE_RESOURCES B
WHERE A.TRIGGER_SCHEMA='スキーマ名'
  AND A.TRIGGER_NAME='トリガ識別子'
  AND A.TRIGGER_SCHEMA=B.ROUTINE_SCHEMA
  AND A.SPECIFIC_NAME=B.SPECIFIC_NAME

(b)　表の列削除の前に，削除されるトリガを確認する方法

トリガ契機で指定されている列がすべて削除された場合，そのトリガは削除されます。表の列が削除される前に，削除されるトリガを確認するSQLの例を次に示します。

SELECT A.TRIGGER_SCHEMA, A.TRIGGER_NAME
  FROM MASTER.SQL_TRIGGERS A
WHERE A.N_UPDATE_COLUMNS>0
  AND A.TABLE_SCHEMA='列削除する表の所有者の認可識別子'
  AND A.TABLE_NAME='列削除する表の表識別子'
  AND NOT EXISTS(SELECT * FROM MASTER.SQL_TRIGGER_COLUMNS B
                 WHERE B.TRIGGER_SCHEMA=A.TRIGGER_SCHEMA
                   AND B.TRIGGER_NAME=A.TRIGGER_NAME
                   AND B.TABLE_SCHEMA=A.TABLE_SCHEMA
                   AND B.TABLE_NAME=A.TABLE_NAME
                   AND B.COLUMN_NAME NOT IN('削除する列名',…))

(c)　表，インデクスなどの定義，定義変更，削除の前にSQLオブジェクトが無効又はSQLオブジェクトのインデクス情報が無効になる関数，手続き及びトリガを確認する方法

表，インデクスなどを定義，定義変更，又は削除する前に，SQLオブジェクトが無効又はSQLオブジェクトのインデクス情報が無効になる関数，手続き及びトリガを確認するSQLの例を次に示します。なお，無効になるのがトリガの場合はTRIGGER_NAMEとしてそのトリガ識別子が得られます。関数及び手続きの場合はTRIGGER_NAMEがNULLになります。

表（ビュー表も含む）の定義変更及び削除，又はインデクス定義（インデクスを定義する表のスキーマ名と表識別子を指定）の場合

SELECT DISTINCT B.ROUTINE_SCHEMA, B.ROUTINE_NAME, B.SPECIFIC_NAME, A.TRIGGER_NAME
  FROM MASTER.SQL_ROUTINE_RESOURCES B LEFT JOIN MASTER.SQL_TRIGGERS A
  ON B.ROUTINE_SCHEMA=A.TRIGGER_SCHEMA
    AND B.SPECIFIC_NAME=A.SPECIFIC_NAME
WHERE B.BASE_TYPE IN('R','V')
  AND B.BASE_OWNER='表（ビュー）の所有者の認可識別子'
  AND B.BASE_NAME='表（ビュー）の表識別子'

インデクス削除の場合

SELECT DISTINCT B.ROUTINE_SCHEMA, B.ROUTINE_NAME, B.SPECIFIC_NAME, A.TRIGGER_NAME
  FROM MASTER.SQL_ROUTINE_RESOURCES B LEFT JOIN MASTER.SQL_TRIGGERS A
  ON B.ROUTINE_SCHEMA=A.TRIGGER_SCHEMA
    AND B.SPECIFIC_NAME=A.SPECIFIC_NAME
WHERE B.BASE_TYPE ='I'
  AND B.BASE_OWNER='インデクスの所有者の認可識別子'
  AND B.BASE_NAME='インデクスの識別子'

関数，又は手続き削除の場合

SELECT DISTINCT B.ROUTINE_SCHEMA, B.ROUTINE_NAME, B.SPECIFIC_NAME, A.TRIGGER_NAME
  FROM MASTER.SQL_ROUTINE_RESOURCES B LEFT JOIN MASTER.SQL_TRIGGERS A
  ON B.ROUTINE_SCHEMA=A.TRIGGER_SCHEMA
    AND B.SPECIFIC_NAME=A.SPECIFIC_NAME
WHERE B.BASE_TYPE ='P'
  AND B.BASE_OWNER='関数又は手続きの所有者の認可識別子'
  AND B.BASE_NAME='ルーチン識別子'

トリガ削除の場合

SELECT DISTINCT B.ROUTINE_SCHEMA, B.ROUTINE_NAME, B.SPECIFIC_NAME, A.TRIGGER_NAME
  FROM MASTER.SQL_ROUTINE_RESOURCES B LEFT JOIN MASTER.SQL_TRIGGERS A
  ON B.ROUTINE_SCHEMA=A.TRIGGER_SCHEMA
    AND B.SPECIFIC_NAME=A.SPECIFIC_NAME
WHERE B.BASE_TYPE ='T'
  AND B.BASE_OWNER='トリガの所有者の認可識別子'
  AND B.BASE_NAME='トリガ識別子'

スキーマ削除の場合

SELECT DISTINCT B.ROUTINE_SCHEMA, B.ROUTINE_NAME, B.SPECIFIC_NAME, A.TRIGGER_NAME
  FROM MASTER.SQL_ROUTINE_RESOURCES B LEFT JOIN MASTER.SQL_TRIGGERS A
  ON B.ROUTINE_SCHEMA=A.TRIGGER_SCHEMA
    AND B.SPECIFIC_NAME=A.SPECIFIC_NAME
WHERE B.BASE_OWNER='スキーマ名'

ユーザ定義型削除の場合

SELECT B.ROUTINE_SCHEMA, B.ROUTINE_NAME, B.SPECIFIC_NAME, A.TRIGGER_NAME
  FROM MASTER.SQL_ROUTINE_RESOURCES B LEFT JOIN MASTER.SQL_TRIGGERS A
  ON B.ROUTINE_SCHEMA=A.TRIGGER_SCHEMA
    AND B.SPECIFIC_NAME=A.SPECIFIC_NAME
WHERE B.BASE_NAME='削除するデータ型識別子'
  AND B.BASE_TYPE='D'
UNION
SELECT B.ROUTINE_SCHEMA, B.ROUTINE_NAME, B.SPECIFIC_NAME, A.TRIGGER_NAME
  FROM MASTER.SQL_ROUTINES C INNER JOIN MASTER.SQL_ROUTINE_RESOURCES B
  ON C.SPECIFIC_NAME=B.BASE_NAME
 LEFT JOIN MASTER.SQL_TRIGGERS A
  ON B.ROUTINE_SCHEMA=A.TRIGGER_SCHEMA
    AND B.SPECIFIC_NAME=A.SPECIFIC_NAME
WHERE C.ROUTINE_ADT_OWNER='削除するユーザ定義型の所有者の認可識別子'
AND C.ROUTINE_ADT_NAME='削除するデータ型識別子'
AND B.BASE_TYPE='P'

(d)　表，インデクスなどの定義，定義変更，削除の後にSQLオブジェクトが無効又はSQLオブジェクトのインデクス情報が無効になった関数，手続き及びトリガを確認する方法

表，インデクスなどを定義，定義変更，又は削除した後に，SQLオブジェクトが無効又はSQLオブジェクトのインデクス情報が無効になったトリガを確認するには，それぞれディクショナリ表のSQL_TRIGGER表のTRIGGER_VALID列，INDEX_VALID列を参照します。TRIGGER_VALID列の内容が'N'の場合，そのトリガのSQLオブジェクトは無効になっています。また，INDEX_VALID列の内容が'N'の場合，そのトリガのSQLオブジェクトのインデクス情報は無効になっています。

表，インデクスなどを定義，定義変更，又は削除した後に，SQLオブジェクトが無効又はSQLオブジェクトのインデクス情報が無効になった関数，手続き及びトリガを確認するSQLの例を次に示します。なお，無効になるのがトリガの場合はTRIGGER_NAMEとしてそのトリガ識別子が得られます。関数及び手続きの場合はTRIGGER_NAMEがNULLになります。

SELECT 'TRIGGER', TRIGGER_SCHEMA AS “SCHEMA”, TRIGGER_NAME AS “NAME”,
 TRIGGER_VALID AS “OBJECT_VALID”, INDEX_VALID
  FROM MASTER.SQL_TRIGGERS
WHERE TRIGGER_VALID='N' OR INDEX_VALID='N'
UNION
SELECT 'ROUTINE', ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_VALID, INDEX_VALID
  FROM MASTER.SQL_ROUTINES
WHERE ROUTINE_VALID='N' OR INDEX_VALID='N'

12.5.5　障害時の回復方法

トリガのソースはデータディクショナリ用RDエリアに，トリガのSQLオブジェクトはデータディクショナリLOB用RDエリアに格納されます。データディクショナリ用RDエリアのログ取得モードはALL，データディクショナリLOB用RDエリアのログ取得モードはPARTIALです。そのため，障害が発生した場合，ソースはバックアップとログを入力して回復すれば最新時点に回復できますが，SQLオブジェクトはバックアップ時点にしか回復できません。そこで次の運用をする必要があります。

常に最新のバックアップを取得しておく

常にデータディクショナリLOB用RDエリアのバックアップを取得し，障害発生時に最新のバックアップから回復します。pdcopyコマンドで-M x，又は-M rを指定してください。

バックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

トリガのSQLオブジェクトを再作成する

データディクショナリLOB用RDエリアの最新のバックアップがない場合，そのデータディクショナリLOB用RDエリアをpdmodコマンドで再初期化します。その後，ALTER ROUTINEにALLを指定して実行し，全トリガのSQLオブジェクトを再作成します。

12.6　ビュー表の作成

12.6.1　ビュー表作成の概要

実際にデータベースに格納している表（実表）から特定の行や列を選択して，新たに定義した仮想の表（ビュー表）を作成できます。

(1)　実表とビュー表の関係

実表とビュー表の関係を次の図に示します。

図12‒18　実表とビュー表の関係

[picture]

〔説明〕

実表（ZAIKO）から，商品名（SNAME）がソックスの行で，商品コード（SCODE），在庫量（ZSURYO）及び単価（TANKA）の列で構成されるビュー表（VZAIKO）を作成した例です。

商品を扱うある支店では，「商品名」が「ソックス」で「商品コード」「在庫量」「単価」のデータを参照だけすればよい場合，実表（ZAIKO）にはアクセス不可とし，ビュー表（VZAIKO）に対して参照だけを許す権限（SELECT権限）を設定します。これによって，必要な情報だけを参照でき，データは保護されます。

(2)　ビュー表を作成したときの効果

ビュー表を作成したときの効果を次に示します。

機密性の向上

自分の表の機密保護を図りたい場合にビュー表を作成します。ビュー表を作成することで，表の特定の列と行だけを表示できます。このため，アクセス権限をビュー表に設定することで，行又は列レベルの機密保護が図れます。

操作性の向上

複雑な問い合わせ指定をして表を検索しなくてもよいように，複雑な問い合わせ指定をした場合に検索できるデータであらかじめビュー表を作成します。これによって，表を参照する操作が手軽になります。

ビュー表を通して実表を参照したり更新したりできます。これによって，実表の定義が変更されてもSQL文を変更する必要はなく，場合によってはビュー表の定義を変更する必要がなくなります。

(3)　ビュー表の作成方法

定義系SQLのCREATE VIEWを実行してビュー表を作成します。CREATE VIEWで次に示すビュー表を定義できます。

実表の特定の行及び列を選択したビュー表

実表の列から集合関数，日付演算，時刻演算，連結演算，スカラ関数，又は四則演算で求めた値を列とするビュー表

最大128個の実表を基にした一つのビュー表

グループ分け検索の結果を基にしたビュー表

ほかのユーザが所有する実表を基にしたビュー表（ほかのユーザが所有する実表のSELECT権限を与えられている場合に限る）

規則

一つのビュー表には30,000個まで列を定義できます。

ビュー表に対して列の追加，及びインデクスを定義できません。

自分の所有する実表から定義したビュー表の所有者はビュー表に対するすべてのアクセス権限（行の検索，追加，削除，更新）を持ちます。

ほかのユーザが所有する実表から定義したビュー表の所有者は，ビュー表に対するアクセス権限として，実表に対して付与されているアクセス権限だけを持ちます。ただし，ビュー表の定義に次に示すどれかの指定をした場合は，機密保護機能を使用するかどうかに関係なく行の検索しかできません。

ビュー表の列に実表の同じ列を複数指定した場合

ビュー表の列に定数，USER値関数，CURRENT_DATE値関数，CURRENT_TIME値関数，四則演算，日付演算，時刻演算，連結演算，又はスカラ関数の結果を指定した場合

複数の実表を指定した場合

DISTINCT，集合関数（COUNT(＊)，AVG，MAX，MIN，SUM），グループ分け（GROUP BY句），又はグループ条件（HAVING句）を指定した場合

機密保護機能を使用しない場合，これら以外のビュー表はほかのユーザが自由に更新できます。ただし，読み込み専用のビュー表（READ ONLY指定）の場合，機密保護機能を使用しなくてもほかのユーザがビュー表を更新できません。

(4)　ビュー表の削除方法

定義系SQLのDROP VIEWを実行してビュー表を削除します。ビュー表を削除すると，削除したビュー表に関するすべてのアクセス権限が取り消されます。

12.7　FIX属性の指定

FIX属性とは，行長が固定の表に付ける属性のことです。

12.7.1　FIX属性を指定したときの効果

表にFIX属性を指定したときの効果を次に示します。

性能の向上

任意の列を取り出す性能が，列の定義順序に関係なく一定になります。また，FIX属性を指定しない場合と比べて，列の取り出し時間を短縮できます。

UAPで行単位インタフェースが使用できるため，列数が多くてもアクセス性能を向上できます。

操作性の向上

FIX属性の表の列を更新する場合に入力データにナル値があったときは，エラーとしてチェックアウトできます。

ディスク所要量の削減

FIX属性を指定していない表と比べて，物理的な行長が1列で2バイト短くなります。このため，列数の多い表の場合はディスク所要量を削減できます。

12.7.2　適用基準

ナル値を持つ列がない，かつ可変長の列がない場合は，表定義時にFIX属性を指定します。

また，上記の条件を満たさない場合でも，次に示すことを検討してください。

将来，表に列の追加が見込まれる場合は，表定義時に予備列を定義してください。予備列を定義しておくと，表にデータが格納されている状態でも，列の追加ができます。

0（数値データ）又は空白（文字データ）を使用して，ナル値を不要にしてください。ただし，ナル値は探索条件や集合関数での扱いが，ほかの値と異なるため注意してください。

最大値の小さい可変長データや実長の取り得る範囲が狭い可変長データを固定長にしてください。ただし，探索条件での扱いが異なるため注意してください。

12.7.3　指定方法

表にFIX属性を指定するには，定義系SQLのCREATE TABLEでFIXを指定（CREATE FIX TABLEと指定）します。

12.7.4　注意

予備列は，将来の列追加のために確保しておく領域（列）であり，ユーザは予備列に対して任意の値で挿入，更新を行うことはできません。また，予備列にはHiRDBが予備列の定義長分のナル文字（0x00）を格納するため，表格納用RDエリアの容量を見積もる際には，予備列も含めて表の格納ページ数を見積もる必要があります。予備列の使い方を次の図に示します。

図12‒19　予備列の使い方

[picture]

12.8　主キー（プライマリキー）の指定

12.8.1　主キーの効果と指定方法

表中の行を一意（ユニーク）に識別するためのキーとして主キーがあります。主キーを定義すると，指定した列に対してインデクスが作成されます。

(1)　主キーを定義したときの効果

主キーを定義した列には，一意性制約と非ナル値制約が適用されます。一意性制約とは，キー（列又は複数の列の組）中のデータの重複を許さない（キー中のデータが常に一意である）制約のことです。非ナル値制約とは，キー中の各列の値にナル値を許さない制約のことです。

(2)　適用基準

行を一意に識別できる列に主キーを定義します。表中に行を一意に識別できる列又は列の組（候補キー）が複数ある場合，その候補キーの中から主キーを選んでください。表中のキーの中で意味的に最も重要で，かつ一意性制約及び非ナル値制約を設定したいキーに主キーを定義します。

(3)　指定方法

表に主キーを定義するには，定義系SQLのCREATE TABLEのPRIMARY KEYオプションを指定します。

なお，主キーは定義系SQLのALTER TABLEでも追加，及び削除ができます。追加する場合は，ADD PRIMARY KEYオプションを指定します。削除する場合は，DROP PRIMARY KEYオプションを指定します。

12.9　クラスタキーの指定

12.9.1　クラスタキーの効果と指定方法

クラスタキーとは，特定の列の値の昇順又は降順に行を格納するためのキーとして指定した列のことです。表の一つの列又は複数の列にクラスタキーを指定しておくと，クラスタキーの昇順又は降順に行を格納できます。

クラスタキーを定義すると，指定した列に対してインデクスが作成されます。

(1)　クラスタキーを定義したときの効果

表にクラスタキーを指定したときの効果を次に示します。

性能の向上

範囲を指定して行の検索，更新，削除などをするとき又はクラスタキー順に検索，更新などをするときに，入出力時間を削減できます。

操作性の向上

UNIQUE指定のクラスタキーを定義すると，そのクラスタキーには一意性制約が適用されます。このため，行を挿入するときに，クラスタキーを構成している列の値がすべての行で重複しないようにできます。なお，フレキシブルハッシュ分割表には，UNIQUE指定のクラスタキーを定義できません。

PRIMARY指定のクラスタキーを定義すると，そのクラスタキーには一意性制約及び非ナル値制約が適用されます。このため，行を挿入するときに，クラスタキーを構成している列の値がすべての行で重複しないようにできます。また，クラスタキーを構成している列の値にナル値を格納しないようにできます。なお，フレキシブルハッシュ分割表には，PRIMARY指定のクラスタキーを定義できません。

表を作成するときに，入力データがクラスタキーの昇順又は降順に並んでいるかどうかをデータベース作成ユティリティ（pdload）で確認できます。

表を再編成するときに，アンロードした行のクラスタキーと，リロードするクラスタキーが一致しているかどうかをデータベース再編成ユティリティ（pdrorg）で確認できます。

(2)　適用基準

クラスタキーを指定するとよい場合を次に示します。

キーの昇順又は降順にデータを蓄積する業務で，キー順にアクセスする業務が多い場合

キーを変更しない表の場合

行長が固定の表の場合

(3)　指定方法

表にクラスタキーを定義するには，定義系SQLのCREATE TABLEでCLUSTER KEYオプションを指定します。

(4)　設計上の考慮点

データを追加した後の検索効果を上げるため，表を格納しているページ内に未使用領域を設定しておきます。設定方法については，「ページ」を参照してください。

(5)　注意

クラスタキーを構成する列の値は更新できません。

クラスタキーを構成する列にナル値は挿入できません。

クラスタキーを指定した表にデータを追加するとき，追加しようとするキー値に近接するキー値を持ったページを探すためのオーバヘッドが発生します。この概要を次の図に示します。

図12‒20　クラスタキーを指定した表にデータを追加するときのオーバヘッドの概要

[picture]

〔説明〕

列Ｃを持つデータを追加します。

列Ｃに近接するキー値を探すオーバヘッドが発生します。

12.10　サプレスオプションの指定

12.10.1　サプレスオプションの効果と指定方法

サプレスオプションとは，表中のデータの一部を省略して，実際のデータ長よりも短くして格納するオプションのことです。

サプレスオプションを指定した場合には，データ格納時に，表中のDECIMALデータの有効けた（先頭の0の部分を除いたけた）部分及び格納データ長だけを格納します。

(1)　サプレスオプションを指定したときの効果

サプレスオプションを指定したときの効果を次に示します。

性能の向上

実際のデータ長よりも短くしてデータを格納できるため，ディスク所要量を削減できます。

ディスク所要量の削減で，全件検索などの検索処理での入出力時間が短縮できます。

(2)　適用基準

次に示す場合にサプレスオプションを指定することをお勧めします。

表中にDECIMALデータが多く，有効けた数が多い場合

全件検索などの検索業務が多く，更新業務が少ない場合

(3)　指定方法

サプレスオプションを指定するには，定義系SQLのCREATE TABLEでSUPPRESSオプションを指定します。

(4)　注意

DECIMALデータの有効けた数が定義長と等しい場合又は定義長が1の場合には，「定義長＋1」の長さで格納されます。このため，サプレスオプション指定時よりも格納するデータ長が長くなります。

FIX属性を指定している表では，サプレスオプションを指定できません。

12.11　ノースプリットオプションの指定

12.11.1　ノースプリットオプションの適用基準と指定方法

表に次に示すデータ型が定義されていて，次に示すデータ型の実際のデータ長が256バイト以上の場合，1行のデータを複数のページに格納します。このときのデータ格納方式を次の図に示します。

VARCHAR

MVARCHAR

NVARCHAR

図12‒21　可変長文字列の実際のデータ長が256バイト以上の場合のデータ格納方式

[picture]

〔説明〕

可変長文字列を除いたデータと可変長文字列のデータは，異なるページに格納されます。このため，データの格納効率が低下します。このような場合に，ノースプリットオプションを指定してデータの格納効率を向上してください。

(1)　適用基準

ノースプリットオプションを指定すると，可変長文字列の実際のデータ長が256バイト以上であっても，1行を1ページに格納します。ノースプリットオプションを指定したときのデータ格納方式を次の図に示します。

図12‒22　ノースプリットオプションを指定したときのデータ格納方式

[picture]

〔説明〕

1行の全データを同じページに格納します。このため，データの格納効率がノースプリットオプションを指定しないときに比べて向上します。

(2)　指定方法

ノースプリットオプションを指定するには，定義系SQLのALTER TABLE，CREATE TABLE又はCREATE TYPEでNO SPLITオプションを指定します。

(3)　注意

1行のデータ長の合計がページ長を超える場合は，ノースプリットオプションを指定してもスプリット（1行のデータを複数のページに格納）します。

可変長文字列の実際のデータ長が255バイト以下の場合にノースプリットオプションを指定すると，指定しないときに比べて列データ長が1バイト長くなります。

ノースプリットオプションを指定すると，可変長文字列の実際のデータ長が256バイト以上であっても分岐しないため，ノースプリットオプションを指定しない場合と比べて1ページに格納される行数が少なくなります。このため，インデクススキャンでノースプリットオプションが適用された可変長文字列型の列データを取り出さない検索をすると，ノースプリットオプションを指定しないときに比べてアクセスするページ数が多くなり，検索性能が低下することがあります。ただし，キースキャン及びテーブルスキャンの場合は影響はありません。

12.12　バイナリデータ列の指定

文書，画像，音声などの可変長バイナリデータを格納する列に指定するデータ型には，次の二つがあります。

BLOB型（BLOB型を指定した列をLOB列といいます）

BINARY型

それぞれのデータの格納方法の比較を次に示します。

データ長（基本行＋バイナリデータ長）が1ページ以下の場合

データ長（基本行＋バイナリデータ長）が1ページより大きい場合

〔説明〕

BLOB型を指定した列はほかの属性の列とは別に，ページ長が8キロバイト固定のユーザLOB用RDエリアに格納します。

BINARY型を指定した列は表を構成するすべての列データが1ページに格納できる場合，実際のデータ長に関係なく1行を1ページ内に格納します。ただし，1行が1ページに格納できない場合は，1行が複数ページになり，バイナリ専用セグメントに格納します。

12.12.1　BLOB型

(1)　設計上の考慮点

BLOB型を指定する場合はユーザLOB用RDエリアを作成してください。

BLOB型のデータは8キロバイトバウンダリされるので，データの格納効率はBINARY型が優位です。ただし，8キロバイトのバウンダリが無視できるような長大データサイズになると余り差はありません。

(2)　指定方法

定義系SQLのCREATE TABLEの列のデータ型で，BLOB型を指定します。

(3)　注意

BLOB型は次の項目には使用できません。

FIX属性の表

インデクスの定義

分割キー

12.12.2　BINARY型

(1)　設計上の考慮点

BINARY型は，BLOB型に比べて1ページに格納する行数が減るため，ある列を探索条件に指定して，BINARY型を指定したデータを取り出さない検索を実行した場合，BLOB型に比べて入出力回数が増えます。そのため，検索性能が低下することがあります。ただし，BINARY型以外の列にインデクスを定義してインデクススキャンにするとBINARY型とBLOB型の性能差はなくなります。

(2)　指定方法

定義系SQLのCREATE TABLEの列のデータ型で，BINARY型を指定します。

(3)　注意

BINARY型は次の項目には使用できません。

FIX属性の表

インデクスの定義

分割キー

外への参照列

バイナリデータ長が1ページより大きい場合，基本行を格納するセグメントと異なるバイナリ専用セグメントに格納します。データ長が1ページより大きいバイナリデータ格納時，基本行を格納するセグメントに未使用ページがある場合でも，バイナリ専用セグメントに未使用ページがなければRDエリアが容量不足となる場合があります。RDエリアが容量不足になった場合，データベース解析ユティリティ（pddbst）でバイナリ専用セグメント，及び基本行を格納するセグメントのそれぞれの使用状況を参照することで，原因がバイナリデータによるものか，又は基本行のデータによるものかが確認できます。

BINARY型の列を定義する場合は，列の定義長（列の最大長）の見積もりを詳細に行ってください。列の定義長を不要に大きくすると，列の定義長に比例してメモリを使用するデータロードを実行できなくなることがあります（BINARY列を定義している表のデータロードを実行する場合，BINARY列の定義長分のメモリを確保します）。

12.12.3　BLOB型とBINARY型の使い分け

バイナリデータの運用方法によってお勧めするデータ型を次の表に示します。

表12‒3　バイナリデータの運用による推奨データ型

バイナリデータの運用方法 | 推奨するデータ型の 平均データサイズ | 説明
32,000バイト以下の場合 | 32,000バイトより大きい場合
射影列にバイナリデータ列を指定する頻度 | 高い | BINARY | BLOB | 32,000バイト以下の場合，BINARY型の方がブロック転送もでき，行全体のデータが近くに集まって配置されるので，性能的に優位です。 32,000バイトより大きい場合，BLOB型の方が長大データに特化した内部メモリ削減などの処理をするので，性能的に優位です。
低い | BLOB※ | BLOB | BLOB型の方がBINARY型より基本行のデータサイズが小さいので，データ件数が多くなればBLOB型が性能的に優位です。ただし，BINARY型以外の列にインデクスを定義してインデクススキャンにすることでBINARY型とBLOB型の性能差はなくなります。また，インデクススキャンにすることを推奨しますが，セグメントサイズを大きくすることでも性能差を小さくできます。
SQL記述の柔軟性 | BINARY | 同等 | 32,000バイト以下の場合，BINARY型のSQL記述はインデクス定義を除いて，ほぼVARCHARと同等の記述ができます。そのため，BLOB型よりSQL記述範囲が広がります。詳細は，マニュアル「HiRDB SQLリファレンス」を参照してください。
データ格納効率 | BINARY | 格納効率はBINARY型が優位です。ただし，8キロバイトのバウンダリが無視できるような長大データサイズになると余り差はありません。
追加更新を頻繁にする場合 | BLOB | 連結演算するデータサイズが大きいほどBLOB型が性能的に優位です。
部分抽出を頻繁にする場合 | 同等 | BLOB | BINARY型の格納済みデータサイズが大きいデータに対して部分抽出をすると非常に性能が悪くなります。さらに，部分抽出回数を多くすると，性能は劣化します。大きなデータに対して部分抽出を頻繁にする必要がある場合には，BLOB型をお勧めします。
運用性を重視する場合 | BINARY | BLOB型はユーザLOB用RDエリアをバックアップするなどの特別な運用が必要になります。
上記使用方法で判断できない場合，又は将来的に方針変更の可能性があり，判断できない場合 | BINARY※ | BLOB | 32,000バイトより大きいデータを扱う場合はBLOB型をお勧めします。比較的データサイズが小さい場合はBINARY型をお勧めします。

注※

データサイズがページサイズに近い大きさで分岐しない場合，BINARY型で大量のテーブルスキャンをすると，BLOB型に比べて非常に性能が悪くなります。これを防ぐため，テーブルスキャンからインデクススキャンへ変更してください。また，インデクススキャンにすることを推奨しますが，セグメントサイズを大きくすることでも性能差を小さくできます。

12.13　文字集合の指定

文字集合とは，文字データに対する属性です。文字集合は，次の三つの属性を持ちます。

使用形式

文字を表現する規約のことです。例えば，ある文字集合ではAを1バイトのコードX'41'と表現しますが，別の文字集合では，これをX'C1'と表現します。このように，文字を表現する規約のことを使用形式といいます。

文字レパートリ

表現できる文字の集合のことです。例えば，ある文字集合ではバックスラッシュを表現できますが，別の文字集合ではこれを表現できません。このように，表現できる文字の集まりを文字レパートリといいます。

既定の照合順

二つの文字列データを比較する場合の規約のことです。例えば，ある文字集合では'1'＞'A'ですが，別の文字集合では'A'＞'1'という照合順になります。どの文字集合にも，既定の照合順があります。

なお，文字集合指定を省略して仮定された文字集合を，既定文字集合といいます。

12.13.1　文字集合を定義したときの効果

文字集合を定義すると，表の列ごとに異なる文字集合の文字列データを格納できます。これによって，文字集合にEBCDIKを指定した場合は，VOS3システムからHiRDBに移行したときに，データベースに格納していた文字データをVOS3システムの文字列データの照合順で検索，代入，比較ができます。また，文字集合にUTF16を指定した場合は，UTF-16で文字データの検索，代入，比較ができます。

12.13.2　HiRDBで使用できる文字集合

HiRDBで使用できる文字集合を次に示します。

EBCDIK

EBCDIKを使用する場合には，HiRDBセットアップ時，文字コード種別にsjisを指定します。

UTF16

UTF16を使用する場合には，HiRDBセットアップ時，文字コード種別にutf-8，又はutf-8_ivsを指定します。

12.13.3　指定方法

文字集合は文字データ型に指定します。文字集合を指定する場合の形式や規則については，マニュアル「HiRDB SQLリファレンス」を参照してください。

12.13.4　注意事項

入力データの文字集合と列の文字集合が異なる場合はデータロードできません。

文字集合にUTF16を指定した場合，データベースに格納されるデータはビッグエンディアン形式になります。文字集合にUTF16を指定した列に対して，埋込み変数，又は？パラメタを使用して操作する場合は，埋込み変数，？パラメタに指定する値をビッグエンディアン形式にしてください。これらをリトルエンディアン形式にした場合，文字コード変換をする必要があるため，性能が悪くなります。

12.14　WITHOUT ROLLBACKオプションの指定

12.14.1　WITHOUT ROLLBACKオプションの効果と適用基準

WITHOUT ROLLBACKオプションとは，表に対しての更新処理（追加，削除を含む）の完了を契機に，その更新行に対する排他が解除され，それ以降はロールバックされなくなるオプションのことです。

(1)　WITHOUT ROLLBACKオプションを指定したときの効果

表にWITHOUT ROLLBACKオプションを指定したときの効果を次に示します。

性能の向上

更新処理完了時に排他が解除されるので，排他待ちの発生を削減できます。

(2)　適用基準

採番業務のような，更新処理が集中する表に適しています。

伝票番号や書類番号などの採番業務では，一つの表で番号を管理し，採番するごとにカウントアップするという方法が考えられます。しかし，この方法では処理が集中すると，COMMIT発行まで排他が解除されないため，排他待ちが多く発生することが考えられます。このような処理をする場合，その表にWITHOUT ROLLBACKオプションを指定すると，カウントアップが終了した時点で排他が解除されるため，排他待ちの発生を削減できます。採番業務の例を次の図に示します。

図12‒23　採番業務の例

[picture]

この例では，1行で1種類の番号を管理しています。

図「採番業務の例」に示した採番管理表の定義例を次に示します。

CREATE TABLE 採番管理表 (種類 NCHAR(4),
                         採番 INT)
                    ：
             WITHOUT ROLLBACK

ただし，次に示す要因で欠番が発生する可能性がありますので，欠番が発生しても問題がない業務で使用してください。

表定義時にWITHOUT ROLLBACKオプションを指定した表の行を更新したトランザクションがROLLBACK文やSQL実行中のエラーによりロールバックした場合，取得した番号を使用した業務の表に対してはロールバックされます。この場合，整合性が保たれますが，取得した番号はロールバックされません。このため，ロールバックしたトランザクションで取得した値はHiRDBシステム内で使われずに次の番号が取得され，欠番となります。

(3)　注意

データベース作成ユティリティ（pdload）及びデータベース再編成ユティリティ（pdrorg）をログ取得モードを指定して実行した場合，WITHOUT ROLLBACKオプションを指定した表でも，通常の表と同様にロールバックされます。

採番業務のように更新処理が集中する表の場合，専用のRDエリア及びグローバルバッファを割り当ててください。

システム共通定義pd_idx_without_rollbackにNを指定した場合，WITHOUT ROLLBACKオプションを指定している表にインデクスを定義すると，行更新時にインデクス構成列に対して同値更新となるときだけ行更新ができます。また，行挿入及び行削除時は，行排他は解除されず，通常の表と同様にロールバックされます。

表定義時にWITHOUT ROLLBACKオプションを指定した表の行を更新したトランザクションが完了する前にHiRDBシステムが異常終了した場合，HiRDBシステムの再開始後に採番した値が戻るときがあります。採番した値をHiRDBシステム内に閉じて使用する場合，採番した値が戻っても，その値を使用したトランザクションもロールバックするため，HiRDBシステム内で一意性が保てます。HiRDBシステム外で使用する場合は採番した値が戻ると一意性が保てなくなります。HiRDBシステム外で使用する場合は，更新するSQL文にWRITE IMMEDIATEオペランドを指定してください。WRITE IMMEDIATEオペランドを指定すると，HiRDBシステムが異常終了しても値が戻りません。ただし，WRITE IMMEDIATEオペランドを指定すると1行の更新ごとにシステムログの書き出しが行われ，その書き出し時間がSQLの実行時間に加算されます。

12.15　改竄防止機能の指定

改竄防止機能とは，表の所有者も含め，すべてのユーザに対して表データの更新を禁止する機能です。この機能を適用することで，重要なデータを人為的ミスや不正な改竄から守れます。この機能が適用された表を改竄防止表といいます。改竄防止表に対する操作の実行可否を次の表に示します。

表12‒4　改竄防止表に対する操作の実行可否

操作 | 改竄防止表
行削除禁止期間指定あり | 行削除禁止期間指定なし
挿入（INSERT） | ○ | ○
検索（SELECT） | ○ | ○
列単位の更新（UPDATE） | ○※１ | ○※１
行単位の更新（UPDATE） | × | ×
削除（DELETE） | ○※２ | ×
全行削除（PURGE TABLE） | × | ×
上記以外の操作系SQL | ○ | ○

（凡例）

○：実行できます。

×：実行できません。

注※１

更新可能列だけ更新できます。

注※２

行削除禁止期間を経過しているデータだけ削除できます。行削除禁止期間を指定しないと，表データを削除できません。

適用基準

改竄防止機能は，表のデータを誤って，又は不当に更新されることを防止したい表に適用をお勧めします。

12.15.1　指定方法

定義系SQLのCREATE TABLEでINSERT ONLYオプション（改竄防止オプション）を指定します。また，ALTER TABLEでINSERT ONLYオプションを指定して，既存の表を改竄防止表に定義変更することもできます。

表定義又は定義変更時に次の列を定義できます。

更新可能列

更新可能列を定義すると，列単位に，次の方法でデータを更新できます。

常に更新できる（UPDATEを指定）

ナル値から非ナル値へ一度だけ更新できる（UPDATE ONLY FROM NULLを指定）

更新可能列を定義できるのは，次の時点です。

CREATE TABLE実行時

ALTER TABLE（CHANGE INSERT ONLY）実行前

ALTER TABLE（ADD 列名），又はALTER TABLE（CHANGE 列名）※実行時

注※

ALTER TABLE（CHANGE 列名）は，改竄防止表に対しては実行できません。既存の表を改竄防止表に定義変更する場合，事前に実行します。

挿入履歴保持列

挿入履歴保持列を定義すると，行削除禁止期間を指定できます。行削除禁止期間を省略すると，表データは一切削除できません。また，表にデータがあるとDROP TABLEが実行できないため（「定義系SQL」参照），行削除禁止期間を省略した場合，表及び表データは共に削除できません。そのため，データの保存期間が決まっている場合，又は決められる場合は行削除禁止期間を指定してください。

なお，データベース再編成ユティリティやpdrelsコマンドでのRDエリアに対する運用に制限がある※ため，改竄防止表は1表1RDエリアに格納することをお勧めします。

注※

データベース再編成ユティリティで改竄防止表の再編成をする場合，RDエリアのコマンド閉塞が必須です。また，データベース再編成ユティリティが異常終了した場合は，再編成が完了するまでRDエリアの閉塞が解除できないため，該当するRDエリアに別の表やインデクスが定義されている場合は，その表やインデクスが使用できなくなります。詳細は，「制限事項」を参照してください。

12.15.2　制限事項

改竄防止表はデータの更新及び削除ができない表のため，改竄防止表又は改竄防止表格納RDエリアに対して，SQL文，ユティリティ，及びコマンドの実行に制限があります。

(1)　定義系SQL

改竄防止表に対して実行できない定義系SQL文があります。制限がある定義系SQL文と制限事項を次の表に示します。

表12‒5　制限がある定義系SQL文と制限事項

SQL文 | 制限事項
CREATE TABLE | すべての列に更新可能列属性を指定し，かつ改竄防止オプションを指定することはできません。

ALTER TABLE

表名称，及び列名称は変更できません。

データが存在する表に改竄防止機能は適用できません。既存の表に改竄防止機能を適用する手順については，「非改竄防止表から改竄防止表への変更」を参照してください。

改竄防止機能の解除はできません。

既存の列を更新可能列に変更したり，更新可能列を通常の列に変更したりすることはできません。

更新可能列は，改竄防止機能を適用する前に定義しておく必要があります※。

行削除禁止期間の設定，解除，及び期間の変更はできません。

行削除禁止期間が指定されている改竄防止表の場合，行削除禁止期間を指定した挿入履歴保持列は削除できません。

分割格納条件は変更できません。

DROP TABLE | 改竄防止表にデータがある場合，実行できません。

注※

既存の表に更新可能列を指定して，改竄防止機能を適用するためには，列及び表に対してそれぞれALTER TABLEを実行する必要があります。次の手順で改竄防止機能を適用してください。

ALTER TABLEで，更新可能とする列の属性を更新可能列に変更

ALTER TABLE（CHANGE INSERT ONLY）で，改竄防止表にする表に対して改竄防止機能を適用

(2)　ユティリティ

改竄防止表，又は改竄防止表格納RDエリアに対して，ユティリティ運用が制限されます。制限されるユティリティと制限事項を次の表に示します。記載されていないユティリティについては，特に制限はありません。

表12‒6　運用時に制限があるユティリティと制限事項

ユティリティ名 | 制限事項
データベース作成ユティリティ（pdload） | 作成モード（-dオプション指定）は使用できません。 対象となる表がデータ未完状態※の場合は実行できません。
データベース構成変更ユティリティ（pdmod） | 改竄防止表格納RDエリアの再初期化（initialize rdarea）は実行できません。

データベース再編成ユティリティ（pdrorg）

表の再編成（-k rorg）

処理対象となる表格納RDエリアがコマンド閉塞となっていない場合は実行できません。

UOCを利用した再編成（unlduoc文）はできません。

同期点指定の再編成（option job文）はできません。

対象となる表がデータ未完状態※の場合は実行できません。

表のアンロード（-k unld）

-Wオプションを指定しない場合は実行できません。

表のリロード（-k reld）

処理対象となる表格納RDエリアがコマンド閉塞となっていない場合は実行できません。

対象となる表がデータ未完状態※となっている場合に実行できます（表の再編成で，表のリロードが異常終了した場合での再実行だけ実行できます）。

同期点指定の再編成（option job文）はできません。

別表へのリロードは実行できません。詳細は図「別表へのリロード可否」を参照してください。

インデクスの一括作成（-k ixmk），再作成（-k ixrc），再編成（-k ixor）

対象となる表がデータ未完状態※の場合は実行できません。

リバランスユティリティ（pdrbal） | 対象となる表がデータ未完状態※の場合は実行できません。

注※

改竄防止表に対して表の再編成を実行し，エラーなどによって表のリロードが完了していない表の状態をデータ未完状態といい，改竄防止表格納RDエリアごとに状態を保持します。該当するRDエリアがデータ未完状態かどうかは，データベース状態解析ユティリティで，RDエリア単位の状態解析（論理的解析）又は表単位の状態解析を実行することで確認できます。データ未完状態は表の再編成（表のリロード）が正常に完了した場合に解除されます。データ未完状態の解除方法の詳細は，マニュアル「HiRDB コマンドリファレンス」を参照してください。

図12‒24　別表へのリロード可否

[picture]

〔説明〕

改竄防止表T1から非改竄防止表T3へのリロードは，改竄防止表T1の改竄にはならないため，できます。

非改竄防止表T3から改竄防止表T1へのリロードは，改竄防止表T1のデータが改竄されることになるため，できません。

改竄防止表T1から改竄防止表T2へのリロードは，改竄防止表T2のデータが改竄されることになるため，できません。

改竄防止表T1自身に対するリロードは，改竄防止表T1の改竄にはならないため，できます。

HiRDBシステム1の改竄防止表T1からHiRDBシステム2の改竄防止表T1へのリロードは，HiRDBシステム2の改竄防止表T1のデータが改竄されることになるため，できません。

(3)　運用コマンド

改竄防止表，又は改竄防止表格納RDエリアに対して，コマンド実行が制限されます。制限事項がある運用コマンドを次の表に示します。

表12‒7　制限がある運用コマンドと制限事項

運用コマンド | 制限事項
RDエリアの閉塞（pdhold） | データ未完状態の改竄防止表格納RDエリアの場合，状態を遷移させると表の再編成を完了させるためのリロード実行が不可となるため次のオプションは実行できません。 参照可能閉塞：-i バックアップ閉塞：-b
RDエリアの閉塞解除（pdrels） | データ未完状態の改竄防止表格納RDエリアの場合，表の再編成が未完了のままで閉塞解除すると該当表のデータが0件の状態となるため，実行できません。

(4)　関連製品での制限事項

関連製品での制限事項を次に示します。

レプリケーション機能

改竄防止表に対して，レプリケーション機能（HiRDB Dataextractor及びHiRDB Datareplicator）を使用してデータの複写，及び更新結果を反映しないでください。使用すると，反映元と反映先でデータの内容が不一致となったり，エラーとなる場合があります。

12.15.3　非改竄防止表から改竄防止表への変更

既存の表を改竄防止表に変更する方法について説明します。次に示すどちらかの方法で，表を改竄防止表に変更できます。

HiRDB Control Managerの改竄防止ウィザードを使用する方法

HiRDBのコマンドを使用する方法

なお，データが格納されている表は改竄防止表に変更できません。したがって，表にデータが格納されている場合は，いったん表データをアンロードし，その後にALTER TABLEで表の定義を変更します。

(1)　HiRDB Control Managerの改竄防止ウィザードを使用する方法

HiRDB Control Managerの改竄防止ウィザードを使用して，改竄防止表に変更する手順を次に示します。なお，手順の画面はWindows版HiRDBサーバで実行した例です。UNIX版HiRDBサーバで実行する場合は，パス名の表記が異なります。

〈手順〉

表T1を次に示す条件を設定した改竄防止表に変更します。

COL_NOTE列は更新可能列にします。

COL_DATE列を挿入履歴保持列とし，行削除禁止期間を10年に設定します。

HiRDB Control Manager - Consoleを起動します。HiRDB Control Manager - Consoleの起動方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

操作対象のHiRDBサーバを登録します。管理HiRDBの登録方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。既に登録してある場合，この手順は必要ありません。

タブメニュー［表操作］から［改ざん防止表移行ウィザード］を選択します。

［改ざん防止ウィザード - 1/5］画面が表示されます。

改竄防止表に変更する表名を選択して，［パスワード］テキストボックスに，表所有者のパスワードを入力してください。ここで入力する値は，大文字と小文字の区別をします。

［次へ＞］ボタンをクリックします。

［改ざん防止ウィザード - 2/5］画面が表示されます。

この画面では，行削除禁止期間を設定します。行削除禁止期間を設定しない場合は，［表データの削除を行わない］が選択されていることを確認してください。行削除禁止期間を設定する場合は，［一定期間後に表のデータの削除を許可する］を選択し，［挿入履歴保持列名］と［行削除禁止期間］を設定してください。

［次へ＞］ボタンをクリックします。

［改ざん防止ウィザード - 3/5］画面が表示されます。

この画面では，更新可能列を設定します。更新可能列を設定しない場合は，［列単位でのデータの更新を許可しない］が選択されていることを確認してください。更新可能列を設定する場合は，［一部の列の更新を許可する］を選択してください。次に，［列一覧］リストから更新可能にする列名を選択し，［＞］ボタンをクリックして［更新可能列一覧］リストに追加してください。

［次へ＞］ボタンをクリックします。

［改ざん防止ウィザード - 4/5］画面が表示されます。

この画面では，変更処理中に使用する一時ファイルを格納するディレクトリについて指定します。［一時ファイル格納先一覧］リストに既定値が設定されていますので，必要に応じて変更してください。

［次へ＞］ボタンをクリックします。

［改ざん防止ウィザード - 5/5］画面が表示されます。

設定した条件を確認します。設定を変更したい場合は，［＜戻る］ボタンをクリックして，前の画面に戻ります。

問題がなければ［実行］ボタンをクリックします。変更処理が始まります。

注意事項

改竄防止ウィザード実行後は，ディクショナリ用RDエリアと表データの回復に必要なRDエリアのバックアップを取得してください。バックアップは，HiRDB Control Managerのバックアップウィザードで実行できます。

参考

HiRDB Control Managerでは，改竄防止表は通常表と区別して表示されます。タブメニュー［マップ］から［表］を選択して，［表マップ］画面を表示すると，変更した表が改竄防止属性であることが確認できます。

(2)　HiRDBのコマンドを使用する方法

HiRDBのコマンドを使用して，改竄防止表に変更する手順を次に示します。

〈手順〉

RDエリア（RDAREA01）に格納されている表T1を改竄防止表に変更します。

pdholdコマンドで，非改竄防止表が格納されているRDエリアとデータディクショナリ用RDエリア（RDDIC01）をバックアップ閉塞します。

pdhold -r RDAREA01,RDDIC01 -b

バックアップ対象のRDエリアが属するサーバ（bes01，dic01）のシステムログファイルをスワップさせます。

pdlogswap -d sys -s bes01 -w
pdlogswap -d sys -s dic01 -w

データベース複写ユティリティ（pdcopy）を実行してRDエリアのバックアップを取得します。

バックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

pdcopy -m C:¥hirdb¥rdarea¥mast¥mast01 -M r -p C:¥usr¥hirdb¥pdcopy¥pdcopy01 -b C:¥usr¥hirdb¥pdcopy¥backup¥backup01 -r RDAREA01,RDDIC01

pdrelsコマンドで，データディクショナリ用RDエリアの閉塞を解除します。

pdrels -r RDDIC01

非改竄防止表のデータを，データベース再編成ユティリティ（pdrorg）を使用してアンロードします。このとき，後でデータベース作成ユティリティ（pdload）の入力データとして使用できるように，-Wオプションを指定してアンロードしてください。制御文ファイル（control_file）については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

pdrorg -k unld -t T1 -W bin control_file

pdrelsコマンドで，ユーザ用RDエリアの閉塞を解除します。なお，9.で再度RDエリアを閉塞するまで，これ以降RDエリアへのアクセスは行わないでください。この間に対象となる表が更新された場合，データの不整合が発生するおそれがあります。

pdrels -r RDAREA01

非改竄防止表のデータをPURGE TABLEですべて削除します。

PURGE TABLE T1

ALTER TABLEで改竄防止オプションを指定して，改竄防止表に変更します。

ALTER TABLE T1 CHANGE INSERT ONLY

pdholdコマンドで，改竄防止表が格納されているRDエリアを閉塞します。

pdhold -r RDAREA01

5.でアンロードしたデータを，データベース作成ユティリティ（pdload）でロードします。制御文ファイル（control_file）については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

pdload -b -W T1 control_file

pdrelsコマンドで，RDエリアの閉塞を解除します。

pdrels -r RDAREA01

pdholdコマンドで，バックアップ対象のRDエリアをバックアップ閉塞します。

pdhold -r RDAREA01,RDDIC01 -b

バックアップ対象のRDエリアが属するサーバ（bes01，dic01）のシステムログファイルをスワップさせます。

pdlogswap -d sys -s bes01 -w
pdlogswap -d sys -s dic01 -w

データベース複写ユティリティ（pdcopy）を実行してRDエリアのバックアップを取得します。

バックアップの取得方法については，マニュアル「HiRDB システム運用ガイド」を参照してください。

pdcopy -m C:¥hirdb¥rdarea¥mast¥mast01 -M r -p C:¥usr¥hirdb¥pdcopy¥pdcopy01 -b C:¥usr¥hirdb¥pdcopy¥backup¥backup01 -r RDAREA01,RDDIC01

pdrelsコマンドで，RDエリアの閉塞を解除します。

pdrels -r RDAREA01,RDDIC01

なお，改竄防止オプションの設定時期はディクショナリ表のSQL_TABLES表の値で確認できます。SQL_TABLES表の値の意味を次の表に示します。

表12‒8　SQL_TABLES表の値の意味

改竄防止オプションの設定 | SQL_TABLES
INSERT_ONLY列の値 | CHANGE_TIME_INSERT_ONLYの値
なし | NULL | NULL
CREATE TABLE実行時に指定 | Y | NULL
ALTER TABLE実行時に指定 | Y | 改竄防止表への変更日時

12.15.4　障害時の運用

改竄防止表格納RDエリアは再初期化（initialize rdarea）できないため，RDエリアの回復のとき，再初期化を使った回復はできません。データベース回復ユティリティ（pdrstr）で回復してください。また，RDエリア満杯時はexpand rdarea文でRDエリアを拡張してください。

12.16　繰返し列を含む表

12.16.1　繰返し列を含む表の効果と指定方法

HiRDBでは，複数の要素から構成される列（繰返し列）を含む表を定義できます。要素とは，繰返し列中で繰り返されている各項目のことをいいます。従来は，このような表を定義する場合，次の図のように作成する必要がありました。繰返し列を定義しない表の例を次の図に示します。

図12‒25　繰返し列を定義しない表の例

[picture]

この二つの表をアクセスする場合，結合する必要があります。結合することで，SQLの構文が複雑になるなどのデメリットが発生します。そこで，繰返し列を含む表を作成することで，一つの表として作成できるため，結合が不要になります。

繰返し列を含む表の例を次の図に示します。

図12‒26　繰返し列を含む表の例

[picture]

〔説明〕

「資格」，「家族」，「続柄」，「扶養」が繰返し列になります。

(1)　繰返し列を含む表を定義したときの効果

多値多重性のある表を行ごとにまとめた形で表現できます。このため，次に示す効果が期待できます。

複数の表の結合が不要になります。

重複する情報がなくなるため，ディスク容量を削減できます。

関連データ（繰返しデータ）が近くに格納されるため，別の表にするよりアクセス性能が優れています。

(2)　指定方法

繰返し列を指定するには，定義系SQLのCREATE TABLEの列定義にARRAYオプションを指定します。

繰返し列を含む表の定義例を次に示します。この定義例は図「繰返し列を含む表の例」に示した社員表の場合です。なお，社員表には，「続柄」，「扶養」に複数列インデクスが定義されているものとします。

（例）

CREATE TABLE 社員表
(氏名 NVARCHAR(10),
 資格 NVARCHAR(20) ARRAY[10],
 性別 NCHAR(1),
 家族 NVARCHAR(5) ARRAY[10],
 続柄 NVARCHAR(5) ARRAY[10],
 扶養 SMALLINT ARRAY[10]);

CREATE INDEX 扶養IDX ON 社員表 (続柄,扶養);

注　扶養IDXは，社員表に付けたインデクス名です。

(3)　注意

次に示すデータ型に対して繰返し列を指定できません。

BLOB型

BINARY型

抽象データ型

クラスタキーを指定した列には，繰返し列を指定できません。

FIXを指定した場合，繰返し列を指定できません。

繰返し列に対して格納条件，ハッシュ分割，サプレスオプションを指定できません。

キーレンジ分割をする場合，境界値を指定する列に繰返し列を指定できません。

繰返し列には非ナル値制約を指定できません。

12.17　抽象データ型を含む表

12.17.1　抽象データ型の効果と継承

HiRDBでは表を構成する列のデータ型として抽象データ型を定義できます。

抽象データ型とは，既定義のデータ型で扱えないような複雑なデータを扱いやすく表現するための構造を持ったデータ型のことです。HiRDBでは，このようなデータ型をユーザが抽象データ型として定義できます。抽象データ型では，構造を示す属性とその値に対する操作をひとまとまりとし，定義系SQLによって定義できます。

抽象データ型は，数値型や文字型などの既定義のデータ型と同様に，表を構成する列のデータ型としてを扱えます。

抽象データ型を含む表のデータ構造を次の図に示します。次の図では，社員表中の「従業員」列のデータ型を抽象データ型「t_従業員型」としています。

図12‒27　抽象データ型を含む表のデータ構造

[picture]

(1)　抽象データ型を定義した場合の効果

複雑な構造のデータを一つの値として扱えます。

データとそれに対する操作を一体化することで，オブジェクト指向のアプリケーションとマッピングしやすくなります。

データとそのデータに対する操作をひとまとまりとし，操作を外部的なインタフェースとすることで，データの内部情報を意識することなくデータを扱えます。

(2)　継承の概要

(a)　継承（inheritance）

HiRDBでは，既に定義した抽象データ型を基に，その型に定義された属性と操作を受け継いだ新しい抽象データ型を導出し定義できます。基になる型をスーパタイプといい，導出した型をサブタイプといいます。サブタイプがスーパタイプの属性及び関数を引き継ぐことを継承といいます。

スーパタイプ−サブタイプの関係は階層的に表現できます。これによって，複雑な概念モデルを抽象データ型を用いて階層化して表現できます。

抽象データ型のスーパタイプ−サブタイプ関係に基づく階層構造を次の図に示します。次の図では，抽象データ型「従業員」から，サブタイプ「営業部員」を導出しています。

図12‒28　抽象データ型のスーパタイプ−サブタイプ関係に基づく階層構造

[picture]

(b)　代替可能性（substitutability）

サブタイプの値は，そのスーパタイプの値として扱うことができます。これを代替可能性（substitutability）といいます。代替可能性を利用して値を挿入した抽象データ型を含む表のデータ構造を次の図に示します。

図12‒29　抽象データ型を含む表のデータ構造（代替可能性を利用した場合）

[picture]

(c)　多重定義（override）

HiRDBでは，上位の抽象データ型（スーパタイプ）で定義されたルーチンと同じ名前のルーチンを下位の抽象データ型（サブタイプ）の定義で上書きして定義できます。このように上書きして定義することを多重定義（override）といいます。多重定義によって，呼び出すルーチンの名称を型によって変更する必要がありません。

(3)　継承を利用したときの効果

継承を利用することで，次に示す効果が期待できます。

上位の抽象データ型の特性（データ及び操作）を下位の抽象データ型でも利用できます。

サブタイプを定義することで，最初から定義し直さなくてもデータ定義を共有できます。これによって，データベースの定義の手間が省けます。

多重定義によって，呼び出すルーチンの名称を型によって変更する必要がありません。

(4)　抽象データ型の定義方法

抽象データ型を定義するには，定義系SQLのCREATE TYPEを実行します。CREATE TYPEでは，構造を示すための属性と，値に対する操作を定義します。また，継承を利用する場合はCREATE TYPEでサブタイプ句を指定して定義します。CREATE TYPEの定義例については，「ユーザが定義した抽象データ型を定義した表の作成」を参照してください。

(a)　コンストラクタ関数の定義

抽象データ型の値を生成するための関数（コンストラクタ関数）を定義します。コンストラクタ関数の実装で，抽象データ型の定義時にHiRDBによって提供されるデフォルトコンストラクタ関数を利用できます。デフォルトコンストラクタ関数は，すべての属性がナル値である値を生成します。

(b)　ルーチンの定義

抽象データ型の定義内に，ある属性の値を操作するインタフェースとしてルーチンを定義できます。

(c)　隠蔽レベルの指定

抽象データ型を構成する属性及びルーチンに対するアクセスを制御するため，隠蔽レベルを指定できます。隠蔽レベルは，属性及びその抽象データ型の値に対する操作であるルーチンに指定できます。隠蔽レベルには，次に示す3種類があります。

PUBLIC

その抽象データ型やサブタイプ以外の抽象データ型の定義中，アプリケーションからも属性の値へアクセスさせたい場合及びルーチンを使用させたい場合に指定します。

PRIVATE

内部情報がアプリケーションによって直接変更されることを防ぎたい場合などに，その抽象データ型の定義中だけで，属性の値へアクセスさせたい場合及びルーチンを使用させたい場合に指定します。SQLで属性の値へアクセスさせたい場合及びルーチンを使用したい場合は，関数を定義する必要があります。

PROTECTED

情報秘匿のため，アプリケーションから直接参照させたくない場合などに，その抽象データ型の定義中及びその抽象データ型のサブタイプの定義中でだけ属性の値へアクセスさせたい場合やルーチンを使用させたい場合に指定します。

抽象データ型の定義内でいったん隠蔽レベルを指定すると，次に別の隠蔽レベルの指定が出現するまでは直前の隠蔽レベルが有効になります。また，隠蔽レベルの指定がない場合，PUBLICが仮定されます。隠蔽レベルの違いによって，データへのアクセス，ルーチンの使用権限の範囲が異なります。

隠蔽レベルと権限を次の表に示します。

表12‒9　隠蔽レベルと権限

隠蔽レベル | アクセス元
その抽象データ型の定義内 | サブタイプの抽象データ型の定義内 | 左記以外の抽象データ型の定義内 | アプリケーション
PUBLIC | ○ | ○ | ○ | ○
PRIVATE | ○ | × | × | ×
PROTECTED | ○ | ○ | × | ×

（凡例）

○：属性値へのアクセス及びルーチンを使用できます。

×：属性値へのアクセス及びルーチンを使用できません（SQLエラーになります）。

12.18　共用表

HiRDB/パラレルサーバの場合，複数の表を結合するとき，それぞれの表が配置されたバックエンドサーバから表データを読み込み，別のバックエンドサーバで突き合わせ処理をします。そのため，複数のサーバを接続し，データを転送する処理が発生します。このとき，結合処理のための検索範囲のデータが一つのバックエンドサーバにあれば，そのデータを共用表として作成することで一つのバックエンドサーバで結合処理が完結します。共用表とは，共用RDエリアに格納された表で，すべてのバックエンドサーバから参照できる表のことです。また，共用表に定義するインデクスを，共用インデクスといいます。共用表を更新できるのは更新可能バックエンドサーバだけです。ほかのバックエンドサーバは参照専用バックエンドサーバになります。ただし，共用表の更新には制限があるため，原則としてオンライン中は更新しないでください。共用表の更新については，「共用表の操作」を参照してください。共用表を使用しない結合処理と使用した結合処理を次の図に示します。

図12‒30　共用表を使用しない結合処理

[picture]

〔説明〕

表Aと表Bの結合処理をします。

BES1，2：表Aからデータを取り出し，突き合わせ処理のため，BES5とBES6にデータを転送します。

BES3，4：表Bからデータを取り出し，突き合わせ処理のため，BES5とBES6にデータを転送します。

BES5，6：突き合わせ，結合処理をしてFESにデータを転送します。

FES：結合処理した結果をマージして，ユーザに結果を返します。

図12‒31　共用表を使用した結合処理

[picture]

〔説明〕

表Aと表Bの結合処理をします。共通データがある表Bを共用表とします。検索範囲はBES2，3のバックエンドサーバにあります。

BES1，4，5，6：特に処理はありません。

BES2，3：表A及び表Bからデータを取り出し，マージ処理をしてFESにデータを転送します。

FES：ユーザに結果を返します。

共用表及び共用インデクスはHiRDB/シングルサーバにも定義できます。これによって，HiRDB/パラレルサーバとSQL及びUAPの互換性を保つことができます。共用表及び共用インデクスはHiRDB/パラレルサーバで有効なので，通常はHiRDB/パラレルサーバで使用します。ここでは，HiRDB/パラレルサーバで共用表を使用する場合について説明します。HiRDB/シングルサーバで共用表を使用する場合については，「HiRDB/シングルサーバで共用表を使用する場合」を参照してください。

12.18.1　効果と適用基準

(1)　共用表の効果

一つのバックエンドサーバで結合処理が完結するため，バックエンドサーバ間の接続やデータ転送によるオーバヘッドが削減できます。また，トランザクションごとに使用するバックエンドサーバ数を少なくできるため，多重実行時などに並列処理の効率が上がります。

(2)　適用基準

更新処理が少なく，結合処理など複数のトランザクションから参照されるような表は，共用表として作成することをお勧めします。

12.18.2　定義方法

定義系SQLのCREATE TABLEでSHAREを指定（CREATE SHARE FIX TABLEと指定）します。なお，共用表は次の条件を満たす必要があります。

共用表は非分割のFIX表である

共用表，及び共用インデクスを格納するRDエリアは共用RDエリア（pdfmkfsコマンドの-kオプションにSDBを指定）である

WITHOUT ROLLBACKオプションが指定されていない

参照制約が定義された参照表でない

12.18.3　共用表の操作

(1)　検索

共用表はすべてのバックエンドサーバから参照できるため，共用表を検索するために最適なバックエンドサーバをHiRDBが決定します。なお，共用表を更新すると全バックエンドサーバで排他が掛かるため，検索処理と更新処理とのデッドロックが発生することがあります。デッドロックを回避するために，共用表の検索時は次のようにすることをお勧めします。

排他オプションにWITHOUT LOCK，又はWITHOUT LOCK NOWAITを指定する

共用表を更新するために検索する場合，FOR UPDATE句を指定する

なお，共用表に対してIN EXCLUSIVE MODE指定でLOCK文を実行すると，対象の共用表と共用インデクスが格納されているRDエリアに排他を掛けます。検索する表がLOCK文の対象ではなくても，アクセスするRDエリアが同じであれば排他制御されます。そのため，WITHOUT LOCK NOWAITを指定していても，ほかのトランザクションがIN EXCLUSIVE MODE指定でLOCK文を実行している場合は，共用表にアクセスできません。そのため，IN EXCLUSIVE MODE指定のLOCK文実行中は共用表を検索できません。

HiRDBが決定するバックエンドサーバの割り当て規則については，「共用表を検索するバックエンドサーバの割り当て規則」を参照してください。

(2)　更新

共用表を更新する場合，LOCK文でIN EXCLUSIVE MODEを指定し，全バックエンドサーバの共用RDエリアに排他を掛けなければ実行できません。ただし，インデクスキー値を変更しないUPDATE文は，LOCK文を発行しないで実行できます。共用表及び共用インデクスの更新は，COMMIT文発行時にディスクに書き込まれます。

なお，ローカルバッファを使用して共用表を更新する場合は，LOCK文を発行して更新してください。LOCK文を発行しない更新をしていて，サーバプロセスが異常終了すると，アボートコードPhb3008が出力されます（ユニットが異常終了することがあります）。

(a)　LOCK文を発行する更新

LOCK文を発行する更新の流れを次に示します。

IN EXCLUSIVE MODE指定でLOCK文を発行します。

このとき，共用表だけでなく，共用表が格納されている共用RDエリア及び共用インデクスが格納されている共用RDエリアにも排他が掛かります。参照専用バックエンドサーバの共用RDエリアのグローバルバッファは無効化されます。

共用表に対して，INSERT，UPDATE，又はDELETE文を実行します。

更新可能バックエンドサーバが更新情報をファイルに反映します。

LOCK文が解除されるまで共用RDエリアに排他が掛かるので，同じ共用RDエリアにある，別の共用表への操作は待ち状態になります。

LOCK文を解除します。

注意事項

LOCK文はUAPの最初に発行してください。LOCK文発行時，関連する共用RDエリア内の表に対して，自サーバプロセスでオープン中のカーソルがあると，LOCK文はエラーになります。

共用表を更新する手続き及びトリガを作成する場合，LOCK文を記述してください。ただし，手続き及びトリガからLOCK文を実行する場合はトランザクションの開始時点から排他が掛かりません。そのため，エラーになるおそれがあります。

全バックエンドサーバで共用表，共用表が格納されている共用RDエリア，及び共用インデクスが格納されている共用RDエリアに排他を掛けるため，該当するRDエリアの表又はインデクスにアクセスする業務があると，デッドロック，又はサーバ間のグローバルデッドロックが発生するおそれがあります。

共用表を更新するトランザクションの決着前に更新可能バックエンドサーバのユニットが異常終了して再開始しない場合に次のような検索をすると，排他タイムアウトエラーになります（KFPA11770-Iメッセージが出力されます）。

・別のユニットの参照専用バックエンドサーバで，更新対象の共用表又はその表に定義されているインデクスが格納されているRDエリア内の表を検索

(b)　LOCK文を発行しない更新

LOCK文を発行しない場合，実行できるのはインデクスキー値の変更がないUPDATE文だけです。また，少量の変更の場合だけにしてください。

LOCK文を発行しない更新の流れを次に示します。

全バックエンドサーバの状態を同じにするため，更新情報を全バックエンドサーバに配布します。

更新可能バックエンドサーバが更新情報をデータベースに反映します。

参照専用バックエンドサーバでは，グローバルバッファ上で更新し，COMMIT文発行までファイルに反映しないで更新情報を保持します。トランザクションがロールバックした場合，グローバルバッファ上で回復します。

注意事項

参照専用バックエンドサーバで，グローバルバッファがすべて更新中，かつCOMMIT文未発行で空きページがない状態になった場合，トランザクションはロールバックします。このため，LOCK文を発行しない場合は大量のデータを更新しないでください。

全バックエンドサーバで更新行に排他を掛けるため，同時に該当する表にアクセスする業務があるとデッドロック，又はサーバ間のグローバルデッドロックが発生するおそれがあります。デッドロックを回避するため，UPDATE文で更新する行はトランザクションで1件だけにすることをお勧めします。

共用表を更新するトランザクションの決着前に更新可能バックエンドサーバのユニットが異常終了して再開始しない場合に次のような検索をすると，排他タイムアウトエラーになります（KFPA11770-Iメッセージが出力されます）。

・別のユニットの参照専用バックエンドサーバで，更新対象の共用表又はその表に定義されているインデクスが格納されているRDエリア内の表を検索

12.18.4　共用表の制限事項

IN EXCLUSIVE MODE指定のLOCK文実行中は共用表を検索できません。

共用表に対しては，ASSIGN LIST文でリストを作成できません。

レプリケーションの反映先に共用表は指定できません。

12.18.5　共用表を検索するバックエンドサーバの割り当て規則

共用表を検索するバックエンドサーバの割り当て規則について説明します。1SQL中に共用表だけが指定されている場合と，1SQL中に共用表を含む複数の表が指定されている場合とで割り当て規則が異なります。それぞれの割り当て規則について説明します。

(1)　1SQL中に指定されている表が共用表だけの場合

1SQL中に指定されている表が共用表だけの場合，共用表を検索するバックエンドサーバの割り当ては，同一トランザクション内の直前のSQLでどのような検索を行ったかなどの条件によって決まります。

共用表を検索するバックエンドサーバの割り当て規則（1SQL中に指定されている表が共用表だけの場合）を次の表に示します。項番1が最も優先順位が高くなっています。

表12‒10　共用表を検索するバックエンドサーバの割り当て規則（1SQL中に指定されている表が共用表だけの場合）

項番 | 検索条件 | 割り当てられるバックエンドサーバ
1 | 次に示すどちらかの条件を満たす場合 検索対象の共用表に対して，IN EXCLUSIVE MODE指定のLOCK TABLE文を実行している FOR UPDATE句による検索を行っている | 更新可能バックエンドサーバを割り当てます。
2 | 同一トランザクション内の（又は複数のトランザクションにわたって※1）異なるSQL内で共用表※2を使用している場合 | 同一トランザクション内の共用表検索のうち，直前に実行したSQL文内で共用表へのアクセスに使用したバックエンドサーバを割り当てます。 バックエンドサーバの割り当ての例については，例1を参照してください。
3 | 同一トランザクション内の（又は複数のトランザクションにわたって※1）異なるSQL内で横分割表※3を使用し，分割列に1バックエンドサーバだけの検索が行われる制限条件※4がある場合 | 同一トランザクション内の分割列に，1バックエンドサーバだけの検索が行われる制限条件がある横分割表検索のうち，直前に実行したSQL文内で横分割表へのアクセスに使用したバックエンドサーバの中から，ランダムに割り当てます。 バックエンドサーバの割り当ての例については，例2を参照してください。
4 | 同一トランザクション内の（又は複数のトランザクションにわたって※1）異なるSQL内で非分割表※5を使用している場合 | 同一トランザクション内の非分割表検索のうち，直前に実行したSQL文内で非分割表へのアクセスに使用したバックエンドサーバの中から，ランダムに割り当てます。 バックエンドサーバの割り当ての例については，例3を参照してください。
5 | 同一トランザクション内の（又は複数のトランザクションにわたって※1）異なるSQL内で横分割表を使用している場合 | 同一トランザクション内の横分割表検索のうち，直前に実行したSQL文内で横分割表へのアクセスに使用したバックエンドサーバの中から，ランダムに割り当てます。 バックエンドサーバの割り当ての例については，例4を参照してください。
6 | 接続したフロントエンドサーバと同じユニットにバックエンドサーバがある場合 | フロントエンドサーバと同じユニット内にあるバックエンドサーバの中からランダムに割り当てます。 バックエンドサーバの割り当ての例については，例5を参照してください。
7 | 項番1〜6に該当しない場合 | バックエンドサーバをランダムに割り当てます。 バックエンドサーバの割り当ての例については，例6を参照してください。

注※1

バックエンドサーバ接続保持機能，ホールダブルカーソル，及びAP単位のローカルバッファの使用時を指します。

注※2

IN EXCLUSIVE MODE指定のLOCK TABLE文を実行している共用表，及びFOR UPDATE句による検索を行う共用表を除きます。

注※3

フレキシブルハッシュ分割，及び1バックエンドサーバ内での分割の場合を除きます。

注※4

探索条件中の一つの表の列だけを指定した条件（述語，又はOR演算された述語）です。

注※5

IN EXCLUSIVE MODE指定のLOCK TABLE文を実行している共用表，及びFOR UPDATE句による検索を行う共用表を含みます。

(a)　例1

〔説明〕

SQL1で共用表S1へのアクセスに使用したバックエンドサーバをBES2とします。

SQL2で横分割表Dへのアクセスに使用したバックエンドサーバをBES1，BES2，及びBES3とします。

SQL1，SQL2の直後に，SQL3で共用表S2にアクセスする場合，共用表S1へのアクセスに使用したBES2を割り当てます。

(b)　例2

〔説明〕

SQL1では，分割列に1バックエンドサーバだけの検索が行われる制限条件を付けて横分割表D1と，横分割表D2を検索します。横分割表D1へのアクセスに使用したバックエンドサーバをBES2，横分割表D2へのアクセスに使用したバックエンドサーバをBES3とします。

SQL2で，非分割表Nへのアクセスに使用したバックエンドサーバをBES1とします。

SQL1，SQL2の直後に，SQL3で共用表Sにアクセスする場合，横分割表D1，及び横分割表D2へのアクセスに使用したバックエンドサーバのうち，ランダムに選んだBES2を割り当てます（ランダムに割り当てるため，BES3となる場合もあります）。

(c)　例3

〔説明〕

SQL1では，非分割表N1と，非分割表N2を検索します。非分割表N1へのアクセスに使用したバックエンドサーバをBES2，非分割表N2へのアクセスに使用したバックエンドサーバをBES3とします。

SQL2で，横分割表Dへのアクセスに使用したバックエンドサーバを，BES1，BES2，及びBES3とします。

SQL1，SQL2の直後に，SQL3で共用表Sにアクセスする場合，非分割表N1と，非分割表N2へのアクセスに使用したバックエンドサーバのうち，ランダムに選んだBES2を割り当てます（ランダムに割り当てるため，BES3となる場合もあります）。

(d)　例4

〔説明〕

SQL1では，横分割表D1と横分割表D2を検索します。横分割表D1へのアクセスに使用したバックエンドサーバをBES1及びBES2，横分割表D2へのアクセスに使用したバックエンドサーバをBES2及びBES3とします。

SQL2で，横分割表D3へのアクセスに使用したバックエンドサーバをBES1及びBES2とします。

SQL1，SQL2の直後に，SQL3で共用表Sにアクセスする場合，横分割表D3へのアクセスに使用したバックエンドサーバのうち，ランダムに選んだBES2を割り当てます（ランダムに割り当てるため，BES1となる場合もあります）。

(e)　例5

〔説明〕

トランザクションを開始した直後に共用表Sにアクセスする場合，フロントエンドサーバと同じユニットにあるバックエンドサーバBES2を割り当てます。

(f)　例6

〔説明〕

トランザクションを開始した直後に共用表Sにアクセスする場合，ランダムに選んだバックエンドサーバBES2を割り当てます（ランダムに割り当てるため，BES1又はBES3となる場合もあります）。

(2)　1SQL中に共用表を含む複数の表が指定されている場合

1SQL中に指定されている表が共用表を含む複数の表の場合，共用表を検索するバックエンドサーバの割り当ては，同一SQL内でどのような検索を行ったかなどの条件によって決まります。なお，1SQL中に共用表と非共用表の両方を含む場合には，非共用表にバックエンドサーバを割り当てた後，共用表にバックエンドサーバを割り当てます。

共用表を検索するバックエンドサーバの割り当て規則（1SQL中に共用表を含む複数の表が指定されている場合）を次の表に示します。項番1が最も優先順位が高くなっています。

表12‒11　共用表を検索するバックエンドサーバの割り当て規則（1SQL中に共用表を含む複数の表が指定されている場合）

項番 | 検索条件 | 割り当てられるバックエンドサーバ
1 | 次に示すどちらかの条件を満たす場合 検索対象の共用表に対して，IN EXCLUSIVE MODE指定のLOCK TABLE文を実行している FOR UPDATE句による検索を行っている | 更新可能バックエンドサーバを割り当てます。
2 | 同一SQL内で共用表※1を使用している場合 | 同一SQL内で共用表を複数使用している場合は，同じバックエンドサーバを割り当てます。すべての表が共用表の場合は，表「共用表を検索するバックエンドサーバの割り当て規則（1SQL中に指定されている表が共用表だけの場合）」に従って割り当てます。 バックエンドサーバの割り当ての例については，例7を参照してください。
3 | 同一SQL内で横分割表※2を使用し，分割列に1バックエンドサーバだけの検索が行われる制限条件※3がある場合 | 同一SQL内で使用している横分割表へのアクセスに使用したバックエンドサーバの中から，ランダムに割り当てます。 バックエンドサーバの割り当ての例については，例8を参照してください。
4 | 同一SQL内で非分割表※4を使用している場合 | 同一SQL内で使用している非分割表へのアクセスに使用したバックエンドサーバの中から，ランダムに割り当てます。 バックエンドサーバの割り当ての例については，例9を参照してください。
5 | 同一SQL内で横分割表を使用している場合 | 同一SQL内で使用している横分割表へのアクセスに使用したバックエンドサーバの中から，ランダムに割り当てます。 バックエンドサーバの割り当ての例については，例10を参照してください。

注※1

IN EXCLUSIVE MODE指定のLOCK TABLE文を実行している共用表，及びFOR UPDATE句による検索を行う共用表を除きます。

注※2

フレキシブルハッシュ分割，及び1バックエンドサーバ内での分割の場合を除きます。

注※3

探索条件中の一つの表の列だけを指定した条件（述語，又はOR演算された述語）です。

注※4

IN EXCLUSIVE MODE指定のLOCK TABLE文を実行している共用表，及びFOR UPDATE句による検索を行う共用表を含みます。

(a)　例7

〔説明〕

同一SQL内で共用表S1，及び共用表S2を検索します。

共用表S1へのアクセスに使用したバックエンドサーバをBES2とします。

1.の直後に共用表S2にアクセスする場合，共用表S1へのアクセスに使用したバックエンドサーバBES2を割り当てます。

(b)　例8

〔説明〕

同一SQL内で，横分割表D1，横分割表D2，共用表Sを検索します。

分割列に1バックエンドサーバだけの検索が行われる制限条件を付けて横分割表D1を検索します。横分割表D1へのアクセスに使用したバックエンドサーバをBES2とします。

分割列に1バックエンドサーバだけの検索が行われる制限条件を付けて横分割表D2を検索します。横分割表D2へのアクセスに使用したバックエンドサーバをBES3とします。

1.，2.の直後に共用表Sにアクセスする場合，横分割表D1，及び横分割表D2へのアクセスに使用したバックエンドサーバのうち，ランダムに選んだBES2を割り当てます（ランダムに割り当てるため，BES3となる場合もあります）。

(c)　例9

〔説明〕

同一SQL内で，非分割表N1，非分割表N2，共用表Sを検索します。

非分割表N1へのアクセスに使用したバックエンドサーバをBES2とします。

非分割表N2へのアクセスに使用したバックエンドサーバをBES3とします。

1.，2.の直後に共用表Sにアクセスする場合，非分割表N1と非分割表N2へのアクセスに使用したバックエンドサーバのうち，ランダムに選んだBES2を割り当てます（ランダムに割り当てるため，BES3となる場合もあります）。

(d)　例10

〔説明〕

同一SQL内で，横分割表D1，横分割表D2，共用表Sを検索します。

横分割表D1へのアクセスに使用したバックエンドサーバをBES1及びBES2とします。

横分割表D2へのアクセスに使用したバックエンドサーバをBES2及びBES3とします。

1.，2.の直後に共用表Sにアクセスする場合，横分割表D1，横分割表D2へのアクセスに使用したバックエンドサーバのうち，ランダムに選んだBES2を割り当てます（ランダムに割り当てるため，BES1又はBES3となる場合もあります）。

12.18.6　定義系SQL，ユティリティ，及び運用コマンド実行時の注意

定義系SQL，ユティリティ，及び運用コマンドで共用表又は共用インデクスを対象とする場合，HiRDBが内部的にLOCK文を発行し，全バックエンドサーバで表と処理対象のRDエリアに対してIN EXCLUSIVE MODE指定で排他を掛けることがあります。このため，該当するRDエリア内の表やインデクスにアクセス中の業務があると，デッドロック，又はサーバ間のグローバルデッドロックが発生するおそれがあります。

HiRDBが内部的にLOCK文を発行する定義系SQLを次に示します。

共用表に対するCREATE TABLE，DROP TABLE，PURGE TABLE

共用インデクスに対するCREATE INDEX，DROP INDEX

共用表を含むスキーマに対するDROP SCHEMA

共用表に対する空き領域の再利用機能の変更（ALTER TABLE）

共用表に対する主キーの追加及び削除（ALTER TABLE）

HiRDBが内部的にLOCK文を発行するユティリティを次に示します。

データベース作成ユティリティ（pdload）

データベース再編成ユティリティ（pdrorg -k reld，rorg，ixrc，ixmk，ixor）

空きページ解放ユティリティ（pdreclaim）

データベース定義ユティリティ（pddef）

データディクショナリ搬出入ユティリティ（pdexp）

データベース構成変更ユティリティ（pdmod -a initialize rdarea）

共用RDエリアに対して実行できないユティリティや運用コマンドについては，「共用RDエリア使用上の制限事項」を参照してください。

12.18.7　HiRDB/シングルサーバで共用表を使用する場合

HiRDB/パラレルサーバの場合との相違点について説明します。

注意事項について

HiRDB/シングルサーバで共用表を使用する場合の注意（共用表の操作時の注意事項，共用表の制限事項，及び定義系SQL，ユティリティ，及び運用コマンド実行時の注意）は，基本的にHiRDB/パラレルサーバと同じです。ただし，HiRDB/シングルサーバはサーバが一つだけなので，サーバ間のデッドロックは発生しません。また，HiRDB/パラレルサーバの場合の運用コマンド実行時の注意は，HiRDB/シングルサーバの場合は該当しません。

共用表及び共用インデクスの格納RDエリアについて

HiRDB/シングルサーバでは共用RDエリアを定義できないため，共用表及び共用インデクスは，通常のユーザ用RDエリアに格納してください。このとき，共用表及び共用インデクスを格納するユーザ用RDエリアと，共用表ではない表及び共用インデクスではないインデクスを格納するユーザ用RDエリアは別にしてください。同じユーザ用RDエリアに混在していると，デッドロックが発生するおそれがあります（共用表を更新中は，共用表及び共用インデクスが格納されているRDエリアにも排他が掛かるため，該当するRDエリアの表又はインデクスにアクセスする業務があると排他待ちになります）。

ローカルバッファの使用について

HiRDB/シングルサーバでローカルバッファを使用して共用表及び共用インデクスを更新する場合，LOCK文を発行しない更新をしていて，サーバプロセスが異常終了しても，アボートコードPhb3008を出力してHiRDBが異常終了することはありません。

HiRDB/シングルサーバからHiRDB/パラレルサーバへの移行について

移行する場合，HiRDB/シングルサーバのシステム内に共用表及び共用インデクスが定義されている状態で，データベース構成変更ユティリティ（pdmod）を使用してHiRDB/パラレルサーバに移行しないでください。移行手順を次に示します。

HiRDB/シングルサーバで定義している共用表及び共用インデクスがあるかどうかを確認します。

次に示すSQL文（システム内に定義されている共用表の名称を確認するため，データディクショナリ表（SQL_TABLES）を検索する）を実行します。表名が出力されなければ，共用表は定義されていません。表名が出力されたら，共用表が定義されています。

SELECT TABLE_NAME
FROM MASTER.SQL_TABLES
WHERE SHARED=’S’
WITHOUT LOCK NOWAIT

HiRDB/シングルサーバで定義している共用表及び共用インデクスがあれば，すべて削除します。

データベース構成変更ユティリティ（pdmod）を使用してHiRDB/パラレルサーバに移行します。

HiRDB/パラレルサーバで共用RDエリアを定義し，共用表及び共用インデクスを定義し直し，共用RDエリアに格納します。

12.19　参照制約

12.19.1　参照制約とは

データベース中の表は，それぞれ独立しているのではなく，お互いに関連を持っている場合があります。一方の表に関連するデータがないと，ほかの表でそのデータの意味がないことがあります。表間のデータの参照整合性を保つため，表定義時に特定の列（外部キーといいます）に定義する制約が参照制約です。参照制約及び外部キーを定義した表を参照表，外部キーによって参照表から参照される表を被参照表といいます。被参照表には外部キーによって参照される主キーを定義しておく必要があります。

なお，SQLやユティリティの実行などで被参照表と参照表間の参照整合性が保証できなくなる場合があります。この場合，参照表は検査保留状態になります。検査保留状態については「検査保留状態」を，整合性を保証できなくなる操作については「データ操作と整合性」を参照してください。

被参照表と参照表の例を次の図に示します。この例では，商品表が参照表，製造元表が被参照表となります。参照表の外部キーから主キーを参照し，製造元名が分かります。

図12‒32　被参照表と参照表の例

[picture]

参照制約を定義する場合，外部キーにインデクスを定義すると処理性能が向上します。ただし，被参照表の主キーを更新しない場合は，外部キー値の更新によるインデクス更新のためのオーバヘッドがあるので，更新時の性能が悪くなることがあります。

参照制約の効果

参照制約を定義すると，表間のデータの整合性チェック，及びデータ操作を自動化できるのでUAPを作成するときの負荷を軽減できます。ただし，被参照表や参照表を更新する場合，データの整合性をチェックするため，チェックに掛かる処理時間が増加しますので，注意してください。次のような場合に，チェックに掛かる処理時間が増加します。

更新する列が被参照表の主キーの場合

被参照表の主キーを参照する参照表の外部キーの数に比例して遅くなります。

更新する列が参照表の外部キーの場合

更新する列を構成列とする外部キーの数に比例して遅くなります。

12.19.2　参照制約の定義

参照制約を有効にするためには，外部キーによって参照される主キーを被参照表に定義しておく必要があります。定義系SQLのCREATE TABLEで被参照表にPRIMARY KEY（主キー）を指定します。また，検査保留状態を使用するには，pd_check_pendingオペランドにUSEを指定するか，又はオペランドの指定を省略します。

参照表には，FOREIGN KEY（外部キー）を指定し，FOREIGN KEY句中に次の指定をします。

参照する列

被参照表

参照制約動作

参照制約動作は被参照表に対する挿入，更新，又は削除時の動作をCASCADE，又はRESTRICTで指定します。

CASCADE，又はRESTRICTを指定した場合の被参照表と参照表の動作について説明します。

(1)　CASCADEを指定している場合

CASCADEを指定すると，被参照表の主キーに変更があった場合，外部キーも同じように変更されます。なお，参照表の外部キーに変更がある場合，主キーに変更後の値と同じ値の行があるかどうかをチェックして，参照制約違反エラーになれば外部キーは変更されません。

CASCADEを指定している場合，被参照表及び参照表にSQLを実行するときの動作の例を次の図に示します。

図12‒33　被参照表に更新SQLを実行するときの動作の例（CASCADE指定時）

[picture]

〔説明〕

主キーの値と同じ値の行が外部キーにあれば，制約を保持するために，外部キーも主キーと同じように変更されます。この場合，被参照表への更新は実行されます。挿入及び削除も同じです。

図12‒34　参照表に更新SQLを実行するときの動作の例（CASCADE指定時）

[picture]

〔説明〕

更新後の外部キーの値と同じ値の行が主キーにあれば，外部キーへの更新が実行されます。同じ値の行がなくても，外部キーにナル値があるときは外部キーへの更新が実行されます。ナル値がないときは参照制約違反エラーになります。この場合，被参照表には特に影響はありません。挿入及び削除も同じです。

CASCADEを指定している場合の主キーに対する操作と参照表の動作と外部キーに対する操作と被参照表の動作を次の表に示します。

表12‒12　主キーに対する操作と参照表の動作（CASCADE指定時）

主キーに対する操作 | 被参照表と参照表の行の関係 | 主キーに対する操作結果 | 参照表の動作
挿入（INSERT文） | なし | ○ | 動作しない
更新（UPDATE文）， 削除（DELETE文） | 更新前の主キー構成列の値と同じ外部キー構成列の値を持つ行が，参照表にある | ○ | 主キーと同じ値で更新，又は行削除
更新前の主キー構成列の値と同じ外部キー構成列の値を持つ行が，参照表にない | ○ | 動作しない

（凡例）

○：正常に実行されます。

表12‒13　外部キーに対する操作と被参照表の動作（CASCADE指定時）

外部キーに対する操作 | 参照表と被参照表の行の関係 | 外部キーに対する操作結果 | 被参照表の動作
挿入（INSERT文） | 挿入する行の外部キー構成列の値と同じ主キー構成列の値を持つ行が被参照表にある | ○ | 動作しない
挿入する行の外部キー構成列の値と同じ主キー構成列の値を持つ行が被参照表にない | 外部キー構成列中にナル値がある | ○
外部キー構成列中にナル値がない | ×
更新（UPDATE文） | 更新後の外部キー構成列の値と同じ主キー構成列の値を持つ行が被参照表にある | ○ | 動作しない
更新後の外部キー構成列の値と同じ主キー構成列の値を持つ行が被参照表にない | 外部キー構成列中にナル値がある | ○
外部キー構成列中にナル値がない | ×
削除（DELETE文） | なし | ○ | 動作しない

（凡例）

○：正常に実行されます。

×：制約違反エラーとなります。

なお，CASCADEを指定すると，主キーの変更を外部キーにも反映するため，表定義時にHiRDBが内部的にトリガを生成します。参照制約動作のトリガ，及びユーザが定義するトリガとの関係については，「参照制約とトリガ」を参照してください。

(2)　RESTRICTを指定している場合

RESTRICTを指定すると，被参照表の主キーに変更がある場合，外部キーに同じ値の行があれば，参照制約違反エラーになり，主キーは変更されません。なお，外部キーに変更がある場合，主キーに同じ値の行があるかどうかをチェックして，参照制約違反エラーになれば外部キーは変更されません。

RESTRICTを指定している場合，被参照表に更新SQLを実行するときの動作を次の図に示します。参照表の動作は，CASCADE指定時（図「参照表に更新SQLを実行するときの動作の例（CASCADE指定時）」を参照）と同じです。

図12‒35　被参照表に更新SQLを実行するときの動作の例（RESTRICT指定時）

[picture]

〔説明〕

主キーの値と同じ値の行が外部キーにあれば，参照制約違反エラーになり，主キーへの更新は実行されません。同じ値の行がなければ，被参照表への更新が実行されます。挿入及び削除も同じです。

RESTRICTを指定している場合の主キーに対する操作と被参照表及び参照表の動作を次の表に示します。外部キーに対する操作と被参照表の動作はCASCADE指定時（表「外部キーに対する操作と被参照表の動作（CASCADE指定時）」を参照）と同じです。

表12‒14　主キーに対する操作と被参照表及び参照表の動作

主キーに対する操作 | 被参照表と参照表の行の関係 | 主キーに対する操作結果 | 参照表の動作
挿入（INSERT文） | なし | ○ | 動作しない
更新（UPDATE文）， 削除（DELETE文） | 更新前の主キー構成列の値と同じ外部キー構成列の値を持つ行が，参照表にある | × | 動作しない
更新前の主キー構成列の値と同じ外部キー構成列の値を持つ行が，参照表にない | ○

（凡例）

○：正常に実行されます。

×：制約違反エラーとなります。

(3)　被参照表，及び参照表定義時の制限事項

被参照表と参照表の表定義，表定義変更，及び表削除時の制限事項を次に示します。

(a)　表定義（CREATE TABLE）時

同じ外部キー構成列（並びが同じでなくてもよい）の外部キーから，同じ被参照表を参照することはできません。

次の場合，外部キーは定義できません。

WITHOUT ROLLBACKを指定した表，共用表，及び改竄防止表の場合

被参照表がWITHOUT ROLLBACKを指定した表の場合

共用表の場合

改竄防止表の場合

一時表の場合

被参照表が一時表の場合

外部キーは，一つの表に255個まで定義できます。256個以上は定義できません。

一つの主キーに対して，外部キーは255個まで定義できます。256個以上は定義できません。

参照表定義時に参照できる表は，同一スキーマの表だけです。

次の条件をすべて満たす場合にだけ，一つの表で，同じ主キーを参照するON UPDATE CASCADE（更新時の参照制約動作がCASCADE）を指定した参照表を定義できます。

複数の外部キー構成列が重複していない

複数の外部キー構成列に関連する検査制約，又は参照制約を定義していない

外部キーの文字集合と，その外部キーから参照される表の主キーの文字集合は同じにしてください。

(b)　表定義変更（ALTER TABLE時）

被参照表及び参照表に対して，DROP句及びRENAME句を使用した表定義変更はできません。

被参照表の主キー構成列，外部キー構成列に対して定義を変更する場合，次の制限があります。

CHANGE句を使用したデータ型やデータ長の変更はできない

RENAME句を使用した列名変更はできない

WITH PROGRAMを指定した場合，参照表が参照する被参照表を使用する関数，手続き，及びトリガのSQLオブジェクトは無効になります。そのため，ALTER ROUTINE，ALTER PROCEDURE，又はALTER TRIGGERで再作成する必要があります。

(c)　表削除（DROP TABLE）時

外部キーから参照される被参照表は削除できません。

(4)　参照制約を定義する場合の注意事項

被参照表と参照表間のデッドロック

次の条件をすべて満たす場合，被参照表と参照表間でデッドロックが発生することがあります。これらの条件は参照制約動作がRESTRICTでもCASCADEでも同じです。

参照表の行を更新するトランザクションと，被参照表を更新するトランザクションが異なるトランザクションで，かつ同時に実行される

参照表で更新する行の主キー構成列の値と，被参照表で更新する行の外部キー構成列の値が同じである

被参照表及び参照表を操作する場合，上記条件が重ならないようにしてください。なお，それぞれのトランザクションで，操作対象の表に対してLOCK文の排他モードで排他制御することでデータの整合性は保証できます。ただし，同時実行性は低下します。

SQLオブジェクト用バッファ長の容量見積もり

参照制約動作を指定すると，HiRDBが内部的に制約条件チェックや参照制約動作を実行するトリガを生成するため，SQLオブジェクト用バッファを指定するときにそれらのSQLオブジェクトについても考慮する必要があります。SQLオブジェクト用バッファ長（pd_sql_object_cache_size）の見積もり式については，マニュアル「HiRDB システム定義」を参照してください。

データディクショナリLOB用RDエリアの容量見積もり

参照制約動作にCASCADEを指定すると，参照制約動作を実行するトリガをHiRDBが生成します。このトリガのトリガ動作手続きのSQLオブジェクトはデータディクショナリLOB用RDエリアに格納されます。そのため，参照制約動作にCASCADEを指定する場合はデータディクショナリLOB用RDエリアに十分な容量を確保しておく必要があります。データディクショナリLOB用RDエリアの容量の見積もりについては，「データディクショナリLOB用RDエリアの容量の見積もり」を参照してください。

バックアップの取得

バックアップは，被参照表が格納されている全RDエリア，及び参照表が格納されている全RDエリアの同期を合わせて取得してください。

また，バックアップ取得時点の検査保留状態によって，バックアップの取得範囲が異なります。バックアップの取得時点と取得範囲については，マニュアル「HiRDB システム運用ガイド」の「同時にバックアップを取得する必要があるRDエリア」を参照してください。

(5)　参照制約の定義例

参照制約の定義例を次に示します。

(a)　１対１対応で参照制約を定義する例

被参照表と参照表が1対1の場合の定義例を次に示します。

参照制約の定義例１

CREATE TABLE SEIZOUMOTO
  (SNO CHAR(4),SNAME NCHAR(6),TELEPHONE CHAR(12))
  PRIMARY KEY(SNO)  …主キーの指定
CREATE TABLE SHOHIN
  (GNO CHAR(4),SNO CHAR(4),GNAME NCHAR(10),SURYO INTEGER)
  CONSTRAINT SHOHIN_FK  …制約名の指定
  FOREIGN KEY(SNO)  …外部キーの指定
  REFERENCES SEIZOUMOTO  …被参照表名の指定

参照制約動作の内容

参照制約動作の指定を省略しているため，更新及び削除時はRESTRICTが仮定されます。製造元表の製造元番号（主キー）の更新，削除をする場合，商品表の製造元番号（外部キー）に対応する行があると，参照制約違反エラーとなり，製造元表の製造元番号の更新，削除は抑止されます。

参照制約の定義例２

CREATE TABLE SEIZOUMOTO
  (SNO CHAR(4),SNAME NCHAR(6),TELEPHONE CHAR(12))
  PRIMARY KEY(SNO)  …主キーの指定
CREATE TABLE SHOHIN
  (GNO CHAR(4),SNO CHAR(4),GNAME NCHAR(10),SURYO INTEGER)
  CONSTRAINT SHOHIN_FK  …制約名の指定
  FOREIGN KEY(SNO)  …外部キーの指定
  REFERENCES SEIZOUMOTO  …被参照表名の指定
  ON UPDATE CASCADE  …更新時の参照制約動作の指定
  ON DELETE CASCADE  …削除時の参照制約動作の指定

参照制約動作の内容

製造元表の製造元番号（主キー）を更新した場合，対応する商品表の製造元番号（外部キー）も主キーと同じ値に更新されます。製造元表の行を削除した場合，商品表に対応する行も削除されます。

(b)　1対2対応で参照制約を定義する例

被参照表が1，参照表が2の場合の定義例を次に示します。

参照制約の定義例

CREATE TABLE SHOHIN
  (GNO CHAR(4),SNO CHAR(4),GNAME NCHAR(10),SURYO INTEGER)
  PRIMARY KEY(GNO)  …主キーの指定
CREATE TABLE SIIRE
  (GNO CHAR(4),GNAME NCHAR(10),SSURYO INTEGER)
  CONSTRAINT SIIRE_FK  …制約名の指定
  FOREIGN KEY(GNO)  …外部キーの指定
  REFERENCES SHOHIN  …被参照表名の指定
  ON UPDATE CASCADE  …更新時の参照制約動作の指定
  ON DELETE CASCADE  …削除時の参照制約動作の指定
CREATE TABLE URIAGE
  (DNO CHAR(4),CNO CHAR(4),GNO CHAR(4),USURYO INTEGER)
  CONSTRAINT URIAGE_FK  …制約名の指定
  FOREIGN KEY(GNO)  …外部キーの指定
  REFERENCES SHOHIN  …被参照表名の指定
  ON UPDATE RESTRICT  …更新時の参照制約動作の指定
  ON DELETE RESTRICT  …削除時の参照制約動作の指定

参照制約動作の内容

商品表の商品番号（主キー）を更新する場合，売り上げ表の商品番号（外部キー）に更新前の主キーと同じ値の行があると，参照制約違反エラーとなり，更新は抑止されます。売り上げ表に更新前の主キーと同じ値の行がないときは仕入れ表の対応する商品番号も主キーと同じ値に更新されます。

商品表の行を削除する場合，売り上げ表に更新前の主キーと同じ値の行があると，参照制約違反エラーとなり，削除は抑止されます。売り上げ表で更新前の主キーと同じ値の行がないときは仕入れ表の対応する行も削除されます。

(c)　2対1対応で参照制約を定義する例

被参照表が2，参照表が1の場合の定義例を次に示します。

参照制約の定義例

CREATE TABLE SHOHIN
  (GNO CHAR(4),SNO CHAR(4),GNAME NCHAR(10),SURYO INTEGER)
  PRIMARY KEY(GNO)  …主キーの指定
CREATE TABLE KOKYAKU
  (CNO CHAR(4),CNAME NCHAR(8),ADDR NCHAR(24))
  PRIMARY KEY(CNO)  …主キーの指定
CREATE TABLE URIAGE
  (DNO CHAR(4),CNO CHAR(4),GNO CHAR(4),USURYO INTEGER)
  CONSTRAINT URIAGE_SHOHIN_FK  …制約名の指定
  FOREIGN KEY(GNO)  …外部キーの指定
  REFERENCES SHOHIN  …被参照表名の指定
  ON UPDATE CASCADE  …更新時の参照制約動作の指定
  ON DELETE CASCADE  …削除時の参照制約動作の指定
  CONSTRAINT URIAGE_KOKYAKU_FK
  FOREIGN KEY(CNO)  …外部キーの指定
  REFERENCES  KOKYAKU  …被参照表名の指定
  ON UPDATE CASCADE  …更新時の参照制約動作の指定
  ON DELETE CASCADE  …削除時の参照制約動作の指定

参照制約動作の内容

商品表の商品番号（主キー）を更新する場合，売り上げ表の商品番号（外部キー）も同じ値に更新されます。商品表の行を削除する場合，売り上げ表の対応する行も削除されます。

顧客表の顧客番号（主キー）を更新する場合，売り上げ表の顧客番号（外部キー）も同じ値に更新されます。顧客表の行を削除する場合，売り上げ表の対応する行も削除されます。

12.19.3　検査保留状態

SQLやユティリティの実行などで表間の参照整合性を保証できなくなった場合，HiRDBは参照表に対するデータ操作を制限します。このように，整合性を保証できないためにデータ操作を制限された状態を検査保留状態といいます。参照表を検査保留状態にして，データ操作を制限するためには，pd_check_pendingオペランドにUSEを指定するか，又はオペランドの指定を省略する必要があります。検査保留状態の表は，整合性チェックユティリティ（pdconstck）を使用して検査保留状態を解除します。また，整合性チェックユティリティを使用して，強制的に検査保留状態にもできます。

pd_check_pendingオペランドにNOUSEを指定していると，表間で参照整合性を保証できない場合でもデータ操作を制限しません。そのため，整合性が保証できなくなるSQLやユティリティを実行した場合は，整合性チェックユティリティで強制的に検査保留状態に設定してから，整合性を確認してください。

整合性が保証できなくなる操作については「データ操作と整合性」を，整合性の確認手順は「表の整合性確認手順」を参照してください。

(1)　検査保留状態の設定又は解除

整合性チェックユティリティ以外に，次に示すユティリティ，コマンド，及びSQLで参照表を検査保留状態に設定するかどうかを決めたり，又は検査保留状態を解除したりできます。

データベース作成ユティリティ（pdload）のconstraint文での指定

データベース再編成ユティリティ（pdrorg）（リロード，再編成）のconstraint文での指定

データベース構成変更ユティリティ（pdmod）（RDエリアの再初期化）

PURGE TABLE文

ALTER TABLE（CHANGE RDAREA）

それぞれの詳細について，ユティリティ及びコマンドはマニュアル「HiRDB コマンドリファレンス」を，SQLはマニュアル「HiRDB SQLリファレンス」を参照してください。

(2)　検査保留状態の管理

検査保留状態はディクショナリ表と，表が格納されたRDエリアの表情報で管理しています。ディクショナリ表では表単位，及び制約単位に検査保留状態を管理し，表情報では分割表の場合はRDエリア単位に，分割表ではない場合は表単位に検査保留状態を管理します。

検査保留状態の情報が格納されている場所と内容を次の表に示します。

表12‒15　検査保留状態の情報が格納されている場所と内容（参照制約）

格納場所 | 格納されている情報
ディクショナリ表 | SQL_TABLES表 | CHECK_PEND列 | 表単位の参照制約の検査保留状態
SQL_REFERENTIAL_CONSTRAINTS表 | CHECK_PEND列 | 制約単位の参照制約の検査保留状態
RDエリアの表情報 | 分割していない表の場合 | 表単位の参照制約又は検査制約の検査保留状態
分割表の場合 | RDエリア単位の参照制約又は検査制約の検査保留状態

(3)　検査保留状態の表に対して制限される操作

検査保留状態の表に対してできなくなる操作を次の表に示します。なお，トリガ動作によって操作対象表にアクセスする場合，トリガSQL文に指定したSQLの操作可否に依存します。また，操作対象表がビュー表の場合，ビュー表の基になる実表の操作可否に依存します。

表12‒16　検査保留状態の表に対する操作可否

検査保留状態の表に対する操作 | 操作可否
操作系SQL | SELECT文 | 対象表の検索 | △※１
対象表から作成したリストの検索
INSERT文 | 対象表への挿入
UPDATE文 | 対象表の更新
DELETE文 | 対象表からの行削除
ASSIGN LIST文 | 対象表からのリスト作成
ユティリティ | リバランスユティリティ（pdrbal） | ×
データベース再編成ユティリティ（pdrorg） | 再編成 | △※２

（凡例）

△：場合によっては操作できません。

×：操作できません。

注※１

次の条件をどちらも満たす場合だけ，操作できます。それ以外は操作できません。

操作対象表が分割表で，分割条件がキーレンジ分割又はFIXハッシュ分割

操作対象となるRDエリアが検査保留状態でない

注※２

フレキシブルハッシュ分割の分割表に対して再編成を実行する場合，操作できないときがあります。詳細は，マニュアル「HiRDB コマンドリファレンス」の「データベース再編成ユティリティ（pdrorg）」の「規則及び注意事項」を参照してください。

(4)　検査保留状態の表と参照関係がある表に対して制限される操作

次のような参照関係がある表を例に説明します。この場合，検査保留状態になるのは表T2と表T3だけです。

表T2と表T3が検査保留状態の場合，各表に対して制限される操作について次に示します。

(a)　表T2だけが検査保留状態の場合

表T2だけが検査保留状態の場合，各表に対して制限される操作を次の表に示します。

表12‒17　表T2だけが検査保留状態の場合，各表に対して制限される操作

操作対象表 | 制限される操作 | 制限の内容

表T1

UPDATE（対象表の更新）

表T2に定義されている参照制約動作指定によって異なります。

CASCADEの場合

参照制約動作の操作対象となるRDエリアの表情報が検査保留状態のときは操作できません。ただし，同値更新のときは操作できます。

RESTRICTの場合

操作できます。参照表T2を参照し，整合性チェックを行います。

DELETE（対象表からの行削除）
表T2 | SELECT文（対象表の検索及び対象表から作成したリストの検索） | 次の条件をどちらも満たす場合だけ，操作できます。それ以外は操作できません。 操作対象表が分割表で，分割条件がキーレンジ分割又はFIXハッシュ分割 操作対象となるRDエリアが検査保留状態でない
INSERT文（対象表への挿入）
UPDATE文（対象表の更新）
DELETE文（対象表からの行削除）
ASSIGN LIST文（対象表からのリスト作成）
リバランスユティリティ（pdrbal） | 操作できません。
データベース再編成ユティリティ（pdrorg）による再編成 | フレキシブルハッシュ分割の分割表に対して再編成を実行する場合，操作できないときがあります。詳細は，マニュアル「HiRDB コマンドリファレンス」の「データベース再編成ユティリティ（pdrorg）」を参照してください。
表T3 | 制限される操作はありません。INSERT及びDELETEの場合，被参照表T2を参照し，整合性チェックを行います。

(b)　表T3だけが検査保留状態の場合

表T3だけが検査保留状態の場合，各表に対して制限される操作を次の表に示します。

表12‒18　表T3だけが検査保留状態の場合，各表に対して制限される操作

操作対象表 | 制限される操作 | 制限の内容
表T1 | UPDATE（対象表の更新） | 表T2及び表T3に定義されている参照制約動作がCASCADEで，参照制約動作の操作対象となるRDエリアの表情報が検査保留状態のときは操作できません。ただし，同値更新のときは操作できます。
DELETE（対象表からの行削除）

表T2

UPDATE（対象表の更新）

表T2及び表T3に定義されている参照制約動作指定によって異なります。

CASCADEの場合

参照制約動作の操作対象となるRDエリアの表情報が検査保留状態のときは操作できません。ただし，同値更新のときは操作できます。

RESTRICTの場合

操作できます。参照表T3を参照し，整合性チェックを行います。

DELETE（対象表からの行削除）
表T3 | SELECT文（対象表の検索及び対象表から作成したリストの検索） | 次の条件をどちらも満たす場合だけ，操作できます。それ以外は操作できません。 操作対象表が分割表で，分割条件がキーレンジ分割又はFIXハッシュ分割 操作対象となるRDエリアが検査保留状態でない
INSERT文（対象表への挿入）
UPDATE文（対象表の更新）
DELETE文（対象表からの行削除）
ASSIGN LIST文（対象表からのリスト作成）
リバランスユティリティ（pdrbal） | 操作できません。
データベース再編成ユティリティ（pdrorg）による再編成 | フレキシブルハッシュ分割の分割表に対して再編成を実行する場合，操作できないときがあります。詳細は，マニュアル「HiRDB コマンドリファレンス」の「データベース再編成ユティリティ（pdrorg）」を参照してください。

(c)　表T2及び表T3が検査保留状態の場合

表T2及び表T3が検査保留状態の場合，各表に対して制限される操作を次の表に示します。

表12‒19　表T2及び表T3が検査保留状態の場合，各表に対して制限される操作

操作対象表 | 制限される操作 | 制限の内容
表T1 | UPDATE（対象表の更新） | 表T2及び表T3に定義されている参照制約動作がCASCADEで，参照制約動作の操作対象となるRDエリアの表情報が検査保留状態のときは操作できません。ただし，同値更新のときは操作できます。 表T2及び表T3に定義されている参照制約動作指定がRESTRICTの場合，操作できます。参照表T2を参照し，整合性チェックを行います。
DELETE（対象表からの行削除）
表T2 | SELECT文（対象表の検索及び対象表から作成したリストの検索） | 次の条件をどちらも満たす場合だけ，操作できます。それ以外は操作できません。 操作対象表が分割表で，分割条件がキーレンジ分割又はFIXハッシュ分割 操作対象となるRDエリアが検査保留状態でない
INSERT文（対象表への挿入）
UPDATE文（対象表の更新）
DELETE文（対象表からの行削除）
ASSIGN LIST文（対象表からのリスト作成）
リバランスユティリティ（pdrbal） | 操作できません。
データベース再編成ユティリティ（pdrorg）による再編成 | フレキシブルハッシュ分割の分割表に対して再編成を実行する場合，操作できないときがあります。詳細は，マニュアル「HiRDB コマンドリファレンス」の「データベース再編成ユティリティ（pdrorg）」を参照してください。
表T3 | SELECT文（対象表の検索及び対象表から作成したリストの検索） | 次の条件をどちらも満たす場合だけ，操作できます。それ以外は操作できません。 操作対象表が分割表で，分割条件がキーレンジ分割又はFIXハッシュ分割 操作対象となるRDエリアが検査保留状態でない
INSERT文（対象表への挿入）
UPDATE文（対象表の更新）
DELETE文（対象表からの行削除）
ASSIGN LIST文（対象表からのリスト作成）
リバランスユティリティ（pdrbal） | 操作できません。
データベース再編成ユティリティ（pdrorg）による再編成 | フレキシブルハッシュ分割の分割表に対して再編成を実行する場合，操作できないときがあります。詳細は，マニュアル「HiRDB コマンドリファレンス」の「データベース再編成ユティリティ（pdrorg）」を参照してください。

(5)　分割表を使用している場合

RDエリア単位に検査保留状態を管理しているため，分割表で，実際に操作するRDエリアの表情報が検査保留状態の場合，その分割表に対する操作は制限されることがあります。それぞれについて説明します。

分割表で，データを格納している一部のRDエリアが検査保留状態の場合の例を次の図に示します。

図12‒36　分割表で，RDエリア単位に検査保留状態を管理する場合のデータ操作可否

[picture]

〔説明〕

分割表Aに対してSELECT文を実行する場合，実際に操作するデータがRDエリア2（表情報が検査保留状態）にあると，SELECT文はエラーになります。RDエリア1及び3にあるデータに対する操作の場合，SELECT文は正常に実行できます。

分割表の場合の注意事項

pd_check_pendingオペランドにUSEを指定していて，参照表のデータを分割格納しているRDエリアを再初期化する場合，再初期化後に整合性チェックユティリティで表単位の整合性チェックを実行してください。

(6)　検査保留状態を使用する場合の注意

pd_check_pendingオペランドの指定値をNOUSEからUSEに変更した場合，整合性チェックユティリティを使用して，参照表の整合性を確認する必要があります。確認手順については，「表の整合性確認手順」を参照してください。

pd_check_pendingオペランドにUSEを指定していて，参照整合性を保証できなくなる操作をした場合でも，RDエリアの状態によっては検査保留状態を設定できないことがあります。このため，pd_check_pendingオペランドの指定値をNOUSEからUSEに変更すると，検査保留状態を使用していない場合は正常だった操作がエラーになることがあります。PURGE TABLE文，又はALTER TABLE（CHANGE RDAREA）実行時，検査保留状態を設定できるRDエリアの状態を次に示します。

オープン契機がINITIALの場合

RDエリアが閉塞なし，オープン状態のとき

RDエリアが更新可能バックアップ閉塞，かつオープン状態のとき

オープン契機がDEFER又はSCHEDULEの場合

RDエリアが閉塞なしのとき

RDエリアが更新可能バックアップ閉塞のとき

ユティリティ実行時，検査保留状態を設定できるRDエリアについては，マニュアル「HiRDB コマンドリファレンス」の「コマンド実行時のRDエリアの状態」の「検査保留状態の設定可否」を参照してください。

pd_check_pendingオペランドにUSEを指定する場合，検査保留状態に設定される参照表及びRDエリアに対して排他が掛かるため，ユティリティ及びSQL実行時の排他資源が検査保留状態を使用しない場合とは異なります。

12.19.4　データ操作と整合性

被参照表及び参照表に対する操作系SQL（PURGE TABLE文を除きます）による更新，追加，又は削除は，HiRDBがSQL実行時にチェックし，整合性を保証します。ただし，次の表に示す操作をした場合，整合性を保証できなくなることがあります。pd_check_pendingオペランドにUSEを指定していて，これらの操作をした場合，参照表は検査保留状態になります。

表12‒20　整合性を保証できなくなる場合の，被参照表に対する操作とデータ不整合の発生条件

表又はRDエリアに対する操作 | データ不整合の発生条件
データベース作成ユティリティ（pdload） | 作成モード（-dオプション指定）のデータロード | データロードした主キー構成列中に，参照表の外部キー構成列と同じ値を持つ行を含まない場合
データベース再編成ユティリティ（pdrorg） | リロード（-k reld指定） | リロードした主キー構成列中に，参照表の外部キー構成列と同じ値を持つ行を含まない場合
再編成（-k rorg指定） | UOCを使用して，参照表の外部キー構成列の値と同じ値の行を削除した場合
データベース構成変更ユティリティ（pdmod） | RDエリアの再初期化（initialize rdarea） | 参照表が，再初期化したRDエリアと異なるRDエリアに格納されている場合
PURGE TABLE文 | 参照表にデータが存在する場合
ALTER TABLEによる表の分割格納条件の変更 | RDエリアの分割や統合の結果，参照表の外部キー構成列と同じ値を持つ行を含まない場合

表12‒21　整合性を保証できなくなる場合の，参照表に対する操作とデータ不整合の発生条件

表又はRDエリアに対する操作 | データ不整合の発生条件
データベース作成ユティリティ（pdload） | データロード | データロードした外部キー構成列中に，被参照表の主キー構成列と同じ値を持つ行がない場合
データベース再編成ユティリティ（pdrorg） | リロード（-k reld指定） | リロードした外部キー構成列中に，被参照表の主キー構成列と同じ値を持つ行がない場合

(1)　操作対象の表が分割表の場合

操作対象の表が分割表で，表中に不整合データがある場合，ユティリティの実行によって，不整合データが，格納されているRDエリアを移動することがあります。例えば，RDエリア1，2，及び3に分割格納されている表で，不整合データがRDエリア1にあるとき，ユティリティの実行によって，不整合データがRDエリア3に移動することがあります。不整合データのRDエリアの移動が発生する条件を次の表に示します。

表12‒22　操作対象が分割表の場合，表中の不整合データがRDエリアを移動する条件

表又はRDエリアに対する操作 | 表中の不整合データがRDエリアを移動する条件

データベース再編成ユティリティ（pdrorg）

再編成（-k rorg指定）

フレキシブルハッシュ分割表，又は第2次元分割列がフレキシブルハッシュ分割のマトリクス分割表に対して次の手順で操作する場合

RDエリア単位でデータロードをする

HiRDB/シングルサーバの場合，表単位に再編成を実行する※

HiRDB/パラレルサーバの場合，-gオプションを指定して表単位に再編成を実行する※

リバランスユティリティ（pdrbal） | 不整合データがある表に対して，RDエリアを追加してリバランスユティリティ（pdrbal）を実行する場合※

注※

pd_check_pendingオペランドにUSEを指定していて，操作対象表が検査保留状態の場合は実行できません。

(2)　データ不整合が発生する可能性があるそのほかの条件

次の条件をすべて満たす場合も，データ不整合が発生することがあるため，データの整合性を確認する必要があります。データの整合性確認手順については，「表の整合性確認手順」を参照してください。これらの条件は参照制約動作がRESTRICTでもCASCADEでも同じです。

参照表の行を削除するトランザクションと，被参照表を更新又は削除するトランザクションが異なるトランザクションで，かつ同時に実行される

参照表で削除する行の主キー構成列の値と，被参照表で更新又は削除する行の外部キー構成列の値が同じである

被参照表の行を更新又は削除するトランザクションをコミットし，参照表の行を削除するトランザクションをロールバックする

被参照表及び参照表を操作する場合，上記条件が重ならないようにしてください。なお，それぞれのトランザクションで，操作対象の表に対してLOCK文の共用モード又は排他モードで排他制御することでデータの整合性は保証できます。ただし，同時実行性は低下します。

12.19.5　表の整合性確認手順

データの整合性確認手順の概要を次の図に示します。

図12‒37　データの整合性確認手順の概要（参照制約）

[picture]

pd_check_pendingオペランドの指定値がUSE又は省略の場合

検査保留状態の表の特定

ディクショナリ表のSQL_TABLES表を検索して，検査保留状態の表名を検出します。

SELECT TABLE_SCHEMA, TABLE_NAME FROM MASTER.SQL_TABLES
    WHERE CHECK_PEND = 'C' OR CHECK_PEND2 = 'C'

検索結果には，検査保留状態の表の所有者と検査保留状態の表名が返されます。検索結果が0行の場合，検査保留状態の表はありません。

整合性チェックユティリティを使用した整合性チェック

整合性チェックユティリティで表単位の整合性チェックを実行し，制約違反データがあれば修正します。検査保留状態の表がなくなるまで整合性チェックを繰り返し，なくなれば終了です。整合性チェックユティリティを使用した整合性確認手順については，「検査保留状態を使用する場合の整合性確認手順（参照制約）」を参照してください。

pd_check_pendingオペランドの指定値がNOUSEの場合

整合性チェックをする表を特定し，強制的に検査保留状態に設定

整合性チェックをする表を特定するために，次のことを確認します。

参照整合性を保証できなくなる操作をした表を被参照表とする参照表が存在するかどうか

参照整合性を保証できなくなる操作をした表に参照制約が定義されているかどうか

これらを確認するSQLの実行例を次に示します。

SELECT N_PARENTS, N_CHILDREN FROM MASTER.SQL_TABLES
    WHERE TABLE_SCHEMA = '対象表の所有者名' AND TABLE_NAME = '対象表の表名'

次の検索結果が返されます。

対象表に定義した外部キーの数

対象表に定義した主キーを参照する外部キーの数

N_PARENTSがナル値の場合，対象表に参照制約は定義されていません。

N_CHILDRENがナル値の場合，対象表を被参照表とする参照表は存在しません。

N_CHILDRENがナル値以外の場合，次に示すSQLを実行し，対象表を参照する参照表の表名を確認してください。

SELECT TABLE_SCHEMA, TABLE_NAME, CONSTRAINT_NAME
    FROM MASTER.SQL_REFERENTIAL_CONSTRAINTS
    WHERE R_OWNER = '対象表の所有者名' AND R_TABLE_NAME = '対象表の表名'

検索結果には，対象表を被参照表とする参照表の所有者名，表名及び参照制約の制約名が返されます。検索結果が0行の場合，対象表を被参照表とする参照表はありません。

表を特定したら，整合性チェックユティリティを使用して，その表を強制的に検査保留状態に設定します（検査保留状態でない表は，整合性チェックユティリティでチェックできません）。

整合性チェックユティリティを使用した整合性チェック

pd_check_pendingオペランドの指定値がUSE又は省略の場合の手順2.と同じです。整合性チェックユティリティを使用した整合性確認手順については，「検査保留状態を使用しない場合の整合性確認手順」を参照してください。

(1)　検査保留状態を使用する場合の整合性確認手順（参照制約）

pd_check_pendingオペランドの指定値がUSE又は省略の場合の，整合性チェックユティリティを使用した整合性確認手順を次の図に示します。

図12‒38　検査保留状態を使用する場合の整合性確認手順（参照制約）

[picture]

確認する表の整合性チェック

表単位，又は制約単位に整合性チェックをします。

制約違反有無判定

手順1.の整合性チェック結果で，制約違反データの有無を判定します。

違反データの修正方法

違反データの修正をユティリティで行うか，SQLで行うかを選択します。ユティリティで行う場合，手順6.へ進んでください。

確認する表の操作抑止

整合性が保証できない表を使用する業務の運用を停止します。

確認する表の検査保留状態を強制解除

制約違反の対策をするため，検査保留状態を強制解除します。

制約違反の対策

ユティリティで修正する場合

対策方法を次に示します。対策後，手順1.に戻り，整合性チェックを実行し，違反データがないことを確認し，終了します。

条件 | 対策方法
主キーに必要なデータがない場合 | データベース作成ユティリティ（pdload）の追加モードで正しいデータをロードします。
外部キーに制約違反データがある場合 | データベース作成ユティリティ（pdload）の作成モードで正しいデータをロードします。 データベース再編成ユティリティ（pdrorg）のUOCを使用して不要なデータを削除します。

SQLで修正する場合

対策方法を次に示します。対策後，手順7.に進みます。

条件 | 対策方法
主キーに必要なデータがない場合 | 主キーに必要なデータをINSERT文で挿入します※１。又は，被参照表の既存のデータをUPDATE文で更新します※２。
外部キーに制約違反データがある場合 | 外部キーの制約違反データをDELETE文で削除，又は，UPDATE文で正しい値に更新します※１。

注※１

外部キーが主キーでもあり，対策を行う表を被参照表とする参照表が存在する場合，修正順序に注意が必要です。例えば，次のような参照関係があるとします。

●REF1の制約違反の対策をする場合の注意

表T2のデータをDELETE文で修正する場合，REF2でON DELETE RESTRICTを指定しているときは，対応する表T3のデータを先に削除後，表T2のデータを削除してください。また，UPDATE文で修正する場合，REF2でON UPDATE RESTRICTを指定しているときは，更新前のデータに対応する表T3のデータを削除後，表T2のデータを更新してください。

●REF2の制約違反の対策をする場合の注意

表T2のデータをINSERT文で修正する場合，表T1に挿入対象のデータが存在するかどうか確認します。存在しないときは，先に表T1にデータを挿入後，表T2にデータを挿入してください。また，UPDATE文で修正する場合，更新後のデータが表T1に存在するかどうか確認します。存在しないときは，先に表T1にデータを挿入後，表T2のデータを更新してください。

注※２

対策をする制約とは別の制約で，その表を被参照表とする参照表が存在する場合，修正順序に注意が必要です。例えば，次のような参照関係があるとします。

●REF1の制約違反の対策をする場合の注意

T1のデータをUPDATE文で修正する場合，REF2でON UPDATE RESTRICTを指定しているときは，更新前のデータに対応するT3のデータを削除後，T2のデータを更新してください。

違反があった制約を，強制的に検査保留状態に設定

整合性チェックユティリティを制約単位で実行し，対策をした制約を強制的に検査保留状態に設定します。

確認する表の操作抑止解除

運用を停止していた業務を再開します。手順1.に戻り，整合性チェックを実行し，違反データがないことを確認します。

(2)　検査保留状態を使用しない場合の整合性確認手順

pd_check_pendingオペランドの指定値がNOUSEの場合の，整合性チェックユティリティを使用した整合性確認手順を次の図に示します。

図12‒39　検査保留状態を使用しない場合の整合性確認手順

[picture]

確認する表の操作抑止

整合性が保証できない表を使用する業務の運用を停止します。

確認する表を強制的に検査保留状態に設定

確認する表を強制的に検査保留状態に設定します。なお，手順3.で制約単位の整合性チェックをする場合は，この操作は不要です。

確認する表の整合性チェック

表単位，又は制約単位に整合性チェックをします。

制約違反有無判定

手順3.の整合性チェック結果で，制約違反データの有無を判定します。

制約違反の対策

「検査保留状態を使用する場合の整合性確認手順（参照制約）」の手順6.を参照して，同様に制約違反データを修正してください。

確認する表の操作抑止解除

運用を停止していた業務を再開します。

12.19.6　参照制約とトリガ

(1)　参照制約動作のトリガ

参照制約動作にCASCADEを指定すると，HiRDBが内部的に参照表を更新するトリガを被参照表に対して生成します。HiRDBが内部的に生成するトリガは，次の場合に無効になるため，再作成する必要があります。ただし，HiRDBが生成したトリガだけを再作成することはできません。ALTER ROUTINEを使用して無効になったトリガすべてを再作成してください。また，インデクスの定義，又は削除でインデクス情報が無効になった場合は，ALTER ROUTINEにALL指定をしてトリガを再作成してください。

更新の場合

参照表の表定義を変更した場合

参照表にインデクスを定義した場合

参照表のインデクスを削除した場合

参照表に，トリガ契機がUPDATEのトリガを生成する場合

参照表のトリガ契機がUPDATEのトリガを削除する場合

参照表が参照する被参照表の主キー構成列の表定義を変更した場合

削除の場合

参照表の表定義を変更した場合

参照表にインデクスを定義した場合

参照表のインデクスを削除した場合

参照表に，トリガ契機がDELETEのトリガを生成する場合

参照表のトリガ契機がDELETEのトリガを削除する場合

また，HiRDBが内部的に生成するトリガは，参照表削除（DROP TABLE，又はDROP SCHEMA）時に削除されます。

(2)　参照制約とユーザが定義したトリガの関係

トリガや参照制約が定義されている表に，更新系SQL（INSERT文，UPDATE文，又はDELETE文）を実行する場合の，トリガ，参照制約の整合性チェック，及び参照制約動作（HiRDBが参照制約定義時に内部的に生成するトリガ）の動作順序について説明します。これらの動作順序は，条件によって二つのパターンがあります。

パターン1の条件：

更新対象が被参照で参照制約動作の指定がRESTRICTだけの場合と，更新対象が参照表の場合

パターン2の条件：

更新対象が被参照で参照制約動作の指定にRESTRICT以外がある場合

なお，更新対象の表が参照表であり，かつ被参照表でもある場合は，被参照表の条件が優先されます。

二つのパターンの場合の動作順序をそれぞれ次に示します。

パターン1

注※

参照制約の整合性はすべてこの時点でチェックされます。チェック内容を次に示します。

更新対象が参照表の場合

更新（INSERT，UPDATE）データが被参照表に含まれているかどうか

更新対象が被参照表の場合

更新（UPDATE，DELETE）データが参照表に含まれているかどうか

更新対象が参照表で，かつ被参照表の場合

上記1，2のチェック内容

パターン2

注※

参照制約の整合性はすべてこの時点でチェックされます。チェック内容はパターン1と同じです。

12.19.7　関連製品との連携時の注意

関連製品との連携時の注意事項を次に示します。

HiRDB Datareplicatorを使用する場合

反映側の表に参照制約の定義がある場合は，条件によってデータ連動できないときがあります。条件の詳細は，マニュアル「HiRDBデータ連動機能 HiRDB Datareplicator」を参照してください。

分割格納条件を変更する場合

被参照表の分割格納条件を変更する場合，及び既存データを削除するようなRDエリアの統合又は分割をした場合，分割格納条件変更の完了後の整合性は保証されないため，データの整合性を確認する必要があります。データの整合性確認手順については，「表の整合性確認手順」を参照してください。

12.20　検査制約

12.20.1　検査制約とは

データベース中の表のデータは，値の範囲や条件など制限を持つ場合が多くあります。例えば，商品の情報をデータベースに格納する場合，商品価格として負の値はあり得ません。そのため，負の値はデータベースに存在してはいけない値であり，挿入又は更新時に値をチェックする必要があります。このように，データ挿入又は更新時に制約条件をチェックし，条件を満たさないデータの場合は操作を抑止することで表データの整合性を保つ制約が検査制約です。また，このマニュアルでは検査制約を定義した表を検査制約表といいます。

なお，ユティリティの実行などで検査制約表のデータの整合性が保証できなくなる場合があります。この場合，検査制約表は検査保留状態になります。検査保留状態については「検査保留状態」を，整合性を保証できなくなる操作については「データ操作と整合性」を参照してください。

検査制約の効果

検査制約を定義すると，データの挿入又は更新時のチェックを自動化できるのでUAPを作成するときの負荷を軽減できます。ただし，検査制約表を更新する場合，データの整合性をチェックするため，チェックに掛かる処理時間が増加します。

12.20.2　検査制約の定義

検査制約は，定義系SQLのCREATE TABLEでCHECKを指定し，表の値の制約条件を探索条件で指定します。また，検査保留状態を使用するには，pd_check_pendingオペランドにUSEを指定するか，又はオペランドの指定を省略します。

(1)　検査制約を定義する表の制限事項

検査制約を定義する表の表定義，及び表定義変更時の制限事項を次に示します。

(a)　表定義（CREATE TABLE）時

検査制約は改竄防止表には定義できません。

検査制約は一つの表に254個まで定義できます。255個以上は定義できません。例を次に示します。

この場合，検査制約数が254個より多いため，定義できません。表定義時にエラーとなります。

検査制約，及び各検査制約の探索条件中のAND，ORの個数の和は一つの表に254個まで定義できます（ただし，CASE式中の探索条件，及びその探索条件中のAND，ORの個数は除きます）。例を次に示します。

この場合，検査制約数は2個ですが，制約名CHECK_T1_C1の探索条件中のANDの数が200，制約名CHECK_T1_C2の探索条件中のANDの数53で，検査制約数と各検査制約の探索条件中のAND，ORの和が255（2＋200＋53）となり，254個より多いため定義できません。表定義時にエラーとなります。

なお，表に定義されている検査制約数と各検査制約の探索条件中のAND，ORの和はディクショナリ表のSQL_TABLE表の，N_CHECK_LIMIT列に格納されています。

(b)　表定義変更（ALTER TABLE）時

検査制約表に対して，DROP句及びRENAME句を使用した表定義変更はできません。

検査制約表に対して，CHANGE句を使用した次の変更はできません。

データ型やデータ長の変更

SPLITの変更

既定値の設定，解除

WITH DEFAULTの設定

検査制約表に対して，RENAME句を使用した列名変更はできません。

(2)　検査制約を定義する場合の注意事項

SQLオブジェクト用バッファ長の容量見積もり

検査制約表に対して操作する場合，HiRDBが制約条件をチェックするトリガを生成します。そのため，SQLオブジェクト用バッファを指定するときにHiRDBが生成する制約条件のSQLオブジェクトについても考慮する必要があります。SQLオブジェクト用バッファ長（pd_sql_object_cache_size）の見積もり式については，マニュアル「HiRDB システム定義」を参照してください。

バックアップの取得

バックアップ取得時点の検査保留状態によって，バックアップの取得範囲が異なります。バックアップの取得時点と取得範囲については，マニュアル「HiRDB システム運用ガイド」の「同時にバックアップを取得する必要があるRDエリア」を参照してください。

データディクショナリ用RDエリアの再編成

検査制約表の定義と削除を繰り返すと，データディクショナリ用RDエリアの格納効率が低下します。このような場合，データベース状態解析ユティリティ（pddbst）でデータディクショナリ用RDエリアの格納効率を確認し，必要に応じて再編成してください。

12.20.3　検査保留状態

ユティリティの実行などでデータの整合性を保証できなくなった場合，HiRDBは検査制約表に対するデータ操作を制限します。このように，整合性を保証できないためにデータ操作を制限された状態を検査保留状態といいます。検査制約表を検査保留状態にして，データ操作を制限するためには，pd_check_pendingオペランドにUSEを指定するか，又はオペランドの指定を省略する必要があります。検査保留状態の表は，整合性チェックユティリティ（pdconstck）を使用して検査保留状態を解除します。整合性チェックユティリティを使用して，強制的に検査保留状態に設定することもできます。

pd_check_pendingオペランドにNOUSEを指定していると，データの整合性を保証できない場合でもデータ操作を制限しません。そのため，整合性が保証できなくなるユティリティを実行した場合は，整合性チェックユティリティで強制的に検査保留状態に設定してから，整合性を確認してください。

整合性が保証できなくなる操作については「データ操作と整合性」を，整合性の確認手順は「表の整合性確認手順」を参照してください。

(1)　検査保留状態の管理

検査保留状態はディクショナリ表と，表が格納されたRDエリアの表情報で管理しています。ディクショナリ表では表単位，及び制約単位に検査保留状態を管理し，表情報では分割表の場合はRDエリア単位に，分割表ではない場合は表単位に検査保留状態を管理します。

検査保留状態の情報が格納されている場所と内容を次の表に示します。

表12‒23　検査保留状態の情報が格納されている場所と内容（検査制約）

格納場所 | 格納されている情報
ディクショナリ表 | SQL_TABLES表 | CHECK_PEND2列 | 表単位の検査制約の検査保留状態
SQL_CHECKS表 | CHECK_PEND2列 | 制約単位の検査制約の検査保留状態
RDエリアの表情報 | 分割していない表の場合 | 表単位の参照制約又は検査制約の検査保留状態
分割表の場合 | RDエリア単位の参照制約又は検査制約の検査保留状態

(2)　検査保留状態の表に対して制限される操作

参照制約の場合と同じです。「検査保留状態の表に対して制限される操作」を参照してください。

(3)　分割表を使用している場合

参照制約の場合と同じです。「分割表を使用している場合」を参照してください。ただし，「参照表」を「検査制約表」に読み替えてください。

(4)　検査保留状態を使用する場合の注意

pd_check_pendingオペランドの指定値をNOUSEからUSEに変更した場合，整合性チェックユティリティを使用して，検査制約表の整合性を確認する必要があります。確認手順については，「表の整合性確認手順」を参照してください。

pd_check_pendingオペランドにUSEを指定する場合，検査保留状態に設定される参照表及びRDエリアに対して排他が掛かるため，ユティリティ及びSQL実行時の排他資源が検査保留状態を使用しない場合とは異なります。

12.20.4　データ操作と整合性

検査制約表に対する操作系SQLによる更新，追加，又は削除は，HiRDBがSQL実行時にチェックし，整合性を保証します。ただし，次の表に示すユティリティによる操作をした場合，チェックをしないため，整合性を保証できなくなることがあります。pd_check_pendingオペランドにUSEを指定していて，これらの操作をした場合，検査制約表は検査保留状態になります。

表12‒24　整合性を保証できなくなる場合の，検査制約表に対する操作とデータ不整合の発生条件

表又はRDエリアに対する操作 | データ不整合の発生条件
データベース作成ユティリティ（pdload） | データロード | 検査制約定義で指定した探索条件を満たさないデータをデータロードした場合
データベース再編成ユティリティ（pdrorg） | リロード（-k reld指定） | 検査制約定義で指定した探索条件を満たさないデータをリロードした場合

12.20.5　表の整合性確認手順

データの整合性確認手順の概要を次の図に示します。

図12‒40　データの整合性確認手順の概要（検査制約）

[picture]

pd_check_pendingオペランドの指定値がUSE又は省略の場合

検査保留状態の表の特定

ディクショナリ表のSQL_TABLES表を検索して，検査保留状態の表名を検出します。

SELECT TABLE_SCHEMA, TABLE_NAME FROM MASTER.SQL_TABLES
    WHERE CHECK_PEND = 'C' OR CHECK_PEND2 = 'C'

検索結果には，検査保留状態の表の所有者と検査保留状態の表名が返されます。検索結果が0行の場合，検査保留状態の表はありません。

整合性チェックユティリティを使用した整合性チェック

整合性チェックユティリティで表単位の整合性チェックを実行し，制約違反データがあれば修正します。検査保留状態の表がなくなるまで整合性チェックを繰り返し，なくなれば終了です。整合性チェックユティリティを使用した整合性確認手順については，「検査保留状態を使用する場合の整合性確認手順（検査制約）」を参照してください。

pd_check_pendingオペランドの指定値がNOUSEの場合

整合性チェックをする表を特定し，強制的に検査保留状態に設定

整合性チェックをする表を特定するために，整合性を保証できなくなる操作をした表に検査照制約が定義されているかどうかを確認します。これを確認するSQLの実行例を次に示します。

SELECT N_CHECK FROM MASTER.SQL_TABLES
    WHERE TABLE_SCHEMA = '対象表の所有者名' AND TABLE_NAME = '対象表の表名'

次の検索結果が返されます。

検査制約の定義数

N_CHECKがナル値の場合，対象表に検査制約は定義されていません。

表を特定したら，整合性チェックユティリティを使用して，その表を強制的に検査保留状態に設定します（検査保留状態でない表は，整合性チェックユティリティでチェックできません）。

整合性チェックユティリティを使用した整合性チェック

pd_check_pendingオペランドの指定値がUSE又は省略の場合の手順2.と同じです。整合性チェックユティリティを使用した整合性確認手順は，参照制約の場合と同じのため，「検査保留状態を使用しない場合の整合性確認手順」を参照してください。

(1)　検査保留状態を使用する場合の整合性確認手順（検査制約）

pd_check_pendingオペランドの指定値がUSE又は省略の場合の，整合性チェックユティリティを使用した整合性確認手順を次の図に示します。

図12‒41　検査保留状態を使用する場合の整合性確認手順（検査制約）

[picture]

確認する表の整合性チェック

表単位，又は制約単位に整合性チェックをします。

制約違反有無判定

手順1.の整合性チェック結果で，制約違反データの有無を判定します。

違反データの修正方法

違反データの修正をユティリティで行うか，SQLで行うかを選択します。ユティリティで行う場合，手順6.へ進んでください。

確認する表の操作抑止

整合性が保証できない表を使用する業務の運用を停止します。

確認する表の検査保留状態を強制解除

制約違反の対策をするため，検査保留状態を強制解除します。

制約違反の対策

ユティリティで修正する場合

対策方法を次に示します。対策後，手順1.に戻り，整合性チェックを実行し，違反データがないことを確認し，終了します。

条件 | 対策方法

検査制約の定義で指定した探索条件を修正する場合

手順を次に示します。

表のデータをすべてアンロードします。

DROP TABLEで表の定義を削除します。

CREATE TABLEで表を再定義します。このとき，検査制約の定義に正しい探索条件を指定します。

1.でアンロードしたデータをロードします。

表に制約違反データがある場合 | データベース作成ユティリティ（pdload）の作成モードで正しいデータをロードします。 データベース再編成ユティリティ（pdrorg）のUOCを使用した削除で不要なデータを削除します。

SQLで修正する場合

対策方法を次に示します。対策後，手順7.に進みます。

条件 | 対策方法
検査制約の定義で指定した探索条件を修正する場合 | ユティリティで修正する場合と同じです。
表に制約違反データがある場合 | 制約違反データをDELETE文で削除，又は，UPDATE文で正しい値に更新します※。

注※

対策する表を被参照表とする参照表が存在する場合，修正順序に注意が必要です。例えば，次のような関係があるとします。

●CHK1の制約違反の対策をする場合の注意

表T1のデータをDELETE文で修正する場合，REF1でON DELETE RESTRICTを指定しているときは，対応する表T2のデータを先に削除後，表T1のデータを削除してください。また，UPDATE文で修正する場合，REF1でON UPDATE RESTRICTを指定しているときは，更新前のデータに対応する表T2のデータを削除後，表T1のデータを更新してください。

違反があった制約を強制的に検査保留状態に設定

整合性チェックユティリティを制約単位で実行し，対策をした制約を強制的に検査保留状態に設定します。

確認する表の操作抑止解除

運用を停止していた業務を再開します。手順1.に戻り，整合性チェックを実行し，違反データがないことを確認します。

12.20.6　関連製品との連携時の注意

関連製品との連携時の注意事項を次に示します。

HiRDB Datareplicatorを使用する場合

整合性があるデータが反映されるので，反映側の表に検査制約の定義は不要です。

12.20.7　検査制約表の64ビットモードへの移行

HiRDBを32ビットモードから64ビットモードへ移行する場合，32ビットモードで定義した検査制約表に挿入や更新をするとエラーになります。32ビットモードで定義した検査制約表を64ビットモードで挿入や更新できるようにするには，64ビットモードでHiRDBを再開始後，検査制約表を再定義してください。検査制約表の64ビットモードへの移行の基本的な流れを次の図に示します。

図12‒42　検査制約表の64ビットモードへの移行の基本的な流れ

[picture]

検査制約表の有無判定

検査制約表の有無を確認するため，次のSQLを実行します。

SELECT TABLE_SCHEMA,TABLE_NAME FROM MASTER.SQL_TABLES WHERE N_CHECK > 0

結果行数が1以上であれば，検査制約表があります。また，検索結果のTABLE_SCHEMAが検査制約表の所有者，TABLE_NAMEが検査制約表の表名になります。

ビュー表の有無判定

検査制約表を削除すると，検査制約表を使用したビュー表も削除されます。そのため，検査制約表を使用したビュー表があるかどうかを確認する必要があります。検査制約表を使用したビュー表の有無を確認するため，次のSQLを実行します。

SELECT VIEW_SCHEMA,VIEW_NAME FROM MASTER.SQL_VIEW_TABLE_USAGE
    WHERE BASE_OWNER=検査制約の表の所有者 AND TABLE_NAME=検査制約の表名

結果行数が1以上であれば，検査制約表を使用したビュー表があります。また，検索結果のVIEW_SCHEMAがビュー表の所有者，VIEW_NAMEがビュー表名になります。

ビュー定義文の生成

pddefrevコマンド（定義系SQLの生成）でビュー定義文を生成してください。

参照表の有無判定

検査制約表を削除する場合，主キーが定義されていて，かつ主キーを参照する参照表が定義されていると，その検査制約表は削除できません。そのため，削除する表の主キーを参照する参照表を削除する必要があります。検査制約表の主キーを参照する参照表の有無を確認するため，次のSQLを実行します。

SELECT CONSTRAINT_SCHEMA,TABLE_NAME
    FROM MASTER.SQL_REFERENTIAL_CONSTRAINTS
      WHERE R_OWNER= 検査制約の表の所有者 AND R_TABLE_NAME=検査制約の表名

結果行数が１以上であれば，参照表があります。また，検索結果のCONSTRAINT_SCHEMAが参照表の所有者，TABLE_NAMEが参照表の表名になります。

ビュー表の有無判定

参照表を削除すると，参照表を使用したビュー表も削除されます。そのため，参照表を使用したビュー表があるかどうかを確認する必要があります。参照表を使用したビュー表の有無を確認するため，次のSQLを実行します。

SELECT VIEW_SCHEMA,VIEW_NAME FROM MASTER.SQL_VIEW_TABLE_USAGE
    WHERE BASE_OWNER=参照表の所有者 AND TABLE_NAME=参照表の表名

結果行数が１以上であれば，参照表を使用したビュー表があります。また，検索結果のVIEW_SCHEMAがビュー表の所有者，VIEW_NAMEがビュー表名になります。

ビュー定義文の生成

pddefrevコマンド（定義系SQLの生成）で検査制約表を参照する参照表を使用したビュー定義文を生成してください。

表定義文の生成，データのアンロード，参照表の削除

pddefrevコマンド（定義系SQLの生成）で参照表の表定義文を生成してください。表定義文を生成後，削除する参照表のデータをアンロードして，参照表を削除してください。

表定義文の生成，データのアンロード，検査制約表の削除

pddefrevコマンド（定義系SQLの生成）で検査制約表の表定義文を生成してください。表定義文を生成後，削除する検査制約表のデータをアンロードして，検査制約表を削除してください。

検査制約表，インデクスの再定義

8.で生成した表の表定義文に検査制約表，及びインデクスを再定義してください。

参照表の有無判定

9.で再定義した検査制約表を参照する参照表の有無を4.と同様にして確認してください。

参照表，インデクスの再定義

9.で再定義した検査制約表を参照する参照表がある場合，7.で生成した表の表定義文に参照表，及びインデクスを再定義してください。

ビュー表の再定義

検査制約表を使用したビュー表，又は参照表を使用したビュー表をがある場合，3.，6.で生成したビュー表の定義文にビュー表を再定義してください。

ALTER ROUTINEの実行

表，ビュー表などの削除によって関数が無効状態になっている可能性があるため，定義系SQLのALTER ROUTINEを実行してください。

参照表，検査制約表へのデータのリロード

再定義した表にデータをリロードしてください。

12.21　圧縮表

12.21.1　データ圧縮機能

HiRDBが表にデータを格納するとき，データを圧縮して格納できます。これをデータ圧縮機能といいます。データの圧縮は列単位に指定でき，圧縮したデータを格納する列を圧縮列といい，圧縮列がある表を圧縮表といいます。

HiRDBがデータを圧縮することで，次のメリットがあります。

データベースの容量を削減できる。

UAP側でデータ圧縮処理を実装する必要がない。

データ圧縮の概要を次の図に示します。

図12‒43　データ圧縮の概要

[picture]

〔説明〕

HiRDBがデータの圧縮及び伸張処理を実行するため，ユーザはデータの圧縮及び伸張を指示する必要はありません。

(1)　適用基準

画像，音声など，容量が大きい可変長バイナリデータを含む表を圧縮表にすることをお勧めします。ただし，圧縮表の場合，圧縮処理や伸張処理によるオーバヘッドが掛かります。このため，性能よりも格納効率を重視するシステムで使用してください。

(2)　データの圧縮効率の目安

圧縮前と比べてどれだけ格納領域を節約できるかは，圧縮効率で表します。圧縮効率は，次の計算式で求めます。

圧縮効率（％）＝
｛（圧縮前のデータ長−圧縮後のデータ長）÷圧縮前のデータ長｝×100

また，圧縮率と圧縮効率の関係を次に示します。

圧縮率＋圧縮効率＝100

圧縮率の測定方法については，「データの圧縮率の測定方法」を参照してください。

圧縮効率の目安を次の表に示します。なお，データの圧縮率及び圧縮効率は，圧縮対象となるデータの実態によって異なるため，ここで示す圧縮効率はあくまで目安値です。

表12‒25　圧縮効率の目安

データ種別 | 圧縮効率（単位：%）
全文字が同一のBINARYデータ | 98.51
完全にランダムなBINARYデータ | -0.36※
テキストデータ（.txt） | 58.50
画像データ（.bmp） | 75.42
音声データ（.wav） | 9.46

注※　

圧縮処理で付与されるヘッダ領域が増加したため，圧縮効率がマイナスになります。圧縮処理については，「データ圧縮の仕組み」を参照してください。

(3)　圧縮表に対する操作でHiRDBが出力するファイル

圧縮表に対する操作によって，HiRDBが出力するファイルのデータの状態を次の表に示します。

表12‒26　HiRDBが出力するファイルのデータの状態

処理内容 | ファイル | データの状態
作業表用ファイルが必要なSQLの実行 | 作業表用ファイル | 伸張されたデータ
データベースの更新 | システムログファイル | 圧縮されたデータ
システムログのアンロード | アンロードログファイル
データベースのバックアップ（pdcopyコマンド） | バックアップファイル
表の再編成 （pdrorg -k rorgコマンド） | アンロードデータファイル | 圧縮されたデータ※
表のアンロード （pdrorg -k unldコマンド） | 伸張されたデータ

注※　UOCを利用して再編成を行う場合は，伸張されたデータが格納されます。

(4)　障害発生時の対処

圧縮表のデータやインデクスが格納されているRDエリアに障害が発生した場合，通常のデータベースの回復と同様にデータベース回復ユティリティ（pdrstr）で回復できます。

12.21.2　データ圧縮の仕組み

データ圧縮時に使用する圧縮ライブラリはzlibです。HiRDBは，zlibを使用して表定義時に指定した圧縮分割サイズ（省略値：MIN（32,000バイト，圧縮列の定義長））ごとに圧縮します。このとき，圧縮前後のデータの情報を管理するヘッダ領域（8バイト）を圧縮分割サイズごとに追加します（zlibが圧縮データに付与するヘッダ領域とは別に追加します）。

ただし，圧縮前後のデータ長が同じ，又は圧縮後のデータ長の方が長くなる場合，HiRDBはデータを圧縮しないで格納します。このため，ヘッダ領域の付与によって，圧縮後のデータサイズが圧縮前よりも大きくなることがあります。圧縮前後のデータを次の図に示します。

図12‒44　圧縮前後のデータ

[picture]

12.21.3　圧縮表の定義方法

定義系SQLのCREATE TABLEの列定義で圧縮指定（COMPRESSED）をします。必要に応じて，圧縮分割サイズも指定します。ただし，圧縮指定には次の条件があります。

圧縮指定は列単位に指定します（表単位に指定することはできません）。

圧縮指定できるのは，次のデータ型の列だけです。

定義長が256バイト以上のBINARY型

抽象データ型（XML型）※

注※　

抽象データ型（XML型）の列のデータを圧縮するためには，バージョン09-03以降のHiRDB XML Extensionが必要です。

12.21.4　既存の表を圧縮表に変更する方法

(1)　既存の表の列を圧縮列に変更する場合

定義系SQLのALTER TABLEの列属性変更定義（CHANGE 列名）で圧縮列に変更することはできません。そのため，既存の表の列を圧縮列に変更する場合は，次の手順で行ってください。

〈手順〉

既存の表のアンロード

既存の表をアンロードします。

既存の表の削除

DROP TABLEで既存の表をいったん削除します。

表の再定義

CREATE TABLEで，圧縮列に変更する列に圧縮指定をして，表を再定義します。圧縮指定以外は変更しないでください。

表のリロード

3.で再定義した表に，1.でアンロードしたアンロードデータファイルをリロードします。

データのアンロード及びリロードについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

参考

圧縮列に変更する列が表の最後の列の場合，上記手順の2.及び3.は次の手順でも圧縮列に変更できます。

既存の列の削除，及び圧縮列の追加

PURGE TABLEで表のデータを0件にし，ALTER TABLEの列削除定義（DROP 列名）で圧縮列に変更する列をいったん削除します。次に，ALTER TABLEの列追加定義（ADD 列名）で，削除した列に圧縮指定をして再定義（追加）します。

(2)　既存の表の最後に新規の圧縮列を追加する場合

定義系SQLのALTER TABLEの列追加定義（ADD 列名）で圧縮指定をして圧縮列を追加します。その後，圧縮列にデータロードすると，データが圧縮して格納されます。

参考

ALTER TABLEの列追加定義では，表の最後に新しい列を追加します。そのため，圧縮列は表の最後の列にしか追加できません。

12.21.5　圧縮列の定義を変更（圧縮指定を解除）する方法

圧縮列の定義は，定義系SQLのALTER TABLEの列属性変更定義（CHANGE 列名）で変更できません。圧縮指定を解除したり，圧縮分割サイズを変更するなど，圧縮列の定義を変更する場合，次の手順で変更してください。

〈手順〉

圧縮表のアンロード

定義を変更する圧縮表をアンロードします。

表の再定義

次のどちらかの方法で，圧縮指定を変更，又は解除した表を再定義します。

表の再定義

DROP TABLEで圧縮表をいったん削除し，CREATE TABLEで圧縮指定を変更又は解除した表を再定義します。

列の削除・追加

PURGE TABLEで表のデータを0件にし，ALTER TABLEの列削除定義（DROP 列名）で圧縮列をいったん削除します。次に，ALTER TABLEの列追加定義（ADD 列名）で圧縮指定を変更又は解除した列を追加します。

ただし，ALTER TABLEの列追加定義では，表の最後に新しい列を追加するため，圧縮指定を変更又は解除できる列は最後の列だけです。

表のリロード

2.で定義した表に，1.でアンロードしたアンロードデータファイルをリロードします。

データのアンロード及びリロードについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

12.21.6　圧縮表使用時の留意事項

圧縮列のデータをSQLやユティリティで操作する場合，圧縮処理や伸張処理のオーバヘッドが掛かります。BINARY型のデータの圧縮処理や伸張処理に掛かった時間は，統計解析ユティリティ（pdstedit）のUAPに関する統計情報で確認できます。なお，抽象データ型（XML型）の処理時間については確認できません。

圧縮対象となるデータの実態によって異なりますが，圧縮分割サイズが大きいほどデータの圧縮効率は上がります。ただし，圧縮分割サイズを大きくすると，圧縮列に対するデータの格納及び抽出が発生するSQL※を実行する場合にSQL実行時に確保するプロセス固有領域が増加します。メモリ不足を防ぐため，圧縮分割サイズはシステム内の空きメモリや，pd_max_access_tablesオペランドの指定値を考慮した値を指定してください。増加するプロセス固有メモリ所要量については，HiRDB/シングルサーバの場合は「圧縮列に対して操作系SQLを実行する場合に必要なメモリ所要量の求め方」を，HiRDB/パラレルサーバの場合は「圧縮列に対して操作系SQLを実行する場合に必要なメモリ所要量の求め方」を参照してください。

表の再編成時にエラーが発生し，その対処として圧縮されたデータを含むアンロードデータファイル（pdrorg -k rorgでアンロードされたファイル）をリロードする場合，アンロード元とリロード先の表の圧縮指定（圧縮指定の有無，及び圧縮分割サイズの指定値）が同じである必要があります。圧縮指定が異なる列がある場合，pdrorgはエラー終了します。

共有モードで圧縮表のリバランスを実行する場合，データの伸張及び圧縮を行うため，圧縮列がない場合に比べてリバランス処理に掛かる時間が長くなることがあります。実行時間を短縮したい場合は，占有モードで実行してください。

注※　次のようなSQLです。

SUBSTR関数を使用している

POSITION関数を使用している

後方削除更新をしている

12.21.7　データの圧縮率の測定方法

データの圧縮率の測定方法について説明します。実際にデータを圧縮・格納する前にどれくらい圧縮されるのか知りたい場合や，データの格納後にどれくらい圧縮されたのか確認したい場合に測定してください。ただし，抽象データ型（XML型）の列の場合，pddbstで確認できないため，圧縮・格納後の測定はできません。

(1)　データを圧縮・格納する前の測定方法

データの圧縮率は，圧縮対象となるデータの実態によって大きく異なります。正確な圧縮率は実際にデータを圧縮・格納した後でないと測定できませんが，gzip※を使用して算出した圧縮後のデータ長の概算値を用いることで，圧縮率の概算値を計算できます。計算式を次に示します。

注※　

HiRDBが圧縮に使用するアルゴリズム（Deflate）と同等の圧縮アルゴリズムを使用しています。

計算式

圧縮率（%）=
｛（gzipによる圧縮後のデータ長×1.05※）÷圧縮前のデータ長｝×100

注※　

zlibとgzipでは，圧縮時に付与される圧縮情報を管理するヘッダの形式が異なるため，圧縮後のデータサイズに5%の余裕値を加えます。

(2)　データを圧縮・格納した後の測定方法

実際にデータを圧縮・格納した後で圧縮率の概算値を算出する計算式を次に示します。

計算式

圧縮率（%）=
（圧縮後のデータ長※1の合計÷圧縮前のデータ長※2の合計）※3×100

注※1　算出手順を次に示します。

-dオプション指定で，RDエリア単位又は表単位にデータベース状態解析ユティリティ（pddbst）を実行します。

出力結果の<BINARY segment>の情報から，次の計算式で圧縮後のデータ長を求めます。

₁₀
Σni×a×b
i=1

ni：バイナリ専用セグメントのUsed Page Ratio（使用中ページの比率別ページ数）が示す各比率の最大値（例えば，Used Page Ratioが1〜10%の場合は10%で0.1，11〜20%の場合は20%で0.2となります）

a：niに対応したPageの値

b：バイナリ専用セグメントのページサイズ

1.で対象としたRDエリア，又は表にBINARY型の圧縮列と非圧縮列が混在している場合，2.の算出結果から非圧縮列のデータ長を減算します。非圧縮列のデータ長は次のSQLを実行して算出します。

select sum（length（非圧縮列名）） from 表識別子 〔in RDエリア名〕

注※2　

圧縮前のデータ長は，非圧縮列のデータ長の算出方法（注※1の3.を参照）と同じSQLを実行して算出します。

注※3　

1.0以上の場合，圧縮によってデータ長が増加した，又は圧縮の効果が小さいことを示します。この場合は，圧縮列の定義を変更して，圧縮指定を解除することをお勧めします。圧縮指定の解除については，「圧縮列の定義を変更（圧縮指定を解除）する方法」を参照してください。

12.22　一時表

一時表は，トランザクション又はSQLセッションの期間中だけ存在する実表です。トランザクションの期間中だけ存在する一時表をトランザクション固有一時表，SQLセッションの期間中だけ存在する一時表をSQLセッション固有一時表といいます。

一時表は，表定義時点では作成されません。一時表に対して，最初にINSERT文が実行されたときに表が作成されます。このことを，一時表の実体化といいます。

また，一時表は一つの表定義に対して接続（CONNECT文実行）ごとに専用の表が作成されるため，複数ユーザが同時に使用しても，ほかのユーザのデータ操作（参照，挿入，更新，又は削除）の影響を受けません。一時表及び一時表に定義したインデクス（一時インデクス）は，一時表用RDエリアに格納され，トランザクションの決着時又はSQLセッションの終了時に，自動的に削除されます。一時表用RDエリアについては，「一時表用RDエリア」を参照してください。

一時表の概要を次の図に示します。

図12‒45　一時表の概要

[picture]

一時表の効果

トランザクション又はSQLセッションで複雑な処理を行う場合，中間処理結果を一時的に保持し，更に加工して最終的な結果を得るなど，作業用の表として使用できます。

データ件数が多い表の一部のデータに対してトランザクション又はSQLセッション内で頻繁にアクセスする場合，該当するデータを一時表に格納することで入出力回数を削減でき，性能向上できます。

一時表は，トランザクションの決着時又はSQLセッションの終了時に自動的に削除されるため，UAPによる後処理が不要になり，UAP作成の負担が軽減できます。

一時表の適用基準

データ件数が多い表の一部にだけアクセスが頻繁にあるトランザクションや，中間処理結果を一時的に保存する必要があるような複雑な処理をするバッチ業務などに一時表の使用をお勧めします。

12.22.1　一時表のデータ有効期間

実体化された一時表のデータ有効期間（実体が存在する期間）は，その一時表がトランザクション固有一時表か，SQLセッション固有一時表かによって異なります。一時表のデータ有効期間の開始及び終了タイミングを次の表に，データ有効期間とある時点で保持されているデータの例を次の図に示します。

表12‒27　一時表のデータ有効期間の開始と終了

一時表の種類 | 開始となるタイミング | 終了となるタイミング
トランザクション固有一時表 | トランザクション中で，一時表に対して最初にINSERT文が実行されたとき | トランザクションが決着したとき

SQLセッション固有一時表

SQLセッション中で，一時表に対して最初にINSERT文が実行されたとき

SQLセッションが終了したとき

一時表を実体化したバックエンドサーバが終了したとき

一時表を実体化したバックエンドサーバがあるユニットが終了したとき

一時表を実体化したバックエンドサーバ，又はそのバックエンドサーバがあるユニットに対して系切り替えが発生したとき

図12‒46　一時表のデータ有効期間と，ある時点で保持されているデータの例（その1）

[picture]

〔説明〕

時刻Tの時点で，SQLセッション1及び2が使用する一時表TMP1及びTMP2に保持されているデータを次に示します。

SQLセッション | 一時表 | 保持されているデータ
SQLセッション1 | TMP1 | 4.で挿入したデータ。
TMP2 | 1.及び3.で挿入したデータ。
SQLセッション2 | TMP1 | この時点では，データはありません。
TMP2 | 1.及び3.で挿入したデータ。

図12‒47　一時表のデータ有効期間と，ある時点で保持されているデータの例（その2）

[picture]

〔説明〕

時刻T1及びT2の時点で，SQLセッション1及び2が使用する一時表TMP2に保持されているデータを次に示します。

時刻 | SQLセッション | 保持されているデータ
T1 | SQLセッション1 | 2.で表のデータを削除しているため，この時点では，データはありません。ただし，TMP2の実体は存在します。
SQLセッション2 | 1.で挿入したデータ。
T2 | SQLセッション1 | 3.及び4.で挿入したデータ。
SQLセッション2 | この時点では，データはありません。TMP2を実体化する前の同期点までロールバックしているため，TMP2の実体は存在しません。

注意事項

一時表のデータ有効期間外に，一時表に対して検索，更新，及び削除を実行しても，データがない表に対してSQLを実行したときと同じ結果になります。

HiRDB/パラレルサーバで，SQLセッション固有一時表を実体化したバックエンドサーバ又はそのバックエンドサーバがあるユニットが異常終了したり，系切り替えが発生したりすると，データ有効期間が終了します。そのため，SQLセッションが終了するまで，該当する一時表に対するデータ操作はSQLエラーになります。

12.22.2　一時表及び一時インデクスの定義方法

(1)　一時表を定義する場合

定義系SQLのCREATE TABLEでGLOBAL TEMPORARYを指定します。トランザクション固有一時表を定義する場合はON COMMIT DELETE ROWSを，SQLセッション固有一時表を定義する場合はON COMMIT PRESERVE ROWSを指定します。なお，一時表の場合，指定できない，又は指定しても無視されるオペランドがあります。詳細については，マニュアル「HiRDB SQLリファレンス」のCREATE TABLEを参照してください。

(2)　一時インデクスを定義する場合

基本的に，通常のインデクスの定義と同じです。一時インデクスも一時表と同様に，指定できない，又は指定しても無視されるオペランドがあります。詳細については，マニュアル「HiRDB SQLリファレンス」のCREATE INDEXを参照してください。

(3)　データを格納する一時表用RDエリアを指定する場合

クライアント環境定義PDTMPTBLRDAREAに使用する一時表用RDエリア名を指定します。複数のRDエリアを指定した場合や，この環境定義の指定を省略した場合，次の規則に従ってHiRDBがデータを格納する一時表用RDエリアを決定します。

PDTMPTBLRDAREAに複数のRDエリアを指定している場合

指定したRDエリアに特定SQLセッション占有属性とSQLセッション間共有属性の一時表用RDエリアが混在しているときは，特定SQLセッション占有属性の一時表用RDエリアを優先して使用します。

PDTMPTBLRDAREAの指定を省略している場合

SQLセッション間共有属性の一時表用RDエリアを使用します。

12.22.3　格納先RDエリアの決定規則

一時表用RDエリアが複数ある場合や，クライアント環境定義PDTMPTBLRDAREAの指定を省略している場合，HiRDBが，データを格納する一時表用RDエリアを決定します。HiRDBは，次の順序で格納先RDエリアを決定します。

(1)　格納先バックエンドサーバの決定（HiRDB/パラレルサーバの場合だけ）

HiRDB/パラレルサーバの場合，まず，データを格納するバックエンドサーバを決定します。このとき，次の規則で格納先候補バックエンドサーバを絞り，その中から，INSERT文で指定した実表の中で一時表以外の実表にアクセスするバックエンドサーバを優先して使用します。

クライアント環境定義PDTMPTBLRDAREAにRDエリアを指定している場合

指定したRDエリアがあるバックエンドサーバを格納先候補とします。

指定したRDエリアに特定SQLセッション占有属性とSQLセッション間共有属性の一時表用RDエリアが混在しているときは，特定SQLセッション占有属性の一時表用RDエリアがあるバックエンドサーバを優先して使用します。

クライアント環境定義PDTMPTBLRDAREAにRDエリアを指定していない場合

SQLセッション間共有属性の一時表用RDエリアがあるバックエンドサーバを格納先候補とします。

ポイント

HiRDBが格納先バックエンドサーバを決定するとき，INSERT文で指定した実表の中で，一時表以外の実表にアクセスするバックエンドサーバを優先するため，（例）のようにINSERT SELECTを使用すると，バックエンドサーバ間のデータ転送を回避できます。

（例）　INSERT INTO TMP1 SELECT C1,C2,C3 FROM T1

一時表TMP1に，表T1から列C1，C2，及びC3を挿入するSQLです。

このSQLを実行する場合の構成を次の図に示します。PDTMPTBLRDAREAには，RDTMP1とRDTMP2を指定しています。

このとき，HiRDBは，表T1があるBES1を格納先バックエンドサーバに決定します。これによって，BES1とBES2間でデータ転送することなく，SQLを実行できます。

(2)　格納先候補RDエリアの決定

クライアント環境定義PDTMPTBLRDAREAの指定によって，格納先候補のRDエリアを決定します。PDTMPTBLRDAREAの指定については，「データを格納する一時表用RDエリアを指定する場合」を参照してください。

(3)　条件に合致するRDエリアの決定

格納先候補RDエリアから，次に示すすべての条件に合致するRDエリアを決定します。

一時表の操作に関する排他を取得できる状態である。

一時表の排他については，「一時表の排他制御」を参照してください。

UAPがアクセスできる状態である。

格納する一時表がFIX表の場合，一時表の行長がRDエリアに格納できるサイズを超えていない。

詳細は，マニュアル「HiRDB SQLリファレンス」の「CREATE TABLE」のFIXオペランドの規則3.を参照してください。

格納する一時インデクスを構成する列の長さの合計が，RDエリアに格納できるサイズを超えていない。

詳細は，マニュアル「HiRDB SQLリファレンス」の「CREATE INDEX」の共通規則5.を参照してください。

RDエリア内の一時表の利用回数が500未満である。

RDエリア内の一時インデクスの利用回数が500未満である。

未使用セグメントが存在する。

一時表及び一時インデクス数がpd_max_temporary_object_noオペランドの指定値を超えていない。

pd_tmp_table_initialize_timingオペランドにACCESSを指定している場合，初期化されていない一時表用RDエリアである。

一時表用RDエリアの初期化については，「一時表用RDエリアの初期化」を参照してください。

(4)　格納先一時表用RDエリアの決定

条件に合致したRDエリアから，次の一時表用RDエリアを優先して使用します。

最も多く未使用セグメントが存在する一時表用RDエリア

pd_tmp_table_initialize_timingオペランドにACCESSを指定している場合，初期化されていない一時表用RDエリア

一時表用RDエリアの初期化については，「一時表用RDエリアの初期化」を参照してください。

12.22.4　一時表用RDエリアがない場合の対処

HiRDBが一時表にデータを格納する時に，使用できる一時表用RDエリアがない場合，KFPA19704-Eメッセージを出力し，トランザクションを無効にします。このとき，KFPA19704-Eメッセージで出力されるエラー要因は，最初に格納先候補になったRDエリアのものだけです。メッセージに表示されたRDエリアの対処をしても，頻繁に同じメッセージが出力される場合，次に示す方法で，ほかの一時表用RDエリアの状態を確認し，対処してください。

〈対処方法〉

pddbls -Tコマンドを実行します。

実行結果から，RDAREA_FOR_TEMPORARY_TABLEにOCCUPIED又はSHAREDが表示されているRDエリアがあるかどうかを確認します。

OCCUPIED又はSHAREDが表示されているRDエリアがない場合

使用できる一時表用RDエリアがありません。特定SQLセッション占有属性の一時表用RDエリアを追加し，必要に応じて追加したRDエリアをクライアント環境定義PDTMPTBLRDAREAに指定してください。

OCCUPIED又はSHAREDが表示されているRDエリアがある場合

一時表用RDエリアはありますが，格納先の条件に合致するRDエリアがありません（格納先の条件は，「条件に合致するRDエリアの決定」を参照）。どの条件に合致しないのかを調査するため，一時表用RDエリアに対してpddbls -a -T，及びpddbst -k -physを実行します。実行結果から次の表に示す項目を確認し，条件を満たさない場合はそれぞれ対処してください。

表12‒28　確認項目と対処方法

項番 | コマンド | 確認項目 | 内容 | 対処

1

pddbls -a -T

STATUS

RDエリアの状態

RDエリアが次の状態の場合，対処が必要です。

クローズ状態

閉塞中

pdholdコマンド受け付け状態

RDエリアをオープンしたり，閉塞を解除したりしてUAPがアクセスできる状態にしてください。障害閉塞のときは，pdmodコマンドで一時表用RDエリアを再初期化（initialize rdarea文）してください。

2

SEGMENT

RDエリア内の未使用セグメント数

未使用セグメントがない場合，pdmodコマンドで次のどれかの対処をしてください。

一時表用RDエリアを追加する（create rdarea文）

作成済みの一時表用RDエリアを再初期化する（initialize rdarea文）

作成済みの一時表用RDエリアを拡張する（expand rdarea文）

作成済みの一時表用RDエリアの属性変更（alter rdarea）で，自動増分を適用する

3 | pddbst -k -phys | Page Size | RDエリアのページ長 | ページ長についての条件を満たしていない場合，次のどちらかの対処をしてください。 ページ長についての条件を満たす一時表用RDエリアを追加する 条件を満たすように作成済みの一時表用RDエリアのページ長を変更する
4 | Unused Segment | RDエリア内の未使用セグメント数 | 項番2と同じです。

12.22.5　一時表の排他制御

一時表はトランザクション又はSQLセッションごとに固有のデータを保持し，ほかのユーザからアクセスされない表のため，実体化以外では，表の操作に対する排他は基本的に取得しません。一時表の排他制御について説明します。

(1)　一時表の実体化時に取得する排他

一時表が実体化する時に，次に示す排他を取得します。

表12‒29　一時表の実体化時に取得する排他

資源種別名 | 内容 | 排他解除時期
トランザクション固有一時表 | SQLセッション固有一時表
RDAR | RDエリア（表及びインデクス※１格納RDエリア） | トランザクション決着時 | DISCONNECT文完了時
TABL | 表
RATM | ユーザディレクトリ表情報
RAIM | ユーザディレクトリインデクス情報※１
SBMB | ユーザディレクトリセグメント情報
TEMP | 一時表実体化管理情報 | 一時表の実体化後※２
TPID | ユーザ固有ID管理（一時表） | DISCONNECT文完了時
RDAS | RDエリア状態管理 | 一時表の実体化後※２
RRAM， TRAL， TRAI | RDエリア管理情報
PTBL | 前処理表 | DISCONNECT文完了時

注※1

一時インデクスがある場合だけです。

注※2

この資源に対する排他は実体化時に一時的に取得する排他です。

(2)　一時表に対する操作で取得する排他

次のSQL文を実行すると，前処理表（PTBL）に対してだけ排他を取得します。

LOCK文

CREATE INDEX文

DROP INDEX文

DROP TABLE文

なお，一時表に対して次のSQL文を実行しても，ページ，行，キー値の排他は取得しません。

SELECT文

INSERT文

UPDATE文

DELETE文

PURGE TABLE文

(3)　排他待ち又は実行エラーになる操作

一時表を操作している場合，次に示す操作のどれかを同時に実行すると，排他待ち又は実行エラーになるおそれがあります。

pdclose（一時表用RDエリアのクローズ）

pdhold（一時表用RDエリアの閉塞）

pdopen（一時表用RDエリアのオープン）

pdrels（一時表用RDエリアの閉塞解除）

pdmodコマンドのcreate rdarea文（一時表用RDエリアの追加）

pdmodコマンドのinitialize rdarea文（一時表用RDエリアの再初期化）

pdmodコマンドのremove rdarea文（一時表用RDエリアの削除）

CREATE INDEX文（一時インデクスの定義）

DROP INDEX文（一時インデクスの削除）

DROP SCHEMA文（スキーマの削除）

DROP TABLE文（一時表の削除）

12.22.6　一時表使用時の制限事項

(1)　運用コマンド又はユティリティ

次に示す運用コマンド又はユティリティは，一時表に対して実行できません。詳細は，マニュアル「HiRDB コマンドリファレンス」を参照してください。

最適化情報収集ユティリティ（pdgetcst）

データベース作成ユティリティ（pdload）

グローバルバッファ常駐化ユティリティ（pdpgbfon）

空きページ解放ユティリティ（pdreclaim）

データベース再編成ユティリティ（pdrorg）

(2)　SQL

次に示すSQLは，一時表又は一時インデクスを指定できないなどの制限があります。詳細は，マニュアル「HiRDB SQLリファレンス」を参照してください。

定義系SQL

ALTER INDEX

ALTER TABLE

CREATE INDEX

CREATE TABLE

CREATE TRIGGER

DROP INDEX

DROP SCHEMA

DROP TABLE

GRANT

REVOKE

操作系SQL

ALLOCATE CURSOR文

ASSIGN LIST文

DECLARE CURSOR文

動的SELECT文

SELECT文（表参照，問合せ式 形式2）

DELETE文

UPDATE文

制御系SQL

COMMIT文

DISCONNECT文

ROLLBACK文

LOCK TABLE文

SET SESSION AUTHORIZATION文

13　インデクスの設計

この章では，B-tree構造のインデクス及びプラグインインデクスを設計する上で検討する項目について説明します。

13.1　インデクスを設計するときの検討項目

表に対する処理性能を向上させるには，インデクスを作成します。ただし，効果的に作成しないと，逆に性能を劣化させることもあります。このため，より効果的なインデクスの作成方法を検討する必要があります。また，インデクスのユーザ用RDエリアへの格納の仕方によって，表に対する処理性能や操作性が異なります。これらの点を考慮してインデクスを設計する必要があります。

インデクスを設計するときの検討項目を次の表に示します。

表13‒1　インデクスを設計するときの検討項目

記載箇所 | 設計作業ごとの検討項目 | 説明
「インデクス」を参照してください。 | インデクスの作成 | SQL文に適したB-tree構造のインデクスを検討するときに，参照してください。
「インデクスの横分割」を参照してください。 | インデクスの横分割 | B-tree構造のインデクスのRDエリア構成について検討するときに，参照してください。
「プラグインインデクス」を参照してください。 | プラグインインデクスの作成 | プラグインインデクスを作成するときに，参照してください。
「プラグインインデクスの横分割」を参照してください。 | プラグインインデクスの横分割 | プラグインインデクスのRDエリア構成について検討するときに，参照してください。
「インデクスの優先順位」を参照してください。 | インデクスの優先順位 | 検索する表に複数のインデクスが定義されている場合，HiRDBが使用するインデクスの優先順位について説明しています。SQL文に適したインデクスを検討するときに，参照してください。

13.2　インデクス

ここでは，B-tree構造のインデクスの設計について説明します。

13.2.1　インデクスの作成

(1)　インデクスの効果

性能の向上

表を検索するときのキーとなる列にインデクスを作成しておくと，表の検索性能が向上します。詳細は，マニュアル「HiRDB 解説」の「インデクスの基本構造」を参照してください。

(2)　適用基準

(a)　インデクス作成に適している列

インデクス作成に適している列を次に示します。

データを絞り込むための条件に使用する列

探索条件に使用する列にインデクスを作成すると，条件を満たすデータを効率良く取り出せます。

表の結合処理の条件として使用する列

表を結合する場合は，結合列にインデクスを作成することで，効率の良い結合処理ができます。特に，結合列に指定することが多い外部キーには，インデクスを作成してください。

ORDER BY，GROUP BYに指定する列

探索条件に使用する列に加えて，ORDER BY，GROUP BYに指定する列をインデクス構成列に含めると，HiRDBが実行するソート処理を省略できることがあるため，効率良く処理ができます。ソート処理を省略できる条件については，マニュアル「HiRDB コマンドリファレンス」の「アクセスパス表示ユティリティ（pdvwopt）」の「ORDER BY，GROUP BYを指定した検索に使用する表のインデクス定義」を参照してください。

インデクスを構成する列の組み合わせや順序については，「インデクス構成列の検討」を参照してください。

(b)　インデクス作成に適さない列

次に示す列にインデクスを作成すると性能が低下するため，インデクス作成には適していません。

更新頻度の高い列

データの重複度が高い列（データの種類が少ない列）

それぞれの理由について，次に説明します。

更新頻度の高い列

更新SQLの性能への影響

インデクス構成列の値を更新すると，キー値も更新されます。このインデクスメンテナンスは，更新SQLの延長で実行されるため，更新SQLの実行頻度が高い場合は，性能が低下します。

インデクス格納ページの断片化

インデクスのキー値はキー値順に並んで格納されているため，キー値が更新されると格納位置が変わり，インデクスのページには断片化した空き領域が発生します。更新SQLの実行頻度が高い場合は，断片化の進行が早いため，次のインデクス再編成を実行するまでに，インデクスを使用した検索性能が低下します。

図13‒1　インデクスページの断片化による検索性能への影響

[picture]

データの重複度が高い列（データの種類が少ない列）

データの重複度が高い列とは，例えば，0と1の2種類の値しか持たないフラグやステータス情報を設定する列が該当します。このような列に対して単一列インデクスを作成しても，行を絞り込めないため，大量の行にアクセスします。インデクスを使った検索は，行の格納順序は意識しないランダムなアクセスです。したがって，大量の行にアクセスすると，インデクスを使用しない場合よりも時間が掛かることがあります。

図13‒2　フラグ列のインデクスを使用した検索処理の例

[picture]

データの重複度が高い列に対して探索条件を指定する場合は，ほかの探索条件に指定した列にインデクスを作成して，絞り込んでください。絞り込めない場合は，データの重複度が高い列も組み合わせて，複数列インデクスを作成してください。この場合，インデクス構成列の順序は，データの重複度が高い列を一番後ろにしてください。

(3)　作成方法

表にインデクスを作成するには，定義系SQLのCREATE INDEXを実行します。

(4)　共通規則

一つの表に最大255個のインデクスを定義できます。

ナル値を含む列又は行のない列に対してもインデクスを定義できます。

ビュー表にはインデクスを作成できません。

(5)　インデクスを定義できないデータ型

次に示すデータ型の列にはインデクスを定義できません。

BLOB

BINARY

抽象データ型

(6)　インデクスのキー長の上限

インデクスのキー長は，次に示す条件を満たす必要があります。この条件を満たさないとインデクスを定義できません。

インデクスのキー長（バイト）
≦MIN｛（インデクス格納RDエリアのページサイズ÷2）−1242，4036｝

インデクス格納RDエリアのページサイズが4096バイトの場合は，キー長が最大806バイトのインデクスが定義できます。インデクスのキー長については，表「インデクスのキー長一覧」を参照してください。

なお，複数列インデクスの場合は，複数列インデクスを構成する各列のキー長の合計がインデクスのキー長となります。

(7)　注意事項

一つの表に同じインデクスを二つ以上作成できません。異なるインデクス名であっても同じインデクスと扱われる場合の例を次に示します。

●単一列インデクスの場合

CREATE INDEX インデクス1 ON 表1 (列1 ASC)
CREATE INDEX インデクス2 ON 表1 (列1 DESC)

この場合，インデクス2はインデクス1と同じインデクスとして扱われます。このため，先に定義したインデクス1が有効になります。

●複数列インデクスの場合

CREATE INDEX インデクス1 ON 表1 (列1 ASC,列2 ASC)
CREATE INDEX インデクス2 ON 表1 (列1 DESC,列2 DESC)

又は

CREATE INDEX インデクス1 ON 表1 (列1 ASC,列2 DESC)
CREATE INDEX インデクス2 ON 表1 (列1 DESC,列2 ASC)

この場合，インデクス1とインデクス2は同じインデクスとして扱われます。このため，先に定義したインデクス1が有効になります。なお，次に示す場合は，互いに異なるインデクスになります。

CREATE INDEX インデクス1 ON 表1 (列1 DESC,列2 DESC)
CREATE INDEX インデクス2 ON 表1 (列1 ASC,列2 DESC)

13.2.2　インデクス構成列の検討

(1)　探索条件を満たすデータだけに絞り込む場合

(a)　インデクス構成列の組み合わせ

探索条件を満たすデータだけに絞り込む場合は，探索条件に指定する列にインデクスを作成してください。AND演算子を使用して，複数の探索条件を満たすデータだけに絞り込む場合は，探索条件に指定する複数の列に対して，一つのインデクスを作成してください。すべての探索条件を一つのインデクスで絞り込む方が，効率が良いです。複数の探索条件を一つのインデクスで絞り込む例を次に示します。

（例）

SQL文

SELECT * FROM TBL1 WHERE C1 = 10 AND C2 = 20 AND C3 = 30

インデクス定義

CREATE INDEX IDX1 ON TBL1(C1, C2, C3)

図13‒3　複数の探索条件を一つのインデクスで絞り込む例

[picture]

[図データ]［注意事項］

AND演算子を使用して，複数の探索条件を満たすデータだけに絞り込む場合に，探索条件のそれぞれの列に単一列インデクスを作成しても，どれか一つのインデクスしか使用しません※。インデクスに含まれない列の条件は，行データを参照して評価します。次に例を示します。

（例）

SQL文

SELECT * FROM TBL1 WHERE C1 = 10 AND C2 = 20 AND C3 = 30

インデクス定義

CREATE INDEX IDX1 ON TBL1(C1)

CREATE INDEX IDX2 ON TBL1(C2)

CREATE INDEX IDX3 ON TBL1(C3)

図13‒4　探索条件のそれぞれの列に単一列インデクスを作成した場合

[picture]

注※

SQL最適化オプションの指定内容によっては，インデクスを複数使用することがあります。ただし，一つの複数列インデクスを使用する方が効率が良いです。

(b)　インデクス構成列の順序

複数列インデクスの場合，第1構成列は，必ず「=」条件を指定する列にします。また，「=」条件を指定する場合が多い列ほど先に指定します。これによって，インデクス内の検索範囲を小さくできるため，インデクス内の検索時間を短縮できます。

インデクス構成列順序による検索範囲の違いについて，次に例を示します。

（例1）

「=」条件を指定した列が第1構成列である場合

SQL文

SELECT * FROM TBL1 WHERE C1 = 'B' AND C2 BETWEEN 10 AND 50

インデクス定義

CREATE INDEX IDX1 ON TBL1(C1,C2)

図13‒5　「=」条件を指定した列が第1構成列である場合

[picture]

（例2）

「=」条件を指定した列が第1構成列ではない場合

SQL文

SELECT * FROM TBL1 WHERE C1 = 'B' AND C2 BETWEEN 10 AND 50

インデクス定義

CREATE INDEX IDX2 ON TBL1(C2,C1)

図13‒6　「=」条件を指定した列が第1構成列ではない場合

[picture]

「=」条件を指定した列については，インデクス構成列の順序を探索条件の指定順序と一致させる必要はありません。次に例を示します。

（例）

SQL文

SELECT * FROM TBL1 WHERE C3 = 10 AND C1 = 20 AND C2 = 30

インデクス定義

CREATE INDEX IDX1 ON TBL1(C2, C3, C1)

［説明］

インデクス構成列の順序が(C3, C1, C2)である必要はありません。

[図データ]［注意事項］

「=」条件を指定した場合でも，フラグやステータス情報を設定する列のようにデータの重複度が高い列は，インデクス構成列には適しません。詳細は，「インデクス作成に適さない列」を参照してください。

(2)　表を結合する場合

(a)　インデクス構成列の組み合わせ

表を結合する場合は，結合列にインデクスを作成してください。結合列にインデクスを作成することで，表の結合方法を効率の良いNESTED LOOPS JOINにできます。

結合列が複数ある場合は，すべての結合列を含んだ複数列インデクスを作成してください。すべての結合列がインデクス構成列に含まれていないと，NESTED LOOPS JOINを効率良く処理できません。詳細は，マニュアル「HiRDB パフォーマンスガイド」の「効率の悪いNESTED LOOPS JOINの対策」を参照してください。

NESTED LOOPS JOINでは，内表の結合列に作成したインデクスを利用します。内表に探索条件が指定されている場合は，結合列に加えて，探索条件に指定した列をインデクス構成列に含めてください。

結合列と探索条件に指定した列を含んだインデクスの例を次に示します。

（例）

SQL文

SELECT * FROM TBL1 INNER JOIN BY NEST TBL2

　ON TBL1.C1 = TBL2.C1 AND TBL1.C2 = TBL2.C2

　WHERE TBL1.C1=10 AND TBL2.C3 BETWEEN 100 AND 500

内表TBL2のインデクス定義

CREATE INDEX IDX2 ON TBL2(C1,C2,C3)

外表TBL1のインデクス定義

CREATE INDEX IDX1 ON TBL1(C1)

図13‒7　結合列と探索条件に指定した列を含んだインデクスの場合

[picture]

探索条件に指定した列がインデクスに含まれていない場合，探索条件は行データを参照して評価することになります。次に例を示します。

（例）

SQL文

SELECT * FROM TBL1 INNER JOIN BY NEST TBL2

　ON TBL1.C1 = TBL2.C1 AND TBL1.C2 = TBL2.C2

　WHERE TBL1.C1=10 AND TBL2.C3 BETWEEN 100 AND 500

内表TBL2のインデクス定義

CREATE INDEX IDX2 ON TBL2(C1,C2)

外表TBL1のインデクス定義

CREATE INDEX IDX1 ON TBL1(C1)

図13‒8　探索条件に指定した列がインデクスに含まれていない場合

[picture]

(b)　インデクス構成列の順序

インデクス構成列の順序は，結合条件及び探索条件の指定方法によって決定してください。詳細は「探索条件を満たすデータだけに絞り込む場合」の「インデクス構成列の順序」を参照してください。

(3)　探索条件を指定し，かつORDER BY，GROUP BYを指定している場合

(a)　インデクス構成列の組み合わせ

探索条件に使用する列に加えて，ORDER BY，GROUP BYに指定する列をインデクス構成列に含めると，HiRDBが実行するソート処理を省略できることがあるため，効率良く処理ができます。ソート処理を省略できる条件については，マニュアル「HiRDB コマンドリファレンス」の「アクセスパス表示ユティリティ（pdvwopt）」の「ORDER BY，GROUP BYを指定した検索に使用する表のインデクス定義」を参照してください。

(b)　インデクス構成列の順序

探索条件として指定する列，グループ分け又はソートする列の順で構成する複数列インデクスを作成します。

次に例を示します。

（例）

SQL文

SELECT * FROM TBL1 WHERE C3 = 10 AND C1 = 20

ORDER BY C4 DESC,C2 ASC

インデクス定義

CREATE INDEX IDX1 ON TBL1(C3 ASC, C1 ASC, C4 DESC, C2 ASC)

注

　インデクス構成列ごとのASC，DESCの指定は，ORDER BYの指定と合わせてください。

(4)　一つの表に作成した複数のインデクスの構成列が，重複している場合

SQLごとにインデクスを検討した結果，一つの表に対して複数のインデクスを作成することがあります。しかし，インデクスの数が多いと性能に影響を与えることがあります。詳細は，「インデクスの数が性能に与える影響」を参照してください。

そこで，構成列が重複しているインデクスが複数ある場合は，一つのインデクスに統合できるか検討してください。インデクスを統合する場合，性能を優先したいSQLの条件に指定した列が，インデクスの第1構成列から連続する順序になるようにしてください。次に例を示します。

（例）

SQL文1（性能を優先したいSQL）

SELECT * FROM TBL1 WHERE C3 = 10 AND C1 = 20

SQL文2

SELECT * FROM TBL1 WHERE C3 = 10 AND C2 = 30

インデクス定義

CREATE INDEX IDX1 ON TBL1(C3, C1, C2)

図13‒9　SQL文1を検索する場合

[picture]

図13‒10　SQL文2を検索する場合

[picture]

どちらのSQLの性能も優先したい場合は，それぞれのSQLに合わせたインデクスを作成してください。次に例を示します。

（例）

SQL文1

SELECT * FROM TBL1 WHERE C3 = 10 AND C1 = 20

SQL文2

SELECT * FROM TBL1 WHERE C3 = 10 AND C2 = 30

インデクス定義

CREATE INDEX IDX1 ON TBL1(C3, C1)

CREATE INDEX IDX2 ON TBL1(C3, C2)

[図データ]［注意事項］

インデクスの追加や，構成列を変更すると，SQLのアクセスパスが変わることがありますので，その表を操作するSQLのアクセスパスを再確認してください。

13.2.3　インデクスを複数使用する場合

表には複数のインデクスを作成できます。一つのインデクス（単一列インデクス又は複数列インデクス）を使用するよりも複数のインデクスを使用した方が，より行を絞り込める場合に有効です。

13.2.4　除外キー値を設定したインデクスの使用

インデクスを定義した列のデータは，すべてインデクスのキー値としてインデクス中に取り込まれます。ところが，インデクス中にはナル値のような余分なキー値もあります。このように，すべての構成列の値がナル値から成るキー値の重複が多いインデクスに対してナル値を除外キー値として指定できます。

(1)　インデクスに除外キー値を設定した場合の効果

インデクスに除外キー値を設定することで，次に示す効果が期待できます。

インデクスには，ナル値のキーを作成しないため，インデクスの容量を削減できます。

行の挿入，削除及び更新時のインデクスメンテナンスのオーバヘッド（CPU時間，入出力回数，排他制御要求回数及びデッドロック発生頻度）とログ量を削減できます。

ナル値を除外キー値とするインデクスの構成列に対する探索条件が，IS NULL，VALUE，又はCASE式を指定した検索ではインデクスを使用しません。これによって，次に示す場合に検索性能が向上します。

ナル値の重複が多い状態でインデクスを使用し，データページをランダムにアクセスしたため，同じページに入出力処理が発生していた場合

(2)　設定方法

除外キー値を設定するには，定義系SQLのCREATE INDEXにEXCEPT VALUESオプションを指定します。

(3)　注意

除外キー値を指定できるのはナル値だけで構成されたキー値です。

非ナル値制約の列を含むインデクスには除外キー値を指定できません。

クラスタキー指定を指定したインデクスには除外キー値を指定できません。

インデクス順にアンロードをする場合，除外キー値を持つインデクスは指定できません。

13.2.5　インデクスの数が性能に与える影響

行を追加又は削除するとき，該当する表に作成しているすべてのインデクスが更新されます。このため，作成するインデクスの数が増えると，インデクスの更新処理のオーバヘッドが増加します。そのため，次に示す点を考慮してインデクスを作成します。

更新の多い列にはインデクスを定義しないようにします。

複数列インデクスを作成して，インデクスの数を減らします。

HiRDB/パラレルサーバの場合に，主に全件検索をするときは，並列処理の効果を上げるため，最低限の数だけインデクスを作成するようにします。

13.3　インデクスの横分割

表を横分割した場合，横分割した表に対応させて，インデクスも複数のユーザ用RDエリアにわたって横分割できます。

13.3.1　分割キーインデクスと非分割キーインデクス

横分割インデクスを設計する前に，分割キーインデクスと非分割キーインデクスについて理解する必要があります。

インデクスがある一定の条件を満たすと，そのインデクスは分割キーインデクスになり，条件を満たさないインデクスは非分割キーインデクスになります。この条件は，表が単一列分割か複数列分割かによって異なります。

注

表の分割条件に一つの列だけを使用している場合を単一列分割といい，表の分割条件に複数の列を使用している場合を複数列分割といいます。

(1)　単一列分割の場合

次に示すどちらかの条件を満たす場合，そのインデクスは分割キーインデクスになります。

〈条件〉

表を横分割するときに格納条件を指定した列（分割キー）に定義した単一列インデクス

表を横分割するときに格納条件を指定した列（分割キー）を第1構成列とした複数列インデクス

次に示すZAIKO表を例にして，インデクスが分割キーインデクスになる場合を次の図に示します。

図13‒11　分割キーインデクスになる場合（単一列分割の場合）

[picture]

〔説明〕

CREATE INDEX A12 ON ZAIKO (SCODE ASC)                1
CREATE INDEX A12 ON ZAIKO (SCODE ASC,TANKA DESC)     2
CREATE INDEX A12 ON ZAIKO (TANKA DESC,SCODE ASC)     3

分割キーであるSCODE列をインデクスとした場合，そのインデクスは分割キーインデクスになります。そのほかの列をインデクスとした場合，そのインデクスは非分割キーインデクスになります。

分割キーであるSCODE列を複数列インデクスの第1構成列にすると，その複数列インデクスは分割キーインデクスになります。

分割キーであるSCODE列を第1構成列以外に指定すると，その複数列インデクスは非分割キーインデクスになります。

(2)　複数列分割の場合

次に示す条件を満たす場合，そのインデクスは分割キーインデクスになります。

〈条件〉

分割キーを先頭とし，分割に指定した列を先頭から同順にすべて含んで，複数の列に作成したインデクス

次に示すZAIKO表を例にして，インデクスが分割キーインデクスになる場合を次の図に示します。

図13‒12　分割キーインデクスになる場合（複数列分割の場合）

[picture]

〔説明〕

CREATE INDEX A12 ON ZAIKO (SCODE ASC,TANKA DESC)               1
CREATE INDEX A12 ON ZAIKO (SCODE ASC,TANKA DESC,ZSURYO ASC)    2
CREATE INDEX A12 ON ZAIKO (TANKA DESC,SCODE ASC)               3
CREATE INDEX A12 ON ZAIKO (SCODE ASC,ZSURYO DESC,TANKA ASC)    4

すべての分割キー（SCODE及びTANKA列）を指定し，かつ分割キーの指定順序が表定義時と同じため，この複数列インデクスは分割キーインデクスになります。

すべての分割キー（SCODE及びTANKA列）を指定し，かつ分割キーの指定順序が表定義時と同じため，この複数列インデクスは分割キーインデクスになります。

すべての分割キー（SCODE及びTANKA列）を指定しているが，分割キーの指定順序が表定義時と異なるため，この複数列インデクスは非分割キーインデクスになります。

すべての分割キー（SCODE及びTANKA列）を指定しているが，分割キーの指定順序が表定義時と異なるため，この複数列インデクスは非分割キーインデクスになります。

13.3.2　インデクスの分割指針

インデクスが分割キーインデクスか非分割キーインデクスかによって，次の表に示すとおりインデクスの分割指針が異なります。

表13‒2　インデクスの分割指針

インデクス の種類 | HiRDB/シングル サーバの場合 | HiRDB/パラレルサーバの場合
表をサーバ内 横分割する場合 | 表をサーバ間 横分割する場合
インデクスが分割キーインデクスの場合 | 横分割表に対応させてインデクスも横分割します。 | 横分割表に対応させてインデクスも横分割します。 | 横分割表に対応させてインデクスも横分割します。
インデクスが非分割キーインデクスの場合 | インデクスを横分割しないことをお勧めします。インデクスを横分割すると，インデクスを使用した検索性能が悪くなることがあります※。 | インデクスを横分割しないことをお勧めします。インデクスを横分割すると，インデクスを使用した検索性能が悪くなることがあります※。

注※

非分割キーインデクスは横分割しないことをお勧めします。インデクスを横分割すると，インデクスを使用した検索性能が悪くなることがあります。具体的には，次に示すアクセスパスを使用した検索ができなくなるため，インデクスを使用した検索性能が悪くなることがあります。

KEY SCAN MERGE JOIN

LIST SCAN MERGE JOIN

L-KEY R-LIST MERGE JOIN

L-KEY R-SORT MERGE JOIN

L-LIST R-KEY MERGE JOIN

L-LIST R-SORT MERGE JOIN

L-SORT R-KEY MERGE JOIN

L-SORT R-LIST MERGE JOIN

これらのアクセスパスについては，マニュアル「HiRDB コマンドリファレンス」のアクセスパス表示ユティリティ（pdvwoptコマンド）を参照してください。

ただし，表のデータが非常に多い場合は，インデクスの横分割を検討してください。インデクスを横分割すると，表格納RDエリアとインデクス格納RDエリアが1対1で管理できるため，ユティリティの操作性が向上します。例えば，インデクスを横分割しない場合にRDエリア単位のデータロード，又はRDエリア単位の再編成をしたときは，データロード又は再編成後にインデクスを一括作成する必要があります。インデクスを横分割すれば，RDエリア単位のデータロード，又はRDエリア単位の再編成後にインデクスを一括作成する必要はありません。

なお，マトリクス分割表にインデクスを定義する場合，非分割キーインデクスであっても分割キーと同様に横分割する必要があります。

13.3.3　設計上の考慮点

横分割表を格納するユーザ用RDエリアと，横分割表のそれぞれに対応するインデクスを格納するユーザ用RDエリアを分けます。これによって，それぞれのユーザ用RDエリアの使用効率が良くなります。

表の中に一意にしたいキーがあるときは，このキーにUNIQUEを指定した分割キーインデクスを定義します。又は，分割キーに対してクラスタキーを指定します。また，非分割キーインデクスの場合でも，次のどちらかであればUNIQUEを指定できます。

非分割インデクス

分割キーを任意の構成列に含む分割インデクス

ただし，フレキシブルハッシュ分割した表では，インデクスにUNIQUEを指定できません。詳細については，マニュアル「HiRDB SQLリファレンス」の「CREATE INDEX」の「表を横分割する場合のUNIQUE指定可否」を参照してください。

13.3.4　インデクスの横分割の例（HiRDB/シングルサーバの場合）

インデクスの横分割の例（HiRDB/シングルサーバの場合）を次の図に示します。

図13‒13　インデクスの横分割の例（HiRDB/シングルサーバの場合）

[picture]

〔説明〕

ディスクのアクセス競合を避けるために，分割した表及びインデクスを格納するRDエリアを異なるディスク上に配置してください。

分割キーインデクスは横分割してください。

性能を重視する場合は，非分割キーインデクスを横分割しないでください。

操作性を重視する場合は，非分割キーインデクスを横分割してください。

13.3.5　インデクスの横分割の例（HiRDB/パラレルサーバの場合）

(1)　表をサーバ内横分割する場合

インデクスの横分割の例（サーバ内横分割の場合）を次の図に示します。

図13‒14　インデクスの横分割の例（サーバ内横分割の場合）

[picture]

〔説明〕

ディスクのアクセス競合を避けるために，分割した表及びインデクスを格納するRDエリアを異なるディスク上に配置してください。

分割キーインデクスは横分割してください。

性能を重視する場合は，非分割キーインデクスを横分割しないでください。

操作性を重視する場合は，非分割キーインデクスを横分割してください。

(2)　表をサーバ間横分割する場合

インデクスの横分割の例（サーバ間横分割の場合）を次の図に示します。

図13‒15　インデクスの横分割の例（サーバ間横分割の場合）

[picture]

〔説明〕

ディスクのアクセス競合を避けるために，分割した表及びインデクスを格納するRDエリアを異なるディスク上に配置してください。

分割キーインデクス及び非分割キーインデクスを横分割してください。

13.4　プラグインインデクス

13.4.1　プラグインインデクスの効果と作成方法

ここでは，プラグインインデクスについて説明します。

(1)　プラグインインデクスの効果

性能の向上

プラグインを使用している場合に，プラグインインデクスを作成すると，表の検索性能を向上できます。プラグインで提供されるインデクス型を使用すると，複雑な検索を高速にできます。

(2)　作成方法

表にプラグインインデクスを作成するには，定義系SQLのCREATE INDEXを実行します。

(3)　注意

プラグインによっては，あらかじめ指定されたプラグインによるプラグインインデクスの定義を前提としていることがあります。その場合，プラグインインデクスを定義しないで，プラグインインデクスを利用する関数を指定すると，実行時にエラーが返されることがあります。

(4)　プラグインインデクスの一括作成

プラグインインデクスは，データベース作成ユティリティ（pdload）による一括作成ができます。プラグインインデクスの一括作成については，「プラグインが提供する抽象データ型を定義した表の作成」を参照してください。

13.5　プラグインインデクスの横分割

表を横分割した場合，横分割した表に対応させて，プラグインインデクスも複数のユーザLOB用RDエリアにわたって横分割する必要があります。

13.5.1　プラグインインデクスの横分割の効果

操作性の向上

プラグインインデクスの一括作成をするときに，ユーザLOB用RDエリアごとに独立した運用ができます。

13.5.2　定義方法

プラグインインデクスの横分割の定義方法については，「プラグインが提供する抽象データ型を定義した表の作成」を参照してください。

13.5.3　プラグインインデクスの横分割の形態

HiRDB/シングルサーバとHiRDB/パラレルサーバの，それぞれの場合でのプラグインインデクスの横分割の形態を次に示します。

(1)　HiRDB/シングルサーバの場合

HiRDB/シングルサーバの場合は，横分割した表に対応させて，複数のディスク上のユーザLOB用RDエリアにわたってプラグインインデクスを横分割できます。

プラグインインデクスの横分割の形態および横分割の例を次の図に示します。

図13‒16　プラグインインデクスの横分割の形態（HiRDB/シングルサーバの場合）

[picture]

図13‒17　プラグインインデクスの横分割（キーレンジ分割）の例（HiRDB/シングルサーバの場合）

[picture]

〔説明〕

取扱説明書列にプラグインインデクスが設定してあるとします。

薬品管理表を薬品IDを条件として，ユーザLOB用RDエリアLOBSGML1，LOBSGML2にわたって横分割しています。これに対応して，プラグインインデクスをLOBNGRAM1，LOBNGRAM2に格納しています。

(2)　HiRDB/パラレルサーバの場合

HiRDB/パラレルサーバの場合は，横分割した表に対応して，複数のサーバマシン又はバックエンドサーバに配置されたユーザLOB用RDエリアにわたってプラグインインデクスを横分割できます。

プラグインインデクスの横分割の形態および横分割の例を次の図に示します。

図13‒18　プラグインインデクスの横分割の形態（HiRDB/パラレルサーバの場合）

[picture]

図13‒19　プラグインインデクスの横分割（キーレンジ分割）の例（HiRDB/パラレルサーバの場合）

[picture]

〔説明〕

取扱説明書列にプラグインインデクスが設定してあるとします。

薬品管理表を薬品IDを条件として，ユーザLOB用RDエリアLOBSGML1〜LOBSGML3にわたって横分割しています。これに対応して，プラグインインデクスをLOBNGRAM1，LOBNGRAM2，LOBNGRAM3に格納しています。

13.5.4　設計上の考慮点

横分割表を格納するユーザLOB用RDエリアと，横分割表のそれぞれに対応するプラグインインデクスを格納するユーザLOB用RDエリアを分ける必要があります。

13.5.5　注意

横分割するとRDエリアの数が増えるため，RDエリア指定のデータベースのバックアップ時には，表とインデクスの対応が1対1であることに注意してください。

13.6　インデクスの優先順位

検索する表に複数のインデクスが定義されている場合，HiRDBが使用するインデクスの優先順位について，次の表に示します。SQLで使用したいインデクスの優先順位を確認してください。使用したいインデクスよりも優先順位の高い別のインデクスがある場合は，使用インデクスのSQL最適化指定で，使用したいインデクス名を指定してください。詳細については，マニュアル「HiRDB SQLリファレンス」の「使用インデクスのSQL最適化指定」を参照してください。

表13‒3　HiRDBが使用するインデクスの優先順位

優先順位 | HiRDBが優先して使用するインデクスの内容 | インデクスがある列（C1）に対する条件の指定例
1 （必ず使用する※1） | インデクス型プラグイン専用関数の条件が「IS TRUE」であり，この関数の第一引数の列に指定したプラグインインデクス | contains(C1,'…') IS TRUE
構造化繰返し述語の探索条件に含まれるすべての列をインデクス構成列に含むインデクス | ARRAY(C1,C2)[ANY] 　(C1='ABC' and C2=10) C1，C2の複数列インデクスを定義しています。
2 | プラグイン提供関数の条件が「IS TRUE」であり，この関数の第一引数の列に指定したプラグインインデクス | within(C1,'…') IS TRUE
3 | 「=」の制限条件の対象になる列にある，UNIQUEを指定したインデクス | C1=100
4 | 「=」の制限条件の対象になる列にあるインデクス | C1=100
5 | 「IS NULL」の制限条件の対象になる列にあるインデクス※2 | C1 IS NULL
6 | LIKE述語，又はSIMILAR述語のパターン文字列に定数で「%」による前方一致比較を指定した列にあるインデクス | C1 LIKE 'ABC%' C1 SIMILAR TO 'ABC%'
7 | LIKE述語，又はSIMILAR述語のパターン文字列に定数で上記以外の前方一致比較を指定した列にあるインデクス | C1 LIKE 'ABC_' C1 SIMILAR TO 'ABC_'
8 | IN述語の制限条件の対象になる列にあるインデクス | C1 IN(10,20,30)
9 | BETWEEN述語の制限条件の対象になる列にあるインデクス | C1 BETWEEN 20 AND 40
範囲条件を指定した列にあるインデクス | 20<=C1 AND C1<=40
10 | 外への参照がない副問合せを使用したIN述語の制限条件の対象になる列にある単一列インデクス | C1 IN(SELECT C1 FROM T2)
外への参照がない副問合せを使用した限定述語「=ANY」又は「=SOME」の制限条件の対象になる列にある単一列インデクス | C1=ANY(SELECT C1 FROM T2) C1=SOME(SELECT C1 FROM T2)
11 | >，>=，<及び<=の制限条件の対象になる列にあるインデクス | C1>50 C1<=200
12※3 | スカラ演算（システム定義スカラ関数，IS_USER_CONTAINED_IN_HDS_GROUPは除く）を指定した列にあるインデクス※2 | length(C1)=10
13 | NOT BETWEEN述語の制限条件の対象になる列にあるインデクス | C1 NOT BETWEEN 10 AND 30
14 | XLIKE述語及び上記以外のLIKE述語，又はSIMILAR述語の制限条件の対象になる列にあるインデクス | C1 XLIKE '%ABC%' C1 LIKE '%ABC%' C1 SIMILAR TO '%ABC%'
15 | 集合関数（MIN又はMAX）の引数に指定した列にあるインデクス※4 | MIN(C1) MAX(C1)
16 | 結合条件列及びグループ分け又はソートの対象になる列にあるインデクス | ORDER BY C1
− | 否定（NOT BETWEENを除く）の制限条件の対象になる列にあるインデクス | C1 NOT LIKE '%ABC%' C1 IS NOT NULL
上記以外の限定述語「ANY」又は「SOME」の制限条件の対象になる列にあるインデクス | C1>=ANY(SELECT C1 FROM T2) C1>SOME(SELECT C1 FROM T2)
限定述語「ALL」の制限条件の対象になる列にあるインデクス | C1>ALL(SELECT C1 FROM T2)
プラグイン提供関数の条件が「IS FALSE」又は「IS UNKNOWN」であり，この関数の第一引数の列に指定したプラグインインデクス | within(C1,'…') IS FALSE

（凡例）−：使用しないインデクスを示します。

注

関数呼出し「contains」は，HiRDB Text Search Plug-inが提供するプラグインの関数です。

関数呼出し「within」は，HiRDB Spatial Search Plug-inが提供するプラグインの関数です。

外への参照がある副問合せを含む制限条件の対象になる列にあるインデクスは使用できません。

OR演算子で両側の条件式にインデクスを利用できる場合は，優先度がその条件式中の述語によって変わります。

制限条件とは，結合条件以外の探索条件のことです。

定義したインデクスが有効に利用できないとHiRDBが判断した場合は，該当するインデクスが使用されないことがあります。

注※1

このインデクスを定義していないと，実行できないでエラーとなります。必ず定義してください。

注※2

次の列に対して，ナル値を除外キーとするインデクスは使用しません。

「IS NULL」の制限条件を指定した列

制限条件中の「VALUE」及び「CASE式」に指定した列

制限条件中の「BIT_AND_TEST」に対して「IS UNKNOWN」，「IS NOT TRUE」，又は「IS NOT FALSE」を指定し，この「BIT_AND_TEST」に指定した列

ただし，上記以外の制限条件を指定しているインデクスは使用します。その場合のナル値を除外キーとするインデクスの使用有無を表「ナル値を除外キーとするインデクスの使用有無」に示します。

注※3

SQL最適化オプションに「スカラ演算を含むキー条件の適用」を指定した場合だけ，インデクスを優先して使用します。SQL最適化オプションの詳細は，マニュアル「HiRDB UAP開発ガイド」を参照してください。また，述語の種類によっては優先順位が下がることもあります。否定が含まれない場合の優先順位は13〜15の範囲になります。否定が含まれる場合の優先順位は13〜−の範囲になります。

注※4

表の指定が一つで，GROUP BYを指定していないSQL文の場合は，集合関数（MIN又はMAX）だけを指定して，次に示すどれかの条件を満たすときに引数に指定した列のインデクスを使用します。

集合関数の引数に指定した列が，単一列インデクスの構成列の場合

集合関数の引数に指定した列が，除外キーを持たない複数列インデクスの第n構成列の場合で，第1構成列から第（n−1）構成列までに「=」又は「IS NULL」を指定したとき

集合関数の引数に指定した列が，除外キーを持つ複数列インデクスの第n構成列の場合で，第1構成列から第（n−1）構成列までに「=」を指定したとき

表13‒4　ナル値を除外キーとするインデクスの使用有無

構成列に指定する制限条件 | 使用有無
IS NULL，VALUE，CASE式，BIT_AND_TEST | IS NULL，VALUE，CASE式，BIT_AND_TEST以外※1
指定あり | 指定あり | 使用します
指定あり | 指定なし | 使用しません
指定なし | 指定あり | 使用します※2
指定なし | 指定なし | 使用しません※3

注※1

「HiRDBが使用するインデクスの優先順位」に示す優先順位の4〜15の制限条件の場合です。

注※2

インデクスが有効に利用できない場合などは，HiRDBが判断してインデクスを使用しないことがあります。

注※3

次に示すすべての条件を満たす検索では使用します。

選択式が，インデクス構成列を引数とする集合関数だけ

FROM句には，一つの表だけ指定している

WHERE句の指定がない

14　RDエリアの設計

この章では，RDエリアを構成するセグメント及びページを設計する上で検討する項目について説明します。

14.1　RDエリアを設計するときの検討項目

RDエリアを構成するセグメントやページの大きさによって，ディスク所要量が異なります。この点を考慮してRDエリアを設計する必要があります。RDエリアを設計するときの検討項目とRDエリアに関する最大値・最小値を次の表に示します。

表14‒1　RDエリアを設計するときの検討項目

設計作業ごとの検討項目 | 長　所 | 短　所 | 記載箇所
セグメントサイズ | 大きくした場合 | 行長が変わるような更新をする場合や，クラスタキーを指定した表に行を追加する場合，行を格納した特定のページに近接する未使用のページを確保できるため，データの入出力時間を削減できます。 | セグメント数が少なくなるため，一つのユーザ用RDエリアに格納できる表とインデクスの数が少なくなります。 | 「セグメントサイズの決定」を参照してください。
小さくした場合 | 一つのユーザ用RDエリアにデータ量の少ない表を多く格納する場合は，余分な未使用ページを削減できます。 | ユーザ用RDエリアに大量のデータを追加すると，セグメントの割り当て回数が増加するため，オーバヘッドが大きくなります。 セグメントの数が多くなるため，表を削除したり，表の全行削除をしたりする場合，排他制御の資源が多くなります。
セグメント内の空きページ比率 | 設定した場合 | 表にデータを追加する場合，クラスタキーを指定している表に対しては，クラスタキーの値に近い場所のページにデータを格納できるため，データの入出力回数を削減できます。 | 設定値を大きくする分，ディスク所要量が増加します。 | 「セグメント内の空きページ比率の設定」を参照してください。
0にした場合 | ディスク所要量を削減できます。 | クラスタキーを指定している表の場合，データの追加時にクラスタキーの値に近い場所にデータを格納できなくなるため，格納状態が乱れ，データの入出力回数の削減効果がなくなります。
ページ長 | ページ内の未使用領域の比率を設定した場合 | UPDATE文で行長が元の行よりも長くなる更新をしても，連続した空き領域が更新後の行長よりも大きい場合は，該当する行がそのページに収まるようになります。 INSERT文で行を繰り返し追加するときに，クラスタキーの値に近い場所のページに，1ページ内が一杯になるまで行を追加できるようになります。 | FIX属性の表の場合は格納効率が悪くなります。 | 「ページ内の未使用領域の比率の設定」を参照してください。
ページ内の未使用領域の比率を0にした場合 | FIX属性の表の場合，データが昇順になるようなときは，格納効率が良くなります。 | 行長が元の行よりも長くなる更新をすると，行が複数ページにわたるため，行にアクセスするときにオーバヘッドが掛かります。
空き領域の再利用 | 使用した場合 | 使用中セグメント内の空き領域を有効活用できます。 RDエリア満杯後の空き領域サーチの性能が向上します。 | 再利用するのに十分空き領域がない場合，空き領域サーチのオーバヘッドが増えます。 | 「空き領域の再利用機能」を参照してください。
使用しない場合 | 空き領域が十分ある状態であれば，挿入処理が高速にできます。 | RDエリアの格納効率が低下します。また，RDエリア満杯後の空き領域サーチの性能が低下します。
共用RDエリア | 使用した場合 | アクセスが多いが，分割が難しい表を共用RDエリアに格納すると，全バックエンドサーバから参照できるため，並列処理の効率が上がります。 | 共用表を更新する場合，更新する共用表がある共用RDエリアに排他を掛けるので，共用RDエリアのほかの表にアクセスする業務があると，デッドロックが発生することがあります。 | 「共用RDエリア（HiRDB/パラレルサーバ限定）」を参照してください。
使用しない場合 | 共用RDエリアが原因となるデッドロックや，サーバ間のグローバルデッドロックが発生しません。 | 結合処理などの複雑な検索処理の場合，複数のバックエンドサーバ接続とデータ転送のオーバヘッドが増えます。
一時表用RDエリア | 使用した場合 | 一時表を使用して，複雑なデータ処理をしたり，ほかのユーザの影響を受けないでトランザクションやSQLセッションを実行できます。また，一時表の場合後処理が不要です。 | HiRDB開始時，又は一時表に最初にINSERT文が実行された時に，一時表用RDエリアを初期化するオーバヘッドが発生します。 | 「一時表用RDエリア」を参照してください。
使用しない場合 | HiRDB開始時に，一時表用RDエリアを初期化するオーバヘッドが発生しません。 | 複雑な処理で中間処理結果を表に格納する場合，処理完了後にデータを削除するなどの後処理が必要になります。

表14‒2　RDエリアに関する最大値・最小値

項目 | 最大値・最小値
総RDエリア数 | 3〜8,388,592
マスタディレクトリ用RDエリア数 | 1
データディレクトリ用RDエリア数 | 1
データディクショナリ用RDエリア数 | 1〜41
ユーザ用RDエリア数 | 1〜8,388,589
データディクショナリLOB用RDエリア数 | 1〜2
ユーザLOB用RDエリア数 | 0〜8,388,325
レジストリ用RDエリア数 | 0〜1
レジストリLOB用RDエリア数 | 0〜1
リスト用RDエリア数 | 0〜8,388,588
1RDエリア中のHiRDBファイル数 | 1〜16
1RDエリア中の実表数 | 0〜500
1RDエリア中のインデクス数 | 0〜500
1RDエリア中のリスト数 | 0〜50,000
総HiRDBファイル数 | 1〜134,217,728

●インデクス格納RDエリアの容量見積もりについて

インデクス格納RDエリアの容量見積もりについては，「ユーザ用RDエリアの容量の見積もり」を参照してください。ここでは，容量見積もり時の注意事項を説明します。

データベース作成ユティリティ又はデータベース再編成ユティリティでインデクスを一括作成した直後は，データはきれいに格納されています。その後のデータ挿入時にすべてのキーを昇順に挿入しないかぎり，インデクスページスプリットが発生するため，インデクスの一括作成時よりインデクスの容量が大きくなります。

インデクスページは基本的に使用中空きページを再使用しません。したがって，キー値を変更するような更新及び削除を行った場合，変更又は削除前のキーが格納されていたページを再使用できません。このように再使用されないむだな使用中空きページができてしまいます。ただし，使用中空きページを再利用する運用もできます。詳細は，マニュアル「HiRDB システム運用ガイド」を参照してください。

キー値の重複がある場合とない場合では基本的にインデクス構造が異なります。このため，正しく重複数を求めないとインデクスの容量が大きく異なってしまいます。インデクスレコード件数が少ない場合は，インデクスの容量に比べてこの誤差の占める割合が大きくなります。

14.2　セグメント

セグメントには次の表に示す状態があります。

表14‒3　セグメントの状態

セグメントの状態 | 説明
使用中セグメント※ | 表又はインデクスのデータを格納しているセグメントです。 データが満杯でセグメント内にデータを追加できないセグメントを満杯セグメント，それ以外の使用中セグメントを空きありセグメントといいます。 空きありセグメントのうち，データの削除でセグメント内の全ページが空きページ（使用中空きページ又は未使用ページ）のセグメントを使用中空きセグメントといいます。
未使用セグメント | 使用されたことがないセグメントです。このセグメントはRDエリア内のすべての表（又はインデクス）が使用できます。
空きセグメント | データを格納していないセグメントです。使用中空きセグメントと未使用セグメントは空きセグメントになります。

注※

使用中セグメントを使用できるのは，このセグメントにデータを格納した表又はインデクスだけです。ほかの表又はインデクスはこのセグメントを使用できません。

14.2.1　セグメントサイズの決定

通常，RDエリアのセグメントサイズは，RDエリア格納ページ数の1/10程度にすることをお勧めします。ただし，セグメントサイズの最大は16,000ページであるため，RDエリアの容量が大きい場合は，1/10以下になります。

セグメントサイズの大小による効果と注意を次に示します。

(1)　セグメントサイズを大きくした場合

性能の向上

行長が変わるような更新をする場合や，クラスタキーを指定した表に行を追加する場合，行を格納した特定のページに近接する未使用のページを確保できるため，データの入出力時間を削減できます。

同じ表のデータが連続したページに格納されるため，プリフェッチ機能による一括入力の効果が得られます。プリフェッチ機能を使用する場合，セグメントサイズは，システム共通定義のpdbufferオペランドの-pオプションで指定する一括入力最大ページ数に合わせることをお勧めします。

注意事項

セグメント数が少なくなるため，一つのユーザ用RDエリアに格納できる表とインデクスの数が少なくなります。

(2)　セグメントサイズを小さくした場合

ディスク所要量の削減

一つのユーザ用RDエリアにデータ量の少ない表を多く格納する場合は，余分な未使用ページを削減できます。

注意事項

セグメントサイズを小さくしたユーザ用RDエリアに大量のデータを追加すると，セグメントの割り当て回数が増加するため，オーバヘッドが大きくなります。

セグメントの数が多くなるため，表を削除したり，表の全行削除をしたりする場合，排他制御の資源が多くなります。

セグメントサイズの大小によるユーザ用RDエリアの概要を次の図に示します。

図14‒1　セグメントサイズの大小によるユーザ用RDエリアの概要

[picture]

(3)　設定方法

セグメントサイズは，データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で設定します。

14.2.2　セグメント内の空きページ比率の設定

表を定義するときにセグメント内に割り当てる空きページの割合をセグメント内の空きページ比率といいます。ここでいう空きページとは，未使用ページのことです。セグメント内の空きページの概要を次の図に示します。

図14‒2　セグメント内の空きページの概要

[picture]

(1)　設定の効果

セグメント内の空きページ比率の設定の効果を次に示します。

性能の向上

表にデータを追加する場合，クラスタキーを指定している表に対しては，クラスタキーの値に近い場所のページにデータが格納されます。このため，データの入出力回数を削減できます。

(2)　適用基準

クラスタキーを指定した表に，データベース作成ユティリティ（pdload）などでデータを格納した後，データの追加が大量に発生するような場合は，セグメント内の空きページ比率を設定するようにします。

データの追加又は更新がほとんど発生しない表の場合は，セグメント内の空きページ比率を0にします。

(3)　設定方法

セグメント内の空きページ比率は，定義系SQLのCREATE TABLEのPCTFREEオプションで指定します。

(4)　注意

セグメント内の空きページ比率に0を指定した場合，クラスタキーを指定している表にデータを追加するときは，クラスタキーの値に近い場所にデータを格納できなくなります。このため，データの格納状態が乱れ，データの入出力回数の削減効果がなくなります。

14.2.3　セグメントの確保と解放

表を定義したときにはセグメントを確保しません。表にデータを格納するときに必要に応じてセグメントを確保します。一度確保したセグメント（一度使用したセグメント）はそのセグメントを解放しないかぎり，ほかの表又はインデクスが使用できません。このため，データの追加と削除を繰り返した場合，データ量が増えていないのにRDエリアが容量不足になることがあります。これを防ぐには次に示す操作を定期的に行ってセグメントを解放してください。

データベース再編成ユティリティ（pdrorgコマンド）による表の再編成又はインデクスの再編成

空きページ解放ユティリティ（pdreclaimコマンド）による使用中空きセグメントの解放

表の再編成，インデクスの再編成，使用中空きセグメントの解放については，マニュアル「HiRDB システム運用ガイド」を参照してください。

なお，これらの操作以外にも次に示す場合はセグメントを解放します。

表の定義を削除した場合

表の全行削除をした場合

表の所有者（スキーマ）を削除した場合

インデクスの定義を削除した場合

表の主キーを削除した場合

RDエリアの再初期化をした場合

データロードを作成モード（-dオプション指定）で実行した場合

表の再編成をした結果，空きセグメントができた場合

また，次に示す場合では，そのトランザクションで確保したセグメントを解放します。

データベース作成ユティリティのデータロード処理又はインデクス一括作成処理でロールバックが発生した場合

データベース再編成ユティリティのリロード処理中にロールバックが発生した場合

14.3　ページ

ページには次の表に示す状態があります。

表14‒4　ページの状態

ページの状態 | 説明
未使用ページ | まだ割り当てられていないページです。
使用中空きページ | データの削除※によって，データが格納されていないページです。
使用中ページ | データが格納されていて，データを追加できる空き領域があるページです。 空き領域の再利用機能を使用している表の場合は，データの削除※によってページ内の空き領域が使用できないために，データを追加できなかったページを含みます。
使用中満杯ページ | データが格納されていて，データを追加できる空き領域がないページです。 空き領域の再利用機能を使用していない表及びインデクスの場合は，データの削除※によってページ内の空き領域が使用できないために，データを追加できなかったページを含みます。

注※

データの削除を実行したトランザクションがCOMMITするまで，データの削除によって発生した空き領域は使用できません。

14.3.1　ページ長の決定

(1)　ページ長を決定するときの考慮点

ページ長を決定するときの考慮点を次に示します。

全件検索及び更新，大量検索及び更新をする業務で，次に示す条件を満たす表，インデクスを格納するページ長は大きくします。

インデクスを付けない表を格納するRDエリア

クラスタキーを指定した表及びそのインデクスを格納するRDエリア

大量検索，大量更新の範囲条件となるインデクスを格納するRDエリア

ページ長は，RDエリアに格納する表の行長を基に，できるだけ無効領域が作られない長さにします。

無効領域＝MAX（mod（（ページ長−48），（行長＋2）），ページ長−48−（行長＋2）×255）

ページ内の未使用領域の比率を指定する場合は，次に示す計算式を目安にします。

（ページ長×ページ内の未使用領域の比率）÷100−行長×ページ内の未使用領域に格納できる行数

この場合，ページ内の未使用領域に1行も格納できなくなるような無意味なページ内の未使用領域の比率は指定しないようにします。

インデクスを格納するページの場合は，一般的に4096〜8192バイト程度が，入出力効率の面から適しています。

列のデータ型がVARCHAR，NVARCHAR及びMVARCHARで，定義長が256バイト以上の場合は，該当する列のデータが別のページに分岐されます。また，256バイト以上の可変長文字列データがある場合，その平均長以上で最も小さいページ長にします。

列のデータ型がVARCHAR，NVARCHAR及びMVARCHARの場合，INSERT文で行をナル値として挿入すると，UPDATE文で該当する列のデータを実データに更新するときに，更新したデータの長さによっては，該当する列のデータが別のページに分岐されることがあります。可変長文字列データの初期値をナル値として，後から実データに更新することが多い場合は，更新後の行長を見込んでページ長を決定します。

HiRDBでは，ページ又は行単位に排他制御ができます。行レベルの排他制御をする場合には，1ページに格納できる行数ができるだけ多くなるように，行長に応じてページ長を設定します。このとき，次に示す点を考慮します。

ページ内の未使用領域の比率を最低限にします。

ページの入出力要求に対するグローバルバッファの排他待ちが少なくなるようにします。更新が多い表の場合，排他待ちの回数が増える可能性があるため，ページ長を小さくします。

ページの入出力要求に対するページの入出力待ちが少なくなるようにします。ランダムアクセスが中心の業務で，ページ長が大き過ぎると，アクセス単位である行長に対する実際の入出力単位が大きくなって不要なデータ転送が発生するため，ページ長を小さくします。

ただし，UPDATE文で列のデータ型がVARCHAR，NVARCHAR及びMVARCHARのデータに対して行長が変更されるような更新を頻繁にする場合は，表を定義するときにページ内の未使用領域の比率を高めに設定します。ページ内の未使用領域の比率の設定については，「ページ内の未使用領域の比率の設定」を参照してください。

(2)　設定方法

ページ長は，データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で設定します。

(3)　ページ長を決定するときの注意

表に行を追加する場合，実際の行の長さ（データ型がVARCHAR，NVARCHAR及びMVARCHARの列を除いた長さ）がページ長を超えると，エラーになります。実際の行の長さは，「RDエリアの容量の見積もり」に記載されているディスク所要量の見積もり式を参照して求めます。求めた行の長さが，使用するユーザ用RDエリアのページ長より大きい場合は，ユーザ用RDエリアを再初期化して，ページ長を再設定する必要があります。RDエリアの再初期化は，データベース構成変更ユティリティ（pdmod）で実行します。RDエリアの再初期化については，マニュアル「HiRDB システム運用ガイド」を参照してください。

14.3.2　ページ内の未使用領域の比率の設定

表とインデクスを定義するときに，ページ内に割り当てる未使用領域の割合をページ内の未使用領域の比率といいます。未使用領域を設定しておくと，データベース作成ユティリティ（pdload）又はデータベース再編成ユティリティ（pdrorg）でデータを格納するとき，未使用領域にはデータは格納されません。

ただし，データベース作成ユティリティ（pdload）で-yオプション又はoption文を指定して実行し，新しいページが確保できなかった場合は，未使用領域にもデータが格納されます。

ページ内の未使用領域の概要を次の図に示します。

図14‒3　ページ内の未使用領域の概要

[picture]

(1)　設定の効果

UPDATE文で行長が元の行より長くなるような更新をしても，連続した空き領域が更新後の行長よりも大きい場合は，該当する行がそのページに収まるようになります。

INSERT文で行を繰り返し追加するときに，クラスタキーの値に近い場所のページに，1ページ内が一杯になるまで行を追加できるようになります。

(2)　適用基準

クラスタキーを指定した表に行を追加する場合に設定します。

FIX属性の表の場合，データが昇順になるようなときは，ページ内の未使用領域の比率を0にした方が，格納効率が良くなります。

行長が元の行よりも長くなるような更新をする場合に設定します。

行長が元の行長より長くなるのは，次に示す更新をしたときです。

ナル値から実データに更新したとき

データ型がVARCHAR，NVARCHAR，MVARCHAR，及びBINARYの列を長い値になるように更新したとき

(3)　設定方法

ページ内の未使用領域の比率は，定義系SQLのCREATE TABLE，CREATE INDEX，又はALTER TABLEのPCTFREEオプションで指定します。

(4)　注意

設定した未使用領域に余裕がない場合は，行長を元の行長より長くなるような更新をしたときに，1行が複数ページにわたるため，入出力回数が増えます。

(5)　ページ内の未使用領域の比率の求め方

最初に格納した行の行長がL1で，最終的にL2になる場合は，次に示す計算式で求めた値を未使用領域の比率とするのが一般的です。

　ページ内の未使用領域の比率=（（L2-L1）÷L2）×100（%）

表にクラスタキーを指定している場合は，次のように求めます。

データベース作成ユティリティ（pdload）でこの表にデータを格納する件数をページ当たりで求めます。これをm件とします。

その後，更に何件のデータを格納するかを求めます。これをn件とします。

1.と2.で求めたmとnから，次に示す計算式でページ内の未使用領域の比率を求めます。

　ページ内の未使用領域の比率=（n÷（m＋n））×100（%）

14.3.3　ページの確保と解放

(1)　ページの確保

表を定義したときにはページを確保しません。表にデータを格納するときに必要に応じてページを確保します。一度確保したページ（一度使用したページ）はそのページを解放しないかぎり，再使用できません。

インデクスを定義した場合は，データ件数に応じてページを確保します。データ件数0件の場合は1ページ（ルートページ）だけ確保します。ただし，CREATE INDEXにEMPTYオプションを指定した場合（インデクスの実体を作成しない場合）はページを確保しません。

注意事項

非FIX表で行長が変わるデータ更新を行った場合は，行長が減った分の領域を再使用できません。

インデクスページは削除ページに格納されていたキー値と同じキー値が追加されないかぎり，そのページを再使用しません。

データの削除によって発生した空き領域があるページを再使用するときは次に示す制限があるので注意してください。

・256バイト以上のVARCHAR，BINARY型，抽象データ型，及び繰返し列の分岐行は，そのページを使用できません。

・セグメントの使用率が100％になるまで，データの挿入時にそのページを使用できません。

・DELETEを実行したトランザクションがCOMMITを発行するまで，DELETEによって発生した空き領域を使用できません。

(2)　ページの解放

セグメントが解放されるとセグメント内のページは解放されます。

EXCLUSIVE指定のLOCK文で排他を掛けた表に対して，UAPがページ内の全行を削除すると，ページを解放します。インデクスのページは解放されません。

PURGE TABLE文を実行すると，表及びインデクスのページとセグメントが解放されます。ただし，インデクスのルートページは残ります。

空きページ解放ユティリティ（pdreclaimコマンド）で使用中空きページを解放できます。使用中空きページの解放については，マニュアル「HiRDB システム運用ガイド」を参照してください。

14.4　リスト用RDエリアの設計

14.4.1　リスト用RDエリアの必要数

1リスト用RDエリアに作成できるリストの最大数は，次に示すオペランドで指定します。

データベース初期設定ユティリティ（pdinit）のcreate rdarea文のmax entriesオペランド

データベース構成変更ユティリティ（pdmod）のcreate rdarea文のmax entriesオペランド

データベース構成変更ユティリティ（pdmod）のinitialize rdarea文のmax entriesオペランド

指定できる最大数は500〜50000です。

14.4.2　ページ長，セグメントサイズの求め方

リストにはリストの基表の行識別子が格納されます。表のように直接データを格納しないので，1ページ内に比較的大量の行を格納できます。したがって，ページ長及びセグメントサイズをリストに格納する行数に比べて大きく設定した場合，RDエリア内に余分な空き領域が発生するので注意してください。

リスト用RDエリアのページ長，セグメントサイズを決定する場合，あらかじめサーバ内に作成するリストの平均行数をおおよそ見積もり，次に示すどれかのケースに基づいてページ長及びセグメントサイズを設定してください。

条件 | ページ長 | セグメントサイズ
サーバ内に作成するリストの平均行数が3000行未満の場合 | 4096 | 1
サーバ内に作成するリストの平均行数が3000行〜6000行の場合 | 4096 | 2
サーバ内に作成するリストの平均行数が6000行を超える場合 | 「リストの平均行数が6000行を超える場合のページ長の求め方」参照 | 「リストの平均行数が6000行を超える場合のセグメントサイズの求め方」参照

(1)　リストの平均行数が6000行を超える場合のページ長の求め方

ページ長は，通常4096〜8192バイトの範囲にしてください。ただし，リストの入出力回数を減らしてリストの入出力時間を短縮したい場合は，ページ長を大きくしてもかまいません。ただし，ページ長を大きくすると，グローバルバッファの必要量も大きくなるため，共用メモリが大量に必要となるので注意してください。

なお，ページ長は次に示す計算式を満たす値にしてください。

計算式

リストの1ページに格納できる行数≦ サーバ内に作成するリストの平均行数÷2

リストの1ページに格納できる行数は，次に示す計算式から求めます。

リストの1ページに格納できる行数＝↓｛ページ長−70−（a×8）｝÷4↓

a：サーバ内のリストの基表を格納しているRDエリアのHiRDBファイルの総数

(2)　リストの平均行数が6000行を超える場合のセグメントサイズの求め方

セグメントサイズは1リストへのRDエリア内領域の割り当て単位です。したがって，1セグメントが1リストへの最低割り当てサイズとなります。セグメントサイズの目安を次に示します。

セグメント割り当てのオーバヘッドを削減したい場合，セグメントサイズを大きくしてください。

リスト用RDエリアのグローバルバッファにプリフェッチ機能を指定する場合は，セグメントサイズに2以上の値を指定してください。指定しないと，プリフェッチ機能が動作しないので注意してください。

セグメントサイズを大きくすると，セグメント内に余分な未使用ページが発生する可能性が高くなります。余分な未使用ページを減らしたい場合は，セグメントサイズを小さくしてください。

セグメントサイズは次に示す計算式を満たす値にしてください。

　　リストの1セグメントに格納できる行数

　　　　　　　　　　≦サーバ内に作成するリストの平均行数÷2

リストの1セグメントに格納できる行数は，次に示す計算式から求めます。

　　リストの1セグメントに格納できる行数

　　　　　　＝リストの1ページに格納できる行数×セグメントサイズ

14.4.3　セグメント数の求め方

リスト用RDエリアに必要なセグメント数は，次に示す計算式から求めます。

計算式

リスト用RDエリアに必要なセグメント数＝↑｛↑a÷b↑×（c＋0.5）｝↑

a：サーバ内のリストの数

b：サーバ内のリスト用RDエリアの数

c：1リストが使用するセグメント数の平均値

次に示す計算式から求めます。

↑サーバ内のリストの平均行数÷リストの1セグメントに格納できる行数↑

セグメント数が不足すると，リストが作成できなくなるため，実際には上記の計算式で見積もったセグメント数に余裕を持たせてください。

14.5　空き領域の再利用機能

空き領域の再利用機能を使用すると，データの削除でできる空き領域を有効活用できます。ここでは，次の項目について説明します。

データ格納時のサーチ方式

空き領域の再利用機能とは

効果と適用基準

使用前の考慮点

環境設定

実行状態の確認

注意事項

14.5.1　データ格納時のサーチ方式

表にデータを格納するとき，格納領域をサーチする方式には次の二つのページサーチモードがあります。

新規ページ追加モード

使用中セグメントの最終ページが満杯になると，新規に未使用セグメントを確保します。RDエリア中に未使用ページがなくなると，使用中ページの空き領域を使用中セグメントの先頭からサーチして空き領域にデータを格納します。

未使用セグメントがある状態のときは，格納効率は良くはなりませんが，高速に処理が行えます。ただし，未使用セグメントがなくなると性能が大きく低下します。

空きページ再利用モード

使用中セグメントの最終ページが満杯になると，未使用セグメントを確保する前に使用中セグメント内の使用中ページの空き領域をサーチします。また，次回サーチ開始位置を記憶し，次に空き領域をサーチするときそこからサーチを開始します。

未使用セグメントがある場合でも，空き領域をサーチしてデータを格納するため，格納効率は良くなりますが，その分オーバヘッドが掛かります。

14.5.2　空き領域の再利用機能とは

空き領域の再利用機能とは，表の使用中セグメントがユーザの指定したセグメント数に達し，そのセグメントが満杯になるとページサーチモードを空きページ再利用モードに切り替えて，使用中ページの空き領域を使用する機能です。指定した数のすべてのセグメントに空き領域がなくなると，新規ページ追加モードに切り替わり，新規に未使用セグメントを確保します。

セグメント数を指定しない場合は，RDエリア中に未使用ページがなくなったときに空きページ再利用モードに切り替わります。

RDエリア中に未使用ページがなくなった場合，空き領域の再利用機能による空きページ再利用モードの方が，この機能を使用しないときに比べて，サーチ効率が良くなります。空きページ再利用モードの場合は，次回サーチ位置を記憶していてそれ以降をサーチしますが，この機能を使用しない場合は，常に先頭からサーチします。

なお，空き領域の再利用機能を使用しない場合，常に新規ページ追加モードで動作します。この場合，未使用セグメントがなくなると，性能が大きく低下してしまうため，その前に表の再編成や，使用中空きページ及び使用中空きセグメントの解放などを行って，未使用セグメントを増やしてください。

空き領域の再利用機能の概要を次の図に示します。

図14‒4　空き領域の再利用機能の概要

[picture]

〔説明〕

空き領域の再利用機能を使用しない場合

RDエリア中に未使用ページがなくなると，その後データが挿入されるたびに使用中セグメントの先頭から使用中ページの空き領域をサーチして空き領域にデータを格納します。

空き領域の再利用機能を使用した場合（セグメント数指定あり）

指定したセグメント数に達した後で表にデータを挿入しようとすると，未使用セグメントを確保しないで，使用中ページの空き領域を使用中セグメントの先頭からサーチしてそこにデータを格納します。そこで次回サーチ開始位置を記憶しておき，次に空き領域をサーチするときはそこからサーチを開始します。

空き領域の再利用機能を使用した場合（セグメント数指定なし）

RDエリア中に未使用ページがなくなってからデータを挿入しようとすると，使用中ページの空き領域を使用中セグメントの先頭からサーチしてそこにデータを格納します。そこで次回サーチ開始位置を記憶しておき，次に空き領域をサーチするときはそこからサーチを開始します。

14.5.3　効果と適用基準

(1)　効果

この機能を使用すると，次の効果が期待できます。

空き領域の有効活用

使用中ページの空き領域を再利用するため，最小限のRDエリア容量で運用でき，データベースの再編成回数を減らせます。また，1RDエリアに複数の表及びインデクスを格納する場合に，ある表に対して集中して挿入及び削除処理が実行された場合の領域占有を回避できます。

可変長列及びBINARY型の列のページ不足エラーの回避

通常，ノースプリットオプションを指定しないで256バイト以上の可変長文字列を挿入したり，1ページに入らないBINARY型の列を挿入したりすると，未使用ページが確保されます。使用中空きページがあっても，未使用ページが確保できなければエラーになりますが，空き領域の再利用機能を使用すると使用中空きページを未使用ページの代わりに確保するのでページ不足エラーを回避できます。

(2)　適用基準

空き領域を再利用する処理はオーバヘッドが掛かるため，性能よりも格納効率を優先する場合に，空き領域の再利用機能を使用してください。

削除と挿入を繰り返すため，データ量に対してセグメントが大量に消費され，頻繁に再編成しなければならない業務で，再編成の回数をできるだけ減らしたい場合に空き領域の再利用機能を使用してください。この機能の使用をお勧めする場合の業務特性と効果を次に示します。

削除（更新），挿入を含み，データ量の増加がない場合

空き領域の再利用機能で格納データの最大サイズを指定しておけば，その後は削除されるデータの領域を優先して再利用するので，新規領域を追加しないで業務を継続でき，再編成が不要になります。

（例）行政電子窓口

電子窓口で受け付け業務を24時間するシステムで，申請受け付け時に申請データを挿入し，保管期限経過後に削除します。最大保管期限内に受け付ける申請データ数のセグメントサイズを指定すれば，削除されるデータの領域を再利用するので，新規領域を追加しないで業務を継続できます。そのため，再編成が不要となり，業務を停止することなく24時間サービスができます。

削除（更新），挿入を含み，データ量が徐々に増加する場合

徐々に増加するデータを新規領域だけでなく，削除した領域にも格納するため，格納効率が向上します。

（例）顧客管理

新規顧客のデータを挿入し，不要になった顧客登録データを削除します。初期顧客データ登録終了後，追加，削除業務開始前のセグメントサイズを指定すれば，その後は削除された顧客データの領域を再利用しながら追加されます。

挿入処理は新規に未使用ページや未使用セグメントにデータを格納する方が性能が良くなります。そのため，短い周期でデータベース再編成ユティリティ（pdrorg）を実行できる場合は，空き領域の再利用機能を適用しないでデータベースを再編成する方が性能が良くなります。

14.5.4　使用前の考慮点

空き領域の再利用機能が有効になるのは，削除処理によって空き領域が十分にできる場合です。空き領域が十分にないときや全くないときに空き領域のサーチをするなど，むだに空き領域サーチをする場合，セグメント内のページ数の指定を大きくしたり，この機能を中止する必要があります。セグメント内のページ数指定を変更するためには，RDエリアを再作成（削除又は追加）する必要があるため，最初の設計時に指定するセグメント数，セグメントサイズは十分に考慮してください。

次の場合，SEGMENT REUSEオプションでセグメント数は省略してかまいません。

RDエリア内に表が一つで，インデクス混在なし，自動増分指定なし

次の場合，SEGMENT REUSEオプションでセグメント数を指定する必要があります。

・RDエリア内に表が一つで，インデクスは混在なし，自動増分指定あり

・RDエリア内に表が一つで，インデクスは混在あり

・RDエリア内に表が複数あり

データ件数が増加する場合，セグメント数を指定し，1セグメントが満杯になるまでに十分削除がされるようなセグメントサイズにしてください。データ件数が増加しない場合，表が使用する総セグメント数を見積もって，セグメント数を指定すればセグメントサイズは考慮不要です。ただし，同一RDエリア内の表で，再利用するセグメント数の合計（インデクスが混在している場合，同一RDエリア内の表で再利用するセグメント数とインデクスの見積もりセグメント数の合計）はRDエリアの総セグメント数以下にしてください。

なお，自動増分指定された表に空き領域の再利用機能が使用された場合，領域の増分を優先し，増分した領域が指定されたセグメント数になると，空き領域の再利用を実行します。

空き領域の再利用機能が有効になると，使用中セグメント内の空き領域をサーチするため，次の機能の効果が低下します。

クラスタ表でクラスタキー順にデータを格納する

UPDATE文の実行で行長が長くなる場合に，元のデータの近くにデータを格納する（CREATE TABLE文のPCTFREE指定，データロード時又は表の再編成時のtblfree指定）

そのため，空き領域の再利用機能を適用する場合は，これらの機能の使用を推奨しません。

14.5.5　環境設定

空き領域の再利用機能を使用するための環境設定について次に示します。

pd_assurance_table_noオペランドに空き領域の再利用機能を使用するユーザ表の表数を指定します。

分割表の場合は1分割を1表として計算します。HiRDB/パラレルサーバの場合，バックエンドサーバごとに計算し，その最大数をこのオペランドに登録します。

なお，CREATE TABLEで定義又はALTER TABLEで定義変更した表は，pd_assurance_table_noオペランドの指定数（予約数）まで空き領域の再利用機能を使用できます。予約数を超えた表に挿入が実行された場合，KFPH22030-Wメッセージが出力され，空き領域の再利用機能は適用されません。この場合，pd_assurance_table_noオペランドの指定値を増やすと定義したすべての表に空き領域の再利用機能が適用されます。ALTER TABLEのADD RDAREA指定で表格納RDエリアを追加して定義数が予約数を超えた場合や，HiRDB/パラレルサーバで定義数が予約数を超えた場合は，空き領域の再利用を定義した分割表でRDエリアごとに空き領域の再利用が適用されたり，されなかったりする場合があります。

空き領域を再利用するセグメント数を見積もり（表の総データ数から総セグメント数を見積もります。「ユーザ用RDエリアの容量の見積もり」を参照してください），見積もったセグメント数を定義系SQLのCREATE TABLEのSEGMENT REUSEオプションで指定します。作成済みの表に対してはALTER TABLEのSEGMENT REUSEオプションで指定します。ここで指定したセグメント数はすべてのRDエリアに適用されます。

また，さらに格納効率を向上させたい場合は，SEGMENT REUSEのOPTIONで再利用オプション値を指定します。再利用オプション値を指定すると，次の機能が使えるようになります。

各機能の再利用オプション値 | 機能 | 格納効率の向上が期待できるケース

1

UPDATE対応

固定長データ，ADT列のNULL値からのUPDATEがある

BINARY列のUPDATEがある

VARCHAR列，NVARCHAR列，MVARCHAR列（NO SPLIT指定）のUPDATEがある

確保済みセグメント数に比べてサーチモードの切り替え回数が少ない（pddbstコマンドで確認できます）

2 | 分岐行が多発する表の格納効率向上 | 分岐行を作成する表を運用するケース

3

UPDATE対応及び分岐行が多発する表の格納効率向上

固定長データ，ADT列のNULL値からのUPDATEがある

BINARY列のUPDATEがある

VARCHAR列，NVARCHAR列，MVARCHAR列（NO SPLIT指定）のUPDATEがある

確保済みセグメント数に比べてサーチモードの切り替え回数が少ない（pddbstコマンドで確認できます）

分岐行を作成する表を運用するケース

なお，OPTION 1（UPDATE対応）を適用すると，UPDATE時のページ確保を，新規ページ追加モード時は最終セグメントから，空きページ再利用モード時は前回記憶したサーチ開始位置のあるセグメントから行います。このとき，データロードや表の再編成で作成する空き領域を優先的に利用することがなくなります。そのため，OPTION 1を指定する表はCREATE TABLE文のPCTFREEに（0，0）を指定することを推奨します。

一度定義したセグメント数を変更する場合，ALTER TABLEのSEGMENT REUSEオプションで再度セグメント数を指定します。ページサーチモードとセグメント数の指定値によって，HiRDBは次のように処理します。

新規ページ追加モード時

指定されたセグメント数が使用中セグメント数より少ない場合，最後に確保したセグメント内に空き領域がなくなった後で空き領域の再利用を実行します。

空きページ再利用モード時

使用中セグメント数以下のセグメント数が指定された場合，そのまま続行します。使用中セグメント数より多いセグメント数が指定された場合，空き領域をすべて使用した後で空き領域の再利用をいったん中止し，新規に未使用セグメントを確保します。

バッチ処理などで一時的に大量追加をする場合など，空き領域の再利用機能を一時中止したい場合，ALTER TABLEでSEGMENT REUSE NOを指定します。実行するとすぐに空き領域の再利用機能は中止され，新規に未使用セグメントが確保されます。

空き領域の再利用機能を使用している表がセグメント確保時に出力する，RDエリアのセグメント使用率通知メッセージ（KFPH00211-I，又はKFPA12300-I）を抑止したい場合，pd_rdarea_warning_point_msgoutオペランドにNを指定します。

削除（更新），挿入を含み，かつデータ量の増加がない場合，空き領域の再利用機能を使用すると，表の再編成やRDエリアの拡張をする必要がなくなります。そのため，ユーザはRDエリアのセグメント使用率通知メッセージの出力を監視する必要もなくなります。削除（更新），挿入を含み，データ量の増加がなく，かつ次のすべての条件に該当するときは，RDエリアのセグメント使用率通知メッセージの出力を抑止できます。

格納RDエリアに，空き領域の再利用機能を使用している表だけを定義している。

FIX属性の表である，又は可変長の列を含まない表である（データ長が長くなるような更新をしない）。

ただし，次に示す場合は空き領域の再利用機能が動作しないおそれがあるため，RDエリアのセグメント使用率通知メッセージを出力し，監視を行ってください。RDエリアの使用状況に応じてユーザが対処する必要があります。

空き領域の再利用機能を定義している表数が，pd_assurance_table_noオペランドで指定した予約数より多い。

格納RDエリアに対して空き領域の再利用機能を使用している表を複数定義していて，表定義のSEGMENT REUSEのセグメント数に，最大データ量サイズ以上を指定していない。

14.5.6　実行状態の確認

空き領域の再利用機能が有効かどうかを，データベース状態解析ユティリティ，統計解析ユティリティ，及びUAP統計レポート機能で表示される項目から確認できます。また，空回りした場合，表（分割表の場合は分割RDエリア）ごとの一回目にメッセージログにKFPH22031-Wが出力されます。表示される項目とその説明を次に示します。

項目 | 説明 | 対処
ページサーチモードの切り替え回数 | 新規ページ追加モードから空きページ再利用モードへ，又は空きページ再利用モードから新規ページ追加モードへのサーチモード切り替え回数です。再利用と未使用セグメントの確保が頻繁に切り替わっているということは，削除でできる空き領域より追加する領域が大きく，セグメントサイズ（ページ数）が小さいということになります。 | セグメントサイズ変更や削除実行のタイミングを見直してください。
空き領域の再利用機能のページサーチ空回り回数 | 使用中セグメント数が指定されたセグメント数になり，空きページ再利用モードに切り替わってサーチしても，空き領域がない場合です。このようなとき，空回り回数がカウントアップされます。空き領域がないのにサーチしているため，むだにサーチ処理をしていることになります。 また，空き領域の再利用のページサーチ空回り回数とページサーチモードの切り替え回数が共に増加している場合は，全く空き領域がない状態で空き領域の再利用が実行されていることになります。 | 指定するセグメント数やセグメントサイズの見直し，又は空き領域の再利用機能の使用中止を検討してください。
使用中セグメント数 | 表が使用しているセグメントに空き領域がなくなると未使用セグメントが確保されるため，表の使用中セグメント数が増加します。空き領域の再利用のページサーチ空回り回数と同じ数だけ増加している場合，空き領域がないのに再利用しようとしてむだにサーチ処理をしていることになります。 | −

（凡例）−：該当しません。

14.5.7　注意事項

次の場合，空き領域の再利用機能は動作しません。

ハッシュ分割表のリバランス機能でデータを格納するとき

データロードやデータベース再編成ユティリティ（pdrorg）で表にデータを格納するとき

ユーザLOB用RDエリアのとき

空き領域の再利用機能使用時，削除による空き領域が連続しない場合，連続している場合と比較するとページのサーチ処理は遅くなります。この場合，空き領域の再利用機能使用の中止や，データベース再編成ユティリティ（pdrorg）によるデータの再編成を検討してください。

非FIX表の場合，空き領域の再利用機能を適用していても，セグメント数が増加することがあります。セグメント数の増加は，次のような更新を行うと，データの追加と削除が同量でも発生することがあります。

↓（ページ長−48）÷（行長＋2）↓件のデータを挿入し，行長が短くなるデータ（NULL値含む）又は別のページに分岐するようなデータに更新した後，削除する操作を繰り返す場合

この場合，空きページ解放ユティリティ（pdreclaim）で解放できる満杯ページが発生し，そのページにはデータが格納できなくなります。そのようなページが発生しているかどうかは，データベース状態解析ユティリティ（pddbst）の「Collect Prearranged Full Page」の値で確認できます。

この満杯ページは，次のどちらかを実行して解放してください。

空きページ解放ユティリティ（pdreclaim）

データベース再編成ユティリティ（pdrorg）

空きページ再利用モードでサーチ実行時でも，同一トランザクションで削除された領域は再利用されません。

空き領域の再利用機能を適用していても，非NULL値からNULL値へのUPDATEを繰り返すと，実際のデータの容量以上のセグメント数を確保する場合があります。この現象を回避するには，NULL値へのUPDATEではなくDELETEを使用するような設計及び運用をしてください。

14.6　共用RDエリア（HiRDB/パラレルサーバ限定）

14.6.1　共用RDエリアの概要

通常，バックエンドサーバがアクセスできるのは，バックエンドサーバ下のRDエリアだけです。そのため，表の検索や更新時はできるだけ表を分割して格納した方が並列処理ができ，処理速度が向上します。しかし，複数のトランザクションからアクセスが集中し，かつ分割が難しい表などの場合，共用RDエリアに格納することで並列処理の効率が上がります。共用RDエリアとは，すべてのバックエンドサーバからアクセスできるユーザ用RDエリアのことです。共用RDエリアに格納する表を共用表，インデクスを共用インデクスといい，すべてのバックエンドサーバから参照できます。共用RDエリアに格納できるのは，共用表及び共用インデクスだけです。共用RDエリアの概要を次の図に示します。

なお，共用RDエリアを定義できるのはHiRDB/パラレルサーバだけです。

図14‒5　共用RDエリアの概要

[picture]

〔説明〕

共用RDエリアRDSHR01は，BES1〜3すべてのバックエンドサーバから参照できます。ただし，共用表の更新ができるのは更新可能バックエンドサーバ（BES3）だけです。BES1及び2は参照専用バックエンドサーバです。

(1)　効果

全バックエンドサーバが共用RDエリアにアクセスできるため，並列処理の効率が上がります。

(2)　適用基準

次の場合に共用RDエリアの使用をお勧めします。

複数のトランザクションからアクセスが集中するが，分割が難しい表の場合

結合処理のような複雑な検索処理をする場合

(3)　定義方法

共用RDエリアを使用するには，次のように指定します。

pd_shared_rdarea_useオペランドにYを指定します。

pdfmkfsコマンドの-kオプション（使用目的）にSDBを指定します。また，全バックエンドサーバから同じパス名でアクセスできるようにアクセスパスを設定します。

データベース初期設定ユティリティ（pdinit），又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文にsharedを指定し，ユーザ用RDエリアの定義をします。また，更新可能バックエンドサーバをserver nameオペランドに指定します。server nameオペランドに指定しなかったバックエンドサーバはすべて参照専用バックエンドサーバになります。

定義時の注意

共用RDエリアは，pd_max_rdarea_noオペランドで指定したRDエリアの最大数まで定義できます。ただし，共用RDエリアは全バックエンドサーバのRDエリアの数に加算されます。

異なるバックエンドサーバが更新可能バックエンドサーバである共用RDエリアを，同一HiRDBファイルシステム領域に定義してはいけません。

共用RDエリアは，共用RDエリア用のHiRDBファイルシステム領域に定義します。pdfmkfs -kコマンドにSDBを指定してください。なお，共用RDエリア用のHiRDBファイルシステム領域には共用RDエリア以外は定義できません。

図「共用RDエリアの概要」の場合の，データベース構成変更ユティリティ（pdmod）の制御文の例を次に示します。

create shared rdarea RDSHR01 globalbuffer buf01 for user used by PUBLIC
  server name BES3   …更新可能バックエンドサーバの指定
  open attribute INITIAL
  page 4096 characters
  storage control segment 20 pages
  file name "¥HiRDB¥DATABASE¥SHR1¥rdshr01_f01"   …ファイル名
          initial 10000 segments ;

(4)　共用RDエリアの更新

共用RDエリアを更新する場合，LOCK文でIN EXCLUSIVE MODEを指定し，全バックエンドサーバの共用RDエリアに排他を掛けなければ実行できません。ただし，インデクスキー値を変更しないUPDATE文は，LOCK文を発行しないで実行できます。共用表の更新については，「共用表の操作」を参照してください。なお，共用表及び共用インデクスの更新はCOMMIT文発行時にディスクに書き込まれます。

(5)　共用RDエリアの閉塞状態の管理

共用RDエリアへのアクセスは，各バックエンドサーバで個別に管理されます。このため，障害発生時に，バックエンドサーバ間で閉塞状態が異なる場合があります。データベース構成変更ユティリティ（pdmod）や，データベース回復ユティリティ（pdrstr）を実行する場合は，pdholdコマンドで全バックエンドサーバ下の共用RDエリアの閉塞状態を一致させる必要があります。なお，pddbls -mコマンドで全バックエンドサーバの共用RDエリアの状態を表示できます。

(6)　共用RDエリアに対するユティリティ及び運用コマンドの実行

ユティリティ及び運用コマンドで共用RDエリア，共用表，又は共用インデクスを対象とする場合，HiRDBが内部的にLOCK TABLE文を発行し，全バックエンドサーバ下の共用RDエリアに排他を掛けることがあります。このため，共用RDエリア内の表やインデクスにアクセス中の業務があると，デッドロック，又はサーバ間のグローバルデッドロックが発生することがあります。ユティリティ及び運用コマンド実行時は，対象となる共用RDエリアをコマンド閉塞しておいてください。

(7)　共用RDエリア使用上の制限事項

系切り替え機能を使用する場合，更新可能バックエンドサーバがあるユニットは次のように配置してください。

参照専用バックエンドサーバと異なるホストに配置

系を切り替えたときに同一ホスト内で参照バックエンドサーバと混在しないように切り替え先を配置

参照専用バックエンドサーバは，共用RDエリアのディスクボリュームをクラスタソフトウェアの管理リソースにしないようにしてください。

共用RDエリアは全バックエンドサーバに配置されるため，フロータブルサーバは設置できません。

レプリケーションの反映先に共用表は指定できません。

ローカルバッファで共用RDエリアの表やインデクスを更新する場合は，LOCK TABLE文を発行して更新してください。LOCK TABLE文を発行しないで更新していると，サーバプロセスが異常終了してトランザクション回復プロセスが回復処理するとき，グローバルバッファで回復対象になる更新ページを保持できないことがあります。更新ページを保持できないと回復できないので，アボートコードPhb3008を出力してユニットは異常終了します。この場合，HiRDBを再開始してください。

14.7　一時表用RDエリア

14.7.1　一時表用RDエリアの概要

一時表用RDエリアは，一時表や一時インデクスを格納するユーザ用RDエリアです。

(1)　適用基準

一時表を使用する場合に必要です。

(2)　一時表用RDエリアの属性

一時表用RDエリアには，次の二つがあります。

SQLセッション間共有属性の一時表用RDエリア

すべてのSQLセッションで使用できる一時表用RDエリアです。SQLセッション間で共有させることで一時表用RDエリアの個数を少なくする場合に使用します。

特定SQLセッション占有属性の一時表用RDエリア

特定のSQLセッション（クライアント環境定義PDTMPTBLRDAREAに使用する一時表用RDエリアを指定しているSQLセッション）だけが使用する一時表用RDエリアです。特定のユーザが膨大なデータを扱い，ほかのユーザが使用する一時表用RDエリアを圧迫する場合，それを避けるときに使用します。

(3)　作成方法

一時表用RDエリアの作成方法を次に示します。

pd_max_temporary_object_noオペランドに，ある一時点で使用する一時表と一時インデクスの最大数を指定します。0904互換モードを適用している場合，pd_max_temporary_object_noオペランドの指定に加えて，pd_max_tmp_table_rdarea_noオペランドに一時表用RDエリアの最大数を指定します。

pdfmkfsコマンドの-kオプション（使用目的）にDBを指定し，HiRDBファイルシステム領域を作成します。

データベース初期設定ユティリティ（pdinit），又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文に次の二つのオペランドを指定して，ユーザ用RDエリアを作成します。

for user used by PUBLICを指定します。

一時表用RDエリアとして使用するには，公用RDエリアである必要があります。

temporary table useを指定します。

SQLセッション間共有属性の場合はtemporary table use sharedを，特定SQLセッション占有属性の場合はtemporary table use occupiedを指定します。

作成時の注意

0904互換モードを適用している場合，pd_max_tmp_table_rdarea_noオペランドの指定値は，pd_max_rdarea_noオペランドの指定値より小さい値にしてください。一時表用RDエリアを追加する場合は，追加する一時表用RDエリアも含めて，pd_max_rdarea_noオペランドで指定するRDエリアの最大数を超えないようにしてください。超える場合，pd_max_rdarea_noオペランドの指定値を変更してください。

使用できる一時表用RDエリアが複数ある場合，使用する一時表用RDエリアはHiRDBが自動的に決定します。そのため，一つのUAPが使用できる一時表用RDエリアは，RDエリアの容量，セグメントサイズ，及びページサイズを同じにすることをお勧めします。

RDエリアの容量，セグメントサイズ，及びページサイズを統一していないと，次の現象が発生します。

・一時表への，初回のINSERT文の実行によって実体化するごとに，ページサイズが異なるRDエリアを格納先として決定する可能性があります。この場合，同じ挿入データであっても，挿入データの行長と格納先RDエリアのページサイズの大小関係によって，初回のINSERT文の実行可否が変わります。

・格納先RDエリアは空きセグメント数が多いRDエリアを優先的に選択しますが，格納先RDエリアの候補となるRDエリアのページサイズやセグメントサイズが異なると，空き容量の小さいRDエリアを格納先RDエリアとして選択することがあります。

一時表用RDエリアはHiRDB開始時，又は一時表への最初のINSERT文実行時に初期化されるため，容量が大き過ぎると初期化のオーバヘッドが大きくなります。一時表用RDエリアの初期化については，「一時表用RDエリアの初期化」を参照してください。

作成例

HiRDB/パラレルサーバのBES1に，SQLセッション間共有属性の一時表用RDエリア（RDTMP01）を作成する場合のデータベース構成変更ユティリティ（pdmod）の制御文の例を次に示します。

create rdarea RDTMP01   …一時表用RDエリア名を指定
  globalbuffer tmpbuf01
  for user used by PUBLIC   …公用RDエリアの指定
  server name BES1
  open attribute INITIAL
  page 4096 characters
  storage control segment 100 pages
  temporary table use shared   …SQLセッション間共有属性を指定
  file name “¥hirdb¥db¥rdtmp01_f01”
    initial 500 segments ;

(4)　一時表用RDエリアの初期化

HiRDB開始時に，開始モードに関係なく，HiRDBは前回稼働時に使用した一時表用RDエリアを初期化します。そのため，初期化する一時表用RDエリアの容量が多いと，HiRDBの開始に時間が掛かります。高速系切り替え機能やスタンバイレス型系切り替え機能を使用していて，系切り替え時間を短縮する必要がある場合，pd_tmp_table_initialize_timingオペランドにACCESSを指定することで，HiRDB開始時に一時表用RDエリアの初期化をしないようにできます。ただし，ACCESSを指定すると，一時表に最初にINSERT文が実行された時点で一時表用RDエリアを初期化するため，初期化する容量が多いと，INSERT実行のオーバヘッドが大きくなります。オーバヘッドを小さくするには，一時表用RDエリアの容量を小さくしてください。

pd_tmp_table_initialize_timingオペランド，及び一時表用RDエリアの初期化によるオーバヘッド量の見積もりについては，マニュアル「HiRDB システム定義」を参照してください。

(5)　一時表用RDエリアのバックアップ

一時表のデータは，トランザクション又はSQLセッションの期間中だけ保持するデータのため，一時表用RDエリアのバックアップは取得不要です。一時表用RDエリアに障害が発生した場合は，データベース構成変更ユティリティ（pdmod）のinitialize rdarea文でRDエリアを再初期化してください。

(6)　一時表用RDエリア使用上の留意事項

(a)　制限事項

一時表用RDエリアに対して，次に示す運用コマンド又はユティリティを実行する場合，一部制限があります。詳細は，マニュアル「HiRDB コマンドリファレンス」を参照してください。

pdholdコマンド

pdrdreflsコマンド

データベース複写ユティリティ（pdcopy）

データベース状態解析ユティリティ（pddbst）

データベース構成変更ユティリティ（pdmod）

RDエリアの移動はできません。

データベース回復ユティリティ（pdrstr）

(b)　特定SQLセッション占有属性の一時表用RDエリアを使用する場合

特定SQLセッション占有属性の一時表用RDエリアを使用するSQLセッションは，クライアント環境定義PDTMPTBLRDAREAに該当する一時表用RDエリアを指定しているSQLセッションだけです。該当する一時表用RDエリアを，さらに占有する（ほかのSQLセッションで使用できないようにする）には，ローカルバッファを割り当ててください。これによって，該当する一時表用RDエリアに排他モード（EX）の排他が掛かります。

(c)　非FIXの一時表を作成する場合

非FIXの一時表を作成する場合，一時表用RDエリアは次のどちらかの条件を満たしている必要があります。条件を満たしていない場合，データを格納するときにKFPA11809-Iメッセージが出力されることがあります。

クライアント環境定義のPDTMPTBLRDAREAを指定している場合

PDTMPTBLRDAREAに指定しているすべての一時表用RDエリアの定義に，同じページ長※を定義している。

クライアント環境変数のPDTMPTBLRDAREAを指定していない場合

すべてのSQLセッション間共有属性の一時表用RDエリアの定義に，同じページ長※を定義している。

注※

ページ長は，基本行長より大きい値となります。基本行長については，マニュアル「HiRDB SQLリファレンス」の「既定義型データ長一覧」のデータ長の計算式を基に算出してください。KFPA11809-Iメッセージが出力された場合は，KFPA11809-Iメッセージの「格納しようとした行長」より大きい値を指定してください。

(d)　HiRDB Datareplicatorと連携する場合

一時表に対する更新は抽出対象外になります。そのため，HiRDB Datareplicatorを使用する場合，一時表について考慮する点は特にありません。

15　HiRDBのメモリ所要量

この章では，HiRDB/シングルサーバ及びHiRDB/パラレルサーバのメモリ所要量の求め方について説明します。

15.1　HiRDB/シングルサーバのメモリ所要量の見積もり

ここでは，HiRDB/シングルサーバのメモリ所要量の見積もり方法について説明します。ここで説明する項目を次に示します。

メモリ配置

メモリ所要量の計算式

ユニットコントローラが使用する共用メモリの計算式

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

グローバルバッファが使用する共用メモリの計算式

SQL実行時に必要なメモリ所要量の計算式

SQL前処理時に必要なメモリ所要量の計算式

BLOB型データの検索又は更新時に必要なメモリ所要量の計算式

ブロック転送又は配列FETCHで必要なメモリ所要量の計算式

15.1.1　メモリ配置

HiRDB/シングルサーバのメモリ配置を次の図に示します。

図15‒1　HiRDB/シングルサーバのメモリ配置

[picture]

HiRDB/シングルサーバの共用メモリの詳細を次の表に示します。

表15‒1　HiRDB/シングルサーバの共用メモリの詳細

項目 | 共用メモリの種類
ユニットコントローラ用共用メモリ | グローバルバッファ用共用メモリ | ユティリティ用共用メモリ | セキュリティ監査情報用バッファ用共用メモリ | プロセス間メモリ通信用共用メモリ | トラブルシュート情報取得用共用メモリ
使用目的 | システム制御 | グローバルバッファ | ユニットコントローラとユティリティとの通信 | セキュリティ監査情報用バッファ | クライアント—サーバプロセス間メモリ通信 | トラブルシュート情報取得
使用プロセス | 全HiRDBプロセス | シングルサーバ | ユティリティプロセス | シングルサーバ | シングルサーバ，クライアントプロセス | 全HiRDBプロセス

セグメント数

1個

グローバルバッファの動的変更機能を使用しない場合

1〜512個

グローバルバッファの動的変更機能を使用している場合

32ビットモード：1〜1,012個

64ビットモード：1〜1,512個

1個

1個

環境変数PDIPC=MEMORYで接続中のクライアント数（0〜2000）×2個

1個

1セグメントの上限 | 表「HiRDB/シングルサーバが使用するメモリ所要量」を参照してください。ただし，OSの環境によっては確保できない場合があります。 | SHMMAXオペランドの値でセグメントを分割します。ただし，OSの環境によっては確保できない場合があります。 | 表「HiRDB/シングルサーバが使用するメモリ所要量」を参照してください。 | 表「HiRDB/シングルサーバが使用するメモリ所要量」を参照してください。ただし，OSの環境によっては確保できない場合があります。 | 表「HiRDB/シングルサーバが使用するメモリ所要量」を参照してください。ただし，OSの環境によっては確保できない場合があります。 | 10メガバイト
確保条件 | なし | グローバルバッファ定義が存在すること | pd_utl_exec_mode=1指定 | pd_aud_file_nameオペランドによる監査証跡ファイル用のHiRDBファイルシステム領域名の指定 | クライアント環境変数PDIPC=MEMORYで接続中クライアントあり | なし
作成契機 | ユニット起動時（ユーザサーバホットスタンバイ又は高速系切り替え機能使用時の待機ユニットの起動を含む） | サーバ起動時（高速系切り替え機能使用時の待機ユニットの起動を含む） pdbufmod -k {add｜upd}実行時 | ユティリティ実行時 | シングルサーバ起動時 | クライアントとサーバの接続時 | ユニット起動時（ユーザサーバホットスタンバイ又は高速系切り替え機能使用時の待機ユニットの起動を含む）
削除契機 | 次回ユニット起動時（ユーザサーバホットスタンバイ又は高速系切り替え機能使用時の待機ユニットの起動を含む） | pdbufmod -k del実行時 正常終了又は計画停止の場合：サーバ終了時 強制停止，異常終了，又は高速系切り替え機能使用時の待機ユニットの停止の場合：次回ユニット起動時 | ユティリティ終了後10分後 | シングルサーバ終了時 | クライアントとサーバの接続切り離し時 | ユニット停止時
pdls -d memによる表示 | 表示される | 表示される | 表示される | 表示される | 表示されない | 表示されない
pdls -d memのSHM-OWNER | MANAGER | サーバ名 | UTILITY | AUDDEF | 表示なし | 表示なし
関連オペランド | pd_sds_shmpool_size | pd_dbbuff_modify pdbuffer SHMMAX | pd_utl_exec_mode | セキュリティ監査機能に関するオペランド※ | PDIPC PDSENDMEMSIZE PDRECVMEMSIZE | pd_prf_trace
備考 | − | − | pd_utl_exec_mode=1の場合だけ作成されます（pd_utl_exec_mode=0の場合，該当する領域はユニットコントローラ用共用メモリ内に確保されます）。 | − | − | −

（凡例）−：該当しません。

注※

詳細はマニュアル「HiRDB システム定義」を参照してください。

15.1.2　メモリ所要量の計算式

HiRDB/シングルサーバが使用するメモリ所要量は，次の表に示すすべての項目を加算した値です。

共用メモリサイズが増加すると，ページフォルトの発生回数が増加し，トランザクション性能に影響を与えるおそれがあります。各オペランドの指定値の目安を参照し，システムに合わせて適切な値を指定することを検討してください。

表15‒2　HiRDB/シングルサーバが使用するメモリ所要量

項目 | メモリ所要量（単位：キロバイト）

プロセス固有領域

ユニットコントローラ全プロセスが使用するプロセス固有領域

●32ビットモードの場合

E＋↑｛（64＋48×（u＋1））×（pd_max_server_processの値−b−6）＋（64＋48×（y＋1））×3＋w｝÷1024↑

●64ビットモードの場合

E＋↑｛（64＋64×（u＋1））×（pd_max_server_processの値−b−6）＋（64＋64×（y＋1））×3＋w｝÷1024↑

●プラグインを使用する場合，加算します。

＋1400

●pd_max_ard_processオペランドが1以上の場合，加算します。

＋r

●pd_process_terminatorオペランドにfixedを指定した場合，加算します。

＋F×（pd_process_terminator_maxの値−1）

●インメモリデータ処理を行う場合，加算します。

＋↑｛K×（pd_max_usersの値×2＋7）｝÷1024↑

●通信トレース格納最大数を変更する場合，加算します。

＋↑M÷1024↑

●通信暗号化機能を適用する場合，加算します。

＋T＋U×クライアント同時接続発生数※5

シングルサーバプロセスが使用するプロセス固有領域※１

pd_work_buff_mode=

each指定時

●32ビットモードの場合

｛G＋g＋（a＋9）×c＋h＋i＋m＋p＋q＋s｝×（b＋3）＋↑（64＋48×（v＋1））÷1024↑×（b＋3）＋J

●64ビットモードの場合

｛G＋g＋（a＋9）×c＋h＋i＋m＋p＋q＋s｝×（b＋3）＋↑（64＋64×（v＋1））÷1024↑×（b＋3）＋J

●インメモリデータ処理を行う場合，加算します。

＋↑｛K×（b＋3）｝÷1024↑

●通信トレース格納最大数を変更する場合，加算します。

＋↑P÷1024↑

●通信暗号化機能を適用する場合，加算します。

＋V×(b＋3)

pd_work_buff_mode=

pool指定又は省略時

●32ビットモードの場合

（G＋g＋a＋↑a÷128×0.1↑＋11＋h＋i＋m＋n＋p＋q＋s）×（b＋3）＋↑（64＋48×（v＋1））÷1024↑×（b＋3）＋J

●64ビットモードの場合

（G＋g＋a＋↑a÷128×0.1↑＋15＋h＋i＋m＋n＋p＋q＋s）×（b＋3）＋↑（64＋64×（v＋1））÷1024↑×（b＋3）＋J

●インメモリデータ処理を行う場合，加算します。

＋↑｛K×（b＋3）｝÷1024↑

●通信トレース格納最大数を変更する場合，加算します。

＋↑P÷1024↑

●通信暗号化機能を適用する場合，加算します。

＋V×(b＋3)

pd_work_buff_mode=pool2指定

●32ビットモードの場合

（G＋g＋↑a÷128×0.1↑＋11＋h＋i＋m＋n＋p＋q＋s）×（b＋3）＋↑（64＋48×（v＋1））÷1024↑×（b＋3）＋J＋(a×S)

●64ビットモードの場合

（G＋g＋↑a÷128×0.1↑＋15＋h＋i＋m＋n＋p＋q＋s）×（b＋3）＋↑（64＋64×（v＋1））÷1024↑×（b＋3）＋J＋(a×S)

●インメモリデータ処理を行う場合，加算します。

＋↑｛K×（b＋3）｝÷1024↑

●通信トレース格納最大数を変更する場合，加算します。

＋↑P÷1024↑

●通信暗号化機能を適用する場合，加算します。

＋V×(b＋3)

共用メモリ | ユニットコントローラ用共用メモリ中，ユニットコントローラが使用する領域 | ↑d÷1024↑
ユニットコントローラ用共用メモリ中，シングルサーバが使用する領域 | e
グローバルバッファ用共用メモリ | f
インメモリデータ処理用共用メモリ | L
ユティリティ用共用メモリ | t

セキュリティ監査情報用バッファ用共用メモリ

●システムによる自動計算の場合

↑0.3＋MAX｛（H＋100），（H×1.2）｝×0.25↑

●ユーザ指定値（pd_audit_def_buffer_sizeオペランドを指定）にする場合

pd_audit_def_buffer_sizeの指定値

プロセス間メモリ通信用共用メモリ※２ | j×k

OSの領域※３

PTEの領域※４

●共用メモリのページ固定をしていない場合

（↑プロセス固有領域の合計サイズ÷510↑＋pd_max_server_processの値×16＋13）＋｛（↑共用メモリの合計サイズ÷510↑＋17）×pd_max_server_processの値｝

●共用メモリのページ固定をしている場合

（↑プロセス固有領域の合計サイズ÷510↑＋pd_max_server_processの値×16＋13）＋｛（↑共用メモリの合計サイズ÷261120↑＋13）×pd_max_server_processの値｝

注※１

プラグインを使用する場合は，1シングルサーバプロセス当たり300を加算してください。

注※２

クライアント環境定義でPDIPC=MEMORYを指定した場合に加算します。プロセス間メモリ通信機能及びクライアント環境定義については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

なお，HiRDBサーバ又はHiRDBクライアントのどちらかが32ビットモードの場合，プロセス間メモリ通信機能で使用する共用メモリは32ビット空間内に確保されます。

注※３

OSが使用する領域の詳細は公開されていないため，あくまでHiRDBが確保するメモリ所要量を基にした目安です。実際の値とは大きく異なる場合があるので，正確な値については実際の環境で測定してください。

注※４

PTEについては，「システム設計」を参照してください。

注※５

HiRDBに対してクライアントが接続を同時に要求する最大数です。

例えば，ある時刻に10個のクライアントを起動し，そのあとの時刻にさらに5個のクライアントを起動する場合，同時に要求する最大数は10となります。

ａ：pd_work_buff_sizeオペランドの値

ｂ：pd_max_usersオペランドの値

ｃ：最大作業表数

SQL文ごとの作業表数を表「SQL文ごとの作業表数の求め方」から求めます。表「SQL文ごとの作業表数の求め方」から求めた作業表数のうちで最大のものを最大作業表数とします。

ｄ：「ユニットコントローラが使用する共用メモリの計算式」で求めた値

ｅ：「シングルサーバが使用する共用メモリの計算式」で求めた値

ｆ：「グローバルバッファが使用する共用メモリの計算式」で求めた値

ｇ：SQL実行時に必要なメモリ所要量

計算式については，「SQL実行時に必要なメモリ所要量の計算式」を参照してください。

ｈ：SQL前処理時に必要なメモリ所要量

計算式については，「SQL前処理時に必要なメモリ所要量の計算式」を参照してください。

ｉ：LOBバッファ一括入出力ワークメモリ

グローバルバッファ定義にLOB用グローバルバッファを指定している場合だけ（システム共通定義のpdbufferオペランドに-bを指定している場合），62キロバイトを加算してください。

ｊ：プロセス間メモリ通信機能を使用するクライアントの最大同時実行数

分からない場合は，プロセス間メモリ通信機能を使用する全クライアント数，又はpd_max_usersオペランドの値を代入してください。

ｋ：プロセス間メモリ通信機能を使用する全クライアントのデータ送受信用メモリサイズ（クライアント環境定義のPDSENDMEMSIZEの値＋PDRECVMEMSIZEの値）の平均値

ｍ：Java仮想マシンが使用するメモリ所要量

Javaストアドプロシジャ又はJavaストアドファンクションを使用する場合に，Java仮想マシンが使用するメモリ所要量を加算します。Java仮想マシンが使用するメモリ所要量は，Java仮想マシンのオプションやJava仮想マシンのバージョンによって異なります。Java仮想マシンが使用するメモリ所要量については，Java仮想マシンのマニュアルを参照してください。

ｎ：作業表用増分メモリサイズ

pd_work_buff_expand_limitオペランドを指定する場合に作業表用増分メモリサイズを加算します。作業表用増分メモリサイズは次に示す計算式から求めます。

作業表用増分メモリサイズ（キロバイト）＝作業表用増分バッファサイズ＋↑（作業表用の増分バッファサイズ÷128）×0.1↑

作業表用増分バッファサイズ（キロバイト）＝MAX（0，ハッシュジョイン，副問合せのハッシュ実行による作業表用増分バッファサイズ）＋MAX（0，作業表数の増加による作業表用増分バッファサイズ）

ハッシュジョイン，副問合せのハッシュ実行による作業表用増分バッファサイズ＝MIN｛（ハッシュジョイン，副問合せのハッシュ実行をするときの作業表用バッファサイズ−pd_work_buff_sizeオペランドの値），（pd_work_buff_expand_limitオペランドの値−pd_work_buff_sizeオペランドの値）｝×ハッシュジョイン，副問合せのハッシュ実行をする同時実行ユーザ数

ハッシュジョイン，副問合せのハッシュ実行をするときの作業表用バッファサイズの求め方については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

作業表数の増加による作業表用増分バッファサイズ＝MIN｛（使用作業表数×128−pd_work_buff_sizeオペランドの値），（pd_work_buff_expand_limitオペランドの値−pd_work_buff_sizeオペランドの値）｝×（使用作業表数がpd_work_buff_sizeオペランドの値÷128以上になるユーザ数）

使用作業表数＝MAX（1SQL文が使用する作業表用ファイルの数，ASSIGN LIST文が使用する作業表用ファイルの数）

1SQL文が使用する作業表用ファイルの数，及びASSIGN LIST文が使用する作業表用ファイルの数の求め方については，「最大ファイル数の見積もり（pdfmkfs -lコマンド）」を参照してください。

ｐ：BLOB型データ用に必要なメモリ所要量

計算式については，「BLOB型データの検索又は更新時に必要なメモリ所要量の計算式（HiRDB/シングルサーバの場合）」を参照してください。

ｑ：サーバ側でブロック転送又は配列FETCHで必要なメモリ所要量

計算式については，「ブロック転送又は配列FETCHで必要なメモリ所要量の計算式」を参照してください。

ｒ：非同期READ用メモリサイズ

pd_max_ard_processオペランドが1以上の場合に加算します。次に示す計算式から求めます（単位：キロバイト）。

（90＋
90
Σ RDエリア用HiRDBファイルシステム領域管理用メモリ）
i=1
×pd_max_ard_processの値

RDエリア用HiRDBファイルシステム領域管理用メモリは計算値の大きい順に90領域を計算に使用します。サーバで使用する領域数が90領域に満たない場合，その領域まで計算します。

HiRDBファイルシステム領域管理用メモリはそれぞれの領域の初期設定時のパラメタを使用して，次の計算式から求めます（単位：キロバイト）。

なお，領域の初期設定時のパラメタはpdfstatfsコマンドに-Aオプションを指定して実行することで確認できます。

｛（ファイル数※１＋増分数※２）÷64｝×1.5※３

注※1　pdfmkfs -l指定値，又はpdfstatfs実行結果の[available file count]に表示される値です。

注※2　pdfmkfs -e指定値，又はpdfstatfs実行結果の[available expand count]に表示される値です。

注※3　領域サイズ（pdfmkfs -n指定値）が2048以上の場合に乗算します。

ｓ：HiRDBファイルシステム用メモリサイズ

次に示す計算式から求めます（単位：キロバイト）。

604＋作業表用HiRDBファイルシステム領域管理用メモリ＋
システムログ用HiRDBファイルシステム領域管理用メモリ＋
90
ΣRDエリア用HiRDBファイルシステム領域管理用メモリ
i=1

作業表用及びシステムログ用HiRDBファイルシステム領域管理用メモリは，サーバで使用するHiRDBファイルシステム領域で計算値が最大になるものを使用します。RDエリアの場合は計算値の大きい順に90領域を計算に使用します。サーバで使用する領域数が90領域に満たない場合，その領域まで計算します。

HiRDBファイルシステム領域管理用メモリはそれぞれの領域の初期設定時のパラメタを使用して，次の計算式から求めます（単位：キロバイト）。

なお，領域の初期設定時のパラメタはpdfstatfsコマンドに-Aオプションを指定して実行することで確認できます。

｛（ファイル数※１＋増分数※２）÷64｝×1.5※３

注※1　pdfmkfs -l指定値，又はpdfstatfs実行結果の[available file count]に表示される値です。

注※2　pdfmkfs -e指定値，又はpdfstatfs実行結果の[available expand count]に表示される値です。

注※3　領域サイズ（pdfmkfs -n指定値）が2048以上の場合に乗算します。

ｔ：pd_utl_exec_modeの値が0の場合：0

pd_utl_exec_modeの値が1の場合：b×201

ｕ：ユニット制御情報定義として有効なpd_module_trace_maxの値

ｖ：シングルサーバ定義として有効なpd_module_trace_maxの値

ｗ：HiRDBの再開始用メモリサイズ

このメモリサイズを確保できないと，HiRDBの再開始に失敗します。次の計算式から求めます（単位：バイト）。

A＋B

●pd_dbsync_pointオペランドにcommitを指定している場合，加算します。
＋112×（pd_max_usersの値×2＋7）
●raw I/O機能を使用したHiRDBファイルシステム領域に作成されたRDエリアを格納したHiRDBファイルシステム領域数が1001以上の場合に加算します。
＋D

y：システム共通定義，又はユニット制御情報定義にpd_module_trace_maxオペランドを指定している場合：pd_module_trace_maxの値

それ以外：16383

HiRDBの再開始用メモリサイズを求める計算に使用する変数を次に示します。

変数 | 値

Ａ

●32ビットモードの場合

246762＋4×pd_max_rdarea_noの値

＋｛48×（pd_max_rdarea_noの値＋表数）＋304｝×（pd_max_usersの値×2＋7）

●64ビットモードの場合

305274＋8×pd_max_rdarea_noの値

＋｛64×（pd_max_rdarea_noの値＋表数）＋512｝×（pd_max_usersの値×2＋7）

表数：62＋MAX｛pd_max_access_tablesの値，500｝

Ｂ

b1×X＋b2×Y

b1：サーバ用ステータスファイルのレコード長＜4096の場合

　　　MAX（（↓（3400÷（（↓（（レコード長−40）−308）÷20↓）

　　　＋（↓（レコード長−40）÷20↓）×（MAX（↓4096÷レコード長↓，2）−1））

　　　＋0.7）↓），1）×MAX(↓4096÷レコード長↓，2）×（レコード長−40）

　　4096≦サーバ用ステータスファイルのレコード長＜12288の場合

　　　MAX（↓（3400÷（↓（（（レコード長−40）−308）÷20）↓）＋0.7）↓，1）

　　　×（レコード長−40）

　　12288≦サーバ用ステータスファイルのレコード長の場合

　　　MAX（↓（3400÷（↓（（（レコード長−40）−836）÷20）↓）＋0.7）↓，1）

　　　×（レコード長−40）

Ｘ：RDエリア数≦3400の場合：1

　　3401≦RDエリア数≦6800の場合：2

　　6801≦RDエリア数の場合：3

b2：サーバ用ステータスファイルのレコード長＜4096の場合

　　　（↓（5662310÷（（↓（（レコード長−40）−308）÷20↓）

　　　＋（↓（レコード長−40）÷20↓）×（MAX（↓4096÷レコード長↓，2）−1））

　　　＋0.7）↓）×MAX（↓4096÷レコード長↓，2）×（レコード長−40）

　　4096≦サーバ用ステータスファイルのレコード長＜12288の場合

　　　↓（5662310÷（↓（（（レコード長−40）−308）÷20）↓）＋0.7）↓

　　　×（レコード長−40）

　　12288≦サーバ用ステータスファイルのレコード長の場合

　　　↓（5662310÷（↓（（（レコード長−40）−836）÷20）↓）＋0.7）↓

　　　×（レコード長−40）

Ｙ：RDエリア数≦10200の場合：0

　　10201≦RDエリア数≦5672510の場合：1

　　5672511≦RDエリア数≦11334820の場合：2

　　11334821≦RDエリア数の場合：3

D

●32ビットモードの場合

12012×（↑（raw I/O機能を使用したHiRDBファイルシステム領域に作成されたRDエリアを格納したHiRDBファイルシステム領域数−1000）÷1000↑）

●64ビットモードの場合

16016×（↑（raw I/O機能を使用したHiRDBファイルシステム領域に作成されたRDエリアを格納したHiRDBファイルシステム領域数−1000）÷1000↑）

Ｅ，Ｆ，Ｇ：固定値

この値はOSによって異なります。OSごとの値を次に示します（単位：キロバイト）。

OS | Ｅの値 | Fの値 | Gの値
Windows (x64) | 155,500 | 5,200 | 12,700

Ｈ：余裕を持って見積もる場合は監査対象イベントの数（CREATE AUDITの実行回数），詳細に見積もる場合はセキュリティ監査情報用バッファのエントリ数

Ｊ：シンクポイント出力同期制御情報取得機能使用時に必要なメモリ（単位：バイト）

pd_dbbuff_trace_levelオペランドに1を指定し，かつpd_dfw_awt_processオペランドの指定を省略している場合に，次の値を加算します。

32ビットモードの場合：

320×シングルサーバに定義したグローバルバッファの数

64ビットモードの場合：

640×シングルサーバに定義したグローバルバッファの数

Ｋ：pd_max_resident_rdarea_noオペランドに1以上を指定している場合に，次の値を加算します。

1648＋16×pd_max_resident_rdarea_noの値＋16×pd_max_resident_rdarea_shm_noの値

Ｌ：インメモリデータ処理で必要なメモリ所要量

計算式については，「インメモリデータ処理で必要なメモリ所要量」を参照してください。

Ｍ：通信トレース処理で必要なメモリ所要量

32ビットモードの場合：

（16×（N−1024）×2）×（pd_max_server_processの値−pd_max_usersの値−3）

64ビットモードの場合：

（32×（N−1024）×2）×（pd_max_server_processの値−pd_max_usersの値−3）

Ｎ：ユニット制御情報定義として有効なpd_pth_trace_maxの値

オペランドの指定値を2のべき乗に切り上げた値になります。

Ｐ：通信トレース処理で必要なメモリ所要量

32ビットモードの場合：

（16×（Q−1024）×2）×（pd_max_usersの値＋3）

64ビットモードの場合：

（32×（Q−1024）×2）×（pd_max_usersの値＋3）

Ｑ：シングルサーバ定義として有効なpd_pth_trace_maxの値

オペランドの指定値を2のべき乗に切り上げた値になります。

S：作業表を使用する操作（SQL及びユティリティ）を行うトランザクションの同時実行数

Ｔ，Ｕ，Ｖ：固定値

この値はOSによって異なります。OSごとの値を次に示します（単位：キロバイト）。

OS | Tの値 | Uの値 | Vの値
Windows (x64) | 1030 | 110 | 1070

表15‒3　SQL文ごとの作業表数の求め方

SQL文 | 作業表数の求め方

SELECT文

INSERT文（問合せ指定の場合）

1.〜8. の指定がない場合：0

1.〜8. の指定がある場合：該当する作業表数をすべて加算した値

複数の表を結合して検索する場合

増加作業表数＝（結合表数−1）×2＋1

ORDER BY句を指定する場合

増加作業表数＝2

GROUP BY句を指定する場合

増加作業表数＝GROUP BY句指定数

DISTINCT句を指定する場合

増加作業表数＝DISTINCT句指定数

UNION句，UNION ALL句又はEXCEPT[ALL]句を指定する場合

増加作業表数＝（UNION又はUNION ALL句指定数）×2＋1

探索条件中にインデクスを定義した列がある場合

増加作業表数＝探索条件中のインデクスを定義した列数

FOR UPDATE句又はFOR READ ONLY句を指定する場合

増加作業表数＝1

副問合せ（限定述語）を指定する場合

増加作業表数＝副問合せ指定数

UPDATE文 DELETE文 | 探索条件中のインデクスを定義した列数＋1

DROP SCHEMA文

DROP TABLE文

DROP INDEX文

CREATE INDEX文

REVOKE文でアクセス権限を取り消す場合

2

15.1.3　ユニットコントローラが使用する共用メモリの計算式

(1)　32ビットモードのHiRDBの場合

HiRDB/シングルサーバの開始から終了までの間にユニットコントローラが使用する共用メモリは，次に示すHiRDBのプロセスの項目すべてを加算した値です。

なお，ユニットコントローラ全体の共用メモリサイズは2ギガバイト以内になるようにしてください。

プロセスの種類 | 共用メモリの計算式（単位：バイト）

スケジューラ

pd_utl_exec_modeの値が0の場合

　｛↑（432＋304×n）÷1024↑＋513＋x＋↑（134＋pd_trn_rcvmsg_store_buflenの値）÷1024↑｝×1024

pd_utl_exec_modeの値が1の場合

　｛↑（432＋304×n）÷1024↑＋y＋↑（134＋pd_trn_rcvmsg_store_buflenの値）÷1024↑｝×1024

ｘ：シングルサーバの場合：116＋5×（m＋3）＋14

ｙ：シングルサーバの場合：5×（m＋3）＋14

ｍ：pd_max_usersの値

ｎ：ユニット内のサーバ数＋ユニット内ユティリティサーバ数＋1

ユニット内ユティリティサーバ数：28＋12

ロックサーバ

（320＋48＋c＋d＋48＋4096＋g＋48＋i＋48＋4096＋48＋n＋t＋u＋16）

　×pd_lck_pool_partitionの値

ｃ：pd_lck_hash_entryを省略，又は0を指定している場合：

　　　（↓（8＋4×MAX（↑（（p＋3）×（pd_max_access_tablesの値＋4＋5×2）

　　　＋↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×6）÷10↑

　　　　の値を超えない最大の素数，11261））÷16↓＋1）×16

　　pd_lck_hash_entryに2以上の素数でない値を指定している場合：

　　　（↓（8＋4×pd_lck_hash_entryの値を超えない最大の素数）÷16↓＋1）

　　　×16

　　pd_lck_hash_entryに1，又は素数を指定している場合：

　　　（↓（8＋4×pd_lck_hash_entryの値）÷16↓＋1）×16

ｄ：（（ｐ＋3）×（pd_max_access_tablesの値＋4＋5×2）＋

　　↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×6）×96

ｇ：pd_utl_exec_modeの値=1，かつp＞32の場合：

　　　（（p＋3）×3＋p）×256

　　pd_utl_exec_modeの値=0，又はp≦32の場合：

　　　（（p＋3）×3＋32）×256

ｉ：pd_utl_exec_modeの値=1，かつp＞32の場合：

　　　（（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8＋（（ｐ＋3）

　　　×（pd_max_access_tablesの値＋4））×2）

　　　＋p×（pd_max_rdarea_noの値＋1）＋（p＋3）×2×2×5）

　　　を偶数に切り上げた値×64

　　pd_utl_exec_modeの値=0，又はp≦32の場合：

　　　（（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8＋（（p＋3）

　　　×（pd_max_access_tablesの値＋4））×2）

　　　＋32×（pd_max_rdarea_noの値＋1）＋（p＋3）×2×2×5）

　　　を偶数に切り上げた値×64

ｎ：pd_utl_exec_modeの値=1，かつp＞32の場合：

　　　（（p＋3）×3＋p）×48

　　pd_utl_exec_modeの値=0，又はp≦32の場合：

　　　（（p＋3）×3＋32）×48

ｐ：pd_max_usersの値

ｔ：pd_utl_exec_modeの値=1，かつｐ＞32の場合：

　　　48＋（（p＋3）×3＋p）×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　pd_utl_exec_modeの値=0，又はp≦32の場合：

　　　48＋（（p＋3）×3＋32）×↑pd_max_open_holdable_cursorsの値÷16↑×4

ｕ：pd_utl_exec_modeの値=1，かつｐ＞32の場合：

　　　48＋（（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8

　　　＋（（p＋3）×（pd_max_access_tablesの値＋4））×2）

　　　＋p×（pd_max_rdarea_noの値＋1）＋（p＋3）×2×2×5）

　　　を偶数に切り上げた値×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　pd_utl_exec_modeの値=0，又はp≦32の場合：

　　　48＋（（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8＋

　　　（（p＋3）×（pd_max_access_tablesの値＋4））×2）

　　　＋32×（pd_max_rdarea_noの値＋1）＋（p＋3）×2×2×5）

　　　を偶数に切り上げた値×↑pd_max_open_holdable_cursorsの値÷16↑×4

トランザクションサーバ | 288＋32＋192×m×2＋1028 ＋（420＋624＋256＋384×2＋128）×（m×2＋7）＋256×2 m：pd_max_usersの値
タイマサーバ | 32×（pd_max_usersの値＋3）×（1＋ユニット内ユティリティサーバ数＋1）＋1440 ユニット内ユティリティサーバ数：26＋12
統計ログサーバ | 384＋128×16＋32＋288×2＋1024＋128×3＋pd_stj_buff_sizeの値×1024×3＋64＋4096＋8192
プロセスサーバ | 192＋512×130＋96＋256＋（pd_max_server_processの値＋50）×（256＋144）＋16＋8×16＋16＋16＋48＋48×（a＋1） a：システム共通定義，又はユニット制御情報定義にpd_module_trace_maxオペランドを指定している場合：pd_module_trace_maxの値 　それ以外：16383

シングルサーバ

992＋（44＋4）×a×2＋（100＋4）×（b＋30＋2）＋（100＋4）×（c＋1）＋40×b×14＋256＋256＋36×d＋12×e＋8＋13080＋272＋5856×b＋f＋16＋1024＋272×h

a：シングルサーバの定義数

b：ユニット内のシングルサーバ数

c：ユニット数

d：pdunitオペランドの-cオプションの指定数

e：pdcltgrpオペランド指定数

f：2052＋128×（g＋3）

g：シングルサーバの場合：92

h：pd_security_host_groupオペランドに指定したホストに対応するIPアドレスの数

　　pd_security_host_groupオペランドを指定していない場合は0

ネームサーバ | 169984

ノードマネジャ

↑（1152＋432×全ユニット数＋80×全サーバ数＋7680＋1008

　＋56×ユニット内のサーバ数＋240×A＋44×A＋28×A＋16×B＋32）

　÷1024↑×1024

Ａ：pd_utl_exec_mode = 0の場合：1024

pd_utl_exec_mode = 1で，ユニット内にシングルサーバがある場合：pd_max_usersの値×10＋400

pd_utl_exec_mode = 1で，ユニット内にシングルサーバがない場合：pd_max_usersの値×7

なお，Aの値が1024を超えない場合は，Aを1024に置き換えて計算してください。

Ｂ：pdcltgrpオペランドを指定しない場合：0

pdcltgrpオペランドを指定する場合：pdcltgrpオペランドの指定数＋1

I/Oサーバ

↑（28＋（↑（32＋A）÷32↑×32））÷128↑×128

Ａ：196940

＋pd_max_file_no値×1024

＋pd_max_utl_ios_file_no値×296

ログサーバ

｛↑｛2＋48＋128×19＋384＋128×7＋1024＋512

＋↑（128＋256＋160＋8＋64）÷pd_log_rec_lengの値↑×pd_log_rec_lengの値

＋64＋4096×2＋（736＋512）×B

＋128×pd_log_write_buff_countの値

＋（pd_log_write_buff_countの値＋A）

×↑｛pd_log_max_data_sizeの値＋（68＋44＋96＋160）｝÷4096↑×4096

＋C＋↑｛（B＋1）÷12｝↑×8320｝÷4096↑｝×4096

Ａ：16

Ｂ：pdlogadfg -d sysオペランドの指定数

Ｃ：512

シンクポイントダンプサーバ

↑（368＋1456×2）÷1024↑×1024

＋↑｛（96＋80＋208＋208）＋192×（pdlogadfg -d spdの指定数）

＋416×（pdlogadpf -d spdの指定数）｝

÷1024↑×1024

ユニット共通

a＋b＋64＋（m＋3）×c＋64＋48＋d＋e

＋（pd_max_server_processの値×2＋100）×（64＋16）＋32

＋（pd_max_server_processの値×2＋100＋384）×40＋32＋f＋g＋h＋i＋p＋q

＋（pd_max_server_processの値＋127＋r）×48＋32＋s＋t＋u

ａ：13376

ｂ：2988

ｃ：2712

ｄ：32×32

ｅ：64＋64×｛（m＋3）×2

　＋MAX（5，↓［m＋3］÷10↓）＋7｝

ｆ：512×（13＋3）×2

ｇ：｛↑（96＋pd_lck_until_disconnect_cntの値×112）÷4096↑｝

　　×4096×2

ｈ：↑（pd_registered_portで指定したポート番号の数×16＋32）

　　÷1024↑×1024

　　pd_registered_portを指定していない場合は0

ｉ：kが2以上の場合は32＋（8＋8×k）×n

　　それ以外の場合は0

ｋ：pd_lck_pool_partitionの値

ｍ：pd_max_usersの値

ｎ：（m＋3）×2＋MAX｛5，↓（m＋3）÷10↓｝＋7

ｐ：pd_dbbuff_modifyにYを指定している場合：2064＋pd_max_add_dbbuff_shm_noの値×4

　上記以外：2064

ｑ：144

ｒ：pd_utl_exec_modeの値=1，かつm＞32の場合：（m＋3）×3＋m

　　pd_utl_exec_modeの値=0，又はm≦32の場合：（m＋3）×3＋32

ｓ：pd_shm_reuseにYを指定し，かつpd_dbbuff_modifyにYを指定している場合：4112＋pd_max_add_dbbuff_shm_no値×8

　　pd_shm_reuseにYを指定し，かつpd_dbbuff_modifyにNを指定している場合：4112

　　上記以外：0

ｔ：352

ｕ：11520

トランザクションログサーバ

1024＋512×A

＋｛

　　128×B＋128

　　＋［F＋↑（128＋256＋8＋224）÷pd_log_rec_lengの値↑×pd_log_rec_lengの値

　　＋↑（pd_log_max_data_sizeの値＋68＋44＋96＋160）

　　÷pd_log_rec_lengの値↑×pd_log_rec_lengの値］×D

　　＋E＋（48＋8）×B×2

　｝×ユニット内のサーバ数

＋584×B＋128×B＋64×B×C＋128

＋｛

　　F＋↑（128＋256＋8＋224）÷pd_log_rec_lengの値↑×pd_log_rec_lengの値

　　＋↑（pd_log_max_data_sizeの値＋68＋44＋96＋160）

　　÷pd_log_rec_lengの値↑×pd_log_rec_lengの値

｝

＋E＋（48＋8）×（B×2＋2）

A：2

B：7＋pd_max_usersの値×2

C：1

D：シングルサーバの場合，pd_log_rollback_buff_countの値が0のときは8，

　　それ以外のときはpd_log_rollback_buff_countの値

E：512

F：512

ステータスサーバ | ↑64÷32↑×32

監査証跡管理サーバ

↑A÷1024↑×1024

Ａ：pd_aud_file_nameオペランドの指定がない場合は640

　　pd_aud_file_nameオペランドの指定がある場合は640＋（304×200）＋B＋C

Ｂ：pd_aud_async_buff_sizeオペランドの値が0の場合は0

　　pd_aud_async_buff_sizeオペランドの値が4096以上の場合は次の計算値

　　　（160×pd_aud_async_buff_countオペランドの値）

　　　＋｛（↑pd_aud_async_buff_sizeオペランドの値÷4096↑×4096）

　　　×pd_aud_async_buff_countオペランドの値｝＋4096

Ｃ：pd_aud_auto_loadingオペランドにNを指定している場合は0

　　pd_aud_auto_loadingオペランドにYを指定している場合は256×2＋240

(2)　64ビットモードのHiRDBの場合

HiRDB/シングルサーバの開始から終了までの間にユニットコントローラが使用する共用メモリは，次に示すHiRDBのプロセスの項目すべてを加算した値です。

プロセスの種類 | 共用メモリの計算式（単位：バイト）

スケジューラ

pd_utl_exec_modeの値が0の場合

　｛↑（432＋304×n）÷1024↑＋513＋x＋↑（134＋pd_trn_rcvmsg_store_buflenの値）÷1024↑｝×1024

pd_utl_exec_modeの値が1の場合

　｛↑（432＋304×n）÷1024↑＋y＋↑（134＋pd_trn_rcvmsg_store_buflenの値）÷1024↑｝×1024

ｘ：シングルサーバの場合：116＋5×（m＋3）＋14

ｙ：シングルサーバの場合：5×（m＋3）＋14

ｍ：pd_max_usersの値

ｎ：ユニット内のサーバ数＋ユニット内ユティリティサーバ数＋1

ユニット内ユティリティサーバ数：28＋12

ロックサーバ

（496＋80＋c＋d＋64＋8192＋g＋80＋i＋64＋8192＋64＋n＋t＋u＋16）

　×pd_lck_pool_partitionの値

ｃ：pd_lck_hash_entryを省略，又は0を指定している場合：

　　　（↓（8＋8×MAX（↑（（p＋3）×（pd_max_access_tablesの値＋4＋5×2）

　　　＋↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×4）÷10↑

　　　　の値を超えない最大の素数，11261））÷16↓＋1）×16

　　pd_lck_hash_entryに2以上の素数でない値を指定している場合：

　　　（↓（8＋8×pd_lck_hash_entryの値を超えない最大の素数）÷16↓＋1）

　　　×16

　　pd_lck_hash_entryに1，又は素数を指定している場合：

　　　（↓（8＋8×pd_lck_hash_entryの値）÷16↓＋1）×16

ｄ：（（p＋3）×（pd_max_access_tablesの値＋4＋5×2）＋

　　↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×4）×128

ｇ：pd_utl_exec_modeの値=1，かつp＞32の場合：

　　　（（p＋3）×3＋p）×320

　　pd_utl_exec_modeの値=0，又はp≦32の場合：

　　　（（p＋3）×3＋32）×320

ｉ：pd_utl_exec_modeの値=1，かつp＞32の場合：

　　　（（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋（（p＋3）×（pd_max_access_tablesの値＋4））×2）

　　　＋↓（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓）÷3↓

　　　＋p×（pd_max_rdarea_noの値＋1）＋（p＋3）×2×2×5）

　　　を偶数に切り上げた値×112

　　pd_utl_exec_modeの値=0，又はp≦32の場合：

　　　（（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋（（p＋3）×（pd_max_access_tablesの値＋4））×2）

　　　＋↓（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓）÷3↓

　　　＋32×（pd_max_rdarea_no値＋1）＋（p＋3）×2×2×5）

　　　を偶数に切り上げた値×112

ｎ：pd_utl_exec_modeの値=1，かつp＞32の場合：

　　　（（p＋3）×3＋p）×80

　　pd_utl_exec_modeの値=0，又はp≦32の場合：

　　　（（p＋3）×3＋32）×80

ｐ：pd_max_usersの値

ｔ：pd_utl_exec_modeの値=1，かつｐ＞32の場合：

　　　48＋（（p＋3）×3＋p）×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　pd_utl_exec_modeの値=0，又はp≦32の場合：

　　　48＋（（p＋3）×3＋32）×↑pd_max_open_holdable_cursorsの値÷16↑×4

ｕ：pd_utl_exec_modeの値=1，かつｐ＞32の場合：

　　　48＋（（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋（（p＋3）×（pd_max_access_tablesの値＋4））×2）

　　　＋↓↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓÷3↓

　　　＋p×（pd_max_rdarea_noの値＋1）＋（p＋3）×2×2×5）

　　　を偶数に切り上げた値×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　pd_utl_exec_modeの値=0，又はp≦32の場合：

　　　48＋（（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋（（p＋3）×（pd_max_access_tablesの値＋4））×2）

　　　＋↓↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓÷3↓

　　　＋32×（pd_max_rdarea_noの値＋1）＋（p＋3）×2×2×5）

　　　を偶数に切り上げた値×↑pd_max_open_holdable_cursorsの値÷16↑×4

トランザクションサーバ | 304＋32＋192×m×2＋1048 ＋（416＋800＋256＋392×2＋128）×（m×2＋7）＋256×2 m：pd_max_usersの値
タイマサーバ | 32×（pd_max_usersの値＋3）×（1＋ユニット内ユティリティサーバ数＋1） ＋1440＋（48−32）×2 ユニット内ユティリティサーバ数は26＋12
統計ログサーバ | 424＋128×16＋32＋288×2＋1168＋144×3 ＋pd_stj_buff_sizeの値×1024×3＋64＋4096＋8192
プロセスサーバ | 208＋528×130＋96＋256＋（pd_max_server_processの値＋50）×（256＋160）＋16＋8×16＋16＋16＋64＋64×（a＋1） a：システム共通定義，又はユニット制御情報定義にpd_module_trace_maxオペランドを指定している場合：pd_module_trace_maxの値 　それ以外：16383

シングルサーバ

1024＋（48＋8）×a×2＋（112＋8）×（b＋30＋2）＋（104＋8）×（c＋1）＋40×b×14＋256＋256＋40×d＋16×e＋8＋13096＋320＋5856×b＋f＋16＋1024＋272×h

a：シングルサーバの定義数

b：ユニット内のシングルサーバ数

c：ユニット数

d：pdunitオペランドの-cオプションの指定数

e：pdcltgrpオペランド指定数

f：2056＋128×（g＋3）

g：シングルサーバの場合：93

h：pd_security_host_groupオペランドに指定したホストに対応するIPアドレスの数

　　pd_security_host_groupオペランドを指定していない場合は0

ネームサーバ | 169984

ノードマネジャ

↑（1312＋464×HiRDBシステムの全ユニット数

　＋96×HiRDBシステムの全サーバ数＋10240＋1200

　＋72×ユニット内HiRDBサーバ数＋240×A＋44×A＋28×A＋16×B＋48）

÷1024↑×1024

Ａ：pd_utl_exec_mode = 0の場合：1024

pd_utl_exec_mode = 1で，ユニット内にシングルサーバがある場合：pd_max_usersの値×10＋400

pd_utl_exec_mode = 1で，ユニット内にシングルサーバがない場合：pd_max_usersの値×7

なお，Aの値が1024を超えない場合は，Aを1024に置き換えて計算してください。

Ｂ：pdcltgrpオペランドを指定しない場合：0

pdcltgrpオペランドを指定する場合：pdcltgrpオペランドの指定数＋1

I/Oサーバ

↑（56＋（↑（56＋A）÷32↑×32））÷128↑×128

Ａ：196988

＋pd_max_file_no値×1024

＋pd_max_utl_ios_file_no値×296

ログサーバ

｛↑｛32＋48＋128×19＋432＋128×7＋1168＋512

＋↑（128＋256＋160＋8＋64）÷pd_log_rec_lengの値↑×pd_log_rec_lengの値

＋64＋4096×2＋（768＋512）×B

＋144×pd_log_write_buff_countの値

＋（pd_log_write_buff_countの値＋A）

×↑｛pd_log_max_data_sizeの値＋（68＋44＋96＋160）｝÷4096↑×4096

＋C＋↑｛（B＋1）÷12｝↑×8320｝÷4096↑｝×4096

Ａ：16

Ｂ：pdlogadfg -d sysオペランドの指定数

Ｃ：512

シンクポイントダンプサーバ

↑（384＋1536×2）÷1024↑×1024

＋↑｛（128＋80＋240＋240）＋192×（pdlogadfg -d spdの指定数）

＋416×（pdlogadpf -d spdの指定数）｝

÷1024↑×1024

ユニット共通

a＋b＋80＋（m＋3）×c＋64＋48＋d＋e

＋（pd_max_server_processの値×2＋100）×（76＋16）＋32

＋（pd_max_server_processの値×2＋100＋384）×40＋32＋f＋g＋h＋i＋p＋q

＋（pd_max_server_processの値＋127＋r）×64＋32＋s＋t＋u

ａ：22784

ｂ：5160

ｃ：3744

ｄ：48×32

ｅ：80＋96×｛（m＋3）×2

　＋MAX（5，↓［m＋3］÷10↓）＋7｝

ｆ：512×（13＋3）×2

ｇ：｛↑（128＋pd_lck_until_disconnect_cntの値×112）÷4096↑｝

　　×4096×2

ｈ：↑（pd_registered_portで指定したポート番号の数×16＋32）

　　÷1024↑×1024

　　pd_registered_portを指定していない場合は0

ｉ：kが2以上の場合は32＋（8＋8×k）×n

　　それ以外の場合は0

ｋ：pd_lck_pool_partitionの値

ｍ：pd_max_usersの値

ｎ：（m＋3）×2＋MAX｛5，↓（m＋3）÷10↓｝＋7

ｐ：pd_dbbuff_modifyにYを指定している場合：2064＋（pd_max_add_dbbuff_shm_noの値＋pd_max_resident_rdarea_shm_noの値）×4

　上記以外：2064＋pd_max_resident_rdarea_shm_noの値×4

ｑ：144

ｒ：pd_utl_exec_modeの値=1，かつm＞32の場合：（m＋3）×3＋m

　　pd_utl_exec_modeの値=0，又はm≦32の場合：（m＋3）×3＋32

ｓ：pd_shm_reuseにYを指定し，かつpd_dbbuff_modifyにYを指定している場合：8208＋（pd_max_add_dbbuff_shm_no値＋pd_max_resident_rdarea_shm_no値）×16

　　pd_shm_reuseにYを指定し，かつpd_dbbuff_modifyにNを指定している場合：8208＋pd_max_resident_rdarea_shm_no値×16

　　上記以外：0

ｔ：352

ｕ：11520

トランザクションログサーバ

1168＋688×A

＋｛

　　128×B＋144

　　＋［G＋↑（128＋256＋8＋224）÷pd_log_rec_lengの値↑×pd_log_rec_lengの値

　　＋↑（pd_log_max_data_sizeの値＋68＋44＋96＋160）

　　÷pd_log_rec_lengの値↑×pd_log_rec_lengの値］×D

　　＋E＋（48＋8）×B×2

　｝×ユニット内のサーバ数

＋600×B＋128×B＋64×B×C＋144

＋｛

　　G＋↑（128＋256＋8＋224）÷pd_log_rec_lengの値↑×pd_log_rec_lengの値

　　＋↑（pd_log_max_data_sizeの値＋68＋44＋96＋160）

　　÷pd_log_rec_lengの値↑×pd_log_rec_lengの値

　｝

＋E＋（48＋8）×（B×2＋2）

Ａ：2

Ｂ：7＋pd_max_usersの値×2

Ｃ：１

Ｄ：シングルサーバの場合，pd_log_rollback_buff_countの値が0のときは8，

　　それ以外のときはpd_log_rollback_buff_countの値

Ｅ：4096

Ｇ：64

ステータスサーバ | ↑64÷32↑×32

監査証跡管理サーバ

↑A÷1024↑×1024

Ａ：pd_aud_file_nameオペランドの指定がない場合は704

　　pd_aud_file_nameオペランドの指定がある場合は704＋（320×200）＋B＋C

Ｂ：pd_aud_async_buff_sizeオペランドの値が0の場合は0

　　pd_aud_async_buff_sizeオペランドの値が4096以上の場合は次の計算値

　　　（176×pd_aud_async_buff_countオペランドの値）

　　　＋｛（↑pd_aud_async_buff_sizeオペランドの値÷4096↑×4096）

　　　×pd_aud_async_buff_countオペランドの値｝＋4096

Ｃ：pd_aud_auto_loadingオペランドにNを指定している場合は0

　　pd_aud_auto_loadingオペランドにYを指定している場合は256×2＋256

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

シングルサーバが使用する共用メモリの計算式を次に示します。

32ビットモードの場合（単位：キロバイト）

計算式1＋↑｛（↑（40＋（計算式2〜計算式6，計算式8を加算した値）＋（6.5×1024×1024））÷512↑×512）｝÷1024↑

64ビットモードの場合（単位：キロバイト）

計算式1＋↑｛（↑（72＋（計算式2〜計算式8を加算した値）＋（6.5×1024×1024））÷512↑×512）｝÷1024↑

計算式1〜9についての注意事項

pd_rdarea_open_attribute_useオペランドにYを指定する場合に計算式3を加算します。

pd_dbsync_point又はpd_system_dbsync_pointオペランドのどちらかの指定がcommitの場合に計算式4を加算します。pd_system_dbsync_pointオペランドの省略値はcommitです。

上記以外の場合，計算式6を加算します。

pd_dfw_awt_processオペランドを指定する場合に計算式5を加算します。

pd_sds_shmpool_sizeオペランドを省略すると，次の値が設定されます。

32ビットモードの場合：

↑｛（↑（40＋（計算式2〜計算式6，計算式8，9の合計値））÷512↑×512）｝÷1024↑

64ビットモードの場合：

↑｛（↑（72＋（計算式2〜計算式8，9の合計値））÷512↑×512）｝÷1024↑

pd_max_resident_rdarea_noオペランドを指定する場合に計算式7を加算します。

pd_max_temporary_object_noの値が1以上の場合に計算式8を加算します。

pd_max_tmp_table_rdarea_noの値が１以上の場合に計算式9 を加算します。

計算式1〜9を次に示します。

計算式の種類 | 共用メモリの計算式

計算式1

（単位：キロバイト）

●32ビットモードの場合

b×1.3＋c＋d＋f＋1.6＋q＋r＋4

＋｛［（a＋12）÷13］×1.1＋［（a＋62）÷63］＋3.7｝×（e＋3）＋3.5

＋｛

　　↑（↑（b÷64）↑）×（8÷16）↑×4×4

　　＋12×｛（b÷3）＋1−mod（b÷3, 2）｝

　　＋8×a×｛（e＋3）×2＋1＋MAX（e÷10，5）｝＋32＋20000

　　＋↑｛（c÷8）＋7｝÷64↑×8＋↑｛（f÷8）＋7｝÷64↑×8

　　＋MAX｛a×（e＋3），c÷8｝×104＋MAX｛a×（e＋3），f÷8｝×24

　　＋↑｛（q÷4）＋7｝÷64↑×8

　　＋↑｛[（r−（s×592＋t×916＋u×172））÷2]＋7｝÷64↑×8

　　＋MAX｛13×（e＋3），q÷4｝×88

　　＋MAX｛21×（e＋3），[r−（s×592＋t×916＋u×172）]÷2｝×60

　　＋44＋256＋1024＋512※１

　｝÷1024＋y＋7.5

＋↑｛248×v×w＋47×v＋72｝÷1024↑

＋↑｛↑（28＋（↑（32＋（（↑g÷127↑＋1）×2048＋128））÷32↑×32））

　　÷128↑×128

　　｝÷1024↑

　D

＋Σ（Ei）

　i=1

＋1024

pd_def_buf_control_area_assignオペランドにINITIALを指定するか，又はこのオペランドを省略した場合に加算します。

＋｛［（a＋12）÷13］×1.1＋［（a＋62）÷63］＋3.7｝×（e＋7）

●64ビットモードの場合

b×1.3＋c＋d＋f＋1.6＋q＋r＋5

＋｛［（a＋12）÷13］×1.2＋［（a＋62）÷63］×1.5＋4.1｝

×（e＋3）＋3.5

＋｛

　　↑（↑（b÷64）↑）×（8÷16）↑×4×4＋12

　　×｛（b÷3）＋1−mod（b÷3, 2）｝

　　＋8×a×｛（e＋3）×2＋1＋MAX（e÷10，5）｝＋48＋20000

　　＋↑｛（c÷8）＋7｝÷64↑×8＋↑｛（f÷8）＋7｝÷64↑×8

　　＋MAX｛a×（e＋3），c÷8｝×104＋MAX｛a×（e＋3），f÷8｝×40

　　＋↑｛（q÷4）＋7｝÷64↑×8

　　＋↑｛[（r−（s×600＋t×936＋u×184））÷2]＋7｝÷64↑×8

　　＋MAX｛13×（e＋3），q÷4｝×104

　　＋MAX｛21×（e＋3），[r−（s×600＋t×936＋u×184）]÷2｝×72

　　＋72＋256＋1536＋512※１

　｝÷1024＋y＋7.5

＋↑｛248×v×w＋64×v＋72｝÷1024↑

＋↑｛↑（56＋（↑（56＋（（↑g÷127↑＋1）×2048＋128））÷32↑×32））

　　÷128↑×128

　　｝÷1024

　D

＋Σ（Ei）

　i=1

＋1024

pd_def_buf_control_area_assignオペランドにINITIALを指定するか，又はこのオペランドを省略した場合に加算します。

＋｛［（a＋12）÷13］×1.2＋［（a＋62）÷63］×1.5＋4.1｝×（e＋7）

計算式2

（単位：バイト）

●32ビットモードの場合

500×1024

　　＋5072×（e＋15）＋（↑436×g÷16↑×16）＋48※１×g＋496×h

　　＋112×（p＋240）

　　＋96×x＋32×j＋132×｛19＋（e＋3）×3｝

　　＋48×n＋48×｛（e＋3）×2＋1＋MAX（5，（e＋3）÷10）｝

　　＋68×B＋152×（A＋120）＋80＋32×g＋64※２＋368※３

　　＋（（↓（↑（g÷8）↑＋3）÷4↓）×4）×j

●64ビットモードの場合

500×1024

　　＋9416×（e＋15）＋（↑536×g÷16↑×16）

　　＋（↑56※１×g÷16↑×16）＋512×h

　　＋（↑136×（p＋240）÷16↑×16）

　　＋144×x＋80×j＋240×｛19＋（e＋3）×3｝

　　＋64×n＋96×｛（e＋3）×2＋1＋MAX（5，（e＋3）÷10）｝

　　＋68×B＋184×（A＋120）＋96＋48×g＋64※２＋448※３

　　＋（（↓（↑（g÷8）↑＋7）÷8↓）×8）×j

計算式3

（単位：バイト）

●32ビットモードの場合

｛[（↑↑g÷8↑÷4↑）×4]＋8｝×｛（e＋3）×2＋12｝

●64ビットモードの場合

｛[（↑↑g÷8↑÷8↑）×8]＋8｝×｛（e＋3）×2＋12｝

計算式4

（単位：バイト）

●32ビットモードの場合

（32＋16×x）×（e×2＋7＋1）＋16

●64ビットモードの場合

（48＋32×x）×（e×2＋7＋1）＋16

計算式5

（単位：バイト）

●32ビットモードの場合

72＋52×C＋68×x

pd_dbbuff_trace_levelオペランドに1を指定する場合に加算します。

＋320×x

●64ビットモードの場合

96＋56×C＋72×x

pd_dbbuff_trace_levelオペランドに1を指定する場合に加算します。

＋640×x

計算式6

（単位：バイト）

●32ビットモードの場合

（32＋16×x）×10＋16

●64ビットモードの場合

（48＋32×x）×10＋16

計算式7 （単位：バイト） | 16＋112＋（48＋48×G）＋（48＋32×Ｈ）
計算式8 （単位：バイト） | 16＋80×I
計算式9 （単位：バイト） | ↑（112＋（28＋J×52））÷8↑×8

ａ：pd_max_access_tablesオペランドの値

ｂ：pd_sql_object_cache_sizeオペランドの値

ｃ：pd_table_def_cache_sizeオペランドの値

ｄ：pd_auth_cache_sizeオペランドの値

ｅ：pd_max_usersオペランドの値

ｆ：pd_view_def_cache_sizeオペランドの値

ｇ：pd_max_rdarea_noオペランドの値

ｈ：pd_max_file_noオペランドの値

ｊ：インデクス用のグローバルバッファプール数

pdbufferに-Dの指定がないものは１，指定があるものは分割数を合計したものがグローバルバッファプール数となります。

ｎ：pd_lck_until_disconnect_cntオペランドの値

ｐ：pd_assurance_index_noオペランドの値

ｑ：pd_type_def_cache_sizeオペランドの値

ｒ：pd_routine_def_cache_sizeオペランドの値

ｓ：インストールしたプラグインの数

ｔ：DMLで使用するプラグイン関数の総数 ※４

ｕ：DMLで使用するプラグイン関数のパラメタ総数 ※４

ｖ：pd_max_list_usersオペランドの値

ｗ：pd_max_list_countオペランドの値

ｘ：総グローバルバッファ数（pdbufferオペランドの指定数）

pdbufferに-Dの指定がないものは１，指定があるものは分割数を合計したものがグローバルバッファプール数となります。

pd_dbbuff_modifyオペランドにYを指定している場合，pdbufferコマンドの指定数に，pd_max_add_dbbuff_noオペランドの値を加算して計算します。

ｙ：pd_registry_cache_sizeオペランドの値

Ａ：pd_assurance_table_noオペランドの値

Ｂ：サーバ内の最大トランザクション数（2×e＋7）

Ｃ：pd_dfw_awt_processオペランドの値

D：指定したpdplgprmオペランドの総数

Ei：i番目のpdplgprmオペランドで指定した共用メモリのサイズ

Ｇ：pd_max_resident_rdarea_noオペランドの値

Ｈ：pd_max_resident_rdarea_shm_noオペランドの値

I：pd_max_temporary_object_noオペランドの値

Ｊ：pd_max_tmp_table_rdarea_noオペランドの値

T：空き領域の再利用機能を使用する表数

注※1

pd_max_list_users及びpd_max_list_countオペランドの両方とも0でない場合に加算します。

注※2

pd_max_ard_processオペランドが1以上の場合に加算します。

注※3

再編成時期予測機能を使用する場合に加算します。

注※4

DMLで使用するプラグイン関数の総数及びDMLで使用するプラグイン関数のパラメタの総数は，次に示すSQLで求められます。

SELECT COUNT(*),SUM(N_PARAM) FROM MASTER.SQL_PLUGIN_ROUTINES
WHERE PLUGIN_NAME = 'プラグイン名称'
AND (TIMING_DESCRIPTOR = 'ADT_FUNCTION'
    OR TIMING_DESCRIPTOR IS NULL
    OR TIMING_DESCRIPTOR = 'BEFORE_INSERT'
    OR TIMING_DESCRIPTOR = 'AFTER_INSERT'
    OR TIMING_DESCRIPTOR = 'BEFORE_UPDATE'
    OR TIMING_DESCRIPTOR = 'AFTER_UPDATE'
    OR TIMING_DESCRIPTOR = 'BEFORE_DELETE'
    OR TIMING_DESCRIPTOR = 'AFTER_DELETE'
    OR TIMING_DESCRIPTOR = 'BEFORE_PURGE_TABLE'
    OR TIMING_DESCRIPTOR = 'AFTER_PURGE_TABLE'
    OR TIMING_DESCRIPTOR = 'INDEX_SEARCH'
    OR TIMING_DESCRIPTOR = 'INDEX_COUNT'
    OR TIMING_DESCRIPTOR = 'INDEX_INSERT'
    OR TIMING_DESCRIPTOR = 'INDEX_BEFORE_UPDATE'
    OR TIMING_DESCRIPTOR = 'INDEX_AFTER_UPDATE'
    OR TIMING_DESCRIPTOR = 'INDEX_DELETE'
    OR TIMING_DESCRIPTOR = 'PURGE_INDEX'
    OR TIMING_DESCRIPTOR = 'INDEX_MAINTENANCE_DEFERRED'
    OR TIMING_DESCRIPTOR = 'BEFORE_INSERT_DC'
    OR TIMING_DESCRIPTOR = 'BEFORE_UPDATE_DC'
    OR TIMING_DESCRIPTOR = 'BEFORE_DATA_CHECK'
    OR TIMING_DESCRIPTOR = 'AFTER_DATA_CHECK')

15.1.5　グローバルバッファが使用する共用メモリの計算式

グローバルバッファが使用する共用メモリサイズは，pdbuffer文ごとに計算式1で求めます。pd_dbbuff_modifyオペランドにYを指定している場合は，計算式2を加算します。計算式1及び2で求めた値を合計した値が，グローバルバッファが使用する共用メモリの所要量です。

pd_shm_reuseオペランドにYを指定している場合は，グローバルバッファが使用する共用メモリ所要量を計算式3で見積もってください。

pd_dbbuff_attributeオペランドにfixedを指定している場合，実メモリ上にページ固定されるため，仮想メモリを構成する実メモリがそのサイズ分減少します。また，残り実メモリとスワップ領域で構成される仮想メモリからもそのサイズ分確保されます。

pdbuffer文に-Dを指定している場合，分割した個々のグローバルバッファを一つのグローバルバッファとして計算します。例として，「pdbuffer -n 10000 -D 3」と指定した場合，「pdbuffer -n 3334」のグローバルバッファを1個と「pdbuffer -n 3333」のグローバルバッファを2個の計3個を指定したものとして計算します。

-n指定値が分割数×4より小さい場合，-nに4を指定した分割数分のpdbuffer文を指定したものとして計算します。例として，「pdbuffer -n 100 -D 100」と指定した場合，「pdbuffer -n 4」のグローバルバッファを100個指定したものとして計算します。

なお，pdbufferオペランドを省略した場合，HiRDBが共用メモリサイズを自動計算するので見積もりは必要ありません。

(1)　グローバルバッファが使用する共用メモリを実メモリ上に固定しない場合

グローバルバッファが使用する共用メモリを実メモリ上に固定しない場合（pd_dbbuff_attributeオペランドにfreeを指定した場合）は，次の計算式を使用します。

計算式の種類 | 共用メモリの計算式（単位：キロバイト）

計算式1

●32ビットモードの場合

n

Σ｛

i=1

　　↑｛752＋64＋（296＋64※１）×（Pi＋4）

　　＋（124＋80※２＋96×A×Mi）×Ui｝÷T↑×T

　　＋Si×｛Pi＋4＋（Ui×Mi×A）｝＋Vi

　　｝÷1024

●64ビットモードの場合

n

Σ｛管理領域部＋データ格納部｝÷1024

i=1

　　管理領域部：

　　　↑｛944＋64＋（480＋112※１）×（Pi＋4）

　　　＋（176＋96※２＋136×A×Mi）×Ui｝÷T↑×T

　　データ格納部：

　　　Si×｛Pi＋4＋（Ui×Mi×A）｝＋Vi

計算式2

●32ビットモードの場合

｛↑（↑（s×1024÷2）÷8↑＋112）÷2048↑×2048×

　↑a÷（s×1024）↑｝÷1024

●64ビットモードの場合

｛↑（↑（s×1024÷2）÷8↑＋144）÷2048↑×2048×

　↑a÷（s×1024）↑｝÷1024

計算式3

↑（計算式1＋計算式2※３＋

n

Σ｛管理領域部｝÷1024）÷（s×1024）↑×（s×1024）

i=1

　　管理領域部：

　　●32ビットモードの場合

　　　↑｛752＋64＋（296＋64※１）×（Pi＋4）

　　　＋（124＋80※２＋96×A×Mi）×Ui｝÷4096↑×4096

　　●64ビットモードの場合

　　　↑｛944＋64＋（480＋112※１）×（Pi＋4）

　　　＋（176＋96※２＋136×A×Mi）×Ui｝÷4096↑×4096

n：グローバルバッファプール数

i：計算対象のグローバルバッファプール定義

P：グローバルバッファ面数

A：

pd_max_ard_processオペランドが1以上の場合は2

pd_max_ard_processオペランドが0の場合は1

M：一括入力最大ページ数

U：同時実行最大プリフェッチ数

T：グローバルバッファのバウンダリ

pd_dbbuff_dev_sector_sizeオペランドに512を指定した場合は2048，4096を指定した場合は4096

S：グローバルバッファに割り当てたRDエリアの最大ページ長

V：

pd_dbbuff_dev_sector_sizeオペランドに4096を指定し，かつSが4096の倍数でない場合は2048。

pd_dbbuff_dev_sector_sizeオペランドに4096を指定していない，又はSが4096の倍数の場合は0。

s：SHMMAX指定値

a：計算式1の総計

注※1　LOB用グローバルバッファの場合に加算します。

注※2　pd_max_ard_processオペランドが1以上の場合に加算します。

注※3　pd_dbbuff_modifyオペランドにYを指定した場合に加算します。

(2)　グローバルバッファが使用する共用メモリを実メモリ上に固定する場合

グローバルバッファが使用する共用メモリを実メモリ上に固定する場合（pd_dbbuff_attributeオペランドにfixedを指定した場合）は，次の計算式を使用します。

計算式の種類 | 共用メモリの計算式（単位：キロバイト）

計算式1

●32ビットモードの場合

n

Σ｛

i=1

　　↑｛↑｛752＋64＋（296＋64※１）×（Pi＋4）

　　＋（124＋80※２＋96×A×Mi）×Ui｝÷T↑×T

　　＋Si×｛Pi＋4＋（Ui×Mi×A）｝＋Vi｝÷p↑×p

　　｝÷1024

●64ビットモードの場合

n

Σ｛↑｛管理領域部＋データ格納部｝÷p↑×p｝÷1024

i=1

　　管理領域部：

　　　↑｛944＋64＋（480＋112※１）×（Pi＋4）

　　　＋（176＋96※２＋136×A×Mi）×Ui｝÷T↑×T

　　データ格納部：

　　　Si×｛Pi＋4＋（Ui×Mi×A）＋Vi｝

計算式2

●32ビットモードの場合

｛↑｛↑（↑（s×1024÷2）÷8↑＋112）÷2048↑×2048×

　↑a÷（s×1024）↑｝÷p↑×p｝÷1024

●64ビットモードの場合

｛↑｛↑（↑（s×1024÷2）÷8↑＋144）÷2048↑×2048×

　↑a÷（s×1024）↑｝÷p↑×p｝÷1024

計算式3

↑（計算式1＋計算式2※３＋

n

Σ｛管理領域部｝÷1024）÷（↑（s×1024÷p）↑×p）↑

i=1

×（↑（s×1024÷p）↑×p）

　　管理領域部：

　　●32ビットモードの場合

　　　↑｛752＋64＋（296＋64※１）×（Pi＋4）

　　　＋（124＋80※２＋96×A×Mi）×Ui｝÷4096↑×4096

　　●64ビットモードの場合

　　　↑｛944＋64＋（480＋112※１）×（Pi＋4）

　　　＋（176＋96※２＋136×A×Mi）×Ui｝÷4096↑×4096

n：グローバルバッファプール数

i：計算対象のグローバルバッファプール定義

P：グローバルバッファ面数

A：

pd_max_ard_processオペランドが1以上の場合は2

pd_max_ard_processオペランドが0の場合は1

M：一括入力最大ページ数

U：同時実行最大プリフェッチ数

T：グローバルバッファのバウンダリ

pd_dbbuff_dev_sector_sizeオペランドに512を指定した場合は2048，4096を指定した場合は4096

S：グローバルバッファに割り当てたRDエリアの最大ページ長

p：WindowsのLarge Pageでのページサイズ

pdntenvコマンドで確認できます。

V：

pd_dbbuff_dev_sector_sizeオペランドに4096を指定し，かつSが4096の倍数でない場合は2048。

pd_dbbuff_dev_sector_sizeオペランドに4096を指定していない，又はSが4096の倍数の場合は0。

s：SHMMAX指定値

a：計算式1の総計

注※1　LOB用グローバルバッファの場合に加算します。

注※2　pd_max_ard_processオペランドが1以上の場合に加算します。

注※3　pd_dbbuff_modifyオペランドにYを指定した場合に加算します。

15.1.6　SQL実行時に必要なメモリ所要量の計算式

(1)　グループ分け高速化機能実行時に必要なメモリ所要量の求め方

クライアント環境定義でPDSQLOPTLVLオペランドを指定するか，HiRDBシステム定義でpd_optimize_levelオペランドを指定（又は省略）した場合，適用条件を満たすSQLを実行すると，グループ分け高速化機能が働きます。このとき，HiRDBはクライアント環境定義のPDAGGRオペランドの値に基づいてプロセス固有領域を確保します。確保するメモリサイズを次に示します。

計算式

e＋↑d÷4↑×4＋↑（17＋4×a＋4×b＋c＋d）÷4↑×4×（N＋1）
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（単位：バイト）

ａ：グループ化する列の数

ｂ：集合関数の演算数

COUNT，SUM，MAX，MINは一つにつき1で換算します。

AVG（COUNT），AVG（SUM）は一つにつき2で換算します。

ｃ：グループ化する列の列長（表「グループ化するときの列の長さ及び集合関数の演算領域の長さ」を参照して求めてください）

ｄ：集合関数の演算領域長（表「グループ化するときの列の長さ及び集合関数の演算領域の長さ」を参照して求めてください）

ｅ：32ビットモードの場合：MAX（4×N×24 ，16408）

64ビットモードの場合：MAX（8×N×40 ，32808）

Ｎ：クライアント環境定義のPDAGGRオペランドの値

表15‒4　グループ化するときの列の長さ及び集合関数の演算領域の長さ

列のデータ型 | グループ化する列の列長 | 集合関数の演算領域長※１
INTEGER | 4 | 6
SMALLINT | 2 | 4※２
DECIMAL(p,s) | ↑（p＋1）÷2↑ | ↑（p＋7）÷2↑※３
FLOAT | 8 | 10
SMALLFLT | 4 | 6
INTERVAL YEAR TO DAY | 5 | 8
INTERVAL HOUR TO SECOND | 4 | 6
CHAR(n) | n | n＋3
VARCHAR(n) | n＋2 | n＋5
NCHAR(n) | 2×n | 2×n＋2
NVARCHAR(n) | 2×n＋2 | 2×n＋4
MCHAR(n) | n | n＋3
MVARCHAR(n) | n＋2 | n＋5
DATE | 4 | 6
TIME | 3 | 6
BLOB(n) | − | −
BINARY(n) | n＋2 | n＋5

（凡例）−：該当しません。

注※1

集合関数がCOUNTの場合，集合関数演算領域長はデータ型にかかわらず6になります。

注※2

集合関数がAVG，SUMの場合は集合関数演算領域長は6になります。

注※3

集合関数がAVG，SUMの場合，集合関数演算領域長は次の値になります。

集合関数の値の型がDECIMAL型で精度が29けたのとき：18

集合関数の値の型がDECIMAL型で精度が38けたのとき：23

集合関数の値のデータ型の規則については，マニュアル「HiRDB SQLリファレンス」の「集合関数」を参照してください。

(2)　列ごとのデータ抑制指定時に必要なメモリ所要量の求め方

列ごとのデータ抑制を指定（CREATE TABLEの列定義にSUPPRESSを指定）した表に対してアクセスするときに使用するメモリサイズは，次に示す計算式で求められます。

計算式

a＋128　　（単位：バイト）

ａ：表中で列ごとのデータ抑制が指定されている列の定義長の合計値

(3)　ハッシュジョイン及び副問合せのハッシュ実行時に必要なメモリ所要量の求め方

クライアント環境定義でPDADDITIONALOPTLVLオペランドを指定するか，HiRDBシステム定義でpd_additional_optimize_levelオペランドを指定すると，SQL拡張最適化オプションが働きます。このSQL拡張最適化オプションで，「ハッシュジョイン，副問合せのハッシュ実行の適用（APPLY_HASH_JOIN）」を指定した場合，表の結合又は副問合せのSQLを実行すると，次に示すメモリサイズのプロセス固有領域を確保します。

計算式

●32ビットモードの場合
 a
Σ（13×1024＋6×1024×ｂ＋ｃ）
i=1

●64ビットモードの場合
 a
Σ （13×1024＋7×1024×ｂ＋ｃ）
i=1
　　　　　　　　　　　　　（単位：バイト）

ａ：SELECT文のハッシュジョイン最大数

SELECT文のハッシュジョイン最大数については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

ｂ：ハッシュ表行数によって適用されるハッシュジョイン処理を求めて，次に示す表から代入する値を決定してください。

ハッシュ表行数の目安 | 適用されるハッシュジョイン処理 | ｂの値
1500以内 | 一括ハッシュジョイン | 0.5
1500×（バケット分割数÷3）以内 | バケット分割 ハッシュジョイン | 1レベルバケット分割 | 1
1500×（バケット分割数÷3）²以内 | 2レベルバケット分割 | 2
1500×（バケット分割数÷3）²を超える場合 | 3レベルバケット分割 | 3

ハッシュ表行数：ジョインの場合はジョインの内表件数です。副問合せの場合は探索条件中の外への参照列を含む述語を除いた副問合せ探索件数です。

バケット分割数：MIN｛↓（ハッシュ表サイズ÷2）÷ハッシュ表ページ長↓，64｝

ハッシュ表サイズ：HiRDBシステム定義のpd_hash_table_sizeオペランド，又はクライアント環境変数のPDHASHTBLSIZEオペランドで指定した値です。

ハッシュ表ページ長：次に示す表からｃ（ハッシュ表最大行長）に対応するハッシュ表ページ長を選択してください。

ハッシュ表最大行長 | ハッシュ表ページ長（単位：バイト）
0〜1012 | 4096
1013〜2036 | 8192
2037〜4084 | 16384
4085〜16360 | 32768
16361〜32720 | ↑（ハッシュ表最大行長＋48）÷2048↑×2048

ｃ：ハッシュ表最大行長

ハッシュ表最大行長については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(4)　スナップショット方式指定時に必要なメモリ所要量の求め方

pd_pageaccess_modeオペランドを省略した場合又はSNAPSHOTを指定した場合，スナップショット方式を適用するSQL文を実行すると，データベース検索時のページアクセス方式にスナップショット方式を使用します。このとき，表又はインデクスの格納RDエリアのページサイズに基づいて，動的に次に示すメモリサイズのプロセス固有領域を確保します。

計算式

a×2　　（単位：バイト）

ａ：検索対象の表又はインデクスが格納されているRDエリア中の最大ページ長

ただし，LOB用RDエリアは除きます。

(5)　先頭からn行の検索結果を取得する機能実行時に必要なメモリ所要量の求め方

先頭からn行の検索結果を取得する機能を使用すると，検索結果の先頭（又はユーザが指定した先頭からのオフセット行数分読み飛ばした位置）からn行取得できます。

LIMIT句に指定した行数が1以上で，（オフセット行数＋LIMIT句に指定した行数）の値が32,767以下の場合，（オフセット行数＋LIMIT句に指定した行数）以内に入り得る行をメモリに保持します。確保するプロセス固有領域のメモリサイズは，次に示す計算式で求められます。なお，（オフセット行数＋LIMIT句に指定した行数）の値が32,768以上になる場合は作業表を作成するため，「作業表用ファイルの容量の見積もり」を参照してください。

計算式

｛100＋（a＋2）×（オフセット行数＋LIMIT句に指定した行数）｝×b
　　　　　　　　　　　　　　　　　　　　　　　　（単位：バイト）

ａ：行長

行長は32,720バイト以下でなければなりません。行長は次の計算式で求められます。

 m
Σ（Ai）＋2×m＋4＋c
i=1
　　　　　　　　　　　　　　　　　　　　　　　　（単位：バイト）

m：選択式，GROUP BY句，又はORDER BY句に指定した列数

FOR UPDATE句を指定した場合は1を加算してください。ただし，選択式にROWを指定している場合は表の全列数になります。

Ai：先頭n行保持領域に格納する行のi番目の列データ長

列のデータ長については，表「データ長一覧」を参照し，dに定義長を代入して求めてください。

ただし，BLOBデータ，定義長が256バイト以上の文字データ（各国・混在文字データも含む），BINARYデータのうち，下記に属さない列の場合は12バイトになります。

DISTINCT句指定の選択式に指定する列

UNION [ALL]によって集合演算対象となっている問合せ指定中の選択式

ORDER BY句に指定した列

また，FOR UPDATE句を指定した場合に，mに加算した1に対応するAiは12バイトとします。

c：8

ただし，次の場合は0になります。

検索対象の表にEXモードで排他が掛かっている場合

WITHOUT LOCKを指定した場合

グループ分け高速化機能を指定した場合

複数の表を結合する場合

b：先頭n行保持領域数

先頭n行の保持領域数は次の計算式で求められます。

1＋UNION [ALL]句指定数

(6)　探索条件にインデクス型プラグイン専用関数を指定したSQL文実行時に必要なメモリ所要量の求め方

探索条件にインデクス型プラグイン専用関数を指定したSQL文の実行時に確保するプロセス固有領域のメモリサイズは，次に示す計算式で求められます。

計算式

a×500＋（20＋6）×800＋16　　（単位：バイト）

ａ：行長。行長は次の計算式で求められます。

 m
Σ（Ai）＋4×（m＋2）＋12＋4＋8
i=1
　　　　　　　　　　　　　　　　　　　　　　　　（単位：バイト）

m：選択式，結合条件，GROUP BY句，又はORDER BY句に指定した列数

FOR UPDATE句を指定した場合は1を加算してください。ただし，選択式にROWを指定している場合は表の全列数になります。

Ai：取り出す行のi番目の列データ長

列のデータ長については，表「データ長一覧」を参照し，dに定義長を代入して求めてください。

ただし，BLOBデータ，又は定義長が256バイト以上の文字データ（各国・混在文字データも含む）で，下記に属さない列の場合は12バイトになります。

結合条件中に指定する列（結合列）

DISTINCT句指定の選択式に指定する列

限定述語の副問合せ中の選択式に指定する列

IN述語の副問合せ中の選択式に指定する列

UNION [ALL]，又はEXCEPT [ALL]によって集合演算対象となっている問合せ指定中の選択式

ORDER BY句に指定した列

また，FOR UPDATE句を指定した場合に，mに加算した1に対応するAiは12バイトとします。

(7)　拡張SQLエラー情報出力機能使用時に必要なメモリ所要量の求め方

拡張SQLエラー情報出力機能を使用した場合，次のときにプロセス固有領域を確保します。

(a)　OPEN文実行時

計算式

●32ビットモードの場合
（16＋16×m）＋a
●64ビットモードの場合
（16＋24×m）＋a
　　　　　　　　　　　　　　　　　　　　　　　　（単位：バイト）

a：？パラメタ又は埋込み変数のデータ長の合計

　m

a=Σ（ai）

　i=1

ｍ：SQL文中の？パラメタ又は埋込み変数の数

ai：i番目の？パラメタ又は埋込み変数のデータ長

埋込み変数又は？パラメタのデータ長を次の表に示します。

表15‒5　埋込み変数又は？パラメタのデータ長

データ型 | 列長（標識変数なし） | 列長（標識変数あり，埋込み変数又は？パラメタ）
INTEGER | 4 | 6
SMALLINT | 2 | 4
DECIMAL(p，s) | ↑（p＋1）÷2↑ | ↑（p＋5）÷2↑
FLOAT | 8 | 10
SMALLFLT | 4 | 6
INTERVAL YEAR TO DAY | 5 | 7
INTERVAL HOUR TO SECOND | 4 | 6
CHAR(n) | n | n＋2
VARCHAR(n) | n＋2 | n＋4
NCHAR(n) | 2×n | 2×n＋2
NVARCHAR(n) | 2×n＋2 | 2×n＋4
MCHAR(n) | n | n＋2
MVARCHAR(n) | n＋2 | n＋4
DATE | 4 | 6
TIME | 3 | 5
BLOB(n) | n＋4 | n＋8
TIMESTAMP(p) | 7＋（p÷2） | 9＋（p÷2）
BINARY(n) | n＋4 | n＋8

(b)　定義系SQLのPREPARE文実行時

計算式

SQL文長＋20
　　　　　　　　　　　　　　　　　　　　　　　　（単位：バイト）

(8)　部分構造インデクスの定義，又は部分構造インデクスを定義した表の更新時に必要なメモリ所要量の求め方

(a)　部分構造インデクスの定義時

定義系SQLのCREATE INDEXで部分構造インデクスを定義する場合に確保するプロセス固有領域は，次に示す計算式で求められます。

計算式

（インデクスキー長※×100＋64）　　（単位：バイト）

注※

表に定義する部分構造インデクスの最大定義長です。

(b)　部分構造インデクスを定義した表の更新時

操作系SQLのINSERT，UPDATE，又はDELETEで部分構造インデクスを定義した表を更新する場合に確保するプロセス固有領域は，次に示す計算式で求められます。

計算式

（インデクスキー長※１×100＋64＋128）＋Σ（インデクスキー長＋128）※２　　（単位：バイト）

注※1

表に定義している部分構造インデクスの最大定義長です。

注※2

USING UNIQUE TAG指定の部分構造インデクス数です。

(9)　圧縮列に対して操作系SQLを実行する場合に必要なメモリ所要量の求め方

SQL実行時，データの格納，及び抽出対象に圧縮列が含まれる場合，次に示すメモリサイズのプロセス固有領域を確保します。

計算式

MIN（圧縮分割サイズ，圧縮列の定義長）※×C＋L　　（単位：バイト）

C：次に示すどれかの条件に該当する場合は2。該当しない場合は1。

SUBSTR関数を使用している

POSITION関数を使用している

後方削除更新をしている

L：SQLの実行対象となる圧縮表が格納されているRDエリアのページ長

複数のRDエリアが対象になる場合は，最大のページ長で計算する。

注※

SQLの実行対象となる全圧縮列の中で最大になる値で計算します。

15.1.7　SQL前処理時に必要なメモリ所要量の計算式

(1)　ストアドプロシジャを使用しない場合に必要なメモリ所要量の求め方

ストアドプロシジャを使用しない場合，SQL前処理時に確保するメモリサイズは，次に示す計算式で求められます。

計算式

↑｛
　　2586＋Si×60＋Pi×20＋Ti×1424＋Ci×Ti×72＋Wi×776＋Ti×Wi×72
　　＋Ki×276＋Ki×Ti×72＋Li×3＋Li×Ti＋Di×Ti×134＋Ari×108
　　＋Gi×44＋Sli×40＋Upi×110＋Fi×90＋ Ti×Cwi×48
　　＋MAX（Pi，Wpi）×60
　｝×1.2 ÷1024↑
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（単位：キロバイト）

Si：SQL文中の検索項目数

Pi：SQL文中の埋込み変数，？パラメタ又はSQLパラメタの数

Ti：SQL文中の表名の数

Ci：SQL文中の列名の数

Wi：SQL文中の論理演算子（AND及びOR）に出てくる述語の数

Ki：SQL文中の定数の数

Li：SQL文中の定数の長さの合計（単位：バイト）

Di：SQL文中に定義された格納条件の総数

Ari：SQL文中の四則演算及び連結演算の数

Gi：SQL文中のGROUP BY句に指定した列の数

Ori：SQL文中のORDER BY句に指定した列指定又はソート項目指定番号の数

Fi：SQL文中の集合関数及びスカラ関数の総数

Sli：SQL文中の問合せ指定の数

Upi：SQL文中の更新列数

Cwi：SQL文中のCASE式中のWHENの数

Wpi：SQL文中のWITH句に対応する変数の数

注

SELECT_APSLが適用されている場合は，前記の計算式で求めた値を３倍してください。

SELECT_APSLが適用されているかどうかについては，アクセスパス表示ユティリティ（pdvwopt）を使用すると分かります。アクセスパス表示ユティリティ（pdvwopt）については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

(2)　ストアドプロシジャを使用する場合に必要なメモリ所要量の求め方

ストアドプロシジャを使用する場合，SQL前処理時に確保するメモリサイズ（単位：キロバイト）は，「ストアドプロシジャを使用しない場合に必要なメモリ所要量の求め方」の計算式で求めた値に，ストアドプロシジャごとのプロシジャ制御用オブジェクト長を加算します。プロシジャ制御用オブジェクト長の計算式については，システム共通定義のpd_sql_object_cache_sizeオペランドの1ストアドプロシジャのプロシジャ制御用オブジェクト長を参照してください。1ストアドプロシジャのプロシジャ制御用オブジェクト長については，マニュアル「HiRDB システム定義」の「1ルーチンのルーチン制御用オブジェクト長の計算式」を参照してください。

15.1.8　BLOB型データの検索又は更新時に必要なメモリ所要量の計算式（HiRDB/シングルサーバの場合）

BLOB型データの検索又は更新時に必要なメモリ所要量は次に示す計算式で求められます。

計算式

ａ＋ｂ＋17　　　（単位：キロバイト）

ａ：1SQL文中に指定するBLOB型入力変数又は出力変数で，実行するSQL文の中で次に示す計算式の結果が最大となる値です。

↑｛
 c
Σ（BLOB型入力変数iの実長※１＋118）＋
i=1
 d
Σ（BLOB型出力変数jの定義長※２＋86）
j=1
｝÷1024↑

注※１

埋込み変数でUAPからHiRDBサーバに受け渡されたBLOB型データの実際の長さです。

注※２

HiRDBからUAPに返すBLOB型データを受け取るUAPの埋込み変数の宣言長です。INSERT−SELECT文の場合は，SELECT側で射影するBLOB列を出力変数とみなします。

ｂ：同時オープン中のカーソルで結合検索を行うSQL文の組み合わせで，次に示す計算式の結果が最大となる値です。

↑｛
 e
Σ｛
i=1
 d
Σ（BLOB型出力変数jの定義長＋18）｝
j=1
｝÷1024↑

ｃ：入力変数の数

ｄ：出力変数の数

ｅ：同時オープン中のカーソル数

15.1.9　ブロック転送又は配列FETCHで必要なメモリ所要量の計算式

ブロック転送又は配列FETCHで必要なメモリ所要量は，次の計算式で求められます。

条件 | PDBLKBUFFSIZEオペランドの指定値
省略又は0 | 1以上
FETCH文のINTO句に配列型の埋込み変数を指定する | 計算式1
FETCH文のINTO句に配列型の埋込み変数を指定しない | PDBLKFオペランドを省略又は1 | − | 計算式2
PDBLKFオペランドが2以上 | 計算式1

（凡例）−：該当しません。

計算式1

↑｛864＋16×ａ＋（6×ａ＋2×d＋ｂ）×ｃ｝÷1024↑
　　　　　　　　　　　　　　　　　　　　　　　　　　（単位：キロバイト）

ａ：SELECT句で指定する検索項目数

ｂ：FETCH文で受け取る検索結果中の1行のデータ長（各列の最大長の合計。単位はバイト）

ｃ：PDBLKFオペランドの指定値又は配列数

ｄ：SELECT句で指定する検索項目で，BINARY型を指定した選択式の数

計算式2

MAX（X₁，X₂）
　　　　　　　　　　　　　　　　　　　　　　　　　　（単位：キロバイト）

X₁：↑（864＋22×a＋2×c＋b）÷1024↑

X₂：PDBLKBUFFSIZEオペランドの値

ａ：SELECT句で指定する検索項目数

ｂ：FETCH文で受け取る検索結果中の1行のデータ長（実際に取得する各列の長さの合計。単位はバイト）

ｃ：SELECT句で指定する検索項目で，BINARY型を指定した選択式の数

15.1.10　インメモリデータ処理で必要なメモリ所要量

インメモリデータ処理で必要なメモリ所要量は次に示す計算式で求められます。

計算式

●インメモリデータバッファが使用する共用メモリを実メモリ上に固定しない場合
計算式１＋D×2　　（単位：キロバイト）
●インメモリデータバッファが使用する共用メモリを実メモリ上に固定する場合
計算式１＋D×↑（↑2048÷p↑×p）÷1024↑　　（単位：キロバイト）

計算式1

●インメモリデータバッファが使用する共用メモリを実メモリ上に固定しない場合
n
Σ　↑｛736＋32×A＋48＋448×B＋2048＋C×B｝÷1024↑　　（単位：キロバイト）
i=1
●インメモリデータバッファが使用する共用メモリを実メモリ上に固定する場合
n
Σ　↑{↑（736＋32×A＋48＋448×B＋2048＋C×B）÷p↑×p｝÷1024↑　　（単位：キロバイト）
i=1

n：インメモリRDエリアの数

A：インメモリRDエリアを構成するHiRDBファイル数

B：インメモリRDエリアの総ページ数

C：インメモリRDエリアのページサイズ

D：計算式2の値

p：WindowsのLarge Pageでのページサイズ

　pdntenvコマンドで確認できます。

計算式2（インメモリデータバッファが使用する共用メモリセグメント数）

↑計算式１の値÷（SHMMAXオペランドの値×1024）↑

計算式2は1RDエリア当たりの計算式です。インメモリRDエリアの数だけ計算してください。

計算式2で求めた値は，pd_max_resident_rdarea_shm_noオペランドの見積もりに使います。

15.2　HiRDB/パラレルサーバのメモリ所要量の見積もり

ここでは，HiRDB/パラレルサーバを構成する各ユニットのメモリ所要量の見積もり方法について説明します。ここで説明する項目を次に示します。

メモリ配置

メモリ所要量の計算式

ユニットコントローラが使用する共用メモリの計算式

各サーバが使用する共用メモリの計算式

グローバルバッファが使用する共用メモリの計算式

SQL実行時に必要なメモリ所要量の計算式

SQL前処理時に必要なメモリ所要量の計算式

BLOB型データの検索又は更新時に必要なメモリ所要量の計算式（フロントエンドサーバの場合）

ブロック転送又は配列FETCHで必要なメモリ所要量の計算式（フロントエンドサーバの場合）

BLOB型データの検索又は更新時に必要なメモリ所要量の計算式（バックエンドサーバ又はディクショナリサーバの場合）

15.2.1　メモリ配置

HiRDB/パラレルサーバの各ユニットのメモリ配置を次の図に示します。

図15‒2　HiRDB/パラレルサーバの各ユニットのメモリ配置

[picture]

HiRDB/パラレルサーバの各ユニットの共用メモリの詳細を次の表に示します。

表15‒6　HiRDB/パラレルサーバの各ユニットの共用メモリの詳細

項目 | 共用メモリの種類
ユニットコントローラ用共用メモリ | グローバルバッファ用共用メモリ | ユティリティ用共用メモリ | セキュリティ監査情報用バッファ用共用メモリ | プロセス間メモリ通信用共用メモリ | トラブルシュート情報取得用共用メモリ
使用目的 | システム制御 | グローバルバッファ | ユニットコントローラとユティリティとの通信 | セキュリティ監査情報用バッファ | クライアント—サーバプロセス間メモリ通信 | トラブルシュート情報取得
使用プロセス | 全HiRDBプロセス | バックエンドサーバ，ディクショナリサーバ | ユティリティプロセス | フロントエンドサーバ | フロントエンドサーバ，クライアントプロセス | 全HiRDBプロセス

セグメント数

1個

グローバルバッファの動的変更機能を使用しない場合

1〜512個※１

グローバルバッファの動的変更機能を使用している場合

32ビットモード：

1〜1,012個※１

64ビットモード

：1〜1,512個※１

1個

1個

環境変数PDIPC=MEMORYで接続中のクライアント数（0〜2000）×2個

1個

1セグメントの上限 | 表「HiRDB/パラレルサーバの各ユニットが使用するメモリ所要量」を参照してください。ただし，OSの環境によっては確保できない場合があります。 | SHMMAXオペランドの値でセグメントを分割します。ただし，OSの環境によっては確保できない場合があります。 | 表「HiRDB/パラレルサーバの各ユニットが使用するメモリ所要量」を参照してください。ただし，OSの環境によっては確保できない場合があります。 | 表「HiRDB/パラレルサーバの各ユニットが使用するメモリ所要量」を参照してください。ただし，OSの環境によっては確保できない場合があります。 | 表「HiRDB/パラレルサーバの各ユニットが使用するメモリ所要量」を参照してください。ただし，OSの環境によっては確保できない場合があります。 | 10メガバイト
確保条件 | なし | グローバルバッファ定義が存在すること | pd_utl_exec_mode=1指定 | pd_aud_file_nameオペランドによる監査証跡ファイル用のHiRDBファイルシステム領域名の指定 | クライアント環境変数PDIPC=MEMORYで接続中クライアントあり | なし
作成契機 | ユニット起動時（ユーザサーバホットスタンバイ又は高速系切り替え機能使用時の待機ユニットの起動を含む） | サーバ起動時（高速系切り替え機能使用時の待機ユニットの起動を含む） pdbufmod -k {add｜upd}実行時 | ユティリティ実行時 | フロントエンドサーバ起動時 | クライアントとサーバの接続時 | ユニット起動時（ユーザサーバホットスタンバイ又は高速系切り替え機能使用時の待機ユニットの起動を含む）
削除契機 | 次回ユニット起動時（ユーザサーバホットスタンバイ又は高速系切り替え機能使用時の待機ユニットの起動を含む） | pdbufmod -k del実行時 正常終了又は計画停止の場合：サーバ終了時 強制停止，異常終了，又は高速系切り替え機能使用時の待機ユニットの停止の場合：次回ユニット起動時 | ユティリティ終了後10分後 | フロントエンドサーバ終了時 | クライアントとサーバの接続切り離し時 | ユニット停止時
pdls -d memによる表示 | 表示される | 表示される | 表示される | 表示される | 表示されない | 表示されない
pdls -d memのSHM-OWNER | MANAGER | サーバ名 | UTILITY | AUDDEF | 表示なし | 表示なし
関連オペランド | pd_dic_shmpool_size pd_bes_shmpool_size | pd_dbbuff_modify pdbuffer SHMMAX | pd_utl_exec_mode | セキュリティ監査機能に関するオペランド※２ | PDIPC PDSENDMEMSIZE PDRECVMEMSIZE | pd_prf_trace
備考 | − | − | pd_utl_exec_mode=1の場合だけ作成されます（pd_utl_exec_mode=0の場合，該当する領域はユニットコントローラ用共用メモリ内に確保されます）。 | − | − | −

（凡例）−：該当しません。

注※１

グローバルバッファ割り当てバックエンドサーバ又はディクショナリサーバ当たりの数です。

注※２

詳細はマニュアル「HiRDB システム定義」を参照してください。

15.2.2　メモリ所要量の計算式

HiRDB/パラレルサーバの各ユニットが使用するメモリ所要量は，次の表に示すすべての項目を加算した値です。

共用メモリサイズが増加すると，ページフォルトの発生回数が増加し，トランザクション性能に影響を与えるおそれがあります。各オペランドの指定値の目安を参照し，システムに合わせて適切な値を指定することを検討してください。

表15‒7　HiRDB/パラレルサーバの各ユニットが使用するメモリ所要量

項目 | メモリ所要量（単位：キロバイト）

プロセス固有領域

ユニットコントローラ全プロセスが使用するプロセス固有領域

●32ビットモードの場合

J＋K×ユニット内FES数＋L×（ユニット内BES数＋ユニット内DS数）＋↑｛（64＋48×（v＋1））×（pd_max_server_processの値−w−3）＋（64＋48×（ab＋1））×3＋z｝÷1024↑

●64ビットモードの場合

J＋K×ユニット内FES数＋L×（ユニット内BES数＋ユニット内DS数）＋↑｛（64＋64×（v＋1））×（pd_max_server_processの値−w−3）＋（64＋64×（ab＋1））×3＋z｝÷1024↑

●プラグインを使用する場合，加算します。

＋1400

●pd_max_ard_processオペランドが1以上の場合，加算します。

＋s

●pd_process_terminatorオペランドにfixedを指定した場合，加算します。

＋M×（pd_process_terminator_maxの値−1）

●インメモリデータ処理を行う場合，加算します。

＋↑｛T×（pd_max_bes_processの値×2＋7）×ユニット内BES数｝÷1024↑

●通信トレース格納最大数を変更する場合，加算します。

＋↑V÷1024↑

●通信暗号化機能を適用する場合，加算します。

＋af＋ag×クライアント同時接続発生数※6

各サーバプロセスが使用するプロセス固有領域※１ ※２

フロントエンドサーバ

（N＋h＋m＋p＋q＋ac）×b＋y

●通信トレース格納最大数を変更する場合，加算します。

＋↑W÷1024↑

●通信暗号化機能を適用する場合，加算します。

＋ah×(b＋3)

ディクショナリサーバ | pd_work_buff_mode=each指定時 | ｛P＋i＋m＋（a＋9）×2＋r＋t｝×b＋y＋S ●通信トレース格納最大数を変更する場合，加算します。 ＋↑W÷1024↑

pd_work_buff_mode=pool指定又は省略時

●32ビットモードの場合

（P＋i＋m＋a＋↑a÷128×0.1↑＋11＋n＋r＋t）×b＋y＋S

●64ビットモードの場合

（P＋i＋m＋a＋↑a÷128×0.1↑＋15＋n＋r＋t）×b＋y＋S

●通信トレース格納最大数を変更する場合，加算します。

＋↑W÷1024↑

pd_work_buff_mode=pool2指定

●32ビットモードの場合

（P＋i＋m＋↑a÷128×0.1↑＋11＋n＋r＋t）×b＋y＋S＋(a×ad)

●64ビットモードの場合

（P＋i＋m＋↑a÷128×0.1↑＋15＋n＋r＋t）×b＋y＋S＋(a×ad)

●通信トレース格納最大数を変更する場合，加算します。

＋↑W÷1024↑

バックエンドサーバ

pd_work_buff_mode=each指定時

｛Q＋g＋（a＋9）×c＋i＋m＋r＋t｝

×（b＋3）＋y＋S

●インメモリデータ処理を行う場合，加算します。

＋↑｛T×（b＋3）｝÷1024↑

●通信トレース格納最大数を変更する場合，加算します。

＋↑W÷1024↑

pd_work_buff_mode=pool指定又は省略時

●32ビットモードの場合

（Q＋g＋a＋↑a÷128×0.1↑＋11＋i＋m＋n＋r＋t）×（b＋3）＋y＋S

●64ビットモードの場合

（Q＋g＋a＋↑a÷128×0.1↑＋15＋i＋m＋n＋r＋t）×（b＋3）＋y＋S

●インメモリデータ処理を行う場合，加算します。

＋↑｛T×（b＋3）｝÷1024↑

●通信トレース格納最大数を変更する場合，加算します。

＋↑W÷1024↑

pd_work_buff_mode=pool2指定

●32ビットモードの場合

（Q＋g＋↑a÷128×0.1↑＋11＋i＋m＋n＋r＋t）×（b×3）＋y＋S＋(a×ad)

●64ビットモードの場合

（Q＋g＋↑a÷128×0.1↑＋15＋i＋m＋n＋r＋t）×（b×3）＋y＋S＋(a×ad)

●インメモリデータ処理を行う場合，加算します。

＋↑｛T×（b＋3）｝÷1024↑

●通信トレース格納最大数を変更する場合，加算します。

＋↑W÷1024↑

共用メモリ | ユニットコントローラ用共用メモリ中，ユニットコントローラが使用する領域 | ↑d÷1024↑
ユニットコントローラ用共用メモリ中，各サーバが使用する領域※１ | e
グローバルバッファ用共用メモリ | f
インメモリデータ処理用共用メモリ | U
ユティリティ用共用メモリ | u

セキュリティ監査情報用バッファ用共用メモリ

●システムによる自動計算の場合

↑0.3＋MAX｛（R＋100），（R×1.2）｝×0.25↑

●ユーザ指定値（pd_audit_def_buffer_sizeオペランドを指定）にする場合

pd_audit_def_buffer_sizeの指定値

プロセス間メモリ通信用共用メモリ※３ | j×k

OSの領域※４

PTEの領域※５

●共用メモリのページ固定をしていない場合

（↑プロセス固有領域の合計サイズ÷510↑＋pd_max_server_processの値×16＋13）＋｛（↑共用メモリの合計サイズ÷510↑＋17）×pd_max_server_processの値｝

●共用メモリのページ固定をしている場合

（↑プロセス固有領域の合計サイズ÷510↑＋pd_max_server_processの値×16＋13）＋｛（↑共用メモリの合計サイズ÷261120↑＋13）×pd_max_server_processの値｝

注※１

ユニット内に複数のサーバ（システムマネジャを除きます）がある場合は，サーバごとに計算した値をすべて加算してください。

ただし，影響分散スタンバイレス型系切り替えの対象となるユニットの場合は，次の手順で求めた値を，ユニット内の全バックエンドサーバのメモリ所要量として加算してください。

ユニット内のホストBES及びゲストBESとして受け入れ可能なBESごとに，計算式中の最大BESプロセス数（変数b，及び，変数yと変数Wで使用する最大起動プロセス数）を，ユニット内の最大プロセス数（pd_ha_max_server_process）に置き換えて計算した値を求めます。

1で求めた中で最大の値を加算してください。

注※２

プラグインを使用する場合は，1サーバプロセス当たり300を加算してください。

注※３

クライアント環境定義でPDIPC=MEMORYを指定した場合に加算します。プロセス間メモリ通信機能及びクライアント環境定義については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

なお，HiRDBサーバ又はHiRDBクライアントのどちらかが32ビットモードの場合，プロセス間メモリ通信機能で使用する共用メモリは32ビット空間内に確保されます。

注※４

OSが使用する領域の詳細は公開されていないため，あくまでHiRDBが確保するメモリ所要量を基にした目安です。実際の値とは大きく異なる場合があるので，正確な値については実際の環境で測定してください。

注※５

PTEについては，「システム設計」を参照してください。

注※６

HiRDBに対してクライアントが接続を同時に要求する最大数です。

例えば，ある時刻に10個のクライアントを起動し，そのあとの時刻にさらに5個のクライアントを起動する場合，同時に要求する最大数は10となります。

ａ：pd_work_buff_sizeオペランドの値

ｂ：次のうちのどれかの値

ディクショナリサーバの場合は，pd_max_dic_processオペランドの値となります。

バックエンドサーバの場合は，次の値となります。

影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

メモリ所要量を計算するユニットのpd_ha_max_server_processオペランドの値

上記以外のユニットの場合：

pd_max_bes_processオペランドの値

pd_max_dic_process又はpd_max_bes_processオペランドを省略する場合は，pd_max_usersオペランドの値となります。

ｃ：最大作業表数

SQL文ごとの作業表数を表「SQL文ごとの作業表数の求め方」から求めます。表「SQL文ごとの作業表数の求め方」から求めた作業表数のうちで最大のものを最大作業表数とします。

ｄ：「ユニットコントローラが使用する共用メモリの計算式」で求めた値

ｅ：「各サーバが使用する共用メモリの計算式」で求めた値

ｆ：「グローバルバッファが使用する共用メモリの計算式」で求めた値

ｇ：SQL実行時に必要なメモリ所要量

計算式については，「SQL実行時に必要なメモリ所要量の計算式」を参照してください。

ｈ：SQL前処理時に必要なメモリ所要量

計算式については，「SQL前処理時に必要なメモリ所要量の計算式」を参照してください。

ｉ：LOBバッファ一括入出力ワークメモリ

該当するサーバのLOB用RDエリアにLOB用グローバルバッファを指定している場合だけ（システム共通定義のpdbufferオペランドに-bを指定している場合），62キロバイトを加算してください。

ｊ：プロセス間メモリ通信機能を使用するクライアントの最大同時実行数

分からない場合は，プロセス間メモリ通信機能を使用する全クライアント数，又はpd_max_usersオペランドの値を代入してください。

ｋ：プロセス間メモリ通信機能を使用する全クライアントのデータ送受信用メモリサイズ（クライアント環境定義のPDSENDMEMSIZEの値＋PDRECVMEMSIZEの値）の平均値

ｍ：Java仮想マシンが使用するメモリ所要量

Javaストアドプロシジャ又はJavaストアドファンクションを使用する場合に，Java仮想マシンが使用するメモリ所要量を加算します。Java仮想マシンが使用するメモリ所要量は，Java仮想マシンのオプションやJava仮想マシンのバージョンによって異なります。Java仮想マシンが使用するメモリ所要量については，Java仮想マシンのマニュアルを参照してください。

ｎ：作業表用増分メモリサイズ

pd_work_buff_expand_limitオペランドを指定する場合に作業表用増分メモリサイズを加算します。作業表用増分メモリサイズは次に示す計算式から求めます。

作業表用増分メモリサイズ（キロバイト）＝作業表用増分バッファサイズ＋↑（作業表用の増分バッファサイズ÷128）×0.1↑

作業表用増分バッファサイズ（キロバイト）＝MAX（0，ハッシュジョイン，副問合せのハッシュ実行による作業表用増分バッファサイズ）＋MAX（0，作業表数の増加による作業表用増分バッファサイズ）

ハッシュジョイン，副問合せのハッシュ実行による作業表用増分バッファサイズ＝MIN｛（ハッシュジョイン，副問合せのハッシュ実行をするときの作業表用バッファサイズ−pd_work_buff_sizeオペランドの値），（pd_work_buff_expand_limitオペランドの値−pd_work_buff_sizeオペランドの値）｝×ハッシュジョイン，副問合せのハッシュ実行をする同時実行ユーザ数

ハッシュジョイン，副問合せのハッシュ実行をするときの作業表用バッファサイズの求め方については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

作業表数の増加による作業表用増分バッファサイズ＝MIN｛（使用作業表数×128−pd_work_buff_sizeオペランドの値），（pd_work_buff_expand_limitオペランドの値−pd_work_buff_sizeオペランドの値）｝×（使用作業表数がpd_work_buff_sizeオペランドの値÷128以上になるユーザ数）

使用作業表数＝MAX（1SQL文が使用する作業表用ファイルの数，ASSIGN LIST文が使用する作業表用ファイルの数）

1SQL文が使用する作業表用ファイルの数，及びASSIGN LIST文が使用する作業表用ファイルの数の求め方については，「最大ファイル数の見積もり（pdfmkfs -lコマンド）」を参照してください。

ｐ：BLOB型データ用に必要なメモリ所要量

計算式については，「BLOB型データの検索又は更新時に必要なメモリ所要量の計算式（フロントエンドサーバの場合）」を参照してください。

ｑ：サーバ側でブロック転送又は配列FETCHで必要なメモリ所要量

計算式については，「ブロック転送又は配列FETCHで必要なメモリ所要量の計算式（フロントエンドサーバの場合）」を参照してください。

ｒ：BLOB型データ用に必要なメモリ所要量

計算式については，「BLOB型データの検索又は更新時に必要なメモリ所要量の計算式（バックエンドサーバ又はディクショナリサーバの場合）」を参照してください。

ｓ：非同期READ用メモリサイズ

pd_max_ard_processオペランドが1以上の場合に加算します。次に示す計算式から求めます（単位：キロバイト）。

（90＋
90
Σ RDエリア用HiRDBファイルシステム領域管理用メモリ）
i=1
×pd_max_ard_processの値

RDエリア用HiRDBファイルシステム領域管理用メモリは計算値の大きい順に90領域を計算に使用します。サーバで使用する領域数が90領域に満たない場合，その領域まで計算します。

HiRDBファイルシステム領域管理用メモリはそれぞれの領域の初期設定時のパラメタを使用して，次の計算式から求めます（単位：キロバイト）。

なお，領域の初期設定時のパラメタはpdfstatfsコマンドに-Aオプションを指定して実行することで確認できます。

｛（ファイル数※１＋増分数※２）÷64｝×1.5※３

注※1　pdfmkfs -l指定値，又はpdfstatfs実行結果の[available file count]に表示される値です。

注※2　pdfmkfs -e指定値，又はpdfstatfs実行結果の[available expand count]に表示される値です。

注※3　領域サイズ（pdfmkfs -n指定値）が2048以上の場合に乗算します。

ｔ：HiRDBファイルシステム用メモリサイズ

次に示す計算式から求めます（単位：キロバイト）。

604＋作業表用HiRDBファイルシステム領域管理用メモリ＋
システムログ用HiRDBファイルシステム領域管理用メモリ＋
90
ΣRDエリア用HiRDBファイルシステム領域管理用メモリ
i=1

作業表用及びシステムログ用HiRDBファイルシステム領域管理用メモリは，サーバで使用するHiRDBファイルシステム領域で計算値が最大になるものを使用します。RDエリアの場合は計算値の大きい順に90領域を計算に使用します。サーバで使用する領域数が90領域に満たない場合，その領域まで計算します。

HiRDBファイルシステム領域管理用メモリはそれぞれの領域の初期設定時のパラメタを使用して，次の計算式から求めます（単位：キロバイト）。

なお，領域の初期設定時のパラメタはpdfstatfsコマンドに-Aオプションを指定して実行することで確認できます。

｛（ファイル数※１＋増分数※２）÷64｝×1.5※３

注※1　pdfmkfs -l指定値，又はpdfstatfs実行結果の[available file count]に表示される値です。

注※2　pdfmkfs -e指定値，又はpdfstatfs実行結果の[available expand count]に表示される値です。

注※3　領域サイズ（pdfmkfs -n指定値）が2048以上の場合に乗算します。

ｕ：pd_utl_exec_modeの値が0の場合：0

pd_utl_exec_modeの値が1の場合：b×201

ｖ：ユニット制御情報定義として有効なpd_module_trace_maxの値

ｗ：ユニット内の全サーバプロセスに対して，（最大起動プロセス数＋3）を合計した値

最大起動プロセス数については，マニュアル「HiRDB システム定義」を参照してください。

ｙ：ユニット内の各サーバプロセスに対して次の計算式で求めた値の総和

32ビットモードの場合：

↑｛（64＋48×（pd_module_trace_maxの値＋1））×（最大起動プロセス数＋3）｝÷1024↑

64ビットモードの場合：

↑｛（64＋64×（pd_module_trace_maxの値＋1））×（最大起動プロセス数＋3）｝÷1024↑

最大起動プロセス数については，マニュアル「HiRDB システム定義」を参照してください。

なお，影響分散スタンバイレス型系切り替えの対象となるユニットの場合，「最大起動プロセス数」は，メモリ所要量を計算するユニットの「pd_ha_max_server_processオペランドの値」に置き換えてください。

ｚ：HiRDBの再開始用メモリサイズ

このメモリサイズを確保できないと，HiRDBの再開始に失敗します。次の計算式から求めます（単位：バイト）。

（D＋E＋F）×ディクショナリサーバ数＋（D＋E＋F）×バックエンドサーバ数＋ΣH

HiRDBの再開始用メモリサイズを求める計算に使用する変数を次に示します。

変数 | 値

D

●32ビットモードの場合

246762＋4×pd_max_rdarea_noの値

＋｛48×（pd_max_rdarea_noの値＋表数）＋304｝×（pd_max_usersの値※×2＋7）

●64ビットモードの場合

305274＋8×pd_max_rdarea_noの値

＋｛64×（pd_max_rdarea_noの値＋表数）＋512｝×（pd_max_usersの値※×2＋7）

表数：62＋MAX｛pd_max_access_tablesの値，500｝

E

b1×X＋b2×Y

b1：サーバ用ステータスファイルのレコード長＜4096の場合

　　　MAX（（↓（3400÷（（↓（（レコード長−40）−308）÷20↓）

　　　＋（↓（レコード長−40）÷20↓）×（MAX（↓4096÷レコード長↓，2）−1））

　　　＋0.7）↓），1）×MAX(↓4096÷レコード長↓，2）×（レコード長−40）

　　4096≦サーバ用ステータスファイルのレコード長＜12288の場合

　　　MAX（↓（3400÷（↓（（（レコード長−40）−308）÷20）↓）＋0.7）↓，1）

　　　×（レコード長−40）

　　12288≦サーバ用ステータスファイルのレコード長の場合

　　　MAX（↓（3400÷（↓（（（レコード長−40）−836）÷20）↓）＋0.7）↓，1）

　　　×（レコード長−40）

Ｘ：サーバ内のRDエリア数≦3400の場合：1

　　3401≦サーバ内のRDエリア数≦6800の場合：2

　　6801≦サーバ内のRDエリア数の場合：3

b2：サーバ用ステータスファイルのレコード長＜4096の場合

　　　（↓（5662310÷（（↓（（レコード長−40）−308）÷20↓）

　　　＋（↓（レコード長−40）÷20↓）×（MAX（↓4096÷レコード長↓，2）−1））

　　　＋0.7）↓）×MAX（↓4096÷レコード長↓，2）×（レコード長−40）

　　4096≦サーバ用ステータスファイルのレコード長＜12288の場合

　　　↓（5662310÷（↓（（（レコード長−40）−308）÷20）↓）＋0.7）↓

　　　×（レコード長−40）

　　12288≦サーバ用ステータスファイルのレコード長の場合

　　　↓（5662310÷（↓（（（レコード長−40）−836）÷20）↓）＋0.7）↓

　　　×（レコード長−40）

Ｙ：サーバ内のRDエリア数≦10200の場合：0

　　10201≦サーバ内のRDエリア数≦5672510の場合：1

　　5672511≦サーバ内のRDエリア数≦11334820の場合：2

　　11334821≦サーバ内のRDエリア数の場合：3

F | pd_dbsync_pointオペランドにcommitを指定している場合，加算します。 ＋112×（pd_max_usersの値※×2＋7）

H

サーバ内のraw I/O機能を使用したHiRDBファイルシステム領域に作成されたRDエリアを格納したHiRDBファイルシステム領域数が1001以上のバックエンドサーバに対して加算します。

●32ビットモードの場合

12012×（↑（raw I/O機能を使用したHiRDBファイルシステム領域に作成されたRDエリアを格納したHiRDBファイルシステム領域数−1000）÷1000↑）

●64ビットモードの場合

16016×（↑（raw I/O機能を使用したHiRDBファイルシステム領域に作成されたRDエリアを格納したHiRDBファイルシステム領域数−1000）÷1000↑）

注※

ディクショナリサーバの場合はpd_max_dic_processの値となります。バックエンドサーバの場合はpd_max_bes_processの値となります。ただし，pd_max_dic_process又はpd_max_bes_processを省略する場合は，pd_max_usersの値となります。

Ｊ，Ｋ，Ｌ，Ｍ，Ｎ，Ｐ，Ｑ：固定値

この値はOSによって異なります。OSごとの値を次に示します（単位：キロバイト）。

OS | Jの値 | Kの値 | Lの値 | Mの値 | Nの値 | Pの値 | Qの値
Windows (x64) | 170,300 | 39,200 | 52,500 | 13,000 | 13,400 | 14,500 | 14,600

Ｒ：余裕を持って見積もる場合は監査対象イベントの数（CREATE AUDITの実行回数），詳細に見積もる場合はセキュリティ監査情報用バッファのエントリ数

Ｓ：シンクポイント出力同期制御情報取得機能使用時に必要なメモリ（単位：バイト）

pd_dbbuff_trace_levelオペランドに1を指定し，かつpd_dfw_awt_processオペランドの指定を省略している場合に，次の値を加算します。

32ビットモードの場合：

320×シングルサーバに定義したグローバルバッファの数

64ビットモードの場合：

640×シングルサーバに定義したグローバルバッファの数

Ｔ：pd_max_resident_rdarea_noオペランドに1以上を指定している場合に，次の値を加算します。

1648＋16×pd_max_resident_rdarea_noの値＋16×pd_max_resident_rdarea_shm_noの値

Ｕ：インメモリデータ処理で必要なメモリ所要量

計算式については，「インメモリデータ処理で必要なメモリ所要量」を参照してください。

Ｖ：通信トレース処理で必要なメモリ所要量

32ビットモードの場合：

（16×（Z−1024）×2）×（pd_max_server_processの値−w）

64ビットモードの場合：

（32×（Z−1024）×2）×（pd_max_server_processの値−w）

W：通信トレース処理で必要なメモリ所要量

ユニット内の各サーバプロセスについて算出した次の値です。

32ビットモードの場合：

（16×（aa−1024）×2）×（最大起動プロセス数＋3）

64ビットモードの場合：

（32×（aa−1024）×2）×（最大起動プロセス数＋3）

最大起動プロセス数については，マニュアル「HiRDB システム定義」を参照してください。

なお，影響分散スタンバイレス型系切り替えの対象となるユニットの場合，「最大起動プロセス数」は，メモリ所要量を計算するユニットの「pd_ha_max_server_processオペランドの値」に置き換えてください。

Ｚ：ユニット制御情報定義として有効なpd_pth_trace_maxの値です。

オペランドの指定値を2のべき乗に切り上げた値になります。

ａａ：各サーバ定義として有効なpd_pth_trace_maxの値です。

オペランドの指定値を2のべき乗に切り上げた値になります。

ａｂ：システム共通定義，又はユニット制御情報定義にpd_module_trace_maxオペランドを指定している場合：pd_module_trace_maxの値

それ以外の場合：16383

ａｃ：フロントエンドサーバで使用するSQL実行用通信メモリ所要量

4×システム内BES数

ａd： 作業表を使用する操作（SQL又はユティリティ）を行うトランザクションの同時実行数

ａｆ，ａｇ，ａｈ：固定値

この値はOSによって異なります。OSごとの値を次に示します（単位：キロバイト）。

OS | afの値 | agの値 | ahの値
Windows (x64) | 1080 | 110 | 1050

表15‒8　SQL文ごとの作業表数の求め方

SQL文 | 作業表数の求め方

SELECT文

INSERT（-SELECT）文

1.〜8. の指定がない場合：0

1.〜8. の指定がある場合：該当する作業表数をすべて加算した値

複数の表を結合して検索する場合

増加作業表数＝（結合表数−1）×2＋1

ORDER BY句を指定する場合

増加作業表数＝2

GROUP BY句を指定する場合

増加作業表数＝GROUP BY句指定数

DISTINCT句を指定する場合

増加作業表数＝DISTINCT句指定数

UNION句，UNION ALL句又はEXCEPT[ALL]句を指定する場合

増加作業表数＝（UNION又はUNION ALL句指定数）×2＋1

探索条件中にインデクスを定義した列がある場合

増加作業表数＝探索条件中のインデクスを定義した列数

FOR UPDATE句又はFOR READ ONLY句を指定する場合

増加作業表数＝1

副問合せ（限定述語）を指定する場合

増加作業表数＝副問合せ指定数

UPDATE文 DELETE文 | 探索条件中のインデクスを定義した列数＋1

DROP SCHEMA文

DROP TABLE文

DROP INDEX文

CREATE INDEX文

REVOKE文でアクセス権限を取り消す場合

2

15.2.3　ユニットコントローラが使用する共用メモリの計算式

(1)　32ビットモードの場合

ユニットの開始から終了までの間にユニットコントローラが使用する共用メモリは，次に示すHiRDBのプロセスの項目すべてを加算した値です。

なお，ユニットコントローラ全体の共用メモリサイズは2ギガバイト以内になるようにしてください。

プロセスの種類 | 共用メモリの計算式（単位：バイト）

スケジューラ

pd_utl_exec_modeの値が0の場合

　｛↑（432＋304×n）÷1024↑＋507＋x＋z＋↑（134＋pd_trn_rcvmsg_store_buflenの値）÷1024↑｝×1024

pd_utl_exec_modeの値が1の場合

　｛↑（432＋304×n）÷1024↑＋y＋z＋↑（134＋pd_trn_rcvmsg_store_buflenの値）÷1024↑｝×1024

ｘ：ユニット内にMGRがある場合：37

ユニット内にFESがある場合：57＋1×（s＋3）＋14

ユニット内にDSがある場合：102＋5×（t＋3）＋14

ユニット内にBESがある場合：｛192＋9×（u＋3）＋14｝×（BES数＋β＋γ）

ｙ：ユニット内にMGRがある場合：0

ユニット内にFESがある場合：1×（s＋3）＋14

ユニット内にDSがある場合：5×（t＋3）＋14

ユニット内にBESがある場合：｛9×（u＋3）＋14｝×（BES数＋β＋γ）

ｚ：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

↑64＋｛（ユニット内BES数＋受け入れ可能なゲストBES数※）×48｝÷1024↑

上記以外のユニットの場合：0

ｎ：ユニット内のサーバ数＋β＋γ＋ユニット内ユティリティサーバ数＋1

ユニット内ユティリティサーバ数：25＋α

α：ユニット内にMGRがある場合：3

　　ユニット内にFESがある場合：3

　　ユニット内にDSがある場合：7

　　ユニット内にBESがある場合：（BES数＋β）×15

ｓ：pd_max_usersの値

ｔ：pd_max_dic_processの値

ｕ：pd_max_bes_processの値

β：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

受け入れ可能なゲストBES数※

上記以外のユニットの場合：0

γ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：代替BES数

上記以外のユニットの場合：0

注※　pd_ha_max_guest_act_serversの値

ロックサーバ

ユニット内にサーバ（FES，BES，又はDS）がある場合

影響分散スタンバイレス型系切り替え機能の対象となるユニットで，ゲストBESについての計算をする場合に使用するサーバごとのオペランド（pd_lck_pool_size，pd_lck_pool_partition，pd_lck_hash_entry，pd_max_bes_processなど）の値は，そのゲストBESのオペランドの値ではなく，そのユニット内の全ゲストBESに指定されている値の最大値を使用します。また，影響分散スタンバイレス型系切り替え機能の対象となるユニットでは，「ユニット内サーバ」は「全ホストBES＋全ゲストBES」です。

1：1スタンバイレス型系切り替え機能の対象となるユニットでは，「ユニット内サーバ」は「全正規BES＋全代替BES」です。

y

Σ｛

x=1

　　320＋48＋cx＋dx＋48＋4096＋gx＋48＋ix

　　＋48＋12252＋48＋nx＋px＋tx＋ux＋16

　　｝×pd_lck_pool_partitionの値※

注※　FESの場合pd_fes_lck_pool_partitionの値

ｘ：ユニット内サーバ通し番号

ｙ：ユニット内サーバ数

ｃx：pd_lck_hash_entryを省略，又は0を指定している場合：

　　FESで，pd_fes_lck_pool_sizeが指定されていないとき

　　　（↓（8＋4×MAX（↑（↓↓（px＋3）×（pd_max_access_tablesの値＋4）÷6↓

　　　÷pd_fes_lck_pool_partitionの値↓×6）÷10↑の値を超えない最大の素数，11261））÷16↓＋1）×16

　　FESで，pd_fes_lck_pool_sizeが指定されているとき

　　　（↓（8＋4×MAX（↑（↓pd_fes_lck_pool_sizeの値÷pd_fes_lck_pool_partitionの値↓×6）

　　　÷10↑の値を超えない最大の素数，11261））÷16↓＋1）×16

　　BES，又はDSのとき

　　　（↓（8＋4×MAX（↑（（px＋3）×2×5＋↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×6）

　　　÷10↑の値を超えない最大の素数，11261））÷16↓＋1）×16

　　pd_lck_hash_entryに2以上の素数でない値を指定している場合：

　　（↓（8＋4×pd_lck_hash_entryの値を超えない最大の素数）÷16↓＋1）

　　×16

　　pd_lck_hash_entryに1，又は素数を指定している場合：

　　（↓（8＋4×pd_lck_hash_entryの値）÷16↓＋1）×16

ｄx：FESで，pd_fes_lck_pool_sizeが指定されていない場合：

　　　（↓↓（px＋3）×（pd_max_access_tablesの値＋4）÷6↓

　　　÷pd_fes_lck_pool_partitionの値↓×6）×96

　　FESで，pd_fes_lck_pool_sizeが指定されている場合：

　　　↓pd_fes_lck_pool_sizeの値÷pd_fes_lck_pool_partitionの値↓×6×96

　　BES，又はDSの場合：

　　　（（px＋3）×2×5＋↓pd_lck_pool_sizeの値

　　　÷pd_lck_pool_partitionの値↓×6）×96

ｇx：FESの場合：

　　　（p＋3）×2×256

　　BESで，pd_utl_exec_modeの値=1，かつs＞32の場合：

　　　（（p＋3）×2＋s）×256

　　BESで，pd_utl_exec_modeの値=0，又はs≦32の場合：

　　　（（p＋3）×2＋32）×256

　　DSで，pd_utl_exec_modeの値=1，かつs＞16の場合：

　　　（（p＋3）×2＋s）×256

　　DSで，pd_utl_exec_modeの値=0，又はs≦16の場合：

　　　（（p＋3）×2＋16）×256

ｉx：FESで，pd_fes_lck_pool_sizeが指定されていない場合：

　　　（↓↓（px＋3）×（pd_max_access_tablesの値＋4）÷6↓

　　　÷pd_fes_lck_pool_partitionの値↓）×12×64

　　FESで，pd_fes_lck_pool_sizeが指定されている場合：

　　　（↓pd_fes_lck_pool_sizeの値÷pd_fes_lck_pool_partitionの値↓×8）を偶数に切り上げた値×64

　　BESで，pd_utl_exec_modeの値=1，かつs＞32の場合：

　　　（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8

　　　＋（px＋3）×2×2×5＋s×（pd_max_rdarea_noの値＋1））

　　　を偶数に切り上げた値×64

　　BESで，pd_utl_exec_modeの値=0，又はs≦32の場合：

　　　（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8

　　　＋（px＋3）×2×2×5＋32×（pd_max_rdarea_noの値＋1））

　　　を偶数に切り上げた値×64

　　DSで，pd_utl_exec_modeの値=1，かつs＞16の場合：

　　　（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8

　　　＋（px＋3）×2×2×5＋s＋4）を偶数に切り上げた値×64

　　DSで，pd_utl_exec_modeの値=0，又はs≦16の場合：

　　　（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8

　　　＋（px＋3）×2×2×5＋20）を偶数に切り上げた値×64

ｎx：FESの場合：

　　　（px＋3）×2×48

　　BESで，pd_utl_exec_modeの値=1，かつs＞32の場合：

　　　（（px＋3）×2×17＋s）×48

　　BESで，pd_utl_exec_modeの値=0，又はs≦32の場合：

　　　（（px＋3）×2×17＋32）×48

　　DSで，pd_utl_exec_modeの値=1，かつs＞16の場合：

　　　（（px＋3）×2×17＋s）×48

　　DSで，pd_utl_exec_modeの値=0，又はs≦16の場合：

　　　（（px＋3）×2×17＋16）×48

ｐx：FESで，HiRDBシステム内のFES数＞1の場合：s＋1

　　FESで，HiRDBシステム内のFES数=1の場合：s

　　BESで，s＞pd_max_bes_processの値 の場合：s

　　BESで，s≦pd_max_bes_processの値 の場合：

　　　pd_max_bes_processオペランドの値

　　DSで，s＞pd_max_dic_processの値 の場合：s

　　DSで，s≦pd_max_dic_processの値 の場合：

　　　pd_max_dic_processオペランドの値

ｓ：pd_max_usersの値

ｔx：FESの場合：

　　　48＋（px＋3）×2×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　BESで，pd_utl_exec_modeの値=1，かつs＞32の場合：

　　　48＋（（px＋3）×2＋s）×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　BESで，pd_utl_exec_modeの値=0，又はs≦32の場合：

　　　48＋（（px＋3）×2＋32）×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　DSで，pd_utl_exec_modeの値=1，かつs＞16の場合：

　　　48＋（（px＋3）×2＋s）×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　DSで，pd_utl_exec_modeの値=0，又はs≦16の場合：

　　　48＋（（px＋3）×2＋16）×↑pd_max_open_holdable_cursorsの値÷16↑×4

ｕx：FESで，pd_fes_lck_pool_sizeが指定されていない場合：

　　　48＋（↓↓（px＋3）×（pd_max_access_tablesの値＋4）÷6↓÷pd_fes_lck_pool_partitionの値↓）×12

　　　×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　FESで，pd_fes_lck_pool_sizeが指定されている場合：

　　　48＋↓pd_fes_lck_pool_sizeの値÷pd_fes_lck_pool_partitionの値↓×8

　　　×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　BESで，pd_utl_exec_modeの値=1，かつs＞32の場合：

　　　48＋（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8

　　　＋（px＋3）×2×2×5＋s×（pd_max_rdarea_noの値＋1））

　　　を偶数に切り上げた値×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　BESで，pd_utl_exec_modeの値=0，又はs≦32の場合：

　　　48＋（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8

　　　＋（px＋3）×2×2×5＋32×（pd_max_rdarea_noの値＋1））

　　　を偶数に切り上げた値×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　DSで，pd_utl_exec_modeの値=1，かつs＞16の場合：

　　　48＋（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8

　　　＋（px＋3）×2×2×5＋s＋4）を偶数に切り上げた値

　　　×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　DSで，pd_utl_exec_modeの値=0，又はs≦16の場合：

　　　48＋（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×8

　　　＋（px＋3）×2×2×5＋20）を偶数に切り上げた値

　　　×↑pd_max_open_holdable_cursorsの値÷16↑×4

●ユニット内にサーバ（FES，BES，又はDS）がない場合

8416

トランザクションサーバ

288＋32×B＋192×s×2

ユニット内にFESがある場合に加算します※

　　＋1028＋（420＋624＋256＋384×2）×（A×2＋7）＋256×2

　　＋128×（システム内BES数×4＋システム内DS数×2

　　＋システム内FES数）×（A×2＋7）

　　＋C

ユニット内にBESがある場合に加算します※

　　＋1028＋（420＋624＋256＋384×2）

　　×（u×2＋7）＋256×2

　　＋128×（システム内BES数×4＋システム内DS数×2

　　＋システム内FES数）×（A×2＋7）

　　＋D

ユニット内にDSがある場合に加算します※

　　＋1028＋（420＋624＋256＋384×2）

　　×（t×2＋7）＋256×2

　　＋128×（システム内BES数×4＋システム内DS数×2

　　＋システム内FES数）×（A×2＋7）

　　＋E

ｓ：pd_max_usersの値

ｔ：pd_max_dic_processの値

ｕ：pd_max_bes_processの値

Ａ：マルチFESの場合：s＋1

　　マルチFESでない場合：s

Ｂ：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　ホストBES数＋pd_ha_max_act_guest_serversオペランドの補正値

　　上記以外のユニットの場合：ユニット内サーバ数

Ｃ：≪条件≫に示すどちらかの条件に一致する場合：

　　128×（システム内BES数×4＋システム内DS数×2

　　＋システム内FES数）×（A×2＋7）

　　≪条件≫に示すどちらの条件にも一致しない場合：0

Ｄ：≪条件≫に示すどちらかの条件に一致する場合：

　　128×（システム内BES数×4＋システム内DS数×2

　　＋システム内FES数）×（u×2＋7）

　　≪条件≫に示すどちらの条件にも一致しない場合：0

Ｅ：≪条件≫に示すどちらかの条件に一致する場合：

　　128×（システム内BES数×4＋システム内DS数×2

　　＋システム内FES数）×（t×2＋7）

　　≪条件≫に示すどちらの条件にも一致しない場合：0

≪条件≫

pd_rpl_reflect_modeオペランドにuapを指定している

システム内に，pdstart -k stlsオペランドを指定したフロントエンドサーバが存在する

注※　上記の計算式で算出した値を各サーバの数分だけ加算します。

1：1スタンバイレス型系切り替え適用ユニットの場合：

正規BES数＋代替BES数

上記以外の場合はユニット内サーバ数

タイマサーバ

32×（pd_max_usersの値＋3）

×（システム内のBES数＋1＋ユニット内ユティリティサーバ数＋1）

＋1440

ユニット内ユティリティサーバ数は23＋α

α：ユニット内にMGRがある場合：2

　　ユニット内にFESがある場合：3

　　ユニット内にDSがある場合：7

　　ユニット内にBESがある場合：BES数×15

統計ログサーバ | 384＋128×16＋32＋288×2＋1024＋128×3 ＋pd_stj_buff_sizeの値×1024×3＋64＋4096＋8192

プロセスサーバ

192＋512×MAX（c，256）＋96＋256＋（pd_max_server_processの値＋50）×（256＋144）＋16＋8×34＋16＋16＋48＋48×（k＋1）

ｃ：↑（51＋d＋e＋f＋（g×ユニット内のBES数※）＋h＋i）÷16↑×16

ｄ：ユニット内にMGRがある場合は59，ない場合はj

ｅ：ユニット内にDSがある場合は17，ない場合は0

ｆ：ユニット内にFESがある場合は11，ない場合は0

ｇ：ユニット内にBESがある場合は25，ない場合は0

ｈ：1：1スタンバイレス型系切り替え機能を使用する場合は9，使用しない場合は0

ｉ：影響分散スタンバイレス型系切り替えの対象となるユニットの場合は1，対象でないユニットの場合は0

ｊ：pd_mlg_msg_log_unitオペランドにmanagerを指定しているときは1，localを指定しているときは2

ｋ：システム共通定義，又はユニット制御情報定義にpd_module_trace_maxオペランドを指定している場合はpd_module_trace_maxの値，指定していない場合は16383

注※　

1：1スタンバイレス型系切り替えの対象となっている場合は（BES数×2）となります。影響分散スタンバイレス型系切り替えの対象となるユニットの場合はpd_ha_max_act_guest_serversオペランドの補正値を含みます。

システムマネジャ

992＋（44＋4）×（g＋h＋i）＋（100＋4）×｛（p＋q＋3）＋u×（15＋1）｝＋（92＋4）×c＋40×（k＋m＋n×o＋u）×14＋256×m＋128×c＋36×d＋12×e＋96×o＋v×（16×35×（k＋u）＋15＋36×z＋15）＋w×（48×Ｂ＋15＋4×z＋15＋4×y＋15）＋v×（132＋15）＋8＋13080＋5856×p＋s＋s×o＋16＋96×o＋1024＋272×Ａ

ｃ：ユニット数

ｄ：pdunitオペランドの-cオプション指定数

ｅ：pdcltgrpオペランド指定数

ｇ：システム内のFES数

ｈ：システム内のBES数

ｉ：システム内のDS数

ｊ：ユニット内のFES数

ｋ：ユニット内のBES数

ｍ：ユニット内のDS数

ｎ：ユニット内の代替BES数

ｏ：ユニットが1：1スタンバイレス型系切り替えの対象となっている場合は1，

　　対象となっていない場合は0

ｐ：i＋k＋m＋n

ｑ：24＋t＋j×3＋k×15＋m×7

ｒ：14×（k＋m＋u）＋p＋q＋u×15＋2＋38＋5＋p×4

ｓ：272＋2052＋128×（r＋3）＋v×（40×（k＋u）＋72×（k＋u））

ｔ：ユニット内にMGRがある場合は2，ない場合は0

ｕ：受け入れ可能なゲストBES数（pd_ha_max_act_guest_serversオペランドの値）

ｖ：ユニットが影響分散スタンバイレス型系切り替えの対象となっている場合は1，

　　対象となっていない場合は0

ｗ：影響分散スタンバイレス型系切り替えの対象となっているユニットがある場合は1，

　　ない場合は0

ｙ：HAグループ内のユニット数の総和

ｚ：HAグループ内のサーバ数の総和

Ａ：pd_security_host_groupオペランドに指定したホストに対応するIPアドレスの数

　　pd_security_host_groupオペランドを指定していない場合は0

Ｂ：システム共通定義に指定しているpdhagroupオペランドの数

ネームサーバ

MAX｛65536，（X＋Y＋Z）｝＋MAX（16384，L）＋M

Ｘ：↑（256＋16＋156×ユニット数＋16＋16×126）÷1024↑×1024

Ｙ：8192

Ｚ：↑（264×（Z₂＋Z₃＋j＋32））÷1024↑×1024

Ｚ₂：b＋10＋c＋11×自ユニット内のHiRDBサーバ数＋d＋e

Ｚ₃：f＋7＋g＋4×自ユニット内のHiRDBサーバ数＋h＋i

Ｌ：↑（224×（L₂＋L3＋L4））÷1024↑×1024

Ｌ₂：k＋2×システム内のユニット数

Ｌ₃：システム内のBES数＋システム内のFES数＋システム内のDS数

Ｌ₄：15×システム内のHiRDBサーバ数

Ｍ：ユニット内のHiRDBサーバ数＋z＋m×ユニット内システムサーバ数

ｂ：ユニットにMGRがある場合：3

　　ユニットにMGRがない場合：0

ｃ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：2

　　それ以外のユニットの場合：0

ｄ：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　11×受け入れ可能なゲストBES数

　　それ以外のユニットの場合：0

ｅ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：

　　6×自ユニット内のHiRDBサーバ数

　　それ以外のユニットの場合：0

ｆ：ユニットにMGRがある場合：3

　　ユニットにMGRがない場合：0

ｇ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：2

　　それ以外のユニットの場合：0

ｈ：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　3×受け入れ可能なゲストBES数

　　それ以外のユニットの場合：0

ｉ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：

　　4×自ユニット内のHiRDBサーバ数

　　それ以外のユニットの場合：0

ｊ：ユニット内のサーバ数＋β＋γ＋ユニット内ユティリティサーバ数＋2

　　ユニット内ユティリティサーバ数：24＋α

ｋ：ユニットにMGRがある場合：3

　　ユニットにMGRがない場合：0

ｍ：38＋n＋o

ｎ：ユニットにMGRがあり，かつユニット数が2以上の場合：5

　　ユニットにMGRがあり，かつユニット数が1の場合：4

　　ユニットにMGRがなく，かつpd_mlg_msg_log_unitの値がlocalの場合：4

　　ユニットにMGRがなく，かつpd_mlg_msg_log_unitの値がmanagerの場合：3

ｏ：4×ユニット内のHiRDBサーバ数

ｚ：24＋α

α：ユニット内にMGRがある場合：3

　　ユニット内にFESがある場合：3

　　ユニット内にDSがある場合：7

　　ユニット内にBESがある場合：（BES数＋β）×15

β：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　受け入れ可能なゲストBES数※

　　上記以外のユニットの場合：0

γ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：代替BES数

　　上記以外のユニットの場合：0

注※　pd_ha_max_guest_act_serversの値

ノードマネジャ

ユニット内にMGRがある場合

　↑（1152＋432×システムの全ユニット数＋80×システムの全サーバ数

　　＋7680＋1008＋56×C＋240×A＋44×A＋28×A

　　＋16×B＋16×システムの全BES数＋8×システムの全ユニット数

　　＋64×システムの全サーバ数＋32×システムの全サーバ数＋32）

　　÷1024↑×1024

ユニット内にMGRがない場合

　↑（1008＋56×C＋（240×A＋44×A＋28×A）×F

　　＋16×B＋16×システムの全BES数＋8×システムの全ユニット数

　　＋64×システムの全サーバ数＋32×システムの全サーバ数＋32）

　　÷1024↑×1024

Ａ：pd_utl_exec_mode=0の場合：1024

pd_utl_exec_mode=1の場合：pd_max_usersの値×システムの全BES数×3

ユニットにMGRがある場合は次に示す値を加算：pd_max_usersの値×4＋200

ユニットにDSがある場合は次に示す値を加算：pd_max_usersの値×3＋200

ユニットにBESがある場合は次に示す値を加算：pd_max_usersの値×D

上記の計算式で算出したAの値が1024を超えない場合は，Aを1024に置き換えてください。

Ｂ：pdcltgrpオペランドを指定しない場合：0

pdcltgrpオペランドを指定する場合：pdcltgrp指定数＋1

Ｃ：ユニット内サーバ数＋E

Ｄ：ユニット内BES数＋E

Ｅ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：ユニット内の代替BES数

影響分散スタンバイレス型系切り替えの対象となるユニットの場合：受け入れ可能なゲストBES数

上記以外のユニットの場合：0

Ｆ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：2

上記以外のユニットの場合：1

I/Oサーバ

↑（28＋（↑（32＋A）÷32↑×32））÷128↑×128

影響分散スタンバイレス型系切り替え機能の対象となるユニットではない場合

Ａ：34268＋pd_max_utl_ios_file_noの値×296＋158064※1

＋｛（162800＋pd_max_file_noの値×1024）×BES数｝※2

＋｛162800＋pd_max_file_noの値×1024｝※3

注※1　FESがある場合に加算します。

注※2　BESがある場合に加算します。

注※3　DSがある場合に加算します。

なお，1：1スタンバイレス型系切り替え構成対象ユニットの場合には，上記の式で求めた値を2倍にします。

影響分散スタンバイレス型系切り替え機能の対象となるユニットの場合

Ａ：↑48＋24×BES数※4÷16↑×16

＋↑（177904＋pd_max_file_noの値×1024）÷16↑×16×BES数※4

＋34016

注※4　pd_ha_max_act_guest_serversの値を含みます。

ログサーバ

32＋48＋128×37

＋｛

　　384＋128×7＋1024＋512

　　＋↑（128＋256＋160＋8＋64）÷pd_log_rec_lengの値※↑

　　×pd_log_rec_lengの値※

　　＋64＋4096×2＋（736＋512）×B

　　＋↑｛（B＋1）÷12｝↑×8320

　　＋128×pd_log_write_buff_countの値※

　　＋（pd_log_write_buff_countの値※＋A）

　　×↑｛pd_log_max_data_sizeの値※＋（68＋44＋96＋160）｝÷4096↑

　　×4096＋C

　｝×ユニット内サーバ数＋D＋128×ユニット内FES数

＋512×ユニット内のHiRDBのサーバ数

Ａ：16

Ｂ：pdlogadfg -d sysオペランド指定数※

Ｃ：512

Ｄ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：ユニット内の代替BES数

　　影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　pd_ha_max_act_guest_serversオペランドの補正値

注※

ユニット内の全サーバの指定値で，最大値を指します。1：1スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとユニット内で動作する代替BESの指定値で，最大値を指します。影響分散スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとHAグループに含まれる全BESの指定値で，最大値を指します。

シンクポイントダンプサーバ

｛

　↑（368＋1456×2）÷1024↑×1024

　＋↑｛（96＋80＋208＋208）＋192×（pdlogadfg -d spdの指定数※）

　＋416×（pdlogadpf -d spdの指定数※）｝÷1024↑×1024

｝×（全サーバ数＋A）

Ａ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：ユニット内の代替BES数

　　影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　pd_ha_max_act_guest_serversオペランドの補正値

注※

ユニット内の全サーバの指定値で，最大値を指します。1：1スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとユニット内で動作する代替BESの指定値で，最大値を指します。影響分散スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとHAグループに含まれる全BESの指定値で，最大値を指します。

ユニット共通

a＋｛b＋64＋（s＋3）×c＋64＋48＋d＋e｝

×（ユニット内のFES，BES，DSの合計数＋i）

＋（g×（ユニット内のBES，DSの合計数＋i））＋f

＋（pd_max_server_processの値×2＋100）×（64＋16）＋32

＋（pd_max_server_processの値×2＋100＋384）×40＋32＋h＋j＋v＋w

＋（pd_max_server_processの値＋127）×48＋32＋y＋A＋B

影響分散スタンバイレス型系切り替え機能を使用する場合に加算します。

（↑（28＋(↑（56＋72584）÷32↑×32））÷128↑×128）

ａ：14480

ｂ：2988

ｃ：2712

ｄ：32×32

ｅ：64＋64×｛（s＋3）×2

　＋MAX（5，↓［s＋3］÷10↓）＋7｝

ｆ：512×（13＋ユニット内のFES，BES，DSの合計数×3）×2

ｇ：｛↑（96＋pd_lck_until_disconnect_cntの値×112）÷4096↑｝

　　×4096×2

ｈ：↑（pd_registered_portで指定したポート番号の数×16＋32）

　　÷1024↑×1024

　　pd_registered_portを指定していない場合は0

ｉ：1：1スタンバイレス型系切り替えの場合は代替BES数

　　影響分散スタンバイレス型系切り替えの場合はpd_ha_max_guest_servers補正値

ｊ：p×（ユニット内のFES数）＋q×（ユニット内のBES数＋i）＋r×（ユニット内のDS数）

ｋ：FESのpd_fes_lck_pool_partitionの値

ｍ：BESのpd_lck_pool_partitionの値

ｎ：DSのpd_lck_pool_partitionの値

ｏ：（s＋3）×2＋MAX｛5，↓（s＋3）÷10↓｝＋7

ｐ：kが2以上の場合は32＋（8＋8×k）×o

　　それ以外の場合は0

ｑ：mが2以上の場合は32＋（8＋8×m）×o

　　それ以外の場合は0

ｒ：nが2以上の場合は32＋（8＋8×n）×o

　　それ以外の場合は0

ｓ：pd_max_usersの値

ｔ：pd_max_dic_processの値

ｕ：pd_max_bes_processの値

sは，DSの場合はt，BESの場合はuとします。pd_max_dic_process又はpd_max_bes_processを省略する場合はsとします。

ｖ：pd_dbbuff_modifyにYを指定し，かつユニット内にBES又はDSがある場合：69648＋（BES定義又はDS定義のpd_max_add_dbbuff_shm_noの値のユニット内最大値）×136

　pd_dbbuff_modifyにNを指定し，かつユニット内にBES又はDSがある場合：69648

　上記以外：2192

ｗ：144

ｙ：pd_shm_reuseにYを指定し，かつpd_dbbuff_modifyにYを指定し，かつユニット内にBES又はDSがある場合：139280＋（BES定義又はDS定義のpd_max_add_dbbuff_shm_noの値のユニット内最大値）×272

　　pd_shm_reuseにYを指定し，かつpd_dbbuff_modifyにNを指定し，かつユニット内にBES又はDSがある場合：139280

　　pd_shm_reuseにYを指定し，かつユニット内にBES及びDSがない場合：4368

　　上記以外：0

Ａ：640

Ｂ：11520

トランザクションログサーバ

｛1024＋512×A｝×（ユニット内サーバ数＋H）

＋｛

　　128×B＋128

　　＋[F＋↑（128＋256＋8＋224）÷pd_log_rec_lengの値※↑×pd_log_rec_lengの値※

　　＋↑（pd_log_max_data_sizeの値※＋68＋44＋96＋160）

　　÷pd_log_rec_lengの値※↑×pd_log_rec_lengの値※]

　　×D＋E＋（48＋8）×B×2

　｝×（ユニット内のBES及びDS数＋H）

＋｛

　　584×B＋128×B＋64×B×C＋128＋F

　　＋↑（128＋256＋8＋224）÷pd_log_rec_lengの値※↑×pd_log_rec_lengの値※

　　＋↑（pd_log_max_data_sizeの値※＋68＋44＋96＋160）

　　÷pd_log_rec_lengの値※↑×pd_log_rec_lengの値※

　　＋E＋（48＋8）×（B×2＋2）

　｝×（ユニット内サーバ数＋H）

Ａ：2

Ｂ：7＋J×2

Ｃ：システム全体のBES数×4＋システム全体のDS数×2

　　＋システム全体のFES数

Ｄ：pd_log_rollback_buff_countの値が0の場合：8

　　それ以外の場合：pd_log_rollback_buff_countの値

Ｅ：512

Ｆ：512

Ｈ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：ユニット内の代替BES数

　　影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　pd_ha_max_act_guest_serversオペランドの補正値

Ｊ：ユニット内サーバ中の，s，t，及びuの最大値

ｓ：pd_max_usersの値

ｔ：pd_max_dic_processの値

ｕ：pd_max_bes_processの値

注※

ユニット内の全サーバの指定値で，最大値を指します。1：1スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとユニット内で動作する代替BESの指定値で，最大値を指します。影響分散スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとHAグループに含まれる全BESの指定値で，最大値を指します。

ステータスサーバ

↑64÷32↑×32×（ユニット内サーバ数＋A）

Ａ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：ユニット内の代替BES数

　　影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　pd_ha_max_act_guest_serversオペランドの補正値

監査証跡管理サーバ

↑A÷1024↑×1024

Ａ：pd_aud_file_nameオペランドの指定がない場合は640

　　pd_aud_file_nameオペランドの指定がある場合は640＋（304×200）＋B＋C

Ｂ：pd_aud_async_buff_sizeオペランドの値が0の場合は0

　　pd_aud_async_buff_sizeオペランドの値が4096以上の場合は次の計算値

　　　（160×pd_aud_async_buff_countオペランドの値）

　　　＋｛（↑pd_aud_async_buff_sizeオペランドの値÷4096↑×4096）

　　　×pd_aud_async_buff_countオペランドの値｝＋4096

Ｃ：pd_aud_auto_loadingオペランドにYを指定し，かつMGRがあるユニットの場合は256×（システム全体のユニット数＋1）＋240

　　上記以外の場合は0

スタンバイレス型系切り替え機能を適用するユニットの場合，自ユニットのメモリ使用量に，系切り替え先となるユニットのセキュリティ監査のメモリ使用量を加算する必要があります。

(2)　64ビットモードの場合

ユニットの開始から終了までの間にユニットコントローラが使用する共用メモリは，次に示すHiRDBのプロセスの項目すべてを加算した値です。

プロセスの種類 | 共用メモリの計算式（単位：バイト）

スケジューラ

pd_utl_exec_modeの値が0の場合

　｛↑（432＋304×n）÷1024↑＋507＋x＋z＋↑（134＋pd_trn_rcvmsg_store_buflenの値）÷1024↑｝×1024

pd_utl_exec_modeの値が1の場合

　｛↑（432＋304×n）÷1024↑＋y＋z＋↑（134＋pd_trn_rcvmsg_store_buflenの値）÷1024↑｝×1024

ｘ：ユニット内にMGRがある場合：37

ユニット内にFESがある場合：57＋1×（s＋3）＋14

ユニット内にDSがある場合：102＋5×（t＋3）＋14

ユニット内にBESがある場合：｛192＋9×（u＋3）＋14｝×（BES数＋β＋γ）

ｙ：ユニット内にMGRがある場合：0

ユニット内にFESがある場合：1×（s＋3）＋14

ユニット内にDSがある場合：5×（t＋3）＋14

ユニット内にBESがある場合：｛9×（u＋3）＋14｝×（BES数＋β＋γ）

ｚ：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

↑64＋｛（ユニット内BES数＋受け入れ可能なゲストBES数※）×48｝÷1024↑

上記以外のユニットの場合：0

ｎ：ユニット内のサーバ数＋β＋γ＋ユニット内ユティリティサーバ数＋1

ユニット内ユティリティサーバ数：25＋α

α：ユニット内にMGRがある場合：3

　　ユニット内にFESがある場合：3

　　ユニット内にDSがある場合：7

　　ユニット内にBESがある場合：（BES数＋β）×15

ｓ：pd_max_usersの値

ｔ：pd_max_dic_processの値

ｕ：pd_max_bes_processの値

β：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

受け入れ可能なゲストBES数※

上記以外のユニットの場合：0

γ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：代替BES数

上記以外のユニットの場合：0

注※　pd_ha_max_guest_act_serversの値

ロックサーバ

ユニット内にサーバ（FES，BES，又はDS）がある場合

影響分散スタンバイレス型系切り替え機能の対象となるユニットで，ゲストBESについての計算をする場合に使用するサーバごとのオペランド（pd_lck_pool_size，pd_lck_pool_partition，pd_lck_hash_entry，pd_max_bes_processなど）の値は，そのゲストBESのオペランドの値ではなく，そのユニット内の全ゲストBESに指定されている値の最大値を使用します。また，影響分散スタンバイレス型系切り替え機能の対象となるユニットでは，「ユニット内サーバ」は「全ホストBES＋全ゲストBES」です。

1：1スタンバイレス型系切り替え機能の対象となるユニットでは，「ユニット内サーバ」は「全正規BES＋全代替BES」です。

y

Σ｛

x=1

　　496＋80＋cx＋dx＋64＋8192＋gx＋80＋ix

　　＋64＋16336＋64＋nx＋px＋tx＋ux＋16

　　｝×pd_lck_pool_partitionの値※

注※　FESの場合はpd_fes_lck_pool_partitionの値

ｘ：ユニット内サーバ通し番号

ｙ：ユニット内サーバ数

ｃx：pd_lck_hash_entryを省略，又は0を指定している場合：

　　FESで，pd_fes_lck_pool_sizeが指定されていないとき

　　　（↓（8＋8×MAX（↑（↓↓（px＋3）×（pd_max_access_tablesの値＋4）÷4↓

　　　÷pd_fes_lck_pool_partitionの値↓×4）÷10↑の値を超えない最大の素数，11261））

　　　÷16↓＋1）×16

　　FESで，pd_fes_lck_pool_sizeが指定されているとき

　　　（↓（8＋8×MAX（↑（↓pd_fes_lck_pool_sizeの値÷pd_fes_lck_pool_partitionの値↓×4）÷10↑

　　　の値を超えない最大の素数，11261））÷16↓＋1）×16

　　BES，又はDSのとき

　　　（↓（8＋8×MAX（↑（（ｐx＋3）×2×5

　　　＋↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×4）÷10↑

　　　の値を超えない最大の素数，11261））÷16↓＋1）×16

　　pd_lck_hash_entryに2以上の素数でない値を指定している場合：

　　（↓（8＋8×pd_lck_hash_entryの値を超えない最大の素数）÷16↓＋1）

　　×16

　　pd_lck_hash_entryに1，又は素数を指定している場合：

　　（↓（8＋8×pd_lck_hash_entryの値）÷16↓＋1）×16

ｄx：FESで，pd_fes_lck_pool_sizeが指定されていない場合：

　　　（↓↓（px＋3）×（pd_max_access_tablesの値＋4）÷4↓

　　　÷pd_fes_lck_pool_partitionの値↓×4）×128

　　FESで，pd_fes_lck_pool_sizeが指定されている場合：

　　　↓pd_fes_lck_pool_sizeの値÷pd_fes_lck_pool_partitionの値↓×4×128

　　BES，又はDSの場合：

　　　（（px＋3）×2×5＋↓pd_lck_pool_sizeの値

　　　÷pd_lck_pool_partitionの値↓×4）×128

ｇx：FESの場合：

　　　（p＋3）×2×320

　　BESで，pd_utl_exec_modeの値=1，かつs＞32の場合：

　　　（（p＋3）×2＋s）×320

　　BESで，pd_utl_exec_modeの値=0，又はs≦32の場合：

　　　（（p＋3）×2＋32）×320

　　DSで，pd_utl_exec_modeの値=1，かつs＞16の場合：

　　　（（p＋3）×2＋s）×320

　　DSで，pd_utl_exec_modeの値=0，又はs≦16の場合：

　　　（（p＋3）×2＋16）×320

ｉx：FESで，pd_fes_lck_pool_sizeが指定されていない場合：

　　　（↓↓（px＋3）×（pd_max_access_tablesの値＋4）÷4↓

　　　÷pd_fes_lck_pool_partitionの値↓）×8×112

　　FESで，pd_fes_lck_pool_sizeが指定されている場合：

　　　（↓pd_fes_lck_pool_sizeの値÷pd_fes_lck_pool_partitionの値↓×5

　　　＋↓↓pd_fes_lck_pool_sizeの値÷pd_fes_lck_pool_partitionの値↓÷3↓）を偶数に切り上げた値×112

　　BESで，pd_utl_exec_modeの値=1，かつs＞32の場合：

　　　（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋↓↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓÷3↓

　　　＋（px＋3）×2×2×5＋s×（pd_max_rdarea_noの値＋1））

　　　を偶数に切り上げた値×112

　　BESで，pd_utl_exec_modeの値=0，又はs≦32の場合：

　　　（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋↓↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓÷3↓

　　　＋（px＋3）×2×2×5＋32×（pd_max_rdarea_noの値＋1））

　　　を偶数に切り上げた値×112

　　DSで，pd_utl_exec_modeの値=1，かつs＞16の場合：

　　　（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋↓↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓÷3↓

　　　＋（px＋3）×2×2×5＋s＋4）を偶数に切り上げた値×112

　　DSで，pd_utl_exec_modeの値=0，又はs≦16の場合：

　　　（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋↓↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓÷3↓

　　　＋（px＋3）×2×2×5＋20）

　　　を偶数に切り上げた値×112

ｎx：FESの場合：

　　　（px＋3）×2×80

　　BESで，pd_utl_exec_modeの値=1，かつs＞32の場合：

　　　（（p＋3）×2×17＋s）×80

　　BESで，pd_utl_exec_modeの値=0，又はs≦32の場合：

　　　（（p＋3）×2×17＋32）×80

　　DSで，pd_utl_exec_modeの値=1，かつs＞16の場合：

　　　（（p＋3）×2×17＋s）×80

　　DSで，pd_utl_exec_modeの値=0，又はs≦16の場合：

　　　（（p＋3）×2×17＋16）×80

ｐx：FESで，HiRDBシステム内のFES数＞1の場合：s＋1

　　FESで，HiRDBシステム内のFES数=1の場合：s

　　BESで，s＞pd_max_bes_processの値 の場合：s

　　BESで，s≦pd_max_bes_processの値 の場合：

　　　pd_max_bes_processオペランドの値

　　DSで，s＞pd_max_dic_processの値 の場合：s

　　DSで，s≦pd_max_dic_processの値 の場合：

　　　pd_max_dic_processオペランドの値

ｓ：pd_max_usersの値

ｔx：FESの場合：

　　　48＋（px＋3）×2×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　BESで，pd_utl_exec_modeの値=1，かつs＞32の場合：

　　　48＋（（px＋3）×2＋s）×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　BESで，pd_utl_exec_modeの値=0，又はs≦32の場合：

　　　48＋（（px＋3）×2＋32）×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　DSで，pd_utl_exec_modeの値=1，かつs＞16の場合：

　　　48＋（（px＋3）×2＋s）×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　DSで，pd_utl_exec_modeの値=0，又はs≦16の場合：

　　　48＋（（px＋3）×2＋16）×↑pd_max_open_holdable_cursorsの値÷16↑×4

ｕx：FESで，pd_fes_lck_pool_sizeが指定されていない場合：

　　　48＋（↓↓（px＋3）×（pd_max_access_tablesの値＋4）÷4↓÷pd_fes_lck_pool_partitionの値↓）×8

　　　×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　FESで，pd_fes_lck_pool_sizeが指定されている場合：

　　　48＋（↓pd_fes_lck_pool_sizeの値÷pd_fes_lck_pool_partitionの値↓×5

　　　＋↓↓pd_fes_lck_pool_sizeの値÷pd_fes_lck_pool_partitionの値↓÷3↓）

　　　を偶数に切り上げた値×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　BESで，pd_utl_exec_modeの値=1，かつs＞32の場合：

　　　48＋（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋↓↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓÷3↓

　　　＋（px＋3）×2×2×5＋s×（pd_max_rdarea_noの値＋1））

　　　を偶数に切り上げた値×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　BESで，pd_utl_exec_modeの値=0，又はs≦32の場合：

　　　48＋（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋↓↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓÷3↓

　　　＋（px＋3）×2×2×5＋32×（pd_max_rdarea_noの値＋1））

　　　を偶数に切り上げた値×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　DSで，pd_utl_exec_modeの値=1，かつs＞16の場合：

　　　48＋（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋↓↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓÷3↓

　　　＋（px＋3）×2×2×5＋s＋4）を偶数に切り上げた値

　　　×↑pd_max_open_holdable_cursorsの値÷16↑×4

　　DSで，pd_utl_exec_modeの値=0，又はs≦16の場合：

　　　48＋（↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓×5

　　　＋↓↓pd_lck_pool_sizeの値÷pd_lck_pool_partitionの値↓÷3↓

　　　＋（px＋3）×2×2×5＋20）を偶数に切り上げた値

　　　×↑pd_max_open_holdable_cursorsの値÷16↑×4

●ユニット内にサーバ（FES，BES，又はDS）がない場合

16704

トランザクションサーバ

304＋32×B＋192×s×2

ユニット内にFESがある場合に加算します※

　＋1048＋（416＋800＋256＋392×2）×（A×2＋7）＋256×2

　＋128×（システム内BES数×4＋システム内DS数×2

　＋システム内FES数）×（A×2＋7）

　＋C

ユニット内にBESがある場合に加算します※

　＋1048＋（416＋800＋256＋392×2）×（u×2＋7）

　＋256×2

　＋128×（システム内BES数×4＋システム内DS数×2

　＋システム内FES数）×（A×2＋7）

　＋D

ユニット内にDSがある場合に加算します※

　＋1048＋（416＋800＋256＋392×2）×（t×2＋7）

　＋256×2

　＋128×（システム内BES数×4＋システム内DS数×2

　＋システム内FES数）×（A×2＋7）

　＋E

ｓ：pd_max_usersの値

ｔ：pd_max_dic_processの値

ｕ：pd_max_bes_processの値

Ａ：マルチFESの場合はs＋1，マルチFESでない場合はs

Ｂ：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　ホストBES数＋pd_ha_max_act_guest_serversオペランドの値

　　上記以外のユニットの場合：ユニット内サーバ数

Ｃ：≪条件≫に示すどちらかの条件に一致する場合：

　　128×（システム内BES数×4＋システム内DS数×2

　　＋システム内FES数）×（A×2＋7）

　　≪条件≫に示すどちらの条件にも一致しない場合：0

Ｄ：≪条件≫に示すどちらかの条件に一致する場合：

　　128×（システム内BES数×4＋システム内DS数×2

　　＋システム内FES数）×（u×2＋7）

　　≪条件≫に示すどちらの条件にも一致しない場合：0

Ｅ：≪条件≫に示すどちらかの条件に一致する場合：

　　128×（システム内BES数×4＋システム内DS数×2

　　＋システム内FES数）×（t×2＋7）

　　≪条件≫に示すどちらの条件にも一致しない場合：0

≪条件≫

pd_rpl_reflect_modeオペランドにuapを指定している

システム内に，pdstart -k stlsオペランドを指定したフロントエンドサーバが存在する

注※　上記の計算式で算出した値を各サーバの数分だけ加算します。

1：1スタンバイレス型系切り替え適用ユニットの場合：

正規BES数＋代替BES数

上記以外の場合はユニット内サーバ数

タイマサーバ

32×（pd_max_usersの値＋3）

×（システム内のBES数＋1＋ユニット内ユティリティサーバ数＋1）

＋1440＋（48−32）×2

ユニット内ユティリティサーバ数は23＋α

α：ユニット内にMGRがある場合：2

　　ユニット内にFESがある場合：3

　　ユニット内にDSがある場合：7

　　ユニット内にBESがある場合：BES数×15

統計ログサーバ | 424＋128×16＋32＋288×2＋1168＋144×3 ＋pd_stj_buff_sizeの値×1024×3＋64＋4096＋8192

プロセスサーバ

208＋528×MAX（c，256）＋96＋256＋（pd_max_server_processの値＋50）×（256＋160）＋16＋8×34＋16＋16＋64＋64×（k＋1）

ｃ：↑（51＋d＋e＋f＋（g×ユニット内のBES数※）＋h＋i）÷16↑×16

ｄ：ユニット内にMGRがある場合は59，ない場合はj

ｅ：ユニット内にDSがある場合は17，ない場合は0

ｆ：ユニット内にFESがある場合は11，ない場合は0

ｇ：ユニット内にBESがある場合は25，ない場合は0

ｈ：1：1スタンバイレス型系切り替え機能を使用する場合は9，使用しない場合は0

ｉ：影響分散スタンバイレス型系切り替えの対象となるユニットの場合は1，対象でないユニットの場合は0

ｊ：pd_mlg_msg_log_unitオペランドにmanagerを指定しているときは1，localを指定しているときは2

k：システム共通定義，又はユニット制御情報定義にpd_module_trace_maxオペランドを指定している場合はpd_module_trace_maxの値，指定していない場合は16383

m：ユニット内にMGRがある場合は0，ユニット内にMGRがない場合は1

注※　

1：1スタンバイレス型系切り替えの対象となっている場合は（BES数×2）となります。影響分散スタンバイレス型系切り替えの対象となるユニットの場合はpd_ha_max_act_guest_serversオペランドの補正値を含みます。

システムマネジャ

1024＋（48＋8）×（g＋h＋i）＋（108＋8）×｛（p＋q＋3）＋u×（15＋1）｝＋（104＋8）×c＋40×（k＋m＋n×o＋u）×14＋256×m＋128×c＋40×d＋16×e＋96×o＋v×（16×35×（k＋u）＋15＋44×z＋15）＋w×（48×Ｂ＋15＋4×z＋15＋4×y＋15）＋v×（144＋15）＋8＋13096＋5856×p＋s＋s×o＋16＋96×o＋1024＋272×Ａ

ｃ：ユニット数

ｄ：pdunitオペランドの-cオプション指定数

ｅ：pdcltgrpオペランド指定数

ｇ：システム内のFES数

ｈ：システム内のBES数

ｉ：システム内のDS数

ｊ：ユニット内のFES数

ｋ：ユニット内のBES数

ｍ：ユニット内のDS数

ｎ：ユニット内の代替BES数

ｏ：ユニットがスタンバイレス型系切り替えの対象となっている場合は1，

　　対象となっていない場合は0

ｐ：i＋k＋m＋n

ｑ：24＋t＋j×3＋k×15＋m×7

ｒ：14×（k＋m＋u）＋p＋q＋u×15＋2＋38＋5＋p×4

ｓ：320＋2052＋148×（r＋3）＋v×（40×（k＋u）＋72×（k＋u））

ｔ：ユニット内にMGRがある場合は2，ない場合は0

ｕ：受け入れ可能なゲストBES数（pd_ha_max_act_guest_serversオペランドの値）

ｖ：ユニットが影響分散スタンバイレス型系切り替えの対象となっている場合1，

　　対象となっていない場合は0

ｗ：影響分散スタンバイレス型系切り替えの対象となっているユニットがある場合は1，

　　ない場合は0

ｙ：HAグループ内のユニット数の総和

ｚ：HAグループ内のサーバ数の総和

Ａ：pd_security_host_groupオペランドに指定したホストに対応するIPアドレスの数

　　pd_security_host_groupオペランドを指定していない場合は0

Ｂ：システム共通定義に指定しているpdhagroupオペランドの数

ネームサーバ

MAX｛65536，（X＋Y＋Z）｝＋MAX（16384，L）＋M

Ｘ：↑（272＋16＋156×ユニット数＋16＋16×126）÷1024↑×1024

Ｙ：8192

Ｚ：↑（264×（Z₂＋Z₃＋j＋32））÷1024↑×1024

Ｚ₂：b＋10＋c＋11×自ユニット内のHiRDBサーバ数＋d＋e

Ｚ₃：f＋7＋g＋4×自ユニット内のHiRDBサーバ数＋h＋i

Ｌ：↑（224×（L₂＋L3＋L4））÷1024↑×1024

Ｌ₂：k＋2×システム内のユニット数

Ｌ₃：システム内のBES数＋システム内のFES数＋システム内のDS数

Ｌ₄：15×システム内のHiRDBサーバ数

Ｍ：ユニット内のHiRDBサーバ数＋z＋m×ユニット内システムサーバ数

ｂ：ユニットにMGRがある場合：3

　　ユニットにMGRがない場合：0

ｃ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：2

　　それ以外のユニットの場合：0

ｄ：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　11×受け入れ可能なゲストBES数

　　それ以外のユニットの場合：0

ｅ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：

　　6×自ユニット内のHiRDBサーバ数

　　それ以外のユニットの場合：0

ｆ：ユニットにMGRがある場合：3

　　ユニットにMGRがない場合：0

ｇ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：2

　　それ以外のユニットの場合：0

ｈ：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　3×受け入れ可能なゲストBES数

　　それ以外のユニットの場合：0

ｉ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：

　　4×自ユニット内のHiRDBサーバ数

　　それ以外のユニットの場合：0

ｊ：ユニット内のサーバ数＋β＋γ＋ユニット内ユティリティサーバ数＋2

ユニット内ユティリティサーバ数：24＋α

ｋ：ユニットにMGRがある場合：3

　　ユニットにMGRがない場合：0

ｍ：38＋n＋o

ｎ：ユニットにMGRがあり，かつユニット数が2以上の場合：5

　　ユニットにMGRがあり，かつユニット数が1の場合：4

　　ユニットにMGRがなく，かつpd_mlg_msg_log_unitの値がlocalの場合：4

　　ユニットにMGRがなく，かつpd_mlg_msg_log_unitの値がmanagerの場合：3

ｏ：4×ユニット内のHiRDBサーバ数

ｚ：24＋α

α：ユニット内にMGRがある場合：3

　　ユニット内にFESがある場合：3

　　ユニット内にDSがある場合：7

　　ユニット内にBESがある場合：（BES数＋β）×15

β：影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　受け入れ可能なゲストBES数※

　　上記以外のユニットの場合：0

γ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：代替BES数

　　上記以外のユニットの場合：0

注※　pd_ha_max_guest_act_serversの値

ノードマネジャ

ユニット内にMGRがある場合

　↑（1312＋464×システムの全ユニット数＋96×システムの全サーバ数

　　＋10240＋1200＋72×C＋240×A＋44×A＋28×A

　　＋16×B＋16×システムの全BES数＋8×システムの全ユニット数

　　＋64×システムの全サーバ数＋32×システムの全サーバ数＋48）

　　÷1024↑×1024

ユニット内にMGRがない場合

　↑（1200＋72×C＋（240×A＋44×A＋28×A）×F

　　＋16×B＋16×システムの全BES数＋8×システムの全ユニット数

　　＋64×システムの全サーバ数＋32×システムの全サーバ数＋48）

　　÷1024↑×1024

Ａ：pd_utl_exec_mode=0の場合：1024

pd_utl_exec_mode=1の場合：pd_max_usersの値×システムの全BES数×3

ユニットにMGRがある場合は次に示す値を加算：pd_max_usersの値×4＋200

ユニットにDSがある場合は次に示す値を加算：pd_max_usersの値×3＋200

ユニットにBESがある場合は次に示す値を加算：pd_max_usersの値×D

上記の計算式で算出したAの値が1024を超えない場合は，Aを1024に置き換えてください。

Ｂ：pdcltgrpオペランドを指定しない場合：0

pdcltgrpオペランドを指定する場合：pdcltgrp指定数＋1

Ｃ：ユニット内サーバ数＋E

Ｄ：ユニット内BES数＋E

Ｅ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：ユニット内の代替BES数

影響分散スタンバイレス型系切り替えの対象となるユニットの場合：受け入れ可能なゲストBES数

上記以外のユニットの場合：0

Ｆ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：2

上記以外のユニットの場合：1

I/Oサーバ

↑（56＋（↑（56＋A）÷32↑×32））÷128↑×128

影響分散スタンバイレス型系切り替え機能の対象となるユニットではない場合

Ａ：34268＋pd_max_utl_ios_file_noの値×296＋158064※1

＋｛（162800＋pd_max_file_noの値×1024）×BES数｝※2

＋｛162800＋pd_max_file_noの値×1024｝※3

注※1　FESがある場合に加算します。

注※2　BESがある場合に加算します。

注※3　DSがある場合に加算します。

なお，1：1スタンバイレス型系切り替え構成対象ユニットの場合には，上記の式で求めた値を2倍にします。

影響分散スタンバイレス型系切り替え機能の対象となるユニットの場合

Ａ：↑64＋24×BES数※4÷16↑×16

＋↑（177952＋pd_max_file_noの値×1024）÷16↑×16×BES数※4

注※4　pd_ha_max_act_guest_serversの値を含みます。

ログサーバ

32＋48＋128×37

＋｛

　　432＋128×7＋1168＋512

　　＋↑（128＋256＋160＋8＋64）÷pd_log_rec_lengの値※↑

　　×pd_log_rec_lengの値※

　　＋64＋4096×2＋（768＋512）×B

　　＋↑｛（B＋1）÷12｝↑×8320

　　＋144×pd_log_write_buff_countの値※

　　＋（pd_log_write_buff_countの値※＋A）

　　×↑｛pd_log_max_data_sizeの値※＋（68＋44＋96＋160）｝÷4096↑

　　×4096＋C

　｝×ユニット内サーバ数＋D＋128×ユニット内FES数

＋512×ユニット内のHiRDBのサーバ数

Ａ：16

Ｂ：pdlogadfg -d sysオペランド指定数※

Ｃ：512

Ｄ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：ユニット内の代替BES数

　　影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　pd_ha_max_act_guest_serversオペランドの補正値

注※

ユニット内の全サーバの指定値で，最大値を指します。1：1スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとユニット内で動作する代替BESの指定値で，最大値を指します。影響分散スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとHAグループに含まれる全BESの指定値で，最大値を指します。

シンクポイントダンプサーバ

｛

　↑（384＋1536×2）÷1024↑×1024

　＋↑｛（128＋80＋240＋240）＋192×（pdlogadfg -d spdの指定数※）

　＋416×（pdlogadpf -d spdの指定数※）｝÷1024↑×1024

｝×（全サーバ数＋A）

Ａ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：ユニット内の代替BES数

　　影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　pd_ha_max_act_guest_serversオペランドの補正値

注※

ユニット内の全サーバの指定値で，最大値を指します。1：1スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとユニット内で動作する代替BESの指定値で，最大値を指します。影響分散スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとHAグループに含まれる全BESの指定値で，最大値を指します。

ユニット共通

a＋｛b＋80＋（s＋3）×c＋64＋48＋d＋e｝

×（ユニット内のFES，BES，DSの合計数＋i）

＋（g×（ユニット内のBES，DSの合計数＋i））＋f

＋（pd_max_server_processの値×2＋100）×（76＋16）＋32

＋（pd_max_server_processの値×2＋100＋384）×40＋32＋h＋j＋v＋w

＋（pd_max_server_processの値＋127）×64＋32＋y＋A＋B

影響分散スタンバイレス型系切り替え機能を使用する場合に加算します。

（↑（56＋(↑（56＋88560）÷32↑×32））÷128↑×128）

ａ：23888

ｂ：5160

ｃ：3744

ｄ：48×32

ｅ：80＋96×｛（s＋3）×2

　＋MAX（5，↓［s＋3］÷10↓）＋7｝

ｆ：512×（13＋（ユニット内のFES，BES，DSの合計数＋i）×3）×2

ｇ：｛↑（128＋pd_lck_until_disconnect_cntの値×112）÷4096↑｝

　　×4096×2

ｈ：↑（pd_registered_portで指定したポート番号の数×16＋32）

　　÷1024↑×1024

　　pd_registered_portを指定していない場合は0

ｉ：1：1スタンバイレス型系切り替えの場合は代替BES数

　　影響分散スタンバイレス型系切り替えの場合はpd_ha_max_guest_servers補正値

ｊ：p×（ユニット内のFES数）＋q×（ユニット内のBES数＋i）＋r×（ユニット内のDS数）

ｋ：FESのpd_fes_lck_pool_partitionの値

ｍ：BESのpd_lck_pool_partitionの値

ｎ：DSのpd_lck_pool_partitionの値

ｏ：（s＋3）×2＋MAX｛5，↓（s＋3）÷10↓｝＋7

ｐ：kが2以上の場合は32＋（8＋16×k）×o

　　それ以外の場合は0

ｑ：mが2以上の場合は32＋（8＋16×m）×o

　　それ以外の場合は0

ｒ：nが2以上の場合は32＋（8＋16×n）×o

　　それ以外の場合は0

ｓ：pd_max_usersの値

ｔ：pd_max_dic_processの値

ｕ：pd_max_bes_processの値

sは，DSの場合はt，BESの場合はu，pd_max_dic_process又はpd_max_bes_processを省略する場合はsとします。

ｖ：pd_dbbuff_modifyにYを指定し，かつユニット内にBES又はDSがある場合：69648＋（（BES定義又はDS定義のpd_max_add_dbbuff_shm_noの値のユニット内最大値）＋pd_max_resident_rdarea_shm_no値）×136

　pd_dbbuff_modifyにNを指定し，かつユニット内にBES又はDSがある場合：69648＋pd_max_resident_rdarea_shm_no値×136

　上記以外：2192

ｗ：144

ｙ：pd_shm_reuseにYを指定し，かつpd_dbbuff_modifyにYを指定し，かつユニット内にBES又はDSがある場合：278544＋（（BES定義又はDS定義のpd_max_add_dbbuff_shm_noの値のユニット内最大値）＋pd_max_resident_rdarea_shm_no値）×544

　　pd_shm_reuseにYを指定し，かつpd_dbbuff_modifyにNを指定し，かつユニット内にBES又はDSがある場合：278544＋pd_max_resident_rdarea_shm_no値×544

　　pd_shm_reuseにYを指定し，かつユニット内にBES及びDSがない場合：8720

　　上記以外：0

Ａ：640

Ｂ：11520

トランザクションログサーバ

｛1168＋688×A｝×（ユニット内サーバ数＋H）

＋｛

　　128×B＋144

　　＋[G＋↑（128＋256＋8＋224）÷pd_log_rec_lengの値※↑×pd_log_rec_lengの値※

　　＋↑（pd_log_max_data_sizeの値※＋68＋44＋96＋160）

　　÷pd_log_rec_lengの値※↑×pd_log_rec_lengの値※]

　　×D＋E＋（48＋8）×B×2

　｝×（ユニット内のBES及びDS数＋H）

＋｛

　　600×B＋128×B＋64×B×C＋144＋G

　　＋↑（128＋256＋8＋224）÷pd_log_rec_lengの値※↑×pd_log_rec_lengの値※

　　＋↑（pd_log_max_data_sizeの値※＋68＋44＋96＋160）

　　÷pd_log_rec_lengの値※↑×pd_log_rec_lengの値※

　　＋E＋（48＋8）×（B×2＋2）

　｝×（ユニット内サーバ数＋H）

Ａ：2

Ｂ：7＋J×2

Ｃ：システム全体のBES数×4＋システム全体のDS数×2

　　＋システム全体のFES数

Ｄ：pd_log_rollback_buff_countの値が0の場合：8

　　それ以外の場合：pd_log_rollback_buff_countの値

Ｅ：4096

Ｇ：64

Ｈ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：ユニット内の代替BES数

　　影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　pd_ha_max_act_guest_serversオペランドの補正値

Ｊ：ユニット内サーバ中の，s，t，及びuの最大値

ｓ：pd_max_usersの値

ｔ：pd_max_dic_processの値

ｕ：pd_max_bes_processの値

注※

ユニット内の全サーバの指定値で，最大値を指します。1：1スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとユニット内で動作する代替BESの指定値で，最大値を指します。影響分散スタンバイレス型系切り替えの対象となるユニットの場合はユニット内の全サーバとHAグループに含まれる全BESの指定値で，最大値を指します。

ステータスサーバ

↑64÷32↑×32×（ユニット内サーバ数＋A）

Ａ：1：1スタンバイレス型系切り替えの対象となるユニットの場合：ユニット内の代替BES数

　　影響分散スタンバイレス型系切り替えの対象となるユニットの場合：

　　pd_ha_max_act_guest_serversオペランドの補正値

監査証跡管理サーバ

↑A÷1024↑×1024

Ａ：pd_aud_file_nameオペランドの指定がない場合は704

　　pd_aud_file_nameオペランドの指定がある場合は704＋（320×200）＋B＋C

Ｂ：pd_aud_async_buff_sizeオペランドの値が0の場合は0

　　pd_aud_async_buff_sizeオペランドの値が4096以上の場合は次の計算値

　　　（176×pd_aud_async_buff_countオペランドの値）

　　　＋｛（↑pd_aud_async_buff_sizeオペランドの値÷4096↑×4096）

　　　×pd_aud_async_buff_countオペランドの値｝＋4096

Ｃ：pd_aud_auto_loadingオペランドにYを指定し，かつMGRがあるユニットの場合は256×（システム全体のユニット数＋1）＋256

　　上記以外の場合は0

スタンバイレス型系切り替え機能を適用するユニットの場合，自ユニットのメモリ使用量に，系切り替え先となるユニットのセキュリティ監査のメモリ使用量を加算する必要があります。

15.2.4　各サーバが使用する共用メモリの計算式

(1)　フロントエンドサーバが使用する共用メモリの計算式

フロントエンドサーバが使用する共用メモリの計算式を次に示します。計算式で使用している変数については，「計算式で使用する変数」を参照してください。

●32ビットモードの場合

40＋b×1.3＋c＋d＋k＋1.6＋x＋y＋4
＋｛[（a＋12）÷13]×1.1＋[（a＋62）÷63]＋3.7｝×（e＋3）
＋｛
　　↑↑b÷64↑×（8÷16）↑×4×4
　　＋12×｛（b÷3）＋1−mod（b÷3，2）｝
　　＋4×a×｛（e＋3）×2＋1＋MAX（e÷10，5）｝
　　＋32＋4＋16＋｛56×（f＋1）×g｝＋20000
　　＋↑｛（c÷8）＋7｝÷64↑×8＋↑｛（k÷8）＋7｝÷64↑×8
　　＋MAX｛a×（e＋3），c÷8｝×104＋MAX｛a×（e＋3），k÷8｝×24
　　＋↑｛（x÷4）＋7｝÷64↑×8
　　＋↑｛[（y−（s×592＋t×916＋u×172））÷2]＋7｝÷64↑×8
　　＋MAX｛13×（e＋3），x÷4｝×88
　　＋60×MAX｛21×（e＋3），（y−（s×592＋t×916＋u×172））÷2｝
　　＋44＋256＋1024
　｝÷1024＋A＋7
　 I
＋Σ（Ji）
　i=1
＋6.5×1024×f
＋1024
●pd_def_buf_control_area_assignオペランドにINITIALを指定するか，又はこのオペランドを省略した場合に加算します。
＋｛［（a＋12）÷13］×1.1＋［（a＋62）÷63］＋3.7｝×（e＋7）
　　　　　　　　　　　　　　　　　　　　　　　　　（単位：キロバイト）

●64ビットモードの場合

40＋b×1.3＋c＋d＋k＋1.6＋x＋y＋5
＋｛[（a＋12）÷13]×1.2＋[（a＋62）÷63]×1.5＋4.1｝×（e＋3）
＋｛
　　↑↑b÷64↑×（8÷16）↑×4×4
　　＋12×｛（b÷3）＋1−mod（b÷3，2）｝
　　＋4×a×｛（e＋3）×2＋1＋MAX（e÷10，5）｝
　　＋48＋8＋16＋｛72×（f＋1）×g｝＋20000
　　＋↑｛（c÷8）＋7｝÷64↑×8＋↑｛（k÷8）＋7｝÷64↑×8
　　＋MAX｛a×（e＋3），c÷8｝×104＋MAX｛a×（e＋3），k÷8｝×40
　　＋↑｛（x÷4）＋7｝÷64↑×8
　　＋↑｛[（y−（s×600＋t×936＋u×184））÷2]＋7｝÷64↑×8
　　＋MAX｛13×（e＋3），x÷4｝×104
　　＋72×MAX｛21×（e＋3），（y−（s×600＋t×936＋u×184））÷2｝
　　＋72＋256＋1536
　｝÷1024＋A＋7
　 I
＋Σ（Ji）
　i=1
＋6.5×1024×f
＋1024
●pd_def_buf_control_area_assignオペランドにINITIALを指定するか，又はこのオペランドを省略した場合に加算します。
＋｛［（a＋12）÷13］×1.2＋［（a＋62）÷63］×1.5＋4.1｝×（e＋7）
　　　　　　　　　　　　　　　　　　　　　　　　　（単位：キロバイト）

(2)　ディクショナリサーバが使用する共用メモリの計算式

ディクショナリサーバが使用する共用メモリの計算式を次に示します。

32ビットモードの場合（単位：キロバイト）

計算式1＋↑｛（↑（40＋（計算式2〜計算式5を加算した値））÷512↑×512）｝÷1024↑

64ビットモードの場合（単位：キロバイト）

計算式1＋↑｛（↑（72＋（計算式2〜計算式5を加算した値））÷512↑×512）｝÷1024↑

計算式で使用している変数については，「計算式で使用する変数」を参照してください。

注意事項

pd_dbsync_point又はpd_system_dbsync_pointオペランドのどちらかの指定がcommitの場合に計算式3を加算します。pd_system_dbsync_pointオペランドの省略値はcommitです。

上記以外の場合，計算式5を加算します。

pd_dfw_awt_processオペランドを指定する場合に計算式4を加算します。

pd_dic_shmpool_sizeオペランドを省略すると，次の値が設定されます。

32ビットモードの場合：

↑｛（↑（40＋（計算式2〜計算式5の合計値））÷512↑×512）｝÷1024↑

64ビットモードの場合：

↑｛（↑（72＋（計算式2〜計算式5の合計値））÷512↑×512）｝÷1024↑

条件 | 共用メモリの計算式

計算式1

（単位：キロバイト）

●32ビットモードの場合

b×1.3

＋｛

　　↑↑b÷64↑×（8÷16）↑×4×4

　　＋12×｛（b÷3）＋1−mod（b÷3，2）｝

　　＋8×a×｛（e＋3）×2＋1＋MAX（e÷10，5）｝

　　＋512

　　｝÷1024

＋3.5＋↑（224×v×w）÷1024↑＋0.5

＋↑｛

　　↑（28＋（↑（32＋（（↑g÷127↑＋1）×2048＋128））÷32↑×32））

　　÷128↑×128

　　｝÷1024↑

　K

＋Σ（Li）

　i=1

●64ビットモードの場合

b×1.3

＋｛

　　↑↑b÷64↑×（8÷16）↑×4×4

　　＋12×｛（b÷3）＋1−mod（b÷3，2）｝

　　＋8×a×｛（e＋3）×2＋1＋MAX（e÷10，5）｝

　　＋1024

　　｝÷1024

＋3.5＋↑（224×v×w）÷1024↑＋0.5

＋↑｛

　　↑（56＋（↑（56＋（（↑g÷127↑＋1）×2048＋128））÷32↑×32））

　　÷128↑×128

　　｝÷1024↑

　K

＋Σ（Li）

　i=1

計算式2

（単位：バイト）

●32ビットモードの場合

500×1024

　　　＋（↑436×g÷16↑×16）＋496×h＋112×240

　　　＋5072×（e＋15）＋96×z

　　　＋32×m＋172×｛a×（e＋3）＋（e＋3）×2＋22｝＋16

　　　＋48×p＋36×｛（e＋3）×2＋1＋MAX（5，[e＋3]÷10）｝

　　　＋68×G＋152×120＋80＋64※１＋368※２

　　　＋（（↓（↑（g÷8）↑＋3）÷4↓）×4）×m

●64ビットモードの場合

500×1024

　　　＋（↑536×g÷16↑×16）＋512×h

　　　＋（↑136×240÷16↑×16）

　　　＋9424×（e＋15）＋144×z

　　　＋80×m＋336×｛a×（e＋3）＋（e＋3）×2＋22｝＋16

　　　＋64×p＋72×｛（e＋3）×2＋1＋MAX（5，[e＋3]÷10）｝

　　　＋68×G＋184×120＋96＋64※１＋448※２

　　　＋（（↓（↑（g÷8）↑＋7）÷8↓）×8）×m

計算式3

（単位：バイト）

●32ビットモードの場合

（32＋16×z）×（G＋1）＋16

●64ビットモードの場合

（48＋32×z）×（G＋1）＋16

計算式4

（単位：バイト）

●32ビットモードの場合

72＋52×H＋68×z

pd_dbbuff_trace_levelオペランドに1を指定する場合に加算します。

＋320×z

●64ビットモードの場合

96＋56×H＋72×z

pd_dbbuff_trace_levelオペランドに1を指定する場合に加算します。

＋640×z

計算式5

（単位：バイト）

●32ビットモードの場合

（32＋16×z）×10＋16

●64ビットモードの場合

（48＋32×z）×10＋16

注※1

pd_max_ard_processオペランドが1以上の場合に加算します。

注※2

再編成時期予測機能を使用する場合に加算します。

(3)　バックエンドサーバが使用する共用メモリの計算式

バックエンドサーバが使用する共用メモリの計算式を次に示します。

32ビットモードの場合（単位：キロバイト）

計算式1＋↑｛（↑（40＋（計算式2〜計算式6を加算した値））÷512↑×512）｝÷1024↑

64ビットモードの場合（単位：キロバイト）

計算式1＋↑｛（↑（72＋（計算式2〜計算式8を加算した値））÷512↑×512）｝÷1024↑

計算式で使用している変数については，「計算式で使用する変数」を参照してください。

計算式1〜8についての注意事項

次に示すどれかの条件を満たす場合に計算式3を加算します。

・pd_rdarea_open_attribute_useオペランドにYを指定する場合

・高速系切り替え機能を使用する場合

次に示すどれかの条件を満たす場合に計算式4を加算します。

・pd_dbsync_pointオペランドにcommitを指定する場合

・pd_shared_rdarea_useオペランドにYを指定する場合

・上記以外の場合，計算式6を加算します。

pd_dfw_awt_processオペランドを指定する場合に計算式5を加算します。

pd_bes_shmpool_sizeオペランドを省略すると，次の値が設定されます。

32ビットモードの場合：

↑｛（↑（40＋（計算式2〜計算式6の合計値））÷512↑×512）｝÷1024↑

64ビットモードの場合：

↑｛（↑（72＋（計算式2〜計算式8の合計値））÷512↑×512）｝÷1024↑

pd_max_resident_rdarea_noオペランドを指定する場合に計算式7を加算します。

pd_max_temporary_object_noの値が1以上の場合に計算式8を加算します。

条件 | 共用メモリの計算式

計算式1

（単位：キロバイト）

●32ビットモードの場合

b×1.3

＋｛

　　↑↑b÷64↑×（8÷16）↑×4×4

　　＋12×｛（b÷3）＋1−mod（b÷3，2）｝

　　＋8×a×｛（e＋3）×2＋1＋MAX（e÷10，5）｝＋512＋512※１

　｝÷1024

＋↑｛72＋8×v×（8＋3×w）｝÷1024↑

＋↑｛（↑g÷127↑＋1）×2048＋128｝÷1024↑

＋↑｛

　　↑（28＋（↑（32＋（（↑g÷127↑＋1）×2048＋128））÷32↑×32））

　　÷128↑×128｝

　　｝÷1024↑

　M

＋Σ（Ni）

　i=1

●64ビットモードの場合

b×1.3

＋｛

　　↑↑b÷64↑×（8÷16）↑×4×4

　　＋12×｛（b÷3）＋1−mod（b÷3，2）｝

　　＋8×a×｛（e＋3）×2＋1＋MAX（e÷10，5）｝＋1024＋512※１

　｝÷1024

＋↑｛72＋24×v×（2＋w）｝÷1024↑

＋↑｛

　　↑（56＋（↑（56＋（（↑g÷127↑＋1）×2048＋128））÷32↑×32））

　　÷128↑×128

　　｝÷1024↑

　M

＋Σ（Ni）

　i=1

計算式2

（単位：バイト）

●32ビットモードの場合

500×1024

　　＋（436＋48※１）×g＋496×h＋112×r

　　＋5072×（e＋15）＋96×z

　　＋32×m＋172×｛a×（e＋3）＋（e＋3）×2＋22｝＋16

　　＋48×p＋48×｛（e＋3）×2＋1＋MAX（5，[e＋3]÷10）｝

　　＋68×G＋152×F＋80＋32×g＋64※２

　　　＋（（↓（↑（g÷8）↑＋3）÷4↓）×4）×m

●64ビットモードの場合

500×1024

　　＋（536＋56※１）×g＋512×h＋136×r

　　＋9424×（e＋15）＋144×z

　　＋80×m＋336×｛a×（e＋3）＋（e＋3）×2＋22｝＋16

　　＋64×p＋96×｛（e＋3）×2＋1＋MAX（5，[e＋3]÷10）｝

　　＋68×G＋184×F＋96＋48×g＋64※２

　　　＋（（↓（↑（g÷8）↑＋7）÷8↓）×8）×m

計算式3

（単位：バイト）

●32ビットモードの場合

｛｛[（↑↑g÷8↑÷4↑）×4]＋8｝×（a×[e＋3]＋e＋15）｝

●64ビットモードの場合

｛｛[（↑↑g÷8↑÷8↑）×8]＋8｝×（a×[e＋3]＋e＋15）｝

計算式4

（単位：バイト）

●32ビットモードの場合

（32＋16×z）×（e×2＋7＋1）＋16

●64ビットモードの場合

（48＋32×z）×（e×2＋7＋1）＋16

計算式5

（単位：バイト）

●32ビットモードの場合

72＋52×H＋68×z

pd_dbbuff_trace_levelオペランドに1を指定する場合に加算します。

＋320×z

●64ビットモードの場合

96＋56×H＋72×z

pd_dbbuff_trace_levelオペランドに1を指定する場合に加算します。

＋640×z

計算式6

（単位：バイト）

●32ビットモードの場合

（32＋16×z）×10＋16

●64ビットモードの場合

（48＋32×z）×10＋16

計算式7 （単位：バイト） | 16＋112＋（48＋48×Q）＋ (48＋32×R）
計算式8 （単位：バイト） | 16＋80×S

注※1

pd_max_list_users及びpd_max_list_countオペランドの両方とも0でない場合に加算します。

注※2

pd_max_ard_processオペランドが1以上の場合に加算します。

(4)　計算式で使用する変数

ａ：pd_max_access_tablesオペランドの値

ｂ：pd_sql_object_cache_sizeオペランドの値

ｃ：pd_table_def_cache_sizeオペランドの値

ｄ：pd_auth_cache_sizeオペランドの値

ｅ：pd_max_usersオペランドの値 ※１

ｆ：バックエンドサーバの総数

ｇ：pd_max_rdarea_noオペランドの値

ｈ：pd_max_file_noオペランドの値

ｋ：pd_view_def_cache_sizeオペランドの値

ｍ：インデクス用のグローバルバッファプール数

pdbufferに-Dの指定がないものは１，指定があるものは分割数を合計したものがグローバルバッファプール数となります。

pd_dbbuff_modifyオペランドにYを指定している場合，該当するサーバに関連するpdbuffer文の数に，該当するサーバ定義のpd_max_add_dbbuff_noオペランドの値を加算して計算します。

ｐ：pd_lck_until_disconnect_cntオペランドの値

ｑ：MIN（e＋3，p）

ｒ：pd_assurance_index_noオペランドの値

ｓ：インストールしたプラグインの数

ｔ：DMLで使用するプラグイン関数の総数 ※２

ｕ：DMLで使用するプラグイン関数のパラメタ総数 ※２

ｖ：pd_max_list_usersオペランドの値

ｗ：pd_max_list_countオペランドの値

ｘ：pd_type_def_cache_sizeオペランドの値

ｙ：pd_routine_def_cache_sizeオペランドの値

ｚ：グローバルバッファ総数（pdbufferオペランドの指定数）

pdbufferに-Dの指定がないものは１，指定があるものは分割数を合計したものがグローバルバッファプール数となります。

pd_dbbuff_modifyオペランドにYを指定している場合，該当するサーバに関連するpdbuffer文の数に，該当するサーバ定義のpd_max_add_dbbuff_noオペランドの値を加算して計算します。

Ａ：pd_registry_cache_sizeオペランドの値

Ｆ：pd_assurance_table_noオペランドの値

Ｇ：サーバ内の最大トランザクション数（2×e＋7）

Ｈ：pd_dfw_awt_processオペランドの値

I：フロントエンドサーバで指定したpdplgprmオペランドの総数

Ji：フロントエンドサーバで指定したi番目のpdplgprmオペランドで指定した共用メモリのサイズ

K：ディクショナリサーバで指定したpdplgprmオペランドの総数

Li：ディクショナリサーバで指定したi番目のpdplgprmオペランドで指定した共用メモリのサイズ

M：バックエンドサーバで指定したpdplgprmオペランドの総数

Ni：バックエンドサーバで指定したi番目のpdplgprmオペランドで指定した共用メモリのサイズ

Q：pd_max_resident_rdarea_noオペランドの値

R：pd_max_resident_rdarea_shm_noオペランドの値

S：pd_max_temporary_object_noオペランドの値

U：空き領域の再利用機能を使用する表数

注※1

ディクショナリサーバの場合はpd_max_dic_processオペランドの値となります。バックエンドサーバの場合はpd_max_bes_processオペランドの値となります。ただし，pd_max_dic_process又はpd_max_bes_processオペランドを省略する場合は，pd_max_usersオペランドの値となります。

注※2

DMLで使用するプラグイン関数の総数及びDMLで使用するプラグイン関数のパラメタの総数は，次に示すSQLで求められます。

SELECT COUNT(*),SUM(N_PARAM) FROM MASTER.SQL_PLUGIN_ROUTINES
WHERE PLUGIN_NAME = 'プラグイン名称'
AND (TIMING_DESCRIPTOR = 'ADT_FUNCTION'
    OR TIMING_DESCRIPTOR IS NULL
    OR TIMING_DESCRIPTOR = 'BEFORE_INSERT'
    OR TIMING_DESCRIPTOR = 'AFTER_INSERT'
    OR TIMING_DESCRIPTOR = 'BEFORE_UPDATE'
    OR TIMING_DESCRIPTOR = 'AFTER_UPDATE'
    OR TIMING_DESCRIPTOR = 'BEFORE_DELETE'
    OR TIMING_DESCRIPTOR = 'AFTER_DELETE'
    OR TIMING_DESCRIPTOR = 'BEFORE_PURGE_TABLE'
    OR TIMING_DESCRIPTOR = 'AFTER_PURGE_TABLE'
    OR TIMING_DESCRIPTOR = 'INDEX_SEARCH'
    OR TIMING_DESCRIPTOR = 'INDEX_COUNT'
    OR TIMING_DESCRIPTOR = 'INDEX_INSERT'
    OR TIMING_DESCRIPTOR = 'INDEX_BEFORE_UPDATE'
    OR TIMING_DESCRIPTOR = 'INDEX_AFTER_UPDATE'
    OR TIMING_DESCRIPTOR = 'INDEX_DELETE'
    OR TIMING_DESCRIPTOR = 'PURGE_INDEX'
    OR TIMING_DESCRIPTOR = 'INDEX_MAINTENANCE_DEFERRED'
    OR TIMING_DESCRIPTOR = 'BEFORE_INSERT_DC'
    OR TIMING_DESCRIPTOR = 'BEFORE_UPDATE_DC'
    OR TIMING_DESCRIPTOR = 'BEFORE_DATA_CHECK'
    OR TIMING_DESCRIPTOR = 'AFTER_DATA_CHECK')

15.2.5　グローバルバッファが使用する共用メモリの計算式

(1)　影響分散スタンバイレス型系切り替え機能を使用しない場合

グローバルバッファが使用する共用メモリサイズは，ディクショナリサーバ又はバックエンドサーバごとに計算式1に代入して求めます。サーバマシンごとに算出する場合，pdbuffer文のオプションの指定によって計算対象になるかどうかが異なります。pdbuffer文のオプションによる計算条件を次の表に示します。

表15‒9　pdbuffer文のオプションによる計算条件（影響分散スタンバイレス型系切り替え機能を使用しない場合）

pdbuffer文のオプション | 計算条件
-r | -rで指定したRDエリアがあるサーバの場合，計算対象とします。
-i | -iで指定したインデクスが格納されているRDエリアがあるサーバの場合，計算対象とします。
-b | -bで指定したRDエリアがあるサーバの場合，計算対象とします。
-o | そのサーバにある全RDエリア中でpdbuffer -rで指定していないRDエリアがある場合，計算対象とします。

pd_dbbuff_modifyオペランドにYを指定している場合は，計算式2を加算します。計算式1及び2で求めた値を合計した値が，そのサーバでグローバルバッファが使用する共用メモリの所要量です。

pd_shm_reuseオペランドにYを指定している場合は，グローバルバッファが使用する共用メモリ所要量を計算式3で見積もってください。

pd_dbbuff_attributeオペランドにfixedを指定している場合，実メモリ上にページ固定されるため，仮想メモリを構成する実メモリがそのサイズ分減少します。また，残り実メモリとスワップ領域で構成される仮想メモリからもそのサイズ分確保されます。

pdbuffer文に-Dを指定している場合，分割した個々のグローバルバッファを一つのグローバルバッファとして計算します。例として，「pdbuffer -n 10000 -D 3」と指定した場合，「pdbuffer -n 3334」のグローバルバッファを1個と「pdbuffer -n 3333」のグローバルバッファを2個の計3個を指定したものとして計算します。

-n指定値が分割数×4より小さい場合，-nに4を指定した分割数分のpdbuffer文を指定したものとして計算します。例として，「pdbuffer -n 100 -D 100」と指定した場合，「pdbuffer -n 4」のグローバルバッファを100個指定したものとして計算します。

なお，pdbufferオペランドを省略した場合，HiRDBが共用メモリサイズを自動計算するので見積もりは必要ありません。

(a)　グローバルバッファが使用する共用メモリを実メモリ上に固定しない場合

グローバルバッファが使用する共用メモリを実メモリ上に固定しない場合（pd_dbbuff_attributeオペランドにfreeを指定した場合）は，次の計算式を使用します。

計算式の種類 | 共用メモリの計算式（単位：キロバイト）

計算式1

●32ビットモードの場合

n

Σ｛

i=1

　　↑｛752＋64＋（296＋64※１）×（Pi＋4）

　　＋（124＋80※２＋96×A×Mi）×Ui｝÷T↑×T

　　＋Si×｛Pi＋4＋（Ui×Mi×A）｝＋Vi

　　｝÷1024

●64ビットモードの場合

n

Σ｛管理領域部＋データ格納部｝÷1024

i=1

　　管理領域部：

　　　↑｛944＋64＋（480＋112※１）×（Pi＋4）

　　　＋（176＋96※２＋136×A×Mi）×Ui｝÷T↑×T

　　データ格納部：

　　　Si×｛Pi＋4＋（Ui×Mi×A）｝＋Vi

計算式2

●32ビットモードの場合

｛↑（↑（s×1024÷2）÷8↑＋112）÷2048↑×2048×

　↑a÷（s×1024）↑｝÷1024

●64ビットモードの場合

｛↑（↑（s×1024÷2）÷8↑＋144）÷2048↑×2048×

　↑a÷（s×1024）↑｝÷1024

計算式3

↑（計算式1＋計算式2※３＋

n

Σ｛管理領域部｝÷1024）÷（s×1024）↑×（s×1024）

i=1

　　管理領域部：

　　●32ビットモードの場合

　　　↑｛752＋64＋（296＋64※１）×（Pi＋4）

　　　＋（124＋80※２＋96×A×Mi）×Ui｝÷4096↑×4096

　　●64ビットモードの場合

　　　↑｛944＋64＋（480＋112※１）×（Pi＋4）

　　　＋（176＋96※２＋136×A×Mi）×Ui｝÷4096↑×4096

n：グローバルバッファプール数

i：計算対象のグローバルバッファプール定義

P：グローバルバッファ面数

A：

pd_max_ard_processオペランドが1以上の場合は2

pd_max_ard_processオペランドが0の場合は1

M：一括入力最大ページ数

U：同時実行最大プリフェッチ数

T：グローバルバッファのバウンダリ

pd_dbbuff_dev_sector_sizeオペランドに512を指定した場合は2048，4096を指定した場合は4096

S：グローバルバッファに割り当てたRDエリアの最大ページ長

V：

pd_dbbuff_dev_sector_sizeオペランドに4096を指定し，かつSが4096の倍数でない場合は2048。

pd_dbbuff_dev_sector_sizeオペランドに4096を指定していない，又はSが4096の倍数の場合は0。

s：SHMMAX指定値

a：計算式1の総計

注※1　LOB用グローバルバッファの場合に加算します。

注※2　pd_max_ard_processオペランドが1以上の場合に加算します。

注※3　pd_dbbuff_modifyオペランドにYを指定した場合に加算します。

(b)　グローバルバッファが使用する共用メモリを実メモリ上に固定する場合

グローバルバッファが使用する共用メモリを実メモリ上に固定する場合（pd_dbbuff_attributeオペランドにfixedを指定した場合）は，次の計算式を使用します。

計算式の種類 | 共用メモリの計算式（単位：キロバイト）

計算式1

●32ビットモードの場合

n

Σ｛

i=1

　　↑｛↑｛752＋64＋（296＋64※１）×（Pi＋4）

　　＋（124＋80※２＋96×A×Mi）×Ui｝÷T↑×T

　　＋Si×｛Pi＋4＋（Ui×Mi×A）｝＋Vi｝÷p↑×p

　　｝÷1024

●64ビットモードの場合

n

Σ｛↑｛管理領域部＋データ格納部｝÷p↑×p｝÷1024

i=1

　　管理領域部：

　　　↑｛944＋64＋（480＋112※１）×（Pi＋4）

　　　＋（176＋96※２＋136×A×Mi）×Ui｝÷T↑×T

　　データ格納部：

　　　Si×｛Pi＋4＋（Ui×Mi×A）｝＋Vi

計算式2

●32ビットモードの場合

｛↑｛↑（↑（s×1024÷2）÷8↑＋112）÷2048↑×2048×

　↑a÷（s×1024）↑｝÷p↑×p｝÷1024

●64ビットモードの場合

｛↑｛↑（↑（s×1024÷2）÷8↑＋144）÷2048↑×2048×

　↑a÷（s×1024）↑｝÷p↑×p｝÷1024

計算式3

↑（計算式1＋計算式2※３＋

n

Σ｛管理領域部｝÷1024）÷（↑（s×1024÷p）↑×p）↑

i=1

×（↑（s×1024÷p）↑×p）

　　管理領域部：

　　●32ビットモードの場合

　　　↑｛752＋64＋（296＋64※１）×（Pi＋4）

　　　＋（124＋80※２＋96×A×Mi）×Ui｝÷4096↑×4096

　　●64ビットモードの場合

　　　↑｛944＋64＋（480＋112※１）×（Pi＋4）

　　　＋（176＋96※２＋136×A×Mi）×Ui｝÷4096↑×4096

n：グローバルバッファプール数

i：計算対象のグローバルバッファプール定義

P：グローバルバッファ面数

A：

pd_max_ard_processオペランドが1以上の場合は2

pd_max_ard_processオペランドが0の場合は1

M：一括入力最大ページ数

U：同時実行最大プリフェッチ数

T：グローバルバッファのバウンダリ

pd_dbbuff_dev_sector_sizeオペランドに512を指定した場合は2048，4096を指定した場合は4096

S：グローバルバッファに割り当てたRDエリアの最大ページ長

V：

pd_dbbuff_dev_sector_sizeオペランドに4096を指定し，かつSが4096の倍数でない場合は2048。

pd_dbbuff_dev_sector_sizeオペランドに4096を指定していない，又はSが4096の倍数の場合は0。

p：WindowsのLarge Pageでのページサイズ

pdntenvコマンドで確認できます。

s：SHMMAX指定値

a：計算式1の総計

注※1　LOB用グローバルバッファの場合に加算します。

注※2　pd_max_ard_processオペランドが1以上の場合に加算します。

注※3　pd_dbbuff_modifyオペランドにYを指定した場合に加算します。

(2)　影響分散スタンバイレス型系切り替え機能を使用する場合

影響分散スタンバイレス型系切り替え機能を使用する場合，ユニットごとに計算式1に代入して求めます。ユニットごとに算出する場合，pdbuffer文のオプションの指定によって計算対象になるかどうかが異なります。pdbuffer文のオプションによる計算条件を次の表に示します。

表15‒10　pdbuffer文のオプションによる計算条件（影響分散スタンバイレス型系切り替え機能を使用する場合）

pdbuffer文のオプション | 計算条件
-r，-b | -rで指定したRDエリアで，同じHAグループに属するRDエリアの場合，計算対象とします。
-i | -iで指定したインデクスが格納されているRDエリアが，同じHAグループに属するRDエリアの場合，計算対象とします。
-o | 同じHAグループ内で，pdbuffer -rオプションで指定していないRDエリアがある場合，計算対象とします。

pd_shm_reuseオペランドにYを指定している場合は，グローバルバッファが使用する共用メモリ所要量を計算式2で見積もってください。

pd_dbbuff_attributeオペランドにfixedを指定している場合，実メモリ上にページ固定されるため，仮想メモリを構成する実メモリがそのサイズ分減少します。また，残り実メモリとスワップ領域で構成される仮想メモリからもそのサイズ分確保されます。なお，pdbufferオペランドを省略した場合，HiRDBが共用メモリサイズを自動計算するので見積もりは必要ありません。

(a)　グローバルバッファが使用する共用メモリを実メモリ上に固定しない場合

グローバルバッファが使用する共用メモリを実メモリ上に固定しない場合（pd_dbbuff_attributeオペランドにfreeを指定した場合）は，次の計算式を使用します。

計算式の種類 | 共用メモリの計算式（単位：キロバイト）

計算式1

●32ビットモードの場合

n

Σ｛

i=1

　　（96＋（（752×（A＋B））＋（288×（F＋（8×（A＋B））））

　　＋8×F×（A＋B）＋16）＋H＋D）＋V

　　＋2048＋G＋（E×F＋（8×（A＋B）））

　　｝÷1024

●64ビットモードの場合

n

Σ｛管理領域部＋データ格納部｝÷1024

i=1

　　管理領域部：

　　　（（144＋（（944×（A＋B））＋（464×（F＋（8×（A＋B））））

　　　＋（16×F×（A＋B））））＋16＋H＋D）

　　データ格納部：

　　　2048＋G＋（E×F＋（8×（A＋B）））＋V

計算式2

↑（計算式1＋

n

Σ｛管理領域部｝÷1024）÷（s×1024）↑×（s×1024）

i=1

　　管理領域部：

　　●32ビットモードの場合

　　　（96＋（（752×（A＋B））＋（288×（F＋（8×（A＋B））））

　　　＋8×F×（A＋B）＋16）＋H＋D）

　　●64ビットモードの場合

　　　（（144＋（（944×（A＋B））＋（464×（F＋（8×（A＋B））））

　　　＋（16×F×（A＋B））））＋16＋H＋D）

n：このユニットに割り当てられるグローバルバッファプール数

i：計算対象のグローバルバッファプール定義

A：ホストBES数

B：受け入れ可能なゲストBESの最大数

C：一括入力ページ数（pdbuffer -pに指定した値）

D：プリフェッチ機能使用時（pdbuffer -m指定）に加算します。

32ビットモードの場合

2×（（（80×U×C）＋（80×U）＋（124×U）＋（8×U×C））×（A＋B））

64ビットモードの場合

2×（（（112×U×C）＋（96×U）＋（176×U）＋（16×U×C））×（A＋B））

E：pdbuffer文のオプションの指定によって値が異なります。オプションと計算式を次に示します。

pdbuffer文のオプション | 最大値の計算式
-r，-b | （MAX（バッファサイズ(pdbuffer -lの値），MAX（指定したRDエリアで同じHAグループに属するRDエリアのページサイズ）））
-i | （MAX（バッファサイズ（pdbuffer -lの値），MAX（-iで指定したインデクスが格納されているRDエリアが同じHAグループに属するRDエリアのページサイズ）））
-o | （MAX（バッファサイズ（pdbuffer -lの値），MAX（同じHAグループ内でpdbuffer -rオプションで指定していないRDエリアのページサイズ）））

F：バッファ面数（pdbuffer -nの値）

G：プリフェッチ機能使用時（pdbuffer -m指定）に加算します。

2×（（E×U×C）×（A＋B））

H：LOB用RDエリアが指定されている（pdbuffer -b指定）場合に加算します。

32ビットモードの場合：64×（F＋（8×（A＋B）））

64ビットモードの場合：112×（F＋（8×（A＋B）））

U：同時実行最大プリフェッチ数（pdbuffer -mの値）

V：

pd_dbbuff_dev_sector_sizeオペランドに4096を指定し，かつEが4096の倍数でない場合は2048。

pd_dbbuff_dev_sector_sizeオペランドに4096を指定していない，又はEが4096の倍数の場合は0。

(b)　グローバルバッファが使用する共用メモリを実メモリ上に固定する場合

グローバルバッファが使用する共用メモリを実メモリ上に固定する場合（pd_dbbuff_attributeオペランドにfixedを指定した場合）は，次の計算式を使用します。

計算式の種類 | 共用メモリの計算式（単位：キロバイト）

計算式1

●32ビットモードの場合

n

Σ｛

i=1

　　｛↑｛（96＋（（752×（A＋B））＋（288×（F＋（8×（A＋B））））

　　＋8×F×（A＋B）＋16）＋H＋D）＋V

　　＋2048＋G＋（E×F＋（8×（A＋B）））｝÷p↑｝×p

　　｝÷1024

●64ビットモードの場合

n

Σ｛↑｛管理領域部＋データ格納部｝÷p↑×p｝÷1024

i=1

　　管理領域部：

　　　（（144＋（（944×（A＋B））＋（464×（F＋（8×（A＋B））））

　　　＋（16×F×（A＋B））））＋16＋H＋D）

　　データ格納部：

　　　2048＋G＋（E×F＋（8×（A＋B）））＋V

計算式2

↑（計算式1＋

n

Σ｛管理領域部｝÷1024）÷（↑（s×1024÷p）↑×p）↑

i=1

×（↑（s×1024÷p）↑×p）

　　管理領域部：

　　●32ビットモードの場合

　　　（96＋（（752×（A＋B））＋（288×（F＋（8×（A＋B））））

　　　＋8×F×（A＋B）＋16）＋H＋D）

　　●64ビットモードの場合

　　　（（144＋（（944×（A＋B））＋（464×（F＋（8×（A＋B））））

　　　＋（16×F×（A＋B））））＋16＋H＋D）

n：このユニットに割り当てられるグローバルバッファプール数

i：計算対象のグローバルバッファプール定義

A：ホストBES数

B：受け入れ可能なゲストBESの最大数

C：一括入力ページ数（pdbuffer -pに指定した値）

D：プリフェッチ機能使用時（pdbuffer -m指定）に加算します。

32ビットモードの場合

2×（（（80×U×C）＋（80×U）＋（124×U）＋（8×U×C））×（A＋B））

64ビットモードの場合

2×（（（112×U×C）＋（96×U）＋（176×U）＋（16×U×C））×（A＋B））

E：pdbuffer文のオプションの指定によって値が異なります。オプションと計算式を次に示します。

pdbuffer文のオプション | 最大値の計算式
-r，-b | （MAX（バッファサイズ(pdbuffer -lの値），MAX（指定したRDエリアで同じHAグループに属するRDエリアのページサイズ）））
-i | （MAX（バッファサイズ（pdbuffer -lの値），MAX（-iで指定したインデクスが格納されているRDエリアが同じHAグループに属するRDエリアのページサイズ）））
-o | （MAX（バッファサイズ（pdbuffer -lに指定した値），MAX（同じHAグループ内でpdbuffer -rオプションで指定していないRDエリアのページサイズ）））

F：バッファ面数（pdbuffer -nの値）

G：プリフェッチ機能使用時（pdbuffer -m指定）に加算します。

2×（（E×U×C）×（A＋B））

H：LOB用RDエリアが指定されている（pdbuffer -b指定）場合に加算します。

32ビットモードの場合：64×（F＋（8×（A＋B）））

64ビットモードの場合：112×（F＋（8×（A＋B）））

U：同時実行最大プリフェッチ数（pdbuffer -mの値）

V：

pd_dbbuff_dev_sector_sizeオペランドに4096を指定し，かつEが4096の倍数でない場合は2048。

pd_dbbuff_dev_sector_sizeオペランドに4096を指定していない，又はEが4096の倍数の場合は0。

p：WindowsのLarge Pageでのページサイズ

pdntenvコマンドで確認できます。

15.2.6　SQL実行時に必要なメモリ所要量の計算式

(1)　グループ分け高速化機能実行時に必要なメモリ所要量の求め方

クライアント環境定義でPDSQLOPTLVLオペランドを指定するか，HiRDBシステム定義でpd_optimize_levelオペランドを指定（又は省略）した場合，適用条件を満たすSQLを実行すると，グループ分け高速化機能が働きます。このとき，HiRDBはクライアント環境定義のPDAGGRオペランドの値に基づいてプロセス固有領域を確保します。確保するメモリサイズを次に示します。

グループ分け高速化機能実行時に必要なメモリ所要量は，バックエンドサーバを定義するサーバマシンについてだけ計算してください。

計算式

e＋↑d÷4↑×4＋↑（17＋4×a＋4×b＋c＋d）÷4↑×4×（N＋1）
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（単位：バイト）

ａ：グループ化する列の数

ｂ：集合関数の演算数

COUNT，SUM，MAX，MINは一つにつき1で換算します。

AVG（COUNT），AVG（SUM）は一つにつき2で換算します。

ｃ：グループ化する列の列長（表「グループ化するときの列の長さ及び集合関数の演算領域の長さ」を参照して求めてください）

ｄ：集合関数の演算領域長（表「グループ化するときの列の長さ及び集合関数の演算領域の長さ」を参照して求めてください）

ｅ：32ビットモードの場合：MAX（4×N×24 ，16408）

64ビットモードの場合：MAX（8×N×40 ，32808）

Ｎ：クライアント環境定義のPDAGGRオペランドの値

表15‒11　グループ化するときの列の長さ及び集合関数の演算領域の長さ

列のデータ型 | グループ化する列の列長 | 集合関数の演算領域長※１
INTEGER | 4 | 6
SMALLINT | 2 | 4※２
DECIMAL(p,s) | ↑（p＋1）÷2↑ | ↑（p＋7）÷2↑※３
FLOAT | 8 | 10
SMALLFLT | 4 | 6
INTERVAL YEAR TO DAY | 5 | 8
INTERVAL HOUR TO SECOND | 4 | 6
CHAR(n) | n | n＋3
VARCHAR(n) | n＋2 | n＋5
NCHAR(n) | 2×n | 2×n＋2
NVARCHAR(n) | 2×n＋2 | 2×n＋4
MCHAR(n) | n | n＋3
MVARCHAR(n) | n＋2 | n＋5
DATE | 4 | 6
TIME | 3 | 6
BLOB(n) | − | −
BINARY(n) | n＋2 | n＋5

（凡例）−：該当しません。

注※1

集合関数がCOUNTの場合，集合関数演算領域長はデータ型にかかわらず6になります。

注※2

集合関数がAVG，SUMの場合，集合関数演算領域長は6になります。

注※3

集合関数がAVG，SUMの場合，集合関数演算領域長は次の値になります。

集合関数の値の型がDECIMAL型で精度が29けたのとき：18

集合関数の値の型がDECIMAL型で精度が38けたのとき：23

集合関数の値のデータ型の規則については，マニュアル「HiRDB SQLリファレンス」の「集合関数」を参照してください。

(2)　列ごとのデータ抑制指定時に必要なメモリ所要量の求め方

列ごとのデータ抑制を指定（CREATE TABLEの列定義にSUPPRESSを指定）した表に対してアクセスするときに使用するメモリサイズは，次に示す計算式で求められます。

計算式

a＋128　　（単位：バイト）

ａ：表中の列ごとのデータ抑制が指定されている列の定義長の合計値

(3)　ハッシュジョイン及び副問合せのハッシュ実行時に必要なメモリ所要量の求め方

クライアント環境定義でPDADDITIONALOPTLVLオペランドを指定するか，HiRDBシステム定義でpd_additional_optimize_levelオペランドを指定すると，SQL拡張最適化オプションが働きます。このSQL拡張最適化オプションで，「ハッシュジョイン，副問合せのハッシュ実行の適用（APPLY_HASH_JOIN）」を指定した場合，表の結合又は副問合せのSQLを実行すると，次に示すメモリサイズのプロセス固有領域を確保します。

計算式

●32ビットモードの場合
 a
Σ（13×1024＋6×1024×ｂ＋ｃ）
i=1

●64ビットモードの場合
 a
Σ（13×1024＋7×1024×ｂ＋ｃ）
i=1
　　　　　　　　　　　　　　　（単位：バイト）

ａ：SELECT文のハッシュジョイン最大数

SELECT文のハッシュジョイン最大数については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

ｂ：ハッシュ表行数によって適用されるハッシュジョイン処理を求めて，次に示す表から代入する値を決定してください。

ハッシュ表行数の目安 | 適用されるハッシュジョイン処理 | ｂの値
1500以内 | 一括ハッシュジョイン | 0.5
1500×（バケット分割数÷3）以内 | バケット分割 ハッシュジョイン | 1レベルバケット分割 | 1
1500×（バケット分割数÷3）²以内 | 2レベルバケット分割 | 2
1500×（バケット分割数÷3）²を超える場合 | 3レベルバケット分割 | 3

ハッシュ表行数：ジョインの場合はジョインの内表件数です。副問合せの場合は探索条件中の外への参照列を含む述語を除いた副問合せ探索件数です。

バケット分割数：MIN｛↓（ハッシュ表サイズ÷2）÷ハッシュ表ページ長↓，64｝

ハッシュ表サイズ：HiRDBシステム定義のpd_hash_table_sizeオペランド，又はクライアント環境変数のPDHASHTBLSIZEオペランドで指定した値です。

ハッシュ表ページ長：次に示す表からｃ（ハッシュ表最大行長）に対応するハッシュ表ページ長を選択してください。

ハッシュ表最大行長 | ハッシュ表ページ長（単位：バイト）
0〜1012 | 4096
1013〜2036 | 8192
2037〜4084 | 16384
4085〜16360 | 32768
16361〜32720 | ↑（ハッシュ表最大行長＋48）÷2048↑×2048

ｃ：ハッシュ表最大行長

ハッシュ表最大行長については，マニュアル「HiRDB UAP開発ガイド」を参照してください。

(4)　スナップショット方式指定時に必要なメモリ所要量の求め方

pd_pageaccess_modeオペランドを省略した場合又はSNAPSHOTを指定した場合，スナップショット方式を適用するSQL文を実行すると，データベース検索時のページアクセス方式にスナップショット方式を使用します。このとき，表又はインデクスの格納RDエリアのページサイズに基づいて，動的に次に示すメモリサイズのプロセス固有領域を確保します。

計算式

a×2　　（単位：バイト）

ａ：検索対象の表又はインデクスが格納されているRDエリア中の最大ページ長。

ただし，LOB用RDエリアは除きます。

(5)　先頭からn行の検索結果を取得する機能実行時に必要なメモリ所要量の求め方

先頭からn行の検索結果を取得する機能を使用すると，検索結果の先頭（又はユーザが指定した先頭からのオフセット行数分読み飛ばした位置）からn行取得できます。

LIMIT句に指定した行数が1以上で，（オフセット行数＋LIMIT句に指定した行数）の値が32,767以下の場合，（オフセット行数＋LIMIT句に指定した行数）以内に入り得る行をメモリに保持します。確保するプロセス固有領域のメモリサイズは，次に示す計算式で求められます。なお，（オフセット行数＋LIMIT句に指定した行数）の値が32,768以上になる場合は作業表を作成するため，「作業表用ファイルの容量の見積もり」を参照してください。

計算式

｛100＋（a＋2）×（オフセット行数＋LIMIT句に指定した行数）｝×b　　（単位：バイト）

ａ：行長

行長は32,720バイト以下でなければなりません。行長は次の計算式で求められます。

 m
Σ（Ai）＋2×m＋4＋c
i=1
　　　　　　　　　　　　　　　　　　　　（単位：バイト）

m：選択式，GROUP BY句，又はORDER BY句に指定した列数

FOR UPDATE句を指定した場合は1を加算してください。ただし，選択式にROWを指定している場合は表の全列数になります。

Ai：先頭n行保持領域に格納する行のi番目の列データ長

列のデータ長については，表「データ長一覧」を参照し，dに定義長を代入して求めてください。

ただし，BLOBデータ，定義長が256バイト以上の文字データ（各国・混在文字データも含む），BINARYデータのうち，下記に属さない列の場合は12バイトになります。

DISTINCT句指定の選択式に指定する列

UNION [ALL]によって集合演算対象となっている問合せ指定中の選択式

ORDER BY句に指定した列

また，FOR UPDATE句を指定した場合に，mに加算した1に対応するAiは12バイトとします。

c：8

ただし，次の場合は0になります。

検索対象の表にEXモードで排他が掛かっている場合

WITHOUT LOCKを指定した場合

グループ分け高速化機能を指定した場合

複数の表を結合する場合

b：先頭n行保持領域数

先頭n行保持領域数は次の計算式で求められます。

1＋UNION [ALL]句指定数

(6)　探索条件にインデクス型プラグイン専用関数を指定したSQL文実行時に必要なメモリ所要量の求め方

探索条件にインデクス型プラグイン専用関数を指定したSQL文の実行時に確保するプロセス固有領域のメモリサイズは，次に示す計算式で求められます。

計算式

a×500＋（20＋6）×800＋16　　（単位：バイト）

ａ：行長。行長は次の計算式で求められます。

 m
Σ（Ai）＋4×（m＋2）＋12＋4＋8
i=1
　　　　　　　　　　　　　　　　　　　　　　　　（単位：バイト）

m：選択式，結合条件，GROUP BY句，又はORDER BY句に指定した列数

FOR UPDATE句を指定した場合は1を加算してください。ただし，選択式にROWを指定している場合は表の全列数になります。

Ai：取り出す行のi番目の列データ長

列のデータ長については，表「データ長一覧」を参照し，dに定義長を代入して求めてください。

ただし，BLOBデータ，又は定義長が256バイト以上の文字データ（各国・混在文字データも含む）で，下記に属さない列の場合は12バイトになります。

結合条件中に指定する列（結合列）

DISTINCT句指定の選択式に指定する列

限定述語の副問合せ中の選択式に指定する列

IN述語の副問合せ中の選択式に指定する列

UNION [ALL]，又はEXCEPT [ALL]によって集合演算対象となっている問合せ指定中の選択式

ORDER BY句に指定した列

また，FOR UPDATE句を指定した場合に，mに加算した1に対応するAiは12バイトとします。

(7)　拡張SQLエラー情報出力機能使用時に必要なメモリ所要量の求め方

拡張SQLエラー情報出力機能を使用した場合，次のときにプロセス固有領域を確保します。

(a)　OPEN文実行時

計算式

●32ビットモードの場合
（16＋16×m）＋a
●64ビットモードの場合
（16＋24×m）＋a
　　　　　　　　　　　　　　　　　　　　　　　　（単位：バイト）

a：？パラメタ又は埋込み変数のデータ長の合計

　m

a=Σ（ai）

　i=1

ｍ：SQL文中の？パラメタ又は埋込み変数の数

ai：i番目の？パラメタ又は埋込み変数のデータ長

データ長については，表「埋込み変数又は？パラメタのデータ長」を参照して算出します。

(b)　定義系SQLのPREPARE文実行時

計算式

SQL文長＋20　　（単位：バイト）

(8)　部分構造インデクスの定義，又は部分構造インデクスを定義した表の更新時に必要なメモリ所要量の求め方

(a)　部分構造インデクスの定義時

定義系SQLのCREATE INDEXで部分構造インデクスを定義する場合に確保するプロセス固有領域は，次に示す計算式で求められます。

計算式

（インデクスキー長※×100＋64）　　（単位：バイト）

注※

表に定義する部分構造インデクスの最大定義長です。

(b)　部分構造インデクスを定義した表の更新時

操作系SQLのINSERT，UPDATE，又はDELETEで部分構造インデクスを定義した表を更新する場合に確保するプロセス固有領域は，次に示す計算式で求められます。

計算式

（インデクスキー長※１×100＋64＋128）＋Σ（インデクスキー長＋128）※２　　（単位：バイト）

注※1

表に定義している部分構造インデクスの最大定義長です。

注※2

USING UNIQUE TAG指定の部分構造インデクス数です。

(9)　圧縮列に対して操作系SQLを実行する場合に必要なメモリ所要量の求め方

SQL実行時，データの格納，及び抽出対象に圧縮列が含まれる場合，次に示すメモリサイズのプロセス固有領域を確保します。

計算式

MIN（圧縮分割サイズ，圧縮列の定義長）※×C＋L　　（単位：バイト）

C：次に示すどれかの条件に該当する場合は2。該当しない場合は1。

SUBSTR関数を使用している

POSITION関数を使用している

後方削除更新をしている

L：SQLの実行対象となる圧縮表が格納されているRDエリアのページ長

複数のRDエリアが対象になる場合は，最大のページ長で計算する。

注※

SQLの実行対象となる全圧縮列の中で最大になる値で計算します。

(10)　バックエンドサーバで使用するSQL実行用通信メモリ所要量の求め方

SQL文実行時，FES−BES間，及びBES−BES間で使用する通信で，次に示すメモリサイズのプロセス固有領域を確保します。

計算式

4×1024×
（2×1SQLで指定する表の最大数
　×表の最大分割BES数÷システム内BES数
　＋フロータブルサーバ数※×システム内BES数×2
　＋2×フロータブルサーバ数※）　　（単位：バイト）

注※

フロータブルサーバを使用するSQLの中で指定している表の最大数を指定してください。フロータブルサーバを使用しないSQLだけの場合は0を指定してください。フロータブルサーバを使用するSQLの詳細は，マニュアル「HiRDB UAP開発ガイド」の「フロータブルサーバの割り当て方法」を参照してください。

15.2.7　SQL前処理時に必要なメモリ所要量の計算式

(1)　ストアドプロシジャを使用しない場合に必要なメモリ所要量の求め方

ストアドプロシジャを使用しない場合，SQL前処理時に確保するメモリサイズは，次に示す計算式で求められます。

計算式

↑｛
　　（2539＋Si×70＋Pi×20＋Ti×980＋Ci×68＋Wi×818＋Ki×416＋Li×5
　　＋Di×116＋Ari×108＋Gi×44＋Ori×10＋Sli×40＋Upi×96＋Fi×90
　　＋Ti×Cwi×48＋MAX（Pi，Wpi）×52＋MAX（Ti，Sli−1）×96
　　＋MAX（Ti×2，Wi）×24＋MAX（Ti×3，Wi）×24
　　＋MAX｛MAX（Ti，Ori＋Gi＋Si＋Fi），Sli−1｝×24
　｝×1.2 ÷1024↑×CLS
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（単位：キロバイト）

Si：SQL文中の検索項目数

Pi：SQL文中の埋込み変数，？パラメタ又はSQLパラメタの数

Ti：SQL文中の表名の数

Ci：SQL文中の列名の数

Wi：SQL文中の論理演算子（AND及びOR）に出てくる述語の数

Ki：SQL文中の定数の数

Li：SQL文中の定数の長さの合計（単位：バイト）

Di：SQL文中に定義された格納条件の総数

Ari：SQL文中の四則演算及び連結演算の数

Gi：SQL文中のGROUP BY句に指定した列の数

Ori：SQL文中のORDER BY句に指定した列指定又はソート項目指定番号の数

Fi：SQL文中の集合関数及びスカラ関数の総数

Sli：SQL文中の問合せ指定の数

Upi：SQL文中の更新列数

Cwi：SQL文中のCASE式中のWHENの数

Wpi：SQL文中のWITH句に対応する変数の数

CLS：SQLオブジェクト内の一つのアクセスパスが生成される領域の数※

注※

SQLオブジェクト内の一つのアクセスパスが生成される領域の数は，次に示す計算式で求められます。

計算式

SELECT_APSLが適用されている場合※
　a＋b×4＋c＋d＋e×2
SELECT_APSLが適用されていない場合※
　a＋b＋c＋d＋e

a：フロントエンドサーバ数

フロントエンドサーバ数は1を指定します。

b：表数

表数は次に示す計算式で求めます。

実表数＋相関名数

c：集合演算サーバ数

集合関数の指定がある場合は1を，指定がない場合は0を指定します。

d：GROUP BY句，DISTINCT又はORDER BY句がある問合せ指定の数

e：ジョインサーバ数

ジョインサーバ数は次に示す計算式で求めます。

b−SQL文中の問合せ指定の数

注※

SELECT_APSLが適用されているかどうかについては，アクセスパス表示ユティリティ（pdvwopt）を使用すると分かります。アクセスパス表示ユティリティ（pdvwopt）については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

(2)　ストアドプロシジャを使用する場合に必要なメモリ所要量の求め方

ストアドプロシジャを使用する場合，SQL前処理時に確保するメモリサイズ（単位：キロバイト）は，「ストアドプロシジャを使用しない場合に必要なメモリ所要量の求め方」の計算式で求めた値に，ストアドプロシジャごとのプロシジャ制御用オブジェクト長を加算します。プロシジャ制御用オブジェクト長の計算式については，システム共通定義のpd_sql_object_cache_sizeオペランドの1ストアドプロシジャのプロシジャ制御用オブジェクト長を参照してください。1ストアドプロシジャのプロシジャ制御用オブジェクト長については，マニュアル「HiRDB システム定義」の「1ルーチンのルーチン制御用オブジェクト長の計算式」を参照してください。

15.2.8　BLOB型データの検索又は更新時に必要なメモリ所要量の計算式（フロントエンドサーバの場合）

BLOB型データの検索又は更新時に必要なメモリ所要量は次に示す計算式で求められます。

計算式

ａ＋ｂ＋7　　　（単位：キロバイト）

ａ：1SQL文中に指定するBLOB型入力変数又は出力変数で，実行するSQL文の中で次に示す計算式の結果が最大となる値です。

↑｛
 c
Σ（BLOB型入力変数iの実長※１×2＋58）＋
i=1
 d
Σ（BLOB型出力変数jの定義長※２＋26）
j=1
｝÷1024↑

注※１

埋込み変数でUAPからHiRDBサーバに受け渡されたBLOB型データの実際の長さです。

注※２

HiRDBからUAPに返却するBLOB型データを受け取るUAPの埋込み変数の宣言長です。

ｂ：同時オープン中のカーソルで結合検索を行うSQL文の組み合わせで，次に示す計算式の結果が最大となる値です。

256×同時オープン中のカーソル数

ｃ：入力変数の数

ｄ：出力変数の数

15.2.9　BLOB型データの検索又は更新時に必要なメモリ所要量の計算式（バックエンドサーバ又はディクショナリサーバの場合）

BLOB型データの検索又は更新時に必要なメモリ所要量は次に示す計算式で求められます。

計算式

ａ＋ｂ
　　　　　　　　　　　　　　　　　　　　　　　　　　（単位：キロバイト）

ａ：1SQL文中に指定するBLOB型入力変数又は出力変数について，実行するSQL文の中で，次に示す計算式の結果が最大となる値です。

↑｛
 c
Σ（BLOB型入力変数iの実長※＋118＋70×出力変数の数）
i=1
｝÷1024↑

注※

埋込み変数でUAPからHiRDBサーバに受け渡されたBLOB型データの実際の長さです。

ｂ：同時オープン中のカーソルでBLOB型データの検索を行うSQL文の組み合わせで，次に示す計算式の結果が最大となる値です。

d
Σ｛280＋184×（SQLiに記述した表数＋1）｝
i=1

ｃ：入力変数の数

ｄ：カーソル数

15.2.10　ブロック転送又は配列FETCHで必要なメモリ所要量の計算式（フロントエンドサーバの場合）

ブロック転送又は配列FETCHで必要なメモリ所要量は，次の計算式で求められます。

条件 | PDBLKBUFFSIZEオペランドの指定値
省略又は0 | 1以上
FETCH文のINTO句に配列型の埋込み変数を指定する | 計算式1
FETCH文のINTO句に配列型の埋込み変数を指定しない | PDBLKFオペランドを省略又は1 | − | 計算式2
PDBLKFオペランドが2以上 | 計算式1

（凡例）−：該当しません。

計算式1

↑｛864＋16×ａ＋（6×ａ＋2×d＋ｂ）×ｃ｝÷1024↑
　　　　　　　　　　　　　　　　　　　　　　　　　　（単位：キロバイト）

ａ：SELECT句で指定する検索項目数

ｂ：FETCH文で受け取る検索結果中の1行のデータ長（各列の最大長の合計。単位はバイト）

ｃ：PDBLKFオペランドの指定値又は配列数

ｄ：SELECT句で指定する検索項目で，BINARY型を指定した選択式の数

計算式2

MAX（X₁，X₂）
　　　　　　　　　　　　　　　　　　　　　　　　　　（単位：キロバイト）

X₁：↑（864＋22×a＋2×c＋b）÷1024↑

X₂：PDBLKBUFFSIZEオペランドの値

ａ：SELECT句で指定する検索項目数

ｂ：FETCH文で受け取る検索結果中の1行のデータ長（実際に取得する各列の長さの合計。単位はバイト）

ｃ：SELECT句で指定する検索項目で，BINARY型を指定した選択式の数

15.2.11　インメモリデータ処理で必要なメモリ所要量

インメモリデータ処理で必要なメモリ所要量は次に示す計算式で求められます。

HiRDB/パラレルサーバの場合は，サーバマシンごとにインメモリ化するRDエリアを見積もってください。

計算式

●インメモリデータバッファが使用する共用メモリを実メモリ上に固定しない場合
計算式１＋D×2　　（単位：キロバイト）
●インメモリデータバッファが使用する共用メモリを実メモリ上に固定する場合
計算式１＋D×↑（↑2048÷p↑×p）÷1024↑　　（単位：キロバイト）

計算式1

●インメモリデータバッファが使用する共用メモリを実メモリ上に固定しない場合
n
Σ　↑｛736＋32×A＋48＋448×B＋2048＋C×B｝÷1024↑　　（単位：キロバイト）
i=1
●インメモリデータバッファが使用する共用メモリを実メモリ上に固定する場合
n
Σ　↑{↑（736＋32×A＋48＋448×B＋2048＋C×B）÷p↑×p｝÷1024↑　　（単位：キロバイト）
i=1

n：インメモリRDエリアの数

A：インメモリRDエリアを構成するHiRDBファイル数

B：インメモリRDエリアの総ページ数

C：インメモリRDエリアのページサイズ

D：計算式2の値

p：WindowsのLarge Pageでのページサイズ

　pdntenvコマンドで確認できます。

計算式2（インメモリデータバッファが使用する共用メモリセグメント数）

↑計算式１の値÷（SHMMAXオペランドの値×1024）↑

計算式2で求めた値は，pd_max_resident_rdarea_shm_noオペランドの見積もりに使います。

16　RDエリアの容量の見積もり

この章では，各RDエリアの容量の見積もり方法について説明します。

16.1　ユーザ用RDエリアの容量の見積もり

ここでは，ユーザ用RDエリアの容量の見積もり方法について説明します。

16.1.1　ユーザ用RDエリアの容量の計算方法

(1)　ユーザ用RDエリアの容量の求め方

ユーザ用RDエリアの容量は，次に示す計算式で求めます。

計算式

ユーザ用RDエリアの容量（単位：バイト）
　　　　　　　＝ユーザ用RDエリアのページ長※1×ユーザ用RDエリアの総ページ数※2

注※1

データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で指定するページ長です。

注※2

「ユーザ用RDエリアの総ページ数を求める計算式」を参照してください。

(2)　ユーザ用RDエリアの総ページ数を求める計算式

ユーザ用RDエリアの総ページ数は，次に示す計算式で求めます。

計算式

ユーザ用RDエリアの総ページ数（単位：ページ）
　　　＝ディレクトリページ部分の総ページ数＋データページ部分の総ページ数

(a)　ディレクトリページ部分の総ページ数の計算式

ディレクトリページ部分の総ページ数（単位：ページ）＝
　　6×（n＋1）＋↑20480÷P↑×2
　　　n
　　＋Σ｛↑di÷b↑＋↑di÷f↑｝
　　 i=1

n：ユーザ用RDエリアを構成するHiRDBファイル数

P：ユーザ用RDエリアのページ長（バイト）

b：↓（P−20）÷（↑S÷32↑×8＋56）↓

f：↓（125×P）÷（16×b）↓×b

di：データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で指定する各HiRDBファイルのセグメント数

S：データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で指定する1セグメントのページ数（セグメントサイズ）

(b)　データページ部分の総ページ数の計算式

データページ部分の総ページ数（単位：ページ）＝
　　　e
　　　Σ｛↑αi÷S↑×S｝
　　 i=1
　　　e
　　＋Σ｛↑βi÷S↑×S｝
　　 i=1
　　　k
　　＋Σ｛↑（γi＋1）÷S↑×S｝
　　 i=1

e：ユーザ用RDエリアに格納する表の総数

k：ユーザ用RDエリアに格納するインデクスの総数

S：データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で指定する1セグメントのページ数（セグメントサイズ）

αi：各表の分岐するとしたBINARY列以外の列を格納するために必要なページ数

「表の格納ページ数の計算方法」を参照してください。

βi：各表の分岐するとしたBINARY列を格納するために必要なページ数

「表の格納ページ数の計算方法」を参照してください。

γi：各インデクスを格納するために必要なページ数

「インデクスの格納ページ数の計算方法」を参照してください。

16.1.2　表の格納ページ数の計算方法

CREATE TABLEでFIX指定をするかどうかによって，表の格納ページ数の計算方法が異なります。それぞれの計算方法を「FIX指定がない場合」と「FIX指定がある場合」に説明します。「FIX指定がない場合」及び「FIX指定がある場合」の計算式中で使用する変数については，「計算式中で使用する変数」で説明しています。表の格納ページ数の計算例については，「表の格納ページ数の計算例」で説明しています。また，リバランス機能を使用する場合のRDエリア容量見積もりを「リバランス機能を使用する場合のエリア容量見積もり」で説明しています。

なお，表を横分割する場合，格納RDエリアごとにページ数を求めてください。

(1)　FIX指定がない場合

FIX指定がない場合の表の格納ページ数は，次に示す計算式で求めます。

計算式

表の格納ページ数＝
　分岐するとしたBINARY列以外を格納するページ数
＋分岐するとしたBINARY列を格納するページ数　　　　（単位：ページ）

・分岐するとしたBINARY列以外を格納するページ数

・分岐するとしたBINARY列を格納するページ数

SPN2

(a)　Pの求め方

Pの求め方を次に示します。なお，Pの分母の括弧部は1ページに格納される行数であり，最小1，最大255とします。

(b)　PSiの求め方

PSiの求め方を次に示します。次に示す計算式で各PSiを計算し，その総和を求めてください。なお，nは表「可変長文字列型のデータ長一覧（抽象データ型及び繰返し列を除く）」に該当する列の数を示しています。

PSi＝a×↑ei÷（b−62）↑

(2)　FIX指定がある場合

FIX指定がある場合の表の格納ページ数は，次に示す計算式で求めます。

計算式

(a)　Qの求め方

Qの求め方を次に示します。なお，Qの分母の括弧部は1ページに格納される行数であり，最小1，最大255とします。

(3)　計算式中で使用する変数

a：表に格納する行の総数（件）

b：ユーザ用RDエリアのページ長（バイト）

c：CREATE TABLEで指定する未使用領域の比率（％）

未使用領域の比率を指定しない場合は，30％を仮定して計算します。

di：各列のデータ長（バイト）

表「データ長一覧」を参照して，すべての列について求めてください。

抽象データ型の列のデータ長については，「抽象データ型の列のデータ長の求め方」を参照してください。

繰返し列のデータ長については，「繰返し列のデータ長の求め方」を参照してください。

ei：列のデータ長の平均値（バイト〉

既定義型で定義された列の場合，表「可変長文字列型のデータ長一覧（抽象データ型及び繰返し列を除く）」を参照して，表中に示したデータ型の列についてだけ求めてください。

抽象データ型で定義された列の場合，表「可変長文字列型のデータ長一覧（抽象データ型の場合）」を参照して，表中に示したデータ型の列についてだけ求めてください。

繰返し列の場合，表「可変長文字列型のデータ長一覧（繰返し列の場合）」を参照して，表中に示したデータ型の列についてだけ求めてください。

f：表に定義する列の総数（個）

g：表を格納するRDエリアのセグメントサイズ（ページ）

h：CREATE TABLEで指定するセグメント内の空きページ比率（％）

セグメント内の空きページ比率を指定しない場合は，10％を仮定して計算します。ここでいう空きページとは，未使用ページのことです。

Z：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がALL，又は，ONLY_USERの場合：0

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合：510

SPN1：分岐するとした列（BINARY以外）を格納するページ数

なお，分岐する条件については表「データ長一覧」の注※5で説明しています。

SPN1＝
　 f
　Σ↑分岐するとしたdiの値÷（b−61）↑×a×SF
　i=1

SPN2：分岐するとしたBINARY列を格納するページ数

なお，分岐する条件については表「データ長一覧」の注※5で説明しています。

SPN2＝SPN2A＋SPN2B＋SPN2C

・INSERT SQLによる分岐ページ数
　分岐するとしたBINARY列について計算します。
　SPN2A＝
　　 k
　｛Σ↓Li÷（b−59）↓×a＋A｝×SF
　　i=1

・pdload又はpdrorgによる分岐ページ数
　Li＞（b−2853）÷255 のとき
　SPN2B＝
　　　 k
　↑｛Σ（Li＋11）×a｝÷（b−48）↑×SF
　　　i=1
　Li≦（b−2853）÷255 のとき
　SPN2C＝
　↑a÷255↑×SF

Aの計算式を次に示します。

k：分岐するとした列の数

Li：各列の実際のデータ長（バイト）

圧縮列の場合は次の計算式の値になります。

圧縮後のデータ長＋（↑圧縮前のデータ長÷圧縮分割サイズ↑）×8

SF：1.3

ただし，次に示す場合は1.3より大きくしてください。

抽象データ型の列を大量に更新する場合

繰返し列に対して要素のデータ長が大きくなる更新又は要素数が増える更新を大量に実行する場合

VARCHAR，NVARCHAR，MVARCHAR，又はBINARY型の列に対してデータ長が大きくなる更新を大量に実行する場合

BINARY型の列に，データ長が大きくなる更新を大量に実行する場合

列ごとのデータ抑制が実行された列に対して，データ長が大きくなる更新を大量に実行する場合

前記以外のデータ型で，NULL値から非NULL値への更新を大量に実行する場合

表16‒1　データ長一覧

分類 | データ型及び条件 | データ長 （単位：バイト）
数値データ | INTEGER | 4
SMALLINT | 2
LARGE DECIMAL(m,n)　※1 | ↓m÷2↓ ＋1※2
FLOAT又はDOUBLE PRECISION | 8
SMALLFLT又はREAL | 4
文字データ | CHARACTER(n) | n※3
VARCHAR(n) | d≦255 | 繰返し列の要素 | d＋2
上記以外 | d＋1
d≧256 | 6

VARCHAR(n)

ノースプリット

オプション

指定あり

n≦255

抽象データ型の属性

d＋3

繰返し列の要素 | d＋2
上記以外 | d＋1
n≧256 | 分岐する場合※5 | 6
分岐しない場合※5 | 抽象データ型の属性 | d＋3
繰返し列の要素 | d＋2
上記以外 | d＋3
各国文字データ | NCHAR(n)又はNATIONAL CHARACTER(n) | 2×n ※4
NVARCHAR(n) | d≦127 | 繰返し列の要素 | 2×d＋2
上記以外 | 2×d＋1
d≧128 | 6

NVARCHAR(n)

ノースプリット

オプション

指定あり

n≦127

抽象データ型の属性

2×d＋3

繰返し列の要素 | 2×d＋2
上記以外 | 2×d＋1
n≧128 | 分岐する場合※5 | 6
分岐しない場合※5 | 抽象データ型の属性 | 2×d＋3
繰返し列の要素 | 2×d＋2
上記以外 | 2×d＋3
混在文字データ | MCHAR(n) | n※3
MVARCHAR(n) | d≦255 | 繰返し列の要素 | d＋2
上記以外 | d＋1
d≧256 | 6

MVARCHAR(n)

ノースプリット

オプション

指定あり

n≦255

抽象データ型の属性

d＋3

繰返し列の要素 | d＋2
それ以外 | d＋1
n≧256 | 分岐する場合※5 | 6
分岐しない場合※5 | 抽象データ型の属性 | d＋3
繰返し列の要素 | d＋2
上記以外 | d＋3
日付データ | DATE | 4
時刻データ | TIME | 3
日間隔データ | INTERVAL YEAR TO DAY | 5
時間隔データ | INTERVAL HOUR TO SECOND | 4
時刻印データ | TIMESTAMP(n) | 7＋（n÷2）
長大データ | BLOB | 9
バイナリデータ | BINARY(n) | n≦255 | d＋3
n≧256 | 分岐する場合※5 | 15
分岐しない場合※5 | d＋3
BINARY(n) 圧縮指定あり | 分岐する場合※5 | 15
分岐しない場合※5 | γ＋9

d：実際のデータ長（文字数）

m，n：正の整数

γ：圧縮後のデータ長（文字数）

注※1

全体のけた数がmけたで，小数点以下のけた数がnけたの固定小数点数です。mを省略した場合は15を仮定します。

注※2

表定義時に表オプションにSUPPRESS DECIMALを指定した場合，データ長は「↓k÷2↓＋2」になります。kは，格納時の有効けた数（先頭の0の部分を除いたけた数）を示します。なお，次に示す場合はSUPPRESS DECIMALを使用しないでください。計算式中のaは，SUPPRESS DECIMAL又は列データ抑制指定を使用しない場合の，表中の列のデータ長の合計値です。

32717＜（a＋表中の列数×2＋8）

注※3

列データ抑制指定をして，データ抑制された場合，nは「n−b＋4」になります。なお，データ抑制は，列データ抑制指定時，列データの最後の文字が空白の場合，その最後の文字と連続している半角の空白が4文字以上あるときだけ実行されます。bは，列データの最後の文字と連続している空白の数を示します。

ただし，列データ抑制指定をして，データ抑制されなかった場合は，列ごとに1バイトの付加情報が追加されます。

なお，次に示す場合は列データ抑制指定を使用しないでください。計算式中のaは，SUPPRESS DECIMAL又は列データ抑制指定を使用しない場合の，表中の列のデータ長の合計値です。

32717＜（a＋表中の列数×2＋8）

注※4

列データ抑制指定をして，データ抑制された場合，2×nは「2×n−2×b＋5」になります。なお，データ抑制は，列データ抑制指定時，列データの最後の文字が空白の場合，その最後の文字と連続している全角の空白が3文字以上あるときだけ実行されます。bは，列データの最後の文字と連続している空白の数を示します。

ただし，列データ抑制指定をして，データ抑制されなかった場合は，列ごとに1バイトの付加情報が追加されます。

なお，次に示す場合は列データ抑制指定を使用しないでください。計算式中のaは，SUPPRESS DECIMAL又は列データ抑制指定を使用しない場合の，表中の列のデータ長の合計値です。

32717＜（a＋表中の列数×2＋8）

注※5

通常は分岐しない場合で計算します。次に示す計算式が成立する場合に分岐します。なお，圧縮列の場合，データ長は圧縮前のデータ長で計算してください。

BL＞ページ長−50
　　　　　　　　 f
ＢＬ（バイト）＝Σ di＋2×f＋6
　　　　　　　　i=1

この分岐条件が成立した場合は，分岐しないとした列を列番号の小さい方から分岐条件が成立しなくなるまで分岐するとしてBLを計算し直してください。

表16‒2　可変長文字列型のデータ長一覧（抽象データ型及び繰返し列を除く）

データ型 | データ長 （バイト）
VARCHAR(n) | d≧256 | d＋2
ノースプリットオプション指定あり | 0
NVARCHAR(n) | d≧128 | 2×d＋2
ノースプリットオプション指定あり | 0
MVARCHAR(n) | d≧256 | d＋2
ノースプリットオプション指定あり | 0

d：実際のデータ長（文字数）

(4)　抽象データ型の列のデータ長の求め方

抽象データ型の列のデータ長diは，次に示す計算式で求めます。

計算式

  　 h
di＝ Σ ADTk＋5
  　 k=1

h：抽象データ型の継承の数（個）

継承なしの場合は1

CREATE TYPE文でUNDERオペランドを指定して別の抽象データ型を継承した場合，最も上位の抽象データ型をh番目，最も下位の抽象データ型を1番目としてください。

ADTk：抽象データ型のデータ長（バイト）

次に示す計算式で求めてください。

    　 m
ADTk＝ Σ attj＋10＋2×m
    　i=1

m：抽象データ型の全属性数（個）

attj：抽象データ型の各属性のデータ長（バイト）

継承がない場合は，m=1であり，ADT₁を計算します。

各属性のデータ長については，表「データ長一覧」を参照してください。ただし，データ型が表「可変長文字列型のデータ長一覧（抽象データ型の場合）」で示す条件を満たしている場合は，表「可変長文字列型のデータ長一覧（抽象データ型の場合）」に従ってデータ長を計算してください。

また，対応するattejの値を次に示す計算式に代入して，分岐行格納ページ数ADTLSをPに加算してください。

     　 h
ADTLS＝ Σ ↑attej÷（b−62）↑×a
     　i=1

属性が抽象データ型で定義されている場合は，次に示す計算式で属性のデータ長を求めてください。

    　　　　　　 h
attj（バイト）＝ Σ ADTk＋5
    　　　　　　k=1

表16‒3　可変長文字列型のデータ長一覧（抽象データ型の場合）

データ型 | 条　件 | データ長 attj （バイト） | 分岐部分の データ長 attej（バイト）
VARCHAR(n) | d≧256 | 8 | d＋2
ノースプリットオプション指定あり | d＋3 | 0
NVARCHAR(n) | d≧128 | 8 | 2×d＋2
ノースプリットオプション指定あり | 2×d＋3 | 0
MVARCHAR(n) | d≧256 | 8 | d＋2
ノースプリットオプション指定あり | d＋3 | 0

d：実際のデータ長（文字数）

(5)　繰返し列のデータ長の求め方

繰返し列のデータ長は，次に示す計算式で求めます。

計算式

di＝4＋（eli＋1）×eni

eli：繰返し列のデータ長

表「データ長一覧」から求めてください。

ただし，可変長文字列型の場合は，表「可変長文字列型のデータ長一覧（繰返し列の場合）」から求めてください。

eni：繰返し列の平均要素数

表16‒4　可変長文字列型のデータ長一覧（繰返し列の場合）

データ型 | 条件 | データ長 eli （バイト） | 分岐部分の データ長 esj（バイト）
VARCHAR(n) | d≧256 | 5 | d＋2
ノースプリットオプション指定あり | d＋2 | 0
NVARCHAR(n) | d≧128 | 5 | 2×d＋2
ノースプリットオプション指定あり | 2×d＋2 | 0
MVARCHAR(n) | d≧256 | 5 | d＋2
ノースプリットオプション指定あり | d＋2 | 0

d：実際のデータ長（文字数）

可変長文字列型の繰返し列で，eliの値が表「可変長文字列型のデータ長一覧（繰返し列の場合）」の条件を満たす列について，次に示す計算式の値をPに加算してください。

　m
↑Σ｛ esi×eni＋14×（eni−1）｝÷（b−62）↑×a
 i=1

m：表「可変長文字列型のデータ長一覧（繰返し列の場合）」の条件を満たす可変長文字列型の繰返し列数

esi：1要素当たりの実際のデータ長の平均値

表「可変長文字列型のデータ長一覧（抽象データ型及び繰返し列を除く）」に示したデータ長を適用します。

(6)　リバランス機能を使用する場合のエリア容量見積もり

ハッシュ関数HASHA，HASHB，HASHC，HASHD，HASHE，HASHFを使用した分割表の場合，データは1,024個のハッシュ要素値に分けられ，値ごとに別々のセグメントに格納されます。

各分割RDエリアには，平均（1024÷分割数）のハッシュ要素数のデータが格納されます。このため，各RDエリアには，少なくともそのRDエリアに格納される要素数分のセグメントを割り当てる必要があります。

リバランス機能を使用する場合のRDエリア容量は次のように見積もります。

データ件数Ｎ，行長L，ページ長Ｐから，必要な総セグメント数Snを見積もります。

RDエリア当たりに必要なセグメント数Ssnを見積もります。

Ssn＝↑Sn÷Srn↑×Srn

Srn：↑1024÷Dvn↑

Dvn：RDエリア分割数

余裕値を考慮して，RDエリア当たりの使用中セグメント数Sを見積もります。

S＝↑（Ssn×K）÷Srn↑×Srn

K：係数（例：余裕率20%の場合，1.2）

(7)　表の格納ページ数の計算例

(a)　例題

次に示す在庫表の表格納ページ数を求めます。

品番 | 商品名 | 規格 | 単価 | 数量 | 原価
20180 | 掃除機 | C20 | 20000 | 26 | 15000
20190 | 掃除機 | C77 | 28000 | 105 | 23000
20130 | 冷蔵庫 | P10 | 30000 | 70 | 25000
20220 | テレビ | K18 | 35000 | 12 | 30000
20200 | 掃除機 | C89 | 35000 | 30 | 30000
20140 | 冷蔵庫 | P23 | 35000 | 60 | 30000
20280 | アンプ | L10 | 38000 | 200 | 33000
20150 | 冷蔵庫 | P32 | 48000 | 50 | 43000
20290 | アンプ | L50 | 49800 | 260 | 45000
20230 | テレビ | K20 | 50000 | 15 | 45000
20160 | 冷蔵庫 | P35 | 55800 | 120 | 50000

計算条件

表に格納する行の総数：10000件

ユーザ用RDエリアのページ長：8192バイト

CREATE TABLEで指定する未使用領域の比率：30％

列数：6列

表を格納するRDエリアのセグメントサイズ：100ページ

CREATE TABLEで指定するセグメント内の空きページ比率：40％

列のデータ型：次に示します。

品番：CHARACTER(5)

商品名：NCHAR(4)

規格：CHARACTER(3)

単価：INTEGER

数量：INTEGER

原価：INTEGER

システム共通定義pd_dbreuse_remaining_entriesオペランドを指定していない

FIX指定がない場合

1.　行長の計算

5（品番）＋2×4（商品名）＋3（規格）＋4（単価）＋4（数量）＋4（原価）＝28バイト

2.　Pの計算

3.　表の格納ページ数の計算

FIX指定がある場合

1.　行長の計算

5（品番）＋2×4（商品名）＋3（規格）＋4（単価）＋4（数量）＋4（原価）＝28バイト

2.　Qの計算

3.　表の格納ページ数の計算

16.1.3　インデクスの格納ページ数の計算方法

インデクスの格納ページ数の計算方法を「計算方法」で説明します。「計算方法」の計算式中で使用する変数については「計算式中で使用する変数」で説明しています。インデクスの格納ページ数の計算例については「インデクスの格納ページ数の計算例」で説明しています。

なお，CREATE TABLEでクラスタキーを指定する場合，インデクスの格納ページ数を求める方法と同じ方法で，クラスタキーの格納ページ数を求めてください。

また，インデクスを横分割する場合，格納RDエリアごとにページ数を求めてください。

注意事項

インデクスページスプリットが発生すると，インデクスページ内のキーの格納比率を50：50にして二つのインデクスページに分割します。このため，インデクスの追加又は更新が多く発生すると，インデクスの格納ページ数は最大で見積もり式の2倍の容量が必要となります。また，最大キーが格納されたリーフページのインデクスページスプリットは，UAPからのINSERTであってもPCTFREEオペランドの値が考慮されます。

なお，インデクスページスプリットの発生回数を削減する方法の一つにアンバランスインデクススプリットがあります。インデクスページスプリット及びアンバランスインデクススプリットについては，マニュアル「HiRDB システム運用ガイド」を参照してください。

(1)　計算方法

インデクスの格納ページ数は，次に示す計算式で求めます。

計算式

　　　　　　　　　　　　　　　　　　　　　 n
インデクスの格納ページ数（単位：ページ）＝ Σ Pi＋Pd
　　　　　　　　　　　　　　　　　　　　　i=1

Piは，計算式1に示す漸化式から求めます。

Pn＝1となるまでPi＋1の計算をし，その計算結果の総計を求めてください。

Pdは，キー値の重複が201以上の場合に計算します。Pdの求め方を計算式2に示します。

計算式1

計算式2

繰返し列を含むインデクスの場合の1行当たりの繰返し要素の重複数について

繰返し列を含むインデクスの場合，1行当たりの繰返し要素の重複数は，次に示す計算式の値を超えないようにしてください。

重複数＝↓（↓a×0.95↓−82）÷4↓−1

(2)　計算式中で使用する変数

a：ユーザ用RDエリアのページ長（バイト）

b：CREATE INDEXで指定する未使用領域の比率※１（％）

c：キー値の重複が200以下のキーの種類の個数（個）※２，３，４

d：キー値の重複が200以下のキーの重複数の平均値（個）※３，５

e：キー値の重複が201以上のキーの種類の個数（個）※３，４

f：キー値の重複が201以上のキーの重複数の平均値（個）※３，５

g：DB格納キー長※６（バイト）

h：次に示すどちらかを代入します。

ユニークインデクスの場合：ナル値以外のキーの種類の個数（個）

なお，複数列インデクスの場合は，構成列にナル値を含まない全キー数となります。

ユニークインデクス以外の場合：0

注※1

未使用領域の比率を指定しない場合は，30％を仮定して計算します。また，クラスタキーを指定する場合は，CREATE TABLEで指定する未使用領域の比率とします。

注※2

ユニークインデクスの重複がないキーを含める必要があります。

注※3

c×d＋e×fの値が，インデクスのキーの総数以上になるように計算してください。

注※4

ユニークインデクスの重複があるキー（キー値にナル値を含むことで重複するキー）を含める必要があります。

注※5

小数点未満は整数値に切り上げてください。

注※6

表「インデクスのキー長一覧」を参照してください。DB格納キー長は，次に示す計算式で求めます。

単一列インデクス及び固定長複数列インデクスの場合

↑キー長÷4↑×4

可変長複数列インデクスで，かつキー長255バイト以下の場合

↑（キー長＋1）÷4↑×4

可変長複数列インデクスで，かつキー長256バイト以上の場合

↑（キー長＋2）÷4↑×4

ただし，複数列インデクスのキー長は，表「インデクスのキー長一覧」を基に全構成列のキー長を加算したものとなります。

表16‒5　インデクスのキー長一覧

分類 | データ型 | キー長（単位：バイト）
キー長が255バイト以下 | キー長が256バイト以上
単一列 インデクス | 複数列インデクス | 単一列 インデクス | 複数列インデクス
固定長※1 | 可変長※2 | 固定長※1 | 可変長※2
数値 データ | INTEGER | 4 | 5 | 6 | − | 5 | 7
SMALLINT | 2 | 3 | 4 | − | 3 | 5
LARGE DECIMAL (m,n)※3 | ↓m÷2↓ ＋1 | ↓m÷2↓＋2 | ↓m÷2↓＋3 | − | ↓m÷2↓＋2 | ↓m÷2↓＋4
FLOAT又は DOUBLE PRECISION | 8 | × | × | − | × | ×
SMALLFLT 又はREAL | 4 | × | × | − | × | ×
文字 データ | CHARACTER (n) | n | n＋1 | n＋2 | n | n＋1 | n＋3
VARCHAR(n) | a＋1 | − | a＋2 | a＋2 | − | a＋3
各国 文字 データ | NCHAR(n) 又はNATIONAL CHARACTER (n) | 2×n | 2×n＋1 | 2×n＋2 | 2×n | 2×n＋1 | 2×n＋3
NVARCHAR (n) | 2×b＋1 | − | 2×b＋2 | 2×b＋2 | − | 2×b＋3
混在 文字 データ | MCHAR(n) | n | n＋1 | n＋2 | n | n＋1 | n＋3
MVARCHAR (n) | a＋1 | − | a＋2 | a＋2 | − | a＋3
日付 データ | DATE | 4 | 5 | 6 | − | 5 | 7
時刻 データ | TIME | 3 | 4 | 5 | − | 4 | 6
日間隔 データ | INTERVAL YEAR TO DAY | 5 | 6 | 7 | − | 6 | 8
時間隔 データ | INTERVAL HOUR TO SECOND | 4 | 5 | 6 | − | 5 | 7
時刻印 データ | TIMESTAMP(p) | 7＋（p÷2） | 8＋（p÷2） | 9＋（p÷2） | − | 8＋（p÷2） | 10＋（p÷2）

a：実際のデータ長

b：実際の文字数

m，n，p：正の整数

×：インデクス定義時にエラーになります。

−：該当しません。

注

最初は「キー長が255バイト以下」で計算してください。その結果，キー長が256バイト以上になる場合は，「キー長が256バイト以上」で再計算してください。

注※1

構成列が固定長の列だけのインデクスのキー長です。

注※2

構成列に可変長の列を含むインデクスのキー長です。

注※3

全体のけた数がmけたで，小数点以下のけた数がnけたの固定小数点数です。mを省略した場合は15を仮定します。

参考

非ユニークインデクスは，インデクスのデータの格納領域中に重複数を格納する領域を持つため，その分容量が大きくなります。一方，ユニークインデクスは重複数を格納する領域を持ちません。そのため，非ユニークインデクスよりもユニークインデクスの方が容量が小さくなります。

(3)　インデクスの格納ページ数の計算例

(a)　例題1

次に示す在庫表の「品番」をユニークインデクス（重複するキーがない）とする場合のインデクス格納ページ数を求めます。

品番 | 商品名 | 規格 | 単価 | 数量 | 原価
20180 | 掃除機 | C20 | 20000 | 26 | 15000
20190 | 掃除機 | C77 | 28000 | 105 | 23000
20130 | 冷蔵庫 | P10 | 30000 | 70 | 25000
20220 | テレビ | K18 | 35000 | 12 | 30000
20200 | 掃除機 | C89 | 35000 | 30 | 30000
20140 | 冷蔵庫 | P23 | 35000 | 60 | 30000
20280 | アンプ | L10 | 38000 | 200 | 33000
20150 | 冷蔵庫 | P32 | 48000 | 50 | 43000
20290 | アンプ | L50 | 49800 | 260 | 45000
20230 | テレビ | K20 | 50000 | 15 | 45000
20160 | 冷蔵庫 | P35 | 55800 | 120 | 50000

計算条件

インデクスのキーの総数：10,000件

ユーザ用RDエリアのページ長：8,192バイト

CREATE INDEXで指定する未使用領域の比率：30％

インデクスのデータ型：CHARACTER

インデクスのキー長：5バイト

キーの重複数：1

計算式

(b)　例題2

例題1に示す在庫表の「商品名」をインデクス（重複するキーがある）とする場合のインデクス格納ページ数を求めます。

計算条件

インデクスのキーの総数：10,000件

ユーザ用RDエリアのページ長：8,192バイト

CREATE INDEXで指定する未使用領域の比率：30％

インデクスのデータ型：NCHAR

インデクスのキー長：4文字（漢字）

キー値の重複が201以上のキーの種類の個数

（このときの平均重複数は250）：1

キー値の重複が200以下のキーの種類の個数

（このときの平均重複数は5）：（10000−250）÷5＝1950

計算式

次に示す会員表の「性別」と「入会年度」を複数列インデクスとする場合のインデクス格納ページ数を求めます。

会員番号 | 氏名 | 年齢 | 性別 | 入会年度
0001 | 安東洋子 | 18 | F | 1983
0002 | 浅井順一 | 25 | M | 1967
0003 | 石井公子 | 24 | F | 1987
0004 | 石井一郎 | 25 | M | 1964
・ ・ ・ | ・ ・ ・ | ・ ・ ・ | ・ ・ ・ | ・ ・ ・
1000 | 渡辺英雄 | 30 | M | 1995

計算条件

インデクスのキーの総数：10,000件

ユーザ用RDエリアのページ長：8,192バイト

CREATE INDEXで指定する未使用領域の比率：30％

1964年度の入会人数：1,000人

ほかの年度の入会人数：200人以下

入会年度：1965〜1995の31年間

入会する男女の数は，毎年同数とします。

列のデータ型：次に示します。

会員番号：CHARACTER(5)

氏名：NCHAR(4)

年齢：INTEGER

性別：CHARACTER(4)

入会年度：INTEGER

計算式

1965年度以降の31年間に入会した人（男，女含めて200人以下）のキーの種類の個数（c）は，c＝31×2＝62となります。

重複数の平均値（d）は，d＝（10000−1000）÷62＝146となります。

1964年の1年間に入会した人（男，女含めて1000人）のキーの種類の個数（e）は，e＝2となります。

重複数の平均値（f）は，f＝1000÷2＝500となります。

性別と入会年度のDB格納キー長（g）は，

g＝↑（4＋1＋5）÷4↑×4＝12となります。

16.2　データディクショナリ用RDエリアの容量の見積もり

データディクショナリ用RDエリアは，データベース構成変更ユティリティ（pdmod）のcreate rdarea文の指定によって次に示す2種類作成できます。

通常のデータディクショナリ用RDエリア

create rdarea文にdatadictionary，又はdatadictionary of routinesを指定

解析情報表及び運用履歴表を格納するデータディクショナリ用RDエリア

create rdarea文にdatadictionary of dbmanagementを指定

上記のRDエリアは，それぞれの種類ごとに容量を見積もる必要があります。

16.2.1　通常のデータディクショナリ用RDエリアの容量の見積もり

(1)　データディクショナリ用RDエリアの容量の求め方

create rdarea文にdatadictionary又はdatadictionary of routinesを指定する場合のデータディクショナリ用RDエリアの容量は，次に示す計算式で求めます。

計算式

データディクショナリ用RDエリアの容量（単位：バイト）
　＝a×b×1.3＋c×125＋1600000
●拡張システム定義スカラ関数を定義する場合に加算します。
　＋1933312

a：データディクショナリ用RDエリアのページ長※１

b：データディクショナリ用RDエリアの総ページ数※２

c：データディクショナリ用RDエリアのセグメントサイズ※３

注※1

データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で指定するページ長です。

注※2

「表の格納ページ数＋インデクスの格納ページ数」です。「表の格納ページ数の計算方法」及び「インデクスの格納ページ数の計算方法」を参照してください。

注※3

データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で指定するセグメントサイズです。

(2)　表の格納ページ数の計算方法

表の格納ページ数（単位：ページ）は，計算式1〜計算式24の総和になります。

(a)　計算式1

ディクショナリ表名 | 計算式
SQL_TABLES | [図データ]
SQL_COLUMNS | [図データ]
SQL_DIV_TABLE | [図データ]

ａ：表の総数（個）

ｂ：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

ｃ：列の名称長の平均値（バイト）

ｄ：表を格納するRDエリアの名称長の平均値（バイト）

ｅ：表の注釈長の平均値（バイト）

ｆ：表の横分割条件を指定する列の名称長の平均値（バイト）

ｇ：表の列数の平均値（個）

ｈ：認可識別子の長さの平均値（バイト）

ｉ：表識別子の長さの平均値（バイト）

ｊ：列の注釈長の平均値（バイト）

ｋ：ビュー表の基になる表の認可識別子の長さの平均値（バイト）

ｍ：ビュー表の基になる表の表識別子の長さの平均値（バイト）

ｎ：ビュー表の基になる表の列の名称長の平均値（バイト）

ｐ：ユーザ定義型の名称長の平均値（バイト）

ｑ：表の横分割条件数の平均値（個）

ｔ：PLUGIN句指定長の平均値（バイト）

ｖ：分割キーの長さの平均値（バイト）

ｗ：挿入履歴保持列の名称の平均値（バイト）

ｙ：DEFAULT句に指定した既定値の実長の平均値（バイト）

実長の算出方法は，マニュアル「HiRDB UAP開発ガイド」の「SQL記述領域に設定するデータコードとデータの長さ」を参照してください。

Ａ：DEFAULT句に指定した既定値の長さの平均値（バイト）

指定した既定値が定数の場合は，定数表現の長さです。既定値の長さを長く変更する可能性がある場合は変更後の長さを考慮して算出してください。文字型の定数の場合，各国文字列定数を表すN，混在文字列定数を表すM，16進文字列定数を表すX，引用符（’）を長さに含みます。それ以外は指定した既定値のバイト数です。

（例）

'HiRDB'：7バイト

N'ＨｉＲＤＢ'：13バイト

X'4869524442'：13バイト

CURRENT_TIME：12バイト

100：3バイト

Ｂ：表の横分割条件長の平均値（バイト）

Ｃ：表格納用RDエリア指定数（個）

(b)　計算式2

ディクショナリ表名 | 計算式
SQL_INDEXES | [図データ]
SQL_INDEX_ COLINF | [図データ]
SQL_DIV_INDEX | [図データ]
SQL_EXCEPT | [図データ]
SQL_INDEX_ DATATYPE | [図データ]
SQL_INDEX_ FUNCTION | [図データ]
SQL_INDEX_ XMLINF | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：表識別子の長さの平均値（バイト）

c：インデクスの総数（個）

d：インデクス識別子の長さの平均値（バイト）

e：1インデクス当たりのインデクス除外キー値数の平均値（個）

f：認可識別子の長さの平均値（バイト）

g：列の名称長の平均値（バイト）

i：表の横分割条件数の平均値（個）

j：インデクスを格納するRDエリアの名称の長さの平均値（バイト）

k：インデクスを構成する列数の平均値（個）

m：インデクス型名称の長さの平均値（バイト）

n：PLUGIN句指定長の平均値（バイト）

p：プラグインインデクス適用関数名称の長さの平均値（バイト）

q：抽象データ型名称の長さの平均値（バイト）

r：属性名称の長さの平均値（バイト）

s：1プラグインインデクス当たりの適用関数の数（個）

t：プラグインインデクスの総数（個）

u：部分構造パス長の平均値（バイト）

v：部分構造インデクスを構成する部分構造パス数の平均値（個）

w：データ長が256バイト以上で，かつ分岐するバイナリデータ（部分構造パス用解析ツリー）数の平均値（個）

バイナリデータの格納ページ数の分岐条件については，表「データ長一覧」を参照してください。

y：部分構造インデクスの総数（個）

A：部分構造パス用解析ツリー長（バイト）

次の計算式で求められる値になります。

S×120＋P＋L＋S×4＋32

L：ステップ式の修飾名に指定した局所名の文字列表現長の合計値（バイト）※

P：接頭辞に関連づけたXML名前空間URIの文字列表現長の合計値（バイト）※

接頭辞を省略した場合は，省略時に関連づけられるXML名前空間URI

S：ステップ式の指定数（個）

注※　4の倍数に切り上げてください。

(c)　計算式3

ディクショナリ表名 | 計算式
SQL_TABLE_ PRIVILEGES | [図データ]
SQL_RDAREA_ PRIVILEGES | [図データ]
SQL_VIEW_ TABLE_USAGE | [図データ]
SQL_VIEWS | [図データ]
SQL_VIEW_DEF※ | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：認可識別子の長さの平均値（バイト）

c：表識別子の長さの平均値（バイト）

d：アクセス権限の定義数（個）

一つの表に対してn人に権限を与えた場合は，権限を与えた表数×n個と計算します。

PUBLICに対して権限を与えた場合は，1人として計算します。

グループに対して権限を与えた場合は，一つのグループIDを1人として計算します。

e：RDエリアの総数（個）

f：表を格納するRDエリアの名称の長さの平均値（バイト）

g：ビュー表を定義するときのSQL文の長さの平均値（バイト）

h：ビュー定義の総数（個）

j：ビュー解析情報の平均長（バイト）

1ビュー表当たりのビュー解析情報長については，マニュアル「HiRDB システム定義」の「ビュー解析情報用バッファ長（pd_view_def_cache_size）の見積もり式」を参照してください。

注※　システムが使用する表です。

(d)　計算式4

ディクショナリ表名 | 計算式
SQL_REFERENTIAL_ CONSTRAINTS | [図データ]

E：｛e×h＋2×h＋（h−1）｝＋1

F：｛e×i＋2×i＋（i−1）｝＋1

G：｛2×h＋（h−１）｝＋1

H：｛2×i＋（i−1）｝＋1

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：制約名称の長さの平均値（バイト）

c：認可識別子の長さの平均値（バイト）

d：表識別子の長さの平均値（バイト）

e：外部キーを定義した列名の長さの平均値（バイト）

f：主キーを定義した列名の長さの平均値（バイト）

h：外部キーを構成する列数の平均値（個）

i：主キーを構成する列数の平均値（個）

(e)　計算式5

ディクショナリ表名 | 計算式
SQL_PHYSICAL_ FILES | [図データ]
SQL_RDAREAS | [図データ]
SQL_USERS | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：RDエリアの総数（個）

c：RDエリアの名称の長さの平均値（バイト）

d：スキーマの認可識別子の長さの平均値（バイト）

e：スキーマ総数（個）

f：全RDエリアを構成するHiRDBファイルの総数（個）

g：全RDエリアを構成するHiRDBファイルの名称の長さの平均値（バイト）

h：パスワード長の平均値（バイト）

i：スキーマ操作権限対象のスキーマ名長の平均値（バイト）

(f)　計算式6

ディクショナリ表名 | 計算式
SQL_DIV_TABLE_ REGULARIZE※ | [図データ]

a：横分割表の総数（個）

b：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

c：表を格納するRDエリアの名称長の平均値（バイト）

d：表の横分割条件数の平均値（個）

e：認可識別子の長さの平均値（バイト）

f：表識別子の長さの平均値（バイト）

g：表の横分割条件を指定する列が文字列のときの条件値長の平均値（バイト）

h：表の横分割条件を指定する列が数値列のときの条件値長の平均値（バイト）

注※　システムが使用する表です。

(g)　計算式7

ディクショナリ表名 | 計算式
SQL_TABLE_ STATISTICS※1 | [図データ]
SQL_COLUMN_ STATISTICS※1 | [図データ]
SQL_INDEX_ STATISTICS※1 | [図データ]

a：最適化情報を取得する表の総数（個）

b：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

c：列の名称長の平均値（バイト）

e：認可識別子の長さの平均値（バイト）

f：表識別子の長さの平均値（バイト）

g：最適化情報を取得する表に定義するインデクスの総数（個）

h：インデクス識別子の長さの平均値（バイト）

i：最適化情報を取得する表に定義するインデクスのキー列値数※2（個）

注※1　システムが使用する表です。

注※2　キー列値数 ＜ 100の場合，i＝キー列値数

　　キー列値数 ≧ 100の場合，i＝100

(h)　計算式8

ディクショナリ表名 | 計算式
SQL_DIV_ COLUMN | [図データ]

a：LOB列を定義した表の総数（個）

b：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

c：列の名称長の平均値（バイト）

d：表を格納するRDエリアの名称の長さの平均値（バイト）

e：認可識別子の長さの平均値（バイト）

f：表識別子の長さの平均値（バイト）

h：コンポネント名称の長さの平均値（バイト）

(i)　計算式9

ディクショナリ表名 | 計算式
SQL_ROUTINES | [図データ]
SQL_ROUTINE_ RESOURCES | [図データ]
SQL_ROUTINE_ PARAMS | [図データ]

a：ルーチンの総数（個）

b：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

c：ルーチン名称の長さの平均値（バイト）

d：認可識別子の長さの平均値（バイト）

e：特定名※1の長さの平均値（バイト）

f：パラメタ名称の長さの平均値（バイト）

g：リソース※2の所有者の認可識別子の長さの平均値（バイト）

h：リソース※2名称の長さの平均値（バイト）

i：1ルーチン当たりのリソース※2数の平均値（個）

j：1ルーチン当たりのパラメタ数の平均値（個）

k：抽象データ型の名称長の平均値（バイト）

m：ユーザ定義型の名称長（戻り値）の平均値（バイト）

n：外部ルーチン名称長の平均値（バイト）

p：Javaクラス名称長の平均値（バイト）

q：Javaアーカイブ名称長の平均値（バイト）

r：Java戻り値のデータ型名称長の平均値（バイト）

s：Javaパラメタデータ型の名称長の平均値（バイト）

t：新旧値相関名で使用した列名称の長さの平均値（バイト）

注※1　「認可識別子.ルーチン識別子」を表しています。

注※2　表及びインデクスを表しています。

(j)　計算式10

ディクショナリ表名 | 計算式
SQL_DATATYPES | [図データ]
SQL_DATATYPE_ DESCRIPTORS | [図データ]

a：ユーザ定義型の総数（個）

b：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

c：属性又はフィールド名の長さの平均値（バイト）

d：ユーザ定義型の注釈の長さの平均値（バイト）

e：1データ型当たりの属性数の平均値（個）

f：認可識別子の長さの平均値（バイト）

g：データ型識別子の長さの平均値（バイト）

h：スーパタイプの抽象データ型の認可識別子の長さの平均値（バイト）

i：スーパタイプの抽象データ型のデータ識別子の長さの平均値（バイト）

j：ユーザ定義型で定義された属性数（個）

k：ユーザ定義型で定義された属性の抽象データ型の認可識別子の長さの平均値（バイト）

m：ユーザ定義型で定義された属性の抽象データ型のデータ識別子の長さの平均値（バイト）

(k)　計算式11

ディクショナリ表名 | 計算式
SQL_PLUGINS | [図データ]
SQL_PLUGIN_ ROUTINES | [図データ]
SQL_PLUGIN_ ROUTINE_PARAMS | [図データ]

a：1プラグイン当たりのプラグインルーチン数の平均値（個）

b：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

c：ルーチン名称の長さの平均値（バイト）

d：認可識別子の長さの平均値（バイト）

e：特定名※の長さの平均値（バイト）

f：1プラグイン当たりのパラメタ名称の長さの平均値（バイト）

i：1ルーチン当たりのリソース数の平均値（個）

k：プラグインの総数（個）

m：プラグイン名称の長さの平均値（バイト）

n：抽象データ型／インデクス型名称の長さの平均値（バイト）

o：プラグインライブラリパス名称の長さの平均値（バイト）

p：プラグインの注釈の長さの平均値（バイト）

q：契機指示子の長さの平均値（バイト）

r：オペレーション修飾子の平均値（バイト）

s：オペレーション修飾コード長の平均値（バイト）

t：パラメタ修飾情報長の平均値（バイト）

u：バインドオペレーション名称長の平均値（バイト）

v：パラメタ修飾情報コード長の平均値（バイト）

注※　「認可識別子.ルーチン識別子」を表しています。

(l)　計算式12

ディクショナリ表名 | 計算式
SQL_INDEX_TYPES | [図データ]
SQL_INDEX_TYPE_ FUNCTION | [図データ]

a：インデクス型の総数（個）

b：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

c：認可識別子の長さの平均値（バイト）

d：インデクス型識別子の長さの平均値（バイト）

e：抽象データ型名称の長さの平均値（バイト）

f：1インデクス型当たりの適用関数の数（個）

(m)　計算式13

ディクショナリ表名 | 計算式
SQL_INDEX_ RESOURCES | [図データ]
SQL_TYPE_ RESOURCES | [図データ]
SQL_TABLE_ RESOURCES | [図データ]

a：プラグインインデクスの総数（個）

b：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

c：認可識別子の長さの平均値（バイト）

d：インデクス型識別子の長さの平均値（バイト）

e：抽象データ型名称の長さの平均値（バイト）

g：抽象データ型で定義された属性の総数（個）

h：サブタイプとして定義された抽象データ型の総数（個）

i：抽象データ型の総数（個）

j：表識別子の平均長（バイト）

(n)　計算式14

ディクショナリ表名 | 計算式
SQL_TRIGGERS | [図データ]
SQL_TRIGGER_ACTCOND※ | [図データ]
SQL_TRIGGER_COLUMNS | [図データ]
SQL_TRIGGER_DEF_SOURCE | [図データ]
SQL_TRIGGER_USAGE | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：トリガ定義の総数（個）

c：トリガ認可識別子の長さの平均値（バイト）

d：トリガ名称の長さの平均値（バイト）

e：トリガを定義した表の認可識別子の長さの平均値（バイト）

f：トリガを定義した表名称の長さの平均値（バイト）

g：旧値相関名称の長さの平均値（バイト）

h：新値相関名称の長さの平均値（バイト）

i：トリガ動作手続きの特定名称の長さの平均値（バイト）

j：トリガ定義時のSQL文の長さの平均値（バイト）

k：UPDATE文を契機とするトリガの定義数（個）

m：トリガの実行契機となる列に指定した列名称の長さの平均値（バイト）

n；トリガの実行契機となる列に指定した列数の平均値（個）

p：トリガ動作の探索条件中のリソース数（個）

q：トリガ動作の探索条件中のリソースの認可識別子の長さの平均値（バイト）

r：トリガ動作の探索条件中のリソースの表名称の長さの平均値（バイト）

s：トリガ動作の探索条件中のリソースの特定名称の長さの平均値（バイト）

t：トリガ動作条件の解析ツリー長（バイト）

次の計算式で求められる値になります。なお，この計算式中の変数はすべてWHENの探索条件での指定内容です。

S×36＋T＋U×48＋V×128

＋F1×420＋F2×132＋F3×124＋F4×296＋F5×F4×132

＋A×140＋B×200＋1000

A：コンポーネント指定の属性数（個）

B：値式に現れる抽象データ型の数（個）

F1：システム定義スカラ関数の数（個）

F2：システム定義スカラ関数の引数の数（個）

F3：ユーザ定義関数の数（個）

F4：ユーザ定義関数の候補となる関数の数（個）

F5：ユーザ定義関数の引数の数（個）

S：論理演算子，算術演算子，定数，及びシステム組込みスカラ関数の合計数（個）

T：定数（HiRDBで解釈するデータ型）の合計長（バイト）

U：スカラ関数VALUE，CASE式，CAST指定中の値式の数（個）

V：列指定の数（個）

注※　システムが使用する表です。

(o)　計算式15

ディクショナリ表名 | 計算式
SQL_PARTKEY | [図データ]
SQL_PARTKEY_DIVISION | [図データ]
SQL_DIV_TYPE | [図データ]

a：作成するマトリクス分割表の数（個）

b：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

c：表の横分割条件値数の平均値（個）

d：表の横分割条件を指定する列の名称長の平均値（バイト）

f：認可識別子の長さの平均値（バイト）

g：表識別子の長さの平均値（バイト）

h：表の横分割条件値の長さの平均値（バイト）

n：境界値指定のキーレンジ分割とハッシュ分割を組み合わせたマトリクス分割表の数（個）

(p)　計算式16

ディクショナリ表名 | 計算式
SQL_AUDITS | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：監査対象イベントの数（個）（CREATE AUDITの実行回数（回））

c：イベントタイプ名称の長さの平均値（バイト）

d：イベントサブタイプ名称の長さの平均値（バイト）

e：オブジェクトタイプ名称の長さの平均値（バイト）

f：オブジェクトの所有者名称の長さの平均値（バイト）

g：オブジェクト名称の長さの平均値（バイト）

h：イベント実行者の名称の長さの平均値（バイト）

(q)　計算式17

ディクショナリ表名 | 計算式
SQL_AUDIT_REGULARIZE※ | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：監査証跡の絞り込みに指定したオブジェクト数とイベント実行者の総数 + 1（個）

c：オブジェクトタイプ名称の長さの平均値（バイト）

d：オブジェクトの所有者名称の長さの平均値（バイト）

e：オブジェクト名称の長さの平均値（バイト）

f：イベント実行者の名称の長さの平均値（バイト）

注※　システムが使用する表です。

(r)　計算式18

ディクショナリ表名 | 計算式
SQL_KEYCOLUMN_USAGE | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：制約定義の総数（個）

c：制約認可識別子の長さの平均値（バイト）

d：制約名称の長さの平均値（バイト）

e：制約を定義した表の認可識別子の長さの平均値（バイト）

f：制約を定義した表名称の長さの平均値（バイト）

g：制約の種類名称の長さの平均値（バイト）

(s)　計算式19

ディクショナリ表名 | 計算式
SQL_TABLE_CONSTRAINTS | [図データ]
SQL_CHECKS | [図データ]
SQL_CHECK_COLUMNS | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：制約定義の総数（個）

c：制約認可識別子の長さの平均値（バイト）

d：制約名称の長さの平均値（バイト）

e：制約を定義した表の認可識別子の長さの平均値（バイト）

f：制約を定義した表名称の長さの平均値（バイト）

g：制約の種類名称の長さの平均値（バイト）

h：検査制約定義時のSQL文の長さの平均値（バイト）

i：検査制約の定義数（個）

j：検査制約を定義した列に指定した列名称の長さの平均値（バイト）

k：検査制約を定義した列に指定した列数の平均値（個）

m：バイナリデータ（検査制約の探索条件，検査制約用解析ツリー）のデータ長が256以上，かつ分岐する平均バイナリデータ数

バイナリデータの格納ページ数の分岐条件については，「表の格納ページ数の計算方法」を参照してください。

X：検査制約用解析ツリー長（バイト）

次の計算式で求められる値になります。なお，この計算式中の変数はすべて検査制約の探索条件の指定です。

32ビットモードの場合：S×36＋T＋（U1＋U2＋U3）×48＋V×128＋1000

64ビットモードの場合：S×72＋T＋（U1＋U2＋U3）×96＋V×184＋1400

S：論理演算子，算術演算子（＋，−，＊，／，又は｜｜），及びシステム組み込みスカラ関数の合計数（個）

T：定数（HiRDBで解釈するデータ型）の長さの合計値（バイト）

U1：CASE式，CAST指定中の値式の数（個）

U2：スカラ関数（VALUE，SUBSTR，BIT_AND_TEST，POSITION，TIMESTAMP，VARCHAR_FORMAT，TIMESTAMP_FORMAT）の値式の数（個）

U3：日時書式の数（個）

V：列指定の数（個）

(t)　計算式20

ディクショナリ表名 | 計算式
SQL_SYSPARAMS | [図データ]

(u)　計算式21

ディクショナリ表名 | 計算式
SQL_PUBLICVIEW_ SAME_USERS | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：パブリックビュー表の総定義数（個）

c：パブリックビュー表ごとの重複名数の平均値※（バイト）

d：パブリックビュー表の表識別子の長さの平均値（バイト）

e：認可識別子の長さの平均値（バイト）

注※

パブリックビュー表の表識別子ごとにSQL_TABLES表のTABLE_NAME列が同じ値となる行数の平均値

(v)　計算式22

ディクショナリ表名 | 計算式
SQL_SEQUENCES | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：順序数生成子の総定義数（個）

c：順序数生成子識別子の長さの平均値（バイト）

d：認可識別子の長さの平均値（バイト）

e：順序数生成子開始値の長さの平均値（バイト）

f：順序数生成子最大値の長さの平均値（バイト）

g：順序数生成子最小値の長さの平均値（バイト）

h：順序数生成子増分値の長さの平均値（バイト）

i：RDエリア名称の長さの平均値（バイト）

(w)　計算式23

ディクショナリ表名 | 計算式
SQL_ACCESS_SECURITY | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：接続制約の総数（個）

c：接続制約名称の長さの平均値（バイト）

d：IPアドレスの長さの平均値（バイト）

e：認可識別子の長さの平均値（バイト）

(x)　計算式24

ディクショナリ表名 | 計算式
SQL_ROLES | [図データ]
SQL_ROLE_PRIVILEGES | [図データ]

a：次に示すどちらかを代入します。

pd_dbreuse_remaining_entriesオペランドの指定値がONLY_USER又はNOTHINGの場合

データディクショナリ用RDエリアのページ長−510（バイト）

pd_dbreuse_remaining_entriesオペランドの指定値が上記以外の場合

データディクショナリ用RDエリアのページ長（バイト）

b：ロールの総定義数（個）

c：平均認可識別子長（1〜30けた）（バイト）

d：1ロールの当たりの平均付与数

(3)　インデクスの格納ページ数の計算方法

インデクスの格納ページ数は，次に示す計算式で求めます。

計算式

インデクスの格納ページ数（単位：ページ）
　　　　　　　　＝ディクショナリ表のインデクスを格納するページ数※＋12

注※

「インデクスの格納ページ数の計算方法」を参照し，ディクショナリ表のインデクスを格納するページ数を計算してください。また，このときの計算条件を次に示します。

計算式には，表「インデクスの格納ページ数を求める計算式に代入する変数一覧」に示す変数を代入します。

変数b（CREATE INDEXで指定する未使用領域の比率）は30とします。

変数e及びf（キー値の重複がdx＋1以上のキーの種類の個数及びキーの重複数の平均値）は12とします。

表16‒6　インデクスの格納ページ数を求める計算式に代入する変数一覧

表名 | 種別 | キー長※３ （変数g ※1） | キーの種類の個数 （変数c ※1） | キーの重複数の平均値 （変数d ※1）
SQL_PHYSICAL_FILES | 1 | 8 | サーバ数 | サーバ内のHiRDBファイル数の平均値
2 | g＋1 | RDエリア数 | RDエリアを構成する HiRDBファイル数の平均値
SQL_RDAREAS | 3 | g＋1 | RDエリア数 | 1
4 | 4
151 | 8 | 1 | RDエリアの総数
152 | 4 | 1 | RDエリアの総数
SQL_TABLES | 5 | d＋e＋2 | 表の総数＋80 | 1
6 | 4
SQL_COLUMNS | 7 | d＋e＋f＋3 | a×b | 1
8 | d＋e＋6
9 | 4 | b
SQL_INDEXES | 10 | d＋e＋2 | a | ↑h÷a↑
11 | d＋i＋2 | h | 1
12 | 4
SQL_USERS | 13 | d＋1 | 認可識別子の数 | 1
153 | d＋1 | スキーマ操作権限対象のスキーマ数 | ↑スキーマ操作権限を付与されたユーザ数÷スキーマ操作権限対象のスキーマ数↑
SQL_RDAREA_PRIVILEGES | 14 | d＋1 | データベース初期設定ユティリティ（pdinit）のUSER USED BYオペランドで指定する認可識別子を重複排除した数 | 1ユーザ当たりの平均RDエリア利用権限使用数
15 | g＋1 | データベース初期設定ユティリティ（pdinit）のUSER USED BYオペランドで指定するRDエリアの数 | 1RDエリア当たりの平均使用ユーザ数
SQL_TABLE_PRIVILEGES | 16 | d＋1 | a | ↑y÷a↑
17 | 2×d＋e＋3 | y | 1
SQL_DIV_TABLE | 18 | d＋e＋6 | 表の横分割数の総数 | 1
19 | g＋1 | 表を横分割したときに指定するRDエリアを重複排除した数 | RDエリアに格納する表数の平均値
20 | 4
SQL_DIV_TABLE_REGULARIZE | 21 | d＋e＋6 | 表の横分割数の総数 | 1
22 | 4 | 横分割表の数 | 表の横分割数の平均値
SQL_INDEX_COLINF | 23 | d＋e＋6 | インデクス定義のある表を重複排除した数 | インデクスを構成する列数の平均値
24 | d＋i＋6 | インデクスの構成列数 | 1
SQL_TABLE_STATISTICS | 25 | d＋e＋2 | 表の総数（ディクショナリ表もカウントの対象とします） | 1
SQL_COLUMN_STATISTICS | 26 | d＋e＋f＋3 | h | 1
SQL_INDEX_STATISTICS | 27 | d＋e＋2 | インデクスを定義する表の総数 | ↑h÷a↑
28 | d＋i＋2 | h | 1
SQL_VIEW_TABLE_ USAGE | 29 | d＋e＋2 | z | 1
30 | d＋e＋2 | ビュー定義をする基表の数 | 1表当たりのビュー定義数の平均値
31 | 4 | z | 1
SQL_VIEWS | 32 | d＋e＋2 | z | 1
33 | 4
SQL_VIEW_DEF | 34 | d＋e＋2 | z | 1
35 | 10
SQL_REFERENTIAL_CONSTRAINTS | 39 | d＋e＋2 | 参照制約の総数 | 1
40 | d＋e＋2 | 参照表の総数 | 1表当たりの参照表数の平均値
41 | d＋e＋2 | 被参照表の総数 | 1表当たりの被参照表数の平均値
SQL_EXCEPT | 86 | d＋e＋2 | 除外値指定をしたインデクスの数 | 一つの表に除外値指定をしたインデクスの数
87 | d＋i＋2 | 1
88 | 4 | 除外値指定をしたインデクスを持つ表を重複排除した数 | 一つの表に除外値指定をしたインデクスの数
SQL_DIV_INDEX | 36 | d＋e＋6 | 横分割インデクス数×分割数 | 1
37 | d＋i＋2 | 横分割インデクスの総数 | 1表当たりの平均分割数
SQL_DIV_COLUMN | 38 | d＋e＋f＋3 | LOB列の定義数 | 1表当たりの平均横分割数
52 | d＋e＋9 | LOB属性の定義数 | 1
SQL_ROUTINES | 43 | d＋MAX（q，7） | p＋174 | 1
44 | d＋MAX（t，18） | u＋65 | 1
45 | 4 | p＋174 | 1
53 | d＋UDT | 抽象データ型の数＋1（NULL値） | 1抽象データ型当たりのルーチン数の平均値＋NULL値数
SQL_ROUTINE_RESOURCES | 46 | d＋q | p×s | 1ルーチン当たりの使用リソース数の平均値
47 | d＋t
48 | d＋q
49 | 4
SQL_ROUTINE_PARAMS | 50 | d＋MAX（q，8） | p×r＋347 | 1ルーチン当たりの平均パラメタ数
51 | d＋MAX（t，19） | ルーチン数 | 1特定名当たりのパラメタ数の平均値（3未満の場合は3としてください）
106 | e＋4＋2 | トリガSQLオブジェクト数×r＋1（NULL値） | 1特定名当たりのパラメタ数の平均値（3未満の場合は3としてください）＋NULL値数
SQL_DATATYPES | 54 | d＋UDT | 抽象データ型の数 | 1
55 | 4
56 | d＋UDT | サブタイプを持つ抽象データ型の数＋1（NULL値） | 1抽象データ型当たりのサブタイプ数の平均値＋NULL値数
SQL_DATATYPE_DESCRIPTORS | 57 | d＋UDT＋ATT | NUDT×NATT | 1
58 | 4 | 抽象データ型の数 | 1抽象データ型当たりの属性数の平均値
SQL_TABLE_RESOURCES | 59 | d＋e | ユーザ定義データ型を使用する表の総数 | 1表当たりの使用ユーザ定義データ型数の平均値
60 | d＋UDT | UDT | 1ユーザ定義データ型当たりの使用表数の平均値
61 | 4
SQL_PLUGINS | 62 | d＋PLG | プラグイン数 | 1
63 | 4
64 | ｛（d＋UDT）÷ IXT｝ | データ型プラグイン数＋ インデクス型プラグイン数
SQL_PLUGIN_ROUTINES | 65 | t | NPLG×NFPLG | 1
66 | PLG＋TMD＋2
67 | PLG＋4
68 | POPR | オペレーション数 | プラグイン数
SQL_PLUGIN_ROUTINE_PARAMS | 69 | t＋PRM | NPLG×NPPAR | 1
70 | PLG | NPLG | 1プラグイン当たりの平均パラメタ数
71 | t＋4 | NPLG×NPPAR | 1
SQL_REGISTRY_CONTEXT | 72 | CNM＋1 | コンテキスト数 | 1
SQL_REGISTRY_KEY | 73 | KNM＋6 | キー数 | 1
SQL_INDEX_TYPES | 74 | d＋IXT | 作成するインデクス型の数 | 1
75 | 4
SQL_INDEX_RESOURCES | 76 | d＋IXT | プラグインインデクス数 | インデクス型を使用するインデクス定義数の平均値
77 | 4
SQL_INDEX_DATATYPE | 78 | d＋e | プラグインインデクスを定義する表の定義数 | 同一表に対する平均プラグインインデクス数
79 | d＋i | プラグインインデクス数 | 1
SQL_INDEX_FUNCTION | 80 | d＋e | プラグインインデクスを定義する表の定義数 | 1表当たりのプラグインインデクス数の平均値×プラグインインデクス適用関数数の平均値
81 | d＋i | プラグインインデクス数 | 1プラグインインデクス当たりの適用関数数の平均値
SQL_TYPE_RESOURCES | 82 | d＋e | ユーザ定義データ型を使用するユーザ定義データ型の数 | ユーザ定義データ型で属性に指定する平均ユーザ定義データ型数
83 | d＋UDT | ユーザ定義データ型数 | ユーザ定義データ型を使用する平均ユーザ定義データ型数
84 | 4
SQL_INDEX_TYPE_FUNCTION | 85 | d＋IXT | インデクス型の数 | 1インデクス当たりの適用関数数の平均値
SQL_TRIGGERS | 90 | d＋e＋2+16 | トリガ数 | 1
91 | d＋TRIG＋2
92 | d＋t＋2
93 | 4
SQL_TRIGGER_ACTCOND | 94 | d＋TRIG＋2＋4 | 動作条件ありのトリガ数 | 1
95 | d＋e＋2 | トリガを定義した表数 | 1表当たりのトリガ数の平均値
SQL_TRIGGER_COLUMNS | 96 | d＋TRIG＋2 | 列指定がある，UPDATE文を契機とするトリガ数 | 1トリガ当たりの指定列の平均値
97 | d＋e＋f＋3 | UPDATE文を契機とするトリガの指定列数 | 1
SQL_TRIGGER_DEF_SOURCE | 98 | d＋TRIG＋2＋4 | トリガ数 | 1
99 | d＋e＋2 | トリガを定義した表数 | 1表当たりのトリガ数の平均値
SQL_TRIGGER_USAGE | 100 | d＋TRIG＋2 | トリガ動作の探索条件中でリソースを参照するトリガ数 | 1トリガ当たりの参照リソース数の平均値
101 | d＋e＋2 | トリガ動作の探索条件中でリソースを参照するトリガを定義した表数 | 1表当たりの参照リソース数の平均値
102 | d＋e＋（t又はe）＋2 | 使用リソース数 | 1
103 | 8
SQL_PARTKEY | 104 | d＋e＋f＋3 | マトリクス分割表の数×分割キーの数 | 1
SQL_PARTKEY_DIVISION | 105 | d＋e＋6 | マトリクス分割表の数×境界値数×分割キーの数 | 1
SQL_AUDITS | 107 | ETP＋EST＋2 | 監査対象イベント数 | 1
108 | OTP＋OSC＋ONM＋3 | 監査対象オブジェクト数 | 1オブジェクト当たりの監査対象イベント数の平均値
109 | d | 監査対象ユーザ数 | 1ユーザ当たりの監査対象イベント数の平均値
SQL_AUDITS_REGULARIZE | 110 | OTP＋OSC＋ONM＋3 | 監査対象オブジェクト数 | 1オブジェクト当たりの監査対象イベント数の平均値
111 | d | 監査対象ユーザ数 | 1ユーザ当たりの監査対象イベント数の平均値
SQL_KEYCOLUMN_USAGE | 112 | d＋CNS＋2 | 制約数 | 1
113 | d＋e＋2 | 制約を定義している表数 | 1表当たりの制約数の平均値
SQL_TABLE_CONSTRAINTS | 114 | d＋CNS＋2 | 制約数 | 1
115 | d＋e＋2 | 制約を定義した表数 | 1表当たりの制約数の平均値
SQL_CHECKS | 116 | d＋CNS＋2 | 検査制約数 | 1
117 | d＋e＋2 | 検査制約を定義している表数 | 1表当たりの検査制約数の平均値
SQL_CHECK_COLUMNS | 118 | d＋CNS＋2 | 検査制約数 | 1検査制約当たりの指定列数の平均値
119 | d＋e＋f＋3 | 検査制約で使用している列数 | 1表当たりの検査制約で使用している列の平均長複数
SQL_SYSPARAMS | 121 | 8 | 2 | 1
SQL_PUBLICVIEW_SAME_USERS | 124 | d＋e＋2 | パブリックビュー表数×認可識別子数 | 1
SQL_INDEX_XMLINF | 125 | d＋e＋2 | NPSIT | 1インデクス当たりの平均インデクス構成部分構造パス数
126 | d＋i＋7 | NPSS | 1
SQL_SEQUENCES | 127 | d＋SEQN＋2 | システム内の順序数生成子数 | 1
128 | 4 | システム内の順序数生成子数 | 1
SQL_ACCESS_SECURITY | 149 | CSTN | 接続制約数 | 1
150 | 1 | 2 | 接続制約数
154 | d | 指定した認可識別子の数 | 1認可識別子当たりの平均接続制約登録数
SQL_ROLES | 155 | 4 | システム内のロール定義数 | 1
156 | d | システム内のロール定義数 | 1
SQL_ROLE_PRIVILEGES | 157 | d×2+7 | システム内のロール付与数 | 1

a：表の総数（個）

b：表の列数の平均値（個）

c：データディクショナリ用RDエリアのページ長（バイト）

d：認可識別子の長さの平均値（バイト）

e：表識別子の長さの平均値（バイト）

f：列の名称長の平均値（バイト）

g：RDエリアの名称長の平均値（バイト）

h：インデクスの総数（個）

i：インデクス識別子の長さの平均値（バイト）

n：RDエリアを構成するHiRDBファイル名称の長さの平均値（バイト）

p：作成するルーチン数（個）

q：ルーチン名称の長さの平均値（バイト）

r：1ルーチン当たりのパラメタ数の平均値（個）

s：1ルーチン当たりの使用リソース数の平均値（個）

t：特定名※２の長さの平均値（バイト）

u：特定名※２の総数（個）

y：アクセス権限の定義数（個）

一つの表に対してn人に権限を与えた場合，表数×n個と数えます。

z：ビュー定義の総数（個）

NUDT：作成するユーザ定義データ型の数（個）

UDT：ユーザ定義データ型名称の長さの平均値（バイト）

NATT：1ユーザ定義データ型当たりの属性数の平均値（個）

ATT：ユーザ定義データ型属性名称の長さの平均値（バイト）

PLG：プラグイン名称の長さの平均値（バイト）

NPLG：作成するプラグイン数（個）

IXT：インデクス型名称の長さの平均値（バイト）

NFPLG：プラグイン関数の数の平均値（個）

POPR：プラグイン関数名の長さの平均値（バイト）

NPPAR：1プラグイン関数当たりのパラメタ数の平均値（個）

PRM：1プラグイン関数当たりのパラメタ名の長さの平均値（バイト）

TMD：契機記述長の平均値（バイト）

CNM：コンテキスト名称長の平均値（バイト）

KNM：キー名称長の平均値（バイト）

TRIG：トリガ名称長の平均値（バイト）

ETP：イベントタイプ名称の長さの平均値（バイト）

EST：イベントサブタイプ名称の長さの平均値（バイト）

OTP：オブジェクト種別名称の長さの平均値（バイト）

OSC：オブジェクトの所有者名称の長さの平均値（バイト）

ONM：オブジェクト名称の長さの平均値（バイト）

CNS：制約名称の長さの平均値（バイト）

NPSIT：部分構造インデクス定義表数（個）

NPSS：部分構造インデクス構成部分構造パス数（個）

SEQN：順序数生成子識別子の長さの平均値（バイト）

CSTN：接続制約名称の長さの平均値（バイト）

注※1

「インデクスの格納ページ数の計算方法」の「計算式中で使用する変数」に記載されている変数のことです。

注※2

「認可識別子.ルーチン識別子」を表しています。

注※3

キー長は4バイト単位で切り上げになります。次に示す計算式で求めてください。

↑キー長÷4↑×4

16.2.2　解析情報表及び運用履歴表を格納するデータディクショナリ用RDエリアの容量の見積もり

create rdarea文にdatadictionary of dbmanagementを指定する場合のデータディクショナリ用RDエリアの容量は，次に示す計算式で求めます。

計算式

データディクショナリ用RDエリアの容量＝（↑（a×1.3）÷b↑）×b×4096
（単位：バイト）

a：データディクショナリ用RDエリアの総ページ数※１

b：データディクショナリ用RDエリアのセグメントサイズ※２

注※1

「表の格納ページ数＋インデクスの格納ページ数」です。「表の格納ページ数の計算方法」及び「インデクスの格納ページ数の計算方法」を参照してください。

注※2

データベース構成変更ユティリティ（pdmod）のcreate rdarea文で指定するセグメントサイズです。

(1)　表の格納ページ数の計算方法

表の格納ページ数（単位：ページ）は，計算式1と計算式2の和になります。

計算式1 | [図データ]
計算式2 | [図データ]

a：作成する表の数＋61（個）

b：表を格納するRDエリアの分割数の平均値（個）

分割していない場合は1とします。また，平均値は切り上げます。

c：作成するインデクス数＋124（個）

e：作成する表に定義したBLOB型の列の総数＋3（個）

g：作成する表に定義したBLOB属性の総数（個）

(2)　インデクスの格納ページ数の計算方法

インデクスの格納ページ数（単位：ページ）は次の計算式で求めます。

ディクショナリ表のインデクスを格納するページ数※×2

注※

「インデクスの格納ページ数の計算方法」を参照し，ディクショナリ表のインデクスを格納するページ数を計算してください。また，このときの計算条件を次に示します。

CREATE INDEXで指定する未使用領域の比率は0とします。

計算式には，次に示す変数を代入します。

キー長 （変数g※） | キーの種類の個数 （変数c※） | キーの重複数の平均値 （変数d※）
12 | （a＋c＋e＋g）×（b＋1）＋120 | 30

a：作成する表の数（個）

b：表を格納するRDエリアの分割数の平均値（個）

c：作成するインデクス数（個）

e：作成する表に定義したBLOB型の列の総数（個）

g：作成する表に定義したBLOB属性の総数（個）

なお，解析情報表及び運用履歴表にはユニークインデクスを定義してないため，変数hを加算する必要はありません。

注※

「インデクスの格納ページ数の計算方法」の「計算式中で使用する変数」に記載されている変数のことです。

16.3　マスタディレクトリ用RDエリアの容量の見積もり

マスタディレクトリ用RDエリアの容量は，次に示す計算式で求めます。

計算式

マスタディレクトリ用RDエリアの容量（単位：バイト）
＝｛
　　↑（a＋2）÷800↑×51＋↑（b＋120）÷6000↑×51＋↑（c＋240）÷6000↑×51
　　＋↑（d＋240）÷64000↑×51＋↑e÷64000↑×51＋2＋6×n
　　｝※１×4096※２

ａ：データディクショナリ用RDエリアの総数＋ユーザ用RDエリアの総数

ｂ：定義する表の総数

ｃ：定義するインデクスの総数

ｄ：定義するビュー表の総数

ｅ：定義するデータ型及びインデクス型の合計

ｎ：マスタディレクトリ用RDエリアを構成するHiRDBファイル数

注※1　マスタディレクトリ用RDエリアの総ページ数です。

注※2　マスタディレクトリ用RDエリアのページ長です。

16.4　データディレクトリ用RDエリアの容量の見積もり

データディレクトリ用RDエリアの容量は，次に示す計算式で求めます。

計算式

データディレクトリ用RDエリアの容量（単位：バイト）
　　　　 e　　　f
＝｛↑（ Σ gi＋Σ pj＋86 ）÷3000↑×51＋6×n＋1 ｝※１×4096※２
　　　　i=1　　j=1
gi＝↑（5×ai＋2×bi＋2×ci＋48）÷32↑
pj＝↑（dj＋12）÷16↑

ai：インデクスを構成する列数

bi：インデクスを格納するRDエリア数

ci：インデクスを定義する表を格納するRDエリア数

dj：表を格納するRDエリア数

e：定義するインデクスの総数

f：横分割する表の総数

n：データディレクトリ用RDエリアを構成するHiRDBファイル数

注※1　データディレクトリ用RDエリアの総ページ数です。

注※2　データディレクトリ用RDエリアのページ長です。

16.5　データディクショナリLOB用RDエリアの容量の見積もり

16.5.1　データディクショナリLOB用RDエリアの容量の計算方法

(1)　ソース格納用のデータディクショナリLOB用RDエリアの容量の見積もり

ソース格納用のデータディクショナリLOB用RDエリアの容量は，次に示す計算式で求めます。

計算式

ソース格納用のデータディクショナリLOB用RDエリアの容量（単位：バイト）
＝｛
　　　 a
　　［ Σ ↑Si÷64000↑×96 ＋7＋3×（a−1）］※１
　　　i=1
　　　　 b
　　＋［ Σ ↑（Cj＋1024）÷8192↑］※２
　　　　j=1
　　｝※３×8192※４

a：ソース格納用のデータディクショナリLOB用RDエリアを構成するHiRDBファイル数

b：次の総数

手続き（CREATE PROCEDURE）

抽象データ型内の関数と手続き（各FUNCTION（ただし，プラグイン関数を除きます），PROCEDURE）

ユーザ定義関数（CREATE FUNCTION）

Si：セグメント数

データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で指定する各HiRDBファイルのセグメント数

Cj：次の長さ

手続き（各CREATE PROCEDUREの長さ）

抽象データ型内の関数と手続き（各FUNCTION（ただし，プラグイン関数を除きます），PROCEDUREの長さ）

ユーザ定義関数（CREATE FUNCTIONの長さ）

注※１　ディレクトリページ部分の総ページ数です。

注※２　データページ部分の総ページ数です。

注※３　ソース格納用のデータディクショナリLOB用RDエリアの総ページ数です。

注※４　ソース格納用のデータディクショナリLOB用RDエリアのページ長です。

(2)　オブジェクト格納用のデータディクショナリLOB用RDエリアの容量の見積もり

オブジェクト格納用のデータディクショナリLOB用RDエリアの容量は，次に示す計算式で求めます。

計算式

オブジェクト格納用のデータディクショナリLOB用RDエリアの容量（単位：バイト）
＝｛
　　　 a
　　［ Σ ↑Si÷64000↑×96＋7＋3×（a−1）］※１
　　　i=1
　　　　 b
　　＋［ Σ ↑（Cj＋1024）÷8192↑］※２
　　　　j=1
　　｝※３×8192※４＋500000※５

a：オブジェクト格納用のデータディクショナリLOB用RDエリアを構成するHiRDBファイル数

b：手続き（CREATE PROCEDURE），抽象データ型内の関数と手続き（各FUNCTION（ただし，プラグイン関数を除きます），PROCEDURE），ユーザ定義関数（CREATE FUNCTION）及びトリガ定義（CREATE TRIGGER）の総数

Si：セグメント数

データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で指定する各HiRDBファイルのセグメント数

Cj：QOi＋PR（QOiの計算式を「QOi（SQLオブジェクト長）の計算式」に，PRの計算式を「PR（ルーチン制御用オブジェクト長）の計算式」に示します。これらの計算式で使用する変数を「PR及びQOiの計算式で使用する変数」に示します）

注※１　ディレクトリページ部分の総ページ数です。

注※２　データページ部分の総ページ数です。

注※３　オブジェクト格納用のデータディクショナリLOB用RDエリアの総ページ数です。

注※４　オブジェクト格納用のデータディクショナリLOB用RDエリアのページ長です。

注※５　抽象データ型，又はプラグイン使用時に加算します。

(3)　QOi（SQLオブジェクト長）の計算式

QOi（単位：バイト）＝
 a
Σ｛
i=1
　　1840＋46×RCN＋298×Si＋20×Pi＋1138×Ti＋76×Ti×Di＋80×Ci＋40×Ii＋534×Wi
　　＋20×Ki＋Li＋8×TCi＋656×Di＋48×nFF＋100×nFP＋148×nFC＋696×nPFF
　　＋16×（nAT＋nPAT）＋20×nCAT＋28×（nAF＋nCAF）＋20×（nAA＋nPAA＋nCAA）
　　＋1057×nSPA＋120×nSPP＋287×nSFF＋8×nSFP＋813×nJFC＋20×nJFP
　　〔＋1057×nTR＋120×（nTSN＋nTSO）＋20×（nTCN＋nTCO）〕※1
　　〔＋760＋376×RCC＋1880×RCT〕※2
　　〔＋32×Si＋16〕※3
　　〔＋↑（42×SiT）＋｛52＋152×（SiTA＋SiSA＋SiNA）×（SiT＋SiS＋SiN）｝↑〕※4
　｝

a：ストアドプロシジャ内のSQL文数

注※１　トリガを使用する場合に加算する計算式です。

注※２　参照制約を使用する場合に加算する計算式です。

注※３　列名記述領域長の計算式です。動的SQLの場合に加算します。

注※４　型名記述領域長の計算式です。動的SQLの場合に加算します。

(4)　PR（ルーチン制御用オブジェクト長）の計算式

(a)　ユーザが定義する場合

ストアドプロシジャ，ストアドファンクション，又はトリガを定義した場合の，ルーチン制御用オブジェクト長は次に示す計算式から求めます。

PR（単位：バイト）＝
 a
Σ｛
i=1
　　600＋28×sRi＋32×（sRUi＋sDi）＋56×sSXi＋sCUi＋sSi＋sPi＋sLA
　　＋sKi＋sL＋80×sWi＋24×sCM＋32×sCCR＋2×sDCR＋60×sCHD＋72×sDHD＋64×sHCN
　　＋8×sCHD×sHCN＋48×nRFF＋100×nRFP＋148×nRFC＋200×nPRFF＋8×nPRFP
　　＋196×nPA＋64×nPP＋36×nPPI＋20×nPPO＋200×nPPA＋8×nPPP＋20×nAR＋48×nARA
　　＋16×nRPAT＋20×nCAT＋28×（nRPAF＋nRCAF）＋20×（nRPAA＋nRCAA）＋287×nRSFF
　　＋8×nRSFP＋813×nPJA＋20×nPJP＋813×nRJFC＋20×nRJFP
　　〔＋28×（nTSN×2＋nTSO）〕※
　｝

a：次のSQL文数

手続き（CREATE PROCEDURE）

抽象データ型内の関数と手続き（各FUNCTION（ただし，プラグイン関数を除きます），PROCEDURE）

ユーザ定義関数（CREATE FUNCTION）

トリガ定義（CREATE TRIGGER）

注※　トリガを使用する場合に加算する計算式です。

(b)　HiRDBが自動的に作成する場合

表定義時，参照動作にCASCADEを指定した場合，HiRDBが制約制御のためにトリガを作成したときのルーチン制御用オブジェクト長は次に示す計算式から求めます。

PR（単位：バイト）＝
 a
Σ｛240＋608×RCC＋（5120＋100×RDi＋256×RIi）×RCP×RCT｝
i=1

a：次のSQL文数

手続き（CREATE PROCEDURE）

抽象データ型内の関数と手続き（各FUNCTION（ただし，プラグイン関数を除きます），PROCEDURE）

ユーザ定義関数（CREATE FUNCTION）

トリガ定義（CREATE TRIGGER）

(5)　PR及びQOiの計算式で使用する変数

変数名 | 説明
RCN | SQLオブジェクトで使用する表，及びインデクスの合計数
Si | SQL文中にある検索項目数（SQL文で指定する列がインデクス列の場合はその列数）
Pi | SQL文中にある埋込み変数又はパラメタ数
Ti | SQL文中にある表名数
Ci | SQL文中にある列名数
TCi | SQL文中にある表の構成列数
Wi | SQL文中にある論理演算子数※
Ki | SQL文中にある定数の数※
Li | SQL文中にある定数の合計長※（単位：バイト）
Ii | SQL文実行時に使用するインデクス数（SQL文で指定する表のうち，検索条件に指定するインデクス数）
Di | SQL文中の表に定義された格納条件の総数（マトリクス分割表は2倍する）
SiT | SQL文中にある選択式の抽象データ型数
SiS | SQL文中にある選択式の抽象データ型のスーパタイプ数
SiN | SQL文中にある選択式のサブタイプである抽象データ型のスーパタイプの総数
SiTA | SQL文中にある選択式の抽象データ型の属性数
SiSA | SQL文中にある選択式の抽象データ型のスーパタイプの属性数
SiNA | SQL文中にある選択式のサブタイプである抽象データ型のコンポネント指定総数
nSPA | SQL文中にある手続き文の呼び出し数
nSPP | SQL文中にある手続き文の引数の総数
nFF | SQL文中にある関数の呼び出し数※
nFP | SQL文中にある関数の引数の総数※
nFC | SQL文中にある関数の総関数定義候補数（関数呼出し数nFFに，引数が抽象データ型の各関数呼出しに対して，サブタイプを引数とする関数定義数を加算する）
nPFF | SQLオブジェクトが使用するプラグイン関数呼出し数（SQL文中にあるプラグイン関数呼出し数＋SELECTの場合は1，INSERT，UPDATE，DELETEの場合は6）
nSFF | SQL文中にあるシステム定義スカラ関数の呼び出し数※
nSFP | SQL文中にあるシステム定義スカラ関数の引数の総数※
nJFC | SQL文中にある外部Java関数の呼び出し数
nJFP | SQL文中にある外部Java関数の引数の総数
nAT | SQL文中にあるコンポネント指定で使用する抽象データ型数（スーパタイプ，抽象データ型属性によって現れる抽象データ型を除く）
nAA | SQL文中にあるコンポネント指定で使用する抽象データ型数（スーパタイプ，抽象データ型属性によって現れる抽象データ型を含む）
nAF | SQL文中にあるコンポネント指定で使用する属性総数
nPAT | SQLオブジェクトが使用するプラグイン関数の引数で使用する抽象データ型数（スーパタイプ，抽象データ型属性によって現れる抽象データ型を除く）
nPAA | SQLオブジェクトが使用するプラグイン関数の引数で使用する抽象データ型数（スーパタイプ，サブタイプを含む）
nCAT | SQL文中にあるコンストラクタ関数の呼び出し数
nCAA | SQL文中にあるコンストラクタ関数の抽象データ型数（スーパタイプを含む）
nCAF | SQL文中にあるコンストラクタ関数の抽象データ型の属性総数
nTR | SQL文の実行によって起動されるトリガ数
nTSN | SQL文の実行によって起動される各トリガのトリガSQL文中の新値相関名によって修飾された列の総数
nTSO | SQL文の実行によって起動される各トリガのトリガSQL文中の旧値相関名によって修飾された列の総数
nTCN | SQL文の実行によって起動される各トリガのトリガ動作条件中の新値相関名によって修飾された列の総数
nTCO | SQL文の実行によって起動される各トリガのトリガ動作条件中の旧値相関名によって修飾された列の総数
RCC | SQL文中で，更新対象の表を参照する表の外部キーの構成列数と，主キーの構成列数の総数
RCT | SQL文中で，更新対象の表を参照する表，及び更新対象の表が参照する表の総数
RCP | 参照表定義時に，参照動作に指定したCASCADEの総数
RIi | 参照表定義時，参照指定をする被参照表に定義されたインデクスの総数
RDi | 参照表定義時，参照指定をする被参照表に定義された分割格納条件の総数（マトリクス分割表の場合は，2倍する）
sRi | 手続き及び関数中のSQLパラメタ数（INOUT指定のSQLパラメタ数は2倍する）
sRUi | 手続き及び関数中のSQLパラメタの総数（又は，トリガ定義中のトリガSQL文中の新旧値相関名によって修飾された列の総数）
sDi | 手続き，関数，及びトリガSQL文中のSQL変数（declare）の総数
sSXi | 手続き，関数，及びトリガSQL文中のSQLCODE，SQLCOUNT変数の総数
sCUi | 手続き，関数，及びトリガSQL文中のCURRENT_TIME値関数，CURRENT_DATE値関数の総数
sSi | 手続き及びトリガSQL文中の操作系SQLの数（カーソル宣言を除くSQL文：OPEN，FETCH，CLOSE，UPDATE，DELETE，INSERT文など）
sPi | 手続き，関数，及びトリガSQL文中のルーチン制御SQL数（BEGIN，SET，IF，ELSEIF，WHILEなど）
sLA | 手続き，関数，及びトリガSQL文中のラベル数
sKi | 手続き，関数，及びトリガSQL文中の定数の数（手続き及びトリガSQL文中に記述された操作系SQL文の定数を除く）
sL | 手続き，関数，及びトリガSQL文中の定数の長さの合計（手続き及びトリガSQL文中に記述された操作系SQL文の定数を除く）
sWi | 手続き，関数，及びトリガSQL文中の条件述語数
sCM | 手続き，関数，及びトリガSQL文中の複合文の数
sCCR | 手続き及びトリガSQL文のカーソル宣言を記述した複合文の数
sDCR | 手続き及びトリガSQL文のカーソル宣言の数
sCHD | 手続き，関数，及びトリガSQL文のハンドラ宣言を記述した複合文の数
sDHD | 手続き，関数，及びトリガSQL文のハンドラ宣言の数
sHCN | 手続き，関数，及びトリガSQL文のハンドラ宣言中に記述された条件値の数
nRFF | ルーチン中にある関数呼出し数
nRFP | ルーチン中にある関数の引数の総数
nRFC | ルーチン中にある関数の関数定義候補の総数（関数呼出し数nFFに，引数が抽象データ型の各関数呼出しに対して，サブタイプを引数とする関数定義数を加算する）
nPRFF | ルーチンのSQLオブジェクトが使用するプラグイン関数呼出し数
nPRFP | ルーチンのSQLオブジェクトが使用するプラグイン関数のプラグインパラメタ総数
nPA | ルーチン中にある手続き呼び出し数
nPP | ルーチン中にある手続きのパラメタ総数
nPPI | ルーチン中にある手続きの入力パラメタ総数（入出力パラメタを含む）
nPPO | ルーチン中にある手続きの出力パラメタ総数（入出力パラメタを含む）
nPPA | ルーチンのSQLオブジェクトが使用するプラグイン手続き呼び出し数
nPPP | ルーチンのSQLオブジェクトが使用するプラグイン手続きのプラグインパラメタ総数
nRSFF | ルーチン中にあるシステム定義スカラ関数の呼び出し数
nRSFP | ルーチン中にあるシステム定義スカラ関数の引数の総数
nPJA | ルーチン中にある外部Java手続きの呼び出し数
nPJP | ルーチン中にある外部Java手続きの引数の総数
nRJFC | ルーチン中にある外部Java関数の呼び出し数
nRJFP | ルーチン中にある外部Java関数の引数の総数
nAR | ルーチン中にあるコンポネント指定で使用する抽象データ型数（スーパタイプ，抽象データ型属性によって現れる抽象データ型を除く）
nARA | ルーチン中にあるコンポネント指定で使用する属性総数
nRPAT | ルーチンのSQLオブジェクトが使用するプラグインルーチンのパラメタで使用する抽象データ型数（ただし，スーパタイプ，抽象データ型属性の抽象データ型を除く）
nRPAA | ルーチンのSQLオブジェクトが使用するプラグインルーチンのパラメタで使用する抽象データ型数（スーパタイプを含む）
nRPAF | ルーチンのSQLオブジェクトが使用するプラグインルーチンのパラメタで使用する抽象データ型の属性総数
nRCAT | ルーチン中にあるコンストラクタ関数の呼び出し数
nRCAA | ルーチン中にあるコンストラクタ関数の抽象データ型数（スーパタイプを含む）
nRCAF | ルーチン中にあるコンストラクタ関数の抽象データ型の属性総数

注※

トリガを使用する場合は，SQL文の実行によって起動される各トリガのトリガ動作条件についても数える必要があります。

16.6　ユーザLOB用RDエリアの容量の見積もり

16.6.1　ユーザLOB用RDエリアの容量の計算方法

ユーザLOB用RDエリアの容量は，次に示す計算式で求めます。

計算式

ユーザLOB用RDエリアの容量（単位：バイト）
　＝（ディレクトリページ部分の総ページ数＋データページ部分の総ページ数）×8192※

注※　ユーザLOB用RDエリアのページ長です。

(1)　ディレクトリページ部分の総ページ数

計算式

ディレクトリページ部分の総ページ数
　　 a
＝　 Σ ↑Si÷64000↑×96＋7＋3×（a−1）
　　i=1

a：ユーザLOB用RDエリアを構成するHiRDBファイル数

Si：セグメント数

データベース初期設定ユティリティ（pdinit）又はデータベース構成変更ユティリティ（pdmod）のcreate rdarea文で指定する各HiRDBファイルのセグメント数

(2)　データページ部分の総ページ数

計算式

データページ部分の総ページ数
　　 b
＝　 Σ ↑（Cj＋1024）÷8192↑
　　j=1

b：LOB列の行の総数

データ長が0の行もカウントします。NULL値の行はカウントしません。

Cj：各BLOBデータのデータ長（バイト）

16.7　レジストリ用RDエリアの容量の見積もり

16.7.1　レジストリ用RDエリアの容量の計算方法

レジストリ用RDエリアの容量は，次に示す計算式で求めます。

計算式

レジストリ用RDエリアの容量（単位：バイト）
　＝レジストリ用RDエリアのページ長※×レジストリ用RDエリアの総ページ数×1.3

注※

レジストリ機能初期設定ユティリティ（pdreginit）のcreate rdarea文で指定するページ長です。

レジストリ用RDエリアの総ページ数の求め方

レジストリ用RDエリアの総ページ数（単位：ページ）
　　 a
　＝ Σ ｛↑Si÷d↑＋↑Si÷e↑＋6×（a＋1）＋2×↑20480÷b↑
　　i=1
　＋レジストリ管理表の格納ページ数＋レジストリ管理表のインデクス格納ページ数

a：レジストリ用RDエリアを構成するHiRDBファイル数

b：レジストリ用RDエリアのページ長（単位：バイト）

c：レジストリ機能初期設定ユティリティ（pdreginit）のcreate rdarea文で指定するセグメントサイズ

d：↓（b−20）÷｛（↑c÷32↑×8）＋56｝↓

e：↓（125×b）÷（16×d）↓×d

Si：レジストリ機能初期設定ユティリティ（pdreginit）のcreate rdarea文で指定する各HiRDBファイルのセグメント数

各表及びインデクスの確保単位は，セグメントです。表やインデクスごとに求めた値をセグメント単位に切り上げます。

(1)　レジストリ管理表の格納ページ数

計算式

a：レジストリ管理表のコンテキスト数

b：レジストリ管理表のページ長

c：レジストリコンテキスト名称の長さ

d：アクセスパスワードの長さ

e：レジストリ管理表のキー値数（レジストリ管理表に登録したキー名称の数）

f：レジストリキー名称長

g：レジストリキー値長（レジストリキー値長が32,000バイト以下の場合に加算する）

(2)　レジストリ管理表のインデクス格納ページ数

計算式

レジストリ管理表のインデクス格納ページ数（単位：ページ）
　＝SQL_REGISTRY_CONTEXT表のインデクス格納ページ数
　＋SQL_REGISTRY_KEY表のインデクス格納ページ数

SQL_REGISTRY_CONTEXT表のインデクス格納ページ数，及びSQL_REGISTRY_KEY表のインデクス格納ページ数については，「インデクスの格納ページ数の計算方法」を参照してください。ただし，CREATE INDEX文で指定する未使用領域の比率は30％として計算してください。

インデクスを格納するページ数の計算式に使用する値を次に示します。

レジストリ用RDエリアのインデクス格納ページ数の計算式に使用する値

表名 | 種別 | キー長 | キーの種類 | 平均重複数
SQL_REGISTRY_CONTEXT | 72 | a＋1 | コンテキスト名の数（レジストリ管理表のコンテキスト数） | 1
SQL_REGISTRY_KEY | 73 | f＋6 | キー値の数（レジストリ管理表のキー値数） | 1

a：レジストリコンテキストの長さ

f：レジストリキー名称の長さ

16.8　レジストリLOB用RDエリアの容量の見積もり

16.8.1　レジストリLOB用RDエリアの容量の計算方法

レジストリLOB用RDエリアの容量は，次に示す計算式で求めます。

計算式

レジストリLOB用RDエリアの容量（単位：バイト）
　＝（ディレクトリページ部分の総ページ数＋データページ部分の総ページ数）×8192※

注※　レジストリLOB用RDエリアのページ長です。

(1)　ディレクトリページ部分の総ページ数

計算式

ディレクトリページ部分の総ページ数
　 a
＝ Σ ↑Si÷64000↑×96＋7＋3×（a−1）
　i=1

a：レジストリLOB用RDエリアを構成するHiRDBファイル数

Si：レジストリLOB用RDエリアのセグメント数

(2)　データページ部分の総ページ数

計算式

データページ部分の総ページ数
　 b
＝ Σ ↑（Cj＋1024）÷8192↑
　j=1

b：32000バイトを超えるレジストリキー値の数

Cj：32000バイトを超えるレジストリキー値の長さ

16.9　リスト用RDエリアの容量の見積もり

リスト用RDエリアの容量は，次に示す計算式で求めます。

計算式

リスト用RDエリアの容量（単位：バイト）
＝｛
　　 a
　　 Σ（↑Si÷f↑＋↑Si÷g↑）
　　i=1
　　＋6×（a＋1）＋↑（1024×n）÷（25×b）↑＋↑20480÷b↑＋c×e
　　｝×b

a：リスト用RDエリアを構成するHiRDBファイル数

b：リスト用RDエリアのページ長※（バイト）

c：リスト用RDエリアのセグメント数

e：リスト用RDエリアのセグメントサイズ※

f：↓｛b−20｝÷｛（↑e÷32↑×8）＋56｝↓

g：↑（125×b）÷（16×f）↑×f

n：1リスト用RDエリアに作成できる最大リスト数※

リスト用RDエリアの最大リスト数は，次の計算式で求めます。

↑サーバ内に保持するリストの総数÷サーバ内に配置するリスト用RDエリアの数↑

Si：リスト用RDエリアを構成するHiRDBファイルのセグメント数※

注※

上記の計算式で求めた値以上となる最も小さい500の整数倍の値を，データベース初期設定ユティリティ（pdinit）若しくはデータベース構成変更ユティリティ（pdmod）のcreate rdarea文，又はデータベース構成変更ユティリティのinitialize rdarea文で指定してください。

17　システムファイル及び監査証跡ファイルの容量の見積もり

この章では，システムログファイル，シンクポイントダンプファイル，ステータスファイルなどのシステムファイルの容量の見積もり方法，及び監査証跡ファイルの容量の見積もり方法について説明します。

17.1　システムログファイルの容量の見積もり

ここでは，システムログファイルの容量の見積もり方法について説明します。説明する項目を次に示します。

システムログファイルの総容量

表定義時に出力されるシステムログ量

インデクス定義時に出力されるシステムログ量

表データ更新時に出力されるシステムログ量

ユティリティによるデータベース作成時に出力されるシステムログ量

SQL操作に応じて出力されるシステムログ量

拡張システム定義スカラ関数の定義時に出力されるシステムログ量

RDエリアの自動増分機能使用時に出力されるシステムログ量

PURGE TABLE文実行時に出力されるシステムログ量

空きページ解放ユティリティ実行時に出力されるシステムログ量

再編成時期予測機能使用時に出力されるシステムログ量

更新可能バックアップ閉塞中に出力されるシステムログ量

pdchpathnコマンド実行時に出力されるシステムログ量

ディクショナリ表のメンテナンス実行時に出力されるシステムログ量

ロール機能使用時に出力されるシステムログ量

17.1.1　システムログファイルの総容量

(1)　システムログファイルの総容量の求め方

システムログファイルの総容量は，次に示す計算式で求めます。

計算式

全システムログファイルの総容量（単位：バイト）＝（↑ａ÷ｃ↑×3）※×ｂ

ａ：出力されるシステムログ量

求め方については，「システムログ量の求め方」を参照してください。

ｂ：pd_log_rec_lengオペランドで指定するシステムログファイルのレコード長です。

ｃ：次に示す値を代入してください。

pd_log_rec_leng = 1024の場合：1000

pd_log_rec_leng = 2048の場合：2000

pd_log_rec_leng = 4096の場合：4000

注

システムログファイル中に空き領域が発生するため，ここで求めた容量の1.2倍以上の容量を準備することをお勧めします。

ここで得られる総容量を単位時間当たりの容量に変換して，一つのシステムログファイルの容量と数を見積もってください。また，容量と数を見積もるときに，システムログファイルのアンロード間隔についても考慮してください。

注※

システムログファイルの総レコード数を求める計算式です。

(2)　システムログ量の求め方

出力されるシステムログ量は，次に示す計算式で求めます。

計算式

出力されるシステムログ量（単位：バイト）＝Σ｛ｂ＋ｅ＋↑ｂ÷（ａ−256）↑×256＋ｄ｝＋c
●回復不要FESの場合だけ加算します。
＋f

Σはトランザクションごとの合計を意味します。ただし，実行するトランザクションが次の条件をすべて満たす場合，その分のシステムログは出力されません。

検索をするトランザクションで，かつCOMMIT文で決着する

トランザクションを実行するサーバがシングルサーバ，ディクショナリサーバ，又はバックエンドサーバである

ａ：pd_log_max_data_sizeオペランドの値

ｂ：1336＋データベース操作に応じて出力されるシステムログ量

ただし，回復不要FESの場合は0になります。

データベース操作に応じて出力されるシステムログ量は，「表定義時に出力されるシステムログ量」〜「ユティリティによるデータベース作成時に出力されるシステムログ量」で求めたシステムログ量を一つのトランザクション当たりで合計した値です。

ｃ：SQL操作に応じて出力されるシステムログ量

「SQL操作に応じて出力されるシステムログ量」を参照してください。

ｄ：サーバ種別ごとに次に示す計算式で算出した値

HiRDB/シングルサーバの場合

2×pd_log_rec_lengオペランドの値

HiRDB/パラレルサーバの場合

・フロントエンドサーバのとき

マルチスレッド対応で，X/Openに準拠した接続方式を実現するHiRDBライブラリを使用したUAPの実行，かつトランザクションの移行機能の使用有無 | 回復不要FESの使用有無 | 計算式
使用 | 未使用（使用できない） | （↑1336÷pd_log_rec_lengオペランドの値↑＋3）×pd_log_rec_lengオペランドの値
未使用 | 使用 | 0
未使用 | 未使用 | 2×pd_log_rec_lengオペランドの値

・バックエンドサーバ又はディクショナリサーバのとき

システム内の，回復不要FESを使用するフロントエンドサーバの有無 | pd_rpl_reflect_modeオペランドの指定値 | 計算式
あり | uap | pd_log_rec_lengオペランドの値＋↑｛176＋128×（一つのトランザクションで更新するBESの最大数＋１）｝÷pd_log_rec_lengオペランドの値↑×pd_log_rec_lengオペランドの値
server
なし | uap
server | 2×pd_log_rec_lengオペランドの値

ｅ：

HiRDB/パラレルサーバの場合

フロントエンドサーバのとき：8＋72×一つのトランザクションで参照，又は更新するBES及びDSの最大数

フロントエンドサーバ以外のとき：0

HiRDB/シングルサーバの場合：0

ｆ：10×pd_log_rec_lengの値

注　システムログは次に示す操作をする場合に出力されます。

表の定義時

インデクスの定義時

表データの更新時

ユティリティによるデータベースの作成時

なお，上記の操作によってデータベースを更新中に，ロールバックが発生した場合，それまでデータベースを更新した分のシステムログが新たに追加で出力されます。このことを考慮してシステムログ量を見積もってください。

(3)　容量見積もり時の注意事項

次のSQLを実行すると，システムログを大量に出力します。システムログファイルの容量が不足するおそれがあるため，これらのSQLは出力するシステムログ量を見積もってから実行してください。また，見積もりの結果，システムログファイルの容量が不足する場合は，次に示す方法で容量不足を回避してください。

システムログを大量に出力するSQL | システムログファイル容量不足の回避方法
CREATE INDEX　形式1（インデクス定義） | インデクスオプションにEMPTYを指定してインデクスを定義し，データベース再編成ユティリティ（pdrorg）を使用してインデクスを作成します。そのとき，ログ取得方式に更新前ログ取得モードを指定してインデクスを作成してください。
CREATE INDEX　形式2（インデクス定義） CREATE INDEX　形式3（部分構造インデクス定義） | ログレスモードで実行してください。 なお，左記のSQL実行時は，特に大量のシステムログを出力します。そのため，システムログファイルの容量の過不足に関係なく，ログレスモードで運用することをお勧めします。ログレスモードでUAP又はユティリティを実行するときの運用については，マニュアル「HiRDB システム運用ガイド」を参照してください。

DROP SCHEMA（スキーマ削除）

指定した認可識別子のスキーマ内の次に示す定義を個別に削除し，一度に出力するシステムログ量を減らしてください。

実表

ビュー表（パブリックビューも含む）

インデクス

アクセス権限

ルーチン（DROP SCHEMAで指定した認可識別子が定義したパブリック手続き，パブリック関数を含む）

トリガ

抽象データ型

インデクス型

GRANT アクセス権限，REVOKE アクセス権限，GRANT ロール利用権限，REVOKE ロール利用権限 | 指定するロール名，認可識別子を減らし，一度に出力するシステムログ量を減らしてください。

17.1.2　表定義時に出力されるシステムログ量

表定義時に出力されるシステムログ量は，次に示す計算式で求めます。

(1)　HiRDB/シングルサーバの場合

条件 | システムログ量（単位：バイト）
表を横分割しない場合 | （（1256×b＋2500）×1.2）×a＋（632×a×d）※
表を横分割する場合 | （（1256×b＋1800×c＋2500）×1.2）×a＋（632×a×d）※

a：定義する表の総数（個）

b：定義する表の列数の平均値（個）

c：定義する表の平均分割数（個）

d：LOB列を格納するRDエリア数（個）

注※　LOB列を定義する表がある場合に加算します。

(2)　HiRDB/パラレルサーバの場合

条件 | システムログ量（単位：バイト）
ディクショナリサーバで出力されるシステムログ量 | （（1256×b＋1800×c＋2500）×1.2）×a
バックエンドサーバで出力されるシステムログ量 | 912×a×d＋（632×a×e）※

a：定義する表の総数（個）

b：定義する表の列数の平均値（個）

c：定義する表の平均分割数（個）

d：定義する表のバックエンドサーバ内での分割数（個）

e：このバックエンドサーバ内にあるRDエリアで，LOB列を格納するRDエリア数（個）

注※　このバックエンドサーバ内に定義する表で，LOB列を定義する表がある場合に加算します。

17.1.3　インデクス定義時に出力されるシステムログ量

インデクス定義時（主キーの追加を含みます）に出力されるシステムログ量は，次に示す計算式で求めます。

(1)　HiRDB/シングルサーバの場合

条件 | システムログ量（単位：バイト）

インデクスを横分割しない場合

n

Σ｛ 5624＋800×b＋1256×↑b×5÷24↑＋1256※

i=1

　　＋R＋KP＋272×Wi

　　＋1940×↑Wi÷Vi↑

　　｝

インデクスを横分割する場合

n

Σ｛ 5124＋800×b＋500×c＋800×a＋1256×↑b×5÷24↑

i=1

　　＋1256※＋R＋

a

Σ｛KP2＋272×Wij

j=1

　　＋1940↑Wij÷Vij↑｝

　　｝

注※　除外値指定がない場合は0になります。

a：インデクスを定義する表の横分割数（個）

b：インデクスの構成列数（個）

c：インデクスを格納するRDエリア数（個）

f：インデクス定義時に指定するPCTFREEオペランドの値（％）

ページ内未使用領域比率の値です。

n：定義するインデクスの総数（個）

V：インデクスを格納するユーザ用RDエリアのセグメントサイズ（ページ）

W：インデクスの格納ページ数（ページ）

「インデクスの格納ページ数の計算方法」を参照してください。

なお，CREATE INDEXでEMPTYを指定した場合は0になります。

X：インデクスを格納するユーザ用RDエリアのページ長（バイト）

h：↓pd_log_max_data_sizeオペランドの値/1000↓×1000

R：次のどちらかの値

ログ取得モードの場合：0

ログレスモードの場合：（a＋c）×h×2

KP：次のどちらかの値

ログ取得モードの場合：（132＋Xi×↑（100−f）÷100↑）×Wi

ログレスモードの場合：0

KP2：次のどちらかの値

ログ取得モードの場合：（132＋Xij×↑（100−f）÷100↑）×Wij

ログレスモードの場合：0

(2)　HiRDB/パラレルサーバの場合

条件 | システムログ量（単位：バイト）

ディクショナリサーバで出力されるシステムログ量

n

Σ｛ 5124＋800×b＋500×c＋800×a＋（1256×↑b×5÷24↑）

i=1

　　＋1256※

　｝

バックエンドサーバで出力されるシステムログ量

n

Σ｛ 814＋R＋KP＋272×Wi

i=1

　　＋1940×↑Wi÷Vi↑

　｝

注※　除外値指定がない場合は0になります。

a：インデクスを定義する表の横分割数（個）

b：インデクスの構成列数（個）

c：インデクスを格納するRDエリア数（個）

f：インデクス定義時に指定するPCTFREEオペランドの値（％）

ページ内未使用領域比率の値です。

n：定義するインデクスの総数（個）

V：インデクスを格納するユーザ用RDエリアのセグメントサイズ（ページ）

W：インデクスの格納ページ数（ページ）

「インデクスの格納ページ数の計算方法」を参照してください。

なお，CREATE INDEXでEMPTYを指定した場合は0になります。

X：インデクスを格納するユーザ用RDエリアのページ長（バイト）

h：↓pd_log_max_data_sizeオペランドの値/1000↓×1000

R：次のどちらかの値

ログ取得モードの場合：0

ログレスモードの場合：（a＋c）×h×2

KP：次のどちらかの値

ログ取得モードの場合：（132＋Xi×↑（100−f）÷100↑）×Wi

ログレスモードの場合：0

17.1.4　表データ更新時に出力されるシステムログ量

表中の行を操作すると次の表に示すシステムログが出力されます。

HiRDB/シングルサーバの場合は，ここで求めるシステムログ量をシングルサーバで出力するログ量に加算してください。HiRDB/パラレルサーバの場合は，更新対象の表及びインデクスが格納されているRDエリアを管理する，バックエンドサーバ及びディクショナリサーバで出力するログ量に，ここで求めるシステムログ量をそれぞれ加算してください。

ただし，UAPがログレスモードの場合には，ログレスモードの表データ更新時に出力されるシステムログ量を求めてください。

表17‒1　表中の行を操作したときに出力されるシステムログの種類

システムログの種類 | 説　明
基本行ログ | 基本行ログは，表中の行データを追加，削除又は更新するときに出力されます。

分岐行ログ

分岐行ログは，次に示すデータ型のデータを操作するときに出力されます。

VARCHAR※１

NVARCHAR※２

MVARCHAR※１

繰返し列

抽象データ型

BINARY型※３

インデクスログ | インデクスログは，インデクスのキーを追加，削除又は更新するときに出力されます。インデクスログ量は，データベースの操作内容（INSERT文，DELETE文及びUPDATE文）によって，表「データベースの操作内容と求めるログ量」に示すとおりに求めてください。
イベントログ | イベントログは，HiRDB Datareplicatorを使用しているとき，繰返し列を含む行データを追加，削除又は更新すると出力されます。

注※1　次に示すどちらかの条件を満たす場合に分岐行ログが出力されます。

ノースプリットオプションの指定がなく，実際のデータ長が256バイト以上の場合

ノースプリットオプションの指定があり，実際の1行のデータ長の合計がページ長を超える場合

注※2　次に示すどちらかの条件を満たす場合に分岐行ログが出力されます。

ノースプリットオプションの指定がなく，実際のデータ長が128文字以上の場合

ノースプリットオプションの指定があり，実際の1行のデータ長の合計がページ長を超える場合

注※3　実際の1行のデータ長の合計がページ長を超える場合に分岐行ログが出力されます。

表17‒2　データベースの操作内容と求めるログ量

操作内容（SQL文） | 求めるログ量
キーの追加（INSERT文） | 追加ログ量
キーの削除（DELETE文） | 削除ログ量
キーの更新（UPDATE文） | 更新前キーの削除ログ量＋更新後キーの追加ログ量

データベースを更新（INSERT，DELETE及びUPDATE）する場合に出力されるシステムログ量は，操作内容（INSERT，DELETE及びUPDATE）によって異なります。システムログ量の計算式を次に示します。

なお，ログを取得しないUAP実行時に出力されるシステムログ量は，セグメント確保が発生する場合のログ量として460バイトとなります。

条件 | 計算式（単位：バイト）
表にn行追加（INSERT）する場合又は表からn行削除（DELETE）する場合に出力されるシステムログ量 | （a＋b＋c）×n
表中のn行を更新（UPDATE）する場合に出力されるシステムログ量 | （a※１＋d※２＋e※３）×n

a：基本行ログ量（バイト）

b：全分岐行ログ量の合計値（バイト）

c：全インデクスログ量の合計値（バイト）

d：更新対象分岐行ログ量の合計値（バイト）

e：更新対象インデクスログ量の合計値（バイト）

n：操作する行数（件）

注※1　更新（UPDATE）する列値が基本行内にある場合に加算します。

注※2　更新（UPDATE）する列値が分岐行内にある場合に加算します。

注※3　更新（UPDATE）する列にインデクスを定義する場合に加算します。

(1)　基本行ログ量の見積もり

データ1件当たりの基本行ログ量の計算式を次の表に示します。

表17‒3　データ1件当たりの基本行ログ量の計算式

データの操作内容（SQL文） | 出力されるログ量（単位：バイト）
データの追加（INSERT文） | k＋152
データの削除（DELETE文）

データの更新

（UPDATE文）

FIX表でf≦12

f

Σ di ＋

i=1

f

Σ dj＋4×f＋152

j=1

非FIX表 又はf＞12 | k1＋k2＋160 ●pd_nowait_scan_optionオペランドにLOCKを指定する場合に加算します。 314×2
行インタフェース使用時 | 2×k1＋160

k：追加又は削除する行長

k1：更新する行の更新前行長

k2：更新する行の更新後行長

f：更新する列数

di：更新する列の更新前データ長

dj：更新する列の更新後データ長

注1

k，k1，k2の値は，操作する表にFIX指定をするかどうかによって異なります。それぞれの計算式を次に示します。なお，表のデータ長については次を参照してください。

表「データ長一覧」

表「可変長文字列型のデータ長一覧（抽象データ型及び繰返し列を除く）」

表「可変長文字列型のデータ長一覧（抽象データ型の場合）」

表「可変長文字列型のデータ長一覧（繰返し列の場合）」

FIX指定をする場合

表の全列のデータ長の合計値＋4

FIX指定をしない場合

表の全列のデータ長の合計値＋6＋2×表の全列数

注2

HiRDB Datareplicatorを使用している場合，FIX表に対して12列以下のUPDATEを列単位で実行すると，13列以上のUPDATEと同量のログが出力されます。

注3

表にBLOB列が定義されている場合，表「データ1件当たりの基本行ログ量の計算式」の行長はBLOB列のとき9バイト固定とし，次の表に示すログ量を加算してください。

表17‒4　BLOB列のデータ1件当たりのログ量の計算式

データの操作内容 （SQL文） | recoveryの指定 | 出力されるログ量（単位:バイト）
データの追加 （INSERT文） | なし又はpartial | 604＋180×p5
all | 2348＋p1＋8340×p2＋（148＋lt）×p3
no | 300
データの削除 （DELETE文） | なし又はpartial | 460＋180×p6
all
no | 468
データの更新 （UPDATE文） | なし又はpartial | 604＋180×p5＋460＋180×p6
all | 2496＋p1＋8340×p2＋（148 ＋lt）×p3
no | 312
データの連結演算 （UPDATE文） Bb≦7168 | なし又はpartial | 2344
all | 8340×a＋1600＋d＋8340×p4＋（148＋lt2）×p3
no | 428
データの連結演算 （UPDATE文） Bb＞7168 | なし又はpartial | 2772
all | 2772＋Ba＋8340×p4＋（148＋lt2）×p3
no | 428
データの後方削除更新 （UPDATE文） Bb≦7168 | なし又はpartial | 2344
all | 9512
no | 428
データの後方削除更新 （UPDATE文） Bb＞7168 | なし又はpartial | 2492＋180×↑（Bb-Bd）÷8192↑
all | 2492＋180×↑（Bb-Bd）÷8192↑
no | 428＋180×↑（Bb-Bd）÷8192↑

Bi：BLOBデータ長（単位：バイト）

Ba：次のどちらかの値

Bb＞7168の場合：8192−｛（Bb−7168）−↓（Bb−7168）÷8192↓×8192｝

Bb≦7168の場合：0

Bb：BLOB更新前データ長（単位：バイト）

Bc：BLOB追加データ長（単位：バイト）

Bd：更新後データ長（SUBSTR関数の値式3の指定値）（単位：バイト）

lt：次のどちらかの値

Bi＞7168の場合：Bi−7168−↓（Bi−7168）÷8192↓×8192

Bi≦7168の場合：0

lt2：次のどちらかの値

Bc＋Bb＞7168の場合：（Bc＋Bb−Ba−7168）−↓（Bc＋Bb−Ba−7168）÷8192↓×8192

Bc＋Bb≦7168の場合：0

p1：次のどちらかの値

Bi＞7168の場合：7168

Bi≦7168の場合：Bi

p2：次のどちらかの値

Bi＞7168の場合：↓（Bi−7168）÷8192↓

Bi≦7168の場合：0

p3：次のどちらかの値

lt＝0又はlt2＝0の場合：0

lt＞0又はlt2＞0の場合：1

p4：次のどちらかの値

Bc＋Bb＞7168の場合：↓（Bc＋Bb−Ba−7168）÷8192↓

Bc＋Bb≦7168の場合：0

p5：次のどちらかの値

Bi＞0の場合：↑（Bi＋1024）÷8192↑

Bi＝0の場合：0

p6：次のどちらかの値

Bb＞0の場合：↑（Bb＋1024）÷8192↑

Bb＝0の場合：0

ａ：次のどちらかの値

Bb＞0の場合：1

Bb＝0の場合：0

ｄ：次のどちらかの値

Bc＋Bb≦7168の場合：Bc＋Bb

Bc＋Bb＞7168の場合：7168

注4

pd_idx_without_rollback=Yを指定し，インデクスを定義したWITHOUT ROLLBACK指定表に対して，INSERT文，DELETE文又はインデクス構成列を更新するUPDATE文を実行する場合に312を加算してください。

(2)　分岐行ログ量の見積もり

(a)　ノースプリットオプション指定なしのVARCHAR，NVARCHAR及びMVARCHARの分岐行ログ量

発生する分岐行分のログ量を算出してその合計値を求めます。1分岐行ログ量の計算式を次の表に示します。

表17‒5　1分岐行のログ量の計算式（その1）

データの操作内容（SQL文） | 出力されるログ量 （単位：バイト）
データの追加（INSERT文） | k＋152
データの削除（DELETE文）
データの更新 （UPDATE文） | 更新によって新たな分岐行ができる場合 | k2＋160
分岐行を更新する場合 | k1＋k2＋160
更新によって分岐行が削除される場合 | k1＋160

k：追加又は削除する一つの分岐行長

k1：更新する一つの更新前分岐行長

k2：更新する一つの更新後分岐行長

注　k，k1及びk2の行長は，次に示す計算式で求めます。

8＋MIN（平均データ長の実長 ，RDエリアのページ長−48 ）

(b)　抽象データ型の列，繰返し列，BINARY型の列，ノースプリットオプション指定ありのVARCHAR，NVARCHAR及びMVARCHARの分岐行ログ量

発生する分岐行分のログ量を算出してその合計値を求めます。1分岐行ログ量の計算式を次の表に示します。

ただし，表格納RDエリアが複数あり，ページ長が各RDエリアで異なる場合は，同じページ長のRDエリアごとに計算して，その合計を分岐行ログ量として求めてください。

表17‒6　1分岐行のログ量の計算式（その2）

データの操作内容（SQL文） | 出力されるログ量（単位：バイト）
データの追加（INSERT文） | SPN×（b＋152）
データの削除（DELETE文）
データの更新（UPDATE文） | SPN×（b＋160）
データの連結演算（UPDATE文）※1 | （b＋160）＋（SPN−1）×（b＋152） ●pd_rpl_hdepathオペランドを指定する場合に加算します。 160
データの後方削除更新（UPDATE文）※1，※2 | （b×2＋160）＋（↓（c−d）÷（b−57）↓）×（b＋152） ●pd_rpl_hdepathオペランドを指定する場合に加算します。 160

注※1　

BINARY型の列の場合だけです。

注※2　

圧縮列の場合は該当しません。圧縮列のデータの後方削除更新（UPDATE文）は，データの更新（UPDATE文）で算出してください。

b：RDエリアのページ長

c：更新前データ長

d：更新後データ長（SUBSTR関数の値式3の指定値）

SPN：求め方を次に示します。

分岐する列がある場合（分岐する条件については表「データ長一覧」の注※5で説明），INSERT文及びDELETE文は表を構成するすべての列について，UPDATE文は更新対象列について次に示す値を求めてください。ただし，BINARY型の列の連結演算の場合，diは追加するデータ長として計算してください。

SPN＝SPN1＋SPN2

SPN1，及びSPN2については表「表の格納ページ数の計算方法」の「計算式中で使用する変数」を参照してください。ただし，aの値には1を設定してください。

(3)　インデクスログ量の見積もり

1本のインデクスの1行ごとの操作で出力するインデクスログ量は，次の表に示す計算式で求めます。

表17‒7　1本のインデクスログ量の計算式

キーの操作内容（SQL文） | 出力されるログ量 （単位：バイト）
pd_indexlock_modeオペランドの指定値
KEY | NONE
非ユニーク属性のインデクス | ユニーク属性のインデクス
キーの追加 （INSERT文） | 新しいキーを追加する場合 | k1＋156 | k1＋156 | k1×2＋356
追加するキーと同じ行が既にある場合 | d≦200 | k1＋156 | k1＋156 | −
d＞200 | k1＋292 | k1＋292 | −
キーの削除 （DELETE文） | キー値を削除する場合 | k2＋156 | k2＋156 | k2＋160＋a
削除するキー値と同じ値を持つ行がほかにある場合 | d≦200 | k2＋156 | k2＋156 | −
d＞200 | k2＋292 | k2＋308 | −
キーの更新（UPDATE文） | キー削除のログ量＋キー追加のログ量

d：キー値の重複数

k1：追加するキー長（バイト）

k2：削除するキー長（バイト）

a：次に示すどちらかを代入します。

pd_unique_check_modeオペランドの指定値が1の場合：20

pd_unique_check_modeオペランドの指定値が0の場合： 0

注

ここでいうキー長とは，DB格納キー長のことです。キー長の求め方については，「インデクスの格納ページ数の計算方法」を参照してください。

(a)　インデクスページスプリット時のインデクスログ量の見積もり

インデクスページスプリットの概念を次の図に示します。

図17‒1　インデクスページスプリットの概念

[picture]

〔説明〕

リーフページの一番右側（図中の最大キーが格納されているページ）にキーが追加され，ページが二つに分割されていることを最大キーが入っているページスプリットといいます。

そのほかのリーフページにキーが追加され，ページが二つに分割されていることを最大キーが入っていないページスプリットといいます。

インデクス格納ページをスプリットする場合，HiRDBは次に示す二つの方法でキー値を格納します。

●最大キー値が入っていないページスプリットの場合

キー値を追加又は削除すると，キーと未使用領域の比率をおよそ50：50にスプリットしてキー値を格納します。最大キー値が入っていないページスプリットが発生する条件を次に示します。

インデクス格納ページ内にキーが入らないとき

重複するキー値が201件以上あり，同じキー値を持つ行をa件以上追加するとき

aは次に示す計算式で求めます。このとき，a件に1回はスプリットが発生します。

計算式

a＝↑インデクスを格納するRDエリアのページ長（バイト）÷4↑

●最大キー値が入っているページスプリットの場合

最大キー値が格納されているインデクス格納ページに対してキー値を追加又は更新すると，キーと未使用領域の比率をCREATE INDEXのPCTFREEオペランドの指定値に従ってスプリットし，キー値を格納します。

例えば，PCTFREE＝30と指定すると，キーと未使用領域の比率をおよそ70：30にスプリットしてキー値を格納します。

キーの追加によってCREATE INDEXのPCTFREEオペランドに指定する分の空き領域が確保できないときに，最大キー値が入っているページスプリットが発生します。ただし，上位レベルページは該当しません。

スプリット種別による1回当たりのインデクスログ量の計算式を次の表に示します。

表17‒8　スプリット種別による1回当たりのインデクスログ量の計算式

スプリット 種別 | 条件 | 出力されるログ量 （単位：バイト）
最大キーが入っているページのスプリット | インデクス中のキー値と異なるキーを追加した場合 | 上位ページにキーを追加するための空き領域が未使用領域にある場合 | 2×k1＋a＋8×（m＋1）≦31516の場合 | 2×k1＋472＋a＋8×（m＋1）
2×k1＋a＋8×（m＋1）＞31516の場合 | 2×k1＋632＋a＋8×（m＋1）

上位ページにキーを追加するための空き領域が未使用領域にない場合

2×k1＋a＋8×（m＋1）≦31516の場合

n-1

Σ（288＋a）

i=2

＋2×k1＋472＋a＋8×（m＋1）

2×k1＋a＋8×（m＋1）＞31516の場合

n-1

Σ（288＋a）

i=2

＋2×k1＋628＋a＋8×（m＋1）

インデクス中に追加するキー値と同じキーがある場合 | d1≦200 | 上位ページにキーを追加するための空き領域が未使用領域にある場合 | 2×k1＋472＋a＋8×（m＋1）

上位ページにキーを追加するための空き領域が未使用領域にない場合

n-1

Σ（288＋a）

i=2

＋2×k1＋472＋a＋8×（m＋1）

d1＞200 | 下位ページにキーを追加するための空き領域が未使用領域にある場合 | k1＋472＋a
下位ページにキーを追加するための空き領域が未使用領域にない場合 | k1＋462＋2×a
最大キーが入っていないページのスプリット | キーを追加するための空き領域が未使用領域にない場合 | 上位ページにキーを追加するための空き領域が未使用領域にある場合 | 2×k1＋a＋8×（m＋1）≦31516の場合 | 2×k1＋332＋a＋8×（m＋1）
2×k1＋a＋8×（m＋1）＞31516の場合 | 2×k1＋492＋a＋8×（m＋1）

上位ページにキーを追加するための空き領域が未使用領域にない場合

2×k1＋a＋8×（m＋1）≦31516の場合

n-1

Σ（288＋a）

i=2

＋2×k1＋332＋a＋8×（m＋1）

2×k1＋a＋8×（m＋1）＞31516の場合

n-1

Σ（288＋a）

i=2

＋2×k1＋492＋a＋8×（m＋1）

ａ：インデクスを格納しているRDエリアのページ長（バイト）

d1：キー値の重複数

k1：追加するキー長（バイト）

ここでいうキー長とは，DB格納キー長のことです。キー長の求め方については，「インデクスの格納ページ数の計算方法」を参照してください。

ｍ：スプリットが発生した時点のインデクス段数

ｎ：スプリットが波及した上位ページの段数

リーフページのスプリットによって波及した上位ページが，さらにスプリットした場合はn＝3（n≧3）となります。

注

この計算式は，1件当たりの行及びインデクス部分の更新ログ量の見積もり式です。このため，この計算式には，追加及び更新によって，新しいページ又はセグメントを確保したときのシステム管理情報に関するログ量を含んでいません。したがって，大量のデータを扱う場合は，次の表に示すログ量を加算して見積もる必要があります。

表17‒9　ページ／セグメントの確保ログ量の計算式

条件 | 出力されるログ量 （単位：バイト）
データの追加（INSERT）又は更新（UPDATE）によって，行の格納ページを新しく確保する場合 | 440
データの追加（INSERT）又は更新（UPDATE）によって，インデクスのページスプリットが発生する場合 | 544×n＋272
上記のページ確保に対して，セグメントの確保が発生する場合（セグメントサイズ数分のページ確保をするごとに発生します） | 1940

n：ページスプリットが発生した時点のインデクスの段数＋1

(4)　イベントログ量の見積もり

イベントログはHiRDB Datareplicatorを使用しているときに，繰返し列を含む行データを追加，削除又は更新すると出力されます。1行を操作したときに出力されるイベントログ量を次の表に示します。

表17‒10　1行を操作したときに出力されるイベントログ量

データ操作内容 | イベントログ量 （単位：バイト）
データの追加（INSERT文） | 156×n
データの更新（UPDATE文） | 更新によって新しい要素が追加される場合（UPDATE ADD） | 164×n
更新によって要素が削除される場合 （UPDATE DELETE） | n Σ （p5 +160） i=1
指定した要素だけを更新する場合 （UPDATE SET） | n Σ （p5 +160） i=1
指定した繰返し列を更新する場合 （UPDATE SET） | 164×n

n：更新対象となる繰返し列の数

p5：↑｛↑（指定する最大添字番号の平均値−指定する最小添字番号の平均値＋1）÷8↑｝÷4↑×4

(5)　ログレスモードの表データ更新時に出力されるシステムログ量の見積もり

ログレスモードの表データ更新時に出力されるシステムログ量は，次に示す計算式で求めます。

計算式

（a＋b＋c）×h×2
＋（（d＋c）×156）
＋（（e＋f）×148)

a：更新対象表を格納するRDエリア数（個）

b：更新対象表のインデクスを格納するRDエリア数（個）

c：更新対象表のLOB列を格納するRDエリア数（個）

d：更新対象表数（個）

e：表データ更新による表の使用中セグメントの増加数：

↑（データ更新後の表の格納ページ数−データ更新前の表の格納ページ数）

　÷更新対象表を格納するRDエリアのセグメントサイズ↑

f：表データ更新によるインデクスの使用中セグメントの増加数：

↑（データ更新後のインデクスの格納ページ数

　−データ更新前のインデクスの格納ページ数）

　÷更新対象表のインデクスを格納するRDエリアのセグメントサイズ↑

h：↓pd_log_max_data_sizeオペランドの値/1000↓×1000

17.1.5　ユティリティによるデータベース作成時に出力されるシステムログ量

次に示すユティリティを実行する場合，表「ユティリティによるデータベース作成時に出力されるシステムログ量の計算式」に示すシステムログが出力されます。

データベース作成ユティリティ（pdloadコマンド）

データベース再編成ユティリティ（pdrorgコマンド）

リバランスユティリティ（pdrbalコマンド）

システムログ量は表「ユティリティによるデータベース作成時に出力されるシステムログ量の計算式」で求めた値に，表「システムログ量の算出時に加算する値と加算する場合の条件」に示す値を加算して算出します。なお，表及びインデクスを横分割している場合は，表及びインデクスを格納するRDエリアごとにシステムログ量を計算します。

HiRDB/シングルサーバの場合

RDエリアごとに計算したシステムログ量の合計を，シングルサーバで出力するログ量に加算してください。

HiRDB/パラレルサーバの場合

RDエリアごとに計算したシステムログ量の合計を，処理対象の表又はインデクスを管理するバックエンドサーバのログ量に加算してください。ただし，データベース再編成ユティリティ（pdrorg）でディクショナリ表の再編成を行う場合は，ディクショナリサーバで出力するログ量に加算してください。

表17‒11　ユティリティによるデータベース作成時に出力されるシステムログ量の計算式

項番 | 条件 | 出力されるシステムログ量（単位：バイト）
-lオプションにaを指定 | -lオプションにpを指定

1

インデクスを一括作成する場合（-iオプションにcを指定）

対象ユティリティ

pdload

pdrorg

pdrbal

n

Σ｛

i=1

　［132＋↑(100−f)÷100↑×Xi］×Wi

　＋280×Wi＋1940×↑Wi÷Vi↑

　｝

＋280×m＋1940×↑m÷s↑＋a×r

n

Σ｛

i=1

　280×Wi＋1940×↑Wi÷Vi↑

　｝

＋280×m＋1940×↑m÷s↑＋c×r

2

インデクス更新モードでインデクスを作成する場合（-iオプションにsを指定）

対象ユティリティ

pdload

pdrorg

pdrbal

n

Σ｛

i=1

　280×Wi＋1940×↑Wi÷Vi↑

　＋b×r＋e×d

　｝

＋280×m＋1940×↑m÷s↑＋a×r

n

Σ｛

i=1

　280×Wi＋1940×↑Wi÷Vi↑

　＋b×r＋e×d

　｝

＋280×m＋1940×↑m÷s↑＋c×r

3

インデクスを作成しない場合（-iオプションにn又はxを指定）

対象ユティリティ

pdload

pdrorg

pdrbal

280×m＋1940×↑m÷s↑＋a×r

280×m＋1940×↑m÷s↑＋c×r

4

インデクスを再作成，又は再編成する場合（pdload 0件ロード，又はpdrorg -kオプションにixrc若しくはixorを指定）

n

Σ｛280wi+1940×↑Wi÷Vi↑

i=1

　＋(「インデクス定義時に出力されるシステムログ量」)

　＋(表「ページ／セグメントの確保ログ量の計算式」)

　＋(表「PURGE TABLE文実行時に出力されるシステムログ量」のインデクスのシステムログ量)

｝

n

Σ｛280wi+1940×↑Wi÷Vi↑

i=1

　＋(表「ページ／セグメントの確保ログ量の計算式」)

　＋(表「PURGE TABLE文実行時に出力されるシステムログ量」のインデクスのシステムログ量)

｝

注

インデクスの一括作成又はインデクスの作成時のシステムログ量は，作成するインデクス数分の計算が必要です。

ａ：表「データ1件当たりの基本行ログ量の計算式」，表「BLOB列のデータ1件当たりのログ量の計算式」で求めた，データを1件追加するときに出力されるログ量

ｂ：表「1本のインデクスログ量の計算式」で求めたデータを1件追加するときに出力されるログ量

ｃ：表「BLOB列のデータ1件当たりのログ量の計算式」で求めた，データを1件追加するときに出力されるログ量

ｄ：インデクススプリット時に出力されるシステムログ量

表「スプリット種別による1回当たりのインデクスログ量の計算式」及び表「ページ／セグメントの確保ログ量の計算式」を参照してください。

ｅ：インデクスのスプリット回数

ｆ：インデクス定義時に指定するPCTFREEオペランド（ページ内未使用領域比率）の値（％）

ｍ：表の格納ページ数（ページ）

「表の格納ページ数の計算方法」を参照してください。

ｎ：表に定義されているインデクス数（個）

ｒ：表に格納する行数（行）

ｓ：表を格納するユーザ用RDエリアのセグメントサイズ（ページ）

Vi：インデクスを格納するユーザ用RDエリアのセグメントサイズ（ページ）

Wi：インデクスの格納ページ数（ページ）

「インデクスの格納ページ数の計算方法」を参照してください。

Xi：インデクスを格納するユーザ用RDエリアのページ長（バイト）

表「ユティリティによるデータベース作成時に出力されるシステムログ量の計算式」の項番1，及び項番2の場合に，システムログ量の算出時に加算する値と，加算する場合の条件を次の表に示します。

表17‒12　システムログ量の算出時に加算する値と加算する場合の条件

加算する場合の条件 | システムログ量に加算する値
LOB列を定義している表の場合 | 次に示すログ量を（LOB列数×行数）の数分加算してください。 LOB列の回復属性がrecovery no以外の場合 3544×（LOBデータ長÷31744）　（単位：バイト）
データベース作成ユティリティ（pdload）を-dオプション指定で，又はデータベース再編成ユティリティ（pdrorg）を実行する場合 | 表「PURGE TABLE文実行時に出力されるシステムログ量」の「表」又は「リバランス表」と，対象表に定義されている全インデクス，及び全LOB列（又はLOB属性）のログ量を加算してください。
データベース再編成ユティリティ（pdrorg）でLOB列，又はLOB属性がある表を再編成する場合で次の二つの条件を満たすとき -jオプションを指定しないで再編成する LOB列がrecovery no指定でなく，かつ-lオプションがn指定でない | 次に示すログ量をLOB用RDエリアの構成ファイル数分加算してください。 　Σ｛17000×↑（HiRDBファイルのセグメント数÷64000）↑×95｝

次に示すログ量を（LOB列又はLOB属性の数×行数）の数分加算してください。

●LOB列がrecovery all指定かつ-l a指定の場合

　↑17600÷sr↑×sr

●上記以外の場合

　↑3200÷sr↑×sr

sr：pd_log_rec_lengオペランドで指定するシステムログファイルのレコード長

HiRDB Datareplicator連携機能を使用（pd_rpl_hdepathオペランドを指定）していて，表に繰返し列を含む場合 | 表「1行を操作したときに出力されるイベントログ量」に示すログ量を追加行数分加算してください。

17.1.6　SQL操作に応じて出力されるシステムログ量

システムログは，システム共通定義のpdhibeginオペランドに-k cncを指定している状態で，CONNECT，DISCONNECT又はset session authorizationを実行した場合に出力されます。

SQL操作に応じて出力されるシステムログ量を求める計算式を次に示します。HiRDB/シングルサーバの場合はシングルサーバで出力するログ量，HiRDB/パラレルサーバの場合はフロントエンドサーバで出力するログ量に，このログ量を加算してください。

計算式

システムログ量（単位：バイト）＝568×（CONNECT回数＋set session authorization実行回数）

17.1.7　拡張システム定義スカラ関数の定義時に出力されるシステムログ量

pdextfuncコマンドで拡張システム定義スカラ関数を定義した場合に出力されるシステムログ量を次に示します。HiRDB/シングルサーバの場合はシングルサーバで出力するログ量，HiRDB/パラレルサーバの場合はディクショナリサーバで出力するログ量に，このログ量を加算してください。

システムログ量（単位：バイト）＝233529

17.1.8　RDエリアの自動増分機能使用時に出力されるシステムログ量

RDエリアの自動増分機能を使用すると，自動増分の実行時にシステムログが出力されます。

出力されるシステムログ量を求める計算式を次の表に示します。HiRDB/シングルサーバの場合はシングルサーバで出力するログ量，HiRDB/パラレルサーバの場合は対象となるRDエリアを管理するバックエンドサーバ及びディクショナリサーバで出力するログ量に，このログ量を加算してください。

表17‒13　RDエリアの自動増分機能使用時に出力されるシステムログ量

RDエリアの種類 | システムログ量（単位：バイト）
LOB用RDエリアの場合 | 1956
LOB用RDエリア以外の場合 | 1372＋（144＋ｐ）×2

ｐ：自動増分するRDエリアのページサイズ

17.1.9　PURGE TABLE文実行時に出力されるシステムログ量

PURGE TABLE文実行時に出力されるシステムログ量は，表に定義されているすべてのインデクス，LOB列，又はLOB属性分のログ量を合計して求めます。分割表，及び分割インデクスの場合はRDエリアごとに求めたログ量を合計して求めます。

求めた値を，HiRDB/シングルサーバの場合はシングルサーバで出力するログ量に加算してください。HiRDB/パラレルサーバの場合は，対象となる表が格納されているRDエリア（表に定義されているインデクス，LOB列，及びLOB属性が格納されているRDエリアも含む）を管理するバックエンドサーバのログ量に加算してください。

PURGE TABLE文実行時のシステムログ量の計算式を次の表に示します。なお，計算式中の変数A，B，CはRDエリア構成ファイルごとに求めてください。

表17‒14　PURGE TABLE文実行時に出力されるシステムログ量

種別 | システムログ量（単位：バイト）
表 | 1000＋1100×確保セグメント数
リバランス表 | 1000＋1100×確保セグメント数＋400×↑1024÷分割RDエリア数↑
インデクス※ | 1000＋1100×確保セグメント数
LOB列又はLOB属性※ | 1000＋17000×A＋160×B＋2×C

Ａ：↑（HiRDBファイルの使用中セグメント数÷64000）↑×95

Ｂ：↑（HiRDBファイルの使用中セグメント数÷64000）↑

Ｃ：↑（HiRDBファイルの使用中セグメント数÷64000）↑×8150

注※

プラグインの場合は，各プラグインの初期化のログが出力されます。各プラグインのマニュアルを参照してください。

17.1.10　空きページ解放ユティリティ（pdreclaim）実行時に出力されるシステムログ量

空きページ解放ユティリティ（pdreclaim）による表，インデクスの空きページ，又はセグメントの解放をする場合，システムログを出力します。

指定したオプションと対象となる資源の組み合わせによるログ量を次に示します。なお，ログ量の説明の項番は，表「空きページ解放ユティリティ実行時に出力されるシステムログ量」の項番に対応しています。

オプション | 対象資源 | ログ量
なし | 表 | 項番(1)の値
インデクス | 項番(2)の値
-j | 表 | 項番(3)の値
インデクス
-a | 表 | 項番(1)と(4)を合計した値
インデクス | 項番(2)と(4)を合計した値

ログ量を求める計算式を次の表に示します。なお，表及びインデクスを横分割している場合は分割したRDエリアごとに計算する必要があります。HiRDB/シングルサーバの場合は，横分割したRDエリアごとに計算したログ量の合計を求めます。これを，シングルサーバが出力するログ量に加算してください。HiRDB/パラレルサーバの場合は，横分割したRDエリアごとに計算したログ量をサーバごとに求め，その合計を求めます。これを，対象資源が格納されているRDエリアを管理するバックエンドサーバ及びディクショナリサーバのログ量に，それぞれ加算してください。

表17‒15　空きページ解放ユティリティ実行時に出力されるシステムログ量

項番 | 種別 | システムログ量（単位：バイト）
(1) | 表 | 140×n ●-oオプションを指定していない場合に加算します。 ＋504×m
(2) | インデクス | キー値の重複が201以上のキーが存在しない | ｛（（k＋14）÷（j−68））×1408＋k＋12×h＋908｝×n＋304×q ●-xオプションを指定している場合に加算します。 +｛m−ｎ−（（（k＋14）×2×m）÷（j−68））｝×（j＋76）×0.7
キー値の重複が201以上のキーが存在する | （724＋k）×n＋285×MAX（n，16×n÷（j−78））−159＋304×q ●-xオプションを指定している場合に加算します。 +｛m−ｎ−（（（k＋14）×2×m）÷（j−68））｝×（j＋76）×0.7
(3) | セグメント | -jオプション指定時 | 2380×p ●-kオプションにindexを指定している場合に加算します。 ＋304×p
(4) | -aオプション指定時 | 3100×p ●-kオプションにindexを指定している場合に加算します。 ＋304×p

h：インデクスの段数（段）

j：ページサイズ（バイト）

k：インデクスキーの長さ（バイト）

m：使用中ページ数（満杯ページを除く）（個）

n：使用中空きページ数（個）

p：使用中空きセグメント数（個）

解放途中セグメントの数を含みます。

q：空きありセグメント数（個）

使用中セグメント数から満杯セグメント数を引いた数となります。

使用中セグメント数と満杯セグメント数は，データベース状態解析ユティリティ（pddbst）で確認できます。

17.1.11　再編成時期予測機能使用時に出力されるシステムログ量

再編成時期予測機能を使用する場合，HiRDB/パラレルサーバの場合はディクショナリサーバで出力するログ量，HiRDB/シングルサーバの場合はシングルサーバで出力するログ量に，次の計算式で求められるログ量を加算する必要があります。

計算式

システムログ量（単位：バイト）＝
　n×｛1604×（A＋B＋C＋D）×（↑E↑＋1）｝
　＋m×｛872×（a＋b＋c＋1）｝
　＋11680×↑｛（A＋B＋C＋D）×（↑E↑＋1）｝×30÷540↑
　＋332×｛（A＋B＋C＋D）×（↑E↑＋1）｝×30
　＋7760

A：作成した表数＋61

B：作成したインデクス数＋124

C：作成した表に定義したBLOB列の総数＋3

D：作成した表に定義したBLOB属性の総数

E：表を格納するRDエリアの分割数の平均値

分割していない場合は1とします。また，平均値は切り上げます。

a：SQL又はコマンドが処理した表を格納しているRDエリア数

b：SQL又はコマンドが処理したインデクスを格納しているRDエリア数

c：SQL又はコマンドが処理した表を格納するLOB用RDエリア数

n：状態解析結果蓄積機能（pddbst -k logi -e）を実行した回数

m：運用履歴表を更新するSQL又はコマンドの実行回数

運用履歴表を更新するSQL及びコマンドについては，マニュアル「HiRDB システム運用ガイド」を参照してください。

17.1.12　更新可能バックアップ閉塞中に出力されるシステムログ量

更新可能バックアップ閉塞中にデータベースを更新すると，次に示す計算式の分だけシステムログが追加で出力されます。HiRDB/シングルサーバの場合は，ここで求めるシステムログ量をシングルサーバで出力するログ量に加算してください。HiRDB/パラレルサーバの場合は，更新対象のRDエリアを管理するバックエンドサーバ及びディクショナリサーバに対して，該当するログ量をそれぞれ加算してください。

ただし，バックアップ閉塞中にHiRDBが異常終了又は強制終了した場合，HiRDBの再開始時にバックアップ閉塞を引き継ぎません（参照可能バックアップ閉塞を除く）。このため，この計算式で示すシステムログは出力されません。

計算式

a
Σ （Ｓi＋200）×Ｔi
i=1

a：更新可能バックアップ閉塞中に更新したRDエリア数

Si：RDエリアのページサイズ（バイト）

Ti：更新可能バックアップ閉塞中に更新したRDエリアの更新ページ数

RDエリアの更新ページ数は次に示す手順で求めます。

〈手順〉

次に示すタイミングで統計解析ユティリティ（データベース操作に関するHiRDBファイルの統計情報）を実行します。

・更新可能バックアップ閉塞の開始時

・更新可能バックアップ閉塞の解除時

「同期WRITE回数（SYNC-W）」を参照し，その差分で更新ページ数を求めます。

17.1.13　pdchpathnコマンド実行時に出力されるシステムログ量

HiRDB/シングルサーバの場合はシングルサーバで出力するログ量，HiRDB/パラレルサーバの場合はディクショナリサーバで出力するログ量に，このログ量を加算してください。

計算式

システムログ量（単位：バイト）
　　　　　　＝590×a

a：SQL_PHYSICAL_FILES表の行数

17.1.14　ディクショナリ表のメンテナンス実行時に出力されるシステムログ量

HiRDB/シングルサーバの場合はシングルサーバで出力するログ量，HiRDB/パラレルサーバの場合はディクショナリサーバで出力するログ量に，このログ量を加算してください。

計算式

システムログ量（単位：バイト）
＝ 2×（8480＋(132＋page_len)×idx_page＋272×idx_page＋1940×↑idx_page÷seg_size↑）

変数の説明

idx_page：インデクスの格納ページ数（ページ）

「データディクショナリ用RDエリアの容量の見積もり」の「インデクスの格納ページ数の計算方法」を参照してください。

page_len：データディクショナリ用RDエリアのページ長（バイト）

seg_size：データディクショナリ用RDエリアのセグメントサイズ（ページ数）

17.1.15　ロール機能使用時に出力されるシステムログ量

ロール機能使用時に出力されるシステムログ量は，次に示す計算式で求めます。

HiRDB/シングルサーバの場合はシングルサーバで出力するログ量，HiRDB/パラレルサーバの場合はディクショナリサーバで出力するログ量に，このログ量を加算してください。

表17‒16　ロール機使用時に出力されるシステムログ量

種別 | システムログ量（単位：バイト）
CREATE ROLE | 18,699
DROP ROLE | 593＋494×（ロール利用権限を付与した認可識別子の数＋1）＋760×ロールに付与したアクセス権限の表の総数
GRANT アクセス権限 | 9,328×指定した認可識別子数
REVOKE アクセス権限 | 760×指定した認可識別子数
GRANT ロール利用権限 | 7,158×指定したロール名数×認可識別子数
REVOKE ロール利用権限 | 494×指定したロール名数×認可識別子数

17.2　シンクポイントダンプファイルの容量の見積もり

17.2.1　シンクポイントダンプファイルの容量の計算方法

(1)　シンクポイントダンプファイルの容量の求め方

シンクポイントダンプファイルの容量は，次に示す計算式で求めます。

計算式

シンクポイントダンプファイルの容量（単位：バイト）
　　　　　　　＝MAX（12，シンクポイントダンプファイルのレコード数）※１×4096※２

注※1

「シンクポイントダンプファイルのレコード数の求め方」を参照してください。ここで求めた値をpdloginitコマンドの-nオプションに指定します。求めた値が12未満の場合，pdloginitコマンドの-nオプションには12を指定してください。

注※2

シンクポイントダンプファイルのレコード長です。

(2)　シンクポイントダンプファイルのレコード数の求め方

条件 | レコード数の計算式
HiRDB/シングルサーバの場合 | ↑（96＋112×a）÷4096↑＋3
HiRDB/パラレルサーバの場合 | フロントエンドサーバの場合 | 4
バックエンドサーバの場合 | ↑（96＋112×a）÷4096↑＋3
ディクショナリサーバの場合 | ↑（96＋112×a）÷4096↑＋3

ａ：pd_lck_until_disconnect_cntオペランドの値

17.3　ステータスファイルの容量の見積もり

17.3.1　ステータスファイルの容量の計算方法

(1)　ステータスファイルの容量の求め方

ステータスファイルの容量は，次に示す計算式で求めます。

計算式

ステータスファイルの容量（単位：バイト）＝a×b

ａ：ステータスファイルのレコード数

「ステータスファイルのレコード数の求め方」を参照してください。ここで求めた値をpdstsinitコマンドの-cオプションに指定します。

ｂ：ステータスファイルのレコード長

pdstsinitコマンドの-lオプションに指定する値です。

(2)　ステータスファイルのレコード数の求め方

ステータスファイルのレコード数は，次に示す計算式で求めます。

計算式

レコード数＝↑｛↑S÷（レコード長−40）↑＋↑S÷100↑＋S＋2 ｝×1.2↑

注　Sについては，「Sの求め方」を参照してください。

(3)　Sの求め方

(a)　HiRDB/シングルサーバの場合

種別 | Sの計算式
ユニット用 | ↑（2056＋128×d）÷g↑＋↑2512÷g↑＋↑40÷g↑ ＋↑308÷g↑＋↑4000÷g↑＋↑43536÷g↑＋↑32÷g↑

サーバ用

↑128÷g↑＋↑3280※１÷g↑＋↑（592※２＋j×b）÷g↑

＋↑8192÷g↑＋↑（8192−128）÷g↑×｛↑（a＋m）÷k↑−1｝

＋↑［↑｛（↑c÷127↑＋1）×2048｝÷8192↑×8192］÷g↑

＋↑2048÷g↑＋↑｛244＋64×（2×h＋7）｝÷g↑

＋↑96÷g↑＋↑｛48＋68×（2×h＋7）｝÷g↑

＋↑［20480×｛1＋↑（（152×e）−（16×f）−（80×A）＋（8×B））

÷20476↑＋↑（4f＋4C）÷20480↑｝］÷g↑

＋↑（12×c＋4）÷g↑

＋w

＋↑（4＋16×c）÷g↑

●ステータスファイルのレコード長＜4096の場合に加算します。

＋↓MAX｛3400÷r＋0.7，1｝↓×MAX（↓4096÷s↓，2）×n

＋↓5662310÷r＋0.7↓×MAX（↓4096÷s↓，2）×p

●4096≦ステータスファイルのレコード長＜12288の場合に加算します。

＋↓MAX｛（3400÷↓（s−348）÷20↓）＋0.7，1｝↓×n

＋↓（5662310÷↓（s−348）÷20↓）＋0.7↓×p

●12288≦ステータスファイルのレコード長の場合に加算します。

＋↓MAX｛（3400÷↓（s−876）÷20↓）＋0.7，1｝↓×n

＋↓（5662310÷↓（s−876）÷20↓）＋0.7↓×p

●pd_log_auto_unload_pathオペランドを指定する場合に加算します。

＋↑20848÷g↑

●高速系切り替え機能を使用する場合に加算します。

＋↑（↑（256×i＋4096）÷4096↑）×4096÷g↑

●pd_dbbuff_modifyオペランドにYを指定する場合に加算します。

＋v

ａ：pdlogadfgオペランドの指定数

ｂ：pdlogadfg -d spdオペランドの指定数

ｃ：pd_max_rdarea_noオペランドの値

ｄ：109

ｅ：pdbufferオペランドの指定数

ｆ：pdbufferオペランドの-iオプション指定数

ｇ：ステータスファイルのレコード長−40

ｈ：pd_max_usersの値

ｉ：pd_max_rdarea_noオペランドの値

ｊ：736

ｋ：11

ｍ：1

ｎ：サーバ内のRDエリア数≦3400の場合は1

3401≦サーバ内のRDエリア数≦6800の場合は2

6801≦サーバ内のRDエリア数の場合は3

ｐ：サーバ内のRDエリア数≦10200の場合は0

10201≦サーバ内のRDエリア数≦5672510の場合は1

5672511≦サーバ内のRDエリア数≦11334820の場合は2

11334821≦サーバ内のRDエリア数の場合は3

ｒ：↓（s−348）÷20↓＋↓g÷20↓×（MAX（↓4096÷s↓，2）−1）

ｓ：ステータスファイルのレコード長

ｖ：32ビットモードの場合：↑（24＋28×（x＋512）＋32＋112×D）÷g↑

64ビットモードの場合：↑（32＋32×（x＋512）＋32＋144×D）÷g↑

w：32ビットモードの場合：↑（（12＋（↑↑（c÷8）↑÷4↑）×4）×z）÷g↑

64ビットモードの場合：↑（（12＋（↑↑（c÷8）↑÷8↑）×8）×z）÷g↑

x：pd_max_add_dbbuff_shm_noオペランドの値

y：pd_max_add_dbbuff_noオペランドの値

z：pdbufferオペランドの-iオプション指定総数に，pd_max_add_dbbuff_noオペランドの値を加算した値（pd_dbbuff_modifyオペランドにY以外を指定した場合は0として計算します）

A：システム共通定義のpdbufferオペランドの-oオプション指定あり：1

システム共通定義のpdbufferオペランドの-oオプション指定なし：0

B：システム共通定義のpdbufferオペランドの-rオプション及び-bオプションに指定したRDエリアの総数

C：システム共通定義のpdbufferオペランドの-iオプションに指定したインデクスを格納しているRDエリアの総数

D：システム共通定義のpd_dbbuf_modifyオペランドにYを指定した場合：

システム共通定義のpd_max_add_dbbuff_noオペランドを指定したとき：e＋y

システム共通定義のpd_max_add_dbbuff_noオペランドを省略したとき：1000

システム共通定義のpd_dbbuf_modifyオペランドにNを指定した場合：e

注※1　64ビットモードの場合は3456です。

注※2　64ビットモードの場合は688です。

(b)　HiRDB/パラレルサーバの場合

種別 | Sの計算式

ユニット用

↑［2056＋128×｛14×（p−P＋q＋N）＋（p−P＋q＋r）

＋（25＋15×（p−P）＋7×q＋3×r）＋（s×2＋1）＋（N×16）

＋（38＋4×（p−P＋q＋r＋N）＋d＋z＋3×（p−P＋q＋r＋N））｝］÷j↑

＋↑944÷j↑＋↑4816÷j↑＋↑40÷j↑

＋↑308÷j↑＋↑4000÷j↑＋↑43536÷j↑

＋↑16÷j↑＋↑16÷j↑

●影響分散スタンバイレス型系切り替え機能を使用しない場合に加算します。

＋↑32÷j↑

●影響分散スタンバイレス型系切り替え機能を使用する場合に加算します。

＋↑［20480×｛1＋↑（（152×f）−（16×g）−（80×Q）＋（8×R））÷20476↑＋↑（4g＋4S）÷20480↑｝］÷j↑

フロントエンド

サーバ用

↑128÷j↑＋↑3280※１÷j↑＋↑（592※２＋A×b）÷j↑

＋↑8192÷j↑＋↑（8192−128）÷j↑×{↑（a＋C）÷B↑−1}

＋↑8192÷j↑＋↑2048÷j↑

＋↑｛244＋64×（2×e＋7）｝÷j↑＋↑96÷j↑＋↑32÷j↑

●pd_log_auto_unload_pathオペランドを指定する場合に加算します。

＋↑20848÷j↑

ディクショナリ

サーバ用

↑128÷j↑＋↑3280※１÷j↑＋↑（592※２＋A×b）÷j↑

＋↑8192÷j↑＋↑8192÷j↑×｛↑（a＋C）÷B↑−1｝

＋↑［↑｛（↑c÷127↑＋1）×2048｝÷8192↑×8192］÷j↑

＋↑2048÷j↑＋↑｛244＋64×（2×h＋7）｝÷j↑＋↑96÷j↑

＋↑｛48＋68×（2×h＋7）｝÷j↑

＋↑［20480×｛1＋↑（（152×f）−（16×g）−（80×Q）＋（8×R））

　÷20476↑＋↑（4g＋4S）÷20480↑｝］÷j↑

＋↑（12×c＋4）÷j↑＋↑32÷j↑

＋H

＋↑（4＋16×c）÷j↑

●ステータスファイルのレコード長＜4096の場合に加算します。

＋↓MAX｛3400÷D＋0.7，1｝↓×MAX（↓4096÷n↓，2）

●4096≦ステータスファイルのレコード長＜12288の場合に加算します。

＋↓MAX｛（3400÷↓（n−348）÷20↓）＋0.7，1｝↓

●12288≦ステータスファイルのレコード長の場合に加算します。

＋↓MAX｛（3400÷↓（n−876）÷20↓）＋0.7，1｝↓

●系切り替え機能を使用する場合に加算します。

＋↑（↑（256×c＋4096）÷4096↑×4096）÷j↑

●pd_log_auto_unload_pathオペランドを指定する場合に加算します。

＋↑20848÷j↑

●pd_dbbuff_modifyオペランドにYを指定する場合に加算します。

＋G

バックエンド

サーバ用

↑128÷j↑＋↑3280※１÷j↑＋↑（592※２＋A×b）÷j↑

＋↑8192÷j↑＋↑8192÷j↑×｛↑（a＋C）÷B↑−1｝

＋↑［↑｛（↑c÷127↑＋1）×2048｝÷8192↑×8192］÷j↑

＋↑2048÷j↑＋↑｛244＋64×（2×i＋7）｝÷j↑＋↑96÷j↑

＋↑｛48＋68×（2×i＋7）｝÷j↑＋↑（12×c＋4）÷j↑

＋↑［20480×｛1＋↑（（152×f）−（16×g）−（80×Q）＋（8×R））

　÷20476↑＋↑（4g＋4S）÷20480↑｝］÷j↑※３

＋↑32÷j↑＋H＋↑（4＋16×c）÷j↑

●ステータスファイルのレコード長＜4096の場合に加算します。

＋↓MAX｛3400÷D＋0.7，1｝↓×MAX（↓4096÷n↓，2）×k

＋↓5662310÷D＋0.7↓×MAX（↓4096÷n↓，2）×m

●4096≦ステータスファイルのレコード長＜12288の場合に加算します。

＋↓MAX｛（3400÷↓（n−348）÷20↓）＋0.7，1｝↓×k

＋↓（5662310÷↓（n−348）÷20↓）＋0.7↓×m

●12288≦ステータスファイルのレコード長の場合に加算します。

＋↓MAX｛（3400÷↓（n−876）÷20↓）＋0.7，1｝↓×k

＋↓（5662310÷↓（n−876）÷20↓）＋0.7↓×m

●系切り替え機能を使用する場合に加算します。

＋↑（↑（256×y＋4096）÷4096↑×4096）÷j↑

●影響分散スタンバイレス型系切り替え機能を使用する場合に加算します。

＋↑2816÷j↑＋↑80÷j↑

＋↑32÷j↑

●pd_log_auto_unload_pathオペランドを指定する場合に加算します。

＋↑20848÷j↑

●pd_dbbuff_modifyオペランドにYを指定する場合に加算します。

＋G

ａ：pdlogadfgオペランドの指定数

ｂ：pdlogadfg -d spdオペランドの指定数

ｃ：pd_max_rdarea_noオペランドの値

ｄ：3

ただし，1サーバマシンでのHiRDB/パラレルサーバの場合は2

ｅ：pd_max_usersオペランドの値＋1

ただし，1サーバマシンでのHiRDB/パラレルサーバの場合はpd_max_usersオペランドの値

ｆ：pdbufferオペランドの指定数

ｇ：pdbufferオペランドの-iオプション指定数

ｈ：pd_max_dic_processオペランドの値

ｉ：pd_max_bes_processオペランドの値

ｊ：ステータスファイルのレコード長−40

ｋ：サーバ内のRDエリア数≦3400の場合は1

3401≦サーバ内のRDエリア数≦6800の場合は2

6801≦サーバ内のRDエリア数の場合は3

ｍ：サーバ内のRDエリア数≦10200の場合は0

10201≦サーバ内のRDエリア数≦5672510の場合は1

5672511≦サーバ内のRDエリア数≦11334820の場合は2

11334821≦サーバ内のRDエリア数の場合は3

ｎ：ステータスファイルのレコード長

ｐ：ユニット内のバックエンドサーバ数

ｑ：ユニット内にディクショナリサーバがある場合は1，ない場合は0

ｒ：ユニット内にフロントエンドサーバがある場合は1，ない場合は0

ｓ：ユニット内にシステムマネジャがある場合は1，ない場合は0

ｙ：pd_max_rdarea_noオペランドの値

ｚ：次の場合は1

ユニット内にシステムマネジャがある場合

ユニット内にシステムマネジャがない場合で，pd_mlg_msg_log_unitオペランドにlocalを指定しているとき

ユニット内にシステムマネジャがない場合で，pd_mlg_msg_log_unitオペランドにmanagerを指定しているか，又は指定を省略しているときは0

A：736

B：11

C：1

D：↓（n−348）÷20↓＋↓j÷20↓×（MAX（↓4096÷n↓，2）−1）

G：32ビットモードの場合：↑（24＋28×（I＋512）＋32＋112×T）÷j↑

64ビットモードの場合：↑（32＋32×（I＋512）＋32＋144×T）÷j↑

H：32ビットモードの場合：↑（（12＋（↑↑（c÷8）↑÷4↑）×4）×K）÷j↑

64ビットモードの場合：↑（（12＋（↑↑（c÷8）↑÷8↑）×8）×K）÷j↑

I：pd_max_add_dbbuff_shm_noオペランドの値

J：pd_max_add_dbbuff_noオペランドの値

K：pdbufferオペランドの-iオプション指定総数に，pd_max_add_dbbuff_noオペランドの値を加算した値（pd_dbbuff_modifyオペランドにY以外を指定した場合は0として計算します）

N：pd_ha_max_act_guest_serversオペランドを指定した場合：pd_ha_max_act_guest_serversオペランドの指定値

pd_ha_max_act_guest_serversオペランドを省略した場合：0

P：ユニット内の代替BESの数（1：1スタンバイレス型系切り替え機能使用時の代替BES）

Q：システム共通定義のpdbufferオペランドの-oオプション指定あり：1

システム共通定義のpdbufferオペランドの-oオプション指定なし：0

R：システム共通定義のpdbufferオペランドの-rオプション及び-bオプションに指定したRDエリアの総数

S：システム共通定義のpdbufferオペランドの-iオプションに指定したインデクスを格納しているRDエリアの総数

T：システム共通定義のpd_buf_modifyオペランドにYを指定した場合

システム共通定義のpd_max_add_dbbuff_noオペランドを指定したとき：f＋J

システム共通定義のpd_max_add_dbbuff_noオペランドを省略したとき：1000

システム共通定義のpd_buf_modifyオペランドにNを指定した場合：f

注※1　64ビットモードの場合は3456です。

注※2　64ビットモードの場合は688です。

注※3　影響分散スタンバイレス型系切り替え機能を使用する場合は，加算しないでください。

17.4　監査証跡ファイルの容量の見積もり

監査証跡ファイル用のHiRDBファイルシステムの容量は，次に示す計算式で求めます。

計算式

監査証跡ファイル用のHiRDBファイルシステムの容量（単位：メガバイト）＝ａ＋19

ａ：最も多い場合の監査証跡のデータ量（単位：メガバイト）

↑（Σ｛ｂ×ｃ｝）÷（1024×1024）↑

Σは監査証跡を出力する監査対象イベントごとの合計を意味します。なお，監査証跡ファイルの入出力エラーが発生した場合や，pdaudswapコマンドで監査証跡ファイルのスワップを実行した場合は，監査証跡ファイルの容量が一杯になる前にスワップします。この場合，監査証跡表へのデータ登録が終了するまで，その空き容量は使用できません。そのため，あらかじめａの値を2倍にしておくことを推奨します。

ｂ：監査証跡のレコードサイズ（単位：バイト）

監査証跡のレコードサイズは，次に示す計算式で求めます。

464＋ｄ＋ｅ＋ｆ＋ｇ＋ｈ＋ｉ

ｃ：監査証跡のレコード数

監査証跡イベントの種類ごとの記録レコード数です。

ｄ：監査証跡のレコードに出力するSQL文の長さ（単位：バイト）

pd_aud_sql_source_sizeの値が0，又は指定していない場合：0

レコード項目にSQL文がない場合：0

レコード項目にSQL文があるが，SQL文がNULL値の場合：0

上記以外の場合：

↑Min（pd_aud_sql_source_sizeの値，SQL文の平均長）÷4↑×4＋8

ｅ：監査証跡のレコードに出力するSQLデータの長さ（単位：バイト）

pd_aud_sql_data_sizeの値が0，又は指定していない場合：0

レコード項目にSQLデータがない場合：0

レコード項目にSQLデータがあるが，SQLデータがNULL値の場合：0

上記以外の場合：

↑Min（pd_aud_sql_data_sizeの値，SQLデータの平均長）÷4↑×4＋8

ｆ，ｇ，ｈ：監査証跡のレコードに出力するユーザ付加情報1，2，3の長さ（単位：バイト）

レコード項目にユーザ付加情報がない場合，又はユーザ付加情報がNULL値の場合：0

上記以外の場合：

↑ユーザ付加情報の平均長÷4↑×4＋8

ｉ：監査証跡のレコードに出力する関連製品付加情報の長さ（単位：バイト）

レコード項目に関連製品付加情報がない場合，又は関連製品付加情報がNULL値の場合※1：0

上記以外の場合：

↑関連製品付加情報の平均長※2÷4↑×4＋8

注※1

関連製品付加情報がNULL値になる場合の条件については，関連製品のマニュアルを参照してください。

注※2

関連製品付加情報の平均長については，関連製品のマニュアルを参照してください。マニュアルに該当する記載がない場合は，関連製品付加情報の最大長で計算してください。

監査証跡のレコード項目，及び監査証跡ファイルに出力される情報については，マニュアル「HiRDB システム運用ガイド」を参照してください。

18　作業表用ファイルの容量の見積もり

この章では，作業表用ファイルの容量の見積もり方法について説明します。

18.1　作業表用ファイルの概要

ここでは，SQL文を実行するときに必要とする一時的な情報を格納する作業表用ファイルについて説明します。

18.1.1　作業表用ファイルの作成契機

作業表用ファイルとは，次に示す操作をするときに発生する一時的な情報を格納するファイルです。

SQL文の実行※

インデクスの一括作成

インデクスの再作成

インデクスの再編成

リバランスユティリティの実行

ディクショナリ表のメンテナンス

注※

作業表用ファイルは，SELECT文で複数の表を結合して検索する場合やCREATE INDEX実行時など，特定のSQL実行時に使用されます。作業表用ファイルを必要とするSQLを次に示します。

ただし，次に該当しないSQLでも，アクセスパスによっては作業表用ファイルを必要とする場合があります。作業表用ファイルの要否については，アクセスパスのWork Tableの項目を確認してください。また，SQLにLIMIT句を指定しアクセスパス中にMEM(SUBSORT)の表示がある場合も，作業表用ファイルを必要とすることがあります。アクセスパスの出力形式の詳細については，マニュアル「HiRDB コマンドリファレンス」の「アクセスパス表示ユティリティ（pdvwopt）」の「出力形式」を参照してください。

UNION [ALL]句又はEXCEPT [ALL]句を指定して検索する場合

DROP SCHEMA

DROP TABLE

DROP INDEX

REVOKEでアクセス権限を取り消す場合

CREATE INDEX

ASSIGN LIST文で実表からリストを作成する場合

SELECT文で次に示す指定をする場合

複数の表を結合して検索するとき

インデクスを定義していない列に対してORDER BY句を指定するとき

横分割表に対してORDER BY句を指定するとき

選択式中に集合関数を含む値式を指定しているとき（HiRDB/パラレルサーバの場合にだけ該当します）

選択式中にウィンドウ関数COUNT(*) OVER()を含む値式を指定しているとき

GROUP BY句を指定するとき

DISTINCT句を指定するとき

インデクスを定義した複数の列に検索条件を指定するとき

繰返し列インデクスを定義した列に検索条件を指定するとき

SQL最適化オプションに「プラグイン提供関数からの一括取得機能」を指定し，探索条件にプラグインインデクスを使用するプラグイン提供関数を指定して検索するとき

FOR UPDATE句を指定するか又はこのカーソルを使用した更新があり，インデクスを定義した列に検索条件を指定するとき

FOR READ ONLY句を指定するとき

限定述語の副問合せを指定するとき

IN述語の副問合せを指定するとき

ビュー表の検索，又はWITH句を指定した検索で内部導出表を作成するとき

INSERT文の挿入元の問合せ本体に，次に示す指定をする場合

外への参照がある副問合せに更新表を指定するとき

挿入元の問合せ式本体の主問合せに更新表を指定するとき

UPDATE文に次に示す指定をする場合

探索条件中又は更新値中に，外への参照がある副問合せを指定し，その副問合せ中に更新表を指定するとき

探索条件中に限定述語の副問合せを指定するとき

探索条件中にIN述語の副問合せを指定するとき

インデクスを定義した列を更新対象及び探索条件に指定し，かつそのインデクスを使用するとき

DELETE文に次に示す指定をする場合

探索条件中の外への参照がある副問合せに，更新表を指定するとき

探索条件中に限定述語の副問合せを指定するとき

探索条件中にIN述語の副問合せを指定するとき

インデクスを定義した列を探索条件に指定し，かつそのインデクスを使用するとき

ALTER TABLE ADD PRIMARY KEY

ALTER TABLE DROP PRIMARY KEY

18.1.2　作業表用ファイルの格納先

作業表用ファイルは，HiRDBがHiRDBファイルシステム領域に作成します。HiRDB管理者は次に示すことをしてください。

pdfmkfsコマンドで，作業表用ファイルを作成するHiRDBファイルシステム領域を初期設定します。

HiRDBシステム定義のpdworkオペランドで，上記のHiRDBファイルシステム領域の名称を指定します。

以降，pdfmkfsコマンドのオプションに指定する値の見積もり方法について説明します。pdfmkfsコマンドのオプションと作業表用ファイルの内容の関係を次の表に示します。

表18‒1　pdfmkfsコマンドのオプションと作業表用ファイルの内容の関係

オプション | 内　容
-n | 作業表用ファイルを作成するHiRDBファイルシステム領域のサイズ
-l | HiRDBファイルシステム領域に作成するHiRDBファイル（作業表用ファイル）の最大数
-e | HiRDBファイルシステム領域の最大増分回数
-a | HiRDBファイルシステム領域を自動的に拡張するかどうか

18.2　HiRDBファイルシステム領域サイズの見積もり（pdfmkfs -nコマンド）

作業表用ファイルを作成するHiRDBファイルシステム領域のサイズは，pdfmkfsコマンドの-nオプションで設定します。

HiRDBファイルシステム領域のサイズは，次に示す計算式で求めます。

計算式

HiRDBファイルシステム領域のサイズ（単位：バイト）＝A＋B

A：

SQL文が使用する作業表用ファイルの容量です。求め方については，「SQL文が使用する作業表用ファイルの容量」を参照してください。

B：

データベース作成ユティリティ（pdload），データベース再編成ユティリティ（pdrorg）でC以外の場合，及びリバランスユティリティ（pdrbal）が使用する作業表用ファイルの容量です。求め方については，「ユティリティが使用する作業表用ファイルの容量」を参照してください。

C：

データベース再編成ユティリティ（pdrorg）でディクショナリ表のメンテナンスを実行する場合に，データベース再編成ユティリティが使用する作業表用ファイルの容量です。求め方については，「ディクショナリ表のメンテナンスが使用する作業表用ファイルの容量」を参照してください。

なお，作業表用ファイルを使用するSQL文と作業表用ファイルを使用するユティリティの操作を同時に実行しない場合は，A又はBのどちらか大きい値をHiRDBファイルシステム領域のサイズとしてください。

注意事項

ここで求めたHiRDBファイルシステム領域のサイズが大き過ぎて，一つのHiRDBファイルシステム領域に収まらない場合は，複数のHiRDBファイルシステム領域をpdfmkfsコマンドで初期設定し，HiRDBシステム定義のpdworkオペランドに指定してください。このときに注意することを次に示します。

各HiRDBファイルシステム領域のサイズを同じにしてください。

一つのHiRDBファイルシステム領域のサイズは，一つの作業表（列情報格納用）の容量より大きくしてください。

HiRDBファイルシステム領域を分割し過ぎると，未使用領域が複数のHiRDBファイルシステム領域に分割されます。したがって，領域すべてが有効活用されないため，容量が不足することがあります。

1作業表用ファイルは複数のHiRDBファイルシステム領域に分割できません。

18.2.1　SQL文が使用する作業表用ファイルの容量

SQL文が使用する作業表用ファイルの容量は次に示す計算式で求めます。

計算式

SQL文が使用する作業表用ファイルの容量（単位：バイト）＝MAX（ａ，ｂ）×ｃ

a：1SQL文が使用する作業表用ファイルの容量の最大値

SQL文ごとに作業表用ファイルの容量を計算します。その中で最も大きい値をaに代入します。「1SQL文が使用する作業表用ファイルの容量の求め方」を参照して求めてください。

ｂ：ASSIGN LIST文が使用する作業表用ファイルの容量の最大値

ASSIGN LIST文ごとに作業表用ファイルの容量を計算します。その中で最も大きい値をｂに代入します。「ASSIGN LIST文が使用する作業表用ファイルの容量の求め方」を参照して求めてください。

ｃ：pd_max_usersオペランドの値

ただし，マルチフロントエンドサーバを使用している場合のバックエンドサーバでは，pd_max_bes_processオペランドの値になります。

(1)　1SQL文が使用する作業表用ファイルの容量の求め方

1SQL文が使用する作業表用ファイルの容量は，次に示す計算式で求めます。

計算式

1SQL文が使用する作業表用ファイルの容量（単位：バイト）＝ａ×ｂ＋ｃ×ｄ

a：列情報作業表の容量

b：列情報作業表の最大数

c：位置情報作業表の容量

d：位置情報作業表の最大数

(a)　列情報作業表の容量の求め方

列情報作業表の容量は次に示す計算式で求めます。

計算式

列情報作業表の容量（単位：バイト）
　　　　　　　　　　＝↑a÷MIN｛↓（b−48）÷c↓ ，255 ｝↑×b×2

a：列情報作業表の行数（表「列情報作業表の行数の求め方」から求めてください）

b：作業表ページ長（計算式1から求めてください）

c：作業表の行長（計算式2から求めてください）

計算式1

pdworkに指定したHiRDBファイルシステム領域のセクタ長が4096の場合※1

作業表ページ長※2＝↑（作業表の行長＋48）÷4096↑×4096

pdworkに指定したHiRDBファイルシステム領域のセクタ長が4096ではない場合

作業表ページ長※2＝MAX｛↑（作業表の行長＋48）÷2048↑×2048 ，4096 ｝

注※1　複数指定した場合，1つでもセクタ長が4096の領域がある場合は，

「セクタ長が4096の場合」の計算式を使用してください。

注※2　作業表ページ長は，32,768バイト以下でなければなりません。

計算式2

　　　　　　　　 n
作業表の行長※＝ Σ Ai＋2×n＋6
　　　　　　　　i=1

Ai：作業表の各列のデータ長（表「作業表の各列のデータ長及び列数の求め方」から求めてください）

n：作業表の列数（表「作業表の各列のデータ長及び列数の求め方」から求めてください）

注※　作業表の行長は，32,720バイト以下でなければなりません。

なお，LIMIT句指定時，（オフセット行数＋LIMIT句に指定した行数）の値が32,768以上になる場合は，計算式2で算出した作業表の行長に12を加算してください。ただし，次の場合には12を加算する必要はありません。

検索対象の表にEXモードで排他が掛かっている場合

WITHOUT LOCKを指定した場合

グループ分け高速化機能を指定した場合

複数の表を結合する場合

表18‒2　列情報作業表の行数の求め方

SQL文 | 列情報作業表の行数
SELECT文 | 検索する個々の表から探索する行数の合計です。ただし，複数の表を結合していて結合結果行数の方が多い場合は，その行数となります。
CREATE INDEX ALTER TABLE ADD PRIMARY KEY | 表に格納している行数です。ただし，繰返し列に対するインデクスの場合は，インデクス構成列のうち一つの繰返し列の要素の総数となります。

表18‒3　作業表の各列のデータ長及び列数の求め方

SQL文 | n | Ai

SELECT文

選択式に指定した列数＋GROUP BY句に指定した列数※＋ORDER BY句に指定した列数※＋HAVING句に指定した列数※＋FOR UPDATE句を指定した場合※は1

ただし，選択式にROWを指定している場合は表の全列数

左記の列ごとの実際の長さ

ただし，長大データ（BLOB），定義長が256バイト以上の文字データ（各国・混在文字データも含む），バイナリデータのうち，下記に属さない列又は位置情報列の場合は12

結合条件中に指定する列（結合列）

DISTINCT句指定の選択式

限定述語の副問合せ選択式中に指定する列

IN述語の副問合せ選択式中に指定する列

UNION [ALL] 又はEXCEPT [ALL] によって，集合演算対象となっている問合せ指定中の選択式

ORDER BY句に指定した列

CREATE INDEX ALTER TABLE ADD PRIMARY KEY | 1（インデクス情報列）＋1（位置情報列） | インデクス情報列はインデクス構成列のデータ長の合計値 位置情報列は12

注　各列のデータ長については，次に示す表を参照してください。

表「データ長一覧」

表「可変長文字列型のデータ長一覧（抽象データ型及び繰返し列を除く）」

表「可変長文字列型のデータ長一覧（抽象データ型の場合）」

表「可変長文字列型のデータ長一覧（繰返し列の場合）」

注※

選択式に指定した列と同一の列の場合は，新たに加算する必要はありません。

(b)　列情報作業表の最大数の求め方

列情報作業表の最大数の求め方を次の表に示します。

表18‒4　列情報作業表の最大数の求め方

SQL文 | 列情報作業表の最大数※1

SELECT文

1. 〜10. の指定がない場合は，0になります。

1. 〜10. の指定がある場合は，対応する作業表増加数をすべて加算した値になります。

複数の表を結合して検索する場合

作業表増加数（HiRDB/シングルサーバの場合）＝結合表数＋1

作業表増加数（HiRDB/パラレルサーバの場合）＝結合表数×2

ただし，結合キーとなる列にインデクスがあり，制限条件がある場合は0

ORDER BY句を指定する場合

作業表増加数＝2

ORDER BY句に指定した列をすべて含むインデクスを検索に使用する場合＝0

GROUP BY句を指定しないで，選択式中に集合関数を含む値式を指定する場合※2

作業表増加数＝1

GROUP BY句を指定する場合

作業表増加数＝GROUP BY句指定数×2

DISTINCT句を指定する場合

作業表増加数＝DISTINCT句指定数×2

UNION［ALL］句又はEXCEPT［ALL］句を指定する場合

作業表増加数（HiRDB/シングルサーバの場合）＝UNION［ALL］句又はEXCEPT［ALL］句指定数＋2

作業表増加数（HiRDB/パラレルサーバの場合）＝（UNION［ALL］句又はEXCEPT［ALL］句指定数＋1）×2

FOR UPDATE句を指定するか又はこのカーソルを使用した更新があり，インデクスを定義した列に検索条件を指定する場合※2

作業表増加数＝2

FOR READ ONLY句を指定する場合

作業表増加数＝1

副問合せ（限定述語）を指定する場合

増加作業表数＝副問合せ指定数＋（インデクスを定義した列に対する＝ANYの限定述語の数）＋（インデクスを定義した列に対するIN述語の副問合せ指定数）＋（インデクスを定義した列に対する＝SOMEの限定述語の数）

選択式にウィンドウ関数COUNT(*) OVER()を指定する場合

増加作業表数＝選択式にウィンドウ関数を指定した問合せ指定数

CREATE INDEX ALTER TABLE ADD PRIMARY KEY | 2

注※1　HiRDBが見積もるアクセスコストによっては作業表を作成しない場合があります。

注※2　HiRDB/パラレルサーバの場合にだけ該当します。

(c)　位置情報作業表の容量の求め方

位置情報作業表の容量は次に示す計算式で求めます。

計算式

位置情報作業表の容量（単位：バイト）＝↑a÷184※↑×4096×2

注※　探索条件にインデクス型プラグイン専用関数を指定する場合は155

a：位置情報作業表の行数

位置情報作業表の行数の求め方を次に示します。

SQL文 | 位置情報作業表の行数の求め方
SELECT文 UPDATE文 DELETE文 | 探索時の条件中にインデクスを定義した列を含む述語が一つの場合，述語が真となる行数になります。二つ以上の場合，次の行数の合計値になります。 述語をOR論理演算している場合，少なくとも一つの述語が真となる行数の合計 述語をAND論理演算している場合，述語のうち真となる行数が多い方の行数として合算した行数

(d)　位置情報作業表の最大数の求め方

位置情報作業表の最大数の求め方を次の表に示します。

表18‒5　位置情報作業表の最大数の求め方

SQL文 | 位置情報作業表の最大数

SELECT文

インデクスを定義した複数の列に検索条件を指定する場合

FOR UPDATE句を指定するか又はこのカーソルを使用した更新があり，インデクスを定義した列に検索条件を指定する場合※

繰返し列インデクスを定義した列に検索条件を指定する場合

SQL最適化オプションに「プラグイン提供関数からの一括取得機能」を指定し，探索条件にプラグインインデクスを使用するプラグイン提供関数を指定して検索する場合

1〜4で，探索時に使用するインデクス数＋1になります。

UPDATE文 DELETE文 | 探索条件中にインデクスを定義した列がある場合，探索時に使用するインデクス数＋1になります。

注※　HiRDB/シングルサーバの場合にだけ該当します。

(2)　ASSIGN LIST文が使用する作業表用ファイルの容量の求め方

ASSIGN LIST文が使用する作業表用ファイルの容量は，次に示す計算式で求めます。

計算式

ASSIGN LIST文が使用する作業表用ファイルの容量（単位：バイト）=
 n
Σ（Bi×2）
i=1

n：ASSIGN LIST文の探索条件中の述語の数

Bi：探索条件中のi番目の述語を処理する作業表の容量。次に示す計算式で求めます。

Bi＝↑リストの基になる表でi番目の述語が真となる行数※÷504↑×4096

　　　×1.5（単位：バイト）

注※　述語が繰返し列に対する条件の場合，真となる要素の総数となります。

18.2.2　ユティリティが使用する作業表用ファイルの容量

インデクスの一括作成，インデクスの再作成，インデクスの再編成，又はリバランスユティリティでデータの再配置をする場合は，次に示す計算式の分の作業表用ファイルが必要になります。

計算式

ユティリティが使用する作業表用ファイルの容量（単位：バイト）＝｛（A＋B）×2×D ｝÷C

A：インデクス作成時に必要な作業表の行数1

B：インデクス作成時に必要な作業表の行数2

C：作業表ページ内の行数

D：作業表ページ長

注

1回のユティリティで複数のインデクスの一括作成又は再作成をする場合は，インデクスのキー長が最も長いインデクスについて求めてください。

インデクスの一括作成又は再作成を同時に実行する場合は，それぞれで必要な作業表用ファイルの容量を求めて加算してください。

複数のユティリティを同時実行する場合は，各ユティリティが使用する作業表用ファイルの容量を計算して合計してください。

(1)　インデクス作成時に必要な作業表の行数1の求め方

インデクス作成時に必要な作業表の行数1は，次に示す計算式で求めます。

計算式

作業表の行数1＝↑c÷｛↓↑a×（100−b）×0.01↑÷（d＋22）↓｝↑

a：インデクスを格納するユーザ用RDエリアのページサイズ

b：CREATE INDEXのPCTFREEオペランドで指定する未使用領域の比率

c：データ件数

繰返し列に対するインデクスの場合は，インデクス構成列のうち一つの繰返し列の各行の要素数の合計

d：インデクスのキー長

インデクスのキー長については表「インデクスのキー長一覧」を参照してください。なお，データベースに格納されるキー長は４バイトバウンダリされるため，↑キー長÷4↑×4となります。

複数インデクスのキー長は，表「インデクスのキー長一覧」を基に全構成列のキー長を加算してください。

(2)　インデクス作成時に必要な作業表の行数2の求め方

インデクス作成時に必要な作業表の行数2は，次に示す計算式で求めます。

計算式

作業表の行数2＝↑c÷｛↓↑a×（100−b）×0.01↑÷（d＋14）↓｝↑

a：インデクスを格納するユーザ用RDエリアのページサイズ

b：CREATE INDEXのPCTFREEオペランドで指定する未使用領域の比率

c：インデクス作成時に必要な作業表の行数1

（1）で求めた値を代入してください。

d：インデクスのキー長

インデクスのキー長については表「インデクスのキー長一覧」を参照してください。なお，データベースに格納されるキー長は４バイトバウンダリされるため，↑キー長÷4↑×4となります。

複数インデクスのキー長は，表「インデクスのキー長一覧」を基に全構成列のキー長を加算してください。

(3)　作業表ページ内の行数の求め方

作業表ページ内の行数は，次に示す計算式で求めます。

計算式

作業表ページ内の行数＝MIN｛↓（b−48）÷a↓ ，255 ｝

a：作業表の行長（インデクスのキー長＋18）

インデクスのキー長については表「インデクスのキー長一覧」を参照してください。キー長は↑キー長÷4↑×4となります。

複数インデクスのキー長は，表「インデクスのキー長一覧」を基に全構成列のキー長を加算してください。

b：作業表ページ長

（4）で求めてください。

(4)　作業表ページ長の求め方

作業表ページ長は，次に示す計算式で求めます。

計算式

作業表ページ長※＝MAX｛↑（作業表の行長＋48）÷2048↑×2048 ，4096 ｝

注※　作業表ページ長は，32,768バイト以下でなければなりません。

a：作業表の行長（インデクスのキー長＋18）

インデクスのキー長については表「インデクスのキー長一覧」を参照してください。キー長は↑キー長÷4↑×4となります。

複数インデクスのキー長は，表「インデクスのキー長一覧」を基に全構成列のキー長を加算してください。

18.2.3　ディクショナリ表のメンテナンスが使用する作業表用ファイルの容量

データベース再編成ユティリティ（pdrorg）でディクショナリ表のメンテナンスを行う場合は，次に示す計算式の分の作業表用ファイルが必要になります。

計算式

ディクショナリ表のメンテナンスが使用する作業表用ファイルの容量（単位：バイト）
＝↑row_num÷134↑×16384

変数の説明

row_num：SQL_RDAREAS表の行数

18.3　最大ファイル数の見積もり（pdfmkfs -lコマンド）

18.3.1　最大ファイル数の計算方法

HiRDBファイルシステム領域に作成する作業表用ファイルの最大ファイル数は，pdfmkfsコマンドの-lオプションで設定します。

HiRDBファイルシステム領域に作成する作業表用ファイルの最大ファイル数は，次に示す計算式で求めます。

計算式

最大ファイル数 ＝ MAX（ａ，ｂ）×ｃ＋20＋2※

a：1SQL文が使用する作業表用ファイルの数

SQL文ごとに作業表用ファイルの数を計算します。その中で最も大きい値をaに代入します。「1SQL文が使用する作業表用ファイルの数の求め方」を参照して求めてください。

ｂ：ASSIGN LIST文が使用する作業表用ファイルの数

ASSIGN LIST文ごとに作業表用ファイルの数を計算します。その中で最も大きい値をｂに代入します。「ASSIGN LIST文が使用する作業表用ファイルの数の求め方」を参照して求めてください。

ｃ：pd_max_usersオペランドの値

ただし，マルチフロントエンドサーバを使用している場合のバックエンドサーバでは，pd_max_bes_processオペランドの値になります。

注※

作業表用ファイルを使用するSQL文と作業表用ファイルを使用するユティリティ（データベース作成ユティリティ又はデータベース再編成ユティリティ）を同時に実行する場合に加算します。

(1)　1SQL文が使用する作業表用ファイルの数の求め方

1SQL文が使用する作業表用ファイルの数は，次に示す計算式で求めます。

計算式

1SQL文が使用する作業表用ファイルの数＝列情報作業表の最大数＋位置情報作業表の最大数

列情報作業表の最大数，及び位置情報作業表の最大数については，「SQL文が使用する作業表用ファイルの容量」を参照してください。

(2)　ASSIGN LIST文が使用する作業表用ファイルの数の求め方

ASSIGN LIST文が使用する作業表用ファイルの数は，次に示す計算式で求めます。

計算式

ASSIGN LIST文が使用する作業表用ファイルの数＝ASSIGN LIST文の探索条件中の述語の数×2

(3)　注意

作業表用ファイルを作成するHiRDBファイルシステム領域を複数設定する場合は，次に示すことに注意してください。

ここで求めた値が4096より大きい場合は，-lオプションには4096を指定してください。

18.4　最大増分回数の見積もり（pdfmkfs -eコマンド）

HiRDBファイルシステム領域に作成する作業表用ファイルの最大増分回数は，pdfmkfsコマンドの-eオプションで設定します。

HiRDBファイルシステム領域の最大増分回数は，次に示す計算式で求めます。

計算式

最大増分回数＝MIN（最大ファイル数×23，60000）

注1

最大増分回数が見積もり値よりも少ない場合，HiRDBファイルシステム領域に空きがあっても領域確保ができなくなることがあります。

注2

最大ファイル数については，「最大ファイル数の見積もり（pdfmkfs -lコマンド）」の説明を基に算出した値を代入してください。

19　ユティリティ実行時の容量の見積もり

この章では，ユティリティ実行時のファイル容量及びメモリ所要量の見積もり方法について説明します。

19.1　ユティリティ実行時のファイルの容量の見積もり

19.1.1　データベース作成ユティリティ（pdload）実行時のファイルの容量

データベース作成ユティリティ（pdload）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：バイト）
入力データファイル | h×b

インデクス情報ファイル

B-treeインデクスの場合

（d＋y）×（b＋e）＋512

プラグインインデクスの場合

（12＋q）×p＋1024

この計算式は，1インデクス当たりの容量計算式です。インデクスが複数ある場合は，それぞれのインデクスに対して計算してください。

エラー情報ファイル | k×f＋s×200＋m
エラー情報ファイル作成用一時ファイル | 次に示す条件の場合は，表格納RDエリアがあるサーバごとに，キー重複エラー数×8＋プラグイン関数が検知したエラー件数×200の容量がワークファイル出力先ディレクトリに必要です。ワークファイル出力先ディレクトリについては，「ワークファイル出力先ディレクトリの作成」を参照してください。 HiRDB/パラレルサーバでは，入力ファイルがあるサーバと表格納RDエリアがあるサーバが異なる場合
LOB入力ファイル | b Σ（LOBデータ長＋4）i i=1

LOB中間ファイル

b

Σ｛

i=1

c

Σ（LOBファイル名称長ij＋36）＋24 ｝

j=1

＋1024＋c×84

エラーデータファイル | MIN（f，g）×h
処理結果ファイル | 1500＋表格納サーバ数×500
ワークファイル※ | ［4＋2×R＋2×r＋4×I×R＋｛b÷（-mオプションに指定した経過メッセージ出力間隔の値）｝］×200

ソート用ワークファイル

条件1の場合

インデクス情報ファイルの容量＋4×（b＋e）

条件2の場合

｛インデクス情報ファイルの容量＋4×（b＋e）｝×2

条件1

1024キロバイト≧Eのとき

条件2

1024キロバイト＜Eのとき

E：バッファサイズ

「ソート用ワークファイル容量の計算で使用するバッファサイズ」で求めたバッファサイズ

a：入力行数×LOB列数

b：入力行数（繰返し列の場合は入力行数×要素数）

c：LOB列数

d：インデクスのキー長

表「インデクスのキー長一覧」を参照してください。ただし，可変長データの場合は単一列でも複数列として扱い，定義長の最大値で計算してください。

e：既存の行数（繰返し列の場合は既存行数×要素数）

f：エラーデータ件数

g：source文のerrdataオペランドで指定する出力行数

h：平均ソースレコード長

k：抽象データ型の列がある場合は300

ない場合は120

m：DAT形式，又はpdrorgで出力したバイナリ形式のファイルの場合は0

そのほかの場合は（入力ファイルの1行のレコード長×4）

p：インデクス格納RDエリアを初期化した場合は（b＋e）

そのほかの場合はb

q：次に示す値

LOB用RDエリアに格納された抽象データ型の場合は27

定義長255バイト以下の抽象データ型の場合は（キー長＋2）

定義長256バイト以上の抽象データ型の場合は2

代表的な抽象データ型の値を次に示します。

SGMLTEXT型の場合は27

FREEWORD，GEOMETRY，及びXML型の場合は2

r：LOB格納RDエリア数

s：サーバ数

y：キー構成列がすべて固定長の場合は10

キー構成列に可変長を含む場合は12

I：インデクス数

R：表，又はインデクスの分割RDエリア数

注

インデクス情報ファイル及びソート用ワークファイルの容量を算出するとき，インデクス構成列が繰返し列の場合はｂ及びｅは行数ではなく，行数×要素数となります。

注※

-mオプションでインフォメーションメッセージ出力抑止レベルにlvl2を指定した場合に出力されます。

19.1.2　データベース再編成ユティリティ（pdrorg）実行時のファイルの容量

データベース再編成ユティリティ（pdrorg）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：バイト）
アンロードデータファイル （オプション指定なし） | n Σ（Pi ＋M）＋Li※６＋1200＋A＋B＋c×96＋D＋I＋F i=1

アンロードデータファイル

（-Wオプション指定時）

DAT形式，又は拡張DAT形式の場合

｛

c

Σ（列の最大文字変換長i ※１＋1）×C＋M

i=1

｝×n

バイナリ形式でFIX表の場合

｛

c

Σ（列データ長i ※２）＋M

i=1

｝×n

バイナリ形式で非FIX表の場合

｛

c

Σ（列データ長i ※２＋G）＋M＋4×（c＋1）

i=1

｝×n

固定長文字形式の場合

｛

c

Σ（列の最大文字変換長i ※３＋crlf）×C＋M

i=1

｝×n

アンロードデータファイル

（-jオプション指定時又はスキーマ単位の再編成時）※４

n

Σ（Pi ＋M）＋Li※６＋

i=1

n

Σ｛

i=1

m

Σ（Oij＋44）

j=1

　　｝＋1200＋A＋B＋c×96＋D＋I＋F

LOBデータのアンロードデータファイル

n

Σ｛

i=1

m

Σ（Oij＋44）

j=1

　　｝＋1200＋A＋B＋c×96＋D＋I＋F

インデクス情報ファイル

B-treeインデクスの場合

（K＋ｐ）×ｎ＋512

プラグインインデクスの場合

（12＋X）×ｎ＋1024

この計算式は，1インデクス当たりの容量計算式です。インデクスが複数ある場合は，それぞれのインデクスに対して計算してください。

処理結果ファイル | 1700＋表格納サーバ数×500＋スキーマ内表数×1000＋スキーマ内総格納RDエリア数×100
ワークファイル※５ | ［8＋2×S＋2×｛n÷（-mオプションに指定した経過メッセージ出力間隔の値）｝＋3×R＋4×J×R］×200

ソート用ワークファイル

条件1の場合

インデクス情報ファイルの容量＋4×ｎ

条件2の場合

｛インデクス情報ファイルの容量＋4×ｎ｝×2

条件1

1024キロバイト≧Eのとき

条件2

1024キロバイト＜Eのとき

E：バッファサイズ

「ソート用ワークファイル容量の計算で使用するバッファサイズ」で求めたバッファサイズ

Ａ：キーレンジ分割の場合：48＋分割条件数×284

ハッシュ分割の場合：40＋ａ×60

マトリクス分割（境界値指定のキーレンジ分割とハッシュ分割の組み合わせ）の場合：

　　48＋（分割条件数×284）＋（40＋a×60）

Ｂ：ｎ×36（FIX表の場合）又は（44＋ｃ×4）×ｎ（非FIX表の場合）

Ｃ：アンロードデータファイルの出力文字コードがHiRDBの既定文字コード以外の場合：2

上記以外の場合：1

Ｄ：16＋（LOB列数×ａ×80）

DはLOB列がある場合に加算します。

Ｆ：次の値を代入してください。

d
Σ｛（列iのプラグインが提供する抽象データ型の属性数×84）＋
i=1　　（列iのプラグインが提供する抽象データ型のLOB属性数×ａ×72）｝

＋64＋
d
Σ（84＋逆生成関数数i×60）
i=1

Ｇ：列Iに対する逆生成関数の返却値がBLOBの属性数×４

Ｉ：136＋インデクス分割数×60

インデクス引き上げ時に加算します。

Ｊ：インデクス数

Ｋ：インデクスのキー長

表「インデクスのキー長一覧」を参照してください。ただし，可変長データの場合は単一列でも複数列として扱い，定義長の最大値で計算してください。

Ｌｉ：行の実長

行の実長は，概算値又は詳細値で見積もってください。なお，BINARY型で圧縮指定ありの場合は，詳細値で見積もると計算が複雑になるため，概算値で見積もることをお勧めします。

概算値の見積もり：

データベースに格納されているデータから，次の計算式で行の実長の全行の合計概算値（単位：バイト）を求めます。

表格納RDエリアの使用中ページ数×表格納RDエリアのページ長

表格納RDエリアの使用中ページ数，及びページ長については，pddbstのRDエリア単位の状態解析（論理的解析），又は表単位の状態解析の実行結果から取得できます。

詳細値の見積もり：

各列のデータから，次の値を使用して行の実長を求めます。

列のデータ型 | 実長（単位：バイト）
BLOB | 16
プラグインが提供する抽象データ型 | 2

BINARY※

pdrorg -k rorgで圧縮指定あり，かつUOCを使用しない場合

定義長＋8×MAX（

　SQLのUPDATE文で連結演算を使用した回数，

　↑定義長÷圧縮分割サイズ↑）

上記以外の場合

BINARY型の列の定義長

上記以外 | 各列の実長

注※

行の実長の最大値を算出するため，BINARY型のデータが定義長のデータで，圧縮率が0%と仮定しています。

Ｍ：文字集合が指定された文字列型の列の合計データ長

次の値になります。

　 k
（Σ列データ長i）
　i=1

Ｏij：LOBデータ長

Ｐｉ：プラグインが提供する抽象データ型のデータ長

Ｒ：表又はインデクスの分割RDエリア数

Ｓ：表格納サーバ数

Ｘ：次に示す値

LOB用RDエリアに格納された抽象データ型の場合は27

定義長255バイト以下の抽象データ型の場合は（キー長＋2）

定義長256バイト以上の抽象データ型の場合は2

代表的な抽象データ型の値を次に示します。

SGMLTEXT型の場合は27

FREEWORD，GEOMETRY，及びXML型の場合は2

ａ：分割RDエリア数

ｃ：列定義数

ｄ：プラグインが提供する抽象データ型が定義された列数

ｋ：文字集合が指定された文字列型の列の数

ｍ：LOB列数

ｎ：行数（繰返し列の場合は行数×要素数）

ｐ：キー構成列がすべて固定長の場合は10，キー構成列に可変長を含む場合は12

crlf：-Wオプションにcr又はcrlfを指定した場合に加算する改行文字の長さ

次の表から改行文字の長さを求めます。

-Wオプション指定値 | 加算値
-W dat又は-W extdat | ,cr | 1
,crlf | 2
上記の指定なし | 1
-W fixtext | ,cr | 1
,crlf | 2
上記の指定なし | 0

注

インデクス情報ファイル及びソート用ワークファイルの容量を算出するとき，インデクス構成列が繰返し列の場合は「リロードする行数」及びｎは行数ではなく，行数×要素数となります。

注※1

DAT形式（-W dat）又は拡張DAT形式（-W extdat）の場合の列の最大文字変換長を次の表に示します。

表19‒1　列の最大文字変換長（DAT形式又は拡張DAT形式の場合）

データ型 | 最大文字変換長（バイト）
数データ | INTEGER | 11
SMALLINT | 11
DECIMAL | 40
FLOAT | 23
SMALLFLT | 23
文字データ※１ | CHARACTER | 定義長＋2※２
VARCHAR | 実長＋2※２
混在文字データ※１ | MCHAR | 定義長＋2※２
MVARCHAR | 実長＋2※２
各国文字データ※１ | NCHAR | 定義長×2＋2※２
NVARCHAR | 実長＋2※２
日付データ | DATE | 10
時刻 | TIME | 8
日間隔データ | INTERVAL YEAR TO DAY | 9
時間隔データ | INTERVAL HOUR TO SECOND | 7
時刻印データ | TIMESTAMP | 19 小数秒けた数が0でなければ，小数秒けた数＋1を加算してください。
バイナリデータ※１ | BINARY | 実長＋2※２

注※１

拡張DAT形式の場合，データ中に「”」があると，「”」の数分，文字変換長が長くなります。

注※２

データの長さに囲み文字数を2バイト加算しています。

ただし，-W dat又は-W extdat指定時，オペランドにsupを指定した場合の列の最大文字変換長は次に示すとおりです。なお，表中の実長とは，後方の連続スペースを圧縮した残りの長さです。スペースを圧縮した場合の出力形式については，マニュアル「HiRDB コマンドリファレンス」のデータベース再編成ユティリティ（pdrorg）の-Wオプションの説明を参照してください。

データ型 | 最大文字変換長（バイト）
文字データ | CHARACTER | 実長＋2
混在文字データ | MCHAR | 実長＋2
各国文字データ | NCHAR | 実長＋2

注※2

データ長については次を参照してください。

表「データ長一覧」

表「可変長文字列型のデータ長一覧（抽象データ型及び繰返し列を除く）」

表「可変長文字列型のデータ長一覧（抽象データ型の場合）」

表「可変長文字列型のデータ長一覧（繰返し列の場合）」

注※3

固定長文字形式（-W fixtext）の場合の列の最大文字変換長を次の表に示します。

表19‒2　列の最大文字変換長（固定長文字形式の場合）

データ型 | 最大文字変換長（バイト）
数データ | INTEGER | 11
SMALLINT | 6
DECIMAL | けた数＋2
FLOAT | 23
SMALLFLT | 23
文字データ | CHARACTER VARCHAR | 定義長 | fixtext_optionにencloseオペランドを指定した場合は出力長に2を加算してください。
混在文字データ | MCHAR MVARCHAR | 定義長
各国文字データ | NCHAR NVARCHAR | 定義長×2
日付データ | DATE | 10
時刻 | TIME | 8
日間隔データ | INTERVAL YEAR TO DAY | 10
時間隔データ | INTERVAL HOUR TO SECOND | 8
時刻印データ | TIMESTAMP | 小数部 0:19　2:22　4:24　6:26
長大データ | BLOB | 0
バイナリデータ | BINARY | 0
抽象データ型 | ADT | 0

注※4

スキーマ単位の再編成（アンロードも含む）をする場合は，表ごとに求めた値を合計してください。

注※5

-mオプションでインフォメーションメッセージ出力抑止レベルにlvl2を指定した場合に出力されます。

注※6

Liを詳細値で見積もる場合は，「（Pi＋M）＋Li」を「（Li＋Pi＋M）」に置き換えてください。

19.1.3　統計解析ユティリティ（pdstedit）実行時のファイルの容量

統計解析ユティリティ（pdstedit）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：バイト）
ワーク用一時ファイル | システムの稼働に関する統計情報 | 4096×取得回数※1×2
サーバごとのシステムの稼働に関する統計情報 | 4096×取得回数※1×サーバ数×2
UAPに関する統計情報 | 872×実行UAP数又は実行トランザクション数×2
SQLに関する統計情報 | 512×実行SQL数×2
SQL静的最適化に関する統計情報 | 512×SQLオブジェクトキャッシュでミスヒットした回数
SQL動的最適化に関する統計情報 | 49624×OPEN又はEXECUTEで発行したSELECT文の数（INSERT SELECTも含む）
SQLオブジェクト実行に関する統計情報 | 512×実行SQL数×サーバ数
SQLオブジェクト転送に関する統計情報 | 256×実行SQL数×サーバ数
SQL文の履歴に関する統計情報 | （1024＋平均的なSQL長）×実行SQL数
CONNECT/DISCONNECTに関する統計情報 | 256×CONNECT及びDISCONNECT回数
グローバルバッファに関する統計情報 | 512×シンクポイント発生回数×2
データベース操作に関するHiRDBファイルの統計情報 | 512×シンクポイント発生回数×2
デファードライト処理に関する統計情報 | 512×デファードライト発生回数×2
インデクスに関する統計情報 （入力：STJ） | 128×シンクポイント発生回数×2
インデクスに関する統計情報 （入力：FJ） | 128×ページスプリット発生回数×2
データベースへの入出力に関する統計情報 | 256×取得時間間隔ごとにアクセスのあったRDエリアを構成するHiRDBファイル数の合計×2
ソート用ワークファイル | 解析対象とした上記のワーク用一時ファイルのソート用作業領域 | 解析対象とした上記のワーク用一時ファイルのファイル容量の最大値
DAT形式ファイル※2 | システムの稼働に関する統計情報 | 3404×取得回数※1
サーバごとのシステムの稼働に関する統計情報 | 3262×取得回数※1×サーバ数
UAPに関する統計情報 | 2167×実行UAP数又は実行トランザクション数
SQLに関する統計情報 | 447×実行SQL数
SQL静的最適化に関する統計情報 | 646×SQLオブジェクトキャッシュでミスヒットした回数
SQL動的最適化に関する統計情報 | 380×OPEN又はEXECUTEで発行したSELECT文の数（INSERT SELECTも含む）
SQLオブジェクト実行に関する統計情報 | 520×実行SQL数×サーバ数
SQLオブジェクト転送に関する統計情報 | 389×実行SQL数×サーバ数
SQL文の履歴に関する統計情報 | （240＋平均的なSQL長）×実行SQL数
CONNECT/DISCONNECTに関する統計情報 | 278×CONNECT及びDISCONNECT回数
グローバルバッファに関する統計情報 | 600×シンクポイント発生回数
データベース操作に関するHiRDBファイルの統計情報 | 356×シンクポイント発生回数
デファードライト処理に関する統計情報 | 330×デファードライト発生回数
データベースへの入出力に関する統計情報（DAT出力） | 196×取得時間間隔ごとにアクセスのあったRDエリアを構成するHiRDBファイル数の合計

注※1

取得回数＝↓（pdstendコマンドの入力時刻−pdstbeginコマンドの入力時刻）÷-mオプションで指定した時間間隔↓

注※2

-bオプションを指定した場合は，容量計算式に3813を加算

(1)　ワーク用一時ファイルの容量の概算値

統計解析ユティリティ実行時に作成されるワーク用一時ファイルの容量の概算値は，次の計算式で求められます。なお，この概算値は，ユティリティの入力情報となる統計ログファイル内のすべての情報を解析した場合の値です。

ワーク用一時ファイルの容量＝統計ログファイルの容量×a（単位：バイト）

a：

統計ログファイルに含まれる統計情報の種別に応じて次の値を代入してください。統計ログファイルに複数の種別の統計情報が含まれる場合は，最も大きい値をaの値とします。

統計情報の種別 | aの値
システムの稼働に関する統計情報 | 3.4
SQL動的最適化に関する統計情報 | 135.6
上記以外 | 2

誤差について

統計ログファイルに複数の種別の統計情報が含まれている場合で，SQL動的最適化に関する統計情報が含まれるとき，その含まれる比率によっては，概算値と実際の値との誤差が大きくなります。この誤差を小さくしたい場合は，SQL動的最適化に関する統計情報の部分だけを別に算出してください。

SQL動的最適化に関する統計情報のワーク用一時ファイルの容量は，次の計算式から求められます。

SQL動的最適化に関する統計情報のワーク用一時ファイルの容量＝SQL動的最適化に関する統計情報の情報数×49624（単位：バイト）

SQL動的最適化に関する統計情報の情報数は，統計解析ユティリティ実行時に出力される入力ログファイルのサマリ情報から取得します。入力ログファイルのサマリ情報については，マニュアル「HiRDB コマンドリファレンス」の「統計解析ユティリティ（pdstedit）」の「統計情報の出力形式」を参照してください。

(2)　ソート用ワークファイルの容量の概算値

統計解析ユティリティ実行時に作成されるソート用ワークファイルの容量の概算値は，次の計算式で求められます。なお，この概算値は，ユティリティの入力情報となる統計ログファイル内のすべての情報を解析した場合の値です。

ソート用ワークファイルの容量＝統計ログファイルの容量×b（単位：バイト）

b：

統計ログファイルに含まれる統計情報の種別に応じて次の値を代入してください。統計ログファイルに複数の種別の統計情報が含まれる場合は，最も大きい値をbの値とします。

統計情報の種別 | bの値
システムの稼働に関する統計情報 | 1.7
上記以外 | 1

(3)　DAT形式ファイルの容量の概算値

統計解析ユティリティ実行時に作成されるDAT形式ファイルの容量の概算値は，次の計算式で求められます。なお，この概算値は，ユティリティの入力情報となる統計ログファイル内のすべての情報を解析した場合の値です。

DAT形式ファイルの容量＝統計ログファイルの容量×2（単位：バイト）

19.1.4　データベース状態解析ユティリティ（pddbst）実行時のファイルの容量

データベース状態解析ユティリティ（pddbst）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：キロバイト）
ワーク用ファイル | RDエリア単位の物理的解析 | 1＋4.1×a

RDエリア単位の論理的解析

　　　　 a

1＋4.1×Σ（

　　　　i=1

　　RDエリア内の表数i

　＋インデクス数i

　＋LOB用RDエリア数i）

状態解析結果蓄積又は再編成時期予測※

　　　　 a

1＋4.1×Σ（

　　　　i=1

　　RDエリア内の表数i

　＋インデクス数i

　＋LOB用RDエリア数i）

表単位の状態解析 | 1＋4.1×（格納RDエリア数）
インデクス単位の状態解析 | 1＋4.1×（格納RDエリア数）
クラスタキーの状態解析 | 1＋4.1×（格納RDエリア数）
ソート用ワークファイル | 上記のワーク用ファイルのソート用作業領域 | 上記の計算式で求めた値×2

注※

pddbst -r ALL指定時は，ユーザ用RDエリア内だけでなく，ディクショナリ用RDエリア内の資源数を加算する必要があります。また，分割した表やインデクスについてはRDエリアごとに数を加算します。

ａ：解析対象のRDエリア数

19.1.5　データベース複写ユティリティ（pdcopy）実行時のファイルの容量

データベース複写ユティリティ（pdcopy）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：バイト）

バックアップファイル※

フルバックアップファイル※

a

Σ｛28×ci＋（di＋28）×（ei＋qi ）｝

i=1

＋88×a＋220×b

差分バックアップファイル※ | ｗ×フルバックアップファイルの容量
差分バックアップ管理ファイル | （1＋j＋m）×32768
ログポイント情報ファイル | 1024

注※

バックアップファイルの容量が2ギガバイトを超える場合は，次に示す対処をしてください。

2ギガバイト以下のパーティションを複数作成して，バックアップファイルを複数指定してください。

a：バックアップ対象RDエリア数

b：バックアップ対象RDエリアのHiRDBファイルの総数

ci：バックアップ対象RDエリアの未使用ページ数

システム構築前に見積もる場合は0と仮定してください。

ユーザ用RDエリアの場合

データベース状態解析ユティリティ（pddbstコマンド）のRDエリア単位の状態解析（物理的解析）を実行して求めてください。ユティリティの実行結果の「RDエリア内のページの情報」の「総ページ数−使用ページ数」の値です。

ユーザLOB用RDエリアの場合

データベース状態解析ユティリティ（pddbstコマンド）のRDエリア単位の状態解析（物理的解析）を実行して求めてください。ユティリティの実行結果の「RDエリア内のセグメントの情報」の「総セグメント数−使用セグメント数」の値です。

di：バックアップ対象RDエリアのページ長

ei：バックアップ対象RDエリアの使用ページ数

システム構築前に見積もる場合は，（バックアップ対象RDエリアのセグメント数×セグメントサイズ）を仮定して計算してください。

ユーザ用RDエリアの場合

データベース状態解析ユティリティ（pddbstコマンド）のRDエリア単位の状態解析（物理的解析）を実行して求めてください。ユティリティの実行結果の「RDエリア内のページの情報」の「使用ページ数」の値です。

ユーザLOB用RDエリアの場合

データベース状態解析ユティリティ（pddbstコマンド）のRDエリア単位の状態解析（物理的解析）を実行して求めてください。ユティリティの実行結果の「RDエリア内のセグメントの情報」の「使用セグメント数」の値です。

g：-bオプションに指定するバックアップファイルの名称長（バイト）

複数のバックアップファイルを指定する場合は，合計の名称長になります。

h：-bオプションに指定するバックアップファイルの数

j：↑（512＋128×a）÷32700↑

k：差分バックアップの継続回数

m：↑｛↑（256＋128×a＋g＋8×h）÷256↑×k｝÷100↑

qi：バックアップ対象RDエリアのディレクトリページ数

ユーザ用RDエリアの場合

6×（ti＋1）＋2×↑（20480÷di）↑＋｛↑（si÷ui）↑＋↑（si÷vi）↑＋2×ti｝

ユーザLOB用RDエリアの場合

7＋3×（ti−1）＋｛↑（si÷64000）↑＋ti｝×96

ri：バックアップ対象RDエリアのセグメントサイズ

si：バックアップ対象RDエリアの全セグメント数

データベース初期設定ユティリティ（pdinitコマンド）又はデータベース構成変更ユティリティ（pdmodコマンド）のcreate rdarea文で指定するHiRDBファイルのセグメント数の合計です。RDエリアの自動増分を指定している場合は，増分したセグメント数を加算してください。

ti：バックアップ対象RDエリアのHiRDBファイル数

ui：↓｛di−20｝÷｛（↑ri÷32↑×8）＋56｝↓

vi：↑（125×di）÷（16×ui）↑×ui

w：バックアップ対象RDエリアの全ページに対する更新ページの比率

ｗの算出式（ユーザ用RDエリア）は次に示す計算式から求めます。

ｗ＝｛
　　　a
　　　Σ Xi÷
　　　i=1
　　　a
　　　Σ ei｝×1.2
　　　i=1

Xi：バックアップ対象RDエリアの更新ページ数

更新ページ数とは，差分の基準となる前回の差分バックアップ取得時から現在までの間に更新されたページの数のことです。更新ページ数は更新SQLの種類又は更新件数などから，バックアップ対象RDエリアに格納されている表及びインデクスについて，次に示す条件に従って計算してください。

INSERTの場合

「ユーザ用RDエリアの容量の見積もり」を参照して，インサート件数から格納ページ数を計算してXiに加算してください。このとき，PCTFREEは0で計算してください。

DELETEの場合

次に示す条件に応じて計算した値をXiに加算してください。

条件 | Xiに加算する値
表 | 行長＜di | 削除行が表全体に分散する場合 | MIN（削除行数，表の使用中ページ数）
削除行が一部のページに集中する場合 | MIN（削除行数÷１ページで格納できる行数，表の使用中ページ数）
行長＞di | MIN（削除行数×１行格納するのに必要なページ数，表の使用中ページ数）
インデクス | 更新されるキーがインデクス全体に分散する場合 | MIN（更新キー数＋α，インデクスの使用中ページ数）
更新されるキーが一部のページに集中する場合 | MIN（更新キー数÷１ページで格納できるキー数＋α，インデクスの使用中ページ数）

α：201以上重複するキーの数

UPDATEの場合

次に示す条件に応じて計算した値をXiに加算してください。

条件 | Xiに加算する値
表 | 更新列長＜di | 更新行が表全体に分散する場合 | MIN（更新行数，表の使用中ページ数）
更新行が一部のページに集中する場合 | MIN（更新行数÷１ページで格納できる行数，表の使用中ページ数）
更新列長＞di | MIN（更新行数×更新列を格納するのに必要なページ数，表の使用中ページ数）
インデクス | 更新されるキーがインデクス全体に分散する場合 | MIN（更新キー数×2＋α×2，インデクスの使用中ページ数）
更新されるキーが一部のページに集中する場合 | MIN（更新キー数×2÷１ページで格納できるキー数＋α×2，インデクスの使用中ページ数）

α：201以上重複するキーの数

再編成を行った場合

再編成を行った表又はインデクスのうち，バックアップ対象RDエリアに格納されているものについてβを計算してください。

β＝再編成を行った表又はインデクスの使用中ページ数＋再編成を行った表又はインデクスの使用中セグメント数÷ui＋再編成を行った表又はインデクスの使用中セグメント数÷vi

βを再編成した表又はインデクスの数だけ計算してXiに加算してください。

PURGEの場合

PURGEを行った表又はインデクスのうち，バックアップ対象RDエリアに格納されているものについてγを計算してください。

γ＝PURGEを行った表又はインデクスの使用中セグメント数÷ui＋PURGEを行った表又はインデクスの使用中セグメント数÷vi

γを再編成した表又はインデクスの数だけ計算してXiに加算してください。

19.1.6　ディクショナリ搬出入ユティリティ（pdexp）実行時のファイルの容量

ディクショナリ搬出入ユティリティ（pdexp）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：キロバイト）

搬出ファイル※

実表の場合

0.7＋0.5×CMN＋（0.1×↑CMN÷10↑）

DEF

＋Σ（0.1＋DSn）＋0.1×↑LRD÷10↑

n=1

＋0.6×↑DIV÷10↑＋2.8×REF

CHK

＋Σ（0.1＋1.0×↑CSn÷10↑）

n=1

IDX

＋Σ（2.7＋0.2×IRn）

n=1

ビュー表の場合 | 0.6＋0.4×CMN＋（0.1×↑CMN÷10↑）＋e
プロシジャの場合 | 0.6＋0.1×g＋h

CHK：検査制約数（0≦CHK≦254）

CMN：表の列数（1≦CMN≦30,000）

CSn：n番目の検査制約の検索条件サイズ（0≦CSn≦2,000,000）

DEF：デフォルト値定義列数（0≦DEF≦30,000）

DIV：分割条件数（0≦DIV≦4,096）

DSn：n番目のデフォルト列のデフォルト値サイズ（1≦DSn≦64,003）

IDX：インデクス数（0≦IDX≦254）

IRn：n番目のインデクスの格納用RDエリア数（0≦IRn≦4,096）

LRD：LOB用RDエリア数（0≦LRD≦4,096）

REF：参照制約数（0≦REF≦255）

e：ビュー表定義時のソース長（単位：キロバイト）

g：搬出するストアドプロシジャが使用するリソース数

SQL_ROUTINES表のN_RESOURCE列の値です。

h：ストアドプロシジャのソース長（単位：キロバイト）

SQL_ROUTINES表のSOURCE_SIZE列の値です。

注※

複数の表を搬出する場合，各表に対して上記の計算をしてください。その合計値が搬出ファイルの容量となります。

19.1.7　最適化情報収集ユティリティ（pdgetcst）実行時のファイルの容量

最適化情報収集ユティリティ（pdgetcst）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：バイト）
最適化情報パラメタファイル | 162＋405×a＋567×b＋162＋324×b×g

出力結果ファイル

検索による最適化情報収集時（-c lvl1指定時）

202＋131×e

検索による最適化情報収集時（-c lvl2指定時）

370＋561×c＋196×d

最適化情報パラメタファイルによる最適化情報登録時

370＋235×c＋387×f＋196×g

a：指定インデクス数

b：指定列数

c：表に定義してあるインデクスの数

d：区間数（全インデクスの区間数の合計）

e：表数

f：表の列数

g：区間数（全列定義で指定した区間数の合計）

19.1.8　アクセスパス表示ユティリティ（pdvwopt）実行時のファイルの容量

アクセスパス表示ユティリティ（pdvwopt）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：バイト）
アクセスパス 情報ファイル | [図データ]

a：検索系SQL数

bi：SQL中の問合せ数

cij：問合せ中の表数

dij：問合せ中の結合処理数

eijk：表の格納RDエリア数

fijk：表のインデクス定義数

19.1.9　リバランスユティリティ（pdrbal）実行時のファイルの容量

リバランスユティリティ（pdrbal）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：バイト）

インデクス情報ファイル

B-treeインデクスの場合

（K＋ｄ）×N＋512

プラグインインデクスの場合

（12×Y）×N＋1024

この計算式は，1インデクス当たりの容量計算式です。インデクスが複数ある場合は，それぞれのインデクスに対して計算してください。

ワークファイル※１ | （3＋4×I×R）×200

ソート用ワークファイル※２

条件1の場合

インデクス情報ファイルの容量＋4×N

条件2の場合

｛インデクス情報ファイルの容量＋4×N｝×2

条件1

1024キロバイト≧Eのとき

条件2

1024キロバイト＜Eのとき

E：バッファサイズ

「ソート用ワークファイル容量の計算で使用するバッファサイズ」で求めたバッファサイズ

実行結果出力ファイル | 1000＋表格納RDエリア数×200

ｄ：キー構成列がすべて固定長の場合は10，キー構成列に可変長を含む場合は12

Ｉ：インデクス数

Ｋ：インデクスのキー長

表「インデクスのキー長一覧」を参照してください。ただし，可変長データの場合は単一列でも複数列として扱い，定義長の最大値で計算してください。

Ｎ：リバランス処理によって移動する行数（繰返し列の場合は行数×要素数）

Ｒ：表又はインデクスの分割RDエリア数

Ｙ：次に示す値

LOB用RDエリアに格納された抽象データ型の場合は27

定義長255バイト以下の抽象データ型の場合は（キー長＋2）

定義長256バイト以上の抽象データ型の場合は2

代表的な抽象データ型の値を次に示します。

SGMLTEXT型の場合は27

FREEWORD，GEOMETRY，及びXML型の場合は2

注※1

-mオプションにlvl2を指定した場合に出力されます。

注※2

プラグインインデクスの場合，このファイルは不要です。

19.1.10　整合性チェックユティリティ（pdconstck）実行時のファイルの容量

整合性チェックユティリティ（pdconstck）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：バイト）

処理結果ファイル

-k set/releaseの場合

560＋（REF＋1）×70＋（CHK＋1）×70

-k checkの場合

700＋（REF＋1）×70＋（CHK＋1）×70

REF

＋Σ（490＋（RCn×70）

n=1

GEN ROW

＋Σ（Σ（RCnml×70）））

m=1 l=1

CHK

＋Σ（490＋（CCn×70）

n=1

GEN ROW

＋Σ（Σ（CCnml×70）））

m=1 l=1

REF：表に定義されている参照制約の制約数

CHK：表に定義されている検査制約の制約数

RC：参照制約の外部キー構成列数

CC：検査制約の探索条件中の列数

GEN：1

ROW：制約違反となったキー値の出力数の上限値（-wオプションで指定した値）

19.1.11　パラレルローディング（pdparaload）実行時のファイルの容量

パラレルローディング（pdparaload）で使用するファイルの容量の計算式を次に示します。

ファイルの種類 | 容量の計算式（単位：バイト）
pdload制御文ファイル | （pdparaload制御文ファイルの容量＋200）×R
pdloadが作成するファイル※ | 表を構成するRDエリア 　　　　　Σ（RDエリア単位のデータロード実行に必要なファイル容量i） 　　　　　i=1

R：表を構成するRDエリア数

注※

pdparaloadコマンドは，表を構成するRDエリアの数だけ，内部でRDエリア単位のデータロード（pdload）を実行します。そのため，pdparaloadは，RDエリア単位のデータロード実行に必要なファイルを，表を構成するRDエリア数分使用します。RDエリア単位のデータロード実行に必要なファイルの容量については，「データベース作成ユティリティ（pdload）実行時のファイルの容量」を参照してください。

19.1.12　ソート用ワークファイル容量の計算で使用するバッファサイズ

ソート用バッファサイズの計算式を次に示します。

n：処理するデータ件数

pdloadの場合：表の既存データと追加ロードするデータの合計

pdrorgの場合：アンロードしたデータ件数

pdrbalの場合：リバランスするデータ件数

なお，繰返し列の場合，データ件数は行数ではなく要素数となります。

k：キー長（最大値で計算します）。キー長の計算式については，「インデクスの格納ページ数の計算例」を参照してください。

x：キー構成列がすべて固定長の場合は10，キー構成列に可変長を含む場合は12

c：インデクスの構成列数

z：可変長の複数列インデクスの場合はc×4，そのほかの場合は0

K：可変長の複数列インデクスの場合はk＋c＋8，そのほかの場合はk＋12

N：可変長の複数列インデクスの場合は（c×2）＋2，そのほかの場合は5

R：k＋x＋z

A：32ビットモードのHiRDBの場合はR＋（K＋8）＋28，64ビットモードのHiRDBの場合はR＋（K＋8）＋56

B：32ビットモードのHiRDBの場合はR＋（K＋8）＋56，64ビットモードのHiRDBの場合はR＋（K＋8）＋104

C：32ビットモードのHiRDBの場合は2092＋（N×32）＋（K＋8），64ビットモードのHiRDBの場合は2112＋（N×32）＋（K＋8）

19.2　ユティリティ実行時のメモリ所要量の見積もり

19.2.1　データベース初期設定ユティリティ（pdinit）実行時のメモリ所要量

データベース初期設定ユティリティ（pdinit）実行時のメモリ所要量は，次に示す計算式で求めます。

(1)　HiRDB/シングルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）

32ビットモードの場合

↑{

　｛61440×（140×a＋20×b＋c）｝÷61432＋（6004×d）÷500

　＋（36008×a）÷1000＋468×e＋404399

}↑÷1024＋267

64ビットモードの場合

↑{

　｛61448×（144×a＋24×b＋c）｝÷61436＋（8004×d）÷500

　＋（36016×a）÷1000＋468×e＋406399

}↑÷1024＋267

a：RDエリアの総数

b：全RDエリアのHiRDBファイル数

c：全HiRDBファイルの名称長の合計

d：認可識別子の総数

e：データディクショナリ用RDエリア数

(2)　HiRDB/パラレルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）

32ビットモードの場合

DS

↑｛

　｛61448×（144×ａ＋24×ｂ＋ｃ）｝÷61436＋（8004×ｄ）÷500

　＋（36016×ａ）÷1000＋468×ｅ＋406399＋348×ｆ＋344×ｇ

｝↑÷1024＋268

BES | ↑（4×b＋246255）÷1024↑＋268
MGR | 10

64ビットモードの場合

DS

↑{

　{61448×（144×a＋24×b＋c）}÷61436＋（8004×d）÷500

　＋（36016×a）÷1000＋468×e＋406399＋348×f＋344×g

}↑÷1024＋268

BES | ↑（4×b＋245744）÷1024↑＋268
MGR | 10

a：RDエリアの総数

b：全RDエリアのHiRDBファイル数

c：全HiRDBファイルの名称長の合計

d：認可識別子の総数

e：データディクショナリ用RDエリア数

f：バックエンドサーバの総数

g：（144×a＋24×b＋c）÷7780 を各バックエンドサーバごとに計算した総計

19.2.2　データベース定義ユティリティ（pddef）実行時のメモリ所要量

データベース定義ユティリティ（pddef）実行時のメモリ所要量は，次に示す計算式で求めます。

条件 | メモリ所要量の計算式（単位：キロバイト）
HiRDB/シングルサーバの場合 | 32ビットモードの場合：1956 64ビットモードの場合：1957
HiRDB/パラレルサーバの場合

19.2.3　データベース作成ユティリティ（pdload）実行時のメモリ所要量

データベース作成ユティリティ（pdload）実行時のメモリ所要量は，次に示す計算式で求めます。計算式の変数については「計算式で使用する変数」を参照してください。

(1)　HiRDB/シングルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）
32ビットモードの場合 | 4352＋↑{（α＋γ）÷1024 }↑＋1482＋↑{（β＋δ）÷1024 }↑
64ビットモードの場合 | 18050＋↑{（α＋γ）÷1024 }↑＋1482＋↑{（β＋δ）÷1024 }↑

(2)　HiRDB/パラレルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）
32ビットモードの場合 | MGR | 1530＋↑{α÷1024}↑
入力ファイルがあるサーバマシン | 1577＋↑{（β＋δ）÷1024}↑
BES※ | 2305＋↑{γ÷1024}↑
64ビットモードの場合 | MGR | 4732＋↑{α÷1024}↑
入力ファイルがあるサーバマシン | 4663＋↑{（β＋δ）÷1024}↑
BES※ | 12220＋↑{γ÷1024}↑

注※

1サーバマシン内に複数のバックエンドサーバがある場合は，バックエンドサーバの数だけ繰り返し計算（加算）してください。

(3)　計算式で使用する変数

α（単位：バイト）：

｛3056＋Ａ＋Ｂ＋（516×ａ）＋（572×ｂ）＋（312×ｃ）＋（144×ｄ）＋（8×ｅ）＋（1032×ｆ）＋（44×ｇ）＋（272×ｈ）＋（224×ｉ）＋（44×ｊ）＋（60×ｋ）＋（260×ｍ）＋（56×ｎ）＋（196×ｐ）＋（236×ｑ）＋（744×ｒ）＋（620×ｓ）｝×2

β（単位：バイト）：

｛6908＋α＋（Ｃ×ｔ）＋Ｋ＋（48×ａ）＋（22×ｂ）＋（8×ｅ）＋（240×ｉ）＋（48×ｊ）＋（4×ｋ）＋（224×ｍ）＋（47416×ｔ）＋（1032×ｕ）＋（4×ｖ）｝

γ（単位：バイト）：

｛37700＋（α÷２）＋Ｃ＋Ｄ＋Ｆ＋Ｈ＋Ｐ＋Q＋T＋（80×ａ）＋（1871×ｂ）＋（120×ｃ）＋（26×ｇ）＋（1532×ｉ）＋（36×ｊ）＋（44×ｋ）＋（1212×ｍ）＋（40×ｎ）＋（344×ｐ）＋（30×ｑ）＋（16×ｕ）＋（88×ｖ）＋（20×ｗ）｝

δ（単位：バイト）：

｛69436＋α＋Ｄ＋Ｋ＋Ｌ＋Ｍ＋Ｎ＋Ｓ＋（Ｕ×2）＋8＋（48×ａ）＋（32×ａ）＋（88×ｃ）＋（4×ｇ）＋（2156×ｋ）＋（24×ｔ）＋（1024×ｕ）＋（4×ｖ）＋（50×y）＋（50×z）｝

ａ：列数

ｂ：抽象データ型の列数

ｃ：コンストラクタ又は逆コンストラクタ関数のパラメタ数

ｄ：コマンドライン及び制御情報ファイルに指定したファイルパス名の数

ｅ：LOB中間ファイル指定数

ｆ：列単位LOBファイル指定数

ｇ：表格納RDエリア数

ｈ：表の横分割条件数

ｉ：インデクス数

ｊ：インデクス格納RDエリア数

ｋ：BLOB型の列数

ｍ：プラグインインデクス数

ｎ：LOB属性の抽象データ型を格納するユーザLOB用RDエリア数

ｐ：プラグインが提供する関数の数

ｑ：プラグイン提供関数のパラメタ数

ｒ：データ型プラグイン数

ｓ：インデクス型プラグイン数

ｔ：表格納サーバ数

ｕ：使用するコンストラクタ関数のパラメタのうちでBLOB型のパラメタ数

ｖ：LOB列を格納するユーザLOB用RDエリア数

ｗ：プラグインインデクスを格納するユーザLOB用RDエリア数

ｙ：BINARY型の列数

skipdata制御文で入力データ中の処理対象外としたBINARYデータの列数と，実際に表に定義されている列数の合計です。

ｚ：プラグイン提供関数のBINARY属性のパラメタ数

skipdata制御文で入力データ中の処理対象外としたプラグイン提供関数のBINARYデータの列数と，実際に表に定義されている列数の合計です。

Ａ：コマンドライン上で指定したファイルサイズの合計

Ｂ：コマンドライン及び制御情報ファイルに指定したファイルパス名の長さの合計

Ｃ：次に示す条件を満たす場合は（pd_utl_buff_size×1024＋4096）×2，そのほかの場合は0

HiRDB/パラレルサーバの場合

source文に指定したサーバ名と表格納RDエリアがあるバックエンドサーバ名が異なるpdloadコマンド実行時，又は-gオプションを指定したpdrorgコマンド実行時

Ｄ：行長

表を構成する全列の定義長の合計です。ただし，BLOB型や抽象データ型は8バイトとします。BINARY型はpdloadの場合は定義長，pdrorgの場合はMIN（定義長，32500）バイトとします。また，FIX表以外は（ａ＋1）×4を加算します。

Ｆ：550×1024＋1024×1024＋Ｇ

-iオプションにcを指定した場合に加算します。

Ｇ：256（32ビットモードの場合）又は512（64ビットモードの場合）

Ｈ：一括入出力用ローカルバッファの指定値×RDエリアのページ長×Ｊ＋ランダムアクセス用ローカルバッファの指定値×RDエリアのページ長

-nオプションを指定した場合に加算します。RDエリアのページ長が横分割したRDエリアごとに異なる場合，最大のページ長で計算してください。

Ｊ：次に示す表から求めてください。

-nオプション の指定値 | 表の分割種別
非分割表 | キーレンジ 分割表 | ハッシュ分割表
リバランスハッシュ （HASHA〜HASHF） | 非リバランスハッシュ （HASH0〜HASH6，HASHZ）
FIXハッシュ | フレキシブルハッシュ
div指定あり | 1 | 表のサーバ内横分割数 | HiRDB/シングルサーバの場合：1024 HiRDB/パラレルサーバの場合：（↑1024÷g↑）×（該当サーバ内の表格納RDエリア数） | 表のサーバ内横分割数 | 表のサーバ内横分割数
div指定なし | 1 | 1

Ｋ：パラメタ長

抽象データ型に格納する値を生成するコンストラクタ関数の引数の合計長です。ただし，BLOB型のパラメタは８バイトで計算します。

Ｌ：次に示す条件をすべて満たす場合は1又は2の値を加算，そのほかの場合は0

source文にerrdataオペランドを指定

source文に指定したサーバ名と表格納RDエリアがあるバックエンドサーバ名が異なる（HiRDB/パラレルサーバの場合）

表に抽象データ型の列がある又はユニークインデクスを定義している

errworkオペランド指定時：errworkオペランドの指定値×1024

errworkオペランド省略時：pd_utl_buff_size×1024×3×ｔ

Ｍ：UOCのメモリ所要量

UOCを使用した場合に加算します。

Ｎ：maxreclenオペランドを指定した場合に次に示す値を加算します。

入力データファイルが拡張DAT形式のとき：

maxreclenオペランド指定値×1024

入力データファイルがDAT形式のとき：

maxreclenオペランド指定値×1024×3

対象となる表がBINARY型の列を持ち，入力データファイルがバイナリ形式のとき：

次のどちらか小さい方を加算してください。

maxreclenオペランド指定値×1024

変数D（行長）

上記以外のとき：

0

Ｐ：プラグインのメモリ所要量

プラグインが提供する抽象データ型の列がある場合に加算します。プラグインのメモリ所要量については，プラグインのマニュアルを参照してください。

コンストラクタ関数の引数がBLOB型又はBINARY型の場合は，1行に定義されている（全抽象データ型に格納する実際のパラメタ長×2）を加算します。

Ｑ：出力バッファ用メモリ所要量

インデクス作成方法にインデクス一括作成モード，又はインデクス情報出力モードを指定していて，次の条件を満たす場合，2メガバイトを加算します。

表分割数×インデクス定義数＞プロセスのオープン数の上限-576

Ｓ：（4×バッファ長＋1.1）×1024

バッファ長は次の値になります（値は32キロバイト単位に切り上げてください）。

データベース作成ユティリティ（pdload）のoption文のfile_buff_sizeの指定値

上記の指定がない場合は1024

Ｔ：圧縮列がある場合は，圧縮分割サイズ×2＋RDエリアのページ長，圧縮列がない場合は0

圧縮分割サイズは，全圧縮列中の最大値で計算してください。また，表を横分割したRDエリアごとにページ長が異なるときは，ページ長の最大値で計算してください。

Ｕ：入力ファイルの行長（単位：バイト）

DAT形式の場合：maxreclenオペランドの指定値×1024（maxreclenオペランドの指定がないときは32768）

固定長形式の場合：入力ファイルの行長

バイナリ形式の場合：0

19.2.4　データベース再編成ユティリティ（pdrorg）実行時のメモリ所要量

データベース再編成ユティリティ（pdrorg）実行時のメモリ所要量は，次に示す計算式で求めます。計算式の変数については，「計算式で使用する変数」を参照してください。

(1)　HiRDB/シングルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）
32ビットモードの場合 | 5466＋↑{（α＋γ）÷1024}↑＋1621＋↑{（β＋δ）÷1024}↑
64ビットモードの場合 | 18362＋↑{（α＋γ）÷1024}↑＋1621＋↑{（β＋δ）÷1024}↑

(2)　HiRDB/パラレルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）
32ビットモードの場合 | MGR | 1509＋↑{α÷1024}↑
-gオプションなし | DS | 1413＋↑{β÷1024}↑
BES※１※２ | 3505＋↑{（γ＋δ）÷1024}↑
-gオプションあり | アンロードデータファイルがあるサーバマシン | 1413＋↑{（β＋δ）÷1024}↑
BES※２ | 3505＋↑{γ÷1024}↑
64ビットモードの場合 | MGR | 4761＋↑{β÷1024}↑
-gオプションなし | DS | 16482＋↑{β÷1024}↑
BES※１※２ | 12100＋↑{（γ＋δ）÷1024}↑
-gオプションあり | アンロードデータファイルがあるサーバマシン | 4566＋↑{（β＋δ）÷1024}↑
BES※２ | 12100＋↑{γ÷1024}↑

注※１

ディクショナリ表を再編成する場合は，計算値をディクショナリサーバがあるサーバマシンに加算してください。

注※２

1サーバマシン内に複数のバックエンドサーバがある場合は，バックエンドサーバの数だけ繰り返し計算（加算）してください。

(3)　計算式で使用する変数

α（単位：バイト）：

｛2592＋Ａ＋Ｂ＋（116×ａ）＋（260×ｂ）＋（6×ｃ）＋（272×ｄ）＋（44×ｇ）＋（272×ｈ）＋（224×ｉ）＋（44×ｊ）＋（60×ｋ）＋（260×ｍ）＋（56×ｎ）＋（196×ｐ）＋（236×ｑ）＋（744×ｒ）＋（620×ｓ）＋（24×ｔ）｝×2

β（単位：バイト）：

｛40940＋α＋（Ｃ×ｔ）＋（Ｄ×ｔ）＋（136×ａ）＋（56×ｇ）＋（2200×ｊ）＋（4×ｋ）＋（548×ｔ）｝

γ（単位：バイト）：

｛101140＋（α÷2）＋Ｃ＋（Ｄ×2）＋Ｆ＋Ｈ＋Ｐ＋Q＋T＋64010＋（48×ａ）＋（128×ａ）＋（1949×ｂ）＋（120×ｃ）＋（154×ｇ）＋（336×ｉ）＋（216×ｊ）＋（32056×ｋ）＋（1212×ｍ）＋（131224×ｎ）＋（344×ｐ）＋（30×ｑ）＋（20×ｗ）｝

δ（単位：バイト）：

｛33104＋α＋（Ｋ×2）＋Ｓ＋72＋（48×ａ）＋（204×ａ）＋（688×ｂ）＋（306×ｃ）＋（44×ｇ）＋（272×ｈ）＋（224×ｉ）＋（44×ｊ）＋（56×ｎ）＋（716×ｒ）＋（152×ｖ）｝

注

変数については，「データベース作成ユティリティ（pdload）実行時のメモリ所要量」の「計算式で使用する変数」で説明しています。

ディクショナリ再編成又はスキーマ単位の再編成で１回のコマンドで複数の表を処理する場合，変数ａ〜ｚは処理対象すべての表の合計で計算してください。

19.2.5　データベース構成変更ユティリティ（pdmod）実行時のメモリ所要量

データベース構成変更ユティリティ（pdmod）実行時のメモリ所要量は，次に示す計算式で求めます。

(1)　HiRDB/シングルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）

32ビットモードの場合

↑{

　　4×a＋56016×b＋53016×c＋2440×d＋1724×e

　　＋（94008×f）÷500＋（4008×g）÷1000＋441231＋h＋i＋j＋k

　}÷1024↑＋9.8

64ビットモードの場合

↑{

　　4×a＋56024×b＋53024×c＋3040×d＋1736×e

　　＋（100016×f）÷500＋（4012×g）÷1000＋451231＋h＋i＋j＋k

　}÷1024↑＋9.8

a：pd_max_rdarea_noの値

b：initialize rdarea文実行時の自RDエリア内のインデクス数＋他RDエリアのインデクス数

c：initialize rdarea文実行時のLOB列の総数

d：initialize rdarea文実行時のLOB属性の抽象データ型の総数

e：initialize rdarea文実行時のプラグイン列とプラグインインデクスの総数

f：initialize rdarea文実行時の抽象データ型の総数

g：initialize rdarea文実行時の自RDエリア格納表のASSIGN LISTの総数

h：8×a＋30720

alter HiRDB mode to parallel文でHiRDB/シングルサーバからHiRDB/パラレルサーバへ移行する場合に加算します。

i：46744

create rdarea文でデータディクショナリLOB用RDエリアを追加する場合に加算します。

j：88064

alter system文でディクショナリ表の参照権限を変更する場合に加算します。

k：54732

alter system文でディクショナリ表の列属性MCHARにする場合に加算します。

(2)　HiRDB/パラレルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）

32ビットモードの場合

DS

↑｛

　　4×a＋56016×b＋53016×c＋2440×d＋1724×e

　　＋（94008×f）÷500＋（4008×g）÷1000＋441231＋h＋i＋j

　　＋108428×m

　｝÷1024↑

BES | ↑（4×a＋253266＋k）÷1024↑
FES | 0.52
MGR | 9.8

64ビットモードの場合

DS

↑{

　　4×a＋56024×b＋53024×c＋3040×d＋1736×e

　　＋（100016×f）÷500＋（4012×g）÷1000＋451231＋h＋i＋j

　　＋108432×m

　}÷1024↑

BES | ↑（4×a＋261112＋k）÷1024↑
FES | 0.53
MGR | 9.8

a：pd_max_rdarea_noの値

b：initialize rdarea文実行時の自RDエリア内のインデクス数＋他RDエリアのインデクス数

c：initialize rdarea文実行時のLOB列の総数

d：initialize rdarea文実行時のLOB属性の抽象データ型の総数

e：initialize rdarea文実行時のプラグイン列とプラグインインデクスの総数

f：initialize rdarea文実行時の抽象データ型の総数

g：initialize rdarea文実行時の自RDエリア格納表のASSIGN LISTの総数

h：46744

create rdarea文でデータディクショナリLOB用RDエリアを追加する場合に加算します。

i：88064

alter system文でディクショナリ表の参照権限を変更する場合に加算します。

j：54732

alter system文でディクショナリ表の列属性MCHARにする場合に加算します。

k：1600

initialize rdarea文を実行する場合に加算します。

m：move rdarea文を実行する場合に次に示す計算式を加算します。

move rdarea文を実行しない場合0になります。

↑（192×移動対象RDエリア数＋160×移動対象RDエリアの総HiRDBファイル数＋8×移動対象RDエリアに格納されている表の総数＋8×移動対象RDエリアに格納されているインデクスの総数＋8×移動対象RDエリアに格納されているLOB列の総数）÷102400↑

19.2.6　統計解析ユティリティ（pdstedit）実行時のメモリ所要量

統計解析ユティリティ（pdstedit）実行時のメモリ所要量は，次に示す計算式で求めます。

条件 | メモリ所要量の計算式（単位：キロバイト）
HiRDB/シングルサーバの場合 | 16384※＋1.5×ホスト数×HiRDBサーバ数×UAP数
HiRDB/パラレルサーバの場合

注※

64ビットモードの場合は18640です。

19.2.7　データベース状態解析ユティリティ（pddbst）実行時のメモリ所要量

データベース状態解析ユティリティ（pddbst）実行時のメモリ所要量は，次に示す計算式で求めます。

条件 | メモリ所要量の計算式（単位：キロバイト）

HiRDB/シングルサーバの場合（32ビットモードの場合）

RDエリア物理解析時：4600

RDエリア論理解析時：4400＋1.4×ａ＋↑ａ÷100↑×672

表単位の解析時：4400＋1.4×ｂ＋↑ｂ÷100↑×672

インデクス単位の解析時：4400＋1.4×ｃ＋↑ｃ÷100↑×672

クラスタキーの解析時：4600

HiRDB/シングルサーバの場合（64ビットモードの場合）

RDエリア物理解析時：17915

RDエリア論理解析時：17915＋1.4×ａ＋↑ａ÷100↑×672

表単位の解析時：17915＋1.4×ｂ＋↑ｂ÷100↑×672

インデクス単位の解析時：17915＋1.4×ｃ＋↑ｃ÷100↑×672

クラスタキーの解析時：17915

HiRDB/パラレルサーバの場合（32ビットモードの場合）

DS

RDエリア物理解析時：750

RDエリア論理解析時：750＋0.1×ａ

表単位の解析時：750＋0.1×ｂ

インデクス単位の解析時：750＋0.1×ｃ

クラスタキーの解析時：750

BES

RDエリア物理解析時：650

RDエリア論理解析時：650＋0.1×ａ

表単位の解析時：650＋0.1×ｂ

インデクス単位の解析時：650＋0.1×ｃ

クラスタキーの解析時：650

MGR

RDエリア物理解析時：3900

RDエリア論理解析時：3550＋1.3×ａ＋↑ａ÷100↑×672

表単位の解析時：3550＋1.3×ｂ＋↑ｂ÷100↑×672

インデクス単位の解析時：3550＋1.3×ｃ＋↑ｃ÷100↑×672

クラスタキーの解析時：3900

HiRDB/パラレルサーバの場合（64ビットモードの場合）

DS

RDエリア物理解析時：16312

RDエリア論理解析時：16312＋0.1×ａ

表単位の解析時：16312＋0.1×ｂ

インデクス単位の解析時：16312＋0.1×ｃ

クラスタキーの解析時：16312

BES

RDエリア物理解析時：11812

RDエリア論理解析時：11812＋0.1×ａ

表単位の解析時：11812＋0.1×ｂ

インデクス単位の解析時：11812＋0.1×ｃ

クラスタキーの解析時：11812

MGR

RDエリア物理解析時：4601

RDエリア論理解析時：4601＋1.3×ａ＋↑ａ÷100↑×672

表単位の解析時：4601＋1.3×ｂ＋↑ｂ÷100↑×672

インデクス単位の解析時：4601＋1.3×ｃ＋↑ｃ÷100↑×672

クラスタキーの解析時：4601

ａ：RDエリア格納表数＋RDエリア格納インデクス数

ｂ：表格納RDエリア数

ｃ：インデクス格納RDエリア数

19.2.8　最適化情報収集ユティリティ（pdgetcst）実行時のメモリ所要量

最適化情報収集ユティリティ（pdgetcst）実行時のメモリ所要量は，次に示す計算式で求めます。

条件 | メモリ所要量の計算式（単位：キロバイト）
HiRDB/シングルサーバの場合 | 6060＋0.1×表格納RDエリア数＋0.07×インデクス格納RDエリア数＋1.0×インデクス数＋0.04×スキーマ内表数＋1.0×サーバ数＋11×列数
HiRDB/パラレルサーバの場合 | BES | 1813＋0.06×表格納RDエリア数＋0.05×インデクス格納RDエリア数＋0.03×インデクス数
MGR | 3336＋0.1×表格納RDエリア数＋0.07×インデクス格納RDエリア数＋1.0×インデクス数＋0.04×スキーマ内表数＋1.0×サーバ数＋11×列数
DS | 16402

注

上記のほかに次のSQLが使用するメモリ所要量を加算します。

SELECT 内部情報※,インデクス第一構成列名 FROM 認可識別子.表識別子
    ORDER BY インデクス第一構成列名 WITHOUT LOCK NOWAIT;
SELECT FLOAT (COUNT(*)) FROM 認可識別子.表識別子 WITHOUT LOCK NOWAIT;
SELECT FLOAT (COUNT(インデクス第一構成列名))
     FROM 認可識別子.表識別子 WITHOUT LOCK NOWAIT;
ALTER TABLE 認可識別子.表識別子 CHANGE LOCK ROW;

注※

内部情報は12バイトです。したがって，インデクス第一構成列のほかに12バイトの文字列（CHAR(12)）を検索するSQLを発行したものとして見積もってください。

SQLが使用するメモリ所要量については，次の箇所を参照してください。

HiRDB/シングルサーバの場合

「SQL実行時に必要なメモリ所要量の計算式」

「SQL前処理時に必要なメモリ所要量の計算式」

HiRDB/パラレルサーバの場合

「SQL実行時に必要なメモリ所要量の計算式」

「SQL前処理時に必要なメモリ所要量の計算式」

19.2.9　データベース複写ユティリティ（pdcopy）実行時のメモリ所要量

データベース複写ユティリティ（pdcopy）実行時のメモリ所要量は，次に示す計算式で求めます。

(1)　HiRDB/シングルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）

シングルサーバ

88＋バックアップファイル数×2×MAX（32，pd_utl_buff_sizeの値）

＋バックアップファイル数×｛（バックアップ対象RDエリア数＋9）÷10｝×6

＋｛（全バックアップ対象RDエリア構成ファイル数＋25）÷16｝×8＋100

＋49＋バックアップファイル数×2×MAX（32，pd_utl_buff_sizeの値）＋64

＋バックアップファイル数×｛（バックアップ対象RDエリア数＋9）÷10｝×6

＋｛（全バックアップ対象RDエリア構成ファイル数＋25）÷16｝×8＋100

●バックアップファイルがこのサーバマシンにある場合に加算

＋63＋バックアップファイル数×（2×MAX（32，pd_utl_buff_sizeの値）×2

＋バックアップファイル数×｛（バックアップ対象RDエリア数＋9）÷10｝×6

＋｛（全バックアップ対象RDエリア構成ファイル数＋25）÷16｝×8＋100＋1024

●差分バックアップを取得する場合に加算

＋32×2＋↑（512＋128×バックアップ対象RDエリア数）÷32768↑×32

＋↑（256＋128×バックアップ対象RDエリア数＋a＋8×b）÷32768↑×32×2

ａ：-bオプションに指定するバックアップファイルの名称長（バイト）

複数のバックアップファイルを指定する場合は，合計の名称長になります。

ｂ：-bオプションに指定するバックアップファイルの数

(2)　HiRDB/パラレルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）

MGR

88＋バックアップファイル数×2×MAX（32，pd_utl_buff_sizeの値）

＋バックアップファイル数×｛（バックアップ対象RDエリア数＋9）÷10｝×6

＋｛（全バックアップ対象RDエリア構成ファイル数＋25）÷16｝×8＋100

●差分バックアップを取得する場合に加算

＋32×2＋↑（512＋128×バックアップ対象RDエリア数）÷32768↑×32

＋↑（256＋128×バックアップ対象RDエリア数＋a＋8×b）÷32768↑×32×2

DS | 49＋バックアップファイル数×2×MAX（32，pd_utl_buff_sizeの値）＋64 ＋バックアップファイル数×｛（バックアップ対象RDエリア数＋9）÷10｝×6 ＋｛（全バックアップ対象RDエリア構成ファイル数＋25）÷16｝×8＋100

BES

バックアップファイルがあるサーバマシン

63＋バックアップファイル数×2×MAX（32，pd_utl_buff_sizeの値）

×(バックアップ対象サーバ数＋1）

＋バックアップファイル数×｛（バックアップ対象RDエリア数＋9）÷10｝×6

＋｛（全バックアップ対象RDエリア構成ファイル数＋25）÷16｝×8＋100＋1024

ａ：-bオプションに指定するバックアップファイルの名称長（バイト）

複数のバックアップファイルを指定する場合は，合計の名称長になります。

ｂ：-bオプションに指定するバックアップファイルの数

19.2.10　データベース回復ユティリティ（pdrstr）実行時のメモリ所要量

データベース回復ユティリティ（pdrstr）実行時のメモリ所要量は，次に示す計算式で求めます。

(1)　HiRDB/シングルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）

シングルサーバ

65＋｛（回復対象RDエリア数＋9）÷10｝×6

＋｛（回復対象RDエリアの構成ファイル数＋25）÷16｝×8＋50

＋98＋2×MAX（32，pd_utl_buff_sizeの値）

＋｛（回復対象RDエリア数＋9）÷10｝×6＋c

＋｛（回復対象RDエリアの構成ファイル数＋25）÷16｝×8＋100

＋｛（回復対象RDエリア数＋99）÷100｝×5

●バックアップファイルがこのサーバマシンにある場合に加算

＋100＋2×MAX（32，pd_utl_buff_sizeの値）

＋｛（回復対象RDエリア数＋9）÷10｝×6

＋｛（回復対象RDエリアの構成ファイル数＋25）÷16｝×8＋100＋1024

●アンロードログファイル，又はシステムログファイルを入力する場合に加算

＋57＋2×MAX（32，pd_utl_buff_sizeの値）

＋｛（回復対象RDエリア数＋9）÷10｝×6＋64

＋｛（回復対象RDエリアの構成ファイル数＋25）÷16｝×8＋100＋d

＋0.6×回復対象RDエリア数＋ソート用ワークバッファサイズ（-yオプションの値）

●差分バックアップを使用した回復をする場合に加算

＋32×2＋↑（512＋128×バックアップ対象RDエリア数）÷32768↑×32

＋↑（256＋128×バックアップ対象RDエリア数＋a＋8×b）÷32768↑×32

＋↑（32×差分バックアップの継続回数）÷1024↑

ａ：-bオプションに指定するバックアップファイルの名称長（バイト）

複数のバックアップファイルを指定する場合は，合計の名称長になります。

ｂ：-bオプションに指定するバックアップファイルの数

ｃ：書き込みバッファサイズを指定している場合はMAX（64，書き込みバッファサイズ），指定していない場合は60

書き込みバッファサイズは-Yオプションの指定値になります。

ｄ：

32ビットモードの場合：

640＋8×↑最大同時実行トランザクション数÷100↑

＋5×↑回復対象RDエリア数÷100↑

＋回復対象RDエリアの最大ページサイズ×54

＋9×ロールバック対象トランザクション数

＋0.02×回復対象RDエリアの構成ファイル数

＋↑（304＋36＋4×（回復対象RDエリア数−1）

　　＋352＋304×（回復対象RDエリア数−1）

　　＋96＋4×（回復対象RDエリア数−1）

　　＋384＋320×（回復対象RDエリア数−1）＋16）÷1024↑

64ビットモードの場合：

640＋11×↑最大同時実行トランザクション数÷100↑

＋6×↑回復対象RDエリア数÷100↑

＋回復対象RDエリアの最大ページサイズ×54

＋9×ロールバック対象トランザクション数

＋0.03×回復対象RDエリアの構成ファイル数

＋↑（304＋40＋8×（回復対象RDエリア数−1）

　　＋400＋336×（回復対象RDエリア数−1）

　　＋168＋8×（回復対象RDエリア数−1）

　　＋408＋336×（回復対象RDエリア数−1）＋16）÷1024↑

(2)　HiRDB/パラレルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）

MGR

65＋｛（回復対象RDエリア数＋9）÷10｝×6

＋｛（回復対象RDエリアの構成ファイル数＋25）÷16｝×8＋50

●差分バックアップを使用した回復をする場合に加算

＋32×2＋↑（512＋128×バックアップ対象RDエリア数）÷32768↑×32

＋↑（256＋128×バックアップ対象RDエリア数＋a＋8×b）÷32768↑×32

＋↑（32×差分バックアップの継続回数）÷1024↑

DS

35＋2×MAX（32，pd_utl_buff_sizeの値）＋100

＋98＋2×MAX（32，pd_utl_buff_sizeの値）

＋｛（回復対象RDエリア数＋9）÷10｝×6＋c

＋｛（回復対象RDエリアの構成ファイル数＋25）÷16｝×8＋100

＋｛（回復対象RDエリア数＋99）÷100｝×5

●アンロードログファイル，又はシステムログファイルを入力する場合に加算

＋57＋2×MAX（32，pd_utl_buff_sizeの値）

＋｛（回復対象RDエリア数＋9）÷10｝×6＋64

＋｛（回復対象RDエリアの構成ファイル数＋25）÷16｝×8＋100＋d

＋0.6×回復対象RDエリア数＋ソート用ワークバッファサイズ（-yオプションの値）

BES

98＋2×MAX（32，pd_utl_buff_sizeの値）

＋｛（回復対象RDエリア数＋9）÷10｝×6＋c

＋｛（回復対象RDエリアの構成ファイル数＋25）÷16｝×8＋100

＋｛（回復対象RDエリア数＋99）÷100｝×5

●アンロードログファイル，又はシステムログファイルを入力する場合に加算

＋57＋2×MAX（32，pd_utl_buff_sizeの値）

＋｛（回復対象RDエリア数＋9）÷10｝×6＋64

＋｛（回復対象RDエリアの構成ファイル数＋25）÷16｝×8＋100＋d

＋0.6×回復対象RDエリア数＋ソート用ワークバッファサイズ(-yオプションの値）

バックアップファイルがあるサーバマシン | 100＋2×MAX（32，pd_utl_buff_size）×回復対象サーバ数 ＋｛（回復対象RDエリア数＋9）÷10｝×6 ＋｛（回復対象RDエリア構成ファイル数＋25）÷16｝×8＋100＋1024

ａ：-bオプションに指定するバックアップファイルの名称長（バイト）

複数のバックアップファイルを指定する場合は，合計の名称長になります。

ｂ：-bオプションに指定するバックアップファイルの数

ｃ：書き込みバッファサイズを指定している場合はMAX（64，書き込みバッファサイズ），指定していない場合は60

書き込みバッファサイズは-Yオプションの指定値になります。

ｄ：

32ビットモードの場合：

640＋8×↑最大同時実行トランザクション数÷100↑

＋5×↑回復対象RDエリア数÷100↑

＋回復対象RDエリアの最大ページサイズ×54

＋9×ロールバック対象トランザクション数

＋0.02×回復対象RDエリアの構成ファイル数

＋↑（304＋36＋4×（回復対象RDエリア数−1）

　　＋352＋304×（回復対象RDエリア数−1）

　　＋96＋4×（回復対象RDエリア数−1）

　　＋384＋320×（回復対象RDエリア数−1）

　　＋16＋32×回復対象RDエリア数）÷1024↑

64ビットモードの場合：

640＋11×↑最大同時実行トランザクション数÷100↑

＋6×↑回復対象RDエリア数÷100↑

＋回復対象RDエリアの最大ページサイズ×54

＋9×ロールバック対象トランザクション数

＋0.03×回復対象RDエリアの構成ファイル数

＋↑（304＋40＋8×（回復対象RDエリア数−1）

　　＋400＋336×（回復対象RDエリア数−1）

　　＋168＋8×（回復対象RDエリア数−1）

　　＋408＋336×（回復対象RDエリア数−1）

　　＋16＋48×回復対象RDエリア数）÷1024↑

19.2.11　ディクショナリ搬出入ユティリティ（pdexp）実行時のメモリ所要量

ディクショナリ搬出入ユティリティ（pdexp）実行時のメモリ所要量は，次に示す計算式で求めます。

(1)　HiRDB/シングルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）
32ビットモード | SDS | 1307＋6.7×↑CTL÷100↑＋0.07×CTL
搬出ファイルのあるホスト | 4499＋0.07×CTL＋0.11×CHK＋1.5×FKY＋CSZ＋0.5×CMN＋0.01×（CHK＋FKY＋CMN＋DIV＋10）＋0.6×DIV＋DEF＋0.06×LOB＋0.2×TBL＋SQL＋8791
64ビットモード | SDS | 1494＋6.7×↑CTL÷100↑＋0.07×CTL
搬出ファイルのあるホスト | 4582＋0.07×CTL＋0.11×CHK＋1.5×FKY＋CSZ＋0.5×CMN＋0.01×（CHK＋FKY＋CMN＋DIV＋10）＋0.6×DIV＋DEF＋0.06×LOB＋0.2×TBL＋SQL＋8791

(2)　HiRDB/パラレルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）
32ビットモード | MGR | 1714＋6.7×↑CTL÷100↑＋0.07×CTL
搬出ファイルのあるホスト | 4907＋0.07×CTL＋0.11×CHK＋1.5×FKY＋CSZ＋0.5×CMN＋0.01×（CHK＋FKY＋CMN＋DIV＋10）＋0.6×DIV＋DEF＋0.06×LOB＋0.2×TBL＋SQL＋8791
64ビットモード | MGR | 2016＋6.7×↑CTL÷100↑＋0.07×CTL
搬出ファイルのあるホスト | 5293＋0.07×CTL＋0.11×CHK＋1.5×FKY＋CSZ＋0.5×CMN＋0.01×（CHK＋FKY＋CMN＋DIV＋10）＋0.6×DIV＋DEF＋0.06×LOB＋0.2×TBL＋SQL＋8791

(3)　計算式で使用する変数

CMN：列数

CHK：検査制約数

CSZ：検査制約の検索条件の合計サイズ（SQL_TABLES表のCHK_SOURCE_LENの値）（単位：バイト）

CTL：制御文ファイルに指定された制御数

DEF：DEFAULT句の最大定義長（単位：バイト）

DIV：分割条件数

FKY：外部キーの数

LOB：LOB格納用ＲＤエリア数

SQL：次のSQL文が使用するメモリ所要量

表の搬出入の場合：CREATE TABLE文

プロシジャの搬出入の場合：CREATE PROCEDURE文

トリガの搬出入の場合：CREATE TRIGGER文

これらのメモリ所要量については，「SQL実行時に必要なメモリ所要量の計算式」，及び「SQL前処理時に必要なメモリ所要量の計算式」を参照してください。

TBL：実際に搬出入する表，プロシジャ，トリガ数（プロシジャ，トリガの場合はCTLと同じ）

19.2.12　アクセスパス表示ユティリティ（pdvwopt）実行時のメモリ所要量

アクセスパス表示ユティリティ（pdvwopt）実行時のメモリ所要量は，次に示す計算式で求めます。

条件 | メモリ所要量の計算式（単位：キロバイト）
HiRDB/シングルサーバの場合 | a Σ bi×0.7＋200 i=1
HiRDB/パラレルサーバの場合 | FES

a：SQL中の問合せ数

bi：問合せ中の表数

19.2.13　リバランスユティリティ（pdrbal）実行時のメモリ所要量

リバランスユティリティ（pdrbal）実行時のメモリ所要量は，次に示す計算式で求めます。

(1)　HiRDB/シングルサーバの場合

メモリ所要量の計算式（単位：キロバイト）

8756※３＋536＋0.02×列数＋0.2×移動先RDエリア数

＋1.7×移動元RDエリア数＋0.26×移動先RDエリア数×インデクス数

＋（0.09＋↑平均index文ファイル長÷1024↑）×index文数

＋（0.02＋↑平均ディレクトリ長÷1024↑）×（idxwork文数＋sort文数）

＋↑（制御情報ファイル長＋実行結果ファイル長）÷1024↑

＋0.05×列数＋0.05×RDエリア数＋0.15×インデクス数

＋0.05×インデクス格納RDエリア数

＋550×1024＋ソートワークサイズ※１

●-nオプションを指定した場合

＋RDエリアのページ長※２×一括入出力バッファ面数×ｙ

●対象表にLOB列がある場合

＋64＋0.01×LOB列数＋0.18×移動先RDエリア数

＋0.09×移動元RDエリア数＋0.08×LOB格納RDエリア数

●対象表にBINARY列がある場合

＋33×（BINARY列数×移動先RDエリア数×移動元RDエリア数）

＋BINARY列の場合に使用するバッファ長※５

●対象表にプラグインが提供する抽象データ型がある場合

＋40＋（0.27＋2×抽象データ型長）×抽象データ型の列数

＋0.3×unld_func指定数

＋（128＋0.11×LOB属性数＋0.1×unld_func指定関数数

＋0.07×抽象データ型属性数）×抽象データ型の列数

＋（33×BINARY属性数×移動先RDエリア数×移動元RDエリア数）×2

＋0.01×プラグインインデクス数＋0.19×unld_func文数

＋（↑平均unld_func文長÷1024↑×unld_func文数）

＋（↑平均reld_func文長÷1024↑×reld_func文数）

＋抽象データ型列数×1＋（LOB属性数×0.05）×RDエリア数

＋データ型プラグイン数×10＋プラグインインデクス数×10

＋プラグインのメモリ所要量

●インデクス作成方法に，インデクス一括作成モード又はインデクス情報出力モードを指定していて，次の条件を満たす場合

　・表分割数×インデクス定義数＞プロセスのオープン数の上限-576

＋2048

●圧縮列がある場合

＋圧縮分割サイズ※４×z＋RDエリアのページ長※２

ｙ：次に示すどちらかの値を代入してください。

FIXハッシュ分割表にリバランス機能を使用した場合

（↑1024÷表全体の格納RDエリア数↑）×該当サーバ内の表格納RDエリア数

そのほかの場合

1

z：次に示すどちらかの値を代入してください。

占有モード（-k exclusive）の場合：2

共有モード（-k share）の場合：1

注※1

インデクスの一括作成時（-i c又は省略）に加算します。

注※2

表を横分割したRDエリアごとにページ長が異なる場合は，ページ長の最大値で計算してください。

注※3

64ビットモードの場合は14272です。

注※4

圧縮分割サイズは，全圧縮列中の最大値で計算してください。

注※5

BINARY列の場合に使用するバッファ長は，次の値を使用してください。

占有モードの場合

0

共用モードの場合

n

Σ（定義長i）

i=1

n：BINARY列数

(2)　HiRDB/パラレルサーバの場合

条件 | メモリ所要量の計算式（単位：キロバイト）

MGR

1498※３＋2＋0.05×列数＋0.05×RDエリア数＋0.15×インデクス数

＋0.05×インデクス格納RDエリア数

＋（0.09＋↑平均index文ファイル長÷1024↑）×index文数

＋（0.02＋↑平均ディレクトリ長÷1024↑）×（idxwork文数＋sort文数）

＋↑(制御情報ファイル長＋実行結果ファイル長）÷1024↑

●対象表にLOB列がある場合

＋0.08×LOB格納RDエリア数

●対象表にプラグインが提供する抽象データ型がある場合

＋0.19×unld_func文数

＋（↑平均unld_func文長÷1024↑×unld_func文数）

＋（↑平均reld_func文長÷1024↑×reld_func文数）

DS

1455※４＋32＋0.33×移動先BES数＋0.3×移動元BES数

＋0.2×移動先RDエリア数＋0.22×移動元RDエリア数＋0.34×FES数

＋（0.09＋↑平均index文ファイル長÷1024↑）×index文数

＋（0.02＋↑平均ディレクトリ長÷1024↑）×（idxwork文数＋sort文数）＋0.05×列数＋0.05×RDエリア数＋0.15×インデクス数

＋0.05×インデクス格納RDエリア数

●対象表にLOB列がある場合

＋0.08×LOB格納RDエリア数

●対象表にBINARY列がある場合

＋33×（BINARY列数×移動先RDエリア数×移動元RDエリア数）

●対象表にプラグインが提供する抽象データ型がある場合

＋0.01×移動先BES数＋0.19×unld_func文数

＋（↑平均unld_func文長÷1024↑×unld_func文数）

＋（↑平均reld_func文長÷1024↑×reld_func文数）

＋抽象データ型列数×1＋（LOB属性数×0.05）×RDエリア数

＋データ型プラグイン数×10＋プラグインインデクス数×10

BES

6601※５＋50＋（517＋0.01×列数）×移動先BES数

＋（33＋0.01×列数）×移動元BES数＋0.2×移動先RDエリア数

＋1.7×移動元RDエリア数＋0.01×列数

＋0.26×移動先RDエリア数×インデクス数

＋（0.09＋↑平均index文ファイル長÷1024↑）×index文数

＋（0.02＋↑平均ディレクトリ長÷1024↑）×（idxwork文数＋sort文数）

＋0.05×列数＋0.05×RDエリア数＋0.15×インデクス数

＋0.05×インデクス格納RDエリア数

＋550×1024＋ソートワークサイズ※１

●-nオプションを指定した場合

＋RDエリアのページ長※２×一括入出力バッファ面数×ｙ

●対象表にLOB列がある場合

＋32＋0.01×LOB列数＋（32＋0.01×LOB列数）×移動先BES数

＋0.18×移動先RDエリア数＋0.1×移動元RDエリア数

＋0.08×LOB格納RDエリア数

●対象表にBINARY列がある場合

＋33×（BINARY列数×移動先RDエリア数×移動元RDエリア数）

＋BINARY列の場合に使用するバッファ長※７

●対象表にプラグインが提供する抽象データ型がある場合

＋40＋（0.27＋2×抽象データ型長）×抽象データ型の列数

＋0.3×unld_func指定数

＋｛（64＋0.05×LOB属性数）×抽象データ型列数｝×移動先BES数

＋｛（64＋0.01×unld_func指定関数数＋0.07×抽象データ型属性数

＋0.05×LOB属性数）×抽象データ型列数｝×移動元BES数

＋（33×BINARY属性数×移動先RDエリア数×移動元RDエリア数）×2

＋ 0.01×プラグインインデクス数＋0.19×unld_func文数

＋（↑平均unld_func文長÷1024↑×unld_func文数）

＋（↑平均reld_func文長÷1024↑×reld_func文数）

＋抽象データ型列数×1＋（LOB属性数×0.05）×RDエリア数

＋データ型プラグイン数×10＋プラグインインデクス数×10

＋プラグインのメモリ所要量

●インデクス作成方法に，インデクス一括作成モード又はインデクス情報出力モードを指定していて，次の条件を満たす場合

　・表分割数×インデクス定義数＞プロセスのオープン数の上限-576

＋2048

●圧縮列がある場合

＋圧縮分割サイズ※６×z＋RDエリアのページ長※２

ｙ：次に示すどちらかの値を代入してください。

FIXハッシュ分割表にリバランス機能を使用した場合

（↑1024÷表全体の格納RDエリア数↑）×該当サーバ内の表格納RDエリア数

そのほかの場合

1

z：次に示すどちらかの値を代入してください。

占有モード（-k exclusive）の場合：2

共有モード（-k share）の場合：1

注※1

インデクスの一括作成時（-i c又は省略）に加算します。

注※2

表を横分割したRDエリアごとにページ長が異なる場合は，ページ長の最大値で計算してください。

注※3

64ビットモードの場合は4660です。

注※4

64ビットモードの場合は15830です。

注※5

64ビットモードの場合は11804です。

注※6

圧縮分割サイズは，全圧縮列中の最大値で計算してください。

注※7

BINARY列の場合に使用するバッファ長は，次の値を使用してください。

占有モードの場合

　m

（Σ（定義長i）

　i=1

　n

＋Σ（定義長i×9））×移動先BES数

　i=1

m：圧縮指定を指定していないBINARY列の数

n：圧縮指定を指定しているBINARY列の数

共用モードの場合

n

Σ（定義長i）×移動先BES数

i=1

n：BINARY列数

19.2.14　空きページ解放ユティリティ（pdreclaim）及びグローバルバッファ常駐化ユティリティ（pdpgbfon）実行時のメモリ所要量

空きページ解放ユティリティ（pdreclaim）及びグローバルバッファ常駐化ユティリティ（pdpgbfon）実行時のメモリ所要量は，次に示す計算式で求めます。

条件 | メモリ所要量の計算式 （単位：キロバイト）
HiRDB/シングルサーバの場合（32ビットモードの場合） | 800＋W
HiRDB/シングルサーバの場合（64ビットモードの場合） | 1897＋W
HiRDB/パラレルサーバの場合 （32ビットモードの場合） | システムマネジャ | 800＋X
-sオプションで指定したサーバ※１ | Y
バックエンドサーバ※２ | Z
HiRDB/パラレルサーバの場合 （64ビットモードの場合） | システムマネジャ | 1953＋X
-sオプションで指定したサーバ※１ | Y
バックエンドサーバ※２ | Z

注※1

-sオプション省略時は，処理対象表格納RDエリアを1個目に定義したサーバです。

注※2

バックエンドサーバが複数ある場合は，バックエンドサーバ数だけメモリ所要量を加算します。

W：データベース再編成ユティリティ（pdrorg）実行時のシングルサーバのメモリ所要量

X：データベース再編成ユティリティ（pdrorg）実行時のMGRのメモリ所要量

Y：データベース再編成ユティリティ（pdrorg）実行時のDSのメモリ所要量

Z：データベース再編成ユティリティ（pdrorg）実行時のBESのメモリ所要量

データベース再編成ユティリティ（pdrorg）実行時のメモリ所要量については，「データベース再編成ユティリティ（pdrorg）実行時のメモリ所要量」を参照してください。

19.2.15　整合性チェックユティリティ（pdconstck）実行時のメモリ所要量

整合性チェックユティリティ（pdconstck）実行時のメモリ所要量は，次に示す計算式で求めます。

条件 | メモリ所要量の計算式 （単位：キロバイト）
HiRDB/シングルサーバの場合 | 32ビットモードの場合 | 11664＋α
64ビットモードの場合 | 22696＋α
HiRDB/パラレルサーバの場合 | 32ビットモードの場合 | MGR | 7577＋α
DS | 5772＋β
64ビットモードの場合 | MGR | 9240＋α
DS | 12776＋β

α：次に示す計算式から求められる値

2175

＋0.14×列数

＋0.09×表格納RDエリア数

＋0.23×インデクス数

＋0.09×インデクス格納RDエリア数

＋0.09×LOB列格納RDエリア数

外部キー数

＋Σ（42＋0.47×外部キー構成列数r）

r=1

検査制約数

＋Σ（5＋0.29×探索条件中の列数c＋0.85

c=1

×探索条件中のAND及びORの数c＋探索条件長c）

β：次に示す計算式から求められる値

0.2

＋0.02×表格納RDエリア数

＋0.02×インデクス格納RDエリア数

＋0.02×LOB列格納RDエリア数

19.2.16　パラレルローディング（pdparaload）実行時のメモリ所要量

パラレルローディング（pdparaload）実行時のメモリ所要量は，次に示す計算式で求めます。

パラレルローディング実行時のメモリ所要量（単位：キロバイト）
　　＝1000＋pdparaload制御文ファイルの容量＋10＋10＋R
　　　　R
　　　＋Σ（RDエリア単位のデータロード実行に必要なメモリ容量i）
　　　 i=1

R：表を構成するRDエリア数

注

pdparaloadコマンドは，表を構成するRDエリアの数だけ，内部でRDエリア単位のデータロード（pdload）を実行します。そのため，pdparaloadは，RDエリア単位のデータロード実行に必要なメモリ所要量を，表を構成するRDエリア数分使用します。RDエリア単位のデータロード実行に必要なメモリ所要量については，「データベース作成ユティリティ（pdload）実行時のメモリ所要量」を参照してください。

20　リソース数に関連する環境変数の見積もり

この章では，リソース数に関連する環境変数の見積もり方法について説明します。

20.1　リソース数に関連する環境変数

リソース数に関連する環境変数の設定について説明します。Windowsにはないメッセージキュー，セマフォ，及び共用メモリの機能を使用するための設定で，HiRDBが自動的に計算し，設定します。

20.1.1　見積もり

通常，HiRDBが自動的に計算するため，見積もりは必要ありません。

ただし，次に示す場合は，ユニット単位で使用するリソース数を見積もってください。見積もり方法は，次節以降で説明します。

ユニット内で使用するRDエリア数が3000個を超える場合，又はプリフェッチ機能を使用する場合は，メッセージキューテーブル数を見積もってください。

ユニット内で使用するRDエリア数が3000個を超える場合，又はHiRDB/パラレルサーバでシステム定義pd_dbbuff_modifyオペランドの値にYを指定している場合は，セマフォ識別子数を見積もってください。

次の条件を満たす場合は，共用メモリ使用数を見積もってください。

↑グローバルバッファが使用する共用メモリの総量÷SHMMAX↑＞16

なお，グローバルバッファが使用する共用メモリについては，次の箇所を参照してください。

HiRDB/シングルサーバの場合：「グローバルバッファが使用する共用メモリの計算式」

HiRDB/パラレルサーバの場合：「グローバルバッファが使用する共用メモリの計算式」

20.1.2　設定方法

見積もりが必要となった場合，見積った値を次に示す方法で設定します。設定方法には，ユニット単位とOS単位の二つがありますが，通常は，見積もりが必要なユニットに対してだけユニット単位で設定してください。

ユニット単位で設定する

pdntenvコマンドの-srオプションで設定します。OS内に複数のユニットが存在する場合に，各ユニットに適した値を設定できます。また，OS単位の設定よりも優先されます。

OS単位で設定する

Windowsのシステム環境変数として設定します。OS内に複数のユニットが存在するマルチHiRDB構成の場合に，見積もりが最大となるユニットの値を指定することで，同じ値で一括設定することができます。ただし，この方法で設定すると，HiRDBが自動的に計算した値が使用されません。また，最大値を必要としないユニットは必要以上のリソースを使用することになります。

なお，設定を反映させるためには，OSの再起動が必要となります。

リソース種別とそれぞれの設定方法で指定する項目の対応関係を，次の表に示します。pdntenvコマンドの詳細については，マニュアル「HiRDB コマンドリファレンス」を参照してください。

表20‒1　リソース種別と設定方法ごとの指定項目

リソース種別 | ユニット単位 （pdntenv -srオプションで指定するリソース名） | OS単位 （システム環境変数名）
メッセージキュー識別子数 | msgmni | PDUXPLMSGMNI
メッセージキューテーブル数 | msgtql | PDUXPLMSGTQL
セマフォ識別指数 | semmax | PDUXPLSEMMAX
共用メモリ使用数 | shmmax | PDUXPLSHMMAX

なお，上記の設定を行った場合でも，設定した値が必要量に対して不足するときは，設定が有効にならないことがあります。詳細は，「バージョンアップ時の注意点」の「リソース数に関連する環境変数を設定している場合」を参照してください。

20.1.3　設定の削除方法

見積もりが必要な条件に該当しない場合で，HiRDBが自動的に計算した値が有効にならない※ときは，既にリソース数が設定されています。HiRDBが自動的に計算した値を有効にするためには，次の手順で設定を削除してください。

pdntenvコマンドの-srオプションで設定を削除します。

システム環境変数を削除して，OSを再起動します。

注※

HiRDBが自動的に計算した値が有効になっているかどうかは，pdntenvコマンドで現在の設定内容を表示することで確認できます。

pdntenvコマンドの詳細は，マニュアル「HiRDB コマンドリファレンス」を参照してください。

20.1.4　HiRDBが自動計算時に用いる計算式

HiRDBが自動計算する際に用いる計算式を，次の表に示します。自動計算した結果が不当に大きいなどの事象が発生した場合は，計算式で用いているシステム定義の指定値が適切でないおそれがあります。その場合は，定義内容を確認してください。

なお，計算結果からメモリ所要量を計算したい場合は，次の箇所を参照してください。

HiRDB/シングルサーバの場合：「共用メモリの計算式」

HiRDB/パラレルサーバの場合：「共用メモリの計算式」

表20‒2　HiRDBが自動計算に用いる計算式

リソース種別 | HiRDB/シングルサーバ | HiRDB/パラレルサーバ
メッセージキュー識別子数 | 50（固定値） | （5×サーバ数）＋57
メッセージキューテーブル数 | b＋3610 | （b×ユニット数）＋3500＋（110×m）
セマフォ識別指数 | Max（64，↑c÷64↑＋g＋10） | Max（64，50＋8×m）
共用メモリ使用数 | Max（4096，20×（e＋50）） | Max（4096，20×（e＋50））

b：pd_max_usersオペランドの値

c：pdbufferオペランドの数

e：pd_max_server_processオペランドの値

g：pd_dbbuff_modifyオペランドの値がYの場合はpd_max_add_dbbuff_noオペランドの値，pd_dbbuff_modifyオペランドの値がNの場合は0

m：ユニット内のバックエンドサーバ数＋ディクショナリサーバ数＋ゲストBES数

20.1.5　バージョンアップ時の注意点

(1)　リソース数に関連する環境変数を省略している場合

自動計算をサポートしていないバージョン09-50より前のバージョンでは，設定を省略した場合，各バージョンの省略値で動作しています。バージョンアップすることで自動計算するようになりますが，自動計算結果がバージョンアップ前の省略値と異なる場合があるため，バージョンアップ前後でメモリ使用量が変わることがあります。バージョンアップによる値の違いを確認し，必要なメモリを準備するなどの対処をしてください。各バージョンの省略値を次の表に示します。

なお，通常は自動計算された値での運用を強く推奨しますが，バージョンアップに際してメモリ使用量の変更が許容できない場合などは，次に示す値を参考にして，「設定方法」に示す方法で設定してください。ただし，設定にあたっては，次の「リソース数に関連する環境変数を設定している場合」の内容も必ず確認してください。

表20‒3　指定を省略した場合のリソース数に関連する環境変数の値

リソース種別 | バージョン09-50以降の値 | バージョン09-50より前のバージョンでの省略値 | バージョン09-04-12より前のバージョンでの省略値
メッセージキュー識別子数 | 自動計算値※ | ●32ビットモードの場合：50 ●64ビットモードの場合：100 | 50
メッセージキューテーブル数 | 自動計算値※ | ●32ビットモードの場合：80 ●64ビットモードの場合：2,048 | 80
セマフォ識別子数 | 自動計算値※ | 64 | 64
共用メモリ使用数 | 自動計算値※ | ●32ビットモードの場合：4,096 ●64ビットモードの場合：16,384 | 4,096

注※　「HiRDBが自動計算時に用いる計算式」を用いて計算した値です。

(2)　リソース数に関連する環境変数を設定している場合

リソース数に関連する環境変数を設定している場合，基本的には設定値が有効となります。ただし，次のリソース種別の設定値が，自動計算した結果に対して不足する場合は，設定値を無効にしてHiRDBが自動計算した値で動作します。

メッセージキュー識別子数

共用メモリ使用数

設定値を無効にした場合，HiRDB起動時にKFPS05628-Wメッセージを出力します。

上記以外のリソース種別では，自動計算した結果に関係なく設定値が有効となるため，不足することがないか十分確認してください。

バージョンアップ前に問題なく動作していた設定値が，上記に該当して無効となる場合，自動計算で使用するpd_max_server_process，及びpd_max_add_dbbuff_noオペランドの指定値が，運用上必要な値に比べて大き過ぎるなど，適切ではないおそれがあります。この場合，各オペランドの指定値を適切な値に設定し直すことで，バージョンアップ前の設定値と同等の自動計算結果を得られることがあります。

20.2　HiRDB/シングルサーバの場合

20.2.1　見積もり式

見積もり式を次の表に示します。

計算結果が環境変数の省略値より大きい場合は，その環境変数に計算結果を設定してください。設定しないとHiRDBを開始できない，又はユティリティを実行できないなどの問題が発生します。

表20‒4　リソース数に関連する環境変数に設定する値（HiRDB/シングルサーバの場合）

種別 | 計算式 | 対応する環境変数 | 設定範囲
メッセージキュー識別子数（単位：個） | Max（50，17＋a＋30） | PDUXPLMSGMNI | 50〜3,600,000※1，2
メッセージキューテーブル数（単位：個） | Max（80，b＋i＋c＋j＋d×2＋f＋1＋↓pd_trn_rcvmsg_store_buflenオペランドの値÷72↓）※3 | PDUXPLMSGTQL | 80〜65,536※1，2
セマフォ識別子数（単位：個） | Max（64，↑c÷64↑＋g＋10） | PDUXPLSEMMAX | 64〜2,147,483,647※1
共用メモリ使用数（単位：セグメント） | Max（4096，（4＋h）×（e＋50）） | PDUXPLSHMMAX | 4,096〜2,147,483,647※1

注※1

設定範囲より小さい値を設定した場合，HiRDBが最小値に切り上げます。

注※2

設定範囲より大きい値を設定した場合，HiRDBが最大値に切り下げます。

注※3

c＋j＋d×2＋fの合計値が3,610以下の場合は，メッセージキューテーブル数に対応する環境変数の設定は必要ありません。

ａ：pd_max_ard_processオペランドが1以上の場合は1，pd_max_ard_processオペランドが0の場合は0となります。

ｂ：pd_max_usersオペランドの値

ｃ：pdbufferオペランドの定義数※1

ｄ：pd_spd_syncpoint_skip_limitオペランドに0以外の値を指定している場合は，pd_spd_syncpoint_skip_limitオペランドの指定値で見積もります。pd_spd_syncpoint_skip_limitオペランドに0を指定，又はオペランドを省略している場合は，マニュアル「HiRDB システム運用ガイド」の「UAPの状態監視（シンクポイントダンプ有効化のスキップ回数監視機能）」の「全システムログファイルの容量から計算する方法」を参照して計算してください。

ｅ：pd_max_server_processオペランドの値

ｆ：pdbuffer -m指定値の合計

ｇ：pd_dbbuff_modifyオペランドの値がYの場合はpd_max_add_dbbuff_noオペランドの値，pd_dbbuff_modifyオペランドの値がNの場合は0

ｈ：↑（グローバルバッファが使用する共用メモリの総量※2÷SHMMAXの値）↑

ｉ：pd_utl_exec_modeオペランドが1の場合は，pd_max_usersオペランドの値となります。

pd_utl_exec_modeオペランドが0の場合は，次に示す値となります。

Min（947，pd_max_usersオペランドの値）

ｊ：実行するpdload，pdrorg，pdrbal，ログレスUAPの最大同時実行数＋1

注※1

pdbufferに-Dオプションの指定がない場合は1，-Dオプションの指定がある場合は分割数を合計したものがpdbufferオペランドの定義数となります。

注※2

グローバルバッファが使用する共用メモリについては，「グローバルバッファが使用する共用メモリの計算式」を参照してください。

20.2.2　共用メモリの計算式

メッセージキュー，セマフォ，及び共用メモリの機能を使うことによって使用される共用メモリの計算式を次の表に示します。

表20‒5　共用メモリの計算式

共用メモリを使う機能 | 計算式（単位：バイト）

メッセージキュー

●32ビットモードの場合

（（（（16384＋（PDUXPLMSGTQL×24））＋15）÷16）×16＋384）＋（（PDUXPLMSGMNI−1）×64）＋（（PDUXPLMSGTQL−1）×32）＋Max（0，8×（PDUXPLMSGTQL−2048））

●64ビットモードの場合

（（（（16384＋（PDUXPLMSGTQL×24））＋15）÷16）×16＋408）＋（（PDUXPLMSGMNI−1）×124）＋（（PDUXPLMSGTQL−1）×64）

セマフォ

●32ビットモードの場合

99136＋PDUXPLSEMMAXの設定値×6192

●64ビットモードの場合

164968＋PDUXPLSEMMAXの設定値×10304

共用メモリ（共用メモリを使用する場合，管理用の共用メモリが必要になる）

●32ビットモードの場合

16＋PDUXPLSHMMAXの設定値×40

●64ビットモードの場合

24＋PDUXPLSHMMAXの設定値×64

20.3　HiRDB/パラレルサーバの場合

20.3.1　見積もり式

見積もり式を次の表に示します。

計算結果が環境変数の省略値より大きい場合は，その環境変数に計算結果を設定してください。設定しないとHiRDBを開始できない，又はユティリティを実行できないなどの問題が発生します。

表20‒6　リソース数に関連する環境変数に設定する値（HiRDB/パラレルサーバの場合）

種別 | 計算式 | 対応する環境変数 | 設定範囲

メッセージキュー識別子数（単位：個）

Max（50，

b

Σ ｛Vi｝＋2×a＋4×b

i=1

＋c＋d＋e＋26＋1＋m）

PDUXPLMSGMNI

50〜3,600,000※1，2

メッセージキューテーブル数（単位：個） | Max（80，h×n＋q＋A＋B＋1＋↓pd_trn_rcvmsg_store_buflenオペランドの指定値÷72↓） | PDUXPLMSGTQL | 80〜65,536※1，2

セマフォ識別子数（単位：個）

●影響分散スタンバイレス型系切り替え機能を使用していない場合

b

Σ ｛↑（Si＋Ti＋Ui）÷64↑＋Zi＋Wi｝

i=1

＋6×b＋2＋f

●影響分散スタンバイレス型系切り替え機能を使用している場合

b

Σ ｛↑｛Yi×（j＋k）｝÷64↑＋Wi｝

i=1

＋6×b＋2＋f

PDUXPLSEMMAX

64〜2,147,483,647※1

共用メモリ使用数（単位：セグメント） | Max（4096，（4＋z）×（g＋50）） | PDUXPLSHMMAX | 4,096〜2,147,483,647※1

注※1

設定範囲より小さい値を設定した場合，HiRDBが最小値に切り上げます。

注※2

設定範囲より大きい値を設定した場合，HiRDBが最大値に切り下げます。

注※3

グローバルバッファの動的変更機能を使用する場合に加算してください。セキュリティ監査機能使用時はさらに1を加算してください。

注※4

インメモリデータ処理を行う場合に加算してください。

A：次の値を代入してください。

m
Σ｛
i=1
　　サーバiに割り当てたグローバルバッファプール数※1
　　＋サーバiのシンクポイントダンプ有効化スキップ回数※2×2
　　＋サーバiで実行するpdload，pdrorg，pdrbal，ログレスUAPの最大同時実行数＋1
｝

m：
ユニット内のバックエンドサーバ数＋ユニット内のディクショナリサーバ数＋ユニット内のゲストBES数※3
注※1
pdbuflsコマンドで表示されるバッファプール名をサーバ単位に集計することで確認できます。
注※2
pd_spd_syncpoint_skip_limitオペランドに0以外の値を指定している場合は，pd_spd_syncpoint_skip_limitオペランドの指定値で見積もります。pd_spd_syncpoint_skip_limitオペランドに0を指定，又はオペランドを省略している場合は，マニュアル「HiRDB システム運用ガイド」の「UAPの状態監視（シンクポイントダンプ有効化のスキップ回数監視機能）」の「全システムログファイルの容量から計算する方法」を参照して計算してください。
注※3
影響分散スタンバイレス型系切り替えを適用している場合に加算します。

B：pd_max_ard_processオペランドに1以上を指定した場合に加算します。次の値を代入してください。

m
Σ｛
i=1
　　サーバiに割り当てたグローバルバッファプールのpdbuffer -m指定値の合計
｝

m：
ユニット内のバックエンドサーバ数＋ユニット内のディクショナリサーバ数＋ユニット内のゲストBES数※
注※
影響分散スタンバイレス型系切り替えを適用している場合に加算します。

ａ：サーバマシン内のフロントエンドサーバ数

ｂ：サーバマシン内のディクショナリサーバ数＋p

ｃ：フロントエンドサーバの場合は4，それ以外は0

ｄ：ディクショナリサーバの場合は8，それ以外は0

ｅ：バックエンドサーバの場合は16＋p，それ以外は0

ｆ：系切り替え機能使用時に加算します。次に示す表から値を求めてください。

条件 | fの値
pd_ha_acttype=monitor（又は省略） | 0
pd_ha_acttype=server | pd_ha_agent=standbyunit | 1
pd_ha_agent=server | 1
pd_ha_agent=activeunits | 0
pd_ha_agent を省略 | pd_ha_server_process_standby=Y （又は省略） | 1
pd_ha_server_process_standby=N | 0

ｇ：pd_max_server_processオペランドの値

ｈ：pd_max_usersオペランドの値

ｊ：ホストBES数

ｋ：ゲストBES数

ｍ：システムマネジャユニットがある場合は3，ない場合は0

ｎ：ユニット内のフロントエンドサーバ数＋ユニット内のバックエンドサーバ数＋ユニット内のディクショナリサーバ数＋pd_ha_max_act_guest_serversオペランドの値

pd_ha_max_act_guest_serversオペランドの値は影響分散スタンバイレス型系切り替えを適用している場合に加算します。

ｐ：次のどちらかの値

影響分散スタンバイレス系切り替えを使用していない場合

サーバマシン内のバックエンドサーバ数

影響分散スタンバイレス系切り替えを使用している場合

サーバマシン内のホストBES数＋pd_ha_max_act_guest_serversオペランドの値

ｑ：pd_utl_exec_modeオペランドが1の場合は，pd_max_usersオペランドの値となります。

pd_utl_exec_modeオペランドが0の場合は，次に示す値となります。

Min（947，pd_max_usersオペランドの値）

ｚ：↑（ユニット内のグローバルバッファが使用する共用メモリの総量※1÷SHMMAXの値）↑

Ai：pd_aud_file_nameオペランドを指定している場合はhの値，指定していない場合は0

Si：各サーバに配置するRDエリアに対するpdbuffer -rオペランドの定義数※2

Ti：各サーバに配置するRDエリアに対するpdbuffer -iオペランドの定義数※2

Ui：pdbuffer -oオペランドの定義数※2

Vi：1（pd_max_ard_processオペランドに1以上を指定する場合）又は0

Wi：2（pd_dfw_awt_processオペランドに値を指定する場合）又は0

Yi：pdbufferオペランドの-cオプションの指定数※2

Zi：pd_dbbuff_modifyオペランドの値がYの場合はpd_max_add_dbbuff_noオペランドの値，pd_dbbuff_modifyオペランドの値がNの場合は0

注※1

グローバルバッファが使用する共用メモリについては，「グローバルバッファが使用する共用メモリの計算式」を参照してください。

注※2

pdbufferに-Dオプションの指定がない場合は1，-Dオプションの指定がある場合は分割数を合計したものがpdbufferオペランドの定義数及び指定数となります。

20.3.2　共用メモリの計算式

メッセージキュー，セマフォ，及び共用メモリの機能を使うことによって使用される共用メモリの計算式を次の表に示します。

表20‒7　共用メモリの計算式

共用メモリを使う機能 | 計算式（単位：バイト）

メッセージキュー

●32ビットモードの場合

（（（（16384＋（PDUXPLMSGTQL×24））＋15）÷16）×16＋384）＋（（PDUXPLMSGMNI−1）×64）＋（（PDUXPLMSGTQL−1）×32）＋Max（0，8×（PDUXPLMSGTQL−2048））

●64ビットモードの場合

（（（（16384＋（PDUXPLMSGTQL×24））＋15）÷16）×16＋408）＋（（PDUXPLMSGMNI−1）×124）＋（（PDUXPLMSGTQL−1）×64）＋Max（0，8×（PDUXPLMSGTQL−2048））

セマフォ

●32ビットモードの場合

99136＋PDUXPLSEMMAXの設定値×6192

●64ビットモードの場合

164968＋PDUXPLSEMMAXの設定値×10304

共用メモリ（共用メモリを使用する場合，管理用の共用メモリが必要になる）

●32ビットモードの場合

16＋PDUXPLSHMMAXの設定値×40

●64ビットモードの場合

24＋PDUXPLSHMMAXの設定値×64

21　Windowsレジストリ設定値の見積もり

この章では，Windowsレジストリ設定値の見積もり方法について説明します。

21.1　デスクトップヒープ指定値の見積もり

21.1.1　デスクトップヒープ指定値の見積もり方法

HiRDBは，必要なデスクトップヒープ量を計算し，ユニット起動時に自動的に確保します。そのため，通常はデスクトップヒープの指定値を変更する必要はありません。ただし，デスクトップヒープ不足が頻発する場合は，次の方法でデスクトップヒープの指定値を見直してください。

(1)　デスクトップヒープの指定値の求め方

デスクトップヒープの使用量はレジストリ中に指定があり，レジストリエディタで変更できます。この指定はアカウントごとの使用量を規定するものです。サーバマシン全体のデスクトップヒープの使用量には，上限値※があります。

注※

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

計算式

HiRDBが起動するサーバプロセス数（pd_max_server_processの値）×a　　（単位：バイト）

ａの値：

5000

ただし，次の点に注意が必要です。

指定値を大きくし過ぎると，別のアカウントで稼働している他PPの動作に影響を与える可能性があります。このため，不要に大きな値を指定しないでください。

HiRDBが起動するプロセスは，HiRDBサーバプロセスやユーザが実行する運用コマンド，及びユティリティだけではありません。HiRDBのサーバプロセスが異常終了した後に実行する保守情報を取得するコマンドも，HiRDBが起動するプロセスとしてデスクトップヒープを使用します。このため，大量のHiRDBサーバプロセス異常終了又はキャンセル時に，デスクトップヒープ不足（サーバプロセス停止を示すKFPS01820-Eメッセージで「end state=0x8000」と表示されます）が発生した場合，デスクトップヒープ量を調整するのではなく，システム共通定義で保守情報を取得しないように変更してください。

(2)　デスクトップヒープの指定値の変更

(a)　HiRDBのシステム定義で変更する場合

システム共通定義，又はユニット制御情報定義のpd_process_desktopheap_sizeオペランドで，1プロセス当たりのデスクトップヒープ消費量を指定します。

(b)　レジストリエディタで変更する場合

上記の方法でデスクトップヒープ不足が解消されない場合は，レジストリエディタでデスクトップヒープの指定値を変更します。なお，レジストリエディタの使い方を誤ると重大な問題が発生することがあります。十分注意してください。また，デスクトップヒープの値は，動作環境に応じて調整する必要があります。

HiRDBのサービスを停止します。

レジストリエディタを使用して，非対話型デスクトップのデスクトップヒープの値を変更します。

●レジストリキー

HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥Session Manager¥SubSystems

●レジストリ値

Windows

●値

%SystemRoot%¥system32¥csrss.exe ObjectDirectory

=¥Windows SharedSection=1024,3072,512

Windows=On SubSystemType=Windows ServerDll=basesrv,1

ServerDll=winsrv:UserServerDllInitialization,3

ServerDll=winsrv:ConServerDllInitialization,2

ProfileControl=Off MaxRequestThreads=16

変更するパラメタは，SharedSectionの3番目のパラメタ（下線）です。このパラメタが512の場合は，システムは各デスクトップに対して512キロバイトのヒープを割り当てます。3番目のパラメタが省略されている場合は，2番目の値（3,072キロバイト）を割り当てます。3番目のパラメタを「デスクトップヒープの指定値の求め方」で求めた値に変更してください。この場合，pd_max_server_processの指定値が正しく見積られた値であることが前提です。

OSを再起動します。

HiRDBサービスを再開始します。

21.2　TCPポートに関する設定値の見積もり

HiRDBの通信処理で使用するTCPポートは，HiRDBが解放してもOSがすぐに解放しない場合（TIME_WAIT状態）があります。HiRDBの運用によって大量のTCPポートがTIME_WAIT状態となり，システム全体のTCPポートが不足し，トランザクションがエラーとなったり，HiRDBが異常終了したりすることがあります。このような場合は，Windowsレジストリの設定値を変更することによって，ポート数不足の発生を回避してください。詳細については，「ポート数不足を回避する方法」を参照してください。

22　サンプルファイル

この章では，HiRDBが提供するサンプルファイル（サンプルデータベース，サンプルコンフィグレーション及びサンプルUOC）について説明します。

22.1　サンプルファイルの概要

HiRDBが提供するサンプルファイルを次に示します。

サンプルオーディット

サンプルデータベース

サンプルコンフィグレーション

サンプルUOC

サンプルファイルのディレクトリ構成を次の図に示します。なお，sample以下のディレクトリは，インストールディレクトリの下にあります。

図22‒1　サンプルファイルのディレクトリ構成

[picture]

以降の説明は，バッチファイルSPsetup.batを実行してHiRDBの環境を設定し終わったことを前提に説明します。SPsetup.batについては，「バッチファイルによる環境設定」を参照してください。

22.1.1　サンプルファイルのファイル名

ここでは，下記のサンプルのファイル名について説明します。

サンプルオーディット

サンプルデータベース

サンプルコンフィグレーション

サンプルUOC

(1)　サンプルオーディットのファイル名

サンプルオーディットは，JP1/NETM/Auditとの連携で使用するサンプルファイルです。ファイル名とその内容を次の表に示します。

表22‒1　サンプルオーディットのファイル名と内容

ファイル名 | 内容
HiRDB.conf | 製品定義ファイル
admjevlog_HiRDB.conf | 動作定義ファイル
sampleaud1 | 検索条件定義ファイル
sampleaud2

これらのサンプルファイルを使用した環境設定については，マニュアル「HiRDB システム運用ガイド」の「JP1/NETM/Auditとの連携」を参照してください。

(2)　サンプルデータベースのファイル名

サンプルで使用するディレクトリ及びファイル名とその内容を次の表に示します。

表22‒2　サンプルで使用するディレクトリ及びファイル名とその内容

ディレクトリ名 又はファイル名 | 内容 | 備考
tblecreate | 表定義文（スキーマ定義を含む） | pddef入力形式
loaddata | データロード入力データ | ディレクトリ
SEIGYO_FILE | データロード用制御文 | −

(3)　サンプルコンフィグレーションのファイル名

サンプルコンフィグレーションの内容を次の表に示します。

ここで示す内容は，パラメタ間の関連性などを分かりやすくするために最小構成での指定値を例として示したもので，最適な値を示したものではありません。

表22‒3　サンプルコンフィグレーションの内容

分類 | 内容 | ファイル名 ※1
システム定義 | システム共通定義 | pdsys
ユニット制御情報定義 | pdutsys
シングルサーバ定義 | sds01
HiRDBファイルシステム領域の確保／初期化 | 次に示すHiRDBファイルシステム領域を作成するバッチファイル RDエリア用のHiRDBファイルシステム領域 作業表用ファイル用のHiRDBファイルシステム領域 | fmkfile.bat
次に示すHiRDBファイルシステム領域を作成するバッチファイル システムファイル用のHiRDBファイルシステム領域 | fmkfs.bat
システムログ，シンクポイントダンプ及びステータスファイル初期化バッチファイル | sysfint.bat
ログアンロード | システムログファイルアンロード用バッチファイル | logunld.bat ※2
データベース初期設定ユティリティ （pdinit） | RDエリアを作成するバッチファイルです。データベース初期設定ユティリティ（pdinit）を実行するバッチファイル | initdb.bat
データベース初期設定ユティリティ（pdinit）の制御文を格納しているバッチファイル | mkinit
コマンドの別名での実行 | コマンドを別名で実行するための実行形式ファイルのひな形（バッチファイル） | aliascmd.bat ※2

注※1

ここではHiRDB/シングルサーバの場合のファイル名を示します。HiRDB/パラレルサーバの場合は，%PDDIR%¥HiRDEF¥readme.txtを参照してください。

注※2

logunld.batは%PDDIR%¥sampleディレクトリ下に，aliascmd.batは%PDDIR%¥sample¥sampleconfディレクトリ下に格納されます。

(4)　サンプルUOCのファイル名

次に示すUOCを格納しています。サンプルUOCの内容を次の表に示します。

データベース作成ユティリティ（pdload）のファイル入力の例

データベース再編成ユティリティ（pdrorg）のファイル出力の例

UOCについては，マニュアル「HiRDB コマンドリファレンス」を参照してください。

表22‒4　サンプルUOCの内容

ファイル名 | 内容
sample1.c | DAT形式入力ファイルをデータベース作成ユティリティ（pdload）が入力するUOCの例です。
sampleA.c | 不要なデータをアンロードファイルに出力しないUOCの例です。

22.2　表の定義情報

サンプルデータベースとして提供している表の種類とその表の列属性を次の表に示します。

これらの表はすべてFIX属性の表です。さらに，バッチファイルSPsetup.batをカスタマイズしないで実行すると，これらの表はユーザ用RDエリアのRDDATA10に格納されます。インデクスはユーザ用RDエリアのRDINDX10に格納されます。

表22‒5　サンプルデータベースとして提供されている表

表名 | 内容 | 行数
CUSTOM | 得意先マスタ | 100
GOODS | 商品マスタ | 100
VENDOR | 仕入先マスタ | 50
TAKEODR | 受注 | データロード対象外
STOCK | 在庫 | 100
WAREHUS | 入庫 | データロード対象外
SHIPMNT | 出庫 | データロード対象外
SENDODR | 発注 | データロード対象外
LAYIN | 仕入れ | データロード対象外

表22‒6　表の列属性及びインデクス

表名 | 列名 | 列属性 | インデクス名
CUSTOM | トクイサキCD | CHAR(5) | UNIQUE CLUSTER KEY CUSTOMX
トクイサキメイ | CHAR(30)
TELNO | CHAR(12)
ZIPCD | CHAR(3)
ジユウシヨ | CHAR(30)
GOODS | シヨウヒンCD | CHAR(6) | UNIQUE CLUSTER KEY GOODSX
シヨウヒンメイ | CHAR(30)
タンカ | DECIMAL(7,0)
シイレサキCD | CHAR(5)
VENDOR | シイレサキCD | CHAR(5) | UNIQUE CLUSTER KEY VENDORX
シイレサキメイ | CHAR(30)
TELNO | CHAR(12)
ZIPCD | CHAR(3)
ジユウシヨ | CHAR(30)
TAKEODR | ジユチユウCD | CHAR(7) | CLUSTER KEY
トクイサキCD | CHAR(5)
シヨウヒンCD | CHAR(6)
スウリヨウ | DECIMAL(7,0)
ヒキアテリヨウ | DECIMAL(7,0)
ジユチユウザン | DECIMAL(7,0)
ジユチユウヒヅケ | CHAR(6)
ノウキ | CHAR(6)
STOCK | シヨウヒンCD | CHAR(6) | CLUSTER KEY
ザイコリヨウ | DECIMAL(7,0)
ヒキアテリヨウ | DECIMAL(7,0)
ハツチユウテン | DECIMAL(7,0)
シイレサキCD | CHAR(5)
WAREHUS | シヨウヒンCD | CHAR(6) | CLUSTER KEY
ニユウコリヨウ | DECIMAL(7,0)
シイレNO | INTEGER
ニユウコビ | CHAR(6)
SHIPMNT | シヨウヒンCD | CHAR(6) | CLUSTER KEY
シユツコリヨウ | DECIMAL(7,0)
ジユチユウCD | CHAR(7)
ジユチユウビ | CHAR(6)
SENDODR | ハツチユウNO | INTEGER | CLUSTER KEY SENDODRX
シイレサキCD | CHAR(5)
シヨウヒンCD | CHAR(6)
ハツチユウリヨウ | DECIMAL(7,0)
ハツチユウビ | CHAR(6)
ノウキ | CHAR(6)
LAYIN | シイレNO | INTEGER | CLUSTER KEY LAYINX
シイレサキCD | CHAR(5)
シヨウヒンCD | CHAR(6)
シイレリヨウ | DECIMAL(7,0)
シイレビ | CHAR(6)

22.3　サンプルファイルの使用方法

サンプルデータベースを作成するバッチファイルを次の表に示します。これらのバッチファイルは%PDDIR%¥sample¥tools（例：C:¥win32app¥hitachi¥hirdb_s¥sample¥tools）ディレクトリ下にあります。

表22‒7　サンプルデータベースを作成するバッチファイル

ファイル名 | 説明
sampleDB1.bat sampleDB2.bat | 表作成者をrootにする場合に使用します。 sampleDB1.batはサンプルデータベースを定義するバッチファイルです。 sampleDB2.batはサンプルデータベースにデータをロードするバッチファイルです。
sampleDB3.bat sampleDB4.bat | 表作成者をUSER1にする場合に使用します。 sampleDB3.batは，USER1にCONNECT権限及びスキーマ定義権限を与えて，サンプルデータベースを定義するバッチファイルです。 sampleDB4.batはサンプルデータベースにデータをロードするバッチファイルです。

注意事項

このバッチファイルの内容をカスタマイズする場合，ファイル名を変更しないで直接カスタマイズすると，HiRDBの更新インストール時に上書きされます。HiRDBが提供しているバッチファイルを別名でコピーしたものをカスタマイズして利用してください。

以降の説明はHiRDB/シングルサーバをデフォルトのインストールディレクトリ（C:¥win32app¥hitachi¥hirdb_s）にインストールしたと仮定しています。必要に応じてパス名及びHiRDBの種類（HiRDB/パラレルサーバ）を読み替えてください。

また，HiRDB/パラレルサーバの場合は，%PDDIR%¥HiRDEF¥readme.txtを参照してください。

22.3.1　サンプルデータベースの作成手順

サンプルデータベースの作成手順を次に示します。

表の定義及びユーザを登録します

HiRDBコマンドプロンプトからsampleDB1.batを実行してください。

「続行するときは何かキーを押してください」と表示されるので，問題がなければ［Enterキー］を押してください。問題がある場合は問題を解決して，再実行してください。この場合，表作成者は「root」になります。表作成者を「USER1」にしたい場合は，sampleDB3.batを実行してください。

表へデータをロードします

HiRDBコマンドプロンプトからsampleDB2.batを実行してください。

「続行するときは何かキーを押してください」と表示されるので，問題がなければ［Enterキー］を押してください。問題がある場合は問題を解決して，再実行してください。表作成者を「USER1」にした場合（sampleDB3.batを使用した場合）は，sampleDB4.batを実行してください。

22.3.2　サンプルデータベースのカスタマイズ

サンプルデータベースを作成するバッチファイルをカスタマイズして，表の定義及び表へのデータロードに利用してください。カスタマイズするには，SQLの知識及びデータベース作成ユティリティ（pdload）の知識が必要になります。SQLについてはマニュアル「HiRDB SQLリファレンス」を，データベース作成ユティリティ（pdload）についてはマニュアル「HiRDB コマンドリファレンス」を参照してください。

注意事項

インストールしてHiRDBの開始が完了した時点で登録されている認可識別子とパスワードは「root」です。「root」ユーザはDBA権限となっています。このため，サンプルデータベースの新規セットアップ実行時にクライアント環境定義（hirdb.ini）中の認可識別子とパスワードはそれぞれ「root」が設定されています（PDUSER='"root" / "root"）。

(1)　新しいユーザを追加する場合

新しいユーザを追加する場合のカスタマイズ方法を次に示します。

カスタマイズ方法

sampleDB1.batの内容を変更します。表定義を実行している部分をコメント化して，権限定義だけが実行されるように変更します。

　pddef<%PDDIR%¥sample¥sampleDB¥tblecreate

　　　　　　　　　　　↓

　rem pddef<%PDDIR%¥sample¥sampleDB¥tblecreate

権限定義のサンプルとして提供している%PDDIR%¥sample¥sampleDB¥gr_USER1の内容を，次のように変更します。

・新しいユーザを追加するため，GRANT文でCONNECT権限を定義します。

・必要に応じてGRANT文でスキーマ定義権限などを定義します。

変更が終了したら，HiRDBコマンドプロンプトからsampleDB1.batを実行します。データベース定義ユティリティ（pddef）が正常に終了したことを示すメッセージが出力されると，新しいユーザの追加と権限定義は完了します。

なお，sampleDB3.batは「USER1」を追加する例です。

(2)　表及びインデクスを定義する場合

表及びインデクスを定義する場合のカスタマイズ方法を次に示します。

カスタマイズ方法

新しいユーザを追加してそのユーザでスキーマ定義などをする場合，クライアント環境定義（hirdb.ini）の認可識別子とパスワードを変更してください（環境変数windirの直下にあるhirdb.iniファイル中の環境変数PDUSERの設定値を「root」から，追加した認可識別子とパスワードに変更してください）。

sampleDB1.batの内容を変更します。権限定義を実行している部分をコメント化し，表定義部分をコメント化していれば元に戻してください。

表定義のサンプルとして提供している%PDDIR%¥sample¥sampleDB¥tblecreateの内容を変更します。定義するスキーマ又は表などの内容を変更します。

変更が終了したら，HiRDBコマンドプロンプトからsampleDB1.batを実行します。データベース定義ユティリティ（pddef）が正常に終了したことを示すメッセージが出力されると完了です。複数の表を定義して，その中にエラーの表がある場合，tblecreateの内容を変更して，もう一度実行してください。

(3)　表にデータロードをする場合

表にデータロードをする場合のカスタマイズ方法を次に示します。

カスタマイズ方法

sampleDB2.batでは認可識別子及びパスワードがそれぞれ「root」になっているので，対応する表の所有者の認可識別子及びパスワードに変更してください。

　set　PDUSER = "root"/"root"

　　　　↓

　set　PDUSER = "認可識別子"/"パスワード"

提供しているサンプルでは四つの表（CUSTOM，GOODS，VENDOR，STOCK）にデータロードをするため，必要に応じてこれらを変更又はコメント化してください。

@echo source%PDDIR%¥sample¥sampleDB¥loaddata¥GOODS.CSV＞%PDDIR%¥TMP¥LODで制御情報ファイルLODに制御情報を設定しています。必要に応じて設定している制御情報部分を変更してください。

%PDDIR%¥bin¥pdload -i s -e GOODS %PDDIR%¥TMP¥LODでデータベース作成ユティリティ（pdload）を実行しています。表名GOODSなど必要に応じて変更してください。

%PDDIR%¥sample¥sampleDB¥loaddata¥GOODS.csvが入力ファイルとなっています。ここで指定したファイル中に入力データを作成してください。提供しているサンプルデータでは，GOODS.CSVがDAT形式になっているので，これを参考に入力データを作成してください。

入力データの作成が終了したら，HiRDBコマンドプロンプトからsampleDB2.batを実行します。データベース作成ユティリティ（pdload）の実行状態を示すメッセージが出力されるので，正しく実行されているかどうかを確認してください。

なお，sampleDB4.batは「USER1」がデータロードを実行する場合の例です。

(4)　コマンドを別名で実行するためのバッチファイルの作成

HiRDBのコマンド名とOSやほかのプログラムが提供しているコマンド名が同一になり，HiRDBのコマンドが実行できない場合があります。このような場合，次に示す回避策があります。

環境変数の設定でHiRDBのコマンドを優先します。

絶対パスを指定してコマンドを実行します。

上記二つの回避策が実行できない場合に，HiRDBのコマンドを任意の名称で実行する方法があります。HiRDBではこの方法を実現するために必要なバッチファイルのひな形を提供しています。

(a)　HiRDBが提供しているバッチファイルのひな形ファイル名

HiRDBが提供しているバッチファイルのひな形ファイルと内容を次の表に示します。ファイルの格納場所を次に示します。

C:¥win32app¥hitachi¥hirdb_s¥sample¥sampleconf

表22‒8　コマンド名の別名実行用バッチファイルのひな形ファイルと内容

ファイル名 | 内容 | 注意
aliascmd.bat | バッチファイルのひな形ファイル | HiRDB運用ディレクトリ下のbin及びlibの二つのディレクトリ以下にはコピーしないでください。

(b)　コマンド名の別名を作成する手順

次に示す手順で，コマンドの別名を作成します。

バッチファイルのひな形ファイルを任意のディレクトリにコピーします。複数のコマンドの別名を作成したい場合は，コマンドの数だけコピーしてください。ただし，HiRDB運用ディレクトリ下のbin及びlibのディレクトリ以下にコピーしないでください。

ひな形ファイルのコピー先のディレクトリをサーチパスとして環境変数PATH又はpathに設定します。

手順1でコピーしたファイルの名称をHiRDBのコマンドの別名として使用したいコマンド名にします。例えば，データベース構成変更ユティリティ（pdmod）のコマンド名を変更したい場合，「hirmod」のように変更します。

コピーしたひな形ファイルを開き，次の図に示す「cc....cc」の部分を別名で実行させたいHiRDBのコマンドの名称に変更します。

図22‒2　バッチファイルのひな形ファイル

[picture]

以上の設定によって，HiRDBのコマンドを任意の名称で実行できます。また，オプションもHiRDBのコマンドと同様に指定できます。

(c)　注意

ひな形ファイルのコピー後の名称には，HiRDBのコマンドとは異なる名称を指定してください。

HiRDB運用ディレクトリ下の二つのディレクトリ（%PDDIR%¥bin及び%PDDIR%¥lib）は，アンインストール時にディレクトリごと削除される可能性があります。このため，この二つのディレクトリ以下にひな形ファイルをコピーしないでください。

バッチファイルのひな形ファイルをほかのバッチファイル中から呼び出す場合は，「call」を使用してください。「call」を使用しない場合は，呼び出し先から戻れなくなります。

ひな形ファイルの内容は，HiRDBのコマンド名の設定箇所以外は変更しないでください。

作成した別名コマンドを実行中に，そのコマンド処理を中断させる場合には別名プロセスの延長で起動しているHiRDBコマンドプロセスを停止させてください。別名プロセスを停止させるだけでは，HiRDBコマンドプロセスは停止しません。

作成した別名コマンドを実行して，HiRDBコマンドが応答入力待ち状態のときに別名プロセスを停止させると，HiRDBコマンドの実行がエラーになったり応答入力待ち状態を継続している場合があります。応答入力待ちが継続されていた場合には，HiRDBコマンドプロセスを停止させてください。

22.3.3　サンプルで使用するHiRDBファイルシステム領域名とユーザ作成ファイル名

サンプルで使用するHiRDBファイルシステム領域名とサイズ及びユーザ作成ファイル名について説明します。

なお，ここで示す内容は，サンプルデータベースで使用している名称を示したもので，この名称と同じにしなければならないというものではありません。

(1)　HiRDBファイルシステム領域名とサイズ

サンプルで使用するHiRDBファイルシステム領域名とサイズを次の表に示します。

表22‒9　SPsetup.batを実行して作成されるHiRDBファイルシステム領域名とサイズ

HiRDBファイルシステム領域の種類 | HiRDBファイルシステム領域のサイズ（単位：メガバイト） | HiRDBファイルシステム領域名

システムファイル用

小規模→74

中規模→148

大規模→296

rdsys011※1

rdsys012※1

rdsys013※1

rdsys014※1

rdsys015※1

rdsys016※1

RDエリア用（システム用RDエリア） | 小規模→20 中規模→40 大規模→80 | rdsys02※2
作業表用ファイル用 | − | rdsys03※2
RDエリア用（ユーザ用RDエリア） | 小規模→40 中規模→80 大規模→160 | rdsys04※2
RDエリア用（ユーザLOB用RDエリア） | 40 | rdsys05※2

注※1

SPsetup.bat実行時に表示されるセットアップ内容の確認画面の［HiRDBシステムファイル領域用ディレクトリ］で指定したディレクトリ下に作成されます。省略値は%PDDIR%¥areaディレクトリになります。

注※2

SPsetup.bat実行時に表示されるセットアップ内容の確認画面の［HiRDB RDエリア領域用ディレクトリ］で指定したディレクトリ下に作成されます。省略値は%PDDIR%¥areaディレクトリになります。

(2)　ユーザ作成ファイル名

サンプルで使用するユーザ作成ファイル名を次の表に示します。

表22‒10　SPsetup.batを実行して作成されるファイルの名称

ファイルの種類 | ファイル名 | 備考
HiRDBシステム定義ファイル | システム共通定義ファイル | %PDDIR%¥conf¥pdsys | ディレクトリはインストール時に作成されます。
ユニット制御情報定義ファイル | %PDDIR%¥conf¥pdutsys
シングルサーバ定義ファイル | %PDDIR%¥conf¥sds01

システムファイル

システムログファイル

rdsys011¥log1※1

rdsys012¥log2※1

rdsys013¥log3※1

rdsys014¥log4※1

rdsys015¥log5※1

rdsys016¥log6※1

6グループ

シンクポイントダンプファイル | rdsys014¥spd1※1 rdsys015¥spd2※1 rdsys016¥spd3※1 | 3グループ

ユニット用ステータスファイル

rdsys011¥utsts1a※1

rdsys012¥utsts1b※1

rdsys013¥utsts2a※1

rdsys014¥utsts2b※1

rdsys015¥utsts3a※1

rdsys016¥utsts3b※1

ユニットごとに

二重化×3個

サーバ用ステータスファイル

rdsys011¥sts1a※1

rdsys012¥sts1b※1

rdsys013¥sts2a※1

rdsys014¥sts2b※1

rdsys015¥sts3a※1

rdsys016¥sts3b※1

サーバごとに

二重化×3個

システム用RDエリア | マスタディレクトリ用RDエリア | rdsys02¥rdmast※2 | RDエリア名はRDMAST
データディレクトリ用RDエリア | rdsys02¥rddirt※2 | RDエリア名はRDDIRT
データディクショナリ用RDエリア | rdsys02¥rddict※2 | RDエリア名はRDDICT
データディクショナリLOB用RDエリア（ソース格納用） | rdsys02¥rtn_src※2 | RDエリア名は DIC_RTN_SRC
データディクショナリLOB用RDエリア（オブジェクト格納用） | rdsys02¥rtn_obj※2 | RDエリア名は DIC_RTN_OBJ
作業表用ファイル | rdsys03※2 | −
RPCトレースファイル | %PDDIR%¥spool¥pdrpctr | −
ユーザ用RDエリア（データ格納用） | rdsys04¥rddata10※2 | RDエリア名はRDDATA10
ユーザ用RDエリア（インデクス格納用） | rdsys04¥rdindx10※2 | RDエリア名はRDINDX10
ユーザLOB用RDエリア | rdsys05¥rlob1※2 | RDエリア名はRLOB1
rdsys05¥rlob2※2 | RDエリア名はRLOB2

（凡例）−：該当しません。

注※1

SPsetup.bat実行時に表示されるセットアップ内容の確認画面の［HiRDBシステムファイル領域用ディレクトリ］で指定したディレクトリ下に作成されます。省略値は%PDDIR%¥areaディレクトリになります。

注※2

SPsetup.bat実行時に表示されるセットアップ内容の確認画面の［HiRDB RDエリア領域用ディレクトリ］で指定したディレクトリ下に作成されます。省略値は%PDDIR%¥areaディレクトリになります。

23　HiRDBサーバとHiRDBクライアント間の通信

この章では，HiRDBサーバとHiRDBクライアントの接続方法，DNSサーバやファイアウォールがある場合の設定などについて説明します。

23.1　HiRDBサーバとHiRDBクライアントの接続方法

HiRDBクライアントがHiRDBサーバに接続するには，クライアント環境定義の次に示すオペランドでホスト名（又はIPアドレス）を指定する必要があります。

PDHOST

PDFESHOST

これらのオペランドに指定するホスト名は，システム共通定義のpdunitオペランドで指定したホスト名を指定します。

ただし，ネットワークの構成によってはpdunitオペランドで指定したホスト名を指定しても接続できない場合があります。DNSを使用している環境では「FQDNを指定したHiRDBサーバへの接続方法」を，HiRDBのサーバ間で使用しているネットワークとHiRDBクライアントとHiRDBサーバ間で使用しているネットワークが異なる場合は「マルチコネクションアドレス機能を使用したHiRDBサーバへの接続方法」を参照してください。

23.1.1　FQDNを指定したHiRDBサーバへの接続方法

pdunitオペランドで指定したホスト名は，HiRDBサーバにアクセスするすべてのクライアントマシンのhostsファイルにIPアドレスとともに登録する必要があります。しかし，DNSを使用すると，hostsファイルに登録する必要がなくなるため，登録処理やIPアドレス変更に伴うhostsファイルの変更処理が不要になります。

ドメイン内に含まれるホスト上で稼働するHiRDBサーバと接続する場合は，PDHOST，PDFESHOSTにサーバマシンのFQDNを指定することで，HiRDBサーバに接続できます。

クライアント環境定義に指定できる名称を次の表に示します。

表23‒1　クライアント環境定義に指定できる名称

クライアント環境定義に指定する名称 | バージョン05-02以前 | バージョン05-03以降
ホスト名 | ○ | ○
FQDN | × | ○ ※

（凡例）

○：指定できます。

×：指定できません。

注※

大規模なネットワーク環境で，ホスト名やIPアドレスの登録，IPアドレスの変更に伴ってhostsファイルを変更したくない場合に使用します。

(1)　FQDNを指定してHiRDBサーバへ接続する場合のネットワーク構成例と定義例

FQDNを指定してHiRDBサーバへ接続する場合のネットワーク構成例と定義例を次の図に示します。

図23‒1　FQDNを指定してHiRDBサーバへ接続する場合のネットワーク構成例と定義例

[picture]

〔説明〕

システム共通定義のpdunitオペランドの-xオプションには，HiRDBサーバで使用するネットワークのホスト名（HS01）を指定します。

クライアント環境定義のPDHOSTには，HiRDBサーバのFQDN（HS01.soft.hitachi.co.jp）を指定します。

(2)　注意事項

バージョン05-03より前のHiRDBサーバに接続する場合は，クライアント環境定義のPDHOST，PDFESHOSTにFQDNを指定できません。指定するとクライアント最大待ち時間（PDCWAITTIME指定値）経過後，キャンセル処理できないでサーバプロセスが残ることがあります。

HiRDBサーバで定義するホスト名にFQDNを指定できません。

HiRDBサーバが使用するネットワークとHiRDBクライアントが接続するネットワークが異なる場合は，マルチコネクションアドレス機能を使用して，HiRDBサーバに接続してください。マルチコネクションアドレス機能については，「マルチコネクションアドレス機能を使用したHiRDBサーバへの接続方法」を参照してください。

23.1.2　マルチコネクションアドレス機能を使用したHiRDBサーバへの接続方法

ネットワークの構成によってはpdunitオペランドで指定したホスト名を指定しても，HiRDBサーバと接続できないことがあります。例えば，HiRDBクライアントとHiRDBサーバ間で使用しているネットワークと，HiRDBサーバのサーバマシン間で使用しているネットワークが異なる場合がこれに該当します。

このような場合，マルチコネクションアドレス機能を使用します。この機能を使用すると，PDHOST又はPDFESHOSTオペランドに，pdunitオペランドと同じホスト名を指定しなくても，HiRDBサーバと接続できるようになります。

(1)　マルチコネクションアドレス機能の使用方法

マルチコネクションアドレス機能を使用するには，システム共通定義のpdstartオペランドで-mオプションを指定します。

系切り替え構成を適用する際は，HiRDBサーバ間で使用するネットワークのIPアドレスを引き継がない場合でも，HiRDBクライアントとHiRDBサーバ間で使用するネットワークのIPアドレス（クライアントの接続先となるIPアドレス）は引き継ぐ構成としてください。その場合の定義例については，「HiRDB/パラレルサーバの場合（IPアドレスを引き継ぐ系切り替えをする場合）」を参照してください。

-m及び-nオプションには，HiRDBクライアントがネットワークを経由して接続できるHiRDBサーバのホスト名を指定します。pdunitオペランドに指定したホスト名と同じ必要はありません。

(2)　マルチコネクションアドレス機能を使用したネットワーク構成例と定義例

(a)　HiRDB/シングルサーバの場合

マルチコネクションアドレス機能を使用したネットワーク構成例と定義例（HiRDB/シングルサーバの場合）を次の図に示します。

図23‒2　ネットワーク構成例と定義例（HiRDB/シングルサーバの場合）

[picture]

〔説明〕

pdunitオペランドの-xオプションには，HiRDBサーバ間で使用するネットワークのホスト名（HS01）を指定します。

pdstartオペランドの-mオプションには，HiRDBクライアントとHiRDB/シングルサーバ間で使用するネットワークのホスト名（he01）を指定します。

クライアント環境定義のPDHOSTオペランドには，HiRDBクライアントとHiRDB/シングルサーバ間で使用するネットワークのホスト名（he01）を指定します。

(b)　HiRDB/パラレルサーバの場合

マルチコネクションアドレス機能を使用したネットワーク構成例と定義例（HiRDB/パラレルサーバの場合）を次の図に示します。

図23‒3　ネットワーク構成例と定義例（HiRDB/パラレルサーバの場合）

[picture]

〔説明〕

pdunitオペランドの-xオプションには，HiRDBサーバ間で使用するネットワークのホスト名（HS01，HS02）を指定します。

pdstartオペランド（フロントエンドサーバを定義するpdstartオペランド）の-mオプションには，HiRDBクライアントとHiRDBサーバ間で使用するネットワークのホスト名（he03）を指定します。

クライアント環境定義のPDHOSTオペランドには，HiRDBクライアントとHiRDBサーバ間で使用するネットワークのホスト名（システムマネジャがあるホスト名：he01）を指定します。

(c)　HiRDB/パラレルサーバの場合（IPアドレスを引き継ぐ系切り替えをする場合）

マルチコネクションアドレス機能を使用したネットワーク構成と定義例（IPアドレスを引き継ぐ系切り替えをする場合）を次の図に示します。

図23‒4　ネットワーク構成例と定義例（IPアドレスを引き継ぐ系切り替えをする場合）

[picture]

〔説明〕

pdunitオペランドの-xオプションには，HiRDBサーバ間で使用するネットワークのホスト名（HS01，HS03）を指定します。

pdstartオペランド（フロントエンドサーバを定義するpdstartオペランド）の-mオプションには，HiRDBクライアントとHiRDBサーバ間で使用するネットワークのIPアドレスに対応するホスト名（he04）を指定します。-nオプションは省略します。

クライアント環境定義のPDHOSTオペランドには，HiRDBクライアントとHiRDBサーバ間で使用するネットワークのホスト名（システムマネジャがあるホスト名：he01）を指定します。

(d)　HiRDB/パラレルサーバの場合（IPアドレスを引き継がない系切り替えをする場合）

マルチコネクションアドレス機能を使用したネットワーク構成例と定義例（IPアドレスを引き継がない系切り替えをする場合）を次の図に示します。

図23‒5　ネットワーク構成例と定義例（IPアドレスを引き継がない系切り替えをする場合）

[picture]

〔説明〕

pdunitオペランドの-xオプションには，HiRDBサーバ間で使用するネットワークのホスト名（HS01，HS03）を指定します。-cオプションには，予備系のホスト名（HS02）を指定します。

pdstartオペランド（フロントエンドサーバを定義するpdstartオペランド）の-mオプションには，HiRDBクライアントとHiRDBサーバ間で使用するネットワークのホスト名（he04）を指定します。-nオプションには，予備系のホスト名（he03）を指定します。

クライアント環境定義のPDHOSTオペランドには，HiRDBクライアントとHiRDBサーバ間で使用するネットワークのホスト名（システムマネジャがあるホスト名：he01）を指定します。また，予備系のホスト名（he03）も指定します。

23.2　DNSサーバでIPアドレスを管理する場合の設定

DNSサーバでIPアドレスを管理する場合のHiRDBシステムには次の2とおりがあります。

サーバマシンが同一ドメイン内に存在する場合

サーバマシンが複数のドメインにわたって存在する場合

それぞれのHiRDBの設定方法を説明します。

23.2.1　同一ドメイン内でのHiRDBの設定方法

サーバマシンが同一ドメイン内に存在する場合，pdunitオペランド及びpdstartオペランドのホスト名称に「ホスト名」又は「FQDN（完全修飾子付きドメイン名称。ただし32文字以内）」のどちらかを指定します。これによって，DNSサーバでIPアドレスが管理でき，hostsファイルの設定が不要になります。

具体的には，次のオプションでホスト名かFQDNを指定します。

pdunitオペランド：-x及び-cオプション

pdstartオペランド：-x，-m，及び-nオプション

同一ドメインのシステム構成例を次の図に示します。

図23‒6　同一ドメインのシステム構成例

[picture]

この場合のpdunit -xの指定例を次に示します。

ホスト名指定の場合

pdunit -x hirdb01 -u unt1 -d "運用ディレクトリ名" -p ポート番号 …

pdunit -x hirdb02 -u unt2 -d "運用ディレクトリ名" -p ポート番号 …

pdunit -x hirdb03 -u unt3 -d "運用ディレクトリ名" -p ポート番号 …

FQDN指定の場合

pdunit -x hirdb01.p1.ne.jp -u unt1 -d "運用ディレクトリ名" -p ポート番号 …

pdunit -x hirdb02.p1.ne.jp -u unt2 -d "運用ディレクトリ名" -p ポート番号 …

pdunit -x hirdb03.p1.ne.jp -u unt3 -d "運用ディレクトリ名" -p ポート番号 …

23.2.2　複数ドメインでのHiRDBの設定方法

サーバマシンが複数のドメインにわたって存在する場合，pdunitオペランド及びpdstartオペランドのホスト名称に「FQDN（完全修飾子付きドメイン名称：ただし32文字以内）」を指定します。これによって，DNSサーバでIPアドレスが管理でき，hostsファイルの設定が不要になります。

具体的には，次のオプションでFQDNを指定します。

pdunitオペランド：-x，及び-cオプション

pdstartオペランド：-x，-m，及び-nオプション

複数ドメインのシステム構成例を次の図に示します。

図23‒7　複数ドメインのシステム構成例

[picture]

この場合のpdunit -xの指定例を次に示します。

FQDN指定の場合

pdunit -x hirdb01.pl1.ne.jp -u unt1 -d "運用ディレクトリ名" -p ポート番号 …

pdunit -x hirdb02.pl1.ne.jp -u unt2 -d "運用ディレクトリ名" -p ポート番号 …

pdunit -x hirdb03.pl2.ne.jp -u unt3 -d "運用ディレクトリ名" -p ポート番号 …

23.3　ファイアウォールやNATが設置されている場合の設定

HiRDBサーバとHiRDBクライアント間又はHiRDBサーバのユニット間に，ファイアウォールやNATが設置されている場合のHiRDBの環境設定について説明します。

23.3.1　HiRDB/シングルサーバ側にファイアウォールを設置した場合

次の図のようにHiRDB/シングルサーバ側にファイアウォールが設置され，そのファイアウォールが次のように設定されているとします。

ファイアウォールの設定

方向：受信

透過させるIPアドレス：172.16.0.10

透過させるポート番号：20000，20001

図23‒8　ファイアウォールがHiRDB/シングルサーバ側に設置されているネットワーク構成例

[picture]

この場合，サーバマシン及びクライアントマシンの設定は次のようになります。ファイアウォールを設置する場合，次のどれかのオペランドを指定する必要があります。

pd_service_portオペランド

pd_scd_portオペランド

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

ファイアウォールだけ設置する場合，クライアント環境定義（PDSERVICEPORTオペランド）を指定する必要はありません。

サーバマシンの設定

システム共通定義ファイル

set pd_name_port= 20000

set pd_service_port= 20001

pdunit -x hirdb01 -u unt1

pdstart -t SDS -s sds01 -u unt1

クライアントマシンの設定

クライアント環境定義

PDHOST　hirdb01

PDNAMEPORT　20000

PDCLTRCVPORT　30000※

PDCONTYPE　ACTIVE※

hostsファイル

172.16.0.10　hirdb01

注※　クライアント側にファイアウォールがある場合は，PDCLTRCVPORTを指定するか，PDCONTYPEにACTIVEを指定してください。クライアントとサーバの間にNAPT（IPマスカレード）のように，グローバルIPアドレスとローカルIPアドレスを１対複数で変換するような機能を設定している場合は，PDCONTYPEにACTIVEを指定してください。

23.3.2　HiRDB/シングルサーバ側にファイアウォールとNATを設置した場合

次の図のようにHiRDB/シングルサーバ側にファイアウォールとNATが設置され，それらが次のように設定されているとします。

ファイアウォールの設定

方向：受信

透過させるIPアドレス：172.16.0.10

透過させるポート番号：20000，20001

NATによるアドレス変換

128.1.1.1←→172.16.0.10

図23‒9　ファイアウォールとNATがHiRDB/シングルサーバ側に設置されているネットワーク構成例

[picture]

この場合，高速接続機能を使用する設定にしてください。サーバマシン及びクライアントマシンの設定は次のようになります。

サーバマシンの設定

システム共通定義ファイル

set pd_name_port = 20000

set pd_service_port = 20001

pdunit -x hirdb01 -u unt1

pdstart -t SDS -s sds01 -u unt1

クライアントマシンの設定

クライアント環境定義

PDHOST　hirdb01

PDNAMEPORT　20000

PDSERVICEGRP　sds01

PDSERVICEPORT　20001

PDSRVTYPE　PC

PDCLTRCVPORT　30000※

PDCONTYPE　ACTIVE※

hostsファイル

128.1.1.1　hirdb01

注※　クライアント側にファイアウォールがある場合は，PDCLTRCVPORTを指定するかPDCONTYPEにACTIVEを指定してください。クライアントとサーバの間にNAPT（IPマスカレード）のように，グローバルIPアドレスとローカルIPアドレスを１対複数で変換するような機能を設定している場合は，PDCONTYPEにACTIVEを指定してください。

23.3.3　HiRDB/パラレルサーバ側にファイアウォールを設置した場合

次の図のようにHiRDB/パラレルサーバ側にファイアウォールが設置され，そのファイアウォールが次のように設定されているとします。

ファイアウォールの設定

方向：受信

透過させるIPアドレス：172.16.0.10，172.16.0.20

透過させるポート番号：20000，20001

図23‒10　ファイアウォールがHiRDB/パラレルサーバ側に設置されているネットワーク構成例

[picture]

この場合，サーバマシン及びクライアントマシンの設定は次のようになります。ファイアウォールを設置する場合，次のどれかのオペランドを指定する必要があります。

pd_service_portオペランド

pd_scd_portオペランド

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

ファイアウォールだけ設置する場合，クライアント環境定義（PDSERVICEPORTオペランド）を指定する必要はありません。

サーバマシンの設定

システム共通定義ファイル

set pd_name_port = 20000

set pd_service_port = 20001

pdunit -x hirdb01 -u unt1

pdunit -x hirdb02 -u unt2

pdstart -t MGR -u unt1

pdstart -t FES -s fes -u unt2

クライアントマシンの設定

クライアント環境定義

PDHOST　hirdb01

PDNAMEPORT　20000

PDCLTRCVPORT　30000※

PDCONTYPE　ACTIVE※

hostsファイル

172.16.0.10　hirdb01

172.16.0.20　hirdb02

注※　クライアント側にファイアウォールがある場合は，PDCLTRCVPORTを指定するかPDCONTYPEにACTIVEを指定してください。クライアントとサーバの間にNAPT（IPマスカレード）のように，グローバルIPアドレスとローカルIPアドレスを１対複数で変換するような機能を設定している場合は，PDCONTYPEにACTIVEを指定してください。

23.3.4　HiRDB/パラレルサーバ側にファイアウォールとNATを設置した場合

次の図のようにHiRDB/パラレルサーバ側にファイアウォールとNATが設置され，それらが次のように設定されているとします。

ファイアウォールの設定

方向：受信

透過させるIPアドレス：172.16.0.10，172.16.0.20

ポート番号：20000，20001

NATによるアドレス変換

128.1.1.1←→172.16.0.10

128.1.1.2←→172.16.0.20

図23‒11　ファイアウォールとNATがHiRDB/パラレルサーバ側に設置されているネットワーク構成例

[picture]

この場合，高速接続機能を使用する設定にしてください。サーバマシン及びクライアントマシンの設定は次のようになります。

サーバマシンの設定

システム共通定義ファイル

set pd_name_port = 20000

set pd_service_port = 20001

pdunit -x hirdb01 -u unt1

pdunit -x hirdb02 -u unt2

pdstart -t MGR -u unt1

pdstart -t FES -s fes -u unt2

クライアントマシンの設定

クライアント環境定義

PDHOST　hirdb01

PDNAMEPORT　20000

PDSERVICEGRP　fes

PDSERVICEPORT　20001

PDFESHOST　hirdb02

PDSRVTYPE　PC

PDCLTRCVPORT　30000※

PDCONTYPE　ACTIVE※

hostsファイル

128.1.1.1　hirdb01

128.1.1.2　hirdb02

注※　クライアント側にファイアウォールがある場合は，PDCLTRCVPORTを指定するかPDCONTYPEにACTIVEを指定してください。クライアントとサーバの間にNAPT（IPマスカレード）のように，グローバルIPアドレスとローカルIPアドレスを１対複数で変換するような機能を設定している場合は，PDCONTYPEにACTIVEを指定してください。

23.3.5　HiRDBサーバのユニット間にファイアウォールを設置した場合

HiRDBサーバはすべてのユニット間で通信できる必要があります。次の図のようにHiRDBサーバのユニット間にファイアウォールを設置する場合，ファイアウォールでユニット間の通信に使用するポートを透過させる必要があります。

ファイアウォールの設定

方向：送信，受信

透過させるIPアドレス：172.16.0.10，172.16.0.20，10.0.0.30

透過させるポート番号：OSの自動割り当てポート，リモートシェルが使用するポート，HiRDBのオペランドで指定したポート

図23‒12　ファイアウォールがHiRDBサーバのユニット間に設置されているネットワーク構成例

[picture]

次の場合，HiRDBサーバはユニット間の通信にOSの自動割り当てポートを使用するため，ファイアウォールでOSの自動割り当てポートを透過させる必要があります。

ユティリティ及び運用コマンドを実行する場合

pd_registered_portオペランドを指定しない場合

pd_registered_portオペランドへ指定したポート番号を使用できなかった場合

次の場合，HiRDBサーバはユニット間の通信にリモートシェルを使用するため，ファイアウォールでリモートシェルが使用するポートを透過させる必要があります。

ユティリティ及び運用コマンドを実行する場合

IPアドレスを引き継がない系切り替え機能を使用する場合

次のオペランドへ指定したポートをHiRDBサーバはユニット間の通信に使用するため，ファイアウォールでオペランドへ指定したポートを透過させる必要があります。

サーバマシンの設定

システム共通定義ファイル

pd_name_portオペランド

pd_service_portオペランド

pd_scd_portオペランド

pd_trn_portオペランド

pd_mlg_portオペランド

pd_alv_portオペランド

pd_registered_portオペランド

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

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

pdunitオペランドの-tオプション

pdunitオペランドの-mオプション

pdunitオペランドの-aオプション

23.4　HiRDBが使用するポート数

HiRDBの通信処理では，pd_registered_portオペランドの指定がない場合，OSが自動的に割り当てる通信ポート番号を使用します。使用する通信ポート数は，pd_max_usersオペランドの値やバックエンドサーバ数の増加に伴って増加します。ポート数が不足すると，処理が中断したり，他プログラムの通信処理に影響を与えたりします。

なお，pd_registered_portオペランドでHiRDBが通信処理で使用するポート番号の範囲を指定（HiRDB予約ポート機能）できます。HiRDB予約ポート機能については，「HiRDB予約ポート機能」を参照してください。

23.4.1　ユニットが使用する通信ポート数の見積もり

HiRDBのユニットが使用する通信ポート数の目安を次に示します。

(1)　HiRDB/シングルサーバの場合

計算式

pd_max_usersの値×4＋1000

(2)　HiRDB/パラレルサーバの場合

マルチフロントエンドサーバ構成の場合は，フロントエンドサーバごとにf，Fを決定し，算出したポート数の合算となります。フロントエンドサーバごとのポート数の目安を算出する計算式を次に示します。

計算式

｛b×［k×〔（b−1）÷2＋B＋1〕＋1］
＋f×（k×（b＋B）＋D＋2）＋d×2｝
×pd_max_usersの値＋1000

ｂ：ユニット内のバックエンドサーバ数

Ｂ：ユニット外のバックエンドサーバ数

ｆ：ユニット内のフロントエンドサーバ数

フロントエンドサーバごとに1，又は0のどちらかの値になります。

ユニット内にフロントエンドサーバがある場合：1

ユニット外にフロントエンドサーバがある場合：0

ｄ：ユニット内のディクショナリサーバ数

Ｄ：ユニット外のディクショナリサーバ数

ｋ：2÷3

23.4.2　注意事項

実行するSQL文によっては，目安以上のポート数が必要となる場合があります。

OSが自動的に割り当てるポート数で足りない場合は，pd_registered_portオペランドで指定し直してください。

ポート番号は，HiRDBが解放してもOSがすぐに解放しない場合（TIME_WAIT状態）があります。そのため，目安以上のポート数を一時的に使用する場合があります。TIME_WAIT状態によるポート数不足を回避する方法については，「ポート数不足を回避する方法」を参照してください。

システム内のバックエンドサーバ数が多いシステム構成の場合，計算した値がOSのポート番号の上限値やpd_registered_portに指定したポート番号を超えるおそれがあります。その場合の対策については，「ユニット数又はサーバ数が多いシステムを構築する場合の考慮点」を参照してください。

23.4.3　計算例

（例1）

1ユニット構成のHiRDB/パラレルサーバ（FES，DS，BESが5個）で，pd_max_users＝1000とした場合

｛5×［2÷3×（0＋0）+1］
＋1×（2÷3×0＋0＋2）＋1×（0＋1）｝
×1000＋1000＝9000

9000個のポート数が目安となります。

（例2）

ユニット構成のパラレル（ユニット1（FES，DS，BESが2個），ユニット2（BESが3個））で，pd_max_users＝1000とした場合

ユニット1：

｛2×［2÷3×（3＋0）＋1］
＋1×（2÷3×3＋0＋2）＋1×（0＋1）｝
×1000＋1000＝12000

ユニット2：

｛3×［2÷3×（2＋1）＋1］
＋0×（2÷3×2＋1＋2）＋0×（1＋1）｝
×1000＋1000＝10000

それぞれに12000個，10000個のポート数が目安となります。

23.4.4　ポート数不足を回避する方法

次に示すような運用をする場合，大量のTCPポートがTIME_WAIT状態となり，システム全体のTCPポートが不足し，トランザクションがエラーとなったり，HiRDBが異常終了したりすることがあります。

ユティリティ及びコマンドを連続実行する場合

UAPの同時接続数が多く，そのUAPがトランザクションの実行を繰り返す場合

このような運用をする場合，次に示す設定を行い，TCPポートが不足しないようにしてください。

なお，ここで説明するWindowsレジストリや設定値は，使用しているWindowsのバージョンによって異なる場合があります。使用しているWindowsのマニュアルを参照し，ここで説明している指定値の目安で示した値を設定してください。

(1)　TCPポートの枯渇を回避する設定

pd_registered_portオペランドでHiRDBが通信処理で使用するポート番号の範囲を拡大（HiRDB予約ポート機能）するとTCPポートの枯渇を回避できます。HiRDB予約ポート機能については，「HiRDB予約ポート機能」を参照してください。

(2)　TCPポートをTIME_WAIT状態に保つ時間を短くする設定

TCPポートをTIME_WAIT状態に保つ時間を短くするには，次に示すWindowsレジストリの設定値を指定してください。

レジストリキー：

HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Services¥Tcpip¥Parameters

レジストリ値：

TcpTimedWaitDelay

指定値の目安：

30

(3)　TCPポートのOS自動割り当てポートの範囲を拡大する設定

TCPポートのOS自動割り当てポートの範囲を拡大するには，次に示すコマンドを実行して設定値を変更してください。

実行コマンド：

netsh int ipv4 set dynamic tcp start=数値 num=範囲

指定値の目安：

サーバマシン内で使用する予約ポートと重複しない範囲で，OS自動割り当てポートの範囲を拡大してください。

23.5　HiRDBで指定するポート番号

23.5.1　HiRDBで指定するポート番号の一覧

ポート番号を指定するオペランドを次の表に示します。

表23‒2　HiRDBで指定するポート番号の一覧

設定箇所 | 指定する環境変数又はオペランド | 説明
クライアント環境定義 | PDNAMEPORT | HiRDBのポート番号
HiRDB_PDNAMEPORT
PDSERVICEPORT | 高速接続用のポート番号
PDFESHOST | フロントエンドサーバがあるユニットのポート番号
PDCLTRCVPORT | クライアントの受信ポート番号
PDASTPORT | HiRDB Control Manager - Agentのポート番号
システム共通定義 | pd_name_port | HiRDBのポート番号
pdunit -p
pd_service_port | スケジューラプロセスのポート番号
pd_scd_port
pdunit -s
pd_trn_port | トランザクションサーバプロセスのポート番号
pdunit -t
pd_mlg_port | メッセージログサーバプロセスのポート番号
pdunit -m
pd_alv_port | ユニット監視プロセスのポート番号
pdunit -a
pd_registered_port | HiRDB予約ポート機能で使用するポート番号
pd_crypto_service_port | スケジューラプロセスの暗号化通信接続用のポート番号
ユニット制御情報定義 | pd_service_port | スケジューラプロセスのポート番号
pd_registered_port | HiRDB予約ポート機能で使用するポート番号
pd_crypto_service_port | スケジューラプロセスの暗号化通信接続用のポート番号
%windir%¥system32¥drivers¥etc¥servicesファイル | − | 連絡用ポート番号

23.5.2　ポート番号の指定方法

ここでは，ポート番号の指定方法について，それぞれ説明します。

(1)　クライアント環境定義

マニュアル「HiRDB UAP開発ガイド」の「クライアント環境定義（環境変数の設定）」を参照してください。

(2)　システム共通定義及びユニット制御情報定義

システム共通定義及びユニット制御情報定義のオペランドの指定有無と使用するポート番号について説明します。

オペランドに指定したポート番号を固定したい場合，表中の「使用するポート番号」を参照して，そのポート番号を使用する組み合わせでオペランドを指定してください。例えば，「(a)HiRDBのポート番号」で，HiRDB/パラレルサーバの場合，pd_name_portオペランドに指定したポート番号に固定したいとき，pdunit -pは指定を省略してください。

(a)　HiRDBのポート番号

HiRDBのポート番号は，pd_name_portオペランド及びpdunitオペランドの-pオプションに指定します。これらのオペランドの指定有無と使用するポート番号について説明します。

HiRDB/シングルサーバの場合

pd_name_port | pdunit -p | 使用するポート番号
あり | あり | pd_name_portの指定
なし
なし | あり | 20000
なし

HiRDB/パラレルサーバの場合

pd_name_port | pdunit -p | 使用するポート番号
あり | あり | pdunit -pの指定
なし | pd_name_portの指定
なし | あり | pdunit -pの指定
なし | 20000

(b)　スケジューラプロセスのポート番号

スケジューラプロセスのポート番号は，次のオペランドに指定します。

pd_service_portオペランド

pd_scd_portオペランド

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

これらのオペランドの指定有無と使用するポート番号を次に示します。

指定箇所 | 使用するポート番号
システム共通定義 | ユニット制御情報定義
pd_service_port | pd_scd_port | pdunit -s | pd_service_port
あり | あり | あり | あり | pdunit -sの指定
なし
なし | あり | pd_scd_portの指定
なし
なし | あり | あり | pdunit -sの指定
なし
なし | あり | ユニット制御情報定義のpd_service_portの指定
なし | システム共通定義のpd_service_portの指定
なし | あり | あり | あり | pdunit -sの指定
なし
なし | あり | pd_scd_portの指定
なし
なし | あり | あり | pdunit -sの指定
なし
なし | あり | ユニット制御情報定義のpd_service_portの指定
なし | ※

注※

システム共通定義又はユニット制御情報定義にpd_registered_portオペランドを指定した場合，pd_registered_portオペランドに指定した範囲内のポート番号を使用します。pd_registered_portオペランドを指定しない場合，OSが自動的に割り当てたポート番号を使用します。

(c)　トランザクションサーバプロセス，メッセージログサーバプロセス，及びユニット監視プロセスのポート番号

トランザクションサーバプロセス，メッセージログサーバプロセス，及びユニット監視プロセスのポート番号は，次に示すオペランドに指定します。

トランザクションサーバプロセス

pd_trn_portオペランド及びpdunitオペランドの-tオプション

メッセージログサーバプロセス

pd_mlg_portオペランド及びpdunitオペランドの-mオプション

ユニット監視プロセス

pd_alv_portオペランド及びpdunitオペランドの-aオプション

これらのオペランドの指定有無と使用するポート番号を次に示します。

pd_trn_port又は pd_mlg_port又は pd_alv_port | pdunit -t又は -m又は -a | 使用するポート番号
あり | あり | pdunit -t，-m，又は-aの指定
なし | pd_trn_port又はpd_mlg_port又はpd_alv_portの指定
なし | あり | pdunit -t，-m，又は-aの指定
なし | ※

注※

システム共通定義又はユニット制御情報定義にpd_registered_portオペランドを指定した場合，pd_registered_portオペランドに指定した範囲内のポート番号を使用します。pd_registered_portオペランドを指定しない場合，OSが自動的に割り当てたポート番号を使用します。

(d)　HiRDB予約ポート機能で使用するポート番号

HiRDB予約ポート機能で使用するポート番号は，pd_registered_portオペランドに指定します。このオペランドの指定有無と使用するポート番号を次に示します。

指定箇所 | 使用するポート番号
システム共通定義 | ユニット制御情報定義
pd_registered_port | pd_registered_port
あり | あり | ユニット制御情報定義の指定
なし | システム共通定義の指定
なし | あり | ユニット制御情報定義の指定
なし | −

（凡例）−：該当しません。

(e)　スケジューラプロセスの暗号化通信接続用のポート番号

スケジューラプロセスの暗号化通信接続用のポート番号は，pd_crypto_service_portオペランドに指定します。このオペランドの指定有無と使用するポート番号を次に示します。

指定箇所 | 使用するポート番号
システム共通定義 | ユニット制御情報定義
pd_crypto_service_port | pd_crypto_service_port
あり | あり | ユニット制御情報定義の指定
なし | システム共通定義の指定
なし | あり | ユニット制御情報定義の指定
なし | −

（凡例）−：該当しません。

(3)　連絡用ポート番号

「OS環境ファイルの設定」を参照してください。

23.5.3　ポート番号の重複に関する注意事項

HiRDBシステム定義（表「HiRDBで指定するポート番号の一覧」のシステム共通定義及びユニット制御情報定義）で指定するポート番号の重複についての注意事項を次に示します。

同じユニットでは，各オペランドに異なるポート番号を指定してください。

HiRDB/パラレルサーバで，一つのサーバマシン上で複数のユニットを起動する場合，それぞれのユニットの各オペランドには異なるポート番号を指定してください。

一つのサーバマシン上で，複数のHiRDBを起動する場合，それぞれのHiRDBの各オペランドには異なるポート番号を指定してください。

一つのサーバマシン上にHiRDBクライアントとHiRDBサーバがある場合，各オペランドには，クライアント環境定義のPDCLTRCVPORTと異なるポート番号を指定してください。

次の条件を満たすようにポート番号を指定してください。

ほかのプログラムプロダクトが使用しているポート番号と異なる

%windir%¥system32¥drivers¥etc¥services（DNS環境の場合は定義した場所）に登録されたポート番号と異なる

OSが自動的に割り当てるポート番号※の範囲に含まれない

注※　OSが自動的に割り当てるポート番号の範囲はOSによって異なります。

HiRDBのポート番号の指定を省略した場合，HiRDBのポート番号に20000が仮定されます。そのため，各オペランドには20000を指定しないでください。

23.6　HiRDB予約ポート機能

HiRDB予約ポート機能とは，pd_registered_portオペランドでポート番号の範囲を指定して，特定の通信ポート番号の範囲で通信できるようにする機能です。この機能によって，次のようなことが防げます。

HiRDB以外のプログラムがOSの自動割り当てポート番号を多数使用した通信処理をしている場合，通信ポート番号不足が発生して処理が中断される

HiRDBが大量の通信ポート番号を使用し，他プログラムの通信処理に影響を与える

確保したポートはHiRDBが解放しても，ある一定時間は再利用されません。そのため，短時間にポートを使用する処理が大量に発生した場合，ポート番号不足が発生する可能性があります。

HiRDBが大量のポート番号を使用する運用をする場合は，「ポート数不足を回避する方法」を参照してください。

なお，HiRDB予約ポート機能を使用する場合の定義例，及び注意事項については，マニュアル「HiRDB システム定義」のpd_registered_portオペランドの説明を参照してください。

23.6.1　HiRDB予約ポート数の見積もり

(1)　統計情報からの見積もり

統計情報からHiRDBの通信ポート番号の使用数を計れます。統計解析ユティリティの「システムの稼働に関する統計情報」で，次の情報からHiRDBの通信ポート数を算出します。なお，これらの詳細は，マニュアル「HiRDB コマンドリファレンス」を参照してください。

HiRDB予約ポート使用数

HiRDB予約ポートオーバー時のOS自動割り当てポート使用数

計算式

HiRDB予約ポート使用数＋HiRDB予約ポートオーバー時のOS自動割り当てポート使用数＋100※

注※　予備として加算しています。

(2)　推奨値の見積もり

推奨値は，「ユニットが使用する通信ポート数の見積もり」の計算式で求められます。なお，この値は目安です。運用上は「統計情報からの見積もり」の値を使用してください。

付録

付録A　HiRDBの最大値・最小値

付録A.1　システム構成に関する最大値と最小値

HiRDBのシステム構成に関する最大値と最小値を次の表に示します。

表A‒1　HiRDBのシステム構成に関する最大値と最小値

項　目 | 最小値 | 最大値 | 単位
1ユニットに作成できるサーバ数 | 1 | 34 | 個
シングルサーバ数 | 1 | 1 | 個
システムマネジャ数 | 1 | 1 | 個
フロントエンドサーバ数 | 1 | 1,024 | 個
ディクショナリサーバ数 | 1 | 1 | 個
バックエンドサーバ数 | 1 | 16,382 | 個
総RDエリア数 | 3 | 8,388,592 | 個
マスタディレクトリ用RDエリア数 | 1 | 1 | 個
データディレクトリ用RDエリア数 | 1 | 1 | 個
データディクショナリ用RDエリア数 | 1 | 59 | 個
解析情報表及び運用履歴表を格納するデータディクショナリ用RDエリア | 1 | 1 | 個
ユーザ用RDエリア数 | 0 | 8,388,589 | 個
データディクショナリLOB用RDエリア数 | 0 | 2 | 個
ユーザLOB用RDエリア数 | 0 | 8,388,325 | 個
レジストリ用RDエリア数 | 0 | 1 | 個
レジストリLOB用RDエリア数 | 0 | 1 | 個
リスト用RDエリア | 0 | 8,388,588 | 個
1RDエリア中のHiRDBファイル数 | 1 | 16 | 個
1RDエリア中の実表数と順序数生成子数の合計 | 0 | 500 | 個
1RDエリア中のインデクス数 | 0 | 500 | 個
1RDエリア中のリスト数 | 0 | 50,000 | 個
総HiRDBファイル数 | 1 | 134,217,728 | 個
同時アクセス可能実表数 | 4 | 32,000 | 個
最大同時接続数 | 1 | HiRDB/シングルサーバの場合：3,000 HiRDB/パラレルサーバの場合：2,000※１ | 個
HiRDBで作成可能なユーザ数※２ | 1 | 無制限 | 個
同時リスト所有可能ユーザ数 | 0 | 32,767 | 個
1ユーザ当たりのリスト作成数 | 0 | 32,767 | 個
1トランザクション当たりの作業表作成数 | 0 | 512 | 個
1サーバ当たりのグローバルバッファ数※３ | 1 | 2,000,000 | 個
HiRDBファイルシステム領域長 | 1 | 1,048,575 | メガバイト
Windowsのファイル容量 | 0 | 2⁶³−1 | バイト

注※１

マルチフロントエンドサーバ構成の場合，フロントエンドサーバ数×pd_max_users数の上限が2,000になります。

注※２

1ユーザ当たりディクショナリ表（SQL_USERS）を1行消費するため，データディクショナリ用RDエリアの容量に依存します。

注※３

ただし，システム全体では2,147,483,647が上限となります。

付録A.2　データベースに関する最大値と最小値

データベースに関する最大値と最小値を次の表に示します。

表A‒2　データベースに関する最大値と最小値

項　目 | 最小値 | 最大値 | 単位
文字データの長さ （定義長） | CHAR | 1 | 30,000 | 字（バイト）
VARCHAR | 1 | 32,000 | 字（バイト）
各国文字データの長さ （定義長） | NCHAR | 1 | 15,000 | 字
NVARCHAR | 1 | 16,000 | 字
混在文字データの長さ （定義長） | MCHAR | 1 | 30,000 | バイト
MVARCHAR | 1 | 32,000 | バイト
パック形式10進数の精度 | DECIMAL又はNUMERIC | 1 | 38 | けた
パック形式10進数の位取り | DECIMAL又はNUMERIC | 0 | 38 | けた
時刻印データの小数秒精度 | TIMESTAMP | 0 | 6 | けた
BLOBデータの長さ | 1 | 2,147,483,647 | バイト
BINARYデータの長さ（定義長） | 1 | 2,147,483,647 | バイト
表中の列数 | 1 | 30,000 | 列
表中のインデクス数 | 0 | 255 | 個
インデクスの構成列数 | 1 | 64 | 列
クラスタキーの構成列数 | 1 | 64 | 列
表を分割格納するRDエリア数 | 1 | 4,096 | 個
表を分割配置するBES数 | 1 | 4,096 | 個
横分割表を定義時の格納条件に指定する定数の総数（格納条件を省略した場合も1と数える） | 1 | 15,000 | 個
ビュー表の基になる表数 | 1 | 128 | 個
ビュー表の列数 | 1 | 30,000 | 列
主キーの構成列数 | 1 | 64 | 列
外部キーの構成列数 | 1 | 64 | 列
1表中の外部キー数 | 0 | 255 | 個
一つの主キーを参照する外部キー数 | 0 | 255 | 個
1表中に指定できる検査制約定義数 | 0 | 254 | 個
1表中に定義できる検査制約中で指定した論理演算子AND，OR，及び検査制約定義の数の合計（CASE式のWHEN探索条件中の論理演算子のAND及びORは除きます） | 0 | 254 | 個
識別子の長さ （ユーザ識別子，表識別子，列名，データ型識別子，インデクス型識別子，属性名，ルーチン識別子，相関名，インデクス識別子，カーソル名，SQL文識別子，RDエリア名，埋込み変数名，標識変数名，パスワード，制約名，条件名，SQL変数名，問合せ名，トリガ識別子，文ラベル，ループ変数名，ホスト識別子，リスト名，ロール名，SQLパラメタ名，接続制約名） | 1 | 30 | バイト
FIX表の行長 | 1 | 30,000 | バイト
手続き又は関数のSQLパラメタ数 | 0 | 30,000 | 個
繰返し列数 | 2 | 30,000 | 個
IPアドレスによる接続制限の登録数 | 0 | 10,000 | 個
1サーバで生成するインデクス情報ファイル数 | − | −※１ | −

次に示すユティリティがメッセージに表示できる処理行数

pdload

pdrorg

pdrbal

0

4,294,967,295※２

件

注※１

プラグイン使用の有無，サーバ内のRDエリア数などによって最大値は変動します。なお，プラグインインデクスの遅延一括作成にHiRDBファイルシステム領域を使用する場合，最大値は4,096になります。

注※２

4,294,967,295件以上のデータを処理した場合，表示行数が一度0にリセットされ，再度1からカウントアップします。

付録A.3　HiRDBファイル名に関する最大値と最小値

HiRDBファイル名に関する最大値と最小値を次の表に示します。

表A‒3　HiRDBファイル名に関する最大値と最小値（単位：文字）

HiRDBファイル種別 | HiRDBファイルに指定できるファイル名の長さ | パス名の長さ※の最大値
最小値 | 最大値
システムステータスファイル | 1 | 30 | 167
サーバステータスファイル | 1 | 30 | 167
システムログファイル | 1 | 30 | 167
シンクポイントダンプファイル | 1 | 30 | 167
アンロードログファイル | 1 | 30 | 167
監査証跡ファイル | 16 | − | 167
作業表用ファイル | 25 | − | 167
RDエリア構成ファイル | 1 | 30 | 167
バックアップファイル | 1 | 30 | 167
アンロードデータファイル | 1 | 30 | 167
インデクス情報ファイル | 30 | − | 167
差分バックアップ管理ファイル | 1 | 30 | 167

（凡例）−：該当しません。最小値の欄に記載されている値が固定値です。

注※

パス名の長さは，「HiRDBファイルシステム領域¥HiRDBファイル」の長さです。

付録B　HiRDBのプロセス一覧

ここでは，HiRDBで起動するプロセスについて説明します。

付録B.1　HiRDB/シングルサーバで起動するプロセス

HiRDBで起動するプロセスの構造を次に示します。

HiRDB/シングルサーバで起動するプロセスを次の表に示します。

表B‒1　HiRDB/シングルサーバで起動するプロセス（システムサーバ）

プロセス名 | 説明 | プロセス数 | サーバ名称
マニュアルでの表記 | プロセス名称
HiRDBサービスプロセス | pdservice | プロセスサーバの制御 | 1 | −
リモート受け付けプロセス | pdrshsrv | リモートシェル・リモートコピーの実行受け付け | 1（pdntenvコマンドでリモート機能を有効にした場合に起動します） | −
プロセスサーバプロセス | pdprcd | HiRDB関連プロセスの管理 | 1 | _prc
後処理プロセス | pdrsvre | プロセス異常終了時の後始末処理 | pd_process_terminatorの指定値がfixedの場合：pd_process_terminator_maxの値 pd_process_terminatorの指定値がresidentの場合：3〜HiRDBが規定したプロセス数 pd_process_terminatorの指定値がnonresidentの場合：0〜異常終了したプロセス数 | _admrsvr

サーバモード系切り替え用HiRDB起動プロセス

pdstart2d

クラスタソフトウェアと連動したHiRDBプロセスの起動制御

ユーザサーバホットスタンバイを行わないスタンバイ型系切り替え

ユーザサーバホットスタンバイ

高速系切り替え

1（オンライン時はなし）

_pdstrt2

メッセージログサーバプロセス | pdmlgd | メッセージ出力制御 | 1 | _mlg
システムマネジャプロセス | pdrdmd | ユニット起動・停止制御，接続ユーザ管理 （なお，ネームサービス，又はノードマネジャと表記している場合があります） | 1 | _rdm
ステータスサーバプロセス | pdstsd | ユニット用ステータスファイルの入出力制御 | 1 | _sts0
スケジューラプロセス | pdscdd | シングルサーバプロセスへのトランザクションの割り当て （なお，ロックサーバと表記している場合があります） | 1 | _scd
トランザクションサーバプロセス | pdtrnd | トランザクション制御 | 1 | _trn
トランザクション回復プロセス | pdtrnrvd | トランザクションの決着・回復制御 | 1〜ダウンしたpdsds数※1 | _trnrcv
監査証跡管理サーバプロセス | pdaudd | 監査証跡管理 | pd_aud_file_nameの指定がある場合は1，ない場合は0 | _aud
監査証跡自動データロード制御プロセス | pdaudld | 自動データロード用pdloadの起動制御 | pd_aud_file_nameの指定があり，かつpd_aud_auto_loadingにYを指定している場合は1，それ以外は0 | _audld
トラブルシュート情報取得プロセス | pdprfd | トラブルシュート機能の制御 | 1 | −
ログサーバプロセス | pdlogd | システムログ取得制御，ログ関連プロセス制御 | 1 | _logN
デファードライトプロセス | pd_buf_dfw | DB格納ディスクへのバックグラウンドライト | 1 | 1dfwN
非同期READプロセス | pd_ios_ard | 非同期READ機能 | pd_max_ard_processの値 | 1ardN
デファードライト処理用並列WRITEプロセス | pd_buf_awt | デファードライト処理の並列WRITE機能 | pd_dfw_awt_processの値 | 1awtN
REDOプロセス | pd_rcv_rd | 全面リラン時のDBの前進復帰 | MIN（接続ディスク数，pd_max_recover_processの値） 接続ディスク数：RDエリアを定義した論理ボリューム数 pd_rdarea_open_attribute_useにYを指定している場合はpd_max_recover_processの値※2 | 2rrnM
ログスワッパプロセス | pdlogswd | システムログ関連ファイルの割り当て・解放・入出力管理，シンクポイントダンプ取得 | 1 | _logNs
デッドロック監視プロセス | pdlckmnd | 排他制御処理の分散を行っている場合のデッドロック検知 | pd_lck_pool_partitionに2以上を指定し，かつpd_lck_deadlock_checkにYを指定すると1，それ以外は0 | _lckmnN

表B‒2　HiRDB/シングルサーバで起動するプロセス（ユーザサーバ）

プロセス名 | 説明 | プロセス数 | サーバ名称
マニュアルでの表記 | プロセス名称
シングルサーバプロセス | pdsds | SQL処理 | pd_max_usersの値※3 | サーバ名※4

表B‒3　HiRDB/シングルサーバで起動するプロセス（ユティリティサーバ）

プロセス名※5 | 説明 | プロセス数 | サーバ名称
マニュアルでの表記 | プロセス名称
pdinit制御プロセス | pdinitd | 初期設定ユティリティ実行プロセス | 1 | 0minit0
pdcopyバックアップ出力プロセス | pdcopyb | バックアップファイル出力 | 多重度数×コマンド同時実行数 | 0bcpy?0※6
pdcopyデータベース読み込みプロセス | pdcopyr | データベース読み込み | コマンド同時実行数 | 0rcopy0
pdrstrバックアップ読み込みプロセス | pdrstrb | バックアップファイル読み込み | コマンド同時実行数 | 0brstr0
pdrstrマスタディレクトリ用RDエリア読み込みプロセス | pdrstrm | マスタディレクトリ用RDエリア読み込み | コマンド同時実行数 | 0mrstr0
pdrstrアンロードログ読み込みプロセス | pdrstrl | アンロードログファイル読み込み | コマンド同時実行数 | 0lrstr0
pdrstrデータベース書き込みプロセス | pdrstrr | データベース書き込み | コマンド同時実行数 | 0brstr0
pdrstrマスタディレクトリ用RDエリア書き込みプロセス | pdrstrw | マスタディレクトリ用RDエリア書き込み | コマンド同時実行数 | 0wrstr0
pdload制御プロセス | pdloadm | データロード制御 | pdloadコマンド同時実行数 | 0mload0
pdrorg制御プロセス | pdrorgm | DB再編成制御（アンロード，リロード，インデクス再編成・再作成，空きページ解放，及びグローバルバッファ常駐化） | pdrorg，pdreclaim，pdpgbfonコマンド同時実行数 | 0mrorg0
pdgetcst制御プロセス | pdgcstm | 最適化情報収集 | pdgetcstコマンド同時実行数 | 0mgcst0
pddbst制御プロセス | pddbst1 | DB状態解析制御 | pddbstコマンド同時実行数 | 0mdbst0
pdexp制御プロセス | pdexpm | ディクショナリ搬出入制御 | 1 | 0mexp0
pdplgexe制御プロセス | pdplgexm | プラグインユティリティ実行制御 | プラグインが提供するコマンド同時実行数 | 0mplge0
MIBパフォーマンス情報取得プロセス | pdmbcd | pdmibcmdコマンドによって指定されたMIBパフォーマンス情報の取得 | 1 | 0mbcd0

（凡例）

−：該当しません。

注

サーバ名称のxxxNはユーザサーバ数によって1，2，…ユニット最大サーバ数と増加します。

サーバ名称のxxxMは定義によって2〜11と増加します。

サーバ名称はメッセージ出力やコマンド情報出力などで使用されます。

注※1

ダウンしたpdsds数が二つ以上発生した場合に，ダウンした数と同数まで増加します。ダウンしたpdsdsのトランザクションが決着するに従ってプロセス数は減少し，回復対象となるトランザクションがなくなると1に戻ります。上限値を次に示します。

MIN（↓pd_trn_rcvmsg_store_buflenの値÷72↓，pd_max_usersの値×2＋7）

注※2

REDOプロセスは，HiRDB開始時に起動され，起動が完了すれば停止します。

注※3

ユティリティサーバの場合にはプロセス数は0となります。計算後に2000を超える場合には2000までが起動されるプロセスとなります。また，pd_process_countが指定されている場合には起動プロセス数は指定値分となります。pd_process_countを超えるアクセス要求があった場合は，同時処理するために同時アクセス数のプロセスをpd_max_usersの値まで起動します。

注※4

システム共通定義のpdstartオペランドの-sオプションで指定するサーバ名です。

注※5

対応するコマンドが実行中のときだけプロセスが起動され，コマンドが終了すればプロセスは停止します。

注※6

「?」は，バックアップ出力プロセスの多重度数（pdcopyの-fオプションで指定した制御文ファイル中の-ｂオプション指定値数）によって，0，1，…fと増加します。

付録B.2　HiRDB/パラレルサーバで起動するプロセス

HiRDBで起動するプロセスの構造を次に示します。

HiRDB/パラレルサーバで起動するプロセスを次の表に示します。

表B‒4　HiRDB/パラレルサーバで起動するプロセス（システムサーバ）（1/2）

プロセス名 | 説明 | プロセス数 | サーバ名称 | サーバごとのプロセスの起動有無
マニュアルでの表記 | プロセス名称
MGR | 非MGR
HiRDBサービスプロセス | pdservice | プロセスサーバの制御 | 1 | − | − | −
リモート受け付けプロセス | pdrshsrv | リモートシェル・リモートコピーの実行受け付け | 1（pdntenvコマンドでリモート機能を有効にした場合に起動します） | − | − | −
プロセスサーバプロセス | pdprcd | HiRDB関連プロセスの管理 | 1 | _prc | ○ | ○
後処理プロセス | pdrsvre | プロセス異常終了時の後始末処理 | pd_process_terminatorの指定値がfixedの場合：pd_process_terminator_maxの値 pd_process_terminatorの指定値がresidentの場合：3〜HiRDBが規定したプロセス数 pd_process_terminatorの指定値がnonresidentの場合：0〜異常終了したプロセス数 | _admrsvr | ○ | ○

サーバモード系切り替え用HiRDB起動プロセス1

pdstart2d

クラスタソフトウェアと連動したHiRDBプロセスの起動制御

ユーザサーバホットスタンバイを行わないスタンバイ型系切り替え

ユーザサーバホットスタンバイ

高速系切り替え

1：1スタンバイレス型系切り替えの実行系

1（オンライン時はなし）

_pdstrt2

○

○

サーバモード系切り替え用HiRDB起動プロセス２ | pdstart2a | クラスタソフトウェアと連動したHiRDBプロセスの起動制御 1：1スタンバイレス型系切り替えの待機系 | 1（オンライン時はなし） | _pdst2a1 | × | ○
サーバモード系切り替え用HiRDB起動プロセス３ | pdsvstartd | クラスタソフトウェアと連動したHiRDBプロセスの起動制御 影響分散スタンバイレス型系切り替えの待機系 | pd_ha_agentにactiveunitsを指定している場合は1，それ以外は0 | _pdsvstd | × | ○
トラブルシュート情報取得プロセス | pdprfd | トラブルシュート機能の制御 | 1 | − | ○ | ○
メッセージログサーバプロセス | pdmlgd | メッセージ出力制御 （pd_mlg_msg_log_unitにlocalを指定している場合に起動します） | 1 | _mlg | ○ | ○
システムマネジャ（MGRユニット）プロセス | pdrdmd | ユニット起動・停止制御，接続ユーザ管理 （なお，ネームサービス，又はノードマネジャと表記している場合があります） | 1 | _rdm | ○ | ×
ノードマネジャ（非MGRユニット）プロセス | pdndmd | ユニット起動・停止制御，接続ユーザ管理 （なお，ネームサービスと表記している場合があります） | 1 | _ndm | × | ○
ステータスサーバプロセス | pdstsd | ユニット用ステータスファイルの入出力制御 | 1 | _sts0 | ○ | ○
スケジューラプロセス | pdscdd | バックエンドサーバプロセス，ディクショナリサーバプロセス，及びフロントエンドサーバプロセスの割り当て （なお，ロックサーバと表記している場合があります） | 1 | _scd | ○ | ○
トランザクションサーバプロセス | pdtrnd | トランザクション制御 | 1 | _trn | ○ | ○

トランザクション回復プロセス

pdtrnrvd

トランザクションの決着・回復制御

FESの場合：

1〜ダウンしたpdfes数※1

DSの場合：

1〜ダウンしたpddic数※1

BESの場合：

1〜ダウンしたpdbes数※1

_trnrcv

○

○

監査証跡管理サーバプロセス | pdaudd | 監査証跡管理 | pd_aud_file_nameの指定がある場合は1，ない場合は0 | _aud _auz※2 | ○ | ○
監査証跡自動データロード制御プロセス | pdaudld | 自動データロード用pdloadの起動制御 | 監査証跡管理サーバプロセスの条件に合わせてpd_aud_auto_loadingにYを指定している場合は1，N又は指定していない場合は0 | _audld | ○ | ×
ユニット監視プロセス | pdrdma | HiRDBユニットが稼働しているかどうかの監視をおこなう | 1（ユニット数が1の場合は0） | _rdmck | ○ | ×

表B‒5　HiRDB/パラレルサーバで起動するプロセス（システムサーバ）（2/2）

プロセス名 | 説明 | プロセス数 | サーバ名称 | サーバごとのプロセスの起動有無
マニュアルでの表記 | プロセス名称
BES | DS | FES
ログサーバプロセス | pdlogd | システムログ取得制御，ログ関連プロセス制御 | 1 | _logN _lozN※2 | ○ | ○ | ○
デファードライトプロセス | pd_buf_dfw | DB格納ディスクへのバックグラウンドライト | 1 | 1dfwN 1dfzN※2 | ○ | ○ | ×
非同期READプロセス | pd_ios_ard | 非同期READ機能 | pd_max_ard_processの値 | 1ardN 1arzN※2 | ○ | ○ | ×
デファードライト処理用並列WRITEプロセス | pd_buf_awt | デファードライト処理の並列WRITE機能 | pd_dfw_awt_processの値 | 1awtN 1awzN※2 | ○ | ○ | ×
REDOプロセス | pd_rcv_rd | 全面リラン時のDBのロールフォワード | MIN（接続ディスク数，pd_max_recover_processの値） 接続ディスク数：RDエリアを定義した論理ボリューム数 pd_rdarea_open_attribute_useの値がYの場合はpd_max_recover_processの値※3 | 2rrnM 2rrzM※2 | ○ | ○ | ×
ログスワッパプロセス | pdlogswd | システムログ関連ファイルの割り当て・解放・入出力管理，シンクポイントダンプ取得 | 1 | _logsN _lozsN※2 | ○ | ○ | ○

デッドロック監視プロセス

pdlckmnd

排他制御処理の分散を行っている場合のデッドロック検知

FESの場合：

pd_fes_lck_pool_partitionに2以上を指定し，かつpd_lck_deadlock_checkにYを指定した場合は1，それ以外は0

DS，BESの場合：

pd_lck_pool_partitionに2以上を指定し，かつpd_lck_deadlock_checkにYを指定した場合は1，それ以外は0

_lckmnN

_lckmzN※2

○

○

○

表B‒6　HiRDB/パラレルサーバで起動するプロセス（ユーザサーバ）

プロセス名 | 説明 | プロセス数 | サーバ名称 | サーバごとのプロセスの起動有無
マニュアルでの表記 | プロセス名称
BES | DS | FES
バックエンドサーバプロセス | pdbes | データベースへのアクセス | MAX（pd_max_usersの値，pd_max_bes_processの値） | サーバ名※4 | ○ | × | ×
ディクショナリサーバプロセス | pddic | ディクショナリ表の一括管理 | MAX（pd_max_usersの値，pd_max_dic_processの値） | サーバ名※4 | × | ○ | ×
フロントエンドサーバプロセス | pdfes | SQL処理，バックエンドサーバへの指示 | pd_max_usersの値 | サーバ名※4 | × | × | ○

表B‒7　HiRDB/パラレルサーバで起動するプロセス（ユティリティサーバ）

プロセス名 | 説明 | プロセス数 | サーバ名称 | サーバごとのプロセスの起動有無
マニュアルでの表記 | プロセス名称
BES | DS | FES
pdinit制御プロセス | pdinitd | 初期設定ユティリティ実行プロセス | 1 | 0minit0 | × | ○ | ×
pdinit実行プロセス | pdinitb | 初期設定ユティリティBES側実行プロセス | 1〜2 | 0sinit0 | ○ | × | ×
pdcopyバックアップ出力プロセス | pdcopyb | バックアップファイル出力 （pdcopyに指定したバックアップ出力先（-bオプション）に起動します） | 多重度数×pdcopyコマンド同時実行数 | 0bcpy?0※5 | × | × | ×
pdcopyデータベース読み込みプロセス | pdcopyr | データベース読み込み | 複写対象サーバ数※6 | 0rcopyN | ○ | ○ | ×
pdrstrバックアップ読み込みプロセス | pdrstrb | バックアップファイル読み込み （pdrstrに指定したバックアップ読み込み先（-bオプション）に起動します） | pdrstrコマンド同時実行数 | 0brstr0 | × | × | ×
pdrstrマスタディレクトリ用RDエリア読み込みプロセス | pdrstrm | マスタディレクトリ用RDエリア読み込み※7 | pdrstrコマンド同時実行数 | 0mrstr0 | × | ○ | ×
pdrstrアンロードログ読み込みプロセス | pdrstrl | アンロードログファイル読み込み※8 | pdrstrコマンド同時実行数 | 0lrstr0 | × | × | ×
pdrstrデータベース書き込みプロセス | pdrstrr | データベース書き込み | 回復対象サーバ数※9 | 0brstrN | ○ | ○ | ×
pdrstrマスタディレクトリ用RDエリア書き込みプロセス | pdrstrw | マスタディレクトリ用RDエリア書き込み※10 | 1 | 0wrstr0 | × | ○ | ×
pdload制御プロセス | pdloadm | データロード制御 | pdloadコマンド同時実行数 | 0mload0 | ○ | ○ | ○
pdrorg制御プロセス | pdrorgm | DB再編成制御（アンロード，リロード，インデクス再編成・再作成，空きページ解放，及びグローバルバッファ常駐化） | pdrorg,pdreclaim,pdpgbfonコマンド同時実行数 | 0mrorg0 | ○ | ○ | ○
pdrbal制御プロセス | pdrbalm | リバランス制御 | pdrbalコマンド同時実行数 | 0mrbal0 | × | ○ | ×
pdgetcst制御プロセス | pdgcstm | 最適化情報収集 | pdgetcstコマンド同時実行数 | 0mgcst0 | × | ○ | ×
pddbst制御プロセス | pddbst1 | DB状態解析制御 （MGRユニットで起動します） | pddbstコマンド同時実行数 | 0mdbst0 | × | × | ×
pdexp制御プロセス | pdexpm | ディクショナリ搬出入制御 （搬出ファイルがあるユニットに起動します） | 1 | 0mexp0 | × | × | ×
pdplgexe制御プロセス | pdplgexm | プラグインユティリティ実行制御 | プラグインが提供するコマンド同時実行数 | 0mplge0 | × | ○ | ×
MIBパフォーマンス情報取得プロセス | pdmbcd | pdmibcmdコマンドによって指定されたMIBパフォーマンス情報を取得する （MGRユニットで起動します） | 1 | 0mbcd0 | × | × | ×

（凡例）

○：プロセスが起動します。

×：プロセスが起動しません。

−：該当しません。

注

サーバ名称のxxxNはユーザサーバ数によって1，2，…ユニット最大サーバ数と増加します。

サーバ名称のxxxMは定義によって2〜（ユニット最大サーバ数×11）と増加します。

注※1

ダウンしたpdbes，pdfes，pddic数が二つ以上発生した場合に，ダウンした数と同数まで増加します。ダウンしたpdbes，pdfes，pddicのトランザクションが決着するに従ってプロセス数は減少し，回復対象となるトランザクションがなくなると1に戻ります。上限値を次に示します。

FESの場合：pd_max_usersの値×2＋7

DSの場合：pd_max_dic_processの値×2＋7

BESの場合：pd_max_bes_processの値×2＋7

なお，ユニット当たりの上限値は↓pd_trn_rcvmsg_store_buflenの値÷72↓です。ユニット内のFES，DS，BESごとに求めた値の総和がこれより大きい場合でも，ユニット当たりの最大プロセス数はこの値になります。

注※2

1：1スタンバイレス型系切り替え構成の場合で，代替BESユニット用に起動するときの名称です。

注※3

REDOプロセスは，HiRDB開始時に起動され，起動が完了すれば停止します。

注※4

システム共通定義のpdstartオペランドの-sオプションで指定するサーバ名です。

注※5

「?」は，バックアップ出力プロセスの多重度数（pdcopyの-fオプションで指定した制御文ファイル中の-ｂオプション指定値数）によって，0，1，…fと増加します。

注※6

pdcopyに指定した複写対象（-r，-s，-u，-aオプション）のRDエリアが属するサーバ数分起動します。

注※7

pdrstrに指定したバックアップファイル（-bオプション）があるホストと，ディクショナリサーバがあるホストが異なる場合に起動します。また，pdrstrに指定したバックアップファイル（-bオプション）の出力先ホストと，ディクショナリサーバがあるホストが異なる場合に起動します。

注※8

pdrstrでアンロードログファイル（-lオプション）又はディレクトリ（-dオプション）を指定した場合に，回復対象が2サーバ以上あるとき，若しくはアンロードログファイルが格納されているホストと回復対象のRDエリアが属するサーバがあるホストとが異なるときに起動します。

注※9

pdrstrに指定した回復対象（-r，-s，-u，-c，-aオプション）のRDエリアが属するサーバ数分起動します。

注※10

回復対象にマスタディレクトリ用RDエリアを指定し，バックアップファイルがあるホストとディクショナリサーバがあるホストが異なる場合に起動します。

付録C　Q＆A

HiRDBシステムの構築に関する事例をQ&A形式でまとめています。

付録C.1　インストールディレクトリに関する質問

質問

インストールディレクトリについて，何か注意することはありますか？

お答えします

インストールディレクトリの名称を指定するときには，次に示す項目に注意してください。なお，インストール時に指定されたインストールディレクトリのパス名は，HiRDBコマンドプロンプト上で環境変数PDDIRを参照することにより確認できます。

ドライブで始まり，次の要素で構成される文字列で指定してください。

英数字

_（下線）

.（ピリオド）

△（空白）

( （左括弧）

) （右括弧）

パス区切りの¥

ドライブだけの指定はできません。

全角文字，及び特殊記号は使用しないでください。

長さは200バイト以内にしてください。

ジャンクションポイント，又はシンボリックリンクを含むパスにはインストールできません。

システム共通定義のpdunitオペランドで指定するHiRDB運用ディレクトリ名と，同じ名称にしてください。

付録C.2　1073エラーに関する質問

質問

インストール時に1073エラーになります。

お答えします

この1073エラーは，HiRDBのアンインストール後にOSを再起動しないで，再度HiRDBをインストールしたときに発生します。HiRDBをインストール，又はアンインストールした後には，OSを再起動する必要があります。対処方法については，「インストール時に1073エラーになったときの対処」を参照してください。

付録C.3　仮想メモリの見積もり方法に関する質問

質問

仮想メモリの見積もり方法について教えてください。

お答えします

一般的には実メモリの2，3倍程度ですが，仮想メモリはディスクを使用するため，大き過ぎるとディスクを圧迫することになります。これらを考慮して，見積もってください。

なお，実メモリを使用するか，又は仮想メモリを使用するかの制御は，OSが管理しています。HiRDBでは制御できません。

付録C.4　ネットワークドライブの使用に関する質問

質問

ネットワークドライブは使用できますか？

お答えします

使用できません。HiRDBのインストールもそうですが，ユティリティのバックアップファイルなどもすべてローカルドライブを使用してください。

付録C.5　システム共通定義のpdstartオペランドに指定するホスト名に関する質問

質問

システム共通定義のpdstartオペランドに指定するホスト名は，どこの設定に対応しているのですか？

お答えします

［コントロールパネル］−［ネットワーク］の「ネットワークの設定」のTCP/IPのプロパティをクリックしてください。「DNS設定」のホストに設定されている名称がホスト名です。この設定値は，コマンドプロンプトからhostnameコマンドを実行しても確認できます。

付録C.6　HiRDB/Developer's Kitに関する質問

質問

HiRDB/Developer's Kitはどのようなときに必要ですか？

お答えします

HiRDBサーバがあるマシンでUAPを作成する場合は，HiRDBサーバにHiRDB/Developer's Kitの機能が含まれているので必要ありません。HiRDBサーバがあるマシンとは別のマシンでUAPを開発する場合に必要です。

また，HiRDBサーバと異なるプラットフォームのUAPを作成する場合にも必要です。

付録C.7　データベース定義ユティリティ（pddef）の実行に関する質問

質問

データベース定義ユティリティ（pddef）でCREATE TABLEを実行したのですが，何も実行されませんでした。なぜですか？

お答えします

pddefの制御文でセミコロン（;）の後ろに空白が入っていませんか？空白が入っていると，そのSQL文は実行されません（この例では，CREATE TABLE以降の指定は省略しています）。

（誤）CREATE TABLE ;△ △：空白

（正）CREATE TABLE ;

付録C.8　表の最大容量に関する質問

質問

HiRDBの表の最大容量はどのくらいですか？

お答えします

一つの表は最大4,096個のRDエリアに分割格納でき，一つのRDエリアは最大16個のHiRDBファイルで構成できます。

一つのHiRDBファイルの最大容量が64ギガバイトになるため，1表の最大容量は次のようになります。

1表の最大容量

4096×16×64ギガバイト＝約4ペタバイト

付録C.9　OpenTP1とのXAインタフェースに関する質問

質問

OpenTP1とHiRDBの連携時，参照するだけのSQLであれば，そのトランザクションのコミットはXAインタフェースを通らないように思えますが，どうでしょうか？

お答えします

参照するだけのSQLであっても，コミット時には必ずXAインタフェースを経由してHiRDBに処理が渡されます。ただし，更新SQLがあるときのコミットに比べると，走行するステップ数が少なくなります。

付録C.10　FIX表の性能に関する質問

質問

FIX表とそうでない表（非FIX表）の性能差はどれくらいありますか？

お答えします

操作対象列数や操作対象行数によって性能差は変わるため一概には言えませんが，1列の大量更新でFIX指定をした場合の実行時間が，FIX指定をしなかった場合に比べ，約2/3になった事例があります。

FIX指定の方が性能劣化しないため，次に示す条件を満たす場合はFIX指定にしてください。

可変長の列がない

NULL値を持つ列がない

付録C.11　重複キーインデクスに関する質問

質問

重複したキーに対してもインデクスを定義できますか？

定義できるなら，それによって何か困ることが生じるのでしょうか？

お答えします

インデクスは定義できます（非UNIQUE属性）。ただし，大量の重複キー（201件以上）があるインデクスは特殊な格納構造になってアクセスするインデクスページが増えるため，性能上好ましくありません。

付録C.12　横分割表のインデクス定義に関する質問

質問

サーバマシン間に分割された表に対してインデクスを定義する場合，どのようにインデクスを配置すればよいですか？

お答えします

次のように分割表単位にインデクスも分割してください。

付録C.13　シンクポイントダンプの運用に関する質問

質問

シンクポイントダンプファイルの有効保証世代数とはどのようなことですか？

お答えします

シンクポイントダンプファイルには，全面回復処理に備えてシステムログファイルをどの位置から読み始めればよいかなどの情報をシンクポイントごとに取得します。シンクポイントダンプファイルに格納されている位置情報が示すシステムログファイル以降のシステムログファイルは，全面回復処理で使用する可能性があるため，上書き禁止状態にして保護しています。

有効保証世代数とは，「シンクポイントダンプファイルの何世代分の位置からシステムログファイルを上書き禁止にして保護するか」ということです。つまり，有効保証世代数が1の場合は，最新のシンクポイントダンプファイルが示すシステムログファイル以降が上書き禁止状態になります。有効保証世代数が2の場合は，最新のシンクポイントダンプファイルの1世代前のシンクポイントダンプファイルが示すシステムログファイル以降が上書き禁止状態になります。

付録C.14　ステータスファイルに関する質問

(1)　ステータスファイルの運用に関する質問（ステータスファイルの二重化）

質問

ステータスファイルの二重化のペアはどのように構成するのですか？

次のように論理ファイル1のA系と論理ファイル2のB系が障害の場合，論理ファイル2のA系と論理ファイル1のB系でペアを組むことはありますか？

お答えします

異なる論理ファイル間でペアを組むことはありません。A系，B系が両方とも正常な論理ファイルにスワップします。A系，B系の両方とも正常な論理ファイルが一つもない場合は，pd_sts_singleoperationオペランドの指定に従ってユニットを異常終了するか，又は片系運転で処理を続行します。

(2)　ステータスファイルの運用に関する質問（障害発生時）

質問

A系，B系の両方とも正常な論理ファイルが一つもない（A系，B系のどちらかが障害）場合の処理方式を決める次に示すオペランドがあります。

pd_syssts_singleoperation = stop｜continue（ユニット用ステータスファイルの場合）

pd_sts_singleoperation = stop｜continue（サーバ用ステータスファイルの場合）

stopとcontinue，どちらを指定すればよいですか？

お答えします

stopを指定すると，HiRDB（HiRDB/パラレルサーバの場合はユニット）が異常終了します。continueを指定すると，ステータスファイルを片系運転します。

ステータスファイルは，全面回復処理のための情報を記録している重要なファイルです。continueを指定して片系運転中にステータスファイルが障害になると，両系障害でユニットが異常終了します。そして，現用ファイルが両系ともアクセスできないため，全面回復処理ができなくなります。したがって，次のような考え方で判断してください。

HiRDBの異常終了よりも，全面回復処理の保証を重視する場合はstopを指定します。

とにかくHiRDBを途中で停止したくない（最悪の場合，全面回復処理はあきらめ，データベースをバックアップ時点まで戻したりデータロードし直す）場合はcontinueを指定します。

(3)　ステータスファイルの運用に関する質問（ステータスファイルの定義）

質問

論理ステータスファイルは1〜7個定義できますが，ディスクに余裕がありません。どの程度用意するのが現実的ですか？

お答えします

ディスクを障害回復して再使用可能になるまでの安全性を考えると，論理ステータスファイルは三つ（二重化×3=6ファイル）以上用意することをお勧めします。

ディスクに余裕がなければ，論理ステータスファイルは二つ（二重化×2=4物理ファイル）が妥当です。この場合，障害発生時には速やかにステータスファイルを回復してください。

論理ステータスファイルを一つしか用意しないと，ステータスファイルの障害発生時にデータベースをバックアップから回復する必要があります。

(4)　ステータスファイルの運用に関する質問（ステータスファイルの配置）

質問

ステータスファイルはどのようにディスクに配置すればよいですか？

お答えします

基本は，複数の物理ステータスファイルを同じディスクに配置しないことです。同じディスクに配置すると，二重化や論理ファイルの複数化の意味がなくなります。つまり，論理ファイルを二つ定義している場合は四つのディスクに分散配置し，論理ファイルを三つ定義している場合は六つのディスクに分散配置します。

なお，次のように，物理ステータスファイルをリング状に配置すると，少ないディスク数で信頼性を確保できます。

論理ファイル数6の場合の配置例

このように配置すると，1ボリュームに障害が発生しても，2世代の両系ファイルが無事のままです。

付録C.15　作業表用HiRDBファイルシステム領域の最大使用量に関する質問

質問

作業表用ファイルを作成するHiRDBファイルシステム領域（バックエンドサーバ定義のpdworkオペランド）の最大使用量，最大使用ファイル数，最大使用増分回数を知りたいのですが，手段がありますか？

お答えします

pdfstatfsコマンドで取得できます。

pdfstatfs -d 作業表用HiRDBファイルシステム領域名

「-d」は，HiRDBファイルシステム領域に割り当てた領域の最大使用量，最大使用ファイル数，最大使用増分回数を表示するオプションです。出力の「peak capacity」が最大使用量，「peak file count」が最大使用ファイル数，「peak expand count」が最大使用増分回数です。

なお，上記の最大使用量は，pdfstatfsコマンドでクリアできます。

pdfstatfs -c 作業表用HiRDBファイルシステム領域名

「-c」は，HiRDBファイルシステム領域に割り当てた領域の最大使用量，最大使用ファイル数，最大使用増分回数を0にするオプションです。

注意事項

pdfstatfsコマンドの「-c」オプションは，HiRDBファイルシステム領域の使用目的が「WORK」又は「UTL」の場合に有効です。

なお，HiRDBファイルシステム領域の使用目的は，pdfmkfsコマンドの-kオプションで指定します。

付録C.16　pdstartコマンドに関する質問

(1)　pdstartコマンドでHiRDBが開始しない場合

質問

pdstartコマンドでHiRDBが開始しないで，Psp4017で-prcがアボートしてしまうのはなぜですか？

お答えします

次に示す原因が考えられます。

HiRDBが正しくセットアップされていない

HiRDBを正しくセットアップし直してください。

(2)　pdstartコマンドで特定のユニットが開始しない場合

質問

pdstartコマンドを実行しましたが，システムマネジャ以外のユニットが開始しないのはなぜですか？

お答えします

開始できなかったユニットのシステム共通定義を確認してください。pdunit又はpdstartオペランドの指定値が，システムマネジャがあるユニットのシステム共通定義と一致していない可能性があります。

開始できなかったユニットのシステム共通定義を修正した後に，pdstart -uコマンドでユニットを再開始してください。

(3)　pdstartコマンドでHiRDBの開始が遅い場合

質問

pdstartコマンドを入力して，コマンドがKFPS05078-I Unable to recognize HiRDB initialization Completionで終了しましたが，すべてのユニットの開始に時間が掛かるのはなぜですか？

1時間〜2時間ぐらいで開始しました。

お答えします

KFPS00608-W（-314）メッセージが複数出力されている場合は，すべてのユニットのシステム共通定義を確認してください。pdunit及びpdstartオペランドで指定したホスト名がすべて一致しているか，正しいホスト（存在するホスト）名が指定されているかを確認してください。

HiRDBで指定したホスト，ネットワークがすべて開始完了（稼働中）になっているかを確認してください。

(4)　pdstartコマンドがエラーリターンする場合（reason code=TIMEOUT）

質問

pdstartコマンドがKFPS01861-Eメッセージ（reason code=TIMEOUT）を出力してエラーリターンしてしまいます。なぜですか？

お答えします

次に示す原因が考えられます。

ユニット開始に予想以上に時間が掛かってしまった

サーバ共通定義又は各サーバ定義の指定に誤りがある

次に示す対策をしてください。

pd_start_time_outオペランドの指定値を大きくしてから，pdstartコマンドを再入力してください。

イベントログに出力されているHiRDBのメッセージを参照して，誤っている定義を修正してください。

付録C.17　データベース定義ユティリティ（pddef）がエラーになる場合

質問

データベース初期設定ユティリティ（pdinit）は実行できましたが，データベース定義ユティリティ（pddef）がエラーになって実行できません。どんな原因が考えられますか？

お答えします

次に示す原因が考えられます。

応答なしや接続エラーになる場合は，環境変数の設定漏れが考えられます。

PDHOST，PDNAMEPORTの設定値を確認してください。

PDHOST：

HiRDBサーバがあるホスト名を指定します。システム共通定義のpdstartオペランドに指定したホスト名を指定します。

PDNAMEPORT：

システム共通定義のpd_name_portオペランドに指定したポート番号を指定します。

コネクトエラーとなる場合，環境変数PDUSERの設定値の不正が考えられます。

pdinitの実行直後は，DBA権限を持つ認可識別子が一つだけ存在します。認可識別子及びパスワードをhirdb.iniファイルの環境変数PDUSERに指定してください。

注意事項

pdinit実行直後の認可識別子とパスワードについては，マニュアル「HiRDB コマンドリファレンス」の「データベース初期設定ユティリティ（pdinit）」の「オプション」を参照してください。

環境変数PDUSERを設定するときは，認可識別子とパスワードを引用符で囲み，その外側をアポストロフィで囲んでください。これは，ほかのHiRDBのユティリティを実行する場合や，UAPを実行する場合も同じです。

付録C.18　CREATE TABLE文のLOB列定義に関する質問

質問

CREATE TABLE文の列定義で，LOB列の最大長を指定した場合（例：300メガバイト）と指定しなかった場合（省略値2ギガバイト）では，HiRDBサーバとHiRDBクライアントのメモリ所要量やデータ転送量にどのような違いがありますか？

お答えします

LOB列の最大長を指定しても指定しなくても，メモリ所要量やデータ転送量は同じです。LOB列の検索又は更新時に使用するメモリ所要量やデータ転送量は，列定義の最大長ではなく，検索又は更新時の実長と埋込み変数の定義長に依存します。なお，格納するバイナリデータサイズを制限したい場合は，LOB列の最大長で制限できます。

付録C.19　ウィルス対策ソフトに関する質問

質問

ウィルス対策ソフトをインストールしたところ，UAPがHiRDBに接続できなくなりました。ウィルス対策ソフトのファイアウォールが原因のようです。ファイアウォールの除外リストに，どのポート番号を除外指定すればよいでしょうか？

お答えします

「HiRDBで指定するポート番号の一覧」にHiRDBで使用するポート番号の一覧があります。この一覧の中で，次に示すポート番号を除外指定してください。

なお，ファイアウォールを設置した場所によって，除外指定するポート番号が異なります。

●HiRDBサーバ側にファイアウォールを設置した場合

システム共通定義及びユニット制御情報定義で指定する次に示すポート番号を除外指定してください。

HiRDBのポート番号

スケジューラプロセスのポート番号

これらのポート番号を指定するオペランドを指定していない場合は，オペランドを指定して，除外指定してください。

●クライアント側にファイアウォールを設置した場合

クライアント環境定義で指定する次に示すポート番号を除外指定してください。

クライアントの受信ポート番号

このポート番号を指定するクライアント環境定義を指定していない場合は，クライアント環境定義を指定して，除外指定してください。

付録C.20　HiRDB管理者の変更に関する質問

質問

インストール後，HiRDB管理者を変更することはできますか？

お答えします

ファイルセキュリティ強化機能を使用されている場合は，pdsetaclコマンドで変更できます。詳細は，マニュアル「HiRDB コマンドリファレンス」の「pdsetacl（ファイルセキュリティ強化機能の設定）」を参照してください。

ファイルセキュリティ強化機能を使用されていない場合は，変更できません。pdsetaclコマンドでファイルセキュリティ強化機能を使用するよう設定を変更するか，現在のHiRDB管理者でHiRDBをアンインストール後，新しいHiRDB管理者でHiRDBを再インストールしてください。

付録C.21　ジャンクションポイント，又はシンボリックリンクの使用に関する質問

質問

ジャンクションポイント，又はシンボリックリンクは使用できますか？

お答えします

HiRDBは，ジャンクションポイント，又はシンボリックリンクを含むパスにはインストールできません。

また，HiRDBが参照するフォルダのパスに，ジャンクションポイント，又はシンボリックリンクは使用できません。

ファイルに対するシンボリックリンクは，一部のHiRDBファイルシステム領域に対してだけ使用できます。

シンボリックリンクを使用できるHiRDBファイルシステム領域については，マニュアル「HiRDB コマンドリファレンス」の「pdfmkfs（HiRDBファイルシステム領域の初期設定）」を参照してください。

付録D　バッチファイルによる環境設定

付録D.1　バッチファイルによる環境設定の概要

ここでは，バッチファイルによる環境設定の方法について説明します。

この章を読むときの注意

バッチファイルによる環境設定は，HiRDB/シングルサーバのときだけ使えます。そのため，この章での説明は「HiRDB/シングルサーバをデフォルトのインストールディレクトリ（C:¥win32app¥hitachi¥hirdb_s）にインストールした」と仮定して説明しています。

HiRDB/パラレルサーバの環境設定については，%PDDIR%¥HiRDEF¥readme.txtを参照してください。

バッチファイルによる環境設定の手順を次の図に示します。

図D‒1　バッチファイルによる環境設定の手順

[picture]

注※1

「バッチファイルによるHiRDBの環境設定」を参照してください。

注※2

「HiRDBシステム定義の変更」を参照してください。

注※3

「サンプルファイル」を参照してください。

(1)　バッチファイル（SPsetup.bat）の内容

HiRDBでは，HiRDBの環境設定を自動的に実行するバッチファイルSPsetup.bat（C:¥win32app¥hitachi¥hirdb_s¥sample¥SPsetup.bat）を提供しています。SPsetup.batを実行すると，次に示す作業を自動的に実行します。

HiRDBシステム定義ファイルの作成

HiRDBファイルシステム領域の作成

システムファイルの作成

RDエリアの作成

このSPsetup.batは次の表に示すファイルを使用して環境を自動生成します。これらのファイルをサンプルコンフィグレーションといいます。次の表に示すファイルの内容をカスタマイズすれば，業務に合わせたシステムを構築できます。これらのファイルは，C:¥win32app¥hitachi¥hirdb_s¥confディレクトリ下にあります。

表D‒1　サンプルコンフィグレーションの内容

ファイル名 | 説　明

pdsys

pdutsys

sds01

HiRDBシステム定義ファイル

pdsys：システム共通定義

pdutsys：ユニット制御情報定義

sds01：シングルサーバ定義

fmkfile.bat | 次に示すHiRDBファイルシステム領域を作成するバッチファイル RDエリア用のHiRDBファイルシステム領域 作業表用ファイル用のHiRDBファイルシステム領域
fmkfs.bat | 次に示すHiRDBファイルシステム領域を作成するバッチファイル システムファイル用のHiRDBファイルシステム領域
sysfint.bat | システムファイルを作成するバッチファイル
initdb.bat | RDエリアを作成するバッチファイルです。データベース初期設定ユティリティ（pdinit）を実行するバッチファイル
mkinit | データベース初期設定ユティリティ（pdinit）の制御文を格納しているバッチファイル

(2)　構築されるシステムの構成

SPsetup.batを実行して作成されるシステムの構成例を次の図に示します。ここで示すのは，バッチファイルをカスタマイズしない場合に作成されるシステム構成です。

図D‒2　SPsetup.batを実行して作成されるシステムの構成例

[picture]

図D‒3　SPsetup.batを実行して作成されるHiRDBファイルシステム領域の構成例

[picture]

(3)　作成されるHiRDBファイルシステム領域及びファイル

SPsetup.batを実行して作成されるHiRDBファイルシステム領域とファイルを次の表に示します。ここで示すのは，バッチファイルをカスタマイズしない場合に作成されるHiRDBファイルシステム領域とファイルです。

表D‒2　SPsetup.batを実行して作成されるHiRDBファイルシステム領域名とサイズ

HiRDBファイルシステム領域の種類 | HiRDBファイルシステム領域のサイズ（単位：メガバイト） | HiRDBファイルシステム領域名

システムファイル用

小規模→74

中規模→148

大規模→296

rdsys011※1

rdsys012※1

rdsys013※1

rdsys014※1

rdsys015※1

rdsys016※1

RDエリア用（システム用RDエリア） | 小規模→20 中規模→40 大規模→80 | rdsys02※2
作業表用ファイル用 | − | rdsys03※2
RDエリア用（ユーザ用RDエリア） | 小規模→40 中規模→80 大規模→160 | rdsys04※2
RDエリア用（ユーザLOB用RDエリア） | 40 | rdsys05※2

注※1

SPsetup.bat実行時に表示されるセットアップ内容の確認画面の［HiRDBシステムファイル領域用ディレクトリ］で指定したディレクトリ下に作成されます。省略値は%PDDIR%¥areaになります。

注※2

SPsetup.bat実行時に表示されるセットアップ内容の確認画面の［HiRDB RDエリア領域用ディレクトリ］で指定したディレクトリ下に作成されます。省略値は%PDDIR%¥areaディレクトリになります。

表D‒3　SPsetup.batを実行して作成されるファイルの名称

ファイルの種類 | ファイル名 | 備考
HiRDBシステム定義ファイル | システム共通定義ファイル | %PDDIR%¥conf¥pdsys | ディレクトリはインストール時に作成されます。
ユニット制御情報定義ファイル | %PDDIR%¥conf¥pdutsys
シングルサーバ定義ファイル | %PDDIR%¥conf¥sds01

システムファイル

システムログファイル

rdsys011¥log1※1

rdsys012¥log2※1

rdsys013¥log3※1

rdsys014¥log4※1

rdsys015¥log5※1

rdsys016¥log6※1

6グループ

シンクポイントダンプファイル | rdsys014¥spd1※1 rdsys015¥spd2※1 rdsys016¥spd3※1 | 3グループ

ユニット用ステータスファイル

rdsys011¥utsts1a※1

rdsys012¥utsts1b※1

rdsys013¥utsts2a※1

rdsys014¥utsts2b※1

rdsys015¥utsts3a※1

rdsys016¥utsts3b※1

ユニットごとに

二重化×3個

サーバ用ステータスファイル

rdsys011¥sts1a※1

rdsys012¥sts1b※1

rdsys013¥sts2a※1

rdsys014¥sts2b※1

rdsys015¥sts3a※1

rdsys016¥sts3b※1

サーバごとに

二重化×3個

システム用RDエリア | マスタディレクトリ用RDエリア | rdsys02¥rdmast※2 | RDエリア名はRDMAST
データディレクトリ用RDエリア | rdsys02¥rddirt※2 | RDエリア名はRDDIRT
データディクショナリ用RDエリア | rdsys02¥rddict※2 | RDエリア名はRDDICT
データディクショナリLOB用RDエリア（ソース格納用） | rdsys02¥rtn_src※2 | RDエリア名は DIC_RTN_SRC
データディクショナリLOB用RDエリア（オブジェクト格納用） | rdsys02¥rtn_obj※2 | RDエリア名は DIC_RTN_OBJ
作業表用ファイル | rdsys03※2 | −
RPCトレースファイル | %PDDIR%¥spool¥pdrpctr | −
ユーザ用RDエリア（データ格納用） | rdsys04¥rddata10※2 | RDエリア名はRDDATA10
ユーザ用RDエリア（インデクス格納用） | rdsys04¥rdindx10※2 | RDエリア名はRDINDX10
ユーザLOB用RDエリア | rdsys05¥rlob1※2 | RDエリア名はRLOB1
rdsys05¥rlob2※2 | RDエリア名はRLOB2

注※1

SPsetup.bat実行時に表示されるセットアップ内容の確認画面の［HiRDBシステムファイル領域用ディレクトリ］で指定したディレクトリ下に作成されます。省略値は%PDDIR%¥areaディレクトリになります。

注※2

SPsetup.bat実行時に表示されるセットアップ内容の確認画面の［HiRDB RDエリア領域用ディレクトリ］で指定したディレクトリ下に作成されます。省略値は%PDDIR%¥areaディレクトリになります。

付録D.2　バッチファイルによるHiRDBの環境設定

ここでは，HiRDB/シングルサーバの環境を設定する例で説明します。

実行者　HiRDB管理者

（1）〜（8）の手順に従ってHiRDBの環境設定をします。

(1)　SPsetup.batを実行します

C:¥win32app¥hitachi¥hirdb_s¥sample¥SPsetup.batをエクスプローラで表示して，アイコンをダブルクリックしてください。

「既存の定義ファイルはありません」という［HiRDBシステム定義］メッセージボックスが表示されます（実行するのが2回目以降の場合は表示されません）。［HiRDBシステム定義］メッセージボックスの［OK］ボタンをクリックしてください。

(2)　HiRDBの規模を選択します

［HiRDBシステム定義］ダイアログボックスが表示されます。［ファイル］−［新規セットアップ］を選択してください。［HiRDB環境定義］の簡易セットアップ画面が表示されます。

ディスク容量と仮想メモリの値を確認してから，実行する規模を選択します。選択したら［OK］ボタンをクリックしてください。

HiRDBの規模を選択するときの注意

大規模，中規模，小規模を選択すると，それぞれpd_max_users（最大同時接続ユーザ数）に32，16，8が設定されたシステム共通定義が作成されます。購入したHiRDBの最大同時接続ユーザライセンスの範囲で選択してください。

(3)　セットアップの内容を確認します

〔説明〕

システムファイルのフィールド

［HiRDBシステムファイル領域用ディレクトリ］には，システムファイルを作成するディレクトリ名を指定します。

簡易セットアップでは，システムログファイルの二重化は指定できません。そのため，［ログファイルを2重化する］チェックボックスはグレー表示になります。

RDエリアのフィールド

［HiRDB RDエリア領域用ディレクトリ］には，RDエリアを作成するディレクトリ名を指定します。

(4)　セットアップを開始します

［セットアップ内容の確認］画面の内容を確認したら，［セットアップ開始］をクリックしてください。コマンドプロンプトに次に示す内容が表示されます。

"＃＃＃　hirdb.iniを更新しますか。"
"？？？　（開始＝Enter）or（終了＝N）"
"＝＝＝＝＞"

Enterキーを押してください。Enterキーを押すと，メモ帳でhostsファイルの内容が表示されます。hostsファイルに，このコンピュータのIPアドレスとホスト名があるかどうかを確認してください。ない場合は，このコンピュータのIPアドレスとホスト名を追加してください。

確認したら（又は追加したら），メモ帳を終了してください。終了すると，hirdb.iniファイルが作成されます。

IPアドレスが分からない場合

［コントロールパネル］の［ネットワーク］をダブルクリックして，［ネットワーク］の［プロトコル］タブを選択します。［TCP/IPプロトコル］のプロパティを開き，その中の［IPアドレス］で確認してください。

(5)　HiRDBを初期化します

HiRDBを初期化します。コマンドプロンプトに次に示す内容が表示されます。

"＃＃＃　HiRDBシステムの初期化を行います"
"＃＃＃　（インストールディレクトリ名）下に必要なファイルがある場合は，移動してください"
"？？？　（開始＝Enter）or（終了＝N）"
"＝＝＝＝＞"

Enterキーを押してください。コマンドプロンプトに次に示す内容が表示されます。

"＃＃＃　終了します。"
"続行するときは何かキーを押してください"

何かキーを押してください。コマンドプロンプトが順に3画面表示され，次に示す内容が表示されます。

"続行するときは何かキーを押してください"

何かキーを押してください。これで，次に示すファイルが作成されます。

HiRDBシステム定義ファイル

システムファイル

HiRDBシステム定義ファイルは，C:¥win32app¥hitachi¥hirdb_s¥conf下に次に示すファイル名で作成されます。

システム共通定義：pdsys

ユニット制御情報定義：pdutsys

シングルサーバ定義：sds01

(6)　HiRDBを開始します

［HiRDBシステム定義］メッセージボックスに［HiRDBを開始しますか？］というメッセージが表示されたら，［OK］ボタンをクリックしてください。クリックすると，コマンドプロンプトに次に示す内容が表示されて，HiRDBが開始されます。

"HiRDB/Single Serverサービスを開始します"
"HiRDB/Single Serverサービスは正常に開始されました。"

(7)　データベース初期設定ユティリティ（pdinit）が実行されます

データベース初期設定ユティリティ（pdinit）が実行されてRDエリアが作成されます。データベース初期設定ユティリティ（pdinit）が終了すると，コマンドプロンプトにKFPX24000-Iメッセージ（リターンコードが0）が表示され，さらに次に示す内容が表示されます。

"続行するときは何かキーを押してください"

何かキーを押してください。ここまでの操作が終了すると，［HiRDBシステム定義］メッセージボックスに「セットアップ終了。アプリケーションを終了します。」というメッセージが表示され，HiRDBのシステム定義が終了します。

注意事項

HiRDBのメッセージを確認して，問題がなければEnterキーを押してください。問題がある場合は強制停止の運用コマンド（pdstop -fコマンド）でHiRDBを強制停止してください。その後で問題を解決して，再度実行してください。

(8)　HiRDBの稼働状況を確認します

実際にHiRDBが稼働しているかどうかをpdlsコマンドで確認します。HiRDBの運用コマンドは，コマンドプロンプトから入力します。

C:¥>pdls

HOSTNAME(112852)                 UNITID SVID     STATUS    STARTTIME
k95x620                          unt1   ******** ACTIVE    111130
k95x620                          unt1   sds01    ACTIVE    111130

〔説明〕

STATUSがACTIVEになっていれば，HiRDBが稼働中です。

これでHiRDBサーバのシステム構築が終わりました。必要に応じてRDエリアを作成して，表を定義してください。

付録D.3　HiRDBシステム定義の変更

実行者　HiRDB管理者

「バッチファイルによるHiRDBの環境設定」で説明した作業を終えると，HiRDBシステム定義が作成されています。必要に応じて，HiRDBシステム定義を変更してください。HiRDBシステム定義を変更する場合は，HiRDBを正常終了させてください。その後，HiRDBシステム定義を変更してください。

HiRDBシステム定義変更（作成時）の注意を次に示します。

注意事項

HiRDBシステム定義ファイルのパーミッションは，ファイルの所有者（HiRDB管理者）にだけ，読み込み権限及び書き込み権限を持たせるように設定，維持するようにしてください。

システム共通定義のpdunitオペランドを指定する場合，HiRDB運用ディレクトリには環境変数PDDIRと同じ指定をしてください。大文字及び小文字も同じ指定にしてください。

システム共通定義のpdstartオペランドとpdunitオペランドの-xに指定するホスト名は同じにしてください。そのホスト名は，コマンドプロンプトでhostnameを実行すると得られます。

システム共通定義のTZオペランド（タイムゾーン）の指定（省略時はJST-9）と，サーバマシンのシステム環境変数TZが同じであることを確認してください。コマンドプロンプトでsetコマンドを入力すると，サーバマシンの環境変数が表示されます。システム環境変数TZが未設定又は内容がシステム共通定義のTZオペランドと異なる場合は，HiRDBの動作が保障できません。システム環境変数は［コントロールパネル］の［システム］をダブルクリックして，［システムのプロパティ］の［環境］タブで切り替わる画面に設定します。

HiRDBシステム定義ファイルには，.txtなどの拡張子を付けないでください。

索引

数字

1073エラーに関する質問[1]

1073エラーになったとき〔インストール〕[1]

24時間連続稼働[1]

64ビットモードのHiRDBへの移行方法[1]

64ビットモードへの移行手順[1]

64ビットモードへの移行に失敗した場合[1]

A

Administrators権限[1]

AFTERトリガ[1]

ALTER TRIGGER[1]

ARRAYオプション〔CREATE TABLE〕[1]

B

BEFOREトリガ[1]

BINARY型[1]

BLOB型[1]

BLOB型データの検索又は更新時に必要なメモリ所要量〔HiRDB/シングルサーバ〕[1]

BLOB型データの検索又は更新時に必要なメモリ所要量〔バックエンドサーバ又はディクショナリサーバ〕[1]

BLOB型データの検索又は更新時に必要なメモリ所要量〔フロントエンドサーバ〕[1]

B-tree構造のインデクスの設計[1]

C

CLUSTER KEYオプション〔CREATE TABLE〕[1]

Cosminexus連携時に考慮が必要になる機能[1]

CosminexusをサポートしているJDBCドライバ[1]

CREATE INDEX[1]

create rdarea文[1]、[2]、[3]、[4]

CREATE SCHEMA[1]

CREATE TRIGGER[1]

CREATE TYPE[1]

D

DECIMAL型の符号正規化機能[1]

DROP TRIGGER[1]

DTP[1]

E

EBCDIK[1]

ESIS-B形式[1]、[2]

EUC中国語漢字コード[1]

EXCEPT VALUESオプション〔CREATE INDEX〕[1]

F

FESホストダイレクト接続機能[1]

FIX属性の指定[1]

FIXハッシュ分割[1]

FIX表の性能に関する質問[1]

FOREIGN KEY[1]

FQDNを指定したHiRDBサーバへの接続方法[1]

H

HiRDB/Developer's Kitに関する質問[1]

HiRDB/シングルサーバのアンインストール[1]

HiRDB/シングルサーバのメモリ所要量の見積もり[1]

HiRDB/パラレルサーバのアンインストール[1]

HiRDB/パラレルサーバのメモリ所要量の見積もり[1]

HiRDB Advanced High Availability[1]

HiRDB Dataextractorとの連携[1]

HiRDB Datareplicatorとの連携[1]

HiRDB Text Search Plug-in[1]

HiRDB XAライブラリ[1]

HiRDB XAライブラリが提供する機能[1]

HiRDB XML Extension[1]

HiRDB運用ディレクトリ下のファイルの削除[1]

HiRDB運用ディレクトリ下のファイルのバックアップの取得〔バージョンアップ〕[1]

HiRDBが作成するディレクトリ及びファイル[1]

HiRDBが使用するポート数[1]

HiRDB管理者が作成するディレクトリ及びファイル[1]

HiRDB管理者の登録〔インストール〕[1]

HiRDB管理者の登録〔マルチHiRDB〕[1]

HiRDB管理者の変更に関する質問[1]

HiRDBグループを設定する[1]

HiRDBサーバとHiRDBクライアントの接続方法[1]

HiRDBシステム定義（UAP環境定義を除く）の変更方法[1]

HiRDBシステム定義の作成[1]

HiRDBシステム定義の作成〔HiRDB/シングルサーバ〕[1]

HiRDBシステム定義の作成〔HiRDB/パラレルサーバ〕[1]

HiRDBシステム定義の設定〔マルチHiRDB〕[1]

HiRDBシステム定義の変更[1]

HiRDBシステム定義ファイルの構成例〔HiRDB/シングルサーバ〕[1]

HiRDBシステム定義ファイルの構成例〔HiRDB/パラレルサーバ〕[1]

HiRDBのインストール手順[1]

HiRDBの開始が遅い場合[1]

HiRDBの環境設定の概要[1]

HiRDBのサービスの停止[1]

HiRDBの状態確認〔バージョンアップ〕[1]

HiRDBの初期開始[1]

HiRDBのディレクトリ及びファイル構成[1]

HiRDBのバージョンアップ[1]

HiRDBのメモリ所要量[1]

HiRDBファイルシステム領域サイズの見積もり〔作業表用ファイル〕[1]

HiRDBファイルシステム領域のアクセス権の設定[1]

HiRDBファイルシステム領域の最大長[1]、[2]、[3]

HiRDBファイルシステム領域の作成[1]

HiRDBファイルシステム領域の作成〔raw I/O機能〕[1]

HiRDBファイルシステム領域の作成〔RDエリア用〕[1]

HiRDBファイルシステム領域の作成〔作業表用ファイル用〕[1]

HiRDBファイルシステム領域の作成〔システムファイル用〕[1]

HiRDBファイルシステム領域の作成〔ユティリティ用〕[1]

HiRDBファイルシステム領域の作成〔リスト用RDエリア用〕[1]

HiRDBファイルシステム領域の種類[1]

HiRDBファイルシステム領域の設計〔HiRDB/シングルサーバ〕[1]

HiRDBファイルシステム領域の設計〔HiRDB/パラレルサーバ〕[1]

HiRDBファイルシステム領域の設計〔RDエリア用〕[1]、[2]

HiRDBファイルシステム領域の設計〔作業表用ファイル用〕[1]、[2]

HiRDBファイルシステム領域の設計〔システムファイル用〕[1]、[2]

HiRDBファイルシステム領域の設計〔ユティリティ用〕[1]、[2]

HiRDBファイルシステム領域の設計〔リスト用RDエリア用〕[1]、[2]

HiRDBファイルシステム領域を作成する準備[1]

HiRDBファイル名に関する最大値と最小値[1]

HiRDB予約ポート機能[1]

HiRDBをインストールするときの注意〔マルチHiRDB〕[1]

I

INSERT ONLYオプション〔CREATE TABLE〕[1]

IPアドレス[1]

IVS対応UTF-8[1]

J

Java EEアプリケーションサーバ[1]

Java仮想マシンが使用するメモリ所要量〔HiRDB/シングルサーバ〕[1]

Java仮想マシンが使用するメモリ所要量〔HiRDB/パラレルサーバ〕[1]

JBossをサポートしているJDBCドライバ[1]

K

KFPS01861-Eメッセージ[1]

KFPS05078-Iメッセージ[1]

L

LOB用グローバルバッファの割り当て[1]

LOB用グローバルバッファを割り当てる場合[1]

LOB列[1]

LOB列を定義した表の作成[1]

LRU管理方式[1]

N

NATが設置されている場合の設定[1]

NO SPLITオプション[1]

O

OLTPとの連携[1]

OLTPと連携したHiRDBシステムの構成例[1]

OLTPと連携できる製品[1]

OpenTP1[1]

OpenTP1とのXAインタフェースに関する質問[1]

OS環境ファイルの設定〔インストール〕[1]

OTS[1]

P

PATH[1]

PCTFREEオプション〔CREATE TABLE〕[1]

PCTFREEオプション〔CREATE TABLE又はCREATE INDEX〕[1]

pd_assurance_table_noオペランド[1]

pd_buf_awt〔HiRDB/シングルサーバ〕[1]

pd_buf_awt〔HiRDB/パラレルサーバ〕[1]

pd_buf_dfw〔HiRDB/シングルサーバ〕[1]

pd_buf_dfw〔HiRDB/パラレルサーバ〕[1]

pd_check_pendingオペランド[1]、[2]

pd_dbbuff_lru_optionオペランド[1]

pd_dbbuff_rate_updpageオペランド[1]

pd_dbsync_pointオペランド[1]、[2]

pd_dfw_awt_processオペランド[1]

pd_ios_ard〔HiRDB/シングルサーバ〕[1]

pd_ios_ard〔HiRDB/パラレルサーバ〕[1]

pd_log_dualオペランド[1]、[2]

pd_log_rerun_reserved_file_openオペランド[1]、[2]

pd_log_rpl_no_standby_file_oprオペランド[1]

pd_log_singleoperationオペランド[1]、[2]

pd_max_temporary_object_noオペランド[1]

pd_max_tmp_table_rdarea_noオペランド[1]

pd_pageaccess_modeオペランド[1]

pd_rcv_rd〔HiRDB/シングルサーバ〕[1]

pd_rcv_rd〔HiRDB/パラレルサーバ〕[1]

pd_rdarea_warning_point_msgoutオペランド[1]

pd_registered_portオペランド[1]、[2]

pd_rpl_hdepathオペランド[1]

pd_rpl_init_startオペランド[1]

pd_shared_rdarea_useオペランド[1]

pd_spd_assurance_countオペランド[1]、[2]

pd_spd_dual[1]、[2]

pd_spd_reduced_modeオペランド[1]、[2]

pd_spd_reserved_file_auto_openオペランド[1]、[2]

pd_spool_cleanup_interval[1]

pd_spool_cleanup_interval_level[1]

pd_spool_cleanup_levelオペランド[1]

pd_spool_cleanupオペランド[1]

pd_sts_singleoperationオペランド[1]、[2]

pd_syssts_singleoperationオペランド[1]、[2]

pd_tmp_table_initialize_timingオペランド[1]

pdadmvrコマンド[1]

pdaudd〔HiRDB/シングルサーバ〕[1]

pdaudd〔HiRDB/パラレルサーバ〕[1]

pdaudld〔HiRDB/シングルサーバ〕[1]

pdaudld〔HiRDB/パラレルサーバ〕[1]

pdbes〔HiRDB/パラレルサーバ〕[1]

pdbufferオペランド[1]

pdbufmodコマンド[1]

pdchgconfコマンド[1]

pdconfchkコマンド[1]

PDCONFPATH[1]

pdcopyb〔HiRDB/シングルサーバ〕[1]

pdcopyb〔HiRDB/パラレルサーバ〕[1]

pdcopyr〔HiRDB/シングルサーバ〕[1]

pdcopyr〔HiRDB/パラレルサーバ〕[1]

pdcspoolコマンド[1]

pddbst1〔HiRDB/シングルサーバ〕[1]

pddbst1〔HiRDB/パラレルサーバ〕[1]

pddefの制御文[1]

pddic〔HiRDB/パラレルサーバ〕[1]

PDDIR[1]

pdexpm〔HiRDB/シングルサーバ〕[1]

pdexpm〔HiRDB/パラレルサーバ〕[1]

pdfes〔HiRDB/パラレルサーバ〕[1]

pdfmkfsコマンド[1]、[2]、[3]

pdgcstm〔HiRDB/シングルサーバ〕[1]

pdgcstm〔HiRDB/パラレルサーバ〕[1]

pdinit[1]

pdinitb〔HiRDB/パラレルサーバ〕[1]

pdinitd〔HiRDB/シングルサーバ〕[1]

pdinitd〔HiRDB/パラレルサーバ〕[1]

pdlckmnd〔HiRDB/シングルサーバ〕[1]

pdlckmnd〔HiRDB/パラレルサーバ〕[1]

pdload[1]

pdloadm〔HiRDB/シングルサーバ〕[1]

pdloadm〔HiRDB/パラレルサーバ〕[1]

pdlogd〔HiRDB/シングルサーバ〕[1]

pdlogd〔HiRDB/パラレルサーバ〕[1]

pdloginitコマンド[1]、[2]

pdlogswd〔HiRDB/シングルサーバ〕[1]

pdlogswd〔HiRDB/パラレルサーバ〕[1]

pdlsコマンド[1]

pdls -d ustコマンド〔HiRDBのバージョンアップ時〕[1]

pdmbcd〔HiRDB/シングルサーバ〕[1]

pdmbcd〔HiRDB/パラレルサーバ〕[1]

pdmlgd〔HiRDB/シングルサーバ〕[1]

pdmlgd〔HiRDB/パラレルサーバ〕[1]

pdmod[1]

pdndmd〔HiRDB/パラレルサーバ〕[1]

pdntenvコマンド[1]、[2]、[3]

pdparaload[1]

pdpgbfon[1]

pdplgexm〔HiRDB/シングルサーバ〕[1]

pdplgexm〔HiRDB/パラレルサーバ〕[1]

pdplgrgstコマンド[1]

pdpluginオペランド[1]

pdprcd〔HiRDB/シングルサーバ〕[1]

pdprcd〔HiRDB/パラレルサーバ〕[1]

pdprfd〔HiRDB/シングルサーバ〕[1]

pdprfd〔HiRDB/パラレルサーバ〕[1]

pdprgcopyコマンド[1]

pdprgrenewコマンド[1]

pdrbalm〔HiRDB/パラレルサーバ〕[1]

pdrdma〔HiRDB/パラレルサーバ〕[1]

pdrdmd〔HiRDB/シングルサーバ〕[1]

pdrdmd〔HiRDB/パラレルサーバ〕[1]

pdrorgm〔HiRDB/シングルサーバ〕[1]

pdrorgm〔HiRDB/パラレルサーバ〕[1]

pdrplstartコマンド[1]

pdrplstopコマンド[1]

pdrshsrv〔HiRDB/シングルサーバ〕[1]

pdrshsrv〔HiRDB/パラレルサーバ〕[1]

pdrstrb〔HiRDB/シングルサーバ〕[1]

pdrstrb〔HiRDB/パラレルサーバ〕[1]

pdrstrl〔HiRDB/シングルサーバ〕[1]

pdrstrl〔HiRDB/パラレルサーバ〕[1]

pdrstrm〔HiRDB/シングルサーバ〕[1]

pdrstrm〔HiRDB/パラレルサーバ〕[1]

pdrstrr〔HiRDB/シングルサーバ〕[1]

pdrstrr〔HiRDB/パラレルサーバ〕[1]

pdrstrw〔HiRDB/シングルサーバ〕[1]

pdrstrw〔HiRDB/パラレルサーバ〕[1]

pdrsvre〔HiRDB/シングルサーバ〕[1]

pdrsvre〔HiRDB/パラレルサーバ〕[1]

pdscdd〔HiRDB/シングルサーバ〕[1]

pdscdd〔HiRDB/パラレルサーバ〕[1]

pdsds〔HiRDB/シングルサーバ〕[1]

pdservice〔HiRDB/シングルサーバ〕[1]

pdservice〔HiRDB/パラレルサーバ〕[1]

pdstart2a〔HiRDB/パラレルサーバ〕[1]

pdstart2d〔HiRDB/シングルサーバ〕[1]

pdstart2d〔HiRDB/パラレルサーバ〕[1]

pdstartオペランドに指定するホスト名[1]

pdstartコマンドがエラーリターンする場合[1]

pdstartコマンドでHiRDBが開始しない場合[1]

pdstartコマンドで特定のユニットが開始しない場合[1]

pdstsd〔HiRDB/シングルサーバ〕[1]

pdstsd〔HiRDB/パラレルサーバ〕[1]

pdstsinitコマンド[1]

pdsvstartd〔HiRDB/パラレルサーバ〕[1]

pdtrnd〔HiRDB/シングルサーバ〕[1]

pdtrnd〔HiRDB/パラレルサーバ〕[1]

pdtrnrvd〔HiRDB/シングルサーバ〕[1]

pdtrnrvd〔HiRDB/パラレルサーバ〕[1]

PDUXPLDIR[1]

PDUXPLMSGMNI[1]、[2]

PDUXPLMSGTQL[1]、[2]

PDUXPLSEMMAX[1]、[2]

PDUXPLSHMMAX[1]、[2]

PRIMARY KEYオプション〔CREATE TABLE〕[1]

PRIVATE[1]

PROTECTED[1]

Psp4017[1]

PUBLIC[1]

Q

Q＆A[1]

R

raw I/O機能[1]

raw I/O機能を使用したHiRDBファイルシステム領域の作成[1]

raw I/O機能を使用したHiRDBファイルシステム領域の作成〔例題〕[1]

RDエリアに関する最大値・最小値[1]

RDエリアの自動増分機能使用時に出力されるシステムログ量[1]

RDエリアの設計[1]

RDエリアの配置〔HiRDB/シングルサーバ〕[1]

RDエリアの配置〔HiRDB/パラレルサーバ〕[1]

RDエリアの容量の見積もり[1]

RDエリア名〔標準セットアップで設定される名称〕[1]

RDエリア用のHiRDBファイルシステム領域の作成[1]

RDエリア用のHiRDBファイルシステム領域の設計〔HiRDB/シングルサーバ〕[1]

RDエリア用のHiRDBファイルシステム領域の設計〔HiRDB/パラレルサーバ〕[1]

RDエリアを設計するときの検討項目[1]

reason code=TIMEOUT[1]

RECOVERYオペランド〔CREATE TABLE〕[1]、[2]

RM[1]

RM関連オブジェクト名[1]

RMスイッチ名[1]

RM名[1]

S

sampleDB1.bat[1]

sampleDB2.bat[1]

sampleDB3.bat[1]

sampleDB4.bat[1]

SEGMENT REUSEオプション[1]

SEGMENT REUSEオプション〔ALTER TABLE〕[1]

server nameオペランド[1]

SPsetup.bat[1]

SQL関連の注意事項〔X/Open XAインタフェース環境〕[1]

SQL実行時に必要なメモリ所要量〔HiRDB/シングルサーバ〕[1]

SQL実行時に必要なメモリ所要量〔HiRDB/パラレルサーバ〕[1]

SQLセッション間共有属性[1]

SQLセッション固有一時表[1]

SQL操作に応じて出力されるシステムログ量[1]

SQL文が使用する作業表用ファイルの容量[1]

SQL前処理時に必要なメモリ所要量〔HiRDB/シングルサーバ〕[1]

SQL前処理時に必要なメモリ所要量〔HiRDB/パラレルサーバ〕[1]

SQL予約語定義の作成〔HiRDB/シングルサーバ〕[1]

SQL予約語定義の作成〔HiRDB/パラレルサーバ〕[1]

SUPPRESSオプション〔CREATE TABLE〕[1]

T

TCPポートに関する設定値の見積もり[1]

TIMEOUT[1]

TM[1]

TPBroker for C++[1]

trnstringオペランド[1]

TUXEDO[1]

TZの確認〔インストール〕[1]

U

UAP環境定義の作成〔HiRDB/シングルサーバ〕[1]

UAP環境定義の作成〔HiRDB/パラレルサーバ〕[1]

UAP環境定義の追加又は変更方法[1]

Unicode[1]、[2]

UOC[1]

UTF16[1]

UTF-8[1]

W

Windowsダンプ出力[1]

Windowsファイアウォールの設定を有効にしている場合[1]

Windowsファイアウォールの例外リストからの削除[1]

Windowsファイアウォールの例外リストへの登録[1]

WITHOUT ROLLBACKオプションの指定[1]

X

X/Open XAインタフェース[1]

xa_switch_t 構造体名[1]

XAインタフェース〔マルチスレッド対応〕[1]

XML型[1]

XML型全文検索用インデクス（n-gram）[1]

あ

空きありセグメント[1]

空きセグメント[1]

空きページ再利用モード[1]

空き容量監視機能〔HiRDB/パラレルサーバ〕[1]

空き領域の確認〔バージョンアップ〕[1]

空き領域の再利用機能[1]

空き領域の再利用機能のページサーチ空回り回数[1]

アクセスパス表示ユティリティ（pdvwopt）実行時のファイルの容量[1]

アクセスパス表示ユティリティ（pdvwopt）実行時のメモリ所要量[1]

新しいユーザを追加する場合[1]

圧縮表[1]

圧縮分割サイズ[1]

圧縮列[1]

アンインストール[1]

アンインストール〔プラグイン〕[1]

暗号化通信環境の構築[1]

暗号化列を含む表を使用している場合[1]

い

一意性制約[1]

一時インデクス[1]

一時表[1]

一時表用RDエリア[1]

位置情報作業表の最大数の求め方[1]

位置情報作業表の容量の求め方[1]

一相最適化[1]

一相最適化に関する注意事項[1]

インストーラによる入れ替え[1]

インストール[1]

インストール後の作業[1]

インストール後の注意[1]

インストールディレクトリに関する質問[1]

インストール手順[1]

インストール〔付加PP〕[1]

インストール〔プラグイン〕[1]

インストール前に必要な作業[1]

インストール前の注意[1]

インストール〔マルチHiRDB〕[1]

インデクス[1]

インデクス一括作成中に発生したエラーの対処[1]

インデクス格納RDエリアの容量見積もり〔注意事項〕[1]

インデクス定義時に出力されるシステムログ量[1]

インデクスの格納ページ数[1]、[2]

インデクスの格納ページ数の計算例[1]

インデクスのキー長一覧[1]

インデクスのキー長の上限[1]

インデクスの作成[1]

インデクスの設計[1]

インデクスの定義[1]

インデクスの分割指針[1]

インデクスの横分割[1]

インデクスページスプリット[1]

インデクスページスプリット時のインデクスログ量の見積もり[1]

インデクス用グローバルバッファの割り当て[1]

インデクス用グローバルバッファを割り当てる場合[1]

インデクス用ローカルバッファ[1]

インデクス用ローカルバッファの割り当て[1]

インデクスログ量の見積もり[1]

インデクスを設計するときの検討項目[1]

インデクスを定義できないデータ型[1]

隠蔽レベル[1]、[2]

インメモリデータ処理で必要なメモリ所要量〔HiRDB/パラレルサーバ〕[1]、[2]

インメモリデータバッファが使用する共用メモリセグメント数[1]、[2]

う

ウィザードセットアップ[1]

ウィルス対策ソフト[1]

お

オープン文字列[1]

オンライン状態であるかどうかの確認〔バージョンアップ〕[1]

か

改竄防止機能[1]

改竄防止表[1]

解析情報表及び運用履歴表を格納するデータディクショナリ用RDエリアの容量の見積もり[1]

外部キー[1]

回復不要FES[1]

回復不要FESユニット[1]

各サーバが使用する共用メモリの計算式〔HiRDB/パラレルサーバ〕[1]

拡張SQLエラー情報出力機能使用時に必要なメモリ所要量の求め方〔HiRDB/シングルサーバ〕[1]

拡張SQLエラー情報出力機能使用時に必要なメモリ所要量の求め方〔HiRDB/パラレルサーバ〕[1]

拡張システム定義スカラ関数の定義時に出力されるシステムログ量[1]

格納条件指定[1]

カスタムセットアップ[1]

カスタムセットアップ（詳細定義）[1]

仮想メモリの確認〔インストール〕[1]

仮想メモリの見積もり方法に関する質問[1]

片系運転〔HiRDB/シングルサーバ〕[1]、[2]

片系運転〔HiRDB/パラレルサーバ〕[1]、[2]

簡易セットアップツールによる環境設定[1]

環境設定〔簡易セットアップツール〕[1]

環境変数〔インストール〕[1]

環境変数設定用バッチファイルの使用方法〔マルチHiRDB〕[1]

環境変数の設定〔マルチHiRDB〕[1]

監査証跡ファイルの容量の見積もり[1]

き

キーレンジ分割[1]

キーレンジ分割（格納条件指定）の例[1]

キーレンジ分割（境界値指定）の例[1]

既定の照合順[1]

既定文字集合[1]

基本行ログ量の見積もり[1]

旧値相関名[1]

旧バージョンと新バージョンを入れ替える場合[1]

旧バージョンに戻す場合[1]

境界値指定[1]

行削除禁止期間[1]

共用RDエリア[1]

共用表[1]

共用メモリ使用数[1]、[2]

共用メモリ〔メモリ所要量〕[1]、[2]

く

空白変換機能[1]

クライアントからの接続用ポート番号の設定〔マルチHiRDB〕[1]

クライアント環境定義〔トランザクションマネジャに登録〕[1]

クライアント環境定義の設定〔データベースの作成〕[1]

クライアント環境定義の設定〔マルチHiRDB〕[1]

クライアントとの接続[1]

クラスタキーの指定[1]

繰返し列[1]

繰返し列のデータ長の求め方[1]

繰返し列を含む表[1]

グループ分け高速化機能実行時に必要なメモリ所要量〔HiRDB/シングルサーバ〕[1]

グループ分け高速化機能実行時に必要なメモリ所要量〔HiRDB/パラレルサーバ〕[1]

クローズ文字列[1]

グローバルバッファが使用する共用メモリ〔HiRDB/シングルサーバ〕[1]

グローバルバッファが使用する共用メモリ〔HiRDB/パラレルサーバ〕[1]

グローバルバッファ常駐化ユティリティ[1]

グローバルバッファのLRU管理方式[1]

グローバルバッファの先読み入力[1]

グローバルバッファの設計[1]

グローバルバッファの定義例[1]

グローバルバッファの動的変更[1]

グローバルバッファのバッファ面数の設定[1]

グローバルバッファの分割[1]

グローバルバッファの割り当て[1]

グローバルバッファの割り当て方法[1]

け

系切り替え機能[1]

系切り替え機能との関連〔マルチHiRDB〕[1]

継承[1]、[2]

検査制約[1]

検査制約表[1]

検査制約用解析ツリー長[1]

検査保留状態[1]、[2]

こ

更新可能バックエンドサーバ[1]

更新可能列[1]

更新バッファ[1]

更新前ログ取得モード[1]、[2]

更新ログ取得方式の種類[1]

高速接続機能[1]

候補キー[1]

コネクションプーリング[1]

コマンドによる環境設定[1]

コマンドによる環境設定の概要[1]

コマンドを別名で実行するためのバッチファイルの作成[1]

コミット時反映処理[1]

コンストラクタ関数[1]、[2]

さ

サーバが使用する共用メモリの計算式〔HiRDB/シングルサーバ〕[1]

サーバが使用する共用メモリの計算式〔HiRDB/パラレルサーバ〕[1]

サーバ間横分割[1]

サーバ共通定義の作成[1]

サーバ数が多いシステムを構築する場合の考慮点[1]

サーバ内横分割[1]

サーバマシン環境〔インストール〕[1]

サービスポート番号のOSへの登録〔マルチHiRDB〕[1]

最小値[1]

最初に作成するファイル[1]

最大使用量〔作業表用HiRDBファイルシステム領域〕[1]

最大増分回数の見積もり〔作業表用ファイル〕[1]

最大値[1]

最大ファイル数の見積もり〔作業表用ファイル〕[1]

最大容量に関する質問〔表〕[1]

最適化情報収集ユティリティ（pdgetcst）実行時のファイルの容量[1]

最適化情報収集ユティリティ（pdgetcst）実行時のメモリ所要量[1]

作業表用HiRDBファイルシステム領域の最大使用量に関する質問[1]

作業表用ファイル[1]

作業表用ファイルの容量の見積もり[1]

作業表用ファイル用のHiRDBファイルシステム領域の作成[1]

作業表用ファイル用のHiRDBファイルシステム領域の設計〔HiRDB/シングルサーバ〕[1]

作業表用ファイル用のHiRDBファイルシステム領域の設計〔HiRDB/パラレルサーバ〕[1]

作業表用ファイルを必要とするSQL[1]

作業用コンソールの使用方法〔マルチHiRDB〕[1]

サブタイプ[1]

サプレスオプションの指定[1]

参照制約[1]

参照専用バックエンドサーバ[1]

参照バッファ[1]

参照表[1]

サンプルUOCのファイル名[1]

サンプルオーディットのファイル名[1]

サンプルコンフィグレーション[1]

サンプルコンフィグレーションのファイル名[1]

サンプルデータベースのカスタマイズ[1]

サンプルデータベースの作成手順[1]

サンプルデータベースのファイル名[1]

サンプルファイル[1]

サンプルファイルの使用方法[1]

し

システム環境変数TZの確認〔インストール〕[1]

システムキャッシュの確認〔インストール〕[1]

システム共通定義の作成〔HiRDB/シングルサーバ〕[1]

システム共通定義の作成〔HiRDB/パラレルサーバ〕[1]

システム構成〔HiRDB/シングルサーバ〕[1]

システム構成〔HiRDB/パラレルサーバ〕[1]

システム構成に関する最小値[1]

システム構成に関する最大値[1]

システム構成変更コマンド[1]

システム構築手順[1]

システム設計〔HiRDB/シングルサーバ〕[1]

システム設計〔HiRDB/パラレルサーバ〕[1]

システム設計〔マルチHiRDB〕[1]

システムの構成の確認〔マルチHiRDB〕[1]

システムファイルの作成[1]

システムファイルの作成例〔HiRDB/シングルサーバ〕[1]

システムファイルの作成例〔HiRDB/パラレルサーバ〕[1]

システムファイルの設計〔HiRDB/シングルサーバ〕[1]

システムファイルの設計〔HiRDB/パラレルサーバ〕[1]

システムファイルの容量の見積もり[1]

システムファイル用のHiRDBファイルシステム領域の作成[1]

システムファイル用のHiRDBファイルシステム領域の設計〔HiRDB/シングルサーバ〕[1]

システムファイル用のHiRDBファイルシステム領域の設計〔HiRDB/パラレルサーバ〕[1]

システムマネジャの設置[1]

システム用RDエリアの作成[1]

システム用RDエリアの配置〔HiRDB/シングルサーバ〕[1]

システム用RDエリアの配置〔HiRDB/パラレルサーバ〕[1]

システム用RDエリアのバックアップの取得〔バージョンアップ〕[1]

システムログファイルの空き容量監視機能〔HiRDB/シングルサーバ〕[1]

システムログファイルの空き容量監視機能〔HiRDB/パラレルサーバ〕[1]

システムログファイルの片系運転〔HiRDB/シングルサーバ〕[1]

システムログファイルの片系運転〔HiRDB/パラレルサーバ〕[1]

システムログファイルの作成[1]

システムログファイルの自動オープン〔HiRDB/シングルサーバ〕[1]

システムログファイルの自動オープン〔HiRDB/パラレルサーバ〕[1]

システムログファイルの自動拡張機能〔HiRDB/シングルサーバ〕[1]

システムログファイルの自動拡張機能〔HiRDB/パラレルサーバ〕[1]

システムログファイルの設計〔HiRDB/シングルサーバ〕[1]

システムログファイルの設計〔HiRDB/パラレルサーバ〕[1]

システムログファイルの総容量[1]

システムログファイルの総レコード数の確認〔バージョンアップ〕[1]

システムログファイルの二重化〔HiRDB/シングルサーバ〕[1]

システムログファイルの二重化〔HiRDB/パラレルサーバ〕[1]

システムログファイルの容量の見積もり[1]

システムログファイルの両系運転〔HiRDB/シングルサーバ〕[1]

システムログファイルの両系運転〔HiRDB/パラレルサーバ〕[1]

システムログファイルのレコード長〔HiRDB/シングルサーバ〕[1]

システムログファイルのレコード長〔HiRDB/パラレルサーバ〕[1]

システムログ量の求め方[1]

実体化〔一時表〕[1]

実表[1]

自動オープン〔HiRDB/シングルサーバ〕[1]、[2]

自動オープン〔HiRDB/パラレルサーバ〕[1]、[2]

自動採番機能を使用したデータロード[1]

シフトJIS漢字コード[1]

修正パッチ〔修正版HiRDBへの入れ替え〕[1]

修正版HiRDB[1]

修正版HiRDBへの入れ替え[1]

主キー[1]

縮退運転〔HiRDB/シングルサーバ〕[1]

縮退運転〔HiRDB/パラレルサーバ〕[1]

順序数生成子[1]

障害時の運用〔修正版HiRDBへの入れ替え〕[1]

詳細定義情報[1]

使用中空きセグメント[1]

使用中空きページ[1]

使用中空きページの解放[1]

使用中セグメント[1]

使用中ページ[1]

使用中満杯ページ[1]

除外キー値[1]

除外キー値を設定したインデクスの使用[1]

新規ページ追加モード[1]

新旧値別名[1]

シンクポイントダンプの運用に関する質問[1]

シンクポイントダンプファイルの作成[1]

シンクポイントダンプファイルの自動オープン〔HiRDB/シングルサーバ〕[1]

シンクポイントダンプファイルの自動オープン〔HiRDB/パラレルサーバ〕[1]

シンクポイントダンプファイルの縮退運転〔HiRDB/シングルサーバ〕[1]

シンクポイントダンプファイルの縮退運転〔HiRDB/パラレルサーバ〕[1]

シンクポイントダンプファイルの設計〔HiRDB/シングルサーバ〕[1]

シンクポイントダンプファイルの設計〔HiRDB/パラレルサーバ〕[1]

シンクポイントダンプファイルの二重化[1]、[2]

シンクポイントダンプファイルの片系運転[1]、[2]

シンクポイントダンプファイルの有効保証世代数〔HiRDB/シングルサーバ〕[1]

シンクポイントダンプファイルの有効保証世代数〔HiRDB/パラレルサーバ〕[1]

シンクポイントダンプファイルの容量の見積もり[1]

シンクポイントダンプファイルのレコード数の求め方[1]

シンクポイントダンプ有効化のスキップ回数監視機能〔HiRDB/シングルサーバ〕[1]

シンクポイントダンプ有効化のスキップ回数監視機能〔HiRDB/パラレルサーバ〕[1]

シングルサーバが使用する共用メモリ[1]

シングルサーバ定義の作成[1]

新値相関名[1]

す

スーパタイプ[1]

スキーマの定義〔データベースの作成〕[1]

ステータスファイルの運用に関する質問〔障害発生時〕[1]

ステータスファイルの運用に関する質問〔ステータスファイルの定義〕[1]

ステータスファイルの運用に関する質問〔ステータスファイルの二重化〕[1]

ステータスファイルの運用に関する質問〔ステータスファイルの配置〕[1]

ステータスファイルの片系運転〔HiRDB/シングルサーバ〕[1]

ステータスファイルの片系運転〔HiRDB/パラレルサーバ〕[1]

ステータスファイルの作成[1]

ステータスファイルの設計〔HiRDB/シングルサーバ〕[1]

ステータスファイルの設計〔HiRDB/パラレルサーバ〕[1]

ステータスファイルの容量の見積もり[1]

ステータスファイルの両系運転〔HiRDB/シングルサーバ〕[1]

ステータスファイルの両系運転〔HiRDB/パラレルサーバ〕[1]

ステータスファイルのレコード数の求め方[1]

ステートメントキャッシュ[1]

ステートメントプーリング[1]

スナップショット方式[1]

せ

正規化[1]

整合性チェックユティリティ（pdconstck）実行時のファイルの容量[1]

静的登録[1]

セグメント[1]

セグメントサイズの決定[1]

セグメント数[1]、[2]、[3]

セグメント内の空きページ比率[1]

セグメント内の空きページ比率の設定[1]

セグメントの確保と解放[1]

セットアップ識別子〔マルチHiRDB〕[1]

セマフォ識別子数の見積もり[1]、[2]

そ

相互系切り替え構成への移行〔マルチHiRDB〕[1]

挿入履歴保持列[1]

総ページ数[1]

総ページ数を求める計算式[1]

ソート用ワークファイル容量の計算で使用するバッファサイズ[1]

た

第1次元分割列[1]

第2次元分割列[1]

代替可能性[1]、[2]

多重定義[1]

単一バイト文字コード[1]

単一列分割[1]

単調増加ファイル[1]

ち

中国語漢字コード（GB18030）[1]

抽象データ型[1]

抽象データ型（SGMLTEXT型）を定義した表の作成方法[1]

抽象データ型（XML型）を定義した表の作成方法[1]

抽象データ型の定義[1]

抽象データ型のナル値[1]

抽象データ型の列のデータ長の求め方[1]

抽象データ型列構成基表[1]

抽象データ型を含む表[1]

重複キーインデクスに関する質問[1]

つ

通信負荷を軽減する運用[1]

て

定義情報の保存と読み込み〔簡易セットアップツール〕[1]

定義の更新〔簡易セットアップツール〕[1]

ディクショナリサーバが使用する共用メモリ[1]

ディクショナリサーバ定義の作成[1]

ディクショナリ搬出入ユティリティ（pdexp）実行時のファイルの容量[1]

ディクショナリ搬出入ユティリティ（pdexp）実行時のメモリ所要量[1]

ディスク容量の確認〔インストール〕[1]

データ圧縮機能[1]

データ操作と整合性〔検査制約〕[1]

データ操作と整合性〔参照制約〕[1]

データ長一覧[1]

データ長一覧〔可変長文字列型〕[1]

データ長一覧〔繰返し列〕[1]

データ長一覧〔抽象データ型〕[1]

データディクショナリLOB用RDエリアの作成[1]

データディクショナリLOB用RDエリアの総ページ数[1]、[2]

データディクショナリLOB用RDエリアの配置〔HiRDB/シングルサーバ〕[1]

データディクショナリLOB用RDエリアの配置〔HiRDB/パラレルサーバ〕[1]

データディクショナリLOB用RDエリアのページ長[1]、[2]

データディクショナリLOB用RDエリアの容量の見積もり[1]

データディクショナリ用RDエリアの容量の見積もり[1]

データディレクトリ用RDエリアの総ページ数[1]

データディレクトリ用RDエリアのページ長[1]

データディレクトリ用RDエリアの容量の見積もり[1]

データの格納状態の確認[1]、[2]

データの変換方式の設定〔データベースの作成〕[1]

データページ[1]

データベース回復ユティリティ（pdrstr）実行時のメモリ所要量[1]

データベース構成変更ユティリティ[1]

データベース構成変更ユティリティ（pdmod）実行時のメモリ所要量[1]

データベース再編成ユティリティ（pdrorg）実行時のファイルの容量[1]

データベース再編成ユティリティ（pdrorg）実行時のメモリ所要量[1]

データベース作成ユティリティ[1]

データベース作成ユティリティ（pdload）実行時のファイルの容量[1]

データベース作成ユティリティ（pdload）実行時のメモリ所要量[1]

データベース状態解析ユティリティ（pddbst）実行時のファイルの容量[1]

データベース状態解析ユティリティ（pddbst）実行時のメモリ所要量[1]

データベース初期設定ユティリティ[1]

データベース初期設定ユティリティ（pdinit）実行時のメモリ所要量[1]

データベース定義ユティリティ（pddef）がエラーになる場合[1]

データベース定義ユティリティ（pddef）実行時のメモリ所要量[1]

データベース定義ユティリティ（pddef）の実行に関する質問[1]

データベースに関する最小値[1]

データベースに関する最大値[1]

データベースの更新ログ取得方式[1]、[2]

データベースの作成[1]

データベース複写ユティリティ（pdcopy）実行時のファイルの容量[1]

データベース複写ユティリティ（pdcopy）実行時のメモリ所要量[1]

データ未完状態[1]

データ有効期間〔一時表〕[1]

データ用グローバルバッファの割り当て[1]

データ用グローバルバッファを割り当てる場合[1]

データ用ローカルバッファ[1]

データ用ローカルバッファの割り当て[1]

データロードをする場合[1]

適用機種の確認〔インストール〕[1]

デスクトップヒープ指定値の見積もり[1]

デファードライト処理[1]

デファードライト処理の並列WRITE機能[1]

デファードライトトリガ[1]

デファードライトトリガでの更新ページの出力比率[1]

デファードライトトリガの要求比率[1]

デフォルトコンストラクタ関数[1]、[2]

と

同期点行数[1]

同期点指定のデータロード[1]

同期点指定のデータロード〔ユティリティ異常終了時の対処方法〕[1]

統計解析ユティリティ（pdstedit）実行時のファイルの容量[1]

統計解析ユティリティ（pdstedit）実行時のメモリ所要量[1]

動的登録[1]

動的トランザクションの登録[1]

登録〔トランザクションマネジャ〕[1]

登録の変更〔トランザクションマネジャ〕[1]

特定SQLセッション占有属性[1]

トランザクション固有一時表[1]

トランザクションの移行[1]、[2]

トランザクションの完了種別[1]

トランザクションマネジャ[1]

トランザクションマネジャに登録する情報[1]

トランザクションマネジャへの登録[1]

トランザクションマネジャへの登録の変更[1]

トランザクションマネジャへの登録例[1]

トリガ[1]

トリガSQL文[1]

トリガ契機となるSQL[1]

トリガ動作条件の解析ツリー長[1]

トリガ動作の探索条件[1]

トリガの管理[1]

に

入力データファイルUOC[1]

ね

ネットワーク構成例と定義例〔FQDN〕[1]

ネットワーク構成例と定義例〔マルチコネクションアドレス機能〕[1]

ネットワークドライブの使用に関する質問[1]

の

ノースプリットオプションの指定[1]

は

バージョンアップ[1]

バージョンアップに失敗した場合[1]

バージョンアップに必要な空き領域[1]

バージョンアップ〔プラグイン〕[1]、[2]

バージョンアップ前にすること[1]

バージョンダウン[1]

バイナリデータ[1]

パスワードの変更〔データベースの作成〕[1]

バックエンドサーバが使用する共用メモリ[1]

バックエンドサーバ定義の作成[1]

ハッシュ関数[1]

ハッシュジョイン及び副問合せのハッシュ実行時に必要なメモリ所要量[1]、[2]

ハッシュ分割[1]

ハッシュ分割表のリバランス機能[1]、[2]

バッチファイルによるHiRDBの環境設定[1]

バッチファイルによる環境設定の概要[1]

バッファヒット率[1]

パラレルローディング機能[1]

ひ

非UNIQUE属性[1]

被参照表[1]

被参照表と参照表間のデッドロック[1]

非同期READ機能[1]

非同期XA呼び出し〔X/Open XAインタフェース環境〕[1]

非ナル値制約[1]

非分割キーインデクス[1]

ビュー表[1]

ビュー表の作成[1]

表及びインデクスを定義する場合[1]

標準セットアップ[1]

表定義時に出力されるシステムログ量[1]

表データ更新時に出力されるシステムログ量[1]

表の格納ページ数の計算方法[1]、[2]

表の格納ページ数の計算例[1]

表の最大容量[1]

表の正規化[1]

表の整合性確認手順〔検査制約〕[1]

表の整合性確認手順〔参照制約〕[1]

表の設計[1]

表の定義[1]

表の定義情報〔サンプルファイル〕[1]

表のマトリクス分割[1]

表の横分割[1]

表の横分割の形態[1]

表の横分割の効果[1]

表へのデータの格納[1]

表を設計するときの検討項目[1]

ふ

ファイアウォールが設置されている場合の設定[1]

ファイルシステムの確認〔インストール〕[1]

ファイルセキュリティ強化機能[1]

複数接続機能〔X/Open XAインタフェース環境〕[1]、[2]

複数列分割[1]

部分構造インデクス（B-tree）[1]

部分構造パス用解析ツリー長[1]

不要なRDエリアの削除[1]

プライマリキー[1]

プラグインインデクス[1]

プラグインインデクスの定義[1]

プラグインインデクスの横分割[1]

プラグインが提供する抽象データ型を定義した表の作成[1]

プラグインのアンインストール[1]

プラグインのインストール[1]

プラグインの環境設定[1]

プラグインの削除[1]

プラグインの所有者[1]

プラグインの登録[1]

プラグインのバージョンアップ[1]

プラグインをバージョンアップする場合[1]

プリフェッチ機能[1]、[2]

フレキシブルハッシュ分割[1]

フレキシブルハッシュ分割及びFIXハッシュ分割の例[1]

フロータブルサーバ[1]

フロータブルサーバの設置[1]

フロータブルマシン[1]

プロセス一覧[1]

プロセス間メモリ通信用共用メモリ〔HiRDB/シングルサーバ〕[1]

プロセス間メモリ通信用共用メモリ〔HiRDB/パラレルサーバ〕[1]

プロセス固有領域〔メモリ所要量〕[1]、[2]

ブロック転送又は配列FETCHで必要なメモリ所要量〔HiRDB/シングルサーバ〕[1]

ブロック転送又は配列FETCHで必要なメモリ所要量〔フロントエンドサーバ〕[1]

フロントエンドサーバが使用する共用メモリ[1]

フロントエンドサーバ定義の作成[1]

フロントエンドサーバの複数化[1]

分割キー[1]

分割キーインデクス[1]

分割キーの選択方法[1]

分割入力データファイル[1]

分割入力データファイルの作成[1]

分岐行ログ量の見積もり[1]

分散トランザクション処理[1]

へ

ページ[1]

ページ固定[1]、[2]

ページサーチモードの切り替え回数[1]

ページ長[1]

ページ長の決定[1]

ページ内の未使用領域の比率[1]

ページ内の未使用領域の比率の設定[1]

ページ内の未使用領域の比率の求め方[1]

ページの解放[1]

ページの確保[1]

別名〔コマンド名〕[1]

ほ

ポート数[1]

ポート数不足を回避する方法[1]

ポート番号の一覧[1]

ポート番号の指定方法[1]

ポート番号を指定するオペランドの一覧[1]

ほかの製品との連携[1]

ホスト名[1]

ホスト名に関する質問[1]

ホスト名の登録[1]

ま

マスタディレクトリ用RDエリアの総ページ数[1]

マスタディレクトリ用RDエリアのページ長[1]

マスタディレクトリ用RDエリアの容量の見積もり[1]

マトリクス分割[1]

マトリクス分割表[1]

マルチHiRDBのインストール[1]

マルチHiRDBの環境設定[1]

マルチHiRDBのシステム設計[1]

マルチコネクションアドレス機能〔HiRDBサーバへの接続方法〕[1]

マルチスレッド対応のXAインタフェース[1]

マルチスレッド用のライブラリ〔注意事項〕[1]

マルチフロントエンドサーバ[1]

マルチフロントエンドサーバの構成例[1]

マルチフロントエンドサーバの設定[1]

満杯セグメント[1]

み

未使用セグメント[1]

未使用ページ[1]

め

メッセージキュー識別子数[1]、[2]

メッセージキューテーブル数[1]、[2]

メモリ所要量の確認〔バージョンアップ〕[1]

メモリ所要量の計算式〔HiRDB/シングルサーバ〕[1]

メモリ所要量の計算式〔HiRDB/パラレルサーバ〕[1]

メモリ所要量の見積もり方法〔HiRDB/シングルサーバ〕[1]

メモリ所要量の見積もり方法〔HiRDB/パラレルサーバ〕[1]

メモリ配置〔HiRDB/シングルサーバ〕[1]

メモリ配置〔HiRDB/パラレルサーバ〕[1]

も

文字コードの選択[1]

文字集合[1]

文字レパートリ[1]

ゆ

有効保証世代数〔HiRDB/シングルサーバ〕[1]

有効保証世代数〔HiRDB/パラレルサーバ〕[1]

ユーザLOB用RDエリアの作成[1]

ユーザLOB用RDエリアの配置〔HiRDB/シングルサーバ〕[1]

ユーザLOB用RDエリアの配置〔HiRDB/パラレルサーバ〕[1]

ユーザLOB用RDエリアのページ長[1]

ユーザLOB用RDエリアの容量の見積もり[1]

ユーザオウンコーディング[1]

ユーザが定義した抽象データ型を定義した表の作成[1]

ユーザ用RDエリアの作成[1]

ユーザ用RDエリアの配置〔HiRDB/シングルサーバ〕[1]

ユーザ用RDエリアの配置〔HiRDB/パラレルサーバ〕[1]

ユーザ用RDエリアの容量の見積もり[1]

ユティリティが使用する作業表用ファイルの容量[1]

ユティリティ実行時のファイルの容量の見積もり[1]

ユティリティ実行時のメモリ所要量の見積もり[1]

ユティリティ実行時の容量の見積もり[1]

ユティリティによるデータベース作成時に出力されるシステムログ量[1]

ユティリティ用のHiRDBファイルシステム領域の作成[1]

ユティリティ用のHiRDBファイルシステム領域の設計〔HiRDB/シングルサーバの場合〕[1]

ユティリティ用のHiRDBファイルシステム領域の設計〔HiRDB/パラレルサーバの場合〕[1]

ユニークインデクス[1]

ユニットコントローラが使用する共用メモリ〔HiRDB/シングルサーバ〕[1]

ユニットコントローラが使用する共用メモリ〔HiRDB/パラレルサーバ〕[1]

ユニット数が多いシステムを構築する場合の考慮点[1]

ユニット制御情報定義の作成〔HiRDB/シングルサーバ〕[1]

ユニット制御情報定義の作成〔HiRDB/パラレルサーバ〕[1]

よ

横分割の設計[1]

横分割表[1]

横分割表のインデクス定義に関する質問[1]

横分割表の作成[1]

横分割〔プラグインインデクス〕[1]

読み取り専用[1]

予約数[1]

り

リスト用RDエリア〔グローバルバッファの割り当て〕[1]

リスト用RDエリアの作成[1]

リスト用RDエリアの設計[1]

リスト用RDエリアの配置〔HiRDB/シングルサーバ〕[1]

リスト用RDエリアの配置〔HiRDB/パラレルサーバ〕[1]

リスト用RDエリアの容量の見積もり[1]

リスト用RDエリア用のHiRDBファイルシステム領域の作成[1]

リスト用RDエリア用のHiRDBファイルシステム領域の設計〔HiRDB/シングルサーバ〕[1]

リスト用RDエリア用のHiRDBファイルシステム領域の設計〔HiRDB/パラレルサーバ〕[1]

リソース数に関連する環境変数の見積もり[1]

リソースマネジャ[1]

リバランス機能[1]、[2]

リバランスユティリティ（pdrbal）実行時のファイルの容量[1]

る

ルーチン[1]

ループバックアドレス[1]

れ

例外リストからの削除〔Windowsファイアウォール〕[1]

例外リストへの登録〔Windowsファイアウォール〕[1]

レコード数の求め方〔システムログファイル〕[1]

レコード数の求め方〔シンクポイントダンプファイル〕[1]

レコード数の求め方〔ステータスファイル〕[1]

レコード長〔システムログファイル〕[1]

レジストリLOB用RDエリアのページ長[1]

レジストリLOB用RDエリアの容量の見積もり[1]

レジストリ機能の初期設定[1]

レジストリ情報の登録[1]

レジストリの削除[1]

レジストリ用RDエリアの容量の見積もり[1]

列情報作業表の最大数の求め方[1]

列情報作業表の容量の求め方[1]

レプリケーション機能との連携[1]

連絡用ポートのサービス名及びサービスポート番号の設定〔マルチHiRDB〕[1]

連絡用ポートのサービス名の変更〔マルチHiRDB〕[1]

ろ

ローカルバッファ[1]

ローカルバッファの設計[1]

ログ取得モード[1]、[2]

ログレスモード[1]、[2]

わ

ワークディスク[1]

ワークファイル出力先ディレクトリの作成[1]