On the Twelfth Day of 12.2, my DBA gave to me…

Pluggable Databases (PDBs) New Features

[hr width=”2px” color=”#2980b9″ style=”solid”][/hr]

December 23, 2016

Oracle introduced their Pluggable Databases (PDBs) technology in Oracle Database 12c Release 1, with the goal of helping customers migrate and consolidate hundreds, or even thousands, of standalone databases; into their multitenant pluggable databases on the private database cloud or to Oracle’s Database Cloud Service. Architecturally, a PDB is a fully functional, self-contained Oracle database, and applications cannot distinguish differences of being connected to a PDB versus a standalone database. PDBs also have complete secured isolation and separation, as if they were two totally independent databases today.

For the last day of our Twelve Days of 12.2, we are going to focus on PDBs. There are so many new features in the PDB architecture in Oracle Database 12c Release 2, we can almost write a book just on this topic. In this article, we will focus on the key new features, and in 2017, one of our ACE Directors, Charles Kim, will run a separate series dedicated to PDBs and provide a deep-dive of architecture and code examples.

Hot Clones

In Oracle 12.1, when we clone a PDB, the source PDB must be quiesced for the duration of the cloning activity. The source database must incur a slight outage window for the duration of the cloning process. Oracle 12.2 Multitenant option, fully integrates the concept of “hot clones” with the ability to perform on-line cloning of PDBs. With hot clones, the source database is still open for read-write mode. Starting with Oracle 12.2, all PDB clones are hot clones and will be referred to as clones.

Read-Only Refreshable PDBs

Building on top of the hot clone technology, Oracle 12.2 offers the Refreshable PDB feature. A classic use case of a Refreshable PDB, is a reporting database that can withstand a 24-hour lag from the primary database. When we clone a PDB, the creation time to copy data from the source PDB, can take hours or even days depending on the size of your database. Since we are now on Oracle 12.2, the duration of time does not matter, as PDBs can be cloned while the source PDB is online. With Refreshable PDBs, we can have the PDB refresh data from the source PDB with delta changes, since the last refresh automatically (define in nnn Minutes) or on demand. There are several restrictions for the refresh to work:

1. The Refreshable PDB must never be opened in read-write mode. Bringing the Refreshable PDB to read-write mode, will cause Oracle to not be able to apply UNDO information from the source.

2. During the refresh process, the Refreshable copy must be shutdown.
To create a Refreshable PDB, we can use the CREATE PLUGGABLE DATABASE with the new options for:
• REFRESH MODE EVERY nnn MINUTES; Where nnn is represented in minutes
• REFRESH MODE MANUAL;

Where the PDB is refreshed on-demand

Once the PDB is created with the REFRESH MODE, we need to open the PDB in READ ONLY mode with the ALTER PLUGGABLE DATABASE pdbrefresh1 READ ONLY command. We can manually refresh any Refreshable PDB with the ALTER PLUGGABLE DATABASE [pdb name] REFRESH statement.

PDB Relocate

PDB Relocate is built on top of Refreshable PDB technology. Instead of hot cloning a PDB, migrating users from old to the new PDB, and dropping the source PDB once the clone is complete; Oracle offers a new RELOCATE clause to the CREATE PLUGGABLE DATABASE, to “relocate” a PDB from one container database (CDB) to another container database. The PDB can be relocated to another CDB on the same server, within the same data center or across data centers. To relocate a PDB, we have to issue the CREATE PLUGGABLE DATABSE command with the FROM and RELOCATE clauses. Relocating a PDB is the fastest way to move a PDB from one CDB to another with minimal downtime. While the relocation process is occurring, database connections still persist on the original PDB. When the statement completes, there will be two transactionally consistent PDBs running.

Next, Oracle quiesces the source PDB, to transport and apply redo data to the relocating PDB. When the PDB is ready, the relocated PDB will be brought online on the new target CDB. During the relocation process to the new CDB, DML and DDL get quiesced and redirected to the relocated PDB. SELECT queries continue to be executed without any pause.

Next, Oracle has to relocate all the database connections. In a nutshell, connections are slowly drained from the original PDB to the new relocated PDB. When we open the new PDB on the target CDB, the source PDB is dropped.

Localized UNDO

As of Oracle 12.2, we have the option to run UNDO in the local PDBs. If the local UNDO option is enabled, each of the PDBs will have it’s own UNDO tablespace. There is no mix of partial….

[link_button link=”https://viscosityna.com/resources/dba-resources/twelve-days-12-2/day-12-pdbs/” size=”small” color=”#1CC6DA” align=”left”]Get Full Version[/link_button]