SYSAUX tablespace growing rapidly

Saturday, December 3, 2011

I have an Oracle 11g R2 (11.2.0.1) database where I noticed the SYSAUX tablespace was growing larger every day.  Searched Oracle My Support and found Doc ID 1292724.1 and Doc ID 552880.1 which were helpful.

After running awrinfo.sql, I found the largest consumer to be SM/OPTSTAT at 2.8 GB which is larger and not typical when compared to my other Oracle 10g R2 and Oracle 11g R1 databases.

********************************************************
(1b) SYSAUX occupants space usage (v$sysaux_occupants)  
********************************************************
|                                                       
| Occupant Name        Schema Name               Space Usage
| -------------------- -------------------- ----------------
| SM/OPTSTAT           SYS                        2,726.8 MB
| SM/AWR               SYS                           76.6 MB
| SM/ADVISOR           SYS                            8.2 MB
| LOGMNR               SYSTEM                         7.9 MB
| SM/OTHER             SYS                            6.8 MB
| JOB_SCHEDULER        SYS                            3.6 MB

**********************************
(4) Space usage by non-AWR components (> 500K)
**********************************

COMPONENT        MB SEGMENT_NAME                            SEGMENT_TYPE  
--------- --------- --------------------------------------- --------------
NON_AWR       800.0 SYS.I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST      INDEX         
NON_AWR       752.0 SYS.WRI$_OPTSTAT_HISTGRM_HISTORY        TABLE         
NON_AWR       424.0 SYS.I_WRI$_OPTSTAT_H_ST                 INDEX         
NON_AWR       240.0 SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY       TABLE         
NON_AWR       192.0 SYS.I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST       INDEX         
NON_AWR       104.0 SYS.I_WRI$_OPTSTAT_HH_ST                INDEX

Searching Google, I came upon John Hallas’ “Purging statistics from the SYSAUX tablespace” blog entry quite informative and detailed on managing occupants in the SYSAUX tablespace.

As John mentions:

“Whenever statistics in the dictionary are modified, old versions of statistics are saved automatically for future restoring. The old statistics are purged automatically at regular intervals based on the statistics history retention setting and the time of recent statistics gathering performed in the system. Retention is configurable using the ALTER_STATS_HISTORY_RETENTION procedure. The default value is 31 days.”

To help reduce the amount of space caused by historical data, I set the retention of old statistics to 14 days.

exec dbms_stats.alter_stats_history_retention(14);

To verify the new setting, I executed the statement below.

select dbms_stats.get_stats_history_retention from dual;

I proceeded to incrementally purge statistics from 31 days to 14 days.  Started with 28 days, then moved to 21 days.

exec dbms_stats.purge_stats(sysdate-28);

Then I tried 14 days, however I encountered an UNDO space error requiring me to change my increments using 18, 16, and finally 14 to complete the purge task.

Now to reclaim the space used by the objects shown in section 4 of the AWRINFO report, I will eventually follow John Hallas’ steps using the ALTER TABLE MOVE command.


SQL Server Script – Size of all tables in a database

Monday, October 10, 2011

While researching information regarding vCenter database retention policy, I stumbled upon this SQL script which displays the number of rows and the physical size of all tables in a specified database.


Capacity Specs for SQL Server

Tuesday, September 27, 2011

Recently referenced the Maximum Capacity Specifications for SQL Server information.  The link provides information for SQL Server 2008 R2, 2008, 2005, and Denali.


Killing a Data Pump Job

Tuesday, January 26, 2010

Another lesson learned in using Oracle 11g Data Pump was being able to attach and kill an existing Data Pump job using the ATTACH command.  This is done either during the existing Data Pump job by using Ctrl-C to get the prompt and executing the KILL_JOB command:

% expdp / full=y dumpfile=dp_test.dmp logfile=dp_test.log directory=expdumpdir job_name=dp_fullexp

Export: Release 10.2.0.4.0 - 64bit Production on Saturday, 16 January, 2010 13:36:18

Connected to: Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
Starting "OPS$ORACLE"."DP_FULLEXP":  /******** full=y dumpfile=dp_test.dmp logfile=dp_test.log directory=expdumpdir job_name=dp_fullexp
Estimate in progress using BLOCKS method...
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA

^C
Export>  kill_job
Are you sure you wish to stop this job ([yes]/no): yes

Or you can attach from a separate session and kill the job from there by executing the KILL_JOB command:

% expdp / attach=ops\$oracle.dp_fullexp

Export: Release 10.2.0.4.0 - 64bit Production on Saturday, 16 January, 2010 13:54:00

Connected to: Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

Job: DP_FULLEXP
Owner: OPS$ORACLE
Operation: EXPORT
Creator Privs: FALSE
GUID: 7D4BF0976ED665ABE04400144FA165B2
Start Time: Saturday, 16 January, 2010 13:52:07
Mode: FULL
Instance: d105
Max Parallelism: 1
EXPORT Job Parameters:
Parameter Name      Parameter Value:
CLIENT_COMMAND     /******** full=y dumpfile=dp_test.dmp
logfile=dp_test.log directory=expdumpdir
job_name=dp_fullexp
State: EXECUTING
Bytes Processed: 0
Current Parallelism: 1
Job Error Count: 0
Dump File: /disk01/oraexport/dp_test.dmp
bytes written: 4,096

Worker 1 Status:
State: EXECUTING

Export> kill_job
Are you sure you wish to stop this job ([yes]/no): yes

In your original Data Pump session, you will see the job has been terminated:

% expdp / full=y dumpfile=dp_test.dmp logfile=dp_test.log directory=expdumpdir job_name=dp_fullexp

Export: Release 10.2.0.4.0 - 64bit Production on Saturday, 16 January, 2010 13:52:03

Connected to: Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
Starting "OPS$ORACLE"."DP_FULLEXP":  /******** full=y dumpfile=dp_test.dmp logfile=dp_test.log
directory=expdumpdir job_name=dp_fullexp
Estimate in progress using BLOCKS method...
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA

Job "OPS$ORACLE"."DP_FULLEXP" stopped due to fatal error at 13:54:18


Oracle 11g Data Pump

Monday, January 18, 2010

Along with installing Oracle 11g for the first time, I want to utilize Oracle 11g Data Pump to replace the prior exp/imp utilitiy in my Solaris 10 environment.

Setup is quite simple to get started.  First, create a directory object in the database:

CREATE DIRECTORY expdumpdir AS '/u01/oraexport';

Then grant the approriate privileges on that directory object:

GRANT READ,WRITE ON DIRECTORY expdumpdir TO mydba;

One difference encountered between Oracle 10g and Oracle 11g is the compression variable.  In Oracle 10g you can compress metadata only, which is the default option:

COMPRESSION = (METADATA_ONLY | NONE)

However in Oracle 11g, you have the added options of compressing data, metadata, or both:

COMPRESSION = (ALL | DATA_ONLY | METADATA_ONLY | NONE

In my search for additional compression information, I found some debate on the better process when comparing the Data Pump compression approach with the expdp/gzip approach.

A nice comparison example of Oracle 11g Data Pump vs. OS compression utility (gzip) can be found on RajaBaskar Thangaraj’s blog.

Also encountered an error based on the value of my database COMPATIBLE parameter.  After installing Patch 8833297 – 11.1.0.7.1 Patch Set Update (October 2009 PSU), this value was set to 11.1.0.7.1.

% expdp / dumpfile=my11gdb.dmp logfile=my11gdb.log full=y directory=expdumpdir job_name=my11gdb_fullexp compression=all

Export: Release 11.1.0.7.0 - 64bit Production on Wednesday, 13 January, 2010 11:42:09

Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
ORA-39001: invalid argument value
ORA-39021: Database compatibility version 11.1.0.7.1 is not supported.

By default, Data Pump uses the value set in your COMPATIBLE parameter.  The value I have set, 11.1.0.7.1, is obviously not valid.  To correct the problem, I simply added the VERSION=LATEST parameter to the command line and the process completed successfully.

% expdp / dumpfile=my11gdb.dmp logfile=my11gdb.log full=y directory=expdumpdir job_name=my11gdb_fullexp compression=all version=latest

My usage of Oracle Data Pump at the moment is very basic.  However I have attended at least one presentation by Arup Nanda showing additional uses of Data Pump which is quite versatile depending upon your needs.


Follow

Get every new post delivered to your Inbox.