Limitations of Flashback Database
- Flashback Database can only undo changes to a data file made by Oracle Database. It cannot be used to repair media failures, or to recover from accidental deletion of data files.
- You cannot use Flashback Database to undo a shrink data file operation.
- You cannot use Flashback Database alone to retrieve a dropped data file. If you flash back a database to a time when a dropped data file existed in the database, only the data file entry is added to the control file. You can only recover the dropped data file by using RMAN to fully restore and recover the data file.
- If the database control file is restored from backup or re-created, all accumulated flashback log information is discarded. You cannot use FLASHBACK DATABASE to return to a point in time before the restore or re-creation of a control file.
Prerequisites for Flashback Database and Guaranteed Restore Points
- database must be running in ARCHIVELOG mode, because archived logs are used in the Flashback Database operation.
- You must have a fast recovery area enabled, because flashback logs can only be stored in the fast recovery area.
Guaranteed Restore Points
To use guaranteed restore points, the database must satisfy the following additional prerequisite: the COMPATIBLE initialization parameter must be set to 10.2.0 or greater
Note:
There are no special prerequisites to set before using normal restore points.
Using Normal and Guaranteed Restore Points
This section describes the various commands and monitoring capabilities you use with normal and guaranteed restore points.
Creating Normal and Guaranteed Restore Points
To create normal or guaranteed restore points, use the CREATE RESTORE POINT SQL statement, providing a name for the restore point and specifying whether it is to be a guaranteed restore point or a normal one (the default).
To create a restore point:
Connect SQL*Plus to a target database.
Run the CREATE RESTORE POINT statement.
The following example shows how to create a normal restore point in SQL*Plus:
SQL> CREATE RESTORE POINT before_upgrade;
This example shows how to create a guaranteed restore point:
SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;
See Also:
Oracle Database SQL Language Reference for reference information about the SQL CREATE RESTORE POINT statement
"Listing Restore Points" to learn how to list restore point
"Dropping Restore Points" to learn how to delete restore points
Listing Restore Points
You can use the LIST command to list either a specific restore point or all restore points known to the RMAN repository. The variations of the command are as follows:
LIST RESTORE POINT restore_point_name;
LIST RESTORE POINT ALL;
RMAN indicates the SCN and time of the restore point, the type of restore point, and the name of the restore point. The following example shows sample output:
RMAN> LIST RESTORE POINT ALL;
using target database control file instead of recovery catalog
SCN RSP Time Type Time Name
---------------- --------- ---------- --------- ----
341859 28-JUL-06 28-JUL-06 NORMAL_RS
343690 28-JUL-06 GUARANTEED 28-JUL-06 GUARANTEED_RS
To see a list of all currently defined restore points (normal and guaranteed), use the V$RESTORE_POINT control file view with the following query:
SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE
FROM V$RESTORE_POINT;
What happens if RVWR cannot write to disk?
A: It depends on the context where the write error occurs:
If there’s a Guaranteed Restore Point, the database crashes to ensure the restore point guarantee is not voided.
If there isn’t a Guaranteed Restore Point and it’s a primary database, the Flashback Mode will be automatically turned off for the database, which will continued to operate normally.
If there isn’t a Guaranteed Restore Point and it’s a standby database, the database will hang until the cause of the write failure is fixed.
When are the flashback logs deleted?
A: Flashback logs are managed by Oracle only. Oracle will try to keep as much Flashback logs as needed to satisfy the DB_FLASHBACK_RETENTION_TARGET parameter. However, if there’s space pressure in the Flash Recovery Area (FRA), flashback logs may be deleted to make room for other things, like backups and archived logs, for example.
If the fast recovery area has enough space, then a flashback log is created whenever necessary to satisfy the flashback retention target.
If a flashback log is old enough that it is no longer needed to satisfy the flashback retention target, then a flashback log is reused.
If the database must create a new flashback log and the fast recovery area is full or there is no disk space, then the oldest flashback log is reused instead.
If the fast recovery area is full, then an archived redo log that is reclaimable according to the FRA rules may be automatically deleted by the fast recovery area to make space for other files. In this case, any flashback logs that would require the use of that redo log file for the use of FLASHBACK DATABASE are also deleted.
No file in the fast recovery area is eligible for deletion if it is required to satisfy a guaranteed restore point. Thus, retention of flashback logs and other files required to satisfy the guaranteed restore point, in addition to files required to satisfy the backup retention policy, can cause the fast recovery area to fill completely.
