Dieselbe Engine, eine völlig andere Umgebung
Abfragen und Sicherungen wandern unverändert mit. Aufwand entsteht bei Dateirechten, beim Dienst, bei der Anmeldung am Verzeichnisdienst und bei Funktionen, die es unter Linux nicht gibt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Umzug scheitert selten an der Engine und fast immer an der Umgebung
Die Erwartung beim ersten Umzug ist meist: Sicherung ziehen, auf dem Linux-Server einspielen, fertig. Dieser Teil funktioniert tatsächlich, eine Sicherungsdatei aus einer Windows-Instanz lässt sich auf einer Linux-Instanz derselben oder einer höheren Hauptversion wiederherstellen, und die Abfragen laufen ohne Anpassung. Genau deshalb wirkt der Umzug am ersten Tag wie ein Erfolg.
Auffällig wird der Unterschied ab der zweiten Woche. Der geplante Auftrag, der die Sicherung auf eine Freigabe schreibt, bricht mit einem Zugriffsfehler ab, weil das Verzeichnis nicht dem Benutzer mssql gehört. Ein Wiederherstellungsskript findet die Datei nicht, weil in einem Pfadbestandteil ein Großbuchstabe steht und Linux das anders bewertet als Windows. Aufträge im Agent laufen gar nicht, weil der Agent unter Linux zwar mitgeliefert, aber ab Werk abgeschaltet ist. Nichts davon ist schwierig, aber alles davon kostet einen Nachmittag, wenn es zum ersten Mal auftritt.
Der teuerste Punkt ist die Bestandsaufnahme, die vorher niemand gemacht hat. Wenn eine Anwendung xp_cmdshell aufruft, eine Abteilung ihre Berichte über die Reporting Services zieht oder Dokumente über FILESTREAM in der Datenbank liegen, ist das keine Feinheit der Konfiguration, sondern ein Umbau. Solche Abhängigkeiten stecken selten in der Projektbeschreibung und fast immer in einem Skript, das seit Jahren funktioniert.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Befehl, der unter Linux alle Einstellungen setzt
Unter Windows verteilen sich Instanzeinstellungen auf den Konfigurations-Manager, die Registrierung und die Instanzeigenschaften. Unter Linux führt fast alles durch dieses eine Werkzeug, und wer seinen Aufbau kennt, findet jede Einstellung.
Der Aufbau
sudo /opt/mssql/bin/mssql-conf set <abschnitt>.<einstellung> <wert> - 01 Rechte
sudoDas Werkzeug schreibt in /var/opt/mssql/mssql.conf und benötigt dafür erhöhte Rechte. Ohne sudo bricht der Aufruf mit einem Rechtefehler ab, was gerade in Skripten leicht übersehen wird, weil die Ausgabe unauffällig bleibt.
- 02 Das Werkzeug
/opt/mssql/bin/mssql-confEs liegt nicht im Standardsuchpfad, deshalb der vollständige Pfad. Neben set kennt es setup für die Ersteinrichtung, get zum Auslesen, unset zum Zurücksetzen auf die Voreinstellung, traceflag für Ablaufverfolgungsflags sowie die eigenen Unterbefehle set-edition, set-sa-password und set-collation.
- 03 Die Aktion
setSetzt einen Wert und schreibt ihn in die Konfigurationsdatei. Wirksam wird er erst nach einem Neustart des Dienstes mit systemctl restart mssql-server. Das ist die häufigste Ursache dafür, dass eine korrekt gesetzte Einstellung scheinbar ignoriert wird.
- 04 Der Schlüssel
<abschnitt>.<einstellung>Zweiteilig aufgebaut, etwa memory.memorylimitmb für die Speichergrenze, network.tcpport für den Port, filelocation.defaultdatadir für das Datenverzeichnis oder sqlagent.enabled für den Agent. Der Abschnitt entspricht der Überschrift in eckigen Klammern in der Konfigurationsdatei.
- 05 Der Wert
<wert>Je nach Einstellung eine Zahl, ein Pfad oder true beziehungsweise false. Ein Pfad muss vorher existieren und dem Benutzer mssql gehören, sonst startet der Dienst nach dem Neustart nicht mehr und meldet den Grund nur im Fehlerprotokoll.
Wenn es nicht funktioniert
Das siehst du
sqlcmd bricht die Verbindung mit einem Hinweis auf den SSL-Anbieter ab, obwohl die Instanz läuft.
Warum
Die Werkzeuge in der Version 18 verschlüsseln die Verbindung standardmäßig und akzeptieren das selbst ausgestellte Zertifikat der Instanz nicht.
Was hilft
Häng für einen Test -C an den Aufruf, damit dem Serverzertifikat vertraut wird. Für den dauerhaften Betrieb hinterlegst du über mssql-conf ein Zertifikat, dem die Clients ohnehin trauen.
Das siehst du
BACKUP DATABASE meldet, dass der Zugriff auf das Verzeichnis verweigert wurde, obwohl der Pfad existiert.
Warum
Das Zielverzeichnis gehört nicht dem Benutzer mssql, oder es liegt eine eingebundene Netzfreigabe darunter, bei der die Einhängeoptionen keine Schreibrechte für diesen Benutzer vorsehen.
Was hilft
Setz Eigentümer und Gruppe mit chown mssql:mssql, und binde eine CIFS-Freigabe mit passenden uid- und Zugriffsoptionen ein. Auf Red Hat prüf zusätzlich den SELinux-Kontext des Verzeichnisses.
Das siehst du
Nach dem Umstellen des Datenverzeichnisses startet der Dienst nicht mehr.
Warum
mssql-conf ändert nur den Eintrag in der Konfiguration. Die vorhandenen Dateien bleiben liegen, und das neue Verzeichnis gehört meist noch root.
Was hilft
Stopp den Dienst, verschieb die Dateien mit erhaltenen Rechten, setz den Eigentümer auf mssql und starte erst dann neu. Was schiefging, steht in /var/opt/mssql/log/errorlog, nicht in der Ausgabe von systemctl.
Das siehst du
Geplante Aufträge laufen nicht, im Management Studio fehlt der Knoten für den Agent.
Warum
Der SQL Server Agent ist im Paket enthalten, aber ab Werk abgeschaltet.
Was hilft
Setz sqlagent.enabled auf true und starte den Dienst neu. Danach erscheint der Knoten, und bestehende Aufträge aus einer wiederhergestellten msdb laufen wieder an.
Das siehst du
RESTORE findet die Sicherungsdatei nicht, obwohl sie sichtbar im Verzeichnis liegt.
Warum
Das Dateisystem unterscheidet Groß- und Kleinschreibung. Ein Skript, das unter Windows mit /Backup/Vollsicherung.BAK lief, findet unter Linux nichts, wenn die Datei anders geschrieben ist.
Was hilft
Übernimm die Schreibweise exakt aus der Ausgabe von ls. Bei portierten Skripten lohnt es sich, Verzeichnisnamen und Erweiterungen grundsätzlich klein zu halten.
Sechs Unterschiede, die im Betrieb wirklich auffallen
- 01 Die Konfiguration liegt in einer Textdatei, nicht in der Registrierung.
- 02 Alle Datenverzeichnisse gehören dem Systembenutzer mssql, sonst startet nichts.
- 03 Dateipfade unterscheiden Groß- und Kleinschreibung, Skripte müssen exakt stimmen.
- 04 Der SQL Server Agent ist enthalten, aber ab Werk abgeschaltet.
- 05 Berichts- und Analysedienste laufen weiter nur auf einem Windows-Server.
- 06 Die automatische Übernahme im Fehlerfall organisiert Pacemaker statt eines Clusters.
Was du danach ohne Suchmaschine erledigst
Der Betrieb unter Linux besteht aus einer überschaubaren Zahl von Handgriffen, die sich von Windows unterscheiden. Wenn du weißt, wo die Konfiguration liegt, wem die Dateien gehören und welche Funktionen gar nicht erst zur Verfügung stehen, ist der Rest Alltagsarbeit.
Die Instanz einrichten und konfigurieren
Du installierst über das Paketrepository der Distribution, führst mssql-conf setup aus und legst Edition, Kennwort des Kontos sa und Sortierreihenfolge fest. Spätere Änderungen laufen alle über dasselbe Werkzeug und landen in /var/opt/mssql/mssql.conf.
Dateirechte richtig setzen
Du weißt, dass Daten-, Protokoll- und Sicherungsverzeichnisse dem Benutzer mssql gehören müssen, und dass auf Red Hat zusätzlich der SELinux-Kontext stimmen muss, wenn ein Pfad außerhalb der Voreinstellung liegt.
Den Dienst über systemd führen
Du startest, stoppst und prüfst die Instanz mit systemctl, liest den Zustand mit systemctl status mssql-server und findest das Fehlerprotokoll unter /var/opt/mssql/log/errorlog statt im Ereignisprotokoll.
Die fehlenden Funktionen vorher erkennen
Du prüfst vor dem Umzug, ob FILESTREAM, FileTable, erweiterte gespeicherte Prozeduren oder die Berichts- und Analysedienste im Einsatz sind, denn diese Bausteine gibt es unter Linux nicht.
Am Verzeichnisdienst anmelden
Du nimmst den Rechner mit realm join in die Domäne auf, erzeugst mit adutil einen Dienstprinzipal und eine Keytab-Datei und hinterlegst sie über mssql-conf. Erst danach funktionieren Anmeldungen mit Windows-Konten.
Hochverfügbarkeit anders denken
Statt des Windows-Failoverclusters übernimmt Pacemaker die automatische Übernahme. Du kennst den Unterschied zu einer Verfügbarkeitsgruppe mit Clustertyp NONE, bei der die Übernahme von Hand erfolgt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Installation und die ersten Entscheidungen
Die Installation läuft über das Paketrepository der jeweiligen Distribution, unterstützt sind Red Hat Enterprise Linux, Ubuntu in den Langzeitversionen und SUSE Linux Enterprise Server. Du fügst das Microsoft-Repository hinzu, installierst das Paket mssql-server und rufst danach sudo /opt/mssql/bin/mssql-conf setup auf. Dort wählst du die Edition, vergibst das Kennwort für sa und schließt die Einrichtung ab. Die Kommandozeilenwerkzeuge sqlcmd und bcp stecken in einem eigenen Paket und landen unter /opt/mssql-tools18/bin, das du sinnvollerweise in den Suchpfad aufnimmst.
Eine Entscheidung fällt dabei und lässt sich später nur mit Aufwand korrigieren: die Sortierreihenfolge der Instanz. Ohne Vorgabe richtet die Einrichtung SQL_Latin1_General_CP1_CI_AS ein, was für deutsche Datenbestände selten die gewünschte Wahl ist. Die Vorgabe setzt du über die Umgebungsvariable MSSQL_COLLATION vor dem Aufruf der Einrichtung, nachträglich geht es nur noch über mssql-conf set-collation und einen leeren Datenbestand. Wer eine bestehende Windows-Instanz umzieht, gleicht die Sortierreihenfolge vorab ab, sonst gibt es beim Verbinden von Tabellen aus Benutzerdatenbank und tempdb Konflikte.
Für den Speicher gilt eine eigene Regel. Die Instanz nimmt sich standardmäßig einen großen Teil des vorhandenen Arbeitsspeichers, und unter Linux gibt es keinen Dienst, der ihr das streitig macht, wohl aber den Mechanismus, der bei Speichermangel Prozesse beendet. Setz die Grenze mit memory.memorylimitmb bewusst, so dass dem Betriebssystem genügend übrig bleibt. Als Dateisystem für Daten- und Protokolldateien sind XFS und ext4 vorgesehen, und die Datendateien gehören auf ein eigenes Dateisystem, nicht in das Wurzelverzeichnis.
Was unter Linux nicht zur Verfügung steht
Die größte Gruppe sind die Dienste neben der Engine. Die Reporting Services, die Analysis Services, die Master Data Services und die Data Quality Services laufen ausschließlich auf einem Windows-Server. Wenn eine Fachabteilung ihre Berichte über die Reporting Services zieht, braucht der Umzug entweder einen zweiten Windows-Server für den Berichtsserver oder eine Ablösung, etwa über Power BI. Das ist der Punkt, an dem ein Linux-Projekt am häufigsten Umfang gewinnt.
In der Engine selbst fehlen die Bausteine, die eng am Windows-Dateisystem hängen: FILESTREAM und FileTable gibt es nicht, ebenso wenig die erweiterten gespeicherten Prozeduren. Damit entfällt auch xp_cmdshell, was Wartungsskripte betrifft, die auf diesem Weg Dateien verschieben oder aufräumen. Solche Aufgaben verlagerst du auf Shell-Skripte, die der Agent als Auftragsschritt ausführt, oder auf Systemd-Timer außerhalb der Datenbank.
Bei der Verteilung von Daten sind Momentaufnahme und transaktionale Verteilung möglich, die Zusammenführung mehrerer Schreibquellen dagegen nicht. Die Integration Services laufen in einer eingeschränkten Fassung: Pakete lassen sich über dtexec ausführen, der Katalog und viele Komponenten fehlen jedoch. Wer eine bestehende Ladestrecke mitnehmen will, prüft deshalb Paket für Paket, ob die verwendeten Komponenten überhaupt vorhanden sind, statt das gesamte Projekt auf einmal zu portieren.
Anmeldung über den Verzeichnisdienst
Anmeldungen mit Windows-Konten funktionieren auch unter Linux, der Weg dorthin sieht nur anders aus. Zuerst muss der Rechner selbst die Domäne kennen, das erledigst du mit realm join und der zugehörigen Namensauflösung. Danach erzeugst du mit dem Werkzeug adutil ein Konto im Verzeichnisdienst, legst den Dienstprinzipalnamen in der Form MSSQLSvc/vollständiger.name:1433 an und exportierst eine Keytab-Datei.
Diese Datei legst du unter /var/opt/mssql/secrets/ ab, setzt Eigentümer und Rechte so, dass ausschließlich der Benutzer mssql sie lesen kann, und trägst sie über mssql-conf mit network.kerberoskeytabfile ein. Nach einem Neustart des Dienstes legst du die Anmeldungen wie gewohnt mit CREATE LOGIN [DOMAENE\Benutzer] FROM WINDOWS an. Die Zeitsynchronisation ist dabei keine Nebensache, denn Kerberos verweigert Tickets, sobald die Uhr des Servers zu weit von der des Domänencontrollers abweicht.
Wenn beim Verbinden trotz korrekter Einrichtung nur eine Anmeldung mit Benutzername und Kennwort gelingt, liegt es fast immer am Dienstprinzipalnamen. Er muss genau zu dem Namen passen, mit dem der Client die Instanz anspricht. Verbindet sich eine Anwendung über einen Aliasnamen aus dem Namensdienst, während der Prinzipal auf den Rechnernamen ausgestellt ist, fällt die Verbindung stillschweigend auf NTLM zurück oder scheitert ganz.
Sicherung und Hochverfügbarkeit in dieser Umgebung
Die Sicherung selbst ändert sich nicht, BACKUP DATABASE und RESTORE arbeiten genau wie unter Windows, und die Dateien sind zwischen den Plattformen austauschbar. Anders ist der Weg zum Ablageort. Eine Netzfreigabe bindest du im Betriebssystem ein und achtest darauf, dass der Benutzer mssql dort schreiben darf, was bei CIFS über die Einhängeoptionen geregelt wird. Alternativ sicherst du direkt in einen Objektspeicher, denn BACKUP TO URL steht unter Linux ebenso zur Verfügung wie unter Windows.
Bei der Hochverfügbarkeit tritt Pacemaker mit Corosync an die Stelle des Windows-Failoverclusters. Du installierst den zugehörigen Ressourcenagenten, richtest eine Verfügbarkeitsgruppe mit dem Clustertyp EXTERNAL ein und überlässt Pacemaker die Entscheidung, wann übernommen wird. Ohne eine funktionierende Abschottung des ausgefallenen Knotens ist ein solcher Aufbau allerdings nicht vollständig, denn erst sie verhindert, dass beide Knoten sich gleichzeitig für den aktiven halten.
Wer diesen Aufwand nicht treiben will, wählt den Clustertyp NONE. Die Verfügbarkeitsgruppe repliziert dann weiterhin, Lesevorgänge lassen sich auf die zweite Kopie verteilen und die Sicherung kann dort laufen, aber die Übernahme im Fehlerfall erfolgt von Hand. Für viele Häuser ist das die ehrlichere Lösung: Ein Aufbau mit automatischer Übernahme, dessen Abschottung nie getestet wurde, ist im Ernstfall gefährlicher als ein dokumentierter Handgriff.
Dazu passende Kurse
Wer eine bestehende Instanz umziehen will, geht die Schritte am besten einmal an einem Testsystem durch, dafür gibt es die SQL-Server-Kurse für den Betrieb unter Linux .
Wenn Dateirechte, systemd und Paketverwaltung noch Neuland sind, lohnt sich der Umweg über die Grundlagen der Linux-Administration , bevor die Datenbank dazukommt.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Kann ich eine Sicherung von Windows unter Linux wiederherstellen?
Wo finde ich das Fehlerprotokoll und die Dienstmeldungen?
Läuft der SQL Server auch in einem Container?
Brauche ich eine andere Lizenz für die Linux-Variante?
Passt thematisch dazu
Dass eine abweichende Uhrzeit oder ein falscher DNS-Eintrag die Anmeldung kippen lässt, ergibt sich aus die Funktionsweise der Kerberos-Anmeldung im Windows-Netz .
Sobald die erste Instanz produktiv unter Linux läuft, braucht es eine Antwort darauf, wer Pakete freigibt und wie Updates gestaffelt ausgerollt werden, und genau diese Fragen beantwortet ein Einführungspfad mit Patchprozess, Härtung und Supportmodell .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Linux-Betrieb, der über die erste Installation hinausträgt
Bei cmt richtest du eine Instanz auf einer Linux-Maschine selbst ein, von den Dateirechten über den Agent bis zur Anmeldung an der Domäne.