Löschen der Löschmakierungen/Dokumentenrumpf

[jor]

Hallo zusammen,

ich habe eine Datenbank in der nachts ein Agent läuft, der alle Dokumente löscht und dann neue erstellt. Soweit so gut, aber die Datenbank wächst immer mehr an (Index ist auch vorhanden),
da wohl die Löschmakierungen nicht mit entfernt werden. Wie kann ich alle Dokumente und Löschmakierungen gleichzeitig löschen? Die DB hat keine Replik!

Danke schonmal,
Volker

[gossifu]

Hallo,

Du kannst auf dem Server den Compacter für diese DB periodisch laufen lassen,
nachdem die Dokumente gelöscht wurden.
Außerdem hast Du auch manuell die Möglichkeit zu komprimieren. DB-Eigenschaften, 2.Register.
Beides entfernt die Löschrümpfe.

mfg

Kjeld

[SeppHerberger]

Hallo

du kannst in den Replikationseinstelliungen unter Space Savers die Einstellung treffen, dass Dokumente nach 1 Tag gelöscht werden. wenn du den haken vorne nicht setzt, dann gilt das nur für Deletion Stubs.

Gruss

Daniel

[koehlerbv]

Beides entfernt die Löschrümpfe.

Beides entfernt NICHT die deletion stubs - das wäre auch verheerend ...

Bernhard

[jor]

Hallo Daniel und Kjeld,

vielen Dank für die Info. Nach dem Löschen der Dokumente habe ich per Script das Komprimieren
angeschmissen, funzt aber irgendwie nicht richtig. Manuelles starten der Komprimierung ist in diesem Fall nicht vorteilhaft, da alles zum Arbeitsanfang fertig sein muss (nee, ich bin schon der erste morgens im Büro! ;-)) )
Die Rep.-Einstellungen werde ich mir jetzt sofort anschauen und einstellen.

Danke, Volker

[jor]

Hi Bernhard,

warum wäre das Löschen der "deletion stubs" verheerend? Die DB wird nicht repliziert,
und die "deletion stubs" plustern die DB doch auf wo sie in diesem Fall nicht benötigt werden, oder...

[koehlerbv]

Es geht hier nicht um Deinen Einzelfall, sondern um das generelle Prinzip: Stell Dir vor, jeden Freitag um 23 Uhr werden die Mail-DBs auf dem Server komprimiert. Im Verlauf des Tages hat Kollege A vorher fleissig seine Mails aufgeräumt und massenhaft Löschungen vorgenommen.
Am Montag schmeisst er nun die Replikation mit seinem Notebook an, da er zum Kunden fahren muss. Und bei dieser Replikation bekommt er nun das ganze Gedöns von der Notebook-Replik wieder zurück auf den Server - die deletion stubs sind ja nicht mehr da ...

Bernhard

[Glombi]

Es gibt Tools zum Entfernen der Deletion stubs - bspw.
http://www.nsftools.com/tools/delstubs.htm

Einfach mal googen nach "delete deletion stubs"

Andreas

[jor]

@Bernhard,

jep, das ist natürlich richtig. Aber ich möchte nicht, das die DB aufgepumpt wird und auch noch der Index das nicht mehr so flott auf die Kette bekommt.

@Andreas,

danke! Werde ich direkt mal nachschauen...

Grüße an alle
Volker

[koehlerbv]

Das ist mir schon klar, Volker, aber SeppHerberger hat die Lösung ja bereits gepostet.

Bernhard

[jor]

Ja, das bin ich momentan am einstellen und dann mal schauen, ob alles so im Rahmen bleibt.

Volker

[gossifu]

Also echt, ihr raubt mir jede Illusion.
Irgendetwas muß doch von Notes her die Löschrümpfe entfernen. Ich glaube nicht, das
Notes alle Löschrümpfe nur mit externen Tools bereinigt.

mfg

Kjeld

[Glombi]

Natürlich gibt es eine eingebaute Funktion, das wurde ja schon zigmal erwähnt: Einfach das Cut-off Datum auf Heute setzen, dann werden die Deletion stubs gelöscht.

Aber wer will das schon jedesmal tun, insb. wenn etwas automatisiert läuft.

Andreas

[flaite]

Es geht hier nicht um Deinen Einzelfall, sondern um das generelle Prinzip:

Bernhard,

da denke ich die ganze Zeit drüber nach (zumindest wenn ich dich richtig verstehe, oder die Intention deiner Aussage).

Imho: Die größte Frage ist eigentlich, ab wann dieses Prinzip gilt.
Schutz vor kuriosen Überraschungen ist natürlich wichtig.
Man kann das "normale" Verhalten der Löschmarkierungen als "spezifiziertes" Verhalten sehen.

Aber ohne Überraschungen geht es eben meist nun einmal nicht:
Wenn man zu weit mit dem Schutz geht->
Das ist die wiederkehrende Melodie bei Damien Katz:

It's like the whole SOAP Vs. REST battle. The designers of SOAP realized that by introducing just a little more complexity into the design, it could free itself from it's HTTP bonds and become transport independent protocol. How's that working out for it?
Well, that tiny little bit of complexity is making it far less useful to real people than simpler bare bones REST protocols. I'm sure someone out there is using SOAP over some other non-HTTP transport and it's great for them, but the vast vast majority of its use will be over HTTP, and it's making things needlessly complex.

http://damienkatz.net/2006/04/comparing_xslt.html#comments (einer seiner Kommentare)

oder Linus torwald (zitiert nach: http://www.ratio.co.uk/ov9pdf.pdf , S. 27) 

Linus stated:
“So there's two MAJOR reasons to avoid
specs: they're dangerously wrong. Reality is different, and anybody who
thinks specs matter over reality should get out of kernel programming
NOW. When reality and specs clash, the spec has zero meaning. Zilch.
Nada. None. It's like real science: if you have a theory that doesn't match
experiments, it doesn't matter how much you like that theory. It's wrong.
You can use it as an approximation, but you MUST keep in mind that it's
an approximation. Specs have an inevitably tendency to try to introduce
abstractions levels and wording and documentation policies that make
sense for a written spec. Trying to implement actual code off the spec
leads to the code looking and working like crap.”
He went on to conclude:
"But the spec says ..." is pretty much always a sign of somebody who has
just blocked out the fact that some device doesn't. So don't talk about
specs. Talk about working code that is readable and works. There's an
absolutely mindbogglingly huge difference between the two.

[Glombi]

Es gibt so einige mysteriöse Dinge im Notes-Universum. Sachen die man sieht - Dokumente, Gestaltungselemente und ACL-Einträge und dann die dunkle Materie: Profile, Deletion stubs, Ungelesenmarkierungen.
Letztere sorgen dann meist für Überraschungen. Und die dann zu begreifen fällt schwer, weil man sie ja nicht sieht. Oder man sieht sie und weiß nicht was passiert. Also so eine Art Notesche Unschärferelation 

Andreas

[flaite]

Man spricht in anderen Kontexten allen Ernstes schon vom "Heisenberg-Effekt".
Etwa bei race conditions bei Multi-Threading kann ein Fehler genau dadurch verschwinden, wenn an der entsprechenden Stelle ein Log-Statement eingefügt wird.
Also: Durch das Hinschauen (Einfügen von logging) verschwindet die Abnormalität (bug).
Das gibts in Notes bestimmt auch irgendwo.

[Glombi]

Spätestens seit mir vor gar nicht so langer Zeit mal ein Administrator ein mir nicht erklärbares Verhalten des Domino-Servers durch eine "lokale Krümmung im Raum-Zeit-Kontinuum im Serverraum" erklärt hat, glaube ich im Notes-Universum an alles. 

Allerdings habe ich es versäumt, eine Ebene 4 Diagnose durchzuführen 

Andreas

[Glombi]

Ich habe da noch einen interessanten Artikel gefunden
http://www.heise.de/tp/r4/artikel/2/2360/1.html

Ich fürchte aber, wir sind schon etwas Offtopic und daher sollten wir es nicht weiter treiben, sonst kommt einer der Mods 

[Tode]

so, um in dem ganzen Wust nochmal die "Essenz" zu extrahieren, versuche ich alle sinnigen und unsinnigen Lösungsversuche noch mal aufzuführen:

compact

TUT:
bereinigt den Platz den die gelöschten Dokumente ohne Zweifel noch belegen und reduziert die Datenbankgrösse erheblich. Sollte durch ein Programmdokument aufgerufen werden und sollte mit den richtigen Parametern auch tun

TUT NICHT:
Entfernen der Deletion- Stubs: Das wäre auch -wie Bernhard ausgeführt hat- Katastrophal.

Dokumente entfernen, die seit X Tagen nicht geändert wurden

TUT:
Wird x auf z.B. 3 gesetzt, dann werden alle Deletion- Stubs älter als x/3 (also 1 im Beispiel) "Gepurgt", auch wenn das Häkchen vor der Option NICHT gesetzt ist.

TUT NICHT:
Gibt nicht den Platz frei, den das Purgen bringt, dazu braucht man dann wieder das compact....