問題が発生した場合，必ず原因を理解して解決策を導かなくてはならないが，チューニングの場面でもこれは同じだ。現象だけを見てチューニングを急いではいけない。

　データベースのパフォーマンスに問題がある場合，よくリソースの使用状況がやり玉に挙げられる。リソースを調べると，例えば「CPUの使用率が100%になっている」。あるいは「ディスク・ビジー率が高くなっている」。これらは一見，パフォーマンスの悪化に一役買っているように見える。ここで短絡的に，リソースを追加して問題を解決しようと思ってはならない。これらがパフォーマンス低下を引き起こしている原因なのかどうかは，これだけでは分からないのである。

「CPU使用率100％」は原因ではなく現象

　リソース消費の状況は，あくまで現象にすぎない。現象と原因を混同してはならない。現象に対して施された対応策で仮に効果が得られたとしても，根本原因にメスを入れていないと何の解決にもならない。なぜなら原因が解決されていないと，現象に対する対応策は一時しのぎにしかならないからである。早晩，新たなボトルネックを引き起こすだろう。

　先の例で考えてみよう。CPU使用率100％の環境にさらにCPUを追加したとする。もし並列処理ができないアプリケーションであれば，追加したCPUがうまく利用されない可能性がある。その結果，見た目のCPU使用率が下がり余裕ができたように見えるだろう。しかし，アプリケーションのパフォーマンスが改善することはない。

　あるいは，ディスク・ビジー率が非常に高い環境に高性能なストレージを導入したとしよう。翌日にはCPUがボトルネックになり，CPUの追加を検討しなくてはならないかもしれない。

　現象の背後にある原因に対して有効な対応策を施さなければ，いつまでも現象への対応にコストをかけ続けることになる。

データベース・バッファのヒット率が低いのも原因ではなく現象

　別の例で，パフォーマンスが劣化しているにもかかわらず，リソースの使用状況には全く問題ないケースを考えてみよう。この場合は，データベースの内部で問題が発生していると考えられる。データベースの情報を探り，その原因を見つけなければならないのだが，ここでも現象と原因を明確に区別しなくてはいけない。

　データベース・バッファのヒット率が低い場合，ヒット率が低いのは現象であり，原因ではない。短絡的にバッファのサイズを大きくしてはいけない。ヒット率が下がる場合，無駄な全件検索をしているSQL文や，格納効率の悪いインデックスが存在している可能性がある。原因はSQL文か格納効率の悪いオブジェクトであり，必ずしもバッファのサイズが原因ではない。

　また，SQL文が原因だとしても，そのSQL文のチューニングが本当に，システム全体のチューニングになるのかを注意深く観察する必要がある。例えば，1回の実行に5時間もかかるSQLをチューニングして3時間にしたとする。しかし，そのSQL文が1カ月に1回しか実行されない場合，システム全体では2時間のチューニング効果にしかならない。一方1回の実行に2秒しかかからないSQL文を1.8秒にチューニングし，そのSQL文が1カ月に10万回実行されていたとするとシステム全体では5時間強のチューニングになるのである。

　これらから，チューニングとは現象が発するメッセージを注意深く読み解き，その根本的な原因にメスを入れる作業だといえる。決して，現象一つをとらえて短絡的に結論を導き出してはならない（図）。

図●データベースをチューニングする際に考えておくべき要素 [画像のクリックで拡大表示]