周五到啦,心花怒放!
周五啦!熬了一周,想到明后两天可以放肆的撒欢,就非常开心!
可临近周五下班前,突然,“铃铃铃……”一阵急促的声音打破办公室的平静!
电话响起,问题来了!
“XX,我们安装异地的备库失败,E-OBAR界面一直处于安装恢复的状态,已经20多个小时了!快帮我们看看!”
来电的客户跟我们关系很铁,彼此相知相伴多年。
放下电话,远程连上,一切都是那么熟练和自然。
看完吓一跳,确实如客户所说,界面一直卡住状态。
由浅入深,层层分析
“你们是不是有做什么特殊的操作?”
以个人职业敏感性判断,问题没那么简单。
于是开始耐心地先安抚客户,让客户冷静地将问题事无巨细地描述清楚。
环境介绍
(1)系统:E-SIM6.0
(2)操作系统&数据库版本:LINUX 6.5,ORACLE11.2.0.4,单实例
(3)E-OBAR版本:2.3
问题定位,真相大白
仔细交流前因后果,再通过查询后台进程发现已经没有RMAN的恢复,判断是由于网络问题,导致rman连接的ssh断开;
并且通过查询恢复日志,得知异地的备库已经完成了restore database的操作。
找到原因了,客户和我都松了一口气。
2种方案,哪个合适
针对问题,我给出2种解决方案:
方案1:重新安装异地备库
方案2:手工执行剩余的恢复操作:
(1)手工进行recover database
(2)强制关闭E-OBAR
(3)备库执行create spfile from pfile;
关闭数据库并启动到mount状态
(4)备库执行ALTER SYSTEM SET AUDIT_TRAIL='NONE' scope=SPFILE;
(5)启动E-OBAR,右键启用备库
(6)备库执行 /obar/tools/实例名/CreateTempTableSpaces.sql
但是!这2种解决方案各有风险:
方案1,重新安装耗时较长,而且无法避免再次出现网络异常的情况;
方案2,手工操作有一定的风险,需要跟E-OBAR开发团队核实程序后续的操作风险。
方案确定,圆满解决
将2种方案及风险告知客户,同时结合当前系统状况,建议方案2更合适。
风险控制方面,开发团队反馈可协助监控程序后续所做的操作,故实际风险较小,客户最终也采用此方案。
经过几个小时的奋战,问题终于圆满解决!
伸伸懒腰,看看屏幕,望望窗外,花好月圆……
—— 看到这里的都是真爱——
领取专属 10元无门槛券
私享最新 技术干货