RE: Negative ramifications of setting CPU_COUNT lower?
Date: Fri, 6 Nov 2009 17:01:51 -0500
Message-ID: <091A72CCF0844621B41C30AE199F9DC7_at_rsiz.com>
I'll take the opportunity to fix two typos "too small and SGA" should be "too small an SGA" and "disabus" should be "disabuse." I don't know where these gremlins come from that depress keys on my keyboard that differ from what my mind is directing and omit characters I'm sure I have typed.
And although I think Dan got my sentiment about right, I just wanted to note for the record I did not type or utter the phrase "best practice." In general I think people mean "the way I do it and you're stupid if you try anything else" when they type "best practice" though I suspect Dan is an exception to that general rule and means it in a kind fashion and only uses it at all because even a fine fellow like Dan cannot completely resist being taken over by market speak under his current employment arrangement. So if you strike out "best practice" and replace it with "a pretty good starting point that might turn out to be good enough" then you've captured my sentiment exactly. And I think that is also Oracle's goal: Get the settings right out of the box most of the time just by looking at the system you're running on. It ain't perfect yet, and they shouldn't even be trying to make it perfect - but it is doggone good.
Of course that's no reason to treat warnings as errors. But I think I've already beaten that dead horse several times. PETA please note the horse was already dead when I started beating it.
Regards,
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Dan Norris
Sent: Friday, November 06, 2009 2:14 PM
To: mwf_at_rsiz.com
Cc: sacrophyte_at_gmail.com; ORACLE-L
Subject: Re: Negative ramifications of setting CPU_COUNT lower?
Note that "instance caging" is enabled by using database resource manager in conjunction with setting cpu_count. I don't think it answers your questions, but it is relevant as it is a case where setting the cpu_count is necessary. I agree with Mark that, in general, letting Oracle determine and use its defaults is best practice--especially when going to a new release.
Anyway, here's the info from the 11.2 docs on instance caging: http://download.oracle.com/docs/cd/E11882_01/server.112/e10595/dbrm007.htm#A DMIN13333 Dan
On Fri, Nov 6, 2009 at 12:32 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:
Oracle has done some really marvelous work coming up with really pretty good automated guesses at good starting points for the various knobs and switches and even more impressive work about dynamically adjusting them to the workload. The upshot is that unless you're doing something specfically different for a real world reason (which includes not perturbing a working systems' settings), you should at least give Oracle's defaults a chance to succeed, especially in a fresh environment.
The downside of the success of such efforts is a re-surgence of the notion that they can calculate ratios of values that should be forbidden, case in point too small and SGA in the face of a lot of CPUs on a system. We tried really, really hard circa 1990-1995 under Oracle VLDB and MOSES to disabus Oracle of the notion of every having any artificial limitations, and for a time we succeeded. Give us the live hand grenade, was the phrase, and if we're not careful it is our fault, not yours. Every single time (EVERY SINGLE TIME) I have ever seen an artificial limitation injected into the settings it has caused someone a problem sometime. Using the various resources to predict good defaults is one thing; using them to inject error conditions that do not need to be errors is another. Even if it had only warned that the sga was probably too small the user problem would have gone away naturally. And of course once someone gets the idea that artificial limits (rather than automated good starting points and warning about dubious choices) are an acceptable thing, hilarity ensues. 20 lashes with a wet noodle to the manager who dropped the ball on this one. And I INSIST it is a dropped ball (with the obvious warning the corrective in the general case).
Then there is the whole substance issue on threads and equivalent horsepower and 9 women trying to have a baby in one month, but my intention in this contribution is only to wiegh in against any artificial limitations. SAAAL? (society against any artificial limitations)?
Regards,
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Charles Schultz
Sent: Friday, November 06, 2009 9:47 AM
To: ORACLE-L
Subject: Negative ramifications of setting CPU_COUNT lower?
Good day,
We recently moved 55 databases from a Sun F15K to a Sun T5440. You can imagine what happened next. =)
Reading Glenn Fawcett's blog
<http://blogs.sun.com/glennf/entry/virtual_cpus_effect_on_oracle> , we
indeed see that CPU_COUNT = 256. I have filed an SR with Oracle, but as I
wait I am curious if those of you in the know could tell me what are the
negative ramifications of resetting CPU_COUNT. If we go forward with this
action, I want to do so in an informed manner, and not simply shooting in
the dark.
Thanks.
-- Charles Schultz -- http://www.freelists.org/webpage/oracle-lReceived on Fri Nov 06 2009 - 16:01:51 CST