What are the Benefits of Flashback Database?
According to many studies and reports, Human Error accounts for 30-35% of data loss episodes. This makes Human Errors one of the biggest single causes of downtime.
With Flashback Database feature Oracle is trying to fight against user and operator errors in an extremely fast and effective way.
You can find more info about most common causes of data loss in the following sources:
For more info about the recovery speed advantages of Flashback Database, you can use the following source:
Oracle Flashback Technology, an Oracle article by Ron Weiss, Director of Product Management in Oracle's Database Kernel Development Group
Flashback Database provides:
I will try to discuss all of them in the sections below.
The Flashback Database is not just your database “rewind” button. It is a “Time Machine” for your Database data that is one single command away from you.
The Flashback Database Architecture
Flashback Database uses its own type of log files, called Flashback Database Log Files.
To support this mechanism, Oracle uses new background process called RVWR (Recovery Writer) and a new buffer in the SGA, called Flashback Buffer.
The Oracle database periodically logs before images of data blocks in the flashback buffer. The flashback buffer records images of all changed data blocks in the database. This means that every time a data block in the database is altered, the database writes a before image of this block to the flashback buffer. This before image can be used to reconstruct a datafile to the current point of time.
The maximum allowed memory for the flashback buffer is 16 MB. You 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.
You can see current size of the redo log buffer, fixed SGA and granule by querying the V$SGAINFO view.
You can query the V$SGASTAT view to display detailed information on the SGA and its structures.
To find current size of the flashback buffer, you can use the following query:
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:
For more info about the granule model in the SGA (available since Oracle9i), see Metalink Note: 148495.1: Oracle9i New Feature: Dynamic SGA
The flashback buffer size is at least two times bigger than the log buffer size. This assertion can be found in OCP Oracle Database 10g : New Features for Administrators by Sam Alapati
Although flashback buffer size is expected to be at least two times bigger than log buffer size, its real size can be smaller. In tested 10g R2 environment, flashback buffer has around two times smaller size as the redo log buffer.
RVWR writes periodically flashback buffer contents to flashback database logs. It is an asynchronous process and you don’t have control over it. All available sources are saying that RVWR writes periodically to flashback logs. The explanation for this behavior is that Oracle is trying to reduce the I/O and CPU overhead that can be an issue in many production environments.
The RVWR writing mechanism and its behavior needs more investigation that will not be discussed here. It can be seen that it is controlled by few hidden parameters in a similar way like writing to redo log files – depending of generated flashback redo and time interval.
Flashback log files can be created only under the Flash Recovery Area (that must be configured before enabling the Flashback Database functionality). RVWR creates flashback log files into a directory named “FLASHBACK” under FRA. The size of every generated flashback log file is again under Oracle’s control. According to current Oracle environment – during normal database activity flashback log files have size of 8200192 bytes. It is very close value to the current redo log buffer size. The size of a generated flashback log file can differs during shutdown and startup database activities. Flashback log file sizes can differ during high intensive write activity as well.
Flashback log files can be written only under FRA (Flash Recovery Area). FRA is closely related and is built on top of Oracle Managed Files (OMF). OMF is a service that automates naming, location, creation and deletion of database files. By using OMF and FRA, Oracle manages easily flashback log files. They are created with automatically generated names with extension .FLB. For instance, this is the name of one flashback log file: O1_MF_26ZYS69S_.FLB
By its nature flashback logs are similar to redo log files. LGWR writes contents of the redo log buffer to online redo log files, RVWR writes contents of the flashback buffer to flashback database log files. Redo log files contain all changes that are performed in the database, that data is needed in case of media or instance recovery. Flashback log files contain only changes that are needed in case of flashback operation. The main differences between redo log files and flashback log files are:
There is a new record section within the control file header that is named FLASHBACK LOGFILE RECORDS. It is similar to LOG FILE RECORDS section and contains info about the lowest and highest SCN contained in every particular flashback database log file
When you perform a flashback operation, Oracle needs all flashback logs from now on to the desired time. They will be applied consecutively starting from the newest to the oldest.
For instance, if you want to flashback the database to SCN 4123376440, Oracle will read flsahback logfile section in control file and will check for the availability of all needed flashback log files. The last needed flashback log should be this with Low scn and High scn values between the desired SCN 4123376440.
In current environment this is the file with name: O1_MF_26YSTQ6S_.FLB and with values of:
The reason for this: Flashback log files contain information about before-images of data blocks, related to some SCN (System Change Number). When you perform flashback operation to SCN 4123376440, Oracle cannot apply all needed flashback logs and to complete successfully the operation because it applying before-images of data. Oracle needs to restore each data block copy (by applying flashback log files) to its state at a closest possible point in time before SCN 4123376440. This will guarantee that the subsequent “redo apply” operation will forward the database to SCN 4123376440 and the database will be in consistent state. After applying flashback logs, Oracle will perform a forward operation by applying all needed archive log files (in this case redo information from the file: ARC00097_0587681349.001) that will forward the database state to the desired SCN.
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 you 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.
A short explanation of this issue can be found in the documentation:
Oracle Database Backup and Recovery Basics -
10g Release 2 (10.2) - Chapter 5.1 - Restore Points and Flashback Database: Concepts
There is another source that is trying to explain this behavior in a comprehensible way:
OCP Oracle Database 10g: New Features for Administrators – Chapter 9: Flashback Enhancements, by Sam Alapati
Flashback logs are not independent. They can be used only with the redo data that contains database changes around the desired SCN. This means that if you want to have working flashback window (and to be able to restore the database to any point in time within this window) you need to ensure the availability of redo logs as well.
If you are familiar with this information then you will be able to work in a better way with this feature and to ensure that it will help you to perform faster recovery without unexpected problems.
Availability within Oracle’s Editions
Oracle Flashback Database feature is available only in Oracle Enterprise and Oracle Personal Editions.
For more info, see Metalink Note: 271886.1: Differences Between Different Editions of Oracle Database 10G
Thanks.
According to many studies and reports, Human Error accounts for 30-35% of data loss episodes. This makes Human Errors one of the biggest single causes of downtime.
With Flashback Database feature Oracle is trying to fight against user and operator errors in an extremely fast and effective way.
You can find more info about most common causes of data loss in the following sources:
- The Data Recovery Solution, a white paper by ONTRACK Data Recovery, Inc.
- The Business Case for Disaster Recovery Planning: Calculating the Cost of Downtime, a white paper by Iron Mountain
- Data Recovery Report, by Ontrack Japan
- The Cost of Lost Data, an article by David M. Smith, Ph.D.
- Critical Data Protection, a white paper by TIDF, LLC
For more info about the recovery speed advantages of Flashback Database, you can use the following source:
Oracle Flashback Technology, an Oracle article by Ron Weiss, Director of Product Management in Oracle's Database Kernel Development Group
Flashback Database provides:
- Very effective way to recover from complex human errors
- Faster database point-in-time recovery
- Simplified management and administration
- Little performance overhead
I will try to discuss all of them in the sections below.
The Flashback Database is not just your database “rewind” button. It is a “Time Machine” for your Database data that is one single command away from you.
The Flashback Database Architecture
Flashback Database uses its own type of log files, called Flashback Database Log Files.
To support this mechanism, Oracle uses new background process called RVWR (Recovery Writer) and a new buffer in the SGA, called Flashback Buffer.
The Oracle database periodically logs before images of data blocks in the flashback buffer. The flashback buffer records images of all changed data blocks in the database. This means that every time a data block in the database is altered, the database writes a before image of this block to the flashback buffer. This before image can be used to reconstruct a datafile to the current point of time.
The maximum allowed memory for the flashback buffer is 16 MB. You 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.
You can see current size of the redo log buffer, fixed SGA and granule by querying the V$SGAINFO view.
You can query the V$SGASTAT view to display detailed information on the SGA and its structures.
To find current size of the flashback buffer, you can use the following query:
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=5392For more info about the sizing restrictions of log buffer in 10g R2, see Metalink Note: 351857.1: The Log_buffer Cannot be Changed In 10g R2
For more info about the granule model in the SGA (available since Oracle9i), see Metalink Note: 148495.1: Oracle9i New Feature: Dynamic SGA
The flashback buffer size is at least two times bigger than the log buffer size. This assertion can be found in OCP Oracle Database 10g : New Features for Administrators by Sam Alapati
Although flashback buffer size is expected to be at least two times bigger than log buffer size, its real size can be smaller. In tested 10g R2 environment, flashback buffer has around two times smaller size as the redo log buffer.
Granule Size: 4194304This rule is mentioned indirectly in the Oracle documentation: Oracle Database Backup and Recovery Basics - 10g Release 2 (10.2) - Chapter 5.3 Setup and Maintenance for Oracle Flashback Database - Performance Tuning for Flashback Database:
Fixed SGA Size: 1289832
Log Buffer: 7098368
Flashback Buffer (flashback generation buff): 3981204
For large, production databases, set the init.ora parameter LOG_BUFFER to be at least 8MB. This makes sure the database allocates maximum memory (typically 16MB) for writing flashback database logs.The RVWR background process has responsibility to write the contents of flashback buffer to flashback log files. This process is started automatically when flashback database feature is enabled.
RVWR writes periodically flashback buffer contents to flashback database logs. It is an asynchronous process and you don’t have control over it. All available sources are saying that RVWR writes periodically to flashback logs. The explanation for this behavior is that Oracle is trying to reduce the I/O and CPU overhead that can be an issue in many production environments.
The RVWR writing mechanism and its behavior needs more investigation that will not be discussed here. It can be seen that it is controlled by few hidden parameters in a similar way like writing to redo log files – depending of generated flashback redo and time interval.
Flashback log files can be created only under the Flash Recovery Area (that must be configured before enabling the Flashback Database functionality). RVWR creates flashback log files into a directory named “FLASHBACK” under FRA. The size of every generated flashback log file is again under Oracle’s control. According to current Oracle environment – during normal database activity flashback log files have size of 8200192 bytes. It is very close value to the current redo log buffer size. The size of a generated flashback log file can differs during shutdown and startup database activities. Flashback log file sizes can differ during high intensive write activity as well.
Flashback log files can be written only under FRA (Flash Recovery Area). FRA is closely related and is built on top of Oracle Managed Files (OMF). OMF is a service that automates naming, location, creation and deletion of database files. By using OMF and FRA, Oracle manages easily flashback log files. They are created with automatically generated names with extension .FLB. For instance, this is the name of one flashback log file: O1_MF_26ZYS69S_.FLB
By its nature flashback logs are similar to redo log files. LGWR writes contents of the redo log buffer to online redo log files, RVWR writes contents of the flashback buffer to flashback database log files. Redo log files contain all changes that are performed in the database, that data is needed in case of media or instance recovery. Flashback log files contain only changes that are needed in case of flashback operation. The main differences between redo log files and flashback log files are:
- 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
- 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
There is a new record section within the control file header that is named FLASHBACK LOGFILE RECORDS. It is similar to LOG FILE RECORDS section and contains info about the lowest and highest SCN contained in every particular flashback database log file***************************************************************************What does a Flashback Database operation?
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
When you perform a flashback operation, Oracle needs all flashback logs from now on to the desired time. They will be applied consecutively starting from the newest to the oldest.
For instance, if you want to flashback the database to SCN 4123376440, Oracle will read flsahback logfile section in control file and will check for the availability of all needed flashback log files. The last needed flashback log should be this with Low scn and High scn values between the desired SCN 4123376440.
In current environment this is the file with name: O1_MF_26YSTQ6S_.FLB and with values of:
Low SCN: 4123374373Note: If you want to perform successfully a flashback operation you will always need to have available at least one archived (or online redo) log file. This is a particular file that contains redo log information about changes around the desired flashback point in time (SCN 4123376440). In this case, this is the archived redo log with name: ARC00097_0587681349.001 that has values of:
High SCN: 4123376446
First change#: 4123361850The flashback operation will not succeed without this particular archived redo log.
Next change#: 4123380675
The reason for this: Flashback log files contain information about before-images of data blocks, related to some SCN (System Change Number). When you perform flashback operation to SCN 4123376440, Oracle cannot apply all needed flashback logs and to complete successfully the operation because it applying before-images of data. Oracle needs to restore each data block copy (by applying flashback log files) to its state at a closest possible point in time before SCN 4123376440. This will guarantee that the subsequent “redo apply” operation will forward the database to SCN 4123376440 and the database will be in consistent state. After applying flashback logs, Oracle will perform a forward operation by applying all needed archive log files (in this case redo information from the file: ARC00097_0587681349.001) that will forward the database state to the desired SCN.
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 you 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.
A short explanation of this issue can be found in the documentation:
Oracle Database Backup and Recovery Basics -
10g Release 2 (10.2) - Chapter 5.1 - Restore Points and Flashback Database: Concepts
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.
Note: Redo logs must be available for the entire time period spanned by the flashback logs, whether on tape or on disk. (In practice, however, redo logs are generally needed much longer than the flashback retention target to support point-in-time recovery.)There is a lack of information about this specific behavior of the Flashback Database feature. The above quote is the only one place in Oracle documentation where it is mentioned.
There is another source that is trying to explain this behavior in a comprehensible way:
OCP Oracle Database 10g: New Features for Administrators – Chapter 9: Flashback Enhancements, by Sam Alapati
Flashback logs are not independent. They can be used only with the redo data that contains database changes around the desired SCN. This means that if you want to have working flashback window (and to be able to restore the database to any point in time within this window) you need to ensure the availability of redo logs as well.
If you are familiar with this information then you will be able to work in a better way with this feature and to ensure that it will help you to perform faster recovery without unexpected problems.
Availability within Oracle’s Editions
Oracle Flashback Database feature is available only in Oracle Enterprise and Oracle Personal Editions.
For more info, see Metalink Note: 271886.1: Differences Between Different Editions of Oracle Database 10G
Thanks.
No comments:
Post a Comment