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

And that's what I was trying to get to (or at): The primary reason it was built this particular way. Because it creates a highly coupled (and frankly, FAT) application in total. And I'm curious at the driving motivation here. I can only imagine it has to do with reducing licensing complexity overall.

The closest analogy to what I would have "thought" that it would make more sense to build a CDB:PDB relationship much like a server where:

MainServer (CDB) with Many LUNS (PDBs) - each LUN could be picked up and moved independently to another MainServer but in this case they can't unless the CDB has the same options installed.

Which leads to this decision point when Oracle was building this setup: 1. Do we install every option in the CDB so that anyone can pick up a PDB and plop it down any where (This is what Oracle chose) OR 2. Do we allow a PDB to be picked up and moved without the options being required in the CDB (this could have been engineered and I think more flexible and lean)

Chris

On Tue, Jul 19, 2016 at 3:44 PM, Dimensional DBA < dimensional.dba_at_comcast.net> wrote:

> This more for simplicity of design, simplicity of coding and simplicity of
> licensing.
>
>
>
>
>
>
>
> *Matthew Parker*
>
> *Chief Technologist*
>
> *Dimensional DBA*
>
> *425-891-7934 <425-891-7934> (cell)*
>
> *D&B *047931344
>
> *CAGE *7J5S7
>
> *Dimensional.dba_at_comcast.net <Dimensional.dba_at_comcast.net>*
>
> *View Matthew Parker's profile on LinkedIn*
> <http://www.linkedin.com/pub/matthew-parker/6/51b/944/>
>
> www.dimensionaldba.com
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Chris Taylor
> *Sent:* Tuesday, July 19, 2016 1:42 PM
> *To:* Franck Pachot
> *Cc:* John Mchugh; ORACLE-L
> *Subject:* Re: Multi-Tenant Question - Oracle chose HIGH COUPLING - why?
>
>
>
> But this is only because the decision was made to "build it that way"
> right? I mean, they could have built it where the PDBs were solely
> independent of the CDB other than for Memory/Storage/Network definitions.
> Right?
>
>
>
> For example, if I'm building a container object, I don't throw in
> everything that a child object might reference do I? The child object can
> reference whatever it needs when it needs it. It doesn't _have_ to be part
> of the parent container.
>
>
>
> Here's why this is interesting to me. Take APEX for example, or OLAP, or
> DBV.
>
>
>
> It's in the CDB, therefore it's in the SEED PDB. At a minimum, we have 1
> master and 1 duplicate of the same application. Now we build another PDB,
> and it gets APEX and OLAP and DBV also. Now we have 3 copies, or
> iterations of the same product.
>
>
>
> The only reason I can think of "why" this is, is because those options are
> licensed at the instance layer and not at the PDB layer.
>
>
>
> Chris
>
>
>
>
>
> On Tue, Jul 19, 2016 at 2: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
>
>
>

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