ケント・ミリガン著

iSeriesの統合データベースであるDB2 UDB for iSeriesでは使いやすさが重視されており、そのおかげでiSeriesとAS/400をご使用のお客様を長きに渡って惹きつけて止みません。分散型ソリューションやSQLの使用形態が普及しているのを背景にiSeries用アプリケーションが近年急速にその複雑さを増しており、それにしたがってi5/OS上のDB2 UDBの使用と管理を容易にするためのツールや機能を求める声も高まっています。本稿をお読みいただけるとおわかりになると思いますが、V5R4にはDB2 UDB for iSeriesがプログラマ、分析担当者、また管理者にとっても簡単で使いやすいデータベースであり続けるためのたくさんの新機能が盛り込まれています。

パフォーマンス・チューニングの簡素化
iSeries Navigatorのデータベース・コンポーネントでは新しいツールが追加されたり既存のツールが簡素化されたりしており、V5R4におけるDB2 UDBの簡素化の目玉となっています。こうした新しいツール群はDB2 OnDemandパフォーマンス・センターと呼ばれています。

システム全体で利用できるインデックス・アドバイザもV5R4で登場した新しいツールの1つです。DB2 UD2のクエリ・オプティマイザが出すインデックス・アドバイスは目新しいものではありません。従来のリリースでは、推奨インデックに関するフィードバックはジョブのログかデータベース監視コレクション中のオプティマイザ・デバッグ・メッセージの中にありました。しかしこのフィードバックはデータベース・モニタを誰かが手動で起動したか、デバッグ・メッセージングを起動した場合しか利用できませんでした。したがって分析担当者はさまざまなジョブのログやデータベース監視ファイルのアドバイス・インデックスの詳細を抽出するという複雑な作業を行わなければなりませんでした。今回新しくなったインデックス・アドバイザではこうした煩雑さが解消され、作業がマウス・クリック1回で済むようになりました。クエリ・オプティマイザがすべてのクエリに対するインデックス・アドバイスをV5R4のリポジトリにログとして自動的に記録してくれるので、データベース・モニタの起動などといったユーザーの手を煩わせるような操作は一切不要です。iSeries Navigatorのツリー上でデータベース名を右クリックしてインデックス・アドバイザ・タスクを選択してください。図1のような表示が出てくるはずです。

さらに素晴らしいことにV5R4ではSQLクエリ・エンジン（SQE）のクエリ・オプティマイザが提供するインデックス・アドバイスがよりインテリジェントで完成度の高いものになっています。[フィードバックは素晴らしい]
（ホームページ、iSeries技術解説 4月号
http://www.e-bellnet.com/special/tec/tec_0604.html）でもご紹介したように、過去のリリースのインデックス・アドバイスはクエリのフィルタリング基準に焦点を当てているだけで、ジョイン、グルーピング、オーダリングの基準については無視していました。ここでも、分析担当者がDB2のインデックス・アドバイスを取り出して関連するクエリをレビューし、DB2インデックス・アドバイスを補完するという作業を手作業で行わなければならない設計となっていました。

しかし、インデックス・アドバイザはインデックス・アドバイスを提供する際にインデックスを管理するコストを考慮していません。このアドバイスはクエリとSQLデータの取り出しを高速化することだけを目的としているからです。各ユーザーは新しいインデックスを作成してレポートを高速化することと、インデックスを管理するのに要するコストとのバランスを考慮しなければなりません。

インデックス・アドバイザの出力を注意深く見てみると、生成すべきインデックスのタイプについてのアドバイスをもオプティマイザが提供しているのがおわかりいただけるでしょう。従来の基数インデックスが有用であるようなクエリもあれば、符号化されたベクトル・インデックス構造のほうが有用であるというクエリもあります。（インデックス化の詳細についてはibm.com/servers/enable/site/education/ibo/view.html?wpに掲載されているインデックス化戦略に関する白書をご覧ください。）

