Zum Inhalt wechseln


Foto

Sql Server 2012 - Arbeitsspeicher Problem?

MS SQL

  • Bitte melde dich an um zu Antworten
16 Antworten in diesem Thema

#1 mygil

mygil

    Newbie

  • 23 Beiträge

 

Geschrieben 16. April 2015 - 08:09

Hallo!

 

Wir haben folgendes im Einsatz:

  • Windows Server 2012  64-BIT, Virtuelle-Hyper-V-Maschine , Virtuelle VM-Ware Maschine,  16 GB Arbeitsspeicher, Genügend Festplatten platz.
  •  SQL Server Standard 2012  32-BIT (!) Zwingend notwendig
  • (select @@version liefert bsp):  Microsoft SQL Server 2012 - 11.0.5058.0 (Intel X86) Standard Edition on Windows NT 6.3 <X64> (Build 9600: ) (WOW64) (Hypervisor)
  • Alle verfügbaren Betriebssystem und SQL Server updates (inkl. SP2) sind installiert.

Der SQL Server wurde frisch installiert bzw. wurden bis jetzt noch keine Konfigurationsänderungen vorgenommen.

Eingesetzt wird alles mögliche wie beispielsweise: DB-Server für Anwendungen, StoredProcedures, SSIS, SSRS, SSAS, Sql-Agent, Wartungspläne etc.

Das Problem ist einfach erklärt: Der Server läuft nach einem Neustartsart (bsp. der SQL Server Instanz) einwandfrei und nach 1-2 Tagen erhalte ich an unterschiedlichen Stellen Fehlermeldungen wie beispielsweise:

 

Ausführung:

SELECT * FROM OPENQUERY(LimeSurvey, 'SELECT * FROM lime_survey_94728')

Fehlermeldung:

 Der OLE DB-Anbieter 'MSDASQL' für den Verbindungsserver 'LimeSurvey' hat die Meldung 'Aufgrund des Systemfehlers   8: Für diesen Befehl ist nicht genügend Speicher verfügbar.
 (MySQL ODBC 5.1 Driver, C:\Program Files (x86)\MySQL\Connector ODBC 5.1\myodbc5.dll) konnte der angegebene Treiber nicht geladen werden.' zurückgeben.
 Meldung 7303, Ebene 16, Status 1, Zeile 1
 Das Datenquellenobjekt des OLE DB-Anbieters 'MSDASQL' für den Verbindungsserver 'LimeSurvey' kann nicht initialisiert werden.

 

Sobald man die SQL-Server-Instanz jetzt neu startet, klappt die Abfrage wieder.

Handelt es sich hierbei um ein Problem mit dem Arbeitsspeicher?
Hat jemand an der Stelle vielleicht schon eine Lösung für das Problem? Muss ich vielleicht zwingend die maximale Speichernutzung auf einen 4096 Wert oder sowas einschränken?

 

Den folgenden Bericht habe ich mir jetzt zweimal erstellt: "SqlManagementStudio/Serverknoten/Rechts klicks/Berichte/Standardberichte/Arbeitsspeichernutzung"

Und zwar 1x zum Zeitpunkt des Problems und 1x nach einem frischen Neustart des Server. 

 

Hier das Ergebnis wenn der Server frisch gestartet ist:

  • Memoryclerk_Sqlbufferpool: 21.440 KB
  • Cacherestore_Sqlcp:  16.736 KB
  • Objectstore_lock_manager: 17.552 KB
  • Nemoryclerk_sqlstoreng:  11.960 KB
  • Nemoryclerk_sqlgeneral:  6.672 KB
  • Sonstige:   36.468 KB

Hier das Ergebnis zum Zeitpunkt des Problem:

  • Memoryclerk_Sqlbufferpool: 2.982.544 KB  
  • Memoryclear_Sqlqereservations: 152.720 KB  
  • Cacherestore_Sqlcp:  22.416 KB  
  • Objectstore_lock_manager: 22.392 KB  
  • Memoryclerk_sosnode:  21.544 KB  
  • Sonstige:   113.768 KB

Kann das jemand interpretieren oder erkennt jemand eine Schwachstelle?

