Before running discovery or masking operations, ensure that the Db2 database is properly configured. Proper database preparation helps improve masking performance and prevents failures during large update operations.
The following recommendations apply to Db2 LUW, Db2 iSeries, and Db2 z/OS environments.
Db2 on z/OS configuration requirements
When preparing a Db2 on z/OS database, certain configuration settings must be enabled to support metadata discovery operations.
DESCSTAT parameter
The DESCSTAT parameter must be set to YES.
If this parameter is set to NO, rule set creation or metadata discovery may fail with errors similar to the following:
com.ibm.db2.jcc.am.SqlException:
[jcc][10150][10300][4.32.28] Invalid parameter: Unknown column name COLUMN_NAME.
ERRORCODE=-4460
To resolve this issue:
-
Bind metadata stored procedures such as
SQLTABLES,SQLSTATISTICS, andSQLCOLUMNSwithDESCSTAT=YES. -
Refresh the Workload Manager (WLM) after completing the rebind operation.
Refer to IBM documentation for additional details about configuring the DESCSTAT parameter.
Memory configuration
Db2 servers require sufficient memory allocation to support database workloads. Masking operations can generate large update transactions and may require additional memory capacity.
Memory requirements depend on factors such as:
-
Database size and complexity
-
Number of active users
-
Volume of database activity
Database administrators should review Db2 memory configuration and allocate sufficient resources for masking workloads.
Refer to the Db2 documentation for guidance on determining appropriate memory requirements.
Table key configuration
Masking operations require a unique key to identify rows when updating records.
For best performance, the key used for masking should be indexed. A clustered index is typically the most efficient option, although a unique index or constraint can also be used.
Continuous Compliance uses the following order when selecting a key:
-
Primary Key (PK) – Used if available.
-
IDENTITY column – Used if no primary key exists.
-
Logical Key (LK) – A user-defined key that overrides other keys. Logical keys must be unique and cannot contain NULL values.
-
Generated identity column – If no suitable key exists, a temporary identity column may be created during masking operations.
Temporary identity columns created during masking are removed after the masking job completes.
For improved performance, it is recommended to run a table reorganization (REORG) when adding or modifying keys.
Journal configuration
Db2 maintains a journal (transaction log) that records database changes. Masking operations can generate large volumes of journal entries because many rows may be updated.
Journal sizing
Masking operations generate journal entries for each database update. Ensure that the journal has sufficient capacity to support the masking workload.
The required journal size depends on the masking method.
In-place masking
For in-place masking operations, the journal size can be estimated as:
Journal size ≈ total size of tables being masked × 3
This accounts for the following entries:
-
Before record (BR)
-
Updated record (UR)
-
Metadata
If a temporary IDENTITY column is added during masking, the journal size requirement may double.
On-the-fly masking
For on-the-fly masking operations, the journal size can be estimated as:
Journal size ≈ total size of tables being masked × 1.5
If truncate operations are used, the required journal size may increase further.
Journal management
The Db2 journal may temporarily contain unmasked data recorded during update operations.
Database administrators should ensure that the journal is properly managed and purged after masking operations complete.
Journal management and cleanup are typically performed as part of standard database administration procedures.
Masking user privileges
It is recommended to create a dedicated database user for masking operations. This user should have the required privileges to read database metadata and update table data.
The masking user should be granted the permissions described in Database user permissions.
Ensure that the credentials configured in the connector correspond to a user with the required privileges.