SQL Server on Linux:

Ja, das gibt es wirklich — und es ist erstaunlich gut

7.1 Vom Unmöglichen zur Produktionsreife: Eine kurze Geschichte

Wer 2015 erzählt hätte, dass Microsoft SQL Server auf Linux laufen wird, hätte gelacht bekommen. Nicht ein müdes Lächeln — echtes Lachen. SQL Server war das Windows-exklusivste Produkt, das Microsoft je gebaut hatte. Und dann, im Jahr 2016, kündigte Microsoft SQL Server for Linux an. Produktionsreife kam mit SQL Server 2017.

Was sich seitdem gezeigt hat: SQL Server on Linux ist kein Marketing-Projekt. Die Performance ist mit Windows vergleichbar, die Feature-Parität ist hoch, und für Container-Deployments ist Linux sogar die bevorzugte Plattform. In Kubernetes-Umgebungen findet man SQL Server for Linux inzwischen häufiger als Windows-basierte Instanzen.

Der Schlüssel dahinter ist die SQLPAL-Schicht — eine technische Meisterleistung, die wir uns gleich genauer anschauen. Aber zuerst: Warum sollte ein Administrator oder Entwickler das überhaupt interessieren? Weil SQL Server on Linux in modernen Infrastrukturen keine Randerscheinung mehr ist. Wer Container-Deployments macht, wer Kubernetes nutzt, wer Kosten mit Linux-Lizenzen spart — der wird SQL Server on Linux früher oder später begegnen.

7.2 SQLPAL: Wie SQL Server auf Linux läuft ohne Linux zu kennen

SQL Server ist seit Jahrzehnten auf Windows-APIs ausgerichtet. Der Code ruft Win32-Funktionen auf, nutzt Windows-Threads, Windows-IO, Windows-Sicherheitsmodelle. Diesen Code komplett für Linux umzuschreiben hätte Jahre gekostet und wäre riskant gewesen. Microsoft hat einen anderen Weg gewählt: SQLPAL.

 

Definition: SQLPAL — SQL Platform Abstraction Layer
SQLPAL ist eine Abstraktionsschicht zwischen SQL Server und dem Linux-Kernel. Sie basiert auf der "Drawbridge"-Technologie aus Microsoft Research — einer Library-Betriebssystem-Architektur. SQLPAL übersetzt Windows-API-Aufrufe von SQL Server transparent in entsprechende Linux-Syscalls. SQL Server "denkt", er läuft auf Windows — der Linux-Kernel sieht nur Standard-POSIX-Aufrufe.

 

 

Abb. 7.1: SQLPAL-Architektur zwischen SQL Server und Linux-Kernel

Die praktische Konsequenz: T-SQL, DMVs, Query Processing, Buffer Pool, Locking — das alles funktioniert auf Linux genauso wie auf Windows. Derselbe Code, dieselbe Logik, dieselben Diagnose-Abfragen. Was ein DBA über SQL Server auf Windows weiß, gilt 1:1 für Linux. Das ist die eigentliche Leistung von SQLPAL: keine neue Lernkurve für die SQL-Ebene.

Was sich ändert, ist die Infrastruktur-Ebene: Installation, Konfiguration, Dateisystem-Wahl, Kernel-Parameter, Monitoring-Tools. Da gilt Linux-Know-how — und das ist der Teil, den wir in diesem Kapitel durchgehen.

7.3 Unterstützte Distributionen

Microsoft unterstützt offiziell drei Linux-Distributionsfamilien. Stand SQL Server 2022:

 

Distribution	Version	Status	Anmerkung
Red Hat Enterprise Linux	RHEL 8.x, 9.x	Vollständig unterstützt	Häufigste Wahl in Enterprise-Umgebungen
Ubuntu	20.04 LTS, 22.04 LTS	Vollständig unterstützt	Bevorzugt für Container und Cloud
SUSE Linux Enterprise Server	SLES 15 SP3+	Vollständig unterstützt	Typisch in SAP-nahen Umgebungen
Azure Linux (Mariner)	2.0+	Unterstützt	Azure-Container-Images
Debian / andere	Verschiedene	Nicht offiziell	Community-Support, kein MS-Support

Tab. 7.1: Unterstützte Linux-Distributionen (SQL Server 2022)

 

Für Produktionsumgebungen gilt: nur offiziell unterstützte Distributionen und Versionen. Debian funktioniert oft, ist aber kein Support-Kandidat bei Microsoft. Wer Kunden-Environments betreut, greift zu RHEL oder Ubuntu — da gibt es keine bösen Überraschungen bei Service-Requests.

7.4 Feature-Unterschiede: Was auf Linux anders ist

Die Feature-Parität zwischen Windows und Linux ist mit jeder SQL Server Version gewachsen. Für die meisten OLTP-Workloads und Analytics-Szenarien sind die Unterschiede heute irrelevant. Trotzdem gibt es Bereiche, die man kennen sollte.

 

Feature	Windows	Linux	Anmerkung
Always On Availability Groups	Vollständig	Vollständig	Auch ohne Windows Cluster (Pacemaker)
Failover Clustering (FCI)	Vollständig	Mit Pacemaker	Aufwändiger zu konfigurieren
ColumnStore Index	Vollständig	Vollständig
In-Memory OLTP	Vollständig	Vollständig
SQL Server Agent	Vollständig	Vollständig	Einige Subsysteme eingeschränkt
Replication	Vollständig	Vollständig (ab 2019)	Einige Topologien erst ab 2019
Distributed Transactions (MSDTC)	Vollständig	Eingeschränkt	Funktioniert, aber Konfigurationsaufwand
Extended Events	Vollständig	Vollständig
SQL Server Audit	Vollständig	Vollständig
Linked Servers (AD-Auth)	Vollständig	Eingeschränkt	Kerberos-Konfiguration nötig
Windows Authentication	Vollständig	Über Kerberos	Konfigurationsaufwand mit AD
SSMS GUI-Tools	Lokal + Remote	Nur Remote (SSMS läuft auf Windows)	Azure Data Studio auf Linux nativ

Tab. 7.2: Feature-Vergleich Windows vs. Linux

 

Die häufigste Stolperfalle in der Praxis: Windows Authentication. Auf Windows ist das transparent — AD-Authentifizierung funktioniert automatisch. Auf Linux braucht man Kerberos-Konfiguration via realm join oder adcli. Wer SQL Server auf Linux in einer Active-Directory-Umgebung betreibt, sollte das frühzeitig in die Planung einbeziehen. SQL Authentication ist dagegen auf beiden Plattformen identisch und für viele Anwendungsszenarien völlig ausreichend.

7.5 Installation und Konfiguration mit mssql-conf

Die Installation erfolgt über die Standard-Paketverwaltung der Distribution. Microsoft stellt offizielle Repositories bereit. Das eigentliche Konfigurationswerkzeug ist mssql-conf — ein Python-Script, das die wichtigsten SQL-Server-Einstellungen kapselt.

# Ubuntu: Microsoft-Repository hinzufügen und SQL Server installieren

curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -

curl https://packages.microsoft.com/config/ubuntu/22.04/mssql-server-2022.list \

  | sudo tee /etc/apt/sources.list.d/mssql-server.list

sudo apt-get update

sudo apt-get install -y mssql-server

 

# Initiale Konfiguration: SA-Passwort setzen, Edition wählen

sudo /opt/mssql/bin/mssql-conf setup

 

# RHEL: Alternative über dnf

sudo dnf install -y mssql-server

mssql-conf: Der Konfigurationsschlüssel

Was auf Windows über die SQL Server Configuration Manager-GUI oder Registrierungsschlüssel passiert, passiert auf Linux über mssql-conf. Das Tool schreibt seine Einstellungen in /var/opt/mssql/mssql.conf.

# Maximalen Arbeitsspeicher begrenzen (wichtig in VMs und Containern!)

# Entspricht "max server memory" in sp_configure

sudo /opt/mssql/bin/mssql-conf set memory.memorylimitmb 8192

 

# SQL Server Agent aktivieren

sudo /opt/mssql/bin/mssql-conf set sqlagent.enabled true

 

# Standarddatenpfade festlegen

sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /data/sqldata

sudo /opt/mssql/bin/mssql-conf set filelocation.defaultlogdir /data/sqllogs

sudo /opt/mssql/bin/mssql-conf set filelocation.defaultbackupdir /backup

 

# TempDB-Dateien auf schnellen Storage legen

sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdumpdir /data/sqldump

 

# Aktuelle Konfiguration anzeigen

sudo /opt/mssql/bin/mssql-conf show

 

# SQL Server nach Konfigurationsänderungen neu starten

sudo systemctl restart mssql-server

 

Tipp: mssql.conf direkt bearbeiten ist möglich, aber riskant
Die Datei /var/opt/mssql/mssql.conf ist eine einfache INI-Datei. Man kann sie direkt editieren, aber mssql-conf validiert Eingaben — direkte Edits tun das nicht. Im Zweifel: mssql-conf nutzen.

 

7.6 Performance-Besonderheiten unter Linux

SQL Server auf Linux verhält sich wie SQL Server auf Windows — solange die Linux-Infrastruktur korrekt konfiguriert ist. Es gibt einige Linux-spezifische Einstellungen die man kennen muss, sonst verschenkt man Performance.

