Using Flashback Database Technology and Restore Points
Oracle Flashback Database and restore points are related data protection features that enable you to rewind data back in time to correct any problems caused by
logical data corruption or user errors within a designated time window.
Restore points provide capabilities related to Flashback Database and other media recovery operations.
In particular, a guaranteed restore point created at a system change number (SCN) ensures that you can use Flashback Database to rewind the database to this SCN.
You can use restore points and Flashback Database independently or together.
About Flashback Database
==========================
Flashback Database enables you to return a database to its state at a time in the past.
Flashback Database is much faster than point-in-time recovery because it does not require restoring data files from backup and requires applying fewer changes from the archived redo logs.
Flashback Database uses its own logging mechanism, creating flashback logs and storing them in the fast recovery area. You can only use Flashback Database if flashback logs are available.
To take advantage of this feature, you must set up your database in advance to create flashback logs.
flashback logs => Oracle-generated logs used to perform flashback database operations. The database can only write flashback logs to the fast recovery area.
Flashback logs are written sequentially and are not archived. They cannot be backed up to disk.
fast recovery area => An disk location that you can use to store recovery-related files such as control file and online redo log copies, archived log files, flashback logs, and RMAN backups.
You can specify the disk quota, which is the maximum size of the fast recovery area. Formerly referred to as flash recovery area.
flashback retention target => A user-specified time or SCN that specifies how far into the past you want to be able to perform a flashback of the database.(db_flashback_retention_target)
From that time onwards,(Post Enabling Flashback) at regular intervals, the database copies images of each altered block in every data file into the flashback logs.
These block images can later be reused to reconstruct the data file contents for any moment at which logs were captured.
When you use Flashback Database to rewind a database to a past target time, the command determines which blocks changed after the target time and restores them from the flashback logs.
The database restores the version of each block that is immediately before the target time.
The database then uses redo logs to reapply changes that were made after these blocks were written to the flashback logs.
Redo logs on disk or tape must be available for the entire time period spanned by the flashback logs.
About Flashback Database Window
===============================
The range of SCNs for which there is currently enough flashback log data to support the FLASHBACK DATABASE command is called the flashback database window.
The flashback database window cannot extend further back than the earliest SCN in the available flashback logs.
You cannot back up flashback logs to locations outside the fast recovery area.
To increase the likelihood that enough flashback logs are retained to meet the flashback database window, you can increase the space in your fast recovery area.
Limitations of Flashback Database
==================================
Because Flashback Database works by undoing changes to the data files that exist at the moment when you run the command, it has certain limitations.
Following are the 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 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.
=> 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.
About Normal Restore Points
============================
Creating a normal restore point assigns a restore point name to an SCN or specific point in time.
Thus, a restore point functions as a bookmark or alias for this SCN. The control file stores the name of the restore point and the SCN.
If you use flashback features or point-in-time recovery, then you can use the name of the restore point instead of a time or SCN.
The following commands support this use of restore points:
=> The RECOVER DATABASE and FLASHBACK DATABASE commands in RMAN
=> The FLASHBACK TABLE statement in SQL
Normal restore points are lightweight. The control file can maintain a record of thousands of normal restore points with no significant effect on database performance.
Normal restore points eventually age out of the control file if not manually deleted, so they require no ongoing maintenance.
About Guaranteed Restore Points
==================================
Like a normal restore point, a guaranteed restore point serves as an alias for an SCN in recovery operations.
A principal difference is that guaranteed restore points never age out of the control file and must be explicitly dropped.
NOTE => A guaranteed restore point ensures that you can use Flashback Database to rewind a database to its state at the restore point SCN, even if the generation of flashback logs is disabled.
If flashback logging is enabled, then a guaranteed restore point enforces the retention of flashback logs required for Flashback Database to any SCN after the earliest guaranteed restore point.
Thus, if flashback logging is enabled, you can rewind the database to any SCN in the continuum rather than to a single SCN only.
Note:
If flashback logging is disabled, then you cannot FLASHBACK DATABASE directly to SCNs between the guaranteed restore points and the current time.
You can, however, flashback to the guaranteed restore point first and then recover to SCN's between the guaranteed restore point and current time.
About Logging for Flashback Database and Guaranteed Restore Points
===================================================================
Logging for Flashback Database and guaranteed restore points involves capturing images of data file blocks before changes are applied.
The chief differences between normal flashback logging and logging for guaranteed restore points are related to when blocks are
logged and whether the logs can be deleted in response to space pressure in the fast recovery area. These differences affect space usage for logs and database performance.
Your recoverability goals partially determine whether to enable logging for flashback database, or use guaranteed restore points, or both.
The implications in performance and in space usage for these features, separately and when used together, also factor into your decision.
Guaranteed Restore Points and Fast Recovery Area Space Usage
================================================================
Certain rules govern the usage of space in the fast recovery area.
The following rules govern creating, retaining, overwriting and deleting of flashback logs in the fast recovery area:
=> 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 the flashback log may be reused or deleted.
=> If the database must create a 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 fast recovery area rules may be automatically deleted by
the fast recovery area to make space for other files.
In this case, any flashback logs that require the use of that redo log file for the use of FLASHBACK DATABASE are also deleted.
Cases when Flashback Database Enabled and Disables with Guaranteed Retore Points
CASE 1=>
About Logging for Guaranteed Restore Points with Flashback Logging Disabled
Assume that you create a guaranteed restore point when logging for Flashback Database is disabled.
In this case, the first time a data file block is modified after the time of the guaranteed restore point, the database stores an image of the block before the modification in the flashback logs.
Thus, the flashback logs preserve the contents of every changed data block when the guaranteed restore point was created.
Later modifications to the same block do not cause the contents to be logged again unless another guaranteed restore point was created after the block was last modified or a subsequent flashback
database operation has restored the original contents of the block.
This method of logging has the following important consequences:
=> FLASHBACK DATABASE can re-create the data file contents at the time of a guaranteed restore point by using the block images.
=> For workloads that repeatedly modify the same data, disk space usage can be less than normal flashback logging. Less space is needed because each changed block is only logged once.
Assume that your primary goal is the ability to return your database to the time at which the guaranteed restore point was created.
In this case, it is usually more efficient to turn off flashback logging and use only guaranteed restore points.
For example, suppose that you are performing an application upgrade on a database host over a weekend.
You could create a guaranteed restore point at the start of the upgrade. If the upgrade fails, then reverse the changes with the FLASHBACK DATABASE command.
CASE 2=>
About Logging for Flashback Database with Guaranteed Restore Points Defined
If you enable Flashback Database and define one or more guaranteed restore points, then the database performs normal flashback logging.
In this case, the recovery area retains the flashback logs required to flash back to any arbitrary time between the present and the earliest currently defined guaranteed restore point.
Flashback logs are not deleted in response to space pressure if they are required to satisfy the guarantee.
Flashback logging causes some performance overhead. Depending upon the pattern of activity on your database, it can also cause significant space pressure in the fast recovery area.
Thus, you should monitor space used in the fast recovery area.
Prerequisites for Flashback Database and Restore Points
=======================================================
To ensure successful operation of Flashback Database and guaranteed restore points, you must first set some key database options.
Configure the following database settings before enabling Flashback Database:
=> Your 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.
=> For Oracle Real Application Clusters (Oracle RAC) databases, the fast recovery area must be in a clustered file system or in ASM.
=> For creating restore points in CDBs, the COMPATIBLE initialization parameter must be set to 12.1.0 or higher.
Creating Normal and Guaranteed Restore Points in non-CDBs
=======================================================
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:
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;
Listing Restore Points Using the LIST Command
==============================================
Use the LIST command to list either a specific restore point or all restore points known to the RMAN repository.
The variations of the LIST 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-APR-15 28-APR-15 NORMAL_RS
343690 28-APR-15 GUARANTEED 28-APR-15 GUARANTEED_RS
Listing Restore Points Using the V$RESTORE_POINT View
=========================================================
You can use the V$RESTORE_POINT control file view to obtain information about all currently-defined restore points (normal and guaranteed).
SELECT name, guarantee_flashback_database, pdb_restore_point, clean_pdb_restore_point, pdb_incarnation#, storage_sizeFROM v$restore_point;
Dropping Restore Points
======================
You can drop the restore point, using the DROP RESTORE POINT SQL*Plus statement.
SQL> DROP RESTORE POINT before_app_upgrade;
Restore point dropped.
The same statement is used to drop both normal and guaranteed restore points.
Using Flashback Database
=====================
To use flashback logging for a target database, you must enable Flashback Database.
Enabling Flashback Database
Use the ALTER DATABASE command to enable Flashback Database
To enable flashback logging:
=> Configure the recovery area as described and check with show parameter reco.
=> Ensure the database instance is open or mounted.
=> Optionally, set the DB_FLASHBACK_RETENTION_TARGET to the length of the desired flashback window in minutes:
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320 SCOPE=BOTH; # 3 days.
Enable the Flashback Database feature for the whole database:
=============================================================
ALTER DATABASE FLASHBACK ON;
Optionally, disable flashback logging for specific tablespaces.
By default, flashback logs are generated for all permanent tablespaces.
You can reduce overhead by disabling flashback logging for specific tablespaces as in the following example:
ALTER TABLESPACE tbs_3 FLASHBACK OFF;
You can re-enable flashback logging for a tablespace later with this command:
ALTER TABLESPACE tbs_3 FLASHBACK ON;
If you disable Flashback Database for a tablespace, then you must take its data files offline before running FLASHBACK DATABASE.
When you enable Flashback Database while the database is open, there is a very small chance the command may not be able to obtain the memory it needs.
If the command fails because of that reason, retry the command after a while or retry after a shutdown and restart of the instance.
Disabling Flashback Database Logging
===========================================
Use the ALTER DATABASE command to disable Flashback Database.
On a database instance that is either in mount or open state, issue the following command:
ALTER DATABASE FLASHBACK OFF;