常に稼動しているもう1つのツールとしてSQLプラン・キャッシュというツール群があります。SQLプラン・キャッシュは内部リポジトリで、SQEはこれを使用してサーバーで現在実行中のSQL文や最近実行したSQL文のアクセス・プランとそれに関連する統計情報を保存します。このプラン・キャッシュ分析ツール群を使用することの大きなメリットはデータベース・モニタを起動することによるオーバーヘッドを生じさせることなくSQLの詳細なパフォーマンス分析が行える点にあります。これは今まではできなかったことです。詳細なデータベース・モニタ・コレクションはディスク空間を急速に食いつぶし、ディスクの応答時間が目に見えて遅くなります。

SQLアプリケーションのパフォーマンスが悪いのでユーザーがヘルプ・デスクへ電話しても、データベース・モニタを起動してレポートかアプリケーションを再度実行してください、という回答しかもらえないというのはもう過去の話です。V5R4では、ユーザーがパフォーマンスの問題で問い合わせをしたら、SQLプラン・キャッシュの内容を即座に分析して、長時間実行されているSQL文がパフォーマンス上の問題の原因となっていないか調査することができます。SQLプラン・キャッシュ・ツールを使用するには、SQLプラン・キャッシュ・スナップショット・コンポーネントを右クリックして、[SQLプラン・キャッシュ] - [ステートメントの表示タスク]を選択するだけです。選択すると図2のようなダイアログが表示されます。

見逃して欲しくないプラン・キャッシュ・ビューワの機能の1つがダイアログの左側にあるステートメント・フィルタです。このフィルタを使用すると、何千というSQL文のランダムなリストの中をスクロールして探さなくても分析対象のSQL文をインテリジェントに小分けにすることができます。たとえば、最も頻繁に実行される文や最も時間のかかる上位10個の文を取り出すことができます。また、現在実行中のSQL文や特定のユーザーが実行しているSQL文だけを分析対象とすることもできます。 さらに、分析対象のSQL文を選択すれば、同じウィンドウからシームレスにビジュアル・エクスプレインを立ち上げてそのSQL文を分析することができます。

この新しいツールが皆さんの心を虜にし過ぎないうちにお断りしておきます。SQLプラン･キャッシュはSQEが処理するSQL文に対してのみ有効であるということを忘れないでください。SQEはV5R4で機能強化されたのですが、すべてのSQL文とクエリを処理する能力を備えているわけではありません。また、SQLプラン・キャッシュは固定長なので、しばらく実行されていないSQL文がキャッシュから削除されてしまう場合もあるということも覚えておいてください。こうした場合はデータベース・モニタ・ツールを使用する必要があります。

キャッシュの中身を永続オブジェクトにアーカイブしたい場合は、SQLプラン・キャッシュ・スナップショットを作成することができます。事実上、この操作によりSQLプラン・キャッシュの中身が詳細なモニタのコレクションと同様の出力ファイルに変換されます。スナップショットが生成されれば、データベース・モニタ・コレクションの場合と同様にレポート機能を実行して中身を分析することができます。

データベース・モニタは長年に渡ってiSeries用のDB2 UDBで利用可能でしたが、V5R4でプレフィルタやポストフィルタが追加されたことでその使い勝手は大きく改善されました。これらのフィルタはSQLプラン・キャッシュ・ビューワのフィルタと同様のものです。

データベース・モニタ・フィルタが重要であるとするにはいくつかの理由があります。まず、これらのフィルタはオーバーヘッドを最小化し、データベース・モニタ・コレクションが消費するディスク空間も最小化します。その好例として、最近あるお客様がシステム上のすべてのジョブに対してデータベース・モニタ・コレクションを15分間実行した事例があります。そのシステムではそのときSQLベースのERPアプリケーションが稼動しており、約300万行の詳細なモニタ・データが出力されました。たとえば、V5R4で利用可能になったフィルタを適用して特定のユーザーあるいは特定のテーブルを参照しているSQL文についてモニタ・データを収集するだけで、DB2 UDBが収集しなければならないデータの量を大幅に減らすことができます。

このフィルタはグラフィック・インタフェースまたはSTRDBMON CLコマンドで新しいSQLパフォーマンス・モニタ・コレクションを起動すれば利用可能になります。図3に示したフィルタは、実行中のジョブのうちジョブ名がQZDASで始まり（つまりQZDASOINIT）、PRODDBスキーマのBIGTABLEを参照しているジョブで実行されているSQLリクエストに対してだけモニタ・データを収集するようにDB2 UDBに対して指示しています。

