The contents of this chapter:
Understanding Flashback Database, restore Points and guaranteed restore Points
Logging for Flashback Database and guaranteed Restore Points
Prerequisites for Flashback Database and guaranteed Restore Points
Using Normal and guaranteed Restore Points
Using Flashback Database
1.Understanding Flashback Database, restore Points and guaranteed restore Points familiar with Flashbackup, restore pointsDatabase flashback and restore points allow the database to return to a time in the past to resolve logic errors that are much more efficient than a point-in-time Table space Recovery (TSPITR) and do not require a backup file to be used for restore. Functionally type onTspitr, it can also be used when the database is upgraded (flash back to upgrade), and when the main library is restored after the DG failure is created.
The restore point is used with the database flashback (Points). The restore point corresponds to an SCN, which can flash the database back to this SCN.
You can execute the Flashback command with Rman or execute the Flashback command in Sqlplus:
FLASHBACK DATABASE to RESTORE Point ' before_upgrade '; FLASHBACK DATABASE to SCN 202381;
1)DatabaseFlash Back (Flashback Database)Database flashback can restore a database to a point in time, but it does not open the database in a resetlogs way. The database flashback uses the flashback log, and the flashback log is placed in the fast recovery area. In order to use the Flashback feature, first turn on the flashback log. The principle of flashback: From the start of the flashback log, the database writes the modified database to the flashback log every once in a while. When the flashback is performed, the data block before the SCN is written to the data file, starting with the target SCN, and then the Redo log and archive log are used to recover the target SCN. Flashback database to rewind a database to a past target time, the command determines which blocks Chang Ed after the target time and restores them from the flashback logs. The database restores the version of each block, which is immediately before the target time. The database then uses redo logs to reapply changes, were made after these blocks were written to the flashback logs. Understandably inaccurate, data is written to the flashback log for each version of the data block? That flashback log was too big). If you want to revert to a week ago, you must keep the redo and archives within a week. The TSPITR need to save the log for a longer period of time.
2) The range of SCN that the Flashback Database window Flashback window can currently flash back is called a flashback window, depending on the size of the FRA, and if the FRA space is insufficient, it can only be flashed back to a relatively short time. Note: The flashback log can only be placed in the FRA. If the FRA space is not sufficient, the database will first delete the oldest flashback log instead of backing up files or other files. A guaranteed restore point is the only way to ensure that you can flash back to an SCN.
3) Limitations of Flashback database Flash back limit 1. Cannot be used for media recovery and delete data files. Reason: Only the modified blocks are recorded, not the full block 2. If the target SCN is followed by a reduction (shrink) operation, the flashback fails. However, you can shrink the data files offline and perform the flashback, and then use Rman to restore and recover. 3. If the control file was restored or re-created after the target SCN, the flashback could not be used. 4.If you have a nologing operation after the target SCN, you cannot recover the nologing data, and you must add the nologing option.
4)Normal restore Points Normal restoration point the normal restore point corresponds to an SCN number, the name of the restore point and the SCN are written in the control file, the control file can save thousands of restore points. The normal restore point is lightweight, requires little maintenance, and has little impact on the database. When a normal restore point expires, it is automatically deleted from the control file. Normal restore points can be used in flashback database and not fully recovered.
5) guaranteed restore Points The guaranteed restore point also corresponds to an SCN, but never expires, and is kept in the control file unless manually deleted. A guaranteed restore point ensures that the database will be able to flash back to that point, even if the flashback log is not turned on. When a guaranteed restore point is created, the database forces the flash back log between the point and the previous guaranteed restore point to be saved, so you can flash back to any of the SCN between the two points. Note: If the Flashback log is not turned on, it will not flash back to the moment between the two points, but can be flashed back to this restore point. A guaranteed restore point can restore the nologing operation. After a guaranteed restore point has been created, the database'scompatibility cannot be set to a higher value. Guaranteed restore points are commonly used to perform risky operations, such as the creation of guaranteed restore points on a physical standby in a DG to perform certain high-risk operations.
2. Logging for Flashback Database and guaranteed restore Points logging for flashback and guaranteed recovery pointsA guaranteed restore point's log records the first modified image of the data block after the SCN. The difference between a guaranteed restore point log and a flashback log is when the data block is logged and whether the logged log can be deleted.
1.Guaranteed restore Points and Fast Recovery area space usage guaranteed restore point space usage
Space usage rules:<1> when FRA has enough space, the flashback log is created and the retention time target is guaranteed (flashback retention target) .<2> If the flashback log is already old, the flashback log is reused <3 > If you have to create a flashback log, but there is no space in the FRA, the old flashback log is deleted <4> if a guaranteed restore point is created, any files that are guaranteed for that restore point are not deleted. In some cases, if the archive log is backed up, it may be deleted and needs to be To the archive log, restore from a backup. Regardless of whether the flashback log is enabled, the use of FRA is noted, and if the FRA space is full due to a guaranteed original point, the database hangs. (it says so much has not said the point, hehe)
2.Logging for guaranteed restore Points with Flashback Logging Disabled turn off log of guaranteed restore points under Flashback log when a guaranteed restore point is created, the first time the data block is modified, The data block image is written in the flashback log, and later changes are not written in the flashback log. There are two other effects: <1> You can rebuild the data file when the restore point is restored, just restore the mirrored block to the data file. <2> use less space than normal flashback logs, Because data block changes are recorded only once, the normal flashback log records multiple versions of the same block of data. When you simply want to restore a database to a point, create a guaranteed restore point, and then close the flashback log.
3.Logging for Flashback the Database with guaranteed restore Points Defined to turn on and flash back under guaranteed restores if both on and off, and a guaranteed restore point is created, At this time the flashback log is a normal flashback log (note 2, 32 cases of the flashback log is not the same). The flashback log ensures that you can flash back to any SCN between the two guaranteed restore points. Note: The space usage of fra must be monitored!
3.Prerequisites for Flashback Database and guaranteed restore Points simultaneously turn on flashback and create guaranteed restore pointsPrerequisites for turning on Flashback:<1> database running in Archivelog mode <2> must be on fra<3> in RAC, FRA must create a guaranteed restore point on the cluster file or ASM: In addition to the above points, The compatible parameter must also be satisfied to be 10.2.0 or above.
4.Using Normal and guaranteed restore Points use a common point (RP) and use a guaranteed restore point (GRP) (abbreviated for the following)1. Create the RP and execute it in Sqlplus:
sql> CREATE RESTORE Point Before_upgrade;
To create a GRP:
sql> CREATE RESTORE Point before_upgrade GUARANTEE FLASHBACK DATABASE;
2.Listing Restore Points lists the RP with the Rman command:
Restore_point_name; LIST RESTORE Point all;
Rman> LIST RESTORE Point all; Using target database control file instead of recovery Catalogscn RSP time Type time Name------------------------------------------------341859 28-jul-06 28-jul-06 normal_rs343690 28- JUL-06 Guaranteed 28-jul-06 Guaranteed_rs
Query from the control file:
Sql> SELECT NAME, SCN, Time, database_incarnation#, guarantee_flashback_database,storage_size from v$ Restore_point;
For the RP, the storage_size is 0, and for the GRP, the amount of disk space used
3.Dropping Restore Points Remove RP Note: The RP cannot duplicate the same name, want to build the RP, must delete the old.
sql> DROP RESTORE Point Before_app_upgrade; Restore Point dropped.
When the RP's retention time exceeds
CONTROL_FILE_RECORD_KEEP_TIMEis deleted. When the RP in the control file exceeds 2048, the old one is deleted.Note: GRP is never automatically deleted.
5.Using Flashback Database uses flash back1. Turn on Flashback log: Set flashback target, default is 1440, one day.
ALTER SYSTEM SET db_flashback_retention_target=4320; # 3 days
Turn on flash back under Mount
ALTER DATABASE FLASHBACK on;
To turn off the flashback log for a table space:
ALTER tablespace Tbs_3 FLASHBACK OFF;
ALTER tablespace Tbs_3 FLASHBACK on;
Note: If you turn off the Flashback feature of a table space, you must first take the table space offline when you perform a flash-back
2. Turn off flash Back:
ALTER DATABASE FLASHBACK OFF;
3.Configuring the environment for Optimal Flashback Database performance Configure the best flash back environment <1> use the fastest file system <2> enough disk space < ;3> a little .....
4.Monitoring the Effect of Flashback database on performance The impact of monitoring flashback on the databases can be viewed through AWR. Related Views (find refrence for views): V$flashback_ Database_stat: Write flash back log rate
V$sysstat:
Table 7-1 V$sysstat Statistics
| Column Name |
Column meaning |
Physical write I/O request |
The number of write operations issued for writing data blocks |
Physical read I/O request |
The number of read operations issued for reading data blocks |
Redo writes |
The number of write operations issued for writing to the redo log |
Flashback Log Writes |
The number of write operations issued for writing to flashback logs |
Flashback Log Write bytes |
Total size in bytes of flashback database data written from this instance |
5.Flashback Writer (RVWR) Behavior with I/O Errors rvwr/o error when the flashback is turned on or the GRP is created, the background process RVWR start and the data is written back into the flashback log. If the RVWR has an I/O error: 1. If the GRP is created, the database is down 2. If there is no GRP, the database continues to run. There are two scenarios at this point:
<1> in the main library (including the DG Master library \ Single database and RAC), the database automatically shuts down the flashback function .<2> on the physical standby and the logical standby, RVWR stops, but periodically attempts to write the flashback log, which eventually leads to a logical standby or managed The physical standby of the recovery is suspended. This time to execute shutdown abort or alter DATABASE FLASHBACK OFF
From for notes (Wiz)
