SharePoint 2010: How to restore multiple web application content databases

Introduction

This posting walks through the process of performing a restore of multiple content databases associated with a single SharePoint 2010 web application.

Procedure

1. Copy the content database backups to a local folder on the database server.
2. Perform a SharePoint detach of the content databases from web application:
1. Go: CA > Application Management > Manage Content Databases.
2. Remove each database.
3. Detach old/corrupted content database(s) (SQL Server Management Studio)
4. Restore backup content database(s) (SQL Server Management Studio)
5. Add farm service and farm administration accounts to database logins and map appropriately (SQL Server Management Studio)
6. Perform a SharePoint attach of the content database(s) (through SharePoint Central Administration or via PowerShell script)
7. Refresh browser.

References

• Restore a content database (SharePoint Foundation 2010)
• Databases running in compatibility range, upgrade recommended (SharePoint Server 2010)
• Attach or detach content databases (SharePoint Foundation 2010)
• Mount-SPContentDatabase
• Upgrade-SPContentDatabase

Notes

• There really is nothing more to do, when restoring multiple content databases associated with a web application - no special procedure, script to run, special order, etc. You don't even need to perform an IISReset. Just attach them and go.  SharePoint will detect that multiple databases are associated with the web application and relink everything appropriately.
• You may find, after attaching the content databases (either via CA or via PowerShell script), that the site collection(s) in one of the content databases are not visible, and navigating to the URL for one of these site collections returns the "404" error.  The basis for this experience is unclear but can be resolved by performing a SharePoint detach/attach of these databases in CA.  You may need to repeat this several times.
• TIP: the following procedure has worked for me when I encountered this problem: first perform the SharePoint attach of the content database containing the main site collection - the one hosting the default site collection.  Next, before performing SharePoint attachments of the other content databases, open a browser and navigate to the default site collection.  Then, perform a SharePoint attach of the next content database, open a browser and navigate to a site collection in this next content database; and so on.
• Performing SharePoint attachments of content databases by using Central Administration may require a database upgrade afterwards.  On the other hand, using the Mount-SPContentDatabase PowerShell script automatically performs the database upgrade as a part of the attach process.
• I have performed a restore in this fashion, for a farm hosting three site collections and about 150 sites, in about 1 hour, and that's with lots of double-checking.
• I've bolded SharePoint when referring to performing an attachment through SharePoint Central Administration or via PowerShell script, as opposed to performing such operations directly with SQL Server.  The terminology here is a bit ambiguous, as these words are also used when performing attach/detach operations when working with SQL Server.  However, the two are effectively different operations.