はじめてのSQLチューニング(oracle)
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

はじめてのSQLチューニング(oracle)

  • 1,760 views
Uploaded on

SQLチューニングってとっかかりがよくわからない。とか、 ...

SQLチューニングってとっかかりがよくわからない。とか、
AWR、実行計画、統計情報。なにそれ?おいしいの?という方にお勧め。

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,760
On Slideshare
1,757
From Embeds
3
Number of Embeds
2

Actions

Shares
Downloads
7
Comments
0
Likes
1

Embeds 3

https://twitter.com 2
http://www.google.co.jp 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. SQLチューニング 勉強会 2013/10/07
  • 2. GOAL  10/7 AM3:00-実行された夜間バッチのSQLが長 時間化している。  どうやら性能試験の時に想定していた実行計 画がぶれている  全パーティションでNestedLoops結合でTable Access Fullが走っている  統計情報が古かったことが原因だとか。。。  ヒント句等でインデックスが効くようにして ほしい
  • 3. GOAL(つづき) ディレード処理が返ってこない  オンライン処理で遅い処理がある  夜間バッチが終わらない   とPMから言われた時どうしますか?  以下を使って切り分けしましょう    「Webアプリの問題点を「見える化」する7つ道具」 AWR(実行計画) 原因切り分けが終わったらチューニングしましょう   ミドルウェア・OSパラメータチューニング SQLチューニング
  • 4. Webアプリの問題点を 「見える化」する7つ道具 http://www.atmarkit.co.jp/ait/articles/0703/22/news138.html
  • 5. 切り分けに使うツール・ログ top,glance,vmstat  jps/jstat  kill -3/侍  NeckLess  サーバログ(catalina.out)  alert/traceログ  syslog 
  • 6. よくある性能問題の原因 GC頻発  スレッド間のオブジェクトwait  DBのデッドロック  JavaScriptの長時間化  SQLの長時間化   性能問題の8割はSQL  実行計画の理解は必須
  • 7. HelloWorld 実行計画   SQL> set autotrace on SQL> select * from TBL2 where col1 = 10000;    COL1 COL2 ---------- -------------------------------------------------------------------------------10000 10000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAA    実行計画 ---------------------------------------------------------Plan hash value: 1207070705        -------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 65 | 3 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| TBL2 | 1 | 65 | 3 (0)| 00:00:01 | |* 2 | INDEX UNIQUE SCAN | PK_TBL2_COL1 | 1 | | 2 (0)| 00:00:01 | --------------------------------------------------------------------------------------------   Predicate Information (identified by operation id): ---------------------------------------------------  2 - access("COL1"=10000) http://www.oracle.com/technetwork/jp/database/articles/shibacho/dba05-1598286-ja.html
  • 8. よくあるSQLが遅い原因  実行計画が悪い  アクセス方法が非効率    Table Full Scan Index Skip Scan 件数絞り込みがいまいち   Merge Join Cartesian(直積) Nested Loops結合にて駆動表の件数が多い
  • 9. インデックス (B tree) http://www.hi-ho.ne.jp/tsumiki/doc_1.html
  • 10. INDEX UNIQUE SCAN http://www.hi-ho.ne.jp/tsumiki/doc_1.html
  • 11. 件数絞り込みがいまいち  Nested Loopsの例 http://www.magata.net/memo/index.php?%C9%BD%B7%EB%B9%E7%A4%CE%B4 %F0%C1%C3%C3%CE%BC%B1
  • 12. 実行計画が作られる仕組み http://www.oracle.com/technetwork/jp/ondemand/db-new/b-14-consulsql-1448421-ja.pdf
  • 13. 統計情報さえ変わらなければ実行 計画はぶれないか?  No     Bind Peek Cardinality Feedback Adaptive Cursor Sharing Dynamic Sampling
  • 14. チューニング  ヒント句や構文変更によりおプティマイ ザに適切な実行計画をださせること http://www.atmarkit.co.jp/ait/articles/0408/25/news101_3.html
  • 15. DBの問題点を「見える化」  AWR http://www.oracle-base.com/articles/10g/automatic-workload-repository-10g.php
  • 16. チューニングの手段 インデックスをDBに貼る  SQLの構文を変更する     結合順序 絞り込み条件 ヒント句を付与する
  • 17. パーティション http://www.atmarkit.co.jp/ait/articles/0611/22/news141.html
  • 18. GOALに達しましたか?  10/7 AM3:00-実行された夜間バッチのSQLが長 時間化している。  どうやら性能試験の時に想定していた実行計 画がぶれている  全パーティションでNestedLoops結合でTable Access Fullが走っている  統計情報が古かったことが原因だとか。。。  ヒント句等でインデックスが効くようにして ほしい。
  • 19. 性能試験は大変  データを積む    顧客テーブルにA顧客がいて、X契約とY契約を 持っていて、X契約の満期日は~月~日で、、、 なんていう業務知識って方式チームにはないです よね。 1000万件の壁 マシンを占有する   移行チーム・業務チーム・基盤チームとの取り合 いです マシン都合で進捗が遅れたなんて言い訳できませ ん
  • 20. 性能問題実例  当該SQLが遅いだけならまだしも、他の SQLの実行に迷惑をかけるケースがありま す    一時表領域を使い果たし、他のSQL遅延 ラッチ競合を起こし、Service Guardのヘルス チェックSQL遅延により、Oracleのフェール オーバー ディレード処理が長時間化(2時間超)し、 CPU使用率が閾値超え
  • 21. 性能問題実例  OSやミドルのパラメータにも気を配る必 要があります  単性能はOKだったが、負荷性能試験でNG  ファイルディスクリプタを使い果たしエラー
  • 22. 性能問題実例  2012年x月y日 とあるシステムがカットオー バーした  デッドロックが多発。ホストDB2のロックエスカ レーションが原因だとか    APサーバはWebOTX SQLが長時間化していないのにも関わらずレスポ ンスが悪い処理がある ⇒synchronized処理におけるスレッドのオブ ジェクト待ちとSQLのロック待ちのデッド ロック