Log File Growing Uncontrollably

Eric the Red · #1 (**permalink**) 11-08-12, 14:00

Hi,
My log file was 2x the size of my actual Database which is obviously too large on a DEV box. I know that my data can be easily recovered so I actually do not even want/need a log file.

After doing some investigation I found that I should turn my database into "Simple Recovery Mode" and after this I used a few scripts to truncate my log file. Things at this point looked great!

Unfortunately my log File is still growing even with this 'simple recovery mode'. So how do I stop this craziness from occurring?

I even unchecked the box 'allow autogrowth' on the database! However, I eventually get errors when creating records in the system because it complains about running out of room in the log file.

Code:

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

Please help me stop this madness

Eric the Red · #2 (**permalink**) 11-08-12, 20:49

86 views. Are there no experts on the SQL logging?

Any help would be appreciated

papadi · #3 (**permalink**) 11-08-12, 21:56

If this is becomming urgent/critical, suggest you open an issue with MS support. Yup, it is expensive, but gets answers . . .

MCrowley · #4 (**permalink**) 11-09-12, 09:04

Are you certain you have the right database set to simple recovery mode?

Code:

 select recovery_model_desc
from sys.databases
where name = 'your database name goes here'

You can also look for open transactions in the database with the DBCC OPENTRAN command, or even do what the error message says, and look at the log_reuse_wait_desc column in the sys.databases table.

Thrasymachus · #5 (**permalink**) 11-09-12, 14:35

is this new behavoir? has something new been recently deployed? I am going to go with MCrowly on this one. Someone is doing some large volume transaction(s), "heh why not just update all billion rows at once" or perhaps some long running large volume ETL operation that probably needs to be rewritten.

Eric the Red · #6 (**permalink**) 11-09-12, 15:03

Quote:

Originally Posted by Thrasymachus

is this new behavoir? has something new been recently deployed? I am going to go with MCrowly on this one. Someone is doing some large volume transaction(s), "heh why not just update all billion rows at once" or perhaps some long running large volume ETL operation that probably needs to be rewritten.

You are exactly right. We are testing DB queries and creating/inserting 5-10 Gb tables at a time. But having the db in Simple recovery mode. I understood that it would not use the transaction log in this scenario.

Could I turn off the transaction log? I haven't seen a simple way to do this.

MCrowley · #7 (**permalink**) 11-09-12, 16:04

Having the db in simple recovery mode does not turn off the log (that can not be done by design), it just does not keep the log records after a transaction has been committed. Check to see if you can configure the load to batch the inserts (say every 50-100,000 rows).

Eric the Red · #8 (**permalink**) 11-11-12, 11:52

Thank you, I will use Batch Insert instead.

Pat Phelan · #9 (**permalink**) 11-12-12, 12:38

Dump your log file into oblivion, then do a full backup to maintain a safety net... Add a new log file that has an appropriate size to your database, and empty the existing log file into it. Drop the empty log file that you just evacuated. I recommend doing a second full backup at this point, even though it isn't strictly necessary. At this point you've restored sanity to your database files.

Logging can NEVER be turned off while SQL Server is running (except if the database is made read-only). Logging can be minimized, but there is no way to completely stop logging for a functional database.

The SIMPLE recovery mode will allow the CHECKPOINT to clear unused log rows. This is usually fine on a development database, but I don't recommend it on either QA or production databases.

-PatP

Internet Services

Web Development

Digital Marketing

Consumer Tech