Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: RZLT am 02.08.10 - 09:40:17
-
Hallo Zusammen,
folgendes Problem.
In unserem Domino-Mailcluster tritt auf einem Server und nur in einem Mailverzeichniss das Phänomen auf, das die Mailfiles erhebliche Größenunterschiede zu der entsprechenden DB auf dem anderen Server aufweisen.
Mittlerweile habe ich herausbekommen, das es an den Ansichtsindizies liegen muss, die sich auf dem Server ständig aufblähen.
Als kurzfristige Lösung habe ich einen compact -D auf dem entsprechenden Verzeichniss durchgeführt, was aber zu keiner dauerhaften Lösung führte.
Hat jemand noch einen Tip um das Problem dauerhaft zu lösen, Danke.
-
Was ist daran ein "Problem"? Zu einer benutzten Notes-Datenbank gehören natürlich die Ansichtsindizes! Ein Auto könnte man auch leichter machen, in dem man die Räder abschraubt oder den Motor ausbaut, aber herrjeh ...
Und wenn man die Ansichtsindizes programmatisch wegwirft, so werden diese bei der nächsten Benutzung wieder aufgebaut - was zu einer Geduldsprobe werden kann und den Domino belastet.
Bernhard
-
Oh, hab ganz vergessen das Problem ja noch zu beschreiben.
Da wir eine sehr strikte Quotaregelung betreiben, kommt es laufend zu Quotaüberschreitungen da die Datenbanken teilweise doppelt so groß sind wie die entsprechende Replik.
compact -D bringt nur kurzfristig eine Besserung, am nächsten Tag ist die DB plötzlich wieder "explodiert", neue Replik bzw. Kopie bringt rein gar nichts.
-
Wenn "man" bei der Quotaregelung die Ansichtenindizes nicht berücksichtigt ...
-
Eigentlich bin ich auf der Suche nach ner Lösung, damit ich das Problem von der Backe bekomme, und keine Aufkläruing was ich Organisatorisch hier im Haus umstellen sollte. Auf das kann ich verzichten.
Wie kann das sein, das die Indizies auf einem Server "explodieren" und auf dem anderen nicht?
Wie kann ich das beheben, ausser täglich nen compact -D laufen zu lassen.
-
Sie "explodieren", weil die Leute die Datenbanken auf dem einen Server benutzen und daher die View-Indizes für sie angelegt werden.
Lösen kannst Du das
a) indem Du den Leuten verbietest, auf dem Server zu arbeiten
b) indem Du die Limits hinauf setzt.
-
und warum passiert das nur in einem von 10 Mailverzeichnissen und nur auf einem Server im Cluster?
Wenn das in den anderen Mailverzeichnissen ebenso der Fall wäre, dann hätte ich ja kein Problem damit, aber nein, es passiert nur in einem Verzeichnis.
Auf den anderen DB´s in den Verzeichnissen wird auch gearbeitet und dort habe ich das nicht.
Der Cluster ist so eingerichtet, das ca. die Hälfte der User den einen Clusterserver als Homeserver haben, die andere Hälfte liegt auf dem gegenüber.
-
Na die ViewIndices werden nur auf dem Server aufgebaut auf dem die user arbeiten.
Übrigens finde ich nicht, dass Du hier rumpflaumen solltest, schliesslich wird dir umsonst geholfen und hier kann keiner etwas für Dein Problem.
Grüße David
-
Lass doch einfach mal auf beiden Nodes die Indizes aller Mail-DBs mit updall aufbauen. Danach machst du einen compact -B und schaust, ob auf beiden Nodes die DBs gleich groß sind. Wenn das der Fall ist, dann weißt du, dass kein technisches Problem vorliegt :)
-
Verstehe ich das richtig? Auf dem einem Cluster passiert das, bei dem anderen aber nicht?
Hast Du mal verglichen, ob die gleichen Mainanance Programme (compact ect.) auf beiden Servern laufen?
-
Genau, richtig verstanden.
Programmtechnisch läuft jeden Sonntag ein Updall -R -X und jeden Mittwoch und Samstag ein compact -B. Der Größenunterschied ist trotzdem vorhanden.
Der Compact läuft deswegen am Mittwoch und Samstag, da wir an diesen Tagen unsere TSM-Sicherung am laufen haben.
Das einzige was mir einfällt, wäre den Updall auf Freitag zu verlegen.
-
Nur damit wir hier da mal so eine Vorstellung bekommen:
Von welchen Grössen reden wir hier? Was ist denn der Unterschied zwischen Server A / B?
P.S: Der Compact läuft bei mir täglich....
-
Wir sprechen in Einzelfällen von bis zu 50 MB Größe der Ansichtsindizies.
Der Compact -B komprimiert in diesen Fällen gar nix, nur bei Compact -D wird ordentlich komprimiert, da die Indizies gelöscht werden. Die sind dann am nächsten Tag bzw. am selben Tag in alter Frische wieder da.
-
50 MB Ansichtsindex sind doch gar nichts.
Ich kenne Anwendungen mit mehreren GB Ansichts-Index.
Also wenn 50 MB das Problem sind, dann solltet ihr das denke ich schon organisatorisch lösen.
Ich sehe folgende Möglichkeiten:
- Quota hochsetzen (wie groß ist das eigentlich)
- Archivieren
- DAOS aktivieren
- Zentrale Ablage wichtiger Emails in einer gemeinsamen DB, damit dann evtl. mehrere an diese Infos kommen.
Unseren Kunden rate ich in den meisten Fällen zu Letzterem, denn nur so hat das In-House-Spammen mit CC und BCC an alle nur irgendwo beteiligten ein Ende.
Grüße David.
-
Die Quotas sind Standardmäßig auf 100 MB.
Wobei wir je nach Aufgabengebiet auch andere Quotas (bis zu 1 GB) zur Verfügung stellen.
Das Archvierungsprojekt wird seit Jahren auf die lange Bank geschoben, DAOS gibts ja erst mit 8.5 und wir sind erst diese Jahr auf 8.02 gegangen.
Stellenweise reden wir auch von 50 + X MB der Ansichtenindizies.
-
100 MB, das könnt ihr doch nicht machen.
Bei 8.5 ist alleine das Template um die 30 MB groß (8.0.2 weiß ich grade nicht, wird aber ähnlich sein)
Bleiben also 70 MB für Dokumente + Ansicht-Indices.
Das reicht heutzutage niemanden mehr denke ich
-
90 % unserer User kommen mit 100 MB aus, SAN-Platz ist teuer, mein HW-Budget für dieses Jahr ist ausgeschöpft.
Das Template bei 8.02 hat ca. 25 MB, mit Gestaltungskomprimierung, LZ1 und Dokumentdaten komprimieren pendelt es sich bei ca. 10 MB ein.
Ist also nicht größer als vorher mit SCT.
Es geht mir ja nicht um die Quotas, sondern um die Problematik, das nur in einem Mailverzeichnis von insgesamt 10 Stück die Mail-DB´s "explodieren".
Werd dann mal bei IBM schnorcheln gehen.
-
100 MB, das könnt ihr doch nicht machen.
Da muss ich atbits recht geben. 100MB geht ja gar nicht - allerhöchstens wenn ein Archivierungssystem alles wegarchiviert...
-
Wenn ich jetzt wieder schreibe, das ich ne Problemlösung suche und keine Hinweise auf Organisatorisches haben will, dann "pflaum" ich ja wieder rum. ::)
-
Werd dann mal bei IBM schnorcheln gehen.
Grenz erst mal das Problem ein, so dass du weißt WAS diesen Größenunterschied ausmacht. Indizes, Dokumente, Gestaltungselemente, etc. Haben die Repliken die selben Einstellungen was Komprimierung der Gestaltung bzw. Anhänge angeht? Und, und, und... Wenn du das nicht eingrenzt, wirst du dazu sicher nichts sinnvolles finden =)
Edit:
Um es neutral auszudrücken: Zynismus und aggressive Rhetorik sind nie förderlich.
-
Wenn ich jetzt wieder schreibe, das ich ne Problemlösung suche und keine Hinweise auf Organisatorisches haben will, dann "pflaum" ich ja wieder rum. ::)
Na ja, man kann eben nicht immer einen organisatorischen Fehler technisch lösen... :-:
Und die 100Mb sind in heutigen Zeiten eben grenzwertig....
-
Die Einstellungen aller DB´s sind gleich.
Und für mich liegt ein technischer Fehler vor, wenn von 10 (ich weis ich wiederhole mich) Mailverzeichnissen auf 1 Server eines explodiert und die anderen 9 davon nicht betroffen sind.
-
Ja, aber 50 Mbyte ist keine Explosion, es würde noch nicht einmal für einen pups ;) reichen.
Hat Du mal im Vergleich zu den anderen die Anzahl der Odner verglichen?
-
Wenn schon unterschiedliche Verzeichnisse verwendet werden: Unterscheiden sich den diese Mail-DBs prinzipiell von denen in anderen Verzeichnissen?
Prinzipiell gilt (bei gleicher DB-Grösse): Wenige (grosse) Dokumente - kleine Indizes, viele (kleine) Dokumente - grosse Indizes.
Bernhard
-
Nein, nur anhand der Bezeichnung. Die DB´s werden anhand der Personalnummer 1-9999 auf die verschiedenen Mailverzeichnisse aufgeteilt.
-
Naja und die sonstigen Unterschiede?
Wieviele Mails, Kaldendereinträge, etc. (Dokumente) sind in der mit großem Ansichtsindex wieviele in der mit kleinem?
Welche View ist so groß? Kann man im Admin-Client nachschauen.
Verwenden die User mit den großen DB's viele Ordner.
Wir brauchen schon mehr Input.
David
-
Die Indizes gelten je Replik. Die Frage wäre also, wie der Cluster bei euch arbeitet. Greifen evtl. die betroffenen User nie auf den anderen Cluster-Member zu ? Dann würden dort auch nie die Indizes aufgebaut oder aktualisiert.
-
Die Größe der Ansichten kann man auch mit dem Admin-Client sehen und verwalten:
DB markieren -> Werkzeuge -> Datenbank -> Ansichten verwalten ( oder rechte Maus )
Hier können auch einzelne Ansichtsindizes gelöscht werden.
gruß, Steffen
-
Wieviele Mails, Kaldendereinträge, etc. (Dokumente) sind in der mit großem Ansichtsindex wieviele in der mit kleinem?
Welche View ist so groß? Kann man im Admin-Client nachschauen.
Verwenden die User mit den großen DB's viele Ordner.
Auch das ist unterschiedlich, hab jetzt 14 User identifiziert die mehr als 100 Ordner haben, einer ist dabei mit knapp 600!!.
Andere haben 5 Ordner und wenige Dokumente. Läßt sich also schwer eingrenzen.
Hab mir jetzt mal ein Testopfer gesucht und den compact -D auf Homeserver und Replikserver bei dem abgesetzt.
Bisher lief der nur auf dem Homeserver.
@driri: Die User arbeiten zu 98% auf dem Homeserver, die Replik wird also kaum verwendet (stabiles System, oder).
-
@driri: Die User arbeiten zu 98% auf dem Homeserver, die Replik wird also kaum verwendet (stabiles System, oder).
Na ja, Du hast wohl auch kein "Load Balancing" aktiviert, dann kommen die User ja erst beim "Failover" auf den anderen Server ... wohl Stabil, aber nicht unbedingt performant ...
Gruss,
Joachim
-
Muss ich ja auch nicht unbedingt, da der eine Mailserver für Vertriebsmitarbeiter und der andere als Homeserver für Stabsmitarbeiter ist aufgeteilt auf 2 Standorte. Das bedeutet, das jeweils 50 % der User auf einem Server liegen und die Repliken jeweils auf dem anderen.
Aber back to Problem.
Langsam bekomm ich es in den Griff. Hab gestern mal Testweise den compact -D auf BEIDEN Datenbanken ausgeführt und bisher ist die DB in dem betroffenen Mailverzeichniss stabil.