In a previous blog post, I covered how you can provide high availability for SQL Server Reporting Services workloads. One of those options is thru SharePoint’s scale-out implementation.

While this topic is primarily for integrating SQL Server Reporting Services with SharePoint 2013, it helps us SQL Server professionals understand the difference in the architecture between native mode and SharePoint-integrated mode and make decisions based on those. In this particular case, when you deploy SQL Server Reporting Services in a SharePoint farm, we need to be aware of a couple of things:

• security and authentication
• high availability and scale out load balancing
• proper deployment

If someone else on the team is responsible for managing your SharePoint farm, you can use these talking points to have a conversation about the implementation. A very common challenge that I see when there are separate teams managing SharePoint and SQL Server is that there is no proper coordination between the teams (I guess this happens in just about any teams, not just in IT.) I’ve seen cases where SQL Server Reporting Services was installed in SharePoint-integrated mode in a server that has not been joined to the SharePoint farm yet. And that usually turns out to be an administration nightmare down the road. It’s why I recommend having that conversation first before you even do any installation.

This video explains the service architecture model when SQL Server Reporting Services is deployed in SharePoint-integrated mode. And if you need help in designing and deploying SharePoint 2013 (and higher) as a business intelligence (BI) farm, drop me a line. I’ll be happy to lend a hand.

Additional Resources

• SQL Server Reporting Services 2012 SharePoint integrated mode Endpoints architecture (or how our services talk each other)
• Providing High Availability to SQL Server Reporting Services
• Install and Configure SQL Server Reporting Services 2012 SP1 and 2014 in SharePoint Integrated Mode
• Installing and Configuring Reporting Services 2012 SP1 or 2014 in SharePoint-Integrated Mode Part 2

• Delayed Durability in SQL Server 2014 by SQL Server MVP/Regional Director and SQLSkills CEO Paul Randal (blog | Twitter)
• Delayed Durability in SQL Server 2014 by SQL Server MVP Aaron Bertrand (blog | Twitter)
• Delayed Durability in SQL Server 2014 – Part 1 – Introduction by Simon Harvey (blog)

As a SQL Server DBA, this is one feature that you should consider implementing in your environment – with the proper testing, of course – if you have a transaction log bottleneck. What this means is that your top waits include WRITELOG, some PAGEIOLATCH_* and potentially LOGBUFFER waits. Check to see if your system has a transaction log bottleneck by taking a look at the top waits.

The one caveat that you need to consider with the delayed durability feature in SQL Server 2014 is this: you want to trade transactional durability for log performance.

Now, as a SQL Server high availability and disaster recovery guy, I’m all for transactional durability. It’s what we’re all accustomed to and it’s a guarantee that transactions are durable when committed. In a highly transactional, mission-critical system, every transaction counts and making them durable is a way to meet recovery objectives in terms of data loss. But why do I think your application would benefit from it?

Understanding the workload profile of your database can help you decide if you can take advantage of delayed durability.  Also, a lot of the SQL Server deployments that I see in the field are now on virtualized environments, utilizing storage area networks (SAN) and even iSCSI. This means that the virtual machines will share a common storage platform which impacts I/O throughput not just for your databases but for all workloads running on the SAN. This means that your databases will potentially experience I/O latencies – be it the data file or the transaction log file.  While we can apply all of the storage best practices configuration settings to optimize database I/O performance, there’s only so much we can do with the limited amount of resources that we have. Implementing delayed durability would definitely help improve transaction log performance.

But what about potential data loss? Your transactions are not durable when committed. Scary, isn’t it?

This is one of the main reasons why I emphasize the importance of recovery objectives (RPO/RTO) and service level agreements (SLAs.) You cannot treat a mission-critical application that cannot afford data loss the same as a line-of-business application that only needs to be online 16 hours every day. It’s the same reason why it’s OK to use SIMPLE recovery model with some of your databases. If you understand your workload profile and your recovery objectives, you can categorize your databases according to criticality. And if your not-so-mission-critical databases are experiencing transaction log bottleneck, every bit of performance optimization helps, including delayed durability.

If I were to decide, I would immediately turn this feature on for Tier 1 and Tier 2 SQL Server 2014 database servers and measure the performance impact. Anything beyond Tier 2, I would carefully evaluate the potential data loss and discuss it with business stakeholders.

Are you in the process of upgrading to SQL Server 2014? This is a great opportunity to test if your workloads can take advantage of this feature.

