皆さんこんにちは、やっと暖かくなってきた感じですが、まだ寒い日があったりしますので体調に注意が必要ですね。今回は、チューニングの初歩的なお話をすることにしました。第3回ではStatspackの実例を使用した分析（問題特定）方法を説明しましたが、そもそも問題があるか（システムが効率良いか）どうかの調べ方について説明していなかったように思います（ユーザからすればレスポンス時間が遅いことが問題ですが、皆さんのような管理者からすればシステムを効率良く使用しているかが気になることだと思います）。今回はそのようなことについて説明しようと思いますので、参考にして下さい。
■1. チューニングとは
まずは、チューニングについて（そもそもチューニングとはどんなことをするのか）簡単に説明しましょう。
私は、古い技術者なのでチューニングを感覚的に（経験と勘を頼りに）行っているところがあるため、このようなことを整理するのが大変なのですが、経験が少ない技術者の参考になると思いますので、少し頑張ってチューニングの手順や考え方をまとめてみました。
チューニングは以下の手順で行います（考え方は単純ですがそれぞれが難しいという訳です）。
- パフォーマンス問題があるか（リソースを有効利用しているか）
- 次に原因を突き止める
- そして原因を解決する
（1）パフォーマンス問題があるか
これについては分からない方または興味のある方も多いようです。よくシステムのアセスメント（ヘルスチェック）を行って欲しいと聞きますので（このようなサービスもあるくらいですので）、皆さん非常に気にしていることだと思います。
パフォーマンス問題があるかはH/Wリソースの使用状況で判断します（使い過ぎていないか、使用できていないかの両方の問題があります）。調べ方としては、リソース（Oracleデータベースの設定項目）毎の閾値を基にチェックして問題ないか確認して行きます（これがノウハウを必要とする訳です）。すべてのリソースをチェックするのは大変ですので、まずはCPUリソースをチェックすると良いと思います。このとき負荷が足りないため（リソースに余裕があるため）に未使用になっている場合もあるので注意が必要です（これにより性能問題として現れていない場合もあります）。問題なのは処理時間が遅いのにリソースに空きがあるかどうかです。つまり以下の4つのパターンがあるので、これを見極める必要があります。
- CPUリソースに空きがある
– 待機があるため・・・【1】
– 負荷が足りない（正常）・・・【2】 - CPUリソースに空きがない
– 無駄に使用している（アプリケーションが悪い／SQL文が悪い）・・・【3】
– リソース不足・・・【4】
CPU使用率は、OS統計から空き（Idle, Wio）があるか見ます（AWRやStatspackにもOS統計があります）。その後はOracleパフォーマンス統計情報でOracleデータベースが有効に使用しているか見ます（つまり、AWRなどだけでも調べることが可能です）。ただし、瞬間的に使用率が高騰するときがあるので、そのような場合はOS統計で時系列に（5秒間隔などで）見る必要がありますので注意して下さい。AWRなどの「Top 5 Timed Events」のトップに「DB CPU （StatspackはCPU time）」が来ているのに（Oracleデータベースとして効率良くCPUを使用しているのに）CPUリソースが余っているのであれば負荷が足りないということです【2】。「DB CPU」がトップに来ていてCPUリソースにも余裕がないのであればCPUリソース不足【4】、または無駄に使用しています【3】。そのため、無駄に使用しているSQL文を探して変更するかリソースを追加する必要があります（これは第3回でも説明しましたね）。「DB CPU」がトップではなくCPUリソースも空いているのであれば（このときCPUリソースは必ず空いています）、使用できない原因（待機）があるということです【1】。つまり。まだ性能が向上する可能性があることになります。このように分析して問題がないか判断するのが良いと思います（これで、少しは簡単に分析することが出来ると思います）。
CPU使用率について
ご存知ない方のために、ここでCPU使用率の考え方について簡単に説明します。
CPU時間には、User, System(Sys), Idle, Wioがあり（IdleとWioはどちらも未使用時間として考えます）、CPU全体の時間に対する比率とCPUコア毎の時間に対する比率があります（それぞれの比率がvmstatなどのOS統計情報に出力されます）。以下の図では簡単にするために全体（CPUコア数が2）の時間としてCPU使用率（75％）を求めています。これにAWRなどに出力される「DB CPU」や「DB Time」を一緒にすると以下の図のような関係になります。「DB Time」がOracleデータベースが動作している時間、「DB CPU」がその内でCPUを使用している時間です（これの最大はUser+Sys時間ということですので、User+Sysより小さい場合はOracleデータベース以外のアプリケーションなどが使用していることになります）。AWRなどの「Top 5 Timed Events」に出力される「%Total Ela Time」は「DB Time」に対する比率になります。つまり「DB CPU」についてはOracleデータベースが動作している時間に対するCPU時間の比率になります（この時間が100％に近いと待機がない訳です）。以下の例ですと60％（60秒/100秒）になりますので40％が待機時間になります。CPU使用率については、瞬間的に変化するため取得するタイミングによって（取得する時間がずれると）異なってきますので、多少の誤差はあると思って下さい。
（2）パフォーマンス問題の原因を突き止める
それでは、次に原因を突き止めていきましょう（ここではCPUリソースに空きがあるとします）。
AWRなどの「DB CPU」がトップに来ていない場合は何かで待ちになっています。これの原因には様々なものがあり待機イベントとして出力されます。待機イベントは大きく分けて以下の2種類です。
- リソース不足による（ストレージ、ネットワークなどのCPU以外のリソース不足）
- 競合（排他制御）による（ラッチ、Mutex、エンキューなど）
これは、同時ユーザ数が増加して発生する場合もありますが、SQL文やアプリケーションが悪いために発生する場合もあります。例えば、SQL文が悪くて索引スキャンできるのにフルスキャンになっているとか。アプリケーションのアクセスの方法が悪くて行ロック競合になっている等が考えられます。両方の原因が混在して発生する場合もありますので注意が必要です。原因になるものは、AWRなどに待機イベントとして出力されますので、調べるのは簡単だと思います（待機時間の大きい待機イベントを調べることになります）。AWRなどの見かたを知っていれば、ここまでは簡単ですよね。
（3）パフォーマンス問題の原因を解決する
これは原因が何故発生するか分からないと解決することができないと思いますが（これが難しいのですが）、一般的に、リソース不足ではリソースの追加または使用の削減をして、競合では競合の回避または同時ユーザ数などの削減などをすることになると思います。これについては簡単なガイドを作成するなどのレベルでは行うことができません（パターンが多すぎてまとめられないからです）。Oracle Database 11gであればチューニング・アドバイザなどを使用して下さいとまとめたいところなのですが、それでは解説にならないので一般的に多く発生するようなことを多少説明しようと思います。それが以下になります。
- I/Oネック
これは第3回、第12回、第13回などで説明ましたので省略します。また、アプリケーション（SQL文）の改善については第9回、第11回の「良いSQLについて」を参照して下さい。 - ネットワーク・ネック
これはリソースの増強（回線を増やすかスピードをアップするか）になると思いますが、これが発生するのはアプリケーションの問題の場合も多いような気がします。大量データの受け渡しをネットワーク越しに行っている可能性がありますので確認して下さい。今回は量が多いので詳細は別の機会にします。 - メモリ競合（ラッチ、Mutexなど）
- エンキュー競合（HW,SQ,TX,TM,STなど）
メモリの競合回避は簡単には行うことができないので（第7回「共有プールについて」で少し触れました）、第18回はエンキューについて説明しようと思います。
■2．おわりに
今回はチューニングついて説明しました。引き続いて第18回「ロックについて」も今回は同時に公開しました。ぜひご覧ください。