在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的。
下面是关于回收站的基础介绍:
1、查看回收站是否开启 value为on即为开启,但其实现在的Oracle都是默认开启的。 2、查看回收站内容 查询 dba_recyclebin 系统表 或者 在对应用户下 show recyclebin 3、清空回收站 4、彻底删除一张表 |
了解完回收站,可以开始进行闪回表操作了。
闪回SQL如下:
flashback table "BIN$F/CHkjSxeqLgY1g7qMByIw==$0" to before drop;
闪回步骤如下图:
至此大家可以看到被DROP的表被闪回了,此时回收站也没有这个表的内容了哦!
Ⅱ:闪回至过去某时间点
扯句闲话,看过周杰伦的《大灌篮》没有?电影结尾,方世杰的球队因为裁判骚操作输了;方世杰一招乾坤大挪移把时间挪回比赛结束前,一记三分线外接力灌篮,方世杰球队又赢了。
当时就觉得,能逆转时间,真的牛叉。现在,Oracle的闪回技术就支持将表数据逆转到过去的某个时间点。
下面通过一个例子和大家分享Oracle的闪回如何 “逆转时间“。
1、时间 :2024-05-08 09:01:00 我对 HR.RO 表 执行了批量 DELETE 操作,且提交。 2、时间 :2024-05-08 09:05:00 领导跑来质问我:你把 hr.ro 表 others 字段 为 NULL 的都删了?你他喵删错了,应该是删掉不为NULL的值。 3、时间 :2024-05-08 09:05:30 我气定神闲:多大点事儿嘛!再给你恢复行了吧 ╮(╯▽╰)╭ 4、时间 :2024-05-08 09:06:00 于是我表面稳定内心慌的一批的执行了如下操作 开启hr.ro表的行移动 闪回hr.ro表 到删除前时间点 关闭hr.ro表行移动 5、此时 hr.ro 表的数据恢复到 2024-05-08 09:00:59 这个时间点时的状态,数据逆转成功。 |
将表闪回至过去某个时间点的操作并不复杂,但有几点大家一定要注意!
- 注意场景!
这张表可能不止您一个人在操作,可能在此期间还有其他用户进行了操作;如果闪回会把其他用户在此期间的操作给搞没。所以谨慎使用,确保您的当下场景合适,再使用此操作!
举个例子,有次我使用闪回到过去某个时间点的操作。使用场景是该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' --使用的用户
以下是一个模拟测试:
1、测试表 hr.ro 2、更新忘记加where条件(已提交) 3.1、先通过闪回版本查询,查询到对应事务的xid 结果集如下: 3.2、通过事务xid,查询到对应的undo_sql,看到底发生了什么 查询结果集如下,可以发现是什么时候,发生了什么操作。 如果想揪出谁做的这个操作,可以通过xid去查询会话动态性能视图,查看是哪个主机干的哦。 |
Ⅳ:闪回事务
前面讲过了闪回至过去某时间点的操作,也说了这个操作有风险,可能会把别的用户提交的事务给一起咔擦了。闪回事务与之相比风险就小很多了,但风险也不是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还提供了以下技术:
- 闪回归档
- 闪回数据库
这俩技术我没有用过;因为在备份恢复体系中,我也没见过哪个项目用过这俩技术。因为不熟悉,也就不多写这块内容。大家权当听个响,有兴趣的可以去查下资料玩一玩。