You are on page 1of 4

Managing SYSAUX tablespace

The size of the SYSAUX tablesp52ace is determined by the size of the database components that occupy SYSAUX. See Table 2-2 for a list of all SYSAUX occupants. Based on the initial sizes of these components, the SYSAUX tablespace needs to be at least 240 MB at the time of database creation. The space requirements of the SYSAUX tablespace will increase after the database is fully deployed, depending on the nature of its use and workload. The largest portion of the SYSAUX tablespace is occupied by the Automatic Workload Repository (AWR). The space consumed by the AWR is determined by several factors, including the number of active sessions in the system at any given time, the snapshot interval, and the historical data retention period. A typical system with an average of 10 concurrent active sessions may require approximately 200 to 300 MB of space for its AWR data. You can control the size of the AWR by changing the snapshot interval and historical data retention period. For more information on managing the AWR snapshot interval and retention period.

1. Run the this query to get the exact SYSAUX Tablespace Size
SELECT /* + RULE */ df.tablespace_name "Tablespace", df.bytes / (1024 * 1024) "Size (MB)", SUM(fs.bytes) / (1024 * 1024) "Free (MB)", Nvl(Round(SUM(fs.bytes) * 100 / df.bytes),1) "% Free", Round((df.bytes - SUM(fs.bytes)) * 100 / df.bytes) "% Used" FROM dba_free_space fs, (SELECT tablespace_name,SUM(bytes) bytes FROM dba_data_files GROUP BY tablespace_name) df WHERE fs.tablespace_name (+) = df.tablespace_name GROUP BY df.tablespace_name,df.bytes UNION ALL SELECT /* + RULE */ df.tablespace_name tspace, fs.bytes / (1024 * 1024), SUM(df.bytes_free) / (1024 * 1024), Nvl(Round((SUM(fs.bytes) - df.bytes_used) * 100 / fs.bytes), 1), Round((SUM(fs.bytes) - df.bytes_free) * 100 / fs.bytes) FROM dba_temp_files fs, (SELECT tablespace_name,bytes_free,bytes_used FROM v$temp_space_header GROUP BY tablespace_name,bytes_free,bytes_used) df

WHERE fs.tablespace_name (+) = df.tablespace_name GROUP BY df.tablespace_name,fs.bytes,df.bytes_free,df.bytes_used ORDER BY 4 DESC; 2. Run the below query which components and their sizes. SELECT occupant_name, round( space_usage_kbytes/1024) "Space (M)", schema_name, move_procedure FROM v$sysaux_occupants ORDER BY 1; 3. Next thing retrieve the oldest and latest AWR snapshot. SELECT snap_id, begin_interval_time, end_interval_time FROM SYS.WRM$_SNAPSHOT WHERE snap_id = ( SELECT MIN (snap_id) FROM SYS.WRM$_SNAPSHOT) UNION SELECT snap_id, begin_interval_time, end_interval_time FROM SYS.WRM$_SNAPSHOT WHERE snap_id = ( SELECT MAX (snap_id) FROM SYS.WRM$_SNAPSHOT); 4. Now use the dbms_workload_repository package to remove the AWR snapshots.
BEGIN dbms_workload_repository.drop_snapshot_range(low_snap_id => 341, high_snap_id=>400); END;

displays

the

various

sysaux

Taken from: reports.html

http://remidian.com/oracle/purging-sysaux-tablespace-purging-awr-

Solution-2
SQL> select * from DBA_HIST_WR_CONTROL; DBID SNAP_INTERVAL RETENTION TOPNSQL ---------- ---------------------------------------- --------------------------------------- ---------3406903167 +00000 01:00:00.0 +00004 00:00:00.0 DEFAULT <= Retention is 4 days SQL> select min(snap_id),MAX(snap_id) from dba_hist_snapshot; MIN(SNAP_ID) MAX(SNAP_ID) ------------ -----------8377 17324 <= Huge snapshots are there. Can be dropped.

SQL> show parameter statistics NAME statistics_level timed_os_statistics timed_statistics TYPE string integer boolean VALUE ALL 5 TRUE <= Should be set TYPICAL

------------------------------------ ----------- -----------------------------

Check whether the retention period is set too high. In this case, it is set to 4 and so no need to modify the retention. If it is set to high value, then consider reducing the retention period to avoid growing of space. By default, it is set to 7 days. The new retention time is specified in minutes. SQL> execute DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (retention => 4320); Here 4320 is 3*24*60 ( Convert the days to minutes). For 3 days, it 4320 minutes. Next thing is to check the amount of snapshots have been generated and available. If this is too high, then try to drop the unwanted snapshots to reclaim the space. SQL> exec dbms_workload_repository.drop_snapshot_range (low_snap_id, high_snap_id); low_snap_id : The low snapshot id of snapshots to drop. high_snap_id : The high snapshot id of snapshots to drop.

Then check whether the statistics_level parameter is set to typical. If it is set to ALL, please change it to TYPICAL. Because statistics_level=ALL will gather lot of additional information in AWR repository which would consume more space. Most of the cases, if the statistics_level is set to TYPICAL then the growth would be stopped. SQL> alter system set statistics_level=typical; If none of the above suits as everything is set proper then consider clean up and rebuild AWR repository to clear all the space. SQL> connect / as sysdba SQL> @?/rdbms/admin/catnoawr.sql SQL> @?/rdbms/admin/catawrtb.sql

You might also like