Non-CDB architecture of Oracle databases is DEPRECATED since Oracle Database 12.1.0.2

Please find an updated blog post here:

as the text in the Database Upgrade Guide has been changed as well.


non-CDB deprecated in Oracle 12.1.0.2

What does this mean?

Deprecation first of all does not mean “desupported”. It means in this case that you of course can have still stand-alone Oracle databases as you know the architecture from previous releases. But you can also have a single-tenant deployment (a CDB with one PDB – no Multitenant license required) or multitenant databases (a CDB with up to 252 PDBs – Multitenant Option license required).

But in a future Oracle release single-tenant and multitenant databases only may be allowed. Right now there’s no information available when this might happen. 

Which features are not supported at the moment?

  • Database Change Notification
  • Continuous Query Notification (CQN)
  • Client Side Cache
  • Heat Map
  • Automatic Data Optimization
  • Oracle Streams
  • Oracle Fail Safe
  • Flashback Pluggable Database (Flashback Database works but will flashback CDB$ROOT including all PDBs)
  • DBVERIFY
  • Data Recovery Advisor (DRA)
  • Flashback Transaction Backout

–Mike

From the Upgrade Guide:
By deprecate, we mean that the feature is no longer being enhanced but is still supported for the full life of the 12.1 release. By desupported, we mean that Oracle will no longer fix bugs related to that feature and may remove the code altogether. Where indicated, a deprecated feature may be desupported in a future major release

