It's well-written and I thought I understood, but when I tried to apply what I learned, I found something that didn't make sense. We have a 1.8G database with a 1.5G log - which sounds way too big, except I remember when it was up to a 3.5G log.I ran the command, DBCC Loginfo, which showed 399 rows, all with status 0. I assumed that meant there'd been no activity since I ran the log backup, so I went in and updated some of my timesheet, checked the LogInfo again - and there was no change.Of course, the transactions would have been committed, so it's not like they're required for a rollback, but they haven't been backed up. The space they're using shouldn't be reusable at this point, should it? That should make it state 2, which should make the status on one of those record = 2. Am I missing something? And anticipating the first question, yes I made sure that I was doing the command on the correct database.

Have you treble-checked . I'm pretty sure one of those 399 rows must have a value of 2 (active). As soon as you create a database, some info gets written to its log file and one of the VLFs will be active.

USE master;goCREATE DATABASE NewTest;

USE NewTest;goDBCC LogInfo;

As for space resue - this does require a log backup if the database is in FULL recovery model, but not in SIMPLE.

Damn if you weren't right. I ran it again, and then, just to humor you of course, I began moving through 399 records one at time. At the 294th click of the down arrow, I found myself staring at a 2.This series has helped me in another way. I think the reason the log file is so huge and at the same time so empty is that I was asked to rebuild all indexes about a month ago. I will be adding to the job some code to switch it to bulk insert recovery and then back to full after the rebuild is done. After I finish the Level 7 article and hopefully find the best code to shrink it.