SQL bei Upgrade auf Nav2013

Hallo zusammen!

Ich bin neu hier und hoffe, einige Antworten zu finden...
WIr wollen im Frühsommer von Nav 4.0 auf Nav 2013 migrieren und befinden uns jetzt in der Planungsphase. Unser NAV- Partner möchte mit einer Hardwareempfehlung nicht wirklich rausrücken und unser Systemhaus kann die Nav und ihre SQL- Bedürfnisse nicht einschätzen...

So auch meine ersten Fragen:
Wir wollen auf SQL- Server 2012 Standard umsteigen. Der Express erscheint uns zu dünn. Gibt's die Lizenzen dafür bei NAV2013- Erwerb noch vergünstigt?
Hat jemand Erfahrungen für eine sinnvolle Hardwarelösung für einen Umfang von ca. 20 Nav- Lizenzen unter SQL (jetzige DB- Größe native 4.0 8GB)? Die Mindestanforderungen von MS erscheinen uns nicht wirklich hilfreich. Wir wollen eine Hardware aufbauen, die sowohl Nav2013- als auch die SQL- Aufgaben in einer moderaten Geschwindigkeit lösen kann. Es muss kein Mercedes sein, aber eine Ente eben auch nicht. Welche anderen Randbedingungen sollte man dabei beachten?

Vielen Dank für Eure Hilfe!

Wie groß ist den die DB jetzt; wie viele User? Wie viele VK/EK-Aufträge je Tag? Wechle Module verwendet Ihr und wie viele Transaktionen finden dort statt? etcpp

Also unsere Datenbank:
Datenbank belegt: 4.720.672kB (NAV 4.0)
Datenbank gesamt 8.100.000kB
10 Userlizenzen --> sollen aber aufgestockt werden auf ca. 20.

Module: Einkauf, Verkauf, Produktion, Lager, Verwaltung, Finanzmanagement, Personalmanagement --> keine Ressourcen, kein Lohn

Also unsere Transaktionen sind durchschnittlich pro Tag 30 EK Bestellungen / Rechnungen, 20 VK- Aufträge, 100 Kapazitätsbuchungen und zusätzliche Lagerbuchungen sind vernachlässigbar. Wir sind ein Lohnfertiger und nutzen Nav vorwiegend zur Steuerung / Einbindung unserer Produktion in die Fibu.

Hallo,

zunächst einmal herzlich willkommen im Forum.

Zu deinen Anforderungen (20 User/8GB-DB Größe) ist keine besondere Hardware nötig. (evtl. wäre noch interessant wie lange ihr schon damit arbeitet).

Was mich ein wenig stutzig macht, sind 20 Benutzer und nur 8GB-DB Größe.
Entweder nutzt ihr NAV noch nicht sehr lange, oder nur zum Teil (nur Buchhaltung), oder du hast nur einen Datenbankteil gesehen. Deine Größenangabe stammt aus "Datei\Datenbank\Informationen"!?

Also unsere Datenbank:
Datenbank belegt: 4.720.672kB (NAV 4.0)
Datenbank gesamt 8.100.000kB
10 Userlizenzen --> sollen aber aufgestockt werden auf ca. 20.

Ah: das erklärt einiges. Wenn sich euer Buchungsverhalten nicht durch neue Aktivitäten ändert (intensive Benutzung der Auftragsbearbeitung, detailliertere Buchung der Fertigung), solltet ihr keine großen Überraschungen erleben, was die DB- Größe angeht.

Da Ihr dann ja wahrscheinlich eh eure Hardware aktualisieren müsst (NAV 2013 erfordert Windows 7 auf den Clients und eine Windows 2008 Domänenstruktur auf dem Server) ((Systemanforderungen NAV2013), wäre ein Windows SBS 2011 Server Premium mit 24-32GB Arbeitsspeicher, 3+X RAID1- Laufwerke (300GB System, 146 GB SQL-Log,146 GB SQL-DB, +X*Y GB-Laufwerke für eure Dateiablage meine Standardempfehlung.
Wieviel Server/Plattenplatz/Arbeitsspeicher/Prozessoren ihr letztendlich wirklich benötigt hängt davon ab, was ihr sonst noch alles an Daten bewegt. Evtl. könnte man auch noch eines der beiden SQL- Laufwerke einsparen, wenn ihr das SQL- LOG auf eines der anderen Laufwerke legt (Nicht auf die SQL- DB- Laufwerk, SQL-LOG + SQL-DB sollten aus Sicherheitsgründen auf physikalisch getrennten Laufwerken liegen.)

Windows SBS2011- Server Premium hätte für euch den Vorteil, das ihr die darin enthaltene SQL-Server 2008 Standard- Lizenz auch für andere Aufgaben nutzen könntet, und nicht nur für NAV wie es bei der über NAV lizensierten SQL-Server Version der Fall ist.

Gruß, Fiddi

Gruß, Fiddi

[...] wäre ein Windows SBS 2011 Server Premium mit 24-32GB Arbeitsspeicher, 3+X RAID1- Laufwerke (300GB System, 146 GB SQL-Log,146 GB SQL-DB, +X*Y GB-Laufwerke für eure Dateiablage meine Standardempfehlung.

Der SBS ist bereits abgekündigt.

Der SBS ist bereits abgekündigt.

Deshalb kann man Ihn aber doch trotzdem bis Ende Nov 2013 kaufen.
Enthält er doch Standard- Komponenten, die noch nicht abgekündigt sind. Außerdem ist das z.Zt. die mit Abstand günstigste Lösung um noch an die benötigte Funktionalität zu kommen.

Wer allerdings zusätzliche Anforderungen an das System hat (Ausfallsicherheit, Virtualisierung, Erweiterbarkeit,...) muss sich natürlich auch mit den normalen Servern auseinander setzen.

Gruß, Fiddi

Ich hätte da noch ein anderes Lösungsszenario.

Windows 2012 Standard mit Software Assurance -> Nutzen des Downgrade-Rechts auf Windows 2012 Essential (= bis 25 User)

Bis jetzt nicht spannend, aber in o. g. Szenario installiert man Windows 2012 Standard als Host, Windows 2012 Essential als ersten Gast und darf einen weiteren Gast in einer VM installieren. Windows 2012 Essential erlaubt Inplace-Update auf Standard bei Bedarf (geht beim SBS nicht).

Bei o. g. Größe der DB und User-Anzahl dürfte die Express-Version (max 10 GB DB, 1 CPU) ausreichen. 1CPU ist eine physische CPU mit x Kernen. Wenn dann die Expressversion nicht mehr reicht kann man immer noch einfach auf die SQL-Standard-Version updaten.

Viel günstiger und gleichzeitig mit viel Luft nach oben wird es wohl nicht gehen.

Volker

Bei o. g. Größe der DB und User-Anzahl dürfte die Express-Version (max 10 GB DB, 1 CPU) ausreichen.

Ich vermute mal das die 10GB schon beim Einspeilen der FBK platzen werden, spätestens aber beim Update auf 2013. Und mit 1GB Arbeitsspeicher wird das Arbeiten auch keinen Spaß machen.

Wenn er dann auch noch mehr User mit mehr Buchungen hat, kommt er damit mit Sicherheit nicht sehr weit.

Gruß, Fiddi

1GB Arbeitsspeicher ist absolut inakzeptabel für jede Produktivinstallation.

Hat schon mal jemand die Auswirkungen des Arbeitsspeichers des SQL-Servers getestet?

In einem anderen Thread geht es gerade um die Performance von NAV 2013 gegenüber den Vorversionen. Gerade in dem Zusammenhang, muss man doch überlegen wird die Arbeitslast tatsächlich trägt. SQL-Server oder NST? Ich habe hier nur 2009 aber da geht beim Arbeiten mit dem RTC (öffnen der Artikelliste, bearbeiten eines Artikels) die Last und RAM-Verbrauch auf dem NST hoch. Am SQL tut sich aber nix. Wenn man dann die angeblichen Performanceverbesserungen für NAV2013 hinzuzieht, bei dem NST ja wohl erheblich effektiver arbeitet, ist es doch durchaus möglich, dass ein kleiner SQL-Server bei 20 Usern erst mal ausreicht. Vor allem wenn man bedenkt wo die Express-Version noch als Unterbau alles läuft (Im SBS für WSUS und Sharepointdienste für bis zu 75 User, TMG als Log, divere Backup-Programme und Virenscanner).

Volker

Hat schon mal jemand die Auswirkungen des Arbeitsspeichers des SQL-Servers getestet?

In einem anderen Thread geht es gerade um die Performance von NAV 2013 gegenüber den Vorversionen. Gerade in dem Zusammenhang, muss man doch überlegen wird die Arbeitslast tatsächlich trägt. SQL-Server oder NST? Ich habe hier nur 2009 aber da geht beim Arbeiten mit dem RTC (öffnen der Artikelliste, bearbeiten eines Artikels) die Last und RAM-Verbrauch auf dem NST hoch. Am SQL tut sich aber nix. Wenn man dann die angeblichen Performanceverbesserungen für NAV2013 hinzuzieht, bei dem NST ja wohl erheblich effektiver arbeitet, ist es doch durchaus möglich, dass ein kleiner SQL-Server bei 20 Usern erst mal ausreicht. Vor allem wenn man bedenkt wo die Express-Version noch als Unterbau alles läuft (Im SBS für WSUS und Sharepointdienste für bis zu 75 User, TMG als Log, divere Backup-Programme und Virenscanner).

Volker

Die Service-Tier setzt ja auch nur SQL Statements ab. Der (SQL-)Arbeitsspeicher wird ja genutzt um einen Cache anzulegen, um die statistisch erwarteten Abfragen schnell abzuarbeiten. Es gibt dafür einen eigenen KPI "Cache Hit Ratio" vom SQL Server.
Da wo die Relation zwischen Arbeitsspeicher und Größe/Nutzung der Datenbank (grob betrachtet!) nicht stimmt, ist die Performance des SQL Servers "suboptimal", da die Daten von der Platte nachgeladen werden müssen.

Also unsere Transaktionen sind durchschnittlich pro Tag 30 EK Bestellungen / Rechnungen, 20 VK- Aufträge, 100 Kapazitätsbuchungen und zusätzliche Lagerbuchungen sind vernachlässigbar. Wir sind ein Lohnfertiger und nutzen Nav vorwiegend zur Steuerung / Einbindung unserer Produktion in die Fibu.

Hi Jan,

das beim SQL-Server mehr RAM immer gut ist ist ja keine Frage. Aber bei der Buchungsmenge oben fällt das wohl nicht wirklich ins Gewicht. Wobei ich zugegebenermaßen das Verhältnis von Buchungen/Transaktionen zu Userlizenzen nicht verstehe. Bei aktuell 10 Usern sind das 15 Aktionen/User+Tag, bei den neu angedachten 20 Usern ist da ja noch mehr Luft. Das hört sich nach einem sehr entspannten Job an. Da produziert unsere Kasse allein ja mehr Buchungen am Tag.

Ich habe auch nochmal den RAM-Verlauf (RTC 2009) angesehen. Mit jedem neu geöffneten/benutzten RTC steigt der RAM-Verbrauch des NST, nicht aber des SQL-Servers. Nadelöhr beim Arbeiten ist ja wohl auch eher NST und nicht der SQL-Server. Ich da noch was von ca. 30-70 User/NST für NAV2009 im Kopf, evtl. ist das jetzt bei NAV2013 besser. SQL-Server ist da wohl unproblematisch.

Volker

Ich habe auch nochmal den RAM-Verlauf (RTC 2009) angesehen. Mit jedem neu geöffneten/benutzten RTC steigt der RAM-Verbrauch des NST, nicht aber des SQL-Servers. Nadelöhr beim Arbeiten ist ja wohl auch eher NST und nicht der SQL-Server. Ich da noch was von ca. 30-70 User/NST für NAV2009 im Kopf, evtl. ist das jetzt bei NAV2013 besser. SQL-Server ist da wohl unproblematisch.

Der SQL- Server verbraucht soviel Speicher wie er bekommt oder soviel wie man ihm lässt.
Desweiteren hängt das sehr davon ab, was man damit veranstaltet. Bei sehr postenlastigen Auswertungen wird sicherlich mehr Speicher benötigt, als bei Buchungsroutinen, die nur Posten hinzufügen.

Die "Cache Hit Ratio" ist schon ein guter Indikator für den Speicher bedarf.

Gruß, Fiddi

Hallo alle zusammen!

Ich danke euch für eure Beiträge und werde dies bei uns mal zur Diskussion stellen!

Danke, Tina!

Also unsere Transaktionen sind durchschnittlich pro Tag 30 EK Bestellungen / Rechnungen, 20 VK- Aufträge, 100 Kapazitätsbuchungen und zusätzliche Lagerbuchungen sind vernachlässigbar. Wir sind ein Lohnfertiger und nutzen Nav vorwiegend zur Steuerung / Einbindung unserer Produktion in die Fibu.

Hi Jan,

das beim SQL-Server mehr RAM immer gut ist ist ja keine Frage. Aber bei der Buchungsmenge oben fällt das wohl nicht wirklich ins Gewicht. Wobei ich zugegebenermaßen das Verhältnis von Buchungen/Transaktionen zu Userlizenzen nicht verstehe. Bei aktuell 10 Usern sind das 15 Aktionen/User+Tag, bei den neu angedachten 20 Usern ist da ja noch mehr Luft. Das hört sich nach einem sehr entspannten Job an. Da produziert unsere Kasse allein ja mehr Buchungen am Tag.

Analyseansichten automatisch beim Buchen aktualisieren, dann wird das Ganze schon etwas komplexer Da ist nicht nur die Anzahl der User entscheidend, sondern auch die Anzahl der automatisch upzudateten Analyseansichten.
Automated Cost Posting "Always" kann auch nochmal für die Komplexität beitragen.