Sean Wallbridge
Ran into this on Friday at a customer. Unexpected as the database logging file size shouldn’t have been changed in the first place but it could happen elsewhere. Hope this helps others.
What
- Event ID: 5586
- Error Posted: Unknown SQL Exception 9002 occurred. Additional error information from SQL Server is included below. The transaction log for database ‘ContentDB02’ is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
So What
Sucks don’t it? SharePoint can’t write anymore. From the SharePoint side, certain site collections couldn’t add/edit content but SharePoint pages would still render. When writing, a generic correlation ID would appear so the clue was in the Servers Event Logs only.
The reality/issue was that the database in question was changed from its default logging database maximum size of 2,097,152 MB to 2,048MB (2GB). Sure enough, on the file system, the LDB file for the database was showing 1.9GB or so. Not sure who changed this from the default but that is another story. As the logfiles are well managed and checked, it was recent activity (huge volumes) of transactions within a matter of a day or so that caused it to climb.
Now What
While there is a bunch of ways to approach this, short and sweet was in order as I had a class to teach. 😉
- First off was to shrink the logging database file (in SQL manager, shrink the database and the file, first of course setting its database recovery type to Simple)
- Set the database limit back to the defaults … as it shouldn’t have been changed in the first place in this circumstance