1. How effective are the memory-resident database buffers at reducing disk I/O?

2. Where have you placed the database transaction recovery log files?

3. Does the database design minimize contention for SQL Server locks and latches?

4. Are high volume SQL Server queries fine-tuned to use appropriate index fields?

The SQL Server 2000 counters provide a wealth of performance statistics that can be used to these and other questions.

We recommend reading “Inside Microsoft SQL Server 2000″ by Kalen Delany of the SQL Server development team and “Microsoft SQL Server 2000 Performance Tuning Technical Reference” by Ed Whalen (and others) if you are interested in finding out more about SQL Server performance and tuning.

If a single, unnamed instance of SQL Server is installed, the SQL Server 2000 performance objects are named “SQLServer:” just like SQL Server 7, although subsequent versions of SQL Server contain additional new objects and counters. For example, the SQLServer:Databases object is an instanced object containing performance counters for each SQL Server database that is defined. If you have a SQL Server 2000 database called “Customers,” you will see an object named SQLServer:Databases with an instance name of Customers. Using the syntax that the MS Performance Monitor recognizes, you would see a counter named SQLServer:Databases(Customers)\Transactions/sec.

If named instances of SQL Server 2000 are installed, the performance objects use a prefix of “MSSQL” instead. The SQL Server perflib actually creates objects named “MSSQL$VSDOTNET:Databases” where the SQL Server instance sysname, (in this example, “VSDOTNET”) is embedded in the object name. Performance Sentry removes the sysname from the object name and makes it the object instance name. In the case of an object like SQLServer:Databases, the sysname is reported as the parent instance name. Using the syntax that the MS Performance Monitor recognizes, you would see a counter named MSSQLServer:Databases(Customers,VSDOTNET)\Transactions/sec.

To make sure that you can gather SQL Server performance data without regard to whether unnamed or named instances of SQL Server are installed, we recommend you place both sets of SQL Server performance objects in your DCS, similar to the SQL Server Starter Set DCSs that ships with the product. 

When you specify that both sets of SQL Server objects should be collected, you can expect to see a Warning message at the start of each collection cycle like the following:

The following objects were specified in the DCS but failed to return data.

These objects will be skipped this cycle.

SQLServer:Buffer Manager (L0, G17100)

SQLServer:Buffer Partition (L0, G17250)

SQLServer:General Statistics (L0, G17300)

SQLServer:Locks (L0, G17500)

SQLServer:Databases (L0, G17700)

SQLServer:Latches (L0, G17900)

SQLServer:Access Methods (L0, G18100)

SQLServer:SQL Statistics (L0, G18300)

SQLServer:Cache Manager (L0, G18500)

SQLServer:Memory Manager (L0, G18700)

SQLServer:User Settable (L0, G18900)

SQLServer:Replication Agents (L0, G19100)

SQLServer:Replication Merge (L0, G19300)

SQLServer:Replication Logreader (L0, G19500)

SQLServer:Replication Dist. (L0, G19700)

SQLServer:Replication Snapshot (L0, G19900)

 This is because only one set of the SQL Server objects that were specified in the DCS can be collected. In this example, there is no ‘default’ instance of SQL Server only named instances of SQL Server, so the objects prefixed “SQL Server:” that are associated with a single, unnamed instance are not found.

One way to accomplish that is to use one of the User Settable counters that are available in SQL Server to return the process ID of that instance of SQL Server, which can be accessed by executing the SERVERPROPERTY statement in a stored procedure. The process ID provided in the User Settable counters can then be matched against the ID Process field of the corresponding instance of the sqlservr Process record.

Follow these steps to output the process ID in one of the User Settable counters:

	Add the MSSQL:User Settable object to the data collection set that are using to gather performance data from your SQL Server machines. Assign and activate this collection set.
	To set a value for one of the User Settable counters, define and execute a stored procedure that executes one of the system stored procedures in the Master database named sp_User_Counter1 through sp_User_Counter10 so that it contains the value of the Process ID from an execution of the SERVERPROPERTY statement, as follows:

declare @ProcessID as integer
set @ProcessID = (SELECT CONVERT(char(20), SERVERPROPERTY(’ProcessID’)))
exec sp_user_counter1 @ProcessID

This example sets the value of the User Settable object’s User Counter 1 to the Process ID for that instance of SQL Server. Check the box to indicate that you want this stored procedure to be triggered to execute whenever this instance of SQL Server starts.

After you have created this stored procedure, it will look similar to this:

Note that the SQL Server User Settable User Counters can only report numeric data, which is why the ProcessID from SERVERPROPERTY must be explicitly converted to an integer value before you call one of the sp_User_Counter stored procedures. For example, if you would also like the SQL Server version information available, you could add the following to your store procedure:

declare @ProductVersion as integer
set @ProductVersion = (SELECT CONVERT(char(20), SERVERPROPERTY(’ProductVersion’)))
exec sp_user_counter2 @ProductVersion

The Product Version information that the SERVERPROPERTY statement returns is a character string with a value something like “8.00.194″, that this SQL statement converts to the closest integer value, which is 8.