交流（二）--分割槽表統計分析耗時太長

 二、分割槽表統計時間太長
      
      在交流中有提到一些分割槽表進行統計時候，耗時巨大。這個問題在很多專案也提

到，這個是一個很饒頭的事情。oracle版本也不段在完善這塊的功能。就針對專案

提出的問題，給出一些可能的方法。（這塊我還沒有進行測試）
   
       問題：有一張分割槽表，型別是range分割槽，分割槽鍵是end_date，新載入資料作

為最後分割槽表。每次載入完做分割槽統計耗時很大。

       解決思路：
 
  1、 10g每天都定時進行統計分析作業，首先我們要將該分割槽排除在統計分析作業中；

        exec dbms_stats.lock_table_stats('OWNER', 'TABLE_NAME');

  2、因為資料型別相似，可以把其他分割槽表的統計資訊拷貝到新的分割槽表統計信

息，但這個有版本要求，至少10.2.0.4版本以上

       exec dbms_stats.copy_table_stats('OWNER', 'TABLE_NAME', 'OLD_PAR_TABLE', 'NEW_PAR_TABLE', force=>true);

      因為我們前面已經鎖住表的統計，需要加force=>true強制進行統計。

   3、而低版本的資料庫，可以採用以下方式直接進行更改統計資訊
    
       dbms_stats.set_index_stats
       dbms_stats.set_table_stats
       dbms_stats.set_column_stats

     以上的方法是基於對錶的各個統計資訊比較清楚的情況下采用的手段，在11g引

入了一個增量統計的概念，具體步驟如下：

     1、開啟增量統計開關
       
  exec dbms_stats.set_table_prefs('owner', 'table_name', 'INCREMENTAL',
                                                             'TRUE');
      2、執行增量統計

   exec dbms_stats.gather_table_stats('owner', 'table_name');

   在10.2.0.4版本，需要打一個補丁Patch 8877245，採用以下方法

    exec dbms_stats.gather_table_stats('owner', 'table_name', 'par_table',
                            granularity=>'APPROX_GLOBAL AND PARTITION');

    該方法不會更新NDV值，（number distinct value)。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/354732/viewspace-683428/，如需轉載，請註明出處，否則將追究法律責任。