デフォルトでは、1時間ごとにパフォーマンス・データのスナップショットが自動的に生成され、その統計はawrに8日間保存されます。スナップショットの作成や、スナップショット保存期間の変更を手動で行うこともできますが、通常は必要ありません。 自動オプティマイザ統計収集 2. oracle 10gでは、データベースを作成するとデフォルトでgather_stats_jobと呼ばれる自動統計収集のためのスケジューラジョブが準備されます 注17。ジョブの定義はlist1のように確認できます。 list1 ジョブの定義 この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。, Oracleは米国Oracle Corporationの登録商標です。文中に参照されている各製品名及びサービス名は米国Oracle, Corporationの商標または登録商標です。その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります。, 1996年日本オラクル入社。人事教育本部にて、新卒や中途採用社員に対し、データベースやOS、ネットワークの講師を5年ほど経験した後、2000年にテクノロジーコンサルティング本部に異動。 テクノロジーのコンサルタントとして、主に大規模ミッションクリティカルシステムを担当。, ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。だから、OS、ストレージ、ネットワークを学ぶべき」。 スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。, 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。.

自動セグメント・アドバイザ 3. 反対に、自動統計収集のデメリットを挙げてみましょう。, 1回の統計収集の負荷、所要時間が予測できない統計収集のたびに、対象となる表の数やサンプルサイズ、作成するヒストグラムの数が異なる可能性があるため、ウィンドウのオープン時間が短いと必要な統計収集をすべて完了できないことがあります。, 必要なヒストグラムや統計の精度（サンプルサイズ）などを個別に指定できない 自動化メンテナンス・タスクとは、データベースのメンテナンス操作を一定間隔毎に自動的に行うタスクです。Oracle Database には、次の 3種類の自動化メンテナンス・タスクが事前に定義されています。 1. このほかに、索引の統計情報を取得するためのサンプリングSQLも実行されます。, 動的サンプリングは、例えば1秒未満の高速なレスポンスが要求されるシステムにおいては、無視できない処理オーバーヘッドです。また、短期間における大きなデータ変動のないシステムにおいては、事前に準備しておいた統計を使用したほうがよほど効率的です。, 動的サンプリングを行なう価値のある代表例としては、「一時表（Temporary Table）」に対するアクセスがあります。一時表にデータを一時的に置いておき、そのデータを使用して別の処理を行なうようなアプリケーションの場合、一連の処理が始まる前は一時表は空ですから、事前に統計収集しても意味がありません。このようなケースにおいて動的サンプリングは最適と言えます。 もちろんこの問題でトラブルに陥らないために、最低でも以下に注意しなければなりません。, 統計収集対象に「漏れ」がないこと（列に対するヒストグラムも含め、必要なオブジェクトが必要なレベルで統計収集されていること）, しかしながら、厳密に「適切な精度／頻度」とは何かというのは、経験によってしか分かりません。ある程度運用していて、問題が起こらない場合の精度／頻度が「適切」なわけです。そのため、適切な設定が分かるまでは「適切でない」設定での試行錯誤を繰り返すことになります。, また、たとえ統計が「適切」に収集されていたとしても、オプティマイザがコストとして評価するときの仮定が現実と異なっていれば、最適ではない実行計画が選択される可能性があります 注19。したがって、統計再収集によってSQL実行計画が変化し性能が劣化するという現象は、程度の違いはあるものの、起き得ることと考えて運用を設計しておくべきです。, これを念頭に置いた最も現実的な運用は、統計再収集の前に現在の統計情報のバックアップを取っておき、新しく収集した統計情報によって何らかのトラブルが発生した場合は、とりあえず以前の統計情報をリストアし、SQLの性能を以前の状態に戻すというものです。, 注19：オプティマイザの仮定を補正するいくつかの方法についてパート2で述べましたが、これも含めてソフトウェアとしてのオプティマイザの「限界」がある、と理解しても構いません。, 9iではこのような統計情報のバックアップをユーザーが管理する必要がありましたが、10gでは、オブジェクトの新しいオプティマイザ統計を収集すると、以前の統計を自動的に保存してくれます。これは履歴として管理され、デフォルトでは31日前までの履歴が保存されています（履歴情報はSYSAUX表領域内に格納されています）。履歴を保存しているため、以前の任意の時点の統計を、現在値としてディクショナリにリストア可能です。つまり、31日前までのどの時点にでも復元できます。, 統計履歴が自動保存されるのはDBMS_STATSパッケージを使用して統計収集した場合のみです。ANALYZEコマンドによって統計収集を行なった場合、統計履歴は自動保存されません。, 「統計収集後、SQL実行計画が変化し、性能が劣化した」というケースでは、この新機能と以前からある統計情報のエクスポート／インポート機能を利用して、以下のような運用が可能です。, 統計再収集後に一部のSQLの性能が劣化したことが判明（原因の詳細な分析や、パラメータを変えて再度、統計収集する時間がない場合に以下を実行）, 適切な性能が出ていた過去の時点を指定して、オプティマイザ統計をリストア（この時点で本番システムは過去の性能に戻る）, 分析中は本番環境の自動統計収集を停止するか、問題があると思われる一部の統計をロックし、上書きされないようにする, 問題が発生したときに、単純に過去の統計に戻しただけでは、それ以降の統計収集でも再度同じ問題が発生するかもしれません。そのため、テスト環境に問題の統計を移行して解析することは重要です。, 本番環境のオプティマイザ統計をエクスポートし、テスト環境にインポートすることで、実データ量が少ないテスト環境や開発環境において、本番環境で選択されるであろう実行計画をシミュレートできます。SQLチューニング時に本番環境が使用できない場合（多くの場合そうだと思いますが）、テスト環境で最良のチューニング方法を検討する場合に非常に有効な方法です。, 以下にスキーマ単位で統計をリストアする手順例を示します。この例ではTESTスキーマを使用しています。まず、現在の統計のタイムスタンプ（収集時刻）を確認します（索引統計、列統計のタイムスタンプの確認は省略しています）。, 現在の統計と同じ時刻の統計がエクスポートされています。22:00:51の統計は、上の例では参照していない索引統計もしくは列統計です。