lg myGil


Bearbeitet von mygil, 17. April 2015 - 07:05.


#2 wiri

wiri

    Junior Member

  • 147 Beiträge

 

Geschrieben 16. April 2015 - 13:38

was hast du denn in der Instanz für max Speicherwerte eingetragen?

 

der sollte immer kleiner als der maximale Hauptspeicher sein, da ja windows auch noch was braucht.


MCSE 2003
CNA

#3 zahni

zahni

    Expert Member

  • 16.497 Beiträge

 

Geschrieben 16. April 2015 - 13:57

Eine  32-Bit Version  des SQL-Servers garantiert  nicht zwingend notwendig. Das geht die  Anwendung überhaupt nichts an. Die soll "SQL" mit dem Server reden.

Und schon gar nicht bei LimeSurvey. Wenn Du den richtigen PHP-Treiber installiert, klappt es  auch mit dieser  Software.

Siehe u.a. hier https://www.limesurv...on&limitstart=0


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#4 mygil

mygil

    Newbie

  • 23 Beiträge

 

Geschrieben 16. April 2015 - 14:13

Hallo Wiri!

 

Wie geschrieben habe ich keine Servereinstellungen verändert und alles auf Standard belassen:

Minimaler Serverarbeitsspeicher (in MB): 0

Maximaler Serverarbeitsspeicher (in MB): 2.147.483.647

 

Das Betriebssystem selbst hat 16GB Arbeitsspeicher.

Der Prozess "SQL Server (MSSQLSERVER)" wächst für immer auf ca. 3,6GB hinauf.

Im folgenden Microsoft Artikel wird ganz unten ein SQL-Statement beschrieben: https://msdn.microso...v=sql.110).aspx

SELECT

(physical_memory_in_use_kb/1024) AS Memory_usedby_Sqlserver_MB,

(locked_page_allocations_kb/1024) AS Locked_pages_used_Sqlserver_MB,

(total_virtual_address_space_kb/1024) AS Total_VAS_in_MB,

process_physical_memory_low,

process_virtual_memory_low

FROM sys.dm_os_process_Memory;

 

Das liefert mir im Augenblick folgende Werte:

Memory_usedby_Sqlserver_MB: 3626

Locked_pages_used_Sqlserver_MB: 0

Total_VAS_in_MB: 4095

process_physical_memory_low: 0

process_virtual_memory_low: 0

 

lg myGil


Hallo Zahni!

 

Deine Antwort verstehe ich jetzt leider überhaupt nicht.

 

Was meinst du mit?

Eine  32-Bit Version  des SQL-Servers garantiert  nicht zwingend notwendig.

 

Die Limesurvey Abfrage war nur ein Beispiel.

(Hier verwende ich einen SQL Verbindungsserver der über ODBC mit MYSQL Treiber auf eine MYSQL Datenbank zugreift und daraus Auswertungen erstellt)

 

Erwähnen sollte ich vielleicht auch noch:

Bevor ich letzte Woche die Umstellung auf das neue Betriebssystem (siehe oben) und den neuen SQL Server (siehe oben) gemacht habe lief das Ganze System Problem los auf einem SQL Server 2008 (ohne R2) trotz den Einschränkungen wie beispielsweise max. 4GB DB, max. 1GB Arbeitsspeicher, max. 1Kern.

 

Die LimeSurvey Anwendung selbst läuft auf einem anderen System mit eigener (mysql) Datenbank.

 

Lg myGil


Bearbeitet von mygil, 16. April 2015 - 14:15.


#5 zahni

zahni

    Expert Member

  • 16.497 Beiträge

 

Geschrieben 16. April 2015 - 14:20

Du hast  geschrieben, dass man zwingend einen 32-Bit SQL-Server braucht. Dies habe  ich bezweifelt.

Übrigens ist der Zugriff per native ODBC-Schnittstelle  i.d.R. nicht empfehlenswert. Es gibt sogar von MS native PHP-Treiber.

Steht im Taskmanager hinter dem SQL-Server-Prozess ein "*32" ? Wenn nicht, ist es ein 64-Bit Server.


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#6 mygil

mygil

    Newbie

  • 23 Beiträge

 

Geschrieben 16. April 2015 - 15:13

Hallo Zahni!

 

Du hast  geschrieben, dass man zwingend einen 32-Bit SQL-Server braucht. Dies habe  ich bezweifelt.

 

Wir im Unternehmen brauchen zwingend einen 32-BIT SQL Server aber aus ganz anderen Gründen bzw. bezog sich das nicht auf Limesurvey oder der Beispielabfrage.

 

Steht im Taskmanager hinter dem SQL-Server-Prozess ein "*32" ? Wenn nicht, ist es ein 64-Bit Server.

 

Ja:

> SQL Server Windows NT (32-Bit)     0%      3.578,8 MB

SQL Server (MSSQLSERVER)

 

Danke Vorab für die Hilfe!



#7 mygil

mygil

    Newbie

  • 23 Beiträge

 

Geschrieben 17. April 2015 - 06:33

Hallo!

 

Heute habe ich wieder an einer völlig anderen Stelle die praktisch gleiche Fehlermeldung bekommen.

Diesmal habe ich versucht ein SSIS Paket "Bereitzustellen" und stoß dabei auf folgende Fehlermeldung:

 

TITEL: SQL Server Integration Services
------------------------------

Fehler beim Erstellen der AppDomain 'SSISDB.dbo[runtime].49'.
Die Datei oder Assembly "System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" oder eine Abhängigkeit davon wurde nicht gefunden. Für diesen Befehl ist nicht genügend Speicher verfügbar. (Ausnahme von HRESULT: 0x80070008) (Microsoft SQL Server, Fehler: 6517)

 

Zeitgleich funktioniert die oben beschrieben SQL-Anweisung (Limesurvey Abfrage) die gestern das gleiche Problem brachte einwandfrei.

 

Ich kann an der Stelle nur Vermutungen aufstellen wie beispielsweise dass der SQL Server (aufgrund 32-BIT WOW64 oder so) nur 4 GB Arbeitsspeicher verwenden darf aber trotzdem versucht mehr aus dem Betriebssystem zu nehmen.
Ich hab mir natürlich wieder den kompletten Report der Arbeitsspeichernutzung (den ich ja nicht wirklich interpretieren kann) zum Zeitpunkt des Problems weggespeichert.

Ich stelle jetzt den Server mal auf eine max. Arbeitsspeichernutzung von 3GB - mal sehen ob dann die Probleme aufhören - wenn alles klappt dann fahre ich natürlich auf 4GB hoch und schau was dann passiert.

Aber vielleicht hat jemand noch einen Tipp für mich dass die Situation irgendwie erklären könnte?

 

Danke myGil

PS: Wie erwartet konnte das SSIS-Paket nach dem Neustart der SQL Server Instanz ohne Probleme "bereitgestellt" werden.


Bearbeitet von mygil, 17. April 2015 - 06:38.


#8 wiri

wiri

    Junior Member

  • 147 Beiträge

 

Geschrieben 17. April 2015 - 06:57

Hi

die Meldungen laufen ja immer mit einem roten Faden namens Speichermangel. Bitte drehe für den Server bitte im HyperV den Speicher hoch und in der Instanz den max speicher auf Hypervspeicher -20%.

 

Das funkioniert bei mir auf 250 Instanzen....


MCSE 2003
CNA

#9 mygil

mygil

    Newbie

  • 23 Beiträge

 

Geschrieben 17. April 2015 - 07:15

Hallo!

 

(Erstmals großes Sorry weil ich hab eine falsche Angabe gemacht - es handelt sich nicht um eine Hyper-V Maschine sondern um eine virtuelle VMware Maschine. Ich hab das oben im 1. Betrag erkennbar korrigiert.)

Die virtuelle VMware Maschine hat im Augenblick 16GB hinterlegt und laut Taskmanager kommt er auch zum Zeitpunkt der Fehlermeldungen nicht annährend auf 50% Arbeitsspeicherausnutzung.

 

Die Probleme beginnen bereits wenn der SQL Server Prozess (lt. Windows Explorer) auf beispielsweise auf 3,6 GB steht.

Um herauszufinden ob der SQL-Server sich vielleicht mehr Speicher versucht zuzuteilen wie er eigentlich sollte, habe ich testweise den "Maximale Serverarbeitsspeicher (in MB)" auf 3GB gedrosselt.

 

Danke myGil


Bearbeitet von mygil, 17. April 2015 - 07:18.


#10 wiri

wiri

    Junior Member

  • 147 Beiträge

 

Geschrieben 17. April 2015 - 07:31

Was sagt den das Windowslog, was sagt das SQL-log?


MCSE 2003
CNA

#11 mygil

mygil

    Newbie

  • 23 Beiträge

 

Geschrieben 17. April 2015 - 08:22

Um 00:30 sollte normalerweise der DataWarehouse Aufbau (via SSIS Pakete) erfolgen und heute in der Nacht hatte er "nichts" dergleichen gemacht.

Hier das SQL Log zu diesem Zeitpunkt:  

Datum  17.04.2015 00:30:00
Protokoll  SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00)

Quelle  spid55

Meldung
Failed to create AppDomain "SSISDB.dbo[runtime].29".
Die Datei oder Assembly "System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" oder eine Abhängigkeit davon wurde nicht gefunden. Für diesen Befehl ist nicht genügend Speicher verfügbar. (Ausnahme von HRESULT: 0x80070008)

 

Ich versuch mal den Verlauf ein wenig nachzuvollziehen:

 

) Serverneustart:

Datum  16.04.2015 08:46:31
Protokoll  SQL Server (Archiv-Nr. 3 - 16.04.2015 08:46:00)

Quelle  spid5s

Meldung
SQL Server shutdown has been initiated

) Weil es gerade da steht:

Datum  16.04.2015 08:46:35
Protokoll  SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00)

Quelle  Server

Meldung
Detected 16383 MB of RAM. This is an informational message; no user action is required.

) An der stelle dürfte die SQL-Server-Instanz dann fertig gestartet sein:

Datum  16.04.2015 08:46:39
Protokoll  SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00)

Quelle  spid5s

Meldung
Recovery is complete. This is an informational message only. No user action is required.

 

Kurze Erklärung an der Stell: Wir erstellen Übernacht immer ein Backup aller virtuellen Maschinen via VEEAM.

Gegen der Erwartung, dass das damit zu tun haben könnte haben wir vorgestern diese Backup-Job deaktiviert um zu sehen ob über Nacht alles klappen würde und es hat tatsächlich von vorgestern auf gestern über Nacht alles geklappt.

Um Sicherzustellen, dass das mit diesen Backup-Job aber nichts zu tun haben kann haben wir um gestern 09:50 nochmals den Backup-Job manuell gestartet und der verlief lt. Aussage unserer IT ohne Fehlermeldungen. Wir konnten auch anschließend unsere Berichte, SQL-Statements und Stored-Procedures ohne Probleme ausführen und haben das Thema eigentlich schon abgehackt.

 

) An der Stelle beginnt genau dieser Backup-Job:

Datum  16.04.2015 09:50:37
Protokoll  SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00)

Quelle  Backup

Meldung
Database backed up. Database: Budget2014, creation date(time): 2015/03/30(14:36:50), pages dumped: 370, first LSN: 141:261:37, last LSN: 141:278:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'{A7E6DBD0-142D-46DB-A147-55AC2DE06D28}2'}). This is an informational message only. No user action is required.

) Hier habe wir aber gegen der Erwartung tatsächlich eine Fehlermeldung:

Datum  16.04.2015 09:59:44
Protokoll  SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00)

Quelle  Backup

Meldung
Fehler: 3041, Schweregrad: 16, Status: 1.

) Hier die letzte Meldung des Backup-Jobs:

Datum  16.04.2015 09:59:44
Protokoll  SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00)

Quelle  Backup

Meldung
BACKUP failed to complete the command BACKUP LOG SSISDB. Check the backup application log for detailed messages.

) 1 Stunde später habe ich dann eine Datenbank für eine einfache Adhoc-Analyse erstellt die hier gestaret wird:

