oracle system和sysaux表空间清理和回收
oracle system和sysaux表空間清理和回收
??前幾天和一個網友討論了下SYSAUX表空間使用率過高的問題，今天有時間整理一下，正好我們的測試數據庫也存在這個問題。本案例數據庫版本為11.2.0.4.0。
??SYSAUX表空間被稱為系統輔助表空間，是10g版本開始推出的新功能，主要的目的是為SYSTEM表空間減負，Oracle對SYSTEM表空間的維護有一套獨立的體系，對SYSTEM表空間操作會占用額外的CPU資源，而且效率低下，詳見我之前發表的文章為什么不要把用戶表存儲到SYSTEM表空間。在10g版本，增加了SYSAUX輔助表空間，將EM、AWR等組件的表從SYSTEM表空間挪到了SYSAUX表空間中，這樣大大減少了SYSTEM表空間的消耗，也減少了Oracle對SYSTEM表空間維護的成本。
??但是有幾個比較坑爹的組件需要的表并沒有挪到SYSAUX表空間，比如常見的審計用到的AUD$表，很多DBA都可能遇到SYSTEM表空間使用率過高，查詢發現是AUD$表很大導致的，我們的數據庫正好打開了審計功能，正好可以拿來做實驗。
??下面先查詢下SYSTEM和SYSAUX表空間的使用率。
??可見，SYSAUX表空間已經使用了21GB左右，SYSTEM表空間已經使用了8GB左右，下面查看下使用SYSTEM和SYSAUX表空間的比較大的表有哪些。
sys@IVLDB> select * from (select segment_name,sum(bytes)/1024/1024 total_mb,tablespace_name from dba_segments where tablespace_name in ('SYSTEM','SYSAUX') group by segment_name,tablespace_name order by 2 desc)where rownum <=20; SEGMENT_NAME TOTAL_MB TABLESPACE_NAME ------------------------------------------------- ---------- -------------- AUD$ 6680 SYSTEM WRH$_ACTIVE_SESSION_HISTORY 5248.0625 SYSAUX WRH$_EVENT_HISTOGRAM_PK 2499.0625 SYSAUX WRH$_EVENT_HISTOGRAM 1794.0625 SYSAUX WRH$_LATCH_MISSES_SUMMARY_PK 905.0625 SYSAUX WRH$_SQLSTAT 816.0625 SYSAUX WRH$_LATCH 800.0625 SYSAUX C_OBJ#_INTCOL# 768 SYSTEM WRH$_LATCH_MISSES_SUMMARY 760.0625 SYSAUX WRH$_ACTIVE_SESSION_HISTORY_PK 712.0625 SYSAUX WRH$_SYSSTAT_PK 672.0625 SYSAUX WRH$_LATCH_PK 560.0625 SYSAUX WRH$_SYSSTAT 504.0625 SYSAUX I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST 456 SYSAUX WRH$_PARAMETER_PK 454.0625 SYSAUX WRH$_SEG_STAT 408.0625 SYSAUX WRH$_PARAMETER 384.0625 SYSAUX WRH$_SYSTEM_EVENT 368.0625 SYSAUX WRI$_OPTSTAT_HISTGRM_HISTORY 312 SYSAUX I_H_OBJ#_COL# 312 SYSTEM??可見，大表大部分都是AUD$和WRH$開頭的AWR基表，AUD$使用SYSTEM表空間，AWR的基表使用SYSAUX表空間，下面再查看下SYSAUX表空間的使用情況，可以通過v$sysaux_occupants視圖查詢到。
sys@IVLDB> SELECT occupant_name "Item", space_usage_kbytes / 1048576 "Space Used (GB)", schema_name "Schema", move_procedure "Move Procedure" FROM v$sysaux_occupants ORDER BY 1 ; Item Space Used (GB) Schema Move Procedure ------------------------------ --------------- -------------------- ----------------------------------- AO .038391113 SYS DBMS_AW.MOVE_AWMETA AUDIT_TABLES 0 SYS DBMS_AUDIT_MGMT.move_dbaudit_tables AUTO_TASK .000366211 SYS EM 0 SYSMAN emd_maintenance.move_em_tblspc EM_MONITORING_USER .001708984 DBSNMP EXPRESSION_FILTER .003540039 EXFSYS JOB_SCHEDULER .010498047 SYS LOGMNR .013061523 SYSTEM SYS.DBMS_LOGMNR_D.SET_TABLESPACE LOGSTDBY .001342773 SYSTEM SYS.DBMS_LOGSTDBY.SET_TABLESPACE ORDIM .000427246 ORDSYS ordsys.ord_admin.move_ordim_tblspc ORDIM/ORDDATA .013244629 ORDDATA ordsys.ord_admin.move_ordim_tblspc ORDIM/ORDPLUGINS 0 ORDPLUGINS ordsys.ord_admin.move_ordim_tblspc ORDIM/SI_INFORMTN_SCHEMA 0 SI_INFORMTN_SCHEMA ordsys.ord_admin.move_ordim_tblspc PL/SCOPE .001525879 SYS SDO .064758301 MDSYS MDSYS.MOVE_SDO SM/ADVISOR .199707031 SYS SM/AWR 18.8637695 SYS SM/OPTSTAT 1.14306641 SYS SM/OTHER .012268066 SYS SMON_SCN_TIME .008178711 SYS SQL_MANAGEMENT_BASE .001647949 SYS STATSPACK 0 PERFSTAT STREAMS .000976563 SYS TEXT .003540039 CTXSYS DRI_MOVE_CTXSYS TSM 0 TSMSYS ULTRASEARCH 0 WKSYS MOVE_WK ULTRASEARCH_DEMO_USER 0 WK_TEST MOVE_WK WM .003417969 WMSYS DBMS_WM.move_proc XDB .123962402 XDB XDB.DBMS_XDB.MOVEXDB_TABLESPACE XSAMD .005004883 OLAPSYS DBMS_AMD.Move_OLAP_Catalog XSOQHIST .038391113 SYS DBMS_XSOQ.OlapiMoveProc31 rows selected.??可見SM/AWR組件就使用了將近19GB的SYSAUX表空間，也就是說審計和AWR占用了大量的SYSTEM和SYSAUX表空間，而這些數據是可以定期清理的，都沒有必要保留太長的時間。
下面先清理審計的數據，如果要保留部分AUD$里面記錄的審計數據，可以把想要的數據插入到一張臨時表，然后直接truncate這張表就可以了，truncate操作會直接回收AUD$占用的空間。
Table truncated.
sys@IVLDB> select bytes/1024/1024 from dba_segments where segment_name='AUD$'; BYTES/1024/1024 ---------------5??可見，truncate這張表之后，6680M的空間直接降為5M，釋放了大量的SYSTEM表空間的空間。下面再來回收下SYSAUX表空間，這個相對比較麻煩，也比較耗時。
??如上文所示，通過查看v$sysaux_occupants視圖，可以確定占用SYSAUX表空間過多的大部分都是AWR的基表，這樣只要刪除部分AWR數據理論上就可以回收一部分SYSAUX表空間，通常AWR的數據都會設置保留期限，10g版本默認保留7天，11g版本默認保留8天，可以通過dba_hist_wr_control視圖來查看(注：并不是所有DBA開頭的表都是數據字典，也有很多是視圖，dba_hist_wr_control就是視圖)。
??大家可能會有疑問了，AWR的數據既然只保留七八天，為什么還會占用這么多的SYSAUX表空間呢？這個問題我個人認為主要有以下兩個原因，首先，AWR刪除過期的數據是通過DELETE操作完成的，這樣就會產生大量的碎片，特別是SYSAUX表空間存在自動擴展的數據文件，而且這個數據文件沒有擴展到最大，還有擴展的空間情況下會很明顯，其次就是ASH的數據有些情況下是不受AWR的保留策略影響的，這個從下面的SQL就可以看出。
sys@IVLDB> select count(*) from WRH$_ACTIVE_SESSION_HISTORY; COUNT(*) ---------- 16918966 sys@IVLDB> select min(snap_id),max(snap_id) from wrh$_active_session_history; MIN(SNAP_ID) MAX(SNAP_ID) ------------ ------------1 15533??可以看到，ASH的數據從第一個快照開始一直都在保留，導致WRH$_ACTIVE_SESSION_HISTORY表很大，使用DBMS_WORKLOAD_REPOSITORY包清理過期或者不需要的AWR數據，可以回收這部分空間。
sys@IVLDB> exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id =>1,high_snap_id => 30000);PL/SQL procedure successfully completed.
??清理了AWR數據之后，你會發現SYSAUX表空間的空間并沒有被回收，使用率還和之前一樣，這是因為清理AWR操作是通過DELETE操作實現的，表的水位線并沒有下降導致的。
??AWR的數據還是使用將近19GB的空間，查詢SYSTEM和SYSAUX表空間的使用率會發現SYSTEM表空間的使用率已經降低了很多，因為上文TRUNCATE了AUD$表，這張表使用的是SYSTEM表空間，上文刪除了很多AWR的數據，AWR的數據使用SYSAUX表空間，并沒有回收。
sys@IVLDB> SELECT * FROM ( SELECT D.TABLESPACE_NAME, SPACE || 'M' "SUM_SPACE(M)", BLOCKS "SUM_BLOCKS", SPACE - NVL (FREE_SPACE, 0) || 'M' "USED_SPACE(M)", ROUND ( (1 - NVL (FREE_SPACE, 0) / SPACE) * 100, 2) || '%' "USED_RATE(%)", FREE_SPACE || 'M' "FREE_SPACE(M)" FROM ( SELECT TABLESPACE_NAME, ROUND (SUM (BYTES) / (1024 * 1024), 2) SPACE, SUM (BLOCKS) BLOCKS FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME) D, ( SELECT TABLESPACE_NAME, ROUND (SUM (BYTES) / (1024 * 1024), 2) FREE_SPACE FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME) F WHERE D.TABLESPACE_NAME = F.TABLESPACE_NAME(+) UNION ALL SELECT D.TABLESPACE_NAME, SPACE || 'M' "SUM_SPACE(M)", BLOCKS SUM_BLOCKS, USED_SPACE || 'M' "USED_SPACE(M)", ROUND (NVL (USED_SPACE, 0) / SPACE * 100, 2) || '%' "USED_RATE(%)", NVL (FREE_SPACE, 0) || 'M' "FREE_SPACE(M)" FROM ( SELECT TABLESPACE_NAME, ROUND (SUM (BYTES) / (1024 * 1024), 2) SPACE, SUM (BLOCKS) BLOCKS FROM DBA_TEMP_FILES GROUP BY TABLESPACE_NAME) D, ( SELECT TABLESPACE_NAME, ROUND (SUM (BYTES_USED) / (1024 * 1024), 2) USED_SPACE, ROUND (SUM (BYTES_FREE) / (1024 * 1024), 2) FREE_SPACE FROM V$TEMP_SPACE_HEADER GROUP BY TABLESPACE_NAME) F WHERE D.TABLESPACE_NAME = F.TABLESPACE_NAME(+) ORDER BY 1) WHERE TABLESPACE_NAME IN ('SYSAUX','SYSTEM'); TABLESPACE_NAME SUM_SPACE(M) SUM_BLOCKS USED_SPACE(M) USED_RATE(%) FREE_SPACE(M) -------------------- --------------- ---------- --------------- ------------- -------------- SYSAUX 22156M 2835968 21126.81M 95.35% 1029.19M SYSTEM 8686M 1111808 1990.25M 22.91% 6695.75M??查詢WRH$_ACTIVE_SESSION_HISTORY表會發現數據已經被刪除了很多，從刪除之前的16918966條記錄變為刪除后的4706條記錄，但是表的大小沒變，還是5GB多。
sys@IVLDB> select count(*) from WRH$_ACTIVE_SESSION_HISTORY; COUNT(*) ----------4706??下面通過MOVE操作回收這個表的水位線，來回收這部分被刪除數據占用的空間。這個表是分區表，分區表不支持表級別的MOVE操作，直接對分區表進行MOVE操作會遇到ORA-14511錯誤。
sys@IVLDB> alter table WRH$_ACTIVE_SESSION_HISTORY move; alter table WRH$_ACTIVE_SESSION_HISTORY move* ERROR at line 1: ORA-14511: cannot perform operation on a partitioned object??查看這個表的分區信息，只有兩個分區。
sys@IVLDB> select segment_name,partition_name,bytes/1024/1024/1024 gb from dba_segments where segment_name='WRH$_ACTIVE_SESSION_HISTORY'; SEGMENT_NAME PARTITION_NAME GB ------------------------------ ------------------------------ ---------- WRH$_ACTIVE_SESSION_HISTORY WRH$_ACTIVE_1357933872_0 5.125 WRH$_ACTIVE_SESSION_HISTORY WRH$_ACTIVE_SES_MXDB_MXSN .000061035??下面按照分區進行MOVE操作，來回收空間。
sys@IVLDB> alter table WRH$_ACTIVE_SESSION_HISTORY move partition WRH$_ACTIVE_1357933872_0;Table altered.
sys@IVLDB> alter table WRH$_ACTIVE_SESSION_HISTORY move partition WRH$_ACTIVE_SES_MXDB_MXSN;Table altered.
??對分區表進行MOVE之后，需要重建索引，查看這個表的索引信息。
??這個表只有一個主鍵，而且是分區索引，也不能對分區索引直接進行REBUILD操作，否則會遇到ORA-14086錯誤。
sys@IVLDB> alter index WRH$_ACTIVE_SESSION_HISTORY_PK rebuild; alter index WRH$_ACTIVE_SESSION_HISTORY_PK rebuild* ERROR at line 1: ORA-14086: a partitioned index may not be rebuilt as a whole??下面查看下這個索引的分區信息。
sys@IVLDB> select partition_name from dba_ind_partitions where index_name='WRH$_ACTIVE_SESSION_HISTORY_PK'; PARTITION_NAME ------------------------------ WRH$_ACTIVE_1357933872_0 WRH$_ACTIVE_SES_MXDB_MXSN??然后按照分區進行重建索引。
sys@IVLDB> alter index WRH$_ACTIVE_SESSION_HISTORY_PK rebuild partition WRH$_ACTIVE_1357933872_0;Index altered.
sys@IVLDB> alter index WRH$_ACTIVE_SESSION_HISTORY_PK rebuild partition WRH$_ACTIVE_SES_MXDB_MXSN;Index altered.
??再次查看，WRH$_ACTIVE_SESSION_HISTORY的空間已經回收。
??可見，這個表大小由之前的5248.0625MB將為2.0625MB，重建索引后，索引的大小也由之前的712.0625MB降為了0.3125MB，這一張表就回收了6GB左右的空間。
sys@IVLDB> SELECT occupant_name "Item", space_usage_kbytes / 1048576 "Space Used (GB)", schema_name "Schema", move_procedure "Move Procedure" FROM v$sysaux_occupants where occupant_name='SM/AWR'; Item Space Used (GB) Schema Move Procedure -------------- --------------- -------------------- ------------------ SM/AWR 13.0436401 SYS??通過v$sysaux_occupants視圖，可以查詢到AWR占用空間由之前的將近19GB降為了不到13GB。按照同樣的方法，回收下WRH$_EVENT_HISTOGRAM表的空間，這也是分區表表1794MB，只有一個索引(是主鍵)2499MB。
sys@IVLDB> select partition_name from dba_tab_partitions where table_name='WRH$_EVENT_HISTOGRAM'; PARTITION_NAME ------------------------------ WRH$_EVENT_HISTO_MXDB_MXSN WRH$_EVENT__1357933872_0 sys@IVLDB> alter table WRH$_EVENT_HISTOGRAM move partition WRH$_EVENT_HISTO_MXDB_MXSN;Table altered.
sys@IVLDB> alter table WRH$_EVENT_HISTOGRAM move partition WRH$_EVENT__1357933872_0;Table altered.
sys@IVLDB> select index_name from dba_indexes where table_name='WRH$_EVENT_HISTOGRAM'; INDEX_NAME ------------------------------ WRH$_EVENT_HISTOGRAM_PK sys@IVLDB> select partition_name from dba_ind_partitions where index_name='WRH$_EVENT_HISTOGRAM_PK'; PARTITION_NAME ------------------------------ WRH$_EVENT_HISTO_MXDB_MXSN WRH$_EVENT__1357933872_0 sys@IVLDB> alter index WRH$_EVENT_HISTOGRAM_PK rebuild partition WRH$_EVENT_HISTO_MXDB_MXSN;Index altered.
sys@IVLDB> alter index WRH$_EVENT_HISTOGRAM_PK rebuild partition WRH$_EVENT__1357933872_0;Index altered.
??清理WRH$_ACTIVE_SESSION_HISTORY和WRH$_EVENT_HISTOGRAM兩張表，SYSAUX表空間就釋放出10GB的空間，其他占用SYSAUX空間比較大的表也可以安裝這樣的方法去釋放空間，這里就不一一演示了。
??可能有人會問了，既然已經刪除了數據，那么如果不回收這部分空間，ORACLE就不會再使用這部分空間了嗎？為什么非要回收呢？這個高水位線的問題主要影響以下幾個方面，不只是使用SYSAUX表空間的表，對所有碎片較多的表都適用。
??1.影響查詢速度，因為這樣的表本身比較大，索引也會很大，查詢會很慢。
??2.消耗資源，因為表和索引都很大，查詢時會消耗很多I/O資源。
??3.空間占用，雖然大部分數據被DELETE掉了，但是這部分空間仍舊是這個段(SEGMENT)的區(EXTENT)，即使可以再利用也只能是這個表的新增數據才可以使用，而且還得是所在表空間無法自動擴展或者沒有足夠的擴展空間的情況下，如果表空間可以自動擴展或者有足夠的擴展空間，那么還是不會使用這部分空間的，這就導致表和索引會越來越大，占用的空間越來越大，而一旦將可擴展的空間用盡，那么其他表將無法擴展，DELETE掉的數據空間，其他對象是無法使用的。
??除了AWR的保留策略會影響SYSAUX表空間的使用率外，AWR收集數據的級別也對SYSAUX表空間的使用率影響很大，AWR收集數據的級別由statistics_level參數控制，這個參數有三個值，BASIC、TYPICAL、ALL，BASIC表示關閉統計信息收集，TYPICAL表示普通收集級別，只收集夠日常用的統計信息，ALL是最給力的，凡是ORACLE能收集的所有信息都要收集，所以生成數據量會很大，相對來說，對性能和占用空間的影響也是最大的，通常TYPICAL就已經夠用了。
??不同的版本statistics_level參數的默認值不同，有的版本默認值為ALL，有的版本默認值為TYPICAL，具體哪些版本使用ALL為默認值，我記不清了，如果您的數據庫設置statistics_level參數的值為ALL，建議調整為TYPICAL。
??如果您的數據庫也遇到了SYSAUX表空間很大的情況，建議在清理AWR數據時，回收這部分空間，對SYSAUX表空間的對象操作，基本不會影響數據庫的正常使用，SYSAUX表空間存放的對象都是數據庫運行非必須的對象，技術這個表空間損壞或者丟失，數據庫一樣可以正常運行
另外一種方式：
如果sysaux表空間使用率90%了，如何維護？？？
SYSAUX表空間做為SYSTEM表空間的輔助表空間，主要存放EM相關的內容以及表統計信息，AWR快照，審計信息等
23.1.修改統計信息的保持時間，默認為31天，這里修改為7天，過期的統計信息會自動被刪除
23.2.修改AWR快照的保存時間為7天(72460),每小時收集一次
SQL> begin dbms_workload_repository.modify_snapshot_settings ( interval => 60, retention => 10080, topnsql => 100 ); end; / 23.3.刪除AWR快照，再次查看SYSAUX表空間使用率,表空間使用率降低查詢最最小和最大快照ID：
select min(snap_id),max(snap_id) from dba_hist_snapshot;查看數據庫的DBID：
SQL> select dbid from v$database;DBID ---------- 1632800928通過最小、最大快照ID和DBID，刪除AWR快照：
begin dbms_workload_repository.drop_snapshot_range( low_snap_id => 9, high_snap_id => 215, dbid => 1632800928); end; /總結
以上是生活随笔為你收集整理的oracle system和sysaux表空间清理和回收的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： struts2 poi导出excel实例
- 下一篇： 文字冒险游戏html,文字冒险游戏-你敢