Alright, let's set expectations here: if I could make you an expert at SQL Server in a single web page, I wouldn't sell training classes. But in one web page, let's see if I can distill the process I use to analyze a client's diagnostic metrics.

I work through the first few tabs of the spreadsheet in order:

First, I look at the Uptime tab. In just a few metrics, I can get a pretty good idea of whether I'm dealing with an overworked monster, or a bored desktop, or a server who has amnesia because she just got rebooted and lost all her metrics.

Next, I hit the Health tab, sp_Blitz's results. I want to know if the databases are backed up because I'm a little paranoid: I won't work on a server without backups. Scrolling down through the rest of the results gives me a quick idea of whether the server has basic best practices set up (like Cost Threshold and MAXDOP configured, or whether auto-shrink has been turned on.)

Then, I check the Waits tab. I'm looking at wait time ratio, the amount of uptime versus time we've spent waiting on stuff. A couple of simple examples:

• 100 hours since startup, but only the top wait is only 10 hours - the server is bored.
• 100 hours since startup, but the top wait is over 10,000 hours - the server is busting its hump.
• If the server is bored, that doesn't mean every query is fast - but it means that I'm probably not going to be solving a server-level problem, like not enough CPUs or memory.

So in short:

1. The Uptime tab tells me about the hardware
2. The Health tab tells me about the people managing it
3. The Waits tab tells me whether the users are happy

Then, based on what their top waits are, I branch off to looking at indexes, queries, storage performance, etc. To learn more about my methodologies for that, check out my SQL Server training classes.