DB Sanity Report Modules
The overall summary informs you about the total number of defects and the number of checks with a certain verdict. A 'faulty' check is one which ended in a processing error, which should not happen. This is typical for checks under development which are still buggy. Another possible cause are application redeployments in which table are missing or were removed. You should address faulty checks first, using the 'Sub Modules' report to locate and correct them in order to get a realistic overview about you database health. When all faulty checks are addressed, it is time to go through the violations (marked in red):
The Digest Module creates a minimalistic overview of all checks, enabling the user to find out and navigate to problematic checks at a glance: The icon color indicates the check verdict, positioning the mouse over an icon displays the check name like a tool tip and clicking the icon sends you to the check result (in case of problems) or the check definition.
Defects per Check
The 'Defects per Check' module lists all checks which have reported rule violations, ordered by the number of defects:
One defect normally corresponds to one defective data set. In other words, if a check reports 2349 defects, it generally means that 2349 database rows in the related table violate the rule verified by the check. Processing and fixing the found issues through this module's list from top to bottom gives you the quickest way to reduce the total number of defects.
A 50%-bar indicates, how many violated rules need to be addressed before half of the defects are resolved. Always be aware that '50% of the defects' is very different from '50% of total work time': If you measure the time needed to resolve 50% of the issues, it is likely that the time for resolving 50% of the remaining issues is similar. And 50% of the defects which remain after that period will take the same amount of time and so on...
Defects per Type
You can - and should - apply a defectType to each check. With the 'Defects per Type' report, DB Sanity sums up all defects by their type:
You are free to define defect types as they seem appropriate to you. The main purpose of this report module is to give you a quick indication of the total effort involved in resolving the issues found. Certain defect types can be resolved safely and quickly with a script (trimming strings for example), others may need investigation and feedback from domain experts. So choose and assign your defect types wisely.
Defects per Table
The 'Defects per Table' report module sums up the number of reported defects of each table:
This gives you a quick indication of which application domains are the messiest. In the example, all defects were found in the same table, so the report contains only one entry. You might encounter cases in which DB Sanity reports a number of defects for a table than its row count is. This can happen if there are table rows which violate several rules.
You can group your checks into files and sub directories and DB Sanity's 'Sub Module' report refects this structure:
It is good practice to group checks in a way that reflects the application's module structure. This way you get the best impression which application domains are most problematic.
Recommended further reading: So what to check with DB Sanity.