ptg 2304 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options FIGURE 55.5 The minimum server memory and maximum server memory configuration settings in SSMS. max text repl size Type: Basic Default value: 65536 The max text repl size parameter specifies the maximum size of the text, ntext, varchar(max), nvarchar(max), and image data types for columns participating in replica- tion during single insert, update, writetext, and updatetext statements. You might need to raise this value if the image sizes your application deals with are consistently large and the data is part of a replication configuration. The following is an example of this option: exec sp_configure ‘max text repl size’, 131072 go RECONFIGURE go ptg 2305 Configuration Options and Performance 55 max worker threads Type: Basic Default value: 0 SQL Server uses native operating system threads. The max worker threads parameter spec- ifies the maximum number of threads available for SQL Server processes. One or more threads are used for supporting each network protocol (for example, TCP/IP, named pipes). SQL Server is configured to listen. The checkpoint and lazywriter processes also consume threads. A pool of threads is used to handle user connections. When the number of connections is lower than the max worker threads parameter value, a thread is created for each connection. When more connections are on the server than the value defined by the max worker threads parameter, SQL Server provides thread pooling for efficient resource utilization. The default value of 0 autoconfigures the number of max worker threads to be (256 + ((number of processors – 4) × 8)) for a 32-bit processor and twice that for a 64- bit processor. So, for an 8 processor 32-bit machine, the max worker threads value would be autoconfigured to be (256 + ((8 – 4) × 8)) = 288. More threads can create overhead on the system processors. Therefore, lowering this value might sometimes improve the performance of a system. For a system with a few hundred user connections, a reasonable value for this parameter is 288. You might want to experi- ment with various values to determine the appropriate setting for this parameter. A multi- processor environment can easily handle more threads, and you can increase the number of threads accordingly. The following is an example of this option: exec sp_configure ‘max worker threads’, 288 go RECONFIGURE go The following is a general recommendation of what to specify based on the different application types you are running: . OLTP—For multiprocessor environments, set the value upward because those envi- ronments can handle servicing more threads. This yields performance gains. . Data warehouse—Use the default value, 0. . OLAP—Use the default value, 0. . Mixed—For multiprocessor environments, set the value upward because those envi- ronments can handle servicing more threads. This yields performance gains. ptg 2306 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options min memory per query Type: Advanced Default value: 1024 The min memory per query option specifies the minimum amount of memory that will be allocated for the execution of a query. Normally, the SQL Server query processor attempts to determine the optimal amount of memory for a query. This option allows the sysadmin role to specify this value instead. Increasing this value usually improves queries that handle hash and sort operations on a large volume of data. The following is an example of this option: exec sp_configure ‘min memory per query’, 2048 go RECONFIGURE go Looking back at Figure 55.5 showing the Memory page of the Server Properties dialog, you can see the min query memory per query option set at 1024 (the default). The following is a general recommendation of what to specify based on the different application types you are running: . OLTP—Use the default value, 1024. . Data warehouse—This is a good opportunity to better service numerous canned queries in this environment. Set the value higher than the default. . OLAP—Use the default value, 1024. . Mixed—Use the default value, 1024. nested triggers Type: Basic Default value: 1 As the name suggests, nested triggers specifies whether a trigger event on a table will fire another trigger (that is, cascade). The nesting level of triggers is 32. If you reach this limit of 32, SQL Server gives an error and rolls back the transaction. The default value of 1 means that a trigger on a table can cause another trigger to fire. network packet size Type: Basic Default value: 4096 The network packet size parameter specifies the default network packet size for SQL Server. Setting this value to a higher number (which should be divisible by 512) can improve the performance of applications that involve a large amount of data transfer from ptg 2307 Configuration Options and Performance 55 the server. Check your network configuration and set an appropriate value for this para- meter. You can also improve performance by lowering the size value for applications that are small in data transfer size. However, the usual scenario is to increase this size to accommodate large amounts of data transfer, as with bulk loads. The following is an example of this option: exec sp_configure ‘network packet size’, 8192 go RECONFIGURE go TIP You can also specify the network packet size from the client when you connect to SQL Server (using the -a option for isql, osql, and bcp). Setting the network packet size from a client can be useful when the default network packet size is adequate for gener- al application needs. However, a larger packet size might be needed for some specific operations, such as bulk copy. You can also call OLE DB, ODBC, and DB-Library func- tions to change the packet size. The following is a general recommendation of what to specify based on the different application types you are running: . OLTP—Possibly decrease this size to 512 if all queries deal with small amounts of data transfer, which is often the case in OLTP or ATM applications. . Data warehouse—Perhaps increase this to 8192 or larger to handle the consistently large data transfers in this environment. . OLAP—Use the default value, 4096. . Mixed—Use the default value, 4096. optimize for ad hoc workloads Type: Advanced Default value: 0 The optimize for ad hoc workloads option is used to improve the efficiency of the plan/procedure cache for workloads that contain many single-use ad hoc batches. When this option is set to 1, the Database Engine stores a small compiled plan stub in the plan/procedure cache when a batch is compiled for the first time, instead of the full compiled plan. This helps to relieve memory pressure by not allowing the plan/procedure cache to become filled with compiled plans that are not reused. The compiled plan stub allows SQL Server to recognize that this ad hoc batch has been compiled before but has stored only a compiled plan stub, so when this batch is invoked (compiled or executed) ptg 2308 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options again, SQL Server compiles the batch, removes the compiled plan stub from the plan/procedure cache, and adds the full compiled plan to the plan/procedure cache. Setting optimize for ad hoc workloads to 1 affects only new plans; plans that are already in the plan/procedure cache are unaffected. The compiled plan stub is one of the cache object types displayed by the sys.dm_exec_cached_plans catalog view. The following is an example of this option: exec sp_configure ‘optimize for ad hoc workloads’,1 go RECONFIGURE go PH_timeout Type: Advanced Default value: 60 You use the full-text protocol handler timeout option (PH timeout) to specify the time, in seconds, that the handler should wait to connect to a database before timing out. The default value is 60 seconds. Increase the value when connection attempts are timing out due to temporary network issues or increased workloads. The full-text protocol handler is hosted in the filter daemon host and is used to fetch the data to be full-text indexed. The following is an example of this option: exec sp_configure ‘PH_timeout’, 120 go RECONFIGURE go priority boost Type: Advanced Default value: 0 The priority boost option is used to specify the process priority of SQL Server processes on the Windows operating system. The default value of 0 means that SQL Server should run on the same priority level—a priority base of 7—as other applications on the machine. This option can be turned on if you have plenty of horsepower to deal with all other services on the box, as in a multiprocessor environment. When you turn on priority boost , the priority base of SQL Server is elevated to 13. The following is an example of this option: exec sp_configure ‘priority boost’, 1 go ptg 2309 Configuration Options and Performance 55 RECONFIGURE go NOTE You shouldn’t set the value of the priority boost parameter to 1 except in the case of a dedicated SQL Server machine with multiprocessors. Looking back at Figure 55.3, you can see the Boost SQL Server Priority on Windows option in the Processors page of the Server Properties dialog. Use care when applying this option. query governor cost limit Type: Advanced Default value: 0 Queries are often the cause of major performance problems. SQL Server can handle queries, but many are poorly written and don’t restrict the search criteria enough. This can result in runaway queries that return large result sets, and they can adversely affect the entire server’s performance. One way to control this situation is to cut off the query at the pass by specifying a maximum cost limit to queries, in seconds. If any query’s cost, in seconds, is greater than this maximum value, the query is not allowed to execute. The query governor cost limit value is server-wide and cannot be applied to just one query. Remember, though, that 0 (the default) for this option turns off the query governor, and all queries are allowed to run without any time limitation. The following is an example of this option: exec sp_configure ‘query governor cost limit’, 300 go RECONFIGURE Go To change the value on a per-connection basis, you use the SET QUERY_GOVERNOR_COST_LIMIT statement. The following is a general recommendation of what to specify based on the different application types you are running: . OLTP—Use the default value, 0. . Data warehouse—This is a must-have option for this environment. Try setting this value to 300 seconds and then get ready for the users to scream at you. On the posi- tive side, the server won’t get bogged down or freeze again. . OLAP—For OLAP systems that use SQL Server storage, set this value to 600 seconds to get started and then reduce it over time. ptg 2310 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options . Mixed—You have the same protection opportunity here as for OLAP. This won’t affect the OLTP queries, so it is safe to apply. query wait Type: Advanced Default value: -1 Queries that are memory intensive and involve huge sorts might take a long time to execute, based on the available memory during execution. SQL Server internally calculates the timeout interval for such queries. Usually, this is quite a large number. You can over- ride this value by specifying a value (in seconds) for the query wait parameter in SQL Server. If you set this value too low, you risk more frequent query timeouts when your system is under a heavy load and a highly concurrent environment. If -1 is specified (the default), the timeout is calculated as 25 times of the estimated query cost. The following is an example of this option: exec sp_configure ‘query wait’, 20 go RECONFIGURE go recovery interval Type: Advanced, self-configuring Default value: 0 The recovery interval parameter is used to specify the maximum time (in minutes) that SQL Server requires to recover a database during startup. During startup, SQL Server rolls forward all the changes committed during a SQL Server crash and rolls back the changes that were not committed. Based on the value specified for this parameter, SQL Server determines when to issue a checkpoint in every database of SQL Server so that in the event of a crash, SQL Server can recover the databases in the time specified by recovery interval . If the value of the recovery interval parameter is low, SQL Server issues check- points more frequently to allow a recovery to be faster; however, frequent checkpoints can slow down performance. Setting recovery interval too high creates a longer recovery time for databases in the event of a crash. The default value of 0 leaves this option open to SQL Server to determine the best value. The following is an example of this option: exec sp_configure ‘recovery interval’, 10 go RECONFIGURE go ptg 2311 Configuration Options and Performance 55 The following is a general recommendation of what to specify based on the different application types you are running: . OLTP—Use the default value, 0. . Data warehouse—This is an opportunity to save on checkpoints and not degrade performance in this mostly read-only environment. Set this value high. . OLAP—In this read-only environment, you have the same performance opportunity here as in a data warehouse. . Mixed—Use the default value, 0. remote admin connections Type: Basic Default value: 0 Microsoft SQL Server 2008 provides a dedicated administrator connection (DAC). The DAC lets an administrator access a running server to be able to execute diagnostic func- tions or T-SQL statements, or troubleshoot problems on the server, even when the server is locked or running in an abnormal state and not responding to any other type of user connection. By default, the DAC is available only from a client on the server. But if you set the Remote Admin connections option to 1, the DAC is available from a remote connection as well. By default, the DAC listens only on the loopback IP address (127.0.0.1), port 1434. The following is an example of this option: exec sp_configure ‘remote admin connections’, 1 go RECONFIGURE Go remote login timeout Type: Basic Default value: 20 You use the remote login timeout option to specify the number of seconds to wait before returning from a failed attempt to log in to a remote server. If you are attempting to log in to a remote server and that server is down, remote login timeout ensures that you do not have to wait indefinitely before your computer ceases its attempts to log in. This option affects connections to OLE DB providers made for heterogeneous queries. The default setting for remote login timeout is 20 (seconds). A value of 0 allows for an infinite wait. ptg 2312 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options The following is an example of this option: exec sp_configure ‘remote login timeout’, 30 go RECONFIGURE Go remote proc trans Type: Basic Default value: 0 The remote proc trans parameter allows remote procedures that are taking part in multi- server transactions to use MS DTC so that transaction integrity is maintained across servers. The default value of 0 means the remote procedure calls will not use MS DTC. Data modification at the remote server will not be a part of transactions at the local server. If you set this parameter to 1, SQL Server uses MS DTC to preserve transaction integrity across servers. This feature is still scheduled to be removed in the next version of Microsoft SQL Server. You should therefore avoid using this feature in new development work and plan to modify applications that currently use this feature. The following is an example of this option: exec sp_configure ‘remote proc trans’, 1 go RECONFIGURE Go remote query timeout Type: Basic Default value: 600 You use the remote query timeout option to specify how long (in seconds) a remote opera- tion can take before Microsoft SQL Server times out. The default is 600, which allows a 10- minute wait. This value applies to an outgoing connection initiated by the Database Engine as a remote query. This value has no effect on queries received by the Database Engine. For heterogeneous queries, remote query timeout specifies the number of seconds (initial- ized in the command object using the DBPROP_COMMANDTIMEOUT rowset property) that a remote provider should wait for result sets before it times out. This value is also used to set DBPROP_GENERALTIMEOUT, if supported by the remote provider. This setting causes any other operations to time out after the specified number of seconds. For remote stored procedures, remote query timeout specifies the number of seconds that must elapse after sending a remote EXEC statement before the remote stored proce- dure times out. ptg 2313 Configuration Options and Performance 55 The following is an example of this option: exec sp_configure ‘remote query timeout’, 300 go RECONFIGURE Go scan for startup procs Type: Advanced Default value: 0 When the scan for startup procs option is set to 1, SQL Server scans for and executes all automatically executed stored procedures on the server on startup. To set a stored procedure to become automatically executed, you use the sp_procoption system stored procedure. Typically, a stored procedure is executed at startup time when you want to have certain processing occur that creates the proper working environment for all subse- quent database processing on the server. You also can execute at startup when you want to make sure that certain stored procedures’ execution plans (with proper optimizer deci- sions) are already in the procedure cache before anyone else requests their execution. The following is an example of this option: exec sp_configure ‘scan for startup procs’, 1 go RECONFIGURE go show advanced options Type: Basic Default value: 0 By default, you do not see the advanced configuration parameters of SQL Server. If you set show advanced options to 1, you can see all the SQL Server parameters that can be set by the sp_configure command. user connections Type: Advanced, self-configuring Default value: 0 The user connections option specifies the number of concurrent users allowed on SQL Server. When the value is 0 (which is the default), SQL Server can configure the needed user connections dynamically as they are needed (unlimited). If you specify a value, you . maximum time (in minutes) that SQL Server requires to recover a database during startup. During startup, SQL Server rolls forward all the changes committed during a SQL Server crash and rolls back. value specified for this parameter, SQL Server determines when to issue a checkpoint in every database of SQL Server so that in the event of a crash, SQL Server can recover the databases in the. value: 0 Microsoft SQL Server 2008 provides a dedicated administrator connection (DAC). The DAC lets an administrator access a running server to be able to execute diagnostic func- tions or T-SQL