[Gelöst] Fehler nach Plattenwechsel

Hallo nochmal,

nachdem eine Serverplatte den Geist aufgegeben hat und gewechselt wurde tritt jetzt nach dem Wiederherstellen der Raid Konfig immer der selbe Fehler auf.

Ich häng mal nen Screenshot dran...

Je länger man wartet mit OK drücken desto öfter muss man Klicken....

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von MBSNAV3.70 am 9. Juni 2008 20:16, insgesamt 1-mal geändert.

Wie groß ist denn die DB, und wieviel davon ist tatsächlich belegt?
Ich gehe mal davon aus, dass es sich hier um "natives" System handelt.

Abhilfe könnte dann entweder der "Table Optimizer" schaffen, oder ein Backup (FBK) / Restore ...

Sie ist zu 79 % belegt und ein neu einlesen bzw. Optimieren hat auch nix gebracht.
Aber gott sei dank funktioniert die Sicherung von Freitag nacht so das wir darauf aufbauen.

Trotzdem danke für die Mühe.

Hallo MBSNAV3.70,

wenn die DB zu 79% belegt ist, solltet Ihr die DB erweitern.
Die 80 % sollte nicht überschritten werden, da Navision für interne Verarbeitung Platz benötigt, andernfalls geht die Performance in den "Keller" (meines Wissens nach).
Ob es mit dem Problem zusammenhängt, kann ich allerdings nicht sagen!
Gruß Mikka

PS: Evtl. findest du über die Forensuche noch verwandte Themen.

Ob es mit dem Problem zusammenhängt, kann ich allerdings nicht sagen!

Ich denke schon! Hängst auch davon ab, auf wieviele DAteien die DB verteilt ist.
NAV benötigt den freien Platz zur Abbildung/Steuerung des Versionsprinzips:

Greift ein Benutzer/Prozess auf einen Datensatz zu, so wird von diesem ein "Snapshot" erstellt, soz. die benutzereigene "Version".
Werden nun Änderungen an dieser Version vorgenommen, so werden die betroffenen Datenblöcke in freie Blöcke kopiert; dort werden dann die Änderungen vollzogen. Die originalen Blöcke bleiben aber noch erhalten - für Versionen anderer Benutzer - solange bis ein COMMIT erfolgt.
Beim COMMIT werden die originalen Blöcke ungültig, statt dessen wird auf die neuen verwiesen. Die neue/geänderte "Version" wird damit zur Ausgangsversion für folgende Snapshots.

Daher sollte man - je nach Transaktionsvolumen - ca. 30% freien Platz verfügbar haben.

Ein weiterer Nebeneffekt des Versionsprinzips ist, dass die DB dabei rel. stark fragmentiert und daher regelmäßig mit dem "Optimzer" bereinigt werden sollte.

(P.S.: Betrifft ausschließlich native DB; SQL Server kennt kein Versionsprinzip)

Ein weiterer Nebeneffekt des Versionsprinzips ist, dass die DB dabei rel. stark fragmentiert und daher regelmäßig mit dem "Optimzer" bereinigt werden sollte.

Das ist bei Platzmangel sicherlich eine Notlösung, führt aber zu längeren Buchungszeiten, weil die Tabellendaten dann wieder auf eine Platte zusammengezogen werden. In den Schulungen von Navision wird vom Optimieren der Tabellen abgeraten ( Zitat : "der Server braucht das Chaos" )

Interessant! Hab' ich so noch nicht gehört - und bisher mit Tabellen "Optimierung" auch eher positive Erfahrungen gemacht (native only!!!) ... Ich glaub' das Thema werd' ich mir mal näher ansehen ...