none
Performence SQL auf W10 oder auf Server 2016 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hat jemand Erfahrung, wie sich die Performance auf den SQL Server 2016 Standard verhält, wenn man Ihn

    auf einem Windows 10 Pro 64 bit laufen lässt, oder auf einem Windows Server 2016 64 bit?

    Der Kunde möchte nicht extra eine Server Lizenz erwerben, und will gerne einen Windows 10 Pro 64 bit mit einem SQL Server Standard 64 bit kaufen. Diese Windows 10 Pro 64 bit PC ist dann in der Domain integriert.

    Test haben ergeben, dass dies schnell läuft (Hardware ist die neuste Server Hardware, sogar mit SSD Platten für die Performance sowie 64 GB Ram) 

     Danke für eure Erfahrung
    Donnerstag, 11. Mai 2017 12:06
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Wenn man bei der Ermittlung der Performance nur auf das Betriebssystem sollte es kaum messbar sein ob Win10 Pro oder Server 2016 Pro. Jetzt kommt jedoch das große ABER. Ein Serverbetriebssystem ist eine ganz andere Sache als ein Desktopbetriebssystem. So kann man zb. das Server-OS stark abspecken. Das kann schon bei der Auswahl des Server OS beginnnen. Man könnte hier auch mit Varianten wie Nano oder Core arbeiten. Das mindert den Updatezyklus Emmens. Diverse Update werden gar nicht benötigt.

    Ein weiterer Punkt ist die Sicherheit. So fängt es bei Kleinigkeiten schon an. Ein Server-OS führt keine Animiertengifs aus ein Desktop-OS schon. Dies ist zwar nur ein sehr primitives Beispiel, zeigt aber das aus meiner Sicht ein Desktop OS ungeeignet ist für den Professionellen Einsatz im Unternehmen. Du kannst auch gern hier die technischen Details des Systems hier vorstellen. Vorsicht auch bei der Konfig. Das Thema ist eben doch komplexer als man manchmal denkt.

    Donnerstag, 11. Mai 2017 20:05
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Die Performance ist i.W. nicht von der Windows-Umgebung sondern von der Gestaltung der Abfragen abhängig.
    Optimierungen siehe hier:
    https://msdn.microsoft.com/de-de/library/ms174202.aspx?f=255&MSPPError=-2147217396

    Das andere Problem der Performance sind ggf. zu viele Indizes bei Insert/Update/Delete, die natürlich alle mit gepflegt werden müssen.
    Und was auch nicht zu verachten ist, ist das Datenbank-Journal, in dem alle Transaktionen aufgezeichnet werden um statt eines Commit auch mal einen Rollback machen zu können.
    Dieses Journal wird immer am Ende fortgeschrieben!
    Ich hatte da mal einen krassen Fall, dass bei einer 300MB-Datenbank das Journal mittlerweile 20GB groß geworden ist. Eine Transaktion, die bei ca. 400.000 Datensätzen 1 Feld upgedatet hat, lief ca. 30 Minuten.
    Nach Bereinigung des Journals auf wenige MB, dauerte die Transaktion nur noch knapp 1 Minute.

    Es gibt also doch so einige Faktoren, die eine SQL-Anwendung ziemlich beeinträchtigen können.

    Donnerstag, 11. Mai 2017 12:19
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    die Performance ist maßgeblich von der technischen Auslegung des Servers geprägt. Wenn du alle erforderlichen Dateien auf C: & D: ablegst, bringt das nix, und zieht die Performance runter.

    Kannst du bei dem von dir beschriebenen Server die erforderlichen Laufwerke anlegen/trennen?

    Also TempDB, Logfiles, Datafiles, Backups, SQL Server binary, etc sollten dann auf getrennten Platten sein, da sich diese vom Schreib-Lese-Zugriff doch stark unterscheiden.

    Läuft dann auch wirklich nur der SQL Server auf dem PC, oder werden dort noch andere Anwendungen laufen, oder arbeitet gar jemand damit?

    Sonst müssten man wissen, was du an Datenbanken darauf laufen lassen willst, also Größe, mögliche Zugriffe, Batchverarbeitungen und so vieles mehr. Eine pauschale Aussage ist hier schwierig.

    Donnerstag, 11. Mai 2017 12:29
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    um eine Aussage über die Performance zu machen sollte man mit vielen gleichzeitigen Zugriffen testen. Hier mal ein Tool um mal richtig Last auf dem System zu erzeugen https://www.microsoft.com/en-us/download/details.aspx?id=8161

    Meine persönliche Erfahrung ist dass die Server Systeme deutlich besser mit vielen gleichzeitigen Zugriffen umgehen können als die Client OS. Dies hängt aber natürlich sehr vom Workload und der Nutzeranzahl ab. Zudem sind die Server OS Systeme natürlich mehr auf Hintergrundverarbeitung (Services) ausgelegt als die Client OS's.

    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Donnerstag, 11. Mai 2017 16:32
    |
  • Question
    Anmelden
    0
    Anmelden

    Wenn man bei der Ermittlung der Performance nur auf das Betriebssystem sollte es kaum messbar sein ob Win10 Pro oder Server 2016 Pro. Jetzt kommt jedoch das große ABER. Ein Serverbetriebssystem ist eine ganz andere Sache als ein Desktopbetriebssystem. So kann man zb. das Server-OS stark abspecken. Das kann schon bei der Auswahl des Server OS beginnnen. Man könnte hier auch mit Varianten wie Nano oder Core arbeiten. Das mindert den Updatezyklus Emmens. Diverse Update werden gar nicht benötigt.

    Ein weiterer Punkt ist die Sicherheit. So fängt es bei Kleinigkeiten schon an. Ein Server-OS führt keine Animiertengifs aus ein Desktop-OS schon. Dies ist zwar nur ein sehr primitives Beispiel, zeigt aber das aus meiner Sicht ein Desktop OS ungeeignet ist für den Professionellen Einsatz im Unternehmen. Du kannst auch gern hier die technischen Details des Systems hier vorstellen. Vorsicht auch bei der Konfig. Das Thema ist eben doch komplexer als man manchmal denkt.

    Donnerstag, 11. Mai 2017 20:05
    |
  • Question
    Anmelden
    0
    Anmelden
    Danke für Deine Info. Im SQL haben wir sowieso jedne Tag Wartungspläne, die ausgeführt werden, um das Inden neu aufzubauen und das Log zu verkleinern. Es geht rein um den Unterschied, ob es auf Windows 10 oder auf Windows 2016 läuft
    Freitag, 12. Mai 2017 05:56
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke dir für Deine aussagt.SQL wird auf dem LW c: installiert. Die DB und LBF wird dann auf einer anderen SSD Partition (LW) gespeichert, damit das auch getrennt ist.

    Freitag, 12. Mai 2017 05:59
    |
  • Question
    Anmelden
    0
    Anmelden

    Eine Trennung einer Platte in Partitionen bringt überhaupt keinen Vorteil, da es sich ja immer noch physisch um dieselbe Platte handelt. Bei einer SSD ist das nicht so kriegsentscheidend, allerdings kann die DB dann nicht so groß werden.
    Geschwindigkeitsvorteile kannst du nur mit getrennten physikalischen Laufwerken erreichen, viel Hauptspeicher, so dass große Teile der DB dann schon mal im Speicher gecached werden.
    Zusätzlich sollten kaum andere Anwendungen laufen, die die CPU ebenso belasten, schließlich müssen sich alle Anwendugen um dieselben Ressourcen schlagen.

    Freitag, 12. Mai 2017 06:06
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 11.05.2017 schrieb Domig Informatik AG:

    Der Kunde möchte nicht extra eine Server Lizenz erwerben, und will gerne einen Windows 10 Pro 64 bit mit einem SQL Server Standard 64 bit kaufen. Diese Windows 10 Pro 64 bit PC ist dann in der Domain integriert.

    Habt ihr die Lizenzen auch im Auge? Ein Client OS ist kein Server OS.
    Und du darfst natürlich auch nur eine begrenzte Anzahl Verbindung zum
    Clients OS herstellen. Die Anzahl der zugelassenen Verbindungen ist
    hart verdrahtet und kann IMO nicht verändert werden. Würde man die
    Anzahl der zulässigen Verbindung verändert, begeht man einen
    Lizenzverstoss. Zusätzlich brauchst Du natürlich auch CALs für den SQL
    Server.

    Im Zweifel oder bei einem Audit muss ordentlich nach lizenziert und
    bezahlt werden.

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Freitag, 12. Mai 2017 15:28
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich würde generell von einem Client-System abraten, ohne die Workload zu kennen. Wenn aber jemand darüber überhaupt nachdenkt, dann sind die Anforderungen sicher sehr gering. (Anzahl gleichzeitige Verbindungen -> CPU, RAM)

    Gerade was gleichzeitige Prozesse angeht, gibt es Unterschiede zwischen der Verarbeitung auf einem Client- vs Serverbetriebssystem. Hintergrund ist das unterschiedliche OS-Quantum.

    Aber wie gesagt, wenn er nicht so hohe Auslastung erwartet, mag das negier bar sein.

    Bleibt die Supportbarkeit. Ein Troubleshooter wird erstmal die Hände über dem Kopf zusammenschlagen. Und bei der Ursachensuche all die auf einem Server normalerweise nichtexistierenden Faktoren ausschließen müssen.

    Ein Spezialist für die Express Edition mag das aber gewohnt sein.
    Ich persönlich habe noch nie ein Client-System bei einem Kunden erlebt (ok, eine Ausnahme, und das war ein Fehler, der dann behoben wurde), aber das hängt mit meiner Zielgruppe zusammen.

    Also, wie immer: It depends. Ich hoffe das hilft.

     

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Freitag, 19. Mai 2017 09:04
    |