RE: Autoextend or not?

From: SHEEHAN, JEREMY <Jeremy.Sheehan_at_fpl.com>
Date: Mon, 13 Apr 2009 08:13:11 -0400
Message-ID: <8833494F383585499CB855121711D2631391993C1D_at_JBXEXVS02.fplu.fpl.com>



I come from a house where we allowed for Autoextend, but we kept the file size managed. we just had a daily email that showed me what tablspaces had less than 1000mb left to grow. Where I worked, we kept a fairly consistent rate of growth so it really wasn't a big deal. I probably extended datafile sizes 3-4 times a month.

Where I work now, I'm having trouble adjusting. Here we allow for rampant datafile grow (set to autoextend/unlimited) and we rely on the SAN administrators to keep the systems going and keeping space available. Not really my preference!

Jeremy
 Consider the environment. Please don't print this e-mail unless you really need to.

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark W. Farnham Sent: Monday, April 13, 2009 8:02 AM
To: cicciuxdba_at_gmail.com; 'oracle-l'
Subject: RE: Autoextend or not?

Whether to turn autoextend on or not depends on far too many issues and varied situations of infrastructure, performance requirements, and acceptable costs of operations for anyone to claim there is a "best practice."

However, please be clear that turning autoextend on does NOT require you to rely on autoextend. You can still plan and make allocations such that expected growth plus a reasonable margin for error will avoid autoextend actually taking place. On some of your databases you might consider autoextention a routine event and on other databases you might consider autoextention actually taking place to be an operational error.

Likewise, you can work with the operating system team to give them growth estimates far enough ahead so they can work with your storage procurement folks to avoid being between a rock and a hard place. Planning a disk farm tends to produce a disk farm that functions better, even if deployed to merely avoid hot spots rather than to maximize throughput. Even if you are just adding media to an ASM disk group, planning when to add it so that dynamic rebalancing takes place when it is more convenient instead of when your system is busiest just makes sense.

Having a safety net does not require you to fall off the trapeze. (Except of course on your test systems, where you should in fact test all your safety nets.)

Eliminating the reasons for your lack of trust in both areas should become a priority for you. I would suggest you start with something like "In order to to my job correctly, I need to be able to know that..." rather than "You're all buffoons I wouldn't trust with my lunch order..."

Regards,

mwf

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Guillermo Alan Bort
Sent: Monday, April 13, 2009 5:33 AM
To: oracle-l
Subject: Autoextend or not?

So,

   We have a debate going on about allowing databases with datafiles with autoextend on... anybody has any input on this? any experience?

My side: I don't like autoextend, I can't trust the unix team to do their job and I can't allow for a datafile to fill up the FS. Then again, I can't trust monitoring tools to do their job, so autoextend *could* save the day.

thanks, and kind regards to all!
Alan Bort
Oracle Certified Professional
--

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

--

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

i0zX+n{+i^ Received on Mon Apr 13 2009 - 07:13:11 CDT

Original text of this message