Oracle 12c Architecture


Recently I was refreshing my Oracle 12c Architecture knowledge, so I google’d around for an article for the same, to my surprise, I wasn’t able to find any good informative article explaining the Oracle 12c Architecture, hence comes this post.

In this post we’ll go through the Oracle 12c Architecture in as simple way as we can.

Multitenant Architecture.PNG

With 12c you might have always heard of multitenant architecture and Container & pluggable Database, so we’ll start with understanding these things. Also 12c configuration has following option:-

  • Multitenant configuration A CDB consists of zero, one, or more PDBs. You need to license the Oracle Multitenant option.
  • Single-tenant configuration Doesn’t require the licensed Oracle Multitenant option
  • Non-CDB This is the same as the pre–Oracle 12 c database  architecture.

So it doesn’t mean that 12c is only about multitenant configuration, it can be configured as the same way as your beloved 11g.

Multitenant Architecture

For those of you who have worked with SQL Server, Sybase etc this architecture won’t be new. Basically till 11g we used to have 1 instance for 1 database (excluding RAC cases for simplicity), so even you have a very small application you need to have a separate instance for that database, separate instance means memory, process and everything (But then Oracle was designed to handle large & critical databases). So with the changing requirements Oracle has changed its architecture where you can have multiple databases within a single instance. To build a little perspective on CDB (CDB$ROOT) and PDB think of this single instance as CDB and multiple databases as PDB.

oma.PNG

Now its time to understand what is CDB & PDB, how is memory allocated to these different PDB, how does CDB maintains PDBs, where’s REDO, where’s UNDO, etc.

CDB & PDB

cdba.PNG

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 e
ach 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.
cdb (1)
Above diagram depicts what a CDB contains and what a PDB contains.
To Read the next article in the series click How to create a 12c test lab from scratch.
Hope this answers the basic ambiguity in mind regarding 12c, I’ll continue posting articles to cover further architecture internals along with How to administer and maintain a 12c database to give users a hands-on. The idea of these posts is to help the DBAs who have understanding of 11g but are yet not aware of 12c. From 12c with architecture everything has changed even the basic commands to administer and maintain a database. Hence sharing these posts to quickly adapt the 12c changes for 11g DBA.