Skip to main content
Delphix

Selective Data Distribution Best Practices 5.0.x

 

Scenario: SDD Replication Performed Against Empty Set could result in unnecessary disk space usage

Description

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.

Work-Around

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

Fix

Resolved in Virtualization Engine 5.1.x and beyond

Scenario: Deleted Data Replicated After Datafile is Dropped

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.

Work-Around

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 filesystem 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.

Fix

Resolved in Virtualization Engine 5.1.x and beyond