记一次业务误删数据后的处理方法
5墨值下载
记录一次意外删除业务表数据的处理
在一个周六的中午，突然接到了客户的电话，说有一个很紧急的故障需要
处理，开发人员误删了一张业务表，且因为种种原因已经
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
发生，所以在上线的
之前就已经打开 了数据库的
ashback
，我寻思最差最 差就用
ashback
table
恢复这个表，虽然不如
ctas
创建备份表让开发人员倒腾数据对原表以及
业务影响小，但是也没什么其他好的办法了。执行
ashback table
命令，报
错，还是报快照过久。这个时候我就非常慌了，明明开了
ashback
了，为什
么还是报错。抓紧问问专家，才明白咋回事：
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
万左右的数据，客户同意采用风险
度较低的异机恢复方案，这才稍微放下点心来。
异机恢复还算顺利，我们从全备恢复出数据库来，归档也从备份里拉出来，
of 4
5墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论