I have noticed on a few different development environments that the logging database can grow significantly and on a development machine that is limited with resource this can cause some issues.
There are lots of articles out there which provide step by step guides and on the whole these are very usual, I have included a few below:
I was reviewing some of the articles above but I noticed that even after I followed the process to establish which database tables were taking the space and reduce the logging details my database still wouldn’t shrink to a sensible size. I checked the settings, ran the two timer jobs time and again but it didn’t make any difference.
I tried changing the values to lower and lower values and eventually set it to 1 day but regardless it never changed the database size. When reviewing all the settings by running the Get-SPUsageDefinition command I noticed the item I was updating the retention period for was actually disabled. I ran the command to enable the category, see below
Set-SPUsageDefinition -Identity GUID/NAME -Enable
After this I ran the two usage timer jobs, although I’m guessing you probably only need to run the processing one, and this time when I selected to shrink the database in SQL there were GBs of free space.
So it looks like when SharePoint is doing the processing for the categories it will skip any ones that are disabled. This does make sense but its is important to consider as if you have a lot of old data and disable a particular category for whenever reason the data will stay in the logging database.
Another day and another SharePoint quirk found.