7
Sharepoit - SQL Log läuft über SBS 2011
Hallo Leute
Ich hoffe ihr könnte mir auch bei diesem Problem helfen.
Ich musste vor kurzen einen Fremden SBS 2011 Server übernehmen.
Dieser läuft Virtuell und hat 4 virtuelle Festplatten mit folgender Aufteilung
1x Syststem
1x Daten
1x Exchange
1x WSUS
Soweit alles gut. Es läuft auch alles bzw. lief.
Heute stand auf einmal alles Still. Soweit ich sehen konnte war die Ursache ein vollen Laufwerk-C.
Dies war seltsam, denn Nutzerdaten, Mails und WSUS liegen auf anderen Volumes.
Mit einem Treesize konnte ich ermitteln das auf einmal extrem viele logfile in folgendem Verzeichnis zu finden waren:
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SHAREPOINT\MSSQL\Log
Die Daten in dem Verzeichnis hatten inzwischen ca. 120 GB wodurch am Ende die VM angehalten wurde.
Nach dem löschen von ca. 50 GB diese Dateien und einem Serverneustart schon nun alles erstmal wieder zu laufen aber es werden neue angelegt.
Die meinsten Dateien enden im übrigen auf .mdmp
Ich kann mir soweit keinen Reim daraus machen. Nachdem ich eine Weile diverse Sachen gelesen habe die nicht klar sind und/oder mein Wissen übersteigen fragen ich nun um eure Hilfe.
Was könnte ich tun??
Vielen Dank für euren Beitrag zu dieser Sache!!!
Ich hoffe ihr könnte mir auch bei diesem Problem helfen.
Ich musste vor kurzen einen Fremden SBS 2011 Server übernehmen.
Dieser läuft Virtuell und hat 4 virtuelle Festplatten mit folgender Aufteilung
1x Syststem
1x Daten
1x Exchange
1x WSUS
Soweit alles gut. Es läuft auch alles bzw. lief.
Heute stand auf einmal alles Still. Soweit ich sehen konnte war die Ursache ein vollen Laufwerk-C.
Dies war seltsam, denn Nutzerdaten, Mails und WSUS liegen auf anderen Volumes.
Mit einem Treesize konnte ich ermitteln das auf einmal extrem viele logfile in folgendem Verzeichnis zu finden waren:
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SHAREPOINT\MSSQL\Log
Die Daten in dem Verzeichnis hatten inzwischen ca. 120 GB wodurch am Ende die VM angehalten wurde.
Nach dem löschen von ca. 50 GB diese Dateien und einem Serverneustart schon nun alles erstmal wieder zu laufen aber es werden neue angelegt.
Die meinsten Dateien enden im übrigen auf .mdmp
Ich kann mir soweit keinen Reim daraus machen. Nachdem ich eine Weile diverse Sachen gelesen habe die nicht klar sind und/oder mein Wissen übersteigen fragen ich nun um eure Hilfe.
Was könnte ich tun??
Vielen Dank für euren Beitrag zu dieser Sache!!!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 203757
Url: https://administrator.de/forum/sharepoit-sql-log-laeuft-ueber-sbs-2011-203757.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
7 Kommentare
Neuester Kommentar
Backup/Wartung.
Lonesome Walker
Lonesome Walker
ok, danke für den Beitrag ... auch wenn ich als diesen zwei Wörten nicht ganz genau erkennen kann wo der zusammenhang besteht..^^´ ???
Hallo Zypher,
im Verzeichnis ..\Log des SQL Servers findet man normalerweise keine solchen Mengen an Daten.
Hauptsächlich Errorlogs und Tracefiles.
Sind es darüberhinaus eventuell logfiles vom Sharepoint dann muss man schauen wie das Logging dort eingestellt ist.
Daher erst mal die Frage welche Dateien sind dort vorhanden und mit welcher Größe?
Gruß
HappyHippo
im Verzeichnis ..\Log des SQL Servers findet man normalerweise keine solchen Mengen an Daten.
Hauptsächlich Errorlogs und Tracefiles.
Sind es darüberhinaus eventuell logfiles vom Sharepoint dann muss man schauen wie das Logging dort eingestellt ist.
Daher erst mal die Frage welche Dateien sind dort vorhanden und mit welcher Größe?
Gruß
HappyHippo
Hallo, vielen Dank für deine Antwort:
Im überwiegenden Teil sind es datein die in etwa auf folgendes Muster passen: SQLdmpxxx.mdmp
Reichlich davon sind meist um die 7,4 MB groß.
Sehr viele auf auch 64 kb
Dazu gibt es noch 2 über 1,2 GB große Datein deren Endung ich noch nachreichen muss, da der Server gerade in einem Abschließenden RAM Test läuft.
Dazu gleich noch eine Information die Helfen könnte.
Der Virtuelle SBS verabschiedete sich gestern Abend noch zwei weitere male und blieb stehen und das obwohl die System HDD nicht voll war.
Da mir das ganz extrem Spanisch vorkam, habe ich heute den VM Host selbst auf seine Hardwaretechnischen Herzen und Nieren geprüft.
Dabei stellte sich heraus das ein DIMM Modul defekt war. Ich habe es Ausgetauscht und bisher läuft der Test ohne Fehler durch aber ist es eben noch nicht fertig.
Ich könnte mir also vorstellen das die log Dateien durch den fehlerhaften RAM ausgelöst wurden und so ein Problem das andere auslöste....?!...
Ich gebe später noch mal Meldung.
Im überwiegenden Teil sind es datein die in etwa auf folgendes Muster passen: SQLdmpxxx.mdmp
Reichlich davon sind meist um die 7,4 MB groß.
Sehr viele auf auch 64 kb
Dazu gibt es noch 2 über 1,2 GB große Datein deren Endung ich noch nachreichen muss, da der Server gerade in einem Abschließenden RAM Test läuft.
Dazu gleich noch eine Information die Helfen könnte.
Der Virtuelle SBS verabschiedete sich gestern Abend noch zwei weitere male und blieb stehen und das obwohl die System HDD nicht voll war.
Da mir das ganz extrem Spanisch vorkam, habe ich heute den VM Host selbst auf seine Hardwaretechnischen Herzen und Nieren geprüft.
Dabei stellte sich heraus das ein DIMM Modul defekt war. Ich habe es Ausgetauscht und bisher läuft der Test ohne Fehler durch aber ist es eben noch nicht fertig.
Ich könnte mir also vorstellen das die log Dateien durch den fehlerhaften RAM ausgelöst wurden und so ein Problem das andere auslöste....?!...
Ich gebe später noch mal Meldung.
Hallo,
die mdmp Dateien sind s.g. SQL Dumpfiles und werden erzeugt wenn der SQL Server ein Problem mit dem Memory hat (Access Violation) - das würde auch den Zusammenhang mit dem defekten RAM erklären. Wenn der wieder ok ist sollten zumindestdie mdmp Dateien nicht mehr auftauchen.
Ich vermute mal der Rest sind dann die dazugehörenden Error.logs - aber da warte ich mal auf deine Info nach dem Ramtest.
VIel Erfolg!
Gruß
HappyHippo
die mdmp Dateien sind s.g. SQL Dumpfiles und werden erzeugt wenn der SQL Server ein Problem mit dem Memory hat (Access Violation) - das würde auch den Zusammenhang mit dem defekten RAM erklären. Wenn der wieder ok ist sollten zumindestdie mdmp Dateien nicht mehr auftauchen.
Ich vermute mal der Rest sind dann die dazugehörenden Error.logs - aber da warte ich mal auf deine Info nach dem Ramtest.
VIel Erfolg!
Gruß
HappyHippo
Hallo,
So ein wenig als geplant, aber hier nun mein Bericht.
Ich habe den Server gestern Abend gegen 21 Uhr wieder an Ort und Stelle gebraucht und alle VM´s gestartet. Alles lief in einer angemessen Zeit hoch und die Clients dich ich Stichprobenartig probiert hatte liefen. Exchang / OWA / ActiveSync ... alles schneit zu gehen. Das Backup wurde in der Nacht auch erledigt.
Im Vollbetrieb heute zwischen 09 und 12 Uhr haben die Mitarbeiter keine Probleme feststellen können.
Soweit scheint also alles gut. Log Files kamen keine neuen hinzu, genau wie du vermutet hattest. Ich habe jetzt gerade noch den gleichen freigen Platz wie gestern Abend
Also vielen dank für die Hilfe.
Die letzte Frage die Bleibt: sollte ich noch irgendwas zu Sicherheit prüfen bzw. irgendwelche Tests durchlaufen lassen.. gerade hinsichtlich Exchange?
Danke
mfg
Zypher
So ein wenig als geplant, aber hier nun mein Bericht.
Ich habe den Server gestern Abend gegen 21 Uhr wieder an Ort und Stelle gebraucht und alle VM´s gestartet. Alles lief in einer angemessen Zeit hoch und die Clients dich ich Stichprobenartig probiert hatte liefen. Exchang / OWA / ActiveSync ... alles schneit zu gehen. Das Backup wurde in der Nacht auch erledigt.
Im Vollbetrieb heute zwischen 09 und 12 Uhr haben die Mitarbeiter keine Probleme feststellen können.
Soweit scheint also alles gut. Log Files kamen keine neuen hinzu, genau wie du vermutet hattest. Ich habe jetzt gerade noch den gleichen freigen Platz wie gestern Abend
Also vielen dank für die Hilfe.
Die letzte Frage die Bleibt: sollte ich noch irgendwas zu Sicherheit prüfen bzw. irgendwelche Tests durchlaufen lassen.. gerade hinsichtlich Exchange?
Danke
mfg
Zypher
Hi,
ja - natürlich, wenn der Server tatsächlich so oft abgestürzt ist und das auch noch wegen RAM Problemen.
Auf jeden Fall die SQL Datenbank checken (z.B. DBCC CHECKDB)und das Gleiche auch für die Exchangedatenbanken.
Gutes Gelingen
Gruß
HappyHippo
ja - natürlich, wenn der Server tatsächlich so oft abgestürzt ist und das auch noch wegen RAM Problemen.
Auf jeden Fall die SQL Datenbank checken (z.B. DBCC CHECKDB)und das Gleiche auch für die Exchangedatenbanken.
Gutes Gelingen
Gruß
HappyHippo
