Wie komme ich Abstürzen auf dem Server auf die Spur?

Wie komme ich Abstürzen auf dem Server auf die Spur?

Sollten Sie auf Ihrem Server wiederholt Abstürze beobachten, so müssen Sie den Ursachen zeitnah auf den Grund gehen. Jeder Absturz einer Komponente Ihres Servers kann die Funktion Ihrer Datenbank beeinträchtigen und schlimmstenfalls sogar Ihre Daten beschädigen.

Allgemeines

Ein Server ist ein komplex aufgebautes System. Es bestehen zahlreiche Schichten, die mit dem OSI-Modell beschrieben werden können: auf der Hardware (Prozessoren, Arbeitsspeicher, Busse) arbeiten low-level Protokolle, welche die verschiedenen Komponenten steuern. Auf jeder Abstraktionsebene der Maschine gibt es wieder Komponenten, welche sich auf das Funktionieren der darunter liegenden Schicht verlassen müssen. Arbeitet die Netzwerkkarte fehlerhaft, so kann vielleicht das low-level Protokoll gewisse Fehler abfangen und korrigieren und die Maschine wird "nur" langsam. Gewisse Fehler können aber nicht korrigiert werden und es kommt zu Paketverlusten. Die darauf aufbauende Schicht hat wieder ihre eigene Strategie, um mit dieser Situation umzugehen, und so versucht das System sich dynamisch in der Balance zu halten, indem jede Schicht eine gewisse, begrenzte Fehlertoleranz aufweist.

Trotzdem gibt es gelegentlich Situationen, bei welchen einzelne Schichten komplett aus dem Tritt geraten und das führt zu Fehlverhalten oder gar Abstürzen auf der Maschine. Erst in dieser Situation bemerkt der Endanwender dann, dass etwas auf dem Gerät nicht stimmt.

Vorbeugung

Die beste Strategie ist es, gar nicht auf solche Fehlersituation zu warten, sondern den Server vorbeugend zu warten. Wartung bedeutet in diesem Zusammenhang eine regelmässige Analyse der relevanten Log Files auf den verschiedenen Ebenen des Systems. So führt beispielsweise timeSensor LEGAL eigene Log Files auf der obersten Ebene, dem Application Layer, welche den Programmablauf innerhalb von timeSensor LEGAL betreffen. Unterhalb von timeSensor LEGAL liegt die 4D Datenbank, welche wiederum eigene Log Files führt, und zwar über die Gesundheit und das Funktionieren der Datenspeicherung in der Datenbank, über die Kommunikation mit den Client Applikationen oder zu Eigenschaften in der Umgebung. Darunter liegt die Schicht des Betriebssystems und auch das OS, sei das nun Windows oder macOS führt eine Menge von Log Files über verschiedenste Aktivitäten, z.B. im Filesystem, über die Speicherauslastung oder die CPU. Eine Server Wartung bedeutet, dass solche Log Files der verschiedenen Ebenen regelmässig untersucht werden, damit sich ein Bild über die "Gesundheit" des Gesamtsystems ergibt.

Fehlersuche

Sollte es trotzdem zu Abstürzen kommen, so beginnt die Phase der Fehlersuche. Häufig unterliegen Anwender*innen den falschen Eindruck, dass etwas mit ihrer Anwendung nicht stimmt, weil diese, also z.B. timeSensor LEGAL, naturgemäss die oberste Schicht des Systems darstellt. Viele Fehler sind aber in unteren Schichten angesiedelt und schlagen nach Oben durch, teilweise eben bis zur Anwendung, welche im Application Layer läuft. Hier eine Checkliste für die systematische Fehlersuche bei Abstürzen auf Ihrem Server:

1.      Journal File ausschalten
Bei der Datensicherung kann für die 4D Datenbank ein "Journal File" eingestellt werden. Dieses speichert jede Transaktion (hinzufügen, ändern, löschen von Datensätzen) in eine Datei. Das Journal File ist somit in permanentem und sehr intensiven Gebrauch. Gibt es auf der Ebene des Filesystems Probleme, so geht das Schreiben ins Journal File gerne schief, was die Datenbank zum Absturz bringen kann. Schalten Sie daher zuerst das Journal File aus und prüfen Sie, ob die Abstürze damit behoben sind. Falls ja, dann sollten Sie Ihre Festplatte überprüfen und im Zweifelsfall austauschen.
Das Journal File muss immer auf der internen Festplatte liegen. Keinesfalls sollten Sie das Journal File auf einer extern angeschlossenen Platte oder einem Netzwerkvolumen/NAS anlegen.

2.      Virenschutz ausschalten
Ein Virenschutz hat auf einem Datenbankserver nichts verloren. Da auf dem Datenbankserver niemand arbeitet, sondern der Server für den Betrieb der 4D Datenbank und timeSensor LEGAL dediziert ist, besteht auf dem Server kein Risiko für Viren. Kein Mitarbeiter arbeitet auf diesem Rechner, kein eMail Programm ist hier installiert und niemand surft auf dem Datenbankserver im Internet. Das Virenschutzprogramm verlangsamt und behindert das gute Funktionieren der Datenbank. Es gehört auf die Arbeitsplätze, aber nicht auf den Datenbank Server. Auf dem Datenbank Server darf nur ein minimales System installiert sein, so dass Interaktionen mit der Datenbank ausgeschlossen werden können.
Ein Anti-Virenprogramm hat auf einem Datenbankserver nichts zu suchen.

3.      Speicherplatz überprüfen
Prüfen Sie, ob auf allen angeschlossenen Platten mindestens 20% der Plattengrösse noch frei sind. Für grosse Datenoperationen werden Cache Dateien angelegt und dann wieder gelöscht und hierzu benötigt das System Luft. Prüfen Sie auch, ob die Datenbank genügend Arbeitsspeicher hat. Nach der Umstellung von 32 auf 64bit besteht die Gefahr, dass die Datenbank die verfügbaren Speicher gar nicht ausnutzt, weil die Datenbankeinstellungen falsch konfiguriert sind. Der Datenbank muss genügend Speicher zugewiesen werden, damit sie genug Luft hat zu arbeiten, gleichzeitig muss aber auch dem OS genügend Speicher verbleiben. Je mehr Speicherplatz der Datenbank zugewiesen wird, desto schneller und stabiler funktioniert sie, weil sie dann einen grossen Cache im Speicher anlegen kann und das Problem der Speicherfragmentierung nicht entsteht. Kann die Datenbank zu wenig Speicher nutzen, so kann der Arbeitsspeicher so stark fragmentiert werden, dass gewisse Operationen nicht mehr ausgeführt werden und ein Absturz ist dann die Folge.
Genügend RAM und Festplattenspeicher sind für den guten Betrieb der Datenbank zwingende Voraussetzung.

4.      Schreib- und Leserechte
Die Datenbank beschreibt während des Betriebs eine Vielzahl von Dateien: das oben erwähnte Journal File (welches Sie zwischenzeitlich hoffentlich ausgeschaltet haben), temporäre Dateien für Cache Operationen, lokale Einstellungsdateien, usw. Erteilt das Betriebssystem der Datenbank diese Erlaubnis nicht, so wir sie nicht zuverlässig funktionieren. Besonders gefährlich ist das Updaten eines macOS Servers von einem Betriebssystem zu einem anderen Betriebssystem (Major Update). Es wurde oft beobachtet, dass nach einem solchen Update die Zugriffsrechte auf OS Ebene nicht mehr gestimmt haben. Solange das Betriebssystem vom Hersteller noch gewartet wird, d.h. Sicherheitsupdates immer noch verfügbar sind, gibt es in der Regel keinen Grund, das Betriebssystem auf dem Server zu wechseln. Kein Anwender wird sich je dafür bedanken, denn welches Betriebssystem genau auf dem Server läuft, ist für die Anwender völlig irrelevant. Never change a running System lautet hier die Binsenweisheit. Und sollten Sie trotzdem das dringende Bedürfnis empfinden, das Betriebssystem Ihres Servers zu wechseln, dann führen Sie einen " Clean Install" durch. Das z.B. von Apple angebotene automatische Update ist zwar praktisch für einen Arbeitsplatz, für einen Server aber die falsche Vorgehensweise.
Fehlerhafte Schreib-/Leserechte auf der Ebene des Filesystems sind nicht ungewöhnlich und können die Datenbank zum Absturz bringen.

5.      Clean Install
Wenn alles nichts bringt, dann sollten Sie einen Clean Install des Servers durchführen: Daten wegsichern, Festplatte frisch formattieren und ein neues Betriebssystem aufspielen und als allerletzte Massnahme den Server austauschen.
Ein Clean Install löste fast alle Probleme, die nicht auf die physische Hardware zurückzuführen sind.

Fazit

Abstürze auf Ihrem Server dürfen nicht sein. Nehmen Sie diese ernst, beheben Sie die Ursachen und stellen Sie sicher, dass Ihr System einwandfrei läuft, um eine Beschädigung Ihrer Datenbank zu vermeiden.








    • Related Articles

    • Client verbindet sich nicht mit dem Server

      Ausgangssituation Beim Start des tSL-Clients erscheint die Fehlermeldung, dass man sich an den Administrator wenden soll. Erklärung Dies liegt daran, dass der Client sich nicht mit dem Server verbinden konnte. Lösung Die Verbindung mit dem Server ...

    • Wie kann ich die Infrastruktur auf Probleme und Engpässe testen?

      Allgemeines  timeSensor® LEGAL läuft so gut und so schnell, wie Ihre Infrastruktur es erlaubt. Das Programm befindet sich in der obersten Schicht: dem „Application Layer“. Jeder Fehler in einer tiefer liegenden Schicht wirkt sich auf die darüber ...

    • Wie teste ich die Verbindung zum Server?

      Hintergrund Damit Sie mit timeSensor LEGAL flüssig arbeiten können, benötigen Sie eine schnelle und zuverlässige Internet Verbindung. Befindet sich der Server im gleichen Netzwerk wie ihre Arbeitsstation, also im lokalen Netzwerk (LAN), so ist dies ...

    • Eignet sich Time Machine zur Datensicherung auf dem Server?

      Time Machine ist eine Datensicherungssoftware von Apple, welche seit Mac OX X 10.5 in das Betriebssystem integriert ist. Vom Einsatz von Time Machine auf der Server Maschine raten wir aus folgenden Gründen ab: In Time Machine lässt sich kein ...

    • Wie erteile dem Support einen Serverzugang?

      Allgemeines Gelegentlich ist es notwendig, den Mitarbeiter*innen unseres Support-Teams den Zugang zum Datenserver zu ermöglichen. Wenn Sie timeSensor LEGAL auf einem eigenen Server verwenden, und die timeSensor AG mit Ihrer Kanzlei keinen Server ...