December 8, 2016 at 2:44 pm
After applying SQL Server cumulative updates or even SPs, we have problems motivating our application users to perform a full test and verify their data, and so we are looking for suggestions for methodologies or tools for DBAs to use to verify the integrity of SQL Server databases after applying cumulative updates or Service Packs.
We can test the SQL to validate that SQL is working correctly, but the IT side doesn't really know the applications that well so we feel the users should test their apps. We do verify that the vendor of a given application has tested their application with certain versions of SPs, but not for Cumulative updates. We also wait several weeks to see if any shops have issues with SPs or updates before we even consider applying them. So we are curious if there is a set of tools that is available, other than SQL itself.
December 8, 2016 at 2:58 pm
There aren't good tools here. You can use Xe/trace/distributed reply to gather a workload and replay it, but I'd do that against a test instance before applying patches.
Really you should have a set of tests that run items against the database with known results ot be sure things haven't changed. These could be used as unit/integration/system tests if you write code, or smoke tests against patches from a vendor, but you really need a sets of tests that apply to the things that matter in your environment.
For example, no sense in testing Service Broker if you don't use it. However, if you use CDC, then you should have some ways of testing that this is still working after any patch.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply