|
Suppose a primary database(which is logshipped) gets corrupted. Does it follow that the logs shipped to the secondary database also gets corrupted once it gets restored via a job step in a log shipping process? Is there a way to stop the restore job once the database corruption is detected? What other options are available once corruption rears its ugly head in a log shipped environment?
(comments are locked)
|
|
The secondary database will import logs up until the last usable point. If the corruption is file / server based, then the log import will not work on the secondary database, and that will be close to the 'last known good state'. However, if your corruption is 'a user decided to delete all the rows by accident' then that will be merrily shipped across to your secondary location.
(comments are locked)
|
|
In addition to @Matt Whitfield's answer, though, you can mitigate (to some extent) against these issues by putting a delay on the restores into the target server. If you know that your user-deleting-everything corruption has just occurred, then you can (hopefully) stop the log restore, and extract what you need to rebuild the data, and then carry on. Assuming your users are honest enough to tell you within the log ship/restore timeframe, that is. Adding to @ThomasRushton - make sure the copy is not delayed and the logs are off the originating server.
Feb 25 '11 at 05:21 AM
Blackhawk-17
(comments are locked)
|
