ncompact ohne gewünschte wirkung

[William Wallace]

Hallo zusammen,

zuerts einmal - ist ja mein erstes posting hier - respekt und gratulation für das tolle forum hier. bin schon lange 'gast' gewesen und hab' fleißig mitgelesen.

nun mein problem:
ich habe eine recht große datenbank (9,5GB mit 570.000 Dokumente). Diese DB ist wegen der vielen Indizes so groß. Nun habe ich die DB auf einem Testserver gestellt, um dort viele Ansichten zu löschen (~60). Als ersatz habe ich eine handvoll selbstsortierter Spalten den Usern zur Verfügung gestellt. Ziel ist und war es einfach die DB kleiner zu kriegen. Ich habe demnach ein ncompact -C und anschließend auch ein ncompact -B durchgeführt. Aber leider ohne merklichen Erfolg. Es wurde nur 1% recovered...

Woran kann das liegen - wie kriege ich diese DB kleiner?

Grüße,
William

[Glombi]

Hallo William,

willkommen als aktiver Teilnehmer hier!

Du musst ein
load compact -D <pfad>

an der Serverkonsole eingeben, um die Ansichtsindizes zu löschen.

Andreas

[William Wallace]

uups - habe gerade festgestellt, dass ich diesen beitrag im R5er Forum gestellt habe - gehört eigentlich im das R6er - sorry.....  

[William Wallace]

Danke Andreas - probiere ich gleich mal aus...

[William Wallace]

Super - Danke. Die DB ist nun nur noch 2,5 GB groß 

[pd]

wieder was gelernt... ;-)


Gruß, Patrick

[William Wallace]

Hallo,

das mit dem compact hat super geholfen. danach habe ich die Datenbank wieder indiziert und musste mit schrecken feststellen, dass sie nun 10,5GB groß ist. Also größer als vorher.

Nochmal mein eigentliches Vorhaben: Habe 9,5GB DB mit 570.000 Doks. Die Doks sind nicht sonderlich groß. Durch löschen von einigen Views (~60) erhoffte ich mir eine Einsparnis der DB-Size. Das Gegenteil ist passiert.... Gibt es sonst noch einen Tipp 

[Driri]

Schau dir die Views an. Killer sind Verwendung von @Today oder ähnlichen Formeln in der View und z.B. sortierbare Spalten vergrößern die Indexe ebenfalls.

In einem Redbook von IBM sind die Sachen auch ein wenig beschrieben. Das Teil heißt "Performance Considerations for Domino Applications", hab leider keinen direkten Link.

http://redbooks.ibm.com

[Semeaphoros]

und dann kann man auch mit NotesPeek nachschauen, wo es besondere Speicherfresser gibt.

[Driri]

sh database xyz.nsf auf der Console ist auch ganz nützlich dafür 

[Semeaphoros]

Oder der Datenbankkatalog und andere Statistiken im Log oder so.

[William Wallace]

@Driri: Habe viele Views mit Kategorisierungen mit Formeln, etc. rausgenommen und größtenteils nur noch VIews mit sorted Columns verwendet. Das soll (lt. notes.net) weniger Speicher fressen als mehrere categorzed Views.
--
Das mit sh <filepath> geht leider nicht

@All: Danke für die weiteren Tipps - werde ich alle nach und nach prüfen 

[Semeaphoros]

Das kann aber keine wirklich grosse Differenz sein, jede sortierte Kolonne produziert einen eigenen Index.

[William Wallace]

Das kann aber keine wirklich grosse Differenz sein, jede sortierte Kolonne produziert einen eigenen Index.

Laut log sind aber genau diese Views die kleinsten Speicherfresser mit 0 KB. Die anderen Views mit vorgegebener Sortierung (Kategorisierung) sind wesentlich größer. Ich denke es wird tatsächlich an der Art der Kategorisierung liegen (@Today, @If, ...).

William

[William Wallace]

Sooooo,

danke an Semeaphoros - der Hinweis mit dem log war ein Guter 
Nach Prüfung bin ich zu zwei Ergebnissen gekommen:
a) Self-Sorted Columns sind nicht wirklich immer Platzsparender 
b) Eini View hat eine Größe von 1.065.176 KB    viele andere liegen zwischen 100.000 und 600.000 KB

Gerade die Views unter b) haben ein oder mehrere @If's in der Kategorisierung und anderen Spalten. Ich denke da muß was umgestellt werden 

Vielen Danke für eure Hilfe,
William

[Driri]

Noch nen kurzer Hinweis zu dem Consolen-Befehl :

sh database <DB mit Pfadangabe>

wäre korrekt gewesen 

[Semeaphoros]

William, vielleicht noch ein Hinweis zur Index-Grösse, wenn sie mit 0 (Null) angegeben ist, dann bedeutet das, dass dieser Index wegen noch nicht oder nicht mehr gebraucht nicht aufgebaut ist. Der ist also nicht wirklich gratis.

[William Wallace]

William, vielleicht noch ein Hinweis zur Index-Grösse, wenn sie mit 0 (Null) angegeben ist, dann bedeutet das, dass dieser Index wegen noch nicht oder nicht mehr gebraucht nicht aufgebaut ist. Der ist also nicht wirklich gratis.

Jepp, das hatte ich dann in der Zwischenzeit auch gemerkt 

[William Wallace]

Hallo,

muß diesen Thread nochmal aufgreifen. Die Ausgangslage ist wie gehabt:

Habe eine ca. 9,5 GB große DB mit 570.000 Dokumenten. Nach einem xcompact oder ncompact -D ist die DB nur noch 2,5 GB groß. Habe demnach ca. 2,5 GB an reinen Daten. Sobald ich die Indizes wieder aufbaue ist die DB 8,8 GB groß.

Ziel ist es die DB kleiner zu machen. Dazu habe ich ca. 60 von vorher 200 Ansichten gelöscht. Zusätzlich habe ich die gängigsten Ansichten auf die Programmierung überprüft (@If-Kategorisierungen aufgehoben / Self-Sorting Columns eingefügt / ...).

Wie es scheint brachte das jedoch nicht den von mir gewünschten Effekt. In der Log-Statistik vom Server sind diese modifizierten Ansichten auch nicht viel kleiner geworden.

Gibt es eurerseits noch eklatante Hinweise oder anderweitige Tipps ?

Vielen Dank und Gruß,
William