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