Temporal Validity和Flashback的区别？两者通常配合使用。
延伸阅读：Oracle 数据库和时间有效性

时间有效性也称为 Flashback Time Travel。

显示不可见的列：

set colinvisible on
desc <table_name>; 

时间有效性的SELECT的字句为：

VERSIONS PERIOD FOR VALID_TIME BETWEEN <start> AND <end>

和Flashback的关联是通过过程DBMS_FLASHBACK_ARCHIVE：

-- level可以是All，CURRENT和ASOF
DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME (
   level          IN    VARCHAR2, 
   query_time     IN    TIMESTAMP DEFAULT SYSTIMESTAMP);

DBMS_FLASHBACK_ARCHIVE.DISASSOCIATE_FBA (
   owner_name     IN    VARCHAR2, 
   table_name     IN    VARCHAR2);

逻辑错误指由人和应用造成的错误。但数据库并没有报错。

复制并不能防止逻辑错误，除非延迟复制。

备份和恢复可以应对逻辑错误，但通常太慢太复杂。

这句话是错的，然后后面的解释也完全错了：

In Oracle, we can perform a flashback table operation. The database must have flashback logging enabled.

这文章只能给2星。

这篇文章讲了Reuse和Delete Flashback Logs的区别。不错，给4星。

Flashback是高可用的特性，好处是简单。

Flashback技术包括逻辑和物理2种：

• Logical Flashback，依赖Undo数据，恢复表和交易。
• Physical Flashback，依赖Flashback logs，恢复整库。

Flashback Database的先决条件：

• 开启归档
• 配置 fast recovery area
• 设置flashback retention target

The retention target signals the database to copy images of each altered block in every data file into the flashback log at regular intervals. These images are later used to reconstruct a previous incarnation of the database on demand. Any remaining changes are recovered using online and archived redo logs if available.

管理flashback logs的四种操作如下：

• Create, 如果满足以下条件，则会创建闪回日志：
  • fast recovery area有足够的空间
  • DB_FLASHBACK_RETETION_TARGET已设置
• Delete, 仅在以下情况下可能会删除闪回日志
  • The flashback logs satisfy a normal restore point and there is space pressure in the fast recovery area
  • Flashback logs are obsolete as per retention target and corresponding archived redo logs have been deleted due to space pressure
  • Flashback logs have already been backed up to tape
• Reuse or Overwrite, 闪回日志在以下情况下被重用或覆盖
  • 不满足保留目标
  • 不属于保证还原点
  • FRA有空间压力时最老的闪回日志
• Retain, 仅在以下情况下保留闪回日志
  • 需要闪回日志来满足保证的还原点
  • FRA没有空间压力

还需要注意的是，除了设置闪回保留目标和创建保证还原点外，不能在快速恢复区管理闪回日志。

这篇文章谈了Flashback Data Archive。

通常，您只能使用它来查询撤消允许的最远时间（默认/标准的Flashback Query）。 借助闪回数据存档 (FBA)，Oracle 可以永久存储表的历史记录（直至保留期）。

Flashback Database类似于盒式录音机上的倒带按钮或CD 播放器上的重置按钮。

虽然很少用于生产系统，因为在重置时间后所有数据都会丢失 （除非您事先导出），但有许多可能的用途，特别是对于测试或备用系统：

• 应用升级失败系统重置
• 具有后续前滚功能的替代时间点恢复 (PITR)（特别适用于备用系统）
• 可重现的起点的测试数据库（例如，用于实际应用程序测试）
• 数据库升级测试

一些数据库功能隐含使用Flashback Database，都和ADG有关：

• Snapshot Standby
• 备用数据库的重新实例化（例如Fast Start Failover）

一些人不愿使用Flashback Databas，因为性能开销和空间管理，但是：

• 启用Flashback Logs的负载通常相对较低（大约 5%）
• 闪回日志所需的额外空间也可以相对精确地确定。

扩展阅读Flashback Database

这篇文章中提到了Flashback Log的启用有标准和隐式2种方式。

-- 标准
alter database flashback on
-- 隐式
create restore point SolbachGRP guarantee flashback database;

-- 可以从flashback_on属性看出区别，标准是YES，隐式是RESTORE POINT ONLY
SQL> SELECT flashback_on, log_mode FROM v$database;

FLASHBACK_ON       LOG_MODE
------------------ ------------
RESTORE POINT ONLY ARCHIVELOG

Oracle 数据库提供了闪回查询、闪回删除（DROP）、时间有效性、闪回数据库、闪回事务、闪回数据存档或闪回版本查询等技术。

所有技术都可以提前使用，无需额外安装。并且都包含在企业版中。

扩展阅读：Flashback in Oracle
其中提到：

注意：重要的是要知道闪回数据库技术也可以在不使用闪回日志记录的情况下使用。但是，这需要使用保证还原点。

准确的说，应该是保证还原点隐式的启用了Flashback Database。

下表也很有用：

关于许可：
闪回表、闪回数据库、闪回事务和闪回事务查询在企业版中可用。归档最初是作为 Oracle 数据库 11gR1 企业版的一个独立选项引入的，名称为 Total Recall——意为“完美的记忆”。后来改名为Flashback Time Travel，也免费了。也就是说，FDA，Total Recall和Flashback Time Travel是一回事。

Total Recall是11g的特性，在OBE的这篇文章Using Total Recall提到：

The Flashback Data Archive feature is part of the Total Recall option.

很有意思，这篇文档Oracle Total Recall Oracle Banking ELCM Release专门介绍了Total Recall。

只有Optimization for Flashback Time Travel特性需要高级压缩选件。

在11gR2的License Guide中是这么说的：

For releases earlier than Oracle Database 11g Release 2 (11.2.0.4): You must license the Oracle Advanced Compression option to use Flashback Data Archive (formerly known as Total Recall).
Beginning with Oracle Database 11g Release 2 (11.2.0.4): You must license the Oracle Advanced Compression option to use Optimization for Flashback Data Archive history tables. Basic Flashback Data Archive—without history table optimization—is available in all editions.

分场景介绍了Flashback的技术：

• Restore a Whole Table - Flashback Table
• Recover a Few Rows - Flashback Query
• Recover a Few Rows++ - Flashback Data Archive
• Restore Dropped Tables - Flashback Drop
• Revert the Whole Database! - Flashback Database

使用触发器进行审计很常见，并且仍然经常被视为捕获 Oracle 数据库表上的行更改的唯一可能解决方案。 但是，在 Oracle 数据库 11.2.0.4 及更高版本中，现在可以使用闪回数据存档来满足审计要求——一种简单、更高效、更安全的解决方案。

执行计划中可以看到对FDA中表的引用。

本文重点介绍了Restore Point，即SCN的别名。以及其适用场景：

1. 反复测试，测试后需要回到测试数据基线
2. 批处理修改数据错误时，回退到批处理前。
3. 升级失败后，回到升级前

Flashback Database是10g Release 2的技术。其启用过程：

1. 开启归档
2. 设置FRA
3. 启用flashback logging

restore point并不能保证一定可以恢复，但guaranteed restore point可以。

闪回日志会保留到 db_flashback_retention_target 数据库参数指定的时间。

较旧的日志不会自动删除；但是，闪回恢复区的最大大小由 db_recovery_file_dest_size 数据库参数决定，在本例中为 2GB。当 Tom 的闪回恢复区达到 2GB 时，Oracle 数据库必须删除一些早于 1,440 秒的日志以为新日志腾出空间。因此，当 Tom 想要执行闪回时，所选还原点所需的日志已过时，从而导致了错误。

这里有个小错误，1440秒应为1440分钟，因为这是DB_FLASHBACK_RETENTION_TARGET 的默认值，即1天。

这是官网的描述。全文抄录如下：

Flashback supports recovery at all levels including the row, transaction, table, and the entire database. Flashback provides an ever growing set of features to view and rewind data back and forth in time, namely:

• Flashback Database: restore the entire database to a specific point-in-time, using Oracle-optimized flashback logs, rather than via backups and forward recovery.
• Flashback Table: easily recover tables to a specific point-in-time, useful when a logical corruption is limited to one or a set of tables instead of the entire database.
• Flashback Drop: recover an accidentally dropped table. It restores the dropped table, and all of its indexes, constraints, and triggers, from the Recycle Bin (a logical container of all dropped objects).
• Flashback Transaction: undo the effects of a single transaction, and optionally, all of its dependent transactions. via a single PL/SQL operation or by using an Enterprise Manager wizard.
• Flashback Transaction Query: see all the changes made by a specific transaction, useful when an erroneous transaction changed data in multiple rows or tables.
• Flashback Query: query any data at some point-in-time in the past. This powerful feature can be used to view and logically reconstruct corrupted data that may have been deleted or changed inadvertently.
• Flashback Versions Query: retrieve different versions of a row across a specified time interval instead of a single point-in-time.
• Total Recall: efficiently manage and query long-term historical data. Total Recall automatically tracks every single change made to the data stored inside the database and maintains a secure, efficient and easily accessible archive of historical data.

The Flashback features offer the capability to query historical data, perform change analysis, and perform self-service repair to recover from logical corruptions while the database is online. With Oracle Flashback Technology, you can indeed undo the past.

也来自官网。

Oracle Database Flashback Technologies is a set of data recovery solutions that reverse human errors by selectively and efficiently undoing the effects of a mistake. Oracle Database Flashback supports recovery at all levels, including the row, transaction, table, and the entire database.

作者Tim Chien是备份和恢复的产品经理。此文比较了基于存储的快照和RMAN的区别。

基于存储的快照在非生产系统上使用快照进行开发或测试有好处，但它们不应被视为有效的数据保护或 Oracle 数据库的备份。正确的做法是RMAN+FRA。

RMAN是Oracle 8引进的。

存储快照不知道 Oracle 块结构（因为它们在存储块级别运行），更重要的是，它们在物理上与备份（由指针而不是块组成）本质上不同。

RMAN的好处：
RMAN 是 Oracle 数据库的集成数据保护解决方案，提供多种保护级别。在粒度块级别，RMAN 在备份和恢复时全面验证 Oracle 块 - 通过块本身内的物理校验和比较和逻辑检查来验证块（例如，验证行片段或索引条目是否一致）。备份可用于在任何数据丢失或物理损坏情况下将生产数据恢复到最后可用的归档重做日志，或恢复到特定时间点（根据 RMAN 保留策略）。此外，可以根据用户的判断使用VALIDATE验证整个数据库或单个表空间/数据文件的物理和逻辑块正确性命令。同样，可以随时验证备份，以确保可以使用RESTORE VALIDATE命令成功恢复。RMAN 还提供块介质恢复功能，允许快速修复数据库中的单个块损坏，同时未受影响的数据保持在线并可供用户访问。

存储快照的缺点
快照不是为 Oracle 数据保护而设计的。他们不了解 Oracle 块结构，因此在创建 Oracle 数据时不会也无法验证它们。它们不能用于任何数据丢失或物理损坏的情况。如果块不随时间变化，则未检测到的块损坏可能会影响一系列快照。由于快照与源数据库驻留在同一阵列上，因此它们很容易受到影响存储阵列的故障的影响。这就是为什么快照即使创建得非常快，也不构成原始数据的备份。对于用作有效备份的快照，必须将其重新构建为完整的块集到另一个存储阵列或磁带，这涉及与完整副本相同的性能问题。最后，还原快照具有使所有在它之后拍摄的快照无效的副作用，除非快照作为生产数据的副本完全还原到备用位置。鉴于快照的这些固有缺陷，很明显只有 Oracle 感知 RMAN 备份才能提供真正的数据保护“安心”。

对于基于写时复制的快照，数据库性能影响体现在两个方面。首先，创建快照后，对数据库块的第一次写入转换为两次存储 I/O 写入——一次用于将原始块复制到新的快照存储位置，一次用于将新块写入原始数据块堵塞。增加的 I/O 使用率会对生产数据库性能产生严重影响。其次，在将生产数据库卷恢复到以前的快照后，现在活动的存储块版本包括对快照块的引用，这些快照块很可能在磁盘上分散而不是按顺序排列（数据库仍然希望如此当发出 I/O 时）。例如，在前面的写时复制快照图中，块 C 的 I/O 请求被重定向到块 C 的快照版本，而块 B 的 I/O 请求没有被重定向，因为它相对于拍摄快照的时间没有改变。当数据库发出 1 MB 的 I/O 时，它不会在单个大读取中顺序读取数据，而是发出 128 个随机 I/O（假设块大小为 8K）。随着时间的推移创建和恢复多个快照，由此产生的碎片化块布局可能导致数据库性能降低 10-100 倍。

由于这些原因，在生产数据库存储上创建和使用快照从来都不是一个好主意。
由于严重影响 I/O 性能，因此不建议在生产数据库上使用快照克隆，而是在数据库的辅助副本上使用。