Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: AUTOEXTEND

RE: AUTOEXTEND

From: Goulet, Dick <DGoulet_at_vicr.com>
Date: Wed, 5 Oct 2005 09:59:59 -0400
Message-ID: <4001DEAF7DF9BD498B58B45051FBEA6502D43EB0@25exch1.vicorpower.vicr.com>


Connor,  

    You obviously live a charmed life.


From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Connor McDonald
Sent: Wednesday, October 05, 2005 9:52 AM To: oracle-l_at_freelists.org
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

  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
<mailto: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
Received on Wed Oct 05 2005 - 09:03:34 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US