Log Chains and SQL Server Transaction Log - sanity check

I'm helping with a rather ad-hoc disaster recovery, and we've restored a database backup from a few weeks ago and then restored t开发者_开发问答ransactions from a transaction log backup.

We did this using SQL Server Management Studio - right click on database, restore full backup but leave in recovery mode, right click again, restore transaction log, etc.

I'm now trying to verify that we had no gaps in our logs. Is it safe to assume that if the SQL Server Management Studio allowed me to restore the logs without errors, then there were no gaps in the logs (e.g. the log chain is complete)?

In other words - would SQL let me restore logs if there were gaps? I assume it would warn me or stop me in that case.

Thanks for any help you can offer ....

We're on SQL 2005 but I think the rules about log chains are similar through all versions.

---

According to the document Working with Transaction Log Backups from Microsoft:

If a log backup becomes missing or damaged, start a new log chain by creating a full or differential database backup and then backing up the transaction log to start a new log chain. We recommend that you retain transaction logs backups that come before a missing log backup, in case you ever want to restore the database to a point in time within those backups. For information about how to help protect your backups, see Security Considerations for Backup and Restore.

and Creating Transaction Log Backups states:

If a transaction log is damaged, work that is performed since the most recent log backup is lost. This highlights the importance of putting the log files on fault-tolerant storage.

My free reading of this is: Considering a lost file a kind of file damage, if Management Studio or any other tool allows you to restore the logs without errors, you can be sure the log chain is complete until the last transaction log backup you're applying. You must be sure it is the last transaction log backup available for that database, but that is other thing to think about.

If you don't trust my reading (and the documentation is not too clear on this point), you can make a simple test to be sure: Say you have 10 transaction logs to apply... deliberately delete the 7th (or a random, but not the first nor the last) transaction log, and try your disaster recovery method.

If you get a error saying something like "a transaction log file backup is missing", you can be sure and trust me.

---

You are correct. SQL will not apply a transaction log backup if it can't be applied, you would have gotten an error.