Flush BLOB cache in SharePoint


To flush the BLOB cache from web application

  1. Open a SharePoint Management Shell or ISE
  2. Copy the following code and paste it into a text editor, such as Notepad
  3. $webApp = Get-SPWebApplication "<WebApplicationURL>"
    [Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)
    Write-Host "Flushed the BLOB cache for:" $webApp
    
  4. Replace <WebApplicationURL> with the URL of the Web application whose BLOB cache you want to clear.
  5. Save the file, and name it FlushBLOBCache.ps1.

 

To flush the BLOB cache from ALL web application

           $wa = get-spwebapplicaton
           foreach($wapp in $wa)
            {
            [Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($wapp)
            Write-Host "Flushed the BLOB cache for:" $wapp
            }

Distributed Cache errors in the ULS log


Summary

We noticed a ton of Distributed Cache errors in the ULS log. There were actually 3,670 of the errors below within 30min;

Issue

Out of the box, AppFabric 1.1 contains a bug with garbage collection. AppFabric 1.1 is a prerequisite for SharePoint 2013 as it is the underlying technology used by the Distributed Cache service.

Affects

SharePoint Server 2013 + March Public Update

Symptoms

Due to the bug, some requests to Distributed Cache time out. In our case, users authenticated to a SharePoint using formed based authentication were unexpectedly logged out of the site because the check for their logon token timed out. As well, requests from the search cache timed out after three seconds increasing the time to load search results.

A review of the ULS logs showed a number of distributed cache exceptions :

Unexpected error occurred in method ‘GetObject’ , usage ‘SPViewStateCache’ – Exception ‘Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode:SubStatus:The request timed out.. Additional Information : The client was trying to communicate with the server : net.tcp://contoso.com:22233 at Microsoft.ApplicationServer.Caching.DataCache.ThrowException(ResponseBody respBody, RequestBody reqBody) at Microsoft.ApplicationServer.Caching.DataCache.InternalGet(String key, DataCacheItemVersion& version, String region, IMonitoringListener listener) at Microsoft.ApplicationServer.Caching.DataCache.<>c_DisplayClass49.b_48() at Microsoft.SharePoint.DistributedCaching.SPDistributedCache.GetObject(String key)’. e7a6759c-378f-40e7-26a8-be00a48fcde1

Token Cache: Failed to get token from distributed cache for ‘0#.f|provider|username’.(This is expected during the process warm up or if data cache Initialization is getting done by some other thread).
Exception: ‘Microsoft.SharePoint.DistributedCaching.SPDistributedCacheClientRequestTimeOutException: Communications with the cache cluster has experienced a delay past the timeout value,please increase the RequestTimeout of the client. —> Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode:SubStatus:The request timed out..
Additional Information : The client was trying to communicate with the server : net.tcp://contoso.com:22233
at Microsoft.ApplicationServer.Caching.DataCache.ThrowException(ResponseBody respBody, RequestBody reqBody)
at Microsoft.ApplicationServer.Caching.DataCache.InternalGet(String key, DataCacheItemVersion& version, String region, IMonitoringListener listener)
at Microsoft.ApplicationServer.Caching.DataCache.<>c__DisplayClass49.b__48()
at Microsoft.SharePoint.DistributedCaching.SPDistributedCache.GetObject(String key) –
— End of inner exception stack trace —
at Microsoft.SharePoint.DistributedCaching.SPDistributedCache.GetObject(String key)
at Microsoft.SharePoint.IdentityModel.SPDistributedSecurityTokenCache.GetObject(String key)
at Microsoft.SharePoint.IdentityModel.SPTokenCache.TryGetCachedToken(String cacheKey)’.

Unexpected error occurred in method ‘GetObject’ , usage ‘Distributed Logon Token Cache’ – Exception ‘Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode:SubStatus:There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable, which could be caused by busy network or servers. For on-premises cache clusters, also verify the following conditions. Ensure that security permission has been granted for this client account, and check that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the serialized object size sent from the client.).
Additional Information : The client was trying to communicate with the server :

