mygil 10 Geschrieben 16. April 2015 Melden Teilen Geschrieben 16. April 2015 (bearbeitet) 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 17. April 2015 von mygil Zitieren Link zu diesem Kommentar
wiri 10 Geschrieben 16. April 2015 Melden Teilen Geschrieben 16. April 2015 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. Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 16. April 2015 Melden Teilen Geschrieben 16. April 2015 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.limesurvey.org/en/forum/installation-a-update-issues/93546-2-00-mssql-not-offered-as-an-instal-option?q=/en/forum/installation-a-update-issues/93546-2-00-mssql-not-offered-as-an-instal-option?q=/en/forum/installation-a-update-issues/93546-2-00-mssql-not-offered-as-an-instal-option&limitstart=0 Zitieren Link zu diesem Kommentar
mygil 10 Geschrieben 16. April 2015 Autor Melden Teilen Geschrieben 16. April 2015 (bearbeitet) 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.microsoft.com/de-de/library/ms178067(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 16. April 2015 von mygil Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 16. April 2015 Melden Teilen Geschrieben 16. April 2015 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. Zitieren Link zu diesem Kommentar
mygil 10 Geschrieben 16. April 2015 Autor Melden Teilen Geschrieben 16. April 2015 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! Zitieren Link zu diesem Kommentar
mygil 10 Geschrieben 17. April 2015 Autor Melden Teilen Geschrieben 17. April 2015 (bearbeitet) 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 17. April 2015 von mygil Zitieren Link zu diesem Kommentar
wiri 10 Geschrieben 17. April 2015 Melden Teilen Geschrieben 17. April 2015 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.... Zitieren Link zu diesem Kommentar
mygil 10 Geschrieben 17. April 2015 Autor Melden Teilen Geschrieben 17. April 2015 (bearbeitet) 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 17. April 2015 von mygil Zitieren Link zu diesem Kommentar
wiri 10 Geschrieben 17. April 2015 Melden Teilen Geschrieben 17. April 2015 Was sagt den das Windowslog, was sagt das SQL-log? Zitieren Link zu diesem Kommentar
mygil 10 Geschrieben 17. April 2015 Autor Melden Teilen Geschrieben 17. April 2015 (bearbeitet) 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:00Protokoll SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00) Quelle spid55 MeldungFailed 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:31Protokoll SQL Server (Archiv-Nr. 3 - 16.04.2015 08:46:00) Quelle spid5s MeldungSQL Server shutdown has been initiated ) Weil es gerade da steht: Datum 16.04.2015 08:46:35Protokoll SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00) Quelle Server MeldungDetected 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:39Protokoll SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00) Quelle spid5s MeldungRecovery 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:37Protokoll SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00) Quelle Backup MeldungDatabase 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:44Protokoll SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00) Quelle Backup MeldungFehler: 3041, Schweregrad: 16, Status: 1. ) Hier die letzte Meldung des Backup-Jobs: Datum 16.04.2015 09:59:44Protokoll SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00) Quelle Backup MeldungBACKUP 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:01Protokoll SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00) Quelle spid61 MeldungFailed 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:01Protokoll SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00) Quelle spid61 MeldungFailed 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:01Protokoll SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00) Quelle spid61 MeldungFehler: 6517, Schweregrad: 16, Status: 1. Datum 16.04.2015 11:00:01Protokoll SQL Server (Archiv-Nr. 2 - 17.04.2015 08:34:00) Quelle spid61 MeldungFailed 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 17. April 2015 von mygil Zitieren Link zu diesem Kommentar
wiri 10 Geschrieben 17. April 2015 Melden Teilen Geschrieben 17. April 2015 https://www.bing.com/search?q=Failed+to+create+AppDomain+%22SSISDB.dbo%5Bruntime%5D.2%22. Zitieren Link zu diesem Kommentar
mygil 10 Geschrieben 17. April 2015 Autor Melden Teilen Geschrieben 17. April 2015 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 Zitieren Link zu diesem Kommentar
mygil 10 Geschrieben 20. April 2015 Autor Melden Teilen Geschrieben 20. April 2015 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 Zitieren Link zu diesem Kommentar
ukulele 11 Geschrieben 23. April 2015 Melden Teilen Geschrieben 23. April 2015 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.com/b/sqlosteam/archive/2012/07/12/memory-manager-configuration-changes-in-sql-server-2012.aspx Bisher wurde ich aber mit dem Problem auch noch nicht konfrontiert. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.