3

I am testing upgrade of a site collection to SharePoint 2013. The size of the content database is 225 GB. It has only one site collection.

This is a double hop upgrade. I have upgraded SP2007 sitecollection to SP2010 first.

On SP 2013 the Upgrade-SPSite is running now for 4 days and only 75% is completed.

The database is already cleaned up for document versions and audit log (clean up done in SP2007). The database is also shrinked (in SP 2007).

I analyzed the site upgrade log file to find the elapsed time for various activities.

The process is trying to upgrade 5688 sub sites in the site collection.

For the initial sub sites, the elapsed time is ~20 to 30 seconds. However as the upgrade is progressing the elapsed time is increasing for each subsite to 2 to 3 minutes.

The biggest difference in execution time is for following steps

  1. Provisioning the Design Gallery in site

Provisioning the Design Gallery in site: << URL of a subsite>>

[SPTree Value=SPSite Url= added to dependency cache by lookup
[SPTree Value=SPSite Url= added to dependency cache by lookup
[SPTree Value=SPSite Url= added to dependency cache by lookup
End Upgrade()
Begin Commit()
End Commit()
Begin Dispose()
End Dispose()
SQL Query Count=48
SPRequest Objects=19
Execution Time=678.875806841372

Provisioning the Design Gallery in site: <>
[SPTree Value=SPSite Url= added to dependency cache by lookup
[SPTree Value=SPSite Url= added to dependency cache by lookup
[SPTree Value=SPSite Url= added to dependency cache by lookup
End Upgrade()
Begin Commit()
End Commit()
Begin Dispose()
End Dispose()
SQL Query Count=58
SPRequest Objects=1348
Execution Time=26429.550543435

  1. Provisioning oslo.preview file in site

Provisioning oslo.preview file in site: nontoxic Site Url: << url of the subsite>>

Successfully provisioned oslo preview master page into the master page gallery.
End Upgrade()
Begin Commit()
End Commit()
Begin Dispose()
End Dispose()
SQL Query Count=6
SPRequest Objects=0
Execution Time=177.670346370838

Provisioning oslo.preview file in site: hortprac Site Url: << Url of the subsite>>
Successfully provisioned oslo preview master page into the master page gallery.
End Upgrade()
Begin Commit()
End Commit()
Begin Dispose()
End Dispose()
SQL Query Count=15
SPRequest Objects=1330
Execution Time=33145.8395550272

|improve this question
  • I know you are doing this to test the upgrade path to 2013, but it could be a good opportunity to split that many subsites into separate site collections (perhaps, for example in the SP2010 environment) which will help with maintenance in the future. – Russell Nov 1 '13 at 2:26
  • Did you specify VersionUpgrade as a parameter? Or just Build-to-build upgrade? – Russell Nov 1 '13 at 2:30
  • As another test after this completes, you could try running Test-SPSite to do a site collection health check. This may highlight any specific issues (other than the large no. subsites). – Russell Nov 1 '13 at 2:32
  • Interesting test. If you find the time is increasing as you move through the sub sites, it could mean bad memory management in the upgrade process. It would be worthwhile to try and isolate that site that is taking 33145s and run an upgrade only on that one site? – Louis Nov 1 '13 at 3:57
  • Thanks Russell. Yes spliting is one of the option. However spliting will require considerable involvement from the site owners. Throughing new features and behivour with exisiting layout and navigation structure will have better user acceptance. So we planned to upgrade the site collection as it is in the first phase. However for further performance enhancement we will split into multiple site collections. – Trupti Nov 1 '13 at 4:32
4

We upgraded one of our 225GB content databases in roughly 4 hours so 4 days is excessive. What this actually sounds like is that one of the servers in the mix is running into severe resource issues and is having to swap to disk a lot more than it should. I'd check all the servers in the farm including the SQL server and make sure that they have adequate free disk space and sufficient RAM. It is also possible that you are running into a server quota set at some point, either on CPU, RAM or disk space.

If your shop is like many these days, it is possible that the SQL data files are also hosted on a SAN and an improper setting there could easily cause this behavior.

|improve this answer
  • To add to this, many subwebs (in the thousands) can significantly impact upgrade performance as well. – Trevor Seward Nov 1 '13 at 0:03
  • Thanks Trevor. Mount-contentdatabe is finishing within 4 hours for my database. However upgrade-spsite for a site collection is taking longer. – Trupti Nov 1 '13 at 0:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.