SQL Server Performance Forum – Threads Archive

LS restore fails

Hi,
I have a LS setup which fails with this error which is in LS history: [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4330: [Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set cannot be applied because it is on a recovery path inconsistent with the database.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally. I tried restoring the primary database backup on secondary and sync’d it up, it works for sometime and backup, copy is happening successfully, its only the restore which fails. Now I am pretty sure if restore the primary backup on secondary it will work now and fail after sometime. Has anyone has ideas on this. Please help me out with this. Thanks in advance for all your help
Rajesh

Disclaimer: "I haven’t done log shipping." With that said the error message would imply to me that perhaps the log file is being written to a certain path structure that you are not restoring it from or something on the target server. Is that a possibility? We recently evaluated a mirroring solution across TCP/IP and the copy worked, but the restore failed because the path was incorrect. The database expects its log file to be in a given path, which was not the same that we were using. Hopefully someone who has used log shipping will know exactly what the issue is.

Are you performing Log shipping using wizards or doing a script based?
Confirm service pack level on both the SQL servers.
I suggest to apply full backup from primary server to secondary server by replacing the data drives and files on SQL database and then configure log shipping to port the transaction logs. Satya SKJ
Contributing Editor & Forums Moderator
http://www.SQL-Server-Performance.Com
This posting is provided â€œAS ISâ€ with no rights for the sake of knowledge sharing.

I think (it’s been some time before I saw this error) that the problem has to do with the secondary server trying to restore a transaction log before that transaction log backup has finished being written to. Either way, try this and see if it helps: Edit the log shipping configuration and specify a load time delay of 1 minute. This instructs the secondary server to wait until the log backup file is 1 minute old before it attempts to restore it. This is setting set to 1 minute, by default, at Microsoft so even if it doesn’t fix the problem it’s a good idea to have anyway. If that doesn’t fix the problem, try restoring your seconday database in NORECOVERY mode instead of STANDBY mode (unless you’re already doing this). Hope that helps, Karl Grambow www.sqldbcontrol.com

]]>