September 20, 2010 at 7:15 am
Hi
Recently I have setup the Logshipping on a server for two databases and destination server also same for both DBs. The problem was one DB is Logshipping fine but another Logshipping database seems wired. While copy job copying the files from the primary server it is verifying all the files existed on the secondary server and writing in the job history ‘ the files is already existed on secondary server and skipping the copy file. This is the way it was verifying all the files instead of copying the files where it was left last time. And also while restoring the database it is trying to restoring the yesterdays already restored files and saying ‘skipped log backup file’.
Anybody has got experienced this issue. Here SQL Server is 2005 SP3
I would appreciate your assistance.
September 20, 2010 at 7:54 am
Pls check if the Sql service account in secondary server has sufficient permissions to the shared folder in which the log backup is being copied to inorder to perform restoration...check the job history in secondary server to find the exact error message and post it
Regards
Sushant Kumar
MCTS,MCP
September 20, 2010 at 8:04 am
i will suggest reconfigure the log shipping for that perticular database.
----------
Ashish
September 20, 2010 at 9:57 am
Hi
I reconfigured the Logshipping twice but no luck 🙁
and moreover the copy job is doing well it is able to copy the log files the only problem is copy and restore jobs are missing somewhere its logic.
because both are behaving in same manner. copy job supposed to start copy the files from previously where it was stopped but what it was doing is.. it is trying to copy all the files from the primary server instead of only new files that is why copy job alway trying to copy all the files and when it finds that file in secondary server it is skipping that file and continuing until finding the new files which are not copied to secondary server.
the restore job also doing the something it is trying to restoring the all existed files but should start restoring from where it was left last time restoration.
any ideas please...
September 20, 2010 at 10:06 am
copy job will not make any mix up with restore.
the only thing you need to make sure that you doing the restoration in sequence.
lastest full backup
latest diff backup(if applicable)
start from first log backup which was taken just after full/diff backup.
keep restoring with norecovery or standby option.
Can you try to do the complete restore process with tsql code and post the error you getting.
----------
Ashish
September 20, 2010 at 10:36 am
Try this way:-
- stop log shipping
- took a new FULL backup of the primary database
- restore this to the 2ndary database (with standby option)
- delete ALL .trn file on primary and 2ndary servers
- Reconfigure log shipping
Regards,
Sushant
Regards
Sushant Kumar
MCTS,MCP
September 20, 2010 at 11:56 am
It does sound like the log chain for the second database got broken by changes on the Primary server.
What's changed on the Primary server, second database? It would have been around the same time as when you started seeing problems. Did anyone change Recovery Model from Full or Bulk-Logged to Simple? Or something else?
September 21, 2010 at 3:15 am
Hi All,
thanks for the replying.
There was no single error message. I reconfigured many times like taking the full back up and applying on secondary server but no luck. It is successfully restoring the log on secondary server but only the problem is it before restoring the recent log files it was trying to verifying the all the existed log files(here we are deleting 3 days only files only) so that is why the restoring was taking long time and something happens with copy job as well 🙁
September 21, 2010 at 3:21 am
few questions to dig the problem further :-
is your log are getting over written by new?
if you think its the copy step then try to configure some other location to copy the log files and restore using that location.
if all effor fails then can you try to restore that to some other test server if you have any?
----------
Ashish
September 21, 2010 at 6:18 am
Okay, how many different backup jobs (and what types) do you have going on with the failing database?
September 21, 2010 at 3:45 pm
I think the problem is with your copy job:
Why not try this:
1. from the primary create a logshipping folder
2. Have a job to copy current tran log to this folder, delete older one after a new one is copied
3. have a nother job copy the current tran log from logshipping folder to secondary
January 21, 2011 at 7:18 am
Hi we have exactly same issue, I restarted new thread just now didn't see yours before, got ur after googling:-)
did you resolve issue, our LS is working perfectly fine just copy and restore try all files and thus the process takes too long. from time to time I remove old files on primary shared so copy doesn't start from begining again and same at secondary so restore doesn't try restoring all files again:(
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply