Held space overview
Held space is storage retained because a dependent dataset or replication operation still requires the data. It can include data from deleted datasets or snapshots, data from parent datasets that are not present as datasets on the engine, and data retained during replication or failover states.
Held space does not by itself indicate a replication failure. However, it consumes storage capacity. Understanding the dependency helps you determine why the data remains and assess the effects of changing or removing that dependency.
Held space can occur in several situations:
Source-side changes to replicated data
When you replicate a dSource or VDB to another engine, that engine is the replication target. A VDB provisioned on the target from replicated data can depend on snapshots and parent data from the replication source. If a replication update removes data from the target while a VDB still depends on it, the remaining data can become held space. Source-side changes that can lead to this include:
Snapshot deleted or expired
A snapshot can be deleted manually or removed by a Retention policy. When a replication update removes that snapshot from the target, its data can remain held if a target VDB provisioned from the snapshot still depends on it. The parent dSource or VDB does not have to be deleted.
A Replica Retention policy can retain snapshots on the target after they are deleted on the source. Source-side snapshot deletion therefore does not always remove the target snapshot in the next replication update. For policy behavior and exceptions, see Replica Retention policy.
Parent dataset deleted
If you delete a replicated dSource or VDB on the source, a later replication update removes it from the target. Data from that parent can remain held when a VDB on the target still depends on it.
Object removed from a replication profile
Removing an object from a replication profile does not remove it from the target immediately. The removal takes effect when the next replication job completes. If a VDB on the target still depends on data from the removed object, that data can remain on the target as held space.
This held space can result from the target-side removal whether or not you later add the object back to the profile. If you add it back, the entire object is replicated again. The new copy cannot be stitched or merged with data retained from the previous copy, and re-adding the object does not release that held data. For details, see Removing objects from a replication profile.
The following diagram illustrates the case where the parent dSource itself is deleted.
For guidance on viewing held space and identifying its dependencies, see Inspect held space.
Selective Data Distribution
During Selective Data Distribution, a Masked VDB is replicated to a Replication Target. As part of Selective Data Distribution, any blocks modified by the masking process are only sent in their new state. Data sent to the Replication Target is accounted for in two ways:
-
Updated blocks that were modified by the masking process are assigned directly to the Masked VDB.
-
Blocks that were not modified by masking, and are still shared between the Masked VDB and its parent Container, are visible as Held Space. Information about the parent Container is not sent to the Replication Target.
In most cases, where only a small portion of the data in a database is considered sensitive, the Held Space for a Replicated Masked VDB will be the largest of the two values.
Failed or interrupted replication
A failed or interrupted replication job can create held space on the replication source engine. During replication, all data blocks to be replicated are serialized for transfer. Once the transfer is complete, the serialized data is released.
However, if a Replication job fails, the serialized data is retained until the next successful Replication job execution, or the Replication Profile is deleted - whichever happens first.
If dSource and VDB snapshots in the serialized data reach the Retention Policy limit before the Replication job successfully executes, that snapshot data will become held space. This is most likely to happen if either of the following is true:
-
A failed Replication job goes a long time before being successfully re-run.
-
Replication schedules are configured with a period that is longer than one or more Retention Policies.
Chained replication
Chained replication can create held space on the final target after failover. The following example describes the data relationships across three engines, A, B, and C. It uses ordinary replication, not Selective Data Distribution (SDD). SDD replicas cannot be failed over, as described in SDD and failover.
-
Engine A replicates a dSource and its descendants, VDB1 and VDB2, to Engine B. VDB1 is a child of the dSource, and VDB2 is a child of VDB1.
-
VDB3 is provisioned on Engine B from a snapshot of replicated VDB2. VDB2 remains in the received replica namespace, and VDB3 is created in the primary namespace.
-
Engine B replicates VDB3 to Engine C. Replication includes the parent objects and data dependencies needed to represent VDB3. The resulting lineage is dSource, VDB1, VDB2, and VDB3. For details about parent inclusion, see Replication details.
-
The received replica is failed over on Engine C.
After failover, VDB3 and the replicated parent objects (the dSource, VDB1, and VDB2) move into Engine C's live system. Data in the upstream Timeflows that VDB3 depends on remains represented as held space. These Held Space entries represent retained Timeflow data, not parent datasets missing from Engine C. For details about what a Held Space entry represents, see Storage capacity screen.
The intermediate provisioning step on Engine B is required. Engine B cannot directly replicate objects from its received replica namespace to Engine C. For the chain setup before failover, see Geographically distributed development. For failover prerequisites and procedures, see Controlled failovers.
Pending failback
When you perform a test-failover with enableFailback enabled, the replication target saves the state needed to undo the failover. The failed-over objects move from the received replica namespace into the active namespace. You can enable, validate, update, and delete these objects while deciding whether to fail back or commit the failover.
Any objects associated with the failed-over namespace that are deleted during this period, whether manually or by policy, remain held on the target until you fail back or commit the failover.
After validating the failed-over objects, you can commit the failover if you want to keep using them on the target. Committing makes the failover permanent and removes the option to undo it through failback. Failback instead returns the objects to a read-only replica namespace. It does not reinstate replicated snapshots deleted during a test-failover or while failover remains uncommitted. If you still need those snapshots and they still exist on the source, send a new replication update after failback as described in Failback.
Inspect held space
First identify which engine reports the held space. Failed or interrupted replication can create held space on the replication source. Source-side changes to replicated data (including deleted snapshots or parent datasets and objects removed from replication profiles), Selective Data Distribution, chained replication, and pending failback can create held space on the replication target.
On engines with access to the Continuous Data management UI, open the Storage Capacity screen and click the Held space tab. Click the lock icon for an entry to open the why-locked dialog and inspect its dependencies. For UI availability, navigation, and dependency details, see Storage capacity screen.
Before changing retention policies or deleting dependencies, confirm which datasets, snapshots, and recovery options you need to preserve. Removing a dependency can affect data that is still in use. For deletion behavior and precautions, see Delete objects to increase capacity.
Held data is still in use by a dependency or replication operation. It is different from data blocks that the engine has already freed but the underlying storage array has not yet reclaimed. For that distinction, see TRIM and UNMAP support for storage devices.