Skip to main content
Delphix

Best Practice: Selective Data Distribution (KBA1196)

 

 

SDD Replication Performed Against Empty Set

Description 

Selective Data Distribution (SDD) Replication performed against empty set can result in unnecessary disk space usage.

If SDD-based replication is performed at the same time as a refresh/remask operation, the data replicated will be performed against an empty set and the entire contents of the dSource will be transferred as part of the replication.

Workaround 

Delphix highly recommends you upgrade to version 5.1.x or later. If you cannot upgrade, you can use the work-around described below.

Verify that refresh policies only trigger far enough after a replication policy triggers to ensure that the replication will be complete

Resolution 

Resolved in Virtualization Engine 5.1.x and beyond

Deleted Data Replicated After Datafile is Dropped Issue 

Description

Storage space can be higher than expected or needed due to the file system’s handling of deleted files. Here we explain what happens and how to prevent it.

As part of the masking/preparation process of the Oracle masked VDB, configure clone hooks drop one or more tablespaces and the related data file(s).  When SDD replicates the VDB, the data associated with the deleted files is also transferred.  This is somewhat like the NFS “silly rename” situation, although there are no files on the VDB’s filesystem that explain why this may be occurring.  Once again, when a VDB is provisioned from the masked, replicated object there is no evidence of the unmasked data, but the source size reflects the space occupied by the previously-deleted files on the source.

The ZFS delete queue is not part of the redaction process for the VDB, and is therefore included in the SDD send.

Workaround 

Delphix highly recommends you upgrade to version 5.1.x or later. If you cannot upgrade, you can use the work-around described below.

The deletion of indirect blocks by ZFS takes some time, and therefore the filesystem related to the location where the files were deleted (normally datafile) should be monitored in a loop until the size of the filesystem “normalizes”, and this check should be completed prior to the masked VDB’s snapshot.  The activity seen will normally be the following:

  1. A minute or two of no changes

  2. Several minutes of the space used by the filesystem reducing (blocks are being deleted)

  3. Filesystem sizes are stable

After the file system sizes are unchanged for 5-10 checks 1 minute apart, it should be safe to proceed with a snapshot.  Results will vary depending on the environment and amount of data being changed, and the scripts should be adjusted accordingly.

Resolution 

Resolved in Virtualization Engine 5.1.x and beyond