AWR 的資料預設保留8天,所以正常來說 |
SYSAUX表格空間的使用量不會有持續成長的狀況 |
我的案例是已經擴展空間到20GB |
看起來還是不夠用 |
就只好透過@?/rdbms/admin/awrinfo.sql |
來查看到底是甚麼咚咚占著茅坑不拉屎 |
結果如下: |
Problem Description |
--------------------------------------------------- |
Part of @?/rdbms/admin/awrinfo output |
SM/ADVISOR |
COMPONENT MB SEGMENT_NAME |
------------------ --------- --------------------------------------------------- |
NON_AWR 8,889.0 SYS.WRI$_ADV_OBJECTS TABLE |
NON_AWR 4,227.0 SYS.WRI$_ADV_OBJECTS_IDX_01 |
NON_AWR 2,897.0 SYS.WRI$_ADV_OBJECTS_PK |
它佔了至少8GB的空間 |
查了metalink |
文件 2305512.1 解釋了問題的所在 |
SYSAUX Tablespace Grows Rapidly After Upgrading Database to 12.2.0.1 Due To Statistics Advisor |
我後來開了Call給global support |
我說文件上講的只是一個work around |
並不是一個solution |
結果support 居然回應我就是只有work around |
我回頭再看文件 2305512.1 |
內容的最末寫了這段話 |
New Product enhancement has been logged to provide more control to disable the task. |
Unpublished Bug 26749785 NEED TO HAVE MORE CONTROL IN DICTIONARY FOR AUTO_STATS_ADVISOR_TASK |
好吧~~ 你承認是bug就好 |
只是不曉得這個"賦予細部控制"的功能甚麼時候會release |
接下來當然就是手動清檔 |
我先是直接執行 drop Statistics Advisor Task |
DECLARE |
v_tname VARCHAR2(32767); |
BEGIN |
v_tname := 'AUTO_STATS_ADVISOR_TASK'; |
DBMS_STATS.DROP_ADVISOR_TASK(v_tname); |
END; |
/ |
8G多的資料,undo 開了20GB還不夠它用 |
我去看了ASH的報表 |
雖然看起來是DROP 指令 |
但是清理資料卻是用delete |
我就只好手動把執行該指令的session給砍掉 |
再手動kill對應的server process |
確認沒有留下甚麼手尾後 |
就依照文件內使用CTAS的清檔方式 |
進行資料的清理 |
果然是大絕招 |
沒幾分鐘就做完了 |
最好就是整理空間數據給客戶看了 |
原本數據 |
占用 已用 剩餘 % |
02/11/2020,SYSAUX,20480,18783,1697,92 |
清檔後數據 |
02/11/2020,SYSAUX,20480,1022,19458,5 |