Database Administrator Vorstellungsgespräch: Fragen & Antworten (mit Musterantworten)

Musterantwort

Ich definiere die Strategie anhand der Geschäftsvorgaben für RPO und RTO und kombiniere Vollbackups mit differenziellen und Transaktionslog-Sicherungen. Entscheidend ist, dass ich Wiederherstellungen regelmäßig in einer Testumgebung übe, denn ein nie getestetes Backup ist kein Backup. Ich überwache den Erfolg der Jobs automatisiert und lagere Kopien an einem getrennten Standort. In meinem letzten Projekt konnten wir so eine versehentlich gelöschte Tabelle innerhalb von 20 Minuten punktgenau wiederherstellen.

Musterantwort

Ich verschaffe mir zuerst über Monitoring und Wait-Statistiken einen Überblick, ob CPU, I/O, Sperren oder einzelne Abfragen die Ursache sind. Anschließend identifiziere ich die teuersten Queries über den Ausführungsplan und prüfe fehlende oder fragmentierte Indizes. Ich vermeide vorschnelle Änderungen und messe die Wirkung jeder Optimierung. So habe ich einmal eine Reporting-Abfrage durch einen passenden Index von Minuten auf Sekunden gebracht.

Musterantwort

Ich plane Wartungsfenster in verkehrsarmen Zeiten und nutze, wo möglich, Online-Operationen für Indexpflege und Patches. Für hochkritische Systeme setze ich auf Hochverfügbarkeitslösungen wie Always On oder Replikation, sodass ich Wartung an passiven Knoten durchführen kann. Änderungen kommuniziere ich frühzeitig und dokumentiere einen Rollback-Plan. So halte ich die Ausfallzeit minimal, ohne notwendige Pflege zu vernachlässigen.

Musterantwort

Ich vergebe Berechtigungen nach dem Least-Privilege-Prinzip und nutze Rollen statt Einzelrechte für bessere Nachvollziehbarkeit. Sensible Daten verschlüssele ich at rest und in transit und führe Auditing für kritische Zugriffe ein. Regelmäßig prüfe ich Berechtigungen auf veraltete Konten. Bei personenbezogenen Daten achte ich auf DSGVO-Anforderungen wie Aufbewahrungsfristen und Löschkonzepte.

Musterantwort

Mich reizt, dass Sie große, transaktionsintensive Systeme betreiben, bei denen Performance und Verfügbarkeit unmittelbar geschäftskritisch sind. Ihre Ausschreibung erwähnt eine Migration in Richtung Cloud-Datenbanken, ein Bereich, in dem ich mich gezielt weiterentwickeln möchte. Ich übernehme gern Verantwortung für Systeme, deren Stabilität direkten Einfluss auf das Geschäft hat. Außerdem passt Ihr Datenbank-Stack gut zu meiner bisherigen Erfahrung.

ACID steht für Atomicity, Consistency, Isolation und Durability und beschreibt die Garantien zuverlässiger Transaktionen. Atomarität sichert, dass eine Transaktion ganz oder gar nicht ausgeführt wird, Konsistenz erhält gültige Zustände, Isolation trennt parallele Transaktionen und Dauerhaftigkeit garantiert, dass bestätigte Änderungen auch nach einem Absturz erhalten bleiben. Diese Eigenschaften sind das Fundament transaktionaler Datenbanken.

Ein Clustered Index bestimmt die physische Sortierreihenfolge der Tabellendaten, weshalb es pro Tabelle nur einen geben kann. Ein Non-Clustered Index ist eine separate Struktur mit Zeigern auf die Datenzeilen, und davon sind mehrere möglich. Clustered Indizes eignen sich gut für Bereichsabfragen, Non-Clustered für gezielte Lookups auf bestimmte Spalten.

Normalisierung organisiert Daten in Tabellen, um Redundanz und Anomalien zu vermeiden, üblicherweise bis zur dritten Normalform. Denormalisierung führt gezielt Redundanz wieder ein, um leseintensive Abfragen zu beschleunigen, etwa in Reporting- oder Data-Warehouse-Szenarien. Die Entscheidung hängt vom Verhältnis zwischen Lese- und Schreiblast ab.

Ich achte auf teure Operatoren wie Table Scans oder Key Lookups, die oft auf fehlende oder unpassende Indizes hindeuten. Hohe geschätzte gegenüber tatsächlichen Zeilen weisen auf veraltete Statistiken hin. Anhand dieser Hinweise ergänze ich Indizes, schreibe Abfragen um oder aktualisiere Statistiken und messe danach erneut.

Replikation kopiert Daten zwischen Datenbanken, oft für Lastverteilung von Lesezugriffen oder geografische Verteilung, und kann asynchron Verzögerung haben. Clustering bündelt mehrere Knoten zu einem hochverfügbaren System mit gemeinsamem oder gespiegeltem Speicher und automatischem Failover. Replikation zielt eher auf Skalierung und Verteilung, Clustering auf Verfügbarkeit.

Ein fehlerhaftes Deployment löschte versehentlich Datensätze in einer Produktionstabelle (Situation). Ich sollte den Verlust ohne längeren Ausfall korrigieren (Task). Ich habe über eine Point-in-Time-Recovery aus den Transaktionslogs den Zustand kurz vor dem Fehler wiederhergestellt und die betroffenen Daten gezielt zurückgespielt (Action). Die Daten waren binnen 25 Minuten konsistent wieder verfügbar, und wir führten danach eine Schutzregel gegen ungesicherte Massenlöschungen ein (Result).

Eine zentrale Suchabfrage führte zu täglichen Beschwerden über Wartezeiten (Situation). Meine Aufgabe war, die Antwortzeit deutlich zu senken (Task). Ich habe den Ausführungsplan analysiert, einen abdeckenden Index erstellt und eine ineffiziente Unterabfrage umgeschrieben (Action). Die Antwortzeit sank von rund acht Sekunden auf unter eine Sekunde, und die Beschwerden hörten auf (Result).

Entwickler wollten direkten Schreibzugriff auf eine Produktionsdatenbank für schnelle Fixes (Situation). Ich sollte die Datenintegrität schützen, ohne ihre Arbeit zu blockieren (Task). Ich habe das Risiko erklärt und stattdessen einen kontrollierten Prozess mit Migrationsskripten und Review eingeführt (Action). Die Entwickler behielten ihr Tempo, während die Produktionsdaten geschützt blieben (Result).

Wir mussten eine alternde Datenbankversion auf eine aktuelle, unterstützte Version migrieren (Situation). Ich sollte die Migration mit minimaler Ausfallzeit umsetzen (Task). Ich habe die Migration im Testsystem mehrfach geprobt, Kompatibilitätsprobleme behoben und den Cutover in ein Wochenendfenster mit Rollback-Plan gelegt (Action). Die Umstellung gelang innerhalb des Fensters ohne Datenverlust und ohne Eskalationen am Montag (Result).