Optim Performance Manager 構築ガイド -...

© 2010 IBM Corporation

Optim Performance Manager 構築ガイド

© 2010 IBM Corporation1

目次

• Optim Performance Manager の概要

• Optim Performance Manager の導入と構成

• OPM導入作業の流れ

• OPMの基本操作

• Optim Performance Manager 活用例

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

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

• 【参考】Optim Performance Manager 導入手順


Optim Performance ManagerOptim Performance Manager Extended Insight

概要


製品の概要

Optim Performance Manager の価値

モニターしたい項目を自由に選択して画面を作成できます。面倒なレポート作成も、項目を選択するだけで可能です。

Optim Performance Manager 画面例

ブラウザーベースでのデータ

ベース状況把握データベース状況のレポートシステムの日常の状態を蓄積

H/W,OS,DB2の問題の発生した時点に遡った分析

DBの使用傾向から、HW資源有効活用をプラン

長期的にデータを保管

パフォーマンス・レポートの容易な作成テキストデータ取得、Excelによる表、グラフ出力作業が不要

Webブラウザ・インターフェースからの簡単操作

V4.1からクライアントソフトなしで操作可能

DB2 WLMフィーチャー機能の設定、監視

日常的に、データベースをモニターすることで実現できます

実現には、Optim Performance ManagerOptim Performance Manager

Extended Insight（オプション）がサポートします

お客様のデータベースシステムについて

システムの日常の状態を監視したいシステムの使用傾向を把握し、今後の拡張プランを立

てたいパフォーマンスが劣化したので原因を調査したい過去の問題について原因の調査をしたいシステム性能レポートを簡単に作成したい

DB2のワークロード管理を行いたいアプリケーションのエンド・ツー・エンドのパフォーマンス

把握を行いたい

と思われたことはありませんか?


Notes:

• Optim Performance Manager(以下OPM) V4.1は、IBM Performance Expert V3.2の後継製品で、名称が変更となっています。

• OPMでは新規アーキテクチャーが組み込まれており、システム正常性の概要や各種パフォーマンス状況のモニタリングが可能なWebインターフェースが準備されています。（WAS V7が同梱されています。）

• Extended Insightフィーチャーを追加することで、以下の機能が新たに利用

できるようになります。

• WebブラウザーインターフェースからのDB2のワークロード管理機能（WLM）の設定およびモニタリング

• Java、Call Level Interface(CLI)アプリケーションのエンド・ツー・エンドのパ

フォーマンスモニタリング


モニタリング機能の特徴1. ドリルダウン形式でのモニタリング機能

問題の認識、原因究明、問題解決が可能

• 概要の表示（ヘルスモニター、ダッシュボード表示）

• 詳細へのドリルダウン（ポップアップによる各種パラメータの表示、グラフ化）

2. 閾値設定により問題が顕在化する前段階での異常検出が可能

3. 複数プラットフォームの一元管理（DB2 for LUW、DB2 for z/OS）

4. 過去のイベントおよびパフォーマンスモニタリングの蓄積

ヘルス・モニター表示

モニター対象の一覧表示が可能で、問題が発生していることが一目で認識可能

各種パラメータのドリルダウン

パラメータ毎の詳細情報へのドリルダウンが可能（何層も詳細化することが可能）


定期監視

･snapshotやlist applications, tablespacesコマンドをシェル化、加工し、テキストで画面表示・db2diag.logをチェックして、エラー発生の有無を確認

OPMの管理画面から、現在のパフォーマンス状況や、履歴情報を踏まえたグラフ表示が可能。継続的なモニター監視で事前に問題トラブルを回避

各モニター対象項目に対する閾値設定が可能で、問題健在化の前に事前対応が可能

DB

2 O

PM

BEFORE AFTER


① 全体的なCPUの使用状況や、ディスク、メモリの使用状況はどうなっているのか？

② 特別なステータスのDB2の接続アプリケーションはいないだろうか？

③ 特別なエラーが発生したり、エラー処理が頻繁に繰り返されていないか？

④ トランザクション数、行読み取り、ロック待ち、ロックタイムアウト、デッドロックなどに異常がないか

特に重いSQLはないか？軽くても頻繁に繰り返されるSQLはないか？

⑤バッファー、パッケージ・キャッシュ、カタログ・キャッシュなどのヒット率はどうか

パフォーマンス分析

db2 list applicationsコマンド

vmstatコマンド

db2diag.logの調査

snapshotモニター

① 全体的なCPUの使用状況や、ディスク、メモリの使用状況はどうなっているのか？

AIXでは、OPMからOSのパラメータ監視が可能に

② DBサーバーから特定のアプリケーションサーバーまで含めた、エンドツーエンドでのパフォーマンス情報を取得

-エンドツーエンドでのアプリ所要時間を時系列グラフ化-DBサーバー内で要した時間、アプリサーバーで要した時間の割合を細かな単位で確認

③特別なエラーが発生したり、エラー処理が頻繁に繰り返されていないか？例外処理の有無から、エラー処理について確認する(ロックタイムアウト、デッドロック)ヒット率はどうか？トップのグラフでヒット率を確認

履歴機能を利用→12:00時点でのパフォーマンスデータを確認可能

特定のコマンドを定期的に実行するコマンド実行結果の加工に時間を要する

snapshotモニターD

B2

OP

M

BEFORE AFTER

こんな時に役立ちます！


レポート資料の作成

蓄積されたスナップショットデータをもとに、レポートを表形式、グラフ化して作成

データベースアクティビティレポート

バッチで定期的に取得したスナップショットデータをもとにエクセルなどで表形式にまとめる

･データベースの統計情報（ソート、ロック、キャッシュヒット率、I/O状況など）

Excelなどにデータを取り込み、レポートを作成

データベース

アプリケーション

DB

2 O

PM

BEFORE AFTER


DB2の構成パラメーターなど（DB/DBマネージャ）のレポーティングも簡単出力


DB2のワークロード管理機能（WLM）の設定＆監視

WLMの設定と監視

サービスクラス、ワークロードの作成、CPU使用率やワークロード優先度設定方法などが煩雑

BEFORE AFTER


DB

2 O

PM

対話形式のGUI操作で簡単設定

ワークロード監視も様々な視点でもグラフ表示が可能


Optim Performance Manager の構成概要

監視対象DB

OPMサーバー

エンドユーザー

クライアント

DB2 for Linux, Unix, Windows

DB2 for z/OS and OS/390

Meta snapshot E2E

レポジトリーDB

DB2 LUW

レポジトリー・サーバー

WebSphereApplication

Server

OPMサーバー

ウェブ・ブラウザーPEクライアント（オプション）


システム構成(本番機とOPMサーバーを分割)•本番機と別サーバーにOPMサーバーを導入

•OPM用のDBをOPMサーバー内に作成•Webベース・インターフェース用のWebSphere App. Serverを導入

•クライアント機はWebブラウザ経由か、PEクライアントを導入•PEクライアントはオプション

Optim Performance Manager


WebSphereApplication ServerWebベース・

コンソール

DB2 インスタンス

モニター対象DB2データベース

(DB2 Database for Linux,UNIX,Windows)

Webインターフェース：Optim Performance Manager- ブラウザ（IE または Firefox）

Performance Expert Client（オプション）

本番機 OPMサーバー


システム構成(本番機にOPMサーバーを共存)•本番機にOPMサーバーを導入

•本番用インスタンスにOPMサーバーを設定すると、OPM用のDBを作成•Webベース・インターフェース用のWebSphere App. Serverを導入

•クライアント機は、Webブラウザ経由かPEクライアントを導入•PEクライアントはオプション



WebSphereApplication ServerWebベース・

コンソール

DB2 インスタンス

本番機

モニター対象DB2データベース

(DB2 Database for Linux,UNIX,Windows)

Webインターフェース：Optim Performance Manager- ブラウザ（IE または Firefox）



システム構成の検討

• OPMサーバーと本番機を分割した場合(p.9)• メリット

• 本番機に与える追加の負荷は、スナップショットモニターをONにする負荷とイベントモニター(デフォルトはデッドロックのみ)の負荷のみになる

• 1台のOPMサーバーで複数の本番機をまとめて監視できる• PEクライアントをOPMサーバーと共存しても、本番機に与える負荷はない• 冗長化の有無をOPMサーバー独自に検討できる

• デメリット• 管理するサーバーが1台増える、H/W導入、メンテナンスコストが1台分増える• イベントモニター用ファイルを2台のサーバー間で共有するための構成が追加で必要

• OPMサーバーと本番機を共存させた場合(p.10)• メリット

• 管理するサーバーが1台でよい、H/W導入、メンテナンスコストも削減できる• イベントモニター用ファイルを2台のサーバー間で共有するための構成が必要ない

• デメリット• 本番機にスナップショット、イベントモニター以外に、OPM用DBにSELECT/INSERT/UPDATEなどのSQL文と、

EXPORT/IMPORTなどのユーティリティを実行する負荷が追加される• 本番機ごとにOPMのセットアップが必要• PEクライアントも共存させると、性能情報のグラフ化、レポーティングなどGUIの処理にかかる負荷も追加されるため、PE

クライアントを別途設けることが必要• 本番機の冗長化構成をとっている場合、OPMサーバーの構成も検討する必要がある


ハードウェア条件：OPM本体

インストール時

稼動時

新規導入WASを利用時導入済みWASを利用時


ソフトウェア要件①：OPMプラットフォームOS要件


ソフトウェア要件②：サポートM/W

• DB2

• WAS

OPMのレポジトリーDB

監視対象DB


ソフトウェア要件③：App.プラットフォームサポート


ソフトウェア要件④：その他S/W

• サポートされるWebブラウザ


○DB2 WLM Feature

○○DB2 WLM Administration

○○Extended Insight (app response time monitoring)

○○○Standard Reporting

○○○Problem Oriented Dashboards

○○○Overview Health Summary

○○○Alerts and Notifications

¥17,450¥16,500¥13,000料金

DB2 Performance Optimization

Feature

Optim Performance Manager Extended

Insight


フィーチャー

注） PAXレートでの1PVU料金

Optim Performance Manager – パッケージ構成情報


Optim Performance Manager の導入と構成


Optim Performance Managerの導入と構成

• OPM導入作業の流れ

• OPMサーバー導入作業

• 監視端末の構成


• OPM サーバーの起動停止

• Web Consoleの起動

• 管理対象DBの追加

• Web Console基本画面遷移


OPM導入作業の流れ

OPMサーバーの導入

OPMサーバー導入作業

OPMサーバー・ライセンスの付与

Extended Insightライセンスの付与

監視対象の追加と構成

監視レベルの決定

OPMサーバーで監視対象を構成

監視しきい値の構成

CIMの導入

Extended Insightの導入と構成

監視端末の構成

Performance Expert Clientの導入

OPMサーバーとして使用するマシンに製品の導入を行う

OPMサーバーのライセンスをActivateする

製品コードは導入済みのため、機能のActivateのみを実施

（オプション）End to Endの応答時間を監視する場合、

サーバー側でExtended InsightのActivateを行う

OPMの監視対象となるサーバーで取得する稼働資料の

レベルを決定する

Web ConsoleもしくはPerformance Expert Clientから

監視対象とするデータベースを追加する

監視対象として追加したデータベースに対して

監視しきい値を設定する

（オプション）監視対象のOS指標（CPU使用率やメモリー使用量など）

を監視する場合、CIMサーバーの導入が必要

（オプション）End to Endの応答時間を監視する場合、

アプリケーション・サーバー上でEIモジュールの導入と

構成を行う

（オプション）監視端末として使用するPC等にクライアント・モジュール

を導入する

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


OPM導入の全体像

Meta snapshot E2E

repository

WebSphere

レポジトリー・サーバー

コンソール・サーバーRS API

Insertmaintain

DB2 LUW ESE

Browser (IE/Firefox)Adobe Flash

Http or Https

-構成-ダッシュボード-アラート-正常性


TCP/IP


監視対象DB監視対象

DB監視対象

DB

TCP/IP TCP/IP

• Optim Performance Manager （サーバー）

• Optim Performance Manager Activate Kit （ライセンス）

• Optim Performance Manager Licence Activation Kit（オプション：Extended InsightのActivate）

• DB2 Performance Expert Client（オプション）

監視端末

WebSphere Application Server

アプリケーション・サーバー

• Optim Performance Manager Extended Insight Client（オプション）

• Common Information Model（オプション:CIMサーバー）

TCP/IP


「OPMサーバー導入作業」の概要• 導入作業の前提

• OPMサーバー導入前にDB2 ESE V9.1以降がインストール済み

• 既存のインスタンスを使用する場合はインスタンスを活動化させておく• OPMインストール時に新規でインスタンスを作成後

• OPMソフトウェアパッケージに同梱されている「DB2 ESE Restricted Use Activation」でインスタンスを活動化• ライセンスセンターからOPMで限定的に使用できるライセンス（パッケージに付属）をインストールする

• メモリ• WASを新規導入する場合、合計で3.5GBの空きメモリが必要

• ディスク• インストール一時用：1100MB• WASを新規で導入：4450MB• その他、パフォーマンス情報の履歴情報

• 作業項目• OPMサーバーの導入

• 具体的な手順は「OPMサーバーの導入ステップ」を参照

• OPMサーバー・ライセンスの付与• 具体的な手順は「OPMサーバーライセンスの付与」を参照

• OPMサーバー上にOPM Extended Insightの導入（オプション）• 具体的な手順は「OPMサーバーでのExtended InsightのActivate」を参照

• 考慮点• OPMパッケージに同梱されているDB2 ESE V9.5をインストールする場合はOPMでのみ使用できる限定的な

ライセンスになるため、必要ならば事前にインストールしておく

• 監視対象となるDBとは別サーバーへの導入が推奨

• 監視対象となるDBはDB2 V9.1以降のESEもしくはWSE• 監視対象となるDBとOPMサーバーで時刻の同期が取れている必要がある


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

• 導入作業の前提• 監視対象となるDBのホスト名、ポート番号、インスタンス名、ログインパスワードの調査

• CIMサーバー導入の前提条件をReadmeで参照（オプション）

• Extended Insightの機能を使用するためには、OPMサーバー上でExtended InsightがActivateされていること（オプション）

• 作業項目• 監視レベルの決定 [次項参照]• OPMサーバー上で監視対象を構成

• 具体的な手順は「OPMサーバー上での監視対象の構成」を参照

• 監視しきい値の設定• 具体的な手順は「監視しきい値の設定」を参照

• CIMの導入（オプション）

• 具体的な手順は「CIMサーバーの導入」を参照

• OPM Extended Insightクライアント・モジュールの導入と構成（オプション）

• 具体的な手順は「OPM EIクライアントモジュールの導入」を参照

• 考慮点• CIMとOPM EIはそれぞれOPMサーバーとは異なるサーバーに導入

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

に導入


監視レベルの決定

SQLの規模と実行数

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

OLPT production

with low overhead

BI production

with low overhead

OLTP production

with all details

BI production

with all details

監視負荷を小さく SQL活動を監視したい監視負荷を小さく

開発環境テスト環境

Development

SystemTest/QA System

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

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

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

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

SQL活動を監視したい

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

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


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

○

○（動的）

○（1）

○

○

○（1）

○

○

Development system

○○○○Extended Server Insight

○（動的）○（動的）○（動的）○（動的）○（動的）○（動的）○（動的）Extended Client Insight

○（2）○（2）○（2）○（2）動的SQL

（サンプリング率[分]）

○○ワークロード・マネージャー

（詳細は別項参照）

○○○○○○○入出力およびディスクスペース


○（1）○（2）○（5）○（1）アクティブSQL及び

接続

（サンプリング率[分]）

○○○○○○ロック


○○○○○○○基本

Test/QA system

SAP production with all details

SAP production with low overhead

BI production with all details

BI production with low overhead

OLTP production with all details

OPTP production with low overhead



××××N/AN/A××既存のデットロックイベントモニターの使用

○○○○×N/A○○デッドロックアラート

×××××N/A××カスタム表スペースの使用

Test/QA system

Development system







1１112N/A11特殊サンプリング率（分）

○○○○○N/A○○ロック待機情報

ステートメント履歴（値あり）

ステートメント履歴

ステートメント履歴

なしステートメント履歴

N/Aステートメント履歴

なしイベント詳細の収集

×××××N/A××ロックタイムアウトアラート

N/AN/AN/AN/A30000N/A3000030000ロック待機しきい値

××××○N/A○○ロックアラート

ロックの詳細



○○○○○×○○表スペース情報の収集

あり

×

Development system

ありなしなしなしN/Aなしなしコンテナー情報

○○○○○○○表情報の収集

Test/QA system







55N/AN/A1N/AN/AN/A統計サンプリング率（分）

30

×

Development system

30N/AN/A10N/AN/AN/A構成サンプリング率（分）

×N/AN/A×N/AN/AN/Aカスタム表スペースの使用

Test/QA system







入出力およびディスクスペースの詳細

ワークロード・マネージャーの詳細


監視対象サーバへの導入作業

• OPMによる監視を行う場合、下記のコンポーネントを導入することでより高度な

監視が可能（オプション）

•CIMサーバ

•UNIX/Linuxへ導入することで、OSリソース（CPU、Memory、I/O）の稼

働資料を取得可能

•Extended Insight

•Websphere上のJDBCアプリケーション、CLIアプリケーションなどを対

象として、トランザクションの応答時間を監視することが可能

•Extended Insightのクライアント・モジュールを導入し、構成を行う


「監視端末の構成」の概要• 導入作業の前提

• 監視端末は2種類

• Webコンソール• Internet Explore もしくはMozilla Firefox• プラグインとしてAdobe Flash Playerが導入されていること

• DB2 performance Manager（オプション）• プラットフォームはWindows もしくはLinux

• 作業項目• 指定のブラウザにログインURLを入力（httpとhttpsの2種類がある）

• http://host_name:9080/optimdatatools/console• https://host_name:9443/optimdatatools/console

• DB2 Performance Expert Clientの導入（オプション）

• 具体的な手順は「DB2 Performance Expert Clientの導入」を参照

• 考慮点• Web コンソール

• 監視結果をWebSphere Application Server を通じてブラウザに表示する• httpsはhttpにSSL/STLプロトコルを使用

• DB2 performance Expert Client• TCP/IPで直接パフォーマンスDB(デフォルトではPERFDB)から情報を取得し、表示する


Optim Performance Manager の基本操作


Optim Performance Manager の基本操作


• OPM サーバーの起動停止

• Web Consoleの起動

• 管理対象DBの追加

• Web Console基本画面遷移


WASの起動・停止

• WASが起動していない場合は起動する。

• LINUX/UNIXの場合：

•OPM_installation_dir/bin ディレクトリからWASstart.sh を実行

• WINDOWSの場合

•OPM_installation_dir¥bin ディレクトリで WASstart.bat を実行

• WASの停止

•LINUX/UNIXの場合

•OPM_installation_dir/bin ディレクトリからWASstop.sh

•WINDOWSの場合

•OPM_installation_dir¥bin ディレクトリで WASstop.bat


OPM Repository Serverの起動

• Optim Repository Serverの起動

• WINDOWSの場合：

•C:¥Program Files¥IBM¥OPM¥RepositoryServer¥bin¥pestart.bat 実行

•UNIX/LINUXの場合：

•OPM_installation_dir/RepositoryServer/bin/pestart 実行

Repository Server が起動していない場

合、画面右上にワーニングが表示される。 → pestart を実行する。

• Optim Repository Serverの停止

•UNIX/LINUXの場合：

•OPM_installation_dir/RepositoryServer/bin/pestop 実行

• WINDOWSの場合：

•C:¥Program Files¥IBM¥OPM¥RepositoryServer¥bin¥pestart.bat 実行


Web Consoleの起動

• 0.OPMのWebコンソールを起動させる

•WINDOWS：

•「すべてのプログラム」⇒「IBM Optim」⇒「IBM Optim Performance Manager」⇒「Web Console」

•ログインユーザーとパスワードを入力

•Linux/Unix：

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

•デフォルトのポートは9080 (HTTPS の場合9443)


監視対象DBの追加と構成

• 1.モニタリング対象のデータベースに接続するために「Manage Database Connections」をク

リック



• 2.「Add」を選択し、モニタリング対象となるデータベースを追加する



• 3.モニタリング対象のDBを追加するために、以下の値を入力する

•データベース接続名：OPM上で識別する名前

•データベース名：実際のデータベース名

•ホスト名：接続したいホストの名前もしくは IPアドレス

•ポート番号：DB2インスタンスのポート番号



• 4.接続テストを行うために、モニタリング対象のDBを所有するインスタンスのユーザー名とパスワードを入力し、「Log In」をクリック

• 5.接続テストが成功したら、「OK」をクリック



• 6.「OK」をクリックし、データベースの接続は完了



• 7.データベースが追加されたことを確認し、「Task Manager」のタブをクリックし、監視したい項目を選択（Performanceの項目から任意に選択、以下では「Health Summary」を選択）



• 8.「Add a Monitored Database」をクリックして、先ほど追加したデータベースを監視できるよ

うにしていく



• 9.「Configure an existing database for monitoring」のラジオボックスをクリックし、「Select a Database」をクリック



• 10.監視したいデータベースを選択して、「Next」をクリック



• 11.ユーザー名（接続したいDBのインスタンス）、パスワード、タイムゾーン、モニタリング構成を選択し「Next」（構成の詳細設定へ）、もしくは「Finish」（構成完了）

•タイムゾーンは「Show Matching」をクリックするとタイムゾーンが絞られて、選択肢を減らせる

•モニタリングの構成では項目を独自に作成する場合は「Create New」を、事前に定義されてものを使用する場合は「Use predefined template」

のラジオボックスをクリックし、環境に合わせたテンプレートを選択する（詳細は別項参照）

•構成は後からでも変更可能（「Managed Database Connection」タブの中の「Configure Monitoring」より）



• 12.モニタリング構成を設定・確認し、「Next」もしくは「Finish」をクリック

• をクリックして、より詳細な設定が可能



• 13.モニタリング許可の構成を確認して、「Next」もしくは「Finish」をクリック



• 14.設定をすべて確認して、「Finish」をクリック



• 15.モニタリングを構成中（数分程度）



• 16.モニタリングの構成は完了

• 17.監視対象のデータベースが追加されたことを確認し、追加と構成は完了


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

Web Console基本画面遷移

Heath Summary

Alert Summary

Dashboard

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

ワーニング/アラート･イベントの発生時

刻、内容を確認

・解析対象のイベントを選択して項目に応じたDashboard画面へ遷移

解析

原因の解析と対応


Web Console基本画面遷移 – Health Summary • ”Health Summary”により、データベースごとに大まかな問題のありかを把握する

• 画面左上 “Task Manager” より”Health Summary”を選択

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

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

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


Web Console基本画面遷移 – Alert Summary

• ”Alart Summary”により、ワーニング/アラート･イベントの発生時刻、

内容を確認

• “Health Summary”のそれぞれのKPIをクリックすると“AlartSummary” が表示される

• 更に詳細情報を得るために、関連する”Dash Board”へのリ

ンクへと飛ぶことができる

Dash Boardへ


Web Console基本画面遷移 – Dash Board

• ”Dash Board” からグラフによる時系列の遷移を見ることができる。

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


監視しきい値の設定



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

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

• 1. 「Health Summary」からNameをクリックする



• 2. 「Configure Alerts」をクリックする



• 3. しきい値を変更したいDBに対して「Connect」をする



• 4. しきい値の設定の一覧が表示され、変更する

•不要な監視項目はEnabled をoffで設定する

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

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


ブランク・ページ


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


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

• 問題判別例

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

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

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



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

Heath Summary ・Locking Alertの発生を検知

LockingのAlert Summary ・Lockingイベントの発生回数や時刻を確認

Locking Dashboard ・解析対象のイベントを選択してAnalyze画面へ遷移

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

・時系列での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=47ACTID=3:


ACTID=4:


Participant ID=48

RES_A表

排他ロック

排他ロック9129321COL2

NOMATTHERsomthingNOMATTHERsomthing

CCCCCBBBBBAAAAA

COL3COL1



• 考えられる対応策

1. SELECTの分離レベルをCurrently Committedへ変更する

• 読込スキャンが排他ロックの解放を待たずに読み飛ばすため、ロック待ちが発生しない

2. 照会と更新のトランザクション・スコープを分離する

• 更新をいったん確定させてから、紹介を行うことでロックの競合を避ける

ACTID=1:


ACTID=8:


Participant ID=47ACTID=3:


ACTID=4:


Participant ID=48



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

Heath Summary ・Critical/Warningの有無を確認

Alert Summary メッセージの傾向を確認

Dashboard メッセージの傾向に応じた Dashboardへ遷移

原因の解析と対応・主要な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%に改善




Heath Summary/Dashboard

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

SQL Activity 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 Tunerへ遷移し、GUIでのSQLチューニングも可能

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

SQLステートメント全文



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

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

• Optim Query Tunerとの連携が可能

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

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

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


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


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

• OPMによるWLM管理概要

• WLMの構成

• Business Process (SERVICE CLASS)の確認

• WORKLOADの作成

• SERVICE SUBCLASS とのマッピング

• THRESHOLDの作成

• モニター

• ヒストグラムの確認


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.事前準備

• Add Database Connections よりSAMPLEデータベースを追加

• Monitoring profile にWorkload Managerが選択されていることを確認


0.事前準備

• Task Manager→ Configuration →Workload Managerの構成


0.事前準備

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

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


1. WLMの構成：Business Processの確認• Business Processの確認

• トップ・レベルのランタイム環境 (SERVICE CLASS)

• デフォルトでDS_AUTO_MGMT_SUPERが作成されている

Business Processタブ


2. WLMの構成：WORKLOADの作成

• Workloadの作成＜アクティビティーをどのような属性で分類するか＞

• Workloadsタブを選択

• Workloadを追加する

• Addボタンを押して、WORKLOADを追加する。ここでは”WL_H” （高優先度用WORKLOAD)を追加する

Workloadsタブ

Addボタン



• Workloadを追加する

• ADDボタンをクリックして、WL_H（高優先度用WORKLOAD)を追加する。



• 追加したWORKOADの特性を設定する

• Connection Attribute

• WORKLOADを識別する属性を選

択

•ここでは接続ユーザーで分類する

•ADDボタンを押して、USER_ID=USER_Hを設定

•Concurrency/Priority

•Urgent work: high priority, no limitsを選択

•デフォルトで作成されている高優先度（緊急ワーク）のSERVICE SUBCLASSにマッ

ピングされる

User IDを選

択してAddする



• 同様にWL_M（中優先度用WORKLOAD)を追加する

• USER_ID=USER_Mを設定

• Concurrency/Priority： Ordinary workを設定

• デフォルトで作成されている中優先度（一般ワーク用）のSERVICE SUBCLASSにマッピングされる

• 同様にWL_L（低優先度用WORKLOAD)を追加する

• USER_ID=USER_Lを設定

• Concurrency/Priority： Batch jobsを設定

• デフォルトで作成されている低優先度（バッチ用）のSERVICE SUBCLASSにマッピングされる

作成したWorkloadが表示さ

れる。


3. WLMの構成：SERVICE SUBCLASSの設定

• Costs and Concurrency タブを選択

•ここで、それぞれのサービス・サブクラスに対して実行並行度制限などを設定する。

Costs and Concurrency タブ



• 高優先度、緊急ワーク用： (DS_HIGH_PRI_SUBCLASS)• COSTによる分類なし、並行度制御なし

• 中優先度、通常ワーク用: (DS_MED_CONC_SUBCLASS)• 並行度制御あり

• デフォルトで利用される

• 低優先度、バッチジョブ用： (DS_LOW_CONC_SUBCLASS)

• 並行度制御あり

• 一定のコストを超える場合は、Ordinary work から Batch jobsのサブクラ

スにマップすることも可能

• LOAD用：（DS_LOAD_SUBCLASS)• LOAD処理が実行される

• 並行度制御あり

Urgent Jobs (High Priority)

Batch jobs (Limited Concurrency)

LOAD

Ordinary Work(Low Cost SQL, DDL)

• デフォルトで４つのSERVICE SUBCLASSが雛形として作成される。用途に応じてそれぞれの優先度

設定を行う



• SERVICE SUBCLASSの設定例

• DS_LOW_CONC_SUBCLASSの実行並行度制限(Concurrency Limit)を設定する。

•この例では低優先度処理については、1並行のみ実行可能

実行並行度の設定


4. WLMの構成：THRESHOLDの設定

• Thresholds タブを選択

•それぞれのSERVICE SUBCLASSに閾値を設定する。設定可能な閾値は以下。

• Activity total time / Estimated SQL cost / CPU time

• SQL rows return / SQL rows read

• SQL temp space

Thresholdsタブ


• Thresholds を設定する (設定例)

•DS_LOW_CONC_SUBCLASSを選択

•Thresholds of the Service Subclass セクションの Rows Limitタブを選択

•Threshold type: SQL rows returned に100000を指定

•しきい値を越えた場合のアクションをチェック

•Monitor the activities that exceeded the limit

•Stop the activities that exceeded the limit

•Enable threshold

4. WLMの構成：THRESHOLDの設定

結果行が100000を超えた

場合にアクティビティを停止、Thresholdイベン

トモニターに記録


5. WLM 設定DDLの実行

• 画面右上 Preview and Run SQL ボタンを押す

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

• 確認して実行する。


6. WLM モニター

• サービス・サブクラスごとのヒストグラム（分布図）を確認する。

• Activity total time / Activity queue time の分布が確認できる。

•Costs and Concurrency タブ、下側のセクション

• サービス・サブクラスごとに確認可能

• 特定の時間帯での状況を把握可能

サービス･サブクラスごとに、実行時間の長いアクティビティの存在有無や分布を確認できる。

確認したい時間帯を選択

ポインタを合わせると詳細が表示される。Bin Countの件数が、Bin BottomからBin Top（milliseconds）の範

囲で実行されている。


6. WLM モニター

• 現在のアクティビティの接続属性を確認

• WORKLOADSタブ → 「View Current Activities」ボタン

現在のアクティビティー、アプリケーション名、所属するWORKLOADが分かる。


• 構成例2．同じ接続ユーザーの処理をCostによって異なる優先度の実行環境で実行する

• 接続ユーザーによって分類し、更にCostによって分類（WORK ACTION SETの利用）

• （例） USER_Mからの接続で行われるアクティビティーについて

• コストが10000以下であれば、中優先度サービス・サブクラスで実行

• コストが10000以上であれば、低優先度サービス・サブクラスで実行

Urgent work

高優先度

LOAD

SYSDEFAULTSUBCLASS

workloadsservice subclasses

中優先度ユーザーUSER_M

thresholds

N/A

並行度制限 = 18

並行度制限 = 1

結果行数 < 100000 行

DS_AUTO_MGMT_SUPER

参考：その他WLM構成例

Costtype

Ordinary Work

中優先度

Batch jobs

低優先度> 10000

service classes


参考：その他WLM構成例

• Workloads タブ

• Concurrency/PriorityをEstimated SQL cost に設定変更

•WORKLOAD：WL_MがSERVICECLASS:DS_AUTO_MGMT_SUPER にマップされる。

•この次にアクティビティーの挙動によって(WORK ACTION SETによって）更に配下

のサブクラスにマップされる。

• Costs and Concurrency タブ

• Max. Costを指定

•COSTが10000以内のアクティビティについては中

優先度のサービスクラスDS_MED_CONC_SUBCLASSにマップされる。

•COSTが10000以上のアクティビティは低優先度

サービス・サブクラス：DS_LOW_CONC_SUBCLASSにマップされる。

•内部的にWORK CLASS SETの定義を変更してい

る。


参考情報

• Best Practices: DB2 Workload Managementhttp://www.ibm.com/developerworks/data/bestpractices/workloadmanagement/

• What's new in Optim Performance Manager Extended Edition for DB2 for Linux, UNIX, and Windows http://www.ibm.com/developerworks/data/library/techarticle/dm-1004optimperformance/index.html

• 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, 2010http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=Demo&htmlfid=897/ENUS210-143


【参考】Optim Performance Manager 導入手順


【参考】OPMサーバーの導入ステップ


OPMサーバーの導入ステップ

• 1. Optim Performance Manager インストーラーを起動

• 2. 言語を選択したら、「OK」をクリック



• 3. インストールのステップが表示される

• 4. 「Next」をクリック



• 5. 「Install the Try and Buy edition」を選択し、「Next」をクリック

•Licensed Editionは後からでも、インストール可能



• 6. ソフトウェア・ライセンス条件を読んで、「I accept the terms int the license agreement」のチェックボックスをクリックし、「Next」をクリック



• 7. 「Install the product on this computer」を選択し、「Next」をクリック



• 8. OPMのインストールディレクトリを選択し、「Next」をクリック

•Window でのデフォルトは C:¥Program Files¥IBM¥OPM

•Linuxでのデフォルトは /opt/IBM/OPM



• 9. 「Typical Installation」を選択し、「Next」をクリック



• 10. 「Install a new copy of WebSphere Application Server」を選択し、「Next」をクリック

•WebSphere Application Serverのコピーがすでにインストールされている場合は、「Using an existing copy of WebSphere Application Server」を選択し、どのWASを使用するのかを選択する



• 11. 「Selected an existing DB2 instance」からリポジトリを管理するインスタンスを選択し、「Next」をクリック

•モニタリング対象のインスタンスとそれを管理するインスタンスは分離する

•インスタンスが作成されていない場合は「Create a new DB2 instance」で新たにインスタンスを作成



• 12. インスタンス・オーナーのユーザー名とパスワードを入力し、「Next」をクリック



• 13. リポジトリー・データベースを作成（数分程度）



• 14. インストールする内容を確認し、「Install」をクリック



• 15. インストールが完了するまでしばらく待ちます（数十分～1時間程度）



• 16.OPMを自動的に起動させるかを選択し、「Next」をクリック

•手動でOPMサーバーを起動（停止）させる場合

インストールディレクトリ/RepositoryServer/bin/pestart.bat (pestop.bat)



• 17.WASを起動させるかを選択し、「Next」をクリック

•WASを手動で起動（停止）させる場合

インストールディレクトリ/bin/WASstart.bat (WASstop.bat)



• 18.OPMのWEBインターフェースを開くかを選択し、「Done」をクリックしてインストール完了

•https ⇒ http と SSL/TSLプロトコルで接続


【参考】OPMサーバーライセンスの付与


OPMサーバーライセンスの付与

• 1. インストーラーを起動




• 3.「Next」をクリック



• 5. インストール情報を確認し、「Install」をクリック



• 6. インストールが正常に完了したことを確認し、「Done」をクリックしてインストール終了


【参考】 OPMサーバーでのExtended InsightのActivate


OPMサーバーでのExtended InsightのActivate

• 1. activate_EI.exeをクリックし、インストーラーを起動




• 3.「Activate the Extended Insight license」と「Configure communication property」のチェックボックスを選択して、「Next」をクリック



• 4.OPMサーバーのインストールディレクトリであることを確認して、「Next」をクリック



• 6. OPMサーバーのホスト名とポート番号を入力し、「Next」をクリック

•ホスト名：同じホスト名であればLOCALHOSTを入力

•ポート番号：使用されていないポート番号を使用



• 7.構成情報を確認して、「Next」をクリック



• 8.インストール中（数分程度）


【参考】CIMサーバーの導入（オプション）


CIMサーバーの導入（AIX）

• 1. CIMのモジュールをダウンロード

注：readmeを読んで、インストール要件を満たしているか確認する

https://www14.software.ibm.com/webapp/iwm/web/reg/download.do?source=aixpegcim&S_PKG=dl&lang=en_US


CIMサーバーの導入（AIX)

• 2. モジュールを展開し、次の３つのファイルがあることを確認する

•sysmgt.cim.providers

•sysmgt.cim.smisproviders

•Sysmgt.cimserver.pegasus

• 3. smitの「Software Installation and Maintenance」からインストールを行う



• 4. 「Install and Update Software」 ⇒ 「Install Software」 ⇒ CIMのモジュールがあるディレクトリを入力 ⇒ 「SOFTWARE to install」でF4を押して、インストールを開始する



• 5. インストールの完了を確認し、CIMサーバーの導入は終了


【参考】OPM EI クライアントモジュールのActivation（オプション）


OPM EI クライアントモジュールのActivation （オプション）





• 4. インストールディレクトリを確認し、「Next」をクリック



• 6. インストール情報中（数分程度）



• 7. 「Open the configuration tool」のチェックボックスをはずす

• 8.「Done」をクリックして、インストール完了


【参考】DB2 Performance Expert Clientの導入（オプション）


DB2 Performance Expertの導入（オプション）





• 3.「Next」をクリック



• 5. プラットフォームを選択し、「Next」をクリック



• 6. 「Typical」を選択し、「Next」をクリック



• 6. インストールディレクトリを確認し、「Next」をクリック



• 7. インストール中（数分程度）

Optim Performance Manager 構築ガイド -...

Documents

Transcript of Optim Performance Manager 構築ガイド -...