| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: table reorganizations
Tom,
In my first example you are right that new inserts would use the space freed by the deletes but the purge program is run every quarter (sorry for not stating that explictly earlier). Therefore there is at most 2.25 years worth of data in the tables when before the first purge there was 4 years. Hence I believe the table reorg is valid for both disk space savings and performance.
In my second example the amount of data loaded into the "transaction log" table can vary dramatically due to "double-day" processing caused by public holidays etc. Therefore if the table wasn't reorganised daily the table would end up being at least twice as large as necessary and therefore impcat the performance of FTS.
These examples were both on 8i but I don't think 9i would make any difference. Pls let me know the details if 9i does make a difference.
Cheers,
Chris
Quoting "Mercadante, Thomas F" <thomas.mercadante_at_labor.state.ny.us>:
> 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:
>
> 1) 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.
>
> 2) 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).
>
Chris Dunscombe
chris_at_thedunscombes.f2s.com
-- 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).Received on Mon Jan 12 2004 - 03:59:25 CST
 |
 |