Re: 12c pluggable database shared SGA question
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: "Mark W. Farnham" <mwf@xxxxxxxx>
- Date: Tue, 16 Sep 2014 13:52:31 -0400
Trying to summarize a few ideas from this thread so far:
Potential efficiencies with multitenant:
- fewer background processes (lower process count, lower cpu to the extent
that bg proc cause cpu)
- more flexible utilization of memory
- plug-based upgrades
Things not impacted by multitenant:
- cpu caused by your app
- i/o
- workloads on the same server will affect each other
Issues:
- in recovery, redo for all pdbs is read
- questionable whether potential efficiencies above could reduce overall
cpu count enough to offset PDB licensing cost
===
you know i'm thinking more about the cpu thing, and i actually wouldn't
look for an awr report where cpu is >10% of cpu count -- i'd look for a
database where bg cpu is higher than fg cpu. which could conceivably
happen if the fg cpu is very very low. consolidate 50 of those completely
idle databases on a single server and suddenly you've got a case where pdb
may reduce cpu usage by 50%.
kevin - there certainly isn't a problem with memory capacity from the
hardware perspective. high-profile projects certainly do get to pick their
own hardware. however david's peoplesoft case, for example, may not have a
dedicated platform architect on the team and may have to choose their kit
from a catalog of internal standardized platforms. and anyway, sure you
can attach a TB of ram to a server... but would it be preferable to
consolidate a bunch of peoplesoft databases into a single SGA and use a
little less memory? from a technical perspective, are there downsides to
very large-memory configurations?
-J
--
http://about.me/jeremy_schneider
Other related posts:
