Potential causes and solutions for the transaction log in database being full [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 8 years ago.

Improve this question

In the data access layer of my teams ASP.NET application, I run stored procedures against our database through the use of the .NET SQLClient. After adding new code to allow an insert operation on the database, I tested the code, and received the following exception:

The transaction log for database 'DBName' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

I verified that I receive the same message when attempting insert operations from within MS SQL Server Management Studio. I was concerned because I recently added three two triggers two the database to perform some insertion of data based on insert and update to certain tables, and I thought potentially I had incurred an infinite loop or something of that nature.

However, based on other instances of this problem online, it does not seem like a problem generally caused by triggers or a spinning query. I queried against the log_reuse_wait and log_reuse_wait_desc columns and returned the following:

2 | LOG_BACKUP

Also, the query SELECT [name], recovery_model_desc, log_reuse_wait_desc
FROM sys.databases returns:

name | recovery_model_desc| log_reuse_wait_desc

DBName|   FULL            | LOG_BACKUP

In which the first column is log_reuse_wait and the second is log_reuse_wait_desc. Based on the definitions for the codes on msdn , I need to perform a log backup and then the log can be automatically truncated, allowing for further operations on the database. Is that a correct assumption? Is this something that could be caused by incorrectly coded triggers, or is more of a routine maintenance task, incurred by numerous transactions on the database?

EDIT:

The query select type_desc, size, max_size from sys.database_files returns:

   type_desc | size | max_size
1| ROWS      |  512 | -1
2| LOG       |  64  |  -1

Answer 1

If your database is in FULL recovery mode, the log is not truncated (truncated is a poor word, I wish they'd chosen something else) until a log backup is performed. Basically, when you put a database in FULL recovery mode, you are telling SQL Server that you want point-in-time recovery. In order to do that, SQL Server needs the full log chain from the last full (or differential) backup, and in order to do that, it does not re-use ('truncate') log space until you have backed the log up.

This is a routine operational matter for databases that are in FULL recovery mode. If you do not need point-in-time recovery, then set your database to SIMPLE recovery mode - this will automatically reuse log space, but you will only be able to recover to your last full/differential backup.

If you do need point-in-time-recovery, then you need (well, your DBA team needs) to set up a maintenance plan that performs a log backup at regular intervals.