Using the word "break" is deliberately provocative. In this context I mean the way you do something in a multitenant database will be different to that of a non-multitenant database. As such, your existing process or method will fail and will appear broken. I am in now way suggesting there is not a working alternative in multitenant databases and I'm not suggesting this is a bug. Oracle database 12c includes many changes to the database whether you are using the multitenant option or not. This article will focus on those changes that are as a direct result of the multitenant architecture.

You must use services to connect to pluggable databases, which effectively breaks OS authentication. This represents a problem for people using shell scripts which connect to the database. There are several solutions for this problem, including the following. - ALTER SESSION SET CONTAINER - TWO_TASK - Secure External Password Store - DBMS_SCHEDULER These methods are discussed in more detail in the following article. Oracle have been telling us to use services for a long time, but this is no consolation for those that are left with a large refactoring job before they can make the move.

When adding or removing features you often have to run built-in scripts. In previous database versions this was done by simply connecting to database as SYS and running the script. Under the multitenant architecture, many built-in scripts must be run against the root container and all pluggable databases. This is achieved using the "catcon.pl" Perl script, as described in the following article. The "catcon.pl" script can also be used to run queries and your own custom scripts against multiple PDBs in the CDB.

In Oracle 12.1 pluggable databases have no direct involvement in the management of redo and undo. This is all taken care of by the container database, so all pluggable databases under the same CDB share the same undo and redo. When connected to SYS@PDB all the undo and redo views are still available, but should be limited to the specific container, so you must be careful not to take this information out of context. Consolidating multiple redo-intensive PDBs into one CDB may be unwise, although in 12c the LGWR process spawns 2 worker slaves and will spawn more on redo intensive systems. Shared undo means undo-based flashback operations may be affected if undo is not sized properly. Consider Flashback Data Archive (FDA) , which is free in 12c. In Oracle 12.2 a container database can run in local undo mode, which means each pluggable database has its own undo tablespace. This means the problems associated with shared undo are no longer present.

1
2
3
4
5

$ ps -ef| grep [o]ra_lg
oracle    3223     1  0 17:31 ?        00:00:00 ora_lgwr_cdb1
oracle    3227     1  0 17:31 ?        00:00:00 ora_lg00_cdb1
oracle    3231     1  0 17:31 ?        00:00:00 ora_lg01_cdb1
$

There are many more backup and recovery scenarios available when dealing with the multitenant architecture. - Backup and recovery at the CDB-level is similar to that of non-CDB instances and affects all PDBs associated with the CDB. - Backup and recovery at the PDB-level is possible, with some restrictions. Point in time recovery (PITR) of a PDB is possible using an auxiliary instance, similar to tablespace PITR. - A PDB-level PITR impacts on possible flashback database operations at the CDB level. Typical backup and recovery scenarios for CDBs and PDBs are discussed in more detail in this article. You must spend some time getting used to the changes brought about by the multitenant architecture. If you don't you will mess up and have problems!

In Oracle 12.1 flashback database is only available at the CDB level and therefore affects all PDBs associated with the CDB. As mentioned previously, PITR of a PDB affects the possible flashback database operations on the CDB. Using flashback database against a CDB is described in the following article. As with backup and recovery, you need to spend some time to learn and understanding the implications! In Oracle 12.2 flashback of a pluggable database is possible, making flashback database relevant again.

By default, Oracle Database 12c Release 1 (12.1) comes with APEX installed in a shared configuration, such that the CDB contains shared APEX components and the PDBs contain their database-specific components, along with your application metadata. The important implications of this shared installation approach are discussed in the following article. Before you start creating PDBs you need to consider how you want to use APEX in your PDBs. If you don't want to use the default shared configuration, you must make that decision up front. From Oracle Database 12c Release 2 (12.2) onward APEX is not installed by default, so you no longer need to worry about uninstalling APEX before creating PDBs.

Encryption key management has changed in Oracle database 12c, which affects transparent database encryption (TDE) for both non-CDB and CDB installations. Under the multitenant architecture, many of the encryption key management operations must be done at both the CDB and PDB level for TDE to work. This also means encryption keys must be exported and imported during unplug and plugin operations on PDBs. This is discussed in more detail in the following article. The changes are relatively simple, but your non-CDB method will not work under multitenant.

In previous releases and non-CDB databases, the data dictionary view hierarchy from top-to-bottom is DBA > ALL > USER. In multitenant databases an additional layer is added, making it CDB > DBA > ALL > USER. This change is described in the following article. - Multitenant : Overview of Container Databases (CDB) and Pluggable Databases (PDB) When connecting to a PDB, the view hierarchy feels the same, so this shouldn't represent a problem for most people or tools. The problem comes when you connect to the root container, maybe using "/ AS SYSDBA" or "SYS@CDB AS SYSDBA", and use the DBA views expecting to see all objects. In this case, you will only see the objects relevant to the root container, not all the PDBs. You will need to judge the impact of this on your applications and tools.

The following features are not currently supported under the multitenant architecture in version 12.1.0.2 ( see here ). - DBVERIFY - Data Recovery Advisor - Flashback Pluggable Database (present in 12.2) - Flashback Transaction Query - Flashback Transaction Backout - Database Change Notification - Continuous Query Notification (CQN) - Client Side Cache - Heat Map - Automatic Data Optimization - Oracle Streams In version 12.2 that list reads as follows ( see here ). - Flashback Transaction Query (in both local undo mode and shared undo mode) - Database Recovery Advisor - Oracle Sharding (new feature in 12.2) - Audit Vault Redo Collector If you need any of these features, use a non-CDB architecture until they are supported.

From Oracle database 12c version 12.1.0.2, the non-CDB architecture is deprecated . > "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." It is still supported and will not disappear immediately, but you should be considering the implications of this move now. The 18c upgrade manual now includes the following statement here . > "The non-CDB architecture was deprecated in Oracle Database 12c. It can be desupported and unavailable in a release after Oracle Database 19c." At Oracle OpenWorld 2019 it was announced that the non-CDB architecture will be desupported in Oracle 20c, so Oracle 19c is the last version of the database where you can use the non-CDB architecture in a supported environment.

A container database with a single user-defined pluggable database, also know as lone-PDB or single tenant, is free and available in all database editions. It is only when you want multiple user-defined PDBs in a single CDB you have to pay for the multitenant option. As such, you can have multiple CDBs on a server, each with a single PDB without incurring any extra cost. Using the lone-PDB approach allows you to get used to the multitenant architecture without having to buy the multitenant option. You can protect yourself from creating too many PDBs by using a system trigger in 12.1, or the parameter in 12.2 onward. You can read about this here . From 12.2 onward you are allowed to create a single user-defined PDB, an application root container and a proxy PDB without needing to buy the multitenant option. In Oracle 18c XE you are allowed to create 3 user-defined PDBs. From 19c onward you are allowed to create 3 regular user-defined PDBs without needing to license the multitenant option, making the multitenant architecture even more attractive.

When the multitenant architecture was first announced, several claims were made about it improving the speed of patches and upgrades because of the ability to unplug a PDB from a CDB running a previous database version and plug it into a CDB running a newer version. In reality, using unplug/plugin for an upgrade involves both pre-upgrade and post-upgrade steps that mean the total elapsed time may not be improved by as much as it initially sounded. Even so, depending on the type of patch or upgrade, you may see some benefits to this approach. Transfers of PDBs between CDBs of the same version using unplug/plugin are incredibly simple and quick! Cloning is where the multitenant architecture really shines. A clone of a PDB can be performed within the local CDB, or to a remote CDB on the same, or a different server. Although cloning using Clonedb and are relatively straight forward, cloning a pluggable database is incredibly simple! It might be worth moving to the multitenant architecture just for this feature. Remote clones can also be used to convert non-CDB databases to PDBs. These topics are discussed in the following articles.

Mark Farnham made an important point relating to support. Getting support on a deprecated feature gets progressively harder over time. There is little incentive to fix problems with a feature/architecture that is slated to be desupported in future. Even if the non-CDB architecture is available for an extended period of time, it doesn't mean it will be a pleasant experience. In addition, it is likely that new features will be coded against the multitenant architecture, and only made available in the non-CDB architecture if it doesn't require much effort to do so, or if it is necessary to not break the product. We've seen examples of this in the past.

The multitenant architecture introduces a lot of changes for DBAs. If you upgrade to non-CDB in 12cR1, you may be "forced" to change to CDB in 12cR2, making your 12cR2 upgrade a bigger change than it needs to be. Maybe it's better to put the effort in upfront and switch now? This is quite a subjective point and will depend on your time scales, training needs and the level of testing your applications require before making this change.

The multitenant architecture is the future of the Oracle database. There is no point putting your head in the sand and hoping it will go away. In the coming years, the DBAs who invest in learning the new architecture will stand out and those that don't will fall by the wayside. Even if your decision is to go with the non-CDB approach in 12.1, you *must* start learning about the multitenant architecture now or you may end up making some really bad choices in the future. At a minimum, you need to start making sure your working practices minimize the impact that a move to multitenant architecture will make in future. For more information see: - Multitenant : Overview of Container Databases (CDB) and Pluggable Databases (PDB) - Multitenant : All Articles Hope this helps. Regards Tim...