Survey: what is the most worrying wait type?

Here’s another survey for you, and I’m really looking forward to seeing and discussing the results of this one.

Imagine you’re the new DBA for a company (which shouldn’t be hard for most of you :-) and a week ago a new release of the client and server code was rolled out, and you cleared out the wait statistics using DBCC SQLPERF. You’ve never monitored wait statistics on this production SQL Server before, although you’ve done so extensively in previous places you’ve worked. Today you look at the aggregate wait statistics from the last week, using a script that presents them in descending order of total wait time for that wait type. You’ve been on vacation for the last week and so don’t know if there have been any complaints about performance since the roll-out.

Survey is now closed – see here for results

Without considering anything except the wait type name, which of the following wait types (listed in alphabetical order) would you be most concerned to see as the top wait type for the past week (i.e. the most aggregate wait time)?


It’s deliberate that there is  no ‘it depends’ option, and no ‘Other’ option for you to type something, so please don’t leave comments complaining about that.

I’ll editorialize the results next week, along with what my pick would be and rationales for picking each of them.

Thanks!

6 thoughts on “Survey: what is the most worrying wait type?

  1. It would be nice if you asked why for each of those. Most of these are worrying and would take some effort to resolve, but only one is typically outside of a DBA simply saying they’ll fix it on their own and be done with it.

    1. As I said, I deliberately didn’t put in an option for people to say why. I disagree – depending on the root cause, most of these might not be fixable by the DBA without dev or some other part of the IT organization being involved too.

  2. I used a process of elimination: of every server I’ve ever seen I eliminated all wait types I have actually seen bubble to the top *without* causing critical performance problems (emphasis on “critical”). I figure whatever remains is probably something you definitely don’t want to see. I’ll be interested to know if I’m right. :-)

  3. Hi Paul…I’m not seeing the list of choices but the most egregious one for me is often OLEDB caused by use (or misuse) or Linked Servers. After that I’d say ASYNCH_NETWORK_IO caused by my developers asking for too much data (unfortunately often coupled with the OLEDB)

  4. If CXPACKET isn’t number one I get worried. If CXPACKET isn’t on the list I get even more worried. WRITELOG and PAGEIOLATCH seem to be killers. That IO stack is such a pain in my tail.

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

Some thoughts on courage

(This is also the Ponderings – editorial – in today’s SQLskills newsletter.) I want to start out this post by sincerely thanking everyone who emailed

Explore

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.