Datenbank Crashs

Wenn die Datenbank beschädigt ist, kann man sie üblicherweise recht leicht (siehe Bedienungsanleitung Reparieren, Komprimieren und Erweitern der Server-Datenbank) reparieren. Trotzdem muss die Ursache gefunden werden, damit nicht an irgendeiner Stelle die Datenbank mal irreparabel ist.

Hier muss unbedingt die Windows Ereignisanzeige sofort nach einem CDH Absturz in den Bereichen Anwendung und System geprüft werden. Siehe Ursache Nummer 7

Ursache 1:

Programmabbruch über Beenden über den Task-Manager
Warmstart - Programm gewaltsam abgewürgt mit Strg+Alt+Entf
Kaltstart - PC einfach abgeschaltet

Lösung: Sollte der Rechner wirklich irgendwann mal hängen und nicht weiterarbeiten, unbedingt lang genug abwarten, bevor ein Warmstart durchgeführt ist. Ist der Rechner noch im schreibenden Zugriff, ist die Datenbank garantiert beschädigt.

Ursache 2:

Virenscanner prüft die Datenbank unangebracht

Lösung a: Bei Virenscanner ETRUST (früher INOCULAN Antivirus 6 / Inoculate/T6) eingehende nur über Server schützen, ausgehende nur über Arbeitsplatz
Lösung b: Die CDH\DATA-Verzeichnisse von der Virenprüfung ausnehmen. Das wären das Client-Verzeichnis z.B. C:\CDH\DATA als auch das Server-Verzeichnis z.B. F:\CDH\DATA. Außerdem sollte man bei ETRUST auch alle *.MDB-Dateien ausnehmen
Lösung c: Bei Virenscanner AVK G-Data auf dem Server alle *.MDB-Dateien ausnehmen
Lösung d: Bei allen anderen Virenscannern entweder alle *.MDB-Dateien ausnehmen und/oder die CDH\DATA-Verzeichnisse

Ursache 3:

Netzwerk-/Servercrash

Lösung: Hardware-Partner fragen. Notfalls testweise Datenbank auf anderen wenig frequentierten PC auslagern und zuordnen (mit C:\CDH\CDHSupportCDHSetup.exe)

Ursache 4:

Linux-Server
Aus Erfahrung heraus wissen wir, dass verschiedene Linux-Server-Betriebssysteme (stark abhängig von der Einstellung) ebenfalls in unregelmäßigen Abständen die Datenbank beschädigen. Eine Reparatur ist oft schwierig bzw. unmöglich

Übergangslösung: Datenbank mit dem Spezial-Programm CDHBackupmdb.exe (Einrichtung im Task-Manager) alle 3 Stunden zusätzlich sichern.

Zeitungsbericht Computer Partner

Aufgrund eines Zeitungsberichts in der Zeitschrift „Computer Partner“ Juni 2003 sind wir informiert worden, dass es offensichtlich Probleme geben kann mit Datenbank-Crashs unter Windows

Die Schwachstelle liegt im „Opportunistic Locking“. Nach weiteren Recherchen im Internet wurde dies nur bestätigt, auch wenn die Fehlerbeseitigung unterschiedlich vorgeschlagen wird.

Auf jeden Fall empfehlen alle Experten nachstehend aufgeführte Änderungen in der Registrierung auf dem Windows-Server (alle Änderungen sollten sorgfältig dokumentiert werden, die Durchführung über einen Spezialisten ist notwendig):

1. Über Start/Ausführen das Programm Regedit starten
2. Über den links angezeigten Explorer über folgende Verzeichnisse verzweigen:
   HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/LanmanServer/Parameters
3. Der wichtige Eintrag dort ist „EnableOplocks“. Dieser muss auf den Wert 0 gesetzt werden.
4. Sollte der Eintrag nicht vorhanden sein, so muss er über Bearbeiten/Neu/ DWORD-Wert neu angelegt werden mit dem Wert 0.
5. Server neu starten.

Eine weitere Information ist, dass es spezielle neue Updates gibt zu Windows. Diese Updates haben wir uns mailen lassen, sind jedoch noch nicht offiziell im Markt. Offensichtlich muss die Geschichte mit dem „Opportunistic Locking“ schon deutlich weiterhelfen, Stufe 1 sollte auf jeden Fall hier angesetzt werden.

Ursache 5:

Netzwerkkabel oder Netzwerkkarte defekt.

Ursache 6:

Serverfestplatte fehlerhaft.

Ursache 7:

ab Windows Server 2016!
Gruppenrichtlinien. Hier wurde hinterlegt, dass die Netzwerkverbindung alle 90 Minuten ersetzt wurden, das muss auf aktualisieren geändert werden

Ursache 8:

Serverbasierters Benutzerprofil in Verbindung mit MS Azure wurde auf lokales Profil umgestellt, weil die Netzwerkverbindung permanent neu hergestellt wurde