事前準備としてDBMS_STATSを使用して手動でヒストグラムを収集しても、アプリケーションの走行前に自動統計が収集されると、「使用されていない列」としてヒストグラムが消されます。, 内部的に記録した行の更新状況や列の使用状況に基づいて一律に統計再収集を決定したり、ヒストグラム作成を決定したりしているため、再収集したものの統計的な変化がない場合があります。条件指定されたことのある列は、アプリケーションの変更によって使用されなくなったとしても、しばらくの間(6ヶ月)はヒストグラム作成の対象となります。, 安定性や予測可能性(所要時間やリソース消費量がいつも同じで、正確な見積もりが可能であること)を最大限重視する場合は、デフォルトの自動統計収集はオフにして、手動で収集 注18したほうが良いでしょう。その際、統計収集パラメータとして「自動設定」は使用せず、数値で指定可能なもの(サンプルサイズ/バケット数/パラレル度)は数値で指定することをお勧めします。また、オブジェクトごとに個別の収集パラメータを指定して、きめ細かな管理をしたい場合にも、自動統計収集をオフにした上で手動で収集してください。, >注18:各種統計収集パラメータ(サンプリング方法/サンプルサイズ/ヒストグラム対象列/パラレル度/パーティション表の扱い/SQLの無効化など)を適切に設定して、DBMS_STATSパッケージプロシージャをコールします。, ただし、このような手動収集で適切なパラメータ値を決定するためには、やはりテストを繰り返す必要があります。とはいえ、オンライン処理のレスポンスやバッチ処理の所要時間は厳密な管理をしていないのに、オプティマイザ統計収集のみ厳密な設定をするためにテストを繰り返す必要はないでしょう。システムの重要性に応じて判断してください。, 自動統計収集ではアプリケーションが実際に走行しないと必要なヒストグラムが作られません。これは、リグレッションツールなどを使用してシステムのカットオーバー前に網羅的にアプリケーションを走行させられない環境では問題かもしれません。その場合、必要なヒストグラムが分かっていれば手動で作成し、しばらく自動統計収集を止めた状態で運用し、アプリケーションのすべての機能が使用されたころを見計らって自動統計収集を開始するというアイディアもあります。, 最後に、自動統計収集が無駄に統計収集をしているかもしれないという点は、それが自動統計収集の本質であり、無駄であろうとも機械的に収集することで陳腐化するのを防ぐというアプローチであることを理解する必要があります。「無駄に収集しているかどうか」は人間の管理者の経験によってのみ判断できることです。データの統計的な変動がほとんどないことが分かっているシステムでは、自動統計収集を使用する必要はありません。適宜、手動で収集してください。, 自動統計収集では、いつ、どの表が統計収集されたか、サンプルサイズはどの程度であったか、どの列にヒストグラムが作成されたかを監視することをお勧めします。これらの情報は将来、手動収集に切り替える必要ができた場合の重要なインプットになります。また、統計収集の頻度があまりに低い表は、更新がほとんど発生していないことも考えられますが、表が大きすぎてウィンドウ内で完了していない可能性もあります。「GATHER_STATS_JOB」のところで記述したようにトレースファイルも確認して、強制中断されているオブジェクトがある場合はウィンドウの長さが妥当かどうかを検討してください。監視例をLIST6およびLIST7に示しておきます。, 自動統計収集はCBOに対する敷居を下げる優れた機能と言えます。しかし、統計収集によって行なわれる作業が「いつも同じである」という安定性を重視する場合や、統計収集の最適な頻度や対象オブジェクトが分かっているようなケース、オブジェクトレベルできめ細かな管理をしたい場合は手動統計収集をお勧めします。自動統計収集を利用する場合は、スケジューラウィンドウを適切に設定し、統計収集の実行状況を監視すると良いでしょう。, 「オプティマイザ統計を再収集したら、SQL実行計画が変化し、性能が劣化した」という経験がリスクとして認識され、定期的な統計が収集されていないケースがあります。この問題についてはCBOの本質として、最後に「CBOを使いこなすためには」の部分で考察しますが、このリスクはCBOで運用する上では避けられないものと言えます。 もう一点、動的サンプリングのメリットは、単一表の列同士に相関関係があるようなケースで、それを反映した選択率を導出できる点があります。例えば、EMP表のJOB列とSALARY列を考えてみましょう。「WHERE JOB='MANAGER'and SALARY>5000」という条件で問い合わせたとします。通常、オプティマイザはそれぞれの列に相関関係はなく、独立しているとみなすため、次のように選択率を計算します。, 例えば、Sel(JOB='MANAGER')が0.1で、Sel(SALARY>5000)が0.1だとしたら、オプティマイザはEMP表からの選択率は0.01(0.1×0.1)とみなします。 例えば、次の問い合わせが参照しているTEST2表には、統計情報が存在しないとします。, 動的サンプリングのために、以下のようなSELECT文が再帰コールとして発行されています。, SAMPLE BLOCK句でTEST2表に対する約73%のブロックサンプリングが指定されています。TEST2表は86ブロックの表であり、73.255814パーセントのサンプリングは63ブロック(≒64ブロック)に相当します。このサンプリングSQLを実行すると、次のような出力が得られます。, 7807行がサンプリングされ、ユーザーの問い合わせ条件である「COL2=10 AND COL3=10」にヒットした行は100行であったことが分かります。 オプティマイザ統計を収集する場合、データベースで内部プロシージャがコールされます。このプロシージャは、gather_database_statsプロシージャをgather autoオプションを指定して実行する場合と同様に動作します。自動統計収集はデータベース内のすべてのプリファレンス・セットに従います。 このほかに、索引の統計情報を取得するためのサンプリングSQLも実行されます。, 動的サンプリングは、例えば1秒未満の高速なレスポンスが要求されるシステムにおいては、無視できない処理オーバーヘッドです。また、短期間における大きなデータ変動のないシステムにおいては、事前に準備しておいた統計を使用したほうがよほど効率的です。, 動的サンプリングを行なう価値のある代表例としては、「一時表(Temporary Table)」に対するアクセスがあります。一時表にデータを一時的に置いておき、そのデータを使用して別の処理を行なうようなアプリケーションの場合、一連の処理が始まる前は一時表は空ですから、事前に統計収集しても意味がありません。このようなケースにおいて動的サンプリングは最適と言えます。 自動オプティマイザ統計収集 2. リストア前にTEST_STATTAB表に退避しておいた統計は、通常のexp/impでテストDBに移行し、ディクショナリに反映させます(LIST11)。, 次はテストDBにおいて、不適切な実行計画を引き起こしたと思われる統計の問題点を調査します。サンプルサイズが小さすぎないか、ヒストグラムのバケット数が変化していないかなどを確認します。場合によってはSQLチューニングやサポートセンターへの問い合わせが必要になるケースも考えられます。原因が究明され、対処法を実装したら統計情報のロックを解除し、定期的な統計収集の運用を再開します。, オプティマイザ統計の再収集によってSQL実行計画が変化し、性能が劣化する現象は、起き得ることとして運用を設計しておく必要があります。, 10gではデフォルトで統計履歴が自動保存されており、31日前までのどの時点にでも戻せます。統計再収集によって性能問題が発生した場合は、保存された統計をリストアすることによって以前の性能に戻して運用できます。この場合、単純に過去の統計に戻しただけでは、それ以降の統計収集でも同じ問題が再発する可能性があるため、テスト環境に問題の統計を移行して解析することをおすすめします。, Oracleでは事前に収集されたオプティマイザ統計ではなく、SQLの実行時(ハードパース時)に動的に統計情報をサンプリングし、その結果を元に実行計画の生成が可能です。このような統計収集のことを「動的サンプリング」と言います。, Oracle 10gではデフォルトで、事前に収集された統計情報が存在しない表に対してSQL文を発行したときは、64ブロックのブロックサンプリングが実行されます。 デフォルトでは、1時間ごとにパフォーマンス・データのスナップショットが自動的に生成され、その統計はawrに8日間保存されます。スナップショットの作成や、スナップショット保存期間の変更を手動で行うこともできますが、通常は必要ありません。 自動SQLチューニング・アドバイザ これらのタスクは、メンテナンス・ウィンドウ(メンテナンス可能として設定した時間帯)で実行され、リソース・コンシューマグループに割り当てられます。また、ウィンドウの期間中に使用されるリ … しかし、実際にはJOB='MANAGER'を満たすレコードがすべてSALARY>5000を満たしていたらどうでしょう(「マネージャの給料は高い」という相関関係です)。本当の選択率はSel(JOB='MANAGER')と同じになり、0.1です。 なお、動的サンプリングの使用法を決めるパラメータOPTIMZER_DYNAMIC_SAMPLINGはセッションレベルで変更可能(ALTER SESSION文)であり、SQLレベルで設定する場合には、DYNAMIC_SAMPLING(表名 n)ヒントを利用可能です(nはサンプリングレベル)。, Oracle 10gでは、統計収集されていない表に対するハードパース時には動的サンプリングが行なわれます。通常、高速なレスポンスが要求されるOLTPシステムでは、動的サンプリングはオーバーヘッドとなります。有効な用途としては一時表に対するアクセスがあります。DWH系のシステムでは相関関係のある列に対する選択率を適切に見積もるのに有効な場合があります。, 動的サンプリングの設定にはoptimizer_dynamic_samplingパラメータを用います。デフォルト値は2であり、本文で説明したような動作をします。値を0に設定すると、動的サンプリングはOFFになります。設定値を大きくすることにより、サンプリングされるブロック数を増やせます。なお9i R2ではデフォルト値は1であり、動的サンプリングが発生する条件は10gよりも厳しくなっています。.

白猫 エレノア 人気, 志望理由書 書き方 ルール, 風花 名前 由来, スズキ エブリイワゴン カタログ, Python 環境変数 存在チェック, 軽自動車 タイヤ 乗り心地, 京阪特急 二階建て 何両目, Bmx 24インチ 中古, ティファール フライパン 種類, ワンピース 97巻 遅い, 富士吉田 雪 何センチ, 七田 教材 買取, 洋服の青山 クーポン 延長, 鶏 香草 パン粉 焼き レシピ, Vscode Anaconda 仮想環境 デバッグ, 国際結婚 貧乏 離婚, Exeファイル 作り方 Python, ロールスクリーン シワ 消す, トヨタ ピクシス 内装, 大阪 フェス 食べ物, 蛍光灯 Led 工事不要, エブリイ ワゴン 彼氏, 鶏胸肉 もやし きゅうり, Tp-link 中継器 初期化, 賃貸 お風呂 リフォーム 交渉, Vba 最終列 取得 アルファベット, ブックオフ ぬいぐるみ 買取, 半角カナ 正規表現 Java,

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *