https://www.climb.co.jp/soft/webseminar/2020/0206/ 後回しにされがちなチューニングを簡単に、今日から始めてみませんか？ データベースがなぜ遅くなるのか、ボトルネックがどこにあるのか、どうすれば改善できるのか、などパフォーマンスでお困りではありませんか？ そんな悩みを解決し、データベースのパフォーマンスを管理する方法をOracleを例にして、以下の5つの要素から解説します。 ・応答時間の監視 ・実行計画の確認 ・オブジェクト情報の収集 ・駆動テーブルの特定 ・無駄の多い処理を排除 加えて上記のような要素を、可視化し、特定できる『Database Performance Analyzer(DPA)』を合わせてご紹介します。難しいイメージのあるDBパフォーマンスのチューニングもDPAを使用すれば簡単に実施できます。 下記URLをご覧ください。 https://www.youtube.com/watch?v=N3KR3Gg8AzA

1. コンサルいらずの
チューニングことはじめ
どこでもセミナー
2/6 17:00～

2. なぜチューニングが難しいのか
• SQLチューニングの問題
• 誰がすべきなのかわからない、DBA？開発者？
• どのSQLなのかわからない
• 広い範囲の知識が必要
• 技術的：実行計画、データアクセス、SQLデザイン
• ビジネス：どのような目的のSQL？
• 時間がかかる
• 大量のSQLステートメント
• ステートメントごとの違い
• 優先順位が低い
• ベンダーアプリケーション
• ハードウェアまたはシステムの問題が優先される
• 終わらない…

3. アジェンダ
•応答時間の監視
•実行計画の確認
•オブジェクト情報の収集
•駆動テーブルの確認
•無駄の多い処理を排除

4. 1．応答時間の監視
• 各ステップにおける待機時間を識別
• データベース内でのクエリ実行にかかった合計時間を把握
• OracleのWaitイベントが便利

5. Waitイベント情報
V$SESSION
SID
SERIAL#
USERNAME
MACHINE
PROGRAM
MODULE
ACTION
CLIENT_INFO
SQL_ID
SQL_CHILD_NUMBER
EVENT
P1TEXT
P1
P2TEXT
P2
P3TEXT
P3
STATE(WAITING, WAITED)
BLOCKING_SESSION
V$SQL
SQL_ID
SQL_FULLTEXT
PLAN_HASH_VALUE
CHILD_NUMBER
IS_BIND_SENSITIVE
IS_BIND_AWARE
IS_SHAREABLE
SQL_PROFILE
SQL_PATCH
SQL_PLAN_BASELINE
BIND_DATA
IS_REOPTIMIZABLE
IS_RESOLVED_ADAPTIVE_PLAN
V$SQL_PLAN
SQL_ID
PLAN_HASH_VALUE
CHILD_NUMBER
OPERATION
OBJECT_NAME
OTHER_XML
V$SQL_BIND_CAPTURE
SQL_ID
NAME
VALUE_STRING
DATATYPE_STRING
LAST_CAPTURED
V$SQLAREA
SQL_ID
EXECUTIONS
PARSE_CALLS
DISK_READS
BUFFER_GETS
DBA_OBJECTS
OBJECT_ID
OBJECT_NAME
OBJECT_TYPE

6. アクティブ・セッション履歴(ASH)
• V$ACTIVE_SESSION_HISTORY
• セッション統計用データウェアハウス
• Oracle 10g以上
• データサンプリング：毎秒
SELECT SAMPLE_TIME, INST_ID, SESSION_ID, SESSION_SERIAL#, SESSION_STATE, SEQ#,
EVENT, P1, P2, P3, WAIT_TIME, TIME_WAITED, PROGRAM, MODULE, SQL_ID,
SQL_OPCODE, BLOCKING_SESSION
FROM V$ACTIVE_SESSION_HISTORY
WHERE INST_ID=&1
AND SAMPLE_TIME BETWEEN TO_DATE('&BEGIN_TIME','YYYY/MM/DD HH24:MI:SS') AND
TO_DATE('&END_TIME','YYYY/MM/DD HH24:MI:SS')
ORDER BY SAMPLE_TIME;
Enterpriseエディションかつ、
Oracle Diagnostics Packが必要

7. 可視化するには？
• Database Performance Analyzer
DPA

8. Database Performance Analyzer
DPA
2017
2016 SP2
2014 SP2
2012 SP4
2008 R2 SP3
2008 SP4
Microsoft SQL Server
18.3.x 12.2.x 12.1.x 11.2.x
Oracle Database
SAP Sybase ASE
16 15.7 15.5
IBM Db2 LUW
11.1 10.5 10.1 9.7
MySQL
5.7.9 5.6.10
Percona 5.6および5.7
Maria 10.0、10.1、および10.2
Amazon RDS
Oracle MS SQL MySQL
Azure SQL Database

9. Database Performance Analyzer
Oracle SE
Oracle EE
Oracle RAC
Oracle Exadata
Oracle E-Business
Oracle PDB

10. 2．実行計画を確認
• 推定計画を当てにしすぎない
• 目隠しされたバインド変数またはデータタイプ
• SQLステートメントとDBMS_XPLAN.display
• トレース機能とTKPROF
• 自動トレース設定(on | trace | exp | stat | off)
• 有益な情報が多数含まれている
• 再現性のある事象に限る
• V$SQL_PLAN (Oracle 9i以上)
• 実際の実行計画
• DBMS_XPLAN.display_cursor を使用

11. 実行計画がどのように作られるのか
クエリ変換 – より効率的な
クエリを生成
プラン生成 – 異なるアクセ
スパスと結合タイプで複数
のプランを作成、コストが
最も低いプランを選択
推定 – セレクティビティ、
カーディナリティ、コスト
データディレクトリ
スキーマ定義
&
統計情報
解析されたクエリ
変換されたクエリ
クエリ＋推定
実行計画を作成するためにデフォルトプランが行ソース・ジェネレータに送信される
Init.oraのパラメータ
OPTIMIZER_FEATURES_ENABL
ED
OR拡張
ビュー・マージ
述語のプッシュ
サブクエリの解放
マテリアライズド・ビューによるクエリ再記述
スター型変換
インメモリ集計
テーブル拡張
結合の因数分解

12. 計画の履歴を確認
• クエリアドバイザ
DPA

13. 計画の履歴を確認
• 計画の履歴
DPA

14. 実行計画の調査
• コストの高いな操作を見つける
• 各ステップのコスト、行数、ステップごとの時間
• フルテーブルかインデックススキャンか
• 述語情報の確認
• バインド変数の解釈のされ方を把握する
• データ型の確認
• 暗黙的な変換
• フィルタリングの変換が適用されるステップを把握する
• 結合方式を確認
• ネステッドループ – 大きなテーブル、小さなテーブル（lookup)結合
• ハッシュ結合 – 大きなテーブル、大きなテーブル結合

15. どの最適化機能を使うべきか？
• Show parameter optimizer
• 実行計画のサポート
• SPM(SQL Plan Management ：ベースライン） / プロファイル / アウトライン / パッチ
• 動的統計、統計フィードバック、SQLディレクティブ
• Adaptive Cursor Sharing（バインド変数に合わせた最適化）
• 適応計画、自動再最適化
• Noteセクション

16. 3．オブジェクト情報の収集
• 実行計画のオブジェクトを理解
• テーブル定義、セグメントサイズ
• ビュー、行数、パーティショニング
• Where句の列を確認
• 列のカーディナリティ
• データの偏り / ヒストグラム
• 統計情報の古さ
• インデックスと制約の確認

17. 関連するオブジェクトを確認
DPA

18. 4．駆動テーブルの確認
• 実行計画の各ステップにおける実際のデータサイズを把握
• 結合(Right, Left, Outer)
• フィルタリング述語がいつ適用されるか
• データ読み取りの最終結果セットを比較
• 駆動テーブルを確認し、バッファを減らす
SELECT s.fname, s.lname, r.signup_date
FROM student s
INNER JOIN registration r ON s.student_id =
r.student_id
INNER JOIN class c ON r.class_id = c.class_id
WHERE c.name = 'SQL TUNING'
AND r.signup_date BETWEEN :beg_date AND
:beg_date +1
AND r.cancelled = 'N'
結合
フィルタリング述語

19. 5．無駄の多い処理を排除
• カーソル、行ごとの処理
• 並列処理
• OLTP環境×、大きなデータセットでのみ使用、追加のリソース
• db_linksを使用するネストされたビュー
• ワイルドカード(*)の乱用、where句なし
• 本当に必要な列のみをSelect、余分な列はI/O増加、コードベースSQL生成
• インデックス付きの列で関数(SUBSTR, TO_CHAR, UPPER,
TRUNC)を使用
• 頻繁に使用するようなら関数ベースインデックスも検討

20. より効率的なSQLを①
• SORTを減らす
• UNION ALLを使用できるならUNIONは使用しない（コスト）
• DISTINCTを必要以上に使用しない
• 複合/複数列インデックスを使用する場合、左端の列にアクセス
（Where句）
• クロス結合（直積・デカルト積）を避ける
• リテラル値の代わりにバインド変数を使用
• サブクエリを使用する場合、可能ならEXISTSを使用
• アクセスする必要のデータが5%未満ならインデックスを使用

21. より効率的なSQLを②
• 可能な限り、等価結合を使用
• use ‘not in’, !=, <>, not nullなどを避ける
• オプティマイザに委ねる
• 複雑な関数(NVL(col1,0), TO_DATE(), TO_NUMBER(),など)を避ける
• カーディナリティやセレクティビティの邪魔をしない
• 実行計画全体と結合方法に影響する可能性あり
• 複雑なビューを結合しない
• 全てのビューをインスタンス化して読み取り、読み取りデータの増大
• パーティションテーブルではWhere句でパーティションキーを使用
• パーティション・プルーニングで読み取りサイズを大幅削減

22. まとめ
応答時間の監視
実行計画の確認
オブジェクト情報の収集
駆動テーブルの確認
無駄の多い処理を排除
その他の要因
リソース不足
ロックなど
応答時間
の監視
実行計画、オブ
ジェクト情報
SQL改善

23. まとめ
応答時間の監視
実行計画の確認
オブジェクト情報の収集
駆動テーブルの確認
無駄の多い処理を排除
その他の要因
リソース不足
ロックなど
応答時間
の監視
実行計画、オブ
ジェクト情報
SQL改善
DPA

24. DPAではじめませんか？
•SQLチューニングの問題＞簡単に共有可能
•広い範囲の知識が必要＞アドバイザ機能
•時間がかかる＞グラフだから一目でわかる
•優先順位が低い＞片手間でも簡単に
•終わらない…＞毎日でも苦にならない

25. 製品情報
• 弊社製品サイト
https://www.climb.co.jp/soft/dbpanalyzer/
• その他 取り扱い製品
• 使用したプレゼンはSlideShareにもアップ予定です。
https://www.slideshare.net/climb_soft/
異種データベース間の双方向にレプリケーション
すべてのデータ統合プロジェクトを効率的に