某项目KT技术小结

澳洲的某项目的knowledge transfer（KT）已经过去一周了，了解到了不少更详细的项目信息，大部分是关于IBM的流程，其中一些是关于技术的。我把技术的部分做了一个的小结。

（1）养成一个良好的工作习惯，在登录主机之后，习惯性的设置环境变量：

注意ORAENV_ASK这个参数和oraenv配合使用。当设置ORAENV_ASK=YES时，运行oraenv会提示当前的数据库sid：

（2）再说一下好的工作习惯，arch在任何时候都不要轻易删除，哪怕目录已经被撑爆，而启动备份需要切出备份日志，因此比较好的方式是将部分（非最后一个）arch mv到新路径，再建立软链之后，启动备份脚本。

（3）solaris中的ping命令，需要加-s参数：

（4）rman proxy
rman proxy copy使用感觉在国内用的不是很多，而且在网上甚至metalink上能找到的资料也不多。大致的情况是将备份的控制权交由第三方的备份软件来操作，不再由rman来控制什么时候、如何将data从datafile备份到磁带上。rman proxy copy不能用type disk的参数。注意rman proxy copy不备份控制文件。

（5）该项目中的22个节点的cluster。
之前和澳洲人的交流中说起过他们有一个22节点的cluster，之前还以为是rac，现在终于了解到了是veriats cluster，有15台机器组成，其中11台机器是active的，4台机器是passive。每个机器上有2个数据库，因此11台active的主机就组成了22个数据库cluster。

Veritas cluster server可以监控到各项组件如数据库、网络、主机、存储。当检测到这些组件发生意外时，就会shutdown发生问题的节点，在另外的可用节点上启动。

从相关介绍来看，veritas cluster server有不少优点，但是我感觉还是存在不少不足：
（5.1）VCS号称Availability across any distance，支持数千英里的数据传输，但是传输的消耗如何，延时如何没说，在不同的操作系统上性能如何也没说。从远程rac的数据来看，已经建立的项目，用VCS来做远程RAC，最远距离没超过50公里。
（5.2）我不认为VCS的fireDrill能将数据库直接恢复，并且启动到open状态。除非利用底层存储的复制技术，如HP CA（HP Continuous Access XP）。

改项目采用的是11+4 roaming spare，当11个节点中任意一个主机宕机的时候，都会在4个节点中选择一个转移。在极端情况下，cluster同时坏4台，转移到standby的4台机器上。这样的情况概率非常小，如此的架构，即节省了成本，不是一台机器做一个双机热备，还把出问题的概率降到了很小。确实不错。

最后提一下，veritas有如此强大的cluster，这么多节点，oracle自身能实现吗？How about Rac one node or single instance HA？