大家好！
惯例先介绍环境：
操作系统：Redhat7.6
数据库版本：19.7
是否RAC：是
ASM或文件系统：ASM
最近巡检发现某库DBalert日志报ORA-600,ORA-700错误。详细如下：
继续分析相关trace如下：
如图显示，用户触发SQL如下：
createtable tab_20200813_2_5_1011 nologging as select * from tab_20200813where mod(serv_id,10)=2
从调用堆栈信息来看，kqrReadFromDBcache读取触发的报错。
继续查看trace：
从上两图显示，ORA-600,ORA-700触发均发生在drop回收站对象时。
总结：
从错误发生时的函数调用信息来看，问题发生在创建新表时，表空间的剩余空间不够，内部通过递归调用来清除recycleBin的对象释放空间时，发生了内存上的临时错误。MOS上无法找到在该版本类似的案例。
临时解决方法：
确保表空间有足够的剩余空间，使其不会自动触发回收站对象清除。
手动清除回收站对象，并将其添加至crontab中。
purgerecyclebin;
19C使用过程中会碰到越来越多的坑，有些MOS上可以找到补丁或者workaroud，但目前看，大部分是无解决方案，这个时候，我们应该秉承，不管白猫黑猫，能让系统稳定健康运行的就是好猫的原则来进行相关的填坑动作。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130100.html
集成安装之oracle19C GI升级遇坑分享 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ...
19c RAC补丁升级报错处理 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; mar...
Goldengate目标端11g升级至19c img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ...
利用Oracle ADG升级11.2.0.4到19.8案例分享 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75...
19C DG Broker配置和测试 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ...
阅读 1487·2023-01-11 13:20
阅读 1841·2023-01-11 13:20
阅读 1285·2023-01-11 13:20
阅读 2030·2023-01-11 13:20
阅读 4239·2023-01-11 13:20
阅读 2921·2023-01-11 13:20
阅读 1577·2023-01-11 13:20
阅读 3840·2023-01-11 13:20
