Oracle Databaseの性能解析セミナーに参加してきました

[Oracle]
　PSソリューションズ株式会社さんが主催する。「実習セミナー：DBにて発生しているスローダウンを調査しよう」（http://atnd.org/events/20963）というイベントに参加してきました。とてつもなく臨場感溢れるStatspack/AWRレポートファイルを使用して、処理遅延・性能問題の解析をするという結構どころでなくガチで実践的な勉強会です。特に性能問題に悩まされることの多い運用フェーズのシステムを看ているエンジニアさんにはぜひ参加して欲しい会。僕は前回の「実習セミナー：RAC環境でのレスポンス遅延を調査・解決」（http://atnd.org/events/19033 http://oracletech.jp/seminar/event/000388.html）から参加し始めたのですが、まぁ、とても仮のデータを使っているとは思えないほど実践的で、Oracle Databaseエンジニア向けの筋トレとしてためになる会でした。

　今回はシングルインスタンス構成のOracle Databaseで、処理遅延が発生したという体のケーススタディ。手元にはStatspack/AWRレポートと、アクティブセッション数＋総セッション数を記録したログファイルのみ。さぁ、挑戦者たちよ！　解析を始めるが良い！という展開（ウソです。ホントはヒントを出していただきつつ一歩ずつ解析を進めていきます）。

　一歩目は「まずはCPU使用率、DBの負荷と処理それぞれの量、セッション状況の3つを確認してみましょう」というもの。まぁ、性能ボトルネックといえば、CPU/メモリ/ディスク/NWですものね。Statspack/AWRレポートからのCPU使用率計算方法、同じくStatspack/AWRレポート内の負荷量処理量の表示場所を教えていただきながら、確認確認。セッション状況については、V$表から直接取得した体のログファイルがあったので、ソイツを確認。

　一歩目の確認が済んだ所で、お次は"Top5 Timed Event"セクションを確認。ここはレポートに出力した期間内で、Oracleに発生した待機イベントの内、割合の多かったもの頭から5つとその割合を表示するセクションです。一般論ですが、ここで"CPU Time"が大半を閉めていれば無問題。何らかのイベントが上位に居れば、改善余地アリを意味します。経験則から言うと、1つのイベントで2割以上占めてたら、手を出す価値もあるかしら？　という感じ。まぁ、性能問題って、バッチ処理が制限時間内に終わらない、とか、業務に影響がでない限り必ずしも手を出さなくちゃいけないものでもないんで、あくまでも「必要だったら処理時間を短くすることができる」というレベルの話ですが。で、今回は、REDOログバッファのフラッシュ（オンラインREDOログファイルへの書き出し）に時間がかかっているかしら？　という内容でした。前述のCPU/メモリ/ディスク/NWで言えば、ディスク（I/O）への疑惑がどんどん深まるという状況。

　これ以上の記述は、僕の筆力では解析手法のネタばれをしてしまいそう＆それは主催してくださるPSソリューションズさんの意図に反してしまいそうなので控えますが、最終的には「やはりディスクが黒い。だがOracleからではこれ以上追えないよ」という「センセイ！　それはちょっと消化不良です（笑）！」という結論になりました。とはいえ、今回も前回同様たいへん実践的な内容で大満足でした。

　勉強会後の懇親会では、先日初参加した「Oracle Lovers勉強会」でご一緒させていただいた @tami_miyawaki さんの仲添えで、 @discus_hamburg さん、 @chirokings さん、 @megascus さんといろいろお話しさせていただきました。みなさんありがとうございます。ワタクシ職場で技術的に突っ込んだ話をできる知人があんま居ないので、たいへん楽しい時を過ごすことができました。皆様も、楽しい時間だったと、思っていただけたら、嬉しいな。と思ってます。

　最後に、自分たちが獲得したノウハウを、クローズドな勉強会の場とはいえ惜しげなく披露してくださるPSソリューションズさんに心からの感謝の気持ちを表明しつつ今回の記事を終えます。ありがとうございました。心から。

　次回も行きますよ！：）