Another Reason to Avoid Anti-Virus on SQL Server

Roughly a year ago, I posted (a rather lengthy) overview of the rationale and reasoning behind my preference to avoid putting anti-virus on SQL Server (or any other production server) whenever possible. In that post, I also listed some ways to help make anti-virus and SQL Server play a bit more 'nicely together' when anti-virus has to be installed on SQL Server due to regulatory compliance or corporate policy.

Part of the guidance I provided in that regard was to try and, effectively, keep anti-virus as far as possible away from SQL Server—to mitigate the potential side effects it can have if it's allowed to 'interfere' with SQL Server's operations, access to files, logs, memory, and the likes.

Anti-Virus Vendors Like to Deploy .dlls into SQL Server

Unfortunately, it also turns out that if you are forced to install anti-virus on SQL Server, many 'bigger' anti-virus vendors out there either offer 'options' that let them 'monitor' SQL Server—or just plain FORCE their binaries right into SQL Server if they detect that it's running on the box.

As you might guess, the outcome of having these .dlls loaded into SQL Server can be disastrous in many cases—with symptoms such as the following being related or described:

Granted, anti-virus, is NOT the only thing that can cause some of the symptoms listed above—but the preponderance of .dlls that Microsoft has identified as part of a Knowledge Base (KB) article dedicated to describing a common source of 'ugly' performance issues within SQL Server end up being related to anti-virus. As such, if you're forced to run anti-virus on any of your SQL Servers, you might want to pre-emptively check for any of the .dlls listed in Microsoft KB 2033238.