Results 1 to 9 of 9
  1. #1
    Join Date
    May 2008
    Posts
    97

    Log File Growing Uncontrollably

    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

  2. #2
    Join Date
    May 2008
    Posts
    97
    86 views. Are there no experts on the SQL logging?

    Any help would be appreciated

  3. #3
    Join Date
    Oct 2009
    Location
    221B Baker St.
    Posts
    487
    If this is becomming urgent/critical, suggest you open an issue with MS support. Yup, it is expensive, but gets answers . . .

  4. #4
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,539
    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.

  5. #5
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,577
    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.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  6. #6
    Join Date
    May 2008
    Posts
    97
    Quote Originally Posted by Thrasymachus View Post
    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.

  7. #7
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,539
    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).

  8. #8
    Join Date
    May 2008
    Posts
    97
    Thank you, I will use Batch Insert instead.

  9. #9
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    14,948
    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
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •