views:

3841

answers:

12

So our SQL Server 2000 is giving me the error, "The log file for database is full. Back up the transaction log for the database to free up some log space."

How do I go about fixing this without deleting the log like some other sites have mentioned?

Additional Info: Enable AutoGrowth is enabled growing by 10% and is restricted to 40MB.

A: 

Rename it it. eg:
old-log-16-09-08.log

Then the SQL server can use a new empty one.

Fire Lancer
A: 

Have a look here: http://support.microsoft.com/kb/272318

Chris Canal
A: 

Well you could take a copy of the transaction log, then truncate the log file, which is what the error message suggests.

If disk space is full and you can't copy the log to another machine over the network, then connect a drive via USB and copy it off that way.

Marc Gear
+1  A: 

I don't think renaming or moving the log file will work while the database is online.

Easiest thing to do, IMO, is to open the properties for the database and switch it ti Simple logging mode. then shrink the database and then go back and set the DB to Full logging (or whatever logging you need).

Changing the logging mode forces SQL Server to set a checkpoint in the database, after which shrinking the database will free up the excess space.

cori
A more precise terminology may be "simple recovery model".
SeaDrive
A: 

You have the answer in your question: Backup the log, then it will be shrunk. Make a maintenance plan to regularly backup the database and don't forget to select "Backup the transaction log". That way you'll keep it small.

Hugo Riley
+10  A: 

To just empty it:

backup log <dbname> with truncate_only

To save it somewhere:

backup log <dbname> to disk='c:\somefile.bak'

If you dont really need transactional history, try setting the database recovery mode to simple.

TrevorD
TRUNCATE_ONLY option on log backup is discontinued in SQL 2008.
Sean
A: 

If it's a non production environment use

dump tran <db_name> with no_log;

Once this has completed shrink the log file to free up disk space. Finally switch database recovery mode to simple.

This is the old syntax that is now deprecated. BACKUP LOG is the preferred method.
Sean Carpenter
+1  A: 

My friend who faced this error in the past recommends:

Try

  • Backing up the DB. The maintenance plan includes truncation of these files.
  • Also try changing the 'recovery mode' for the DB to Simple (instead of Full for instance)

Cause: The transaction log swells up due to events being logged (Maybe you have a number of transactions failing and being rolled back.. or a sudden peaking in transactions on the server )

Gishu
A: 

As soon as you take a full backup of the database, and the database is not using the Simple recovery model, SQL Server keeps a complete record of all transactions ever performed on the database. It does this so that in the event of a catastrophic failure where you lose the data file, you can restore to the point of failure by backing up the log and, once you have restored an old data backup, restore the log to replay the lost transactions.

To prevent this building up, you must back up the transaction log. Or, you can break the chain at the current point using the TRUNCATE_ONLY or NO_LOG options of BACKUP LOG.

If you don't need this feature, set the recovery model to Simple.

Mike Dimmick
+1  A: 

You may want to check related SO question:

kristof
+1  A: 

Scott, as you guessed: truncating the log is a bad move if you care about your data.

The following, free, videos will help you see exactly what's going on and will show you how to fix the problem without truncating the logs. (These videos also explain why that's such a dangerous hack and why you are right to look for another solution.)

Together these videos will help you understand exactly what's going on and will show you whether you want to switch to SIMPLE recovery, or look into actually changing your backup routines. There are also some additional 'how-to' videos that will show you exactly how to set up your backups to ensure availability while managing log file sizing and growth.

Michael K Campbell
A: 

ether backup your database logs regularly if you need to recover up to the minute or do other fun stuff like log shipping in the future, or set the database to simple mode and shrink the data file.

DO NOT copy, rename, or delete the .ldf file this will break your database and after you recover from this you may have data in an inconsistent state making it invalid.