ubuntuusers.de

Hallo, ich bin dabei meinen Windows-Server auf Ubuntu zu migrieren. Samba- und Dateirechte sind (fast) kein Problem, ich kann unter Windows 11 über den Explorer auf die Freigaben zugreifen, Dateien erzeugen und ändern. Beim Versuch nun meine SQL-Server-DB unter Ubuntu zu verwenden scheitere ich. Prinzipieller setup: Es gibt den Benutzer "smbuser" mit der Gruppe "smbgrp", über den alle Zugriffe auf Dateiebene erfolgen. Die Unterscheidung, welcher Benutzer auf welchem Verzeichnis schreiben darf, geschieht ausschließlich über den Samba-Share. Die Benutzerdaten liegen auf einer eigenen Platte die unter /mnt als /mnt/daten eingebunden ist. Auf Dateiebene sieht das so aus:

 ls -al /mnt/daten
total 16
drwxr-x--x 1 smbuser   smbgrp   86 Jun  2 13:53 .
drwxr-xr-x 1 root      root     28 Jun  2 13:22 ..
drwxr-x--x 1 smbuser   smbgrp   16 Jun  2 18:36 alle
drwxr-x--x 1 smbuser   smbgrp 4454 Jun  7 15:06 bernd
drwxr-x--x 1 smbuser   smbgrp    0 Jun  2 13:53 haushalt
drwxr-x--x 1 smbuser   smbgrp    0 Jun  2 13:52 heike
drwxr-x--x 1 smbuser   smbgrp    0 Jun  2 13:53 kits
drwxr-x--x 1 smbuser   smbgrp 8024 Jun  2 20:24 lars
drwxr-x--x 1 smbuser   smbgrp   22 Jun  2 13:52 medien
drwxr-x--x 1 rsyncuser smbgrp  220 Jun  7 14:56 skripte

Meine smb.conf sieht auszugsweise so aus:

[bernd]
comment = bernd
path = /mnt/daten/bernd
write list = bernd
valid users = @familie
force user = smbuser

[heike]
comment = heike
path = /mnt/daten/heike
write list = heike
valid users = @familie
force user = smbuser

d.h. jeder user hat auf "seinem" share Schreibrechte, die ganze Faminlie darf lesen.

Nun mein Datenbankproblem:
Der Versuch über den SQL Servermanager eine Datenbank anzulegen, scheitert an Dateirechten. Wenn ich mir eine existierende Datenbank anschaue, bekomme ich ein Recht, das ich nicht einschätzen kann und wo ich (wahrscheinlich wegen falscher Suche) auch im Web nichts gefunden habe:
Die beiden Dateien, aus denen die DB besteht selen folgendermaßen aus:

sudo ls -l depot*.mdf
-rwxr-x--x  1 smbuser smbgrp 209715200 Jun  2 10:02 depot_log.mdf
-rwxr-x--x+ 1 smbuser smbgrp 168624128 Jun  2 10:02 depot.mdf

Man sieht ein "+" bei den Zugriffsrechten von depot.mdf, was wohl von einer ACL-herrührt, die der SQL-Servermanager unter Windows gesetzt hat und die beim Übertragen nach Ubuntu mittransporttiert wurde, obwohl ich beim Ubuntu-Setup auf keine ACLs installiert hatte. Als Ergebnis sehe ich unter Windows, daß ich lesen, schreiben, ausführen darf, aber keinen Vollzugriff habe - der Servermanager will aber Vollzugriff.

Ich habe dann aie ACL-Software nachinstalliert mit: sudo apt install acl und erhalte folgendes Ergebnis:

getfacl depot*
# file: depot_log.mdf
# owner: smbuser
# group: smbgrp
user::rwx
group::r-x
other::--x

# file: depot.mdf
# owner: smbuser
# group: smbgrp
user::rwx
user:smbuser:rwx                #effective:r-x
group::r--
group:smbgrp:r--
mask::r-x
other::--x

d.h. der Server erzählt mir, daß die DB - wie gewollt - dem smbuser gehört, dieser die Rechte rwx hat (auch wie gewollt), daß smbuser aber an der Datenbankdatei selbst (depot.mdf) effektiv nur Lese- und Executerechte bestehen. Frage: Warum ist das so und wie kann ich das ändern. Auch unter Windows ist der SQL-Servermanager heikel: Wenn die Dateien nicht mir persönlich gehören, gibt es eine vergleichbare Fehlermeldung.

Hat jemand eine Idee? Erstmal vielen Dank fürs lesen. Gruß bernd

Moin, das Wichtigste, deinen Text kann man so wie er gerade ist sehr schwer lesen

• Daten die du uns zeigen willst, bitte als codeblock (wie datei rechte usw).

• Deine Strichaufzählungen bitte mit der Funktion im Forum nutzen und schau dir das Ergebnis mit der Vorschau an

Ich habe einige Fragen

• In der Überschrift geht es um SQL Server (bitte genaue Angaben welche Version du unter Ubuntu installiert hast)

• Deine Daten liegen auf einer Externen Platte, wie ist diese Formatiert?

• Du schreibst was von ACLs, bitte die Ausgabe von

  getfacl

  als codeblock

• Was hat SAMBA mit deinem SQL Server zu tun, davon steht doch nichts in deinem Betreff, ist das ein zusätzliches Thema?

• Bitte mehr informationen zu deinem SAMBA Freigaben

• Bitte ein

  ls -lah

  auf das Verzeichnis wo deine SQL daten liegen, Ausgabe als codeblock

bbmonster schrieb:

... ich bin dabei meinen Windows-Server auf Ubuntu zu migrieren.

👍

... Beim Versuch nun meine SQL-Server-DB unter Ubuntu zu verwenden scheitere ich.

Bitte gib detaliert an welchen SQL-Server du benutzt. Also Produkt und Version, so wie micneu es schon gewünscht hat.

sudo ls -l depot*.mdf
-rwxr-x--x  1 smbuser smbgrp 209715200 Jun  2 10:02 depot_log.mdf
-rwxr-x--x+ 1 smbuser smbgrp 168624128 Jun  2 10:02 depot.mdf

OK, du benutzt anscheinend einen Microsoft SQL Server.

1. Welche Version?

2. Ist der MSSQL Server auf Ubuntu installiert, so wie hier beschrieben?

3. Oder ist der MSSQL-Server noch auf dem Windows Rechner und du hast nur die Datenbank auf Ubuntu geschoben und möchtest nun das der MSSQL-Server via Dateiprotokoll auf die MDF zugreift? Das wird nicht funktionieren. Die MDF Datei muss immer auf dem System liegen, auf welchem der MSSQL-Server Installiert wurde. Die Clients greifen dann via TCP und TDS Protokoll auf den Server zu

Hat jemand eine Idee?

Wir benötigen bitte erst einmal mehr Informationen. Danke!
Bitte beachte die Forums Syntax. Danke!

Gruß SH

Edit: für Ubuntu 24.04 ist die Installation des MSSQL-Server nicht "freigegeben" bzw. nicht getestet. Siehe obigen Link.

Hallo, anscheinend hat das Ausformulieren des Problems hier zu einem neuen und erfolgreichen Suchansatz geführt. Zur Klarstellung des Problems

Istzustand: Ich betreibe eine SQLExpress-Installation. Auf meiner Windows-Maschine benutze ich MS-Access als Frontend. Der SQLServerprozess läuft auf der gleichen Windowsmaschine, die Datenbankdateien liegen im Netz auf einen Windows Server

Ich möchte den Windowsserver abschaffen und durch ein ubuntuserver 24.04 ersetzen, auf den ich via SAMBA zugreife. Die Basiskonfiguration (Zugriffe auf die Shares des ubuntuservers) funktioniert gut, ich konnte lediglich mit dem entsprechenden Tool (=MS SQL Server Management Studio) keine neue Datenbank auf dem entsprechenden ubuntu-share anlegen oder eine bestehende DB ansprechen, wegen vermeintlichen Rechteproblemen.

Mein Ansatz mit dem Fehler war es, von der Windowsmaschine ein Laufwerk zu mappen auf dem die Datenbank liegt oder in einem leeren Verzeichnis dieses gemappten Laufwerks eine neue DB mittels MS SQL MGMT Studio anzulegen. Das erzeugt einen Fehler der auf fehlende Zugriffsrechte hinweist.

Die Lösung ist trivial: Wenn man z.B. das leere Verzeichnis, in dem man eine DB anlegen will statt über den gemappten Laufwerksbuchstaben von Windows mit dem UNC-Namen anspricht, funktioniert alles.

Vielen Dank für die Hilfe beim Denken

Bernd

p.s. wegen der Formatierung: Ich sehe, daß das Frontend hier manche Zeilenumbrüche verschluckt, der Hinweis mit der Vorschau war hilfreich .-)

Wenn damit dein Problem gelöst ist bitte auch so markieren, danke

Hallo, ich möchte der Form halber noch die gewünschte Version nachliefern:

Ich verwende die neuste Version des MS SQL-Servers, nämlich SqlServerExpress 2022 und den ODBC-Treiber 17 unter Windows 11. Neuere Versionen des ODBC-Treibers funktionieren bei mir nicht. Das MS das Plazieren der Datenbankdateien auf einem Remotesystem nicht begrüßt weiß ich, ich wollte aber auf einen mehrmals täglich gesicherten Datenbestand nicht verzichten. MS sagt immerhin, daß ab Version 2012 eine solche Konfiguration prinzipiell möglich ist. Ich verwende das (halt mit MS Server) seit 2019 und hatte (außer dem rausfinden wie es geht) keine Probleme. Zur Vollständigkeit hier der gewünschte Blick auf die gerade laufende DB, auf der ich einen Performancetest mache:

1
2
3
4
5
6

ls -lah /mnt/daten/bernd/Test2/
total 361M
drwxrwxr-x+ 1 smbuser smbgrp   44 Jun  7 20:29 .
drwxr-x--x  1 smbuser smbgrp 4,4K Jun  7 15:06 ..
-rwxr-----+ 1 smbuser smbgrp 200M Jun  7 21:13 depot_log.mdf
-rwxr-----+ 1 smbuser smbgrp 161M Jun  7 21:13 depot.mdf

Auf den ersten Blick liegt die Performance auf dem Samba-Share des Ubuntu-Servers bei ca. 20% der Performance des Windows-Share. Beide Maschinen (Windows Server und Ubuntuserver) sind Quadcore-Cpus, der Windowsserver hat 32 GB RAM, der Ubuntuserver (derzeit noch eine ausrangierte alte Workstation von mir = Testsystem) hat 16 GB RAM. CPU-technisch sollte der Windowsserver deutlich langsamer sein als das Ubuntu-Testsystem, denn das war mein letzter Hauptrechner, der Windowsserver ist ca 12 Jahre alt.

Gibt es unter Ubuntu typische Fehler beim Aufsetzen, die eine Verlangsamung erklären würde? Der Share von beiden Maschinen (Windows und Ubuntu) zeigt jeweils auf Verzeichnisse, die auf einer SSD liegen. Beide SATA-SSDs sind in etwa gleich schnell.

Von der Performancemessung unter Ubuntu habe ich noch keine Ahnung, aber anbei noch den Header von TOP, vielleicht sagt das einem von Euch was:

1
2
3
4
5

top - 21:26:15 up  1:01,  1 user,  load average: 0,50, 0,62, 0,69
Tasks: 180 total,   1 running, 179 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,4 us,  3,1 sy,  0,0 ni, 79,8 id, 16,3 wa,  0,0 hi,  0,4 si,  0,0 st
MiB Mem :  15938,3 total,  13826,7 free,    505,1 used,   1882,4 buff/cache
MiB Swap:   4096,0 total,   4096,0 free,      0,0 used.  15433,2 avail Mem

Viele Grüße

Bernd

bbmonster schrieb:

... Das MS das Plazieren der Datenbankdateien auf einem Remotesystem nicht begrüßt weiß ich,

Wo "begrüßen" sie das nicht?

ich wollte aber auf einen mehrmals täglich gesicherten Datenbestand nicht verzichten.

Verstehe ich nicht.

MS sagt immerhin, daß ab Version 2012 eine solche Konfiguration prinzipiell möglich ist.

Wo sagen sie das?

Ich verwende das (halt mit MS Server) seit 2019 und hatte (außer dem rausfinden wie es geht) keine Probleme.

Aus meiner Sicht ist es ist komplett unlogisch was du da betreibst. Ich bin mir sicher, dass du dir damit Probleme ran hohlen wirst. Ich an deiner Stelle würde es nicht machen.

