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

From: Chris Taylor <christopherdtaylor1994_at_gmail.com>
Date: Tue, 19 Jul 2016 09:49:16 -0500
Message-ID: <CAP79kiRE5=6DqUBTJ8v8c--26Bv+O4W=JPhGDFKTN-JhRxZc8w_at_mail.gmail.com>

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?

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?

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?

It just seems like this should have raised some engineering red flags along the way unless there's something I'm not seeing.

Chris

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

Received on Tue Jul 19 2016 - 16:49:16 CEST