Skip to main content

Using the Custom SQL Rule Set Feature (KBA4455)




KBA# 4455

At a Glance   

Description: Used to Filter and Alter (including casting) data before masking using SQL statement.
Location: Custom SQL can be modified from the UI and the API.

UI: [Environment] > Rule Set > [Edit] > Custom SQL

API: tableMetadata
Configuration: The following parameter is used to configure this feature: 
  • Custom SQL: Complete SELECT SQL statement.
  • Only SELECT can be used (as it is used to read the data to be masked).  
UI Code: When used, the following code appears in the Rule Set (UI): 'SQL'.
Oracle:  Masking Oracle databases will need ROWID in the SELECT statement.
More Info: For information about investigating errors and the logs:
More info: 

Applicable Delphix Versions

Click here to view the versions of the Delphix engine to which this article applies
Major Release All Sub Releases




5.0,,,,,,,,, ,,,,,


This feature is used to specifically define the SQL statement used to read the data from the database table. The columns needed in the statement will depend on the job type (IP or OTF).

The 'Custom SQL' can also be used to alter datatypes and values (as in casting). 



In earlier versions, the Custom SQL requires the SQL statement to be defined in one single line.



Below is an example of a Custom SQL for In-Place (IP):

SELECT [id_col], [mask_col1], [mask_col2],... FROM [table] WHERE [predicate];

Warning: UNION, ORDER, and WHERE

A warning when creating the SELECT statement - Some statements can cause deadlocks. Please check execution plans - data should be retrieved in Logical Order (Full Table Scan, Index Scan, ...) as the data is stored on disk.

For example:

  • Union will perform multiple scans on the table which can cause deadlocks. 
  • Order can access blocks/pages in random order and cause deadlocks.
  • Where can also cause deadlocks - especially if columns in the predicate are indexed (same reason as Order).

Custom SQL and IP or OTF Masking 

Masking: In-Place

When using In-Place (IP) the 'Custom SQL' should include: 

  • All masked columns.
  • All required Unique Row Identifiers (URI).
  • Optional: Column detailed to be required for a custom algorithm. 

URI is the Unique Row Identifier, which is required to update the masked row in In-Place masking. This URI is usually a Primary Key or, for Oracle, the ROWID. At times it is required to manually set this URI or to create a key other than the Primary Key.



If additional columns are specified, these are not used. Additional columns may adversely affect performace and consume additional memory.


Masking: On-The-Fly

When using On-The-Fly (OTF), the 'Custom SQL' should include all columns. The best is to only use 'Custom SQL' if a value needs to be CAST. Any column that is not included will be set to NULL. 



For Oracle, ROWID should not be included.


The 'Custom SQL' affects profiling. If all columns need to be profiled, ensure the Custom SQL is erased or contains all columns. 

UI Examples  

In the examples below, the following names have been used: 

  • Rule Set: 'Rule Set Features RS'
  • Original Table Name: 'Main_Table'

Rule Set page  

Please note the 'SQL' indicator when the table has a 'Custom SQL' defined. 

UI RS - SQL.png

Edit Table Settings popup  

This shows an example of a 'Custom SQL'. In this case, it is the engine generated SQL. 

The SQL statement will include all columns in the table (based on the Rule Set). Columns not required need to be deleted. 

UI RS - Popup - Custom SQL .png


No Invalid Input error  

There is no verification if the 'Custom SQL' is valid or not. The product assumes the SQL is valid and that it can be used in the Masking Job. 

Related Articles  

The following articles may provide more information or related information to this article: