Flashback Database Best Practices & Performance
(Doc ID 565535.1)
Last updated on JUNE 30, 2021
Applies to:Oracle Database Backup Service - Version N/A and later
Oracle Database - Enterprise Edition - Version 10.2.0.1 to 188.8.131.52 [Release 10.2 to 12.2]
Oracle Database Cloud Schema Service - Version N/A and later
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Information in this document applies to any platform.
Some application profiles may require special tuning or additional considerations when enabling flashback database or using guaranteed restore points.
This note describes
- flashback database benefits,
- performance observations,
- configuration best practices
- operational best practices,
- performance tuning for specific application workloads
This note is intended for database administrators who are using or considering using flashback database or guaranteed restore points.
Flashback Database Feature and its Benefits
Flashback database can be used to quickly flashback a database to a point in time as opposed to the traditional point-in-time recovery. Flashback database feature can provide the following benefits
- Point-in-time recovery – to quickly rewind the database to point-in-time by using restore points or normal flashback database functionality. This functionality can be used for 1) repair from failed batch updates that has modified a significant portion of the database, 2) repair from a crashed database where the current online redo log is corrupted or irreparable or 3) repair from a planned maintenance event (e.g. application change that changes the database) that goes awry.
- Data Guard Fast-start failover - to quickly reinstate the primary database.
- Manual primary database reinstate- if Data Guard is being used without the fast-start failover feature and a Data Guard failover is necessary, then flashback database can be used to manually reinstate the failed primary database. Reinstatement of the failed primary database via flashback can complete in minutes regardless of database size compared to much more extensive work and time required for database reinstantiation performed across the network. Using flashback database to reinstate a failed primary database after a failover is documented in the Data Guard Administration and Concepts guide.
- 11g Data Guard Snapshot Standby (<Note 443720.1> 11g Using Snapshot Standby Database or refer to Data Guard Concepts and Administration) - An implicit guaranteed restore point is created when a physical standby database is converted into a snapshot standby database and this restore point is used to flashback a snapshot standby to its original state when it is converted back into a physical standby database.
- To flashback a failed database upgrade - using flashback database rather than the conventional downgrade procedure is far quicker. This is practical when only the database upgrade has been done, the COMPATIBLE parameter remains at the source version, and no application data changes have occurred. Please see note for steps to achieve this goal....... Downgrading Database Without Executing catdwgrd.sql (11.1.0.x to 10.2.0.x/10.2.0.x to 10.2.0.x) (Doc ID 783643.1)
- Rolling Database Upgrades with Physical Standby Databases using Transient Logical Standby or DBMS_ROLLING - As part of the database rolling upgrade when a physical standby is temporarily converted to a logical standby, a guaranteed restore point is taken on the primary database prior to the upgrade process. This is so that the database can be flashed back and converted back to a physical standby after the upgrade. For details on this see the MAA paper, Database Rolling Upgrade using Data Guard and Automated Database Upgrades using Oracle Active Data Guard and DBMS_ROLLING at our website www.oracle.com/goto/maa
- RMAN - flashback database is integrated with Oracle Recovery Manager and used implicitly in recovery and explicitly if desired. One example of RMAN implicit use of flashback database is when block media recovery is performed.
- Snapshot Standby - Snapshot standby feature uses flashback database to help reinstate the database back to a physical database
- Restoring Test and Training Databases - Another common use of flashback database is for flashing back a test or training database to the same starting point after each test run or training session.
- Flashback PDB - Starting in Oracle 12.2 and higher, flashback PDB can rewind a pluggable database without affecting other PDBs. You can also create PDB restore points.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document