Replication: Update monitoring views and table functions for OPTIMIZED_REFRESH in failover groups (Pending)

Attention

This behavior change is in the 2026_05 bundle.

For the current status of the bundle, refer to Bundle history.

When this behavior change bundle is enabled, the public monitoring surfaces for replication and failover groups expose the count of objects that actually changed during a refresh. The following surfaces are affected:

Before the change:

The OBJECT_COUNT JSON value (in the REPLICATION_GROUP_REFRESH_HISTORY family of views and table function) and the details JSON value for the SECONDARY_DOWNLOADING_METADATA phase (in the REPLICATION_GROUP_REFRESH_PROGRESS family of table functions) reported only totalObjects and completedObjects, both at the top level and inside each objectTypes entry. The REPLICATION_GROUP_USAGE_HISTORY table function reported credit and byte usage but did not surface the number of objects that changed during each refresh. There was no way to distinguish how many objects were actually changed by a refresh from how many objects the refresh inspected.

After the change:

OBJECT_COUNT in the REPLICATION_GROUP_REFRESH_HISTORY views and table function

A new changedObjects field is included at the top level of the JSON value and inside each objectTypes entry. The field reports the number of objects that changed during the refresh. The shape of the OBJECT_COUNT value depends on the OPTIMIZED_REFRESH setting of the failover group. (OPTIMIZED_REFRESH applies only to failover groups; refreshes of replication groups behave the same as failover-group refreshes with OPTIMIZED_REFRESH = FALSE.)

  • For refreshes where OPTIMIZED_REFRESH = FALSE (the current default), the OBJECT_COUNT value continues to include totalObjects and completedObjects alongside the new changedObjects field:

    {
      "totalObjects": 150,
      "completedObjects": 150,
      "changedObjects": 42,
      "objectTypes": [
        {
          "objectType": "TABLES",
          "totalObjects": 100,
          "completedObjects": 100,
          "changedObjects": 30
        }
      ]
    }
    
  • For refreshes where OPTIMIZED_REFRESH = TRUE, the OBJECT_COUNT value contains only the changedObjects field. The totalObjects and completedObjects fields are omitted, both at the top level and inside each objectTypes entry, because Optimized Refresh inspects only changed objects:

    {
      "changedObjects": 42,
      "objectTypes": [
        {
          "objectType": "TABLES",
          "changedObjects": 30
        }
      ]
    }
    

details in the REPLICATION_GROUP_REFRESH_PROGRESS family of table functions

In the details JSON for the SECONDARY_DOWNLOADING_METADATA phase reported by the REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB, and REPLICATION_GROUP_REFRESH_PROGRESS_ALL table functions, all three fields (totalObjects, completedObjects, and changedObjects) are always present, regardless of the OPTIMIZED_REFRESH setting:

{
  "totalObjects": 150,
  "completedObjects": 150,
  "changedObjects": 42,
  "objectTypes": [
    {
      "objectType": "TABLES",
      "totalObjects": 100,
      "completedObjects": 100,
      "changedObjects": 30
    }
  ]
}

New CHANGED_OBJECT_COUNT column in the REPLICATION_GROUP_USAGE_HISTORY table function

The REPLICATION_GROUP_USAGE_HISTORY table function (Information Schema) returns a new CHANGED_OBJECT_COUNT column of type NUMBER, which reports the count of objects that changed during each refresh. The column is populated for refreshes of replication groups and for failover-group refreshes where OPTIMIZED_REFRESH = FALSE. As before, the table function does not return rows for failover-group refreshes where OPTIMIZED_REFRESH = TRUE.

Migration note

If you have queries or scripts that parse OBJECT_COUNT and assume that totalObjects or completedObjects are always present, update them to handle the case where these fields are omitted for failover-group refreshes with OPTIMIZED_REFRESH = TRUE.

This change exposes the count of objects that actually changed during a refresh, which helps you size and monitor replication workloads more accurately, especially for failover groups that use Optimized Refresh.

Ref: 2340