...keinen Zugriff auf den Objektspeicher...

[Joschi]

Hallo zusammen,

ein Kollege erstellt eine lokale Replik, leider wird diese aber nicht aktualisiert und im Replikator erscheint folgende Meldung:

Sie haben keinen Zugriff auf den Objektspeicher, der von diesem Dokument verwendet wird.

Kennt jemand von euch diese Meldung und kann mir weiterhelfen?

Danke vorab.

[gab]

Hallo,

evtl. hängt der Fehler mit shared mail zusammen

die Konsolenbefehle show scos bzw. show scos all
könnten in diesem Fall weiterhelfen

[Joschi]

das probiere ich mal aus, danke.

[Joschi]

der Befehl show scos an der Serverkonsole brachte das Ergebnis:
Shared Mail: Not enabled

[gab]

Kannst du evtl. mit einem englischen Notes Client die Fehlermeldung auf Englisch reproduzieren?

Mit der deutschen Fehlermeldung komme ich jedenfalls nicht weiter, evtl. weis jemand anderes hier damit mehr anzufangen?

[Lisa]

Mit Meldungen über fehlenden Zugriff auf den Objektspeicher hatte ich einige Monate lang zu tun.

Vor einigen Jahren war hier shared mail eingerichtet worden. Shared mail wurde einige Monate lang benutzt und dann deaktiviert.

Im vergangenen Jahr wurde durch
load object unlink mail/*.nsf
die noch bestehenden Verbindungen der MailDBs zum Objektspeicher aufgelöst und die Objektspeicherdatei physisch gelöscht.

In einigen Maildateien verblieben Reste von verbundenen Mails, welche sich wegen des fehlenden Zugriffs zum Objektspeicher nicht löschen ließen.
Das Verschieben der dieser Mails in den Ordner unerwünschte Mail bleib die einzige Lösung.

Als dann das Komprimieren einiger Maildateien nicht mehr funktionierte habe ich hier im Forum unter dem Stichwort Objektspeicher eine Lösung gefunden:

der Befehl
show scos
sagte mir, dass shared mail derzeit nicht aktiviert ist

Beim unlink kann es Probleme mit Maildateien geben, die einen zu hohen Füllgrad aufweisen. Dort bleiben dann Reste übrig.

load object collect mail/usermail.nsf

löste die Verbindung auf. Daraufhin funktionierte auch das Komprimieren.

Leider funktioniert der Befehl hier nicht mit mail/*.nsf, weil Notes dann wieder auf den nicht mehr vorhandenen Objektspeicher zugreifen will.

Weiß jemand eine einfache Möglichkeit, herauszufinden, welche Maildateien betroffen sind? Ich möchte nicht 350 Maildateien einzeln anfassen.

Lisa

[Glombi]

Vielleicht hilft Dir das weiter:

http://atnotes.de/index.php?topic=34940.0

Andreas

[SD]

Wir haben das schockierenderweise, obwohl wir noch nie SharedMail eingesetzt haben.

Nach Recherchen hat sich dann ergeben, dass das möglicherweise Altlasten aus der Notes5-Zeit sind, die nach dem Update auf Notes7 ans Licht gekommen sind (siehe Technote 1117045). Mit dem Hinweis aus dem hier verlinkten Thread konnten wir kaputte Verknüpfungen dann auch entfernen (ich denke mal ein compact -c -i hat prinzipiell den gleichen effekt).

So richtig schocken tut uns jetzt allerdings, dass solche kaputte Dokumente in bereits "bereinigten" Datenbanken wieder aufgetaucht sind und das nicht gerade in einer unbedeutend kleinen Anzahl. Das kann einem schon den Tag verderben.
"Although the source of the corruption was not determined, the workaround was to ..." nützt uns auf jeden Fall nicht sonderlich viel, denn wenn wir so weitermachen, haben wir bald wieder ordentlich Platz auf dem Dominoserver.

Falls irgendjemand irgendeine Ahnung hat, wie wir das abgestellt bekommen, wäre mir der Tag schwer gerettet. Der IBM-Support hat uns bisher nur mit den 2 Technotes beglückt, mit denen wir die Reste der Dokumente, die wir eigentlich gerne behalten würden, auch noch losbekommen.

[Glombi]

Der Link auf die Technote geht nicht

[koehlerbv]

Dieser bereinigte Link geht - da war in der URL ein abschliessendes " zuviel ...

Bernhard

[SD]

Sorry, ich hab's gefixt.

Strengenommen war vor der URL auch mal ein ", aber dieses Forum mag das anscheinend nicht.

[Glombi]

Ok, da steht drin, dass die Maildokument schon zu Notes 5 Zeiten beschädigt waren, es der Server aber nicht bemerkt hat. Notes 6 ist nun besser im Erkennen beschädigter Dokumente und löscht die eben jetzt.

Mit einem
lo fixup -F -N  db.nsf
bzw.
lo fixup -C db.nsf

kann man beschädigte Dokumente aufspüren ohne diese zu löschen.

Andreas

[SD]

Ah, okay, das können wir vielleicht nutzen.

Verstehe ich das jetzt richtig, dass der fixup bei uns die Dokumente, mit denen was nicht stimmt, löscht und die Dokumentverknüpfungen in den Ansichten in der Datenbank lässt?

Sprich da, wo jetzt der Fehler "The object store that is used by this note was not found or is not a Notes database" kommt (z.B. beim compact), hat der fixup bereits zugeschlagen?

[SD]

Hmm, warum sagt der "load object collect -force"-Befehl bei manchen Datenbanken "mail/xxx.nsf contains no notes which use an object store" und bei manchen "x of xxxx notes processed"?

Es kann unmöglich sein, dass die Datenbanken bei denen ersteres kommt leer sind.

[Lisa]

Hmm, warum sagt der "load object collect -force"-Befehl bei manchen Datenbanken "mail/xxx.nsf contains no notes which use an object store" und bei manchen "x of xxxx notes processed"?

Es kann unmöglich sein, dass die Datenbanken bei denen ersteres kommt leer sind.

Nach meiner Erfahrung kommt die Meldung "x of xxxx notes processed" bei den Datenbanken, welche Objektspeicherverweise enthalten, wobei "x" für die Anzahl der ins Leere gehenden Objektspeicherverweise steht. "xxxx"sind die insgesamt in der Datenbank vorhandenen Dokumente.
Bei den Datenbanken, welche keine Objektspeicherverweise haben, kommt die Meldung "...contains no notes...", d.h. es sind nur intakte Dokumente aber keine Dokumente mit Objektspeicherverweisen vorhanden.

Lisa