Filesystem-Wahl: XFS für Data, ext4 geht auch

Für SQL Server Data- und Log-Dateien empfiehlt Microsoft XFS. XFS ist für große Dateien und hohen Datendurchsatz optimiert — genau das, was SQL Server braucht. ext4 funktioniert auch, aber XFS liefert bei intensiver IO-Last typischerweise 5–15% bessere Durchsatzwerte. Für TempDB auf NVMe-Storage ist der Unterschied oft noch größer, weil XFS bei parallelen Schreibzugriffen skalierbarer ist. Der Zusammenhang zwischen Filesystem-Wahl, IO-Performance und TempDB wird in Kapitel 2 (Storage) und Kapitel 13 (TempDB) ausführlich behandelt.

Transparent Huge Pages deaktivieren

Transparent Huge Pages (THP) ist eine Linux-Funktion, die große Speicherseiten (2 MB statt 4 KB) automatisch zusammenfasst. Das klingt wie eine Optimierung — und für manche Workloads ist es das auch. Für Datenbankserver (SQL Server, Oracle, MySQL) ist THP aber ein Performance-Problem: die Defragmentierungs-Hintergrundprozesse können zu unvorhersehbaren Latenz-Spitzen führen. Microsoft empfiehlt THP zu deaktivieren.

# THP-Status prüfen

cat /sys/kernel/mm/transparent_hugepage/enabled

# [always] madvise never  → "always" ist aktiv — das ist falsch für SQL Server

 

# THP sofort deaktivieren (bis zum nächsten Reboot)

echo never > /sys/kernel/mm/transparent_hugepage/enabled

echo never > /sys/kernel/mm/transparent_hugepage/defrag

 

# THP dauerhaft deaktivieren via systemd-Service

# /etc/systemd/system/disable-thp.service erstellen:

[Unit]

Description=Disable Transparent Huge Pages (THP)

DefaultDependencies=no

After=sysinit.target local-fs.target

 

[Service]

Type=oneshot

ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"

ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"

 

[Install]

WantedBy=basic.target

 

systemctl enable disable-thp

systemctl start disable-thp

IO-Scheduler: none für SSDs und NVMe

Der Linux-IO-Scheduler entscheidet, in welcher Reihenfolge Schreibanforderungen an das Storage-Subsystem weitergegeben werden. Für traditionelle Festplatten macht Scheduling Sinn — der Scheduler optimiert die Seekbewegungen des Schreibkopfs. Für SSDs und NVMe ist das kontraproduktiv: diese Geräte haben keinen Schreibkopf, und jede Scheduler-Einmischung kostet nur Zeit.

# Aktuellen IO-Scheduler für ein Storage-Gerät prüfen

cat /sys/block/sda/queue/scheduler

# Ausgabe: mq-deadline [kyber] none  → [kyber] ist aktiv

 

# Auf "none" (kein Scheduling) setzen für SSD/NVMe

echo none > /sys/block/nvme0n1/queue/scheduler

 

# Dauerhaft über udev-Regel setzen (anpassen für deine Geräte)

# /etc/udev/rules.d/60-mssql-scheduler.rules:

ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"

NUMA-Konfiguration unter Linux

SQL Server on Linux erkennt NUMA-Topologien automatisch über die Linux-Kernel-Informationen — genauso wie auf Windows (wie in Kapitel 1 beschrieben). Die NUMA-Affinität von SQL-Server-Threads wird über SQLPAL korrekt an den Linux-Scheduler übergeben. Man muss nichts explizit konfigurieren. Was sich ändert: die Überprüfung. Auf Linux prüft man NUMA-Topologien mit numactl:

# NUMA-Topologie des Systems anzeigen

numactl --hardware

# Zeigt: Nodes, CPUs pro Node, Speicher pro Node, Distanzmatrix

 

# SQL Server NUMA-Erkennung prüfen

-- (via sqlcmd oder SSMS)

SELECT * FROM sys.dm_os_nodes ORDER BY node_id;

-- node_state_desc sollte "ONLINE" zeigen, eine Zeile pro NUMA-Node

Memory-Konfiguration: Warum memory.memorylimitmb auf Linux wichtiger ist als auf Windows

Auf Windows schützt sich SQL Server über den Windows Memory Manager vor übermäßigem Speicherverbrauch. Das Betriebssystem kann Seiten auslagern, und SQL Server reagiert darauf mit dem Buffer Pool Management. Auf Linux gibt es diesen Schutzmechanismus in dieser Form nicht. Ohne explizites Limit versucht SQL Server, so viel RAM wie möglich zu belegen — bis Linux die Reißleine zieht. Und Linux zieht die Reißleine nicht sanft.

Der Übeltäter heißt OOM-Killer: der Out-Of-Memory-Killer des Linux-Kernels. Wenn der Speicher knapp wird und kein Prozess freiwillig verzichtet, wählt der OOM-Killer einen Prozess aus und beendet ihn — sofort, ohne Vorwarnung, ohne graceful shutdown. Trifft es den SQL Server Prozess (sqlservr), ist das eine harte Instanzabschaltung. Keine saubere Datenbankwiederherstellung, kein kontrolliertes Checkpoint-Flushing — einfach weg. Beim nächsten Start läuft die Crash Recovery durch, was je nach Datenbankgröße und Workload zwischen Sekunden und vielen Minuten dauern kann.

 

Warnung: OOM-Killer trifft lieber große Prozesse — und SQL Server ist groß

Der Linux-OOM-Killer berechnet für jeden Prozess einen "oom_score" — je mehr Speicher ein Prozess belegt, desto höher der Score, desto wahrscheinlicher wird er abgeschossen. Ein SQL Server ohne Memory-Limit ist damit ein bevorzugtes OOM-Ziel. Die Empfehlung: immer memory.memorylimitmb setzen. Als Faustregel 85% des physischen RAMs, niemals mehr als 90%. Auf einer Maschine mit 32 GB RAM also maximal 27.000 MB für SQL Server — der Rest gehört dem Betriebssystem und anderen Prozessen. Mehr dazu in Kapitel 5 (Serverkonfiguration) und Kapitel 11 (Memory Management).

 

# memory.memorylimitmb setzen — das ist das Linux-Äquivalent zu max server memory

# 85% von 32 GB = ~27.000 MB

sudo /opt/mssql/bin/mssql-conf set memory.memorylimitmb 27648

 

# Konfiguration prüfen

sudo /opt/mssql/bin/mssql-conf show memory

 

# OOM-Killer-Ereignisse im Systemlog prüfen — war SQL Server schon mal Opfer?

# dmesg zeigt Kernel-Ringpuffer, grep filtert auf OOM-relevante Einträge

dmesg | grep -i "oom"

# Alternativ im systemd-Journal (zeigt auch ältere Ereignisse)

journalctl -k | grep -i "out of memory"

 

# Den OOM-Score von sqlservr prüfen — je höher, desto gefährdeter

# PID ermitteln:

MSSQL_PID=$(pgrep sqlservr | head -1)

cat /proc/$MSSQL_PID/oom_score

# Wert > 500: hohes Risiko. Wert < 200: moderates Risiko.

 

# Optional: OOM-Score für SQL Server manuell senken (schützt den Prozess etwas)

# -17 = vollständig vom OOM-Killer ausschließen (nur in gut kontrollierten Umgebungen)

# -1000 entspricht dem modernen Äquivalent

echo -1000 > /proc/$MSSQL_PID/oom_score_adj

Wer NUMA-Konfiguration für SQL Server auf Linux feinjustieren möchte, kann über mssql-conf auch die CPU-Affinität steuern. Das ist auf Maschinen mit vielen NUMA-Nodes relevant — etwa, wenn SQL Server nur auf bestimmten Nodes laufen soll, während andere Nodes für Anwendungsserver reserviert sind. Die NUMA-Grundlagen dazu sind in Kapitel 1 (Hardware) und Kapitel 11 (Memory Management) beschrieben.

# CPU-Affinität für SQL Server einschränken (optional, für NUMA-Tuning)

# Beispiel: SQL Server auf CPUs 0-7 beschränken (NUMA-Node 0 auf Dual-Socket-System)

sudo /opt/mssql/bin/mssql-conf set processoraffinitymask 255

# Wert ist eine Bitmaske: 255 = binär 11111111 = CPUs 0-7

 

# Für 64-Bit-Systeme mit mehr als 64 CPUs: processoraffinitymask64 nutzen

# Empfehlung: erst NUMA-Topologie mit numactl --hardware verstehen,

# dann berechnen welche CPUs welchem Node gehören.

7.7 Container: SQL Server in Docker und Kubernetes

SQL Server in Containern ist keine Zukunftstechnologie mehr — das ist gelebte Praxis. Entwicklungsumgebungen, CI/CD-Pipelines, Test-Stacks, Kubernetes-basierte Applikationen: überall laufen SQL-Server-Container. Das offizielle Image kommt direkt von Microsoft.

SQL Server in Docker

# SQL Server 2022 Container starten

# --name:        Container-Name für spätere Befehle

# -e SA_PASSWORD: SA-Passwort (Mindestanforderungen beachten!)

# -e ACCEPT_EULA: Lizenzvereinbarung akzeptieren (Y = ja)

# -p 1433:1433:  Port-Mapping Host:Container

# -v:            Volume für Datenpersistenz (ohne Volume gehen Daten verloren!)

# -d:            Detached = im Hintergrund laufen

docker run -d \

  --name sqlserver2022 \

  -e "ACCEPT_EULA=Y" \

  -e "SA_PASSWORD=Str0ngP@ssw0rd!" \

  -e "MSSQL_PID=Developer" \

  -p 1433:1433 \

  -v sqldata:/var/opt/mssql \

  mcr.microsoft.com/mssql/server:2022-latest

 

# Verbindung prüfen (sqlcmd im Container)

docker exec -it sqlserver2022 /opt/mssql-tools/bin/sqlcmd \

  -S localhost -U SA -P 'Str0ngP@ssw0rd!' -Q 'SELECT @@VERSION'

 

# Logs des Containers anzeigen

docker logs sqlserver2022

 

Warnung: Das Persistenz-Problem: Volumes sind Pflicht
Ein SQL Server Container ohne Volume verliert alle Daten, wenn der Container stoppt oder neu erstellt wird. Das ist gewollt für Wegwerf-Container in CI/CD-Pipelines, aber fatal für alles andere. Immer ein Volume einbinden: -v sqldata:/var/opt/mssql. Der Pfad /var/opt/mssql enthält Daten, Logs und Konfiguration.

 

SQL Server in Kubernetes

Für Produktionsszenarien in Kubernetes nutzt man StatefulSets — sie garantieren stabile Netzwerk-Identitäten und persistenten Storage für jeden Pod. Ein minimales Beispiel:

# Kubernetes StatefulSet für SQL Server (vereinfacht)

# In der Praxis: Secrets für SA_PASSWORD, PersistentVolumeClaim für Storage

apiVersion: apps/v1

kind: StatefulSet

metadata:

  name: mssql

spec:

  serviceName: "mssql"

  replicas: 1

  selector:

    matchLabels:

      app: mssql

  template:

    metadata:

      labels:

        app: mssql

    spec:

      containers:

      - name: mssql

        image: mcr.microsoft.com/mssql/server:2022-latest

        ports:

        - containerPort: 1433

        env:

        - name: ACCEPT_EULA

          value: "Y"

        - name: SA_PASSWORD

          valueFrom:

            secretKeyRef:

              name: mssql-secret

              key: SA_PASSWORD

        - name: MSSQL_MEMORY_LIMIT_MB

          value: "4096"

        volumeMounts:

        - name: sqldata

          mountPath: /var/opt/mssql

  volumeClaimTemplates:

  - metadata:

      name: sqldata

    spec:

      accessModes: ["ReadWriteOnce"]

      resources:

        requests:

          storage: 50Gi

Das StatefulSet-Konzept ist entscheidend: jeder Pod bekommt einen eigenen PersistentVolumeClaim. Bei einem Pod-Neustart (durch Crash oder Rolling Update) wird derselbe PVC wieder eingebunden — die Daten bleiben erhalten. Im Gegensatz zum Deployment (das zustandslos ist und keinen stabilen Storage garantiert) ist das StatefulSet der richtige Typ für Datenbankworkloads.

7.8 Always On Availability Groups auf Linux

Always On Availability Groups funktionieren auf Linux — ohne Windows Server Failover Cluster. Das ist der fundamentale Unterschied zur Windows-Welt: auf Windows setzt eine AG einen WSFC (Windows Server Failover Cluster) als Unterbau voraus. Auf Linux übernimmt diese Rolle entweder Pacemaker oder — in Kubernetes-Umgebungen — der Kubernetes-Controller selbst. Das Ergebnis ist dasselbe: automatisches Failover bei Instanzausfall, synchrone oder asynchrone Replikation, lesbare Sekundärreplikate. Der Weg dahin ist aber ein anderer.

Pacemaker als Cluster-Manager (RHEL und SLES)

Auf RHEL- und SLES-basierten Umgebungen ist Pacemaker der Standard-Cluster-Manager für SQL Server AGs. Pacemaker ist ein ausgewachsenes Open-Source-Cluster-Framework das Ressourcen überwacht und bei Ausfall automatisch auf einen anderen Knoten verschiebt. Die Kombination aus Pacemaker und dem SQL Server Resource Agent (mssql-server-ha-Paket) ergibt ein vollwertiges HA-Setup. Die Konfiguration ist aufwändiger als auf Windows — wer WSFC gewohnt ist, braucht etwas Eingewöhnung in Pacemaker-Konzepte wie CIB (Cluster Information Base) und Constraint-basierte Ressourcensteuerung.

-- AG-Status auf Linux prüfen — identische Abfrage wie auf Windows

-- Zeigt alle konfigurierten Availability Groups der Instanz

SELECT

    ag.name                     AS ag_name,

    ag.automated_backup_preference_desc,

    ag.failure_condition_level,

    ags.primary_replica,

    ags.synchronization_health_desc

FROM sys.availability_groups ag

JOIN sys.dm_hadr_availability_group_states ags

    ON ag.group_id = ags.group_id;

 

-- Replikat-Status aller Knoten abfragen

SELECT

    ar.replica_server_name,

    ar.availability_mode_desc,      -- SYNCHRONOUS_COMMIT oder ASYNCHRONOUS_COMMIT

    ar.failover_mode_desc,          -- AUTOMATIC oder MANUAL

    ars.role_desc,                  -- PRIMARY oder SECONDARY

    ars.connected_state_desc,       -- CONNECTED oder DISCONNECTED

    ars.synchronization_health_desc -- HEALTHY, PARTIALLY_HEALTHY, NOT_HEALTHY

FROM sys.availability_replicas ar

JOIN sys.dm_hadr_availability_replica_states ars

    ON ar.replica_id = ars.replica_id

ORDER BY ars.role_desc;

 

-- Pacemaker-Cluster-Status aus der Shell (nicht aus SQL Server)

# Zeigt alle Ressourcen und ihren aktuellen Status

sudo pcs status

# Detaillierter: inkl. Constraint-Konfiguration

sudo pcs status --full

Kubernetes: External Lease Mode

In Kubernetes-Deployments gibt es keinen Pacemaker. Kubernetes übernimmt das Neustartendes Pods automatisch — wenn ein Pod abstürzt, startet der Controller einen neuen Pod auf einem verfügbaren Node und bindet den PersistentVolumeClaim wieder ein. Das ist kein echtes AG-Failover sondern ein Restart-Mechanismus. Für einfache Szenarien (ein primäres Replikat, kein automatisches Failover auf ein Sekundärreplikat) reicht das. Für echte AG-Szenarien in Kubernetes — mehrere Replikate, automatisches Failover — gibt es den External Lease Mode.

External Lease Mode ist eine AG-Konfiguration bei der kein externer Cluster-Manager für die Lease-Verwaltung zuständig ist. SQL Server verwaltet dabei die Primär-Rolle selbst, und ein externer Operator (z.B. der SQL Server Operator for Kubernetes oder ein Custom Operator) steuert Failover-Entscheidungen. Das Modell ist für Kubernetes-native Umgebungen gedacht und vermeidet die Komplexität eines vollständigen Pacemaker-Setups im Container.

 

Hinweis: AG-Features auf Linux: Welche Edition, welche Funktionen?

Basic Availability Groups: ab Standard Edition verfügbar, ein Datenbank-AG, kein lesbares Sekundärreplikat. Read-Scale AGs: kein automatisches Failover, aber lesbare Sekundärreplikate für Reporting-Workloads — sehr beliebt in Kubernetes für Read-Scale-Szenarien. Standard AGs mit Pacemaker: automatisches Failover, bis zu 9 Sekundärreplikate, synchrone und asynchrone Modi. Alle diese AG-Typen funktionieren auf Linux genauso wie auf Windows. Die vollständige Behandlung von Availability Groups — Architektur, Failover-Mechanismen, RPO/RTO-Planung — findest du in Band 2 (High Availability & Disaster Recovery).

 

Eine praktische Empfehlung für den Alltag: Wer SQL Server AGs auf Linux plant, sollte die Entscheidung zwischen Pacemaker und Kubernetes früh treffen. Pacemaker ist mächtiger und flexibler, verlangt aber Linux-Cluster-Know-how. Kubernetes ist einfacher zu betreiben, wenn die Infrastruktur bereits Kubernetes-basiert ist, aber bietet weniger Kontrolle über Failover-Timing und -Logik. Für gemischte Umgebungen (einige SQL Server on Linux, einige on Windows) gilt: die AG-Konfiguration auf SQL-Ebene ist identisch — nur der Cluster-Unterbau unterscheidet sich.

7.9 mssql-tools: sqlcmd und bcp unter Linux

Für die Kommandozeilen-Arbeit mit SQL Server on Linux stellt Microsoft die mssql-tools-Pakete bereit: sqlcmd und bcp. Das sind funktional äquivalente Werkzeuge zur Windows-Version — wer mit sqlcmd auf Windows umgehen kann, kommt sofort zurecht.

# mssql-tools installieren (Ubuntu)

sudo apt-get install -y mssql-tools unixodbc-dev

 

# PATH erweitern damit sqlcmd direkt aufrufbar ist

echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc

source ~/.bashrc

 

# Verbindung zu lokalem SQL Server

sqlcmd -S localhost -U SA -P 'Passwort' -Q "SELECT @@SERVERNAME, @@VERSION"

 

# Verbindung zu Remote-Server mit Windows-Auth (Kerberos nötig)

sqlcmd -S sqlserver.domain.local -E -Q "SELECT name FROM sys.databases"

 

# T-SQL-Script aus Datei ausführen

sqlcmd -S localhost -U SA -P 'Passwort' -i /scripts/setup.sql -o /logs/output.log

 

# go18 — sqlcmd v2: modernes Tool mit verbessertem Output

# Installation: go install github.com/microsoft/go-sqlcmd/cmd/sqlcmd@latest

sqlcmd -S localhost -U SA -P 'Passwort' --format table -Q "SELECT top 10 name FROM sys.objects"

7.10 Monitoring: Was auf Linux anders geht

Die SQL-Server-interne Diagnose-Ebene — DMVs, Extended Events, Wait Statistics, Query Store — funktioniert auf Linux identisch zu Windows. Alle Abfragen die in diesem Buch gezeigt werden, laufen auf beiden Plattformen. Der Unterschied liegt bei den Tools und der System-Ebene.

 

Tool / Methode	Windows	Linux	Anmerkung
SSMS	Nativ	Nur Remote-Verbindung	SSMS läuft nur auf Windows, verbindet sich aber zu Linux-Instanz
Azure Data Studio	Nativ	Nativ	Plattformübergreifend, für Linux empfohlen
sqlcmd	Nativ	Via mssql-tools	Funktional identisch
SQL Server Error Log	Event Viewer / Pfad	/var/opt/mssql/log/errorlog	Lesbar mit cat, tail, less
Performance Monitor (perfmon)	Nativ	Nicht verfügbar	Ersatz: sys.dm_os_performance_counters
DMVs	Vollständig	Vollständig	Identisch auf beiden Plattformen
Extended Events	Vollständig	Vollständig
Systemressourcen (CPU/RAM)	Task Manager, perfmon	top, htop, vmstat, iostat	Standard-Linux-Tools

Tab. 7.3: Monitoring-Tools Windows vs. Linux

 

-- SQL Server Error Log direkt aus T-SQL lesen (funktioniert auf Linux identisch)

EXEC sp_readerrorlog 0, 1, 'Error';  -- aktuelle Log-Datei, nur Fehler

 

-- Oder aus der Shell: neueste Einträge des Error Logs verfolgen

-- tail -f zeigt neue Zeilen in Echtzeit — praktisch beim Troubleshooting

sudo tail -f /var/opt/mssql/log/errorlog

 

-- CPU-Nutzung von SQL Server auf Linux-Ebene überwachen

-- PID des mssql-Prozesses ermitteln

pgrep -a sqlservr

 

-- Performance-Counters aus SQL Server (ersetzt perfmon)

SELECT object_name, counter_name, instance_name, cntr_value

FROM sys.dm_os_performance_counters

WHERE counter_name IN ('Page life expectancy',

                       'Batch Requests/sec',

                       'SQL Compilations/sec');

Linux-Systemmetriken für den DBA

Ein Windows-DBA der erstmals auf einem Linux-Server arbeitet, vermisst den Task Manager. Die gute Nachricht: Linux hat bessere Werkzeuge. Die weniger gute: man muss ein paar Befehle lernen. Hier die wichtigsten, direkt übersetzt in SQL-Server-Kontext:

 

Linux-Tool	Was es zeigt	SQL-Server-Relevanz	Typischer Befehl
top / htop	CPU-Auslastung und RAM pro Prozess in Echtzeit	Gesamtlast, sqlservr-Anteil, CPU-Steal in VMs	top -p $(pgrep sqlservr)
iostat -x	IO-Durchsatz und Latenz pro Gerät	Entspricht DiskLatency in perfmon — zeigt ob Storage gesättigt ist	iostat -x 1 5
vmstat	Speicher, Swap, IO-Queues, CPU in Summe	Swap-Aktivität (si/so) zeigt Memory-Pressure	vmstat 1 10
sar	Historische System-Metriken (CPU, RAM, IO, Netzwerk)	Trendanalyse, Baseline-Erhebung ohne SQL Server	sar -u 1 60
numactl –hardware	NUMA-Topologie des Systems	Voraussetzung für NUMA-Konfiguration (Kap. 1)	numactl –hardware
free -h	RAM und Swap Übersicht	Schnellcheck: wie viel RAM ist wirklich frei?	free -h

Tab. 7.4: Linux-Systemtools für den SQL Server DBA

 

# top: nur den sqlservr-Prozess beobachten, 1-Sekunden-Refresh

