背景
某用户一套业务系统反馈晚上跑批非常慢，后来客户发现是在处理truncate分区表分区的时候慢。
初步分析
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
SQL ID: f63rfdamawhv2 Plan Hash: 1605285479 select ts#, file#, block# from seg$ where type# =11 call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 2010 0.04 0.05 0 0 0 0 Execute 2010 0.05 0.06 0 0 0 0 Fetch 2010 526.17 526.63 0 52736370 0 2010 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 6030 526.27 526.75 0 52736370 0 2010 Misses in library cache during parse: 1 Optimizer mode: CHOOSE Parsing user id: SYS (recursive depth: 1) Number of plan statistics captured: 3 Rows (1st) Rows (avg) Rows (max) Row Source Operation ---------- ---------- ---------- --------------------------------------------------- 1 1 1 TABLE ACCESS FULL SEG$ (cr=26237 pr=0 pw=0 time=429271 us cost=5177 size=16 card=1)
有异常语句发现：去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跟踪去细细查看执行此语句的会话全过程，或许就会明朗了。
