oracle数据库某张表数据tuncate之后,还要将部分数据使用impdp导回,数据量大概有6亿,当时由于等待时间较长,就将这个jod kill掉了,导致这些数据占用大量回滚段,且数据库资源都用在回滚上,新的数据写进来非常的慢,因为有OGG的同步库,所以当时没有用备份集做恢复
收起我也来说一个吧
DB2 V8.1 32位
应用系统为数据平台
日志LSN号满,造成数据库宕机,无法启动
由于数据库较大6T,恢复了几乎3天3夜,当时请了IBM LEVEL3的美国佬恢复的LSN序号,将它清零,然后才可以将数据库实例启动,但是数据是无法进行更新操作的,只能将数据库的所有表,用IMPORT操作导出,然后再导入到新的数据库当中,由于数据库版本太老,也不支持联邦方式导数据,也不支持游标方式,花了大量时间对数据恢复,最后导完数据后,对原表的数据量进行统计,看和新表是否一致。
最后才将数据库给应用使用。
对于这种大数据量的数据库,平时又无法备份,出现问题确实非常麻烦。
所以后面我们对这种大数据量的数据库所在的存储每天都做快照,保留两份快照,循环。来规避以后类似的问题。
曾经用TSM。客户端写的脚本进行SQL SERVER的备份。因为当时的业务环境混乱,正式数据和历史数据,备份数据混在一起,磁带机的容量又不足,所以不得不手工挑选那些是要每天备份的。那些是临时备份的。那些是按年备份的。结果疏于沟通和检查,一个新上线的库没有添加进每天的备份任务中。后来数据出错。结果备份中就没有这个。。。。。
收起分享很久以前记录的一个事吧
晚上11点多,客户突然打来电话,说数据库崩溃了,通过了解详细情况,得知崩溃的原因是
因为换电源,停机(停机过程正常),在开机存储就丢失了。
在这里我想提醒各位同仁,在做任何操作之前,一定要把生产库备份一个全备,以防万一,并要查看之前
的备份是否都正常,还要收集一下数据库的相关信息,参数文档,控制文件,以及一些基本的数据库名称
DBID等,万万不可大意,以下是恢复过程。
客户的运气比较好,他的全备是在周六晚,出问题是周日的晚上,但是他的数据库是8*5的,数据只要恢复
到16号晚上就可以,过程比较曲折
因客户对数据库不太熟悉,很多路径,什么的都不清楚,只能自己来收集。
1、通过alert日志中的信息先找到DBID,RMAN连接要使用;
2、恢复参数文件,和控制文件,并启动到mount状态;
3、恢复之前的目录架构,因为是SAP的数据库,目录有几百个,只能一个一个的对比;
4、写了两个恢复脚本,执行恢复;
5、恢复完成,400G数据不算多,但也恢复了2小时左右;
6、让客户启动应用,测试了一下,数据库恢复正常,不会耽误第二天早晨的使用。
在测试应用的是的,我发现他的数据库响应比较慢,但由于时间的关系,没有帮他优化。这次恢复算是比较幸运
,客户有完整的备份,虽然少了一天,但是这是周末,只要恢复到前一天的数据就可以了。
这个能恢复,算是不幸中的万幸,如果备份无效,基本任何数据也恢复不了。