Ａ−ＶＸのデータベース（３）

入門レベルを少し外れるかもしれませんが、もう少し詳しく説明します。

１　キーファイル

レコードキーを作ると必ずキーファイルが１つできます。キーファイルは、ＯｒａｃｌｅやＳＱＬ　Ｓｅｒｖｅｒ、ＭｙＳＱＬなど通常一般的なＲＤＢ（以下オープン系ＲＤＢと書きますね）でいうところのインデックスです。
Ａ−ＶＸ　ＲＤＢはキーを８個まで作ることができます。

さて、オープン系ＲＤＢの入門書の説明によく書いてあることとして、　

「インデックスを作ると検索は速くなるが、インデックスをたくさん作るとレコードの挿入、削除、更新などの（インデックスの更新が走るので）パフォーマンスが悪くなる」　

というのがあります。

Ａ−ＶＸのキーファイルはインデックスと同等なので、キーをたくさん作るとキーファイルも同じだけでき、オープン系ＲＤＢと全く同じ理由でパフォーマンスが悪く（簡単に言うと遅く）なります。

Ａ−ＶＸは仕組み的に複数のキーを作ることが多いので、単に「遅くなります」で終わってはよろしくありません。このためＡ−ＶＸ　ＲＤＢではチューニングする方法がいくつか用意されています。

その１つがキーファイルの更新モードです。

２　更新モード

キーファイルそれぞれに「同時更新モード」か「実行時生成モード」かの指定ができます。

社員番号や社員名や所属部門などの社員の情報が入ったデータベースがあるとします。社員番号と所属部門、職種の３つの列にキー（つまりインデックス）が定義されているとします。

新入社員が入ってきたので、その人の情報を社員データベースに入れましょう。まず新入社員のデータがデータファイルに入ります。レコードが挿入されるとキーファイル（インデックス）の更新も必要になります。

データを入力すると同時にキーファイルの更新が入るのが「同時更新モード」です。
社員番号のキーファイルと所属部門のキーファイルと職種のキーファイルの３つのファイルが「同時更新モード」なら、これら３つのファイルも同時に更新します。データファイルとキーファイルの合計４ファイルのデータが更新されることになるので、「同時更新モード」だと遅いよなぁということはわかると思います。

キーファイルが１つも無ければデータファイル１つの更新で済むのに、毎回４ファイルを更新しなければなりません。１回ぐらいならそれほど差は無いかもしれませんが、これが百レコード、千レコードになるとかなりな性能差になりそうな気がしますよね。

一方、必要な時にキーファイルの更新が入るのが「実行時生成モード」です。
キーファイル３つ全てが「実行時生成モード」とします。新入社員のデータがデータファイルに入ったときは、キーファイルの更新は入りません。

その後、キーファイルを使用するときにそのキーファイルだけが更新されます。一旦更新されるとそのキーファイルは以降「同時更新モード」と同じ動きになります。
例えば新入社員のデータを入力した後に、社員番号で検索するときは、社員番号のキーファイルだけ更新してから、検索処理が行われます。


データファイルが更新されたときは最低限のファイルしか更新（例の場合はデータファイルだけ）しないので、「同時更新モード」より速そうだということはわかると思います。

一方、キーファイルを使用するときに、キーファイルの更新が入ることがあるので、ちょっとだけ遅くなりそうかなぁということが分かると思います。１万件データを挿入した後に「実行時生成モード」のキーを使って処理すると１万件分のデータのキーの情報をインデックスに反映させてから検索するということになります。
ただし一回更新されると以降は「同時更新モード」と同じ動きになるので、検索のときに遅くなるということはありません。

社員番号のキーファイルは「同時更新モード」、他の２つは「実行時生成モード」みたいにキー毎に変えることができます。
頻繁に使用するキーは「同時更新モード」、「毎日１回夕方の集計処理にしか使いません」のように時々にしか使わないキーは「実行時生成モード」にするみたいです。

３　キーファイルの強制的更新

「実行時生成モード」のキーファイルを強制的に更新させることができます。

実際、実行時だけしか更新できなかったら大変です。業務中どんどんデータを入力して、いざ検索しようとしたら「キーファイル（インデックス）を更新し始めてなかなか結果が戻ってこないよ」みたいなことになったら困りものです。
そこでサーバの暇な時間（データベースを使っていない、CPUの使用率の低い時間帯etc）を使って、キーファイルを強制的に更新してしまおうという訳です。

例えば、毎月月末にしか使わないようなキーファイルがあるとします。そのようなキーファイルは「実行時生成モード」にしておきます。
１カ月の間にデータの更新が何万件とあって、キーファイルに反映すべき情報がたくさんあるとします。（最近のサーバは速いから、たぶんこれだけあってもキーファイルの更新はすぐ終わるかもしれませんが・・・。）このままだと月末処理の最初の検索の前にキーファイルの更新が行われて、たぶんちょっと時間が掛かってしまいそうです。
そこで月末処理を行う前の日の夜間にバッチ処理で強制的にキーファイルの更新を行っておけば、実際に処理を行う時にはキーファイルは最新状態、従ってすぐに検索できる、というようになります。

４　キーファイルの再編成

さて話は変わりますが、オープン系ＲＤＢの説明書のインデックスのところには　

「データを大量に削除した場合はインデックスを再構築して適切な構造を保つようにしたほうが良いこともあります」　

みたいなことが書かれていることがあります。

Ａ−ＶＸのキーファイルはインデックスと同じですので、同じ話になります。
Ａ−ＶＸの場合はキーファイルの再編成とか言われ、システムメニュー画面から「データ操作支援−Ｈ／再編成」か＃ＡＢＣ（あるいは＃ＭＩＸＧＮ）で行います。