Re: 12c pluggable database shared SGA question

There are a number of test cases documented here that get into background cpu utilization, memory savings, throughput (tps), IOPS of PDBs vs non-CDB dbs, density, elasticity, etc.


http://www.oracle.com/technetwork/database/multitenant/learn-more/oraclemultitenantt5-8-final-2185108.pdf

At
identical CPU utilization, PDBs achieve an 80% higher aggregate throughput than non-CDBs
with slightly elevated response times and save 1.5 GB memory per database. The
sharing of background processes allows PDBs to aggregate work–mainly log
writing and flushing of database blocks–more efficiently, freeing CPU resources
that can now be used for query processing instead, which results in higher
throughput. While response times for non - CDB s are lower, they come at an
enormous cost of not only loss in throughput, but also a 19 times higher redo
log write rate. This requires the storage to sustain more than 100,000 IOPS for
log writing alone (compared to 5,000 IOPS for all PDBs together), which –
depending on the workload – might result in lack of storage performance for
buffer 
cache
misses or other storage operations (i.e. backup and restore). Considering this
cost, an increase of response times by only 3ms appears to be more than
tolerable for an 80% throughput gain.

-------

Read that white paper, the authors executed and documented a variety of test cases and measured the impacts.

Job




________________________________
 From: Kevin Closson <dmarc-noreply_at_freelists.org>
To: "jeremy.schneider_at_ardentperf.com" <jeremy.schneider_at_ardentperf.com>; Mark W. Farnham <mwf_at_rsiz.com> 
Cc: "Glenn.Travis_at_sas.com" <Glenn.Travis_at_sas.com>; "rajendra.pande_at_ubs.com" <rajendra.pande_at_ubs.com>; Seth Miller <sethmiller.sm@gmail.com>; Oracle-L <Oracle-L@freelists.org> 
Sent: Tuesday, September 16, 2014 2:32 PM
Subject: Re: 12c pluggable database shared SGA question
 


>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%.


Is it generally believed that BG processes on idle databases consume any appreciable CPU? 




________________________________
 From: Jeremy Schneider <jeremy.schneider_at_ardentperf.com>
To: Mark W. Farnham <mwf_at_rsiz.com> 
Cc: Glenn.Travis_at_sas.com; "rajendra.pande_at_ubs.com" <rajendra.pande_at_ubs.com>; Seth Miller <sethmiller.sm_at_gmail.com>; Oracle-L <Oracle-L@freelists.org> 
Sent: Tuesday, September 16, 2014 10:52 AM
Subject: Re: 12c pluggable database shared SGA question
 


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