Domino 9 und frühere Versionen > ND9: Administration & Userprobleme

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

(1/4) > >>

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.

Navigation

[0] Themen-Index

[#] Nächste Seite