データベース・モニタ・コレクションのサイズを小さくすることのもう1つの利点は、300万行のモニタ・データを調べる代わりに3万行のモニタ・レコードを調べれば済むので、SQLのパフォーマンスを分析してボトルネックを突き止めることが今までよりもすばやく簡単に行えるようになったことです。ポストフィルタ（図4）もデータをすばやく小分けにしてDB2のパフォーマンス・ボトルネックを見つけるのを容易にするために利用可能になったのもこうした理由によるものです。ポストフィルタにアクセスするには、モニタ・コレクションを右クリックして[ステートメントの表示]タスクを選択します。

SQLパフォーマンス・モニタ分析機能もV5R4で大幅に改善されました。この機能はモニタ・コレクション中の主要な指標をまとめて表示する機能と、パフォーマンスの分析を特定の文に絞り込む際にレポートを深く掘り下げる機能を提供しています。SQLプラン・キャッシュの場合と同様に、分析対象のSQL文を絞り込めれば、ビジュアル・エクスプレインを簡単に起動できます。従来のリリースでは、モニタ分析機能を手動で終了させ、分析対象のSQL文を別のインタフェースから探し出して、そのSQLリクエストに対してビジュアル・エクスプレイン図を表示させなければなりませんでした。また、2つのモニタ・コレクションを比較して1つのアプリケーションが異なるSQLリクエストを実行しているのか、DB2クエリ・オプティマイザが異なる実装を選択しているのかを判断するための新しいモニタ比較ツールも加わっています。

iSeries Navigatorに加わった機能で注目したい機能の最後としてDB2ヘルス・センターがあります。ヘルス・センターを使用すると、テーブル中の最大行数やインデックス・オブジェクトの最大サイズなどといったDB2 UDBのさまざまな制限に対してデータベース・オブジェクトがどの程度使用しているかを監視、チェックすることができます。さらに、DB2オブジェクトが制限値に近づいたので検査結果を永続ファイルに保存して過去の履歴と比較できるようにするための閾値を変更することもできます。この機能を起動するには、名前付きデータベースを右クリックして[ヘルス・センター・タスク]を選択してください。このヘルス・センターにはDB2の分析機能が今後も追加されていきます。

SQL簡素化のための機能追加
プログラミング言語に新しい機能を追加すると開発者にとっては複雑度が増すのではという懸念がありますが、問題解決のためのツールが増えるという意味では開発作業が容易になるのが一般的です。DB2 UDB for iSeriesは、業界標準のSQLをサポートすることでSQLプログラミングを簡素化しようとしており、他のデータベース製品からスキルや知識を容易に移管できるようにしています。

V5R4で、DB2 UDB for iSeriesは最新の標準である2003 SQL標準のコアレベルに準拠した最初の主要なデータベース製品となりました。SQL標準のシンタックス・フラガを追加し、サブクエリとスカラー・フルセレクトをサポートしたことで2003 SQL標準への準拠が完了しました。

フルセレクトはSQL用語で、複数のSelect文をUnion、Intersect、Except集合演算子で結合したものです。フルセレクトはかなり前のリリースからサポートされていますが、以前のリリースではサブクエリやスカラー・サブセレクトでは使用できませんでした。新しくサポートされたスカラー・フルセレクトをSQL文で使用した例を図5に示します。

この例では、あなたの会社の取引先があるすべての国の為替レートのテーブルがあります（Union演算子により1行以下の列からなる結果セットが生成されます）。あなたの会社では毎日ヨーロッパ各国の最新の為替レートをある情報源から受け取り、別の情報源からはアジア諸国の為替レートを受け取ります。これらの情報源は重複していません。V5R4では、両情報資源をUnion節で結合することにより1つのSQL Update文で為替レートを更新することができます。従来のリリースでは、為替レートの更新には2つの別々のUpdate文が必要でした。Select、Insert、Update、Delete文でSQL式（たとえばcol1 + 100）が使用できるところであればどこでもスカラー・フルセレクトを使用することができます。

新しいマルチカラム・プレディケイトがサポートされているのでサブクエリのコーディングも簡単です。下記に示す例で、INプレディケイトを使用して2つのカラムをどのように比較しているかを見てください。この例では、クエリの結果として所属部署のオフィスがある街と同じ街に住んでいる従業員が得られます。

SELECT empno,lastname FROM employee
　 WHERE (workdept, emp_city) IN
　　 (SELECT deptno, deptloc FROM department)

DB2 UDB for iSeriesに格納されているデータの暗号化は多くのお客様が解決しようとしている共通のビジネス課題です。V5R4には新しい組み込み型の暗号化関数ENCRYPT_TDESがあり、V5R3で実装されたENCRYPT_RC2機能を補完しています。この新しい暗号化関数を使用すると、SQLプログラマが機密度の高いデータを三重のDES暗号化アルゴリズムで保護することができます。

V5R4で加わったその他の新しいSQL関数としては、Last_Day、Next_Day、Varchar_Format、AddMonthsなどがあり、日付や時間の値を処理するのに便利です。

Raise_Error関数を使用すると、特別な計算や検知条件に基づいてSQL文から例外をシグナル通知して、予期せぬイベントが発生したことをアプリケーションに警告として知らせることができます。たとえば図6中のクエリは、Select文の実行中に不正なjob_typeを検知すると処理を終了してSQL STATE 70001をシグナル通知します。

Raise_Error関数はSignal文と同じようなエラー・レポート機能を備えていますが、Signal文を使用するのはSQLリクエストが完了した後のエラー条件をレポートする場合に限ります。Raise_Error関数はSelect、Insert、Update、Delete文の実行中に発生したエラーを知らせるユニークな機能を提供します。

GENERATE_UNIQUEは新しいSQL関数で、ご想像通り13バイトの長さからなるビット・データの文字列形式でユニークな値を返します。生成された文字列にはタイムスタンプ値が含まれているため、2回目以降の戻り値はそれ以前の呼び出しの戻り値よりも大きな値になります。この関数は、エンド・ユーザーが理解できるような値である必要はないユニークな識別子を内部処理用に必要とするアプリケーションで使用すると便利です。

オブジェクトとタイプの改善
V5R4では新しいSQLオブジェクトやデータ・タイプは追加されていませんが、既存のSQLサポートに改善を施したことで多少の変化があります。Timestampデータ・タイプは決して新しいデータ・タイプではありませんが、タイムスタンプ・カラムのタイムスタンプ値をANSフォーマット（たとえば、2005-04-20 05:01:33）で初めて保存することができるようになりました。以前のリリースではアプリケーションを他のデータベースに移植する際によくこの制約に悩まされていました。

SQLビュー用の新しいタイプのトリガとしてV5R3のリリース後にInstead Ofトリガが導入されました。しかしこのトリガのサポートはPTFでのリリースに追加されたものであったためいくつかの制限がありました。V5R4ではこれらの制限が取り除かれ、SQL開発者はInstead Ofトリガをより多くの状況で使用できるようになりました。たとえば、ジョインを含んだSQLビューに対してInstead Ofトリガを作成できるようになりました。これはV5R3ではできませんでした。図7に示す例はempdeptビューのアップデート可能なジョインのサポートをInstead Ofトリガがどのように提供しているのかを示しています。

図7のempdept SQLビューが以下のようなSQLリクエストでアップデートされると、ビューが読み取り専用であるというエラーがシグナル通知される代わりに、DB2 UDBはUpdate-Joinトリガを呼び出します。

UPDATE empdept SET lastname='SMITH'
　 WHERE empno = 55

このトリガは、その元になっているビューでジョインされている従業員と部署の2つのテーブルに対してアップデートを2つの別々のUpdate文に分解します。

揮発テーブルも既存のSQLオブジェクト・タイプから派生したものです。Volatileは通常のSQLテーブルを作成する際に指定することのできる属性です。揮発テーブルといってもDB2 UDBがテーブル中の列を任意の時点で揮発させたり消滅させたりできるというわけではありません。むしろその反対で、このキーワードはDB2 UDBクエリ・オプティマイザにとっては、実行時の行数が大幅に変わること、オプティマイザはそのテーブル・サイズに関係なく比較的パフォーマンス良く実行できるアクセス方法を使用しなければならないということを意味します。クエリ・オプティマイザがクエリを参照するときにこのテーブルに対してインデックス・スキャンを実行してしまおうという傾向になりがちです。バッチ・プロセス中にデータが頻繁に入れられてはクリアされるような作業テーブルはこの新しいキーワードを使用する良い候補でしょう。

CREATE TABLE worktable
　 (id INT,
　　 name CHAR(10),
　　 current_total DECIMAL(12,2))
　 VOLATILE

SQLプログラミングの簡素化
今までは揮発という語は最新のRPG機能と組み込みSQLを統合した環境を指す言葉でした。これは、SQLのプリ・コンパイラがRPG言語の進歩についていけなかったためです。RPG SQLのプリ・コンパイラに大幅な改善がなされ、この問題が解決しました。その改善はV5R4においても継続され、フリー・フォームのRPGでSQLを統合して使用することができるようになりました（図8）。

当然のことですが、JDBCや.NETのプログラマもより高いレベルを求めているので、IBMはそれに応じてV5R4で関連するミドルウェアをアップデートして、最新の業界標準に準拠するようにしました。さらに、iSeries Access for Windows .NETプロバイダに加えられたiSeries用のカスタマイズによりシステム・ネーミングやライブラリ・リストの使用がサポートされただけでなく、大型オブジェクト（LOB）カラムのサポートも可能になりました（この2つの機能強化はV5R3でも利用可能です）。DB2 Connect Unlimited Edition for iSeriesが最近登場したため、DB2 UDB for iSeriesでデータを処理して保存したい.NET開発者にとってはこれまで以上にMicrosoft Visual Studio用のDB2プラグインが使いやすくなりました。SQL CLIやネイティブJDBCドライバーなどといった動的SQLインタフェースを使用してi5/OSで稼動しているアプリケーションもSQLデスクリプタ・エリアのIBMサポート部分の内部設計を見直したおかげでパフォーマンスが飛躍的に向上しました。

SQLプログラマはカラム名のサイズが30バイトから128バイトに増えたために記述性が高くなりました。またV5R4でもインデックス・キーの最大サイズが32Kに拡張されました。

ストアード・プロシージャを使用しているアプリケーションもV5R4で拡張された制限値の恩恵を受けています。ストアード・プロシージャではパラメータの制限が256個から1,024個に拡張され柔軟性が高まりました。さらに、1つのSQL文で1,000個のテーブルまで参照でき、SQL文の最大サイズも64Kから2MBへと劇的に拡張されました。文の長さを長くしすぎではないかと思われる方が多いかもしれませんが、SQLストアード・プロシージャは1つのCreate Procedure文で定義されるのでとても長くなることがあるということを思い出してください。SQLストアード・プロシージャではビジネス・ロジックをコーディングするのに使用されているすべてのSQL文がCreate Procedures文の長さとしてカウントされます。SQL関数やトリガもこの新しい最大長の恩恵を受けています。

Alter Procedure文もSQLプロシージャの開発と保守を簡素化する機能強化の1つです。この新しい文を使用することで既存のプロシージャを一旦削除したりプロシージャ・オブジェクトの所有権や特権をリセットしたりすることなく、そのプロシージャの属性やロジックをすばやく変更できます。以下に示すAlter Procedure文はLevelIncreaseロジックを変更して元のプロシージャにある5%の昇給ではなく10%の昇給を認可しています。

ALTER PROCEDURE LevelIncrease
REPLACE
BEGIN
　　　 DECLARE CurLvl INT;
　　　 SELECT edlevel INTO CurLvl FROM emptbl
　　　　　 WHERE empno=Emp#;

　　　 IF NwLvl > CurLvl THEN
　　　　　 UPDATE emptbl
　　　　　　　 SET edlevel=NwLvl,
　　　　　　　　　　 salary=salary + (salary*0.10)
　　　　　　　 WHERE empno=Emp#;
　　　　　 END IF;
　　　　 END

SQL高速化への近道
V5R4でのパフォーマンスの改善はSQLストアード・プロシージャにとっての仕上げの一筆です。ご存知かも知れませんが、SQLプロシージャ・オブジェクトが作成される際にDB2 UDBエンジンはSQLが組み込まれたCのソース・コードを生成してSQLで定義されたビジネス・ロジックを実装します。V5R4ではSQLプロシージャ言語用のDB2 UDB Cコード生成エンジンに対しても大幅な変更が加えられています。当然のことながら、改善の度合いはシステムによって異なりますが、研究室での実験によれば30%のパフォーマンス向上が得られたというテスト結果もあります。V5R4での機能強化の恩恵を受けるには、すべてのSQLプロシージャ、トリガ、関数を再生成する必要があります。

SQLクエリ・エンジンはiSeriesでSQLのパフォーマンスをさらに次のレベルに向上させようというIBMの重要な戦略の1つです。LIKE節があるSQLリクエストやLOBカラムを処理しているSQLリクエストをSQEが新たに実行できるようになったことで、V5R4におけるSQL実行の負荷がその恩恵に授かっています。

V5R4におけるSQEのもう1つの機能強化としてSQEクエリ・オプティマイザの「インテリジェンス」の追加があります。この機能強化により、自動インデックス（AI）として知られているインデックスの自動生成のパフォーマンスが向上しました。オプティマイザはバックグラウンドで待機しており、生成されるインデックスから恩恵を受けることのできる頻繁に実行されるクエリを探しています。そのようなクエリを見つけたら、DB2 UDBは一時的なインデックスとしてAIを生成します。DB2 UDBは、この一時インデックスの元になっているテーブル・データが永続的なSQLインデックスの場合と同様に更新されるため、この一時インデックスを維持します。しかしAIはシステムの電源が切断されたときに消滅します。

SQEがSQL文を実行しないようにするためのV5R4における最も一般的な項目と環境は以下の通りです。

　 ・ Upper、Lower、Translate関数

　 ・ 各国語ソート・シーケンス

　 ・ ユーザー定義テーブル関数（UDTF）

　 ・ FROM節における論理ファイル参照

　 ・ テーブルで定義されているセレクト/オミット論理ファイル

　 ・ 非SQLインタフェース（たとえばOPNQRY、Query/400） − SQLはiSeries
　　 データ・アクセスや業界標準にとって戦略的なインタフェースであるため、
　　 非SQLインタフェースはSQLクエリ・エンジンにとっては優先度が非常に
　　 低くなっており、近い将来SQEはSQLベースのインタフェースだけを
　　 サポートするようになるでしょう。

上記のリストは大変重要なものです。というのも前述した通りSQEがSQL文を実行させる場合に限って利用可能なツール（たとえばSQLプラン・キャッシュ）や機能があるからです。次に示すように、SQL文がSQEによって実行されるとわかっている場合にのみ使用できるSQLシンタックスもはじめて登場しています。

　 ・ スカラー・フルセレクト

　 ・ 再帰共通テーブル式

　 ・ OLAP式 −RowNumber、Rank、DenseRank

　 ・ IntersectおよびExcept集合演算子

マテリアライズ・クエリ・テーブル（MQT）はSQEだけが使用できるもう1つの機能です。Instead Ofトリガと同様にMQTはV5R3の発売後にPTFで導入され、V5R4でその機能が強化されました。MQTはクエリの定義とクエリの結果を含んだDB2のテーブルです。MQTはAIと同様にSQEで使用することができ、クエリのパフォーマンスを自動的に向上させます。SQLクエリが実行されるとき、SQEクエリ・オプティマイザは実行されるクエリにマッチするかあるいは部分的にマッチするMQTがシステム上にないかをチェックします。マッチするあるいは部分的にマッチするものがあることをクエリ・オプティマイザが検知するとクエリを書き直してMQTの中身をショートカットとして使用し、クエリの結果の配信を高速化します。MQTはデータ・ウェアハウスやビジネス・インテリジェンス環境で最も効果を発揮します。（MQTの詳細についてはibm.com/servers/enable/site/education/ibo/view.html?wpにある白書をご覧ください。）

