Message
Hi Thomas,
Never say never (oh bugger, I've just gone and done
it myself).
A large table accessed via a FTS for various
important reporting requirements has permanently shrunk in size from 10G to
100M (say list of Informix customers ;)
Business requirements have changed and you need to
add some columns to a table resulting in mucho row
migration.
You were told (incorrectly) that rows would grow
significantly after loading (honestly) but now the 80 pctfree value you've set
is causing problems for other really important reports.
There are of course other cases but you
get my point ;)
Cheers
Richard
----- Original Message -----
Sent: Thursday, January 08, 2004 6:34
AM
Subject: RE: table reorganizations
Jolene,
Tables should never *need* to be reorganized. This is an old
falacy. If you know how big a table is going to grow, say in a year,
then place it in a Locally Managed tablespace with extent sizes to hold enough
data for one year (say 1M).
You
should never have to reorganize a table.
Tom Mercadante
Oracle Certified Professional
What SQL
statement do you use to identify tables that need
reorganization?
How do you
identify tables that are used in full table scans? How often do you
run this query?
Thanks,
Jolene
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Richard Foote
INET: richard.foote_at_bigpond.com
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: ListGuru_at_fatcity.com (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 Thu Jan 08 2004 - 06:24:35 CST