Plugin a Pluggable Database (PDB) Manually

Plugin a Pluggable Database (PDB) Manually

Plugging in a PDB into the CDB is similar to creating a new PDB. First check the PBD is compatible with the CDB by calling the DBMS_PDB.CHECK_PLUG_COMPATIBILITY function, passing in the XML metadata file and the name of the PDB you want to create using it.

SET SERVEROUTPUT ON

DECLARE

  l_result BOOLEAN;

BEGIN

  l_result := DBMS_PDB.check_plug_compatibility(

                pdb_descr_file => '/u01/app/oracle/oradata/cdb1/pdb2/pdb2.xml',

                pdb_name       => 'pdb2');

  IF l_result THEN

    DBMS_OUTPUT.PUT_LINE('compatible');

  ELSE

    DBMS_OUTPUT.PUT_LINE('incompatible');

  END IF;

END;

/

compatible

PL/SQL procedure successfully completed.

SQL>

If the PDB is compatible, create a new PDB using it as the source. If we were creating it with a new name we might do something like this.

CREATE PLUGGABLE DATABASE pdb5 USING '/u01/app/oracle/oradata/cdb1/pdb2/pdb2.xml'

  FILE_NAME_CONVERT=('/u01/app/oracle/oradata/cdb1/pdb2/','/u01/app/oracle/oradata/cdb1/pdb5/');

Instead, we want to plug the database back into the same container, so we don't need to copy the files or recreate the temp file, so we can do the following.

CREATE PLUGGABLE DATABASE pdb2 USING '/u01/app/oracle/oradata/cdb1/pdb2/pdb2.xml'

  NOCOPY

  TEMPFILE REUSE;

ALTER PLUGGABLE DATABASE pdb2 OPEN READ WRITE;

SELECT name, open_mode

FROM   v$pdbs

ORDER BY name;

NAME                          OPEN_MODE

------------------------------ ----------

PDB$SEED                      READ ONLY

PDB1                          MOUNTED

PDB2                          READ WRITE

PDB3                          READ WRITE

SQL>

Create a Pluggable Database (PDB) Manually

Create a Pluggable Database (PDB) Manually

To create a new pluggable database from the seed database, all we have to do is tell Oracle where the file should be placed. We can do this using one of two methods. The first method uses theFILE_NAME_CONVERT clause in the CREATE PLUGGABLE DATABASE statement.

CONN / AS SYSDBA

CREATE PLUGGABLE DATABASE pdb2 ADMIN USER pdb_adm IDENTIFIED BY Password1

  FILE_NAME_CONVERT=('/u01/app/oracle/oradata/cdb1/pdbseed/','/u01/app/oracle/oradata/cdb1/pdb2/');

Alternatively, we can specify the PDB_FILE_NAME_CONVERT initialization parameter before calling the command without using the FILE_NAME_CONVERT clause.

CONN / AS SYSDBA

ALTER SESSION SET PDB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/cdb1/pdbseed/','/u01/app/oracle/oradata/cdb1/pdb3/';

CREATE PLUGGABLE DATABASE pdb3 ADMIN USER pdb_adm IDENTIFIED BY Password1;

Every time there is a need to convert file locations, either of these two methods will work. For the remainder of the article I will stick to using the FILE_NAME_CONVERT method to cut down on the variations I have to display.

We can see the PDBs are present by querying the DBA_PDBS and V$PDBS views.

COLUMN pdb_name FORMAT A20

SELECT pdb_name, status

FROM   dba_pdbs

ORDER BY pdb_name;

PDB_NAME            STATUS

-------------------- -------------

PDB$SEED            NORMAL

PDB1                NORMAL

PDB2                NEW

PDB3                NEW

SQL>

SELECT name, open_mode

FROM   v$pdbs

ORDER BY name;

NAME                          OPEN_MODE

------------------------------ ----------

PDB$SEED                      READ ONLY

PDB1                          MOUNTED

PDB2                          MOUNTED

PDB3                          MOUNTED

SQL>

The PDBs are created with the status of 'NEW'. They must be opened in READ WRITE mode at least once for the integration of the PDB into the CDB to be complete.

ALTER PLUGGABLE DATABASE pdb2 OPEN READ WRITE;

ALTER PLUGGABLE DATABASE pdb3 OPEN READ WRITE;

SELECT pdb_name, status

FROM   dba_pdbs

ORDER BY pdb_name;

PDB_NAME            STATUS

-------------------- -------------

PDB$SEED            NORMAL

PDB1                NORMAL

PDB2                NORMAL

PDB3                NORMAL

SQL>

SELECT name, open_mode

FROM   v$pdbs

ORDER BY name;

NAME                          OPEN_MODE

------------------------------ ----------

PDB$SEED                      READ ONLY

PDB1                          MOUNTED

PDB2                          READ WRITE

PDB3                          READ WRITE

SQL>

Note. Depending on the syntax used, you may need to grant the PDB_DBA role to the local admin users for the PDB.

Oracle PL/SQL Interview Questions       When Use ADG (Active Data Guard)

Oracle GoldenGate    Oracle Active Data Guard and Oracle GoldenGate
GO TO ORACLE Technology Network

Container & Pluggable Databases 12C

Container Database & Pluggable Databases:

The multitenant option represents one of the biggest architectural changes in the history of the Oracle database. The option introduced the concepts of the Container Database (CDB) and Pluggable Database (PDB).

• Container Databases (CDB) : This seems very similar to a conventional Oracle database, as it contains most of the working parts you will be already familiar with (controlfiles, datafiles, undo, tempfiles, redo logs etc.). It also houses the data dictionary for those objects that are owned by the root container and those that are visible to all PDBs.
• Pluggable Database (PDB) : Since the CDB contains most of the working parts for the database, the PDB only needs to contain information specific to itself. It does not need to worry about controlfiles, redo logs and undo etc. Instead it is just made up of datafiles and tempfiles to handle it's own objects. This includes it's own data dictionary, containing information about only those objects that are specific to the PDB.
  

This split of the data dictionary between common objects, in the root container, and PDB-specific objects, in the PDB's data dictionary, is very important, because this separation is what gives the multitenant option its flexibility. From the perspective of the PDB, the data dictionary is the union of the root and PDB data dictionaries, so internally the PDB feels very much like a normal Oracle database. For example, the DBA_% and ALL_% views within the PDB appears the same as any non-CDB database.

Creating Pluggable Databases (PDBs)

Since the bulk of the working parts are already present in the root container, creating a new PDB is a comparatively quick and simple task. When creating a completely new PDP, the PDB is created as a copy of a seed PDB, so it only takes as long as the files take to copy.

Instead of creating a new PDB from the seed, you can clone an existing PDB.

It is also possible to create clones in a remote CDB.

Oracle PL/SQL Interview Questions       When Use ADG (Active Data Guard)

Oracle GoldenGate    Oracle Active Data Guard and Oracle GoldenGate
GO TO ORACLE Technology Network

Dividing the Backup of a Large Datafile into Sections

If you specify the SECTION SIZE parameter on the BACKUP command, then RMAN creates a backup set in which each backup piece contains the blocks from one file section. A file section is a contiguous range of blocks in a file. This type of backup is called a multi-section backup.

Note:
You cannot specify SECTION SIZE in conjunction with MAXPIECESIZE.
The purpose of multisection backups is to enable RMAN channels to back up a single large file in parallel. RMAN divides the work among multiple channels, with each channel backing up one file section in a file. Backing up a file in separate sections can improve the performance of backups of large datafiles.

If a multisection backup completes successfully, then none of the backup sets generated during the backup contain a partial datafile. If a multisection backup is unsuccessful, then it is possible for the RMAN metadata to contain a record for a partial backup set. RMAN does not consider partial backups for restore and recovery. You must use the DELETE command to delete the partial backup set.

If you specify a section size that is larger than the size of the file, then RMAN does not use multisection backup for the file. If you specify a small section size that would produce more than 256 sections, then RMAN increases the section size to a value that results in exactly 256 sections.

To make a multisection backup:

Start RMAN and connect to a target database and recovery catalog (if used).

If necessary, configure channel parallelism so that RMAN can parallelize the backup.

Execute BACKUP with the SECTION SIZE parameter.

For example, suppose that the users tablespace contains a single datafile of 900 MB. Also assume that three SBT channels are configured, with the parallelism setting for the SBT device set to 3. You can break up the datafile in this tablespace into file sections as shown in the following example:

BACKUP
  SECTION SIZE 300M
  TABLESPACE users; 

In this example, each of the three SBT channels backs up a 300 MB file section of the users datafile.

RMAN script to take full database backup

RMAN script to take full database backup

Before taking a backup using RMAN , First we have to decide which type of backup you want to take. You can take online or offline backup using RMAN. For online backups, database archiving must be turned ON. If archiving of you database is not ON, database must be in MOUNT stage to take backup using RMAN. Oracle recommends you to turn ON archiving to protect your data. This example is tested with online backup option.

 First step is to start RMAN, click Start->Run and type RMAN and press Enter key.
 Second step is to connect RMAN to database. In this example, RMAN metadata will be saved in control

 file of target database. Now, issue following commands to connect database.
  RMAN> Connect target /
  Here note down DBID of database. This DBID will be used in recovery process
Third step is to Create a directory name as “D:\RMANBACKUP”. Now type following script to take full database backup.

RMAN> run{
2> configure controlfile autobackup format for device type disk to 'd:/rmanbackup/%F';
3> configure controlfile autobackup on;
4> allocate channel d1 type disk;
5> backup tag FULL_DB format 'd:/rmanbackup/db_%t_%s.bk' (database);
6> release channel d1;
7> }
After the procedure is competed, you will find backupup files in “D:\RMANBACKUP” directory.These backup files can be used to recover any datafile or all datafiles, control file or SPFILE.

In production database, you will have several backups. What if you want to restore a particular backup? To handle this issue, RMAN supports a TAG with each backup. In above script tag FULL_DB is used at line 3. At the time of recovery this tag can be used to restore a particular backup.
Following is the snapshot of all above process.