相干概念
Flashback Data Archive是什么
Flashback data archive是oracle 11g中引入的一个新个性。Flashback archive是一个新的数据库对象，用于存储一个或多表的历史数据。Flashback archive是一个逻辑对象，概念上相似于表空间。实际上flashback archive能够看作是存储一个或多个表的所有事务变动的逻辑空间。Oracle 11g 中 Flashback Data Archive 个性。将变动数据另外存储到创立的闪回归档区（Flashback Archive）中，以和 undo 区别开来，这样就能够为闪回归档区独自设置存储策略，使之能够闪回到指定工夫之前的旧数据而不影响 undo 策略。并且能够依据须要指定哪些数据库对象须要保留历史变动数据，而不是将数据库中所有对象的变动数据都保留下来，而只是记录了指定表的数据变动。所以，Flashback Data Archive 是针对对象的爱护，是 Flashback Database 的无力补充。
它和Flashbak的区别？
在Oracle中的flashback 包含： flashback version query、flashback transaction query、flashback database、flashback table和flashback drop等个性。
在这些闪回技术当中，除了Flashback Database（依赖于闪回日志）之外，其余的闪回技术都是依赖于Undo撤销数据，都与数据库初始化参数UNDO_RETENTION密切相关。
它们是从撤销数据中读取信息来结构旧数据的。这样就有一个限度，就是undo中的信息不能被笼罩。而undo段是循环应用的，只有事务提交，之前的undo信息就可能被笼罩，尽管能够通过 undo_retention等参数来缩短undo的存活期，但这个参数会影响所有的事务，设置过大，可能导致undo tablespace疾速收缩。
换句话说：个别的数据库内undo_retention只设置了900秒，如果事务量太大，在产生误操作后undo内的事务被其余顶掉或超过900秒，那么就无奈通过flashbak进行复原。而Flashback Data Archive和undo无关，是独自创立一个闪回归档区，把表级的历史记录都存到归档区外面，能够随时查看表级对象的历史状况。
模仿用Flashback Data Archive复原
环境筹备
数据库版本：Oracle Database 11g Enterprise Edition Release 11.2.0.4.0
是否开启归档：否
是否为RAC：否
建设测试表插入测试数据
建设一个测试表test_table_delete，插入数据如下图所示
查问time_stamp内的数据和执行打算
select * from test_table_delete as of timestamp to_timestamp('2020-09-17 13:55:09','yyyy-mm-dd hh24:mi:ss');
能够看到，此时的打算走的是test_table_delete这张表的全表扫描，先记着，前面有用。
创立一个用来存储闪回归档的表空间
能够应用现有表空间，但Oracle倡议最好应用专用表空间
对表空间的要求：
（1）Flashback data archive只能在ASSM的tablespace上创立
（2）Flashback data archive要求必须应用主动undo治理，即undo_management参数为auto
create tablespace fa_data datafile '/opt/ora_data/fa_01.dbf' size 1G;查看咱们创立的fa_data表空间是否符合要求：
select dbt.TABLESPACE_NAME,dbt.SEGMENT_SPACE_MANAGEMENT from dba_tablespaces dbt where dbt.TABLESPACE_NAME = 'FA_DATA';SEGMENT_SPACE_MANAGEMENT为AUTO代表为ASSM形式段治理的表空间
数据库的undo_management参数也为AUTO
Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 Connected as lijian@oraclevmSQL> show parameter undo NAME TYPE VALUE------------------------------------ ----------- ------------------------------undo_management string AUTOundo_retention integer 900undo_tablespace string UNDOTBS1创立一个闪回归档区
语法：
create flashback archive fa_data tablespace fa_data quota 50M retention 1 year;qutoa前面跟的是闪回归档区的大小，retention前面跟的是要保留多久的历史数据。qutoa如果不设置，默认自增；当闪回归档区数据超过retiontion设置的值时Oracle会主动清理。
查看闪回归档、闪回归档和表空间的关系
select * from dba_flashback_archive;select * from dba_flashback_archive_ts;把测试表调配到闪回归档区
alter table test_table_delete flashback archive fa_data;查问DBA_FLASHBACK_ARCHIVE_TABLES视图能够取得曾经归档的表
select * from dba_flashback_archive_tables;模仿delete操作（更新不频繁的表）
因为测试库没有那么大量的事务，所以undo会保留很长时间
这里为了模仿，所以采纳的看执行打算的形式来判断是否走了Flashback Data Archive
并且上面所有的操作，都没有用flashbak操作命令，为的就是区别这两种做法
操作过程：删掉一条数据
复原指标：复原到表里之前5条数据的状况
delete from test_table_delete where cityid =1002;commit;SQL> select * from test_table_delete;CITYID CITYNAME-------------------------------------------------- --------------------------------------------------1001 吉林1003 武汉1004 成都1005 四川再来看一下之前SQL的执行打算
发现打算里曾经走了DBA_FLASHBACK_ARCHIVE_TABLES里的表，阐明曾经调用到闪回归档的信息，当初查问进去的数据就是走的Flashback Data Archive，不走undo了
进行复原
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;TO_CHAR(SYSDATE,'YYYY-MM-DDHH2------------------------------2020-09-17 14:47:09 --获取当初的工夫-- 这里的2020-09-17 14:25:54能够始终往前找，delete后理论表里存在4条数据-- 咱们须要找到一个工夫点，外面有5条数据的。SQL> select * from test_table_delete as of timestamp to_timestamp('2020-09-17 14:25:54','yyyy-mm-dd hh24:mi:ss');CITYID CITYNAME-------------------------------------------------- --------------------------------------------------1002 长春1001 吉林1003 武汉1004 成都1005 四川-- 这里咱们间接用insert into语句，where条件后跟cityid=1002，因为咱们晓得删的数据是哪条。SQL> insert into test_table_delete (select * from test_table_delete as of timestamp to_timestamp('2020-09-17 14:25:54','yyyy-mm-dd hh24:mi:ss') where cityid = 1002);1 row insertedSQL> commit;Commit complete-- 能够看到，id=1002,cityname=长春的数据被咱们复原回来了。-- 无论是删除1条还是多条，还是删除后表里又新增数据，只有晓得过后删除的条件，都能够找回来。SQL> select * from test_table_delete;CITYID CITYNAME-------------------------------------------------- --------------------------------------------------1002 长春1001 吉林1003 武汉1004 成都1005 四川模仿truncate操作
truncate表操作，用
flashbak命令是无奈进行闪回的
但Flashback Data Archive将不可能变成了可能。复原指标：
truncate后复原到新增3条数据之前的5条记录
- truncate后复原到8条记录
-- 我又新增了3条数据进去SQL> select * from test_table_delete;CITYID CITYNAME-------------------------------------------------- --------------------------------------------------1002 长春1006 甘肃1007 上海1008 北京1001 吉林1003 武汉1004 成都1005 四川8 rows selectedCommit completeSQL> truncate table test_table_delete;Table truncatedSQL> select * from test_table_delete;CITYID CITYNAME-------------------------------------------------- ---------------------------------------------------- 用之前5条记录的工夫点来看，是否还能查出来数据SQL> select * from test_table_delete as of timestamp to_timestamp('2020-09-17 14:25:54','yyyy-mm-dd hh24:mi:ss');CITYID CITYNAME-------------------------------------------------- --------------------------------------------------1002 长春1005 四川1003 武汉1004 成都1001 吉林-- 咱们能够将这个sql的后果insert到test_table_delete表里来实现truncate后的复原SQL> insert into test_table_delete (select * from test_table_delete as of timestamp to_timestamp('2020-09-17 14:25:54','yyyy-mm-dd hh24:mi:ss'));5 rows insertedSQL> commit;Commit complete-- 5条数据被复原回来SQL> select * from test_table_delete;CITYID CITYNAME-------------------------------------------------- --------------------------------------------------1002 长春1005 四川1003 武汉1004 成都1001 吉林-- 再执行一遍truncate，这次要复原8条数据SQL> truncate table test_table_delete;Table truncated-- 找到存在8条记录的工夫SQL> select * from test_table_delete as of timestamp to_timestamp('2020-09-17 15:00:00','yyyy-mm-dd hh24:mi:ss');CITYID CITYNAME-------------------------------------------------- --------------------------------------------------1002 长春1006 甘肃1007 上海1008 北京1005 四川1003 武汉1004 成都1001 吉林8 rows selected-- 用Insert语句进行复原SQL> insert into test_table_delete (select * from test_table_delete as of timestamp to_timestamp('2020-09-17 15:00:00','yyyy-mm-dd hh24:mi:ss'));8 rows insertedSQL> commit;Commit completeSQL> select * from test_table_delete;CITYID CITYNAME-------------------------------------------------- --------------------------------------------------1002 长春1006 甘肃1007 上海1008 北京1005 四川1003 武汉1004 成都1001 吉林8 rows selectedSQL> 对于Drop table的操作
对于退出了归档空间的table，进行删除的时候会产生一个报错，强制不让你drop这个表
从另一种角度来说，也是存在肯定的平安因素。
如果非要删除，那么须要用dbms_flashback_archive包来解除关联关系，咱们来试验一下。
SQL> drop table test_table_delete;drop table test_table_deleteORA-55610: 针对历史记录跟踪表的 DDL 语句有效SQL> EXEC DBMS_FLASHBACK_ARCHIVE.DISASSOCIATE_FBA('LIJIAN','TEST_TABLE_DELETE');PL/SQL procedure successfully completedSQL> drop table test_table_delete;drop table test_table_deleteORA-55610: 针对历史记录跟踪表的 DDL 语句有效SQL> exec dbms_flashback_archive.reassociate_fba('LIJIAN','test_table_delete');PL/SQL procedure successfully completed发现执行了dbms_flashback_archive包来解除关联关系，咱们也无奈drop table
网上的材料说是Oracle的一个bug，也有材料说是在11.2版本修复的，然而我是11.2.0.4试过了也不行
既然drop不行，那么测试下rename和一些增加、批改字段的操作，具体的测试步骤不写了，大略是这样：
- 在原表减少一个字段，不必波及到
dbms_flashback_archive包的相干操作，间接新增就能够，在主表减少实现后闪回归档空间的对象表主动减少一个列，如图所示：
2.如果主表中删除一个列，也不须要波及到dbms_flashback_archive包的相干操作，间接删除就能够。然而删除后在闪回归档空间的对象表里存在一列记录，如图所示：
3.要还原删除列后的表，须要先在主表上减少字段后从对应工夫点内复原
- 如果不须要在闪回归档空间的对象表里保留曾经删除列的信息，则须要用
dbms_flashback_archive包进行解除关系，之后删除回归档空间的对象表里的列。 - 如果真要强行
drop table，那么只能解除表和闪回归档空间的关系，带来的结果是无奈再复原之前的历史记录。
alter table test_delete no flashback archive;总结
通过Flashback Data Archive，咱们能够更好的治理表级别的复原，然而应用Flashback Data Archive也有一些限度。
比方咱们应该布局数据库中哪些表是十分重要的，将它们退出到闪回归档区里。
另外还须要独自为空间进行布局，这须要肯定的存储用来保留你冀望的历史数据。
对于频繁批改的表，可能不太实用。
以上。