- Very effective way to recover from complex human errors.
- Faster database point-in-time recovery.
- Simplified management and administration .
- Little performance overhead .
- It provides a lot of benefits and almost no disadvantages.
The Flashback Database Architecture :
The maximum allowed memory for the flashback buffer is 16 MB. We don’t have direct control on its size. The flashback buffer size depends on the size of the current redo log buffer that is controlled by Oracle. Starting at 10g R2, the log buffer size cannot be controlled manually by setting the initialization parameter LOG_BUFFER.
In 10G R2, Oracle combines fixed SGA area and redo buffer together. If there is a free space after Oracle puts the combined buffers into a granule, that space is added to the redo buffer. The sizing of the redo log buffer is fully controlled by Oracle. According to SGA and its atomic sizing by granules, Oracle will calculate automatically the size of the log buffer depending of the current granule size. For smaller SGA size and 4 MB granules, it is possible redo log buffer size + fixed SGA size to be multiple of the granule size. For SGAs bigger than 128 MB, the granule size is 16 MB. We can see current size of the redo log buffer, fixed SGA and granule by querying the V$SGAINFO view , and can query the V$SGASTAT view to display detailed information on the SGA and its structures.
SQL> SELECT * FROM v$sgastat WHERE NAME = 'flashback generation buff';
There is no official information from Oracle that confirms the relation between 'flashback generation buff' structure in SGA and the real flashback buffer structure. This is only a suggestion. A similar message message is written to the alertSID.log file during opening of the database .
Allocated 3981204 bytes in shared pool for flashback generation buffer Starting background process RVWR RVWR started with pid=16, OS id=5392 .
- Flashback log files are never archived - they are reused in a circular manner.
- Redo log files are used to forward changes in case of recovery while flashback log files are used to backward changes in case of flashback operation.
- Flashback log files can be compared with UNDO data (contained in UNDO tablespaces) as well. While UNDO data contains changes at the transaction level, flashback log files contain UNDO data at the data block level. While UNDO tablespace doesn’t record all operations performed on the database (for instance, DDL operations), flashback log files record that data as well. In few words, flashback log files contain the UNDO data for our database.
- UNDO data doesn’t contain all changes that are performed in the database while flashback logs contain all altered blocks in the database .
- UNDO data is used to backward changes at the transaction level while flashback logs are used to backward changes at the database level .
FLASHBACK LOGFILE RECORDS
(size = 84, compat size = 84, section max = 2048, section in-use = 136,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 139, numrecs = 2048)
FLASHBACK LOG FILE #1:
(name #4) E:\ORACLE\FLASH_RECOVERY_AREA\ORCL102\FLASHBACK\O1_MF_26YR1CQ4_.FLB
Thread 1 flashback log links: forward: 2 backward: 26
size: 1000 seq: 1 bsz: 8192 nab: 0x3e9 flg: 0x0 magic: 3 dup: 1
Low scn: 0x0000.f5c5a505 05/20/2006 21:30:04
High scn: 0x0000.f5c5b325 05/20/2006 22:00:38
What does a Flashback Database operation ?
High SCN : 4123376446
Next change#: 4123380675
Oracle cannot start applying redo log files before to be sure that all data blocks are returned to their state before the desired point in time. So, if desired restore point of time is 10:00 AM and the oldest restored data block is from 09:47 AM then we will need all archived log files that contain redo data for the time interval between 09:47 AM and 10:00 AM. Without that redo data, the flashback operation cannot succeed. When a database is restored to its state at some past target time using Flashback Database, each block changed since that time is restored from the copy of the block in the flashback logs most immediately prior to the desired target time. The redo log is then used to re-apply changes since the time that block was copied to the flashback logs.
Rules for Retention and Deletion of Flashback Logs :
The following rules govern the flash recovery area's creation, retention, overwriting and deletion of flashback logs:
- A flashback log is created whenever necessary to satisfy the flashback retention target, as long as there is enough space in the flash recovery area.
- A flashback log can be reused, once it is old enough that it is no longer needed to satisfy the flashback retention target.
- If the database needs to create a new flashback log and the flash recovery area is full or there is no disk space, then the oldest flashback log is reused instead.
- If the flash recovery area is full, then an archived redo log may be automatically deleted by the flash recovery area to make space for other files. In such a case, any flashback logs that would require the use of that redo log file for the use of FLASHBACK DATABASE are also deleted.
- Since Flashback Database works by undoing changes to the datafiles that exist at the moment that we run the command, it has the following limitations:Flashback Database can only undo changes to a datafile made by an Oracle database. It cannot be used to repair media failures, or to recover from accidental deletion of datafiles.
- we cannot use Flashback Database to undo a shrink datafile operation.
- If the database control file is restored from backup or re-created, all accumulated flashback log information is discarded. We cannot use FLASHBACK DATABASE to return to a point in time before the restore or re-creation of a control file.
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 datafiles immediately after any NOLOGGING operation to ensure recoverability to points in time after the operation. If we expect to use Flashback Database to return to a point in time during an operation such as a direct-path INSERT, consider performing the operation in LOGGING mode.
Finally few important point to be noted :
- The Flashback Database should be part of our Backup & Recovery Strategy but it not supersedes the normal physical backup & recovery strategy. It is only an additional protection of our database data.
- The Flashback Database can be used to flashes back a database to its state to any point in time into the flashback window, only if all flashback logs and their related archived redo logs for the spanned time period are physically available and accessible.
- Always ensure that archived redo logs covering the flashback window are available on either the tape or disk.
- We cannot perform flashback database operation if we have media failure. In this case we must use the traditional database point-in-time media recovery method.
- Always write down the current SCN or/and create a restore point (10g R2) before any significant change over our database: applying of patches, running of batch jobs that can can corrupt the data, etc. As we know: The most common cause for downtime is change.
- Always write down the current SCN or/and create a restore point (10g R2) before to start a flashback operation .
- Flashback database is the only one flashback operation that can be performed to undone result of a TRUNCATE command (FLASHBACK DROP, FLASHBACK TABLE, or FLASHBACK QUERY cannot be used for this).
- Dropping of tablespace cannot be reversed with Flashback Database. After such an operation, the flashback database window begins at the time immediately following that operation.
- Shrink a datafile cannot be reversed with Flashback Database. After such an operation, the flashback database window begins at the time immediately following that operation.
- Resizing of datafile cannot be reversed with Flashback Database. After such an operation, the flashback database window begins at the time immediately following that operation. If we need to perform flashback operation in this time period, we must offline this datafile before performing of flashback operation.
- Recreating or restoring of control file prevents using of Flashback Database before this point of time.
- We can flashback database to a point in time before a RESETLOGS operation. This feature is available from 10g R2 because the flashback log files are not deleted after RESETLOGS operation. We cannot do this in 10g R1 because old flashback logs are deleted immediately after an RESETLOGS operation.
- Don’t exclude the SYSTEM tablespace from flashback logging. Otherwise we will not be able to flashback the database.
- The DB_FLASHBACK_RETENTION_TARGET parameter is a TARGET parameter. It doesn’t guarantee the flashback database window. Our proper configuration of the Flashback Database should guarantee it.
- Monitor regularly the size of the FRA and generated flashback logs to ensure that there is no space pressure and the flashback log data is within the desired flashback window
For Flashback Configuration and examples .Click Here
Reference : http://docs.oracle.com/cd/B19306_01/backup.102/b14192/rpfbdb003.htm