簡単なDBAの使い方
本稿の初めの部分では管理者や分析担当者がデータベースのパフォーマンスをチューニングしたり管理したりするのを容易にするための新しいグラフィックなツールについて焦点を当てていました。V5R4では、DB2がシステム資源をより上手に管理できるようにするためのグラフィックではない機能も追加されています。 DB2 UDB for iSeriesはV3R1以後、Change Query Attributes（CHGQRYA）コマンドで実行時間に基づいた予測クエリ・ガバナ機能を備えています。クエリの実行時間が定義されている制限時間を超えそうだとクエリ・オプティマイザが予測した場合、管理者は長時間にわたって実行されるクエリがシステムを一定時間以上占有するの止めさせることができます。場当たり的なクエリを実行するユーザーがいる場合には大変便利な機能です。

場当たり的なクエリが引き起こすもう1つの問題は、データベースが正しいインデックスで適切にチューニングされていない場合、クエリ・オプティマイザはハッシュ・テーブルなどの一時オブジェクトを作成してクエリの実行を促進しなければならないということです。サーバーに十分なメモリと一時記憶装置が搭載されていればクエリの実行中に大量のメモリを消費する場当たり的なクエリにも耐えられます。しかし、このような場当たり的なクエリが複数個並列で実行されるような場合は、応答時間についてユーザーからすぐに不満が出てくるでしょう。したがってV5R4ではSTORAGE_LIMIT QAQQINIオプションまたはCHGQRYAコマンドのQuery Storage Limitパラメータによって一時記憶ガバナを追加し、システム資源をむさぼり食う場当たり的なクエリを制御するもう1つの方法が提供されています。クエリ・オプティマイザは時間制限と同様でクエリの実行中に一時オブジェクトが使用する空間サイズも予測します。記憶空間のサイズがユーザーごとに定義されているサイズを超えると予想される場合、クエリの実行を中止することができます。

ガバナ記憶や時間制限を超えたときのワークフローを自動化するために、V5R4のクエリ・ガバナでは新しい出口ポイントが設けられました。QIBM_QQQ_QUERY_GOVR出口ポイントがそれで、制限を超えたことをガバナが検知するとプログラムを呼び出します。呼び出されたプログラムは管理者に通知するか、または定義された制限値を超えたユーザーを記録することができます。

システムのクロス・リファレンス・ファイルの回復性が改善されたこともシステム管理者にとっては嬉しいことです。この改善によりクロス・リファレンス・ファイルの回復の際に行わなければならない再要求操作の数が減りました。さらに、DB2 UDBがクロス・リファレンス・ファイルを再構築する際に、そのクロス・リファレンス・ファイルに依存していたQSYS2スキーマとSYSIBMスキーマのSQLカタログ・ビューを再生成するタスクも起動します。

SQLで作成されたオブジェクトをあるスキーマから別のスキーマへ、あるいはあるシステムから別のシステムに移動するのはこれまでは大変な問題でした。このような状況においてはSQLで作成されたテーブルのジャーナル環境をリストア操作またはCreate Duplicate Object（CRTDUPOBJ）操作の後に再構成しなければならないという課題がありました。しかしV5R4では、システム管理者やデータベース管理者がQDFTJRNデータ・エリアをライブラリに追加してDB2 UDBがジャーナル構成を自動的にリセットできるようになりました。

毎日をシンプルに過ごす
OnDemandパフォーマンス・ツールセットから強力なプログラミングへの機能強化にいたるまで、V5R4はDB2 UDB for iSeriesが業界におけるデータベースの使い勝手の良さの基準を定めることができるようにしています。DB2 UDB for iSeriesを使用することでiSeriesの管理者やプログラマが間違いなくシンプルな毎日を過ごすことができるようになるでしょう。

ケント・ミリガン氏はIBMのSystem i5のISV支援チームのDB2 UDB of iSeriesのテクノロジ・スペシャリストです。同氏はIBM入社後の最初の8年間をロチェスターにあるDB2開発グループのメンバーとして勤務しました。同氏はリレーショナル・データベースに関して定期的に講演を行ったり執筆したりしています。