Oracle数据库基础之8_闪回

闪回技术分以下几类

闪回查询:Flashback Query

闪回版本查询:Flashback Version Query

闪回事务查询:Flashback Transaction Query

闪回表:Flashback Table

闪回删除:Flashback Drop

闪回数据库:Flashback Database

其中闪回查询,闪回版本查询,闪回事务查询,闪回表这四种闪回都是基于undo实现的,闪回删除Flashback Drop是基于回收站来实现的,闪回数据库Flashback Database是基于闪回日志来实现的。

闪回查询:Flashback Query

select * from A as of scn 1095782;

select * from A as of timestamp sysdate-5/1440;

闪回版本查询:Flashback Version Query

select column1,column2,versions_startscn,versions_starttime,versions_xid,versions_operation from A versions BETWEEN SCN MINVALUE AND MAXVALUE order by 3

闪回事务查询:Flashback Transaction Query

必须启用ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;否则flashback_transaction_query.undo_sql结果为空

Select xid,operation,commit_scn,undo_sql from flashback_transaction_query where xid in

(Select versions_xid from A versions between scn minvalue and maxvalue)

闪回表:Flashback Table

必须启用ALTER TABLE t1 ENABLE ROW MOVEMENT;否则执行flashback table时会报错: ORA-08189: 因为未启用行移动功能, 不能闪回表

需要ROW MOVEMENT的原因

每一行数据都对应一个row_id,记录了数据存放的具体位置,哪个数据文件、哪个数据块、哪行

比如1行数据被删除了,这行对应的数据块就空了,一旦有其他数据插入,可能就会写入到这些到数据块上,也就是这行数据的位置被其他数据占用了,以后如果要恢复这行,因为原先的位置被其他数据占用,就要改变这行数据的位置,这就是row movement

flashback table t1 to scn XX

闪回删除:Flashback Drop

每个表空间都会有一个叫作回收站的逻辑区域,当用户执行drop命令时, 被删除的表和表的关联对象( 包括索引, 约束,

触发器,LOB段,LOBindex 段) 不会被物理删除, 这些对象先转移到回收站中,这就给用户提供了一个恢复的可能。闪回丢弃是指将被丢弃的数据库对象及其相依对象的拷贝保存在回收站中,以便在必要时能够及时恢复这些对象。在回收站被清空以前,被丢弃的对象并没有从数据库中删除,这就使得数据库能够恢复被意外或误操作而删除的表。

drop table t1;

show recyclebin;

select object_name,original_name from user_recyclebin;

flashback table t1 to before drop;

闪回数据库Flashback Database

要想使用Flashback Database, 必须使用Flash RecoveryArea,因为Flashback Database Log 只能保存在这里。 要配置的2个参数如下,一个是大小DB_RECOVERY_FILE_DEST_SIZE,一个是位置DB_RECOVERY_FILE_DEST。

startup mount;

alter database flashback on;

alter database open;

shutdown immediate;

startup mount;

Flashback database to timestamp to_timestamp('09-10-14 14:37:05','yy-mm-dd hh24:mi:ss');

Flashback database to SCN XX;

alter database open resetlogs;

直接alter database open resetlogs打开数据库,当然,指定scn或者timestamp时间点之后产生的数据统统丢失。如果不想丢数据,可以先执行alter database open read only命令以read-only模式打开数据库,然后立刻通exp(expdp不行因为expdp必须在readwrite下操作)方式将误操作涉及表的数据导出,再执行recover database命令以重新应用数据库产生的redo,将数据库修复到flashback database操作前的状态,然后再通过逻辑导入的方式,将之前误操作的表重新导入,这样的话对现有数据的影响最小,不会有数据丢失。

相关推荐
袋鼠云数栈7 小时前
让 SQL 解析不再重复造轮子:SqlParserX 正式开源
数据库·人工智能·sql·开源·数据治理
这个DBA有点耶7 小时前
期货 CTP 系统 Oracle RAC 迁移国产库实战:读写分离架构设计与性能对标
数据库·架构·dba
数据库安全7 小时前
AI数据访问安全 |如何控制AI访问权限,防止越权
数据库·安全
这个DBA有点耶8 小时前
Redo Log循环写与checkpoint推进:长事务阻塞下的Checkpoint风暴完整链路
数据库·mysql·代码规范
jnrjian8 小时前
pg_waldump --key-file-name status 查看wal 产生的db
数据库
SelectDB技术团队9 小时前
Snowflake 的开源替代怎么选:能力对照、三条部署路径与迁移执行
大数据·数据库·云原生·开源·snowflake·apache doris
Elastic 中国社区官方博客9 小时前
告别繁琐控制台:Kabanos 如何将 MongoDB Compass 的易用性带入 Elasticsearch
大数据·数据库·mongodb·elasticsearch·搜索引擎·全文检索
京东云开发者9 小时前
当我谈数据库高可用时我谈些什么
数据库
梦影_9 小时前
MySQL进阶教程(一)—— 储存过程与触发器(上)
开发语言·数据库·后端·sql·mysql·中间件
星禾元亨10 小时前
用结构化数据与干净实体信号,让技术内容被 AI 搜索引擎稳定引用
数据库·人工智能·自动化·创业创新