Not likely, no. But how much time will it cost you to run that command? I’m the type of person that doesn’t mind doing the extra legwork, just in case something turns up weird.

Thanks for the great questions!

1. I don’t hand a system over for testing until I am done with my work. If it can take too long for your checks, then you should consider using rolling upgrades in order to minimize downtime.

2. Not for SPs or CUs, no, because those are more easily rolled back. My checklist would be simpler and focused on the items that the CU was meant to address.

HTH

1. At what step do you recommend end user testing begin (and, if successful, the system be brought back online)? DBCC checks and statistic updates can run for a long time on larger databases. On the one hand, I don’t want to take 3hrs on post-upgrade tasks, only to find there’s a critical end-user issue that could have been spotted 3hrs sooner had some things been done in parallel. But I also don’t want to be reckless.

2. When applying a cumulative update rather than doing a version upgrade, do you follow the same process outlined here for a full version upgrade? Is there anything you think can be safely skipped, or postponed until after the system is back online, when it comes to cumulative updates? Again, don’t want to be reckless, but also want to minimize downtime, especially since cumulative updates are so frequent.

Thanks!

EXEC sp_MSforeachtable @command1=’UPDATE STATISTICS [?] WITH FULLSCAN’;