Poolování spojení SQL Server s Microsoft. Data.SqlClient

Sdružování připojení v Microsoft.Data.SqlClient opětovně používá ověřená fyzická připojení. SqlConnection.Open nebo OpenAsync ověří, zda je ve fondu dostupné použitelné připojení. Close, Dispose nebo DisposeAsync ji resetují a vrátí. Tento přístup eliminuje potřebu síťového připojení, ověřování a navázání relace při každé operaci.

Pooling je ve výchozím nastavení zapnutý. Použijte tento aplikační vzor:

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

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

Otevírejte pozdě, vyhazujte dříve a nechte bazén spravovat fyzické spojení. Nenechávejte SqlConnection otevřené globálně.

Pochopte klíče poolu

Spojení lze znovu použít pouze ze svého shodného poolu. Klíč poolu zahrnuje víc než jen cílový server.

Input Chování poolu
Připojovací řetězec Text musí přesně odpovídat. Rozdíly v pořadí klíčových slov vytvářejí samostatné pooly, i když jsou efektivní nastavení ekvivalentní.
Integrované ověřování systému Windows Identita Windows je součástí klíče. Stejný řetězec použitý pod různými identitami vytváří různé pooly.
SqlCredential Instance objektu je součástí klíče. Samostatné instance vytvářejí samostatné pooly, i když obsahují stejné uživatelské jméno a heslo.
SqlConnection.AccessToken Hodnota přístupového tokenu je součástí klíče. Nahrazení řetězců tokenů může vytvořit nové pooly a ponechat spojení autentizovaná se starými tokeny v existujících poolech.
SqlConnection.AccessTokenCallback Zpětné volání je součástí klíče. Použijte stejnou instanci zpětného volání pro spojení, která by měla sdílet pool. Vrácená hodnota tokenu není klíč poolu.
Vlastní poskytovatel kontextu SSPI Instance poskytovatele se účastní konfigurace připojení. Použijte jednu instanci poskytovatele pro spojení, která by se měla spojit dohromady.
Kontextová transakce Registrovaná připojení používají v rámci párovacího fondu pododdíly specifické pro danou transakci.

Databáze, režim ověřování, možnosti šifrování, název aplikace, možnosti sdružování připojení a všechny ostatní hodnoty jeho připojovacího řetězce se uplatňují prostřednictvím jeho přesného znění.

Vytvořte jeden kanonický připojovací řetězec a opakovaně ho používejte. Vyhněte se hodnotám pro jednotlivé požadavky v Application Name, Workstation ID nebo jiných klíčových slovech.

Vyberte tokenová API, která mohou poolovat

Pro přístupové tokeny Microsoft Entra ID použijte autentizační režim poskytovaný Microsoft. Data.SqlClient nebo stabilní AccessTokenCallback.

AccessTokenCallbackbyl představen v Microsoft. Data.SqlClient 5.2. Ovladač ho volá, když potřebuje token, a může požádat o obnovený token pro opakovaně použitý pool. Zajistěte, aby callback byl deterministický vzhledem k autentizačním parametrům, které poskytuje ovladač, a opakovaně používejte stejnou instanci delegáta.

Když kód nastavuje AccessToken přímo:

  • Řetězec tokenů se stává součástí klíče poolu.
  • Aplikace odpovídá za expiraci a obnovení tokenu.
  • Sdílené fyzické připojení může mít delší životnost než token použitý k jeho vytvoření.
  • Zavolejte ClearPool po výměně expirovaného tokenu, pokud už nelze tento pool bezpečně použít.

Nevytvářejte pro každý požadavek novou funkci lambda zpětného volání ani nový objekt přihlašovacích údajů. Rozdíly v identitě objektů mohou rozdělit pooly.

Microsoft.Data.SqlClient 7.0 přidává SspiContextProvider pro vlastní vyjednávání Kerberos nebo NTLM. Provider považujte za konfiguraci připojení s platností v rámci celé aplikace, nikoli za stav vázaný na jednotlivé požadavky.

Velikost každého bazénu

Tyto možnosti připojovací řetězec řídí jeden pool:

Keyword Výchozí Účinek
Pooling true Povoluje nebo zakazuje sdružování.
Min Pool Size 0 Nastavuje minimální počet fyzických spojení, které si pool zachová po svém vytvoření.
Max Pool Size 100 Nastavuje maximální počet fyzických spojení v poolu.
Connect Timeout 15 sekund Nastavuje, jak dlouho Open se čeká, když není dostupné žádné použitelné připojení.
Load Balance Timeout 0 sekundy Připojení se při návratu do fondu vyřadí, pokud jeho stáří překročí nastavenou hodnotu. Connection Lifetime je alias.

Pool vytváří připojení podle toho, jak poptávka roste, dokud nedosáhne hodnoty Max Pool Size. Když jsou všechna spojení aktivní, pozdější otevření čekají na návrat spojení. Pokud čekání překročí Connect Timeout, otevření selže.

Nezvyšujte Max Pool Size dřív, než zkontrolujete:

  • Každé spojení a čtenář je rozložen na každé cestě.
  • Příkazy a transakce končí rychle.
  • Zátěž dotazů není blokovaná ani přetížená.
  • Limit připojení k databázi zvládne vynásobit Max Pool Size každým poolem v každé instanci aplikace.

Pozitivní Min Pool Size udrží spojení otevřené během období nečinnosti. Používejte ho jen tehdy, když měření ospravedlňují teplé spojení. Obvykle je v rozporu s návrhy typu scale-to-zero, serverless s automatickým pozastavením a burstable cloud architekturami.

Ve výchozím Load Balance Timeout=0nastavení periodické čištění obvykle odstraní nepoužitá spojení nad nimi Min Pool Size po asi čtyřech až osmi minutách, nebo je pool odstraní, když zjistí, že je připojení k serveru přerušeno. Tento interval považujte za chování implementace, ne za záruku nečinnosti na každé spojení. Pool neposílá validační dotaz před každou pokladní, protože tato zpáteční cesta ubírá velkou část výhody poolingu.

Řešení blokačních období autentizace

Po vypršení autentizace nebo jiném selhání autentizace může pool vstoupit do blokovacího období. Během tohoto období odpovídající pokusy o otevření znovu vyvolají původní výjimku, aniž by proběhl další pokus o ověření.

První blokovací období trvá pět sekund. Po dalším neúspěchu se období zdvojnásobí na jednu minutu.

Pool Blocking Period Řídí toto chování:

Value Behavior
Auto Umožňuje blokování pro běžné SQL Server endpointy a deaktivuje ho pro rozpoznané Azure SQL koncové přípony. Anonymní DNS jméno nemusí přijímat chování Azure.
AlwaysBlock Povolí dobu blokování pro každý koncový bod.
NeverBlock Zakáže blokovací období.

Ponechte Auto, pokud návrh mechanismu opakování aplikace založený na měření nevyžaduje jinou volbu. Vypnutí blokovací doby může proměnit problém s přihlašovacím dokumentem, firewallem nebo výpadkem v autentizační bouři.

Blokovací období je oddělené od konfigurovatelné logiky opakovaných pokusů. Poskytovatel opakovaných pokusů, který otevře stejný pool během blokovacího období, obdrží cacheovanou výjimku.

Správa životnosti a vymazání spojení

Pool automaticky vymaže postižený pool, když rozpozná fatální chybu, například při failoveru. Pool uzavírá nečinná připojení a při návratu odškrtnutá připojení vyřazuje.

Použijte clearing API pro známou konfiguraci nebo hranici přihlašovacích údajů:

  • ClearPool vymaže pool spojený s jednou SqlConnection konfigurací.
  • ClearAllPoolsvymaže všechny Microsoft. Data.SqlClient pooly v procesní nebo aplikační doméně.

Bazén uzavírá nečinné spoje v uvolněném bazénu. Bazén označuje spoje, která jsou aktuálně používána, takže je při vrácení vyhodí.

Vymazání poolů způsobí, že pozdější otevření provedou fyzické přihlášení. Nepoužívejte jej jako pravidelnou údržbu, obecný mechanismus pro zpracování chyb ani jako náhradu za uvolňování připojení.

Load Balance Timeout zajišťuje postupnou výměnu podle věku. Používejte ho, když nasazení nebo clusterová služba potřebuje, aby staré fyzické připojení časem odešly. Ujistěte se, že zvolená hodnota nevede k nadměrnému počtu vynucených přímých připojení.

Principy transakcí

Při použití výchozího nastavení Enlist=true se připojení otevřené uvnitř System.Transactions.Transaction.Current automaticky zařadí do této transakce.

Když se spojení zaregistrované do transakce uzavře, fond připojení ho umístí do části vyhrazené pro danou transakci. Později otevřený v rámci stejné transakce ji může znovu použít. Fyzické spojení se do obecného poolu nevrátí, dokud transakce není dokončena.

Dlouhé nebo opuštěné ambientní transakce tedy mohou:

  • Fyzické kontakty držte mimo obecný okruh.
  • Spotřebovávají kapacitu poolu po uzavření logického připojení.
  • Udržujte zámky serverů a stav transakcí živé.

Udržujte transakce krátké, explicitně je ukončujte a sledujte připojení ve stavu stasis. Nastavte Enlist=false pouze tehdy, když musí spojení zůstat mimo okolní transakci.

Zabránit fragmentaci poolu

Fragmentace bazénů vytváří mnoho malých bazénů místo několika znovupoužitelných. Mezi běžné příčiny patří:

  • Rozdíly v pořadí klíčových slov nebo v aliasech připojovacího řetězce.
  • Jeden připojovací řetězec pro každého zákazníka, uživatele, požadavek nebo databázi.
  • Integrovaná autentizace pod mnoha Windows identitami.
  • Nové SqlCredential, zpětné volání přístupového tokenu nebo instance poskytovatele SSPI pro každý požadavek.
  • Tokeny s přímým přístupem, které se mění při každém obnovení.
  • Názvy aplikací s vysokou kardinalitou nebo identifikátory pracovních stanic.

Normalizujte připojovací řetězce pomocí SqlConnectionStringBuilder a centralizujte vytváření připojení.

Pokud se aplikace záměrně připojuje k mnoha databázím nebo identitám, zahrňte výsledný počet poolů do plánování kapacity. Nespouštějte USE s nedůvěryhodným názvem databáze za účelem sloučení poolů. Izolace databáze, oprávnění, stav relace a chování při resetování poolu musí zůstat explicitní.

Zohledněte aplikační role a stav relace

Pool resetuje stav znovupoužitelné relace SQL Server před přiřazením fyzického připojení k jinému logickému spojení. Aplikační kód by měl i nadále nastavovat veškerý potřebný stav relace v rámci vlastní jednotky práce.

Aplikační role serveru SQL Server aktivované pomocí sp_setapprole nelze pro běžné sdružování připojení bezpečně resetovat. Preferujte databázové uživatele, uzavřené uživatele, role, zabezpečení na úrovni řádku nebo jiný autorizační design. Pokud je role aplikace nevyhnutelná, použijte zdokumentovaný vzor obrácení založený na cookies nebo po testování vypněte pooling pro tuto izolovanou cestu.

Zlikvidujte čtečky, dokončujte nebo vraťte transakce zpět a nenechávejte příkazy běžet po uzavření připojení. Nespoléhejte na to, že dočasné tabulky nebo jiný stav relace přetrvají napříč logickými připojeními.

Používejte cloudové poolingové vzory

For Azure App Service, Azure Functions, containers, Kubernetes a další horizontálně skalované hosty:

  • Spočítejte možné databázové spojení napříč všemi instancemi, procesy, klíči poolu a replikami.
  • Použijte spravovanou identitu nebo stabilní zpětné volání pro přístupový token místo obměňování řetězců tokenů v objektech připojení.
  • Ponechte Min Pool Size=0, ledaže naměřený požadavek na cold start odůvodňuje zachování relací.
  • Očekávejte, že nová instance začne s prázdným poolem.
  • Udržujte spojovací řetězce identické napříč instancemi, které obsluhují stejnou pracovní zátěž.
  • Omezte pokusy o připojení a jejich opakování, aby se během převzetí služeb při selhání nebo horizontálního škálování předešlo nárazovým vlnám synchronizovaných přihlášení.
  • Nastavte MultiSubnetFailover=true pro Azure SQL a další podporované koncové body TCP s více adresami.

Pooly připojení jsou lokální pro proces žádosti. Nejsou sdíleny napříč instancemi aplikace, kontejnery nebo hostiteli.

Diagnostikujte chování skupiny

Použijte diagnostické čítače SqlClient k pozorování:

  • Pevná připojení a odpojení, což představuje fyzická serverová připojení.
  • Měkké připojení a odpojení, které představují odchod a návrat do poolu.
  • Aktivní a volně sdílená připojení.
  • Aktivní skupiny bazénů a bazény.
  • Připojení Stasis.
  • Obnovené spojení tam, kde aplikační kód logické spojení nezlikvidoval.

Korelujte čítače klienta s relacemi, čekáními, blokováním a limity prostředků v SQL Serveru. Časový limit poolu může znamenat únik spojení, pomalé dotazy, blokované transakce, příliš velkou souběžnost, fragmentaci poolu nebo omezení kapacity databáze.

Použijte trasování pomocí zdroje událostí pro cílené trasování pooleru. Trasování je příliš podrobné. Zapněte ho pro omezené diagnostické okno a chraňte všechna zachycená metadata spojení.

Kontrolní seznam pro produkční prostředí

  • Poolování stále zapínám.
  • Používejte jeden kanonický připojovací řetězec pro každou zátěž a databázi.
  • Zbavejte se spojení, příkazů, čteček a transakcí na každé cestě.
  • Znovu použijte instance přihlašovacích údajů, zpětného volání tokenu a poskytovatele SSPI.
  • Nastavte omezené časové limity pro připojení a příkazy.
  • Nastavte celkový rozpočet připojení napříč každou instancí aplikace.
  • Sledujte navázaná spojení, počty připojení v poolech, volná připojení, nečinnost a časové limity.
  • Vymažte pooly pouze pro přihlašovací údaje, tokeny nebo hranice konfigurace, které poskytovatel nedokáže odhalit, nebo když diagnostika potvrdí, že spojení zůstávají zastaralá.
  • Zátěžově otestujte horizontální škálování, převzetí služeb při selhání a chování při obnovení přihlašovacích údajů před nasazením do produkce.

Související obsah

  • Last updated on