Attempt to use an invalid slot-number

[Peter Klett]

Hallo,

diese Fehlermeldung wurde hier zwar schon einmal angefragt, aber bisher wurde nur eine Einmal-Reparaturmöglichkeit diskutiert.

Wir hatten diese Fehlermeldung vor Jahren schon einmal in einer intern genutzten Datenbank, hartnäckig immer wieder etwa alle 2 Wochen. Dann fusionierte der Mandant und die Datenbank wurde archiviert - Problem "gelöst" (für jeden Mandanten existiert eine Datenbank mit der gleichen Schablone).

Vor vielleicht einem halben Jahr fing der Spaß mit einer weiteren Datenbank an (gleiche Schablone, anderer Mandant). In den letzten 5 Wochen wohl 3 mal. Da diesmal eine Fusion nicht abzusehen ist , versuche ich nun der Ursache auf den Grund zu gehen.

Die Datenbank liegt auf einem Cluster. Im Fehlerfall löschen wir die defekte DB und replizieren neu vom Clusterpartner. Sind beide Repliken defekt, replizieren wir die Datenbank neu auf lokal, löschen auf beiden Servern und replizieren von lokal wieder zurück. Die Routine funktioniert bisher zuverlässig, ist aber auf die Dauer lästig.

Die Frage ist, welche Ursache die Fehlermeldung hat und ob man mit ein paar Einstellungen vielleicht dagegen arbeiten kann.

Wir haben schon eingestellt, dass keine Ungelesen-Markierungen verwaltet werden. Auffallend war bei der ersten Datenbank, dass ein Dokument sehr viele Antwortdokumente besaß. Auch in der jetzigen Problemdatenbank hat ein Dokument sehr viele Antworten (derzeit 28.003). Der Fehler tritt auf, wenn genau dieses Elterndokument mit den vielen Antworten gespeichert werden soll.

Wenn es aber mit der Anzahl der Antworten zusammenhängt, warum ist das Problem durch Replikation behoben, obwohl die Anzahl dadurch nicht verringert wurde? Bis zum nächsten Auftreten sind ja auch wieder Dokumente dazugekommen (50-100 pro Tag durch Import). Möglicherweise dauert ein Aufbau eines Indexes in der Datenbank zu lange und wird durch einen anderen Prozess gestört (z.B. Clusterreplikation). Vielleicht kann man durch eine Einstellung da mehr Zeit schaffen?

Ein paar Rahmendaten:
Server: 7.02
Datenbank:
Anzahl Dokumente: ca. 185.000
Plattenplatz: ca. 350 MB, 96 % verwendet
ODS-Version: 43

Danke schonmal für die Antworten

[Peter Klett]

Ein Nachtrag:

In Axels Link zu den Größenbeschränkungen ist aufgeführt, dass max. 300.000 Antworten möglich sind. Davon haben wir noch keine 10 % genutzt 

http://atnotes.de/index.php/topic,50929.msg327119/topicseen.html#msg327119

[Micha B]

Vielleicht ist hier was hilfreiches für Dich dabei:
http://www-01.ibm.com/support/docview.wss?uid=swg21099509
http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/1a5de2e89d2ba29d8525708400526200?OpenDocument
http://notes.crg.net/ibr/doc.nsf/b1b300107ee46e89412569c00047192b/21c04d36acf6ecb441256b5a0060d610?OpenDocument

[Peter Klett]

Vielen Dank, hab' mal durchgeschaut. Da geht es leider nur um die Reparaturmöglichkeit, darin haben wir allerdings schon eine ganz gute Routine.

Ich würde das Auftreten des Fehlers gerne verhindern.

Wir hatten auch schon mal die Clusterreplikation abgeschaltet und dann beim nächsten Auftreten des Fehlers als Ursache ausgeschlossen.

[rpes]

Bei mir ist dies in einer Anwendung auch aufgetaucht.
Ich habe ein paar Tests gemacht und konnte das Problem auf diese Art nachvollziehen.

1. Ein Hauptdokument mit 40.000 Antwortdokumenten angelegt
2. Eine LotusScript-Routine durchläuft in einer while-Schleife alle Antwortdokumente und speichert alle 500 Dokumente das Hauptdokument.

Ergebnis: Wenn ca. 16.000 bis 18.000 Antwortdokumente durchlaufen wurden, tritt der Fehler beim Speichern des Hauptdokumentes auf.
Das Script habe ich unten mal eingefügt. Der Fehler tritt unabhängig davon auf, ob man mit delete den Speicher freigibt oder nicht.
Sobald der Fehler aufgetreten ist, ist die Struktur so kaputt, dass das gleiche Script beim ersten Speichern nach 500 Dokumenten den Fehler bringt.

Meine Anwendung werde ich jetzt so umstellen, dass dort keine Antwortdokumente mehr benutzt werden. Dies ist in meinem Fall zum Glück relativ einfach möglich.

Ralf

Sub Initialize
   On Error Goto Errorhandle
   
   Dim session As New NotesSession
   Dim db As NotesDatabase
   Dim collection As NotesDocumentCollection
   Dim doc As NotesDocument
   Dim docAntwort As NotesDocument
   Dim lngZaehler As Long
   Dim collAntworten As NotesDocumentCollection
   Dim strSubject As String
   Dim docNext As NotesDocument
   
   Set db = session.CurrentDatabase
   Set collection = db.UnprocessedDocuments
   Set doc = collection.GetFirstDocument()
   
   Set collAntworten = doc.Responses
   Set docAntwort = collAntworten.getFirstDocument
   lngZaehler = 1
   While Not (docAntwort Is Nothing)
      If lngZaehler Mod 500 = 0 Then
         Print "Hauptdok speichern: " & Cstr(lngZaehler)
         Call logEvent("Hauptdok speichern: " & Cstr(lngZaehler), "", Nothing)
         Call doc.Replaceitemvalue("Test", Cstr(lngZaehler))
         Call doc.Save(True, False)
      End If
      lngZaehler = lngZaehler + 1
      Set docNext = collAntworten.Getnextdocument(docAntwort)
      Delete docAntwort
      Set docAntwort = docNext 
   Wend
EndFunction:
   Exit Sub
   
errorhandle:
   Select Case Err
   Case Else
      Call logEvent("Zähler: docNext " & Cstr(lngZaehler), "", Nothing)
      Call sBEBStandardErrorHandler(cBEBAusgabeDialog + cBEBAusgabeLog)
      Resume EndFunction
   End Select
   
End Sub

[Peter Klett]

Danke für die Info. Ein Umstellen weg von Antwortdokumenten ist in unserer Datenbank leider nicht so einfach möglich. Inzwischen haben wir schon zwei dieser Datenbanken (von etwa 150), bei denen der Fehler auftritt. Die Reparatur mittels Anlegen einer neuen Replik funktionierte zum Glück bisher immer.

[Peter Klett]

Durch den Hinweis von rpes hatte ich Bestätigung genug, um wirklich das Projekt anzugehen, das Verfahren umzubauen. Zum Schluss hatten wir schon 4 Datenbanken, die bis zu zweimal pro Woche kaputtgingen.

In dem jetzt geänderten Verfahren verbleibt nur ein kleiner Teil der bisherigen Antwortdokumente (nur die der letzten 30 Tage und die nicht bearbeiteten) als Antwortdokumente, die anderen werden zu Hauptdokumenten. Dadurch sind sie nicht mehr in den Ansichten zu sehen. Eine Archivmaske mit einer eingebetteten Ansicht, die über die Kundennummer des zuvor markierten Kundendokuments (erste Kategorie) die zugehörigen Hauptdokumente als Archiv anzeigt, ist der Ersatz dazu.

Das ist nicht ganz so schön, wie vorher, aber gut genug.

Das Verfahren läuft so seit etwa 3 Wochen ohne weitere Probleme. Aufgrund der Häufigkeit des Fehlers ist anzunehmen, dass das Problem damit gelöst ist.

Allein der Umstellungsagent, der in den alten Dokumenten aller Datenbanken die strukturelle Änderung nachvollzogen hat, brauchte 48 Stunden. Solche Änderungen braucht man nicht jeden Tag ...

Vielen Dank nochmal für die Bestätigung.