November 2, 2018 at 10:41 am
Hi gurus,
For the past two days, one production DB's log grows to the point that fills up the disk where all logs are stored. I have this message in the SQLlog:
The instance of the SQL Server Database Engine cannot obtain a LOCK resource at this time. Rerun your statement when there are fewer active users. Ask the database administrator to check the lock and memory configuration for this instance, or to check for long-running transactions
This DB is in simple recovery mode. Is there something I could do to find out why is the log growing so uncontrollably? Yesterday when it first happened, I reverted any changes made to SPs that use transaction statements but today, I have the exact issue.
As always, any help is greatly appreciated.
Regards,
November 2, 2018 at 10:45 am
Any large data imports, data updates or deletes occur? The transaction log is still used when a database uses the SIMPLE recovery model.
November 2, 2018 at 10:46 am
Thomas Rushton
blog: https://thelonedba.wordpress.com
November 2, 2018 at 10:50 am
Thanks gurus!
Doesn't the incremental backup sets the checkpoint? this DB has full backups every friday night and daily incrementals. While this is a production DB, there aren't many apps/services transacting on it and that's why we have this schedule.
Should I move it to Full recovery and do log back ups daily?
November 2, 2018 at 11:11 am
No, do transaction logs hourly if, for example, you can only afford to lose an hour of data in the event of a disaster.
Checkpoints occur automatically every minute or so.
I recommend you search "managing transaction logs" and do some reading.
John
November 2, 2018 at 11:19 am
Suggest you start with this: https://www.red-gate.com/library/sql-server-transaction-log-management
Thomas Rushton
blog: https://thelonedba.wordpress.com
November 2, 2018 at 11:28 am
The one thing that I've found most often causes notable log file growth in my databases is Index maintenance, which may also be related to your lock issue.
November 2, 2018 at 2:35 pm
Gurus,
Thank you for your infinite wisdom, and Thomas in particular for the recommended link, that was a very interested read and time very well spent. I found the culprit using what I've learned from that ebook and my log's growth is back to normal.
As it turns out, there is a Windows service that runs a series of SPs and one of those SPs was calling a procedure that did not have the Commit statement. It had the Rollback but no commit anywhere. Further investigation revealed that one of the developers was testing a new implementation in the lab server and accidentally that implementation was brought over to the production box.
If it wasn't for Thomas' recommendation, I am not sure I would've found it. So, Thomas, I owe you a Beer 😀
Once again, thank you everyone!
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply