Flashback and restore point in Container architecture - A study note

Flashback at container database-

In Oracle Database 12.1 flashback database operations were limited to the root container, and therefore affected all pluggable databases(PDBs) associated with the root container. Oracle Database 12.2 now supports flashback of a pluggable database.

In Oracle Database 12c Release 1 all containers in an instance shared the same undo tablespace. This mode is called SHARED UNDO MODE. In Oracle 12c Release 2 each container in an instance can use its own undo tablespace this is called LOCAL UNDO MODE. This mode is the default mode in this release.

select * from database_properties where property_name='LOCAL_UNDO_ENABLED';

Irrespective of local undo enabled or not, you can flashback a PDB in 12cR2.

In oracle 12.2 if local_undo is not enabled, then we can use AUXILIARY DESTINATION parameter , which will create an auxiliary instance with container database’s system,sysaux and undo tablespace, and then restore the PDB using rollback transactions. However this flahback will take a long time and will consume additional space on the auxiliary destination.

SQL> alter pluggable database SRPDB close;

SQL> flashback pluggable database SRPDB to SCN 345678 auxiliary destination '/oradata/aux_inst';

SQL> alter pluggable database SRPDBopen resetlogs;

Some facts about restore point in container database-

CDB restore points are accessible to every pluggable database (PDB) within the CDB. However, a CDB restore point does not reflect the PDB sub-incarnation of any of its PDBs.

CDB restore points are useful in the following scenarios:

The whole CDB needs to be recovered to a particular point in time.

Multiple PDBs in a CDB need to be recovered to a particular point in time.

PDB restore points are accessible only to the PDB in which they are defined. Creating a guaranteed PDB restore point requires careful consideration because such a restore point can prevent required flashback logs in the multitenant container database (CDB) from being reused. This can potentially impact CDB functioning because the fast recovery area could run out of space.

Clean PDB Restore Points

A clean PDB restore point is a PDB restore point that is created when the PDB is closed and when there are no outstanding transactions for that PDB. Clean PDB restore points are only applicable to CDBs that use shared undo.

Clean PDB restore points can be normal or guaranteed restore points. Use the CREATE CLEAN RESTORE POINT command to explicitly create a clean PDB restore point. For a CDB that uses shared undo, if a PDB is closed and it has no outstanding transactions, any PDB restore point created is marked as a clean PDB restore point.

If you anticipate that you may need to rewind a PDB to a particular point in time, for example, to a state just before an application upgrade, then it is recommended that you create a clean PDB guaranteed restore point.

For CDBs that use shared undo, a Flashback Database operation to a clean PDB restore point is faster than a Flashback Database operation to an SCN or other restore points that are not clean PDB restore points. This is because RMAN does not need to restore any backups while performing a flashback operation to a clean PDB restore point.

PDB restore points are accessible only to the PDB in which they are defined.