LD 8.5.2 EN Update Tasks bringt Domino zum Absturz

[SlyFox]

Hallo,

EINE Mail-DB (8.5er Design DE, LN 8.5.2 DE) bringt den Domino zum Absturz, wenn in dieser Update Tasks ausgeführt wird.

Kann mir jemand sagen, woran das liegen könnte bzw. wo ich etwas überprüfen soll?

Christoph

[WildVirus]

N'abend,

was hast Du denn schon unternommen ? Wie siehts im Log / auf der Console aus ?

CU,
Axel

[SlyFox]

Hallo,

mit den Logs kenne ich mich leider nicht aus. :-(

Wo finde ich die und wonach soll ich suchen? Nach dem letzten Eintrag?

Auf der Konsole wird natürlich nichts mehr angezeigt, weil der Domino abschmiert und sich anschließend neu startet (hat ein Kollege so eingestellt). Nach dem Neustart werden Konsistenz-Prüfungen durchgeführt.

Christoph

[WildVirus]

N'abend,

das klingt nach Ahnungslosigkeit - schlechte Voraussetzungen, um einen Fehler am Domino alleine anzugehen !!

Frag doch den Kollegen, der den Server so eingerichtet hat.......

Das (nicht die) Log ist die log.nsf im Rootverzeichnis.

Falls die DB wirklich nen Hau hat und ein Fixup nichts bringt, könnte die DB wirklich defekt sein. In dem Fall ist z.B. das Zurückspielen eines Backups sinnvoll.

Aber fang nur an, wenn Du Dir sicher bist, was Du tust. Du kannst den Schaden auch leicht vergrößern.

CU,
Axel

[Tode]

Welches dokument in welcher datenbank den server zum crash bringt, steht im jeweiligen nsd im ibm_technical_support- verzeichnis. Einfach analysieren (und wenn ihr es nicht selbst könnt, dann jemanden fragen, der sich damit auskennt). Wenn du das nsd hier hochlädst, hast Du vielleicht Glück, dass sich das jemand ansieht und die Ursache findet. Aber Achtung: das nsd enthält jede Menge Daten Eures domino- servers und sollte anonymisiert werden, bevor man es öffentlich macht...

[koehlerbv]

Genau. Das im Log was steht, ist nicht unmöglich, aber ungefähr so, als wenn Weihnachten und Ostern auf einen Tag fallen und gleichzeitig Leverkusen Deutscher Meister wird.

Weiters: Die Frage von Axel "was hast Du schon unternommen" ist nicht umsonst gestellt. Wirklich nicht! Ohne diese Information hat man eigentlich nicht wirklich Bock, sich näher dem Problem zu widmen.

Bernhard

[SlyFox]

Hallo,

"was habt ihr getan?": wir haben ein Fixup laufen lassen, dass alle defekten Dokumente rausschmeißen sollte. Wir haben eine Replik der Datenbank auf einem anderen Server angelegt und diese Replik wieder auf den Ursprungsserver zurück kopiert. Alles ohne Erfolg.

Der Agent muss knapp 3.000 Dokumente abarbeiten. Ist das vielleicht das Problem?

Ich werde auch mal im IBM_Technical_Support Verzeichnis nachsehen. Das kannte ich bisher nicht.

Christoph

[SlyFox]

Die geloggte Fehlermeldung lautet:

Code

PANIC: Attempt to rewrite NonSummary data when not appended to Summary Bucket and not in NonSummary Bucket

[RZLT]

Man nehme die PANIC-Meldung und befrage google  

https://www-304.ibm.com/support/docview.wss?uid=swg21255676



Das Problem sollte eigentlich mit 8.5.1 gefixt sein.

Mach mal Fixup -J -F -O dann updall -X und updall -R anschliessend compact -B
Wie groß ist denn die Datenbank??

[SlyFox]

Hallo RZLT,

das habe ich bereits gemacht und habe ZWEI Treffer erzielt, die beide nichts gebracht haben.

//EDIT: Sorry, hatte deine Antwort nicht zu Ende gelesen, habe nur bis zum Link gelesen. Werde die Befehle mal ausprobieren.

Christoph

[Peter Klett]

Der Agent muss knapp 3.000 Dokumente abarbeiten. Ist das vielleicht das Problem?

Ich würde jetzt die Zahl 3.000 nicht mit der Eigenschaft "viel" in Verbindung bringen. Was sind das für Routinen, die dort laufen? Sind das Scripte? Habt ihr die mal debuggt, um herauszufinden, an welchem Dokument es hängt? Die Fehlermeldung selbst hatte ich noch nicht, da kann ich leider nichts zu sagen.

[SlyFox]

Hallo Peter,

wie debugge ich denn knapp 3.000 Schleifendurchläufe?

Ich bin einen Schleifendurchlauf Schritt für Schritt durchgegangen und konnte nichts merkwürdiges feststellen.

Wenn der Domino abschmiert, schmiert auch gleichzeitig der Debugger ab. Ich sehe also nicht mehr, welcher Befehl zuletzt ausgeführt wurde bzw. welche Werte die Variablen zum Zeitpunkt des Crahes haben.

Ich werde es mal mit den Befehlen von RZLT versuchen.

Christoph

[Tode]

Nochmal: im nsd steht (wenn es nicht extrem dumm läuft) EXAKT, welches Dokument den crash verursacht. In ca. 10 Minuten hat man das raus... Wenn Du überlegst, wie lange Du schon dran rumdokterst, dann wäre die Investition in einen Experten schon lange drin gewesen (in der Annahme, dass Du Geld für Deine Arbeit bekommst).

Ansonsten: eine schleife zu debuggen, die 3000 Dokumente durchläuft ist ja auch nicht das Hexenwerk: einfach die Unid loggen (im zweifel per print, obwohl das die schlechteste Alternative ist), an der der agent grade arbeitet, dann sieht man ja, was vor dem crash zuletzt passiert ist...

[SlyFox]

Hallo Tode,

einen Experten kann ich leider nicht beauftragen, weil ich nicht der Chef in der Firma bin.

Ansonsten: eine schleife zu debuggen, die 3000 Dokumente durchläuft ist ja auch nicht das Hexenwerk: einfach die Unid loggen (im zweifel per print, obwohl das die schlechteste Alternative ist), an der der agent grade arbeitet, dann sieht man ja, was vor dem crash zuletzt passiert ist...

Genau so habe ich das jetzt gemacht. Ich habe per Print-Befehl die Doc-Id in eine Datei geschrieben und kenne jetzt den Übeltäter. Heute Abend werde ich das Script so anpassen, dass es stehen bleibt, sobald diese Doc-Id bearbeitet wird und debugge ab dem Zeitpunkt, um heraus zu finden, welcher Befehl den Crash auslöst.

Christoph

[SlyFox]

Hallo,

ich habe das Script gerade noch mal debugged.

Das Script schmier ab bei dem Aufruf von

Code

call vToDo.Init(node)

Hilft das irgendwie weiter?

Ach ja, vorher hatte ich die Befehle ausgeführt, die RZLT mir genannt hatte.

Christoph

[Tode]

Du erwartest nicht tatsächlich von uns, dass wir anhand einer einzigen Zeile eines Scriptes erkennen, warum es beim Aufruf einer Methode (Init) einer selbst definierten Klasse (Instanz: vToDo) mit dem Parameter "node" crasht?

Weder wissen wir, wie die Variablen deklariert sind, noch kennen wir die Klasse, noch haben wir ne Ahnung, was in dem Moment im Speicher steht...

Du weisst doch jetzt, welches Dokument für den Crash verantwortlich ist. Dieser Crash ist mit grosser Wahrscheinlichkeit der Struktur der Daten geschuldet, und NICHT dem Code... Analysier das Dokument und finde raus, was an diesem Dokument anders / kaputt ist... Und im Zweifel kopierst Du Dir das Dokument in eine Sicherungs- Datenbank und lässt den Agenten nochmal durchrennen...

[koehlerbv]

Wenn es wirklich der originale Agent aus dem Mail-Template ist, heisst die Zeile auch nicht
vToDo.Init(node)
sondern
Call vTodo.Init(note)

Und wenn es sich um originalen Stuff at all handelt, dann mach doch bitte einen PMR auf (und informiere uns dann, was dabei heraus kam, denn das wäre im Sinne des Forums und nicht das herumschicken auf eine Codezeile von Tausenden).

Danke.
Bernhard

[Tode]

ups.. sorry: Hatte das mit dem "Update Tasks" überlesen und nicht gemerkt, dass es um Standard- Funktionalität geht. Ich entschuldige mich hiermit....

[SlyFox]

Hallo Tode,

kein Problem.

Hallo Bernhard,

es ist der Standard-Agent und die Codezeile heißt tatsächlich so, wie du gesagt hast.

Was, bitte schön, ist ein PMR? Ich habe die Domino-Landschaft so von userem Ex-Mutterkonzern übernommen, ohne 100 %-ig eingewiesen zu sein. Wir haben noch nicht einmal einen eigenen Zugang zur Homepage von Lotus, da wir OFFIZIELL noch bis Ende September von unserem Ex-Mutterkonzert betreut werden. Aber "Betreuung" kann man DAS nicht nennen...

Christoph

[koehlerbv]

PMR = Problem Management Record

Aber ohne Kundenzugang bei IBM wird das natürlich nix. Dann bleibt Dir nur das, was Torsten schon schrieb und was Du ja eh machen musst: Analysiere das problemverursachende Dokument. Notfalls musst Du es löschen und neu erstellen.

Bernhard