June 16, 2009 at 7:55 am
We have log shipping running on our databases to create a warm standby disaster recovery copy. The other day we added a new filegroup and file to one of the databases. After that, the log shipping restore jobs for that database began to fail. The new filegroup was never instantiated on the DR copy.
Question: is there a series of steps we could take that would allow us to add a filegroup to a log-shipped database and not cause log-shipping to fail? Thanks for any advice.
June 16, 2009 at 8:07 am
I'm sure I've successfully added files to a database before, and they have been propagated by log shipping.
Does the same drive letter/folder for the filegroup exist on the secondary server?
June 16, 2009 at 8:17 am
There is nothing about adding a filegroup that should make log shipping fail. Ians suggestion sounds like a good one.
what does table msdb..log_shipping_monitor_error_detail say? Perhaps the log was truncated or a log backup taken outside of the logshipping jobs.
---------------------------------------------------------------------
June 16, 2009 at 8:21 am
there is nothing about adding a filegroup that should make logshipping fail. Ians suggestion sounds like a good one.
what does table msdb..log_shipping_monitor_error_detail say?
Possibly your tran log was truncated or a log backup was taken outside of the logshipping jobs
sorry about double post - problems with t'internet
---------------------------------------------------------------------
June 16, 2009 at 8:39 am
Thanks for the reply.
The source machine's files are on drive F: which does not exist on the target machine. To me this explains why the file wasn't created on the target machine, but not why the filegroup itself wasn't created.
June 16, 2009 at 8:49 am
Here's the error detail:
Directory lookup for the file "F:\SQLDATA\scratch2.ndf"
failed with the operating system error 3(The system cannot
find the path specified.). File 'testdat2' cannot be
restored to 'F:\SQLDATA\scratch2.ndf'. Use WITH MOVE to
identify a valid location for the file. Problems were
identified while planning for the RESTORE statement.
Previous messages provide details. RESTORE LOG is
terminating abnormally.
June 16, 2009 at 12:38 pm
Find out which log backup file is failing, restore that log manually with move and norecovery option, once that is restored, please restart restore job, this should fix your problem.
June 16, 2009 at 12:42 pm
murthykalyani (6/16/2009)
Find out which log backup file is failing, restore that log manually with move and norecovery option, once that is restored, please restart restore job, this should fix your problem.
I'm not sure how we use WITH MOVE option when restoring a log backup. can u give some pointers to that?
June 16, 2009 at 7:26 pm
ps (6/16/2009)
murthykalyani (6/16/2009)
Find out which log backup file is failing, restore that log manually with move and norecovery option, once that is restored, please restart restore job, this should fix your problem.I'm not sure how we use WITH MOVE option when restoring a log backup. can u give some pointers to that?
Its similar to restore database command.
restore log from disk ='backup file' with
move 'logicalfilename' to 'filelocation',norecovery
Here logicalfilename is the new file which was created after which transaction log backup was taken for which restore is failing.
Note:- Move option has to be mentioned only for new files that were created not for files that were restored.
June 16, 2009 at 9:36 pm
Thanks. will try this out today 🙂
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply