RE: table reorganizations

From: Mercadante, Thomas F <thomas.mercadante_at_labor.state.ny.us>
Date: Fri, 09 Jan 2004 04:49:28 -0800
Message-ID: <F001.005DC430.20040109044928@fatcity.com>

Chris,

I would argue that in your two examples, nothing needs to be done if you are using Locally Managed Tablespaces. All of the free space that your deletes generated would be reused by new inserts. When you say "not good for FTS", I think you are wrong. Have you tried testing this statement? How much "slower" is it?

Of course, I am talking about using Oracle 9i. Prior versions behaved much differently.

Tom Mercadante
Oracle Certified Professional

-----Original Message-----
Sent: Friday, January 09, 2004 6:09 AM
To: Multiple recipients of list ORACLE-L

Richard,

I agree there are a number of reasons for reorganising tables. LMTs remove the
need to reorganise a tablespace but not to reorganise a table. Two further real-
ilfe examples of table reorgs:

The purge programs have at last been written and run deleting data > 2 years old. The system's been running for 4 years. So in simple terms most of the tables are approx 50% empty. You need to reorg in this case.
A "transaction log" table is inserted to throughout the day and most of the night. A clear down processing job runs at the end of the day and deletes all the rows its processed, but more rows are being added. So the table is now < 1% full. Not good for FTS. So instead of a conventional reorg we implemented a nightly "table-swap". This meant locking the source table, copying it's contents to a replica empty single extent table, target table. The names of the target and source tables are swapped, hence "table-swap". The new source table is now available to the application and the original source is truncated and

ready to be the target in 24 hrs time.

Cheers,

Chris Dunscombe

Quoting Richard Foote <richard.foote_at_bigpond.com>:

> MessageHi 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:JEShrake_at_Pella.com]
> 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
>

Chris Dunscombe

chris_at_thedunscombes.f2s.com

Everyone should have http://www.freedom2surf.net/

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: 
  INET: chris_at_thedunscombes.f2s.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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Mercadante, Thomas F
  INET: thomas.mercadante_at_labor.state.ny.us

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 Fri Jan 09 2004 - 06:49:28 CST