温故而知新（二）：”Using Flashback Database and Restore Points“ Translate & Notes

Using Flashback Database and Restore Points

This chapter explains Flashback Database, restore points. This chapter discusses configuring, monitoring, and maintaining these features as part of an overall data protection strategy.
This chapter contains the following topics:

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
See Also:
Detailed information on recovery scenarios that use Flashback Database and normal and guaranteed restore points can be found in Chapter 18, "Performing Flashback and Database Point-in-Time Recovery".
Understanding Flashback Database, Restore Points and Guaranteed Restore Points
Oracle Flashback Database and restore points are related data protection features that enable you to rewind data back in time to correct any problems caused by logical data corruption or user errors within a designated time window. These features provide a more efficient alternative to point-in-time recovery and does not require a backup of the database to be restored first. The effects are similar to database point-in-time recovery (DBPITR). Flashback Database and restore points are not only effective in traditional database recovery situations but can also be useful during database upgrades, application deployments and testing scenarios when test databases must be quickly created and re-created. Flashback Database also provides an efficient alternative to rebuilding a failed primary database after a Data Guard failover.
oracle的“数据库闪回”与“还原点”是与数据保护相关的功能，它可以让你在限定的时间及时“倒回”数据以修正任何逻辑上或者用户误操作导致的问题，这些功能提供了一种非常规且更有效的“基于时间点的恢复“，并且不需要首先通过数据库备份进行还原。其效果类似于”基于时间点的恢复“。数据库闪回与还原点不仅仅适用于事务类数据库恢复的情况，也适用于升级过程、应用部署与需要快速创建或者重建的测试场景。数据库闪回也提供了一种在dataguard中，做“灾难切换”后，高效重建主库的可选方案。
See Also:
Oracle Data Guard Concepts and Administration
Restore points provide capabilities related to Flashback Database and other media recovery operations. In particular, a guaranteed restore point created at an system change number (SCN) ensures that you can use Flashback Database to rewind the database to this SCN. You can use restore points and Flashback Database independently or together.
还原点为数据库闪回与其他介质恢复操作提供了支持。尤其是”担保性还原点“会创建一个SCN号，来确保你可以使用数据库闪回功能”倒回“数据库至这个SCN。你可以单独或者一起使用”还原点“与”数据库闪回“
Flashback Database is accessible through the RMAN command FLASHBACK DATABASE or the SQL statement FLASHBACK DATABASE. You can use either command to quickly recover the database from logical data corruption or user errors. The following examples return the database to a specified SCN or restore point:
FLASHBACK DATABASE TO RESTORE POINT 'before_upgrade';
FLASHBACK DATABASE TO SCN 202381;

Flashback Database

Flashback Database is similar to conventional point-in-time recovery in its effects. It enables you to return a database to its state at a time in the recent past. Flashback Database is much faster than point-in-time recovery because it does not require restoring datafiles from backup and requires applying fewer changes from the archived redo logs.
数据库闪回类似于传统的基于时间点的恢复的效果。它允许你将数据库返回到过去不远的某个时间状态。数据库闪回比基于时间点的恢复快很多，因为它不需要还原数据文件，并且仅仅需要从归档日志应用很少的一部分数据变化
（BOND： 所以数据库闪回有点类似与增量备份的模式，且闪回日志应用完后，是需要引用归档日志或者在线日志的）
You can use Flashback Database to reverse most unwanted changes to a database if the data files are intact. You can return a database to its state in a previous incarnation, and undo the effects of an ALTER DATABASE OPEN RESETLOGS statement.
你可以使用数据库闪回来倒回很多数据库中你不希望的变化，如果数据文件是完好的。你可以将数据库退回到过去某个incarnation的状态。
并且可以撤销“ ALTER DATABASE OPEN RESETLOGS”的效果！！（BOND：这就是为什么可以在DG测试中能快速重建环境的原因了，真的很强大）
Flashback Database uses its own logging mechanism,creating flashback logs and storing them in the fast recovery area. You can only use Flashback Database if flashback logs are available. To take advantage of this feature, you must set up your database in advance to create flashback logs.
数据库闪回使用了自身的日志算法，它创建闪回日志并将其保存在闪回恢复区。你仅能在闪回日志可用时使用数据库闪回功能。为了利用这一功能，你必须提前调整你的数据库，以创建闪回日志。
To enable Flashback Database, you configure a fast recovery area and set a flashback retention target. This retention target specifies how far back you can rewind a database with Flashback Database.
为了闪回数据库，你需要配置一个闪回恢复区并且设置一个闪回保留值，这个保留值指定了你在使用数据库闪回时你能“倒回”多远。
From that time on wards, at regular intervals, the database copies images of each altered block in every data file into the flashback logs. These block images can later be reused to reconstruct the data file contents for any moment at which logs were captured.
从那个时间往前（正向），每逢一个规律的间隔期，数据库会拷贝每个数据文件中变化的数据块的镜像到闪回日志。这些块镜像可以在今后被用于在闪回日志记录的情况下，重构任意时刻数据文件内容。（BOND：所以说闪回日志实际上是一组块镜像的集合，并且是隔一个时间间隔拷贝一次，有点类似差异增量备份的模式）
When you use Flashback Database to rewind a database to a past target time, the command determines which blocks changed after the target time and restores them from the flashback logs. The database restores the version of each block that is immediately before the target time. The database then uses redo logs to reapply changes that were made after these blocks were written to the flashback logs.
当你使用数据库闪回来倒回数据库至过去一个目标时间点，该命令会决定在这个时间点之后哪些数据块变化了并且将他们从闪回恢复区恢复出来。数据库会还原每个数据库至目标时间最近的“块版本”。然后数据库会使用重做日志来应用这些“块版本”之后的变化
（BOND： 第一步通过闪回日志回到最接近时间点的块版本，第二步利用重做日志应用至该时间点，这就是为什么归档日志在flashback on时，不会被标记为obsolete）
Redo logs on disk or tape must be available for the entire time period spanned by the flashback logs. For example, if the flashback retention target is 1 week, then you must ensure that online and archived redo logs that contain all changes for the past week are accessible. In practice, redo logs are typically needed much longer than the flashback retention target to support point-in-time recovery.
磁盘与磁带上重做日志必须在整个闪回日志生成期间是可用的。例如：如果闪回保留目标是1周，那么你必须确保那些包含了所有变化的在线或者归档日志是可访问的。在实践中，通常重做日志会比闪回日志的保留期保存更多，以便支持基于任意时间点的闪回恢复。

Flashback Database Window

The range of SCNs for which there is currently enough flashback log data to support the FLASHBACK DATABASE command is called the flashback database window. The flashback database window cannot extend further back than the earliest SCN in the available flashback logs.
用来足够支持数据库闪回所需的的闪回日志，他们的SCN区间称作“数据库闪回窗口”。它的上限不能小于可用闪回日志的最早的SCN值。
You cannot back up flashback logs to locations outside the fast recovery area. To increase the likelihood that enough flashback logs are retained to meet the flashback database window, you can increase the space in your fast recovery area (see "Initialization Parameters for the Fast Recovery Area").
你不能备份闪回日志至闪回恢复区以外的位置。为了增加有足够闪回日志来符合“闪回恢复窗口”的可能性，你可以增加闪回恢复区的空间。
If the fast recovery area is not large enough to hold the flashback logs and files such as archived redo logs and other backups needed for the retention policy, then the database may delete flashback logs from the earliest SCNs forward to make room for other files. Consequently, the flashback database window can be shorter than the flashback retention target, depending on the size of the fast recovery area, other backups that must be retained, and how much flashback logging data is needed. The flashback retention target is a target, not a guarantee that Flashback Database is available.
如 果闪回恢复区不能为保留策略保存足够的闪回日志与归档日志以及其他备份内容，数据库将会从最早的SCN开始删除闪回日志，以便于为其他文件腾出空间。因此 逻辑上，“数据库闪回窗口”可以比保留策略要小，它取决于闪回恢复区的尺寸，与其他必须保留下来的备份，同时取决于有多少闪回日志需要被使用。闪回保留目标仅仅是个目标值，并不会保证数据库闪回可以成功。（BOND：补充一下：DB_FLASHBACK_RETENTION_TARGET specifies the upper limit (in minutes) on how far back in time the database may be flashed back. How far back one can flashback a database depends on how much flashback data Oracle has kept in the fast recovery area.）
If you cannot use FLASHBACK DATABASE because the flashback database window is not long enough, then you can use database point-in-time recovery (DBPITR) in most cases to achieve a similar result. Guaranteed restore points are the only way to ensure that you can use Flashback Database to return to a specific point in time or guarantee the size of the flashback window.
如果你因为“数据库闪回窗口”不够大而不能使用数据库闪回，你可以在大多数情况下使用基于时间点的恢复来取得类似的效果。“保证还原点”是唯一可以保证你可以使用数据库闪回至指定的时间点，或者能够保证“数据库闪回窗口“足够的尺寸。

Limitations of Flashback Database

