关闭

ORA-00001 unique constraint violated错误的解决

标签: oracle10gparsingsqloracletree数据库
2134人阅读 评论(1) 收藏 举报
分类:
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:
select a1,a2 from t1 where a3=1;
select a1,a2 from t1 where a3=3;

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

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:10946次
    • 积分:199
    • 等级:
    • 排名:千里之外
    • 原创:8篇
    • 转载:5篇
    • 译文:0篇
    • 评论:2条
    文章分类