美文网首页
记一次补数据的经历

记一次补数据的经历

作者: 小尘哥 | 来源:发表于2018-10-15 21:01 被阅读15次

最近又发生了丢数据的事情,比较郁闷,解决完问题后,对年前和此次的丢数据的事件做个记录,欢迎大家贡献更好的解决方法。

问题描述

在20171228交易日收市结束后,对2017年历史库hisdb中归档到historysettlement这个schema的增备数据进行了例行检查,经过与生产库DB1的数据比对,发现20170511这个交易日的增量备份数据丢失了。

这个记录了客户成交回报、操作日志的historysettlment下居然没有归档?在DB1中只保留近半年的数据,数据库增备、全备定期删的情况下,....

首先说明一下生产库DB1的备份方式:一周一次数据库全备(expdp导出dmp文件,压缩后大概10G左右),每天收市作业结束后导出DB1增备数据(CSV文件,压缩后大概800M左右),同时DB1增备数据导入至HISDB中。

那如果有20170511那一天的增备问题不是就能解决了?看到一丝曙光,赶紧回去找备份,ε(┬┬﹏┬┬)3 20170511增备已被删除,紧接着的3个星期的全备也被删了,but,找到了DB1 20170602那一天的全备,20170602的全备是DB1截库后( 4月28号截库)包含0511的数据后的全备,现在唯一的方法就是从全备中抽取20170511的数据然后导入到历史库中。

操作之前,确认在20170511到20171228之间historysettlement 下的一些常用表的表结构没有变化,如t_operationlog、t_brokeruserevent、t_tmdbtrade/t_tmdborder、t_marketdata。

操作如下:

1、备份:生产环境hisdb做数据泵全库备份。

2、数据准备:

1)搭建测试数据库(表空间总共分配150G大小,参考DB1的表空间使用率)。

2)导入DB1-20170602全备数据,时间比较久,夜晚进行.......

3)记录导入后的20170511常用表的数据量,便于验证。

4)使用软件供应商提供的每日expdp增备工具抽取20170511的增备数据。

5)将增备数据导入公司另一个DB2(日常和DB1数据实时同步)环境中验证,导入后比对常用表的数据量,结算系统柜台登录信息查询正常。

3、数据恢复:经过验证的增备数据导入生产环境hisdb中,导入语句如下:

impdp system/oracle@ctp1 schemas=historysettlement directory=dumpdir dumpfile=expdp_schema_historysettlement_20170511.dmp tables=historysettlement.t_% content=data_only table_exists_action=append logfile=impdp_schema_historysettlement_20170511.log

impdp system/oracle@ctp1 schemas=report directory=dumpdir dumpfile=expdp_schema_report_20170511.dmp tables=report.t_% content=data_only table_exists_action=append logfile=impdp_schema_report_20170511.log

注意:现在是补充对已有数据的表中进行数据插入,因此这里使用append方式。

4、重建索引(看情况执行):

    select 'historysettlement schema' from dual;

    execute dbms_stats.unlock_schema_stats('HISTORYSETTLEMENT');

    execute dbms_stats.gather_schema_stats('HISTORYSETTLEMENT');

    select 'alter index '||t.owner||'.'||t.index_name||' rebuild nologging;' from dba_indexes t where t.owner='HISTORYSETTLEMENT';

5、验证:导入完成后,检查导入log,无异常,hisdb中部分表的数据记录比对一致,前台查询0511历史数据正常。

图片1.png

DB1表空间使用率

图片2.png

部分常用表的数据量

总结:现在数据恢复完成了,数据为什么会丢失一天呢?当前的运维流程中,每天都要进行增备数据归档至历史库,收市作业时间跨度比较长,一般情况下,在19:30夜市开市作业前能完成数据归档工作,特殊情况可能延迟,而下午收市作业的最后一步表数据量比对,在业务繁忙时便被忽略了,造成过了很久才发现数据丢失的情况。

应对办法:在每周的运维流程中,针对historysettlement,加入上周的DB1和HISDB数据比对的情况,对差异较大的表予以关注,并进行维护,运维无小事,还是要靠运维的同事细心啊。

未完待续.............

相关文章

  • 保护好群晖的数据

    记一次设置数据损毁经历Posted by SunnyRx on September 30, 2018原文地址:ht...

  • 记一次 Google 面试经历

    记一次 Google 面试经历 记一次 Google 面试经历

  • 记一次补数据的经历

    最近又发生了丢数据的事情,比较郁闷,解决完问题后,对年前和此次的丢数据的事件做个记录,欢迎大家贡献更好的解决方法。...

  • 记一次数据恢复的经历

    小x同学的U盘出了问题,症状就是插在电脑上时图一提示: 图一 点击“取消”后,我的电脑可以,在设备和驱动...

  • 不过人傻钱多

    记一次伴娘经历

  • 凤凰游记

    记一次凤凰古城的经历

  • 记一次经历

    2018年7月11日,“港澳七日游”回来的第三天,因为不是我主动联系的团所以很多细节问题都不是很清楚,而后来的我...

  • 记一次经历

    每一次经历都是很宝贵的,都是对自己的一次锻炼。积极向上,淡定从容。活到老,学到老。

  • 石头记|红楼往事1

    曹雪芹著作的石头记,便是红楼梦。因曾经历一番梦幻之后,借通灵之说,来表达自身的经历之过。女娲补天的时候,只用了三万...

  • 记一次租房的经历

    在这个周末,我开始了在北京的第一次搬家,其实很早我就决定不续租原来的房子,当时看到了58或者赶集上面的房子还觉得自...

网友评论

      本文标题:记一次补数据的经历

      本文链接:https://www.haomeiwen.com/subject/dluqzftx.html