June 25, 2008 at 5:21 am
Hi,
Has anybody encountered the following error:
The file .trn is too recent to apply to the standby database
I have log shipping set up between the primary and standby database. We had experienced an issue with ports that prevented us from accessing the server. In the meantime the restore job failed and continues to do so.
I've checked the log_shipping_monitor_secondary table on the primary table to check which log was last restored. The next tlog generated on the primary and all subsequent logs have successfully been copied to the standby server however, it won't apply the log that was generated after the last restored log as would be expected.
It fails with the above error.
Does anybody know why this error occurs and is there a way to resolve it without rebuilding the standby database?
Thanks in advance 🙂
June 25, 2008 at 6:30 am
have you tried to restore all outstanding logs in sequence starting with the last log to be restored on the standby database.
Gethyn Elliswww.gethynellis.com
June 25, 2008 at 7:06 am
Check the Log for the Date-time the error appeared and start applying all the logs Manually, until you are at the current stage.
This Error is due to the LSN, which Logshipping encountered, the LSN should match the last Log LSN Sequence.
Maninder
www.dbanation.com
June 25, 2008 at 7:07 am
How do you apply the logs manually in SQL Server 2005
June 25, 2008 at 7:14 am
You canuse a script look up restore log in bol nd be sure to use the no recover option or you can use management studio.
Gethyn Elliswww.gethynellis.com
June 25, 2008 at 7:24 am
Some like this:
RESTORE LOG (Database Name) from disk = 'path of .trn file'
WITH NORECOVERY
Use NORECOVERY Untill you are on the last LOG File, then replace WITH NORECOVERY with 'WITH RECOVERY'
Maninder
www.dbanation.com
June 25, 2008 at 7:26 am
Thank you Mani, I'll give that a try. 🙂
June 25, 2008 at 7:45 am
Do you still need to use the recovery options on a standby database? Is the status not always in a restore state?
I tried the restore log with norecovery against the database but got the following error:
Msg 3102, Level 16, State 1, Line 1
RESTORE cannot process database 'db name' because it is in use by this session. It is recommended that the master database be used when performing this operation.
June 25, 2008 at 7:55 am
June 25, 2008 at 7:59 am
If you are restoring logs to the standby "log-shipped" database then you do not want to use the WITH RECOVERY option. Using this option will mean you can apply no further logs to the database and will have to reconfigure log-shipping again. just use the NO RECOVERY option.
Gethyn Elliswww.gethynellis.com
June 25, 2008 at 8:11 am
Thanks both. I tried the command against the master database again (tried earlier but got an error). It allowed me to apply the log before the one that it's complaining about.
However, when I tried to apply the log that the scheduled restore job errors on. I got this:
The log in this backup set begins at LSN 14239000000012400001, which is too recent to apply to the database. An earlier log backup that includes LSN 14239000000001600001 can be restored.
Is there a way to check which log needs to be applied from the lsn?
June 25, 2008 at 1:01 pm
How do toy backup the LOG?
There should be several T-Logs available gright, if you are using a maintenance plan to BAck them up.?
Manually Sort/check the logs by Datetime appended at the end of the Filenames.
Maninder
www.dbanation.com
June 26, 2008 at 2:35 am
Issue is resolved.
Unknown to me, a colleague took an adhoc transaction log backup on Monday and saved it to a different location to where the transaction logs are stored. Sure enough, the time stamp of the adhoc tlog backup was in between the log that was successfully applied and the log it would not apply believing there was an earlier log to apply. :rolleyes:
I just couldn't understand it yesterday when it was complaining about this archive log, it didn't exist on the primary or standby server.
Anyway, I was able to apply the adhoc tlog this morning and the subsequent logs have applied successfully too.
Thank you so much for your help 🙂
June 26, 2008 at 2:45 am
Hi debs i was going to suggest that a log missing....:)
Glad that you have resolved your issue.
Gethyn Elliswww.gethynellis.com
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply