What is SharePoint configuration cache? What is its importance?

The configuration cache is a location, where configuration information stored in the configuration database is cached on each server in the farm. Caching the data on each server prevents from having to make SQL calls to pull this information from the configuration database. If this becomes corrupt for any reason, you can face issues with Timer jobs and other unexpected issues.

What is the default behavior? How can you reset the Cache?

At first, isolate the issue! Before further ado, let me show you what the default behavior is.

    Go to your Services console, and change the Startup type of Windows SharePoint Services Timer to Manual, and stop the service.
Navigate to…

Server 2003 location: Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\GUID
Server 2008 location: Drive:\ProgramData\Microsoft\SharePoint\Config\GUID

    Delete all files EXCEPT Cache.ini.
    Open the cache.ini and you will find a number in this text file. Change this number to 1 and save this file.
    Now, start the Windows SharePoint Services Timer. Very soon you will start seeing XML files in this folder.
    After some time [a few minutes], you should be able to open Cache.ini file and find that the value 1 would have changed. This is the default behavior. The SharePoint cache is now built on the server.

What to do if the Cache.ini is not getting updated?

    Repeat the reset exercise mentioned above on any other machine, and see if the issue happens on another server. If Cache.ini is not getting updated even on another server then in that case your configuration DB might be corrupt. I checked with the SQL profiler, and the Config refresh job is pulling all the objects from this table Objects inside your SharePoint_Config. Notice that there are total of 478 records in this table [in my farm].

    In the Cache folder I have 479 objects [cache.ini included]

    Please don't try to fix your table or pull records directly from the Config database! The screenshots above is just to show you how things look like, when they work. That way you can figure out what is wrong, when it is actually broken.
    What if the cache is not getting updated only on 1 server and works well on other servers?
    I encountered this issue a few days ago, and trust me, it was not that easy to fix. At one point we were almost on the verge of rebuilding the problematic server.
    However, here is what we did to fix it.
    Started with the ULS logs and found that RefreshCache method was throwing an exception.

OWSTimer - Exception in RefreshCache. Exception message :Exception has been thrown by the target of an invocation.

OWSTimer - The timer service could not initialize its configuration, please check the configuration database.  Will retry later.

    Tried with Fusion Log as mentioned in this post, but it didn't help either in isolating the bad DLL.
    Finally, tried to remove the problematic server from the farm using PSConfig and got another error suggesting a third party DLL causing this issue.
    Removed it from the GAC.
    Ran PSConfigUI again to detach the server from the farm, and this time it succeeded.
    Joined it back to the farm, just to find that the DLL was installed again. Hence, uninstalled it back. And finally, everything was up and working again!

I hope this helps someone!

Until next time,
Rahul