SQL Server 2000 lahmt immer mal wieder
Hallo zusammen,
ich habe ein sehr sehr seltsames Problem.
Seit letzten Sonntag hängt sich bei unserem kunden immer wieder der sql-server auf. und zwar so, dass aktionen die ansonsten in millisekunden abgearbeitet werden, auf einmal mehr als 45 sekunden dauern und dann in einen timeout rennen.
das irre daran ist aber, dass dies dann passiert, wenn längere Zeit NIEMAND mit der Datenbank arbeitet. Läuft der Server unter Vollast ist dieser Fehler bisher nie aufgetreten.
Das einzige was hilft ist, den SQL Server zu beenden und neu zu starten. Es sind auch keine Deadlocks o.ä., da habe ich schon nachgeschaut.
Ich bin echt mit meinem Latein am Ende und hätte als letzte Möglichkeit eigentlich nur noch die Neuinstallation des Rechners bzw. des SQL Servers vorzuschlagen.
Vielleicht kann mich jemand aus dem Tal der Tränen erlösen.
Schöne Grüsse
Timo
Hallo timokeller,
in all den Jahren indem ich mit MSSQL arbeite, kam es bisher nur einmal vor das der SQL Server nicht mehr reagierte. Dabei war das Problem im Active Directory und das OS sperrte daraufhin das Netzwerk ab. Ich konnte dann nur noch den kompletten Server neu booten.
Also paar Punkte die mir auf die schnelle einfallen:
Was sagt die Ereignisanzeige?
Was für eine Edition von SQL Server (+welches SP) und vom OS nutzt du?
Welche Lizenzierung nutzt du vom SQL Server und vom OS?
Wieviele Connections hat der SQL Server offen?
Was sagt die Systemauslastung wenn der SQL Server nichts mehr macht?
Hast du die Möglichkeit den Profiler einzusetzen und wenn ja, was ist das letzte Statement bevor nichts mehr geht?
Mit was für einer Art von Applikation gehst du auf die DB?
Nächtliche Grüße,
Tom
Hallo Tom,
vielen Dank erstmal für deine Tipps. Also ich bin jetzt gerade beim Kunden (Krankenhauslabor!!!), werde jetzt mal das aktuelle Servicepack draufspielen, vielleicht hängt es damit zusammen.
Schöne Grüsse
Timo
Vertraue der Macht, Luke.
Zumindest der Macht des Schames, wenn User erkennen wie dumm ihr Fehler war und sie nach dem Bug report schnell alles klar schiff machen. Ist dann natürlich schwer selbst vor Ort das Problem zu reproduzieren. 😉
Ich halte Dinge wie ein Defrag tool, das im Idle mode startet, nicht für ausgeschlossen.
Habe schon ... 🤔 kreativere Dinge erlebt. 😁
Ich hatte das mal bei einem SQL Server, der einige Volltextkatalog hatte. Diese Kataloge werden normalerweise per SQL Agent-Job aktualisiert. Der betroffene Server hatte dies mehrmal täglich während den Arbeitszeiten getan. Ich hatte das elbe Ergebnis. Lahme Antwortzeiten und Timeouts. Die Lösung bestand darin, das auffwüllen der Volltextkatalog auf nachts und die Mittagspause zu verlegen.
Natürlich könnten es auch andere Jobs ein (Schau Dir mal in den SQL Agent an), die zeitgesteuert ausgeführt werden.
Ein anderes Problem könnte eine Anwendung sein, die tausende Verbindungen öffnet und diese nicht mehr schließt (Programmierfehler). Also vorsichtshalber die offenen Verbindungen auf dem Server überwachen.
Es könnte auch sein, dass eine Anwendung auf dem Server zu viele Speicherhandler hält und diese nicht freigibt. Hatte einen solchen Bug mal in einer Delphi-Anwendung. Die Anzahl der Handles pro Prozeß kannst Du Dir im Task-Manager einblenden. Wenn der Wert bei einem Prozeß über 20.000 ist, stimmt wahrscheinlich was nicht.
So sind auch meine Erfahrungen.
Meist agiert ein Job oder eine Anwendung von ausserhalb so, dass es den gesamten Server runterzieht. (Zuviel Performance, zuviele Verbindungen, etc.)
Könnte z.B. auch ein Idle Problem von der Anwendung sein.
Wie z.B. unter IIS6 gibts ja der idleTimeout sein und die Applikation kommt mit dem 'recycle process' nicht klar.
Aber mal sehen was der Threadersteller dazu sagt 🙂
Gruß,
Tom
Also, was sagt der Threadstarter dazu? 🙂
Erst mal bedanke ich mich bei allen, die sich bei diesem Thema engagiert haben.
Ich war jetzt gestern und heute beim Kunden und hab folgendes versucht:
1.) Neuestes Servicepack eingespielt. (hat nix gebracht)
2.) Datenbank gesichert, SQL Server neu installiert, Datenbank wieder eingespielt (heute)
3.) Transaktionslog gesichert und verkleinert (war vorher 4,5 GB gross).
Bisher keine Probleme, mal schauen, wie es morgen früh ist.
Das Problem an der Geschichte ist, dass sich sowohl im Profiler wie in der Ereignisanzeige eigentlich kein Fehler erkennen lässt.
Und zum Thema User / Hintergrunddienste / Programmierung:
Die Anwendung läuft seit Anfang 2006 ohne diese Fehler. Seit letzten Sonntag tauchen diese auf, es sind keine neuen Dienste o.ä. programmiert oder dazugekommen.
Aus diesem Grund kann ich eine fehlerhafte Programmierung eigentlich ausschliessen.
Ich bin morgen früh wieder beim Kunden (schreibe dies gerade vom Hotel aus), dann werde ich wieder berichten (hoffentlich die Lösung!!!)
Nochmal dank an alle.
Gruss Timo
So, da bin ich nochmal. Ich hab jetzt den SQL Server deinstalliert und dann neu installiert, danach noch das Transaktionslog verkleinert und jetzt scheint es zu funktionieren.
Keine Ahnung,was das war.
Greetz
Timo
Möglicherweise liegt es am Protokollierungs-Modus des Transaktionsprotokolls. Wenn der auf Vollständig eingestellt ist, kann das Protokoll schnell mega groß werden. Wenn nach ein paar Wochen wieder alles Langsam ist, solltest Du den Modus auf "Einfach" umstellen.
Hallo,
Ich würde den Wiederherstellungsmodus schon auf Vollständig lassen, bzw drauf stellen.
Aber das TLog sollte auch mal gesichert werden.
Dann wächst die Tlog Datei nicht so schnell an. Da beim sichern der TLog der gesicherte Bereich wieder freigegeben wird.
Die Datei sieht dass zwar im Dateisystem riesig aus, ist aber fast nicht gefüllt.
Das Kann man sich auch anzeigen lassen über den Enterprise Manager.
SQL-Statment zum Sicher der TLog Datei
Backup Log <Datenbank> To Disk = N'<Pfad>.trn'
go
@Performance Problem:
- Was sagt das ErrorLog des SQL Server?
- Wie ist die Fragmentierung des Dateisystems, wo die Datendatei / Logdatei liegt?
-> Wichtig die Logdatei, da die zuerst geschrieben wird. (Unabhängig vom Recover Modus) - Wie ist die Fragmentierung der Indexe? (Ich gehe mal davon aus das es Indexe gibt)
- Wieviel User (Connection sind normaler weise offen) nutzen den SQL Server, und wieviel RAM hat dieser?
- Darf der SQL Server den Speicher selber verwalten?
- Wie schnell ist der Netzwerkanschluss?
- Wie wird der Server aufgelöst? (DNS oder IP Adresse)
Das Tlog verkleinern bringt relativ wenig, da der SQL Server mal den Platz gebraucht hat, und dann kann er immer wieder den Platz brauchen. Ich habe die erfahrung gemacht das das OS nicht schnell genug Plattenplatz zur Verfügung stellen kann, darum versuche ich das TLog immer in einer anständigen Größe zu lassen, in Abhängigkeit zur Datendatei. (OK 4,5 GB ist schon groß.)