If you’re looking for the best performance and quickest upgrade I highly recommend the Database Migration approach. At MSIT our preferred method is such, it allows a creative flexible upgrade path that has the fastest throughput. Using a method we call parallel upgrades, in MSIT we were able to upgrade at 4 times faster than a standard database migration. What is a parallel farm upgrade you ask? Well read on :)
Consider the following scenario
4 Terabytes of data to upgrade
12,000 site collections to upgrade
48 hours to complete the upgrade
Product throughput on optimal hardware from our experiences internally was 50-70GB per hour.
Let’s assume we only get 50GB/hr that comes out to around 80 hours to complete, this was not fast enough in our situation. With that being said we had to get creative and came up with the parallel method. This entails creating multiple single box farms with single web applications on a shared high powered SQL 2005 cluster and balancing out the database attach. Let’s assume that http://portal has 80 content databases at 50GB per database.
Some standards to note that we hold true internally.
· Your root site should be kept in its own database with the site warning maximum set to 0/1, this allows for easy manipulation of the root site in upgrades away from the rest of the farm
· Site collection count / Site size should be balanced accordingly internally we try to maintain no more than 500 site collections per database, once reaching that limit we cap off the database and create a new content database (this will not be true if you are going toward a database mirror scenario) reason being is due to the max quotas we have set on site collections this is the best site cap by design storage wise. In your environment this may be different.
The following steps are assuming you have already run prescan on your environment and cleaned up any discrepancies. Additionally the assumption would be you have a new Production MOSS Farm created and awaiting your content databases. For more information on prescan Bill Baer has several great posts explaining this in detail @ http://blogs.technet.com/wbaer/search.aspx?q=prescan&p=1
Step 1 would be to create the 4 farms; this can be virtualized however in our experience we used physical hardware.
Step 2 would be to backup your databases, in a database migration approach you would backup your databases, restore them with new names and upgrade your backups, thus in the event you need to back-out your old farm with your old databases are running untouched.
Step 3 would be to create your batch files for easy automation of your database migration. Your batch files may look similar to the following. Please only upgrade copies of your databases and never the actual databases if at all possible. Also once you execute a database attach command the schema changes instantly, canceling the command will not save the database J
Batch1.cmd
Stsadm –o addcontentdb –url http://webapp1 –databasename contentdb_1 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp1 –databasename contentdb_2 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp1 –databasename contentdb_3 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp1 –databasename contentdb_4 –databaseserver SQLsrvA
Batch2.cmd
Stsadm –o addcontentdb –url http://webapp2 –databasename contentdb_5 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp2 –databasename contentdb_6 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp2 –databasename contentdb_7 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp2 –databasename contentdb_8 –databaseserver SQLsrvA
Batch3.cmd
Stsadm –o addcontentdb –url http://webapp3 –databasename contentdb_9 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp3 –databasename contentdb_10 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp3 –databasename contentdb_11 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp3 –databasename contentdb_12 –databaseserver SQLsrvA
Batch4.cmd
Stsadm –o addcontentdb –url http://webapp4 –databasename contentdb_13 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp4 –databasename contentdb_14 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp4 –databasename contentdb_15 –databaseserver SQLsrvA
Stsadm –o addcontentdb –url http://webapp4 –databasename contentdb_16 –databaseserver SQLsrvA
Notice how we are evenly distributing the content databases between the 4 parallel farms. These batch files should be ran from your bin folder on their respected parallel farm installs (%systemdrive%\program files\common files\web server extensions\12\bin)
Once all 4 batch scripts have completed check your upgrade.log on all 4 parallel farms for discrepancies.
Step 4 Verify upgrade has completed successfully for all databases
Step 5 Detach all of your databases from the parallel farms, this can be done by modifying your batch scripts to use stsadm –o deletecontentdb rather then addcontentdb.
Step 6 Create a new batch file that would dbattach all of your upgraded databases to your production MOSS farm that you have created and waiting on standby. Ensure that you DBattach your root site collection database first.
And that’s it! Essentially we have quadrupled the throughput of your database migration.
Happy Upgrading!
Cory