Interviewfragen für Datenbankadministratoren, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Beantworte jede Frage in den Begriffen des Produkts, das die Anzeige nennt, und füge einen echten Fall an: die Datenbank, ihre Größe, was ausgefallen ist, was du getan hast und wie lange es gedauert hat. DBA-Interviewer bitten oft, eine Nacht in Rufbereitschaft durchzusprechen; such dir also eine aus und kenne ihren zeitlichen Ablauf.

Was ein Datenbankadministrator können muss

• Wiederherstellung: Backups, Restores, Point-in-Time-Recovery und die Recovery-Ziele, die das Geschäft vereinbart hat.
• Verfügbarkeit: Replikation, Standby-Datenbanken, Failover und geplante Wartung mit wenig Ausfallzeit.
• Performance: SQLJede Abfrage lesen und tunen: Joins, Indizes, Ausführungspläne, Transaktionen und Sperren, im Dialekt deines Produkts., Ausführungspläne, Indizes, Statistiken, Sperren und Arbeitsspeicher und Storage des Servers.
• Sicherheit und Changes: Least Privilege, Verschlüsselung, Audit Trails, Patches und Upgrades über einen Change-ProzessIncidents, Changes und Problems in großen IT-Abteilungen; eine Änderung an einer Datenbank läuft meist durch einen Change-Prozess..
• Produkte und Plattformen: mindestens eines von PostgreSQLIn Produktion betreiben: Replikation, Backups mit Point-in-Time-Recovery, Vacuum, Upgrades und Extensions., Oracle Database, Microsoft SQL Server oder MySQL in der Tiefe, auf LinuxDie meisten Datenbanken laufen unter Linux: Speicher, Arbeitsspeicher, Dateisysteme, Dienste und die Logs, die einen Absturz erklären. oder Windows, im eigenen Rechenzentrum oder in der Cloud.

Backup, Wiederherstellung und Verfügbarkeit

Wie entwirfst du Backups für eine Datenbank, und woher weißt du, dass eine Wiederherstellung funktioniert?

Worauf sie achten: dass du vom Wiederherstellungsbedarf des Geschäfts ausgehst und Restores testest.

Kurze Antwort: „Ich beginne mit zwei Zahlen, die das Geschäft vereinbart: dem Recovery Point Objective, wie viele Daten es verlieren darf, und dem Recovery Time Objective, wie lange es ausfallen darf. Danach wähle ich volle und inkrementelle Backups plus die Transaktionslogs, halte Kopien an einem anderen Ort und eine, die sich nicht ändern lässt, und stelle nach Plan ein echtes Backup wieder her, um zu beweisen, dass es funktioniert, und um zu messen, wie lange es dauert.“

Die ausführliche Antwort: Ein Backup, das nie jemand wiederhergestellt hat, ist eine Hoffnung, kein Backup. Jedes Produkt hat eigene Werkzeuge, etwa RMAN für Oracle Database, native Backups für SQL Server oder Base Backups mit archivierten Logs für PostgreSQL, aber der Plan ist derselbe: eine Kopie fern vom Server, eine, die Ransomware nicht verschlüsseln kann, ein schriftliches Verfahren für die Wiederherstellung und ein Test, der die Daten prüft, nicht nur, ob der Restore durchgelaufen ist. Überwache Backup-Jobs mit Alarmen, denn ein stiller Fehler wird an dem Tag entdeckt, an dem er am meisten schmerzt.

Schwache Antwort: „Wir sichern jede Nacht, also sind wir sicher.“ Nachfrage: „Das Geschäft sagt, es darf höchstens fünf Minuten verlieren.“ Erklär, warum nächtliche Backups das nicht schaffen und wie Log-Backups oder Replikation es können.

Jemand hat vor einer Stunde Zeilen aus einer wichtigen Tabelle gelöscht. Wie stellst du sie wieder her?

Worauf sie achten: eine ruhige, sorgfältige Wiederherstellung, die nichts schlimmer macht.

Kurze Antwort: „Zuerst stoppe ich den Schaden und finde den genauen Zeitpunkt des Löschens aus den Logs oder der Anwendung. Dann stelle ich das letzte Backup auf einem getrennten Server wieder her und spiele die Transaktionslogs bis kurz vor diesen Moment nach, eine Point-in-Time-Recovery. Die fehlenden Zeilen kopiere ich zurück in die Produktion, nachdem ich sie mit dem Dateneigentümer geprüft habe.“

