Category Archives: PDB

Configure listener.ora for PDB

With Oracle 12c multitenant databases connection is still normally performed through the Oracle networking files of listener.ora, tnsnames.ora, and sqlnet.ora.   PDBs are contained within a specific CDBs thus no configuration of the listener is needed.   The listener process will pick up all active PDBs on startup if the PDB is started within its CDB.  However, you can test the connection to a PDB through the listener process as shown below.

 

 

  1. Logon to your Oracle Server as the oracle software owner.

 

[larry@linux2 ~]$ su – oracle

Password:

Last login: Mon Feb 24 09:57:56 EDT 2016 on pts/0

[oracle@linux2 ~]$

 

  1. Now start the listener with the command: lsnrctl start

 

[oracle@linux2 ~]$ lsnrctl start

 

LSNRCTL for Linux: Version 12.1.0.2.0 – Production on 24-FEB-2016 10:58:06

 

Copyright (c) 1991, 2014, Oracle.  All rights reserved.

 

Starting /opt/app/oracle/product/12.1.0.2/db_1/bin/tnslsnr: please wait…

 

TNSLSNR for Linux: Version 12.1.0.2.0 – Production

System parameter file is /opt/app/oracle/product/12.1.0.2/db_1/network/admin/listener.ora

Log messages written to /opt/app/oracle/diag/tnslsnr/linux2/listener/alert/log.xml

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.30.15.75)(PORT=1521)))

 

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.30.15.75)(PORT=1521)))

STATUS of the LISTENER

————————

Alias                     LISTENER

Version                   TNSLSNR for Linux: Version 12.1.0.2.0 – Production

Start Date                24-FEB-2016 10:58:06

Uptime                    0 days 0 hr. 0 min. 0 sec

Trace Level               off

Security                  ON: Local OS Authentication

SNMP                      OFF

Listener Parameter File   /opt/app/oracle/product/12.1.0.2/db_1/network/admin/listener.ora

Listener Log File         /opt/app/oracle/diag/tnslsnr/linux2/listener/alert/log.xml

Listening Endpoints Summary…

  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.30.15.75)(PORT=1521)))

Services Summary…

Service “cdb1” has 1 instance(s).

  Instance “cdb1”, status UNKNOWN, has 1 handler(s) for this service…

The command completed successfully

[oracle@linux2 ~]$

 

  1. List all serviced SIDs and Services with the command: lsnrctl status.

 

[oracle@linux2 admin]$ lsnrctl status

 

LSNRCTL for Linux: Version 12.1.0.2.0 – Production on 24-FEB-2016 11:08:45

 

Copyright (c) 1991, 2014, Oracle.  All rights reserved.

 

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.30.15.75)(PORT=1521)))

STATUS of the LISTENER

————————

Alias                     LISTENER

Version                   TNSLSNR for Linux: Version 12.1.0.2.0 – Production

Start Date                24-FEB-2016 10:58:06

Uptime                    0 days 0 hr. 10 min. 39 sec

Trace Level               off

Security                  ON: Local OS Authentication

SNMP                      OFF

Listener Parameter File   /opt/app/oracle/product/12.1.0.2/db_1/network/admin/listener.ora

Listener Log File         /opt/app/oracle/diag/tnslsnr/linux2/listener/alert/log.xml

Listening Endpoints Summary…

  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.30.15.75)(PORT=1521)))

Services Summary…

Service “cdb1” has 2 instance(s).

  Instance “cdb1”, status UNKNOWN, has 1 handler(s) for this service…

  Instance “cdb1”, status READY, has 1 handler(s) for this service…

Service “cdb1XDB” has 1 instance(s).

  Instance “cdb1”, status READY, has 1 handler(s) for this service…

Service “pdb1” has 1 instance(s).

  Instance “cdb1”, status READY, has 1 handler(s) for this service…

The command completed successfully

[oracle@linux2 admin]$

 

NOTE:  The Service pdb1 is being handled by the Instance cdb1.   The SID you will see at the OS layer will be cdb1 and you will not see any SID named pdb1.   PDB1 is a service which is handled by the SID cdb1.

 

  1. You can test the listener configuration by suppling the tnsping utility with the <machine_IP>:<Port>/<service_name> as below:

 

[oracle@linux2 admin]$ tnsping 10.30.15.75:1521/pdb1

 

TNS Ping Utility for Linux: Version 12.1.0.2.0 – Production on 24-FEB-2016 11:38:30

 

Copyright (c) 1997, 2014, Oracle.  All rights reserved.

 

Used parameter files:

 

Used HOSTNAME adapter to resolve the alias

Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=pdb1))(ADDRESS=(PROTOCOL=TCP)(HOST=10.30.15.75)(PORT=1521)))

OK (10 msec)

[oracle@linux2 admin]$

 

  1. This completes configuration of listener.ora file for PDB.

 

 

Larry Catt

OCP

 

 

Root and Multitenant Architecture

Oracle multitenant database architecture gives the ability to virtualize oracle database implementations, similarly to OS virtualization.   The multitenant architecture has two main components:  The CDB – Container Database and PDB – Pluggable database.  These two components have many aspects which help to describe their architecture and are detailed below:

 

CDB – Container Database

  1. CDB is commonly referred to as the root container.
  2. One root container in any implementation and contains all oracle provided metadata and common user.
  3. CDB$ROOT is the name of the root container.
  4. All PDBs belong to a single root container.
  5. User or application data should never stored in the root.
  6. You can have common users for system administration in root that crosses all PDB in the root container.
  7. One seed PDB exist in all root containers, Oracle supplies this template to create new PDB.

 

PDB – Pluggable Database

  1. PDB$SEED is the name of the seed PDB in all root container databases.
  2. You cannot add or modify objects in PDB$SEED.
  3. Zero or more user-created PDBs in CDB.
  4. PDBs are entities that contain application data and code for specific features.
  5. PDBs do not contain oracle supplied metadata or common users.
  6. No PDBs exist at CDB creation.
  7. PDBs are uniquely named in a CDB.
  8. PDBs name must be unique across multiple CDB if using the same listener.

 

 

Larry Catt

OCP

Non-supported features in Oracle 12c Multitenant database (CDB)

As of Oracle 12c release 12.1.0.2  the following features are not supported for use in CDB instances.

  1. Database Change Notification
  2. Continuous Query Notification (CQN)
  3. Client Side Cache
  4. Heat Map
  5. Automatic Data Optimization
  6. Oracle Streams
  7. Oracle Fail Safe
  8. Flashback Pluggable Database (Flashback Database works but will flashback CDB$ROOT including all PDBs)
  9. DBVERIFY
  10. Data Recovery Advisor (DRA)
  11. Flashback Transaction Backout

 

Larry Catt

OCP

Methods to Migrate stand-alone database to PDB

12c release has given us the ability to virtualize databases.   These procedure outlines three methods to move a stand-alone database to a 12c PDB.   Each of these methods have both positive and negatives aspects.  Careful thought, analysis and some testing should be performed before deciding which method is best for your situation.

 

 

Method 1 – DBMS_PDB package.

DBMS_PDB package is provided with Oracle 12c RDBMS release.  It provides multiple procedures for checking, preparing, creating conversions, and cleaning up after movement of standalone database to PDB.

 

Pros:

  1. Removes guess work from conversion process.
  2. No coding on administrators part.
  3. No need to create PDB before procedure.

 

Cons:

  1. No ability to transform data elements.

 

Method 2 – Data Pump

Use the EXP/IMP to extract metadata and data from standalone database into PDB.

 

Pros:

  1. EXP/IMP utility of data pump are well known.
  2. Able to do inclusive/exclusive data movement.
  3. Able to start and stop.

 

Cons:

  1. Have to build CDB and PDB for destination.
  2. Can requires disk space for exports.
  3. Can be very time consuming.

 

Method 3 – Goldengate / ETL technology

Use Goldengate or other ETL tool to move data from existing standalone into PDB.

 

Pros:

  1. Can be done online with minimal down time.
  2. Is extremely flexible.
  3. Able to start and stop.
  4. Able to transform data during process.

 

Cons:

  1. Have to build CDB and PDB for destination.
  2. Expensive licensing cost.
  3. Can be time consuming.

 

 

 

Larry Catt

OCP

RMAN Backup of PDB in Oracle 12c Multitenant Database

RMAN backup of a PDB in Oracle 12c Multitenant Database can be performed from the Recovery Manager utility or EM Cloud Control.    This procedure shows the steps of performing a PDB backup from RMAN utility.

 

  1. Logon to your oracle database server as the oracle software owner.

 

[root@linux2 larry]# su – oracle

Last login: Thu Jan  3 11:02:25 EDT 2016 on pts/1

[oracle@linux2 ~]$

 

  1. Enter the RMAN utility.

 

[oracle@linux2 ~]$ rman

 

Recovery Manager: Release 12.1.0.2.0 – Production on Tue Jan 15 12:26:22 2016

 

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

 

RMAN>

 

 

  • You can now either connect to the CDB and issue BACKUP PLUGGABLE DATABASE command or connect directly to PDB and use BACKUP DATABASE

 

  1. Connect to your target CDB database with SYSBACKUP privilege.

 

RMAN> connect target ‘”sys/@cdb1 as sysbackup”‘

 

target database Password:

connected to target database: CDB1 (DBID=898165058)

 

RMAN>

 

  1. From the CDB issue BACKUP PLUGGABLE DATABASE
    • Single PDB backup

 

RMAN>  BACKUP PLUGGABLE DATABASE PDB1;

 

  • Or multiple PDB backup

 

RMAN>  BACKUP PLUGGABLE DATABASE PDB1, PDB2;

 

  1. Additionally you can connect directly to the PDB. To do this you must connect as a common user with sysdba or sysbackup privilege,  in this example we are using C##DBA.

 

RMAN> connect target ‘”c##dba/@pdb1 as sysdba”‘

 

target database Password:

connected to target database: CDB1 (DBID=898165058)

 

RMAN> backup database;

 

 

  1. This completes backup of PDBs in the Oracle 12c Multitenant Database.

 

 

 

Larry Catt

OCP

Configure Linux for multiple Oracle Database connections

You can have multiple database on a single server of any platform.    The key to this configuration is have the appropriate environmental parameter for the database you which to attach to.   This procedure demonstrates the setup of .bash_profile file to set the appropriate OS environmental parameters upon attachment as the Oracle software owner.  NOTE: This procedure was done on a Oracle Enterprise Linux server.

 

  1. Logon to your database server as the root user.

 

[larry@linux2 ~]$ su –

Password:

Last login: Wed Jan  7 08:49:18 EST 2016 on pts/1

[root@linux2 ~]#

 

  1. List the current databases running on your database server with command: ps –ef|grep smon

 

[root@linux2 ~]# ps -ef|grep smon

oracle    3793     1  0 08:47 ?        00:00:00 ora_smon_cdb1

oracle    6454     1  0 09:38 ?        00:00:00 ora_smon_orcl

root     15059 15008  0 13:44 pts/1    00:00:00 grep –color=auto smon

[root@linux2 ~]#

 

  1. From the ‘ps’ command, we can see there are two active database instance on this server: CDB1 and ORCL.   We need to adjust the .bash_profile file in the oracle software owner home directory to choose between these two instances at logon.
  2. Go to the home directory of your oracle software owner.

 

[root@linux2 ~]# cd /home/oracle

[root@linux2 oracle]#

 

  1. Now normal install of multiple databases on a single server will all use the same Oracle binaries, thus the only thing which will be different between the environmental variables will be the ORACLE_SID value. If something else is different, you can adjust the shell script below to allow for more variable definition.   In this example attach the following to end of the .bash_profile file with vi.

 

## Beginning of request for information

database=””

while [ -z “$db” ]

do

   echo “Enter database to use:”

   echo “1 – ORCL       “

   echo “2 – CDB1       “

   echo “Option > “

read db

   if [[ “$db” != “1” &&

         “$db” != “2” ]]

   then

      echo “$db” is not valid >&2

      db=””

   fi

done

## Ending of request for information </strong>

 

 

 

##Beginning of local variable definitions

if [[ $db = “1” ]]

then

   export ORACLE_SID=orcl

elif [[ $db = “2” ]]

then

   export ORACLE_SID=cdb1

else

   echo “Invalid options “

fi

## Ending of local variable definitions

 

  1. Now logon as the oracle software owner and you will be prompted to give 1 for orcl instance or 2 for cdb1. Any other options will produce nothing.

 

Choosing option 1 example:

 

[root@linux2 oracle]# su – oracle

Last login: Wed Jan  7 14:02:23 EST 2016 on pts/1

Enter database to use:

1 – ORCL

2 – CDB1

1

[oracle@linux2 ~]$ echo $ORACLE_SID

orcl

[oracle@linux2 ~]$

 

 

 

 

 

Choosing option 2 example:

 

[root@linux2 oracle]# su – oracle

Last login: Wed Jan  7 14:04:51 EST 2016 on pts/1

Enter database to use:

1 – ORCL

2 – CDB1

2

[oracle@linux2 ~]$ echo $ORACLE_SID

cdb1

[oracle@linux2 ~]$

 

 

Choosing option other than 1 or 2 example:

 

[root@linux2 oracle]# su – oracle

Last login: Wed Jan  7 14:12:24 EST 2016 on pts/1

Enter database to use:

1 – ORCL

2 – CDB1

Option >

3

3 is not valid

Enter database to use:

1 – ORCL

2 – CDB1

Option >

4

4 is not valid

Enter database to use:

1 – ORCL

2 – CDB1

Option >

 

 

 

  1. This completes setup of Linux for multiple Oracle Databases.

 

 

Larry Catt

OCP

 

Managing tablespaces in CDB and PDB

An Oracle 12c multitenant database consist of a CDB which houses one to many PDBs serving end user applications.    Thus objects such as tablespaces can become a little confusing to manage with questions of do they belong to CDB or PDB or both.   This article tries to clear this subject and give a brief tutorial in managing tablespaces in the multitenant architecture.

 

Rules to tablespaces in CDB and PDB:

 

  1. Permanent tablespace can only be associated with a single container (CDB or PDB).
  2. When you create a tablespace in a container, it belongs to that container.
  3. CDB can have only one active undo tablespace or one active undo tablespace for each instance of RAC.
  4. Only one default temporary tablespace for CDB.
  5. PDBs can use the CDB’s temporary tablespace.
  6. Each PDB can have its own default temporary tablespace.
  7. PDBs can have their own tablespaces.
  8. Permanent Default tablespace in PDB can still use the ALTER DATABASE command, but it is preferred to use the command:

ALTER PLUGGABLE DATABASE DEFAULT TABLESPACE tbs_user_pdb;

  1. CDB will have only one temporary tablespace.
  2. To modify the temporary tablespace for CDB, the current container must be root.
  3. You can have other temporary tablespaces in CDB with specific users assigned to them, but only one default.
  4. Each PDB can have only one temporary tablespace and when PDB is unplugged so is its temporary tablespace.

 

 

 

Managing tablespaces in Multitenant architecture.

 

  1. Logon as the oracle software owner.

[larry@linux2 ~]$ su – oracle

Password:

Last login: Tue Oct 25 09:29:48 EDT 2015 on pts/1

[oracle@linux2 ~]$

 

  1. Connect to your CDB with sqlplus and show current container.

 

[oracle@linux2 ~]$ sqlplus / as sysdba

 

SQL*Plus: Release 12.1.0.2.0 Production on Wed Oct 26 10:02:53 2015

 

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

 

 

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production

With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

 

SQL> show con_name

 

CON_NAME

——————————

CDB$ROOT

SQL>

 

  1. Create a new permanent tablespace in the root container of cdb1_user, set it as the default tablespace for root.

 

SQL> create tablespace cdb1_users

datafile ‘/opt/app/oradata/cdb1_users.dbf’ size 10m;  2

 

Tablespace created.

 

SQL> ALTER DATABASE DEFAULT TABLESPACE cdb1_users;

 

Database altered.

 

SQL>

 

  1. View tablespaces from the root container and default tablespaces.

 

SQL> select tablespace_name from dba_tablespaces;

 

TABLESPACE_NAME

——————————

SYSTEM

SYSAUX

UNDOTBS1

TEMP

USERS

CDB1_USERS

 

6 rows selected.

 

SQL> select distinct(default_tablespace) from dba_users;

 

DEFAULT_TABLESPACE

——————————

SYSAUX

CDB1_USERS

SYSTEM

 

 

  1. Change to one of your pluggable database and note that you cannot see the newly create tablespace cdb1_users.

 

