私にとってのデータベースチューニングとは

（注）本エントリは私の考えであって一般的な解でもないですし何の保証もないのでご注意を

「DB周りのチューニング」と一言で言ってしまうと様々な作業がありますが、
一般的には2つのフェーズがあると考えています。

1．SQLチューニング
2．Databaseチューニング

の2つです。

SQLチューニングはアプリケーションが妥当な実行計画、レスポンスで動くように
チューニングする作業です。
具体的には
　遅い処理を特定
　どのSQLが遅いのがドリルダウン
　SQLの実行計画を取得(SQLトレース)
　遅い実行計画を早い実行計画に変える
という作業になります。

遅いSQLを早くするには
　FullScanで遅い場合はIndexScanされるように索引作成＋統計情報取得
　ほかのもの、もしくはIndex作成では改善しない場合はヒント文

となるでしょう。
プランを固定するならプランスタビリティを使うと良いですが、
あまり使いこなしている人は見たことをありません。
どちらかといえばプラン固定よりも計画的な統計情報の取得や遅いSQLの定期監視の方が
効果が高く、何かあったときの柔軟性高いです。

SQLチューニングが終わった後に＜＜＜これ重要
ようやくDatabaseチューニングです。

Database周りを見るならstatspackもしくはAWRレポートでしょう。
レポートの作り方はマニュアルなりを見ていただくとして見る観点はどこか？

それはまずはTop5　Eventを私は見ます。

Top5でCPU Timeが上位かつ占める割合が高ければ良い状態です。
良い状態とはI/Oやメモリ確保よりもCPUをたくさん使っている、
システムとして性能を十分に出しやすい状態になっているということです。

ですのでCPU TimeがTopにくるようにチューニングをしましょう。

db file scattered readが多い場合はFullScanが走っている可能性があります。
索引を使わせる、db_file_multiblock_read_countを増やす、早いディスクを
採用するなどの方法がありますが、原因を突き止めてどのような手法が有効か考えましょう。
SQLチューニングが不十分なケースもあります。

buffer busy waitsなどが出ている場合はブロック競合が起きている可能性があります。
色々なブロックが対象になりますがレポートのほかのセクションにbufferの情報がありますので
何がBusyになっているかを特定して対策を考えましょう。

ただし。これらが必ず悪いわけではありません。
チューニングのコツは「目標値を決めること」です。
目標を達していれば必ずしもFullScanが悪いわけではないですし、
CPU TimeがTopになくても良いのです。
よく目標を「可能な限り速く」というオーダーも受けますが、
いわゆるカリカリのチューニングをすることに意味はありません。
必ず数値目標を立ててそこを達成するようにしましょう。

そしてせっかくチューニングしたデータベースです。
定常運用に入った後もチューニングの必要が出てくるかもしれません。
定期的にレポートを見てデータベースの変化を監視しましょう。
ビジネス要件の変化によって予期せぬボトルネックが生じることがあります。
よくある、といってもいいでしょう。
そここそDBAとしての腕の見せ所ですし、問題が顕在化する前に潰すことが
エンジニアの仕事です。

ほかにもこんなことある！というのがあったら是非教えてください。