JTL-Wawi Datenbank defekt, was tun?

Aug 4, 2017 | E-Commerce, Tutorial | 0 Kommentare

Hin und wieder gibt es Probleme mit der Datenbank bei dem einen oder anderen Kunden. Es kommt sehr selten vor, doch was tun, wenn der Ernstfall eintritt und die Wawi keine Verbindung zur Datenbank herstellen kann?

Neulich erreichte uns der Hilferuf eines Kunden. Nach einem Stromausfall, während eines Windows Update startete seine JTL-Wawi nicht mehr, alle Amazon, eBay und Shop-Bestellungen können nicht ausgeliefert werden und obendrein funktionierte das POS Kassensystem im Ladengeschäft nicht. Das war der Super-Gau.

Fehlende Datensicherung keine Seltenheit

An dieser Stelle merkt man eigentlich erst, wie wichtig eine tägliche Datensicherung der SQL-Datenbank ist. Allerdings machen sich die wenigsten Nutzer darüber Gedanken. Das wundert uns immer wieder aufs Neue. Hängt doch das gesamte Geschäft des Nutzers an diesem Datenbestand und damit auch seine Existenz. Sind die Daten erst einmal unwiederbringlich verloren, ist es kaum noch möglich hier irgend etwas zu retten.

In diesem Fall war es so gelagert, das die Datenbank als solche zwar noch in dem Ordner des SQL-Servers vorhanden war, aber die Wawi nur noch die Meldung zurückgegeben hat, das der Zugriff nicht möglich sein, da die Datenbank als Fehlerhaft (Suspect) gekennzeichnet sei.

Kurios war außerdem, dass auch ein Zugriff über das Microsoft SQL Management Studio nicht möglich war. Hier war also mehr im Argen.

Lösungsansatz zur Rettung der JTL-SQL Datenbank

Unser erster Lösungsansatz war erst einmal wieder in irgendeiner Weise in das Managementstudio zu kommen, denn auch hier wurden wir beim Login mit einer Fehlermeldung abgewiesen. Es schien also, dass es auch den Server erwischt hatte, obwohl der SQL-Server Dienst lief und sich auch wie gewohnt neu starten ließ.

Im ersten Schritt haben wir also mit dem SQL-Server Installationstool eine Wartung durchgeführt und darüber die Reparatur des SQL Servers angestoßen. Das hat auch eine Weile gedauert. Wichtig ist hierbei die Original Installations-Dateien zu verwenden, die man bei der Erstinstallation benutzt hat.

Nach der Reparatur Installation konnten wir uns erst einmal Zugang zum SQL Server über die SQL Management Console verschaffen. Leider wurden außer den SQL Systemdatenbanken keine weiteren Datenbanken angezeigt. Weder die eazybusiness noch irgend ein Mandant.

Also haben wir jetzt versucht die Datenbank eazybusiness wieder in der SQL-Server Instanz JTLWAWI einzuhängen, denn die Datenbank Dateien eazybusiness und eazybusiness.log waren ja nach wie vor noch im Daten-Ordner des SQL-Server vorhanden. Leider funktionierte auch das nicht. Sie ließen sich nicht anhängen.

Nach dem Starten des SQL Server Agent und einer Aktualisierung im Management-Studio tauchte die DB eazybusiness und auch die Mandant_2 wieder im Mangement-Studio auf. Allerdings waren die Wawi Datenbanken beide als Fehlerbehaftet gekennzeichnet und der Server gewährte uns keinen Zugang.

Fehlerhafte Datenbank reparieren

Nun ging es ans Eingemachte. Als Erstes haben wir die Datendateien der beiden JTL-Datenbanken zu Sicherheit in einen anderen Ordner kopiert. Sicher ist sicher. Anschließend haben wir die eazybusiness Datenbank, welche immer noch als „Suspect“ gekennzeichent war über ein SQL Statement in den Emergency Modus versetzt.

EXEC sp_resetstatus 'eazybusiness';
ALTER DATABASE eazybusiness SET EMERGENCY;

Anschließend konnten wir die Datenbank auf beschädigte Objekte überprüfen. Das ging auch recht schnell.

DBCC checkdb('eazybusiness');

Als nächstes musste die Datenbank in den Single-User Mode versetzt werden. Auch das klappte problemlos.

ALTER DATABASE eazybusiness SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

Jetzt konnten wir endlich einen Reparaturversuch ohne Datenverlust der JTL-Datenbank anstarten. Es dauerte doch eine ganze Weile, bis der SQL Server damit fertig war. Immerhin war die JTL-Wawi Datenbank schon beachtliche 5,6 GB groß. Auch hier bekamen wir wieder eine Fehlermeldung.

DBCC CheckDB ('eazybusiness', REPAIR);
DBCC CheckDB ('eazybusiness', REPAIR_REBUILD);

Also starteten wir erneut einen Reparaturversuch, dieses mal allerdings mit Datenverlust. Es konnte sich ja nur um einige Zuordnungen handeln, die man vielleicht auch manuell korrigiert bekommt.

DBCC CheckDB ('eazybusiness', REPAIR_ALLOW_DATA_LOSS);

Dieser Vorgang dauerte auch wieder eine ganze Weile und wurde mit einer Meldung beendet, das alles geklappt hat und einige Zuordnungseinheiten nicht korrekt wieder hergestellt werden konnten.

Als Letztes mussten wir nur noch die Datenbank mit nachfolgendem Befehl wieder online schalten.

ALTER DATABASE eazybusiness SET MULTI_USER;

Die Meldung „Suspect“ mit dem Datenbanknamen „eazybusiness“ war verschwunden. Ein erneuter Versuch sich an der JTL-Wawi anzumelden funktonierte wieder. Als letztes haben wir noch die Reparaturfunktionen auch dem JTL-Datenbankmanager durchlaufen lassen und der Kunde konnte wieder mit seiner JTL-Wawi arbeiten.

Bislang sind keine nennenswerten Probleme mit den fehlerhaften Zuordnungseinheiten aufgetreten. Da hat er nochmal richtig Glück gehabt.

Fazit

Ich hoffe mit diesem Workaround konnte ich dem Einen oder Anderen helfen die JTL-Wawi wieder ans Laufen zu bekommen. Man sieht an dieser Stelle, wie wichtig doch ein eigenständiger Server und eine richtige Datensicherung ist.

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert