Megosztás a következőn keresztül:

Memóriakezelési architektúra útmutatója

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Windows Virtual Memory Manager

A címtér lekötött területeit a Windows Virtual Memory Manager (VMM) leképezi a rendelkezésre álló fizikai memóriára.

A különböző operációs rendszerek által támogatott fizikai memória mennyiségéről további információt a Windows-kiadások memóriakorlátairól szóló Windows-dokumentációban talál.

A virtuális memóriarendszerek lehetővé teszik a fizikai memória túlvállalását, így a virtuális és a fizikai memória aránya meghaladhatja az 1:1-et. Ennek eredményeképpen a nagyobb programok különböző fizikai memóriakonfigurációkkal rendelkező számítógépeken is futtathatók. Ha azonban az összes folyamat összesített átlagos munkakészleténél jelentősen több virtuális memóriát használ, az rossz teljesítményt okozhat.

SQL Server memóriaarchitektúra

Az SQL Server szükség szerint dinamikusan szerzi be és szabadít fel memóriát. A rendszergazdáknak általában nem kell megadniuk, hogy mennyi memóriát kell lefoglalni az SQL Serverhez, bár a lehetőség továbbra is létezik, és bizonyos környezetekben szükség van rá.

Az adatbázisszoftverek egyik elsődleges tervezési célja a lemez I/O-jának minimalizálása, mivel a lemez olvasása és írása a leginkább erőforrás-igényes műveletek közé tartozik. Az SQL Server pufferkészletet hoz létre a memóriában az adatbázisból beolvasott lapok tárolásához. Az SQL Server kódjának nagy része a lemez és a pufferkészlet közötti fizikai olvasások és írások számának minimalizálására szolgál. Az SQL Server két cél közötti egyensúlyt próbál elérni:

  • Tartsa távol a pufferkészletet attól, hogy olyan nagy legyen, hogy az egész rendszer kevés memóriával rendelkezik.
  • A pufferkészlet méretének maximalizálásával minimalizálhatja az adatbázisfájlok fizikai I/O-ját.

A nagy terhelésű rendszerekben egyes nagy méretű lekérdezések, amelyek nagy mennyiségű memóriát igényelnek a futtatáshoz, nem kapják meg a kért memória minimális mennyiségét, és időtúllépési hibát kapnak a memóriaerőforrásokra való várakozás során. A probléma megoldásához növelje a lekérdezés várakozási beállítását. Párhuzamos lekérdezés esetén érdemes lehet csökkenteni a párhuzamossági érték maximális mértékét .

A memóriaterhelés alatt álló, erősen betöltött rendszerekben a lekérdezéstervben egyesítési illesztéssel, rendezéssel és bitképpel rendelkező lekérdezések eldobhatják a bitképet, ha a lekérdezések nem kapják meg a bitkép minimálisan szükséges memóriáját. Ez befolyásolhatja a lekérdezés teljesítményét, és ha a rendezési folyamat nem fér el a memóriában, növelheti a munkatáblák tempdb használatát az adatbázisban, ami tempdb növekedéshez vezethet. A probléma megoldásához adjon hozzá fizikai memóriát, vagy hangolja a lekérdezéseket egy másik és gyorsabb lekérdezési terv használatára.

Hagyományos (virtuális) memória

Minden SQL Server-kiadás támogatja a hagyományos memóriát a 64 bites platformon. Az SQL Server-folyamat x64-architektúrán legfeljebb az operációs rendszer maximális virtuális címterét érheti el.

Megjegyzés:

Az SQL Server 2025 -től kezdve (17.x) az SQL Server Standard kiadás akár 256 GB-ot is támogat. Az SQL Server 2022 (16.x) és korábbi verzióiban az SQL Server Standard kiadás akár 128 GB-ot is támogat.

Az IA64-architektúra esetében a korlát 7 TB volt (az IA64 nem támogatott az SQL Server 2012 (11.x) és újabb verzióiban.

További információt a Windows memóriakorlátjai című témakörben talál.

A Windows-bővítmények (AWE) memóriáinak kezelése

A Címablak-bővítmények (AWE) és az AWE által megkövetelt memória-zárolási ( LPIM) jogosultság használatával az SQL Server-folyamatmemória nagy része fizikai RAM-ban zárolva tartható alacsony virtuális memóriafeltételek mellett. Ez a 32 bites és a 64 bites AWE-foglalásokban is előfordul. A memória zárolása azért történik, mert az AWE-memória nem halad át a Windows Virtual Memory Managerén, amely szabályozza a memória lapozását. Az AWE memórialefoglalási API-hoz az Oldalak zárolása a memóriában (SeLockMemoryPrivilege) jogosultság szükséges, lásd AllocateUserPhysicalPages megjegyzések. Ezért az AWE API használatának fő előnye, hogy a memória nagy részét RAM-ban tárolja, ha memóriaterhelés van a rendszeren. Az SQL Server AWE használatának engedélyezéséről további információt a Lapok zárolása a memória beállításban (Windows) című témakörben talál.

Ha az LPIM meg van adva, határozottan javasoljuk, hogy egy adott értékre állítsa be max server memory (MB) ahelyett, hogy a 2 147 483 647 megabájt (MB) alapértelmezett értékét hagyja meg. További információ: Kiszolgáló memóriakonfigurációs beállításai: Beállítások manuális beállítása és Lapok zárolása a memóriában (LPIM).

Ha az LPIM nincs engedélyezve, az SQL Server a hagyományos memória használatára vált, és az operációs rendszer memóriakimerülése esetén a hibanaplóban megjelenhet a MSSQLSERVER_17890 hiba. A hiba a következő példához hasonlít:

A significant part of SQL Server process memory has been paged out. This may result in a performance degradation. Duration: #### seconds. Working set (KB): ####, committed (KB): ####, memory utilization: ##%.

A memóriakezelés változásai az SQL Server 2012-től kezdve

Az SQL Server régebbi verzióiban a memóriafoglalás öt különböző mechanizmussal történt:

  • Single-Page kiosztó (SPA), beleértve csak azokat a memóriafoglalásokat az SQL Server folyamatban, amelyek 8 KB-nál kisebbek vagy egyenlőek voltak. A max server memory (MB) konfigurációs min server memory (MB) lehetőségek meghatározták az SPA által felhasznált fizikai memória korlátait. A pufferkészlet egyidejűleg az SPA mechanizmusa volt, és az egyoldalas foglalások legnagyobb felhasználója.

  • Többoldalas allokátor (MPA) a 8 KB-nál több memóriát igénylő memóriafoglalásokhoz.

  • CLR-kiosztó, beleértve az SQL CLR-halomokat és a CLR inicializálása során létrehozott globális foglalásokat.

  • Az SQL Server-folyamat szálveremeinek memóriafoglalásai .

  • Közvetlen Windows-foglalások (DWA) a közvetlenül a Windowsnak küldött memóriafoglalási kérelmekhez. Ezek közé tartozik a Windows halomhasználat és az SQL Server-folyamatba betöltött modulok által végrehajtott közvetlen virtuális foglalások. Ilyen memóriafoglalási kérések például a kiterjesztett tárolt eljárás DLL-jeiből származó foglalások, az Automation-eljárások (sp_OA hívások) használatával létrehozott objektumok és a társított kiszolgálószolgáltatók foglalásai.

Az SQL Server 2012 -től (11.x) kezdődően a Single-Page foglalások, a többoldalas foglalások és a CLR-foglalások egy "Bármilyen méretű" lapelosztóba vannak összesítve, és bele vannak foglalva a memóriakorlátokba, amelyeket a max server memory (MB) beállítások és min server memory (MB) a konfigurációs beállítások szabályoznak. Ez a módosítás pontosabb méretezési képességet biztosított az SQL Server memóriakezelőjében áthaladó összes memóriakövetelményhez.

Fontos

Az SQL Server 2012 (11.x) és újabb verziókra való frissítés után gondosan tekintse át az aktuális max server memory (MB) és min server memory (MB) a konfigurációkat. Ennek az az oka, hogy az SQL Server 2012-ben (11.x) kezdődően az ilyen konfigurációk mostantól a korábbi verziókhoz képest több memóriafoglalást tartalmaznak és biztosítanak. Ezek a módosítások az SQL Server 2012 (11.x) és az SQL Server 2014 (12.x) 32 bites és 64 bites verzióira, valamint az SQL Server 2016 (13.x) és újabb verziók 64 bites verzióira is érvényesek.

Az alábbi táblázat azt jelzi, hogy egy adott memóriafoglalási típust a max server memory (MB) konfigurációs beállítások min server memory (MB) vezérelnek-e:

A memóriafoglalás típusa SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) és SQL Server 2008 R2 (10.50.x) Az SQL Server 2012-től kezdve (11.x)
Egyoldalas kiosztások Igen Igen, összesítve "bármilyen méretű" lap-hozzárendelésekre
Többoldalas kiosztások Nem Igen, összesítve "bármilyen méretű" lap-hozzárendelésekre
CLR-foglalások Nem Igen
A szálverem memóriája Nem Nem
Közvetlen foglalások a Windowsból Nem Nem

Előfordulhat, hogy az SQL Server túllépi a maximális szervermemória-beállítást, és lefoglalja a memóriát.

Az SQL Server 2012 -től (11.x) kezdve az SQL Server több memóriát foglalhat le, mint a max server memory (MB) beállításban megadott érték. Ez a viselkedés akkor fordulhat elő, ha a Kiszolgáló teljes memóriája (KB) érték már elérte a Célkiszolgáló memóriája (KB) beállítást a megadott módon max server memory (MB). Ha nincs elegendő egybefüggő szabad memória a többoldalas memóriakérések (több mint 8 KB) igényének kielégítéséhez a memória töredezettsége miatt, az SQL Server a memóriakérelem elutasítása helyett túlvállalást hajthat végre.

A foglalás végrehajtása után az Erőforrás-figyelési háttérfeladat elkezdi jelezni az összes memóriafelhasználónak, hogy engedje fel a lefoglalt memóriát, és megpróbálja a kiszolgáló teljes memóriájának (KB) értékét a célkiszolgálói memória (KB) specifikációja alá helyezni. Ezért az SQL Server memóriahasználata rövid ideig meghaladhatja a max server memory (MB) beállítást. Ebben az esetben a teljes kiszolgálói memória (KB) teljesítményszámlálója meghaladja a max server memory (MB)célkiszolgálói memória (KB) beállításait.

Ez a viselkedés általában a következő műveletek során figyelhető meg:

  • Nagyméretű oszlopcentrikus indexes lekérdezések
  • Nagy kötegelt üzemmód a sor-áruház lekérdezéseken
  • Oszlopcentrikus index újjáépítések, amelyek nagy mennyiségű memóriát használnak hash és rendezési műveletek végrehajtásához
  • Nagy memóriapuffereket igénylő biztonsági mentési műveletek
  • Olyan nyomkövetési műveletek, amelyeknek nagy bemeneti paramétereket kell tárolniuk
  • Nagy memória-hozzáférési kérelmek

Ha gyakran észleli ezt a viselkedést, fontolja meg a 8121 nyomkövetési jelző használatát az SQL Server 2019-ben (15.x) annak érdekében, hogy az erőforrás-figyelő gyorsabban törölje a műveletet. Az SQL Server 2022 -től (16.x) kezdődően ez a funkció alapértelmezés szerint engedélyezve van, és a nyomkövetési jelzőnek nincs hatása.

Az SQL Server 2012-től kezdődő memory_to_reserve változásai

Az SQL Server régebbi verzióiban az SQL Server memóriakezelője a folyamat virtuális címterének (VAS) egy részét félreteheti a többoldalas kiosztó (MPA), a CLR-kiosztó, az SQL Server-folyamat szálveremeinek memóriafoglalásai és a Közvetlen Windows-foglalások (DWA) számára. A virtuális címtartomány ezen részét "Mem-To-Leave" vagy "nem pufferkészlet" régiónak is nevezik.

A foglalások számára fenntartott virtuális címteret a memory_to_reserve konfigurációs beállítás határozza meg. Az SQL Server által használt alapértelmezett érték 256 MB.

Mivel a "bármilyen méretű" lapelosztó 8 KB-nál nagyobb foglalásokat is kezel, az memory_to_reserve érték nem tartalmazza a többoldalas foglalásokat. A módosítás kivételével minden más ugyanaz marad ebben a konfigurációs beállításban.

Az alábbi táblázat azt jelzi, hogy egy adott memóriafoglalási típus az memory_to_reserve SQL Server-folyamat virtuális címterének régiójába esik-e:

A memóriafoglalás típusa SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) és SQL Server 2008 R2 (10.50.x) Az SQL Server 2012-től kezdve (11.x)
Egyoldalas kiosztások Nem Nem, "bármilyen méretű" lapfoglalásba konszolidálva
Többoldalas kiosztások Igen Nem, "bármilyen méretű" lapfoglalásba konszolidálva
CLR-foglalások Igen Igen
A szálverem memóriája Igen Igen
Közvetlen foglalások a Windowsból Igen Igen

Dinamikus memóriakezelés

Az SQL Server adatbázismotor alapértelmezett memóriakezelési viselkedése az, hogy annyi memóriát szerezzen be, amennyire szüksége van anélkül, hogy memóriahiányt okoz a rendszeren. Az SQL Server adatbázismotor ezt a Microsoft Windows memóriaértesítési API-kkal végzi.

Ha az SQL Server dinamikusan használja a memóriát, rendszeres időközönként lekérdezi a rendszert a szabad memória mennyiségének meghatározásához. A szabad memória fenntartása megakadályozza az operációs rendszer lapozását. Ha kevesebb memória van szabad, az SQL Server felszabadítja a memóriát az operációs rendszer számára. Ha több memória szabad, az SQL Server több memóriát foglalhat le. Az SQL Server csak akkor ad hozzá memóriát, ha a számítási feladat több memóriát igényel; a inaktív kiszolgálók nem növelik a virtuális címtér méretét. Ha azt tapasztalja, hogy a Feladatkezelő és a Teljesítményfigyelő folyamatosan csökkenti a rendelkezésre álló memóriát, amikor az SQL Server dinamikus memóriakezelést használ, ez az alapértelmezett viselkedés, és nem szabad memóriaszivárgásként érzékelni.

A kiszolgáló memóriakonfigurációs beállításai vezérli az SQL Server memóriafoglalását, a memóriafordítást, az összes gyorsítótárat (beleértve a pufferkészletet), a lekérdezés-végrehajtási memóriát, a zároláskezelő memóriáját és a CLR1 memóriát (lényegében a sys.dm_os_memory_clerks található memóriaírót).

1 CLR-memória kezelése az SQL Server 2012-től (11.x) kezdődő foglalások alatt max server memory (MB) történik.

Az alábbi lekérdezés az aktuálisan lefoglalt memóriával kapcsolatos információkat adja vissza:

SELECT physical_memory_in_use_kb / 1024 AS sql_physical_memory_in_use_MB,
       large_page_allocations_kb / 1024 AS sql_large_page_allocations_MB,
       locked_page_allocations_kb / 1024 AS sql_locked_page_allocations_MB,
       virtual_address_space_reserved_kb / 1024 AS sql_VAS_reserved_MB,
       virtual_address_space_committed_kb / 1024 AS sql_VAS_committed_MB,
       virtual_address_space_available_kb / 1024 AS sql_VAS_available_MB,
       page_fault_count AS sql_page_fault_count,
       memory_utilization_percentage AS sql_memory_utilization_percentage,
       process_physical_memory_low AS sql_process_physical_memory_low,
       process_virtual_memory_low AS sql_process_virtual_memory_low
FROM sys.dm_os_process_memory;

Veremméretek

Az 1, CLR 2, kiterjesztett eljárás .dll fájlok, elosztott lekérdezések által hivatkozott OLE DB-szolgáltatók, Transact-SQL utasításokban hivatkozott automatizálási objektumok és nem SQL Server DLL által lefoglalt memória memóriáját nem szabályozza max server memory (MB)a rendszer.

1 Tekintse meg a kiszolgáló konfigurációját: a feldolgozói szálak maximális száma, amely az aktuális gazdagép adott számú affinitású processzorának számított alapértelmezett feldolgozószálával kapcsolatos információkat tartalmazza. Az SQL Server veremméretei a következők:

SQL Server-architektúra Operációsrendszer-architektúra Verem mérete
x86 (32 bites) x86 (32 bites) 512 KB
x86 (32 bites) x64 (64 bites) 768 KB
x64 (64 bites) x64 (64 bites) 2048 KB
IA64 (Itanium) IA64 (Itanium) 4 096 KB

2 CLR-memória kezelése az SQL Server 2012-től (11.x) kezdődő foglalások alatt max server memory (MB) történik.

Az SQL Server a memóriaértesítési API QueryMemoryResourceNotification használatával határozza meg, hogy az SQL Server memóriakezelője mikor foglalhatja le a memóriát és szabadít fel memóriát.

Az SQL Server indításakor a pufferkészlet virtuális címterének méretét számítja ki számos paraméter, például a rendszer fizikai memóriájának mennyisége, a kiszolgálószálak száma és a különböző indítási paraméterek alapján. Az SQL Server lefoglalja a folyamat virtuális címterének kiszámított mennyiségét a pufferkészlethez, de csak az aktuális terheléshez szükséges fizikai memóriát szerzi be (véglegesíti).

A példány ezután szükség szerint továbbra is memóriát szerez be a számítási feladat támogatásához. Ahogy egyre több felhasználó csatlakozik és futtat lekérdezéseket, az SQL Server igény szerint több fizikai memóriát szerez be. Az SQL Server-példányok mindaddig fizikai memóriát szereznek be, amíg el nem éri a foglalási max server memory (MB) célt, vagy az operációs rendszer azt jelzi, hogy nincs többé szabad memóriafelesleg; a memória felszabadítása, ha több, mint a kiszolgáló minimális memóriabeállítása, és az operációs rendszer azt jelzi, hogy hiányzik a szabad memória.

Mivel más alkalmazások az SQL Server egy példányát futtató számítógépen indulnak el, memóriát használnak fel, és a szabad fizikai memória mennyisége az SQL Server-cél alá csökken. Az SQL Server példánya módosítja a memóriahasználatot. Ha egy másik alkalmazás leáll, és több memória válik elérhetővé, az SQL Server példánya növeli a memóriafoglalás méretét. Az SQL Server másodpercenként több megabájtnyi memóriát szabadíthat fel és szerezhet be, így gyorsan alkalmazkodhat a memóriafoglalás változásaihoz.

A minimális és a maximális kiszolgálómemória hatásai

A minimális kiszolgálómemória és a kiszolgáló maximális memóriakonfigurációs beállításai felső és alsó korlátot szabnak a pufferkészlet és az adatbázismotor egyéb gyorsítótárai által használt memóriamennyiségre. A pufferkészlet nem szerzi be azonnal a minimális kiszolgálómemória által megadott memóriamennyiséget. A pufferkészlet csak az inicializáláshoz szükséges memóriával kezdődik. Az SQL Server adatbázismotor számítási feladatainak növekedésével folyamatosan szerzi be a számítási feladat támogatásához szükséges memóriát. A pufferkészlet nem szabadít fel egyetlen beszerzett memóriát sem, amíg el nem éri a minimális kiszolgálómemória által megadott mennyiséget. A minimális kiszolgálómemória elérése után a pufferkészlet a standard algoritmus használatával szerez be és szabadít fel memóriát szükség szerint. Az egyetlen különbség az, hogy a pufferkészlet soha nem dobja a memóriafoglalást a minimális kiszolgálómemória által megadott szint alá, és soha nem szerez be több memóriát, mint a megadott szint.max server memory (MB)

Megjegyzés:

Az SQL Server mint folyamat több memóriát szerez be, mint amennyit a beállítás határoz max server memory (MB) meg. A belső és a külső összetevők is lefoglalhatnak memóriát a pufferkészleten kívül, amely további memóriát használ fel, de a pufferkészlethez lefoglalt memória általában továbbra is az SQL Server által felhasznált memória legnagyobb részét képviseli.

Az SQL Server adatbázismotor által beszerzett memória mennyisége teljes mértékben a példányon elhelyezett számítási feladattól függ. Előfordulhat, hogy egy SQL Server-példány, amely nem dolgoz fel sok kérést, soha nem éri el a megadott min server memory (MB)értéket.

Ha ugyanazt az értéket adja meg mind a minimális kiszolgálómemória max server memory (MB), mind pedig az SQL Server adatbázismotor számára lefoglalt memória elérése után az SQL Server adatbázismotorja leáll a pufferkészlet dinamikus felszabadításával és beolvasásával.

Ha az SQL Server egy példánya olyan számítógépen fut, amelyen gyakran leállítják vagy elindítják a többi alkalmazást, a memória SQL Server-példány általi lefoglalása és felszabadítása lelassíthatja a többi alkalmazás indítási idejét. Ha az SQL Server egyike azon kiszolgálóalkalmazásoknak, amelyek egyetlen számítógépen futnak, a rendszergazdáknak szabályoznia kell az SQL Server számára lefoglalt memória mennyiségét. Ezekben az esetekben a kiszolgáló minimális memóriáját és max server memory (MB) beállításait használhatja annak szabályozására, hogy az SQL Server mennyi memóriát használhat. A min server memory (MB) beállítások megabájtban max server memory (MB) vannak megadva. További információ, beleértve a memóriakonfigurációk beállítására vonatkozó javaslatokat, tekintse meg a kiszolgáló memóriakonfigurációs beállításait.

Az SQL Server-objektumok specifikációi által használt memória

Az alábbi lista az SQL Server különböző objektumai által használt memória hozzávetőleges mennyiségét ismerteti. A felsorolt összegek becslések, és a környezettől és az objektumok létrehozásának módjától függően változhatnak:

  • Zárolás (a Lock Manager által karbantartott módon): 64 bájt + tulajdonosonként 32 bájt
  • Felhasználói kapcsolat: Körülbelül (3 * network_packet_size + 94 KB)

A hálózati csomagméret az alkalmazások és az adatbázismotor közötti kommunikációhoz használt táblázatos adatfolyam-(TDS-) csomagok mérete. Az alapértelmezett csomagméret 4 KB, és a hálózati csomagméret konfigurációs beállításai vezérlik.

Ha több aktív eredményhalmaz (MARS) használatban van, a felhasználói kapcsolat körülbelül (3 + 3 * num_logical_connections) * hálózati csomagméret + 94 KB.

A minimális memória lekérdezésenkénti hatásai

A min memory per query konfigurációs beállítás meghatározza a lekérdezés végrehajtásához lefoglalt minimális memóriamennyiséget (kilobájtban). Ezt a minimális memóriakiadásnak is nevezik. Minden lekérdezésnek meg kell várnia, amíg a kért minimális memória biztonságossá nem lesz, mielőtt a végrehajtás elkezdődhet, vagy amíg a lekérdezési várakozási kiszolgáló konfigurációs beállításában megadott érték meg nem haladódik. Ebben a forgatókönyvben a várakozási típus, amely felhalmozódik, a következő: RESOURCE_SEMAPHORE.

Fontos

Ne állítson be min memory per query túl magas kiszolgálókonfigurációs beállítást, különösen a nagyon forgalmas rendszereken, mert ez a következőhöz vezethet:

  • Nagyobb verseny a memóriaerőforrásokért.
  • Az egyidejűség csökkentése azáltal, hogy minden egyes lekérdezéshez növeli a memória mennyiségét, még akkor is, ha a szükséges memória futásidőben alacsonyabb, mint ez a konfiguráció.

A konfiguráció használatára vonatkozó javaslatokért tekintse meg a kiszolgáló konfigurációját: lekérdezésenként minimális memória.

Memóriahozzájárulási szempontok

Sor módú végrehajtás esetén a kezdeti memóriakijelenítés semmilyen feltétel mellett nem léphető túl. Ha a kivonatolási vagyrendezési műveletek végrehajtásához a kezdeti engedélynél több memóriára van szükség, akkor a műveletek a lemezre kerülnek. A kiömlött kivonat műveletet egy Workfile tempdbtámogatja, míg a kiömlött rendezési műveletet egy Worktable támogatja.

A Rendezési művelet során előforduló kiömléseket rendezési figyelmeztetések eseményosztálynak nevezzük. A rendezési figyelmeztetések azt jelzik, hogy a rendezési műveletek nem férnek bele a memóriába. Ez nem foglalja magában az indexek létrehozását magában foglaló rendezési műveleteket, csak a lekérdezésen belüli rendezési műveleteket (például egy ORDER BYSELECT utasításban használt záradékot).

A hash művelet során bekövetkező túlcsordulást Hash Figyelmeztetési Eseményosztálynak nevezzük. Ezek akkor fordulnak elő, ha kivonatos rekurzió vagy kivonatolás leállítása (hash bailout) történt egy kivonatolási művelet során.

  • A hash rekurzió akkor fordul elő, amikor a build bemenete nem fér el a rendelkezésre álló memóriában, és emiatt a bemenetet több külön feldolgozott partícióra osztják fel. Ha ezek a partíciók még mindig nem férnek el a rendelkezésre álló memóriába, az alrészekre lesz felosztva, amelyek szintén külön vannak feldolgozva. Ez a felosztási folyamat addig folytatódik, amíg az egyes partíciók el nem férnek a rendelkezésre álló memóriába, vagy amíg el nem éri a maximális rekurziós szintet.
  • A kivonatos mentés akkor fordul elő, ha egy kivonatolási művelet eléri a maximális rekurziós szintet, és egy másik tervre vált a fennmaradó particionált adatok feldolgozásához. Ezek az események csökkenthetik a teljesítményt a kiszolgálón.

Kötegelt módú végrehajtás esetén a kezdeti memóriakiadás alapértelmezés szerint dinamikusan növekedhet egy bizonyos belső küszöbértékig. Ez a dinamikus memória-megadási mechanizmus úgy lett kialakítva, hogy lehetővé tegye a memória-rezidens, kötegelt üzemmódban futó kivonat vagy rendezési műveletek végrehajtását. Ha ezek a műveletek még mindig nem férnek el a memóriába, akkor a műveletek a lemezre kerülnek.

A végrehajtási módokról további információt a lekérdezésfeldolgozási architektúra útmutatójában talál.

Pufferkezelés

Az SQL Server-adatbázisok elsődleges célja az adatok tárolása és lekérése, így az intenzív lemez I/O az adatbázismotor alapvető jellemzője. Mivel a lemez I/O-műveletei sok erőforrást használhatnak fel, és viszonylag hosszú ideig is eltarthatnak, az SQL Server az I/O rendkívül hatékonyvá tételére összpontosít. A pufferkezelés kulcsfontosságú eleme ennek a hatékonyságnak. A pufferkezelési összetevő két mechanizmusból áll: az adatbázisoldalak elérésére és frissítésére szolgáló pufferkezelőből , valamint a puffergyorsítótárból (más néven pufferkészletből) az adatbázisfájl I/O-jának csökkentése érdekében.

Az SQL Server lemez I/O-jának részletes ismertetését az SQL Server I/O alapjaiban találja.

A pufferkezelés működése

A puffer egy 8 KB-os memórialap, amely ugyanolyan méretű, mint egy adat- vagy indexlap. Így a puffermemória gyorsítótára 8 KB-os oldalakra van felosztva. A pufferkezelő kezeli az adatbázislemezfájlokból a puffergyorsítótárba beolvasott adatok vagy indexlapok olvasásának és a módosított lapok lemezre való visszaírásának funkcióit. A lap a puffergyorsítótárban marad, amíg a pufferkezelőnek szüksége van a pufferterületre, hogy további adatokat olvasson be. Az adatok csak akkor lesznek visszaírva a lemezre, ha módosultak. A puffergyorsítótárban lévő adatok többször módosíthatók, mielőtt visszaírták őket a lemezre. További információ: Adatlapok olvasása az adatbázismotorban és írási lapok az adatbázismotorban.

Az SQL Server indításakor a puffergyorsítótár virtuális címterének méretét számítja ki több paraméter alapján, például a rendszer fizikai memóriájának mennyisége, a maximális kiszolgálószálak konfigurált száma és a különböző indítási paraméterek alapján. Az SQL Server lefoglalja a folyamat virtuális címterének (a memóriacélnak) ezt a kiszámított mennyiségét a puffergyorsítótár számára, de csak az aktuális terheléshez szükséges fizikai memóriát szerzi be (véglegesíti). A sys.dm_os_sys_info katalógusnézetében lekérdezheti a committed_target_kbcommitted_kb és az oszlopokat, így visszaadhatja a memóriacélként fenntartott lapok számát, illetve a puffergyorsítótárban jelenleg lekötött lapok számát.

Az SQL Server indítása és a puffercache memóriacéljának elérése közötti időszakot felfutási időszaknak nevezzük. Ez idő alatt az olvasási kérések szükség szerint kitöltik a puffereket. Egy 8 KB-os oldal olvasási kérése például egyetlen pufferlapot tölt ki. Ez azt jelenti, hogy a felfutás az ügyfélkérések számától és típusától függ. A ramp-up folyamata felgyorsul azáltal, hogy az egyoldalas olvasási kéréseket olyan nyolcoldalas kérésekké alakítják át, amelyek egy egységet képeznek. Ez lehetővé teszi, hogy a felpörgés sokkal gyorsabban befejeződjön, különösen a sok memóriával rendelkező gépeken. A lapokról és a mértékekről további információt a Pages and Extents Architektúra útmutatójában talál.

Mivel a pufferkezelő az SQL Server folyamatában a memória nagy részét használja, együttműködik a memóriakezelővel, hogy más összetevők is használhassanak puffereket. A pufferkezelő elsősorban a következő összetevőkkel foglalkozik:

  • A Resource Manager az általános memóriahasználat szabályozására és a 32 bites platformokon a címtérhasználat szabályozására.
  • A Database Manager és az SQL Server operációs rendszere (SQLOS) alacsony szintű fájl I/O-műveletekhez.
  • Log Manager az előre írt naplózáshoz.

Támogatott funkciók

A pufferkezelő a következő funkciókat támogatja:

  • A pufferkezelő nem egységes memóriahozzáférés (NUMA) tudatában van. A puffergyorsítótár lapjai hardveres NUMA-csomópontok között vannak elosztva, így a szál nem idegen memóriából, hanem a helyi NUMA-csomóponton lefoglalt pufferoldalhoz fér hozzá.

  • A pufferkezelő támogatja a gyakori elérésű memória hozzáadását, amely lehetővé teszi a felhasználók számára a fizikai memória hozzáadását a kiszolgáló újraindítása nélkül.

  • A pufferkezelő 64 bites platformokon támogatja a nagy oldalakat . Az oldalméret a Windows verziójára jellemző.

    Megjegyzés:

    Az SQL Server 2012 (11.x) előtt a nagyméretű lapok engedélyezése az SQL Serverben a 834-es nyomkövetési jelző szükséges.

  • A pufferkezelő további diagnosztikákat biztosít, amelyek dinamikus felügyeleti nézeteken keresztül érhetők el. Ezekkel a nézetekkel figyelheti az SQL Serverre jellemző különböző operációsrendszer-erőforrásokat. A sys.dm_os_buffer_descriptors nézet használatával például figyelheti a puffergyorsítótár lapjait.

Memóriaterhelés észlelése

A memóriaterhelés a memóriahiányból eredő állapot, amely a következőt eredményezheti:

  • További I/O-k (például a nagyon aktív lusta írót futtató háttérszál)
  • Magasabb újrafordítási arány
  • Hosszabb ideig futó lekérdezések (ha memóriahasználati várakozások léteznek)
  • Extra CPU-ciklusok

Ezt a helyzetet külső vagy belső okok is kiválthatják. Külső okok a következők:

  • A rendelkezésre álló fizikai memória (RAM) alacsony. Emiatt a rendszer levágja a jelenleg futó folyamatok munkakészletét, ami általános lassulást eredményezhet. Az SQL Server csökkentheti a pufferkészlet véglegesítési célját, és gyakrabban vághatja le a belső gyorsítótárakat.
  • A teljes rendelkezésre álló rendszermemória (amely tartalmazza a rendszeroldalfájlt) alacsony. Ez azt okozhatja, hogy a rendszer nem tud memóriafoglalásokat végrehajtani, mivel nem tudja kilapozza az aktuálisan lefoglalt memóriát.

Belső okok:

  • A külső memóriaterhelésre reagálva, amikor az SQL Server adatbázismotor alacsonyabb memóriahasználati korlátot állít be.
  • A memóriabeállítások manuálisan lettek csökkentve a kiszolgáló maximális memóriakonfigurációjának csökkentésével.
  • A belső összetevők memóriaeloszlásának változásai a több gyorsítótár között.

Az SQL Server adatbázismotor egy, a memóriaterhelés észlelésére és kezelésére szolgáló keretrendszert implementál a dinamikus memóriakezelés részeként. Ez a keretrendszer tartalmazza a Resource Monitor nevű háttérfeladatot. Az Erőforrás-figyelési feladat figyeli a külső és a belső memóriajelzők állapotát. Miután az egyik mutató megváltoztatja az állapotot, kiszámítja a megfelelő értesítést, és közvetíti azt. Ezek az értesítések az egyes motorösszetevők belső üzenetei, amelyeket gyűrűpufferekben tárolnak.

Két gyűrűpuffer a dinamikus memóriakezelés szempontjából fontos információkat tartalmaz:

  • A Resource Monitor gyűrűpuffere nyomon követi az Erőforrás-figyelő tevékenységet, például hogy jelezve volt-e a memória kényszer vagy sem. Ez a gyűrűpuffer állapotinformációkat tartalmaz az aktuális feltételtől függően, legyen az RESOURCE_MEMPHYSICAL_HIGH, RESOURCE_MEMPHYSICAL_LOW, RESOURCE_MEMPHYSICAL_STEADY vagy RESOURCE_MEMVIRTUAL_LOW.

  • A Memóriaszervező gyűrűpuffere, amely minden egyes Resource Governor erőforráskészlet memóriaértesítéseinek rekordjait tartalmazza. A belső memóriaterhelés észlelésekor a rendszer bekapcsolja az alacsony memória-értesítést a memóriát lefoglaló összetevők esetében a memória gyorsítótárak közötti egyensúlyát csökkentő műveletek aktiválásához.

A memóriaközvetítők figyelik az egyes összetevők által igényelt memóriahasználatot, majd az összegyűjtött információk alapján kiszámítják és optimálisan értékelik a memória értékét az egyes összetevők esetében. Az egyes Resource Governor-erőforráskészletekhez több közvetítő is tartozik. Ezt az információt ezután a rendszer az egyes összetevőkre szórja, amelyek igény szerint bővítik vagy csökkentik a használatukat.

További információ a memóriaközvetítőkről: sys.dm_os_memory_brokers.

Hibaészlelés

Az adatbázisoldalak két választható mechanizmus egyikét használhatják, amelyek segítenek biztosítani a lap integritását a lemezre írásuk időpontjától kezdve az újbóli olvasásig: a szakadt oldalvédelem és az ellenőrzőösszegek védelme. Ezek a mechanizmusok lehetővé teszik nem csak az adattárolás, hanem a hardverösszetevők, például a vezérlők, illesztőprogramok, kábelek és még az operációs rendszer helyességének független ellenőrzését is. A védelem hozzáadódik a laphoz közvetlenül azelőtt, hogy azt a lemezre írnák, és ellenőrzik, miután a lemezről kiolvassák.

Az SQL Server négy alkalommal újrapróbálkozza az ellenőrzőösszeggel, az oldaltöréssel vagy más I/O-hibával meghiúsuló olvasásokat. Ha az olvasás sikeres az újrapróbálkozási kísérletek bármelyikében, a rendszer egy üzenetet ír a hibanaplóba, és az olvasást kiváltó parancs folytatódik. Ha az újrapróbálkozási kísérletek sikertelenek, a parancs a MSSQLSERVER_824 hibával hiúsul meg.

A használt oldalvédelem típusa az oldalt tartalmazó adatbázis attribútuma. Az Ellenőrzőösszeg-védelem az SQL Server 2005 -ben (9.x) és újabb verziókban létrehozott adatbázisok alapértelmezett védelme. Az oldalvédelmi mechanizmus az adatbázis létrehozásakor van megadva, és a használatával ALTER DATABASE SETmódosítható. Az aktuális lapvédelmi beállítást a page_verify_option katalógusnézet oszlopának vagy a IsTornPageDetectionEnabled függvény tulajdonságának lekérdezésével határozhatja meg.

Megjegyzés:

Ha az oldalvédelmi beállítás módosul, az új beállítás nem érinti azonnal a teljes adatbázist. Ehelyett a lapok az adatbázis aktuális védelmi szintjét fogadják el, amikor legközelebb írásra kerülnek. Ez azt jelenti, hogy az adatbázis különböző típusú védelemmel rendelkező lapokból állhat.

Oldaltörés elleni védelem

Az SQL Server 2000 -ben (8.x) bevezetett szakadt lapvédelem elsősorban az áramkimaradások miatti lapsérülések észlelésének egyik módja. Előfordulhat például, hogy egy váratlan áramkimaradás egy lapnak csak egy részét hagyja lemezre írni. Utolsó lapvédelem használatakor a 8 kilobájtos adatbázis oldal minden 512 bájtos szektorához egy adott 2 bites aláírási mintát alkalmaznak, amelyet az oldal lemezre írásakor az adatbázis oldal fejlécébe tárolnak.

Amikor a lap lemezről olvasható, az oldalfejlécben tárolt szakadt biteket a rendszer összehasonlítja a lap tényleges szektoradataival. Az aláírási minta bináris 01 és 10 között váltakozik minden egyes íráskor, ami mindig lehetővé teszi annak megállapítását, hogy a szektorok csak egy része került-e lemezre: ha egy bit helytelen állapotban van a lap későbbi olvasásakor, akkor a lap helytelenül lett megírva és egy szakadt oldal észlelhető. A megrekedt lapészlelés minimális erőforrásokat használ; azonban nem észleli a lemez hardverhibái által okozott összes hibát. A szétszakadt lap észlelés beállításával kapcsolatos információkért lásd: ALTER DATABASE SET Options.

Ellenőrzőösszeg-védelem

Az SQL Server 2005-ben (9.x) bevezetett ellenőrzőösszeg-védelem erősebb adatintegritás-ellenőrzést biztosít. A rendszer minden megírt és az oldalfejlécben tárolt oldal adataihoz ellenőrzőösszeget számít ki. Amikor egy tárolt ellenőrzőösszeget tartalmazó lapot olvas a rendszer a lemezről, az adatbázismotor újraszámítja az oldal adatainak ellenőrzőösszegét, és 824-re növeli a hibát, ha az új ellenőrzőösszeg eltér a tárolt ellenőrzőösszegtől. Az ellenőrzőösszeg-védelem több hibát tud kiszűrni, mint az oldaltörés elleni védelem, mert az oldal minden bájtját érinti, ugyanakkor mérsékelten erőforrás-igényes.

Ha az ellenőrzőösszeg engedélyezve van, az áramkimaradások és a hibás hardver vagy belső vezérlőprogram által okozott hibák bármikor észlelhetők, amikor a puffermenedzser beolvassa a lemezről a lapot. Az ellenőrzőösszeg beállításával kapcsolatos információkért lásd: ALTER DATABASE SET Options.

Fontos

Ha egy felhasználó vagy rendszeradatbázis SQL Server 2005 (9.x) vagy újabb verzióra frissül, a PAGE_VERIFY érték (NONE vagy TORN_PAGE_DETECTION) megmarad. Nyomatékosan javasoljuk, hogy használja a CHECKSUM. TORN_PAGE_DETECTION kevesebb erőforrást használhat, de a védelem minimális részhalmazát CHECKSUM biztosítja.

A nem egységes memóriahozzáférés ismertetése

Az SQL Server nem egységes memória-hozzáféréssel (NUMA) rendelkezik, és speciális konfiguráció nélkül jól működik a NUMA-hardvereken. Az órajel és a processzorok számának növekedésével egyre nehezebb csökkenteni a memória késését, amely a további feldolgozási teljesítmény használatához szükséges. Ennek megkerüléséhez a hardvergyártók nagy L3-gyorsítótárakat biztosítanak, de ez csak korlátozott megoldás. A NUMA-architektúra skálázható megoldást kínál erre a problémára.

Az SQL Server úgy lett kialakítva, hogy az alkalmazás módosítása nélkül kihasználja a NUMA-alapú számítógépek előnyeit. További információ: Soft-NUMA (SQL Server).

Memóriaobjektumok dinamikus partíciója

Az SQL Server memóriaobjektumainak nevezett halomelosztók lehetővé teszik, hogy az adatbázismotor memóriát foglaljon le a halomból. Ezek nyomon követhetők a sys.dm_os_memory_objects DMV használatával.

CMemThread egy szálbiztos memóriaobjektum-típus, amely több szál egyidejű memóriafoglalását teszi lehetővé. A helyes nyomon követés érdekében az CMemThread objektumok szinkronizálási szerkezetekre (mutexre) támaszkodnak, így biztosítható, hogy egyszerre csak egyetlen szál frissítse a kritikus fontosságú információkat.

Megjegyzés:

Az CMemThread objektumtípus az adatbázismotor kódbázisában számos különböző lefoglaláshoz használható, és globálisan, csomópont vagy processzor alapján particionálható.

A mutexek használata azonban versengéshez vezethet, ha sok szál kerül ki ugyanabból a memóriaobjektumból rendkívül egyidejű módon. Ezért az SQL Server a particionált memóriaobjektumok (PMO) fogalmával rendelkezik, és minden partíciót egyetlen CMemThread objektum jelöl. A memóriaobjektumok particionálása statikusan van definiálva, és a létrehozás után nem módosítható. Mivel a memóriafoglalási minták a hardver- és memóriahasználattól függően széles körben változnak, lehetetlen előre létrehozni a tökéletes particionálási mintát.

A legtöbb esetben elegendő egyetlen partíció használata, de bizonyos esetekben ez versengéshez vezethet, ami csak egy erősen particionált memóriaobjektummal megelőzhető. Nem kívánatos az egyes memóriaobjektumok particionálása, mivel a további partíciók más hatékonysági hiányosságokat okozhatnak, és növelhetik a memória töredezettségét.

Megjegyzés:

Az SQL Server 2016 (13.x) előtt a 8048-as nyomkövetési jelzővel kényszeríthető, hogy a csomópontalapú PMO CPU-alapú PMO-vá alakuljon. Az SQL Server 2014 (12.x) SP2 és az SQL Server 2016 (13.x) verziótól kezdve ez a viselkedés dinamikus és a motor által vezérelhető.

Az SQL Server 2014 (12.x) SP2 és az SQL Server 2016 (13.x) verziótól kezdve az adatbázismotor képes dinamikusan észlelni egy adott CMemThread objektum versengését, és előléptetni az objektumot csomópontonkénti vagy processzoralapú implementációra. Az előléptetés után a PMO előléptetve marad, amíg az SQL Server-folyamat újra nem indul. CMemThreadA versengés észlelhető a magas CMEMTHREAD várakozások jelenléte alapján a sys.dm_os_wait_stats DMV-ben, valamint a sys.dm_os_memory_objects DMV oszlopainak, contention_factor, partition_type, exclusive_allocations_count és waiting_tasks_count, megfigyelésével is.

Kapcsolódó tartalom

  • Last updated on