Datum  16.04.2015 11:00:01
Protokoll  SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00)

Quelle  spid61

Meldung
Failed to create AppDomain "SSISDB.dbo[runtime].2".
Die Datei oder Assembly "System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" oder eine Abhängigkeit davon wurde nicht gefunden. Für diesen Befehl ist nicht genügend Speicher verfügbar. (Ausnahme von HRESULT: 0x80070008)

) 7 Minuten später kommt dann die folgenden 3 Fehlermeldungen:

Datum  16.04.2015 11:00:01
Protokoll  SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00)

Quelle  spid61

Meldung
Failed to create AppDomain "SSISDB.dbo[runtime].2".
Die Datei oder Assembly "System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" oder eine Abhängigkeit davon wurde nicht gefunden. Für diesen Befehl ist nicht genügend Speicher verfügbar. (Ausnahme von HRESULT: 0x80070008)

 

Datum  16.04.2015 11:00:01
Protokoll  SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00)

Quelle  spid61

Meldung
Fehler: 6517, Schweregrad: 16, Status: 1.

 

Datum  16.04.2015 11:00:01
Protokoll  SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00)

Quelle  spid61

Meldung
Failed to create AppDomain "SSISDB.dbo[runtime].2".
Die Datei oder Assembly "System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" oder eine Abhängigkeit davon wurde nicht gefunden. Für diesen Befehl ist nicht genügend Speicher verfügbar. (Ausnahme von HRESULT: 0x80070008)

 

Diese 3 Fehlermeldung wiederholten sich exakt (!) alle 30 Minuten bis zuletzt heute um 08:30:01 wo ich die SQL Server Instanz erneut startete.

Mit Sicherheit kann ich dem Backup-Job noch nicht die Schuld geben aber der bleibt jetzt auf jeden Fall die nächsten Tage ausgeschalten.

 

lg myGil
 


Bearbeitet von mygil, 17. April 2015 - 08:29.


#12 wiri

wiri

    Junior Member

  • 147 Beiträge

 

Geschrieben 17. April 2015 - 08:51

https://www.bing.com...dbo[runtime].2".


MCSE 2003
CNA

#13 mygil

mygil

    Newbie

  • 23 Beiträge

 

Geschrieben 17. April 2015 - 11:26

Hallo Wiri!

 

Den Link den du geschickt hast scheint nicht wirklich etwas mit meiner Fehlermeldung zu tun haben.
In meiner Fehlermeldung steht ja immer: "Für diesen Befehl ist nicht genügend Speicher verfügbar.".

Aber Danke für den Tipp!

 

Lg myGil



#14 mygil

mygil

    Newbie

  • 23 Beiträge

 

Geschrieben 20. April 2015 - 06:30

Hallo Alle!

 

Das Wochenende über lief alles Problemlos.

Die Änderungen die im Augenblick vorgenommen wurden:

  • VEEAM Backup (habe so eben erfahren dass es sich hierbei nicht um die neueste Version handelt) ist im Augenblick deaktiviert.
  • Maximaler Serverarbeitsspeicher (in MB): wurde von der Standard-Einstellung: 2.147.483.647 MB auf 3.000 MB geändert.

Ich werde das jetzt eine Woche lang in diese Konfiguration laufen lassen um sicherzustellen dass es so immer Problemlos klappt.

Falls das klappt dann werde ich die beiden Punkte nochmals einzeln Testen um zu sehen was zum Problem führt.

 

lg myGil

 



#15 ukulele

ukulele

    Newbie

  • 68 Beiträge

 

Geschrieben 23. April 2015 - 07:44

So wie ich das verstehe dürfte deine Standard-Einstellung von 3.000 MB eigentlich keine Verbesserung bewirken sondern ~2.147 MB sollten das Maximum sein. Ich finde auch die VM Konfiguration mit 16 GB nur bedingt sinnvoll wenn "nur" eine 32 Bit DB betrieben wird.

http://blogs.msdn.co...erver-2012.aspx

 

Bisher wurde ich aber mit dem Problem auch noch nicht konfrontiert.





Auch mit einem oder mehreren der folgenden Tags versehen: MS SQL