Skip to main content

Best Practice: Selective Data Distribution (KBA1306)



This document describes best practices for implementing Selective Data Distribution (SDD) and is not meant to be an all-inclusive troubleshooting document.

Snapshot Policy Enabled for a Masked VDB 


This scenario is a condition resulting from the timing of operations that could result in the potential transfer of unmasked data. We recommend configuring the software avoid this condition. Details follow:

By default, a provisioned virtual database (VDB) is set to the “Default Snapshot” policy, which performs a snapshot on a regular cadence of the given VDB. If the masking process for the VDB has issues it should stop the refresh/provisioning operation and leave the VDB in a state where the database is up and running. It may have a mix of masked and unmasked data but has no VDB snapshot. If an SDD replication process occurs in this state, the unmasked data in the running database should not be transferred. However, if a snapshot policy is defined and takes a snapshot of the VDB in this state, unmasked data would potentially be transferred by the SDD replication if done after the automated snapshot.


Masked VDBs must have their snapshot policy set to None during the provisioning process, or must have their policy changed to "None” if already provisioned. It should be verified that no previous snapshots generated automatically may have had unmasked data present before the VDB is replicated using SDD.

If it is unknown whether certain snapshots may have unmasked data present, the VDB should be destroyed and re-provisioned, as well as the remote data destroyed and re-seeded from a known-good source masked VDB that does not have automated snapshots enabled.

Preventing Replication of NFS Data Files Deleted During Masked Provisioning 


As part of the masking/preparation process of a masked VDB on any database accessed over NFS, configure clone hooks drop one or more tablespaces and the related data file(s).

As part of the deletion process, the NFS file renames the datafile to .nfsxxxxxxxxx, waits until the NFS client has no further locks on the file, then the client deletes the file. The client hasn’t deleted this “silly rename” file, and it is recognized as being part of the file system to be replicated. The SDD replication pushes over both the wanted data as well as data equal to the size of the file(s) deleted. This data cannot be realized when a VDB on the remote end is provisioned (things appear completely normal for the VDB), but the size of the source data is much larger than expected.


As part of the configure clone hook, make sure the VDB is shut down and started up after the deletion of data files. This releases the NFS lock and allows the .nfsxxxxxx file to be removed.

In addition, a check script should be run which verifies that no .nfsxxxxx files are present on the VDBs file systems prior to the snapshot of the masked VDB after the data is refreshed/remasked.




Customers using version 5.0.x, please refer to the document for that release.

Sensitive Data Removal 

Delphix Masking replaces sensitive data with masked data at the SQL level. After masking is complete, an application accesses masked data and therefore sensitive data is secured from application and database users.

When masking in-place, sensitive data may still be present in various areas outside the application’s view. This data can potentially be accessed by file system and database administrators. The specific areas that might contain sensitive data depend on the internal workings of each data platform. In general, sensitive data may be found in areas such as log files, data files, other application files, file system blocks, and/or bits on physical storage (even if the data is deleted from the application). As a result, when SDD moves masked data sources to a non-production environment sensitive data may be sent to and be present in these non-application accessible areas on the non-production environment. Therefore, SDD does not remove the need for normal processes and procedures to protect access to data (administrative users who have access might be able to see sensitive information).


Sensitive data at rest is a concern. Users of masked data (through SQL) should be prevented from accessing the following areas (these lists may not be exhaustive depending on the application design, database configuration, etc.). Customers are recommended to contact Delphix Professional Services for customer specific procedures to mitigate this issue.

The following lists best practices, although these steps do not entirely remove the issue. These instructions apply to the combination of Delphix Virtualization and Delphix Masking. If a third-party masking tool is used, these issues may or may not apply (and there might be other issues).

  • Oracle

    • SYSDBA access

    • Access to the database files, including

      • Online Log Files

      • Archived Log Files

      • Undo Datafiles

      • User Datafiles

      • Temp Datafile

    • Audit trail

    • Automatic Workload Repository (AWR)

    • Active Session History (ASH)

    • Freed file system blocks

  • Microsoft SQL Server

    • Database administrator access

    • Datafiles

    • Transaction Logs

    • FILESTREAM Files

    • Temp tables

    • Underlying NTFS volume

  • SAP ASE (Sybase)

    • Database administrator access

    • Datafiles

    • Transaction Logs

    • Temp tables