SQL Server Best Practices: Check and Install the "Best" Drivers

Between the hardware in your system and the interaction with the operating system are a set of software programs and code called "drivers". These bits of information have the most impact on how well a particular hardware device works with your system. In fact, drivers are one of the leading causes of a "Blue Screen" error in the Windows operating system.

For your SQL Server systems, every driver from the I/O subsystem to the network card can impact functionality or even performance. I've even had a video driver - that's a right - a video driver make an impact on the system, although that was admittedly an edge case. The point is that you should use the "best" driver for a particular device.

Wait a minute - what do I mean by "best"? Isn't the latest driver, written by the vendor, the "best" driver? Well, not always. I had a network card driver that had a "teaming" feature, which tied two of the built-in network cards together to theoretically give very high performance. I say "theoretically" because it ended up being less than 56K! Turns out that the network driver, along with the Windows networking stack, at a certain service pack level caused the issue. We backed out the driver to the older one and all was well.

That doesn't mean that all vendors have bad driver software - far from it. For the most part, I install the vendor's latest driver that is certified with the operating system and service pack level I'm at. I test that configuration before I put it into production, and if I see anything I don't understand, I consult the documentation, the forums, and then the vendor to ask more questions. It may turn out that for my configuration there's a better driver.

Comments (1)

  1. Amen. I’ve also seen a nasty network teaming driver that is single-threaded, and on heavy network IO takes one core straight to 100% CPU.  Removed teaming, and presto, more network throughput and less CPU use.  Sketchy.

Skip to main content