RE: RE: Locally Managed Tablespaces

FWIW I've come to think of autoextend as a valuable ally in certain cases.

When loading data it's nice to enable autoextend when you don't know how large you really need to have the database files. Create several and set autoextend on, being sure that if all were to fill up, it won't fill up
the drive, as that can cause some sticky problems.

When upgrading a database, I may set autoextend on on the SYSTEM datafiles so they don't run out.

Along the same lines, I set maxextents to unlimited and monitor the number of extents so that it is not unreasonable. Better to have a couple thousand
extents during a data load that someone 'forgot' to inform you about than to have the job die in the middle of the night.

I think my 'reasonable' # of extents must be higher than yours Jacques. :)

Jared

Jacques Kilchoer <Jacques.Kilchoer_at_quest.com> Sent by: root_at_fatcity.com
 03/21/2003 11:00 AM
 Please respond to ORACLE-L  

        To:     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        cc: 
        Subject:        RE: RE: Locally Managed Tablespaces

> -----Original Message-----
> From: rgaffuri_at_cox.net [mailto:rgaffuri_at_cox.net]
>
> thanks in case I happen to work on a 7.3 database....
>
> what kind of pctincrease should I set? What about the other
> settings? Just curious.

The current thinking is that uniform extents are a good thing. So in 7.3, try and "manually" enforce uniform extents: initial = next for all clusters/tables/indexes in the same tablespace pctincrease=0 for all objects
These should of course be the settings for the DEFAULT STORAGE clause on the create tablespace. Then to create a cluster/table/index you can (should?) use tablespace defaults and skip the storage parameter on the CREATE cluster/table/index statement.
My personal opinion: always use maxextents unlimited but put your object in a tablespace where the values of INITIAL and NEXT will prevent the object from having more than 1000 extents. Autoextend datafiles: my personal opinion is don't use those, because you should have an idea of how and when your database is going to grow, and if you need more space it's nice to be aware of it. Of course this means the risk of failure when a datafile is full, but the same thing can happen Received on Fri Mar 21 2003 - 17:22:03 CST