Please start any new threads on our new site at We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 Old Forums
 CLOSED - General SQL Server
 Antivirus Scanning...File Exclusions...Why Do it?

Author  Topic 

Starting Member

23 Posts

Posted - 2006-02-27 : 11:02:02
So, there's no question that we'll be running antivirus scanning on our database servers. This question involves File Exclusions.

Most people have written that you should be excluding your .MDF/.LDF/.NDF files from virus scanning. However, I'm not sure I understand why. The antivirus software won't be able to scan the file until it can gain access to it and if the DB is running the antivirus engine won't be able to get to it...

The only thing I've read is that there can be issues if the antivirus engine starts a scan at startup that happens to begin before the DB server has grabbed control then the DB file and that may cause the DB to fail to start. I personally have never seen that happen, though.

The other files I was surprised no one talks about are the .BAK and .LOG (etc.) files that are written...But again, I don't think the antivirus engine will be able to read it until the DB engine has completed writing the file and at that point why would I care if the antivirus engine scans the file?

I'll be honest, originally I was a hardcore proponent of excluding DB files from being scanned...But, the more I think about it the less concerned I am. We even had a recent incident where we had a DB server in production that had an antivirus engine on it without any exclusions for several weeks and never had a problem and didn't notice any performance benefit when we created the exclusions...

We have both SQL Server and Oracle here and I work on both (though primarily SQL Server)...And, the other DBAs who work primarily on Oracle get crazy when someone brings up the idea of not having the exclusions, though I'm no longer convinced that they are warranted concerns.

Any thoughts? Anyone know of any recent whitepaper "Best Practices" that deal with this issue?



22859 Posts

Posted - 2006-02-27 : 13:23:23
Not sure this is valid, but:

A multi-GB file is going to take a LONG time to virus check. That's lots of CPU and disk I/O that could have been used for the user's benefits ...

... and I can't see that AV software is going to be able to detect a virus in a BAK file - maybe if the database is storing EXE files as data though ...

... but ... if it did and quarantined the file, what then?

I agree that if you are going to exclude MDF/LDF then you probably should exclude BAK too ... but if one did that the virus writers would presumably start hiding their stuff in files looking like SQL Server databases and backups!

Go to Top of Page

Aged Yak Warrior

771 Posts

Posted - 2006-02-27 : 13:38:14
The On-Access scan feature that intercepts writes to disk can cause phantom disk errors in SQL Server. These errors are recorded in SQL Server's errorlog, but have no corresponding System event. Bit of a bugger to troubleshoot.
Go to Top of Page

Master Smack Fu Yak Hacker

3575 Posts

Posted - 2006-02-27 : 13:41:43
why would you want so much extra disk i/o occuring on your db server? Watch perfmon while your antivirus attemtps to scan your datafiles or backups.

read this

Make the exclusions suggested. ALso exclude your backup files.

Go to Top of Page

Starting Member

23 Posts

Posted - 2006-02-27 : 13:43:07
Thanks for the comments Kristen...

mcrowley: Can you elaborate on what files were affected in your environment and what errors you saw?
Go to Top of Page

Master Smack Fu Yak Hacker

4110 Posts

Posted - 2006-02-27 : 20:22:45
never excluded and never had a problem so far, even with very large databases and OLTP

not sure why... hmm....

keeping it simple...
Go to Top of Page

Starting Member

23 Posts

Posted - 2006-02-27 : 20:47:02

Thanks for the input...Honestly I'm not surprised at this point...I also think the AV engine's have probably improved drastically and probably aren't causing the issues that they once were...Especially now with the more powerful processors.
Go to Top of Page

- Advertisement -