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.csdn.net/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

----这次出现这个错误，是因为数据库中的那个表中有两条重复的数据，所以读取的时候不能产生唯一结果导致的。
解决方法：找到对应表删除重复数据。