某项目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?

相关文章

一条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.