讨论:说说你所经历的数据危机?

大家一起说说看所经历过的数据危机,有没有备份的?有备份失效的?有备份周期过长?丢失数据过多的?等!

6回答

岳彩波岳彩波  产品经理 , 无
gz_kevinaixkevinTonyWang等赞同了此回答
分享很久以前记录的一个事吧晚上11点多,客户突然打来电话,说数据库崩溃了,通过了解详细情况,得知崩溃的原因是因为换电源,停机(停机过程正常),在开机存储就丢失了。在这里我想提醒各位同仁,在做任何操作之前,一定要把生产库备份一个全备,以防万一,并要查看之前的备份是否都正常,还要收...显示全部

分享很久以前记录的一个事吧
晚上11点多,客户突然打来电话,说数据库崩溃了,通过了解详细情况,得知崩溃的原因是
因为换电源,停机(停机过程正常),在开机存储就丢失了。
在这里我想提醒各位同仁,在做任何操作之前,一定要把生产库备份一个全备,以防万一,并要查看之前
的备份是否都正常,还要收集一下数据库的相关信息,参数文档,控制文件,以及一些基本的数据库名称
DBID等,万万不可大意,以下是恢复过程。
客户的运气比较好,他的全备是在周六晚,出问题是周日的晚上,但是他的数据库是8*5的,数据只要恢复
到16号晚上就可以,过程比较曲折
因客户对数据库不太熟悉,很多路径,什么的都不清楚,只能自己来收集。
1、通过alert日志中的信息先找到DBID,RMAN连接要使用;
2、恢复参数文件,和控制文件,并启动到mount状态;
3、恢复之前的目录架构,因为是SAP的数据库,目录有几百个,只能一个一个的对比;
4、写了两个恢复脚本,执行恢复;
5、恢复完成,400G数据不算多,但也恢复了2小时左右;
6、让客户启动应用,测试了一下,数据库恢复正常,不会耽误第二天早晨的使用。
在测试应用的是的,我发现他的数据库响应比较慢,但由于时间的关系,没有帮他优化。这次恢复算是比较幸运
,客户有完整的备份,虽然少了一天,但是这是周末,只要恢复到前一天的数据就可以了。
这个能恢复,算是不幸中的万幸,如果备份无效,基本任何数据也恢复不了。

收起
 2017-07-26
浏览763
aixchina 邀答
hufeng719hufeng719  系统工程师 , 山东莱钢永锋钢铁
xijiehaiqingaixchina赞同了此回答
第三方厂商误操作删除ERP部分模块的表数据。利用昨日的备份加归档日志进行恢复的显示全部

第三方厂商误操作删除ERP部分模块的表数据。利用昨日的备份加归档日志进行恢复的

收起
 2017-07-27
浏览725
aixchina 邀答
潘延晟潘延晟  系统工程师 , 第十区。散人
风风aixchina赞同了此回答
曾经用TSM。客户端写的脚本进行SQL SERVER的备份。因为当时的业务环境混乱,正式数据和历史数据,备份数据混在一起,磁带机的容量又不足,所以不得不手工挑选那些是要每天备份的。那些是临时备份的。那些是按年备份的。结果疏于沟通和检查,一个新上线的库没有添加进每天的备份任...显示全部

曾经用TSM。客户端写的脚本进行SQL SERVER的备份。因为当时的业务环境混乱,正式数据和历史数据,备份数据混在一起,磁带机的容量又不足,所以不得不手工挑选那些是要每天备份的。那些是临时备份的。那些是按年备份的。结果疏于沟通和检查,一个新上线的库没有添加进每天的备份任务中。后来数据出错。结果备份中就没有这个。。。。。

收起
 2017-07-26
浏览759
aixchina 邀答
喂小饱me9喂小饱me9  数据库运维工程师 , chinapay
aixchina赞同了此回答
oracle数据库某张表数据tuncate之后,还要将部分数据使用impdp导回,数据量大概有6亿,当时由于等待时间较长,就将这个jod kill掉了,导致这些数据占用大量回滚段,且数据库资源都用在回滚上,新的数据写进来非常的慢,因为有OGG的同步库,所以当时没有用备份集做恢复...显示全部

oracle数据库某张表数据tuncate之后,还要将部分数据使用impdp导回,数据量大概有6亿,当时由于等待时间较长,就将这个jod kill掉了,导致这些数据占用大量回滚段,且数据库资源都用在回滚上,新的数据写进来非常的慢,因为有OGG的同步库,所以当时没有用备份集做恢复

收起
 2017-08-04
浏览669
邓毓邓毓  系统工程师 , 江西农信
aixchina赞同了此回答
我也来说一个吧DB2 V8.1 32位应用系统为数据平台日志LSN号满,造成数据库宕机,无法启动由于数据库较大6T,恢复了几乎3天3夜,当时请了IBM LEVEL3的美国佬恢复的LSN序号,将它清零,然后才可以将数据库实例启动,但是数据是无法进行更新操作的,只能将数据库的所有表,用IMPORT操作导出,然...显示全部

我也来说一个吧
DB2 V8.1 32位
应用系统为数据平台
日志LSN号满,造成数据库宕机,无法启动
由于数据库较大6T,恢复了几乎3天3夜,当时请了IBM LEVEL3的美国佬恢复的LSN序号,将它清零,然后才可以将数据库实例启动,但是数据是无法进行更新操作的,只能将数据库的所有表,用IMPORT操作导出,然后再导入到新的数据库当中,由于数据库版本太老,也不支持联邦方式导数据,也不支持游标方式,花了大量时间对数据恢复,最后导完数据后,对原表的数据量进行统计,看和新表是否一致。
最后才将数据库给应用使用。
对于这种大数据量的数据库,平时又无法备份,出现问题确实非常麻烦。
所以后面我们对这种大数据量的数据库所在的存储每天都做快照,保留两份快照,循环。来规避以后类似的问题。

收起
 2017-07-30
浏览683
aixchina 邀答
tt_45tt_45  技术经理 , eenese
aixchina赞同了此回答
在CLONE DB的过程中手误,将源库的database file 全部删除了,大约1TB,幸亏有全库备份,有归档日志,很快将全库恢复了。显示全部

在CLONE DB的过程中手误,将源库的database file 全部删除了,大约1TB,幸亏有全库备份,有归档日志,很快将全库恢复了。

收起
 2017-07-26
浏览730
aixchina 邀答

提问者

zxl1982系统架构师, 九州证券

问题状态

  • 发布时间:2017-07-26
  • 关注会员:7 人
  • 问题浏览:3572
  • 最近回答:2017-08-04
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2020  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30