Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für: 
.NET Framework .NET .NET Standard
Konfigurierbare Wiederholungslogik (CRL) ermöglicht Microsoft.Data.SqlClient, ausgewählte SqlCommand- und SqlConnection-Operationen nach transienten Fehlern erneut auszuführen. Du wählst, welche Fehler qualifizieren, wie viele Versuche gemacht werden, wie die Verzögerungen zwischen den Versuchen wachsen und welche Befehle sicher wiederholt werden können.
CRL ist standardmäßig ausgeschaltet. Du aktivierst es, indem du einem Anbieter eine Verbindung, einen Befehl oder beides zuweist. Die beiden Anbieter sind unabhängig voneinander: Die Zuweisung eines Anbieters zu einer Verbindung gilt nicht für Befehle, die von dieser Verbindung erstellt werden.
Hinweis
CRL ist bei Microsoft verfügbar. Data.SqlClient 3.0 und später. Die Standardeinstellung ist SqlConfigurableRetryFactory.CreateNoneRetryProvider, was nicht erneut versucht.
CRL-Wiederholungen
| Szenario | Weisen Sie den Anbieter zu | Typische Fehlschläge |
|---|---|---|
| Eröffne eine Verbindung | SqlConnection.RetryLogicProvider | Failover, Drosselung, kurze Datenbankunverfügbarkeit und Transportfehler während der Verbindungseinrichtung. |
| Ausführen von Befehlen | SqlCommand.RetryLogicProvider | Ausgewählte Anweisungsfehler, die außerhalb einer Transaktion sicher wiederholt werden können. |
Den gemeinsamen Katalog von Verbindungsfehlern, für die in SQL Server, Azure SQL-Datenbank, Azure SQL Managed Instance, SQL-Datenbank in Microsoft Fabric und dedizierten SQL-Pools in Azure Synapse Analytics ein Wiederholungsversuch unterstützt wird, finden Sie unter Built-in transient error list.
Wählen Sie einen Konfigurationspfad
| Aufgabe | Artikel |
|---|---|
| Erstellen und weisen Sie einen Provider im Code zu | Konfigurieren Sie die Wiederholungslogik in SqlClient |
| Vergleichen Sie feste, inkrementielle, exponentielle und No-Retry-Anbieter | Anbieter für integrierte Wiederholungslogik in SqlClient |
| Setze anwendungsweite Standardwerte in einer Konfigurationsdatei | Konfiguration der SqlClient-Wiederholungslogik mit einer Konfigurationsdatei |
| Implementiere ein benutzerdefiniertes Intervall, ein Fehlerprädikat oder einen Provider | Erstellen Sie einen benutzerdefinierten Wiederholungsanbieter für SqlClient |
Entwerfen Sie eine sichere Wiederholungsrichtlinie
- Wiederhole nur fehlgeschlagene Vorgänge, die sich wahrscheinlich beheben lassen, ohne die Anwendungseingabe zu ändern.
- Begrenzen Sie Wiederholungsversuche sowohl anhand der Anzahl der Versuche als auch der maximalen Verzögerung. Eine endlose Wiederholungsschleife kann einen Ausfall zu einer dauerhaften Belastung machen.
- Betrachten Sie
NumberOfTriesals Gesamtzahl der Versuche, einschließlich der ersten Operation. - Füge Jitter hinzu, damit nicht zu viele Clients gleichzeitig einen erneuten Versuch starten. Die integrierten Anbieter fügen Jitter automatisch hinzu.
- Versuchen Sie eine ganze Transaktion erneut, nicht eine einzelne Aussage darin. Die integrierten Befehlsprovider wiederholen Befehle bei Verbindungen mit aktiver Transaktion nicht.
- Beschränken Sie Wiederholungsversuche von Befehlen auf idempotente Operationen oder auf Operationen, die durch einen Idempotenzmechanismus auf Anwendungsebene geschützt sind.
- Protokollieren Sie das Retrying Ereignis, damit Sie wiederhergestellte vorübergehende Ausfälle von persistenten Vorfällen unterscheiden können.
Für allgemeine Architekturhinweise siehe Retry-Muster. Für Azure SQL-Fehleranleitungen siehe Transient errors.
Clientseitige Timeouts und serverlose Fortsetzung
CRL versucht nur bei Fehlern erneut, die der Treiber tatsächlich empfängt. Ein clientseitiges Timeout tritt als Fehler -2 auf, der nicht in der integrierten Liste transienter Fehler enthalten ist, sodass die integrierten Anbieter Open() oder einen Befehl, bei dem das Clienttimeout auftritt, nicht erneut versuchen.
ConnectTimeout und CommandTimeout müssen lang genug sein, um den Vorgang jeweils eigenständig abzudecken.
Diese Bedingung ist am wichtigsten für die Serverless-Compute-Stufe für Azure SQL-Datenbank mit aktivierter automatischer Pause. Eine automatisch pausierte Datenbank wird beim ersten Open() wieder aufgenommen, und die Wiederaufnahme kann 30 bis 60 Sekunden oder länger dauern. Erhöhen Sie ConnectTimeout auf mindestens 60 Sekunden, wenn das Ziel automatisch anhalten kann. Die Retry-Logik behandelt dann die verbleibenden vorübergehenden Fehler (zum Beispiel 40613, 40197, und 40501), während die Datenbank online geht.