Ich habe mir schon überlegt alle laufenden Events zu stoppen. Die braucht man in der Nacht eh nicht.
Oder doch meeeehr Power:D
Ich habe mir schon überlegt alle laufenden Events zu stoppen. Die braucht man in der Nacht eh nicht.
Oder doch meeeehr Power:D
Am Ende wird es darauf hinauslaufen
Früher als die DB noch kleiner war hatte ich diese Probleme nicht. Ich muss sie irgenwie stutzten oder gleich löschen (das wäre natürlich ein schwerer Verlust). Ich hätte mich schon viel früher um die DB kümmern müssen.
Hab ein Problem…
musste IPS runterfahren, Dienst beenden ging leider nicht. RS DB Analyzer 2.3 (echt ein tolles Tool, muss ich sagen, Hut ab!!)
war mitten in der Reaggregation einer 2 Millionen DS umfassenden Variablen… bei rund 66 %
mhm, nun zeigt er im RS immer noch 66 % an, er macht aber nix mehr, sehe ich an den Meldungen…da kommt nix…
wie geh ich jetzt am besten vor, hab mich nicht getraut irgendwas zu unternehmen…
Jürgen
Juwo,
ist dass das erste Mal, dass du den Aggregations-Manager einsetzt?
Duck… klein mach…ja…
hab ihn erst frisch installiert… ein paar kleine hab ich schon aggregiert…
da ist nichts Schlimmes dran (ich freu mich über jeden Nutzer ;)), das ist nur wichtig für die Ferndiagnose.
Im Thread haben wir einige dieser Vorfälle. In allen Fällen lag es daran, dass die DB korrupt war. Ich würde dir eine DB-Wiederherstellung nahelegen: http://www.ip-symcon.de/service/dokumentation/modulreferenz/archive-control/datenbankwiederherstellung/
mhm, gibt es keine Möglichkeit die Variable aus der Queue zu werfen… das würde mir doch schon helfen…
solange die Variable aktuell nicht im ReAgg-Prozess ist, kannst du sie jederzeit aus der Queue entfernen. Steht sogar in der Tool-Hilfe
das ist ja genau das Problem, durch das Runterfahren von IPS und nicht beenden des Dienstes steht sie in der Warteschlange als in Bearbeitung, wird aber nicht bearbeitet…
Genau diesen Zustand möchte ich nun beenden, weiß aber nicht wo ich hingreifen soll…
sach das doch gleich
;)hm, den Fall hab ich noch gar nicht getestet. Versuchs mal via „Job/OFF“.
Alternativ: in der Aggragations-Manager tabelle den Haken der betroffenen Var entfernen und „Save“.
Job = OFF = 0 bringt nix
Haken lässt sich nicht enfernen, beim saven sitzt er wieder und JOB steht auf WEITER
ok, ich habs mal bei mir versucht zu simulieren:
da musst du mal die Motorhaube aufmachen und händisch in die Variable "ReAgg-Fortschritt"den Wert 100 setzen. Wenn du danach im WFE auf Save oder OFF klickst, sollte wieder alles synchron sein
Motorhaube geöffnet und Reparatur erfolgreich beendet!! DANKE !!
prima.
und immer an die DB-Reparatur denken!
Weil wir gerade über Reparatur reden… Ich kann eigentlich nicht glauben das die Zahlen für die Variable 53100 real sind (siehe Grafik)
Ist das ein Datenbankfehler oder rechnet das Programm was falsch ?
H5 BestEx,
das sieht ziemlich verkorkst aus. Mindestens die daten in den Spalten ‚#‘ und ‚U‘ sind gaga.
Versuch mal, via Variablensteckbrief diese Werte auf NULL (also auch kein Leerzeichen) zu setzen.
Die Anzahl in ‚Records‘ kann ich nicht wirklich beurteilen, ist aber verdammt hoch. Dieser Wert wird direkt aus der IPS-DB gezogen, in das Inventory-CSV geschieben und von da aus ins WFE-Dokument eingelesen. Der Wert selbst wird nicht berechnet oder irgendwie verändert. Sofern ken Fehler vorliegt.
Was sacht denn der Archive-Handler zu dieser Var und diesem Wert?
So ich habe das Ding auf NULL gesetzt, mal schauen was nach dem Update morgen zu sehen ist
du musst nicht bis morgen warten. Du kannst auch das Script „read DB“ manuell anschubsen.
Hast du die Records mal mit denen im Archivehandler verglichen?
So das Problem ist behoben.
Da ich das ganze aus der Ferne gemacht habe war es mir nicht möglich mir die Daten des Archive Handlers anzuschauen. Aber keine Sorge ich habe ein Backup von gestern und werde später mal nachschauen und mich melden
AF