none
SQL Server Express as production database RRS feed

  • Frage

  • Hi all,

    there are several articles covering this issue. But it is hard to find out if Express edition is expected to be reliable in "practical use".

    I know about the limitations: max db size 10 GB, max ram 1 GB, max 4 cores.

    Facts about my database:

    • Consists of about 70 tables.
    • Max column size is 30, most tables consist of less than 15 columns.
    • Biggest table consists of about 1 million rows, most table consist of less than 10.000 rows.
    • Current db size is 1 GB. I can hardly imagine that it becomes greater than 5 GB.
    • Database is used only in the local network.
    • Database is concurrently accessed by up to 10 instances (= 10 users) of a local network application.
    • No binary data stored in db.

    Does anybody have experience with express edition in a production environment and a comparable size?

    Regards





    Montag, 25. Februar 2019 11:25

Antworten

  • Hi,

    da Du in einem deutschsprachigen Forum schreibst, antworte ich auch mal auf Deutsch.

    Man kann die Express Edition problemlos auch in einer produktiven Umgebung nutzen, bei einem geringen Daten- und Abfrageaufkommen auch für mehr gleichzeitige Zugriffe (bspw. für eine Webanwendung).

    Die Problemstelle würde ich hier beim RAM sehen. Sobald das maximale RAM verbraucht ist, wird es schon ziemlich lahm, daher würde ich mal schauen, wie es hier bei deiner Instanz aussieht.

    Ich würde es an deiner Stelle einfach mal probieren, wenn es eng wird, schauen, ob man die Datenbank optimieren kann (Abfrageaufbau, Indizes, Statistiken, usw.). Wenn es nicht klappt bzw. die Performance zu schlecht ist, analysieren, an was es liegt und falls es dann trotz Optimierungsmaßnahmen am RAM hängt, kannst Du immer noch recht schnell auf eine normale SQL Server Lizenz mit CALs gehen.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Montag, 25. Februar 2019 11:42
    Moderator

Alle Antworten

  • Hi,

    da Du in einem deutschsprachigen Forum schreibst, antworte ich auch mal auf Deutsch.

    Man kann die Express Edition problemlos auch in einer produktiven Umgebung nutzen, bei einem geringen Daten- und Abfrageaufkommen auch für mehr gleichzeitige Zugriffe (bspw. für eine Webanwendung).

    Die Problemstelle würde ich hier beim RAM sehen. Sobald das maximale RAM verbraucht ist, wird es schon ziemlich lahm, daher würde ich mal schauen, wie es hier bei deiner Instanz aussieht.

    Ich würde es an deiner Stelle einfach mal probieren, wenn es eng wird, schauen, ob man die Datenbank optimieren kann (Abfrageaufbau, Indizes, Statistiken, usw.). Wenn es nicht klappt bzw. die Performance zu schlecht ist, analysieren, an was es liegt und falls es dann trotz Optimierungsmaßnahmen am RAM hängt, kannst Du immer noch recht schnell auf eine normale SQL Server Lizenz mit CALs gehen.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Montag, 25. Februar 2019 11:42
    Moderator
  • Zudem fehlt in der Express Edition der SQL Server Agent, damit muss man geplante Aufgaben über den Windows Aufgabenplaner abwickeln. Das ist kein Hindernis aber macht mache Aufgaben etwas komplizierter, aber da vieles heute über PowerShell abgewickelt werden kann braucht dafür nicht mal umfangreiche TSQL Kenntnisse.

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

    Montag, 25. Februar 2019 13:13

  • Die Problemstelle würde ich hier beim RAM sehen. Sobald das maximale RAM verbraucht ist, wird es schon ziemlich lahm, daher würde ich mal schauen, wie es hier bei deiner Instanz aussieht.

    Kann jemand erklären, warum der RAM das System so ausbremsen kann? Der RAM wird doch für diverse Caches benötigt, soweit ich weiß.

    Nach meinen Wissen ist ja jedes DBMS darauf optimiert, möglichst schnell von der Platte zu lesen. Ich plane sowieso den Einsatz von SSDs. Ich frage mich halt, ob der fehlende RAM vom Anwender überhaupt bemerkt wird.

    Gruß

    Mittwoch, 27. Februar 2019 07:11
  • Hi,

    der Lese- und Schreibzugriff auf das RAM ist aber immer noch um den Faktor x schneller als beim Lesen/Schreiben von Platten. Der Performanceverlust verringgert sich etwas, wenn Du SSDs nimmst, noch mehr, wenn Du bspw. M.2 SSDs verwendest aber ohne ausreichendes RAM ist lt. meiner Erfahrung die Performance immer noch erheblich schlechter.

    Zudem sind SSDs nicht für eine solch extrem hohe Anzahl an Speicherzyklen gedacht, deren Lebensdauer ist meist um einiges geringer als die von hochwertigem Hauptspeicher.

    Ich bin kein Hardwarespezi, daher kann ich dir nur sagen, was mich die Erfahrungen gelehrt haben: Zuwenig Arbeitsspeicher lässt die Performance signifikant einbrechen.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Mittwoch, 27. Februar 2019 07:24
    Moderator
  • Hallo,

    Das stimmt nicht. Der SQL Server versucht Plattenzugriffe wo immer möglich zu vermeiden. Alle Operationen auf Daten laufen nur im RAM. Der SQL Server ist bemüht alle Daten die er braucht immer im RAM zu halten um direkt damit arbeiten zu können. Lesen von einer Platte wird er nur dann machen wenn er die Daten zuvor nicht schon in den RAM geladen hat. Je mehr Daten in den RAM passen desto schneller wird das System da der RAM um Größenordnungen schneller ist als die beste SSD am Markt. Wenn der RAM nicht ausreicht werden "alte" Daten wieder aus dem RAM geworfen und die benötigten Daten von der Platte nachgeladen.

    Auch der Schreibzugriff für geänderte Daten im RAM auf die Datenfile werden soweit es geht eingeschränkt. Nur der Schreibzugriff auf das LOG File muss schnell gehen da man diese Geschwindigkeit direkt merkt.

    Hier mal ein Artikel welcher das Schreibverhalten beschreibt https://docs.microsoft.com/de-de/sql/relational-databases/logs/database-checkpoints-sql-server?view=sql-server-2017


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


    Mittwoch, 27. Februar 2019 07:25