logshipping not working properly

  • lazy writer

    Ten Centuries

    Points: 1126

    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.

  • SkyBVI

    SSCoach

    Points: 15111

    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

  • crazy4sql

    SSCoach

    Points: 19590

    i will suggest reconfigure the log shipping for that perticular database.

    ----------
    Ashish

  • lazy writer

    Ten Centuries

    Points: 1126

    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...

  • crazy4sql

    SSCoach

    Points: 19590

    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

  • SkyBVI

    SSCoach

    Points: 15111

    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

  • Brandie Tarvin

    SSC Guru

    Points: 172760

    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?

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • lazy writer

    Ten Centuries

    Points: 1126

    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 🙁

  • crazy4sql

    SSCoach

    Points: 19590

    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

  • Brandie Tarvin

    SSC Guru

    Points: 172760

    Okay, how many different backup jobs (and what types) do you have going on with the failing database?

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • bugop

    Mr or Mrs. 500

    Points: 559

    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

  • veena_kedia

    Grasshopper

    Points: 20

    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 12 (of 12 total)

You must be logged in to reply to this topic. Login to reply