Re: 12c pluggable database shared SGA question
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: my42clips <ora_kclosson@xxxxxxxxx>, "fuzzy.graybeard@xxxxxxxxx" <fuzzy.graybeard@xxxxxxxxx>, "Freek D'Hooge" <freek.dhooge@xxxxxxxxx>
- Date: Tue, 16 Sep 2014 12:03:03 -0400
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:
