April 2, 2015 at 12:24 pm
We have a primary database 'A' which has a secondary database 'B' setup in "norecovery" mode on another server which works fine.
What I'm trying to do is setup a second secondary database 'C' on a different server and have it be the monitor. Currently the monitor is 'B' so that is being changed to 'C'.
The issue is that after I restore the database on 'C' in "norecovery" mode and bring it up to date with the transaction logs from the ones after the back up I take after the 45 minutes goes by the alert starts to fail with this error:
Execute as user; '' The log shipping secondary database "SERVER C" has store threshold for 45 minutes and is out of sync. No restore was performed for xx minutes. Restored latency is 0 minutes. Check agent log and logshipping monitor information [SQLSTATE 42000] (Error 14421). The step failed.
It appears that the secondary database 'B' is still operating correctly.
I'm at a loss as to what is going wrong since both the LSCopy_xxx and LSRestore_xxx jobs are completing successfully.
April 2, 2015 at 12:41 pm
Are you sure that the correct log files are being copied to both server B and C? It almost seems like a file isn't getting to C, and then the next log backup is beyond the 45 minute delay for some reason.
If you look at the job history, are all the same files being copied and restored on B and C until you get the error?
April 2, 2015 at 12:50 pm
I ship the log files to a shared location.
The copy destination is a directory local to each of the secondaries.
The copy locations have the same file size and time stamps. I know it's copying them correctly.
I'm really confused because the Copy and Restore jobs are successful. How could they be successful but the alert job fails?
April 7, 2015 at 8:08 am
vomster37 (4/2/2015)
We have a primary database 'A' which has a secondary database 'B' setup in "norecovery" mode on another server which works fine.What I'm trying to do is setup a second secondary database 'C' on a different server and have it be the monitor. Currently the monitor is 'B' so that is being changed to 'C'.
If you want server C to be just the LS monitor why are you restoring a database there?
vomster37 (4/2/2015)
I'm at a loss as to what is going wrong since both the LSCopy_xxx and LSRestore_xxx jobs are completing successfully.
Just because the jobs are successful doesn't mean there's no issue. Carefully check each line of output in the job history, you'll likely find the jobs have a message buried there somewhere
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply