Re: Autoextend Data files - Corruption???

Maybe I should have qualified that a little more !! In my production environment I have a very good handle on what is growing and what is expected - so I react - pro-act accordingly - I have thresholds set with warnings that give me enough time to extend tablespaces after I examine WHY. When autoextend is invoked, a runaway process or some other bizarre circumstance, can fill up a directory or mount point and bring your system to an abrupt halt. I definitely do not use autoextend in development or test 'cause usually developers do not size their table defaults. Also, I have a set of standard datafile size increments that optimize my disk usage. When you have a bunch of oddball sized datafiles and need to re-structure your database it can be a nightmare and effectively a jigsaw puzzle to deal with.

Past experince has proved it for me.

Thnx

Kip.Bryant_at_Vishay.com wrote:

> Hi,
>
> Could you elaborate a little about why you are "dead against" it?
>
> Kip
>
> |I have encountered problems pre 7.3.4 with resize (I am dead against autoextend
> |- a non-issue in our shop) but have had no problems in my 8.0.5 and 8.1.5
> |environments - resizing UP and DOWN !!
>
> |"Thapliyal, Deepak" wrote:
>
> |> 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-----
> |> Sent: Thursday, June 08, 2000 12:48 PM
> |> To: Multiple recipients of list ORACLE-L
> |>
> |> 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
> |> also send the HELP command for other information (like subscribing).
> |> --
> |> Author: Thapliyal, Deepak
> |> INET: DThapliyal_at_ea.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: Chris Royce
> | INET: Chris_at_Royce.net
>
> |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
Received on Fri Jun 09 2000 - 20:22:11 CDT