1.6 Offizieles Release direkt Updaten?

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
1.676
533
So mal neues zum Update,
habe Antwort vom JTL Support auf das Ticket bekommen.

Was soll ich sagen,... hm davon ist naturgemäß auszugehen wenn man die Anwendung mit dem Taskmanager nach Gut 5 Stunden beendet!
Nur mal so nebenbei,... eine bei JTL gehostete Datenbank!

Für alle die ein ähnliches vermeintliches Problem haben, es scheint so zu sein, das dass Update nicht nur mehrere Stunden sondern am Ende mehrere Tage dauern kann, je nach Anzahl der vorhandenen Rechnungen.
Als Grundregel kann man folgende Zeit einplanen.
bei 300.000 Rechnungen ca. 24 Stunden
bei 600.000 Rechnungen ca. 48 Stunden
bei 900.000 bis 1.200.000 Rechnungen ca 60 bis 70 Stunden

Mal was an JTL und das ist nicht böse gemeint sondern mal so als Anregung.
Wenn man ein Major Update auf den Markt bringt, insbesondere dann wenn so einschneidende Änderungen vorgenommen werden,
sollte man den Kunden zumindest eine Vorwarnung geben mit welcher Zeitspanne zu rechnen ist.
Sowas muss kommuniziert werden.
Sowas geht überhaupt nicht, die Kunden so im Dunkeln stehen zu lassen, insbesondere dann wenn
wie im folgenden Thread beschrieben nach 60 Stunden immer noch das gleiche steht wie Updatevortschritt 2 %

https://forum.jtl-software.de/threa...scheinpos-und-stockt-dann.183142/#post-979810

Sorry aber so geht man nicht mit zahlenden Kunden um!
Gerade dann wenn JTL selbst immer schreibt, Kommunikation ist alles !
Hab den Thread nur durch Zufall gefunden, sorry aber das geht garnicht.
Werde das Update entspechend Freitagmorgen nach rechnungsstellung erneut ausführen und es demnach
über Pfingsten laufen lassen.

Somit erstmal Danke an JTL, in diesem Fall also für nichts !
mfG.
Sorry, aber da muss ich JTL in Schutz nehmen, ein Stück weit liegt das Problem leider bei Dir.

Hier im Thread ist eigentlich alles beschrieben was Du brauchst und auch JTL stellt sehr umfangreiche Informationen zum Update und den Änderungen bereit. An der einen oder anderen Stelle gibt es da sicherlich auch Optimierungsbedarf, aber aus Deinem Beitrag kann ich herauslesen, dass Du weder den hier im Thread benannten Links gefolgt bist, noch sonderlich viel vor dem großen Update recherchiert hast.

Soetwas sollte man vor dem Update auf jeden Fall lesen:
https://guide.jtl-software.de/jtl-wawi/installation/checkliste-fuer-den-umstieg-auf-jtl-wawi-1-6/

Dann sieht man nämlich auch:
Planen Sie genügend Zeit ein!
Idealerweise planen Sie das Update an einem Wochenende oder nach Feierabend durchzuführen. Erfahrungsgemäß kommen viele kleinere und größere Änderungen auf Sie zu, mit denen Sie nicht unbedingt rechnen und die Ihren Tagesablauf blockieren könnten. Auch der Einsatz eines Testsystems wäre in jedem Fall vorteilhaft!


Update-Dauer verkürzen: Um die Dauer des Updates zu verkürzen, empfehlen wir Ihnen, das Update direkt auf Ihrem Server durchzuführen, da andernfalls erst einmal alle Daten, wie Bilder oder SQL-Befehle auf Ihren Client geladen werden müssen, was sehr viel Zeit in Anspruch nehmen kann.

JTL-Hosting:


Wenn Sie die SQL-Datenbank für Ihre JTL-Wawi von JTL hosten lassen, bitten wir Sie das Update während der Supportzeiten von JTL zu machen. Hintergrund: Sie selbst können keinen manuellen Restore durchführen, d.h. ein evtl. notwendiges Backup kann nur durch JTL wieder eingespielt werden.

Daher würde ich mal darauf tippen, dass bei Dir das Hauptproblem die Internetleitung und damit die Anbindung ans DB-Hosting ist.
Ansonsten müsstest Du ggf. abwarten, bis JTL die Update-Funktionalität soweit optimiert hat, dass sie auch bei vielen Rechnungen bzw. bestimmten Konstellationen mit voller Geschwindigkeit läuft.

Zur Lösung solltest Du Dich vielleicht noch einmal direkt an den JTL-Support wenden und vielleicht gibt es da ja eine Möglichkeit, das Update direkt auf dem Server auszuführen, um den Flaschenhals zwischen Deinem Client und dem Server zu entschärfen. Alternativ liegt Deine DB ja schon bei JTL auf dem Server, so dass der Support anhand Deiner DB ja vielleicht testen kann, was der Flaschenhals im Update-Prozess ist und diese für entsprechende Optimierungen heranziehen kann.
 
Zuletzt bearbeitet:

forumjtlolshopag

Sehr aktives Mitglied
6. Juni 2018
540
139
Sorry, aber da muss ich JTL in Schutz nehmen, ein Stück weit liegt das Problem leider bei Dir.
Naja, man hätte in der Zwischenzeit eine "Zwischen"version rausbringen können, damit der Wechsel von 1.5 zu 1.6 nicht zu viele Fallstricke hat. 1.6 war ja gefühlt ewig in der Entwicklung. Je nach Datenbankumfang dauern natürlich mehrere größere Umstellung insgesamt länger. JTL sollte daher kürzere Releasezyklen ansätzen, damit das nicht immer so ein "riesiger" Brummer wird bei solchen Updates.
 

hula1499

Sehr aktives Mitglied
22. Juni 2011
4.781
926
Sorry, aber da muss ich JTL in Schutz nehmen, ein Stück weit liegt das Problem leider bei Dir.
Äh....sorry, aber hier gibts nix in Schutz zu nehmen.

bei 300.000 Rechnungen ca. 24 Stunden
bei 600.000 Rechnungen ca. 48 Stunden
bei 900.000 bis 1.200.000 Rechnungen ca 60 bis 70 Stunden
Wenn das eine JTL Ticketaussage sein soll, gehört das natürlich auch in die Guide als Info rein.

bei 900.000 bis 1.200.000 Rechnungen ca 60 bis 70 Stunden

Und in der Zwischenzeit?
Alle Artikel auf allen Plattformen abdrehen, damit keine Überverkäufe stattfinden?

60-70 Std. sind - im worst case - knapp 3 Tage, dh. man "dürfte" das Update nur an einem WE mit angeschlossenem Feiertag machen.
Zusätzlich eine Vielzahl an Anmerkungen, das Update läuft gar nicht durch wegen irgendwelcher Fehler in der DB Struktur....dann muss man auf das nächste WE mit Feiertag warten? :D

Die Kommunikation ist - wie üblich - halt wiedermal nicht vorhanden. Zeitliche Größenordnung, wenn wir hier schon von möglichen TAGEN an Updates sprechen, müssen dem Kunden - offiziell - kommuniziert werden.
 
  • Gefällt mir
Reaktionen: enbikey

Arne Janson

Offizieller Servicepartner
SPBanner
17. Juni 2019
314
69
Naja, man hätte in der Zwischenzeit eine "Zwischen"version rausbringen können, damit der Wechsel von 1.5 zu 1.6 nicht zu viele Fallstricke hat. 1.6 war ja gefühlt ewig in der Entwicklung. Je nach Datenbankumfang dauern natürlich mehrere größere Umstellung insgesamt länger. JTL sollte daher kürzere Releasezyklen ansätzen, damit das nicht immer so ein "riesiger" Brummer wird bei solchen Updates.
JTL hatte vor Jahren auch schon gesagt das die 1.6 "bald" kommt :) es gibt sicherlich Gründe, warum JTL es so geplant hat. Nicht umsonst ist die erste offizielle 1.6 eine 1.6.38.1, weil JTL hier noch vieles anpassen musste. Die 1.7 hat hier nicht so viele große Veränderungen und die Beta-Phase könnte wohl 2022 los gehen. An der 1.7.0 wird schon gearbeitet: https://issues.jtl-software.de/issues?project=wawi&version=1.7.0.0
 

Arne Janson

Offizieller Servicepartner
SPBanner
17. Juni 2019
314
69
Äh....sorry, aber hier gibts nix in Schutz zu nehmen.


Wenn das eine JTL Ticketaussage sein soll, gehört das natürlich auch in die Guide als Info rein.



Und in der Zwischenzeit?
Alle Artikel auf allen Plattformen abdrehen, damit keine Überverkäufe stattfinden?

60-70 Std. sind - im worst case - knapp 3 Tage, dh. man "dürfte" das Update nur an einem WE mit angeschlossenem Feiertag machen.
Zusätzlich eine Vielzahl an Anmerkungen, das Update läuft gar nicht durch wegen irgendwelcher Fehler in der DB Struktur....dann muss man auf das nächste WE mit Feiertag warten? :D

Die Kommunikation ist - wie üblich - halt wiedermal nicht vorhanden. Zeitliche Größenordnung, wenn wir hier schon von möglichen TAGEN an Updates sprechen, müssen dem Kunden - offiziell - kommuniziert werden.
Ich glaube, pauschal kann man das nicht sagen.
Hier kommen viele Faktoren zusammen .
Bei einigen Kunden ist das Update in ein paar Stunden durchgelaufen.
Kunden wo z.B. 928.993 und 1.424.063 Aufträge => ähnliche Anzahl Rechnung sind, lief es auf unseren "einfachen" Testsystem über Nacht durch. Und morgens konnten wir dann Workflows etc. testen. Also definitiv nicht mehrere Tage, sondern Stunden. Aber es kommt auf viele Faktoren an.
 
  • Gefällt mir
Reaktionen: RECENTmarketing

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
1.676
533
Wenn das eine JTL Ticketaussage sein soll, gehört das natürlich auch in die Guide als Info rein.
Genau das kann ich mir aber nicht vorstellen, dass das schon das "Optimum" an Updatezeit ist und es gibt auch keinen konkreten Kontext dazu, ob das eine allgemeine Faustformel ist oder im speziellen für gehostete Datenbanken per Update über den Client bei Verbindung XY ist.

Ich kann diese Zeiten auf jeden Fall für mich nicht bestätigen.

Deshalb ja der Tipp, dass nochmal mit dem JTL-Support abzustimmen und ggf. die DB untersuchen zu lassen. Vielleicht kann JTL dann in einer der nächsten Updates einen Fix einbauen oder etwas an der Logik verändern, so dass sich das Ganze beschleunigen lässt.

Was auch immer da passiert, aber das Update von 10000 bis 12000 Rechnungen pro Stunde kann ich mir auf einem halbwegs performanten System (Server) nicht als Richtwert vorstellen.

Naja, man hätte in der Zwischenzeit eine "Zwischen"version rausbringen können, damit der Wechsel von 1.5 zu 1.6 nicht zu viele Fallstricke hat. 1.6 war ja gefühlt ewig in der Entwicklung. Je nach Datenbankumfang dauern natürlich mehrere größere Umstellung insgesamt länger. JTL sollte daher kürzere Releasezyklen ansätzen, damit das nicht immer so ein "riesiger" Brummer wird bei solchen Updates.

In diesem Fall ist aber scheinbar eher zu früh, als zu spät released worden, da der Guide noch nicht auf die 1.6 aktualisiert ist, etc. pp.

Grundsätzlich gebe ich Dir aber Recht, es wäre schöner, wenn Bereich für Bereich und Ablauf für Ablauf neu strukturiert würde. Aber ich hoffe, dass das ab dem nächsten Update (1.7) auch so läuft und jetzt die Ausnahme war.

Während der Pilotphase gab es so viele Veränderungen in einzelnen Abläufen, dass hätte man im Feldeinsatz so gar nicht machen können. Es gibt sicherlich Optimierungsmöglichkeiten, aber im Großen und Ganzen ist die 1.6 schon gelungen. Wenn man dann noch den Guide, die Youtube-Videos, etc. zu Rate zieht, sollte der Umstieg / die Umgewöhnung eigentlich recht gut klappen.

Auch hier gibt es ja nochmal wieder das aktuelle Video von heute:
 

Seulberg

Sehr aktives Mitglied
14. Januar 2012
627
30
Hätte ich nach dem Update auf 1.6.38.1 nichts mehr gemacht, wäre es vielleicht nicht so richtig aufgefallen, es war klar, dass die DB um ca. 30-40% wächst,
aber das zweite Update auf die 1.6.38.2 hat noch mal 3 GB reingeschrieben und hier ist wahrscheinlich irgendwo der Fehler versteckt.
Hallo,

Gestern noch mal TV + Update auf 1.6.39.0
Nach den Update auf die 1.6.39.0 ist die DB wieder "normal" groß also bei mir ca. 6 GB.

Gruß
Johann
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Arne Janson

MichaelH

Sehr aktives Mitglied
17. November 2008
13.206
1.243
Das ist unklar vorfumliert, es wird ja eine Version nach der anderen durchgeführt beim Update.
Wenn es z.B. im Verlauf bei der 1.6.38 crasht weil die DB überläuft, nützt die Korrektur die danach bei 1.6.39 kommt nichts.
 

Seulberg

Sehr aktives Mitglied
14. Januar 2012
627
30
Das ist unklar vorfumliert, es wird ja eine Version nach der anderen durchgeführt beim Update.
Wenn es z.B. im Verlauf bei der 1.6.38 crasht weil die DB überläuft, nützt die Korrektur die danach bei 1.6.39 kommt nichts.
Ja, da könntest Du Recht haben, habe angenommen, dass eben nach meiner Problemschilderung hier etwas verändert wird damit das nicht mehr passiert.
genauer sollte das eher ein Fachnamm von JTL besser beantworten können.

Gruß
Johann
 

Shoppert

Aktives Mitglied
19. Dezember 2012
27
10
D.h. wer direkt auf 1.6.39.0 updated hat das Problem nicht ?

Wir führen gerade das Update von 1.5.46.3 auf 1.6.40.0 durch und haben es Freitag Nachmittag kurz nach Feierabend gestartet. Unsere SQL Datenbank wird bei JTL gehostet und hat ca. 700.000 Aufträge/Rechnungen. Seit ca. 27 Stunden hängt unser Datenbank-Update im Zwischenschritt auf 1.6.0.0 auch mit 21% Fortschritt an folgender der Stelle
IF(OBJECT_ID('tempdb..#RechnungKey') IS NOT NULL)
BEGIN
DROP TABLE #RechnungKey;
END
[...]

Es scheint erst einmal keine Verbesserung stattgefunden zu haben.
 

pixxass

Sehr aktives Mitglied
8. Februar 2017
160
40
Chemnitz
Guten Abend,

ich häng mich hier kurz mal mit rein:

Im Juni hatten wir bereits einen Versuch des Updates in der Testumgebung gestartet (von 1.5.55.2 zu 1.6.38.1 / Rechnungen sind ca. 200.000 vorhanden) und der gesamte Vorgang hat ca. 2 Stunden in Anspruch genommen.
Es gab keine Probleme.
Nach längerer Vorbereitung wollten wir heute das Update in der Produktivumgebung durchführen, hängen aber nun auch an der besagten Rechnungsstelle (1%) fest:

IF(OBJECT_ID('tempdb..#RechnungKey') IS NOT NULL)
BEGIN
DROP TABLE #RechnungKey;
END
[...]

Den ersten Versuch haben wir nach 1 1/2 Stunden abgebrochen, da in der Testumgebung zu diesem Zeitpunkt der Vorgang deutlich fortgeschrittener war. Da wir vermuteten, dass es ggf. an der Version liegt (zumindest nach den vielen Forenbeiträgen), veruschten wir danach die 1.6.40.0.
Jetzt sind wir aktuell bei fast drei Stunden und der Fortschritt steht beim bekannten Rechnungspunkt. Wir lassenes jetzt noch 30 Minuten laufen, vermuten aber andere Probleme (automatische BackUp Programme und Drittsoftware wurden deaktivert - aber wer weiß...). Die Testumgebung läuft auf Win10, der Server auf WinServer2019. Die Testumgebung hat keine aktive Shop- oder Connectoranbindungen.

Ist in der Zwischenzeit zu dem Problem noch etwas hilfreiches bekannt geworden bzw. können die Zeiten aufgrund Shopanbindung und Connectoren sich stärker zwischen Testumgebung und Livebetrieb unterscheiden?
Oder müssen wir auch ein Wochenende einplanen sowie eine Ticket öffnen?

Morgen werden es nochmal in der Testumgebung versuchen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: RECENTmarketing

Frederik von Bot

Sehr aktives Mitglied
8. September 2012
122
31
Hallo,

nachdem einige Updates au 1.6 fehlgeschlagen sind, Sql Standartlizenz umgestellt, Update am Nachmittag gestartet um Puffer zu haben, nun hängt das Update bei 1%, bin nicht sehr optimistisch das sich über Nacht was ändern wird.

Simple Frage, wie beende ich von selbst ein Update, um ein Backup einzuspielen, über den Taskmanager?

Danke im voraus
 

pixxass

Sehr aktives Mitglied
8. Februar 2017
160
40
Chemnitz
Taskmanager öffnen und bei Details die Wawi beenden.


1.jpg


Wir hängen jetzt seit 16:45 Uhr am zweiten Versuch und sind bei 26% (1.6.11.3) wo erneut die viele Rechnungsbezogene SQL´s laufen (laut Übersicht wieder:
IF(OBJECT_ID('tempdb..#RechnungKey') IS NOT NULL)
BEGIN
DROP TABLE #RechnungKey;
END
[...].
Seltsamerweise war das Test-Update wieder in 2 Studnen und 38 Minuten durch... komisch.
Laut SQL Aktivitätenmonitor ist aber alles am Laufen.
 

Anhänge

  • 1.jpg
    1.jpg
    10,9 KB · Aufrufe: 6
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Frederik von Bot

Frederik von Bot

Sehr aktives Mitglied
8. September 2012
122
31
Taskmanager öffnen und bei Details die Wawi beenden.


Den Anhang 86344 betrachten


Wir hängen jetzt seit 16:45 Uhr am zweiten Versuch und sind bei 26% (1.6.11.3) wo erneut die viele Rechnungsbezogene SQL´s laufen (laut Übersicht wieder:
IF(OBJECT_ID('tempdb..#RechnungKey') IS NOT NULL)
BEGIN
DROP TABLE #RechnungKey;
END
[...].
Seltsamerweise war das Test-Update wieder in 2 Studnen und 38 Minuten durch... komisch.
Laut SQL Aktivitätenmonitor ist aber alles am Laufen.
unser update hängt mittlerweile auch genau an der selben Stelle 26%, 1.6.11.3. Zwischen 1-26% lief es recht zügig.
 

pixxass

Sehr aktives Mitglied
8. Februar 2017
160
40
Chemnitz
unser update hängt mittlerweile auch genau an der selben Stelle 26%, 1.6.11.3. Zwischen 1-26% lief es recht zügig.
Das ist normal. An der Stelle werden wie gesagt nochmal einige Einträge getätigt. Sobald das rum ist, geht es flott bis zum Ende!
Bei uns hat es nun am Ende 7:15h gedauert in einer WinServer2019 Umgebung und in der Win10 Testumgebung nur 2:38h.

Jetz sind wir aber durch und ziemlich müde (fast 24h Tag...)^^
 

Frederik von Bot

Sehr aktives Mitglied
8. September 2012
122
31
Taskmanager öffnen und bei Details die Wawi beenden.


Den Anhang 86344 betrachten


Wir hängen jetzt seit 16:45 Uhr am zweiten Versuch und sind bei 26% (1.6.11.3) wo erneut die viele Rechnungsbezogene SQL´s laufen (laut Übersicht wieder:
IF(OBJECT_ID('tempdb..#RechnungKey') IS NOT NULL)
BEGIN
DROP TABLE #RechnungKey;
END
[...].
Seltsamerweise war das Test-Update wieder in 2 Studnen und 38 Minuten durch... komisch.
Laut SQL Aktivitätenmonitor ist aber alles am LaufenUnser
bei uns ist das Update auch durch, hat ca 15H gedauert.
 
  • Gefällt mir
Reaktionen: pixxass