Thank you SQLRNNR. sorry, I am trying to explain better way:
There is a log file 100 GB. New transaction occurs and it shows 125 GB log file backup on E:\ (got it from Log shipping primary backup at 1 pm).
According to Gila total log file would be 125+1 GB(99% free on 100 GB) total 126 GB.
I think you are confusing things.
Your log backup was 125GB. That would be the size of the transaction log that was in use. Just because the backup was 125GB, does not indicate that it was a single transaction. It very well could have been a 124GB transaction.
Next If I take a transaction log backup, will transaction log backup make log file (.ldf) smaller or just makes VLF to 0 but size remains 126 GB?
Will there be again 99% free space on 125 GB log file (.ldf)?
If you take another log backup, the size of that backup could be anything from 1k to 125GB. When a log backup occurs, it does not shrink your file. It backs up the used space, and truncates that space internally. This does not reduce your VLF to 0, each vlf that was backed up and cleared is marked ready to be used by a new transaction. Your free space will be anything between 100% free and 0% free.
at what point I reclaim disk space? just say my .ldf file is now 500 GB but 99% free, shouldn't I claim at least 400 GB space for different purpose because .ldf is only occupied 5 GB (1%)?
You don't reclaim the disk space via log backups. The log backup reclaims the space internally for use later on.
If the log grew to 125GB, it is likely because the log needs to be that size.
Like Gail has already said, Shrinking the log will likely just mean it will regrow later. Constant growing and shrinking of the log is not recommended and will lead to performance issues (think slower IO for starters).
_______________________________________________I have given a name to my pain...MCM SQL Server, MVPSQL RNNRPosting Performance Based Questions - Gail Shaw
Learn Extended Events