本篇内容介绍了“误删数据库数据后的处理方法有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
创新互联是一家专业提供保康企业网站建设,专注与网站建设、做网站、成都h5网站建设、小程序制作等业务。10年已为保康众多企业、政府机构等服务。创新互联专业网站建设公司优惠进行中。
1.停库，起mount
2.flashback database to timestamp to_timestamp(‘2019-09-07 09:47:54’,‘yyyy-mm-dd hh34:mi:ss’);
3.alter database open read only;
4.查数据是否满足要求，expdp导出
5.停库 起mount
6.recover database;
alter database open;
测试环境下简单测试下可以操作，不过心里非常害怕，万一recover有问题，那不是这个表的问题了，整个数据库都回到47分54秒，影响非常巨大，内心十分抗拒这个方案，无奈影响太大，需要尽快恢复。不过后来和客户再三沟通该方案的风险性，再加上已经恢复了3000万左右的数据，客户同意采用风险度较低的异机恢复方案，这才稍微放下点心来。
异机恢复还算顺利，我们从全备恢复出数据库来，归档也从备份里拉出来，然后recover指定时间，一秒一秒recover，recover一秒查一次行数，最后数据量大约在3300万左右，该故障告一段落。
我认为本次故障我的失误占了很大一部分，本来对flashback不是很熟悉，误认为flashback table这个命令是依赖于flashback database on；实际上该命令完完全全是依赖于undo，和闪回查询是一个东西，对于一个自己不熟悉的技术，绝对不能自以为是的用于生产环境，任何一个变更操作都要在做了充足的测试后才能给客户使用，本次故障让我受益匪浅，以后我也将铭记于心，不会再发生类似事件。
亡羊补牢，事情结束后第一时间准备开启可以不依赖undo闪回查询表的flashback archive技术，这个flashback archive的粒度是表，可以闪回查询指定保留时间的数据，且不依赖undo表空间，如果想实现业务表的实时回溯，那flashback archive可以满足要求，flashback database 实用性不高，一般用在备库上居多，下面贴出我整理的flashback archive的简单步骤，可以参考参考：
flashback archive 测试：
开启flashback archive前提：
undo管理是AOTU
表空间必须是ASSM
1.创建flashback archive 表空间
create tablespace fba datafile ‘+DATADG’ size 10g;
2.创建flashback archive 区域
create flashback archive default fba1 tablespace fba retention 2 day; //创建时指定数据库默认闪回区域
查询：
select flashback_archive_name name, status from dba_flashback_archive;
select OWNER_NAME,FLASHBACK_ARCHIVE_NAME,FLASHBACK_ARCHIVE#,RETENTION_IN_DAYS,CREATE_TIME,LAST_PURGE_TIME,STATUS from dba_flashback_archive;
3.尝试修改保留时间：
alter flashback archive fba1 modify retention 1 day;
4.清空flashback archive中的全部信息：
alter flashback archive fba1 purge all;
清空1天前的信息：
alter flashback archive fba1 purge before timestamp (systimestamp - interval ‘1’ day);
5.创建测试数据
test1 2936192 384M
test2 2936192 384M
6.把test2 放到flashback archive 里面去
alter table test2 flashback archive fba1;
查询：
SELECT table_name,archive_table_name,status from dba_flashback_archive_tables;
7.都delete掉 18：07 左右
delete from test1;
delete from test2; 占用了1000m的表空间
8.做些别的操作确保清空undo
9.查询尝试：
test1已经无法查询：
select count(*) from test1 as of timestamp to_timestamp(‘2019-09-18 18:01:00’,‘YYYY-MM-DD HH24:MI:SS’)
*
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 10 with name “_SYSSMU10_1251597811$” too small
test2 可以在开启后查询任意时间的数据：
SQL> select /*+ parallel(16) / count() from test2 as of timestamp to_timestamp(‘2019-09-18 18:20:00’,‘YYYY-MM-DD HH24:MI:SS’);
“误删数据库数据后的处理方法有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！