Table of Contents

Search

  1. Preface
  2. Introduction to Test Data Management
  3. Test Data Manager
  4. Projects
  5. Policies
  6. Data Discovery
  7. Data Subset
  8. Data Masking
  9. Data Masking Techniques and Parameters
  10. Data Generation
  11. Data Generation Techniques and Parameters
  12. Data Sets
  13. Plans and Workflows
  14. Monitor
  15. Reports
  16. ilmcmd
  17. tdwcmd
  18. tdwquery
  19. Data Type Reference
  20. Data Type Reference for Test Data Warehouse
  21. Data Type Reference for Hadoop
  22. Glossary

Reset With and Without Downtime

Reset With and Without Downtime

You can choose to disable constraints and indexes when you perform a reset operation.
Disabling constraints during the reset might increase the performance of the reset operation because the constraints do not exist. TDM performs delete and load in multiple tables in parallel and the reset operation might take less time to complete.
When you do not disable constraints between tables during a reset operation, TDM must check the order in which deletes and inserts happen. TDM cannot perform load and delete for multiple tables in parallel. TDM must consider constraints before deleting records. The reset operation might take longer to complete than when you disable constraints and indexes.
You apply constraints between tables. When you disable constraints, you disable constraints for the entire table. During the time the constraints are disabled, tests that you run using the tables might fail as the constraints do not exist. Consider a case where multiple testers use the test data. You create a data set version that contains the first 100 records of the Customer table. After running a few tests, you want to reset the test data with the data set version. If you disable constraints for the table during the reset operation, tests run by other testers that include the Customer table might fail. The reset operation causes a downtime for running tests that use the target connection.
While disabling constraints can increase performance, there might be a tradeoff with a downtime in testing if the target tables are shared among testers.
If multiple testers use the tables, a slower reset operation might be better than a downtime in testing for multiple testers. If the target tables are not used by other testers, and you are sure that no tests that include the tables are run during the reset, you can increase the performance of the reset by disabling constraints.
Analyze the requirement and consider this tradeoff when you configure a reset operation.
Consider a case where multiple testers use the test data. You create a data set version that contains the first 100 records of the Customer table. After running a few tests, you want to replace the test data with the data set version.