The Multitenant Architecture

The Multitenant Architecture

The Multitenant architecture allows a single super container (“Container” alias CDB) to shelter multiple other containers (“Pluggable” alias PDB). From the server subsystem, there is only one database i.e. the container database, and therefore only one instance (and one SID) is available i.e. the CDB, while each application sees only the specific PDB to which it connects to. There is no application code change required while connecting to a PDB. Each PDB runs as a service within the CDB but ensures complete security and isolation amongst them.

Traditionally, an Oracle database consists of its instance and the file structure. An Oracle database instance is made up of the memory and the background process. The file structure comprises of the datafiles (.dbf), control file, spfile, password file, redo logs, archived logs, undo segment and temp tablespace. Oracle 12c Multitenant architecture simply reorganizes these components and categorizes them as “sharable” component and “application component”. The “sharable” components are instance level pieces and the system pieces of a database like SPFILE (parameter file), control file, SYSTEM and SYSAUX tablespace, redo logs, archived log files, UNDO and TEMP. These sharable components exist at the root container (CDB) level. The user or application data for each database is the application component and therefore, each PDB just holds its own user data. Each PDB plugs into the CDB with its application data only while shares the memory, redo logs, archived logs, UNDO segment, and control file information with other pluggable databases in the same container.

A multitenant container database has three types of containers:

*The Oracle supplied container is called the root container (CDB$ROOT) and consists of just Oracle metadata (and maybe a little bit of user data) and common users. Each CDB has one root.

*The seed container is named PDB$SEED, and there is one of these per CDB. The purpose of the seed container isn’t to store user data—it’s there for you as a template to create PDBs.

*The user container , which is actually called a pluggable database (or PDB), consists of user metadata and user data.

Each of these—the root, the seed, and the PDB(s)—is called a container, and each container has a unique container ID (CON_ID) and container name (CON_NAME). Each PDB also has a globally unique identifier (GUID). The idea behind the concept of a container is to separate Oracle metadata and user data by placing the two types of data into separate containers. That is, the system and user data are separated. There’s a SYSTEM tablespace in both the central container and the PDB containers, however, they contain different types of data. The root container consists of Oracle metadata whereas the PDB container’s SYSTEM tablespace contains just user metadata. The Oracle metadata isn’t duplicated by storing it in each PDB—it’s stored in a central location for use by all the PDBs that are part of that CDB. The CDBs contain pointers to the Oracle metadata in the root container, thus allowing the PDBs to access these system objects without duplicating them in the PDBs. A CDB has similar background processes and files as a normal non-CDB database. However, some of the processes and files are common for both a CDB and its member PDB databases, and some aren’t.

Common Entities between CDB and PDBs

*Background processes There’s a single set of background processes for the CDB. The PDBs don’t have any background processes attached to them.

*Redo log files These are common for the entire CDB, with Oracle annotating the redo data with the identity of the specific PDB associated with the change. There’s one active online redo log for a single-instance CDB or one active online redo log for each instance of an Oracle RAC CDB. A CDB also has a single set of archived redo log files.

*Memory You allocate memory only to the CDB, because that’s the only instance you need in a multitenant database.

*Control files These are common for the entire CDB and will contain information that reflects the changes in each PDB.

*Oracle metadata All Oracle-supplied packages and related objects are shared.

*Temporary tablespace There’s a common temporary tablespace for an entire CDB. Both the root and all the PDBs can use this temporary tablespace. This common tablespace acts as the default TEMP tablespace. In addition, each PDB can also have a separate temporary tablespace for its local users.

*Undo tablespace All PDBs use the same undo tablespace. There’s one active undo tablespace for a single-instance CDB or one active undo tablespace for each instance of an Oracle RAC CDB.

A CDB contains a set of system data files for each container and a set of user-created data files for each PDB. Also CDB contains a CDB resource manager plan that allows resources management among the PDBs in that CDB.

Entities Exclusive for PDBs

*Tablespaces for the applications tables and indexes These application tablespaces that you’ll create are specific to a PDB and aren’t shared with other PDBs, or the central CDB. The data files that are part of these tablespaces constitute the primary physical difference between a CDB and a non-CDB. Each data file is associated to a specific container.

*Local temporary tablespaces Although the temporary tablespace for the CDB is common to all containers, each PDB can also create and use its own temporary tablespaces for its local users.

*Local users and local roles Local users can connect only to the PDB where the users were created. A common user can connect to all the PDBs that are part of a CDB.

*Local metadata The local metadata is specific to each application running in a PDB and therefore isn’t shared with other PDBs.

*PDB Resource Manager Plan These plans allow resource management within a specific PDB. There is separate resource management at the CDB level.

The PDB containers have their own SYSTEM and SYSAUX tablespaces. However, they store only user metadata in the SYSTEM tablespace and not Oracle metadata.

Data files are associated with a specific container. A permanent tablespace can be associated with only one container. When you create a tablespace in a container, that tablespace will always be associated with that container.