SAP Note 966117 Note Language: English

Oracle Flashback Database technology

Version: 11 Validity:
Valid Since 19.07.2011

Summary
Symptom Oracle Flashback Database
This note describes functions, configuration and the use of Oracle Flashback Database in the SAP environment. This note is valid for Oracle Releases 10.2 and 11.2.

New features with Release 11.2

o Activating and deactivating FLASHBACK with an open database (the database must be mounted in Release 10.2) SQL> ALTER DATABASE FLASHBACK ON; SQL> ALTER DATABASE FLASHBACK OFF; Creating guaranteed restore points with an open database (the database must be mounted in Release 10.2) SQL> CREATE RESTORE POINT "<NAME>" GUARANTEE FLASHBACK DATABASE;

Other terms
DB_FLASHBACK_RETENTION_TARGET V$FLASHBACK_DATABASE_LOG V$FLASHBACK_DATABASE_STAT V$RESTORE_POINT V$DATABASE Terminology SCN = System Change Number PITR = Point-in-time-Recovery PIT = Point-in-time Flashback Logging = Writing Flashback logs Flashback Window = Time interval for Flashback Database

Reason and Prerequisites Flashback Database and data inconsistency in a system landscape
Note that a temporal resetting of a database has major consequences for the data consistency in a system landscape. Therefore, a recovery concept should consider that logical errors in a production system should be corrected by other means if possible. For more information, see SAP Notes 434645 and 434647.

Fast Recovery Area

17.10.2011 Page 1 of 12

SAP Note 966117 -

Oracle Flashback Database technology

Also note that the Fast Recovery Area (as described in Note 966073) should be in a storage system that is as fast as possible and that has a fast I/O. If the Fast Recovery Area is in an I/O system that is too slow, Flashback Logging may lead to performance problems (wait event: flashback buf free by RVWR).

Solution Oracle Flashback Database

Oracle Flashback Database is a new Oracle feature as of Oracle Database Release 10g. Flashback Database is a feature module of the entire Oracle Flashback technology. Flashback Database can be compared to the rewind it allows a time reset of the database without a all database files. The duration of the "rewind" Flashback Database is independent of the size of button on a tape recorder: time-consuming reload of of the database using the database.

When you consider the status of the database after a Flashback Database operation, the result is identical to a Point-In-Time-Recovery (PITR) of the entire database. A normal Point-in-Time-Recovery consists of two steps: 1.) the reload of an entire database backup and 2.) the import of archive logs/recovery up until the required point of time. With a Flashback Database operation, however, the last changes starting from the current state of the database are reversed. Compared to a normal PITR, the Flashback Database operation is significantly faster and easier, and therefore provides a good alternative to the normal PITR procedure.

Usage scenarios for Flashback Database

It may be required to revert the database to an earlier state if a logical data corruption occurred due to an application error, user error, or administrator error. In this case, activate normal Flashback Logging. Note the following: Resetting a database has major consequences for the data consistency in a system landscape. Therefore, a recovery concept must take into account that logical errors in a production system should be solved by different measures. For more information about this, see Notes 434645 and 434647. Flashback Database also lends itself for cases where you anticipate in advance that the database may have to be reset. For example: o o SAP upgrade Database upgrade
Page 2 of 12

17.10.2011

SAP Note 966117 -

Oracle Flashback Database technology

Real Application Testing

For such application cases, you define one (or more) guaranteed restore points, but no normal Flashback Logging.

Recommendations
Depending on the case (see above), you should either activate normal Flashback Logging only (ALTER DATABASE FLASHBACK ON), or create guaranteed restore points only (CREATE RESTORE POINT <NAME> GUARANTEE FLASHBACK DATABASE). However, due to space restrictions and for performance reasons, both variants should not be active at the same time.

Normal PITR - Flashback Database

In contrast to a normal PITR, you do not need to reload data prior to a backup with Flashback Database. The duration of a PITR mainly depends on the time it takes to reload all database files from the backup, and on the duration of the subsequent recovery using Archive Logs. With Flashback Database, the duration is proportional to the time to which the database is reset to. The effort is proportional to the amount of changes that were made during this time that now need to be reversed. A rule of thumb is therefore that it takes approximately the same time to undo the changes in the database by reversing the time than it took to make those changes in the first place (for example, a 1 h Flashback Database takes approx. 1 h). Another advantage of Flashback Database in contrast to the normal PITR is that you can use Flashback Database to check if you have reset the database to the correct point of time. If you did not select the correct point of time, you can repeat Flashback Database with earlier or later points of time until the correct point of time has been found. With a PITR, however, you must execute a new PITR in such cases, combined with another complete reload of the backup.

Architecture, function, characteristics of Flashback Database

Flashback Database is based on special log files, the so-called Flashback Logs. When Flashback Logging is active, Flashback Logs of the RVWR Oracle background process are exclusively written to the Flash Recovery Area during operation. There, the logs are automatically administrated by Oracle. Flashback Logging is deactivated by default. As soon as Flashback Logging is active, Oracle regularly writes all blocks of database files that were changed to Flashback Logs. With a Flashback Database, the data blocks that were changed since the time set for the Flashback are read from the Flashback Logs and written back to the database file. After that, the changes that occurred in the database
17.10.2011 Page 3 of 12

SAP Note 966117 -

Oracle Flashback Database technology

between the time the block was copied to the Flashback Log and the required recovery target time are also implemented using Archive Logs. Flashback Database therefore not only requires Flashback Logs, but also the relevant Archive Logs for the desired period of time (flashback retention target). Therefore, the database must run in ARCHIVELOG mode (this is always the case for SAP databases). If the RVWR background process detects problems when writing Flashback Logs, the following occurs: If a Flashback Log cannot be written correctly for a guaranteed restore point (see below), the Oracle instance terminates. This behavior becomes clear when you consider the purpose of guaranteed restore points and the possible usage scenarios. For Flashback Logging activated in the usual way, an I/O problem of the RVWR results in the deactivation of Flashback Logging, but the instance keeps running (exception: standby database). During FLASHBACK DATABASE, only the database files are returned to an earlier state, but not the auxiliary files such as Oracle password files, Oracle profile files, Oracle Wallet files, or Oracle control files. Flashback Logs are not backed up. Therefore, you do not need to adjust the database backup strategy to also backup Flashback Logs. Flashback Logs are deleted automatically from the Flash Recovery Area by the Oracle server as soon as they are no longer needed or if space is required in the Flash Recovery Area for other, more important files.

Usage in the SAP environment - support by BR*Tools

Prerequisites for using Flashback Database in the SAP environment are: o o o o o COMPATIBLE to 10.2.0 and higher A Flash Recovery Area is configured (see Note 966073) The database runs in ARCHIVELOG mode. To execute Flashback Database, Flashback Logging must be activated. SAP BR*Tools Release 7.10 Patchlevel 6 As of this release, the SAP BR*Tools (BRRESTORE, BRREOVER) support the efficient 'Flashback Database' procedure in addition to the regular PITR procedure. The SAP BR*Tools require that a Flash Recovery Area is configured (see Note 966073). Further information about the support of FLASHBACK DATABASE in SAP BR*Tools is available in Note 1125923 (brspace -f mfback).

Cost of Flashback Logging and effects on performance

Flashback Logging generates an additional 2 % of I/O load. To keep the additional I/O load generated by Flashback Database as low as
17.10.2011 Page 4 of 12

SAP Note 966117 -

Oracle Flashback Database technology

possible, changed blocks from the Oracle buffer cache are only written to the Flashback Logs in certain, fixed intervals. Therefore, not every version of a data block is written to the Flashback Logs. (See below: Variants of Flashback Logging.) Recommendations for Flash Recovery Area (see also Note 966073): o For the Flash Recovery Area, a fast file system should be used, if possible, without operating system caching File system with high throughput

To monitor the system performance, the views V$FLASHBACK_DATABASE_STAT and V$SYSSTAT are available.

Restrictions of Flashback Database

Note the following when you use Flashback Database: o o o Flashback Database is NOT a substitute for database backups! You cannot use Flashback Database to perform media recovery. To use Flashback Database, the database must be physically intact. If database files are corrupted or missing, Flashback Database cannot revert the database to an intact state. Flashback Database can only undo changes in Oracle database files. Profile files (spfile, init<SID>.ora), password files, Net Services configuration files (sqlnet.ora etc.) are not reset by Flashback Database. Certain database operations cannot be undone using Flashback Database. These operations are, for example: o Datafile Shrink Drop Tablespace Drop Datafile

After such operations, the Flashback Database time window starts again from the beginning.

If the database is to be reset using Flashback Database to a point of time at which a NOLOGGING operation was running, the affected data blocks will probably be inconsistent or corrupt. For this reason, this should be avoided. You can achieve this by replacing the NOLOGGING operation with a LOGGING operation or by triggering a full backup or incremental backup of the affected data files directly after a NOLOGGING operation. The time span specified in the parameter DB_FLASHBACK_RETENTION_TARGET is to be understood as target. Oracle cannot guarantee this time span (exception: guaranteed restore points, see below). Only if enough space is available for the Flashback logs can the required Flashback retention (retention period of Flashback logs) be adhered to.

17.10.2011

Page 5 of

12

SAP Note 966117 -

Oracle Flashback Database technology

Comparison between normal Flashback Logging and guaranteed restore points

There are two different variants of Flashback Logging: o o 'Normal' Flashback logging and Flashback Logging for a guaranteed restore point (GRP).

Both variants are based on Flashback Logs and allow the use of FLASHBACK DATABASE to revert the database to an earlier state. Normal Flashback Logging is activated explicitly by activating the FLASHBACK mode. Flashback Logging for a guaranteed restore point is automatically or implicitly activated when a guaranteed restore point is created. The difference between those variants is, aside from the way Flashback logging is activated, in the possible points of time to which the database can be reverted using FLASHBACK DATABASE. o With normal Flashback Logging, you can reset the database to any point of time (that is covered by the Flashback Logs). The SCN area covered by the Flashback Logs is called a Flashback Database time window. This timeframe should cover at least the defined Flashback retention. If sufficient space is not available in the Flash Recovery Area, the oldest Flashback Logs are overwritten. The desired Flashback retention is ignored. The concept of guaranteed restore points offers the option to reset the database to exactly the same state it was in at the time of the guaranteed restore point (but not at any other earlier or later point in time). Guaranteed restore points are therefore particularly suitable for situations prior to larger and critical database operations (for example, an SAP upgrade or an Oracle patchset installation). If this operation fails, you can use FLASHBACK DATABASE to reset the database (even repeatedly) to the point of time at the beginning of the operation without having to reload a database backup.

Normal Flashback Logging and guaranteed restore points can be used independently of each other. However, we recommend not to activate both variants at the same time (see below: Variants of Flashback Logging).

Variants of Flashback Logging

Whether Flashback Logging has been activated for a guaranteed restore point or normal Flashback Logging has been activated differs with regard to: o o o IO behavior Space usage for Flashback Logs in the Flash Recovery area Space management of Flashback Logs

With normal Flashback Logging, changed blocks are written to the Flashback Logs at fixed intervals. If a block is changed at different points of time, it is saved several times in the Flashback Log.
17.10.2011 Page 6 of 12

SAP Note 966117 -

Oracle Flashback Database technology

If a guaranteed restore point has been defined and normal Flashback Logging has not additionally been activated, the block is written to the Flashback Log when it is changed the first time. If the block is changed, this changed block is not saved again. This way, you can reset the database only to the guaranteed restore point using the block information saved in the Flashback Logs, but not to any point in time before or after. Each block that was changed is saved exactly once in a Flashback Log. Because every changed block is only written to the Flashback Log once, Flashback Logging for guaranteed restore points is less time-consuming or extensive (less I/O) than normal Flashback Logging. You can therefore run a guaranteed restore point for several days or weeks without any concerns regarding space requirements for Flashback Logs (even if the Flashback Log are not deleted). Due to the reduced I/O, the effect of Flashback Logging for guaranteed restore points on performance is less when compared to normal Flashback Logging. If normal Flashback Logging has been activated and if several guaranteed restore points have also been defined, the database uses normal Flashback Logging. However, Flashback Logs cannot be deleted as of the first GRP. For this reason, you must monitor the free space in the Flash Recovery Area closely, to prevent the database from terminating or hanging due to space problems in the Flash Recovery Area. We therefore do not recommend to use normal Flashback logging and GRP at the same time. With regard to the space usage and the automatic administration of Flashback Logs in the Flash Recovery Area, the following differences exist: Flashback Logs that are written for a GRP are not deleted automatically. They are required to guarantee the reset of the database to the GRP. They are only deleted together with the relevant GRP. Therefore, a GRP should be deleted if it is no longer required. With normal Flashback Logging, Flashback Logs are overwritten after the specified Flashback retention target. The Flashback retention is defined by the parameter DB_FLASHBACK_RETENTION_TARGET. If there is not enough space in the Flash Recovery Area to save the Flashback Logs for the required Flashback retention, the oldest Flashback Logs are overwritten first. The desired Flashback retention is not guaranteed.

Restore Points
You use a restore point to define a restart point at which you want to reset the database. A restore point acts as a bookmark and marks a certain point of time. You can define a restore point, for example, before a critical or unstable operation. If the operation actually fails and you want to reset the database to the status before this operation, you only have to execute a Flashback Database with the restore point define previously. There are two types of restore points: Normal restore points and guaranteed restore points.

Normal restore points and guaranteed restore points

A normal restore point (NRP) is only the descriptive name for a certain
17.10.2011 Page 7 of 12

SAP Note 966117 SCN.

Oracle Flashback Database technology

Name and relevant SCN are saved in the control file.

You can use normal restore points with the following commands: - RECOVER DATABASE - FLASHBACK DATABASE Prerequisites to create an NRP: none Guaranteed restore points: (GRP) guarantee the option to execute a Flashback Database to the SCN or the point of time of the GRP, even if normal Flashback Logging has not been activated in the database. If Flashback Logging is active, all Flashback Logs from the oldest GRP onwards are not deleted, and a possible Flashback Database back to any point of time between the oldest GRP and now is always guaranteed. Here, the following restrictions apply. Certain database operations cannot be undone using Flashback Database (see above). - Datafile Shrink - Drop Tablespace Prerequisites to create a GRP: o o o o COMPATIBLE to 10.2.0 and higher A Flash Recovery Area is configured (see Note 966073) The database runs in ARCHIVELOG mode. If normal Flashback Logging has not been activated, the database must have mount status when the first GRP is defined.

Administration
The following administrative tasks belong to Flashback Database: o o o o o Create the Flash Recovery Area. See Note 966073. Activate/deactivate normal Flashback Logging (see below) Create and delete GRPs (see below) Monitor performance (see below, flashback buf free by RVWR) Monitor free space in the Flash Recovery Area The size of the Flash Recovery Area is determined from the monitoring result (see below).

Activate normal Flashback Logging

SQL> SQL> SQL> SQL> shutdown immediate startup mount ALTER DATABASE FLASHBACK ON; ALTER DATABASE OPEN;

BRSPACE Action: brspace -fbon

17.10.2011

Page 8 of

12

SAP Note 966117 -

Oracle Flashback Database technology

Deactivate: SQL> ALTER DATABASE FLASHBACK OFF; BRSPACE Action: brspace -fboff The following query determines whether Flashback Logging is active: SQL> SELECT FLASHBACK_ON FROM V$DATABASE;

Define Flashback retention

The parameter DB_FLASHBACK_RETENTION_TARGET specifies (in mins) how long Flashback Logs are to be retained in the Flash Recovery Area. Oracle Default: 1440 (=24h) Recommendation: Depending on your requirements, not below 60 mins. For example: Flashback retention = 5 hours SQL> alter system set db_flashback_retention_target=300;

Estimating the memory requirement for Flashback Logs

The memory requirement for Flashback Logs (normal Flashback Logging) depends on two factors: 1. DB_FLASHBACK_RETENTION_TARGET 2. Change activities in the database. To estimate the memory requirement for Flashback Logs, use the following query: SQL> SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG; For the result of this query to be correct, Flashback Logging must be activated, Flashback retention must be defined, and the database should have run with normal, typical load for a while.

Monitoring freespace in the Flash Recovery Area

See Note 966073: V$RECOVERY_FILE_DEST, V$FLASH_RECOVERY_AREA_USAGE

V$RESTORE_POINT
How much space is used by Flashback Logs for each GRP? SQL> SELECT NAME, SCN, STORAGE_SIZE FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE = 'YES'; How much space do all GRP Flashback Logs use? SQL> SELECT SUM(STORAGE_SIZE) FROM V$RESTORE_POINT WHERE GUARANTEE_FLASHBACK_DATABASE = 'YES';

The Flashback time window/Flashback Database window

The View V$FLASHBACK_DATABASE_LOG provides an overview over the current Flashback Logging status. Flashback Database can only go back as far as the oldest SCN in the Flashback Logs. Since Flashback Logs cannot be saved outside the Flash Recovery Area, the only option you have to ensure that the Flashback retention is adhered to is to provide sufficient space in the Flash Recovery Area.
17.10.2011 Page 9 of 12

SAP Note 966117 -

Oracle Flashback Database technology

The following SQL command determines the oldest SCN in the Flashback Logs: SQL> SELECT OLDEST_FLASHBACK_SCN, TO_CHAR(OLDEST_FLASHBACK_TIME, 'YYYY-MON-DD HH24:MI:SS') FROM V$FLASHBACK_DATABASE_LOG; CAUTION: Certain database operations restart the Flashback window (for example, Drop Tablespace). This query does not take this restriction into account. The following SQL command determines the current SCN of the database: SQL> SELECT CURRENT_SCN FROM V$DATABASE;

Flashback Database in operation

The SCN area covered by the Flashback Logs is called a Flashback Database time window. To be able to execute Flashback database across the entire time interval, all Archive Logs must exist for this period of time. If you want to reset the database before the start of the current Flashback Database time window (that is, before the oldest SCN in the Flashback Logs), you must use the usual Point-in-Time-Recovery. You can execute the Flashback Database command using RMAN or SQL*PLus. If you use SQL*PLus, the DBA must ensure that the required Archive Logs are provided.

For example: Flashback Database

1. Log on to the database using RMAN: rman target / RMAN> SHUTDOWN IMMEDIATE RMAN> STARTUP MOUNT 2. Execute Flashback Database with one of the following three options (SCN, restore point, time): RMAN> FLASHBACK DATABASE TO SCN <number>; RMAN> FLASHBACK DATABASE TO RESTORE POINT <name of restore point>; RMAN> FLASHBACK DATABASE TO TIME "TO_DATE('09/20/00','MM/DD/YY')"; 3. Open database in READ ONLY mode to check whether the point of time was chosen correctly: RMAN> SQL 'ALTER DATABASE OPEN READ ONLY'; Note that it is not possible to start the SAP system if the database was opened in READ ONLY mode. To proceed, you have several options: 4a. Option 1: Open database again for normal use. RMAN> ALTER DATABASE OPEN RESETLOGS; You should select this option it the Flashback Database point of time was selected correctly and if the system should start again at this point.

17.10.2011

Page 10 of

12

SAP Note 966117 -

Oracle Flashback Database technology

4b. Option 2: Recover database up to current point of time RMAN> RECOVER DATABASE; With this, the Flashback Database command is undone and the database is brought back to its current state. 4c. Option 3: Another Flashback Database to an earlier SCN RMAN> FLASHBACK DATABASE TO SCN <scn number>; If the point of time was selected incorrectly (too late), you can use the Flashback command again to go even further back in the past. 4d. Option 4: Recover database for a later SCN RMAN> RECOVER DATABASE UNTIL SCN <scn number>; If the point of time was selected incorrectly (too early), you can move the recovery of the database towards the current point of time. For further example scenarios, refer to the Oracle documentation.

Flashback Database on a standby database

You can also activate Flashback Logging on a standby database of a standby configuration.

Administration of normal and guaranteed restore points

Create normal restore point: SQL> CREATE RESTORE POINT <NAME>; Create guaranteed restore point: SQL> CREATE RESTORE POINT <NAME> GUARANTEE FLASHBACK DATABASE; Note: To create a guaranteed restore point, you do not need to use ALTER DATABASE FLASHBACK ON to activate normal flashback mode in advance. On the contrary, due to space restrictions and for performance reasons, this has a negative impact and is not recommended. Display all restore points: SQL> SELECT * from V$RESTORE_POINT; Display guaranteed restore points: SQL> SELECT * from V$RESTORE_POINT WHERE guarantee_flashback_database = 'YES'; Comment: V$RESTORE_POINT.STORAGE_SIZE=0 for normal restore points Examples: SQL> create restore point NRP_before_test; SQL> create restore point GRP_before_upgr guarantee flashback database;

Deleting restore points

Command to explicitly delete a restore point: SQL> DROP RESTORE POINT <name>; Before you can create a restore point with the same name, you must explicitly delete it.

17.10.2011

Page 11 of

12

SAP Note 966117 -

Oracle Flashback Database technology

A normal restore point is deleted automatically from the control file if it is older than specified in parameter CONTROL_FILE_RECORD_KEEP_TIME. Independent of this time restriction, the last 2048 restore points remain saved in the control file. A GRP remains active and in the control file until it is deleted explicitly.

Header Data
Release Status: Released on: Master Language: Priority: Category: Primary Component: Secondary Components: BC-DB-ORA-DBA Database Administration with Oracle Released for Customer 19.07.2011 12:13:51 German Recommendations/additional info Consulting BC-DB-ORA Oracle

The Note is release-independent

Related Notes
Number 1125923 966073 937492 828268 434647 434645 105047 Short Text Support for Oracle database flashback in BR*Tools Oracle Flash Recovery Area/Fast Recovery Area FAQ: Oracle Flashback Oracle Database 10g: New functions Point-in-time recovery in an SAP system group Point-in-time recovery: What must I be aware of? Support for Oracle functions in the SAP environment

Attributes
Attribute Database system Value ORACLE

17.10.2011

Page 12 of

12