FLASHBACK DATABASE

Purpose

Use the FLASHBACK DATABASE command to rewind the database to a target time, SCN, or log sequence number.

This command works by undoing changes made by Oracle Database to the data files that exist when you run the command. Flashback can fix logical failures, but not physical failures. Thus, you cannot use the command to recover from disk failures or the accidental deletion of data files.

FLASHBACK DATABASE is usually much faster than a RESTORE operation followed by point-in-time recovery, because the time needed to perform FLASHBACK DATABASE depends on the number of changes made to the database since the desired flashback time. On the other hand, the time needed to do a traditional point-in-time recovery from restored backups depends on the size of the database.

Flashback Database also has several uses in a Data Guard environment.

Prerequisites

You can run this command from the RMAN prompt or from within a RUN command.

RMAN must be connected as TARGET to a database, which must be Oracle Database 10g or later. The target database must be mounted with a current control file, that is, the control file cannot be a backup or re-created. The database must run in ARCHIVELOG mode.

You cannot use FLASHBACK DATABASE to return to a point in time before the restore or re-creation of a control file. If the database control file is restored from backup or re-created, then all existing flashback log information is discarded.

The fast recovery area must be configured to enable flashback logging. Flashback logs are stored as Oracle-managed files in the fast recovery area and cannot be created if no fast recovery area is configured. You must have enabled the flashback logging before the target time for flashback using the SQL statement ALTER DATABASE ... FLASHBACK ON. Query V$DATABASE.FLASHBACK_ON to see whether flashback logging has been enabled.

The database must contain no online tablespaces for which flashback functionality was disabled with the SQL statement ALTER TABLESPACE ... FLASHBACK OFF.

Usage Notes

A Flashback Database operation applies to the whole database. You cannot flash back individual tablespaces. A Flashback Database operation is similar to a database point-in-time recovery (DBPITR) performed with RECOVER, but RMAN uses flashback logs to undo changes to a point before the target time or SCN. RMAN automatically restores from backup any archived redo log files that are needed and recovers the database to make it consistent. RMAN never flashes back data for temporary tablespaces.

The earliest SCN that can be used for a Flashback Database operation depends on the setting of the DB_FLASHBACK_RETENTION_TARGET initialization parameter, and on the actual retention of flashback logs permitted by available disk. View the current database SCN in V$DATABASE.CURRENT_SCN.

Effect of NOLOGGING Operations on Flashback Database

When using FLASHBACK DATABASE with a target time at which a NOLOGGING operation was in progress, block corruption is likely in the database objects and data files affected by the NOLOGGING operation. For example, assume that you do a direct-path INSERT operation in NOLOGGING mode and that the operation runs from 9:00 to 9:15 on April 3. If you later use Flashback Database to return to 09:07 on this date, then the objects and data files updated by the direct-path INSERT may be left with block corruption after Flashback Database completes.

If possible, avoid using FLASHBACK DATABASE with a target time or SCN that coincides with a NOLOGGING operation. Also, perform a full or incremental backup of the affected data files immediately after any NOLOGGING operation to ensure recoverability to points in time after the operation. If you expect to use FLASHBACK DATABASE to return to a point in time during an operation such as a direct-path INSERT, then consider performing the operation in LOGGING mode.

Effect of Data File Status Changes on Flashback Database

The FLASHBACK DATABASE command does not start modifying the database until it has made sure that it has all the files and resources that it needs. A Flashback Database operation should never fail due to missing data files, redo log files, or flashback logs.

If a data file has changed status between the current SCN and the target SCN of the flashback, then the FLASHBACK DATABASE command behaves differently depending on the nature of the status change. Refer to Table 2-8 for details.

Tablespaces with Flashback Logging Disabled

It is possible for the ALTER TABLESPACE ... FLASHBACK OFF statement to have been executed for some tablespaces. If FLASHBACK DATABASE has insufficient flashback data to rewind a tablespace to the target SCN, then RMAN issues an error and does not modify the database. Whenever FLASHBACK DATABASE fails or is interrupted, the database is left mounted.

In this scenario, query V$TABLESPACE to determine which tablespaces have flashback logging disabled. You have the following options:

• Take the data files in the affected tablespaces offline. Afterwards, run RESTORE and then RECOVER to bring these data files to the same point in time as the rest of the database.

• Drop the affected data files with the ALTER DATABASE DATAFILE ... OFFLINE FOR DROP statement. You can then open the database with the RESETLOGS option. After the database is open, execute DROP TABLESPACE statements for the tablespaces that contain the dropped data files.

State of the Database After Flashback Database

After running FLASHBACK DATABASE, the database may not be left at the SCN most immediately before the target time. Events other than transactions can cause the database SCN to be updated. If you use the FLASHBACK DATABASE TO form of the command, and if a transaction is associated with the target SCN, then after the flashback the database includes all changes up to and including this transaction. Otherwise, all changes up to but not including this transaction are included in the data files, whether you use the FLASHBACK DATABASE TO or FLASHBACK DATABASE TO BEFORE form of the command. Changes after the specified target SCN are never applied because of a FLASHBACK DATBASE.

After FLASHBACK DATABASE completes, you may want to open the database read-only and run queries to ensure that you achieved the intended result. If you are not satisfied, then you can use RECOVER DATABASE to recover the database to its state when you started the flashback. You can then rerun FLASHBACK DATABASE.

If you are satisfied with the results of the flashback, then you can OPEN RESETLOGS to abandon all changes after the target time. Alternatively, you can use Data Pump to export lost data, use RECOVER DATABASE to return the database to its state before the flashback operation, and then use Data Pump to reimport the lost data.

Syntax

flashback::=

(deviceSpecifier::=)

Semantics

Examples

SQL> SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME
  2  FROM   V$FLASHBACK_DATABASE_LOG;

OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK
-------------------- ----------------
              411010 2007/02/14 16:49

RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
RMAN> FLASHBACK DATABASE TO SCN 411010;
 
Starting flashback at 15-FEB-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=104 device type=DISK
 
 
starting media recovery
media recovery complete, elapsed time: 00:00:07
 
Finished flashback at 15-FEB-07
 
RMAN> ALTER DATABASE OPEN RESETLOGS;

SQL> CREATE RESTORE POINT before_update GUARANTEE FLASHBACK DATABASE;

RMAN> LIST RESTORE POINT ALL;

SCN              RSP Time  Type       Time      Name
---------------- --------- ---------- --------- ----
412742                     GUARANTEED 15-FEB-07 BEFORE_UPDATE

RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
RMAN> FLASHBACK DATABASE TO RESTORE POINT 'BEFORE_UPDATE';
 
Starting flashback at 15-FEB-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=104 device type=DISK
 
 
starting media recovery
 
archived log for thread 1 with sequence 34 is already on disk as file /disk2/oracle/oradata/prod/arch/archive1_34_614598462.dbf
media recovery complete, elapsed time: 00:00:01
Finished flashback at 15-FEB-07
 
RMAN> ALTER DATABASE OPEN RESETLOGS;