November 14, 2011 at 8:00 am
In case of a Log Shipping, I'm aware that if you do if you do T-Log backup maybe through maintenance plan on the same machine (Primary), it will break the log backup chain on the secondary machine that receives the log.
However, in case of DB mirroring, if you do T-Log backup on the Mirroring Principal, does that break the log chain on the Mirroring Partner?
November 14, 2011 at 8:05 am
There's no 'log chain' on a mirroring partner. Mirroring doesn't depend on log backups to copy transactions across (as log shipping does). You can't take log backups on a mirror DB (it's not online), only on the principal.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 14, 2011 at 8:10 am
GilaMonster (11/14/2011)
There's no 'log chain' on a mirroring partner. Mirroring doesn't depend on log backups to copy transactions across (as log shipping does). You can't take log backups on a mirror DB (it's not online), only on the principal.
Ok.
So it means that it will not mess up the mirrored database on the Mirroring partner if you do T-Log backup on the mirroring principal. Right?
November 14, 2011 at 8:18 am
Yup.
But if you don't do log backups, it will mess up your principal. Log full errors aren't fun and the only thing that marks the log reusable in full recovery is a log backup.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
April 4, 2012 at 7:32 am
Just to clarify 1 point: there is a log chain on the mirror database. It has the exact same log chain as the principal. Without it, you wouldn't be able to fail over and bring the mirror online. Also, database mirroring will not allow you to do anything that will break the log chain. If you try to do something that would break the log chain, you will receive an error that you can't do that while the database is mirrored.
Another point: Taking a manual log backup of the log shipping primary does not break the log chain. what causes log shipping to fail is that the automated processes may not copy and restore that log backup causing a gap in the log sequence number on the secondary. You can remedy this by manually restoring (with NORECOVERY) the manual log backup on the secondary or by taking a differential backup that spans the missing gap and restoring it (with NORECOVERY) manually to secondary. After doing this, log shipping processes will be able to resume normal processing.
If you do need to take an out of band backup, it is recommended that you use the COPY_ONLY option as this generates the backup without updating the last LSN backed up.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply