Re: table reorganizations

[Richard Foote]

Title: 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 ----- From: Mercadante, Thomas F To: Multiple recipients of list ORACLE-L 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 -----Original Message----- From: Shrake, Jolene [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 2:39 PM To: Multiple recipients of list ORACLE-L Subject: table reorganizations 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