DB2 Web Query パフォーマンス改善のツボ！

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 ポータルサイト には関連する情報を集約しています 当セミナー情報の最下部 参考情報 をご覧ください 第 1 弾 :DB2 Web Query を利用した IBM i での情報活用のススメ

第 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 ポータルサイト DB2 Web Query デモビデオ

実際に操作している様子を動画にて公開しています 現在は基本機能編とレポート作成編の 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 メタデータを参照ください DB2 Web Query 日本語版 Redbook 発行のお知らせ