RE: Auto Extend

>Neither large files nor small files are evil. As with all
>things, fit the
>solution to the problem.
>Small files can leave you with lots of separate datafiles which isn't
>necessarily a drag on performance but can be an administrative
>chore and can
>cause more wasted space due to that pesky 'end-of-datafile'
>free extent.

Mike, I will have to disagree with you about small files not necessarily being a drag on performance. Given a specific size of a database, it would be better to go in for larger files (avoiding the >2Gb pitfall if possible) since each datafile adds its own component to the flurry of I/O activity that takes place during log switch, i.e. when all datafile headers need to be updated.

In simpler terms, (Large number of) Small datafiles + small redo logs + high DML activity = disaster during (the frequent) log switches...

>People who want to
>set up databases larger than a terabyte will inevitably have a
>budget to invest
>in new kit and buy-in to up to date OS and software levels.
>Not everyone has
>that luxury and a lot of legacy kit doesn't like 2GB+ files.
>
>That's only my opinion but really, why play around with any
>area that is
>demonstrably strewn with bugs unless you need to?

Fully agreed!

John Kanagaraj

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: John Kanagaraj
  INET: john.kanagaraj_at_hds.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).