System iを愛するすべての人のためのコミュニティサイト

SELECT/OMIT の論理ファイルがくっついているだけで SQL が遅くなってしまうって、ご存知でしたか?!

SELECT/OMIT の論理ファイルが存在すると、
WHERE 句なしの SELECT * などという単純な SQL でさえ
最新式のデータベースエンジン（SQE と呼ばれます）ではなく、
S/38 以来の旧式のエンジン(今ではCQE と呼ばれています)に再ルートされてしまいます。

CQE で動いている、ということは Visual Explain というツールを使うとわかります。
CQE の場合、↓ のような項目が確認できます。

SQE で動いている場合は ↓ のように表示されます。

では、SELECT/OMIT の論理ファイルがくっついたテーブルについて
↓ のような単純な SQL を実行させてみて、どうなるか見てみましょう。（以下 V5R4 のマシンでの実行結果です）

SELECT * FROM JUMIDP;

まず、SQE で実行させた実行結果です。
（どうやって実行させるかは後ほど。もちろん SELECT/OMIT の論理ファイルを削除しても SQE になります）

CQE での実行結果です。
（V5R4 以前で普通に実行させればそうなります）

最適化時間はこちらの方が 2 ミリ秒ほど少ないのですが、この時間はこれ以降キャッシュされるので複数回実行される場合は二回目からはかからない時間になります。
その最適化時間を足したとしても CQE は 34(1+12+21) ミリ秒ですね。

SQE の 11(3+8) ミリ秒より大幅に遅いことがわかります。（3倍近く遅いわけです。。）

SQE というのは V5R2 から新しく登場したデータベース・エンジンです。

現在必要になってきている大量のデータベース処理、複雑な SQL を見据え、
現在のテクノロジの利用、今後の新機能への迅速な対応や品質の安定化のために、
あらためてオブジェクト指向設計で設計し直したデータベース・エンジンになっています。

CQE というのは、今までの S/38 以来のデータベース・エンジンのことを指します。

もともと S/38 や AS/400 ではいいところメモリが数～数十 MB でディスクが数 GB もあればかなり潤沢でしたよね?!
そういうシステム用に作られた/チューニングされたデータベースエンジンが CQE なわけです。

現在のような状況では逆にもう効率が悪くなってしまっている（たとえば、豊富にあるメモリを有効に利用できない、とか）ということはじゅうぶん考えられます。
（ですので、テスト用にちょこっと作った数件～数十件しかないテーブル、などにさらに単純な SQL を流しただけ、なんて状況では差が出ない/ CQE の方が速いということはあるかもしれません。
ただ、通常業務で使われるような状況では大半のケースで SQE の方が速いと考えていいでしょうね。）

SELECT/OMIT の論理ファイルがくっついているだけで こんな単純な SQL でさえ実行時間がのびてしまう（3 倍にも!!）、ということが起こってしまうんです。

が、それを避けるための方法がいくつかあります。

前回ご紹介したように、OPNQRYF などを使って SELECT/OMIT の論理ファイルをなくしてしまうのが一番いいのですが、
そのための期間もあるでしょうし、回避するための設定は存在します。（V5R3 あるいはそのための PTF 適用後の V5R2 以降）

QAQQINI というデータベースの挙動を設定するためのテーブルがあるのですが、
そこで IGNORE_DERIVED_INDEX という環境変数について *YES と設定することで、
SELECT/OMIT の論理ファイルがくっついているテーブルでも CQE にルートされないようにする、ということができます。

V6R1 からはそれがデフォルトになっていますので、V5R4 を使用されている場合は変えてみた方がいいかもしれませんね!?

とにかく、ただ SELECT/OMIT の論理ファイルがついている、というだけで、
普通の SQL も遅くなってしまったり、そのために余計なシステム資源を浪費してしまったりする、ということがあります。
ダイエットしてみると新たな世界が開けるかもしれませんよ!?

パフォーマンス、損していませんか?!