Feb 04 2013

New DMO in Azure SQL Database: sys.dm_db_wait_stats

I just did a series of Boogle searches and when that didn’t find anything I tried Ging. Neither listed sys.dm_db_wait_stats. Nothing in a search directly against MSDN either. So, let me introduce you to a new DMO, sys.dm_db_wait_stats.

It’s a dynamic management view since it doesn’t require any input. The output is about what you would expect if you thought about it for a second:

NewAzureDMO

 

In short, what we have is the sys.dm_os_wait_stats moved internally into your SQL Database so, even though you cannot get at any of the OS counters from with an a SQL Database normally. In short, thanks Microsoft. Now we can see the wait statistics on our Azure SQL Database in order to better understand where things are problematic.

Without documentation I don’t know for sure how far back these stats go. But like the other wait stats, the best way to use them would be to query them twice, say, once an hour ago and once now, or once yesterday and once today. Having two comparison points is how the values prove useful anyway. It’s likely that they reset when your instance moves. I’m working on trying to confirm this.

8 Comments

  • By Thomas LaRock, February 4, 2013 @ 8:49 am

    The natural first question is this: what can I do with this information? It’s not like I call folks at Azure and tell them to make changes, right?

    The follow up question then becomes…how soon before I *can* make changes? For example, if WASD is really just a contained database, perhaps we are getting closer to the point I would be able to lift and load and deploy elsewhere, maybe to a system where I can tweak the O/S.

  • By Grant Fritchey, February 4, 2013 @ 10:56 am

    I’d go back to knowledge is power. If you know what is causing your systems to run slow, you can make determinations as to whether or not it’s something you can affect or something you just have to suffer through or something you need to leave SQL Database over. I think it’s great that we can understand why things are slow. And, let’s face, the number one issue for most people is still going to be what the number one issue is on their local box, their code.

  • By Tony, February 4, 2013 @ 2:28 pm

    My question would be – is that instance-wide stats, just exposed via a database-scoped dmv, or is that database-scoped wait stats?
    If its just the wait stats coming from a specific db, then I hope they bring that into regular non-azure SQL Server, as that could be quite useful.

Other Links to this Post

  1. Azure SQL Database の sys.dm_db_wait_stats を使ってみる « SE の雑記 — February 6, 2013 @ 8:53 am

  2. Shareables: Week of February 2, 2013 | SQLAgentman — February 10, 2013 @ 3:12 pm

  3. Shareables: Week of February 3, 2013 | SQLAgentman — February 10, 2013 @ 3:22 pm

  4. Windows Azure Community News Roundup (Edition #54) - Windows Azure Blog — February 11, 2013 @ 2:01 pm

  5. Hyper-V King — February 13, 2013 @ 8:55 am

RSS feed for comments on this post. TrackBack URI

Leave a comment