sysaux表空間清理,小心有坑
一、問題描述
SYSAUX表空間做為SYSTEM表空間的輔助表空間,主要存放EM相關的內容以及表統計資訊,AWR快照,審計資訊等,而如果SYSAUX表空間在預設條件下你如果不做任何配置,隨著時間的推移,會膨脹的越來越大。經過幾次的不斷擴充套件增加SYSAUX表空間,目前已經24G以上了,所以是該考慮減肥的時候了。
二、sysaux表空間分析與處理
1.檢查表空間使用情況,發現sysaux表空間使用空間已達24G
- [email protected] > set lines 200
- [email protected] > Select Tablespace_Name,
- Sum_m,
- Max_m,
- Count_Blocks Free_Blk_Cnt,
- Sum_Free_m,
- To_Char(100 * Sum_Free_m / Sum_m, '99.9999')|| '%' As Pct_Free,
- 100 - To_Char(100 * Sum_Free_m / Sum_m,'99.9999') || '%' As Pct_used
- From (Select Tablespace_Name, Sum(Bytes) / 1024 / 1024 As Sum_m
- From Dba_Data_Files
- Group By Tablespace_Name)
- Left Join
- (Select Tablespace_Name As Fs_Ts_Name,
- Max(Bytes) / 1024 / 1024 As Max_m,
- Count(Blocks) As Count_Blocks,
- Sum(Bytes / 1024 / 1024) As Sum_Free_m
- From Dba_Free_Space
- Group By Tablespace_Name)
- On Tablespace_Name = Fs_Ts_Name
- ORDER BY Sum_Free_m / Sum_m ;
TABLESPACE_NAME SUM_M MAX_M FREE_BLK_CNT SUM_FREE_M PCT_FREE PCT_USED
------------------------------ ---------- ---------- ------------ ---------- --------- -----------------------------------------
SYSTEM 11450 53 2 53.75 .4694% 99.5306%
SYSAUX 24280 628 330 1138.1875 4.6878% 95.3122%
USERS 230 46 2 46.8125 20.3533% 79.6467%
... ...
2.檢視SYSAUX表空間內詳細佔儲存空間的比重資訊,AWR快照佔用了近21G多空間,其他資訊佔空間都非常小
- col Item for a30
- col Schema for a20
- set lines 200
- [email protected] > SELECT occupant_name"Item",
- round(space_usage_kbytes/1024/1024,3)"Space Used (GB)",
- schema_name "Schema",
- move_procedure "MoveProcedure"
- FROM v$sysaux_occupants
- ORDER BY 2 Desc;
Item Space Used (GB) Schema MoveProcedure
------------------------- --------------- ---------- ----------------------------------------------------------------
SM/AWR 21.377 SYS
SM/ADVISOR .526 SYS
SM/OPTSTAT .188 SYS
XDB .124 XDB XDB.DBMS_XDB.MOVEXDB_TABLESPACE
EM .085 SYSMAN emd_maintenance.move_em_tblspc
SDO .073 MDSYS MDSYS.MOVE_SDO
... ...
3.根據以上查詢情況得出,只要處理AWR的快照資訊就可以將儲存空間清理出來,檢查快照取樣間隔為每30分鐘一次,保留時間為8天,當然這個值從Oracle 11g 開始,預設值就為30分鐘一次,如果沒有特殊要求可以不做修改。
- [email protected] > col SNAP_INTERVAL for a40
- [email protected] > col RETENTION for a30
- [email protected] > select * from dba_hist_wr_control;
- DBID SNAP_INTERVAL RETENTION TOPNSQL
- ---------- -------------------- --------------------------------------------------------------------------- ----------
- 1361686490 +00000 00:30:00.0 +00008 00:00:00.0 DEFAULT
4.由於快照取樣時間過短,需要將快照取樣間隔調整為1小時1次
- [email protected] > begin
- 2 dbms_workload_repository.modify_snapshot_settings(
- 3 interval => 60
- 4 );
- 5 end;
- 6 /
- PL/SQL procedure successfully completed.
- [email protected] > col SNAP_INTERVAL for a40
- [email protected] > col RETENTION for a30
- [email protected] > select * from dba_hist_wr_control;
- DBID SNAP_INTERVAL RETENTION TOPNSQL
- ---------- -------------------------------------------------------------------------------------------- ----------
- 1361686490 +00000 01:00:00.0 +00008 00:00:00.0 DEFAULT
5.檢查最小和最大快照ID
- [email protected] > select min(snap_id),max(snap_id) from dba_hist_snapshot;
- MIN(SNAP_ID) MAX(SNAP_ID)
- ------------ ------------
- 37091 37680
6.按照官網介紹是可以用dbms_workload_repository包中drop_snapshot_range儲存過程來刪除快照,但是在此處,由於環境中存在著大量快照資訊,會有個大坑,需要DBA們take care!!!你要刪除的快照資訊不多時,仍然是首選該過程處理。如下命令。
- Syntax:
- DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(
- low_snap_id IN NUMBER,
- high_snap_id IN NUMBER
- dbid IN NUMBER DEFAULT NULL);
- Examples:
- EXECUTE DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(37091, 37679);
7.大坑描述與分析
根據用DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE來刪除快照耗時非常久,此時我也感覺到困惑,生產庫這樣子操作很危險,於是就繼續跟蹤查詢問題,最後發現在執行該過程時後臺實際執行的都是delete基表的動作,這下大家明白了吧,delete大表呀, undo表空間夠不夠大,歸檔日誌切換頻繁,導致歸檔目錄空間不足。多麼可怕的大坑啊!
8.另外一種處理方式,簡單粗暴,但很簡單實用,思路是按照上面操作儲存過程的方法進行改量,採取手動備份基表部分資料,truncate基表,再將備份部分資料插入回基表。經驗證該方法很高效而且成功,順便提一句,truncate表同時索引空間也被清空了。
三、高效處理方法
1.檢查最小和最大快照ID,根據快照ID來定們邊界值,以便找到要刪除和保留內容
- [email protected] > select min(snap_id),max(snap_id) from dba_hist_snapshot;
- MIN(SNAP_ID) MAX(SNAP_ID)
- ------------ ------------
- 37091 37680
2.查詢到那些佔用sysaux表空間的基表,按照大小進行排序
- select * from (select segment_name,PARTITION_NAME,segment_type,bytes/1024/1024 from dba_segments where tablespace_name='SYSAUX' order by 4 desc) where rownum<=10;
3.查表基本的組織結構發現WRH$表中都有snap_id欄位,所以我們就用這個欄位進行分界線處理。我們對佔用空間第一的表進行處理,備份WRH$_ACTIVE_SESSION_HISTORY表保留資料到WRH$_ACTIVE_SESSION_HISTORY_B表。
- CREATE TABLE WRH$_ACTIVE_SESSION_HISTORY_B AS SELECT * FROM WRH$_ACTIVE_SESSION_HISTORY WHERE SNAP_ID>37679 ;
4.驗證WRH$_ACTIVE_SESSION_HISTORY_B表儲存及包含資料
- SELECT COUNT(*) FROM WRH$_ACTIVE_SESSION_HISTORY_B;
5.清除源表WRH$_ACTIVE_SESSION_HISTORY資料
- TRUNCATE TABLE WRH$_ACTIVE_SESSION_HISTORY;
6.將備份資料恢復至源表
- INSERT INTO WRH$_ACTIVE_SESSION_HISTORY SELECT * FROM WRH$_ACTIVE_SESSION_HISTORY_B;
- COMMIT;
7.驗證基表資料
- SELECT COUNT(*) FROM WRH$_ACTIVE_SESSION_HISTORY;
8.刪除備份臨時表
- drop table WRH$_ACTIVE_SESSION_HISTORY_B purge;
9.按照上面的操作方式,將其餘佔空間的WRH$_開頭的表繼續清除資料,最終還給我們一個乾淨的Sysaux表空間。
四、總結
在這次處理sysaux輔助表空間時,我們掌握了兩種方法: (1)DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE 儲存過程方式 (2)查出哪些基表佔用空間大,進行手工備份與刪除 。 在這次清理過程中,讓我們感覺到使用ORACLE提供的儲存過程也會有大坑,還是要了解清楚,或者在測試環境測試過方可在生產上執行,否則還真會帶來不少麻煩。學習的道路是坎坷快樂的,但是為了人生更大的目標,需要努力。Where there is a will there is a way.