There was a conversation on Twitter recently (with the #sqlhelp hashtag) about whether it was completely safe to run the popular CPU-Z utility on a Production database server. The questioner was concerned about possible instability or even a Blue Screen of Death (BSOD) that might occur if you ran CPU-Z on a server.  I can completely understand this concern, but in this case, I think it is overstated. Database Professionals are typically more risk averse and more careful than many other I.T. Professionals, which is an admirable thing. It is very easy for a DBA to cause a lot of havoc with one quick mistake. It is good to be a detail-oriented, careful DBA.

On the other hand, life is full of risks. Everyone has to carefully consider the risks and rewards of any course of action before they decide whether to do something or not. Everyone has a different level of risk tolerance, and you have to find the right balance between being overly cautious and being overly aggressive. I have seen far too many DBAs who are almost afraid to do anything to a system. Afraid to make a configuration change to a SQL Server instance, afraid to drop an index, afraid to use data compression, etc..

One path to becoming a “wise” DBA is combining technical knowledge with good judgment and hard-won experience gained by making decisions and actually doing things as part of your day to day work. Hopefully, most of your decisions are good ones, and most things you try are beneficial, but nobody will have a 100% success ratio. Sometimes, you will fail, or just make a bad decision, but I bet you will learn from your mistake! 

You should also remember that good, experienced DBAs are very hard to find, and thus are quite valuable. Unless you have a habit of making bad mistakes and bad decisions, I would say that your reputation and job are safer than you think. In most cases, your employer needs you more than you need them. Think about that! As Franklin Delano Roosevelt said in 1933, “The only thing we have to fear is fear itself”. Well, it is time to climb down from the soapbox…

Getting back to CPU-Z, all the anecdotal evidence I have is good. I have been using it regularly for many years, running it on many hundreds of servers, never having any problems. Many other well-known SQL Server MVPs piped up with similar results in the Twitter thread. Of course, this is not definitive proof that CPU-Z will never cause a problem for anyone. If you are convinced that CPU-Z might be risky, then no amount of anecdotal evidence is likely to convince you otherwise.

If you have any sort of HA solution in place (such as fail-over clustering or database mirroring), you can always run CPU-Z on a passive node or on the mirror, to pretty much eliminate any possible risk. You can run it on the other nodes or other side of the mirror during your rolling maintenance activities. If you don’t have any HA solution in place, I would say you have bigger things to worry about than CPU-Z.

I would like to hear people’s opinions and experience with using CPU-Z on their systems, good or bad.