Recently, I had to truncate 3 TB table from the availability group. Since truncate deallocates extents, it does not generate as much log compared to delete (logs individual records). However, I wanted to research this as we have synchronous AG and did not want to flood the secondary replicas with too much log.
I came across an article from Paul Randal about this exact issue. Thanks Paul. Link to Paul’s article here https://www.sqlskills.com/blogs/paul/the-curious-case-of-log-generated-during-a-drop-table/
To confirm this, I executed the truncate command on test server ( it does not have AG) and tracked the log backup size. Since, there was no database activity at that time, all the growth should be related to this event. The math worked out very well and it was exactly in the range as mentioned in Paul’s blog. I also read the log backup contents to verify.
So, we executed this task on prod during non-peak hours and secondary replicas were able to catch up without any hiccups.
This article is for future reference. Thanks Paul for the wonderful article. Timing could not have been more right and the math was exact.
SQL Server Repository 