在Oracle体系结构初探这个专栏中，已经写过了REDO、UNDO等内容。觉得可以开始写下有关备份恢复的内容。闪回技术 — Oracle数据库备份恢复机制的一种。它可以在一定条件下，高效快速的恢复因为逻辑错误（误删误更新等）导致的数据丢失、错乱等问题。

在我所见过的实际生产例子中，很少会选择闪回技术作为一整套的备份恢复方案基础；闪回技术更多的是应用于误删误更新了某些数据后，在避免大动干戈进行备份还原恢复的情况下，进行快速数据恢复。

所以本篇文章也不想长篇大论闪回的每个细节，更多是想结合实际生产去和大家分享下闪回技术的使用。

目录

闪回技术前提需知

常用闪回技术必备

Ⅰ：闪回DROP操作

Ⅱ：闪回至过去某时间点

Ⅲ：闪回查询

闪回时间点查询

闪回版本查询 

闪回事务查询 

Ⅳ：闪回事务

其他闪回技术了解

闪回技术前提需知

• 只闪回逻辑错误（缺陷）

Oracle的闪回只能闪回逻辑错误；对于数据文件损坏等类似的错误，闪回操作是无能为力的。所以对于正式生产来讲，闪回技术不能作为正式的备份方案技术基础。

• 受限于undo （缺陷）

大部分的闪回技术都是依赖于undo段中的undo数据。关于undo，前面有篇文章已经讲述过了（聊聊undo）。如果要恢复的数据超过了undo大小或者保留时效，那闪回此时也无能为力。

举个例子：

我不小心删除了某个表的数据，当时不知道该怎么做；过了俩钟头，有人对我说，可以闪回，此时该表的在两个小时前的数据早已被覆盖过期，闪回无能为力。

• 一般不能跨越DDL

例如闪回查询、闪回至过去某时间点、闪回事务等，如果表结构发生了变动，闪回技术则无效。

• 恢复耗时短（优势）

相比较Oracle的RMAN等恢复技术手段，Oracle的闪回技术可以在非常短时间内恢复数据错误。而进行RMAN还原恢复的话，受限于RMAN备份时的文件大小，恢复耗时的成本可能就很高了。

• 精准恢复（优势）

在生产上，常常可能在测试时，删除了某张表真实的业务数据且提交；此时运用闪回技术可以快速定位此表进行数据闪回。如果用RMAN等手段的话，因为RMAN的备份策略一般都不会针对某张表进行备份，基本是针对数据文件或者数据库进行备份；此时如果进行还原恢复，就得把整个数据文件甚至整个表空间进行还原恢复，这非常有可能影响到数据库其他表的数据内容。

常用闪回技术必备

Ⅰ：闪回DROP操作

这里的闪回表针对的是 DROP TABLE TABLE_NAME 操作。

在掌握闪回表技术前，需要先了解Oracle的另一个知识点：recyclebin（回收站）。

凡是通过DROP操作删除的表，如果没有在操作代码中加purge，是没有被彻底删除的。被DROP掉的表都进入了Oracle的回收站，所以这让我们可以恢复因误用DROP操作导致的数据问题。且现在的Oracle数据库都是默认开启recyclebin的。

下面是关于回收站的基础介绍：

show parameter recyclebin

SELECT * FROM dba_recyclebin;

show recyclebin

purge recyclebin;

DROP TABLE TABLE_NAME PURGE

了解完回收站，可以开始进行闪回表操作了。

闪回SQL如下：

flashback table "BIN$F/CHkjSxeqLgY1g7qMByIw==$0" to before drop;

闪回步骤如下图：

 至此大家可以看到被DROP的表被闪回了，此时回收站也没有这个表的内容了哦！

Ⅱ：闪回至过去某时间点

扯句闲话，看过周杰伦的《大灌篮》没有？电影结尾，方世杰的球队因为裁判骚操作输了；方世杰一招乾坤大挪移把时间挪回比赛结束前，一记三分线外接力灌篮，方世杰球队又赢了。

当时就觉得，能逆转时间，真的牛叉。现在，Oracle的闪回技术就支持将表数据逆转到过去的某个时间点。

下面通过一个例子和大家分享Oracle的闪回如何 “逆转时间“。

DELETE FROM hr.ro WHERE others is null;

ALTER TABLE hr.ro ENABLE ROW MOVEMENT;

flashback table hr.ro to timestamp to_date('2024-05-08 09:00:59','yyyy-mm-dd hh24:mi:ss');

ALTER TABLE hr.ro DISABLE ROW MOVEMENT;

将表闪回至过去某个时间点的操作并不复杂，但有几点大家一定要注意！

• 注意场景！

这张表可能不止您一个人在操作，可能在此期间还有其他用户进行了操作；如果闪回会把其他用户在此期间的操作给搞没。所以谨慎使用，确保您的当下场景合适，再使用此操作！

举个例子，有次我使用闪回到过去某个时间点的操作。使用场景是该Oracle数据库是用来存储数据仓库的DW层数据；有同事误将某张表的历史数据删除了；但对于该表当天的数据而言，是通过ETL实时同步的，所以我可以放心的使用该闪回操作，不必担心有其他影响。

• 受限undo

这种闪回到过去的某个时间点的操作，都是使用undo中的前镜像数据。Oracle默认的undo保留时间是900s，超过这个时间，undo空间还够的话，就会继续保留；undo空间如果不够，不到900s也会把该undo数据覆盖掉。这个时候想闪回都没地方闪回了。如果delete或者update的数据量太大，甚至超过了undo表空间，那就只能闪回一部分数据了，不能闪回所有。

Ⅲ：闪回查询

闪回查询又分为三种查询方式：闪回时间点查询、闪回版本查询、闪回事务查询；下面分别对这三种查询进行说明。

• 闪回时间点查询

可以在undo数据有效期内，查询过去某个时间点的表数据。

闪回SQL如下：

select * FROM hr.ro as of timestamp to_timestamp('2024-05-08 20:37:00', 'yyyy-mm-dd hh24:mi:ss') where req_no = 'A1';

下面是操作例子：

• 闪回版本查询 

可以查询存在于两个时间点或两个SCN之间的所有行的版本。

查询SQL如下：

select 
versions_startscn, 
versions_endscn, 
versions_xid, 
versions_operation,
req_no, --业务表字段
others  --业务表字段
from hr.ro 
versions between timestamp 
to_timestamp('2024-05-09 22:16:00', 'yyyy-mm-dd hh24:mi:ss') 
and 
to_timestamp('2024-05-09 22:19:59', 'yyyy-mm-dd hh24:mi:ss')
where req_no = 'A2';

下面是操作例子：

其中有几个需要注意的点：

① 仅查询已提交的数据

② 不能用于查询外部表，临时表或视图

③ 无法跨越DDL命令

PS：做这个例子的时候，我花了半小时；最后发现自己傻逼的把虚拟机时间调到了第二天，导致一直查不出来  /(ㄒoㄒ)/~~（所以这也是为什么Oracle使用scn号记录标识数据库变化，而不是时间，因为操作系统时间有可能是错的）

• 闪回事务查询 

先给使用的用户赋予查询事务的权限

grant select any transaction to HR;

开启补充日志

alter database add supplemental log data;

查询补充日志是否开启

SELECT db.supplemental_log_data_min db FROM v$database db;
--返回YES，即开启

 查询SQL

select 
ftq.xid,
ftq.operation,
ftq.table_name,
ftq.table_owner,
ftq.row_id,
ftq.start_scn,
to_char(ftq.start_timestamp,'YYYY-MM-DD HH24:MI:SS') AS start_timestamp,
ftq.commit_scn,
to_char(ftq.commit_timestamp,'YYYY-MM-DD HH24:MI:SS') AS commit_timestamp,
ftq.undo_sql --不开启补充日志，此字段是空值
from flashback_transaction_query ftq 
where ftq.logon_user = 'HR' --使用的用户

以下是一个模拟测试：

update hr.ro set others = 'traquery'; 

SELECT req_no,  --业务表字段
       others,  --业务表字段
       to_char(versions_starttime, 'YYYY-MM-DD HH24:MI:SS') versions_starttime,
       to_char(versions_endtime, 'YYYY-MM-DD HH24:MI:SS') versions_endtime,
       versions_startscn,
       versions_endscn,
       versions_xid,
       versions_operation
  FROM hr.ro versions BETWEEN TIMESTAMP minvalue AND maxvalue
 ORDER BY versions_starttime;

select 
ftq.xid,
ftq.operation,
ftq.table_name,
ftq.table_owner,
ftq.row_id,
ftq.start_scn,
to_char(ftq.start_timestamp,'YYYY-MM-DD HH24:MI:SS') AS start_timestamp,
ftq.commit_scn,
to_char(ftq.commit_timestamp,'YYYY-MM-DD HH24:MI:SS') AS commit_timestamp,
ftq.undo_sql
from flashback_transaction_query ftq 
where ftq.logon_user = 'HR'
and ftq.xid = '010013006D050000'

Ⅳ：闪回事务

前面讲过了闪回至过去某时间点的操作，也说了这个操作有风险，可能会把别的用户提交的事务给一起咔擦了。闪回事务与之相比风险就小很多了，但风险也不是0。

为啥不是0呢？在这个专栏的 网络管理 和 session与process 两篇文章中都描述了Oracle的事务。对于一个事务A所操作的行数据，很有可能另一个事务B也对此行数据进行了操作；如果闪回了事务A，那么就会影响到事务B。

当然如果您觉得当下场景对于此事务之间的关系无所谓，不在乎事务A之后有多少事务进行了操作，只想将数据返回到事务A发生之前的状态，那就可以进行闪回。

操作如下：

① 在闪回事务查询的基础上，闪回事务需要再打开一个主键补充日志。

alter database add supplemental log data (primary key) columns;

② 通过SQL闪回事务需要使用到Oracle的程序包，所以需要增加用户的 dbms_flashback 的执行权限。

grant execute on dbms_flashback to HR;

③ 通过闪回版本查询，查询到需要闪回的事务的XID。

④ 通过 dbms_flashback.transaction_backout 执行闪回事务。

declare
     xids sys.xid_array;
    begin
     xids := sys.xid_array('01000A006F050000');
     dbms_flashback.transaction_backout(1,xids,options=>dbms_flashback.cascade);
    end;

xids := sys.xid_array('01000A006F050000');

数组内容，这里是填写xid，可以填写多个或1个。

dbms_flashback.transaction_backout(1,xids,options=>dbms_flashback.cascade);

这里的 1 指的是xid数量；

这里的 xids 指的是容纳xid的集合变量，就是在declare声明下面定义的那个；

这里的 options=>dbms_flashback.cascade 是参数选项，包含下面几个参数：

• NOCASCADE 

翻译下就是要闪回的事务不能和其他事务扯上关系，不然闪回GG；

• CASCADE

翻译下就是管你这几个事务有没有关系，直接级联闪回；

• NOCASCADE_FORCE

翻译下就是，比如有 A B两个事务有关系，忽略B，闪回A，如果没有约束错误（比如主键冲突啊）就能成功，否则GG；

• NONCONFILICT_ONLY

翻译下就是，比如有 A B两个事务有关系，闪回A，别影响B，否则GG；

其他闪回技术了解

除了以上的闪回技术外，Oracle还提供了以下技术：

• 闪回归档
• 闪回数据库

这俩技术我没有用过；因为在备份恢复体系中，我也没见过哪个项目用过这俩技术。因为不熟悉，也就不多写这块内容。大家权当听个响，有兴趣的可以去查下资料玩一玩。