When having a disaster recovery farm facilitated by Log Shipping, you would set up content databases in your secondary farm to process logs from your primary farm. For that to work successfully, you need to configure and set up the secondary farm with it’s own configuration database, and some services also can’t be configured as targets for log shipping or asynchronous mirroring. This KB article has more info on that: http://technet.microsoft.com/en-us/library/ff628971.aspx
As you create sites in your primary environment, the Configuration Database in the secondary environment(s) don’t get updated – they end up not knowing about these sites. The configuration database stores a “SiteMap” of all sites, and that is used in various places, such as Search, the Central Administration UI, and I also believe the constructor of an SPSite object uses that to identify the exact site you are instantiating.
In SharePoint 2007, the only way to refresh the SiteMap in the configuration DB is to detach and re-attach the content database. Apart from being inconvenient and not well known this was also adding to precious minutes in downtime.
In SharePoint 2010 you can also detach and re-attach the database, but we now have a managed method that does the job for us. The SPContentDatabase object has a RefreshSitesInConfigurationDatabase() method that we could call from code or PowerShell:
To list all databases in the farm:
Get-SPDatabase
To get a specific database in a variable:
$contentDB = Get-SPDatabase | where {$_.Name -eq “WSS_Content_Contoso”}
To execute the method on the database:
$contentDB.RefreshSitesInConfigurationDatabase()
You will have to do this on each disaster recovery farm that you have.
Opening up this method with Reflector, we could see its implementation.
It first calls the CleanUpSiteMap() method, which deletes all entries that do not exist anymore. It runs the following SQL query:
“SELECT SiteMap.Id, SiteMap.Path FROM SiteMap WHERE SiteMap.ApplicationId=@ApplicationId AND SiteMap.DatabaseId=@DatabaseId”
And then runs a check for each SiteMap.Id (the GUID of the site), deleting entries where the site is not found.
After that it calls RestoreSiteMap() , which internally gets all sites and runs the SPConfigurationDatabase.CreateSite() method. And that’s how the configuration database gets updated.
The key thing here to point out is that having a HOT standby environment requires planning and testing. If you haven’t tested your recovery strategy you might as well say you don’t really have one.
Other resources:
http://msdn.microsoft.com/en-us/library/ms191233.aspx
http://technet.microsoft.com/en-us/library/cc748824.aspx
