Deleting Statspack tables.

From: Reddy, Madhusudana <Madhusudana.Reddy_at_bestbuy.com>
Date: Tue, 10 Jun 2003 11:32:39 -0700
Message-ID: <F001.005AE7D4.20030610111451@fatcity.com>

Hello All,
We have a job ( shell Script ) which deletes from the statspack tables every Sunday, but uses SPPURGE.sql ( $ORACLE_HOME/rdbms/admin). Seems like it is not deleting all tables and hence causing the tablespace to grow. Does anybody has a different approach which deletes all table without any referential integrity issues ??

I do not want to use SPTRUNC.sql please.

Pl find below some of the statspack tables are growing so big ( also Indexes /PKs ).

STATS$BG_EVENT_SUMMARY                  7
STATS$ROWCACHE_SUMMARY                  8
STATS$SGASTAT                           8
STATS$LATCH_PARENT                     10
STATS$SYSTEM_EVENT                     19
STATS$ROLLSTAT                         37
STATS$LATCH                            50
STATS$SYSSTAT                          51

TABLE                          Size in MB
------------------------------ ----------
STATS$PARAMETER                        56
STATS$LATCH_MISSES_SUMMARY             84
STATS$SQLTEXT                         122
STATS$FILESTATXS                      234
STATS$SQL_SUMMARY                     886
STATS$LATCH_CHILDREN                 2872 ( These are just tables , didnt show indexes

here)

Thank You ,
Madhu Reddy

--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Reddy, Madhusudana
INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Tue Jun 10 2003 - 13:32:39 CDT