Post on 28-Jan-2021
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を探し出せ
いったい何が原因になり得るのか?
SQLのプランが悪くなった?
OSの問題?
ディスクIOの問題?
ネットワークの問題(RACの場合)
悪玉SQLを探し出せ
アラートログにでも出てくれればいいが、 正常に動いてはいるのなら、何も出してくれない。
様々な要素をどう効率よく確認するかが 解決を早くする!
悪玉SQLを探し出せ
Jonathan Lewis氏に聞いてみた。
この問題は難しく、 必ずしも同じパターンでいつも対応できる ものではない。 だが、一般論としてお話はできる。
Oracle Ace トラブルシューティングや SQLオプティマイザが専門
悪玉SQLを探し出せ
一般的な確認順
OS CPUの確認 TopコマンドなどでOSのCPUを確認する
SQLの確認 現在動いている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があったら、そいつが怪しいです。
悪玉SQLを探し出せ
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を探し出せ
SQL_IDを探したら・・・
select sql_text from v$sqltext
Where sql_id = ‘XXXXXXX’ order by piece ;
SQLをみてみましょう。
SQL_IDからSQLテキストを導き出します。
悪玉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がどのように実行されているかを見てみます。 まずは、どんな実行計画があるか見てみましょう。
悪玉SQLを探し出せ
SID_ID SQLに振られたID
PLAN_HASH_VALUE 実行計画の値
EXECUTIONS 実行回数
OPTIMIZER_COST オプティマイザが計算したコスト(実行負荷)
XXXX_WAIT_TIME XXXXによる待機時間(5つの総計が処理時間)
BUFFER_GETS 論理読み込み数
PHYSICAL_READ_BYTES 物理読み込み数
V$SQL
悪玉SQLを探し出せ
本当にSQLが悪いのか?
悪玉SQLを探し出せ
遅いSQLが悪いとも限らない
バッチ処理で時間がかかるSQL
そもそも処理量が多い(分析系)
ハードパース処理
普段の状態との比較をする必要がある
悪玉SQLを探し出せ
普段の状態をどう調べるか
Statspack スナップショット間のデータベースの状態を確認できる。 デフォルトで1時間に1回取得する。
AWR スナップショット間のデータベースの状態を確認できる。 期間比較やアドバイス機能あり(有償)
v$session 現在データベースにあるセッション情報を確認できる。
普段の状態
現在の状態
ASH (Active Session History)
データベースにあるセッション情報の履歴を確認できる。 (有償)
Enterprise Manager パフォーマンスタブで現在のデータベースの状態を 確認できる。(有償)
悪玉SQLを探し出せ
被害者と加害者
注意すべきなのは、 待機しているセッションは 「被害者」であること。 被害者を無くするのではなく、 「加害者」をどうするか考える のが重要。
悪玉SQLを探し出せ
待機イベント
待機イベントとは、 プロセスがSQLを処理するために(CPUを使わずに)待たなくては いけない出来事のこと。 I/Oやロック競合などの情報を 確認できる。
図)buffer busy waitの例
悪玉SQLを探し出せ
待機イベント例(1) db file sequencial read
ファイル読み込み (単一ブロック)による待機
待機させられている
サッポロラガーがあるか メニュー確認しているファイル読込)で 店員さんを待たせている
悪玉SQLを探し出せ
待機イベント例(2) free buffer waits
バッファキャッシュに 空きが無くて待機している。
3人で来たが2席しか空いていない
SQLチューニングの基礎
どうやってチューニングするのか?
チューニングにはどのような方法が あるのだろうか?
SQLチューニングの基礎
実行計画の取得
まずは事前準備
GRANT PLUSTRACE to USERS;
権限の取得(sysdbaにて実行)
@?/rdbms/admin/utlxplan.sql
PLAN_TABLEの作成(なければ)
SQLチューニングの基礎
実行計画の取得
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実行
SQLチューニングの基礎
実行計画の中身(1)
実行計画 ---------------------------------------------------------- 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)
SQLチューニングの基礎
実行計画の中身(2) 統計 ---------------------------------------------------------- 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チューニングの基礎
主な問題
インデックスが無い・使用されない
表の結合と絞り込みの問題
ライブラリキャッシュが有効に使われていない
インデックスを貼る、外部表で条件がある場合等、SQL記述ルールとバインド変数化
SQLチューニングの基礎
ケース1)
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
<チェックポイント> ・インデックスが使用されていない ・データを絞り込んでからJOINしていない
SQLチューニングの基礎
ケース2)
ID OPERATION OPTIONS OBJECT_NAME OPT COST ---- -------------------- --------------- ---------------------- --- ---------- 0 SELECT STATEMENT CHO 2 1 FAST DUAL 2
<チェックポイント> ・dualは内部的に発行するSQLが大量に発行される。
SQLチューニングの基礎
解決のヒント
SQLを書きなおす
ヒント句を使う
SQL実行計画管理(SPM)を使う
SQLチューニングアドバイザ(有償)
ORA-3113