Pluggable Database Concepts

An Oracle Database instance is combination of SGA and group of background processes. An Oracle database is a group of files that contain data. In a single instance db, there  is a 1 to 1 relationship between an instance and a database. In a RAC environment, there are many to 1 relationship between instance and DB.

To have multiple DB on the same machine, you need to run multiple DB instance. So, in a single instance DB, if you have 3 mounted DB, you will need 3 DB instances. With PDB, the idea is to remove this duplication of resources and to share one DB instance with multiple DBs now referred to as CDBs.


A container Database (CDB) contains Plugable database (PDB)

A container database consists of following three components each of which is called a container

• the root container (CDB$ROOT) which contains metadata for Oracle supplied objects
• Seed PDB (PBD$SEED) which contains metadata for user supplied objects
• PDBs which are generated by cloning seed PBD and assigned a unique ID upon creation.

At a physical level, the CDB has a database instance and database files, just as a non-CDB does.

The following files exist only in root container:

• The redo log files
• The redo log files are common for the whole CDB and therefore the information it contains is annotated with the identity of the PDB where a change occurs. All PDBs in a CDB share the ARCHIVELOG mode of the CDB
• The control file
• The control files are also common for the whole CDB. The control files are updated to reflect any additional tablespaces and datafiles of plugged PDBs.
• Add info about undo tbsp ??

Following files exist either  in  both root container and user container or in one of them(PDBs and seed PDBs together form user container)

• Temporary tbsp (required in root ;optional in user container):
• A temporary tbsp is required in the root container.  This tbsp is optional in PDB. Each PDB can hold its own temporary tbsp for its own local users.
• System and SysAux tablespace (required in both containers)
• Each container has its own data dictionary stored in its proper SYSTEM tbsp ,containing its own metadata and a SYSAUX tbsp.
• User tablespace (only in user container)
• The PDBs can create their tbsp according to its application needs

Each datafile is associated with a specific container , named CON_ID.



There are four ways to provision a PDB:

• Create a new PDB from seed PDB
• Plug in a non-CDB as a PDB
• Clone a PDB from another PDB (in same or another CDB)
• Plug a unplugged PDB into another CDB. (However, a PDB can be plugged into only one CDB at a time)

You can plug or unplug a PDB from a CDB. A PDB can be plugged into only one CDB at a time.A CDB has a common users which can log in as root and adminster the PDB.You can create a CDB by either DBCA tool or by create database sql.

When you create a CDB, you can specify how many PDBs it will contain. Once the CDB is created, you can use DBCA to plug and unplug PDBs

When you create a CDB using a CREATE DATABASE sql statement, you must enable PDBs (by specifying enable PLUGGABLE DATABASE clause) and specify the names and locations of the seed's files.



Backup and Recovery:

• Backup :

RMAN will support backup and recovery of a CDB that contains zero or more PDBs. All RMAN operations will be performed while connected as root of a CDB. An individual PDB is not a valid RMAN target  db. New syntax, namely Pluggable Database, is introduced to allow backup of CDB.

• Recovery:

On a CDB, the recovery can be done for the entire CDB, for a PDB, a tbsp, a datafile or even a block.

If the files in the root container are lost (namely redo log file, control files, temp tbsp, ...)the only possible  recovery is once CDB is in a mounted state.

How to create “Cold” RMAN Backup

 

This blog entry describes how to take rman backup of a database with NOARCHIVELOG mode. The only option you have to take backup of a NOARCHIVELOG mode database is to take consistent whole database backup.

The characteristic of a consistent backup is as under:

• All read/write datafiles and control files are checkpointed with the same system change number (SCN)
• A consistent backup does not need recovery after it is restored as all files in the backup are guaranteed to contain all changes up to the same SCN.

The steps involved in taking consistent backup as as under:

• Make sure the database is shutdown properly.
• If the database is not shut down consistently, for example, an instance fails or you issue a “shutdown abort” statement, then the datafiles are always inconsistent and hence your restore will fail. The script is shutting down the database twice as to ensure that the datafiles are in consistent state.
• Startup the database in mount option
• Configure the location where you need to take the backup
• The script is backing up the database on an disk at ‘backupPool/backup’ directory
• Configure autobackup of controlfile and specify a location where control file will be backed up.
• Backup the complete database

Here is the script to take cold rman backup:

#!/bin/sh
echo "Taking backup of $ORACLE_SID\n"
#rman target /  log=backupbench.log << !

shutdown immediate ;
startup  pfile=p_build.ora force dba;
shutdown immediate;
startup pfile=p_build.ora mount ;

configure device type disk parallelism 15 backup type to  backupset ;
configure channel device type disk format '/backupPool/backup/ora_df%t_s%s_s%p' ;
configure controlfile autobackup on ;
configure controlfile autobackup format for device type  disk to  '/backupPool/backup/cf_%F' ;

backup database tag 'JGD_create';
alter database open;
exit
!