In Oracle 12c multitenant databases consist of a container database CDB which contain one or more pluggable databases PDB.   Startup of the PDB must be done after the CDB it is contained in has been started.   This procedures covers the startup and shutdown of all PDBs in a CDB.

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

[larry@linux2 ~]$ su – oracle

Password:

Last login: Mon Mar 24 14:55:04 EDT 2016 on pts/1

[oracle@linux2 ~]$

2. Logon to your CDB where the PDB you wish to start is stored.

[oracle@linux2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Tue Mar 25 09:41:06 2016

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

Connected to an idle instance.

SQL> startup open

ORACLE instance started.

Total System Global Area  734003200 bytes

Fixed Size                  2928728 bytes

Variable Size             524292008 bytes

Database Buffers          201326592 bytes

Redo Buffers                5455872 bytes

Database mounted.

Database opened.

SQL>

3. View the available PDBs within the CDB with SQL statement: select name, open_mode from v$pdbs.

SQL> select name, open_mode from v$pdbs;

NAME                           OPEN_MODE

—————————— ———-

PDB$SEED                       READ ONLY

PDB1                           MOUNTED

PDB2                           MOUNTED

SQL>

NOTE: MOUNTED is the closed state for a PDB while it CDB is open.

4. You have four options for PDBs to choose from:
   1. MOUNTED – PDB closed but CDB open.
   2. OPEN MIGRATE – PDB is open for upgrade and patching.
   3. OPEN READ ONLY – PDB is open for reads but not writes.
   4. OPEN READ WRITE – PDB is open for all operations.

All of this modes can be moved to and from with the SQL statement:  ‘ALTER PLUGGABLE DATABASE all <OPTION>;    In this step we will move all the PDBs from mounted to open read write.   NOTE: read write is optional.

SQL> alter pluggable database all open;

Pluggable database altered.

SQL> select name, open_mode from v$pdbs;

NAME                           OPEN_MODE

—————————— ———-

PDB$SEED                       READ ONLY

PDB1                           READ WRITE

PDB2                           READ WRITE

SQL>

5. You can close all the PDB with close option.

SQL>  alter pluggable database all close;

Pluggable database altered.

SQL> select name, open_mode from v$pdbs;

NAME                           OPEN_MODE

—————————— ———-

PDB$SEED                       READ ONLY

PDB1                           MOUNTED

PDB2                           MOUNTED

SQL>

6. You can actually specify the read write option and it will be accepted.

SQL> alter pluggable database all open read write;

Pluggable database altered.

SQL> select name, open_mode from v$pdbs;

NAME                           OPEN_MODE

—————————— ———-

PDB$SEED                       READ ONLY

PDB1                           READ WRITE

PDB2                           READ WRITE

SQL>

7. You cannot move from read write to simply read option with all PDB and you cannot move all PDB into read only mode. You can only open all PDBs in read write mode and close all PDBs with all option.

SQL> alter pluggable database all open read;

alter pluggable database all open read

                                     *

ERROR at line 1:

ORA-00922: missing or invalid option

SQL> alter pluggable database all close;

Pluggable database altered.

SQL> alter pluggable database all open read;

alter pluggable database all open read

                                     *

ERROR at line 1:

ORA-00922: missing or invalid option

SQL>

8. There are no other options to move all PDBs open mode. This completes startup and shutdown of all PDB within its CDB.

Larry Catt

OCP

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

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

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

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.

2. 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.

3. 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.

4. 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.

5. 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.

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

Larry Catt

OCP