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

Thanks. Here is related presentation:
http://www.soug.ch/fileadmin/user_upload/SIGs/SOUG_DAY2_160623/MultitenantBeyondDocumentation_-_12cR1_version_dbi_Pachot.pdf

On Wed, Jul 20, 2016 at 5:51 PM John McHugh <john.mchugh_at_oracle.com> wrote:

> Yes, in 2014 you posted a couple articles:
>
>
> http://blog.dbi-services.com/oracle-12c-cdb-metadata-a-object-links-internals/
>
> This is a good read to understand the dictionary architecture.
>
> thanks again,
> jpm
>
> Sent from my iPhone
>
> On Jul 20, 2016, at 12:39 AM, Ls Cheng <exriscer_at_gmail.com> wrote:
>
> I think he refers to a post which talks about metadata link and object link
>
>
>
> On Tue, Jul 19, 2016 at 11:44 PM, Franck Pachot <franck_at_pachot.net> wrote:
>
>> Thanks John. I don't know exactly which blog post you refer.
>> It don't think it's about licensing. You don't license what you install
>> but you license what you use. It's about consolidation. Look at the SYSTEM
>> tablespace on a freshly created database. hundreds of megabytes of PL/SQL
>> code for all those dbms_xxx packages. In non-CDB you have that for each
>> database. And when you patch/upgrade, you upgrade each of them. But they
>> are all the same (for same version). In multitenant you install them only
>> on CDB$ROOT and all pluggable databases (including PDB$SEED) links to it.
>> But if you want to be able to link to it, all must be there in CDB$ROOT.
>>
>>
>> On Tue, Jul 19, 2016 at 9:53 PM John Mchugh <john.mchugh_at_oracle.com>
>> wrote:
>>
>>> Yes Franck, thank you. And you have an excellent blog describing this.
>>> Would you be so kind to post a link to that blog here?
>>>
>>> thanks,
>>> jpm
>>>
>>>
>>> On Jul 19, 2016, at 12:41 PM, Franck Pachot <franck_at_pachot.net> wrote:
>>>
>>> Hi,
>>> All the system metadata (table, pl/sql, etc) related to features and
>>> options is stored in the CDB$ROOT. So, the CDB must have all options that
>>> may be used by one or more PDBs.
>>> Think of it like the oracle executable and libraries having all the code
>>> even when you don't use the options.
>>> CDB$ROOT is like an ORACLE_HOME but for the part of the software that
>>> resides in tables and stored procedures.
>>> Regards,
>>> Franck.
>>> Franck Pachot | Senior Consultant & Oracle Technology Leader | Oracle
>>> Certified Master 12*c* and Oracle ACE Director
>>>
>>>
>>> On Tue, Jul 19, 2016 at 8:37 PM Chris Taylor <
>>> christopherdtaylor1994_at_gmail.com> wrote:
>>>
>>>> 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