Upgrade von 2.01 auf NAV 2009 R2

Hallo,

beim Durchführen des Upgrades von NAV 2.01 auf 2009 R2 musste ich zunächst den Schritt auf NAV 3.70B voranstellen. Die Native-Datenbank ist ca. 6 GB groß. Das Upgrade wurde auf einem leistungsstarken Rechner (8 GB Ram Intel Xeon 2.66 GHz) durchgeführt. Die Systemleistung hat kaum Aktivitäten angezeigt. Trotzdem lief Step 1 und Step 2 vom 3.70 Upgrade jeweils 30 Stunden. Kann mir jemand von Euch einen Tipp geben, wie ich es beschleunigen kann?

Danke im Voraus.

Gruß

Michael

Hall,

hast du das Update mit einem Serverdienst oder nur mit dem Client durchgeführt? Falls letzteres dreh doch mal den DBMS-Cache des Clients auf 900+X GB, das wirkt Wunder.

- alle nicht benötigten Schlüssel deaktivieren.

Gruß, Fiddi

Herzlichen Dank für die rasche Antwort.

Der Cache ist jetzt bei <8000>. Wenn ich Deine Formel nehme dann müsste ich 900 x 8 GB = 7200 rechnen. Oder rechne ich da etwas falsch?

Wie finde ich heraus, welche Schlüssel nicht benötigt werden. Kann ich die Schlüssel nur in der Tabelle deaktivieren, oder gibt es da etwas globales?

Gruß

Michael

Sorry ich meinte 900 MB+X MB . X hängt vom System ab. Die Summe kann jedoch 1GB nicht überschreiten.

Gruß, Fiddi

Kann man nicht direkt 2009 R2 technisch upgraden und das inhaltliche upgrade über 3.7 machen?
Ich denke gerade an folgenden Ablauf
1. tech update 2009r2
2. checkfield
3. sql import
4. inhaltliche updates über 3.7 auf 2009r2

Kann man nicht direkt 2009 R2 technisch upgraden

Kann man nicht. 2009er Client kann soviel ich weiß 2.01 DB bzw. FBK nicht öffnen.

Ansonsten kann man natürlich den Weg des technischen Updates gehen. In diesem Fall wäre ich allerdings vorsichtig, das mit SQL zu machen, da die alten Versionen damit noch nicht allzu viel am Hut haben.

Gruß, Fiddi

Hallo,

das technische Upgrade auf 2009 habe ich ganz am Anfang getan. Das hat wunderbar funktioniert.

Welchen Vorteil hätte ich, wenn ich die Datenbank auf den SQL-Server bringen?

Gruß

Michael

Hallo,

unter welcher technischen Umgebung habt ihr den vorher gearbeitet?

Der SQL-Server hat den Vorteil, das er Zukunftsorientiert ist. Die nächste bzw. übernächste NAV-Version wird keine native DB mehr unterstützen.

Gruß, Fiddi

Den Update solltest Du aber auf jeden Fall Native machen.
Wird sogar durch Microsoft in diesem Buch http://msdynamicsbooks.com/product_info ... cts_id=352 empfohlen.
Der Performance des Upgrade-Toolkits auf SQL ist eine Katastrophe!!!
Habe in den letzten Monaten einige Updates von 2.x gemacht. Die DB's waren teilw. > 50GB.
Native ist das Update zu schaffen. Wenn das Update durch ist, kannst Du eine Sicherung in Nav anlegen und auf der SQL-Plattform mit dem NAV-Client wieder einlesen.

Gruss und viel Erfolg

Hallo Martinst,

wie lange hast Du für dieses Upgrade gebraucht? Wie hast Du es performant gemacht?

Gruß

Michael

Hallo

Das ist eine Riesengeschichte.
Ich habe die Updates jeweils ca. 3-4 x testmässig durchgeführt und alle Schritte minutiös aufgeschrieben.
Am Schluss hatte ich dann jeweils einen genauen Zeitplan in dem jeder Schritt mit Zeitbedarf aufgeführt war.
So wusste ich ganze genau, wenn ich am Freitag Abend um 17.00 den ersten Schritt starte, dass ich am Montag morgen um 04.00 Uhr durch sein werde
Bedeutet natürlich auch, Wochenende vergessen und jeweils nach Zeitplan mitten in der Nacht den Wecker stellen und wieder einen Schritt starten.

Alles in allem ist ein Update mit grossen Datenmengen eine Aufgabe, die man irgendwann aus Zeitnot nicht mehr durchführen kann.
Wenn ich mir überlege, dass unsere aktualisieren Kunden z.B. in 2 - 3 Jahren wieder einen Vollupdate (mit allen Daten) machen wollen, wird ein Wochenende nicht mehr reichen.

Zum Teil hat mn nun folgenden Weg beschritten.
- Geb. Belege in neue (SAVE) Tabellen kopieren -> Danach löschen
- dito Artikelposten etc.
- Am Schluss haben wir nur "noch" Fibuposten, Debitorenposten, etc. und ntürlich die Stammdaten
- Upgrade-Toolkit laufen lassen
- Nach Upgradetoolkit mit einer Funktion die Geb. Rechnungen (Kopf und Zeilen) aus den SAVE-Tabellen die effektiven Tabellen zurückkopieren (ca. die letzten 2 jahre)
- Artikelposten Verkauf der letzten 2 jahre programmmässig via Artikelerfassungsjournalzeile buchen (natürlich mit richtigem Zugang). So bleibt die Debitor Artikelstatistik erhalten
- Aktuelle Bestände mit einer Buchung wieder einbuchen
- etc.

Ist aber halt alles ein ziemlicher Aufwand.

Aber ganz sicher kann man sagen, solche Operationen (insb. Upgrade-Toolki) laufen mit der nativen DB viel schneller, als auf SQL-Server.
(Prima dass es die Nativ-DB jetzt nicht mehr gibt)
Du brauchst einfach einen Rechner, der sehr schnelle Platten hat.

Viel Erfolg.

Nicht nur Wecker für die Nacht stellen, sondern auch Kontrollsichtungen, ob die Routine noch läuft.
Ich habe das auch mal gemacht. Der Fieldcheck war da noch relativ harmlos (bis auf probleme in einigen Addons wo es ein feldname "FIELDNAME" gibt).
Insgesamt hat das dann auch ~ 48 stunden gedauert, wobei ich glaube ich in der zeit so 8 stunden schlaf hatte.

VLDB Kunden würden eh mit einem Zwischenschritt (Fieldmerge) ein Upgrade durchführen müssen.
Also auf Tabellenebene:
Urversion -> Merge aus Urversion und Neuversion -> nur neuVersion + Non-Table-Objekte.

Zuletzt geändert von JanGD am 19. Mai 2011 14:15, insgesamt 1-mal geändert.

Nicht nur Wecker für die Nacht stellen, sondern auch Kontrollsichtungen, ob die Routine noch läuft.

Richtig. Hatte ich vergessen.
Insgeasmt ist ein NAV-Update nicht so das tolle Erlebnis

Nicht nur Wecker für die Nacht stellen, sondern auch Kontrollsichtungen, ob die Routine noch läuft.

Richtig. Hatte ich vergessen.
Insgeasmt ist ein NAV-Update nicht so das tolle Erlebnis

Ist aber aus meiner Sicht die beste Möglichkeit, bei einem Kunden viel Vertrauen aufzubauen.

Ist aber aus meiner Sicht die beste Möglichkeit, bei einem Kunden viel Vertrauen aufzubauen.

Der Kunde bekommt ausser der Rechnung von dem Ganzen nicht viel mit.

gruss

Abgesehen davon, daß im Vorfeld zigtausend Sachen mit dem Kunden abgesprochen werden müssen, fände ich es sehr verwunderlich, wenn jemand nicht merkt, daß ein ganzes Wochenende (evtl. länger) sein System abgeschaltet ist und am darauffolgenden Werktag seine ERP-Arbeitsumgebung komplett anders aussieht.

Ist aber aus meiner Sicht die beste Möglichkeit, bei einem Kunden viel Vertrauen aufzubauen.

Der Kunde bekommt ausser der Rechnung von dem Ganzen nicht viel mit.

gruss

In meinem Fall war es ein NAV4->5 Upgrade. Kaum visuelle Änderungen.
Eigentlich sollte der Kunde grobe Funktionstest vor Start der upgedateten Version. Also von daher sollte er auf jeden Fall mitbekommen, dass sich die Anwendung geändert hat.

Gut, von dieser Seite her gesehen: JA!!!
Aber die ganze Prozedur kriegt der Kunde nicht direkt mit.

Du kannst dir aber sicher sein, daß sowohl beim Partner als auch beim Kunden die guten Entscheidungsträger registrieren, daß sich da jemand mit übermässiger (Wochenend-)Arbeit engagiert. Und falls es bei euch einen Wochenend-/Feiertagsaufschlag gibt, dann registrieren das beide Seiten auch ganz plastisch.

Aber ganz sicher kann man sagen, solche Operationen (insb. Upgrade-Toolki) laufen mit der nativen DB viel schneller, als auf SQL-Server.

Also so 1:1 würde ich das niemals unterschreiben. Ich habe, natürlich mit entsprechender Vorarbeit, sehr positive anderweitige Erfahrungen gemacht. War zwar "nur" 3.70 auf 4.0 SP3 und die Datenbank mit ca. 50 GB nicht besonders groß, aber wir lagen bei brutto 14 Stunden.

Durch entsprechende Vor- und Handarbeit kann man den Schritt 1, also die Erstellung der Tabellenkopien auf dem SQL Server auf sicherlich 1-2 Stunden verkürzen, wenn nicht weniger. Kommt natürlich auf die Datenbankgröße an.

Da muss ich Dir aufgrund mehrfachen Erfahrungen widersprechen.
Ebenso wird es von Microsoft (siehe Link weiter oben Im Beitrag) empfohlen.

Gruss

ich hab's mit SQL zwar noch nicht ausprobiert, aber wenn man - wie Karsten schon sagte - das UGT ein wenig bearbeitet, kann man die Geschwindigkeit des Updates schon erheblich gegenüber dem Standard steigern. Ob man nach diesen Änderungen am UGT die Geschwindigkeit auf dem SQL-Server auch steigern kann hab ich noch nicht ausprobiert.

Ich habe mir inzwischen allerdings abgewöhnt 2er Versionen upzudaten. Ist die Impuls Lagerregulierung installiert, gibt es kein offizielles Update, d.h. du baust dir dein UGT dafür selbst. Nach den Erfahrungen die wir mit den Updates von 2 nach XX gemacht haben, fängt der Ärger mit den Artikelposten erst richtig an. Es taucht dann vermehrt das Phänomen der Lagerwerte ohne Bestand auf, bzw. bei kleinen Mengen steigen die Einstandspreise auf riesige Werte. (Dieses Phänomen ist unabhängig von der Art der Lagerregulierung) Deshalb werden bei uns aus 2er- Versionen keine Artikelposten mehr übernommen, die in den großen DBs den größten Teil der Daten ausmachen, und durch das Erstellen der Wertposten den größten Zeitaufwand bedeuten.

Gruß, Fiddi

Deshalb werden bei uns aus 2er- Versionen keine Artikelposten mehr übernommen, die in den großen DBs den größten Teil der Daten ausmachen, und durch das Erstellen der Wertposten den größten Zeitaufwand bedeuten.

Das finde ich auch den richtigen Ansatz.
Meistens wollen die Kunden halt die Statisk nicht komplett verlieren.
Aber volle Updates von 2.x auf 2009 mit grossen Datenmengen möchten wir lieber auch keine mehr machen.

Gruss

Aber volle Updates von 2.x auf 2009 mit grossen Datenmengen möchten wir lieber auch keine mehr machen.

Lässt sich alles über den Preis regeln

Hallo,

herzlichen Dank für die vielen Tipps. Was mich noch interessieren würde ist: was muss ich am UGT verändern, um bessere Performance zu erreichen, besonders auf dem SQL-Server?

Gruß

Michael