From the main window Settings -> Database -> Execution tab you can set the default method that DataVeil shall use to generate and write masked values.
This represents the maximum number of long-running threads that shall be running concurrently.
This applies particularly to masked value generation threads (each mask uses a dedicated thread) and the number of threads used to write masked values to tables.
Occasionally this thread count may be exceeded for very brief periods by short-running threads.
If you find that your environment is facing resource pressures then reducing this value shall reduce resource contention.
If you have adequate resources then increasing this value may reduce the overall execution
time of your masking project because more tasks shall be run concurrently.
Masked Value Generation
This represents the maximum number of masked values that are generated and written to mapping tables in a single SQL query.
Higher values increase throughput and reduce overall execution time but may also increase undo log space held for the duration of the query.
The default value is 800,000. Although this number may seem high it does not cause problems in most modern environments.
Using NEW, DataVeil shall create a copy of the original table except that it shall replace the sensitive columns with columns containing masked values.
DataVeil shall then create all the constraints, indexes and triggers that were found in the original table.
If all of this is successful then the original table is dropped and the copy shall be renamed to the name of the original table.
* Please ensure that you have sufficient table space to accommodate duplicate tables of all those tables being written using the NEW table IO method.
* For Oracle, writing to tables using this method is much faster than UPDATE and it significantly reduces writes to the redo log.
* For SQL Server, this setting is not available.
* The NEW method can still be slower overall than UPDATE because if the original table contained a great number of indexes and constraints (including 'NOT NULL' constraints) then each of these must be created in the new table, whereas when using UPDATE only those indexes and constraints that involved masked columns must be created in the new table. This can be a significant workload. For example, suppose you have a table with 20 indexes and 50 constraints and you are only masking 1 column that affects 1 index and 1 constraint. If you use NEW table IO then all 20 indexes and 50 constraints shall need to be created that can take a very significant amount of time. If you use UPDATE table IO then only 1 index and 1 constraint shall need to be created.
Using UPDATE, DataVeil shall overwrite only the sensitive columns in the actual original table.
DataVeil only needs to rebuild indexes and constraints that are dependent on the masked columns. All other original indexes and constraints will remain unaffected.
* For Oracle, multiple table update queries are performed in parallel by DataVeil that can result in very fast execution. DataVeil does not perform multiple concurrent updates to SQL Server.
* For Oracle, if DataVeil needs to rebuild an index and the table has statistics locked
then DataVeil shall unlock statistics on the table to allow the index to be rebuilt.
DataVeil shall leave statistics unlocked for tables that had indexes rebuilt. All
other table statistics locks shall remain unchanged.
Setting an Explicit Table IO for an Individual Table
You can override the default table IO method, described above, on a per-table basis.
To do so, select the table node in the Project explorer tree and then open the Masking -> Execution tab for that table.
The default is DEFAULT which means that the table IO method defined for the Database (as described above for Settings -> Database -Execution) shall be used for this table.
To override the table IO for this table simply choose one of the other settings (UPDATE has been selected in the example screen capture above).
Upon Run Completion
Upon a masking run completion, the state of each index, constraint and trigger that DataVeil manipulated during the masking run shall be restored to the same enabled or disabled state that each was in at the start of the masking project execution.
Upon a masking run completion, the state of each index, constraint and trigger that DataVeil manipulated during the masking run shall be set to the enabled state regardless of the state that each item was in at the start of the masking project execution.