DBMT crasht Server

[benito]

Hallo,
vielleicht kann mir jemand helfen.
Ich habe zwei Server bei denen mittels DBMT jedes Wochenende die Maildatenbank gewartet werden. Auf dem einen Server läuft DBMT sauber durch. Beim zweiten Server crasht der ganze Server, sobald DBMT per Programmdokument gestartet werden soll. In der NSD steht auch als fatal task ndbmt drin. Er schafft es nicht mal mehr im Server Log zu schreiben, dass DBMT gestartet wurde.
DBMT lief auf dem Server noch nie erfolgreich.
Beide Server sind 9.0.1FP6 64bit auf Window 2008R2.

Mein Problem, ich kann die NSD nicht lesen, bzw. verstehe nicht, was er mir da sagen will und ob es da überhaupt eine Info drin gibt, was für ein Problem er hat.

Code

############################################################
### thread 3/7: [   ndbmt:  12bc:  123c] FATAL THREAD
### FP=0x566691f8, PC=0x76dabd7a, SP=0x566691f8
### stkbase=0x56670000, total stksize=1048576, used stksize=28168
### EAX=0xa36183a7, EBX=0x00000000, ECX=0x56668540, EDX=0x00000020
### ESI=0x000927c0, EDI=0x0000037c, CS=0x00000033, SS=0x0000002b
### DS=0x00000000, ES=0x00000000, FS=0x00000000, GS=0x00000000 Flags=0x00000287
############################################################
 [ 1] 0x76dabd7a ntdll.ZwWaitForSingleObject+10 (0,56669c17,7FEF7CE8E38,ffffffff)
 [ 2] 0x7FEFCDA10AC KERNELBASE.WaitForSingleObjectEx+156 (0,566693a0,0,37c)
@[ 3] 0x7FEF682951A nnotes.FRSendCommandToService+1450 (56669c17,56669c17,258,7FEF6827EF0)
@[ 4] 0x7FEF682B0A6 nnotes.OSRunExternalScript+1334 (12bc,0,0,5)
@[ 5] 0x7FEF682BA3A nnotes.FRTerminateWindowsResources+1738 (0,5,1,2d7a00)
@[ 6] 0x7FEF682C1C9 nnotes.OSFaultCleanupExt+1177 (1,0,5666fe00,FFFFFFFFFFFFFFF)
@[ 7] 0x7FEF682C7C7 nnotes.OSFaultCleanup+23 (0,7FEF72DF1F3,415e34f0,7FEF6850000)
@[ 8] 0x7FEF6890057 nnotes.OSNTUnhandledExceptionFilter+423 (5666b3f0,0,1,0)
 [ 9] 0x76bdbc10 kernel32.UnhandledExceptionFilter+352 (5666b3f0,6,0,7FE00000001)
 [10] 0x76de0108 ntdll.EtwEventSetInformation+7688 (394,7FEF68521F9,11c000,0)
 [11] 0x76d77958 ntdll.__C_specific_handler+156 (56670000,5666fe00,5666fe00,76e9f818)
 [12] 0x76d8812d ntdll.RtlDecodePointer+173 (56670000,76c4dd88,127ec,0)
 [13] 0x76d7855f ntdll.RtlUnwindEx+3007 (5666c030,5666bb40,0,0)
 [14] 0x76dabcb8 ntdll.KiUserExceptionDispatcher+46 (0,0,0,212)
@[15] 0x7FEF687B299 nnotes.OSFDGLockWriteSem+9 (0,56678500,2,200)
@[16] 0x7FEF745831C nnotes.NSFFDGAcquireOSFD+204 (200,0,56660000,0)
@[17] 0x7FEF6803BE8 nnotes.ReadObject+2488 (0,4b36,0,0)
@[18] 0x7FEF771F3BC nnotes.DbReadObject+28 (7FEF80A0025,263,4b36,0)
@[19] 0x7FEF74A8411 nnotes.iNSFDbReadObject+289 (7840000,56678500,5666c771,0)
@[20] 0x7FEF73FC0DA nnotes.NSFDbReadObject+1002 (0,212,0,a)
@[21] 0x7FEF74BA8F0 nnotes.DbCopyObject+3248 (5666000a,0,19,56bd17d8)
@[22] 0x7FEF725E041 nnotes.NSFDbCopyObject+1089 (a,0,4b36,2ad)
@[23] 0x7FEF774E062 nnotes.xNSFDbCopyObject+162 (19,5666d310,F29000000019,F16800000019)
@[24] 0x7FEF761A94E nnotes.NSFNoteUpdateObjectsBegin+6030 (19,40c,5666d7f0,F1F800000000)
@[25] 0x7FEF739EF45 nnotes.NSFNoteUpdateExtended3+2197 (0,1,19,0)
@[26] 0x7FEF739F594 nnotes.NSFNoteUpdateExtendedFlags2+148 (4010000,5666db70,40c,56bd0400)
@[27] 0x7FEF74942BB nnotes.CopyNoteCompactMode+1035 (43606E000002B3,7FE000002AD,0,125817500600008)
@[28] 0x7FEF7495141 nnotes.CopyNote+193 (0,c4,80000100,12582E200600004)
@[29] 0x7FEF74A4061 nnotes.NSFDbCompactInternal2_h+5345 (2b3,2ad,80000100,4010000)
@[30] 0x7FEF7493C28 nnotes.NSFDbCompactInternal2+104 (4010000,5666e3a0,1,0)
@[31] 0x7FEF74A2013 nnotes.DbCompactExtended+10067 (566831e8,80000100,4010000,8051e)
@[32] 0x7FEF74A5C2C nnotes.NSFDbCompactExtended5+236 (566831e8,8051e,5666f588,5666f588)
@[33] 0x7FEF74A5D3B nnotes.NSFDbCompactExtended4+219 (0,5666f600,566831e8,12581750060346D)
@[34] 0x13FD91C60 ndbmt.CompactFile+704 (1e13344,0,12582E280000100,566831e0)
@[35] 0x13FD930B6 ndbmt.CompactThread+518 (0,8001ffa1,0,1)
@[36] 0x7FEF683D322 nnotes.ThreadWrapper+258 (0,0,0,0)
 [37] 0x76b559cd kernel32.BaseThreadInitThunk+13 (0,0,0,0)
 [38] 0x76d8a561 ntdll.RtlUserThreadStart+33 (0,0,0,0)