Gruß SH

Hi SH4711, hier die Antworten: Hier begrüßt MS nicht die Benutzung von Netzwerkshares:

1
2
3
4
5

Zusammenfassung

Microsoft empfiehlt in der Regel, einen SAN (Storage Area Network) oder lokal angefügten Datenträger für den Speicher Ihrer Microsoft SQL Server-Datenbankdateien zu verwenden, da diese Konfiguration die LEISTUNG und Zuverlässigkeit von SQL Server optimiert. Standardmäßig ist die Verwendung von Netzwerkdatenbankdateien, die auf einem netzwerkgebundenen Server oder einem NAS-Server (Network Attached Storage) gespeichert sind, für SQL Server nicht aktiviert.

Sie können SQL Server jedoch so konfigurieren, dass eine Datenbank auf einem Netzwerkserver oder NAS-Server gespeichert wird. Server, die für diesen Zweck verwendet werden, müssen SQL Server-Anforderungen für die Datenschreib- und Schreibzugriffsgarantie erfüllen. Dies finden Sie im Abschnitt "Weitere Informationen ".

Zur Datensicherung: Auf meinem Windowsserver und auch auf meinem Ubuntu-Testsystem wird 5 mal am Tag eine Datensicherung durchgeführt, die auch die Datenbank mitnimmt. Ich hatte schon mal Hardwareprobleme und konnte alles erforderliche (auch die DB) problemlos wieder herstellen. In beiden Fällen ist der Backup ein Skript (Windows: VBasic, Ubuntu: Bash-Skript, was letztlich rsync aufruft mit ein bischen Logik drumherum) was über den Scheduler des Betriebssystems aufgerufen wird. Dabei ist der Backup unter Ubuntu beeindruckenderweise ca. 3 mal so schnell wie der unter Windows. Nach 6 Jahren mit auch mal Stromausfall kann ich sagen: alles funktioniert bestens (jedenfalls unter Windows, Ubuntu muß sich erst noch zeigen), denn das sind ca. 10000 Durchläufe.

MS sagt, daß prinzipiell ein NAS verwendbar ist in o.a. Artikel unter

1

https://learn.microsoft.com/de-de/troubleshoot/sql/database-engine/database-file-operations/support-network-database-files

ein Teil davon hab ich oben einkopiert.

Wie gesagt, auf dem Windowsserver läuft das ganze jetzt 6 Jahre. Klar läuft das auf dem Netzwerkshare etwas langsamer, aber absolut im Rahmen. Hier ein Performancevergleich: Ich mache einmal pro Woche (Samstags) eine Simulation auf einer Datenbankkopie (so ein KI-Ding) bei der ich die DB auf Basis der Kurse der letzten 180 Tage herausfinden lasse, was meine optimalen Parameter fürs Handeln sind. Dabei durchläuft die DB ca. 140 Mal das letzte halbe Jahr mit den Kursen aller betrachteten Wertpapiere unter verschiedenen Randbedingungen um die optimalen Einstellungen zu finden. Das ganze ist das Training eines neuronalen Netztes (wie es vor dem KI-Hype hies). Zur Performance: Diese Simulation hat heute mit der DB auf einer Ramdisk 1:56:23 gedauert, auf einer einigermaßen zeitgemäßen NVME-SSD (Samsung 990 Pro, 4 Lanes mit PCIE4) dauert die Simulation 2:50:12 und auf dem Ubuntu-Share läuft es, seit 21:45 und hat vielleicht 30% des Pensums geschafft. Ich denke die Lösung hat ihre Robustheit gezeigt. Wenn MS nicht die Wartung von Server 2012 eingestellt hätte, würde ich auch nichts dran ändern, aber Augen zu hilft normalerweise wenig.

Gruß Bernd

bbmonster schrieb:

... MS sagt, daß prinzipiell ein NAS verwendbar ist in o.a. Artikel unter

1	https://learn.microsoft.com/de-de/troubleshoot/sql/database-engine/database-file-operations/support-network-database-files

ein Teil davon hab ich oben einkopiert. ...

Vielen Dank für deine Rückmeldung.
Du hast den Artikel und die Unterartikel gelesen, dann weißt du was du machst bzw. machen musst.
Ich würde es nicht tun. Aber das ist meine persönliche Ansicht dazu, das soll dich nicht daran hindern.

Gruß SH

Hallo, da ich gestern Eure Ressourcen beansprucht habe, will ich heute eine Erkenntnis mit Euch teilen: Die Performance bei der Ablage der MS-SQL-Server Datenbankfiles auf einem Ubuntushare hat sich mehr als verdoppelt, nachdem ich das Filesystem von btrfs nach ext4 geändert habe, während alle Samba-Tuningvorschläge, die ich im Netz so gefunden habe (SO_SNDBUF=8192, SO_RCVBUF=8192, TCP_NODELAY, write raw, ...) nichts gebracht haben. Gruß Bernd

bbmonster schrieb:

... mehr als verdoppelt, nachdem ich das Filesystem von btrfs nach ext4 geändert habe,...

Schau hier mal bitte rein dann verwundert dich das auch nicht.
Und jetzt sind wir wieder bei dem Punkt ... du sprichst über Performance aber deine Installation ist alles andere als performant. Mitunter begründet in der Ablage der MDF auf einem Fileserver und hier auch noch auf einem SAMBA File-Server.
Wenn du Zeit und Lust hast, dann teste doch einfach mal die MDF auf einem Ubuntu mit ext4 Dateisystem und mit dem MSSQLServer direkt auf dem Ubuntu installiert.
Das Feedback wäre interessant 😀

Gruß sh

sh4711 schrieb:

... Wenn du Zeit und Lust hast, dann teste doch einfach mal die MDF auf einem Ubuntu mit ext4 Dateisystem und mit dem MSSQLServer direkt auf dem Ubuntu installiert.

Und noch einen Redis Server dazu.

Hi Mylin, hab ich heute gemacht - den SQL-Server direkt auf dem Linuxserver installiert. Ich habe zwar noch Verrechtungsprobleme offen, die ich erstmal unsauber abgeknipst habe, da ich viel zu neugierig war zu sehen, wie sich der SQLServer unter Windows mit ext4 schlägt. Der DB-Serverprozeß unter Linux zieht über 80% der CPU-Leistung, die für meinen Test benötigte Zeit wurde locker halbiert gegen den Versuch mit btrfs. Das Ergebnis ist trotzdem langsamer als die Variante mit dem Linuxshare auf ext4 und dem DB-Prozess unter Windows.

Im ext4-Fall mit dem Samba-Share benötigt der smdb-Prozess 10-12% der Rechenleistung und ist mindestens doppelt so schnell als mit SQLServer auf Linux. In einem zweiten Schritt habe ich mit Samba rumgespielt und noch ca. 10% Performance rausgeholt, indem ich

1
2

security = user
guest ok = yes

gesetzt habe. Das reduziert den CPU-Konsum des smdb-Prozesses von 12% auf 8-9% und die elapsed time um ca. 10%. Ich hab inzwischen auch alle die Hacks ausprobiert, die man im Web so findet (TCP_NODELAY, send/receive-Buffer, read/write raw, ...) aber die aktuelle Sambaversion läßt sich in meinem Fall damit nicht verbessern.

Was ein Redisserver ist, weiß ich (noch) nicht. Ich informiere mich morgen und informiere Euch dann über das Ergebnis. Gruß Bernd

Hi zusammen, ich habe mir die Website von Redis angesehen und stelle fest dass

• Es nicht trivial ist das zu verarbeiten

• mir derzeit nicht klar ist, ob das eine persistente Datenbank ist

• Ich muß mir erstmal über das Lizenzierungsmodell klarwerden, bevor ich da weiter Zeit reinstecke

Ich bin aber mittlerweile über das disk-Gegenstück von top (iostat) gestolpert. Da meine Linuxzeit noch sehr kurz ist, brauche ich bei solchen Dingen immer ein bischen. iostat liefert mir die Information, über die Auslastung meiner Disks, dabei sind sda und sdb Sata-SSDs und sdb (die Backupplatte) eine mechanische Disk). Die Werte, die ich finde sehen folgendermassen aus:

Device             tps      kB/s    rqm/s   await  areq-sz  aqu-sz  %util
loop0             0,00      0,00     0,00    0,00     1,27    0,00   0,00
sda               9,94    741,09     5,71    0,91    74,58    0,01   0,33
sdb              81,83    698,66    27,20    0,75     8,54    0,11   5,68
sdc               0,13      1,50     0,01   19,06    11,56    0,00   0,07

Linux liegt auf sda und die Datenbank auf sdb. Die DB-Disk macht also 81 IOs/sec was auch für eine ältere SSD keine nennenswerte Last ist. An await sieht man schön, dass sdc eine klassische Festplatte ist. An den IO-Raten von sdb sehe ich, daß Samba keinen nennenswerten Flaschhals darstellt, was bei einem CPU-Verbrauch von mittlerweile 9% auch nicht zu erwarten ist.

Das bisherige Ergebnis zusammengefasst:

• Das bisher schlechteste Ergebnis des Performancetest bekomme ich, wenn die DB auf dem Sambashare liegt, der mit btrfs formatiert ist

• Es kommt zu mehr als einer Verdopplung der Geschwindigkeit, wenn ich das Filesystem für die DB von Btrfs auf Ext4 ändere

• Weitere etwa 10 % erhält man, wenn man durch Sambatuning (security = user, guest ok = yes)

• Wenn man den Datenbankprozeß vom Windowsclient, der hier die Sambashares verwendet) nach Linux verschiebt und damit die Last von den Sambashares nimmt, ist die Performance wieder so schlecht wie bei Punkt 1. Das liegt wahrscheinlich daran, daß mein Linux-Testsystem ein Intel i5 6xxx quadcore ist und mein Windowsclient ein Ryzen 5 5800x, also ein octacore mit erheblich mehr GHZ.

• Fazit: Mit der jetzigen Lösung kann ich leben, auch wenn sie schlechter performt als meine derzeitige Windowslösung

• Meine neue Hardware für mein zukünftiges Lunix-NAS sollte einen großen Teil der Performancedefizite auffangen

Nochmal zum Schluß die vorliegenden absoluten Zahlen, die die Probleme deutlich machen. Gemessen wurde jeweils ein kompletter Lernvorgang des neuronalen Netzes, so wie ich das jeden Samstag mache:

• 1. Optimaler Fall: DB-Files auf Windows Ramdisk, DB-Prozess/Backend-DB und Frontend-DB auf dem gleichen Windows: Dauer: 1:56:23

• 2. Wie 1, aber die DB-Files liegen auf einem share meines Windows-Servers und dort auf einer SSD: Dauer: 2:50:12. Das ist der Fall gegen den ich Linux vergleiche

• 3. Wie 2, aber nun liegen die Datenbankfiles auf einem Linuxshare mit btrfs Dauer: 7:19:53

Wie man aus Punkt 3 sieht, habe ich beim Übergang auf ext4 und den anderen Tuningvorgängen nicht mehr den Gesamtvorgang gemessen, sondern mich auf Teile beschränkt. Ich messe derzeit das ext4-Gegenstück von Fall 3 komplett aus, gefühlt bin ich etwas mehr als doppelt so schnell. Ich liefere die Zahlen heute abend. Ein explizites Bottleneck finde ich nicht mehr, Aus der Erinnerung kann ich sagen, daß ich bei meiner Windowslösung (Fall 1) beim Übergang von meinem jetzigen Linux-Testsystem (damals mein Hauptrechner) auf den Ryzen 5800X dachte: boa, rohe Gewalt. Insofern sollte auch der Übergang vom Linux-Testsystem auf die finale Hardware (Ryzen 5 9600X, Sata-SSD → NVME-SSD) ein spürbarer Schub kommen.

Gruß Bernd

Hi zusammen,

der volle Trainingslauf des neuronalen Netzes nun auf der optimierten Version des Linuxservers ist durch und hat 3:35:22 gedauert. Gegen die 7:19:53 ist das ziemlich genau die Hälfte. Wenn ich das gegen die 2:50:12 auf dem Windowsserver vergleiche ist es plausibel anzunehmen, daß sich das durch die neue Hardware egalisieren läßt (SATA-SSD gegen NVME-SSD, erheblich schnellerer 6-Kerner gegen alte 4-Kerner CPU, 32 GB statt 16 GB RAM, schnelleres RAM).

Danke fürs mitdenken und diskutieren.

Bernd