Oracle 12c Pluggable Database feature insights
I’m excited about a new version of Oracle database 12c that will be released soon. In the last article I wrote about a considerable architectural change that Oracle is going to introduce with help of Oracle 12c Pluggable database feature. Let’s continue and explore some details of Oracle 12c Pluggable database feature.
Bear in mind that conventional database mode will be still available in 12c database. That means you will have two options of creating a usual old-fashioned Oracle database (non-CDB) or creating a Container Database (CDB) that will hold all your Pluggable Databases (PDB) that you will create or plug later. See below more details.
12c Pluggable Database details
– Each PDB has its own private data dictionary for customer-created database objects; CDB on the other hand as a whole has the data dictionary for the Oracle-supplied system each data dictionary defines its own namespace. In other words, there is global Data dictionary (CDB level) and local one (PDB level).
– There is a new split data dictionary architecture that allows a PDB to be quickly unplugged from one CDB and plugged into a different CDB
– Each PDB sees a read-only definition of the Oracle-supplied system
– There are global database initialisation parameters on CDB level and local ones. PDB parameters belong only to you particular PDB and will be persistent even after you unplug you PDB.
– Database users can be global (CDB) or local (PDB only). SYS and SYSTEM users exist in both DBs right at the beginning. If you create a new user in CDB you will see it in PDB also. In case of creation of a user on PDB level it will stay local.
– Temporary tablespaces can be global or local
– Redo logs and Undo tablspace are only global (on CDB level)
– Data Guard acts on the CDB as a whole; RMAN scheduled backups are done for the CDB as a whole; you can back up a selected PDB whenever you want to; you can do point-in-time
– An application connects, with no code changes, to a PDB; the system administrator connects to the CDB; the service named in the connect string specifies the destination PDB
– A PDB allows a clear declarative definition of an application; one PDB knows nothing of the other PDBs within the same CDB; each PDB is a hermetically sealed container. That ensures new level of DB independence and robust security
Connecting to a PDB
As a side-effect of creating a PDB, a service is created inside it with a property that identifies it as the initial current container. You can discover the current container with below SQL statement:
select Sys_Context('Userenv', 'Con_Name') "current container" from dual;
At the 12.1 SQL*Plus prompt, you can use SHOW Con_Name.
The service is also started as a side-effect of creating the PDB. The service has the same name as the PDB; and though its metadata is recorded inside the PDB. Sessions will be typically created by authorizing as a user that cannot change the current container.
Client-side application code is normally designed so that the connection specification is done outside of the code. For example, the code might use a TNS alias to allow the connect string that it defines to be changed without changing the application code.
Of course you can have many services within a PDB. Each will denote the PDB within which it is defined as the initial current container. Use the normal methods to create, maintain, and drop additional services in a PDB. A PDB’s default service must not be dropped. The only way to establish a session whose initial container is a PDB is to specify a service.
See below an example how to connect to Oracle 12c CDB called “cdb1” and then to one of the PDBs using Easy Connect syntax:
sqlplus Sys/Sys@localhost:1521/cdb1 AS SYSDBA
and later this:
I’ll continue giving more details about Pluggable Database feature in the next posts