Oracle 19c RAC Automatic Failback Service

We know that in the ORACLE RAC environment, when a database instance fails, the service running on this instance can failover to another available instance. When the instance is restored, the failover service will not be returned to the original instance. The administrator had to relocate the service. This situation has changed in Oracle Database 19c. When adding a service (srvctl add service), it is achieved through the parameter failback.

In Previous versions Oracle, When a service moves to an available instance, Oracle Database does not automatically move the service back to the preferred instance when the preferred instance restarts because:​

• The service is running on the desired number of instances.​
• Maintaining the service on the current instance provides a higher level of service availability.​
• Not moving the service back to the initial preferred instance prevents a second outage.​

Starting with Oracle Database release 19.3, if you specify yes for the -failback attribute of a service, then, after failing over to an available instance when the last preferred instance went down, the service transfers back to a preferred instance when one becomes available. For earlier releases, you can automate fail back to the preferred instance by using FAN callouts. ​

​srvctl add service –s test –d test –a instance1 –r instance2 --fallback

Let us look at this change in the 19c:-

$] srvctl add service -db pgold -service srvohsdba -preferred pgold1 -available pgold2 -failback yes

$] srvctl start service -db pgold -service srvohsdba

$] srvctl status service -db pgold -service srvohsdba

$] srvctl config service -db pgold -service srvohsdba

Note: When creating a service, if failback is not used, the word Failback: false will not be displayed when viewing srvctl config service.

Restart the first node . Then check on the second node to see the changes in the service srvohsdba

We see that the service automatically returns to the first node.

Benefits of Failback parameters:-

Assuming that the Oracle cluster has 4 nodes and 4 pdbs are running, then we can fix the service to the corresponding node, which ensures high availability on the one hand, and reduces the competition of cache fusion on the other hand. If there is no failback parameter, it will be difficult for us to control the service to run in a fixed instance every time we restart or the instance fails, and we must manually intervene. This is great for DBA. This long-awaited feature was finally realized in 19c.

Reference

https://docs.oracle.com/en/database/oracle/oracle-database/19/racad/server-control-utility-reference.html#GUID-EC1BA6D7-D538-4E11-9B31-C59389FDF93B

=================================================

19c RAC : Dynamic Cluster Services

Posted on August 2, 2019

High-availability of database services has been a feature of Oracle Real Application Servers since many versions. Basically, when a database instance fails, a service which has got this instance as a preferred instance, fails over to another available instance.
Unfortunately, the service did not fail back to the original instance as soon as the instance is up again.

The administrator had to relocate the service

OR Needs to configure the fan callout script

You can refer my old blog post – fan-callouts-for-rac

This has changed with Oracle Database 19c.

Starting with Oracle Database release 19.3, if you specify yes for the -failback attribute of a service,
then, after failing over to an available instance when the last preferred instance went down, the service
transfers back to a preferred instance when one becomes available. For earlier releases, you can automate
fail back to the preferred instance by using FAN callouts.

Dynamic Services Fallback Option
For a dynamic database service that is placed using “preferred” and “available” settings,
you can now specify that this service should fall back to a “preferred” instance when it becomes
available if the service failed over to an available instance.

The Dynamic Services Fallback Option allows for more control in placing dynamic database services
and ensures that a given service is available on a preferred instance as long as possible.

#Create serv19c Service inside the acs pluggable database.

srvctl add service -db cdb -pdb acs -service serv19c -preferred cdb1 -available cdb2 -failback YES

#Review the configuration of pdb

-bash-4.2$ srvctl config service -db cdb -service serv19c
Service name: serv19c
Server pool:
Cardinality: 1
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Global: false
Commit Outcome: false
Failover type:
Failover method:
Failover retries:
Failover delay:
Failover restore: NONE
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Pluggable database name: acs
Hub service:
Maximum lag time: ANY
SQL Translation Profile:
Retention: 86400 seconds
Failback : true
Replay Initiation Time: 300 seconds
Drain timeout:
Stop option:
Session State Consistency: DYNAMIC
GSM Flags: 0
Service is enabled
Preferred instances: cdb1
Available instances: cdb2
CSS critical: no

#Review the status of service

-bash-4.2$ srvctl status service -db cdb -service serv19c
Service serv19c is not running.

#Starting the service
-bash-4.2$ srvctl start service -db cdb -service serv19c

#Review the status of service

-bash-4.2$ srvctl status service -db cdb -service serv19c
Service serv19c is running on instance(s) cdb1

#From Node1 we will reboot the machine1

#reboot

#From Node2 review the status of service

-bash-4.2$ srvctl status service -db cdb -service serv19c
Service serv19c is running on instance(s) cdb2

#Once Node1 is comes back in Cluster Service are automatically failback. 

-bash-4.2$ srvctl status service -db cdb -service serv19c
Service serv19c is running on instance(s) cdb1