Böser Fehler in Nativ-Server?????

Hallo

Nachdem wir mehrfach bei Kunden mit der Nativ-DB (Version 5 =>) DB-Crashes hatten, wurden diese Installationen auf SQL-Server migriert.
(Beste Entscheidung seit langem )
Laut Microsoft waren wir aber die einzigen, mit solchen Problemen.

Und heute sehe ich diese Informationen frei zugänglich im Internet:
http://blogs.msdn.com/b/nav/

Für mich sieht dies nach einem bösen Fehler in der Nativ-DB aus!!!!

Die Crashes waren bei uns leider so verherrend, dass das beschriebene Verfahren zur Reparatur nicht angewendet werden konnte.
Sobald man auf die Tabelle Sales Line zugreifen wollte, wurde der Client geschlossen.
Eine Reparatus war nur noch mit C/DART möglich. Leider dauert es aber Stunden bis Tage C/DART auf einer grösseren DB laufen zu lassen.

Zur info bzw. Problemvermeidung:
Bei unseren Kunden passierten die Crashes praktisch immer beim Löschen der erledigten AUfträge oder kurz danach.
Manchmal wurde auch einfach der Serverdienst beendet, ohne aber einen Crash in der Datenbank zu verursachen.

Gruss und hoffentlich keine DB-Crashes.

Wenn ihr (bzw. euer Kunde) "regelmäßig" DB-Crashes erleidet, dann sieht das ganz stark nach einem schwerwiegenden Problem mit den Festplatten / -Controllern aus.

Ja, die native DB ist etwas empfindlich, und kann schon mal den ein oder anderen Fehler produzieren.
Für vier verschiedene Formen des "Internen Fehler x in Modul y" habe ich mir vor einiger Zeit mal einen Report gebaut, der in der Lage sein müsste, die Ursache für diese Fehler zu beheben:
- Error 1190 in module 19: #Err_DB_AlphaTypeIncorrect
- Error 1192 in module 19: #Err_DB_BoolOutOfRange
- Error 1204 in module 19: #Err_DB_FrontLenTooLong
- Error 9 in module 50: #Err_BCD_NoMantisse

Letzte Woche musste er dann zum ersten Mal auf eine defekte Echt-Datenbank beim Kunden losgelassen werden.
Die Laufzeit ist natürlich abhängig davon, wieviele Datensätze und wieviele Code-, Boolean- und Dezimal-Felder sich in den Tabellen befinden.
Bei diesem Kunden lief der Report mehrere Stunden.

Zufälligerweise musste der Report nochmal bei einem weiteren Kunden eingesetzt werden.
Dort läuft er mehrere Tage.

Timo

Bei den HW-Defekten gebe ich Dir bis zu einem gewissen Punkt recht.
Wir machen seit mehr als 10 Jahren Navision.
Wir haben in all den Jahren 2x einen Defekt mit Nativ-DB's erlebt. In beiden Fällen war nachweislich die HW defekt.

Aber seit der Version 5.x häuften sich die Fehler.
Wir hatten jedesmal den Fehler in Tabelle 37. 2 Records mit dem gleichen Primärschlüssel!!!!
Der Kunde hat an diesem Rechner alles gewechselt, was man so wechseln kann. Es passierte immer wieder in unregelmässigen Abständen.
Wie gesagt, besonders in Zusammenhang mit dem Löschen der Erledigten Aufträge.
Was sollte ich dem Kunden sagen, was er noch wechseln soll?

Bei einem anderen Kunden passierte es auch plötzlich (quasi aus dem Nichts).

Mich erstaunt es einfach, dass wir gemäss Microosoft quasi die EInzigen mit solchen Problemen sein sollen, gleichzeitig wird durch Microsoft ein solcher Beitrag in einem Blog veröffentlicht. Da müssen ganz klar viele solcher Fälle aufgetreten sein.
Ich bin froh, dass wir bereits ein paar Kunden von nativ auf SQL umgestellt haben. Neue werden logischerweise sowieso nur noch mit SQL installiert.

Gruss

Hallo

An Hardwarefehler mag ich inzwischen auch nicht mehr glauben.
Wir haben bei einem Kunden ebenfalls ein Problem mit Serverabstürzen, wenn er den Report zum löschen erledigter Aufträge aufruft.

Gruß, Fiddi

Wir haben damals mit Lars Lohndorf Larsen das Problem via Remote-Session beim Kunden analysiert.
Als Abhilfe haben wir den Hotfix Build 30848 erhalten.
Abe so richtig besser wollte es nicht werden.

Bei NATIV-Kunden hat man nun den Report "Erledigte Aufträge löschen" einfach immer ohne Serverdienst laufen lassen.
Dann gings.

Gruss

Was für eine Server- Hardware war denn das bei euch? Bei uns ist das ein HP Proliant DL380 G5, der den Ärger macht. Auf anderen Systemen mit native DB hatte ich dieses Problem noch nicht.

Gruß, Fiddi

HP Proliant DL380 G5

Bei einem Kunden genau diesen. Bei anderen Kunden andere Modelle, allerdings immer HP.

Aber die HW schliesse ich aus.
Man hat die den Controller, die Festplatten, das Mainboard, die Netzwerkkarten getauscht. -> Nichts.

Als wir damals mit Lars Lohndorf den Report "Erledigte Aufträge löschen" laufen liessen, ist der Serverdienst nach ca. 30 Sekunden abgeschmiert.
Die DB war damals nicht kaputt, allerdings meinte er, dass das wiederherstellen der freien Blöcke unglaublich lange gedauert hat.
Er hat damals etwas von einem Fehler im Handling Rollback-Segmente etc. gesagt. Wir musste damals im Hintergrund einen Debugger laufen lassen.
Der hat ein 1 GB grosses Dumpfile erzeugt, welches wir dann an Microsoft senden mussten.
Aber so eine "richtig" Lösung gab es eigentlich nie.

Wie gesagt, haben wir die meisten Kunden zum Glück auf SQL migriert.

Gruss

Wir setzen normalerweise Fujitsu-Maschinen ein. Dort habe ich dieses Problem noch nie gehabt. Das finde ich dann schon etwas merkwürdig. Aber das Fehlerbild ist bei dem Kunden identisch.

Sollte es da etwa ein Problem im Zusammenspiel NAV-Server mit der Hardware geben, auch wenn die nicht defekt ist?

Gruß, Fiddi

Hallo,
bei uns tritt der Fehler ebenfalls auf, NAV 5.0 und Nativ.
Beim Löschen der erledigten Aufträge im Mandant "1" stürzt der Dienst fast regelmäßig ab, vor allem wenn das löschen während der Datensicherung ausgeführt wird.
Wird das löschen nicht während der Dasi ausgeführt stürzt der Dienst nicht immer ab.

Beim löschen der erl. Aufträge Im Mandant "2" der erst seit 3/2012 aktiv ist ist der Dienst bisher noch nie abgestürzt.

Beim löschen der erl. Aufträge Im Mandant "2" der erst seit 3/2012 aktiv ist ist der Dienst bisher noch nie abgestürzt.

Es ist definitiv abhängig von der Datenmenge.
Einer unserer Kunden hat einen Mandanten mit sehr vielen Aufträgen und einen Mandanten mit wenig Aufträgen.
Das Problem hatten wir immer nur im Mandanten mit vielen Aufträgen!!!

SQL-Server löst das Problem definitiv!

Gruss

SQL-Server löst das Problem definitiv!

MS hat ja diese "Option" in 2013 zur Pflicht gemacht