Datenbanksystem in Betrieb nehmen

Bisher hast du Datenbanken vor allem benutzt: Tabellen angelegt, Daten abgefragt. In diesem Modul stehst du auf der anderen Seite und bist für den Server selbst verantwortlich. Du wählst ein passendes DBMS, installierst es auf Linux oder Windows, passt Konfiguration und Speicher an, richtest Benutzer mit minimalen Rechten ein und sicherst die Verbindung ab. Dazu gehören ein funktionierendes Backup mit getestetem Restore, eine Datenübernahme aus einem Altsystem und eine Betriebsdokumentation, mit der auch jemand anderes den Server übernehmen kann.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Ein passendes DBMS anhand von Anforderungen auswählen

   Kompetenz A

   Du vergleichst Systeme wie MariaDB, PostgreSQL und SQL Server nach Kriterien, die im Betrieb wirklich zählen: Kompatibilität mit der Anwendung, Lizenzkosten, Know-how im Team, Plattform und Support-Dauer. Die Wahl begründest du schriftlich statt nach Bauchgefühl.

   Situation

   Eine Gemeinde mit 40 Mitarbeitenden führt eine neue Software für die Raumreservation ein. Der Hersteller unterstützt MariaDB 10.11 und SQL Server ab 2019. Im Haus laufen bereits zwei Debian-Server.

   Deine Aufgabe

   Erstelle eine Entscheidungsgrundlage mit gewichteten Kriterien und gib eine Empfehlung ab.

   Gutes Ergebnis

   Nutzwertanalyse mit fünf Kriterien. MariaDB auf Debian gewinnt: keine Lizenzkosten (SQL Server Standard wäre lizenzpflichtig, pro Kern mit mindestens 4 Kernen pro VM oder als Server-Lizenz plus CAL, Preise beim Lizenzpartner), vorhandenes Linux-Know-how, LTS-Version mit Support bis 2028.

   DBMSLTS-VersionLizenzmodellNutzwertanalyseHerstellervorgaben
2. 2

   Den Datenbankserver installieren und grundlegend konfigurieren

   Kompetenz A

   Du installierst das DBMS aus offiziellen Paketquellen, legst Datenverzeichnis, Port, Zeichensatz und Zeitzone fest und sorgst dafür, dass der Dienst beim Systemstart sauber hochfährt. Danach entfernst du unsichere Standardeinstellungen wie anonyme Benutzer oder Testdatenbanken.

   Situation

   Für die Raumreservation steht eine VM mit 4 vCPU, 8 GB RAM und einer separaten 100-GB-Datenplatte bereit.

   Deine Aufgabe

   Installiere MariaDB so, dass die Daten auf der separaten Platte liegen und der Server UTF-8 vollständig unterstützt.

   Gutes Ergebnis

   Paket aus dem MariaDB-Repository installiert, datadir auf /srv/mariadb verschoben, character-set-server=utf8mb4, mariadb-secure-installation ausgeführt, Dienst mit systemctl enable aktiviert und Neustart erfolgreich getestet.

   PaketquelleKonfigurationsdatei (my.cnf / postgresql.conf)Datenverzeichnisutf8mb4systemd-Dienst
3. 3

   Benutzer und Rechte nach dem Minimalprinzip einrichten

   Kompetenz B

   Jede Anwendung und jede Person bekommt einen eigenen Login mit genau den Rechten, die sie braucht. Der Root- oder sa-Account wird nie von Anwendungen verwendet. Du kannst Rechte vergeben, prüfen und wieder entziehen.

   Situation

   Die Reservationssoftware braucht Lese- und Schreibzugriff auf ihre Datenbank. Die Leiterin Finanzen möchte monatlich Auswertungen mit Excel ziehen.

   Deine Aufgabe

   Lege passende Konten an und dokumentiere die Rechte.

   Gutes Ergebnis

   Konto 'app_raum'@'10.10.20.15' mit SELECT, INSERT, UPDATE, DELETE auf raum_db.*. Konto 'report_finanzen' mit SELECT auf zwei Views. Kein Konto ausser dem Admin hat GRANT OPTION. Prüfung mit SHOW GRANTS.

   Least PrivilegeGRANT / REVOKERolleHost-EinschränkungView als Zugriffsschicht
4. 4

   Den Netzwerkzugriff einschränken und verschlüsseln

   Kompetenz C

   Der Datenbankport ist nur von den Servern erreichbar, die ihn wirklich brauchen. Verbindungen laufen über TLS, damit Passwörter und Daten nicht im Klartext durchs Netz gehen. Das ist bei Personendaten auch eine Anforderung aus dem revDSG.

   Situation

   Ein Lernender stellt fest, dass Port 3306 aus dem ganzen Büronetz erreichbar ist.

   Deine Aufgabe

   Beschränke den Zugriff auf den Applikationsserver und erzwinge verschlüsselte Verbindungen.

   Gutes Ergebnis

   bind-address auf die interne Server-IP gesetzt, Host-Firewall (nftables) erlaubt 3306 nur von 10.10.20.15, Zertifikat der internen CA eingebunden, require_secure_transport=ON. Test mit nmap aus dem Büronetz: Port gefiltert.

   bind-address / listen_addressesHost-FirewallTLS-Zertifikatpg_hba.confrevDSG Datensicherheit
5. 5

   Datenbanken sichern und einen Restore nachweislich testen

   Kompetenz D

   Du wählst eine Sicherungsmethode, die zur Datenmenge und zum erlaubten Datenverlust passt, automatisierst sie und prüfst regelmässig, ob sich die Sicherung tatsächlich zurückspielen lässt. Ein Backup ohne getesteten Restore zählt nicht.

   Situation

   Die Treuhand-Datenbank ist 12 GB gross. Die Geschäftsleitung akzeptiert höchstens 1 Stunde Datenverlust (RPO) und 4 Stunden Ausfall (RTO).

   Deine Aufgabe

   Plane und teste eine Sicherung, die diese Vorgaben erfüllt.

   Gutes Ergebnis

   Nächtlicher Vollexport mit mariadb-dump --single-transaction plus Binary Logs, die stündlich auf das NAS kopiert werden. Restore-Test auf einer Test-VM dauert 50 Minuten inklusive Einspielen der Binlogs bis 10:00 Uhr. Protokoll mit Datum und Dauer abgelegt.

   logisches vs. physisches BackupBinary Log / WALPoint-in-Time-RecoveryRPO / RTORestore-Test
6. 6

   Bestehende Daten aus einem Altsystem übernehmen

   Kompetenz E

   Du importierst Daten aus CSV-Dateien, Excel oder einer älteren Datenbank, prüfst Zeichensätze, Datentypen und Schlüssel und kontrollierst danach mit Zählungen und Stichproben, dass nichts verloren ging.

   Situation

   Die Raumreservationen der letzten drei Jahre liegen in einer Access-Datei mit rund 9'500 Einträgen.

   Deine Aufgabe

   Übernimm die Daten in die neue MariaDB-Datenbank ohne kaputte Umlaute und ohne Duplikate.

   Gutes Ergebnis

   Export als CSV in UTF-8, Import mit LOAD DATA in eine Staging-Tabelle, Bereinigung per SQL (Datumsformat, doppelte Einträge), Übernahme in die Zieltabelle. Vergleich: 9'512 Quelle, 9'497 Ziel, 15 Duplikate dokumentiert entfernt.

   CSV-ImportStaging-TabelleZeichenkodierungDatenvalidierungMengenabgleich
7. 7

   Leistung überwachen und den Betrieb dokumentieren

   Kompetenz F

   Du beobachtest wichtige Kennzahlen wie Verbindungen, langsame Abfragen und freien Speicher und passt Parameter wie den Buffer Pool gezielt an. Alles Wichtige hältst du in einer Betriebsdokumentation fest, damit eine Kollegin den Server auch ohne dich betreuen kann.

   Situation

   Nutzer:innen melden, dass die Monatsauswertung über zwei Minuten dauert.

   Deine Aufgabe

   Finde die Ursache und dokumentiere die Massnahme.

   Gutes Ergebnis

   Slow Query Log zeigt eine Abfrage ohne Index auf 'datum'. Index ergänzt, Laufzeit sinkt auf 3 Sekunden. innodb_buffer_pool_size von 128 MB auf 4 GB erhöht. Änderungen mit Datum und Begründung in der Betriebsdoku nachgeführt.

   Slow Query LogIndexBuffer Pool / shared_buffersBetriebshandbuchMonitoring-Kennzahl

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Aylin ist im 2. Lehrjahr als Informatikerin Plattformentwicklung bei der Logistik Frei AG in Schlieren, 150 Mitarbeitende. Die Lagerverwaltung läuft noch auf MySQL 5.7 auf einem Windows-Server, für den es keine Updates mehr gibt. Aylin soll mit ihrem Berufsbildner einen neuen Datenbankserver aufbauen und die Daten an einem Wochenende übernehmen.

1. Kapitel 1

   MariaDB oder PostgreSQL?

   Aylin sammelt die Anforderungen: 40 GB Daten, bis zu 60 gleichzeitige Benutzer und Linux als Betriebssystem. In der Dokumentation des Softwareherstellers steht, dass die Lagerverwaltung nur MySQL 8 und MariaDB 10.11 unterstützt. PostgreSQL wäre technisch spannend, fällt aber an diesem Muss-Kriterium heraus. In der Nutzwertanalyse gewinnt MariaDB 10.11 LTS auf Debian 12 vor MySQL 8.4 LTS, vor allem weil MariaDB direkt in den Debian-Paketquellen enthalten ist und mit mariadb-backup ein passendes Backup-Werkzeug mitbringt.

   Ziel 1

2. Kapitel 2

   Ein frischer Server

   Aylin installiert Debian 12 auf einer VM mit 4 vCPU und 16 GB RAM und legt das Datenverzeichnis auf eine eigene Disk mit 100 GB. Nach mariadb-secure-installation setzt sie den Buffer Pool auf 8 GB. Beim ersten Testimport werden aus Umlauten seltsame Zeichen. Sie stellt Server und Client auf utf8mb4 mit passender Sortierung um, importiert neu und prüft Artikelnamen wie Müesli-Riegel stichprobenweise.

   Ziel 2

3. Kapitel 3

   Nur so viel Recht wie nötig

   Die alte Anwendung hatte sich mit root angemeldet. Aylin legt ein Konto für die Lager-App an, das nur vom App-Server aus lesen und schreiben darf, und ein Auswertungskonto mit Lesezugriff auf eine View ohne Einkaufspreise. Der Server lauscht nur noch auf seiner internen Adresse, die Firewall lässt nur App-Server und Admin-Netz durch, und Verbindungen müssen TLS nutzen. Am Montag beschwert sich das Controlling, dass ihr Power-BI-Bericht nicht mehr geht: Sie hatten ebenfalls root benutzt und erhalten nun das Auswertungskonto.

   Ziel 3Ziel 4

4. Kapitel 4

   Der Restore, der zu lange dauerte

   Jede Nacht sichert Aylin die Datenbank mit mariadb-dump, und das Binary Log erlaubt eine Wiederherstellung auf jeden Zeitpunkt der letzten sieben Tage. Beim Restore-Test auf einer Test-VM dauert das Zurückspielen 2 Stunden und 10 Minuten. Vereinbart war aber ein RTO von einer Stunde. Aylin stellt auf ein physisches Backup mit mariabackup um und schafft den Restore danach in 25 Minuten.

   Ziel 5

5. Kapitel 5

   Umzug am Samstag und schnellere Suche

   Am Samstag exportiert Aylin die Daten aus MySQL 5.7, lädt sie zuerst in Staging-Tabellen und vergleicht per Skript die Anzahl Zeilen jeder Tabelle. Drei Lieferungen mit dem ungültigen Datum 0000-00-00 werden abgelehnt, und mit dem Lagerchef legt sie das richtige Datum fest. In der ersten Woche zeigt das Slow Query Log, dass die Suche nach Artikelnummer 4 Sekunden dauert. Mit einem Index sind es noch 30 Millisekunden, und Aylin hält alles im Betriebshandbuch fest.

   Ziel 6Ziel 7

1. 1

   Systeme kennen und auswählen

   ca. 2 Std.

   Du verschaffst dir einen Überblick über die gängigen DBMS und lernst, eine Auswahl nachvollziehbar zu begründen.

   • MariaDB, PostgreSQL und SQL Server Express in einer Tabelle vergleichen: Lizenz, Plattform, Support-Ende, Tools
   • Systemanforderungen einer echten Fachanwendung (z.B. aus dem Lehrbetrieb) heraussuchen
   • Eine kurze Nutzwertanalyse mit 4 bis 5 Kriterien erstellen

   Trainiert Kompetenz A1

   Lernziel1

2. 2

   Installation im Heimlabor

   ca. 4 Std.

   Du setzt eine VM (Debian oder Ubuntu Server, 2 vCPU, 4 GB RAM) in VirtualBox, Hyper-V oder Proxmox auf und installierst dort MariaDB und PostgreSQL nebeneinander.

   • Beide DBMS aus den offiziellen Repositories installieren und Version prüfen
   • Datenverzeichnis auf eine zweite virtuelle Platte verschieben
   • Zeichensatz, Zeitzone und Port in der Konfigurationsdatei setzen und Dienst neu starten

   Trainiert Kompetenz A1A2

   Lernziel2

3. 3

   Konten, Rechte und Netzwerk absichern

   ca. 4 Std.

   Du richtest Anwendungs- und Personenkonten ein und machst den Server nur für berechtigte Hosts erreichbar.

   • Drei Konten mit unterschiedlichen Rechten anlegen und mit SHOW GRANTS bzw. \du kontrollieren
   • Port mit nftables oder ufw auf eine IP einschränken und mit nmap von aussen testen
   • Ein Zertifikat erstellen, TLS aktivieren und im Client prüfen, ob die Verbindung verschlüsselt ist

   Trainiert Kompetenz B1B2C1C2

   Lernziel34

4. 4

   Backup und Restore üben

   ca. 4 Std.

   Du sicherst eine Beispieldatenbank auf verschiedene Arten und spielst sie unter Zeitdruck wieder ein.

   • Dump mit mariadb-dump und pg_dump erstellen, per cron nächtlich automatisieren
   • Binary Logs aktivieren und einen Point-in-Time-Restore auf eine bestimmte Uhrzeit durchführen
   • Restore-Zeit messen und in einem kurzen Testprotokoll festhalten

   Trainiert Kompetenz D1D2

   Lernziel5

5. 5

   Datenübernahme und Tuning

   ca. 4 Std.

   Du importierst einen grösseren Datensatz, prüfst die Qualität und optimierst danach die Leistung.

   • Einen offenen Datensatz (z.B. Gemeindeverzeichnis des BFS als CSV) in eine Staging-Tabelle laden und bereinigen
   • Slow Query Log aktivieren, eine langsame Abfrage finden und mit einem Index beschleunigen
   • Buffer Pool an den verfügbaren RAM anpassen und den Effekt messen

   Trainiert Kompetenz E1E2F1F2

   Lernziel67

6. 6

   Gesamtauftrag mit Dokumentation

   ca. 4 Std.

   Du spielst einen kompletten Auftrag durch, wie er im Kompetenznachweis vorkommen kann: vom leeren Server bis zur Übergabe.

   • Server installieren, absichern, Daten übernehmen und Backup einrichten
   • Betriebsdokumentation mit Zugangsdaten-Verweis, Ports, Konten, Backup-Plan und Restore-Anleitung schreiben
   • Die Doku einer Kollegin geben und prüfen, ob sie damit einen Restore schafft

   Trainiert Kompetenz A3B3D3F3

   Lernziel2357

DBMS

Datenbankmanagementsystem: Software, die Daten speichert, verwaltet und Abfragen ausführt, z.B. PostgreSQL.

Instanz

Ein laufender Datenbankserver-Prozess mit eigener Konfiguration und eigenen Datenbanken.

Least Privilege

Prinzip, nach dem jedes Konto nur die minimal nötigen Rechte erhält.

Binary Log / WAL

Fortlaufendes Protokoll aller Änderungen, Grundlage für Replikation und Point-in-Time-Recovery.

Point-in-Time-Recovery

Wiederherstellung einer Datenbank auf einen genauen Zeitpunkt, z.B. kurz vor einem versehentlichen DELETE.

Buffer Pool

Cache im Arbeitsspeicher für Tabellen- und Indexdaten, entscheidend für die Leistung.

Staging-Tabelle

Zwischentabelle, in die Daten zuerst roh importiert und dann bereinigt werden.

pg_hba.conf

Datei in PostgreSQL, die regelt, wer sich von wo mit welcher Methode anmelden darf.

Passende Module