Re: Additional CPU justification

Mark is moving the answer into the direction of my first thoughts: we're all assuming that the current workload cannot be improved upon, in terms of its resource usage.

It wouldn't be the first time that I see a database spending 80-90% time on something that can easily be "tuned".

On Wed, Mar 22, 2017 at 2:23 AM, Mark W. Farnham <mwf_at_rsiz.com> wrote:

> Back to the original question (the suggestions were all reasonable):
>
>
>
> But if you want to know which resource is your limiting factor, get
> yourself a good profiling tool (*cough* Method-R was built by some
> friends), and see what you’re waiting for that might help out the business
> queries you care most about.
>
>
>
> Of course surprising results of the limiting factor often leads directly
> to some sql that should be optimized, and it may save you from adding
> resources at all. Or at least you’re more likely to add the more important
> thing.
>
>
>
> mwf
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_
> freelists.org] *On Behalf Of *Jack Applewhite
> *Sent:* Tuesday, March 21, 2017 5:29 PM
> *To:* oracle-l_at_freelists.org; backseatdba_at_gmail.com
> *Subject:* Re: Additional CPU justification
>
>
>
> Jeff,
>
>
>
> If you're going to Linux you should consider Oracle Linux. Also, get some
> SSDs for that server. The huge performance improvement of implementing
> Database Smart Flash Cache is available under Oracle Linux and Solaris -
> only those two OS's.
>
>
>
> We have two X5 ODAs with a lot of Prod DBs on them. Each ODA node (server)
> has 256GB of RAM, 20 cores lit up, with one shared 512GB SSD per ODA. Our
> main Prod DBs are running on the the two nodes of one of the ODAs, each
> with about a 50GB SGA.. They were straining the ODA nodes at times - Load
> Averages of up to 80 or so (which is 400%), with a lot of that being I/O
> waits.
>
>
>
> We turned on Flash Cache and have been utterly stunned at the performance
> improvement for each DB. We rarely have L.A.'s over 20 (100%) anymore.
> Flash Cache extends the Buffer Cache to the SSD and manages it. We've seen
> waits on DB File Sequential Read go way, way down.
>
>
>
> As you know memory and disk are much, much cheaper than Oracle CPU
> licenses. SSDs have come way down. Licensing Oracle Linux looks like a
> fairly inexpensive proposition, though I haven't done so standalone - OL is
> just part of the ODA package, which we love.
>
>
>
> Hope this helps.
>
> --
> Jack C. Applewhite - Database Administrator
> Austin I.S.D. - MIS Department
> 512.414.9250 (wk)
>
> I can't help about the shape I'm in,
> I can't sing, I ain't pretty and my legs are thin.
> But ... -- "Oh Well" F.M.
>
>
>
>
> ------------------------------
>
> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on
> behalf of Jeff Chirco <backseatdba_at_gmail.com>
> *Sent:* Tuesday, March 21, 2017 3:07 PM
> *To:* oracle-l_at_freelists.org
> *Subject:* Additional CPU justification
>
>
>
> Hi everyone, I am working on trying to make a case that our production
> database server needs some additional CPU's but was hoping you might be
> able to give me some tips/suggestion that you've used to prove your case.
> We are a smaller shop and so we currently only have a 2 CPU database
> license and so the cost of doubling that plus all the packs and options we
> have is not an easy thing to pass.
> We currently running 11.2.0.4 on Windows but plans to move to Oracle Linux
> this year and possibly 12c at that time.
>
> We occasionally spike to 80-100% during the day but average around 40%
>
> Thanks for any help.
>
> Jeff
>
> Confidentiality Notice: This email message, including all attachments, is
> for the sole use of the intended recipient(s) and may contain confidential
> student and/or employee information. Unauthorized use of disclosure is
> prohibited under the federal Family Educational Rights & Privacy Act (20
> U.S.C. §1232g, 34 CFR Part 99, 19 TAC 247.2, Gov’t Code 552.023, Educ. Code
> 21.355, 29 CFR 1630.14(b)(c)). If you are not the intended recipient, you
> may not use, disclose, copy or disseminate this information. Please call
> the sender immediately or reply by email and destroy all copies of the
> original message, including attachments.
>

-- 
Toon Koppelaars
RuleGen BV
Toon.Koppelaars_at_RuleGen.com
www.RuleGen.com
TheHelsinkiDeclaration.blogspot.com

(co)Author: "Applied Mathematics for Database Professionals"
www.RuleGen.com/pls/apex/f?p=14265:13

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