Post reply

Problem with log shipping

  • May 18, 2005 at 8:10 pm

    #164625

    Hi,

    I am trying to setup log shipping on a SQL server 2000 database. The backup and copy are suceeding but the load is failing.

    The load process is throwing the following error

    [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4326: [Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set terminates at LSN 1397000000706800001, which is too early to apply to the database. A more recent log backup that includes LSN 1544000001263500001 can be restored.

    [Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.

    I noticed that the copy process is copying all transaction log files for the past week to the backup destination folder everytime the copy runs.

    I will greatly appreciate any help you can provide.

    Thanks. 

    Thanks,
    SR

  • May 19, 2005 at 6:10 am

    #559815

    Backup your original database and restore it into destination server without recovery, then continue the log shipping.

  • May 19, 2005 at 10:56 am

    #559931

    Thanks for response Allen but I did samething but  still I am getting same error.

     

    Thanks,

    Sree

    Thanks,
    SR

  • May 20, 2005 at 1:17 am

    #560108

    Is this standard log shipping that comes with SQL Server Enterprise, or a "home built" log shipping system?

     

    --------------------
    Colt 45 - the original point and click interface

  • May 20, 2005 at 6:54 am

    #560168

    I am going to take a SWAG here that this is a 'home built' application. You had mentioned that the copy was taking all log files from your source directory every time. Does it also apply all of the log files every time? If it does you could run into the error  that you are seeing. The other possibility is that you have restored from a more recent backup and are applying logs from prior to that backup.

    SQL Server log shipping takes care of tracking the log files that have been copied and applied already and also giving you a delay in case you run into corruption issues.

    Good Luck

    Eric

  • May 20, 2005 at 8:15 am

    #560210

    Hi,

     

    Its a home built application.

    Everytime trasaction logs runs it copies all transaction logs from shared directory to destination directory.It have some old transaction logs on source side.I guess I need to clear all the old transaction logs from the source and start fresh backup.

    Please correct me if I am wrong.

     

    Thanks,

    Sree

     

    Thanks,
    SR

  • May 20, 2005 at 8:26 am

    #560215

    There are some examples and discussions on this site about home built applications. If you are going to have this application running in the backgroud to for a standby server you will probably need to create a tracking table that monitors logs as they get taken, copied and applied this way you are not duplicating work. There is no need to re-copy log files that have already been applied to the destination server.

    Eric

  • May 20, 2005 at 8:57 am

    #560232

    Ok, a home built system is much easier to manage. We have this setup for two servers at our site. It's all basically contained in one table, 2-3 stored procedures and handles full, differential and tran log backups.

    Now I'm doing a lot of guessing here because you haven't provided much information about how your process operates. First, when you take the transaction log dump, I'm presuming it's done in a stored procedure ?? and you have a filename that you're creating ?? Once you've got the backup file, your next step would be to move the file to a path that's accessible to both servers, pass the filename and the new path to a stored procedure on the standby server. The stored procedure uses these parameters to restore that specific file.

    A failure in the backup generates an alert which you can action and a failure in the restore generates an alert that you can action.  In our setup, if an error occurs the first thing that happens is the log shipping job gets disabled. This prevents any further backups from happening and stops files from getting out of sync. If we want to continue doing backups while the standby is unavailable, then we change a field in the table and the restore part of the operation is skipped. 

    You've also got the added bonus of the backup files sitting on a third un-related server so if both SQL Servers go down the backup files are still accessible.

     

    --------------------
    Colt 45 - the original point and click interface

  • May 20, 2005 at 12:58 pm

    #560329

    Thanks for all help.I deleted the old transaction log files from the source and destinatio and no my log shipping is working fine.

     

    Thanks,

    Vidya

    Thanks,
    SR

Viewing 9 posts - 1 through 8 (of 8 total)

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