You can also create audit tables that are populated with triggers (and that provide much more flexibility than collecting change data). A critical component is capturing datasets that don't try to work row by row. He adds some invoices yes, but if you write triggers correctly, it is not. Be sure to write down who (including which application, if you have several applications that fall into the database) and when are both old and new values. Set up one audit table for each table you want to check (too many locks if you use only one audit table). And while you are setting up your system, write a code to return data from a bad transaction or set of transactions. This makes recovery easier when something goes wrong and you need to come back.We use two tables for each audited table, which contains information about the process that made the changes (application name, date, user, etc.), and the other contains information about what was changed (old and new values, ID affected recording and collision). Our structure allows us to use the same structure for each table being checked and allows us to change tables without changing the audit table and allows us to easily script audit tables for new tables. It is also easy for us to understand which records were changed at the same time or in the same process, or to find out which of the many applications that concern our database are responsible for the bad data, as well as for the fact that we said who in particular was responsible for bad data. This helps us track application errors and find outwhy the data was changed as it was in some cases. It also makes it easier for us to keep track of all the data that was affected by the broken process, and not just the one we knew about.