ITPub博客

首页 > 数据库 > Oracle > 记一次业务人员误删数据后的处理方法

记一次业务人员误删数据后的处理方法

Oracle 作者:云和恩墨 时间:2020-03-27 16:48:05 0 删除 编辑
摘要:一次业务人员删除数据后,恢复的思路,供参考,有问题欢迎指出

原文链接(阅读原文提升阅读体验): https://www.modb.pro/db/23209?cyn 

记录一次意外删除业务表数据的处理
在一个周六的中午,突然接到了客户的电话,说有一个很紧急的故障需要处理,开发人员误删了一张业务表,且因为种种原因已经commit,现在需要恢复。虽然后来才知道是非常核心的业务表(以下称表A),当天这个操作已经严重影响电信用户查询修改各种套餐,不过当时并没有想到影响这么大,后续的处理过程也让给我一个深刻的教训。
由于以前也经历过类似的事件,当时的时间约是10点10分左右,客户和我说操作时间在9点50分左右,时间不算常,第一时间想起用undo闪回查询保留数据:
select * from table_name as of timestamp to_timestamp(‘2019-xx-xx xx:xx:xx’,‘YYYY-MM-DD HH24:MI:SS’);
10点15查询当前A表的才200多条,查9点55 229条,查9点53分就160多万行,不过数量级还是不对,客户说正常应该1200万左右,再闪回查询,这期间可以看到随着时间往前推移行数在不断增加:10点51的980万,10点50的时候就变1500万,9点49的时候有 2300万,9点48分10秒的时候有3000万,9点48分0秒就报快照过久了。不过我发现9点48分08秒到9点48分10秒这段时间内行数没有减少,行数在3000万左右;介于刚才的查询每一秒行数都在减少的情况下,我主观认为这个时刻可能就是delete之前行数最大的时刻,和客户沟通这个行数也和业务对得上,48分0秒undo就过期了,当时觉得有点幸运,抓紧create table as select 创建出备份表,数据出来了后续就让开发人员折腾数据就行了,以为这事结了,准备吃口饭时,客户打来电话,说数据还是不对,还是少。不过这时我也没太慌,因为在设计这套库的时候就已经考虑到可能有这种delete发生,所以在上线的之前就已经打开了数据库的flashback,我寻思最差最差就用flashback table恢复这个表,虽然不如ctas创建备份表让开发人员倒腾数据对原表以及业务影响小,但是也没什么其他好的办法了。执行flashback table 命令,报错,还是报快照过久。这个时候我就非常慌了,明明开了flashback了,为什么还是报错。抓紧问问专家,才明白咋回事:
alter database flashback on;
这条命令开启的是数据库级别的闪回,并不代表数据库中的每个表随时都能闪回,数据库级别的闪回只能把整个数据库闪回到某个时刻;这样就非常棘手了,和专家和客户商量,想出了一条解决方案:
1.停库,起mount

2.flashback database to timestamp to_timestamp(‘2019-09-07 09:47:54’,‘yyyy-mm-dd hh24: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’);

COUNT(*)

2936192


更多Oracle故障恢复相关文章: https://www.modb.pro/tag/oracle?cyn 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29715045/viewspace-2682948/,如需转载,请注明出处,否则将追究法律责任。

全部评论

注册时间:2014-06-19

  • 博文量
    117
  • 访问量
    115100