Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a: 
.NET Framework .NET .NET Standard
A lógica configurável de repetição (CRL) permite que o Microsoft.Data.SqlClient tente novamente operações SqlConnection e SqlCommand selecionadas após falhas transitórias. Você escolhe quais erros se qualificam, quantas tentativas fazer, como os atrasos aumentam entre as tentativas e quais comandos são seguros para repetir.
O CRL está desligado por padrão. Você habilita isso atribuindo um provedor a uma conexão, um comando, ou ambos. Os dois provedores são independentes: atribuir um provedor a uma conexão não a aplica a comandos criados a partir dessa conexão.
Observação
O CRL está disponível na Microsoft. Data.SqlClient 3.0 e posteriores. O padrão é SqlConfigurableRetryFactory.CreateNoneRetryProvider, que não repete a tentativa.
Quais novas tentativas de CRL
| Scenario | Atribuir o fornecedor a | Falhas típicas |
|---|---|---|
| Abra uma conexão | SqlConnection.RetryLogicProvider | Failover, limitação de taxa, indisponibilidade do banco de dados temporária e falhas no transporte durante o estabelecimento da conexão. |
| Executar um comando | SqlCommand.RetryLogicProvider | Falhas em instruções selecionadas que podem ser reexecutadas com segurança fora de uma transação. |
Para o catálogo compartilhado de erros de conexão passíveis de repetição no SQL Server, no Banco de Dados SQL do Azure, na Instância Gerenciada de SQL do Azure, no banco de dados SQL no Microsoft Fabric e em pools de SQL dedicados no Azure Synapse Analytics, consulte Lista interna de erros transitórios.
Escolha um caminho de configuração
| Task | Artigo |
|---|---|
| Crie e atribua um provedor em código | Configurar lógica de retentativa no SqlClient |
| Compare provedores fixos, incrementais, exponenciais e sem repetição | Provedores internos de lógica de repetição no SqlClient |
| Defina os padrões padrão para toda a aplicação em um arquivo de configuração | Configure a lógica de repetição do SqlClient com um arquivo de configuração |
| Implemente um intervalo personalizado, predicado de erro ou provedor | Crie um provedor de retentativas personalizado para o SqlClient |
Projetar uma política de repetição segura
- Tente novamente apenas as tentativas com falha que provavelmente devem ser resolvidas sem alterar os dados de entrada da aplicação.
- Limite as novas tentativas tanto pela contagem de tentativas quanto pelo atraso máximo. Um loop ilimitado de novas tentativas pode transformar uma indisponibilidade em carga contínua.
- Trate
NumberOfTriescomo o número total de tentativas, incluindo a operação inicial. - Adicione a tremulação para que muitos clientes não tentem novamente ao mesmo tempo. Os provedores integrados adicionam jitter automaticamente.
- Tente novamente a transação inteira, e não apenas uma instrução dentro dela. Os provedores de comandos integrados não tentam comandos novamente em uma conexão com uma transação ativa.
- Restrinja novas tentativas de comandos a operações idempotentes ou a operações protegidas por um mecanismo de idempotência no nível da aplicação.
- Registre o Retrying evento para distinguir falhas transitórias recuperadas de incidentes persistentes.
Para orientações gerais sobre arquitetura, veja o padrão Retry. Para orientações de erro em SQL do Azure, veja Erros transitórios.
Tempos limite do lado do cliente e retomada sem servidor
O CRL só tenta novamente em caso de erros recebidos efetivamente pelo driver. Um tempo limite do lado do cliente se manifesta como erro -2, que não está na lista interna de erros transitórios, logo, os provedores internos não tentam novamente um Open() ou um comando que atinja o tempo limite do cliente.
ConnectTimeout e CommandTimeout devem ser longos o suficiente para abranger a operação por conta própria.
Essa condição é o mais importante para o nível de computação Serverless do Banco de Dados SQL do Azure com a pausa automática ativada. Um banco de dados pausado automaticamente é retomado na primeira Open(), e essa retomada pode levar de 30 a 60 segundos ou mais. Aumente ConnectTimeout para pelo menos 60 segundos quando o alvo pode fazer uma pausa automática. A lógica de nova tentativa acaba manipulando falhas transitórias restantes (por exemplo 40613, 40197 e 40501) e o banco de dados fica online.