RE: DB12c in Production?
Date: Fri, 6 Jun 2014 08:49:28 -0400
Message-ID: <114d01cf8185$c202ca70$46085f50$_at_rsiz.com>
A single PDB in a multi-tenant architecture does not invoke the multi-tenant upcharge in any license documentation I have seen. IF it did, I think all of Niall’s concerns would be valid.
Multiple container databases (each with one PDB) on a single machine (or RAC cluster) would emulate the existing architecture with no upcharge for being “containerized.”
No fee would be invoked for moving a PDB from one container to another (as long as the total tenant count of any container is 0 or 1.) That feature supports unplug – plug upgrades (although there are technical considerations about flashback history and point-in-time recovery to the past that should be carefully considered.)
I believe Hans is correct.
The terminology IS strained, because they started calling it “multi-tenant” to promote that feature AS IF every containerized database deployment will in fact have greater than 1 PDB resident.
The huge growth in process count of background jobs (which facilitates not time slicing each other for waits) makes deploying multiple databases expensive in machine resource footprint.
Figuring out the license cost matrix (can I use a smaller enough chip count due to process reduction so that license is less by enough to pay for the upcharge for multi-tenant at resident count over 1) to net benefit seems difficult to forecast.
The logical obstacles to database consolidation remain, for example patch cycles and support certification. The multitenant architecture DOES help with that by creating the possibility of a small number of “containers” each at a different release level, with the PDBs smoothly moving forward by the unplug – plug upgrade operation without forcing consolidation on databases that should not be consolidated. So if you have 10 databases that would be awkward to consolidate, maybe having only, say, 3 containers up and running would be sufficient and reduce the background process count to 30 percent of what it would have been. How many chips will that save? I don’t know. It seems like a one-off calculation for each implementation.
Unless your salesman’s name is Ed Rearick, you probably have to figure out your own best net benefit. (Ed sold computers for Sequent, and he believed getting the best value matrix to his customers ultimately paid off for his customers, his company, and himself in the long run. Plus he slept like a baby. Oh how I wish we could clone him to be deployed as an Oracle saleman!)
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Jeremy Schneider
Sent: Friday, June 06, 2014 8:04 AM
To: niall.litchfield_at_gmail.com
Cc: fuzzy.graybeard_at_gmail.com; John Hallas; oracle-l_at_freelists.org
Subject: Re: DB12c in Production?
Is the extra cost option for using PDBs at all or is it for having more than one PDB?
-Jeremy
-- http://about.me/jeremy_schneider Sent from my iPhone On Jun 6, 2014, at 6:20 AM, Niall Litchfield <niall.litchfield_at_gmail.com> wrote: On Thu, Jun 5, 2014 at 9:52 PM, Hans Forbrich <fuzzy.graybeard_at_gmail.com> wrote: Three things come to mind 1) The non-multi-tenant architecture is known as the 'Pre-12c' architecture. In other words, in the future, we will have no choice. I agree that the wording and marketing tends to point in that direction. However I consider it unlikely that the old architecture will disappear any time soon for one major reason. Multi-tenant has been introduced as an extra cost option, and its an option I think a reasonable number of customers, but by no means all will pay for. A future decision for Oracle to drop support for the option would have to do one or more of the below (or some other smart alternative).Received on Fri Jun 06 2014 - 14:49:28 CEST
* make multi-tenant part of the base license killing a revenue stream.
* make existing customers who don't see value in multi-tenant pay for it (reducing a revenue stream).
* make it cost neutral or advantageous to move to multi-tenant (perhaps by playing with overall discount rates for those who purchase it)
* allow multi-tenant for SE customers
I suspect that any of the above will be difficult and have unexpected side effects. -- Niall Litchfield Oracle DBA http://www.orawin.info -- http://www.freelists.org/webpage/oracle-l