「Select/Omit を指定した論理ファイル」を「ビュー」と区別する

Select/Omit を指定した論理ファイルを SQL 文の FROM 句に指定すると、たいていの場合とってもパフォーマンスはよくありません。

FROM 句の論理ファイルを SQL オブジェクトであるビューに差し替えることで文字どおり桁が違って速くなることがあります。(知人の話ですが、数十秒が 0.以下になったことがあったそうです。つまり、二桁違うわけですね)

これには理由があります。


昔からの技術者に多いのですが、SQL オブジェクトである「ビュー」と Select/Omit 指定の論理ファイルを同じものだと思っていたりする困った人がけっこういます。が … 全然違うものなんです。

そもそも DDS で作成したものと SQL DDL で作成したものは、「TABLE と PF の違い (その2)」や「LF と INDEX の違い」で見るように、かなり違った動きをする、異なる "SQL オブジェクト"です。
わざわざ SQL ファイル・タイプなどという属性が増えていることからもわかりますね。

「論理ファイル」というのは、むかしむかしリレーショナル・データベースなんていうのが "夢の技術"だった時代 − ワークファイルによる"ソート"と"マージ"で業務処理をプログラミングするしかない時代に、その"ソート済みワークファイル"のイメージを実現するためにできたものなんです。

ソートしてできたワークファイル、というのがそのまま「論理ファイル」なんです。"論理的に存在するだけの仮想的なソート済みファイル"というようなかんじですね。

たとえば、あくまでオプティマイザーの判断の補助と実装の道具である「インデックス」とは用途・目的からして似て非なるものなんです。

ビュー/インデックスと論理ファイルの違い

SQL でいう「ビュー」と"ソート済みファイル"がどう違うのか、考えて見ましょう。

たとえば、ビューはあくまでカラムの選択/除外を行うのが目的であって、どういう順番で結果を並べるかは利用者にまかされているわけです。
降順に見たい場合だって昇順に見たい場合だってあるでしょう。

SQL の考え方では、 ORDER BY は最終の選択済み結果の表現の仕方にかかわるものです。

目的となる選択済み(や、グルーピング済み)の結果は通常それほど大きなデータ集合にはなりません。
その段階で、何らかの順序で見る必要があれば、メモリー上で効率よく高速にソートできます。

また、その選択結果、いろんな見方をしたい場合があるかもしれないですよね。
クライアント上で降順にしたり昇順にしたり、閾値で切ってみたりしたい場合は、クライアントに渡されてくる時点での順序などそもそもどうでもいいことになります。

また、ビューそのものもジョインの対象にできますよね。
そういうケースでは順序などは関係ありません。(トップ 10 とかワースト 10とかいうのは"条件"です)

だからビューには "ORDER BY" は含まれないんですね。あくまで SQL 文実行時の機能であるという位置づけです。

そもそもインデックスがキー順に並んでいるのは、「キー」をもって行/レコードを特定しやすくするためです。
並べることが目的ではありません。

並んだ実体が目的である「論理ファイル」とはそこが大きく違うんですね。

疎結合と密結合

「論理ファイル」は常時最新状態を保つように(通常は)なっているので、親の物理ファイルが更新されると即時に更新が行われます。
そのこと自体はインデックスも論理ファイルも同じことなのですが、インデックスはオプティマイザーを通してしか使用されないのに対して、論理ファイルは直接プログラムで読み込まれてしまいます。
さらに、インデックスはトランザクション制御の仕組みによって整合を保った状態で常に使用されるのですが、論理ファイルは(たいていのケースでは)ファイルとしての整合ではなく一レコード単位でプログラムによって使用されています。(そのため「「暗黙のアクセス・パス共有」でプログラムがループ?!」や「「暗黙のアクセス・パス共有」でデータがおかしい?!」のような問題が起きてしまうわけです)

インデックスというのは"疎結合"ですが、論理ファイルは"密結合"なわけです。今どきのソフトウェア工学のトレンドから言って趨勢は明らかですね。

さらに非効率な"Select/Omit を指定した論理ファイル"

