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@xxxxxxxxxxx> 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@xxxxxxxxxxx <Dimensional.dba@xxxxxxxxxxx>*
*View Matthew Parker's profile on LinkedIn*
<http://www.linkedin.com/pub/matthew-parker/6/51b/944/>
www.dimensionaldba.com
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *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@xxxxxxxxxx> 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