オプティマイザ統計を収集する場合、データベースで内部プロシージャがコールされます。このプロシージャは、gather_database_statsプロシージャをgather autoオプションを指定して実行する場合と同様に動作します。自動統計収集はデータベース内のすべてのプリファレンス・セットに従います。 なお、動的サンプリングの使用法を決めるパラメータOPTIMZER_DYNAMIC_SAMPLINGはセッションレベルで変更可能（ALTER SESSION文）であり、SQLレベルで設定する場合には、DYNAMIC_SAMPLING（表名 n）ヒントを利用可能です（nはサンプリングレベル）。, Oracle 10gでは、統計収集されていない表に対するハードパース時には動的サンプリングが行なわれます。通常、高速なレスポンスが要求されるOLTPシステムでは、動的サンプリングはオーバーヘッドとなります。有効な用途としては一時表に対するアクセスがあります。DWH系のシステムでは相関関係のある列に対する選択率を適切に見積もるのに有効な場合があります。, 動的サンプリングの設定にはoptimizer_dynamic_samplingパラメータを用います。デフォルト値は2であり、本文で説明したような動作をします。値を0に設定すると、動的サンプリングはOFFになります。設定値を大きくすることにより、サンプリングされるブロック数を増やせます。なお9i R2ではデフォルト値は1であり、動的サンプリングが発生する条件は10gよりも厳しくなっています。. ョット設定の変更」, 「変動ウィンドウ・ベースライン」, 「自動ワークロード・リポジトリ」, 「ベースライン・テンプレート」, Oracle Databaseセキュリティ・ガイド, Oracle Database PL/SQLパッケージおよびタイプ・リファレンス, 「自動ワークロード・リポジトリ・ビューの使用」, 「SQLスクリプトを使用したパフォーマンス・ハブ・アクティブ・レポートの生成」, 「パフォーマンス・ハブ・アクティブ・レポートのタイプについて」.

例えば、CBOをまったく知らないユーザーが、Oracle 10gをインストールして表を作成し、データをローディングして索引を作ったとします。10gでは、CREATE INDEX文の実行時にデフォルトで索引のオプティマイザ統計を収集するため、この時点でまず、索引の統計情報が格納されます。, 次に、その表を使用してアプリケーションのテストを開始したとします。この時点では表の統計情報が存在しないため、SQLの発行時にオプティマイザ統計の動的サンプリングが行なわれます。これに基づいて、オプティマイザは実行計画を生成します。この時、OracleはSQLの条件句で指定された列の情報をディクショナリに記憶しています。, さらに、その夜の22時になるとオプティマイザ統計を収集するスケジュールジョブが自動的に起動します。昼間作成された表の統計情報が収集され、アプリケーションが条件指定した列に対してはヒストグラムが作成され、翌日には統計情報が揃った状態で使用可能です。, オプティマイザ統計の再収集のタイミングも、ユーザーが意識する必要はありません。Oracleは表ごとに更新された行数の履歴を記録しており、更新された行数の割合が増えてくると、自動的に統計を再収集します。, いかがでしょう。オプティマイザに関する運用が自動化されたのは、魅力的ではないでしょうか。確かに、システム規模が小さく、管理に時間やお金がかけられないシステムにおいては、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）とみなします。 自動化メンテナンス・タスクとは、データベースのメンテナンス操作を実行するために、 一定の間隔をおいて自動的に開始されるタスクです。 デフォルトでは以下の3種類の自動化メンテナンス・タスクが設定されています。 自動オプティマイザ統計収集 小田 圭二(おだ けいじ), さて、これまでオプティマイザがどんな情報を利用し、どういう仮定を立て、どういう計算で実行計画を選択しているかについて説明してきました。次に、オプティマイザ統計の管理について知っていただきたいと思います。, オプティマイザに対する重要なインプットは、言うまでもなくオプティマイザ統計であり、これを収集する頻度や精度、ヒストグラムを収集するか、また対象の列はどうするかといった点は、CBOの運用における極めて重要なポイントです。, Oracle 10gではRBOがサポートされなくなり、すべてのユーザーはCBOを使用する必要があります。そのためにOracle 10gは、ユーザーが意識しなくても「オプティマイザ統計管理」を自動的に実行する仕組みを実装しています。

しかし、実際にはJOB='MANAGER'を満たすレコードがすべてSALARY>5000を満たしていたらどうでしょう（「マネージャの給料は高い」という相関関係です）。本当の選択率はSel（JOB='MANAGER'）と同じになり、0.1です。 「SIZE AUTO」の場合にどの列にヒストグラムが作られるのかは、それ以前のアプリケーションの実行状況に依存します。Oracleは表のどの列がSQLの条件句として使用されたかモニタリングし、ディクショナリに記録しています。「SIZE AUTO」の場合、このディクショナリを参照して、どの列にヒストグラムを作る価値があるかを判断しています。, Oracleはこれまでに条件指定のあった列に対してメモリ上で200バケットの高さ調整ヒストグラムを作成し、値の偏り（ポピュラー値が存在、もしくは値のまばらな区間の存在）が見られた場合には、オプティマイザ統計としてディクショナリに格納します。, 統計収集はパラレル実行が可能ですが、デフォルトではパラレル度としてオブジェクトのDEGREE属性が使用されます。DEGREE属性はデフォルトでは1であり、シリアル実行となります。表のDEGREE属性は「ALTER TABLE…PARALLEL 4;」のように変更可能です。ただし表のDEGREE属性を変更した場合、統計収集だけでなく、通常の問い合わせもパラレルで実行されるようになりますので注意が必要です。, 統計の再収集後に、当該オブジェクトに依存している共有カーソルを無効化できます。これにより、統計収集の直後に、そのSQL文を新しい統計情報とともに再解析し、新しい実行計画を生成できます。デフォルトでは統計の再収集後も、共有カーソルを無効化しません。つまり、その共有カーソルがキャッシュアウトし、次回のハードパースのタイミングではじめて、新しい統計値を反映した実行計画が生成されます。, これは、オプティマイザ統計の収集直後に発行されるSQL文のレスポンスを劣化させないためには有効です。しかし、共有カーソルがキャッシュされている間は新しい統計を取った意味がないため、システム負荷が低くなる時間帯などに共有プールをフラッシュ（alter system flush shared_pool文）するようなオペレーションが必要です。, 10gではデフォルト（STATISTICS_LEVEL=TYPICALの場合）で、すべての表に対するDMLの発行状況をOracleがモニタリングし、ディクショナリに記録しています。この記録に基づいて、最後の統計収集以後に大量の行（全体の10%以上）が更新された表については、既存のオプティマイザ統計が「古くなった」ものとみなして再収集の対象とします。 Copyright © 2009, Oracle Corporation Japan. 自動化メンテナンス・タスクとは、データベースのメンテナンス操作を一定間隔毎に自動的に行うタスクです。Oracle Database には、次の 3種類の自動化メンテナンス・タスクが事前に定義されています。, これらのタスクは、メンテナンス・ウィンドウ（メンテナンス可能として設定した時間帯）で実行され、リソース・コンシューマグループに割り当てられます。また、ウィンドウの期間中に使用されるリソース・プランの設定値により、タスクが消費できる CPU 等のリソースが制限されます。, デフォルト設定では、自動化メンテナンス・タスクに割り当てられる CPU 使用率は最大 25%に抑えられるため、他の通常タスクにほとんど影響を与えないで統計情報を収集できます。上記 3つのタスクの利点は、DBA による領域使用量の監視やオプティマイザ統計の収集、高負荷 SQL 文のチューニングに役立つことです。, 自動オプティマイザ統計収集は、Oracle Database 10g 以降に実装された、データベース・オブジェクトに対する統計情報を自動的に収集する機能です。この機能によって、データベース管理者の手動タスクを削減でき、また不適切な実行計画による SQL 文のパフォーマンス低下を防止できます。, 自動オプティマイザ統計で収集される統計情報には、オブジェクト統計とシステム統計があります。オブジェクト統計では、表や列、索引などの統計情報が取得されます。システム統計では、システムのハードウェア特性である I/O や CPU のパフォーマンスと使用率についての統計情報が取得されます。Oracle Database では、設定された時間になると自動的に統計情報の収集を開始し、情報の最新化を行います。（デフォルト設定の場合、平日は 22時、土曜日・日曜日は 6時から収集を開始します）, 収集された統計情報は、SQL 文の実行計画を作成するために使用されます。実行計画とは、表へのアクセス方法や結合方法など SQL 文を実行するための計画です。オプティマイザは、アクセスパスのコストを見積もり、コストが最も低いものを実行計画として選択します。これにより最適な実行計画が選択されるため、パフォーマンスの向上が期待できます。, しかし、統計情報はリアルタイムで更新されないため、頻繁に大量のデータ更新が行われる場合、理想的な実行計画が選択されずパフォーマンス劣化が発生する恐れがあります。これは、取得した統計情報と実際のデータ状況が異なることが原因です。例として、日中帯に大幅なデータ追加・削除のある表に対し、深夜帯に統計情報を収集することで、取得した統計情報と実際のデータに乖離が発生することが挙げられます。, 自動オプティマイザ統計収集は、自動化メンテナンス・タスクの一部として実行されます。デフォルトでは有効となっており事前定義されたすべてのメンテナンス・ウィンドウで実行されます。, 事前定義されている自動化メンテナンス・タスクが有効になっているかは、下記のように確認できます。（以下は、Oracle Database 11.2.0.3 Enterprise Edition での実行例です）, 上記では、自動オプティマイザ統計収集、自動セグメント・アドバイザ、自動 SQL チューニング・アドバイザが有効となっていることを確認できます。, 自動オプティマイザ統計収集は、データベース・オブジェクトに対する統計情報を自動的に収集するための機能で、最適な SQL文の実行計画を作成するために利用しています。自動的に統計情報を収集できる反面、利用しているシステムの特性によってはパフォーマンス劣化を引き起こす場合もありますので、その点を踏まえたうえで使用をご検討ください。, Copyright © 2020 NTT DATA INTELLILINK Corporation, http://docs.oracle.com/cd/E16338_01/server.112/b56301/tasks.htm#CIHGDCEH, http://docs.oracle.com/cd/E16338_01/server.112/b56312/stats.htm#sthref1165, ビッグデータコラム Column on Big Data Analytics and Platform. 月曜日～金曜日の22時にオープンし、8時間後（明朝6時）にクローズするウィンドウ, WEEKEND_WINDOW 事前準備としてDBMS_STATSを使用して手動でヒストグラムを収集しても、アプリケーションの走行前に自動統計が収集されると、「使用されていない列」としてヒストグラムが消されます。, 内部的に記録した行の更新状況や列の使用状況に基づいて一律に統計再収集を決定したり、ヒストグラム作成を決定したりしているため、再収集したものの統計的な変化がない場合があります。条件指定されたことのある列は、アプリケーションの変更によって使用されなくなったとしても、しばらくの間（6ヶ月）はヒストグラム作成の対象となります。, 安定性や予測可能性（所要時間やリソース消費量がいつも同じで、正確な見積もりが可能であること）を最大限重視する場合は、デフォルトの自動統計収集はオフにして、手動で収集 注18したほうが良いでしょう。その際、統計収集パラメータとして「自動設定」は使用せず、数値で指定可能なもの（サンプルサイズ／バケット数／パラレル度）は数値で指定することをお勧めします。また、オブジェクトごとに個別の収集パラメータを指定して、きめ細かな管理をしたい場合にも、自動統計収集をオフにした上で手動で収集してください。, >注18：各種統計収集パラメータ（サンプリング方法／サンプルサイズ／ヒストグラム対象列／パラレル度／パーティション表の扱い／SQLの無効化など）を適切に設定して、DBMS_STATSパッケージプロシージャをコールします。, ただし、このような手動収集で適切なパラメータ値を決定するためには、やはりテストを繰り返す必要があります。とはいえ、オンライン処理のレスポンスやバッチ処理の所要時間は厳密な管理をしていないのに、オプティマイザ統計収集のみ厳密な設定をするためにテストを繰り返す必要はないでしょう。システムの重要性に応じて判断してください。, 自動統計収集ではアプリケーションが実際に走行しないと必要なヒストグラムが作られません。これは、リグレッションツールなどを使用してシステムのカットオーバー前に網羅的にアプリケーションを走行させられない環境では問題かもしれません。その場合、必要なヒストグラムが分かっていれば手動で作成し、しばらく自動統計収集を止めた状態で運用し、アプリケーションのすべての機能が使用されたころを見計らって自動統計収集を開始するというアイディアもあります。, 最後に、自動統計収集が無駄に統計収集をしているかもしれないという点は、それが自動統計収集の本質であり、無駄であろうとも機械的に収集することで陳腐化するのを防ぐというアプローチであることを理解する必要があります。「無駄に収集しているかどうか」は人間の管理者の経験によってのみ判断できることです。データの統計的な変動がほとんどないことが分かっているシステムでは、自動統計収集を使用する必要はありません。適宜、手動で収集してください。, 自動統計収集では、いつ、どの表が統計収集されたか、サンプルサイズはどの程度であったか、どの列にヒストグラムが作成されたかを監視することをお勧めします。これらの情報は将来、手動収集に切り替える必要ができた場合の重要なインプットになります。また、統計収集の頻度があまりに低い表は、更新がほとんど発生していないことも考えられますが、表が大きすぎてウィンドウ内で完了していない可能性もあります。「GATHER_STATS_JOB」のところで記述したようにトレースファイルも確認して、強制中断されているオブジェクトがある場合はウィンドウの長さが妥当かどうかを検討してください。監視例をLIST6およびLIST7に示しておきます。, 自動統計収集はCBOに対する敷居を下げる優れた機能と言えます。しかし、統計収集によって行なわれる作業が「いつも同じである」という安定性を重視する場合や、統計収集の最適な頻度や対象オブジェクトが分かっているようなケース、オブジェクトレベルできめ細かな管理をしたい場合は手動統計収集をお勧めします。自動統計収集を利用する場合は、スケジューラウィンドウを適切に設定し、統計収集の実行状況を監視すると良いでしょう。, 「オプティマイザ統計を再収集したら、SQL実行計画が変化し、性能が劣化した」という経験がリスクとして認識され、定期的な統計が収集されていないケースがあります。この問題についてはCBOの本質として、最後に「CBOを使いこなすためには」の部分で考察しますが、このリスクはCBOで運用する上では避けられないものと言えます。

.

Fy 17s7 取扱説明書 5, 広島 街コン アニメ 4, Giant Gravier レビュー 5, チャイルドシート Isofix 外し方 4, レンガ 花壇 丸 9, エコキュート 配管 むき出し 5, スマイル 目薬 歴史 6, Vba リストボックス 未選択にする 4, 星野源 ライブ 曲 順 4, Eh Na9b Eh Cna9b 違い 8, エコキュート 日立 デメリット 7, Pc スリープ 解除される 5, Ff14 レベル上げ 初心者 7, Here You Are 漫画 日本語 9, ミニチュア シュナウザー 里親 福岡 32, バモス 間欠 ワイパー 4, 鎌倉高校 サッカー部 人数 6, モラハラ妻 離婚 後悔 16, Ie10 Flex はみ出る 8, Galaxy S20 急速充電できない 14, 自動車保険 強制解約 再契約 27, トヨタ Atf交換 料金 7, 野獣先輩 現在 2019 20, 赤西仁 Tiktok 消えた 14, スライド 丸ノコ レンタル 4, No Module Named Busio 7, 雨樋 エルボ 角度 4, アル中 カラカラ Bgm 23, 炊き込みご飯 黄金比 一 番 人気 7, Jba 審判 3po 8, ハイセンス 65s6e 65u7e 14, 合コン カラオケ 行きたくない 4, 外付けhdd 録画 消去 5, 資生堂 スリークライナー 後継 9, The Light 関ジャニ Mp3 24, リコイル制御 マウス Apex 8, Jb23 エンジンルーム 異音 7, バイク ツーリング 九州 冬 14,