Post reply

In Log shipping process, Primary Server’s Primary Database is crashed after taking backup, then how you bring the secondary server into Online without any data loss?

  • March 31, 2011 at 12:47 am

    #237062

    Hi,

    In Log shipping process, Primary Server’s Primary Database is crashed after taking backup,

    then how to bring the secondary server into Online without any data loss?

    can any help out this

  • April 1, 2011 at 12:43 am

    #1306304

    Hi,

    Manually run the copy job on secondary server.

    & after that restore the copied backup on to secondary server with recovery option...

    Note: in log shipping minimal data loss will be there.

    Regards

    Subha......

  • April 1, 2011 at 9:11 am

    #1306556

    If it were me in this situation, you have a mandatory down time, production is stopped until you can get this database up to speed on the secondary server.

    1) Turn off all application servers that are sending requests to the primary database, isolate the database server from any more transactions.

    2) Notify management and users of the issue (maybe a webpage that states when you'll be back up)

    3) I believe that I'd then determine when the last T-Log backup job completed sucessfully on the primary and secondary servers.

    4) Like the guy above me stated, run the restore job manually on secondary server to make sure that any log files that didn't get inserted in the the secondary server are now populated there.

    5) Now we need to assess the condition of the primary database server - can you get it online?

    6) Can you perform a Differential restore from your last DR backup files? Can you restore the database ( in a relatively short time ) back to within your Recovery Objective Points (period of allowed data loss, sometimes that could be within 15 minutes or less) ?

    7) If the primary DB is offline, corrupted beyond repair, it would take too much time to try and get the primary backup, then your left with your backup files on the secondary and restoring everything you can there and then execute the restore script with recovery switch.

    8) change the connection strings to your application / web servers and come back online (with managers permissions for the data loss)

    9) If you had any difficulty here, then you need to re-evaluate your DR plans, make adjustments and hope that your lack of planning prior to this disaster doesn't put you back in the job market!

    Job # 1 of a DBA = protect the data, be able to recover from these types of losses to within your allowed recovery SLA's.

    Hope this helps.

Viewing 3 posts - 1 through 2 (of 2 total)

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