Moving SharePoint Database Data Files

April 27, 2008 · 2 min read

I ran across a client that was looking to move the SQL Server data files and logs from their SharePoint 2007 installation to another drive. The reason was to free up some space on the drive that SQL Server was installed on. I decided to post the steps that I took so that it might be beneficial for others. Now, with that said, I am not completely positive that my steps are the best possible way; but it did accomplish the task and everything worked when I was done. So I guess the steps I took couldn't have been too bad. J

Here are the steps:

  1. Quiesce the Farm – This is especially important if you are working on a production system. Pretty much it takes the farm out of commission and doesn't allow any more sessions to be created.

  2. Backup all of the databases that you are looking to move.

    1. With the client I was working with they were looking to move all of the SharePoint database data and log files. Your needs may vary, but in any case this is another very important step. Be sure you have a current backup of any databases you will be fiddling with.

  3. Turn off SharePoint Services

    1. This will stop the connections to some of the databases. If you try to detach any of the databases you will find that some will have connections active. In case of the content databases you will probably find that the connections to the have already been taken care of. Either way you will need to stop some of the SharePoint services in order to get the search databases and config database totally disconnected.

    2. You can either stop the services through the Central Administration, or you can do it at the Services Console. I chose the services console since I didn't want to deal with typing in configuring the services again.

      1. To stop the connections to the existing databases stop the following services:

        1. Office SharePoint Search Service
        2. Windows SharePoint Services Administration
        3. Windows SharePoint Services Search
        4. Windows SharePoint Services Timer
        5. Windows SharePoint Services Tracing
        6. World Wide Web Publishing Service

  4. After the services are stopped, you should be able to detach the databases that you are looking to move.

  5. After detaching the databases navigate to where the data and log files are being stored and copy them to your destination.

  6. Reattach your databases.

  7. Restart your services.

  8. Un-quiesce the farm.

If everything went well, you should have the ability to get back to your sites and all of your content. If not, you can always roll back to the database data files you previously had in the old location. I would recommend doing a test run on a development machine first to be sure that you not encounter any problems.

Hopefully, you will find this to be helpful in your quest if you run in to the same need.

Happy SharePointing..

Michael

This article is part of the GWB Archives. Original Author: Michael Van Cleave

New on Geeks with Blogs

  • We Won The One Award I Actually Care About

    Full Scale made the Inc. 5000 for the fifth year straight, the 12th listing across my three companies. Here is why the one award you cannot buy is worth stopping for.

  • Your Customers Build the Features Now

    I let a tool I liked sit dead for a year rather than build the features I wanted. An MCP server meant I never had to, and your customers can do the same to your product.

  • Get the Size of a Directory in Linux the Easy Way

    du -sh for the quick answer, ncdu for the cleanup, df for the disk itself: every command for checking directory size in Linux, plus why du and df never agree.

  • Vim Search and Replace: The Ultimate Guide

    One :%s command replaces every match in a file before a find dialog would even open. The Vim substitute patterns worth the muscle memory: flags, ranges, capture groups, and multi-file edits.