某银行分区表truncate慢处理
/
背景
某银行一套业务系统反馈晚上跑批非常慢,后来客户发现是在处理truncate分区表分区的时候慢。
数据库版本 | 12.1.0.2 |
操作系统类型 | linux |
初步分析
truncate的实质是在不修改数据块的情况下,通过修改segment header的data_object_id,hwm,extent map,aux map等信息来实现清空表的目的,其中还涉及数据字典基表以及L1、L2位图块的修改,所以说truncate操作只是存储数据的数据块没有产生任何redo和undo,但是segment header,位图块,数据字典基表还是会产生redo和undo。一般来说是很快的。
初步思路
首先truncate这个动作本身是非常快的,只是更新数据字典信息,不涉及清除表的真正数据。
思路1:数据库是否存在异常等待事件
思路2:在不知道具体原因的情况下对会话进行10046跟踪。(通用方法)
排查步骤
登录客户生产环境,查看等待事件,发现没有异常等待事件
对truncate语句会话进行10046跟踪
对10046会话进行跟踪:
有异常语句发现:去mos查询select ts#, file#, block# from seg$ where type# =11
匹配bug:
建议客户优先设置隐含参数:
ALTER SYSTEM SET "_drop_stat_segment" =1;
发现客户已经设置此参数,说明此设置此参数无效!
既然隐含参数设置无效,那么尝试通过打补丁的方式去规避此问题。
打完补丁后,有一个小插曲。集群启动,asm磁盘带不起来,各位知道这是啥问题不?
验证
打完补丁后验证truncate速度
alter table ADM.ADM_D_ACCOUNT_DETAIL TRUNCATE PARTITION PART_20220609
打完补丁后truncate分区表为3s
未打补丁之前truncate分区表为8分钟
结论
当我们排查问题没有思路的时候,不妨尝试下10046跟踪去细细查看执行此语句的会话全过程,或许就会明朗了。