The "log" is a misnomer, IMHO. It's more of a change tracking file for the db than a log.

You shouldn't, in general, read the log. Especially now with auditing built into the product. Really the log is there to ensure that changes made to data are completely written to disk and committed in case power goes out, something corrupts, etc. Changes are written to the log, then once that is hard on disk, the changes are made to the data file.

In terms of recovery, you use the log backup file to do a log restore. Typically if I backed up at 1:00am once a day, and then did a log backup every hour, when I did a restore, I'd restore:

- the full backup (data as of 1:00am)

- log backups, in order, starting at 2:00am (possible 1:00am) and continuing through failure.

If I crashed at 8:02am, I'd have one full backup and then 7 log backups to restore. If you look up the RESTORE LOG command, you'll find syntax.

In terms of your system, I think that you are not running log backups, which you need to do. You should schedule those when you set things up, and if you want an easy way to do it, use maintenance plans. You can delete log files older than a couple days if space is an issue. This will allow all the "records" in the log file to be marked as backed up and then that space is reused. Your log file will need to be the size of all the changes to data that occur in between log backups. If you run log backups hourly, you'll get an idea of how many changes are made to data in an hour.

Does this make sense?