1

I was log shipping. I disabled the jobs, and restored the database on the secondary machine and used them for a bit. Now I want to undo this. I don't care about history or syncing, I simply want to turn log shipping back on and carry on my merry way.

I enabled the jobs, but 'running' them (right click > start job at step, if that's how you run them) just pops up and says success but nothing happens.

I am unsure of how I can start the log shipping going again. I tried deleting the databases from the secondary machine but that didn't help either.

Any ideas? Surely it's a simple thing?

Edit: Still at a loss. Says the job was successful but nothing happens, no database is created. It was working fine before I took the databases out of recovery on the secondary machine.

Improve this question

1 Answer 1

Reset to default
1

You need to take another full backup from the production database and restore it to the log shipping server in NORECOVERY mode. Then the log shipping should be able to restart. You may need to remove the log shipping and put it back by going through the wizard depending on how you set it up.

Improve this answer
5
  • 1
    That could be a pain in the arse if I have to remove and re-add every single log shipping task on the server whenever there's a failover. Log shipping originally worked without any databases on the secondary, it created them. Perhaps I just need to write a big script to remove all the tasks and recreate them or something... in this day and age:S
    – NibblyPig
    Commented Jul 8, 2014 at 16:20
  • When a failover happens you wouldn't need to do that, but this wasn't a failover event. When you failover the LSN chains aren't broken so the two databases are still in sync. When you brought the backup databases online you broke the LSN chain so you have to start the restore process over.
    – mrdenny
    Commented Jul 8, 2014 at 16:24
  • Why does starting the restore process over involve removing log shipping, then going in and typing all the details in again, eg. schedule, paths to files, target database etc.?
    – NibblyPig
    Commented Jul 9, 2014 at 8:10
  • Because I don't know how well the logshipping that comes with SQL Server is going to handle the database being deleted and manually restored into no-recovery. It might work just fine, or it might give you all sorts of problems as older logs can't be applied. Either way at the very least you'll need to backup the production database and restore it to your secondary server.
    – mrdenny
    Commented Jul 9, 2014 at 20:34
  • I've figured it out, you are correct. I restored the database in NORECOVERY and log shipping could resume. When it was broken, the source server would run the job and report no errors and that everything was fine, but delving into the job on the target server being shipped to, it showed there was an error restoring it. It was a bit hidden!
    – NibblyPig
    Commented Jul 10, 2014 at 8:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.