Because Flashback Database works by undoing changes to the data files that exist at the moment when you run the command, it has the following limitations:
Flashback Database can only undo changes to a data file made by Oracle Database. It cannot be used to repair media failures, or to recover from accidental deletion of data files.
You cannot use Flashback Database to undo a shrink data file operation. However, you can take the shrunken file offline, flash back the rest of the database, and then later restore and recover the shrunken data file.
You cannot use Flashback Database alone to retrieve a dropped data file. If you flash back a database to a time when a dropped data file existed in the database, only the data file entry is added to the control file. You can only recover the dropped data file by using RMAN to fully restore and recover the data file.
If the database control file is restored from backup or re-created, all accumulated flashback log information is discarded. You cannot use FLASHBACK DATABASE to return to a point in time before the restore or re-creation of a control file.
When using Flashback Database with a target time at which a NOLOGGING operation was in progress, block corruption is likely in the database objects and datafiles affected by the NOLOGGING operation. For example, if you perform a direct-path INSERT operation in NOLOGGING mode, and that operation runs from 9:00 to 9:15 on April 3, 2005, and you later use Flashback Database to return to the target time 09:07 on that date, the objects and datafiles updated by the direct-path INSERT may be left with block corruption after the Flashback Database operation completes.
If possible, avoid using Flashback Database with a target time or SCN that coincides with a NOLOGGING operation. Also, perform a full or incremental backup of the affected data files immediately after any NOLOGGING operation to ensure recoverability to points in time after the operation. If you expect to use Flashback Database to return to a point in time during an operation such as a direct-path INSERT, consider performing the operation in LOGGING mode.
因为是数据库闪回是通过撤销数据文件改变进行工作的，它有如下限制：
数据库闪回只能撤销数据库系统产生的数据文件变化，它不能用来修复介质失效。或者从意外删除数据文件时恢复过来。
1.你不能使用数据库闪回来撤销“数据文件收缩”的操作。可是，你可以将被收缩过的文件离线，闪回数据库的其他部分，然后再还原并恢复被收缩的文件。
2.你不能单独使用闪回数据库来取回一个被删掉的数据文件。如果你将数据库闪回至该数据文件还存在时的时间点，仅仅会有数据文件的记录被加入到控制文件。你只能使用RMAN进行完全还原后并恢复以还原被删除掉的数据文件。
3.如果数据库的控制文件是从旧备份恢复或者是被重建的，所有累计的闪回日志记录信息会被清空。你不能再使用数据库闪回到控制文件还原或者重建时间之前的某个时间点。
4. 当在一个有很长时间的nologging过程中使用数据库闪回时，数据文件与数据库对象可能受nologging的操作影响产生坏块。例如：如果你执行了 一个onlogging模式下的direct-path insert操作，并且这个操作在2005年8月3日 9：00到9：15运行，随后你使用数据库闪回让其回到当天9：07的状态，那些被direct-path insert更新的数据块可能会在数据库闪回操作完毕后产生坏块。 （BOND：需要注意这是一种容易引起坏块的情况）
所 以如果可能的话，请避免使用数据库闪回至目标时间且同时存在nologging操作。同时在nologging操作后，立即为受影响的数据文件执行一次全 量或者增量备份以确保能够在操作之后是可以被恢复至某个时间点的。如果你希望在诸如direct-path insert操作过程中，使用数据库闪回让其回到某个时间点，建议使用logging模式来做以上操作（BOND：这里说明了flashback database是需要logging模式来确保成功的）

Normal Restore Points

Creating a normal restore point assigns a restore point name to an SCN or specific point in time. Thus, a restore point functions as a bookmark or alias for this SCN. Before performing any operation that you may have to reverse, you can create a normal restore point. The control file stores the name of the restore point and the SCN.
If you use flashback features or point-in-time recovery, then you can use the name of the restore point instead of a time or SCN. The following commands support this use of restore points:
    The RECOVER DATABASE and FLASHBACK DATABASE commands in RMAN    The FLASHBACK TABLE statement in SQL
Creating a normal restore point eliminates manually recording an SCN in advance or determine the correct SCN after the fact by using features such as Flashback Query.
Normal restore points are lightweight. The control file can maintain a record of thousands of normal restore points with no significant effect on database performance. Normal restore points eventually age out of the control file if not manually deleted, so they require no ongoing maintenance.
常规还原点创建一个常规还原点会为SCN或者指定时间点分配一个还原点名称，因此，一个还原点功能类似与SCN的一个标签或者别名。在你做任何回退操作之前，你可以创建一个常规还原点。控制文件记录这个还原点的名称与SCN。如果你使用闪回功能或者基于还原点的恢复，你可以用还原点的名称代替代替时间点或者SCN。以下的命令支持还原的这种用法：RMAN 的 recover database   , flash database；SQL 的 flashback table
（BOND:任何需要使用到时间点或者SCN的恢复与闪回操作，均可以使用还原点别名）
创建一个常规还原点可以不用手动记录详细的SCN或者诸如在闪回查询功能时手动判断正确的SCN。
常规还原点是轻量级的，控制文件可以管理上千条常规还原点记录，并且对数据库的性能没有重大影响。常规还原点如果没有手动删除，它最终会在控制文件老化，所以他们不需要持续性的维护。

Guaranteed Restore Points

Like a normal restore point, a guaranteed restore point serves as an alias for an SCN in recovery operations. A principal difference is that guaranteed restore points never age out of the control file and must be explicitly dropped. In general, you can use a guaranteed restore point as an alias for an SCN with any command that works with a normal restore point. Except as noted, the information about where and how to use normal restore points applies to guaranteed restore points as well.
A guaranteed restore point ensures that you can use Flashback Database to rewind a database to its state at the restore point SCN, even if the generation of flashback logs is disabled. If flashback logging is enabled, then a guaranteed restore point enforces the retention of flashback logs required for Flashback Database to any SCN after the earliest guaranteed restore point. Thus, if flashback logging is enabled, you can rewind the database to any SCN in the continuum rather than to a single SCN only.
Caution:
If flashback logging is disabled, then you cannot FLASHBACK DATABASE directly to SCNs between the guaranteed restore points and the current time. You can, however, flashback to the guaranteed restore point first and then recover to SCNs between the guaranteed restore point and current time.
If the recovery area has enough disk space to store the needed logs, then you can use a guaranteed restore point to rewind a whole database to a known good state days or weeks ago. As with Flashback Database, even the effects of NOLOGGING operations like direct load inserts can be reversed with guaranteed restore points.
Note:
Limitations that apply to Flashback Database also apply to guaranteed restore points. For example, shrinking a data file or dropping a tablespace can prevent flashing back the affected data files to the guaranteed restore point. See "Limitations of Flashback Database" for details. In addition, when there are guaranteed restore points in the database, the database compatibility parameter cannot be set to a higher database version. An attempt to do so results in an error. This restriction exists because flashback database is currently unable to reverse the effects of increasing the database version with the compatibility initialization parameter.
担保型还原点：
与 常规还原点类似，一个担保型还原点作为SCN的别名在恢复操作中提供服务。其主要的区别在于担保型还原点永远不会在控制文件里老化，并且必须手动删除它 们。通常来说你可以将担保型还原点作为任何与还原点相关操作的SCN别名。除非另有注解，那些关于常规还原点在什么场合或者如何使用方面的信息，同样适用 与担保型还原点。
一个担保型还原点确保你可以使用数据库闪回来倒转数据库至还原点的SCN，甚至在闪回日志关闭的情况下。如果闪回日志是启用的，那么担保型还原点会强制保留闪回至它之后任何SCN所需的闪回日志。因此如果闪回日志启用了，你可以倒转数据库至任意连续的SCN而不是仅仅一个SCN。
（BOND:闪回日志关闭的情况下如何保证？下面说了）
警告：
如果闪回日志是关闭的，那么你不能使用FLASHBACK DATABSE直接到当前时间与担保型还原点之间的SCN，无论如何，你可以先闪回至担保型还原点，然后恢复至当前时间与担保型还原点之间的SCN。
（BOND: 可以理解为，在闪回日志关闭情况下，变化的数据块的就镜像仍然会被，但是仅仅会保存创建担保型还原点时SCN的块镜像，是不是又有点类似于增量备份的模式 呢：D，但是增量备份是保存变化后的数据块，而这里是保存数据块变化之前的最早镜像，可以理解这样的方式，磁盘、性能开销也应该最小。
这时候flashback_on的值为RESTORE POINT ONLY，但是无论如何，归档是必须打开的）
SQL> create restore point guarant_1 guarantee flashback database;create restore point guarant_1 guarantee flashback database*ERROR at line 1:ORA-38784: Cannot create restore point 'GUARANT_1'.ORA-38785: Media recovery must be enabled for guaranteed restore point.

Guaranteed Restore Points versus Storage Snapshots

In practice, guaranteed restore points provide a useful alternative to storage snapshots. Storage snapshots are often used to protect a database before risky operations such as large-scale database updates or application patches or upgrades. Rather than creating a snapshot or duplicate database to test the operation, you can create a guaranteed restore point on a primary or physical standby database. You can then perform the risky operation with the certainty that the required flashback logs are retained.
担保型还原点与存储设备镜像的对比
在 实 践中，担保型还原点提供了一种很有用且不同于存储设备镜像的方法。存储设备镜像常常用于保护数据库在有风险的操作诸如大规模的数据库升级或者应用补丁 或 者升级成功之前。与其创建镜像或者复制数据库来进行测试操作，不如创建一个担保型还原点在主库或者物理备库上。然后你可以在有足够闪回日志被保存的前 提下 执行风险性的操作。
（BOND:所以在数据库升级时，可以多加利用担保型还原点替代手动备份。）
Logging for Flashback Database and Guaranteed Restore Points
Logging for Flashback Database and guaranteed restore points involves capturing images of data file blocks before changes are applied. The FLASHBACK DATABASE command can use these images to return the data files to their previous state.
The chief differences between normal flashback logging and logging for guaranteed restore points are related to when blocks are logged and whether the logs can be deleted in response to space pressure in the fast recovery area. These differences affect space usage for logs and database performance.
Your recoverability goals partially determine whether to enable logging for flashback database, or use guaranteed restore points, or both. The implications in performance and in space usage for these features, separately and when used together, should also factor into your decision.
闪回日志与担保型还原点
闪回日志与担保型还原点包含了数据块变化的前镜像。FLASHBACK DATABASE命令可以使用这些镜像让数据文件回到他们之前的状态。
常规闪回日志记录与担保性还原点日志记录的主要的区别在关于何时数据块被日志记录与是否日志在闪回恢复区空间压力下是否能被删除。这些差别影响日志空间的使用与数据库的性能。
你“可恢复的”目标部分得决定了是否启用数据库闪回日志或者使用担保性还原点或者两者都用。在这些功能的性能与空间使用的含义上，分开且同时使用需要作为你决定的因素。

Guaranteed Restore Points and Fast Recovery Area Space Usage

The following rules govern creating, retaining, overwriting and deleting of flashback logs in the fast recovery area:
If the fast recovery area has enough space, then a flashback log is created whenever necessary to satisfy the flashback retention target.
If a flashback log is old enough that it is no longer needed to satisfy the flashback retention target, then a flashback log is reused.
If the database must create a flashback log and the fast recovery area is full or there is no disk space, then the oldest flashback log is reused instead.
Note:
Reusing the oldest flashback log shortens the flashback database window. If enough flashback logs are reused due to a lack of disk space, then the flashback retention target may not be satisfied.
If the fast recovery area is full, then an archived redo log that is reclaimable according to the fast recovery area rules may be automatically deleted by the fast recovery area to make space for other files. In this case, any flashback logs that would require the use of that redo log file for the use of FLASHBACK DATABASE are also deleted.
Note:
According to fast recovery area rules, a file is reclaimable when one of the following criteria is true:
The file is reported as obsolete and not needed by the flashback database. For example, the file is outside the DB_FLASHBACK_RETENTION_TARGET parameters. The file is backed up to tape.
No file in the fast recovery area is eligible for deletion if it is required to satisfy a guaranteed restore point. Thus, retention of flashback logs and other files required to satisfy the guaranteed restore point, in addition to files required to satisfy the backup retention policy, can cause the fast recovery area to fill completely. Consult "Responding to a Full Fast Recovery Area" if your fast recovery area becomes full.
When you create a guaranteed restore point, with or without enabling full flashback database logging, you must monitor the space available in your fast recovery area. "Managing Space for Flashback Logs in the Fast Recovery Area" explains how to monitor fast recovery area disk space usage.
Caution:
If no files are eligible for deletion from the fast recovery area because of the requirements imposed by your retention policy and the guaranteed restore point, then the database performs as if it has encountered a disk full condition. In many circumstances, this causes your database to halt. See "Responding to a Full Fast Recovery Area".
担保型还原点与闪回恢复区空间使用
以下的规则掌控着闪回恢复区内闪回日志的创建、保存、重写与删除：
如果闪回恢复区有足够的空间，然后闪回日志无论何时都会被创建来满足闪回保留目标。
如果一个闪回日志足够老，不再被“闪回保留目标”所需要，那么它会被重用。
如果数据库必须要创建闪回日志并且闪回恢复区的空间已经满或者磁盘没有空间，那么最旧的闪回日志会被重用
注意：
重用最旧的闪回日志会缩断“数据库闪回窗口”。如果由于磁盘空间不足导致很多闪回日志被重用了。那么很可能导致闪回保留目标不会被满足了。
如果闪回恢复区满了，然后按照闪回恢复区规则，那些可回收的归档日志可能会被删除以为其他文件腾出空间。在这种情况下，任何需要这些归档日志的闪回日志也会被删除。
注意：
按照闪回恢复区规则，一个文件当达到以下其中一个评判标准时，就是“可被回收”的：
1. 文件被报告为“废弃”并且不再被数据库闪回需要。例如，文件在参数DB_FLASHBACK_RETENTION_TARGET之外。文件被备份至了磁带。
2. 如果文件被用来保证满足“担保型还原点”，那么他在闪回恢复区是不会被删除的。因此，闪回日志与其他文件的的保留需要满足担保型还原点的需要。除此之外，文件也需要被保留来满足备份保留策略，会引起闪回恢复区被完全填满。
当你创建一个担保型还原点，同时启用或者没有启用数据库闪回日志，你必须监控你闪回恢复区的可用空间。
警告：
如果因为你的保留策略与担保型还原点，而没有文件从闪回恢复区删除，随后数据库可能会遇到磁盘满的情况。在很多境况下，这会导致数据库挂起！
（BOND：担保型还原点需要尽早删除）

Logging for Guaranteed Restore Points with Flashback Logging Disabled

Assume that you create a guaranteed restore point when logging for Flashback Database is disabled. In this case, the first time a data file block is modified after the time of the guaranteed restore point, the database stores an image of the block before the modification in the flashback logs. Thus, the flashback logs preserve the contents of every changed data block at the time that the guaranteed restore point was created. Later modifications to the same block do not cause the contents to be logged again unless another guaranteed restore point was created after the block was last modified.
This method of logging has the following important consequences:
FLASHBACK DATABASE can re-create the data file contents at the time of a guaranteed restore point by using the block images.
For workloads that repeatedly modify the same data, disk space usage can be less than normal flashback logging. Less space is needed because each changed block is only logged once. Applications with low volume inserts may benefit from this disk space saving. This advantage is less likely for applications with high volume inserts or large batch inserts. The performance overhead of logging for a guaranteed restore point without flashback database logging enabled can also be lower.
Assume that your primary goal is the ability to return your database to the time at which the guaranteed restore point was created. In this case, it is usually more efficient to turn off flashback logging and use only guaranteed restore points. For example, suppose that you are performing an application upgrade on a database host over a weekend. You could create a guaranteed restore point at the start of the upgrade. If the upgrade fails, then reverse the changes with the FLASHBACK DATABASE command.
没有启用闪回日志的担保型还原点
假 设你在数据库闪回日志禁用的情况下创建了一个担保型还原点，在此情况下，数据块在担保型还原点之后第一次被更改，数据库会保存在这个数据块修改之前的镜 像 到闪回日志。因此在担保型还原点创建的时候，闪回日志保存了每一个变化的数据块（的前镜像），随后同一个数据块的修改，不会导致其内容被又记录一次， 除非 另一个担保型还原点在它上一次修改之后创建。
（BOND：这里明确证实了我前面的设想，在闪回日志功能关闭的情况下，闪回日志仅会保存数据块的第一个旧镜像，即使该数据块被多次修改）
这种日志记录方式有以下重要的结果：
FLASHBACK_DATABSE 可以重建数据文件内容，在担保型还原点使用块镜像。
对 于 反复修改一个数据块的负载，其磁盘使用空间会比正常闪回日志小。需要更小的空间是因为每一个变化的数据块只会记录一次。应用程序小容量插入可能会受益 于 磁盘空间的节省，这个优势太可能体现在大量数据插入或者大批量插入。不启用日志功能的担保型还原点比启用日志功能的性能开销同样会低一些。
假设你的主要目标是你的数据库可以回到担保型还原点创建的那个时刻。在这种情况下，通常关闭闪回日志功能并且仅仅使用担保型还原点是更加高效的。例如，它可以支持你周末在数据库主机上进行应用的升级。你可以在升级之前创建一个担保型还原点。如果升级失败了，使用FLASHBACK DATABASE to restore point xxxx 命令来倒回所有的改变。

