SQL Server-Verbindungspooling mit Microsoft.Data.SqlClient

Microsoft.Data.SqlClient-Verbindungspoolierung verwendet authentifizierte physische Verbindungen erneut. SqlConnection.Open oder OpenAsync prüft einen Pool auf eine verwendbare Verbindung. Close, Dispose oder DisposeAsync setzt es zurück. Dieser Ansatz vermeidet eine Netzwerkverbindung, Authentifizierung und Sitzungseinrichtung für jede Operation.

Pooling ist standardmäßig aktiviert. Verwenden Sie dieses Anwendungsmuster:

await using var connection = new SqlConnection(connectionString);
await connection.OpenAsync(cancellationToken);

using var command = new SqlCommand(sql, connection);
await command.ExecuteNonQueryAsync(cancellationToken);

Spät öffnen, früh entsorgen und den Pool die physischen Verbindungen verwalten lassen. Halte eine SqlConnection nicht global offen.

Verstehen Sie die Poolschlüssel

Eine Verbindung kann nur aus dem zugehörigen Pool wiederverwendet werden. Der Poolschlüssel umfasst mehr als nur den Zielserver.

Die Datenbank, der Authentifizierungsmodus, die Verschlüsselungsoptionen, der Anwendungsname, die Pooling-Optionen und alle anderen Verbindungszeichenfolge-Werte tragen über genau diesen String bei.

Erstelle eine kanonische Verbindungszeichenfolge und verwende sie erneut. Vermeiden Sie anfragespezifische Werte in Application Name, Workstation ID oder anderen Schlüsselwörtern.

Wählen Sie Token-APIs, die sich poolen lassen können

Für Microsoft Entra ID-Zugriffstoken verwenden Sie einen von Microsoft.Data.SqlClient bereitgestellten Authentifizierungsmodus oder ein stabiles AccessTokenCallback.

AccessTokenCallback wurde in Microsoft.Data.SqlClient 5.2 eingeführt. Der Treiber ruft diese Funktion auf, wenn er ein Token benötigt, und kann für einen wiederverwendeten Pool ein erneuertes Token anfordern. Behalten Sie den Callback-Determinismus für die vom Treiber bereitgestellten Authentifizierungsparameter und verwenden Sie dieselbe Delegate-Instanz wieder.

Wenn der Code AccessToken direkt festlegt:

• Der Token-String wird Teil des Pool-Schlüssels.
• Die Anwendung verwaltet den Tokenablauf und die Tokenaktualisierung.
• Eine gepoolte physische Verbindung kann den Token überdauern, mit dem sie erstellt wurde.
• Rufen Sie ClearPool nach dem Austausch eines abgelaufenen Tokens an, wenn dieser Pool nicht mehr sicher genutzt werden kann.

Erstelle nicht für jede Anfrage ein neues Callback-Lambda oder Credential-Objekt. Objektidentitätsunterschiede können die Pools fragmentieren.

Microsoft.Data.SqlClient 7.0 fügt SspiContextProvider für die benutzerdefinierte Kerberos- oder NTLM-Aushandlung hinzu. Behandle den Anbieter als anwendungsweite Verbindungskonfiguration, nicht als anfragebezogenen Zustand.

Dimensionieren Sie jedes Becken

Diese Verbindungszeichenfolge-Optionen steuern einen Pool:

Der Pool stellt Verbindungen her, wenn die Nachfrage wächst, bis sie erreicht Max Pool Size. Wenn alle Verbindungen genutzt sind, warten spätere Öffnungen darauf, dass eine Verbindung zurückkehrt. Wenn die Wartezeit überschreitet Connect Timeout, scheitert die Öffnung.

Erhöhe Max Pool Size erst, nachdem du es überprüft hast:

• Jede Verbindung und jedes Lesegerät sind auf allen Pfaden angeordnet.
• Befehle und Transaktionen werden schnell abgeschlossen.
• Die Query-Workload ist nicht blockiert oder gesättigt.
• Das Datenbankverbindungslimit kann Max Pool Size multipliziert mit jedem Pool in jeder Anwendungsinstanz verarbeiten.

Ein positiver Min Pool Size hält die Verbindungen während Leerlaufphasen offen. Verwende es nur, wenn die Messungen warme Verbindungen rechtfertigen. Es steht in der Regel Scale-to-Zero-Architekturen, serverloser automatischer Pausierung und burstable Cloud-Architekturen entgegen.

Mit der Standardeinstellung Load Balance Timeout=0 entfernt die periodische Bereinigung normalerweise ungenutzte Verbindungen über Min Pool Size nach etwa vier bis acht Minuten, oder der Pool entfernt sie, wenn er erkennt, dass die Serververbindung unterbrochen ist. Behandle dieses Intervall als Implementierungsverhalten, nicht als Idle-Garantie pro Verbindung. Der Pool sendet vor jedem Checkout keine Validierungsanfrage, weil diese Hin- und Rückfahrt einen Großteil des Pooling-Vorteils nimmt.

Authentifizierungssperrzeiten verwalten

Nach einer Zeitüberschreitung bei der Authentifizierung oder einem anderen Authentifizierungsfehler kann der Pool in eine Sperrphase übergehen. Während dieses Zeitraums lösen entsprechende offene Versuche erneut die ursprüngliche Ausnahme aus, ohne einen weiteren Authentifizierungsversuch durchzuführen.

Die erste Blockphase beträgt fünf Sekunden. Nach einem weiteren Fehlschlag verdoppelt sich die Periode auf eine Minute.

Pool Blocking Period Kontrolliert dieses Verhalten:

Behalten Sie Auto bei, es sei denn, das gemessene Retry-Design der Anwendung erfordert eine andere Entscheidung. Das Deaktivieren der Sperrperiode kann ein Problem mit Zugangsdaten, einer Firewall oder einem Ausfall in einen Authentifizierungssturm verwandeln.

Die Blockperiode ist getrennt von der konfigurierbaren Wiederholungslogik. Ein Retry-Provider, der denselben Pool während einer Blockierungsphase öffnet, erhält die zwischengespeicherte Ausnahme.

Verbindungslebensdauer verwalten und Verbindungen löschen

Der Pool löscht den betroffenen Pool automatisch, wenn er einen fatalen Fehler erkennt, wie zum Beispiel einen Failover. Der Pool schließt inaktive Verbindungen und verwirft entliehene Verbindungen, wenn sie zurückgegeben werden.

Verwenden Sie die Clearing-APIs für eine bekannte Konfigurations- oder Zugangsgrenze:

• ClearPool leert den Pool, der einer SqlConnection-Konfiguration zugeordnet ist.
• ClearAllPoolslöscht jeden Microsoft. Data.SqlClient Pool im Prozess- oder Anwendungsbereich.

Der Pool schließt inaktive Verbindungen in einem geleerten Pool. Der Pool kennzeichnet Verbindungen, die sich derzeit in Verwendung befinden, sodass er sie bei ihrer Rückgabe verwirft.

Das Löschen von Pools führt dazu, dass spätere Öffnungsvorgänge physische Anmeldungen erfordern. Verwenden Sie es nicht als periodische Wartung, allgemeinen Fehlerbearbeiter oder als Ersatz für das Entsorgen von Verbindungen.

Load Balance Timeout sorgt für eine allmähliche, altersabhängige Fluktuation. Verwende es, wenn ein Deployment oder ein geclusterter Dienst bestehende physische Verbindungen nach und nach aufgeben muss. Bestätigen Sie, dass der gewählte Wert keine übermäßigen Hard-Connects verursacht.

Grundlegendes zu Transaktionen

Mit Enlist=true als Standard wird eine innerhalb von System.Transactions.Transaction.Current geöffnete Verbindung automatisch in diese Transaktion eingebunden.

Wenn eine einer Transaktion zugeordnete Verbindung geschlossen wird, ordnet der Verbindungspool sie einem transaktionsspezifischen Unterbereich zu. Ein späterer Öffnungsvorgang innerhalb derselben Transaktion kann ihn wiederverwenden. Die physische Verbindung kehrt erst nach Abschluss der Transaktion zum allgemeinen Pool zurück.

Lang andauernde oder abgebrochene Ambient-Transaktionen können daher:

• Halte physische Verbindungen aus dem allgemeinen Pool heraus.
• Verbrauche die Poolkapazität nach dem Schließen der logischen Verbindung.
• Halte Serversperren und Transaktionszustände aktiv.

Begrenzen Sie die Dauer von Transaktionen, schließen Sie sie ausdrücklich ab und überwachen Sie inaktive Verbindungen. Legen Sie Enlist=false nur dann fest, wenn die Verbindung außerhalb einer Umgebungstransaktion bleiben muss.

Poolfragmentierung verhindern

Poolfragmentierung erzeugt viele kleine Pools anstelle einiger wiederverwendbarer Pools. Häufige Ursachen sind:

• Unterschiede in der Reihenfolge von Verbindungsstring-Schlüsselworten oder Alias.
• Eine Verbindungszeichenfolge pro Kunde, Nutzer, Anfrage oder Datenbank.
• Integrierte Authentifizierung unter vielen Windows-Identitäten.
• Neue SqlCredential, Zugriffstoken-Callback oder SSPI-Provider-Instanzen pro Anfrage.
• Direktzugriffstoken, die sich bei jeder Aktualisierung ändern.
• Anwendungsnamen oder Workstation-IDs mit hoher Kardinalität.

Verbindungszeichenfolgen mit SqlConnectionStringBuilder normalisieren und die Erstellung von Verbindungen zentralisieren.

Wenn die Anwendung absichtlich mit vielen Datenbanken oder Identitäten verbunden ist, sollten Sie die resultierende Pool-Anzahl in die Kapazitätsplanung einbeziehen. Führen Sie USE nicht mit einem nicht vertrauenswürdigen Datenbanknamen aus, um Pools zusammenzuführen. Datenbankisolation, Berechtigungen, Sitzungszustand und Pool-Reset-Verhalten müssen explizit bleiben.

Berücksichtigen Sie Anwendungsrollen und den Sitzungszustand

Der Pool setzt den wiederverwendbaren SQL Server-Sitzungszustand zurück, bevor eine physische Verbindung einer anderen logischen Verbindung zugeordnet wird. Der Anwendungscode sollte weiterhin jeden erforderlichen Sitzungszustand innerhalb seiner Arbeitseinheit festlegen.

SQL Server-Anwendungsrollen, die mit sp_setapprole aktiviert werden, können für normales Pooling nicht sicher zurückgesetzt werden. Bevorzugen Sie Datenbankbenutzer, Contained-User, Rollen, Zeilensicherheit oder ein anderes Autorisierungsdesign. Wenn eine Anwendungsrolle unvermeidbar ist, verwenden Sie ein dokumentiertes, cookie-basiertes Umkehrmuster oder deaktivieren Sie das Pooling für diesen isolierten Pfad nach dem Test.

Entsorge Leser, beende oder rücke Transaktionen zurück und lass keine Befehle laufen, wenn die Verbindung geschlossen wird. Verlasse dich nicht darauf, dass temporäre Tabellen oder andere Sitzungszustände über logische Verbindungen hinweg überleben.

Verwenden Sie cloud-gehostete Pooling-Muster

Für Azure App Service, Azure Functions, Container, Kubernetes und andere horizontal skalierte Hosts:

• Berechnen Sie die möglichen Datenbankverbindungen über alle Instanzen, Prozesse, Poolschlüssel und Replikate.
• Verwenden Sie eine verwaltete Identität oder einen stabilen Zugriffstoken-Callback, anstatt Token-Strings in Verbindungsobjekten zu drehen.
• Behalten Sie Min Pool Size=0 bei, es sei denn, gemessene Kaltstartzeiten rechtfertigen beibehaltene Sitzungen.
• Erwarte, dass eine neue Instanz mit einem leeren Pool startet.
• Halte die Verbindungsstrings in allen Instanzen, die denselben Workload bedienen, identisch.
• Begrenzen Sie Verbindungsversuche und Wiederholungen, um synchronisierte Anmeldespitzen während eines Failovers oder einer horizontalen Skalierung zu vermeiden.
• Legen Sie MultiSubnetFailover=true für Azure SQL und andere unterstützte TCP-Endpunkte mit mehreren Adressen fest.

Verbindungspools sind lokal im Antragsprozess verankert. Sie werden nicht zwischen Anwendungsinstanzen, Containern oder Hosts geteilt.

Poolverhalten diagnostizieren

Verwenden Sie SqlClient-Diagnosezähler, um Folgendes zu beobachten:

• Harte Verbindungen und Abschaltungen, die physische Serververbindungen darstellen.
• Soft-Verbindungen und -Trennungen, die die Entnahme aus dem Pool und die Rückgabe an den Pool darstellen.
• Aktive und frei gepoolte Verbindungen.
• Aktive Poolgruppen und Pools.
• Stasisverbindungen.
• Zurückgewonnene Verbindungen, bei denen der Anwendungscode die logische Verbindung nicht beseitigte.

Korrelieren Sie Clientzähler mit SQL Server-Sitzungen, Wartezeiten, Blockierungen und Ressourcenlimits. Ein Pool-Timeout kann ein Verbindungsleck, langsame Abfragen, blockierte Transaktionen, zu viel Nebenläufigkeit, Poolfragmentierung oder eine Datenbankkapazitätsbegrenzung bedeuten.

Verwenden Sie Ereignisquellen-Tracing für gezielte Pooler-Traces. Nachzeichnen ist ausführlich. Aktivieren Sie es für ein begrenztes Diagnosefenster und schützen Sie alle erfassten Verbindungsmetadaten.

Produktionsprüfliste

• Bleib Pooling aktiviert.
• Verwenden Sie für jede Arbeitslast und jede Datenbank wieder eine kanonische Verbindungszeichenfolge.
• Entsorge Verbindungen, Befehle, Leser und Transaktionen auf jedem Pfad.
• Wiederverwendung von Zugangsdaten, Token-Callback- und SSPI-Provider-Instanzen.
• Setze Endverbindungs- und Befehls-Timeouts.
• Dimensionieren Sie das gesamte Verbindungsbudget für jede Anwendungsinstanz.
• Überwachen Sie direkte Verbindungen, die Anzahl der Verbindungen im Pool, freie Verbindungen, Stasis und Zeitüberschreitungen.
• Leeren Sie Pools nur für eine Anmeldeinformation, ein Token oder eine Konfigurationsabgrenzung, die vom Anbieter nicht erkannt werden kann, oder wenn Diagnosedaten bestätigen, dass veraltete Verbindungen bestehen bleiben.
• Testen Sie vor dem Produktiveinsatz das Scale-Out-, Failover- und das Verhalten bei der Aktualisierung von Anmeldeinformationen unter Last.

Verwandte Inhalte

• Mit einer Datenquelle verbinden
• Verbindungszeichenfolgen
• Verbindungsoptionen.
• SqlClient-Diagnosezähler
• Konfigurierbare Wiederholungslogik
• Microsoft Entra ID-Authentifizierung