Create Container Databases (CDB) with less options – it’s now supported in Oracle

When Oracle Multitenant was launched Roy and I amongst many other people always mentioned that the requirement of having all options in a Container Database (CDB$ROOT), and therefore also for the PDB$SEED with the immediate result that all PDBs provisioned from the PDB$SEED will have all options as well, will hinder customer adoption significantly. But this has been changed now. You can create Container Databases (CDB) with less options – it’s now supported in Oracle

Create Container Databases (CDB) with less options – it’s now supported in Oracle

Almost all customers I have talked to in the past 3-4 years about Oracle Multitenant mentioned immediately that it will be a huge problem for them to install all options as (1) their policy is to install only things they are licensed for to (2) prevent developers, users and DBAs to use things accidentally without even knowing that this or that will require a license.

As it is not allowed to manipulate and change the PDB$SEED. Your best workaround – as PDBs were allowed to have less options – was simply to create a stand-alone Oracle 12c database with exactly the options you’d like to have. This would become your gold standard. Then you’d plug it in under a remarkable name, for instance PDB$MASTER. In addition you need to switch it to read only (recommended but not necessary anymore in Oracle 12.2 onwards). From now on you must make sure that you’ll provision a new PDB always as a clone from PDB$MASTER instead of PDB$SEED.

All Options in a CDB

That would even work in the Single Tenant case. As long as you have only one PDB it is not required to licene the Oracle Multitenant option. But in this case you’d have the PDB$MASTER always unplugged. The provisioning would mean that you’ll have to plug it in as a new PDB. This sounds quite complicated.

Now this will become all obsolete as from now you it is allowed to have a CDB installation with less options. This applies to linked kernel modules (e.g. RAT) as well as to configured database components (e.g. JAVA, OWM, SPATIAL etc).

The important MOS Notes

Please see the following new/rephrased MOS Notes:

MOS Note:2001512.1 basically explains the following steps:

  • Do all the click-work in DBCA (Database Creation Assistant) to create a container database – but let DBCA only create the scripts
  • Edit the <SID>.sql script and remove the unwanted options according to the dependency table in the MOS Note
  • Edit the CreateDBCatalog.sql in case you want to remove OWM (Oracle Workspace Manager) creation as well
  • Add the Oracle PERL $ORACLE_HOME/perl/bin in front of your $PATH variable
  • Start the <SID>.sh script on the shell prompt

Here’s an example of a CreateDBCatalog.sql and a XXXX.sql creating a CDB with no options except XDB (which is mandatory in Oracle Database 12c):

cat CreateDBCatalog.sql
connect "SYS"/"&&sysPassword" as SYSDBA
set echo on
spool /u01/app/oracle/admin/XXXX/scripts/CreateDBCatalog.log
alter session set "_oracle_script"=true;
alter pluggable database pdb$seed close;
alter pluggable database pdb$seed open;
host perl
/u01/app/oracle/product/ -n 1
-l /u01/app/oracle/admin/XXXX/scripts -b catalog
host perl
/u01/app/oracle/product/ -n 1
-l /u01/app/oracle/admin/XXXX/scripts -b catproc
host perl
/u01/app/oracle/product/ -n 1
-l /u01/app/oracle/admin/XXXX/scripts -b catoctk
-- host perl
/u01/app/oracle/product/ -n
1 -l /u01/app/oracle/admin/XXXX/scripts -b owminst
host perl
/u01/app/oracle/product/ -n 1
-l /u01/app/oracle/admin/XXXX/scripts -b pupbld -u
connect "SYSTEM"/"&&systemPassword"
set echo on
spool /u01/app/oracle/admin/XXXX/scripts/sqlPlusHelp.log
host perl
/u01/app/oracle/product/ -n 1
-l /u01/app/oracle/admin/XXXX/scripts -b hlpbld -u
SYSTEM/&&systemPassword -a 1
spool off
spool off
cat XXXX.sql

set verify off
ACCEPT sysPassword CHAR PROMPT 'Enter new password for SYS: ' HIDE
ACCEPT systemPassword CHAR PROMPT 'Enter new password for SYSTEM: ' HIDE
host /u01/app/oracle/product/ file=/u01/app/oracle/product/ force=y format=12
-- @/u01/app/oracle/admin/XXXX/scripts/JServer.sql
-- @/u01/app/oracle/admin/XXXX/scripts/context.sql
-- @/u01/app/oracle/admin/XXXX/scripts/ordinst.sql
-- @/u01/app/oracle/admin/XXXX/scripts/interMedia.sql
-- @/u01/app/oracle/admin/XXXX/scripts/cwmlite.sql
-- @/u01/app/oracle/admin/XXXX/scripts/spatial.sql
-- @/u01/app/oracle/admin/XXXX/scripts/labelSecurity.sql
-- @/u01/app/oracle/admin/XXXX/scripts/apex.sql
-- @/u01/app/oracle/admin/XXXX/scripts/datavault.sql
-- @/u01/app/oracle/admin/XXXX/scripts/CreateClustDBViews.sql

This results in a database having only these components – the minimal component set in Oracle

-------- --------------------------------------
CATALOG  Oracle Database Catalog View
CATPROC  Oracle Database Packages and Types
XDB      Oracle XML Database

How about Oracle Database 12.2 and newer?

Beginning with Oracle Database you don’t have to do such stunts anymore. The DBCA by default allows you to customized your container database – but only if you choose ADVANCED and CUSTOM DATABASE during creation. In all other cases you’ll end up with a preconfigured database having all options.

Create Container Databases (CDB) with less options - it's now supported in Oracle

Why can this be dangerous?

Please be a bit careful to avoid future issues. Once you are settled in the world of Oracle Multitenant you should make sure to have an identical set of options/components deployed. Otherwise you may end up in a situation where you try to pluigin a PDB with more options than the destination CDB.

In this case CHECK_PLUG_COMPATIBILITY will alert you and populate PDB_PLUG_IN_VIOLATIONS with a lot of warnings about component mismatches. In this case you will have to either:

  • Remove options from your PDB before unplug
  • Install the missing options into the destination CDB
  • Create a new CDB with matching components and plug this PDB into it
  • Use another technique (not unplug/plug), for instance Data Pump to migrate the contents to a newly created PDB


Share this: