對於最近2天的bi資料庫的最佳化

由於朋友的一個bi資料庫最近使用者增加，日誌增加很多，每天有2000w行的使用者日誌，需要分析，但機器還是原來的一個32位的pc機，速度比較慢，報表需要10個小時才能出來，上頭不能及時看到報表，很是著急！

我先想32位的對於記憶體使用不好，有1.7G的限制，想先突破，我參考了http://yangtingkun.itpub.net/post/468/492617，但是發現出現ora錯誤 ORA-00371: not enough shared pool memory, should be atleast 72265318 bytes

要注意的是，開啟這個引數後DB_CACHE_SIZE 就不能用了，否則啟動的時候會報ORA-00385: cannot enable Very Large Memory with new buffer cache parameters的錯誤，要用DB_BLOCK_BUFFERS來代替

()

設了shared_pool_size和

event = "10262 trace name context forever, level 1024000"

後資料庫能重新啟動

但是發現資料插入很慢，每秒鐘才850條資料（他們沒有采用sqlldr入庫，而是逐條插入，10000條再commit），這樣算下來插入2000w資料需要7個小時才能插完，很是鬱悶！

然後我取消了相關引數，檢視sql語句的執行時間

發現insert into mid_user_action_log (RECORDTIME,MOBILE,PROVINCEID,CITYID,URI,REGTIME,USERNAME) select /*+ USE_HASH(t,r) */ t.RECORDTIME,t.MOBILE,t.PROVINCEID,t.CITYID,t.URI,r.recordtime ,t.userid from a t ,b r where t.mobile=r.mobile(+) and t.mobile is not null and length(t.mobile)=11

這個a表有1800w條資料，b有600w條資料



使用hash_join後發現很快2分鐘！

還有一個：insert into a select mobile ,case .. when from b group by mobile的語句，發現select不花費時間，但是insert into花費了大量的時間，整個時間花了大概65分鐘，經查發現a表是個大表，有1800w的資料，有2個索引；慢就慢在組織索引上；alter index inx_a unusable; 然後插入資料；最後alter index inx_a rebuild;最後發現時間為13分鐘！

[@more@]