I recently had to recover from a disaster with one of our SharePoint testing environments. (This happens to be the only testing environment that is not on virtual hardware.) Fortunately, I do quality assurance testing for a disaster recovery product and it wasn’t long before I had new hardware for the failing database server and could rebuild the farm. I did run into some interesting issues however. After I reinstalled the WFEs and had central administration working again, I reattached the content databases that I had recovered. After all of this my farm worked fine and I had access to all of my Site Collections again. Disaster averted. The health analyzer on the farm kept warning me about upgrading databases though. Specifically the error message that I got was the following; "Database is in compatibility range and upgrade is recommended." Seems simple enough. There are Powershell commands that I can use to upgrade the databases.
$contentdb = Get-SPContentDatabase | Where-Object {$_.Name -eq "WSS_Content"}
Upgrade-SPContentDatabase -Identity $contentdb
I ran those commands from a Powershell prompt (the SharePoint 2010 Management Shell since that one automatically loads the SharePoint snap-in.) I was then immediately irritated when the upgrade failed.
WARNING: Database [SPContentDatabase Name=WSS_Content] does not need to be upgraded.
So, Central Administration tells me that my database needs to be upgraded, and then when I try to update the database, it tells me that it doesn’t need to be upgraded. I was a little confused. I figured I would try a different approach, so I ran PSConfig on the farm with the “build to build” switch.
psconfig -cmd upgrade -inplace b2b -wait -force
This only resulted in more errors.
I then tried to detach and reattach the content databases, since, when attaching a content db, SharePoint should typically upgrade the database if it needs it. That didn’t work either.
I talked with Sean McDonough for a few minutes about the situation and he enlightened me that there is a chance that it is not my content databases that need upgrading. How do you really know though? Time to poke into your content databases to tell for sure. The first database you need to check is your SharePoint Config database since that is the one that shows you what version your farm is currently using, be it a service pack, or one of the myriad cumulative updates. Run the following in a Sequel Server Management Studio Query.
use SharePoint_Config
SELECT Version
FROM Versions
WHERE VersionId = ’00000000-0000-0000-0000-000000000000′
ORDER BY Id DESC
This will show you every version that your farm has evolved through. Mine showed one version; 14.0.4762.1000. (This is incidentally the RTM version of SharePoint 2010) I then ran the same query against one of my databases that supposedly needed to be upgraded and found more than one version. 4762 was there, but so was 5128. It would seem that it wasn’t my content databases that needed to be upgraded, but rather the rest of my farm. Now my problem was figuring out which version I needed to end up with after upgrading. Fortunately, Todd Klindt has an awesome reference page here that will tell you which Service Pack or Cumulative Update each version number means with a link to download what you need. I downloaded the Cumulative Update for October 2010, installed it on my farm, and then ran psconfig again to finish everything up. All of those “database needs upgrade” errors were gone and the health analyzer on my farm settled down again. Just to be sure I went to the Farm’s Central Administration, then to “Upgrade and Migration” and clicked on “Review Database status.” Every database stated “No Action required” instead of the upgrade message.
So, if you have to recover a farm and reattach your databases, or you are attaching your content databases to a new farm, keep in mind that if SharePoint tells you that databases need to be upgraded, it might not be the databases that are in need of an upgrade.
Many thanks to Sean McDonough for his input, and to Todd Klindt for his blog for reference.
No comments:
Post a Comment