Logging for Flashback Database with Guaranteed Restore Points Defined

If you enable Flashback Database and define one or more guaranteed restore points, then the database performs normal flashback logging. In this case, the recovery area retains the flashback logs required to flash back to any arbitrary time between the present and the earliest currently defined guaranteed restore point. Flashback logs are not deleted in response to space pressure if they are required to satisfy the guarantee.
Flashback logging causes some performance overhead. Depending upon the pattern of activity on your database, it can also cause significant space pressure in the fast recovery area. Thus, you should monitor space used in the fast recovery area.

Prerequisites for Flashback Database and Guaranteed Restore Points

To ensure successful operation of Flashback Database and guaranteed restore points, you must first set several key database options.
启用了数据库闪回日志的担保型还原点
如果你启用了数据库闪回并且定义了一个或者更多的保障性还原点，那么数据库会进行常规的闪回日志记录。在这种情况下，用来闪回至当前与最早定义的担保型还原点之前任意时间点的日志会一直被保持。即使有磁盘空间压力，只要闪回日志需要被用于满足担保性，他们就不会被删除。

Flashback Database

Configure the following database settings before enabling Flashback Database:
Your database must be running in ARCHIVELOG mode, because archived logs are used in the Flashback Database operation.
You must have a fast recovery area enabled, because flashback logs can only be stored in the fast recovery area.
For Oracle Real Application Clusters (Oracle RAC) databases, the fast recovery area must be in a clustered file system or in ASM.
闪回数据库
你在启用闪回数据库功能之前，必须依照如下设定：
1. 你的数据库必须运行在归档日志模式下，因为归档日志需要使用在数据库闪回操作中。
2.你必须启用闪回恢复区，因为闪回日志只能放在闪回恢复区。
3. 在RAC系统中，闪回恢复区必须放在集群文件系统或者ASM中 （即共享存储中）
(BOND:闪回日志功能不一定开，但是归档是一定要打开的！）

Guaranteed Restore Points

To use guaranteed restore points, the database must satisfy the following additional prerequisite:
the COMPATIBLE initialization parameter must be set to 10.2.0 or greater
Note:
There are no special prerequisites to set before using normal restore points.
担保型还原点
为了使用担保型还原点，数据库必须满足下面的先决条件：COMPATIBLE参数值必须在10.2.0或者更高。
注明：
使用常规还原点没有特别的先决条件。

Using Normal and Guaranteed Restore Points

This section describes the various commands and monitoring capabilities you use with normal and guaranteed restore points.
这一章描述了你在使用常规与担保型还原点是用到的大多数命令与监控功能

Creating Normal and Guaranteed Restore Points

To create normal or guaranteed restore points, use the CREATE RESTORE POINT SQL statement, providing a name for the restore point and specifying whether it is to be a guaranteed restore point or a normal one (the default).
创建常规或者担保型还原点，使用CREATE RESTORE POINT 语句，为还原点提供一个名称，并且制定他是担保型还原点或者常规还原点。（默认是常规还原点）

To create a restore point:

Connect SQL*Plus to a target database.
Ensure that the database is open or mounted. If the database is mounted, then it must have been shut down cleanly (unless it is a physical standby database).
确保数据库是开启或者挂载状态。如果数据库已经挂载，那么它（之前）必须是被干净关闭的（除非它书物理备库）
Run the CREATE RESTORE POINT statement.
The following example shows how to create a normal restore point in SQL*Plus:
SQL> CREATE RESTORE POINT before_upgrade;
This example shows how to create a guaranteed restore point:
SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;

Listing Restore Points

You can use the LIST command to list either a specific restore point or all restore points known to the RMAN repository. The variations of the command are as follows:
你可以使用LIST命令来列出一个指定的还原点或者RMAN 资源库所记录的所有还原点。这个命令的变化使用如下所示：
LIST RESTORE POINT restore_point_name;
LIST RESTORE POINT ALL;
RMAN indicates the SCN and time of the restore point, the type of restore point, and the name of the restore point. The following example shows sample output:
RMAN标识了还原点的SCN与时间，与还原点的类型，还有还原点的名称。下面的例子展示了示例输出：
RMAN> LIST RESTORE POINT ALL;
 
using target database control file instead of recovery catalog
SCN              RSP Time  Type       Time      Name
---------------- --------- ---------- --------- ----
341859           28-JUL-06            28-JUL-06 NORMAL_RS
343690           28-JUL-06 GUARANTEED 28-JUL-06 GUARANTEED_RS

To see a list of all currently defined restore points (normal and guaranteed), use the V$RESTORE_POINT control file view with the following query:
为了查看目前所有定义的还原点（常规或者担保型的），使用 下面的语句查询V$RESTORE_POINT控制文件试图
SQL> SELECT NAME, SCN, TIME,
     DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE  
     FROM V$RESTORE_POINT;
The output from the view:
1.Name of each restore point (guaranteed and normal)
2.SCN
3.Time and database incarnation number when the restore points were created
4.Type of restore point (normal or guaranteed)
5.Amount of space in the fast recovery area being used to support information needed for Flashback Database operations for that restore point

For normal restore points, STORAGE_SIZE is zero. For guaranteed restore points, STORAGE_SIZE indicates the amount of disk space in the fast recovery area used to retain logs required to guarantee FLASHBACK DATABASE to that restore point.
对于常规还原点，STORAGE_SIZE是0，对于担保型还原点，STORAGE_SIZE标识了在闪回恢复区的磁盘使用空间用于保存日志来确保能闪回至还原点。

Dropping Restore Points

When you are satisfied that you do not need an existing restore point, or when you want to create a restore point with the name of an existing restore point, you can drop the restore point, using the DROP RESTORE POINT SQL*Plus statement. For example:
SQL> DROP RESTORE POINT before_app_upgrade;
Restore point dropped.
The same statement is used to drop both normal and guaranteed restore points.
Note:
Normal restore points eventually age out of the control file, even if not explicitly dropped. The rules governing retention of restore points in the control file are:
The most recent 2048 restore points are always kept in the control file, regardless of their age.
Any restore point more recent than the value of CONTROL_FILE_RECORD_KEEP_TIME is retained, regardless of how many restore points are defined.
Normal restore points that do not meet either of these conditions may age out of the control file.
Guaranteed restore points never age out of the control file. They remain until they are explicitly dropped.
注明：
常规还原点最终会在控制文件中老化，即使没有显示地删除。掌控控制文件中还原点保留的规则如下：
1.控制文件中会保存最近2048个还原点记录，与age无关。
2.任何还原点比CONTROL_FILE_RECORD_KEEP_TIME值更多的被保留，与多少还原点被定义了无关。
3.常规还原点
4.担保型还原点在控制文件内永远不会老化。他们会一直存在知道显示地删除它。

Enabling Flashback Database

Ensure the database instance is open or mounted. If the instance is mounted, then the database must be shut down cleanly unless it is a physical standby database. Other Oracle RAC instances can be in any mode.
Optionally, set the DB_FLASHBACK_RETENTION_TARGET to the length of the desired flashback window in minutes:
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320; # 3 days
By default DB_FLASHBACK_RETENTION_TARGET is set to 1 day (1440 minutes).
Enable the Flashback Database feature for the whole database:
ALTER DATABASE FLASHBACK ON;
Optionally, disable flashback logging for specific tablespaces.
By default, flashback logs are generated for all permanent tablespaces. You can reduce overhead by disabling flashback logging for specific tablespaces as in the following example:
ALTER TABLESPACE tbs_3 FLASHBACK OFF;
You can re-enable flashback logging for a tablespace later with this command:
ALTER TABLESPACE tbs_3 FLASHBACK ON;
If you disable Flashback Database for a tablespace, then you must take its datafiles offline before running FLASHBACK DATABASE.
When you enable Flashback Database while the database is open, there is a very small chance the command may not be able to obtain the memory it needs. If the command fails because of that reason, retry the command after a while or retry after a shutdown and restart of the instance.
When you enable Flashback Database on a physical standby database, you can flash back a standby database. Flashback Database of standby databases has some applications in the Data Guard environment. See Oracle Data Guard Concepts and Administration for details.
启用数据库闪回
确保数据库实例是打开或者挂载状态。如果实例是挂载状态，数据库必须被干净关闭除非它是物理备库。其他RAC实例可以是任意模式。（BOND：open时可以开启闪回）
可选的，设置DB_FLASHBACK_RETENTION_TARGET以分钟为期望的闪回窗口设置尺寸。默认是一天 （BOND: DB_FLASHBACK_RETENTION_TARGET不是必须的）
可以为整个数据库启用数据库闪回功能,可选地，为指定表空间关闭数据库闪回日志。
缺省情况下，闪回日志会为永久表空间收集，你可以通过对指定表空间禁用闪回日志的方式来减少系统开销。
如果你为表空间禁用了闪回功能，那么在执行 flashback之前，你必须要将其数据文件置为离线。（BOND： 单独禁用表空间闪回功能时需要注意这一点）
当你在数据库开启状态时启用数据库闪回功能，有很小的可能性，命令不能获得它需要的内存。如果命令因为这个原因失败，可以过一会儿再重试，或者关闭并重启实例后重试
（BOND：open状态下不能获得内存，具体应该指的RVWR所用的内存，在SGA区域的里）

Disabling Flashback Database Logging

On a database instances that is either in mount or open state, issue the following command:
ALTER DATABASE FLASHBACK OFF;
 
Configuring the Environment for Optimal Flashback Database Performance
Maintaining flashback logs imposes comparatively limited overhead on an database instance. Changed blocks are written from memory to the flashback logs at relatively infrequent, regular intervals, to limit processing and I/O overhead.
To achieve good performance for large production databases with Flashback Database enabled, Oracle recommends the following:
Use a fast file system for your fast recovery area, preferably without operating system file caching.
Files that the database creates in the fast recovery area, including flashback logs, are typically large. Operating system file caching is typically not effective for these files, and may actually add CPU overhead for reading from and writing to these files. Thus, it is recommended to use a file system that avoids operating system file caching, such as ASM.
为数据库闪回的优异性能配置环境
维护闪回日志强行实施对数据库比较有限的开销。改变的数据块以相对较少，固定的间隔被从内存写入闪回日志，以减少处理量与IO开销。
为了让大型生产数据库在启用数据库闪回时，达到好的性能，Oracle建议如下：
使用快速文件系统作为你的闪回恢复区，最好是不使用操作系统缓存。
闪回恢复区里的数据库创建的文件，包括闪回日志，通常都很大。操作系统文件缓存通常对这些文件是无效的，并且实际上可能增加CPU在读取与写入这些文件时的开销。因此，推荐使用一种避免操作系统文件缓存的文件系统，例如ASM。

Configure enough disk spindles for the file system that holds the fast recovery area.

For large production databases, multiple disk spindles may be needed to support the required disk throughput for the database to write the flashback logs effectively.
If the storage system used to hold the fast recovery area does not have nonvolatile RAM, then try to configure the file system on striped storage volumes.
Use a relatively small stripe size such as 128 KB. This technique enables each write to the flashback logs to be spread across multiple spindles, improving performance.
For large databases, set the initialization parameter LOG_BUFFER to at least 8 MB.
The overhead of logging for Flashback Database depends on the mixture of reads and writes in the database workload. When you have a write-intensive workload, the Flashback Database logging overhead is high since it must log all those database changes. Queries do not change data and thus do not contribute to logging activity for Flashback Database.
为文件系统配置足够的“disk spindles”以容纳闪回恢复区
对于大型生产数据库，多个”disk spindles”能够让闪回日志高效地写入。
如果用来保存闪回恢复区的存储系统没有“不易丢失的内存”，那么就尝试为存储系统配置条带化。
使用相对较小的sripe size例如128k。这项技术允许每次闪回日志的写入可以贯穿多个磁盘，提升性能。
对于大型数据库，设置初始化参数LOG_BUFFER至少为8M。
数据库闪回日志的开销取决于数据库中读写混合的负载。当你有write-intensive负载时，数据库闪回日志的开销会很高，因为它必须记录所有数据库的改变。查询不会改变数据块，因此不会促进数据库闪回的日志记录活动。

Monitoring the Effect of Flashback Database on Performance

The Automatic Workload Repository (AWR) automates database statistics gathering by collecting, processing, and maintaining performance statistics for database problem detection and self-tuning. There are several data analysis methods for monitoring the Flashback Database workload on your system. For example, you can compare AWR reports from before and after the Flashback Database was turned on. You can also review AWR snapshots to pinpoint system usage caused by flashback logging. For example, if flashback buf free by RVWR is the top wait event, then you know that Oracle Database cannot write flashback logs very quickly. Therefore, you might want to tune the file system and storage used by the fast recovery area, possibly using a technique described in "Configuring the Environment for Optimal Flashback Database Performance".
监控数据库闪回在性能上的影响
AWR自动化收集数据库性能信息用于故障检测与自我调整。在系统中监控闪回数据库性能有几种数据分析方式。例如，你可以比较数据库闪回开启之前与之后的AWR报告。

The V$FLASHBACK_DATABASE_STAT view shows the bytes of flashback data logged by the database. Each row in the view shows the statistics accumulated (typically over the course of an hour). The FLASHBACK_DATA and REDO_DATA columns describe bytes of flashback data and redo data written respectively during the time interval, while the DB_DATA column describes bytes of data blocks read and written. The columns FLASHBACK_DATA and REDO_DATA correspond to sequential writes, whereas DB_DATA column corresponds to random reads and writes.
Because of the difference between sequential I/O and random I/O, a better indication of I/O overhead is the number of I/O operations issued for flashback logs. The V$SYSSTAT statistics shown in Table 7-1 can tell you the number of I/O operations that your instance has issued for various purposes.
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

Flashback Writer (RVWR) Behavior with I/O Errors

When flashback is enabled or when there are guaranteed restore points, the background process RVWR writes flashback data to flashback database logs in the fast recovery area. If RVWR encounters an I/O error, then the following behavior is expected:
If there are any guaranteed restore points defined, then the instance fails when RVWR encounters I/O errors.
If no guaranteed restore points are defined, then the instance remains unaffected when RVWR encounters I/O errors.
 Note the following cases:
On a primary database, Oracle Database automatically disables Flashback Database while the database is open. All existing transactions and queries proceed unaffected. This behavior is expected for both single-instance and Oracle RAC databases.
On a physical or logical standby, RVWR appears to have stopped responding, retrying the I/O periodically. This may eventually cause the logical standby or the managed recovery of the physical standby to suspend. (Oracle Database does not cause the standby instance to fail because it does not want to cause the primary database to fail in maximum protection mode.) To resolve the issue, you can issue either a SHUTDOWN ABORT or an ALTER DATABASE FLASHBACK OFF command.
当RVWR遇到IO错误
当数据库闪回启用或者有担保型还原点时，后台进程RVWR将闪回数据写入闪回恢复区的闪回日志中。如果RVWR遭遇IO错误，那么会发生以下的行为：
1. 如果有任何的担保型还原点被定义了，那么在遭遇IO错误时实例会失效。
2. 如果没有保障型还原点被定义，那么实例不会受RVWR遭遇IO错误的影响而继续存在。
注意下面的情况:
1.在主库，oracle在open状态下，会自动禁用数据库闪回。所有正在进行的事务与查询过程不会受影响。这一行为适用于单实例与RAC。
2.在物理或者逻辑备库，RVWR似乎会停止响应，并循环重试IO。这可能最终导致逻辑备库或者物理备库的恢复管理被挂起。（Oracle不会让备库实例失效，因为在最大保护模式中不想让主库失效）。
处理这个问题，你可以使用shutdown abort或者alter database flashback off命令。