LF と INDEX の違い

世の中には LF とインデックスはまったく同じものだと思っている方がいるのではないでしょうか。

実はかく言う私もそう思っている一人だったのですが、おそらくは SQE あたりから、こうした OS/400 から見たデータベース関係のものと SQL インターフェイスでのデータベース関係のものはそれぞれはかなり違うものになってきているようです。

V3R1 などの頃には、データベース関係の新機能、たとえばトリガーや参照制約などは SQL インターフェイスではなく OS/400 のコマンドや DDS で実装されてきていましたが、最近の、カラムレベルの暗号化や、マテリアライズ照会表、"INSTEAD OF" トリガーなどのデータベース関連の機能拡張は SQL インターフェイスのみによるものになってきています。

DSPFD の出力に「SQL ファイル・タイプ」などといった項目が増えていたりすることから、SQL インターフェイスによって作成されたものだけが持つ機能なんてのもあっておかしくないんじゃないかという気がします。実際にテーブルと PF で挙動が違うことがあったりしました。

以前、LF があるのにそれがオプティマイザーによって選択されない、なんて無能な機能なんだ、といったようなことを聞いたことがありましたが、実はそれは私たちがこうした OS/400 のデータベース・オブジェクトと DB2/400 にとってのデータベース・オブジェクトを混同していることによる勘違いなのかもしれません。

少なくとも、今回わかったことは LF とインデックスは別のもので、おそらく SQL インターフェイスからそのアクセス・パスを使ってほしい場合はきちっとインデックスを作成しておかないといけないようになっているのだと思います。

今後は「OS/400 のオブジェクトを SQL から使う」から「SQL オブジェクトを OS/400 からも使う」に発想を転換していかないといけないんじゃないでしょうか。

とりあえずの実験の結果なので画面ショットがかなり多くなってしまっていますが、ご容赦ください。


物理ファイルを準備

同じ物理ファイル (PF) を作って、それに対して LF やインデックスを作成してみて比較してみることにしました。

TOKMSP とまったく同じ TOKMSP2 を CRTDUPOBJ で作ります。

会社名(カタカナ) をキーにした論理ファイル (LF) をそれぞれに作成するために DDS を用意します。

ベースになる物理ファイル (PF) を TOKMSP にし、TKNAKN フィールドをキーに指定しました。

同じ LF を TOKMSP2 にも作成するための DDS です。
PFILE キーワードのところが違うだけですね。

先に LF を作成

まず TOKMSP に対して LF を作成します。

TOKMSP に対しての LF のファイル記述を DSPFD コマンドで見てみます。

これがその LF のファイル記述ですね。
SQL ファイル・タイプ」といった属性がないことがわかります。

「索引サイズ」は 24576 になっています。

先にインデックスを作成

TOKMSP2 に対しては、先に LF と同じ内容のインデックスを作成してみましょう。

会社名(カタカナ) をキーにします。

インデックスが作成されました。

こちらはその TOKMSP2 に対するインデックスのファイル記述です。
SQL ファイル・タイプ」に "INDEX" という文字が見えますね。

「索引サイズ」が TOKMSP に対する LF では 24576 であったのに対し、こちらでは 139264 になっています。

先にインデックスを作成し LF を次に作成

TOKMSP2 に対する LF を続けて作成してみましょう。

こちらが TOKMSP2 に対する、インデックスと同内容の LF のファイル記述になります。

まず、「SQL ファイル・タイプ」はありません。

「索引サイズ」が 139264 と、先に作成したインデックスと同じ値になっています。

「暗黙のアクセス・パスの共用」が "YES"になっています。

先に LF を作成し インデックスを次に作成

今度は TOKMSP に対して、すでにある LF と同内容のインデックスを作成してみましょう。

こちらが、同内容の LF がすでに存在する TOKMSP に対して作成したインデックスのファイル記述になります。

TOKMSP2 に最初に作成したインデックスと同じような内容になっているのが確認できます。

「索引サイズ」は 139264 となっており、新規にインデックスを作成した場合と同じ値になっています。
先に作成した LF の 24576 とは違っているのがわかりますね。

「暗黙のアクセス・パスの共用」が "NO" になっています。
つまり異なるアクセス・パスが作られているということがわかります。LF のアクセス・パスではおそらく役不足で共用できない、ということでしょうか。(かなりサイズも違いますしね)

SQL から使用されるのはインデックス優先

LF を先に作成した TOKMSP でも、 Visual Explain で見てみるとオプティマイザーによって選択されているのはインデックスの方になっています。

インデックスを先に作成した TOKMSP2 でも、オプティマイザーが選択するのはやはりインデックスです。

先に LF を作成した方では「最適化された索引のリスト」に LF もインデックスもリストされていますね。
双方が考慮された上、インデックスが選択されていることが重み付けの数値でわかります。

先に LF を作成したケースでインデックスを削除する

TOKMSP の方の、LF に続いて作成したインデックスを削除して、もう一回実行してみましょう。

インデックスを削除してしまうと LF が使用されるようになります。
索引のサイズや索引のページ・サイズが LF のものになっているのがわかりますね。

先にインデックスを作成したケースでのオプティマイザーによって検討されたインデックスは

TOKMSP2 の方を見てみましょう。
暗黙的にアクセスパスが共用されているためか「最適化された索引のリスト」には LF はインデックスとしてリストされていません。

先にインデックスを作成したケースでインデックスを削除する

では、インデックスを削除するとどうなるでしょうか。

LF が使用されるようになりますが、「索引のサイズ」や「索引のページ・サイズ」はアクセス・パスを共用していたインデックスと同じままになっています。
「最適化された索引のリスト」には LF の名前がちゃんとリストされるようになりましたね。

[Top Pageに戻る]

Ads by TOK2