DB-korrupt / Sekundärschlüssel

7. März 2009 23:14

Hallo Zusammen,

wir haben ein Problem mit der Native-DB, welche folgende Fehlermeldungen produziert.
Bild1.JPG

Da ist wohl der Platz von der Disk gemeint. Die DB ist groß genug (siehe unten) die DB ist optimiert. Wie kann ich den Ausdruck „Aktionen die lange dauern“ interpretieren, Platz ist genug da.
Sollten die „konkurrierenden Änderungen“ nicht vom NAV-Server „gehandelt“ werden ?

Die Konsequenz ist dann wohl diese Meldung…
Bild2.JPG



Habe ich auch dann gemacht, nach Stunden… konnte man die DB auch wieder benutzen.

Dann lief es eine Zeit lang, dann wieder dieselbe Problematik. D.h. das ganze Procedere wieder von Vorne. Bis jetzt konnte die DB immer wieder erstellt werden. Gott sei Dank

Die Standard-Auskunft von Microsoft dazu:
All errors in Module 19 occur after Hardware crash or problems with Hard drives, Raid-controllers and so. If you place Database for your ERP systems on Hardware that have fail and cause a error in Module 19, Microsoft strongly recommend to replace the Hardware to avoid the error to occur again in the Database.

Alles schön und gut, aber ich kann bis jetzt keinen Hinweis auf einen HW-Fehler, in ServerRAID Logs, noch in DSA DynamicSystemAnalyse von IBM, einen Fehler feststellen.
Bzw. Ist dies wirklich so, dass alle Fehler in Modul 19 die HW- als Ursache haben ?

Sowie es aussieht sind immer die Sekundärschlüssel des „Sales Header „ defekt, der Primärschlüssel ist o.k. Wieso ist nicht mal eine andere Tabelle betroffen ?
Gibt es irgendeine Möglichkeit ein Tool im Hintergrund mitlaufen zu lassen, welches evtl. die Ursache ermitteln kann ? bzw. was den Cache Bereich auf Unstimmigkeiten hin überprüft etc.?

Hier noch die Systemumgebung bzw. Ausgangslage:

- externes DISK-Subsystem mit 12 Platten plus zwei HotSpare Platten SCSI RAID „1E0“ (a 36GB 15TU/min)
- DB Größe 100 GB zu 50% gefüllt / NAV 4.0
- NAV-Server plus zwei CITRIX Maschinen.
- NAS-Server
- 35 User
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Re: DB-korrupt / Sekundärschlüssel

8. März 2009 18:10

Hallo Stefan,

Modul 19 steht für die Datenbank, d. h. alle Fehler im Modul 19 stellen ein Problem in der Datenbank dar.
Dass immer die Hardware daran Schuld wäre ist nicht korrekt, einige Fehler können auch durch externe Programme verursacht werden, welche z. B. mit C/FRONT oder C/ODBC direkt in die Datenbank schreiben.

Deine Fehlermeldung bedeutet auf jeden Fall, dass die aktuelle Datenbank defekt ist und mit ihr nicht mehr weitergearbeitet werden kann bzw. auf keinen Fall mehr mit gearbeitet werden soll.
Sofern möglich, sollte man eine Datensicherung erstellen und damit eine neue Datenbank aufbauen. Anschließend eine vollständige Datenbankprüfung durchführen und die Fehlermeldungen abarbeiten / beheben.
Um die Hardware als Schuldigen auszuschließen, sollte die neue DB auf einer anderen Maschine (z. B. einem lokalen PC) aufgebaut werden.

Wenn der Fehler in regelmäßigen Abständen wieder auftritt, dann könnte es wirklich an der Hardware liegen (sofern keine externen Programme direkt in die Datenbank schreiben).

Re: DB-korrupt / Sekundärschlüssel

8. März 2009 20:38

Hallo Timo,

besten dank für die rasche Antwort.
Es gibt kein externes Programm, welches Zugriff hat, Daten werden nur mittels Dataports ein und ausgelesen.

Ich konnte die DB bis jetzt jedesmal neu erstellen, dies macht keine Probleme (ausser Warnungen TAB36 bezüglich Kontakten, können Warnungen auch in letzter Instanz zu solchen Fehlern führen ?) dauert nur extrem lang (50 GB) und da viele Schlüssel.
Da es eine produktiveDB (RAID 1E0) mit gleichzeitigen Zugriff auf 12 Platten ist, ist es nicht so einfach auf eine andere HW auszuweichen, da diese einfach nicht da ist.

Das einzige was ich mir vorstellen kann, ist die Sache mit dem "Cache" da habe ich mal was gelesen, dass der RAID Controller kein WriteCache eingeschaltet haben sollte, da habe ich aber keine konkreten Unterlagen bzw. gibt es diese Info irgendwo ? So nach dem Motto Speicherbereich wurde überschrieben ?
Aber der NAV-Server sollte dies doch eigentlich verwalten oder ?
Und falls dies so wäre wie kann man ein solchen Fehler eingrenzen, bzw. wo bekomme ich Informationen diesbezüglich.