SQL> alter session set container=pdb1;

 

Session altered.

 

SQL> select tablespace_name from dba_tablespaces;

 

TABLESPACE_NAME

——————————

SYSTEM

SYSAUX

TEMP

USERS

 

SQL>

 

  1. Create a tablespace tablespace in your PDB and move back to your root container.

 

SQL> create tablespace pdb1_users

datafile ‘/opt/app/oradata/pdb1_users.dbf’ size 10m;  2

 

Tablespace created.

 

SQL> select tablespace_name from dba_tablespaces;

 

TABLESPACE_NAME

——————————

SYSTEM

SYSAUX

TEMP

USERS

PDB1_USERS

 

SQL> alter session set container=CDB$ROOT;

 

Session altered.

 

SQL> select tablespace_name from dba_tablespaces;

 

TABLESPACE_NAME

——————————

SYSTEM

SYSAUX

UNDOTBS1

TEMP

USERS

CDB1_USERS

 

6 rows selected.

 

SQL>

 

 

  1. This completes the management of tablespaces within the multitenant database architecture.

 

Larry Catt

OCP

Benefits of Oracle CDB and PDB

New to Oracle 12c is the feature of multitenant databases or CBD/PDB implementation to add a form of Virtualization to the Oracle RDBMS world.    This new feature is designed to reduce the number of physical server machines currently required to house normal database suites.    It is fairly common to have a large number of small data stores in an organization to server various system needs and though the resource requirements of these data stores is relatively low, they still exist on a single VM or physical server.   CDB and PDB technology looks to resolve this issue by combining these databases into a single instance which appears to be stand-alone to the outside world.   This article lists and describes the benefits of a CDB/PDB implementation.

 

  1. Database Consolidation – Multitenant Databases implementations can consolidate several small databases on separate servers into a CDB using one server. Allowing the organization to minimize the number of physical or virtual servers being used without reducing the number of application data stores being accessed.

 

  1. Reduced Cost – Reduction in the number of physical and virtual machines in use saves money in hardware, labor costs, floor space, and a multitude of other ways.

 

 

  1. Rapid Implementation – Implementation of a new data store or the movement of existing database is significantly reduced both in complexity and resource requirements. New PDB can be created on the fly to test various applications and removed when no longer needed.

 

  1. Simplified Management – Reduced number of servers and database instances easies the burden placed on administrators and management to ensure proper operations of a data center. Thus allowing of an increased level of performance to end users.

 

  1. Separation of administrative duties – Administration of the CDB and PDB are branched along resource lines where CDB control memory and processes and allocate them to various PDBs based on needs. CDB administration consists of managing performance related to OS and internal processes.  PDB administration is focused on performance related to application using the data store.   Thus creating a well-defined separation of administrative duties between CDB and PDB.   DBA responsible for CDB administration are focused on system/processes performance improvements and DBA responsible for individual PDB are focused on application implementation performance.

 

  1. Simplified Patching – Patching/upgrade single CDB database which contains multiple PDBs and not multiple separate databases.

 

 

Larry Catt

OCP

Basics of Multitenant Container Database (CDB)

The IT industry has increasing developed server technology with increased levels of memory and processing power which have out grown traditional system setups of one application to one server.  Most modern physical servers are very capable of handling multiple applications and even multiple server platforms through Virtualization technologies.   This is just as true with RDBMS suites.   Oracle has developed Multitenant architecture databases to take advantage of excess server power and reduce the physical hardware foot print.   This technology is known as CDB – Container Databases and PDB – Pluggable Databases.

Container Databases (CDB) act as the container where you store all of your application and system databases.  It contains and manages all of the initialization parameters, memory resources, processor resource and shared services granted to the RDBMS by the OS and created through the RDBMS.   Container Databases should not be used by application data stores to process user requests or perform any action for an outside application.   It should only be used to house PDB data stores which do provide data storage and manipulations of applications.  CDB’s can hold one to many PDBs.

Pluggable Databases (PDB) act as the application data stores and perform all actions that a traditional Oracle database perform through the use of resources granted by the CDB.   It allows us to reduce the overhead of managing multiple Oracle RDBMS Suites and increase the utilization of current hardware resources.  PDB’s are housed in a single CDB and can be moved from one CDB to another CDB.

Larry Catt

OCP

Recovery of PDB in Oracle 12c Multitenant Database

Oracle 12c multitenant database can use the Recovery Manager utility or EM Cloud control to recover a database from a previously taken backup set.   This procedure outlines the general steps to recover a PDB database using the RMAN utility.

 

 

  1. Logon to your database server as the oracle software owner.

 

[root@linux2 etc]# su – oracle

Last login: Wed Nov 30 11:45:07 EST 2015 on pts/1

[oracle@linux2 ~]$

 

  1. Logon to RMAN utility with sysbackup privileges.

 

[oracle@linux2 ~]$ rman target ‘”/ as sysbackup”‘

 

Recovery Manager: Release 12.1.0.2.0 – Production on Thu Dec 1 09:26:07 2015

 

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

 

connected to target database: CDB1 (DBID=898155058)

 

RMAN>

 

  1. Place the database in mount mode.

 

RMAN> shutdown immediate

Oracle instance shut down

 

RMAN> startup mount

connected to target database (not started)

Oracle instance started

database mounted

Total System Global Area     734003200 bytes

Fixed Size                     2928728 bytes

Variable Size                524292008 bytes

Database Buffers             201326592 bytes

Redo Buffers                   5455872 bytes

 

RMAN>

 

  1. Issue the command; RESTORE PLUGGABLE DATABASE <PDB>;

 

RMAN> RESTORE PLUGGABLE DATABASE pdb1;

 

Starting restore at 01-DEC-15

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=22 device type=DISK

 

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00008 to /u01/oradata/cdb1/pdb1/system01.dbf

channel ORA_DISK_1: restoring datafile 00009 to /u01/oradata/cdb1/pdb1/sysaux01.dbf

channel ORA_DISK_1: restoring datafile 00010 to /u01/oradata/cdb1/pdb1/pdb1_users01.dbf

channel ORA_DISK_1: restoring datafile 00015 to /opt/app/oradata/pdb1_users.dbf

channel ORA_DISK_1: reading from backup piece /opt/app/oracle/fast_recovery_area/CDB1/3F4D938FE2151097E0534B0F1E0A4221/backupset/2015_12_01/o1_mf_nnndf_TAG20151201T092735_d40dy1qr_.bkp

channel ORA_DISK_1: piece handle=/opt/app/oracle/fast_recovery_area/CDB1/3F4D938FE2151097E0534B0F1E0A4221/backupset/2015_12_01/o1_mf_nnndf_TAG20151201T092735_d40dy1qr_.bkp tag=TAG20151201T092735

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:45

Finished restore at 01-DEC-15

 

RMAN>

 

  1. Issue the command RESTORE PLUGGABLE DATABASE <PDB>;

 

RMAN> RESTORE PLUGGABLE DATABASE pdb1;

 

Starting restore at 01-DEC-15

using channel ORA_DISK_1

 

skipping datafile 8; already restored to file /u01/oradata/cdb1/pdb1/system01.dbf

skipping datafile 9; already restored to file /u01/oradata/cdb1/pdb1/sysaux01.dbf

skipping datafile 10; already restored to file /u01/oradata/cdb1/pdb1/pdb1_users01.dbf

skipping datafile 15; already restored to file /opt/app/oradata/pdb1_users.dbf

restore not done; all files read only, offline, or already restored

Finished restore at 01-DEC-15

 

RMAN>

 

 

  1. You can remove any database archive redo logs after they are no longer needed using command: RECOVER DATABASE DELETE ARCHIVELOG;

 

RMAN> RECOVER DATABASE DELETE ARCHIVELOG;

 

Starting recover at 01-DEC-15

using channel ORA_DISK_1

starting media recovery

media recovery complete, elapsed time: 00:00:03

 

Finished recover at 01-DEC-15

 

RMAN>

 

 

  1. Examine RMAN logs for errors and if no errors open root and PDBs.

 

ALTER DATABASE OPEN;

ALTER PLUGGABLE DATABASE ALL OPEN;

 

RMAN> ALTER DATABASE OPEN;

Statement processed

 

RMAN> ALTER PLUGGABLE DATABASE ALL OPEN;

Statement processed

 

RMAN>

 

  1. This completes recovery of PDB database.

 

Larry Catt

OCP