Kann mir jemand einen Tipp geben, wo ich in der NSD suchen muss um der Sache auf den Grund zu gehen?

Wo kann ich sowas mal nachlesen, wie man die NSD untersucht?

Gruß
Benito

[Jörg P.]

Moin,

9.0.1 Fix Pack 7 Fix List descriptions:
FABNA3BQDM (LO86717) - Fixed a potential Domino server crash when DBMT is processing soft deletions.

Vielleicht hilft ein kleines Update, sonst würd' ich einen PMR eröffnen...

Gruß
Jörg

[benito]

Hallo Jörg,
Danke für die Info. FP8 ist bei uns gerade in der Prüfung. Ich habe mich aber jetzt durch das NSD durchgequält.
Durch Zufall bin ich darauf gestoßen, dass auf dem Server, auf dem der DBMT crasht eine MailDB noch ODS 43 hat, obwohl mal alle auf 51 hochgehievt wurden. Auf dem Clusterpartner war die Replik auf 51.
Daraufhin habe ich die NSD nach der Datenbank durchsucht und tatsächlich in den Threaddumps den Hinweis auf die MailDB gefunden.
Ich hab die Replik auf dem crashenden Server gelöscht und neu angelegt. Ich lass heute abend mal den DBMT nochmals laufen, ob er diesmal fehlerfrei durchläuft.

Aber den Hinweis mit dem LO86717 werde ich beim nächsten Jourfix ansprechen, dann bekommen wir da vielleicht zügiger einen Wartungstag.

Gruß
Benito

[Scuba]

Hallo Benito,

wenn der Notes.ini Parameter Create_R85_Databases=1 auf deinem Server gesetzt ist und die
Datenbank nicht im Zugriff ist, hätte auch ein Copystyle Compact auf die Datenbank ausgereicht.

Das Ziel wäre das ODS 51, dass du angesprochen hast.

Aber eigentlich gibt es schon seit 9.0.1 das neuere ODS 52. (Create_R9_Databases=1)
Ich vermute, dass du das 9.0.1 FP8 meinst.

Es kann natürlich auch technische Gründe geben, warum man dies nicht verwendet einsetzt. z.B. verwendete Backuplösung etc.


Gruß

Scuba

[benito]

Hi Scuba,

da ich im NSD gesehen habe, dass der DBMT Thread der crashte auf der Datenbank gerade einen "DBCompactExtended" durchführen wollte, vermute ich jetzt, ein Compact hätte hier eventuell nicht viel gebracht.
Da der Benutzer nicht auf der Replik arbeitete, war das löschen und neu anlegen der Replik der sichere Weg.

Den Eintrag Create_R85_Database hatte ich bisher in der notes.ini, den habe ich jetzt in R9 geändert.

Das FP8 meinte ich nur in dem Zusammenhang mit dem Hinweis, dass es im FP7 einen Fix für einen Crash des DBMTs gab und wir derzeit noch auf FP6 sind.

Gruß
Benito

[Scuba]

Hallo Benito,

der von Dir angepasste Werte würde alle Datenbanken betreffen und mit einem Compact -c / dbmt alle Datenbanken anpassen.

Ich würde erst mal mit einer Datenbank und ggf. nicht dem prod. System testen, ob Backup & Restore ohne Probleme läuft oder es
andere Auffälligkeiten gibt.

Erst danach serverseitig anpassen bzw. definieren.

Gruß
Scuba

[benito]

Hi Scuba,

wird jetzt etwas OT:
bist Du da nicht etwas übervorsichtig? Das Anheben der ODS erst testen?
Das hab ich noch nie getan. Einspielen einer neuen Schablone - ja da teste ich, beim Backup schaue ich aber nur, dass die letzten ordnungsgemäß durchliefen.
Auch bei Fixpacks bin ich entspannt. Ich mach zwar nicht alle Server an einem Termin, sondern je um einen Tag versetzt.
Aber im Großen und Ganzen hat sich die Taktik - nach dem Release eines FPs einige Zeit warten, Foren lesen, HFs abwarten, dann umsetzen - bewährt.

Da der betroffene Server nur als Failover gedacht ist und alle Benutzer auf dem anderen arbeiten und auch dort die Backups gezogen werden ... ab dafür.

Und selbst der Test des DBMT-Prozesses sagt nichts aus, wie der DBMT dann im Produktivsystem läuft. Siehe mein Problem, da ist irgendwo eine DB unter hunderten defekt und es reißt den ganzen Server.

Gruß
Benito

[Scuba]

Hi Benito,

war nur ein Hinweis. Geklappt hatte die Umstellung dort auch direkt.
Ich hatte nur schon Kunden, deren Software damit nicht zurecht kam.
Daher erwähne ich das nur.

Und wenn das Backup nur von dem Server aus gemacht wird, da dort keine Nutzer drauf sind..
und der Restore von betroffenen/allen Datenbanken nicht klappt,.. ist das mehr als stressig.

Normalerweise stellst du keine Probleme fest....

Gruß
Scuba