so for normal business you should not use autoextend? You should monitor it yourself? What are some tips for monitoring the database to see if you need to extend your tablespace manually? Do you use DBMS_ALERT and read the v$ views and then broadcast a message if you need to extend a tablespace? ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Friday, March 21, 2003 6:38 PM
> 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 <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 03/21/2003 11:00 AM > Please respond to ORACLE-L > > > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > cc: > Subject: RE: RE: Locally Managed Tablespaces > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > 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 > with autoextend when the disk gets full. > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: > INET: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: Ryan INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
