SQLServer Guidelines for optimal setup

SP3DServices Division Sunit Joshi

Updated: 01/20/2011

These are some general guidelines to follow when setting up your SQL Server databases. Make sure to install Service Pack 2 or 3 of SQLServer before making any changes. Also have the DBA/SysAdmin take a look at MS Guidelines & SQLServer best practices for estimating/planning SQLServer requirements Optimization Tips Figure out IO requirements: Do note that the process of selecting RAID levels and calculating the required number of disks is significantly different in a SAN configuration compared to traditional storage. Configuring and monitoring virtualized SAN storage is a specialist skill and normally it is recommended to use the SAN vendor (HP/EMX/Hitachi/etc.) to set it up as suited for SQLServer. Using SQLIO/SQLIOSIM and calculating the number of disks required: Use SQLIO to stress test database with your initial size. An often used average is 125 IOPS (I/O per sec) per disk for random I/O, and can be used to calculate the required disk numbers. You can also use MS SQLIO & SQLIOSIM tools to detect these values. A commonly used formula is: No of Disks Reqd = (Reads/sec + (Write/sec * RAID adjuster)) / Disk IOPS So if you have a RAID 10 to support 1200 reads and 400 writes /sec, the no of disks would be: No of Disks Reqd = (1200 + (400 * 2)) / 125 = 16 DISKS Note for RAID 10, two physical writes are required for each logical write hence the adjustment to writes per sec. Check if partitions are track-aligned using DISKPART tool: This simple fix in some cases, can give you 30-40% performance boost. Refer to this MS support article for details. This has to be done when you build the server. Do note that starting with Windows Server 2008; all partitions are track-aligned by default.

A common offset used for SQL Server partitions is 64K, or 128 sectors. Using DiskPart, you achieve this by using the Create Partition command with an align=64 option. Windows Server 2008 (and Vista) automatically use a 1024K offset, a value chosen to work with almost all storage systems. If unaligned partitions are used by these operating systemsfor example, after an upgrade from Windows Server 2003then the partition overhead remains until the partition is rebuilt. As with the RAID stripe size, check the offset value with the storage vendor, and verify any changes from their recommended value with an appropriate performance test. Check Allocation Unit Size: SQL Server allocates space within a database using extents, which are collections of eight 8K pages, making a total extent size of 64K. So for a disk for use by SQL Server, it is recommended to format the partition using the Windows Disk Management tool with 64K allocation unit size.

Using appropriate RAID level: Your doc mentions RAID 5, for SQLServer files. The main advantage of RAID 5 is higher disk utilization than RAID 1, and therefore a lower overall cost. However, there are downsides each write to a RAID 5 array, involves multiple disks operations and therefore write performance is much lower than other RAID solutions. Such overheads make RAID 5 unsuitable for OLTP SQLServer

implementations like SP3D. Exceptions include installations with predominantly only read-only profiles or those with disk capacity or budgetary constraints that can handle the write overhead. As such RAID 10 is recommended for SQLServer implementations as it combines the best features of RAID 1 and 0 without any downsides of RAID 5. Heres a good comparison between various RAID levels.

Check SAN Configuration: This section addresses some of the common issues that DBAs face in SAN-based environments, including LUN configuration and performance tuning. Two commonly tuned SAN settings are the storage cache and the HBA queue depth setting. Make sure that the SAN vendor/admin has configured this correctly for an OLTP database system; i.e. optimized for writes rather than reads. Additional information can be found at SQLCrunch How many individual physical disks are included in the SQL Server LUNs? Remember the principle of striping across many physical disks, if a LUN consists of a small number of physical disks, then performance may be less than ideal. What other servers are sharing the physical disks in the LUNs, and what is their I/O pro-file? If many servers LUNs share the same physical disks, performance may be reduced. This is particularly important for transaction log LUNs. Transaction log I/O is sequential in nature, and dedicated physical disks mean the disk heads are able to stay in position, with writes proceeding in a sequential manner. This is obviously not possible if the transaction log LUNs are created on disks containing other LUNs. For SQL Server applications with high transaction log rates, this can have a large impact on transaction response time, leading to decreased performance and throughput. What are the RAID levels of the LUNs? RAID 5 is often chosen as the default RAID level. RAID 10 is recommended for SQLServer.