Die ausführliche Antwort: Die ganze Produktionsdatenbank auf einen früheren Zeitpunkt zurückzusetzen, würde auch eine Stunde guter Arbeit rückgängig machen; eine Wiederherstellung daneben ist also meist richtig. Manche Produkte bieten schnellere Wege für frische Fehler, etwa Flashback-Funktionen oder ein verzögertes Replikat, das eine Stunde hinterherläuft. Frag danach, warum das Löschen möglich war: Hätte dieses Konto das Recht haben sollen, hätte die Änderung durch ein Review gehen sollen?

Schwache Antwort: „Ich spiele das Backup von letzter Nacht über die Produktion.“ Nachfrage: „Die Tabelle ist zwei Terabyte groß.“ Sprich darüber, nur diese Tabelle oder dieses Schema wiederherzustellen, wo das Produkt es erlaubt, und wie lange es dauert.

Wie funktioniert Replikation, und wie planst du Hochverfügbarkeit und Failover?

Worauf sie achten: dass du weißt, was jeder Entwurf verliert und wie lange die Umschaltung dauert.

Kurze Antwort: „Replikation schickt die Änderungen des Primärservers an ein oder mehrere Replikate. Synchrone Replikation wartet, bis ein Replikat jede Änderung bestätigt, damit beim Failover nichts Committetes verloren geht, auf Kosten der Geschwindigkeit; asynchrone Replikation ist schneller, kann aber die letzten Änderungen verlieren. Hochverfügbarkeit ergänzt ein automatisches Failover auf ein Replikat, mit einem Mechanismus, der verhindert, dass zwei Server zugleich als Primärserver arbeiten.“

Die ausführliche Antwort: Jedes Produkt hat eigene Namen: Always-On-Verfügbarkeitsgruppen in SQL Server, Data Guard in Oracle Database, Streaming-Replikation mit einem Failover-Manager in PostgreSQL, Group Replication in MySQL, Replica Sets in MongoDB. Die Fragen sind dieselben: wie viele Daten verloren gehen können, wie schnell die Umschaltung ist, wie Anwendungen den neuen Primärserver finden und wie der alte wieder dazukommt. Replikation ist kein Backup, denn ein Löschen wird sofort auf jedes Replikat kopiert. Teste das Failover regelmäßig, in der Arbeitszeit, bevor du es nachts brauchst.

Schwache Antwort: „Wir haben ein Replikat, also brauchen wir keine Backups.“ Nachfrage: „Das Netz zwischen zwei Standorten bricht auseinander.“ Erklär, wie ein Quorum oder ein Witness verhindert, dass beide Seiten Schreibzugriffe annehmen.

Performance, Indizes und Sperren

Eine Abfrage, die eine Sekunde gedauert hat, braucht jetzt eine Minute. Wie findest du heraus, warum sie langsam ist?

Worauf sie achten: eine Methode, die bei Belegen beginnt, nicht bei einem Index auf gut Glück.

Kurze Antwort: „Ich finde die Abfrage im Monitoring oder im Slow Query Log und lese dann ihren Ausführungsplan, die Schritte, die die Datenbank für die Antwort gewählt hat. Ich vergleiche ihn mit dem alten Plan, wenn ich ihn habe: Ein geänderter Plan heißt oft veraltete Statistiken, gewachsene Daten oder ein anderer Parameter. Dann prüfe ich die Wartezeiten auf dem Server: Sperren, Storage, Arbeitsspeicher oder CPU.“

Die ausführliche Antwort: Ein Ausführungsplan zeigt, wie Tabellen gelesen, verknüpft und sortiert werden und wie viele Zeilen die Datenbank erwartet und wie viele sie gefunden hat; eine große Lücke deutet auf die Statistiken. Jedes Produkt hat Werkzeuge dafür, etwa den Query Store in SQL Server, die Performance-Berichte von Oracle Database oder die Statistik-Views von PostgreSQL. Behebe die Ursache: Statistiken auffrischen, einen Index ergänzen oder ändern, die Abfrage mit den Entwicklern umschreiben oder eine Zeit lang einen bekannt guten Plan festschreiben. Miss nach der Änderung, mit echten Datenmengen.

Schwache Antwort: „Ich starte die Datenbank neu.“ Nachfrage: „Die Abfrage ist im Test schnell und in der Produktion langsam.“ Vergleiche Datenmengen, Statistiken, Parameter und die Pläne in beiden.

Wie entscheidest du, welche Indizes du anlegst und welche du entfernst?

Worauf sie achten: dass du weißt, dass ein Index Kosten hat und nicht nur Nutzen.

Kurze Antwort: „Ich lege einen Index für häufige, wichtige Abfragen an, die auf Spalten mit vielen verschiedenen Werten filtern oder verknüpfen, und prüfe, ob der Plan ihn nutzt. Jeder Index bremst Schreibzugriffe und braucht Platz; deshalb suche ich Indizes, die nie genutzt werden oder andere doppeln, und entferne sie, nachdem ich sie einen ganzen Geschäftszyklus lang beobachtet habe, den Monatsabschluss eingeschlossen.“

Die ausführliche Antwort: Die Reihenfolge der Spalten in einem zusammengesetzten Index zählt: Er hilft Abfragen, die seine ersten Spalten nutzen. Covering Indexes können eine Abfrage beantworten, ohne die Tabelle zu lesen. Zu viele Indizes auf einer viel genutzten Tabelle können Inserts und Updates zum Engpass machen. Halte fest, warum es jeden Index gibt, und stimme neue mit den Entwicklern ab, denen die Abfragen gehören.

Schwache Antwort: „Ich indiziere sicherheitshalber jede Spalte.“ Nachfrage: „Inserts sind langsam geworden.“ Prüf, wie viele Indizes die Tabelle trägt und welche genutzt werden.

Nutzer sagen, die Anwendung hängt, und du siehst blockierende Sperren und Deadlocks. Was tust du?

Worauf sie achten: dass du Transaktionen, Sperren und Isolation verstehst und Ursachen mit den Entwicklern behebst.

Kurze Antwort: „Ich finde die Session am Anfang der Blockierkette und was sie gerade tut, oft eine lange Transaktion, die nie committet wurde. Deadlocks löst die Datenbank selbst, indem sie eine Transaktion abbricht; ich lese also den Deadlock-Bericht, um zu sehen, welche Objekte und Anweisungen beteiligt waren, und arbeite mit den Entwicklern daran, die Reihenfolge der Zugriffe zu ändern oder die Transaktionen zu verkürzen.“

Die ausführliche Antwort: Eine Transaktion hält ihre Sperren, bis sie endet; lange Transaktionen, Benutzereingaben innerhalb einer Transaktion oder fehlende Indizes, durch die Updates ganze Tabellen durchsuchen, verbreiten also Blockaden. Das Isolation Level entscheidet, worauf Leser und Schreiber warten; manche Produkte bieten Zeilenversionen, damit Leser Schreiber nicht blockieren. Eine Session abzuschießen beendet das Symptom; die Lösung liegt in der Anwendung oder in den Indizes.

Schwache Antwort: „Ich beende die blockierende Session und mache weiter.“ Nachfrage: „Es passiert jeden Tag um neun.“ Schau auf die Batch-Jobs und Berichte, die dann laufen, und die Größe ihrer Transaktionen.

Upgrades, Sicherheit und Monitoring

Wie planst du ein Upgrade auf eine neue Hauptversion und die monatlichen Patches mit wenig Ausfallzeit?

Worauf sie achten: sorgfältiges Change Management und einen Weg zurück.

Kurze Antwort: „Ich lese die Release Notes auf Änderungen, die uns betreffen, teste das Upgrade auf einer Kopie der Produktion mit den Tests der Anwendung und einer Performance-Prüfung und schreibe einen Plan Schritt für Schritt mit einem Rollback-Punkt. Patches gehen zuerst in den Test, dann auf die Replikate, dann nach einem Failover auf den Primärserver, damit die Ausfallzeit kurz bleibt.“

