Why a SQL Health check can save thousands (and your job)?

Recently, DSP provided a SQL server Health check to a client that was having some timeout issues with their in house SQL Server. A number of storage experts, networking and VMWare consultants had endeavoured to find the cause of the issue but to no avail.

A simple 3 day health check from DSP uncovered a number of issues as well as pinpointing the cause of the client timeouts. This was due to a misconfiguration of the memory for a SQL Server on a 32 bit system. This effectively only allowed the SQL server to use only 4GB of the 32GB installed on the server. As the data sets had grown over time this flooded the memory buffers and caused the time out issues.

So how does a health check from DSP differ from that of a standard one provided by other disciplines within IT such as storage, networking and hypervisors? The answer is pretty straight forward, SQL Server has within it a number of different queues that expand past the OS or Hypervisor. There are over 100 and plenty of places for something to get stuck.

While ensuring OS and hypervisor those environments work optimally, a storage or VMWare engineer is never going to be able to lift the lid off the SQL Server black box and get inside its internals like database experts DSP could.

In the scenario above, the client was recommended a new architecture costing £54,000. Luckily before purchasing they contacted DSP and for the price of a 3 day health check managed to resolve their issues with no further cost. Worryingly, if the environment had been P2V’d to the new environment, the misconfiguration would have still been in the SQL Server Settings, again restricting the memory on the new hardware and throttling this new investment… a painful explanation to the FD to be sure.