DB2 Web Query パフォーマンス改善のツボ！
今回のインターネット・セミナーでは、IBM DB2 Web Query for i（以下、DB2 Web Query）のパ フォーマンスを取り上げます。DB2 Web Query は、Query for iSeries（Query/400）の後継製品と 言いながらも、5250 インターフェースから Web インターフェースと進化し、Excel や PDF などの多 様な出力形式、ドリルダウンレポートやグラフ作成、OLAP 分析、ダッシュボード作成など、 Business Intelligence（以下、BI）ツールとしての機能を多数兼ね備えています。これらの機能を パフォーマンス良く利用するには、従来あまり意識することの少なかったいくつかの点を、考慮し なければなりません。 当セミナーでは、DB2 Web Query のパフォーマンス改善のツボとして、「パフォーマンスアップの ために考慮すべき 3 つのポイント」と「データベース・インデックス作成によるパフォーマンス向上」 を解説します。簡単な確認・作業で大きなパフォーマンス向上につながることがありますので、ぜ ひご一読ください。 なお、今回の内容は、DB2 Web Query の基本的な内容を理解している中級レベルの情報を一部 含んでいます。DB2 Web Query をご存じない方、あまり使用したことがない方は、まず下記の 「DB2 Web Query をご存知ない方は」をご参照ください。
DB2 Web Query をご存知ない方は
DB2 Web Query は、IBM i で稼働するデータ活用支援ツールです。オプション製品などを活用す ることで BI 環境を実現します。2008 年 2 月 8 日に V1R1M0、2009 年 3 月 21 日に V1R1M1、 2010 年 12 月 10 日に V1R1M2 がそれぞれ登場しています。 なお、DB2 Web Query は、このインターネット・セミナーでも過去に 3 回取り上げていますので、ま だお読みでない方は、はじめに以下のインターネット・セミナーをご覧ください。実際のイメージが 掴めるように「デモ動画」も下記リンク内に掲載しています。また、「DB2 Web Query ポータルサ イト」には関連する情報を集約しています。当セミナー情報の最下部「参考情報」をご覧ください。
第 2 弾：DB2 Web Query 1.1.2 新機能 解説：インフォアシストを利用したレポート作成 第 3 弾：DB2 Web Query 徹底活用：シノニムを使ってレポート生産性を向上！
DB2 Web Query パフォーマンスアップのために考慮すべき 4 つのポイント
パフォーマンスに影響を及ぼす主な要素には、「システム環境」「シノニムの作成方法」「レポート の作成方法」「インデックス作成」の 4 点があります。当セミナーでは、「どうすれば良いのか」に フォーカスして説明します。具体的なメカニズムや実装方法の詳細を知りたい方は、個別に紹介し ている Redbooks などの情報をご参照ください。 1.システム資源の確認ポイント DB2 Web Query の一般的な稼働要件は、2300CPW 以上、メモリー4GB 以上とされています。 必要なシステム資源を満たさない場合には、DB2 Web Query のパフォーマンスだけなく、既存の アプリケーションなどに影響を及ぼす恐れもあるため、ご注意ください。 また、「同時に使用するユーザー数」や「照会対象の DB サイズ」などの情報から、サイジング（必 要となるハードウェアスペックの見積）を実施できます。サイジングをご希望の際には、営業担当 者までご相談ください。 2.シノニム作成方法のツボ DB2 Web Query で利用するテーブル（物理ファイル）やビュー（論理ファイル）などの情報がまと められているファイルの名称です。シノニムについて学習したい場合には、前述の「インターネッ ト・セミナー：DB2 Web Query 徹底活用：シノニムを使ってレポート生産性を向上！」をご参照くだ さい。 シノニムを作成する時のポイントは『【DB2 CLI アダプター】を利用して、【テーブル（物理ファイ ル）】もしくは【ビュー】から作成すること』です。「他のアダプター（DB2 Heritatge アダプターや Query/400 アダプター）」や、「論理ファイル」を使用することは、パフォーマンスの観点から推奨し ていません。まずアダプターについて説明します。DB2 for i 用のアダプターは、下表のように全部で 3 種類用 意されています。「DB2 CLI アダプター」を利用して作成したシノニムは、SQL 照会エンジン （SQE）を利用し、DB2 for i の最新の機能拡張を最大限に活用できます。それに対して、「DB2 Heritage アダプター」や「Query/400 アダプター」を利用して作成したシノニムは、機能拡張がなさ れていない、旧来からある Classic Query Engine（CQE）を利用するため、相対的にパフォーマン スが良好でない傾向にあります。 一例を挙げると、「Query/400 アダプター」を利用した際には、レスポンスに 3.2 秒程度かかってい たレポートが、「DB2 CLI アダプター」を用いて物理ファイルからシノニムを作成した際には、レス ポンスが 1.3 秒程度に短縮されたというベンチマーク結果が紹介されています。利用するアダプ ターがパフォーマンスにどの程度の影響を与えるかを詳しく知りたい方は、Redbooks p.489 以 降をご参照ください。 アダプター データ・タイプ マシンに送信され るコマンド 処理エンジン DB2 CLI 単一メンバーの物理ファイル別名、 MQT、ストアード・プロシージャー
CLI API SQE
DB2 Heritage 複数メンバーのファイル、複数レコー
ド形式のファイル
OPNQRYF CQE
Query/400 QRYDFN オブジェクト RUNQRY CQE
また、「論理ファイル」からシノニムを作成した場合も、CQE で実行されるケースが多くなるため、 「論理ファイル」を使用するのではなく「物理ファイル」もしくは「ビュー」を利用してください。 マルチメンバーファイルを照会する場合には、「DB2 Heritage アダプター」が利用できますが、 CQE を利用することになるため、パフォーマンスの観点から推奨していません。SQL の別名を利 用することで、「DB2 CLI アダプター」を利用したシノニム作成ができます。実際の作成方法を知 りたい方は、Redbooks p.58 をご参照ください。
RedBook：DB2 Web Query for i はじめに（13MB）
3.レポート作成のツボ
レポート作成にはいくつかのポイントがありますが、その中でもすぐにできるもの、もしくは効果の 大きいものをご紹介します。
3-1.レポート出力件数 レポートの出力件数は、レポート実行時間に大きく影響します。 一例をあげると、16 万件の売上データを、（極端な話ではありますが）16 万件そのまま一覧表示 させる場合、50 秒程度かかりました。次に、16 万件のうちに 7000 件程度に絞り込んで（例えばあ る地域の売上のみに限定して）表示させて場合、実行時間は 3 秒程度に短縮されます。さらに、 16 万件のデータを、全て合計した値を表示させる場合（結果的に 1 レコードだけ表示させた場合） は、1 秒以下で表示できました。この例から、クライアント側のレスポンスタイムに大きく影響する 要因が、最終的な出力結果のレコード数であることがわかります。 なぜこのような結果となるのでしょうか？ 理由は、サーバー側ではなく、クライアント PC 側にあり ます。仮に、PC 側に 16 万件の HTML 形式で一覧 表示させた場合、結果が出力される 1 分程度、 PC 側の CPU 使用率が、100%近くまで上昇します。ブラウザーが大量のデータを表示するため、 PC に急激な負荷がかかっています。そのため、大量のデータをクライアントに渡すのではなく、パ ラメーター（選択条件）を利用することで、絞られた出力結果をユーザーに返すよう、レポートを作 成ください。 3-2.Web ビューアの利用
どうしても大量のデータを表示させたい場合には、「Web ビューア」の利用を強くオススメします。 Web ビューアとは、一度に大量のデータを表示させるのではなく、サーバー側でレポート実行結 果を 50 件程度に分割し、PC 側にページ単位で渡し、表示させる DB2 Web Query の基本機能で す。 初めてレポートを作成するような際には、どの程度の出力件数が表示されるか、分からない場合 があります。そのような際に、うっかり数万件の出力結果を表示させるようなレポートを作成してし まうと、しばらく待ちが発生します。そのため、どの程度の出力件数が返ってくるかが分からない 場合などには、必ず「Web ビューア」にチェックを入れることをオススメします。 【インフォアシストでの設定画面】 【レポートアシスタントでの設定画面】 なお、意図せず大量の出力件数のレポートを実行してしまった際には、レポート実行のキャンセル が可能です。画面右上にある「リクエストの停止」をク リックすることで、実行中の SQL をキャンセ ルできます。ただし、「リクエストの停止」が機能するのは、あくまで SQL 実行段階のみとなります。 サーバー側での処理が終了し、クライアント側での処理に移ってしまった後には、「リクエストの停
止」を実行しても効果がありませんのでご注意ください。（お使いいただいている DB2 Web Query のバージョンによっては、この「リクエストの停止」がご利用いただけません。） 【リクエストの停止の方法】 3-3.レポートブローカーによるバッチ処理 レポートブローカーは、レポートを「バッチ処理」で実行する DB2 Web Query のオプション製品の 1 つです。レポートブローカーを利用することで、事前にスケジュールしたタイミングでレポートが実 行され、「メールでの自動 配信」や「DB2 Web Query のフォルダへの自動格納」が可能です。 例えば、1000 ページを越えるような PDF ファイルを出力する場合、その都度ブラウザーから PDF ファイルを要求すると、大きな待ち時間が生じてしまいます。そのような場合には、レポートブロー カーを利用して、例えば夜間バッチなどで大容量の PDF ファイルを作成することで、レポート実行 時の処理時間の大幅な短縮が実現します。また、パフォーマンス負荷の高いレポートをシステム 負荷の高くない時間帯に実行させることで、負荷分散にも役立ちます。 3-4.その他
上記以外にも、レポートで利用している一次項目が SQL に変換されない場合、データベース側で の処理が完結せずに、DB2 Web Query ジョブ内での計算処理が発生します。その場合、大きな オーバーヘッドが発生します。初級者向けの内容ではないため、当セミナーでの説明は割愛しま すが、レポート内で一次項目などを多用されている方は、見極め方や対処方法などの情報が Redboos p.452 に記載されていますので、ご確認ください。 4.データベース・インデックス作成によるパフォーマンス向上 DB2 Web Query のパフォーマンスを考える上で、データベース・インデックス（以下、インデック ス）作成は非常に重要です。「2．シノニム作成方法のツボ」でも説明していますが、DB2 Web Query でのレポート実行は、原則として SQL 処理となります。そして、SQL をパフォーマンス良く 利用するには、インデックスの作成が必要不可欠となります。「インデックスは難しそう」と感じるか もしれませんが、IBM i の OS に組み込まれた DB2 for i ならば難しくありません。ぜひ読み進め てください。 4-1.インデックスの必要性 はじめに、インデックスの作成がどの程度重要であるかデータを基に見てみましょう。このデータ からは、「2．シノニム作成方法のツボ」で解説した「CQE と SQE の違い」と「インデックスの重要 性」が確認できます。
「CQE と SQE の違い」として、Query/400 アダプターを利用して作成したレポートで 28 分程度か かった処理が、DB2 CLI アダプター経由で作成したレポートでは 8 分程度で完了していることが確 認できます。DB2 CLI アダプターを用いてシノニムを作成することで、1/3 以下の実行時間になっ ています。 さらに、「インデックスの重要性」を見てみましょう。適切なインデックスを作成したことで、8 分程度 かかっていた処理が 90 秒以内に短縮されています。さらに、2 回目以降の実行ではキャッシュの 効果もあり、1 秒以下にまで大幅に短縮しています。単に DB2 CLI アダプターを利用するだけでは なく、インデックスを併せて活用することで、DB2 Web Query は本来持っているパフォーマンスを 発揮できます。
インデックスは、テーブルの検索速度の向上や、データベースの統計情報として利用されることに より、パフォーマンス向上に貢献します。また、DB2 for i には、システムがインデックスを必要と 判断した場合、自動的に一時的なインデックス（一時インデックス）を作成する機能が備わってい ます。一時インデックス作成の際にはシステム資源が消費されるため、一時インデックスとして作 成されるインデックスを、あらかじめ作成しておくことで、システム資源の使用率を低減できます。 より詳細な情報を確認されたい方は、Redbooks p.475 をご参照ください。 なお、インデックスを作成すると、データの挿入、削除、更新時にインデックスをメンテナンスする オーバーヘッドが発生します。そのために、闇雲に一度に大量のインデックスを作成するのではな く、効果を確かめながらインデックスを作成することを推奨します。また、利用されていないような 不要なインデックスはいつでも削除できます。 シノニムの作成方法の違いによるパフォーマンス比較 処理内容 o 3 つのファイルをジョインして、計 600 万レコードを Read するレポート
CQE：Query/400 定義を DB2 Web Query に移行した際の処理時間 o 28 分
SQE：同様のレポートを DB2 Web Query CLI アダプターで作成した際の処理時間 o 8 分 SQE：さらにパフォーマンス分析を実行し適切なインデックスを作成した際の処理時間 o 初回実行：90 秒以内 o 2 回目以降：1 秒以下（SQE のキャッシュが有効なため） 4-2.インデックスの作成方法 次に、インデックスの作成方法をご紹介します。DB2 for i では、インデックス作成に下記の 2 つの 方法が用意されています。このうち下記の「2．システム（インデックス・アドバイザー）が推奨する 「推奨インデックス」」を利用できるため、DB2 for i では、高度なデータベースの知識がなくとも、 パフォーマンスアップに貢献するインデックスを作成できます。 【DB2 for i でのインデックスの作成指針】 1. 利用するアプリケーションに応じて必要と考えられるインデックスを予想して作成 2. システム（インデックス・アドバイザー）が推奨する「推奨インデックス」を基に作成※
※ DB2 for i では、OS が常にデータベース統計情報を自動収集しています。「インデックス・アド バイザー」と呼ばれる機能が、その統計情報を基に、インデックスが存在することで SQL の実行 に大きなパフォーマンス改善が予想されるインデックスを推奨します。この推奨されるインデックス を「推奨インデックス」といいま す。この機能は IBM i 5.4 以降で実装されています。 【インデックス・アドバイザーの利用方法】 インデックス・アドバイザーを利用したインデックスの作成は、IBM i ナビゲーター（iSeries ナビ ゲーター）から実行できます。なお、IBM i ナビゲーター上では「インデックス」を「索引」と表記して います。 手順 1. IBM i ナビゲーター内の「データベース」を展開 手順 2. データベース名で右クリックし、「索引アドバイザー」を選択 手順 3. 「勧告索引を圧縮※ もしくは 索引アドバイザー」を選択 ※ 「勧告索引を圧縮」を選択することで、重複したインデックスが排除され最小限のインデックス のみ表示されます。IBM i ナビゲーターのバージョンなどにより勧告索引の圧縮が利用できない 場合は通常の「索引アドバイザー」を選択してください。 手順 4．推奨インデックスの一覧から選択し※、インデックスを作成
※ 推奨された回数や MTI（一時インデックス）の作成回数も確認できますので、どのインデックス から作成していくかの参考にしてください。
なお、「インデックスの使用頻度の確認方法」や「インデックスの削除方法」や「推奨インデックスを 一括作成する方法」などの情報が、下記資料に記載されていますので、実際にインデックスを作 成する際には併せてご確認ください。
2011 年 Power Systems スキルアップセミナー IBM i（11 月～12 月）：DB2 for i 最新情報&再 認識（3.31MB）
参考情報
DB2 Web Query ポータルサイト
DB2 Web Query のご紹介ビデオや各種資料、導入手順書や FAQ、研修情報など、数多くの情 報がまとまったポータルサイトです。DB2 Web Query をこれから使用する方も、既にご利用中の 方も、ぜひ一度ご覧ください。
IBM DB2 Web Query for i ポータルサイト
実際に操作している様子を動画にて公開しています。現在は基本機能編とレポート作成編の 2 つ が公開されています。ログイン画面や、様々なレポートの実行の様子、レポート作成の操作感をご 覧ください。
第 1 弾：IBM DB2 Web Query for i デモビデオ（基本機能編）［約 5 分］ 第 2 弾：IBM DB2 Web Query for i デモビデオ（レポート作成編）［約 7 分］ 第 3 弾：IBM DB2 Web Query for i デモビデオ（インフォアシスト編）［約 6 分］
DB2 Web Query Redbook 日本語版 第 2 版
Redbook はチュートリアル形式の無料の自習書です。DB2 Web Query の主要な機能がこの一 冊に詰まっていますので、ぜひご一読ください。今回取り上げたシノニム（メタデータ）の説明や作 成方法も、この Redbook に記載されています。3.6.1 メタデータを参照ください。
