Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op: 
.NET Framework .NET Standard
Met Configurable retry logic (CRL) kan Microsoft.Data.SqlClient geselecteerde SqlConnection- en SqlCommand-bewerkingen opnieuw uitvoeren na tijdelijke fouten. Je kiest welke fouten kwalificeren, hoeveel pogingen je moet maken, hoe de vertragingen tussen pogingen groeien en welke commando's veilig zijn om te herhalen.
CRL staat standaard uit. Je schakelt het in door een provider toe te wijzen aan een verbinding, een commando, of beide. De twee providers zijn onafhankelijk: het toewijzen van een provider aan een verbinding past deze niet toe op commando's die vanuit die verbinding zijn gemaakt.
Opmerking
CRL is beschikbaar bij Microsoft. Data.SqlClient 3.0 en later. De standaard is SqlConfigurableRetryFactory.CreateNoneRetryProvider, die het niet opnieuw probeert.
Nieuwe pogingen voor CRL
| Scenario | Wijs de aanbieder toe aan | Typische mislukkingen |
|---|---|---|
| Open een verbinding | SqlConnection.RetryLogicProvider | Failover, throttling, korte onbeschikbaarheid van de database en transportfouten bij het tot stand brengen van verbindingen. |
| Een opdracht uitvoeren | SqlCommand.RetryLogicProvider | Geselecteerde fouten in een statement die veilig buiten een transactie herhaald kunnen worden. |
Voor de gedeelde catalogus van verbindingsfouten die in aanmerking komen voor herhaling via SQL Server, Azure SQL Database, Azure SQL Managed Instance, SQL-database in Microsoft Fabric, en speciale SQL-pools in Azure Synapse Analytics, se Built-in transient error list.
Kies een configuratiepad
| Opdracht | Artikel |
|---|---|
| Maak een provider aan en wijs toe in code | Retrylogica in SqlClient configureren |
| Vergelijk vaste, incrementele, exponentiële en no-retry providers | Ingebouwde providers voor logica voor nieuwe pogingen in SqlClient |
| Stel applicatiebrede standaardwaarden in een configuratiebestand in | Configureer SqlClient hertry-logica met een configuratiebestand |
| Implementeer een aangepast interval, foutpredicaat of provider | Maak een aangepaste herhalingsprovider voor SqlClient |
Ontwerp een veilig herproefbeleid
- Probeer alleen opnieuw fouten die waarschijnlijk worden opgelost zonder applicatie-invoer te veranderen.
- Beperk retries door zowel het aantal pogingen als de maximale vertraging in te stellen. Een eindeloze retrylus kan een storing veranderen in een aanhoudende belasting.
- Behandel
NumberOfTriesals het totale aantal pogingen, inclusief de eerste operatie. - Voeg jitter toe zodat veel klanten het niet tegelijk opnieuw proberen. De ingebouwde providers voegen jitter automatisch toe.
- Probeer een hele transactie opnieuw, niet één statement erin. De ingebouwde opdrachtproviders proberen opdrachten niet opnieuw uit te voeren via een verbinding met een actieve transactie.
- Beperk herhalingen van opdrachten tot idempotente bewerkingen, of tot bewerkingen die beschermd worden door een idempotentiemechanisme op applicatieniveau.
- Log het Retrying evenement zodat je herstelde tijdelijke storingen kunt onderscheiden van persistente incidenten.
Voor algemene architectuurrichtlijnen, zie Retry-patroon. Voor Azure SQL foutrichtlijnen, zie Transient errors.
Client-side time-outs en serverless cv
CRL probeert alleen opnieuw bij fouten die het stuurprogramma daadwerkelijk ontvangt. Een time-out aan de clientzijde treedt op als fout -2, die niet in de ingebouwde lijst met tijdelijke fouten staat. Daarom proberen de ingebouwde providers een Open() of een opdracht die de time-out aan de clientzijde bereikt, niet opnieuw.
ConnectTimeout en CommandTimeout moeten lang genoeg zijn om de bewerking op zichzelf af te dekken.
Deze voorwaarde is het belangrijkst voor de Serverless compute-laag voor Azure SQL Database met auto-pauze ingeschakeld. Een automatisch onderbroken database wordt bij de eerste Open() hervat, en het hervatten kan 30 tot 60 seconden of langer duren. Verhoog ConnectTimeout naar minstens 60 seconden wanneer het doelwit automatisch kan pauzeren. De herkansingslogica behandelt vervolgens de resterende tijdelijke storingen (bijvoorbeeld 40613, 40197, en 40501) terwijl de database online komt.