このドキュメントでは、次のトピックについて説明します。
コンテナファイルは、Adabas ユーティリティで作成したディスクファイルです。これらは Adabas ニュークリアスおよび Adabas ユーティリティによって管理されます。これらのファイルの内部構造は Adabas で構成し、保守します。したがって、非常に効率的なディスク使用アルゴリズムを使用できます。
コンテナファイル内のデータは、データベースの作成者により定義されたブロックサイズを持つデータブロックで構成さています。各コンテナタイプのすべてのデータブロックは、いわゆる相対 Adabas ブロック番号（RABN）によりアドレスが付与されます。このアドレスは、4 バイトの符号なし整数で、その値は 0 よりも大きな値です。したがって、Adabas データベースには、各コンテナタイプのブロックを最大 232 - 1 ブロック含めることができます。RABN という用語は、ブロック番号だけでなく、対応するブロックにも使用されます。
Adabas データベースに必要なコンテナファイルは ASSO、DATA、および WORK といいます。いくつかのユーティリティについては、SORT や TEMP といった追加のコンテナファイルが必要になります。
ASSO には、データベースやデータベースファイルの構成データが含まれます。ASSO に格納されるデータの例として次のものがあります。
データベースの物理レイアウトおよび論理レイアウトの概要
データベースの使用ブロックおよび未使用ブロックのリスト
各ファイルのレコードフィールドの記述
非順次データベース検索処理に使用されるディスクリプタ（検索キー）フィールドのリスト
データベースがオフラインのときに Adabas ユーティリティを使用するためのプロテクションメカニズム
データストレージ（単に DATA とも呼ぶ）には、データベースのユーザーデータが含まれます。ディスクスペース要件を削減するために、Adabas はデータ圧縮技術を使用します。これは、ユーザーデータが DATA に格納される前によりコンパクトな形式に変換されるので、ストレージ要件とディスク I/O を著しく削減することを意味しています。
Adabas ニュークリアスは、バックアウトトランザクションと自動再スタートのために必要な更新ログ情報用の一時的なストレージエリアとして WORK を使用します。
WORK のサイズは、次の条件が常に適用されるように選択します。まず、現在アクティブな最も古いトランザクションの開始時から実行されたすべての更新、削除および格納処理を対象に考えます。次に、WORK のサイズを
(変更されたまたは削除されたすべての圧縮レコードのサイズ
+ 変更または挿入後のすべての新しい圧縮レコードのサイズ
+ 変更または削除されたすべての古いインデックス値のサイズ
+ 変更または挿入後のすべての新しいインデックス値のサイズ）
x 4 と等しいかそれ以上にします。
注意:
LOB データを持つデータベースは、LOB データのサイズも考慮の対象となるため（更新されたレコードの場合は更新された LOB のサイズのみ考慮）、必然的にかなり大きな WORK サイズとなります。データベースに LOB データが含まれる場合、4
KB の WORK ブロックサイズが推奨されます。
これらは一時的なストレージエリアおよびワークエリアとして、いくつかの Adabas ユーティリティに使用されます。事前定義された SORT と TEMP コンテナに加えて、Adabas は、ワークスペースとしてニュークリアスまたはユーティリティによって作成される一時ファイルも使用します。これらのファイルは使用後に削除されます。詳細については「一時ワークスペース」セクションを参照してください。
Adabas 論理エクステントは、Adabas ニュークリアスや Adabas ユーティリティが割り当てた一連の RABN 群です。
データベースにロードされた各ファイルに対して、次の各タイプの Adabas 論理エクステントを最低 1 つファイルに割り当てられます。
データストレージ論理エクステント
（データストレージ物理エクステントから割り当てられる）
アドレスコンバータ論理エクステント
（アソシエータ物理エクステントから割り当てられる）
ノーマルインデックス論理エクステント
（アソシエータ物理エクステントから割り当てられる）
アッパーインデックス論理エクステント
（アソシエータ物理エクステントから割り当てられる）
追加の論理エクステントは、ファイル更新の結果として追加スペースが必要になったときに、Adabas ニュークリアスや Adabas ユーティリティによって割り当てられます。
アソシエータおよびデータストレージは、最大 16 個のエクステントを持つことができます：ASSO1 ～ASSO16、DATA1 ～DATA16。SORT および WORK は 2 個のエクステントを持つことができます：SORT1 と SORT2、WORK1 と WORK2。Temp は、1 個のエクステントを持つことができます：TEMP1。これらのエクステントは、連続する数字で定義される必要があります。例えば、ASSO1、ASSO2 および ASSO4 と定義すると、ASSO3 の定義がないため、ASSO4 は認識されません。
ディスクやその他の補助的な記憶媒体の領域が物理的に分離している場合など、ASSO、DATA、WORK、SORT、および TEMP の各データセットのエクステントが複数になることがあります。ユーティリティがこれらのエクステントのいずれかを参照するとき、参照用の環境変数を使用します。ASSO データセットに対する環境変数は ASSO1、ASSO2 など、DATA データセットについては DATA1、DATA2 などで、WORK、SORT および TEMP についても同様です。例えば、ユーティリティが 3 つのエクステントを持つ ASSO データセットにアクセスする場合には、環境変数 ASSO1、ASSO2 および ASSO3 に、これらのエクステントの参照先を設定しておく必要があります。
ASSO、DATA、および WORK コンテナのエクステントを見つけるための検索方法は次のとおりです。
ASSO の場合は、環境変数 ASSO1、ASSO2 など、DATA の場合は、環境変数 DATA1、DATA2 など、WORK の場合は、環境変数 WORK1 を調べてみます。そのような環境変数が存在している場合、それは対応するコンテナエクステントのファイル名を含んでいなければなりません。
DBnnn.INI ファイルに該当するエントリがあるかどうか探してみます。そのようなエントリが存在している場合、それはコンテナエクステントのファイル名を含んでいなければなりません。DBnnn.INI ファイルの詳細については、Adabas 拡張オペレーションのドキュメントを参照してください。
ファイル CONTx.nnn を次のデータベースディレクトリで検索します：UNIX：$ADADATADIR/dbnnn、Windows：%ADADATADIR%\dbnnn。ここで、CONT は ASSO、DATA、WORK のいずれか、x はエクステント番号、nnn は 3 桁のデータベース ID をそれぞれ表します。
SORT と TEMP を使用する検索方法については、「一時ワークスペース」を参照してください。
ASSO エクステントの最大数は (ASSO1 ブロックサイズ - 2) / 12 で求められます。DATA エクステントの最大数は (ASSO1 ブロックサイズ * 3 - 2) / 12 で求められます。ただし、下記の条件に従えば、計算値よりも小さくすることができます。
ASSO と DATA エクステントの合計数が 2721 を超えることはできません。隣り合った DATA エクステントのブロックサイズを比較していったときに、互いのブロックサイズが異なっている回数分だけ、この最大数は 1 つずつ減っていきます。したがって、公式は次のようになります。
ASSO エクステント数 + DATA エクステント数 + (隣り合わせの DATA エクステントを比較したときにブロックサイズが違っている回数) ≦ 2721
例えば、データベースが 1 個の ASSO エクステントと 1360 個の DATA エクステントから構成されていて、隣り合った DATA エクステントのブロックサイズがどれもサイズが違っているとすると、データベースのエクステントの合計は、1 個の ASSO エクステント + 1360 個の DATA エクステント + 1359 個の異なる DATA ブロックサイズ = 2720 となります。
次の表は、コンテナファイル ASSO1 のサイズと、ASSO と DATA のエクステントの数との対応関係を例示したものです。"最良のケース" の欄のエントリは、すべての DATA エクステントが同じブロックサイズの場合の DATA エクステントの最大数です。"最悪のケース" の欄のエントリは、隣り合った DATA エクステントのブロックサイズを比較するとどれも違っている場合の DATA エクステントの最大数を示しています。
ASSO1 blocksize max. number of max number of DATA extents
ASSO extents best case worst case
-----------------------------------------------------------------------
2 KB (2048 bytes) 170 511 511
3 KB (3072 bytes) 255 767 767
4 KB (4096 bytes) 341 1023 1023
5 KB (5120 bytes) 426 1279 1148
6 KB (6144 bytes) 511 1535 1105
7 KB (7168 bytes) 597 1971 1062
8 KB (8192 bytes) 682 2047 1020
SORT は最高 50 までのエクステントを持つことができます。SORT1、SORT2、...、SORT50。
WORK はエクステントを 1 個のみ持つことができます：WORK1。
TEMP は最高 10 までのエクステントを持つことができます：TEMP1、TEMP2、...、TEMP10。
WORK ブロックサイズに 8K 以下の値を指定した場合、PLOG ブロックサイズは 8K に設定されます。WORK ブロックサイズに 8K よりも大きい値を指定した場合、PLOG ブロックサイズは 32K に設定されます。
完了したトランザクションがデータベースのリカバリ時にすべて再適用されるように、ET コマンドの発行後に毎回、PLOG バッファがフラッシュされ PLOG に反映されます。この処理は、PLOG バッファがいっぱいになっているかどうかに関係なく行われます。後に ET コマンドが続く場合、PLOG バッファがいっぱいになるまで、ET コマンドの発行時に、現在の PLOG ブロックが繰り返し上書きされます。新しい PLOG ブロックは、PLOG バッファがいっぱいになったときにだけ使用されます。WORK パート 1 ブロックも同様に、自動再スタート後にデータに不整合が生じないように、WORK パート 1 バッファがいっぱいになるまで、ET コマンド発行後に、現在の WORK パート 1 ブロックが繰り返し上書きされます。
通常、PLOG と WORK のブロックサイズが大きい場合は、それらが小さい場合に比べて、PLOG バッファと WORK パート 1 バッファがいっぱいになるまでのトランザクションの量が多くなります。この場合、I/O 転送の平均サイズは大きくなりますが、ET コマンドの数は変わらないため、I/O 転送の全体的な回数は変わりません。
このような理由があるため、データレコードを圧縮して 8K 以下になる場合は、WORK ブロックサイズを 8K 以下に指定し、PLOG ブロックサイズを 8K に設定することをお勧めします。
次に示すように、データベースコンテナファイルを作成およびアクセスするためのメソッドが 2 つ用意されています。
デバイスタイプ非依存型アクセスメソッド
デバイスタイプ依存型アクセスメソッド
デバイスタイプ非依存型アクセスメソッドでは、コンテナファイルの作成時に、できるだけ物理的に連続した領域を確保するように、Adabas はオペレーティングシステムに要求します。Adabas ブロックは、物理デバイスの特性によらず連続して書き込まれます。あるコンテナファイルのアクセスメソッドとして、デバイスタイプ非依存型アクセスメソッドを選択する場合には、そのコンテナファイルの作成時にサイズをメガバイト単位で指定します。
最新のハードウェア（RAID システム、可変トラックサイズディスク、ストレージサーバーなど）では、システムにより返されるトラックサイズは、不定数であり、ディスクの物理的特性との関連性を持ちません。この場合、デバイスタイプ非依存型アクセスメソッドを使用します。
デバイスタイプ非依存型アクセスメソッドは、常に SORT および TEMP コンテナファイルへのアクセスに使用されます。
コンテナファイルのアクセスメソッドとして、デバイスタイプ依存型アクセスメソッドを選択する場合には、そのコンテナファイルの作成時に、シリンダ境界線を基点とする連続したシリンダの数を指定します。セクタ／トラックおよびトラック／シリンダの値には、システムからデバイス情報として返される値を使用します。また、クラスタサイズは、1 つのシリンダに割り当て可能なサイズにする必要があります。言い換えれば、1 シリンダあたりのセクタ数は、クラスタサイズの倍数になります。
このアクセスメソッドを使用してブロックがコンテナファイルに書き込まれると、このブロックがトラックに収まることが確実になります。トラックサイズが Adabas ブロックサイズの倍数ではない場合、最後のトラックは使用されません。これにより、Adabas ブロックは 1 回のディスク回転で読み込まれます。
セクタ／トラック、トラック／シリンダおよびクラスタサイズを表示するには、OpenVMS DCL コマンド、"SHOW DEVICE/FULL <ディスク名>" を使用します。
デバイスタイプ非依存型アクセスメソッドを使用する場合、DATA コンテナおよび WORK コンテナファイルのブロックサイズには、ASSO ブロックサイズの倍数を選択する必要があります。これにより、異なるコンテナファイルタイプのブロックを置き換えるときに、Adabas バッファプール内の一時的に未使用なスペースを最小化できます。
この規則を使用すると、異なる組み合わせのブロックサイズが可能になります。
| ASSO | DATA | WORK |
| 3 K | 6 K | 6 K |
| 2.5 K | 7.5 K | 7.5 K |
| 2 K | 4 K | 8 K |
デバイスタイプ依存型アクセスメソッドを使用する場合でも、この規則を使用することをお勧めします。このメソッドを使用するためにブロックサイズを選択する場合は、トラックの終わりの未使用のスペースが過度に大きくならないように、トラックあたりのセクタ数も考慮に入れる必要があります。
トラックあたり 62 セクタのディスクの場合（すなわち、トラックサイズは 31K）のディスクの場合、コンテナファイルに選択したブロックサイズごとのトラックあたりの未使用スペース量がどうなるかを次の表に示します。
| ASSO/DATA/WORK ブロックサイズ | トラックあたりの Adabas ブロック | トラックの終わり未使用スペース |
| 4 K | 7 | 3 K |
| 8 K | 3 | 7 K |
| 3 K | 10 | 1 K |
| 6 K | 5 | 1 K |
WORK ブロックサイズに 8K 以下の値を指定した場合、PLOG ブロックサイズは 8K に設定されます。WORK ブロックサイズに 8K よりも大きい値を指定した場合、PLOG ブロックサイズは 32K に設定されます。
完了したトランザクションがデータベースのリカバリ時にすべて再適用されるように、ET コマンドの発行後に毎回、PLOG バッファがフラッシュされ PLOG に反映されます。この処理は、PLOG バッファがいっぱいになっているかどうかに関係なく行われます。後に ET コマンドが続く場合、PLOG バッファがいっぱいになるまで、ET コマンドの発行時に、現在の PLOG ブロックが繰り返し上書きされます。新しい PLOG ブロックは、PLOG バッファがいっぱいになったときにだけ使用されます。WORK パート 1 ブロックも同様に、自動再スタート後にデータに不整合が生じないように、WORK パート 1 バッファがいっぱいになるまで、ET コマンド発行後に、現在の WORK パート 1 ブロックが繰り返し上書きされます。
通常、PLOG と WORK のブロックサイズが大きい場合は、それらが小さい場合に比べて、PLOG バッファと WORK パート 1 バッファがいっぱいになるまでのトランザクションの量が多くなります。この場合、I/O 転送の平均サイズは大きくなりますが、ET コマンドの数は変わらないため、I/O 転送の全体的な回数は変わりません。
このような理由があるため、データレコードを圧縮して 8K 以下になる場合は、WORK ブロックサイズを 8K 以下に指定し、PLOG ブロックサイズを 8K に設定することをお勧めします。
データベースの空き容量がなくなると、Adabas はデータベースコンテナ ASSO と DATA を自動的に拡張することができます。このための必要条件は、ニュークリアスパラメータ OPTIONS=AUTO_EXPAND が指定されていることです。新しいスペースを割り当てるために用いられる方法は以下のとおりです。
新しいスペースを必要としているコンテナの最後のエクステントを増やそうとします。エクステントが、コンテナの新しいスペースに必要なブロックサイズと同じブロックサイズを持っている場合にのみ可能です。
次のコンテナエクステントのための環境変数があるかどうかをチェックします。環境変数が存在している場合、それは次のエクステントのファイル名を含んでいなければなりません。そして、指定された位置には新規コンテナエクステントに利用可能な十分なスペースを持っていなければなりません。
DBnnn.INI ファイルがセクション RESERVED_LOCATIONS にエントリを含んでいるかどうかをチェックします。含んでいる場合は、指定された位置の 1 つに新規コンテナエクステントを割り当てます。DBnnn.INI ファイルの詳細については、Adabas 拡張オペレーションのドキュメントを参照してください。新しいコンテナエクステントのファイル名は、CONTx.nnn になります。CONT は ASSO または DATA、x はエクステント番号、nnn は 3 桁のデータベース ID をそれぞれ表します。
新規コンテナエクステントをデータベースディレクトリに割り当てます（UNIX：$ADADATADIR/dbnnn、Windows：%ADADATADIR%\dbnnn）。新しいコンテナエクステントのファイル名は、CONTx.nnn になります。CONT は ASSO または DATA、x はエクステント番号、nnn は 3 桁のデータベース ID をそれぞれ表します。
注意:
Adabas はインデックスブロックを作成するとき、ディスクリプタ値のサイズに依存するブロックサイズによって、次のようにブロックを割り当てます。
253 バイトより大きなディスクリプタ値は、ブロックサイズが 16 KB 以上の大きなインデックスブロックに格納されます。
小さ目のディスクリプタ値は、ブロックサイズが 16 KB 未満の小規模のインデックスブロックに格納されます。
したがって、大きなディスクリプタ値を格納する場合、データベースに大規模のブロックサイズで ASSO コンテナを定義しなければなりません。
SORT データセットは ASSO および DATA と同じボリュームに配置しないことをお勧めします。10 万件を超えるレコードを含むファイルを処理するとき、ディスクアーム移動を最小化するため、SORT エリアを 2 つのボリュームに分割すべきです。
小規模のデータだけを処理するときには、SORT データセットを省略することができます（例えば空ファイルのフィールドのインバート）。このとき使用する Adabas ユーティリティはインコアソートを行います。
SORT データセットは、処理する最大ディスクリプタをソートできるほど十分な大きさが必要です。将来的にデータの圧縮や圧縮解除を行うときに備えて、ADACMP または ADAULD ログにディスクリプタが並んで出力されているかどうか、SORT と TEMP の推奨サイズを確認しておいてください。
ADAINV SUMMARY 機能はメモリ常駐のソートに対して必要な SORT および LWP も表示します。
注意:
ADAINV にメモリ常駐のソートを行わせたい場合、LWP パラメータがメモリ常駐ソートに十分な大きさであっても、ADAINV は最初のディスクリプタに対してファイルベースのソートを行う可能性があるので、SORT データセットを指定しないでください。これは、ADAINV
がディスクリプタのサイズを前もって知らないからです。可能であれば、後続のディスクリプタは常にメモリで処理されます。
TEMP データセットは DATA および SORT を同じボリュームに設置しないことを推奨します。
TEMP データセットは、次の状況で使用されます
ノーマルインデックスとメインインデックスのロード
アッパーインデックスの更新
TEMP のサイズはノーマル／メインインデックスのロード時のシステムパフォーマンスと密接な関係がありますが、ロードが正常に終了するどうかは、TEMP のサイズとは関係がありません。一方、アッパーインデックスの更新時は、必要なすべてのデータは TEMP データセットに収まる必要があります。
ADACMP および ADAULD では、ディスクリプタの概要に推奨の TEMP サイズが表示されます。
TEMP データセットは、複数ディスクリプタをインバートする場合のディスクリプタ値の中間ストレージに使用されます。
TEMP のサイズはノーマル／メインインデックスのロード時のパフォーマンスと密接な関係がありますが、ロードが正常に終了するどうかは、TEMP のサイズや有無とは関係がありません。TEMP データセットは、最低でも 2 番目に大きなディスクリプタの格納に十分な大きさにすることをお勧めします。TEMP データセットのサイズを拡張すると、パスの数（つまり、処理されるファイルの DATA エリアが読み込まれる回数）を減らすことができます。ADAINV/ADAMUP SUMMARY 機能により、TEMP データセットに望ましいサイズが表示されます。
Adabas コンテナファイルは、ファイルシステムまたは RAW デバイス（UNIX のみ）のいずれかに作成できます。
次の点を考慮する必要があります。
一般的に、ファイルシステムのコンテナか、RAW デバイスのコンテナのどちらが優れているかを判断することはできません。これは、Adabas の使用方法に大きく依存します。ファイルシステムにはデータをバッファできるという利点があります。つまり、ファイルシステム I/O が必ずしもディスク I/O になるとは限らず、ファイルシステムで I/O 動作が最適化される可能性もあります。一方、ファイルシステムには、RAW デバイスでは回避されるオーバーヘッドがあります。したがって、Software AG では、両方を試して、特定の環境では最高の性能を発揮する I/O システムを使用することを推奨しています。
RAW デバイスは 2 テラバイトに制限されています。
 |
注意: Adabas では、RAW デバイスが 2 テラバイト以下であるかどうかは確認されませんが、より大きな RAW デバイスを使用すると、予期しないエラーが発生する可能性があります。 |
2 テラバイトを超えるコンテナは、ファイルシステムに作成する必要があります。
ファイルシステムでコンテナを使用し、RAW デバイスのコンテナと同様の動作を望む場合は、ADANUC パラメータ UNBUFFERED を使用することをお勧めします。
Adabas コンテナは、ローカルディスクまたはリモートストレージサーバーに作成できます。
ストレージサーバー上のディスクを使用する場合、Adabas が実行されているコンピュータとストレージサーバーの間のネットワーク速度によって I/O 速度が制限されることがあります。これにより、Adabas の全体的なパフォーマンスが低下する可能性があります。
ファイルシステムのスナップショットをサポートする一部のファイルシステムでは、更新されたブロックが上書きされず、別の場所にコピーが書き込まれます。データベースに多数の更新があると、データが断片化されて、I/O パフォーマンスが大幅に低下することがあります。Software AG では、ストレージシステムのベンダーに問い合わせて、ストレージシステムでこれが発生する可能性があるかどうか、およびこれらの問題を回避するために実行できる方法について確認することを推奨しています。
バッファプールが十分に大きい場合（ADANUC パラメータ LBP）、通常、I/O パフォーマンスは重要ではなりません。これは、ほとんどの論理 I/O が物理 I/O を必要としないことが理由です。ただし、WORK および PLOG（Adabas プロテクションログ）が含まれているデバイスのパフォーマンスは重要です。これは、WORK および PLOG に、データベースの整合性を保証するために必要なログ情報が含まれていることが理由です。したがって、ET（トランザクション終了）コマンドは、ログ情報が WORK および PLOG デバイスに安全に保存されている場合にのみ完了できます。これらの理由から、Software AG では、更新の負荷が高い場合に、非常に高速なストレージデバイスを使用することを推奨しています。WORK および PLOG 用の通常のストレージデバイスを高速デバイスに置き換えると、パフォーマンスが最大 30% 向上します。もちろん、パフォーマンスの向上は、実行する Adabas コマンドの組み合わせと、ストレージデバイスの速度の差に大きく依存します。