love wife love life —Roger的Oracle/MySQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

当遭遇ORA-00600  [kkdlron-max-objid], [4254950911] 怎么办

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL数据恢复博客

本文链接地址: 当遭遇ORA-00600  [kkdlron-max-objid], [4254950911] 怎么办

今天同事反馈有客户环境遇到ORA-00600: [kkdlron-max-objid], [4254950911] 报错;该环境超过30tb大小;处理起来比较麻烦。

从错误来看,应该就是应用不断drop重建对象,导致object_id达到Oracle最大值了。虽然Oracle Mos提供了一个Bug,如下:

但实际上即使打上Patch,能用的object_id 范围也很小了,也就几千万。不足以支撑3天。

在Oracle数据库中关于object/cosntraint/users的最大数量限制,可以参考这篇文档。Internal Database Limits on Number of Objects, Constraints, and Users (Doc ID 2660231.1)

言归正传;很明显这个问题,根本原因在于应用架构设计问题,不应该不断drop重建对象,其实可以使用temporary table来解决这个问题。

就这个问题而言,同事查询该数据object 仅仅不到20万个对象。那么针对这个问题,能否有一些方法可以绕过呢?

我们知道oracle创建对象是通过_next_object来获取id的,该对象属于sys;如下:

下面我们来进行简单的测试:

我们可以看到,其实完全可以重用object_id。但是这里需要注意的是,直接修改数据字典,存在一定风险。需要慎重评估。

另外对于这个临时处理方案,主要是要寻找到object id到空洞范围,最好是范围够大。

当然,如果担心数据字典有异常,可以使用Oracle提供到脚本check一次。

操作有风险!上述操作均为个人测试,生产环境建议慎重。如果可能,还是重建库比较好。

 

Leave a Reply

You must be logged in to post a comment.