Oracle Restore Points

（一）Normal Restore Points

一般还原点只是给恢复SCN起个别名方便使用，并不会生成类似flashback log，存储空间基本为0，并不保证一定能把数据库恢复到此还原点，你可以在RECOVER DATABASE、FLASHBACK DATABASE以及FLASH TALBE中使用

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:

1. The RECOVER DATABASE and FLASHBACK DATABASE commands in RMAN
2. The FLASHBACK TABLE statement in SQL

一般还原点存于控制文件，它不需要维护，过期会自动删除

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, even if not explicitly dropped.

The rules governing retention of restore points in the control file are:

1. The most recent 2048 restore points are always kept in the control file, regardless of their age.
2. 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

保证还原点在控制文件中不会自动删除而是需要手动删除，它原理同回数据库（下面会详细说），在作危险操作前可以先创建保证还原点

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.

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.

不论是否开启闪回日志都可使用保证还原点：

1. 如果开启了闪回日志，则保证还原点之后的闪回日志不会被删除，即可以闪回到此还原点以后的任意时间，而不是只闪回到还原点SCN
2. 如果未开启闪回日志，只可以闪回到此还原点，如果再恢复之后时间点要用recover

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.

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 SCN's 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.

保证还原点的限制同闪回数据库，详细查看闪回数据库部分。另外compatibility也可注意

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.

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.

（三）Restore Points in a Multitenant Environment

You can create the following types of restore points in a multitenant environment:

1. CDB restore point

It can be a normal restore point or a guaranteed restore point.

CDB restore points are similar to restore points in a non-CDB, except that you need to connect to the root as a common user with the SYSDBA or SYSBACKUP privilege to create them.

CDB restore points are accessible to every pluggable database (PDB) within the CDB. However, a CDB restore point does not reflect the PDB sub-incarnation of any of its PDBs.

CDB restore points are useful in the following scenarios:

1. The whole CDB needs to be recovered to a particular point in time
2. Multiple PDBs in a CDB need to be recovered to a particular point in time

1. PDB restore point

You can create normal and guaranteed restore points in a pluggable database (PDB).

A PDB restore point represents the PDB sub-incarnation of the point in time at which it was created. A PDB restore point can be used to perform Flashback Database operations or point-in-time recovery only for the PDB in which it was created.

注意PDB的保证还原点可能导致 fast recovery area空间不足

Creating a guaranteed PDB restore point requires careful consideration because such a restore point can prevent required flashback logs in the multitenant container database (CDB) from being reused. This can potentially impact CDB functioning because the fast recovery area could run out of space.

1. Clean PDB restore point

在PDB关闭且没有未完成事务时创建的pdb restore point，它只用于使用共享undo架构。

A clean PDB restore point is a PDB restore point that is created when the PDB is closed and when there are no outstanding transactions for that PDB. Clean PDB restore points are only applicable to CDBs that use shared undo.

Clean pdb restore point也分为一般还原点及保证还原点，通过create clean restore point创建

Clean PDB restore points can be normal or guaranteed restore points. Use the CREATE CLEAN RESTORE POINT command to explicitly create a clean PDB restore point. For a CDB that uses shared undo, if a PDB is closed and it has no outstanding transactions, any PDB restore point created is marked as a clean PDB restore point.

If you anticipate that you may need to rewind a PDB to a particular point in time, for example, to a state just before an application upgrade, then it is recommended that you create a clean PDB guaranteed restore point.

For CDBs that use shared undo, a Flashback Database operation to a clean PDB restore point is faster than a Flashback Database operation to an SCN or other restore points that are not clean PDB restore points. This is because RMAN does not need to restore any backups while performing a flashback operation to a clean PDB restore point.

About the Namespace for PDB Restore Points

Each pluggable database (PDB) has its own namespace for restore points. Therefore, you can define a PDB restore point with the same name in more than one PDB.

In a multitenant environment, when you use a restore point name in a PDB or for a PDB operation, the name is first interpreted as a PDB restore point for the concerned PDB. If a PDB restore point with the specified name is not found, then it is interpreted as a CDB restore point.

（四）Logging for Flashback Database and Guaranteed Restore Points

保证还原点的机制与闪回数据库一样均是使用闪回日志记录images of data file blocks

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.

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

1. If the fast recovery area has enough space, then a flashback log is created whenever necessary to satisfy the flashback retention target.
2. 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.
3. 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.

1. 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 require the use of that redo log file for the use of FLASHBACK DATABASE are also deleted.
2. 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.

（五）Prerequisites for Restore Points

1. Guaranteed Restore Points除了要满足闪回数据库的以下条件：

1. Your database must be running in ARCHIVELOG mode, because archived logs are used in the Flashback Database operation.
2. You must have a fast recovery area enabled, because flashback logs can only be stored in the fast recovery area.
3. For Oracle Real Application Clusters (Oracle RAC) databases, the fast recovery area must be in a clustered file system or in ASM.
4. For creating restore points in CDBs, the COMPATIBLE initialization parameter must be set to 12.1.0 or higher.

还要满足以下条件:

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.

1. Normal restore points无使用前提
2. Restore Points in PDBs

To create restore points in a pluggable database (PDB), the COMPATIBLE initialization parameter must be set to 12.2.0 or higher.

（六）Using Normal and Guaranteed Restore Points

1. Create Restore Points

1) Creating Normal and Guaranteed Restore Points in non-CDBs

A. 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).

B. Run the CREATE RESTORE POINT statement.

SQL> CREATE RESTORE POINT before_upgrade;

SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;

2) Creating CDB Restore Points

A. Ensure that the CDB is open or mounted. If the CDB is mounted, then it must have been shut down cleanly (unless it is a physical standby database).

B. Run the CREATE RESTORE POINT statement to create a CDB restore point.

SQL> CREATE RESTORE POINT cdb_before_upgrade;

SQL> CREATE RESTORE POINT cdb_grp_before_upgrade GUARANTEE FLASHBACK DATABASE;

1. Creating PDB Restore Points

To create a PDB restore point when connected to the PDB:

1. If you are creating a clean PDB restore point in a CDB that uses shared undo, then the PDB must be closed.

SQL> SELECT name, open_mode FROM V$PDBs;

CopySQL> ALTER PLUGGABLE DATABASE CLOSE;

1. If the multitenant container database (CDB) is in mounted state, then it must have been shut down consistently (unless it is a physical standby database).
2. Set the current container to the PDB.

SQL> ALTER SESSION SET CONTAINER=my_pdb;

1. Create a PDB restore point by using the CREATE RESTORE POINT command.

SQL> CREATE RESTORE POINT before_patching;

SQL> CREATE RESTORE POINT before_upgrade GUARENTEE FLASHBACK DATABASE;

SQL> CREATE CLEAN RESTORE POINT before_patching;

To create a PDB restore point when connected to the CDB:

1. If you are creating a clean PDB restore point in a CDB that uses shared undo, then the PDB must be closed.

SQL> ALTER PLUGGABLE DATABASE my_pdb CLOSE;

1. The CDB that contains the PDB can be open or mounted. If the CDB is mounted, then it must have been shut down consistently (unless it is a physical standby database).
2. Set the current container to the root.

SQL> ALTER SESSION SET CONTAINER = CDB$ROOT;

1. Create a PDB restore point by using the CREATE RESTORE POINT command with the FOR PLUGGABLE DATABASE clause.

SQL> CREATE RESTORE POINT mypdb_before_patching FOR PLUGGABLE DATABASE my_pdb;

SQL> CREATE RESTORE POINT mypdb_grp_before_upgrade FOR PLUGGABLE DATABASE my_pdb GUARANTEE FLASHBACK DATABASE;

SQL> CREATE CLEAN RESTORE POINT mypdb_crp_before_patching FOR PLUGGABLE DATABASE my_pdb;

1. Listing Restore Points

1. Listing Restore Points Using the LIST Command

使用RMAN命令list查某个或所有还原点

LIST RESTORE POINT restore_point_name;

LIST RESTORE POINT ALL;

示例

RMAN> LIST RESTORE POINT ALL;

 

using target database control file instead of recovery catalog

SCN              RSP Time  Type       Time      Name

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

341859           28-APR-15            28-APR-15 NORMAL_RS

343690           28-APR-15 GUARANTEED 28-APR-15 GUARANTEED_RS

Note: The LIST command does not display details such as the PDB incarnation number and whether a restore point is a PDB restore point. To view additional details about restore points in a multitenant environment, Using the V$RESTORE_POINT View.

1. Listing Restore Points Using the V$RESTORE_POINT View

The V$RESTORE_POINT view contains additional information about restore points in a multitenant environment that is not displayed by the LIST RESTORE POINT command.

SELECT name, guarantee_flashback_database, pdb_restore_point, clean_pdb_restore_point, pdb_incarnation#, storage_sizeFROM v$restore_point;

NAME                         GUARANTEE_  PDB_RESTORE_POINT  CLEAN_PDB_RESTORE_POINT  STORAGE_SIZE

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

CDB_GRP_BEFORE_PATCH            YES         NO                  NO                     84586

PDB_GRP_BEFORE_UPGRADE_TEMP     YES         YES                 NO                      4562

CDB_RP1                         NO          NO                  NO                         0

PDB1_BEFORE_PATCHING            NO          YES                 NO                         0

MYPDB_CLEAN_GRP_BEFORE_UPGRADE  NO          YES                YES                        0    

For normal restore points, STORAGE_SIZE is zero. For guaranteed restore points, STORAGE_SIZE indicates the approximate number of bytes of disk space in the fast recovery area that is tied up retaining logs required to guarantee FLASHBACK DATABASE to that restore point.

1. Dropping Restore Points

SQL> DROP RESTORE POINT before_app_upgrade;