客户数据库移植过程与教训

客户数据库移植过程与教训
 上周五开始进行我们最大客户的HMIS系统的移植工作,将P650上面的数据库Oracle 从8i升级到9i,
我们已经做了严格的实验和精密的计划,计划从2007.8.4 零点 开始 到 2007.8.5 20:00 结束;但为了
保险起见,我们向用户申请了从从2007.8.4 零点 开始 到 2007.8.5 18:00 停机时间,这个决策在后来
看来是多么的英明.
 我们在2007.8.4 17:00前就组织一个4人小组到了客户现场,在晚上吃饭前重新梳理了一下移植过程,
然后安排了一下工作重点.
 2007.8.4 12:00 发现用户数据传输并没有结束,无奈只能等待客户数据上传完才能进行工作,一直等到
00:30分,未开始工作计划就以及推迟了半个小时,感觉稍微有些不爽.在确认所有用户上传完毕后,我们马上
开始了紧急的工作,停掉数据库监听,停止job进行数据库导出到P650的磁盘阵列柜上;过程进行的非常顺利,大约在凌晨五点时,
数据库备份结束.
 关闭数据库实例,我叫醒在工作间的临时床铺上休息的同事,准备重新启动P650,按计划在重新启动数据库服务器后,
我就进行休息,由小季组织进行oracle9i的数据库安装和导入工作;不料意外马上就要发生了.
 在重新P650前,我一直在琢磨是不是要把exp出的dmp文件Copy到229的备份机器上,由于数据量较大40G左右,ftp过来大概也得
3-4个小时,为了效率起见,就没有备份.这个决定将马上被证明是多么的愚蠢.在我再三考虑之后,没有备份已经备份的文件,直接
输入命令shutdown -Fr 回车.P650马上进行启动;telnet窗口反馈证明服务器正常关闭,但在我们等了一个小时之后,
服务器也没有正常启动起来.
 马上感到了压力和紧张,找到机房的管理人员,登记申请到机房的临时输入卡,在6:00左右时进入机房看看机器情况,
最终发现在P650 lcd上显示了一个b10f1300的代号,当时并没有太紧张,认为关闭电源重新启动一下就好了;但是当怎么按
白色开关按钮没有反应的时候就真正紧张了;马上给ibm打电话,sn过期了,对方不提供服务.
 紧张马上升温,最终找到一个新的P570的序列号,打电话给IBM,然后查资料,最后得到IBM的回答和查P650 手册的错误信息一致,
Service processor failuer,建议拿细微工具捅lcd和电源按钮之间的小洞对Service processor 进行复位处理;按照手册捅了两下,
错误故障依旧!心理真正开始担心起来,不会是硬件故障吧.
 然后又根据指导,断掉主机电源,休息一会后重新接通电源,故障依旧,最后确认主板上的service processor损坏,需要更换主板.
 
 真正害怕起来.
 
 首先感觉真背,重启一下小型机竟然导致service processor failure的硬件故障,另外后悔没有将备份文件导出这个愚蠢的决定.
 
 当时的情况是,小型机硬件损害,需要更换主板,备份的数据在盘阵上,就是在备用机器上将环境搭建起来都没有数据文件.
 
 后来,找到一个专做小型机的朋友花了5-6个小时,在下午4点前才把数据从原来的盘柜上备份出来.
 
 后来朋友笑称,他们在重启小型机时,一般都要洗手以示尊重,祈祷不要出现问题.
 
 在数据备份出来后,又投入了紧张的工作,直到2007.8.5 10点才在备用机上将数据库重新搭建起来.
 
 由于原来硬件损坏,导致这次升级工作失败.虽然在备用机上已经将oracle升级到9i,但是还要等小型机修好后重新进行一次移植.
 
 教训总结如下:
 (1) 风险估计不足,没有将计划将备份数据备份到其它物理主机;
 (2) 没有考虑硬件损坏的情况,没有准备备用机器,虽然系统最后在一台P570上搭建起来,只是运气好,正好有一台机器;
 (3) 感觉巨背,shutdown -Fr 也会出问题.
 (4) 总之,以后做事情,需要考虑一切重大风险,并提出风险时的解决方案.越到风险时按方案进行.