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: When stats trash your performance

Re: When stats trash your performance

From: stephen booth <stephenbooth.uk_at_gmail.com>
Date: Wed, 7 Dec 2005 21:56:58 +0000
Message-ID: <687bf9c40512071356j6ba64632o@mail.gmail.com>


On 07/12/05, Bobak, Mark <Mark.Bobak_at_il.proquest.com> wrote:
>
>
> Ultimately, I think there are two schools of thought here:
> 1.) If the system is stable, don't analyze objects. Leave the stats
> where they are, and Oracle will continue to supply stable execution plans.
> This is the "if it ain't broke, don't fix it" school of thought.
>
> 2.) Analyze early and often. The CBO is far smarter than I ever will
> be. The better my stats are, the better off my performance will be. This
> is the "I have faith in the church of Oracle. Oracle is the one true light,
> and the way." school of thought.
>

I tend to lean more towards the cautious "If it ain't broke don't fix it, unless it looks like there's a compelling reason to." Because we tend to run packaged apps from software vendors (this particular one is a Forms 6i app for managing planning permission applications) I tend to find out from them what they reccommend, assume they know the app better than me, until shown otherwise.

In my shop, we are fortunate enough to have a full preproduction environment
> which is equal in size to production. Every 3-6 months, we clone from prod
> into preprod, so we have fresh data.
>

That's what I'd like to do, but see comments about the organisation in my other replies.

Finally, I gotta ask: Why the heck are you bouncing for nightly backups on
> a production server? Hot backups are a good thing! ;-)
>
>

In this case it's a business hours only app so it's difficult to make an arguement for hot backups. There's also the fact that most of the databases we have are managed by people with little or no Oracle training or knowledge who have been running the same backup scripts for years so it's hard to get them to try something new. A couple of years ago I tried to get one of the DBAs at our FM supplier to consider hot backups (he'd been telling our management that making one of our systems 24x7 was unsupportable as we'd need at least one outage a week to do a cold backup) and his response was that hot backups are inherantly unreliable.

I'm looking at RMAN for our newer apps, many of which have to be 24x7.

Stephen

--
It's better to ask a silly question than to make a silly assumption.

http://stephensorablog.blogspot.com/

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Dec 07 2005 - 15:57:09 CST

Original text of this message

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