SharePoint 2013 Upgrade Process – Part 2

Continuing on the SharePoint 2013 upgrade process from previous post, we will see some considerations and commands while planning upgrading content databases to SP 2013.

When you have upgraded to SharePoint 2013 from SharePoint 2010 the sites are still in 2010 format. The sites themselves have to be updated as well.

Farm Administrators can run the command “Request-SPUgradeEvaluationSiteCollections”  This creates an evaluation site collections and renders all the content in a different site collection.

The below command shows how many days the evaluation site will be stick around for evaluation.

We can push the reminder to upgrade the site collection :  $weba.UpgradeReminderDelay = 5

In case if you does not want to upgrade a site collection you can disable the option to upgrade for site collections users from SP management shell.

Lets see some throttle settings at Site Collection level, which shows the ConcurrentUpgradeSessionLimit which on requirement we can either decrease or increase. If we have a small content upgrade it better to spike the limit up otherwise it will not be much help.

Throttle settings on content database upgrade

 

Lets see some more action while we initiate a site collection upgrade from SP management shell.

 

Coming to some options while running either the site collection upgrade or content database upgrade, we have options to “-Throttled” or “-Unthrottled” what unthrottling means it just upgrade everything  immediately as a priority and will not put in throttling queue.

We can get the upgrade session info status by running this command “get-spsiteupgradesessioninfo -contentdatabase wss_content -showinprogress” we have other options like “-showcompleted” and “-showfailed”

we can remove a site from upgrade if its already queued to upgrade with “remove-spsiteupgradesessioninfo -identity http://intranet/sites/it”

Upgrade-SPContentDatabase WSS_Content -NoB2BSiteUpgrade -UseSnapshot

 This example upgrades the existing WSS_Content content database schema only while using a snapshot of the database to retain read-only access to the content during the upgrade. No build-to-build upgrade actions are performed on any site collections. This operation does not change the CompatibilityLevel for existing site collections in this database.

We have seen some of the PowerShell help necessary for upgrading. But we need to plan and test the whole process from a staging farm before and look at the upgrade performance and plan the schedule. Once again this is purely from and SharePoint Admin perspective, later in another post we will look at other dev aspects which are key for smooth upgrade.

http://technet.microsoft.com/en-us/library/cc262483(v=office.15).aspx                                                  http://technet.microsoft.com/en-us/library/ff607813(v=office.15).aspx

Advertisement

SharePoint Content database – maxsitecount and warningsitecount – PowerShell

Quick Help Script:

How to set the maxsitecount and warningsitecount  on a content database either after the upgrade or migration or even after moving the content database from different farm or web application.

Add-PSSnapin microsoft.sharepoint.powershell
$dbs = get-spcontentdatabase -webapplication https://webapplicationname
foreach($db in $dbs.name) {Set-SPContentDatabase -Identity $db -MaxSiteCount 1 -WarningSiteCount 0}

Can you move a single large site collection into multiple content databases?

Although single content databases of upto 200GB is possible in Sharepoint 2010, administering and managing such a db would be a nightmare. What would you suggest for options in a case where there is one site collection and one corresponding content database. Can you have more than one content db for that one site collection? Can you expand the table to be hosted on other sql servers/machines? Does RBS help?

Expert Comments:

Officially there is support up to 4TBs with optimization, but realistically that is difficult to support and should only be used in extreme exceptions. Technically there were no real changes made to support the additional sizes, it was just an update to guidance. I still try and work with my customers to maintain databases no larger than 75-100GBs unless absolutely necessary. I do have customers with multi-terabyte farms.

A single site collection can only use 1 Content DB. It is possible though to create solutions that use a single site collection that interacts with multiple site collections for content storage. Its transparent to the users, but splits the content across multiple sites, multiple content dbs.

RBS can also help. The big advantage there is it reduces storage within the content db. I’m not as sold on RBS though in most scenarios. There are benefits, but there are also costs and added complexity. If you have an extremely large data source that MUST be in a single site collection and content cannot be archived, then this may be a good solution.

As for multiple SQL servers, you can leverage multiple SQL servers for a single farm, but my understanding is that a single database and all supporting data/log files must be part of the same instance. Using multiple data files on separate disk partitions though is part of the guidance to increase performance on those content dbs above 200GB.