8i | 9i | 10g | 11g | 12c | 13c | 18c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » 12c » Here

Multitenant : Pluggable Databases - What they will break and why you should use them anyway!

This article assumes you have a basic understanding of the multitenant architecture. If you don't, you should probably read the multitenant overview article first.

Many of the points raised by this article are explored in more detail in other articles. Rather than duplicate them, links are provided if you require more information.

What do I mean by, "What they will break"?

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.

What they will break!

OS Authentication

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.

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.

Built-In Scripts

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.

Redo and Undo Management

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.

$ 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
$

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.

Backup and Recovery

There are many more backup and recovery scenarios available when dealing with the multitenant architecture.

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!

Flashback Database

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.

Application Express (APEX)

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.

Transparent Data Encryption (TDE)

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.

DBA_% and DBA_%_AE Views

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.

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.

Features Not Available with Multitenant

The following features are not currently supported under the multitenant architecture in version 12.1.0.2.

In version 12.2 that list reads as follows.

If you need any of these features, use a non-CDB architecture until they are supported.

Why you should use them anyway!

Non-CDB Architecture Deprecated

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.

Lone-PDB is Free

A container database with a single 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 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.

At this point there is no way to limit an Enterprise Edition CDB to a single PDB, so it is up to you to avoid breaking your license agreement!

Patching, Upgrading and Cloning

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 RMAN DUPLICATE 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.

Get Started Now

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.

Future-Proof Yourself

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:

Hope this helps. Regards Tim...

Back to the Top.