Statspack ORA-00001 unique constraint violated错误的解决

最新推荐文章于 2025-01-09 10:00:00 发布

转载最新推荐文章于 2025-01-09 10:00:00 发布 · 3.6k 阅读

文章标签：

#oracle10g #parsing #sql #oracle #tree #优化

oracle 专栏收录该内容

100 篇文章

订阅专栏

本文探讨了ORA-00001错误的原因及解决方案，涉及到唯一约束冲突和如何通过临时禁用约束检查来定位问题。此外，文章还深入分析了cursor_sharing参数的不同设置对Oracle性能的影响。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Statspack ORA-00001 unique constraint violated错误的解决

ORA-00001: unique constraint (PERFSTAT.STATS$SQL_SUMMARY_PK) violated
ORA-06512: at "PERFSTAT.STATSPACK", line 1361
ORA-06512: at "PERFSTAT.STATSPACK", line 2471
ORA-06512: at "PERFSTAT.STATSPACK", line 91
ORA-06512: at line 1
Sun Oct 16 00:43:39 2005

这个错误此前从未遇到，但是既然是主键冲突，那肯定是存在重复主键的数据。

肯定能暂时解决问题方法就是暂时禁用唯一约束检查:
ALTER TABLE PERFSTAT.STATS$SQL_SUMMARY
MODIFY CONSTRAINT STATS$SQL_SUMMARY_PK DISABLE NOVALIDATE;

然后观察数据来发现根本问题，最后彻底解决之。

到Metalink搜索了一下，发现存在一个相关Bug，Bug号为:2784796.
在设置了cursor_sharing为similar或者force之后，可能触发此Bug，导致主键冲突。

此bug据说在Oracle10g中已经修正。

怪不得我前天加statpack时老报这个错，于是我随手加多一个字段address来作为唯一索引
其实从sql优化角度来说。。。cursor_sharing有exact、similar、force三种值的选择，为了减少statement hard parse value，最好是使用绑定变量，如果无法全面改写程序，DBA的另外选择就是调整这个参数.

完全相同的statement (包含整个statement的內容、大小写完全相同、where条件相同)在执行计划和parsing tree尚未被清除前可以被直接拿來执行，減少了hard parse的次数，但8i以前只能选择force或者exact，force有可能会造成optimizer执行计划选择失当，结果反而造成性能上的灾难，因此通常不用。

从9i开始多了similar的选择，它具备了2者的优点，当对象表有统计值时，会选择最佳的执行计划，如果没有，就和force一样使用旧的执行计划。

cursor_sharing=similar的效果就是这样：

如果你有2句sql：
selecｔ a1,a2 from t1 where a3=1;
selecｔ a1,a2 from t1 where a3=3;

那么oracle会自动转换为：
selecｔ a1,a2 from t1 where a3==:"SYS_B_0";

这样就可以避免硬解析带来的CPU开销，从而提高性能；但是如果这个表做过分析了，则每换一次条件值，就会做一次硬解析，以避免执行计划选择失当的问题。

更详细的分析看这里：http://blog.youkuaiyun.com/biti_rainy/archive/2004/07/12/39466.aspx

en... 找时间作个试验，验证一下这段话。看来oracle的确做得越来越不需要dba了，呵呵

还有一篇相关的，讨论是否使用preparedstatment的帖子，贴出来作为参考
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=121&threadID=10397&start=0&tstart=0

感觉概念清楚很多了，以后向研发挥舞大刀的时候，也有理论依据啦，哈哈