Preparing DB2 database for profiling and masking
Before masking data, the database(s) must be prepared. This page provides configuration resources, information on how memory requirements are determined, table keys, creating roles, and creating user privileges. These are generic guidelines for Db2 LUW, Db2 iSeries, and Db2 z/OS.
Determining the amount of memory the DB2 LUW server needs
The memory requirements for the DB2 Server are documented in the “Memory requirements” section on the DB2 database’s Disk and memory requirements page. Memory requirements are affected by the size and complexity of your database system, the extent of database activity, and the number of clients accessing your system. Visit the page mentioned above for more elaborated details.
In-place masking and table keys
A key is a unique, non-NULL value that identifies a row in the database table. When masking using In-Place, this key looks up the row to update the masked record. For performance, this key needs to be indexed. The best index is a Clustered Index as this is ordered and 100% unique. A Unique index or constraint can also be used. For best performance and hasselfree masking operation consider running a reorganization (reorg) on the table (adding the key column if needed).
Primary Key (PK): If there is a Primary Key, the Continuous Compliance Engine will use this key.
IDENTITY column: If there is no PK, but there is an IDENTITY column on the table, the Continuous Compliance Engine will use this. If this column is not indexed, the Continuous Compliance Engine will add a non-clustered index called
i_MASKING_GENERATED_IDENTITY_TMP_<TABLE_NAME>.Logical Key (LK): You can add a Logical Key to override the key used. The Logical Key can be one or multiple columns. The Logical Key has to always be 100% unique and can’t have NULLs.
No Key: If there is no Key, the Continuous Compliance Engine has an automated feature that will add an IDENTITY column called MASKING_GENERATED_IDENTITY_TMP. This column is removed at the end of the masking job execution. This column will be indexed with a non-clustered index called i_MASKING_GENERATED_IDENTITY_TMP_<TABLE_NAME>.
An alternative would be using On-the-Fly masking.
DB2 Journal
Sizing the Journal
When a table is altered, DB2 will create log entries (needed for Rollback, Auditing, and other DB features so these are unavoidable). For each Update, each record will be logged twice (there will be a BR and UR or similar entry in the Journal). The Journal size required for masking can be estimated using this formula:
In-Place Masking
Masking: Total size of tables * 3 (for BR, UR, and metadata)
If the IDENTITY column is added: the amount needs to be doubled.
On-the-fly Masking
Masking: Total size of tables * 1.5 (for the record + metadata)
If
Truncatis used the amount needs to be doubled.
Journal Management and PII
The Journal will contain unmasked data and needs to be purged after masking. The management of the Journal is a manual DB2 DBA task.
Creating a masking user and privileges
It is highly recommended to create a database user and possibly a role to mask. This user should not be created in production but should be created in non-production. The masking user should have privileges as described in the Database user permissions for executing masking and profiling job document.