Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a: 
.NET Framework .NET .NET Standard
A lógica de repetição configurável (CRL) permite que o Microsoft.Data.SqlClient repita operações SqlConnection e SqlCommand selecionadas após falhas transitórias. Escolhe quais os erros que se qualificam, quantas tentativas fazer, como os atrasos aumentam entre tentativas e quais os comandos que é seguro repetir.
O CRL está desligado por defeito. Ativa-se ao atribuir um fornecedor a uma ligação, um comando, ou ambos. Os dois fornecedores são independentes: atribuir um fornecedor a uma ligação não a aplica a comandos criados a partir dessa ligação.
Observação
O CRL está disponível na Microsoft. Data.SqlClient 3.0 e posteriores. O padrão é SqlConfigurableRetryFactory.CreateNoneRetryProvider, que não faz nova tentativa.
O que o CRL retenta
| Scenario | Atribuir o fornecedor a | Falhas típicas |
|---|---|---|
| Abrir uma ligação | SqlConnection.RetryLogicProvider | Failover, limitação, breve indisponibilidade da base de dados e falhas de transporte durante o estabelecimento da ligação. |
| Executar um comando | SqlCommand.RetryLogicProvider | Falhas selecionadas de instruções que podem ser repetidas com segurança fora de uma transação. |
Para o catálogo partilhado de erros de conexão que podem ser objeto de nova tentativa no SQL Server, no Base de Dados SQL do Azure, no Azure SQL Managed Instance, na base de dados SQL no Microsoft Fabric e nos conjuntos de SQL dedicados no Azure Synapse Analytics, consulte lista incorporada de erros transitórios.
Escolha um caminho de configuração
| Tarefa | Artigo |
|---|---|
| Criar e atribuir um fornecedor em código | Configurar a lógica de retentativa no SqlClient |
| Compare fornecedores fixos, incrementais, exponenciais e sem repetição | Implementações integradas de lógica de repetição no SqlClient |
| Definir os valores definidos para toda a aplicação num ficheiro de configuração | Configurar a lógica de retentativa do SqlClient com um ficheiro de configuração |
| Implemente um intervalo personalizado, predicado de erro ou provedor | Criar um provedor de retentativas personalizado para SqlClient |
Conceba uma política segura de novas tentativas
- Tente novamente apenas as falhas que provavelmente serão corrigidas sem alterar os dados de entrada da aplicação.
- Limite as repetições tanto pelo número de tentativas como pelo atraso máximo. Um ciclo ilimitado de novas tentativas pode transformar uma indisponibilidade numa sobrecarga contínua.
- Trate
NumberOfTriescomo o número total de tentativas, incluindo a operação inicial. - Adicione jitter para que muitos clientes não tentem ao mesmo tempo. Os fornecedores integrados adicionam jitter automaticamente.
- Tente novamente uma transação inteira, não uma única declaração dentro dela. Os fornecedores de comandos integrados não repetem os comandos numa ligação que tenha uma transação ativa.
- Restrinja as repetições de comandos a operações idempotentes ou a operações protegidas por um mecanismo de idempotência de nível aplicacional.
- Registe 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 sobre erros do SQL do Azure, veja Erros transitórios.
Timeouts do lado do cliente e retoma sem servidor
O CRL só retenta os erros que o driver realmente recebe. Um timeout do lado do cliente surge como o erro -2, que não está na lista integrada de erros transitórios, pelo que os fornecedores integrados não repetem um Open() nem um comando que atinja o timeout do cliente.
ConnectTimeout e CommandTimeout devem ser suficientemente longos para cobrir a operação por si só.
Esta condição é mais relevante para o escalão de computação sem servidor do Base de Dados SQL do Azure com pausa automática ativada. Uma base de dados em pausa automática recomeça no primeiro Open(), e a retomada pode demorar entre 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 repetição trata as restantes falhas transitórias (por exemplo 40613, 40197 e 40501) enquanto a base de dados fica disponível.