oracle direct seminar · (ここではitem表、date_dim 表、store_sales表の順に...

<Insert Picture Here>

複雑なSQLチューニングもラクにする！SQL監視機能とは

日本オラクル株式会社2010年4月7日

Oracle Direct Seminar

目次

• 従来のOracle Databaseチューニング機能

• 新機能「リアルタイムSQL監視」

• 活用例その1

• 活用例その2

• まとめ

• 参考情報

Copyright© 2010, Oracle. All rights reserved. 2

・SQL Serverからの移行アセスメント・MySQLからの移行相談

・PostgreSQLからの移行相談・Accessからの移行アセスメント

・Oracle Database バージョンアップ支援・Oracle Developer/2000 Webアップグレード相談

・パフォーマンス・クリニック・Oracle Database 構成相談

・Oracle Database 高可用性診断・システム連携アセスメント・システムセキュリティ診断

・簡易業務診断

無償技術サービスOracle Direct Concierge

http://www.oracle.com/lang/jp/direct/services.html

従来のOracle Databaseチューニング機能


Oracle Databaseの代表的なチューニング方法


カテゴリーチューニング方法

インスタンスのチューニングメモリー割り当ての変更

初期化パラメーターの変更

SQLの並列実行

オブジェクトのチューニング索引の作成

パーティショニング

マテリアライズド・ビューの作成

表の圧縮

SQLのチューニングバインド変数の使用

SQL文の修正

SQLプロファイルの作成

ハードウェアの増強 CPU/メモリーの増強

I/O帯域の増強

サーバーの追加

Oracle Enterprise Managerによるチューニング


カテゴリーチューニング方法オラクル製品 (の機能)

インスタンスのチューニングメモリー割り当ての変更 ADDM、メモリアドバイザ

初期化パラメーターの変更 ADDM

SQLの並列実行パラレルクエリ、インメモリー・パラレルクエリ

オブジェクトのチューニング索引の作成チューニングアドバイザ、アクセスアドバイザ

パーティショニングアクセスアドバイザ

マテリアライズド・ビューの作成アクセスアドバイザ

表の圧縮圧縮アドバイザ(DBMS_COMPRESSIONパッケージ)

SQLのチューニングバインド変数の使用 ADDM

SQL文の修正チューニングアドバイザ

SQLプロファイルの作成チューニングアドバイザ

ハードウェアの増強 CPU/メモリーの増強

I/O帯域の増強自動ストレージ管理(ASM)を利用したストレージ追加

サーバーの追加 Real Appication Clusters

赤太字・・・Oracle Enterprise Managerで提供される機能


オラクルの運用管理ソリューションOracle Enterprise Manager

• システムライフサイクル全体の効率化• プロアクティブな監視

• 深い診断と問題解決へのアドバイス

• オペレーションの自動化による効率化

• 構成情報の管理

• サービスレベル管理

• 仮想化環境への対応

ビジネス・サービス

ビジネス・ユーザー

ミドルウェア

データベース

オペレーティング・

システム

仮想化層

エンタープライズ・

アプリケーション

自動データベース診断モニター(ADDM)

• 自動データベース診断モニター (ADDM)

• AWR(自動ワークロードリポジトリ)のデータを定期的に自動診断

• パフォーマンスについての診断結果を表示

• 対処方法をアドバイス


負荷の高いSQL を検出

問題解決のための具体的な設定方法をアドバイス

SGA の領域不足を検出



行ロック待ちがパフォーマンスに影響を与えており、アプリケーションのロジック

を見直す必要がある

ブロックしているセッションも検索可能



リテラルの使用によりハード解析が多く発生

アドバイスは、

「バインド変数を使用する」、または

「”CURSOR_SHARING”をFORCEに設定する」

チューニングアドバイザ / アクセスアドバイザ


SQLチューニング・アドバイザ

高負荷なSQL文ADDMAWR

推奨索引の作成

SQL文の再構成

SQLプロファイルの作成

失効・欠落している統計の収集

複数のSQL文フィルタリング/ランキング

索引の作成

マテリアライズド・ビューの作成SQLアクセス・アドバイザ

推奨

パーティションの作成


チューニングアドバイザ / アクセスアドバイザチューニングのアドバイスの例

「上位SQL」から時間のかかっているSQLを特定し、チューニングアドバイザ

を実行

SQLのチューニング方法についてアドバイスを取得

(11gでは自動チューニングも可能)

従来のSQLチューニング


v$sessionなど複数の表を検索して問題のあるセッションを特定

SQL> select username, event, sid from v$session・・・

このセッションから長時間実行されているSQLをv$sqlなどから特定

SQL> select sql_id, elapsed_time/1000000, executions, disk_reads from v$sql・・

特定したSQLの実行計画を表示し、問題のある場所を探して対処策を模索

SQL> select * from table(dbms_xplan.display_cursor・・・

Statspackレポートを取得し、実行時間の長かったSQLを特定

SQL> @?/rdbms/admin/spreport.sql

begin snapに値を入力してください：

情報取得に多くの工数が必要

チューニング方法を見つけるまでに時間がかかりやすい

チューニング効果を事前に見極めるのが困難

：実行計画表示例

Statspackレポート例

Oracle Enterprise ManagerによるSQLチューニング


情報収集の負担が無い(データベースが自動収集)

自動診断やアドバイザにより迅速にチューニング方法を決定

自動的に見積もられたチューニング効果を見て判断可能

長時間実行されているSQLを特定自動的に診断された結果を参照

アドバイザによりSQLのチューニング方法を分析・チューニング実施

アドバイスに従ってチューニング実施

新機能「リアルタイムSQL監視」


より高度なSQLチューニングの手法


• 一定のチューニングができたが、さらに高い性能目標を満たすためにより細かいチューニングをほどこしたい

• 分析のため、実行計画の各ステップで何にどれくらい時間を使っているかを知りたい

• 細かいチューニングの後、どれくらい効果が出たかを詳しく確認したい

たとえば・・・

• インスタンスのチューニング• メモリー割り当ての変更• 初期化パラメーターの変更• SQLの並列実行(パラレルクエリー)

• オブジェクトのチューニング• 索引の作成• パーティショニング• マテリアライズド・ビューの作成• 表の圧縮

• SQLチューニング• バインド変数の使用• SQL文の修正• SQLプロファイルの作成

• ハードウェアの増強• CPU/メモリーの増強• IO帯域の増強• サーバーの追加

SQLトレースによる分析

より高度なSQLチューニングの手法SQLトレースについて

• SQL文が実際に実行された際の統計情報の出力• 「実行計画」の値はOracle Databaseが実行前に見積もったもの

• 実行時に実際にどのようになったかはSQLトレースから確認することができる

• EM画面あるいはDBMS_MONITORパッケージを使用して取得

• SQL全体、また実行ステップごとに以下の情報が取得される• 解析、実行、フェッチの各フェーズを行った回数

• CPU時間、経過時間

• 物理読取り、論理読取りでそれぞれ読み込んだブロック数

• 処理した行数

• ライブラリ・キャッシュ・ミスの回数など

• TKPROF• トレースファイルを整形するユーティリティ


より高度なSQLチューニングの手法SQLトレースファイルの例(整形後)


TKPROF: Release 11.1.0.6.0 - Production on 金 3月 26 16:49:21 2010

(略)

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.00 0.06 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 6 49.76 217.56 107265 108648 0 66

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 8 49.77 217.62 107265 108648 0 66

Rows Row Source Operation

------- ---------------------------------------------------

66 HASH GROUP BY (cr=108648 pr=107265 pw=107265 time=0 us cost=74184 size=149310 card=1422)

8127334 HASH JOIN (cr=108648 pr=107265 pw=107265 time=2287676 us cost=73633 size=846531420 card=8062204)

102000 TABLE ACCESS FULL ITEM (cr=7387 pr=7383 pw=7383 time=19963 us cost=2019 size=5712000 card=102000)

8127334 HASH JOIN (cr=101261 pr=99882 pw=99882 time=2110269 us cost=47733 size=398239366 card=8127334)

73049 TABLE ACCESS FULL DATE_DIM (cr=1373 pr=0 pw=0 time=417 us cost=377 size=730490 card=73049)

8127334 TABLE ACCESS FULL STORE_SALES (cr=99888 pr=99882 pw=99882 time=1922464 us cost=27571 size=316966026 card=8127334)

Elapsed times include waiting on following events:

Event waited on Times Max. Wait Total Waited

---------------------------------------- Waited ---------- ------------

SQL*Net message to client 6 0.00 0.00

direct path read 951 0.04 0.64

SQL*Net message from client 5 0.00 0.01

より高度なSQLチューニングの手法SQLトレースによる分析の課題


•グラフィカルではないので直感的に判断することが難しい

•パラレル実行の場合、I/Oの偏りを判別するのも大変

分析に時間がかかりやすい

• SQLトレースの設定後、問題のあるSQLを再現しないといけない

•再現するまで数時間～数日待つことも

•不定期に起こる問題の場合はより困難

再現待ちで時間が費やされる

• vmstatなど

•グラフ化する作業の手間もかかる

OS統計は別途取得する必要がある

• トレースファイルへの大量のI/Oが発生するため

オーバーヘッドに注意する必要がある

「リアルタイムSQL監視」

• 「リアルタイムSQL監視」とは• 実行中のSQLを自動で監視し、詳細な統計を取得

• EMのグラフィカルなレポート画面から分析ができる

• Oracle Database 11gからの新機能

• Tuning Packで提供

• 特長• GUIから簡単にボトルネックを突き止められる

• 再現待ちや特別な設定をせずすぐに分析を始められる

• レポートをエクスポートして外部で参照可能

• オーバーヘッドがほとんどない


特長1: GUIからのボトルネック分析分析するSQLの特定


時間のかかっているSQLが自動的に監視されリストされる (経過時間等でソート可能)

このSQL実行全体の統計

実行計画のステップごとの統計など

特長1: GUIからのボトルネック分析SQLの実行状況の詳細確認(1)


バッファ読取りよりI/Oバイト数が大幅に多い場合は、ストレージがボトルネック

になる傾向あり

SQL実行全体の期間(経過時間)のほか、DB時間や待機イベントの

内訳を把握できる

特長1: GUIからのボトルネック分析SQLの実行状況の詳細確認(2)


各ステップごとの待機イベントの発生個所やその内訳も

簡単にわかる

各ステップごとの実行タイミングや実行時間など

(ここではITEM表、DATE_DIM表、STORE_SALES表の順に読み取りながら結合している)

各ステップごとのメモリ(PGA)、一時表領域の使

用状況

実行計画で予想された行数と実際に返された行数の比

較も容易

特長1: GUIからのボトルネック特定パラレルクエリの実行状況


パラレルサーバーごとの統計を表示するビューが

現れる

全スレーブプロセスでDB時間やI/O量などが均等であることをグラフィカルに確認

できる

パラレルクエリの場合はパラレル度に関する情報

も表示される

特長1: GUIからのボトルネック特定実行中のデータ参照(「今ここ！」マーク)


現在実行中であることを示すマーク

進行状況がわかるため、「あとどれくらいで(バッチなどの)処理が終了するか」、見当をつけられる

「今ここ！」

特長1: GUIからのボトルネック特定SQL全文とバインド変数の参照


SQL_ID横の「i」マークをクリックすると、SQL全文に加え、実行時にバインド変数に入っていた値も参照可能

(Oracle Database 11g R2以降)

特長1: GUIからのボトルネック特定時系列グラフ


チューニング前後で「CPUがきちんと使われるようになったか」「IOスループットが改善したか」などを素早くチェック

時系列のデータもシームレスに分析可能

特長2: 再現待ちや特別な設定が不要

• SQL監視は自動的に実行される

• 自動実行される条件• 5秒以上のCPU時間またはI/O時間を消費しているSQL

または

• パラレル実行されているSQL

• 手動実行する方法• ヒント句 /*+MONITOR*/


[参考] Oracle Databaseパフォーマンス・チューニング・ガイド

10.4 リアルタイムSQL監視

http://download.oracle.com/docs/cd/E16338_01/server.112/b56312/instance_tune.htm#CACGEEIF

特長3: HTMLでのエクスポート


HTMLファイルにエクスポートすることで

環境に直接アクセスできない場所でも分析可能

ローカル(ブラウザを起動しているマシン)にHTMLで保存

可能

特長4: オーバーヘッドがほとんどない

• 監視情報はV$表に保存される• V$SQL_MONITOR, V$SQL_PLAN_MONITOR (11gで追加)

• V$SQLのサブセット

• 単一実行の統計(複数実行の累積や平均ではない)

• ディスクI/Oを伴うSQLトレースと違い、SGA上に格納される


SQL> select sql_id, sql_exec_start, last_refresh_time, sql_exec_id, sid, fetches from v$sql_monitor where sql_id=‘42nv7jt4dcz81’;

SQL_ID SQL_EXEC LAST_REF SQL_EXEC_ID SID FETCHES

-------------- -------- -------- ----------- ------ --------

42nv7jt4dcz81 10-04-01 10-04-01 16777216 170 6

期待される導入効果


開発・テスト時からのチューニング精度の向上

カットオーバー後に発生した性能問題の迅速な解決

長時間かかるSQL(バッチなど)への正確な対処

従来のチューニング

リアルタイムSQL監視を使用したチューニング

V$表やStatspackによる切り分け

SQLトレース設定、OSスクリプト作成

再現待ち集めた情報の整形、分析

SQL監視結果の分析時間

活用例その1


障害発生！データベーストラブル対応24時

• データ投入のバッチジョブが明け方になっても終わらない• ジョブコントローラーからアラート通知

• 後続のバッチジョブも控えている

• 朝9時までに解決しないとオンライン業務に影響が出る


ジョブコントローラー

原因は？

すぐに解決するか？？

バッチを停止するか？完了するまで待つか？

いままでなら・・・問題の切り分け

• 分析用の情報を取得

• データベース全体か、バッチ処理セッションの問題かを分析


$sqlplus / as sysdba

SQL>@lockchk.sql

$vmstat

$iostat

KROWNで発見したハング時の情報取得スクリプトを利用。3分間隔で3回取得

OS側の情報も取得

障害対処用のスクリプトを準備していなければ、作成する時間も必要

各情報を関連付けるのが大変

量も多い

時間は過ぎていく・・・

いままでなら・・・(参考）ハング時に取得する情報

--- begin [lockchk10.sql] ---

define spoolfile = &1

spool &spoolfile

alter session set nls_date_format = 'YYYY-MM-DD

HH24:MI:SS';

alter session set timed_statistics = true;

alter session set max_dump_file_size = UNLIMITED;

set feedback on

set term on

set wrap on

set trimspool on

set pagesize 1000

set linesize 2000

set numwidth 10

set echo on

Select to_char(sysdate) start_time from dual;

alter session set events 'immediate trace name systemstate

level 10';

alter session set events 'immediate trace name

hanganalyze level 3';

column host_name format a20 tru

;

select instance_name, host_name, version, status, startup_time from

v$instance;

select * from v$session;

select * from v$process

select * from v$bgprocess;

select * from v$lock;

select * from v$locked_object;

select * from v$session_wait;

select * from v$latch;

select * from v$latchholder;

select * from v$rowcache;

set echo off

Prompt; Prompt Output file name is:;

define spoolfile

Prompt;Prompt ALERT.LOG and TRACE FILES are located in:;

column host_name format a12 tru

column name format a20 tru

column value format a60 tru

select distinct i.host_name, p.name, p.value from v$instance i,

v$parameter p where p.name like '%_dump_dest' and p.name !=

'core_dump_dest';

select to_char(sysdate) end_time from dual;

spool off

exit

--- end [lockchk10sql] ---


いままでなら・・・実行中のSQL確認と対処の判断

• 採番テーブルのロック待機のセッションを複数発見

• ロックを獲得しているセッションを特定• 採番テーブルをUpdate後、commitしないまま

• 待機イベントdb file scattered readが発生している

• このSQLと実行計画を確認

• Insert-Select文であることが判明

• 処理を止めてしまう？処理完了を待つ？どうする？• 処理が終わらないと他の待機セッションもそのまま

• 再発防止のため、SQLはどうチューニングしたらよいのだろう？

• 詳細をとっておきたいけれどSQLトレースを仕掛けるような余裕もなさそう

• ・・・・・


SID112SID116

SID122

採番テーブル

SID97

“insert into order_detail select

id, c_name from ・・・”

もう時間が・・・・・

V$表へのSQLを書くだけでも時間がかかる

しかもSQL*Plusではフォーマットも考えないと見づらい

update

Oracle Enterprise Managerを使えば・・・問題の切り分け


データベースの状態をおおまかに把握

複数セッションで待機が発生している

OS側のリソースは問題ないようだが、OracleプロセスがCPUを使っている



アクティブセッションの状態を確認

行ロック待機を表す”Application”が多い

この待機は複数のSCOTTのセッションで発生しており、同一のUPDATE文で待っているらしきことが一目でわかる



セッションID126の処理がブロック原因になっている

セッションID126の詳細は？(次ページ→)

ブロックされているセッション



リアルタイムでグラフィカルな情報により情報取得、分析にかかる時間を大幅に短縮

セッションID126の処理はINSERTで待機イベントはdb file scattered

read（全表検索）だ


「SQL監視」タブをみると、確かに実行中のSQLが一つある

元の表からのselectが94％まで進んでいるので、このまま進める

ことにしよう

「いまどれくらい進んでいるか？」が簡単にわかるため冷静に素早く対処することができた

Oracle Enterprise Managerを使えば・・・対処方法の判断


このinsert文に対してチューニング・アドバイザを実行したところ、「索引の作成」が最も効果がある

とのアドバイス

一次対応完了後、チューニングも行うことができた

Oracle Enterprise Managerを使えば・・・再発防止策の調査・実行

実行計画を比較すると３倍以上の効果が見込めることがわかる

チューニングアドバイザ

活用例その2


チューニングの効果を知りたい

• SQLの並列実行(パラレル・クエリー)によりチューニング• Oracle Database 11g R2では「インメモリ・パラレル・クエリー」が登場

• 通常のパラレル・クエリーでは、高速化するもののディスクI/Oがボトルネックとして残ることが多い

• TABLE ACCESS FULL時に「direct path read」が大量発生

• 「インメモリ・パラレル・クエリー」を使用することで、ディスクI/Oが劇的に減りCPU使用率が向上し、SQLの高速化を実現

• どうやって効果を確認するか？• 実行計画、待機イベント、パーティションごとのI/O、CPU統計・・・


[参考] インメモリー・パラレル・クエリーについて

40X

9X

インメモリー・パラレル・クエリーの詳細については、Oracle GRID Centerにて公開されているホワイトペーパーおよび検証報告をご参照ください

http://www.oracle.co.jp/solutions/grid_center/nec/index.html

http://www.oracle.co.jp/solutions/grid_center/nssol/index.html

チューニング前 (シリアル・クエリー)


表のフルスキャンにより13GBのI/Oが発生、「db file

scattered read」が待機イベントのほとんどを占めている

16スレッド(4コア×2CPU×HT)利用できるのにもかかわらず、1スレッド分も使い切れていない

I/Oスループットはわずか30MB/sほど

チューニング後(パラレル・クエリー)


シリアル・クエリーと比較して、CPU使用効率は改善(平均5スレッドほど)しているが、ストレージのボトルネックにより、まだ空きリソースがある

今回のストレージの最大性能である350MB/sほどに達している

パラレル化されたことで所要時間が改善された

しかし、引き続き13GBのディスクI/Oが「direct path

read」を発生させて、ボトルネックになっている

パラレル化されている

チューニング後(インメモリ・パラレル・クエリー)


I/Oが無くなったため、I/Oスループットのグラフも空に

インメモリ・パラレル・クエリにより、I/Oが無くなった！

まとめ


まとめ

• 「リアルタイムSQL監視」• 実行中のSQLを自動で監視し、詳細な統計を取得

• EMのグラフィカルなレポート画面から分析ができる


開発・テスト時からのチューニング精度の向上

カットオーバー後に発生した性能問題の迅速な解決

長時間かかるSQL(バッチなど)への正確な対処

参考情報


参考情報

• Oracle Databaseパフォーマンス・チューニング・ガイド• 10.4 リアルタイムSQL監視

• http://download.oracle.com/docs/cd/E16338_01/server.112/b

56312/instance_tune.htm#CACGEEIF

• Oracle Database 11g: Real-Time SQL Monitoring

• http://www.oracle.com/technology/products/manageability/dat

abase/sqlmonitor.html (英語)

• サンプルのアクティブレポートを見ることができます

• ホワイトペーパー• http://www.oracle.com/technology/products/manageability/dat

abase/pdf/wp/owp_sql_monitoring.pdf (英語)


OTN×ダイセミでスキルアップ!!

※OTN掲示版は、基本的にOracleユーザー有志からの回答となるため100%回答があるとは限りません。ただ、過去の履歴を見ると、質問の大多数に関してなんらかの回答が書き込まれております。

Oracle Technology Network(OTN)を御活用下さい。

・技術的な内容について疑問点を解消したい！・一般的なその解決方法などを知りたい！・セミナ資料など技術コンテンツがほしい！

技術的な疑問点は、OTN掲示版の

「データベース一般」へ

http://otn.oracle.co.jp/forum/index.jspa?categoryID=2

過去のセミナ資料、動画コンテンツはOTNの「OTNセミナーオンデマンドコンテンツ」へ

http://www.oracle.com/technology/global/jp/ondemand/otn-seminar/index.html

※ダイセミ事務局にダイセミ資料を請求頂いても、お受けできない可能性がございますので予めご了承ください。ダイセミ資料はOTNコンテンツオンデマンドか、セミナ実施時間内にダウンロード頂くようお願い致します。


OTNセミナーオンデマンドコンテンツ期間限定にて、ダイセミの人気セミナーを動画配信中!!

ダイセミのライブ感はそのままに、お好きな時間で受講頂けます。

※掲載のコンテンツ内容は予告なく変更になる可能性があります。期間限定での配信コンテンツも含まれております。お早めにダウンロード頂くことをお勧めいたします。

OTN オンデマンド


オラクルクルクルキャンペーン

Enterprise Editionはここが違う!!

•圧倒的なパフォーマンス!

•データベース管理がカンタン!

•データベースを止めなくていい!

• もちろん障害対策も万全!

Oracle Databaseのライセンス価格を大幅に抑えて

ご導入いただけます

詳しくはコチラhttp://www.oracle.co.jp/campaign/kurukuru/index.html

あのOracle Database Enterprise Editionが超おトク!!

お問い合わせフォームhttp://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

多くのお客様でサーバー使用期間とされる

5年間にライセンス期間を限定

•期間途中で永久ライセンスへ差額移行

• 5年後に新規ライセンスを購入し継続利用

• 5年後に新システムへデータを移行


http://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

Oracle Direct 検索

あなたにいちばん近いオラクル

Oracle Directまずはお問合せください

Web問い合わせフォームフリーダイヤル

専用お問い合わせフォームにてご相談内容を承ります。

※フォームの入力には、Oracle Direct Seminar申込時と同じログインが必要となります。

※こちらから詳細確認のお電話を差し上げる場合がありますので、ご登録されている連絡先が最新のものになっているか、ご確認下さい。

0120－155－096

※月曜~金曜 9:00~12:00、13:00~18:00

（祝日および年末年始除く）

システムの検討・構築から運用まで、ITプロジェクト全般の相談窓口としてご支援いたします。

システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。



日本オラクル株式会社無断転載を禁ずこの文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

本プレゼンテーションは、情報提供を唯一の目的とするものであり、いかなる契約書または合意書に組み込むことはできません。

oracle direct seminar · (ここではitem表、date_dim 表、store_sales表の順に...

Documents