Geeks With Blogs
Scott Lock Thoughts on .Net, Caparea.net and Windows Phone

Again, maybe old news but I thought I would post something interesting that happened during a recent upgrade from SPS 2003 to MOSS.  SharePoint is very finicky when it comes to database transactions and sizing during the gradual upgrade process.  Here are a couple of things to note:

1.  Make sure you have enough size - When upgrading a site that had about 150GB in content, we needed about 500GB in space to complete the migration.

2.  Make sure you know where your _Pair DB's Are - SharePoint for some reason didn't put the _Pair db's on the default data and log file locations (C:\) and had to be moved to a larger volume.  This caused the upgrade to fail with space issues.

3.  Make sure to set the _Pair data and log files to AutoGrow - Now that you have the right amount of space, make sure that you configure the new databases to grow correctly.  Large content databases will have large transactions when copying the sitecollections.  This can also lead to things like timeouts and space issues.  You should also consider setting the recovery model to "Simple" during the migration to keep things tight.

Just some things to think about.

Posted on Tuesday, July 22, 2008 6:10 PM SQL Server , SharePoint | Back to top


Comments on this post: Database gotchas when upgrading SPS 2003 to MOSS

# re: Database gotchas when upgrading SPS 2003 to MOSS
Requesting Gravatar...
I remember you being slammed with this and asking me questions about the problems you were having with the migration. I'm glad it got it all worked out finally and this is great information to keep track of for future migrations.

For what it's worth, you can now look to System Center Data Protection Manager for some of your database migration requirements. Also, alias the SQL Server so you can change it's hardware without SharePoint (or any other DB app) being the wiser.

Final bit of advice. The Simple recovery model cuts the logs off (they basically shrink to 0) but make sure you turn full back on for production work so you can have some real chances of recovery without losing much work. Again - Data Protection Manager can be beneficial here.
Left by Matt Ranlett on Aug 14, 2008 4:35 PM

Your comment:
 (will show your gravatar)


Copyright © Scott Lock | Powered by: GeeksWithBlogs.net