Multitenancy


  1. Oracle 12c introduced a major new feature – multitenancy – in 2013, but even today many Oracle DBAs view this as uncharted territory. It’s important to understand this technology now as Oracle has already announced that 20c will require migration to multitenant architecture and that non-CDB databases will be deprecated. 
  2. Does that mean you have to convert to multitenant right now, even on 19c? The short answer is no – you can continue to create, manage, and use non-CDBs in 19c. Though, you’ll be losing out on new technical features and one of the best licensing deals Oracle has offered, because Oracle has also extended multitenant usage to allow for three (3) PDB’s with no additional licensing.  
  3. That said, here are a few things to consider: First, making the transition to multitenant can be a pretty big technical change for your database staff, especially if they’ve not been upgrading their skills and technical orientation through training courses and even simple experimentation.  Taking on the additional challenges of using PDBs within CDBs for the first time during the upgrade process can lead to all sorts of issues while also tackling the differences between releases.
  4. Secondly, once you convert a non-CDB to a new CDB/PDB environment, there is no easy way to revert back to a non-CDB. While it’s not 100% irreversible, it can require a lot of extra effort and database downtime to revert back.  
  5. Your application will generally drive the path and type of upgrade you choose. Some commercial off the shelf products like E-Business Suite or JD Edwards will only support specific types of upgrades. Sometimes outages for upgrades are inevitable due to application level patches or changes that are required. Other applications might be so simple or straightforward that upgrading requires that you just copy the data from the source database to the target.
  6. It’s critical to put database upgrade options in context to your application, and here are a few final questions to help you:
  7. Does my application have specific Oracle database version or migration tool requirements?
  8. How much downtime can I afford for my upgrade?
  9. Have I properly funded the team with training, tools, and equipment to support those uptime needs?
  10. Is my team trained and fluent with the upgrade tools required for the path we have chosen?
  11. Will I need to procure or build out a new platform for the upgrade?
  12. Can my current platform support my system for four more years?
  13. This can all be kind of daunting. But as I said in my previous blog post: If not now, then when? Why not invoke the spirit of Carpa Indicia – Seize the Data! Start your upgrade plans now, make it a priority to spend the time and effort needed to get your application and database teams up to date, and pull together the plan and funding needed. 


To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics