Wem man eine produktive Datenbank anvertraut
Eine Sicherung zählt erst, wenn du sie zurückgespielt hast, und ein Index hilft erst, wenn der Ausführungsplan ihn auch benutzt. Alles andere ist Hoffnung.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Datenbank fällt niemandem auf, bis sie ausfällt
Datenbanken sind die einzige Schicht im Haus, in der ein Fehler nicht nur eine Störung ist, sondern ein Verlust. Ein abgestürzter Webserver kommt neu hoch, eine gelöschte Tabelle nicht. Deshalb ist die Rolle im Kern eine Vertrauensfrage, und deshalb wird sie selten an jemanden vergeben, der zwar sauber abfragt, aber noch nie unter Zeitdruck zurückgespielt hat.
Der übliche Weg in die Verantwortung ist schleichend: Jemand schreibt die Abfragen für eine Fachanwendung, richtet nebenbei ein paar Rechte ein, legt einen Index an, und irgendwann gilt er als der Datenbankmensch. Was in dieser Zeit nie geübt wurde, ist genau das, was im Ernstfall zählt, nämlich der Weg zurück auf einen Stand von gestern Abend.
Teuer wird das an zwei Stellen. Die eine ist der Datenverlust selbst, die andere die Zeit bis zur Wiederherstellung, in der niemand arbeiten kann. Wer beide Größen nicht als Vorgabe von der Geschäftsführung hat, entscheidet sie im Ernstfall selbst und steht danach allein damit da.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Weg in sieben Schritten
Die Reihenfolge ist nicht beliebig: Wer die Wiederherstellung übt, bevor er das erste Mal etwas verliert, kann sich beim Rest Fehler leisten.
- 1
SQL über die Abfrage hinaus beherrschen
Verbünde, Gruppierungen und Unterabfragen sind die Grundlage, aber der eigentliche Schritt ist der Ausführungsplan. Sieh dir an, wie dieselbe Abfrage mit und ohne passenden Index läuft, und lern, welche Formulierung einen Index unbrauchbar macht, etwa eine Funktion um die Spalte herum.
Geschafft, wenn: du erklärst an einem Plan, warum eine Abfrage langsam ist
- 2
Eine eigene Instanz aufsetzen
PostgreSQL lokal zu installieren, kostet nichts und zwingt dich durch alle Grundfragen: Datenverzeichnis, Speicherparameter, Anmeldeverfahren, Zeichensatz. Genau diese Entscheidungen trifft im Betrieb sonst ein Installationsprogramm für dich.
Geschafft, wenn: eine Instanz läuft, die du selbst konfiguriert hast und erklären kannst
- 3
Die Wiederherstellung üben, nicht die Sicherung
Richte Sicherungen ein, lösch danach absichtlich eine Tabelle und hol den Stand von vorher zurück. Bei PostgreSQL heißt das Transaktionsprotokoll WAL und erlaubt zeitpunktgenaues Zurückspielen, andere Systeme nennen es anders und können dasselbe. Stopp dabei die Zeit, denn diese Zahl ist die Antwort auf die Frage, wie lange ein Ausfall dauert.
Geschafft, wenn: du kennst deine eigene Wiederherstellungsdauer aus Erfahrung
- 4
Rechte schneiden, bevor jemand danach fragt
Ein Konto für die Anwendung mit genau den Rechten, die sie braucht, persönliche Konten für Menschen, Rollen statt Einzelrechte und kein gemeinsames Kennwort für alle Fälle. Prüf danach, wer im Bestand schreiben darf, und rechne damit, dass die Liste länger ist als erwartet.
Geschafft, wenn: du kannst zu jedem schreibenden Zugang sagen, wozu er da ist
- 5
Beobachten statt vermuten
Sammle langsame Abfragen und Wartezustände dauerhaft ein. PostgreSQL bringt dafür pg_stat_statements mit, der SQL Server den Query Store, Oracle liefert AWR, das allerdings eine kostenpflichtige Zusatzoption voraussetzt und ohne diese nicht benutzt werden darf. Prüf die Lizenzlage, bevor du ein Werkzeug einschaltest.
Geschafft, wenn: du zeigst auf die zehn Abfragen, die den Tag bestimmen
- 6
Wartung und Ausfallsicherheit planen
Statistiken und Wartungsläufe gehören in einen Rhythmus, ebenso wie das Aufräumen alter Versionen von Zeilen. Richte danach eine Replik ein und übe den Schwenk darauf. Ein Schwenk, den niemand geübt hat, ist im Ernstfall genauso wertlos wie eine ungeprüfte Sicherung.
Geschafft, wenn: der Schwenk auf die Zweitinstanz ist einmal ohne Zuschauer gelaufen
- 7
Ein zweites System dazunehmen
Nimm ein Produkt aus einer anderen Ecke: nach PostgreSQL etwa den SQL Server, Oracle oder MongoDB. Vergleich dabei gezielt vier Punkte, nämlich Sicherung, Rechte, Sperrverhalten und die Werkzeuge zur Beobachtung. Danach ordnest du jedes weitere System in wenigen Tagen ein.
Geschafft, wenn: du benennst zu einem fremden System die vier Punkte, die du zuerst prüfst
Sechs Stationen vom SQL zur Betriebsverantwortung
- 01 SQL sicher schreiben und den Ausführungsplan lesen können.
- 02 Eine eigene Instanz aufsetzen und selbst konfigurieren.
- 03 Die Wiederherstellung üben, nicht nur die Sicherung einrichten.
- 04 Rechte über Rollen vergeben und Anwendungszugänge trennen.
- 05 Wartezustände und langsame Abfragen dauerhaft beobachten.
- 06 Ausfallsicherheit üben und ein zweites System dazunehmen.
Was du am Ende dieses Wegs verantworten kannst
Der Weg besteht aus Handgriffen, die man im laufenden Betrieb ungern zum ersten Mal macht. Genau deshalb gehören sie in eine eigene Instanz, die niemandem wehtut.
Zurückspielen unter Zeitdruck
Du stellst eine Datenbank auf einen Zeitpunkt vor dem Fehler wieder her, kennst den Unterschied zwischen vollständiger und zeitpunktgenauer Wiederherstellung und weißt, wo die Zugangsdaten liegen, wenn das System, auf dem sie stehen, gerade nicht läuft.
Rechte sauber schneiden
Du trennst den technischen Zugang der Anwendung von den Zugängen der Menschen, vergibst über Rollen statt über einzelne Konten und kannst benennen, wer im Bestand schreibend unterwegs ist.
Ausführungspläne lesen
Du siehst im Plan, ob eine Abfrage einen Index benutzt, warum sie ihn ignoriert und an welcher Stelle die Zeilen entstehen, die alles Weitere langsam machen.
Warten statt raten
Du erkennst an Wartezuständen und Sperren, ob das System auf Speicher, auf Platten oder auf sich selbst wartet, und tauschst nicht als Erstes die Hardware.
Versionswechsel planen
Du planst einen Wechsel mit Rückweg, weißt, was ein Wartungsfenster wirklich kostet, und prüfst vorher an einer Kopie, ob die Anwendung mit der neuen Version umgehen kann.
Ein zweites System einordnen
Du überträgst Sicherung, Rechte und Beobachtung von einem Produkt auf ein anderes, weil du weißt, welche Begriffe nur anders heißen und welche wirklich etwas anderes bedeuten.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was den Alltag ausmacht, und was Leute erwarten
Erwartet wird meist ein Tag voller Abfrageoptimierung. Tatsächlich sind das einzelne Stunden im Monat. Den Alltag füllen Sicherungsprotokolle, Platzbedarf, Rechteanträge, Freigaben für neue Anwendungen, Wartungsläufe, Versionsstände, Anfragen aus der Entwicklung und die Prüfung von Änderungen, die jemand am Datenmodell vorhat.
Dazu kommt eine Sorte Arbeit, die von außen unsichtbar bleibt: das Nein. Eine Anwendung, die ihre eigenen Indizes anlegt, ein Bericht, der zur Hauptlast auf der Produktivdatenbank läuft, ein Dienstleister, der administrative Rechte für die Installation verlangt. Wer hier nachgibt, verschiebt die Störung nur in die Zukunft und erbt sie dann selbst.
Die Störungen sind selten und dafür teuer. Eine volle Platte, eine Sperre, die eine Anwendung stehenbleiben lässt, ein Ausführungsplan, der nach einem Versionswechsel kippt. Wer diese drei Fälle einmal gesehen hat, erkennt sie beim zweiten Mal in Minuten, und genau darin liegt der Wert von Berufserfahrung in dieser Rolle.
Der Weg hinein, und was von Nachweisen zu halten ist
Die zwei häufigen Herkünfte sind die Anwendungsentwicklung und die Systemadministration. Aus der Entwicklung bringt man Datenmodell und SQL mit und muss Betrieb, Sicherung und Rechte lernen. Aus dem Betrieb bringt man Wartungsfenster, Überwachung und Sicherungsdenken mit und muss Datenmodell und Ausführungspläne lernen. Beide Wege funktionieren, aber sie haben unterschiedliche Lücken.
Bei Nachweisen unterscheidet sich das Feld deutlich vom Netzbereich. Oracle und Microsoft haben eigene Zertifizierungen, die in Ausschreibungen auch genannt werden. Im PostgreSQL-Umfeld sind Nachweise weniger verbreitet, dort zählt, was du betrieben hast. Wer in einem Bewerbungsgespräch erzählen kann, wie er eine zeitpunktgenaue Wiederherstellung durchgeführt hat, ist damit fast immer weiter als mit einer Zeile im Lebenslauf.
Ein Punkt, den Quereinsteiger unterschätzen: Rufbereitschaft. Datenbanken fallen bevorzugt nachts und zum Monatsabschluss aus, und in vielen Häusern gehört ein Bereitschaftsplan zur Stelle. Frag danach, bevor du unterschreibst, und frag gleich mit, wie viele Menschen sich diesen Plan teilen.
Wie sich die Systeme im Betrieb unterscheiden
Oracle ist das System mit dem größten Regelwerk und der größten Lizenzfalle. Viele Werkzeuge zur Diagnose gehören zu kostenpflichtigen Zusatzoptionen, und wer sie einfach benutzt, erzeugt eine Nachforderung. Der SQL Server ist im Betrieb bequemer, weil Wartungspläne, Query Store und Hochverfügbarkeit eng verzahnt sind, dafür sind die Ausgaben und ihre Grenzen ein Thema für sich.
PostgreSQL verlangt mehr eigene Entscheidungen und belohnt sie mit Erweiterungen für fast jeden Zweck. Der klassische Stolperstein ist das Aufräumen alter Zeilenversionen: Wo der automatische Lauf zu selten greift, wachsen Tabellen, und im Extremfall zwingt die Transaktionsnummernvergabe zum Eingriff. MySQL ist im Webumfeld verbreitet, die Replikation über das Binärprotokoll ist schnell aufgesetzt und genauso schnell auseinandergelaufen, wenn niemand hinsieht.
MongoDB ist der größte Sprung, weil dort kein festes Schema die Struktur erzwingt. Die Verantwortung für Datenqualität wandert damit in die Anwendung, und die Betriebsthemen heißen Replikatgruppe, Fehlerübernahme und Indexentwurf. Wer aus der relationalen Welt kommt, unterschätzt regelmäßig, wie stark der Entwurf der Dokumente über die spätere Leistung entscheidet.
Woran sich zwei Leute mit gleicher Berufsdauer unterscheiden
Der eine hat die Wiederherstellung geübt, die andere hat sie eingerichtet. Das ist der größte einzelne Unterschied in diesem Beruf, und er zeigt sich genau einmal, dafür dann in voller Höhe. Wer die Übung im Kalender hat und protokolliert, kann im Ernstfall eine Dauer nennen, statt sie zu schätzen.
Der zweite Unterschied ist die Fähigkeit, mit der Entwicklung über das Datenmodell zu sprechen, ohne die Rolle des Bremsers zu spielen. Wer erklären kann, warum eine Abfrage mit dieser Struktur nie schnell wird, verändert Entwürfe früh. Wer nur ablehnt, wird umgangen, und die Anwendung geht mit ihrem eigenen Schema in Betrieb.
Der dritte ist Zurückhaltung. Erfahrene Leute ändern im Produktivsystem wenig, dokumentieren jede Ausnahme und lassen Automatik walten, wo sie funktioniert. Wer täglich von Hand nachjustiert, hält das für Sorgfalt, baut aber ein System, das nur mit ihm läuft.
Wohin die Rolle führt
Drei Richtungen sind üblich. Data Engineering, wenn dich mehr interessiert, wie Daten zwischen Systemen fließen als wie eine einzelne Instanz läuft. Cloud-Datenbanken, wo Sicherung und Verfügbarkeit vom Anbieter kommen und dafür Entwurf, Zugriffsrechte und Kosten in den Vordergrund rücken. Und Informationssicherheit, weil die Frage, wer welche Daten sehen darf, in der Datenbank endet und nirgendwo sonst.
Managed Services nehmen der Rolle die Handgriffe, nicht die Verantwortung. Wer die Sicherung nicht mehr selbst einrichtet, muss trotzdem wissen, welchen Stand er zurückbekommt und wie lange das dauert. In der Praxis verschiebt sich die Arbeit von der Installation zur Auswahl, zur Kostenkontrolle und zur Frage, was der Anbieter im Störfall wirklich zusagt.
Zur Zahl weiter unten gehört ein Hinweis: Die amtliche Statistik führt Datenbankentwicklung und Datenbankadministration in einer einzigen Berufsgattung. Jemand, der Abfragen für Berichte schreibt, und jemand, der nachts die Wiederherstellung verantwortet, stecken damit in derselben Zeile. Das ist beim Vergleich mit dem eigenen Verdienst der wichtigste Vorbehalt.
Dazu passende Kurse
Wer die Handgriffe nicht am Produktivsystem üben will, findet in den Kurse rund um Datenbankbetrieb und Wiederherstellung eine Umgebung, in der ein Fehler nichts kostet.
Die amtlichen Zahlen zu dieser Rolle
Für Datenbankarbeit gibt es genau eine amtliche Zelle, und sie fasst Entwicklung und Administration zusammen: Wer Abfragen für Berichte schreibt, und wer die Instanz samt Sicherungen verantwortet, steckt hier in derselben Zahl, und zwischen Oracle, SQL Server und PostgreSQL wird ebenfalls nicht getrennt. Das Anforderungsniveau Spezialist beschreibt den Zuschnitt der Stelle und nicht deine Berufsjahre. Der Wert gilt für Vollzeit ohne Sonderzahlungen, Weihnachts- und Urlaubsgeld kommen also noch dazu und dein Jahresverdienst liegt über dem Zwölffachen. Nimm den Median als Bezugsgröße, weil wenige sehr hoch bezahlte Stellen den Durchschnitt heben.
Amtliche Medianverdienste, April 2025
Brutto im MonatStatistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.
KldB 43353, Durchschnitt 6.244 €, gerundet rund 70.000 € im Jahr ohne Sonderzahlungen
- Vollzeitbeschäftigte, Bruttomonatsverdienst ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld, Prämien und Boni sind nicht enthalten, der Jahresverdienst liegt also über dem Zwölffachen.
- Das Anforderungsniveau beschreibt den Zuschnitt der Stelle, nicht die Berufserfahrung. Fachkraft, Spezialist und Experte sagen etwas über die Komplexität der Tätigkeit aus, nicht über Dienstjahre.
- Die Erhebung geht regional nur bis auf die Bundeslandebene. Für einzelne Städte gibt es keine amtlichen Zahlen, weil der Zufallsfehler zu groß wäre.
Quelle: Statistischer Bericht Verdienste , Statistisches Bundesamt (Destatis). Den eigenen Fall prüfst du im Entgeltatlas der Bundesagentur für Arbeit . Beachte dort: Entgelte oberhalb der Beitragsbemessungsgrenze sind der Statistik nicht bekannt, bei gut bezahlten IT-Rollen steht deshalb nur eine Untergrenze.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Muss ich programmieren können?
Welches System lerne ich zuerst?
Wird die Rolle durch Managed Services überflüssig?
Zertifikat oder eigene Instanz, was bringt mehr?
Passt thematisch dazu
Wie du eine Wiederherstellung übst, statt sie im Ernstfall zum ersten Mal zu versuchen, zeigt der Ablauf eines Restore-Tests samt gemessener Dauer .
Bevor du an einer langsamen Abfrage schraubst, ersetzt eine einzige Fertigkeit die Vermutung, nämlich wie du einen Ausführungsplan von innen nach außen liest .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Wiederherstellen übt man nicht am Produktivsystem
Bei cmt arbeitest du an eigenen Instanzen, spielst Stände zurück, liest Ausführungspläne und siehst nebeneinander, worin sich PostgreSQL, Oracle, SQL Server und MongoDB im Betrieb unterscheiden.