Probleme mit Mail-DB-Performance nach Wechsel zu neuem Certifier

[max.power]

Hallo Leute,

ich hab da ein großes Problem und leider keine Ahnung, was die Ursache ist und was ich dagegen machen kann (zum Glück befinde ich mich noch in der Testumgebung - aber wenn das Problem auch in Produktion auftritt...  ):

Leider hat sich unser Firmenname geändert, wodurch alle User auf einen neuen Certifier verschoben werden müssen. Neuanlage cert.id, Gegenzertifizierung und Verschieben der User soweit kein Problem (alles in einer Testumgebung - also 1:1 Kopie des Servers und der Clients in einem eigenen, physischen Netz - dass da ja nix in die Produktion repliziert  )
Wenn jetzt einer der umbenannten User zum 1. Mal sein Notes startet, so wird ja die Namensänderung in der admin4.nsf fortgesetzt - und auch erfolgreich abgeschlossen. Aber: Das Öffnen der Mail-Datenbank dauert - ja: ewig.
Soll heissen: Vor der Umbenennung dauert es ein paar Sekunden, bis die Mail-DB offen ist, nach der Umbenennung dauert's bis zu 15(!) Minuten(!). In der Zeit blinkt der Blitz links unten wie verrückt und im Taskmanager erkennt man auch, dass viel Netzverkehr erzeugt wird.
Wenn mal die DB offen ist, geht alles wunderbar. Andere Datenbanken machen das Problem nicht.

Ich hatte das Problem schon mal beim Ändern des allg. Namens (wegen Heirat z.B.) - doch da war der Fehler, dass in der ACL nicht "Alle Leser- und Autorenfelder ändern" ausgewählt war - was hier aber definitiv korrekt auf allen DBs gesetzt wurde.
Abhilfe war dann nur mehr eine neue Replik der Mail-DB... nicht auszudenken, wenn ich das dann bei rund 400 Usern machen muss 

Hat irgendjemand Erfahrung mit dem Verschieben von Usern auf einen neuen Certifier?
Ich seh' auf jeden Fall, dass alle Prozesse in der admin4.nsf vollständig abgeschlossen sind, die user.ids die richtigen neuen Namen haben und die Owner richtig gesetzt sind.

Es scheint irgendwas mit den "neuen" user.ids zu haben, denn das Öffnen dieser DBs mit jeweils einem anderen User zeigt keine Performanceprobleme 

Achja: Server 6.0.2CF2 Englisch, Clients 6.0.1CF1 Deutsch.

Leicht ratlos und für jeden Tipp dankbar,
Max

[MartinG]

Ich hatte so ein ähnliches Problem auch kürzlich - da war das Problem das die Userin geheiratet hatte und der neue Namen jetzt ein Umlaut hatte...

Hast Du nur einen User getestet oder mal mehrere?

Gruss
Martin

[max.power]

Hallo Martin,

ja, mittlerweile habe ich 5 User auf den neuen Certifier verschoben - bei einem der 5 tritt der Fehler seltsamerweise nicht auf, ich kann aber keinen Unterschied zu den anderen 4 erkennen.

Allg. Frage: Macht eigtl. die Einstellung "Alle Namensfelder ändern" mehr "Sinn" als "Alle Leser- und Autorenfelder ändern"? Bzw. bei welchen Datenbanken sollte man welche Option in der ACL wählen?

Achja: Und wie konntest Du den Fehler beheben? fixup? compact? Neue Replik?

LG,
Max

[MartinG]

Achja: Und wie konntest Du den Fehler beheben?   

Ich hab das ganze abgebrochen und noch ein, zwei Änderungen dann manuell nachgezogen...

Achja: Und wie konntest Du den Fehler beheben? fixup? compact? Neue Replik? 

Glaube eigentlich nicht das es an einem Problem mit der Datenbank liegt, wechselst Du bei der Sache auch den Server? Wenn ja dann vermute ich das Problem eher aus der Ecke Verbindungsdokumente.

Das andere was mir einfällt - hast Du in Deinem Testnetz auch einen DNS-Server? Nicht das es ein Netzwerkproblem ist und Du auf Notesseite den Fehler suchst...

[max.power]

Ich hab das ganze abgebrochen und noch ein, zwei Änderungen dann manuell nachgezogen...

Hmm, wie und was hast du abgebrochen und welche Änderungen manuell nachgezogen?
Sorry für meine Neugierde  , aber evtl. helfen diese manuellen Änderungen auch bei meinem Problem...

In meinem Testnetz gibt's keinen DNS, die IP-Adressen habe ich direkt in die HOSTS geklopft.
Bevor ich einen User auf die neue Organisation verschiebe, ist die Zugriffszeit beim Öffnen der Mail-DB ja noch normal (ein paar Sekunden zum Öffnen) - erst wenn der User seinen neuen Namen hat, bröselts 

Hat nicht zufällig jemand auch eine Testumgebung und kann mein Problem nachstellen? Das wäre für mich ja das Allerschönste 

[MartinG]

Habs ganz normal abgebrochen mit STRG + PAUSE...

[max.power]

Achso, das Öffnen hast Du abgebrochen. Ich dachte, den Umbenennungsprozess.
Aber mich interessiert jetzt schon noch, was deine "ein, zwei Änderungen" waren 

Ja, weil Du gemeint hast, dass es auch was mit Verbindungsdokumenten zu tun haben könnte: Der Servername (also die Organisation) ändert sich nicht, bleibt vorerst alles beim alten. So möchten wir das auch dann in Produktion machen, dass wir erst dann den/die Server umbenennen, wenn alle User den neuen Namen haben.

[Andy B]

Hallo

hatte das Proble auch soch mei der Umbenennung einer Person. Das öffen der Db dauerte sehr lange. Habe dort auch festgestellt das wenn der User die Mail DB öffnen ca. 150MB zwischen Server und Client übermittelt werden, das was ca die ganze Mail-DB.
Lösung
User noch einmal Umbenennen und dann war alles wie es sollte.

Wird Dir nicht direkt Helfen aber könnte zur Löung beitragen.

Gruss
Andy

[MartinG]

Nur eine Vermutung:  es könnte damit zu tun haben wenn es in der Datenbank verschlüsselte Dokumente (Mails gab) das diese dann alle nochmals angefasst werden....

[max.power]

@Andy:
Nochmals umbenennen... also nochmals auf einen anderen Namen und dann zurück auf den richtigen neuen? Oder hast du die admin4.nsf bearbeitet, damit der komplette Umbenennungsprozess nochmals durchläuft?

@Martin:
Vielleicht blöde Frage, aber: Wie kann ich (möglichst schnell und einfach) feststellen, ob in einer Mail-DB verschlüsselte Mails sind? Evtl. hat es ja wirklich was damit zu tun und wie gesagt: Bei einem User tritt das Problem ja nicht auf - und ich kann einfach nicht erkennen, was bei dem anders ist.

[tttonic]

@all

also ich glaube nicht das dieses etwas mit Verschlüsselung zu tun hat. Ich musste hier bei uns alle MA umbennen. Mir fiel auf das es schneller geht wenn man die DB nach der Umbennung neu signieren läßt. Da stehen bei allen MA bei der Ordnerstrukur der alte Name drin, und anscheinend führt das zu unwahrscheinlich viel traffic.

[max.power]

Ah, Ordner... danke, das werde mal ausprobieren, melde mich dann morgen.
Wäre ja geil, wenn es das ist 

[max.power]

@tttonic:

DANKE!! Genau das war's! Alternativ zum Signieren der Ordner kann auch der User selbst 1 x "Ordnergestaltung aktualisieren" aufrufen, damit bei den ganzen Ordnern bei "geändert von" der neue Name steht - dann passt die Performance beim Öffnen wieder!!

Leider greift der adminp diese Ordner beim Umbenennen nicht an 

Danke an dich und natürlich auch an alle anderen!! 

Jetzt geht's mir besser 
Max

[Velocy]

@tttonic

DIR fiel auf???

*grummel*

@max.power

Wie tttonic sagte trat das Problem bei uns auch auf. Der AdminP würde das ganze schon angreifen, doch wenn du mit dem Designer in die DB schaust, wirst du sehen, dass hinter jedem Ordner "Keine Aktualisierung" anghakt ist. Wenn man dieses Häkchen entfernt, greift auch der AdminP, allerdings kannst du dir das sparen, denn sobald du das Häkchen entfernst, signierst du die Ordner mit deinem eigenen Namen neu, was mehr oder weniger den gleichen Effekt hat (vorausgesetzt deine ID wurde schon neu zertifiziert).

Das Problem tritt auch nur auf, wenn der User eine Datenbank öffnet, in der er selbst mit seinem alten Namen in der Ordnergestaltung drin steht.

Ich hab das ganze mal mit einem User gemmonitort... wir haben den Notes Client gestartet, die Mail-DB geöffnet und dann in den Kalender gewechselt. Die 3 aktionen verursachten 50 MB traffic... da freuen sich die ISDN User

Aus irgendwelchen Gründen hinterfragt er ständig beim Serveradressbuch, wer dieser Ordnerbesitzer ist. das verursacht den imensen Traffic.

[Onkel ToM]

Aus irgendwelchen Gründen hinterfragt er ständig beim Serveradressbuch, wer dieser Ordnerbesitzer ist. das verursacht den imensen Traffic.

Die Gründe sind: Benennt man Personen um (egal ob allg. Name oder Org) kann angegeben werden, wie lange der alte Name noch akzeptiert werden soll - daher kommen die ständigen Fragereien.
Wenn die 42 Tage um sind gehts wieder schneller 

Schönen Abend

Onkel ToM

[max.power]

@Velocy:

Deinem Kommentar entnehme ich, dass sich tttonic mit fremden Federn geschmückt hat? 

Danke für den Tipp mit dem "Keine Aktualisierung", dass ich das ja eigtl. auch mit meiner (Admin-) ID machen kann. Würde dem User am nächsten Tag nach der Umbenennung eine Menge Nerven sparen (mir halt nicht, weil ich das dann bei allen Usern machen müsste, die eigene Ordner haben  ).
Aber: Kann es nicht zu Problemen kommen, wenn die Ordner meinen Namen tragen?

@Onkel ToM:
Wenn das die Ursache ist - spricht was dagegen bzw. kann es zu Problemen kommen, wenn man als Option "0" eingibt?!

--> werde auf jeden Fall beides in der Testumgebung durchspielen.
Danke euch beiden! 

[tttonic]

@Velocy:

Deinem Kommentar entnehme ich, dass sich tttonic mit fremden Federn geschmückt hat? 

Wir beiden arbeiten in der gleichen Firma, deshalb hätte es villeicht nicht "mir" lauten müssen. Habe ich allerdings nicht so geschrieben, weil einfach nicht daran gedacht.

[tttonic]

Aus irgendwelchen Gründen hinterfragt er ständig beim Serveradressbuch, wer dieser Ordnerbesitzer ist. das verursacht den imensen Traffic.

Die Gründe sind: Benennt man Personen um (egal ob allg. Name oder Org) kann angegeben werden, wie lange der alte Name noch akzeptiert werden soll - daher kommen die ständigen Fragereien.
Wenn die 42 Tage um sind gehts wieder schneller 

Schönen Abend

Onkel ToM

Stimmt nur teilweise,

wenn ich als Dauer 0 eingebe dauert es auch noch etliche Tage. Auch mit Einstellung 1 ist es nicht besser.

[knoedel0815]

Habe nicht alle Kommentare durchgelesen, aber hast Du schon den Arbeitsbereich komprimiert?

[Onkel ToM]

Wenn die 42 Tage um sind gehts wieder schneller 

Stimmt nur teilweise,

wenn ich als Dauer 0 eingebe dauert es auch noch etliche Tage. Auch mit Einstellung 1 ist es nicht besser.

Ist das verifiziert? Wenn die Zeit um ist gibts ja keinen Grund mehr.
Haben die Ordner ein $Readers? Ansonsten ist es ja egal wer da auf den Ordner zugreift, er darf ja lt. ACL ja in die DB.

Bye
Torsten