During a calm day, it is easy to reduce HADR monitoring to a handful of states. During an incident, the question becomes much sharper: if the primary disappeared now, could the standby take over within the recovery limits that matter to this application?
This article separates HADR pair health from takeover readiness, explains why a composite status must show its underlying inputs, and asks Db2 practitioners which signals and thresholds they trust before a takeover.
Disclosure: I am VP of Operations at Integration Plumbers. We are developing a third-party Db2 LUW plug-in for Oracle Enterprise Manager, now in Open Beta. It is not an IBM product. This article describes the operational question behind one capability and asks for feedback from Db2 practitioners.
During a calm day, it is easy to reduce HADR monitoring to a handful of states. During an incident, the question becomes much sharper: if the primary disappeared now, could the standby take over within the recovery limits that matter to this application?
That question has at least three layers.
First, is the HADR relationship functioning? Role, state, synchronization mode, connection status, and heartbeat timing tell us whether the pair is communicating and behaving roughly as configured.
Second, what is the exposure at this moment? Primary and standby log positions, log gap, and replay lag help translate “connected” into a view of how much work remains and whether the standby is keeping pace.
Third, is the direction improving or deteriorating? A current gap is only a point. A series tells us whether the standby is catching up after a burst, remaining stable, or steadily losing ground.
Why one status is not enough
We are experimenting with a composite takeover-readiness result in our Open Beta. The attraction is obvious: a single status is easier to alert on and easier for a mixed-database operations team to interpret quickly.
The danger is equally obvious: a badge can create false confidence. If the inputs and thresholds are hidden, “ready” becomes an assertion rather than an operational aid.
Our design principle is therefore that the result must show its work. The Db2-native values remain available, the gap and lag can be trended, and an operator should be able to identify the exact input behind a change in readiness. The composite is an invitation to inspect, not permission to skip a runbook.
The threshold problem
There is no honest universal number for acceptable lag. Recovery objectives differ by application, topology, and synchronization mode. Maintenance and known workload events can also change what is normal for a period.
Starter thresholds can still be useful if they are treated as starting points. We currently think defaults should catch unambiguous communication failures, surface the magnitude and trend of the gap, and make it straightforward to substitute application-specific warning and critical limits.
This is where practitioner experience is more useful than another laboratory test. A lab can verify that values collect, history persists, and alerts change state. It cannot reproduce the operating assumptions, unusual topologies, or failure patterns found across real estates.
Questions for Db2 operators
If you manage Db2 LUW HADR, I would value your view on three questions:
1. What are the minimum signals you check before takeover?
2. Are your limits tied explicitly to RPO/RTO, or do you use operational thresholds developed from experience?
3. Which apparently healthy condition has proved misleading in a real incident or exercise?
We are particularly interested in Db2 11.5 and 12.1, multiple-standby configurations, and monitoring from a remote host. You do not need to use Oracle Enterprise Manager to answer; the purpose of the questions is to improve the Db2 readiness model itself.
For transparency, the beta is intended for non-production evaluation. The plug-in collects through Db2's modern monitoring interfaces with a CONNECT and SQLADM monitoring account, and the readiness view is only one part of the current test surface. Technical details and the current limitations are in the Db2 beta documentation: https://docs.integrationplumbers.io/db2/
I will summarize useful patterns from the discussion and, where they change the model, report those changes back to the community.