DistributedSearchResultsCache::Get() – Failed due to exception = ‘Microsoft.Office.Server.DistributedCaching.SPDistributedCacheClusterDownException: Cache cluster is down, restart the cache cluster and Retry —> Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode:SubStatus:There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable, which could be caused by busy network or servers. For on-premises cache clusters, also verify the following conditions. Ensure that security permission has been granted for this client account, and check that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the serialized object size sent from the client.).
Additional Information : The client was trying to communicate with the server

Resolution
  1. Apply AppFabric Cumulative Update 3AppFabric Cumulative Update 4, or a later AppFabric CU to all servers in the farm
  2. Add backgroundGC key to DistributedCacheService.exe.config file on all cache servers
  3. Restart AppFabric Windows Service on all cache servers
  4. Restart Distributed Cache SharePoint service on all cache servers
  5. Reset IIS (IISRESET) on all servers in the farm

If the issue persists, you may need to increase timeout and connection values:

  1. Increase distributed cache client settings for affected containers using the Set-SPDistributedCacheClientSetting cmdlet.
  2. Increase security token service values with Get-SPSecurityTokenServiceConfig
  3. Restart AppFabric, and Distributed Cache on cache servers

 

References:

https://www.habaneroconsulting.com/insights/SharePoint-2013-Distributed-Cache-Bug

http://support.microsoft.com/kb/2800726/en-us

http://msdn.microsoft.com/en-us/library/hh351248(v=azure.10).aspx

Recover Sharepoint 2013 databases from suspect mode.


This Post courtesy to: 
Original Post from: Blogs.cloudshare.com

I restarted my SharePoint server, opened Central Administration and encountered the following error:
Server Error in ‘/’ Application
Runtime Error
Description: An application error occurred on the server.
01 - SharePoint 2013 Server Error in Application
In order to troubleshoot this issue I had to check couple of thing:

  • Make sure SQL Server services are up and running
  • Make sure the IIS application pools are started
  • Review Windows logs and gather more information about the server. I noticed the following event:

SQL Database ‘SharePoint_Config’ on SQL Server instance ‘C4968397007′ not found. Additional error information from SQL Server is included below.
Cannot open database “SharePoint_Config” requested by the login. The login failed. Login failed for user ‘DC07SQLSvc’.

02.1 - Windows logs
This event made me suspect something is wrong with my SQL Server. I opened SQL Server management studio and noticed that some of my most critical SharePoint databases are not accessible and set to suspect mode. 02 - SharePoint 2013 databases are in Suspect mode
What is a suspect mode in SQL Server database?
Suspect mode might be caused by many reasons like unavailable or corrupted database files, hardware failure etc.
Don’t worry! This situation is reversible.
Here’s a quick guide of how to recover your SharePoint databases from suspect mode:
Open your SQL Server management studio and execute the following queries one after another:

  • Run the following query. sp_resetstatus command will turn off suspect flag on the database.

EXEC sp_resetstatus ‘SharePoint_Config’;

After executing this query you’ll see the following warning. Don’t worry, this doesn’t mean you did something wrong.
04 - SQL Server reset status of database warning

  • The next step is to set the database to an Emergency mode. This can be done by executing following query:

ALTER DATABASE SharePoint_Config SET EMERGENCY

After executing this query your database should look like this:
06 - SharePoint_config database is set to emergency mode
Once we set the database to an Emergency mode it temporarily becomes a Read Only database.

  • Execute the following query in order to check the logical and physical integrity of the objects in the database.

DBCC checkdb(‘SharePoint_Config’)

  • To complete the process, run the following queries:

ALTER DATABASE
SharePoint_Config SET SINGLE_USER
WITH ROLLBACK IMMEDIATE
DBCC CheckDB (‘SharePoint_Config’, REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE SharePoint_Config SET MULTI_USER
DBCC CheckDB (‘SharePoint_Config’)

Repeat this action for each one of the affected databases.
09 - Everything is back to track
I ran some basic tests to make sure my SharePoint server is working properly again, looks like everything is back to track.

January 29th, 2013 | Author:  | Filed under: CloudShareDev / TestSharePoint | Tags: