Neu Linux / MSSQL und WaWi

[Voltmaster]

Hallo zusammen,

leider hatten wir heute Nacht den SuperGau und unser geliebter lokaler WindowsServer hat sich verabschiedet... Über Nacht mussten wir kurz einen Client zum "Server" umfunktionieren, damit es weiter geht.

Nun beginnt die HardwareSuche und wir überlegen gerade, ob evtl sogar ein weiterer Linux Server ins Haus kommt....
Gibt es aktuell bekannte Probleme mit SQL Server 2019 Standard und Linux im Zusammenhang mit der WaWi?
Oder würdet Ihr davon komplett abraten?

Warum Linux? Wir haben im Bereich Server einfacher mehr Erfahrung im Bezug auf Linux und könnten das besser und einfacher selbst supporten....

 

[recent.digital]

Es gibt einige Mitforisten die Linux und SQL gut betreiben - Vorkenntnisse vorrausgesetzt.

Hier gibt es noch einen ausführlichen Foren-Thread, wenn auch etwas älter: https://forum.jtl-software.de/threads/mssql-server-linux-docker.97137/

 

[sjk]

Was man auch noch bedenken sollte ist, dass JTL den SQL auf Linux (noch?) nicht offiziell supportet. Ich würde daher auf jeden Fall zuerst mal ein Testsystem aufsetzen, mal backup/restore etc. und paar andere Szenarien durchspielen. Dann werdet ihr selbst einschätzen können, ob Ihr euch damit wohl fühlen würdet.
Im anderen Thread siehst du ja, grundsätzlich rennt es auf Linux aber es gibt, mangels offiziellem Support, ein paar Stolpersteine.

 

[mh1]

Da du ja schreibst, dass ihr hausintern besser ein linuxbasierendes Betriebssystem supporten könnt, würd ich ja zu einem solchen System raten.

In der Administration der Datenbank merkst du dann eh nicht mehr ob mssql auf Windows oder Ubuntu oder RedHat oder sonstwas läuft

Die Installation bzw. die Konfiguration des mssql erfolgt auf einem Windows System eben Windows-typisch, indem man sich mit der Maus durch bunte Fenster klickt und auf einem linuxbasierten System editiert man eine Textdatei. Mir persönlich gefällt der Weg über die conf Datei viel besser, aber letztlich muss da jeder selbst schauen, mit was man besser zurecht kommt - denn genau um das gehts: man muss damit gut zurechtkommen (wie mache ich ein Backup? wie einen Restore?...)

Aber auf jedenfall stimme ich meinem Vorredner zu, dass ein Testsystem hilfreich ist.

 

[Dom@H1]

Dann gebe ich hier auch noch meine Meinung dazu:

Ich mag Linux sehr und arbeite mit Debian und Ubuntu für verschiedene Aufgaben.
Persönlich empfehle ich gerne Proxmox als Hypervisor, mit dem man ja schon viele Linux Vorteile nutzen kann.
Warum ich sehr häufig die Windows VM empfehle, liegt am Support durch JTL. Solltet Ihr keinen Support benötigen, dann ist eine eine Linux VM/LXC Container oder Docker Container in Proxmox eine sehr gute Lösung.
Damit habt ihr dann Testsysteme schnell verfügbar und Backups/Snapshots sind auch einfach zu konfigurieren.

 

[Powalowski]

Dann gebe ich hier auch noch meine Meinung dazu:

Ich mag Linux sehr und arbeite mit Debian und Ubuntu für verschiedene Aufgaben.
Persönlich empfehle ich gerne Proxmox als Hypervisor, mit dem man ja schon viele Linux Vorteile nutzen kann.
Warum ich sehr häufig die Windows VM empfehle, liegt am Support durch JTL. Solltet Ihr keinen Support benötigen, dann ist eine eine Linux VM/LXC Container oder Docker Container in Proxmox eine sehr gute Lösung.
Damit habt ihr dann Testsysteme schnell verfügbar und Backups/Snapshots sind auch einfach zu konfigurieren.

So muss das. Wir warten eigentlich alle nur noch darauf, dass die WAWI endlich vernünftig auf API umgebaut, im Docker hostbar und ganz ohne Windows nutzbar wird 😋😋😋

 

[Voltmaster]

Danke für Eure Mithilfe / Infos hier!
Unser DB-Backup haben wir mit einigen Umwegen gleich von den Collation-Problemen befreit und eingespielt.

Inzwischen rennt unser System seit ca. 1 Woche auf dem alten Server aber unter Ubuntu....
Noch keine Probleme.
Backup läuft auch auf mehrere Rechner und Platten...

Einziges "Problem" ist aktuell noch das Starten der WaWi 1.9.4.5. Das ist auf jedem Client extrem lahm.
Evtl hat mir da ja jemand noch einen Trick oder eine Info, wo das Problem liegen könnte...

Nächste Woche werden wir da mal einen schnelleren "Testserver" mit ordentlich NVMe und RAM probieren.... sollte das das Problem lösen, muss halt einfach was neues her oder man muss etwas warten

DANKE!

 

[Powalowski]

Wenn es um die Konfiguration geht, müssten die Standardoptimierungen gelten.
Ich nehm an, ihr habt den im Docker: Wie macht ihr denn die Backup-Routine? Zieht ihr die .baks aus dem Docker raus?

 

[recent.digital]

Danke für das Feedback! Wo läuft der Worker in dieser Konstellation?

 

[Voltmaster]

Der MSSQL 2022 Standard läuft direkt auf dem Server....

Backup:
läuft via ShellScript.
einmal um 3 Uhr volles Backup,
Danach jede Stunde ein DiffBackup
Das Script kopiert das Backup erst auf die lokale Disk, dann komprimiert nochmal lokal auf ein Raid und dann auf ein gemountetes SMB-Share.
Zusätzlich ist eine Sicherung per Copy auf USB Stick geplant.
Alte Backups > 10 Tage werden gelöscht, Diff Backups > 2 Tage

Der Worker läuft auch auf dem Server in einer WindowsLTSC-VirtualBox

 

[Fabrice]

Wir nutzen Die Datenbank in Docker. Bis auf das sich der Support manchmal ziert weil es kein Windows ist, läuft es mega stabil und perfomant. Man kann die Datenbank auch Bare Metal oder in einer VM installieren aber über Docker fand ich es einfacher und deshalb nutzen wir es so.
Updates und Upgrades sind eine Sache von Sekunden. Backups macht der SQL Server selbst. Zusätzlich ist die VM in der der Container läuft in unserem Backup. Handling von Backups ist finde ich über die CLI deutlich angenehmer als über das SMSS.

SMSS lässt sich dennoch sehr gut nutzen. Es gibt ein paar Features, welche es unter Linux nicht gibt. Zumindest nicht ohne weiteres: Filestream mal als Beispiel.

https://learn.microsoft.com/en-us/s...known-issues?view=sql-server-ver16&tabs=rhel9

Worker läuft auf einer separaten Maschine unter Windows.

 

[Powalowski]

Wir nutzen Die Datenbank in Docker. Bis auf das sich der Support manchmal ziert weil es kein Windows ist, läuft es mega stabil und perfomant. Man kann die Datenbank auch Bare Metal oder in einer VM installieren aber über Docker fand ich es einfacher und deshalb nutzen wir es so.
Updates und Upgrades sind eine Sache von Sekunden. Backups macht der SQL Server selbst. Zusätzlich ist die VM in der der Container läuft in unserem Backup. Handling von Backups ist finde ich über die CLI deutlich angenehmer als über das SMSS.

SMSS lässt sich dennoch sehr gut nutzen. Es gibt ein paar Features, welche es unter Linux nicht gibt. Zumindest nicht ohne weiteres: Filestream mal als Beispiel.

https://learn.microsoft.com/en-us/s...known-issues?view=sql-server-ver16&tabs=rhel9

Worker läuft auf einer separaten Maschine unter Windows.

Same same. Wie genau macht ihr die Backups?

 

[mh1]

Same same. Wie genau macht ihr die Backups?

Du hast zwar nicht MICH gefragt, aber ich bin trotzdem mal so frech und antworte. Deshalb schreibe ich, wie ich es mache, nämlich ziemlich einfach (KISS-Prinzip):

• Ich habe eine kleine Stored Procedure auf dem SQL-Server angeleget, die einen sinnvollen Dateinamen für die Backupdatei bastelt und entscheidet, welche Art von Backup gemacht werden soll (z.b. "with differential")
• Auf dem Host auf dem der sqlserver läuft ist ein simpler Cronjob eingerichtet, der regelmäßig diese SP ausführt (so in der Art: sqlcmd -Q "EXEC sp_Backup")

Jetzt kann man die erstellte Backupdatei noch nach belieben irgendwohin kopieren (z.b. einfach an den Cronjob noch ein && scp soundso anhängen, oder auf eine externe Platte schieben), oder oder ...

 

[Fabrice]

Du hast zwar nicht MICH gefragt, aber ich bin trotzdem mal so frech und antworte. Deshalb schreibe ich, wie ich es mache, nämlich ziemlich einfach (KISS-Prinzip):

• Ich habe eine kleine Stored Procedure auf dem SQL-Server angeleget, die einen sinnvollen Dateinamen für die Backupdatei bastelt und entscheidet, welche Art von Backup gemacht werden soll (z.b. "with differential")
• Auf dem Host auf dem der sqlserver läuft ist ein simpler Cronjob eingerichtet, der regelmäßig diese SP ausführt (so in der Art: sqlcmd -Q "EXEC sp_Backup")

Jetzt kann man die erstellte Backupdatei noch nach belieben irgendwohin kopieren (z.b. einfach an den Cronjob noch ein && scp soundso anhängen, oder auf eine externe Platte schieben), oder oder ...

Genau so

 

[SHKiel]

Ich würde mich hier gerne mal ranhängen, da ich Probleme mit dem Aktualisieren von MSSQL in Docker habe.

Host ist Synology, dort habe ich vor langer Zeit einen MSSQL 2017 Container eingerichtet, der seitdem zuverlässig meine JTL DB hostet.
Heute wollte ich dann mal das Container Image aktualisieren. Dazu muss ich den bestehenden Container dann duplizieren und mit dem neuesten Image von MSSQL starten. Das klappt prinzipiell auch.

Bzgl. der manuellen Backups über das JTL DB-Tool hatte ich schon immer das Problem, dass es nicht funktioniert hat.
Bei Updates kam immer die Meldung, dass 0MB Space verfügbar sind, am Ende konnte er das Update aber trotzdem durchführen. Das ist seit dem heutigen Update des Container-Images nicht der Fall. Ich bekomme diese Fehlermeldung:

Die Prüfung der Datenbank ist fehlgeschlagen
Eine Datenbank-Momentaufnahme kann aufgrund eines Fehlers beim Starten nicht erstellt werden.
Eine Datenbank-Momentaufnahme kann aufgrund eines Fehlers beim Starten nicht erstellt werden.
Die Datei "/var/opt/mssql/data/eazybusiness.mdf_MSSQL_DBCC6" kann nicht in eine Datei mit geringer Dichte konvertiert werden. Stellen Sie sicher, dass das Dateisystem Dateien mit geringer Dichte unterstützt.
Die Datenbank-Momentaufnahme für Onlineüberprüfungen konnte nicht erstellt werden. Die Ursache wird in einem vorherigen Fehler beschrieben, oder eines der zugrunde liegenden Volumes unterstützt Dateien mit geringer Dichte oder alternative Datenströme nicht. Es wird versucht, exklusiven Zugriff zu erhalten, um die Überprüfung offline auszuführen.

Meine Recherchen habe bereits ergeben, dass das was mit dem Filesystem zu tun haben kann. Host ist Synology, da ist im GUI die Dateikomprimierung nicht aktiviert für die Festplatte.
Bei manuellen Backups über das DB-Tool erhalte ich den selben Fehler, egal ob ich das Backup auf dem Host oder im Container ablegen möchte.

Kennt einer das Problem?

 

[mh1]

Die Prüfung der Datenbank ist fehlgeschlagen
...

Kommen diese Fehlermeldungen, wenn du das JTL Update ausführst?

...
Eine Datenbank-Momentaufnahme kann aufgrund eines Fehlers beim Starten nicht erstellt werden.

Versuch mal direkt per SQL ein Datenbanksnapschot zu erstellen. Also z.B. so CREATE DATABASE eazybusiness_20250313_1346 ON (NAME = eazybusiness, FILENAME = 'eazybusiness.mdf_202501313_1346.ss') AS SNAPSHOT OF eazybusiness

Kommt hier eine Fehlermeldung?

Wurde der Snapshot angelegt?
Köntest du z.B. im Management Studio sehen:

Wie sieht die Ausgabe von ls -lsh /var/opt/mssql/data/ aus?

Die Datei "/var/opt/mssql/data/eazybusiness.mdf_MSSQL_DBCC6" kann nicht in eine Datei mit geringer Dichte konvertiert werden. Stellen Sie sicher, dass das Dateisystem Dateien mit geringer Dichte unterstützt.

"...Datei mit geringer Dichte"
puuh - als Tipp (unabhängig von dem Problem in diesem Thread): Server Software von Microsoft am besten immer die originalen nicht übersetzte Fehlermeldung anzeigen lassen. In dem Fall wäre das dann "Cannot make the file 'xxx' a sparse file"

Ein Beispiel für den Übersetzungskäse ist Recovery und Restore: Zwei völlig unterschiedliche Dinge, aber in den deutschen Versionen übersetzen die Microsoftler beides mit dem Wort Wiederherstellung und das hat schon vor 20 Jahren häufig zu Verwirrung geführt

 

[mh1]

Ich würde mich hier gerne mal ranhängen, da ich Probleme mit dem Aktualisieren von MSSQL in Docker habe.

Prüfe bezüglich der von dir geposteten Fehlermeldung auch die Berechtigungen von /var/opt/mssql/data/ jeweils im Docker und auf dem Host in Verbindung mit dem User, der Docker ausführt.