Relocating Services in Oracle RAC is mainly used for maintenance purpose.
Maintenance purpose :- When for Patching(OS/Oracle), we wanted to do it in a rolling fashion, one node at a time as we don't have downtime for the application, we have to relocate service temporarily to other nodes of the cluster.
We can also permanently move a service from one node to another node. We will show both the methods in this article
Temporary relocation of a Service in Oracle :-
==>srvctl config service -d AMIT -s app_prod
Service name: app_prod
Service is enabled
Server pool: amit_app_prd
Cardinality: 1
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SESSION
Failover method: BASIC
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Preferred instances: AMIT1
Available instances: AMIT2
==>srvctl status service -d AMIT
Service app_prod is running on instance(s) AMIT1
We can see from above that app_prod service is running on AMIT1 instance , now we wanted to do patching on AMIT1 instance.
We will relocate service temporarily to AMIT2 instance and once our maintenance work is done we will relocate it back.
Relocating a service will not modify the preferred instance and available instance details for a service . This is a temporary job.
We can relocate service temporarily using below methods :-
Using Database instance :-
==>srvctl relocate service -d AMIT -s app_prod -i p1end1 -t p1end2
Using Node details :-
==>srvctl relocate service -d AMIT -s app_prod -c NODE1 -n NODE2
If you want to disconnect all session while relocating the service , we can use -f clause.
Now check the configuration of the service , it's the same :-
==>srvctl config service -d AMIT -s app_prod
Service name: app_prod
.......
TAF policy specification: NONE
Edition:
Preferred instances: AMIT1
Available instances: AMIT2
Once maintenance job is done, relocate it as it was before using same command.
Permanent relocation of a service :-
When we have to permanently relocate a service then we have to modify the config parameters for the service , in this case the preferred instance and available instance details will be changed.
==>srvctl config service -d AMIT -s app_prod
Service name: app_prod
Service is enabled
Server pool: amit_app_prd
Cardinality: 1
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SESSION
Failover method: BASIC
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Preferred instances: AMIT1
Available instances: AMIT2
Now modify the service for preferred instance as AMIT2
=> srvctl modify service -d AMIT -s app_prod -i AMIT2 -a AMIT1
if multiple instances then we can use comma(,)
=> srvctl modify service -d AMIT -s app_prod -i AMIT2,AMIT3 -a AMIT1,AMIT4
we can use -f to disconnect all active session in the relocation process.
Let's see if configuration modified or not :-
==>srvctl config service -d AMIT -s app_prod
Service name: app_prod
..................
Edition:
Preferred instances: AMIT2
Available instances: AMIT1
It's modified permanently
Maintenance purpose :- When for Patching(OS/Oracle), we wanted to do it in a rolling fashion, one node at a time as we don't have downtime for the application, we have to relocate service temporarily to other nodes of the cluster.
We can also permanently move a service from one node to another node. We will show both the methods in this article
Temporary relocation of a Service in Oracle :-
==>srvctl config service -d AMIT -s app_prod
Service name: app_prod
Service is enabled
Server pool: amit_app_prd
Cardinality: 1
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SESSION
Failover method: BASIC
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Preferred instances: AMIT1
Available instances: AMIT2
==>srvctl status service -d AMIT
Service app_prod is running on instance(s) AMIT1
We can see from above that app_prod service is running on AMIT1 instance , now we wanted to do patching on AMIT1 instance.
We will relocate service temporarily to AMIT2 instance and once our maintenance work is done we will relocate it back.
Relocating a service will not modify the preferred instance and available instance details for a service . This is a temporary job.
We can relocate service temporarily using below methods :-
Using Database instance :-
==>srvctl relocate service -d AMIT -s app_prod -i p1end1 -t p1end2
Using Node details :-
==>srvctl relocate service -d AMIT -s app_prod -c NODE1 -n NODE2
If you want to disconnect all session while relocating the service , we can use -f clause.
Now check the configuration of the service , it's the same :-
==>srvctl config service -d AMIT -s app_prod
Service name: app_prod
.......
TAF policy specification: NONE
Edition:
Preferred instances: AMIT1
Available instances: AMIT2
Once maintenance job is done, relocate it as it was before using same command.
Permanent relocation of a service :-
When we have to permanently relocate a service then we have to modify the config parameters for the service , in this case the preferred instance and available instance details will be changed.
==>srvctl config service -d AMIT -s app_prod
Service name: app_prod
Service is enabled
Server pool: amit_app_prd
Cardinality: 1
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SESSION
Failover method: BASIC
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Preferred instances: AMIT1
Available instances: AMIT2
Now modify the service for preferred instance as AMIT2
=> srvctl modify service -d AMIT -s app_prod -i AMIT2 -a AMIT1
if multiple instances then we can use comma(,)
=> srvctl modify service -d AMIT -s app_prod -i AMIT2,AMIT3 -a AMIT1,AMIT4
we can use -f to disconnect all active session in the relocation process.
Let's see if configuration modified or not :-
==>srvctl config service -d AMIT -s app_prod
Service name: app_prod
..................
Edition:
Preferred instances: AMIT2
Available instances: AMIT1
It's modified permanently
I hope this article helped you
Thanks
Amit Rath
Good Article!
ReplyDeleteThank's for sharing such a nice post. I am really glad after reading Your post. Home Office Moving, Relocation Services
ReplyDeleteAmit,
ReplyDeleteThis is very good document.
I have a question while doing a node patch in rolling fashion, what happens to the ACTIVE sessions in the node where we are going to stop the cluster(down the node for patching).
Regards,
Kaushika K
Thanks for the Article, what happens to existing connections. I think existing connections will be terminated and only new connection will be failed over to existing nodes.
ReplyDeleteThank you Amit. It helped..
ReplyDeleteThanks for the blog article.Thanks Again. Keep writing.
ReplyDeleteazure training
java training
salesforce training
hadoop training
mulesoft training