Ａ−ＶＸ／ＲＤＢのいろいろな機能
- １ 条件式付き表定義
-
条件付き表とは、条件式付き表定義により定義される仮想表です。
条件式付き表は、条件式（行の制約条件）に合致した行のみを参照・更新・追加・削除することができ、その評価は、条件式付き表のオープン直後の最初の命令、および行の追加・更新・削除命令のたびに行われます。
一般的なＲＤＢでビューを作るときに「create view xxx as select ・・・ where 」でwhereで条件式を指定したようなものです。
- ２ 自動アライン
-
Ａ−ＶＸ／ＲＤＢは削除されたレコードはそのままでは利用されないので、削除レコードが増えるとレコードの追加ができなくなります。それでは困るので、通常はユーティリティを利用して削除レコードをアラインして未使用領域にします。
自動アライン機能とは、ＲＤＢの表をオープン後の最初にアクセスにおいてあらかじめ指定している最小未使用領域よりファイル内の未使用領域が小さい場合に、自動的にアラインを行う機能です。
- ３ 結合型仮想表のセカンダリ表の項目に対する条件／分類指定
-
結合型仮想表のセカンダリ表の項目に対して条件／分類を指定した場合、テンポラリワークファイルに結合結果を出力します。以降の参照命令は、ＳＣＲＡＴＣＨまたはＣＬＯＳＥまでテンポラリワークファイルのデータに対する処理になります。
- ４ １，２バイト混在フィールド（検索処理指定）
-
英数字項目に対して、１、２バイト混在文字の部分検索を行う場合や１，２バイト混在文字を含む表をＲＤＢサーバでアクセスする場合、２バイト文字の一部（後ろの１バイトのコード）を１バイト文字と誤って検索してしまうことがあります。そうなると正しい結果が返ってこないことになります。
このような場合はデータディクショナリ保守ユーティリティ（＃ＤＤＭ）で１，２バイト混在フィールドの検索処理方法を指定することにより、正しく検索できるようになります。ただし性能が約１．３倍程度低下するとのことです。
- ５ 共用／排他制御
-
今までＲＤＢファイルの実体は複数索引順編成ファイルだと何度も書きました。そのようなわけで、ＲＤＢファイルの共用／排他制御は従来のファイルシステムと同様に制御されます。
簡単に復習すると次の通りです。
複数のプログラムから同時にＲＤＢファイルをアクセスする場合は、次の三種類のモードにより適切に制御します。このモードは表のオープン時に指定することができます。- 排他モード（ＥＸＣＬＵＳＩＶＥ）
- 保護モード（ＰＲＯＴＥＣＴＥＤ）
- 共用モード（ＳＨＡＲＥＤ）
あるプログラムで処理中のレコードを他のプログラムがアクセスに行くと、そのレコードに対する処理が終わるまで、他のプログラムからのアクセスを待ち合わせをします。この機能をレコード排他制御といいます。
ＲＤＢファイルの共用／排他制御やレコードの排他制御の詳細は、ファイルのところに書いた説明を見てください。
- ６ データファイルの再編成
-
ＲＤＢファイルの実体は複数索引順編成ファイルです。複数索引順編成ファイルは、データファイルの再編成という作業が必要になります。そういう訳で、ＲＤＢファイルもデータファイルの再編成という作業が必要になります。
データは追加した順（発生順）に格納されていると書きました。
データファイルは後ろの方に空き領域があって、前から順番にデータが入っていきます。
データを削除してもそこは再利用されません。データを削除していくと、だんだん歯抜けの状態になります。
上の図の�い妊譽魁璽稗討鯆媛辰垢襪箸�に、レコードＣを削除したところに書き込まない理由は次の通りです。レコードＣを削除したところに書き込むと、レコードＡ、レコードＢ、レコードＦ、レコードＤ、レコードＥという順番になり、Ａ−ＶＸ／ＲＤＢの特徴である「追加した順（発生順）にデータを格納」という決まりに反してしまうからです。
データを削除した部分は再利用されないので、データを挿入したり削除したりを繰り返していくと、だんだん新規にデータを挿入できる空きの領域（未使用領域）が減っていき、そのうち未使用の領域が無くなって全く新規データを挿入できなくなってしまいます。
でも削除した部分は実際には利用されていない場所です。この削除した部分を再利用できれば、そこにまた新規データを挿入していくことができますよね。
この削除した部分を再利用できるようにすることを「データファイルの再編成」といいます。
データファイルの再編成が行われると、「追加した順」の関係が崩れないようにデータの入ったレコードを前に移動していき、後ろに削除した部分が集められて、そこが未使用領域に変わります。
データファイルの再編成を行うと、削除した部分を再利用できるようになります。
データファイルの再編成は時間が掛かります。データのサイズにもよりますが、数分かかる場合もあります。
普通はデータファイルは「自動アライン（自動再編成）」されるようになっており、ほとんど意識する必要はありません。
ただしこれには１つ問題があって、再編成を実行している最中はデータにアクセスできません。つまり業務中にいきなり一時的にデータアクセスが遅くなる、あるいは一時的に業務アプリが停止したような感じになることがあり得るわけで、シビアな状況でこれが起きると非常に困ることになります。
このため手動で強制的に再編成する方法もあり、サーバが暇な時間帯にバッチ処理で強制的に再編成をやってしまう、というようなことを行うこともできます。このようなときには通常は夜間バッチや月末処理のバッチの中に再編成処理を入れ込むということをやっていることが多いです。Ａ−ＶＸ／ＲＤＢでデータファイルがいっぱいになってこれ以上入らないという状態は２種類あって、１つは上で説明したように削除データがある状態、もう１つは本当にデータファイルにデータがいっぱいになっている状態です。
前者の方はデータファイルの再編成をして削除データを未使用状態に変更すれば又データを入れることができるようになるし、後者の方はさらにデータを入れたいのならば、データファイルを大きく拡張しなければならない、ということになります。
なお先に説明したキーファイルの再編成とデータファイルの再編成は別物（両方ともファイルの中身を整理するという点では同じですが）なので注意してください。
- ７ ＲＤＢファイルを複数索引順編成ファイルとして読み書き
-
最初にＡ−ＶＸ／ＲＤＢは複数索引順編成ファイルの上に表定義というものを被せたものだと書きました。
ＲＤＢとしてではなく、複数索引順編成ファイルとしてアクセスすることも可能です。表定義という布をピラッとまくって、隙間からファイルを覗くみたいな感じですね。これは特に禁止されていません。
理論的にはＲＤＢファイルをＲＤＢファイルとして使ったり複数索引順編成ファイルとして使ったり、混在で読み書きしても問題ありませんが、キーファイルの更新方法に差異があるなど、いろいろと複雑な話が出てくると思うので、実際のところはＲＤＢファイルはＲＤＢファイルとして読み書きするのがよさそうです。
- ８ ＲＤＢの性能改善
-
何度もしつこい感じですが、ＲＤＢファイルは複数索引順編成ファイルなので、ファイルシステムの性能改善方法がそのまま使えます。
ＮＥＣの公式のリレーショナル型データベース説明書に書いてある以上の情報を私は持たないので、項目の羅列だけにします。
- 8.1 バッファ参照モードの改善
-
ファイルシステムのバッファのファイルアクセスの高速化の手段を使うことができます。
- ＭＯＶＥモード（ＭＯＶＥモード）
- ＭＯＶＥモード２（ＭＯＶＥ ＭＯＤＥ２）
ＭＯＶＥモード２は別名バーストモードと呼ばれており、高速化が期待できますが、制約も多いので注意が必要です。
それぞれの参照モードの説明は、ファイルのところに書いてありますので、そこを見てください。
- 8.2 ディスクバッファのサイズの改善
-
ディスクバッファを大きく確保すると、業務プログラムの処理性能を改善することができます。
- 8.3 データファイルの改善
-
データファイルのブロック化係数（ブロック長）を改善することによって、業務プログラムの処理性能を大幅に改善することができます。 順アクセスの多いファイルの場合はブロック化係数を大きくして、ランダムアクセスが多い場合はブロック化係数はそれほど大きくしないようにします。
- 8.4 キーファイルの改善
-
キーファイルについてもいくつか改善案があります。
- 領域確保位置の改善：データファイルとキーファイルの領域確保する位置はできるだけ隣接するようにする
- 更新モードの改善：頻繁に利用するキーファイルは同時更新モードに，頻繁に利用しないキーファイルは実行時生成モードにする
- キーブロック長の改善：キーブロック長を大きくする
- 使用率の改善：更新がほとんどないキーファイルは，使用率を上げて一度生成をしてから利用する
キーファイルはインデックスなので、検索等では高速化に寄与しますが、キーファイルの数が多いと書き込み時の性能に影響します。キーファイルは必要なものに絞ることも必要です。
- ９ ＤＢエンジン機能
-
ＤＢエンジンは、ハードディスク上のファイルをメモリへ貼り付けることにより、ファイルに対する処理を高速化する機能です。ＲＤＢファイルも対象です。
ＤＢエンジン機能はファイルシステムのところで説明済みなので、そちらを参照してください。
