The second one is about networking best practices for SQL Server high availability and disaster recovery. The premise of the webcast is that SQL Server DBAs are now dependent on the things that they have no control over. Knowing what SQL Server depends on for high availability and disaster recovery enabled SBAs to be better prepared to communicate with the other teams to meet their overall objectives. You can check out the recording from the MSSQLTips.com website.

I bet a lot of IT professionals who are really serious about their work are like me. When they see an error or warning message like this, their first instinct is to find out what the problem is and fix it. That’s what I did when I saw this error while configuring a SQL Server 2012 Always On Availability Group. I searched  blog posts, forum posts, mailing lists, KB articles, and everything I can think of. I’ve seen this error message before and I know exactly what to do. I’ve done this many times. Except this time, I didn’t do what I knew I needed to do.

Understanding the underlying architecture design is key to addressing warning and/or error messages like this. Microsoft KB article 2833122 outlines the different causes of this warning message when you are working with SQL Server 2012 Always On Availability Groups. I knew causes #1 and #2 do not apply to me because I’m already running on Windows Server 2012 with SQL Server 2012 with Service Pack 1. In the past, I had to install the required hotfix for Windows Server 2008/R2 to get this to work. But check this out. If you look closely at causes #3 and #4, and you understand the underlying architecture design, you might miss out the last phrase (emphasis mine.)

…you can safely ignore the warning message.

That’s it. No panicking, no pressing of the emergency button, no dialing 911.  Again, the key thing here is “understanding the architecture design.” In my case, it is a SQL Server failover clustered instance configured with an Always On Availability Group whose standby replica is on a different network subnet. I had to explicitly configure the node weight of the secondary replica to zero (0) because it is on a different network subnet. I do not want that node to affect the SQL Server failover clustered instance that is running in my primary data center. Ironically, I was the one who designed the architecture but was the very first one who panicked.

So, the next time you see an error message like this, ask yourself these questions:

1. Do I know what caused it?
2. Do I understand the underlying architecture design?
3. Do I need to resolve it?
4. Did I have enough sleep last night?

Feeling helpless and confused when dealing with Windows Server Failover Clustering  (WSFC) for your SQL Server databases?

You’re not alone. I’ve heard the same thing from thousands of SQL Server administrators throughout my entire career. These are just a few of them.

“How do I properly size the server, storage, network and all the AD settings which we do not have any control over?”

“I don’t quite understand how the Windows portion of the cluster operates and interacts with what SQL controls.”

“I’m unfamiliar with multi-site clustering.”

“Our servers are setup and configured by our parent company, so we don’t really get much experience with setting up Failover Clusters.“

If you feel the same way, then, this course is for you. It’s a simple and easy-to-understand way for you to learn and master how Windows Server Failover Clusters can keep your SQL Server databases highly available. Be confident in designing, building and managing SQL Server databases running on Windows Server Failover Clusters.

But don’t take my word for it. Here’s what my students have to say about the course.

“The techniques presented were very valuable, and used them the following week when I was paged on an issue.”

“Thanks again for giving me confidence and teaching all this stuff about failover clusters.”

“I’m so gladdddddd that I took this course!!”

“Now I got better knowledge to setup the Windows FC ENVIRONMENT (DC) for SQL Server FCI and AlwaysON.”

Thanks to the guys at CanITPro.net, my article has gone live. Check out the article on Step-By-Step: Creating a SQL Server 2012 AlwaysOn Availability Group.

Don’t put your databases at risk when deploying SQL Server Always On Availability Groups

Did you know that SQL Server Always On Availability Groups depend so much on Windows Server Failover Clustering (WSFC)?  The availability of the SQL Server databases relies heavily on the WSFC. And if you don’t know these other external dependencies, you are putting your mission-critical SQL Server databases at risk. Don’t be caught off guard. I’ve lost count of the number of times that I have had to bring a SQL Server Always On Availability Group online in an emergency just to explain that it was the WSFC that caused the outage.

I’ve been thinking about those heart-pounding moments when I needed to resolve an outage in the middle of the night involving SQL Server Always On Availability Groups. It doesn’t have to be painful and extremely complex.

If you need help with SQL Server Always On Availability Groups, let’s talk. Schedule a call with me.

One of the things I mentioned in the presentation is the need for a dedicated SQL Server instance just for the SharePoint farm. There are two main reasons why that is the case. First, SharePoint requires a specific collation for the content databases. Microsoft KB 2008668 mentions the collation required for the content databases and the recommended one for the instance (while the KB article mentions SharePoint 2007, it still applies to SharePoint 2010 and 2013.) If your databases require a collation other than those, the collation difference will cause a lot of issues. Hence, the recommendation for a dedicated SQL Server instance.

Another reason for having a dedicated SQL Server instance for the SharePoint farm is the instance-wide maximum degree of paralellism configuration. This is clearly documented in this Microsoft TechNet article. Now, if you’re a SQL Server DBA, you might be laughing at this because it is not a best practice that we apply to our SQL Server instances. We usually analyze the workload and decide whether to keep the default setting of zero or tweak it to a number that would address the workload. However, SharePoint requires a maximum degree of parallelism of 1. Yes, that wasn’t a typo. This is one of the settings that I check whenever performing a best practices configuration check for a SQL Server instance running SharePoint databases. In the past, SharePoint will just install and create content databases even when the instance-wide maximum degree of parallelism value is not equal to 1. With SharePoint 2013, this is no longer the case. In fact, in the earlier builds of SharePoint 2013, the installation media will inform you that the maximum degree of parallelism is not set to 1 and will halt the installation with the error message below.

New-SPConfigurationDatabase : This SQL Server instance does not have the required “max degree of parallelism” setting of 1. Database provisioning operations will continue to fail if “max degree of parallelism” is not set 1 or the current account does not have permissions to change the setting. See documentation for details on manually changing the setting

As I was preparing a new SharePoint 2013 farm for my test environment, I decided to play around with it. I intentionally switched my SQL Server instance’s maximum degree of parallelism from 1 to 0 just so I could hit the error. For the installation, I used the SharePoint 2013 build 15.0.4420.1017 released back in 24-Oct-2012. For starters, I used the SharePoint configuration wizard to create the farm and made sure that my maximum degree of parallelism configuration is set to 0. To my surprise, the installation went well. I decided to check the maximum degree of parallelism configuration after the installation and was shocked to see that it was changed to a value of 1. Not satisfied with what I found out, I recreated the SharePoint 2013 farm and decided to run SQL Profiler to capture the SQL statements being sent to the SQL Server instance while the SharePoint farm is initially created. This is what I found.

--DELETE_SQL_AZURE_START
IF (SELECT value FROM sys.configurations WHERE name = 'max degree of parallelism') <> 1
BEGIN
 exec sp_configure 'show advanced options', 1;
 RECONFIGURE WITH OVERRIDE;
 exec sp_configure 'max degree of parallelism', 1;
 RECONFIGURE WITH OVERRIDE;
END
--DELETE_SQL_AZURE_END
IF EXISTS (SELECT TOP 1 1 FROM sys.types WHERE name='tSystemID')
 DROP TYPE [dbo].[tSystemID]

Part of the SharePoint 2013 farm build process is to check whether or not the max degree of parallelism configuration value is equal to 1. This is a good thing. This means that if this configuration setting was ignored during the installation of your SQL Server instance, SharePoint 2013 will reconfigure it for you. But I didn’t stop there. I decided to switch it back from 1 to 0 before creating a new site collection. The site collection will create a corresponding content database, if one doesn’t already exist. I fired up SQL Profiler again to capture the SQL statements getting executed against the SQL Server instance. The same statements are being executed prior to creating the content database for the site collection. So, even if somebody accidentally changed the configuration setting from 1 to something else, SharePoint will automatically change it to 1 whenever a new content database is created.

While this is a good change in SharePoint 2013, I strongly recommend regularly checking your SQL Server instances for configuration changes that do not follow best practices, particularly those that are well documented. Even better is configuring your monitoring tool to notify you when this configuration setting is changed. A proactive approach to managing SQL Server instances will make sure that you minimize issues that you might come across with, whether they be performance-, reliability-, or security-related.