Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för: 
.NET Framework .NET .NET Standard
Konfigurerbar återförsökslogik (CRL) gör det möjligt för Microsoft.Data.SqlClient att försöka igen med valda SqlConnection- och SqlCommand-operationer efter tillfälliga fel. Du väljer vilka fel som räknas, hur många försök du gör, hur fördröjningar ökar mellan försöken och vilka kommandon som är säkra att upprepa.
CRL är avstängt som standard. Du aktiverar det genom att tilldela en leverantör till en anslutning, ett kommando eller båda. De två leverantörerna är oberoende: att tilldela en leverantör till en anslutning gäller inte för kommandon som skapas från den anslutningen.
Anmärkning
CRL finns tillgängligt i Microsoft. Data.SqlClient 3.0 och senare. Standardinställningen är SqlConfigurableRetryFactory.CreateNoneRetryProvider, som inte försöker igen.
Vilka återförsök för CRL
| Scenario | Tilldela leverantören till | Typiska fel |
|---|---|---|
| Öppna en anslutning | SqlConnection.RetryLogicProvider | Failover, strypning, kortvarig databasotillgänglighet och transportfel under anslutningsetablering. |
| Köra ett kommando | SqlCommand.RetryLogicProvider | Utvalda uttalandefel som är säkra att upprepa utanför en transaktion. |
För den gemensamma katalogen över anslutningsfel som kan försökas igen i SQL Server, Azure SQL Database, Azure SQL Managed Instance, SQL-databas i Microsoft Fabric och dedikerade SQL-pooler i Azure Synapse Analytics, se Inbyggd lista över tillfälliga fel.
Välj en konfigurationssökväg
| Task | Artikel |
|---|---|
| Skapa och tilldela en leverantör i kod | Konfigurera återföringslogik i SqlClient |
| Jämför fasta, inkrementella, exponentiella och icke-återvändande leverantörer | Inbyggda retry-logikleverantörer i SqlClient |
| Ställ in applikationsövergripande standardinställningar i en konfigurationsfil | Konfigurera SqlClient återförsökslogik med en konfigurationsfil |
| Implementera ett anpassat intervall, ett predikat för fel eller en provider | Skapa en anpassad återprövningsleverantör för SqlClient |
Designa en säker återförsökspolicy
- Försök bara igen med misslyckade försök som sannolikt löser sig utan att programmets indata ändras.
- Begränsa återförsök både med antal försök och maximal fördröjning. En obegränsad loop med återförsök kan förvandla en driftstörning till varaktig belastning.
- Betrakta
NumberOfTriessom det totala antalet försök, inklusive den inledande operationen. - Lägg till jitter så att många klienter inte försöker igen samtidigt. De inbyggda leverantörerna lägger automatiskt till jitter.
- Försök igen med en hel transaktion, inte ett enda uttalande i den. De inbyggda kommandoleverantörerna försöker inte köra kommandon igen på en anslutning med en aktiv transaktion.
- Begränsa omförsök av kommandon till idempotenta operationer eller till operationer som skyddas av en idempotensmekanism på applikationsnivå.
- Logga händelsen Retrying så att du kan skilja återställda tillfälliga fel från persistenta incidenter.
För allmän arkitekturvägledning, se Retry-mönster. För Azure SQL-felguider, se Transient errors.
Tidsgränser på klientsidan och serverlös återupptagning
CRL gör endast omförsök för fel som drivrutinen faktiskt tar emot. En timeout på klientsidan yttrar sig som felet -2, vilket inte finns med i den inbyggda listan över transienta fel, så de inbyggda leverantörerna försöker inte igen ett Open() eller ett kommando som överskrider timeoutgränsen på klientsidan.
ConnectTimeout och CommandTimeout måste vara tillräckligt lång för att täcka operationen på egen hand.
Detta förhållande är särskilt viktigt för den serverlösa beräkningsnivån för Azure SQL Database med automatisk paus aktiverad. En automatisk pausad databas återupptas på den första Open(), och återupptagningen kan ta 30 till 60 sekunder eller mer. Höj ConnectTimeout till minst 60 sekunder när målet kan autopausa. Omförsökslogik hanterar sedan de återstående tillfälliga felen (till exempel 40613, 40197, och 40501) medan databasen tas i bruk.