Use Gigabit Switches: Most servers these days come configure with a gigabit card. The speed of the network card is only as good as the switch port it is connected to. So if are connected to a 100Mbps switch port with a gigabit network card, you are using

1/10 throughput. So make sure to use Gigabit switches particularly at the server level between the database and application servers. Set a reasonable size for your database mdf & ldf files: With SQL server 2005 a database is created by default with a data file of 1 MB and a log file of 1 MB. Both files are set to grow by 10 percent increment until no more space is available on the drive. These defaults are not adequate for monitoring or for a production system. When the data or log file are growing the process may consume a very large amount of server resources slowing down the interactive users. The following tab proposes some reasonable orders of magnitudes for medium pilots. Note that these are recommendations not the size that you should use. If your projects scope is not this big, you may reduce the sizes shown here. The important thing to note is the ratios of the Initial Size and Growth Increments. File Initial Size Growth increment Drive

OS files Model log Catalog log Catalog Schema log Site log Site Schema log Reports log Reports Schema log Model data Catalog data Catalog Schema data Report data Temp DB data Temp DB log

40 GB 1 GB 500 MB Default 50 MB Default Default Default 10 GB 1 GB Default Default 1 GB MB 250 MB

None 500 MB 100 MB Default 10 MB Default Default Default 1 GB 500 MB Default Default 500 MB 100 MB

C: Raid 1 E: Raid 10 E: Raid 10 E: Raid 10 E: Raid 10 E: Raid 10 E: Raid 10 E: Raid 10 F: Raid 10 F: Raid 10 F: Raid 10 F: Raid 10 G: Raid 10 G: Raid 10

AutoGrowth (1MB) is the defaults and should not be set in production env.

Dont place the data file (.mdf) and the log file (.ldf) on the same Physical Drive:

Because logging is more write-intensive, it's important that the disks containing SQL Server log files have sufficient disk I/O performance. So do separate the data and log files into their own RAID arrays.

Dont set the Auto Shrink feature: This degrades performance since the SQLServer has to run this every 30mins or so and causes unnecessary overhead. Also make sure that AutoClose is set to False as otherwise the SQL Cache is flushed and leads to performance degradation.

Set a reasonable size for tempdb and Add additional data files: The size of tempdb can affect query performance. If the size is not adequate then the tempdb autogrows to whatever size it needs as the application runs. Since the default size of tempdb is 8MB, and it shrinks to this size when you restart the server, the growth process can slow and degrade the performance of queries that use tempdb. You may set it to a size of 1000MB for data and 500MB for log file to start with and monitor the size as you go. Also add additional data file equivalent to the no of CPUs the server has. So if you have 4xCPU machine, add 3 more datafiles.

Set up index-defragmentation for Model & Catalog databases (Only on non-GWC databases): Since SP3D is a data-intensive application, the SQLServer database indexes tend to get fragmented over a period of time. As such it is recommended to setup an sql server job which run a defragmentation of the indexes on SP3D model and catalog databases at least once a week during off hrs. One can use an SQL Server management plan or SP3DTools to monitor and scheduled this.

Index defragmentation using SP3DTools

Monitor performance & blocking on periodic basis This should be done periodically to get an idea of the system performance and bottlenecks that may occur over time. Typically issues would be disk-subsystem getting overloaded, server being used by other applications, etc. Use the attached Counters.txt for list of performance counters to monitor.

Counters.txt

File Placements: Location of Operating System Files: Install the operating system on drive C: of the server and configure it as RAID 1 mirrored drive for both fault tolerance and best overall performance. DO NOT locate the operating system files on the same array as SQL Server data files. Location of SQL Server executables:

The location of the SQL Server executables (binaries), like the location of the operating system files, is not critical, as long as they are not located on the same array as the SQL Server data files. Normally place SQL Server executables on drive C: which is generally configured as a RAID 1 mirrored drive. Location of Swap File: Assuming that your SQL Server is a dedicated SQL Server, and that SQL Server memory usage has been set to dynamic (the default), the swap file won't see a lot of activity. This is because SQL Server doesn't normally use it a lot. Because of this, it is not critical that the swap file be located in any particular location, except you don't want to locate it on the same array as SQL Server data files. These can be placed also on the same array as the OS files. Location of SP3D Databases (.mdf): For best performance, user database files (MDBs) should be located on their own array (RAID 10), separate from all other data files, including log files. If you have multiple large databases on the same SQL Server, consider locating each separate database file(s) on its own array for less I/O contention. Each RAID array (10) should have as many physical disks in the array as the controller will support. This allows reads and writes to be performed simultaneously on each physical drive in the array, significantly boosting disk I/O. Location of SP3D Log Files (.ldf): Locate all log files on an array (RAID 1 or RAID 10) other than the array used for database files. This assumes that there is only a single log file on the RAID 1 array. If there is only a single log file on the RAID 1 array, the file can be written to sequentially, speeding up log writes. If there are multiple log files (from multiple databases) sharing the same RAID 1 array, put each database log on its own separate RAID 1 array. One more option is to put the log on a RAID 10 array, which offers the best features of RAID 1 and RAID 5. While this is expensive, it will provide optimum performance. While sequential write performance won't be as good as if each log file had its own array, it is still much better than trying to contend for disk I/O with data files. Put the transaction log on a RAID 1 device at least, even if you can't afford RAID for any other parts of your database. No of Disk Controllers on the Server: A single disk controller, whether is it is SCSI or fiber, has a maximum limit on its throughput. This is a good scenario: One controller is for non-hard disk devices (CDROM. Tapes, etc.), one controller is used for a RAID 1 local hard disk, and a third (and sometimes more) is used for arrays that hold SQL Server database files and logs. Be sure you don't attach more drives to a controller than it can handle. While it may work, performance will suffer. Is Write Back Cache in Disk Controller On or Off? Disk cache in your disk controller offers two ways to speed access. One is for reads and the other for writes. Of these, the most important use is for

reads, as this is where most disk I/O time is spent in most SQL Server databases. A write back cache, on the other hand, is used to speed up writes, which usually occur less often, relatively speaking. Unfortunately, SQL Server, in most cases, assumes that write back cache is not on, and because of this, write back caching should be turned off on most controllers even though you might suffer a very small write performance hit by doing so. Setting Instant file Initialization The first one is Windows Instant File Initialization, which allows SQL Server 2005 to skip the step of "zeroing out" the space used by a database file at the operating system level. Having this turned on makes a big difference in the time it takes to restore a database, create a new database file or database, or expand the size of an existing database file. This only works on Windows Server 2003 and Windows XP. In order to turn this on, you have to give the "Perform volume maintenance tasks" right to the SQL Server Service Account on the server where SQL Server is running. One tool you can use to do this is the Group Policy snapin. Just type GPEDIT.MSC at the Run prompt, and then navigate to Windows Settings, Security Settings, Local Policies, User Rights Assignment, and then add your SQL Server Service account to the "Perform volume maintenance tasks" policy. After you do this, you will need to bounce the server where SQL Server is running in order for the change to take effect. Setting Lock Pages in Memory The second one is the "Lock pages in memory" policy located in the same area in GPEDIT.MSC. You should also add the SQL Server Service account to this policy in order to prevent the operating system from being able to page SQL Server buffer data out of memory when it wants to, rather than letting SQL Server control it. This also requires a restart of the server to take effect.