オプティマイザーの統計範囲:
テーブル統計; --行数、ブロック数、平均行長; all_tables : NUM_ROWS 、BLOCKS 、AVG_ROW_LEN ;
列統計; --列内の一意の値の数 ( NDV )、NULL値の数、データ分布;
--DBA_TAB_COLUMNS : NUM_DISTINCT 、NUM_NULLS 、HISTOGRAM ;
インデックス統計; --リーフ ブロック数、レベル、クラスタリング係数;
--DBA_INDEXES : LEAF_BLOCKS 、CLUSTERING_FACTOR 、BLEVEL ;
システム統計; --I/Oパフォーマンスと使用法;
-- CPU のパフォーマンスと使用率; --aux_stats$に
格納されますdbms_stats を使用して収集する必要があり、 I/O統計はX$KCFIOにあります。
-------------
分析
------------- ANALYZE統計
を使用する必要がある統計: LIST CHAINED ROWSおよびVALIDATE句を使用する;フリー リスト ブロックに関する統計を収集する;テーブル tablename 計算統計の分析;インデックス|クラスター インデックス名推定統計の分析; ANALYZE TABLE テーブル名 COMPUTE STATISTICS FOR TABLE FOR ALL [LOCAL] INDEXES FOR ALL [INDEXED] COLUMNS; ANALYZE TABLE テーブル名 DELETE STATISTICS ANALY ZE TABLE テーブル名 VALIDATE REF UPDATE ANALYZE TABLE テーブル名 VALIDATE STRUCTURE [CASCADE]|[INTO TableName] ANALYZE TABLE tablename LIST CHAINED ROWS [INTO TableName] ANALYZEはパーティション テーブルには適していません
----------------------
dbms_stats
の分析---------------------- dbms_statsは良い 統計データを正確に見積もり (特に大きな分割テーブルの場合)、より良い統計結果を取得し、最終的により高速なSQL実行計画を作成します。
このパッケージの次の 4 つのストアド プロシージャは、それぞれindex 、table 、schema 、およびdatabaseの統計情報を収集します:
dbms_stats.gather_table_stats はテーブル、列、およびインデックスの統計情報を収集します;
dbms_stats.gather_schema_stats はSCHEMAの下のすべてのオブジェクトの統計情報を収集します; dbms_stats.gather_index_statsは収集します索引統計; dbms_stats.gather_system_stats はシステム統計を収集しますdbms_stats.GATHER_DICTIONARY_STATS :すべてのディクショナリ・オブジェクトの統計; DBMS_STATS.GATHER_DICTIONARY_STATS
すべてのシステム モードの統計を収集します。
dbms_stats.delete_table_statsテーブル統計の削除
dbms_stats.delete_index_statsインデックス統計の削除
dbms_stats.export_table_statsテーブル統計のエクスポート
dbms_stats.create_state_table
dbms_stats.set_table_statsテーブル統計の設定
dbms_stats.auto_sample_size
統計収集の許可
============================================ ================================
通常のユーザー権限を付与する必要があります
sys@ORADB > grant execute_catalog_role to hr;
sys @ORADB > grant connect , resource, analyze any to hr;
統計収集方法の使用
============================
1.統計情報の自動収集
Oracle10g以降では、ジョブGATHER_STATS_JOB がデフォルトで使用され、データベース オブジェクトの統計情報が自動的に収集されます。
自動統計収集は、表の監視に依存します。表の監視はoracle10gではデフォルトで有効化されており、STATISTICS_LEVELパラメータにも依存します。
パラメータSTATISTICS_LEVELがTYPICALまたはALLに設定されている場合、システムは夜間に統計情報を自動的に収集します。システムが自動的に統計を収集するジョブを表示します: SELECT * FROM dba_scheduler_jobs WHERE job_name = ' GATHER_STATS_JOB ';また、自動統計収集をオフにすることもできます:
2.手動統計を使用する
自動統計収集は夜間に行われるため、すべての変更アクティビティのオブジェクトの自動統計で十分なはずです。頻繁に更新されるオブジェクトの一部の統計は古くなる可能性があります。そのような 2 つの典型的なオブジェクト:
日中の活動中にTRUNCATE/DROPされ、再構築される非常に揮発性のテーブル(頻繁に変化するオブジェクト);ブロックが
合計サイズの10%を超えて変更されるオブジェクト (バッチ変更オブジェクト)。
最初のオブジェクトについては、次の 2 つの方法を使用できます:
1.これらのテーブルの統計をNULLに設定します。Oracleは、統計のないテーブルを検出すると、クエリの最適化の一環として必要な統計を動的に収集します。動的収集機能は、OPTIMIZER_DYNAMIC_SAMPLINGコントロールによって決定されます。このパラメータは2以上に設定する必要があります。デフォルトは2です。統計を削除してロックすることにより、統計をNULLに設定できます: DBMS_STATS.DELETE_TABLE_STATS('SCHEMA','TABLE') ;
2これらのテーブルの統計を、典型的な状態を表す値に設定します。表に代表的な値がある場合に統計を収集し、統計をロックします。
夜間に収集された統計はその日の負荷に適していない可能性があるため、このような場合はGATHER_STATS_JOBよりも手動収集を使用する方が効率的です。
バッチで変更されるテーブルの場合、統計はバッチ変更の直後に収集する必要があり、統計情報ステートメントは通常、バッチ ステートメントの後ろにバインドされます。
外部テーブルの場合、GATHER_DATABASE_STATS 、GATHER_SCHEMA_STATS 、および自動統計収集を介して統計を収集することはできません。したがって、 GATHER_TABLE_STATS を使用して単一テーブルの統計を収集する必要があり、サンプリングは外部テーブルではサポートされておらず、ESTIMATE_PERCENT を明示的にNULLに設定する必要があります。STATISTICS_LEVELがBASICに設定され、監視機能が無効になっている場合、自動統計収集では古い統計が検出されず、手動収集が必要になります。
3手動で収集する必要があるもう 1 つの場所は、自動的に収集されないシステム統計です。GATHER_FIXED_OBJECTS_STATS
を使用して収集する必要がある動的パフォーマンス テーブルなどの固定テーブルの場合、これらのテーブルの統計は、データベースが代表的にアクティブになった後に収集する必要があります。
統計収集に関する考慮事項
============================
1統計収集でサンプリングを使用 ( ESTIMATE_PERCENT )
サンプリングを使用しない統計収集では、全表スキャンと表全体のソートが必要であり、サンプリングによって統計収集に必要なリソースが最小限に抑えられます。
DBMS_STATSのESTIMATE_PERCENTパラメータをDBMS_STATS.AUTO_SAMPLE_SIZEに設定して、必要な統計精度を達成しながらパフォーマンスを最大化することをお薦めします。
2並列統計収集 ( DEGREE )
DBMS_STATSのDEGREEパラメータをDBMS_STATS.AUTO_DEGREEに設定することをお薦めします。これにより、Oracleはオブジェクトのサイズと並列処理初期化パラメータの設定に従って、適切な並列処理の度合いを選択できます。クラスタ化インデックス、フィールド インデックス、およびビットマップ結合インデックスは、並列に収集できません。
3パーティション化されたオブジェクトの統計収集 パーティション
化されたテーブルとインデックスの場合、DBMS_STATS は個々のパーティションとグローバル パーティションの統計を収集できます 結合パーティションの場合は、サブパーティション、パーティション、およびテーブル/インデックスの統計を収集できます パーティションの統計は、宣言によって収集できますパラメータGRANULARITY 。最適化するSQL文に応じて、オプティマイザはパーティション統計またはグローバル統計の使用を選択できます。ほとんどのシステムでは、これら2つの統計が非常に重要です。GRANULARITYをAUTOに設定し、すべての情報を同時に収集することをお薦めします。
4列の統計とヒストグラム
テーブルの統計を収集する場合、DBMS_STATS はテーブル内の列のデータ分布に関する情報を収集します。データ分布に関する最も基本的な情報は最大値と最小値ですが、データ分布が偏っている場合、このレベルオプティマイザには十分な統計がありません。偏ったデータ分布の場合、ヒストグラムは列統計の一部としてよく使用されます。
ヒストグラムは、METHOD_OPTパラメータによって宣言されます。Oracleでは、METHOD_OPTをFOR ALL COLUMNS SIZE AUTOに設定することをお薦めします。この値を使用すると、ヒストグラムが必要な列と各ヒストグラムのバケット数が自動的に決定されます。ヒストグラムを必要とする列とバケットの数を手動で設定することもできます。DBMS_STATSの使用時にテーブル内のすべての行を削除する必要がある場合は、 drop/createの代わりにTRUNCATEを使用する必要があります。そうしないと、自動統計収集機能で使用される負荷情報とRESTORE_*_STATSで使用される保存された統計履歴が失われます。これらの機能は正しく機能しません。
5期限切れの統計の判別
時間の経過とともに変化するオブジェクトについては、統計を定期的に収集する必要があります.期限切れの統計を判別するために、Oracleはこれらの変更を監視する表を提供します.これらの監視は、 STATISTICS_LEVELがTYPICAL/ALLの場合、デフォルトで有効になります. USER_TAB_MODIFICATIONS . DBMS_STATS.FLUSH_DATABASE_MONITORING_INFOを使用すると、監視を超えた情報をすぐにメモリに反映できます。OPTIONSパラメータがGATHER STALE または GATHER AUTOに設定されている場合、DBMS_STATS は、統計の有効期限が切れているオブジェクトに関する統計を収集します。
6ユーザー定義の統計インデックスベースの統計を作成した後、テーブルで新しい列統計を収集する必要があります。これは、 METHOD_OPTのFOR ALL HIDDEN COLUMNS
を呼び出すことによって設定できます。
7いつ統計を収集するか 増分的に変更されたテーブルの場合、月または週
に 1 回だけ収集する必要がある場合があり、ロードされたテーブルの場合、通常、統計を収集するためのスクリプトがロード スクリプトに追加されます。パーティション化されたテーブルの場合、大きな変更が 1 つのパーティションのみにある場合、1 つのパーティションの統計を収集するだけで済みますが、テーブル全体のパーティションも収集する必要があります。
システム統計
==========================システム統計は、 I/OやCPU
を含むシステム ハードウェアの特性を表します。実行計画を選択するとき、オプティマイザはクエリに必要なCPUとI/Oのコストを考慮します。システム統計により、オプティマイザーはCPUとIO のコストをより正確に評価し、より適切なクエリ プランを選択できます。DBMS_STATS.GATHER_SYSTEM_STATSを使用してシステム統計を収集します。システム統計を収集することをお薦めします。システム統計の収集には、DBA権限が必要です。収集されたオプティマイザ システム統計には、次のものが含まれます: cpuspeedNW : 無負荷のCPU速度を表し、CPU速度は 1 秒あたりのCPUサイクル数です。統計は、collecting_mode = NOWORKLOAD を設定するか手動で設定されます。単位はMillions/secです。ioseektim : I/Oシーク時間=シーク時間+
遅延時間+ OSロード時間。collecting_mode = NOWORKLOAD を設定するか、統計を手動で設定します。単位はmsです。
Iotfrspeed : I/O転送速度;統計は、 gathering_mode = NOWORKLOAD を設定するか手動で設定されます; 単位はバイト/ミリ秒です. Cpuspeed : 負荷CPU速度を表し、CPU速度は1 秒あたりのCPUサイクル数です;収集モードを設定することにより=NOWORKLOAD、INTERVAL、START|STOP 、または統計を手動で設定します。単位はMillions/secです。Maxthr : 最大I/Oスループット; 統計は、gathering_mode =NOWORKLOAD、INTERVAL、START|STOPを設定するか、手動で設定します; 単位はバイト/秒ですSlavethr : サービスI/Oスループットは平均並列サービスI/Oです
スループット;統計は、collecting_mode = INTERVAL 、START|STOP 、または手動の設定による; Bytes/sec. Sreadtim : 単一ブロックのランダム読み取りの平均時間; 統計は、collecting_mode = INTERVAL 、START|STOPまたは手動の設定による; 単位はmsです。Mreadtim : gather_mode = INTERVAL 、START|STOP を設定するか、統計を手動で設定することにより、複数のブロックを順次読み取るための平均時間。単位はmsです。Mbrc:マルチブロック読み取りによって毎回読み取られるブロックの平均数。
システム統計の再収集によって現在のSQLが無効になることはありませんが、新しいSQLステートメントはすべて新しい統計を使用します。
Oracle では、統計を収集するために、負荷統計と非負荷統計の 2 つのオプションを提供しています。
負荷統計
============================================== ===========
ロード ウィンドウの開始時にdbms_stats.gather_system_stats('start')を実行し、次にdbms_stats.gather_system_stats(' stop')を実行してロード ウィンドウを終了します。dbms_stats.gather_system_stats('interval', interval=>N)
を実行します。Nは、システム統計収集がN分後に終了することを意味します。dbms_stats.delete_system_stats()を実行して負荷統計を削除します。
非負荷統計
=========================== dbms_stats.gather_system_stats()を
パラメータなしで実行して、非負荷統計を収集します。 -load statistics 特定のI/O負荷があります。場合によっては、非負荷統計の値がデフォルトのままになることがあります。その場合は、dbms_stats.set_system_stats設定を使用する必要があります。
統計の管理
===========================
前のバージョンの統計をダンプするタイムスタンプを使用するRESTORE手順
を使用して、前のバージョンの統計をダンプする1 DBA_OPTSTAT_OPERATIONS : DBMS_STATSを使用してモード/システム・レベルで実行される統計操作が含まれます; 2 *_TAB_STATS_HISTORY : 表の統計変更の履歴が含まれます。古い統計は、 DBMS_STATSのALTER_STATS_HISTORY_RETENTIONプロセス設定に従って定期的にリフレッシュされ、デフォルトは31日です。デフォルトでは、STATISTICS_LEVELがTYPICAL/ALLの場合、自動更新が有効になります。それ以外の場合は、PURGE_STATによる手動更新が必要です。
ダンプとリフレッシュに関連するその他の情報には、以下が含まれます:
PURGE_STATS : 特定のタイムスタンプより古い古い統計を手動でリフレッシュする;
GET_STATS_HISTORY_RENTENTION : 現在の履歴統計保持値を取得する;
GET_STATS_HISTORY_AVAILABILTY : 利用可能な最も古い統計のタイムスタンプを取得する.
ダンプの制限:
1.ユーザー定義の統計はダンプできません;
2. ANALYZEコレクションが使用されている場合、古い統計はダンプできません。
統計のインポート/エクスポート
==========================統計をエクスポートする前に、 DBMS_STATS.CREATE_STAT_TABLEを使用して、統計を保持するための統計テーブルを作成する
必要があります。表の作成後に作成できます。DBMS_STATS.EXPORT_*_STATSを使用して統計をカスタム表にエクスポートし、これらの統計をDBMS_STATS.IMPORT_*_STATSを使用して再インポートできます。IMP/EXP を使用して他のデータベースにインポートすることもできます。
統計をダンプし、統計をインポートおよびエクスポートします
ダンプを使用する場合:
1.古いバージョンの統計を復元する;
2.データベース管理の統計履歴を保持および更新することを望む; EXPORT/IMPORT_*_STATS
を使用する: 1.さまざまな値のさまざまな状況で実験する; 2.統計を別のデータベースに移動する; 3. .統計を長期間保持します。
ロックされたテーブルとスキーマの統計
==========================
統計がロックされると、ロックされるまで統計を変更することはできません。ロックされていません。DBMS_STAT には、ロック解除用の 2 つのプロセスとロック用の 2 つのプロセスがあります。¤LOCK_TABLE_STATS ; 2 UNLOCK_SCHEMA_STATS ; ¡ ¤ UNLOCK_TABLE_STATS ;
統計の設定
=========================== SET_*_STATISTICS
を使用して、テーブル、インデックス、列、システム統計を設定できます。統計を評価するための動的サンプリングの使用========================================== ================================================== ================================================== =======見積もりはサーバーのパフォーマンスを向上させ、より正確な見積もりはより良いパフォーマンスをもたらします。動的サンプリングを使用できる状況: 1収集された統計が使用できない場合、または重大な見積もりエラーが発生する場合に、単一のテーブルの述語選択性を見積もります; 2 統計のないテーブル/インデックスの統計を見積もります; 3期限切れのテーブルとインデックスの統計を見積もります統計:動的サンプリング機能は、パラメータOPTIMIZER_DYNAMIC_SAMPLINGによって制御され、デフォルト レベルは2です。
動的サンプリングの動作メカニズムの
主なパフォーマンス特性は、コンパイル時です。Oracleは、問合せがサンプリングの恩恵を受けるかどうかをコンパイル時に決定します。そうである場合、再帰SQLを使用して少数の表ブロックをランダムにスキャンし、関連する単一テーブルの述語の評価 述語の選択性。
動的サンプリングを使用する時間は、
動的サンプリングを使用することでメリットがあります。1 より
適切な実行計画を見つけることができます。2サンプリング
時間は合計時間のごく一部にすぎません。3クエリが複数回実行されます。
サンプリング レベル
============================ 1..10
の範囲
欠落統計処理
============================ Oracle が欠落統計を検出する
と、オプティマイザはその統計を動的に必要とします。場合によっては、Oracle が動的サンプリングを実行できないことがあります。これには、リモート テーブル/外部テーブルが含まれ、現時点ではデフォルトの統計が使用されます。統計が欠落している場合のテーブルのデフォルト値: 1 カーディナリティ: num_of_blocks * (block_size - cache_layer) / avg_row_len 2 平均行長: 100バイト; 3 ブロック数: 100またはパーティション マッピングに基づく実際の値; 4 リモート カーディナリティ: 2000行; 5 リモート平均行長: 100バイト;統計がない場合のインデックスのデフォルト値:レベル: 1リーフ ブロック: 25リーフ ブロック/キー:
1
データ ブロック/キー：1
個別キー：100
クラスタリング係数：800
dbms_statsを 開始 します
。=> dbms_stats.auto_sample_size, method_opt => 'for all columns size repeat', degree => 15 ); end;オプション
パラメータは、 4 つのプリセット メソッドを使用します:
収集 -アーキテクチャ全体を再分析します (スキーマ)。
空の収集 -まだカウントされていないテーブルのみを分析します。
stale を集める - 10%を超えて変更されたテーブルのみを再分析します(これらの変更には、挿入、更新、および削除が含まれます)。収集自動 -現在統計を持たないオブジェクト、および統計が古い (ダーティ) オブジェクトを再分析します。gather staleとgather emptyの組み合わせに似ています。
stale の収集とauto の収集の両方で監視が必要であることに注意してください。alter table xxx 監視コマンド
を実行すると、Oracle はdba_tab_modificationsビューを使用して、変更されたテーブルを追跡します。このようにして、最後に統計を分析してから、挿入、更新、および削除が何回発生したかを正確に知ることができます。SELECT * FROM Sys.Dba_Tab_Modifications WHERE Table_Owner = 'SCOTT'; alter table xxx モニタリングコマンドを使用してOracleテーブル モニタリングを実装する場合、 dbms_statsでautoオプションを使用する必要があります。autoオプションは、データ分布とアプリケーションが列にアクセスする方法 (例: 監視によって決定された列のワークロード) に基づいてヒストグラムを作成します。method_opt=>'auto'を使用することは、 dbms_statsのオプションパラメータでgather autoを使用することに似ています。
begin
dbms_stats.gather_schema_stats(ownname => 'SCOTT',
Estimate_percent => dbms_stats.auto_sample_size,
method_opt => 'for all column size auto',
degree => 7);
終わり;
Estimate_percentオプション
次のEstimate_Percentパラメータは比較的新しい設計で、Oracleのdbms_statsが統計データの収集時にサンプリングされるセグメントの最適なパーセンテージを自動的に推定できるようにします
。で、 dba_tables sample_size列
を表示できます。興味深い点の 1 つは、オートサンプリングを使用する場合、オラクルはサンプル サイズとして5 ～20のパーセンテージを選択することです。統計が優れているほど、CBO が下す決定も優れていることを忘れないでください。
method_optオプション
dbms_statsのmethod_optパラメータは、テーブルとインデックスのデータが変更されたときに統計を更新するのに特に適しています。method_optパラメーターは、どの列にヒストグラムが必要か ( histograms )を判断するのにも適しています。場合によっては、インデックス内の値の分布が、インデックスを使用するか、テーブル全体のスキャンを実行するかのCBOの決定に影響を与える可能性があります。たとえば、where句で指定された値の数が非対称である場合、完全なテーブル スキャンはインデックス アクセスよりも経済的に見えることがあります。インデックスが大きく歪んでいる (特定の値の行数が非対称である) 場合は、Oracleヒストグラム統計を作成できます。しかし、現実の世界では、これが起こる可能性はかなり低いです。CBOを使用する際の最も一般的な間違いの 1 つは、不必要にヒストグラムをCBO統計に導入することです。経験則として、ヒストグラムは、列の値が実行計画の変更を必要とする場合にのみ使用する必要があります。ヒストグラムをインテリジェントに生成するために、Oracle はdbms_statsのmethod_optパラメータを用意しました。method_opt句には、 skewonlyなどの重要な新しいオプションもいくつかあります。
repeat和auto ：method_opt=>'for all column size skewonly'
method_opt=>'for all column size repeat'
method_opt=>'for all column size auto'
Skewonlyオプションは、各インデックスの各列の値の分布をチェックするため、処理にコストがかかります。インデックスの列が不均一に分散されていることがdbms_stat によって検出される
と、そのインデックスのヒストグラムが作成され、コストベースのSQLオプティマイザーがインデックス アクセスとフル テーブル スキャン アクセスのどちらを実行するかを決定するのに役立ちます。たとえば、インデックスで、行の50%に列があると仮定すると、これらの行を取得するには、全テーブル スキャンの速度がインデックス スキャンよりも速くなります。--************************************************ ************* -- SKEWONLY オプション - 詳細な分析-- -- この方法は、歪んだインデックスの最初の分析に使用します-- すべてのインデックスが検査されるため、これは長時間実行されます-- ****************************************************** *** ************ begin dbms_stats.gather_schema_stats(ownname => 'SCOTT', Estimate_percent => dbms_stats.auto_sample_size, method_opt => 'for all column size skewonly',
程度 => 7);
終わり;
統計を再分析するときは、繰り返しオプションを使用すると、再分析タスクが消費するリソースが少なくなります。繰り返しオプションを使用すると、インデックスは既存のヒストグラムに対してのみ再分析され、他のヒストグラムの機会は検索されません。これは、定期的に統計を再分析するときに行う必要があります。
--************************************************ ****************
-- 繰り返しオプション - インデックスのヒストグラムのみを再分析します
-- ヒストグラムを持つ
--
-- 最初の分析に続いて、毎週の分析
-- ジョブは「繰り返し」を使用します” オプション。repeat オプション
は、インデックスが変更されていないことを dbms_stats に通知し、 --ヒストグラムを持つインデックス
のみを再分析します--**************** **************************************************開始dbms_stats.gather_schema_stats( ownname => 'SCOTT',
Estimate_percent => dbms_stats.auto_sample_size,
method_opt => 'すべての列のサイズを繰り返します',
degree => 7);
終わり;
Oracleのテーブルに関する統計情報はデータ ディクショナリにあり、 SQLでクエリできます。
これは、コマンドとツールキットの要約です。
1.分割されたテーブルの場合、 Analyzeステートメントの代わりにDBMS_STATS を使用することをお勧めします。a)並列に実行できます。複数のユーザー、複数のテーブルに対してb)パーティション テーブル全体のデータと単一のパーティションのデータを取得できます。c)さまざまなレベルで統計を計算できます: 単一パーティション、サブパーティション、テーブル全体、すべてのパーティションd )統計はダンプできますe )ユーザーは自動的に統計を収集できます2 、DBMS_STATSの欠点a)構造を検証できないb) CHAINED ROWSを収集できない、 CLUSTER TABLE情報を収集できない、これら 2 つはまだAnalyzeステートメントを使用する必要があります。c) DBMS_STATS は、デフォルトではインデックスを分析しません。
CascadeはFalseであり、 True 3として手動で指定する必要があります。External Tableの場合、Analyze は使用できず、DBMS_STATSのみを使用して情報を収集できます。
GATHER_TABLE_STATS （存储手順定义）
==========================
DBMS_STATS.gather_table_stats
(ownname varchar2,
tabname varchar2,
partname varchar2 default null,
assessment_percent number default to_estimate_percent_type(get_param('ESTIMATE_PERCENT'))、
block_sample boolean デフォルト FALSE、
method_opt varchar2 デフォルト get_param('METHOD_OPT')、
度数 デフォルト to_degree_type(get_param('DEGREE'))、
粒度 varchar2 デフォルト get_param('GRANULARITY')、
cascade ブールデフォルト to_cascade_type(get_param('CASCADE')),
stattab varchar2 デフォルト null, statid varchar2 デフォルト null,
statown varchar2 デフォルト null,
no_invalidate boolean デフォルト to_no_invalidate_type(get_param('NO_INVALIDATE')),
stattype varchar2 default 'DATA',
force boolean default FALSE);
パラメータの説明: ownname :
分析対象のテーブルの所有者tabname :分析
対象のテーブルの名前partname :パーティションの名前。値の範囲[0.000001, 100]、Nullはすべて分析、サンプリングなし定数: DBMS_STATS.AUTO_SAMPLE_SIZEはデフォルト値であり、オラクルが最適なサンプリング値を決定します. block_sapmple:行サンプリングの代わりにブロック サンプリングを使用するかどうか. method_opt:方法を決定しますヒストグラム情報がカウントされますMethod_opt値は次のとおりです:すべての列について:すべての列をカウントします
ヒストグラム.
すべてのインデックス付きの列:すべてのインデックス付きの列のヒストグラムをカウントします.すべての非表示の列:表示できない列のヒストグラムをカウントしますfor 列 <list> SIZE <N> | REPEAT | AUTO | SKEWONLY:のヒストグラムをカウントします指定された列.N [1,254]の値の範囲; R EPEAT最後の統計ヒストグラム; AUTO はオラクルによってNのサイズを決定します; SKEWONLY 同じ値を持つ複数のエンドポイント。degree:設定 統計を収集するための並列処理の度合い.デフォルトはnull です.
粒度: 収集する統計の粒度, テーブルがパーティション化されている場合にのみ適切.
cascade:インデックス情報を収集する.デフォルトはfalse.
stattabは統計を格納するテーブルを指定します. statid複数のテーブルの統計が同じに格納されている場合stattabに使用されます区別. Statown は統計情報テーブルの所有者を格納します.上記の 3 つのパラメータが指定されていない場合,統計情報は直接データ ディクショナリに更新されます.
no_invalidate: TRUE に設定すると依存カーソルを無効にしません. このプロシージャは、
force:テーブルがロックされていても統計を収集します。
例子:
execute dbms_stats.gather_table_stats(ownname => 'owner',
tabname => 'table_name' ,
assessment_percent => null ,
method_opt => 'for all indexed columns' ,
cascade => true);
GATHER_INDEX_STATS
=========================
BEGIN
SYS.DBMS_STATS.GATHER_INDEX_STATS (OwnName => 'ABC',
IndName => 'IDX_FUNC_ABC',
Estimate_Percent = > 10、
程度 => SYS.DBMS_STATS.DEFAULT_DEGREE、
No_Invalidate => FALSE);
終わり;
------------------------------------------------------
10g統計を自動収集
------ - -------------------------------- 10g
以降、Oracle はデータベースの構築後にGATHER_STATS_JOBという名前のデフォルトを作成しました。スケジュールされたタスクは次のとおりです。CBO統計を自動的に収集するために使用されます。この自動タスクは、デフォルトで、平日は午後 10 時から午後6 時まで、週末は終日オンになります。DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROCをコールして統計を収集します。このプロセスでは、最初に統計が欠落しており、古いオブジェクトが検出されます。次に、優先順位を付けてカウントを開始します。
SELECT * FROM Dba_Scheduler_Jobs WHERE Job_Name = 'GATHER_STATS_JOB';実際、10 :00に実行されるAUTO_SPACE_ADVISOR_JOBもあります。
JOB_NAME LAST_START_DATE
------------------------------ ------------------ ------------------
AUTO_SPACE_ADVISOR_JOB 30-OCT-08 10.00.01.463000 PM +08:00
GATHER_STATS_JOB 30-OCT-08 10.00.01.463000 PM +08:00
ただし、この自動化機能は多くのシステムの通常の運用に影響を与えており、ほとんどの運用システムでは夜の10時はアイドル時間ではありません。
自動分析により、非常に深刻なラッチ競合が発生し、データベースのハングまたはクラッシュが発生する可能性があります。
したがって、この統計情報の自動収集機能をオフにすることをお勧めします:
自動収集機能をオフにして開くには、次の 2 つの方法があります:
方法 1:
exec dbms_scheduler.disable('SYS.GATHER_STATS_JOB')
; enable('SYS.GATHER_STATS_JOB');
方法 2:
alter system set "_optimizer_autostats_job"=false scope=spfile;
alter system set "_optimizer_autostats_job"=true scope=spfile;
---------------------------------------
統計を見る
---------- ------------------------------
DBA_TABLES DBA_OBJECT_TABLES DBA_TAB_STATISTICS DBA_TAB_COL_STATISTICS DBA_TAB_HISTOGRAMS DBA_INDEXES DBA_IND_STATISTICS DBA_CLUSTERS DBA_TAB_PARTITIONS DBA_TAB_SUBPARTITIONS DBA_IND_PARTITIONS DBA_IND_SUBPARTITIONS _ _ _ _ DBA_PART_C OL_STATISTICS DBA_PART_HISTOGRAMS DBA_SUBPART_COL_STATISTICS DBA_SUBPART_HISTOGRAMS ------------------------------------------ヒストグラム統計---- - ----------------------------------ヒストグラムの種類は
* TAB_COL_STATISTICS ビューのHISTOGRAM列。
-------------------------------------------------- ----------------------------
bde_last_analyzed.sql - CBO 統計の検証
--------------- -------------------------------------------------- -------------
bde_last_analyzed.sql は、すべてのテーブル、インデックス、およびパーティションについて、データ ディクショナリ内の CBO 統計を検証します。また、'SYS' が所有するテーブルとインデックスの統計も検証します。
生成された 5 つのレポート bde_last_analyzed_xxx.html は、モジュールごとおよび日付ごとに分析されたテーブルとインデックスの合計を示します。
脚本。このノートで提供される bde_last_analyzed.sql は、Oracle Apps 11i および R12 インスタンスを含む、8i、9i、10g、11g 以降のデータベースで使用できます。
ERPデータベースの場合はAPPSに接続します。それ以外の場合は、 SYS権限を持つ他のユーザーと接続できます#sqlplus <user>/<pwd> SQL> START bde_last_analyzed.sql
スプール出力ファイル bde_last_analyzed_xxx.html ファイルを確認します。スプール ファイルは、このスクリプトと同じディレクトリに作成されます。実行されます。NT では、$ORACLE_HOME/bin の下にファイルが作成される場合があります。
一部のモジュールが分析されていない場合、または最近分析されていない場合、これらの Apps オブジェクトは FND_STATS または coe_stats.sql (Oracle Apps に属している場合) を使用して分析する必要があります。それ以外の場合は、DBMS_STATS を使用してください。
Oracle Apps の場合は、推定 10% で対応するコンカレント プログラムを使用するか、SQL*Plus から同等の FND_STATS プロシージャを実行します。
SQL> exec fnd_stats.gather_schema_statistics('APPLSYS'); 「APPLSYS」は、新しい統計が必要なモジュール (スキーマ) です。
統計を収集する必要がある表が少ない場合は、対応するコンカレント・プログラムを使用して表ごとに統計を収集するか、SQL*Plus から同等の FND_STATS プロシージャを実行します
。
ここで、'MRP' はスキーマ所有者、'MRP_FORECAST_DATES' はテーブル名です。この構文は、パーティション分割されていないテーブル専用です。
パーティション化されたテーブルでグローバル統計を再構築する必要がある場合、ある時点で PARTITION の粒度を使用してテーブルの統計を収集したことが原因です。以下の 2 番目の方法を参照して
ください
。
fnd_stats.gather_table_stats (所有者名 => 'APPLSYS'、タブ名 => 'WF_ITEM_ACTIVITY_STATUSES'、
粒度 => 'DEFAULT');
終わり;
/
統計を修正したら、パーティション分割されたテーブルには常に DEFAULT の粒度を使用してください。
この bde_last_analyzed.sql スクリプトを実行する場合。1 つのスキーマのみに対して、DEF SCHEMA コード行を変更します。
------------------------------------------
パーティションテーブルの統計情報例
-- --- -------------------------------
ORATEA ORACLE統計は、SQLロールの実行プロセスにおいて非常に重要な役割を果たします。ORACLEは、テーブルの各レベルで異なる統計情報を持ち、テーブルと列のさまざまな統計情報を記述します。複合パーティション テーブルを使用して、いくつかの一般的な統計を以下に示します。
SQL>
create table test
partition by range(object_id)
subpartition by hash(object_type) subpartitions 4
(パーティション p1 の値が (10000) 未満、
パーティション p2 の値が (20000) 未満、
パーティション p3 の値が (30000) 未満、
パーティション p4 の値) less than(maxvalue))
as
select * from dba_objects;
表已创建。_ _ _ _ _ ALL',カスケード => TRUE); 終わり;
1、表レベルの統計
SQL> select table_name,num_rows,blocks,empty_blocks,avg_space from user_tables where table_name = 'TEST';
TABLE_NAME NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE
------------------------------ ---------- ----- ----- ------------ ----------
TEST5070578800
2、表に記載されている統計情報
SQL> select table_name,column_name,num_distinct,density from user_tab_columns where table_name = 'TEST';
TABLE_NAME COLUMN_NAMENUM_DISTINCTDENSITY
------------------------------ ------------------ ------------ ------------ ----------
テスト所有者 25 .365014295
テスト オブジェクト名 30275 .000039205
テスト サブオブジェクト名 191 .015657993
テスト オブジェクト ID 50705 .000019722
TEST DATA_OBJECT_ID 4334 .000248075
TEST OBJECT_TYPE42 .271207855
TEST CREATED2305 .001608457
TEST LAST_DDL_TIME2369 .001566737
TEST TIMESTAMP2412 .00161025 1
TEST STATUS2 .000009861
TEST TEMPORARY 2 .000009861
TEST GENERATED 2 .000009861
TEST SECONDARY 2 .000009861
13 行が選択されました。
3、表に記載されているヒストグラム情報
SQL>
select table_name,column_name,endpoint_number,endpoint_value
from user_tab_histograms
where table_name = 'TEST'
and column_name = 'OBJECT_ID';
TABLE_NAME COLUMN_NAM ENDPOINT_NUMBER ENDPOINT_VALUE
---------- ---------- --------------- ----------- ---
TEST OBJECT_ID02
TEST OBJECT_ID1 5160
TEST OBJECT_ID210587
TEST OBJECT_ID315658
TEST OBJECT_ID420729
TEST OBJECT_ID525800
TEST OBJECT_ID630870
TEST OBJECT_ID735940 TEST OBJECT_ID8410 89
テスト OBJECT_ID946821
テスト
OBJECT_ID 1053497
4、パーティションの統計
SQL>
select partition_name,num_rows,blocks,empty_blocks,avg_space
from user_tab_partitions
where table_name = 'TEST';
PARTITION_NAMENUM_ROWS ブロック EMPTY_BLOCKS AVG_SPACE
------- ---------- ---------- ----------- - ----------
P1958114000
P2997316400
P3 1000015800
P4 2115132600
5、パーティションにリストされた統計
SQL> select column_name,num_distinct,density,num_nulls
from user_part_col_statistics
where table_name = 'TEST'
and partition_name = 'P1';
COLUMN_NAME NUM_DISTINCTDENSITY NUM_NULLS
--------------- ------------ ---------- ----------
OWNER7 .0000521870
OBJECT_NAME 7412 .0001569250
SUBOBJECT_NAME26 .47017301 9496
OBJECT_ID 9581 .0001043730
DATA_OBJECT_ID1765 .000664385 7780
OBJECT_TYPE 34 .184948540
CREATED913 .0019774490
LAST_DDL_TIME994 .0018826950
TIMESTAMP982 .0019287750
STATUS 2 .0000521870
TEMPORARY2 .0000521870
GENERATED2 .0000521870
SECONDARY1 .0000521870
6、パーティションにリストされているヒストグラム情報
SQL> select column_name,bucket_number,endpoint_value
from user_part_histograms
where table_name = 'TEST'
and partition_name = 'P1'
and column_name = 'OBJECT_ID';
COLUMN_NAME BUCKET_NUMBER ENDPOINT_VALUE
--------------- ------------- --------------
OBJECT_ID 02
OBJECT_ID 1 1005
OBJECT_ID 2 1963
OBJECT_ID 3 2921
OBJECT_ID 4 3888
OBJECT_ID 5 4859
OBJECT_ID 6 5941
OBJECT_ID 7 6899
OBJECT_ID 8 7885
OBJECT_ID 9 8864
OBJECT_ID10 9999
7、サブパーティションの統計
SQL> select subpartition_name,num_rows,blocks,empty_blocks
from user_tab_subpartitions
where table_name = 'TEST'
and partition_name = 'P1';
SUBPARTITION_NAMENUM_ROWS ブロック EMPTY_BLOCKS
------------------------------ ---------- ------- --- ------------
SYS_SUBP21 3597 500
SYS_SUBP22 3566 520
SYS_SUBP23637 110
SYS_SUBP24 1781 270
8、サブパーティションの列の統計
SQL> select column_name,num_distinct,density
from user_subpart_col_statistics
where table_name = 'TEST'
and subpartition_name = 'SYS_SUBP21';
COLUMN_NAME NUM_DISTINCTDENSITY
--------------- ------------ ----------
OWNER6 .000139005
OBJECT_NAME 3595 .000278319
SUBOBJECT_NAME 4 .014285714
OBJECT_ID 3597 .000278009
DATA_OBJECT_ID 155 .006451613
OBJECT_TYPE8 .000139005
CREATED751 .002392334
LAST_DDL_TIME784 .002302524
TIMESTAMP768 .00235539
ステータス 1 .000139005
TEMPORARY2 .000139005
GENERATED2 .000139005
SECONDARY1 .000139005
9、サブパーティション上の列のヒストグラム情報
SQL> select column_name,bucket_number,endpoint_value
from user_subpart_histograms
where table_name = 'TEST'
and subpartition_name = 'SYS_SUBP21'
and column_name = 'OBJECT_ID';
COLUMN_NAME BUCKET_NUMBER ENDPOINT_VALUE
--------------- ------------- --------------
OBJECT_ID 0208
OBJECT_ID 1 1525
OBJECT_ID 2 2244
OBJECT_ID 3 2892
OBJECT_ID 4
3252 OBJECT_ID 5
4047 OBJECT_ID 6 5238
OBJECT_ID 7 6531
OBJECT_ID 8 7661
OBJECT_ID 9 8474
OBJECT_ID10 9998
この複合パーティションを分析した後、上記の 9 つの異なるレベルの統計情報を生成しました。CBO は、効率的な実行計画のために非常に多くの統計を取得したいと考えています。