| 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: Stop defragmenting and start ...
Cary's paper is the first such that I remember. It served as validation -
that I wasn't a raving radical (at least not in that respect). I started
doing "uniform extents" per tablespace in about 1991/1992 - within a year or
so of when we got Oracle6 (with the TPO option!). [It wasn't divine
inspiration then - a co-worker suggested it after we encountered some
"fragmented free space" issues and it just made sense.] At the time the
"recommended practice" was to size the initial extent large enough to hold
all the initial data and the next extent significantly smaller - with a
number of variations on the theme. "Recommended practice" then was also to
"export/import to compress extents". Of course, this is when backups were
always cold backups and users logged off and went home at 5 PM.
There were a number of such papers between Cary's and the "Stop Defragmenting and Start Living" (SDSL) paper, but they all seem to have been forgotten - the latter is the one you always hear about. I would say that it became "recommended practice" to set pctincrease 0 the first time you seriously considered the alternative - especially the default of pctincrease 50!
This is similar to the "tuning revolution" discussion of a couple of years ago. Good ideas and sound logic rarely prevail immediately on merit alone. They have to marinate in slow growth praxis, then there is a sort of community sense of profound revelation when they finally become generally accepted. For the death of the BCHR and such as the holy grail of tuning, that was IOUG-A Live! 2002 (?2001?). For uniform extents, I think it was about 1997/1998.
Speaking of uniform extents... I anyone else annoyed at the way that ASSM does extent sizing - and can waste a *lot* of space in multi-datafile tablespaces with large objects? Its the best argument I've seen yet for monster datafiles ;-)
-Don Granaman
uniformly sized OraSaurus
> I originally wrote this in 1994 as an engagement summary document for a
> power company in Colorado. I don't have the exact date anymore.
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> * Nullius in verba *
>
> Upcoming events:
> - Performance Diagnosis 101: 6/22 Pittsburgh, 7/20 Cleveland, 8/10 Boston
> - SQL Optimization 101: 5/24 San Diego, 6/14 Chicago, 6/28 Denver
> - Hotsos Symposium 2005: March 6-10 Dallas
> - Visit www.hotsos.com for schedule details...
>
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Wolfgang Breitling
> Sent: Thursday, June 10, 2004 2:13 PM
> To: oracle-l_at_freelists.org
> Subject: RE: Stop defragmenting and start ...
>
> My copy of Cary's paper "Oracle7 Server Space Management - An Oracle
> Services
> Advanced Technologies Research Paper", which was my first encounter with
the
>
> concept of uniform extents - and a certain Cary Millsap - is dated
"Revision
>
> 1.4b (95/10/31)"
> I was immediately hooked and converted.
>
> Quoting Lex de Haan <lex.de.haan_at_naturaljoin.nl>:
>
> > Robyn,
> >
> > I quickly checked my courseware archives,
> > and for sure Cary Millsap talked about uniform extent sizes in 1996.
> > to be more precise: he probably talked about this even before 1996,
> > but my private collection does not contain any hard evidence :-)
> >
> > Kind regards,
> > Lex.
> >
> > ---------------------------------------------
> > visit my website at http://www.naturaljoin.nl
> > ---------------------------------------------
> >
> >
> > -----Original Message-----
> > From: oracle-l-bounce_at_freelists.org
> > [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Robyn
> > Sent: Thursday, June 10, 2004 16:02
> > To: oracle-l_at_freelists.org
> > Subject: Stop defragmenting and start ...
> >
> >
> > Hello,
> >
> > Can someone tell me when uniform extent sizing became a recommended
> > practice? The 'Stop defragmenting and Start Living' paper has a
copyright
> > date of 1998, and I remember implementing it on some databases back in
> > 1999, but I was wondering if it there were earlier references to this
> > approach.
> >
> > Robyn
> >
> > ----------------------------------------------------------------
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > ----------------------------------------------------------------
> > To unsubscribe send email to: oracle-l-request_at_freelists.org
> > put 'unsubscribe' in the subject line.
> > --
> > Archives are at http://www.freelists.org/archives/oracle-l/
> > FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> > -----------------------------------------------------------------
> >
>
>
> --
> regards
>
> Wolfgang Breitling,
> Oracle 7,8,8i,9i OCP DBA; Oaktable member
> Centrex Consulting Corporation
> www.centrexcc.com
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Fri Jun 11 2004 - 23:41:21 CDT
 |
 |