由于朋友的一个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来代替

(http://www.linuxdiyf.com/bbs/thread-58174-1-1.html)

设了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@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7916042/viewspace-1028975/，如需转载，请注明出处，否则将追究法律责任。