Sharepoint 2007 - Splitting up a very large Content DB into multiple content DBs

Very Exciting. Getting ready to split up a large content DB on a large enterprise level moss farm deployment. The idea is to distribute data that has grown over time into multiple content databases for performance and reliability. The plan is to use stsadm -o mergecontentdbs. However this is known to have implications and issues - http://support.microsoft.com/kb/969242. We are taking all necessary steps to avoid any problems. I'll update this post later on how our operation does.

 Update - Sorry for the late update guys. heres how it went.

 We had 2 tasks ahead of us. One was to move a content db from one database server to another in the cluster. The other was to split up a large content db on one of the servers into multiple content dbs.

Splitting the large content db into multiple content DB's:

 Microsoft recommended that we do not run the merge content db command on databases larger that 10 GB in size. So instead of moving out the larger site collections into new content databses, we decided to move all of the smaller site collections out instead. This would take much longer, but would be safer so we went that route.

1. Make sure we stop all search crawls. This is important. Not pause but completely stop the search crawls. Let the running crawls complete and remove the schedule for all future crawls. If we do not do this, we take the risk of corrupting our search indexes.
2. Create the new content databses
3. Run stsadm -o preparetomove on the content db to be split
4. Create a sites.xml using stsadm -o enumsitecollections on the source content database
5. split up the sites.xml into manageable chunks containing the site colllections that we which to split out
6. run stsadm -o mergecontent dbs on the source and destination content databases using the site.xml files created in step 5 to move the site collections from source to destination database to the destination content databases
7. run stsadm -o databaserepair command on the source and destination databses to remove any orphan records - we had none
8. test

we moved approximately 150 GB of data from a large content database into 5 diffenet new content databases. It took us approximately 18 hours including testing. After the maintennance, we improved page response times for the site collections. We also reduced app pool recycles for our web applications due to processes hitting their virtual memory limits. These almost seemed to dissapear after the maintennance. Overall we were very happy with the results.

Moving a content db from one server to another:

We had multiple large content databases on one server and we wanted to balance it out by moving a large content database from one server to another in the cluster.

1. Run stsadm -o preparetomove on the content db to move
2. detach the content db by running stsadm -o deletecontentdb
3. using sql management studio, detach the content database from the server instance
4. move the databse files from the source server to the destination server
5. using management studio, re-attach the content database on the new sql server
6. add the content database by ising stsadm -o addcontentdb
7. Test

that was pretty much it. After our maintennance, we started our search crawls and reset the schedule. balancing out the databases also increased performance on our web applications.