• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2168
  • Last Modified:

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!
  • 3
  • 3
  • 3
  • +1
1 Solution
Geert GruwezOracle 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 GruwezOracle 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
k3vsmithAuthor Commented:
Thanks for the quick response.
These are the top 10 objects in SYSAUX:

Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

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.
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 GruwezOracle 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
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?
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.
k3vsmithAuthor Commented:
Thank you all for your feedback. I have enough info to proceed.

Featured Post

NEW Veeam Agent for Microsoft Windows

Backup and recover physical and cloud-based servers and workstations, as well as endpoint devices that belong to remote users. Avoid downtime and data loss quickly and easily for Windows-based physical or public cloud-based workloads!

  • 3
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now