« Oracle RAC VIP的依赖 »
Oracle » http://www.anysql.net/oracle/oracle_rac_vip_depend.html 2008-01-03Oracle 10G RAC中多了一个VIP资源, 也许应当叫服务, 如下所示, 其中db01, db02, db03都是RAC节点的名称.
[root@db02 oracle]# crs_stat | grep vip
NAME=ora.db01.vip
NAME=ora.db02.vip
NAME=ora.db03.vip
正常安装后, 有两个资源或服务依赖于vip这个资源, 分别是listener和instance.
[root@db02 oracle]# crs_stat | grep db01
NAME=ora.db01.LISTENER_DB01.lsnr
NAME=ora.db01.gsd
NAME=ora.db01.ons
NAME=ora.db01.vip
NAME=ora.racdb.db01.inst
这样也就是说如果vip出现服务, RAC会自动停止监听器和数据库实例. 停止监听器, 我们可以理解, 因为vip的问题造成数据库实例停止, 我认为是有些不合理的. 监听器还是依赖于vip服务, 但数据库实例不会依赖于vip服务, 可以说整个RAC系统中, 比较弱的环境就是这个vip服务了.
不知道这样的设置合理不? 象在9i RAC中是没有vip服务的, 因此实例和vip不应当有依赖关系.
存在即合理, ^_^
从10.2.0.3开始，instance和asm应该是不再信赖vip。在10.2.0.3中，更改vip地址不需要停instance，而此前的版本需要。metalink DocId 391454.1也提到10.2.0.3开始instance不再依赖vip。
10.2.0.3以前的版本中,其实可也可以改的,我现在就已经改掉了.
crs_stat -p xxx > xxx.cap
vi xxx.cap
crs_unregister xxx
crs_register xxx -dir ./
只要你不让instance 随 vip 一起启动，而手工启动 instance 的话，停 vip 资源就不会停 instance。 这样即使vip 因为一些故障（还老有人遇见）切换，instance还在的，可以再手工启动vip资源把vip拉回来。
当然如果使用public ip监听 则vip 就失去作用了。 vip 目前最有效的是让 failover 更快速。但10gR2(10.2.0.2) 中看起来不适合跟instance 挂在一起。
在metalink上看到一个vip的bug, 说是如果网络负荷太重的话, crs有可能会认为vip失败. 改进的方法是增大check_timeout和script_timeout这两个选项.
网络负荷不重…… 有时可能也发生这种问题，增加这个值只是延缓接管的概率，但真实发生的时候系统相互之间无法通讯也很严重的，增大这两个值不能从根本上解决问题。
因为06年的时候我使用10.2.0.2 rac 深为这个问题所困，最后只好抛弃 vip ！
上面说的不严谨，修正一下。 我也修改过这些值，但发现问题发生的时候系统其实并没有什么负载（每次都是深夜），网络流量也不大。 增大这个值也依然不行，因为并不是很快就恢复正常。 所以我宁愿vip切换 instance 不 down 而保持系统可用。 同时我监听了public ip。 这样系统发生这种情况（几乎每个月一次）的时候我可以不着急去处理，等有空的时候再把vip拉过来就可以了。
vip和listener绑定在一起比较好, 让instance不依赖于vip就行了.
from 10.2.0.4 and 11.1, instance will not depends on VIP anymore.
这个问题在itpub上已经讨论过了。
从10gR1开始到现在10gR2的最新版本10.2.0.3，oracle不停地在调整跟Oracle Clusterware相关的部分，包括各种资源的依赖关系，还有各种check timeout的算法，几乎每个小版本都有不同的地方。
你说的check_timeout这事儿，恐怕还是跟css timeout相关，10.2.0.2之前的版本是一种比较不靠谱的算法，10.2.0.2之后好很多。
BTW：MT的留言系统体验真不好，还是你这里不好？Firefox下面留言完了一个白窗口，成功没不知道？
留完言后, 应当回到原来页面的啊.
10.2.0.3以后就不是instance依赖vip了