Regelmäßig schlechte Performance einer Datenbank

[Don Olli]

Hi Forum,

bei einem Kunden gibt es eine Datenbank, die über mehrere Server verteilt liegt.
In schöner Regelmäßigkeit (ein paar Monate) wird die Performance zunehmend schlechter bis teilweise unerträglich. Wir können das Problem "beheben", indem wir zu gegebener Zeit alle Repliken auf allen Server löschen und eine neue Replik wieder auf alle Server verteilen. Durch diese Maßnahme wird die Performance wieder sehr deutlich angekurbelt. Damit haben wir wieder ein paar Monate Ruhe, bis wir dieses Spiel von Neuem durchführen müssen.
Wie Ihr Euch vorstellen könnt, ist das nicht recht befriedigend.
Diverse Versuche die Deletion Stubs und Profildokumente via Ytria ScanEZ zu bereinigen und so die Performance anzukurbeln, bringt bisher leider nicht den gewünschten Erfolg.
Die typischen Prozesse wie Updall, Compact, Fixup sind auf den Servern entsprechend eingerichtet.

Daher meine Frage:
Kann sich jemand vorstellen, was beim Erstellen und Verteilen einer neuen Replik geschieht, was jedes Mal einen so deutlichen Performancegewinn mit sich bringt?
Und hat jemand eine Idee was ich noch versuchen könnte, um dieses ewige Spiel der Verteilung einer neuen Replik beenden?

Schonmal besten Dank für Eure Ideen!
Cheerz!
Olli

[WernerMo]

Hallo Olli

Kann sich jemand vorstellen, was beim Erstellen und Verteilen einer neuen Replik geschieht, was jedes Mal einen so deutlichen Performancegewinn mit sich bringt?

Da fallen mir ein:
- Datei ist nicht fragmentiert
- Index wird neu erstellt
- ?Ungelesenmarkierungen?

Zusätzlich wäre sehr interessant,
wie die "Typischen Prozesse" (opitionen) aktiviert sind.
Gibt es keinerlei Meldungen wenn das Problem auftritt
Ist ein Cluster "im Spiel"?
Wie werden die neuen Repliken angelegt (manuell oder AdminP)?

Gibt es mehr Infos zu der DB (Größe Anzahl Dokumente etc)

Gruß Werner

[Don Olli]

Servus Werner,

Ungelesenmarkierungen werden in der DB generell keine verwaltet.
Was genau meinst Du mit "Datei ist nicht fragmentiert" und "Index wird neu erstellt"?
Nachdem die Repliken neu verteilt wurden, wird auch der Index neu erstellt.
Verteilt werden die Datenbanken manuell, nicht über den AdminP.

Es ist sowohl ein Cluster im Spiel, als auch weitere Server auf denen Repliken liegen.
Meldungen kommen in der Tat keine im Log. Wie gesagt taucht dieses Problem nicht über Nacht auf, sondern verfestigt sich im Laufe der Zeit immer mehr.
Es sind um die 65.000 Dokumente in der Datenbank.

Hier die Befehle, welche auf die Datenbank abgeschossen werden:
Load fixup Pfad\DBName -f
Load compact Pfad\DBName -i -c -d -K
Load compact Pfad\DBName -B
Load updall Pfad\DBName -R
Load updall Pfad\DBName -X

Danke für die Hilfe!
Cheerz!
Olli

[Don Olli]

Hi Forum,

ich möchte diesen Thread nochmal aktivieren.

Ich habe per Notes Client Clock mal ein Debug Protokoll erstellen lassen. Dabei fällt auf, dass viele Operationen vom Typ PROFILE_ENUM_RQST durchgeführt werden, bei denen deutlich zu viel Zeit liegen bleibt.
Frage: Kennt das jemand? Weiß jemand damit umzugehen?

Vielleicht passend dazu habe ich im Code getProfileDocument Aufrufe lokalisiert, bei denen offensichtlich die Zeit liegen bleibt.

Läutet da irgendwo was?

Bin für jeden Hinweis dankbar!

Cheerz!
Olli

[ata]

... getProfileDocument bedeutet, daß mit Notes Profilen gearbeitet wird. Wieviele sind denn angelegt? Habe ihr die Profile schon mal analysiert? Sind die wirklich notwendig?

Ist es eine Standardanwendung - als aus einer Mailschablone oder ähnlichem gezogen?
Ist es eine Mail-DB? Wenn ja, wieviele Dokumente sind in der $Inbox?

Das wären so die ersten Dinge, nach denen ich schauen würde...

Toni

[m3]

Kein Volltextindex erstellt und FT-Suchen in der Anwendung?
Views mit @Now drinnen, ...?

Viele PROFILE_ENUM_RQST Aufrufe sollten kein Problem sein, solange sie nicht lange dauern. Ich würde eher mal nach "langen" Aufrufen ausschau halten.