Oracle 分析及动态采样
之前在說Oracle Optimizer中的CBO時講到，當表沒有做分析的時候，Oracle 會使用動態采樣來收集統計信息。 獲取準確的段對象（表，表分區，索引等）的分析數據，是CBO存在的基石，CBO的機制就是收集盡可能多的對象信息和系統信息，通過對這些信息進行計算，分析，評估，最終得出一個成本最低的執行計劃。 所以對于CBO，數據段的分析就非常重要。
?
Oracle Optimizer CBO RBO
http://blog.csdn.net/tianlesoftware/archive/2010/08/19/5824886.aspx
?
一．???????? 先演示一個示例，來理解分析的作用
?
1.1創建表
SQL> create table t as select object_id,object_name from dba_objects where 1=2;
表已創建。
SQL> create index index_t on t(object_id);
索引已創建。
SQL> insert into t select object_id,object_name from dba_objects;
已創建72926行。
SQL> commit;
提交完成。
?
1.2查看分的分析及執行計劃
SQL> select num_rows,avg_row_len,blocks,last_analyzed from user_tables where table_name='T';
? NUM_ROWS AVG_ROW_LEN???? BLOCKS LAST_ANALYZED
---------- ----------- ---------- --------------
?
SQL> select blevel,leaf_blocks,distinct_keys,last_analyzed from user_indexes where table_name='T';
??? BLEVEL LEAF_BLOCKS DISTINCT_KEYS LAST_ANALYZED
---------- ----------- ------------- --------------
????? ???0?????????? 0???????????? 0 25-8月 -10
?
從查詢結果看出，表的行數，行長，占用的數據塊數及最后的分析時間都是空。 索引的相關信息也沒有，說明這個表和說因都沒有被分析，如果此時有一條SQL 對表做查詢，CBO 由于無法獲取這些信息，很可能生成錯誤的執行計劃，如：
?
SQL> set linesize 200
SQL> set autot trace exp;
SQL> select /*+dynamic_sampling(t 0) */ * from t where object_id>30;
執行計劃
----------------------------------------------------------
Plan hash value: 80339723
?
---------------------------------------------------------------------------------------
| Id? | Operation?????????????????? | Name??? | Rows? | Bytes | Cost (%CPU)| Time???? |
---------------------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT??????????? |???????? |???? 4 |?? 316 |???? 0?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS BY INDEX ROWID| T?????? |???? 4 |?? 316 |???? 0?? (0)| 00:00:01 |
|*? 2 |?? INDEX RANGE SCAN????????? | INDEX_T |???? 1 |?????? |???? 0?? (0)| 00:00:01 |
---------------------------------------------------------------------------------------
?
Predicate Information (identified by operation id):
---------------------------------------------------
?? 2 - access("OBJECT_ID">30)
SQL>
?
在Oracle 10g以后，如果一個表沒有做分析，數據庫將自動對它做動態采樣分析，所以這里采用hint的方式將動態采樣的級別設置為0，即不使用動態采樣。
?
???????? 從這個執行計劃，看書CBO 估計出表中滿足條件的記錄為4條，索引使用了索引。 我們對表做一下分析，用結果比較一下。
?
1.3 分析表及查看分析之后的執行計劃
分析可以通過兩中方式：
一種是analyze 命令，如：
analyze table tablename compute statistics for all indexes;
???????? 還有一種就是通過DBMS_STATS包來分析，從9i 開始，Oracle 推薦使用DBMS_STATS包對表進行分析操作，因為DBMS_STATS 提供了更多的功能，以及靈活的操作方式。
????????
SQL> exec dbms_stats.gather_table_stats('SYS','T');
PL/SQL 過程已成功完成。
SQL> select blevel,leaf_blocks,distinct_keys,last_analyzed from user_indexes where table_name='T';
??? BLEVEL LEAF_BLOCKS DISTINCT_KEYS LAST_ANALYZED
---------- ----------- ------------- --------------
???????? 1???????? 263???????? 72926 25-8月 -10
SQL> select num_rows,avg_row_len,blocks,last_analyzed from user_tables where table_name='T';
? NUM_ROWS AVG_ROW_LEN???? BLOCKS LAST_ANALYZED
---------- ----------- ---------- --------------
???? 72926????????? 29??????? 345 25-8月 -10
?
從上面的結果，可以看出DBMS_STATS.gather_table_stats已經對表和索引都做了分析。 現在我們在來看一下執行計劃。
?
SQL> set autot trace exp;
SQL> select * from t where object_id>30;
執行計劃
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? | 72899 |? 2064K|??? 96?? (2)| 00:00:02 |
|*? 1 |? TABLE ACCESS FULL| T??? | 72899 |? 2064K|??? 96?? (2)| 00:00:02 |
--------------------------------------------------------------------------
?
Predicate Information (identified by operation id):
---------------------------------------------------
?
?? 1 - filter("OBJECT_ID">30)
?
從這個計劃，我們看出CBO 估算出的結果是72899 條記錄，與實際的72926很近。 此時選擇全表掃描更優。 通過這個例子，我們也看出了分析對執行計劃的重要性。
?
?
二．???????? 直方圖（Histogram）
DBMS_STATS 包對段表的分析有三個層次：
（1）表自身的分析： 包括表中的行數，數據塊數，行長等信息。
（2）列的分析：包括列值的重復數，列上的空值，數據在列上的分布情況。
（3）索引的分析： 包括索引葉塊的數量，索引的深度，索引的聚合因子等。
?
直方圖就是 列分析中 數據在列上的分布情況。
?
???????? 當Oracle 做直方圖分析時，會將要分析的列上的數據分成很多數量相同的部分，每一部分稱為一個bucket,這樣CBO就可以非常容易地知道這個列上的數的分布情況，這種數據的分布將作為一個非常重要的因素納入到執行計劃成本的計算當中。
?
???????? 對于數據分布非常傾斜的表，做直方圖是非常有用的。 如： 1,10,20,30,40,50. 那么在一個數值范圍（bucket）內，它的數據記錄基本上一樣。 如果是：1,5,5,5,5,10,10,20,50,100. 那么它在bucket內，數據分布就是嚴重的傾斜。
?
???????? 直方圖有時對于CBO非常重要，特別是對于有字段數據非常傾斜的表，做直方圖分析尤為重要。 可以用dbms_stats包來分析。 默認情況下，dbms_stats 包會對所有的列做直方圖分析。 如：??
???????? SQL> exec dbms_stats.gather_table_stats('SYS','T',cascade=>true);
PL/SQL 過程已成功完成。
?
然后從user_histograms視圖上查看到相關的信息：
?
SQL> select table_name,column_name,endpoint_number,endpoint_value from user_histograms where table_name='T';
TABLE_NAME???????????????????? COLUMN_NAME????????? ENDPOINT_NUMBER ENDPOINT_VALUE
------------------------------ -------------------- --------------- --------------
T????? ????????????????????????OBJECT_ID????????????????????????? 0????????????? 2
T????????????????????????????? OBJECT_NAME??????????????????????? 0???? 2.4504E+35
T????????????????????????????? OBJECT_ID????????????????????????? 1????????? 76685
T???????????? ?????????????????OBJECT_NAME??????????????????????? 1???? 1.0886E+36
?
如果一個列上的數據有比較嚴重的傾斜，對這個列做直方圖是必要的，但是，Oracle 對數據分析是需要消耗資源的，特別是對于一些很大的段對象，分析的時間尤其長。對于OLAP系統，可能需要幾個小時才能完成。
???????? 所以做不做分析就需要DBA 權衡好了。 但有一點要注意， 不要在生產環境中隨便修改分析方案，除非你有十足的把握。 否則可能導致非常嚴重的后果。
?
?
三．???????? DBMS_STATS包
DBMS_STAS包不僅能夠對表進行分析，它還可以對數據庫分析進行管理。 按照功能可以分一下幾類：
（1）?????? 性能數據的收集
（2）?????? 性能數據的設置
（3）?????? 性能數據的刪除
（4）?????? 性能數據的備份和恢
?
更多信息參考Oracle 聯機文檔：
11g DBMS_STATS
http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10577/d_stats.htm#ARPLS68486
?
10g DBMS_STATS
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461
?
?
3.1 ?DBMS_STATS包的幾個常用功能：性能的手機，設定 和刪除
???????? 性能數據的收集包含這樣幾個存儲過程：
GATHER_DATABASE_STATS Procedures
GATHER_DICTIONARY_STATS Procedure
GATHER_FIXED_OBJECTS_STATS Procedure
GATHER_INDEX_STATS Procedure
GATHER_SCHEMA_STATS Procedures
GATHER_SYSTEM_STATS Procedure
GATHER_TABLE_STATS Procedure
?
從名字也可以看出各自的作用，這些存儲過程用來收集數據庫不同級別對象的性能數據，包括：數據庫，數據字典，表，索引，SCHEMA的性能等。
?
3.1.1? GATHER_TABLE_STATS Procedure 存儲過程
?
在10g中, GATHER_TABLE_STATS的參數如下：
DBMS_STATS.GATHER_TABLE_STATS (
?? ownname????????? VARCHAR2,
?? tabname????????? VARCHAR2,
?? partname???????? VARCHAR2 DEFAULT NULL,
?? estimate_percent NUMBER?? DEFAULT to_estimate_percent_type
??????????????????????????????????????????????? (get_param('ESTIMATE_PERCENT')),
?? block_sample???? BOOLEAN? DEFAULT FALSE,
?? method_opt?????? VARCHAR2 DEFAULT get_param('METHOD_OPT'),
?? degree?????????? NUMBER?? DEFAULT to_degree_type(get_param('DEGREE')),
?? granularity????? VARCHAR2 DEFAULT GET_PARAM('GRANULARITY'),
?? cascade????????? BOOLEAN? DEFAULT to_cascade_type(get_param('CASCADE')),
?? stattab????????? VARCHAR2 DEFAULT NULL,
?? statid?????????? VARCHAR2 DEFAULT NULL,
?? statown????????? VARCHAR2 DEFAULT NULL,
?? no_invalidate??? BOOLEAN? DEFAULT? to_no_invalidate_type (
???????????????????????????????????? get_param('NO_INVALIDATE')),
?? force??????????? BOOLEAN DEFAULT FALSE);
?
到了11g，對參數做了調整：
???????? DBMS_STATS.GATHER_TABLE_STATS (
?? ownname????????? VARCHAR2,
?? tabname????????? VARCHAR2,
?? partname???????? VARCHAR2 DEFAULT NULL,
?? estimate_percent NUMBER?? DEFAULT to_estimate_percent_type
??????????????????????????????????????? ????????(get_param('ESTIMATE_PERCENT')),
?? block_sample???? BOOLEAN? DEFAULT FALSE,
?? method_opt?????? VARCHAR2 DEFAULT get_param('METHOD_OPT'),
?? degree?????????? NUMBER?? DEFAULT to_degree_type(get_param('DEGREE')),
?? granularity????? VARCHAR2 DEFAULT GET_PARAM('GRANULARITY'),
?? cascade????????? BOOLEAN? DEFAULT to_cascade_type(get_param('CASCADE')),
?? stattab????????? VARCHAR2 DEFAULT NULL,
?? statid?????????? VARCHAR2 DEFAULT NULL,
?? statown????????? VARCHAR2 DEFAULT NULL,
?? no_invalidate??? BOOLEAN? DEFAULT? to_no_invalidate_type (
???????????????????????????????????? get_param('NO_INVALIDATE')),
?? force??????????? BOOLEAN DEFAULT FALSE);
?
對參數的說明：
Parameter | Description |
ownname | Schema of table to analyze |
tabname | Name of table |
partname | Name of partition |
estimate_percent | Percentage of rows to estimate (NULL means compute) The valid range is [0.000001,100]. Use the constant DBMS_STATS.AUTO_SAMPLE_SIZE to have Oracle determine the appropriate sample size for good statistics. This is the default.The default value can be changed using the SET_PARAM Procedure. |
block_sample | Whether or not to use random block sampling instead of random row sampling. Random block sampling is more efficient, but if the data is not randomly distributed on disk, then the sample values may be somewhat correlated. Only pertinent when doing an estimate statistics. |
method_opt | Accepts: FOR ALL [INDEXED | HIDDEN] COLUMNS [size_clause] FOR COLUMNS [size clause] column|attribute [size_clause] [,column|attribute [size_clause]...] size_clause is defined as size_clause := SIZE {integer | REPEAT | AUTO | SKEWONLY}
The default is FOR ALL COLUMNS SIZE AUTO.The default value can be changed using the SET_PARAM Procedure. |
degree | Degree of parallelism. The default for degree is NULL. The default value can be changed using the SET_PARAM Procedure NULL means use the table default value specified by the DEGREE clause in the CREATE TABLE or ALTER TABLE statement. Use the constant DBMS_STATS.DEFAULT_DEGREE to specify the default value based on the initialization parameters. The AUTO_DEGREE value determines the degree of parallelism automatically. This is either 1 (serial execution) or DEFAULT_DEGREE (the system default value based on number of CPUs and initialization parameters) according to size of the object. |
granularity | Granularity of statistics to collect (only pertinent if the table is partitioned). 'ALL' - gathers all (subpartition, partition, and global) statistics 'AUTO'- determines the granularity based on the partitioning type. This is the default value. 'DEFAULT' - gathers global and partition-level statistics. This option is obsolete, and while currently supported, it is included in the documentation for legacy reasons only. You should use the 'GLOBAL AND PARTITION' for this functionality. Note that the default value is now 'AUTO'. 'GLOBAL' - gathers global statistics 'GLOBAL AND PARTITION' - gathers the global and partition level statistics. No subpartition level statistics are gathered even if it is a composite partitioned object. 'PARTITION '- gathers partition-level statistics 'SUBPARTITION' - gathers subpartition-level statistics. |
cascade | Gather statistics on the indexes for this table. Index statistics gathering is not parallelized. Using this option is equivalent to running the GATHER_INDEX_STATS Procedure on each of the table's indexes. Use the constant DBMS_STATS.AUTO_CASCADE to have Oracle determine whether index statistics to be collected or not. This is the default. The default value can be changed using theSET_PARAM Procedure. |
stattab | User statistics table identifier describing where to save the current statistics |
statid | Identifier (optional) to associate with these statistics within stattab |
statown | Schema containing stattab (if different than ownname) |
no_invalidate | Does not invalidate the dependent cursors if set to TRUE. The procedure invalidates the dependent cursors immediately if set to FALSE. Use DBMS_STATS.AUTO_INVALIDATE. to have Oracle decide when to invalidate dependent cursors. This is the default. The default can be changed using the SET_PARAM Procedure. |
force | Gather statistics of table even if it is locked |
?
?
在gather_table_stats 存儲過程的所有參數中，除了ownname和tabname，其他的參數都有默認值。 所以我們在調用這個存儲過程時，Oracle 會使用參數的默認值對表進行分析。如：
SQL> exec dbms_stats.gather_table_STATS('SYS','T');
PL/SQL 過程已成功完成。
?
???????? 如果想查看當前的默認值，可以使用dbms_stats.get_param函數來獲取：
?
SQL> select dbms_stats.get_param('method_opt') from dual;
?
DBMS_STATS.GET_PARAM('METHOD_OPT')
------------------------------------------------------------
FOR ALL COLUMNS SIZE AUTO
?
結合上面對參數的說明：
???? - AUTO : Oracle determines the columns to collect histograms based on data distribution and the workload of the columns.
我們可以看出，就是對所有的列做直方圖分析，直方圖設置的bucket值由Oracle自己決定。
?
3.1.1.1? estimate_percent 參數
???????? 這個參數是一個百分比值，它告訴分析包需要使用表中數據的多大比例來做分析。
????????
理論上來講，采樣的數據越多，得到的信息就越接近于實際，CBO做出的執行計劃就越優化，但是，采樣越多，消耗的系統資源必然越多。 對系統的影響也越大。 所以對于這個值的設置，要根據業務情況來。 如果數據的直方圖分布比較均勻，就可以使用默認值：AUTO_SAMPLE_SIZE，即讓Oracle 自己來判斷采樣的比例。有時，特別是對于批量加載的表，我們可以預估表中的數據量，可以人工地設置一個合理的值。 一般，對于一個有1000萬數據的表分區，可以把這個參數設置為0.000001.
?
3.1. 1.2 ?Method_option 參數
???????? 這個參數用來定義直方圖分析的一些值。
FOR ALL [INDEXED | HIDDEN] COLUMNS [size_clause]
FOR COLUMNS [size clause] column|attribute [size_clause] [,column|attribute [size_clause]...]
?
???????? 這里給出了4種指定哪些列進行分析的方式：
（1）?????? 所有列：for all column
（2）?????? 索引列：只對有索引的列進行分析，for all indexed columns
（3）?????? 影藏列：只對影藏的列進行分析，for all hidden columns
（4）?????? 顯示指定列：顯示的指定那些列進行分析，for columns columns_name
?
該參數默認值：for all columns size auto.
????????
3.1. 1.3 degree 參數
用來指定分析時使用的并行度。 有以下這些設置：
(1)???? Null： 如果設置為null，Oracle 將使用被分析表屬性的并行度，比如表在創建時指定的并行度，或者后者使用alter table 重新設置的并行度。
(2)???? 一個數值： 可以顯示地指定分析時使用的并行度。
(3)???? Default_degree: 如果設置為default，Oracle 將根據初始化參數中相關參數的設置來決定使用的并行度。
?
這個參數的默認值是Null，即通過表上的并行度屬性來決定分析使用的并行度。 當需要分析的表或表分區非常大，并且系統資源比較充分的時候，就可以考慮使用并行的方式來做分析，這樣就會大大提高分析的速度。 相反，如果你的系統資源比較吃緊，那么啟用并行可能會適得其反。
?
3.1. 1.4 Granularity
分析的粒度，有以下幾個配置：
（1）?????? ALL : 將會對表的全局（global），分區，子分區的數據都做分析
（2）?????? AUTO: Oracle 根據分區的類型，自動決定做哪一種粒度的分析。
（3）?????? GLOBAL：只做全局級別的分析。
（4）?????? GLOBAL AND PARTITION: 只對全局和分區級別做分析，對子分區不做分析，這是和ALL的一個區別。
（5）?????? PARTITION: 只在分區級別做分析。
（6）?????? SUBPARTITION: 只在子分區做分析。
?
在生產環境中，特別是OLAP 或者數據倉庫的環境中，這個參數的設置會直接影響到CBO的執行計劃選擇。
?
在OLAP或者數據倉庫系統中，經常有這樣的事情，新創建一個分區，將批量的數據（通常是很大的數據）加載到分區中，對分區做分析，然后做報表或者數據挖掘。 在理想的情況下，對表的全局，分區都做分析，這樣才能得到最充足的數據，但是通常這樣的表都非常大，如果每增加一個分區都需要做一次全局分析，那么會消耗極大的系統資源。 但是如果只對新加入的分區進行分區而不做全局分析，oracle 在全局范圍內的信息就會不準確。
?
???????? 該參數在默認情況下，DBMS_STATS 包會對表級（全局），分區級（對應參數partition）都會進行分析。 如果把cascade 設置為true，相應索引的全局和分區級別也都會被分析。 如果只對分區級進行分析，而全局沒有分析，那么全局信息沒有更新，依然會導致CBO 作出錯誤的執行計劃。
?
所以當一些新的數據插入到表中時，如果對這些新的數據進行分析，是一個非常重要的問題。 一般參考如下原則：
（1）?????? 看一下新插入的數據在全表中所占的比例，如果所占比例不是很大，那么可以考慮不做全局分析，否則就需要考慮，一句是業務的實際運行情況。
（2）?????? 采樣比例。 如果載入的數據量非常大，比如上千萬或者更大，就要把采樣比例壓縮的盡可能地小，但底線是不能影響CBO做出正確的執行計劃，采樣比例的上線是不能消耗太多的資源而影響到業務的正常運行。
（3）?????? 新加載的數據應該要做分區級的數據分析。 至于是否需要直方圖分析，以及設置多少個buckets（size參數指定），需要DBA一句數據的分布情況進行考慮，關鍵是視數據的傾斜程度而定。
?
?
3.1.2 ?GATHER_SCHEMA_STATS 存儲過程
???????? 這個存儲過程用于對某個用戶下所有的對象進行分析。如果你的數據用戶對象非常多，單獨對每個對象進行分析設定會非常不方便，這個存儲過程就很方便。 它的好處在于如果需要分析的對象非常多，將可以大大降低DBA的工作量，不足之處是所有分析使用相同的分析策略，可能會導致分析不是最優。 所以要根據實際情況來決定。
?
???????? 該存儲過程參數如下：
???????? DBMS_STATS.GATHER_SCHEMA_STATS (
?? ownname????????? VARCHAR2,
?? estimate_percent NUMBER?? DEFAULT to_estimate_percent_type
??????????????????????????????????????????????? (get_param('ESTIMATE_PERCENT')),
?? block_sample???? BOOLEAN? DEFAULT FALSE,
?? method_opt?????? VARCHAR2 DEFAULT get_param('METHOD_OPT'),
?? degree?????????? NUMBER?? DEFAULT to_degree_type(get_param('DEGREE')),
?? granularity????? VARCHAR2 DEFAULT GET_PARAM('GRANULARITY'),
?? cascade????????? BOOLEAN? DEFAULT to_cascade_type(get_param('CASCADE')),
?? stattab????????? VARCHAR2 DEFAULT NULL,
?? statid?????????? VARCHAR2 DEFAULT NULL,
?? options????????? VARCHAR2 DEFAULT 'GATHER',
?? objlist????????? OUT????? ObjectTab,
?? statown????????? VARCHAR2 DEFAULT NULL,
?? no_invalidate??? BOOLEAN? DEFAULT to_no_invalidate_type (
???????????????????????????????????? get_param('NO_INVALIDATE')),
? force???????????? BOOLEAN DEFAULT FALSE,
? obj_filter_list? ObjectTab DEFAULT NULL);
?
參數說明如下：
Parameter | Description |
ownname | Schema to analyze (NULL means current schema) |
estimate_percent | Percentage of rows to estimate (NULL means compute): The valid range is [0.000001,100]. Use the constant DBMS_STATS.AUTO_SAMPLE_SIZE to have Oracle determine the appropriate sample size for good statistics. This is the default.The default value can be changed using the SET_DATABASE_PREFS Procedure, SET_GLOBAL_PREFS Procedure, SET_SCHEMA_PREFS Procedure and SET_TABLE_PREFS Procedure. |
block_sample | Whether or not to use random block sampling instead of random row sampling. Random block sampling is more efficient, but if the data is not randomly distributed on disk, then the sample values may be somewhat correlated. Only pertinent when doing an estimate statistics. |
method_opt | Accepts: FOR ALL [INDEXED | HIDDEN] COLUMNS [size_clause] size_clause is defined as size_clause := SIZE {integer | REPEAT | AUTO | SKEWONLY}
The default is FOR ALL COLUMNS SIZE AUTO.The default value can be changed using the SET_DATABASE_PREFS Procedure, SET_GLOBAL_PREFS Procedure, SET_SCHEMA_PREFS Procedure and SET_TABLE_PREFS Procedure. |
degree | Degree of parallelism. The default for degree is NULL. The default value can be changed using the SET_DATABASE_PREFS Procedure, SET_GLOBAL_PREFS Procedure, SET_SCHEMA_PREFS Procedure and SET_TABLE_PREFS Procedure. NULL means use the table default value specified by the DEGREE clause in the CREATE TABLE or ALTER TABLE statement. Use the constant DBMS_STATS.DEFAULT_DEGREE to specify the default value based on the initialization parameters.The AUTO_DEGREE value determines the degree of parallelism automatically. This is either 1 (serial execution) or DEFAULT_DEGREE (the system default value based on number of CPUs and initialization parameters) according to size of the object. |
granularity | Granularity of statistics to collect (only pertinent if the table is partitioned). 'ALL' - gathers all (subpartition, partition, and global) statistics 'AUTO'- determines the granularity based on the partitioning type. This is the default value. 'DEFAULT' - gathers global and partition-level statistics. This option is obsolete, and while currently supported, it is included in the documentation for legacy reasons only. You should use the 'GLOBAL AND PARTITION' for this functionality. Note that the default value is now 'AUTO'. 'GLOBAL' - gathers global statistics 'GLOBAL AND PARTITION' - gathers the global and partition level statistics. No subpartition level statistics are gathered even if it is a composite partitioned object. 'PARTITION '- gathers partition-level statistics 'SUBPARTITION' - gathers subpartition-level statistics. |
cascade | Gather statistics on the indexes as well. Using this option is equivalent to running the GATHER_INDEX_STATS Procedure on each of the indexes in the schema in addition to gathering table and column statistics. Use the constant DBMS_STATS.AUTO_CASCADE to have Oracle determine whether index statistics to be collected or not. This is the default. The default value can be changed using the SET_DATABASE_PREFS Procedure, SET_GLOBAL_PREFS Procedure, SET_SCHEMA_PREFS Procedure and SET_TABLE_PREFS Procedure. |
stattab | User statistics table identifier describing where to save the current statistics |
statid | Identifier (optional) to associate with these statistics within stattab |
options | Further specification of which objects to gather statistics for: GATHER: Gathers statistics on all objects in the schema. GATHER AUTO: Gathers all necessary statistics automatically. Oracle implicitly determines which objects need new statistics, and determines how to gather those statistics. When GATHER AUTO is specified, the only additional valid parameters are ownname, stattab, statid, objlist and statown; all other parameter settings are ignored. Returns a list of processed objects. GATHER STALE: Gathers statistics on stale objects as determined by looking at the *_tab_modifications views. Also, return a list of objects found to be stale. GATHER EMPTY: Gathers statistics on objects which currently have no statistics. also, return a list of objects found to have no statistics. LIST AUTO: Returns a list of objects to be processed with GATHER AUTO. LIST STALE: Returns list of stale objects as determined by looking at the *_tab_modifications views. LIST EMPTY: Returns list of objects which currently have no statistics. |
objlist | List of objects found to be stale or empty |
statown | Schema containing stattab (if different than ownname) |
no_invalidate | Does not invalidate the dependent cursors if set to TRUE. The procedure invalidates the dependent cursors immediately if set to FALSE. Use DBMS_STATS.AUTO_INVALIDATE. to have Oracle decide when to invalidate dependent cursors. This is the default. The default can be changed using the SET_DATABASE_PREFS Procedure, SET_GLOBAL_PREFS Procedure, SET_SCHEMA_PREFS Procedure and SET_TABLE_PREFS Procedure. |
force | Gather statistics on objects even if they are locked |
obj_filter_list | A list of object filters. When provided, GATHER_SCHEMA_STATS will gather statistics only on objects which satisfy at least one object filter in the list as needed. In a single object filter, we can specify the constraints on the object attributes. The attribute values specified in the object filter are case- insensitive unless double-quoted. Wildcard is allowed in the attribute values. Suppose non-NULL values s1, s2, ... are specified for attributes a1, a2, ... in one object filter. An object o is said to satisfy this object filter if (o.a1 like s1) and (o.a2 like s2) and ... is true. See Applying an Object Filter List. |
?
?
3.1.3 ?DBMS_STATS.GATHER_INDEX_STATS 存儲過程
???????? 該存儲過程用于對索引的分析，如果我們在使用DBMS_STATS.GATHER_TABLES_STATS的分析時設置參數cascade=>true。 那么Oracle會同時執行這個存儲過程來對索引進行分析。
?
存儲過程參數：
DBMS_STATS.GATHER_INDEX_STATS (
?? ownname????????? VARCHAR2,
?? indname????????? VARCHAR2,
?? partname???????? VARCHAR2 DEFAULT NULL,
?? estimate_percent NUMBER?? DEFAULT to_estimate_percent_type
??????????????????????????????????????????????? (GET_PARAM('ESTIMATE_PERCENT')),
?? stattab????????? VARCHAR2 DEFAULT NULL,
?? statid?????????? VARCHAR2 DEFAULT NULL,
?? statown????????? VARCHAR2 DEFAULT NULL,
?? degree?????????? NUMBER?? DEFAULT to_degree_type(get_param('DEGREE')),
?? granularity????? VARCHAR2 DEFAULT GET_PARAM('GRANULARITY'),
?? no_invalidate??? BOOLEAN? DEFAULT to_no_invalidate_type
??????????????????????????????????????????? ???(GET_PARAM('NO_INVALIDATE')),
?? force??????????? BOOLEAN DEFAULT FALSE);
?
Parameter | Description |
ownname | Schema of index to analyze |
indname | Name of index |
partname | Name of partition |
estimate_percent | Percentage of rows to estimate (NULL means compute). The valid range is [0.000001,100]. Use the constant DBMS_STATS.AUTO_SAMPLE_SIZE to have Oracle determine the appropriate sample size for good statistics. This is the default.The default value can be changed using the SET_DATABASE_PREFS Procedure, SET_GLOBAL_PREFS Procedure, SET_SCHEMA_PREFS Procedure and SET_TABLE_PREFS Procedure. |
stattab | User statistics table identifier describing where to save the current statistics |
statid | Identifier (optional) to associate with these statistics within stattab |
statown | Schema containing stattab (if different than ownname) |
degree | Degree of parallelism. The default for degree is NULL. The default value can be changed using the SET_DATABASE_PREFS Procedure, SET_GLOBAL_PREFS Procedure, SET_SCHEMA_PREFS Procedure and SET_TABLE_PREFS Procedure. NULL means use of table default value that was specified by the DEGREE clause in the CREATE/ALTER INDEX statement. Use the constant DBMS_STATS.DEFAULT_DEGREE for the default value based on the initialization parameters. The AUTO_DEGREE value determines the degree of parallelism automatically. This is either 1 (serial execution) or DEFAULT_DEGREE (the system default value based on number of CPUs and initialization parameters) according to size of the object. |
granularity | Granularity of statistics to collect (only pertinent if the table is partitioned). 'ALL' - gathers all (subpartition, partition, and global) statistics 'AUTO'- determines the granularity based on the partitioning type. This is the default value. 'DEFAULT' - gathers global and partition-level statistics. This option is obsolete, and while currently supported, it is included in the documentation for legacy reasons only. You should use the 'GLOBAL AND PARTITION' for this functionality. Note that the default value is now 'AUTO'. 'GLOBAL' - gathers global statistics 'GLOBAL AND PARTITION' - gathers the global and partition level statistics. No subpartition level statistics are gathered even if it is a composite partitioned object. 'PARTITION '- gathers partition-level statistics 'SUBPARTITION' - gathers subpartition-level statistics. |
no_invalidate | Does not invalidate the dependent cursors if set to TRUE. The procedure invalidates the dependent cursors immediately if set to FALSE. Use DBMS_STATS.AUTO_INVALIDATE. to have Oracle decide when to invalidate dependent cursors. This is the default. The default can be changed using the SET_DATABASE_PREFS Procedure, SET_GLOBAL_PREFS Procedure, SET_SCHEMA_PREFS Procedure and SET_TABLE_PREFS Procedure. |
force | Gather statistics on object even if it is locked |
?
?
上面討論了三個常用的存儲過程。 分析對CBO 來說非常重要，如果不能按照自己的系統指定出切合實際的數據分析方案，可能會導致如下問題的發生：
（1）?????? 分析信息不充分導致CBO 產生錯誤的執行計劃，導致SQL執行效率低下。
（2）?????? 過多的分析工具帶來系統性能的嚴重下降。
?
?
?
3.2 ?DBMS_STATS包管理功能
3.2.1 獲取分析數據
GET_COLUMN_STATS Procedures
GET_INDEX_STATS Procedures
GET_SYSTEM_STATS Procedure
GET_TABLE_STATS Procedure
?
這四個存儲過程分別為用戶獲取字段，索引，表和系統的統計信息。 它的用法是首先定義要獲取性能指標的變量，然后使用存儲過程將性能指標的值賦給變量，最后將變量的值輸出。 ?如：
?
SQL> set serveroutput on
SQL> declare
? 2? dist number;
? 3? dens number;
? 4? ncnt number;
? 5? orec dbms_stats.statrec;
? 6? avgc number;
? 7? begin
? 8? dbms_stats.get_column_stats('SYS','T','object_ID',distcnt=>dist,density=>dens,nullcnt=>ncnt,srec=>orec,avgclen=>avgc);
? 9? dbms_output.put_line('the distcnt is:' ||to_char(dist));
?10? dbms_output.put_line('the density is:' ||to_char(dens));
?11? dbms_output.put_line('the nullcnt is:' ||to_char(ncnt));
?12? dbms_output.put_line('the srec is:' ||to_char(ncnt));
?13? dbms_output.put_line('the avgclen is:' ||to_char(avgc));
?14? end;
?15? /
the distcnt is:72926
the density is:.0000137125305103804
the nullcnt is:0
the srec is:0
the avgclen is:5
?
PL/SQL 過程已成功完成。
?
更多信息參考：
???????? http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461
?
3.2.2 設置分析數據
SET_COLUMN_STATS Procedures
SET_INDEX_STATS Procedures
SET_SYSTEM_STATS Procedure
SET_TABLE_STATS Procedure
?
這幾個存儲過程允許我們手工地為字段，索引，表和系統性能數據賦值。 它的一個用處是當相應的指標不準確導致執行計劃失敗時，可以使用這種方法手工地來為這些性能數據賦值。 在極端情況下，這也不失為一個解決問題的方法。
?
關于這4個存儲過程的絕提用法參考 oracle 聯機文檔：
???????? http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461
?
?
3.2.3 刪除分析數據
DELETE_COLUMN_STATS Procedure
DELETE_DATABASE_STATS Procedure
DELETE_DICTIONARY_STATS Procedure
DELETE_FIXED_OBJECTS_STATS Procedure
DELETE_INDEX_STATS Procedure
DELETE_SCHEMA_STATS Procedure
DELETE_SYSTEM_STATS Procedure
DELETE_TABLE_STATS Procedure
?
當性能數據出現異常導致CBO判斷錯誤時，為了立刻修正這個錯誤，刪除性能數據也是一種補救的方法，比如刪除了表的數據，讓CBO重新對表做動態采樣分析，得到一個正確的結果。
???????? 它可以刪除字段，數據庫，數據字典，基表，索引，表等級別的性能數據。
?
具體參考oracle 聯機文檔：
???????? http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461
?
3.2.4 保存分析數據
CREATE_STAT_TABLE Procedure
DROP_STAT_TABLE Procedure
????????
???????? 可以用這兩個存儲過程創建一個表，用于存放性能數據，這樣有利于對性能數據的管理，也可以刪除這個表。
?
具體參考oracle 聯機文檔：
???????? http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461
?
?
3.2.5 導入和導出分析數據
EXPORT_COLUMN_STATS Procedure
EXPORT_DATABASE_STATS Procedure
EXPORT_DICTIONARY_STATS Procedure
EXPORT_FIXED_OBJECTS_STATS Procedure
EXPORT_INDEX_STATS Procedure
EXPORT_SCHEMA_STATS Procedure
EXPORT_SYSTEM_STATS Procedure
EXPORT_TABLE_STATS Procedure
IMPORT_COLUMN_STATS Procedure
IMPORT_DATABASE_STATS Procedure
IMPORT_DICTIONARY_STATS Procedure
IMPORT_FIXED_OBJECTS_STATS Procedure
IMPORT_INDEX_STATS Procedure
IMPORT_SCHEMA_STATS Procedure
IMPORT_SYSTEM_STATS Procedure
IMPORT_TABLE_STATS Procedure
?
這些存儲過程可以將已經有的性能指標導入到用戶創建好的表中存放，需要時，可以從表中倒回來。
?
具體參考oracle 聯機文檔：
???????? http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461
?
?
3.2.6 鎖定分析數據
LOCK_SCHEMA_STATS Procedure
LOCK_TABLE_STATS Procedure
UNLOCK_SCHEMA_STATS Procedure
UNLOCK_TABLE_STATS Procedure
The LOCK_* procedures either freeze the current set of the statistics or to keep the statistics empty (uncollected).When statistics on a table are locked, all the statistics depending on the table, including table statistics, column statistics, histograms and statistics on all dependent indexes, are considered to be locked.
可能在某些時候，我們覺得當前的統計信息非常好，執行計劃很準確，并且表中數據幾乎不變化，那么可以使用LOCK_TABLE_STATS Procedure 來鎖定表的統計信息，不允許對表做分析或者設定分析數據。 當表的分析數據被鎖定之后，相關的所有分析數據，包括表級，列級，直方圖，索引的分析數據都將被鎖定，不允許被更新。
?
具體參考oracle 聯機文檔：
???????? http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461
?
?
3.2.7 分析數據的恢復
RESET_PARAM_DEFAULTS Procedure
RESTORE_DICTIONARY_STATS Procedure
RESTORE_FIXED_OBJECTS_STATS Procedure
RESTORE_SCHEMA_STATS Procedure
RESTORE_SYSTEM_STATS Procedure
RESTORE_TABLE_STATS Procedure
Whenever statistics in dictionary are modified, old versions of statistics are saved automatically for future restoring. The old statistics are purged automatically at regular intervals based on the statistics history retention setting and the time of recent statistics gathering performed in the system. Retention is configurable using the ALTER_STATS_HISTORY_RETENTION Procedure.
比如我們重新分析了表，發現分析的數據導致了CBO選擇了錯誤的執行計劃，為了挽救這種局面，可以將統計信息恢復到從前的那個時間點，也就是CBO執行計劃正確的時間點，先解決這個問題，再來分析問題的原因。
?
具體參考oracle 聯機文檔：
???????? http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461
?
?
四．???????? 動態采樣
?
4.1 什么是動態采樣
???????? 動態采樣（Dynamic Sampling）技術的最初提出是在Oracle 9i R2，在段（表，索引，分區）沒有分析的情況下，為了使CBO 優化器得到足夠的信息以保證做出正確的執行計劃而發明的一種技術，可以把它看做分析手段的一種補充。
???????? 當段對象沒有統計信息時（即沒有做分析），動態采樣技術可以通過直接從需要分析的對象上收集數據塊（采樣）來獲得CBO需要的統計信息。
?
一個簡單的例子：
?
創建表：
SQL> create table t
? 2? as
? 3? select owner,object_type from all_objects;
表已創建。
?
查看表的記錄數：
SQL> select count(*) from t;
COUNT(*)
----------
72236? -- 記錄數
?
這里創建了一張普通表，沒有做分析，我們在hint中用0級來限制動態采樣，此時CBO 唯一可以使用的信息就是表存儲在數據字典中的一些信息，如有多少個extent，有多少個block，但是這些信息是不夠的。
?
SQL> set autot traceonly explain
SQL> select /*+dynamic_sampling(t 0) */ * from t;
?
執行計劃
----------------------------------------------------------
Plan hash value: 1601196873
?
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? | 15928 |?? 435K|??? 55?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS FULL| T??? | 15928 |?? 435K|??? 55?? (0)| 00:00:01 |
?
在沒有做動態分析的情況下，CBO 估計的記錄數是15928條，與真實的72236 相差甚遠。
?
我們用動態分析來查看一下：
SQL> select * from t;
執行計劃
----------------------------------------------------------
Plan hash value: 1601196873
?
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? | 80232 |? 2193K|??? 56?? (2)| 00:00:01 |
|?? 1 |? TABLE ACCESS FULL| T??? | 80232 |? 2193K|??? 56?? (2)| 00:00:01 |
--------------------------------------------------------------------------
?
Note
-----
?? - dynamic sampling used for this statement (level=2)
?
在Oracle 10g中默認對沒有分析的段做動態采樣，上面的查詢結果顯示使用了Level 2級的動態采樣，CBO 估計的結果是80232 與72236 很接近了。
?
注意一點：
???????? 在沒有動態采樣的情況下，對于沒有分析過的段，CBO也可能錯誤地將結果判斷的程度擴大話。 如：
SQL> delete from t;
已刪除72236行。
SQL> commit;
提交完成。
SQL> select /*+dynamic_sampling(t 0) */ * from t;
執行計劃
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? | 15928 |?? 435K|??? 55?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS FULL| T??? | 15928 |?? 435K|??? 55?? (0)| 00:00:01 |
--------------------------------------------------------------------------
?
SQL> select * from t;
執行計劃
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
--------------------------------------------------------------------------
|?? 0 | SELECT STATEMENT? |????? |??? ?1 |??? 28 |??? 55?? (0)| 00:00:01 |
|?? 1 |? TABLE ACCESS FULL| T??? |???? 1 |??? 28 |??? 55?? (0)| 00:00:01 |
--------------------------------------------------------------------------
Note
-----
?? - dynamic sampling used for this statement (level=2)
?
如果細心一點，可能看出2個執行計劃的差別。 在沒有采用動態分析的情況下，CBO 對t表估計的還是15928行記錄，但是用動態分析就顯示1條記錄。 而表中的數據在查詢之前已經刪除掉了。? 出現這種情況的原因是因為高水位。 雖然表的數據已經刪除，但是表分配的extent 和block 沒有被回收，所以在這種情況下CBO 依然認為有那么多的數據在那。
????????
???????? 通過這一點，我們可以看出，此時CBO能夠使用的信息非常有限，也就是這個表有幾個extent，有幾個block。 但動態采樣之后，Oracle 立即發現，原來數據塊中都是空的。
?
關于Oracle 高水位，參考我的blog：Oracle 高水位(HWM)
http://blog.csdn.net/tianlesoftware/archive/2009/10/22/4707900.aspx
?
動態采樣有兩方面的作用：
（1）?????? CBO 依賴的是充分的統計分析信息，但是并不是每個用戶都會非常認真，及時地去對每個表做分析。 為了保證執行計劃都盡可能地正確，Oracle 需要使用動態采樣技術來幫助CBO 獲取盡可能多的信息。
（2）?????? 全局臨時表。 通常來講，臨時表的數據是不做分析的，因為它存放的數據是臨時性的，可能很快就釋放了，但是當一個查詢關聯到這樣的臨時表時，CBO要想獲得臨時表上的統計信息分析數據，就只能依賴于動態采樣了。
?
動態采樣除了可以在段對象沒有分析時，給CBO提供分析數據之外，還有一個獨特的能力，它可以對不同列之間的相關性做統計。
?
相對的，表分析的信息是獨立的。 如：
（1）?????? 表的行數，平均行長。
（2）?????? 表的每個列的最大值，最小值，重復率，也可能包含直方圖。
（3）?????? 索引的聚合因子，索引葉的塊數目，索引的高度等。
?
盡管看到動態采樣的優點，但是它的缺點也是顯而易見，否則Oracle 一定會一直使用動態采樣來取代數據分析：
（1）?????? 采樣的數據塊有限，對于海量數據的表，結果難免有偏差。
（2）?????? 采樣會消耗系統資源，特別是OLTP數據庫，尤其不推薦使用動態采樣。
?
?
4.2 動態采樣的級別
???????? Oracle 為動態采樣劃分了11個級別，在Oracle 的官網上詳細的介紹。
?????????????????? 13.5.7.4 Dynamic Sampling Levels
????????????? http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/stats.htm#PFGRF94760
?
The sampling levels are as follows if the dynamic sampling level used is from a cursor hint or from the OPTIMIZER_DYNAMIC_SAMPLING initialization parameter:
Level 0: Do not use dynamic sampling.
Level 1: Sample all tables that have not been analyzed if the following criteria are met: (1) there is at least 1 unanalyzed table in the query; (2) this unanalyzed table is joined to another table or appears in a subquery or non-mergeable view; (3) this unanalyzed table has no indexes; (4) this unanalyzed table has more blocks than the number of blocks that would be used for dynamic sampling of this table. The number of blocks sampled is the default number of dynamic sampling blocks (32).
Level 2: Apply dynamic sampling to all unanalyzed tables. The number of blocks sampled is two times the default number of dynamic sampling blocks.
Level 3: Apply dynamic sampling to all tables that meet Level 2 criteria, plus all tables for which standard selectivity estimation used a guess for a predicate that is a potential dynamic sampling predicate. The number of blocks sampled is the default number of dynamic sampling blocks. For unanalyzed tables, the number of blocks sampled is twice the default number of dynamic sampling blocks.
Level 4: Apply dynamic sampling to all tables that meet Level 3 criteria, plus all tables that have single-table predicates that reference 2 or more columns. The number of blocks sampled is the default number of dynamic sampling blocks. For unanalyzed tables, the number of blocks sampled is two times the default number of dynamic sampling blocks.
Levels 5, 6, 7, 8, and 9: Apply dynamic sampling to all tables that meet the previous level criteria using 2, 4, 8, 32, or 128 times the default number of dynamic sampling blocks respectively.
Level 10: Apply dynamic sampling to all tables that meet the Level 9 criteria using all blocks in the table.
?
The sampling levels are as follows if the dynamic sampling level for a table is set using the DYNAMIC_SAMPLING optimizer hint:
Level 0: Do not use dynamic sampling.
Level 1: The number of blocks sampled is the default number of dynamic sampling blocks (32).
Levels 2, 3, 4, 5, 6, 7, 8, and 9: The number of blocks sampled is 2, 4, 8, 16, 32, 64, 128, or 256 times the default number of dynamic sampling blocks respectively.
Level 10: Read all blocks in the table.
4.2.1 Level 0
???????? 不做動態分析
?
4.2.2 Level 1
???????? Oracle 對沒有分析的表進行動態采樣，但需要同時滿足以下4個條件。
（1）?????? SQL中至少有一個未分析的表
（2）?????? 未分析的表出現在關聯查詢或者子查詢中
（3）?????? 未分析的表沒有索引
（4）?????? 未分析的表占用的數據塊要大于動態采樣默認的數據塊（32個）
?
4.2.3 Level 2
???????? 對所有的未分析表做分析，動態采樣的數據塊是默認數據塊的2倍。
?
4.2.4 Level 3
???????? 采樣的表包含滿足Level 2定義的所有表，同時包括，那些謂詞有可能潛在地需要動態采樣的表，這些動態采樣的數據塊為默認數據塊，對沒有分析的表，動態采樣的默認塊為默認數據塊的2倍。
?
4.2.5 Level 4
???????? 采樣的表包含滿足Level 3定義的表，同時還包括一些表，他們包含一個單表的謂詞會引用另外的2個列或者更多的列；采樣的塊數是動態采樣默認數據塊數；對沒有分析的表，動態采樣的數據塊為默認數據塊的2倍。
?
4.2.6 Level 5，6，7，8，9
???????? 采樣的表包含滿足Level 4定義的表，同時分別使用動態采樣默認數據塊的2，4，8，32，128 倍的數量來做動態分析。
?
4.2.7 Level 10
???????? 采樣的表包含滿足Level 9定義的所有表，同時對表的所有數據進行動態采樣。
?
?
采樣的數據塊越多，得到的分析數據就越接近與真實，但同時伴隨著資源消耗的也越大。
?
?
4.3 什么時候使用動態采樣
???????? 動態采樣也需要額外的消耗數據庫資源，所以，如果 SQL 被反復執行，變量被綁定，硬分析很少，在這樣一個環境中，是不宜使用動態采樣的，就像OLTP系統。 動態采樣發生在硬分析時，如果很少有硬分析發生，動態采樣的意義就不大。
?
???????? 而在OLAP或者數據倉庫環境下，SQL執行消耗的資源要遠遠大于SQL解析，那么讓解析在消耗多一點資源做一些動態采樣分析，從而做出一個最優的執行計劃是非常值得的。 實際上在這樣的環境中，硬分析消耗的資源幾乎是可以忽略的。
?
???????? 所以，一般在OLAP 或者數據倉庫環境中，將動態采樣的level 設置為3或者4 比較好。 相反，在OLTP系統下，不應該使用動態采樣。
?
?
FROM：http://blog.csdn.net/tianlesoftware/article/details/5845028
轉載于:https://www.cnblogs.com/zlja/archive/2011/07/11/2449092.html
總結
以上是生活随笔為你收集整理的Oracle 分析及动态采样的全部內容，希望文章能夠幫你解決所遇到的問題。
