Comments on: Deleting the transaction log

By: Gail

Gail — Mon, 14 May 2012 23:51:41 +0000

‘Just’ the transaction log? The log is one of the more critical portions of the database because it is what ensures durability and consistency. Any database platform that supports durability has some form of transaction log

It is not an audit log or just record of what happened. It’s every bit as important (if not more) than the data files

By: RJ

RJ — Mon, 14 May 2012 10:26:47 +0000

I had lost my ldf file and neither had the DB, nor the backup. The workaround/hack you mentioned here worked successfully from the recovery mode. Muchas gracias!

PS: On a sidenote, this is exactly why I hate closed/proprietary systems. Who in their frigging mind ties the workability/dependence of a complete database with just its transaction log!

By: Gail

Gail — Sat, 05 May 2012 05:45:20 +0000

Please note that restoring from backup should always be considered first and is a much safer way of getting the database back than rebuilding the log.

By: HappynThankful

HappynThankful — Sat, 05 May 2012 03:42:52 +0000

Big Thank You! Worked perfect! A little data loss, but way better than all lost!

By: GSquared

GSquared — Tue, 04 Oct 2011 08:38:16 +0000

Thanks again for this article, Gail. Came in handy for me tonight, dealing with a log file corrupted during a server move.

By: shannon

shannon — Tue, 10 May 2011 21:15:39 +0000

Ok thanks Gail, will do!

By: Gail

Gail — Tue, 10 May 2011 20:48:32 +0000

Short answer: You can’t back a log up if the DB is in simple recovery, and log truncation happens every time a checkpoint runs.

If you want to go into more detail, maybe post a question over at SQLServerCentral.com and you’ll get lots of good (and probably some not-so-good) advice.

By: shannon

shannon — Tue, 10 May 2011 20:19:35 +0000

Gail, great article! I always love reading your blog.

One question I do have though as I am trying to educate myself on Transaction Logs as much as I can, what is the best practice for managing Transaction logs in the Simple recovery mode? I use this on my reporting datawarehouse that supports SSAS Cubes and SSRS reporting. It is only loaded once a night at 2am in the morning and no modifications are made to it during the day so no point in time restores would be necessary. However during the night the transaction log does grow during the ETL process. I leave it alone as I am in no danger of running out of space and it is not that big, but none the less I wonder if I should be truncating it by backing it up? What is the best practice in this situation? I can’t seem to find much of that info on the net

By: Gail

Gail — Wed, 04 May 2011 18:26:59 +0000

As I pointed out in this post, no, not always. If the database was not cleanly shut down, the attach will fail. See the second example in this post.

The sp_attach procs are deprecated, the replacement is the CREATE DATABASE … FOR ATTACH or CREATE DATABASE … FOR ATTACH_REBUILD_LOG that I used

By: Kaminda

Kaminda — Wed, 04 May 2011 11:05:21 +0000

Gail, We can do a single file db attach using sp_attach_single_file_db when the log file is deleted isnt it?