33 thoughts on “Non-CDB architecture of Oracle databases is DEPRECATED since Oracle Database 12.1.0.2

  1. Hi Mike,

    Of course it’s better to have only one kind of architecture, but going from non-CDB to single-tenant will come with a big overhead for small databases.

    Each database will have more datafiles (CDB$ROOT ones in addition to PDB ones).
    Some structures (redo, memory) will be larger as they store CON_ID, but that may be a minimal overhead.
    But worse: in CDB you have to install all components. That means more space, and a lot more time to upgrades.

    That should be carefully planned for companies having lot of small SE databases…

    Regards,
    Franck.
    @FranckPachot

  2. Franck,

    I fully see your point – and agree. Even though I believe the extra with the 3-4 datafiles of the CDB$ROOT is not that much – and the footprint in process memory shouldn’t be significant.

    And of course I fully understand your point about SE. The "all options required" topic is another key point.

    I just can tell you now that this (Single/Multi-Tenant is a must) won’t happen in Oracle 12.2.

    So there’s a lot of time for customers, partners and users to discuss their concerns with Oracle.

    Thanks a lot!
    Mike

  3. Arun,

    thanks for your comment.

    And there’s a clear answer: No.

    You will have to create a new CDB (Container Database) ideally with DBCA – you will not have to create any PDB within the DBCA.
    Once the CDB is created you’ll convert your existing stand-alone database (which must be upgraded to Oracle Database 12c first!!!) into a PDB.

    Basically it is very straight forward:
    (1) Upgrade your stand-alone database to 12c
    (2) Put it into Read-Only mode
    (3) DBMS_PDB.DESCRIBE will create an XML manifest file
    (4) Shut your database down IMMEDIATE
    (5) Connect into the CDB$ROOT
    (6) CREATE PLUGGABLE DATABASE pdb1 USING (pdb.xml) NOCOPY TEMPFILE REUSE;
    (7) Start @noncdb_to_pdb.sql

    If you use the NOCOPY option make sure you have a backup of your database – otherwise use COPY with the FILE_NAME_CONVERT command option but this will require double space on your system as the files will be copied.
    TEMPFILE REUSE will ensure that your TEMP tablespace(s) will be kept and carried over (highly recommended).
    The final "sanity" script will now merge the PDB and CDB$ROOT together – be aware that the runtime with a real life database can be up to some hours in extreme situations where many objecs exist.

    Hope this helps – cheers
    Mike

  4. Mike,
    Thank you so much for clear answer and steps. This is precisely what I was looking for. Your web site is an excellent resource.

    We are migrating from 11.2.0.4 on Windows to 12.1.0.2 on Exadata. Here is what I have tested so far:

    a) Create a physical standby with primary on Windows and physical standby on Exadata. We will need 11.2.0,4 DB_HOME installed on Exadata in addition to 12.1.0.2. The GI will be at 12.1.0.2.

    b) On the day of upgrade, gracefully failover to physical standby and shutdown the old primary on Windows. Now I will have a fully functional 11.2.0.4 primary database on Exadata.

    c) Remove all Data Guard parameters from primary on Exadata and from old primary on Windows. Leave the Windows database shutdown to prevent any application from even accidentally connecting to it.

    d) Create a guaranteed restore point on the 11.2.0.4 database on Exadata.

    d) Upgrade the 11.2.0.4 database on Exadata to 12.1.0.2. I prefer manual upgrade method using catctl.pl. I have to upgrade 12 database in one day. With manual scripting, I can upgrade all databases nearly at the same time. DBUA GUI wastes lot of time answering questions.

    e) If the upgrade is successful and no issues are found, drop guaranteed restore point and continue to use the 12c database.

    f) If upgrade process goes wrong, flashback to guaranteed restore point and keep using the 11.2.0.4 on Exa.

    g) Worst case scenario, abandon the database on Exadata and keep using 11.2.0.4 on Windows.

    Do you see any potential issues with this plan? Our requirement is that we can tolerate a small amount of downtime but missing transactions and database objects cannot be tolerated.

    Thanks,
    Arun Gupta

  5. Arun,

    this is exactly what I would do as well.
    I’m silently assuming that you included the execution of the preupgrd.sql in your plan as otherwise catctl.pl will complain. And once you do the upgrade on an Exa you may go forward with "-n 8" setting for the run of catctl.pl.

    That all looks very good and very well planned!!!

    Thanks
    Mike

  6. Yes, the preupgrd.sql, dbupgdiag.sql and utlu121s.sql scripts are an integral part of the upgrade process, I just left out the details.

    Thanks for the reply,
    Arun Gupta

  7. Mike,

    Great information regarding this subject that seems to have been the subject of a bit of FUD on the blogosphere… Personally I don’t see the learning curve of the CDB architecture to be that extreme.

    I think one thing I really find is surfaced by this issue is that there really is insufficient training when a new version of the database is released. Most of the time, people can get by "doing what they have always done". Now we have a case where they can’t and this surfaces a real problem (IMHO) – the serious lack of reoccurring training, or a belief that it’s even needed on a regular basis.

  8. Mike,
    We are upgrading from 11g to 12c. Once we run DBUA will we end up with a standalone database or with a container database?
    If the answer is standalone, can we then stay running like that or must we go to container with single PDB model?

  9. Robert,

    you will always end up with a stand-alone (non-CDB) database. So please don’t worry.

    You have THE OPTION to make your database a pluggable database afterwards but the upgrade to 12c has to happen first. And there’s no pressure to do so even though I’d recommend to start playing seriously with the single tenant architecture right now.

    Cheers
    Mike

  10. Having worked with Oracle and SQL Server for years, this looks like Oracle trying to be more like SQL Server.

    Most of the small databases I’ve dealt with over the years are single schemas, so where is the real advantage of the CDB/PDB over a non-CDB with multiple schemas?

    Yes the CDB/PDB separates the metadata objects into different views and that the PDB is more transportable. However you are paying for this ability at 17500/processor (Like the database isn’t already expensive enough as is)

    Could you not instead just run the small databases in a seperate non-CDB instance with separate tablespaces for each schema. Administer the accounts and permissions as you’ve done in the past. Yes you can’t easily move them, so ask yourself how often do you need to do that and for what purpose? Maybe if this were free it would make more sense. Maybe this is geared towards companies that are providing database services and not organizations with departments, and especially not for non-profit organizations.

    Clearly I’m missing something.

  11. Are you about to ask about single or multitenant?

    Not sure what the nature of your comment is. The idea of Multitenant is pretty obvious – leverage your computing resources way better, isolate things, flexibility for upgrades and patching and such. Especially the latter is something you don’t have when doing SCHEMA consolidation. And way more …

    Mike

  12. Can i install Oracle 12c database in standalone mode , with no PDB or CDB architecture ? Just like oracle 11g database. i am having problem while installing OBIEE12c due to multi tenancy problem.

  13. Of course you can.

    We officially say (and write it down) that all potential architectures (non-CDB == as you know it, CDB with either one PDB or many) will be available free of choice until at least Oracle Database 12.2.

    So clear YES, most customers I know use Oracle Database 12.1. as they used it in any other database release before.

    Cheers
    Mike

  14. Hi Mike,

    Can CBD and PDB architecture be used in EBS (as we have OATM model ) and how?
    How to justify client abt going for consolidation as it risks downtime of all databases at once if anything goes wrong like hitting a bug etc. So in this case we lose availability for all applications.

    Need a view on this situation

  15. No – EBS is not certified with Multitenant yet as far as I know. I think there is a certification process going on – but I don’t know the exact status.

    Cheers
    Mike

  16. Hi Mike,

    My question: I have a large RAC in 11.2.0.4. My cluster have several databases, in fact, I have more than 30 and every database have 5 or more instances. Now, i need to migrate it to 12c but I have not license for PDB. So, what is the road map that oracle thing for people like us? We have an ULA and we did not have in mind this limitation when we sign it. May I have a CDB for every database? and May I have lot of CDB’s in the same cluster?
    I will appriciate your answer.

    Best regards!

  17. No worries – please see the above link and check the statement saying

    "The non-CDB architecture is deprecated in Oracle Database 12c, and may be desupported and unavailable in a release after Oracle Database 12c Release 2. Oracle recommends use of the CDB architecture."

    No need to use PDBs now, no need in 12.2. And we’ll see what happens after 12.2. Still I’d recommend that you play with Single Tenant (one active PDB – no extra license required) – see the presentation "HOw Single Tenant will change a DBAs life" in the Slides Download Center.

    Cheers
    Mike

  18. So to be clear if we have a small database and only use one tenant we won’t be required to pay the additional multi tenant / processor up charge?

  19. True – please see the "Single Tenant" presentation on the right in the Slides Download Center – you’ll find this in slide 5 or 6 🙂

    Cheers
    Mike

  20. Thanks Mike for the nice info.

    Just a small clarification. You mentioned that Oracle Fail Safe is not supported with the CDB/PDB architecture. I remember that Oracle Fail Safe version 4.1.1 is supported with CDB/PDB while Oracle Fail Safe 4.1 is not supported. Is that correct?

    Thanks Again
    Ahmed

  21. @Ahmed:

    Ahmed,

    I’m not sure – the list I mentioned is taken from the documentation. You will need to ask Support via an SR as my recent research didn’t bring up any clarification.

    Cheers
    Mike

  22. Hi Mike,
    If I go with that note, and create a CDB with only those three options, meanwhile my old 11g db I was able to remove quite a lot of components from it, but still ended up a few more than what the CDB has, if I plug in my old db (after upgrade to 12c of course), will that work? I mean pbd has more options than what cdb has, will that still work?

    Thanks,

    Erin

  23. Erin,

    when your PDB has more options than the CDB your are plugging into you’ll see a plug in error and may be able to open the PDB only in RESTRICTED mode.

    Workaround:
    Remove the options from the source first before plugging in OR install the mission option into the CDB.

    Cheers
    Mike

  24. Hi Mike – great article (as always) – I’d dearly like Oracle to push harder at times and, perhaps, one day we will see multi-tenant bundled as part of the core RDBMS and the non-CDB architecture fully relegated to the history books. Of course I’d also like to see advanced security bundled for those folks who deploy the RDBMS on the new Sparc chip but I’m not holding my breath on that.

  25. This looks like what Microsoft have been doing in SQL Server since the ’90’s.. what’s so clever about this? Unplug = detach; plug = attach; lose all the clever stuff about cross database queries.. oh, and get a massive bill for something that’s in their free Express Edition..

  26. Well, then you compare Apples and Oranges. No offense but you can also compare a US car to a German car such as BMW or Porsche. Both will be cars and can drive … just usually quite a different experience and durability … 😉

    Just saying … I drive cars from Bavaria for over 29 years 😉

    Mike

  27. I have not find anything useful – especially not on the EBS group’s blog. So please open an SR with Oracle Support and check for certification and plans.

    Cheers
    Mike

Leave a Reply

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