Tip: Take a moment to rename databases during a database attach upgrade

SharePoint Products automatically generate GUID-based database names when databases are created, such as WSS_Content_ 2a24a7ecde1744d4823e31d77b266653. When you're ready to upgrade, if you don’t have a handy farm inventory, it can take a little time and research to identify each database and map them to your Web applications and site collections. It sure would make farm management a bit easier if the database names actually meant something that you could more easily identify. Why not take a little time to make the database names more meaningful while you’re doing a database attach upgrade?

Note   This tip does not apply to an in-place upgrade.

When you’re not in the middle of an upgrade, renaming databases requires detaching them from the SharePoint Web applications in SharePoint Central Administration, then using SQL Server Management Studio to rename them (or back up and restore them with a new name). Either action requires some down time to accomplish, and renaming databases might not be your top priority for your down time opportunities.

However, when you do a database attach upgrade, you are either detaching the databases while you move them to the new farm, or backing them up and restoring them to the new farm, so you have an opportunity to rename them. Why not straighten them out then? It's as easy as typing a new name in the "To database" box if you're restoring a database or using “Rename” when you attach the database to a new SQL Server instance.





Before you rename the database to just anything, take a moment to decide on a naming scheme. For example, you could include any of the following in your database names:

  • The port number for the Web application associated with the database, such as WSS_Content_2133.
  • The type of sites that are stored in the databases, such as WSS_Content_Collab or WSS_Content_MySites.
  • The name of the site collection in the database, if there’s only one per database), such as WSS_Content_ContosoHome.

Of course, even if you're not doing an upgrade, you can take time during a service outage to rename databases to lose the GUIDs and make them make more sense. Here are some blog posts to help you rename databases at any time:

Also, see more info on:

- Samantha Robertson

Comments (2)
  1. Craig Humphrey says:

    Better yet, don't let the GUIDs get there in the first place!

    Giving new Content DBs sensible names is easy, even some of your service DBs can be named at creation time, others (I'm looking at you PerformancePoint) are harder.

    Using reusable/repeatable scripts like AutoSPInstaller (autospinstaller.codeplex.com) can make life so much simpler, even in complex environments.

  2. Nico de Jong says:

    Better yet – resore, rename and move the mdf and ldf to your preferred location with T-SQL like

    RESTORE DATABASE SP2010UA_IntranetPortal_Content

    FROM DISK='\SomeServerDBUAUpgradeWSS_Content_Intranet.bak'


    MOVE 'WSS_Content_Intranet' TO 'C:Microsoft SQL ServerMSSQLDataSP2010UA_IntranetPortal_Content.mdf',

    MOVE 'WSS_Content_Intranet_log'  TO 'C:Microsoft SQL ServerMSSQLDataLogsSP2010UA_IntranetPortal_Content_log.ldf'

Comments are closed.

Skip to main content