Track Your Cluster Failovers T-SQL Tuesday #33

Posted: August 14, 2012 in dbUtilities, SQLServerPedia Syndication, T-SQL Tuesday

Another awesome discussion for T-SQL Tuesday, and big thank you to Mike Fal. The question is what sort of tips and tricks you use with SQL Server. The first thing that came to mind for me was how I track the history of Windows cluster failovers. I am not a big fan of having to dive into error logs, events and emails to just find the history of my servers. Recently I ran into a situation where a Clustered SQL Server Install was performing better on one node of the cluster than the other node. I have a history of the performance, but I did not have a quick easy way to look at the history of what node was hosting when. The solution I came up with was to use my dbUtility database to track when a node was hosting. This way, I don’t have to go looking around error logs, or emails looking for any failover events. The solution is quite simple.

First I created a table to host the information that I wanted to track.

Simple enough? Below is a small version of the information that I track.



CREATE TABLE [CLU].[ClusterLogging](

[ClusterLoggingID] [int] IDENTITY(1,1) NOT NULL,

    [ClusterName] [sysname] NOT NULL,

    [PrimaryHostName] [sysname] NOT NULL,

    [ReadingDate] [datetime] DEFAULT getdate() NULL,




Once the table and the Schema are there, I created a stored procedure that will check and find out the host is that is currently running. This information can be pulled from the Server Property Function without much difficulty, once I have that information, I checked to see if this is a new host, if it is a new status and log the information if it is new. This is the procedure that I use.






DECLARE @CurrentStatusID INT


SET @PrimaryHostName = CAST(SERVERPROPERTY (‘ComputerNamePhysicalNetBIOS’) AS SYSNAME)

— Is this a new entry? If so insert seed.

If Not Exists (Select ClusterName, PrimaryHostName From CLU.ClusterLogging

            WHERE ClusterName like @ClusterName

            AND PrimaryHostName like @PrimaryHostName)


        Insert CLU.ClusterLogging (ClusterName, PrimaryHostName)

        VALUES (@ClusterName, @PrimaryHostName)


— What is the ID of the current Status

SET @CurrentStatusID = (Select Max(ClusterLoggingID) From CLU.ClusterLogging

            WHERE Clustername like @ClusterName

            AND PrimaryHostName like @PrimaryHostName)

— Does the current hostname match the most recent status?

If @PrimaryHostName not like (Select PrimaryHostName From CLU.ClusterLogging

            WHERE ClusterLoggingID = @CurrentStatusID)


        Insert CLU.ClusterLogging (ClusterName, PrimaryHostName)

        VALUES (@ClusterName, @PrimaryHostName)



All that is left is to schedule the execution of the stored procedure, I imagine it could be triggered as a startup procedure, but I just choose to run it on a schedule basis. I know that the times may be off a little depending on how often I run it however; it gets me in the ball park. Now I know that I can query the CLU.ClusterLogging table in my utility database and I will have a decent idea of what happened and when. Much more efficient than digging through large error logs that only go back so far.

  1. […] Shaw (b|t) gives us some information on cluster failovers. While we want our operations to appear seamless to our users, as DBAs it’s important that […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s