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@xxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@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 12c and Oracle ACE Director
On Tue, Jul 19, 2016 at 8:37 PM Chris Taylor
<christopherdtaylor1994@xxxxxxxxx> 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@xxxxxxxxxx>
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@xxxxxxxxx> 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 configuration
rules 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
