Re: 12c pluggable database shared SGA question
Date: Tue, 16 Sep 2014 13:52:31 -0400
Message-ID: <CA+fnDAY76=LeBfb-=_W8RK8hAau=TxbbjdbJPrnQihG1yBsh-g_at_mail.gmail.com>
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
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Sep 16 2014 - 19:52:31 CEST