Disaster Recovery Standby Nodes: IBM DB2 Warm vs. Cold Standby Rules

High availability (HA) and disaster recovery (DR) clustering are essential for database durability. But in the IBM ecosystem, the way you configure your standby database server determines whether it is free, flat-rated, or fully licensable.

IBM DB2 classifies standby servers into three categories: Cold, Warm, and Hot.

If you configure your standby cluster incorrectly, you could be exposed to unexpected licensing deficits during audits.

---

The Three Standby Tiers

IBM defines standby servers based on how quickly they can take over from the primary node and what state the database engine is in:

#### 1. Cold Standby (Usually Unlicensed)

* The Rule: The DB2 software is installed on the backup server, but the database engine is completely shut down.

* The Benefit: A cold standby node does not require any DB2 licenses.

* The Restriction: To qualify, the server must only be booted for maintenance or patch testing. The database must not be started until a disaster occurs and the primary node is offline.

#### 2. Warm Standby (Flat-Rated at 100 PVUs)

* The Rule: The database engine is running on the standby server, and it is actively receiving data logs from the primary node (e.g., using HADR or log shipping) to keep the databases in sync. However, the database is in "standby mode" and cannot accept user connections or run queries.

* The Benefit: A warm standby server is licensed at a flat rate of 100 PVUs per server, regardless of how many cores or processors are installed on that server.

* The Savings: For a 32-core Intel host (normally requiring 2,240 PVUs), you only pay for 100 PVUs if configured as a warm standby.

#### 3. Hot Standby (Fully Licensed)

* The Rule: The database engine is running, and the database is open for read-only queries, reporting, or active user connections (similar to a read-only secondary replica).

* The Requirement: A hot standby must be fully licensed for all cores (based on standard PVU or core metrics) just like the primary node.

---

The 100-PVU Warm Standby Trap

The flat-rated 100-PVU Warm Standby is a massive cost benefit, but it is a common compliance trap during IBM audits due to configuration and access errors:

* The Read-Only Violation: If your database administrator configures HADR (High Availability Disaster Recovery) and enables the parameter DB2_HADR_ROS (Read on Standby) to offload reporting queries:

* The standby becomes Hot.

* The 100-PVU flat-rate is void.

* The standby must be licensed for its full core capacity.

* Missing ILMT Exclusions: ILMT scans software installations, but it cannot automatically detect if a DB2 instance is in warm standby mode. If you do not manually configure a "Warm Standby" exclusion or bundling rule in the ILMT console, ILMT will report the server at full PVU capacity. During an audit, you must present your HADR logs to prove the standby was passive and justify the 100-PVU mapping.

---

Best Practices for DB2 Standby Compliance

1. Isolate Reporting from HADR Standbys: If your organization requires read-only reporting databases, deploy a separate, fully-licensed DB2 instance for reporting rather than enabling "Read on Standby" on your HADR disaster recovery node.

2. Audit db2set Parameters: Run the command db2set on all your standby servers. Check if DB2_HADR_ROS is set to ON. If it is, ensure the server is fully licensed.

3. Document Standby Roles in ILMT: Work with your software asset management (SAM) team to ensure that any server acting as a warm standby is manually classified as such in your ILMT and licensing records.