Wednesday, February 15, 2017

How to relocate RAC Database Services?

$ srvctl relocate service -h

Temporarily relocates service from one node of the cluster to another.

Usage: srvctl relocate service -d <db_unique_name> -s <service_name> {-i <old_inst_name> -t <new_inst_name> | -c <current_node> -n <target_node>} [-f]
       Specify instances for an administrator-managed database, or nodes for a policy managed database
    -d <db_unique_name>      Unique name for the database
    -s <service>             Service name
    -i <old_inst>            Old instance name
    -t <new_inst>            New instance name
    -c <current_node>        Node name to relocate service from
    -n <target_node>         Node name to relocate service to
    -f                       Disconnect all sessions during stop or relocate service operations
    -h                       Print usage

Exmaple:
-------

[oracle@uktul02oradb51b ~]$ srvctl config service -d TUL10ATF_SDC
TUL_TUL10ATF_ATG1 PREF: TUL02ATF1 AVAIL: TUL02ATF2
TUL_TUL10ATF_ATG2 PREF: TUL02ATF1 AVAIL: TUL02ATF3
TUL_TUL10ATF_TIBCO PREF: TUL02ATF1 TUL02ATF2 TUL02ATF3 AVAIL:


$srvctl relocate service -d TUL10ATF_SDC -s TUL_TUL10ATF_ATG1 -i TUL02ATF2 -t TUL02ATF1 -f

$srvctl relocate service -d TUL10ATF_SDC -s TUL_TUL10ATF_ATG2 -i TUL02ATF3 -t TUL02ATF1 -f

$srvctl relocate service -d TUL10ATF_SDC -s TUL_TUL10ATF_TIBCO -i TUL02ATF2 -t TUL02ATF1 -f

$ srvctl status service -s TUL_TUL10ATF_ATG1 -d TUL10ATF_SDC
Service TUL_TUL10ATF_ATG1 is running on instance(s) TUL02ATF2

$ srvctl status service -s TUL_TUL10ATF_ATG2 -d TUL10ATF_SDC
Service TUL_TUL10ATF_ATG2 is running on instance(s) TUL02ATF3

$ srvctl status service -s TUL_TUL10ATF_TIBCO -d TUL10ATF_SDC
Service TUL_TUL10ATF_TIBCO is running on instance(s) TUL02ATF2, TUL02ATF3

2 comments:

  1. The examples using srvctl relocate service make the process much clearer than just reading the documentation. I’ve noticed that disconnecting sessions can impact certain workloads, so it’s nice to see that highlighted. Would love to see a follow-up post on scheduling relocations with minimal disruption in a busy database environment.

    ReplyDelete