Problemen met onvoldoende geheugen of weinig geheugen in SQL Server oplossen

Overzicht

In dit artikel wordt beschreven hoe u SQL Server geheugenproblemen oplost, waaronder onvoldoende geheugen en fouten bij het toewijzen van geheugenfouten, lage geheugenomstandigheden en gerelateerde prestatieproblemen. Hierin worden de symptomen uitgelegd, de drie hoofdcategorieën geheugendruk (extern, intern van niet-enginemodules en interne onderdelen van SQL Server engine), de diagnostische hulpprogramma's die u kunt gebruiken om gegevens te verzamelen en de stappen die u kunt nemen om de geheugenbelasting op een SQL Server exemplaar op te lossen of op te lossen.

Symptomen van fouten door onvoldoende geheugen

SQL Server maakt gebruik van een complexe geheugenarchitectuur die overeenkomt met de complexe en uitgebreide functieset. Vanwege de verscheidenheid aan geheugenbehoeften kunnen veel bronnen geheugenverbruik en geheugenbelasting veroorzaken, wat kan leiden tot onvoldoende geheugen.

Veelvoorkomende fouten duiden op weinig geheugen in SQL Server. Voorbeelden van deze fouten zijn:

• 701: Kan niet voldoende geheugen toewijzen om een query uit te voeren.
• 802: Kan geen geheugen ophalen voor het toewijzen van pagina's in de buffergroep (gegevens- of indexpagina's).
• 1204: Kan geen geheugen toewijzen voor vergrendelingen.
• 6322: Kan geen geheugen toewijzen voor XML-parser.
• 6513: Kan CLR niet initialiseren vanwege geheugendruk.
• 6533: AppDomain is niet geladen vanwege onvoldoende geheugen.
• 8318: Kan SQL-prestatiemeteritems niet laden vanwege onvoldoende geheugen.
• 8356 of 8359: ETW of SQL-tracering kan niet worden uitgevoerd vanwege onvoldoende geheugen.
• 8556: Kan MSDTC niet laden vanwege onvoldoende geheugen.
• 8645: Kan een query niet uitvoeren vanwege geen geheugen voor geheugentoekenningen (sorteren en hashen).
• 8902: Kan geen geheugen toewijzen tijdens de uitvoering van DBCC.
• 9695 of 9696: Fout bij het toewijzen van geheugen voor Service Broker-bewerkingen.
• 17131 of 17132: Opstartfout server vanwege onvoldoende geheugen.
• 17890: Kan geen geheugen toewijzen omdat SQL-geheugen door het besturingssysteem naar het wisselbestand is verplaatst.
• 18053: De fout wordt afgedrukt in de terse-modus omdat er een fout is opgetreden tijdens de opmaak. Tracering, ETW en meldingen worden overgeslagen.
• 22986 of 22987: Fouten bij het vastleggen van gegevens wijzigen vanwege onvoldoende geheugen.
• 25601: De Xevent-engine heeft onvoldoende geheugen.
• 26053: SQL-netwerkinterfaces kunnen niet worden geïnitialiseerd vanwege onvoldoende geheugen.
• 30085, 30086, 30094: SQL-bewerkingen in volledige tekst mislukken vanwege onvoldoende geheugen.

Oorzaak van problemen met weinig geheugen

Veel factoren kunnen onvoldoende geheugen veroorzaken. Dergelijke factoren omvatten besturingssysteeminstellingen, beschikbaarheid van fysiek geheugen, onderdelen die geheugen in SQL Server gebruiken en geheugenlimieten voor de huidige werkbelasting. In de meeste gevallen is de query die mislukt met een fout buiten het geheugen niet de oorzaak van de fout. U kunt de oorzaken groeperen in drie categorieën.

Externe geheugendruk of geheugendruk van het besturingssysteem

Externe druk verwijst naar een hoog geheugengebruik van een onderdeel buiten het SQL Server proces dat leidt tot onvoldoende geheugen voor SQL Server. Controleer of andere toepassingen op het systeem geheugen verbruiken en bijdragen aan een lage beschikbaarheid van het geheugen. SQL Server is een van de weinige toepassingen die zijn ontworpen om te reageren op geheugendruk van het besturingssysteem door het geheugengebruik te verminderen. Als een toepassing of stuurprogramma geheugen aanvraagt, stuurt het besturingssysteem een signaal naar alle toepassingen om geheugen vrij te maken en SQL Server reageert door het eigen geheugengebruik te verminderen. Weinig andere toepassingen reageren hierop, omdat ze niet zijn ontworpen om op die melding te reageren. Wanneer SQL Server het geheugengebruik vermindert, wordt de geheugengroep kleiner en krijgen onderdelen die geheugen nodig hebben dit mogelijk niet. Als gevolg hiervan krijgt u 701 of andere geheugengerelateerde fouten. Zie SQL Server geheugenarchitectuur voor meer informatie over hoe SQL Server dynamisch geheugen toewijst en vrijgeeft. Zie Externe geheugendruk in dit artikel voor gedetailleerde diagnostische gegevens en oplossingen.

Drie algemene categorieën problemen kunnen leiden tot geheugenbelasting van het besturingssysteem:

• Problemen met betrekking tot toepassingen: een of meer toepassingen samen gebruiken het beschikbare fysieke geheugen. Het besturingssysteem reageert op nieuwe toepassingsaanvragen voor resources door geheugen vrij te maken. Zoek welke toepassingen geheugen uitputten en voer stappen uit om het geheugen ertussen te verdelen zonder het RAM-geheugen te vermoeien.
• Problemen met apparaatstuurprogramma's: apparaatstuurprogramma's kunnen ervoor zorgen dat alle processen worden gepagineerd als een stuurprogramma een geheugentoewijzingsfunctie onjuist aanroept.
• Problemen met het besturingssysteemproduct.

Zie MSSQLSERVER_17890 voor een gedetailleerde uitleg en probleemoplossing.

Interne geheugendruk van niet-motormodules

Interne geheugenbelasting verwijst naar lage geheugen beschikbaarheid veroorzaakt door factoren in het SQL Server-proces. Sommige onderdelen die in het SQL Server proces worden uitgevoerd, zijn extern voor de SQL Server-engine. Voorbeelden hiervan zijn OLE DB-providers (DLL's), zoals gekoppelde servers, SQLCLR-procedures of -functies, uitgebreide procedures (XPs) en OLE Automation (sp_OA*). Andere omvatten antivirus- of beveiligingsprogramma's die DLL's in het proces injecteren voor bewakingsdoeleinden. Een probleem of slecht ontwerp in een van deze onderdelen kan leiden tot een groot geheugenverbruik. Denk bijvoorbeeld aan een gekoppelde server die 20 miljoen rijen gegevens uit een externe bron in het cachegeheugen van SQL Server cachet. Vanuit het perspectief van de engine rapporteert geen enkele memory clerk een hoog geheugengebruik, maar het geheugengebruik binnen het SQL Server-proces is hoog. Deze toename van het geheugengebruik door een DLL van een gekoppelde server zorgt ervoor dat SQL Server het geheugengebruik begint te verminderen en situaties met weinig beschikbaar geheugen voor onderdelen van de engine veroorzaakt, wat leidt tot onvoldoende-geheugenfouten. Zie Interne geheugendruk van modules buiten de engine voor gedetailleerde diagnostiek en oplossingen.

Interne geheugenbelasting van SQL Server motoronderdelen

Interne geheugendruk van onderdelen in de SQL Server-engine kan ook leiden tot fouten met onvoldoende geheugen. Honderden onderdelen die via memory clerks worden bijgehouden, wijzen geheugen toe in SQL Server. Bepaal welke geheugenmedewerkers verantwoordelijk zijn voor de grootste toewijzingen om het probleem op te lossen. Als bijvoorbeeld de OBJECTSTORE_LOCK_MANAGER memory clerk een grote toewijzing weergeeft, zoek dan uit waarom de Lock Manager zoveel geheugen verbruikt. Mogelijk vindt u query's die veel vergrendelingen verkrijgen. Optimaliseer deze query's met behulp van indexen door transacties te verkorten die lange tijd vergrendelingen bevatten of door te controleren of escalatie van vergrendelingen is uitgeschakeld. Elke geheugenbediende of elk onderdeel heeft een unieke manier om geheugen te gebruiken. Zie sys.dm_os_memory_clerks en de beschrijvingen van het type geheugenbediende voor meer informatie. Zie Intern geheugengebruik door de SQL Server-engine voor gedetailleerde diagnostische gegevens en oplossingen.

Geheugendruktypen

In de volgende grafiek ziet u de typen druk die kan leiden tot onvoldoende geheugen in SQL Server:

Diagnostische hulpprogramma's voor het oplossen van geheugenproblemen

Gebruik de volgende diagnostische hulpprogramma's om probleemoplossingsgegevens te verzamelen.

Prestatiemeter

Stel de volgende tellers in en verzamel deze met behulp van Performance Monitor:

• Geheugen:Beschikbare MBytes
• Proces:Working Set
• Proces: Privébytes
• SQL Server:Memory Manager: (alle tellers)
• SQL Server:Bufferbeheer: (alle tellers)

DMVs en DBCC MEMORYSTATUS

Gebruik sys.dm_os_memory_clerks of DBCC MEMORYSTATUS bekijk het algehele geheugengebruik in SQL Server. sys.dm_os_memory_clerks retourneert één rij per geheugenbediende en is het beste startpunt om te vinden welke onderdelen het meeste geheugen verbruiken. DBCC MEMORYSTATUS retourneert een gedetailleerdere momentopname die informatie groepeert op geheugenbeheer, buffergroep en bedienden.

Rapport Geheugenverbruik in SSMS

Geheugengebruik weergeven in SQL Server Management Studio (SSMS):

1. Open SSMS en maak verbinding met een server.
2. Selecteer en houd in Objectverkenner de naam van het SQL Server exemplaar ingedrukt (of klik erop met de rechtermuisknop).
3. Selecteer in het contextmenu Rapporten>Standaardrapporten>Geheugengebruik.

PSSDiag of SQL LogScout

Als u deze gegevenspunten automatisch wilt vastleggen, gebruikt u een hulpprogramma zoals PSSDiag of SQL LogScout.

• Als u PSSDiag gebruikt, configureert u het zo dat de collector Perfmon en de collector Custom Diagnostics\SQL Memory Error worden vastgelegd.
• Als u SQL LogScout gebruikt, stelt u dit in om het geheugenscenario vast te leggen.

Snel geheugen vrijmaken

De volgende acties kunnen geheugen vrijmaken en beschikbaar maken voor SQL Server. Gebruik ze als kortetermijnontlasting terwijl u de hoofdoorzaak onderzoekt.

Geheugenconfiguratie wijzigen

Controleer de volgende sql Server-geheugenconfiguratieparameters en overweeg indien mogelijk het maximale servergeheugen te verhogen:

• maximaal servergeheugen
• minimale servergeheugen

Als u het maximale servergeheugen niet hebt ingesteld, met name als Pagina's in geheugen vergrendelen is ingeschakeld, stelt u deze in op een specifieke waarde om het geheugen voor het besturingssysteem te behouden. Zie de serverconfiguratieoptie Pagina's in geheugen vergrendelen (LPIM) voor meer informatie.

De workload wijzigen of verplaatsen

Controleer de queryworkload, inclusief het aantal gelijktijdige sessies en momenteel uitgevoerde query's. Controleer of u minder kritieke toepassingen tijdelijk kunt stoppen of naar een ander SQL Server exemplaar kunt verplaatsen.

Voor alleen-lezenwerkbelastingen kunt u deze verplaatsen naar een alleen-lezen secundaire replica in een AlwaysOn-omgeving. Zie Alleen-leesbelasting verplaatsen naar een secundaire replica van een Always On-beschikbaarheidsgroep en Alleen-leestoegang tot een secundaire replica van een Always On-beschikbaarheidsgroep configureren voor meer informatie.

Geheugenconfiguratie van virtuele machines controleren

Als u SQL Server uitvoert op een virtuele machine (VM), moet u ervoor zorgen dat de host het geheugen van de virtuele machine niet overschrijft. Zie Memory best practices for SQL Server op virtuele machines in Azure voor richtlijnen over het dimensioneren van geheugen voor SQL Server op Azure-VM's. Raadpleeg de documentatie van de leverancier van uw hypervisor over het detecteren en voorkomen van overtoewijzing van geheugen voor VMware-vm's.

Geheugen vrijgeven in SQL Server

Voer een of meer van de volgende DBCC-opdrachten uit om SQL Server geheugencaches vrij te maken. Gebruik deze opdrachten met voorzichtigheid bij productiesystemen omdat ze caches wissen die opnieuw moeten worden ingevuld:

• DBCC FREESYSTEMCACHE
• DBCC FREESESSIONCACHE
• DBCC FREEPROCCACHE

De SQL Server-service opnieuw starten

Als geheugenuitputting kritiek is en SQL Server geen query's kan verwerken, kunt u de service als laatste redmiddel opnieuw opstarten. Met deze actie worden alle actieve verbindingen verwijderd en worden caches gewist, dus gebruik deze alleen wanneer andere opties mislukken.

Instellingen voor Resource Governor controleren

Als u Resource Governor gebruikt, controleert u de instellingen van de resourcepool en de workloadgroep om ervoor te zorgen dat deze het geheugen niet te sterk beperken. Zie Resource Governor voor meer informatie.

Meer RAM-geheugen toevoegen

Als het probleem zich na de vorige stappen blijft voordoen, onderzoekt u verder en kunt u overwegen om serverbronnen (RAM) op de fysieke of virtuele server te verhogen.

Geheugendruk vaststellen en oplossen

Als een onvoldoende-geheugenfout slechts af en toe of gedurende een korte periode optreedt, kan het probleem van korte duur zijn en vanzelf verdwijnen, en is er mogelijk geen actie nodig. Als de fout meerdere keren voorkomt in meerdere verbindingen en zich gedurende enkele seconden of langer blijft voordoen, volgt u de diagnostische gegevens en oplossingen in de volgende secties om de hoofdoorzaak te identificeren en te verhelpen.

Druk op extern geheugen

Gebruik de volgende methoden om problemen met weinig geheugen op het systeem buiten het SQL Server-proces te diagnosticeren:

• Prestatiemetertellers verzamelen. Controleer of andere toepassingen of services dan SQL Server geheugen op deze server verbruiken door deze tellers te bekijken:

  • Geheugen:Beschikbare MBytes
  • Proces:Working Set
  • Proces: Privébytes

  Hier volgt een voorbeeld van het verzamelen van Perfmon-logboeken met behulp van PowerShell:

  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)) }
  }
  }
  

• Controleer het gebeurtenislogboek van het systeem en zoek naar geheugengerelateerde fouten (bijvoorbeeld weinig virtueel geheugen).

• Controleer het gebeurtenislogboek van de toepassing op problemen met betrekking tot toepassingsgerelateerd geheugen.

  Hier volgt een voorbeeld van een PowerShell-script waarmee query's worden uitgevoerd op de gebeurtenislogboeken van het systeem en de toepassing voor het trefwoord 'geheugen'. U kunt andere tekenreeksen zoals 'resource' gebruiken voor uw zoekopdracht:

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

• Los eventuele code- of configuratieproblemen op voor minder kritieke toepassingen of services om het geheugengebruik te verminderen.

• Als toepassingen naast SQL Server resources verbruiken, kunt u deze stoppen of opnieuw plannen of uitvoeren op een afzonderlijke server. Met deze stappen wordt de druk van het externe geheugen verwijderd.

Interne geheugendruk van niet-motormodules

Gebruik de volgende methoden om interne geheugenbelasting te diagnosticeren die wordt veroorzaakt door modules (DLL's) in SQL Server:

• Als SQL Server geen gebruikmaakt van Lock Pages in Memory (AWE-API), is het grootste deel van het geheugengebruik zichtbaar in de teller Process:Private Bytes (sqlservr-exemplaar) in Performance Monitor. De teller SQL Server:Memory Manager: Total Server Memory (KB) toont het totale geheugengebruik vanuit de SQL Server-engine. Als u een belangrijk verschil vindt tussen Proces:Privébytes en SQL Server:Memory Manager: Totaal servergeheugen (KB), is dat verschil waarschijnlijk afkomstig van een DLL (gekoppelde server, XP, SQLCLR, enzovoort). Als privébytes bijvoorbeeld 300 GB zijn en het totale servergeheugen 250 GB is, komt ongeveer 50 GB van het totale geheugen in het proces van buiten de SQL Server engine.

• Als SQL Server Vergrendelingspagina's in het geheugen (AWE API) gebruikt, is het moeilijker om het probleem te identificeren omdat Performance Monitor geen AWE-tellers biedt waarmee het geheugengebruik voor afzonderlijke processen wordt bijgehouden. De teller SQL Server:Memory Manager: Total Server Memory (KB) toont het totale geheugengebruik in de SQL Server-engine. Typische waarden voor proces:privébytes kunnen variëren tussen 300 MB en 1-2 GB over het algemeen. Als Proces:Privébytes aanzienlijk hoger is dan dit typische bereik, is het verschil waarschijnlijk afkomstig van een DLL (gekoppelde server, XP, SQLCLR, enzovoort). Als privébytes bijvoorbeeld 4-5 GB zijn en SQL Server Vergrendelingspagina's in geheugen (AWE) gebruikt, kan een groot deel van privébytes afkomstig zijn van buiten de SQL Server-engine. Deze waarde is een benadering.

• Gebruik het tasklist hulpprogramma om DLL's te identificeren die in het SQL Server proces zijn geladen.

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

• U kunt ook de volgende query gebruiken om geladen modules (DLL's) te onderzoeken en te controleren of er iets onverwachts aanwezig is:

  SELECT * FROM sys.dm_os_loaded_modules
  

• Als u vermoedt dat een gekoppelde servermodule aanzienlijk veel geheugen gebruikt, configureert u deze zo dat deze buiten het proces wordt uitgevoerd door de optie In-process toestaan uit te schakelen. Zie Gekoppelde servers maken voor meer informatie. Niet alle OLE DB-providers voor gekoppelde servers kunnen buiten het proces worden uitgevoerd. Neem voor meer informatie contact op met de fabrikant van de provider.

• In het zeldzame geval waarin OLE Automation-objecten (sp_OA*) worden gebruikt, kunt u instellen dat het object wordt uitgevoerd in een proces buiten SQL Server door een contextwaarde op te geven van 4 (alleen lokaal (.exe) OLE-server). Zie sp_OACreate voor meer informatie.

Intern geheugengebruik door de SQL Server-engine

Gebruik de volgende methoden om interne geheugendruk van onderdelen in de SQL Server-engine vast te stellen:

• Begin met het verzamelen van Performance Monitor tellers voor SQL Server: SQL Server:Bufferbeheer en SQL Server:Memory Manager.

• Voer meerdere keren een query uit op de SQL Server-DMV voor geheugenklerken om te zien waar in de engine het hoogste geheugenverbruik optreedt.

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

• U kunt ook de gedetailleerdere DBCC MEMORYSTATUS uitvoer bekijken en zien hoe deze wordt gewijzigd wanneer u deze foutberichten ziet.

  DBCC MEMORYSTATUS
  

• Als u een duidelijke dader onder de geheugenbedienden identificeert, moet u zich richten op de specifieke kenmerken van het geheugenverbruik voor dat onderdeel. Hier volgen enkele voorbeelden:

  • Als de MEMORYCLERK_SQLQERESERVATIONS geheugenbediende geheugen geheugen verbruikt, identificeert u query's die gebruikmaken van grote geheugentoekenningen en optimaliseert u deze met behulp van indexen, door ze te herschrijven (bijvoorbeeld verwijderen ORDER BY), of door queryhints voor geheugentoekenningen (MIN_GRANT_PERCENT en MAX_GRANT_PERCENT) toe te passen. Zie Hints voor query's voor meer informatie. U kunt ook een resourcepool maken om het gebruik van geheugentoewijzingen te beheren. Zie Problemen met trage prestaties of geheugenproblemen oplossen die worden veroorzaakt door geheugentoelagen in SQL Server voor meer informatie over geheugentoelagen.
  • Als veel ad-hocqueryplannen in de cache worden opgeslagen, gebruikt de CACHESTORE_SQLCP geheugenbediende grote hoeveelheden geheugen. Identificeer niet-geparameteriseerde query's waarvan de queryplannen niet kunnen worden hergebruikt en parameteriseer deze door ze om te zetten in stored procedures, door sp_executesql te gebruiken of door FORCED-parameterisatie te gebruiken. Als traceringsvlag 174 is ingeschakeld, kunt u deze uitschakelen om te zien of het probleem hiermee wordt opgelost.
  • Als het cachearchief CACHESTORE_OBJCP van het objectplan te veel geheugen verbruikt, identificeert u welke opgeslagen procedures, functies of triggers grote hoeveelheden geheugen gebruiken en kunt u overwegen de toepassing opnieuw te ontwerpen. Dit gebeurt meestal met veel databases of schema's die elk honderden procedures bevatten.
  • Als de OBJECTSTORE_LOCK_MANAGER memory clerk grote toewijzingen laat zien, identificeer dan query's die veel vergrendelingen gebruiken en optimaliseer deze met behulp van indexen. Verkort transacties die vergrendelingen gedurende lange perioden in bepaalde isolatieniveaus bevatten of controleer of escalatie van vergrendelingen is uitgeschakeld.
  • Als u een zeer grote TokenAndPermUserStore (SELECT type, name, pages_kb FROM sys.dm_os_memory_clerks WHERE name = 'TokenAndPermUserStore') ziet, kunt u traceringsvlag 4618 gebruiken om de cachegrootte te beperken.
  • Als u geheugenproblemen met In-Memory OLTP vanuit de MEMORYCLERK_XTP geheugenbeheerder vaststelt, raadpleegt u Geheugengebruik voor In-Memory OLTP bewaken en problemen oplossen en Fouten wegens onvoldoende geheugen in voor geheugen geoptimaliseerde tempdb-metagegevens (HkTempDB).

Veelgestelde vragen

Waarom gebruikt SQL Server bijna alle RAM-geheugen op de server?

De SQL Server buffergroep wordt ontworpen om gegevenspagina's in de cache op te slaan en fysieke I/O te verminderen, zodat het gebruik van onveranderbaar geheugen vaak de maximale servergeheugeninstelling nadert. Dit gedrag wordt verwacht en is geen lek. Als u het verbruik wilt caperen en de hoofdruimte voor het besturingssysteem en andere processen wilt verlaten, configureert u het maximale servergeheugen. Zie Opties voor servergeheugenconfiguratie voor meer informatie.

Wat is het verschil tussen maximaal servergeheugen en het vastgelegde geheugen dat wordt weergegeven in Taakbeheer?

De maximale servergeheugeninstelling beperkt het geheugen dat de SQL Server buffergroep en de meeste geheugenbediende in de engine kan doorvoeren. Taakbeheer toont het vastgelegde geheugen voor het hele sqlservr.exe proces. Deze weergave bevat toewijzingen die onderdelen buiten de buffergroep maken, zoals CLR, gekoppelde serverproviders, uitgebreide opgeslagen procedures en back-upbuffers. Als gevolg hiervan kan het totale procesgeheugen het maximale servergeheugen overschrijden. Zie de handleiding voor geheugenbeheerarchitectuur voor meer informatie.

Wanneer moet ik 'pagina's in het geheugen vergrendelen' (LPIM) inschakelen?

Schakel Pagina's vergrendelen in het geheugen in wanneer het OS de werkset van SQL Server trimt. Dit probleem treedt op als fout 17890 of plotselinge dalingen in totaal servergeheugen. Koppel LPIM met een expliciete maximale servergeheugenwaarde om RAM te behouden voor het besturingssysteem en andere processen. Schakel LPIM niet standaard in voor elke instantie. Gebruik deze om een bevestigd pagingprobleem op te lossen.

Wat vertelt sys.dm_os_memory_clerks mij?

sys.dm_os_memory_clerksretourneert één rij voor elke actieve geheugenbediende in de SQL Server engine, met de hoeveelheid geheugen die de clerk doorvoert. Gebruik dit om te vinden welk onderdeel (bijvoorbeeld buffergroep, plancache, vergrendelingsbeheer of querygeheugentoekenningen) het meeste geheugen verbruikt en om uw afstemmingsinspanning te leiden.