# CPU%-Wert kann über 100% liegen bei Mehrkernsystemen (Summe aller Kerne)

top -p $(pgrep sqlservr | head -1) -d 1

 

# iostat: IO-Latenz pro Gerät, 5 Messungen alle 1 Sekunde

# Wichtige Spalten: await (Latenz in ms), %util (Auslastung in %)

# await > 10ms auf SSD: Storage-Problem. await > 1ms auf NVMe: ungewöhnlich.

iostat -x 1 5

 

# vmstat: Memory-Pressure erkennen

# si/so = swap in/swap out — wenn diese Werte > 0 sind: ernstes Problem

# SQL Server auf einem System das swappt ist ein SQL Server der leidet

vmstat 1 10

 

# sar: historische CPU-Nutzung der letzten Stunde (falls sysstat installiert)

# -u = CPU, -r = RAM, -d = Disk

sar -u 1 60   # CPU der nächsten 60 Sekunden, einmal pro Sekunde

sar -r        # RAM-Nutzung historisch aus dem sar-Archiv

 

# Zusammenhang: wenn SQL Server zu viel CPU zeigt (Kap. 9, Wait Statistics),

# bestätigt top das auf OS-Ebene. Wenn iostat hohe await-Werte zeigt,

# erklärt das PAGEIOLATCH-Waits in sys.dm_os_wait_stats.

Der entscheidende Punkt: Linux-Systemmetriken und SQL-Server-interne Metriken ergänzen sich. Ein hoher await-Wert in iostat erklärt PAGEIOLATCH_SH-Waits in den Wait Statistics (Kapitel 9). Hohe si/so-Werte in vmstat erklären warum der Buffer Pool schrumpft und die Page Life Expectancy einbricht (Kapitel 11). Das Bild wird erst vollständig, wenn man beide Ebenen zusammen betrachtet — das SQL-Server-interne Diagnose-Toolkit und die Linux-Systemwerkzeuge.

 

Tipp: htop ist top mit Komfort — einmal installieren, nie bereuen
htop zeigt dieselben Informationen wie top, aber mit farbiger Darstellung, sortierbaren Spalten und einer NUMA-Ansicht. Auf einem frisch aufgesetzten Linux-Server oft nicht vorinstalliert: sudo apt install htop oder sudo dnf install htop. Fünf Minuten Investition, täglicher Nutzen im Troubleshooting.

 

Zusammenfassung

SQL Server on Linux ist erwachsen geworden. Die SQLPAL-Architektur sorgt dafür, dass das SQL-Know-how vollständig übertragbar ist — T-SQL, DMVs, Extended Events, Query Store, alles identisch. Was sich ändert, ist die Infrastruktur-Ebene: Linux-Dateisystem, Kernel-Parameter, mssql-conf statt Registrierung, systemd statt Windows Services.

Die wichtigsten Punkte auf einen Blick:

SQLPAL übersetzt Windows-API-Calls transparent in Linux-Syscalls — SQL Server "denkt" er läuft auf Windows.

Unterstützte Distributionen: RHEL, Ubuntu, SLES — nur offiziell unterstützte Versionen für Produktion.

Feature-Parität ist hoch: AG, ColumnStore, In-Memory OLTP, XE, SQL Audit — alles dabei.

mssql-conf ist das zentrale Konfigurationswerkzeug auf Linux.

XFS als Dateisystem, THP deaktivieren, IO-Scheduler "none" für SSDs: drei Einstellungen mit spürbarem Effekt.

memory.memorylimitmb immer setzen — ohne Limit riskiert man OOM-Killer-Ereignisse und harte Instanzabschaltungen.

Always On AGs auf Linux: Pacemaker für RHEL/SLES, External Lease Mode für Kubernetes — ohne WSFC.

Container-Einsatz: Docker für Entwicklung, Kubernetes StatefulSets für Produktion — Volumes immer!

Monitoring: Azure Data Studio und SSMS (remote) auf der Tool-Ebene, DMVs auf der SQL-Ebene identisch.

Linux-Systemtools (top, iostat, vmstat, sar) ergänzen die SQL-Server-internen Diagnosewerkzeuge.

 

Ausblick auf Kapitel 8: Mit der Infrastruktur im Griff beginnt jetzt die eigentliche Diagnose-Arbeit. Kapitel 8 führt in Extended Events ein — das mächtigste Diagnosewerkzeug das SQL Server bietet und das verblüffend wenig bekannt ist. Wir schauen uns die Architektur an, bauen konkrete Sessions für häufige Diagnose-Szenarien, und lernen wie man XE-Daten effizient auswertet — ohne den Server dabei zu belasten.

 

Kapitel 8