[Gelöst] Von 3.70B Native zu SQL wechseln? Macht das Sinn?
10. Juni 2008 20:13
Hallo an alle,
nach dem ich mich nun mit der Leistungsteigerung unserer Datenbank und der Anschaffung eines neuen Servers ausgiebig beschäftig habe, höre ich nun von mehreren Seiten, das es wenig bringen wird einen Neuen Server für eine Native DB (38GB) anzuschaffen. Da wir vorhatten die DB von 2 DB-Teilen auf 4 DB-Teile zu Erweitern und das mit Raid10 käme ja nur ein SAN in Frage, welches die 16 Platten aufnehmen kann. Da auch dieses Rechen-Leistung benötig, würde diese der Native DB abgezwackt, da die Native ja auch nur eine CPU unterstüzt. Weil man sich ja so einen Server auch nicht nur für 1-2 Jahre anschafft, sollten wir doch gleich auf SQL umstellen, da würde man mit den heutige CPU (Quad & Co.) und den verfpgbaren RAM Möglichen auch ordenlich was erreichen können.
Deshlab mein Frage an Euch!! Mach es Sinn von Native auf SQL umzusteigen?? Was denkt Ihr dazu?
Da ich die Einfacheit von Native eigentlich liebe würde mir dieser Schritt auch sehr schwer fallen, ausser es bringt wirklich was.
Im Voraus schon vielen Dank.
Andi
PS: Gibt es für eine solche Umstellung irgendwo ein Todo, was alles gemacht und beachtet werden muss? Habe nix gefunden.
nach dem ich mich nun mit der Leistungsteigerung unserer Datenbank und der Anschaffung eines neuen Servers ausgiebig beschäftig habe, höre ich nun von mehreren Seiten, das es wenig bringen wird einen Neuen Server für eine Native DB (38GB) anzuschaffen. Da wir vorhatten die DB von 2 DB-Teilen auf 4 DB-Teile zu Erweitern und das mit Raid10 käme ja nur ein SAN in Frage, welches die 16 Platten aufnehmen kann. Da auch dieses Rechen-Leistung benötig, würde diese der Native DB abgezwackt, da die Native ja auch nur eine CPU unterstüzt. Weil man sich ja so einen Server auch nicht nur für 1-2 Jahre anschafft, sollten wir doch gleich auf SQL umstellen, da würde man mit den heutige CPU (Quad & Co.) und den verfpgbaren RAM Möglichen auch ordenlich was erreichen können.
Deshlab mein Frage an Euch!! Mach es Sinn von Native auf SQL umzusteigen?? Was denkt Ihr dazu?
Da ich die Einfacheit von Native eigentlich liebe würde mir dieser Schritt auch sehr schwer fallen, ausser es bringt wirklich was.
Im Voraus schon vielen Dank.
Andi
PS: Gibt es für eine solche Umstellung irgendwo ein Todo, was alles gemacht und beachtet werden muss? Habe nix gefunden.
Zuletzt geändert von MBSNAV3.70 am 11. Juni 2008 12:48, insgesamt 3-mal geändert.
11. Juni 2008 01:04
Rein technisch gesehen ist eine Umstellung von Native auf SQL problemlos möglich und ruckzuck erledigt.
ABER:
Wer einfach nur eine Datensicherung zieht und in SQL wieder einspielt wird zu tiefst enttäuscht.
Erst recht, wenn es noch eine 3.70-DB ist, da sich mit jeder Version viel in Sachen SQL-Optimierung getan hat.
Manche Versuche gingen zwar mehr oder weniger nach hinten los, aber das gehört zum Lernprozess dazu. (Stichwort: Index-Hinting)
Ob sich die Umstellung auf SQL lohnt hängt von mehreren Faktoren ab.
Fakt ist: Der SQL-Server ist ein Kraftpaket mit vielen Möglichkeiten, wovon Navision nur die Basics nutzt.
Wenn dann noch die finsql.exe suboptimale SQL-Statements generiert, dann kann man nur zusammenfassend sagen:
"Shit in - Shit out"
Dynamics NAV wird mit jeder Version ein wenig besser, was die SQL-Performance angeht.
Solange aber noch die Native-DB unterstützt wird (und das wird noch eine Zeit lang der Fall sein), kann Dynamics NAV (aus Kompatibilitätsgründen) nicht alles aus dem SQL-Server herauskitzeln.
Dynamics NAV 5.00 SP1 bietet hier schon deutliche Verbesserungen, aber es reicht leider nicht, einfach nur eine aktuelle RunTime auf eine 3.70er DB anzusetzen.
Auch der C/AL-Code muss die neuesten Befehle nutzen, welche speziell für die SQL-Performance eingeführt wurden.
Das beste Ergebnis würdet ihr also erhalten, wenn ihr eure derzeitige Lösung komplett auf NAV 5.00 SP1 upgraden würdet.
Je nach dem, wieviel Individualprogrammierung sich in eurer Lösung befindet, kann dies viele Euros verschlingen, somit kann ich auch nicht sagen, ob sich eine Umstellung in Bezug auf den ROI lohnt.
Meine persönliche Meinung: Hier kann Jörg Stryk die kompetenteste Antwort liefern.
ABER:
Wer einfach nur eine Datensicherung zieht und in SQL wieder einspielt wird zu tiefst enttäuscht.
Erst recht, wenn es noch eine 3.70-DB ist, da sich mit jeder Version viel in Sachen SQL-Optimierung getan hat.
Manche Versuche gingen zwar mehr oder weniger nach hinten los, aber das gehört zum Lernprozess dazu. (Stichwort: Index-Hinting)
Ob sich die Umstellung auf SQL lohnt hängt von mehreren Faktoren ab.
Fakt ist: Der SQL-Server ist ein Kraftpaket mit vielen Möglichkeiten, wovon Navision nur die Basics nutzt.
Wenn dann noch die finsql.exe suboptimale SQL-Statements generiert, dann kann man nur zusammenfassend sagen:
"Shit in - Shit out"
Dynamics NAV wird mit jeder Version ein wenig besser, was die SQL-Performance angeht.
Solange aber noch die Native-DB unterstützt wird (und das wird noch eine Zeit lang der Fall sein), kann Dynamics NAV (aus Kompatibilitätsgründen) nicht alles aus dem SQL-Server herauskitzeln.
Dynamics NAV 5.00 SP1 bietet hier schon deutliche Verbesserungen, aber es reicht leider nicht, einfach nur eine aktuelle RunTime auf eine 3.70er DB anzusetzen.
Auch der C/AL-Code muss die neuesten Befehle nutzen, welche speziell für die SQL-Performance eingeführt wurden.
Das beste Ergebnis würdet ihr also erhalten, wenn ihr eure derzeitige Lösung komplett auf NAV 5.00 SP1 upgraden würdet.
Je nach dem, wieviel Individualprogrammierung sich in eurer Lösung befindet, kann dies viele Euros verschlingen, somit kann ich auch nicht sagen, ob sich eine Umstellung in Bezug auf den ROI lohnt.
Meine persönliche Meinung: Hier kann Jörg Stryk die kompetenteste Antwort liefern.
11. Juni 2008 02:04
Vielen Dank für die eindeutige und deutliche Info. Hatte ich mir fast schon gedacht. Diesen Schritt koennen wir erst machen, wenn zwingende wirtschaftliche Gründe vorliegen. Haben uns noch immer nicht so richtig von der Umstellung 2.6 auf 3.7 Ende 2005 erholt.
auf Grund unseres hohen Anteils an Induvidual Programierung ist das immer ein relativ grosser Akt und natürlich teuer. Vielen Dank nochmals.
Andi
auf Grund unseres hohen Anteils an Induvidual Programierung ist das immer ein relativ grosser Akt und natürlich teuer. Vielen Dank nochmals.
Andi