February 1, 2011 at 4:04 pm
I'm trying to get some clarification on logshipping...
I've set up logshipping between primary server and secondary server, with the log files being saved to a shared folder on another server. First question:
I can't find anything referencing WHY the log files need to be saved on another server, and then copied over to the secondary server. Is it a best practice?
Because (I'm assuming) those files are saved on a separate server and then copied via the Copy job on the secondary server over to the secondary server, I'm seeing a bit of latency involved. In order to mitigate this latency, couldn't I somehow set it up so that the log files are being saved to a folder directly on the secondary server, exclude the whole Copy job altogether, and allow the Restore job to just restore from those orignal log files? (I wouldn't want to keep the copy job going, then I'd have two copies of the log files on the secondary server -- not necessary) I thought this might help with some of the latency by "removing the middle man", so to speak.
Am I missing something? Is there a way to actually do this using the log shipping GUI? (could I set up the Backup job to copy over to a folder on the secondary server, and then just disable the Copy job once it's created?)
Help! I'm a bit of a newbie in this area so bear with me....
Thank you!
February 1, 2011 at 11:24 pm
You could do that, but I wouldn't recommend it. The most important step in the process is creating the log backup because you may need to use it in a recovery scenario. Plus you want that part of the process to be optimized for speed because it's hitting the live server.
Yes, you can disable the copy job, but again, I'd advise against it.
February 1, 2011 at 11:50 pm
tacy.highland (2/1/2011)
I can't find anything referencing WHY the log files need to be saved on another server, and then copied over to the secondary server. Is it a best practice?
As it is configured this way on your server, there could be some reason for this like something related to space shortage that might exist in your current set up. There might be some unknown reason as to why somebody had configured like this on your current set up. It is advisable to test thoroughly before making any quick changes on set up.
M&M
February 2, 2011 at 8:50 am
Thanks for the responses. Let's see if I can clarify a few things...
I'm the one who set up the log shipping, based on what I've read and been told, so I can change it up however necessary. I've been asked to try to eliminate the middle server part of the equation in order to reduce the latency involved in copying the backups from the middle server over to the secondary server. It seems the GUI automatically assumes there's a third machine involved which will store the backups, but...why is this necessary? The backups are still being stored on a machine, it's just that they'd be stored directly on the secondary server instead of the middle server. They'd definitely still be used in case of a recovery scenario (they'd still be available in the scenario I described). I can understand the point of not saving the backups on the primary server (if the primary server goes down, you can't get to those log backups to do a recovery) but don't see the logic behind not just saving the backups directly on the secondary server. (what's the drawback I'm not seeing?) And for optimizing, that's exactly what I'm trying to do in this situation. It seems to me that the middle machine in this process just slows things down rather than optimizes anything (latency)...?
I'm wondering if anyone else out there has a similar set up to the one I threw out there: excluding the middle server to store the backups, and just saving them directly on the secondary server to which they're applied....? And if so, how did you set this up?
Thanks!
February 2, 2011 at 10:27 am
Log shipping is not expecting there to be a 3rd server. Most people store the backups local on the primary server. Generally, the expectation is that the directory with the log backups is on a share, and the copy job uses the share to copy the files across. That is the way it is normally done.
February 7, 2011 at 8:57 pm
tacy.highland (2/1/2011)
I'm trying to get some clarification on logshipping...I've set up logshipping between primary server and secondary server, with the log files being saved to a shared folder on another server. First question:
I can't find anything referencing WHY the log files need to be saved on another server, and then copied over to the secondary server. Is it a best practice?
[Minaz]: Yes, for DR plan in case we loose both Primary & Secondary server we still have the tlogs so there are chances to recover. Coping the tlog file to third server and from coping back to secondary for restoring will be perf issue as you have already noticed.
Because (I'm assuming) those files are saved on a separate server and then copied via the Copy job on the secondary server over to the secondary server, I'm seeing a bit of latency involved. In order to mitigate this latency, couldn't I somehow set it up so that the log files are being saved to a folder directly on the secondary server, exclude the whole Copy job altogether, and allow the Restore job to just restore from those orignal log files? (I wouldn't want to keep the copy job going, then I'd have two copies of the log files on the secondary server -- not necessary) I thought this might help with some of the latency by "removing the middle man", so to speak.
[Minaz]: You can do that.. depend how imp is your data. There is always a tread off between performance and safety.
Am I missing something? Is there a way to actually do this using the log shipping GUI? (could I set up the Backup job to copy over to a folder on the secondary server, and then just disable the Copy job once it's created?)
Help! I'm a bit of a newbie in this area so bear with me....
[Minaz]: You can do that.
Thank you!
"More Green More Oxygen !! Plant a tree today"
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply