On a smaller scale, our masking jobs were running better after upgrading to 4.9. However, masking on large tables is very slow. Every time we 'restarted' a job after cancellation or failure, it has been super slow to start. PFA a screen shot ... the job has been running for over 1 hour 50 minutes and still it has not began to mask any rows. We are using TDM Portal 184.108.40.206 and FastDataMasker-220.127.116.11. Our source and target databases are running on the same Oracle schema.
To give you an idea, it took over 20 hours to mask 111,963,468 rows.
Release : 4.9
Component : CA Test Data Manager
We recommend you upgrade to the latest Portal and FDM patched releases, which at the time this KB was written is FastDataMasker-18.104.22.168 and TDMWeb-22.214.171.124.
After upgrading, you should use block masking to help increase performance on large jobs.
Suppose you have a table with 100,000,000 rows and you want to run masking jobs in parallel to mask all the rows.
When activated through ... LARGETABLESPLITENABLED=Y
... FDM will create 10 threads(default setting) to process all the blocks that were created by dividing the 100 million rows into chunks. Each block of the size LARGETABLESPLITSIZE=5000000 will be processed.
When a thread completes processing a block, it will process the next block from the queue.
This thread pool is configurable by setting the option PARALLEL=n
We have tried to run it so far with the settings with larger batch size 30k, Fetch Size 30K and optimally up to 4.5 million as LargeTableSplitSize. However, even with smaller split size, maximum four threads are possible, as back-end goes out of space for more number of thread.
As a guideline to the kind of space that must be maintained in the back-end in the Default Table Space and Temp Space, work with your DBA to analyze your table space used and multiple it by 2 times the number of threads you plan to to use.