分割槽表truncate慢處理

背景

某使用者一套業務系統反饋晚上跑批非常慢，後來客戶發現是在處理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跟蹤去細細檢視執行此語句的會話全過程，或許就會明朗了。