SPFarm.GetObject Cache? (转载)

2011-02-28 09:11 DanielWise 阅读(356) 评论(0) 编辑收藏举报

If you experience issues with WSS and MOSS timer jobs failing to complete are receiving errors trying to run psconfig, clearing the configuration cache on the farm is a possible method for resolving the issue. The config cache is where we cache configuration information (stored in the config database) on each server in the farm. Caching the data on each server prevents us from having to make SQL calls to pull this information from the configuration database. Sometime this data can become corrupted and needs to be cleared out and rebuilt. If you only see a single server having issues, only clear the config cache on that server, you do not need to clear the cache on the entire farm. To do a single server, follow the steps below on just the problem server.

To clear the config cache on the farm, follow these steps:

Stop the OWSTIMER service on ALL of the MOSS servers in the farm.
On the Index server, navigate to:

Server 2003 location: Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\GUID and delete all the XML files from the directory.
Server 2008 location: Drive:\ProgramData\Microsoft\SharePoint\Config\GUID and delete all the XML files from the directory.

Delete all the XML file in the directory. NOTE: ONLY THE XML FILES, NOT THE .INI FILE.
Open the cache.ini with Notepad and reset the number to 1. Save and close the file.
Start the OWSTIMER service on the Index server and wait for XML files to begin to reappear in the directory.
After you see XML files appearing on the Index server, repeat steps 2, 3 & 4 on each query server, waiting for XML files to appear before moving to subsequent servers.
After all of the query servers have all been cleared and new .xml files have been generated, proceed to the WFE and Application servers in the farm, following steps 2, 3, 4 and 5 for each remaining server.

8. So what happened if you delete the whole directory? The directory in question is: \Microsoft\SharePoint\Config\<guid>\. So the name of the directory is some kind of identifier. Looks pretty innocent, huh.. it isn’t!
When this happened to me earlier on today, I wasn’t really feeling at ease. The timerjobs didn’t want to run, and no one seemed to know what this guid was. After a few hours of reverse engineering however, I found discovered this was actually the config DB ID. Nice! But where can I find it? Luckily it was not hard to find out. You’ll have to open up the registry and go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0(14.0)\Secure\ConfigDB.

In this key, you’ll find the config DB id. Now all you have to do, is create a directory with this guid and restart the SharePoint Timer service. And you’ll see your XML files reappearing, and soon after your timerjobs restarting. Phuw, that was a close one.. :-)