その時代の S/38 の制約で、本来"順序"は関係ない"選択・除外"も「論理ファイル」として実装せざるを得ませんでした。

「論理ファイル」= ソートの代替物なので、並べ替えの機能ははずせません。
そのため、"Select/Omit の指定" に"ダミー"の「キー」が必要になっています。

サイズ

"Select/Omit を指定した論理ファイル"は↑で言ったように「論理ファイル」なので、並べ替えられた「実体」が存在します。
つまり、それなりのサイズになります。

同じ選択機能を実現するビューを作成してサイズを見てみてください。
ビューはテキストだけなので、"Select/Omit を指定した論理ファイル"とは比較にならないほどサイズは小さくなっています。

動的実行しても問題ないのにわざわざ親ファイルの更新に負荷

S/38 の時代とは、CPU/メモリー/ディスクアクセスなどのハードウェアはもとよりいろんなソフトウェア技術の進歩で、処理能力がまったく異なります。

S/38 の時代では、選択・除外は「論理ファイル」の並べ替えのどさくさで一緒にやってもらうしかなかったわけですが、今は全然違います。
きちんと SQL を書けば、その時代とは比較にならない速度と効率で返ってきます。

くだけた言い方をすれば、らくらく一括払いをできるのに、手数料のかかるマイクロローンを常に払い続けているような状態なんですね。
"一括払い"をするとどのくらいのレスポンスでどのくらいの負荷なのか、OPNQRYF でも SQL ででも一度試されてみるといいと思います。

非汎用性 - チリも積もれば -

インデックスであれば汎用的に使われるものですし、"Select/Omit" の機能を必要としない SQL の役にも立ちます。
"Select/Omit を指定した論理ファイル"は、その "Select/Omit"でそのキー順のものにしか使えない非汎用的なものです。

こういう論理ファイルは微妙に条件を変えてたくさん作られることがままあります。
論理ファイルというのは、たいていそのプログラム専用に近い形で作られます("Select/Omit を指定した論理ファイル"は特にその傾向が強いように思いますが)ので、チリも積もれば山、でたいていの場合、影響は小さくありません。

ついで

さらに、冒頭で言ったように、"Select/Omit を指定した論理ファイル"を SQL の FROM に指定して数百倍遅くする、などというのは、システム資源のムダづかいでしかありません。


いずれにせよ、まずどのくらい使われているかを調べてみるのが出発点です。

冒頭に言ったように、SQL オブジェクトであるビューを"Select/Omit を指定した論理ファイル"と同じものと考えている人がいた場合、「ビュー」を作っていたはずがその人の勝手なやり方で"Select/Omit を指定した論理ファイル"になってしまっている場合があり得ます。
本人は「ビュー」だと信じているので、聞いても正しい答えは出てきません。

PDM や DSPOBJD で見ても、同じ LF なのでわからない、、ということもあるでしょう。

そういう場合には DSPFD コマンドが使用できます。
↓のように、出力ファイルを利用するのが便利です。

DSPFD TYPE(*BASEATR) OUTPUT(*OUTFILE)

出力されたファイルを見てみましょう。

Select/Omit を指定した論理ファイル

Select/Omit を指定した論理ファイルの属性情報はは↓のようになります。

「選択/除外」にはもちろん "Y" が入っていますし、「SQL ファイルタイプ」には SQL オブジェクトではないので "0" が入っています。
また、「アクセス・パス」については存在するのでキー順であることを示す "K" が値として入っています。

ビュー

ビューの場合は↓のようになります。

「アクセス・パス」は存在していないので "A"(到着順)、 「SQL ファイル・タイプ」は View という SQL オブジェクトなので "V" が入っています。
当然、「選択/除外」は "N" ですね。

値の意味

それぞれの値ですが、

というのが内容になります。

対応

こうした情報を元に集計し、SQL にしか使われていないのに "Select/Omit を指定した論理ファイル" だったという場合は、ビューに書き換えることをおすすめします。
"Select/Omit" しかないので書き替えの仕方は言うまでもありませんね?! WHERE での = か <> に置き換えるだけのことです。

[Top Pageに戻る]

Ads by TOK2