Re: 12c pluggable database shared SGA question

From: Kevin Closson <ora_kclosson_at_yahoo.com>
Date: Tue, 16 Sep 2014 08:03:24 -0700
Message-ID: <1410879804.29537.YahooMailNeo_at_web121206.mail.ne1.yahoo.com>

"However, with 10 instances on the machine, each with it's own DB

Console, it's own LGWR, DBWR, SMON, PMON, ..., I suspect that reclaiming those CPU cycles and therefore being able to put the same load on a smaller machine,"
"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.

Kevin Closson
Chief Performance Architect, XtremIO Business Unit EMC

---

 From: Hans Forbrich <fuzzy.graybeard_at_gmail.com> To: Freek D'Hooge <freek.dhooge_at_gmail.com> Cc: oracle-l_at_freelists.org
Sent: Thursday, September 11, 2014 1:16 PM Subject: Re: 12c pluggable database shared SGA question  

As I said Your Mileage May Vary. You may find that in your case, if you do a proper load-based benchmark, you may get 50% reduction in CPU usage, or you may get 5% reduction. One is conducive to using multiple PDBs, the other is not. Other parts of the thread have already discussed that disparity in actual workload may have a significant impact on whether multi PDBs are even feasible from am interactive perspective.

The SE discussion is a separate issue. If you need EE options -

      Spatial, Partitioning, Advanced Security, Advanced Compression,
      etc. - you can not fall back on SE.  So that particular discussion
      is potentially a red herring.  Al least until you start
      calculating the cost of electricity, floor space, cooling,
      networking (each server needs ports on the switch, and could force
      another switch), and management/administration overhead for having
      separate servers and more switches, at which time things may start
      looking different again.



"If I look at my customers" is EXACTLY THE POINT.  Look at your

      situation and do a proper and honest evaluation of the needs, the
      costs and the benefits.  In some cases multi-tenant might work out
      in your favour - I showed you some of my cases in which I can
      justify it.  In other cases it will not - and I also have those
      situations within my customer base as well.

We can discuss until we are blue in the face, and not achieve a
      'one size fits all' consensus, precisely because your situation is
      not the same as mine. 

However, we can provide a variety of different use cases and then
      each of us can evaluate our situations based on the experience of
      others and make our own decisions. 

/Hans

On 11/09/2014 12:11 PM, Freek D'Hooge wrote:

Hans,

But with the current price setting, the reduction in cpu resources

      would need to be more then 33% (list price EE $47.500 and
      multitenant $17.500) ....

Which seems very high to me...

As a standard edition license cost for a cpu socket the same

      amount as for 1 PDB option (which licenses 2 intel cores), I think
      it would often make more sense to put less important databases on
      separate standard edition licensed servers instead of using PDB's.

If I look at my customers, I don't see any benefit for them (at
      least not with the current price tag).
Hence my question if there are people out there who have a real
      business case that justify the multitenant cost.

Kind regards,

Freek

On do, 2014-09-11 at 10:58 -0600, Hans Forbrich wrote: I don't think the win is necessarily in the memory. However, with 10 instances on the machine, each with it's own DB Console, it's own LGWR, DBWR, SMON, PMON, ..., I suspect that reclaiming those CPU cycles and therefore being able to put the same load on a smaller machine, or consolidate more instances on the same machine, hopefully we will be able to reduce the overall CPU licenses (to be replaced by multi-tenant licenses). Basically, in my mind it amounts to the difference between getting 24 cores for individual instances, or 16 cores for multi-tenant instances. If I've just managed to save 1/3 of the CPUs and therefore reduced the licenses, and the energy footprint, by 1/3, I may have won. I say "may" because of the possible mixed-load and admin considerations that are discussed in other areas of this (and other) thread. As always YMMV, so Benchmark. This, by the way, is the exact same reasoning for using Cloud Control instead of a DB Control for each instance. Cloud Control is moved to a different machine and monitors many instances, and you therefore recoup the CPU cycles used to run the console from the DB box, where you pay by the CPU core. Setting aside Cloud Control HA configuration, which is an extra cost, the Cloud COntrol base configuration is included in your DB license. Back a number of year and versions, the DB Control's App Server used *significant* CPU and memory and in fact became one of the undetected performance bottlenecks on some server configurations because it's own overhead was outside the scope of what was measured. And yes, the numbers are different when considering SE. /Hans On 11/09/2014 10:23 AM, Freek D'Hooge wrote: > > This has me wondering since the moment I saw the cost for this option. > Has anyone a real business case in which the reduction in in memory > footprint and such has lowered the cost in such amount that it > outweighs the additional cost of the option? > Aside from sharing resources, what are the things that would make > managing PDB's so much more efficient that it justifies the price > Oracle charges you? -- http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l

Received on Tue Sep 16 2014 - 17:03:24 CEST