ES/1 NEO CSシリーズ性能分析事例｜レスポンス遅延時のOracle性能分析事例｜アイ・アイ・エム

きっかけ：承認フローシステムのレスポンス遅延

全社で使用している承認フローシステムのレスポンスが悪い

ログイン時、文書通知一覧が表示されるはずが、数分かかることがしばしばある

システム部門の対応：開発会社の保守切れにより対応しきれず

日頃トランザクションを見ての監視はしていたものの、このシステムを開発した会社との保守契約が切れており、詳細について不明

リソースではなくシステムの問題かもしれないが、原因を調査し、今後も継続的に遅延予防対策を行いたい

CPUを増強して改善を図る、という案も出たが、IIMへ評価を依頼

システム構成

システム名	OS	サブシステム	CPU数	メモリサイズ
DBサーバー	RHEL5.1（64）	Oracle	8	8.0GB
Webサーバー	RHEL5.1（64）	HTTP	4	3.2GB
APサーバー	RHEL5.1（64）	HTTP	2	3.2GB

STEP1：チューニングヒントによる問題点の特定

下記二点の問題点をチューニングヒントにより発見

物理CPUの枯渇

ESXホスト（HostC）のCPU使用率が高い

→90%を超えている

vCPUの枯渇

仮想マシン（clubmember02、clubmember01）のvCPU使用率が高い

→90%を超えている

上記2点にボトルネックがあると判断し、更なる分析を進めることになった

APサーバー、Webサーバーには問題無し

【出力されたチューニングヒント】

STEP4：遅延原因の特定と対応策の提案

遅延原因

バッファキャッシュヒット率の低下

ハードパースが発生し、DBサーバーのCPUが枯渇

－CPUはOracleによってほぼ全てが消費されている
－処理の重いハードパースが多く発生し、CPUを消費している

対応策

バッファキャッシュヒット率の改善

－メモリーには余裕がることが確認できているので、SGA領域を増やして、バッファキャッシュヒット率の向上を図る

－アクセス件数が大量であるため、数％の向上でもレスポンスが改善できる可能性がある

ハードパースの削減

－同じ構文のSQLが確実に共有されるように記述法（大文字、小文字、空白の位置など）を統一する
－バインド変数を使用してSQLを記述し、条件指定される値の違いによって共有プール内で別オブジェクトとなることを防ぐ

お客様の対応

バッファキャッシュヒット率については、SGA領域を拡張し、改善された

ハードパースについては、当該システムが１年後に更改予定のため、SQL文の改修実施せず

次期システムのプロジェクトチームへ状況を報告

同じことが起こらないようにSQL文を見直すよう依頼