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.