Re: 12c pluggable database shared SGA question
Date: Thu, 11 Sep 2014 14:16:07 -0600
Message-ID: <54120307.8040004_at_gmail.com>
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-lReceived on Thu Sep 11 2014 - 22:16:07 CEST