version_count>6000

显示全部楼层 · 2010-3-1 11:07:21

一个金融系统，1O。2。0。3， AIX，事务比较平凡， COMMIT太多，有REDO 等待事件。都是很小的事务。
最近报ORA-00600错误，根据METALINK，说是BUG，有WORK AROUND是把SESSION CACHED CURSOR = 0。
这样的代价，必然是引起更多的解析。
联想到SESSION 级别以外，发现 V SQL 中VERSION COUNT> 6000 的情况有 10多个， VERSION COUNT大于 100的有上百。
难怪可户SGA一加再加， 5G了。
开了个SR， ORACLE 支持也没提出什么见解，一是看SQL 语句下的对象是否有HISTOGRAM，这确实有的，建议重新分析，不用直方图。另外建议把 CURSOR SHARING= FORCE。
这个是PRODUCTION，不敢下手啊，大家给点建议。
。。。。。。
忘了说，现在 CURSOR SHARING=SIMILAR， OF COURSE
[ 本帖最后由 yunyan 于 2009-4-17 09:41 编辑 ]

千问 · 2010-3-1 11:07:21

try in pre-production db before apply in production

千问 · 2010-3-1 11:07:21

cursor_sharing是设置的similar??

千问 · 2010-3-1 11:07:21

AIX 53 Bit 10203, version count 10000
前段时间处理了一个，Oracle确认是一个bug
本来说打单独patch
后来升了10204

千问 · 2010-3-1 11:07:21

谢谢大家关注，
楼上那位，你说的那个BUG，是在SESSION LEVEL的， ORA-00600，是SESSION CACHED CURSOR 超过极限，所以ORACLE 说有个WORK AROUND是 SETSESSION CACHED CURSOR =0，但是用脚想想都知道，这样有什么不好，所以我联想到跳出SESSION 级别，果然就发现了VERSION COUNT 瞎大。所以占了那么多SHARED POOL 。
那难道可以想象在 SESSION 范围外，不用 CURSOR SHARING 的功能啊。
棉花：是 SIMILAR，所以才会在SESSION CACHED CURSOR 下有很多，以至超过极限，报ORA-00600的错。这个错误导致了LATCH FREE，而设置了 SESSION CACHED CURSOR=0，自然就报LIBRARY CACHE LOCK 等的问题了。
[ 本帖最后由 yunyan 于 2009-4-17 10:27 编辑 ]

千问 · 2010-3-1 11:07:21

检查相关字段是否真需要直方图,没必要的话就干掉
method_opt=>'for all columns size 1';

千问 · 2010-3-1 11:07:21

OLTP的应用需要直方图的情况很少的

千问 · 2010-3-1 11:07:21

恩，多谢，这是客户跑的 STATS，不知道是怎么回事，只能建议了，唉。

千问 · 2010-3-1 11:07:21

把VERSION_COUNT特别高的SQL找出来，查看WHERE条件中引用的列，如果有HISTOGRAM的，那个列上的数据又不是真的倾斜的，把直方图去掉。

千问 · 2010-3-1 11:07:21

是啊，但是用户不知道用什么东西跑的STATS，要想个法去掉啊。要不隔天又收集了。
看来只能等他们的跑完了，我再设置个收集的作业去抵消。
[ 本帖最后由 yunyan 于 2009-4-17 11:10 编辑 ]

version_count&gt;6000

version_count>6000