Beginning with SQL Server 2000, performance objects are named differently depending on whether you are running a single, unnamed instance of SQL Server or either a named instance or multiple instances of SQL Server. If you are installing SQL Server on a machine that is also running a previous version of SQL Server, then you must install a named instance of SQL Server. For more information, see the section entitled “Working with Named and Multiple Instances of SQL Server 2000” in the SQL Server 2000 online documentation.
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.