在应用10.2.0.3补丁集后Oracle集群产品的变化
Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.3 to 10.2.0.3 - Release: 10.2 to
10.2
Oracle Server - Standard Edition - Version: 10.2.0.3 to 10.2.0.3 [Release: 10.2 to
10.2]
Information in this document applies to any platform.
Oracle Clusterware version 10.2.0.3 and above
目的
这个注释的目的是注释在oracle clusterware组件中的行为的变化。
范围和应用
这个注释倾向于系统管理员和数据库管理员的职责来操作oracle
Clusterware
Changes in Oracle Clusterware after applying 10.2.0.3 Patchset
介绍一些和从早期的释放中的改变不同。关系到用ifconfig来测试failoverVIP行为上的变化。到10.2.0.3版本以前的可能通过简单的运行ifconfig来测试。在linux上行为一样，在其他系统上则不行。当应用补丁集10.2.0.3时在RAC资源依靠上的改变。补丁集释放带来一些改变。
优点：从网络失败的情况下更快的恢复时间以及不用有效网络为应用提供存储链接。
10.2.0.3版本以前的补丁集的释放：RAC 数据库实例。ASM 实例和监听器都依靠节点应用VIP源码。在应用10.2.0.3补丁集到Oracle集群产品中。这种依赖性在节点应用VIP ASM实例 和 RAC实例被自动移除。依赖性将会继续存在监听器和VIP AND 和RAC 数据库实例中间。
补丁集
10.2.0.3以前的版本
当公用网络适配器失败时发生了什么。
VIP资源被重新定位到集群中其他节点，监听器资源下线，RAC实例下线，ASM实例如果在线也下线，ASM和RAC实例同其他消除注册。
10.2.0.3以后的版本
VIP资源被定位到集群的另一个节点，监听器资源下线，RAC实例持续并把一般的操作限制住，ASM一直持续，ASM和RAC实例同其他消除注册
在集群中的监听器
为什么依赖性改变？
原因有二。第一，运行在相同的节点上的单个数据库实例。当ASM实例被Oracle Clusterware关闭，单一的数据库实例将会无法进入它的数据库文件并且最后实例被关闭。第二，Oracle代码的提高使它没有必要让实例从集群的数据库中分离。
当VIP在10.2.0.3补丁集重定位时服务的变化
当VIP重定位时，服务被节点上的实例操纵会在实例上不可用。
如果在其他实例上有'preferred'这个状态，它将会长驻在这些实例上，如果是'available'状态，
服务就会在其中一个实例上可用，如果在VIP失败和在其它实例上没有'available'状态时，服务只
有'preferred'状态在实例上，服务不可用直到VIP返回到节点。
当公用适配器回来时发生什么？
VIP将会重新定位会它的主节点，将会发生下一次Oracle Clusterware检查实例。检查被实施，默
认的，每六百秒 。这是在重定位被触发之前能通过的最大的时间量。VIP能通过srvctl开始节点应
用来手动定位回它的主节点。当创建一个新的RAC集群数据库时发生什么?
如果DB主程序升级到10.2.0.3，通过dbca将来新的实例被创建，没有依赖Nodeapps VIP的实例会被安装。
测试此功能
记住在断开公共网络后再测试功能，如果不这样，你将不能ssh或者vnc到节点。你应该能ssh/vnc尽管其它节点内部互联。
在测试VIP failover，首先用Oracle Clusterware堆停止和禁用和确保节点能在数据库运行中断开测试之前还存在环境中来尝试公网断开测试。
如下是一个用RAC集群中2节点来测试的例子，
* Create and start a new service which is ‘Preferred’ on Node1 and ‘Available’ on
Node2.
* On Node2 run lsnrctl stat. You will see that the new service is being provided by
inst1.
* On Node1 disconnect the public network adapter cable. The listener on that node will
stop but the RAC database and ASM instances will stay up. The RAC database and ASM
instances from node1 will be deregistered from the listeners on other nodes in the
cluster.
* On Node2 repeat the lsnrctl stat command you will see that the service is now being
provided by inst2, Oracle Clusterware relocates the service to one of it’s
‘available’ instances.
* On Node1 replace the public adapter cable.
* The VIP will relocate back to node1, or you can use the “srvctl start nodeapps –n
node1” to trigger a relocate of the VIP. The listener on Node1 will be restarted by
Oracle clusterware. The RAC database and ASM instances will re-register with all the
listeners in the cluster. The service will NOT be relocated back to Node1
automatically.
* A FAN callback can be added to automatically fallback service if this is the desired
behavior. Note that fallback disrupts ongoing work. Download this callback from
http://otn.oracle.com/rac - sample scripts page.
其它著名例子
* Rolling upgrade or upgrade of Oracle Clusterware to 10.2.0.3 patchset may cause VIP
to move to the last node. This is also documented in the 10.2.0.3 patchset readme.
Workaround:
Enter the following command to relocate the VIP to the preferred node:
srvctl start nodeapps -n
* @On all Linux OS (x86, X86-64 and itanium using OCFS2) bringing down the private
network of any node causes all the nodes to panic, Although this issue is not specific
to 10.2.0.3 patchset, it is included here because this was re-discovered during
10.2.0.3 testing. This is an OCFS2 issue, A fix is being tested until that time,
please do not test bringing down the private network on production.
* @On windows 2003 RC2 with CRS_HOME on OCFS, lowest node crash can cause a hang of at
least 2-5 minutes
当前位置：
论坛首页 »
自由讨论区 »
MySQL, Oracle及数据库讨论区
»
发起投票
技术讨论
加好友
发消息
2012-3-5 9:32:09 |
赞(
操作
