SQL Centre of Excellence

Recently, I noticed some very interesting side-effects from a mirror that was in a suspended state.

When I went to rebuild the mirror, I had to play catch up, with DB Backups, Differential backups and TLog Backups…nothing new here.

I copied the backup across (it took nearly 6 hours). The Differential was just about half the size of the database, and differentials were taken every 2 hours.

I then broke the mirror just before the differential backup was due to be taken.

And – the next differential was TINY – a fraction of the size of the previous differential – it copied across straight away, and I had the mirror up and running in minutes.

So, I looked at the Differential backup history, and could see that differential backups when mirrored (but suspended) appear to be significantly larger than differential backups when there is no mirror.

So I am going to state what was probably obvious to everyone (except me!): When your mirror becomes suspended, the differential backup appears to hold on to everything that is required for the mirror to catch up, which can result in unmanageably large files. So, breaking the mirror early can result in a speedier recovery to full mirroring.

Also, worth noting was that the full backup when the mirror was in the suspended state was 50% larger than full backup with no mirror (mirror suspended for a week before I was asked to look at it).

So, a suspended mirror can cause issues other than the obvious loss of High Availability – it can have a relatively significant impact on backup size, storage and of course network bandwidth as a result.

blog comments powered by Disqus

Page List

Page List