July 12, 2012 at 1:43 am
Hi,
I had configured log shipping before one month.it was working fine.secondary server had shut down due to some reason.when i restarted secondary server restore job is not working.error is coming like
*** Error: The file 'D:\UJJSECONDARY\UJJDRDBLOGFILE\UJJLIVEDB_20120710072002.trn' is too recent to apply to the secondary database 'UJJDRDB'.(Microsoft.SqlServer.Management.LogShipping) ***
2012-07-12 12:40:01.75*** Error: The log in this backup set begins at LSN 746518000000024600001, which is too recent to apply to the database. An earlier log backup that includes LSN 746517000000213200001 can be restored.
RESTORE LOG is terminating abnormally.(.Net SqlClient Data Provider) ***
please tell me how to solve this..
July 12, 2012 at 2:53 am
The LSN's are out of sync, it looks like either a manual transaction log backup was taken and not shipped or something deleted the transaction log before it was copied and replayed.
If you have backups of your transaction log backups, find the missing log(s) and replay them on the secondary server, if not you will need to reinitialise logshipping, by performing a Full/Diff backup depending on your backup routines.
July 12, 2012 at 3:08 am
jugo.pinky (7/12/2012)
Hi,I had configured log shipping before one month.it was working fine.secondary server had shut down due to some reason.when i restarted secondary server restore job is not working.error is coming like
is your primary server has any history clean up task scheduled which distrupts the log shipping?.
anthony suggested is correct.
Regards
Durai Nagarajan
July 12, 2012 at 3:12 am
sp_help_log_shipping_secondary_database @secondary_database = ''
Run that on the secondary server in master and it will tell you the last restored file, then you can investigate what went on.
July 12, 2012 at 3:30 am
ya it will delete old logfiles
July 12, 2012 at 3:33 am
my last restored file is:'20120710070000.trn'
next one is ='20120710072002.trn'
while restoring this file '20120710072002.trn' it is showing that it is too recent
July 12, 2012 at 3:34 am
Yes it is normal for it to delete log files.
The issue you have is that something or someone has done a manual transaction log backup or deleted a trn file which they shouldnt have causing the issue.
Its like this
Primary server has backed up TX1, TX2, TX3, TX4
Someone/Something deletes TX3 or Someone/Something manually created TX3 and put it in a different folder
Secondary server has copied TX1, TX2, TX4
Secondary server has restored TX1, TX2
Secondary server cannot restore TX4 as it needs to first restore TX3 which is cant as the TX3 file doesnt exist any more or is not in the right folder to be copied.
July 12, 2012 at 3:38 am
anthony.green (7/12/2012)
Yes it is normal for it to delete log files.Secondary server cannot restore TX4 as it needs to first restore TX3 which is cant as the TX3 file doesnt exist any more or is not in the right folder to be copied.
Anthony is there a way to alert the admin that a transaction log file missing or manual transaction log done?
Regards
Durai Nagarajan
July 12, 2012 at 3:42 am
Dear Anthony,
actually i configured this in client server.so i dont know whether they deleted or not.
but can u pls tell me what to do now
July 12, 2012 at 3:45 am
Either find the missing transaction log backup or re-initialise logshipping from a full/diff backup depending on the database backup routines.
July 12, 2012 at 3:57 am
thanx anthony
July 12, 2012 at 4:58 am
jugo.pinky (7/12/2012)
Dear Anthony,actually i configured this in client server.so i dont know whether they deleted or not.
but can u pls tell me what to do now
1. Disable log shipping jobs on primary & secondary server
2. Take a full or differential backup of the primary database
3. Copy it to secondary server
4. Restore the copied backup file with "no recovery" or "standby" whatever you had configured earlier
5. Enable log shipping jobs on primary & secondary
Log shipping should resume fine after this.
July 12, 2012 at 5:19 am
thanx a lot divine
July 12, 2012 at 6:46 am
if your secondary ever shuts down again for long periods either keep a copy of the backups that havent been restored or perform a differential on the primary and apply to the secondary
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
July 12, 2012 at 7:08 am
How about delaying the log files deletion say after a day .
Regards
Durai Nagarajan
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply