Comments
Description
Transcript
5-1. - IBM
5. モニターとチューニング 1 ・ＳＱＬ＆ＳＱＬ/PL ・Ｃ，Ｊａｖａ，etc. ・統合開発環境 システム構築の流れとDB2 要件定義 ・接続形態 ・ユーザー認証 ・セキュリティ ・耐障害性構成 アプリケーション 設計者／開発者 ・コードページ ・ソート順 ･スキーマ ・Diskへの配置 ・表・索引の設計 データベース 設計者／管理者 ・障害回復 ・再編成 /統計情報更新 ・監視 システム要件 の整理 データ項目の 標準化 設計 開発 テスト 本番運用 システム構成 の選択 アプリケーショ ン設計 プログラミング・ インターフェー スの選択 データベース 設計 運用設計 パフォーマンス を考慮した プログラミング 統合テスト キャパシティ、 パフォーマンス に関する検証 テスト モニターと チューニング ・チューニング手法 概要 ・チューニングに 役立つツール 2 2 DB管理者の仕事のなかでのチューニング作業 要件定義 • 論理設計 物理設計 ｺｰﾃﾞｨﾝｸﾞ 単体ﾃｽﾄ 統合･ｼｽﾃﾑ ﾃｽﾄ 本番稼働 パフォーマンス 目標設定 DB管理者 ﾓﾃﾞﾘﾝｸﾞ DB物理設計 ﾊﾟﾌｫｰﾏﾝｽ･ﾁｭｰﾆﾝｸﾞ ｷｬﾊﾟｼﾃｨｰ ﾌﾟﾗﾝﾆﾝｸﾞ DB定義(表､索引 etc) 配置 ﾊﾟﾗﾒｰﾀ設定 SQL標準作成 問題判別 DB運用設計 監視 3 パフォーマンス・チューニングとは 下記を調整することにより、業務要件に定められたパフォーマンス（ トランザ クション・スループットやレスポンス・タイム）を達成する/改善すること – システム構成 – データベース論理設計 – データベース物理設計 • データベース構成パラメータ – アプリケーション – ＳＱＬ文 早期にパフォーマンス・チューニング上困難なものが無いか確認。早期であ ればアクションの幅は広く取れる 4 DB管理者の本番稼動前最後のハードル 最後の大きなハードルは、パフォーマンス・チューニング – 物理設計の最適化（パラメータ変更やインデックス追加・修正など）が主な 作業 • システム・テスト・フェーズでは、システム構成や、論理設計の変更まで実施す ることは困難 • プロジェクトの早期フェーズで、システム構成、論理設計や業務設計のパフォー マンスに与える影響を調査すべき – 本番稼動後のチューニングも容易にするような、運用設計も重要 • テストフェーズで使用していないツールは、本番環境でなかなか使えない • サービスレベルを保つためにチューニングが必要になる場合も存在 – 定常監視とリンクする必要性 > チューニングの必要性判断 > チューニングの効果判定 要件定義 DB管理者 論理設計 ﾓﾃﾞﾘﾝｸﾞ 物理設計 DB物理設計 ｺｰﾃﾞｨﾝｸﾞ 単体ﾃｽﾄ 統合･ｼｽﾃﾑ ﾃｽﾄ 本番稼働 ﾊﾟﾌｫｰﾏﾝｽ･ﾁｭｰﾆﾝｸﾞ 5 5-1. データベースのモニター DB2付属ツール：モニター･ツールの種類 – アクセス・プラン表示ツール • Visual Explain – GUIツール • db2exfmt – EXPLAIN表の情報を解釈しやすい書式(テキスト形式)で表示 – パフォーマンス測定ツール • スナップショット・モニター ※ DB2の現在の活動状況を知る – 現在いくつのアプリケーションがデータベースに接続しているのか？ – デッドロックはどれくらい発生しているのか？ • イベント・モニター ※ 各イベントについて調査する – アプリケーションの実行時間が長い。どこに時間がかかっているのか？ – デッドロックが発生した。どこに原因があるのか？ • db2batch – ベンチマークツールコマンド • db2pd – モニター＆トラブルシューティングコマンド • メモリー･トラッカー(db2mtkrコマンド) – メモリー使用状況 • 他 6 5-1. データベースのモニター EXPLAIN機能実行手順 EXPLAIN表を使用するEXPLAIN機能 EXPLAIN.DDLの実行 最初に一度だけ実行する – EXPLAIN表の作成 – EXPLAIN情報のEXPLAIN表への書き出し • EXPLAINコマンド • EXPLAIN特殊レジスター • EXPLAIN BINDオプション • VISUAL EXPLAIN – EXPLAIN表に戻された結果の検証 • VISUAL EXPLAIN • db2exfmt EXPLAINファシリティ SQLコンパイラーの一部で、 静的/動的SQL文のアクセス・ プラン情報をEXPLAIN表に書 き出すことができる EXPLAINツール EXPLAIN情報を元にアクセス･プラン を解析するためのツール EXPLAIN表を使用しないEXPLAIN機能 – db2expln – dynexpln 7 5-1. データベースのモニター Visual Explain： 使いやすくて分かりやすい GUI – アクセス・プランの分析 – Explain 表からの最適化プログラム情報を分析 詳細情報 ・CPUコスト ・I/Oコスト ・バッファープール 使用ページ数 ・結合タイプ など ボックスをダブルクリック 詳細情報取得 8 (参考）db2exfmtツールによるアクセス・プランの確認(動的SQL) db2exfmtツールを使用してEXPLAIN情報を取得する db2 –tvf c:¥sqllib¥misc¥explain.ddl ① db2 set current explain mode explain ② db2 –tvf XXX.sql ③ db2 set current explain mode no ④ db2exfmt –d データベース名 –g TIC -1 –o XXX.exfmt ⑤ ①事前準備：EXPLAIN.DDLの実行 – 最初の１回のみ実行 ②EXPLAINモードの設定ON ③EXPLAINを取得するSQLの発行 ④EXPLAINモードの設定OFF ⑤EXPLAIN情報のフォーマット – – -d データベース名 -g グラフに関するオプションを指定 • • • – – T 各オペレーターの下に合計コストを表示 I 各オペレーターの下に入出力コストを表示 C 各オペレーターの下に予期出力のカーディナリティを表示 -1 最新の Explain 要求を取得、またその他のオプションに関してデフォルトを使用 (cf. 「-w タイムスタンプ」で 時間を指定してExplain要求を取得) -o 出力先ファイル名 9 参考：db2exfmt (1/2) ④SQL ①ヘッダー 実行SQL: select firstnme, lastname from employee where salary > 40000 ②DB情報 ⑤アクセスプラン オプティマイザーによっ て書き直されたSQL アクセスプラン 合計コスト ③パッケージ情報 詳細情報の番号 ロック分離レベル 10 参考：db2exfmt (2/2) オペレーター毎の詳細 ⑥オペレーター毎の詳細 全体の合計コスト ここまでの合計コスト このオペレータへの入力 プリフェッチの有無 ここでの入力行数 11 5-1. データベースのモニター スナップショット･モニター – スナップショット・モニターは、DB2が提供するモニター / 解析ツールのひとつ • 特定時点のデータベース活動状況を取得する – バッファープールなどの資源の使用状況 – データベースへの接続数 – デッドロック発生数 参考） イベント・モニター ： 特定の時間内に発生したイベントを記録 EXPLAIN機能 ： SQL文のアクセス・プランに関する情報を取得 – 取得手順 • 取得したい対象のMONITOR SWITCHESの更新 – – – – – – BUFFERPOOL（バッファープールのヒット率など） LOCK（各アプリケーションの具体的なロック取得情報） SORT STATEMENT TABLE UOW • 必要なスイッチをONにした後、get snapshot for xxx（取得対象） で取得 12 5-1. データベースのモニター スナップショット・モニターの出力例 バッファー・プール・データ論理読み取り バッファー・プール・データ物理読み取り 非同期プール・データ・ページ読み取り バッファー・プール・データ書き込み 非同期プール・データ・ページ書き込み バッファー・プール索引論理読み取り バッファー・プール索引物理読み取り 非同期プール索引ページ読み取り バッファー・プール索引書き込み 非同期プール索引ページ書き込み バッファー・プール読み取り時間の合計 (ms) バッファー・プール書き込み時間の合計 (ms) ・・・ = = = = = = = = = = = = 8 0 0 0 0 0 0 0 0 0 0 0 論理読み取り バッファープールから、データやイン デックスを読み込んだ回数 物理読み取り ディスクI/Oを伴うバッファープールの 読み込み回数 バッファー・ヒット率(%) (1-(物理読み取り/論理読み取り))*100 バッファープール・ヒット率が低い場合は、バッファープールを大きくするな ど設定値を変更する バッファープールにデータがキャッシュされていない場合は、一度ディスクから 読み込みバッファープールに読み込む時間が余分に発生する 13 5-1. データベースのモニター 新しいスナップショットのビュー活用 スナップショットとビューの対応表 （一部抜粋） スナップショット ビュー SYSIBMADM.SNAPDB データベース 表スペース データベースのデータベース・レベル情報およびカウンター SYSIBMADM.SNAPSTORAGE_PATH データベースの自動ストレージ・パス情報 S データベース・レベルの表スペース・アクティビティーに関する SYSIBMADM.SNAPTBSP 情報。また、データベースに接続された各アプリケーションの アプリケーション・レベル、およびデータベースに接続された各 アプリケーションがアクセスしている各表スペースの表スペー ス・レベルの情報 表スペース構成に関する情報 SYSIBMADM.SNAPTBSP_PART SYSIBMADM.SNAPCONTAINER SYSIBMADM.SNAPTAB 表 動的SQL キャッシュ 説明 SYSIBMADM.SNAPDYN_SQL 表スペース・レベルでの表スペース・コンテナー構成に関する 情報 データベースに接続された各アプリケーションのデータベー ス・レベルとアプリケーション・レベルの表アクティビティー情報。 データベースに接続されたアプリケーションが アクセスした 各 表の表レベルの表アクティビティー情報 データベースの SQL ステートメント・キャッシュからのステート メント情報 ビューをselectすることにより、データを絞り込んだり、ソートした結果を 簡単にCSVファイルに出力可能 14 5-1. データベースのモニター イベント・モニター – イベント・モニターは、指定されたイベントの発生時に情報を収集する • イベントの例 – デッドロック検出時（デフォルト） – 接続終了時 – SQLステートメント終了時 – 取得手順 • 取得したいイベントに対してイベント・モニターを登録して開始する。停止後、取得した イベント・トレースをフォーマットして調査する。 create event monitor evmon1 for statements write to file …… set event monitor evmon1 state 1 イベント･トレースを採取したい処理を実行 set event monitor evmon1 state 0 db2evmonコマンドでイベント・トレースをフォーマット 、あるいは GUIのイベント・ アナライザーを利用 drop event monitor evmon1 15 DB2 9.7で導入された新たなモニタリング基盤 モニタリングのための基盤が大きく刷新された – モニタースイッチを必要としないモニタリング機能 • モニタースイッチに対するこれまでのポリシー – 基本はOFF、必要に応じてONに変更 – モニタイングスイッチは、インスタンス単位で設定 • 新しいインフラでのポリシー – デフォルトでBASEスコープで取得、少しでも負荷を下げたい場合に NONEに変更 – 新たなモニタリング要素の名称は「メトリック（metric）」 • 大きくリクエスト・メトリック、アクティビティ・メトリック、オブジェクト・メトリッ クの3種類に分類できる。 – 取得インターフェースは表関数とイベントモニター • 必要な情報のみ特定して収集可能 • スナップショットAPIを使用しないためフォーマットのオーバーヘッドを回 避可能 16 DB2 9.7の”メトリック” 新しいシステム・モニタリングのインフラの提供 DB2 9.7から”メトリック”とよぶ新しいシステム・モニタリングのインフラが提供さ れて、新しい表関数や新しいイベント･モニターの仕組みを提供 – 新しいモニタリングのインフラは、従来のSystem Monitorとは独立したインフ ラを提供 • インメモリに展開された負荷の少ない仕組み • 既存のsnapshotやmonitor switchとは別の仕組み • データベースレベルのsnapshotの既存の仕組みを置き換え、システム性能情報の 提供はsnapshotからメトリックへ移行していく方針 – DB29.7でsnapshotの機能がなくなるわけではない • DBM等のインスタンスレベルの情報を取得するためにはsnapshotが必要 システム・メトリック アクティビティー･メトリック データ･オブジェクト・メトリック 17 モニタリング情報取得のために追加されたコマンド群 モニタリング表関数 – SQLの形式で関数をコールし、モニタリング情報を取得 – 大きく3種類に分類できる イベントモニター – 2つのイベントモニターが追加された Data object level Package cache statement level System level MON_GET_SERVICE_SUBCLASS MON_GET_WORKLOAD MON_GET_PKG_CACHE_STMT Activity level MON_GET_CONNECTION MON_GET_ACTIVITY_DETAILS MON_GET_UNIT_OF_WORK WORKLOAD SERVICE CLASS MON_GET_TABLE MON_GET_INDEX MON_GET_BUFFERPOOL MON_GET_TABLESPACE MON_GET_CONTAINER MON_GET_EXTENT_MOVEMENT_STATUS Buffer pool Index Tablespac e Table Table Index WORKLOAD Event monitor SERVICE CLASS Container EVENT MONTIOR for Locking EVENT MONITOR for Unit of work 18 システム・メトリックとデータ・オブジェクト・メトリックの設定 新しいDB構成パラメーターでメトリックのモニタリングを設定 Request metrics Object metrics (MON_REQ_METRICS) = BASE (MON_OBJ_METRICS) = BASE MON_REQ_METRICS MON_OBJ_METRICS システム レベル データ・オブジェクト レベル MON_GET_SERVICE_SUBCLASS MON_GET_TABLE MON_GET_WORKLOAD MON_GET_INDEX MON_GET_BUFFERPOOL MON_GET_CONNECTION MON_GET_TABLESPACE MON_GET_UNIT_OF_WORK MON_GET_CONTAINER MON_GET_EXTENT_MOVEMENT_STATUS WORKLOAD WORKLOAD SERVICE CLASS SERVICE CLASS Buff er pool Index Tablespac e Table Table Index Container 19 （参考）メトリックによる簡易パフォーマンステスト – TPCH95 Select • DB2 9.5のデフォルトのモニターリング設定 デフォルトのデータベース・モニター・スイッチ バッファー・プール ロック ソート ステートメント 表 タイム・スタンプ 作業単位 インスタンスとデータベースの状況をモニター – (DFT_MON_BUFPOOL) = (DFT_MON_LOCK) = (DFT_MON_SORT) = (DFT_MON_STMT) = (DFT_MON_TABLE) = (DFT_MON_TIMESTAMP) = (DFT_MON_UOW) = (HEALTH_MON) OFF OFF OFF OFF OFF ON OFF = ON TPCH97 Select Metrics NONE • DB2 9.7でデフォルトのモニタースイッチで、メトリックをNONEに設定 モニター収集設定 要求メトリック (MON_REQ_METRICS) = NONE アクティビティー・メトリック (MON_ACT_METRICS) = NONE オブジェクト・メトリック (MON_OBJ_METRICS) = NONE 作業単位イベント (MON_UOW_DATA) = NONE ロック・タイムアウト・イベント (MON_LOCKTIMEOUT) = NONE デッドロック・イベント (MON_DEADLOCK) = WITHOUT_HIST ロック待機イベント (MON_LOCKWAIT) = NONE ロック待機イベントのしきい値 (MON_LW_THRESH) = 5000000 – TPCH97 Select Metrics BASE • DB2 9.7でデフォルトのモニタースイッチで、メトリックスをBASEに設定 モニター収集設定 要求メトリック (MON_REQ_METRICS) = BASE アクティビティー・メトリック (MON_ACT_METRICS) = BASE オブジェクト・メトリック (MON_OBJ_METRICS) = BASE 作業単位イベント (MON_UOW_DATA) = NONE ロック・タイムアウト・イベント (MON_LOCKTIMEOUT) = NONE デッドロック・イベント (MON_DEADLOCK) = WITHOUT_HIST ロック待機イベント (MON_LOCKWAIT) = NONE ロック待機イベントのしきい値 (MON_LW_THRESH) = 5000000 20 （参考）簡易パフォーマンステスト D F T_M ON OF F 80000 70000 60000 TPS 50000 40000 30000 20000 TPCH95 Select TPCH97 Select Metrics N one TPCH97 Select Metrics B as e 10000 300 250 200 150 100 50 0 0 Total U s er ユーザー数が100を超えるとパフォーマンスの差が現れはじめます DB2 9.7 ではパフォーマンスが改善されていることから DB2 9.5 よりもTPSが良いことがわかります。 メトリックNONEとBASEでは、NONEの方がTPSが良いですが、いずれの場合もDB2 9.5よりもTPSが良いことがわかります。 メトリックBASEでも、ユーザー数が100未満の環境であれば、さほど影響の違いが無いことがわかります。 21 5-1. データベースのモニター db2batch ベンチマーク・ツール・コマンド DB2が提供するベンチマーク・ツール – ファイルより読み取ったSQLステートメント（複数可能）を実行し、結果セットを SQL 戻し、処理時間、ならびにパフォーマンス情報を収集 入力ファイル オプションによって制御 – 出力ファイルや標準出力に送るフェッチ済み行の数 – 応答セットからフェッチする行の数 db2batch （SQL実行） – パフォーマンス情報のレベル • • • • 経過時間、CPU時間 結果セットの出力の表示 スナップショット・モニター情報 Explainモードの設定 DB2 パフォーマンス情報 実行時間 / 結果セット 出力ファイル 標準出力 22 5-1. データベースのモニター db2batch 出力例 db2batch -d DB名 –f 入力SQLファイル名 –o p 5 r 0 の結果例 取得するパフォーマンス情報のレベル * タイム・スタンプ: Wed Dec 13 2006 11:14:01 東京 (標準時) --------------------------------------------* SQL ステートメント番号 1: select count(*) from employee where empno between '000010' and '200010'; 1 ----------* 1 行取り出され、0 行出力されました。 実行時間 * 経過時間: 0.000992 秒 モニター情報 インスタンス名 ノード名 ノード・タイプ スナップショット・タイム・スタンプ = DB2 出力行数 TIMESTAMP SQLステートメント インスタンス名 = = ローカルとリモート・クライアントを持つ Enterprise Server Edition = 2005-12-13 11:14:01.450458 データベース・マネージャー・スナップショット スナップショット・モニターからの出力（内容は省略） （省略） * サマリー表: タイプ 番号 反復回数 合計回数 最小回数 最大回数 算術平均 幾何平均 行が取り出されました 行が出力されました -------------- ----------- ----------- -------------- -------------- -------------- -------------- -------------- -------------------ステートメント 1 1 0.000992 0.000992 0.000992 0.000992 0.000992 1 0 * 合計項目数: 1 * 合計時間: 0.000992 秒 * 最小時間: 0.000992 秒 実行時間サマリー * 最大時間: 0.000992 秒 * 算術平均時間: 0.000992 秒 * 幾何平均時間: 0.000992 秒 23 5-1. データベースのモニター db2pd モニター及びトラブル･シューティング用のツール – 1つのコマンドで、既存のDB2コマンドやその他のコマンドと同様の情報を取得可能 – DB2が使用しているメモリー上の情報を読み取る – スナップショット・モニターと異なり、パフォーマンスに影響を与えない • スナップショット･モニターやイベント･モニターと異なり内部的にロックやラッチを 取らない。したがって、高速に実行することができ、かつ、データベース本体へ 与える影響が小さい。 – データベースに接続せずに利用可能 – ハングやローダウン時の資料収集も可能 • DB2エンジンの外で実行させるので、DB2エンジンがハングしている状態でも 使用可能 – vmstat,iostatのように実行する間隔と回数を指定して実行することができる。 24 5-1. データベースのモニター db2pdで取得できる情報 アプリケーション -applications メモリー･プール -mempools エージェント -agents メモリー･セット -memsets トランザクション -transactions DBM構成パラメーター -dbmcfg バッファープール -bufferpools DB構成パラメーター -dbcfg ログ -logs カタログ・キャッシュ -catalogcache ロック -locks 表と索引 -tcbstats 表スペース -tablespaces 表の再編成 -reorg 動的SQL -dynamic リカバリー -recovery 静的SQL -static REOPT -reopt FCM -fcm OS -osinfo list applications 対応するDB2コマンド – db2 get snapshot – db2 get dbm cfg – db2 list applications – db2 get db cfg – db2mtrk snapshot db2mtrk 等 db2pd 25 5-1. データベースのモニター db2pd 実行例 -utilities ユーティリティー、実行中のジョブに関する情報を取得する C:¥TAKUMI>db2pd -utilities -db sample Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:57:50 Utilities: Address ID Type Priority DBName StartTime 0x0096E710 2 LOAD 0 TPCC Thu Mar 09 13:40:00 2006 INDEXING REPLACE COPY NO DB2ADMIN.ITEMi 2 NumPhases CurPhase Description 2 OFFLINE LOAD DEL AUTOMATIC Progress: Adress ID PhaseNum 0x0096E9C0 2 1 0x0096EAA8 2 2 Description SETUP LOAD StarTime CompletedWork TotalWork Thu Mar 09 13:40:00 2006 0 bytes 0bytes Thu Mar 09 13:40:00 2006 93274rows 1000822rows LOADが終了した行数 全LOAD行数 ※ LOAD実行中に取得した db2pd -utilitiesコマンドの出力 26 クイズ Currently Committedをモニターするには？ 1) EXPLAINを利用する 2) db2pdを利用する a) db2pd –tcbstats b) db2pd –logs a) db2pd –tcbstats – CCLogReads • 表に関して現在コミット済みバージョンの行が検索された回数 b) db2pd –logs – Cur Commit Disk Log Reads • (ログ・バッファーではなく) ディスクからのログ読み取りにより、現在コミット済みバージョンの 行が検索された回数 – Cur Commit Total Log Reads • 現在コミット済みバージョンの行が、ログ (ログ・バッファーおよびディスク) から検索された合 計回数 27 例） Curently Commitが使用されたことを示すExplainの例 2) TBSCAN: (Table Scan) Cumulative Total Cost: 3579.25 Cumulative CPU Cost: 2.70981e+09 Cumulative I/O Cost: 28588 Cumulative Re-Total Cost: 987.011 Cumulative Re-CPU Cost: 2.612e+09 Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: 3579.25 Estimated Bufferpool Buffers: 28588 Arguments: --------CUR_COMM: (Currently Committed) TRUE ・ ・ 28 5-2. 問題判別 エラー・コードによる判別 – エラー・メッセージやエラー・コードを参考にして原因を追究 SQL0204N "ADMINISTRATOR.TB" は未定義の名前です。 SQLSTATE=42704 エラー･コード エラー･メッセージ 頭のアルファベットでエラーを出している内容を判断 SQL：SQLメッセージ SQLJ：DB2Java組み込みSQLメッセージ DB2：CLPまたはコマンド･センターのメッセージ CCA：クライアント構成アシスタントのメッセージ …etc 下1桁でエラーの重要性を判断 C：重大メッセージ E：緊急メッセージ N：エラー･メッセージ W：警告メッセージ I：通知メッセージ 詳しくは、メッセージ・リファレンス参照 DB2のコマンドラインでは、「?」コマンドを使用して簡単な解説を得ること ができる db2 “? SQLXXXXX” 29 5-2. 問題判別 FFDC (First Failure Data Capture) db2diag.log – DB2の基本診断ログ – 予期しないエラーが発生した場合には、まずdb2diag.logを参照する 管理通知ログ – 従来のdb2diag.logファイルに出力される診断レコードのうち、データベース管 理者が読むべき内容を別途出力している • WINDOWS • UNIX イベント・ログに書き込まれる 「インスタンス名.nfy」というテキスト・ファイルに書き込まれる – イベント･タイプおよび情報のレベルは、データベース構成パラメーター 「NOTIFYLEVEL」で指定(0-4、デフォルト3) – V7にて、db2alert.logを使用していた場合、代わりに管理通知ログを使用する ダンプ･ファイル ※お客様サポート用 – DB2のプロセスまたはスレッドに障害が起きてエラーを通知する場合に、外部 のバイナリー･ダンプ･ファイルにも追加情報が記録される トラップ･ファイル ※お客様サポート用 – OSのトラップやセグメンテーション違反、例外などにより処理が続行できないと きに生成される 30 5-2. 問題判別 Db2diag.log – 目的 • DB2のエラー、警告、通知メッセージを記録 – 解析方法 問題判別に 最も重要な 情報源 • db2diag.log（テキスト・ファイル）の参照 • db2diagコマンド（V8.2以降） – 設定パラメータ • 出力先はDIAGPATH（DBM CFG）にて設定 • 詳細レベルはDIAGLEVEL（DBM CFG）にて設定 – 0 - 診断データを取り込まない – 1 - 重大エラーのみ – 2 - すべてのエラー（重大エラーおよび非重大エラー） – 3 - すべてのエラー、警告 (デフォルト値) ※通常運用時の推奨設定値 – 4 - すべてのエラー、警告、通知メッセージ ※問題発生/再現時の推奨設定値 – 考慮点 • db2diag.logファイルは自動的には削除されない。計画的なバックアップ/削除が必 要 31 5-3. チューニング パフォーマンス上の問題が起きた場合の基本的な対応手順 – パフォーマンス・チューニングの進め方 • 全体状況の確認 • 個々のSQLの調査が必要な場合 • 正常稼動時の記録の必要性 32 5-3. チューニング パフォーマンス・チューニングの進め方 問題発生 全体状況の確認 個々の状況の調査 個々の状況の調査 個々の状況の調査 <= 必ずシステム全体を見渡して、 何が起きているかを確認します <= 個々について、OS、DB2、アプ OS DB2 リケーションから調査を進めま す 個々の状況に対して解決策の検討 個々の状況に対して解決策の検討 個々の状況に対して解決策の検討 個々の解決策の効果確認 個々の解決策の効果確認 個々の解決策の効果確認 適用時期および運用方法の検討 本番適用 <= 解決策の効果が確認されたら、 適用時期、および、その適用に より運用面の変更内容を検討 します 33 5-3. チューニング 全体状況の確認 – 問題が報告された場合には、必ず、システム全体で何が起きているのかを確認し、問題 への対応について、重大な漏れが発生しないようにします。以下は確認項目（例）です。 確認項目 確認のポイント 確認ツール/コマンド OS, HWのエラー状況 ＯＳおよびＨＷのエラーが起きていなかったか、ま た、その影響の確認 OSおよびHWの運用・監視手 順に従ってください システム資源使用状況の確認 ＣＰＵ, Memory, Ｉ/Oの状況について確認 - vmstat - Iostat ＤＢ２エラー状況 DB2のエラーや、その他特別な現象が起きていた かを確認 - db2diag.log ファイルの中を確 認します ＤＢ２アプリケーション稼動状況 UOW実行中、 UOW待機中、ロック待ち、コミット アクティブの状況確認 - db2 list applications show detail DB2内部稼動状況 バッファープールヒット率、ソート処理、ロック処理、 などの基本状況の確認 -database snapshot アプリケーション稼動 Appl PGM, バッチ処理用shell等のアプリケーショ ン側で、エラーや警告が出ていないかを確認 -(option) all snapshot on db - アプリケーションのエラー・メッ セージやアプリケーション・ログ の確認 34 5-3. チューニング 個々のＳＱＬの調査が必要なケース – 全体状況の確認をした上で、個々のSQLレベルでの分析が必要となるケースがあり ます。 – 以下のような手順で作業を進めます。 • 問題となっているＳＱＬの抽出 – 使用ツール例：Statement イベント・モニター • アクセス・プランの確認 – 使用ツール例：db2exfmt • ＳＱＬ実行状況の分析 – 使用ツール例： ・db2batch ・スナップショット･モニター ・Statementイベント・モニター • 対応方法の検討 35 5-3. チューニング 正常稼動時の記録の必要性 – パフォーマンスに関する問題が起きたときに、そのときの状況を調査した資料だけ では判断が難しく、正常稼動していたときのシステム状況と比較したい場合が多々 あります。 – 正常稼動時の情報を計画的に記録することお薦めします。 – 正常稼動時の記録（例） • 「全体状況の確認」に挙げたツール／コマンドの出力結果およびログ – db2diag.log – database snapshot – (list applications show detail) – vmstat, iostat, アプリケーション・ログ • その他 – データベース毎の表・表スペース定義情報、統計情報 > db2look –d <DB名> -a –e –l –m –o <ＤＢ名>_db2look.out – 性能上重要なSQLのアクセス・プラン（db2exfmt 出力） 36