March 27, 2009 at 11:43 am
depend with san you have but is possible use clone drive to connect your SQL on this clone on same SAN. and reuse the Same clone id each time you shedule new one.
March 27, 2009 at 12:27 pm
I guess in your case, as you need it mainly for reporting, Mirroring with Snapshots should do. You'd only have to device a functionality to keep the snapshots updated, with all that is implied doing that.....
March 27, 2009 at 1:36 pm
Meredith Ryan (3/27/2009)
As far as root cause analysis of my logshipping issues there seem to be a few. One issue I have is with the shared folder setup that is needed. On a cluster shared folders on cluster resources need to be recreated after every reboot, or failover. If that doesn't happen then logshipping copies fail. And, of course you really want your backup jobs writting to a cluster resource so that they continue to work in a failover situation.
Set up the share as clustering resource in Cluster Adminsitrator and put it into cluster group;
and also when you refer the path, use the ClusterName instead of the physical server name, like '\\CLUSTERNAME\SHARENAME\'. This way the share should be a failover share.
The other issue that I see most often is that the restore job just doesn't restore the files. I don't get a failure, it just skips the trn logs and tells me that a later trn log must be applied. If I use that same set of files and do a manual restore they work fine and logshipping will most likey do it's thing the next night.
We had the same issue before, we ended up adding one more step before each restore to check the trn series number and check whether it's been restored, if not matching, an error alert will be sending to us.
It seems that you are using LightSpeed. If it is Enterprise version, it has logshipping functionality in it too, which is much faster than MS' native Logshipping.
March 27, 2009 at 2:18 pm
Set up the share as clustering resource in Cluster Adminsitrator and put it into cluster group;
and also when you refer the path, use the ClusterName instead of the physical server name, like '\\CLUSTERNAME\SHARENAME\'. This way the share should be a failover share.
Wow! you are the first person I've come across with a solution for that! I will have to test that this weekend.
thanks!
We had the same issue before, we ended up adding one more step before each restore to check the trn series number and check whether it's been restored, if not matching, an error alert will be sending to us.
It seems that you are using LightSpeed. If it is Enterprise version, it has logshipping functionality in it too, which is much faster than MS' native Logshipping.
I get this behavior with litespeed logshipping and with native unfortunately...
I am still working on finding the root cause of it.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply