Oracle Flashback: Database Administration Features

Oracle把闪回技能分为Database Administration Features与Application Development Features：Database Administration Features供DBA使用，主要用于数据恢复，它包括Oracle Flashback Table，Oracle Flashback Drop以及Oracle Flashback Database，在官方手册的《Database Backup and Recovery User's Guide》中介绍

Application Development Features供开发者使用，用于报告历史数据或撤消错误的更改，它包括Oracle Flashback Query，Oracle Flashback Version Query，Oracle Flashback Transaction Query，DBMS_FLASHBACK Package，Flashback Transaction以及Flashback Data Archive，它们均依赖于UNDO DATA，在官方手册的《Database Development Guide》中介绍

本文为介绍Database Administration Features，它分为Physical Flashback与Logical Flashback，其中物理闪回即为闪回数据库，它依赖于Flashback log与redo data；逻辑闪回分为Flashback Table与Flashback Drop. 其中Flashback Table依赖于undo data，Flashback Drop依赖于回收站.

Physical Flashback Features Useful in Backup and Recovery

闪回数据库与数据库的时间点恢复一样的效果，它们同样需要以OPEN RESETLOGS打开，但闪回数据库不需要RESTORE并且只应用少量的REDO.

Oracle Flashback Database is the most efficient alternative to DBPITR. Unlike the other flashback features, it operates at a physical level and reverts the current data files to their contents at a past time. The result is like the result of a DBPITR, including theOPEN RESETLOGS, but Flashback Database is typically faster because it does not require you to restore data files and requires only limited application of redo compared to media recovery.

FLASHBACK DATABASE除了用于一般恢复场景还用于数据库升级、应用开发及测试环境中，同时它也可用于在切换主备后快速恢复原主库

Flashback Database and restore points are not only effective in traditional database recovery situations butcan 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.

你同样可使用FLASHBACK DATABASE来回到之前转世

You can return a database to its state in a previous incarnation, and undo the effects of an ALTER DATABASE OPEN RESETLOGS statement.

Principle of Flashback Database

闪回数据库会将改动块的image copies从db buffer复制到SGA的闪回缓冲区，然后由后台进程(Recover Write RVWR)将此闪回缓冲区刷新到Fast Recovery Area中的Flashback Log，整个过程与LGWR无关

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.

与REDO LOG不同FLASHBACK LOG不是记录数据库变化的日志，而是记录完整块影像的记录，即为快照，快照之间的时间使用redo日志来恢复

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.

FLASHBACK LOG是顺序写入的，无法被归档或复用

During normal operation, the database periodically writes old images of data file blocks to the flashback logs. Flashback logs are written sequentially and often in bulk.

The database automatically creates, deletes, and resizes flashback logs in the recovery area. Flashback logs are not archived. You need only be aware of flashback logs for monitoring performance and determining disk space allocation for the recovery area.

About 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.

limitations of Flashback Database

闪回数据库无法修复media failures或误删除数据文件的情况

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.

如果对数据文件进行shrink操作则同样无法闪回，需要先将此文件offline

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.

数据文件被drop后闪回到drop前状态则只是将此数据文件记录到控制文件而已。闪回数据库可用于恢复TRUCATE TABLE、DROP TABLE、DROP USER CASCADE等操作

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.

如果控制文件使用备份RESTORE则所有flashback log不可用

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.

如果闪回点在执行NOLOGING操作会产生坏块

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 data files affected by theNOLOGGINGoperation. 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 data files updated by the direct-pathINSERTmay 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 anyNOLOGGINGoperation 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.

You are not trying to use FLASHBACK DATABASE to undo a compatibility change.

Enabling/Disabling Flashback Database

Ensure the database is in ARCHIVELOG mode
Configure the recovery area
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 Real Application Clusters (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 SCOPE=BOTH; # 3 days

By default DB_FLASHBACK_RETENTION_TARGET is set to 1 day (1440 minutes).

Note: 归档日志存在时间要长于flashback retention时间

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.

关于闪回恢复区删除顺序：如果闪回恢复区空间不够会优先删除obsolete RMAN备份，之后再删flashback logs，所以这时无法保证db_flashback_retention_target设置

唯一保证闪回数据库恢复时间是通过Guaranteed restore points

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.

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.

关于restore points:

Restore points provide capabilities related to Flashback Database and other media recovery operations. In particular, a guaranteed restore point created at a 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.

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;

If you disable Flashback Database for a tablespace, then you must take its data files offline before running FLASHBACK DATABASE.

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.

关闭闪回数据库：

On a database instance that is either in mount or open state, issue the following command:

ALTER DATABASE FLASHBACK OFF;

Configuring for Optimal Flashback Database Performance

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.

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 Automatic Storage Management (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.

Monitoring the Effect of Flashback Database on Performance

AWR reports
AWR snapshots
V$FLASHBACK_DATABASE_LOG view -

用于查看实际数据库最晚闪回时间以及需要的闪回空间大小

V$FLASHBACK_DATABASE_LOG displays information about the flashback data. Use this view to help estimate the amount of flashback space required for the current workload.

OLDEST_FLASHBACK_SCN Lowest system change number (SCN) in the flashback data, for any incarnation

OLDEST_FLASHBACK_TIME

RETENTION_TARGET db_flashback_retention_target的设置值 (in minutes)

FLASHBACK_SIZE Current size (in bytes) of the flashback data

ESTIMATED_FLASHBACK_SIZE Estimated size of flashback data needed for the current target retention

因为在闪回空间不足时会忽略参数flashback_retention_target的值删除还没过期的闪回日志，查看此视图如果最晚可恢复时间小于retention_target要扩大闪回恢复区大小

V$FLASHBACK_DATABASE_STAT view

每一行为大约1小时的累计统计, 记录单位时间内数据库的活动量

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.

V$SYSSTAT view

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

Rewinding a Database with Flashback Database

6.1 Performing a Flashback Database Operation

FLASHBACK DATABASE可以自动回到direct ancestral path中，它会自动跨OPEN RESETLOGS，不需要执行RESET DATABASE TO INCARNATION。回到abandoned incarnation barch见6.6节

By default, an SCN used in a FLASHBACK DATABASE command refers to an SCN in the direct ancestral path of the database incarnations.

Connect SQL*Plus to the target database and determine the desired SCN, restore point, or point in time for the FLASHBACK DATABASE command.

Obtain the earliest SCN in the flashback database window as follows:

SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME

FROM V$FLASHBACK_DATABASE_LOG;

The most recent SCN that can be reached with Flashback Database is the current SCN of the database. The following query returns the current SCN:

SELECT CURRENT_SCN FROM V$DATABASE;

You can query available guaranteed restore points as follows (sample output included):

SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,

GUARANTEE_FLASHBACK_DATABASE

FROM V$RESTORE_POINT

WHERE GUARANTEE_FLASHBACK_DATABASE='YES';

Shut down the database consistently, ensure that it is not opened by any instance, and then mount it:

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

Repeat the query in Step 1 of this procedure.

Some flashback logging data is generated when the database is shut down. If flashback logs were deleted due to space pressure in the fast recovery area, then your target SCN may not be reachable.

Start RMAN and connect to the target database.
Run the SHOW command to see which channels are preconfigured.

During the flashback operation,RMAN may need to restore archived redo logs from backup. Enter the following command to see whether channels are configured:

SHOW ALL;

If the necessary devices and channels are configured, then no action is necessary. Otherwise, use the CONFIGURE command to configure automatic channels, or include ALLOCATE CHANNEL commands within a RUN block.

Run the RMAN FLASHBACK DATABASE command.

You can specify the target time by using a form of the command shown in the following examples:

FLASHBACK DATABASE TO SCN 46963;

FLASHBACK DATABASE TO RESTORE POINT BEFORE_CHANGES;

FLASHBACK DATABASE TO TIME "TO_DATE('09/20/12','MM/DD/YY')";

FLASHBACK DATABASE TO BEFORE SCN 4693;

FLASHBACK DATABASE TO BEFORE TIME "TO_DATE('09/20/12','MM/DD/YY')";

使用BEFORE会闪回到此SCN的前一个闪回快照，应该是不会使用对应的归档日志

TO BEFORE SCN reverts the database back to its state at the system change number just preceding the specified SCN.

When the FLASHBACK DATABASE command completes, the database is left mounted and recovered to the specified target time.

Open the database read-only in SQL*Plus and run some queries to verify the database contents. Open the database read-only as follows:

ALTER DATABASE OPEN READ ONLY;

If you are satisfied with the state of the database, then end the procedure with Step 9. If you are not satisfied with the state of the database, skip to Step 10.

If you are satisfied with the results, then perform either ofthe following mutually exclusive actions:

Make the database available for updates by opening the database with the RESETLOGS option. If the database is currently open read-only, then execute the following commands in SQL*Plus:

SHUTDOWN IMMEDIATE

STARTUP MOUNT

ALTER DATABASE OPEN RESETLOGS;

Note: After you perform this OPEN RESETLOGS operation, all changes to the database after the target SCN for FLASHBACK DATABASE are abandoned. Nevertheless, you can use the technique in "Rewinding the Database to an SCN in an Abandoned Incarnation Branch" to return the database to that range of SCNs while they remain in the flashback window.

Use Oracle Data Pump Export to make a logical backup of the objects whose state was corrupted. Afterward, use RMAN to recover the database to the present time:

RECOVER DATABASE;

This step undoes the effect of the Flashback Database by reapplying all changes in the redo logs to the database, returning it to the most recent SCN.After reopening the database read/write, you can import the exported objects with the Data Pump Import utility.

If you find that you used the wrong restore point, time, or SCN for the flashback, then mount the database and perform one of the following mutually exclusive options:

如果恢复SCN早了可以RECOVER UNTIL，如果恢复SCN晚了可以继续FLASHBACK

If your chosen target time was not far enough in the past, then use another FLASHBACK DATABASE command to rewind the database further back in time:

FLASHBACK DATABASE TO SCN 42963; #earlier than current SCN

If you chose a target SCN that is too far in the past, then use RECOVER DATABASE UNTIL to wind the database forward in time to the desired SCN:

RECOVER DATABASE UNTIL SCN 56963; #later than current SCN

If you want to completely undo the effect of the FLASHBACK DATABASE command, then you can perform complete recovery of the database by using the RECOVER DATABASE command without an UNTIL clause or SET UNTIL command:

RECOVER DATABASE;

6.2 Performing a Flashback Database Operation for a Whole CDB

只能flashback整个CDB或某个PDB，而不能只flashback CDB$root

You cannot perform a flashback operation only on the root, you must perform a flashback operation on the entire CDB.

The steps to perform a Flashback Database operation for a CDB are similar to the ones used for non-CDBs, with the differences described below.

Connect SQL*Plus to the target CDB and determine the desired SCN, restore point, or point in time for the FLASHBACK DATABASE command.

SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME

FROM V$FLASHBACK_DATABASE_LOG;

The most recent SCN that can be reached with Flashback Database is the current SCN of the database. The following query returns the current SCN:

SELECT CURRENT_SCN FROM V$DATABASE;

You can query available guaranteed restore points as follows (sample output included):

SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,

GUARANTEE_FLASHBACK_DATABASE

FROM V$RESTORE_POINT

WHERE GUARANTEE_FLASHBACK_DATABASE='YES';

Shut down the database consistently, ensure that it is not opened by any instance, and then mount it:

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

Repeat the query in Step 2 of this procedure.

Some flashback logging data is generated when the database is shut down. If flashback logs were deleted due to space pressure in the fast recovery area, then your target SCN may not be reachable.

Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege
Run the SHOW command to see which channels are preconfigured.

SHOW ALL;

Run the FLASHBACK DATABASE command to perform a flashback operation for the whole CDB to a specified point in time.

You can specify the target time by using an SCN, a time expression, or a CDB restore point.

The following examples perform a flashback database operation for the whole CDB:

FLASHBACK DATABASE TO SCN 345588;

FLASHBACK DATABASE TO RESTORE POINT cdb_before_upgrade;

Open the CDB read-only in SQL*Plus and run some queries to verify the database contents.

Open the CDB read-only as follows:

ALTER DATABASE OPEN READ ONLY;

If you are satisfied with the state of the database, then end the procedure with Step 9. If you are not satisfied with the state of the database, skip to Step 10.

If you are satisfied with the results, then perform either of the following mutually exclusive actions:

Make the database available for updates by opening the database with the RESETLOGS option. If the database is currently open read-only, then execute the following commands in SQL*Plus:

SHUTDOWN IMMEDIATE

STARTUP MOUNT

ALTER DATABASE OPEN RESETLOGS;

Use Oracle Data Pump Export to make a logical backup of the objects whose state was corrupted. Afterward, use RMAN to recover the database to the present time:

RECOVER DATABASE;

This step undoes the effect of the Flashback Database by reapplying all changes in the redo logs to the database, returning it to the most recent SCN. After reopening the database read/write, you can import the exported objects with the Data Pump Import utility.

If you find that you used the wrong restore point, time, or SCN for the flashback, then mount the database and perform one of the following mutually exclusive options:

If your chosen target time was not far enough in the past, then use another FLASHBACK DATABASE command to rewind the database further back in time:

FLASHBACK DATABASE TO SCN 42963; #earlier than current SCN

If you chose a target SCN that is too far in the past, then use RECOVER DATABASE UNTIL to wind the database forward in time to the desired SCN:

RECOVER DATABASE UNTIL SCN 56963; #later than current SCN

If you want to completely undo the effect of the FLASHBACK DATABASE command, then you can perform complete recovery of the database by using the RECOVER DATABASE command without an UNTIL clause or SET UNTIL command:

RECOVER DATABASE;

The RECOVER DATABASE command reapplies all changes to the database, returning it to the most recent SCN.

Since the PDBs are not automatically opened when the CDB is opened, open the PDBs.

ALTER PLUGGABLE DATABASE ALL OPEN;

6.3 Performing a Flashback Database Operation for PDBs

Performing a Flashback Database operation on a particular PDB modifies only data files related to that PDB. The other PDBs in theCDBare not impacted and are available for use.

不能把PDB恢复到CDB所在ancestor incarnation外

You can only perform a flashback operation on a PDB to one of its ancestor incarnations. A PDB must always stay in a past incarnation that is compatible with the overall database incarnation.

如果flashback整个application container，需要分别对application root及application pdbs进行flashback

To perform a flashback operation for an application container, you must perform flashback operations for the application root and all the individual application PDBs that are part of the application container. Performing a flashback operation on the application root reverts only the application root to the specified point in time.

When using restore points, you can perform a flashback database operation either to aCDB restore point,PDB restore point, PDB clean restore point, or PDB guaranteed restore point.

In general, for PDBs, a flashback operation to a PDB restore point is more accurate than a flashback operation to a CDB restore point. This is because a PDB restore point represents the PDB sub-incarnation of the point in time at which it was created.

About Flashback Database and PITR for PDBs

在使用shared undo时pdb进行resetlogs操作时同时整个CDB进行recover可能导到pdb不可用，需要对pdb进行恢复

For PDBs that use local undo, database point-in-time recovery and flashback operations are independent of each other. For PDBs that use shared undo, database point-in-time recovery and flashback operations are independent with the following caveat警告:

If you subsequently recover the entire multitenant container database (CDB) to a point in time that is in the middle of the PDB resetlogs operation, then you will receive a warning that some PDBs may not be opened.

For such PDBs, you need to perform one of the following mutually exclusive actions:

Recover the entire CDB or perform a flashback operation for the entire CDB to a different SCN
Recover all the affected PDBs or perform a flashback database operation for all the affected PDBs to a different SCN

To perform a Flashback Database operation for a PDB:

Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.
Ensure that the CDB is open.

SELECT open_mode from V$DATABASE;

Determine the desired SCN, restore point, or point in time for the Flashback Database command.

Query the V$RESTORE_POINT view to obtain the list of PDB restore points.

V$FLASHBACK_DATABASE_LOG displays the oldest SCN to which a flashback operation can be performed.

Ensure that the PDB for which the Flashback Database operation must be performed is closed. Other PDBs can be open and operational.

ALTER PLUGGABLE DATABASE my_pdb CLOSE;

Perform a Flashback Database operation for the specified PDB to the desired point in time.

For a PDB that uses local undo:

FLASHBACK PLUGGABLE DATABASE my_pdb TO SCN 24368;

FLASHBACK PLUGGABLE DATABASE my_pdb TO RESTORE POINT guar_rp;

FLASHBACK PLUGGABLE DATABASE my_pdb TO CLEAN RESTORE POINT clean_rp;

For a PDB that uses shared undo, you can optionally include the AUXILIARY DESTINATION clause to specify a location for the auxiliary instance that stores data files restored as part of the Flashback Database operation. If you omit this clause, then the auxiliary instance is created in the fast recovery area.

FLASHBACK PLUGGABLE DATABASE my_pdb TO SCN 24368 AUXILIARY DESTINATION '+data';

FLASHBACK PLUGGABLE DATABASE my_pdb TO RESTORE POINT before_appl_changes AUXILIARY DESTINATION '/temp/aux_dest';

FLASHBACK PLUGGABLE DATABASE my_pdb TO TIME "TO_DATE('03/20/15','MM/DD/YY')";

Open the PDB with RESETLOGS.

ALTER PLUGGABLE DATABASE my_pdb OPEN RESETLOGS;

Note: Flashback operations are not supported for proxy PDBs.

6.4 Monitoring Flashback Database

Flashback database分为两个过程restore phase与recovery phase

When you use Flashback Database to rewind a database to a past target time, Flashback Database determines which blocks changed after the target time and restores them from the flashback logs. This is called the restore phase. After this phase completes, Flashback Database then uses redo logs to reapply changes that were made after these blocks were written to the flashback logs. This is called the recovery phase.

通过V$SESSION_LONGOPS监视restore phase

The progress of Flashback Database during the restore phase can be monitored by querying the V$SESSION_LONGOPS view. The opname is Flashback Database. Under the column TOTALWORK is the number of megabytes of flashback logs that must be read. The column SOFAR in Example 18-3 lists the number of megabytes that have been currently read.

Example 18-3 Tracking Flashback Database Progress - Restore Phase

SQL> SELECT sofar, totalwork, units FROM v$session_longops WHERE opname = 'Flashback Database';

SOFAR TOTALWORK UNITS

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

17 60 Megabytes

通过V$RECOVERY_PROGRESS监视recovery phase

The progress of Flashback Database during the recovery phase can be monitored by querying the view V$RECOVERY_PROGRESS.

6.5 Rewinding an OPEN RESETLOGS Operation with Flashback Database

除了使用SCN/时间/还原点外，如果想回到上个OPEN RESETLOGS状态可用FLASHBACK DATABASE TO BEFORE RESETLOGS

Rather than specifying a particular SCN or point in time for the FLASHBACK DATABASE command, however, you use FLASHBACK DATABASE TO BEFORE RESETLOGS.

The procedure for using Flashback Database to reverse an unwanted ALTER DATABASE OPEN RESETLOGS statement is similar to the general case described in "6.1 Performing a Flashback Database Operation".

To undo an OPEN RESETLOGS operation:

Connect SQL*Plus to the target database and verify that the beginning of the flashback window is earlier than the time of the most recent OPEN RESETLOGS.

SELECT RESETLOGS_CHANGE# FROM V$DATABASE;

SELECT OLDEST_FLASHBACK_SCN FROM V$FLASHBACK_DATABASE_LOG;

If V$DATABASE.RESETLOGS_CHANGE# is greater than V$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_SCN, then you can use Flashback Database to reverse the OPEN RESETLOGS. operation

Shut down the database, mount it, and recheck the flashback window. If the resetlogs SCN is still within the flashback window, then proceed to the next step.
Connect RMAN to the target database.
Perform a flashback to the SCN immediately before the RESETLOGS.

FLASHBACK DATABASE TO BEFORE RESETLOGS;

If the command completes successfully, then the database is left mounted and recovered to the most recent SCN before the OPEN RESETLOGS operation in the previous incarnation.

Open the database read-only in SQL*Plus and perform queries as needed to ensure that the effects of the logical corruption have been reversed.

ALTER DATABASE OPEN READ ONLY;

To make the database available for updates again, shut down the database, mount it, and then execute the following command:

ALTER DATABASE OPEN RESETLOGS;

6.6 Rewinding the Database to an SCN in an Abandoned Incarnation Branch

在使用SCN闪回或数据库时间恢复时可能会产生歧义，因为abandoned incarnation SCN可能与当前direct ancestral path中的SCN值相同，而使用时间或还原点则不会

Unlike SCNs, time expressions and restore points are not ambiguous. A time expression is always associated with the incarnation that was current at that time.A restore point is always associated with the current incarnation when it was created. The database incarnation is automatically reset to the incarnation that was current at the specified time or when the restore point was created.

As shown in the diagram, the database could be at SCN 3000 in incarnation 3 when you must return to the abandoned SCN 1500 in incarnation 1.

If the SCN to which you are rewinding is in the direct ancestral path, or if you are rewinding the database to a restore point, then an explicit RESET DATABASE command is not necessary for Flashback Database. However, an explicit RESET DATABASE TO INCARNATION command is required when you use FLASHBACK DATABASE to rewind the database to an SCN in an abandoned database incarnation.

如果回到abandoned incarnation需要使用RESET DATABASE TO INCARNATION

To rewind the database to an SCN in an abandoned incarnation branch:

Use SQL*Plus to connect to the target database and verify that the flashback logs contain enough information to flash back to the SCN.

SELECT OLDEST_FLASHBACK_SCN FROM V$FLASHBACK_DATABASE_LOG;

Determine the target incarnation number for the Flashback Database operation, that is, the incarnation key for the parent incarnation.

SELECT PRIOR_INCARNATION# FROM V$DATABASE_INCARNATION WHERE STATUS = 'CURRENT';

Start RMAN and connect to the target database.
Shut down the database, and then mount it as follows:

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

Set the database incarnation to the parent incarnation.

RESET DATABASE TO INCARNATION 1;

Run the FLASHBACK DATABASE command, specifying the target SCN.

FLASHBACK DATABASE TO SCN 1500;

Open the database read-only in SQL*Plus and perform queries as needed to ensure that the effects of the logical corruption have been reversed.

ALTER DATABASE OPEN READ ONLY;

To make the database available for updates again, shut down the database, mount it, and then execute the following command:

ALTER DATABASE OPEN RESETLOGS;

Logical Flashback Features Useful in Backup and Recovery

All logical flashback featuresexcept Flashback Drop rely on undo data. Used primarily for providing read consistency for SQL queries and rolling back transactions, undo records contain the information required to reconstruct data as it existed at a past time and examine the record of changes since that past time.Flashback Drop relies on a mechanism called therecycle bin.

Rewinding a Table with Flashback Table

When a Flashback Table operation occurs, new rows are deleted and old rows are reinserted. The rest of your database remains available while the flashback of the table is being performed.

闪回表只是闪回表的数据，即表的相关对象(索引，约束，触发器等)仍为当前表状态，在闪回表时会同时维护当前表上索引数据，如表在T1时创建了索引IND_1，在之后T2时间删除IND_1并创建了索引IND_2, 闪回到DROP IND_1之前并不会创建IND_1，而只是维护IND_2索引。闪回表可以看作一个事务，如果在闪回时表时违反了当前约束则将回退整个闪回过程。

1.1 Prerequisites for Flashback Table

You must have the following privileges to use the Flashback Table feature:

You must have been granted the FLASHBACK ANY TABLE system privilege or you must have the FLASHBACK object privilege on the table.
You must have READ or SELECT, INSERT, DELETE, and ALTER privileges on the table.
To flash back a table to a restore point, you must have the SELECT ANY DICTIONARY or FLASHBACK ANY TABLE system privilege or the SELECT_CATALOG_ROLE role.

For an object to be eligible to be flashed back, the following prerequisites must be met:

The object must not be included the following categories:

tables that are part of a cluster, materialized views, Advanced Queuing (AQ) tables, static data dictionary tables, system tables, remote tables, object tables, nested tables, or individual table partitions or subpartitions.

Thestructure of the table must not have been changed between the current time and the target flashback time. The following Data Definition Language (DDL) operations change the structure of a table:

upgrading, moving, or truncating a table; adding a constraint to a table, adding a table to a cluster; modifying or dropping a column; adding, dropping, merging, splitting, coalescing, or truncating a partition or subpartition (except adding a range partition).

Row movement must be enabled on the table, which indicates that rowids change after the flashback occurs.

This restriction exists because if rowids before the flashback were stored by the application, then there is no guarantee that the rowids correspond to the same rows after the flashback.If your application depends on rowids, then you cannot use Flashback Table.

The undo data in the undo tablespace must extend far enough back in time to satisfy the flashback target time or SCN.

The point to which you can perform Flashback Table is determined by theundo retention period, which is the minimal time for which undo data is kept before being recycled, and tablespace characteristics. The undo data contains information about data blocks before they were changed. The flashback operation uses undo to re-create the original data.

To ensure that the undo information is retained for Flashback Table operations, Oracle suggests setting the UNDO_RETENTION parameter to 86400 seconds (24 hours) or greater for the undo tablespace.

1.2 Performing a Flashback Table Operation

To perform a flashback of temp_employees:

Connect SQL*Plus to the target database and identify the current SCN.

You cannot roll back a FLASHBACK TABLE statement, but you can issue another FLASHBACK TABLE statement and specify a time just before the current time. Therefore, it is advisable to record the current SCN. You can obtain it by querying V$DATABASE as follows:

SELECT CURRENT_SCN FROM V$DATABASE;

Identify the time, SCN, or restore point to which you want to return the table.

If you have created restore points, then you can list available restore points by executing the following query:

SELECT NAME, SCN, TIME FROM V$RESTORE_POINT;

Ensure that enough undo data exists to rewind the table to the specified target.

SELECT NAME, VALUE/60 MINUTES_RETAINED

FROM V$PARAMETER

WHERE NAME = 'undo_retention';

Ensure that row movement is enabled for all objects that you are rewinding with Flashback Table.

ALTER TABLE table ENABLE ROW MOVEMENT;

Determine whether the table that you intend to flash back has dependencies on other tables. If dependencies exist, then decide whether to flash back these tables as well.

You can issue the following SQL query to determine the dependencies, where schema_name is the schema for the table to be flashed back and table_name is the name of the table:

SELECT other.owner, other.table_name

FROM sys.all_constraints this, sys.all_constraints other

WHERE this.owner = schema_name

AND this.table_name = table_name

AND this.r_owner = other.owner

AND this.r_constraint_name = other.constraint_name

AND this.constraint_type='R';

Execute a FLASHBACK TABLE statement for the objects to flash back.

FLASHBACK TABLE hr.temp_employees TO RESTORE POINT temp_employees_update;

FLASHBACK TABLE hr.temp_employees TO SCN 123456;

FLASHBACK TABLE hr.temp_employees TO TIMESTAMP TO_TIMESTAMP('2013-10-17 09:30:00', 'YYYY-MM-DD HH:MI:SS');

Note: The mapping of time stamps to SCNs is not always exact. When you use time stamps with the FLASHBACK TABLE statement, the time to which the table is flashed back can vary by up to approximately 3 seconds of the time specified for TO_TIMESTAMP. If an exact point in time is required, then use an SCN rather than a time.

Optionally, query the table to check the data.

By default, the database disables triggers on the affected table before performing a FLASHBACK TABLE operation. After the operation, the database returns the triggers to the state they were in before the operation (enabled or disabled). To keep triggers enabled during the flashback of the table, add an ENABLE TRIGGERS clause to the FLASHBACK TABLE statement in Step7.

FLASHBACK TABLE hr.temp_employees

TO TIMESTAMP TO_TIMESTAMP('2013-03-03 14:00:00' , 'YYYY-MM-DD HH:MI:SS')

ENABLE TRIGGERS;

Rewinding a DROP TABLE Operation with Flashback Drop

开启或关闭FLASHBACK DROP

SQL> ALTER SYSTEM SET RECYCLEBIN=ON|OFF SCOPE=SPFILE;

drop表同时会把表及索引放入回收站，其它依赖对象会重命名；单独DROP索引或依赖对象均不会放入回收站，DROP USER/TABLESPACE等当然也不会放入回收站，回收站对象只可查询，不能DML。依赖对象会被改名恢复时不再使用原来名字，另外恢复时不会恢复表的bitmap join indexes及外键约束

When you drop a table, the table and all of its dependent objects go into the recycle bin together. Likewise, when you perform Flashback Drop, the objects are generally all retrieved together.

When you restore a table from the recycle bin, dependent objects such as indexes do not get their original names back; they retain their system-generated recycle bin names.

Oracle Database retrieves all indexes defined on the tableexcept for bitmap join indexes, and all triggers and constraints defined on the table except for referential integrity constraints that reference other tables.

2.1 Prerequisites of Flashback Drop

The following list summarizes the user privileges required for the operations related to Flashback Drop and the recycle bin:

DROP

Any user with DROP privileges over an object can drop the object, placing it in the recycle bin.

FLASHBACK TABLE ... TO BEFORE DROP

Privileges for this statement are tied to the privileges for DROP. That is, any user who can drop an object can perform Flashback Drop to retrieve the dropped object from the recycle bin.

PURGE

Privileges for a purge of the recycle bin are tied to the DROP privileges. Any user having DROP TABLE, DROP ANY TABLE, or PURGE DBA_RECYCLE_BIN privileges can purge the objects from the recycle bin.

READ or SELECT and FLASHBACK for objects in the Recycle Bin

Users must have the READ or SELECT and FLASHBACK privileges over an object in the recycle bin to query the object in the recycle bin. Any users who had the READ or SELECT privilege over an object before it was dropped continue to have the READ or SELECT privilege over the object in the recycle bin. Users must have FLASHBACK privilege to query any object in the recycle bin, because these are objects from a past state of the database.

Objects must meet the following prerequisites to be eligible for retrieval from the recycle bin:

The recycle bin is only available for non-system, locally managed tablespaces. If a table is in a non-system, locally managed tablespace, but one or more of its dependent segments (objects) is in a dictionary-managed tablespace, then these objects are protected by the recycle bin.

System及dictionary managed tablespace对象无法使用flashback drop

Tables that have fine-grained auditing (FGA) and Virtual Private Database (VPD) policies defined over them are not protected by the recycle bin.
Partitioned index-organized tables are not protected by the recycle bin.
The table must not have been purged, either by a user or by Oracle Database during a space reclamation operation.

2.2 Performing a Flashback Drop Operation

To retrieve a dropped table:

Connect SQL*Plus to the target database and obtain the name of the dropped table in the recycle bin. show recyclebin只能查看回收站的表，USER_RECYCLEBIN or DBA_RECYCLEBIN还可以查看回收站的索引

SHOW RECYCLEBIN;

Alternatively, you can query USER_RECYCLEBIN or DBA_RECYCLEBIN to obtain the table name:

SELECT object_name AS recycle_name, original_name, type FROM recyclebin;

想恢复表依赖对象的原始名称(放入回收站会被改名)，要在这步记下依赖对象的原始名称

If you plan to manually restore original names for dependent objects, then ensure that you make note of each dependent object's system-generated recycle bin name before you restore the table.

Note: Object views such as DBA_TABLES do not display the recycle bin objects.

Optionally, query the table in the recycle bin.

You must use the recycle bin name of the object toquery rather than the object's original name:

SELECT * FROM "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0";

Quotation marks are required because of the special characters in the recycle bin name.

If you have the necessary privileges, then you can also use Flashback Query on tables in the recycle bin, but only by using the recycle bin name rather than the original table name. You cannot use Data Manipulation Language (DML) or DDL statements on objects in the recycle bin.

Retrieve the dropped table.

FLASHBACK TABLE "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0" TO BEFORE DROP;

FLASHBACK TABLE HR.EMPLOYEE_DEMO TO BEFORE DROP;

FLASHBACK TABLE "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0" TO BEFORE DROP

RENAME TO hr.emp_demo;

Optionally, verify that all dependent objects retained their system-generated recycle bin names. The following query determines the names of the indexes of the retrieved hr.employee_demo table:

SELECT INDEX_NAME FROM USER_INDEXES WHERE TABLE_NAME = 'EMPLOYEE_DEMO';

INDEX_NAME

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

BIN$JKS983293M1dsab4gsz/I249==$0

Optionally, rename the retrieved indexes to their original names.

ALTER INDEX "BIN$JKS983293M1dsab4gsz/I249==$0" RENAME TO I_EMP_DEMO;

If the retrieved table had referential constraints before it was placed in the recycle bin, then re-create them.

This step must be performed manually because the recycle bin does not preserve referential constraints on a table.

Note: 回收站可能有多个重名对象，此时恢复时要注意：

CREATE TABLE temp_employees ( ...columns ); # temp_employees version 1

DROP TABLE temp_employees;

CREATE TABLE temp_employees ( ...columns ); # temp_employees version 2

DROP TABLE temp_employees;

CREATE TABLE temp_employees ( ...columns ); # temp_employees version 3

DROP TABLE temp_employees;

这时在执行以下命令时恢复的是最近一个被drop的表

FLASHBACK TABLE temp_employees TO BEFORE DROP;

可以按以下查询恢复具体某个时间drop的表

SELECT object_name, original_name, createtime FROM recyclebin;

OBJECT_NAME ORIGINAL_NAME CREATETIME

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

BIN$yrMKlZaLMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES 2013-02-05:21:05:52

BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES 2013-02-05:21:25:13

BIN$yrMKlZaQMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES 2013-02-05:22:05:53

You can use the following command to retrieve the middle table:

FLASHBACK TABLE BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TO BEFORE DROP;

回收站的表可以使用PUREG命令永久删除

Purge tablespace tablespace_name; 清空表空间回收站

Purge tablespace tablespace_name user user_name; 清空表空间中某用户的回收站

Purge recyclebin; 删除当前用户的RecycleBin对象

Purge dba_recyclebin 删除所有用户的RecycleBin对象

Drop table table_name purge; 直接永久删除

Purge table original_obj_name; 永久删除回收站某表，如果有多个同名则删除最旧的

Purge index original_obj_name; 永久删除回收站某索引，如果有多个同名则删除最旧的

Purge table recycle_bin_object_name; 永久删除回收站中某表

Purge index recycle_bin_object_name; 永久删除回收站中某索引

2.3 Space Usage of Recyclebin

Recyclebin使用的是所在表空间空间，表空间空间不够即使设置了AUTOEXTEND属性，也会先覆盖RECYCLEBIN空间，另外DBA_FREE_SPACE显示的空闲空间包含了回收站数据

Flashback Drop relies on a mechanism called the recycle bin, which the database uses to manage dropped database objects until the space they occupied is needed for new data. There is no fixed amount of space allocated to the recycle bin, and no guarantee regarding how long dropped objects remain in the recycle bin. Depending on system activity, a dropped object may remain in the recycle bin for seconds or for months. Some dependent objects such as indexes may possibly have been reclaimed because of space pressure. In such cases, the reclaimed dependent objects are not retrievable from the recycle bin.

测试：

CREATE TABLESPACE TOOL DATAFILE '/u01/app/oracle/oradata/orcl/tools01.dbf' SIZE 20M AUTOEXTEND ON;

CREATE TABLE T1 TABLESPACE TOOL AS SELECT * FROM DBA_OBJECTS;

SELECT BYTES/1024/1024 FROM USER_SEGMENTS WHERE SEGMENT_NAME='T1'; -12M

DROP TABLE T1;

SHOW RECYCLEBIN;

ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME

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

T1 BIN$x7FBPD2hCV/gVe8RVJH0Lw==$0 TABLE 2021-07-22:14:41:34

CREATE TABLE T2 TABLESPACE TOOL AS SELECT * FROM DBA_OBJECTS;

SHOW RECYCLEBIN; --空

SELECT BLOCKS*8/1024 from dba_data_files WHERE TABLESPACE_NAME='TOOL'; --20M

Oracle Flashback: Database Administration Features相关推荐

Oracle Flashback Database and Restore Points 说明
一.FlashbackDatabase 和 Restore Points 说明官网的链接如下: http://download.oracle.com/docs/cd/E18283_01/backup ...
oracle flashback database,Flashback Database
在Flashback Database中创建基于guarantee的restore point,是可以进行快速备份和恢复的方法.这对于RAT中的播放之后的数据库恢复特别有用! 下面的notes详细描述 ...
oracle flashback database,Oracle Flashback Database
Flashback 技术是以Undo segment中的内容为基础的,因此受限于UNDO_RETENTON参数.要使用flashback的特性,必须启用自动撤销管理表空间. 在Oracle 10g中, ...
oracle flashback on,Oracle Flashback database
这里简单介绍下flashback database,这个既可以在RMAN中执行,也可以再SQL*PLUS执行,有时候还是挺实用的必备条件: 1:必须是归档模式 2:必须指定flash recover ...
oracle flashback database,flashback database 使用及注意事项
适用版本:10.2+(9i+可能也适用) 读者阅读前提: 1. 知道flashback 2. 知道oracle 的启动模式和基本系统视图 v$database中的flashback_on Oracle ...
oracle flashback 用法,使用oracle flashback database
1闪回的方法使用闪回方法的目的:修正用户错误. 1.1FLASHBACK DATABASE flashback data1base闪回到过去的某一时刻闪回点之后的所有工作都将丢失必须使用rese ...
oracle中闪回和回滚,Oracle Flashback 闪回查询功能9i和10g的区别
Oracle从9i开始提供了基于回滚段的闪回查询(Flashback Query)功能,可用于恢复错误的DML操作.在Oracle 10g中对闪回查询做了较大改进,不再局限于闪回查询,还可用于恢复错误 ...
oracle数据库升级失败,Oracle 11.2.0.1 rac 升级失败后，数据库降级方案（flashback database）...
升级失败后,数据库降级方案(flashback database) 环境:Oracle 11.2.0.1 rac on redhat 5.8 Flashback database 准备工作查看是否f ...
oracle data guard闪回,11gR2 Active Data Guard 闪回 - flashback database / snapshot standby - 2
二,11g 使用snapshot方式设置Data Guard闪回 snapshot standby是11g引入的新特性,它不需要开启flashback database特性,就可以让physical ...

Oracle Flashback: Database Administration Features

Oracle Flashback: Database Administration Features相关推荐

最新文章

热门文章