分区表truncate慢处理

某银行分区表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会话进行跟踪：

glkjdb2_ora_26523_abcd.txt

有异常语句发现：去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跟踪去细细查看执行此语句的会话全过程，或许就会明朗了。