I like Performance Monitor (perfmon); its a good tool for diagnosing many different types of problems. Its great for determining from how well your memory is handling requests to how well your CPU usage is doing...its also great for checking out different SQL Server metrics. In SQL Server 2005, the sys.dm_os_performance_counters Dynamic Management View (DMV) is introduced to allow you to query SQL Server related performance counters directly through the database engine. This makes is very useful when you need to quickly determine your buffer cache hit ratio or how many lock deprecated features being ran in your SQL engine. This DMV is straightforward to use, which allows you to easily setup your own custom procedures to quickly review any performance metric that may be important to you.
Lets run a quick query against the sys.dm_os_performance_counters DMV to see what kind of data we are dealing with:
select *
from sys.dm_os_performance_counters
Here is a simple output from my system:

Its all SQL Server related infromation, which may not be 100% what you might want to monitor...but it is a good start. It allows me to monitor just about any SQL Server related metric that I want. For instance, if I wanted to see how many temp tables were currently on my system, I could write a little script like the one below.
select *
from sys.dm_os_performance_counters
where counter_name = 'Active Temp Tables'
GO
IF OBJECT_ID('tempdb..#NewTempTable') IS NOT NULL
DROP TABLE #NewTempTable
GO
CREATE TABLE #NewTempTable
(
Field1 INT
)
GO
select *
from sys.dm_os_performance_counters
where counter_name = 'Active Temp Tables'
And the output from my home system:

You can see from the output above that the DMV pulls accurate information. When I first ran the query there were no temp tables on my system. I created a temp table, and then reran the query again. The DMV returned that there was one active temp table. Neat stuff...and very handy.
While having the ability to see how many temp tables on my system might not be really useful right now (it very well could be depending on your environment), you can easily see how you could write your own custom routines to pull data from this table that is important to you. The trickiest part is determine which counter is what you want to look at. That is a whole other topic in and of itself.
Hope this helps!
Tim
Posted
9/30/2009 10:21 PM
by
TimChapman