"Datenbank ist zu groß geworden. Kompromieren Sie ..." + lässt sich nicht entf.

[Obrac]

Hallo, ihr...

Ich habe ein Problem mit meiner Maildatenbank, die wohl groß geworden ist. Sie liegt auf nem Notes-Server 9.01.
Das Komische an der Sache ist: Ich habe ein paar tausend Dokumente mit Anhängen auf eine lokale Kopie umgezogen und die Größe nimmt nicht ab. Es bleibt immer bei 65 GB.
Die zweite Seltsamkeit ist die, dass sich die Datenbank nicht aus dem Arbeitsbereich entfernen lässt. Wenn ich es versuche, wird behauptet, dass die DB geöffnet ist, was nicht der Fall ist. Neustart von Server und Client ändert nichts. Komprimieren ändert nichts.

Was tun?

[(h)uMan]

load compact -B [database name] reduziert die Dateigröße

Welche ODS Version hat denn die Mail-DB?
Ab ODS 53 kann eine DB größer als 64GB sein.
https://www.ibm.com/support/knowledgecenter/SSKTMJ_10.0.1/admin/wn_ods_53_supports_larger_databases_and_folders.html

[Obrac]

Ich habe schon versucht, die Dateigröße zu verringern, durch löschen von Dokumenten und komprimieren. Ich habe ca. die Hälfte der Dokumente umgezogen, aber die Größe ändert sich nicht. Ich denke mal, die DB ist beschädigt. Leider bringt aber auch ein Fixup nichts. Ich habe jetzt eine neue Mail-DB auf dem Server angelegt und kopiere die Ordnerinhalte nach und nach rüber. Mühsam ...

[J Parlin]

.. hattest du nun load compact -B [database name] auf der DB ausgeführt ?

[ronka]

Wenn der DB sich nicht von dein Arbeitsbereich lösen läßt, dann kannst du versuchen dein CLIENT zu beenden, und nach ein neustart das nochmal zu versuchen.

Wenn du "Mühsam" die inhalte zurück kopieren musstest, dann machst du etwas falsch. Der Replikator sollte das zu 100% für dich machen.

Weitere Fragen:
- Ist DAOS im einsatz ? (wenn nicht warum nicht ?)

Offene Fragen:
- Welches ODS wird (auf den Server) verwendet ?
- Ist "Load Compact -B [Pfad/dateiname.nsf] ausgeführt auf den Server ?

[Obrac]

.. hattest du nun load compact -B [database name] auf der DB ausgeführt ?

Nach meinem Verständnis entspricht der Befehl doch der normalen Komprimierung einer Datenbank, die man auch im Client vornehmen kann? Ja, das hatte ich schon versucht. Ich habe es jetzt über die Konsole angeschmissen und während des Prozesses verhält sich die Datenbank so, als wenn sie komprimiert würde.

- Ist DAOS im einsatz ? (wenn nicht warum nicht ?)

Nein, weil ich noch nie davon gehört habe.

Wenn der DB sich nicht von dein Arbeitsbereich lösen läßt, dann kannst du versuchen dein CLIENT zu beenden, und nach ein neustart das nochmal zu versuchen.

Das habe ich ohne Erfolg bereits versucht.

- Welches ODS wird (auf den Server) verwendet ?

Es ist die ODS-Version 43.

[tfrenz]

Hallo, wenn bei der DB noch ODS43 vorliegt, solltest du (vermutlich bei allen DBs) die ODS auf ODS52 anheben.
Das wird mit einem compact -c gemacht.
Wichtig vorher muss Create_R9_Database=1 gesetzt sein.
Dann erst den compact ausführen.
Gruß Thomas

[tfrenz]

Ach ja, was ich noch sagen wollte.
Um Mail-Dokumente von einer DB in eine andere zu kopieren habe ich den "Mail Merge" mir runtergeladen.
Da gibt man die Quelle, das Ziel, welche Dokumente kopiert werden sollen und einen Startzeitpunkt.
Dann läuft das ganze auf dem Server im Hintergrund.
Es wird auch die Ordnerstruktur mit übernommen (angelegt).
Es ist also alles so wie in der Quell DB.
Gruß Thomas

Jetzt habe ich auch den Link bei OpenNTF dazu gefunden.
https://openntf.org/main.nsf/project.xsp?r=project/Mail Merger/releases/FD30008ACE395517862577000063A719

[J Parlin]

... tu deinem DOMINO-Server mal was Gutes und schau dir den u.a. mal an: https://de.slideshare.net/BCCFFM/honey-i-shrunk-the-data-mehr-platz-am-ibm-domino-server

[ronka]

Also WENN der Datenbank auf den Server die 64 GB grenze überschritten hat (=vergangenheit) und du ODS 43 einsetzt, dann kann ich nur sagen das du "pech" gehabt hast, und einen neue Replik von dein Lokale Replik erstellen solltest auf den Server..

Aber das NACHDEM du DAOS aktiviert hast, UND ODS auf den aktuelle Stand gebracht hast.

Sonnst kann dir nichts mehr helfen diesen Datenbank wieder zu öffnen und verwenden zu können.

Und zu dein Verständnis.. der Client macht ein compact -b (achtung kleines b nicht grosses B), und damit was anderes. ABER wenn der DB schon zu groß ist, ist das völlig egal, dann wird dir keine option beim Compact helfen können.

[J Parlin]

Das Thema der "übergelaufenen", zu großen Datenbank mit Lösungsansätzen gab es hier doch letztens schon einmal.

Wenn er das Ding jetzt etwas unkonventionell mit Umkopieren retten kann, ist doch nur gut für ihn ( und seinen Erfahrungsschatz ) ...

Wenn er jetzt am System nicht weiter rumschrauben möchte / kann, dann ist das eben so.

Nur sollte man nochmal schauen, wann einem die nächste übergelaufene DB überrascht ...

[Obrac]

Danke für eure vielen Tipps, auch zur Vermeidung des Problems in Zukunft. Ich werde es mir zu Herzen nehmen.

Bei der Datenbank geht mittlerweile gar nichts mehr. RRV Bucket is corrupt. Ich weiß, dass das ziemlich aussichtslos ist. Leider fehlt mir ausgerechnet noch der Inhalt der Inbox, in der alle unbeantworteten Mails noch lagen. Ein Backup, das aktuell genug ist, um die eingegangenen Mails vom Wochenende zurückzuholen, habe ich auch nicht zur Verfügung.
nfixup, ncompact und nupdall haben auch nicht gebracht, es kommt immer wieder die RRV-Bucket-Meldung. Ich kriege die Kachel auch gar nicht mehr in den Arbeitsbereich, da vorher schon die Konsistenzprüfung fehlschlägt. Eine Replik ist so auch nicht mehr möglich. Habe die DB auch schon übers Dateisystem ins lokale Verzeichnis kopiert, aber auch dort kommt die Meldung beim Öffnen.
Fällt evtl. noch jemandem irgendwas ein, um doch noch an die Dokumente zu kommen?

[ronka]

Ohne einen Replik irgendwo bist du sicherlich weit weg von einen Rettung.. und auch einen 2 Wochen alte Datensicherung ist besser als keine.

Optionen: Kaum welche, in den letzte 4 monaten hatte ich 4 solche datenbanken beim Kunden..

3 davon waren NICHT zu retten, und sind mit 2 bis 14 tagen dokument verluste wieder aus einen sicherung geholt.

Nr 4 haben wir auf einen anderen weg "gerettet", welches bei den ersten 3 NICHT funktioniert hat.

Auch wenn es eher unwahrscheinlich ist, und sicherlich auch mit Potentiellen verluste geht.
Wechsel mal auf ein BLANKO template, damit alle Ansichten weg sind, und damit auch Ordner und restliche gestaltung.
DANN NICHT ÖFFNEN, sondern Fixup / Compact auf der Console mit entfernen alle ansicht indices.
Dann schauen ob der Client ran kommt, wenn das ohne fehler klappen sollte.

FALLS der DB dann zu öffnen WÄRE, als ersts dafür sorgen das die größte dokumente wo anders landen.
Dann der DB UNTERHALB von 60 GB bekommen, wenn möglich unter 50 GB

DANACH kann mann versuchen mit einen SICHERUNG der db noch etwas der Datenstruktur wieder ein zu fügen.

ABER ich rate dich weiterhin dich SEHR genau über DAOS zu informieren, das kann dir hier SEHR gut helfen dieses im Griff zu bekommen.

[Obrac]

@ronka: Ich werde es gerne versuchen, aber wie schaffe ich es, die Schablone zu wechseln, ohne die Kachel in den Arbeitsbereich zu bekommen?

[eknori]

An dr Server Konsole load convert mail\user.nsf * blank.ntf

[Obrac]

Danke, eknori. Leider gibt's bei der Operation als erstes eine Konsistenzprüfung, die direkt fehlschlägt. Wird also leider nichts mit der neuen Schablone.

[Obrac]

Da bin ich mal wieder

Ich habe wieder oder immer noch ein Problem mit der Maildatenbank, wenn auch kein akutes. Ich hatte jetzt eine Sicherung wieder eingespielt. Die Datenbank ist so wieder benutzbar, aber sie verhält sich immer noch komisch bzw. irgendwas stimmt nicht. Sie ist über 60 GB groß, aber noch nicht zu groß. Wenn ich Dokumente lösche, wird sie nicht kleiner und sie lässt sich nicht aus dem Arbeitsbereich entfernen, weil sie angeblich geöffnet sein soll, was nicht der Fall ist. Irgendwas stimmt mit der Datenbankstruktur nicht. Ein Fixup bringt aber auch keine Besserung.
Wenn ich eine lokale Replik anlege, ist diese 10 GB kleiner und sie lässt sich auch normal handhaben (inkl. löschen aus dem Arbeitsbereich etc.).  Gibt es einen administrativen Weg, die lokale Replik zur serverseitigen Version zu machen, ohne die Datenbank auf dem Server über das Dateisystem zu löschen? Das Problem ist, dass der Dateiname gleich bleiben muss, weil ich programmiertechnisch auf die Datenbank per Dateiname zugreife (ist auch nicht optimal, ich weiß).

[tfrenz]

Hallo, also as erstes die DB auf die zum 9.0.1 Server ODS anheben.
Am Server muss CREATE_R9_DATABASES=1 gesetzt sein in der Notes.ini.
-> set console CREATE_R9_DATABASES=1
Dann ein Copy-Style Compact machen. mit den Optionen, das Design compression, document compression und LZ1 attachment compression eingeschaltet wird.
Genau Infos: https://help.hcltechsw.com/domino/9.0.1/admin/tune_compactoptions_r.html
-> load compact -c -D -F -H -n -v -ZU dbname.nsf
Wenn der fehlerfrei durchgelaufen ist, sollte die DB auch am Sever kleiner sein.
Wenn nicht dann nochmal einen FIxup Full, Updall komplett durcführen.
-> load fixup -F dbname.nsf

Gruß Thomas

[eknori]

Wenn ich Dokumente lösche, wird sie nicht kleiner und sie lässt sich nicht aus dem Arbeitsbereich entfernen, weil sie angeblich geöffnet sein soll, was nicht der Fall ist.

Wie schon ein paar Mal gesagt; Löschen alleine reduziert nicht die Größe.
Und der Server denkt sich das nicht aus, dass die Db im Zugriff ist. Wird schon seinen grund haben. Kann man aber leicht herausfinden. Einfach mal ein Tool verwenden, das die File Handles anzeigt. Das zeigt dann auch den Prozess an, der die Datei im Zugriff hat.
Ich tippe auf den replicator task des Client.

load compact -c -D -F -H -n -v -ZU dbname.nsf

Ui, mal nicht gleich mit Kanonen auf Spatzen schiessen.

Ich würde zunächst einmal nach dem Löschen der Dokumente ein lo compact -B machen.
Das macht ein in-place compact mit reduzierung der Dateigröße

Wenn das nicht funktioniert wg. meldung über "Datei im Zugriff", dann kannst Du ein lo campact -REPLICA versuchen.
Das sollte Dir in jedem Fall eine neue Datei erstellen.

Problem wird sein, daß wenn die originale Datei im Zugriff ist, der compact task diese nicht löschen kann und auch die Umbenennung nicht funktioniert.
Da bleibt Dir nichts weiter übrig, als den Server neu zu starten. danach benennt der Compact task die datei um.

Du sagst, du hast eine lokale Replik. Gut. Dann würde ich persönlich, den Server runterfahren, die Datei auf dem Server löschen, im Client die notwendigen Bereinigungen vornehmen, und dann eine neue Replik vom Client aus anstossen.

Es gibt hier viele Möglichkeiten.

[Obrac]

Danke schonmal, euch beiden. Ich bin jetzt generell schlauer und habe mich sicherlich geirrt, was die vermeintliche defekte Datenbankstruktur anbelangt. Gestern Abend habe ich noch eine Komprimierung über die Konsole angeworfen. Danach war die Datenbank nur noch 50 GB groß. Dass sie sich nicht aus dem Arbeitsbereich entfernen lässt, ist wohl auch, wie eknori richtig bemerkt hat, nichts Ungewöhnliches.

Was ich noch nicht verstanden habe: Müsste man beim Anlegen einer Replik nicht die maximale Größe hochsetzen können? Diese Option finde ich allerdings beim Erstellen der Replik nicht.