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? -- //www.freelists.org/webpage/oracle-l
