NAV Upgrade via SQL-Script

Hallo Zusammen

Wie ich schon in einem anderen Forum geschrieben habe,
bin an einer etwas speziellen Upgrade/Migration mit NAV:

Ausgangslage:
Kunde hat 2 Datenbanken auf Version 3.60 SQL

Unterschied der Datenbanken:

- Datenbank A ist eine "normale" DB mit 11 Mandanten. ca 30 GB
- Datenbank B ist eine DB mit 3 Mandanten, wovon 330 Tabellen übergreifen sind. ca. 80 GB
Aussser den Flags DataPerCompany der 330 Tabellen ist der Objektestand der Datenbanken gleich.

Die übergreifenden Tabellen sind Stammdaten-, Dokument- und Postentabellen. Also bund gemischt
Beispiel: Lagerposten, Artikel,.... ist übergreifen, aber Artikeleinheiten, Fibuposten und "Entry Ledger Dimension" , Verkaufsauftrag- Einkaufstabellen aber nicht.

Der Kunde hat diverse Module / spezifische Tabellen total sind es zwischen 1500-2000 Objekte. Welche voll in die Standard-Objekte eingreifen.

Diverse Posten-Tabellen haben an die 29 Mio. Datensätze.
Es müssen alle Datenübernommen werden!

Ziel :NAV2009 R2 eine Datenbank:

Die 3 Mandanten der DB B werde zusammen in einen Mandaten gelegt. Damit die übergreifenden Tabellen entfallen und die Mandanten der DB A auch in die neue DB passen. Die neue Datenbank wurde neben allen spezifischen Anpassungen zusätzlich "Shortcute Dimension 5" (Mandant) auf allen erforderlichen Tabellen erweitert - Grund die zusammengeführten Mandaten sind eigene Firmen.

Die Mandanten der Datenbank A werde in der neuen gesamten DB als eigene Mandaten geführt.
Der Migrationsserver WinSercer2008 R2, SQL-Server 2008R2 ist virtuell.


Unser Messungen über ein "Standart" Navisionupgrade und das erforderliche zusammen führenden der Daten via Dataport würde gegen gemäss Test's 1-3 Wochen dauern. Wir haben aber max 70h.

Daher haben wir uns entschieden, die Zusammenführung der Datenbanken (Transfer) via SQL Scripts zu machen.

Dabei gab es folgende Herausforderungen:
- NAV 360 auf NAV2009r2 sind im Standard-Nav-Upgrade 2 Schritte. Muss in einem Schritt erfolgen.

- Primärschlüssel Verletzungen beim Zusammenführen der Datenbank B - Alle Tabellen mit Konflikten und deren Verbindungen müssen umbenannt (Rename) und mit der neuen Mandanten-Dimension ergänzt werden.
- Mapping der NAV DB A und NAV B auf die neuen DB (über 42000 Felder), unzählige Konvertierungen
- Auf SQL-Ebene sind alle Felder mit "notNull" definiert, es müssen also leer-Werte abgefüllt werden
- Alle Dimensionsfelder sind in der neuen DB vom DateTypSQL Variante - also richtig abfüllen, damit Nav diese dann auch verwenden kann. CAST
- Die spezifischen Module haben in der Version NAV2009R2 eine andere Daten-Strukturen als ins der Version 360.

Mir ist klar, dass einige der Anforderungen nicht nachvollziehbar sind, für mich auch nicht. Hatte aber kein Mehrheit bei den Entscheidungen (

Nun wisst ihr, mit was ich mich in letzter Zeit beschäftigt habe.
Stand ist das ich alle Anforderungen erfüllen kann, ich möchte aber die Durchlaufszeit noch optimieren

Nun zu meiner Frage habt Ihr für mich spontane Tipps, damit ich den Transfer der Daten (SQL-Scripts) optimieren kann.
- Zum Beispiel habe ich festgestellt dass Recoverymodel Simple schneller als Bulk ist!?
- Wie würdet ich den SQL-Server Konfigurieren RAM

Für jede Idee bin ich dankbar.

Grüsse Marcos

Hallo Marco,

zunächst einmal herzlich Willkommen im Forum.

Also meine persönliche Meinung zu deinem Vorhaben:

Entweder der Kunde hat dir mindestens 1 Monat Programmieraufwand gezahlt, oder du hegst Selbstmordgedanken.

Was du da vorhast ist aus meiner Sicht in zweifacher Hinsicht Harakiri:

• Mehrere Firmen in einem Mandanten abzubilden, ist mit Sicherheit nicht nur mit Dimensionen zu behandeln. Wenn du alle Eventualitäten (Steuerabrechnung, Rechnungsempfänger, Belegdruck mit der korrekten Firma,...) berücksichtigen willst, wirst du einiges programmieren müssen. Mal ganz zu schweigen von Updates, die nicht mehr einfach durchzuführen sind.
• Das Upgradetoolkit bzw. die NAV- Runtime tun Dinge wie z.B. Rundungen, die ein SQL-Script nicht machen wird (es sei denn du programmierst es, und hast es getestet). Das UGT ist so gestrikt, dass es bei Fehlern abbrechen kann, und automatisch wieder an der richtigen Stelle aufsetzt, wenn man es neu startet, das müsstest du dann auch von Hand abbilden, oder dem Skript beibringen. Dann bist irgendwann andem Punkt, das dein SQL-Skript genauso komplex wird wie das UGT.

Ich würde an deiner Stelle vier Dinge tun:

• Deaktiviere in den Tabellen alle Schlüssel, außer Primärschlüssel und vom UGT benutzte bevor der erste Step1 richtig los läuft (kann man per Code über die Tabelle Key machen, oder indem man Objekte mit deaktivierten Schlüsseln einspielt {eh nötig für 2. und 4. Step, sonst baut er jedes mal die Schlüssel wieder auf} ) und aktiviere Sie erst wieder, wenn der letzte Step 2 fertig ist. (das dürfte inkl. Einspielen der Objekte die Zeit wahrscheinlich mehr als halbieren)
• Schau dir den UGT Code genauer an, der ist nur mit CRONUS getestet, und daher nicht unbedingt optimiert. Oft werden Tabellen mehrfach durchlaufen, oder sind in SQL-Hinsicht nicht optimal gelöst, was man u.U. optimieren kann.
• Das UGT läuft auf dem Server oder einem mindestens über GB- Ethernet angeschlossenen Client.
• Wenn du ganz viel Aufwand treiben willst, versuchst du das UGT für 3.60 nach 3.70 in das für 3.70 nach 2009 zu integrieren

Nach meiner Erfahrung ist eine 50 GB große Datenbank durchaus in 2 Tagen zu konvertieren, das gute Stück hatte schon mehr als 10Mio. Artikelposten. Ich habe das bei einem Update von 2.6 nach 4 ähnlich komplex gehabt, wobei man in dem Fall auch noch die Anlage der Wertposten beim Update zusätzlich berücksichtigen muss.

Gruß, Fiddi

Hi Marco,

warum trennst Du die 3 Mandanten nicht? siehe http://www.msdynamics.de/viewtopic.php?f=36&t=6379&hilit=+datapercompany

Volker