DB2/400 には予測照会管理プログラム (Predictive Query Governor) と呼ばれる、データベースエンジンのオプティマイザーという機能による見積もり実行時間を実行前にチェックして、時間のかかりすぎる SQL に対して事前に処置することができるようになっています。
オプティマイザーが事前に SQL の実行計画 (アクセス･プラン) を決定することはこちらの記事で見ました。
このアクセス･プランには、実行するとどのくらい時間がかかるだろうかという見積もりが含まれます。PRTSQLINF
コマンドで見たアクセス･プラン情報の中に「見積 QUERY 実行時間は xx 秒である」という記述が実際にあるのがわかります。
この「見積 QUERY 実行時間」と、事前に決めておいた処理時間の閾値をチェックして、超えていた場合に処置(事前に停止させる/メッセージを処理することによって実行させる)を行うことができるようになっているわけです。
設定自体は至って簡単です。
システム値 QQRYTIMLMT、QAQQINI の QUERY_TIME_LIMIT、CHGQRYA コマンドの
QRYTIMLMT パラメータのいずれかで、どこまでが「かかりすぎる」時間かを設定できます。
たとえば JDBC アクセスなどの場合、プロパティなどでどのライブラリーの QAQQINI
を使うかの指定ができますので QAQQINI での設定がリーズナブルでしょうし、ユーザーで制御したい場合は初期プログラムに
CHGQRYA コマンドを入れておくことも可能でしょう。
それぞれの関係ですが、より個別の設定が有効になります。つまり、システム値
→ QAQQINI → CHGQRYA の順に、右に行くほど優先されるということです。
システム全体に適用するには、以下のようにシステム値 QQRYTIMLMT を変更します。
以下のように 1 と設定すると、 1秒以上かかる照会はすべて「時間のかかりすぎる」ものとなるわけです。
たとえば、こんな風に事前に実行がストップされるわけです。
(ちなみに、以下のメッセージで表示されている見積もり実行時間が上の例と異なっているのは、実行しているマシンが実は違うからなのであまり気にしないでください)
閾値となる時間は、ジョブ毎に変更することもできます。
以下のように CHGQRYA コマンドを実行すると、そのセッションだけで有効になります。
こうしたプログラムでの実行の場合、静的 SQL の場合でも動的 SQL の場合でも、以下のようなメッセージが出てきます。
(もちろんシステム応答リストを使えば自動応答も可能です)
今回は STRSQL 画面による動的 SQL の例にとりました。
同じ SQL を二回実行していますが、最初の実行では C で答えているため実行されず、二回目の実行では
I で答えているため実行されていることが確認できますね。
0 にセットすると実行されないことになります。
その場合でも、アクセス･プランの作成を含む最適化は行われます。これを利用して
SQL が新規で作成された場合に実際に実行しないで最適化を事前に行っておくことができますね。
|
|