DB2 Probe: SQL1776N Error on HADR Standby Nodes with ROS Disabled

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

In a DB2 High Availability Disaster Recovery (HADR) environment where Read on Standby (ROS) is disabled, the db2 probe generates recurring SQL1776N errors and alerts indicating the database is down on the standby node.

Environment

• Product: DX Unified Infrastructure Management (DX UIM 23.4.*)
• Probe: db2 v4.31 or earlier
• Database: IBM DB2 HADR with ROS disabled

Cause

The probe attempts to establish a standard database connection to verify health. In HADR configurations with ROS disabled, the standby node does not permit connections, resulting in the SQL1776N error. Prior versions relied on a state file (hadr_role.state) that could become out of sync or fail to initialize correctly during the first failover.

Resolution

Install db2 probe v4.32 T1 or later (db2-4.32-T1-20260617.181406-3.zip attached to this case).This version includes a fix for DE675127, which changes the probe logic to:

1. Directly evaluate the HADR status before attempting a connection.
2. Identify if the node is a standby with ROS disabled.
3. Suppress the "Database Down" alarm if the node is in a valid standby state.

Note: This fix eliminates the dependency on the hadr_role.state file for initial role determination, ensuring accurate monitoring from the first poll after deployment.

Additional Information

NOTE: Later fixes and GA versions of the probe will have this fix and change. 

---

New Alarm Logic Clarification: 

We have improved the probe by removing its dependency on the old state file.

Instead, the probe now reads the DB2 HADR status directly. Because of this, the alerting logic is now based on state transitions.

Here is exactly how the new behavior works:

1. Alerting on State Changes
When a failover occurs, the probe detects the role change and immediately generates an alarm. You will get an alarm for the very first failover, the second, the third, and so on.

2. Preventing Alarm Spam ("First Occurrence" Logic)
When we mentioned the alarm triggers on the "first occurrence," we mean the first occurrence of the status change. Once a server switches to Standby and sends you that failover alarm, it will not continue to send you identical, redundant "I am Standby" alarms every polling cycle.

Example Scenario

To illustrate:

Failover 1: Server 1 (Primary) fails over. Server 1 becomes Standby, and Server 2 becomes Primary.
Result: You get an alarm from Server 1 ("I am Standby") and an alarm from Server 2 ("I am Primary").
Steady State: While the servers remain in these roles, no redundant alarms are sent.

Failback / Failover 2: Server 1 becomes Primary again, and Server 2 becomes Standby.
Result: You get a new set of alarms reflecting this exact change.

Summary: You are no longer missing the very first failover alarm (as happened before the fix), and you will still be alerted every single time a failover occurs.

The new logic simply ensures your inbox isn't flooded with duplicate alerts when the database roles haven't actually changed.