I recently got a question about how to reclaim database space in SharePoint. The specific database mentioned was WSS_Logging although this could have been any of the SharePoint databases or any other SQL Server database for that matter. The database was growing really fast so the farm was configured to only keep a week’s worth of data. But because the database did not get any smaller, they decided to shrink it to reclaim space. To which I responded, “Are you running out of free space on your disk?”

Why I’m Against Regular Database Shrinking

I still see this on a regular basis – a database maintenance plan that takes daily backups and shrinks the database after an index maintenance task. The reasoning behind it is that the administrator simply wants to reclaim disk space every day.  Very good intentions without understanding the effects of the action. That’s why I take my time to explain why it is a bad idea to regularly shrink databases.

In a previous blog post, I talked about how databases are like boxes being filled with content every day. As the box gets filled, the amount of free space decreases. But if you know that you will need to fill it up with more content, wouldn’t you go get a bigger box? Sadly, that’s not what we’re doing when we’re shrinking databases. We’re basically throwing away the box with free space to replace it with a smaller box with just enough space to keep all of the existing content. Imagine what you would do to accomplish this task – empty the box of its contents, throw away the box, replace it with a smaller box and put the contents back in. Wow, that’s a lot of work just to replace the box with a smaller one only to see someone else replace it back with a bigger one tomorrow (that someone else is SQL Server running autogrowth to accommodate new data being stored in the database.) But that’s similar to what’s happening to your databases every time you shrink them – you’re basically wasting resources every time you’re doing so.

But more than wasting resources just to reclaim free space is the performance impact this process has on the database. One of my favourite demos to show is how fragmentation in the database immediately happens as a side effect of shrinking. If you don’t believe me, watch this video recording before proceeding any further.

Shrinking a database increases fragmentation which causes performance problems.

Let’s move on. Imagine a database maintenance plan that has an index maintenance task immediately followed by a shrink database task. Ugh! You’ve just fragmented the indexes that have been defragmented on your database.

Let me get something straight. I’m not against shrinking databases especially in an emergency situation where you run the risk of causing downtime because of a disk space issue. Besides, there are other ways to resolve a disk space issue like adding a new file and moving data into it. I just don’t like shrinking the databases on a regular basis. So, do yourself a favor and check if your database maintenance plans have the Shrink Database Task included anywhere. If you can’t, ask your database administrator to make sure you don’t have it. Remove it if you find any. Ignore anything that any SharePoint expert tells you otherwise, even when the response comes from the TechNet/MSDN forum and marked as Answered. Your SharePoint users will thank you for it.

Dealing With Database Space Issues The Right Way

The proper way to deal with database space issues is to do capacity planning and monitoring. You need to understand what your space requirements will be within the next two years or more and plan accordingly. This should give you enough information to ask for budget allocation for that new storage infrastructure.

Now, you might ask, “my database server has been running for almost a year now and we didn’t capture usage statistics to determine disk capacity. What do we do?”

To which I would respond by asking, “Do you have database backups?” Well, I sure hope you do. In the next blog post, I’ll show you how you can use your database backups for more than just disaster recovery.

Additional Resources

• Why you should not shrink your data files
• SQL SERVER – Shrinking Database is Bad – Increases Fragmentation – Reduces Performance
• Oh, the horror! Please stop telling people they should shrink their log files!

This is a question that I regularly ask those attending my high availability and disaster recovery presentations: is your SQL Server Always On Availability Group really highly available?

Now, don’t get me wrong. I love the Always On Availability Groups feature in SQL Server (except for the price tag of an Enterprise Edition license.) But there’s a back story why I ask this question. Back in 2013, one of my customers asked me to build an Always On Availability Group infrastructure for their SharePoint 2013 farm. Back then, there was a lot of talk and promotion in the SharePoint community about using the new *cough* Always On *cough* feature in SQL Server 2012. Almost everyone I met at conferences who were planning on upgrading their SharePoint 2010 farms to SharePoint 2013 were looking at implementing Always On Availability Groups.

Fast forward to go-live and a happy customer. Their farm is running on SharePoint 2013 with SQL Server 2012 Always On Availability Groups on a 2-node Windows Server 2012 cluster. They used a file share witness for the extra vote on their cluster since they were only using standalone instances for the Always On Availability Group replicas. The file share witness went offline for whatever reason. But since the cluster nodes are still available, the Always On Availability Group remains online together with the SharePoint databases in it. Until somebody rebooted the secondary replica due to installation of security patches. That caused the SharePoint farm to go offline because the Always On Availability Group went offline. One of my colleagues back then was telling me that we are getting blamed for what happened to their SharePoint farm. I told them, “that behavior is by design.”

It’s easy to fall into the belief that something works until it doesn’t. And, then we blame someone – either the vendor or the one who implemented the solution – when it doesn’t. That’s why we need to understand the underlying infrastructure and it’s behavior.

Since SQL Server Always On Availability Groups (AGs) (as well as failover clustered instances (FCIs)) depend so much on the underlying Windows Server Failover Cluster (WSFC) for health detection, automatic failover, etc., we need to understand how WSFC works and how it actually keeps the applications running on top of it online.

Why Quorum Matters

As per this TechNet article, the quorum for a cluster is determined by the number of voting elements that must be part of active cluster membership for that cluster to start properly or continue running. This means that the number of voting members in a WSFC determine whether or not the cluster stays online together with the applications running on top of it. You’ll commonly see a 2-node WSFC – both for AG and FCI – because of simplicity and ease of management. A disk witness (commonly known in the past as a disk quorum) is typically used for an FCI while a file share witness for AGs with standalone instances as replicas.

Every node in the cluster, by default, will have a vote. In order to keep the cluster up and running, the total number of votes have to reach a majority. The calculation for majority of votes is as follows.

I mentioned voting members because there are a dozen or more combinations of configuration that you can implement where the voting members may or may not have a vote, depending on your requirement. This could mean having a node that does not have a vote if you’re on earlier versions of Windows Server. But, first, let’s start with the common 2-node cluster and how quorum behaves on different versions of Windows Server.

In a 2-node cluster, the majority of votes will be one (1.) And because both nodes in a cluster will have a vote, by default, we don’t really have a majority since 50% is sitting right in the middle. This is the reason why an additional vote in the form of a disk or file share witness is introduced. We need a “tie-breaker” in order to have majority of votes. Now that we have three (3) votes – two from the cluster nodes and one from the witness – the majority of votes will be two (2) – three divided by two is 1.5, plus one is 2.5 (I’ve never really gotten the hang of doing math using words in a sentence.) We need to round down the results of the calculation of votes since we cannot really have half-a-vote. 66.67% is definitely higher than 50%, making it a majority. You can use this same logic to calculate the majority of votes for any number of nodes in your WSFC to keep it online and available.

So, Is My Always On Availability Group Really Highly Available?

Since our goal is to keep the WSFC online, we have to make sure that majority (if not all) of the voting members remain online and available. Just because a voting member is online doesn’t mean it is available from the WSFC’s point of view. It could mean that the network switch that connects one of the nodes to the WSFC become unavailable, causing it to be disconnected and not communicate with the other nodes. The node is online but it isn’t available as far as the WSFC is concerned.

So, with Windows Server 2012 (same as with Windows Server 2008/R2,) when I lost the file share witness, I still have two out of three votes (majority of votes) that kept the WSFC online. When somebody rebooted the secondary replica because of the installed security patches, the WSFC only had one out of three votes which is less than majority of votes. Doing so took the WSFC offline which also took the Always On Availability Group offline. Below is a screenshot of an SQL Server 2014 AG configuration that runs on Windows Server 2012 where the network connectivity between the nodes in the WSFC became unavailable.

Note that while the SQL Server instance is still online because it’s a standalone instance, the AG and the databases in it are offline and inaccessible. This means you can still connect to the SQL Server instance, run some queries against DMVs or the system databases but the AG databases are offline. And because the AG contained the SharePoint databases, the SharePoint farm went offline.

Introducing Dynamic Quorum

The customer panicked and complained when that happened. For one, they expected the AG to stay online regardless. Unfortunately, they were not monitoring the file share witness and, while it remained offline, somebody rebooted the secondary replica. This would not have happened if the file share witness remained online while the secondary replica was rebooted.

The good thing is that they were on Windows Server 2012. This version of Windows Server introduced the concept of dynamic quorum and is enabled, by default.  The WSFC manages the vote assignments to the nodes depending on their state. If the node is taken offline – rebooted, powered down, disconnected from the network, etc. – it’s vote is also removed from the cluster. It’s the reason why the AG went offline when the cluster node was rebooted. The beauty of this is that, when the node came back online, the cluster went back online (together with the AG) by virtue of the vote being added back to the WSFC. This was worse in earlier versions of Windows Server in that, if the WSFC went offline, the only way to bring it back online was to force start without quorum. Unfortunately, even when the WSFC came back online eventually, the SharePoint farm still was taken offline and was down for almost half an hour because it took a while to reboot the server.

And Dynamic Witness

Windows Server 2012 R2 introduced the dynamic witness feature. From the name itself, the WSFC dynamically adjusts the voting capability of the witness resource based on the number of votes required to meet quorum. This works in tandem with the dynamic quorum feature in Windows Server 2012 to enable the WSFC to maintain availability when any of the voting members become unavailable which also eliminates the additional administrative overhead of having to keep an odd number of votes.

Know Where You Stand

With AGs dependency on WSFC, there’s a lot that we DBAs need to be aware of that go outside the scope of their traditional job description. We need to know about Active Directory, DNS, networking, WSFC and AGs just to keep our databases highly available. So, in order to really know if your AGs are highly available,

1. Monitor your cluster. This means the nodes, the witness and everything in it. You need to be alerted when the number of voting members fall below total but still higher than majority. That way you can decide early on how to deal with it.
2. Know what version of Windows Server you’re running. Different versions of Windows Server behave differently when it comes to the quorum. I’ve described how Windows Server 2012 behaves. Windows Server 2012 R2 introduced the concept of dynamic witness where the witness vote is dynamically adjusted based on the number of voting nodes in the WSFC. I’ll save the details of dynamic witness in a future blog post but knowing what version of Windows Server you’re running will give you an understanding of what to expect.
3. Identify steps should any of the voting members in your WSFC fail. If any of the voting members in the WSFC become unavailable, know what steps you need to take. If the file share or disk witness went offline, maybe an alternative file share can be configured temporarily. This can be automated via a PowerShell script.
4. Document your configuration and recovery steps. Once you’ve identified how you can address issues when they happen, include them in your documentation. This will help your junior DBAs or operations engineers to resolves issues in case you decide to go on vacation.

There really is no guarantee that your AGs will always be highly available all of the time. That’s why it’s important to define your recovery objectives and service level agreements. But knowing where you stand and how you can resolve issues when they occur can help you meet your availability goals.

Additional Resources

• Understanding Quorum in a Failover Cluster
• What’s New in Failover Clustering in Windows Server
• Getting Started with AlwaysOn Always On Availability Groups (SQL Server)

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.”

This last weekend, I had the opportunity to speak at SharePoint Saturday Montreal – being one of the few English speakers for the event – on the topic of SQL Server high availability and disaster recovery options for SharePoint. After my presentation, one of my SharePoint MVP friends approached me about a database corruption issue that happened on their SharePoint farm. Now, being a SQL Server geek, I certainly would love to get my hands dirty and start looking at the error messages that DBCC CHECKDB reported. Unfortunately, since they do not have a dedicated SQL Server DBA, the only error message that they have is the one logged on the Windows Event Log as reported by SharePoint – Event ID 5586  from SharePoint Foundation. Unfortunately, there aren’t a lot of information from the Windows Event Log that tells any SharePoint (nor SQL Server) administrator that this is a database corruption issue. I asked if there were any Error Numbers 823, 824 or 825 reported and, sure enough, there was.

If it was only the database…

As a SQL Server administrator who has encountered any form of database corruption, our first instinct is to run DBCC CHECKDB, identify the level of corruption and how to possibly fix it. I’ve highlighted in a previous blog post that the output of DBCC CHECKDB can tell us what the corruption is and what possible options are available to resolve it. Armed with a good, working backup to use for repairing the corrupted database, we can safely restore the pages (if you’re on Enterprise Edition) or rows that were affected by the corruption and save the day. This could easily make any SQL Server DBA’s day a great one.

But, let’s pause for a minute and think, “what is this database used for?”

What is the database used for?

If the database is used by an internal, custom built application, you can simply ask the development team about how the data is stored and what the impacts are in terms of the corruption. Of course, we’re also assuming that this is just ONE database, not many. But what if there were many databases used by the application? What if it was a third-party application? What is covered by the support contract? Do we have that in writing? What is the service-level agreement (SLA) for this application? These are just some of the questions that you need to ask yourself before a real disaster strikes. Here are some of the ways that you can find out what your disaster recovery strategy will be like so you can prepare way ahead of time should it happen.

1. Know what application uses your database. Knowing the application that uses your databases can help you get more information about your possible options. As a SQL Server DBA, we are sometimes blindsided by the fact that our approach only revolves around SQL Server – restoring from backups, repairing corruption, provisioning high availability and disaster recovery solutions, etc. We need to know the application to prepare our plan of action.
2. Know what other databases are involved. Enterprise applications use either one or more databases to implement their functionality. SharePoint is a classic example that I use when explaining this concept – it uses a farm configuration database, an administration site content database, a bunch of content databases used by different site collections, several service application databases, etc. (a more detailed list of the different SharePoint databases are available in this TechNet article.) This is because the transactional consistency of the application no longer depends on just one database. Even if you managed to repair a corrupted database in an application that uses multiple databases, there is no guarantee that the application is transactionally consistent.
3. If a third-party application is used, know what the application vendor considers as SUPPORTED. I mentioned Microsoft KB 841057 in my previous blog post and how the REPAIR_ALLOW_DATA_LOSS option in DBCC CHECKDB is considered to be an unsupported database change. When my friend told me that one of the IT staff ran DBCC CHECKDB using the REPAIR_ALLOW_DATA_LOSS option, my immediate response was, “he should not have done that.” By doing so, it rendered the application – in this case, SharePoint – unsupported. Furthermore, because the impacts of the REPAIR_ALLOW_DATA_LOSS was not considered, the SharePoint content database became even more corrupted.Now, another option that we SQL Server DBAs would probably do is to restore the SharePoint configuration database. This approach is not officially supported as per Microsoft KB 948725. This means that regardless of whether or not your SharePoint database backups are valid and working, restoring them on the existing farm is not supported. Now, this is just one of many examples. Even SAP has it’s own supported way of dealing with corrupted databases. SAP Notes # 1597910 – Handling of database corruptions on SQL Server – discusses what is supported and what isn’t in terms of dealing with database corruption. This blog post from Luis Darui (SAP Support Engineer) on this particular topic talks about how not to use REPAIR_ALLOW_DATA_LOSS without guidance from SAP.
4. Plan your disaster recovery strategy based on collected information. At this point, there really is no other option to recover the SharePoint databases other than restore all of the database backups taken at a specific point in time on a DIFFERENT SQL Server instance to keep the farm transactionally consistent. Or, if at all possible, rebuild the whole farm using the documented process to keep the farm configuration consistent and restore the content databases to it. This will definitely take the whole farm offline while restoring the backups and lose all of the data after the backups were taken. This is why it is important to know what the defined and agreed upon recovery objectives (RPO/RTO) and SLAs are in order to properly design a disaster recovery solution. A SQL Server Availability Group configuration that uses a different storage subsystem could have been implemented to address the database corruption issue. Once the disaster recovery strategy is implemented and documented, it is important to test it out on a regular basis to make sure that recovery objectives and SLAs are met.

In my presentations, I always joke around the fact that we don’t really need a high availability and a disaster recovery solution – until we do. It’s like the health insurance policy that we don’t really need – until we do. But more than just the database for the SQL Server DBA, it is important to know and understand the overall disaster recovery strategy from the ground up, involving individuals from different teams, the different components that make up the application architecture and how to execute the strategy when the real disaster strikes. It’s also the main reason why I recorded the video below to emphasize that while we SQL Server DBAs need to be focused on the database, we need to have an understanding of the overall application architecture that our databases are being used for.

So, here it is, a video recording of my most requested topic at SharePoint conferences and events – Database Configuration for Maximum SharePoint 2010/2013 Performance

And, you’ve probably seen the corresponding slide deck.

Feel free to use this script as you wish. It has only been tested on default instances of SQL Server 2008 and higher (named instances have not been considered yet) running on Windows Server 2008 and higher. High availability checks like failover clustering, database mirroring and Availability Groups have not been included yet on this version. Comment on the script for bugs and fixes that you want included, keeping in mind that this is specifically for SharePoint databases. Don’t expect any indexing improvements nor identifying the TOP I/O consumers because there is no way for us to modify those queries without breaking your SharePoint support contract (and I am in no way a lawyer to even argue about the contents of the EULA.)

Enjoy.

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.

If you are free on 1-Dec-2012, join us for a whole day of FREE training on SharePoint from industry experts, Microsoft engineers and MVPs. Register here to reserve a slot.