ITPub博客

首页 > IT职业 > IT生活 > 一次惨痛的教训

一次惨痛的教训

原创 IT生活 作者:blue_prince 时间:2005-10-08 11:20:58 0 删除 编辑
国庆放假在家的时候,一个客户打电话说他们在做RMAN备份的时候提示一个数据文件出现坏块了。这个数据库是做DATA GUARD的,便跟客户说把备用库上的数据文件拷至主库上面,然后做恢复就行了。不过客户说在出现坏块之前DATA GUARD已经拿掉了,而且备用库的机器已经给另一个数据库用了。现在的情况是没有任何备份,只有每晚上做的EXP。由于放假在几千公里之外的老家,也没网络,让客户与另一个同事联系。后面客户说暂时不影响,也没要求做现场支援。只是让他做好备份,等放假过来后再来做。[@more@]

昨天早上还在火车上的时候客户便催着过去了。一下火车,把行李放到宿舍后,便直奔过去了。那时候比较累,坐了20多个小时的火车,也基本上不怎么睡觉,在去客户现场的路上还在担心会不会顶得住。到现场后,用DBVERIFY检查了一下那个数据文件,发现报了很多坏块。于是便查坏块对应的表,查了一下,数据居然是完整的。当时便怀疑是逻辑坏块,数据块并没有真正损坏。分布在那个坏数据文件上一共有47张表,包括对业务影响最大的几张大表。接下来便开始想对策了,当时有三个方案:1、将分布在那个数据文件上的表MOVE到另外的表空间上,然后将那个数据文件OFFLINE2、用Dbms_redefinition联机重组表,移至其他表空间;3、用on prebuilt materialized view将数据库上的所有表迁移至其他服务器上,当时想到这点主要是由于就算所有表都移走了,那个讨厌的数据文件还会留在数据库上,看着不舒服。

客户只有晚饭时40分钟的停机时间,也就是必须在这个时间段内完成。当时想23两种方案自己都未在生产库上做过,想用比较保守的第一种方案试一下。于是开始整理脚本,把move tablerebuild index的脚本都准备好了,只等一停线就开工。客户DBA说这样子也不知道能不能在40分钟内做完,要不先做一张大表看看。于是便拿他们业务影响最大的一张大表先来做试验,8G的一张表MOVE了将近20分钟。看来用MOVE是不行了,接下的时间只能是先把这张表对应的13个索引给REBUILD好。开了几个会话,把每个会话级的workarea_size_policy设为MANUALsort_area_size设为100M,便开始alter index rebuild online了。接下打开监听,让客户端连上来,想不影响他们的业务。

由于索引失效,他们业务根本无法进行下去。业务不停地在催,只能让他们先等等了。发现重建索引的速度非常之慢,查v$session_longops,居然一个索引得将近一个小时才能做好。当时想REBUILD应该是最快的方法了,而且已经重建了5个了,不想前功尽弃,只能任由慢慢来了。不过越拖越不对劲,这时候已经比预定的停机时间超过一个小时了,索引还是迟迟未重建好。客户的业务不停地打电话上来问到底什么时候能好,每次都说半个小时后就行,结果每次半个小时之后都不行。客户的DBA、业务和领导这时候在旁边一直催着,说这个宕机时间已经超过他们可以忍耐的极限了。查v$session_longops,看看还是不对劲,这样下去,要把剩下的8个索引重建好,起码是几个小时后的事情了。无奈只能关闭数据库,重打开数据库后关闭监听,不让客户端连上来操作。

重启数据库后想rebuild index肯定是不行了,于是把只能DROP INDEX,然后重新CREATE了。用nologging选项建了一个索引,发现速度果然快了很多,差不多只要4分钟左右了。于是便打开几个会话想一并来,报错资源锁定,只能一个个来了。于是便又开始了漫长的等待,中间客户领导召集他们DBA开会,业务的电话在不停地响着……

到了1940,终于把这张表对应的索引都建好了。从17点停机,到1940,额外宕机了两个小时。做完后便和客户交流了一下,责任的话是谁都无法担待的,只能他们领导向老板汇报了。客户要求接下来只有十足的把握下,再做其他46张表的迁移。目前不影响业务,先放在那边好了。当时想还是redefitinition最适合情况了,客户说要测试完整后再做迁移,让自己先回去。

想想真有些委屈,却无法对任何人诉说。走出客户的厂门,发现夜风已经很冷了……

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/60857/viewspace-807596/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2007-12-23

  • 博文量
    92
  • 访问量
    2217588