Let’s say you have a ContentDB that’s growing larger. I know, crazy idea right… Anyhow, the SQL server is running out of drive space. The solution is to move the ContentDB. There are two ways of going about this. One is to move to a new server instance. While this is a valid and supported solution it may not be the right one. Moving to a new instance has been well documented, so I’ll leave that alone for now. Also, if this is a common procedure in your environment you should be using a SQL Alias. Todd Carter’s post titled Don’t Tell SharePoint The Name of Your SQL Server is a great place to get up to speed on this topic.
The second solution is to move the database file to a new drive. Since all that’s needed is to detach and attach the database in the same instance, we don’t need to tell SharePoint to do anything differently. With that said there are a couple of tricks you can use to minimize downtime.
Start by moving only one ContentDB at a time. This will allow the other sites located in other ContentDBs to stay online. Also, setting the ContentDB to read-only and doing a copy backup users can still access the sites and data, but can’t write. This should help to insure data consistency during the move. Just be sure to remove the read-only attribute of the “copied” ContentDB before attaching. For more information see Moving User Databases.