Slide 1

Size: px
Start display at page:

Download "Slide 1"

Transcription

1 第 121 回夜な夜な! なにわオラクル塾 SQL チューニング & メモリチューニングに必要な考え方と最新テクニック 日本オラクル株式会社テクノロジー製品事業統括本部支社ソリューション本部西日本グループ 2014 年 03 月 12 日 THIRD PARTY COMPANY LOGO

2 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます Oracle と Java は Oracle Corporation 及びその子会社 関連会社の米国及びその他の国における登録商標です 文中の社名 商品名等は各社の商標または登録商標である場合があります 2

3 目的とゴール 目的 SQLチューニングで有効となるテクニックとメモリ障害の予防を知るゴール SQLチューニングにおける様々な 戦術 をつかむ ORA-4031 撲滅 共有プールの性質の理解 メモリ設計 監視のポイント 3

4 本セミナーの内容に関する注意 本資料の内容 製品仕様に関する正式な情報ではなく プロジェクトで調査を行い把握した内容を記載 プロジェクトで得られた経験を基にした 具体的な一次サイジングの指針および値 実際には 必要領域は処理内容や処理タイミングに依存するため テストによりサイズを検討ください 前提環境 Oracle Database 11g Release2 自動 SGA 管理 4

5 Program Agenda SQLと云う言語の特徴 予測 と 実測 の乖離を補正せよ! Oracle Database の機能を活用した最新テクニック 共有プールの基本的理解 設計 ~テスト~ 運用フェーズでの検討事項 管理方式選定 一次サイジング ( 自動 SGA 前提 ) 監視 チューニング ( 自動 SGA 前提 )

6 SQL と云う言語の特徴について

7 SQL という言語の特徴 (1) SQL と云う言語は 過去を振り返ってみても最も成功した言語 / 標準規格の一つ 何故成功したのか? それはどうやって (How) データを抽出するかを書かずに 何を (What) 抽出するかという 条件 のみを記述する仕様 多くの言語では 繰り返し (for~) や条件分岐 (if~) などのアルゴリズムを記述する必要がある アルゴリズムを書かない ( 書く必要が無い ) のが SQL と云う言語の最大の特徴 7

8 SQL という言語の特徴 (2) どうやって (How) データを抽出するか 即ちアルゴリズムの決定 制御は RDBMS のオプティマイザで行われる オプティマイザが決定したアルゴリズム = 実行計画 オプティマイザは SQL テキストや統計情報などを基に 適切な実行計画を予測して組み立てる 条件 のみを記述 アルゴリズムを決定 / 制御 プログラム SQL Optimizer データ 8

9 アルゴリズムを書かないことによるメリット アルゴリズムを書かないことによる最大のメリット言語の習得が 簡単 エンジニアではない現場のお客様でも SQL なら書くことは可能 習得が簡単ということは 生産性の高さ = コスト削減にも繋がっている エンジニアの確保が容易 一般的にアプリケーション作成の工数も少なく済む 9

10 アルゴリズムを書かないことによるデメリット アルゴリズムを書かないことによる最大のデメリット 性能 に関する問題が出やすい 適切ではないアルゴリズム ( 実行計画 ) による 著しい性能劣化 アルゴリズム ( 実行計画 ) 変動に伴う 性能変動 ( 劣化 ) SQL を使うユーザ ( 開発者 ) は 性能が悪くなり易い良くない実行計画となる SQL も書くことができる 多くのユーザは必要なデータが抽出できれば良く 実行計画など気にしない 一部ユーザが無意識に強烈な実行計画の SQL をリリースすることもある 10

11 参考 : 某チューニング案件の超巨大 SQL 実行計画 SQL テキストで 6700 行以上 40 表以上を結合した SELECT 文の実行計画 実行計画のステップ数換算で 実に 500 ステップ以上の超巨大 SQL ( 中略 ) 11

12 振り返ってもう一度このスライド どうやって (How) データを抽出するか 即ちアルゴリズムの決定 制御は RDBMS のオプティマイザで行われる オプティマイザが決定したアルゴリズム = 実行計画 オプティマイザは SQL テキストや統計情報などを基に 適切な実行計画を予測して組み立てる 条件 のみを記述 アルゴリズムを決定 / 制御 プログラム SQL Optimizer データ 12

13 本セクションのキーワードの一つ : 予測 どうやって (How) データを抽出するか 即ちアルゴリズムの決定 制御は RDBMS のオプティマイザで行われる オプティマイザが決定したアルゴリズム = 実行計画 オプティマイザは SQL テキストや統計情報などを基に 適切な実行計画を予測して組み立てる ココ! 条件 のみを記述 アルゴリズムを決定 / 制御 プログラム SQL Optimizer データ 13

14 SQL のアルゴリズムは 予測 で組み立てられる SQL のアルゴリズム 実行計画は オプティマイザが最適と考えられるものを 予測 して組み立てる そして 予測 である以上 必ずハズレのケースがある ハズレの実行計画の場合 性能問題として顕在化! SQL の特徴に由来する 全ての RDBMS に共通した本質的な困難 各ベンダやオープンソースの RDBMS は この SQL の本質的な困難に立ち向かうべく 日々凌ぎを削っている ( もちろん Oracle も!) まずこのハズレの実行計画の存在を意識 / 認識しておくのが SQL チューニングの出発点 14

15 全体最適 と 個別最適 の使い分け SQL チューニングの手法は 全体最適にマッチする手法と 個別最適に適した手法の 2 つに大別 全体最適にマッチする手法の例 適切な SQL(SQL コーディング ガイド コード インスペクション 等 ) 適切な統計 ( 常時最新化されたフレッシュな統計 最大件数想定の固定値 等 ) 適切な索引 ( 一意キー索引 追加索引 等 ) 実行計画最適化機能 (BindPeek, Dynamic Sampling, Cardinality Feedback 等 ) 個別最適にマッチする手法の例 ヒント SQL 計画管理 (SPM/11gR1 以降 ) アウトライン (10gR2 以前 ) SQL プロファイル 15

16 全体最適 と 個別最適 の適用イメージ (1) 長 個別最適 全体最適 処理時間短 低 SQL の重要度 高 16

17 全体最適 と 個別最適 の適用イメージ (2) 長 適切な統計 適切な SQL 実行計画最適化機能 (Bind Peek, Dynamic Sampling, Cardinality Feedback, 等 ) 適切な索引 ヒストグラム 拡張統計 ヒント 全体最適 個別最適 SPM(or アウトライン ) SQL プロファイル 処理時間短 低 SQL の重要度 高 17

18 全体最適 と 個別最適 の適用イメージ (3) 長 適切な統計 適切な SQL 実行計画最適化機能 (Bind Peek, Dynamic Sampling, Cardinality Feedback, 等 ) 適切な索引 ヒストグラム 拡張統計 ヒント 全体最適 個別最適 SPM(or アウトライン ) SQL プロファイル 終 処理時間短 序 まず初めは全体最適な手法で 実行計画全体の予測精度を上げる! 低 SQL の重要度 高 18

19 全体最適 と 個別最適 の適用イメージ (4) 長 個別最適 全体最適 処理時間短 予測精度向上でハズレの実行計画を引くリスクを低減し 個別最適の範囲を極小化する! と云う設計思想 低 SQL の重要度 高 19

20 全体最適 のち 個別最適 の考え方 まずは 全体最適 の設計思想で 実行計画全体の予測精度を向上させることが必要 個別最適 の必要性は無くなるわけではない 何故か? ハズレの実行計画の存在が理由 SQL の仕組み上 ハズレの実行計画は不可避であると云う認識が必要 ハズレの実行計画は有るものとして 個別最適 でチューニングする これ以降 個別最適 のチューニングで有効なテクニックを紹介 20

21 予測 と 実測 の乖離を補正せよ! Oracle Database の機能を活用した最新テクニック

22 SQL チューニングの流れ (1) KROWN# 遅い SQL の特定 (sql_id 特定 ) 実行計画のボトルネック特定 Tuning 案 1 Tuning 案 2 Tuning 案 3 Tuning 案 4 目標達成!! 22

23 SQLチューニングの流れ (2) 遅いSQLの特定 (sql_id 特定 ) 実行計画のボトルネック特定 Tuning 案 1 Tuning 案 2 Tuning 案 3 Tuning 案 4 KROWN# Oracle Database の機能を利用した ボトルネック特定方法を紹介 DBMS_XPLAN.DISPLAY_CURSOR で実行統計を出力する方法 ( 参考 KROWN#141531) DBMS_SQLTUNE.REPORT_SQL_MON ITOR によるリアルタイム監視 SQL のレポーティング 目標達成!! 23

24 SQL チューニングの流れ (3) 遅い SQL の特定 (sql_id 特定 ) 実行計画のボトルネック特定 複数のチューニング案を疑似ワークショップ形式で紹介 Tuning 案 1 Tuning 案 2 Tuning 案 3 Tuning 案 4 複数のチューニング案を覚えて 引き出しを増やす チューニングの引き出しを増やすことが 上級者への近道! 目標達成!! 24

25 DBMS_XPLAN と DBMS_SQLTUNE による実行計画のボトルネック特定

26 DBMS_XPLAN.DISPLAY_CURSOR の概要 KROWN# 実行計画を出力するための PL/SQL パッケージ ( 標準機能 ) ボトルネック特定を行いたい SQL の sql_id を調査 対象 SQL の完了を待つか Ctrl+C 等で強制終了 対象 SQL の完了後 下記 SQL を実行して対象 SQL の実行計画 / 実行統計を出力 format パラメータに ALLSTATS オプションを付与 SELECT * FROM TABLE( DBMS_XPLAN.DISPLAY_CURSOR( ' 対象 SQL の sql_id', NULL, 'ALL ALLSTATS LAST')); 26

27 DBMS_XPLAN.DISPLAY_CURSOR の制限事項 10gR1 以降の機能 ALLSTATS 書式を有効化する場合 下記の どちらか を満たして 実行統計が採取される状態で SQL を実行する 初期化パラメータ STATISTICS_LEVEL = ALL を設定 セッション単位 (ALTER SESSION~) でも設定可能 SQL に /*+ gather_plan_statistics */ ヒントを付与 対象 SQL が終了すると 実行統計が共有プールのカーソルに反映 SQL が完全に終了するか Ctrl+C 等で強制終了 強制終了させた場合は 強制終了時点までの実行統計が反映 SQL 終了前に実行計画を出力しても 実行統計は出ない 27

28 DBMS_XPLAN.DISPLAY_CURSOR の実行例 実行例 ( 一部の出力行 / 出力項目を省略 ) SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('80w7gaz4dywud', NULL, 'ALL ALLSTATS LAST')); PLAN_TABLE_OUTPUT SQL_ID 80w7gaz4dywud, child number SELECT /*+ gather_plan_statistics */ C.DATBI, C.HI_PR, C.LOW_PR, : Plan hash value: Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00: SORT ORDER BY :02: :00: VIEW :02: :00: SORT UNIQUE :02: :00: WINDOW SORT :02: :00:53.33 * 5 HASH JOIN K 00:02: :00: TABLE ACCESS BY INDEX ROWID DBN_FTBPR K 00:02: :00:52.49 * 7 INDEX SKIP SCAN DBN_FTBPR900PK 2 00:02: :00:51.98 * 8 TABLE ACCESS FULL DBN_FTBAT K 00:00: :00: : 28

29 DBMS_XPLAN.DISPLAY_CURSOR による解析 (1) 注目ポイント 1 SQL の実行統計 ( 実測 の処理件数 (A-Rows)/ 処理時間 (A-Time)) に注目 SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('80w7gaz4dywud', NULL, 'ALL ALLSTATS LAST')); : Plan hash value: Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00: SORT ORDER BY :02: :00: VIEW :02: :00: SORT UNIQUE :02: :00: WINDOW SORT :02: :00:53.33 * 5 HASH JOIN K 00:02: :00: TABLE ACCESS BY INDEX ROWID DBN_FTBPR K 00:02: :00:52.49 * 7 INDEX SKIP SCAN DBN_FTBPR900PK 2 00:02: :00:51.98 * 8 TABLE ACCESS FULL DBN_FTBAT K 00:00: :00: : 実行統計ここが遅そう 29

30 DBMS_XPLAN.DISPLAY_CURSOR による解析 (2) 注目ポイント 2 実行統計 (Actual) と CBO 予測 (Estimate) の乖離に注目 CBO 予測 SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('80w7gaz4dywud', NULL, 'ALL ALLSTATS LAST')); 実行統計 : Plan hash value: Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00: SORT ORDER BY :02: :00: VIEW :02: :00: SORT UNIQUE :02: :00: WINDOW SORT :02: :00:53.33 * 5 HASH JOIN K 00:02: :00: TABLE ACCESS BY INDEX ROWID DBN_FTBPR K 00:02: :00:52.49 * 7 INDEX SKIP SCAN DBN_FTBPR900PK 2 00:02: :00:51.98 * 8 TABLE ACCESS FULL DBN_FTBAT K 00:00: :00: : CBO は 2 件アクセスと予測しているが 実際は 件にアクセス 30

31 DBMS_XPLAN.DISPLAY_CURSOR による解析 (3) 前 2 ページの解析より 実行計画の Id 7 がボトルネックになっていると判断 処理時間の実行統計(A-time) が多い 処理件数のCBO 予測 (E-Rows) と実行統計 (A-Rows) が乖離している SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('80w7gaz4dywud', NULL, 'ALL ALLSTATS LAST')); : Plan hash value: Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00: SORT ORDER BY :02: :00: VIEW :02: :00: SORT UNIQUE :02: :00: WINDOW SORT :02: :00:53.33 * 5 HASH JOIN K 00:02: :00: TABLE ACCESS BY INDEX ROWID DBN_FTBPR K 00:02: :00:52.49 * 7 INDEX SKIP SCAN DBN_FTBPR900PK 2 00:02: :00:51.98 * 8 TABLE ACCESS FULL DBN_FTBAT K 00:00: :00: : 31

32 DBMS_SQLTUNE.REPORT_SQL_MONITOR の概要 SQLチューニングのための機能を提供するPL/SQLパッケージ ( オプション ) チューニング対象のSQLのsql_idを特定 対象 SQL のリアルタイムSQL 監視レポートを出力例 対象 SQL が実行中でも可能 SET LONG SET LONGC VAR c_rep CLOB; EXEC :c_rep := DBMS_SQLTUNE.REPORT_SQL_MONITOR(sql_id => ' 対象 SQLのsql_id'); PRINT c_rep; 32

33 DBMS_SQLTUNE.REPORT_SQL_MONITOR の制限事項 11gR1 以降の機能 DBMS_SQLTUNE パッケージを使用するためには Enterprise Edition の Tuning Pack オプションライセンスが必要 リアルタイム SQL 監視の対象となる ( V$SQL_MONITOR ビューに載る ) ため下記の どれか が満たされる必要 SQL の処理時間が 5 秒以上 SQL に MONITOR ヒントを付与 パラレル クエリー 33

34 DBMS_SQLTUNE.REPORT_SQL_MONITOR の実行例 実行例 ( 一部の出力行 / 出力項目を省略 ) SQL> EXEC :C_REP := DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID => '9ksyk16au4zzf'); SQL> PRINT C_REP; SQL Text SELECT B762.R_DIST_CODE B762.R_CUSTOMER_CODE Global Stats =================================================================== Elapsed Cpu IO Other Buffer Read Read Time(s) Time(s) Waits(s) Waits(s) Gets Reqs Bytes =================================================================== MB =================================================================== SQL Plan Monitoring Details (Plan Hash Value= ) ====================================================================================================================== Id Operation Name Rows Execs Rows Activity Activity Detail (Estim) (Actual) (%) (# samples) ====================================================================================================================== 0 SELECT STATEMENT 1 1 SORT UNIQUE UNION-ALL : : : : : : : : 7 VIEW VM_NWVW_ > 8 HASH GROUP BY Cpu (1168) -> 9 HASH JOIN 2M 1 980M 7.57 Cpu (96) 10 INDEX RANGE SCAN KUAB : : : : : : : : 20 TABLE ACCESS FULL CUAB ====================================================================================================================== 34

35 DBMS_SQLTUNE.REPORT_SQL_MONITOR の解析 (1) 注目ポイント 1 実行統計 (SQL の 実際 の処理時間 / 処理件数 ) に注目 SQL> EXEC :C_REP := DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID => '9ksyk16au4zzf'); SQL> PRINT C_REP; SQL Text SELECT B762.R_DIST_CODE B762.R_CUSTOMER_CODE Global Stats =================================================================== Elapsed Cpu IO Other Buffer Read Read Time(s) Time(s) Waits(s) Waits(s) Gets Reqs Bytes =================================================================== MB =================================================================== SQL Plan Monitoring Details (Plan Hash Value= ) ====================================================================================================================== Id Operation Name Rows Execs Rows Activity Activity Detail (Estim) (Actual) (%) (# samples) ====================================================================================================================== 0 SELECT STATEMENT 1 1 SORT UNIQUE UNION-ALL : : : : : : : : 7 VIEW VM_NWVW_ > 8 HASH GROUP BY Cpu (1168) -> 9 HASH JOIN 2M 1 980M 7.57 Cpu (96) 10 INDEX RANGE SCAN KUAB : : : : : : : : 20 TABLE ACCESS FULL CUAB ====================================================================================================================== 35

36 DBMS_SQLTUNE.REPORT_SQL_MONITOR の解析 (2) 注目ポイント 2 実行統計 (Actual) と CBO 予測 (Estimate) の乖離に注目 SQL> EXEC :C_REP := DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID => '9ksyk16au4zzf'); SQL> PRINT C_REP; SQL Text SELECT B762.R_DIST_CODE B762.R_CUSTOMER_CODE Global Stats =================================================================== Elapsed Cpu IO Other Buffer Read Read Time(s) Time(s) Waits(s) Waits(s) Gets Reqs Bytes =================================================================== CBO 1 予測 1MB =================================================================== 実行統計 ( トータル ) 実行統計 ( 待機イベント付き ) SQL Plan Monitoring Details (Plan Hash Value= ) ====================================================================================================================== Id Operation Name Rows Execs Rows Activity Activity Detail (Estim) (Actual) (%) (# samples) ====================================================================================================================== 0 SELECT STATEMENT 1 1 SORT UNIQUE UNION-ALL : : : : : : : : 7 VIEW VM_NWVW_ > 8 HASH GROUP BY Cpu (1168) -> 9 HASH JOIN 2M 1 980M 7.57 Cpu (96) 10 INDEX RANGE SCAN KUAB : : : : : : : : 20 TABLE ACCESS FULL CUAB ====================================================================================================================== CBO は 2M 件アクセスと予測しているが 実際は 980M 件にアクセス 36

37 DBMS_SQLTUNE.REPORT_SQL_MONITOR の解析 (3) 前 2 ページの解析より 実行計画の Id 8,9 がボトルネックと判断 SQL> EXEC :C_REP := DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID => '9ksyk16au4zzf'); SQL> PRINT C_REP; SQL Text SELECT B762.R_DIST_CODE B762.R_CUSTOMER_CODE Global Stats =================================================================== Elapsed Cpu IO Other Buffer Read Read Time(s) Time(s) Waits(s) Waits(s) Gets Reqs Bytes =================================================================== MB =================================================================== SQL Plan Monitoring Details (Plan Hash Value= ) ====================================================================================================================== Id Operation Name Rows Execs Rows Activity Activity Detail (Estim) (Actual) (%) (# samples) ====================================================================================================================== 0 SELECT 処理時間の実行統計 STATEMENT (Activity Detail) が多い 1 1 SORT UNIQUE UNION-ALL : : : : : : : : 7 VIEW VM_NWVW_ > 8 HASH GROUP BY Cpu (1168) -> 9 HASH JOIN 2M 1 980M 7.57 Cpu (96) 10 INDEX RANGE SCAN KUAB : : : : : : : : 20 TABLE ACCESS FULL CUAB ====================================================================================================================== 処理件数の CBO 予測 (Rows Estim) と実行統計 (Rows Actual) が乖離している 37

38 リアルタイム SQL 監視による確認 テキスト形式と同等の情報を GUI のオペレーションで参照可能 38

39 DBMS_XPLAN/DBMS_SQLTUNE の比較 DBMS_XPLAN.DISPLAY_CURSOR (ALLSTATS 書式 ) バージョン 10gR1 以降 11gR1 以降 DBMS_SQLTUNE. REPORT_SQL_MONITOR 有償オプション不要要 Tuning Pack 事前準備 採取可能な情報 SQL 終了要否 どちらかを事前に仕込む必要アリ STATISTICS_LEVEL=ALL gather_plan_statistics ヒント付与 実行統計 ( 行数 / 処理時間 ) 対象 SQL が終了しているか Ctrl+C 等で強制終了させる必要がある SQL が 5 秒以上 又はパラレル クエリなら不要 非パラレルかつ 5 秒未満の場合は MONITOR ヒント付与 実行統計 ( 行数 / 処理時間 / トータル統計 / 待機イベント ) 対象 SQL が実行中でも情報採取可能 有償オプションが必要な DBMS_SQLTUNE の方が総じて優秀 但し DBMS_XPLAN でしか採取できない情報もある 39

40 疑似ワークショップによる SQL チューニング案の紹介

41 疑似ワークショップの目的 ワークショップの目的は SQL チューニングのネタ / 引き出し ( 選択肢 ) を増やすこと 上級者への入り口 チューニングのネタ / 引き出しが増えれば 目標到達への可能性が広がる 複数あるチューニング案の一部を紹介 SQL チューニングを疑似体験して 引き出しを増やしましょう! 41

42 チューニング前 疑似ワークショップの課題 SQL チューニング対象の SQL TEST_TABLE_A 表と TBL_B 表を結合する SQL -- g9gnrhjwajfnn SELECT /*+ MONITOR */ A.* FROM TEST_TABLE_A A, TBL_B B WHERE A.P_NO2 = B.P_NO AND A.P_CHAR = B.P_CHAR AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; 42

43 チューニング前 SQL 実行時間と AUTOTRACE 統計 チューニング前の SQL 実行時間 /AUTOTRACE 統計 下記の実行時間 (Elapsed) と負荷 (gets/reads) を減らすのが SQL チューニングのセオリー 10:39:35 SQL> SELECT /*+ MONITOR */ 10:39:35 2 A.* 10:39:35 3 FROM TEST_TABLE_A A 10:39:35 4, TBL_B B 10:39:35 5 WHERE A.P_NO2 = B.P_NO 10:39:35 6 AND A.P_CHAR = B.P_CHAR 10:39:35 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; 1102 rows selected. Elapsed: 00:00:12.44 : Statistics consistent gets 5985 physical reads 43

44 チューニング前 DBMS_XPLAN.DISPLAY_CURSOR 結果 SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('g9gnrhjwajfnn', NULL, 'ADVANCED ALLSTATS LAST')); PLAN_TABLE_OUTPUT SQL_ID g9gnrhjwajfnn, child number SELECT /*+ MONITOR */ A.* FROM TEST_TABLE_A A, TBL_B B WHERE A.P_NO2 = B.P_NO AND A.P_CHAR = B.P_CHAR AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' ' Plan hash value: Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00:10.41 * 1 HASH JOIN :00: :00: TABLE ACCESS FULL TEST_TABLE_A :00: K 00:00:01.49 * 3 TABLE ACCESS FULL TBL_B :00: :00:

45 チューニング前 DBMS_SQLTUNE.REPORT_SQL_MONITOR 結果 SQL Text SELECT /*+ MONITOR */ A.* FROM TEST_TABLE_A A, TBL_B B WHERE A.P_NO2 = B.P_NO AND A.P_CHAR = B.P_CHAR AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' : Global Stats ================================================================================ Elapsed Cpu IO Fetch Buffer Read Read Write Write Time(s) Time(s) Waits(s) Calls Gets Reqs Bytes Reqs Bytes ================================================================================ MB MB ================================================================================ SQL Plan Monitoring Details (Plan Hash Value= ) =========================================================================================================== Id Operation Name Rows Rows Activity Activity Detail (Estim) (Actual) (%) (# samples) =========================================================================================================== 0 SELECT STATEMENT HASH JOIN Cpu (9) direct path write temp (1) 2 TABLE ACCESS FULL TEST_TABLE_A 26 3M 9.09 Cpu (1) 3 TABLE ACCESS FULL TBL_B =========================================================================================================== 45

46 チューニング案の一覧 今回の SQL では下記に挙げるチューニングで性能が改善 案 1 DBMS_STATS による統計情報採取 案 2 拡張統計の採取 案 3 SQL プロファイル適用 (by DBMS_SQLTUNE) 案 4 Cardinality Feedback の使用 案 5 ヒントや SPM による実行計画操作 案 6 パラレル クエリ化 案 7 SQL 修正 (WHERE 句書き換え ) 案 8 SQL 修正 (WITH 句によるサブクエリ切り出し ) 案 9 Dynamic Sampling 適用 案 10 新規索引付与 案 11 リザルト セットの適用 今回紹介するチューニング案 46

47 案 1. DBMS_STATS による統計情報採取

48 案 1. DBMS_STATS による統計情報採取 (1) まず確認するのは 統計情報が実態と合っているか? SQL> SELECT TABLE_NAME, NUM_ROWS FROM USER_TABLES WHERE TABLE_NAME IN ('TEST_TABLE_A', 'TBL_B'); TABLE_NAME NUM_ROWS TEST_TABLE_A 26 TBL_B SQL> SELECT COUNT(*) FROM TEST_TABLE_A; COUNT(*) 統計は 26 件 実態は約 2,600,000 件 SQL> SELECT COUNT(*) FROM TBL_B; COUNT(*)

49 案 1. DBMS_STATS による統計情報採取 (2) DBMS_STATS パッケージで統計情報を採取 採取した統計を即座に使用 (NO_INVALIDATE => FALSE) 4 パラレルで採取 (DEGREE => 4) EXEC DBMS_STATS.GATHER_TABLE_STATS( USER, 'TEST_TABLE_A, NO_INVALIDATE => FALSE, DEGREE => 4); 49

50 案 1. DBMS_STATS による統計情報採取 (3) 統計情報採取後の実行統計 10:39:35 SQL> SELECT /*+ MONITOR */ 10:39:35 2 A.* 10:39:35 3 FROM TEST_TABLE_A A 10:39:35 4, TBL_B B 10:39:35 5 WHERE A.P_NO2 = B.P_NO 10:39:35 6 AND A.P_CHAR = B.P_CHAR 10:39:35 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; 1102 rows selected. Elapsed: 00:00:12.44 : Statistics consistent gets 5985 physical reads 10:48:08 SQL> SELECT /*+ MONITOR */ 10:48:08 2 A.* 10:48:08 3 FROM TEST_TABLE_A A 10:48:08 4, TBL_B B 10:48:08 5 WHERE A.P_NO2 = B.P_NO 10:48:08 6 AND A.P_CHAR = B.P_CHAR 10:48:08 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; 1102 rows selected. Elapsed: 00:00:04.71 : 性能改善! Statistics consistent gets 59 physical reads 50

51 案 1. DBMS_STATSによる統計情報採取 (4) DBMS_XPLAN.DISPLAY_CURSOR 結果の比較 Before Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00:12.32 * 1 HASH JOIN :00: :00: TABLE ACCESS FULL TEST_TABLE_A :00: K 00:00:01.46 * 3 TABLE ACCESS FULL TBL_B :00: :00: After Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00:04.65 * 1 HASH JOIN K 00:00: :00:04.65 * 2 TABLE ACCESS FULL TBL_B :00: :00: TABLE ACCESS FULL TEST_TABLE_A 2600K 49M 00:00: K 00:00:

52 案 1. DBMS_STATSによる統計情報採取 (5) DBMS_SQLTUNE.REPORT_SQL_MONITOR 結果の比較 Before ============================================================================================== Id Operation Name Rows Rows Activity Detail (Estim) (Actual) (# samples) ============================================================================================== 0 SELECT STATEMENT HASH JOIN Cpu (8) direct path write temp (4) 2 TABLE ACCESS FULL TEST_TABLE_A 26 3M 3 TABLE ACCESS FULL TBL_B ============================================================================================== After =================================================================================== Id Operation Name Rows Rows Activity Detail (Estim) (Actual) (# samples) =================================================================================== 0 SELECT STATEMENT HASH JOIN Cpu (5) 2 TABLE ACCESS FULL TBL_B TABLE ACCESS FULL TEST_TABLE_A 3M 3M =================================================================================== 52

53 案 1. DBMS_STATS による統計情報採取 (6) CBO は統計情報を元に 最適な実行計画を予測して組み立てる テーブルの統計情報と実態 ( 実件数 ) が合致しているかどうかを 真っ先に確認 0 件統計 ( 典型的なアンチパターン!) 0 件では無いが 実態と乖離した統計 統計情報最新化で HASH JOIN の結合順序が入れ替わり 一時表領域への I/O が無くなって性能が改善 53

54 案 2. 拡張統計の採取

55 案 2. 拡張統計の採取 (1) 表の列 ( カラム ) に関数を適用しているのは SQL のアンチパターンの一つ SELECT /*+ MONITOR */ A.* FROM TEST_TABLE_A A P_DATE 列にTO_CHAR 関数を適用, TBL_B B WHERE A.P_NO2 = B.P_NO AND A.P_CHAR = B.P_CHAR AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; このパターンが性能劣化し易い理由は以下の 2 つに集約される 1. 列に作成された索引が使用されない 2. CBO が列統計を使用できず 実行計画の予測精度が落ちる 今回は 2 に着目 55

56 案 2. 拡張統計の採取 (2) DBMS_STATS パッケージで拡張統計情報を採取 METHOD_OPT に拡張統計 ( 今回の SQL では式統計 ) の明示的採取を設定 ESTIMATE_PERCENT に 100 を設定して 全サンプリング DBMS_STATS.GATHER_TABLE_STATS( USER,'TBL_B', NO_INVALIDATE => FALSE, METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO ' 'FOR COLUMNS (TO_CHAR(P_DATE, ''YYYYMMDD'')) SIZE 254', DEGREE => 4, ESTIMATE_PERCENT => 100); 56

57 案 2. 拡張統計の採取 (3) 拡張統計 ( 式統計 ) 採取後の実行統計 10:48:08 SQL> SELECT /*+ MONITOR */ 10:48:08 2 A.* 10:48:08 3 FROM TEST_TABLE_A A 10:48:08 4, TBL_B B 10:48:08 5 WHERE A.P_NO2 = B.P_NO 10:48:08 6 AND A.P_CHAR = B.P_CHAR 10:48:08 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; 1102 rows selected. Elapsed: 00:00:04.71 : Statistics consistent gets 59 physical reads 13:47:45 SQL> SELECT /*+ MONITOR */ 13:47:45 2 A.* 13:47:45 3 FROM TEST_TABLE_A A 13:47:45 4, TBL_B B 13:47:45 5 WHERE A.P_NO2 = B.P_NO 13:47:45 6 AND A.P_CHAR = B.P_CHAR 13:47:45 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; 1102 rows selected. Elapsed: 00:00:00.16 : 性能改善! Statistics consistent gets 0 physical reads 57

58 案 2. 拡張統計の採取 (4) DBMS_XPLAN.DISPLAY_CURSOR 結果の比較 Before Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00:04.65 * 1 HASH JOIN K 00:00: :00:04.65 * 2 TABLE ACCESS FULL TBL_B :00: :00: TABLE ACCESS FULL TEST_TABLE_A 2600K 49M 00:00: K 00:00: After Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00: NESTED LOOPS :00: NESTED LOOPS :00: :00:00.09 * 3 TABLE ACCESS FULL TBL_B :00: :00:00.09 * 4 INDEX RANGE SCAN TEST_TABLE_A_I :00: :00: TABLE ACCESS BY INDEX ROWID TEST_TABLE_A :00: :00:

59 案 2. 拡張統計の採取 (5) DBMS_SQLTUNE.REPORT_SQL_MONITOR 結果の比較 Before =================================================================================== Id Operation Name Rows Rows Activity Detail (Estim) (Actual) (# samples) =================================================================================== 0 SELECT STATEMENT HASH JOIN Cpu (5) 2 TABLE ACCESS FULL TBL_B TABLE ACCESS FULL TEST_TABLE_A 3M 3M =================================================================================== After ================================================================================================ Id Operation Name Rows Rows Activity Detail (Estim) (Actual) (# samples) ================================================================================================ 0 SELECT STATEMENT NESTED LOOPS NESTED LOOPS TABLE ACCESS FULL TBL_B INDEX RANGE SCAN TEST_TABLE_A_I TABLE ACCESS BY INDEX ROWID TEST_TABLE_A ================================================================================================ 59

60 案 2. 拡張統計の採取 (6) 今回のケースでは 式統計 を採取することで CBO 予測の誤りを補正 CBO 予測の誤りが補正されたことで より良い実行計画が選択された SELECT /*+ MONITOR */ A.* FROM TEST_TABLE_A A, TBL_B B WHERE A.P_NO2 = B.P_NO AND A.P_CHAR = B.P_CHAR AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; ここの式統計を採取 拡張統計 式統計 複数列統計 サブクエリ内で DISTINCT/GROUP BY を使用するケースで グルーピングしている列値同士に相関関係が有る場合に有効 60

61 案 3. SQL プロファイル適用 (by DBMS_SQLTUNE)

62 案 3. SQL プロファイル適用 (by DBMS_SQLTUNE)(1) SQL プロファイルは DBMS_SQLTUNE のチューニング タスク実行によって作成 / 提案される リアルタイム SQL 監視 (REPORT_SQL_MONITOR) に並ぶ DBMS_SQLTUNE パッケージの有効な機能 Enterprise Edition の Tuning Pack オプションライセンスが必要 個別 SQL の CBO 予測 ( 実行計画作成 ) を精緻化する 使いこなせれば 強力な SQL チューニング手段の一つ 62

63 案 3. SQL プロファイル適用 (by DBMS_SQLTUNE)(2) SQL プロファイルの作成 / 適用サンプル SQL> VARIABLE STMT_TASK VARCHAR2(64); SQL> EXEC :STMT_TASK := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id => 'g9gnrhjwajfnn', time_limit => 10800); Elapsed: 00:00:00.46 SQL> EXEC DBMS_SQLTUNE.EXECUTE_TUNING_TASK(:STMT_TASK); Elapsed: 00:12:12.02 SQL> SET LONGCHUNKSIZE LONG LINESIZE 300 PAGESIZE 1000; SQL> COLUMN REPORT FORMAT A300 SQL> SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK(:STMT_TASK) AS REPORT FROM DUAL; : 1- SQL Profile Finding (see explain plans section below) A potentially better execution plan was found for this statement. Recommendation (estimated benefit: 87.03%) Consider accepting the recommended SQL profile. execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_20343', task_owner => 'AYSHIBAT', replace => TRUE); : SQL> execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_20343', task_owner => 'AYSHIBAT', replace => TRUE); Elapsed: 00:00:00.44 SQL> 4SQL プロファイルの承認 ( 3 で SQL プロファイルが提案された場合 ) 1 チューニング タスク作成 2 チューニング タスク実行 3 チューニング タスクのレポーティング 63

64 案 3. SQL プロファイル適用 (by DBMS_SQLTUNE)(3) SQL プロファイルのサンプル ( チューニング タスク レポート ) 19:00:16 SQL> SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK(:STMT_TASK) 19:00:16 2> AS REPORT FROM DUAL; : 1- SQL Profile Finding (see explain plans section below) A potentially better execution plan was found for this statement. : Recommendation (estimated benefit: 87.03%) Consider accepting the recommended SQL profile. execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_20343', task_owner => 'AYSHIBAT', replace => TRUE); : Validation results The SQL profile was tested by executing both its plan and the original plan and measuring their respective execution statistics. A plan may have been only partially executed if the other could be run to completion in less time. : Original Plan With SQL Profile % Improved Completion Status: COMPLETE COMPLETE Elapsed Time (s): % CPU Time (s): % User I/O Time (s): 0 0 Buffer Gets: % Physical Read Requests: 0 0 Physical Write Requests: 0 0 Physical Read Bytes: 0 0 Physical Write Bytes: 0 0 Rows Processed: Fetches: Executions: 1 1 Notes Statistics for the original plan were averaged over 1 executions. 2. Statistics for the SQL profile plan were averaged over 10 executions. : SQL プロファイルが提案されている SQL プロファイル適用前の統計 SQL プロファイル適用後の統計 64

65 案 3. SQL プロファイル適用 (by DBMS_SQLTUNE)(4) SQL プロファイル適用後の実行統計 10:48:08 SQL> SELECT /*+ MONITOR */ 10:48:08 2 A.* 10:48:08 3 FROM TEST_TABLE_A A 10:48:08 4, TBL_B B 10:48:08 5 WHERE A.P_NO2 = B.P_NO 10:48:08 6 AND A.P_CHAR = B.P_CHAR 10:48:08 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; 1102 rows selected. Elapsed: 00:00:04.71 : Statistics consistent gets 59 physical reads 19:00:18 SQL> SELECT /*+ MONITOR */ 19:00:18 2 A.* 19:00:18 3 FROM TEST_TABLE_A A 19:00:18 4, TBL_B B 19:00:18 5 WHERE A.P_NO2 = B.P_NO 19:00:18 6 AND A.P_CHAR = B.P_CHAR 19:00:18 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; 1102 rows selected. Elapsed: 00:00:00.17 性能改善! Note SQL profile "SYS_SQLPROF_013aeee99cec0000" used for this Statistics consistent gets 1 physical reads SQL プロファイルが使用されている 65

66 案 3. SQLプロファイル適用 (by DBMS_SQLTUNE)(5) DBMS_XPLAN.DISPLAY_CURSOR 結果の比較 Before Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00:04.65 * 1 HASH JOIN K 00:00: :00:04.65 * 2 TABLE ACCESS FULL TBL_B :00: :00: TABLE ACCESS FULL TEST_TABLE_A 2600K 49M 00:00: K 00:00: After Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00: NESTED LOOPS :00: NESTED LOOPS :00: :00:00.09 * 3 TABLE ACCESS FULL TBL_B :00: :00:00.08 * 4 INDEX RANGE SCAN TEST_TABLE_A_I :00: :00: TABLE ACCESS BY INDEX ROWID TEST_TABLE_A :00: :00:

67 案 3. SQLプロファイル適用 (by DBMS_SQLTUNE)(6) DBMS_SQLTUNE.REPORT_SQL_MONITOR 結果の比較 Before =================================================================================== Id Operation Name Rows Rows Activity Detail (Estim) (Actual) (# samples) =================================================================================== 0 SELECT STATEMENT HASH JOIN Cpu (5) 2 TABLE ACCESS FULL TBL_B TABLE ACCESS FULL TEST_TABLE_A 3M 3M =================================================================================== After =========================================================================================================== Id Operation Name Rows Rows Activity Activity Detail (Estim) (Actual) (%) (# samples) =========================================================================================================== 0 SELECT STATEMENT NESTED LOOPS NESTED LOOPS TABLE ACCESS FULL TBL_B INDEX RANGE SCAN TEST_TABLE_A_I TABLE ACCESS BY INDEX ROWID TEST_TABLE_A =========================================================================================================== 67

68 案 3. SQL プロファイル適用 (by DBMS_SQLTUNE)(7) SQL プロファイルの仕組みについて マニュアル ( ) を参照 17.5 SQL プロファイルの管理 SQL プロファイルには 個別の実行計画に関する情報は含まれません オプティマイザには 計画を選択する際に 次の情報ソースがあります データベース構成 バインド変数値 オプティマイザ統計 データ セットなどを含む環境 SQL プロファイルの補足的な統計情報 SQL プロファイルの正体は 個別の SQL に特化した補助的なオプティマイザ統計 個別 SQL に対する詳細なダイナミック サンプリングのようなもの サンプリング結果を実体として保持 そのサンプリング結果が適用されると CBO 予測が精緻化されて実行計画が改善 SPM やアウトラインのように 実行計画そのものを保持している訳ではない マニュアル Oracle Database パフォーマンス チューニング ガイド 11g リリース 2(11.2)B

69 案 3. SQL プロファイル適用 (by DBMS_SQLTUNE)(8) KROWN# SQL プロファイル有効時の トレース抜粋例 SQL 内のカーディナリティやセレクティビティに関する補足情報 KROWN# event トレースの取得方法 event は Cost Base Optimizer(CBO) の動作をトレースするイベント : atom_hint=(~txt=opt_estimate (INDEX_FILTER "B111" "xxxx11101" ROWS= ) ) atom_hint=(~txt=opt_estimate (INDEX_SCAN "B111" "xxxx11101" MIN= ) ) atom_hint=(~txt=opt_estimate (TABLE "x111" ROWS= ) ) atom_hint=(~txt=opt_estimate (GROUP_BY ROWS= ) ) atom_hint=(~txt=opt_estimate (INDEX_FILTER "A002" "yyyy00201" MIN= ) ) atom_hint=(~txt=opt_estimate (INDEX_SCAN "A002" "yyyy00201" MIN= ) ) atom_hint=(~txt=opt_estimate (TABLE "y002" MIN= ) ) : 69

70 案 3. SQL プロファイル適用 (by DBMS_SQLTUNE)(9) SQL プロファイルを作成 / 適用する環境は 本番環境 又はそれに準じた量 / 質のデータが保持されている 必要がある この点を理解していれば 複雑な SQL を機械的にチューニングできる 強力な武器となる 機械的なチューニングによる 時間短縮 / 必要スキル低減 / コスト削減 本番環境 開発環境間の相互移行も可能 性能改善が 100% 保証される訳ではないので 適用後の検証 / 評価は必要 本番環境 開発環境間の移行方法 Notes# How to Move SQL Profiles from One Database to Another 70

71 案 3. SQL プロファイル適用 (by DBMS_SQLTUNE)(10) SQL プロファイル生成時のチューニング タスクでは 最終ハード パースのバインド変数で 対象 SQL を実際に実行して統計を採取 Completion Status の値が双方 COMPLETE であれば SQL プロファイル適用による性能改善の確度は高い Original Plan With SQL Profile % Improved Completion Status: COMPLETE COMPLETE Elapsed Time (s): % CPU Time (s): % User I/O Time (s): 0 0 Buffer Gets: % Physical Read Requests: 0 0 Physical Write Requests: 0 0 Physical Read Bytes: 0 0 Physical Write Bytes: 0 0 Rows Processed: Fetches: Executions: 1 1 : SQL プロファイル適用前後の検証が完了している 71

72 案 3. SQL プロファイル適用 (by DBMS_SQLTUNE)(11) Enterprise Manager からも作成 / 適用可能 72

73 案 4. Cardinality Feedback の使用

74 案 4. Cardinality Feedback の使用 (1) KROWN# Cardinality Feedback は CBO の実行計画予測精度を上げる機能の一つ 11gR2 で導入された新機能 CBO 予測と実行統計が乖離している際に 2 回目以降の SQL 実行時に実行結果を Feedback して 実行計画を作成し直す機能 Feedback 結果により CBO 予測が精緻化される KROWN# [11.2 新機能 ] オプティマイザ フィードバック ( カーディナリティ フィードバック ) 74

75 案 4. Cardinality Feedback の使用 (2) KROWN# Cardinality Feedback はデフォルトで有効 隠しパラメータ _optimizer_use_feedback で制御可能 KROWN# [11.2 新機能 ] オプティマイザ フィードバック ( カーディナリティ フィードバック ) -- Cardinality Feedback を無効化 ALTER SYSTEM SET "_optimizer_use_feedback" = FALSE SCOPE = BOTH; -- Cardinality Feedback を有効化 ALTER SYSTEM SET "_optimizer_use_feedback" = TRUE SCOPE = BOTH; 75

76 案 4. Cardinality Feedback の使用 (3) Cardinality Feedback 有効時の実行統計 (2 回目 ) 10:48:08 SQL> SELECT /*+ MONITOR */ 10:48:08 2 A.* 10:48:08 3 FROM TEST_TABLE_A A 10:48:08 4, TBL_B B 10:48:08 5 WHERE A.P_NO2 = B.P_NO 10:48:08 6 AND A.P_CHAR = B.P_CHAR 10:48:08 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; 1102 rows selected. Elapsed: 00:00:04.71 : Statistics consistent gets 59 physical reads 21:12:15 SQL> SELECT /*+ MONITOR */ 21:12:15 2 A.* 21:12:15 3 FROM TEST_TABLE_A A 21:12:15 4, TBL_B B 21:12:15 5 WHERE A.P_NO2 = B.P_NO 21:12:15 6 AND A.P_CHAR = B.P_CHAR 21:12:15 7 AND TO_CHAR(B.P_DATE, 'YYYYMMDD') = ' '; 1102 rows selected. Elapsed: 00:00:00.14 性能改善! Statistics consistent gets 1 physical reads 76

77 案 4. Cardinality Feedbackの使用 (4) DBMS_XPLAN.DISPLAY_CURSOR 結果の比較 Before Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00:04.65 * 1 HASH JOIN K 00:00: :00:04.65 * 2 TABLE ACCESS FULL TBL_B :00: :00: TABLE ACCESS FULL TEST_TABLE_A 2600K 49M 00:00: K 00:00: After(2 回目の実行計画 ) Id Operation Name E-Rows E-Bytes E-Time A-Rows A-Time SELECT STATEMENT :00: NESTED LOOPS :00: NESTED LOOPS :00: :00:00.09 * 3 TABLE ACCESS FULL TBL_B :00: :00:00.08 * 4 INDEX RANGE SCAN TEST_TABLE_A_I :00: :00: TABLE ACCESS BY INDEX ROWID TEST_TABLE_A :00: :00:

78 案 4. Cardinality Feedbackの使用 (5) DBMS_SQLTUNE.REPORT_SQL_MONITOR 結果の比較 Before =================================================================================== Id Operation Name Rows Rows Activity Detail (Estim) (Actual) (# samples) =================================================================================== 0 SELECT STATEMENT HASH JOIN Cpu (5) 2 TABLE ACCESS FULL TBL_B TABLE ACCESS FULL TEST_TABLE_A 3M 3M =================================================================================== After(2 回目の実行計画 ) ================================================================================================ Id Operation Name Rows Rows Activity Detail (Estim) (Actual) (# samples) ================================================================================================ 0 SELECT STATEMENT NESTED LOOPS NESTED LOOPS TABLE ACCESS FULL TBL_B INDEX RANGE SCAN TEST_TABLE_A_I TABLE ACCESS BY INDEX ROWID TEST_TABLE_A ================================================================================================ 78

79 案 4. Cardinality Feedback の使用 (6) 今回のケースでは Cardinality Feedback により 2 回目の SQL で CBO 予測の誤りが補正 CBO 予測の誤りが補正されたことで より良い実行計画が選択 CBO による実行計画の予測精度を上げる働きを持つ機能 BindPeek, Cardinality Feedback, Dynamic Sampling これらの機能を 実行計画の安定化 を目的に 無効化されているシステムも多い これらの機能を無効化することは CBO の機能 / 性能をスポイルしている と云う事実認識も必要 ハズレの実行計画を引く確率が高まると云うリスクの増加 10gR2 までの BindPeek の欠点 ( 初回 PARSE 時のプランで固定される ) は 11gR1 導入の 優れたカーソル共有 で改善 現在は BindPeek 使用も有力な選択肢で false 一択ではない KROWN# [11g 新機能 ] 優れたカーソル共有 79

80 SQL チューニングのまとめ

81 SQL とオプティマイザが抱える弱点 SQL と RDBMS のオプティマイザは その言語の仕組みに由来する本質的な弱点を抱えている SQL はアルゴリズムを記述しないと云う特徴があるため それ ( アルゴリズム ) が RDBMS( オプティマイザ ) 任せになる SQL のアルゴリズム 実行計画は コストと云う基準の 予測 で導出されている 予測 である以上 ハズレのケースが出てくる 81

82 SQL チューニングを上手くやるには SQL やオプティマイザの弱点 / アンチパターンを知っておく 実行計画は 予測 であり ハズレが有り得ることの認識 予測がハズレる ハズレ易いケースとは? 弱点 / アンチパターンの対抗手段を見つけておく 予測精度を向上させる設計技法や機能の活用 予測(Estimate) と 実測(Actual) を補正するというアプローチ アンチパターンをダイレクトに潰す手法も有効 Oracle Database の機能を利用して 予測 と 実測 の乖離を捉える DBMS_XPLAN.DISPLAY_CURSOR( ALLSTATS 書式 ) DBMS_SQLTUNE.REPORT_SQL_MONITOR( リアルタイムSQL 監視 ) 82

83 紹介したチューニング案の方向性について 今回紹介したのは 全て 予測 (Estimate) と 実測 (Actual) の乖離を補正する方向性でのチューニング 既に述べた通り 下記のようなチューニングも可能 案 5 ヒントや SPM による実行計画操作 案 6 パラレル クエリ化 案 7 SQL 修正 (WHERE 句書き換え ) 案 8 SQL 修正 (WITH 句によるサブクエリ切り出し ) 案 9 Dynamic Sampling 適用 案 10 新規索引付与 案 11 リザルト セットの適用 チューニングの正解は 1 つではないので併せて利用を検討 83

84 共有プールの基本的理解

85 Memory Management バージョン毎の主要な追加機能 Oracle9i Database ~ 動的なメモリサイズ変更のサポート (SGA_MAX_SIZE) 自動 PGA メモリ管理機能の追加 (PGA_AGGREGATE_TARGET) Shared Pool の CPU 数によるヒープ分割機能の追加 Oracle Database 10g~ [R1] 自動共有メモリ管理機能の追加 (Automatic Shared-Memory Management) [R2] Shared Pool の存続期間 (Duration) 毎の分割管理機能の追加 Oracle Database 11g~ [R1] 自動メモリ管理機能の追加 (Automatic Memory Management) [R2] ASMM/AMM 未使用時の各プールサイズの自動調整機能の追加 [R2] Database Smart Flash Cache 機能の追加 85

86 Automatic Shared-Memory Management (ASMM) Oracle Database 10g Release 1~ SGA_TARGET 初期化パラメータを使用して SGA の合計量を指定すると MMAN によって各コンポーネントのサイズが自動調整される機能 バッファ キャッシュを中心に調整され グラニュル単位で移行 Shared Pool Large Pool Buffer Cache SGA Java Pool Stream Pool Shared IO Pool 86

87 ASMM sga_max_size sga_target の上限設定デフォルト値は sga_target と同値 shared_pool_size Shared Pool sga_target 全 SGA コンポーネントの合計サイズ 明示的に 0 に設定しない限り ASMM が有効化する db_cache_size Buffer Cache 自動共有メモリ管理時の各メモリ コンポーネントのサイズを指定するパラメータ ( 例えば db_cache_size / shared_pool_size) は 自動調整の際の下限値となる 87

88 手動メモリ管理での自動調整機能 Oracle Database 11g Release 1~ KROWN# 手動メモリ管理の場合でも ORA-4031 の発生を抑止する目的で Shared Pool の自動拡張 (Buffer Cache から奪う動作 ) が実行される 注意点 手動メモリ管理の場合 DB_CACHE_SIZE パラメータの値が Buffer Cache の下限値とは認識されない為 Buffer Cache が 1Granul になるまで Shared Pool が自動拡張します V$MEMORY_RESIZE_OPS ビューの定期的な監視 隠しパラメータ _memory_imm_mode_without_autosga=false を設定し 本機能を無効化する ( 動的変更可能なパラメータ ) 88

89 Automatic Memory Management (AMM) Oracle Database 11g Release 1~ MEMORY_TARGET 初期化パラメータにより SGA (SGA_TARGET) と PGA (PGA_AGGREGATE_TARGET) が自動調整される機能 SGA 内は自動共有メモリ管理 (ASMM) と同じ動作 Shared Pool Large Pool Buffer Cache SGA Java Pool Stream Pool Shared IO Pool PGA 89

90 AMM memory_max_target pga_aggregate_target PGA memory_target 自動メモリ管理時の sga_target / pga_aggregate_target/ は 自動調整の際の最小値であり 実際の SGA と PGA の割当値と一致するとは限らない sga_target SGA memory_target は memory_max_target 以下で設定可能だが sga_target / pga_aggregate_target を設定している場合 memory_target はその合計サイズ以上で設定する必要あり 90

91 メモリ割り当ての優先度 下位の S/W スタック 業務影響が大きいコンポーネントを優先 性能重視ではなく 安定稼働重視 土台となる OS や ASM インスタンスが健全な状態でなければならない あくまで初期構築時に限定 Workload に応じて 随時適切に配分見直しは必須 Buffer Cache が不足する場合は 物理メモリの追加を検討 3 Buffer Cache 1 2 Others Shared Pool Database Server Processes DB Instance SGA PGA 6 Processes ASM Instance SGA PGA Free Memory Operating System

92 共有プールの基本的理解 (1/16) 共有プールとは SQL 定義情報 実行計画等が格納される共有メモリ領域 データベースで行われるほぼ全ての操作でアクセスされる領域 共有プール SGA バッファキャッシュ ライブラリキャッシュ 共有カーソル (SQL PL/SQL 実行計画 ) ディクショナリキャッシュ オブジェクト定義 ( オブジェクト ユーザー等のメタデータ ) オブジェクト定義 ( 表 索引等 ) OTHER リザルトキャッシュ 結果セット ( リザルトキャッシュ機能利用時 ) GCS (RAC 環境固有 ) GES (RAC 環境固有 ) ログバッファ その他 92

93 共有プールの基本的理解 (2/16) グラニュル (Granule) SGA や各プールのメモリ割り当ての最小単位 共有プールやバッファキャッシュ等の各領域のサイズはグラニュルサイズの倍数 ( グラニュルサイズ グラニュル数 ) となる SGA のサイズ (SGA_MAX_SIZE の値 ) に応じてグラニュルサイズは大きくなる 自動 SGA 管理 自動メモリ管理における自動調整 ( 拡張 / 縮小 ) はグラニュル単位で行われる SGA_MAX_SIZE グラニュルサイズ ~ 1GB 以下 4MB 1GB 超 ~ 8GB 以下 16MB 8GB 超 ~ 16GB 以下 32MB 16GB 超 ~ 32GB 以下 64MB 32GB 超 ~ 64GB 以下 128MB 64GB 超 ~ 128GB 以下 256MB 128GB 超 ~ 512MB 93

94 共有プールの基本的理解 (3/16) 存続期間による分割 存続期間による分割なし sga heap(1,0) sga heap(1,0) 存続期間の異なるメモリ領域が一つの領域に混在すると 領域が解放されたときにメモリの断片化が発生しやすくなる A: 使用中 ( 短期 ) B: 使用中 ( 長期 ) C: 使用中 ( 短期 ) メモリ領域は チャンク と呼ばれる可変サイズの断片で割り当てられる 上記 A~C の断片が チャンク にあたる メモリ解放 A: 空き B: 使用中 ( 長期 ) C: 空き 存続期間の短い A と C がまず解放されるが 間に存続期間の長い B が残るため大きな領域を次に割り当てることができない 存続期間による分割あり 同等の存続期間 ( 2) のメモリ領域を決まった領域に割り当てることで断片化が発生しにくくなる ( 2) チャンクの獲得から解放までの期間 A: 使用中 ( 短期 ) 存続期間に応じて異なるヒープに割り当てる B: 使用中 ( 長期 ) sga heap(n,3) C: 使用中 ( 短期 ) sga heap(n,2) sga heap(n,1) sga heap(n,0) サブプール #n メモリ解放 sga heap(n,3) A: 空き C: 空き B: 使用中 ( 長期 ) sga heap(n,2) sga heap(n,1) sga heap(n,0) サブプール #n 連続した空き領域に対して大きな領域を割り当てることが可能となる 断片化を低減するために存続期間による分割を導入 94

95 共有プールの基本的理解 (4/16) サブプール分割 サブプール分割なし サーバプロセス A 共有プール全体を 1 つのラッチで保護 サーバプロセス B サーバプロセス C 競合 shared pool latch sga heap(1,0) サブプール分割あり サブプール毎 ( 1) に 1 つのラッチで保護 最大で 7 個のラッチで共有プール全体を保護 サーバプロセス A メモリを獲得する際は 使用するサブプールをラウンドロビン方式で選択 サーバプロセス B shared pool latch sga heap(1,3) sga heap(1,2) sga heap(1,1) sga heap(1,0) サブプール #1 sga heap(2,3) sga heap(2,2) sga heap(2,1) ( 1) 存続期間毎に分割された従属ヒープ (sga heap) 単位でラッチが対応づくわけではない サーバプロセス C shared pool latch shared pool latch sga heap(2,0) サブプール #2 sga heap(n,3) sga heap(n,2) sga heap(n,1) sga heap(n,0) サブプール #n ラッチ競合を低減しパフォーマンスを向上するためにサブプール分割を導入 95

96 共有プールの基本的理解 (5/16) 共有プールの内部構造 KROWN# KROWN# サブプール分割 目的 : 共有プールを保護するラッチ (shared pool latch) の競合分散のため CPU 数と共有プールのサイズに応じて最大 7 個に分割 存続期間による分割 目的 : 断片化を予防するため メモリの存続期間に応じてサブプール毎に 4 個に分割 存続期間短い 存続期間長い sga heap(1,3) sga heap(1,2) sga heap(1,1) sga heap(1,0) サブプール #1 共有プール sga heap(2,3) sga heap(2,2) sga heap(2,1) sga heap(2,0) サブプール #2. Oracle Database では SGA や PGA 等の多くのメモリ領域を ヒープ と呼ばれる共通の構造で管理している 共有プールは複数の従属ヒープ sga heap(x,y) で構成される 最大で 28 個に分割される sga heap(n,3) sga heap(n,2) sga heap(n,1) sga heap(n,0) サブプール #n 例 SQL 領域親 / 子カーソル Library Cache 永続メモリ領域 96

97 共有プールの基本的理解 (6/16) サブプールの数と構成変更時の注意事項 KROWN# サブプールの数は以下の初期化パラメータ値によって決定される CPU_COUNT (CPU 数 )/SHARED_POOL_SIZE/SGA_TARGET/MEMORY_TARGET/MEMORY_MAX_TARGET 構成変更する際はサブプール毎のサイズに注意 CPU を増設する際 / 共有プールのサイズを変更する際 共有プールの分割数 (11gR2 の計算式 ) KROWN# CPU 数 共有プールサイズによる共有プールの分割について共有プールの分割数 = min( min( A, max( B, C )), 7 ) 構成変更により サブプール1つあたりのサイズが変化することがあるので注意 A = trunc((( CPU_COUNT - 1 ) / 4) + 1 ) B = trunc( SHARED_POOL_SIZE / 512M ) C = trunc(( SGA_TARGET / 2 ) / 512M ) 前提 : ( 特に小さくなった場合に 領域枯渇のリスクが高まるため注意 ) MEMORY_TARGET を設定していない または 0 に設定しており かつ SGA_TARGET > 0 を設定している場合 97

98 共有プールの基本的理解 (7/16) 共有プールへの新規メモリ割当ての流れ 1. フリーリストから空きを探すフリーリストは各従属ヒープ sga heap(x,y) 毎に存在 2.Reserved Granule ( 未割当ての領域 ) から確保 3. 予約済みプールから確保 ( 条件があえば ) 4. 使用済み領域を再利用 (LRU リストをフラッシュ & チャンクを連結して空きを作る ) 5. 共有プールを拡張 (IMMEDIATE モードでバッファキャッシュから空きを確保 ) 6.ORA-4031 エラー ( 要求サイズのメモリが割り当てられない ) 98

99 共有プールの基本的理解 (8/16) 空き領域 :Reserved Granule Reserved Granule インスタンス起動直後等に存在するグラニュル全体がまだ未使用の領域 V$SGASTAT の free memory は Reserved Granule を含む インスタンス起動直後. Reserved Granule が全て各サブプールに割り当てられた後は 各サブプール内の空き領域が再利用される Reserved Granule サブプール #1 サブプール #2 サブプール #n Reserved Granule のサイズは以下で確認可能 Reserved Granule 使用後 各サブプール内の空きが不足すると Reserved Granule から割り当てられる 追加. 追加 Reserved Granule サブプール #1 サブプール #2 サブプール #n SELECT KSMSSLEN "SIZE" FROM X$KSMSS WHERE KSMSSNAM = 'free memory' AND KSMDSIDX = 0; Reserved Granule からの割当ての結果 サブプール間で偏りが生じることがある 99

100 共有プールの基本的理解 (9/16) 予約済みプール KROWN# 予約済みプールは共有プールの一部 サイズ :shared_pool_reserved_size にて指定 ( デフォルト : 共有プールのサイズの 5%) 要求サイズが閾値 (11gR2 では SGA のグラニュル サイズの約 1/2 以上 ) を超えた場合にのみ使用される 他の領域の使用状況が逼迫していても予約済み領域は使用されていないことがある ( 領域が有効活用されていない場合があるので注意 ) 予約済みプール領域 sga heap(n,3) 共有プール内の各サブプール 従属ヒープ sga heap(x,y) から分散して予約済みプールとしてのチャンクが獲得される sga heap(n,2) 空き ( 予約済みプール領域 ) sga heap(n,1) sga heap(n,0) サブプール #n 予約済みプール領域 100

101 共有プールの基本的理解 (10/16) 空き領域 : 分割された各サブプール / 従属ヒープ内の空き領域の管理 空き領域は各従属ヒープ毎に個別に管理 / 使用される 特定のサブプールや従属ヒープにおいて空き領域が枯渇した場合でも他のサブプールや従属ヒープの空きメモリは使用されない サブプール #1 サブプール #2 sga heap(1,3) 空き領域不足 融通不可 sga heap(2,3) FREE LRU リストからフラッシュ ( 解放 ) した領域 ( 空き領域 (FREE チャンク )) は それぞれの従属ヒープのフリーリストに戻される LRU リスト 各サブプール毎に管理 sga heap(1,2) FREE sga heap(1,1) FREE sga heap(1,0) FREE フリーリスト 各従属ヒープ毎に管理 ( 予約済みフリーリストも同様 ) sga heap(2,2) FREE sga heap(2,1) FREE sga heap(2,0) FREE 例えば sga heap(1,3) の空きを作るために LRU フラッシュが発生した際 LRU スキャン中に sga heap(1,2) の解放可能なチャンクを見つけた場合は そのチャンクは sga heap(1,2) のフリーリストにリンクされる 101

102 共有プールの基本的理解 (11/16) 空き領域 : 共有プールの空き領域予備軍 バッファキャッシュ 共有プールが不足すると バッファキャッシュを減らして共有プールを拡張する ( 自動調整はグラニュル単位 ) DEFERRED モード ( 遅延要求 ) と IMMEDIATE モード ( 即時要求 ) がある ログバッファ その他 共有プール 最低値 (shared_pool_size) バッファキャッシュから共有プールにメモリを移動可能な領域 SGA_ TARGET バッファキャッシュ 他コンポーネントが不足した場合の拡張余力 最低値 (db_cache_size) DEFERRED モード : ( 自動 SGA 管理 自動メモリ管理 ) 定期取得した統計情報に基づいて行う IMMEDIATE モード : ( 手動 SGA 管理 自動 SGA 管理 自動メモリ管理 ) 拡張を行わないと ORA-4031 が発生する状況に陥った場合に行う 102

103 共有プールの基本的理解 (12/16) 共有プールの空きの量 各空き領域の消費推移 Reserved Granule を全て使用完了 空き インスタンス起動直後 予約済みプールの空き 予約済みプールは 大きなサイズの割当てがない限り利用されない 断片化が進行すると 再利用できない空き領域 ( 小さい空き領域 ) が徐々に増加し 空き領域が右肩上がりに増加する場合もある 予約済みプールの空きは 実際は有効利用されていない場合がある V$SGASTAT の free memory ( 空き領域 ) のみでは どのサブプールの空きか判断できない 共有プールの空きのみの監視では不十分 V$SGASTAT の [shared_pool].[free memory] で確認できる空き 時間 103

104 共有プールの基本的理解 (13/16) メモリ割当てエラー (ORA-4031) ORA-4031 の発生ケース 連続した空き領域を確保できない場合に発生するエラー 従来からの代表的な発生例は サイズが小さい 断片化によるもの 昨今のメモリ低コスト化 大規模化によって 余裕を持った共有プールのサイジングが可能となり 共有プール全体のサイズが小さいことが原因で ORA-4031 が発生するという事例は比較的減少傾向 ( 総量は足りているケースが多い ) sga heap(x,y) A: 空き B: 使用中 C: 空き D: 割当て要求 ORA-4031 要求したメモリサイズ分の連続した空き領域を確保できない場合には ORA-4031 が発生 104

105 共有プールの基本的理解 (14/16) 最近の ORA-4031 の傾向 サブプール間の偏り 最近の発生パターン 従属ヒープ ( 存続期間による分割 ) 間の偏り 共有プールの拡張余力がない ( 共有プール拡張時の供給元のバッファキャッシュの余力がない ) 実例 特定の機能に依存した処理の大量使用により 一部のサブプールが肥大化し 他のサブプールへの割り当てが失敗 ( 他のサブプールのサイズ ( 空き領域 ) が小さくなったため ) リテラル SQL を多く使用した環境において 共有 SQL 領域 (sga heap(n,3)) が肥大化した結果 存続期間が長い従属ヒープ (sga heap(n,1)) への割り当てが失敗 バッファキャッシュ最低サイズ (db_cache_size) の設定不備 ( 不必要に大きく設定されていた ) により 共有プールの自動拡張ができず 割り当てが失敗 共有プールの空き領域監視のみでは検知できない 105

106 共有プールの基本的理解 (15/16) 共有プールのサイズの考え方 サイズ (shared_pool_size) の設定 サブプールあたりのサイズを勘案して初期設計を検討するとよい 大きければ大きいほどよいという領域ではない (shared pool latch 待ち注意 ) サイズが小さいケース サイズが大きいケース サブプール #n sga heap(n,3) LRU リスト サブプール #n sga heap(n,3) LRU リスト FREE sga heap(n,2) 共有プールのサイズが小さ過ぎると メモリ枯渇 (ORA エラー ) が発生しやすくなる FREE sga heap(n,2) FREE sga heap(n,1) FREE sga heap(n,0) FREE 共有プールのサイズが大き過ぎると 空き領域を探す際のリストが長くなり shared pool latch 競合が発生しやすくなる FREE sga heap(n,1) FREE sga heap(n,0) FREE 106

107 共有プールの基本的理解 (16/16) まとめ 共有プールの構造 最大で 28 個に分割される ( サブプール分割 / 存続期間による分割 ) サブプール間での偏りが生じる場合がある 特定のサブプールや従属ヒープにおいて空き領域が枯渇した場合でも他のサブプールや従属ヒープの空きメモリは使用されない 共有プールの空き領域監視のみでは空きの枯渇は検知できない テストに完全な網羅性がないリスクは 拡張余力のリアルタイム監視で担保 107

108 設計 ~ テスト ~ 運用フェーズでの検討事項 1. 管理方式選定 手動 SGA 管理 自動 SGA 管理 自動メモリ管理の選択 2. 一次サイジング ( 自動 SGA 前提 ) 主要チャンクのサイズを意識した一次サイジング 共有プール自動拡張余力の確保 3. 監視 チューニング ( 自動 SGA 前提 ) テスト 運用フェーズの監視 チューニング ( 二次サイジング ) 設計 テスト 運用

109 1. 管理方式選定共有プール (SGA) 管理方式比較 比較項目手動 SGA 管理自動 SGA 管理 (10gR1~) 自動メモリ管理 (11gR1~) 概要 SGA の各 SGA コンポーネント ( バッファキャッシュ 共有プール ラージプールなど ) のサイズを個別に設定する SGA 全体のサイズを設定し 各 SGA コンポーネント ( バッファキャッシュ 共有プール ラージプールなど ) のサイズは 必要に応じて動的に調整される SGA と PGA の合計サイズを設定し PGA と各 SGA コンポーネント ( バッファキャッシュ 共有プール ラージプールなど ) のサイズは 必要に応じて動的に調整される 特徴 各コンポーネントの精緻なサイジングが必要 手動 SGA 管理でも 共有プールが不足した場合は IMMEDIATE モードで バッファキャッシュを縮小し 動的に共有プールが拡張される (11gR2~) (KROWN#151272) 一次サイジングが比較的容易 各 SGA コンポーネントの最低サイズを設定可能 11gR2 では広く採用されている 一次サイジングが比較的容易 PGA 各 SGA コンポーネントの最低サイズを設定可能 Linux では Hugepage との併用ができない PGA のサイズ変動により 同じ処理の性能が変わる可能性あり 109

110 1. 管理方式選定手動 SGA 管理 自動 SGA 管理 自動メモリ管理の採用率 日本オラクルでコンサル支援することが多い中 ~ 大規模のシステムでの経験値 自動 SGA 管理 95% 以上の採用率 推奨設定 11gR2 では 経験則的に 95% 以上のシステムで 広く一般的に採用されており日本オラクルコンサルが支援する場合に 初めに検討する方式 手動 SGA 管理 数 % 程度の採用率 旧バージョンからの移行のお客様以外 新規に採用するケースはほとんどない 自動メモリ管理 数 % 程度の採用率 中 ~ 大規模なシステムでも OS として Linux が選定されることが多くなってきており Hugepage と併用できないため 積極的に採用されるに至っていない 110

111 設計 ~ テスト ~ 運用フェーズでの検討事項 1. 管理方式選定 手動 SGA 管理 自動 SGA 管理 自動メモリ管理の選択 2. 一次サイジング ( 自動 SGA 前提 ) 主要チャンクのサイズを意識した一次サイジング 共有プール自動拡張余力の確保 3. 監視 チューニング ( 自動 SGA 前提 ) テスト 運用フェーズの監視 チューニング ( 二次サイジング ) 設計 テスト 運用

112 2. 一次サイジング 共有プールを 3 つの領域に分割して一次サイジング 初期設定値計算イメージ 共有プールに占める主要なチャンク領域を見積もる バッファキャッシュ依存領域 バッファキャッシュのブロック数に応じて計算する 共有 SQL 領域 経験則的に十分なサイズを確保する 各種可変領域 サブプール数に応じて一次サイジングする 3 つの領域の合計に余裕率を掛けて計算する shared_pool_size 初期設定値 = バッファキャッシュ依存領域 ( 固定領域 ) + 共有 SQL 領域 ( 可変領域 ) + 各種可変領域 ( 可変領域 ) X 1.2 倍 ( 余裕率 ) サブプール共有プール #2 #1 #n バッファキャッシュ依存領域 ( 計算式により固定値算出 ) 共有 SQL 領域各種可変領域 ( サブプール数分 ) 112

113 2. 一次サイジング バッファキャッシュ依存領域 (RAC/Single 共通 ) db_block_hash_buckets バッファキャッシュを管理するハッシュ バケットの領域がキャッシュされる バッファキャッシュのブロック数に比例して大きくなり 大規模なバッファキャッシュを確保するシステムでは 共有プールのサイジングに注意が必要 KROWN# バッファ キャッシュのサイズ変更時の注意点 固定領域 KROWN# サイズ見積もり (11gR2の場合) バッファキャッシュ1GBにつき15MBで計算 11gR2の実績から導出した参考値 実機確認の上 調整する db_block_size=8kbの前提 113

114 2. 一次サイジング バッファキャッシュ依存領域 (RAC のみ ) 固定領域 gcs resource/gcs shadow RAC ノード間で バッファキャッシュ上のデータブロックの整合性を管理するためのロック可能な実体 gcs resource/gcs shadow はバッファキャッシュのブロック数に比例して大きくなり 大規模なバッファキャッシュ環境では 共有プールを圧迫する可能性あり サイズ見積もり (11gR2 の場合 ) db_block_size=8k では バッファキャッシュ 1GB につき 45MB で計算 11gR2 で 2~3 ノード環境の実績から導出した参考値 gcs shadow はノード数によって異なりますので 実機確認の上 調整する 原則的には起動時のサイズで固定的に確保されるが DRM(Dynamic Resource Mastering) などによるリソースマスタの偏りによって 変動する可能性あり 114

115 2. 一次サイジング 共有 SQL 領域 可変領域 SQLA( 共有 SQL 領域 ( 共有カーソル領域 )) SQL テキストや実行計画などがキャッシュされる SQL が十分に共有化されていれば節約できる SQL が十分に共有された状態 下記 2 点をいずれも満たす : SQL のヒット率 (AWR の Soft Parse % ) が 95% 以上 2 回以上実行された SQL の共有プール占有率 (AWR の % SQL with executions>1 ) が 95% 以上 高 SQL ヒット率でもリテラル SQL が多い例 数種類の共有された SQL を 100 万回実行 リテラル SQL を 1 万回実行 SQL のヒット率 99% リテラル SQL が多い 子カーソルが多く生成されるようなシステムで肥大し易いため 大きく見積もる 115

116 2. 一次サイジング 各種可変領域 各種可変領域の机上見積もりは不可能 共有 SQL 以外の可変領域で そのサイズは 使用する機能 使い方 同時実行並列度に依存するため 見積もりは困難 サブプール数から仮見積もりする サブプールあたりのサイズを十分に確保する CPU 数が多い ( サブプールが多い ) システムでは 処理の多様性が高くなり より多くの領域が必要 プール分割に起因する障害防止 悪い例 可変領域 総量では 2.1GB と大きいが サブプールが小さいため 更に従属ヒープに分割され ORA-4031 が発生し易い 共有プール (2.1GB) #1 300M #7 300M サブプール 116

117 2. 一次サイジング 共有プール自動拡張余力の確保 db_cache_size と shared_pool_size には最低サイズを設定する [sga_target > 各 SGA コンポーネント設定値の和 ] になるよう 共有プールの拡張余力を十分に確保する SGA_ TARGET バッファキャッシュ ログバッファ その他 共有プール 最低値 (shared_pool_size) 他コンポーネントが不足した 場合の拡張余力 最低値 (db_cache_size) 共有プールと同サイズ程度の拡張余力があれば 共有プールが自動拡張した後 対処の為の時間的猶予ができる 初期サイジングでは バッファキャッシュからの共有プール拡張余力を十分に確保して テストに臨むことが重要 117

118 2. 一次サイジング RAC 縮退運転時の考慮 RAC 環境の場合は 必要に応じて縮退運転時の余裕分を考慮する 完全にアプリケーションパーティショニングされている RAC 環境では 縮退運転時に 生存ノードでは全く異なるタイプの処理を受け付けることになる 例 ノード間で実行されている SQL が異なるため 縮退時の SQLA が増加 ノード間でアクセスするオブジェクトが異なるため ディクショナリキャッシュが増加 ノード間で発生するロックの種類が異なるため GES 関連領域が増加 縮退運転のテストにて増加分を検討する 見積もりは困難であるため 縮退運転のテストにおいて 特定チャンクが過剰に増加していないか確認の上 共有プールのサイズ追加を検討する 118

119 設計 ~ テスト ~ 運用フェーズでの検討事項 1. 管理方式選定 手動 SGA 管理 自動 SGA 管理 自動メモリ管理の選択 2. 一次サイジング ( 自動 SGA 前提 ) 主要チャンクのサイズを意識した一次サイジング 共有プール自動拡張余力の確保 3. 監視 チューニング ( 自動 SGA 前提 ) テスト 運用フェーズの監視 チューニング ( 二次サイジング ) 設計 テスト 運用

120 3. 監視 チューニング空き率分析の問題点 共有プールの監視 共有プールの空き率監視 チャンク別のサイズ遷移分析 などが一般的 共有プールの空き率分析の問題点 V$SGASTAT の [shared pool].[free memory] には 予約済プールが含まれるため 空きが枯渇することはほぼない 空きが少なくても 使用頻度の低いチャンクを再利用できていれば問題ない サブプール別 従属ヒープ別の空きは確認できない 断片化が進行すると 再利用可能な連続領域が減少し 逆に空き率が上昇傾向を示すことがある 120

121 推奨する共有プールの監視 共有プールに関するリアルタイム監視は 1 で実施する 2~6 と高負荷の 7 は必要に応じて情報収集を検討する No. 監視 / 分析の内容監視 / 情報採取の方法種別 監視 チューニング 共有プール拡張余力の監視 共有プールのサイズ遷移の傾向分析 チャンク別サイズ遷移の傾向分析 V$SGA_DYNAMIC_COMPONENTS による自動拡張余力の監視 AWR レポートの Memory Dynamic Components セクション参照 AWR レポートの SGA breakdown difference セクション参照 : 必須 : 推奨 : 必要に応じて検討 テストフェーズ 運用フェーズ リアル監視 情報取得 情報取得 4 サブプール別の偏り傾向分析 X$KSMSS のロギング情報取得 5 予約済みプールの傾向分析 V$SHARED_POOL_RESERVED のロギング情報取得 6 巨大 SQL を検知する Memory Notification の閾値変更 (50MB 2MB 等 ) 情報取得 7 従属ヒープ別の偏り傾向分析 X$KSMSP のロギング ( latch を掴むため高負荷 ) 情報取得 121

122 3. 監視 チューニング 1 共有プール拡張余力の監視 ( リアルタイム監視 )(1) 自動 SGA 管理の設計指針として重要なのは 共有プールの拡張余力を十分に残す こと インスタンスの再起動を頻繁にできない環境では 早めに検知できる閾値を設定する 監視間隔は 30 分 ~ 60 分間隔程度で十分 共有プールの拡張余力を監視する 運用 テスト 拡張余力が十分に確保されていることを監視する 122

123 3. 監視 チューニング 1 共有プール拡張余力の監視 ( リアルタイム監視 )(2) 運用 テスト V$SGA_DYNAMIC_COMPONENTS による拡張余力の監視 バッファキャッシュの 現在値 (CURRENT_SIZE) - 初期設定値 (USER_SPECIFIED_SIZE) に十分余裕があることを確認 バッファキャッシュの 現在値 から 初期設定値 を引いた数値が共有プールの自動拡張余力と言える 例 2GB の db_cache_size を設定したが 現在は 4G 程 (4,385,875,968byte) であり 共有プールが不足した場合 2G 程 (2,238,392,320byte) の拡張余力がある SELECT USER_SPECIFIED_SIZE,CURRENT_SIZE, CURRENT_SIZE - USER_SPECIFIED_SIZE SIZE_DIFFERENCE FROM V$SGA_DYNAMIC_COMPONENTS WHERE COMPONENT = 'DEFAULT buffer cache'; USER_SPECIFIED_SIZE CURRENT_SIZE SIZE_DIFFERENCE ,147,483,648 4,385,875,968 2,238,392,

124 3. 監視 チューニング 2 共有プールのサイズ遷移の傾向分析 ( 情報取得 )(1) 運用 テスト 共有プールが自動拡張機能で拡張を続けていないか確認 IMMEDIATE モードや DEFERRED モードによる自動拡張が頻発していない ( 各コンポーネントのサイズが安定推移している ) ことを確認する 共有プールが拡張し続けるような傾向にあれば 1 の監視閾値を越える前に 対策をする必要がある 処理特性が同じ時間帯に 共有プールとバッファキャッシュの間で 短時間に頻繁に奪い合いが発生 ( 増減を繰り返す ) していたら SGA が不足していると考えられる 対処 3 の分析で特定チャンクの過剰消費があれば原因を分析する sga_target/shared_pool_size を見直す 124

125 2012/9/25 00:00: /9/25 01:00: /9/25 02:00: /9/25 03:00: /9/25 04:00: /9/25 05:00: /9/25 06:00: /9/25 07:00: /9/25 08:00: /9/25 09:00: /9/25 10:00: /9/25 11:00: /9/25 12:00: /9/25 13:00: /9/25 14:00: /9/25 15:00: /9/25 16:00: /9/25 17:00: /9/25 18:00: /9/25 19:00: /9/25 20:00: /9/25 21:00: /9/25 22:00: /9/25 23:00: /9/25 00:00: /9/25 01:00: /9/25 02:00: /9/25 03:00: /9/25 04:00: /9/25 05:00: /9/25 06:00: /9/25 07:00: /9/25 08:00: /9/25 09:00: /9/25 10:00: /9/25 11:00: /9/25 12:00: /9/25 13:00: /9/25 14:00: /9/25 15:00: /9/25 16:00: /9/25 17:00: /9/25 18:00: /9/25 19:00: /9/25 20:00: /9/25 21:00: /9/25 22:00: /9/25 23:00:10 MB MB 3. 監視 チューニング 2 共有プールのサイズ遷移の傾向分析 ( 情報取得 )(2) 運用 テスト SGA コンポーネントのサイズ遷移を確認する AWR レポートの Memory Dynamic Components セクションの時系列データ 定期取得した V$SGA_DYNAMIC_COMPONENTS (1 のリアルタイム監視と情報ソースは同じ ) 500, , , , , , , , ,000 50,000 0 Memory Dynamic Components shared pool と db cache の奪い合いが続いている streams pool shared pool Shared IO Pool large pool java pool DEFAULT buffer 60,000 50,000 40,000 30,000 20,000 10,000 0 Memory Dynamic Components shared pool の拡張が続いている streams pool shared pool Shared IO Pool large pool java pool DEFAULT buffer 125

126 3. 監視 チューニング 2 共有プールのサイズ遷移の傾向分析 ( 情報取得 )(3) 運用 テスト 性能テスト 本番運用開始時の注意 テスト 運用開始時点で 共有プールの拡張余力が十分残っていることを AWR や V$SGASTAT などで確認すること テストデータの作成 大量オブジェクトのコンパイル 移行データの作成などで 実運用時と異なる用途の領域により共有プールが自動拡張している場合がある 共有プール初期値 ( 最低値 ): 2GB SGA_ TARGET 6 G B テスト 運用開始 テスト 運用開始バッファキャッシュ初期値 ( 最低値 ):2GB 時間経過 テスト運用開始時点で 共有プールの拡張余力がなくなっている 126

127 3. 監視 チューニング 3チャンク別サイズ遷移の傾向分析 ( 情報取得 )(1) 運用 テスト 共有プールのチャンクサイズの推移を確認する 空き領域と 先に上げた 共有 SQL 領域 RAC 依存領域など重要なチャンクを中心に サイズの推移を確認する 各チャンクサイズが安定的に推移しているか 特定チャンクが増加し続ける傾向がないか確認する 空き領域の大小をそれほど注目して見る必要はない 127

128 3. 監視 チューニング 3 チャンク別サイズ遷移の傾向分析 ( 情報取得 )(2) 運用 テスト AWR レポートの SGA breakdown difference より時系列にグラフ化 定期的取得した V$SGASTAT より時系列にグラフ化 特定のチャンクが肥大し続けることなく安定推移 128

129 3. 監視 チューニング 4 サブプール別の偏り傾向分析 ( 情報取得 )(1) 運用 テスト サブプール間の偏りを確認する 共有プール全体として空きがあっても 特定のサブプールの肥大により ORA-4031が発生することがある リアルタイム監視は不要だが テストの時や 新規アプリリリース後の本番環境などで 特定のサブプールに偏りがないか確認し 極端な偏りは 原因を明らかにする 偏りが見つかった場合の対処 偏りの原因を分析する sga_target/shared_pool_size を見直し 各サブプールが十分大きくなるように調整する ( サブプール別の割り当てサイズは手動制御できないため ) 共有プール (2.4GB) #1 300M 悪い例 サブプール #2 に割り当てが極端に偏っている #2 1500M #3 300M サブプール #4 300M 129

130 3. 監視 チューニング 4 サブプール別の偏り傾向分析 ( 情報取得 )(2) 運用 テスト X$KSMSS(V$SGASTAT の元表 ) で サブプール別のサイズと空きを確認 例 SELECT KSMDSIDX SUBPOOL#,DECODE(KSMSSNAM,'free memory','free memory','used memory') TYPE,SUM(KSMSSLEN) BYTES FROM X$KSMSS GROUP BY KSMDSIDX,decode(KSMSSNAM,'free memory','free memory','used memory') ORDER BY KSMDSIDX,decode(KSMSSNAM,'free memory','free memory','used memory'); SUBPOOL# TYPE BYTES free memory 0 0 used memory 0 1 free memory 52,393,584 1 used memory 232,819,088 2 free memory 53,940,240 2 used memory 231,272,432 3 free memory 46,664,144 3 used memory 221,771,312 4 free memory 60,816,984 4 used memory 190,841,256 Reserved Granule の空きは すでに枯渇 4 つのサブプールに分割されており ほぼ均等に割り当てられている 偏りがある場合は DECODE と SUM() を外して 何のチャンクが偏っているか確認する 130

131 3. 監視 チューニング 5 予約済みプールの傾向分析 運用 テスト 予約済みプールの空き領域確認 V$SGASTAT.[shared_pool].[free memory] の値には 予約済みプールの空きが含まれており 要求サイズが小さい場合は使える領域ではない V$SHARED_POOL_RESERVED.USED_SPACE と FREE_SPACE で 共有プール全体に占める 予約済みプールの使用サイズ 空きサイズを確認する 予約済みプールとして割り当てられる デフォルトの shared_pool_size x 5% がどの程度消費されているか確認する 対処 予約済みプールがほとんど使用されていない場合は 予約済みプールのサイズ (SHARED_POOL_RESERVED_SIZE) を小さくし 非予約済みプールに割り当てたほうが有効 予約済みプールの空きが枯渇している場合は SGA のグラニュル サイズの 1/2 以上のチャンクが頻繁に割り当てられる原因を調査した上で 必要に応じて 共有プールの拡張を検討する 131

132 3. 監視 チューニング 6 巨大 SQL を検知する ( 情報取得 ) 運用 テスト Memory Notification で巨大 SQL を検知する Memory Notification(_kgl_large_heap_warning_threshold) は一定サイズ以上の SQL が実行されたことを アラート ログにメッセージ出力する機能 テストで閾値を小さめに設定しておくことにより 極端に大きな SQL を検知し 事前に対処することが可能 以降は 50MB 以上の SQL が実行されると メッセージ出力 KROWN# アラート ログにライブラリ キャッシュ オブジェクトの SGA への割り当てに関するメッセージが出力される KROWN# アラート ログメッセージ例 Wed Dec 26 12:38: Memory Notification: Library Cache Object loaded into SGAHeap size 1018K exceeds notification threshold (70K) Details in trace file D: APP diag rdbms orcl trace orcl_ora_2352.trc KGL object name :SELECT /* Test SQL */ COL01, COL02, COL03FROM TAB01, TAB02, TAB03 WHERE 132

133 3. 監視 チューニング 7 従属ヒープ別の偏り傾向分析 ( 情報取得 ) X$KSMSP で 従属ヒープ別のサイズと空きを確認 検索時に shared pool latch を取得し負荷が高いため 本番環境や性能テスト中の採取は推奨しない 従属ヒープの肥大や 断片化状態を分析するなど 個別の障害分析目的で取得することが多い 性能 負荷テスト終了後や 本番のオンライン終了後 バッチ終了後のような処理の切れ目で情報取得しておくと ORA-4031 の分析に役立つ場合がある KROWN#19607 ライブラリ キャッシュのメモリ使用状況確認スクリプト KROWN# X$ 表から分割された共有プールの各プールごとの使用状況を確認する方法 運用 テスト KROWN#19607 KROWN#

134 まとめ 共有プールのサイジング テスト 運用の重要ポイント ORA-4031 撲滅 1 自動 SGA 管理の使用を推奨 2 大規模バッファキャッシュ環境 ( 特に RAC 環境 ) では バッファキャッシュ依存領域を上乗せしてサイジングする 3 1 サブプールあたりのサイズを十分に大きくサイジングする 4 共有プールの自動拡張余力を残して バッファキャッシュの最低サイズを設定する 5 共有プールの自動拡張余力が残っていることをリアルタイム監視する 134

135 目的とゴール 目的 SQLチューニングで有効となるテクニックとメモリ障害の予防を知るゴール SQLチューニングにおける様々な 戦術 をつかむ 予測(Estimate) と 実測(Actual) の乖離を捉える補正する ORA-4031 撲滅 共有プールの性質の理解 メモリ設計 監視のポイント 135

136

スライド 1

スライド 1 オラクル コンサルが語る! 共有プール管理の極意 日本オラクル株式会社テクノロジーコンサルティング統括本部シニアプリンシパルコンサルタント辰巳昌紀プリンシパルコンサルタント池田大地 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント

More information

untitled

untitled Oracle Direct Seminar SQL Agenda SQL SQL SQL SQL 11g SQL FAQ Oracle Direct SQL Server MySQL PostgreSQL Access Application Server Oracle Database Oracle Developer/2000 Web Oracle Database

More information

はじめに コースの概要と目的 Oracle をより効率的に使用するための SQL のチューニング方法について説明します また 索引の有無 SQL の 記述方法がパフォーマンスにどのように影響するのかを実習を通して理解します 受講対象者 アプリケーション開発者 / データベース管理者の方 前提条件 S

はじめに コースの概要と目的 Oracle をより効率的に使用するための SQL のチューニング方法について説明します また 索引の有無 SQL の 記述方法がパフォーマンスにどのように影響するのかを実習を通して理解します 受講対象者 アプリケーション開発者 / データベース管理者の方 前提条件 S はじめに コースの概要と目的 Oracle をより効率的に使用するための SQL のチューニング方法について説明します また 索引の有無 SQL の 記述方法がパフォーマンスにどのように影響するのかを実習を通して理解します 受講対象者 アプリケーション開発者 / データベース管理者の方 前提条件 SQL トレーニング データベース アーキテクチャ コースを受講された方 もしくは同等の知識をお持ちの

More information

第 5 章 結合 結合のパフォーマンスに影響を与える結合の種類と 表の結合順序について内部動作を交えて 説明します 1. 結合処理のチューニング概要 2. 結合の種類 3. 結合順序 4. 結合処理のチューニングポイント 5. 結合関連のヒント

第 5 章 結合 結合のパフォーマンスに影響を与える結合の種類と 表の結合順序について内部動作を交えて 説明します 1. 結合処理のチューニング概要 2. 結合の種類 3. 結合順序 4. 結合処理のチューニングポイント 5. 結合関連のヒント はじめに コース概要と目的 Oracle をより効率的に使用するための SQL チューニング方法を説明します また 索引の有無 SQL の記述方 法がパフォーマンスにどのように影響するのかを実習を通して習得します 受講対象者 アプリケーション開発者 / データベース管理者の方 前提条件 SQL トレーニング データベース アーキテクチャ コースを受講された方 もしくは同等の知識をお持 ちの方 テキスト内の記述について

More information

スライド 1

スライド 1 ! ~Oracle Database を監視しよう ~ Session by Shinnosuke Akita 2014.02.00 Self Introduction Shinnosuke Akita Oracle DBA をやっています 今の現場は DB 設計もやっています 入社 2 年目 休日はランニングと家族サービス たまに小説も書いたり 勉強会にでかけたり 大衆酒場めぐりがマイブーム Today

More information

PowerPoint Presentation

PowerPoint Presentation MySQL Workbench を使ったデータベース開発 日本オラクル株式会社山崎由章 / MySQL Senior Sales Consultant, Asia Pacific and Japan 1 Copyright 2013, Oracle and/or its affiliates. All rights reserved. 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです

More information

PA4

PA4 SQL チューニングによる 性能改善の効果とポイント 株式会社アクアシステムズ PPA4003J-00-00 株式会社アクアシステムズ Oracle データベースを専門とする技術者集団 Oracle チューニング & 監視ツール Performance Analyzer の開発 / 販売 Oracle 診断及びパフォーマンスチューニング Oracle データベースに関するコンサルティング Oracle

More information

自己管理型データベース: 自動SGAメモリー管理

自己管理型データベース: 自動SGAメモリー管理 自己管理型データベース : 自動 SGA メモリー管理 オラクル ホワイト ペーパー 2004 年 8 月 自己管理型データベース : 自動 SGA メモリー管理 概要... 3 現在の課題... 3 自動共有メモリー管理の導入... 4 SGA_TARGET パラメータ... 4 SGA コンポーネントの自動管理... 4 手動でサイズを指定する SGA コンポーネント... 6 利点... 7

More information

Null

Null Technical Discussion Night ~ 今宵のテーマ : DB 12c クエリー オプティマイザ ( パフォーマンス チューニング ) を語ろう ~ 日本オラクル株式会社クラウド テクノロジー事業統括 Database & Exadata プロダクトマネジメント本部 Copyright 2017, Oracle and/or its affiliates. All rights reserved.

More information

A. 前ページからの続きです DBMS_SPACE.UNUSED_SPACE の各パラメータの意味 segment_owner = オブジェクトの所有者 segment_name = オブジェクト名 segment_type = オブジェクトタイプ total_blocks = セグメント合計ブロッ

A. 前ページからの続きです DBMS_SPACE.UNUSED_SPACE の各パラメータの意味 segment_owner = オブジェクトの所有者 segment_name = オブジェクト名 segment_type = オブジェクトタイプ total_blocks = セグメント合計ブロッ 対応バージョン :Oracle 10gR1 ~ 12cR1 本資料は アシスト Oracle 研修をご受講いただいたお客様からのご質問や 研修ではご案内できなかった情報などを FAQ にまとめたものです 研修受講後のスキルアップの一助として 是非お役立てください ご利用上の注意事項は最後のページにまとめられております ご確認のうえ ご利用ください 第 1 章 SQL パフォーマンスチューニングの基礎知識

More information

Oracle Database 10g Release 2を使用したデータベース・パフォーマンス

Oracle Database 10g Release 2を使用したデータベース・パフォーマンス Oracle Database 10g Release 2 2005 9 Oracle Database 10g Release 2... 3... 3... 3 Automatic Workload Repository AWR... 3 Automatic Database Diagnostic Monitor ADDM... 4 Automatic SQL Tuning SQL... 4 SQL

More information

Oracle SQL Developerの移行機能を使用したOracle Databaseへの移行

Oracle SQL Developerの移行機能を使用したOracle Databaseへの移行 < ここに画像を挿入 > Oracle SQL Developer の移行機能を使用した Oracle Database への移行 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい

More information

自己管理型データベース: アプリケーションおよびSQLチューニング・ガイド

自己管理型データベース: アプリケーションおよびSQLチューニング・ガイド : SQL 2005 9 : SQL... 3 SQL... 6... 8... 9 SQL :... 9 SQL... 10... 11 SQL... 12 SQL TUNING SET... 13 SQL... 14 ADDM SQL... 14 SQL... 15 STS... 15... 16 SQL... 16 DBMS_SQLTUNE... 17... 17 SQL... 19 SQL

More information

ORACLE TUNING PACK 11G

ORACLE TUNING PACK 11G 注 : 本書は情報提供のみを目的としています 下記の事項は マテリアルやコード 機能の提供を確約するものではなく また 購買を決定する際の判断材料とはなりえません 本書に記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定いたします ORACLE TUNING PACK 11G 主な機能 SQL Tuning Advisor Automatic SQL Tuning Advisor

More information

はじめに コース概要と目的 Oracle データベースのパフォーマンス問題の分析方法 解決方法を説明します 受講対象者 データベース管理者の方を対象としています 前提条件 データベース アーキテクチャ データベース マネジメント を受講された方 もしくは同等の知識 をお持ちの方 テキスト内の記述につ

はじめに コース概要と目的 Oracle データベースのパフォーマンス問題の分析方法 解決方法を説明します 受講対象者 データベース管理者の方を対象としています 前提条件 データベース アーキテクチャ データベース マネジメント を受講された方 もしくは同等の知識 をお持ちの方 テキスト内の記述につ はじめに コース概要と目的 Oracle データベースのパフォーマンス問題の分析方法 解決方法を説明します 受講対象者 データベース管理者の方を対象としています 前提条件 データベース アーキテクチャ データベース マネジメント を受講された方 もしくは同等の知識 をお持ちの方 テキスト内の記述について 構文 [ ] 省略可能 { A B } A または B のどちらかを選択 n _ 数値の指定 デフォルト値

More information

第 7 章 ユーザー データ用表領域の管理 この章では 表や索引を格納するユーザー データ用表領域の作成や 作成後のメンテナンスに ついて解説します 1. ユーザー データ用表領域の管理概要 2. ユーザー データ用表領域作成時の考慮事項 3. ユーザー データ用表領域の作成 4. ユーザー データ

第 7 章 ユーザー データ用表領域の管理 この章では 表や索引を格納するユーザー データ用表領域の作成や 作成後のメンテナンスに ついて解説します 1. ユーザー データ用表領域の管理概要 2. ユーザー データ用表領域作成時の考慮事項 3. ユーザー データ用表領域の作成 4. ユーザー データ はじめに コース概要と目的 効率良く Oracle データベースを使用するための運用管理について 管理タスクを行う上での考慮事項や注意 点を実習を通して習得します 受講対象者 データベース管理者 前提条件 データベース アーキテクチャ コースを受講された方 もしくは Oracle システム構成とデータベース構 造に関する知識をお持ちの方 テキスト内の記述について 構文 [ ] 省略可能 { A B

More information

Slide 1

Slide 1 Oracle Data Guard の構築とフェイルオーバー実行例 日本オラクル株式会社 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい

More information

Oracle Database 12c

Oracle Database 12c 免責事項 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます

More information

~~~~~~~~~~~~~~~~~~ wait Call CPU time 1, latch: library cache 7, latch: library cache lock 4, job scheduler co

~~~~~~~~~~~~~~~~~~ wait Call CPU time 1, latch: library cache 7, latch: library cache lock 4, job scheduler co 072 DB Magazine 2007 September ~~~~~~~~~~~~~~~~~~ wait Call CPU time 1,055 34.7 latch: library cache 7,278 750 103 24.7 latch: library cache lock 4,194 465 111 15.3 job scheduler coordinator slave wait

More information

今さら聞けない!? Oracle入門 ~後編~

今さら聞けない!? Oracle入門 ~後編~ Oracle Direct Seminar 今さら聞けない!? Oracle 入門 ~ 後編 ~ 日本オラクル株式会社 Agenda 1. Oracle の基本動作 2. Oracle のファイル群 3. Oracle のプロセス群と専用メモリ領域. データベース内部動作 今さら聞けない!? オラクル入門 ~ 後編 ~. データベース内部動作 検索時の動作更新時の動作バックアップについて

More information

untitled

untitled Oracle Direct Seminar !?Oracle Database 11g Agenda Oracle Database Enterprise Manager Oracle Direct Concierge SQL Server MySQL PostgreSQL Access Oracle Database Oracle Developer/2000

More information

今さら聞けない!? Oracle入門 ~前編~

今さら聞けない!? Oracle入門 ~前編~ Oracle Direct Seminar 今さら聞けない!? Oracle 入門 ~ 前編 ~ 日本オラクル株式会社 Agenda 1. Oracle の基本動作 2. Oracle のファイル群 3. Oracle のプロセス群と専用メモリ領域 4. データベース内部動作 今さら聞けない!? オラクル入門 ~ 後編 ~ 4. データベース内部動作

More information

Oracle Database Connect 2017 JPOUG

Oracle Database Connect 2017 JPOUG Oracle Database Connect 2017 / JPOUG 異なるデータベース間の SQL 比較と Oracle Database 12c の新機能 Noriyoshi Shinoda March 8, 2017 自己紹介篠田典良 ( しのだのりよし ) 所属 日本ヒューレット パッカード株式会社テクノロジーコンサルティング事業統括 現在の業務 Oracle Database をはじめ

More information

PostgreSQL SQL チューニング入門 ~ Explaining Explain より ~ 2012 年 11 月 30 日 株式会社アシスト 田中健一朗

PostgreSQL SQL チューニング入門 ~ Explaining Explain より ~ 2012 年 11 月 30 日 株式会社アシスト 田中健一朗 PostgreSQL SQL チューニング入門 ~ Explaining Explain より ~ 2012 年 11 月 30 日 株式会社アシスト 田中健一朗 アジェンダ 1.EXPLAIN とは 2. 表アクセスの基本 3. 結合の基本 4. 統計情報とは 5.EXPLAIN コマンド 6. 問題解決例 7. まとめ 2 1.EXPLAIN とは 実行計画とは - 目的地は 1 つでもアクセス方法は複数

More information

Slide 1

Slide 1 インメモリ パラレル処理 データ圧縮技術がもたらす超高速データベース ~ システムの運用 そしてビジネスを変える ~ 日本オラクル株式会社テクノロジー製品事業統括本部データベースビジネス推進本部 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は

More information

Oracle Web CacheによるOracle WebCenter Spacesパフォーマンスの向上

Oracle Web CacheによるOracle WebCenter Spacesパフォーマンスの向上 Oracle ホワイト ペーパー 2010 年 2 月 Oracle Web Cache による Oracle WebCenter Spaces パフォーマンスの向上 免責事項 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント

More information

バッチ処理にバインド変数はもうやめません? バッチ処理にバインド変数はもうやめません?

バッチ処理にバインド変数はもうやめません? バッチ処理にバインド変数はもうやめません? バッチ処理にバインド変数はもうやめません? ~ バッチ処理の突発遅延を題材にして考えてみる ~ 2012/4/6 株式会社コーソル渡部亮太 今日お伝えしたいこと バッチ処理 SQL を バインド変数化するの はやめませんか? OLTP 処理 SQL はバインド変数化して OK なんだけどね 自己紹介 + 所属企業の紹介 渡部亮太 ( わたべりょうた ) SE PM を経験後 Oracle Database

More information

自己管理データベース: 自動SGAメモリー管理

自己管理データベース: 自動SGAメモリー管理 : SGA Tirthankar Lahiri, Arvind Nithrakasyhap, Brian Hirano, Kant Patel, Poojan Kumar, Sushil Kumar Oracle Corporation Oracle Database 10g 1 SGA Oracle Oracle Oracle SGA SQL PL/SQL Java Java Java SGA shared_pool_size

More information

Slide 1

Slide 1 Oracle Direct Seminar 実践パフォーマンスチューニングオプティマイザ活用編 日本オラクル株式会社 Agenda オプティマイザとは コストベース オプティマイザでの運用管理 無償技術サービス Oracle Direct Concierge SQL Server からの移行アセスメント MySQL からの移行相談 PostgreSQL からの移行相談 Access からの移行アセスメント

More information

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション Oracle GRID Center Flash SSD + 最新ストレージと Oracle Database で実現するデータベース統合の新しい形 2011 年 2 月 23 日日本オラクル Grid Center エンジニア岩本知博 進化し続けるストレージ関連技術 高速ストレージネットワークの多様化 低価格化 10GbE FCoE 8Gb FC ディスクドライブの多様化および大容量 / 低価格化

More information

Enterprise Manager 10gによるデータベース・パフォーマンスチューニング

Enterprise Manager 10gによるデータベース・パフォーマンスチューニング Oracle Direct Seminar < 写真欄 > EnterpriseManager10g によるデータベース パフォーマンスチューニング Agenda Enterprise Manager 10g 概要 DB 運用 管理に関する課題 障害やパフォーマンス劣化時の迅速な通知 パフォーマンス問題の切り分けとチューニング まとめ 2 Agenda Enterprise Manager 10g

More information

Oracle 入門 ~ 研修受講後のスキルアップサポート ~ 対応バージョン :Oracle 10gR1 ~ 12cR1 本資料は アシスト Oracle 研修をご受講いただいたお客様からのご質問や 研修ではご案内できなかった情報などを FAQ にまとめたものです 研修受講後のスキルアップの一助とし

Oracle 入門 ~ 研修受講後のスキルアップサポート ~ 対応バージョン :Oracle 10gR1 ~ 12cR1 本資料は アシスト Oracle 研修をご受講いただいたお客様からのご質問や 研修ではご案内できなかった情報などを FAQ にまとめたものです 研修受講後のスキルアップの一助とし Oracle 入門 ~ 研修受講後のスキルアップサポート ~ 対応バージョン :Oracle 10gR1 ~ 12cR1 本資料は アシスト Oracle 研修をご受講いただいたお客様からのご質問や 研修ではご案内できなかった情報などを FAQ にまとめたものです 研修受講後のスキルアップの一助として 是非お役立てください ご利用上の注意事項は最後のページにまとめられております ご確認のうえ ご利用ください

More information

MySQL研修コース & 資格のご案内

MySQL研修コース & 資格のご案内 < 写真欄 > MySQL 研修コース & 資格のご案内 2011/2/25 日本オラクル株式会社 オラクルユニバーシティ 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい

More information

第 3 章 メディア障害とバックアップ リカバリ この章では メディア障害の発生に備えたバックアップ方法と 障害時の基本的なリカバリ方法につい て説明します 1. メディア リカバリ概要 2. ファイルの多重化 3. アーカイブ モードの設定 4. バックアップ概要 5. 一貫性バックアップ ( オ

第 3 章 メディア障害とバックアップ リカバリ この章では メディア障害の発生に備えたバックアップ方法と 障害時の基本的なリカバリ方法につい て説明します 1. メディア リカバリ概要 2. ファイルの多重化 3. アーカイブ モードの設定 4. バックアップ概要 5. 一貫性バックアップ ( オ はじめに コース概要と目的 データベースのバックアップの取得方法 障害発生時のリカバリ方法について習得します 受講対象者 データベース管理者の方 前提条件 データベース アーキテクチャ および データベース マネジメント コースを受講された方 または 同等の知識をお持ちの方 テキスト内の記述について 構文 [ ] 省略可能 { A B } A または B のどちらかを選択 n _ 数値の指定 デフォルト値

More information

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション Oracle Database Technology Night 集え オラクルの力 チカラ Technical Discussion Night - オラクル コンサルが語る SQL性能を最大限に引き出す DB 12c クエリー オプティマイザ 新機能活用 と 統計情報運用の戦略 日本オラクル株式会社 コンサルティングサービス事業統括 クラウド テクノロジーコンサルティング事業本部 プリンシパルコンサルタント

More information

Oracle Tuning Pack

Oracle Tuning Pack feature overview Oracle Tuning Pack Release 2 (9.2.0) Oracle Tuning Pack は データベース分析とチューニングを自動化する機能を提供する Oracle Enterprise Manager と統合されたアプリケーションのセットです Oracle Tuning Pack は データベース インスタンス設定 索引 SQL および領域使用をチューニングすることにより

More information

How to Use the PowerPoint Template

How to Use the PowerPoint Template 運用ヘルスチェックでトラブルを予防しよう! 今西由人スタッフコンサルタント クラウド テクノロジーコンサルティング統括本部テクニカルアーキテクト本部 DB ソリューション部 2 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント

More information

Oracle Solaris 仮想環境とプロビジョン環境の構築

Oracle Solaris 仮想環境とプロビジョン環境の構築 1 Oracle Solaris 仮想化環境と OS プロビジョニング環境の構築 日本オラクル株式会社プロダクト & パートナーソリューション本部シニア セールス コンサルタント黒田俊介 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント

More information

Oracle Database 12c Release 1 ( ) CoreTech Seminar

Oracle Database 12c Release 1 ( ) CoreTech Seminar 免責事項 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます

More information

How to Use the PowerPoint Template

How to Use the PowerPoint Template Customer Success Stories 2017 クラウド時代のアイデンティティ アクセス管理 - Oracle Identity Cloud Service のご紹介と導入のアプローチ - 日本オラクル株式会社クラウド テクノロジー事業統括 Fusion Middleware 事業本部 プリンシパル セールスコンサルタント井坂源樹 Copyright Copyright 2014 Oracle

More information

Make the Future Java FY13 PPT Template

Make the Future Java FY13 PPT Template Yoshio Terada Java Evangelist http://yoshio3.com, Twitter : @yoshioterada 1 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため

More information

PowerPoint Presentation

PowerPoint Presentation 1 SQL Plan Management(SPM) 導入事例 ~ オラクル コンサルの現場から ~ 日本オラクル株式会社テクノロジーソリューションコンサルティング統括本部テクニカルアーキテクト本部 DB コアコンサルティング部プリンシパルコンサルタント鈴木健吾 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません

More information

セットアップカード

セットアップカード NEC COBOL SQL アクセス Client Runtime Ver1.0 COBOL SQL アクセス Client Runtime Ver1.0 (1 年間保守付 ) COBOL SQL アクセス Client Runtime Ver1.0 (1 年間時間延長保守付 ) セットアップカード ごあいさつ このたびは COBOL SQL アクセス Client Runtime Ver1.0 (

More information

Oracle Data Pumpのパラレル機能

Oracle Data Pumpのパラレル機能 Oracle Data Pump のパラレル機能 Carol Palmer オラクル社 Principal Product Manager はじめに Oracle Database 10g 上の Oracle Data Pump により 異なるデータベース間のデータとメタデータを高速で移動できます Data Pump の最も便利な機能の 1 つは エクスポート ジョブとインポート ジョブをパラレルに実行しパフォーマンスを高める機能です

More information

このドキュメントに記載されている情報 (URL 等のインターネット Web サイトに関する情報を含む ) は 将来予告なしに変更することがあります このドキュメントに記載された内容は情報提供のみを目的としており 明示または黙示に関わらず これらの情報についてマイクロソフトはいかなる責任も負わないもの

このドキュメントに記載されている情報 (URL 等のインターネット Web サイトに関する情報を含む ) は 将来予告なしに変更することがあります このドキュメントに記載された内容は情報提供のみを目的としており 明示または黙示に関わらず これらの情報についてマイクロソフトはいかなる責任も負わないもの 2 - SQL の最適化 このドキュメントに記載されている情報 (URL 等のインターネット Web サイトに関する情報を含む ) は 将来予告なしに変更することがあります このドキュメントに記載された内容は情報提供のみを目的としており 明示または黙示に関わらず これらの情報についてマイクロソフトはいかなる責任も負わないものとします お客様が本製品を運用した結果の影響については お客様が負うものとします

More information

データベース暗号化ツール「D’Amo」性能検証

データベース暗号化ツール「D’Amo」性能検証 平成 29 年 5 月 31 日 株式会社東和コンピュータマネジメント 概要 測定環境 測定要件 テーブル構成 測定手順 測定結果 システムログ 統計レポート 考察 感想 データベース暗号化ツール D Amo の導入を検討するにあたり NEC 製サーバ Express 上におけるツール適用後の動作確認ならびに処理性能の増加傾向を把握する目的で 本性能測定を実施する 測定環境 ハードウェア,OS, データベース

More information

目次 はじめに... 2 無料トライアルのサインアップ方法... 3 トライアル環境へのアクセス 参考情報

目次 はじめに... 2 無料トライアルのサインアップ方法... 3 トライアル環境へのアクセス 参考情報 2018 年 11 月 日本オラクル株式会社 目次 はじめに... 2 無料トライアルのサインアップ方法... 3 トライアル環境へのアクセス... 11 参考情報... 14 1 はじめに このガイドは Oracle Cloud の無料トライアルを利用登録 ( サインアップ ) するための手順書です 本お申込みでご利用いただけるサービスについては 以下サイトの [ ご利用可能な Oracle サービス

More information

How to Use the PowerPoint Template

How to Use the PowerPoint Template ORACLE MASTER Bronze Oracle Database 12c 試験対策ポイント解説セミナー Bronze DBA 12c 編 日本オラクル株式会社オラクルユニバーシティ 2018 年 6 月 Safe Harbor Statement The following is intended to outline our general product direction. It is

More information

DBA & Developer Day 2016 ダウンロード資料

DBA & Developer Day 2016 ダウンロード資料 - オラクル コンサルが語る!- SQL 性能を最大限に引き出す DB 12c クエリー オプティマイザ新機能活用と統計情報運用の戦略 日本オラクル株式会社 コンサルティングサービス事業統括クラウド テクノロジーコンサルティング事業本部 プリンシパルコンサルタント畔勝洋平 プリンシパルコンサルタント柴田歩 Copyright 2016, Oracle and/or its affiliates. All

More information

スライド 1

スライド 1 Zabbix のデータベース ベンチマークレポート PostgreSQL vs MySQL Yoshiharu Mori SRA OSS Inc. Japan Agenda はじめに Simple test 大量のアイテムを設定 Partitioning test パーティションイングを利用して計測 Copyright 2013 SRA OSS, Inc. Japan All rights reserved.

More information

Microsoft PowerPoint - FormsUpgrade_Tune.ppt

Microsoft PowerPoint - FormsUpgrade_Tune.ppt Forms アップグレードに関する追加作業 - 工数見積もり サイジング チューニング - 必要な追加作業 工数見積もり サイジング チューニング 2 1 C/S Web 工数見積もり 工数見積もりの際に考慮すべき事項 アップグレードによる一般的なコード修正 テスト工数 C/S では使用できるが Web では廃止された機能に対する対策 USER_EXIT を使って Windows 上 DLL のファンクションをコールしている

More information

MaxGauge_診断分析プロセス

MaxGauge_診断分析プロセス Easy Use -1- MaxGauge 診断 / 分析プロセス Easy Use -2- システム性能低下認識 システムレベル分析 : トレンド アラート等 診断 / 分析対象の時間帯を特定 トップダウンアプローチ 概要分析 : アクティブセッション / 滞留 /CPU 詳細領域分析 :I/O メモリー ロック 上位 ロック 上位 SQL... セッション診断 / 分析 SQL 診断 / 分析

More information

第 1 章 条件分岐 この章では 条件に応じて処理を分岐する方法について説明します 1. CASE 式で複雑な条件分岐を実現 2. 関数を使用した条件分岐 3. MERGE 文による条件に応じた DML の実行

第 1 章 条件分岐 この章では 条件に応じて処理を分岐する方法について説明します 1. CASE 式で複雑な条件分岐を実現 2. 関数を使用した条件分岐 3. MERGE 文による条件に応じた DML の実行 はじめに コース概要と目的 SQL での作業の幅を広げるための応用的なテクニックをご説明します また 効率性の向上や正しい結果を得 るための記述方法など 実践的な記述方法についても併せてご説明します 本コースは SQL の応用的な記述テクニックとしてどのようなものがあるかを 1 日で広く浅くご理解いた だくことを目的としたコースです 細かな構文やオプションの習得は目的としておりませんことをご了承 ください

More information

Oracle Real Application Clusters 10g: 第4世代

Oracle Real Application Clusters 10g: 第4世代 Oracle Real Application Clusters 10g: Angelo Pruscino, Oracle Gordon Smith, Oracle Oracle Real Application Clusters RAC 10g Oracle RAC 10g Oracle Database 10g Oracle RAC 10g 4 Oracle Database 10g Oracle

More information

第 3 章代表的なチューニングポイント 3 Q. ストアド プロシージャを使用した SQL 共有率の向上 A. ストアド プロシージャを使用した場合 同じストアド プロシージャを実行する複数のユーザーが 同じ共有 PL/SQL 領域を使用します また ストアド プロシージャは解析済みで格納されている

第 3 章代表的なチューニングポイント 3 Q. ストアド プロシージャを使用した SQL 共有率の向上 A. ストアド プロシージャを使用した場合 同じストアド プロシージャを実行する複数のユーザーが 同じ共有 PL/SQL 領域を使用します また ストアド プロシージャは解析済みで格納されている Oracle パフォーマンスチューニング ~ 研修受講後のスキルアップサポート ~ 対応バージョン :Oracle 10gR1 ~ 12cR1 本資料は アシスト Oracle 研修をご受講いただいたお客様からのご質問や 研修ではご案内できなかった情報などを FAQ にまとめたものです 研修受講後のスキルアップの一助として 是非お役立てください ご利用上の注意事項は最後のページにまとめられております

More information

Microsoft PowerPoint - J-S301167_idx_comp.ppt [互換モード]

Microsoft PowerPoint - J-S301167_idx_comp.ppt [互換モード] SAP R/3 および SAP BW システムに対応する索引圧縮 Jan Klokkers SAP Development Server Technologies 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約

More information

Title Slide with Picture

Title Slide with Picture 意外と知らない!? オラクル ライセンス見積 ABC -Oracle Database 編 - 本資料は 2016 年 10 月 3 日時点の情報として有効です 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 )

More information

はじめに コース概要と目的 Oracle を使用した開発 管理を行う上でのファースト ステップとして リレーショナル データベース管理ソフトウェアである Oracle の役割 基本機能 基本アーキテクチャを幅広く理解することを目的としています 受講対象者 これから Oracle を使用する方 データ

はじめに コース概要と目的 Oracle を使用した開発 管理を行う上でのファースト ステップとして リレーショナル データベース管理ソフトウェアである Oracle の役割 基本機能 基本アーキテクチャを幅広く理解することを目的としています 受講対象者 これから Oracle を使用する方 データ はじめに コース概要と目的 Oracle を使用した開発 管理を行う上でのファースト ステップとして リレーショナル データベース管理ソフトウェアである Oracle の役割 基本機能 基本アーキテクチャを幅広く理解することを目的としています 受講対象者 これから Oracle を使用する方 データベース入門者の方 前提条件 コンピュータの基本操作 ( マウス操作やキーボード操作 ) と基本用語 (

More information

Oracle Database 11gのSQL Plan Management

Oracle Database 11gのSQL Plan Management Oracle Database 11g の SQL Plan Management Oracle ホワイト ペーパー 2007 年 6 月 注 : 本書は オラクルの一般的な製品の方向性を示すことが目的です また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 下記の事項は マテリアルやコード 機能の提供を確約するものではなく また 購買を決定する際の判断材料とはなりえません

More information

Oracle Enterprise Manager 10g R2 Grid Control: データベース管理の新機能

Oracle Enterprise Manager 10g R2 Grid Control: データベース管理の新機能 Oracle Enterprise Manager 10g R2 Grid Control: 2005 8 Oracle Enterprise Manager 10g R2 Grid Control:... 3... 3 GRID CONTROL... 4... 4... 4... 5... 5 GRID CONTROL... 5... 5 SQL /... 6... 7 HANG ANLYSIS...

More information

ソフト活用事例③自動Rawデータ管理システム

ソフト活用事例③自動Rawデータ管理システム ソフト活用事例 3 自動 Raw データ管理システム ACD/Labs NMR 無料講習会 & セミナー 2014 於 )2014.7.29 東京 /2014.7.31 大阪 富士通株式会社テクニカルコンピューティング ソリューション事業本部 HPC アプリケーション統括部 ACD/Spectrus をご選択頂いた理由 (NMR 領域 ) パワフルな解 析機能 ベンダーニュートラルな解析環境 直感的なインターフェース

More information

以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらな

以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらな 第 2 回データベース セキュリティ コンソーシアムセミナー < 写真欄 > 内部統制時代のデータベース セキュリティ 日本オラクル株式会社システム製品統括本部北野晴人 2006 年 11 月 7 日 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント

More information

PowerPoint Presentation

PowerPoint Presentation オラクル コンサルが語る! SQL 実行性能の安定化方式 日本オラクル株式会社テクノロジーコンサルティング統括本部テクニカルアーキテクト本部 DB コアテクノロジー部プリンシパルコンサルタント鈴木健吾 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント

More information

はじめに コースの概要と目的条件分岐の方法や複雑な集計の手法など SQL のコーディングの幅を広げるためのテクニックについて説明します また パフォーマンスを考慮した記述方法や正しい結果を取得するための記述方法などについても あわせて説明します 本コースでは 実践的な SQL の記述手法を広く浅く紹

はじめに コースの概要と目的条件分岐の方法や複雑な集計の手法など SQL のコーディングの幅を広げるためのテクニックについて説明します また パフォーマンスを考慮した記述方法や正しい結果を取得するための記述方法などについても あわせて説明します 本コースでは 実践的な SQL の記述手法を広く浅く紹 はじめに コースの概要と目的条件分岐の方法や複雑な集計の手法など SQL のコーディングの幅を広げるためのテクニックについて説明します また パフォーマンスを考慮した記述方法や正しい結果を取得するための記述方法などについても あわせて説明します 本コースでは 実践的な SQL の記述手法を広く浅く紹介することを目的としているため 細かな構文やオプションの習得を目的とはしていないことを 予めご了承ください

More information

Oracle DatabaseとIPv6 Statement of Direction

Oracle DatabaseとIPv6 Statement of Direction Oracle ホワイト ペーパー 2011 年 2 月 Oracle Database と IPv6 Statement of Direction 免責事項 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能の提供をコミットメント ( 確約 ) するものではなく

More information

COBOL Standard Edition COBOL SQL アクセスのご紹介 2017 年 3 本電気株式会社 次 COBOL SQLアクセスとは P.4 COBOL85 SQLEXTENSIONからの移 P.10 製品情報 P.13 COBOL SQL アクセスとは 製品概要 COBOL ソース中の埋め込み SQL によるデータベースアクセスが可能に 業界標準 ODBC(Open DataBase

More information

Oracle Database 11g Oracle Real Application Testing

Oracle Database 11g Oracle Real Application Testing Oracle Database 11g Real Application Testing 1 2 Oracle Real Application Testing 価値 テクノロジの迅速な導入 テスト品質の向上 ビジネス上の利点 低コスト 低リスク テスト 変更 修正 配置 機動的なビジネスのためのソリューション 3 Database Replay 4 Database Replay の必要性 ビジネスに相応しい価値を付加する新しいテクノロジの導入

More information

目次 1 集計関数 / 分析関数とは 2 集計関数 / 分析関数のパフォーマンス効果 3 ケーススタディグループ小計やクロス集計を計算するランキングを表示する前月比較を表示する累計を計算する移動平均を計算する構成比を計算する Oracle8i SQL Oracle8i Oracle Oracle C

目次 1 集計関数 / 分析関数とは 2 集計関数 / 分析関数のパフォーマンス効果 3 ケーススタディグループ小計やクロス集計を計算するランキングを表示する前月比較を表示する累計を計算する移動平均を計算する構成比を計算する Oracle8i SQL Oracle8i Oracle Oracle C Oracle8i データウェアハウス機能活用法 ~ レポーティングに有効な集計関数 分析関数 ~ Creation Date: Oct. 11, 2000 Last Update: Oct. 11, 2000 Version: 1.0!! DWH etc Business Intelligence Oracle8i RDBMS DWH Oracle8i Oracle Corporation Japan

More information

Oracle DatabaseとIPv6 Statement of Direction

Oracle DatabaseとIPv6 Statement of Direction Oracle ホワイト ペーパー 2017 年 10 月 Oracle Database と IPv6 Statement of Direction 免責事項 下記事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません マテリアルやコード 機能の提供をコミットメント ( 確約 ) するものではなく 購買を決定する際の判断材料になさらないで下さい

More information

NEC COBOL SQL アクセス Server Runtime V1.0 COBOL SQL アクセス Server Runtime V1.0 (1 年間保守付 ) COBOL SQL アクセス Server Runtime V1.0 (1 年間時間延長保守付 ) セットアップカード SL438

NEC COBOL SQL アクセス Server Runtime V1.0 COBOL SQL アクセス Server Runtime V1.0 (1 年間保守付 ) COBOL SQL アクセス Server Runtime V1.0 (1 年間時間延長保守付 ) セットアップカード SL438 NEC COBOL SQL アクセス Server Runtime V1.0 COBOL SQL アクセス Server Runtime V1.0 (1 年間保守付 ) COBOL SQL アクセス Server Runtime V1.0 (1 年間時間延長保守付 ) セットアップカード SL438730U01-1 ごあいさつ このたびは COBOL SQL アクセス Server Runtime

More information

Oracle Direct Seminar <Insert Picture Here> 試験対策ポイント解説 Bronze DBA11g 日本オラクル株式会社

Oracle Direct Seminar <Insert Picture Here> 試験対策ポイント解説 Bronze DBA11g 日本オラクル株式会社 Oracle Direct Seminar 試験対策ポイント解説 Bronze DBA11g 日本オラクル株式会社 アジェンダ ORACLE MASTER Oracle Database 11g 概要 Bronze DBA 11g 試験紹介 ポイント解説 Copyright 2011 Oracle All rights reserved. 2 資格体系 実務エキスパートの認定

More information

Oracle Application Expressの機能の最大活用-インタラクティブ・レポート

Oracle Application Expressの機能の最大活用-インタラクティブ・レポート Oracle Application Express 4.0 を使用した データベース アプリケーションへのセキュリティの追加 Copyright(c) 2011, Oracle. All rights reserved. Copyright(c) 2011, Oracle. All rights reserved. 2 / 30 Oracle Application Express 4.0 を使用した

More information

Oracle Direct 無償支援サービス ヒアリング・シート利用手順

Oracle Direct 無償支援サービス ヒアリング・シート利用手順 パフォーマンス クリニック サービス パフォーマンス診断ツール の使い方 日本オラクル株式会社 Copyright 2016, Oracle and/or its affiliates. All rights reserved. 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は

More information

変更履歴 項番版数内容更新日 版新規作成 2013 年 11 月 18 日

変更履歴 項番版数内容更新日 版新規作成 2013 年 11 月 18 日 Windows Server 2012 R2 機能評価レポート Windows Server 2012 R2 Hyper-V 動的メモリ強化のポイントと構成時の留意点 第 1. 0 版 2013 年 11 月 18 日 株式会社日立製作所 IT プラットフォーム事業本部 変更履歴 項番版数内容更新日 1 1.0 版新規作成 2013 年 11 月 18 日 目次 1. はじめに... 1 2. Windows

More information

PowerPoint Presentation

PowerPoint Presentation 1 データベースの症状からアプリの問題点を見つけるパフォーマンス ドクター 日本オラクル株式会社テクノロジー製品事業統括本部ソリューション本部基盤技術部プリンシパルエンジニア柴田竜典 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント

More information

Null

Null Oracle Database Connect 2017 ~ 最新のデータベース技術がここにある ~ エキスパートはどう考えるか? 体感! パフォーマンスチューニング Japan Oracle User Group 日本オラクル株式会社クラウド テクノロジー事業統括 Database & Exadata プロダクトマネジメント本部 Copyright 2017, Oracle and/or its

More information

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション 部内向けスキルアップ研修 組込み OS 自作入門 2014 年 2 月 10st ステップ担当 : 中村 目次 はじめに OSの役割 メモリ管理 メモリ管理実装 プログラムの実行 まとめ はじめに 前回やったこと OS の原型を作成 今回やること 9th ステップでは CPU 時間 という資源管理 本ステップでは メモリ という資源管理 10.1 OS の役割 10.1.1 コンピュータの 3 大要素

More information

第 2 章 PL/SQL の基本記述 この章では PL/SQL プログラムの基本的な記述方法について説明します 1. 宣言部 2. 実行部 3. 例外処理部

第 2 章 PL/SQL の基本記述 この章では PL/SQL プログラムの基本的な記述方法について説明します 1. 宣言部 2. 実行部 3. 例外処理部 はじめに コース概要と目的 Oracle 独自の手続き型言語である PL/SQL について説明します PL/SQL の基本構文 ストアド サブプログラム トリガーの作成方法 またストアド サブプログラムの管理について習得することを目的としています 受講対象者 これから PL/SQL を使用してアプリケーション開発をされる方 前提条件 SQL トレーニング コースを受講された方 もしくは 同等の知識をお持ちの方

More information

Oracle Data Pumpのパラレル機能

Oracle Data Pumpのパラレル機能 Oracle ホワイト ペーパー 2009 年 2 月 Oracle Data Pump のパラレル機能 はじめに Oracle Database 10gから使用できるようになったOracle Data Pumpは データベース間でのデータおよびメタデータの高速移動を実現します Data Pumpが提供するもっとも実用的な機能の1つに エクスポート ジョブとインポート ジョブのパフォーマンスの最大化を目的としたパラレル化機能があります

More information

Microsoft Word - nvsi_050090jp_oracle10g_vlm.doc

Microsoft Word - nvsi_050090jp_oracle10g_vlm.doc Article ID: NVSI-050090JP Created: 2005/04/20 Revised: Oracle Database10g VLM 環境での NetVault 動作検証 1. 検証目的 Linux 上で稼動する Oracle Database10g を大容量メモリ搭載環境で動作させる場合 VLM に対応したシステム設定を行います その環境において NetVault を使用し

More information

津島博士のパフォーマンス講座

津島博士のパフォーマンス講座 Oracle Database Technology Night 津島博士のパフォーマンス講座 SQL パフォーマンスの基礎 日本オラクル株式会社ソリューション エンジニアリング統括クラウド インフラストラクチャー本部津島浩樹 2019/01/23 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません

More information

Oracle Un お問合せ : Oracle Data Integrator 11g: データ統合設定と管理 期間 ( 標準日数 ):5 コースの概要 Oracle Data Integratorは すべてのデータ統合要件 ( 大量の高パフォーマンス バッチ ローブンの統合プロセスおよ

Oracle Un お問合せ : Oracle Data Integrator 11g: データ統合設定と管理 期間 ( 標準日数 ):5 コースの概要 Oracle Data Integratorは すべてのデータ統合要件 ( 大量の高パフォーマンス バッチ ローブンの統合プロセスおよ Oracle Un お問合せ : 0120- Oracle Data Integrator 11g: データ統合設定と管理 期間 ( 標準日数 ):5 コースの概要 Oracle Data Integratorは すべてのデータ統合要件 ( 大量の高パフォーマンス バッチ ローブンの統合プロセスおよびSOA 対応データ サービスへ ) を網羅する総合的なデータ統合プラットフォームです Oracle

More information

2. 設定画面から 下記の項目について入力を行って下さい Report Type - 閲覧したい利用統計の種類を選択 Database Usage Report: ご契約データベース毎の利用統計 Interface Usage Report: 使用しているインターフェイス * 毎の利用統計 * 専用

2. 設定画面から 下記の項目について入力を行って下さい Report Type - 閲覧したい利用統計の種類を選択 Database Usage Report: ご契約データベース毎の利用統計 Interface Usage Report: 使用しているインターフェイス * 毎の利用統計 * 専用 EBSCOadmin 利用統計設定方法 EBSCOadmin 内の Report & Statistics 機能をご利用頂くことで セッション別 発信元の IP アドレス別 デー タベース別 最も多く検索された雑誌タイトルなどに限定して ユーザーのデータベース利用頻度を把握すること ができます ここでは 基本的なデータベースの利用統計レポートの作成方法をご説明します 利用統計を設定する (=Standard

More information

Title Slide with Picture

Title Slide with Picture 意外と知らない!? オラクル ライセンス見積 ABC -Oracle Database 編 - 本資料は 2018 年 6 月 1 日時点の情報として有効です 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 )

More information

以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらな

以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらな 20 分で理解する Oracle GoldenGate 日本オラクル株式会社 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい

More information

Oracle Business Rules

Oracle Business Rules Oracle Business Rules Manoj Das(manoj.das@oracle.com) Product Management, Oracle Integration 3 Oracle Business Rules について Oracle Business Rules とはビジネスの重要な決定と方針 ビジネスの方針 実行方針 承認基盤など 制約 有効な設定 規制要件など 計算 割引

More information

Oracle8簡単チューニング for Windows NT

Oracle8簡単チューニング for Windows NT Oracle8 ... 2 0.... 3 1.WINDOWS NT... 4 1.1.CPU...4 1.2....8 W INDOWS NT...9 2.ORACLE... 10 2.1.SHARED_POOL_SIZE...10 2.2.DB_BLOCK_BUFFERS...11 2.3.SORT_AREA_SIZE...14 2.4.DB_FILE_MULTIBLOCK_READ_COUNT...15

More information

proventia_site_protector_sp8_sysreq

proventia_site_protector_sp8_sysreq SiteProtector 2.0 Service Pack 8.x システム要件 2010 年 7 月 26 日 SiteProtector 2.0 Service Pack 8.x システム要件... 1 Service Pack 8.1 - SiteProtector システム要件... 1 Service Pack 8.1 仮想環境... 1 Service Pack 8.1 - Express

More information

リアルタイムSQL監視

リアルタイムSQL監視 2009 年 12 月 はじめに Oracle Database 11g で導入されたは リソース消費量が多く長時間実行される SQL 文やパラレル SQL 文で発生するランタイム パフォーマンスの問題を極めて効果的に特定する手段です Oracle Enterprise Manager(Oracle EM) のインタラクティブな画面に SQL 実行の詳細が表示されますが この情報を取得するのに使用されるのが

More information

意外と簡単!?Oracle Database 10g Release2 - データベース構築から運用まで - データベースの運用 - チューニング編 (Windows 版 ) Creation Date: Nov 2, 2005 Last Update: Nov 2, 2005 Version: 1

意外と簡単!?Oracle Database 10g Release2 - データベース構築から運用まで - データベースの運用 - チューニング編 (Windows 版 ) Creation Date: Nov 2, 2005 Last Update: Nov 2, 2005 Version: 1 意外と簡単!?Oracle Database 10g Release2 - データベース構築から運用まで - (Windows 版 ) Creation Date: Nov 2, 2005 Last Update: Nov 2, 2005 Version: 1.0 はじめに 意外と簡単!? シリーズは Oracle Database 10g を使用してこれからシステム構築を行い 運用していく方向けに作成しており

More information

Oracle Cloud Adapter for Oracle RightNow Cloud Service

Oracle Cloud Adapter for Oracle RightNow Cloud Service Oracle Cloud Adapter for Oracle RightNow Cloud Service Oracle Cloud Adapter for Oracle RightNow Cloud Service を使用すると RightNow Cloud Service をシームレスに接続および統合できるため Service Cloud プラットフォームを拡張して信頼性のある優れたカスタマ

More information

Silk Central Connect 15.5 リリースノート

Silk Central Connect 15.5 リリースノート Silk Central Connect 15.5 リリースノート Micro Focus 575 Anton Blvd., Suite 510 Costa Mesa, CA 92626 Copyright Micro Focus 2014. All rights reserved. Silk Central Connect は Borland Software Corporation に由来する成果物を含んでいます,

More information

IBM Cloud Social Visual Guidelines

IBM Cloud  Social Visual Guidelines IBM Business Process Manager 連載 : 事例に学ぶパフォーマンスの向上 第 4 回 SPARK UI Toolkit 活用による画面描画の高速化 概要 第 3 回画面描画の高速化 では CoachView の数に起因するパフォーマンス問題について その原因と改善策を解説しました 本ドキュメントでは SPARK UI Toolkit を用いて CoachView の描画コストを削減する具体的な実装アプローチについて説明します

More information

Microsoft Word - MOPatch-1.doc

Microsoft Word - MOPatch-1.doc Oracle for SAP MOPatch 利用マニュアル 2007 年 12 月 5 日日本オラクル株式会社 SAP サポート チーム Ver1.1-1 - MOPatch とは... 3 前提条件... 3 MOPatch の入手方法... 3 MOPatch dry-run モードでの実行... 4 MOPatch の実行... 5-2 - MOPatch とは MOPatch は Multiple

More information

組込み Linux の起動高速化 株式会社富士通コンピュータテクノロジーズ 亀山英司 1218ka01 Copyright 2013 FUJITSU COMPUTER TECHNOLOGIES LIMITED

組込み Linux の起動高速化 株式会社富士通コンピュータテクノロジーズ 亀山英司 1218ka01 Copyright 2013 FUJITSU COMPUTER TECHNOLOGIES LIMITED 組込み Linux の起動高速化 株式会社富士通コンピュータテクノロジーズ 亀山英司 1218ka01 組込み Linux における起動高速化 組込み Linux の起動時間短縮について依頼あり スペック CPU : Cortex-A9 ( 800MB - single) RAM: 500MB 程度 要件 起動時間 画出し 5 秒 音出し 3 秒 終了時間 数 ms で電源断 1 課題と対策 問題点

More information

Slide 1

Slide 1 Oracle Direct Seminar もうアプリ改修は必要ない! これからの SQL チューニング 日本オラクル株式会社 Agenda 従来の SQL チューニング 一般的なチューニングの流れ 一般的なチューニング ポイント 画期的な SQL チューニング SQL チューニング アドバイザ SQL プロファイル チューニング実施手順 11g 新機能

More information

Oracle TimesTenについて

Oracle TimesTenについて Oracle TimesTen Success 2012 東京エレクトロンデバイス ( 株 ) CN 事業統括本部 CN プロダクト事業部ミドルウェア コンサルティング グループ TimesTen 製品と東京エレクトロンデバイス TimesTen-TED の歴史 東京エレクトロン24X7 サポート開始 2002 東京エレクトロン日本国内販売開始 2001 初の商用インメモリDBリリース 1998 TimesTen

More information

標準化 補足資料

標準化 補足資料 高度専門データベース技術 SQL99 補足資料 ( 株 ) アイテック情報技術教育研究部 2012 年 2 月 14 日 ( はじめに ) この補足資料は,SQL99(ISO/IEC9075-2,JIS X3005-2) の必須機能 (Core SQL) のうち, SQL92に対し機能拡張が行われた部分で, 高度専門データベース技術 ( 以下, DB 技術 という ) に記載のないものについて記述する

More information

OWI(Oracle Wait Interface)の概要

OWI(Oracle Wait Interface)の概要 日本エクセム株式会社 1 目次 OWI とは? OWI ベース診断 / 分析 Oracle アーキテクチャーと OWI OWI の構成要素 システム性能管理の必要性 2 QUIZ 以下はある期間の STATSPACK レポートの一部です データベース処理で遅延が発生しているでしょうか 性能低下現象が発生している場合 どのように診断 / 分析を行い どのような改善ポイントを提案すべきでしょうか 3 プロセスの状態と

More information

Microsoft Word - nvsi_050110jp_netvault_vtl_on_dothill_sannetII.doc

Microsoft Word - nvsi_050110jp_netvault_vtl_on_dothill_sannetII.doc Article ID: NVSI-050110JP Created: 2005/10/19 Revised: - NetVault 仮想テープ ライブラリのパフォーマンス検証 : dothill SANnetⅡSATA 編 1. 検証の目的 ドットヒルシステムズ株式会社の SANnetll SATA は 安価な SATA ドライブを使用した大容量ストレージで ディスクへのバックアップを行う際の対象デバイスとして最適と言えます

More information