I don’t know if this was a one-off thing, but I figured I’d share just in case. It’s even possible someone turned these jobs on without notifying anyone..though nobody has fessed up yet! If I run through another SPF13 install soon I’ll be sure to update the post.
I have confirmed that all copies of SharePoint Server 2013 do NOT enable the Data Diagnostic Timer Jobs by default. I have also confirmed that a RTM SharePoint Foundation 2013 install has the same behavior. Recently I ran through a SharePoint Foundation SP1 install (ISO pulled from VLSC)..and after a few weeks noticed the Usage Logging database was growing out of control! Looking over the timer jobs I saw that all diagnostic data provider timer jobs were turned on:
That explains it..These jobs are normally disabled as they aggregate a lot of different information/logs from SharePoint and puts it into one central location/database. We usually either turn these on for “health checks” or when troubleshooting issues and want a complete snapshot of the farm. Turned them off..Trimmed up the usage data using this method: http://blogs.msdn.com/b/manhar/archive/2012/04/17/how-to-reduce-the-size-of-logging-database-or-how-to-purge-the-old-data-from-logging-database.aspx
Note: The link above cleared up only about 10GB of data..leaving me still with a gigantic Usage Logging database. Apparently there isn’t any way I could find (without SQL queries) to clear the Diagnostic Data out of the DB. It did trim some items – Page Requests, Feature Usage, etc. You could either wait for the retention period to kick in..or if the data isn’t important you can create a new Usage database and delete the old one using the Set-SPUsageApplication PowerShell cmdlet explained here: https://technet.microsoft.com/en-us/library/Ff607641.aspx