Flashback Database is implemented by using a new type of log file called flashback logs. Flashback logs are before images of data blocks. These logs contain data block images for changed blocks and other information that enables the operation. The Oracle database server periodically logs before images of data blocks in the flashback logs. The data block images are used to quickly back out changes to the database during a Flashback Database operation.
The flashback logs are created in the flash recovery area. You do not create or manage the files in the Flash Recovery Area. You do not need to explicitly size the flashback logs. The catch here is you must decide how much disk space to allocate to the flash recovery area for them.Also mind that nothing comes free it has some cost associated with it . Additional Backgroungd process in the form of Recovery Writer (RVWR) is introduced.You have the choice of enabling or disabling Flashback Database. When Flashback Database is enabled, the Recovery Writer (RVWR) background process is started. This new background process writes Flashback Database data to the flashback logs.
Now lets take a look at how Flashback Database is enabled You can configure Flashback Database by performing the following steps:
1. we need to Configure the flash recovery area by setting the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE initialization parameters.
2. Enable Flashback Database with the following command:
SQL>ALTER DATABASE FLASHBACK ON
It is very important that the database must be in MOUNT EXCLUSIVE mode to issue this command. The database must also be in ARCHIVELOG mode to enable Flashback Database.
3. Set the flashback retention target by using the DB_FLASHBACK_RETENTION_TARGET initialization parameter. You can specify an upper limit in minutes on how far back you want to flash back the database by using this parameter.
You can query V$DATABASE to determine whether Flashback Database is enabled as follows:
SELECT flashback_on FROM v$database;
Additinal comments : You can enable Flashback Database for a standby database even when its primary database does not have Flashback Database enabled.Flashback logs are not archived.
Performing Flashback of the Database
While performing a flashback of the database, Oracle uses the flashback logs to go back in time. In addition, redo log entries may be applied to ensure consistency in the database.This explains why the database is to be in archive log mode for flashback feature.
Once the Flashback is complete, the database can be opened in read-only mode to verify that the correct target time or SCN was used. If not, you can flash back the database again or perform additional recovery to roll forward the database to a different point in time.
Additional comments:
In the following situations, you cannot use the Flashback Database feature:
The control file has been restored or re-created.A tablespace has been dropped.A datafile has been shrunk.Recovery occurs through a RESETLOGS operation.
You must open the database with a RESETLOGS operation following the flashback to allow for updates.
Flashback using RMAN
The RMAN FLASHBACK DATABASE command can be to perform the Flashback.
we need to query V$FLASHBACK_DATABASE_LOG to find the OLDEST_FLASHBACK_SCN and OLDEST_FLASHBACK_TIME in to display the approximate lowest SCN and time to which we can flash back. The current database SCN can be queried through V$DATABASE.CURRENT_SCN.
The SEQUENCE and THREAD keywords can be specified for flashback as an upper limit. RMAN will select only files those files that can be recovered up to, but not including, the specified sequence number.
Example:
RMAN>FLASHBACK DATABASE TO SEQUENCE=143 THREAD=1;
RMAN>FLASHBACK DATABASE TO SCN=600;
Alternatively the FLASHBACK DATABASE command can be run at the SQL PROMPT to return the database to a past time or SCN.
Example:
SQL>FLASHBACK DATABASE TO SCN 143;
CAVEATS
The important points to look out for would be that the Flashback Database operation does not have enough flashback data and there is not enough Flashback Database data for the database,the solution is to change the time or SCN specified or use you may end up doing the point-in-time recovery.
There can also be a possibility that not enough Flashback Database data for a set of files, then we can take these set of datafiles offline and flash back the remaining datafiles. The offline datafiles can then be recovered to the same point in time by using normal point-in-time recovery methods.
Disabling Flashback Database
Issue the following RMAN command to disable Flashback Database:
RMAN> SQL "ALTER DATABASE FLASHBACK OFF";
Using SQL Commands
Issue the following SQL command to disable Flashback Database:
SQL> ALTER DATABASE FLASHBACK OFF;
When we disable Flashback Database, all existing flashback logs are deleted!!.
Flashback Database in a Standby Database Configuration
Most of the Enterprises have a DR policy in place where in they create a time lag between the archiving of a redo log at the primary site and the applying of the redo log at the standby site. This time lag protects against the application of corrupted or erroneous data from the primary site to the Disaster Recovery site. So to accomplish this they create multiple DR sites (databases) with varying delays, so that they are able to easily recover from user errors. But the bottom line is to have enough storage and resources to support the configuration of multiple standby databases.
But starting with Oracle Database 10g, you can configure one standby database with Flashback Database to achieve the same benefit as multiple standby databases with different delays.
Flashback Database After Failover
A Failover is initiated when a catastrophic failure occurs on the primary database, and there is a need to bring up the database in a timely manner. After failover the old standby database becomes the new primary database, and the old primary database is not a part of Data Guard anymore. In 9i release of Oracle Data Guard, you had to reinstantiate the old primary so that it could rejoin the Data Guard environment. Reinstantiation of the standby database often took a long time because you had to restore the database from a remote or local backup.
In Oracle Database 10g, the Flashback Database feature can be used to convert the old primary database into a new standby database without performing a complete reinstantiation of the database. The old primary database can be flash backed so that it contains only changes that are already applied to the old standby database. This allows you to convert the old primary database into a new standby database without restoring the old primary database.
The Flashback Database feature enabled on the old primary database.
Physical Standby with Failover Configuration
In a physical standby configuration, you can perform the following steps to avoid reinstantiating the old primary database after a failover:
1. On the new primary database ie the old standby database, determine the SCN at which the old standby database became the new primary database by running the following query:
SQL>SELECT standby_became_primary_scn FROM v$database;
2. Now when the old primary database site becomes available, mount the old primary database.
3. Flash back the old primary database to the “standby became primary” SCN as determined in step 1.
SQL>FLASHBACK DATABASE TO SCN
4. Disable Flashback Database on the old primary database by issuing the following command:
SQL>ALTER DATABASE FLASHBACK OFF;
5. At the old primary database , create a new standby database control file.
6. Shut down the old primary instance.
7. On the old primary database, replace the existing control file with the new standby control file created in step 5.
8. Mount the old primary database. The old primary database is now your new standby database.
9. On the new standby, enable Flashback Database:
SQL>ALTER DATABASE FLASHBACK ON;
10. On the new primary database, log transport services can be enabled to the old primary (new standby). Archive a new log to the new standby by running the following command:
SQL>ALTER SYSTEM ARCHIVE LOG CURRENT;
11. On the new standby, start managed standby recovery. The role reversal is now complete.
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Backing up the Recovery Area
RMAN> BACKUP RECOVERY AREA;
The above command ensures that all flash recovery files created in the current (and any previous) flash recovery area destinations that have not previously been backed up to tape will be backep up. Files that fall into this category are full and incremental backup sets, control file autobackups, archive logs, and data file copies. It is important to note that flashback logs, incremental bitmaps, current control file, online redo log files are not backed up.
RMAN> BACKUP RECOVERY FILES;
The above command ensures that all recovery files on disk that have not previously been backed up to tape. The files backedup are full and incremental backup sets, control file autobackups, archive logs, and data file copies.
The RMAN CONFIGURE BACKUP OPTIMIZATION is always ON for these keywords. It is important to choose only TAPE as the backup destination for these commands.
Worth Reading
http://www.oracle.com/technology/oramag/oracle/07-jan/o17recovery.html
http://www.oracle.com/technology/oramag/oracle/06-nov/o66recovery.html
No comments:
Post a Comment