ptg 2284 . set working set size (remains listed but has no effect) . Open Objects (remains listed but has no effect) From a historical perspective, one of the all-time favorite options in SQL Server 7.0 was max async IO. The reason that option became obsolete is that it is completely automated with SQL Server 2000, SQL Server 2005, and SQL Server 2008. Previously, max async IO was used to specify the number of simultaneous disk I/O requests that SQL Server 7.0 (and earlier versions) could submit to the Windows OS during a checkpoint operation. It invari- ably helped overall throughput on systems that used RAID devices that had extensive disk cache mechanisms. SQL Server 2008 adjusts these options automatically. Configuration Options and Performance The following sections explain essential information about many of the most significant SQL Server configuration options and their impact on SQL Server performance. Some of the options don’t have performance implications and therefore may not be addressed in much detail—or at all. As part of each option’s explanation, an indication of whether the option is advanced or basic is given, along with the option’s default value and whether the option is self-configuring. Recommended values are usually indicated for the different types of generalized application processing that the SQL Server is used for (that is, OLTP, OLAP, data warehouse, and mixed). For some configuration options, there may not be recommended values, but perhaps there may be notes that further explain how they can be used. Remember that there are 70 configuration options; this chapter focuses on the essential ones in alphabetical order (how they are listed in SQL Server). access check cache bucket count Type: Advanced Option Default Value: 0 When any database object is accessed by SQL Server, the access check is cached in an internal structure named access check result cache. The access check cache bucket count option controls the number of entries and number of hash buckets used for access check result cache . Possible performance gains can be made by changing these options (in rare circum- stances). In general, you should leave this one alone. The following is an example of this option: exec sp_configure ‘access check cache bucket count’, 0 go RECONFIGURE Go CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options ptg 2285 Configuration Options and Performance 55 access check cache quota Type: Advanced Option Default Value: 0 In conjunction with access check cache bucket count option, when SQL server accesses any database object, the access check is cached in an internal structure named access check result cache . The access check cache bucket count option, along with the access check cache quota option, controls the number of entries and number of hash buckets used for access check result cache. Possible performance gains can be made by changing these options (in rare circum- stances). But, in general, you should leave this one alone also. The following is an example of this option: exec sp_configure ‘access check cache quota’, 0 go RECONFIGURE Go ad hoc distributed queries Type: Advanced Option Default Value: 0 SQL Server does not allow ad hoc distributed queries using OPENROWSET and OPENDATASOURCE against providers other than the SQL Native Client OLE DB provider. When the ad hoc distributed queries option is set to 0, SQL Server allows ad hoc access against other providers. When it is set to 1, SQL Server does not allow any ad hoc access. Ad hoc distributed queries use the OPENROWSET and OPENDATASOURCE functions to connect to remote data sources using OLE DB. OPENROWSET and OPENDATASOURCE should be used only to reference OLE DB data sources that are accessed infrequently. For any data sources that will be accessed more than a few times, you should define a linked server. Enabling the use of ad hoc queries means that any authenticated login to SQL Server can access the provider. SQL Server administrators should enable this feature only for highly trusted providers that are safe to be accessed by any local login. The following is an example of this option: exec sp_configure ‘Ad Hoc Distributed Queries’, 1 go RECONFIGURE Go ptg 2286 affinity I/O mask Type: Advanced option; requires a reboot of SQL Server to take effect Default value: 0 In Windows Servers, multitasking sometimes requires that process threads move among different processors. This type of movement of processing threads can reduce Microsoft SQL Server performance under heavy system loads because each processor cache is repeat- edly reloaded with data. Assigning processors to specific threads can improve performance by eliminating processor reloads; such an association between a thread and a processor is called processor affinity. SQL Server 2008 supports processor affinity by means of two affin- ity mask options: affinity mask (to deal with the processor affinity needs) and affinity I/O mask (to address I/O-related affinity). Affinity support for servers with 33 to 64 proces- sors is available only on 64-bit operating systems. The affinity I/O mask option binds SQL Server disk I/O to a specified subset of CPUs. In high-end SQL Server OLTP environments, this extension can enhance the performance of SQL Server threads issuing I/Os. This enhancement does not support hardware affinity for individual disks or disk controllers. The value for affinity I/O mask specifies which CPUs in a multiprocessor computer are eligible to process SQL Server disk I/O operations. The mask is a bitmap in which the rightmost bit specifies the lowest-order CPU ( 0), the bit to its immediate left specifies the next-lowest-order CPU ( 1), and so on. To configure more than 32 processors, you set both affinity I/O mask and affinity64 I/O mask. When all bits are set to 0 (or affinity I/O mask is not specified), SQL Server disk I/O is scheduled to any of the CPUs eligible to process SQL Server threads. The values for affinity I/O mask are as follows: . A 1-byte affinity I/O mask value covers up to 8 CPUs in a multiprocessor computer. . A 2-byte affinity I/O mask value covers up to 16 CPUs in a multiprocessor computer. . A 3-byte affinity I/O mask value covers up to 24 CPUs in a multiprocessor computer. . A 4-byte affinity I/O mask value covers up to 32 CPUs in a multiprocessor computer. To cover more than 32 CPUs, you configure a 4-byte affinity I/O mask value for the first 32 CPUs and up to a value-byte affinity64 I/O mask value for the remaining CPUs. A 1 bit in the affinity I/O pattern specifies that the corresponding CPU is eligible to perform SQL Server disk I/O operations; a 0 bit specifies that no SQL Server disk I/O opera- tions should be scheduled for the corresponding CPU. An example of the bitmask values for the first seven processors of an eight-processor system follows (with decimal values shown in parentheses): CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options ptg 2287 Bitmask Processors Used 00000001 (1) 0 00000011 (3) 0, 1 00000111 (7) 0, 1, 2 00001111 (15) 0, 1, 2, 3 00011111 (31) 0, 1, 2, 3, 4 00111111 (63) 0, 1, 2, 3, 4, 5 01111111 (127) 0, 1, 2, 3, 4, 5, 6 Configuration Options and Performance 55 Because setting the SQL Server affinity I/O mask option is a specialized operation, it should be used only when necessary. When specifying the affinity I/O mask option, you must use it with the affinity mask configuration option. You should not enable the same CPU in both the affinity I/O mask switch and the affinity mask option. The bits corresponding to each CPU should be in one of the following three states: . 0 in both the affinity I/O mask option and the affinity mask option . 1 in the affinity I/O mask option and 0 in the affinity mask option . 0 in the affinity I/O mask option and 1 in the affinity mask option In SQL Server 2008, reconfiguring the affinity I/O mask option requires a restart of the SQL Server instance. The following is an example of this option: exec sp_configure ‘affinity I/O mask’, 1 go RECONFIGURE Go Affinity64 I/O mask is available only in the 64-bit version of SQL Server. affinity mask Type: Advanced option Default value: 0 When a server is experiencing a heavy load because other applications are running on the same server, it might be desirable to bind thread affinity to a processor. affinity mask is a bitmapped field that provides SQL Server threads an affinity to proces- sors. This is typically used in conjunction with the affinity I/O mask option just described. Starting from the least-significant digit, each bit that is set to 1 represents the processor on which SQL Server will spawn its threads. Processors are numbered from 0 to 7. An example of the bitmask values for the first seven processors of an eight-processor system follows (with decimal values shown in parentheses): ptg 2288 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options Bitmask Processors Used 00000001 (1) 0 00000011 (3) 0, 1 00000111 (7) 0, 1, 2 00001111 (15) 0, 1, 2, 3 00011111 (31) 0, 1, 2, 3, 4 00111111 (63) 0, 1, 2, 3, 4, 5 01111111 (127) 0, 1, 2, 3, 4, 5, 6 You usually leave the eighth processor alone because many system processes—such as domain controllers—default to that processor. For example, if you want to create the affinity for one SQL Server instance’s threads to use four processors of an eight-processor system, you would set this bitmask to be 15 (00001111). As a result, SQL Server would spawn its threads only on those processors, thus reducing overall reloading of the processor cache. This can be especially evident during heavy system loads. The following is an example of this option: exec sp_configure ‘affinity mask’, 15 go RECONFIGURE Go In general, the default affinity value is able to provide ample load balancing across proces- sors. You should allocate CPUs based on your particular processing load and application types. affinity64 mask is available only on the 64-bit version of SQL Server. Following is a general recommendation of what to specify based on the different applica- tion types you are running: . OLTP—Use the default value, 0. . Data warehouse—Potentially use 75% of available processors to maximize the huge data loads, large reporting, and number of users. . OLAP—Use the default value, 0. . Mixed—Use the default value, 0. From SSMS, you select SQL Server Properties, open the Processor tab, and select the targeted processors in the Enable Processors section, as shown in Figure 55.3. ptg 2289 Configuration Options and Performance 55 FIGURE 55.3 SQL Server 2008 processors’ configurations from SSMS. Agent XP Type: Advanced Default value: 0 The Agent XP option enables SQL Server 2008 Agent extended stored procedures for this server. If enabled, the SQL Server Agent is available in SSMS. If not enabled, the SQL Server Agent is not available in SSMS and cannot be used to start or stop the service. This option also supports direct execution of CLR assemblies. It is not optimized to do so; it just supports this. A 0 value indicates that SQL Server Agent extended stored procedures are not available (the default). A value of 1 indicates that the SQL Server Agent extended stored procedures are available. awe enabled Type: Advanced; requires a reboot of SQL Server to take effect Default value: 0 SQL Server can use the Advanced Windowing Extensions (AWE) API to support large amounts of physical memory. In fact, the specific amount of memory you can use ptg 2290 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options depends on your hardware configuration and operating system support. The amount of physical memory supported has increased with the introduction of Microsoft Windows Server operating systems: . Windows Server Standard Edition supports physical memory up to 4GB. . Windows Server Enterprise Edition supports physical memory up to 32GB. . Windows Server Datacenter Edition supports physical memory up to 64GB. The default of 0 for the awe enabled option tells SQL Server to use dynamic memory in standard 32-bit virtual address spaces. When you enable AWE, the SQL Server instance does not dynamically manage the size of the address space. The instance holds all memory acquired at startup until it is shut down, and memory pages come from the Windows nonpageable pool. This means that none of the memory of the instance can be swapped out. You end up with a great deal of activity occurring in memory only. This is potentially a fast Database Engine. NOTE Releases of SQL Server before SQL Server 2005 supported dynamic memory, which allowed SQL Server to automatically adjust memory usage when there was spare memory on the system. However, SQL Server was limited by the amount of memory available at startup. Starting with SQL Server 2005, this limit on startup memory availability is removed. SQL Server 2005 and 2008 support Hot Add Memory in Microsoft Windows Servers, which allows users to add physical memory without restarting the server. Hot Add Memory requires SQL Server 2008 Enterprise Edition and is available only for 64-bit SQL Server and for 32-bit SQL Server when AWE is enabled. Hot Add Memory is not available for 32-bit SQL Server when AWE is not enabled. Hot Add Memory is avail- able only for Windows Servers Enterprise and Datacenter Editions. It also requires spe- cial hardware supported by the hardware vendor. awe enabled is usually used in conjunction with the max server memory option to control how much memory each SQL Server instance uses. The following is an example of this option: sp_configure ‘awe enabled’, 1 go RECONFIGURE Go Following is a general recommendation of what to specify based on the different applica- tion types you are running: . OLTP—If memory is available, set it to 1. . Data warehouse—Not appropriate for this type. ptg 2291 Configuration Options and Performance 55 . OLAP—If memory is available and you are not using OLAP file options, set it to 1. . Mixed—If memory is available, set it to 1. backup compression default Type: Basic Default value: 0 Starting with SQL Server 2008 Enterprise, you can use the BACKUP Transact-SQL statement to select the backup compression setting to use WITH COMPRESSION or WITH NO_COMPRES- SION . However, when you install SQL Server 2008, the backup compression default is set to 0, which makes backup compression off by default. To change the default to COMPRESSION, you set the backup compression default to 1. To revert the default to NO_COMPRESSION, set the backup compression default back to 0. From a performance point of view, compression can significantly increase CPU usage, and the additional CPU consumed by the compression process might impact concurrent oper- ations. Therefore, you might want to create low-priority compressed backups in a session whose CPU usage is limited by the Resource Governor. blocked process threshold Type: Advanced Default value: 0 The blocked process threshold option allows you to specify the threshold, in seconds, at which blocked process reports are generated. By default, no blocked process reports are produced. blocked process threshold uses the deadlock monitor background thread to walk through the list of tasks waiting for a time greater than or multiples of the config- ured threshold. This option is useful when debugging systems with many deadlock situa- tions. However, there is a cost of overhead involved, so it should be used for only short periods of time. c2 audit mode Type: Advanced; requires a reboot of SQL Server to take effect Default value: 0 C2 audit mode can be configured through SSMS or with the c2 audit mode option in sp_configure. This feature is still available. Selecting this option configures the server to record both failed and successful attempts to access statements and objects. This informa- tion can help you profile system activity and track possible security policy violations. The C2 security standard has been superseded by common criteria compliance features. Much of the detail-level auditing is now done with SQL Auditing (covered in the SQL Server Security chapters) and is far more robust than this feature. C2 audit mode data is saved in a file in the default data directory of the instance. If the audit log file reaches its size limit of 200MB, SQL Server creates a new file, closes the old file, and writes all new audit ptg 2292 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options records to the new file. This process continues until the audit data directory fills up or auditing is turned off. To determine the status of a C2 trace, you query the sys.traces catalog view. Be aware that C2 audit mode saves a large amount of event information to the log file, which can grow quickly. If the data directory in which logs are being saved runs out of space, SQL Server shuts itself down! If auditing is set to start automatically, you must either restart the instance with the -f flag (which bypasses auditing) or free up additional disk space for the audit log. clr enabled Type: Basic Default value: 0 SQL Server 2008 supports direct execution of CLR assemblies. It is not optimized to do so; it just supports this capability. A 0 value for clr enabled indicates that these CLR assemblies are not allowed to run on this SQL Server instance. A value of 1 allows this type of execution. The setting takes effect immediately after sp_configure is run, with no restart of the SQL Server instance required. When RECONFIGURE is run and the run value of the clr enabled option is changed from 1 to 0, all application domains containing user CLR assemblies are immedi- ately unloaded. CLR assembly execution is not supported under lightweight pooling, so you must disable one of two options: clr enabled or lightweight pooling. common criteria compliance enabled Type: Advanced; requires a reboot of SQL Server to take effect Default value: 0 The common criteria compliance enabled option enables three areas (or elements) of what is termed common criteria. The first is Residual Information Protection (RIP), which overwrites memory with a known pattern of bits before memory is reallocated to a new resource. This meets the RIP standard and contributes to improved security. The downside of this improvement is a slowing in performance. The second enables login auditing to occur. Each time a user successfully logs in to SQL Server, information about the last successful login time, the last unsuccessful login time, and the number of attempts between the last successful and current login times is made available. These login statistics can be viewed by querying the sys.dm_exec_sessions dynamic management view. And lastly, this option enables the behavior that a column-level GRANT should not override a table-level DENY. In other words, when enabled, a table-level DENY takes precedence over a column-level GRANT. ptg 2293 Configuration Options and Performance 55 cost threshold for parallelism Type: Advanced Default value: 5 SQL Server 2008 supports parallel query execution. Before a query is executed, SQL Server’s cost-based optimizer estimates the cost of execution for a serial plan (that is, a plan that uses a single thread). The option to set the cost threshold for parallelism allows you to specify a threshold in seconds; if the cost of the serial execution plan (in seconds) is greater than the value specified by this parameter, SQL Server considers a parallel query execution plan. A query does not become a candidate for parallel query execution simply based on this fact. Because parallel query execution is supported only on multiprocessor servers, the cost threshold for parallelism value is ignored for single-processor hard- ware. For an application that uses many complex queries, you should set this value to a lower number so that you can take advantage of the parallel query execution capabilities of SQL Server. The following is an example of this option: exec sp_configure ‘cost threshold for parallelism’, 2 go RECONFIGURE Go The following is a general recommendation of what to specify based on the different application types you are running: . OLTP—Use the default value, 5. . Data warehouse—Many complex queries are candidates for parallelism. Set to a low value, such as 2 (seconds). . OLAP—Use the default value, 5. . Mixed—Use the default value, 5. cross db ownership chaining Type: basic Default value: 0 You use the cross db ownership chaining option to configure cross-database ownership chaining for an instance of Microsoft SQL Server. This server option allows you to control cross-database ownership chaining at the database level or to allow cross-database owner- ship chaining for all databases. In other words, when this option is off for the instance, it is disabled for all databases. This server-wide option can be more selectively set at the indi- vidual database level. Our recommendation is to turn it off at the server instance level and . favorite options in SQL Server 7.0 was max async IO. The reason that option became obsolete is that it is completely automated with SQL Server 2000, SQL Server 2005, and SQL Server 2008. Previously,. Engine. NOTE Releases of SQL Server before SQL Server 2005 supported dynamic memory, which allowed SQL Server to automatically adjust memory usage when there was spare memory on the system. However, SQL Server. memory without restarting the server. Hot Add Memory requires SQL Server 2008 Enterprise Edition and is available only for 64-bit SQL Server and for 32-bit SQL Server when AWE is enabled. Hot