SQL Server-kapcsolatközösítés a Microsoft.Data.SqlClient használatával

A Microsoft.Data.SqlClient kapcsolat-összevonása újra felhasználja a hitelesített fizikai kapcsolatokat. SqlConnection.Open vagy OpenAsync ellenőrzi, hogy a kapcsolatkészletben van-e használható kapcsolat. Close, Dispose vagy DisposeAsync visszaállítják és visszaadják azt. Ez a megközelítés szükségtelenné teszi a hálózati kapcsolatot, a hitelesítést és a munkamenet létrehozását minden műveletnél.

A pooling alapértelmezés szerint engedélyezett. Használd ezt az alkalmazási mintát:

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

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

Későn nyitodj ki, korán dobd el, és hagyd, hogy a medence kezelje a fizikai kapcsolatokat. Ne tartsd a SqlConnection elemet globálisan nyitva.

Válasszon egy connection pool megvalósítást

A SqlClient két kapcsolati pool implementációt tartalmaz. A V1 pool az alapértelmezett. A Microsoft.Data.SqlClient 7.1-es verziójától kezdve választhatod a csatornaalapú V2 poolt, ha az alkalmazás indításakor a true AppContext kapcsolót Switch.Microsoft.Data.SqlClient.UseConnectionPoolV2 értékre állítod:

AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseConnectionPoolV2", true);

A kapcsolati karakterlánc pooling vezérlése mindkét megvalósításra érvényes. További információért a kapcsolóról és annak alapértelmezett beállításáról lásd: Engedélyezd a V2 kapcsolati poolt.

Értsd meg a pool kulcsokat

Egy kapcsolatot csak a hozzá tartozó poolból lehet újra felhasználni. A pool kulcs többet tartalmaz, mint a célszerver.

Input Medence viselkedés
Csatlakozási karakterlánc A szövegnek pontosan egyeznie kell. A kulcsszósorrendi különbségek külön poolokat hoznak létre, még akkor is, ha az effektív beállítások egyenértékűek.
Integrált Windows-hitelesítés A Windows identitása a kulcs része. Ugyanaz a karakterlánc különböző azonosítókkal használva különböző poolokat hoz létre.
SqlCredential Az objektumpéldány a kulcs része. Különálló példányok külön poolokat hoznak létre, még akkor is, ha ugyanazt a felhasználónevet és jelszót tartalmazzák.
SqlConnection.AccessToken A hozzáférési token értéke a kulcs része. A token stringek cseréje új poolokat hozhat létre, és a meglévő poolokban régi tokenekkel hitelesített kapcsolatokat hagyhat.
SqlConnection.AccessTokenCallback A visszahívás a kulcs része. Használd újra ugyanazt a visszahívási példányt azokhoz a kapcsolatokhoz, amelyeknek közös kapcsolatkészletet kell használniuk. A visszaadott token érték nem a pool kulcs.
Egyéni SSPI-kontextusszolgáltató A szolgáltatópéldány részt vesz a kapcsolat konfigurálásában. Használjon egyazon szolgáltatópéldányt azokhoz a kapcsolatokhoz, amelyeknek ugyanazt a kapcsolatpoolt kell használniuk.
Környezeti tranzakció A regisztrált kapcsolatok tranzakcióspecifikus alosztásokat használnak a megfelelő poolon belül.

Az adatbázis, hitelesítési mód, titkosítási lehetőségek, alkalmazásnév, pooling opciók és minden más kapcsolati karakterlánc érték pontosan a stringen keresztül járul hozzá.

Építs egy kanonikus kapcsolati karakterlánc-et, és használd újra. Ne használjon kérésenkénti értékeket a Application Name, Workstation ID vagy más kulcsszavakban.

Válassz olyan token API-kat, amelyek összevonhatók

A Microsoft Entra ID hozzáférési tokenjeihez használjon a Microsoft.Data.SqlClient által biztosított hitelesítési módot vagy egy stabil AccessTokenCallback-t.

AccessTokenCallback a Microsoft.Data.SqlClient 5.2-ben került bevezetésre. Az illesztőprogram ezt akkor hívja meg, ha tokenre van szüksége, és kérhet egy frissített tokent egy újra felhasznált készlethez. A visszahívás legyen determinisztikus az illesztőprogram által megadott hitelesítési paraméterek esetén, és ugyanazt a delegate-példányt használd újra.

Amikor a kód közvetlenül beállítja a(z) AccessToken értéket:

  • A token string a pool kulcs részévé válik.
  • Az alkalmazás kezeli a token lejáratát és frissítését.
  • Egy összekötött fizikai kapcsolat túlélheti a létrehozásához használt tokent.
  • Hívj ClearPool egy lejárt token cseréje után, ha az a pool már nem használható biztonságosan.

Ne hozz létre új callback lambda-t vagy credential objektumot minden kéréshez. Az objektumidentitás különbségei széttörhetik a medencéket.

A Microsoft.Data.SqlClient 7.0 hozzáadja a SspiContextProvider elemet az egyéni Kerberos- vagy NTLM-egyeztetéshez. A providert alkalmazásszintű kapcsolatkonfigurációként kezeld, ne kérésenkénti állapotként.

Állítsa be az egyes medencék méretét

Ezek a kapcsolati karakterlánc opciók egy poolt irányítanak. A teljes kulcsszó hivatkozásért lásd ConnectionString.

Keyword Alapértelmezett Effect
Pooling true Lehetővé teszi vagy letiltja a csoportosítást.
Min Pool Size 0 Megadja a minimális fizikai kapcsolatok számát, amelyet a pool megtart a létrehozása után.
Max Pool Size 100 A medencében a maximális fizikai kapcsolatok számát állítja be.
Connect Timeout 15 másodperc Meghatározza, mennyi Open várakozás van, amikor nincs használható kapcsolat.
Load Balance Timeout 0 másodperc Ha az életkora meghaladja a beállított értéket, akkor eldobja a kapcsolatot, amikor visszatér a poolhoz. Connection Lifetime egy alias.
Connection Idle Timeout 300 A 7.1.0-s verziótól kezdve ennyi másodperc után a beállítás alkalmassá teszi a tétlen kapcsolatot az eltávolításra. A 0 érték letiltja az üresjárati lejáratot. A végrehajtáshoz az UseLegacyIdleTimeoutBehavior AppContext kapcsolót false értékre kell állítani.

A medence kapcsolatokat hoz létre a kereslet növekedésével, amíg el nem éri Max Pool Size. Amikor minden kapcsolat használatban van, a későbbi nyitások várják, hogy visszatérjen a kapcsolat. Ha a várakozás meghaladja a(z) Connect Timeout értéket, a megnyitás sikertelen.

Ne emelje fel Max Pool Size ellenőrzés előtt:

  • Minden kapcsolat és olvasóegység minden útvonalon van elhelyezve.
  • A parancsok és tranzakciók gyorsan befejeződnek.
  • A lekérdezési munkaterhelés nincs blokkolva vagy telített.
  • Az adatbázis-kapcsolatok maximális száma minden alkalmazáspéldány minden kapcsolatkészletére vetítve a Max Pool Size-szorosát képes kezelni.

A pozitív Min Pool Size nyitva tartja a kapcsolatokat az inaktív időszakok alatt. Csak akkor használd, ha a mérések indokolják a meleg csatlakozásokat. Általában nem kedvez a nullára skálázásnak, a szervermentes automatikus szüneteltetésnek és a rugalmasan skálázható felhőarchitektúráknak.

Az alapértelmezett Load Balance Timeout=0 beállítás mellett az időszakos tisztítás általában körülbelül négy-nyolc perc elteltével eltávolítja a Min Pool Size feletti, nem használt kapcsolatokat, vagy a kapcsolatkészlet akkor távolítja el őket, amikor észleli, hogy a kiszolgálókapcsolat megszakadt. Tekintse ezt az intervallumot implementációs viselkedésnek, ne pedig kapcsolatonkénti tétlenségi garanciának. A pool nem küld minden kifizetés előtt validációs lekérdezést, mert ez a körút elveszi a csoportosítás előnyeit.

Kapcsolódási tétlenségi idő korlátozása

A Microsoft.Data.SqlClient 7.1.0-tól kezdve Connection Idle Timeout használatával konfigurálhatók az üresjárati lejárati ellenőrzések és a háttértisztítás a kapcsolatkészletben lévő kapcsolatokhoz. Az alapértelmezett érték 300 másodperc. A 0 érték letiltja az inaktivitási lejáratot. Negatív értékek esetén ArgumentException kivétel keletkezik.

Connection Idle Timeout=120

Azt is beállíthatodSqlConnectionStringBuilder.IdleTimeout, a kapcsolati karakterlánc létrehozásakor:

var builder = new SqlConnectionStringBuilder(connectionString)
{
    IdleTimeout = 120
};

Az inaktivitási időkorlát érvényesítése opcionális. Állítsa be a következő AppContext kapcsolót false értékre az alkalmazás indításakor:

AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseLegacyIdleTimeoutBehavior", false);

A switch és kapcsolati karakterlánc beállítása minden pool megvalósítását másképp befolyásolja:

  • V1 medence. Amikor a kapcsoló true, a V1 a korábban használt véletlenszerű, két-négy perces tisztítási ritmusát használja, és eltávolítja a tétlen kapcsolatokat, függetlenül attól, hogy Connection Idle Timeout. Ha a kapcsoló false, és Connection Idle Timeout nem nulla, a V1 tisztítási ütemként a beállított időkorlát felét használja, és egy-két tisztítási ciklus után eltávolítja az inaktív kapcsolatokat. Amikor a kapcsoló false és Connection Idle Timeout=0, a V1 letiltja a tétlen elemek eltávolítását, de továbbra is fenntartja a minimális készletméretet a korábban használt, véletlenszerű két–négy perces időközönként.
  • V2 készlet. Ha a kapcsoló true, a V2 nem végez kapcsolatonként alapjárati időméréseket, de egy nem nulla Connection Idle Timeout engedélyezi és konfigurálja a háttérben végzett ritkítást. Ha a kapcsoló false, és a(z) Connection Idle Timeout nem nulla, a V2 kapcsolatonkénti üresjáratiidő-ellenőrzéseket végez, és az időkorlát alapján konfigurálja a háttérbeli tisztítást. Amikor a kapcsoló false és Connection Idle Timeout=0 állapotban van, a V2 nem végez kapcsolatonként üresjárati kor ellenőrzéseket vagy háttérben végzett tisztítást. A V2 nem végez háttérmetszést, ha Min Pool Size nagyobb vagy egyenlő, mint Max Pool Size.

Mindkét poolmegvalósítás eltávolít egy kapcsolatot, ha a pooler észleli, hogy megszakadt a kapcsolat a szerverrel.

Kezelni a hitelesítési blokkoló időszakokat

Hitelesítési időkorlát vagy más hitelesítési hiba után a pool blokkolási időszakba léphet. Ebben az időszakban a megnyitott egyeztetési kísérletek újraindítják az eredeti kivételt anélkül, hogy újabb hitelesítési kísérletet végeznének.

Az első blokkolási időszak öt másodperc. Újabb sikertelen próbálkozás után az időszak egy percre nő.

Pool Blocking Period Szabályozza ezt a viselkedést:

Érték Viselkedés
Auto Lehetővé teszi a blokkolást a hagyományos SQL Server végpontoknál, és letiltja a felismert Azure SQL végvégpontok utótagjainál. Előfordulhat, hogy egy egyéni DNS-név nem az Azure-ra jellemző módon viselkedik.
AlwaysBlock Engedélyezi a blokkolási időszakot minden végpontnál.
NeverBlock Letiltja a blokkolási időszakot.

Tartsd Auto meg, hacsak az alkalmazás mértékelt újrapróbálkozási kialakítása nem igényel más választást. A blokkolási időszak kikapcsolása a hitelesítő adatokkal, a tűzfallal vagy a szolgáltatáskimaradással kapcsolatos problémát hitelesítési viharrá alakíthatja.

A blokkolási időszak külön a konfigurálható újrapróbálkozási logikától. Egy újrapróbálási szolgáltató, amely ugyanazt a poolot nyitja meg egy blokkolási időszak alatt, megkapja a gyorsítótározott kivételt.

A kapcsolat élettartamának és az elszámolás kezelése

A pool automatikusan töröli az érintett poolt, ha halálos hibát, például failovert észlel. A medence lezárja az üres kapcsolatokat, és a kifizetett csatlakozásokat eldobja, amikor visszatérnek.

Használd a clearing API-kat egy ismert konfigurációhoz vagy hitelesítési határhoz:

  • ClearPool megtisztítja az egyetlen SqlConnection konfigurációhoz tartozó medencét.
  • ClearAllPoolsminden Microsoft. Data.SqlClient pool-ot töröl a folyamatban vagy alkalmazási tartományban.

A medence lezárja az üres csatlakozókat egy tisztított medencében. A medence megjelöli a jelenleg használt kapcsolatokat, így visszaküldéskor eldobja őket.

A készletek törlése miatt a későbbi megnyitások fizikai bejelentkezést végeznek. Ne használd időszakos karbantartásként, általános hibakezelőként vagy a csatlakozások eldobásának helyettesítésére.

Load Balance Timeout fokozatos életkor szerinti fluktuációt biztosít. Használd ezt, amikor egy telepítésnek vagy fürtözött szolgáltatásnak arra van szüksége, hogy a régi fizikai kapcsolatok idővel megszűnjenek. Győződj meg róla, hogy a kiválasztott érték nem okoz túl sok kényszerített kapcsolódást.

Tranzakciók ismertetése

A(z) Enlist=true használatakor alapértelmezés szerint a System.Transactions.Transaction.Current belsejében megnyitott kapcsolat automatikusan csatlakozik ahhoz a tranzakcióhoz.

Amikor egy bejegyzett kapcsolat bezárul, a pool egy tranzakcióspecifikus alosztályba helyezi azt. Egy későbbi megnyitás ugyanabban a tranzakcióban újra felhasználhatja azt. A fizikai kapcsolat csak akkor tér vissza az általános poolba, amikor a tranzakció befejeződik.

A hosszú ideig futó vagy elhagyott ambient tranzakciók ezért a következőket eredményezhetik:

  • Tartsd távol a fizikai kapcsolatokat az általános készlettől.
  • A logikai kapcsolat zárása után használd fel a medence kapacitását.
  • Tartsd életben a szerverzárolásokat és a tranzakciós állapotot.

A tranzakciókat tartsd korlátok között, explicit módon zárd le őket, és monitorozd a stáziskapcsolatokat. Enlist=false csak akkor állítsa be, ha a kapcsolatnak a környezeti tranzakción kívül kell maradnia.

A pool fragmentáció megelőzése

A medence fragmentáció sok kis medencét hoz létre néhány újrahasználható medence helyett. A gyakori kiváltó okok között a következőket találjuk:

  • A kapcsolati sztring kulcsszavainak sorrendje vagy az álnevek közötti különbségek.
  • Ügyfelenként, felhasználónként, kérésenként vagy adatbázisonként egy kapcsolati karakterlánc.
  • Integrált hitelesítés sok Windows identitás alatt.
  • Új SqlCredential, hozzáférési tokenhez tartozó visszahívási függvény vagy SSPI-szolgáltatópéldányok kérésenként.
  • Közvetlen hozzáférésű tokenek, amelyek minden frissítéskor változnak.
  • Magas kardinalitású alkalmazásnevek vagy munkaállomásazonosítók.

Normalizáld a kapcsolati sztringeket a(z) SqlConnectionStringBuilder használatával, és központosítsd a kapcsolat létrehozását.

Ha az alkalmazás szándékosan sok adatbázishoz vagy azonosítóhoz csatlakozik, akkor a kapott poolszámot is belefoglalják a kapacitástervezésbe. Ne futtasd a USE elemet nem megbízható adatbázisnévvel, mert az a készletek összevonását eredményezheti. Az adatbázis izolálásának, jogosultságoknak, session állapotának és a pool visszaállításának viselkedésének explicit maradnia kell.

Az alkalmazásszerepkörökhöz és a munkamenet állapotához tartozó fiók

A pool visszaállítja az újrahasználható SQL Server munka-alkalomállapotát, mielőtt egy másik logikai kapcsolathoz rendelné a fizikai kapcsolatot. Az alkalmazáskódnak továbbra is be kell állítania a szükséges session állapotot a munkaterületen belül.

A sp_setapprole használatával aktivált SQL Server-alkalmazásszerepkörök nem állíthatók vissza biztonságosan normál kapcsolatkészlet-kezeléshez. Részesítse előnyben az adatbázis-felhasználókat, az önálló felhasználókat, a szerepköröket, a sorszintű biztonságot vagy más jogosultságkezelési modellt. Ha egy alkalmazás szerep elkerülhetetlen, használj dokumentált cookie-alapú visszafordítási mintát, vagy tiltsd le a pooling-et ezen az izolált úton tesztelés után.

Dobd el az olvasókat, fejezd be vagy fordítsd vissza a tranzakciókat, és ne hagyd a parancsokat futva, amikor a kapcsolat zárul. Ne számíts arra, hogy az ideiglenes táblák vagy más munkamenetállapotok megmaradnak a logikai kapcsolatok között.

Használj felhőben üzemeltetett készletkezelési megoldásmintákat

Azure App Service, Azure Functions, containers, Kubernetes és más horizontally scaled hosts esetén:

  • Számold ki az összes példány, folyamat, pool kulcs és replika lehetséges adatbázis-kapcsolatait.
  • Használj menedzselt identitást vagy stabil hozzáférési token visszahívást a token stringek forgatása helyett a kapcsolati objektumokban.
  • Tartsa meg a Min Pool Size=0 elemet, kivéve, ha egy mért hidegindítási követelmény indokolja a megőrzött munkameneteket.
  • Arra számítson, hogy egy új példány üres tárral indul.
  • Tartsd a kapcsolati láncokat azonosnak azokon az instancekban, amelyek ugyanazt a terhelést szolgálják.
  • Korlátozza a kapcsolódási kísérletek és az újrapróbálkozások számát, hogy elkerülje a szinkronizált bejelentkezési rohamokat feladatátvétel vagy horizontális bővítés során.
  • Beállítás MultiSubnetFailover=true az Azure SQL-hez és más támogatott többcímű TCP-végpontokhoz.

A csatlakozási poolok a jelentkezési folyamathoz kapcsolódnak. Nem osztoznak meg alkalmazáspéldányok, konténerek vagy hosztok között.

Medence viselkedés diagnosztizálása

Használd a SqlClient diagnosztikai számlálókat a következő megfigyelésre:

  • Kemény kapcsolatok és megszakítások, amelyek fizikai szerver kapcsolatokat képviselnek.
  • A lágy csatlakozások és megszakítások a medencébe való kilépést és visszaküldést jelentik.
  • Aktív és ingyenes közös kapcsolatok.
  • Aktív medencés csoportok és medencék.
  • Stázis kapcsolatok.
  • Visszaszerzett kapcsolatok, amelyeknél az alkalmazáskód nem szabadította fel a logikai kapcsolatot.

Korreláljuk az ügyfélszámlálókat az SQL Server munkamenetekkel, várakozásokkal, blokkolásával és erőforrás-korlátokkal. A kapcsolatkészlet időkorlátja jelenthet kapcsolatszivárgást, lassú lekérdezéseket, blokkolt tranzakciókat, túl nagy egyidejű terhelést, a kapcsolatkészlet töredezettségét vagy az adatbázis kapacitáskorlátját.

Használj eseményforrás követést célzott pooler nyomokhoz. A nyomkövetés bőbeszédű. Engedélyezd egy korlátozott diagnosztikai ablakhoz, és védd meg a rögzített kapcsolat metaadatait.

Éles ellenőrzőlista

  • Hagyd bekapcsolva a poolingot.
  • Használj újra egy kanonikus kapcsolati karakterlánc-et minden munkaterhelésre és adatbázisra.
  • A kapcsolatokat, parancsokat, olvasókat és tranzakciókat minden útvonalon elhelyezz.
  • Használd újra a hitelesítő adatok, a tokenes visszahívási függvény és az SSPI-szolgáltató példányait.
  • Állíts be véges kapcsolati és parancsidőkorlátokat.
  • Tervezze meg a teljes kapcsolatkeretet az összes alkalmazáspéldány között.
  • Figyeld a létrehozott kapcsolatokat, a kapcsolatkészletek számát, a szabad kapcsolatokat, a stagnálást és az időtúllépéseket.
  • Tisztítsd ki a poolokat csak olyan hitelesítés, token vagy konfigurációs határ esetén, amelyet a szolgáltató nem tud észlelni, vagy amikor a diagnosztika megerősíti, hogy megmaradt elavult kapcsolatok.
  • Tesztelje terheléses teszttel a horizontális skálázás, a feladatátvétel és a hitelesítő adatok frissítésének működését az éles üzembe helyezés előtt.

Kapcsolódó tartalom

  • Utolsó frissítés időpontja: