Re: AUTOEXTEND

There's always exceptions to every rule, but lets say there is suddenly a "came-from-nowhere" requirement to collect bucketloads more audit information. In that case, before I turn on auto-extend - I'm asking the customer/client about

1. what happens to my backups - will they still fit on my existing secondary storage/tape
2. will those backups complete within available windows
3. archive log space ok ?
4. what is collection and retrieval going to do my server resources, and my SLA's for responsiveness of the system
5. if its RAC, what instance(s) is that audit data being grabbed from - is my interconnect going to be toasted

gotta be thinking that in order to get answers to those questions, I'll at least have a reasonable idea of how much data I'm gonna get (and hence obviate the need for autoextend). If the customer can't give me answers - then the next thing is to ask them to sign off as "no guarantees" on all the things above.

Cheers
Connor

On 10/5/05, Goulet, Dick <DGoulet_at_vicr.com> wrote:
>
> Connor,
> I respectfully disagree. We laid out a production database based of the
> end user's requirements and the desires of the 3rd party provider. All went
> just fine for 6 months, until the auditors tossed the proverbial monkey
> wrench into the works. Right now we still do not know how large this
> database is going to grow since we've now got nothing to base our estimates
> on. BTW: neither do the auditors. Now how do you plan for the unknown??
> Dick Goulet
>
> ------------------------------
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Connor McDonald
> *Sent:* Wednesday, October 05, 2005 5:02 AM
> *To:* oracle-l_at_freelists.org
> *Subject:* Re: AUTOEXTEND
>
> On non-production systems - autoextend works fine for me.
>
> On production systems - well I'm inclined to think that you should never
> need it. After all, you already know roughly how and when the database is
> going to grow (even if its sporadic). After all, thats one of the reasons we
> have non-production systems - to work all this stuff out before it goes
> live.
>
> If on a production system, your in a position where you're thinking: "I
> really don't know when or by how much this system is gonna grow by", then
> your customers have every right to be doubting your capacity to effectively
> manage that database.
>
> Cheers
> Connor
>
> On 10/5/05, Niall Litchfield <niall.litchfield_at_gmail.com> wrote:
> >
> > On 10/4/05, Allen, Brandon < Brandon.Allen_at_oneneck.com> wrote:
> >
> > > Another disadvantage that hasn't been mentioned yet is the performance
> > > impact - if a user is inserting rows and fills up the tablespace to the
> > > point it has to extend, then the end user has to incur the cost of waiting
> > > for the file to extend. This is avoided if the DBA anticipates the growth
> > > and manually pre-extends the datafile, or adds another data file to the
> > > tablespace.
> > >
> >
>
>
> --
> Connor McDonald
> ===========================
> email: connor_mcdonald_at_yahoo.com
> web: http://www.oracledba.co.uk
>
> "Semper in excremento, sole profundum qui variat"
>

--
Connor McDonald
===========================
email: connor_mcdonald_at_yahoo.com
web: http://www.oracledba.co.uk

"Semper in excremento, sole profundum qui variat"

--
http://www.freelists.org/webpage/oracle-l