Comments
4 comments
-
Good Morning KVM thank you for your post!
The Index Refresh rule is just to refresh Data Masker's offline understanding of what indexes are available so that it selects the correct one for fetching the internal row IDs for masking.
For this purpose there's _usually_ only 1 Index refresh rule needed, towards the beginning of the masking set or just after, if you've run a number of command rules changing indexes. This is why it is limited in product.
Is there a reason you need more than 1 Index Refresh Rule?
Thank you very much! -
Of the approximately 60 tables that need masking for one database, I have 6 tables without a primary key. My approach was to create a rule block per table. see image. Based on what you said, should my approach be to start with a single command rule and modify all six tables with single refresh in one nested block?
-
Thanks @KVM I couldn't have put it better myself.
It's easier to have them either all in 1 cmd rule and call that your PK adding rule and then refresh, or create a number of nested command rules with 1 index refresh at the end.
(and then maybe add command rules at the end to remove the keys if you don't necessarily want them going back into pre-Prod when the reality is those keys don't exist on Prod!)
On a side note...
I can also see from the screen shot above that you have substitution rules that _could_ run in the same rule block too, so you could nest your index management command and refresh rules in rule block 1 for example and then put some of the sub rules for those tables in the same rule blocks so that you can run them in parallel using Data Maskers multiple workers - just a thought, if you're experiencing long masking times
Let me know if you have any other thoughts or questions! Happy to help!
Kindest, Chris -
Thank you Chris, That is good and helpful insight on using this product. Much appreciated!
Add comment
Please sign in to leave a comment.
Thanks!