ベースラインによる監視
EM 「ベースライン・メトリックしきい値」ページで「クイック構成」
–
変動ベースラインによるメトリックしきい値–
ワークロード・プロファイルによって設定（設定されるメトリックが決まる）
主としてOLTP（トランザクション処理の未、24時間）
主としてデータ・ウェアハウス（問合せとロード集中型）
代替（日中はOLTP
、夜間はバッチ）–
ベースラインの時間ごとにしきい値が設定される
しきい値タイプ、クリティカルのしきい値、警告のしきい値適応メトリックしきい値の設定
ベースラインによる監視
最大パーセント
–
ベースラインのデータの最大値に対する割合（100%,120%
までOK
）–
ピーク・ワークロード用 重大レベル
–
ベースラインのデータを超える値に対する百分位数–
高い：.95
（100回に5回までOK）、非常に高い：.99
、重度：.999
、極度：.9999
適応メトリックしきい値のタイプ
ベースラインによる監視
メトリックの「しきい値の編集」ページで行う
–
ベースラインを指定してメトリックごとにしきい値を編集する
変動ベースラインまたは固定ベースライン–
固定ベースラインはしきい値統計の計算が必要–
指定したベースラインの時間ごとのしきい値を表示
しきい値タイプ、クリティカルのしきい値、警告しきい値 しきい値のないメトリックについては
–
「基本メトリック」又は「基本および追加メトリック」を使用する適応メトリックしきい値の編集
実行計画（オプティマイザ）
実行計画（オプティマイザ）
最適な実行計画を作成してくれるのか
– SQL
の書き方を気にしなくて良いのか（問合せの変換が動作します） 実行計画を変化させたくない
–
なぜ（どのようなときに）変化するのか分かりますか オプティマイザ統計収集に時間が掛る
–
あまり収集できない（効率的な収集を行っていますか） オプティマイザ統計の運用をどうするのか
–
自動オプティマイザ統計収集を知っていますかCBO についての疑問点
実行計画（オプティマイザ）
論理的に等しく効率的な SQL に変換する（代表的なものとして）
–
副問合せありに変換（件数を削減してから結合する）–
ビューのマージ（ビューを副問合せとして処理せずに）–
述語のプッシュ（副問合せ結果件数を削減するため） select * from (select * from tab1 where …) where c1 = ‘x’
↓
select * from (select * from tab1 where c1 = ‘x’ and …)
– OR拡張（ORをUNION ALLに変換することで索引を使用する）
実行計画は読めるようになりましょう
オプティマイザ機能（問合せの変換）
実行計画（オプティマイザ）
オプティマイザ統計
–
大きく変化すれば（サンプル・サイズが少ないと効果が低下する場合がある） 初期化パラメータ OPTIMIZER_MODE
– all_rows（デフォルト）, first_rows_n（より索引を使用させたい）, first_rows
–
統計情報が正確でない（行数が正しく見積もれない）とき以外は変えない ダイナミック・サンプリング
–
動的にオプティマイザ統計を取得する（デフォルトは2
：統計情報がないと行う） カーディナリティ・フィードバック
–
実際のカーディナリティが統計情報と異なっている場合にオプティマイザ機能（実行計画に影響）
実行計画（オプティマイザ）
子カーソル（同じ SQL で複数の実行計画ができる）
–
同じSQL
でもベストな実行計画が異なるため
バインド変数（bind peek
、優れたカーソル共有、CURSOR_SHARING
）
スキーマが異なるなど–
共有メモリの消費が増える
子カーソル数の上限値に達すると無効化されるオプティマイザ機能（実行計画に影響）
実行計画（オプティマイザ）
オプティマイザ統計を収集するとき
–
自動オプティマイザ統計収集 22:00
から26:00
（土日は6:00
から26:00
）に自動実行する
独自の方式で収集している以外は使用する–
オプティマイザ統計の手動収集
必要な（大量に変更があった）ときを判断して実行するオプティマイザ統計管理
実行計画（オプティマイザ）
オプティマイザ統計収集の効率を向上させる
–
パラレル化（デフォルトはテーブルのDEGREE
句で行います） AUTO_DEGREE
を推奨（オブジェクト・サイズによってパラレル度が調整される） CONCURRENT（複数オブジェクトの統計収集を並列実行）
ドキュメント内
PowerPoint Presentation
(ページ 38-48)