Multitenant Container Database- Architecture Overview

Starting with Oracle 12c, Oracle introduced a new type of database, the multitenant container database and the associated pluggable databases. A multitenant container database (CDB) or root container database is a self-contained set of datafiles, controlfiles, redo log files, parameter files, and so on that only include the Oracle metadata, Oracle data, and Oracle code. There are no application objects or code in these datafiles—only Oracle-supplied metadata and Oracle-supplied code objects. This database is self-contained in that it can be mounted and opened without any other supporting physical structures.

A pluggable database (PDB) is a set of datafiles only. It is not self-contained. A pluggable database needs a container database to be “plugged into” to be opened and accessible. These datafiles contain only metadata for application objects, application data, and code for those applications. There is no Oracle metadata or any Oracle code in these datafiles. There are no redo log files, control files, parameter files, and so on—only datafiles associated with a pluggable database. The pluggable database inherits these other types of files from the container database it is currently plugged into.

A pluggable database will be associated with a single container database at a time and is only indirectly associated with an instance; it will share the instance created to mount and open the container database. So, like a container database, a pluggable database can be associated with one or more instances at any point in time. The root container instance may be providing access to many (thousands) pluggable databases simultaneously. That is, a single instance may be providing services for many pluggable databases, but only one container database.

Figure 2-3 displays the architecture of a container database and associated pluggable databases. The container instance is named CDB, and the root container is also named CDB.

There are two pluggable databases (PDB1 and PDB2) attached to this container database.

Figure 2-3.  A container database with two pluggable databases

As depicted in Figure 2-3, the client initiates a connection to the PDB1 pluggable database. The listener connects the client to a server process which processes SQL requests. In this configuration, the client is connected to the CDB instance and ­accessing the PDB1 pluggable database. The client has no visibility to any other pluggable databases within the container. In other words, the client can only access data within the pluggable database that the client is currently connected to (PDB1 in this example).

There is only one instance (CDB) associated with this container database. We can view the system monitor process of this instance as follows:

$ ps -ef | grep smon
oracle 19362 1 0 00:29 ? 00:00:00 ora_smon_CDB

We can view the datafiles associated with the root container database as well as the pluggable databases. First, connect to the root container:

$ sqlplus / as sysdba

And while connected to the root container, we can view all datafiles associated with the root container and both pluggable databases:

SQL> select name from v$datafile;

NAME

/opt/oracle/oradata/CDB/system01.dbf
/opt/oracle/oradata/CDB/sysaux01.dbf
/opt/oracle/oradata/CDB/undotbs01.dbf
/opt/oracle/oradata/CDB/pdbseed/system01.dbf
/opt/oracle/oradata/CDB/pdbseed/sysaux01.dbf
/opt/oracle/oradata/CDB/users01.dbf
/opt/oracle/oradata/CDB/pdbseed/undotbs01.dbf
/opt/oracle/oradata/CDB/PDB1/system01.dbf
/opt/oracle/oradata/CDB/PDB1/sysaux01.dbf
/opt/oracle/oradata/CDB/PDB1/undotbs01.dbf
/opt/oracle/oradata/CDB/PDB1/users01.dbf
/opt/oracle/oradata/CDB/PDB2/system01.dbf
/opt/oracle/oradata/CDB/PDB2/sysaux01.dbf
/opt/oracle/oradata/CDB/PDB2/undotbs01.dbf
/opt/oracle/oradata/CDB/PDB2/users01.dbf

To connect to the PDB1 database, I use the PDB1 service in my connection string (more on this later):
$ sqlplus system/foo@localhost:1521/PDB1

While connected to PDB1, there is no visibility to any other containers in the database. As far as the pluggable PDB1 database is concerned, there are no other databases it can see. For example, querying the name of the datafiles shows only the datafiles associated with the PDB1 pluggable database:

SQL> select name from v$datafile;

NAME

/opt/oracle/oradata/CDB/PDB1/system01.dbf
/opt/oracle/oradata/CDB/PDB1/sysaux01.dbf
/opt/oracle/oradata/CDB/PDB1/undotbs01.dbf
/opt/oracle/oradata/CDB/PDB1/users01.dbf

This means you could have one application and all its users and objects in PDB1, and you could have a completely different application using PDB2. There are no collisions of users and objects between these two databases. They are physically implemented as two stand-alone pluggable databases (within a container database).

Multiple pluggable databases, subordinate to the container database, can be open and accessible simultaneously—but will all share the single instance created to open the container database. A pluggable database—in order to be used, to be queried—must be associated with a container database. That container database will only have Oracle data and metadata in it—just the information Oracle needs to “run.” The pluggable databases have the “rest” of the database metadata and data.

So, for example, the container database would have the definition of the “SYS” user (the metadata for the SYS user) and the compiled code and source code for objects like DBMS_OUTPUT and UTL_FILE. A pluggable database, on the other hand, would have the definition of an application schema like SCOTT, all of the metadata describing the tables in the SCOTT schema, all of the PL/SQL source code for the SCOTT schema, all of the GRANTS granted to the SCOTT schema, and so on. In short, a pluggable database has everything that describes a set of application schemas—the metadata for the accounts, the metadata for the tables in those accounts, and the actual data for those tables. A pluggable database is self-contained with respect to the application accounts it contains, but it needs a container database to be “opened” and queried. Therefore, you can say that a pluggable database is not “self-contained,” it needs something else in order to be opened and used.

A pluggable database is not directly opened by an instance, but rather an Oracle instance must be started and a container database mounted and opened by that instance. Once the container instance is up and running, and the container database is opened, that container database may open multiple pluggable databases. Each of these pluggable databases acts as if it were a “stand-alone” database. That is, they appear to be self-­contained, stand-alone “single-tenant” databases. But they all share the same container database and container instance.

Note In Oracle 19c and above, you can have three customer-created pluggable databases in an Enterprise Edition database without any extra licensing required. With the multitenant license, you can have up to 4096 separate pluggable databases in a single container database.

When you start an Oracle instance, there are many processes associated with it (more on this in Chapter 5). Each instance is supported by about a hundred or so processes (varies by configuration). If you attempted to start up 50 single-tenant databases—where each database has an instance associated with it or its own instance— you would have upward of 5000 processes just to get the databases started! That is extremely taxing on the operating system, both to create that many processes and then to manage them.

Additionally, each instance would have its own SGA. Chapter 4 will cover what is in the SGA, but suffice it to say, there is a lot of duplication. Each SGA would have a cached copy of DBMS_OUTPUT in its shared pool, and each SGA would have a redo log buffer and many other duplicative data structures.

With pluggable databases, you can have the separation of application metadata, users, data, code, and so on, but avoid the redundant instances. That is, you can have a single instance with a single container database (the Oracle metadata, code, and data) that provides access to many pluggable databases, each hosting a separate application. That’s a massive reduction in server resource utilization. In general, the size of the single SGA you would allocate for these application pluggable databases will be smaller than the sum of the separate SGAs you would have to allocate otherwise.

From the perspective of a developer, a pluggable database is no different from a single-tenant database. The application connects to the database in exactly the same way it would connect to a single-tenant database in earlier releases. The differences lie in the underlying architecture—that of a single instance for many pluggable databases, and the resulting reduced resource utilization on the server and the ease of management for the DBA.

From a DBA perspective, there are many changes in the way a database is administered—positive changes. For example, if a DBA configured a container database for RAC, every pluggable database under that container would be RAC enabled. The same with Data Guard, RMAN backups, and so on. The DBA has one instance to configure and work with, instead of one instance per application as in the past.

About the author

Leave a Reply

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