MSSQLSERVER_701

A következőkre vonatkozik:SQL Server

Részletek

Attribute Value
Termék neve SQL Server
Eseményazonosító 701
Eseményforrás MSSQLSERVER
Összetevő SQLEngine
Szimbolikus név NOSYSMEM
Üzenet szövege Nincs elegendő rendszermemória a lekérdezés futtatásához.

Note

Ez a cikk az SQL Server-re fókuszál. Az Azure SQL Database memória nélküli problémák elhárításáról információért lásd: Hibakeresés az Azure SQL Database-vel.

Explanation

A 701-es hiba akkor fordul elő, amikor az SQL Server nem osztotta ki elegendő memóriát egy lekérdezés futtatásához. A elégtelen memória számos tényező okozhatja, például operációs rendszer beállításai, fizikai memória elérhetősége, más komponensek az SQL Server-en belüli memóriát használnak, vagy a jelenlegi munkaterhelés memóriakorlátai. A legtöbb esetben a sikertelen tranzakció nem okozza ezt a hibát. Összességében az okok három csoportba sorolhatók:

Külső vagy operációs rendszer memórianyomás

A külső nyomás azt jelenti, hogy a folyamaton kívüli komponensből származó magas memóriahasználat van, ami az SQL Server számára nem elegendő memóriához vezet. Meg kell derítened, hogy más alkalmazások a rendszerben fogyasztják-e a memóriát, és hozzájárulnak-e az alacsony memória rendelkezésre álláshoz. Az SQL Server azon kevés alkalmazások egyike, amely az operációs rendszer memória terhelésére válaszul csökkenti a memóriahasználatot. Ez azt jelenti, hogy ha egy alkalmazás vagy illesztőprogram memóriát kér, az operációs rendszer jelet küld minden alkalmazásnak a memória felszabadítására, és az SQL Server válaszul csökkenti saját memóriahasználatát. Nagyon kevés más alkalmazás válaszol, mert nem arra tervezték, hogy meghallgassák ezt az értesítést. Tehát ha az SQL elkezdi csökkenteni a memóriahasználatot, a memóriakészlet csökken, és azok az összetevők, amelyekre szükségük van, nem kapja meg. Elkezdsz 701-et és más memóriahibákat kapni. További információért lásd: SQL Server Memóriaarchitektúra

Belső memórianyomás, nem az SQL Server-ből származik

A belső memórianyomás az alacsony memória rendelkezésre állását jelenti, amelyet az SQL Server folyamaton belüli tényezők okoznak. Vannak olyan komponensek, amelyek az SQL Server folyamaton belül futhatnak, és "külsőleg" működnek az SQL Server motortól. Példák például a DLL-ek, mint a linked serverek, SQLCLR komponensek, kiterjesztett eljárások (XP-k) és OLE automatizálás (sp_OA*). Mások közé tartoznak az antivírus vagy más biztonsági programok, amelyek DLL-eket injektálnak a folyamatba a megfigyelés céljából. Bármelyik alkatrész hibája vagy rossz tervezése nagy memóriafogyasztáshoz vezethet. Például képzelj el egy összekapcsolt szervert, amely 20 millió sort tárol előre, amelyek külső forrásból származnak, az SQL Server memóriába. Az SQL Server esetében egyetlen memóriakezelő sem jelent magas memóriahasználatot, de az SQL Server folyamaton belül fogyasztott memória magas lesz. Például ez a memórianövekedés egy összekapcsolt szerver DLL-től arra készteti, hogy az SQL Server elkezdi csökkenteni a memóriahasználatot (lásd fent), és alacsony memória feltételeket teremtene az SQL Server-en belüli komponensek számára, ami olyan hibákat okoz, mint például a 701.

Belső memórianyomás, amely az SQL Server komponens(ei)ből származik

Az SQL Server Engine-en belüli komponensekből eredő belső memórianyomás is okozhat 701-es hibát. Több száz komponens található, amelyeket sys.dm_os_memory_clerks követnek, és amelyek SQL Server-ben osztanak memóriát a területen. Meg kell határoznod, hogy mely memória író(k) felelősek a legnagyobb memória allokációkért, hogy ezt tovább tudja oldani. Például, ha azt tapasztalod, hogy a OBJECTSTORE_LOCK_MANAGER memóriakezelő mutatja a nagy memória allokációt, akkor jobban meg kell értened, miért fogyaszt annyi memóriát a Lock Manager. Előfordulhat, hogy olyan lekérdezések vannak, amelyek sok zárat szerznek és indexekkel optimalizálják, vagy lerövidítik a tranzakciókat, amelyek hosszú ideig tartják a zárokat, vagy ellenőrzik, hogy a zár ekalációja le van-e tiltva. Minden memória tisztviselőnek vagy komponensnek egyedi módja van a memória elérésének és használatának. További információért lásd a sys.dm_os_memory_clerks és azok leírásait.

Felhasználói művelet

Ha a 701-es hiba időnként vagy rövid ideig előfordul, előfordulhat, hogy rövid ideig tartó memóriaprobléma oldódott meg magától. Lehet, hogy ezekben az esetekben nem kell lépéseket tenni. Ha azonban a hiba többször előfordul, több kapcsolaton is, és másodperceken át vagy hosszabb ideig fennáll, kövesse a további hibakeresési lépéseket.

Az alábbi lista általános lépéseket tartalmaz, amelyek segítenek a memóriahibák elhárításában.

Diagnosztikai eszközök és rögzítés

A diagnosztikai eszközök, amelyek lehetővé teszik a hibakeresési adatok gyűjtését, a Performance Monitor, sys.dm_os_memory_clerks és DBCC MEMORYSTATUS.

Konfiguráld és gyűjtsd össze a következő számlálókat a Performance Monitor-ral:

  • Memória:Elérhető MB
  • Folyamat:Munkakészlet
  • Process:Privát bájtok
  • SQL Server:Memóriakezelő: (minden számláló)
  • SQL Server:Buffer Manager: (minden számláló)

Gyűjtsd össze ennek a lekérdezésnek a időszakos kimeneteit az érintett SQL Server-en

SELECT pages_kb, type, name, virtual_memory_committed_kb, awe_allocated_kb
FROM sys.dm_os_memory_clerks
ORDER BY pages_kb DESC

Pssdiag vagy SQL LogScout

Egy alternatív, automatizált módja ezeknek az adatpontoknak a rögzítésére a PSSDIAG vagy az SQL LogScout használata.

  • Ha Pssdiagot használsz, konfiguráld úgy, hogy rögzítse a Perfmon gyűjtőt és a Custom Diagnostics\SQL Memory Error Collectort
  • Ha SQL LogScoutot használsz, konfiguráld úgy, hogy rögzítsd a memória forgatókönyvet

A következő szakaszok részletesebb lépéseket mutatnak be minden forgatókönyvre – külső vagy belső memórianyomás.

Külső nyomás: diagnosztika és megoldások

  • Az alacsony memória állapotok diagnosztizálásához a SQL Server folyamaton kívüli rendszeren keresztül gyűjtsünk teljesítménymonitor-számlálókat. Vizsgáld meg, hogy az SQL Server-en kívüli alkalmazások vagy szolgáltatások fogyasztanak-e memóriát ezen a szerveren, az alábbi számlálókat:

    • Memória:Elérhető MB
    • Folyamat:Munkakészlet
    • Process:Privát bájtok

    Íme egy példa a Perfmon naplógyűjtemény PowerShell használatával

    clear
$serverName = $env:COMPUTERNAME
$Counters = @(
   ("\\$serverName" +"\Memory\Available MBytes"),
   ("\\$serverName" +"\Process(*)\Working Set"),
   ("\\$serverName" +"\Process(*)\Private Bytes")
)

Get-Counter -Counter $Counters -SampleInterval 2 -MaxSamples 1 | ForEach-Object  {
$_.CounterSamples | ForEach-Object       {
   [pscustomobject]@{
      TimeStamp = $_.TimeStamp
      Path = $_.Path
      Value = ([Math]::Round($_.CookedValue, 3)) }
}
}

  • Nézze át a System Event naplót, és keresse a memória hibákat (például alacsony virtuális memória).

  • Tekintse át az alkalmazás eseménynaplójában az alkalmazással kapcsolatos memóriaproblémákat.

    Itt egy minta-PowerShell szkript, amellyel a "memory" kulcsszóra lekérdezhetjük a Rendszer- és Alkalmazáseseménynaplókat. Nyugodtan használhatsz más sorokat, mint például a "resource" a kereséshez:

    Get-EventLog System -ComputerName "$env:COMPUTERNAME" -Message "*memory*"
Get-EventLog Application -ComputerName "$env:COMPUTERNAME" -Message "*memory*"

  • Kezelni a kevésbé kritikus alkalmazások vagy szolgáltatások kód- vagy konfigurációs problémáit, hogy csökkentsék a memóriahasználatukat.

  • Ha az SQL Server-en kívüli alkalmazások is erőforrásokat fogyasztanak, próbáld meg megállítani vagy újraütemezni ezeket az alkalmazásokat, vagy fontold meg a futtatásukat egy külön szerveren. Ezek a lépések eltávolítják a külső memória nyomását.

Belső memórianyomás, nem az SQL Server-ből származik: diagnosztika és megoldások

Az SQL Server-en belüli modulok (DLL) által okozott belső memórianyomás diagnosztizálásához a következő megközelítést alkalmazzuk:

  • Ha az SQL Server nem használja a Lock pages in memory opciót (AWE API), akkor a memória nagy része a Performance Monitor Process:Private Bytes számlálóján (SQLServrinstance) jelenik meg. Az SQL Server motoron belüli memóriahasználat az SQL Server:Memory Manager: Total Server Memory (KB) számlálóban is tükröződik. Ha jelentős különbséget találsz a Process:Private Bytes és az SQL Server:Memory Manager: Total Server Memory (KB) érték között, akkor ez a különbség valószínűleg egy DLL-ből (linked server, XP, SQLCLR stb.) származik. Például, ha a privát bájtok 300 GB, a teljes szervermemória 250 GB, akkor a folyamat teljes memóriájának körülbelül 50 GB a SQL Server motoron kívülről származik.

  • Ha az SQL Server Lock pages in memory (AWE API) rendszert használ, akkor nehezebb azonosítani a problémát, mert a Performance monitor nem kínál AWE számlálókat, amelyek nyomon követnék az egyes folyamatok memóriahasználatát. Az SQL Server motoron belüli memóriahasználat az SQL Server:Memory Manager: Total Server Memory (KB) számlálóban is tükröződik. Tipikus folyamat: A privát bájtértékek összességében 300 MB és 1-2 GB között változhatnak. Ha jelentős Process:Private Bytes használatot találsz ezen a tipikus használaton túl, akkor a különbség valószínűleg egy DLL-ből származik (linked server, XP, SQLCLR stb.). Például, ha a Private bytes számláló 5-4 GB, és az SQL Server Lock pages in memory (AWE) rendszert használ, akkor a Private bytes nagy része az SQL Server motoron kívülről származhat. Ez egy közelítő technika.

  • Használja a Tasklist segédprogramot, hogy azonosítsd azokat a DLL-eket, amelyek az SQL Server területén vannak betöltve:

    tasklist /M /FI "IMAGENAME eq sqlservr.exe"

  • Ezt a lekérdezést arra is használhatod, hogy megvizsgáld a betöltött modulokat (DLL-eket), és megnézd, nem várható-e valami ott

    SELECT * FROM sys.dm_os_loaded_modules

  • Ha gyanítod, hogy egy Linked Server modul jelentős memóriafogyasztást okoz, akkor beállíthatod, hogy kifut a folyamaton kívül, ha kikapcsolod az Allow inprocess opciót. További információért lásd: Create linked servers (SQL Server adatbázismotor) oldalt. Nem minden összekapcsolt szerver OLEDB szolgáltató kimerül a folyamatból; További információért keresse a termékgyártót.

  • Ritka esetben, amikor OLE automatizálási objektumokat használnak (sp_OA*), konfigurálhatod az objektumot úgy, hogy a SQL Server-on kívül futson egy folyamatban, ha beállítod a context = 4 (csak helyi (.exe) OLE szerver). További információért lásd: sp_OACreate.

Belső memóriahasználat az SQL Server motornál: diagnostika és megoldások

  • Kezdj el teljesítménymonitor-számlálókat gyűjteni SQL Server:SQL Server:Buffer Manager, SQL Server: Memory Manager számára.

  • Többször is kérdezze az SQL Server memória tisztviselőinek DMV-nél, hogy hol jár a legnagyobb memóriafogyasztás a motorban:

    SELECT pages_kb, type, name, virtual_memory_committed_kb, awe_allocated_kb
FROM sys.dm_os_memory_clerks
ORDER BY pages_kb DESC

  • Alternatívaként megfigyelheted a részletesebb DBCC MEMORYSTATUS kimenetet, és azt, ahogyan változik, amikor ezeket a hibaüzeneteket látod.

    DBCC MEMORYSTATUS

  • Ha egyértelmű vétőt azonosítasz a memória tisztviselők között, koncentrálj az adott komponens memóriafogyasztásának részleteire. Íme néhány példa:

    • Ha MEMORYCLERK_SQLQERESERVATIONS memóriakezelő memóriát fogyaszt, azonosítsd azokat a lekérdezéseket, amelyek hatalmas memóriatámogatást használnak, és optimalizáld őket indexekkel, újraírd (például töröld a ORDER-et), vagy alkalmazz lekérdezési tippeket.
    • Ha sok ad hoc lekérdezési terv kerül gyorsagtárba, akkor a CACHESTORE_SQLCP memória tisztviselő nagy mennyiségű memóriát használ. Azonosítsd azokat a nem paraméterezett lekérdezéseket, amelyek lekérdezési tervei nem használhatók újra, és paraméterezzük őket tárolt eljárásokra konvertálva, vagy , vagy sp_executesqlFORCED paraméterezéssel.
    • Ha az objektumterv gyorsítótár tárolója CACHESTORE_OBJCP sok memóriát fogyaszt, akkor tedd a következőket: azonosítsuk, mely tárolt eljárások, függvények vagy triggerek sok memóriát használnak, és esetleg újratervezzük az alkalmazást. Ez gyakran előfordulhat nagy mennyiségű adatbázis vagy séma miatt, amelyek mindegyikében több száz eljárás található.
    • Ha a OBJECTSTORE_LOCK_MANAGER memória tisztviselője mutatja a nagy memória allokációkat, azonosítsd azokat a lekérdezéseket, amelyek sok zárat alkalmaznak, és optimalizáld azokat indexek használatával. Rövidítsd le azokat a tranzakciókat, amelyek miatt a zárak hosszú ideig nem szabadulnak fel bizonyos izolációs szinteken, vagy ellenőrizd, hogy a zár ekalációja le van-e tiltva.

Gyors felszabadítás, ami talán elérhetővé teszi a memóriát

Az alábbi műveletek felszabadíthatnak némi memóriát, és elérhetővé teszik az SQL Server számára:

  • Ellenőrizd az alábbi SQL Server memóriakonfigurációs paramétereket, és ha lehetséges, fontold meg a maximális szervermemória növelését:

    • maximális szervermemória

    • minimális kiszolgálómemória

      Figyelje meg a szokatlan beállításokat. Szükség szerint javítsa ki őket. Figyelembe venni a megnövekedett memóriaigényt. Az alapértelmezett beállítások a szervermemória konfigurációs opciókban találhatók.

  • Ha nem állítottad be a maximális szervermemóriát , különösen a Lock oldalak memóriájában, fontold meg, hogy egy adott értéket állíts, hogy engedélyezz némi memóriát az operációs rendszernek. Lásd: Oldalak zárolása a memóriaszerver konfigurációban opció.

  • Nézd meg a lekérdezési munkaterhelést: az egyidejű munkamenetek számát, jelenleg futtató lekérdezéseket, és nézd meg, vannak-e kevésbé kritikus alkalmazások, amelyeket ideiglenesen meg lehet állítani vagy áthelyezni egy másik SQL Server-re.

  • Ha az SQL Server-et virtuális gépen (VM) futtatod, győződj meg róla, hogy a VM memóriája ne legyen túlterhelt. A VM-ek memória konfigurálására vonatkozó ötletekért lásd:

  • Az alábbi DBCC parancsokat futtathatod, hogy több SQL Server memóriagyorsítótárt szabadíts.

    • DBCC FREESYSTEMCACHE

    • DBCC FREESESSIONCACHE (a munkamenet-cache tartalmának felszabadítása)

    • DBCC FREEPROCCACHE

  • Ha Resource Governor-t használsz, javasoljuk, hogy nézd meg az erőforrás-pool vagy a munkaterhelés csoport beállításait, hogy nem korlátozzák túl drasztikusan a memóriát.

  • Ha a probléma továbbra is fennáll, további vizsgálatot kell végezned, és esetleg növelned kell a szerver erőforrásait (RAM-ot).

  • Last updated on