本資料掲載事項は、ある特定の環境・使用状況においての正確性がIBMによって確認されていますが、すべての環境において同様の結果が得られる保証は ありません。これらの技術を自身の環境に適用する際には、自己の責任において十分な検証と確認を実施いただくことをお奨めいたします。
DB2パフォーマンス管理ツール構築・利用ガイド
第2章 本編
・Optim Performance Manager
・Optim Query Workload Tuner
Notes
• 本SILは2012年07月30日時点の情報を元に、Optim Performance
Manager V5.1.1, Optim Query Workload Tuner V3.1.1, Optim
Configuration Manager V2.1.1, Optim pureQuery runtime V2.2の情報
をまとめたものです。
• 本資料は、1章 概要編、2章 本編、3章 OPM運用編、4章 導入編に分かれ
て構成されています。
第1章 DB2パフォーマンス管理ツール構築・利用ガイド 【概要編】
第2章 DB2パフォーマンス管理ツール構築・利用ガイド 【本編】
• Optim Performance Manager の導入と構成
• OPM導入作業の流れ
• OPMの基本操作
• Optim Performance Manager 活用例
• OPMを利用したデータベースの問題判別 • OPMを使用したWLMの構成とモニタリング
第3章 DB2パフォーマンス管理ツール構築・利用ガイド 【運用編】
• レポジトリーデータベースの構成 • レポジトリーデータベースの運用管理第4章 DB2パフォーマンス管理ツール構築・利用ガイド 【導入編】
• 【参考】Optim Performance Manager 導入手順 • 【参考】Optim Query Workload Tuner 導入手順
目次
【本編】目次
【 DB2パフォーマンス管理ツール構築・利用ガイド-本編】
• Optim Performance Manager の導入と構成
•
OPM導入作業の流れ
•
OPMの基本操作
• Optim Performance Manager 活用例
•
OPMを利用したデータベースの問題判別
Optim Performance Manager の 導入と構成
Optim Performance Managerの導入と構成
•
OPM導入作業の流れ
•
OPMサーバー導入作業
•
監視対象の追加と構成
OPM導入作業の流れ
OPMサーバーの導入OPMサーバー 導入作業
OPMサーバー・ライセンスの付与 Extended Insightライセンスの付与監視対象の追加と構成
監視レベルの決定 OPMサーバーで監視対象を構成 監視しきい値の構成 CIMの導入 Extended Insightの導入と構成監視端末の構成
Performance Expert Clientの導入
OPMサーバーとして使用するマシンに製品の導入を行う OPMサーバーのライセンスをActivateする 製品コードは導入済みのため、機能のActivateのみを実施 （オプション）End to Endの応答時間を監視する場合、 APサーバー側でExtended InsightのActivateを行う OPMの監視対象となるサーバーで取得する稼働資料の レベルを決定する
Web ConsoleもしくはPerformance Expert Clientから 監視対象とするデータベースを追加する 監視対象として追加したデータベースに対して 監視しきい値を設定する （オプション）監視対象のOS指標（CPU使用率やメモリー使用量など） を監視する場合、CIMサーバーの導入が必要。PE Clientで表示可能。 （オプション）End to Endの応答時間を監視する場合、 アプリケーション・サーバー上でEIモジュールの導入と 構成を行う （オプション）監視端末として使用するPC等にクライアント・モジュール を導入する ※監視対象DBのバージョンがV9.5以前の場合のみ
OPM導入の全体像
Meta snapshot E2E repository レポジトリー・サーバー コンソール・サーバー RS API Insert maintain DB2 LUW ESE Browser (IE/Firefox) Adobe Flash Http or Https -構成 -ダッシュボード -アラート -正常性Optim Performance Manager
TCP/IP
Performance Expert Client（オプション）
監視対象
DB 監視対象 DB 監視対象 DB
TCP/IP TCP/IP
• Optim Performance Manager Server （サーバー）
• Optim Performance Manager License Activation Kit （ライセンス）
• Optim Performance Manager Extended Insight Licence Activation Kit (オプション：Extended InsightのActivate）
• DB2 Performance Expert Client
（オプション） ※監視対象DBのバージョンがV9.5 以前の場合のみ
監視端末
WebSphere Application Server
アプリケーション・サーバー
• Optim Performance Manager Extended Insight Client（オプション）
• Common Information Model （オ
プション:CIMサーバー）
※監視対象DBのバージョンがV9.5以前の場合のみ TCP/IP
「OPMサーバー導入作業」の概要
•
導入作業の前提
• OPMサーバー導入前にDB2 ESE V9.1以降がインストール済み • 既存のインスタンスを使用する場合はインスタンスを活動化させておく
• OPMインストール時に新規でインスタンスを作成後
• OPMソフトウェアパッケージに同梱されている「DB2 ESE Restricted Use Activation」でインスタンスを活動化
• ライセンスセンターからOPMで限定的に使用できるライセンス（パッケージに付属）をインストールする • メモリ要件の確認 • 別章参照のこと • ディスク要件の確認 • 別章参照のこと
•
作業項目
• OPMサーバーの導入 • 具体的な手順は「OPMサーバーの導入ステップ」を参照 • OPMサーバー・ライセンスの付与 • 具体的な手順は「OPMサーバーライセンスの付与」を参照• OPMサーバー上にOPM Extended Insightの導入（オプション）
• 具体的な手順は「OPMサーバーでのExtended InsightのActivate」を参照
•
考慮点
• OPMパッケージに同梱されているDB2 ESE V10.1をインストールする場合はOPMでのみ使用できる限定的 なライセンスになるため、必要ならば事前にインストールしておく
• レポジトリサーバとしての利用する場合は、Oracle互換モードは使用しない
• 監視対象となるDBとは別サーバーへの導入が推奨
「監視対象の追加と構成」の概要
•
導入作業の前提
• 監視対象となるDBのホスト名、ポート番号、インスタンス名、ログインパスワードの調査
• CIMサーバー導入の前提条件をReadmeで参照（オプション） －PEクライアントを使用している場合のみモニター可能
• Extended Insightの機能を使用するためには、OPMサーバー上でExtended InsightがActivateされ ていること（オプション）
•
作業項目
• 監視レベルの決定 [次項参照] • OPMサーバー上で監視対象を構成 • 具体的な手順は「OPMサーバー上での監視対象の構成」を参照 • 監視しきい値の設定 • 具体的な手順は「監視しきい値の設定」を参照 • CIMの導入（オプション） • 具体的な手順は「CIMサーバーの導入」を参照• OPM Extended Insightクライアント・モジュールの導入と構成（オプション） • 具体的な手順は「OPM EIクライアントモジュールの導入」を参照
•
考慮点
• CIMとOPM EIはそれぞれOPMサーバーとは異なるサーバーに導入 • CIMはPEクライアントを使用している場合のみモニター可能 • CIMは監視したいDBサーバーに導入 •監視レベルの決定
SQLの規模と実行数 OLTPシステム BI/DWHシステム 低オーバーヘッド用 詳細情報収集用 監視負荷を小さく SQL活動を監視したい 開発システム テスト/QAシステム• OPMでは環境に合わせて監視対象を構成したテンプレートが用意されている
•本番環境ではSQLの規模と実行数に応じて適切な取得対象を選定する •監視対象項目を個別に選定し、データベース独自の組み合わせを作成することも可能• 監視対象のシステムが許容する負荷、構成に応じて柔軟に対応可能
SQLの規模が小さく、 同時実行数が多い SQLの規模が大きく、同時実行数が少ない pureScaleシステム SAP BI システム SAP ERP システム 低オーバーヘッド用 詳細情報収集用 監視負荷を小さく SQL活動を監視したい 低オーバーヘッド用 詳細情報収集用 低オーバーヘッド用 詳細情報収集用 低オーバーヘッド用 詳細情報収集用 開発システム テスト/QAシステム監視レベルの決定 －
デフォルトで用意されるテンプレート
OPTP 低負荷ﾞ OLTP 詳細 BI 低負荷 BI 詳細 pureScal e 低負荷 pureSca le 詳細 SAI BIw 低負荷 SAP BIw 詳細 SAP ERP 低負荷ﾞ SAP ERP 詳細 開発 ﾃｽﾄ/QA 基本 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ロック （詳細は別項） ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ SQL ステートメン トと接続 （ｻﾝﾌﾟﾘﾝｸﾞ率[分]） ○（1） ○（5） ○（2） ○(1) ○（1） ○（1） 入出力とディスク スペース （詳細は別項） ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ワークロード・マ ネージャー （詳細は別項） ○ ○ ○ ○ ○ 動的SQL （ｻﾝﾌﾟﾘﾝｸﾞ率[分]） ○（2） ○（2） ○(2) ○(15) ○（15） ○（1） ○（2） Extended Client Insight ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ Extended Server Insight ○ ○ ○ ○ ○ ○ ○監視レベルの決定 －
デフォルトで用意されるテンプレート
OPTP 低負荷ﾞ OLTP 詳細 BI 低負荷 BI 詳細 pureScal e 低負荷 pureSca le 詳細 SAI BIw 低負荷 SAP BIw 詳細 SAP ERP 低負荷ﾞ SAP ERP 詳細 開発 ﾃｽﾄ/QA ﾛｯｸ待機ｱﾗｰﾄ ○ ○ N/A ○ ○ ○ × × × × × × ﾛｯｸ待機しきい値 (msec)5000 5000 N/A 120000 5000 5000 N/A N/A N/A N/A N/A N/A
ﾛｯｸ･ﾀｲﾑｱｳﾄ･ｱ ﾗｰﾄ × × N/A × × × × × × × × × ﾃﾞｯﾄﾞﾛｯｸ･ｱﾗｰﾄ ○ ○ N/A × ○ ○ ○ ○ ○ ○ ○ ○ 既存のﾃﾞｯﾄﾞﾛｯｸ･ｲ ﾍﾞﾝﾄﾓﾆﾀｰの使用 × × N/A N/A × × × × × × × × ｶｽﾀﾑ表ｽﾍﾟｰｽの 使用 × × N/A × × × × × × × × × イベント詳細の収 集 なし ｽﾃｰﾄﾒ ﾝﾄ履歴 N/A ｽﾃｰﾄﾒ ﾝﾄ履歴 なし ｽﾃｰﾄﾒﾝ ﾄ履歴 なし なし なし なし ｽﾃｰﾄﾒ ﾝﾄ履歴 ｽﾃｰﾄﾒﾝ ﾄ履歴 （値あ り） ロック待機情報 ○ ○ N/A ○ ○ ○ × ○ × ○ ○ ○ 特殊ｻﾝﾌﾟﾘﾝｸﾞ率 （分）
1 1 N/A 1 1 1 N/A 5 N/A 5 １ 1
監視レベルの決定 －
デフォルトで用意されるテンプレート
OPTP 低負荷ﾞ OLTP 詳細 BI 低負荷 BI 詳細 pureScal e 低負荷 pureSca le 詳細 SAI BIw 低負荷 SAP BIw 詳細 SAP ERP 低負荷ﾞ SAP ERP 詳細 開発 ﾃｽﾄ/QA ﾊﾞｯﾌｧﾌﾟｰﾙ情報 (分) 1 1 1 1 1 1 5 5 5 5 1 1 表情報の収集(分) 1 1 1 1 1 1 5 5 5 5 × 1 表ｽﾍﾟｰｽ情報の 収集(分) 1 1 × 1 1 1 5 5 5 5 1 1 ｺﾝﾃﾅｰ情報 × × N/A × × × × × × × ○ ○ 入出力およびディスクスペースの詳細 OPTP 低負荷ﾞ OLTP 詳細 BI 低負荷 BI 詳細 pureScal e 低負荷 pureSca le 詳細 SAI BIw 低負荷 SAP BIw 詳細 SAP ERP 低負荷ﾞ SAP ERP 詳細 開発 ﾃｽﾄ/QA ｶｽﾀﾑ表ｽﾍﾟｰｽの 使用N/A N/A N/A × × × N/A N/A N/A N/A × ×
ｱｸﾃｨﾋﾞﾃｨ情報 （分）
N/A N/A N/A 30 30 30 N/A N/A N/A N/A 30 30
構成情報（分） N/A N/A N/A 30 30 30 N/A N/A N/A N/A 30 30
監視対象サーバへの導入作業
• OPMによる監視を行う場合、下記のコンポーネントを導入することでより高度な
監視が可能（オプション）
•CIMサーバ
•AIX ⇒「AIX Pegasus CIM server and providers for AIX」
•Solaris ⇒「WBEM Services」
•Linux ⇒「Open Pegasus」
•UNIX/Linuxへ導入することで、OSリソース（CPU、Memory、I/O）の稼働
資料を取得可能
•
PEクライアントを使用している場合のみモニター可能
•Extended Insight
•Websphere上のJDBCアプリケーション、CLIアプリケーションなどを対象
として、トランザクションの応答時間を監視することが可能
•Extended Insightのクライアント・モジュールを導入し、構成を行う
「監視端末の構成」の概要
•
導入作業の前提
• 監視端末は2種類 • Webコンソール
• Internet Explorer もしくはMozilla Firefox
• プラグインとしてAdobe Flash Playerが導入されていること • DB2 performance Expert Client（オプション）
• プラットフォームはWindows もしくはLinux
•
作業項目
• 指定のブラウザにログインURLを入力（httpとhttpsの2種類がある） • http://host_name:55000/optimdatatools
• https://host_name:55001/optimdatatools
• DB2 Performance Expert Clientの導入（オプション）
• 具体的な手順は「DB2 Performance Expert Clientの導入」を参照
•
考慮点
• Web コンソール
• WebSphere Application Server は不要 • httpsはhttpにSSL/STLプロトコルを使用
• DB2 performance Expert Client
• TCP/IPで直接パフォーマンスDB(デフォルトではPERFDB)から情報を取得し、表示する
詳細はSystem Requirementsを参 照
Optim Performance Manager の 導入と構成
Optim Performance Manager の基本操作
• OPMの基本操作
•
OPM サーバーの起動停止
•
Web Consoleの起動
•
監視対象DBの追加
•
Web Console基本画面遷移
•
監視しきい値の設定
•
レポートの作成とエクスポート
OPMサーバーの起動停止
Web Consoleの起動
Optim Performance Managerの起動
• Optim Performance Managerの起動 • WINDOWSの場合：
•スタートメニューから、「IBM InfoSphere Optim」 > 「IBM InfoSphere Optim Performance Manager」
> 「IBM InfoSphere Optim Performance Manager の開始」 実行 •UNIX/LINUXの場合：
•/opt/IBM/OPM/OPMStart.sh 実行
OPM が起動していない場合、画面右上にワーニン
グが表示される。 → OPMStart を実行する。
• Optim Performance Managerの停止 • WINDOWSの場合：
•スタートメニューから、「IBM InfoSphere Optim」 > 「IBM InfoSphere Optim Performance Manager」
> 「IBM InfoSphere Optim Performance Manager の停止」 実行 •UNIX/LINUXの場合：
•/opt/IBM/OPM/OPMStop.sh 実行
レポジトリDBのDB2インスタンスユーザーで実行
db2stopは実行していない db2startを実行している
Web Consoleの起動
• 0.OPMのWebコンソールを起動させる •WINDOWS：
•「すべてのプログラム」⇒「IBM InfoSphere Optim」⇒「IBM Optim Performance Manager 5.1」⇒「Web Console」 •ログインユーザーとパスワードを入力（導入時に指定したユーザー／パスワード）
•Linux/Unix：
監視対象DBの追加と構成
1.モニタリング対象のデータベースを構成
監視対象DBの追加と構成
2.モニタリング対象のデータベースの追加
「追加」をクリックし、モニター対象のDBを追加する
監視対象DBの追加と構成
3.モニタリング対象のDBを追加するために、必要項目を入力し、テスト接続を実施する
OPM上で識別する名前 実際のﾃﾞｰﾀﾍﾞｰｽ名 接続したいﾎｽﾄ名 or IPｱﾄﾞﾚｽ DB2ｲﾝｽﾀﾝｽのﾎﾟｰﾄ番号 DBへｱｸｾｽ件を持つﾕｰｻﾞ/ﾊﾟｽ ﾜｰﾄﾞの指定。暗号化されて保存 される監視対象DBの追加と構成
4.モニター情報の選択
監視対象DBの追加と構成
5.タイムゾーン、モニタリング構成を選択し「次へ」をクリック
ﾀｲﾑｿﾞｰﾝの選択 ﾓﾆﾀﾘﾝｸﾞ・ﾌﾟﾛﾌｧｲﾙの事前ﾃﾝ ﾌﾟﾚｰﾄを指定することが可能 (詳細は別項参照)監視対象DBの追加と構成
6.モニタリング・プロファイルを設定・確認できる。「次へ」をクリック。
をクリックしてより詳細な設定ができる
ﾃﾞﾌｫﾙﾄのﾃﾞｰﾀ収集間隔は1分と なっている。拡張することを推奨。
監視対象DBの追加と構成
7. 「保存期間およびサンプリング間隔」の設定例。OKを押して「モニタリングの構成」へ戻る
「ﾊﾟﾌｫｰﾏﾝｽ・ﾃﾞｰﾀ」は、ｻﾝﾌﾟﾘ ﾝｸﾞ間隔と保存期間でﾃﾞｰﾀ保 持を設定できる。 ﾃﾞﾌｫﾙﾄのｻﾝﾌﾟﾘﾝｸﾞ間隔は1分 となっている。拡張することを 推奨。 「ﾊﾟﾌｫｰﾏﾝｽ・ﾃﾞｰﾀ」は4段階の 集約ﾚﾍﾞﾙが決まっていて、各 レベルの期間を指定すること となる。 集約レベル4は1日単位の荒 い情報となるが保管期間は1 年間と長くなる。 この設定によってﾚﾎﾟｼﾞﾄﾘｰDB の容量見積もりが変化する監視対象DBの追加と構成
8.指定したﾓﾆﾀﾘﾝｸﾞ・ﾌﾟﾛﾌｧｲﾙ
によって、モニター・スイッ
チ、イベントモニター、メト
リックの収集項目が変化す
る。「次へ」もしくは「終了」
をクリック
監視対象DBの追加と構成
監視対象DBの追加と構成
監視対象DBの追加と構成
11.パスワードを入力し「OK」をクリックすると、モニタリングの構成が実行される
OPM上のDB(PERFDB)に管理用の 表などを作成している
監視対象DBの追加と構成
12.データベースが追加されたことを確認し、「タスク・マネージャー」のタブをクリックし、「正常性の
監視対象DBの追加と構成
監視対象DBの追加と構成
Web Console基本画面遷移
アクションと確認事項
OPM画面遷移
正常性の要約 アラート ダッシュボード データベースごとに問題の所在（ワー ニング/アラートの有無）を確認 ワーニング/アラート･イベントの発生時 刻、内容を確認 ・解析対象の「アクション」から対応した ダッシュボード画面へ遷移 解析 原因の解析と対応Web Console基本画面遷移
– 正常性の要約
•
”正常性の要約”により、データベースごとに大まかな問題のありかを把握する
•
画面左上 “開く
↓” より”正常性の要約”を選択
• ”正常性の要約”画面より、どのデーターベースに問題があるかのサマリーを表示。
• それぞれのデータベースについてKey Performance Indicators (KPIs)が表示される
Web Console基本画面遷移
–
アラート画面
•
”アラート画面”により、ワーニング/
アラート･イベントの発生時刻、内容
を確認
•
“正常性の要約”のそれぞれの
KPIをクリックすると対応する
“アラート画面” が表示される
•
更に詳細情報を得るために、
”アクション”タブから関連する
”ダッシュボード”へのリンクへ
と飛ぶことができる
ダッシュボード へWeb Console基本画面遷移
–
ダッシュボード
•
”ダッシュボード” からグラフによる時系列の遷移を見ることができる。
監視しきい値の設定
OPMではデータベース毎にWarning/Criticalのアラートを出すしきい値を決定できる
Webコンソールから設定が可能
監視しきい値の設定
監視しきい値の設定
4. しきい値の値、使用可否を変更する
•不要な監視項目は「有効」列にて「オフ」に設定する •変更箇所は色違いで判別できる
レポートの作成 と エクスポート –
レポート作成
• [タスク・ランチャー] >> [データベースのパフォーマンス・レポートの実行] もしくは
• [開く↓] >> [パフォーマンス] >> [レポート] でレポート作成開始
レポートの作成 と エクスポート –
レポート作成
•
情報を取得したいデータベースに接続し、＜レポートのタイプの選択＞からレポート
作成したい項目を選択
レポートの作成 と エクスポート –
レポート作成
•
レポートに出力したい情報の条件(取得期間やソート順、ステートメントの数など)を指定し
て、[レポートの生成] ボタンをクリック
レポートの作成 と エクスポート –
レポート作成/エクスポー
ト
•
レポートが以下のように表示される
•
エクスポートしたい場合は、ファイル形式（xls,ppt,pdf）を右上から選択できる
平均や合計、ソートや ロックなど、表示したい 計算方法やカテゴリを 選択できるレポートの作成 と エクスポート –
エクスポート
•
エクスポートのファイル形式を選択すると、「プログラムで開く」か「ファイルを保存
する」を選択できる
レポートの作成 と エクスポート –
エクセル形式
•
エクセル形式のファイルとしてエクスポート可能
実際のxlsファイルをサンプルレポートと してザ技術に添付しています。レポートの作成 と エクスポート –
PDF形式
レポートの作成 と エクスポート –
パワーポイント形式
•
パワーポイント形式のファイルでのエクスポート可能
実際のPPTファイルをサンプルレポート としてザ技術に添付しています。Optim Performance Manager 活用例
OPMを利用したデータベースの問題判別
•
問題判別例
1.
デッドロックの発生と原因の特定
2.
データベース稼働状態のヘルス・チェック
3.
非効率なアクセスプランによるリソースの占有
4.
APサーバからの3層構造での性能問題分析
アクションと確認事項
OPM画面遷移
１．デッドロック発生の特定と原因解析
正常性の要約 ・ロックアラートの発生を検知 ロックのアラート画面 ・ロックイベントの発生回数や時刻を確認 ロッキングダッシュボード ・解析対象のイベントを選択して分析画面へ遷移 分析画面 ・デッドロックに関係するアプリケーションの詳細を確認 ・時系列でのSQLステートメント情報 ・デッドロックに至ったロックの詳細情報• 問題解析の流れ
１．デッドロック発生の特定と原因解析
• Locking Alert の発生を確認
•
OPMによる監視対象データベースを横串でサマリーする「Health Summary」から
PEDEMOデータベースに複数のアラートが発生していることを確認
•
デッドロックによる問題発生の場合、アプリケーション側でのエラー検知
（SQL0911,RC=2を検知）となる場合もある
PEDEMOデータベースのみ アラートが発生 Lockingのアラートをクリック し、Alert Summaryに遷移１．デッドロック発生の特定と原因解析
• Lockingイベントの発生状況や時刻を確認
10:30から10:35にかけて4回 のデッドロックが発生 Lockingの発生状況を見るた めLocking Dashboardへ遷 移 Analyzeから直接デッドロッ クの詳細へ飛ぶことも可能１．デッドロック発生の特定と原因解析
• 解析対象のイベントを選択してAnalyze画面へ遷移
最新のデッドロック発生を選択
１．デッドロック発生の特定と原因解析
• デッドロックに関係するアプリケーションの詳細を確認
デッドロックの原因となったアプ リケーション名を確認 ここではサンプル・アプリ同士の デッドロックとなっている。 本番環境ではWAS/WASや WAS/バッチ処理といった接続 元の情報から両者の関連を類 推可能 パネルの最下部にデッドロック の原因となったSQLステートメン トが表示される。 この例では、RES_A表への全 件スキャンが2つのアプリケー ションで重なっている１．デッドロック発生の特定と原因解析
• 時系列でのSQLステートメント情報を取得
•
Statements画面の上半分
•
2つの接続から発行されたSQLが時系列で表示される
時 系 列 時 系 列 デッドロックに関連する2つのアプリ ケーションで実行されたSQLが、時 系列に出力される。 Participantsタブの情報から、デッド ロックの直接の原因となったSQLの 一方が特定できる。 これを手がかりに、問題となる処理 順序や処理対象行の特定を行う１．デッドロック発生の特定と原因解析
• デッドロックに関連するSQLとロックの詳細情報
•
Statements画面の下半分
•
前ページの各SQLごとに詳細情報が確認可能
複数のSQLが同じUOW IDの場合、１トランザクションで実 行されており、複数SQL分のロックが保持される READ ONLYのSQLだが、NSロックが要求してい るため、他のアプリが排他ロックを保持する場合、 競合しロック待ちが発生する１．デッドロック発生の特定と原因解析
• デッドロック発生原因の特定
•
「statements」タブからデッドロックに直接関係するSQLを抽出
•
両方のアプリケーションが相手のINSERTコミットを待つ状態となっている
相手のINSERTに よる排他ロックで ロック待ち ACTID=1:INSERT INTO pedemo.res_a VALUES ('SOMETHING',29,'NOMATTER')
ACTID=8:
SELECT * FROM pedemo.res_a Participant ID=47
ACTID=3:
INSERT INTO pedemo.res_a VALUES ('SOMETHING',91,'NOMATTER')
ACTID=4:
SELECT * FROM pedemo.res_a Participant ID=48
RES_A表
排他ロック
排他ロック
COL1 COL2 COL3
AAA 1 AA
BBB 2 BB
CCC 3 CC
somthing 29 NOMATTHER somthing 91 NOMATTHER
１．デッドロック発生の特定と原因解析
• 考えられる対応策
1. SELECTの分離レベルをCurrently Committedへ変更する
•
読込スキャンが排他ロックの解放を待たずに読み飛ばすため、
ロック待ちが発生しない
2. 照会と更新のトランザクション・スコープを分離する
•
更新をいったん確定させてから、紹介を行うことでロックの競合を
避ける
ACTID=1:INSERT INTO pedemo.res_a VALUES ('SOMETHING',29,'NOMATTER')
ACTID=8:
SELECT * FROM pedemo.res_a Participant ID=47
ACTID=3:
INSERT INTO pedemo.res_a VALUES ('SOMETHING',91,'NOMATTER')
ACTID=4:
SELECT * FROM pedemo.res_a Participant ID=48
アクションと確認事項
OPM画面遷移
2.データベース稼働状態のヘルス・チェック
正常性の要約 ・Critical/Warningの有無を確認 アラート画面 メッセージの傾向を確認 ダッシュボード メッセージの傾向に応じた ダッシュボードへ遷移 原因の解析と対応 ・主要なBuffer Poolのヒット率を確認 ・I/O負荷の原因となっている表、表スペースを確認 ・原因SQLの改善やBP拡張などを実施• 問題解析の流れ
2.データベース稼働状態のヘルス・チェック
• Health Summaryから大まかな問題の所在を確認 • Health Summary画面では、複数の監視対象に対して横串で問題の所在を確認可能 • データベース毎に決めたしきい値にもとづいてWarningやCriticalのAlertが発行される。 • 個別に設定しない場合、共通のデフォルト値が使用される。 • 「BPヒット率が90%以下でCritical、95%以下でWarning」など PEDEMOデータベースのMemory UsageやI/O、Workloadにアラート が発生している PEDEMO以外の2データベースは 問題なく稼働中 I/Oのアイコンをクリッ クし、Alert Summery へ遷移2.データベース稼働状態のヘルス・チェック
• I/O状況の確認
•
BPヒット率が50%以下になっており、かつ同期I/OがREAD処理の100％を占める。
詳細を確認するため、
Buffer Pool and I/O Dashboardへ遷移 Buffer Poolヒット率が著しく低くなっ ており、READの効率が悪い
2.データベース稼働状態のヘルス・チェック
• Buffer Pool and I/O Dashboard :Buffer Poolsタブ
•
バッファープール、表スペース、表のそれぞれのビューで処理負荷の高いオブジェク
トをピックアップ可能
•
バッファープール => 表スペース => 表とドリルダウンすることで、GUIから問題の所
在を絞り込むことが可能
• 下記の例では、バッファープールサイズがデータ量に比して過小となっている FRUITSバッファープールはサイズが 5pageと小さく、ヒット率が10%以下。 また、Logical Readsが毎秒10万弱と、 データベース全体の50%以上を占める デフォルトではヒット率の下位2.データベース稼働状態のヘルス・チェック
• Buffer Pool and I/O Dashboard :Table Spacesタブ
•
サイズが過小となっているFRUITSバッファープールに関連する表スペースを一覧
•
2つの表スペースGROWTHとTRADEのうち、GROWTHのBPヒット率が約4%と著しく低い
FRUITSバッファープールに紐 付く表スペースのみをリスト FRUITSバッファープールのREAD活動 のうち、90%程度をGROWTH表スペース が占め、そのヒット率は4%程度 さらに絞り込む場合、GROWTH表スペー スをドリルダウンする2.データベース稼働状態のヘルス・チェック
• Buffer Pool and I/O Dashboard :Tables タブ
•
読み込み量の多いGROWTH表スペースに属する表を一覧
•
表スペース全体のアクセスレコード数が毎分約45000行
•
アクセス数の最も多いFRUIT表のアクセスレコード数が毎分約42000行
FRUITSバッファープールのREAD活動 のうち、90%程度をGROWTH表スペース が占め、そのヒット率は4%程度 さらに絞り込む場合、GROWTH表スペー スをドリルダウンする2.データベース稼働状態のヘルス・チェック
• PEDEMOデータベースでのI/O過多への対応
•
Buffer Pool and I/O Dashboardの情報から、FRUITSバッファープールのサ
イズが過小であることが判明したため、拡張を行う。
5page
3000page
FRUITS BP
ALTER BUFFERPOOL拡張後のHealth Summary
拡張後のDash Board
BPヒット率97%に改善アクションと確認事項
OPM画面遷移
3. 非効率なアクセスプランによるリソースの占有
正常性の要約 「2.ヘルスチェック」と同様に全体の稼働状況を確認 アクティブSQL OPMからSQLの活動をチェック アクセスプラン取得 問題のあるSQLのアクセスプランを確認 SQLのチューニング実施 ・アクセスプランの評価 ・統計情報最適化の可能性を検討 ・索引追加によるチューニングを検討• 問題解析の流れ
3. 非効率なアクセスプランによるリソースの占有
• 多くのリソースを消費し、他の処理に影響を与えるSQLを発見する
• 最初にデータベース全体の動きをチェックするのは2.と同様
•
Health Summaryからアラートをチェック
•
BP and I/O Dashboardから特異な表アクセスが発生していないかを確認
Health SummaryからI/O異常を検知し、Tableの Viewまでドリルダウンした結果、LINTEITEM2表の I/Oが非常に多いことがわかる
3. 非効率なアクセスプランによるリソースの占有
• 特異な表アクセスが発見された場合、その表に関連するSQLを検索
•
Task ManagerからActive SQL Dashboardへ遷移
•
Elapsed TimeやCost、CPU使用量などで上位/下位のSQLを特定可能
LINTEITEM2表に関連するSQLが実行時間 （Elapsed Time）の上位に来ている
3. 非効率なアクセスプランによるリソースの占有
• 特異な表アクセスが発見された場合、その表に関連するSQLを検索
•
実行中のSQLであれば、OPM画面からのキャンセルも可能
•
OPMからOptim Query Workload Tunerへ遷移し、GUIでのSQLチューニングも可
能
SQLステート メント全文
3. 非効率なアクセスプランによるリソースの占有
• SQLのチューニングを実施
•
OPM自身はSQLのチューニング機能は持たない
•
Optim Query Workload Tunerとの連携が可能
•
アクセスプランの取得はOPMからではなく他のツールを使用
•
SQLを抽出してCUIでのEXPLAIN取得も可能
（参考）Optim Query Workload Tuner概要
DB2のパフォーマンス最適化、開発コストの削減の実現
• 下記の各種アドバイザー機能統合による、パフォーマンスチューニングの生産性向上
•
統計アドバイザー
•
照会アドバイザー
•
アクセス・パス・アドバイザー
•
索引アドバイザー
• 注）これまでは上記アドバイザーを個別に立ち上げが必要でした。• 各アドバイザー機能をEclipseベースのGUIから簡単に呼び出し可能
•
他Optimツール群との機能連携も実現
• Optim Performance Manager
• Optim Database Administrator / Optim Development Studio etc..
OQWTによるクエリーチューニングの流れ
モニター
起動
分析
アドバイス
実行
0. OPMなどを利用し、ハイコストなSQLステートメントをモニター
1 . 問題のSQLを特定し、OQWTを起動
2 . 現状の統計情報を下に、アクセ
スプランを分析
3 . OQWTから各種アドバイザを起動、最
適なアクセスプランや照会のアドバイスを
実施
4 . 各種アドバイザのアドバイス内容を実施し、
アクセスプランの比較・検証を実施
改善！
• OPMのSQLステートメント詳細[チューニング]ボタンからもOQWT起動可能
OQWT(DataStudio上)起 動&SQL入力OPMなどで、ハイコストなSQLステートメントを特定
2.ハイコストなSQLステートメント 1.各SQLステートメントを表示 ハイコストなSQLの特定OQWTによるSQLステートメントの分析
• チューニング対象のSQLステートメント入力
照会テキストを直接入力 (コピー可) チューニング対象 と入力方法として 様々な手段がある• ツール、アドバイザーの選択
この例では[すべてを選択] 分析ツールの選択 アドバイス内容を選択 サマリーレポートの 生成の選択OQWTによるSQLステートメントの分析
「OK」で実 行•OQWTのアドバイス結果の表示
優先順位をつけた形でSQLチュー ニングのアドバイスが列挙される
• 推奨情報の実行 ／統計アドバイザの結果表示と実行
各アドバイザの概要の表示 複数アドバイザ結果があ る場合は、高い効果が期 待できる順に出力される 統計アドバイザの詳細項目 アドバイザ項目をクリックする と、その詳細と共に実行すべ きDDL文を作成、表示可能 内容を確認次第、DDLを 実行することが可能OQWTによるSQLステートメントの分析
• 索引アドバイザの結果表示と実行
索引アドバイザの詳細 項目 推奨索引の各項目説明 が羅列される 具体的に実行されるされ るDDL文が表示され、内 容確認後実行することが 可能OQWTによるSQLステートメントの分析
• アドバイス内容の実施の前と後でアクセスプランの比較検証
索引作成前 索引作成後
アクションと確認事項
OPM画面遷移
4． APサーバからの3層構造での性能問題分析
正常性の要約 ・エンドーツーエンドの応答時間の遅延を確認 拡張インサイト・ダッシュボード ・解析対象の切り口を選択して分析画面へ遷移
分析画面 ・応答時間の長いステートメントやクライアントを確認 原因の解析と対応 ・どの層に時間が要しているかボトルネックの判別 ・各製品担当と連携してチューニングを対応 ・DBサーバが原因の場合、Query Tunerと
連携可• 問題解析の流れ
• 最大のエンドツーエンド応答時間が12秒以上かかっていることを確認
• OPMによる監視対象データベースを横串でサマリーする「正常性の要約」からray_tpccデータ ベースのエンドツーエンド応答時間が10秒を超えていることを確認 応答時間が12秒を要してい ることを確認 応答時間をクリックし表示さ れる「拡張インサイト・ダッ シュボード」に遷移4． APサーバからの3層構造での性能問題分析
• ray_tpccの拡張インサイト分析ダッシュボートのトランザクションの詳細を
確認
さらに詳細を確認するため、 [応答時間の詳細]へ遷移
• 応答時間の詳細をグラフ、SQLステートメント、実際の数値を表示
• 下部にはさらに詳細な応答時間の詳
細な数値が表示されている
4． APサーバからの3層構造での性能問題分析
• 上部のグラフにカーソルを近づけ
ると、取得項目や時刻が確認で
きる
• [SQLステートメント]タブの単位で[エンド
ツーエンド応答時間]を選択し、応答時
間のいちばん長かったSQLをクリック
• SQLステートメントの詳細領域を表示して、
時間のかかったSQLがどこで時間を要し
ていたか、調べることができる
[全体時間の分布]から、ク ライアントで最も時間を要 していたことか、がわかる4． APサーバからの3層構造での性能問題分析
• ボトルネックがどこか判別し、対応するチューニングを実施
•
OPM自身は各製品のチューニング機能は持たない
•
データベース(SQL)がボトルネックであれば、Optim Query
Workload Tunerとの連携が可能(前項参照)
•
クライアント、ネットワークがボトルネックの場合は、各製品担当と
連携して対応する
4． APサーバからの3層構造での性能問題分析
Optim Performance Manager 活用例
OPMを利用したWLMの構成とモニタリング
• OPMによるWLM管理概要
• WLMの構成
•
現在のWLM構成を表示
•
推奨WLM構成の作成／確認
•
データベース全体のポリシー
•
ワークロードの構成
•
サービス・スーパークラスの構成
•
サービス・サブクラスの構成
•
パフォーマンス目標の設定
•
DDLの実行
• WLMのモニター
OPMによるWLM管理概要
• OPMによって何ができるか？
•
グラフィカルなインターフェースで簡単にWLM構成とモニターが可能
•
WLMの構成
• デフォルトでWLM構成モデルが提供される • ワークロード分類設定、サービスクラス（実行環境）の設定、しきい値の設定をグラ フィカルなインターフェースから実行可能•
WLMのモニター
• サービス・サブクラスごとにSQL実行時間や、キュー待機時間の分布図がモニター できる • その他、サービスクラスのCPU使用量、現状アクティビティの接続属性を確認できるWLMを利用したアクティビティの分類
•
構成例１．シンプル構成
• 接続ユーザーによってアクティビティを分類し、優先度の異なるサービスサブクラスで実行させる。 • OPMでは、デフォルトのサービス（サブ）クラスが雛形として提供される。 Urgent work 高優先度 Ordinary Work 中優先度 Batch jobs 低優先度 LOADworkloads
service subclasses
高優先度ユーザー USER_H 低優先度ユーザー USER_L 中優先度ユーザー USER_M
thresholds
N/A 並行度制限 = 18 並行度制限 = 1 結果行数 < 100000 行service classes
DS_AUTO_MGMT_SUPER0.事前準備
• 対象のDBのモニタリング・プロファイ
ルで、ワークロード・マネージャーが選
択されていることを確認
0.事前準備
0.事前準備
• データベースを選択し接続する
• 接続ユーザー/パスワードを指定
1. WLMの構成：現在のWLM構成を表示
• タイプを選択すると詳細設定が表示される
• 現在のWLM構成をリバースエンジニアリング2. WLMの構成：推奨WLM構成の作成
• WLMの推奨ベースラインの作成
3. WLMの構成：推奨WLM構成の概要確認
• WLMの推奨ベースラインの概要確認
• WLM未構成の場合、推奨ベースラインの作成を実施する
3. WLMの構成：推奨WLM構成の概要確認
• WLMの推奨ベースラインのしきい値確認
3. WLMの構成：推奨WLM構成の概要確認
• WLMの推奨ベースラインと現行構成の差異確認
• MAINをスーパークラスとしたサブクラスが作成されている 変更（追加）ありのマーク 変更部分のDDLを表示し、実行可能。 他のタグで詳細設定後に実行することも 可能。 差異のみの表示も可能4. WLMの構成：データベース全体のポリシー
• データベース全体のポリシーの確認／修正
• 以下のしきい値に関するデータベース全体のポリシーを確認／修正できる
4. WLMの構成：データベース全体のポリシー
• データベース全体のポリシーの確認／修正
• 以下のしきい値に関するデータベース全体のポリシーを確認／修正できる
4. WLMの構成：データベース全体のポリシー
4. WLMの構成：データベース全体のポリシー
• さらに詳細な設定の確認／修正
5. WLMの構成：ワークロードの構成
• ワークロードの確認／修正
6. WLMの構成：サービス・スーパークラスの構成
• サービス・スーパークラスの確認／修正
• サービス・スーパークラスの追加、各サービス・スーパークラスのプロパティー、しきい値、ワークロードの確認 ／修正ができる
7. WLMの構成：サービス・サブクラスの構成
• サービス・サブクラスの確認／修正
• 任意のサービス・スーパークラスに関連したサブクラスの確認／追加、各サービス・サブクラスのプロパティー、 しきい値、ワークロードの確認／修正ができる
• 「MAIN」のサービス・スーパークラスに6つのサービス・サブクラスが雛形として作成され
る。
• 用途に応じてそれぞれの優先度設定を行う • デフォルトはモニター設定のみであり、制限を越えるアクティビティの停止はされない設定となっている • DML処理 • SQLコストに応じて、5つのサービス・サブクラスが定義されている • コストに応じたアクティビティ合計時間のしきい値が設定されている • 並行性のしきい値が設定されているが、使用可能の設定にはなっていない • Load処理 • Load処理用に１つのサービス・サブクラスが定義されている TRIVIAL_DML7. WLMの構成：サービス・サブクラスの構成
MINOR_DML SIMPLE_DML MEDIUM_DML COMPLEX_DML
8. WLMの構成：パフォーマンス目標の設定
• パフォーマンス目標の確認／修正
• 任意のサービス・サブクラスの並行性の設定をオートノミックに調整する設定ができる
• 画面右上 「SQLのプレビューと実行」 ボタンを押す
•
WLM設定を反映するためのDDLが表示される。
•
確認して実行する。
• ワークロード、サービス・スーパークラス、サービス・サブクラスの単位でモニター可能 • 右上の「グラフの表示」により、グラフと設定情報を切り替えられる
10. WLMのモニター
「グラフの表示」⇔「サブクラスの表示」で、 グラフと定義を切り替えられる 「ワークロード」、「サービス・スーパークラス」、 「サービス・サブクラス」でグラフ表示が可能• ワークロード、サービス・スーパークラス、サービス・サブクラスの単位でモニター可能 • 並行性およびキュー内にある時間 • ヒストグラム（分布図） • 応答時間 の分布
10. WLMのモニター
タイムスライダーにより、 対象期間を設定可能 サービス・サブクラスごとに、 確認できる参考情報
• IBM REDBOOKS ”IBM Optim Performance Manager for DB2 for Linux, UNIX, and Windows”
http://www.redbooks.ibm.com/abstracts/sg247925.html
• Capacity planning for Optim Performance Manager
https://www-304.ibm.com/support/docview.wss?uid=swg27021636
• Best Practices: DB2 Workload Management
http://www.ibm.com/developerworks/data/bestpractices/workloadmanagement/
• Optim Performance Manager Extended Edition for DB2 for Linux, UNIX and Windows (home page)
http://www-01.ibm.com/software/data/optim/performance-manager-extended-edition/
• IBM Optim Performance Manager for DB2 for Linux , UNIX , and Windows helps resolve emergent
performance problems before they impact the business – IBM United States Software Announcement 210-143 – April 6, 2010
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=Demo&htmlfid=897/ENUS210-143
