首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >巧用闪回数据库来查看历史数据 (r10笔记第47天)

巧用闪回数据库来查看历史数据 (r10笔记第47天)

作者头像
jeanron100
发布2018-03-19 18:02:20
5960
发布2018-03-19 18:02:20
举报

国庆期间有一个例行维护的任务,需要在大早上7点起来,先根据业务指定的SQL查出指定数据,然后运行一个存储过程来更新数据。 查出来的这部分数据需要作为后期的数据稽核所用,涉及到审计,所以优先级还是比较高的。 因为这样的查询有几个,所以为了统一数据格式,先加了rownum看看数据的基本情况。 SQL类似于下面的形式: select cn 账号,present_point 剩余积分点 , last_date 积分最后更新时间 from test.user_present_point_sp where present_point > 0 and last_date < to_date('2016-10-07','yyyy-MM-dd') and rownum<10; 操作的过程很快就完成了。因为在内网环境,而且又是使用V**,这部分数据要拷贝出来还是有一些难度,就和同事商量能不能上班了之后再提供,同事也很爽快,就答应了。 上班的时候,离这个操作的时间已经过去了近3天。 当我把数据提供给同事的时候,同事发现有一个查询的数据出入太大,完全对不上。我查看当时操作的日志发现,这下坏了,语句执行错了。 应该执行的语句是: select cn 账号,present_point 剩余积分点 , last_date 积分最后更新时间 from test.user_present_point_sp where present_point > 0 and last_date < to_date('2016-10-07','yyyy-MM-dd'); 而我当时格式化的时候竟然给忘了去掉rownum<10 ,那个查询只返回了9条数据。想想这已经过去了好几天,怎么能够保证数据的准确性呢。 带着侥幸心理,尝试通过闪回查询来完成,但是发现这次确实不走运,回滚段还是不满足要求,毕竟时间已经过去了好几天了。 select cn 账号,present_point 剩余积分点 , last_date 积分最后更新时间 from test.user_present_point_sp as of timestamp to_timestamp('2016-10-06 08:00:00','yyyy-mm-dd hh24:mi:ss') where present_point > 0 and last_date < to_date('2016-10-07','yyyy-MM-dd') * ERROR at line 1: ORA-01555: snapshot too old: rollback segment number 22 with name "_SYSSMU22_163011606$" too small 这个时候问题就摆在了我的面前,这个问题该怎么解决。首先不能作假,其次这部分内容是要提供的,完全能没有办法通过日志 或者其它的方式来间接得到了。 这个时候我想到了我之前的一个完美的决定。那就是一主两备,在异机备库开了闪回数据库的特性。保留的时间是4天,这下我是这个问题的真正受益者了。 来看看在备库做真实的闪回数据库操作是否可行,这次艰巨的任务就靠它了。 首先确认备库的状态: SQL> select flashback_on,database_role,open_mode from v$database; FLASHBACK_ON DATABASE_ROLE OPEN_MODE ------------------ ---------------- -------------------- YES PHYSICAL STANDBY READ ONLY WITH APPLY 确认了时间点,就准备停库,停库前还是需要确认是否有其它的业务连接。 SQL> select username,count(*)from v$session group by username; USERNAME COUNT(*) ------------------------------ ---------- 50 PUBLIC 5 SYS 1 启库到mount阶段,闪回到具体的时间点。 flashback database to timestamp to_timestamp('2016-10-06 07:20:00','yyyy-mm-dd hh24:mi:ss'); 这个闪回的过程因为涉及到的闪回日志还是蛮多的,所以持续时间就略微长一些。大概有15分钟的样子。 Sat Oct 08 11:14:59 2016 flashback database to timestamp to_timestamp('2016-10-06 07:20:00','yyyy-mm-dd hh24:mi:ss') Flashback Restore Start Sat Oct 08 11:27:03 2016 Flashback Restore Complete Flashback Media Recovery Start started logmerger process Parallel Media Recovery started with 24 slaves Flashback Media Recovery Log /U01/app/oracle/fast_recovery_area/SGCDB2/archivelog/2016_10_06/o1_mf_1_3696_czc0wj0f_.arc Flashback Media Recovery Log /U01/app/oracle/fast_recovery_area/SGCDB2/archivelog/2016_10_06/o1_mf_1_3697_czc540wp_.arc Sat Oct 08 11:27:15 2016 Incomplete Recovery applied until change 229374582017 time 10/06/2016 07:20:01 Sat Oct 08 11:27:15 2016 Flashback Media Recovery Complete Completed: flashback database to timestamp to_timestamp('2016-10-06 07:20:00','yyyy-mm-dd hh24:mi:ss') Sat Oct 08 11:29:34 2016 再次查询,数据就是当时的状态了,就和一个完整的快照一样,如果对闪回时间有疑问,还可以再次闪回,直到满足要求,经过比对,发现数据准确无误。 重启数据库,开启日志应用,备库又开始接受应用归档了。整个过程也是有惊无险,我也在这个过程中对闪回数据库有了更深入的理解。对此我有几点感触,一个就是如果异机备库的空间较大,日志量不是非常大,可以考虑将闪回的时间设置长一些。对于很多操作来说,还是需要尽可能保留一些关键的日志,没准哪天那些看似不重要的时间戳就非常重要了。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-10-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
对象存储
对象存储(Cloud Object Storage,COS)是由腾讯云推出的无目录层次结构、无数据格式限制,可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限,无需分区管理,适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档