SQL Server lernen: T-SQL und Administration

Du willst mit SQL Server mehr machen als nur „SELECT * FROM Tabelle“ und verstehen, was im Hintergrund passiert. Genau darum geht es hier: saubere T-SQL-Abfragen, sinnvolle Indizes, Ausführungspläne lesen, plus die Basics der Administration mit Backups, Wartung und Sicherheit. Und vor allem: Wo hört der Entwicklerjob auf und wo beginnt die Rolle der Datenbankadministratorin oder des Datenbankadministrators?

Rollenklärung: Entwickler, Power-User oder DBA?

Bevor du dich in Details verlierst, hilft eine klare Trennung der Aufgaben. Grob gibt es drei Ebenen:

• T-SQL-Anwender: schreibt Abfragen, Views, Stored Procedures, arbeitet mit Tools wie SSMS oder Azure Data Studio.
• Datenbankentwickler: modelliert Schemas, entwirft Indizes, optimiert Performance, arbeitet eng mit der Anwendungsentwicklung.
• DBA (Database Administrator): installiert und konfiguriert SQL Server, sorgt für Backups, Wartung, Monitoring, Sicherheit und Hochverfügbarkeit.

In vielen kleineren Unternehmen in München und Umgebung macht das eine Person in Personalunion. Fachlich sind es aber verschiedene Skillsets. Für dich heißt das: Du kannst sehr gut produktiv mit SQL Server arbeiten, ohne alles zur Cluster-Konfiguration zu wissen. Aber ein Grundverständnis der DBA-Themen ist Pflicht, sobald du mit produktiven Systemen arbeitest.

T-SQL-Grundlagen, die wirklich sitzen müssen

Ohne solide T-SQL-Basis brauchst du über Performance und Administration kaum nachdenken. Die wichtigsten Bausteine:

Selektieren: Projektion, Filter, Sortierung

• SELECT: immer nur die Spalten holen, die du brauchst, nicht „SELECT *“.
• WHERE: filtern, möglichst sargable, also so, dass Indizes verwendet werden können. Beispiel: „WHERE Bestelldatum >= ‘2024-01-01’“ ist besser als „WHERE YEAR(Bestelldatum) = 2024“.
• ORDER BY: nur dort, wo du wirklich sortieren musst. Sortieren kostet Speicher und Zeit.

Ein schlechtes Muster im Reporting: „SELECT * FROM RiesenTabelle ORDER BY Irgendwas“ und dann in der Anwendung erst filtern. Besser: Filter in die Datenbank, so früh wie möglich.

Aggregationen und Gruppierung

SUM, COUNT, MIN, MAX, AVG in Kombination mit GROUP BY sind Standardwerkzeug. Typische Stolperfallen:

• Spalten in SELECT müssen entweder aggregiert oder in GROUP BY auftauchen.
• HAVING filtert nach der Aggregation, WHERE davor.

Beispiel:

SELECT KundenID, COUNT(*) AS AnzahlBestellungen
FROM Bestellungen
WHERE Bestelldatum >= '2024-01-01'
GROUP BY KundenID
HAVING COUNT(*) >= 5;

WHERE schränkt erst die Bestellungen ein, HAVING filtert dann nach der Anzahl.

Joins richtig verstehen: Datensätze kombinieren

Joins sind die Basis für alle nicht-trivialen Abfragen. Die wichtigsten Typen:

• INNER JOIN: liefert nur Datensätze, die auf beiden Seiten passen.
• LEFT OUTER JOIN: alle Zeilen der linken Tabelle, fehlende rechte Werte werden NULL.
• RIGHT OUTER JOIN: umgekehrte Richtung, praktisch selten nötig.
• FULL OUTER JOIN: alle Zeilen beider Tabellen, mit NULLs, wenn nichts passt.
• CROSS JOIN: kartesisches Produkt, nur in Spezialfällen sinnvoll.

Typische Praxisfälle:

• Kunden mit Bestellungen: INNER JOIN, wenn du nur Kunden mit Bestellungen willst, LEFT JOIN, wenn du alle Kunden sehen möchtest, auch ohne Bestellung.
• „Verwaiste“ Datensätze finden: LEFT JOIN und dann in der WHERE-Klausel „rechteSpalte IS NULL“.

Beispiel für verwaiste Detailzeilen:

SELECT p.*
FROM Positionszeilen p
LEFT JOIN Bestellungen b ON b.BestellID = p.BestellID
WHERE b.BestellID IS NULL;

Hier siehst du alle Positionszeilen, zu denen es keine Bestellung mehr gibt. Das ist wichtig für Datenqualität und Wartungsaufgaben.

Indizes: Wie SQL Server schneller sucht

Indizes sind zentrale Performance-Hebel. Ohne das Prinzip verstanden zu haben, wirst du Ausführungspläne schwer lesen können.

Grundbegriffe:

• Clustered Index: bestimmt die physische Sortierung der Tabelle. Jede Tabelle kann höchstens einen haben. Oft liegt er auf einem Primärschlüssel.
• Nonclustered Index: zusätzliche Sortierung und Zugriffspfade, ähnlich wie ein Inhaltsverzeichnis.
• Indexschlüssel: die Spalten, nach denen sortiert wird.
• Include-Spalten: zusätzliche Spalten, die im Index mit abgelegt werden, um „Index-Only-Scans“ zu ermöglichen.

Praxisregeln:

• Lege Indizes auf häufig genutzte Suchspalten und Join-Spalten. Beispiel: Fremdschlüsselspalten wie KundenID, ProduktID.
• Vermeide zu breite Indizes mit vielen Spalten, sie kosten Speicher und Verarbeitungszeit bei Inserts/Updates.
• Nutze Include-Spalten, wenn eine Abfrage immer dieselben Zusatzspalten mitliest, die aber nicht Teil der Filter- oder Join-Bedingung sind.

Beispiel: Häufige Abfrage der Bestellungen eines Kunden mit Datum und Betrag:

CREATE NONCLUSTERED INDEX IX_Bestellungen_Kunde
ON Bestellungen (KundenID, Bestelldatum)
INCLUDE (Gesamtbetrag);

SQL Server kann so viele Abfragen direkt aus dem Index bedienen, ohne auf die eigentliche Tabelle zugreifen zu müssen.

Ausführungspläne lesen: Was macht die Abfrage wirklich?

Der Ausführungsplan zeigt, wie SQL Server deine Abfrage intern umsetzt. In SQL Server Management Studio (SSMS) kannst du geschätzte oder tatsächliche Ausführungspläne anzeigen.

Wichtige Operatoren und Muster:

• Index Seek: zielgerichteter Zugriff, gut.
• Index Scan oder Table Scan: vollständiges Durchlaufen des Index oder der Tabelle, potenziell teuer.
• Nested Loops, Merge Join, Hash Match: unterschiedliche Join-Algorithmen mit unterschiedlichen Kostenprofilen.
• Sort, Hash Match (Aggregate): können viel Speicher benutzen, auf TempDB ausweichen und so langsam werden.

Darauf solltest du schauen:

• Werden die erwarteten Indizes genutzt oder siehst du viele Table Scans?
• Gibt es „Key Lookups“, also zusätzliche Zugriffe auf die Basistabelle, weil im Index Spalten fehlen?
• Gibt es Warnungen im Plan, zum Beispiel zu impliziten Konvertierungen oder fehlenden Statistiken?

Ein typischer Optimierungsschritt: Du siehst in einer häufig genutzten Abfrage einen Nonclustered Index Scan mit vielen Key Lookups. Durch Hinzufügen einer Include-Spalte kannst du daraus einen reinen Index Seek machen.

Abfrage-Skills vs. DBA-Skills: Wo ist der Schnitt?

Viele Themen wie Indizes und Ausführungspläne liegen im Grenzbereich. Sowohl Entwickler als auch DBAs brauchen hier Wissen. Grob kannst du so trennen:

Abfrage- und Entwicklungs-Skills:

• Saubere T-SQL-Abfragen mit Joins, Aggregationen, Subselects, CTEs.
• Datenmodellierung: Normalisierung, sinnvolle Schlüssel, Relationen.
• Entwurf und Pflege von Indizes auf Tabellen, die deine Anwendung nutzt.
• Performanceanalyse einzelner Abfragen mit Ausführungsplänen.
• Grundverständnis von Transaktionen, Locks und Isolation Levels.

DBA-Skills:

• Installation und Konfiguration von SQL Server Instanzen.
• Backup-Strategien und Restore-Tests.
• Wartungspläne: Indexpflege, Statistiken, Datenbankintegrität.
• Benutzer- und Rechteverwaltung, Verschlüsselung, Auditing.
• Monitoring von Serverressourcen, Langläufer-Abfragen, Blockierungen.
• Hochverfügbarkeit und Disaster Recovery Konzepte.

Für konkrete Termine und passende Kurse rund um SQL Server, T-SQL und Administration schaust du am besten bei cmt.de vorbei.

Backups: Ohne Restore-Test ist jedes Backup wertlos

Backups sind klassische DBA-Aufgabe, aber du solltest das Konzept verstanden haben, wenn du produktiv mit SQL Server arbeitest.

Wichtige Backup-Typen:

• Vollbackup: komplette Datenbank.
• Differenzielles Backup: alle Änderungen seit dem letzten Vollbackup.
• Transaktionslog-Backup: Änderungen seit dem letzten Log-Backup, Voraussetzung für Punkt-in-Zeit-Wiederherstellung im Full-Recovery-Modell.

Kernprinzipien:

• Definiere ein Recovery-Ziel: Wie viele Daten darfst du maximal verlieren (RPO)? Wie lange darf eine Wiederherstellung dauern (RTO)?
• Automatisiere Backups und überwache sie. Ein Job, der heimlich seit Wochen fehlschlägt, hilft niemandem.
• Teste regelmäßig das Restore, idealerweise auf einem separaten Server. Nur so weißt du, ob deine Backups brauchbar sind.

Als Entwickler solltest du wissen, in welchem Recovery-Modell deine Datenbank läuft und wie sich das auf Transaktionslog-Größe und Wiederherstellbarkeit auswirkt.

Wartung: Indizes, Statistiken und Integrität

SQL Server ist kein Selbstläufer. Ohne Wartung wird die Performance mit der Zeit schlechter und das Fehler-Risiko steigt.

Typische Wartungsaufgaben:

• Indexpflege: Fragmentierung reduzieren, insbesondere bei vielen Inserts/Deletes.
• REORGANIZE bei mittlerer Fragmentierung.
• REBUILD bei hoher Fragmentierung, wenn das Wartungsfenster es zulässt.
• Statistiken aktualisieren: SQL Server nutzt Statistiken, um Ausführungspläne zu optimieren. Veraltete Statistiken führen zu schlechten Plänen.
• DBCC CHECKDB: prüft die logische und physische Konsistenz der Datenbank. Sollte regelmäßig laufen, idealerweise mit Monitoring der Ergebnisse.
• Aufräumen von Log-Dateien, TempDB-Überwachung, Entfernen alter Daten oder Archive.

Als Entwickler ist es hilfreich, bei Performanceproblemen zu wissen, ob sie eher an der Abfrage, an fehlenden Indizes oder an mangelnder Wartung liegen.

Sicherheit: Wer darf was, und wie sicher sind die Daten?

Sicherheit ist nicht nur ein Häkchen im Installer, sondern ein durchgehendes Konzept. SQL Server bietet viele Funktionen, die du zumindest im Überblick kennen solltest.

Authentifizierung und Rechte

• Authentifizierung: Windows-Authentifizierung oder SQL Server Logins.
• Prinzip: „Least Privilege“. Benutzer bekommen nur die Rechte, die sie wirklich brauchen.
• Rolle-basierte Rechtevergabe: Eigene Datenbankrollen anlegen, statt alles direkt auf Benutzer zu setzen.

Typische Fehler:

• Verwendung des „sa“-Kontos für Anwendungen.
• Vergabe von db_owner oder sysadmin, „weil es sonst nicht funktioniert“.
• Direkte Tabellenzugriffe statt Nutzung von Stored Procedures, wo sinnvoll.

Verschlüsselung und Datenschutz

• Transparent Data Encryption (TDE): verschlüsselt Daten im Ruhezustand, schützt vor Diebstahl der Datendateien.
• Always Encrypted: schützt besonders sensible Spalten, auch vor Administratoren, die keinen Zugang zu den Schlüsseln haben.
• Verschlüsselung von Verbindungen mit TLS, insbesondere in verteilten Umgebungen oder Cloud-Szenarien.

In regulierten Branchen oder bei personenbezogenen Daten kommst du um ein klares Sicherheitskonzept nicht herum. Auch in vielen Münchner Unternehmen sind technische und organisatorische Maßnahmen hier inzwischen Standard.

Wie du sinnvoll einsteigst und weiterlernst

Wenn du SQL Server lernen willst, hilft eine grobe Lernreihenfolge:

1. T-SQL-Basics: SELECT, WHERE, JOINs, Aggregationen, Subqueries, CTEs.
2. Datenmodellierung: Tabellenentwurf, Schlüssel, Normalisierung.
3. Indizes und Ausführungspläne: wie SQL Server sucht und warum manche Abfragen langsam sind.
4. Transaktionen und Sperren: Verhalten bei Parallelzugriff, Deadlocks vermeiden.
5. Backup und Restore: Konzepte verstehen, einfache Wiederherstellungen durchführen.
6. Wartung und Monitoring: Indexpflege, Statistiken, CHECKDB, einfache Performanceanalyse.
7. Sicherheit: Rollen, Rechte, grundlegende Verschlüsselungsmöglichkeiten.

Parallel dazu lohnt es sich, mit echten Daten zu arbeiten. Beispieldatenbanken wie „AdventureWorks“ oder „WideWorldImporters“ von Microsoft sind ein guter Start. Du kannst sie über die offiziellen Microsoft-Seiten herunterladen und lokal in einer SQL Server Developer Edition oder Express Edition nutzen.

Am Ende zählt nicht, wie viele Features du auswendig kennst, sondern ob du in deiner Umgebung robuste, nachvollziehbare Lösungen baust. Wer die Trennung zwischen Abfrage-Skills und DBA-Skills versteht und beide Seiten zumindest im Kern beherrscht, ist in Projekten mit SQL Server sehr schnell deutlich mehr als „jemand, der ein bisschen SQL kann“.