??? User: As with process errors, log shipping is only effective if the user error is identified
before the shipped log backup has been restored. The likelihood of this being
the case is almost completely dependent on the process involved in the notification
of a user error.
Caveats and Recommendations
If I had to make a single recommendation, it would be to ensure that you have a failover/
failback plan in place and to practice that plan on a regular basis. If you??™re lucky, you??™ll
never need to fail over, but as the Boy Scouts say, ???Be prepared.???
Keep these tips in mind when using log shipping:
??? Avoid using any replication method as a disaster-mitigation technique: Yes, this is
me on a soapbox, but I really believe this. (I??™ll gladly argue it over a cup of coffee.)
While log shipping resembles replication as far as architecture, it has a level of
overhead and complexity that worries me. I question its effectiveness as a mitigation
technique.
??? Don??™t forget to monitor: Automated does not mean automatic. Log shipping is so
straightforward to set up, it can be easy to overlook some sort of monitoring technique,
whether it??™s the built-in jobs provided in SQL Server 2005 or alerts.
Pages:
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337