RDエリアを構成するセグメントやページの大きさによって，ディスク所要量が異なります。この点を考慮してRDエリアを設計する必要があります。RDエリアを設計するときの検討項目を表15-1に，RDエリアに関する最大値・最小値を表15-2に示します。

表15-1　RDエリアを設計するときの検討項目

設計作業ごとの検討項目		長　所	短　所	記載箇所
セグメントサイズ	大きくした場合	行長が変わるような更新をする場合や，クラスタキーを指定した表に行を追加する場合，行を格納した特定のページに近接する未使用のページを確保できるため，データの入出力時間を削減できます。	セグメント数が少なくなるため，一つのユーザ用RDエリアに格納できる表とインデクスの数が少なくなります。	15.2.1
	小さくした場合	一つのユーザ用RDエリアにデータ量の少ない表を多く格納する場合は，余分な未使用ページを削減できます。	ユーザ用RDエリアに大量のデータを追加すると，セグメントの割り当て回数が増加するため，オーバヘッドが大きくなります。 セグメントの数が多くなるため，表を削除したり，表の全行削除をしたりする場合，排他制御の資源が多くなります。
セグメント内の空きページ比率	設定した場合	表にデータを追加する場合，クラスタキーを指定している表に対しては，クラスタキーの値に近い場所のページにデータを格納できるため，データの入出力回数を削減できます。	設定値を大きくする分，ディスク所要量が増加します。	15.2.2
	0にした場合	ディスク所要量を削減できます。	クラスタキーを指定している表の場合，データの追加時にクラスタキーの値に近い場所にデータを格納できなくなるため，格納状態が乱れ，データの入出力回数の削減効果がなくなります。
ページ長	ページ内の未使用領域の比率を設定した場合	UPDATE文で行長が元の行よりも長くなる更新をしても，連続した空き領域が更新後の行長よりも大きい場合は，該当する行がそのページに収まるようになります。 INSERT文で行を繰り返し追加するときに，クラスタキーの値に近い場所のページに，1ページ内が一杯になるまで行を追加できるようになります。	FIX属性の表の場合は格納効率が悪くなります。	15.3.2
	ページ内の未使用領域の比率を0にした場合	FIX属性の表の場合，データが昇順になるようなときは，格納効率が良くなります。	行長が元の行よりも長くなる更新をすると，行が複数ページにわたるため，行にアクセスするときにオーバヘッドが掛かります。
空き領域の再利用	使用した場合	使用中セグメント内の空き領域を有効活用できます。 RDエリア満杯後の空き領域サーチの性能が向上します。	再利用するのに十分空き領域がない場合，空き領域サーチのオーバヘッドが増えます。	15.5
	使用しない場合	空き領域が十分ある状態であれば，挿入処理が高速にできます。	RDエリアの格納効率が低下します。また，RDエリア満杯後の空き領域サーチの性能が低下します。
共用RDエリア	使用した場合	アクセスが多いが，分割が難しい表を共用RDエリアに格納すると，全バックエンドサーバから参照できるため，並列処理の効率が上がります。	共用表を更新する場合，更新する共用表がある共用RDエリアに排他を掛けるので，共用RDエリアのほかの表にアクセスする業務があると，デッドロックが発生することがあります。	15.6
	使用しない場合	共用RDエリアが原因となるデッドロックや，サーバ間のグローバルデッドロックが発生しません。	結合処理などの複雑な検索処理の場合，複数のバックエンドサーバ接続とデータ転送のオーバヘッドが増えます。

表15-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エリアの容量見積もりについては，「17.1　ユーザ用RDエリアの容量の見積もり」を参照してください。ここでは，容量見積もり時の注意事項を説明します。

1. データベース作成ユティリティ又はデータベース再編成ユティリティでインデクスを一括作成した直後は，データはきれいに格納されています。その後のデータ挿入時にすべてのキーを昇順に挿入しないかぎり，インデクスページスプリットが発生するため，インデクスの一括作成時よりインデクスの容量が大きくなります。
2. インデクスページは基本的に使用中空きページを再使用しません。したがって，キー値を変更するような更新及び削除を行った場合，変更又は削除前のキーが格納されていたページを再使用できません。このように再使用されないむだな使用中空きページができてしまいます。ただし，使用中空きページを再利用する運用もできます。詳細は，マニュアル「HiRDB Version 8 システム運用ガイド」を参照してください。
3. キー値の重複がある場合とない場合では基本的にインデクス構造が異なります。このため，正しく重複数を求めないとインデクスの容量が大きく異なってしまいます。インデクスレコード件数が少ない場合は，インデクスの容量に比べてこの誤差の占める割合が大きくなります。