Symptoms
The .usage logs are never deleted. There should typically be no more than 6 .usage files at any given time, but when you have this problem, you may find hundreds or thousands of usage logs in the logging directory.
You'll see errors like this in the SharePoint ULS logs when the Usage Import timer job runs:
OWSTIMER.EXE (0x51A0) 0x59E4 SharePoint Foundation Usage Infrastructure a5rv High Failed to delete usage log file 'E:\Logs\ServerName-20130701-2117.usage' after data import. Exception: System.IO.IOException: The process cannot access the file because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileInfo.MoveTo(String destFileName) at Microsoft.SharePoint.Administration.SPProvisioningAssistant.MoveFileOrDirectory(FileSystemInfo fi, String newPath) at Microsoft.SharePoint.Administration.SPProvisioningAssistant.DeleteFileOrDirectory(FileSystemInfo fi) at Microsoft.SharePoint.Administration.SPUsageLogImporter.ImportUsageLogFiles(List`1 usageLogFileList)
Other symptoms include:
• Missing or incomplete Web Analytics data
• The “Microsoft SharePoint Foundation Usage Data Import” timer job never completes.
• The “Timer Service Recycle” timer job is never able to actually restart the timer service. It tries to pause the Usage Data Import job and cannot, so after ten minutes it skips the recycle.
• Memory bloat (leak) within owstimer.exe. You may see the timer service consume much more memory than normal. Restarting the timer service will bring it back to normal, but it will build up again over time.
• The "Diagnostic Data Provider: Trace Log" timer job intermittently does not import the ULS log data into the Logging database.
Cause
This happens when Windows updates KB 2775511 or KB 2682011 or KB 2882822 are applied to the SharePoint servers.
Resolution
The fix is in the December 2013 Cumulative Update for SharePoint 2010.
If you look at the description for the Foundation package (which is included in the SharePoint server package) here: http://support.microsoft.com/kb/2849981, you will see this description for one of the issues that are fixed:
"After you install hotfix 2775511 or hotfix 2682011 on a SharePoint Server 2010 server, the Usage Provider (.usage) files are not deleted from the file system. Additionally, the .usage files keep growing."
This is a somewhat generic summarization of the problem that does not include all the known symptoms, but it does fix the issues described in this KB.
Here is the link to the KB and download:
http://support.microsoft.com/kb/2849971
More Information
In case you cannot quickly install the December 2013 Cumulative Update, there are two independent workarounds that should get you by until you can:
1. Set up a scheduled task to manually recycle the timer service (at least) once a day -- every 6 hours would be better. You can use a PowerShell command like this to recycle the service:
restart-service -Name SPTimerV4
Then you just need to set up a scheduled task to run it every 6 hours on every SharePoint server in the farm. When the timer service is manually recycled, the open handles to the .usage files are released, and they will be automatically deleted when the next instance of the Usage Data Import timer job runs (by default every 30 minutes). There should be no need to manually delete the files.
2. Uninstall KB2775511 or KB2682011 or KB2882822 if they are installed -- This is not recommended, but it is an option.
Note about the "There should typically be no more than 6 .usage files at any given time" statement: You will have a max of 6 .usage files at any given time as long as the default settings are in place. Two settings that will affect this are:
-- Schedule for the “Microsoft SharePoint Foundation Usage Data Import” timer job. By default it runs every 30 minutes. If the schedule has been increased to say, once daily, then you will have many more .usage files.
-- UsageLogCutTime. By default this is 5, which means we create a new usage log every five minutes. With the import job running every 30 minutes. We should compile no more than 6 files before the import job runs, imports the data, and then deletes the files. You can check this value by running Get-SPUsageService.
