Technical Discussion Night ~ 今宵のテーマ : DB 12c クエリー オプティマイザ ( パフォーマンス チューニング ) を語ろう ~ 日本オラクル株式会社クラウド テクノロジー事業統括 Database & Exadata プロダクトマネジメント本部 Copyright 2017, Oracle and/or its affiliates. All rights reserved.
以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます Oracle と Java は Oracle Corporation 及びその子会社 関連会社の米国及びその他の国における登録商標です 文中の社名 商品名等は各社の商標または登録商標である場合があります
Technical Discussion Night ~ DB 12c クエリー オプティマイザ ( パフォーマンス チューニング ) を語ろう ~ 皆様が 本当に必要としている技術や Tips について 熱く語り合いましょう! お申し込み時に頂いたご質問に対して 可能な限り 日本オラクルのエキスパートが回答させて頂きます 本日のファシリテーター 日本オラクル株式会社クラウド テクノロジー事業統括 Database & Exadata プロダクトマネジメント本部ディレクター柴田長 3
Topic#1 実行計画って どう読めばよいのですか? will be answered by Oracle University Copyright 2017, Oracle and/or its affiliates. All rights reserved.
Profile Oracle ユニバーシティーシニア インストラクター中村真理子 前職では 開発に携わりながら DBA もやっていました ( 苦労話が理解できる ) インストラクターです 今回は 2 つの質問にお答えします 5
実行計画の基本的な読み方が知りたいです 基本の読み方 ---------------------------------------------------------------------------------------- Id Operation Name Rows Bytes Cost (%CPU) Time ---------------------------------------------------------------------------------------- 0 SELECT STATEMENT 3 66 4 (0) 00:00:01 1 NESTED LOOPS 3 66 4 (0) 00:00:01 2 TABLE ACCESS BY INDEX ROWID DEPT 1 13 1 (0) 00:00:01 * 3 INDEX UNIQUE SCAN PK_DEPT 1 0 (0) 00:00:01 * 4 TABLE ACCESS FULL EMP 3 27 3 (0) 00:00:01 ---------------------------------------------------------------------------------------- インデントが一番深いものから実行 同一インデントならば上のステップを実行 アクセスパス :TABLE ACCESS FULL TABLE ACCESS BY INDEX ROWID 結合方法の次に駆動表 6
結合方法 ネステッド ループ結合 ---------------------------------------------------------------------------------------- Id Operation Name Rows Bytes Cost (%CPU) Time ---------------------------------------------------------------------------------------- 0 SELECT STATEMENT 3 66 4 (0) 00:00:01 1 NESTED LOOPS 3 66 4 (0) 00:00:01 2 TABLE ACCESS BY INDEX ROWID DEPT 1 13 1 (0) 00:00:01 * 3 INDEX UNIQUE SCAN PK_DEPT 1 0 (0) 00:00:01 * 4 TABLE ACCESS FULL EMP 3 27 3 (0) 00:00:01 ---------------------------------------------------------------------------------------- 1 駆動行ソースがスキャンされる 2 駆動行ソースから 1 件ずつ 内部行ソースを検索 3 結果行が返される DEPT( 駆動表 ) EMP( 内部表 ) 1 1 件読み込み 3 2 件目 ( 全件繰り返し ) LOOP 2 探す 7
結合方法 ハッシュ結合 ---------------------------------------------------------------------------------------- Id Operation Name Rows Bytes Cost (%CPU) Time ---------------------------------------------------------------------------------------- 0 SELECT STATEMENT 3 66 4 (0) 00:00:01 * 1 HASH JOIN 3 66 4 (0) 00:00:01 2 TABLE ACCESS BY INDEX ROWID DEPT 1 13 1 (0) 00:00:01 * 3 INDEX UNIQUE SCAN PK_DEPT 1 0 (0) 00:00:01 * 4 TABLE ACCESS FULL EMP 3 27 3 (0) 00:00:01 ---------------------------------------------------------------------------------------- 1 駆動表 : 結合キーを元にハッシュ表を作成 2 内部表 : 結合キーを順にハッシュ表をハッシングし 合致する行を特定 DEPT ハッシュ表 EMP HASH HASH PGA 8
結合方法 ソート マージ結合 ---------------------------------------------------------------------------------------- Id Operation Name Rows Bytes Cost (%CPU) Time ---------------------------------------------------------------------------------------- 0 SELECT STATEMENT 14 308 5 (0) 00:00:01 1 MERGE JOIN 14 308 5 (0) 00:00:01 2 TABLE ACCESS BY INDEX ROWID DEPT 4 52 2 (0) 00:00:01 3 INDEX FULL SCAN PK_DEPT 4 1 (0) 00:00:01 * 4 SORT JOIN 14 126 3 (0) 00:00:01 5 TABLE ACCESS FULL EMP 14 126 3 (0) 00:00:01 1 表 1 の結果セットを 結合列でソート 2 表 2 の結果セットを 結合列でソート 3 表 1 のデータセット各行に対して 2 つ目の開始点が検索され 結合されない行が検出されるまでスキャン DEPT 1 並び替えて EMP 2 並び替えて 3 マージ PGA 9
結合方法 デカルト結合 ----------------------------------------------------------------------------- Id Operation Name Rows Bytes Cost (%CPU) Time ----------------------------------------------------------------------------- 0 SELECT STATEMENT 56 1064 10 (0) 00:00:01 1 MERGE JOIN CARTESIAN 56 1064 10 (0) 00:00:01 2 TABLE ACCESS FULL DEPT 4 52 3 (0) 00:00:01 3 BUFFER SORT 14 84 7 (0) 00:00:01 4 TABLE ACCESS FULL EMP 14 84 2 (0) 00:00:01 ----------------------------------------------------------------------------- 一方のデータソースにあるすべての行を 他方にあるすべての行と直積演算 DEPT 全ての組み合わせを作成 EMP 直積演算 10
想定通りの結合方法にならない場合は ex. 結合行は少ないのに ハッシュ結合が選択されている 確認ポイント 統計情報 誤ったヒント句 構文エラーを含む 11
Topic#2 良くある待機イベントが知りたい will be answered by Oracle University Copyright 2017, Oracle and/or its affiliates. All rights reserved.
よくある待機イベント その 1: buffer busy waits Buffer busy waits プロセス A プロセス B 更新のためにサーバプロセスが確保している 確保済みバッファ へ 別のプロセスがアクセスしようとすると buffer busy waits が記録される 13
buffer busy waits の待機が多い場合は アプリケーション競合をなくす SQLチューニングで アクセスするブロックを極力減らす DML 操作を分散して 競合をなくす索引が原因なら 再構築して断片化を減らす 14
よくある待機イベント その 2: log file sync COMMIT ユーザー セッションをコミットするには セッションの REDO 情報を REDO ログ ファイルにフラッシュする必要がある REDO ログ ファイルに書き込むまでの間 フォアグラウンド プロセスは待機する この待機が log file sync 15
log file sync の待機が多い場合は COMMIT 回数が多すぎる REDO ログファイルがいっぱいになるのがはやすぎる 書き込み速度に原因がある 確認ポイント - COMMIT をまとめて行う - REDO ログサイズを大きくする - 低速ディスクから高速ディスクへ切り替える 16
Topic#3 性能の良い SQL の書き方を教えて下さい will be answered by Oracle Consulting Service Copyright 2017, Oracle and/or its affiliates. All rights reserved.
皆様の声 (from アンケート ) よいSQLの書き方が知りたい パフォーマンスが向上するSQLの書き方 優秀なSQLコーディングルールの実例などがあれば数多く教えてください パフォーマンスの良いSQLの書き方を知りたい また 良いSQLの書き方だけではなく 悪いSQLの書き方も知りたいです よいSQLの書き方 ( 複数の副問合せ ) を知りたい 本題の前に ちょっと前半を振り返ってみる 18
DDD 2016 前半資料より Oracle Database 12cR1 における 実行計画生成の全体像 予測精度向上のための 様々なクエリー オプティマイザ機能をご紹介 凡例 実線( ) 必須情報 破線( ) 追加情報 ⑥ヒント句 ⑦アウトライン SPM(11g以降) ⑧Bind Peek/ 適応カーソル共有 ⑨SQL Profile ①SQLテキスト/Bind変数 ②オブジェクト構造 オプティマイザ (CBO) ⑩Cardinality Feedback(11gR2以降) ⑪Dynamic Sampling (12c以降:動的統計) ③初期化パラメータ ④システム統計 ⑫適応計画(12c以降) ⑤オプティマイザ統計 実行計画 実行計画 の生成 実データ SQL性能 (レスポンス) ⑭SQL計画ディレク ティブ(12c以降) ⑬SQLワークロード (COL_USAGE$) H/W 19
SQL 性能で重要になるのは CBO の予測精度 SQL の性能を上げるには 良い実行計画 が必要 良い実行計画 を生成するには CBO の予測精度 を上げると云う考え方が重要 SQL の書き方も重要なんですが それ以外の Input の精度も上げていくことが必要です でも全ての Input を闇雲に揃えて行くのは はっきり言って現実的ではない ではどう云う風に考えて行くかというと 20
全体最適 と 個別最適 の適用イメージ DDD 2013 SQL チューニングに必要な考え方と最新テクニックより 長 適切な統計 適切な索引 適切なSQL ヒストグラム 実行計画 拡張統計最適化機能 (Bind Peek, Dynamic Sampling, Cardinality Feedback, 等 ) 全体最適 ヒント SPM(or アウトライン ) SQLプロファイル 個別最適 処理時間短 低 SQL の重要度 高
全体最適 と 個別最適 の適用イメージ ( 少し追記 ) 長 適切な統計 適切なSQL 適切なデータ構造 実行計画最適化機能 (Bind Peek, Dynamic Sampling, Cardinality Feedback, 等 ) 適切な索引 ヒストグラム 拡張統計 SQL 計画ディレクティブ 全体最適 ヒント SPM(or アウトライン ) SQLプロファイル 個別最適 処理時間短 低 SQL の重要度 高
基本的な部分を良くして全体の予測精度を底上げする 長 適切な統計 適切なSQL 適切なデータ構造 実行計画最適化機能 (Bind Peek, Dynamic Sampling, Cardinality Feedback, 等 ) 適切な索引 ヒストグラム 拡張統計 SQL 計画ディレクティブ 全体最適 ヒント SPM(or アウトライン ) SQLプロファイル 個別最適 処理時間短 低 適切な統計 適切な SQL 適切なデータ構造 各種実行計画の最適化機能 で SQL 全体の実行計画予測精度を 上げていく SQL 適切なの重要度 ~の定義については後述高
適切な ~ の定義とは? アンチパターンの回避 では 適切な SQL 適切な統計 適切なデータ構造 の定義とは何だろうか? それは CBO の予測精度を下げる要素を回避 / 排除する事 だと考えます CBO の予測精度を下げる要素 で 最も一般的なのは アンチパターン SQL データ構造 統計 に関する 代表的な アンチパターン をご紹介 24
SQL のアンチパターン 25
参考 : ハズレの実行計画例 結合表が多い (1/2) Oracle のオプティマイザは 実行計画作成時に表の適切な結合順序を見つけるために全ての組み合わせを解析しようとします 結合する表が 3 つの場合 3!(3 の階乗 )=3 2 1=6 通り DDD 2016/ 前半資料より 結合する表が 2 つの場合 2!(2 の階乗 )= 2 1=2 通り 表 A 表 B 表 A 表 B 表 C 表 A 表 C 表 B 表 B 表 A 表 C 表 B 表 A 表 B 表 C 表 A 表 C 表 A 表 B 表 C 表 B 表 B 26
参考 : ハズレの実行計画例 結合表が多い (2/2) 結合する表が多い場合は Oracle のオプティマイザは結合順序の解析を途中で止めます 全組み合わせの解析には 時間が掛かり過ぎるからです デフォルトで 2000 通りまでの結合順序を解析します 結合表が多過ぎる SQL は 適切な結合順序に辿り着けず ハズレの実行計画を引くリスクが高いと言えます 結合する表が 8 つの場合 8!(8 の階乗 )=8*7*6*5*4*3*2*1=40320 通り DDD 2016/ 前半資料より 表 A 表 B 表 C 表 D 表 E 表 F 表 G 表 H 27
DDD 2013 SQL チューニングに必要な考え方と最新テクニックより 参考 : 某チューニング案件の超巨大 SQL 実行計画 SQL テキストで 6700 行以上 40 表以上を結合した SELECT 文の実行計画 実行計画のステップ数換算で 実に 500 ステップ以上の超巨大 SQL ( 中略 )
DDD 2013 SQL チューニングに必要な考え方と最新テクニックより WHERE 句の列 ( カラム ) に関数を適用 WHERE 句の列 ( カラム ) に関数を適用しているのは SQL のアンチパターンの一つです SELECT /*+ MONITOR */ A.* FROM TEST_TABLE_A A, TBL_B B P_DATE 列にTO_CHAR 関数を適用 WHERE A.P_NO2 = B.P_NO AND A.P_CHAR = B.P_CHAR AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = '20120801'; 本パターンが性能劣化し易いのは 下記 2 つの理由に依ります (1). 列に作成された索引が使用されない (2). CBO が列統計を使用できず 実行計画の予測精度が落ちる
結合条件の欠如とそれによる直積 結合条件が欠如して直積 (MERGE JOIN CARTESIAN) が発生するのは 典型的なアンチパターンと言えます DEPT 全ての組み合わせを作成 EMP 直積演算 ----------------------------------------------------------------------------- Id Operation Name Rows Bytes Cost (%CPU) Time ----------------------------------------------------------------------------- 0 SELECT STATEMENT 56 1064 10 (0) 00:00:01 1 MERGE JOIN CARTESIAN 56 1064 10 (0) 00:00:01 2 TABLE ACCESS FULL DEPT 4 52 3 (0) 00:00:01 3 BUFFER SORT 14 84 7 (0) 00:00:01 4 TABLE ACCESS FULL EMP 14 84 2 (0) 00:00:01 ----------------------------------------------------------------------------- 30
View のネストや View 内の結合 View の View の View 一見シンプルな SQL なのに複雑な実行計画 ヒント等による実行計画制御もやり辛く 地獄 View_A View_C View_D SELECT * FROM TBL_A WHERE ~ View_B SELECT * FROM TBL_B WHERE ~ SELECT A.*, B.*, C.* FROM View_A A, View_B B, TBL_C C WHERE A.ID = B.ID AND B.PID = C.PID : TBL_C 一見シンプルな SQL SELECT * FROM View_D WHERE ID = XXX SELECT C1.* FROM View_C C1 WHERE C1.PID = ( SELECT MAX(C1.PID) FROM View_C C2 ) 複雑な実行計画 ------------------------------------------------ Id Operation Name ------------------------------------------------ 0 SELECT STATEMENT 1 HASH JOIN 2 HASH GROUP BY 3 HASH JOIN 4 TABLE ACCESS FULL SCAN TBL_A 5 HASH JOIN 6 TABLE ACCESS FULL SCAN TBL_B 7 TABLE ACCESS FULL SCAN TBL_C 8 HASH JOIN 9 TABLE ACCESS FULL SCAN TBL_A 10 HASH JOIN 11 TABLE ACCESS FULL SCAN TBL_B 12 TABLE ACCESS FULL SCAN TBL_C ------------------------------------------------
IN リストに指定する値が多い 下記のような IN リストに沢山の値を設定する SQL は Parse の負荷が高くなる傾向が有り 可能なら回避したい SELECT * FROM TBL_A WHERE C1 IN (:B1, :B2, :B3, :B4, :B5, :B6, :B7, :B8, :B9, :B10, :B11, :B12, :B13, :B14, :B15, :B16, :B17, :B18, :B19, :B20, :B21, :B22, :B23, :B24, :B25, :B26, :B27, :B28, :B29, :B30, :B31, :B32, :B33, :B34, :B35, :B36, : : :, :B719, :B720, :B721, :B722, :B723, :B724, :B725, :B726, :B727, :B728, :B729, :B730, :B731, :B732, :B733, :B734, :B735, :B73 6, :B737, :B738, :B739, :B740, :B741, :B742, :B743, :B744, :B745, :B746, :B747, :B748, :B749, :B750, :B751, :B752, :B753, :B7 54, :B755, :B756, :B757, :B758, :B759, :B760, :B761, :B762, :B763, :B764, :B765, :B766, :B767, :B768, :B769, :B770, :B771, :B 772, :B773, :B774, :B775, :B776, :B777, :B778, :B779, :B780, :B781, :B782, :B783, :B784, :B785, :B786, :B787, :B788, :B789, : B790, :B791, :B792, :B793, :B794, :B795, :B796, :B797, :B798, :B799, :B800, :B801, :B802, :B803, :B804, :B805, :B806, :B807, :B808, :B809, :B810, :B811, :B812, :B813, :B814, :B815, :B816, :B817, :B818, :B819, :B820, :B821, :B822, :B823, :B824, :B825, :B826, :B827, :B828, :B829, :B830, :B831, :B832, :B833, :B834, :B835, :B836, :B837, :B838, :B839, :B840, :B841, :B842, :B843, :B844, :B845, :B846, :B847, :B848, :B849, :B850, :B851, :B852, :B853, :B854, :B855, :B856, :B857, :B858, :B859, :B860, :B86 1, :B862, :B863, :B864, :B865, :B866, :B867, :B868, :B869, :B870, :B871, :B872, :B873, :B874, :B875, :B876, :B877, :B878, :B8 79, :B880, :B881, :B882, :B883, :B884, :B885, :B886, :B887, :B888, :B889, :B890, :B891, :B892, :B893, :B894, :B895, :B896, :B 897, :B898, :B899, :B900, :B901, :B902, :B903, :B904, :B905, :B906, :B907, :B908, :B909, :B910, :B911, :B912, :B913, :B914, : B915, :B916, :B917, :B918, :B919, :B920, :B921, :B922, :B923, :B924, :B925, :B926, :B927, :B928, :B929, :B930, :B931, :B932, :B933, :B934, :B935, :B936, :B937, :B938, :B939, :B940, :B941, :B942, :B943, :B944, :B945, :B946, :B947, :B948, :B949, :B950, :B951, :B952, :B953, :B954, :B955, :B956, :B957, :B958, :B959, :B960, :B961, :B962, :B963, :B964, :B965, :B966, :B967, :B968, :B969, :B970, :B971, :B972, :B973, :B974, :B975, :B976, :B977, :B978, :B979, :B980, :B981, :B982, :B983, :B984, :B985, :B98 6, :B987, :B988, :B989, :B990, :B991, :B992, :B993, :B994, :B995, :B996, :B997, :B998, :B999);
SQL アンチパターンのまとめ 結合表が多い SQL の結合を全て 6 表以下に抑えるのは難しいかもですが 40 表結合の超巨大 SQL とかは止めた方が良いです 実行計画ブレまくり WHERE 句の列 ( カラム ) に関数を適用 索引が使われなくなる ( 有名 ) と共に CBO の予測精度も低下 ( 無名?) します 結合条件の欠如とそれによる直積 (CARTESIAN) 予測精度の話とは若干ズレるのですが いわずもがななので View のネスト View 内の結合 View の View の View 地獄 一言で表すと地獄 ある程度のルール ( 制限 ) を設けるべき 後フェーズで発覚することが多くて 手遅れな場合も多いんですけどね IN リストに指定する値が多い 高負荷な Parse となり易い傾向
データ構造のアンチパターン 34
パフォーマンスで最も重要なのはデータ構造 行方向で減らし ( 索引 パーティション ) 列方向で減らす ( カバリングインデックス ) 表 行を絞る 索引スキャン 仕事量を減らすにはデータ構造が肝 パーティション カバリングインデックス フルスキャン 列を絞る 索引 表 35
行き過ぎた正規化 ( データモデル ) 正規化が行き過ぎていると 結合表が多くなってしまう 下記例では 個人 のデータを取得するのに 7 表結合する必要がある 個人姓名 個人 ID 名前 ID 姓名 : 個人電話番号 個人 個人 ID 名前 ID 性別 ID 電話番号 ID 住所 ID 性別 ID : 個人住所 個人 ID 住所 ID 郵便番号 ID 番地番号建物名 : 郵便番号マスタ 郵便番号 ID 県 ID 市区町村 ID 番地名 : 個人 ID 電話番号 ID 電話番号電話番号種別 : 性別マスタ 性別 ID 性別 県マスタ 県 ID 県名 市区町村マスタ 市区町村 ID 市区町村名
オプティマイザ統計のアンチパターン 37
オプティマイザ統計のアンチパターン 0 件統計 /Null 統計 / 実体と乖離した古い統計 前半の資料でお話し済み 特に 0 件統計は典型的なアンチパターン 絶対回避すること! 索引や MView 実体表の 0 件統計 /Null 統計 こちらも前半の資料でお話し済み 通常の表は意識していても 索引や Mview の統計には気が付かないことも ( サブ ) パーティションの 0 件統計 /Null 統計 GLANURALITY => 'AUTO'( デフォルト ) だとサブパーティション統計が取られないので 'ALL', 'SUBPARTITION' 等を明示的に指定するようにしましょう
参考 : 統計アンチパターンのオススメ回避方法 性能テスト等の突入前に 以下のディクショナリをチェックして アンチパターン (0 件統計 /Null 統計 ) を確認するのがオススメです (DBA ALL USER)_TAB_STATISTICS (DBA ALL USER)_IND_STATISTICS これらのディクショナリには表 / 索引の統計が 以下の 3 段階全てで格納されており 網羅的なチェックが可能 グローバル統計 ( 表 / 索引全体の統計 ) パーティション統計 サブパーティション統計
まとめ SQL の性能を良くするには アンチパターンを回避して CBOの予測精度を向上! 40
Topic#4 SE(Standard Edition) でも SQL チューニングしたい! will be answered by Oracle Consulting Service Copyright 2017, Oracle and/or its affiliates. All rights reserved.
DBMS_XPLAN と SQL トレースで SE でも闘える! DBMS_XPLAN(.DISPLAY_CURSOR) の参考資料 SQL の実行計画に実行統計を併記して表示する方法 (DBMS_XPLAN.DISPLAY_CURSOR) (KROWN:141531) ( ドキュメント ID 1749298.1) DDD 2013 A-1 オラクル コンサルが語る! SQL チューニングに必要な考え方と最新テクニック http://www.oracle.com/webfolder/technetwork/jp/ondemand/ddd2013/a-1.pdf SQL トレースの参考資料 SQL トレースを使用した SQL チューニング (KROWN:137157) ( ドキュメント ID 1747064.1) EVENT: 10046 "SQL 文のトレースを有効にする ( バインド / 待機含む )" ( ドキュメント ID 1965967.1)
でも EE/Tuning Pack を諦めないで欲しい EE(Enterprise Edition) は高くて手が出ない? Oracle Database Cloud Service が有るじゃないか! Tuning Pack が使用可能な High Performance Package は時間当たり $6.72~ から利用可能 2017 年 2 月 24 日現在 詳細は下記 URL をご参照ください https://cloud.oracle.com/ja_jp/database/pricing
Topic#5 SQL チューニング関連でよくある問い合わせ will be answered by Oracle Customer Support Service Copyright 2017, Oracle and/or its affiliates. All rights reserved.
Profile データベースサポート部シニア プリンシパル サポートエンジニア松本尚子 1997 年新卒入社 サポートエンジニア歴 19 年 45
SQL が突然遅くなった 調査アプローチ 時間がかかっている要素の確認 STATSPACK OSWatcher Black Box を SQL 監視導入しましょう AWR/STATSPACK レポート STATSPACKのドキュメント : AWR/STATSPACK の SQLレポート $ORACLE_HOME/rdbms/admin/spdoc.txt SQLトレース Active Session History (ASH) OSWatcher Black Box (MOS Doc ID 1763622.1) 統計情報の内容確認 DBA_TAB_STATISTICS, DBA_TAB_COL_STATISTICS, DBA_IND_STATISTICS いつ収集されたものか LAST_ANALYZED 列 0 行で採取してしまっていないか NUM_ROWS 列 46
SQL が突然遅くなった 原因 ディスク関連の待機イベントの平均待機時間が延びている実行計画は変わっていない SQL 監視で Actual と Estimate に大きな差が見えるアクセスバッファ数がとても増えている 対処 ストレージの応答速度の確認 統計情報収集の運用確認 ディスク遅延が起きている可能性あり 適切な実行計画で実行されていない可能性あり 47
ヒント句を指定したが有効になっていないようだ 調査アプローチ コストベースオプティマイザトレース (event 10053) アウトラインヒント 原因 ヒント構文の間違い エイリアスを指定している場合はエイリアスをヒント句に ビューマージなどの考慮不足 複数のクエリブロックがある SQL へのヒント句指定は難しい SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR( <SQL_ID>', NULL, 'ADVANCED')); 出力の Outline Data の部分 対処 正しいヒント構文を使用 わからない場合はアウトラインヒントを参考に 固定 SQL 計画ベースライン (SPM) アウトラインヒントの導入 48
Oracle12.1 ってハードパースが遅くないですか オプティマイザのゴールはフェッチも含むトータルの実行時間を短くすること バージョンがあがるにつれオプティマイザの処理ステップ / 時間は増加傾向 調査アプローチ SQL トレース 原因 SQL の書き方 適応統計による最適化 対処 SQL の書き換え 適応統計機能の無効化 データベース パフォーマンスの MOS ドキュメント Doc ID 1946305.2 インフォメーション センター : データベースおよび Enterprise Manager 日本語ドキュメント 左メニュー : パフォーマンスを選択 49
みなさまの投稿をお待ちしております Twitter #OracleTechNight 50
Learn Oracle from Oracle オラクルユニバーシティでは SQL やデータベース インスタンスのパフォーマンス問題の診断 改善に役立つスキルを幅広く習得することができる研修コースを提供しています データベース チューニングの基礎から実践までわかりやすい講義と実機演習を通してじっくり しっかり身につけることができます Oracle Database 12c: SQL チューニングワークショップ コース概要 このコースでは SQL チューニングの方法論から実践までを学習します 自動 SQL チューニング コンポーネント EXPLAIN SQL Trace および TKPROF SQL*Plus AUTOTRACE などの診断ツールや機能を活用して チューニングが必要な SQL 文を特定して改善する方法を説明します くわえて 物理的なスキーマおよび SQL 構文を変更することによるオプティマイザの動作への影響についても学習します このコースで習得できる技術を活用することで オプティマイザの概念を理解して自動 SQL チューニング機能を活用することができるようになります Oracle Database 12c: パフォーマンス チューニング コース概要 このコースでは DBA に必要とされるパフォーマンス分析およびチューニング手法について学習します パフォーマンス分析のために必要とされる チューニンが必要な SQL 文を特定する方法 および統計の使用 オプティマイザを制御するためのプロファイルなど各種診断ツールを活用してパフォーマンス改善を行う方法を理解することができます また インスタンスのチューニングでは 問題の診断 主要なチューニング可能コンポーネントの詳細 およびインスタンスの動作への影響についても説明します 学習内容 効率の悪い SQL 文の識別 SQL 文を最適に実行するための改良 アプリケーション トレース 問い合わせオプティマイザの理解 実行計画の説明 オプティマイザ ヒントの効果的な使用 学習内容 SQL やインスタンスのパフォーマンス問題を監視および診断するツールの使い方 データベース アドバイザを使用したパフォーマンス問題への事前対応的な修正 問題素のある SQL 文の特定 およびチューニング Enterprise Manager を使用したインスタンスのパフォーマンス監視 Oracle インスタンスのコンポーネントのチューニング 日数 3 日間 日数 5 日間 51