Re: 12c pluggable database shared SGA question
- From: "Kevin Closson" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "ora_kclosson@xxxxxxxxx" for DMARC)
- To: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>, "fuzzy.graybeard@xxxxxxxxx" <fuzzy.graybeard@xxxxxxxxx>, Freek D'Hooge <freek.dhooge@xxxxxxxxx>
- Date: Tue, 16 Sep 2014 09:08:51 -0700
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@xxxxxxxxxxxxxx>
To: my42clips <ora_kclosson@xxxxxxxxx>; "fuzzy.graybeard@xxxxxxxxx"
<fuzzy.graybeard@xxxxxxxxx>; Freek D'Hooge <freek.dhooge@xxxxxxxxx>
Cc: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
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
Other related posts:
