一.FlashbackDatabase 和 Restore Points 说明

OracleFlashback Database and restore points are related data protectionfeatures that allow you to rewind data back in time tocorrect any problems caused by logical data corruption or user errors within adesignated time window.

These featuresprovide a more efficient alternative to point-in-time recovery and does notrequire a backup of the database to be restored first. The effects are similarto databasepoint-in-time recovery (DBPITR).

Flashback Database and restore points are not only effectivein traditional database recovery situations but can also be useful duringdatabase upgrades, application deployments and testing scenarios when test databasesmust be quickly created and recreated. FlashbackDatabase also provides an efficient alternative to rebuilding a failed primarydatabase after a Data Guard failover.

Flashback Database 和 restore points 都可以提供一个基于时间点的回滚，类似与RMAN 的 point-in-time recovery，但是这两种方法与RMAN 的区别是在恢复的速度上，当我们在database upgrade 或者快速创建测试环境的时候就可以使用这种技术，因为等我们升级遇到问题或者测试完成，还可以恢复我们之前的时间点。

Restore pointsprovide capabilities related to Flashback Database and other media recoveryoperations. In particular, a guaranteed restore point created at an systemchange number (SCN) ensures that you can use Flashback Database to rewind thedatabase to this SCN. You can use restore points andFlashback Database independently or together.

Restore Points 和 Flashback Database 可以分开使用也可以一起使用。

FlashbackDatabase is accessible through the RMANcommand FLASHBACK DATABASE or the SQLstatement 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:

FLASHBACKDATABASE TO RESTORE POINT 'before_upgrade';

FLASHBACK DATABASETO SCN 202381;

1.1 Flashback Database

Flashback Database is accessible through the RMAN command and SQL statement FLASHBACKDATABASE. You can use either command to quickly recover the database fromlogical data corruptions or user errors.

Flashback Database is similar to conventional point-in-time recoveryin its effects. It enables you to return a database to its state at a time inthe recent past. Flashback Database is much faster thanpoint-in-time recovery because it does not require restoring datafiles frombackup and requires applying fewer changes from the archived redo logs.

--Flashback database 不需要restore database，所以它恢复的速度比较块。

You can use Flashback Database to reverse most unwanted changes to a database if thedatafiles are intact. You can return a database to its state in aprevious incarnation,and undo the effects of an ALTERDATABASE OPEN RESETLOGS statement. "Rewindinga Database with Flashback Database" explains how to usethe FLASHBACK DATABASE command to reverse database changes.

Flashback Database uses its own logging mechanism, creating flashbacklogs and storing them in the fastrecovery area. You can only use Flashback Database if flashback logs areavailable. To take advantage of this feature, you must set up your database inadvance to create flashback logs.

--Flashback Database 与Point-in-time recover 的机制不同，它是基于Flashback logs，默认情况下，没有启用Flashback Database，当启用之后，会创建Flashback log，并存放在FastRecovery Area。启用该弄能会给DB带来一定的负担，所以一把不启用该功能。

To enable Flashback Database, you configure a fast recovery area and set a flashbackretention target. This retention target specifies how far back you canrewind a database with Flashback Database.

From that timeonwards, at regular intervals, the database copies images of each altered blockin every datafile into the flashback logs. These block images can later bereused to reconstruct the datafile contents for any moment at which logs werecaptured.

--当启用Flashback Database 之后，DB 会每个一段时间copy一份datafile 中修改的block的镜像到FRA中。如果需要使用FlashbackDatabase 进行rewind 操作，就会使用这些images 文件。

When you useFlashback Database to rewind a database to a past target time, the commanddetermines which blocks changed after the target time and restores them fromthe flashback logs. The database restores the version of each block that is immediatelyprior to the target time. The database then uses redo logs to reapply changesthat were made after these blocks were written to the flashback logs.

--Flashback Database 机制每隔一段时间就会创建一次images，这里记录了block的改变的转台，当进行闪回时，先恢复到对应target time，即我们的之前的某个镜像上，然后根据redo log，重新应用redo log，将数据恢复到我们指定的闪回的时间点上。

Redo logs ondisk or tape must be available for the entire time period spanned by theflashback logs. For example, if the flashback retention target is 1 week, thenyou must ensure that online and archived redo logs that contain all changes forthe past week are accessible. In practice, redo logs are typically needed muchlonger than the flashback retention target to support point-in-time recovery.

1.2 Flashback Database Window

The range of SCNs for which there is currently enough flashback log data to supportthe FLASHBACK DATABASE command is called the flashbackdatabase window. The flashback database window cannot extend further backthan the earliest SCN in the available flashback logs.

You cannot back up flashback logs to locations outside thefast recovery area. To increase the likelihood thatenough flashback logs are retained to meet the flashback database window, youcan increase the space in your fast recovery area (see "InitializationParameters for the Fast Recovery Area").

If the fast recovery area is not large enough to hold the flashback logs and files such asarchived redo logs and other backups needed for the retention policy, then thedatabase may delete flashback logs from the earliest SCNs forward to make roomfor other files. Consequently, the flashback databasewindow can be shorter than the flashback retention target, depending onthe size of the fast recovery area, other backups that must be retained, andhow much flashback logging data is needed. The flashback retention target is atarget, not a guarantee that Flashback Database is available.

If you cannot use FLASHBACK DATABASE because the flashback database window is notlong enough, then you can use database point-in-time recovery (DBPITR) in mostcases to achieve a similar result. Guaranteed restorepoints are the only way to ensure that you can use Flashback Database to returnto a specific point in time or guarantee the size of the flashback window.

1.3 Limitations of Flashback Database

Because Flashback Database works by undoing changes to the datafilesthat exist at the moment when you run the command, it has the followinglimitations:

(1) Flashback Database can onlyundo changes to a datafile made by Oracle Database. It cannot be used to repairmedia failures, or to recover from accidental deletion of datafiles.

(2) You cannot use FlashbackDatabase to undo a shrink datafile operation. However, you can take theshrunken file offline, flash back the rest of the database, and then laterrestore and recover the shrunken datafile.

(3) You cannot use FlashbackDatabase alone to retrieve a dropped datafile. If you flash back a database toa time when a dropped datafile existed in the database, only the datafile entryis added to the control file. You can only recover the dropped datafile byusing RMAN to fully restore and recover the datafile.

(4) If the database control file isrestored from backup or re-created, all accumulated flashback log informationis discarded. You cannot use FLASHBACK DATABASE to return to a pointin time before the restore or re-creation of a control file.

(5) When using Flashback Databasewith a target time at which a NOLOGGING operation was in progress,block corruption is likely in the database objects and datafiles affected bytheNOLOGGING operation. For example, if you perform adirect-path INSERT operation in NOLOGGING mode, and thatoperation runs from 9:00 to 9:15 on April 3, 2005, and you later use FlashbackDatabase to return to the target time 09:07 on that date, the objects anddatafiles updated by the direct-path INSERT may be left with blockcorruption after the Flashback Database operation completes.

If possible,avoid using Flashback Database with a target time or SCN that coincides witha NOLOGGING operation. Also, perform a full or incremental backup ofthe affected datafiles immediately after any NOLOGGING operation toensure recoverability to points in time after the operation. If you expect touse Flashback Database to return to a point in time during an operation such asa direct-path INSERT, consider performing the operationin LOGGING mode.

1.4 Normal RestorePoints

Creating a normalrestore point assigns a restore point name to an SCN or specific pointin 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 anormal restore point. The control file stores the nameof the restore point and the SCN.

--对于Normal Restore Points， point的名称和SCN 保存在控制文件里。

If you use flashback features or point-in-time recovery, then you can use the name of therestore point instead of a time or SCN. The following commands support this useof restore points:

(1) The RECOVERDATABASE and FLASHBACK DATABASE commands in RMAN

(2) The FLASHBACKTABLE statement in SQL

Creating anormal restore point eliminates manually recording an SCN in advance ordetermine the correct SCN after the fact by using features such as FlashbackQuery.

Normal restore points are lightweight. The control file can maintain a record of thousands of normalrestore points with no significant effect on database performance. Normal restore points eventually age out of the control fileif not manually deleted, so they require no ongoing maintenance.

--Normal restore points 信息保存在控制文件中，属轻量级别，即使我们没有手工的删除这些points 信息，控制文件也会有删除这些信息，所以对于Normal restore points，我们不要其他的维护操作。

Restore Point 同Flashback Database 一样，也会产生image 文件，在没有启用FD的情况下，只在开始时创建一次image，并保存在FRA中。这点下文有说明。

控制文件保留Restore Points 的2点注意：

(1) The most recent 2048 restorepoints are always kept in the control file, regardless of their age.

(2) Any restore point more recentthan the value of CONTROL_FILE_RECORD_KEEP_TIME is retained,regardless of how many restore points are defined.

1.5 Guaranteed Restore Points

Like a normalrestore point, a guaranteedrestore point serves as an alias for an SCN in recovery operations. A principal difference is that guaranteed restore pointsnever age out of the control file and must be explicitly dropped. Ingeneral, you can use a guaranteed restore point as an alias for an SCN with anycommand that works with a normal restore point. Except as noted, theinformation about where and how to use normal restore points applies toguaranteed restore points as well.

--Guaranteed restore points 的信息也是保存在控制文件里的，本质的不同是Guaranteedrestore points 不会自动的删除，必须手工的清除这些信息。

A guaranteed restorepoint ensures that you can use Flashback Database to rewind a database to itsstate at the restore point SCN, even if the generation of flashbacklogs is disabled. If flashback logging is enabled, then a guaranteedrestore point enforces the retention of flashback logs required for FlashbackDatabase to any SCN after the earliest guaranteed restore point. Thus, ifflashback logging is enabled, you can rewind the database to any SCN in thecontinuum rather than to a single SCN only.

--如果我们创建了Guaranteed restore point，那么即使我们没有启用Flashback Database，那么我也可以恢复到我们创建的point。但如果我们同时启用了Flashback Database，那么guaranteed restorepoint 会强制保留从那个point 依赖的flashback log 文件。这样我们就会rewind从我们创建point 以来的任一个SCN。

一句话表示，就是在不启用FlashbackDatabase 的情况下， Guaranteed restore point 只能rewind到我们创建的点对应的SCN.

If the recoveryarea has enough disk space to store the needed logs, then you can use aguaranteed restore point to rewind a whole database to a known good state daysor weeks ago. As with Flashback Database, even the effectsof NOLOGGING operations like direct load inserts can be reversed withguaranteed restore points.

1.6 Guaranteed Restore Points versus Storage Snapshots

In practice, guaranteed restore points provide a usefulalternative to storage snapshots. Storage snapshots are often used to protect adatabase before risky operations such as large-scale database updates orapplication patches or upgrades. Rather than creating a snapshot or duplicatedatabase to test the operation, you can create a guaranteed restorepoint on a primary or physicalstandby database. You can then perform the risky operation with thecertainty that the required flashback logs are retained.

1.7 Logging for Flashback Database and Guaranteed RestorePoints

Logging forFlashback Database and guaranteed restore points involves capturing images ofdatafile blocks before changes are applied.The FLASHBACK DATABASE command can use these images to returnthe datafiles to their previous state.

The chiefdifferences between normal flashback logging and logging for guaranteed restorepoints are related to when blocks are logged and whether the logs can bedeleted in response to space pressure in the fast recovery area. Thesedifferences affect space usage for logs and database performance.

Yourrecoverability goals partially determine whether to enable logging forflashback database, or use guaranteed restore points, or both. The implicationsin performance and in space usage for these features, separately and when usedtogether, should also factor into your decision.

1.7.1 Guaranteed RestorePoints and Fast Recovery Area Space Usage

The following rules govern creating, retaining, overwriting and deleting of flashback logs inthe fast recovery area:

(1) If the fast recovery area hasenough space, then a flashback log is created whenever necessary to satisfy theflashback retention target.

(2) If a flashback log is oldenough that it is no longer needed to satisfy the flashback retention target,then a flashback log is reused.

(3) If the database must create anew flashback log and the fast recovery area is full or there is no disk space,then the oldest flashback log is reused instead.

(4) automatically deleted by thefast recovery area to make space for other files. In this case, any flashbacklogs that would require the use of that redo log file for the useof FLASHBACK DATABASE are also deleted.

(5) No file in the fast recoveryarea is eligible for deletion if it is required to satisfy a guaranteed restorepoint. Thus, retention of flashback logs and other files required to satisfythe guaranteed restore point, in addition to files required to satisfy thebackup retention policy, can cause the fast recovery area to fill completely.Consult "Respondingto a Full Fast Recovery Area" if your fast recovery area becomesfull.

When you createa guaranteed restore point, with or without enabling full flashback databaselogging, you must monitor the space available in your fast recovery area. "ManagingSpace for Flashback Logs in the Fast Recovery Area" explains howto monitor fast recovery area disk space usage.

1.7.2 Logging for Guaranteed Restore Points with FlashbackLogging Disabled

Assume that youcreate a guaranteed restore point when logging for Flashback Database isdisabled. In this case, the first time a datafile block is modified after thetime of the guaranteed restore point, the database stores an image of the blockbefore the modification in the flashback logs. Thus, the flashback logspreserve the contents of every changed data block at the time that theguaranteed restore point was created. Later modifications to the same block donot cause the contents to be logged again unless another guaranteed restorepoint was created after the block was last modified.

--当我们创建了一个Guaranteed Restore Points，并且我们没有启动Flashback Database，那么在这种情况下，DB 会也会创建一个block 的镜像，并存在FRA空间里，这个和FlashbackDatabase 的一致，那么不同的时，Flashback Database 会每隔一段时间创建一个block的image，而RestorePoints 只在开始时创建一次，那么恢复的时候也就只能恢复到这个时间点。

这里要注意一点，我们创建Restore Point的名称和对应的SCN是保存在控制文件里的，这点前面有说明。

This method of logging has the following important consequences:

(1) FLASHBACK DATABASE canre-create the datafile contents at the time of a guaranteed restore point bymeans of the block images.

(2) For workloads that repeatedlymodify the same data, disk space usage can be less than normal flashbacklogging. 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 orlarge batch inserts. The performance overhead of logging for a guaranteedrestore point without flashback database logging enabled can also be lower.

Assume that yourprimary goal is the ability to return your database to the time at which theguaranteed restore point was created. In this case, it is usually moreefficient to turn off flashback logging and use only guaranteed restore points.For example, suppose that you are performing an application upgrade on adatabase host over a weekend. You could create a guaranteed restore point atthe start of the upgrade. If the upgrade fails, then reverse the changes withthe FLASHBACK DATABASE command.

在不启用Flashback Database 的情况下，我们创建Guaranteed Restore Points，只创建一次image，那么会节省很多的FRA空间，这种方法在对数据库进行升级的时候很有用，在升级之前我们创建一次Guaranteed Restore Point，然后升级DB，如果升级失败，我们回退，如果升级生成，我们删除Restore Point。

1.7.3 Logging forFlashback Database with Guaranteed Restore Points Defined

If you enableFlashback Database and define one or more guaranteed restore points, then thedatabase performs normal flashback logging. In this case, the recovery arearetains the flashback logs required to flash back to any arbitrary time betweenthe present and the earliest currently defined guaranteed restore point.Flashback logs are not deleted in response to space pressure if they arerequired to satisfy the guarantee.

Flashback logging causes some performance overhead. Depending upon the pattern ofactivity on your database, it can also cause significant space pressure in thefast recovery area. Thus, you should monitor space used in the fast recoveryarea.

1.8 Prerequisites for Flashback Database and Guaranteed Restore Points

To ensuresuccessful operation of Flashback Database and guaranteed restore points, youmust first set a number of key database options.

1.8.1 Flashback Database

Configure the following database settingsbefore enabling Flashback Database:

(1) Your database must be runningin ARCHIVELOG mode, because archived logs are used in the FlashbackDatabase operation.

(2) You must have a fast recoveryarea enabled, because flashback logs can only be stored in the fast recoveryarea.

(3) For Oracle Real ApplicationClusters (Oracle RAC) databases, the fast recovery area must be in a clusteredfile system or in ASM.

1.8.2 Guaranteed Restore Points

To use guaranteed restore points, thedatabase must satisfy the following additional prerequisite: the COMPATIBLE initializationparameter must be set to 10.2.0 or greater

二.Flashback Database 和 Restore Points 语法

2.1 Using Flashback Database

This section describes the basic commands for Flashback Database. It also lists guidelinesto ensure optimal performance of Flashback Database.

2.1.1 Enabling Flashback Database

Follow these are the steps to enableFlashback Database.

To enable flashback logging:

（1）Ensure thedatabase instance is open or mounted. If the instance is mounted, then thedatabase must be shut down cleanly unless it is a physical standby database.Other Oracle RAC instances can be in any mode.

（2）Optionally,set the DB_FLASHBACK_RETENTION_TARGET to the length of the desiredflashback window in minutes:

ALTER SYSTEM SETDB_FLASHBACK_RETENTION_TARGET=4320; # 3 days

Bydefault DB_FLASHBACK_RETENTION_TARGET is set to 1 day (1440 minutes).

（3）Enable theFlashback Database feature for the whole database:

ALTER DATABASE FLASHBACK ON;

（4）Optionally,disable flashback logging for specific tablespaces.

By default,flashback logs are generated for all permanent tablespaces. You can reduceoverhead by disabling flashback logging for specific tablespaces as in thefollowing example:

ALTER TABLESPACEtbs_3 FLASHBACK OFF;

You can reenable flashback logging for atablespace later with this command:

ALTER TABLESPACEtbs_3 FLASHBACK ON;

If you disable Flashback Database for atablespace, then you must take its datafiles offline beforerunning FLASHBACK DATABASE.

When you enableFlashback Database while the database is open, there is a very small chance thecommand may not be able to obtain the memory it needs. If the command failsbecause of that reason, retry the command after a while or retry after ashutdown and restart of the instance.

When you enableFlashback Database on a physicalstandby database, you can flash back a standby database. Flashback Databaseof standby databases has a number of applications in the Data Guardenvironment. See OracleData Guard Concepts and Administration for details.

2.1.2 Disabling Flashback Database Logging

On one of thedatabase instances that is either in mount or open state, issue the following command:

ALTER DATABASEFLASHBACK OFF;

2.2 Using Normal and Guaranteed Restore Points

This sectiondescribes the various commands and monitoring capabilities you use with normaland guaranteed restore points.

2.2.1 Creating Normal and Guaranteed Restore Points

To create normal or guaranteed restorepoints, use the CREATERESTORE POINT SQL statement, providing a name for the restore pointand specifying whether it is to be a guaranteed restore point or a normal one (the default).

To create a restore point:

（1）Connect SQL*Plus to a targetdatabase.

（2）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).

--如果是mount状态来创建point，那么这个必须是shutdown cleanly 之后的mount，如果是非cleanshutdown，那么在下次启动时需要进行recover 操作，这样就不能创建point。

Oracle 实例恢复时前滚（roll forward）后滚（rollback）问题

Oracle 实例恢复时前滚（roll forward）后滚（roll back）问题_Dave的博客-CSDN博客

（3）Run the CREATE RESTOREPOINT statement.

The following example shows how to create anormal restore point in SQL*Plus:

SQL> CREATE RESTORE POINTbefore_upgrade;

This example shows how to create aguaranteed restore point:

SQL> CREATE RESTORE POINT before_upgradeGUARANTEE FLASHBACK DATABASE;

2.2.2 ListingRestore Points

You can use the LIST command to list either a specificrestore point or all restore points known to the RMAN repository. Thevariations of the command are as follows:

LIST RESTORE POINT restore_point_name;

LIST RESTORE POINT ALL;

RMAN indicatesthe SCN and time of the restore point, the type of restore point, and the nameof the restore point. The following example shows sample output:

RMAN> LIST RESTORE POINT ALL;

using target database control file insteadof recovery catalog

SCN RSP Time Type Time Name

---------------- --------- ------------------- ----

341859 28-JUL-06 28-JUL-06 NORMAL_RS

343690 28-JUL-06 GUARANTEED 28-JUL-06GUARANTEED_RS

To see a list ofall currently defined restore points (normal and guaranteed), usethe V$RESTORE_POINT control file view, by means of the followingquery:

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 incarnationnumber when the restore points were created

(4) Type of restore point (normalor guaranteed)

(5) Amount of space in the flashrecovery area being used to support information needed for Flashback Databaseoperations for that restore point

For normal restore points, STORAGE_SIZE is zero. For guaranteed restorepoints, STORAGE_SIZE indicates the amount of disk space in the flashrecovery area used to retain logs required toguarantee FLASHBACK DATABASE to that restore point.

2.2.3 Dropping Restore Points

When you are satisfied that you do not need an existing restore point, or when you want tocreate a new restore point with the name of an existing restore point, you can drop the restore point, using the DROP RESTORE POINT SQL*Plusstatement.

For example:

SQL> DROP RESTORE POINTbefore_app_upgrade;

Restore point dropped.

The same statement is used to drop bothnormal 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:

(1) The most recent 2048 restorepoints are always kept in the control file, regardless of their age.

(2) Any restore point more recentthan 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 controlfile.

Guaranteed restore points never age out of the control file. They remain until they areexplicitly dropped.

三. RestorePoints 示例

3.1 先创建restore point

--有关Flashback的相关参数：

SQL> show parameter db_recovery_file_dest

NAME TYPE VALUE

----------------------------------------------- ------------------------------

db_recovery_file_dest string D:\app\Administrator\flash_rec overy_area

db_recovery_file_dest_size big integer 1300M

SQL> show parameter db_flashback

NAME TYPE VALUE

----------------------------------------------- ------------------------------

db_flashback_retention_target integer 1440

SQL> select flashback_on from v$database;

FLASHBACK_ON

------------------

--创建restore point

SQL>startup mount

SQL> create restore point upgrade_pointguarantee flashback database;

Restore point created.

SQL>shutdown immediate

注意：

如果数据库的Flashback database 没有打开，那么只能在mount 状态下进行创建。

如果是Open 状态执行，创建完之后，DB 会变成mount状态。

--查看我们创建的restore point

RMAN> list restore point all;

SCN RSP Time Type Time Name

---------------- --------- ------------------- ----

1316268211 GUARANTEED 29-OCT-11UPGRADE_POINT

3.2 执行操作

如果是升级，这里就执行升级的脚本

SQL>startup upgrade

SQL>@?/rdbms/admin/catupgrd.sql

SQL>shutdown immediate

SQL>startup

SQL>@?/rdbms/admin/utlrp.sql

这里我们就不执行，我们创建一个表，演示一下效果。

SQL> select open_mode from v$database;

OPEN_MODE

--------------------

READ WRITE

SQL> create table d1(id number);

Table created.

SQL> insert into d1 values(1);

1 row created.

SQL> insert into d1 values(2);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from d1;

----------

3.3 如果失败，就进行回滚

注意：执行Flashback Database时，DB 不能处于open状态.

SQL> shutdown immediate

SQL> startup mount;

SQL> select open_mode from v$database;

OPEN_MODE

--------------------

MOUNTED

SQL> select flashback_on from v$database;

FLASHBACK_ON

------------------

RESTORE POINT ONLY

SQL> flashback database to restore point upgrade_point;

Flashback complete.

SQL> alter database open;

alter database open

ERROR at line 1:

ORA-01589: must use RESETLOGS orNORESETLOGS option for database open

--提示必须用Resetlogs打开：

SQL> alter database open resetlogs;

Database altered.

--查看我们之前的创建的表：D1

