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.

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 the workaround – as PDBs were allowed to have less options – has been to create a stand-alone Oracle 12c database with exactly the options you’d like to have configured as your gold standard – and then plug it in under a remarkable name, for instance PDB$MASTER. Switch it to read only and make sure from now on you’ll provision a new PDB always as a clone from PDB$MASTER, and not from PDB$SEED.

All Options in a CDB

That would have even worked in the Single Tenant case, which does not require licensing the Oracle Multitenant option and where you have only one active (“customer-created PDB”) PDB. For this purpose you would have unplugged your PDB$MASTER after making it a pluggable database and provision new PDBs with just your desired options set as plugging in PDB$MASTER under a new name (e.g. PDB26) using the COPY option of the command.

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).

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


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

  1. With non-CDBs you don’t face the issue as the DBCA does allow you to deselect options.

    But you can use the script approach as well of course for non-CDBs.


  2. Hello Mike,

    for a POC i am working finally with PDB’s 😉

    one thing I noticed is that the PDB_PLUGIN_VIOLATIONS view displays the options missing when you plugin a noncdb

    for example :

    Database option SDO mismatch: OPTION PDB installed version NULL. CDB installed version PENDING Fix the database option in the PDB or the CDB

    I want to have it clean so decided to create the cdb exactly with the same options as the noncdb.
    So from your blogpost above I understand that the messages in PDB_PLUGIN_VIOLATIONS is strictly informational and not an error ?

  3. Hi Philippe,

    the PDB_PLUG_IN_VIOLATRIONS contains a lot of useless information and does not get purged as far as I know. Bugs had been filed years ago but got ignored.

    The only thing you can do is query for errors.

    select message from pdb_plug_in_violations
    where status<> ‘RESOLVED’ and TYPE=’ERROR’;

    The issue I see:
    Sometimes things which cause a road block are not tagged as error but as WARNING such as "you’ll have to run noncdb_to_pdb.sql".

    Sorry for the inconvenience 🙁

  4. Philippe,

    to add:
    There are ERRORS and WARNINGS – but there’s no clear rules. Everything needs to be really checked and verified – some things can be ignored (such as the SDO error in your case which is complete nonsense – why should you care that your PDB you’ll plug in has no SDO but the CDB your are gonna plug into has SDO – useless information).


  5. Hi Mike,

    Is there a way to not install these options when using templates to create the cdb ? I did try to edit the template and do this however no success.


  6. Hi Steve,

    "templates" in DBCA unfortunately don’t allow you this customization as far as I remember. Only the "create scripts" approach will work for CDBs. But for non-CDBs you should have the choice.

  7. Pingback: Why you should remove APEX from the CDB$ROOT | Upgrade your Database - NOW!

  8. Pingback: Always create databases as CUSTOM databases - Oracle DBCA

  9. Hi Mike

    Issue – Some components missing in pdb$seed and PDBs.

    I have created the “Create Database” scripts for CDB using Multi-Tenant with the dbca in a environment – using “Advanced configuration” – first of all with all options. I checked out “Create as Container Database” and “Create an empty Container database” – none PDB. All options has been created in my scripts using “Database components.

    As mentioned in MyOracleSupport Note 2001512.1 “Creating A Container Database (CDB) With A Subset Of Options” – of course note is for 12.1 … therefore I comment out all unnecessary option – only JServer should by installed.
    Therefore I changed the script Database.sql and run the complete create database scripts. CDB created successfully.

    After than a PDB database was created manually. Some imports have done – But with errors using Java.
    The pdb$seed and all other pdbs do not have any JServer installed. I checked out dba_registry – no Java in pdb$seed and PDBs

    I compared your scripts, my older 12.1 scripts and the new 12.2 scripts and found the parameter -c ‘CDB$ROOT’ in my dbca scripts in some *.sql scripts. After removing this parameter in my JServer.sql and recreating the new database the JServer was installed correct in pdb$seed and within all my additional created PDBs.

    I hope this helps

    Cheers and many thanks for all my other problems solved on your blog
    Peter Jensch

    • Hi Peter,

      this is coming from the OPTIONS screen in DBCA. When you create the scripts with DBCA and don’t explicitly click on “PDB” in the options check box (e.g. check JAVAVM but don’t click it for the PDB) then your scripts will contain the extra option -c ‘CDB$RROT’ to indicate that this particular option won’t be present in PDBs. Side effect: it won’t be in the PDB$SEED as well. Meaning, every newly provisioned PDB won’t have it either. But you can easily install it – also into the PDB$SEED or in any of the PDBs separately.


  10. Pingback: Can you simply switch from SE2 to EE with Oracle Multitenant - Upgrade

Leave a Reply

Your email address will not be published. Required fields are marked *