There are currently six major versions of SQL Server that I commonly see being used in Production, along with five major versions of Windows Server. Only certain combinations of SQL Server and Windows Server are officially supported by Microsoft, but tracking down this information is a little tedious.

Table 1 shows these possible combinations and whether they are officially supported by Microsoft. One possibly surprising combination is the fact that SQL Server 2012 is not officially supported on Windows Server 2016. Perhaps this is less surprising if you keep in mind that SQL Server 2012 will fall out of mainstream support on July 11, 2017, which is not that far away.

Table 1: OS Support for Recent Versions of SQL Server

The available links that document this are listed below:

Hardware and Software Requirements for Installing SQL Server 2008 R2

Hardware and Software Requirements for Installing SQL Server 2012

Hardware and Software Requirements for Installing SQL Server 2014

Hardware and Software Requirements for Installing SQL Server (for 2016 and later)

If you are getting ready to deploy a new instance of SQL Server 2014 or SQL Server 2016, then you should prefer Windows Server 2016, even though they are also supported on older operating systems. If you are getting ready to deploy a new instance of SQL Server 2008 through SQL Server 2012, then you should prefer Windows Server 2012 R2, even though they are supported on older operating systems.

Finally, if you are getting ready to deploy a new instance of SQL Server 2005, then I feel a little sorry for you! SQL Server 2005 is out of extended support, and it is missing so many useful features that were added in newer versions of SQL Server.

Actually, I recently helped a client deploy some new instances of SQL Server 2005 for some pretty valid business reasons. We ended up deploying to a VM (on new, very fast host hardware) that was running Windows Server 2008 R2, which worked perfectly fine.

The post Operating System Support for SQL Server Versions appeared first on Glenn Berry.

I had several initial ideas about what the problem might be, including:

1. Windows instant file initialization was not enabled
1. This would force Windows to have to “zero-initialize” the database data file after it was created during the restore, which slows down the restore
2. It was already enabled on this instance, so that was not the problem
2. The transaction log files were particularly large for these user databases
1. Windows instant file initialization does not work on log files, only on data files
2. This issue would be present on any database instance, not just one
3. The VLF counts were particularly high in the log files for these databases
1. This causes the recovery portion for a full database restore (or crash recovery) to take much longer
2. None of the VLF counts were above 300, plus this would behave the same on any database instance

After my initial ideas were found to be incorrect, I tried restoring a full backup of one of the user databases to the new database server, making sure to use the Stats = 1 option, so the restore progress statistics would update every 1%. This gives you more immediate and fine-grained feedback about the progress of the restore, which is always a good idea.

While the restore was running, I carefully watched the disk activity in Windows Resource Monitor.  You can sort the columns in Windows Resource Monitor to see the highest Reads and Writes (in bytes/second) while the database restore is running. This will show the reads from the database backup file, then the writes to the database data file(s) and the database log file. It also showed the writes to the filetable files, and then something that I did not expect…

The full database restore went very fast until it got to 92%. Then I saw a huge number of parallel reads by the MsMpEng.exe process (which is the Microsoft Antimalware service), which slowed the restore progress to an absolute crawl, also pegging one of the CPU cores on the instance (so it looks like that service is single-threaded).  This seemed to be a major factor in the slowness of the database restore as MsMpEng.exe process was scanning the 8,684 Filetable documents that were in this particular user database.

The solution to this issue was simply changing the exclusion rules for the Microsoft Antimalware Service to not scan the files in the filetable directories. This one change decreased the database restore time by 56%.

Here is the restore command and the results of the test.

-- Test restore of TestUserDatabase
-- This database uses Filetables
RESTORE DATABASE [TestUserDatabase] 
FROM  DISK = N'T:\BackupRestoreTest\TestUserDatabase_FULL.bak' WITH  FILE = 1,  
MOVE N'TestUserDatabase' TO N'D:\SQLDATA\TestUserDatabase.mdf',  
MOVE N'TestUserDatabase_log' TO N'L:\Logs\TestUserDatabase_log.ldf',  
MOVE N'DOCUMENTS' TO N'D:\SQLDATA\TestUserDatabase_DOCUMENTS',  NOUNLOAD,  STATS = 1;
GO

-- Actual elapsed time 6:21 (Before directory exclusion change)
--Processed 2358856 pages for database 'TestUserDatabase', file 'TestUserDatabase' on file 1.
--Processed 4 pages for database 'TestUserDatabase', file 'TestUserDatabase_log' on file 1.
--Processed 208905 pages for database 'TestUserDatabase', file 'DOCUMENTS' on file 1.
--RESTORE DATABASE successfully processed 2567764 pages in 378.708 seconds (52.971 MB/sec).


-- Actual elapsed time 2:52 (After directory exclusion change)
--Processed 2358856 pages for database 'TestUserDatabase', file 'TestUserDatabase' on file 1.
--Processed 4 pages for database 'TestUserDatabase', file 'TestUserDatabase_log' on file 1.
--Processed 208905 pages for database 'TestUserDatabase', file 'DOCUMENTS' on file 1.
--RESTORE DATABASE successfully processed 2567764 pages in 167.607 seconds (119.688 MB/sec).

Figure 1: T-SQL for Database Restore Test

One thing you might notice is that the filetable directory is on the same LUN as the PRIMARY data file for this database, which is not really the best location. Ideally this directory would be on a separate LUN from any other SQL Server database files, but this may not always be possible due to economic resource constraints.

Here is some more information about filestream performance:

High-performance FILESTREAM tips and tricks

Best Practices on FILESTREAM implementations

The post Using Windows Resource Monitor to Find Unusual Performance Bottlenecks appeared first on Glenn Berry.

The system in question was using about 15.5GB of disk space in that directory. After a bit of research, I discovered the DISM.exe command. When you install Windows Server 2008 R2 SP1, the setup program backs up any files that are replaced by the service pack. You can remove these backup files to save space with the Deployment Image Servicing and Management (DISM) tool. If you do this, you will not be able to uninstall Service Pack 1 any longer, but you will get back a decent amount of disk space (typically, anywhere from around 2 to 7 GB).

You need to open a command prompt with elevated privileges (by right-clicking and selecting “Run as Administrator”). Once you have a command prompt open, simply type this command (shown in Figure 1):

DISM.exe /online /Cleanup-Image /spsuperseded

Microsoft has a Deployment Guide for Windows Server 2008 R2 with SP1 and Windows 7 with SP1, where you can get more background on this.

Depending on the speed of your disk subsystem and the components you have installed, it may take around five to ten minutes for the command to complete. Once it is done, you should have some more free space available on your system drive. After running this command (which you can only do once), I would also manually defragment the system drive.

This command will only work if you have Windows Server 2008 R2 Service Pack 1 (or Windows 7 Service Pack 1) installed. If you are running Windows Server 2008 R2 or Windows 7, you really should have Service Pack 1 installed by now. Microsoft has actually started pushing Service Pack 1 down to Windows 7 systems as an Important Update, using Windows Update on March 19, 2013.

Figure 1: Command Prompt Window with DISM.EXE Command Switches

Figure 2: Command Prompt Window After Running DISM.EXE

The post How to Reclaim Disk Space in your Windows\winsxs directory on Windows Server 2008 R2 SP1 appeared first on Glenn Berry.