In the past, when I’ve set up log shipping, it was primarily as a DR device, designed to get copies of logs to another server ASAP. The idea being that if we had an issue on the production server, we could switch to the secondary server quickly and lose minimal working time for the company.
To that end me, and most everyone I knew, restored those logs ASAP. If you ran log backups every minute, you didn’t want more than a couple of minutes before you could bring the secondary online and start moving clients over.
That’s a good process, though to a large extent it has been superseded by database mirroring for quick recovery on another server. Mirroring also includes the ability to automatically direct clients to the mirror server, which isn’t something log shipping can do.
However you don’t always want to restore those logs immediately. Not all disasters require you, or even force you, to switch servers. Consider those “accidental” disasters. What do you do if a user deletes all customers, or the DBA accidently sets all orders to the same quantity because they forgot a WHERE clause?
If you restore immediately, those changes are likely applied on the secondary server before you can even contact the DBA, or make a remote connection to the secondary server and shut off the log shipping process.
If, however, you have, say a 3rd database, one that delays restoring logs for an hour or two, you’ll still have that original data on that server. Even if you’ve made some changes in the last few hours, you could “catch up” all the logs except for the one where you made the mistake, and then move that data over with an SSIS Wizard package.
That might save you a lot of time, or explanations, when you do make a mistake. And rest assured, sooner or later you will.
