由于bug造成truncate table卡住问题

客户反应truncate table卡主,检查awr发现多个truncate在awr报告期内一直没执行完,如下:

检查ash,truncate table表的等待事件都是"enq: RO - fast object reuse"和"local write wait"

查找"enq: RO - fast object reuse",造成该问题的是由于数据库bug造成,bug号为:bug 21422580

该bug可以通过打补丁解决,补丁在11.2.0.4.180116中已解决,同时也可以设置隐含参数解决"_db_fast_obj_truncate=FASE"。

另外在Truncate Slow in 11.2.0.3 and Higher (Doc ID 1667223.1)文档中也提到,"local write wait"和"enq: RO - fast object reuse"事件,该事件由BUG:18251841造成。

但这个案例中,是最后打算最新补丁,该问题解决。

相关推荐
悟能不能悟1 小时前
redis的红锁
数据库·redis·缓存
安当加密3 小时前
MySQL数据库透明加密(TDE)解决方案:基于国密SM4的合规与性能优化实践
数据库·mysql·性能优化
JH30734 小时前
第七篇:Buffer Pool 与 InnoDB 其他组件的协作
java·数据库·mysql·oracle
板凳坐着晒太阳4 小时前
ClickHouse 配置优化与问题解决
数据库·clickhouse
数据库生产实战4 小时前
解析Oracle 19C中并行INSERT SELECT的工作原理
数据库·oracle
AAA修煤气灶刘哥5 小时前
服务器指标多到“洪水泛滥”?试试InfluxDB?
数据库·后端·面试
阿沁QWQ5 小时前
MySQL服务器配置与管理
服务器·数据库·mysql
程序新视界7 小时前
MySQL“索引失效”的隐形杀手:隐式类型转换,你了解多少?
数据库·mysql·dba
Logintern097 小时前
windows如何设置mongodb的副本集
数据库·windows·mongodb
RestCloud9 小时前
在制造业数字化转型浪潮中,数据已成为核心生产要素。然而,系统割裂、数据滞后、开发运维成本高等问题,却像顽固的 “数据枷锁”,阻碍着企业发展。ETLCloud与
数据库·postgresql