Die ausführliche Antwort: Jedes Produkt hat ein Datum, an dem der Support endet, und wer darüber hinaus weiterläuft, bekommt keine Sicherheitskorrekturen mehr. Für das Upgrade selbst gibt es mehrere Wege, etwa das Upgrade an Ort und Stelle oder einen neuen Server aufbauen, die Daten per Replikation hinüberkopieren und dann umschalten. Plane die Änderung über den Change-Prozess mit den Verantwortlichen der Anwendungen, einem Zeitfenster und einem benannten Go/No-Go-Punkt. Prüf die Abfragepläne nach dem Upgrade, denn ein neuer Optimierer kann sie ändern.

Schwache Antwort: „Wir bleiben auf der alten Version, sie funktioniert.“ Nachfrage: „Die Version fällt in drei Monaten aus dem Support.“ Zeig den Plan, den Testaufwand und das Risiko des Wartens.

Wie sicherst du eine Datenbank ab: Konten, Verschlüsselung und Audit?

Worauf sie achten: Least Privilege und Nachweise, die ein Auditor lesen kann.

Kurze Antwort: „Jede Person und jede Anwendung bekommt ein eigenes Konto mit nur den Rechten, die sie braucht, Least Privilege, über Rollen; keine geteilten Admin-Passwörter. Die Daten sind auf der Platte und im Netz verschlüsselt, die Backups auch. Anmeldungen und Änderungen an sensiblen Daten und an Rechten landen in einem Audit Trail, den DBAs nicht unbemerkt ändern können, und die Zugriffe werden regelmäßig geprüft.“

Die ausführliche Antwort: Halte Admin-Zugriffe persönlich, protokolliert und, wo möglich, nur für die Zeit vergeben, in der sie gebraucht werden. Maskiere oder entferne personenbezogene Daten in Testkopien. Patche schnell, wenn eine Sicherheitslücke veröffentlicht wird. In der EU setzt die DSGVO, das Datenschutzgesetz der EU, Regeln für personenbezogene Daten, und viele Firmen werden nach ISO 27001Sicherheitskontrollen, die Auditoren prüfen: Zugriffsreviews, Verschlüsselung, Backups, Logging und dokumentierte Verfahren. auditiert; andere Länder haben eigene Regeln, frag also, was dort gilt, wo die Daten liegen.

Schwache Antwort: „Das Konto der Anwendung hat alle Rechte, das ist einfacher.“ Nachfrage: „Ein Auditor fragt, wer letzten Monat eine Gehaltstabelle geändert hat.“ Zeig, wo der Audit Trail das beantwortet.

Was überwachst du an einer Datenbank, und was sollte dich nachts wecken?

Worauf sie achten: Alarme, die auf echtes Risiko zeigen, nicht auf Rauschen.

Kurze Antwort: „Ich beobachte Verfügbarkeit, Replikationsverzug, fehlgeschlagene Backups, freien Speicher und sein Wachstum, Verbindungen, lange Transaktionen und Sperren und die Antwortzeit wichtiger Abfragen. Nur was Daten oder Dienst bedroht, weckt jemanden: ein ausgefallener Primärserver, eine abgerissene Replikation, ein Speicher kurz vor dem Volllaufen, fehlschlagende Backups. Der Rest kommt in eine tägliche Durchsicht.“

Die ausführliche Antwort: Sammle Metriken in einem zentralen System, etwa Prometheus mit GrafanaDatenbankmetriken sammeln und bei dem alarmieren, was zählt: Replikationsverzug, Verbindungen, Speicher, langsame Abfragen. oder den eigenen Werkzeugen des Produkts, und bewahre die Historie auf, damit Trends sichtbar werden, bevor Grenzen erreicht sind. Jeder Alarm braucht ein Runbook: was er bedeutet und die ersten Schritte. Geh die Alarme nach jedem Incident durch und entferne die, auf die niemand reagiert hat.

Schwache Antwort: „Wir alarmieren bei allem über achtzig Prozent.“ Nachfrage: „Der DBA in Rufbereitschaft bekommt dreißig Alarme pro Nacht.“ Sortiere sie danach, ob gehandelt werden muss, und justiere den Rest nach oder entferne ihn.

Kapazität, Cloud, Automatisierung und Incidents

Wie planst du die Kapazität für das nächste Jahr?

Worauf sie achten: dass du aus Daten prognostizierst und mit dem Geschäft sprichst.

Kurze Antwort: „Ich nehme das Wachstum von Daten, Transaktionen und Spitzenlast im letzten Jahr aus dem Monitoring, ergänze, was das Geschäft plant, etwa ein neues Land oder Produkt, und rechne Speicher, Arbeitsspeicher und CPU mit einem Puffer hoch. Ich prüfe das jedes Quartal, denn Pläne ändern sich.“

Die ausführliche Antwort: Der Speicher ist meist die erste Grenze, dann der Arbeitsspeicher für die Daten, die ständig gebraucht werden, dann die CPU in Spitzen wie dem Monatsabschluss. Alte Daten zu archivieren und ungenutzte Indizes zu entfernen, schafft Platz. In der Cloud wird Kapazität stundenweise gekauft; der Plan wird also auch ein Kostenplan: Instanzen und Speicher richtig bemessen und Kapazität für die gleichmäßige Grundlast reservieren.

Schwache Antwort: „Wir kaufen mehr Platten, wenn es voll ist.“ Nachfrage: „Der Speicher ist doppelt so schnell gewachsen wie geplant.“ Finde heraus, welche Tabellen gewachsen sind und warum, und vereinbare Aufbewahrungsfristen mit den Dateneigentümern.

Wie würdest du eine Datenbank in die Cloud oder auf ein anderes Produkt migrieren?

Worauf sie achten: einen Migrationsplan mit wenig Risiko und einem Rollback.

Kurze Antwort: „Ich liste auf, was die Datenbank nutzt und das Ziel vielleicht nicht hat, teste die Umwandlung und die Anwendung auf einer Kopie und bewege die Daten mit laufender Replikation, damit die letzte Umschaltung Minuten dauert. Vor der Umschaltung vergleiche ich Zeilenzahlen und Prüfsummen, und ich halte das alte System für eine vereinbarte Zeit bereit, um wieder zu übernehmen.“

Die ausführliche Antwort: Ein Umzug auf verwaltete Dienste wie Azure SQL Database, AWS RDS oder Cloud SQL nimmt dem DBA das Patchen und einen Teil der Backups ab, bringt aber Grenzen bei Einstellungen und Zugriff; lies sie zuerst. Ein Wechsel des Produkts, etwa von Oracle Database zu PostgreSQL, ändert auch Stored Procedures, Datentypen und Werkzeuge und braucht die Entwickler. Plane Performance-Tests ein, denn der Speicher der Cloud verhält sich anders.

Schwache Antwort: „Wir exportieren am Freitag alles und importieren es am Samstag.“ Nachfrage: „Der Export dauert dreißig Stunden.“ Erklär laufende Replikation und eine kurze Umschaltung.

Was automatisierst du, und wie?

Worauf sie achten: dass du wiederkehrende Arbeit als Code behandelst, geprüft und getestet.

Kurze Antwort: „Alles, was ich öfter als zweimal tue: Server aufbauen, Einstellungen, Backups und ihre Prüfungen, Patchen, Benutzerrechte, Restore-Tests und Berichte. Ich schreibe es als Skripte oder Konfiguration in Git, mit AnsibleDatenbankserver jedes Mal gleich konfigurieren, aus einem geprüften Playbook. oder TerraformDatenbankserver und verwaltete Instanzen als Code anlegen, damit Umgebungen gleich sind und Änderungen geprüft werden., lasse es durch ein Review gehen und teste es zuerst außerhalb der Produktion.“

Die ausführliche Antwort: Automatisierung macht viele Datenbanken gleich, und das macht sie leichter zu betreiben und zu auditieren. Datenbankänderungen können über Migrationswerkzeuge in der Pipeline mit der Anwendung mitreisen, damit Schemaänderungen wie Code geprüft werden. Skripte in PythonAutomatisierung und Werkzeuge: Migrationen, Berichte, Prüfungen gegen viele Server, Verbindungsstücke für die Pipeline., BashSkripte für Backups, Prüfungen und Routinejobs, so geschrieben, dass ein anderer DBA sie lesen und neu starten kann. oder PowerShellAufgaben in SQL Server und Windows automatisieren: Backups, Berechtigungen, Prüfungen über viele Instanzen. füllen die Lücken. Lass bei riskanten Schritten, etwa dem Löschen von Daten, einen Menschen entscheiden.

