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

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のロック待ちのデッド
ロック