设为首页 收藏本站
查看: 401|回复: 0

[经验分享] [原]记一次使用flashback恢复数据,警惕自己不要浮躁,还是太嫩了

[复制链接]

尚未签到

发表于 2015-6-16 10:36:37 | 显示全部楼层 |阅读模式
  周五晚十点多,同事突然来电称操作CMS后台的时候不小心删除了很多记录(其实应该是这个CMS的逻辑问题),大概了解了情况以后,能初步判断为p_web表的2万多条数据被delete了,事发时间大概在9:30左右,这种场景几乎就是“专门”为flashback而设的了。
  于是马上翻开书找到flashback那节书,先鄙视一下自己,以前所学的都还给书本了。
  确认一下可以flashback的极限是多少
select
min(start_timestamp)
from
flashback_transaction_query
where
table_name='P_WEB'
and table_owner='CMS'
  结果是前天的下午3点,比预期中的时间要长很多啊。
  由于p_web表数据量不大,还不到100M,赶紧做个“备份”,免得突然犯浑把剩下的2万多条记录都整丢了,那就可以跳楼了:

create table p_web_bad
as
select * from p_web;
  使用flashback query将9:20的数据放在一个p_web_20100507_0920表里面,让同事看看效果先:

create table p_web_20100507_0920
as
select
*
from
p_web
as of timestamp to_date('2010-05-07 21:20:00','yyyy-mm-dd hh24:mi:ss');
  其实我也是笨,脱离了表现层的数据能看出什么呢?除了“感觉”上是正确的一点说服力也没有。
  同事说这个数据没问题。为了进一步确定事发的准确时间点,使用flashback transaction query 将自8:30以来的所有undo操作列出,这样可以找出什么时候开始删除的了。

create table p_web_undo_20100507_2030
as
select
start_timestamp,operation,undo_sql
from
flashback_transaction_query
where
table_name='P_WEB'
and table_owner='CMS'
and start_timestamp>to_date('2010-05-07 20:30:00','yyyy-mm-dd hh24:mi:ss')
order by
start_timestamp desc
  经过一个简单的查询从start_timestamp 能查出是21:39:04开始删除的,只要将flashback到21:38:00问题就OK了啦。

flashback table p_web
to timestamp to_date('2010-05-07 21:38:00','yyyy-mm-dd hh24:mi:ss');
  此时,报了一个错:

ORA-08189: cannot flashback the table because row movement is not enabled
  小问题,enable row movement 就是了

alter table p_web enable row movement;
  我再闪(flashback):

flashback table p_web
to timestamp to_date('2010-05-07 21:38:00','yyyy-mm-dd hh24:mi:ss');
  shit!竟然出现了flashback的克星:

ora-01555 snapshot too old
  明明前面查到可以flashback的时间很长的啊,莫非是前面几个大create table把undo内容刷走了,这也太快了吧@_@!
  先不管了,我同事还在着急的等待,虽然没有催我,但是“弄丢”数据的心情我很清楚。
  幸好前面创建了一个p_web_undo_20100507_2030表,里面有一对undo的sql,可以将被delete的数据再insert回去。
  于是写了个简单的过程做这件事:

declare
v_undo_sql varchar2(4000);
CURSOR cur is select substr(undo_sql,1,length(undo_sql)-1) --将undo_sql最后那个分号去掉
from p_web_undo_20100507_2030 where operation='DELETE';
BEGIN
open cur;
loop
fetch cur into v_undo_sql;
EXIT when cur%NOTFOUND;
execute immediate v_undo_sql;
--dbms_output.put_line(v_undo_sql);
END LOOP;
CLOSE cur;
END delete_state ;
  经过“漫长”的等待,终于将误删的数据恢复回来了。
  
  经过这次数据恢复让我认识到:
  1。虽然掌握了基本概念,但是熟练程度还不够,体现在临急翻书上。
  2。实际操作经验欠缺,整个过程实际上没多少东西,但是却足足折腾了一个半小时。
  3。前瞻性不足,这个数据库是我维护的,对于误操作删除数据这种问题应该要有所觉悟,就这个问题而言,我做的措施仅仅是扩大了undo表空间。
  总的来说,就是太嫩了。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-77873-1-1.html 上篇帖子: 数据库错误集锦 下篇帖子: Linux 环境下Oracle PRO*C程序的编写简单范例
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表