SQL Server-anslutningspoolning med Microsoft. Data.SqlClient

Microsoft. Data.SqlClient anslutningspoolning återanvänder autentiserade fysiska anslutningar. SqlConnection.Open eller OpenAsync kontrollerar en pool för en användbar anslutning. Close, Dispose, eller DisposeAsync återställer och returnerar den. Denna metod undviker nätverksanslutning, autentisering och sessionsinstallation för varje operation.

Pooling är aktiverat som standard. Använd detta appliceringsmönster:

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

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

Öppna sent, stäng tidigt och låt poolen hantera de fysiska anslutningarna. Ha inte en SqlConnection öppen globalt.

Förstå poolnycklar

En anslutning kan endast återanvändas från sin motsvarande pool. Poolnyckeln inkluderar mer än bara destinationsservern.

Databasen, autentiseringsläget, krypteringsalternativen, applikationsnamn, poolalternativ och alla andra värden på reťazec pripojenia bidrar via exakt samma sträng.

Bygg en kanonisk anslutningssträng och återanvänd den. Undvik per-request-värden i Application Name, Workstation ID, eller andra nyckelord.

Välj token-API:er som kan poolas

För Microsoft Entra ID-åtkomsttokens, använd ett autentiseringsläge som tillhandahålls av Microsoft. Data.SqlClient eller en stabil AccessTokenCallback.

AccessTokenCallbackintroducerades i Microsoft. Data.SqlClient 5.2. Drivrutinen anropar den när den behöver en token och kan begära en uppdaterad token för en återanvänd pool. Se till att återanropet är deterministiskt för de autentiseringsparametrar som drivrutinen tillhandahåller, och återanvänd samma delegatinstans.

När koden ställer in AccessToken direkt:

• Tokensträngen blir en del av poolnyckeln.
• Applikationen ansvarar för tokenutgång och förnyelse.
• En poolad fysisk anslutning kan överleva tokenen som användes för att skapa den.
• Ring ClearPool efter att ha bytt ut en utgången token om den poolen inte längre kan användas säkert.

Skapa inte en ny callback-lambda eller ett nytt legitimationsobjekt för varje förfrågan. Skillnader i objektidentitet kan fragmentera poolerna.

Microsoft. Data.SqlClient 7.0 lägger till SspiContextProvider för anpassad Kerberos- eller NTLM-förhandling. Behandla leverantören som applikationsbaserad anslutningskonfiguration, inte som ett per-förfrågan tillstånd.

Storlek på varje pool

Dessa anslutningssträngsalternativ styr en pool:

Poolen skapar kopplingar när efterfrågan ökar tills den når Max Pool Size. När alla anslutningar används väntar senare anslutningsförsök tills en anslutning blir tillgänglig igen. Om väntetiden överskrider Connect Timeout, misslyckas öppningen.

Höj inte Max Pool Size innan du kontrollerar:

• Varje koppling och läsare är placerad på varje väg.
• Kommandon och transaktioner slutförs snabbt.
• Frågebelastningen är varken blockerad eller överbelastad.
• Gränsen för databasanslutningar klarar av Max Pool Size multiplicerat med antalet pooler i varje applikationsinstans.

En positiv Min Pool Size håller kontakterna öppna under viloperioder. Använd den bara när mätningar motiverar varma anslutningar. Det motverkar vanligtvis nedskalning till noll, serverlösa lösningar med automatisk paus och molnarkitekturer som är skalbara för tillfälliga belastningstoppar.

Med standard Load Balance Timeout=0tar periodisk rensning normalt bort oanvända anslutningar ovanför Min Pool Size efter cirka fyra till åtta minuter, eller så tar poolen bort dem när den upptäcker att serveranslutningen är bruten. Behandla det intervallet som ett implementeringsbeteende, inte som någon garanti för inaktivitet per anslutning. Poolen skickar inte en valideringsfråga före varje utcheckning eftersom den rundresan tar bort mycket av poolningsfördelen.

Hantera blockeringsperioder för autentisering

Efter en autentiseringstidsavslutning eller annat autentiseringsfel kan poolen gå in i en blockeringsperiod. Under den perioden utlöser motsvarande öppningsförsök det ursprungliga undantaget på nytt utan att göra ett nytt autentiseringsförsök.

Den första blockeringsperioden är fem sekunder. Efter ytterligare ett misslyckande förlängs perioden till en minut.

Pool Blocking Period kontrollerar detta beteende:

Behåll Auto om inte programmets uppmätta återförsöksstrategi kräver ett annat val. Att inaktivera blockeringsperioden kan förvandla ett problem med inloggningsuppgifter, brandväggar eller avbrott till en autentiseringsstorm.

Blockeringsperioden är separat från konfigurerbar återförsökslogik. En återprövningsleverantör som öppnar samma pool under en blockeringsperiod får det cachade undantaget.

Hantera anslutningens livslängd och rensning

Poolen rensar automatiskt den berörda poolen när den känner igen ett fatalt fel, såsom en failover. Anslutningspoolen stänger inaktiva anslutningar och kasserar anslutningar som har lånats ut när de lämnas tillbaka.

Använd rensnings-API:erna för en känd konfiguration eller inloggningsgräns:

• ClearPool rensar poolen som är kopplad till en konfiguration SqlConnection .
• ClearAllPoolsrensar varje Microsoft. Data.SqlClient-pool i process- eller applikationsdomänen.

Poolen stänger lediga anslutningar i en rensad pool. Poolen markerar de anslutningar som används för tillfället så att de kasseras när de returneras.

Att tömma pooler leder till att senare öppningar kräver fysiska inloggningar. Använd den inte som periodiskt underhåll, allmän felhantering eller som ersättning för att göra sig av med anslutningar.

Load Balance Timeout ger gradvis åldersbaserad omsättning. Använd den när en distribution eller klustrat tjänst behöver gamla fysiska anslutningar att försvinna över tid. Bekräfta att det valda värdet inte orsakar överdrivna hårda anslutningar.

Förstå transaktioner

Med Enlist=true, som standardinställning, ansluts en anslutning som öppnas inuti System.Transactions.Transaction.Current automatiskt till den transaktionen.

När en anslutning som är registrerad i en transaktion stängs placerar anslutningspoolen den i en transaktionsspecifik undergrupp. Ett senare öppnande inom samma transaktion kan återanvända den. Den fysiska anslutningen återvänder inte till den allmänna poolen förrän transaktionen är slutförd.

Långa eller övergivna ambienta transaktioner kan därför:

• Håll fysiska kontakter utanför den allmänna poolen.
• Förbruka poolkapacitet efter att den logiska anslutningen stängts.
• Håll serverlås och transaktionstillstånd vid liv.

Håll transaktionerna avgränsade, slutför dem uttryckligen och övervaka anslutningar i stasisläge. Ställ in Enlist=false endast när anslutningen måste förbli utanför en omgivande transaktion.

Förhindra poolfragmentering

Poolfragmentering skapar många små pooler istället för några få återanvändbara pooler. Vanliga orsaker är bland annat:

• Anslutningssträngens nyckelordsordning eller skillnader i alias.
• En reťazec pripojenia per kund, användare, förfrågan eller databas.
• Integrerad autentisering under många Windows-identiteter.
• Nya SqlCredential, åtkomsttoken-callback, eller SSPI-leverantörsinstanser per förfrågan.
• Direktåtkomsttokens som ändras vid varje uppdatering.
• Applikationsnamn eller arbetsstations-ID med hög kardinalitet.

Normalisera anslutningssträngar med SqlConnectionStringBuilder och centralisera skapandet av anslutningar.

Om applikationen medvetet ansluter till många databaser eller identiteter, inkludera det resulterande poolantalet i kapacitetsplaneringen. Kör inte USE med ett otillförlitligt databasnamn för att slå samman pooler. Databasisolering, behörigheter, sessionstillstånd och återställningsbeteende för poolen måste förbli explicita.

Ta hänsyn till applikationsroller och sessionstillstånd

Poolen återställer återanvändbart SQL Server-sessionstillstånd innan en fysisk anslutning tilldelas en annan logisk anslutning. Applikationskoden bör fortfarande ange vilket sessionstillstånd som helst inom sin arbetsenhet.

SQL Server-applikationsroller som aktiveras med sp_setapprole kan inte återställas säkert för vanlig pooling. Föredra databasanvändare, inneslutna användare, roller, radnivåsäkerhet eller annan auktorisationsdesign. Om en applikationsroll är oundviklig, använd ett dokumenterat cookiebaserat reverseringsmönster eller inaktivera poolning för den isolerade vägen efter testning.

Släng läsare, avsluta eller rulla tillbaka transaktioner, och låt inte kommandon köras när anslutningen stängs. Lita inte på att tillfälliga tabeller eller annat sessionstillstånd överlever över logiska anslutningar.

Använd molnhostade poolningsmönster

För Azure App Service, Azure Functions, containrar, Kubernetes och andra horisontellt skalade värdar:

• Beräkna möjliga databasanslutningar över alla instanser, processer, poolnycklar och repliker.
• Använd managed identity eller en stabil åtkomsttoken-callback istället för att rotera tokensträngar i anslutningsobjekt.
• Behåll Min Pool Size=0 om inte ett uppmätt krav på kallstart motiverar bibehållna sessioner.
• Räkna med att en ny instans startar med en tom pool.
• Behåll anslutningssträngarna identiska mellan instanser som hanterar samma arbetsbelastning.
• Begränsa anslutningsförsök och återförsök för att undvika synkroniserade inloggningstoppar vid redundansväxling eller utskalning.
• Ställ MultiSubnetFailover=true in för Azure SQL och andra stödda fleradresserade TCP-endpoints.

Anslutningspooler är lokala för ansökningsprocessen. De delas inte mellan applikationsinstanser, containrar eller värdar.

Diagnostisera poolbeteende

Använd SqlClient-diagnostiska räknare för att observera:

• Hårda anslutningar och frånkopplingar, som representerar fysiska serveranslutningar.
• Mjuka anslutningar och frånkopplingar, som representerar poolutcheckning och retur.
• Aktiva och fria poolade anslutningar.
• Aktiva poolgrupper och pooler.
• Stasisanslutningar.
• Återvunna anslutningar där applikationskoden inte tog bort den logiska kopplingen.

Korrelera klienträknare med SQL Server-sessioner, väntetider, blockeringar och resursbegränsningar. En pool-timeout kan innebära en anslutningsläcka, långsamma frågor, blockerade transaktioner, för mycket samtidighet, poolfragmentering eller en kapacitetsbegränsning i databasen.

Använd spårning av händelsekällor för riktad spårning för poolaren. Spårning är utförlig. Aktivera det för ett begränsat diagnostikfönster och skydda all infångad anslutningsmetadata.

Checklista för produktion

• Behåll pooling aktiverat.
• Återanvänd en standardiserad anslutningssträng per arbetsbelastning och databas.
• Gör dig av med anslutningar, kommandon, läsare och transaktioner på varje väg.
• Återanvänd legitimation, token-callback och SSPI-leverantörsinstanser.
• Ställ in ändliga tidsgränser för anslutning och kommando.
• Dimensionera den totala anslutningsbudgeten över varje applikationsinstans.
• Övervaka hårda uppkopplingar, antal anslutningspooler, lediga anslutningar, stillestånd och tidsgränser.
• Rensa endast pooler för en autentiseringsuppgift, token eller konfigurationsavgränsning som providern inte kan upptäcka, eller när diagnostiken bekräftar att inaktuella anslutningar kvarstår.
• Testa skalning, redundansväxling och uppdatering av autentiseringsuppgifter före produktionssättning.

Relaterat innehåll

• Koppla till en datakälla
• Anslutningssträngar
• Anslutningsalternativ.
• SqlClient-diagnostikräknare
• Konfigurerbar omprövningslogik
• Microsoft Entra ID-autentisering