mygil

Hallo! Danke für deine Antwort! Die "globalen Firewall Einstellungen" kannte ich bis heute noch gar nicht. (Rechte Maustaste auf 1. Windows-Firewall-Knoten + Eigenschaften) Darin erkennt man viel einfacher/verständlicher was standardmäßig blockiert und zugelassen wird. Genau so was hab ich gesucht!! Danke für das vervollständigen + korrigieren meines Gedankengangs! :) Lg Gilbert

Hallo! Ein frisch installierter Windows Server hat standardmäßig Aktive und Inaktive "Ausgehende Regeln" gesetzt die alle auf "Zugelassen" gestellt sind. Ich behaupte jetzt, dass weder die Aktivierten noch die Inaktiven Regeln darin irgendeine Bedeutung haben! Ich könnte alles auf Aktiv stellen und hätte nichts verändert, genauso könnte ich alles auf Inaktiv stellen und hätte immer noch die gleiche Einstellung. Lieg ich richtig? Ich glaub das weil folgendes in der Beschreibung steht: "Ausgehende Verbindungen werden nur dann nicht zugelassen, wenn sie einer Regel entsprechen, durch die sie blockiert werden. Meiner Meinung nach gilt: Bei Eingehende Regeln: Nur Einträge mit grünen Symbole haben hier eine Bedeutung (Graue und vor allem Rote Symbole bezwecke nichts). Bei Ausgehende Regeln: Nur Einträge mit roten Symbole haben hier eine Bedeutung (Graue und vor allem Grüne Symbole bezwecken nichts). Lieg ich richtig oder hab ich jetzt einen Denkfehler? Danke & lg Gilbert

Hallo Leute! Die Sache ist gelöst! Ursache waren: Eine böse Auswertung hat die 1/2 unserer Daten in einen Report geladen und gleichzeitig 800.000 einzelne Abfragen gegen unsere Produktiv-DB geworfen. Die Auswertung wurde sauber neugebaut und dauert jetzt nur noch 2-3 Sekunden :D Zudem haben wir noch ein Problem in einer Open-Edge-DB-System Tabelle festgestellt dass wir lösen konnten. Ein Feld das auf max. 50 Zeichen gesetzt wurde - wurde mit 70 Zeichen beschrieben (dieses DB-System lässt das zu :suspect:) und damit kommt ODBC und verständlicherweise SQL Server nicht wirklich klar. Es war also von Anfang an eine komplett spezifisches Problem von uns. Sorry!!! Vielen Dank für eure Hilfe und Unterstützung!!! lg myGil

Hallo! Hab jetzt auf der neuen VM-Ware Maschine ebenso einen alten SQL Server 2008 (ohne R2) installiert und siehe da auch dieser SQL Server läuft ein wenig langsamer. Damit liegt es also nicht mehr am SQL Server sondern am Betriebssystem und somit bin ich hier im SQL Server Forum komplett falsch :) Vielen Dank für euch Hilfe!

Hallo! Mit Option (force order) erhalte ich die komplett gleichen Ergebnisse. Alt: select top 100000 * from Auftrag braucht 3 Sekunden Neu: select top 100000 * from Auftrag braucht 4 Sekunden Hab schon DB neu erstellt und die Tabelle sozusagen frisch in eine neue DB gespielt - immer ist der Neue SQL Server bei so einfachen Aufgaben 1-3 Sekunden langsamere) (Oben im Screenshot stehen im neuen Abfrageplan Gather-Stream und Partion-Stream? Das Google ich mir mal morgen ein wenig - vielleicht stoß ich dabei auf eine mögliche Ursache) Wenn aber jemand noch einen Tipp für mich hat :) myGil

Hallo! Wir haben vor kurzem eine SQL Server Umstellung von 2008 Express (ohne R2) auf SQL Server 2012 Standard durchgeführt. SQL Server 2008 (ohne R2) hat u.a. ja folgende Einschränkungen: Max 1GB Arbeitsspeicher, 1 Kern etc. SQL Server 2012 Standard hat hingegen deutlich mehr wie beispielsweise: 4 Kerne und mehr Arbeitsspeicher. Das folgende sehr einfache SQL Statement dauerte bei unserem alten eingeschränkten SQL exakt 0 Sekunden: select * from Auftrag A left join Kurstour KT on KT.TourKey = A.TourKey left join Kurs KK on KK.KursKey = KT.Kurskey where A.AuftragID = 123 Bei unserem neuen SQL Server dauert die exakt selbe Abfrage mit dem gleichen Datenstand aber 2 Sekunden? Kann das jemand erklären? Im Anhang hätte ich die beiden "Ausführungspläne" dazu hochgeladen! Vielen Dank für eure Unterstützung im Voraus!! lg myGil (OS In diesen DB wurden weder in der neuen noch in der alten Version "Indizes" erstellt - ich würde gerne vorher noch ohne auskommen bevor ich hier unterschiedliche Ausgangssitituationen erstelle.)

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

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

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

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

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.

Post nochmal bitte das komplette Statement. lg myGil

Hier ein SQL-Statement das mir mal sehr geholfen hat. Es geht darum, dass du beispielsweise eine Liste von Personen hast und in einer Spalte (mit Beistrich getrennt) alle Kurse auflistet möchtest die sich in einer anderen Tabelle befinden. (Entspricht nicht wirklich deiner Frage, könnte aber vielleicht auch nützlich sein.) select SUBSTRING(( select ', ' + Kursname from Kurse K where K.KursID = P.KursID for xml path('')), 3,4000) AS 'Kurse', * from Personen P Lg myGil

Hallo Zahni! 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. Ja: > SQL Server Windows NT (32-Bit) 0% 3.578,8 MB SQL Server (MSSQLSERVER) Danke Vorab für die Hilfe!

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? 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