求助 oracle 吃cpu

lovewwd · 发表于 2003-2-10 12:50

终于解决了，thx 各位

最初由 4pal 发布
[B]没有这样的说法，但是我估计你们动态生成的sql语句，跟我举的例子是差不多的。比如 insert into temp values (1); insert into temp values (2); ......insert into temp values (N); 是完全不同的sql语句，肯定要硬解析的说。因此为什么不用insert into temp values (:a);这样的也可以是动态sql语句来代替呢？
shared_pool_size的增大，只能延缓瘫痪的时间，但会造成更加严重的恶果，也纵容了不好好写代码的惰性

第2点你说的对，跟应用有关。俺们不知道你们的应用，但我感觉返回的结果集太大，是不是真的需要这么多的查询数据呢？ [/B]

1.insert into temp values (1); insert into temp values (2); ......insert into temp values (N);

这个是没办法了，大部分是这种情况了，涉及到好多方面，想优化也没办法。但是这样的话，我的shared_pool_size 是不是应该适当的大些？

2. 结果集大这个提醒帮了我，应用方面逻辑读数量巨大是事实，但是结果集是大了些，后来终于找到原因了。我观察了一下tablespace的利用，将近80%，根据对方dba说，不应该有这么多数据，怀疑是碎片，exp/imp后，压缩成10％，结果现在运行相当平稳，cpu idle平均30%，基本满足要求。

4pal · 发表于 2003-2-10 13:04

t.t 其实应该没解决问题。不知道怎么让你们exp/imp 提高了性能 @_@ 是不是你们的应用经常写数据？（insert or update ）碎片对于读取query来说，没有性能影响。碎片太多对动态分配extent 才会有巨大的overhead。参考 http://www.itpub.net/showthread.php?s=&threadid=93622

改应用难是通病，算了。只是希望能够提醒程序员以后要注意绑定变量的说

ocpjerry · 发表于 2003-2-10 13:40

试试在init<SID>中加入cursor_sharing=forse行强制绑定变量，看看能否解决shared_pool_size的问题？

lovewwd · 发表于 2003-2-10 14:46

最初由 4pal 发布
[B]t.t 其实应该没解决问题。不知道怎么让你们exp/imp 提高了性能 @_@ 是不是你们的应用经常写数据？（insert or update ）碎片对于读取query来说，没有性能影响。碎片太多对动态分配extent 才会有巨大的overhead。参考 http://www.itpub.net/showthread.php?s=&threadid=93622

改应用难是通病，算了。只是希望能够提醒程序员以后要注意绑定变量的说 [/B]

没错