株式会社クロノス AIソリューション / Web・モバイルアプリ開発 / IT研修・トレーニング

一緒にまなぼ！「hiromi と楽しむOracleパフォーマンスチューニング！」【Vol.2 Statspackを見てみよう】

 

こんにちわぁ～ひさしぶりだね～

 

また見にきてくれてありがとぉ～Oracle女子のhiromiです

みんな元気だったかなぁ？hiromiは元気ー

でも最近、お友達とショッピングするよりもOracleのサイジングについて考える方が楽しくなっちゃって、仲のいい友達がどんどん離れていっちゃうよーってのが一番の悩み。

でもまあOracle触ってたらそんなことすべて忘れちゃうんだけどね。ふふ

 

早速なんだけどー、前回は実行計画についてれくちゃーしたから、今回はStatspackについて教えちゃおうと思うのー。いいかなー？

Statspack、すたっつぱっく、ね。はー？Statspackってなにー？って感じだよねー？

早く知りたいよねー？じゃあもういっちゃおかー

 

Statspackってなにーなにー？

 

Statspackっていうのは、Oracleが標準で提供してくれている性能を分析するためのツールだよ。

無料だよ、無料。It’s Free!

hiromi、無料大好き。サンプル化粧品とか試食とか無料って超好き！

 

実はAWRっていうものすごーく細かく分析できるツールもあるんだけど、こっちは有料なの。もしStatspackじゃものたりなーいって人はぜひ調べみてね

 

で、Statspackを使うとOracleの使用状況を見ながら分析レポートを作ってくれるんだけど、定期的に、そう、１時間毎くらいにレポートを出力することなんかもできるんだよー。１時間単位のレポートだとその前後のスナップショットをもとにして、その１時間で繰り広げられた処理の情報を元にいろいろ教えてくれちゃうんだよー。まぢで、すごくない？

 

 

とりあえず、実際のレポートをみちゃおう！

 

どう？よくわかんないよねー？hiromiも最初見た時わけわかんなすぎて、Oracle女子やめてDB2女子になろうかと思ったもん。ウソだけどね。えへ。

 

大事なところを順番に拡大して説明しちゃうよー

 

 

 

 

そう、まずはここ。赤で囲んでいるところね。ここはLoad Profileっていう項目なんだけど、ここを見ればデータベースの特性とか傾向をざーっくり見ることができるんだよ。

 

 

なんか参考になりそうな感じするでしょ～！

たとえば、Parsesの回数に対してHard Parsesの割合が大きいほど超ハードパースしちゃってんじゃんてことだから、バインド変数を使うように修正できるSQLがないか探してみるとかー、共有プールサイズを大きくしてみるといいと思うよ

 

ちなみに、SQLの空白の数とか改行の位置が違うだけでも、それぞれ別ものってことでハードパースされちゃうからね～

 

じゃあ次のレポート見てみよっかー

 

 

 

 

 

Instance Efficiency Percentageっていう項目なんだけど、簡単に言うと「インスタンスが効率的に使われてるのー？」ってことだよ。非効率だと全体のパフォーマンスに影響するからねー。非効率ダメ、絶対アカン！

 

Load Profileにでてきた数値だけぢゃ、ぶっちゃけパフォーマンスどんなもんなの？ってところがパーセンテージでわかっちゃうー！

だいじな項目の意味はこんな感じだよ

 

 

このへんの項目が１００％に近かったら効率的に使われてるよー、ってことなんだ。このサンプルとか超イイ感じ～♪データもSQLもメモリからスルスルスルリ～ンてとってこれてるねー。

ココはわかりやすよねー。hiromiも喜怒哀楽が激しいから、超わかりやすい子ってよく言われるんだー。激おこぷんぷん丸！

 

で、９５％以上が理想的らしーんだけどね、それより低かったらどーすんのよって？まぢ焦るよね。Buffer Hitはー、バッファキャッシュのサイズを大きくするとかー、SQL実行タイミングを調整してみるといいかもねー。SQLを実行しまくって、いろんなデータを取得すればするほど、その分バッファキャッシュはパンクしちゃうからねー。パンクしたら、また物理読み込みが発生して、パフォーマンスが低下しちゃーう（泣）

 

同じデータを使う処理をかためたり、バッチの実行時間をほかの処理とかぶらないようにを調整することで効果が出ることもあるかもしれないよ～

 

Library Hitは、Load Profileで書いた超ハードパースしてんじゃんってのがパーセンテージで見えるんだよねーわかりやすーい！でも、Hitって言ったらやっぱりイチローだよねー。4000本とかまぢ神！実は、hiromi野球好きだったり～、てゆーか、やっぱりやっぱりスポーツしてる男子とか超カッコイイっしょ

 

ハイ、次ね、次。次はここ。

 

 

 

 

 

 

Top 5 Timed Events、簡単に言うと「超頑張っちゃってるイベントの上位５つ」だよー

 

よく見るイベントはサンプルのなかからコレ！

 

 

「CPU  Time」はね、CPUを使用して処理してる時間だからいいとしてー、それ以外でなに頑張っちゃってるの？ってところがパフォチュの観点だよね。「CPU time」が一番上にきてると、まぁイイ感じらし～よ～

 

このサンプルの場合だと、「CPU Time」よりも上に「db file sequential read」てのがきてるよね。キングだよね～なんでキングとってんのかってゆーと、インデックスで検索をして単一ブロックを物理読み込みしたからってのが一番の理由だと思うんだよねー。

てことは、イベントだけで言うと悪いやつってわけでもないよね。「db file scattered read」も物理読み込みが発生してて、こっちは全表検索をして複数ブロックを読み込んでいる可能性が高いみたい。

 

「db file sequential read」でも「db file scattered read」でも、まずはどのSQLで物理読み込みが発生しているのかを突き止めちゃおーよー。で、どうやって突き止めるかというと・・・、Statspackのレポートの「SQL ordered by Reads」ってのが物理読み込み回数が多いSQLを示してくれてるんだよね！！超タスカルー！！

そしたら、インデックス設計を見直したりー、読み込み対象のデータが多くなりすぎてるようだったら、パーティションを使ってみるとか、考えてみてほしぃなぁ～

★もっとイロイロできちゃうStatspack

Statspackって実はもっともっといろんなことを調べられちゃうの。たとえば・・・

 

 

とかね。

でもhiromiはこれから青山でOracle男子とコンパだから、もし興味があったら各自で調べてみてー。うふふふー

 

 でわ、ばいばぁ〜い