The word \u201cdashboard\u201d immediately puts me into a state of suspicion. This is probably because I\u2019ve been a part of the corporate world for 18 years now and, fair or not, the word \u201cdashboard\u201d gives me flashbacks of executive conversations where I\u2019m asked to summarize complicated information into a single square \u2013 while somehow defying the laws of physics and providing all the necessary detail being asked for.<\/p>\n
So when I heard of the \u201cAlwaysOn Dashboard<\/em>\u201d \u2013 I was pretty sure I wouldn\u2019t like it and that I would stick primarily with other methods.<\/p>\n \n Well \u2013 I was wrong.<\/p>\n While any tool could use further improvement, the AlwaysOn Dashboard is definitely something I\u2019ll be using in the future. Hence the purpose of this post was just to show the various questions the dashboard can answer.<\/p>\n Where am I?<\/strong><\/p>\n I start with this question because depending on which replica you\u2019re launching the dashboard from, you\u2019ll see a different view of the world. For example, the following is the first section of the dashboard when launched from the primary replica of an availability group called EMU-AG1:<\/p>\n As you can see, from the primary I\u2019m getting three sections and a view of my replicas, availability databases and more (which I\u2019ll get in to later in this post).<\/p>\n Contrast this to launching the dashboard from a secondary replica:<\/p>\n You can see that I\u2019m getting information from the perspective of just <\/em>that replica. You may have no other choice in a disaster recovery scenario \u2013 and in that case, you will see even less. But the key is not to be surprised to see this subset of information if you\u2019re launching the dashboard from a secondary instead of the primary. If you want to ensure you\u2019re connecting to the primary, you could connect with SSMS to the Availability Group listener name instead, again assuming you\u2019re not in an outage scenario.<\/p>\n What can I find out by default?<\/strong><\/p>\n <\/p>\n You saw by the earlier screen shots that we can find out quite a bit by default:<\/p>\n \u00b7 Where is the primary replica? (called \u201cprimary instance\u201d on the dashboard)<\/p>\n \u00b7 What are the roles of each replica? (primary or secondary)<\/p>\n \u00b7 What are the failover modes? (automatic or manual)<\/p>\n \u00b7 What are the synchronization states? (for example \u2013 \u201cnot synchronizing\u201d, \u201csynchronizing\u201d, \u201csynchronized\u201d)<\/p>\n \u00b7 What are the availability databases?<\/p>\n \u00b7 What are their individual availability database states?<\/p>\n \u00b7 What are the database failover readiness states? (data loss possible, no data loss)<\/p>\n \u00b7 Any issues at the replica scope?<\/p>\n \u00b7 Any issues at the availability database scope?<\/p>\n Regarding the \u201cissues\u201d \u2013 let\u2019s say one of my Windows Server Failover Cluster (WSFC) nodes is paused, and thus, one of my replicas is now offline. The issues column in the availability replicas shows the following:<\/p>\n Clicking on the link-text, I see additional information in the Policy Evaluation Result on Availability Replica dialog box:<\/p>\n So the theme is becoming clear that the dashboard is pointing out the summarized things I should be concerned with and then allowing me to click through to add additional information \u2013 instead of overwhelming me with information by default.<\/p>\n What else?<\/strong><\/p>\n Right-click on the availability replica section and you\u2019ll see other very useful data points:<\/p>\n We start seeing information that merges the availability group and Windows Server Failover Cluster (WSFC) worlds \u2013 such as Quorum Votes and Member State (for example \u2013 if I pause a WSFC node, I\u2019ll see Member State = Offline).<\/p>\n <\/p>\n We have the same ability to add columns for the availability databases section. Right clicking the column headers reveals quite a few useful statistics (and again \u2013 I\u2019m impressed that the UI designers exerted editorial control and didn\u2019t try to stuff all columns into the report by default):<\/p>\n Some excellent data points here \u2013 including Estimated Recovery Time, Estimated Data Loss, Synchronization Performance, Log Send Queue Size and Redo Queue Size. And while this isn\u2019t replacing Perfmon for trending analysis \u2013 if you\u2019re in the middle of a \u201cthings are slow now<\/em>\u201d scenario, this additional information is incredibly useful.<\/p>\n Where else can I go?<\/strong><\/p>\n In the upper-right hand corner of the dashboard (I\u2019m using the 11.0.2316 version of the SQL Server 2012, by the way), I can navigate into three different useful areas\u2026<\/p>\n The \u201cStart Failover Wizard\u201d is as you might suspect. This wizard allows me to fail over to a secondary replica, making it the new primary replica.<\/p>\n The View AlwaysOn Health Events option allows you to explore Extended Events captured via the \u201cAlwaysOn_health\u201d session (which Jonathan has already talked about in more detail). What I love about this viewer (pictured below) is that unlike the dashboard which gives us a moment in time, with the viewer I can see what has happened recently that is noteworthy. And just like the dashboard, I can add the columns I\u2019m interested in by right-clicking the column headers and then choosing what I need and also clicking specific rows to reveal details:<\/p>\n Back to the main dashboard, if I click the \u201cView Cluster Quorum Information\u201d link, I\u2019ll see data from a WSFC quorum perspective (nodes, member type, member state, and vote assignment):<\/p>\n What about the T-SQL?<\/strong><\/p>\n The information captured on the dashboard also provides us (if you snoop via Extended Events or SQL Trace) with guidance on the new catalog views and DMVs. Below I\u2019ve capturing the commands behind the scenes \u2013 removing most of the extraneous T-SQL to show the core areas where some of this data is pulled for the dashboard. I didn\u2019t clean up the original formatting from what I captured \u2013 so please forgive everything being in lower-case. Also \u2013 in many cases more information is pulled than displayed \u2013 and many fields are converted to a more readable format for use on the dashboard. I still find it useful to understand the origins of the data:<\/p>\n
<\/a><\/p>\n
<\/a><\/p>\n
<\/a><\/p>\n
<\/a><\/p>\n
<\/a><\/p>\n
<\/a><\/p>\n
<\/a><\/p>\n
<\/a><\/p>\n
<\/a><\/p>\n
<\/a><\/p>\n