I have a testdb. the recovery mode is on simple and I am back my system up with veeam. Now how can i check if my log from the testdb was being truncated after the backup or not?

I just found some commands like DBCC SQLPERF(LOGSPACE). But with that i just see the usedspace.


In simple recovery mode the log gets truncated automatically when checkpoint is issued. Now when you run DBCC SQLPERF(LOGSPACE) and your log is more than 70% full then you can assume that your log is not getting truncated because a checkpoint is supposed to be issued when the log grows to 70% in simple recovery.

If you suspect that your log is not getting truncated in simple recovery you can use sys.databases, log_reuse_wait_desc columns to find out why the last log truncation did not work.

If you wanna dig a bit deeper, you can use dbcc loginfo and check the status column to see which virtual log records are active and in that way figure out if its getting truncated or not

  • Indeed, [log_reuse_wait_desc] provides the key info here, together with dbcc sqlperf(logspace), you can get accurate picture of your log status, i.e. whether it is truncated or not. For example, if your dbcc sqlperf(logspace) shows continuous growth of usedspace, you need to check log_reuse_wait_desc to see what prevents the log space being recycled back. – jyao Dec 14 '16 at 4:47

If all your databases are in SIMPLE recovery model, you should not care about log truncation. With this model, space is automatically reclaim from the transaction log when checkpoints occurs (when datas are written to disks). Nevertheless if your .ldf is growing too big, you still have the possibility to use the DBCC SHRINKFILE command in order to reduce his size.

You should take care about log truncation when you database is in FULL recovery model. the Microsoft doc says : "Under the full recovery model or bulk-logged recovery model, the inactive part of the log cannot be truncated until all its log records have been captured in a log backup. This is needed to maintain the log chain "

Here an example of the "log chain" from severals inheritance backups :

enter image description here

Note the first_lsn and last_lsn values. The log chain is consistent


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.