load compact zum xten mal

[brainstorm]

hey leute
habe ein Problem mit der Komprimierung einer User db.

Der User hat eine Lokale Replik auf seinem Laptop. dort zeigt mir die *.nsf
eine Dateigröße von 2.3 GB an. auf dem Server aber zeigt mir die Datenbank eine Dateigröße von 3.1 GB an. Habe nun schon eine komprimierung (Datei-Datenbank-Eigenschaften-komprimieren) (Verwendet = 82%) lokal ausgeführt. die Änderungen durch schießen von Notes an den Server übergeben und auf dem Server eine komprimierung mit load compact mail\namevonuser.nsf durchgeführt. keinerlei veränderung der angeziegten größe im Domino Administrator.

Was mach ich falsch?? wie bekomm ich den reservierten Speicherplatz frei??

Gruss

[Driri]

Was zeigt Dir denn der Admin-Client für die Datenbank unter Benutzung an ? Ist der Compact auch wirklich gelaufen oder evtl. abgebrochen, weil die Datenbank im Zugriff war.

[Peter S.]

Die DB Größe berücksichtigt die Ansichten-Indizes.
Ich wette, wenn du in beiden DBs mal "STRG-SHIFT-F9" drückst sind die danach annähernd gleich groß :-)

Dauert aber seeehhhhhrrrrrr lange.

[brainstorm]

Wo kann ich mir die bentuzung anschauen?? bin noch nicht solang in der Noteswelt.
Komprimierung am Server hat er mit angezeigt das diese abgeschlossen ist mit 0 Fehler.
Das die Datenbank in benutzung war kann nicht sein da ich den Client persönlich geschlossen habe. (Änderungen Übergabe an Server)
Gruss

[Driri]

Schau mal im Adminclient unter Dateien. Da gibt es auch eine Spalte "Belegter Speicher".

Es muß auch nicht dein Client sein, der die Datenbank im Zugriff hat. Der Server greift ja auch immer wieder darauf zu.


Es gibt auch noch ein weiteres Problem. Unter bestimmten Umständen werden lokal durchgeführte Löschungen nicht zum Server repliziert. Lösch doch mal das Replizierprotokoll der lokalen Replik und replizier einmal manuell neu mit dem Server.

[brainstorm]

Danke ihr zwei.
War tatsächlich des ding mit den indizes. sind tatsächlich jetzt beide annähernd gleich groß.
Danke noch mal.

[SD]

Mal eine kleine Frage nebenbei: Wenn ich unter Datei -> Datenbank -> Eigenschaften auf das Komprimieren-Knöpfchen drücke, welche Komprimier-Art wird dann eingesetzt? Mit Kopie oder ohne?

[Peter S.]

Kommt auf das Serverrelease an.
Ich denke es war bei R6 in-Place und bei älteren mit Kopie.

Aber ich lasse mich gerne korrigieren :-)

[SD]

Hmm, es handelt sich um einen 7.0 Notes-Client und um eine 7er Archiv-Maildatenbank.


Da inzwischen noch ein sehr seltsames Phenomen aufgetauch ist, hole ich aber mal weiter aus:

Das Archiv liegt auf einem Netzlaufwerk mit Größenbeschränkung und ist leider ziemlich angewachsen worüber das Laufwerk nicht sehr glücklich war. Es wurde dann die Größenbeschränkung ein wenig hochgesetzt und ein Haufen Zeug aus dem Archiv gelöscht. Das Komprimieren hat dann zuerst gesagt, dass es jetzt ausgeführt wird, aber schon 1-2 Sekunden danach kam die Meldung "Fehler 'Datei nicht vorhanden': Komprimieren von pfad\dateiname.nsf beendet". Die Datei ist aber sehr wohl genau an dem Pfad mit dem Dateinamen vorhanden und lässt sich auch über die Kachel öffnen. Die Eigenschaften zeigen sonst auch alles normal an.
Eigentlich dachte ich das Problem würde sich lösen lassen, indem ich das Archiv auf C: kopiere und dort komprimiere, aber da sagt er mit, dass die Komprimierung später durchgeführt werden würde, was normalerweise heißt bei einem Notes Neustart. Dieser hatte allerdings nur den Effekt, dass beim öffnen des Archivs kurz ein Fortschrittsbalken aufblitzt (zu kurz um was zu lesen), die Datei aber so groß bleibt wie sie war.
Irgendwann zwischendrin habe ich das Archiv auf dem Netzlaufwerk und das auf C: auch mal mit einem Strg+Shift+F9 beglückt, um die Maximalgröße der Datenbank zu sehen (hat die größe allerdings nicht verändert, es waren wohl schon alle Indizies aufgebaut).

Diese Problem habe ich inzwischen damit gelöst, dass ich eine neue Kopie der Datenbank aus Notes heraus (also nicht im Filesystem) erstellt habe, die ja dann nur den tatsächlich verwendeten Speicherplatz belegt, aber es ist noch ein Effekt zu beobachten, bei dem ich mir nicht so wirklich sicher bin, ob der überhaupt was damit zu tun hat.
Seit ich diese Komprimier-Versuche gemacht habe öffnen sich Excel- und Powerpoint-Dateien nur noch sehr, sehr langsam (>20 Sekunden für Dateien <100 KB, betrifft alle xls und ppt Dateien auf Netzlaufwerk und lokaler Platte, Word ist verschont geblieben). Ich bin mir nicht mehr 100% sicher, aber ich meine während der Aktion war Excel und Powerpoint offen. Der Effekt geht auch nach einem Reboot des Rechners nicht weg.

Kann ein auf die Art misslungener Komprimierungs-Versuch etwas im System zerschießen, das so einen Effekt mit sich bringt? Leider habe ich jetzt keine Ahnung, ob ich mich schuldig fühlen soll, oder nicht.

[Tode]

ja, wenn die komprimierung nicht durchläuft, dann kann es auch sein, dass sich Dein Rechner selbst zerstört und nebenbei aus versehen den dritten Weltkrieg auslöst....

Jetzt aber mal wieder zur Sache:

Dein Post zeigt genau, dass Du DRINGENDST eine Domino- Admin- Schulung brauchst.

1. Das Archiv liegt auf einem Netzlaufwerk..
Archivierst Du "Lokal" oder auf den Server ?
Und damit meine ich NICHT, ob das Archiv auf einem Netzlaufwerk liegt, sondern was der Client sagt in den Datenbankeigenschaften...

a) Lokal
Dann KANN der Server die Datenbank nicht komprimieren, den Server interessiert nur, was er innerhalb seines Datenpfades findet, alles andere geht ihm am A... vorbei (mal abgesehen von Verzeichnis- Links, aber darauf komme ich gleich)
Wenn er die Datei aber findet, dann kannst Du wiederum nicht mehr lokal drauf zugreifen (wegen konkurrierender Zugriffe)
Jeder Compact- Versuch ist von vornherein zum Scheitern verurteilt

b)Auf Server
Wenn das Ding auf einem Netzlaufwerk liegt UND auf dem Server archiviert wird, dann wurde dem Server das Verzeichnis als Directory- Link bekannt gemacht. Das funktioniert aber bei einem Server NUR, wenn dieser NICHT als Dienst gestartet wurde, weil der Dienst den Systembenutzer verwendet, und der hat keine Netzwerk- Credentials.

Nun zu dem Thema "später": Das heisst keineswegs nach einem Neustart.
Der Client hat eine Queue mit Aufträgen, die er abarbeitet. Diese wird sequentiell abgearbeitet, und wenn darin schon eine Anforderung ist, z.B. Indizes neu aufzubauen oder eben eine DB zu komprimieren, dann wird die nächste Anforderung hintenangestellt.

Wenn das Archiv sehr gross ist, werden im übrigen nach dem Neuerstellen alle Ansichts- Indizes neu erstellt /aktualisiert, was einen mittelmässigen Rechner schon mal in die Knie zwingen kann, aber das tut er nur, während der Client läuft.

Tiefer möchte ich mit meinen Erläuterungen nicht gehen...

Gruß
Tode

[Peter S.]

Ich nehme mal an das Archiv liegt auf dem Netzlaufwerk (kein Domino-Server), dann wird mit Hilfe einer Kopie komprimiert und man benötigt auf dem Laufwerk (ich vermute auf dem Netzlaufwerk) nochmal dieselbe Menge an freien Platz den die DB jetzt belegt.
Um das zu umgehen könnte man von der DB auch eine Kopie über Notes machen, hat denselben Größen-Spar-Effekt, ändert aber die replik-ID.

[SD]

Jetzt fühle ich mich irgendwie missverstanden.

Das Archiv liegt lokal auf dem Netzlaufwerk auf dem sich das Data-Verzeichnis des Clients befindet. Komprimieren tut auch nicht der Server, sondern der Client indem in den Datenbank Eigenschaften auf das Komprimieren-Knöpfchen gedrückt wird.

Wir vermuten hier, dass die Datenbank einen Knacks bekommen hat, als Notes versucht hat was reinzuschreiben und das Filesystem mittendrin die Aufnahme verweigert hat, wegen der Größenbeschränkung des Netzlaufwerks. Gelöst haben wir das inzwischen tatsächlich durch eine neue Kopie.

Das Office-Problem und der dritte Weltkrieg hatten tatsächlich andere Ursachen. Ein Makro ist da gleichzeitig wie das Archiv in den Streik getreten, vermutlich ebenfalls wegen dem vollen Netzlaufwerk. Wegen dem Weltkrieg mach ich wahrscheinlich demnächst einen PMR auf...

Wie dem auch sei: Frohe Weihnachten!