SYSAUX tablespace

My manager has tasked me with purging some space from the SYSAUX tablespace in one of our databases that has grown large. He asked me to do this by doing the following:
Find large objects in tablespace
Export tables out
Remove OEM related data and anything else we can purge
Import back in which will remove the tablespace and renter it with the smaller data

My manager has left for a few weeks vacation and Id like to get this task complete for him although I need assistance. Im able to find the large objects in tablespace but dont know what is related to OEM, nor do I know what is capable of being purged from SYSAUX without messing up the database? Can any of you give me some insight? Thanks!
Who is Participating?
SurranoConnect With a Mentor System EngineerCommented:
1. Buy license.
Otherwise you are not allowed to delete, change retention-- nothing.

2. Check snapshot range to delete:
SELECT snap_id, begin_interval_time, end_interval_time FROM SYS.WRM$_SNAPSHOT
WHERE snap_id = ( SELECT MIN (snap_id) FROM SYS.WRM$_SNAPSHOT) and instance_number=1
SELECT snap_id, begin_interval_time, end_interval_time FROM SYS.WRM$_SNAPSHOT
WHERE snap_id = ( select start_snap_id-1 from dba_hist_baseline) and instance_number=1;

Open in new window

3. If there is only one row: nothing to delete.
If there are two rows: substitute the snap_id values to the following command:
exec dbms_workload_repository.drop_snapshot_range(low_snap_id => 10147, high_snap_id=>10210); 

Open in new window

4. To persistently adjust configuration, reduce retention as follows:
select * from  DBA_HIST_BASELINE; 
-- reduce AWR moving window size (example below with 4 days, specified in days)
exec DBMS_WORKLOAD_REPOSITORY.modify_baseline_window_size(window_size => 4);
-- reduce AWR retention parameter (same 4 days, specified in minutes)
-- check results
select * from  DBA_HIST_BASELINE; 

Open in new window

But as I said even this is a temporary solution; AWR will eventually grow over time to the limits of the tablespace.
Geert GOracle dbaCommented:
see an aud$ table in sysaux tablespace ?
if so then auditing is switched on and still in sysaux tablespace.

it has to be moved to a different tablespace to be able to purge it
see here for a very detailed explanation
Geert GOracle dbaCommented:
you could also set the purging policies to get rid of the old data in oem

allthough that might not retrieve the used tablespace
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

k3vsmithAuthor Commented:
Thanks for the quick response.
These are the top 10 objects in SYSAUX:

Praveen Kumar ChandrashekatrDatabase Analysist Senior Commented:
the most of the objects is  OEM, AWR ,ASH  and LOB related objects. A LOB segment stores data for a CLOB/BLOB table column.
SurranoSystem EngineerCommented:
Bad news:
- AWR cannot be completely turned off
- *Any* manipulation of AWR data needs appropriate (paid) licenses (not included in Enterprise Edition)
- AWR snapshot size will grow over time (this is a known issue) so even deleting old snapshots is not a final solution, because the snapshot will eventually reach the size where only one snapshot fits.

Good news:
- AWR data is not needed for everyday operation, nor for mere mortals like DBAs, only for Oracle Support Requests. (you are allowed to provide them requested AWR information even if you don't have the license)
- Oracle handles the case when SYSAUX is full with no problems. In worst case some AWR stuff will fail. So what.

So you should apply two measures:
- ensure that SYSAUX tablespace is limited in size (e.g. current size + 10% would do)
- modify your DB free space checking tools so that they don't raise alarms on SYSAUX tablespace being 100% full.
Geert GOracle dbaCommented:
That's the trap everyone falls into
this is not true
(you are allowed to provide them requested AWR information even if you don't have the license)

it's stated in the license that support will ask your for AWR data because they are oblivious to what you are entitled to by your license
it's up to you (the dba) to know if you are licensed to that

after that the license people come in: i see you use AWR but aren't license for it
here's your extra fee you need to pay

so be careful with that
SurranoSystem EngineerCommented:
Well we are more foxy than that.

Oracle Support: "Please send AWR Reports"
Me: "I'm sorry but we don't have the necessary licenses."
Oracle Support: "That's no problem, Sir. Please send them."

Once we have it written in an email Oracle shouldn't complain, maybe they should subtract the license fee from the annual bonus of that given support expert. :P
k3vsmithAuthor Commented:
Thank you guys for the help. Do you guys have any insight as to how best to remove AWR data?
k3vsmithAuthor Commented:
Thank you all for your feedback. I have enough info to proceed.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.