Thursday , September 28 2023

Client Connectivity – RAC

Today we will learn how to Automatically Connect Clients to New Primary in Role Changes (Client Connectivity – RAC).

Management of database services in RAC structure is done with SRVCTL utility.

The meanings of some attributes to be used when adding services are as follows.

-d: db_unique_name

-s: service_name

-r: instance_names

-l: db_roles

-e: failover_type {NONE | SESSION | SELECT}

-m: failover_method {NONE | BASIC}

-z: failover_retries

-w: failover_delay

If standby databases are created with Enterprise Manager, they are not automatically registered to Oracle Restart. So we add it manually as follows.

• If the Data Guard Environment is managed by the Broker, then the service is automatically started and the FAN ONS event is broadcast to the applications by the Broker itself, but if the Broker is not used, then this work is done with the help of Triggers.

○ STARTUP TRIGGER starts the service on the new Primary database.

○ The ROLE_CHANGE Trigger tells JDBC Clients to connect to the old Physical Standby instead of connecting to the Original Primary database.

• In the broker, this process is managed completely automatically. The process steps are as follows.

○ When the failover process is completed and the old Physical Standby database becomes Primary, the Broker broadcasts the old Primary as down and the new Primary as a FAN event.

○ In applications using JDBC, OCI or ODP.NET as Oracle Client, clients are automatically connected to the new Primary database with Fast Connection Failover (FCF) configuration.

• Let’s take a closer look at the Client Failover components.

Connect Time Failover: It redirects failed connection requests to secondary listener.

Transparent Application Failover: Allows the re-executing of failing SELECT statements, rollback of DML operations, and re-execution of ALTER SESSION statements by the application.

Fast Application Notification: When the original primary database fails, it sends a notification to the applications.

Let’s Test

1. We add service.

2. The status of the service is questioned.

3. Since the service will be started from the operating system, we define the sh script at a location in the operating system.

4. We create Trigger that will start the service.

5. We check whether the trigger occurs on the Primary and Standby sides.

6. We restart the Primary database to see if the service has started in STARTUP.

7. It is checked whether the service starts automatically or not.

8. It is checked whether the service is running in Physical Standby.

9. We check whether the service starts automatically in Stanby by performing the switchover operation.

10. We check the status of the services on the Primary and Standby side.

Could not understand why the service did not start. Will look again later.




Leave a Reply

Your email address will not be published. Required fields are marked *