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.
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.
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.
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
- 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 (orPDB), consists of user metadata and user data.
- 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.