On the Tenth Day of 12.2, my DBA gave to me… RMAN New Features

The following are changes in the Oracle Database Backup and Recovery Reference for Database 12c Release 2 (12.2.01). All features require the COMPATIBLE initialization parameter must be set to or higher.

Perform Flashback on a Pluggable Database (PDB) to a Specified Point in Time

You can perform a flashback database operation to rewind an individual PDB to a previous point in time. This enables you to reverse unwanted changes made to a single PDB, without impacting the operation of the remaining PDBs. When using restore points, you can rewind the PDB, to either a PDB restore point or CDB restore point. PDB restore points can be normal restore points or guaranteed restore points. Additionally, in 12.2 users can execute a database flashback on a CDB across PDB, PITR or PDB flashback operations. The PDB on which a Flashback Database operation is being performed must be closed, though other PDBs may be open and operational. When invoking the RMAN RECOVER command, RMAN must be connected to the root as a common user with the SYSDBA or SYSBACKUP privilege. This example will illustrate the PDB Flashback capability. First, create a guaranteed PDB restore point in vnapdb when connected to the PDB (the PDB is mounted). Then, perform DML operations on the tables in the PDB vnapdb. Now, we would like to rewind the PDB just before the data changes, which in this case is the restore point, VNAPDB_GRP_BEFORE_CHANGES, which is a guaranteed PDB restore point. Connect to the CDB as a common user with the SYSDBA or SYSBACKUP privilege. To perform a flashback operation for VNAPDB, this PDB must be closed. All other PDBs in the CDB can remain open and operational. Place the PDB in mount mode, flash back the PDB to the guaranteed PDB restore point, and then open the PDB with resetlogs. In this example, the CDB uses shared undo, therefore, an auxiliary instance is used to store temporary files during the flashback operation. SQL> CREATE RESTORE POINT vnapdb_grp_before_changes GUARENTEE FLASHBACK DATABASE; RMAN> SHUTDOWN IMMEDIATE; RMAN> STARTUP MOUNT; RMAN> FLASHBACK PLUGGABLE DATABASE vnapdb TO RESTORE POINT vnapdb_grp_before_changes AUXILIARY DESTINATION ‘/temp/aux_dest’; RMAN> ALTER PLUGGABLE DATABASE vnapdb OPEN RESETLOGS;

Validation and Recovery of Nonlogged Data Blocks

In a Data Guard environment, you can perform recovery of non-logged data blocks, by fetching data blocks from the primary or physical standby database. You can also perform validation to determine if the data blocks, in the non-logged block ranges, are still invalid. To recover all blocks reported in the V$DATABASE_BLOCK_CORRUPTION view, either use RECOVER CORRUPTION LIST, specify the data file number and block number or specify the tablespace and data block address (DBA). For RMAN to be able to search a standby database for good copies of corrupt blocks, the target database must be associated with a physical, standby database in… To receive a full version emailed copy of this document, including more on Enhancements to Table Recovery, Enhancements to the DUPLICATE Command, Enhancements to Cross-Platform Transport, and Backup and Recovery of Sparse Databases, please complete the download form provided.


Full Name (required)

Your Email (required)

Company (required)

Phone number (required)

Job Title (required)