Transactionlogs analysieren

[aes]

Hallo,

haben einen 6.5 Server auf Win2k SP4. Der Server hat archival-Transactionlogging aktiviert. Die Transactionlogs dienen dem Backup mit einem Tivoli Backup Client & Server. Die Sicherung klappt auch.
Heute begann der Server um 9 Uhr plötzlich damit ca 120MB/Minute an Transactionlogs zu schreiben. Bis eben 15 Uhr insgesamt knappe 60GB. Üblich waren bisher ca. 120 MB/Tag! Die Gesamtgröße aller Datenbanken im selben Zeitraum hat sich kaum verändert (wenige MB). Wir konnten leider nicht erkennen wer dies verursacht hat. Besondere Nutzer- bzw. Datenbankaktivitäten waren nicht erkennbar. Auch nicht in der log.nsf oder auf der Console. Gleichzeitig stieg jedoch die CPU Last deutlich von durchschnittlich wenigen Prozenten auf druchschnittlich 40% an. Der Task Schedule-Manager (nsched.exe)  in der Taskliste meldete am Ende ca 63% an CPU-Last.
Da wir nun ratlos sind woher dieses Verhalten kommt, kamen wir auf die Idee vielleicht Informationen aus den Transaction-Log-Dateien zu den vorgefallenen Transaktionen selbst zu ziehen. Leider sind die jedoch nicht lesbar.
Hat irgendwer eine Idee, was passiert sein könnte, bzw. wie sich aus den Transaction-Log Dateien Informationen zu den Transaktionen bzw. betroffenen Datenbanken ziehen lassen.

Freundliche Grüße
A.Sexauer

[aes]

Ein Neustart des Domino-Servers (nicht der Maschine) hat naqch wenigen Minuten zu einer Beruhigung gefürt. Momentan schreibt der Server nicht mehr jede Minute 120 MB Log-Dateien und die CPU ist vorerst wieder ruhig. Mal sehen wann das Problem wieder auftritt.

[m3]

Habt ihr ev. ein "compact" gemacht?

When you enable transaction logging, Domino assigns a unique database instance ID (DBIID) to each Domino database. When Domino records a transaction in the log, it includes this DBIID. During recovery, Domino uses the DBIID to match transactions to databases.
Some database maintenance activities, such as using the Compact command with options, cause Domino to reconstruct the database in such a way that old transaction log records are no longer valid. When this happens, a new DBIID is assigned to the database. From that point on, all new transactions recorded in the log for that database use the new DBIID. After a database is assigned a new DBIID, take a new full backup of the database. The new full backup captures the database in its current state with the new DBIID. Then, if you have to restore the database, Domino needs only the new transactions that contain the new DBIID.

[Gandhi]

Ein Compact sollte sich auf das TLog nicht auswirken - da dabei ja keine Dokumente verändert werden.
Lasst ihr die log.nsf loggen - sollte man wegen Last eigentlich nicht.
Der Verdacht liegt nahe, dass der Schedule Manager wild geworden ist (oder längere Zeit nicht gelaufen ist). Ihr solltet daher die DBs überprüfen, die dieser Task anfasst...

[aes]

wir wissen jetzt zumindest, wie der Fehler reproduzierbar ist.
Das Problem tritt jedes mal auf, wenn ein Mitarbeiter von extern via Outlook-Connector seinen Cassiopeia zu synchronisieren versucht. Die Sychronisation wird über eine ansonsten schwach ausgelastete 2Mbit Leitung bei einer 200MB Mail-Datei auch in 6 Stunden noch nicht fertig, wir brechen diese jetzt erst mal ab und überlegen, was wir noch tun können.
Kennt jemand eine bessere Lösung als den Outlook Connector für den Cassiopeia.

Grüße
Andreas

[aes]

problem gefunden und gelöst.
Ursache war die sammlung der busytime in der busytime.nsf. Der User hatte auf dem PDA Geburtstage eingetragen, die als Termine mit 1000 Wiederholungen mehrfach synchronisiert wurden. Pro Geburtstag gab es nach dem Sychronisieren im Notes-Mail-File mehr als 4 Einträge pro Geburtstag mit jeweils 1000 Wiederholungen. (Ob der Nutzer diese Geburtstage wohl noch erlebt, aber vielleicht wird der PDA oder Mailfile auch an die Nachfahren verererbt, die dann Blumen an die passenden Ruhestätten bringen) Ergebnis der Nutzer hat 100000 Termine in seinem Kalender. HILFE!!
Als Ergebnis bekommt der Schedule-Task beim Updaten dieser Person in der busytime.nsf ganz langsam die Krise. Das Dokument für diese Person in der busytime.nsf wächst und wächst, dieses jedoch auf moderate wenige MB. Allerdings führt wohl eine Hinzufügen eines weiteren Termins zu einer fast kompletten Änderung an des Dokuments, ergo landen pro Eintrag jedes Mal fast die gesamte Datenmenge des Dokumentes im Transactionlog. Ein Vergleich der in einem Zeitraum durch den Schedule-Task bearbeiteten Events und der im gleichen Zeiträume angelaufenen Datenmenge im Transactionlog scheint dies zu bestätigen.
Workaround ist bei uns erst einmal das Transactionlogging für die busytime.nsf zu deaktivieren. Leider ist es schwer den Nutzer nachhaltig zu zwingen, seine Termine in Ordnung zu halten. Entlastet nur die HD aber leider nicht die CPU.
Ich habe in der busytime.ntf eine Maske "LocalScheduleSettings" gefunden, mit der scheinbar Werte für sinnvolle Zeiträume in denen die Busytime verwaltet werden soll vorgegeben werden können. Leider habe ich nicht gefunden, wo man das zugeörige Settings-Dokument erstellt. Kann mir da wer weiterhelfen?
Grüße
Andreas

[NetteXL]

Hallo!
Die Maske "LocalScheduleSettings" ist für mobile Anwender gedacht. Man kann im Client auf der Replikatorseite einstellen, für welche Personen und welchen Zeitraum Informationen in die lokale Busytime.nsf repliziert wird. Auswirkungen auf die Busytime.NSF am Server sind mir nicht bekannt.

Grüße
Annette