SQL> select * from d1;

select * from d1

ERROR at line 1:

ORA-00942: table or view does not exist

提示我们表不存在，数据闪回到了我们之前的Restore Point了。用resetlogs 打开DB 之后记得重新备份一下数据库。

3.4如果升级成功，我们直接删除restore point即可

SQL> drop restore point upgrade_point;

Restore point dropped.

用RMAN 验证：

RMAN> list restore point all;

using target database control file insteadof recovery catalog

SCN RSP Time Type Time Name

---------------- --------- ------------------- ----

RMAN>

已经为空。

基于Restore Points的方法，还可以将standby库临时激活到读写状态进行测试，测试完成后，在还原到之前的状态。这种方法的步骤，参考如下链接：

------------------------------------------------

[Oracle] 闪回数据库真的需要开闪回日志？

1. 容易陷入的知识盲区：闪回数据库

原来闪回数据库可不用闪回日志！！

官方文档有非常详细的说明：https://docs.oracle.com/cd/E18283_01/backup.112/e10642/flashdb.htm#insertedID0

2. 闪回数据库的局限性

因为闪回数据库通过撤消对运行命令时存在的数据文件的更改来工作，所以它具有以下限制：

闪回数据库只能撤消对Oracle数据库所做的数据文件的更改。它不能用于修复介质故障或从意外删除数据文件中恢复。
不能使用闪回数据库撤消收缩数据文件操作。但是，您可以使缩小的文件脱机，闪回数据库的其余部分，然后在以后还原和恢复缩小的数据文件。
不能单独使用闪回数据库来找回被删除的数据文件。如果将数据库闪回至数据库中存在删除的数据文件的时间，则仅将数据文件条目添加到控制文件中。您只能通过使用RMAN完全还原和恢复数据文件来恢复已删除的数据文件。
如果从备份还原数据库控制文件或重新创建数据库控制文件，则所有累积的闪回日志信息都将被丢弃。您不能用于FLASHBACK DATABASE返回到还原或重新创建控制文件之前的时间点。
在NOLOGGING执行操作的目标时间使用闪回数据库时，受NOLOGGING操作影响的数据库对象和数据文件中的块损坏很可能会发生。

3. Normal闪回点

我们创建闪回点有两种：Normal和Guaranteed，比如：

create restore point BEFORE_UPGRADE {guarantee flashback database};

Normal restore point相当于某个时间点或者SCN的一个别名。

restore point的名字和对应的SCN会保存在控制文件中。
创建了normal restore point后，如果需要执行RMAN中的RECOVER DATABASE和FLASHBACK DATABASE命令，FLASHBACK TABLE的SQL语句，就可以制定目标时间点为该normal restore point，而不需要指定当时的SCN了。从而消除预先手动记录SCN或事后使用Flashback Query之类的功能确定正确的SCN的麻烦。
normal还原点是轻量级的。控制文件可以保留数千个normal还原点的记录，而对数据库性能没有重大影响。如果不手动删除，normal还原点最终会在控制文件中老化，因此它们不需要进行持续的维护。
创建normal restore point仅仅是创建了SCN的一个别名，甚至不需要开归档和开闪回日志，当然这样就无法闪回数据库了。

4. Guaranteed闪回点

Guaranteed restore point的功能和normal restore point的功能基本一致，也是作为SCN的一个别名。主要区别在于，Guaranteed还原点永远不会超出控制文件的范围，因此必须明确地将其删除。
即使数据库没有启用flashback database日志, 也可以创建一个guaranteed restore point，它可以保证能将数据库flashback到该点。因为在创建guaranteed restore point后，对于任何block的第一次变更，都会将其前镜像整个的记录下来(快速恢复区)。以后对同一块的修改不会导致再次记录该内容，除非在最后一次修改该块之后创建了另一个guaranteed restore point。FRA区还是会创建flashback log 但是只是保留一个最初始的镜像，后面在这个块上再改动就不需要记录了。就相当于一次性UNDO。
如果系统启用了flashback database日志，那么guaranteed restore point可以保证能将数据库flashback到guaranteed restore point之后的任何时间点。

完全可以不开启数据库闪回功能，只需要开归档后，就可以创建guaranteed restore point，这样只会产生很少量的闪回数据（就是初次修改前的块镜像）。

5. 闪回数据库为什么需要归档

Flashback Logs contain old versions of Oracle Blocks. But not every Block Modifications leads to the generation of Flashback Logs. Therefore, if you do a flashback database operation, you will never reach exactly the point in time in the past with flashback logs only. You 'grow your datafiles older' than the point in time you want to reach (very much faster than a complete restore from backup would achieve the same). The rest is then recovered with Redo Protocol from Archivelogs or Online Logs. Basically, flashback database does 2 steps under the cover:

make datafiles sufficiently old with old blocks from flashback logs

recover with redo protocol to the exact point in time you want to get to

我自已还有一个想法：数据库不是实时落盘的，所以数据文件可能缺乏最新的已提交块内容，也可能包含了未提交的块内容。当我们创建数据库闪回点后，块内容不一致，闪回日志可以帮我们将块闪回到一开始的状态，但还需要当时的归档日志来前滚和回滚（利用当时的undo表空间）。

当然闪回数据库的操作不是说需要所有的归档日志，只需要少量几个而已。具体哪些归档呢？可以通过以下sql查看：

  SELECT DISTINCT al.thread#, al.sequence#, al.resetlogs_change#, al.resetlogs_time
    FROM v$archived_log al,
         (select grsp.rspfscn               from_scn,
                 grsp.rspscn                to_scn,
                 dbinc.resetlogs_change#    resetlogs_change#,
                 dbinc.resetlogs_time       resetlogs_time
            from x$kccrsp grsp,  v$database_incarnation dbinc
           where grsp.rspincarn = dbinc.incarnation#
             and bitand(grsp.rspflags, 2) != 0
             and bitand(grsp.rspflags, 1) = 1 -- guaranteed
             and grsp.rspfscn <= grsp.rspscn -- filter clean grp
             and grsp.rspfscn != 0
         ) grsp
      WHERE al.next_change#   >= grsp.from_scn
          AND al.first_change#    <= (grsp.to_scn + 1)
          AND al.resetlogs_change# = grsp.resetlogs_change#
          AND al.resetlogs_time       = grsp.resetlogs_time
          AND al.archived = 'YES';

这些归档文件也是可以备走的，闪回用到时会自动恢复出来（反正不多，不备也行）。

ORA-38754: FLASHBACK DATABASE NOT STARTED - REQUIRED REDO LOG IS NOT AVAILABLE (Doc ID 560686.1)

Files in the fast recovery area are not eligible for deletion if they are required to satisfy a guaranteed restore point. However, archived redo logs required to satisfy a guaranteed restore point may be deleted after they are backed up to disk or tape. When you use the RMAN FLASHBACK DATABASE command, if the archived redo logs required to satisfy a specified guaranteed restore point are not available in the fast recovery area, they are restored from the backups.

不过考虑到实际归档的备份可能也就保留几天，闪回数据库还是别开太久了，否则如果归档日志和备份都被删了，你就闪回不了了。

----------------------------------------

RMAN> recover database;
Starting recover at 23-FEB-10
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
starting media recovery
media recovery failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/23/2010 04:16:34
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
start
ORA-00283: recovery session canceled due to errors
ORA-38760: This database instance failed to turn on flashback database
RMAN>

SQL> alter database flashback off;

Database altered.
SQL> alter database recover;
alter database recover
*
ERROR at line 1:
ORA-00283: recovery session canceled due to errors
ORA-38760: This database instance failed to turn on flashback database
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-38760: This database instance failed to turn on flashback database

原来是因为flashback的日志文件丢了的原因，

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
RESTORE POINT ONLY

SQL> select name from v$restore_point;

NAME
--------------------------------------------------------------------------------
BEFORE_DROP

SQL> drop restore point BEFORE_DROP;

Restore point dropped.

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/tpdata/database/oradata/test/system01.dbf'