Empfohlene Datenbankversion

Hallo,

wir planen zum Jahreswechsel eine Umstellung von Navision 3.7 (technisch 2009) auf NAV2013.
Zur Zeit sind es 90 Anwender und die Datenbankgröße ist ca. 180 GB.

Nav 3.7 DB-Server: MS SQL 2005 Standard, 2 x Dual-Core Xeon 5140 CPU, 32GB RAM, Raid 10 (Performance ist OK)
NAV2013 DB-Server: MS SQL 2012, 2 x Hexa-Core Xeon 2640 CPU, 64 GB RAM, Raid 10

Durch das neue Lizenzprogramm von Microsoft ist es leider nicht ganz so einfach zu entscheiden, welche Datenbankversion für NAV2013 Sinn macht, da die Preisunterschiede doch beträchtig sind. Unser Partner schlägt uns die Enterprise-Version mit 128 GB RAM vor, da er damit auf der sicheren Seite liegt, doch das erscheint mir ein wenig überdimensioniert.

Welche SQL 2012 Server-Lizenz ist für unsere Umgebung empfehlenswert?
- Standard 8 Kerne
- Standard 90 CALS (alle 12 Kerne)
- Enterprise 8 oder 12 Kerne

Gruß
Hubertus

Hallo Hubertus,

das ist schwer zu beantworten. Ich betreue z. B. Unternehmen, die haben 2 gut dimensionierte Server. SQL und Anwendungsserver laufen jeweils mit 64 GB RAM, im Durchschnitt 8 Kerne und ausreichend Plattenplatz. Die Frage ist auch, virtualisiert ihr oder stellt ihr euch 2 physikalische Maschinen hin? Die Eckwerte von Microsoft bspw. sind zwar hilfreich, aber es ist halt auch eine
Minimalanforderung, z. B. 10 GB pro 100 User NST. Einen Hardwareguide wird es voraussichtlich erst ab September geben.

Wenn nur die NAV Datenbank auf dem SQL Server läuft, dann reicht meiner Meinung nach auch ein SQL 2012 Standard aus. Sind weitere Elemente bspw. DWH etc. geplant, dann sollte man größer dimensionieren. SharePoint, Dynamics CRM, DMS-Systeme etc. lässt man am besten eh auf eigene Serverumgebungen laufen.
Arbeitsspeicher ist so gesehen das Zauberwort. Da in NAV 2013 die Reports (so gesehen) nur noch Query-basierte Abfragen machen und Daten aufbereiten, so landen diese im Cache und brauchen dann für das Bereitstellen ausreichend Arbeitsspeicher. Die Anforderungen hinsichtlich RAID 10 hat sich nicht geändert.

Das so mal meine Meinung dazu. Vielleicht hat ja noch jemand eine andere Idee....
Viele Grüße
Michael

Hallo Michael,

anscheinend ist es doch nicht so einfach, eine Empfehlung zu erhalten, daher hier noch ein paar weitere Infos

- Der Datenbankserver und die geplanten drei Anwendungsserver sind einzelne HP ProLiant-Server.
- Auf dem Datenbankserver läuft nur die Navision-Datenbank.
- Eine aus den Navision-Daten erstellte MS SQL 2012 BI-Datenbank würden wir ggf. auf einen anderen Server auslagern.

Gruß
Hubertus

Was davon (http://www.microsoft.com/de-de/server/sql-server/2012/editionen.aspx) braucht Ihr ggf. für eure Umgebung bzw. BI-Lösung? Da könnte sich ggf. die Frage nach Enterprise oder nicht schon erledigt haben.

Volker

Hallo,

zunächst brauchen wir nur die Funktionen der Standardversion, aber die Enterpriseversion bietet zusätzlich die Möglichkeit mehr als 64GB RAM zu verwenden und die Datenkomprimierung.

Gruß
Hubertus

Datenkomprimierung würde ich jetzt erstmal nicht einsetzen wollen.
Mehr als 64 GB RAM könnten sinnvoll sein, aber dazu stehen dafür zu wenig Infos (Auftrags-/Buchungsmengen etc)

Wir haben Navision seit 2005 im Einsatz und da hat sich schon einiges angesammelt

Unsere größten Tabelle sind

17 G/L Entry, 25 Mio. Datensätze, 15 GB
37 Sales Line, 4 Mio. Datensätze, 10 GB
111 Sales Shipment Line, 4 Mio. Datensätze, 8 GB
113 Sales Invoice Line, 4 Mio. Datensätze, 5 GB
32 Item Ledger Entry, 4 Mio. Datensätze, 2 GB
74016 Item Ledger Entry history, 2 Mio. Datensätze, 2 GB

alle andere Tabellen sind wesentlich kleiner mit max. 500 Ts. Datensätze und max. 500 MB Größe

37 Sales Line, 4 Mio. Datensätze, 10 GB

warum ist eure "Sales Line" so groß. Löscht ihr erledigte Aufträge nicht? Normalerweise sollten da nur die aktuellen noch nicht komplett fakturierten Aufträge drin sein.

Gruß, Fiddi

Die Tabelle Sales Line enthält unheimlich viele Angebote die auf keinen Fall gelöscht werden dürfen , auch wenn wir die meisten nach drei Jahren dann doch wieder entfernen.

Die Tabelle Sales Line enthält unheimlich viele Angebote die auf keinen Fall gelöscht werden dürfen , auch wenn wir die meisten nach drei Jahren dann doch wieder entfernen.

Deswegen gibt es die Archivierungsfunktion nicht nur für Sales Orders sondern auch für Sales Quotes.

74016 Item Ledger Entry history, 2 Mio. Datensätze, 2 GB

Das ist eine Individualtabelle. Wozu soll die gut sein bzw. wird die wirklich aktuell noch gebraucht?

Gut, daß wir darüber gesprochen haben
Die Tabelle wird nicht produktiv genutzt und enthält Daten aus dem Altsystem (InfoSoft, falls das einer kennen sollte). Die Daten werden wir nicht nach NAV2013 übernehmen.

Ihr nutzt doch nur den SQL-Server auf der Maschine, oder? Dort habt Ihr 12 Kerne, denkt aber darüber nach nur 8 zu lizenzieren? Was sollen die restlichen Kerne machen?

Ist abzusehen, dass es neue User geben wird? So wie ich das sehe, seid Ihr genau an der Grenze, ab der die Lizenzierung nach Kernen günstiger wird als CALs.

Könnt Ihr euch ggf. einen eigenen BI-Server sparen wenn Ihr die Features der Enterprise-Version und dann nur einen Server nutzen könnt? Dazu zählt auch dass man dem SQL-Server bei Bedarf noch zusätzlich RAM spendieren könnte.

Weitere Überlegung: Was ist mit externem Zugriff (Lieferanten, Handelsvertreter, Agenturen, Webshop,...)? Kommt das, gibt es dafür schon CALs?

Volker

Die Problematik sind wir auch schon durchgegangen. Die 90 Anwender werden sich die nächste Zeit nicht ändern und 4 Kerne nicht zu verwenden ist auch nicht gerade sinnvoll. Ich bin daher dafür, den Server und User-CALS zu kaufen.

Als Alternative gibt es ja noch die BI-Version vom SQL-Server, die ebenfalls über User-CALS lizensiert werden kann.
Der Preise für die Enterprise-Version ist jedenfalls drei mal so teuer wie die Standard-Version und immer doppelt so teuer wie die BI-Version.

warum redet ihr eigentlich immer üner "Kerne" die Lizensierung des SQL-Server geschieht doch über "Sockets" also wenn das eine CPU mit 6 Kernen ist, dann müsst ihr 1 CPU lizensieren.

und:
Was spricht gegen den 2005er SQL-Server den Ihr bereits habt? der hat meines Erachtens keinerlei RAM-Begrenzung. oder läuft da NAV 2013 nicht drauf?
wir planen einen ziemlich ähnlichen Umstieg.

SQL2012 wird mit einer Ausnahme per Core lizensiert, und NEIN NAV 2013 benötigt mindestens SQL2008

Gruß Fiddi

yessas. ok, mein Fehler.

Ich komme nochmal zurück auf die Datenmengen. Ich glaube das es entscheidend vom Vorteil wäre zu schauen, was für Daten beibehalten werden und welche nicht.
Ggf. kann das Datenvolumen heruntergeschraubt werden. Auch die notwendigen Tabellen sollten dann nochmal begutachtet werden. Wenn ihr seit 2005 mit NAV arbeitet, so hat sich
in der Zeit einiges getan, auch innerhalb von NAV, was evtl. einiges erleichtert. Und selbst die Komprimierung von Datensätzen ist in NAV ja möglich.

Fiddi hat beim SQL recht... NAV braucht mind. 2008 und wenn es um Funktionalitäten wie Always-on geht, so hat diese nur der 2012er SQL.
Bei BI macht ihr doch bestimmt Snapshots und bereitet dagegen Euer Reporting auf, damit die Live-DB nicht belastet wird. Ggf. kann man hier noch für Abhilfe sorgen...



Viele Grüße!
Michael

Und selbst die Komprimierung von Datensätzen ist in NAV ja möglich.

Dies ist zwar theoretisch möglich, ist aber mit sehr vielen Einschränkungen verbunden. Daher sollte man von einer Komprimierung der Daten absehen.

Gruß, Fiddi