Neu Datenbank Sicherung / Import per batch - muss der worker wirklich IMMER deativiert sein?

[Shop-Schmied]

Guten Morgen,

ich hab mal eine Verständnisfrage: Bisher bin ich immer davon ausgegangen (irgendwo gelesen), dass der Worker deaktiviert sein sollte, während ein DB-Backup erstellt wird. Vermutlich auch, wenn z.B. neue Artikeldaten oder Kundendaten eingespielt werden?! Es sollte natürlich auch gerade niemand an den betreffenden Datensätzen arbeiten. Aktuell werden Sicherungen gemacht, während der Worker deaktiviert ist. Da ich jetzt aber öfter sichern möchte ... würde ich das gerne bei laufendem Worker tun.

Nun ist es so, dass unser Worker ca. alle 5 Minuten arbeitet (mehr brauchen wir nicht, das Intervall könnte sogar noch größer sein). Meist hat er auch nicht viel - oder gar nichts zu tun, wenn nicht gerade im Laden kassiert wird, da der Shop einen wirklich kleinen Anteil hat.

1. Wo liegt denn das Risiko, falls ich eine DB-Sicherung bei aktiviertem Worker automatisiert laufen lasse? Ist es lediglich, dass ich vielleicht nicht mitbekomme, dass 30sek später eine Bestellung eingegangen ist? Das Risiko wäre für uns sehr überschaubar. Oder werden Daten ggf. hinterher nicht lesbar? Letzteres wäre ganz schlecht.
2. Gilt das mit dem Worker wirklich auch für den Import von Artikeldaten und Kundendaten? Ich möchte z.B. automatisiert einmal am Tag neue Kunden aus einem anderen System übernehmen. Und wir arbeiten gerade an einer externen Eingabemaske für Artikel, die dann übertragen werden. Muss dazu wirklich auch der Worker aus sein? Ich habe schonmal Artikel-Importe mit laufendem Worker gemacht... außer, dass man aufpassen muss, dass nicht zu viele workflows greifen, ist mir nichts negatives aufgefallen.

 

[SebastianB]

Also,

Ein Backup sollte im Idealfall gemacht werden wenn niemand an der Datenbank arbeitet. Und das aus zwei Gründen: Viele Händler verwenden den "Einfachen Widerherstellungsmodus". Ein Backup in diesem Modus dauert ein paar Minuten bis -je nach Größe- sehr lange. In dieser Zeit reagiert die Datenbank nicht so gut, es kann sein, dass Teile vom SQL Server gesperrt werden, es kann sein, dass das ganze System sehr träge ist. Das kann dazu führen, dass einzelne Abfragen abgebrochen werden wegen einer Zeitüberschreitung - und das wiederum kann dazu führen, dass Vorgänge, die ausgeführt werden sollten nicht sauber beendet werden. Bei der Anlage einer Bestellung kann dann z.B. eine Bestellposition fehlen. Das kommt nur in sehr seltenen Fällen vor, aber aus dem Grund geben wir die Empfehlung raus. Der Worker 2.0 in der JTL-Wawi 1.6 wird dafür einen besonderen Modus bekommen (vielleicht auch erst in der Wawi 1.7) - so dass dieser dann automatisch die DB Sicherung machen kann und dafür alle Abgleiche vorher anhält.

Bei der Ameise ist der Grund eigentlich ein ganz pragmatischer: Wenn man mit der Ameise einen Fehler macht, ist der ggf. nicht mehr zu korrigieren. Mit einer falschen Einstellung kann ich mir z.B: alle Artikel löschen oder bei allen Artikeln die Preise zerlegen. Deshalb raten wir dazu, vor dem Ameisen-Einsatz ein Backup zu machen.
Wenn jetzt der Worker läuft während die Ameise arbeitet und es kommt zu einem Problem, kann man nicht mehr das Backup einspielen, ohne dass alle DInge, die in der Zeit passiert sind, zu verlieren. Sprich: Alle Bestellungen die seit dem Backup in die Wawi kommen sind beim Einspielen vom Backup wieder futsch.
Deshalb unser Rat, wenn man mit der Ameise experimentiert: Alle Abgleiche deaktivieren, Arbeit auf allen Plätzen einstellen, Worker aus, Backup machen, Ameise machen und dann schauen ob alles gut ist und weiter damit. (Okay, Idealerweise probiert man sowas auf einem Testsystem - aber das hat leider nicht jeder)
Wenn man jetzt aber einen Ameisen-Job hat der gut funktioniert, dann braucht man vorher auch kein Backup zu machen und auch nicht den Worker zu beenden.

(Es gibt noch eine seltene Ausnahme: Die Ameise kann -je nachdem- was da gemacht wird, das System an die Auslastungsgrenze bringen. Wenn die erreicht ist kann es in anderen Prozessen zu Fehlern kommen. Und der Worker legt Bestellungen an, das ist ein Prozess in dem man eher keine Fehler möchte. Aber in dem Fall wäre die Lösung eigentlich ein stärkerer SQL-Server.)

 

[recent.digital]

Danke für diese ausführliche Erklärung @SebastianB