パフォーマンス管理ツール構築・利用ガイド · 第3章 DB2パフォーマンス管理ツール構築・利用ガイド【運用編】 • レポジトリーデータベースの構成

本資料掲載事項は、ある特定の環境・使用状況においての正確性がIBMによって確認されていますが、すべての環境において同様の結果が得られる保証はありません。これらの技術を自身の環境に適用する際には、自己の責任において十分な検証と確認を実施いただくことをお奨めいたします。

© 2012 IBM Corporation

DB2パフォーマンス管理ツール構築・利用ガイド第2章本編・Optim Performance Manager ・Optim Query Workload Tuner

© 2012 IBM Corporation 1

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


第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 導入手順

目次

© 2012 IBM Corporation 3 3

【本編】目次

【 DB2パフォーマンス管理ツール構築・利用ガイド-本編】

• Optim Performance Manager の導入と構成

• OPM導入作業の流れ


• Optim Performance Manager 活用例

• OPMを利用したデータベースの問題判別

• OPMを使用したWLMの構成とモニタリング


Optim Performance Manager の導入と構成 OPM導入作業の流れ


Optim Performance Managerの導入と構成

• OPM導入作業の流れ

• 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以前の場合のみ

ブラウザを使用したWeb Consoleによる監視も可能


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とOPMサーバーで時刻の同期が取れている必要がある


監視対象の追加と構成


「監視対象の追加と構成」の概要

• 導入作業の前提 • 監視対象となる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サーバーに導入

• OPM Extended Insightクライアントモジュールは監視したいアプリケーションが稼動しているWASと同じサーバーに導入


監視レベルの決定

SQLの規模と実行数

OLTPシステム BI/DWHシステム

低オーバーヘッド用

詳細情報収集用

監視負荷を小さく

SQL活動を監視したい

開発システム

テスト/QAシステム

• OPMでは環境に合わせて監視対象を構成したテンプレートが用意されている

•本番環境ではSQLの規模と実行数に応じて適切な取得対象を選定する

•監視対象項目を個別に選定し、データベース独自の組み合わせを作成することも可能

• 監視対象のシステムが許容する負荷、構成に応じて柔軟に対応可能

SQLの規模が小さく、同時実行数が多い

SQLの規模が大きく、同時実行数が少ない

pureScaleシステム

SAP BI システム

SAP ERP システム



監視負荷を小さく

SQL活動を監視したい







開発システム

テスト/QAシステム


監視レベルの決定－デフォルトで用意されるテンプレート

OPTP 低負荷ﾞ

OLTP 詳細

BI 低負荷

BI 詳細

pureScale 低負荷

pureScale 詳細

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 詳細

pureScale 低負荷

pureScale 詳細

SAI BIw 低負荷

SAP BIw 詳細


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 詳細

pureScale 低負荷

pureScale 詳細

SAI BIw 低負荷

SAP BIw 詳細


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 詳細

pureScale 低負荷

pureScale 詳細

SAI BIw 低負荷

SAP BIw 詳細


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 の導入と構成 OPM基本操作


Optim Performance Manager の基本操作


• 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：

•ブラウザから http://IP_address:port_number/optimdatatools へアクセス

•デフォルトのポートは55000 (HTTPS の場合55001)


監視対象DBの追加


監視対象DBの追加と構成

1.モニタリング対象のデータベースを構成

「モニター用データベースの追加および構成」をクリック



2.モニタリング対象のデータベースの追加

「追加」をクリックし、モニター対象のDBを追加する

「ヘルプ」の表示／非表示が可能



3.モニタリング対象のDBを追加するために、必要項目を入力し、テスト接続を実施する

OPM上で識別する名前

実際のﾃﾞｰﾀﾍﾞｰｽ名

接続したいﾎｽﾄ名 or IPｱﾄﾞﾚｽ

DB2ｲﾝｽﾀﾝｽのﾎﾟｰﾄ番号

DBへｱｸｾｽ件を持つﾕｰｻﾞ/ﾊﾟｽﾜｰﾄﾞの指定。暗号化されて保存される

画面一番下に「テスト接続」がある



4.モニター情報の選択

対象のDBが、DB2 V9.7以降である場合、履歴モニターも選択可能。



5.タイムゾーン、モニタリング構成を選択し「次へ」をクリック

ﾀｲﾑｿﾞｰﾝの選択

ﾓﾆﾀﾘﾝｸﾞ・ﾌﾟﾛﾌｧｲﾙの事前ﾃﾝﾌﾟﾚｰﾄを指定することが可能 (詳細は別項参照)



6.モニタリング・プロファイルを設定・確認できる。「次へ」をクリック。

をクリックしてより詳細な設定ができる

ﾃﾞﾌｫﾙﾄのﾃﾞｰﾀ収集間隔は1分となっている。拡張することを推奨。



7. 「保存期間およびサンプリング間隔」の設定例。OKを押して「モニタリングの構成」へ戻る

「ﾊﾟﾌｫｰﾏﾝｽ・ﾃﾞｰﾀ」は、ｻﾝﾌﾟﾘﾝｸﾞ間隔と保存期間でﾃﾞｰﾀ保持を設定できる。ﾃﾞﾌｫﾙﾄのｻﾝﾌﾟﾘﾝｸﾞ間隔は1分となっている。拡張することを推奨。

「ﾊﾟﾌｫｰﾏﾝｽ・ﾃﾞｰﾀ」は4段階の集約ﾚﾍﾞﾙが決まっていて、各レベルの期間を指定することとなる。集約レベル4は1日単位の荒い情報となるが保管期間は1年間と長くなる。この設定によってﾚﾎﾟｼﾞﾄﾘｰDBの容量見積もりが変化する



8.指定したﾓﾆﾀﾘﾝｸﾞ・ﾌﾟﾛﾌｧｲﾙ

によって、モニター・スイッチ、イベントモニター、メトリックの収集項目が変化する。「次へ」もしくは「終了」をクリック



9.モニタリング許可の構成を確認して、「次へ」をクリック



10.設定をすべて確認して、「終了」をクリック



11.パスワードを入力し「OK」をクリックすると、モニタリングの構成が実行される

正常に構成されたメッセージを確認し「閉じる」をクリック

OPM上のDB(PERFDB)に管理用の表などを作成している



12.データベースが追加されたことを確認し、「タスク・マネージャー」のタブをクリックし、「正常性の要約」を選択



13.追加したデータベースが既にモニターされていることを確認



14.「データベース」のタスクを開き「モニタリングの構成」で構成の変更が可能


Web Console基本画面推移


Web Console基本画面遷移

アクションと確認事項 OPM画面遷移

正常性の要約

アラート

ダッシュボード

データベースごとに問題の所在（ワーニング/アラートの有無）を確認

ワーニング/アラート･イベントの発生時刻、内容を確認

・解析対象の「アクション」から対応したダッシュボード画面へ遷移

解析

原因の解析と対応


Web Console基本画面遷移 – 正常性の要約

• ”正常性の要約”により、データベースごとに大まかな問題のありかを把握する

• 画面左上 “開く↓” より”正常性の要約”を選択

• ”正常性の要約”画面より、どのデーターベースに問題があるかのサマリーを表示。

• それぞれのデータベースについてKey Performance Indicators (KPIs)が表示される

• 問題がある場合、該当KPIにワーニングやアラートが表示される。


Web Console基本画面遷移 – アラート画面

• ”アラート画面”により、ワーニング/

アラート･イベントの発生時刻、内容を確認

• “正常性の要約”のそれぞれのKPIをクリックすると対応する“アラート画面” が表示される

• 更に詳細情報を得るために、

”アクション”タブから関連する

”ダッシュボード”へのリンクへと飛ぶことができる

ダッシュボードへ


Web Console基本画面遷移 – ダッシュボード

• ”ダッシュボード” からグラフによる時系列の遷移を見ることができる。

※具体的なモニタリング実施例は次章「Optim Performance Manager 活用例」を参照


監視しきい値の設定



OPMではデータベース毎にWarning/Criticalのアラートを出すしきい値を決定できる

Webコンソールから設定が可能

1. 「正常性の要約」からデータ・ソースをクリックし、「アラートの構成」を選択



2. 選択されているDBのしきい値が表示される



4. しきい値の値、使用可否を変更する

•不要な監視項目は「有効」列にて「オフ」に設定する

•変更箇所は色違いで判別できる

•設定が完了したら、「適用」をクリック


レポートの作成とエクスポート


レポートの作成とエクスポート – レポート作成

• [タスク・ランチャー] >> [データベースのパフォーマンス・レポートの実行] もしくは

• [開く↓] >> [パフォーマンス] >> [レポート] でレポート作成開始


レポートの作成とエクスポート – レポート作成 • 情報を取得したいデータベースに接続し、＜レポートのタイプの選択＞からレポート

作成したい項目を選択


レポートの作成とエクスポート – レポート作成 • レポートに出力したい情報の条件(取得期間やソート順、ステートメントの数など)を指定し

て、[レポートの生成] ボタンをクリック


レポートの作成とエクスポート – レポート作成/エクスポート • レポートが以下のように表示される

• エクスポートしたい場合は、ファイル形式（xls,ppt,pdf）を右上から選択できる

平均や合計、ソートやロックなど、表示したい計算方法やカテゴリを選択できる


レポートの作成とエクスポート – エクスポート

• エクスポートのファイル形式を選択すると、「プログラムで開く」か「ファイルを保存する」を選択できる


レポートの作成とエクスポート – エクセル形式

• エクセル形式のファイルとしてエクスポート可能

実際のxlsファイルをサンプルレポートとしてザ技術に添付しています。


レポートの作成とエクスポート – PDF形式

• PDF形式のファイルとしてのエクスポート可能

実際のPDFファイルをサンプルレポートとしてザ技術に添付しています。


レポートの作成とエクスポート – パワーポイント形式 • パワーポイント形式のファイルでのエクスポート可能

実際のPPTファイルをサンプルレポートとしてザ技術に添付しています。


Optim Performance Manager 活用例 OPMを利用したデータベースの問題判別


OPMを利用したデータベースの問題判別

• 問題判別例

1. デッドロックの発生と原因の特定

2. データベース稼働状態のヘルス・チェック

3. 非効率なアクセスプランによるリソースの占有

4. APサーバからの3層構造での性能問題分析

3-a. Optim Query Workload Tunerの活用


1.デッドロックの発生と原因の特定



１．デッドロック発生の特定と原因解析

正常性の要約・ロックアラートの発生を検知

ロックのアラート画面・ロックイベントの発生回数や時刻を確認

ロッキングダッシュボード・解析対象のイベントを選択して分析画面へ遷移

分析画面・デッドロックに関係するアプリケーションの詳細を確認

・時系列での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画面へ遷移

最新のデッドロック発生を選択

Analyze画面へ遷移



• デッドロックに関係するアプリケーションの詳細を確認

デッドロックの原因となったアプリケーション名を確認

ここではサンプル・アプリ同士のデッドロックとなっている。

本番環境ではWAS/WASやWAS/バッチ処理といった接続元の情報から両者の関連を類推可能

パネルの最下部にデッドロックの原因となったSQLステートメントが表示される。

この例では、RES_A表への全件スキャンが2つのアプリケーションで重なっている



• 時系列でのSQLステートメント情報を取得 • Statements画面の上半分

• 2つの接続から発行されたSQLが時系列で表示される

時系列

時系列

デッドロックに関連する2つのアプリケーションで実行されたSQLが、時系列に出力される。

ここから、デッドロックに関連する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:


ACTID=4:


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:


ACTID=8:


Participant ID=47

ACTID=3:


ACTID=4:


Participant ID=48


2.データベース稼動状態のヘルス・チェック



2.データベース稼働状態のヘルス・チェック

正常性の要約・Critical/Warningの有無を確認

アラート画面メッセージの傾向を確認

ダッシュボードメッセージの傾向に応じたダッシュボードへ遷移

原因の解析と対応・主要なBuffer Poolのヒット率を確認

・I/O負荷の原因となっている表、表スペースを確認

・原因SQLの改善やBP拡張などを実施




• Health Summaryから大まかな問題の所在を確認

• Health Summary画面では、複数の監視対象に対して横串で問題の所在を確認可能

• データベース毎に決めたしきい値にもとづいてWarningやCriticalのAlertが発行される。

• 個別に設定しない場合、共通のデフォルト値が使用される。 • 「BPヒット率が90%以下でCritical、95%以下でWarning」など

PEDEMOデータベースのMemory UsageやI/O、Workloadにアラートが発生している

PEDEMO以外の2データベースは問題なく稼働中

I/Oのアイコンをクリックし、Alert Summeryへ遷移



• I/O状況の確認

• BPヒット率が50%以下になっており、かつ同期I/OがREAD処理の100％を占める。

詳細を確認するため、

Buffer Pool and I/O Dashboardへ遷移

Buffer Poolヒット率が著しく低くなっており、READの効率が悪い



• Buffer Pool and I/O Dashboard :Buffer Poolsタブ

• バッファープール、表スペース、表のそれぞれのビューで処理負荷の高いオブジェクトをピックアップ可能

• バッファープール => 表スペース => 表とドリルダウンすることで、GUIから問題の所在を絞り込むことが可能

• 下記の例では、バッファープールサイズがデータ量に比して過小となっている

FRUITSバッファープールはサイズが5pageと小さく、ヒット率が10%以下。

また、Logical Readsが毎秒10万弱と、データベース全体の50%以上を占める

デフォルトではヒット率の下位5つまでを表示



• Buffer Pool and I/O Dashboard :Table Spacesタブ

• サイズが過小となっているFRUITSバッファープールに関連する表スペースを一覧

• 2つの表スペースGROWTHとTRADEのうち、GROWTHのBPヒット率が約4%と著しく低い

FRUITSバッファープールに紐付く表スペースのみをリスト

FRUITSバッファープールのREAD活動のうち、90%程度をGROWTH表スペースが占め、そのヒット率は4%程度

さらに絞り込む場合、GROWTH表スペースをドリルダウンする



• Buffer Pool and I/O Dashboard :Tables タブ

• 読み込み量の多いGROWTH表スペースに属する表を一覧

• 表スペース全体のアクセスレコード数が毎分約45000行

• アクセス数の最も多いFRUIT表のアクセスレコード数が毎分約42000行

FRUITSバッファープールのREAD活動のうち、90%程度をGROWTH表スペースが占め、そのヒット率は4%程度

さらに絞り込む場合、GROWTH表スペースをドリルダウンする



• PEDEMOデータベースでのI/O過多への対応

• Buffer Pool and I/O Dashboardの情報から、FRUITSバッファープールのサイズが過小であることが判明したため、拡張を行う。

5page 3000page

FRUITS BP

ALTER BUFFERPOOL

拡張後のHealth Summary

拡張後のDash Board BPヒット率97%に改善


3.非効率なアクセスプランによるリソースの占有




正常性の要約「2.ヘルスチェック」と同様に全体の稼働状況を確認

アクティブSQL OPMからSQLの活動をチェック

アクセスプラン取得問題のあるSQLのアクセスプランを確認

SQLのチューニング実施・アクセスプランの評価

・統計情報最適化の可能性を検討

・索引追加によるチューニングを検討




• 多くのリソースを消費し、他の処理に影響を与えるSQLを発見する

• 最初にデータベース全体の動きをチェックするのは2.と同様

• Health Summaryからアラートをチェック

• BP and I/O Dashboardから特異な表アクセスが発生していないかを確認

Health SummaryからI/O異常を検知し、TableのViewまでドリルダウンした結果、LINTEITEM2表のI/Oが非常に多いことがわかる



• 特異な表アクセスが発見された場合、その表に関連するSQLを検索

• Task ManagerからActive SQL Dashboardへ遷移

• Elapsed TimeやCost、CPU使用量などで上位/下位のSQLを特定可能

LINTEITEM2表に関連するSQLが実行時間（Elapsed Time）の上位に来ている



• 特異な表アクセスが発見された場合、その表に関連するSQLを検索

• 実行中のSQLであれば、OPM画面からのキャンセルも可能

• OPMからOptim Query Workload Tunerへ遷移し、GUIでのSQLチューニングも可能

SQL毎にアプリケーションの詳細や実行状況が取得される

SQLステートメント全文



• SQLのチューニングを実施

• OPM自身はSQLのチューニング機能は持たない

• Optim Query Workload Tunerとの連携が可能

• アクセスプランの取得はOPMからではなく他のツールを使用

• SQLを抽出してCUIでのEXPLAIN取得も可能

• CUIツールであるdb2topから同じSQLを特定し、EXPLAINを崇徳することも可能


3-a. Optim Query Workload Tunerの活用


（参考）Optim Query Workload Tuner概要

DB2のパフォーマンス最適化、開発コストの削減の実現

• 下記の各種アドバイザー機能統合による、パフォーマンスチューニングの生産性向上

• 統計アドバイザー

• 照会アドバイザー

• アクセス・パス・アドバイザー

• 索引アドバイザー

• 注）これまでは上記アドバイザーを個別に立ち上げが必要でした。

• 各アドバイザー機能をEclipseベースのGUIから簡単に呼び出し可能

• 他Optimツール群との機能連携も実現

• Optim Performance Manager

• Optim Database Administrator / Optim Development Studio etc..

• 本製品はOptim Performance Managerとは別製品のため、別途購入する必要があります。


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を実行することが可能



• 索引アドバイザの結果表示と実行

索引アドバイザの詳細項目

推奨索引の各項目説明が羅列される

具体的に実行されるされるDDL文が表示され、内

容確認後実行することが可能



• アドバイス内容の実施の前と後でアクセスプランの比較検証

索引作成前索引作成後



4． APサーバからの3層構造での性能問題分析




正常性の要約・エンドーツーエンドの応答時間の遅延を確認

拡張インサイト・ダッシュボード・解析対象の切り口を選択して分析画面へ遷移

分析画面・応答時間の長いステートメントやクライアントを確認

原因の解析と対応・どの層に時間が要しているかボトルネックの判別

・各製品担当と連携してチューニングを対応

・DBサーバが原因の場合、Query Tunerと連携可



• 最大のエンドツーエンド応答時間が12秒以上かかっていることを確認

• OPMによる監視対象データベースを横串でサマリーする「正常性の要約」からray_tpccデータベースのエンドツーエンド応答時間が10秒を超えていることを確認

応答時間が12秒を要していることを確認

応答時間をクリックし表示される「拡張インサイト・ダッシュボード」に遷移



• ray_tpccの拡張インサイト分析ダッシュボートのトランザクションの詳細を確認

さらに詳細を確認するため、[応答時間の詳細]へ遷移



• 応答時間の詳細をグラフ、SQLステートメント、実際の数値を表示



• 下部にはさらに詳細な応答時間の詳細な数値が表示されている


• 上部のグラフにカーソルを近づけると、取得項目や時刻が確認できる


• [SQLステートメント]タブの単位で[エンドツーエンド応答時間]を選択し、応答時間のいちばん長かったSQLをクリック



• SQLステートメントの詳細領域を表示して、時間のかかったSQLがどこで時間を要していたか、調べることができる

[全体時間の分布]から、クライアントで最も時間を要していたことか、がわかる



• ボトルネックがどこか判別し、対応するチューニングを実施

• OPM自身は各製品のチューニング機能は持たない

• データベース(SQL)がボトルネックであれば、Optim Query Workload Tunerとの連携が可能(前項参照)

• クライアント、ネットワークがボトルネックの場合は、各製品担当と連携して対応する



Optim Performance Manager 活用例 OPMを利用したWLMの構成とモニタリング


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

低優先度

LOAD

SYSDEFAULTSUBCLASS

workloads service subclasses

高優先度ユーザー

USER_H

低優先度ユーザー

USER_L

中優先度ユーザー

USER_M

thresholds

N/A

並行度制限 = 18

並行度制限 = 1

結果行数 < 100000 行

service classes

DS_AUTO_MGMT_SUPER


0.事前準備

• 対象のDBのモニタリング・プロファイ

ルで、ワークロード・マネージャーが選択されていることを確認

DB2 WLM V9.5 が必要


0.事前準備

• 開く → 構成 → ワークロード・マネージャーの構成


0.事前準備

• データベースを選択し接続する

• 接続ユーザー/パスワードを指定


1. WLMの構成：現在のWLM構成を表示

• タイプを選択すると詳細設定が表示される

• 現在のWLM構成をリバースエンジニアリング


2. WLMの構成：推奨WLM構成の作成

• WLMの推奨ベースラインの作成

• WLM未構成の場合、推奨ベースラインの作成を実施する


3. WLMの構成：推奨WLM構成の概要確認

• WLMの推奨ベースラインの概要確認

• WLM未構成の場合、推奨ベースラインの作成を実施する

変更数



• WLMの推奨ベースラインのしきい値確認

• MAINをスーパークラスとしたサブクラスが作成されている



• WLMの推奨ベースラインと現行構成の差異確認

• MAINをスーパークラスとしたサブクラスが作成されている

変更（追加）ありのマーク

変更部分のDDLを表示し、実行可能。他のタグで詳細設定後に実行することも可能。

差異のみの表示も可能


4. WLMの構成：データベース全体のポリシー

• データベース全体のポリシーの確認／修正

• 以下のしきい値に関するデータベース全体のポリシーを確認／修正できる

• 時間制限、行数制限、並行性の制限、接続の制限



• データベース全体のポリシーの確認／修正

• 以下のしきい値に関するデータベース全体のポリシーを確認／修正できる

• 時間制限、行数制限、並行性の制限、接続の制限



• 時間制限、行数制限、並行性の制限、接続の制限の確認／修正



• さらに詳細な設定の確認／修正

• 追加のしきい値、作業クラス、ヒストグラム・テンプレートも追加で確認／修正できる


5. WLMの構成：ワークロードの構成

• ワークロードの確認／修正

• ワークロードの追加、各ワークロードのプロパティー、しきい値の確認／修正ができる


6. WLMの構成：サービス・スーパークラスの構成

• サービス・スーパークラスの確認／修正

• サービス・スーパークラスの追加、各サービス・スーパークラスのプロパティー、しきい値、ワークロードの確認／修正ができる


7. WLMの構成：サービス・サブクラスの構成

• サービス・サブクラスの確認／修正

• 任意のサービス・スーパークラスに関連したサブクラスの確認／追加、各サービス・サブクラスのプロパティー、しきい値、ワークロードの確認／修正ができる


• 「MAIN」のサービス・スーパークラスに6つのサービス・サブクラスが雛形として作成される。

• 用途に応じてそれぞれの優先度設定を行う

• デフォルトはモニター設定のみであり、制限を越えるアクティビティの停止はされない設定となっている

• DML処理

• SQLコストに応じて、5つのサービス・サブクラスが定義されている

• コストに応じたアクティビティ合計時間のしきい値が設定されている

• 並行性のしきい値が設定されているが、使用可能の設定にはなっていない

• Load処理

• Load処理用に１つのサービス・サブクラスが定義されている

TRIVIAL_DML

7. WLMの構成：サービス・サブクラスの構成

MINOR_DML SIMPLE_DML MEDIUM_DML COMPLEX_DML

ETL


8. WLMの構成：パフォーマンス目標の設定

• パフォーマンス目標の確認／修正

• 任意のサービス・サブクラスの並行性の設定をオートノミックに調整する設定ができる

• 「実施タイプ」を「パフォーマンス目標」に変更する


• 画面右上「SQLのプレビューと実行」ボタンを押す

• WLM設定を反映するためのDDLが表示される。

• 確認して実行する。

9. 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

• InfoSphere Optim Performance Manager v5.1 (マニュアル)

http://publib.boulder.ibm.com/infocenter/perfmgmt/v5r1/index.jsp

http://www.redbooks.ibm.com/abstracts/sg247925.html

https://www-304.ibm.com/support/docview.wss?uid=swg27021636



http://www.ibm.com/developerworks/data/bestpractices/workloadmanagement/

http://www-01.ibm.com/software/data/optim/performance-manager-extended-edition/
















http://publib.boulder.ibm.com/infocenter/perfmgmt/v5r1/index.jsp

Documents

パフォーマンス管理ツール構築・利用ガイド · 第3章 DB2パフォーマンス管理ツール構築・利用ガイド 【運用編】 • レポジトリーデータベースの構成

パフォーマンス管理ツール構築・利用ガイド · 第3章 DB2パフォーマンス管理ツール構築・利用ガイド【運用編】 • レポジトリーデータベースの構成