Algoritmo de nova tentativa de conexão (para conexões TCP/IP)

Para uma conexão TCP/IP, se o cliente estiver executando o Microsoft Windows XP ou uma versão posterior, quando ambos os nomes de parceiro estiverem no cache, o provedor de acesso de dados adere a um algoritmo de retentar conexão. Isto é verdade tanto para fazer a conexão inicial para a sessão como para reconectar depois de perder uma conexão estabelecida. Quando uma conexão tiver sido estabelecida, completar os passos de pré-logon e logon leva tempo adicional.

Observação

O tempo gasto para abrir uma conexão pode exceder o tempo de retentar por causa de fatores externos, como lookups de DNS lento, controlador/Kerberos Key Distribution Center (KDC) de domínio lento, tempo gasto contatando o navegador do SQL Server, congestão de rede e outros. Tais fatores externos podem impedir um cliente de conectar a um banco de dados espelhado. Além disso, fatores externos podem fazer uma conexão levar mais tempo para abrir do que o tempo estimado para retentar. Para obter informações em como ignorar o DNS e o navegador do SQL Server para tentativa de conexão ao parceiro inicial, consulte Fazendo a conexão inicial com uma sessão de espelhamento de banco de dados.

Se uma tentativa de conexão falhar ou o tempo de retentar expirar antes da conexão acontecer, o provedor de acesso de dados tentará o outro parceiro. Se uma conexão não for aberta neste ponto, o provedor tentará alternadamente os nomes do parceiro inicial e do failover, até que uma conexão seja aberta ou o período de logon expire. O período do tempo limite de logon padrão é de 15 segundos. Nós recomendamos que o período de tempo limite de logon seja pelo menos de 5 segundos. Especificar um período de tempo limite menor poderia impedir quaisquer das tentativas de conexão de ter êxito.

O tempo da retentar é uma porcentagem do período de logon. O tempo da retentar para uma tentativa de conexão é maior em cada turno sucessivo. No primeiro turno, o tempo de retentar para cada das duas tentativas é de 8 por cento do período de logon total. Em cada turno sucessivo, o algoritmo de retentar aumenta o tempo máximo de retentar pela mesma quantia. Assim, o retentar para as primeiras oito tentativas de conexão são:

8%, 8%, 16%, 16%, 24%, 24%, 32%, 32%

O tempo de retentar é calculado usando a seguinte fórmula:

RetryTime**=PreviousRetryTime+(** 0.08 *LoginTimeout)

Onde PreviousRetryTime é inicialmente 0.

Por exemplo, se usar o período de intervalo de logon padrão de 15 segundos, LoginTimeout = 15. Neste caso, os tempos de retentar nos primeiros três turnos são:

Turno	Cálculo de RetryTime	Tempo de retentar por tentativa
1	0 +(0.08 * 15)	1.2 segundo
2	1.2 +(0.08 * 15)	2.4 segundos
3	2.4 +(0.08 * 15)	3.6 segundos
4	3.6 +(0.08 * 15)	4.8 segundos

A figura seguinte ilustra estes tempos de retentar para tentativas de conexão sucessivas, cada uma delas expirando.

Para o período limite de logon padrão, o tempo máximo estimado para os primeiros três turnos de tentativas de conexão é de 14.4 segundos. Se toda tentativa fosse usar tudo de seu tempo estimado, só 0.6 segundo de tempo restaria antes do período de logon expirar. Naquele caso, o quarto turno seria reduzido, permitindo só uma tentativa rápida final para conectar usando o nome de parceiro inicial. Porém, uma tentativa de conexão pode falhar em menos tempo do que seu tempo estimado, particularmente em turnos posteriores. Por exemplo, receber um erro de rede pode fazer com que uma tentativa termine antes que o tempo de retentar expire. Se as primeiras tentativas falharem devido a um erro de rede, haveria tempo adicional disponível para o quarto turno e, talvez, turnos adicionais.

Outra causa de uma tentativa falha é uma instância de servidor inativa, como acontece quando uma instância de servidor estiver comprometida numa interrupção de seu banco de dados. Neste caso, um atraso é imposto para impedir clientes de sobrecarregar os parceiros com uma sucessão rápida de tentativas de conexão.

Observação
Quando ambos os nomes de parceiros estiverem disponíveis, se o período de intervalo de logon for infinito, o cliente tentará reconectar indefinidamente aos servidores, alternando entre o nome de parceiro inicial e o nome de parceiro de failover.

Atrasos de retentar durante failover

Se um cliente tentar conectar a um parceiro que está em failover, o parceiro responderá imediatamente que é inativo. Neste caso, cada turno de tentativas de conexão é muito mais breve que o tempo de retentar estimado. Isso significa que muitos turnos de tentativas de conexão poderiam acontecer antes que o período de logon expire. Para evitar a sobrecarrega dos parceiros com uma série rápida de tentativas de conexão durante um failover, o provedor de acesso de dados adiciona um breve retardo ao retentar depois de cada turno de retentar. A duração de um determinado retardo ao retentar é determinada pelo algoritmo de retardo ao retentar. Depois do primeiro turno, o retardo é 100 milissegundos. Após cada um dos três turnos, o retardo ao retentar dobra—para 200, 400 e 800. Em todos os últimos turnos, o retardo é de 1 segundo até que a tentativa de conexão tenha êxito ou expire.

Observação
Se a instância de servidor for parada, então a solicitação de conexão falhará imediatamente.

A figura seguinte ilustra como o retardo ao retentar afeta tentativas de conexão durante um failover manual no qual os parceiros trocam suas funções. O período do tempo limite de logon padrão é de 15 segundos.

Consulte também

Conceitos

Visão geral do espelhamento de banco de dados

Possíveis falhas durante espelhamento de banco de dados

Fazendo a conexão inicial com uma sessão de espelhamento de banco de dados

Reconectando uma sessão de espelhamento de banco de dados

Outros recursos

Conectando ao Mecanismo de Banco de Dados do SQL Server