Modifying SQL Server Parameters | Microsoft Systems Management Server 2003 Administrators Companion (Pro-Administrators Companion)

< Day Day Up >

Several SQL Server parameters can affect how well the SMS database will be managed. SQL Server self-manages most of these parameters—that is to say, you shouldn’t need to fool around with them. In some scenarios, however, you might choose to manually configure one or more parameters—for example, when trying to optimize the use of server resources on the SQL Server system. In those cases, when you install SQL Server you should pay particular attention to the following SQL Server configuration parameters and set them appropriately before installing SMS 2003: User Connections, Open Objects, Memory, Locks, and Tempdb Size. Table 19.2 provides guidelines for setting these parameters for SQL Server 2000.

Table 19.2: SQL Server configuration parameters
Parameter	Guidelines
User Connections	SMS 2003 requires a minimum of 40 user connections for the site server and 2 connections for each SMS Administrator Console you plan to install. It also requires five additional user connections for each instance of the SMS Administrator Console, if more than five consoles will be running concurrently on your site. You can set SMS 2003 to calculate this number and configure it automatically during setup. Each installation of SMS 2003 requires 20 user connections. In SQL Server this allocation is made dynamically at the time of the connection, providing more efficient memory management.
Open Objects	This parameter indicates the number of tables, views, stored procedures, and the like that can be open at a time. If you exceed the specified number of open objects, SQL Server must close some objects before it can open others, resulting in a performance hit. For most sites, a value of 1000 should be sufficient. For large sites, however, this number could be 5000 or more. Use SQL Server performance counters to track the number of open objects in use to determine the optimum number for the SMS site. Note that SQL Server sizes this number automatically.
Memory	This parameter indicates the amount of RAM that should be used for database caching and management. SMS automatically allocates 16 MB of RAM for SQL Server use. SQL Server allocates memory dynamically in 8 KB units. You can define a range for SQL Server to use.
Locks	This parameter prevents users from accessing and updating the same data at the same time. Because of the volume of information contained in the database, Microsoft recommends setting this value from 5000 to 10,000 depending on the size of the database and the number of SMS Administrator Consoles.
Tempdb Size	This temporary database and log are used to manage queries and sorts. By default, the tempdb database and log information are maintained on the same server running SQL. It’s recommended that the tempdb data device size should be at least 20 percent of the SMS database size. SQL Server, as you have by now surmised, sizes the tempdb database dynamically.

Modifying Parameters for SQL Server 2000

To modify these parameter settings for SQL Server 2000, follow these steps:

In Enterprise Manager, select your SQL Server entry (the icon of a computer with a white triangle within a green circle), right-click it, and choose Properties from the context menu to display the SQL Server Properties dialog box, shown in Figure 19.13.

Figure 19.13: The SQL Server Properties dialog box.
The SQL Server Properties dialog box contains tabs for those parameters for which you can modify settings. (Recall from Table 19.2 that SQL Server dynamically manages most SMS-specific parameters.)
Select the Memory tab, shown in Figure 19.14. Notice that the Dynamically Configure SQL Server Memory option is enabled by default, although you can modify the memory range within which SQL Server should manage memory allocation. You can also specify a fixed amount of memory as well as identify the amount of memory to allocate per user for query execution.

Figure 19.14: The Memory tab.
Select the Connections tab, shown in Figure 19.15. This tab displays the maximum number of user connections that were configured for SQL Server during the SMS setup. By default, this value is set to 0, which means that SQL Server will dynamically allocate connections and appropriate resources to support them as required. The allocation of user connections is a value you should monitor, especially if you choose to enter your own maximum value. If you add SMS Administrator Consoles or define additional site systems, you might need to increase the maximum number of connections to accommodate the increased resource demand by modifying this setting.

Figure 19.15: The Connections tab.
When you have finished making your changes, click OK to save them. You might need to stop and then restart SQL Server to implement your changes. If this step is necessary, a message box will display to that effect.

More Info
Several performance tuning documents are available at Microsoft’s SQL Web site (http://www.microsoft.com/sql/techinfo/administration/2000/perftuning.asp).

The topic of time synchronization is significant enough to bear revisiting here (you can refer to the “Real World” sidebar in Chapter 2 entitled “Synchronizing System Clocks” for a specific example), especially if SQL Server and the SMS site server are installed on two different servers. Because the time stamp of data objects created will generally be that of the server running SQL, it’s important that the SMS site server and the server running SQL synchronize their system times on a regular basis.

It’s also important that the SMS clients synchronize their time with the SMS site server and the server running SQL. SMS client computers will check their own system clocks when determining when to execute a program or run an agent. You can see how easily things can go awry if the server running SQL, the site server, and the client computer system clocks are all set to different times. A package might not execute at the time you expected, or an inventory collection might not take place because the scheduled times and the system clock are out of sync.

One way to overcome this situation is to identify one server as your time server for the SMS site. Have all your site systems, the SMS client computers, and the server running SQL synchronize their times with the time server. Or you might even consider making the server running SQL the time server for the SMS site. Fortunately, Windows 2000 and higher domains have this functionality built in.

< Day Day Up >