How Using the Windows 2000 Encrypted File System to Secure SQL Server Databases and Backups Affects SQL Server's Performance

Those running Windows 2000 can take advantage of the EFS (encrypted file system) for encrypting SQL Server database and/or backup files. In some organizations, encrypting data is mandatory, and as you might expect, it can exact a performance penalty. In this article, I will take a brief look at how you set up encryption for SQL Server and Windows 2000, and then run some tests to see how it affects SQL Server's performance.

How to Turn on Encryption for SQL Server Databases and Backups

To turn on the encrypted file system in Windows 2000 for use by SQL Server:

• Shutdown your database instance.
  
  
• Login with the service account the SQL Server instance is using.
  
  
• Select the properties of the folder(s) in which the database files reside using Windows Explorer.
  
  
• Select the advanced option button and follow the prompts to encrypt the files/folders.
  
  
• Re-start the SQL Server service.
  
  
• Verify the successful start-up of the instance and databases affected via the encryption (or create databases after the fact over the encrypted directories).
  
  
• Verify encryption of the database files via cipher.exe.

If you attempt to start the service as any user other than the user that encrypted the database data files, the instance will not start and/or your database will be set to suspect.

Here is an example of SQL Server error log entry showing what happens if you start the service with an account other than the one used to encrypt the files:

udopen: Operating system error 5(error not found) during the creation/opening of physical device E:\cktemp\efs\efs_Data.MDF.

FCB::Open failed: Could not open device E:\cktemp\efs\efs_Data.MDF for virtual device number (VDN) 1.

udopen: Operating system error 5(error not found) during the creation/opening of physical device E:\cktemp\efs\efs_Log.LDF.

FCB::Open failed: Could not open device E:\cktemp\efs\efs_Log.LDF for virtual device number (VDN) 2.

As you might expect, encrypting your SQL Server data negatively affects SQL Server's performance. How much it will affect speed is a tough to measure as there are so many factors to consider. For example:

• Hardware vendor chosen
  
  
• I/O drives and OS version and patch level
  
  
• Disk vendor, speed, cache
  
  
• RAID levels, channels, disk interconnect
  
  
• RAID controller type, cache, vendor
  
  
• Software-based caching models and/or BIOS patches
  
  
• OS configuration parameters, service packs and registry “tweaks”

and perhaps more, can all affect SQL Server's encrypted performance.

Testing How Windows 2000 Encryption Affects SQL Server's Performance

The testing of EFS performance using SQL Server database files was done on the following hardware:

HP NetServer, Dual PIII 850Mhz, 512Mb RAM, SCSI 160 RAID-1 18Gb Disks

The tests were repeated five times, with the average figures shown below. No other user or application was running during the tests. The databases were identical in terms of their size, recovery model, collation and other basic settings.

Before beginning the tests, I tested to be sure that encryption was working. This can be done by typing the following at the command line:

cipher

The results of this command were:

Listing d:\
New files added to this directory will be encrypted.

E EFSTEST_Data.MDF
E EFSTEST_Log.LDF

The results above indicate that encryption is on and that there are two existing files that are encrypted.

Next, from within Query Analyzer, I set I/O time and statistics to on, as follows:

set statistics io on
set statistics time on

And before each test, I ran the following code in order to clear out the memory buffer and to force a checkpoint.

dbcc dropcleanbuffers
checkpoint