周六下午，一个同事打电话给我说，一个系统的连不上了，连telnet都做不了。于是赶到了单位。到了以后才知道，是AIX出问题了。负责操作系统的同事说，只能升级操作系统来尝试能不能修复。有可能出现的结果就是操作系统修复了，但是一些文件系统被破坏，数据库软件不能使用。因为管理操作系统的同事在外地不能立刻赶回，只好在第二天上午开始做。

    一开始以为他说的是一个测试系统，跑到论坛区发帖求助，看看能不能把Oracle11g ASM里面的数据导出来。结果周日负责项目的同事告诉我，那是个刚上线不久的生产系统，既没有做备机（之前我曾经催促过他把备机装好），数据也没有完全备份。我真的是各种无奈。好在那是个内部管理系统，周末基本不用。

    操作系统已经开始安装，我们几个讨论了一下，决定兵分两路：

    1.第一组人开始安装备机，把Oracle安装好，然后把不完全备份的数据导入备机。一旦主机不能在周一之前弄好，先用备机上线使用。项目负责人比较抵触ASM，决定改回文件系统。这样的话，就没法用原来的ASM磁盘。

    2.第二组人等到主机操作系统修复完之后，尝试把库恢复，实在不能恢复就把ASM里面的数据导出。

    我开始是在第一组，整个备机的安装很快，不到一个小时就搞定了，数据导入需要一些时间但这个时间并不长，因为这个系统是刚上线的内部管理系统，数据量不大。差不多在周日中午的时候就已经全部完成。后续的中间件和应用和我关系不大，就没再跟进。

    下午操作系统修复后，我加入了第二组。数据库需要重装。ASM因为是独立的存储，所以得以保留。grid infrastructure和oracle都装好之后，把之前的ASM磁盘mount成功。startup nomount这一步就开始报错，多数都是和pfile的配置相关。修改了一些pfile参数，但是还是不能启动。考虑到后面还有可能出现未知的问题，我决定先把ASM里的数据导入到备机中。毕竟这是第一次做ASM的恢复，所以还是很谨慎。

    论坛有朋友提出用AMDU导出数据，11g里面集成了这个工具。稍微摸索了一下就把所有的数据文件都导出来了。是*.f格式的。然而在往备库里面导入的时候，却提示字符集有问题。主机在之前是装了几个中文语言环境的，而备机没有。这也提醒了我修复操作系统后的主机也需要重装这些字符集。

    字符集都装好后，我又打开pfile看了一遍，无意之中发现了一个路径，这个目录在重装Oracle之后因为没有建库是不存在的。突然想起论坛一位朋友的回帖说要建立目录。把这个目录手动建了一个，直接startup，居然成功了！很低级的错误，还是经验不足所致。controlfile和datafile都没有问题，好在之前把controlfile放在了ASM和文件系统各一份。

    这下主机的库恢复成功了，可以继续使用。后续的工作还是中间件和应用，在乙方工作人员的努力下，剩下的问题基本就是时间问题了。

    回到家已经是12点多。一个周末一多半时间都用在了这个既没有容灾备份又没有数据备份的系统上。

    总结一下，有如下几个教训和收获：

    1.备份。负责备份的运维同事并没有收到这个系统相关负责人需要备份数据的请求。所以数据始终没有做过全备，手头的数据即使是恢复也不能完全恢复。这点很要命。好在ASM里面的数据没有问题。

    2.备机。可能是对备机的理解不同，上线后我问相关同事备机环境都做好了吧，他回答我是。可是他认为操作系统装好就可以了。事实上不仅仅应该安装数据库，还应该做好相关的容灾策略，比如双机热备或者dataguard。遗憾的是都没有。

    3.ASM数据导出。学会了AMDU的使用，是个很方便的工具，集成在了Oracle11g里面，拿过来就可以用。可以对ASM里面的数据进行冷备份。

    后续的工作其实还远远没有结束，如何让相关项目组的同事以及乙方工作人员对这些问题引起足够的重视尤其重要。过分依赖外包终究还是不行的。