分区表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会话进行跟踪：
有异常语句发现：去mos查询
select ts#, file#, block# from seg$ where type# =11
匹配bug：
建议客户优先设置隐含参数：
ALTER SYSTEM SET "_drop_stat_segment" =1;
发现客户已经设置此参数，说明此设置此参数无效！
既然隐含参数设置无效，那么尝试通过打补丁的方式去规避此问题。
验证
打完补丁后验证truncate速度
alter table ADM.ADM_D_ACCOUNT_DETAIL TRUNCATE PARTITION PART_20220609
打完补丁后truncate分区表为3s
未打补丁之前truncate分区表为8分钟
结论
当我们排查问题没有思路的时候，不妨尝试下10046跟踪去细细查看执行此语句的会话全过程，或许就会明朗了。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70013625/viewspace-3090272/ ，如需转载，请注明出处，否则将追究法律责任。
