Ist DAOS Schuld für plötzlichen Anstieg des Datenvolumens?

[Manni Ciao]

Wir haben seit ein paar Jahren DAOS im Einsatz und das ohne Probleme, deshalb bin ich nicht so fit im Troubleshooting.

Heute hat unser Server plötzlich nur mehr 71 GB frei (von 1.229 GB Gesamt)
Gestern hatte er noch 264 GB frei

Der Server führte heute um 24:00 einen Restart durch

Ausschnitte aus der LOG:
14.04.2015 00:09:21   The DAOS catalog cannot be opened. DAOS cannot operate normally.: The integrity of a database storage container has been lost - the container will be rebuilt.
14.04.2015 00:09:23   Event Monitor started
14.04.2015 00:09:23   Begin scan of databases to be consistency checked

...
14.04.2015 00:10:56   DAOSMGR: DAOS Manager started
14.04.2015 00:10:56   DAOSMGR: Container Scan started
14.04.2015 00:10:56   DAOSMGR: Container Scan completed

Der CatalogState war heute 8 Uhr nicht in Synch
Ich habe dann ein Resync gemacht und nun ist er wieder 'SYNCHRONIZED'

Bitte um Ihre geschätzte Expertenmeinung!
Bekomme ich morgen ohne weitere Eingriffe meine ~200 GB zurück?
Oder verdächtige ich DAOS zu Unrecht?

Server(64Bit)(Release 9.0.1FP2 for Windows/64)

[eknori]

Du hast den falschen im Verdacht.

So von heute auf morgen 190GB weniger, das ist nicht die Schuld von DAOS.

Allerdings wirst du nach dem resync wieder etwas mehr Platz zur Verfügung haben, da DAOS .NLO Files, die keinen verweis mehr hatten aufgrund des Sync-Fehlers nicht gelöscht hat.

Ich würde mal einen Scan nach .NLO files machen, die im fraglichen Zeitraum erstellt wurden. Evtl. bekommst du damit einen Hinweis, welches Datenvolumen in das DAOS Repository geschrieben wurde.
Da müssten dann aber schon einige Mails mit riesigen Anhängen durchgelaufen sein, oder in Datenbanken, die von DAOS behandelt werden einige riesige Attachments abgelegt worden sein.

Die Zunahme kann sehr viele Ursachen haben. z.B. auch Aufbau von Ansichtenindexen, Erstellen FT-Index  ...

[Manni Ciao]

Danke, ich habe jetzt die DAOS Container nach 'Date modified' durchsucht und festgestellt, dass ca.  120.000 NLO Files (!!) in der Zeit zwischen 03:30 bis 7 Uhr erstellt wurden!

In dieser Zeit läuft genau mein Task:
DBMT -compactThreads 3 -updallThreads 3 -range 03:30 AM 07:00 AM

Wir setzen DBMT schon seit Monaten ein, aber heute sind die sich "in die Quere gekommen"?!

Ich habe mir schon mal die Frage gestellt, ob der tägliche compact (wochentags) Sinn macht. So wie ich das verstehe, macht ein compact eine neue DBIID und diese tauscht der Server dann im DAOS Katalog aus.

So sieht das dann in der log (nicht nur heute) aus:

> drop Mail\R02C3062.nsf
07.04.2015 06:36:59   Compacting Mail\R02C3062.nsf (Elisabeth xxxx),  -compactThreads 3 -updallThreads 3 -range 03:30 AM 07:00 AM
07.04.2015 06:37:03   Recovery Manager: Assigning new DBIID for f:\domdata\Mail\r02c3050.nsf (need new backup for media recovery).
07.04.2015 06:37:03   DAOSMGR: DbDelete started
07.04.2015 06:37:03   DAOSMGR: DbDelete completed
07.04.2015 06:37:04   DBMT: Compacted  Mail\r02c3050.nsf (Florian xxxx), 0K bytes recovered (0%),  -compactThreads 3 -updallThreads 3 -range 03:30 AM 07:00 AM

> drop Mail\R02c3063.nsf
07.04.2015 06:37:05   Compacting Mail\R02c3063.nsf (Ramona xxxx),  -compactThreads 3 -updallThreads 3 -range 03:30 AM 07:00 AM
07.04.2015 06:37:09   DAOSMGR: DbDelete started
07.04.2015 06:37:09   DAOSMGR: DbDelete completed
07.04.2015 06:37:15   Loadmon: Domino AI = 100, XF = 0

07.04.2015 06:37:17   Recovery Manager: Assigning new DBIID for f:\domdata\Mail\R02c3063.nsf (need new backup for media recovery).
07.04.2015 06:37:18   DBMT: Compacted  Mail\R02c3063.nsf (Ramona xxxx), 0K bytes recovered (0%),  -compactThreads 3 -updallThreads 3 -range 03:30 AM 07:00 AM


Danke für eure Hilfe oder Input!

[cg-home]

schau doch auch mal ob Die NLO am Ende ein "P" haben.
.....P.nlo
Das sind eigentlich temporäre NLOs die z.B.: bei Replizieren
angelegt werden und dannach einen anderen Dateinamen bekommen sollten.

Ein Kollege von uns hat mal seinen Notebook gesichert (ZIP) und hat sich
dann selbst per Mail dieses ZIP gesendet, damit es am Server gesichert wird.
Die ZIP hatte ca. 2GB (Wenn ich mich noch recht erinnere).
Als er gemerkt hat, dass es irgendwie nicht hinhaut und auch seine Quota überschritten war,
hat er die Mail unter gesendet wieder gelöscht und gemeint das es das war.
Allerdings hat sein Client seit dem versucht, diese Mail aus der lokalen mail.box zu versenden
aber hat immer wieder automatisch abgebrochen. Dadurch wurden bei uns so viele
NLOs erzeugt das die Platten voll wurden und der Server keinen Bock mehr hatte.
War gar nicht so einfach mit IBM zusammen den Übeltäter zu finden.

Das ging allerdings über mehrere Tage/Wochen und nicht wie bei Dir über Nacht.

Sind vielleicht irgendwelche Dokumente/DBs verschlüsselt? Wenn ich mich nicht arg täusche
legt er für jedes verschlüsseltes Dokument mit Anhänge einzelne neue NLOs an.
Wenn dann der compact mit -c läuft könnte es ggf. jedesmal die Anhänge verdoppeln, weiß nicht
wie schlau das der Compact bzw. DAOS macht.
Das kann ggf. Ulrich wiederlegen.

Gruß Christian

[Manni Ciao]

Danke Christian,
Nein - die 120.000 NLOs habe kein "P" am Ende des Dateinamen.
 
Es werden sicher ein paar Dokumente auf unserem Mailserver verschlüsselt sein.

Aber dass es zu einer solchen Datenmenge führen kann, nur wenn beim Server Reboot der DAOS Katalog ein Problem hat, macht mir Angst. Insbesondere da ich nun nur mehr 70 GB frei habe und nicht weiß, ob nun nach Resync das Datenvolumen geringer wird oder dies heute auch wieder passieren kann.

> The DAOS catalog cannot be opened. DAOS cannot operate normally.: The integrity of a database storage container has been lost - the container will be rebuilt.

[eknori]

Wenn ich mich nicht arg täusche
legt er für jedes verschlüsseltes Dokument mit Anhänge einzelne neue NLOs an.

Ja, das ist so. Allerdings werden die nicht bei jedem Compact dupliziert. der "Hash" bleibt ja gleich; und wenn das Doc schon im repository ist, dann wird es auch nicht neu angelegt.

@Manni: Ohne auf die genaue Configuration deines Systems zu gucken, kann man nicht viel sagen.

Auch was den DBMT angeht, kann man da einiges optimieren. Nicht jede DB braucht jeden Tag ein compact. Aber das kann der DBMT ja gerade ganz gut selber bewerkstelligen, wenn er richtig konfiguriert ist.

Und den Resync kann man auch programmgesteuert täglich anstossen. das garantiert dann, daß auch die Prune Operationen sauber laufen.
Wenn der DAOS Cat jeden tag bei euch aus dem tritt kommt, dann muss man sich dringend das System einmal ansehen.

Ich habe DAOS auf Systemen im Einsatz, die weit mehr als eure "läppische" Datenmenge beinhalten. Und eine solche Datenvermehrung ist mir auch noch nicht untergekommen.

[Manni Ciao]

Hallo Eknori,

> DBMT werde ich anpassen - aber da wurde ja propagiert, dass dieses Wundertool um so viel mehr kann, als der updall und compact ...

> Resync Force machen wir jeden Werktag um 19:00

> Über DAOS habe ich bisher auch noch nie was Negatives gehört/gelesen..

Im Netz fand ich zu der Fehlermeldung nur einen Eintrag:
http://www-10.lotus.com/ldd/fixlist.nsf/Public/B10059DE9EC65AAD85257B370064D516?OpenDocument
Ob das die Lösung ist.. ein Debug-Parameter, das irritiert mich.

[Manni Ciao]

Kann es sein, dass der DAOS Cat aus dem Tritt kommt, weil ich temporär 3 Rücksicherungen von Mail-DBs habe, die Dateianhänge die auf DAOS Container referenzieren und die NLO Datei nicht findet?

Hochgerechnet findet er gerade 1100 Dateien nicht.
(Die Dateianhänge habe ich nicht zurück gesichert, da nur ein Text-Mail gesucht wurde)

13.04.2015 19:45:26   The database f:\domdata\MailAustritte\r02c031.nsf has a reference to F:\SMDATA\DAOS\0009\34562676278D5F5F41849690A8F0180DEE34A50B00060705.nlo, which does not exist.  An entry has been added to the DAOS catalog indicating the NLO is missing: Entry not found in index
13.04.2015 19:45:26   The database f:\domdata\MailAustritte\r02c031.nsf has a reference to F:\SMDATA\DAOS\0008\0D268A6CD90AB470E5927FE3AB4DA1DA1824122400499D97.nlo, which does not exist.  An entry has been added to the DAOS catalog indicating the NLO is missing: Entry not found in index

[eknori]

Der DEBUG param bezieht sich auf ein anderes problem. Da gaukelt irgendeine andere Datenbank dem daosmgr vor, sie sei der daoscat.

resync FORCE würde ich nur im äussersten Notfall einsetzen, weil dann wirklich alles neu aufgebaut wird. Und das dauert. Und wenn dann ein Prozess dazwischen funkt, bist du wieder am Anfang.

Die missing NLO können den sync ausser Tritt bringen.
Hier würde ich zunächst mal aus dem Backup die fehlenden NLO wieder in das DAOS Repository spielen und dann erst die Rücksicherung der Datenbanken anstossen.

Das der daoscat nicht in Sync ist, spielt aber nur eine Rolle beim Löschen von nicht referenzierten NLO. Wenn ihr also die 3 Dbs lediglich temporär auf dem Server habt und ihr mal ein paar Tage auf das Löschen nicht referenzierter NLO verzichten könnt, dann ist das OK.

Übrigens, ich weiss nicht, wie ihr die Dbs auf den Server gebracht habt. Wenn das über das OS geschehen ist, dann kommt der daoscat auch aus dem Tritt. Auch, wenn man einfach eine Db im OS löscht ...

[Manni Ciao]

Einen schönen guten Morgen,

das Datenvolumen hat sich über Nacht wieder um 180 GB reduziert.
Die letzten DAOS Container die gestern noch 40.000 NLOs hatten, haben heute nur mehr 5-10 Files.

Mein Resümee:
Der plötzliche Anstieg von ~20% des Datenvolumens war durch einen aus dem Tritt gekommenen DAOS Cat. Verursacht wurde das durch eine Rücksicherung ohne NLOs von ein paar DBs über OS.

Unsere zukünftige Vorgehensweise:
Einen Server ohne DAOS betreiben. Dort die DBs vor dem Löschen ent-DAOS-ieren, sichern und auch dort bei Bedarf wieder rücksichern.

[eknori]

aus dem Tritt gekommenen DAOS Cat. Verursacht wurde das durch eine Rücksicherung ohne NLOs von ein paar DBs über OS

nachvollziehbar

Die letzten DAOS Container die gestern noch 40.000 NLOs hatten, haben heute nur mehr 5-10 Files

DAOSCat wieder in Sync; Prune Prozess ist gelaufen

das Datenvolumen hat sich über Nacht wieder um 180 GB reduziert.

Prune Prozess gelaufen.
Allerdings kann ich mir das Volumen immer noch nicht erklären.

[Manni Ciao]

Nein, der Prune Prozess läuft nur am Wochenende. Ich vermute, es waren temporäre NLOs deren Dateinamen doch nicht mit "P" enden.

[Pfefferminz-T]

Ein grosser Vorteil von DAOS ist doch u.a., dass die Laufzeiten für das Backup extrem reduziert werden. Das entsprechende Anpassungen am Backup (Backup-Datenbanken, Backup TL, Backup NLO) erfolgen müssen ist auch klar und dementsprechend muss auch der Restore durchdacht werden. Ich weiss nicht, wie alt der Stand dieser Datenbanken war aber mit einer langen Prune-Time kann man einen Restore der NLO-Dateien ausgleichen.

Eure geplante Backup-Strategie sehe ich als Rückschritt...

Gruß,
Thorsten

[Manni Ciao]

Ich habe hier nur die zu löschenden Mail-DBs der ausgetretenen Mitarbeiter gemeint. Oder auch andere zu löschende DBs, dass wir diese davor ent-DAOS-ieren.

[MCPvsTron]

Hallo,

Verursacht wurde das durch eine Rücksicherung ohne NLOs von ein paar DBs über OS.

Man kann es nicht oft genug wiederholen. NSF-Datenbanken sollten immer über die Notes API gesichert und restored werden. Jeder Backup Enterprise Anbieter hat einen Client hierfür im Programm.


Viele Grüße
Christian

[J Parlin]

PS. wie sichere ich denn "fehlende".NLOs zurück, das muß dann aber schon sehr geziehlt sein, oder ? Oder gibt es eine Art Diff ?

[Pfefferminz-T]

Da steht eigentlich alles drin:

http://www-10.lotus.com/ldd/dominowiki.nsf/dx/daos-backup-and-restore#Restoring+DAOS+objects

Zwei Phasen habt ihr:
- NLO-Objekte einer DB sind noch vorhanden (-> nur NSF wiederherstellen)
- NLO-Objekte einer DB sind aufgrund der prune-Time schon gelöscht (-> entsprechend der Beschreibung im Link verfahren)
Bei meinen Kunden habe ich Prune-Settings von 90-365 Tage, das wird in der Konzeption mit dem Kunden besprochen und festgelegt.

Gruss,
Thorsten

[Manni Ciao]

Nein, der Prune Prozess läuft nur am Wochenende. Ich vermute, es waren temporäre NLOs deren Dateinamen doch nicht mit "P" enden.

Sorry, Domino startet den Prune Prozess standardmäßig um 2:00 und ist auch nicht veränderbar. Am Wochenende machen wir einen Prune 40