Connor, You obviously live a charmed life. _____ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Connor McDonald Sent: Wednesday, October 05, 2005 9:52 AM To: oracle-l@xxxxxxxxxxxxx Subject: 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 a) what happens to my backups - will they still fit on my existing secondary storage/tape b) will those backups complete within available windows c) archive log space ok ? d) what is collection and retrieval going to do my server resources, and my SLA's for responsiveness of the system e) 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@xxxxxxxx> 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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Connor McDonald Sent: Wednesday, October 05, 2005 5:02 AM To: oracle-l@xxxxxxxxxxxxx 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@xxxxxxxxx> wrote: On 10/4/05, Allen, Brandon < Brandon.Allen@xxxxxxxxxxx <mailto:Brandon.Allen@xxxxxxxxxxx> > 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@xxxxxxxxx web: http://www.oracledba.co.uk "Semper in excremento, sole profundum qui variat" -- Connor McDonald =========================== email: connor_mcdonald@xxxxxxxxx web: http://www.oracledba.co.uk "Semper in excremento, sole profundum qui variat"