Re: Multi-Tenant Question - Oracle chose HIGH COUPLING - why?

So, if I'm reading this correctly, it's about licensing then? Because the options (OLAP, Data Vault) are licensed at the CDB (instance layer) ? That would make sense if that's the driving factor. Otherwise you would (could) have different PDBs attached with different licensed components. PDBA might have DV and PDB2 might have OLAP and you'd have to manage a household of options for just one CDB. Am I close, or still missing "it"?

Chris

On Tue, Jul 19, 2016 at 11:58 AM, John Mchugh <john.mchugh_at_oracle.com> wrote:

> Hi Chris,
>
> let me see if I can clarify these questions. See inline responses...
>
>
> On Jul 19, 2016, at 7:49 AM, Chris Taylor <
> christopherdtaylor1994_at_gmail.com> wrote:
>
> As I'm learning the multi-tenant technology with 12c, I'm struck by the
> following ODD choice that Oracle made. I feel certain there's a reason
> (and perhaps a good one) why Oracle chose to increase COUPLING instead of
> building independent, low dependence modules?
>
>
> Actually it was not an Oracle decision per se, but Oracle responding to
> customer demand.
>
> Here's what I'm talking about: (Note: 2001512.1)
>
>
>
>
> *Oracle recommends the creation of a container database with all options
> as that configurationrules out any option related mismatch problems while
> unplugging and plugging a PDB from one container to another. However
> customers have often asked whether it is possible to create a container
> database with a subset of options. Although it is still recommend to create
> a CDB with all options, this document outlines a supported method of
> creating a CDB with the options that the customer chooses to install.*
>
> And (Note: 1616554.1)
>
> *Oracle generally recommends that a CDB should have all options
> installed in order to avoid any issues with the plug-in of a PDB from
> another environment.*
>
> It seems to me that this over complicates the situation unnecessarily but
> I'm sure there must be a good reason.
>
> Why doesn't it make more sense to have the CDB as a "brain" that doesn't
> really care about what options are installed in a PDB. Why does the CDB
> need all the options installed to properly plugin another PDB that has some
> "x" option installed?
>
>
> This was exactly the initial intent where the CDB, as the ‘brain’, which
> has all of the options available such that any PDB plugged in that requires
> a specific option would have that option available. This avoids the
> complexities of placement and maximizing consolidation density where if
> this were not the case, you would need to map PDBs to CDBs providing the
> specific option and consolidation density would be negatively impacted. ULA
> customers obviously have no problem w/ this, however, other customers did
> not want to incur the licensing implications for all options. Hence, the
> MOS note which describes the cumbersome 12.1 steps limit the options
> configured in the CDB. This gets much, much better in 12.2 in terms of ease
> of configuration and licensing.
>
>
> Wouldn't it make more sense for the CDB to ambivalent about what options
> the PDB has and just be the controller instead of having these created
> dependencies between the CDB and the PDBs it controls?
>
>
> The CDB cannot be ‘ambivalent’ to the options required by the PDB. The
> architecture is what we refer to as in-database virtualization where we
> have a pristine, master copy of the Oracle data dictionary in CDB$ROOT. For
> this reason, CDB$ROOT will have all dictionary references for all options
> configured. PDBs use object and/or metadata links to resolve
> inter-dictionary dependencies between the PDB dictionary and the CDB$ROOT
> dictionary. It is required that the PDB have all or a subset of options
> installed in the CDB$ROOT. Otherwise, you get the plug in violation warning
> until the dependencies are resolved.
>
>
> It just seems like this should have raised some engineering red flags
> along the way unless there's something I'm not seeing.
>
>
> Let me know if this answers your questions. This dictionary relationship
> is really the core of Multitenant and gives us many opportunities for
> future development.
>
> thanks,
> jpm
>
>
>
> Chris
>
>
>
>
>
>

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