Recovery Manager: LogFile is full

[mcilly]

Hallo zusammen!

Unter eines schönen Tages riefen plötzlich unsere User an und meinten beim Versenden von Mails kommt: "Recovery Manager: LogFile is full". Tja, das war dann auch wirklich so.

Warum kam diese Meldung? Es half nur ein Reboot der Maschine, danach ein Haufen Konsistenzchecks, indexer, updall usw. die die gesamte Nacht durchliefen. Das ganze passierte um ca. 17:30 eines Tages und war am nächsten Tag um 9:00 fertig, sprich da war der Server dann erst wieder voll da. Bis dahin war er voll unter Last.

Habe nun Angst, dass es mit dem TransLog was zu tun hat, aber eigentlich sollte das ja bei Systemwiederherstellung nach Servercrash helfen, oder?

Wir haben Win2003 mit Domino 6.5.5. Cluster und archivierendes TransLog (4 GB) für Online Backup. Platz auf der Partition ist 15 GB.

Danke schon mal, lG mcilly

[Lossa]

Hi,

du musst auf jeden Fall dafür sorgen, das das Backupprogramm die archivierten Translog einträge auch als gesichert vermerkt, da sonst der Platz nicht wiederverwendet wird. Wenn es dazu kommt, das der Server nichts mehr in das Translog schreiben kann, dann kommen solche Meldungen und der Server bleibt dann auch stehen.
Wenn das Backupprogramm einmal kein backup machen kann musst du oder der Backupadmin davon 100% Kenntniss erhalten, denn dann muss das Backup manuell angetriggert werden damit das Translog nicht vollläuft.

[mcilly]

Hallo Lossa!

Sry für meine Fehlauskunft. Habe zwei Server verwechselt. Also, der Server um den es sich handelt wird nicht gesichert, kein Online Backup. Wir haben aber trotzdem Translog auf 4 GB zirkulierend eingestellt.
Sprich das Translog kann nicht voll werden auf diesem Server, richtig?
Warum also dann plötzlich die Meldung?
Kann ein Translog defekt geworden sein?
Komisch war, dass in der Nacht vor dem Absturz das Tranlsog um 00:16 extrem viele Einträge geschrieben hat. Um 2:42 war dann Schluss mit Translogs, es wurden keine mehr geschrieben. Um 17:30 war dann die Meldung "Recovery Manager: LogFile is full".

Hilft die genauere Auskunft wahrscheinlich in der Analyse - sry nochmal.

LG mcilly

[Lossa]

Hi,

es gab/gibt bei ND6 Probleme mit dem Zirkular TransLog. Die Max Grösse ist 4GB, die scheinst du ja eingehalten zu haben. Aber mach doch einmal die max. Grösse etwas kleiner nur um gaaanz sicher zu sein.

[mcilly]

Danke. Ich werde es versuchen. LG mcilly

[blizzard]

Hi,

ich habe momentan genau das gleiche Problem auf einem Domino 6.5.4 Server mit FP3.
Zirkulierendes Translogging auf 4096MB und die Kiste raucht alle zwei Wochen mit dem selben Fehler ab:
Error Recovery Manager: Log File is full, try again later

Restart und wie beschrieben die Consistency Checks beheben dann das Problem. Ich kann mir keinen Reim darauf machen, wieso das so ist.
Jemand ne Idee? mcilly, was hast du da gemacht?

Danke

[tks]

Ich hatte vor kurzem dazu einen Call bei IBM aufgemacht.

Laut Auskunft des Support-Mitarbeiters sind mit der Meldung "logfile is full" nicht die TA-Logs (txn) gemeint, sondern eine Datei im Speicher. Die Größe dieser Datei kann im Serverdokument unter "Transaktionsprotokollierung" unter dem Punkt "Leistung zur Laufzeit bzw. Systemstart" beinflusst werden. Ich kenne jetzt nicht mehr die Größen, aber ich glaube mit "Vorrang für Laufzeit" kann man den Bereich vergrößern. Zudem könne es vorkommen, dass die LFH-Datei korrupt wird und dadurch Probleme entstehen.

Der Supportmensch riet davon aber ab. Die Meldung rührt davon, dass zuviele Transactionen auf einmal anfallen und dann diese "logfile" überläuft. Er hat mir geraten einige Datenbanken vom Logging auszuschliessen und einige INI-Parameter zu setzen.

Wir haben dann die empfohlenen Datenbanken (log.nsf, mail.box, busytime, usw.) vom TA-Log ausgeschlossen. Zudem haben wir TA-Log mal ausgeschaltet, den Server beendet, alle Dateien (txn und lfh) gelöscht und dann TA wieder aktiviert.

Hier noch der Text der Supportmail:

bitte deaktivieren Sie das Transactional logging für diese Datenbanken:
- log.nsf
- mail.box
- busytime.nsf, clubusy.nsf
- und in allen datenbanken wo das TL nicht notwendig ist.

Setzen Sie bitte diese notes.ini parameter:

RM_NO_LOG_LARGE_OBJECTS=1
No attachments larger than 1 MB are logged into the mail.box database

To disable logging on the schedule databases (busytime.nsf, clubusy.nsf) and the log file:
ScheduleDisableTXNLogging=1

MailBoxDisableTXNLogging=1
This disables logging of mail.box.

Log_DisableTXNLogging=1 (Available in 7.0.2+)

These parameters do not automatically disable transaction logging of these databases.  The parameter means that NEW instances created by the SERVER on server startup will be CREATED without Transaction Logging enabled.  It does not disable Transaction Logging if it is already enabled for these databases.  It also does not automatically disable Transaction Logging if the databases are created manually.  It does not override manually enabling Logging for these databases once they have been created.   

Erstellen Sie ein nsd wenn der Fehler noch einmal auftreten sollte und prüfen Sie das log.nsf (Usage -> by Date)


bitte beachten Sie auch die Informationen in dieser Technote

Title:        Notes/Domino Best Practices: Transaction Logging
Doc #:        7009309
URL:        http://www.ibm.com/support/docview.wss?rs=899&uid=swg27009309


Anbei noch einige Technotes zu dem Thema


Title:        How do transaction logs become corrupt?
Doc #:        1195109
URL:        http://www.ibm.com/support/docview.wss?rs=899&uid=swg21195109

Title:        How to clean up corrupt Domino server transaction logs after a failure
Doc #:        1239792
URL:        http://www.ibm.com/support/docview.wss?rs=899&uid=swg21239792

[Bastian_W]

Sorry für das Reaktivieren der Posting Leiche ;-), aber der notes.ini Eintrag ScheduleDisableTXNLogging schreibt sich wie folgt: Schedule_DisableTXNLogging. In der von dir oben verwendeten Version fehlt ein "_" ...

Wenn man Googelt findet man auch nur diese Schreibweise z.B. hier ScheduleDisableTXNLogging

oder hier: Lotus Domino 7 performance in production at IBM on pSeries servers.

Für den Fall das jemand dein Posting findet und sich wundert warum es nicht geht ;-).

[koehlerbv]

Danke, Bastian. Über derartige Postings mit versehentlichen Schreibfehlern stolpern andere dann nach Jahren wieder, und Deine Korrektur wird dann sehr hilfreich sein.

Bernhard