ナレッジボックス

Pocket


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

オラクル女子

 

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

 

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

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

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

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

 

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

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

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

 

Statspackってなにーなにー?

 

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

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

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

 

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

 

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

 

 

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

 

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

 

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

 

 

いち

image1612データベースの特性を見るならLoad Profile♥image1612

 

 

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

 

  • Redo size:Redoログ生成量
  • Logical reads:論理読み込み量 (ブロック数)
  • Block changes:変更量(ブロック数)
  • Phsical reads:物理読み込み量 (ブロック数)
  • Phsical  writes:物理書き込み量(ブロック数)
  • User calls:ログイン、解析、フェッチ、実行などクライアントが生成した処理数
  • Parses:パース全体回数
  • Hard Pareses:ハードパース回数
  • Sorts:ソート回数
  • Logons:ログオン数
  • Executes:SQL実行回数
  • Transactions:トランザクション回数

 

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

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

 

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

 

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

 

 

 

に

image1612Instance Efficiency Percentageでインスタンスは効率的に♥image1612

 

 

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

 

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

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

 

  • Buffer Hit:バッファキャッシュヒット率、データがメモリにのっているか
  • Library Hit:ライブラリキャッシュヒット率、SQLがメモリにのっているか

 

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

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

 

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

 

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

 

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

 

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

 

 

 

 

さん

image1612Top 5 Timed Eventsは超頑張ってる奴ら!image1612

 

 

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

 

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

 

  • CPU time:CPUの使用時間
  • db file sequential read:単一ブロック読み取り
  • db file scattered read:複数ブロック読み取り

 

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

 

このサンプルの場合だと、「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を示してくれてるんだよね!!超タスカルー!!

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

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

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

 

  • 実行時間が長いSQL(SQL ordered by Elapsed)
  • CPU使用時間が長いSQL(SQL ordered by CPU)
  • 実行回数が多いSQL(SQL ordered by Executions)

 

とかね。

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

 

 でわ、ばいばぁ〜いkaerup


Pocket

お問合せ

開発に関するご相談/各種お問合せは下記まで。

TEL.06-4806-3470 月曜~金曜(祝日を除く)10:00~18:00
contact-dev@kronos-jp.net

技術情報

  • ナレッジボックス
採用