Microsoft SQL Server 2008 R2 Unleashed- P234 pptx

ptg 2294 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options then explicitly allow cross-database ownership chaining using the SET clause of the ALTER DATABASE statement. cursor threshold Type: Advanced Default value: -1 The cursor threshold option allows you to specify when SQL Server should generate a cursor result set asynchronously. If the optimizer estimates that the number of rows returned by the cursor is greater than the value specified by this parameter, it generates the result set asynchronously. The optimizer makes this decision based on the distribution statistics for each table that is participating in the join in the cursor. To determine the optimal value for this parameter, you need to make sure that statistics are up-to-date (by running update statistics) for the tables used in the cursors. By default, SQL Server generates a cursor result set synchronously. If you are using a fair number of cursors that return a large number of result sets, setting this value to a higher value results in better performance. Setting this value to 0 forces SQL Server to always generate a cursor result set asynchronously. The following is an example of this option: exec sp_configure ‘cursor threshold’, 100000 go RECONFIGURE go The following is a general recommendation of what to specify based on the different appli- cation types you are running: . OLTP—Use the default value, -1. . Data warehouse—A data warehousing environment is the largest potential user of this option due to the high volume of result rows returned by applications using data warehouses. Setting this value to 100,000 is a good starting point. . OLAP—Use the default value, -1. . Mixed—Use the default value, -1. default full-text language Type: Advanced Default value: 1033 The default full-text language option is used to specify a default language value for full-text indexed columns. Linguistic analysis is performed on all data that is full-text indexed and is strictly dependent on the language of the data. The default value of this option is the language of the server. ptg 2295 Configuration Options and Performance 55 The value of the default full-text language option is used when no language is speci- fied for a column through the LANGUAGE option in the CREATE FULLTEXT INDEX or ALTER FULLTEXT INDEX statements. If the default full-text language option is not supported or the linguistic analysis package is not available, the CREATE or ALTER operation doesn’t work, and SQL Server returns an invalid language specified error message. To see the list of linguistic analysis packages that are part of SQL Server 2008, you query the system view sys.fulltext_languages, as in this example: SELECT * FROM sys.fulltext_languages order by 2 Go lcid name 1025 Arabic 1093 Bengali (India) 1046 Brazilian 2057 British English 1026 Bulgarian 1027 Catalan 3076 Chinese (Hong Kong SAR, PRC) 5124 Chinese (Macau SAR) 4100 Chinese (Singapore) 1050 Croatian 1043 Dutch 1033 English 1036 French 1031 German 1095 Gujarati 1037 Hebrew 1081 Hindi 1039 Icelandic 1057 Indonesian 1040 Italian 1041 Japanese 1099 Kannada 1042 Korean 1062 Latvian 1063 Lithuanian 1086 Malay - Malaysia 1100 Malayalam 1102 Marathi 0 Neutral 1044 Norwegian (Bokmål) 2070 Portuguese 1094 Punjabi 1048 Romanian ptg 2296 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options 1049 Russian 3098 Serbian (Cyrillic) 2074 Serbian (Latin) 2052 Simplified Chinese 1051 Slovak 1060 Slovenian 3082 Spanish 1053 Swedish 1097 Tamil 1098 Telugu 1054 Thai 1028 Traditional Chinese 1058 Ukrainian 1056 Urdu 1066 Vietnamese If setting to other than the default, the sp_configure command would look like this (when set to French): exec sp_configure ‘default full-text language’, 1036 go RECONFIGURE Go default language Type: Basic Default value: 0 The default language option specifies the language ID currently in use by SQL Server. The default value is 0, which specifies the U.S. English system. As you add languages on the server, SQL Server assigns a new ID for each language. You can then use these IDs to specify the default language of your choice. You can add languages by using the SQL Server Setup program. Adding a language allows SQL Server to display error messages and date/time values in the format that is appropriate for that language. You set this option in the Server Settings tab of the SQL Server Properties dialog. You can override the default language for a login by using sp_addlogin or sp_defaultlanguage. The default language for a session is the language for that session’s login, unless overridden on a per-session basis by using the ODBC or OLE DB APIs. To see the languages supported for your SQL Server instance, you use the system view sys.syslanguages. SELECT langid, substring(name,1,20) AS name, substring(alias,1,20) AS alias, lcid FROM sys.syslanguages ptg 2297 Configuration Options and Performance 55 order by 3 Go langid name alias lcid 31 Arabic Arabic 1025 27 Português (Brasil) Brazilian 1046 23 British British English 2057 20 Bulgarian 1026 16 hrvatski Croatian 1050 12 Czech 1029 4 Dansk Danish 1030 7 Nederlands Dutch 1043 0 us_english English 1033 24 eesti Estonian 1061 10 Suomi Finnish 1035 2 Français French 1036 1 Deutsch German 1031 19 Greek 1032 13 magyar Hungarian 1038 6 Italiano Italian 1040 3 Japanese 1041 29 Korean 1042 25 Latvian 1062 26 Lithuanian 1063 8 Norsk Norwegian 2068 14 polski Polish 1045 9 Português Portuguese 2070 15 românä Romanian 1048 21 Russian 1049 30 Simplified Chinese 2052 17 Slovak 1051 18 slovenski Slovenian 1060 5 Español Spanish 3082 11 Svenska Swedish 1053 32 Thai 1054 28 Traditional Chinese 1028 22 Türkçe Turkish 1055 Setting the default language to something other than the default would look like this (again, when set to French): exec sp_configure ‘default language’, 2 go ptg 2298 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options FIGURE 55.4 SQL Server 2008 language configuration from SSMS. RECONFIGURE Go You can change the language for a session during the session through the SET LANGUAGE statement. From SSMS, you can easily see the current default language and default full-text language settings, as shown in Figure 55.4. EKM provider enabled Type: basic Default value: 0 The EKM provider enabled option controls Extensible Key Management (EKM) device support in SQL Server. By default, this option is off. SQL Server 2008 Extensible Key Management enables third-party EKM/HSM vendors to register their modules in SQL Server. When registered, SQL Server 2008 users can use the encryption keys stored on EKM modules. This enables SQL Server to access the advanced encryption features these modules support, such as bulk encryption and decryption, and key management functions such as key aging and key rotation. ptg 2299 Configuration Options and Performance 55 The following is an example of this option: exec sp_configure ‘EKM provider enabled’, 1 go RECONFIGURE go filestream_access_level Type: basic Default value: 0 You use the filestream_access_level option to change the FILESTREAM access level. Before this option has any effect, the Windows administration settings for FILESTREAM must be enabled. You can also enable these settings when you are installing SQL Server or by using SQL Server Configuration Manager (SSCM) for a specific SQL Server instance. Setting the value to 0 disables this option. A value of 1 enables FILESTREAM for T-SQL access only. A value of 2 enables FILESTREAM for both T-SQL and Win32 streaming access. FILESTREAM integrates the SQL Server Database Engine with an NTFS file system by storing varbinary(max) binary large object (BLOB) data as files on the file system. T-SQL statements can insert, update, query, search, and back up FILESTREAM data. The following is an example of this option: exec sp_configure ‘filestream_access_level’, 2 go RECONFIGURE fill factor Type: Basic Default value: 0 The fill factor option allows you to define the percentage of free space on a data page or an index page when you create an index or a table. The value can range from 1 to 100. Setting the value to 80 would mean each page would be 80% full at the time of the create index . SQL Server also allows you to specify the value of fill factor at the server level by providing a fill factor parameter. The following is an example of this option: exec sp_configure ‘fill factor’, 80 go RECONFIGURE Go ptg 2300 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options The following is a general recommendation of what to specify based on the different application types you are running: . OLTP—This is a good candidate for leaving space free in pages due to the update, delete, and insert characteristics. Try 80% full value first and watch the page split activity. . Data warehouse—Use the default value, 0. . OLAP—Use the default value, 0. . Mixed—Use the default value, 0, or about a 90% full value. index create memory Type: Advanced, self-configuring Default value: 0 The index create memory option is used to control the amount of memory used by index creation sorts. It is a self-configuring option and usually doesn’t need to be adjusted. However, if you are having problems with the creation of large indexes, you might want to try specifying a KB value here that will contain the sort portion of the index create. The following is an example of this option: exec sp_configure ‘index create memory’, 1000 go RECONFIGURE go in-doubt xact resolution Type: Advanced Default value: 0 The in-doubt xact resolution option changes the behavior of the default outcome for transactions that the Microsoft Distributed Transaction Coordinator (MS DTC) is unable to resolve. This helps prevent MS DTC–related downtime and provides clarity to transaction outcomes across database servers. A value of 1 is a presume commit directive. In other words, any MS DTC in-doubt transactions are presumed to have committed. A value of 2 is a presume abort directive, which means any MS DTC in-doubt transactions are presumed to have aborted. The following is an example of this option: exec sp_configure ‘in-doubt xact resolution’, 2 go RECONFIGURE go ptg 2301 Configuration Options and Performance 55 lightweight pooling Type: Advanced Default value: 0 Lightweight pooling is relevant to multiprocessor environments that have excessive context switching. By flipping the lightweight pooling switch, you might get better throughput by performing the context switching inline, thus helping to reduce user/kernel ring transitions. The lightweight pooling option actually causes SQL Server to switch to fiber mode scheduling. CLR execution is not supported under lightweight pooling. You can disable one of two options: clr enabled or lightweight pooling. The following is an example of this option: exec sp_configure ‘lightweight pooling’, 1 go RECONFIGURE go The following is a general recommendation of what to specify based on the different application types you are running: . OLTP—This is a good candidate for use on a multiprocessor machine. . Data warehouse—This has a good potential for usage on a multiprocessor machine. . OLAP—Use the default value, 0. . Mixed—Use the default value, 0. locks Type: Advanced, self-configuring Default value: 0 In versions of SQL Server prior to 2005, the DBA had to specify the number of locks avail- able to SQL Server. If this parameter was set to a low value, a query requiring a large number of locks would fail at runtime. Setting it too high would result in wasting memory that otherwise could be used to cache data. SQL Server 2008 can handle locks dynamically if this parameter is set to the default value ( 0). SQL Server initially allocates 2% of memory available to SQL Server (or usually about an initial pool of 2,500 lock structures). As lock resource structures are consumed, the lock manager allocates more lock resources to the pool, to a maximum of 60% of the memory available on SQL Server. When the locks option is not set to 0, lock escalation occurs when the number of locks reaches 40% of the value specified for locks. Unless you are certain of the overall lock consumption of your application, you probably don’t need to change this value. ptg 2302 CHAPTER 55 Configuring, Tuning, and Optimizing SQL Server Options The following is an example of this option: sp_configure ‘locks’, 10000 go RECONFIGURE go max degree of parallelism Type: Advanced Default value: 0 The max degree of parallelism option specifies the number of threads to be used for parallel query execution. On a single-processor server, this value is always ignored. For multiprocessor servers, a default value of 0 signifies that all the CPUs will be used for parallel query execution. When SQL Server 2008 runs on a machine that has more than one processor, it detects the best degree of parallelism. If you set this value to 1, all query plans are serialized. If the affinity mask option is on, parallel query execution takes place only on the CPUs for which the affinity mask bit is turned on. In that way, these two options can be used in conjunction. The application types assessment is the same as described for the affinity mask option. The following is an example of this option: sp_configure ‘max degree of parallelism’, 4 go RECONFIGURE go max server memory and min server memory Type: Advanced, self-configuring Default values: 2147483647 and 0 The max server memory option specifies the maximum amount of memory (in megabytes) available to SQL Server. It is used in conjunction with min server memory, and they essen- tially establish upper and lower bounds for memory allocation. SQL Server uses this memory for user connections, locks, internal data structures, and caching of the data. This is the memory pool described earlier. The default value of 2147483647 for the max server memory option means that SQL Server performs dynamic allocation of memory from the operating system, based on available physical memory on the machine. The default value of 0 for the min server memory option means that SQL Server starts allocation memory as it is needed and then never goes below the minimum value after it is reached. ptg 2303 Configuration Options and Performance 55 The SQL Server lazywriter process is responsible for making sure enough memory is avail- able to SQL Server for the optimal number of buffers and Windows so that no excess paging occurs at the operating system level. The lazywriter process frequently checks phys- ical memory available on the machine. If the memory available is greater than 5MB, lazy- writer assigns excess memory to the SQL Server buffer cache. You should watch the Working Set performance counter, which shows the amount of memory used by a process (SQL Server in this case). If this number is consistently below the amount of memory for which SQL Server is configured, SQL Server is configured for more memory than it needs. You can also adjust the set working set size configura- tion option. If SQL Server is the only application running on a machine, you might want to perform static memory allocation. You need to be careful when you allocate fixed memory to SQL Server. If you allocate more memory to SQL Server than the machine has, SQL Server fails to start. You use the -f option during startup to bring up SQL Server with the default configuration. You can then change the value to the correct value and restart SQL Server. The following is an example of this option: exec sp_configure ‘max server memory’, 200 go RECONFIGURE Go exec sp_configure ‘min server memory’, 8 go RECONFIGURE go Because memory is managed dynamically, these settings basically create the lower and upper bounds within which SQL Server must operate. When SQL Server is started, it uses the minimum server memory amount to pre-allocate space to SQL Server. If the load on the server never requires allocating the amount of memory specified in the minimum server memory option, SQL Server runs with less memory. Figure 55.5 shows both the minimum server memory and maximum server memory settings on the Server Properties page. The following is a general recommendation of what to specify based on the different application types you are running: . OLTP—For those with heavy loads, this is a good candidate for high minimum memory settings. . Data warehouse—Use the default values. . OLAP—Use the default values. . Mixed—For those with heavy loads, this is a good candidate for high minimum memory settings. . in SQL Server. By default, this option is off. SQL Server 2008 Extensible Key Management enables third-party EKM/HSM vendors to register their modules in SQL Server. When registered, SQL Server. allocate fixed memory to SQL Server. If you allocate more memory to SQL Server than the machine has, SQL Server fails to start. You use the -f option during startup to bring up SQL Server with the default configuration bounds within which SQL Server must operate. When SQL Server is started, it uses the minimum server memory amount to pre-allocate space to SQL Server. If the load on the server never requires