This is a quick tip but an important one. I see many people using SQL Server Management Studio (SSMS) and they aren't aware of Activity Monitor.
While there are many clever things that we can do with queries, to interrogate the health of the system, don't forget that there is quite a bit of useful information in Activity Monitor, and it's easy to get to.
There are two basic ways to launch Activity Monitor. The first is to right-click the server in Object Explorer:
The other common way to launch it is from the Toolbar:
Note that if you connect to more than one server in Object Explorer, Activity Monitor will connect to whichever one you have selected any object from within.
Activity Monitor puts a bit of a load on the server that it's connected to but I generally don't find it too bad. However, please don't leave it running and go on using other tabs. I've been to sites where there are many copies of it running all the time from several users. Don't do that.
I don't find most of the graphs at the top very useful, apart from perhaps the processor time.
It will show you if the server is running flat out.
The list of Processes is more interesting. If you right-click any session, you get these options:
The Details link will show you the last command executed on that connection. Take note that this doesn't mean it's still running. You can also kill the process (obviously carefully), and you can connect SQL Server Profiler to the server and filter the session immediately, to see what it's doing.
The columns are filterable.
They show you a list of values currently in that column, plus an All, and a choice of Blanks (rows with no value in this column) or NonBlanks (rows with anything in this column). They start as All.
For a simple example of using this though, we could pick sessions that have any type of command running, by choosing Task State of RUNNING.
One that I often use this view for is to look for blocking issues. Every process that's blocked by another process will tell you that. Generally, what I'm looking for is the head of a blocking chain ie: who's the main culprit that's blocking everyone.
For that, I look for a value of 1 in the Head Blocker column. Unfortunately, the way it's designed, you can't select that value until there is a row with that value.
The Application Name, Database Name, and Login can all be pretty useful as well.
The Resource Waits section is only mildly interesting.
The information there is at a bit of a coarse level to be really useful to me. Note that on this system, Buffer I/O is top of the list, but the cumulative wait time (since the server restarted) is small. Over time, if the system has been up for a long time, you can start to get a feel for the main waits in here, but be aware that there are a lot of values that can appear in here, without actually being an issue.
The Data File I/O list is a little more interesting:
This will show you how busy each data and log file is, for all databases. I generally sort it by Response Time (ms) descending. The value here is then basically the latency for the I/O on that file. In this example, it's 8 milliseconds. That's ok.
The Recent Expensive Queries list is interesting. The information is available from the system DMVs but this puts some useful data in an easy to get location:
It keeps updating this over time. Note that this won't be showing you queries currently running, just ones that were expensive and finished recently. If you right-click one, you can either look at the query text, or check out the execution plan that was being used.
The final section with Active Expensive Queries will only have data if you're using Live Query Statistics. I'll write about it another day.