Log Truncation and Log shrinking

I see a lot of post in SQL Server forums and groups asking about log truncation and shrinking , when i started my career as DBA this is was on of the main doubt i had , so let me  explain you the difference between log shrinking and log truncation

Log Truncation

We all know that log file is made of multiple Virtual Log Files, transaction log file is a wrap around file, when database is created transactions are logged at the beginning of log file and new log records are added at the end of logical log file towards the end of physical log file ,

So the VLF are reused in a cyclic fashion and the process of making a VLF which is no longer required as free or marking it as reusable is called log truncation

If there is no reusable free space available then Physical log file will expand by adding new VLF if auto growth  is enabled for log file else if  you will get an error 9002 which says that your transaction log is full

When is a log truncated

In SIMPLE recovery model log is truncated by a CHECKPOINT

In FULL and BULK recovery model log is truncated by a LOG BACKUP

So lets have a look at it, i have a database called 'test' it have 10 VLF and i made all the VLF as active by running some transactions , refer the snapshot below , i have used the command dbcc loginfo(  ) to see the the details of VLF inside my log file, here status = '2' means they are active

So why VLF's are not reused ??? Lets check it by using below query

  select log_reuse_wait_desc from sys.databases where name='test'

As the output says its waiting for logbackup to mark VLF's as reusable as i said earlier for a database in full or bulk recovery model a log backup is required to truncate the log file , so here this database is in full recovery model so lets take log backup and see what's going to happen

 BACKUP LOG [test] TO  DISK = N'D:\MSSQL\Backup\test.trn' 

Now lets run dbcc loginfo and could see that 9 VLF is marked as reusable that means log file is truncated
     

Log Shrinking

So log truncation will mark VLF as reusable and this won't reduce the physical size of log file , Shrinking log file is the process of releasing space back to OS from the end of physical log file .

Shrinking  is not suggested to be done frequently until you are sure that your log file won't grow back to the size from which we are shrinking as log growth is an expensive process

So lets see the size of log file of the database 'test' after truncation using the command
dbcc sqlperf(logspace)

Here we can see that log truncation have created free space inside disk so now lets shrink the log file to release unused space back to disk using the below query

USE [test]

GO

DBCC SHRINKFILE (N'test_log' , 0)

GO

now lets check the log file space , you can see that log file have shrink to the initial value

Enabling Backup compression in server level

Backup compression was one of the attractive feature introduced in SQL Server 2008 Enterprise edition which is available in all edition from SQL Server 2008 R2. Compressed backup saves us both disk space and backup time with a cost of CPU consumption :)

We can take compressed backup by specifying with compression option when we take backup like mentioned below

BACKUP DATABASE [Database name] 
TO  DISK = N'Path' 
WITH COMPRESSION

Instead of specifying  compression  in each backup lets see how to make it default in instance level

1)Using SSMS

   Right click on the Instance name->Database setting and check the compress backup check box and now its done

2) Using script

      We can use the below script to enable backup compression by default in server level

  EXEC sys.sp_configure N'backup compression default', N'1'

  GO

  RECONFIGURE WITH OVERRIDE

   GO

So from now it is not required to specify with compression in each backup and if we want to take a uncompressed backup we need to specify WITH NO_COMPRESSION

So lets  see how much time and disk space compressed backup save, i will show you this my showing the values of a compressed and uncompressed backup i took

So from the above output its pretty clear  how attractive is compressed backup and i would suggest compression  to enabled in instance level as soon as we install server

Could not clear 'DIFFERENTIAL' bitmap in database because of error 9002

While i was doing some testing in my server i got an interesting error while taking a full backup

System.Data.SqlClient.SqlError: Could not clear 'DIFFERENTIAL' bitmap in database 'test' because of error 9002. As a result, the differential or bulk-logged bitmap overstates the amount of change that will occur with the next differential or log backup. This discrepancy might slow down later differential or log backup operations and cause the backup sets to be larger than necessary. Typically, the cause of this error is insufficient resources. Investigate the failure and resolve the cause. If the error occurred on a data backup, consider taking a data backup to create a new base for future differential backups. (Microsoft.SqlServer.Smo)

This was really an interesting error for me and had  no idea why i am getting this error while taking backup ,but i noticed one thing in the error message ' Typically, the cause of this error is insufficient resources' , Resources ehhh , whats thats??

So i started with basic check

Is there enough CPU ?? Yeah there is plenty enough 

Memory?? Enough free memory is there

Disk ?? yess.. enough to take another 30 backups

Then what else????????????????????

I missed one important thing in error message 'error 9002'

When log file is full database engine  throws error 9002

Yes there it is.... my log file is full and auto growth is disabled

  

But how come log space will make my backup fail?? anyway lets  give a try and initiated a log backup

OK there is no issues with my log backup and it completed successfully.. now  let me try for a full backup

There  goes my backup status 10 20 30 40 50 60 70 80 90 100 and completed successfully :)

So how come log space will cause backup failure??

So my understanding of this error we faced is that clearing differential bit map will be a logged operation so in our case there was no space to write to log file also we know a checkpoint will be triggered  when we take a backup and during checkpoint log records from log buffer will be written to log file so in this case since our log file was full and checkpoint was not able  to write log records to disk and once we took log backup there was enough space in log file and every thing went smooth then