18
SQL-Server lahm
wir haben ein akutes Problem mit einem plötzlich lahmen SQL-Server 2008 R2
SQL-Ereignisprotokoll zeigt nur 2 Fehler, aber an denen liegt es wohl:
nltest /dnsgetdc:GAS.local / kein Fehler
repadmin /replsummary = %% Fehler
repadmin /showreps / bringt keine auswertbaren Infos
Ereignisprotokoll:
auf SRV-RDS (fileserver 2008R2):
- Schwerwiegende Warnung Fehler 1203
- Sharepoint 2010 Tiner Fehler
- Test SystemLog nicht bestanden
Ein Zertifikat in der Zertifizierungsstellen-Zertifikatkette 0 für gas-SRV-GAS-CA ist abgelaufen. Ein erforderliches Zertifikat befindet sich nicht im Gültigkeitszeitraum gemessen an der aktuellen Systemzeit oder dem Zeitstempel in der signierten Datei. 0x800b0101 (-2146762495).
SQL-Dump kreiert massenwiese Fehlerberichte, die ich bereits von der Betriebssystem-Partition umgeleitet haben auf eine andere Platte.
Wer kann helfen ?
SQL-Ereignisprotokoll zeigt nur 2 Fehler, aber an denen liegt es wohl:
Ereignis-ID 3210:
Dieser Computer (SQL-SRV) konnte sich nicht mit \\SRV-GAS.gas.local, (DC 2008R2 -SBS) einem Windows-Domänencontroller für Domäne GAS, authentifizieren.
Aus diesem Grund wird dieser Computer möglicherweise Anmeldeanforderungen ablehnen.
Die Ursache hierfür ist möglicherweise ein anderer Computer im gleichen Netzwerk mit demselben Namen,
oder das Kennwort für dieses Computerkonto wird nicht erkannt. Ereignis-ID 5858
ID: {02102CD8-F800-0003-2552-E0D0EDCED701}; Clientcomputer: SRV-SQL; Benutzer: NT-AUTORITÄT\SYSTEM; Clientprozess-ID: 904; Komponente: Unknown; Vorgang: Start IWbemServices::DeleteInstance - Root\Rsop\Computer : RSOP_ExtensionStatus.extensionGuid=
[Diverse ID's wie]"{B087BE9D-ED37-454f-AF9C-04291E351182}";
Ergebniscode: 0x80041002; mögliche Ursache: Unknown
Lösungsansätze:
Ursache dafür liegt in einem ungültigen Passwort für das Computer-Konto, das man zurücksetzen muss.
SRV-SQL aus Domain entfernen Neustarten und wieder einbinden -> Fehler:
Auf Server GAS ist beim Suchen des LDAP-Suchfunktionsattributs ein fehler aufgetreten,. Rückgabewert = 81
Der Host SRV/GAS konnte nicht zu einer IP-Adresse aufgelößt werden. Überprüfen Sie DNS-Server, DHCP, Servername,usw...
DHCP+DNS zeigen keine doppelten Einträge.
DCDiag /s:SRV-GAS geht nicht auf SRV-SQL, sonst ja
auf SRV-GAS:
dcdiag /test:dns (SVR-GAS) ohne Fehler
Auf Server GAS ist beim Suchen des LDAP-Suchfunktionsattributs ein fehler aufgetreten,. Rückgabewert = 81
Der Host SRV/GAS konnte nicht zu einer IP-Adresse aufgelößt werden. Überprüfen Sie DNS-Server, DHCP, Servername,usw...
nltest /dsregdns- DNS-Einträge von Active Directory repariert.
nltest /dnsgetdc:GAS.local / kein Fehler
repadmin /replsummary = %% Fehler
repadmin /showreps / bringt keine auswertbaren Infos
Ereignisprotokoll:
auf SRV-RDS (fileserver 2008R2):
- Schwerwiegende Warnung Fehler 1203
- Sharepoint 2010 Tiner Fehler
- Test SystemLog nicht bestanden
Ein Zertifikat in der Zertifizierungsstellen-Zertifikatkette 0 für gas-SRV-GAS-CA ist abgelaufen. Ein erforderliches Zertifikat befindet sich nicht im Gültigkeitszeitraum gemessen an der aktuellen Systemzeit oder dem Zeitstempel in der signierten Datei. 0x800b0101 (-2146762495).
SQL-Dump kreiert massenwiese Fehlerberichte, die ich bereits von der Betriebssystem-Partition umgeleitet haben auf eine andere Platte.
Wer kann helfen ?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator tomolpi am 09.11.2021 um 22:00:05 Uhr
Beitrag formatiert
Content-ID: 1488112767
Url: https://administrator.de/contentid/1488112767
Ausgedruckt am: 20.11.2024 um 07:11 Uhr
18 Kommentare
Neuester Kommentar
Moin...
hast du das zertifikat mal erneuert?
was ist das für eine umgebung, ich habe da etwas von SBS gelesen. ist das der DC ein SBS2011?
wenn es ein SBS2011 nutze den Assi um die zertifikate zu erneuern...
über die nutzung des SBS2011 brauche ich ja im jahr 2021 nix mehr zu sagen...
es gibt keinen SQL Server 2008 R2... es gibt ein Server 2008R2 und einen SQL Server 2008... ich vermute mal
du meinst den SQL Server im SBS2011...
wenn es ein SBS ist, hat er alle Updates? ist der Server auch von 2011, und die kiste ist am ende?
Frank
hast du das zertifikat mal erneuert?
was ist das für eine umgebung, ich habe da etwas von SBS gelesen. ist das der DC ein SBS2011?
wenn es ein SBS2011 nutze den Assi um die zertifikate zu erneuern...
über die nutzung des SBS2011 brauche ich ja im jahr 2021 nix mehr zu sagen...
lahmen SQL-Server 2008 R2
was ist genau lahm... welche anwendung? was sagt der SQL Monitor? bitte beschreibe dein fehler etwas genauer!es gibt keinen SQL Server 2008 R2... es gibt ein Server 2008R2 und einen SQL Server 2008... ich vermute mal
du meinst den SQL Server im SBS2011...
wenn es ein SBS ist, hat er alle Updates? ist der Server auch von 2011, und die kiste ist am ende?
Frank
Moin, wenn der SQL Server im SBS nicht gemeint ist: Es besteht erstmal keinen Grund den in der Domäne zu haben.
Zu Testzwecken und wenn hier das Problem anfangen sollte, kannst Du den auch Standalone betreiben.
Ich schließe mich meinem Vorredner an: Zu SBS2011 sage ich nichts, und erhöhe um Server 2008R2 oder Server 2008
Zu Testzwecken und wenn hier das Problem anfangen sollte, kannst Du den auch Standalone betreiben.
Ich schließe mich meinem Vorredner an: Zu SBS2011 sage ich nichts, und erhöhe um Server 2008R2 oder Server 2008
und falls wir wirklich über einen SBS reden, frage ich mich auch auf was für ner Hardware der SQL läuft :>
Es sind ja zwei Probleme welche du hier beschreibst.
Das erste kann man fast nur aus deinem Header lesen... SQL Server langsam.
Aber dein restlicher Text passt überhaupt nicht dazu, denn dieser betrifft ja einen Domain Join.
Und anhand deiner Fehlermeldung sollte die Fehlerquelle relativ eindeutig sein: DNS.
Also DNS Einträge überprüfen, ist der Server darin enthalten, wenn ja kann man diesen auch vernünftig auflösen: nslookup
Zweiter Ansatz, hat der SQL Server den korrekten DNS eingetragen, kann dieser die Domäne und andere Server auflösen: nslookup
Aber dein Performance Problem sollte unabhängig von deinem DNS Problem sein. Wahrscheinlich lösen deine Clients den SQL Server nicht auf sondern verbinden sich direkt über die IP.
Wenn du dein Performance Problem gelöst haben möchtest, müsstest du mehr infos dazu geben. Zumindest wie sich die Performance Probleme bemerkbar machen.
Grüße
Somebody
Das erste kann man fast nur aus deinem Header lesen... SQL Server langsam.
Aber dein restlicher Text passt überhaupt nicht dazu, denn dieser betrifft ja einen Domain Join.
Und anhand deiner Fehlermeldung sollte die Fehlerquelle relativ eindeutig sein: DNS.
Also DNS Einträge überprüfen, ist der Server darin enthalten, wenn ja kann man diesen auch vernünftig auflösen: nslookup
Zweiter Ansatz, hat der SQL Server den korrekten DNS eingetragen, kann dieser die Domäne und andere Server auflösen: nslookup
Aber dein Performance Problem sollte unabhängig von deinem DNS Problem sein. Wahrscheinlich lösen deine Clients den SQL Server nicht auf sondern verbinden sich direkt über die IP.
Wenn du dein Performance Problem gelöst haben möchtest, müsstest du mehr infos dazu geben. Zumindest wie sich die Performance Probleme bemerkbar machen.
Grüße
Somebody
DC ist ein SBS2011
aber das Problem scheint am SQL-Server 2008 zu liegen.
Das Netzwerk scheint ok, keine Fehler im DNS oder DHCP erkennbar.
Kein Hinweis auf gleichen Namen im Netzwerk.
SQL-Server korrekt eingetragen, NSlookup ok.
Die Zertifikate sind gültig bis 2023.
SQL-View-Aufrufe und Abfragen in MS-Access die sonst 10 Sekunden dauern, dauern nun 30 Minuten oder länger
Der Speicher ist in den Momenten voll ausgelastet, was er vorher nicht war.
Es scheint als würden Anfragen verzögert mit Rechenleistung beantwortet.
Der SQL-Dump (auf D verlegt, nicht mehr auf C) läuft im Sekundentakt voll,
auch wenn gerade keine Aktivität auf dem Access-Frontend ist.
Dessen Auswertung ist für mich undurchsichtig...
Der SQL-Profiler kreiert im Sekundentakt:
RPC:Completed exec sp_execute 1,10017638 (bis zu 4x gleiche oder andere Zahlen..)
Der Protokoll-Datei-Viewer steht in der Zeit.
Alle Einträge beziehen sich dort auf Quelle spid21s
Ich würde es ja gerne verstehen,
aber ich sehe ohne eure Hilfe keine Chance, hier weiter zu kommen...
aber das Problem scheint am SQL-Server 2008 zu liegen.
Das Netzwerk scheint ok, keine Fehler im DNS oder DHCP erkennbar.
Kein Hinweis auf gleichen Namen im Netzwerk.
SQL-Server korrekt eingetragen, NSlookup ok.
Die Zertifikate sind gültig bis 2023.
SQL-View-Aufrufe und Abfragen in MS-Access die sonst 10 Sekunden dauern, dauern nun 30 Minuten oder länger
Der Speicher ist in den Momenten voll ausgelastet, was er vorher nicht war.
Es scheint als würden Anfragen verzögert mit Rechenleistung beantwortet.
Der SQL-Dump (auf D verlegt, nicht mehr auf C) läuft im Sekundentakt voll,
auch wenn gerade keine Aktivität auf dem Access-Frontend ist.
Dessen Auswertung ist für mich undurchsichtig...
Der SQL-Profiler kreiert im Sekundentakt:
RPC:Completed exec sp_execute 1,10017638 (bis zu 4x gleiche oder andere Zahlen..)
Der Protokoll-Datei-Viewer steht in der Zeit.
Alle Einträge beziehen sich dort auf Quelle spid21s
Ich würde es ja gerne verstehen,
aber ich sehe ohne eure Hilfe keine Chance, hier weiter zu kommen...
moin...
oha...
SQL-View-Aufrufe und Abfragen in MS-Access die sonst 10 Sekunden dauern, dauern nun 30 Minuten oder länger
Der Speicher ist in den Momenten voll ausgelastet, was er vorher nicht war.
und der speicher ist was... 8, 16 oder 32 Gigabyte?
welches SP hat der SQL und wie ist es mit den updates der server?
Frank
oha...
aber das Problem scheint am SQL-Server 2008 zu liegen.
und der läuft wo genau?Das Netzwerk scheint ok, keine Fehler im DNS oder DHCP erkennbar.
ein scheint, sind keine 100%, sonderern eher ein vieleicht!Kein Hinweis auf gleichen Namen im Netzwerk.
ok..SQL-Server korrekt eingetragen, NSlookup ok.
okDie Zertifikate sind gültig bis 2023.
welche?SQL-View-Aufrufe und Abfragen in MS-Access die sonst 10 Sekunden dauern, dauern nun 30 Minuten oder länger
Der Speicher ist in den Momenten voll ausgelastet, was er vorher nicht war.
Es scheint als würden Anfragen verzögert mit Rechenleistung beantwortet.
was sagt der SQL monitor dazu?Der SQL-Dump (auf D verlegt, nicht mehr auf C) läuft im Sekundentakt voll,
läuft in was voll? wiso läuft der durchgehend? oder ws genau meinst du mit SQL Dump?!?auch wenn gerade keine Aktivität auf dem Access-Frontend ist.
okDessen Auswertung ist für mich undurchsichtig...
von wem?Der SQL-Profiler kreiert im Sekundentakt:
RPC:Completed exec sp_execute 1,10017638 (bis zu 4x gleiche oder andere Zahlen..)
Der Protokoll-Datei-Viewer steht in der Zeit.
Alle Einträge beziehen sich dort auf Quelle spid21s
Ich würde es ja gerne verstehen,
aber ich sehe ohne eure Hilfe keine Chance, hier weiter zu kommen...
wo läuft der sql den jetzt genau, auf dem SBS? auf einer extra VM?RPC:Completed exec sp_execute 1,10017638 (bis zu 4x gleiche oder andere Zahlen..)
Der Protokoll-Datei-Viewer steht in der Zeit.
Alle Einträge beziehen sich dort auf Quelle spid21s
Ich würde es ja gerne verstehen,
aber ich sehe ohne eure Hilfe keine Chance, hier weiter zu kommen...
welches SP hat der SQL und wie ist es mit den updates der server?
Frank
1
Hallo Frank, danke für deine Fragen
SQL-Server 10.50.6220 (SP3) läuft auf einem separatem Server 2008R2
mit 8 GB Speicher, die bisher ausreichten. (Zugriff von max. 10 MA's)
Alle anderen Server haben die aktuellsten Updates
Nach bisheriger Analyse von einem "Netzwerk-Fachmann" kein Netzwerkproblem, aber ich bin nicht Jesus...
Zertifikate hat auch der "Fachmann" geprüft - ich kann es nicht wirklich sagen.
SQL-Monitor ?
Der SQL-Dump läuft in der Ablage voll die ich von C nach D geändert habe,
sonst würde gar nix mehr gegen
\\Srv-sql\c$\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log
- Errorlog-Datei füllt sich immer weiter auf
Auf D verlagert und wird im Sekundentakt erzeugt:
SQLDump2482.log
SQLDump2482.mdmp
SQLDump2482.txt
SQLDUMPER_ERRORLOG.log - nur 1x aber füllt sich mit Daten
Ich hoffe, ich habe alles beantwortet...
SQL-Server 10.50.6220 (SP3) läuft auf einem separatem Server 2008R2
mit 8 GB Speicher, die bisher ausreichten. (Zugriff von max. 10 MA's)
Alle anderen Server haben die aktuellsten Updates
Nach bisheriger Analyse von einem "Netzwerk-Fachmann" kein Netzwerkproblem, aber ich bin nicht Jesus...
Zertifikate hat auch der "Fachmann" geprüft - ich kann es nicht wirklich sagen.
SQL-Monitor ?
Der SQL-Dump läuft in der Ablage voll die ich von C nach D geändert habe,
sonst würde gar nix mehr gegen
\\Srv-sql\c$\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log
- Errorlog-Datei füllt sich immer weiter auf
Auf D verlagert und wird im Sekundentakt erzeugt:
SQLDump2482.log
SQLDump2482.mdmp
SQLDump2482.txt
SQLDUMPER_ERRORLOG.log - nur 1x aber füllt sich mit Daten
Ich hoffe, ich habe alles beantwortet...
Wie sieht denn der Ressourcenmonitor auf deinem Server aus?
Also Grundsätzlich würde ich vielleicht mal den Arbeitsspeicher auf dem Server begrenzen, wenn du nur 8 GB zur Verfügung hast, würde ich den SQL Server hier auch eingrenzen:
https://docs.microsoft.com/de-de/sql/database-engine/configure-windows/s ...
Außerdem würde ich das Wiederherstellungsmodell auf "Einfach" setzen, ich kann dir gerade nciht mehr sagen wo das genau ist, aber du wirst es schon finden.
Problem in der Vergangenheit war auch des öfteren ein voll laufendes Transaktionslog, vielleicht ist dies auch bei dir der Fall:
https://docs.microsoft.com/de-de/sql/relational-databases/logs/the-trans ...
Das wären mal meine Ansätze, allerdings kann ich nicht einschätzen wie kritisch die Applikation ist welche auf den SQL Server zugreift. Deshalb die üblichen Backup Regeln bitte beachten
Grüße
Somebody
Also Grundsätzlich würde ich vielleicht mal den Arbeitsspeicher auf dem Server begrenzen, wenn du nur 8 GB zur Verfügung hast, würde ich den SQL Server hier auch eingrenzen:
https://docs.microsoft.com/de-de/sql/database-engine/configure-windows/s ...
Außerdem würde ich das Wiederherstellungsmodell auf "Einfach" setzen, ich kann dir gerade nciht mehr sagen wo das genau ist, aber du wirst es schon finden.
Problem in der Vergangenheit war auch des öfteren ein voll laufendes Transaktionslog, vielleicht ist dies auch bei dir der Fall:
https://docs.microsoft.com/de-de/sql/relational-databases/logs/the-trans ...
Das wären mal meine Ansätze, allerdings kann ich nicht einschätzen wie kritisch die Applikation ist welche auf den SQL Server zugreift. Deshalb die üblichen Backup Regeln bitte beachten
Grüße
Somebody
Hallo,
was steht den in den Log Dateien?
Nachfolgendes nicht von mir:
https://dba.stackexchange.com/questions/87112/the-sql-server-log-folder- ...
First of all, everything that Shanky said in his answer is 100% correct. I would like to add:
The age of the files - If your log folder has several dumps from two years ago, then no dumps for several months, then a few recent dumps, you can safely delete the two year old dumps.
Duplicate dumps - When dumps occur there are three files created: .txt, .log & .mdmp. Open the .txt file for several of the dumps. If they are different, keep the dumps. If they are the same, delete the old ones.
Your available disk space - If the disk where your dumps are accumulating is also the same disk where your database files or transaction log files also reside, and you are going to run out of disk space if you don't do something, and you have no where to move the dump files to, then by all means, delete them.
Types of dumps - If the .log file indicates "Non-yielding Scheduler", "Non-yielding IOCP Listener" or "Non-yielding Resource Monitor", these are performance related specific to CPU. You can troubleshoot those following the steps in this blog: https://blogs.msdn.microsoft.com/karthick_pk/2012/08/21/non-yielding-ioc ...
If the .log file indicates "Deadlocked Schedulers", this is also performance related specific to CPU. You can troubleshoot those following the steps in this blog: https://blogs.msdn.microsoft.com/karthick_pk/2010/06/22/how-to-analyze-d ...
Corruption Dumps - Just as the first answer states, run DBCC CHECKDB. If the output from DBCC CHECKDB indicates corruption in your indexes, rebuild them. If it indicates that "repair allow dataloss is the minimum" necessary to repair the database, then restore from last known good backup.
AV Dumps - You can attempt to tackle this yourself: https://blogs.msdn.microsoft.com/sqlcat/2009/09/11/looking-deeper-into-s ...
If you run into difficulty, open a case with Microsoft, but just as Shanky said, ensure you are on a supported version and you have the latest updates.
was steht den in den Log Dateien?
Nachfolgendes nicht von mir:
https://dba.stackexchange.com/questions/87112/the-sql-server-log-folder- ...
First of all, everything that Shanky said in his answer is 100% correct. I would like to add:
The age of the files - If your log folder has several dumps from two years ago, then no dumps for several months, then a few recent dumps, you can safely delete the two year old dumps.
Duplicate dumps - When dumps occur there are three files created: .txt, .log & .mdmp. Open the .txt file for several of the dumps. If they are different, keep the dumps. If they are the same, delete the old ones.
Your available disk space - If the disk where your dumps are accumulating is also the same disk where your database files or transaction log files also reside, and you are going to run out of disk space if you don't do something, and you have no where to move the dump files to, then by all means, delete them.
Types of dumps - If the .log file indicates "Non-yielding Scheduler", "Non-yielding IOCP Listener" or "Non-yielding Resource Monitor", these are performance related specific to CPU. You can troubleshoot those following the steps in this blog: https://blogs.msdn.microsoft.com/karthick_pk/2012/08/21/non-yielding-ioc ...
If the .log file indicates "Deadlocked Schedulers", this is also performance related specific to CPU. You can troubleshoot those following the steps in this blog: https://blogs.msdn.microsoft.com/karthick_pk/2010/06/22/how-to-analyze-d ...
Corruption Dumps - Just as the first answer states, run DBCC CHECKDB. If the output from DBCC CHECKDB indicates corruption in your indexes, rebuild them. If it indicates that "repair allow dataloss is the minimum" necessary to repair the database, then restore from last known good backup.
AV Dumps - You can attempt to tackle this yourself: https://blogs.msdn.microsoft.com/sqlcat/2009/09/11/looking-deeper-into-s ...
If you run into difficulty, open a case with Microsoft, but just as Shanky said, ensure you are on a supported version and you have the latest updates.
Arbeitsspeicher: max. 6144 MB, AWE wird verwendet
Wiederherstellungsmodell auf "Einfach" setzen: verstehe ich nicht...
Log-Dateien: welche, wo ? bisher kann ich dort nix finden, was weiterhilft...
SQLDump*.Log:
neben unendlichen Zahlenreihen diese Text
2021-11-11 19:40:38.94 spid20s Stack Signature for the dump is 0x00000000EABCC4B7
2021-11-11 19:40:39.34 spid20s External dump process return code 0x20000001.
External dump process returned no errors.
2021-11-11 19:40:48.06 spid22s ex_raise2: Exception raised, major=52, minor=42, state=9, severity=22, attempting to create symptom dump
2021-11-11 19:40:48.07 spid22s Dump thread - spid = 0, EC = 0x0000000121876B20
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * User initiated stack dump. This is not a server exception dump.
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s *Stack Dump being sent to D:\Backup\LOG\SQLDump4740.txt
2021-11-11 19:40:48.07 spid22s * *
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * BEGIN STACK DUMP:
2021-11-11 19:40:48.07 spid22s * 11/11/21 19:40:48 spid 22
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * ex_raise2: Exception raised, major=52, minor=42, state=9, severity=22
2021-11-11 19:40:48.07 spid22s *
SQLDump*.txt:
Computer type is Intel(R) Xeon(R) CPU X3220 @ 2.40GHz.
Bios Version is INTEL - 0
BIOS Date: 03/26/07 12:03:20 Ver: 08.00.10
4 X64 level 8664, 2 Mhz processor (s).
Windows NT 6.1 Build 7601 CSD Service Pack 1.
Memory
MemoryLoad = 87%
Total Physical = 8188 MB
Available Physical = 999 MB
Total Page File = 16374 MB
Available Page File = 8543 MB
Total Virtual = 8388607 MB
Available Virtual = 8380082 MB
Dump thread - spid = 0, EC = 0x00000000F39E8B20
und danach wieder unendliche Zahlenreihen...
Möchte sich jemand mal über Teamviewer gegen Bezahlung einloggen ?
Wiederherstellungsmodell auf "Einfach" setzen: verstehe ich nicht...
Log-Dateien: welche, wo ? bisher kann ich dort nix finden, was weiterhilft...
SQLDump*.Log:
neben unendlichen Zahlenreihen diese Text
2021-11-11 19:40:38.94 spid20s Stack Signature for the dump is 0x00000000EABCC4B7
2021-11-11 19:40:39.34 spid20s External dump process return code 0x20000001.
External dump process returned no errors.
2021-11-11 19:40:48.06 spid22s ex_raise2: Exception raised, major=52, minor=42, state=9, severity=22, attempting to create symptom dump
2021-11-11 19:40:48.07 spid22s Dump thread - spid = 0, EC = 0x0000000121876B20
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * User initiated stack dump. This is not a server exception dump.
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s *Stack Dump being sent to D:\Backup\LOG\SQLDump4740.txt
2021-11-11 19:40:48.07 spid22s * *
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * BEGIN STACK DUMP:
2021-11-11 19:40:48.07 spid22s * 11/11/21 19:40:48 spid 22
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * ex_raise2: Exception raised, major=52, minor=42, state=9, severity=22
2021-11-11 19:40:48.07 spid22s *
SQLDump*.txt:
Computer type is Intel(R) Xeon(R) CPU X3220 @ 2.40GHz.
Bios Version is INTEL - 0
BIOS Date: 03/26/07 12:03:20 Ver: 08.00.10
4 X64 level 8664, 2 Mhz processor (s).
Windows NT 6.1 Build 7601 CSD Service Pack 1.
Memory
MemoryLoad = 87%
Total Physical = 8188 MB
Available Physical = 999 MB
Total Page File = 16374 MB
Available Page File = 8543 MB
Total Virtual = 8388607 MB
Available Virtual = 8380082 MB
Dump thread - spid = 0, EC = 0x00000000F39E8B20
- User initiated stack dump. This is not a server exception dump.
und danach wieder unendliche Zahlenreihen...
Möchte sich jemand mal über Teamviewer gegen Bezahlung einloggen ?
Der mangelnde Speicher ist zurückzuführen auf:
Systemunterbrechungen: Hohe CPU-Auslastung
normal für diesen Prozess: Soll 0,1% bis 2% / Ist 14-25%
Systemunterbrechungen werden immer durch Treiber verursacht !
Alle Hardware-Komponenten im Gerätemanager nacheinander deaktiviert
-> keine Änderung
Unklar woher die Systemunterbrechnungen kommen...
Systemunterbrechungen: Hohe CPU-Auslastung
normal für diesen Prozess: Soll 0,1% bis 2% / Ist 14-25%
Systemunterbrechungen werden immer durch Treiber verursacht !
Alle Hardware-Komponenten im Gerätemanager nacheinander deaktiviert
-> keine Änderung
Unklar woher die Systemunterbrechnungen kommen...
Moin...
allerdings findest du nicht, das jetzt der beste zeitpunkt für aktuelle software wäre?
schon auf Virus und Co. geprüft?
Frank
Zitat von @Senuba:
Arbeitsspeicher: max. 6144 MB, AWE wird verwendet
Wiederherstellungsmodell auf "Einfach" setzen: verstehe ich nicht...
Wiederherstellungsmodelle (SQL Server)Arbeitsspeicher: max. 6144 MB, AWE wird verwendet
Wiederherstellungsmodell auf "Einfach" setzen: verstehe ich nicht...
Log-Dateien: welche, wo ? bisher kann ich dort nix finden, was weiterhilft...
SQLDump*.Log:
neben unendlichen Zahlenreihen diese Text
2021-11-11 19:40:38.94 spid20s Stack Signature for the dump is 0x00000000EABCC4B7
2021-11-11 19:40:39.34 spid20s External dump process return code 0x20000001.
External dump process returned no errors.
2021-11-11 19:40:48.06 spid22s ex_raise2: Exception raised, major=52, minor=42, state=9, severity=22, attempting to create symptom dump
2021-11-11 19:40:48.07 spid22s Dump thread - spid = 0, EC = 0x0000000121876B20
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * User initiated stack dump. This is not a server exception dump.
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s *Stack Dump being sent to D:\Backup\LOG\SQLDump4740.txt
2021-11-11 19:40:48.07 spid22s * *
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * BEGIN STACK DUMP:
2021-11-11 19:40:48.07 spid22s * 11/11/21 19:40:48 spid 22
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * ex_raise2: Exception raised, major=52, minor=42, state=9, severity=22
2021-11-11 19:40:48.07 spid22s *
SQLDump*.txt:
Computer type is Intel(R) Xeon(R) CPU X3220 @ 2.40GHz.
Bios Version is INTEL - 0
BIOS Date: 03/26/07 12:03:20 Ver: 08.00.10
4 X64 level 8664, 2 Mhz processor (s).
Windows NT 6.1 Build 7601 CSD Service Pack 1.
Memory
MemoryLoad = 87%
Total Physical = 8188 MB
Available Physical = 999 MB
Total Page File = 16374 MB
Available Page File = 8543 MB
Total Virtual = 8388607 MB
Available Virtual = 8380082 MB
Dump thread - spid = 0, EC = 0x00000000F39E8B20
*
***Stack Dump being sent to D:\Backup\LOG\SQLDump4766.txt
und danach wieder unendliche Zahlenreihen...
Möchte sich jemand mal über Teamviewer gegen Bezahlung einloggen ?
evtl. morgen am frühen abend...SQLDump*.Log:
neben unendlichen Zahlenreihen diese Text
2021-11-11 19:40:38.94 spid20s Stack Signature for the dump is 0x00000000EABCC4B7
2021-11-11 19:40:39.34 spid20s External dump process return code 0x20000001.
External dump process returned no errors.
2021-11-11 19:40:48.06 spid22s ex_raise2: Exception raised, major=52, minor=42, state=9, severity=22, attempting to create symptom dump
2021-11-11 19:40:48.07 spid22s Dump thread - spid = 0, EC = 0x0000000121876B20
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * User initiated stack dump. This is not a server exception dump.
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s *Stack Dump being sent to D:\Backup\LOG\SQLDump4740.txt
2021-11-11 19:40:48.07 spid22s * *
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * BEGIN STACK DUMP:
2021-11-11 19:40:48.07 spid22s * 11/11/21 19:40:48 spid 22
2021-11-11 19:40:48.07 spid22s *
2021-11-11 19:40:48.07 spid22s * ex_raise2: Exception raised, major=52, minor=42, state=9, severity=22
2021-11-11 19:40:48.07 spid22s *
SQLDump*.txt:
Computer type is Intel(R) Xeon(R) CPU X3220 @ 2.40GHz.
Bios Version is INTEL - 0
BIOS Date: 03/26/07 12:03:20 Ver: 08.00.10
4 X64 level 8664, 2 Mhz processor (s).
Windows NT 6.1 Build 7601 CSD Service Pack 1.
Memory
MemoryLoad = 87%
Total Physical = 8188 MB
Available Physical = 999 MB
Total Page File = 16374 MB
Available Page File = 8543 MB
Total Virtual = 8388607 MB
Available Virtual = 8380082 MB
Dump thread - spid = 0, EC = 0x00000000F39E8B20
*
- User initiated stack dump. This is not a server exception dump.
***Stack Dump being sent to D:\Backup\LOG\SQLDump4766.txt
und danach wieder unendliche Zahlenreihen...
Möchte sich jemand mal über Teamviewer gegen Bezahlung einloggen ?
allerdings findest du nicht, das jetzt der beste zeitpunkt für aktuelle software wäre?
schon auf Virus und Co. geprüft?
Frank
Moin,
wenn ich nach den Fehlern aus dem Dump suche, dann laufen die Ergebnisse in Richtung Korrupte Datenbank....
Kann es evtl. sein das das Problem nach einem Server Absturz oder Wartungsarbeiten aufgetreten ist?
Versuche mal ein Backup von der Datenbank zu machen und die Hardware zu checken.
In einem Thread welchen ich gefunden habe hat scheinbar auch folgendes zur Lösung beigetragen:
Hi,
just to sum-up, what helped in my case, because of sudden death of HDD controller, because of outdated firmware.
When this problem with extremely long log come up.
Check database with DBCC CHECKDB (<DatanaseName>)
When database is damaged, you have to set database into single user mode and then use CHECKDB with additional parameter as example below:
Alter database <DatabaseName> set Single_User
DBCC CHECKDB (<DatanaseName>, REPAIR_REBUILD) -- try to avoid option REPAIR_ALLOW_DATA_LOSS
ALTER DATABASE <DatabaseName> set MULTI_USER
3. If the result show repair was bypassed or corrupted pages as written above (SGAM\IAM), go for most recent >full backup and log backups.
These steps helped me solve my issue and with suggestions from Vikas Rana and Erland.
Thanks,
//Radek
Quelle: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/eb7be5ff-41a6-4 ...
Meine Intensive SQL Zeit liegt schon ein paar Jahre zurück, ich weiß nicht wie schnell ich dir helfen kann.
Wenn du heute Abend gegen 20:00 Uhr Zeit hast kann ich es mir mal anschauen (Gerne PM). Auch erstmal ohne Bezahlung, da können wir uns dann einigen wenn ich das Problem gelöst bekommen sollte.
Aber VIsion2015 ist mit Sicherheit fitter als ich
Grüße
Somebody
wenn ich nach den Fehlern aus dem Dump suche, dann laufen die Ergebnisse in Richtung Korrupte Datenbank....
Kann es evtl. sein das das Problem nach einem Server Absturz oder Wartungsarbeiten aufgetreten ist?
Versuche mal ein Backup von der Datenbank zu machen und die Hardware zu checken.
In einem Thread welchen ich gefunden habe hat scheinbar auch folgendes zur Lösung beigetragen:
Hi,
just to sum-up, what helped in my case, because of sudden death of HDD controller, because of outdated firmware.
When this problem with extremely long log come up.
Check database with DBCC CHECKDB (<DatanaseName>)
When database is damaged, you have to set database into single user mode and then use CHECKDB with additional parameter as example below:
Alter database <DatabaseName> set Single_User
DBCC CHECKDB (<DatanaseName>, REPAIR_REBUILD) -- try to avoid option REPAIR_ALLOW_DATA_LOSS
ALTER DATABASE <DatabaseName> set MULTI_USER
3. If the result show repair was bypassed or corrupted pages as written above (SGAM\IAM), go for most recent >full backup and log backups.
These steps helped me solve my issue and with suggestions from Vikas Rana and Erland.
Thanks,
//Radek
Quelle: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/eb7be5ff-41a6-4 ...
Meine Intensive SQL Zeit liegt schon ein paar Jahre zurück, ich weiß nicht wie schnell ich dir helfen kann.
Wenn du heute Abend gegen 20:00 Uhr Zeit hast kann ich es mir mal anschauen (Gerne PM). Auch erstmal ohne Bezahlung, da können wir uns dann einigen wenn ich das Problem gelöst bekommen sollte.
Aber VIsion2015 ist mit Sicherheit fitter als ich
Grüße
Somebody
Hallo Somebody, ich brauche dann schon Kontaktdaten...
meine: xxxx
meine: xxxx
Hallo,
wie geschrieben am besten per PM/PN (Private Message / Private Nachricht)
Grüße
Somebody
wie geschrieben am besten per PM/PN (Private Message / Private Nachricht)
Grüße
Somebody
das glaube ich jetzt nicht.... kopf meets tischplatte!
kann mal jemand von den Admins die HandyNr. Löschen.....
kann mal jemand von den Admins die HandyNr. Löschen.....
Nummer gelöscht.
