我这里说的rac one node是11203版本,如果我们为了主动进行维护进行计划内切换,比如进行:
srvctl relocate database -d lteidba -n osslteidb2
这里是为了主动维护的计划内手工动作,这里是SWITCHOVER,比如如上举例,我把实例1从节点1:osslteidb1
推到节点2:osslteidb2:
这时grid他会自动帮我们做如下动作:
1 首先自动在节点2上创建pfile( init.ora);
2 在节点2上他会依此新的参数文件启动实例;
3 完成手工的SWITCHOVER,此时在节点2上实例的名称会自动更新为_2,一般的说和主机实例编号对应;
如果是计划外的意外的节点CRASH:突然异常CRASH还是主机层面的误操作导致CRASH:
这时grid他会自动帮我们做如下动作:
1 现在原来节点努力启动实例,当然如果此时主机crash了,自然没法做这个尝试了;
2 主机crash了自然1努力是枉然了。所以他只能选择在节点2把实例 FAILOVER过来 ,因为是
FAILOVER,所以实例名称没有变化,即没有 自动更新为_2,而仍然是_1了。
srvctl relocate database -d lteidba -n osslteidb2
这里是为了主动维护的计划内手工动作,这里是SWITCHOVER,比如如上举例,我把实例1从节点1:osslteidb1
推到节点2:osslteidb2:
这时grid他会自动帮我们做如下动作:
1 首先自动在节点2上创建pfile( init.ora);
2 在节点2上他会依此新的参数文件启动实例;
3 完成手工的SWITCHOVER,此时在节点2上实例的名称会自动更新为_2,一般的说和主机实例编号对应;
如果是计划外的意外的节点CRASH:突然异常CRASH还是主机层面的误操作导致CRASH:
这时grid他会自动帮我们做如下动作:
1 现在原来节点努力启动实例,当然如果此时主机crash了,自然没法做这个尝试了;
2 主机crash了自然1努力是枉然了。所以他只能选择在节点2把实例 FAILOVER过来 ,因为是
FAILOVER,所以实例名称没有变化,即没有 自动更新为_2,而仍然是_1了。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/13750068/viewspace-1200278/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/13750068/viewspace-1200278/