February 8, 2006 at 9:16 pm
hi all,
I have 2 servers doing bi-directional transactional replications. When server a goes down, people will use server b for updates and inserting of data. When this occurs, the distribution agent will try to connect to server a which obviously fails. I know theres a number of retry available to specify the retry to be done by the distributor. What i will like to know is if it is possible to ignore the network failure and go on retrying forever till server a comes alive again?
February 8, 2006 at 10:53 pm
IMHO, this will not be an efficient setup for you, if the distribution agent fails then something must be really wrong (reasons for network failure are diverse) and should remain stopped until the problem gets resolved
you can however create a job that will retry the "retries" after let's say 15 minutes, this way you'll get an "indefinite" retry but this will surely add more rows in your job history table
HTH
February 9, 2006 at 3:04 am
does setting 99 to number of retries make it infinite?
February 9, 2006 at 5:47 pm
maximum is 9999
replication contributes to a part of your server performance, so if you keep asking the server to retry the connection for n-minutes and infinitely, you might have some overheads to deal with...
deal with the root cause and not the symptom
HTH
February 9, 2006 at 6:20 pm
tks for the reply jen. I agree with out to deal with the cause. So i was thinking, as the distribution agent would give an error number '17' when theres a problem connecting to the subscriber. Maybe i can modify the command in the distribution agent properties to like
if(error=='17') retry
is it possible?
February 9, 2006 at 8:30 pm
yep, check for sysjobs union with sysjobhistory for run_status
concurrently check sysprocesses so that you'll have a baseline when to stop trying
but as i mentioned, an error for failed distribution agent may have different causes, you may want to check also if there are specific error messages for specific reasons
HTH
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply