DAOS und compact -c -ZU / Änderung in Domino 10.0.1 FP2

[Manfred W.]

Hallo zusammen,

so weit ich weiß war das Verhalten eines compact -c -ZU seit Einführung von DAOS mit Domino 8.5 immer das selbe. Wenn die Anhänge bereits in den DAOS ausgelagert sind, ist es nicht mehr möglich nachträglich die LZ1-Komprimierung zu aktivieren/deaktivieren. Deshalb ja auch die Empfehlung von IBM erst die LZ1-Komprimierung und dann DAOS zu aktivieren.
Wenn man einen compact -c -ZU auf einer Datenbank ausgeführt hat, auf der DAOS bereits aktiv war, ist einfach nichts passiert.

Irgendjemand muss sich bei HCL darüber beschwert haben, dass es nicht möglich ist, mit einem compact -c -ZU nachträglich die LZ1-Komprimierung zu aktivieren. Und irgendjemand bei HCL hat das tatsächlich als Bug eingestuft.
Das Ergebnis: im FixPack 2 für Domino 10.0.1 wurde als "fix" das Verhalten der -ZU / -ZD Switches geändert.
http://www-10.lotus.com/ldd/fixlist.nsf/Public/8B2BFF63BD8A95C0002583E7006E01D0?OpenDocument

Ein compact -c -ZU holt jetzt automatisch alle Anhänge in die Datenbank zurück, um die LZ1-Komprimierung aktivieren zu können! Und diese Änderung ist nirgends öffentlich dokumentiert.
Die Information dass diese Änderung der "Fix" ist hab ich vom Support.
Dabei wäre der Workaround doch mehr als einfach: erst einen compact -c -daos off und dann den compact -c -ZU ausführen. Vor allem: wieviele Kunden wird das "Problem" wohl betreffen?

Man mag darüber streiten ob es der richtige Weg ist. Aber der einfachste Weg nach einem Domino Versions-Upgrade alle Datenbanken und Schablonen auf die aktuelle ODS Version zu heben, und gleichzeitig die Gestaltungs-/Dokumenten-/LZ1-Komprimierung zu aktivieren, wo sie bisher nicht aktiv war (z.B. neue Schablonen) war nun mal ein
compact -c -ods -upgrade -* -n -v -ZU
als Rundumschlag auf alle Datenbanken.
Bisher hat das auch wunderbar geklappt. Auf den Datenbanken mit aktiviertem DAOS ist nichts passiert (außer dass der copy-style compact die Datenbanken auf die neue ODS-Version aktualisiert hat). Und auf den Datenbanken und Schablonen, wo die Komprimierung noch nicht aktiv war, wurde die Komprimierung aktiviert. Ziel erreicht.

Diesmal (10.0.1 FP2) ist das allerdings gewaltig in die Hose gegangen. Durch die (undokumentierte und aus meiner Sicht völlig unnötige) Änderung am Switch -ZU wurden alle Anhänge in die Datenbanken zurückgeholt, was die Datenpartition auf den Servern voll laufen ließ...

Grüße
Manfred

[eknori]

ach du Schei...
habe es gerade getestet. Alle attachments sind wieder in der Db. OMFG

[Manfred W.]

Ich werd das Thema mal über den Tom Zeizel eskalieren. Der Support kann schließlich nichts dafür.
Oder gibt's den Manfred Lenz noch? Der musste schon Ende 2014 meinen Unmut über die fehlende TLS1.0 (und höher) Unterstützung aushalten

[MacSpudik]

Wtf? Das ist definitiv tödlich.
Haltet Ihr uns auf dem laufenden? Darüber werden sicherlich noch mehr Menschen stolpern 

Viele Grüße von
Sebastian

[Manfred W.]

Ja, ich halte euch auf dem laufenden.
Daniel Nashed ist auch schon direkt mit dem Entwickler in Kontakt.
Und an HCL Deutschland hab ich das Thema mittlerweile auch weitergegeben.
Mal sehen was raus kommt.

[Manfred W.]

Hallo zusammen,

dass die Anhänge zurückgeholt werden, um komprimiert werden zu können, ist tatsächlich so gewollt. Dass die Anhänge bisher nachträglich nicht LZ1 komprimiert werden konnten, wurde als Bug angesehen, weil es anders dokumentiert war.

Nicht gewollt ist jedoch definitiv, dass die Anhänge danach in der Datenbank liegen bleiben. Hier wird mit der Entwicklung an einer Lösung gearbeitet. Evtl. wird dann noch der zusätzliche Schritt eingebaut, dass die Anhänge auch gleich wieder ausgelagert werden. Dann wachsen die nsf-Dateien zumindestens nicht mehr. Man sollte dann vermutlich nur aufpassen, dass genug Speicherplatz für das Transaction Log vorhanden ist (wenn der Archived logging style verwendet wird).

Und das geänderte Verhalten wird kurzfristig dokumentiert.

Das ist einfach alles unglücklich gelaufen.

Grüße
Manfred

[eknori]

Mir wäre es am liebsten, wenn es einen notes.ini paramater gibt, der das alte Verhalten wieder herstellt.

Zu der ganzen LZ1 Geschichte evtl noch ein paar Anmerkungen auf der Grundlage meiner Beobachtungen in den letzten Jahren.

LZ1 ist war eine gute Sache zum Platzsparen, wenn es denn durchgängig funktionieren würde. Hier spreche ich jetzt von beobachtungen, die ich im Zusammenhang mit iNotes gemacht habe. Das ist aber schon ein paar Jahre her und muss heute nicht mehr zutreffen.
Wenn man im Client in einer LZ1 aktivierten Applikation ein Dokument mit Attachment erstellt, dann wird es auch LZ1 komprimiert. Nimmt man nun das gleiche Attachment und hängt es über iNotes an ein Memo ran, dann sieht man in der Analyse des Dokuments, daß das Attachment werder LZ1 noch Huffmann kompromiert wurde. Im DAOS gab es dann auch 2 NLO. Ist ja logisch.

Daher macht es schon Sinn, hin und wieder alle Attachments neu zu komprimieren. Allerdings sollte man sich auch überlegen, ob der Aufwand ( und ggfs. das Fehlerpotential ) nicht größer ist, als ein paar Duplikate in Kauf zu nehmen.
Zu der Zeit, als LZ1 ( und die ganzen anderen Speicheroptimierungen ) eingeführt wurden, da war Plattenplatz noch extrem teuer, und auch ich habe seinerzeit um jedes Bit gekämpft, was man einsparen konnte.
Stellt man aber den Aufwand dem Nutzen heute gegenüber, fallen die Duplikate und der damit verbundene Speicherverbauch nicht weiter ins Gewicht.

Ich würde daher auf neuen Datenbanken alles aktivieren, was irgendwie Platz spart und gut ist.  Dann DBMT konfigurieren und werkeln lassen. Bei Fehlern reagieren, aber nicht jede Datenbank nachkontrollieren, ob irgendwo etwas nicht so komprimiert wurde, wie man es erwartet, und dann noch stundenlang analysieren, warum.
DAOS sowieso aktivieren. Der damit gewonnene Platz übersteigt die paar Byte bei Weitem, die man durch LZ1 einspart.

[oliK]

Hallo Manfred,

es wäre sicherlich korrekt, dass Anhänge zum Komprimieren aus dem Attachment-Store geholt werden und dann komprimiert wieder zurückgeschoben werden.
Dabei sollte man dann aber unbedingt AUCH beachten, dass je nach Einstellungen am Server-DAOS die Ordner des AttachmentStore anschwellen.
Ein komprimiertes Attachment hat sicherlich einen anderen Hash als unkomprimiert und wird ja daher als NEUE NLO-Datei abgelegt.
Bei uns ist das DAOS bspw. so eingestellt, dass Attachments nach Löschung aller Referenzen noch einige Tage vorgehalten werden. D.h. temporär landen ggf. beide Anhang-Varianten im DAOS bis das prune mit entsprechendem Zeitstempel durchgeführt wird.

[eknori]

Ein komprimiertes Attachment hat sicherlich einen anderen Hash als unkomprimiert und wird ja daher als NEUE NLO-Datei abgelegt.

Veranschaulicht sehr gut, dass solche Aktionen eher kontraproduktiv sind.
Daher war die ursprüngliche Funktionsweise sicherlich gut , und möglicherweise auch unter diesem Gesichtspunkt umgesetzt worden.
Und wenn man das jetzt weiter spinnt: Was ist im Cluster? Und wenn dann später noch das FileSync auf NLO Ebene im Domino funktioniert, dann ist ratz fatz eine Menge zusätzlicher Plattenplatz belegt. Das kann beliebig komplex werden.

[Manfred W.]

Mit 10.0.1 FP4 kann man jetzt keinen compact -c -ZU mehr auf Datenbanken ausführen, auf denen DAOS aktiv ist

SPR# RDRABGQMWZ - compact -c -ZU no longer allowed on DAOS enabled databases

Diskussion beendet