悪玉SQLを探し出せ！ - J-schooL悪玉SQLを探し出せ Jonathan...

Session by Shinnosuke

Akita

2014.02.00

悪玉SQLを探し出せ！～Oracle Databaseを監視しよう～

Self Introduction

Shinnosuke Akita

・ Oracle DBAをやっています。・今の現場はDB設計もやっています。・入社2年目・休日はランニングと家族サービス・たまに小説も書いたり、勉強会にでかけたり・大衆酒場めぐりがマイブーム

Today’s Agenda

・悪玉SQLを探し出せ！

・SQLチューニングの基礎

突然データベースが遅くなったら？本当にSQLが悪いのか？被害者と加害者

Tips紹介

悪玉SQLを探し出せ

データベースが突然遅くなった！

エンドユーザに早く報告しなければならないだが、糸口が掴めない… いったいどうすれば…


いったい何が原因になり得るのか？

SQLのプランが悪くなった？

OSの問題？

ディスクIOの問題？

ネットワークの問題（RACの場合）


アラートログにでも出てくれればいいが、正常に動いてはいるのなら、何も出してくれない。

様々な要素をどう効率よく確認するかが解決を早くする！


Jonathan Lewis氏に聞いてみた。

この問題は難しく、必ずしも同じパターンでいつも対応できるものではない。だが、一般論としてお話はできる。

Oracle Ace トラブルシューティングや SQLオプティマイザが専門


一般的な確認順

OS CPUの確認 TopコマンドなどでOSのCPUを確認する

SQLの確認現在動いているSQLを確認する

スナップショットの確認

現状のスナップショットを取得し、いつもの状態と比較する


SQLを探してみる

select SID,USERNAME,PROGRAM,COMMAND,SQL_ID,

STATUS,EVENT,P1,P2,P3,WAIT_TIME,SECONDS_IN_WAIT,last_call_et

from v$session

where status = 'ACTIVE' and USERNAME IS NOT NULL;

まずは、現状動いているSQLを見てみましょう。

何度か叩いてみましょう。続けて出てくるSQL_IDがあったら、そいつが怪しいです。


SID セッションのID

USERNAME SQLを実行したユーザの名前

PROGRAM SQLを実行したプログラム

COMMAND SQLを実行したコマンド

SQL_ID SQLに振られたID

STATUS アクティブかインアクティブか。今回はアクティブしか見ない

EVENT 待機をしている場合、何が理由で待機をしているか

P1,P2,P3 EVENTの補足情報（EVENTによって内容が変わる）

WAIT_TIME 待機時間。-1は1/100秒未満

SECONDS_IN_WAIT 現在の待機が開始されるまでの時間

LAST_CALL_ET セッションがアクティブになってからの時間

V$SESSION


SQL_IDを探したら・・・

select sql_text from v$sqltext

Where sql_id = ‘XXXXXXX’ order by piece ;

SQLをみてみましょう。

SQL_IDからSQLテキストを導き出します。


実行計画を見てみる

select sql_id, plan_hash_value, executions, optimizer_cost,

application_wait_time,concurrency_wait_time,cluster_wait_time,user_io_w

ait_time,plsql_exec_time,java_exec_time,buffer_gets,physical_read_bytes

from v$sql

Where sql_id = ‘XXXXXXX’;

SQLがどのように実行されているかを見てみます。まずは、どんな実行計画があるか見てみましょう。


SID_ID SQLに振られたID

PLAN_HASH_VALUE 実行計画の値

EXECUTIONS 実行回数

OPTIMIZER_COST オプティマイザが計算したコスト（実行負荷）

XXXX_WAIT_TIME XXXXによる待機時間（５つの総計が処理時間）

BUFFER_GETS 論理読み込み数

PHYSICAL_READ_BYTES 物理読み込み数

V$SQL


本当にSQLが悪いのか？


遅いSQLが悪いとも限らない

バッチ処理で時間がかかるSQL

そもそも処理量が多い（分析系）

ハードパース処理

普段の状態との比較をする必要がある


普段の状態をどう調べるか

Statspack スナップショット間のデータベースの状態を確認できる。デフォルトで1時間に1回取得する。

AWR スナップショット間のデータベースの状態を確認できる。期間比較やアドバイス機能あり（有償）

v$session 現在データベースにあるセッション情報を確認できる。

普段の状態

現在の状態

ASH (Active Session History)

データベースにあるセッション情報の履歴を確認できる。（有償）

Enterprise Manager パフォーマンスタブで現在のデータベースの状態を確認できる。(有償）


被害者と加害者

注意すべきなのは、待機しているセッションは「被害者」であること。被害者を無くするのではなく、「加害者」をどうするか考えるのが重要。


待機イベント

待機イベントとは、プロセスがSQLを処理するために(CPUを使わずに)待たなくてはいけない出来事のこと。 I/Oやロック競合などの情報を確認できる。

図）buffer busy waitの例


待機イベント例（１） db file sequencial read

ファイル読み込み（単一ブロック）による待機

待機させられている

サッポロラガーがあるかメニュー確認しているファイル読込）で店員さんを待たせている


待機イベント例（２） free buffer waits

バッファキャッシュに空きが無くて待機している。

3人で来たが2席しか空いていない

SQLチューニングの基礎

どうやってチューニングするのか？

チューニングにはどのような方法があるのだろうか？


実行計画の取得

まずは事前準備

GRANT PLUSTRACE to USERS;

権限の取得(sysdbaにて実行)

@?/rdbms/admin/utlxplan.sql

PLAN_TABLEの作成(なければ)


実行計画の取得

SQL> set lines 200

SQL> col plan_plus_exp format a200

SQL> set pages 0

SQL> set autotrace on;

フォーマット設定

select num from test2 where num = 1;

SQL実行


実行計画の中身（１）

実行計画 ---------------------------------------------------------- Plan hash value: 2520579295 ------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | 4 | 1 (0)| 00:00:01 | |* 1 | INDEX RANGE SCAN| TEST2_IX1 | 1 | 4 | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("NUM"=1)


実行計画の中身（２）統計 ---------------------------------------------------------- 1 recursive calls 0 db block gets 2 consistent gets 0 physical reads 0 redo size 283 bytes sent via SQL*Net to client 388 bytes received via SQL*Net from client 1 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 0 rows processed


主な問題

インデックスが無い・使用されない

表の結合と絞り込みの問題

ライブラリキャッシュが有効に使われていない

インデックスを貼る、外部表で条件がある場合等、SQL記述ルールとバインド変数化


ケース１）

ID OPERATION OPTIONS OBJECT_NAME OPT COST ---- -------------------- --------------- ---------------------- --- ---------- 0 SELECT STATEMENT CHO 1 NESTED LOOPS 125 2 VIEW 116 3 SORT UNIQUE 116 4 TABLE ACCESS FULL ORDERS ANA 40 5 TABLE ACCESS BY INDEX ROWID EMPLOYEES ANA 1 6 INDEX UNIQUE SCAN EMP_EMP_ID_PK ANA

＜チェックポイント＞・インデックスが使用されていない・データを絞り込んでからＪＯＩＮしていない


ケース２）

ID OPERATION OPTIONS OBJECT_NAME OPT COST ---- -------------------- --------------- ---------------------- --- ---------- 0 SELECT STATEMENT CHO 2 1 FAST DUAL 2

＜チェックポイント＞・dualは内部的に発行するSQLが大量に発行される。


解決のヒント

ＳＱＬを書きなおす

ヒント句を使う

ＳＱＬ実行計画管理（ＳＰM)を使う

ＳＱＬチューニングアドバイザ（有償）

ＯＲＡ－３１１３

悪玉SQLを探し出せ！ - J-schooL悪玉SQLを探し出せ Jonathan...

Documents

Transcript of 悪玉SQLを探し出せ！ - J-schooL悪玉SQLを探し出せ Jonathan...