Schwache Antwort: „Ich kenne die Schritte auswendig.“ Nachfrage: „Du betreust hundert Instanzen.“ Zeig, wie Einstellungen und Patches auf allen gleich bleiben.

Die wichtigste Produktionsdatenbank ist ausgefallen. Führ uns durch den Incident.

Worauf sie achten: ruhige Ordnung: Dienst wiederherstellen, informieren, dann die Ursache finden.

Kurze Antwort: „Ich bestätige die Auswirkung, eröffne einen Incident und sage dem Incident Manager, was ich weiß. Zuerst stelle ich den Dienst wieder her, per Failover auf ein Replikat oder mit einem Neustart, wenn er sicher ist, und bewahre dabei die Logs für später auf. Ich gebe Updates zu festen Zeiten. Wenn der Dienst wieder läuft, finde ich die eigentliche Ursache ohne Schuldzuweisung und schreibe die Änderungen auf, die es beim nächsten Mal verhindern.“

Die ausführliche Antwort: Prüf vor dem Handeln: Ist es die Datenbank, der Server, der Speicher, das Netz oder die Anwendung? Ein Failover, das Daten verliert, kann schlimmer sein als ein paar Minuten mehr Ausfall; kenne also die Recovery-Ziele und wer entscheidet. Führ nebenbei eine Zeitleiste. Teste danach die Lösung, aktualisiere das Runbook und ergänze den fehlenden Alarm.

Schwache Antwort: „Ich probiere so lange etwas aus, bis sie wieder läuft.“ Nachfrage: „Das Failover hat funktioniert, aber die Anwendung kann sich immer noch nicht verbinden.“ Prüf, wie die Anwendung den Primärserver findet: Namen, Connection Strings, Caches.

Lead-Datenbankadministrator, Datenarchitekt und Head of Database Engineering

Diese Fragen kommen bei Rollen als Senior-Datenbankadministrator, Lead-Datenbankadministrator, Datenarchitekt und Head of Database Engineering, in denen die Arbeit viele Datenbanken, Teams und Produkte umfasst.

Wie setzt du als Lead-DBA oder Head of Database Engineering Standards über viele Teams und Produkte hinweg?

Worauf sie achten: dass du viele Datenbanken sicher und einheitlich machen kannst, ohne die Teams zu bremsen.

Kurze Antwort: „Ich vereinbare eine kurze Liste unterstützter Produkte und Versionen, Standard-Builds, bei denen Backups, Monitoring und Sicherheit vom ersten Tag an eingeschaltet sind, und Service Levels nach Wichtigkeit. Teams bekommen Datenbanken über Automatisierung, nicht über Tickets. Ich messe bestandene Restore-Tests, Patch-Stand und Incidents und bespreche sie mit der Engineering-Leitung.“

Die ausführliche Antwort: Weniger Produkte bedeuten tiefere Kenntnisse und weniger Risiko, aber jedes Team hat seine Gründe; entscheide also mit ihnen und schreib die Gründe auf. Ein Plattformteam, das Datenbanken innerhalb der Firma als Dienst anbietet, skaliert besser als ein DBA für jedes Team. Ein Datenarchitekt entwirft, wie Daten modelliert werden und zwischen Systemen fließen; ein Head of Database Engineering stellt außerdem ein, plant die Rufbereitschaft und verantwortet das Budget für Lizenzen und Cloud-Kosten.

Schwache Antwort: „Jedes Team kann jede Datenbank wählen.“ Nachfrage: „Die Lizenzkosten sind in einem Jahr um die Hälfte gestiegen.“ Zeig, wie du die Ursache finden würdest und was ein Produktstandard sparen könnte.

Dein Lebenslauf für diese Fragen

Jede Datenbank in deinem Lebenslauf lädt zur Frage ein: wie groß, wie kritisch, was ist schiefgegangen, was hast du geändert. Schreib Zeilen, die diese Geschichten eröffnen, jede unter der Stelle, an der es passiert ist:

Bewerte deinen Lebenslauf vor dem Vorstellungsgespräch an einem echten DBA-Job; die Lücken, die er zeigt, sind die Geschichten, die du zuerst vorbereiten solltest.