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

2,218 views

Published on

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

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,218
On SlideShare
0
From Embeds
0
Number of Embeds
87
Actions
Shares
0
Downloads
13
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

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

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

×