尴尬！安装异地备库时界面卡住，咋整？

周五到啦，心花怒放！

周五啦！熬了一周，想到明后两天可以放肆的撒欢，就非常开心！

可临近周五下班前，突然，“铃铃铃……”一阵急促的声音打破办公室的平静！

电话响起，问题来了！

“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更合适。

风险控制方面，开发团队反馈可协助监控程序后续所做的操作，故实际风险较小，客户最终也采用此方案。

经过几个小时的奋战，问题终于圆满解决！

伸伸懒腰，看看屏幕，望望窗外，花好月圆……

—— 看到这里的都是真爱——