RE: Autoextend Data files - Corruption???

a little bird once told me that resize/autoextend df has known to lead towards dB corruptions ..
anyone out there seen that happen to their db"s

tia
-deepAk

-----Original Message-----
From: Kip.Bryant_at_Vishay.com [mailto:Kip.Bryant_at_Vishay.com] Sent: Thursday, June 08, 2000 12:48 PM
To: Multiple recipients of list ORACLE-L Subject: RE: Autoextend Data files - Pros & Cons

Hi,

I held off from using autoextend initially for about the same reasons noted below but finally started using it (except for rollback and temp tablespaces)
so I could rest a little easier when I'm "away." My growth is usually pretty
linear. Anyway, the only negative side effect for me so far is that my alert
that watches for table-won't-be-able-to-take-next-extent (straight out of the
manual) starts squawking until the table does need to take that extent and the
tablespace extends. I have a junior staff person looking at correcting this

problem as a training exercise...anyone have a script? ;)

Kip

|> Advantages: you don't have to worry that someone will run a
|> program that
|> will cause a table to extend and it will fail for lack of space
|>
|> Disadvantages: you don't KNOW that they have extended, so you have to
|> monitor it very carefully, because what you REALLY want to know is if the
|> tables are extending quickly so that you can size them better
|>
|That's why I do trending... I capture growth in tables and indexes, and can
|even see the tablespaces. This is usually weekly, and anything that grows
|more than one extent I take a close look at.

|But, as I said before, I'd rather grow it. I've seen some that may extend
|1-2 times a week simply because they don't extend that much at a time and
|they have hundreds of objects. I'd rather resize it for 1-6 months and
|concentrate on the objects and keeping them under control.

|I've got one customer whose table is about to take the last extent, but I
|know that won't happen for 7-8 weeks due to historical patterns. (The table
|has room for 40,954 records and they grew 5,903 last week) That gives me
|time to contemplate splitting it over two drives, and maybe even moving the
|indexes. I've had my eye on this one for almost 2 months now, so I knew
|almost 4 months before it would have become critical.

|Michael Kline
|ThinkSpark
|Richmond, VA
|804-744-1545

|--
|Author: Michael Kline
| INET: maklinesr_at_home.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).

-- 
Author: 
  INET: Kip.Bryant_at_Vishay.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