SQL Saturday Cleveland 2014

Cleveland SQL SaturdayHappy New Year, and welcome to another exciting year of SQL Server learning! With that said, why not join us at Cleveland’s 3rd SQL Saturday on February 8th at Hyland Software? The weather may be cold and gray outside, but I promise you it’ll be warm, inviting, and fun at our event! This year I’ve decided to step into the captain’s seat and lead the planning efforts for SQL Saturday, and it’s been a blast! We have a ton of awesome speakers and experts lined up like Tom LaRock, Steve Jones, Tim Ford, Grant Fritchey, Kendal Van Dyke, Argenis Fernandez, Stacia Misner, Andy Leonard, and Erin Stellato, just to name a few. Check out the full line-up here! In addition to our amazing speaker line-up, we’ll also have some fun activities and experts available to answer your questions. Believe me, you don’t want to miss this event!

Oh, and did I mention that we have two awesome pre-con sessions available? Why yes, yes we do!

A Day of SQL Server Internals and Data Recovery

Take your recovery game to an all new level. Take a deep dive into SQL Server internals and data recovery and learn how to handle a wide variety of data loss and corruption scenarios. The session will cover how to be prepared for, prevent, and recover data lost due to deletion or corruption.

Learn the following skills in this session:

  • Built-in functionality in SQL Server for preventing and detecting corruption that you may not even know about.
  • How to identify a specific transaction in the transaction log and recover data lost from that transaction.
  • Categories of corruption and how to manage recovery differently for each one.

Don’t come empty handed. Bring your laptop and we’ll practice recovering corrupt databases together.

Speaker Bio:

Argenis Fernandez is a Senior Database Engineer for SurveyMonkey based in Redmond, WA. He has worked with SQL Server for over 15 years and enjoys large SQL Server farms, high-end OLTP databases, managing Windows environments, performance troubleshooting, high availability, disaster recovery, best practices, and PowerShell scripting. Prior to SurveyMonkey, Argenis worked as a Senior Database Administrator for Coinstar/redbox and as a Senior Consultant on SQL Server Core for Microsoft Consulting Services. In 2013 he founded the Security Virtual Chapter for the Professional Association for SQL Server (PASS) (http://security.sqlpass.org).

Argenis is a SQL community enthusiast and speaks frequently at major SQL Server conferences, including the PASS Summit, PASS SQL Rally, IT/Dev Connections, SQLBits, and Microsoft TechEd. He is also a Microsoft Certified Master on SQL Server 2008, an avid Twitter user (you can follow him at @DBArgenis), and occasional blogger on SQL Server topics at SQLBlog.com.

Register for this precon

Automate and Manage SQL Server with PowerShell

This soup-to-nuts all day workshop will first introduce you to PowerShell, after which you’ll learn the basic SMO object model, how to manipulate data with PowerShell and how to use SMO to manage objects. We’ll also cover how to manage data using the Invoke-SQLCmd cmdlet as well as ADO.NET.  We’ll then move on to creating Policy-Based Management policies, work with the Central Management Server, manage your system inventory and gather performance data with PowerShell. We’ll wrap up with a look at PowerShell Remoting and how you can use PowerShell to manage SQL Server 2012 in server environments including Windows Server Core. After this one day, you’ll be ready to go to work and able to use PowerShell to make you truly effective.

Speaker Bio:

Allen White is a Microsoft SQL Server MVP and Practice Leader at UpSearch. Allen has been working with relational database systems for over 20 years. He has architected database solutions in application areas like retail point-of-sale (POS), POS audit, loss prevention, logistics, school district information management, purchasing and asset inventory and runtime analytics. He currently serves the SQL Server community as President of the Ohio North SQL Server User Group, the Cleveland, OH based chapter of the Professional Association for SQL Server (PASS).  Contact Allen at upsearch.com. Follow Allen on Twitter: @SQLRunr

Register for this precon

Adam Belebczuk is an IT Professional with ten years of experience in support, training, and software/database development. His primary focus is on designing solutions utilizing MS SQL Server and .Net and then helping to develop, implement, performance tune, and maintain those solutions. He is also certified as an MCSE: Data Platform and MCITP DBA 2005/2008 and belongs to the Ohio North SQL Server User Group & Professional Association for SQL Server (PASS). In addition to all things technological, he also loves to make electronic music, cook, run, go skiing, read, & help educate his fellow geeks whenever the opportunity presents itself.

Facebook Twitter LinkedIn Google+ 

Introduction to SQL Server 2012 AlwaysOn Availability Groups – Q & A

Last week, I presented my session “Introduction to SQL Server 2012 AlwaysOn Availability Groups” to my largest audience ever at the PASS DBA Fundamentals Virtual Chapter. There were 191 total attendees, and I would like to take a moment to thank all of you for attending, it was truly AWESOME! Also, I would like to take a moment to apologize for the audio issues that occurred throughout the session. This was primarily my fault, as I had joined the webinar twice, once as a presenter by phone with a high-quality headset and good quality audio connection, and another time as an attendee just to keep an eye on what all of you were seeing. Unfortunately, the attendee laptop was somehow selected as the microphone to be used while I presented from my actual presenter laptop, and that is why the audio kept fading in and out and was poor quality. Mark, Mike, and I met to discuss this and how to prevent it in the future, and so this should not happen again.

Anyway, I received several questions during this session that I wanted to address via this blog post, as I think they could benefit everyone. So without further delay, here they are:

  • What would you recommend for the maximum number of (practical) databases per Availability Group?
    • This will depend on the hardware you’re running on (specifically the number of CPU threads that the primary replica can support), and the network bandwidth available between your primary and secondary replicas. Also, the amount of transactions per second occurring in each database will be a factor in this. There are no hard-and-fast rules about how many databases can be in the Availability Group. Please see http://msdn.microsoft.com/en-us/library/ff878487.aspx#RestrictionsAG for Microsoft’s recommendations in this regard.
  • How do Availability Groups work with CDC?
  • If an Availability Group is setup at the SQL Instance level, can you have multiple SQL instances per cluster node and have an Active-Active configuration?
    • First of all, an Availability Groups is not the same as a Failover Cluster Instance. An Availability Group is a group of 1 or more databases that all failover together and share a set of replicas onto which that failover may occur. Each replica is another SQL Server instance that sits on another node of the same Windows Server Failover Cluster that the primary replica does. With that said, an Availability Group can only have replicas that are nodes of the same Windows Server Failover Cluster. Therefore, active/active in an Availability Group would be more a question about which replicas are readable or not and not so much about running multiple Availability Groups. Additionally, an Availability Group is not an instance-level failover (like in a Failover Cluster Instance), so things like the master and MSDB databases, logins, etc. do not failover in an Availability Group. You can have multiple Availability Groups running at the same time, but keep in mind that they would all need to be sitting on nodes of the same Windows Server Failover Cluster, and only one instance of SQL Server per cluster node can participate in Availability Groups due to the coordination between the Availability Groups and their underlying Windows Server Failover Cluster. To clarify that a bit, you cannot install 2 SQL Server instances to the same Windows Server Failover Cluster node and have one instance host a replica for on Availability Group and the other instance host a replica for a different Availability Group. Instead, you would have a single SQL Server Instance on the Windows Server Failover Cluster node that would participate in both of the Availability Groups.
  • Is it possible to set this up with demo licenses? Is there a temp/demo/developer clustering license available from Microsoft? (for those of us on the bench who would like to test this)
    • Absolutely! Microsoft offers an evaluation version of SQL Server 2012, which can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=29066 and used to test AlwaysOn Availability Groups. In addition, if you already have SQL Server Developer Edition licenses, you can use those licenses to test AlwaysOn Availability Groups (you just can’t use them in any production capacity).
  • Can you select which databases are in the Availability Group? Can you have two different databases from two different servers?
    • Yes, you can select which databases are part of the Availability Group. However, any database that is part of the Availability Group will need to be present on the primary replica and then synchronized to all secondary replicas. Therefore, if your primary replica has 10 databases, you could select 5 of those databases to be part of the Availability Group and those would then be synchronized to the other replicas. The 5 databases not included in the Availability Group would remain untouched and only on the server that they were on originally. The same is true of the secondary replicas. They will already contain all of the databases that are part of the Availability Group, but they can also contain a number of local databases that are not part of the Availability Group.
  • Can we use SQL Server Standard edition for only two nodes? (reference: http://msdn.microsoft.com/en-us/library/cc645993.aspx)
    • No, you cannot. What the High Availability matrix is showing is running a two node Failover Cluster Instance on Standard edition. There are only two editions of SQL Server that will support Availability Groups, and those are Enterprise and Developer editions, and both edition support up to 5 replicas in an Availability Group. Remember that AlwaysOn is just a marketing term that Microsoft uses to describe several of their High Availability features, and is not a feature in itself. Don’t let their overuse of this term confuse you.
  • Should the listener be a separate server? Does the listener need to have SQL Server installed on it?
    • The listener name is just a cluster resource name, and is not a separate physical server or cluster node, nor is it a separate SQL Server instance like a Database Mirroring Witness would be. Think of the listener name as just another service that the Windows Server Failover Cluster can host on any of its nodes. The caveat here is that the Availability Group and the Cluster are talking to one another and so the Availability Group makes sure that the listener name is always hosted by the cluster node that is the primary replica of the Availability Group. Therefore it is safe to say that the primary replica (a stand-alone SQL Server Instance installed on a Windows Server Failover Cluster node) is always the host of the listener name (if you created one).

Adam Belebczuk is an IT Professional with ten years of experience in support, training, and software/database development. His primary focus is on designing solutions utilizing MS SQL Server and .Net and then helping to develop, implement, performance tune, and maintain those solutions. He is also certified as an MCSE: Data Platform and MCITP DBA 2005/2008 and belongs to the Ohio North SQL Server User Group & Professional Association for SQL Server (PASS). In addition to all things technological, he also loves to make electronic music, cook, run, go skiing, read, & help educate his fellow geeks whenever the opportunity presents itself.

Facebook Twitter LinkedIn Google+ 

Service Broker Replication – Using AlwaysOn Availability Groups with Service Broker Replication

Service Broker Replication – Table of Contents

Using AlwaysOn Availability Groups with Service Broker Replication

Well, it has certainly been a while since the last installment of this blog series, and now I’m working at a new company and doing a pretty different kind of work. However, I’ve been getting a lot of requests to complete this series, and I still have the source-code, so let’s get to it!

When we last left off on our little adventure, I described the general architecture of my Service Broker Replication system and why I made the design decisions that I did. In this blog post, I’m going to further that discussion a bit by explaining how Service Broker and AlwaysOn Availability Groups can be used together to increase the availability of the system.

Why is Availability Important to Service Broker Replication?

Well, other than the obvious answer that availability is important to EVERY system, there is one key part of the Service Broker Replication topology that is especially susceptible to a failure, and where a failure would be devastating: the distributor database. If the distributor database fails, then not only will messages fail to be sent through the environment (and therefore the replication partners would get out of sync, but we would also lose the ability to bring new replication partners online, as we wouldn’t have the message history needed to bring them up to speed. For these reasons, some kind of availability solution is critical to Service Broker Replication.

In addition to preventing data-loss, we also need to minimize the amount of time that the distributor is unavailable during an outage. This is because the longer the distributor is inaccessible, the more our replication partners will get out of sync, and the more likely we are to have conflicts occur because expected updates aren’t being replicated across the environment. With that said, we could just implement something like Database Mirroring, Log Shipping, or a Failover Cluster Instance, and all of those are certainly viable options. However, what would happen if there were a loss of connectivity at the data-center housing our distributor database? What if that outage lasted for a couple minutes? How about a couple hours? A couple days? A couple weeks? I think you get the idea. If we implement one of the availability solutions I mentioned above, we don’t really have an answer to those questions (yes, Log Shipping and geo-clustering can potentially solve the issue, but they each have caveats I’d like to avoid, like data-loss due to backup timing and prohibitively expensive and complex SAN hardware).

The Solution

Enter SQL Server 2012 Enterprise Edition and AlwaysOn Availability Groups. Chances are, if you’re at an organization that needs a solution like Service Broker Replication, then you’re probably already running Enterprise Edition. If not, you may want to consider increasing my licensing budget a bit, because Enterprise Edition has some pretty amazing features! One of those amazing features is AlwaysOn Availability Groups, which take the best features of Database Mirroring and Failover Cluster Instances and combine them together. For more information on AlwaysOn Availability Groups and why they solve a lot of availability problems, check out my AlwaysOn Availability Groups page.

The reason why AlwaysOn Availability Groups are a big win for Service Broker Replication is that unlike Failover Cluster Instances, Availability Groups don’t require any cluster shared storage objects. Therefore, geo-clustering with AlwaysOn Availability Groups gets MUCH easier (and cheaper) than it is in a Failover Cluster Instance. So, if you have an Availability Group that spans two data-centers, and the first data-center’s Internet connection fails, your Availability Group will automatically failover to the node in the working data-center, and your Service Broker Replication topology will remain up and running, with no data-loss (actually, there is a possibility for data-loss if you’re running in asynchronous commit mode, but it’s usually pretty minimal).

Another beautiful thing about this combination is that even if messages do fail to send to the distributor or from the distributor to a replication partner during the failover process, those messages will remain en-queued by Service Broker and will be resent once connectivity is restored, which is usually within a minute or two. Therefore, as long as we don’t have any data-loss at the distributor database, our replication partners will synchronize as though no failure even happened.

In addition to making the distributor database a member of an Availability Group, you can also reap the benefits of Availability Groups at each of your replication partners, and keep your local databases and applications up and running in the event of patching, hardware failures, and losses of connectivity. However, I would consider running Availability Groups at the replication partners a lower priority than running an Availability Group at the distributor, so if cash is short, at least make sure your distributor is protected.

Coming Up

Stay tuned! This series gets a lot more juicy in the next installment, as I dive into the different message types that Service Broker Replication sends and how they each work. This is where we make the leap from theoretical to practical, so you won’t want to miss it!

Service Broker Replication – Table of Contents

Adam Belebczuk is an IT Professional with ten years of experience in support, training, and software/database development. His primary focus is on designing solutions utilizing MS SQL Server and .Net and then helping to develop, implement, performance tune, and maintain those solutions. He is also certified as an MCSE: Data Platform and MCITP DBA 2005/2008 and belongs to the Ohio North SQL Server User Group & Professional Association for SQL Server (PASS). In addition to all things technological, he also loves to make electronic music, cook, run, go skiing, read, & help educate his fellow geeks whenever the opportunity presents itself.

Facebook Twitter LinkedIn Google+ 

Slacking Off…or…Adjusting To Change

If you’re reading this, then I owe you some credit as a committed follower of my blog. :-) In addition to some credit, I also owe you an apology. As you may or may not know, I started a new job back in November, and since that time I’ve been slacking off on my blog posts and speaking engagements. For that, I am truly sorry. However, I do have some good news: Now that I’ve had over 4 months to adjust to these changes, I’ve finally decided to get off of my lazy butt and start blogging and presenting again!

With that said, here are my plans (for better or for worse):

  • Begin blogging again
    • I’d like to set my cadence at one blog post every other week or so, until I see how that works out, and then I’ll adjust it.
    • I’d like to complete my Service Broker Replication series (because I should, and also because I’ve been asked to by a couple of readers).
    • In my new position, I am doing quite a bit of documentation and written communication, and blogging can only help me improve in those areas.
  • Start speaking again
    • I have to say, I’ve missed the limelight. ;-) But more importantly, I’ve missed being able to help other SQL Server Professionals, and I miss my SQL Family as well.
    • I’d like to start developing new sessions again. I have a couple of ideas for topics that I’d like to learn more about, and I think they would make great presentations as well (I’ll probably be blogging about them too).
    • I’ve gained so much from being a member of PASS, that I need to keep giving back to the community in return. After all, that’s how this sort of community works. :-)

So in conclusion, I’m back, I’m recharged, I’m excited, and I think you’ll be reading, hearing, and seeing a whole lot more of me as we head into summer. It’s going to be a great year!

Adam Belebczuk is an IT Professional with ten years of experience in support, training, and software/database development. His primary focus is on designing solutions utilizing MS SQL Server and .Net and then helping to develop, implement, performance tune, and maintain those solutions. He is also certified as an MCSE: Data Platform and MCITP DBA 2005/2008 and belongs to the Ohio North SQL Server User Group & Professional Association for SQL Server (PASS). In addition to all things technological, he also loves to make electronic music, cook, run, go skiing, read, & help educate his fellow geeks whenever the opportunity presents itself.

Facebook Twitter LinkedIn Google+ 

Creating a Login with a SID

For those of you who don’t already know, there is a new PASS Virtual Chapter called DBA Fundamentals that has meetings on the first Tuesday of every month. The chapter specializes in providing training and support for new DBAs and also for seasoned DBAs who would just like to brush-up on their skills. I was fortunate enough to be asked to present at their second meeting on 9/4, and I gave my session about SQL Server Service Broker. One of the questions that I was asked during the session was: How do you create a login with a SID, and more specifically, how do you create and find the SID for that login?

In my session on Service Broker and also in my session on AlwaysOn Availability Groups, I mention that if you’re using AlwaysOn Availability Groups or Database Mirroring that you should create your logins with the same SID on each instance/replica so that when a failover occurs, you don’t have to re-map your database users to their appropriate logins. However, I don’t really go into the detail of how to do that in my sessions, so I wanted to take some time to do that here.

use master;

-- Get a new GUID value to use as the SID
declare @SID uniqueidentifier = newid();

-- In order to use the SID in a create login statement, it must be in binary format
declare @SID_Binary varbinary(max) = (select cast(@SID as varbinary(max)));

-- View the SID in GUID and Binary format:
select @SID, @SID_Binary;
-- E72669E3-9FAA-4BCB-8F8F-570EBF114674, 0xE36926E7AA9FCB4B8F8F570EBF114674

-- Here is the statement we really want to run:
--create login SQLDiablo with password='Passw0rd!', sid=0xE36926E7AA9FCB4B8F8F570EBF114674;

-- But that requires us to paste in the SID. There has to be a better way:
declare @UserName nvarchar(128) = 'SQLDiablo', @Password nvarchar(max) = 'Passw0rd!';
declare @Query nvarchar(max) = 'create login ' + @UserName + ' with password=''' + @Password + ''', sid=0x' + cast('' as xml).value('xs:hexBinary(sql:variable("@SID_Binary") )', 'varchar(max)') + ';';

select @Query;
execute sp_executesql @Query;

-- Since varbinary can be a little tricky to work with in dynamic SQL, XPath is our friend.
-- Above we converted the value of @SID_Binary to Hex using XPath's value method (don't forget to add 0x to the beginning of it).

-- Get the SID for the login we just created, as a GUID
select sp.name, cast(sp.sid as uniqueidentifier) SID_AS_GUID from sys.server_principals sp where sp.name = 'SQLDiablo';

-- SQLDiablo, E72669E3-9FAA-4BCB-8F8F-570EBF114674

set @Query = 'drop login ' + @UserName + ';';
execute sp_executesql @Query;

Adam Belebczuk is an IT Professional with ten years of experience in support, training, and software/database development. His primary focus is on designing solutions utilizing MS SQL Server and .Net and then helping to develop, implement, performance tune, and maintain those solutions. He is also certified as an MCSE: Data Platform and MCITP DBA 2005/2008 and belongs to the Ohio North SQL Server User Group & Professional Association for SQL Server (PASS). In addition to all things technological, he also loves to make electronic music, cook, run, go skiing, read, & help educate his fellow geeks whenever the opportunity presents itself.

Facebook Twitter LinkedIn Google+ 

SQL Saturday #164 – Cleveland: Lessons Learned

Well, SQL Saturday #164 – Cleveland 2012 is in the history books, and it looks like all of our planning, blood, sweat, and tears have paid off. This was my first time helping organize a SQL Saturday, and I’ve got to say it was quite an experience! As part of the core planning team and as the lead for the restaurant and catering team, my last several months have been filled with tons of planning meetings, e-mails, phone calls, and lots and lots of little details to manage. It’s amazing how much work goes into an event like this, and it’s even more amazing to see a great team come together and pull it off. Before I continue with my lessons learned, I just wanted to take a moment to thank the awesome people who really helped make this event a success:

  • Craig Purnell & Allen White – Thanks for being such awesome leaders and mentors throughout the planning process, I really appreciated your council and direction
  • The Devry staff – THANK YOU, THANK YOU, THANK YOU for donating your facility for the day, for helping me remember to take breaks every now and then, for helping keep me sane, and for all of your help throughout the day (you guys were truly AWESOME!!!)
  • The Mavis Winkle’s staff – Despite rushed deadlines, miscommunications, double-bookings, an overly stressed team lead (yours truly), and lots of calls back and forth, you guys still pulled off two awesome meals for us and helped make for a great event. I would especially like to thank the owners, Bob and Marie, for helping to make my life a little less stressful on Friday and Saturday. It was really cool getting to work with you and your staff.
  • All of our sponsors – We couldn’t do an event like this without your support, and for that we are EXTREMELY grateful. THANK YOU!
  • Steven Wright and SQL Sentry – Thanks for sponsoring our Speaker/Sponsor/Volunteer dinner, YOU ROCK!
  • Ann Marie Kozlowski – Thanks for letting us use the Solutient offices for bag stuffing, and thanks for taking care of the breakfast arrangements
  • Carlton Ramsey & Cory Stevenson (and his wife) – Thanks for buying cookies, pop, and all of the other little odds-and-ends that we needed for the event
  • Sam Nasr – Thank you for taking care of the after party arrangements
  • Colleen Morrow, Erin Stellato, and anyone else who helped out – THANK YOU SO MUCH!

From the speaker’s dinner on Friday night until I left Devry sometime around 6 PM on Saturday, I was pretty much a blur of activity as I tried to help make sure everything ran smoothly. Despite all of that running around, I was still able to attend two awesome sessions, present my own session, mingle, network, and have a ton of fun! I think the key to my success was that I had an absolutely awesome team that I could rely on to really get things done.

One of the things to keep in mind about an event like this is that it is inevitable that there will be lots of little problems and issues that come up throughout the day. The key to handling these issues is to keep calm, ask for help when you need it, and to trust your team to do their job. It’s not necessary to manage every little detail of an event like this. It’s simply too much to handle for one person. Instead, break the responsibilities up into smaller tasks, assign those tasks to people or teams to accomplish, and then give them the room to do their job.

As far as the food was concerned, there are a couple things to consider when planning an event like this:

  • If you have the space to allow everyone to dine in the same area, then you have a lot more flexibility as to what kinds of food you can serve, and you can even have a fully catered buffet (much like the awesome buffet at SQL Saturday in Chicago earlier this year).
  • If you don’t have a large common area, then you will need to distribute the food and have the attendees go into the session rooms to eat it. If this is the case, you’re going to want to go with highly portable food such as boxed lunches.
  • Don’t forget to get lots of heavy-duty construction garbage bags and to distribute them throughout the venue to handle the trash that will be generated. It would also be a good idea to have a team that checks the garbage cans and bags throughout the day and empties them as needed.
  • An afternoon snack is a good idea, but don’t over do it. We bought 2 cookies for every attendee as an afternoon snack, and we had about half of them left over after the event.
  • You’re going to have food left over after an event like this. It might be a good idea to get in touch with your local foodbank, homeless shelter, or area churches before the event and see if they can use the leftover food. They’ll thank you for it, and it’s one more way you can give back to the community.

As far as the venue goes, here are my thoughts:

  • Keep the logistics of an event like this in mind when choosing a venue. Make sure the hallways are wide enough, the doors won’t automatically lock you out throughout the day (yep, this actually happened to us), and that there is enough space for the number of attendees you’re aiming for. Sometimes cheaper (free) isn’t always better.
  • Regardless of whether you get the venue for free or at full price, make sure to clean up after your event and to try to help the venue’s staff in any way you can. After all, you’re representing PASS as a whole, and you might even want to have another SQL Saturday there next year.
  • If you’re having the event at a college or school, why not do a track of sessions that students from the school can attend? It’s a way of saying thank you for the use of the venue and it’s also a way to give back to the community. SQL Saturday in Cleveland was able to use the Devry campus here for free as a direct result of SQL Saturday in Chicago doing exactly what I mentioned. The Cleveland team also did a track of intro sessions for the Devry students, and the track was very well received.

Other than that, my only advice is to HAVE FUN! Events like this aren’t worth the effort if they’re not only educational, but fun and social as well. You’re going to have to work hard to get the job done, but that doesn’t mean you can’t play hard too.

Adam Belebczuk is an IT Professional with ten years of experience in support, training, and software/database development. His primary focus is on designing solutions utilizing MS SQL Server and .Net and then helping to develop, implement, performance tune, and maintain those solutions. He is also certified as an MCSE: Data Platform and MCITP DBA 2005/2008 and belongs to the Ohio North SQL Server User Group & Professional Association for SQL Server (PASS). In addition to all things technological, he also loves to make electronic music, cook, run, go skiing, read, & help educate his fellow geeks whenever the opportunity presents itself.

Facebook Twitter LinkedIn Google+ 

AlwaysOn Availability Groups, Isolation Levels, & Selects Blocking the Redo Thread

This past weekend, I had the pleasure of presenting my session SQL Server 2012 AlwaysOn Readable Secondaries at SQL Saturday #126 in Indianapolis, IN. In that session, I covered the basics of AlwaysOn Availability Groups, how to set them up, failing over, and using readable secondary replicas for read-only workloads and backups. During the session, I always make sure to mention the possibility of queries running on the secondary replica blocking the redo thread that is trying to write changes from the primary database to the secondary database.

After mentioning this caveat, I was asked a very good question: Can you use transaction isolation levels (such as snapshot isolation) with AlwaysOn Availability Groups, and would they help to avoid the issue of read-only queries on secondary replicas blocking the redo thread? In order to answer this question, I’m going to break it two parts, and then we’ll work through a couple demos to illustrate the answers.

Questions:

Q: Can you use transaction isolation levels with AlwaysOn Availability Groups?
A:
Yes and no. Yes, you can set whatever isolation level you would like when running queries on the secondary replicas, and SQL Server will not return an error. However, SQL Server will automatically override the isolation level (and ignore all lock hints) when querying a read-only replica, and instead force the queries to use snapshot isolation.

Per the “Benefits” topic of the Active Secondaries: Readable Secondary Replicas (AlwaysOn Availability Groups) BOL article:

Read-only workloads use row versioning to remove blocking contention on the secondary databases. All queries that run against the secondary databases are automatically mapped to snapshot isolation transaction level, even when other transaction isolation levels are explicitly set. Also, all locking hints are ignored. This eliminates reader/writer contention.

Q: Does using snapshot isolation prevent read-only queries from blocking the redo thread on secondary replicas?
A: After reading the above quote from BOL, you would think that read-only queries won’t block the redo thread, and that is true for DML statements. However, it is not true for DDL statements. Sure, snapshot isolation prevents read-only queries on the secondary replicas from taking locks and preventing other DML statements against the database from executing, but it doesn’t prevent the read-only queries from taking schema stability locks and blocking DDL statements.

If you take a look later on in the same article I quoted above, you will come to the “Read-Only Workload Impact” section under the “Performance Considerations” topic:

Also, read-only workloads on the secondary replicas can block data definition language (DDL) changes that are applied through log records. Even though the read operations do not take shared locks because of row versioning, these operations take schema stability (Sch-S) locks, which can block redo operations that are applying DDL changes.

Demos:

In order to have a reference architecture to use for this demo, I’m going to use the Availability Group that I setup as part of the presentation that I mentioned at the beginning of this article. If you would like to play along at home, you can download the scripts and slide deck for that session here. This Availability Group is called DemoAG, and has three replicas, AlwaysOn1 (primary), AlwaysOn2 (secondary), and AlwaysOn3 (secondary). There are two databases participating in the Availability Group: AdventureWorks2012 and AdventureWorksDW2012. I’m going to be using AdventureWorks2012 for this demo.

Testing isolation levels and lock hints:

Unfortunately, I haven’t come up with a good way to demonstrate that SQL is overriding the transaction isolation level on the readable secondary because it is actually doing this internally (I’ll keep looking into this to see if there is a good way to demonstrate it). I can, however, demonstrate that SQL Server is ignoring lock hints on the read-only replicas. I can do this by beginning a transaction, executing a select query with the tablockx lock hint, and leaving the transaction open. I then open a new query window and query sys.dm_tran_locks to see if there is a table lock on the table. If I do this on the primary, you will see an open table lock on the table. If I do this on the secondary, there is no open table lock. If I then try to update data on the primary replica, I am able to see the statement completes and that the data has been written to the replica, even with the open transaction on the secondary that should be holding a table lock.

-- Execute this in a session of its own on the primary replica:
begin tran;

select * from ErrorLog with (tablockx);

-- With the above transaction open, launch a new query window on
-- the primary replica, and execute this query
-- (you should notice a table lock on the ErrorLog table):
use master;

select
t.name
, dtr.*
from sys.dm_tran_locks dtr
join sys.databases d
on d.name = 'AdventureWorks2012'
and d.database_id = dtr.resource_database_id
join AdventureWorks2012.sys.tables t
on t.object_id = dtr.resource_associated_entity_id;

-- Now try running this insert in the same query window as the sys.dm_tran_locks query
-- (you should get blocked until you commit or rollback the transaction in the other session):
insert AdventureWorks2012.dbo.ErrorLog(UserName, ErrorNumber, ErrorMessage)
values('DemoUser', 1, 'Demo Message');

-- Go ahead and close both query windows, and connect to one of the secondary replicas.
-- Now, try running through the scenario above on the secondary replica (minus the insert).
-- You should notice that there is no table lock being held, even though we explicitly requested one.

Testing read-only queries blocking DDL statements:

As far as demonstrating that read-only queries can block DDL statements, all we need to do is run a long-running query on the secondary replica and simultaneously try to alter the table that the query on the secondary is using. We should notice that the redo queue size on the secondary then increases and stays that way until we either kill or complete the read-only query. This indicates that the redo thread is not able to commit the DDL changes because the select statement is taking a schema stability lock and preventing the alteration to the table.

-- Run this query on the secondary replica
-- (it's horribly ugly and inefficient, but the idea is to hold a
-- schema stability lock on ErrorLog for as long as we can):

select
NumbersTable.Number
from AdventureWorks2012.dbo.ErrorLog el
cross apply (
select
Number
from
(
select
row_number() over (order by s1.name) as number
from AdventureWorks2012.sys.sysobjects s1
cross apply AdventureWorks2012.sys.sysobjects s2
cross apply AdventureWorks2012.sys.sysobjects s3
cross apply AdventureWorks2012.sys.sysobjects s4
cross apply AdventureWorks2012.sys.sysobjects s5
) as InnerNumbersTable
) NumbersTable
group by NumbersTable.Number
order by NumbersTable.Number desc;

-- While that beast is running on the secondary replica, run the
-- following on the primary replica:

alter table AdventureWorks2012.dbo.ErrorLog add DemoColumn varchar(10) null;

-- Now go back to the secondary replica, open a new query window, and run the
-- query below (you should notice that the redo queue is greater than 0,
-- which indicates that the redo thread is having trouble applying changes
-- to the database):
select
dhdrs.redo_queue_size
from master.sys.dm_hadr_database_replica_states dhdrs
join master.sys.databases d
on d.database_id = dhdrs.database_id
and d.name = 'AdventureWorks2012';

Adam Belebczuk is an IT Professional with ten years of experience in support, training, and software/database development. His primary focus is on designing solutions utilizing MS SQL Server and .Net and then helping to develop, implement, performance tune, and maintain those solutions. He is also certified as an MCSE: Data Platform and MCITP DBA 2005/2008 and belongs to the Ohio North SQL Server User Group & Professional Association for SQL Server (PASS). In addition to all things technological, he also loves to make electronic music, cook, run, go skiing, read, & help educate his fellow geeks whenever the opportunity presents itself.

Facebook Twitter LinkedIn Google+