Scenario Description

The existence of a Held Space is not indicative of an issue but rather a representation of an underlying storage dependency.

There are two scenarios which can create Held Space.  

Scenario 1:

The first scenario can occur when you replicate a dSource to a second engine, which we'll call a Replication Target. 

If you then provision a VDB from the Replication Target, and the dSource is subsequently deleted from the Replication Source, you will create a Held Space when that delete replicates to the Replication Target engine.

When this happens, the deleted dSource is removed from the target, but its storage remains held because it is needed by the replica provisioned VDB. 

Scenario 2:

The second scenario can occur in the context of a snapshot which is in use by a Jet Stream branch or bookmark.  

The snapshot may be removed via policy, but until the branches and/or bookmarks which leverage that snapshot are removed, its space will be held.

Held Space can be viewed in the capacity management screen after the namespace it is in is failed over. While before failover we cannot see the storage for individual objects in a namespace, after failover each piece of held space belonging to a deleted dSource/snapshot/etc. will have an entry in the capacity management table named Held Space (was Unknown Storage object xxx), as shown below: