Re: 12c pluggable database shared SGA question

From: Kevin Closson <ora_kclosson_at_yahoo.com>
Date: Tue, 16 Sep 2014 09:08:51 -0700
Message-ID: <1410883731.5151.YahooMailNeo_at_web121205.mail.ne1.yahoo.com>

Actually, I don't know enough about it to be skeptical and thus my quest for AWRs. I'm on back-channel with Hans on the same topic.

I am, however, skeptical that there is any problem getting enough DRAM bolted to modern CPUs given the fact that there are no frontside bus systems left to buy. Sure, dense DRAM is more expensive but the question is whether the expense of going from, say, 512GB to 768GB on the same 2S box is more expensive than $17.5K/core + 22% (in perpetuity)?

Finally, I'm always skeptical of solutions to problems that no longer exist--such as main memory capacities. Everything we know in IT has a shelf life.

---

 From: Jeremy Schneider <jeremy.schneider_at_ardentperf.com> To: my42clips <ora_kclosson_at_yahoo.com>; "fuzzy.graybeard_at_gmail.com" <fuzzy.graybeard_at_gmail.com>; Freek D'Hooge <freek.dhooge_at_gmail.com> Cc: "oracle-l_at_freelists.org" <oracle-l_at_freelists.org> Sent: Tuesday, September 16, 2014 9:03 AM Subject: Re: 12c pluggable database shared SGA question  

On Tue, Sep 16, 2014 at 11:03 AM, Kevin Closson <dmarc-noreply_at_freelists.org> wrote:

>
>"you may get 50% reduction in CPU usage, or you may get 5% reduction."
>
>... Does anyone have an AWR report showing background DB CPU greater than, say, 10% of cpu count? I'd like to study such a workload.

I'm also skeptical about significant cpu reduction.

IMHO, the main point of pluggable is memory rather than CPU. Many apps (ebusiness? peoplesoft?) have multiple schemas and really it's just too complicated to do schema-level consolidation of multiple instances of the app. So you end up with one database for each instance - test, dev, qa, etc. Which means one SGA for each database. If you have a lot of these instances, you might have underutilized servers just because of the memory limitations on your company's standard hardware platform. With pluggable, you can now get the memory efficiencies of schema-level consolidation but from the app's perspective it thinks that it still has it's own DB. If it reduces the number of physical servers you need, then that can cut licensing costs. But the core reason isn't a cpu usage reduction, it's a bunch of idle CPUs in the first place because memory constraints were preventing the optimal level of consolidation.

Also, if your app already can do schema-level consolidation, then you've already got something better than pluggable in many ways.

-J  

--
http://about.me/jeremy_schneider
--
http://www.freelists.org/webpage/oracle-l

Received on Tue Sep 16 2014 - 18:08:51 CEST