MSSQLSERVER_701

Van toepassing op:SQL Server

Details

Explanation

Fout 701 treedt op wanneer SQL Server er niet in slaagt voldoende geheugen toe te wijzen om een query uit te voeren. Onvoldoende geheugen kan worden veroorzaakt door verschillende factoren, waaronder instellingen van het besturingssysteem, beschikbaarheid van fysiek geheugen, andere componenten die geheugen gebruiken binnen SQL Server, of geheugenlimieten op de huidige werklast. In de meeste gevallen is de mislukte transactie niet de oorzaak van deze fout. Over het algemeen kunnen de oorzaken in drie worden gegroepeerd:

Externe geheugendruk of geheugendruk van het besturingssysteem

Externe druk verwijst naar een hoog geheugengebruik afkomstig van een component buiten het proces, wat leidt tot onvoldoende geheugen voor SQL Server. Je moet nagaan of andere applicaties op het systeem geheugen verbruiken en bijdragen aan een lage geheugenbeschikbaarheid. SQL Server is een van de weinige applicaties die zijn ontworpen om te reageren op de druk op het geheugen van het besturingssysteem door het geheugengebruik te verminderen. Dit betekent dat als een applicatie of driver om geheugen vraagt, het besturingssysteem een signaal naar alle applicaties stuurt om geheugen vrij te maken en SQL Server zal reageren door zijn eigen geheugengebruik te verminderen. Heel weinig andere applicaties reageren omdat ze niet ontworpen zijn om naar die melding te luisteren. Dus als SQL het geheugengebruik begint te verminderen, wordt de geheugenpool verminderd en krijgen de componenten die geheugen nodig hebben het misschien niet. Je begint 701- en andere geheugengerelateerde fouten te krijgen. Voor meer informatie, zie SQL Server Memory Architecture

Interne geheugendruk, niet afkomstig van SQL Server

Interne geheugenbelasting verwijst naar lage geheugen beschikbaarheid veroorzaakt door factoren in het SQL Server-proces. Er zijn componenten die binnen het SQL Server-proces kunnen draaien en die "extern" zijn aan de SQL Server-engine. Voorbeelden zijn DLL's zoals linked servers, SQLCLR-componenten, uitgebreide procedures (XP's) en OLE Automation (sp_OA*). Andere bevatten antivirus- of andere beveiligingsprogramma's die DLL's in een proces injecteren voor monitoringdoeleinden. Een probleem of slecht ontwerp in een van deze componenten kan leiden tot een groot geheugenverbruik. Stel bijvoorbeeld een gekoppelde server voor die 20 miljoen rijen data die van een externe bron komen cacht in het geheugen van SQL Server. Wat SQL Server betreft, zal geen enkele geheugenclerk een hoog geheugengebruik rapporteren, maar het geheugenverbruik binnen het SQL Server-proces zal hoog zijn. Deze geheugengroei van een gekoppelde server-DLL zou bijvoorbeeld ertoe leiden dat SQL Server zijn geheugengebruik begint te verminderen (zie hierboven) en lage geheugencondities van voor componenten binnen SQL Server veroorzaakt, wat fouten zoals 701 veroorzaakt.

Interne geheugendruk, afkomstig van SQL Server-component(en)

Interne geheugendruk van componenten binnen de SQL Server Engine kan ook leiden tot fout 701. Er zijn honderden componenten, gevolgd via sys.dm_os_memory_clerks, die geheugen toewijzen in SQL Server. Je moet vaststellen welke geheugenclerk(s) verantwoordelijk zijn voor de grootste geheugenallocaties om dit verder te kunnen oplossen. Als je bijvoorbeeld merkt dat de geheugenclerk van de OBJECTSTORE_LOCK_MANAGER de grote geheugentoewijzing toont, moet je beter begrijpen waarom de Lock Manager zoveel geheugen verbruikt. Je zult misschien zien dat er queries zijn die een groot aantal sloten verzamelen en deze optimaliseren met behulp van indexen, of transacties verkorten die sloten lange tijd vasthouden, of controleren of lock-escalatie is uitgeschakeld. Elke geheugenclerk of component heeft een unieke manier om geheugen te benaderen en te gebruiken. Voor meer informatie, zie sys.dm_os_memory_clerks en hun beschrijvingen.

Gebruikersactie

Als fout 701 af en toe of voor korte tijd verschijnt, kan er een kortstondig geheugenprobleem zijn dat zichzelf oplost. Misschien hoef je in die gevallen geen actie te ondernemen. Als de fout echter meerdere keren optreedt, op meerdere verbindingen en slechts enkele seconden of langer aanhoudt, volg dan de stappen om verder te onderzoeken.

De volgende lijst geeft algemene stappen die helpen bij het oplossen van geheugenfouten.

Diagnostische hulpmiddelen en vastlegging

De diagnostische tools waarmee je probleemoplossingsgegevens kunt verzamelen zijn Performance Monitor, sys.dm_os_memory_clerks en DBCC MEMORYSTATUS.

Configureer en verzamel de volgende tellers met Performance Monitor:

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

Verzamel periodieke uitvoer van deze query op de getroffen SQL Server

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

Pssdiag of SQL LogScout

Een alternatieve, geautomatiseerde manier om deze datapunten vast te leggen is het gebruik van tools zoals PSSDIAG of SQL LogScout.

• Als je Pssdiag gebruikt, configureer dan om Perfmon collector en de Custom Diagnostics\SQL Memory Error Collector vast te leggen
• Als je SQL LogScout gebruikt, configureer dan om het geheugenscenario vast te leggen

De volgende secties beschrijven meer gedetailleerde stappen voor elk scenario - externe of interne geheugendruk.

Externe druk: diagnostiek en oplossingen

• Om lage geheugencondities op het systeem buiten het SQL Server-proces te diagnosticeren, verzamel je Performance Monitor counters. Onderzoek of applicaties of diensten anders dan SQL Server geheugen op deze server verbruiken door naar deze tellers te kijken:

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

  Hier is een voorbeeld van een Perfmon-logcollectie met 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)) }
  }
  }
  

• Bekijk het System Event-log en zoek naar geheugengerelateerde fouten (bijvoorbeeld laag virtueel geheugen).

• Controleer het toepassingsgebeurtenislogboek op toepassingsgerelateerde geheugenproblemen.

  Hier is een voorbeeld van een PowerShell-script om de Systeem- en applicatie-gebeurtenislogs te doorvragen op het trefwoord "geheugen". Voel je vrij om andere strings zoals "resource" te gebruiken voor je zoekopdracht:

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

• Pak eventuele code- of configuratieproblemen aan voor minder kritieke applicaties of diensten om hun geheugengebruik te verminderen.

• Als applicaties naast SQL Server resources verbruiken, probeer dan deze applicaties te stoppen of opnieuw te plannen, of overweeg ze op een aparte server te draaien. Deze stappen nemen de druk op het externe geheugen weg.

Interne geheugendruk, niet afkomstig van SQL Server: diagnostiek en oplossingen

Om interne geheugendruk veroorzaakt door modules (DLL's) binnen SQL Server te diagnosticeren, gebruik je de volgende methode:

• Als SQL Server de optie Pages in memory vergrendelen (AWE API) niet gebruikt, wordt het grootste deel van zijn geheugen weergegeven in de Process:Private Bytes-teller (SQLServrinstance) in Performance Monitor. Het totale geheugengebruik binnen de SQL Server-engine wordt weerspiegeld in SQL Server:Memory Manager: Total Server Memory (KB) teller. Als je een significant verschil vindt tussen de waarde Process:Private Bytes en SQL Server:Memory Manager: Total Server Memory (KB), dan komt dat verschil waarschijnlijk van een DLL (linked server, XP, SQLCLR, enz.). Als bijvoorbeeld Private bytes 300 GB zijn en het totale servergeheugen 250 GB, dan komt ongeveer 50 GB van het totale geheugen in het proces van de externe SQL Server-engine.

• Als SQL Server Lock Pages in het geheugen (AWE API) gebruikt, is het moeilijker om het probleem te identificeren omdat Performance Monitor geen AWE-tellers biedt die het geheugengebruik voor individuele processen bijhouden. Het totale geheugengebruik binnen de SQL Server-engine wordt weerspiegeld in SQL Server:Memory Manager: Total Server Memory (KB) teller. Typische waarden voor proces:privébytes kunnen variëren tussen 300 MB en 1-2 GB over het algemeen. Als je een aanzienlijk gebruik van Process:Private Bytes vindt buiten dit gebruikelijke gebruik, dan komt het verschil waarschijnlijk door een DLL (gekoppelde server, XP, SQLCLR, enz.). Als bijvoorbeeld de Private bytes teller 5-4 GB is en SQL Server gebruikt Lock pages in memory (AWE), dan kan een groot deel van de Private bytes afkomstig zijn van een externe SQL Server-engine. Dit is een benaderingstechniek.

• Gebruik de Tasklist-tool om DLL's te identificeren die binnen de SQL Server-ruimte zijn geladen:

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

• Je kunt deze query ook gebruiken om geladen modules (DLL's) te onderzoeken en te zien of er iets niet verwacht wordt

  SELECT * FROM sys.dm_os_loaded_modules
  

• Als je vermoedt dat een gekoppelde servermodule veel geheugenverbruik veroorzaakt, kun je deze zo instellen dat deze zonder proces komt te zitten door de optie 'Inprocess toestaan ' uit te schakelen. Zie Create linked servers (SQL Server Database Engine) voor meer informatie. Niet alle gekoppelde servers OLEDB-providers raken zonder proces; Neem contact op met de productfabrikant voor meer informatie.

• In het zeldzame geval dat OLE-automatiseringsobjecten worden gebruikt (sp_OA*), kun je het object configureren om te draaien in een proces buiten SQL Server door context = 4 in te stellen (alleen lokaal (.exe) OLE-server). Voor meer informatie, zie sp_OACreate.

Intern geheugengebruik door de SQL Server-engine: diagnostiek en oplossingen

• Begin met het verzamelen van prestatiemonitortellers voor SQL Server:SQL Server:Buffer Manager, SQL Server: Memory Manager.

• Vraag meerdere keren bij de DMV van de SQL Server geheugenadministratie om te zien waar het hoogste geheugenverbruik plaatsvindt binnen de engine:

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

• Alternatief kun je de meer gedetailleerde DBCC MEMORYSTATUS-output observeren en hoe deze verandert wanneer je deze foutmeldingen ziet.

  DBCC MEMORYSTATUS
  

• Als je een duidelijke boosdoener onder de geheugenclerks identificeert, richt je dan op het aanpakken van de specifieke geheugenconsumptie voor dat component. Hier volgen enkele voorbeelden:

  • Als MEMORYCLERK_SQLQERESERVATIONS geheugenclerk geheugen verbruikt, identificeer dan queries die enorme geheugentoewijzingen gebruiken en optimaliseer deze via indexen, herschrijf ze (verwijder bijvoorbeeld ORDER by), of pas queryhints toe.
  • Als een groot aantal ad hoc queryplannen wordt gecached, gebruikt de CACHESTORE_SQLCP geheugenclerk grote hoeveelheden geheugen. Identificeer niet-geparametriseerde queries waarvan de queryplannen niet hergebruikt kunnen worden en parametriseer ze door ze om te zetten naar opgeslagen procedures, of door gebruik te maken sp_executesqlvan , of door FORCED-parametrisatie te gebruiken.
  • Als object plan cacheopslag CACHESTORE_OBJCP veel geheugen verbruikt, doe dan het volgende: identificeer welke opgeslagen procedures, functies of triggers veel geheugen gebruiken en ontwerp mogelijk de applicatie opnieuw. Vaak gebeurt dit door grote hoeveelheden databases of schema's met honderden procedures in elk.
  • Als de OBJECTSTORE_LOCK_MANAGER geheugenclerk de grote geheugenallocaties toont, identificeer dan queries die veel locks toepassen en optimaliseer deze met behulp van indexen. Verkort transacties waardoor sloten lange tijd niet worden vrijgegeven in bepaalde isolatieniveaus, of controleer of de lock-escalatie is uitgeschakeld.

Snelle verlichting die geheugen beschikbaar kan maken

De volgende acties kunnen wat geheugen vrijmaken en beschikbaar stellen voor SQL Server:

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

  • maximaal servergeheugen

  • minimale servergeheugen

    U ziet ongebruikelijke instellingen. Corrigeer ze indien nodig. Houd rekening met de verhoogde geheugenvereisten. Standaardinstellingen worden vermeld in opties voor servergeheugenconfiguratie.

• Als je het maximale servergeheugen nog niet hebt geconfigureerd, vooral met Lock Pages in het geheugen, overweeg dan een bepaalde waarde in te stellen zodat er wat geheugen voor het besturingssysteem beschikbaar is. Zie Pagina's vergrendelen in de configuratieoptie van geheugenserver .

• Controleer de queryworkload: aantal gelijktijdige sessies, momenteel uitvoerende queries en kijk of er minder kritieke applicaties zijn die tijdelijk kunnen worden gestopt of naar een andere SQL Server kunnen worden verplaatst.

• Als je SQL Server draait op een virtuele machine (VM), zorg er dan voor dat het geheugen van de VM niet overbelast is. Voor ideeën over hoe geheugen voor VM's te configureren, zie deze blog Virtualization – Overcommitting memory and how to detect it within the VM and Troubleshooting ESX/ESXi virtual machine performance issues (memory overcommitment)

• Je kunt de volgende DBCC-commando's uitvoeren om meerdere SQL Server-geheugencaches vrij te maken.

  • DBCC FREESYSTEMCACHE

  • DBCC FREESESSIONCACHE (Gebruik deze SQL Server-opdracht om cache van sessies vrij te maken.)

  • DBCC FREEPROCCACHE

• Als je Resource Governor gebruikt, raden we aan om de instellingen van de resource pool of workload group te controleren en te zien of ze het geheugen niet te drastisch beperken.

• Als het probleem aanhoudt, moet je verder onderzoek doen en mogelijk de serverbronnen (RAM) vergroten.