? Configure the Flashback database? Perform a flashback database operation? Monitoring the Flash back database
- Flash back to the database
Flash back database operation:? Functions like a rewind button for a database? You can use the flashback database to use a flashback database in the event of a user causing logical data corruption, and quickly restore the database to that time by restoring any changes that have occurred since the previous point in time. Becauseno need to restore backup, so this operation is very fast. You can use this feature to restore changes that cause logical data corruption. When using the Flashback database, Oracle DB can roll back changes to the database using a past block image. During normal database operations, Oracle DB will occasionally record these block images in the flashback log. The flashback log is written sequentially and is not archived. Oracle DB automatically creates, deletes, and resizes the flashback log in the Quick recovery area. You only need to focus on the flashback log for monitoring performance purposes and determine how much disk space is allocated for the fast recovery zone to hold the flashback log. The time it takes to rewind a database using the flashback database is proportional to how long it will take to fall back and the amount of database activity that occurs after the target time. It takes much longer to restore and restore an entire database. The pre-image in the flashback log is used only to restore the database to a point in time in the past, while a roll-forward recovery is used to restore the database to a state consistent with a time in the past. Oracle DB restores the data files to a previous point in time, with the exception of auxiliary files, such as initialization of parameter files. The flashback database can also be used to assist with data Guard and recovery guidance, and to synchronize replicated databases.
- Flash Back Database architecture
When the Flashback database feature is enabled, it startsRVWR(Flash back to write process) background process. The subsequent process sequentially writes the flashback database data from the flashback buffer to the Flash back database log, which is used for recycling. Then, when the Flashback Database command is issued, the system uses the flashback log to revert to the front of the block, and then rolls back to the desired flashback time using the redo data. The cost of enabling the flashback database depends on the database's read/write mix effort. Because the query does not need to record any flashback data, the greater the amount of write operations, the higher the overhead of enabling the flashback database.
- Configuring the Flashback Database
sql> shutdownimmediatesql> STARTUP MOUNTsql> ALTER DATABASE ARCHIVELOG;If the database is in Archivelog mode, you do not need to restart the database. sql> ALTER SYSTEM SETDb_flashback_retention_target=2880 Scope=both; Sql> ALTER DATABASE FLASHBACK on; sql> ALTER DATABASE OPEN; Follow these steps to configure the Flashback database: 1. Configure the quick recovery area. 2. Set the retention target using the Db_flashback_retention_target initialization parameter. You can specify an upper limit (in minutes) that indicates how long the database can be flashed back. ALTER SYSTEM SETDb_flashback_retention_target=2880 Scope=both was used for 2,880 minutes, equivalent to two days. This parameter is only a target and does not provide any guarantees. The flashback interval depends on the amount of flash data saved in the Quick recovery area. 3. Use the following command to enable the Flashback database: ALTER db FLASHBACK on; The database must be configured for archiving before issuing a command to enable the flashback database. You can use the following query to determine whether the flashback database is enabled: SELECT flashback_on from v$database; You can disable the flashback database by using the ALTER DATABASE flashback off command. In this way, all existing flashback database logs are automatically deleted. Note: The flash-back database cannot be enabled until the database is mounted in exclusive mode, but not in the open state.
- The action you need to perform
Configure Workflow: 1. Make sure the database is in Archivelog mode. 2. Enable flashback logging and specify the Quick recovery area. You need to perform an action to log on to Oracle Enterprise Manager (EM). On the availability (availability) page, in the Backup/recovery (Backup/restore) area, select Recovery Settings (Restore settings). Make sure the database is in Archivelog mode. If the database is not in this mode, check ARCHIVELOG mode ARCHIVELOG, and then click Continue (Continue). You need to close and restart the instance for the changes to take effect. After the quick recovery Zone and archive are configured, the Use_db_recovery_file_dest is configured to archive log target location 10. Select Enable Flashback Logging (enable flashback logging) to turn on flashback logging. You can also set the flash back retention time to view important information about the Flashback Database window. Review the location of the quick recovery area. The quick recovery zone is the unified storage location for all recovery-related files and activities in Oracle DB. All files required to fully recover the database after a media failure are included in the quick recovery area. Recovery-related files that can be created in the Quick recovery area include: Archive redo log files, control files, backups created by Recovery Manager (RMAN), flashback logs, and change tracking files. By allocating storage locations and centralizing recovery-related files into specific areas, Oracle DB Server eases the burden on the database administrator so that they do not have to manage the disk files created by these components. The default location for the quick Recovery zone is $oracle_base/flash_recovery_area. If you want it to be in a different location, you can change it immediately. Scroll down to the bottom of the Recovery Settings (Restore Settings) page, and then click Apply.
- Flash Back Database: Example
? Flashback: Mount the database in exclusive mode rman> FLASHBACK to time = "to_date (' 2009-05-27 16:00:00 ', ' yyyy-mm-dd HH24:MI:SS ')"; Rman> FLASHBACK DATABASE to scn=23565; Rman> FLASHBACK DATABASE to sequence=223thread=1; Sql> FLASHBACK DATABASE to TIMESTAMP (SYSDATE-1/24); Sql> FLASHBACK DATABASE to SCN53943; sql> FLASHBACK database to RESTORE point b4_load; Monitor the progress of the flash-back databases through the V$session_long view. Review changes: Open the database as read-only? Finish: Open the Database Flashback database using Resetlogs as read/write: example you can use the Rman FLASHBACK Database command to perform a flash-back db operation. You can use sequence and thread to specify the redo log sequence number and thread as the lower bound. RMAN selects only files that can be used to flash back to the specified serial number (but not the specified serial number). You can also use the SQL FLASHBACK database command to return databases to a time or SCN in the past. If you use the to SCN clause, you must supply a number. If you specify to TIMESTAMP, you must provide a timestamp value. You can also specify a restore point name. You can monitor the flashback database progress through the V$session_longops view. Note: You must mount the database in exclusive mode before you issue the Flashback Database command; To review the changes, you can open the database as read-only. When you are finished, you must open the database in read/write with the Resetlogs option.
- Flash Back Database considerations
? After the flashback database operation is complete, open the database: – Verify that the target time used or the SCN is correct in read-only mode. – UseResetlogsOperation to allow DML.? "Flashback" is opposite to "recovery". The flashback database operation cannot be used in the following situations: – The control file has been restored or has been recreated. – The tablespace has been deleted. – The size of the data file has been reduced. Use the to before RESETLOGS clause to flash back to the moment before the first resetlogs operation. Flashback database Considerations When you cannot use the Flashback database feature, you should use an incomplete recovery operation to restore the database to a specific time. After the flashback database operation is complete, you canOpen the database in read-only mode to verify that the correct target time is used orSCN。 If not, you can either flash back to the database again, or roll forward the database by performing a recovery operation. Therefore, to restore the flashback database operation, you should roll forward the recovery database.You cannot use the Flashback database operation to recover a data file that was deleted during a flash back operation。 The deleted data file is added to the control file and marked offline, but does not flash back. The flashback database operation failed to flash the data file back to a time before it was created and resized. If a file is resized during the time the database is going to flash back, you should take the file offline before the flashback database operation begins. This applies to shrinking files, not extended files. You can use the flashback database for data files that are already configured to scale automatically. By providing the to before Resetlogs clause in the Flashback Database command, you can just flash back to the moment before the first resetlogs operation. Note: Flashback retention targets are not fully guaranteed to be available for Flash back. If the required files need to occupy space in the quick recovery area, the flashback log may be deleted automatically.
- Monitoring the Flash back database
To monitor capacity for reserved targets:? View disk quotas for the quick recovery Zone:sql> SELECT estimated_flashback_size, flashback_size from V$flashback_database_log;? Determine the current flashback window:sql> SELECT oldest_flashback_scn, oldest_flashback_time from V$flashback_database_log;? Monitor log records in the Flashback database log:sql> SELECT * from V$flashback_database_stat; It is important to monitor the flashback database to monitor the amount of space used in the fast recovery area, because doing so will know how to meet the retention targets. UseV$flashback_database_logView to monitor the retention target of the flashback database:? Estimated_flashback_sizeUsing the previously recorded flashback data, you can estimate how much disk space the Flash logs in the fast recovery area will require to meet the current flashback retention target. The estimate is based on the amount of work since the instance was started, or the last time interval that is equal to the flashback retention target, taking the smaller value.? Flashback_sizeThe current byte size (in bytes) of the flashback data is given.? OLDEST_FLASHBACK_SCN and Oldest_flashback_timeShows the approximate minimum SCN and time at which the database can be flashed back. The CURRENT_SCN in v$database gives the current database SCN. Use the V$flashback_database_stat view to monitor the overhead of recording flashback data in the Flashback database log. This view contains 24 hours of information, and each line represents an hour interval. Use this view to determine the change in the generation rate of the flashback data. Sql> SELECT begin_time, End_time, Flashback_data, db_data, Redo_data, estimated_flashback_size as EST_FB_SZE& nbsp From V$flashback_database_stat; begin_tim end_time flashback_data db_data redo_data EST_FB_SZE----------------- ---------------------------------------------12-feb-09 12-feb-09 16384 0 24576 012-feb-09 12-feb-09 6594560 7471104 1533440 81592320012-feb-09 12-feb-09 17235968 12361728 5150920 &nbSp 83946700812-feb-09 12-feb-09 311648256 37249024 10272768 855195648 based on this information, you may need to adjust the retention time or the fast recovery area size. The Flashback_data and Redo_data represent the number of flashback and redo data written during the time interval, respectively, and the Db_data provides the number of bytes of data blocks read and written. This view also includes the expected flash back space within a certain time interval. Query V$recovery_file_dest to view information related to the quick recovery area. The columns are described as follows:? Name: Names of the quick recovery zones, indicating the location string? Space_limit: The disk limit specified in the Db_recovery_file_dest_size parameter? Space_used: The space used in the Fast Recovery zone file (bytes)? Space_reclaimable: How much space can be reclaimed by removing the low-priority files identified by obsolete files, redundant files, and other spatial management algorithms? Number_of_files: Number of files sql> SELECT name, space_limit as quota,space_used as used,space_reclaimable as Reclaimable, Number_of_files as files from V$recovery_file_dest; NAME QUOTA used reclaimable files---------------------------------- --------------------------/u01/flash_recovery_area 5368707120 2507809104 203386880 226 use em to monitor the Flash back database Recovery Settings (Restore Settings) page, you see most of the flashback database statistics that are mentioned in the previous pages. These measures include the amount of space currently used by all flashback logs, the minimum SCN, and the minimum SCN time in the flashback data.
- Guaranteed restore points
Using a guaranteed restore point ensures that the Flashback Database command can be flashed back to the SCN at any time by executing the. Sql> CREATERESTORE PointBefore_upgradeGUARANTEEFLASHBACK DATABASE; Ensure that restore points, like normal restore points, ensure that restore points are used as aliases for SCN in recovery operations. The main difference is to ensure that the restore point is never removed from the control file due to expiration and must be explicitly deleted. However, guaranteed restore points also provide specific functionality related to using the Flashback database feature. After a specific SCN creates a guaranteed restore point, the database is restored to the state of the SCN by forcing the flashback database operation, even if the database is not enabled for flashback logging. If flashback logging is enabled, creating a guaranteed restore point forces the required flashback log to be retained, enabling the flashback database operation to revert to the earliest guaranteed restore point at any point in time after it was created. Ensure that restore points can be used to restore an entire database to a known good state of days or weeks, as long asQuick Recovery ZoneThere is enough disk space in the storage to store the required logs. The same as a normal restore point, which guarantees that the restore point can be used to specify a point in time for the recover database operation. Note: The restrictions that apply to the Flashback database also apply to guaranteed restore points. For example, shrinking a data file or deleting a tablespace can cause the affected data file to fail to flash back to the guaranteed restore point.
- Flashback database and guaranteed restore point
To use a guaranteed restore point, the database must meet the following prerequisites:? The compatible initialization parameter must be set to a value of 10.2 or greater. The database must be running in Archivelog mode. FLASHBACK database requires an archive redo log that starts at approximately the time of the restore point. The quick recovery area must be configured. Flashback database and guaranteed restore point to support the use of guaranteed restore points, the database must meet the followingPrerequisites：? The compatible initialization parameter must be set to a value of 10.2 or greater. The database must be running in Archivelog mode. To rewind the database to a guaranteed restore point, the FLASHBACK Database command needs to use an archive redo log that starts approximately from the restore point time. The quick recovery area must be configured. Ensure that restore points use a mechanism similar to flashback logging. As with flashback logging, Oracle DB must store the required logs in the fast recovery area. If the flashback database is not enabled, when the first guaranteed restore point is created (or if all previously created guaranteed restore points have been deleted),The database must be in a mounted state instead of open。 The flashback database and the log records that guarantee the restore point need to capture the image of the data file block before the application changes. The FLASHBACK database command can use these images to restore a data file to its previous state. The primary difference between normal flashback logging and guaranteed restore point logging is when the block is logged and whether the log is deleted when there is insufficient space in the fast recovery area. These differences affect the amount of space used and database performance of the log. If you enable the Flashback database and define one or more guaranteed restore points, the database performs normal flash-back logging. In this case, the recovery area retains the flashback log required to flash back to the current time and at any time between the currently defined guaranteed restore points. If you guarantee that the restore point requires a flashback log, the flashback log will not be deleted because of insufficient space. http://blog.csdn.net/rlhua/article/details/12421005
