Beiträge von CarstenH

ok - ich hab nochmal genauer geforscht und (ich hatte sowas schon befürchtet) meine aussage daß der compact dafür verantwortlich ist war schlicht falsch. ich war da einer falschaussage in einem älteren papier aufgesessen. man soll eben nicht alles glauben was man nicht überprüft hat. für abgelaufene dokumente ist es nämlich ein anderer task nur hatte ich gelöschte nicht mit abgelaufenen gleichgesetzt. es ist nämlich der indexer (update bzw. updall). allerdings gibt es keine mir bekannten parameter die das ganze beeinflussen können wann er das tut. m.e. tut er es sofort wenn eine db von ihm bearbeitet wird. zumindest sollte er das laut support info so tun. da der indexer in form des update-tasks ständig läuft kann man es auch kaum verhindern. warum allerdings bei dir nachweislich einige dokumente nicht gelöscht wurden weiß wohl nur der server selber ;=)

in dem zusammenhang fand ich noch die folgenden infos die für argumente gegen den papierkorb als dauerablage sprechen:

Zitat:
Starting in Domino 5.0.12 and Domino 6.0, the Maximum number of Soft Deletions is 32768. In previous releases of Domino 5.x the default maximum number of Soft Deletion was 1000.

unabhängig davon wirst du das problem mit den defekten gelöschten dokumenten m.e. nur los wenn du die softdeletion wenigstens kurzzeitig deaktiviertst (und vorher alles daraus rettest was nicht endgültig weg soll)

Ordner unter Notes sind nicht gleichzusetzen mit Ordnern unter Outlook oder Windows. Ein Notes-Ordner (wie alle Design-Elemente von Notes) ist eigentlich nur ein spezieller Dokumenttyp der vom Client entsprechend dargestellt wird.

Wenn man Dokumente in einen Ordner "schiebt" passiert eigentlich mit dem Dokument gar nichts. Vielmehr wird dem Ordnerdokument in einer speziellen Tabelle nur ein Verweis auf das zusätzliche Dokument hinzugefügt. Die Dokumente liegen also gar nicht wirklich im Ordner und ein Kopieren des Ordners, z.B. in eine neue Datenbank, würde nur das Designelement übernehmen nicht aber die Dokumentverweise da sich diese (wie zuvor angesprochen) in einer separaten Tabelle befinden die in einer anderen Datenbank keine Gültigkeit hätte und demzufolge nicht übernommen wird.

Kurz gesagt, um eine "Ordnerstruktur" samt allen Dokumenten und Verweisen darauf in den Ordnern in eine neue DB zu übernehmen gehen nur 2 Möglichkeiten: Entweder die von meinen Vorrednern angesprochene Variante mit aufwendiger Programmierung zu versuchen erst die Struktur und anschließend die gesamten Inhalte in einer zweiten DB nachzubilden oder (was ich in dem Fall machen würde) eine Datenbankkopie via Notes anlegen und alles was ich dort nicht brauche aus der neuen Kopie löschen. Geht schneller und funktioniert ohne Programmierung.

nööö. kennst mich doch micha... da kommt der trainer durch *fg*

Der vollständige Notes-Name Server/Firma/DE hat nichts mit der Netzwerkadressierung im TCP/IP zu tun. Auch läßt mich deine Schreibweise Server/Domain/DE vermuten, daß du gar nicht weißt was eine Notes-Domain eigentlich ist. Weder die Notes-Domain noch die Netzwerk-Domain haben irgendetwas mit dem Namen xxxxx/Firma/DE zu tun. Es gibt mehr Netzwerkprotokolle als nur TCP/IP und Notes/Domino ist ein Multiprotokollsystem.

Zum eigentlichen Problem. Ich geh davon aus (da ja DNS nur für TCP/IP verwendet werden) daß deinem Netzwerk eine Internetdomain (oder Intranet) zugeordnet ist, also z.b. *.meinedomain.de
Steht der Server Server/Firma/DE direkt im Internet wäre sein Name dann entsprechend server.meinedomain.de
Jenachdem wie eure Netztopologie aufgebaut ist käme auch server.meineintranetdomain.meinedomain.de oder was auch immer bei euch verwendet wurde in Frage. Wichtig ist dabei lediglich daß den Clients die Auflösung innerhalb der für sie festgelegten Suchreihenfolge möglich ist wobei identische oder zumindest identische übergeordnete Suffixe für Server und Clients problemlos gehen. Also workstationxyz.intranet.meinedomain.de kann server.intranet.meinedomain.de oder server.meinedomain.de problemlos auflösen.

In beiden Beispielen wird für den DNS nur die Common-Komponente (CN) des Notesnamens für den DNS-Eintrag verwendet (CN=Server/O=Firma/C=DE) also in dem Beispiel nur das Wort Server ohne die restlichen Namensbestandteile (die ausschließlich innerhalb Notes für Security von Bedeutung sind).

Sollte sich die Netzwerkdomain des Servers übrigens von der für SMTP verwendeten Internetdomain unterscheiden muß dem Server zusätzlich mitgeteilt werden für welche SMTP-Domains er zuständig ist ansonsten werden ohne weiteres keine Internetmails ankommen.

vermutlich ist das design deines domino directories defekt. technisch solltest du das design dort einfach neu reinsetzen (mittels datenbank gestaltung ersetzen). anschließend alle views aufbauen (updall names.nsf -r an der konsole).

da du einen cluster hast solltest du den andren server anschließend mit dem normalen replikator durchreplizieren lassen (clusterreplikator alleine reicht nicht aus dafür)

Serverdokument, Internet-Protokolle, Domino Web Server, Feld: Zeitlimit für inaktive HTTP Sitzungen.

Ich glaube aber nicht, daß das alleine tatsächlich ein Performanceproblem löst.

.[d]das löschen übernimmt der compact task, dazu ermittelt er alle laut datenbankvorgabe (eben diese 48h normalerweise) abgelaufenen dokumente.[/d]

korrektur - siehe später in diesem thread.

der compact task sollte eigentlich auf jedem server 1x täglich, mindestens jedoch einmal wöchentlich laufen.

läuft der nicht (z.b. weil ihn niemand als periodisch auszuführen eingerichtet hat) dann werden auch verschiedene aufgaben nicht wahrgenommen. danach klingts bei dir, als wäre er nie eingerichtet gewesen und nur sporadisch von hand gestartet worden.

du hast anscheinend meine antwort im papierkorb-topic (19.07.2004 11:42) überlesen sonst wüßtest du daß dein MANUELL keine auswirkung auf gelöschte dokumente bei R6 hat (oder hast du 5er mailtemplates?) die funktion löschen sorgt nämlich fürs echte löschen, nur werden xxx stunden (default 48, bei dir eben 4000) die dokumente noch von der physikalischen löschung verschont. nach ablauf der zeit...no way (außer backup)

fakt ist: die datenbank des nutzers ist nunmal kaputt - wenn du nichts unternimmst riskierst du daß noch mehr dokumente betroffen sind. notfalls muß man sich eben einen plan ausarbeiten wie man die im papierkorb liegenden dokumente so markiert daß man sie zurückholen, das problem beseitigen und wieder löschen kann. weiterhin würde ich meinen usern erklären daß der papierkorb kein normaler ordner ist. dann sollen sie sich einen müll-ordner anlegen oder archiv-db's.

betreffs zurückholen...wenn du kein backup hast siehts sehr schlecht aus.

aaah, ok, langsam kommt klarheit in die sache. ich hatte ja schon vermutet daß es was mit den gelöschten dokumenten zu tun hat. lediglich an die möglichkeit daß hier softdeleted dokumente noch im papierkorb liegen könnten hab ich nicht gedacht. ok, dann in der original-db mal den papierkorb leeren (in geh davon aus daß das was drin ist absichtlich gelöscht wurde). danach die datenbank-eigenschaft "softdeletions" (also wiederherstellbare löschungen) mal deaktivieren, anschließend das " spiel" mit der 0 und der 90 wiederholen. und die softdeletions dann wieder aktivieren und die 90 wieder rein. jetzt fixup, compact -c und updall -r wie schon gehabt.
meine andre frage nach der anzahl der betroffenen dokumente bezog sich übrigens aufs notes-log, da ja dort die defekte einzeln mit note-id aufgeführt sind.

ok...hatte ich nur falsch verstanden dann. aber was mir fehlt ist eine aussage zur noteskopie der db. dort treten doch nicht exakt die gleichen fehler auf? und auch vieviele dokumente das betrifft hast du nicht geschrieben.

was findest du denn nun im admin-client wenn du wie beschrieben nach der note-id schaust? wie viele defekte sinds denn die noch gemeldet werden? sind noch ansichten betroffen? das replace design schon durchgeführt? wirklich mal eine noteskopie versucht? fragen über fragen die ich aus deinen antworten nicht herauslesen kann ;=)

Dokument finden leicht gemacht:

- Admin-Client, Dateien, die Datenbank markieren
- Menü Werkzeuge, Datenbank, Dokument suchen
- ID (ohne die Nullen) eintippen

allerdings läßt mich die ausschrift oben "45CE GELÖSCHT daten note" vermuten, daß entweder fixup oder compact schon die defekten dokumente beseitigt haben und nur noch die deletion-stubs probleme machen. in dem falle sollte das beseitigen aller deletionstubs aus der db das problem lösen:

- Datenbank, Replizierparameter, Platzsparer
- Feld: Dokumente löschen die seit xxx Tagen nicht geändert wurden
- statt xxx eine 0 (Null) eintragen (ich nehme an vorher stand eine 90 drin, ist der Default-Wert) und, GANZ WICHTIG: NICHT den Haken vor der Zeile setzen. Also nur den Wert ändern!!!!
- Ok klicken

Das dauert jetzt nen Moment - er löscht dann die Deletionstubs.

Anschließend wieder die 90 reinschreiben (oder was eben drin stand)

Schauen ob jetzt alles i.O. ist

loool - ok, an den 4er client hatte ich nicht mehr gedacht. da dürftest du recht haben ;=) dann hast jetzt ne tüte gummibärchen gut *g*

ohne mail-db's machen die beiden eh nichts. insofern raus damit ;=)

Alle offiziellen frei verfügbaren Updates und die Fixlists findet man am einfachsten unter http://www.notes.net (Allerdings weiß ich grad nicht ob da auch die deutschen Versionen liegen)

Entsprechende Lizenzen vorausgesetzt bekommt man auch Zugriff auf den geschützten Downloadbereich bei IBM mit allen Voll- und Updateversionen bzw. das Ganze als CD-Stapel per Post.

die neue replik solltest du vielleicht nicht auf dem gleichen server anlegen - wenn der server per adminp mit sich selbst neue repliken anlegen will geht das ziemlich sicher in die hose ;=)

- versuch eine neue replik, z.b. auf deinem client

oder

- wenn es sonst nirgendwo weitere repliken dieser db geben sollte dann leg eine noteskopie dieser db an (das müßte sogar unter andrem namen auf dem server gehen)

- wenn das alles den fehler nach wie vor bringt dann sind mit ziemlicher sicherheit die internen verweise der bodyfelder zu den separat gespeicherten richtext- bzw. mime-objekten kaputt und die einzige mir bekannte lösung wäre manuelles löschen der defekten dokumente (bzw. anschließend vom backup zurückholen). welche dokumente das sind erfährt man aus dem log, da sind die note-id's aufgeführt.

- um zu testen ob der defekt noch da ist kann man mal ein im log genanntes dokument suchen und öffnen, vielleicht sinds ja auch nur verlorene anhänge, aber ich vermute die entsprechende mail wird sich nicht normal öffnen lassen (meine letzte erfahrung damit produzierte immer redboxes oder nsd)

- die defekten ansichten kann man versuchen zu beseitigen indem man einfach das design der mailschablone neu drüberspielt (mit db->gestaltung ersetzen)

so, dann viel erfolg erstmal...;=)

wenn die absenderadresse so aussieht heißt das, daß der mailrouter dem notesnamen keine gültige emailadresse zuordnen konnte (personendokument). dann kommt die default-formatierung wie sie zentral vorgegeben wurde für diesen fall.

wenns nur die internetmailadresse ist die dich stört dann versuche mal das feld INetFrom mit der mailadresse aus der arbeitsumgebung zu füllen (das macht der client eigentlich selber)

für den notes-versand sind die felder from und principal von bedeutung, für den externen versand die INet*-felder die jenachdem vom client bzw. router vervollständigt werden. ist schon wieder ne weile her daß ich das angepaßt hab daher kann ichs grad aus dem kopf nicht genauer sagen.

Ronka:

das man mit tricks die ansichten aus einer db rauslöschen kann ist mir klar, für die guimmibärchentüte mußt du mir aber schon glaubhaft machen, daß es dem topicverfasser versehentlich passiert sein kann. wenn er nämlich nur vergessen hätte ansichten zu erstellen wäre zumindest die leere defaultview da ;=)

ob dir der debugger in der mail-db viel spaß macht wag ich zu bezweifeln. zu viele scripte...;=) außerdem sind einige teile der vertreterfunktionen in der formelsprache, da muß man schon ohne debugger nach suchen.

im simpelsten fall brauchen nur ein oder zwei felder in der memo-maske geändert werden, beim kalender ists vermutlich erheblich mehr aufwand. ich hab jetzt aber nicht wirklich nochmal nachgeschaut, hab nur schon etliche mailtemplates für kunden anpassen dürfen. versuchs aber besser mit einem testuser und vergiß nicht dessen mail-db vom design-task unberührt zu lassen ;=)

wenn du das dokument, das du beantwortest, von der ansicht mit der maskenformel aus geöffnet hast dann gilt die maskenformel natürlich auch innerhalb der maske *g* in dem falle muß die maskenformel ein wenig umgebaut werden.

allerdings ist die lösung von diali in dem falle vorzuziehen...