Migration nach SQL (CC)

Hallo zusammen,

ich möchte eine 2009R2-Datenbank nach SQL migrieren, die dann später nach 2015 upgegradet werden soll. Das ist ja zunächst kein wirkliches Problem.

Programmmäßig war die DB noch eine 3.70, so dass auch die Programmkonvertierung nach 2009R2 und weiter nach 2015 stattfinden muss. Das ist alles auch schon gelaufen und hat auch funktioniert. Das einzige ist, dass die Konvertierung schweinelangsam ist (ca. 80 GB, mehrere Tage) und dass ich mir auch nicht sicher bin, ob es unter 2015 optimal laufen wird. Gibt es denn irgendwelche Tipps & Tricks, wie die richtigen Einstellungen auszusehen haben, wenn man die SQL-Datenbank unter NAV2009R2 erzeugt, und zwar im Hinblick auf eine schnelle Konvertierung und gleichzeitig auf das Laufzeitverhalten, nachdem die Datenbank zur 2015-Datenbank wurde.

Es gibt doch bestimmt irgendwelche Doku darüber, die ich nur wieder nicht gefunden habe . Das einzige, was ich habe, ist das alte Ressource-Kit für NAV4 und SQL2005, also nicht wirklich mehr brauchbar.

Danke für eure Hilfe!

Rainer

Hast du auch das hier gesehen? Microsoft Dynamics NAV SQL Server Migration Tool
(Inhaltlich kann ich dazu leider nichts sagen.)

Hallo,

Hast du auch das hier gesehen? Microsoft Dynamics NAV SQL Server Migration Tool

genau das ist das Problem

eine Möglichkeit das ganze zu beschleunigen ist dieses Tool von mibuso.

Es ist um einiges schneller (allerdings erst ab Technik >NAV 5.0) und man kann auch Probleme mit Codefeldern beheben die nach der Umwandlung von 'ß' in 'ss' zu lang würden (die Ersetzen- Funktion ß -> z.B. # umsetzen und dann den Konvertiervorschlag manuell bearbeiten).

Gruß Fiddi

Hast du auch das hier gesehen?

Hatte ich noch nicht, es ist aber leider nur der Auszug aus einer Doku, dich ich schon habe.

eine Möglichkeit das ganze zu beschleunigen ist dieses Tool von mibuso.

Es ist um einiges schneller (allerdings erst ab Technik >NAV 5.0) und man kann auch Probleme mit Codefeldern beheben die nach der Umwandlung von 'ß' in 'ss' zu lang würden (die Ersetzen- Funktion ß -> z.B. # umsetzen und dann den Konvertiervorschlag manuell bearbeiten).

Leider ersetzt dieses Tool nur den FieldCheck, bringt aber nichts für die Konfiguration des SQL-Servers oder die Upgrade-Prozedur. Dieses Tool habe ich schon eingesetzt und muss sagen, es ist einfach genial, besonders von der Laufzeit her. Trotz mehr und besserer Features beträgt hierbei die Laufzeit in Stunden das, was das Original-MS-Tool in Tagen braucht.

Gruß
Rainer

Leider ersetzt dieses Tool nur den FieldCheck, bringt aber nichts für die Konfiguration des SQL-Servers oder die Upgrade-Prozedur. Dieses Tool habe ich schon eingesetzt und muss sagen, es ist einfach genial, besonders von der Laufzeit her. Trotz mehr und besserer Features beträgt hierbei die Laufzeit in Stunden das, was das Original-MS-Tool in Tagen braucht.

Also für die Konfiguration des SQL-Servers kann ich nur wärmstens das Buch von 'unserem' SQL-Guru Jörg empfehlen. Praktisch /das/ Standardwerk zum Thema.

http://www.bod.de/buch/joerg-a--stryk/the-nav/sql-performance-field-guide/9783837014426.html

Hallo,

bei SQL-Server kannst du nicht viel tun, außer eine für SQL-Server performante Systemumgebung bereit zu stellen und NAV im Standard- Sicherheitsmodell zu betreiben.

Den Rest musst du dir dann zu Gemüte führen, wenn es zum Problem wird, d.h. wird irgendetwas langsam, den auslösenden Programmteil in NAV lokalisieren, und entweder Schlüssel oder Programmcode optimieren (dabei u.U. Anleihen am neuesten NAV- Build tätigen)

Gruß Fiddi

Leider ersetzt dieses Tool nur den FieldCheck, bringt aber nichts für die Konfiguration des SQL-Servers oder die Upgrade-Prozedur. Dieses Tool habe ich schon eingesetzt und muss sagen, es ist einfach genial, besonders von der Laufzeit her. Trotz mehr und besserer Features beträgt hierbei die Laufzeit in Stunden das, was das Original-MS-Tool in Tagen braucht.

Also für die Konfiguration des SQL-Servers kann ich nur wärmstens das Buch von 'unserem' SQL-Guru Jörg empfehlen. Praktisch /das/ Standardwerk zum Thema.

http://www.bod.de/buch/joerg-a--stryk/the-nav/sql-performance-field-guide/9783837014426.html

Ich hatte sogar schon Kontakt mit Jörg selbst, und sein Buch liegt auch hier vor mir . Leider sind das hier ja zwei Probleme, und ganzheitliche Ansätze gibt es noch keine.

Trotzdem danke!

Ich hatte sogar schon Kontakt mit Jörg selbst, und sein Buch liegt auch hier vor mir . Leider sind das hier ja zwei Probleme, und ganzheitliche Ansätze gibt es noch keine.

Also dann tät ich mal SSDs versuchen. Jedenfalls für die Migration.

Hallo,

jetzt muss ich mal fragen, was ist denn langsam bei deiner Umsetzung?

Gruß Fiddi

jetzt muss ich mal fragen, was ist denn langsam bei deiner Umsetzung?

In erster Linie das, was mit den Objekten in der Upgrade370B2009SP1.DE.2.fob abläuft. Speziell bei den gebuchten Belegen (Tabellen 110 bis 115) hält er sich tagelang auf. Auch auf einem anderen Server oder mit SSDs behält er diese Geschwindigkeit bei.

Was ich noch versuchen werde, beim nächsten Testlauf auf Bulkinsert umzustellen und vielleicht ein bisschen an den Blockgrößen zu drehen, aber viel mehr Ideen hatte noch niemand.

In erster Linie das, was mit den Objekten in der Upgrade370B2009SP1.DE.2.fob abläuft.

Das ist ja schon was ganz anderes.

Da hilft nur eins: SQL lernen und das Upgrade Toolkit weitestgehend (insbesondere beim Löschen von Feldinhalten) auf SQL- Skripte umstellen.
(oder du benutzt die SQL-Unterstützungsobjekte, die im UGT für die Dimensionsumstellung enthalten sind)

Außerdem solltest du überlegen, die UGT- Steps zusammen zu fassen, damit du wieder den guten alten Step1 und Step2 zu hast, und direkt von NAV 3.70 nach NAV 2015 über NAV 2013 umzustellen.
Mit NAV 4.0 nach NAV 2015 funktioniert das ganz gut, da hier hauptsächlich Felder gelöscht werden, die sich per SQL-UPDATE binnen Minuten bearbeiten lassen, C/AL aber gefühlte Ewigkeiten benötigen würde.

Ach ja eine Sache noch: der NST und der SQL- Server sollten für diese Aktion auf physikalisch unterschiedlichen Rechnern mit einer sehr schnellen Netzwerkverbindung arbeiten.

Gruß, Fiddi

Hallo Fiddi,

auch wenn ich SQL beherrsche (mit Zertifikat), tue ich mir mit deiner Lösung schwer. Zum einen kann ich so ad hoc nicht alles nachvollziehen, was du hier schreibst, besonders den Satz mit dem Step1 und Step2, zum anderen gehe ich davon aus, dass das Erarbeiten einer individuellen Lösung wie du sie dir vorstellst mich mehr Zeit kostet (Testaufwand!), als wenn ich die Umstellung "klassisch" durchführe, ganz abgesehen davon, dass der Kunde diesen Aufwand mit Sicherheit nicht zahlen würde.

Dies sieht natürlich für dich anders aus, denn wenn man weiß wo man hinlangen muss und was wo und wie im Detail abläuft, ist das möglicherweise eine schnelle Sache, ich bin davon aber meilenweit entfernt.

Trotzdem danke für die Info.

Gruß, Rainer

Hallo,

fang erst mal damit an, die Routinen aus dem UpgradeToolkit durch SQL zu ersetzen, die nur Felder löschen oder auf konstante Werte setzen. Das ist relativ überschaubar, und bringt bei großen Tabellen eine Unmenge an Zeit.

Gruß, Fiddi

Jetzt ist einige Zeit vergangen und ich habe noch einiges Anderes ausprobiert, mit erstaunlichen Ergebnissen. Ich habe die Umstellung auf SQL nach hinten verschoben, so dass die Phase 1 des Upgrades noch mit der nativen Datenbank stattfindet und erst danach die SQL-Datenbank erzeugt wird. Dieses hat schon einmal die Verarbeitungszeit halbiert. Und während SQL ziemlich resistent gegen andere Einstellungsvarianten oder Wahl des Rechners war, ist die native Datenbank auf einem schnelleren Rechner mit SSD deutlich flotter. Während ich mit SQL immer 57 bis 60 Stunden gebraucht habe, bin ich jetzt unter 2 und das kann ich so lassen.

Nun habe ich noch eine einzige Bremse, und das ist das erstmalige Erstellen der SQL-Datenbank aus der Datensicherung der nativen Datenbank, und diesen Schritt kann ich nun einmal nicht vermeiden. Und das Erstellen dauert leider auch mit optimalen Einstellungen rund 8 Stunden. Hat da jemand noch eine Idee dazu?

Viele Grüße
Rainer

Dieses hat schon einmal die Verarbeitungszeit halbiert. Und während SQL ziemlich resistent gegen andere Einstellungsvarianten oder Wahl des Rechners war, ist die native Datenbank auf einem schnelleren Rechner mit SSD deutlich flotter

Das hört sich fast so an, als ob du beim SQL- Server- Rechner in der Systemsteuerung/Energieoptionen nicht auf Höchstleistung gestellt hast? Aber was das Zeitverhältnis zwischen Standard-Update und mit Hilfe von SQL- Skripten angeht, liege ich mit den SQL-Skripten sogar noch ein wenig besser

Nun habe ich noch eine einzige Bremse

Was dauert denn so lange, das Einlesen der DB oder das Aufbauen der Schlüssel? Egal wie du es machst, das Transaktionslog wird sehr groß, und sollte(muss) eigentlich auf einem anderen physikalischen Laufwerk als die Datenbank laufen (SSD sollte beim LOG nicht so wichtig sein, nur Platz ist wichtig, alle Platten sollten zu nicht mehr als 80% gefüllt sein, wenn das ganze fertig ist.).
Eine Beschleunigung könnte die Deaktivierung aller nicht Primärschlüssel vor dem Ziehen der FBK sein (das war immer meine erste Aktion bei einem native Update, alle unbenutzten Schlüssel in Step 1 zu deaktivieren). Die Schlüssel würde ich dann auch deaktiviert lassen, bis ich den endgültigen 2015- Stand einspiele. Die Konvertierung nach 2013 wirft die Schlüssel eh weg, und baut sie neu wieder auf, damit der 2015- Update noch einmal das gleiche tut, also weg damit)

Gruß Fiddi

Das hört sich fast so an, als ob du beim SQL- Server- Rechner in der Systemsteuerung/Energieoptionen nicht auf Höchstleistung gestellt hast?

Zum einen wusste ich nicht, dass das tatsächlich etwas bringt, zum anderen komme ich bei diesem Rechner nicht an die Einstellungen dran (Kundenrechner).

Aber was das Zeitverhältnis zwischen Standard-Update und mit Hilfe von SQL- Skripten angeht, liege ich mit den SQL-Skripten sogar noch ein wenig besser

Klar, wenn ich diese Skripte erst schreiben müsste, dann hätte ich nie einen Zeitvorteil

Was dauert denn so lange, das Einlesen der DB oder das Aufbauen der Schlüssel?

Das Einlesen

Egal wie du es machst, das Transaktionslog wird sehr groß, und sollte(muss) eigentlich auf einem anderen physikalischen Laufwerk als die Datenbank laufen

Wie gesagt, nicht mein Rechner

Eine Beschleunigung könnte die Deaktivierung aller nicht Primärschlüssel vor dem Ziehen der FBK sein (das war immer meine erste Aktion bei einem native Update, alle unbenutzten Schlüssel in Step 1 zu deaktivieren).

Wie machst du das? Einzeln doch sicher nicht, oder?

Gruß Rainer

Eine Beschleunigung könnte die Deaktivierung aller nicht Primärschlüssel vor dem Ziehen der FBK sein (das war immer meine erste Aktion bei einem native Update, alle unbenutzten Schlüssel in Step 1 zu deaktivieren).

Wie machst du das? Einzeln doch sicher nicht, oder?

Entweder eine Form für die Tabelle "Key" erstellen oder per Report durch diese durch.
Hier sind auch Beispiele für vergleichbare Fälle:
http://www.mibuso.com/forum/viewtopic.php?t=38168
Manche Upgrade-Toolkits benötigen ggf. einen speziellen Schlüssel in einer bestimmten Tabelle, daher also immer vorher den C/AL-Code nach SETCURRENTKEY durchforsten und diese aktiviert lassen.

TabelleKey.png

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

Das hört sich fast so an, als ob du beim SQL- Server- Rechner in der Systemsteuerung/Energieoptionen nicht auf Höchstleistung gestellt hast?

Zum einen wusste ich nicht, dass das tatsächlich etwas bringt, zum anderen komme ich bei diesem Rechner nicht an die Einstellungen dran (Kundenrechner).

Schau dir mal den Taskmanager an, mit und ohne Option, du wirst merken, das dann dann alle CPU- Kerne was tun, nicht nur die Hälfte
Es ist auch eine einschlägige Empfehlung für die SQL-Server- Einrichtung.

Aber was das Zeitverhältnis zwischen Standard-Update und mit Hilfe von SQL- Skripten angeht, liege ich mit den SQL-Skripten sogar noch ein wenig besserr

Klar, wenn ich diese Skripte erst schreiben müsste, dann hätte ich nie einen Zeitvorteilr

Das ist eigentlich nur ein fertiges Skript das Mandantenunabhängig und bis auf kleinere Anpassungen nur von der zu aktualisierenden NAV- Version abhängig ist. Dort wird pro Tabelle nur der auszuführende SQL- Befehl angepasst, das müsste ich auch in C/AL machen. Ein Alternaive kann sein, die SQL-Toool- Objekte aus dem UGT zu verwenden, und das ganze aus dem C/AL- Upgrade heraus aufzurufen, dann hast du es mit den Feldnamen etwas einfacher, und das ganze läuft synchron zum normalen Update ab.

Was dauert denn so lange, das Einlesen der DB oder das Aufbauen der Schlüssel?r

Das Einlesen

Nun, da würde ich es mal mit den Energieoptionen und den anderem Empfehlungen für die SQL-Server- Einrichtung versuchen. (was auch der Performance später zu Gute kommt) Mit dem Taskmanager würde ich auch überprüfen, wer die Rechenzeit auf dem System zieht. Ist der NAV- Client hier sehr beteiligt, mach es u.U. Sinn den NAV- Client zum einspielen der FBK auf einem anderen Rechner als dem SQL- Server laufen zu lassen. Voraussetzung ist dann allerdings eine sehr schnelle Netzwerkanbindung (>=1GB/s)

Egal wie du es machst, das Transaktionslog wird sehr groß, und sollte(muss) eigentlich auf einem anderen physikalischen Laufwerk als die Datenbank laufenr

Wie gesagt, nicht mein Rechner

Du hast nach möglichen Ursachen gefragt. Platte(n) voller als 80% >> System langsam.

Eine Beschleunigung könnte die Deaktivierung aller nicht Primärschlüssel vor dem Ziehen der FBK sein (das war immer meine erste Aktion bei einem native Update, alle unbenutzten Schlüssel in Step 1 zu deaktivieren).

Wie machst du das? Einzeln doch sicher nicht, oder?

Siehe Kowas- Antwort

Gruß Fiddi

Vielen Dank für eure Antworten! Ich werde das bei meinem nächsten Testupdate alles umsetzen, außer was die SQL-Scripts betrifft. Um das nachzuvollziehen fehlt mir die Zeit.

Ein letztes Problem habe ich noch in diesem Zusammenhang, dann soll's auch gut sein: In der Datenbank stecken hunderte (!) von Objekten, die aus Modulen stammen, die der Kunde nicht mehr nutzt. Die Kundenlizenz sieht zwar die Nutzung dieser Objekte vor, nicht aber deren Löschung. Beispiele sind Lohn und Gehalt oder Easy Archiv. Das einzige, was ich nun machen kann, um diese Objekte loszuwerden, ist in SQL diese aus der Objekttabelle zu löschen, dann einen (Classic-)Backup zu machen und diesen Backup in eine neue DB einzulesen. Dann sind diese Tabellen auch physikalisch verschwunden. Aber das kostet ja Zeit, viel Zeit. Man könnte zwar die Tabellen in SQL physikalisch löschen, aber bei der Vielzahl der Tabellen müsste dies automatisch, also durch ein Skript geschehen können. Hat das schon irgendjemand von euch gemacht oder gibt es da irgendwo eine Anleitung? Oder eine bessere Lösung?

Erstelle mit deiner Partnerlizenz eine Killer-fob. Mit Hilfe dieser kann der Kunde mit seiner Kundenlizenz die Objekte löschen.
http://navisionary.com/2015/08/how-to-d ... version-2/

Hat das schon irgendjemand von euch gemacht oder gibt es da irgendwo eine Anleitung?

Ja, mehrere SQL-Varianten dazu hier am Ende des Themas:
www.msdynamics.de/viewtopic.php?f=64&t=27324

Oder alternativ, gar nicht so weit weg: hier und drunter.

Oder alternativ, gar nicht so weit weg: hier und drunter.

2 Dumme, 1 Gedanke (das ist das gleiche Thema )

Oder alternativ, gar nicht so weit weg: hier und drunter.

2 Dumme, 1 Gedanke (das ist das gleiche Thema )

Die Diskussion war ja auch lang genug, so dass man sich dran erinnern kann

Sorry, das mit den Killer-Objekten hatte ich schon mal gelesen, aber ich habe bis heute nicht verstanden, wie das genau funktioniert. Eure Beispiele bringen mich da auch nicht viel weiter.

Ich bin so vorgegangen, dass ich mit einem DELETE FROM dbo.Object ... alle Objekte, die ich nicht gebraucht habe, weggehauen habe. Das funktioniert außer bei den Tabellen perfekt. Jetzt muss ich aber die Tabellen, die noch Daten emthalten, auch irgendwie noch wegbekommen. Gibt es da nicht einfachere Möglichkeiten? Ich habe doch in der Objects-Tabelle die Namen der Tabellen, die zu löschen sind?

Wahrscheinlich gibt es jetzt den einen oder anderen, der mich für zu dumm hält, aber ich denke, es gibt viele, die sich einfach nicht trauen, das zuzugeben, dass sie es auch nicht auf Anhieb verstehen.

Gruß

Rainer