Freigeben über

High Performance Upgrades for MOSS 2007 & WSS 3.0 (Database Migration Methods)

  • Artikel

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 https://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 @ https://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 https://webapp1 –databasename contentdb_1 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp1 –databasename contentdb_2 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp1 –databasename contentdb_3 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp1 –databasename contentdb_4 –databaseserver SQLsrvA

 

Batch2.cmd

Stsadm –o addcontentdb –url https://webapp2  –databasename contentdb_5 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp2  –databasename contentdb_6 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp2 –databasename contentdb_7 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp2  –databasename contentdb_8 –databaseserver SQLsrvA

 

 

Batch3.cmd

Stsadm –o addcontentdb –url https://webapp3  –databasename contentdb_9 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp3  –databasename contentdb_10 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp3  –databasename contentdb_11 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp3  –databasename contentdb_12 –databaseserver SQLsrvA

 

Batch4.cmd

Stsadm –o addcontentdb –url https://webapp4  –databasename contentdb_13 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp4  –databasename contentdb_14 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://webapp4  –databasename contentdb_15 –databaseserver SQLsrvA

Stsadm –o addcontentdb –url https://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

Comments

  • Anonymous
    January 01, 2003
    And several topics came up so I thought I would post some of them here. Here are some of the counters

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Unfortunately it is not possible to update/patch SharePoint without occurring some amount downtime. So

  • Anonymous
    January 01, 2003
    PingBack from http://www.kaizenlog.com/2007/08/03/database-03082007/