We have a highly transactional database that's mirrored (and thus in recovery mode = 'FULL') so we have to perform regular transaction log backups between full database backups.
The transaction log backup grows very fast. We have plenty of space, but the issue is that as the day goes on (until the next full backup), the media set (I think that's the correct terminology) on disk grows and grows. And for each subsequent transaction log backup, we see start pegging read i/o on that disk.
The behavior seems to be that we seek to the end to append the latest transaction log backup by reading the entire file.
Are there ways to mitigate this behavior? My colleague says to rotate the media set (i.e., transaction log backup file) more frequently to reduce the max size. I also explored having the media set consist of multiple media families (e.g., three different files on disk). But my colleague postulates that this would not solve the problem because ultimately the same amount of seeking will have to be done (albeit on three smaller files). Perhaps if these files were on separate disks we might see a win.
Anyway, am I correct in my analysis with regards to large media set on disk requiring lots of read i/o to successfully backup subsequent transaction logs?