January 22, 2008 at 2:24 pm
Dear Forum,
Recently our log shipping transaction file could not restore to the secondary server database (database in read only standby).
So, i started again, took a fresh backup and restored over to secondary, due to the importance of this database on the primary after the backup i had to run transaction log files, this applied i then applied to secondary server. when I was ready to start log shipping again. I stopped the transaction backup, made sure all logs were in updated to the secondary.
Verified that both secondary and primary datatabase were the same.
cleared any history to do with previous log shippipng job before it fell over.
network share drives had previously been created with correct permissions.
created the log shippping job again, monitor indicated the the first log copied and was restored, then after that the rest of the transactions logs are copied to the secondary server and would not restore.
14421 out of synch.
Does anyone have any notes on log shipping preparation, this is before we get to the log shipping wizard etc? I would really appreciate a heads up on this.
January 22, 2008 at 11:11 pm
For your ref. 🙂
http://support.microsoft.com/kb/329133/en-us
http://support.microsoft.com/kb/314515/en-us
http://support.microsoft.com/kb/810969/en-us
http://support.microsoft.com/kb/821786/en-us
"More Green More Oxygen !! Plant a tree today"
January 23, 2008 at 7:32 am
I still remember I also had a bizaare problem in the past with log shipping getting out of sync which has something to do about the dates not being updated correctly. Part of the resolution, as I can recall was to update the following columns with the value of @@servername each from primary and secondary instance.
log_shipping_primaries.primary_server_name
log_shipping_secondaries.secondary_server_name columns
You may give it a try, then trigger the tlog backup again, see how it goes.
Can you tell us how your log shipping got broken? Was there a tlog backup piece missing?
Why would you recreate the jobs in the first place?
_____________
Donn Policarpio
January 23, 2008 at 5:14 pm
a set of logs would not restore to the secondary server it was corrupted, simply would not write to the database on secondary.
this happened on a friday night we have a weekly that kicks off at 11.00pm to do the database shrink, optimization, that job did not finish until i had to manually stop the job via sql agents. the next morning early. No error messages on that job. ran it again the next night and worked fine
meanwhile log shipping was out of synch, then i went through the sql logs and found the offending log file not able to restore.
i copied the log over again from primary to see if it would restore, no such success.
and the resf of the logs of course would not apply, so decided to stop logshipping.
get a fresh backup of the database, verify it and restore it to our secondary database, it was fine.
so I am still not how the log file got corrupted.
So decided to setup log shipping again.
January 23, 2008 at 8:04 pm
hi,
i have now recreated the log shipping successfully.
well consider this a bit of a dress rehearsal if we ever go to Disaster Recovery.
thanks for the advice.
Why i ended up creating it, I tried for a few days to resolve, this is our Disaster Recovery Server so its something I had to resolve fairly quickly.
I asked our outside support what they thought and they said if its messed up, get a fresh backup and start again.
now in so doing, I will be probably be better organised for DR testing which is something we are starting to do here on a regular basis.
January 23, 2008 at 8:05 pm
thanks this will help when we have to do DR testing to the secondary server.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply