1. Can you? Yes. Should you? Probably not. sp_updatestats is extremely undisciplined in which statistics it updates. Remember, when stats get updated, not only are you adding the load to the system for the statistics update process, but, after that process completes, any plans in cache that reference those stats is going to be recompiled the next time it gets referenced. That's going to add quite a bit of locking and resource contention, especially around your CPU.
2. Gianluca has already made a number of great suggestions and I strongly support you following those. I'd add the idea of targeting statistics updates where needed using UPDATE STATISTICS
, not the generic approach of sp_updatestats. You might also want to test whether or not setting your automatic update of statistics to async
is helpful. That one is not a sure thing. It helps in some cases, it doesn't in others.
Now, should you run the individual UPDATE STATS commands during high load on the system? Maybe. There's no hard and fast answer there. Experimentation and testing will be the key. I've done it to great success in some situations. It really depends on if the cost incurred from a targeted statistics update offsets the cost of bad execution plans causing poor performance. In many cases, it can, but not all.
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore RooseveltThe Scary DBA
Author of: SQL Server 2017 Query Performance Tuning, 5th Edition
and SQL Server Execution Plans, 3rd Edition
Product Evangelist for Red Gate Software